Faut-il encore commencer par un MVP à l'ère de l'IA ? 211 millions de lignes de code montrent un taux de reprise passé de 3,3 % à 7,1 %

Lancez une idée à une IA et huit fois sur dix, la première chose qu’elle vous renvoie est « commençons par une version minimale viable ».

Cela sonne comme un jugement. C’est un souvenir. Le Manifeste Agile date de 2001, The Lean Startup de 2011, et ces deux textes plus les centaines de milliers d’articles, de cours et de rétrospectives qu’ils ont engendrés sont tous dans les données d’entraînement. Si elle recommande l’itération, ce n’est pas parce qu’elle a fait ses propres comptes.

Elle a fait les nôtres. Et ces deux factures sont structurées en sens inverse.

Les quatre prémisses du MVP : trois tiennent encore

L’itération n’est pas une loi de la nature. C’est la solution optimale sous un ensemble précis de contraintes, et cet ensemble ressemble à ceci :

• Écrire du code est lent et cher. Une fonctionnalité passe de « comprise » à « qui tourne » en jours-homme.
• Modifier coûte plus cher qu’écrire. Pour modifier il faut d’abord lire, et lire signifie rentrer à nouveau dans la tête de quelqu’un d’autre — ou dans la sienne d’il y a trois mois.
• Les besoins se précisent en cours de route. L’utilisateur ne sait ce qu’il veut qu’en voyant quelque chose, donc lui montrer tôt rapporte.
• La décisive : il existe un écart de coût considérable entre une implémentation grossière et une implémentation complète.

Cette dernière est le socle économique du MVP. Stocker dans localStorage pour l’instant, sauter les permissions pour l’instant, coder en dur trois valeurs de configuration — les semaines économisées étaient réelles, et les dépenser à valider une hypothèse était vraiment le meilleur arbitrage.

Trois de ces quatre contraintes tiennent encore aujourd’hui. La quatrième a disparu.

localStorage et PostgreSQL : quelques minutes d’écart entre les mains d’une IA

Un fil sur V2EX le dit le plus proprement (t/1216691, intitulé « La pensée MVP a-t-elle cessé de fonctionner à l’ère du codage par IA ? »). Les mots de l’auteur : décrire à Cursor « stocke les données dans localStorage » et décrire « utilise PostgreSQL avec un pool de connexions », c’est quelques minutes d’écart en génération.

Si le coût est le même, pourquoi faire la version simplifiée ?

Cette seule phrase retire la moitié du socle. Ce que vous économisez n’est plus des semaines, c’est des minutes ; tandis que ce que vous contractez en échange n’a pas diminué d’un pouce : une couche de stockage vouée au remplacement, une série d’appels écrits par-dessus, une migration à refaire.

Le grossier n’est plus bon marché. Il est seulement incomplet.

La facture de l’IA : le contexte est le poste principal, pas la tâche

L’autre moitié du socle s’effondre au niveau de la structure de coûts, et cette couche-là se voit moins.

Quand vous lancez une tâche agentique, l’essentiel des tokens d’entrée n’est jamais votre description de tâche. C’est l’invite système, la carte du dépôt, l’historique de conversation, les fichiers lus. La description de tâche y pèse une part négligeable.

Tout ce qui en découle a été mesuré :

• À chaque nouvelle tentative, l’intégralité du contexte est renvoyée. Deux tentatives suffisent à tripler le coût d’une session.
• Une fois le surcoût de contexte compté, le coût réel vaut 3 à 5 fois l’estimation naïve — de 0,27 à 3,25 dollars par PR, et dépasser 20 dollars sur une seule tâche dans un dépôt complexe n’a rien d’exceptionnel.
• L’article arXiv Cheap Code, Costly Judgment (2607.01087) a mesuré que les tâches agentiques consomment 1000 fois plus de tokens qu’un simple échange de code, avec jusqu’à 30 fois de variance entre exécutions répétées de la même tâche.

Mettons maintenant l’itération humaine et l’itération par IA côte à côte.

Un humain qui découpe un travail en trois phases paie à peu près pareil à chaque phase, parce qu’il se souvient de ce qu’il a fait à la précédente. Le contexte est dans sa tête et son rappel est gratuit.

L’IA ne se souvient pas. Elle rachète le contexte à chaque phase.

L’itération est une assurance pour un humain et des frais de friction pour une IA.

GitClear a mesuré la reprise : 3,3 % → 7,1 %

Tout ce qui précède est du raisonnement. Ce qui suit est de la mesure.

GitClear a analysé 211 millions de lignes de code modifié en suivant un indicateur nommé churn : la part de code substantiellement réécrit ou supprimé dans les jours qui suivent sa fusion. Il mesure exactement une chose : ne pas avoir fait juste du premier coup.

Plus du double en deux ans. Les autres indicateurs de la même étude pointent dans la même direction :

• Copier-coller au sein d’un même commit +41 %
• Blocs de code dupliqués +81 %
• Constructions masquant les erreurs +47 %
• Appels de fonctions inter-fichiers, indicateur de réutilisation : −35 %
• Déplacements de lignes liés au refactoring : −70 %

GitClear range la reprise amplifiée par l’IA en trois catégories, et chacune découle directement du fait d’avoir livré un objet à moitié fini :

1. Mauvais endroit — logique et syntaxe correctes, mais placées au mauvais endroit de l’architecture ; quelqu’un les déplace ensuite
2. Construit deux fois — réimplémenter une fonctionnalité qui existait déjà au lieu de la réutiliser
3. Réécrit quelques jours plus tard — fusionné, puis largement modifié pour un cas limite ou une convention enfreinte

Dans le même corpus de recherche, les PR écrites par IA portent en moyenne 10,83 problèmes contre 6,45 pour celles écrites par des humains. Un facteur 1,7.

Le vécu des développeurs colle à ces chiffres. Enquête Stack Overflow 2026 auprès des développeurs :

• 84 % utilisent des outils d’IA
• 45 % déclarent que déboguer du code généré par IA prend plus de temps que de l’écrire soi-même
• 66 % disent que leur plus grande frustration est un résultat « presque juste, mais pas tout à fait »
• Et la confiance dans les sorties d’IA se situe à 3 %

Une autre enquête chiffre à 43 % les modifications de code générées par IA qui nécessitent un débogage en production.

« Presque juste » est l’expression déterminante. Cela signifie que le problème n’apparaît pas au moment où vous recettez, mais après la fusion — ce qui le fait retomber pile sur l’itération suivante. Le tour que vous croyiez avoir économisé est facturé plus loin.

« Bien faire du premier coup » n’est pas « tout faire d’un coup » : granularité de livraison et granularité d’exécution

C’est ici qu’on glisse le plus facilement vers un slogan : arrêtez d’itérer, faites tout d’un coup. C’est faux, et dangereusement faux.

Deux granularités doivent rester distinctes :

• Granularité d’exécution : une modification à la fois, vérifiée avant la suivante. Toujours valable aujourd’hui, et davantage qu’avant — une IA qui touche dix fichiers d’un coup dépasse ce que vous pouvez relire.
• Granularité de livraison : ce que vous remettez à ce tour est-il un produit fini.

« Bien faire du premier coup » parle de la seconde. Ce qui est contraint, c’est le degré d’achèvement, pas le nombre de fonctionnalités.

Le périmètre peut être étroit — une page, un point d’API. Mais la partie que vous vous êtes engagé à faire ce tour-ci doit être complète : de vraies structures de données, pas des espaces réservés ; les quatre états présents, chargement, vide, erreur et succès, pas seulement le chemin idéal ; quelque chose qui tourne vraiment et qu’une personne peut utiliser, pas une capture d’écran.

Le plus gros problème du mot MVP est d’avoir vendu « périmètre étroit » et « fait grossièrement » en lot. Les deux étaient effectivement liés — économiser voulait dire économiser sur les deux. Ils se dissocient désormais : le périmètre doit rester étroit, mais le grossier a cessé d’être économique.

« Le MVP sert à valider une hypothèse, ça n’a rien à voir avec l’IA » — deux des quatre objections tiennent

Les réponses sous ce fil V2EX valent mieux que le message initial. Une par une :

1. « Le cœur du MVP, c’est valider une hypothèse. Cela n’a rien à voir avec le code, ni avec le fait qu’il y ait une IA ou non. »

Ça tient — et cela désigne exactement où est le problème. Le mot MVP a toujours empaqueté deux choses : valider une hypothèse et livrer une implémentation incomplète. Elles étaient inséparables, parce que la seule manière bon marché de valider une hypothèse était de bâcler quelque chose. Elles se sont dissociées. Validez l’hypothèse, bien sûr — vous pouvez désormais le faire avec quelque chose de complet.

2. « Vous ne pourrez jamais connaître d’un coup tous les besoins de vos utilisateurs potentiels. »

Ça tient, et cela n’entre pas en conflit avec « bien faire du premier coup ». Personne ne vous demande de construire toutes les fonctionnalités en une passe. On vous demande que la partie faite cette passe-ci ne reste pas à moitié.

3. « Sur des projets à logique complexe, surtout des systèmes avec des boucles métier et des machines à états, tout faire d’un coup donne une bouillie. »

Vrai problème, mais problème de granularité d’exécution. Une machine à états complexe se construit évidemment pas à pas, avec vérification à chaque étape. Ce n’est pas un argument pour livrer une version qu’on sait déjà devoir réécrire.

4. « Avec l’IA, itérer est ultra rapide et ne coûte presque rien. »

Celle-là ne tient pas. Les deux sections précédentes en sont le contre-exemple : ce qui est devenu rapide, c’est la génération, pas la convergence. Le churn passant de 3,3 % à 7,1 % mesure précisément cet écart.

Après avoir inscrit « pas de développement par phases » dans mes règles globales

J’ai une ligne figée dans mes propres règles globales : pas de développement par phases, livrer signifie un produit fini, ni MVP ni jalon partiel.

En pratique, cela donne :

• De vraies structures de données et de vrais contenus dès la première passe — pas de Lorem ipsum, pas de fausses données
• Les quatre états livrés ensemble : chargement, vide, erreur, succès
• L’exécuter moi-même avant de considérer que c’est livré — ouvrir dans un navigateur, exécuter en ligne de commande, taper le point d’API avec curl

Le prix est réel : la première description doit être bien plus longue. Il faut penser les limites, les états et les structures de données avant de commencer. Ce travail n’a pas été repris par l’IA ; il a seulement migré de « contraint d’y réfléchir au troisième tour de reprise » vers « réfléchi avant même le premier tour ».

Le gain est tout aussi direct : vous n’expliquez pas la même chose une deuxième puis une troisième fois. Et réexpliquer est justement le poste le plus cher de la facture ci-dessus.

Jusqu’où découper le périmètre : l’IA n’aide pas

Cette question n’a toujours pas de réponse.

« Bien faire du premier coup » suppose que le périmètre a été bien découpé. Trop large, et « du premier coup » devient « un très long coup ». Trop étroit, et ce que vous avez construit ne valide plus rien. Où passe ce trait relève du jugement sur les utilisateurs et les situations — et le titre de cet article de recherche avait déjà tout dit : le code est devenu bon marché, le jugement non.