L'IA optimise pour écrire, pas pour entretenir : 623M de modifications montrent duplication +81% et refactor -70%. La dette s'accumule invisible. Le remède n'est pas un meilleur modèle mais l'architecture : source unique de vérité, DRY forcé et un graphe du projet.
Imagine un maçon qui ne sait que poser des briques, jamais les retirer. Chaque fois que tu lui demandes un nouveau mur, il le dresse impeccable et à toute vitesse — mais il ne démolit jamais celui qui ne sert plus, ne réutilise jamais un mur existant, ne réorganise jamais la maison. Au bout de six mois, tu n'as pas une maison : tu as un labyrinthe de murs superbes que personne ne peut habiter. Ce maçon, c'est l'IA en train d'écrire du code, et nous ne le disons pas comme une métaphore provocatrice : c'est ce que dit la plus grande étude empirique existante sur le sujet. GitClear et GitKraken ont analysé 623 millions de modifications réelles de code entre 2023 et 2026, et ont découvert que l'IA optimise brutalement pour une seule chose — écrire — tandis que l'autre moitié du métier, entretenir, s'effondre en silence.
Le chiffre qui devrait t'empêcher de dormir
Les chiffres sont précis et ils sont laids. La duplication de code a bondi de 81%. Le code déplacé ou refactorisé — le signal le plus net que quelqu'un consolide au lieu d'entasser — a chuté de 70%. Le refactor de code legacy, cette tâche ingrate qui consiste à réparer l'ancien, s'est effondré de 74% depuis 2023. Et l'error masking, l'habitude d'avaler les erreurs pour qu'elles ne remontent pas comme des défauts, a augmenté de 47% en 2026. Ce n'est pas l'anecdote d'une équipe malchanceuse : c'est un schéma mesuré sur des centaines de millions de commits, avec l'IA déjà présente dans environ un cas sur quatre.
L'IA n'a pas un problème de talent, elle a un problème d'incitation
Voici le piège mental qu'il faut briser. On a tendance à penser que si le code sort mal, c'est parce que le modèle n'est pas assez intelligent. Faux. Le modèle est excellent — pour ce à quoi on l'a entraîné. Et on l'a entraîné à produire la réponse qui satisfait ta demande maintenant, pas à prendre soin de la santé du système dans un an. Bill Harding, PDG de GitClear, le résume par une phrase que tu devrais te tatouer avant ton prochain prompt : « chaque fois que tu veux quelque chose, l'IA crée un nouveau paquet ». Elle ne cherche pas la fonction qui existe déjà. Elle ne demande pas s'il y a un motif à réutiliser. Elle dresse un autre mur. Et comme il le prévient lui-même, « à long terme, ça commence à faire mal quand tu réalises que tu as cinq implémentations différentes » de la même chose — chacune légèrement différente, chacune un endroit où le prochain bug peut se cacher.
Écrire est gratuit, entretenir coûte très cher — et l'IA n'a rendu bon marché que ce qui l'était déjà
Le grand malentendu de cette époque, c'est de croire que le goulot d'étranglement du logiciel était de taper au clavier. Ça ne l'a jamais été. Dans tout projet sérieux, écrire la première version de quelque chose est la partie facile et courte ; ce qui consomme des années et des budgets, c'est de le comprendre, de le modifier sans le casser, et d'effacer ce qui est en trop. L'IA a rendu triviale la partie qui était déjà bon marché — générer des lignes — et n'a pas touché (voire a empiré) la partie coûteuse. C'est comme si on inventait une imprimante qui crache des pages gratuites et qu'on célébrait qu'écrire des romans soit désormais plus facile, en ignorant que le difficile a toujours été d'éditer. L'error masking à 47% est la cerise perverse : comme le résume Harding, l'IA « préfère clairement écrire du code qui ne sera pas étiqueté comme défaut ». Non seulement la dette s'accumule : le code est conçu pour ne pas crier quand quelque chose va mal, si bien que la dette devient invisible jusqu'à ce qu'elle explose en production.
La duplication n'est pas du désordre, c'est de l'intérêt composé à l'envers
Un doublon isolé ne tue personne. Le problème, c'est que la duplication se compose. Quand la même logique vit à cinq endroits, chaque changement de règles métier t'oblige à trouver et éditer les cinq copies — et il suffit d'en oublier une pour avoir un bug subtil qui n'apparaît que dans le cas rare. La connectivité fonctionnelle du code, selon la même étude, a chuté de 35% : les modules se parlent moins entre eux parce que chacun apporte sa propre version de tout. C'est exactement l'inverse d'un système sain, où une décision se prend à un seul endroit et où tout le reste en hérite. Une base de code avec 81% de duplication en plus n'est pas une base de code plus grande : c'est une base de code qui vieillit à double vitesse, où chaque semaine de génération accélérée t'achète deux semaines de maintenance future.
Le remède n'est pas un meilleur modèle : c'est une source unique de vérité
Voici la leçon réutilisable, celle que tu peux partager et appliquer demain quel que soit l'outil que tu utilises. L'IA ne va pas se guérir toute seule de son biais vers l'écriture, parce que ce biais est dans sa fonction objectif. La contre-mesure ne vit pas dans le modèle : elle vit dans l'architecture qui l'entoure. DRY a cessé d'être une préférence esthétique pour devenir une défense active : si ton système rend facile de trouver et réutiliser ce qui existe déjà, l'IA duplique moins parce qu'elle a moins d'excuses. Une source unique de vérité — un endroit canonique pour chaque contrat, chaque type, chaque règle — c'est ce qui transforme le maçon qui ne fait qu'empiler en un maçon qui réutilise. Et une carte navigable du projet, un graphe qui dit « ceci existe déjà, connecte-toi à ça », c'est la différence entre un assistant qui consolide et un qui entasse. La vitesse de l'IA n'est un avantage que si tu la canalises dans une structure qui l'oblige à ne pas pourrir ce qu'elle touche.
Comment nous le voyons
Notre pari part d'une conviction inconfortable : la partie difficile n'est pas de générer, c'est de ne pas pourrir. D'où le fait que, dans NeuralOS, le frontend soit la source unique de vérité — le contrat existe d'abord et ce qui vient derrière le remplit, au lieu que chaque génération invente sa propre version du même écran. D'où le fait que nous maintenions un graphe de connaissance du projet : 623 millions de modifications d'autrui nous rappellent que sans carte, l'IA réécrit ce que tu avais déjà au lieu de le réutiliser. Et d'où le fait que le protocole Construct-Audit-Reflect sépare le moment de créer du moment d'auditer — parce que construire avec énergie et réviser avec paranoïa sont des états mentaux incompatibles, et les mélanger, c'est exactement ainsi que s'accumule la dette invisible que mesure l'étude. Nous ne croyons pas que la réponse à l'IA qui pourrit soit d'écrire moins avec l'IA. Nous croyons qu'il faut l'entourer de la discipline qu'elle n'apporte pas d'usine : DRY forcé, un contrat clair, un graphe qui se souvient. La vitesse sans architecture n'est pas de la productivité ; c'est de la dette avec une meilleure typographie.