Votre IA vient de produire en masse de la dette technique.
L'IA était censée améliorer votre code. Elle l'a empiré.
Pour la première fois depuis l'invention du contrôle de version, les équipes livrent plus vite et cassent davantage.
L'IA fait trois choses pour les équipes d'ingénierie. Elle écrit du code plus vite. Elle détecte les défauts plus tôt. Elle construit des choses que votre équipe actuelle ne peut pas construire seule.
L'industrie a tout misé sur la première. La vitesse. Plus de code, plus vite.
Personne ne s'est demandé ce qui se passe quand on multiplie par 3 le rendement d'une équipe qui ne comprenait déjà pas la moitié de sa propre base de code.
Source : https://www.faros.ai/blog/ai-acceleration-whiplash-takeaways
J'ai déjà vu ça. Nous l'avons tous vu.
À la fin des années 1990, le Java d'entreprise promettait "write-once-run-anywhere". Les entreprises ont misé des gammes entières de produits là-dessus. J2EE, EJB, piles middleware.
En 2005, changer la couleur d'un bouton dans une application Java d'entreprise moyenne nécessitait 14 fichiers répartis dans 6 packages. Martin Fowler a appelé ça "la maladie de l'entreprise". Les entreprises ne pouvaient plus livrer. Elles ne pouvaient embaucher personne qui comprenne le système. Elles ne pouvaient pas réécrire parce qu'elles ne pouvaient pas documenter ce que faisait l'ancien système.
Le correctif a pris une décennie. Frameworks légers. TDD. CI. Agile. L'industrie a dû reconstruire la couche de gestion autour de la technologie.
L'IA fait la même chose, mais sur une échelle de temps compressée.
Nous avons donné à chaque développeur la capacité de générer des milliers de lignes de code par jour. Le développeur qui a fait la requête ne peut pas expliquer ce qui a été construit. Le relecteur qui l'a approuvé ne l'a pas lu. Et le prochain développeur qui héritera du code le traitera comme une boîte noire, parce que c'est ce que c'est.
J'ai observé cela sur des bases de code existantes et sur des démos nouvelles. Elles cassent de la même manière.
Voici les 5 modes de défaillance que nous observons dans nos missions.
Les 5 Modes de Défaillance de l'IA sur les Bases de Code Réelles
1. Le volume généré par l'IA est le nouveau "jeter du personnel sur le problème".
Tous les CTO ont acheté des licences Cursor. Chaque conseil d'administration a demandé le ROI. Le cycle de battage médiatique a fait son plein en moins d'un an.
Mais plus de code n'a jamais été le problème.
70% des entreprises du Fortune 500 utilisent encore des logiciels vieux de plus de vingt ans. Ces bases de code ne sont pas lentes parce que les développeurs tapent trop lentement. Elles sont lentes parce que personne en vie dans l'entreprise ne comprend toutes les règles métier encodées dans le code.
Donnez à un agent IA accès à cette base de code. Il produira un code fonctionnel qui passe les tests et viole des contrats que personne n'a documentés.
Le rapport DORA 2026 : les outils IA offrent des gains de 35 à 40% sur les tâches propres en terrain vierge. Sur une base existante, mêmes outils, 10% ou moins. Un écart de 4x.
Le goulot d'étranglement, c'était la compréhension. L'IA l'a aggravé.
2. La dette de compréhension est la nouvelle dette technique.
GitClear a analysé 623 millions de modifications de code. La refactorisation d'ancien code a chuté de 74% depuis 2023. Les outils IA génèrent du nouveau code au lieu de réutiliser ce qui existe. Un test réussi. Un ticket fermé. Aucune consolidation par rapport au système existant.
Addy Osmani de Google l'a nommée "dette de compréhension" : l'écart entre la quantité de code qui existe et ce qu'un humain peut comprendre.
Sur une base de code de 6 mois, vous récupérez. Sur un monolithe de 10 ans avec des intégrations non documentées et une logique métier répartie sur des centaines de fichiers, vous ne récupérez pas.
La dette technique, c'est du code dont vous savez qu'il est mauvais. La dette de compréhension, c'est du code que vous ne pouvez même pas évaluer. L'IA est la première technologie qui génère le second type à grande échelle.
3. La revue de code de façade est le nouveau tampon en caoutchouc.
31% de PR en plus fusionnées sans aucune revue dans l'ensemble de données de 22 000 développeurs de Faros AI. Le temps de revue médian a augmenté de 5x parce que les relecteurs ne pouvaient pas suivre le rythme du volume.
Plus de production, moins de contrôle qualité, personne n'a le pouvoir de ralentir. Nous avons vu ce schéma organisationnel des centaines de fois avant l'existence de l'IA. Maintenant, il tourne à la vitesse machine.
Anthropic a découvert que les développeurs utilisant l'IA pour une délégation passive obtenaient un score inférieur à 40% aux tests de compréhension. En mode interrogation active : 65%+. Mêmes outils. La variable, c'était l'humain.
La plupart des équipes utilisent l'IA pour éviter de penser. Cela vous rattrape en production.
4. Les personnes qui comprennent le système ont le moins d'intérêt à le nourrir à l'IA.
J'ai parlé au responsable technique d'une société de logiciels soutenue par du capital-investissement, réalisant environ 15 millions de dollars de revenus. Son équipe a essayé Claude en interne. Ses mots : "Il a fait un tas de trucs stupides."
Il a raison d'être sceptique.
Ford a laissé partir des ingénieurs expérimentés avant que leurs connaissances ne puissent former les systèmes qualité. Trois ans et des milliards de coûts de garantie plus tard, ils ont réembauché 350 ingénieurs vétérans. Ces ingénieurs ont ré-entraîné l'IA. Reconstruit les processus qualité. Ford est désormais en tête de l'étude de qualité initiale 2026 de JD Power pour la première fois en 16 ans.
Leur VP de l'ingénierie matérielle : ils pensaient qu'ingérer les exigences de conception produirait un produit de haute qualité. Ça n'a pas marché. L'expertise du domaine devait passer en premier.
Les personnes qui détiennent la connaissance institutionnelle ont vu la dernière série d'initiatives "d'efficacité". Elles savent ce qui se passe après que le processus soit documenté. Les guildes médiévales gardaient leurs méthodes secrètes pour la même raison.
5. La base de code qui a le plus besoin d'IA est celle où l'IA fonctionne le moins.
Plateformes SaaS de milieu de marché. Systèmes de santé. Backends logistiques. Produits financiers construits par des développeurs partis il y a des années.
Ces entreprises ont des clients payants, des revenus réels et une logique métier qui mérite d'être préservée. Elles ont la plus grande surface d'accélération pour l'IA.
Chaque outil de codage IA vendu aujourd'hui suppose que la base de code est propre, que l'architecture est modulaire, que le développeur peut donner suffisamment de contexte à l'agent. Cette hypothèse se brise à l'intérieur d'un monolithe de 10 ans avec des intégrations non documentées et des règles métier dont personne ne se souvient avoir écrites.
74% des initiatives IA ne passent pas le stade du pilote, selon Gartner. Le modèle fonctionne bien. La base de code n'était pas prête.
Ce qui résout réellement le problème
Nous l'avons prouvé sur une mission réelle. Deux ingénieurs sur une plateforme logistique existante. 330 PR fusionnées en 6 mois. ~90% de code généré par IA. Le client les a qualifiés de meilleure équipe de performance. Ils ont reçu des bonus discrétionnaires à deux reprises.
Ce résultat est venu de la préparation, pas de meilleurs modèles. Trois choses se sont produites avant que l'IA ne touche une ligne de code.
Documentez avant de requêter. Nous appelons cela l'Étape Zéro. Avant qu'un agent IA ne touche une base de code existante, vous analysez le code existant, produisez une documentation lisible par l'IA, rendez le système compréhensible pour les outils. L'agent ne peut pas raisonner sur ce qu'il ne peut pas voir. Le redressement de Ford a commencé ici. Ils ont ramené les personnes qui comprenaient le système, documenté ce qu'elles savaient, et seulement ensuite ré-entraîné l'IA.
Définissez les zones. 80/20/0. 80% de code standard (CRUD, tests, config, doc) : l'IA génère librement. 20% de logique métier et d'intégrations : mode copilote, l'IA rédige un brouillon, l'ingénieur réécrit. 0% pour l'authentification, les paiements, le chiffrement, les décisions d'architecture : l'IA n'y touche pas. Cette discipline empêche la dette de compréhension de s'accumuler.
Mesurez avant de passer à l'échelle. Coût par commit. Modèles d'utilisation. Pourcentage de code IA. Métriques DORA pour chaque équipe. Baseline avant l'IA. Mesure après. Sans ces données, vous volez à l'aveugle dans le même coup de fouet d'accélération qui a frappé 22 000 développeurs dans l'ensemble de données de Faros.
Où cela mène
Microsoft a engagé 2,5 milliards de dollars. Amazon a engagé 1 milliard de dollars. Anthropic a levé 1,5 milliard de dollars. OpenAI a levé 4 milliards de dollars. Tous visent le même problème : faire fonctionner l'IA dans des entreprises qui existent déjà.
Le marché s'est concentré sur le terrain vierge parce que les démos sont plus belles. L'impact d'ingénierie le plus important viendra des entreprises dont les bases de code sont les plus laides, dont les produits sont les plus anciens, et dont les pipelines ont été construits avant que quiconque ait entendu parler d'un LLM.
Le goulot d'étranglement, c'est le système d'ingénierie sous-jacent au modèle.
P.S. C'est ce que nous faisons chez Limestone Digital. Nous intégrons des équipes d'ingénierie natives de l'IA dans des bases de code existantes. Étape Zéro, discipline de zone, infrastructure de mesure. Si votre pilote IA a calé sur une base de code existante, envoyez-moi un message privé.
Contactez-nous : [limestonedigital.com](https://limestonedigital.com/)
