# La Dette Technique IA N'est Pas ce que Vous Croyez

URL: https://codebasechat.com/fr/journal/dette-technique-ia
Type: blog
Locale: fr
Published: 2026-07-14
Updated: 2026-07-14

---

> La dette technique IA est deux problèmes distincts : la dette de code (doublons, patterns) et la dette cognitive (compréhension d'équipe). Découvrez ce que mesurent vraiment les équipes efficaces.

## La Dette Technique IA N'est Pas ce que Vous Croyez

La dette technique liée à l'IA ne se résume pas aux doublons de fonctions et aux noms de variables incohérents qu'un linter peut signaler. La moitié d'elle vous paraît impeccable lors de la relecture, passe les tests, est mergée en production, et ne fait surface que six semaines plus tard quand personne dans l'équipe ne peut expliquer pourquoi une modification ici a cassé trois choses inattendues ailleurs. C'est cette seconde moitié que presque aucune équipe ne mesure réellement.

## La Dette Technique IA : Deux Problèmes Distincts, Pas Un

Interrogez cinq responsables techniques sur la définition de la dette technique IA, et vous recevrez cinq réponses. Mais elles se rangent généralement dans deux catégories très différentes.

La première est la **dette de code** : duplication, patterns incohérents, code techniquement correct mais qui ajoute une surface de complexité que personne n'avait demandée. C'est le domaine natif des outils d'analyse statique.

La seconde est la **dette cognitive** : l'écart entre la vitesse de génération du code et la vitesse à laquelle l'équipe construit réellement un modèle mental partagé de ce qu'il fait. L'enquête 2026 « State of Code » de Sonar révèle que 88 % des développeurs rapportent au moins un impact négatif de l'IA sur la dette technique, et 53 % affirment que l'IA génère du code qui semble correct mais cache des défauts. C'est de la dette de code. Ce que l'enquête ne capture pas pleinement, c'est le second type, et [le reportage de LeadDev sur ce concept](https://leaddev.com/ai/ai-coding-creates-two-kinds-of-debt-youre-only-measuring-one) en donne le traitement le plus clair que nous ayons lu.

Trois équipes sur cinq confondent les deux. Voici ce que font les deux autres : elles trackent la dette de code avec des outils, et la dette cognitive avec des conversations.

## La Partie Debt de Code : du Code qui Paraît Bon et Ne l'Est Pas

La dette de code est du domaine familier. Le code généré par l'IA tend à dupliquer la logique qui existe déjà trois fichiers plus loin, parce que l'assistant ne sait pas que cette logique existe à moins qu'elle soit dans le contexte. L'enquête Sonar chiffre le phénomène : 40 % des développeurs affirment que l'IA a augmenté la dette en générant du code inutile ou dupliqué.

La variante dangereuse, ce n'est pas le code qui a l'air mauvais. C'est le code qui a l'air bon. Une fonction passe ses tests, traite le happy path proprement, se lit comme quelque chose qu'un senior écrirait, sauf qu'elle omet silencieusement un cas limite que l'implémentation originale gérait. La revue de code attrape les typos. La revue de code est bien plus mauvaise pour attraper une fonction plausible qui est subtilement incomplète.

`// Généré par IA : passe les tests, semble propre
function getActiveUsers(users) {
  return users.filter(u => u.status === "active");
}

// Ce que l'original gérait, trois fichiers plus loin :
function getActiveUsers(users) {
  return users.filter(u => u.status === "active" && !u.deletedAt);
}`Rien ici ne lève d'erreur. Rien n'échoue à la CI. L'écart n'apparaît que quand un utilisateur soft-supprimé réapparaît dans un rapport trois semaines plus tard, et celui qui reçoit l'alerte doit faire un grep, blâmer la commit, et demander autour pour trouver quelle version est correcte et pourquoi. Cette boucle de grep et de questionnement est le vrai coût, et on peut la mesurer en heures, pas dans un sentiment vague que quelque chose ne va pas.

Les outils docs-as-code qui vivent dans le même repo plutôt que dans un wiki séparé réduisent la fréquence de cette boucle, parce que le raisonnement derrière une fonction est un clic loin de la fonction elle-même au lieu de vivre dans la mémoire de quelqu'un.

![Gros plan sur des mains sur un clavier avec un diff rouge-vert visible sur l'écran flou en arrière-plan](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-07/eaeaef-inline1.webp)

## La Partie Debt Cognitive : Quand l'Équipe Perd le Fil

Le Dr Margaret-Anne Storey, professeur d'informatique à l'Université de Victoria, a forgé le terme « dette cognitive » en octobre 2025 après avoir observé ses étudiants livrer rapidement avec l'IA puis avoir du mal à agir sur leurs propres retours utilisateurs. Son diagnostic : les étudiants n'avaient pas perdu trace du code, ils avaient perdu trace de ce qu'ils construisaient et pourquoi, et qui dans l'équipe savait quoi.

Cette formulation emprunte à l'ancien argument de Peter Naur selon lequel le logiciel n'est pas vraiment le code, c'est la théorie partagée dans la tête des gens qui l'ont construit. Quand le code est généré plus vite que l'équipe ne peut construire cette théorie, la théorie ne se forme jamais. Vous pouvez avoir une base de code propre, entièrement testée, et toujours avoir une dette cognitive significative si les personnes qui l'ont livrée ne peuvent pas la expliquer complètement, ou si une seule personne peut.

C'est la partie que les métriques standard de dette technique IA manquent entièrement, parce que les tableaux de bord trackent le code, pas la compréhension. La question qui vaut le coup d'être posée lors de votre prochain rétro est directe : montrez un diagramme d'architecture, et demandez qui dans l'équipe peut expliquer chaque boîte. Si la réponse est « une personne, et elle est en vacances cette semaine », vous avez de la dette cognitive peu importe ce que votre linter dit.

Un wiki interne vivant ne règle pas la dette cognitive en soi. Il donne à l'équipe un endroit pour écrire le « pourquoi » avant qu'il ne vive dans la tête d'une seule personne, ce qui est un début.

![Trois ingénieurs debout devant un tableau blanc esquissant ensemble un diagramme d'architecture système](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-07/e90110-inline2.webp)

## Pourquoi la Revue de Code Ne Peut Pas Suivre la Vitesse de Génération

Voici le problème mécanique qui sous-tend les deux types de dette : l'IA permet à un ingénieur seul de générer une semaine de code avant le déjeuner, mais la capacité de revue n'a pas du tout augmenté. Le goulot s'est déplacé de l'écriture à la lecture, et la lecture est la partie que personne n'a accélérée.

C'est là que la comparaison d'outils compte réellement, et il vaut la peine d'être spécifique au lieu de vague. Copilot et Cursor sont rapides pour générer du code dans le fichier que vous avez déjà ouvert, ce qui explique exactement pourquoi ils sont bons pour produire plus de code qu'une équipe ne peut relire. Cody et Continue.dev s'appuient davantage sur la retrieval entre les fichiers du repo avant de générer, ce qui aide à éviter le problème de duplication ci-dessus, mais aucun ne remplace l'étape humaine de décider si le nouveau code convient à la façon dont le système est censé fonctionner. Aucun d'eux ne vous dit si la personne qui merge le PR comprend réellement ce qui a changé, ce qui est une question différente de savoir si le diff est syntaxiquement correct.

Les outils ask-your-codebase existent précisément pour cette raison : le moyen le plus rapide de relire correctement le code généré par l'IA est de pouvoir demander, en langage naturel, « où ce pattern existe-t-il d'autre » ou « qui gère déjà ce cas », avant d'approuver la fusion. Cette question prenait autrefois 20 minutes à un senior engineer avec grep et blame. Ce ne devrait pas être le cas.

Il y a aussi un effet de taille de repo qui vaut la peine d'être nommé. Sur un service de 5 000 lignes, un reviewer peut tenir la plupart du système dans sa tête, donc une fonction plausible se démarque parce qu'elle ne correspond pas au modèle mental du reviewer. Sur un monorepo de 80 000 lignes touché par six équipes, aucun reviewer seul n'a plus ce modèle mental, donc le code plausible passe simplement parce que personne dans la salle n'a le contexte pour remarquer qu'il est mauvais. Plus le repo est grand, plus le goulot de revue dépend des outils au lieu de la mémoire d'un senior engineer.

## Les Juniors Paient Cette Dette en Premier et Plus Vite

Anthhropic a mené une étude contrôlée en janvier 2026, un essai randomisé avec 52 développeurs juniors, et a découvert que ceux qui utilisaient les assistants IA obtenaient un score 17 % plus bas sur les tests de compréhension de code, à peu près deux lettres de note. L'équipe d'ingénierie interne d'Infobip, qui gère un programme de stage depuis 2022 sur 225 stagiaires, a vu le même pattern dans les données longitudinales réelles : les cohortes pré-IA ont grandi en moyenne de 2,50 points en compétence technique auto-évaluée pendant un stage ; les cohortes ère-IA ont grandi de 1,56.

Le mécanisme n'est pas l'utilisation de l'IA elle-même. Deux stagiaires de la cohorte la plus récente d'Infobip ont utilisé l'IA à la même fréquence, avec des résultats opposés. L'un a posé des questions de suivi et a pu expliquer complètement ce que l'IA a produit ; leur croissance a été la plus élevée de la cohorte. L'autre a accepté la sortie avec un examen minimal, a traité comme une boîte noire, et a grandi de zéro. L'outil était identique. La relation envers lui ne l'était pas.

Enregistrer les sessions de pair programming et les walkthroughs d'architecture, et les rendre interrogeables après coup, donne aux juniors quelque chose à relire au lieu de re-poser la même question à quiconque est disponible. Ce ne sera pas un remplaçant au mentorat, mais ça réduit le coût de poser une question une deuxième fois.

![Un ingénieur senior pointant un écran d'ordinateur portable tandis qu'un ingénieur junior se penche pour suivre](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-07/ec3aa0-inline3.webp)

## Ignorez la Recommandation « Interdire l'IA aux Juniors »

Chaque compilation sur ce sujet atterrit finalement à la même recommandation : restreindre l'accès à l'IA pour les ingénieurs juniors jusqu'à ce qu'ils l'aient « mérité ». Sautez celle-là. Elle ne correspond pas à ce que les équipes qui ont réellement mesuré le problème ont trouvé, et elle échange un mode de défaillance contre un autre, tout aussi réel ; les juniors qui ne peuvent pas utiliser les outils que leur équipe livre avec prennent du retard d'une autre manière.

Ce qui a fonctionné pour Infobip à la place était la séquençage, pas l'interdiction : essayez le problème en premier, consultez l'IA en second, pour que l'habitude de la réflexion indépendante se forme avant que l'IA ne devienne le move par défaut. Ils ont ajouté des points de contrôle sans-IA, pas comme une punition mais comme un calibrage, pour que le stagiaire et le mentor sachent où les compétences réelles en sont. Les mentors ont aussi changé leur approche, passant de la revue des pull requests au tracking du processus : qui a demandé quoi, qui a bloqué où, qui a expliqué son propre changement sans aide.

Les scores de satisfaction ont augmenté pendant que la croissance des compétences diminuait, ce qui est le vrai avertissement dans leurs données : si vous trackez uniquement comment les gens se sentent à propos des outils, vous ne verrez pas ça arriver. 20 % des stagiaires dans la cohorte la plus récente d'Infobip ne savaient pas ce qui était attendu d'un ingénieur junior à leur niveau en premier lieu, ce qui rendait l'auto-évaluation proche d'être dénuée de sens. Vous ne pouvez pas mesurer un écart par rapport à un point de référence que personne n'a écrit.

## Ce Qu'on Changerait Réellement Ce Sprint

Commencez par la question du rétro ci-dessus : qui peut expliquer chaque partie du système, à haute voix, maintenant. Cette seule question surface plus de dette cognitive en dix minutes que n'importe quel tableau de bord ne le fera jamais.

Pour la dette de code, gardez l'analyse statique dans la boucle. [L'enquête 2026 de Sonar](https://www.sonarsource.com/blog/how-ai-is-redefining-technical-debt/) montre que 70 % des développeurs l'utilisent déjà, et les équipes qui la font tourner rapportent des résultats significativement meilleurs sur le coût de rework que les équipes qui la sautent. Ce n'est pas une recommandation controversée, c'est juste une que les équipes sautent quand elles se déplacent rapidement parce que la sortie IA avait l'air terminée.

Le travail que l'IA supprime de l'écriture de code ne disparaît pas. Sonar appelle ça le « grand changement de travail » : il réapparaît en aval, dans la gestion de la dette et la correction de la sortie IA. Automatiser les parties récurrentes de ce triage, signaler les PRs obsolètes, acheminer les demandes de revue, chasser les suites, libère le temps des seniors pour la partie qui nécessite réellement un humain : décider si l'équipe comprend ce qu'elle vient de livrer.

Mesurez la trajectoire, pas la satisfaction. Une équipe qui se sent bien à propos de l'IA et ne peut pas expliquer sa propre architecture en six mois n'a pas sauvé du temps. Elle l'a emprunté, à un taux que personne n'a écrit.

## FAQ

### Quelle est la différence entre la dette de code et la dette cognitive ?

La dette de code est un problème d'outils : doublons, patterns incohérents, code techniquement correct mais superflu. La dette cognitive est un problème d'équipe : l'écart entre la vitesse de génération du code et la capacité de l'équipe à le comprendre et l'expliquer. Les outils d'analyse statique traitent la première ; les conversations et la documentation traitent la seconde.

### Pourquoi 88 % des développeurs rapportent un impact négatif de l'IA sur la dette technique ?

Parce que l'IA génère du code plus vite que les équipes ne peuvent le relire et le comprendre. L'enquête 2026 de Sonar montre que 53 % des développeurs affirment que l'IA produit du code qui semble correct mais cache des défauts. C'est le problème mécanique du goulot d'étranglement déplacé de l'écriture à la relecture.

### Comment puis-je mesurer la dette cognitive dans mon équipe ?

La question la plus directe est lors d'un rétro : montrez un diagramme d'architecture et demandez qui peut expliquer chaque boîte. Si une seule personne peut, ou si cette personne est en vacances, vous avez de la dette cognitive. Mesurez aussi le taux de turnover des connaissances : quand quelqu'un quitte l'équipe, combien de contexte perdu ?

### La restriction de l'accès à l'IA pour les juniors aide-t-elle vraiment ?

Non, selon les données réelles d'Infobip. Cela crée un autre mode de défaillance. Ce qui a marché était la séquençage : essayez d'abord seul, consultez l'IA en second, avec des checkpoints réguliers pour calibrer les compétences réelles. La satisfaction augmente mais la croissance des compétences peut décliner — c'est le piège à surveiller.

### Quel est le lien entre taille du repo et dette technique IA ?

Sur un petit service (5 000 lignes), un reviewer peut tenir le système en tête et remarquer les erreurs. Sur un monorepo de 80 000 lignes, personne ne l'a plus en tête, donc le code plausible passe indetecté. Plus le repo est grand, plus vous dépendez des outils d'analyse pour détecter les problèmes.

### Quels outils dois-je utiliser pour tracker la dette technique IA ?

Pour la dette de code : gardez l'analyse statique dans la boucle (Sonar, SonarQube). Pour la dette cognitive : documentez via des wikis internes, enregistrez les walkthroughs d'architecture, et posez régulièrement la question « qui peut expliquer ce système ? » en rétro.