Pourquoi les équipes IA livrent plus vite et lancent moins bien : le problème de la dette d'intention

L'IA a rendu l'écriture de code presque gratuite. Décider quoi écrire est devenu plus difficile. Cet écart, c'est la dette d'intention, et elle s'accumule plus vite que n'importe quelle base de code legacy.

Garry Tan annonce livrer 37 000 lignes de code par jour sur cinq projets tout en dirigeant Y Combinator à plein temps. Les ingénieurs d'Anthropic ont accumulé 47 jours de régressions silencieuses dans Claude Code avant de les documenter dans un postmortem public le 23 avril 2026. Ces deux chiffres décrivent le même problème depuis des angles opposés.

Si votre équipe écrit plus de code que jamais et livre de moins bons résultats qu'il y a un an, vous observez la dette d'intention s'accumuler en temps réel. La dette technique était la taxe sur le développement lent. La dette d'intention est la taxe sur la décision lente. Cet article nomme le goulot d'étranglement, explique pourquoi vos couches de revue et d'évaluation ne peuvent pas le détecter, et présente les quatre actions qui permettent de la rembourser.

• L'IA a compressé le temps de développement de 30 à 100 fois. Le temps de décision, lui, n'a été compressé que de 3 à 5 fois. L'écart est le nouveau goulot d'étranglement.

• La dette d'intention se situe en amont de chaque couche de revue. Les outils de revue de code IA, les évaluations et les agents QA détectent le mauvais code ; ils ne détectent pas la mauvaise chose bien construite.

• Les 47 jours de régression silencieuse d'Anthropic dans Claude Code constituent un postmortem de dette d'intention déguisé en problème d'évaluation. La dérive n'était pas dans le code, elle était dans ce à quoi l'équipe prêtait attention.

• La solution est structurelle, pas tactique. On ne s'en sort pas en livrant davantage. On ne s'en sort qu'en décidant mieux, plus vite et plus tôt.

• webvise traite la capture d'intention comme le livrable, et non comme une activité pré-vente gratuite. Voyez où cela s'applique dans votre équipe.

Ce qu'est réellement la dette d'intention

La dette technique est le terme que Ward Cunningham a forgé en 1992 pour décrire le coût futur du choix d'une solution rapide plutôt que propre. L'échange avait une économie claire. On livrait plus tôt, on payait des intérêts sous forme d'une maintenance plus lourde, et le capital restait dans la base de code comme quelque chose à refactoriser dès que le temps le permettrait.

La dette d'intention a la même forme. L'échange consiste à obtenir du code plus rapidement en contrepartie de décisions plus floues. On livre plus tôt parce que l'IA a écrit l'implémentation en 30 minutes au lieu de trois jours, et les intérêts représentent tout ce qui s'accumule en aval quand personne n'a défini dès le départ ce que devait être le bon résultat.

Le vocabulaire manque parce que l'échange est nouveau. Les écrits de Martin Fowler sur le nommage et l'intention de conception supposent un monde où écrire le code était l'étape coûteuse, ce qui justifiait économiquement de bien concevoir dès le départ pour éviter les réécritures.

Cette hypothèse s'est inversée en 2024. Quand une réécriture prend une journée, l'étape de conception cesse de se rentabiliser comme avant. Les équipes le constatent et sautent l'étape de conception, qui était précisément l'endroit où l'intention se condensait en quelque chose d'exploitable pour la suite.

Deux modes d'échec observés directement.

Premier cas : une fonctionnalité est livrée en trois jours, là où il aurait fallu trois semaines avant l'IA. Elle fonctionne. Elle résout aussi un problème que les utilisateurs n'avaient pas, parce que la spec était un message Slack et que l'implémenteur était un agent Cursor. Le coût de construction était si bas que l'équipe n'a jamais remis en question l'intérêt de la construire.

Second cas : un ingénieur senior abandonne six directions produit en une seule année. Aucune ne disparaît pour des raisons techniques. Chacune échoue à l'étape de pré-vente, et l'ingénieur continue à éviter cette étape parce qu'écrire du code lui semble plus productif. Cet ingénieur, c'est moi, et le coût a posteriori de ces six directions était supérieur à n'importe quelle dette technique jamais remboursée.

Ces deux récits sont la dette d'intention avec les preuves à l'appui. La plupart des équipes d'ingénierie tentent encore de les résoudre au niveau de la construction, avec un autre outil de revue, une autre évaluation, un autre linter. La solution se trouve un niveau au-dessus. Si votre équipe produit ce type de résultats, webvise a été conçu autour de cette inversion.

Les chiffres derrière le changement

Les données de première main les plus claires sur l'asymétrie proviennent du fichier ETHOS de gstack de Garry Tan, publié en avril 2026. Tan distribue une boîte à outils d'agents open source depuis Y Combinator et instrumente ses agents avec des ratios de compression explicites homme/IA pour chaque type de tâche.

À lire colonne par colonne. Le boilerplate se compresse à 100x, l'écriture de tests à 50x, le travail sur les fonctionnalités à 30x. L'architecture et la recherche se compriment à 5x et 3x respectivement.

Les trois dernières lignes relèvent du travail de décision. Elles se compriment, mais à un dixième du rythme des trois premières. Voilà la source structurelle de la dette d'intention : le développement est désormais presque gratuit, la prise de décision reste coûteuse.

Pour rendre cela concret : si votre équipe consacrait autrefois 80 % d'une journée d'ingénierie au code et 20 % aux décisions, le nouveau ratio après une compression de 30x sur le code ressemble à environ 12 % de code et 88 % de décisions. La plupart des équipes ont conservé les mêmes effectifs, le même rythme de réunions et la même structure de revue, puis ont regardé la seconde colonne déborder.

Ce débordement, c'est ce à quoi ressemble la dette d'intention en pratique.

Trois symptômes indiquant que vous la portez déjà

La dette d'intention est invisible jusqu'à ce qu'on la nomme. Trois symptômes apparaissent dans toutes les équipes avec lesquelles je travaille.

Le réflexe de réduction de périmètre sur du travail à coût amorti

On se surprend à écrire trois tests au lieu de dix, à sauter la documentation, à considérer 80 % comme suffisant. Cet instinct avait du sens quand le temps humain était la contrainte principale. Avec l'IA dans la boucle, la version complète coûte le même nombre de minutes que la solution de contournement.

Ce réflexe est désormais une pensée héritée, appliquée automatiquement. Le coût en est l'habitude décisionnelle qui dit que livrer plus tôt vaut mieux que livrer bien, alors que livrer plus tôt ne fait plus gagner de temps.

Plus de revues, moins de décisions

Elie Steinbock a publié une thèse le 20 avril 2026 qui identifie la revue comme le nouveau goulot d'étranglement. Il liste sept couches de défense, des outils de revue de code IA comme Cubic et CodeRabbit aux agents QA dédiés et à l'observabilité ciblée. Les équipes adoptent ces couches et la surface de revue absorbe une part croissante de la journée.

La dette d'intention se situe en amont de tous ces outils. Les outils de revue IA détectent le mauvais code ; ils ne détectent pas la mauvaise chose bien construite. Un agent QA qui parcourt chaque flux à chaque livraison indiquera que le flux fonctionne, pas s'il devrait exister.

La dérive silencieuse qu'on ne voit qu'en postmortem

Anthropic a publié un postmortem le 23 avril 2026 documentant 47 jours de régressions silencieuses dans Claude Code. Le cadre d'analyse principal était : "les évaluations ne détectent pas la dérive". Le cadre plus profond est que la dérive s'accumule dans l'écart entre ce que l'équipe avait l'intention de faire et ce que le système faisait réellement.

Chaque équipe qui développe avec assistance IA a sa propre fenêtre de 47 jours ouverte en ce moment. La plupart des équipes ne la découvriront qu'en postmortem.

Pourquoi les revues et les évaluations ne peuvent pas la détecter

Les outils de revue répondent à la question : "le code a-t-il fait ce que la spec disait ?" Les suites d'évaluation répondent à : "le modèle s'est-il comporté comme l'évaluation le prévoyait ?" Ce sont des questions correctes et étroites. L'une et l'autre traitent la spec et l'évaluation comme des vérités établies.

La dette d'intention s'accumule à la couche au-dessus. Le coût réside dans l'écart entre ce dont le client avait besoin, ce que le brief disait, et ce que la spec a capturé. Quand le code arrive devant un outil de revue, la spec a déjà verrouillé l'intention. L'outil de revue ne peut pas détecter un défaut de spec, il peut seulement signaler des défauts d'implémentation par rapport à une spec elle-même défectueuse.

C'est la même configuration que la dérive chez Anthropic. L'équipe Claude Code disposait d'évaluations. Les évaluations passaient.

La dérive portait sur ce que les évaluations mesuraient par rapport à ce que les utilisateurs vivaient réellement. Quarante-sept jours de feux verts, des utilisateurs réels touchés par une régression chaque jour. La solution réside dans un retour d'information plus étroit entre les personnes qui décident quoi mesurer et celles qui observent le signal de production.

La pensée centrée sur les goulots de revue traite cela comme un problème d'outillage. C'est un problème d'architecture en couches. À lire en complément de l'article précédent sur pourquoi les logiciels générés par l'IA nécessitent encore une revue d'ingénierie, qui couvre la moitié de l'argument au niveau de la construction. Pour rembourser la dette d'intention, il faut poser une question différente, plus tôt.

La couche de décision ne se comprime pas comme le code

La formulation de Tan sur la raison pour laquelle c'est structurel : "vous apportez le goût à travers vos échanges avec l'agent". L'agent apporte l'exhaustivité. L'humain apporte la direction et le jugement. Le goût ne suit pas la même courbe de compression que le code.

Trois composantes du goût que la génération de code ne peut pas remplacer.

Choisir le bon problème

La thèse services-as-software d'Alex Vacca, publiée via Julien Bek (associé chez Sequoia) en avril 2026, en donne la version élargie. Les éditeurs de logiciels qui vendent l'outil courent éternellement après le modèle. Les entreprises qui possèdent le travail et utilisent le modèle pour le réaliser progressent à chaque amélioration du modèle.

La même logique s'applique au sein des équipes. Les ingénieurs qui choisissent le bon problème progressent à chaque amélioration du modèle. Ceux qui n'exécutent que des specs imposées deviennent une commodité du jour au lendemain.

Savoir quand s'arrêter

Les outils IA ne disent jamais de s'arrêter. Un LLM s'engage dans la dix-septième approche du même problème avec le même enthousiasme que la première, et chaque réponse donne l'impression de progresser. Sans condition d'arrêt externe, la boucle tourne indéfiniment.

Les ingénieurs expérimentés imposaient autrefois la sortie par l'ennui ou le manque de temps. Ces deux contraintes sont désormais infinies. La condition d'arrêt doit être définie explicitement en amont, avant le premier prompt.

La dissidence que fournissent les ingénieurs seniors

La contribution la plus difficile qu'un ingénieur senior produise est la dissidence : le message "c'est la mauvaise chose à construire" qui préempte un trimestre d'exécution. Les agents IA ne dissentent pas. Ils construisent ce qu'on leur demande, complètement, sur une courbe de compression de 100x.

On livre ce qu'on a demandé, et on réalise seulement plus tard qu'on avait demandé la mauvaise chose.

Quatre actions pour rembourser la dette d'intention

Ces actions sont tactiques. Elles supposent que votre équipe a déjà nommé le problème et cessé d'essayer de l'absorber au niveau de la couche de revue.

Pré-vendre avant d'ouvrir l'éditeur

C'est l'action que j'ai dû réapprendre à mes dépens. Si vous construisez quelque chose pour quelqu'un d'autre que vous-même, obtenez un engagement verbal, un acompte ou une lettre d'intention avant qu'un agent n'écrive la moindre ligne.

L'enthousiasme verbal, les votes au lancement et une liste d'attente sans engagement réel sont des signaux de demande faibles. Le coût de construction est si bas que le seul filtre restant est de savoir si le client paiera.

Traiter la spec comme l'artefact durable

Avant l'IA, la spec était un document de travail et le code était l'artefact. Après l'IA, le code est régénérable et la spec est la chose durable.

Rédigez des specs qui nomment explicitement le client, les modes d'échec et la métrique de succès. Stockez-les sous contrôle de version à côté du code. Quand la spec change, la régénération est triviale ; quand la spec est fausse, aucune régénération ne sauvera le projet.

Effectuer une revue de décision à deux modèles

Un seul LLM peut rationaliser n'importe quelle direction ; un second modèle invité à contredire détecte la moitié des mauvais choix. Ce schéma fonctionne pour la revue de code, où Claude plus Codex plus Gemini servent de vérification croisée sur chaque fonctionnalité livrée.

L'usage à plus haute valeur est la revue de décision. Présentez la spec à deux modèles, demandez-leur de diverger, évaluez la divergence avant de construire. Le coût est négligeable comparé à la construction de la mauvaise chose.

Tenir un fichier des directions abandonnées

Chaque produit, fonctionnalité ou campagne abandonné avant livraison va dans un document unique avec la raison. La raison compte plus que le nombre. À relire avant de commencer quoi que ce soit de nouveau.

Le schéma qui explique pourquoi les directions échouent est le remboursement de dette d'intention le moins coûteux disponible, et presque toutes les équipes l'ignorent. Si vous cherchez à déterminer où appliquer ces actions dans votre équipe, webvise peut vous aider.

Choisir un partenaire web à l'ère de l'IA

L'erreur la plus coûteuse qu'une équipe à l'ère de l'IA puisse commettre est de recruter une agence qui ne maîtrise que la couche de construction. La construction est désormais la partie bon marché. La couche de décision (quoi livrer, quand abandonner, qui est réellement l'utilisateur) est là où se trouve le multiplicateur.

La plupart des agences tarifient encore la construction parce que c'est ce que leur modèle de marge sait faire. webvise a été conçu autour de l'inversion.

Les engagements en automatisation IA et en applications full-stack démarrent par un sprint de découverte qui produit une spec rédigée, une liste de directions abandonnées et une revue de décision à deux modèles sur chaque élément de périmètre validé. Une fonctionnalité peut être livrée en une journée. Elle ne le sera pas tant que l'équipe n'aura pas défini à quoi ressemble le succès en production.

Si vous avez livré plus de code que jamais ce trimestre et vous sentez plus loin d'un produit fonctionnel qu'il y a six mois, réservez un appel de découverte. Le moyen le plus rapide de rembourser la dette d'intention est de cesser d'en accumuler.