Pourquoi la plupart des MVP ne prouvent rien
Le MVP était censé être l'expérience la plus rapide possible pour tester le risque le plus grand. En vingt ans, il est devenu son contraire : une version allégée du produit final, livrée avec fierté, et présentée comme une validation. Le problème n'est pas la taille du produit, c'est la question posée. Si vous n'avez pas écrit, avant de construire, l'hypothèse précise que le MVP doit confirmer et la mesure qui pourrait la réfuter, vous ne faites pas une expérience : vous faites une démonstration. Et une démonstration ne prouve rien — elle montre seulement que votre équipe sait coder. Voici où se joue la différence, et comment construire un MVP qui, lui, prouve quelque chose.
By John-Guy Park · · 12 min de lecture
Key facts
- Le MVP n'a jamais été conçu pour être la version allégée du produit final : Eric Ries le définit comme la version qui permet « un tour complet de la boucle construire-mesurer-apprendre » et de tester les hypothèses les plus risquées avec le minimum d'effort — sa fonction est d'apprendre, pas de livrer (donnée tierce : The Lean Startup, Eric Ries).
- Le réflexe qui tue : écrire la liste des fonctionnalités avant d'écrire l'hypothèse. Un MVP sans question falsifiable explicite est une démonstration technique, et le critère qui le « valide » — quelques inscriptions, des retours polis — ne peut pas le réfuter. Une chose que rien ne peut montrer fausse ne prouve rien.
- Ce que mesure mal le fondateur non entraîné, c'est la différence entre « les gens utilisent » et « les gens adhèrent ». Le test des 40 % de Sean Ellis : plus de 40 % d'utilisateurs déclarant qu'ils seraient « très déçus » de ne plus pouvoir utiliser le produit est un signal fort de product-market fit ; les sociétés en dessous peinent à croître, celles au-dessus croissent presque toujours (donnée tierce : Sean Ellis / Product-Market Fit Survey).
- Le volumètre n'est pas la preuve : en analysant 615 produits SaaS, Pendo trouve que 80 % des fonctionnalités sont rarement ou jamais utilisées, et qu'environ 12 % d'entre elles génèrent l'essentiel de l'usage quotidien (donnée tierce : Pendo, Feature Adoption Report). Un MVP qui « tourne » et attire des curieux peut donc n'avoir prouvé aucune utilité.
- La cause n° 1 d'échec des startups n'est pas technique : en analysant plus de 100 post-mortem, CB Insights trouve que l'absence de besoin marché est citée dans 42 % des cas — un produit construit pour un besoin qui n'existait pas (donnée tierce : CB Insights). Un bon MVP sert précisément à trancher cette question avant d'y dépenser le budget.
- Le vrai critère d'un MVP réussi n'est pas un produit qui reste en ligne, c'est une décision éclairée : on a départagé l'hypothèse, par oui ou par non, avec un signal qui ne pouvait pas être biaisé par la politesse. C'est ce que je vérifie avant d'accepter un périmètre, et c'est ce qui manque à la majorité des MVP que je vois passer.
Le MVP a été inventé pour apprendre, pas pour livrer
Revenons à la source, parce que le glissement est instructif. Eric Ries n'a pas inventé le MVP comme un produit minimal, mais comme une boucle d'apprentissage : il le définit comme la version d'un produit qui permet « un tour complet de la boucle construire-mesurer-apprendre » — l'unité de progrès d'une startup n'est pas le code livré, c'est l'apprentissage validé. La méthodologie (décrite sur theleanstartup.com) pose que l'activité fondamentale d'une startup est de transformer des idées en produits, de mesurer la réponse des clients, puis d'apprendre à pivoter ou persévérer (donnée tierce : The Lean Startup, Eric Ries).
Ce renversement a une conséquence immédiate : la bonne question n'est pas « quelles fonctionnalités mettre dans la V1 ? », mais « quelle est l'hypothèse la plus risquée de mon plan, et quelle est la plus petite chose qui peut la tester ? ». Chez nous, avant de parler d'une seule ligne de code, on écrit l'hypothèse, puis le signal qui peut la réfuter, puis le seuil à partir duquel on décide de continuer ou d'arrêter. Ce n'est pas du formalisme : c'est ce qui rend le MVP une expérience au lieu d'une démonstration.
Et c'est précisément ce qui a disparu dans l'usage courant. Le MVP est devenu un format de livraison : un périmètre réduit, livré en quelques semaines, présenté à la démo comme une étape. Rien dans ce format n'empêche qu'il soit en même temps une expérience, mais rien ne l'y oblige — et sans la contrainte de l'hypothèse, l'équipe construit naturellement « la plus petite version du grand produit », pas « l'expérience ciblée sur le risque n° 1 ». La différence se joue là, avant la première ligne de code.
Si rien ne peut vous faire dire non, votre MVP ne prouve rien
Le test le plus utile que je connaisse pour juger un MVP avant la construction est d'une simplicité déconcertante : demandez qu'on vous montre la phrase exacte qui, écrite sur le tableau, vous ferait considérer l'expérience comme un échec. Pas « on n'aura pas assez d'inscrits » — un chiffre, une durée, une condition précise. Si votre équipe ne sait pas écrire cette phrase, vous n'avez pas de MVP, vous avez un projet avec un périmètre réduit.
Une hypothèse est scientifique au sens où elle est falsifiable : il existe un résultat d'expérience qui pourrait la montrer fausse. « Les PME françaises ont besoin d'un outil de suivi de trésorerie » n'est pas falsifiable — qui pourrait prouver le contraire ? « Si la pré-inscription des candidats dépasse 30 par semaine sur deux mois pour un coût d'acquisition sous 40 €, alors les PME adhèrent » l'est : un résultat sous le seuil montre que l'hypothèse est fausse ou mal formulée, et c'est une information précieuse. Le problème des MVP que je vois échouer n'est presque jamais qu'ils étaient trop petits ; c'est qu'ils ne pouvaient pas dire non.
Le refus de s'engager sur un signal réfutable a des causes que je reconnais dans presque tous les cas : la peur de devoir arrêter un projet auquel on tient, la croyance que « plus de fonctionnalités = plus de preuve » (c'est l'inverse), et la confusion entre validation technique et validation de marché. Or la politesse des retours est le pire juge qui soit : personne ne vous dira en réunion que votre produit n'intéresse personne. Il faut un indicateur comportemental, pas déclaratif — et c'est exactement la limite du MVP qui « a été bien reçu ».
Utiliser n'est pas adhérer : le piège du volumètre
Le deuxième glissement consiste à confondre le trafic et l'engagement. Un MVP qui attire des visiteurs, des inscriptions, voire des retours enthousiastes, est-il validé ? Pas forcément — et les données agrégées sur des centaines de produits le montrent sans ambiguïté. Pendo a analysé l'usage réel de 615 produits SaaS : environ 80 % des fonctionnalités sont rarement ou jamais utilisées, et une minorité d'entre elles — environ 12 % — génère l'essentiel de l'usage quotidien (donnée tierce : Pendo, Feature Adoption Report). En clair : un produit peut « marcher », être installé, examiné, et pourtant ne servir vraiment à presque personne.
Ce chiffre illustre une distinction que les fondateurs non techniques ont du mal à tenir : entre un produit qu'on utilise parce qu'il est là et un produit dont on aurait du mal à se passer. C'est exactement le point du test des 40 % de Sean Ellis, l'homme qui a porté la croissance de Dropbox et d'Eventbrite : demander aux utilisateurs « comment réagiriez-vous si vous ne pouviez plus utiliser le produit ? », et mesurer la part qui répond « très déçu ». Plus de 40 % est un signal fort de product-market fit ; les sociétés en dessous peinent presque toujours à croître, celles au-dessus y arrivent presque toujours (donnée tierce : Sean Ellis, Product-Market Fit Survey — pmfsurvey.com). La question n'est pas « est-ce que vous l'utilisez ? » mais « est-ce que son absence vous coûterait quoi que ce soit ? ».
Attention à la facilité du 40 % : le seuil est robuste quand l'échantillon est qualifié (des utilisateurs qui ont réellement éprouvé le cœur du produit, pas des curieux). Et un score au-dessus de 40 % ne garantit pas la viabilité — il indique un besoin ressenti, pas forcément un modèle qui tient (analyse tierce : Kromatic, sur les faux positifs du test 40 %). Mais comme signal de départ, c'est infiniment plus parlant que « 1 200 personnes se sont inscrites à la newsletter », qui ne dira jamais si le produit résout un problème réel.
Le MVP n'a pas à résoudre un problème qui n'existe pas encore
La statistique qui devrait décorer toutes les salles de cadrage : en analysant plus d'une centaine de post-mortem de startups, CB Insights trouve que la cause la plus fréquemment citée d'échec, dans 42 % des cas, est l'absence de besoin marché (donnée tierce : CB Insights, The Top 20 Reasons Startups Fail). Pas un problème d'exécution, pas un manque de financement : un produit correctement construit pour un besoin qui n'existait pas. Le MVP, quand il est bien conçu, sert précisément à trancher cette unique question avant d'y consacrer des mois et des dizaines de milliers d'euros.
Il y a là une vérité inconfortable : construire vite un petit produit pour une idée non vérifiée ne réduit pas le risque principal, il le déplace. On réduit un risque technique (peut-on le construire ?) qui est rarement le vrai risque, au prix d'un calendrier qui retarde le seul test qui compte (quelqu'un a-t-il vraiment besoin de ça ?). Sur un prototype Data ou IA, je vois exactement la même dérive : l'équipe passe des semaines à rendre un traitement impeccable, alors que la question qui décide de tout est celle des données et du besoin, pas celle du modèle.
Le MVP le plus honnête que je connaisse commence donc par une décision explicite du risque n° 1 : pour telle idée, quel est le doute qui, s'il est levé négativement, rend le projet sans intérêt ? C'est sur ce doute que porte l'expérience. Le périmètre est ensuite dérivé de la question, jamais l'inverse. Quand un client arrive chez Workfutur avec « une app de X », ma première réponse n'est pas un devis, c'est une question : qu'est-ce que ce MVP doit vous apprendre, et quel résultat vous ferait dire non ? Si la réponse est « je ne sais pas », le cadrage — pas le développement — devient la première étape, et c'est justement ce que permet l'audit et cadrage avant tout engagement.
Comment construire un MVP qui prouve quelque chose : cinq règles
Je résume en cinq règles ce que j'applique dans les missions de construction, et qui transforme un livrable en expérience qui décide.
Un, écrivez l'hypothèse par écrit avant le périmètre. Une phrase du type « Si [l'utilisateur cible] fait [action] dans [délai] alors il adhère à [promesse] ». Si votre équipe ne peut pas l'écrire, le MVP est prématuré, quel que soit son coup.
Deux, définissez le signal réfutable et le seuil avant de coder. Quelle mesure (taux de rétention à 14 jours, part de « très déçu », ventes réelles) et quel chiffre départage « oui » et « non » ? C'est la clause qui manque à 80 % des MVP que je vois, et c'est elle qui transforme le lancement en décision.
Trois, mesurez un comportement, pas une opinion. Les retours en réunion, les réponses à un questionnaire « c'était génial » ne prouvent rien : elles coûtent peu à donner. Un signal comportemental (est-ce qu'ils reviennent, est-ce qu'ils paient, est-ce qu'ils invoquent le produit spontanément) est le seul qui ne soit pas biaisé par la politesse. Le test des 40 % est un bon départ ; la rétention réelle et les premières ventes sont la confirmation.
Quatre, dérivez le périmètre du risque, pas du produit final. Ne demandez pas « quelle est la plus petite version complète ? » mais « quelle est la plus petite chose qui teste le risque n° 1 ? ». Ces deux questions mènent à des MVP très différents — et la première reproduit souvent la confiance excessive que le marché n'a pas encore méritée.
Cinq, décidez d'une date de décision, pas seulement d'une date de livraison. Le MVP n'est pas « fini » quand il est en ligne ; il est fini quand il a produit son verdict. Planifiez la revue d'hypothèse comme un jalon aussi intangible que la mise en production — c'est elle qui vous dira de continuer, de pivoter, ou d'arrêter avant d'avoir dépensé ce que vous seriez tenté de « rattraper ».
Et pour finir, la part que je ne contourne pas : un MVP honnête peut très bien montrer que l'hypothèse est fausse, et c'est un excellent résultat. Chez Workfutur, on considère que soixante jours et un budget mesuré bien dépensés pour éviter de construire un produit dont personne ne veut sont un succès, pas un échec. C'est toute la logique d'un calendrier de MVP à soixante jours : obtenir la réponse qui décide avant d'avoir dépensé le budget qui vous aurait permis de réagir.
MVP-démonstration vs MVP-expérience : ce qui change
| MVP-démonstration | MVP-expérience | |
|---|---|---|
| Question posée | « Peut-on le construire ? » (capacité technique) | « Quelqu'un a-t-il réellement besoin de ceci ? » (hypothèse falsifiable) |
| Critère de validation | En ligne, inscriptions, « c'était bien reçu » (déclaratif, biaisé par la politesse) | Signal comportemental réfutable : rétention à 14 j, part de « très déçu », premières ventes (seuil écrit avant de coder) |
| Ce qu'il peut montrer faux | Rien — ne peut pas dire non | L'hypothèse, explicitement : un résultat sous le seuil arrête ou fait pivoter |
| Objet construit | La plus petite version complète du produit final | La plus petite chose qui teste le risque n° 1 |
| Fin du projet | Livraison et démo | Verdict sur l'hypothèse → continuer, pivoter ou arrêter |
| Risque de l'approche | Construire un produit dont personne ne veut (cause n° 1 d'échec, 42 % — CB Insights) | Risque maîtrisé : la décision précède la dépense lourde |
Sources : The Lean Startup (boucle construire-mesurer-apprendre, MVP comme expérience) ; Sean Ellis, Product-Market Fit Survey (test 40 %) ; Pendo, Feature Adoption Report (80 % de fonctionnalités rarement jamais utilisées) ; CB Insights (42 % d'échecs pour absence de besoin marché) ; Kromatic (limites et faux positifs du seuil 40 %). Aucune donnée inventée : chaque chiffre renvoie aux sources en bas de page.
Frequently asked questions
Pourquoi la plupart des MVP ne prouvent-ils rien ?
Parce qu'ils répondent à une question mal posée. Le MVP a été conçu comme une expérience qui teste l'hypothèse la plus risquée avec un minimum d'effort (Eric Ries, boucle construire-mesurer-apprendre). L'usage courant en a fait une version allégée du produit final, livrée comme une démonstration. Sans hypothèse falsifiable écrite avant de coder — et sans signal réfutable avec un seuil — le MVP ne peut pas dire non, donc il ne prouve rien : il montre seulement que le code fonctionne et que quelques curieux l'ont regardé.
Quelle différence entre « les gens utilisent » et « les gens adhèrent » ?
L'usage ne dit pas que le produit est indispensable, il dit qu'il est là. Pendo, en analysant 615 produits SaaS, trouve qu'environ 80 % des fonctionnalités sont rarement ou jamais utilisées et qu'une minorité (12 %) génère l'essentiel de l'usage (Feature Adoption Report). Le test de Sean Ellis mesure l'adhésion : la part d'utilisateurs qui seraient « très déçus » de perdre le produit. Plus de 40 % est un signal fort de product-market fit, en dessous les sociétés peinent à croître. C'est la différence entre un outil qu'on ouvre et un outil qui manque quand il disparaît.
Que faut-il écrire avant de construire un MVP ?
Trois choses, dans l'ordre : (1) l'hypothèse en une phrase du type « si [cible] fait [action], alors elle adhère à [promesse] » ; (2) le signal réfutable et son seuil — quelle mesure et quel chiffre départageraient « oui » et « non » (rétention à 14 jours, part de « très déçu », ventes) ; (3) la date de décision, le moment où on juge le verdict. Sans ces trois éléments, le projet a un périmètre réduit mais pas d'expérience.
Le test des 40 % de Sean Ellis est-il fiable ?
Le seuil de 40 % de « très déçu » est un signal robuste quand l'échantillon est qualifié : des utilisateurs qui ont réellement éprouvé un usage récent du cœur du produit, pas des inscriptions passives. Un score élevé indique un besoin ressenti — pas automatiquement un modèle d'affaires viable. Et un score bas est un signal très fiable du manque de product-market fit. L'analyse de Kromatic note d'ailleurs que le test peut donner des faux positifs en début de vie d'un produit, quand les répondants réagissent à la promesse plutôt qu'au produit réel (analyse tierce : Kromatic). Il faut donc le combiner à des mesures comportementales.
Quel est le vrai critère de réussite d'un MVP ?
Ce n'est pas qu'il reste en ligne, ni qu'il ait attiré des inscriptions : c'est qu'il ait produit une décision. Le MVP a réussi quand il a départagé son hypothèse — continuer, pivoter ou arrêter — sur la base d'un signal comportemental qui ne pouvait pas être biaisé par la politesse. La cause n° 1 d'échec des startups est l'absence de besoin marché (42 % des post-mortem, CB Insights) ; un MVP bien conçu sert à trancher cette question avant d'y dépenser le budget. Démontrer qu'une hypothèse est fausse tôt est un succès, pas un échec.
Combien de temps et combien coûte un MVP qui prouve quelque chose ?
Un MVP-expérience bien cadré se construit en soixante jours, comme un MVP-démonstration — la différence est dans la question posée, pas dans le volume de code. Chez Workfutur, le forfait démarre à 29 000 € pour un périmètre de deux ou trois parcours et au plus deux intégrations tierces, et la propriété du code vous est transférée dès le premier euro. Si le périmètre ou l'hypothèse est encore incertain, un audit et cadrage à 4 900 € permet de fixer, avant tout engagement, l'hypothèse et le signal qui décideront de la suite. La grille complète est publiée sur la page des tarifs, sans formulaire.
Sources cited
- The Lean Startup / Eric Ries — méthodologie et MVP (construire-mesurer-apprendre) — donnée tierce · le MVP est défini comme la version qui permet un tour complet de la boucle construire-mesurer-apprendre pour tester une hypothèse ; une startup est une institution conçue pour créer sous incertitude extrême ; l'activité est de transformer des idées en produits, mesurer la réponse, apprendre à pivoter ou persévérer ; les efforts non nécessaires à l'apprentissage doivent être éliminés
- Sean Ellis — Product/Market Fit Survey (test des 40 %) — donnée tierce · question « comment réagiriez-vous si vous ne pouviez plus utiliser le produit ? » ; seuil de 40 % de « très déçu » comme signal de product-market fit ; les sociétés au-dessus croissent presque toujours, celles en dessous peinent ; à appliquer à un échantillon qualifié (usage réel du cœur du produit)
- Pendo — Feature Adoption Report (analyse de 615 produits SaaS) — donnée tierce · Pendo analyse l'usage anonymisé de 615 produits SaaS sur trois mois : environ 80 % des fonctionnalités sont rarement ou jamais utilisées, 56 % jamais utilisées, et environ 12 % des fonctionnalités génèrent 80 % de l'usage quotidien ; rapport Pendo 2019 ; comparé au CHAOS report du Standish Group (45 % de fonctionnalités jamais utilisées)
- CB Insights — The Top 20 Reasons Startups Fail — donnée tierce · analyse de plus de 100 post-mortem de startups : l'absence de besoin marché est la cause la plus fréquemment citée, dans 42 % des cas ; un produit correctement construit pour un besoin qui n'existait pas — la justification centrale d'un MVP qui teste la demande
- Kromatic — Product Market Fit 40 % test : limites et faux positifs — analyse tierce · le seuil de 40 % est nécessaire mais pas suffisant : les produits jeunes peuvent obtenir un faux positif quand les répondants réagissent à la promesse du produit plutôt qu'au produit réel ; un score bas est un signal très fiable de l'absence de product-market fit
Got a project to turn into a product?
Book 30 minutes, or describe your idea in a few lines. We reply within 5 business days with free scoping — scope, risks, timeline and engagement pricing.