La dette de compréhension : le coût caché que personne ne mesure

Le couplage qui s’est rompu

Depuis que le logiciel existe, écrire du code et comprendre du code étaient la même activité. Vous tapiez une fonction, vous compreniez ce qu’elle faisait. Vous construisiez un module, vous pouviez l’expliquer. Écrire, c’était comprendre.

L’IA a rompu ce couplage.

Vous pouvez maintenant accepter une fonction de 200 lignes en 30 secondes, la parcourir, regarder les tests passer, et la déployer. Le code fonctionne. Mais l’écart entre « code qui fonctionne » et « code que je comprends » grandit à chaque suggestion acceptée. Cet écart a un nom : la dette de compréhension.

La dette technique vit dans le code. La dette de compréhension vit dans l’esprit des développeurs. C’est la distance croissante entre ce que votre codebase fait et ce que votre équipe comprend réellement.

Et contrairement à la dette technique, personne ne la suit.

Le problème de l’effet composé

Les mathématiques sont simples et impitoyables.

Avant l’IA, une équipe livre 5 fonctionnalités par mois. La compréhension croît à peu près au même rythme : 5 fonctionnalités comprises par mois. Le système est en équilibre. Ce que l’équipe construit, l’équipe le connaît.

Avec le développement assisté par l’IA, la même équipe livre 12 fonctionnalités par mois. Mais la compréhension croît toujours à 5 par mois. Le cerveau humain n’est pas devenu plus rapide pour comprendre le code simplement parce que l’IA est devenue plus rapide pour le générer.

Cela laisse un écart de 7 fonctionnalités par mois que l’équipe a livrées mais ne comprend pas en profondeur.

Sur 6 mois, ce sont 42 fonctionnalités que votre équipe ne peut pas expliquer, déboguer ou étendre avec confiance sans recourir à nouveau à l’IA. Sur un an, 84. La codebase grandit. La compréhension de l’équipe ne suit pas le rythme. Et l’écart se compose, car chaque nouvelle fonctionnalité qui touche du code que vous ne comprenez pas rend la suivante plus difficile à raisonner.

Ce n’est pas théorique. C’est la réalité quotidienne des équipes qui avancent à la vitesse de l’IA sans systèmes de vérification.

Les preuves

Les données confirment ce que les mathématiques prédisent.

Les revues de pull requests avec beaucoup de code IA prennent 26% plus longtemps que celles du code écrit par des humains. La raison n’est pas que le code IA est plus long : c’est que le code IA utilise des patterns inhabituels qui augmentent la charge cognitive pour les relecteurs. Quand vous n’avez pas écrit le code et que l’IA l’a assemblé à partir de patterns issus de ses données d’entraînement, chaque fonction demande plus d’effort pour être validée.

Les relecteurs rapportent une confiance réduite dans la validation de logique qu’ils n’ont pas écrite. C’est la dette de compréhension qui se manifeste en temps réel : la personne qui relit le code ne peut pas le vérifier complètement parce qu’elle ne comprend pas entièrement l’approche choisie par l’IA.

Pendant ce temps, 76% des développeurs sont dans ce que Qodo appelle la « zone rouge » : confrontés à des hallucinations fréquentes combinées à une faible confiance dans le code qu’ils livrent. Seuls 3,8% des développeurs ont atteint à la fois un faible taux d’hallucinations et une haute confiance. Ce n’est pas une erreur d’arrondi. C’est un marché où 96 développeurs sur 100 accumulent de la dette de compréhension plus vite qu’ils ne la remboursent.

Pourquoi les revues ne peuvent pas vous sauver

La revue de code est la défense traditionnelle contre le code que vous ne comprenez pas. Quelqu’un d’autre le lit, détecte les erreurs, et tout le monde apprend.

Mais la revue de code suppose que le relecteur peut comprendre le code. Quand l’IA génère des fonctions utilisant des patterns que le relecteur n’a jamais vus, assemblés à partir de données d’entraînement couvrant des millions de repositories, le relecteur fait face au même écart de compréhension que l’auteur. Ils revoient du code que ni l’un ni l’autre ne comprend complètement.

L’augmentation de 26% du temps de revue n’est pas le signe de développeurs rigoureux. C’est le signe de développeurs en difficulté. Et des revues laborieuses produisent un résultat prévisible : les relecteurs finissent par valider sans vérifier du code qu’ils ne peuvent pas pleinement valider, parce que l’alternative serait de bloquer indéfiniment chaque PR assistée par l’IA.

Les revues ne résolvent pas la dette de compréhension. Elles l’exposent, puis cèdent sous son poids.

La solution

Simon Willison propose un test d’une simplicité trompeuse : « Puis-je expliquer chaque ligne à quelqu’un d’autre ? »

Si la réponse est non, vous avez de la dette de compréhension. Peu importe que les tests passent. Peu importe que la fonctionnalité fonctionne. Si vous ne pouvez pas expliquer le code, vous ne pouvez pas le maintenir. Vous êtes à un bug inattendu de vous retrouver à fixer de la logique que vous ne comprenez pas, sous pression temporelle, en regrettant de ne pas avoir pris le temps de l’apprendre quand c’était encore frais.

La Vérification Paranoïaque force la compréhension par conception. Vous ne pouvez pas vérifier du code depuis plusieurs angles (comportemental, structurel, sécurité, performance) sans comprendre ce que fait le code et pourquoi il le fait de cette manière. La vérification exige la compréhension. Ce n’est pas un effet secondaire. C’est le but.

Chaque prompt de vérification qui demande « explique pourquoi cette approche a été choisie » ou « identifie quelles hypothèses ce code fait » rembourse la dette de compréhension en temps réel. Le développeur qui vérifie est le développeur qui comprend. Le développeur qui comprend est celui qui peut déboguer, étendre et maintenir le code dans six mois, quand la session IA qui l’a généré est depuis longtemps terminée.

Le choix est simple : payez le coût de compréhension maintenant, pendant la vérification, quand le contexte est frais et le coût est faible. Ou payez-le plus tard, pendant un incident, quand le contexte a disparu et le coût est catastrophique.

Faites le Diagnostic pour découvrir où en est votre dette de compréhension, et si votre workflow actuel l’aggrave.

Sources : CodeRabbit AI Code Quality Report 2025 · Mathieu Kessler, “The Hidden Cost of AI Code” (DEV) · Allstacks, “AI’s Impact on Developer Productivity” · Qodo State of AI Code Quality 2025