Vous n'avez pas un problème d'idée, vous avez un problème d'hypothèses

« Est-ce que mon idée est bonne ? » est la question que se posent tous les porteurs de projet, et c'est une question à laquelle personne ne peut répondre. Pas votre entourage, pas un investisseur, pas une IA générative, pas nous. Elle est mal posée.

Une idée n'est pas un bloc que l'on valide ou que l'on rejette. C'est un empilement d'hypothèses dont certaines sont probablement justes, certaines probablement fausses, et une ou deux fatales si elles s'avèrent fausses. Tant que vous raisonnez sur l'idée entière, vous ne pouvez ni la tester, ni progresser, ni savoir où vous en êtes.

Cet article pose la méthode qui structure tout le reste de ce blog : découper une idée en hypothèses, les classer par risque réel, et les tester dans un ordre qui minimise ce que vous perdez en cas d'erreur.

Pourquoi « bonne idée » ne veut rien dire

Prenons un exemple volontairement banal : une application qui aide les indépendants à relancer leurs factures impayées.

Formulée comme ça, l'idée est invérifiable. Elle semble raisonnable, on peut lui trouver des arguments, et on peut tout aussi bien lui trouver des objections. Vous pouvez en discuter pendant six mois sans avancer d'un pas.

Maintenant écrivons ce qu'elle suppose réellement :

• Les indépendants ont effectivement un problème d'impayés significatif.
• Ce problème leur coûte assez cher pour qu'ils cherchent une solution.
• Ils ne l'ont pas déjà résolu autrement (relances manuelles, outil de facturation existant, affacturage).
• Ils sont prêts à payer un abonnement pour ça.
• On peut les atteindre à un coût inférieur à ce qu'ils rapporteront.
• La relance automatisée est techniquement et juridiquement praticable.

Six affirmations. Chacune peut être vraie ou fausse indépendamment des autres. Chacune est testable. Et surtout, elles n'ont pas du tout le même poids : si la quatrième est fausse, il n'y a pas de projet, quelle que soit la qualité des cinq autres.

Voilà tout le déplacement. Vous ne cherchez pas à savoir si votre idée est bonne. Vous cherchez à savoir laquelle de vos hypothèses vous tue, et vous allez la regarder en face en premier.

Les trois familles d'hypothèses

Un découpage classique et utile, parce qu'il permet de vérifier qu'on n'a pas oublié un pan entier du problème.

Désirabilité : est-ce que quelqu'un en veut ?

Le problème existe-t-il vraiment, pour qui, à quelle fréquence, et à quel point fait-il mal ? C'est la famille qui contient presque toujours l'hypothèse la plus dangereuse, et c'est celle que l'on teste en dernier parce qu'elle demande de sortir parler à des gens.

Faisabilité : est-ce que vous savez le faire ?

Compétences, technique, accès aux données, contraintes réglementaires, dépendance à un fournisseur ou à une plateforme. Les profils techniques sur-testent cette famille, parce que c'est la seule qu'ils peuvent explorer seuls devant leur écran.

Viabilité : est-ce que ça tient économiquement ?

Prix acceptable, coût d'acquisition d'un client, marge, durée de vie d'un abonné, taille du marché atteignable. C'est la famille la plus souvent traitée à la louche, avec des chiffres posés pour remplir un tableau plutôt que pour éclairer une décision.

Écrire une hypothèse correctement

Une hypothèse exploitable a trois propriétés. Elle est précise, elle est falsifiable (on peut imaginer un résultat qui la contredit), et elle porte sur un seul élément.

Comparez :

• « Les indépendants ont besoin d'aide sur leurs factures. » Trop vague. Aucun résultat ne pourrait la contredire.
• « Au moins la moitié des indépendants facturant plus de 30 000 € par an ont eu au moins un impayé de plus de 60 jours au cours des douze derniers mois. » Précise, falsifiable, testable.

Le second format est inconfortable, parce qu'il vous engage sur un chiffre. C'est exactement pour ça qu'il est utile : il rend le résultat du test lisible, au lieu de vous laisser conclure « globalement ça a plutôt confirmé ».

Une règle pratique : écrivez votre hypothèse, puis écrivez la phrase qui la contredirait. Si vous n'arrivez pas à formuler cette seconde phrase, c'est que votre hypothèse n'en est pas une.

La matrice qui décide de l'ordre

Vous avez maintenant dix à quinze hypothèses. Vous ne pouvez pas toutes les tester, et surtout pas en même temps. Le critère de priorisation tient en deux axes.

Axe 1 : le coût de l'erreur. Si cette hypothèse est fausse et que je m'en aperçois dans un an, qu'est-ce que ça me coûte ? Une hypothèse dont la fausseté annule le projet est en haut. Une hypothèse dont la fausseté demande un ajustement est en bas.

Axe 2 : le coût du test. Combien de temps et d'argent pour obtenir une réponse crédible ? Un après-midi de recherche documentaire, une semaine d'entretiens, un mois de développement ?

L'ordre de traitement en découle :

1. Coût de l'erreur élevé, coût du test faible. Faites-le maintenant, aujourd'hui si possible. C'est le quadrant qui contient presque toujours la question du besoin réel et celle de la taille du marché.
2. Coût de l'erreur élevé, coût du test élevé. Le vrai travail. Cherchez d'abord un test partiel et moins cher qui réduit l'incertitude, même imparfaitement.
3. Coût de l'erreur faible, coût du test faible. À traiter en remplissage, quand vous attendez des réponses ailleurs.
4. Coût de l'erreur faible, coût du test élevé. Ne testez pas. Décidez arbitrairement et passez à autre chose.

Ce classement produit un effet secondaire utile : il rend visible le fait que la plupart des porteurs de projet commencent par le quadrant 4 (peaufiner le nom, la charte, le choix technique) parce qu'il est confortable, et repoussent le quadrant 1 parce qu'il fait peur.

Définir le seuil avant de tester

Voici l'erreur qui ruine la moitié des tests menés sérieusement par ailleurs : ne pas décider à l'avance ce qui compte comme réussite.

Si vous lancez une page d'inscription et que vous vous dites « on verra bien ce que ça donne », vous obtiendrez un chiffre que vous interpréterez favorablement, parce que vous voulez que le projet continue. Douze inscrits ? « C'est un bon début pour une page sans budget. » Trois inscrits ? « L'audience n'était pas la bonne. »

La discipline : avant de lancer, écrivez la phrase « je considérerai cette hypothèse comme validée si X, et invalidée si Y ». Puis rangez cette phrase quelque part où vous la relirez. C'est trivial et presque personne ne le fait.

Ce que vous obtenez au bout

Pas une réponse binaire, et c'est normal. Vous obtenez une carte : quelles hypothèses sont désormais appuyées par des éléments concrets, lesquelles ont été invalidées et vous obligent à ajuster, et lesquelles restent ouvertes.

Cette carte a trois usages immédiats. Elle vous dit quoi tester ensuite. Elle vous permet de décider en connaissance de cause de continuer, d'ajuster ou d'arrêter. Et elle constitue le seul document réellement convaincant face à un partenaire ou un financeur, parce qu'il montre non pas ce que vous croyez, mais ce que vous avez vérifié.

C'est aussi à ce stade que le chiffrage devient possible. Tant que vos hypothèses de marché sont dans votre tête, aucune estimation ne vaut rien. Une fois qu'elles sont écrites et documentées, elles deviennent des paramètres, et un paramètre, ça se calcule.

En résumé

Arrêtez de chercher à savoir si votre idée est bonne. Écrivez les dix à quinze hypothèses sur lesquelles elle repose, réparties entre désirabilité, faisabilité et viabilité. Classez-les selon ce que coûterait l'erreur et ce que coûte le test. Traitez en premier celles qui sont à la fois dangereuses et peu coûteuses à vérifier.

Et pour chaque test, écrivez votre seuil de réussite avant de le lancer. C'est la seule protection contre le biais qui vous fera lire n'importe quel résultat comme un encouragement. Les autres guides sont sur le blog Predictis →

Sources

• CB Insights : les principales raisons d'échec des startups, analyse de post-mortem
• Bpifrance Création : réaliser son étude de marché
• Strategyzer : le Value Proposition Canvas (désirabilité, faisabilité, viabilité)