La plupart des MVP n’en sont pas

Le sigle a été étiré au point de désigner n’importe quoi qu’un fondateur livre dans la précipitation. La version qui survit est avant tout un exercice de marketing. Celle qui aide est un pari falsifiable — et presque personne ne l’écrit avant de commencer.

Il y a quelques mois, un fondateur nous a montré son MVP. C’était une application web fonctionnelle, construite en sept semaines par un freelance trouvé sur Workana. Elle avait une authentification, un dashboard, trois flux principaux, un panneau d’administration et une intégration Stripe. Elle lui avait coûté environ 7 000 dollars. Il en était fier, et nous avait sollicités parce qu’il voulait de l’aide pour « la scaler ». Nous lui avons posé une question : qu’est-ce que ce MVP t’a appris que tu ne savais pas déjà ?

Il a marqué une pause. Il a dit que les clients aimaient. Puis il a dit que trois s’étaient inscrits. Puis il a dit que deux des trois étaient des amis. Et nous sommes restés silencieux une minute, parce que nous étions arrivés à la même conclusion à peu près en même temps. Le MVP n’avait rien validé. Il avait construit quelque chose. Ce sont deux choses différentes.

Eric Ries a forgé l’expression « minimum viable product » en 2008. Elle apparaît dans The Lean Startup avec une définition précise — la version d’un nouveau produit qui permet à une équipe de collecter le maximum d’apprentissage validé sur les clients avec le moins d’effort possible. Lisez-le deux fois. L’unité de sortie n’est pas un produit. L’unité de sortie est l’apprentissage. Tout le reste est un effet secondaire.

Presque personne, en 2026, n’utilise le terme comme Ries l’entendait. Le sigle a été étiré au point de désigner tout ce qu’un fondateur livre dans la précipitation, et la version qui gagne sur LinkedIn est avant tout un exercice de marketing — une application fonctionnelle, un tweet de lancement, une capture de trois inscriptions et un post sur le « product-market fit validé ». Ce n’est pas de la validation. C’est du théâtre habillé du vocabulaire de la validation.

La corruption est structurelle

La raison pour laquelle le MVP a cessé de fonctionner comme dispositif d’apprentissage n’est pas que les fondateurs sont devenus paresseux. C’est que le coût de construire l’artefact a chuté plus vite que le coût de comprendre ce que cet artefact devait tester. En 2008, construire une application web fonctionnelle de zéro demandait six ingénieurs et quatre mois. La friction obligeait le fondateur à réfléchir longuement à ce qu’il fallait construire, parce que construire quoi que ce soit était cher. En 2018, avec le no-code et les freelances bon marché, le coût s’est effondré. En 2024, avec le développement assisté par l’IA, il s’est effondré encore.

Ce qui n’a pas chuté — ce qui ne pouvait pas chuter — c’est le travail cognitif consistant à décider quoi tester. Définir l’affirmation falsifiable, concevoir le test qui la falsifierait réellement, choisir la métrique, choisir la population, choisir le seuil : ce travail a la même difficulté en 2026 qu’en 2008. Ce n’est pas un problème d’outil. C’est un problème de pensée.

Il s’est passé quelque chose d’étrange. Le coût de construire est tombé proche de zéro, alors que le coût de décider ce qu’il faut construire est resté constant. Le chemin de moindre résistance est devenu : sauter la réflexion, démarrer la construction. Des fondateurs qui auraient autrefois été contraints à la clarté par l’économie peuvent désormais se passer entièrement de cette étape. Le MVP est devenu une construction, pas un test. Et le vocabulaire est resté — parce que « MVP » sonne toujours comme un signe de discipline, même quand le travail n’en montre aucune.

Le résultat est une catégorie d’artefact que nous appelons le MVP théâtral. Il ressemble à un MVP. Il coûte ce qu’un MVP coûterait. Il sort dans le délai d’un MVP. Mais il n’apprend rien au fondateur qu’il ne savait déjà, parce qu’aucune affirmation n’a été spécifiée avant le démarrage.

Le test qui compte : écrivez le pari d’abord

Le seul changement qui transforme un MVP théâtral en un MVP réel est brutalement simple. Avant la moindre ligne de code, le fondateur écrit une phrase :

« Si, à [date], nous n’avons pas observé [comportement précis] de la part de [population précise], au seuil de [seuil précis], nous avons tort sur [affirmation précise]. »

Cette phrase n’est pas un slogan. C’est un contrat. Elle engage le fondateur sur une affirmation falsifiable et sur une définition de l’échec. Les deux moitiés comptent. Sans l’affirmation, il n’y a rien à tester. Sans définition de l’échec, il n’y a pas d’apprentissage — n’importe quel résultat peut être rationalisé en « prometteur ».

Trois fondateurs avec qui nous avons travaillé l’an dernier ont utilisé une variante de cette phrase avant de cadrer leur première construction. L’un d’eux a écrit : « Si, dans les soixante jours suivant le lancement, moins de 30 % des petites cliniques onboardées se sont connectées au dashboard au moins trois fois dans leur deuxième mois, la thèse du soin asynchrone est fausse et nous devons pivoter. » Soixante jours plus tard, le chiffre était 11 %. Ils n’ont pas livré de v2. Ils sont retournés réinterroger les cliniques, ont découvert que le frein n’était pas l’intérêt pour le soin asynchrone, et ont reconstruit autour d’un flux entièrement différent. Ce MVP a fait exactement ce qu’un MVP est censé faire. Il n’a pas livré un produit à scaler. Il a livré une thèse sur laquelle il fallait arrêter de construire.

Les deux autres fondateurs ont refusé d’écrire la phrase. Nous avons demandé pourquoi. Ils ont répondu qu’ils n’arrivaient pas à choisir un chiffre, parce qu’ils ne savaient pas quel chiffre était raisonnable. Nous avons fait remarquer que ne pas savoir quel chiffre est raisonnable est précisément le problème que le MVP est censé résoudre. Si on ne peut pas articuler à quoi ressemble le succès avant de commencer, on ne peut pas reconnaître le succès ou l’échec en finissant. On ne peut que rationaliser le résultat obtenu.

Pourquoi la phrase est la partie difficile

La raison pour laquelle la plupart des fondateurs sautent la phrase, c’est qu’elle les force à affronter les parties du business qu’ils ont laissées floues. Pour écrire une affirmation falsifiable, il faut connaître le client de manière assez précise pour le nommer. Connaître le comportement de manière assez précise pour l’instrumenter. Connaître le seuil de manière assez précise pour le défendre. Aucune de ces choses n’est une compétence technique. Toutes sont une discipline commerciale.

C’est pour cela que le problème du MVP est rarement un problème d’ingénierie. C’est un problème de clarté commerciale déguisé en problème de construction. Le fondateur recrute un développeur parce qu’un développeur, ça se recrute. Le travail de clarté n’a pas de fournisseur évident. Alors le fondateur achète ce qu’il peut acheter, livre ce qu’il peut livrer, et la question d’origine — qu’est-ce que nous testons ? — se perd discrètement en chemin.

Un bon partner d’ingénierie est l’avant-dernière ligne de défense contre cela. Un bon partner d’ingénierie refuse de coder tant que le fondateur n’a pas répondu aux quatre questions : quelle affirmation testons-nous, quel comportement la falsifierait, quelle est la population, quel est le seuil ? La dernière ligne de défense, c’est le fondateur lui-même. Si le partner ne pousse pas et que le fondateur n’écrit pas la phrase, ce qui sort en bout de course est, au mieux, une application fonctionnelle, et le fondateur découvre, un an plus tard, qu’il a dépensé quarante mille dollars à n’apprendre rien.

Ce qu’un MVP n’est pas

Le but de tout cela n’est pas d’être précieux sur le terme. C’est de signaler une erreur de catégorie qui coûte du runway. Donc, pour lever toute ambiguïté :

Un MVP n’est pas un petit produit. Il peut être petit ou grand ; ce qui compte, c’est s’il est conçu pour tester quelque chose. Un MVP n’est pas un lancement. Lancer est une activité distincte, parfois partie du test, parfois non. Un MVP n’est pas « la chose qu’on livre avant de construire le vrai produit ». Si ce que vous livrez ne change pas une décision réelle en fonction de son résultat, l’appeler MVP, c’est juste emprunter la dignité du terme original.

Ce n’est pas non plus le maximum que l’on peut construire en trois mois. La plupart des fondateurs, quand on leur demande de réduire le scope, réduisent sur le mauvais axe — ils coupent la finition et gardent la largeur. Un vrai MVP coupe la largeur, fort, et garde assez de finition pour que la friction d’un client réel soit observable. Huit features bâclées vous apprennent moins que deux features bien faites, parce que la friction du client est la variable, pas la surface.

La version du terme qu’il faudrait garder

Nous avons envisagé de jeter le sigle. Il est tellement corrompu que le défendre est épuisant. Mais il y a un usage qui mérite encore sa place, et la discipline de le distinguer vaut plus que la peine d’inventer un autre mot.

La version qui mérite de rester, c’est le plus petit artefact qui, placé devant un vrai client, produit un oui ou un non sur l’hypothèse restante la plus coûteuse. C’est le test. Trois choses doivent être vraies pour que l’artefact qualifie. Il doit être assez petit pour que la construction n’écrase pas l’apprentissage. Il doit être placé devant un vrai client — pas un ami, pas un designer, pas l’équipe. Et il doit produire une réponse — oui ou non — qui change ce que le fondateur construit ensuite.

Si votre MVP ne change pas ce que vous construisez ensuite, ce n’en est pas un. Quoi que ce soit, ce n’est pas ce dont parlait Ries. Et la question qui vaut la peine d’être posée, avant d’écrire le spec, est la même que celle à laquelle notre ami à São Paulo n’a pas su répondre : qu’est-ce que cela m’apprendrait que je ne sache déjà ?

Si vous ne pouvez pas le dire, ne construisez pas. Le MVP le moins cher est celui que vous ne livrez pas — parce qu’écrire la phrase, c’est ce que vous deviez réellement à l’entreprise.