Les huit hooks qui garantissent la fiabilité de vos agents IA

CLAUDE.md est une suggestion. Écrivez « lancer Prettier avant chaque commit » et l’agent l’ignorera environ une fois sur trois. Des instructions plus précises ne règlent rien. Un taux de conformité de 80 % n’est pas un problème de qualité du modèle. C’est la limite structurelle inhérente au fait de placer des règles dans la fenêtre de contexte en espérant que le modèle les respecte.

Les hooks opèrent sur un plan radicalement différent. Ce sont des scripts qui s’exécutent automatiquement à des points précis du cycle de vie, indépendamment de ce que décide le modèle. PreToolUse se déclenche juste avant que l’agent modifie un fichier ou lance une commande. PostToolUse se déclenche juste après. Le modèle n’a pas son mot à dire. Les hooks s’exécutent, point.

La différence pratique est immédiate. Ajouter dix lignes de règles dans CLAUDE.md et ajouter un hook dans .claude/settings.json sont deux interventions de nature totalement différente. Le code de sortie 2 bloque l’action de l’agent. Le code 0 la laisse passer. Tout autre code logue un avertissement sans bloquer. Et parce que les hooks vivent dans settings.json, un seul commit suffit pour que toute l’équipe en bénéficie via git.

Les quatre gardes avant l’exécution

J’utilise des hooks depuis plus de six mois. Ces quatre hooks PreToolUse ont survécu à chaque projet sans jamais être supprimés.

Bloquer les commandes dangereuses intercepte les patterns destructeurs comme rm -rf, git reset --hard et DROP TABLE par correspondance regex, puis retourne le code de sortie 2 pour tuer l’action avant qu’elle ne se produise. J’ai vu des agents tenter rm -rf sur des répertoires qu’ils n’auraient jamais dû toucher. Sans ce hook, les dégâts auraient été bien réels.

Protéger les fichiers sensibles bloque toute tentative de modification sur .env, package-lock.json, *.pem et les fichiers similaires. L’agent n’a jamais la possibilité d’écraser votre fichier de verrou ou de faire fuiter des credentials dans un commit.

Exiger les tests avant une PR conditionne la création d’une pull request au passage des tests. Configurez le matcher sur mcp__github__create_pull_request et l’agent ne peut littéralement pas ouvrir une PR tant que les tests ne passent pas. Fini les « je corrigerai les tests dans un prochain commit ».

Logger chaque commande écrit dans .claude/command-log.txt chaque commande bash lancée par l’agent, horodatée. Trois jours plus tard, quand quelque chose cloche, vous pouvez retracer exactement ce qui s’est passé.

Les trois inspecteurs après l’exécution

Les hooks PostToolUse s’exécutent immédiatement après que l’agent a modifié un fichier. J’en chaîne trois dans l’ordre.

Auto-format lance Prettier sur chaque fichier modifié. Pour les projets Python, remplacez par Black. Pour Go, utilisez gofmt. Le formateur tourne que l’agent ait pensé à formater ou non.

Auto-lint lance ESLint juste après le formatage. Si ESLint trouve des erreurs, l’agent les voit immédiatement et les corrige dans le même tour. Le nombre de problèmes de lint qui arrivent jusqu’à la revue de code humaine tombe pratiquement à zéro.

Auto-test lance la suite de tests correspondante après chaque modification de fichier. Quand un test échoue, l’agent le sait en quelques secondes et tente un correctif. Je passe la sortie dans tail -5 pour ne garder que le résumé, ce qui évite que les logs de test n’inondent la fenêtre de contexte.

L’ordre compte. Prettier d’abord, ESLint ensuite, puis les tests. Quand un humain regarde le code, le formatage et le lint ont déjà passé. Les commentaires de style en revue de code disparaissent.

Préserver le travail quand l’agent s’arrête

Un seul hook Stop s’occupe de ça : Auto-commit lance git add -A && git commit à chaque fois que l’agent termine une réponse. Chaque unité de travail obtient son propre commit. Deux tâches ne se retrouvent jamais mélangées dans un même commit.

Combinez ça avec les git worktrees et vous obtenez des commits automatiques par branche sur les branches de fonctionnalité. Si l’agent plante ou que vous l’interrompez, vous ne perdez jamais le dernier bloc de travail.

Ce qui n’a pas fonctionné proprement

Le chaînage de hooks paraît élégant sur le papier, mais déboguer une chaîne défaillante est plus difficile que déboguer un script isolé. Quand le hook auto-test a commencé à échouer silencieusement parce que le runner de tests n’était pas installé dans un nouveau projet, j’ai passé une heure à comprendre pourquoi l’agent continuait à produire du code non testé. Le hook retournait le code de sortie 0 car le script de test lui-même n’était pas trouvé, et le shell traitait « command not found » comme une condition non bloquante. J’ai dû ajouter une vérification explicite de l’existence du runner avant de l’invoquer.

La performance est l’autre contrainte. L’inquiétude habituelle est que beaucoup de hooks ralentissent les choses, mais ce n’est pas tout à fait la bonne question. Ce qui compte vraiment, c’est si chaque hook individuel se termine en moins de 200 millisecondes. Un passage de Prettier sur un seul fichier prend environ 50 ms. Un check ESLint environ 80 ms. Les tests varient, mais en les limitant aux fichiers affectés, la plupart des exécutions restent rapides. Dès qu’un hook dépasse la seconde, la boucle de feedback de l’agent commence à sembler poussive.

Pourquoi ça rejoint un pattern plus large

Le blog Harness Engineering d’OpenAI l’a formulé clairement : les agents fonctionnent mieux dans des frontières rigides et une structure prévisible. La philosophie de conception de React dit la même chose à propos des composants : des unités composables avec des phases de cycle de vie définies et un état.

Les hooks dans Claude Code suivent la même abstraction. L’état correspond aux sessions et à la mémoire. Les hooks sont les fonctions qui interviennent aux frontières du cycle de vie. PreToolUse pose les limites. PostToolUse rend la structure prévisible. Stop préserve le résultat.

La ligne « lancer Prettier » que j’avais dans CLAUDE.md a disparu. Le hook le fait à chaque fois, sans qu’on le lui demande.