Le Code Qui a Passé la Review
Une équipe a livré un service de réconciliation de paiements en trois jours. Avec l'aide de l'IA, un ingénieur a écrit 4 000 lignes de code, validé la suite de tests, et obtenu l'approbation en code review. Six semaines plus tard, un cas limite subtil d'arrondi monétaire a causé un écart de 12 000 €. La logique de réconciliation était correcte de façon isolée. L'interaction entre trois composants — chacun généré séparément, chacun relu séparément — a produit un mode de défaillance que personne n'avait modélisé.
Quand ils ont cherché à comprendre pourquoi, personne dans l'équipe ne pouvait expliquer entièrement le code. Pas parce qu'il était mal écrit. Parce que personne ne l'avait écrit avec une compréhension complète dès le départ.
C'est le nouveau visage de la dette technique.
À Quoi Ressemblait la Dette Technique Avant
La définition classique — la métaphore originale de Ward Cunningham(lien externe, nouvel onglet) — décrivait la dette comme des raccourcis délibérés : du code écrit rapidement en sachant qu'on en paierait le coût plus tard. Le développeur comprenait le compromis. Il le faisait consciemment.
Avec le temps, la définition s'est élargie. La dette accidentelle : de mauvais choix de conception faits sans mesurer les conséquences. Le bit rot : du code correct lors de son écriture, mais dégradé au fil de l'évolution du système.
Les deux formes partageaient une propriété : un humain avait écrit le code. Un humain le comprenait, au moins au moment de l'écriture.
La dette technique a toujours été une question de compréhension différée. L'IA n'a pas changé la dette — elle a supprimé le moment de compréhension.
Comment l'IA Change l'Équation
Quand un développeur écrit du code, il construit un modèle mental. Il comprend la logique, les cas limites, les hypothèses implicites. Même si cette compréhension s'efface avec le temps, elle a existé. Elle pouvait être retrouvée grâce à la mémoire de l'auteur, aux messages de commit ou aux documents de conception.
Le développement assisté par IA brise cette chaîne. Un développeur soumet un prompt à un agent, examine le résultat pour en vérifier l'exactitude apparente, lance les tests, et livre. Le modèle mental n'a jamais été construit. La compréhension n'a jamais existé pour s'effacer.
Le code a l'air propre. Les tests passent. Le linter est satisfait. L'analyse statique ne trouve rien. Et quelque part dans l'interaction entre les composants, il y a un mode de défaillance qui va surgir en production au pire moment.
Ce n'est pas hypothétique. Une étude de Stanford(lien externe, nouvel onglet) a montré que les développeurs ayant accès à un assistant IA écrivaient un code nettement moins sécurisé — tout en étant plus convaincus qu'il l'était — non pas parce que l'IA produisait du code manifestement mauvais, mais parce que les développeurs relisaient le code de l'IA avec moins de rigueur que le leur.
Trois Patterns à Surveiller
Code confiant avec des hypothèses incertaines. Les modèles d'IA génèrent des implémentations qui ressemblent à ce qu'ils ont vu. Le code est fluide. Les hypothèses métier peuvent être fausses. Un service de paiement qui gère EUR et USD correctement mais qui échoue silencieusement pour JPY parce que le modèle a été entraîné principalement sur des patterns fintech occidentaux.
Couverture de tests sans compréhension comportementale. L'IA peut générer des tests pour le code qu'elle génère. Ces tests passeront. Ce qu'ils testent, c'est que le code se comporte de façon cohérente avec lui-même — pas que ce comportement est correct. Les métriques de couverture sont excellentes. La suite de tests est un miroir, pas un validateur.
Chaînes de dépendances que personne n'a cartographiées. Les agents IA qui travaillent sur plusieurs fichiers créent des dépendances implicites entre composants. Chaque pièce est localement cohérente. La surface d'intégration est invisible à moins que quelqu'un ne l'ait explicitement cartographiée — et sous la pression de la livraison, personne ne l'a fait.
C'est un Problème de Processus, Pas d'Outil
Je ne plaide pas contre le développement assisté par IA. Les gains de productivité sont réels et la direction est irréversible. Mais la vitesse sans discipline échoue de la même manière qu'une migration Kubernetes précipitée — les raccourcis restent invisibles jusqu'à la production.
Mais les équipes qui traitent le code de l'IA comme celui d'un développeur senior — en vérifiant les bugs évidents et en passant à autre chose — accumulent une nouvelle forme de dette plus difficile à détecter et à rembourser que tout ce que Ward Cunningham avait imaginé.
La réponse n'est pas de relire chaque ligne comme si elle avait été écrite à la main. Ça supprime le bénéfice de vitesse. La réponse est d'investir dans des garde-fous différents : une couverture de tests comportementale qui valide les résultats par rapport aux spécifications, pas seulement la cohérence interne ; des Architecture Decision Records(lien externe, nouvel onglet) explicites pour que le pourquoi derrière les structures générées par l'IA soit capturé ; et des sessions régulières où les équipes parcourent les chemins critiques non pas pour les déboguer, mais pour reconstruire les modèles mentaux que la génération IA a ignorés.
La dette n'est pas dans le code. Elle est dans la compréhension manquante. C'est ça qui doit être remboursé.
Si vous vous demandez pourquoi les équipes continuent à livrer sous cette pression, la réponse se trouve en partie dans la façon dont l'IA redéfinit les attentes de livraison — et en partie dans l'évolution des cadences de sprint.
Le Takeaway
Choisissez un module généré par IA que votre équipe a livré le mois dernier. Planifiez une heure où quelqu'un qui ne l'a pas écrit doit expliquer à voix haute ce qu'il fait et pourquoi il est correct. S'ils ne peuvent pas — c'est là la dette. Commencez par là.
