Même équipe, mêmes outils, même trimestre. Sur un projet démarré de zéro : cent pour cent du travail produit par des agents, pas une ligne écrite à la main en trois mois, et un niveau d’ambition que son auteur décrit comme sans plafond. Sur un produit déjà installé avec des milliers d’utilisateurs : des ajouts défendables un par un, un ensemble devenu incohérent, et une reprise manuelle pour réparer.
C’est le même homme qui raconte les deux, et c’est ce qui rend l’histoire utile.
Deux résultats opposés, un seul praticien
David Heinemeier Hansson dirige la technique de 37signals, l’éditeur de Basecamp, et a créé Ruby on Rails. En août 2026, il raconte sa dernière année dans un entretien.
Côté page blanche, il déclare n’avoir écrit aucune ligne à la main pendant trois mois sur un projet neuf, avec une accélération qu’il chiffre à cent pour cent. Côté existant, le récit change de ton. En février 2026, pendant le sprint final de Basecamp 5, son équipe a laissé les designers produire eux-mêmes des fonctionnalités avec des agents, au motif qu’ils savaient exactement ce qu’ils voulaient. Sa conclusion : chaque contribution prise isolément pouvait se défendre, mais l’ensemble a détruit l’architecture du produit. Il a fallu reprendre le travail à la main pour retrouver quelque chose de cohérent.
Deux précautions avant d’en tirer quoi que ce soit. C’est un récit fait par la partie concernée, crédible sur le fait mais non chiffré sur l’ampleur. Et son auteur date lui-même l’épisode de février 2026 en soulignant que les outils ont beaucoup changé depuis.
Ce que mesurent 623 millions de modifications
Un récit ne prouve rien. Une mesure, si.
L’étude GitClear publiée en 2026 sous le titre The Maintainability Gap a analysé 623 millions de modifications de code entre 2023 et 2026, à mesure que la part de travail assisté par IA montait jusqu’à environ un quart des livraisons. Les résultats vont tous dans le même sens.
Ce qui recule : le remaniement de code, en baisse de 70 %. La réutilisation de fonctions d’un fichier à l’autre, en baisse de 35 %. La maintenance du code ancien, en baisse de 74 % par rapport à 2022.
Ce qui monte : la duplication de blocs, en hausse de 81 %. Le copier-coller à l’intérieur d’une même livraison, en hausse de 41 %. La reprise de code sous quinze jours, en hausse de 15 %.
Traduit en français courant : on produit beaucoup plus vite, et on entretient beaucoup moins. Chaque ajout rapide se défend tout seul. C’est l’accumulation qui coûte.
Pourquoi ça vous concerne même sans une ligne de code
Ces chiffres portent sur du code. Ils ne prouvent rien sur un site, une identité ou une campagne, et prétendre le contraire serait malhonnête.
Ce qu’ils établissent, c’est qu’un mécanisme précis est mesuré dans le seul domaine où il est mesurable. Ce mécanisme, le voici : quand produire devient rapide et peu cher, on ajoute au lieu de reprendre. Chaque ajout est justifiable. L’ensemble se dégrade. Et le coût de la dégradation n’apparaît qu’au chantier suivant, quand la modification d’après coûte trois fois la précédente.
Vous avez déjà vu ce mécanisme ailleurs, sans lui donner ce nom. Un site qui a reçu quatorze pages ajoutées au fil des besoins, chacune décidée pour une bonne raison, et dont plus personne ne sait décrire l’arborescence. Une identité visuelle déclinée par cinq intervenants successifs, chaque déclinaison défendable, l’ensemble méconnaissable. Un jeu de gabarits d’e-mails qui a doublé de volume sans que quiconque ne supprime jamais rien.
Ce mécanisme existait avant l’IA, et il rejoint un constat plus ancien : acheter un bel actif n’achète pas un résultat. La différence, c’est qu’il tourne maintenant beaucoup plus vite, et qu’il coûte moins cher à alimenter.
La question à trancher avant de commander quoi que ce soit
Le réflexe du marché consiste à promettre un gain uniforme : moins cher, partout, tout de suite. C’est ce que le client veut entendre, et c’est faux.
Le gain est spectaculaire sur un terrain vierge. Il se retourne sur un terrain occupé et mal cadré. Avant de commander, il faut donc trancher une question que peu de devis posent : est-ce qu’on greffe, ou est-ce qu’on refait ? La réponse change le prix autant que le délai.
Trois critères font pencher vers la greffe. Votre structure actuelle tient encore debout et vous savez la décrire en une minute. Le besoin est localisé, il ne touche pas le socle. Quelqu’un chez vous ou chez votre prestataire est responsable de la cohérence de l’ensemble et a le pouvoir de refuser un ajout.
Trois critères font pencher vers la refonte. Personne ne sait plus expliquer pourquoi telle page ou tel gabarit existe. Les dernières modifications ont pris plus de temps que les premières, à difficulté comparable. Chaque nouvelle demande oblige à en réparer une ancienne.
Si vous êtes dans le second cas, greffer vite avec de l’IA vous coûtera plus cher que le statu quo. Vous accélérerez la dégradation, et vous paierez la remise en ordre deux fois.
Ce qu’un devis honnête devrait contenir
Un devis qui promet la vitesse sans nommer le terrain est un devis incomplet. Trois éléments manquent presque toujours.
Le premier : la qualification explicite du chantier. Terrain vierge ou existant occupé, dit noir sur blanc, parce que ce n’est pas le même prix à périmètre égal.
Le deuxième : sur un existant, une estimation du coût de remise en ordre, séparée du coût de construction. Personne n’aime lire cette ligne. Elle est pourtant la seule qui protège contre la mauvaise surprise du chantier suivant.
Le troisième : le nom de la personne qui tient la cohérence pendant que la production accélère, et son droit de refuser une demande. Sans ce rôle, l’accumulation est garantie, quels que soient les outils.
Rien de tout cela n’est un argument contre l’IA. Le praticien cité plus haut produit aujourd’hui l’intégralité de son travail avec des agents et n’en revient toujours pas. La leçon est ailleurs : la vitesse n’est pas une propriété de l’outil, c’est une propriété du terrain sur lequel vous le lâchez.
