Votre agent écrit plus vite que vous ne pouvez lire

Mardi dernier, mon agent de codage autonome a terminé un refactoring de 47 fichiers en 9 minutes. Les tests passaient. Le linting passait. Les portes de qualité n’ont trouvé aucune violation. J’ai fusionné la PR, déployé et suis passé à autre chose. Trois jours plus tard, un collègue a demandé pourquoi la logique de retry dans le service de paiement était passée d’un backoff exponentiel à un polling à intervalle fixe. Je ne savais pas que cela avait changé. Le message de commit de l’agent disait « refactor: standardize retry patterns across services ». La modification était techniquement correcte. Je n’avais jamais lu la ligne 847 du fichier 31.

Cet écart entre ce qui a été livré et ce que j’ai compris, c’est de la dette cognitive.

TL;DR

Cinq équipes de recherche indépendantes ont publié sur le même problème structurel en une semaine : les agents de codage produisent des résultats plus vite que les développeurs ne peuvent les vérifier, les comprendre et les maintenir. Margaret-Anne Storey a nommé ce schéma « dette cognitive ». Des chercheurs de Microsoft, de l’ETH Zurich et de plusieurs universités construisent des systèmes pour détecter les comportements indésirables des agents, rendre les appels d’outils transactionnels et évaluer comment les agents apprennent par l’interaction. Cette convergence est importante car elle signale que la communauté de recherche rattrape un problème que les praticiens résolvaient avec des portes de qualité ad hoc. Le problème de fiabilité des agents a désormais un nom, une taxonomie et cinq approches concurrentes. Ci-dessous : la recherche, comment détecter la dette cognitive dans votre propre flux de travail, et une intervention minimale viable que vous pouvez implémenter dès aujourd’hui.

Cinq articles, une semaine, un problème

Entre le 15 et le 21 février 2026, cinq groupes indépendants ont publié des travaux abordant le même défaut structurel des agents de codage IA. Aucun ne citait les autres. Chacun abordait le problème sous un angle différent. Tous convergeaient vers la même conclusion : le goulot d’étranglement dans le développement assisté par agent n’est plus la qualité du code. Le goulot d’étranglement, c’est la compréhension humaine.

Margaret-Anne Storey a articulé le concept de « dette cognitive » pour décrire ce qui s’accumule lorsque les agents produisent du code propre, testé et bien structuré pendant que les développeurs perdent le fil de ce que le code fait réellement.¹ La dette technique vit dans le code. La dette cognitive vit dans la tête du développeur. Le cadrage de Storey déplace la question de la fiabilité des agents de « est-ce que le code fonctionne ? » à « est-ce que le développeur comprend le code ? »

Nanda et al. chez Microsoft ont publié Wink, un système de détection et de récupération automatique des comportements indésirables des agents de codage.² Leur taxonomie identifie trois modes de défaillance : la déviation d’instruction (l’agent fait quelque chose de différent de ce que vous avez demandé), les boucles répétitives (l’agent réessaie la même approche échouée de manière répétée) et le mauvais usage des outils (l’agent appelle le mauvais outil ou passe les mauvais arguments). Wink surveille le comportement de l’agent en temps réel et intervient avant que le comportement indésirable ne s’aggrave.

Mohammadi et al. à l’ETH Zurich ont introduit Atomix, un runtime qui encapsule les appels d’outils des agents dans des transactions.³ Lorsque le plan en plusieurs étapes d’un agent échoue en cours de route, Atomix annule les effets de bord. L’idée clé : les agents agissent sur des systèmes externes (bases de données, API, systèmes de fichiers), et ces actions ont des conséquences que l’agent ne peut pas annuler sans une infrastructure explicite de rollback.

Hallinan et al. ont créé OpaqueToolsBench, un benchmark mesurant comment les agents apprennent le comportement des outils par l’interaction plutôt que par la documentation.⁴ Les outils du monde réel sont mal documentés. Le benchmark teste si les agents peuvent découvrir les modes de défaillance, les bonnes pratiques et les cas limites par essai et erreur. Le résultat : les agents qui explorent le comportement des outils de manière indépendante produisent de meilleurs résultats que les agents auxquels on fournit une documentation parfaite qu’ils ne vérifient jamais.

Deng et al. ont évalué 28 systèmes de test de pénétration basés sur des LLM et ont identifié deux catégories distinctes de défaillance.⁵ Les défaillances de Type A proviennent de capacités manquantes (mauvais outils, mauvais prompts) que l’ingénierie corrige facilement. Les défaillances de Type B persistent indépendamment de l’outillage car l’agent manque du jugement nécessaire pour évaluer ses propres conclusions. Le Type B est le problème de dette cognitive exprimé comme un risque de sécurité : l’agent trouve six vulnérabilités sur sept mais rapporte avec assurance que le système est sécurisé.

La convergence compte plus que n’importe quel article isolé

Un article sur la fiabilité des agents est intéressant. Cinq articles en une semaine provenant d’équipes sans lien entre elles, c’est un signal. La communauté de recherche arrive indépendamment à la même conclusion que les praticiens découvraient à travers des défaillances en production.

J’ai construit le système de qualité Jiro à partir de mai 2025. Le système applique une boucle de qualité en 7 étapes, une porte d’évaluation à 6 critères et 7 modes de défaillance nommés qui correspondent directement aux schémas décrits dans ces articles :

La chronologie est importante. Neuf mois de débogage par essai et erreur en production, construisant des portes de qualité une défaillance à la fois, ont abouti à une architecture que cinq articles de recherche formalisent maintenant indépendamment. Les problèmes structurels sont réels. Les solutions ad hoc fonctionnent. La recherche rattrape son retard avec des cadres, des taxonomies et des benchmarks qui rendent les solutions reproductibles.

Les trois lois de la dette cognitive

Le cadrage de Storey cristallise ce que j’ai observé au cours de 11 mois de développement avec des agents autonomes. Trois schémas se vérifient indépendamment du modèle, de l’outillage ou du domaine :

1. La dette cognitive se compose avec la vélocité. Mon agent produit en moyenne 140 à 200 lignes de modifications de code significatives par minute lors d’une session de refactoring (mesuré à partir des diffs git, hors espaces blancs). Un développeur humain concentré produit environ 20 à 40 lignes par minute pendant un codage actif.⁸ La boucle Ralph qui fait tourner Claude à 10 $/heure ne produit pas 5 fois la dette cognitive d’un développeur humain. Elle en produit bien davantage, car la vitesse de frappe du développeur humain est couplée à sa vitesse de réflexion. La vitesse de production de l’agent n’a aucun couplage avec votre vitesse de compréhension. La production double ; la compréhension reste constante ; la dette se compose.

2. Réussir les tests n’élimine pas la dette cognitive. Chaque article de cette semaine traite le passage des tests comme un signal nécessaire mais insuffisant. Les défaillances de Type B de Deng et al. passent toutes les vérifications automatisées. La taxonomie des comportements indésirables de Wink inclut des agents qui produisent du code fonctionnel ne correspondant pas à l’intention. Ma porte d’évaluation exige six critères au-delà de « les tests passent », et le critère le plus difficile à vérifier reste « est-ce que le développeur comprend ce qui a changé ? »⁶

Voici un exemple concret. Mon agent a refactorisé une requête de base de données pour utiliser une CTE (Common Table Expression) au lieu d’une sous-requête. Les deux approches retournaient des résultats identiques. Les tests passaient. La version CTE était 3 fois plus lente sur notre jeu de données parce que le planificateur de requêtes ne pouvait pas pousser les prédicats dans la CTE. Je l’ai découvert lors d’une vérification routinière avec EXPLAIN ANALYZE deux semaines plus tard. Les tests de l’agent vérifiaient la correction. Rien dans la suite de tests ne vérifiait les caractéristiques de performance. La dette cognitive n’était pas du « mauvais code ». La dette cognitive était « je ne savais pas que le plan d’exécution avait changé ».

3. La dette cognitive est invisible jusqu’à ce qu’elle ne le soit plus. La dette technique s’annonce par des builds lents, des tests instables et des conflits de fusion. La dette cognitive est silencieuse jusqu’à ce que quelqu’un demande « pourquoi le service de paiement utilise-t-il du polling à intervalle fixe ? » et que personne ne le sache. La contribution de Storey est de donner un nom au problème invisible.

Cinq signes d’alerte que vous accumulez de la dette cognitive

Avant de pouvoir résoudre le problème, vous devez le voir. Ces cinq signaux apparaissent avant les incidents en production :

1. Vous ne pouvez pas expliquer la dernière PR de l’agent sans la relire. Ouvrez la PR la plus récente créée par votre agent. Sans regarder le diff, décrivez ce qui a changé et pourquoi. Si vous ne pouvez pas, vous avez fusionné du code que vous ne comprenez pas. Je suis cela en ajoutant une « vérification de résumé » en une ligne à mon processus de revue : avant d’approuver, j’écris une explication en une phrase dans le commentaire de la PR. Si je ne peux pas écrire cette phrase, je n’ai pas assez examiné.

2. Votre git log --stat montre des sessions avec plus de 20 fichiers modifiés. Exécutez ceci maintenant :

git log --stat --since="1 week ago" --author="$(git config user.name)" | \
  awk '/files? changed/ {files+=$1} END {print files, "files changed this week"}'

Comparez le nombre au nombre de ces fichiers que vous pourriez décrire de mémoire. L’écart est votre arriéré de dette cognitive.

3. Vous relisez les diffs en défilant, pas en lisant. Défiler, c’est de la reconnaissance de motifs : « ça a l’air correct ». Lire, c’est comprendre : « ceci change l’intervalle de retry d’exponentiel à fixe, ce qui signifie que le service en aval verra un schéma de trafic différent ». Si votre revue prend moins d’une minute pour 100 lignes de diff, vous défilez.

4. Vos messages de commit décrivent le QUOI, pas le POURQUOI. « Refactor: standardize retry patterns » décrit ce que l’agent a fait. « Fix: exponential backoff caused thundering herd after service restart » décrit pourquoi. Si les messages de commit de votre agent ressemblent au premier exemple et que vous ne les réécrivez pas, personne (y compris votre futur vous) ne connaîtra le raisonnement derrière la modification.

5. Vous vous sentez productif mais ne pouvez pas lister ce qui a changé. À la fin d’une journée d’utilisation d’un agent, notez de mémoire les trois modifications de code les plus significatives. Si vous avez du mal, l’agent était productif. Vous ne l’étiez pas. La dette s’est accumulée pendant que vous vous sentiez efficace.

Commencez ici : le protocole des trois fichiers

Vous n’avez pas besoin de 95 hooks, de 7 modes de défaillance nommés ni d’un système de délibération multi-agents pour commencer à gérer la dette cognitive. Commencez par une règle et construisez à partir de là.

La règle : Après chaque session d’agent, lisez entièrement trois fichiers. Pas survoler. Pas défiler. Lisez chaque ligne des trois fichiers avec les plus gros diffs.

Pourquoi trois ? Parce que trois fichiers est réalisable (vous le ferez vraiment) et diagnostique (vous découvrirez si les modifications de l’agent correspondent à votre modèle mental). S’ils correspondent, votre dette est gérable. S’ils ne correspondent pas, vous avez un indicateur avancé que le reste des modifications de la session diverge également de votre compréhension.

Mise en œuvre

Après que votre agent a terminé, exécutez :

# Show the 3 files with the largest diffs from the last commit
git diff HEAD~1 --stat | sort -t'|' -k2 -rn | head -3

Puis lisez ces trois fichiers. Pas le diff. Le fichier complet. Le contexte compte : le diff montre ce qui a changé, mais le fichier montre ce que la modification signifie en contexte.

Parcours d’évolution

Une fois que le protocole des trois fichiers est devenu une habitude (environ une semaine), ajoutez une couche à la fois :

Chaque couche élimine une catégorie spécifique de dette cognitive. La lecture des trois fichiers détecte les lacunes de compréhension. Le résumé de PR détecte le désalignement d’intention. La vérification des requêtes détecte l’incident de CTE que j’ai décrit ci-dessus. La réécriture des commits préserve le raisonnement qui s’évaporerait autrement. Les modes de défaillance nommés préviennent les erreurs répétées.

Ce que la recherche propose (et ce qui fonctionne réellement)

Les cinq articles pointent vers quatre interventions structurelles. Les quatre existent sous une forme ou une autre dans ma chaîne d’outils Claude Code, construite avant la publication des articles, validée par les mêmes schémas que les articles décrivent.

Vérification indépendante. Wink surveille le comportement de l’agent par rapport à l’intention déclarée. Ma boucle de qualité exige de relire chaque ligne écrite, interdisant explicitement le mode de défaillance Phantom Verification (affirmer que les tests passent sans les exécuter dans la session en cours).⁷ La solution est structurelle : la vérification doit être effectuée par un processus différent de celui qui a produit le résultat.

En pratique, j’applique cela avec un hook post-session qui exécute la suite de tests indépendamment plutôt que de faire confiance au rapport de l’agent :

# Post-session verification hook (simplified)
# Agent says "tests pass" — verify independently
cd "$PROJECT_DIR"
test_output=$(python -m pytest --tb=short -q 2>&1)
exit_code=$?

if [ $exit_code -ne 0 ]; then
  echo "AGENT CLAIMED TESTS PASS. INDEPENDENT RUN FAILED:"
  echo "$test_output"
  exit 1
fi

L’agent a rapporté « tous les tests passent » et le pensait sincèrement. L’exécution indépendante détecte les différences d’environnement, les fixtures manquantes et les tests qui passent par effets de bord plutôt que par correction. En 11 mois d’exécution de ce hook, il a détecté 23 faux positifs dans les auto-rapports de l’agent.⁹

Frontières transactionnelles. Atomix encapsule les appels d’outils dans des transactions avec rollback. Mon système de délibération soumet les actions irréversibles au consensus de plusieurs agents indépendants. Les deux approches ajoutent de la friction à l’exécution de l’agent aux points où les erreurs sont les plus coûteuses. La version pratique pour la plupart des équipes : exiger une étape d’approbation manuelle avant toute migration de base de données, tout déploiement ou tout appel d’API externe initié par l’agent.

Taxonomies comportementales. Les trois modes de défaillance de Wink (déviation, boucles, mauvais usage des outils) et mes sept modes de défaillance nommés (Shortcut Spiral, Confidence Mirage, Good-Enough Plateau, Tunnel Vision, Phantom Verification, Deferred Debt, Hollow Report) servent le même objectif : rendre visibles les défaillances invisibles en leur donnant des noms.⁷ Un développeur qui peut dire « l’agent exhibe du Tunnel Vision » peut intervenir avant que la dette ne se compose. Commencez par trois noms pour les trois erreurs d’agent les plus courantes de votre équipe. Les noms comptent plus que la taxonomie.

Engagement sélectif. La distinction Type A/Type B de Deng et al. et le module de confiance de mon système de délibération encodent tous deux la même idée : chaque sortie d’agent ne mérite pas le même niveau de scrutin. Une heuristique utile :

La question à laquelle personne n’a encore répondu

Les cinq articles décrivent le problème. Wink, Atomix et OpaqueToolsBench proposent des solutions partielles. Aucun ne répond à la question la plus importante : comment mesure-t-on la dette cognitive ?

La dette technique a ses indicateurs : complexité cyclomatique, couverture de tests, ancienneté des dépendances. La dette cognitive n’a pas de métrique équivalente. Ma porte d’évaluation demande « est-ce que le développeur comprend ce qui a changé ? » mais fait respecter la réponse par auto-déclaration, ce qui est exactement la méthode de vérification que le mode de défaillance Confidence Mirage exploite.

Une métrique utile suivrait le delta entre ce que l’agent a modifié et ce que le développeur peut expliquer. Le nombre de fichiers est un indicateur grossier. La complexité du diff (pas le nombre de lignes, mais la densité de changements sémantiques) est meilleure. La métrique idéale serait corrélée avec la probabilité d’un incident en production causé par une incompréhension du code généré par l’agent. Personne n’a encore construit cette métrique. Le calculateur interactif ci-dessus approxime le ratio, mais un ratio n’est pas un seuil. Nous ne savons pas encore où se situe la ligne entre « dette gérable » et « incident en attente ».

Tant que personne ne construit cette métrique, la réponse pratique est la même que celle qui précède les agents IA : lisez le code. La vélocité de l’agent rend la lecture de chaque ligne impraticable. Le protocole des trois fichiers, les taxonomies comportementales et les frontières transactionnelles réduisent le volume de code nécessitant une attention humaine. La dette cognitive qui reste après ces filtres est la dette qui compte.

Points clés à retenir

• Cinq groupes de recherche indépendants ont convergé sur le même problème en une semaine. Lorsque des équipes sans lien arrivent à la même conclusion simultanément, le problème sous-jacent est structurel, pas théorique.
• La dette cognitive est le goulot d’étranglement, pas la qualité du code. Les agents produisent du code correct plus vite que les développeurs ne peuvent le comprendre. Les tests, les linters et les portes de qualité réduisent le problème mais ne peuvent pas l’éliminer.
• Commencez par le protocole des trois fichiers. Après chaque session d’agent, lisez entièrement les trois fichiers avec les plus gros diffs. Ajoutez des couches supplémentaires (résumés de PR, vérifications de requêtes, réécritures de commits, modes de défaillance nommés) une par semaine.
• Nommez les modes de défaillance. La taxonomie de Wink et les modes de défaillance nommés de Jiro servent le même objectif : rendre visibles les problèmes invisibles. Si votre système d’agent n’a pas de noms pour ses schémas de défaillance, vous ne pouvez pas les détecter.
• Ajoutez de la friction aux frontières irréversibles. Les appels d’outils transactionnels (Atomix) et le consensus multi-agents (délibération) ajoutent tous deux un coût aux points où les erreurs sont les plus chères. Ce coût en vaut la peine.

FAQ

Références