Comment donner à votre agent de codage IA une boucle de rétroaction qui détecte ses propres bugs

Lorsqu'un agent de codage IA écrit du code qui semble correct mais casse silencieusement quelque chose, le problème ne vient généralement pas du modèle — c'est que l'agent n'a jamais vu l'échec. Il a écrit la modification, crié victoire et est passé à autre chose, parce que rien ne lui a indiqué que la suite de tests était désormais au rouge. La solution consiste à boucler la boucle : faire en sorte que les propres outils de l'agent lui rapportent automatiquement les résultats.

Ce guide montre comment construire cette boucle de rétroaction pour que votre agent détecte ses erreurs avant vous.

L'idée centrale : les erreurs doivent revenir dans le contexte

Un flux de travail d'agent fiable comporte quatre temps — explorer, planifier, construire, vérifier. La plupart des gens s'arrêtent à « construire ». L'étape de vérification est ce qui distingue un agent qui produit du code fonctionnel d'un agent qui produit du code plausible en apparence.

Vérifier, c'est exécuter de vrais contrôles après chaque modification — votre lanceur de tests, votre linter et votre vérificateur de types — et renvoyer le résultat à l'agent. Lorsqu'un contrôle échoue, le message d'erreur arrive dans le contexte de l'agent, et le modèle le traite comme n'importe quelle autre instruction : il lit l'échec et le corrige. Aucun humain dans la boucle pour les allers-retours fastidieux.

Vous pouvez procéder de deux manières : le demander dans vos instructions de projet, ou l'automatiser pour qu'on ne puisse pas le contourner.

Option 1 : se contenter de le demander, dans la configuration de votre projet

La version la plus simple est une ligne dans votre CLAUDE.md ou AGENTS.md (le fichier d'instructions en texte brut que la plupart des agents lisent au démarrage) :

## Verification
After any code change, run `npm run typecheck && npm test`.
If either fails, fix the cause and re-run before reporting done.

Cela fonctionne étonnamment bien — mais ce n'est qu'indicatif. Un agent occupé peut oublier, ou décider qu'une modification est « trop petite » pour être vérifiée. Pour tout ce qui compte à vos yeux, rendez la vérification déterministe.

Option 2 : l'automatiser avec un hook

Les hooks de Claude Code vous permettent d'exécuter une commande shell en réponse à des événements du cycle de vie, indépendamment du fait que le modèle s'en souvienne ou non. Celui qui nous intéresse ici est PostToolUse, qui se déclenche après que l'agent a modifié un fichier. Comme le formule un guide pratique sur les hooks, PostToolUse est conçu pour les réactions — formatage, journalisation, exécution de tests — et sa sortie est réinjectée dans le contexte de l'agent pour influencer son étape suivante.

Voici un hook minimal qui exécute votre vérificateur de types après toute modification de fichier et renvoie les échecs à l'agent. Dans .claude/settings.json :

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "npm run typecheck"
          }
        ]
      }
    ]
  }
}

Désormais, le cycle est automatique : l'agent écrit du code → le hook exécute tsc → s'il y a une erreur de type, le message revient dans le contexte → l'agent la corrige → le hook s'exécute à nouveau. La référence des hooks documente comment le code de sortie non nul et la sortie sont remontés au modèle. Cette boucle s'exécute à chaque écriture, sans aucune sollicitation.

Gardez la boucle rapide et ciblée

Une boucle de rétroaction n'est utile que si elle est rapide. Quelques règles empiriques :

• Exécutez les contrôles peu coûteux à chaque modification, les coûteux moins souvent. Une vérification de types ou un linter sur le fichier modifié est rapide. Une suite d'intégration complète ne l'est pas — réservez-la à un hook Stop (lorsque l'agent termine un tour) ou à une commande manuelle, pas à chaque frappe.
• Ciblez ce qui a changé. Exécuter l'intégralité de votre suite de tests après un ajustement CSS d'une ligne fait perdre du temps et inonde le contexte. Là où votre outillage le permet, ciblez les fichiers concernés.
• Rendez les échecs lisibles. L'agent ne corrige que ce qu'il peut lire. Des linters et vérificateurs de types aux messages d'erreur clairs et localisés (file:line: message) donnent au modèle exactement ce dont il a besoin ; un simple « build failed » non.

Un avant/après concret

Sans boucle : vous demandez à l'agent de renommer une fonction. Il met à jour trois sites d'appel, en oublie un quatrième dans un fichier qu'il n'a pas ouvert, et signale que c'est terminé. Vous découvrez l'import cassé à l'exécution une heure plus tard.

Avec la boucle : le même renommage déclenche typecheck à l'enregistrement. tsc signale Cannot find name 'oldFn' au site d'appel oublié. Cette erreur arrive dans le contexte, l'agent ouvre le quatrième fichier, corrige la référence, et le contrôle suivant passe — le tout avant qu'il ne vous annonce qu'il a fini.

L'essentiel à retenir

Les agents IA sont doués pour produire du code et mauvais pour remarquer quand il est faux. Vous comblez cet écart en leur donnant le même signal que celui sur lequel vous vous appuyez : un test au rouge, une erreur de type, une règle de lint non respectée — livrés automatiquement, juste après la modification. Commencez par une ligne dans vos instructions de projet, puis promouvez votre contrôle le plus important au rang de hook pour qu'il s'exécute, que le modèle s'en souvienne ou non. Les agents qui semblent « intelligents » ne sont généralement que ceux qui sont branchés sur une boucle de rétroaction bien serrée.