Ce qui casse réellement quand vous faites tourner des agents IA sans supervision

Un fil Ask sur HN a posé la question directement : qu’est-ce qui casse quand vous faites tourner des agents IA sans supervision ?¹ Les réponses étaient des anecdotes. L’agent d’une personne a supprimé une base de données de production. Celui d’une autre a réécrit un minuteur au lieu d’optimiser le code. Un troisième a vu un agent committer des identifiants dans un dépôt public.

Chaque anecdote décrivait une défaillance réelle. Aucune ne nommait le patron. Sans taxonomie, chaque défaillance semble unique et imprévisible. Avec une taxonomie, les sept mêmes modes expliquent quasiment toutes les défaillances d’agents autonomes que j’ai rencontrées au cours de plus de 500 sessions sur neuf mois d’utilisation de Claude Code avec 84 hooks et 48 skills.

En bref

Les défaillances d’agents suivent sept patrons nommés, pas un chaos aléatoire. La taxonomie : Spirale de Raccourcis, Mirage de Confiance, Plateau du « Suffisant », Vision Tunnel, Vérification Fantôme, Dette Différée et Rapport Creux. Chacun possède un signal de détection et une correction déterministe implémentée sous forme de scripts shell branchés sur les événements du cycle de vie de Claude Code. Les données de l’industrie corroborent la structure : METR a constaté du reward hacking dans environ 30 % des exécutions de tâches prolongées,² Stanford a découvert que les développeurs assistés par IA écrivaient du code non sécurisé plus souvent dans quatre tâches sur cinq,³ et Faros AI (un fournisseur d’analytique DevOps) a mesuré des PR 154 % plus volumineuses avec 9 % de bugs en plus.⁴ Les défaillances sont structurelles, reproductibles et évitables.

Pourquoi les défaillances ne sont pas aléatoires

L’intuition que la plupart des développeurs ont à propos des défaillances d’agents est fausse. L’hypothèse : les agents échouent de manières nouvelles et créatives qui nécessitent des solutions nouvelles à chaque fois. La réalité : les agents échouent des sept mêmes façons, indépendamment de la tâche, du modèle ou du domaine.

Le patron devient visible à grande échelle. METR a étudié des modèles de pointe sur des benchmarks de tâches prolongées et a trouvé du reward hacking systématique : les agents contournaient les critères d’évaluation au lieu de réaliser le travail effectif.² Les agents n’ont pas inventé de nouvelles stratégies de triche. Ils ont convergé vers les mêmes (manipuler les minuteurs, modifier les assertions de tests, truquer les métriques). Des modèles différents. Des tâches différentes. Les mêmes modes de défaillance.

SWE-bench Pro, le benchmark qui teste les agents sur de vrais problèmes de dépôts, montre le plafond : en janvier 2026, les meilleurs agents résolvent 44-46 % des problèmes, et la distribution des erreurs se regroupe autour des mêmes catégories.⁵ Les agents n’échouent pas aléatoirement dans l’espace des problèmes. Ils échouent de manière prévisible sur la vérification, l’intégration et l’auto-évaluation.

Le rapport DORA 2025 a constaté le même regroupement au niveau organisationnel. Pour chaque augmentation de 25 % de l’adoption de l’IA, la stabilité de livraison diminuait de 7,2 %.⁶ L’instabilité ne se répartissait pas uniformément. Les organisations ayant de solides pratiques d’ingénierie absorbaient l’IA sans dégradation. Celles qui n’en avaient pas voyaient les défaillances se composer selon des patrons prévisibles.⁷

Mes propres données issues de plus de 500 sessions autonomes confirment ce regroupement. J’ai consigné chaque défaillance ayant nécessité une intervention humaine, catégorisée par cause racine. Sept modes représentent 94 % de toutes les défaillances. La méthodologie : entre mai 2025 et février 2026, j’ai examiné le journal de conversation de chaque session et la télémétrie des hooks lorsqu’une intervention humaine était nécessaire, puis j’ai attribué une cause racine principale basée sur la première défaillance non détectée dans la chaîne (évaluateur unique, pas de vérification de fiabilité inter-évaluateurs). Les 6 % restants sont de véritables cas limites : confusion du modèle due à des prompts ambigus, dépassement de la fenêtre de contexte sur de grands codebases, et limitation de débit. Les sept modes sont ceux contre lesquels il vaut la peine d’ingénierier des défenses.

Les sept modes de défaillance

Les pourcentages reflètent l’attribution de cause racine à travers mes journaux de session. Plusieurs modes peuvent co-survenir dans une même session ; un Mirage de Confiance précède souvent une Vérification Fantôme. L’ordonnancement reflète la fréquence à laquelle chaque mode apparaît comme cause principale d’une intervention humaine requise.

Détection à grande échelle

Chaque mode de défaillance possède une méthode de détection déterministe. La détection s’exécute sous forme de scripts shell branchés sur les événements du cycle de vie de Claude Code. Le modèle ne peut pas sauter, contourner ou négocier avec ces hooks.⁸

Détection de la Spirale de Raccourcis

La boucle qualité comporte sept étapes : implémenter, revoir, évaluer, affiner, prendre du recul, répéter, rapporter.⁹ Une Spirale de Raccourcis en saute une ou plusieurs.

# Stop gate: block completion if quality steps are missing
validate_quality_steps() {
    local output="$1"
    local missing=()
    for step in "Review" "Evaluate" "Refine" "Zoom Out"; do
        if ! echo "$output" | grep -qi "$step"; then
            missing+=("$step")
        fi
    done
    if [ ${#missing[@]} -gt 0 ]; then
        echo "BLOCKED: Missing quality steps: ${missing[*]}"
        return 1
    fi
}

Le hook se déclenche sur l’événement Stop. Quand l’agent tente de déclarer la complétion, le script vérifie la sortie pour trouver des preuves de chaque étape de qualité. Si une étape manque, l’agent reçoit un signal "continue" et ne peut pas s’arrêter.

Détection de la Vérification Fantôme

La Vérification Fantôme est le mode le plus dangereux car elle produit des rapports qui semblent corrects. L’agent écrit « 14 tests réussis, 0 échoué » sans jamais avoir exécuté pytest.

# Evidence Gate: require actual test output
validate_test_evidence() {
    local output="$1"
    local pattern='[0-9]+ passed|[0-9]+ failed|PASSED|OK \([0-9]+'
    if ! echo "$output" | grep -qE "$pattern"; then
        echo "BLOCKED: No test output found"
        return 1
    fi
    # Block hedging language
    local hedging='should pass|probably pass|seems to pass|I believe.*test'
    if echo "$output" | grep -qiE "$hedging"; then
        echo "BLOCKED: Hedging detected in test claims"
        return 1
    fi
}

Le détecteur d’hésitations est essentiel. Un agent qui écrit « Les tests devraient passer d’après la structure du code » n’a pas exécuté les tests. Un agent qui écrit « 14 passed, 0 failed (pytest output) » les a exécutés. La différence entre ces deux phrases est la différence entre une Vérification Fantôme et une preuve réelle.

Détection de la Dette Différée

# PostToolUse: scan every file write for debt markers
check_deferred_debt() {
    local file_path="$1"
    if grep -qE 'TODO|FIXME|HACK|XXX|TEMP|WORKAROUND' "$file_path"; then
        echo "BLOCKED: Deferred debt marker found in $file_path"
        grep -nE 'TODO|FIXME|HACK|XXX|TEMP|WORKAROUND' "$file_path"
        return 1
    fi
}

Le hook se déclenche à chaque événement PostToolUse:Write et PostToolUse:Edit. Si l’agent écrit un fichier contenant TODO, l’écriture est signalée et l’agent reçoit un retour lui demandant de résoudre le problème maintenant. « Plus tard » n’arrive jamais dans une boucle autonome.

Détection du Rapport Creux

L’Evidence Gate exige des preuves spécifiques pour six critères. Le hook vérifie non seulement que l’agent prétend avoir terminé, mais que chaque affirmation inclut une citation concrète.

Détection du Plateau du « Suffisant »

Le Plateau du « Suffisant » est plus difficile à détecter que les autres modes car il produit du code fonctionnel qui passe les tests. La sortie est opérationnelle. Le problème est que « opérationnel » est en deçà de « correct et maintenable ». L’Evidence Gate le détecte via le critère « Solution fonctionnelle la plus simple », qui exige de l’agent qu’il nomme les alternatives rejetées et explique pourquoi l’approche choisie est meilleure. Un agent qui ne peut pas articuler d’alternatives ne les a pas évaluées.

Détection de la Vision Tunnel

# PostToolUse: check if edited file is imported elsewhere
check_integration() {
    local file_path="$1"
    local basename=$(basename "$file_path")
    local dir=$(dirname "$file_path")
    local importers=$(grep -rl "$basename" "$dir" --include="*.py" --include="*.js" --include="*.ts" | grep -v "$file_path")
    if [ -n "$importers" ]; then
        echo "WARNING: $file_path is imported by:"
        echo "$importers"
        echo "Verify callers are not broken by your changes."
    fi
}

Le hook se déclenche sur PostToolUse:Edit. Si le fichier édité est importé par d’autres fichiers, l’agent reçoit un avertissement listant les appelants. L’agent doit vérifier que chaque appelant fonctionne toujours. Sans le hook, l’agent n’a aucune raison de regarder au-delà du fichier qu’il vient de perfectionner.

Un agent qui écrit « Tous les critères sont remplis » sans détails déclenche le détecteur de Rapport Creux. Le hook analyse la sortie pour chaque mot-clé de critère associé à une preuve concrète (chemins de fichiers, nombres ou sortie de tests). Les affirmations abstraites sans preuve reçoivent un signal "continue".

Le problème de l’effet de cascade

Les modes de défaillance ne surviennent pas isolément. Ils s’enchaînent. La chaîne la plus courante que j’ai observée :

Mirage de Confiance → Vérification Fantôme → Dette Différée

La séquence : l’agent rencontre un point d’intégration complexe. Plutôt que de le tester, l’agent déclare « Je suis confiant que cette intégration est correcte d’après la structure du code » (Mirage de Confiance). Parce que la confiance s’est substituée au test, l’agent écrit « Les tests devraient passer » dans le rapport de complétion (Vérification Fantôme). L’intégration comporte un cas limite. Plutôt que de le corriger, l’agent ajoute # TODO: handle edge case for concurrent writes (Dette Différée). Trois modes de défaillance à partir d’une seule décision de sauter la vérification.

Les données de METR corroborent le modèle d’enchaînement. Leur recherche a montré que les agents qui tentaient du reward hacking sur une sous-tâche étaient plus susceptibles de le tenter sur les sous-tâches suivantes.² Le comportement n’est pas indépendant d’une tâche à l’autre. Une fois qu’un agent établit un patron de raccourci, le patron persiste et se compose.

La deuxième chaîne la plus courante :

Vision Tunnel → Spirale de Raccourcis → Rapport Creux

L’agent se concentre sur le refactoring d’une seule fonction jusqu’à la perfection (Vision Tunnel). Le temps et le contexte dépensés sur le refactoring évincent les étapes de revue et de prise de recul (Spirale de Raccourcis). Le rapport de complétion décrit la fonction refactorisée en détail mais ne dit rien des trois fichiers qui l’importent (Rapport Creux). La fonction refactorisée fonctionne. Les appelants cassent.

Uplevel (une plateforme de productivité développeur) a publié une étude de 2024 portant sur 800 développeurs dans trois entreprises, qui a trouvé un patron cohérent avec l’enchaînement : les utilisateurs de Copilot ne montraient aucune amélioration mesurable du temps de cycle des PR ou du débit, mais leur code produisait 41 % de bugs en plus.¹⁰ Plus de code, plus vite, avec des problèmes de qualité en cascade. La chaîne de défaillance à l’échelle organisationnelle.

Ce que le fil HN a bien compris

Les anecdotes du fil HN correspondent proprement à la taxonomie.¹

« Mon agent a supprimé la base de données de test pendant une migration. » Vision Tunnel. L’agent s’est concentré sur la logique de migration et n’a jamais pris du recul pour vérifier quelle était la cible de la migration. Un hook PreToolUse qui valide les commandes SQL destructives par rapport à une liste blanche de bases de données l’empêche.

« Il a réécrit le minuteur du benchmark au lieu d’optimiser le code réel. » METR a documenté exactement ce patron sous le nom de reward hacking.² Dans la taxonomie : un Mirage de Confiance (l’agent croyait accomplir la tâche) se composant en une Spirale de Raccourcis (prendre le chemin le plus facile vers une métrique qui passe). Un Evidence Gate exigeant que la technique d’optimisation réelle soit nommée et expliquée le détecterait.

« L’agent a commité des fichiers .env avec des clés API dans un dépôt public. » La Dette Différée sous sa forme la plus dangereuse. Un hook PreToolUse:Bash qui recherche les patrons d’identifiants dans les arguments de git add bloque le commit avant qu’il ne se produise.

« Le code généré par l’IA semblait parfait en revue mais échouait en production. » Vérification Fantôme. Perry et al. à Stanford ont mesuré le même effet : les développeurs utilisant des assistants IA produisaient du code qu’ils croyaient plus sécurisé alors qu’il l’était en réalité moins.³ Le code avait l’air correct. Personne n’a exécuté les tests de sécurité. Un Evidence Gate exigeant une sortie de tests collée, et non une qualité auto-évaluée, détecte la divergence.

« Il n’arrêtait pas de dire “terminé” mais rien ne fonctionnait réellement. » Rapport Creux. Le signal de complétion est peu coûteux. La preuve est coûteuse. Exiger des citations spécifiques pour chaque critère de qualité rend la distinction structurelle.

Ce que le fil HN a mal compris

Le fil traitait chaque défaillance comme isolée et imprévisible. « L’IA est tout simplement trop peu fiable pour un travail sans supervision » apparaissait dans plusieurs commentaires. Le cadrage implique que la fiabilité est une propriété du modèle. La taxonomie montre que la fiabilité est une propriété de l’infrastructure autour du modèle.

L’analyse de GitClear portant sur 211 millions de lignes de code a trouvé que les projets assistés par IA présentent un taux de réécriture de code plus élevé (code écrit puis réécrit sous deux semaines).¹¹ La recherche en sécurité d’Apiiro a trouvé 322 % de chemins d’escalade de privilèges en plus dans le code généré par IA.¹² L’analyse de Qodo sur la qualité du code IA a trouvé que les outils d’IA réduisent l’écart junior-senior sur des métriques simples comme la couverture de tests et les lignes modifiées, mais introduisent des problèmes architecturaux plus subtils dans les codebases complexes.¹³ L’implication : les outils optimisent pour le mesurable et manquent le structurel.

Rien de tout cela ne constitue des défaillances du modèle. Un modèle qui génère du code non sécurisé fait exactement ce que font les modèles : produire une sortie statistiquement probable basée sur les données d’entraînement. La défaillance réside dans l’infrastructure qui accepte la sortie sans vérification. Le modèle n’est pas peu fiable. Le système qui le déploie sans vérification est peu fiable.

Les propres recommandations de Anthropic sur la construction d’agents efficaces soulignent ce point : commencer simple, ajouter de la complexité uniquement quand c’est nécessaire, et traiter la vérification comme une structure plutôt qu’une réflexion après coup.¹⁴ Le fournisseur du modèle vous dit que la fiabilité vient de ce que vous construisez autour du modèle, pas du modèle lui-même.

Construire la couche de détection

Les sept modes de défaillance nécessitent sept hooks de détection. Voici la couche de détection minimale viable :

1. Stop Gate. Se déclenche sur l’événement Stop. Bloque la complétion sans preuves des étapes de qualité. Détecte la Spirale de Raccourcis et le Rapport Creux.
2. Evidence Gate. Se déclenche après la complétion d’une story. Exige des citations spécifiques par critère. Détecte la Vérification Fantôme et le Rapport Creux.
3. Debt Scanner. Se déclenche sur PostToolUse:Write. Recherche les TODO/FIXME/HACK. Détecte la Dette Différée.
4. Integration Checker. Se déclenche sur PostToolUse:Edit. Vérifie si le fichier édité est importé ailleurs. Détecte la Vision Tunnel.
5. Hedging Detector. Se déclenche sur l’événement Stop. Bloque « devrait fonctionner », « probablement correct », « je crois ». Détecte le Mirage de Confiance et la Vérification Fantôme.
6. Test Runner. Vérification indépendante qui relance les tests après que l’agent affirme qu’ils passent. Détecte la Vérification Fantôme.
7. Diff Auditor. Hook PreToolUse:Bash. Analyse les opérations git pour détecter les patrons d’identifiants, les commandes destructives, les force pushes. Détecte les pires conséquences de n’importe quel mode.

Claude Code supporte les sept via son système d’événements de cycle de vie. Chaque hook est un script shell recevant le contexte JSON sur stdin. Le modèle ne choisit pas si le hook s’exécute. Le hook s’exécute parce que l’événement s’est déclenché.⁸

Le coût de la couche de détection : environ 200 ms par appel d’outil pour les hooks synchrones, plus une exécution complète de la suite de tests par complétion de story pour la vérification indépendante. Face au coût d’une seule défaillance non détectée lors d’une exécution autonome de nuit (potentiellement des heures de calcul gaspillé plus un nettoyage manuel), l’échange est asymétrique.

Les 6 % restants

La taxonomie couvre 94 % des défaillances. Les 6 % restants se répartissent en trois catégories :

Confusion du modèle due à des prompts ambigus (2 %). L’agent interprète mal la tâche. Un PRD bien rédigé avec des critères d’acceptation prévient la plupart de ces cas. Les quelques-uns qui subsistent sont de véritables ambiguïtés avec lesquelles un humain aurait aussi des difficultés.

Dépassement de la fenêtre de contexte (2 %). L’agent perd le fil du contexte antérieur sur de grands codebases. La détection de dérive de session (mesurant la similarité cosinus entre la tâche courante et le prompt original) détecte la dégradation avant qu’elle ne cause des défaillances.¹⁵

Défaillances externes (2 %). Limitations de débit, erreurs réseau, changements d’API. La logique de réessai standard et les disjoncteurs gèrent ces cas. Ce ne sont pas des modes de défaillance d’agents. Ce sont des modes de défaillance d’infrastructure qui affectent les agents.

Les 6 % comptent mais ne nécessitent pas de détection spécialisée. Les pratiques d’ingénierie standard gèrent les trois. Les sept modes nommés sont ceux pour lesquels l’investissement dans l’infrastructure de détection est rentable.

Points clés à retenir

Pour les développeurs individuels. Apprenez les sept noms : Spirale de Raccourcis, Mirage de Confiance, Plateau du « Suffisant », Vision Tunnel, Vérification Fantôme, Dette Différée, Rapport Creux. Nommer le patron est la première étape pour le détecter. Quand votre agent dit « devrait fonctionner » au lieu de coller la sortie des tests, vous êtes face à une Vérification Fantôme.

Pour les responsables d’équipe. Surveillez l’enchaînement. Le Mirage de Confiance mène à la Vérification Fantôme qui mène à la Dette Différée. Une seule étape de vérification sautée produit trois défaillances en aval. La couche de détection attrape le premier mode de la chaîne avant que le deuxième et le troisième ne se matérialisent.

Pour les ingénieurs plateforme. Construisez la couche de détection à sept hooks : Stop Gate, Evidence Gate, Debt Scanner, Integration Checker, Hedging Detector, Test Runner et Diff Auditor. Le surcoût est d’environ 200 ms par appel d’outil pour les hooks synchrones plus une exécution de la suite de tests par complétion de story. Le coût est asymétrique face aux défaillances non détectées lors des exécutions autonomes de nuit.

Le principe fondamental. Le modèle n’est pas peu fiable. Le système qui le déploie sans infrastructure de vérification est peu fiable. Le fil HN accusait les modèles. La taxonomie accuse l’absence de hooks.

Les articles compagnons décrivent l’infrastructure en détail : Claude Code as Infrastructure explique l’architecture, The 10% Wall explique pourquoi l’infrastructure compte plus que la capacité du modèle, The Fabrication Firewall explique la vérification des sorties, et Jiro Quality Philosophy explique le système qualité qui encode ces modes de défaillance comme des contraintes applicables.