Discovery produit pour le fondateur non technique : ce qui compte, ce qui ne compte pas, et comment le faire en quatre semaines

Une fondatrice que nous connaissons a payé US$ 18 000 pour du “discovery produit” fin 2024. Le livrable était un Notion de 64 pages avec des personas, des journey maps, des hypothèses, des cartes d’empathie et trois ateliers enregistrés. Bien fait, dans le standard des cours de produit. Quatre mois plus tard, elle n’avait toujours pas de logiciel, pas de scope, pas de décision. Elle avait un rapport.

Le discovery produit, en une phrase, c’est le travail qui transforme une intuition d’opportunité en une décision de construire, avec un scope, un coût et un délai défendables. Pour une équipe produit mature, c’est une pratique continue de recherche et de validation. Pour un fondateur non technique qui n’a encore rien construit, c’est autre chose : c’est la diligence minimale qui sépare un brief sérieux d’un chèque signé à l’aveugle. Les articles qui dominent cette requête sur Google enseignent la première version. La deuxième, qui est la vôtre, personne ne l’écrit.

Ce texte parle de la version qui colle à votre situation. Plus courte, plus étroite, et qui se termine par une décision, pas par un document.

Le discovery n’est pas de la recherche, c’est de la diligence

Le mot “discovery” porte un problème de traduction culturelle. Dans le lexique américain du produit, il vient du monde des PMs senior dans les grandes entreprises, où le temps passé à explorer un problème est justifié par l’ampleur de la décision de roadmap qui suivra. Quand vous êtes fondateur non technique et que vous n’avez encore rien construit, votre décision n’est pas “quelle feature prioriser au Q3”. Votre décision, c’est “vaut-il la peine de construire quelque chose, avec quel scope, et pour quel budget”. C’est de la diligence, pas de la recherche.

La diligence a des critères objectifs. La recherche pose des questions ouvertes. Les deux se ressemblent dans les premières semaines. La différence apparaît au moment de clore.

La version que nous décrivons ici est, en fait, un sous-ensemble discipliné de ce qu’enseignent les frameworks canoniques (Marty Cagan, Teresa Torres, Jeff Patton). C’est la partie qui paie le loyer pour votre étape. Le reste, en général, vous coûtera du temps que vous n’avez pas.

Là où le discovery typique échoue pour les fondateurs

Le modèle standard suppose trois choses qu’un fondateur non technique n’a pas : une équipe pluridisciplinaire, un produit déjà en production, et des dizaines d’utilisateurs disponibles pour entretien continu. Retirez ces trois prémisses du framework et essayez de l’appliquer pareil, vous êtes comme un cardiologue traitant un patient sans aucun examen d’imagerie. Le médecin continue de donner de bonnes intuitions, mais il perd l’outil principal.

Trois échecs que nous avons vus se répéter chez beaucoup de fondateurs.

Le premier, c’est le discovery sans deadline. Sans deadline ferme, le discovery devient le meilleur projet de votre vie. Vous trouvez toujours un entretien de plus, une hypothèse de plus à valider, une étude de marché de plus qui semble utile. Un mois devient trois, trois deviennent six. Le capital brûle et le logiciel ne naît pas.

Le deuxième, c’est le discovery académique. Le fondateur, souvent quelqu’un avec un parcours de conseil ou de finance, aime les frameworks. Il apprend Jobs to Be Done, Double Diamond, Design Thinking, Lean UX et veut tous les appliquer. Le résultat ressemble à un mémoire de master en produit et ne répond jamais à la question de base : peut-on construire, avec qui, pour combien, en combien de temps.

Le troisième, et le plus cher, c’est le discovery sans utilisateur réel. Les fondateurs sont tentés de faire toute leur “recherche” avec des collègues, des mentors et des investisseurs. Ces gens-là sont généreux en avis et économes en vérité. Ce qu’ils vous disent dans un appel de 30 minutes n’est pas ce qu’un client réel paierait pour résoudre. Le discovery de fondateur exige des conversations avec au moins cinq personnes qui correspondent exactement à votre ICP, hors de votre cercle, qui ne vous doivent rien.

Les cinq questions auxquelles tout discovery de fondateur répond

Au lieu d’adopter un framework produit traduit, nous proposons cinq questions. Elles sont petites, mais si vous ne pouvez pas répondre à chacune par une phrase concrète, vous n’avez pas terminé.

1. Qui est la personne précise qui va payer, et pourquoi paie-t-elle aujourd’hui (même mal) pour le problème ? Si vous ne pouvez pas dire “elle paie X € pour Y, aujourd’hui, avec la solution Z”, vous avez encore une hypothèse de marché, pas un client. Cela vaut pour le B2B comme pour le B2C.

2. Quelle friction tolère-t-elle parce qu’elle n’a pas d’alternative ? Le logiciel qui vaut la peine d’être construit résout une vraie friction. Pas celle qu’elle mentionne d’abord (qui est en général le prix), mais celle qui apparaît quand vous demandez “comment vous faites ça aujourd’hui” et que vous entendez la description d’un processus manuel que personne ne devrait faire en 2026.

3. Quel est le scope minimal qui remplace un workflow manuel par un workflow automatisé, de bout en bout, pour un seul cas d’usage ? Attention au “de bout en bout”. La moitié des logiciels que les fondateurs achètent ne résout que la partie élégante du problème et pousse le reste vers un tableur. Ce n’est pas un produit, c’est une démo.

4. Quelle preuve montre que votre version est suffisamment différente pour que quelqu’un paie ? Différente en quoi : prix, intégration, parcours, données, contexte local. Si votre réponse est “meilleur design”, vous cherchez encore. Le meilleur design seul est presque jamais un wedge défendable.

5. Quelle est la plus grosse chose qui peut mal tourner, et comment sauriez-vous en quatre semaines qu’elle a mal tourné ? Toute construction est un pari. Le discovery se termine quand vous avez une hypothèse falsifiable rapidement, et un plan explicite pour la tester une fois que le code existe.

Si vous pouvez répondre aux cinq sur une page, vous avez fini. Si vous y répondez sur vingt pages, vous avez fait le mauvais discovery.

Le discovery de quatre semaines : un calendrier honnête

Nous n’avons pas rencontré un seul bon discovery de fondateur qui ait pris plus de quatre semaines de temps dédié. Nous en avons connu beaucoup qui se sont étirés en temps total parce que le fondateur jonglait avec d’autres choses, mais le “temps de focus” dépasse rarement un mois utile.

Voici le calendrier que nous recommandons à un fondateur non technique qui n’a encore rien construit :

Semaine 1 : carte du territoire. Vous décrivez le problème dans le vocabulaire de vos futurs clients (pas dans votre vocabulaire académique de fondateur). Vous listez explicitement qui vit ce problème aujourd’hui. Vous menez cinq à huit conversations courtes (30 minutes), enregistrées et transcrites, avec des gens que vous ne connaissez pas personnellement. Vous demandez comment ils résolvent ça aujourd’hui, ce qu’ils paieraient, et ce qu’ils ont “essayé et qui n’a pas marché”.

Semaine 2 : un cas d’usage de bout en bout. Vous prenez un seul cas réel chez l’une des personnes interviewées et vous dessinez son flux complet, du moment où le problème se déclenche jusqu’au résultat souhaité. Sur papier, dans Miro, dans Excel, peu importe. Le critère : quelqu’un qui n’a jamais entendu parler de votre produit peut lire ce flux et décrire ce que ferait le logiciel. Cela vous force déjà à couper 40% de ce que vous imaginiez au départ.

Semaine 3 : un spec d’une page. Traduction du flux en une spécification courte qui décrit ce que fait le logiciel, quelles décisions il automatise, quelles décisions il laisse à l’utilisateur, et quelles intégrations il doit avoir pour ne pas casser le premier mois. Ce spec est la base du product requirements document que vous remettrez au développeur.

Semaine 4 : diligence commerciale. Vous utilisez ce spec pour parler à deux ou trois software houses, à un freelance senior, et (si cela a du sens) à un candidat pour premier dev interne. Pas pour embaucher. Pour valider trois choses : le scope est assez clair pour recevoir un devis sérieux, ce devis colle avec votre matrice de coût, et le calendrier tient dans le runway que vous avez avant la prochaine fenêtre commerciale.

Quatre semaines. Cinq questions répondues. Un spec d’une page. Trois devis comparables. Vous n’avez pas terminé un Notion de 64 pages, vous avez terminé une décision.

Le livrable : une spécification qui empêche la software house de vous mener en bateau

La plus grande vertu du discovery court, c’est ce qui en sort. Pas une présentation. Pas un rapport. Une page dense qui décrit, au bon niveau de détail, ce que va faire le logiciel.

Cette spec a quatre blocs, et rien d’autre.

L’objectif business en deux lignes. Si vous dépensez plus que ça, vous n’avez pas convergé.

Le cas d’usage primaire sous forme de parcours en cinq à huit étapes, du déclencheur au résultat. Vous pouvez écrire ce bloc comme des bullets comportementaux (“l’utilisateur colle le lien”, “le système valide”, “le système demande”, “le système exécute”, “le système notifie”). Sans décoration, sans visualisation.

Les décisions techniques que prend le fondateur et celles qu’il délègue. Il y a trois ou quatre décisions qui pèsent sur le budget et que le fondateur doit pouvoir défendre (multi-tenant ou pas, intégration critique X ou Y, mobile-first ou web-first, données sensibles sous régulation ou pas). Le reste, vous le déléguez à celui qui va construire.

Les trois choses explicitement hors du scope de la v1. Un bon discovery porte autant sur ce qu’on garde que sur ce qui sort. Quand vous nommez ce que vous coupez, vous coupez vraiment. Quand vous ne le nommez pas, la software house rouvre la conversation dès que le budget commence à serrer.

Ce document d’une page, c’est la différence entre un brief que la software house peut chiffrer en forfait et un brief qui se transforme en contrat en régie sans plafond. C’est le filtre contre les devis gonflés : quand le scope est clair, on voit tout de suite quand le chiffre est honnête et quand c’est de la marge.

Quand vous terminez le discovery, et quand vous procrastinez

La ligne entre “je n’ai pas encore fini” et “j’utilise le discovery pour retarder la décision” est fine. Pour la plupart des fondateurs non techniques, elle passe par ici.

Si vous êtes en discovery dédié depuis plus de quatre semaines, vous ne validez plus, vous repoussez. Le discovery ne s’améliore pas avec plus de temps au-delà d’un certain point. Il devient plus redondant. Chaque nouvel entretien confirme ce que les trois précédents ont déjà dit, ou contredit quelque chose de précis que vous pouvez résoudre par une petite décision, pas par un mois de recherche supplémentaire.

Si vous ne pouvez pas écrire votre spec d’une page sans retomber sur “ça dépend du feedback des utilisateurs”, vous êtes coincé dans une boucle de validation qui ne se terminera pas toute seule. La spec est le résultat d’une synthèse, pas d’une recherche continue. À un moment, vous fermez le carnet et vous écrivez.

Si vous n’avez encore parlé à aucune software house, freelance ou candidat dev avec votre matériel, vous n’avez fait que la moitié du discovery. La diligence technique et commerciale, c’est ce qui valide que votre spec est constructible dans le budget et dans le temps. Sauter cette partie, c’est comme valider un plan de voyage sans vérifier qu’il existe un avion pour la destination.

Retour à la première PAA : alors c’est quoi, le discovery produit ?

En une phrase : c’est le travail qui transforme une intuition d’opportunité en une décision de construire, avec un scope, un coût et un délai défendables. Pour un fondateur non technique, c’est un exercice de diligence fait en quatre semaines, ancré sur cinq questions, avec un spec d’une page comme livrable.

Ce n’est pas un atelier. Ce n’est pas une hypothèse empilée sur une hypothèse. Ce n’est pas une carte d’empathie. Ces outils existent, ils sont utiles dans d’autres situations, et ils peuvent apparaître ponctuellement dans votre discovery. Ils ne doivent pas être le discovery.

Et les quatre phases d’un produit ?

La PAA pose cette question parce que l’internet produit francophone parle beaucoup de “cycle de vie du produit”. Pour le fondateur, les quatre phases qui comptent sont, dans un ordre honnête : le discovery (vous êtes ici), la décision de construire, une première version réelle en production, et l’itération avec des clients qui paient. Le choix des outils et des approches à l’intérieur de la troisième phase n’a de sens qu’une fois que la phase 1 a livré une décision.

La phase où la plupart des fondateurs non techniques se coincent, c’est entre 1 et 2. Le discovery se termine quand vous avez assez de preuves pour prendre une décision de construire. Si vous collectez encore des preuves, vous n’avez pas quitté la phase 1.

Comment savoir que vous avez fini : le test de l’enveloppe

Si un client potentiel entrait dans votre bureau maintenant, et que vous deviez expliquer en trois minutes ce que vous allez construire, pour qui, avec quelle différence, en combien de temps, et pour combien, le pourriez-vous ? Sans slides, sans Notion, sans replonger dans “ça dépend”.

Si oui, vous avez fini le discovery. Vous pouvez arrêter de chercher et commencer à construire.

Sinon, il vous reste du travail. Mais le travail, c’est de fermer une des cinq questions, pas de tout recommencer.

Le discovery de fondateur n’est pas la partie glamour du métier. Mais c’est la seule partie où cinq heures d’honnêteté brutale valent plus que cinquante heures de framework. La différence entre les fondateurs qui construisent et ceux qui restent en discovery pendant neuf mois est en général juste là : les premiers savent clore.