Apprenez à construire une startup en partant de problèmes douloureux, pas d’idées brillantes. Trouvez une demande réelle, validez rapidement et gagnez avec une valeur claire.
Un problème douloureux est quelque chose que les gens ressentent déjà dans leur vie quotidienne ou au travail — quelque chose qui leur coûte de manière fiable du temps, de l’argent, du chiffre d’affaires, du sommeil, de la réputation ou un risque de conformité. Ils ne sont pas « intéressés » à le réparer ; ils essaient déjà de le réduire, même si leur solution actuelle est bricolée (tableurs, contournements manuels, embauche de temporaires, ou simplement y survivre).
Une idée cool est l’inverse : elle est nouvelle, astucieuse ou excitante — mais elle n’est pas liée à un problème fréquent, coûteux et marqué. Les gens peuvent dire que c’est « sympa » ou « j’utiliserais ça », mais ils ne changent pas de comportement ni n’allouent de budget pour l’obtenir.
La douleur crée de l’urgence. Si le problème coûte cher ou est suffisamment risqué, les gens prêtent vite attention : ils répondent à vos mails, prennent des réunions et testent des alternatives. La douleur crée aussi du budget : les entreprises financent les problèmes qui menacent le chiffre d’affaires, gaspillent des heures de paie ou augmentent l’exposition au risque. Les individus dépensent pour résoudre un gain de temps, réduire le stress ou éviter quelque chose de pire.
Les idées cool se retrouvent généralement face à un « peut-être plus tard ». Quand il n’y a pas de conséquence immédiate à l’ignorer, elles perdent face à tout le reste dans la liste des priorités.
Ce guide suit un chemin répétable :
Vous n’êtes pas là pour parier des mois sur une grosse construction. Vous allez exécuter des tests réduits — conversations courtes, prototypes légers, préventes et MVPs restreints — pour prouver qu’il existe un problème douloureux avec une réelle disposition à payer. Si la douleur n’est pas là, vous le saurez tôt et pourrez pivoter, recentrer ou renoncer sans regret.
Une « idée cool » est facile à aimer et difficile à vendre. Elle reçoit des compliments, des upvotes et des « tu devrais absolument construire ça » — mais cette admiration ne se traduit pas en startup orientée problème avec une vraie volonté de payer.
Quand une idée n’est pas liée à un point de douleur net, les mêmes symptômes réapparaissent :
Une douleur légère engendre une procrastination infinie. Si votre produit aide sur quelque chose « énervant » plutôt que « coûteux », les acheteurs repoussent toujours : « Revenons-y le trimestre prochain. » C’est mortel pour les fondamentaux du go-to-market, car c’est l’urgence qui transforme les conversations en décisions.
C’est pourquoi la discovery client doit moins porter sur ce que les gens aiment et plus sur ce qu’ils ont déjà essayé pour réparer — surtout quand du temps, de l’argent ou de la réputation sont en jeu. En termes de jobs-to-be-done : quel travail échoue, et quel est le coût de cet échec ?
Les fonctionnalités nouvelles peuvent temporairement masquer une demande faible. Les premiers utilisateurs y jouent, partagent et louent le design — tout en refusant de l’intégrer dans leurs workflows ou d’en payer le prix. La nouveauté augmente l’attention, pas l’engagement.
L’objectif quand vous validez une idée de startup n’est pas l’admiration. C’est un soulagement mesurable : cycles plus courts, moins d’erreurs, moins de travail manuel, moins de risques, revenus plus rapides. Si vous ne pouvez pas nommer le soulagement et le mesurer, votre MVP axé sur la douleur aura du mal à gagner des adopteurs.
Les idées cool excitent, mais les problèmes douloureux ont de la gravité. Pour rester honnête, utilisez un « score de douleur » rapide avant de tomber amoureux d’une solution.
Attribuez à chaque dimension un score de 1 à 5, puis multipliez.
Un problème hebdomadaire (4), qui bloque le travail (5) et coûte 2k$/mois (4) obtient 80. Une gêne rare et légère ne peut pas rivaliser.
Notez trois rôles :
Une forte douleur sans acheteur clair se transforme souvent en « tout le monde est d’accord, personne ne paie ». Les meilleures opportunités ont la douleur et le budget alignés — ou un champion interne capable de traduire la douleur utilisateur en business case.
La douleur devient urgente quand une horloge lui est attachée :
Si un client répond « on s’en occupe le trimestre prochain », votre score de douleur est probablement surévalué.
Les contournements sont la preuve que quelqu’un paie déjà — simplement pas avec votre produit. Surveillez :
Plus les gens dépensent d’effort pour éviter le problème, plus ils seront susceptibles de payer pour le soulagement.
Un problème douloureux devient business seulement lorsqu’il appartient à un quelqu’un réel, dans une situation réelle, avec de vraies contraintes (temps, budget, outils, approbations). « Petites entreprises » ou « créateurs » est trop vague — la douleur se dilue et votre apprentissage ralentit.
Choisir un client et un contexte précis vous permet de :
En commençant large, chaque conversation paraît différente, et vous finissez par construire un produit flexible qui ne convient à personne.
Cherchez des endroits où les gens se plaignent avec urgence et détail — surtout quand le même problème revient :
La douleur concentrée ressemble à des scénarios répétés, des émotions fortes (« ça nous tue ») et des personnes déjà en train de dépenser du temps ou de l’argent pour colmater le problème.
Utilisez ceci pour définir votre premier client cible :
Si vous ne pouvez pas remplir « où les atteindre cette semaine », l’audience est encore trop vague.
La discovery client ne consiste pas à demander si les gens trouvent votre idée « bonne ». Il s’agit de découvrir ce qu’ils font aujourd’hui pour gérer une situation douloureuse — et ce que cela leur coûte.
Les questions d’opinion (« Tu utiliserais… ? » « Tu aimes… ? ») produisent des réponses polies et inexactes. Les questions sur le comportement révèlent la réalité.
Essayez des amorces comme :
Coupez court aux réponses vagues en demandant un incident concret et récent :
S’ils ne se souviennent pas d’un exemple récent, la douleur peut être occasionnelle — ou pas assez importante.
La douleur se mesure. Pendant le récit, écoutez (et demandez) les coûts :
Évitez de décrire votre solution ou de demander une validation. Collectez plusieurs histoires, puis cherchez les déclencheurs, contournements et conséquences répétées.
Une bonne conclusion : « Si tu pouvais agiter une baguette magique et changer une chose dans ce process, quoi serait-ce — et pourquoi ? »
Après quelques conversations clients, vous aurez des pages de citations et d’anecdotes. L’objectif est de transformer ce bazar en un ensemble clair et classé de problèmes — pour ne pas construire autour de l’histoire la plus divertissante plutôt que la plus douloureuse.
Extrayez des problèmes, pas des demandes de fonctionnalités. Mettez en évidence les moments où la personne décrit friction, retard, risque, gêne, travail supplémentaire ou argent perdu. Regroupez les moments similaires sous un même libellé de problème.
Créez un tableau simple avec des colonnes comme : Problème, Qui l’a dit, Fréquence, Gravité, Contournement actuel, Coût du contournement. Classez les problèmes avec un score rapide (par ex. 1–5 pour fréquence et 1–5 pour gravité). Multipliez-les. Vous verrez vite ce qui est constamment douloureux.
Faites attention aux phrases exactes que les clients répètent : « Je déteste… », « Ça casse toujours quand… », « Je reste bloqué en attendant… ». Le langage répété est un signal que le problème est top-of-mind.
Regardez aussi les conséquences répétées — souvent plus fortes que les plaintes :
Écrivez une phrase qui force la clarté :
Pour [client précis] dans [contexte précis], [problème] se produit quand [déclencheur], causant [conséquence douloureuse] parce que [cause racine].
Si vous ne pouvez pas remplir chaque partie avec de vraies citations, vous n’avez pas fini.
Certains problèmes paraissent « plus gros » ou plus amusants. Ignorez tout ce qui :
Ce qui reste est votre meilleur candidat pour un problème qui mérite d’être résolu.
Valider ce n’est pas « est-ce que les gens aiment ça ? » C’est « quelqu’un s’engagera-t-il avec du temps, de la réputation ou de l’argent pour que ce soit réglé ? » Avant d’écrire du code, cherchez des preuves concrètes que la douleur est assez forte pour déclencher l’action.
Les meilleurs signaux impliquent de l’engagement :
Créez une page simple avec une offre précise : pour qui c’est, la situation douloureuse, le résultat promis, et un appel à l’action clair (réserver un appel, rejoindre un pilote, verser un dépôt). Puis faites de l’outreach ciblé vers des personnes correspondant exactement au contexte.
Votre objectif n’est pas le trafic. C’est des conversations avec des acheteurs qualifiés. Une douzaine d’outreaches de haute qualité peut valoir mieux que mille clics aléatoires.
Évitez « combien paieriez-vous ? » Ancrez le pricing sur les alternatives actuelles :
Décidez en amont ce qu’est un “pass” : nombre d’appels qualifiés réservés, engagements de pilote, montant de dépôt, ou taux de conversion de l’outreach à l’étape suivante. Si vous ne pouvez pas fixer un seuil, vous testez au lieu d’espérer.
Un MVP n’est pas une version réduite de votre produit rêvé. C’est le moyen le plus petit d’apporter une baisse réelle et perceptible de la douleur client.
Commencez par écrire le résultat en langage clair :
Gardez-le mesurable et immédiat.
Exemples :
Ce résultat devient votre cible MVP. Tout le reste est optionnel.
Si une fonctionnalité n’accélère pas le temps vers le soulagement, ne la mettez pas dans le MVP. Les premiers clients pardonnent des défauts quand la douleur diminue rapidement ; ils ne pardonnent pas des extras « nice-to-have » qui retardent le soulagement.
Règle utile : expédiez la première version capable de délivrer le résultat au moins une fois pour un vrai client, de bout en bout.
Pour apprendre plus vite, remplacez le logiciel par des humains quand c’est nécessaire :
Le travail manuel n’est pas un échec ; c’est comment vous découvrez ce qui doit être automatisé plus tard.
Quand la rapidité compte, utilisez des outils qui vous permettent de prototyper le workflow et d’itérer en jours, pas en semaines. Par exemple, une plateforme de vibe-coding comme Koder.ai peut être utile ici : vous pouvez décrire le workflow dans le chat, générer une application web fonctionnelle (souvent React en front et Go + PostgreSQL en back sous le capot), puis l’affiner à mesure que vous apprenez des pilotes. Si le test fonctionne, vous pouvez exporter le code source et continuer ; sinon, vous avez minimisé le sunk cost.
Des fonctionnalités comme le mode planification, les snapshots et le rollback peuvent aussi vous aider à mener des expériences MVP contrôlées sans transformer chaque changement en grosse refonte.
Écrivez-le et partagez-le avec les premiers clients :
L’objectif est le soulagement, la preuve de demande et la clarté sur la suite, pas la perfection.
Le positionnement n’est pas « ce que le produit fait ». C’est une promesse claire à une personne précise dans une situation précise : vous avez ce problème douloureux, et nous vous aidons à obtenir ce résultat. Si votre positionnement ressemble à une liste de fonctionnalités, vous forcez les clients à faire la traduction.
Utilisez une structure simple et restez concret :
« Pour X, qui ont du mal avec Y, nous fournissons Z résultat. »
Exemples :
Remarquez que le résultat est ce qu’ils veulent, pas ce que vous avez construit.
Les clients n’achètent pas du « mieux ». Ils achètent moins de risque, moins de temps, plus d’argent, moins d’erreurs. Traduisez la douleur en résultats précis :
Si vous ne pouvez pas encore le mesurer, choisissez un proxy (« moins d’échanges », « une source de vérité », « délai de traitement en same-day ») et affinez après usage réel.
Votre meilleur copy est souvent une citation directe des appels de discovery. Gardez un fichier de formules exactes utilisées par les clients (« Je suis constamment en train de relancer… », « On est aveugles jusqu’à la clôture du mois… »).
Miroitez ces mots :
Les objections comparent souvent à ce qu’ils font déjà. Listez les vraies alternatives (tableurs, outil généraliste, agence, « ne rien faire ») et répondez-y directement :
Un bon positionnement rend l’achat équivalent à du soulagement, pas à un pari.
Le go-to-market initial n’est pas un growth hack. C’est une mission de vérification de la vérité. Votre but est de confirmer (ou infirmer) que la douleur est réelle, fréquente et assez coûteuse pour pousser les gens à changer de comportement et à payer.
Choisissez un canal qui vous met en contact direct avec les acheteurs rapidement :
Ne vous dispersez pas sur cinq canaux. Un seul suffit tant que vous pouvez réserver des conversations régulièrement.
Traitez chaque pitch comme une interview avec un prix. Vous testez :
Si les gens ne font pas l’étape suivante — essai, pilote, test payant — vous avez appris quelque chose d’important.
Gardez-le simple et mesurable :
Observez où vous fuyez. Si les appels deviennent des pilotes mais que les pilotes ne deviennent pas payants, votre MVP ne libère peut-être pas le soulagement assez vite — ou vous vendez au mauvais acheteur.
Chaque « non » doit donner une raison. Capturez-la mot pour mot et taguez-la (timing, prix, confiance, fonctionnalité manquante, mauvais persona, valeur peu claire). Puis réinjectez ces apprentissages dans :
Le but de la vente précoce n’est pas de gagner des arguments, c’est de compresser l’apprentissage en semaines plutôt qu’en mois.
Une idée cool peut obtenir des inscriptions. Un problème douloureux fait changer de comportement, fidélise et fait payer. L’objectif des métriques ici est simple : prouver que les utilisateurs obtiennent un vrai résultat — pas seulement qu’ils cliquent.
Au début, concentrez-vous sur les signaux montrant que votre produit apporte rapidement du soulagement :
Si l’activation est élevée mais l’usage répété faible, vous résolvez peut-être une tâche « nice-to-have » plutôt qu’une douleur urgente.
La rétention est la preuve la plus claire que le problème persiste.
Suivez la rétention par cohorte (semaine 1 → semaine 4, mois 1 → mois 3) et associez-la à des signaux d’expansion :
Quand la douleur est réelle, les clients élargissent naturellement l’usage parce que le produit est lié à un travail critique.
Surveillez les utilisateurs qui se connectent mais n’achèvent pas le travail :
Cela signifie souvent que la valeur est peu claire, que le workflow est trop dur, ou que le résultat n’est pas assez attractif.
Le churn et les essais stoppés sont des données. Faites des interviews courtes pour apprendre :
Servez-vous de ces réponses pour affiner votre ICP et resserrer la phrase-problème. Si le churn est aléatoire et les raisons vagues, vous n’êtes probablement pas encore ancré sur un problème douloureux spécifique.
La plupart des « échecs » précoces ne viennent pas d’un mauvais produit — mais d’une douleur insuffisante, ou d’un mauvais acheteur. Le but n’est pas de persister indéfiniment ; c’est d’apprendre vite et de prendre une décision claire.
Pivotez quand vous constatez un effort constant de votre part mais un tirage incohérent des clients. Signes courants :
Si ces schémas apparaissent dans plusieurs conversations, vous n’avez probablement pas un vrai problème douloureux — du moins pas tel que vous l’avez formulé.
Il y a deux mouvements distincts :
Ne changez pas les deux en même temps, sinon vous ne saurez pas quelle modification a produit l’amélioration.
Même quand les résultats sont faibles, gardez les preuves : un message qui a obtenu des réponses, un canal qui a produit des appels qualifiés, ou un cas d’usage où l’urgence a augmenté. Traitez-les comme des ancres pendant que vous testez des changements.
Fixez une règle de décision time-boxée pour éviter le bricolage sans fin : par exemple, « Dans les 3 prochaines semaines, faire 15 discovery calls et essayer de conclure 3 pilotes payants. Si on ne trouve pas de propriétaire budget et un déclencheur d’urgence répétable, on arrête. »
Partir n’est pas un échec ; c’est protéger votre temps pour un problème qui fait vraiment mal.
Un problème douloureux coûte de manière fiable à quelqu’un du temps, de l’argent, du chiffre d’affaires, de la réputation, du sommeil ou implique un risque de conformité, et cette personne cherche déjà à le réduire (même avec des contournements bricolés).
Une idée « cool » suscite de l’intérêt et des compliments, mais elle ne force pas à agir — elle se retrouve donc face au « peut-être plus tard ».
La douleur crée de l’urgence et du budget. Quand un problème menace le chiffre d’affaires, gaspille des heures de paie ou augmente le risque, les gens :
La nouveauté attire l’attention, mais c’est l’urgence qui produit des décisions.
Utilisez un score simple : Fréquence × Gravité × Coût (chacun 1–5), puis multipliez.
Si vous ne pouvez pas quantifier au moins un de ces éléments avec des exemples concrets, vous traitez probablement d’un « nice-to-have ».
Définissez trois rôles :
Si les utilisateurs ressentent la douleur mais qu’il n’y a pas d’acheteur clair (ou de processus d’achat), vous risquez « tout le monde est d’accord, personne ne paie ». Visez l’alignement douleur–budget ou un champion interne capable de transformer la douleur en business case.
Cherchez une horloge qui force l’action, par exemple :
Si la réponse courante est « on verra au trimestre prochain », considérez que l’urgence (et la volonté de payer) est probablement faible.
Les contournements prouvent que des gens paient déjà — simplement pas avec votre produit. Exemples :
Plus un contournement demande d’effort et de coordination, meilleures sont vos chances que la relief ait une vraie valeur commerciale.
Posez des questions sur le comportement et des incidents récents, pas des opinions :
Évitez « Tu l’utiliserais ? » : ce type de question donne des réponses trop polis et peu fiables.
Cherchez des signes d’engagement concret avant de coder :
L’intérêt sans engagement n’est que du bruit ; l’engagement est la preuve.
Définissez le plus petit résultat soulageant : « Après utilisation, le client n’a plus à… » et rendez-le mesurable.
Puis déployez la version la plus petite capable d’atteindre ce résultat de bout en bout au moins une fois, même si cela implique des étapes manuelles (onboardings concierge, mise en œuvre « done-with-you », imports manuels). La rapidité pour apporter du soulagement prime sur la complétude fonctionnelle.
Pivotez (ou resserrez) quand vos efforts sont constants mais que la traction client est irrégulière :
Différenciez les mouvements :
Time-boxez les tests (ex. X appels, Y tentatives de pilote) pour éviter de bricoler indéfiniment.
