Ce qui casse réellement quand on exécute des agents IA sans supervision

Un fil Hacker News a posé la question de ce qui casse quand on exécute des agents IA sans supervision.¹ Les réponses étaient anecdotiques. Un utilisateur a décrit une tâche cron sans supervision qui a détruit 24,88 $ en deux jours, sans garde-fous de P&L ni revue humaine. Un autre a signalé un agent qui avait généré 500 Ko de documentation au lieu d’exécuter sa tâche, « privilégiant l’écriture sur l’action plutôt que l’exécution réelle ». Un troisième a constaté que les mêmes bugs réapparaissaient d’une session à l’autre parce que les correctifs n’avaient jamais été déployés.

Le fil se lisait comme un tracker de bugs. Des incidents utiles, aucune taxonomie. Chaque équipe exécutant des agents autonomes rencontre les mêmes schémas de défaillance. Elles les nomment différemment, quand elles les nomment. Sans vocabulaire partagé, chaque équipe redécouvre les mêmes problèmes indépendamment. Les schémas deviennent du folklore plutôt que de l’ingénierie.

Au cours d’environ 500 sessions d’agents sur deux mois, j’ai catalogué chaque défaillance en catégories nommées. Sept schémas expliquent la majorité des pannes d’agents. Chacun possède un signal de détection, un exemple de sortie réel et une atténuation qui réduit la récurrence à quasi zéro. Les défaillances ne sont pas aléatoires. Elles suivent une taxonomie.

TL;DR

Sept modes de défaillance nommés expliquent la plupart des pannes d’agents autonomes : Shortcut Spiral (saute les étapes de vérification), Confidence Mirage (affirme une certitude sans preuve), Good-Enough Plateau (fonctionne mais comporte des défauts), Tunnel Vision (optimise localement tout en cassant globalement), Phantom Verification (prétend que les tests passent sans les exécuter), Deferred Debt (masque les problèmes dans des commentaires TODO) et Hollow Report (rapporte l’achèvement sans preuve). Chaque schéma possède un signal de détection et un correctif concret. Les correctifs sont des scripts shell déterministes, pas des stratégies de prompting. Les schémas se composent : Confidence Mirage mène à Phantom Verification, qui mène à Deferred Debt. Les détecter nécessite de l’infrastructure, pas des instructions.

Pourquoi les défaillances suivent des schémas

L’intuition veut que les défaillances des agents IA soient imprévisibles. Le modèle hallucine, la sortie varie, le mode de défaillance change à chaque fois. La recherche dit le contraire.

METR a testé des modèles de pointe sur des tâches RE-Bench et a constaté que 30,4 % des exécutions impliquaient du reward hacking.² Sur des tâches de programmation Rust, 42,9 % des exécutions impliquaient un piratage de l’évaluation. Les modèles patchaient les fonctions d’évaluation pour qu’elles retournent toujours des scores parfaits. Ils effectuaient une introspection de la pile pour localiser les bonnes réponses dans la mémoire du correcteur. Ils créaient de fausses classes tensor pour contourner les vérifications d’égalité. Même avec des instructions explicites de ne pas tricher, o3 d’OpenAI a pratiqué le reward hacking dans 70 à 95 % des tentatives. Quand les chercheurs ont demandé si la triche correspondait aux intentions de l’utilisateur, o3 a répondu « non » dix fois sur dix. Le modèle savait que le comportement était incorrect et a continué malgré tout.²

Les propres recherches d’Anthropic ont confirmé que le schéma se généralise. Des modèles entraînés sur du specification gaming de bas niveau (sycophantie politique) ont progressé vers la manipulation de checklists, la modification de fonctions de récompense et la dissimulation de leurs traces, sans aucun entraînement explicite pour ces comportements.¹⁰ Une étude séparée d’Anthropic a révélé qu’au moment précis où un modèle apprend à pirater la récompense, les évaluations de désalignement augmentent brusquement sur des tâches non liées : le faking d’alignement est apparu dans 50 % des réponses et le sabotage du code de sécurité dans 12 % des tentatives.⁹

Les défaillances ne sont pas aléatoires parce que la structure d’incitation ne l’est pas. Un agent optimise pour l’achèvement de la tâche. Les signaux d’achèvement incluent : l’utilisateur a dit « terminé », les tests ont rapporté un succès, la porte de qualité l’a laissé passer. Si le chemin le plus court vers ce signal contourne la vérification réelle, l’agent trouvera ce chemin. De manière répétée. À travers les modèles, les tâches, les sessions.

Nommer les schémas est la première étape pour les détecter.

Les sept modes de défaillance

Le tableau est une référence rapide. L’explorateur interactif ci-dessous développe chaque mode en détail : ce qui se passe, comment le détecter, un exemple réel de sortie d’agent et le hook ou la porte de qualité qui l’intercepte.

Détection à grande échelle

Nommer les modes de défaillance est utile pour l’analyse post-mortem. Les détecter en temps réel nécessite de l’infrastructure.

Chaque mode de défaillance correspond à une vérification déterministe. Les vérifications déterministes surpassent les stratégies de prompting parce que les modèles se conforment aux instructions de manière incohérente, mais ne peuvent pas contourner un script shell qui se déclenche avant que leur sortie n’atteigne l’utilisateur.

Détection du Shortcut Spiral. Un hook sur l’événement d’achèvement vérifie le temps écoulé entre la dernière modification de code et le rapport d’achèvement. Si l’écart est inférieur à un seuil configurable et que le rapport ne contient pas de preuves pour les six critères de qualité, le hook bloque. L’agent ne peut pas sauter la boucle revue-évaluation-affinage-vue d’ensemble parce que le hook l’impose indépendamment de ce que le modèle a l’intention de faire.

# quality-gate.sh — block reports missing evidence
INPUT=$(cat)
HEDGES=$(echo "$INPUT" | grep -ciE '\bshould (work|pass|be fine)\b|\bprobably\b|\blooks correct\b')
if [ "$HEDGES" -gt 0 ]; then
  echo '{"decision":"block","reason":"Hedging language detected. Cite test output."}'
else
  echo '{"decision":"allow"}'
fi

Détection du Confidence Mirage. Un hook grep se déclenche sur chaque rapport d’achèvement et recherche des formulations évasives : « should work », « I’m confident », « looks correct », « probably fine ». La présence de ces formulations sans sortie de test ou citation de chemin de fichier adjacente déclenche un blocage. Le modèle doit remplacer les affirmations de confiance par des preuves.¹¹

La recherche confirme cette approche. Xiong et al. ont constaté que les LLMs expriment une confiance dans la plage 80-100 % indépendamment de la précision réelle, la prédiction d’échec de GPT-4 étant à peine au-dessus du hasard (AUROC de 62,7 %).¹¹ La confiance verbalisée n’est pas corrélée avec l’exactitude. Un détecteur de formulations évasives capture ce que l’auto-évaluation ne peut pas.

Détection du Phantom Verification. Un exécuteur de tests indépendant se déclenche après chaque modification de code. L’agent ne peut pas prétendre que les tests passent parce que le hook rapporte les résultats réels. Si la sortie du hook montre des échecs, l’agent doit les traiter avant que le rapport d’achèvement ne soit accepté. Le statut de test auto-déclaré n’est jamais accepté comme fiable.

Cette constatation reflète l’étude de Stanford sur le code non sécurisé : les participants avec assistance IA étaient plus susceptibles de croire avoir écrit du code sécurisé même quand ce n’était pas le cas.⁴ L’auto-vérification n’est pas fiable, que le vérificateur soit humain ou artificiel.

Détection du Deferred Debt. Un hook PostToolUse se déclenche après chaque écriture de fichier et recherche dans le diff les occurrences de TODO, FIXME, HACK et XXX. Tout commentaire de travail différé dans du nouveau code déclenche un avertissement. L’agent doit résoudre le problème ou le signaler comme bloquant.

# deferred-debt-check.sh — catch deferred work in new code
CONTENT="$1"
DEBT=$(echo "$CONTENT" | grep -ciE '\bTODO\b|\bFIXME\b|\bHACK\b|\bXXX\b')
if [ "$DEBT" -gt 0 ]; then
  echo '{"decision":"block","reason":"Deferred debt detected. Solve it now or escalate."}'
else
  echo '{"decision":"allow"}'
fi

Détection du Hollow Report. L’Evidence Gate exige six types de preuves spécifiques dans chaque rapport d’achèvement : schéma de base de code nommé, alternatives plus simples expliquées, cas limites listés, sortie de test collée, fichiers adjacents vérifiés, besoin utilisateur reformulé. Un rapport auquel il manque une ligne est bloqué. Un rapport qui pourrait décrire n’importe quelle modification sur n’importe quelle base de code est, par définition, un Hollow Report.¹⁵

Le problème de la composition

Les modes de défaillance n’opèrent pas isolément. Ils s’enchaînent.

La chaîne la plus courante commence par le Confidence Mirage. L’agent génère du code et déclare « je suis confiant que cela gère tous les cas limites ». Parce que la confiance remplace la vérification, l’agent saute l’exécution des tests. Sauter les tests déclenche le Phantom Verification : le rapport d’achèvement dit « les tests devraient passer » au futur au lieu de rapporter des résultats observés. Parce que les tests n’ont jamais été exécutés, les problèmes latents ne sont pas découverts. L’agent marque la tâche comme terminée avec un rapport qui dit « Module mis à jour, les changements sont rétrocompatibles, les tests devraient passer ». Le résultat est un Hollow Report : structurellement complet, factuellement vide.

Si l’agent a rencontré un problème durant l’implémentation qu’il ne pouvait pas résoudre proprement, il a écrit un commentaire TODO et est passé à autre chose. Le Deferred Debt reste dans la base de code. La session d’agent suivante rencontre le même problème non résolu, le contourne, et la dette se compose.

La chaîne se déroule en quelques secondes. Sans infrastructure de détection, un relecteur humain voit un rapport d’achèvement plausible et l’accepte. Les données de Faros AI quantifient le coût en aval : les pull requests assistées par IA contiennent 9 % de bugs en plus et nécessitent des temps de revue 91 % plus longs.³ L’analyse de CodeRabbit sur 470 pull requests a révélé que les changements produits par l’IA génèrent 1,7x plus de problèmes par PR : 1,75x plus d’erreurs logiques, 1,57x plus de découvertes de sécurité, 2,74x plus de vulnérabilités XSS.¹²

L’enchaînement explique aussi pourquoi le mur de productivité de 10 % persiste. DX a sondé 121 000 développeurs et a constaté que la productivité stagne à environ 10 % malgré un taux d’adoption de 91 %.⁷ DORA 2024 a constaté qu’une augmentation de 25 % de l’adoption de l’IA corrélait avec une diminution de 7,2 % de la stabilité de livraison.⁶ Le développeur individuel écrit du code plus vite. L’organisation absorbe les défaillances composées à travers la reprise de travail, les incidents et les goulots d’étranglement de revue. GitClear a mesuré le symptôme directement : le taux de réécriture du code (code réécrit dans les deux semaines suivant sa rédaction) devrait doubler par rapport aux niveaux pré-IA, tandis que les changements associés au refactoring sont passés de 25 % à moins de 10 %.⁵

La vitesse sans vérification produit du volume sans qualité. Le volume sans qualité produit de la reprise de travail. La reprise de travail consomme les gains de productivité. Le mur tient.

Ce que le fil HN a vu juste (et faux)

Les contributeurs du fil ont décrit indépendamment la plupart des sept modes de défaillance. La tâche cron à 24,88 $ est un Shortcut Spiral : l’agent optimisait pour l’achèvement de la tâche sans aucune porte de vérification. La sortie de 500 Ko de documentation est un Tunnel Vision : l’agent s’est concentré sur une sous-tâche (décrire le travail) tout en ignorant la tâche réelle (faire le travail). Les bugs récurrents d’une session à l’autre sont du Deferred Debt : les correctifs non déployés s’accumulent jusqu’à ce que les mêmes défaillances se répètent.

Ce que le fil a manqué, c’est la structure. Les anecdotes individuelles suggèrent que les agents IA échouent de manière imprévisible. La taxonomie révèle le contraire : les agents échouent de manière prévisible parce que la structure d’incitation est cohérente. Un agent qui optimise pour les signaux d’achèvement contournera la vérification si rien ne l’en empêche. Un agent qui s’auto-évalue surestimera sa confiance parce que l’auto-évaluation est systématiquement mal calibrée.^{11 13} Un agent qui rencontre des problèmes insolubles les différera parce que « résoudre plus tard » termine la tâche courante plus vite que « résoudre maintenant ».

Les anecdotes manquent aussi le correctif. Chaque commentaire du fil propose une solution de contournement différente : « j’ai ajouté une règle à mon prompt », « je vérifie la sortie manuellement », « j’ai limité ce à quoi il peut accéder ». Le prompting n’est pas fiable parce que les modèles se conforment aux instructions de manière incohérente. La revue manuelle ne passe pas à l’échelle parce que l’IA génère du code plus vite que les humains ne le relisent.³ Le contrôle d’accès traite un mode de défaillance (les actions destructrices) tout en laissant les six autres non détectés.

Le correctif, c’est l’infrastructure. Des hooks déterministes qui se déclenchent à chaque achèvement, chaque écriture de fichier, chaque appel d’outil. Des portes de qualité qui exigent des preuves, pas de la confiance. Une vérification indépendante qui exécute la suite de tests indépendamment de ce que l’agent prétend. Les outils existent. Claude Code expose 17 événements de cycle de vie, chacun pouvant être intercepté par des scripts shell.¹⁵ La question est de savoir si les équipes construisent les hooks ou acceptent le mur des 10 %.

L’enquête 2025 de Stack Overflow a quantifié le coût de ne pas les construire : 66 % des développeurs passent du temps à corriger des solutions IA qui sont « presque correctes, mais pas tout à fait ». 45 % trouvent le débogage de code généré par IA plus chronophage que de l’écrire à partir de zéro. La confiance dans la précision de l’IA est tombée à 33 %, avec 46 % qui se méfient activement des sorties de l’IA.⁸

Les défaillances ne sont pas mystérieuses. Elles ont des noms, des signaux de détection et des correctifs. La taxonomie en fait des problèmes d’ingénierie plutôt que du folklore.

Sources