Extraire la verite client : notre methode d'interview

Chaque projet commence par une conversation. Pas un pitch. Une écoute. Avant de concevoir un seul plugin, avant d'écrire une ligne de code, on s'assoit avec l'équipe client et on pose des questions. Pas des questions sur ce qu'ils veulent. Des questions sur ce qu'ils vivent.

CB Insights a analyse les causes d'échec de plus de 100 startups : 42% ont echoue parce qu'il n'y avait pas de besoin réel. Combien d'outils ont été développés parce qu'un manager a dit "ce serait bien d'avoir ça" sans que personne ne verifie ? Rob Fitzpatrick a écrit The Mom Test pour résoudre cette question. Le titre vient d'une idée simple : même ta mère te mentirait si tu lui poses la mauvaise question. Et nos clients, aussi honnêtes soient-ils, font pareil.

Les questions qu'on pose vraiment

En discovery call, on ne demande jamais "est-ce que vous aimeriez un plugin qui fait X ?". Cette question invité le "oui" poli. A la place, on explore le quotidien.

"Raconte-moi la dernière fois que ce problème t'a bloque." C'est la question d'ouverture. Elle force le concret. Si le client peut décrire une situation precise avec des details (date, contexte, conséquence), le problème est réel. S'il reste vague, c'est un inconfort, pas une douleur.

"Qu'est-ce que tu as essaye pour résoudre ça ?" Les tentatives passees sont le meilleur indicateur. Un client qui a écrit un script maison, installe trois extensions VS Code et passe des heures sur des workarounds a un vrai problème. Un client qui n'a jamais rien tente a un problème théorique.

"Combien de temps ça te coute par semaine ?" Le temps est la monnaie universelle. Si un dev passe 4 heures par semaine a copier-coller des snippets entre fichiers, tu as un signal fort. S'il dit "un peu de temps" sans pouvoir chiffrer, le problème n'est pas assez douloureux pour justifier un investissement.

Distinguer besoin réel et nice-to-have

Un client nous a dit un jour : "On a besoin d'une meilleure intégration IA dans notre workflow." Belle phrasé. Inutile. En creusant avec les questions du Mom Test, on a découvert que le vrai problème n'avait rien a voir avec l'IA. L'équipe n'avait pas de processus de code review structure. Les PR restaient ouvertes des jours. Les feedbacks étaient inconsistants d'un reviewer a l'autre.

Le plugin qu'on a conçu n'était pas un "assistant IA générique". C'était un skill de code review qui imposait une checklist standardisee, detectait les patterns recurrents et generait un premier draft de review que le reviewer humain pouvait affiner. Le besoin réel était la structure, pas la magie.

Steve Blank écrit dans HBR que la validation ne vient pas de ce que les clients disent vouloir, mais de ce qu'ils font déjà. Notre discovery call applique ce principe : on observe les comportements passes, pas les projections futures.

Notre grillé de signaux

Chaque discovery call produit des signaux. On les classe par niveau de fiabilité, exactement comme Fitzpatrick le recommande.

Signal	Niveau	Ce qu'on en fait
"Ça serait cool d'avoir ça"	Compliment	On note, on ne construit pas
"On a essaye de résoudre ça avec un script"	Tentative passee	Signal moyen, on creuse
"Ça nous coute 3 heures par dev par semaine"	Douleur chiffree	Signal fort, on valide
"On a budgete pour résoudre ce problème"	Engagement financier	Signal très fort, on avance
"Je te mets en contact avec le CTO"	Mise en relation	Signal de confiance

La répétition compte plus que l'intensité. Un prospect enthousiaste est une anecdote. Cinq équipes qui decrivent le même problème avec les mêmes mots, c'est un pattern fiable.

Mais attention : le Mom Test n'est pas un interrogatoire. La discovery call reste une conversation. Si le client se sent "examine", il se ferme. On pose des questions ouvertes, on rebondit sur ce qu'il dit, on laisse les silences faire leur travail. Le ratio est le même que Fitzpatrick recommande : 20% de parole, 80% d'écoute.

Du Mom Test a l'audit technique

Les insights de la discovery call alimentent directement notre audit. C'est la première étape du workflow PluginFactory : Audit, Conception, Déploiement, Formation, Maintenance. Sans discovery call rigoureuse, l'audit part dans la mauvaise direction.

C'est la phase "Observe" du framework FOCUSED : aller sur le terrain pour comprendre, pas pour confirmer. Et c'est aussi le premier diamant du Double Diamond : diverger pour explorer avant de converger sur une solution.

Quand on arrive a l'audit technique, on sait déjà quels processus investiguer en priorité. On ne perd pas de temps a auditer des workflows que personne n'utilise vraiment. On construit des processus autour des vrais points de friction, pas autour des demandes de surface.