Le MVP est devenu un mensonge confortable.

Ces peut être les trois lettres qui ont tué plus de projets qu’elles n’en ont sauvé.

Pas parce que le concept est mauvais à la base, mais parce qu’il est devenu ce genre de mot qu’on pose sur la table en réunion et qui donne l’illusion que tout le monde parle de la même chose. En réalité, personne ne parle de la même chose. Le client entend “version légère qui marche vraiment”. L’agence entend “périmètre qu’on a réussi à caser dans le budget”. L’équipe de développement entend “base propre sur laquelle on va construire la suite”. Trois lectures, un seul mot, et des mois de friction garantis dès le démarrage du projet. C’est dans ce flou entretenu que la plupart des projets commencent à mourir, bien avant la première ligne de code.

Le vrai problème n’est pas la méthode, c’est l’intention

Pendant longtemps, le secteur a livré des MVPs solides : architecture propre, code maintenable, équipes pluridisciplinaires bien rôdées. L’idée centrale était de poser des fondations sérieuses pour que le produit puisse grandir sur la durée. Ce modèle avait une cohérence interne réelle.

Le problème, c’est qu’il optimisait pour le mauvais objectif. On construisait pour durer, alors qu’un MVP devrait avant tout construire pour apprendre. Ce n’est pas la même intention, et cela ne peut pas être la même façon de travailler. Le résultat concret : des projets qui s’étiraient sur quatre mois, des budgets conséquents, et au bout du compte un livrable techniquement correct mais trop lourd pour pivoter, pas assez abouti pour passer à l’échelle.

La question n’est donc pas “comment faire de meilleurs MVPs”. Elle est plus radicale : à partir de quand ça n’a plus de sens de l’appeler MVP ? Ma réponse tient en deux chiffres : 15 jours, plusieurs irerations tres courtes et surtout un seul profil adapté a la problematique. Au-delà, on fait autre chose, et on devrait l’appeler autrement. Ce que ce cadre produit n’est plus un MVP au sens classique, mais un POC fonctionnel : quelque chose qui tourne réellement, qu’on peut mettre entre les mains de vrais utilisateurs, et qui permet de décider avec de la matière concrète plutôt qu’avec des maquettes et des projections.

L’IA, ou le goût retrouvé de construire

Je pourrais rester prudent sur ce sujet et me contenter de dire que “l’IA est un accélérateur parmi d’autres”. Ce serait honnête, mais franchement incomplet.

L’IA m’a redonné le goût de coder. Concrètement. Après des années passées à déléguer l’exécution technique pour me concentrer sur le pilotage, j’ai retrouvé le plaisir de construire des choses, vite, avec un feedback immédiat. Le moment révélateur n’était pas professionnel : c’était face à un problème de gestion des inscriptions dans une école dont je suis président d’OGEC. Chaque année, le même rituel : des fichiers Excel qui s’accumulent, des formulaires papier, une friction administrative inutile. La solution évidente aurait été de chercher un outil SaaS adapté. Au lieu de ça, j’ai codé Eddis, une application dédiée, en moins de 15 jours, avec une demi-journée de mise en place initiale. Quelque chose d’exploitable, de maintenable, taillé exactement pour le besoin, sans compromis imposé par un outil générique.

Ce qui a changé avec l’IA, c’est précisément ce seuil de démarrage. La barrière qui rendait un projet personnel trop coûteux en temps et en énergie pour être lancé s’est effondrée. Le “je vais coder quelque chose” est devenu plus rapide et plus pertinent que le “je vais chercher un outil qui fait à peu près ça”. C’est un renversement fondamental dans la façon d’aborder un problème technique, et il touche aussi bien les profils non-développeurs que les équipes produit aguerries.

Dans le modèle POC à 15 jours, l’IA n’est pas un gadget ou un argument commercial. C’est ce qui rend la contrainte tenable. Un boilerplate solide, des agents structurés et testés en amont, des méthodes documentées : une grande partie de l’exécution répétitive passe en vitesse supérieure, ce qui concentre le temps humain sur les décisions qui ne peuvent pas être déléguées. La stack se pose en quelques heures. Les fonctionnalités critiques s’implémentent en cycles courts. Ce qui prenait trois semaines de setup en prend désormais deux jours.

Le piège symétrique : quand tout devient un projet à lancer

Mais il y a un revers que je vois tous les jours, en moi d’abord. Après avoir réussi Eddis, l’envie de tout reconstruire s’est installée naturellement : remplacer cet outil par une solution dédiée, refaire ce process, améliorer ce système. L’IA rend chaque idée immédiatement “lançable”. Une conversation, quelques prompts bien construits, et on a un prototype qui tourne. C’est vertigineux.

C’est aussi un piège cognitif réel, et des travaux récents sur la charge mentale liée à l’IA commencent à le documenter sérieusement. Le problème n’est pas la fatigue d’exécution, c’est la fatigue de conception. Avoir en permanence des projets en cours de gestation dans un coin de la tête, des idées qu’on pourrait lancer demain parce que la barrière technique a disparu, génère un épuisement mental que le secteur sous-estime encore largement. La facilité de démarrer ne dit strictement rien sur la pertinence de ce qu’on construit. Elle crée une inflation de projets, une accélération d’intentions qui ne sont pas toutes bonnes à suivre jusqu’au bout.

Le vrai travail, celui que l’IA ne fait pas à notre place, c’est de décider ce qui mérite d’être construit et ce qui mérite de rester dans un carnet. La contrainte des 15 jours et des 10k€ n’est donc pas seulement économique. Dans un contexte où tout peut être prototypé très rapidement, elle force une discipline que la facilité technique tend naturellement à éroder. C’est une contrainte de sélection autant que de production.

Ce que ça change dans la composition des équipes

Cette réalité repose une question concrète : qui doit porter un POC, et en fonction de quoi ?

La réponse dépend d’une seule distinction préalable, qu’il faut trancher avant même de parler de budget ou de planning : s’agit-il d’une innovation d’usage ou d’une innovation technique ? Dans le premier cas, le problème est comportemental. Est-ce que les gens vont vraiment utiliser ça ? Est-ce que ça colle à un usage réel ? C’est un PM ou un Product Designer qui doit tenir le gouvernail. Mettre un développeur senior en lead sur ce genre de POC, c’est apporter une réponse technique à une question qui ne l’est pas. Dans le second cas, on cherche à prouver qu’une chose est faisable, performante ou intégrable dans un contexte donné. Le développeur doit être en lead, souvent seul ou presque, sans la friction d’une équipe élargie qui ralentit là où il faut aller vite.

Ce choix se fait à l’avant-vente, pas en début de mission. S’il n’est pas tranché à ce moment-là, on reproduit mécaniquement le schéma d’avant : une équipe standard sur un projet qui n’en a pas besoin, et un MVP qui prend quatre mois pour des raisons d’organisation plutôt que de complexité réelle.

Ce que je n’ai pas encore résolu

Ce modèle est en cours de construction, pas figé, et il serait malhonnête de le présenter autrement.

Ce qui coince encore : des projets qui démarrent dans une logique POC claire et qui dérivent progressivement dès que les premiers retours arrivent. Le “et si on ajoutait juste…” s’installe doucement, et la contrainte de périmètre ne tient que tant qu’elle est défendue activement. Dès qu’elle lâche, on retombe dans les mêmes travers, non pas par incompétence, mais parce que la pression naturelle d’un projet va toujours dans le sens de “faire plus”. C’est vrai en agence, c’est vrai en solo, c’est vrai partout où l’IA a abaissé le coût de l’ajout de fonctionnalités.

Ce qui reste une vraie question ouverte : comment maintenir une discipline de sélection des idées dans un contexte où la barrière technique a quasiment disparu ? Comment décider, collectivement ou individuellement, que telle idée mérite 15 jours de développement et que telle autre mérite de rester dans un carnet, alors que les deux sont techniquement lançables dès demain matin ?

Le mot MVP est peut-être mort dans mon vocabulaire. La question de ce qui le remplace, elle, est bien vivante.