Claude Code · Automation · 2026
Claude Code Hooks
automatiser Claude pour ne plus rien oublier
Décrochez les tâches répétitives de votre workflow Claude Code. Formatage, lint, tests, scan de secrets, notifications Slack — câblés une fois, oubliés à jamais.
ℹ️Réponse directe — Claude Code Hooks ?
Un hook Claude Code est une commande shell qui se déclenche automatiquement à un événement précis du cycle de vie : avant ou après une édition de fichier, au démarrage d’une session, quand Claude termine sa réponse. Configuration dans .claude/settings.json.
Exemple minimal : déclencher Prettier sur chaque fichier édité par Claude — {"hooks": {"PostToolUse": [{"matcher": "write_file", "hooks": [{"type": "command", "command": "npx prettier --write {file}"}]}]}}. Plus jamais à dire ‘n’oublie pas de formater’.
Les hooks Claude Code, c’est quoi concrètement ?
Un hook Claude Code est une commande shell qui se déclenche automatiquement à un moment précis de la session : avant qu’un outil soit utilisé, après une édition de fichier, au démarrage d’une session, ou quand Claude termine sa réponse. Pendant que vous codez avec l’IA, le hook tourne en fond et exécute votre logique : formatage Prettier, scan de secrets, lancement des tests, envoi d’une notification Slack. Vous n’avez plus à le demander à Claude ni à vous en souvenir — c’est câblé.
Il existe quatre types de hooks en 2026. Le command hook est la brique de base : il lance une commande shell simple à un événement donné. Le agent hook lance un sous-agent Claude qui reçoit le JSON de l’événement et décide quoi faire de manière intelligente. Le HTTP hook envoie l’événement vers une URL externe (webhook Slack, Datadog, système de monitoring). Le StopFailure hook (nouveau en mars 2026) bloque dur la session tant qu’une condition n’est pas remplie — tests verts, lint propre, pas de secrets exposés.
La grande nouveauté de la mise à jour de mars 2026 est précisément le StopFailure. Avant, un hook Stop pouvait alerter l’utilisateur en cas d’échec, mais Claude continuait quand même. Désormais, un StopFailure bloque dur : la session Claude Code ne peut pas rendre la main tant que la condition n’est pas remplie. C’est la garantie ultime de qualité pour les équipes qui veulent un garde-fou strict.
Les 4 événements d’accrochage disponibles
| Événement |
Quand il se déclenche |
Cas d’usage typique |
| PreToolUse |
Avant que Claude utilise un outil (lecture, écriture, bash…) |
Bloquer l’écriture dans des fichiers sensibles |
| PostToolUse |
Après que Claude a utilisé un outil |
Formater les fichiers après écriture, lancer les tests |
| Stop |
Quand Claude a terminé de répondre |
Vérifier la qualité globale, notifier Slack |
| StopFailure |
Quand Stop échoue — bloque la session |
Garantir que les tests passent avant de rendre la main |
settings.json — 4 hooks essentiels
{
"hooks": {
"PostToolUse": [
{
"matcher": "write_file",
"hooks": [
{
"type": "command",
"command": "npx prettier --write {file}",
"description": "Formater automatiquement après chaque écriture"
}
]
}
],
"Stop": [
{
"hooks": [
{
"type": "command",
"command": "npm test -- --passWithNoTests",
"description": "Lancer les tests à la fin de chaque session"
},
{
"type": "command",
"command": "npx secretlint --no-color .",
"description": "Scanner les secrets exposés"
}
]
}
],
"StopFailure": [
{
"hooks": [
{
"type": "command",
"command": "echo 'Tests échoués — impossible de terminer la session'",
"description": "Bloquer si les tests ne passent pas"
}
]
}
]
}
}
Les hooks les plus utiles par cas d’usage
Formatage automatique : configurez un hook PostToolUse sur write_file pour exécuter Prettier, Black, gofmt ou rustfmt selon votre langage. Claude ne postera plus jamais du code non formaté. L’économie en tokens est aussi réelle — vous n’avez plus à demander ‘formate ce fichier’ dans chaque prompt.
Scan de secrets : un hook Stop qui lance secretlint ou detect-secrets sur les fichiers modifiés évite les accidents de commit de credentials. Sur les projets avec des APIs ou des clés AWS, c’est un garde-fou indispensable. Le hook bloque et alerte si un pattern de secret est détecté.
Tests automatiques : un hook Stop qui lance la suite de tests rapides (< 30 secondes) à la fin de chaque session vous donne un feedback immédiat. Vous savez avant de committer si Claude a cassé quelque chose. StopFailure peut bloquer la session si les tests échouent.
Notifications d’équipe : un hook HTTP vers un webhook Slack qui envoie un résumé des modifications à chaque fin de session Claude Code. L’équipe voit en temps réel ce que l’IA a fait sans avoir à consulter le diff Git.
💡Mon verdict
Les hooks ont transformé mon workflow Claude Code. Avant, je devais systématiquement rappeler à Claude de formater, de lancer les tests, de vérifier les imports. Maintenant c’est câblé et ça tourne tout seul. La différence se ressent après 2 à 3 jours d’utilisation.
Mon conseil pour démarrer : identifiez la chose que vous répétez le plus souvent dans vos prompts Claude Code — souvent ‘n’oublie pas de formater’ ou ‘lance les tests’. Créez un seul hook pour cette tâche. Une semaine plus tard, ajoutez le scan de secrets. En un mois, vous avez 3 à 4 hooks qui automatisent tout ce qui était répétitif.
Questions fréquentes sur Claude Code Hooks ?
Les hooks Claude Code sont-ils des scripts shell standards ?+
Oui, les command hooks exécutent des commandes shell standard dans le répertoire du projet. Vous pouvez utiliser n’importe quelle commande disponible dans votre PATH : npm, npx, python, go, curl, jq, etc. Les variables disponibles dans la commande incluent {file} (le fichier concerné), {event} (le nom de l’événement) et d’autres selon le type d’événement.
Les hooks ont accès à l’environnement complet de votre shell — variables d’environnement, PATH, outils installés localement via node_modules. Un hook qui lance npx prettier –write {file} fonctionnera si prettier est installé dans votre projet, même s’il n’est pas installé globalement.
La sortie standard des hooks est capturée par Claude Code. Si un hook échoue (code de retour non nul), Claude Code peut être configuré pour traiter cela comme une erreur ou l’ignorer selon la configuration du hook. Les messages d’erreur des hooks sont visibles dans le panneau Claude Code pour le debugging.
Comment déboguer un hook qui ne se déclenche pas ?+
Trois étapes de debugging. D’abord, vérifiez la syntaxe de votre settings.json avec un linter JSON — une virgule manquante ou une accolade fermante en trop et tout le fichier est ignoré silencieusement. Utilisez jq . .claude/settings.json pour valider le JSON.
Ensuite, ajoutez un echo de test dans votre hook pour vérifier qu’il se déclenche : command: ‘echo HOOK_DECLENCHE >> /tmp/claude-hooks.log && votre-commande’. Après une session Claude Code, vérifiez /tmp/claude-hooks.log — si le message n’est pas là, le hook ne se déclenche pas.
Enfin, vérifiez le matcher de votre hook. Si vous utilisez un matcher sur le nom d’un outil (write_file, bash, etc.), assurez-vous que le nom correspond exactement à ce que Claude Code utilise. La liste des noms d’outils exacts est dans la documentation officielle Claude Code.
Peut-on avoir des hooks différents selon le projet ?+
Oui, c’est même la configuration recommandée. Claude Code lit d’abord le settings.json global (~/.claude/settings.json) puis le settings.json du projet (.claude/settings.json). Les hooks des deux fichiers sont combinés — les hooks globaux s’appliquent à tous les projets, les hooks de projet s’appliquent uniquement au projet en question.
Exemple de configuration : hooks globaux pour le scan de secrets (s’applique à tous vos projets), hooks de projet pour le formatage (Prettier dans un projet JS, Black dans un projet Python). Chaque projet a son propre fichier settings.json avec les hooks adaptés à son stack.
Pour les équipes, commitez le settings.json du projet dans Git. Tous les développeurs du projet bénéficient des mêmes hooks automatiquement quand ils clonent le repo. C’est l’un des moyens les plus efficaces de standardiser les pratiques de qualité dans une équipe.
Les hooks ralentissent-ils Claude Code ?+
Ça dépend de ce que font vos hooks. Un hook de formatage Prettier sur un fichier de 200 lignes prend 50 à 200 millisecondes — imperceptible. Un hook qui lance toute la suite de tests (npm test) peut prendre 30 secondes à 5 minutes selon la taille du projet — clairement perceptible.
Pour les hooks lents (tests, analyses statiques), configurez-les sur l’événement Stop (fin de session) plutôt que PostToolUse (après chaque écriture de fichier). Vous avez le résultat une fois par session plutôt qu’après chaque modification individuelle.
Pour les projets avec des suites de tests très longues, créez deux hooks séparés : un hook Stop rapide (tests unitaires < 10 secondes), et un hook HTTP vers votre CI/CD pour les tests complets. Le hook local donne un feedback rapide, la CI valide en profondeur.
StopFailure peut-il bloquer indéfiniment Claude Code ?+
En théorie oui, mais c’est volontaire — c’est le but de ce type de hook. Si vos tests ne passent pas à cause d’un bug introduit par Claude Code, StopFailure bloque la session et vous force à résoudre le problème avant de passer à autre chose. C’est un garde-fou fort.
En pratique, Claude Code affiche clairement le message d’erreur du hook StopFailure et attend votre intervention. Vous pouvez soit demander à Claude de corriger le problème qui a fait échouer le hook, soit interrompre manuellement la session avec Ctrl+C si vous voulez investiguer indépendamment.
Pour éviter les blocages non intentionnels, déployez StopFailure progressivement. Commencez avec un hook Stop normal qui affiche des warnings, observez les faux positifs, affinez la commande du hook, puis passez à StopFailure quand vous êtes confiant dans la fiabilité du hook.
Peut-on utiliser les hooks pour envoyer des métriques à un système de monitoring ?+
Oui, c’est un cas d’usage excellent via les HTTP hooks. Un hook HTTP qui envoie un événement à DataDog, Grafana Loki, ou votre propre endpoint de monitoring à chaque fin de session Claude Code vous donne une traçabilité complète des modifications IA.
Exemple : un hook HTTP vers un webhook Slack qui envoie un résumé JSON des fichiers modifiés et du nombre de lignes changées. En 10 lignes de configuration, vous avez une traçabilité IA dans votre canal #dev-team. L’équipe voit en temps réel ce que l’IA a fait sans regarder les commits.
Pour les équipes avec des obligations de conformité (audit trail des modifications IA, secteur financier ou médical), les HTTP hooks permettent d’envoyer chaque modification vers un système d’archivage immuable. C’est une exigence légale dans certains secteurs qui veulent savoir ‘quelle partie du code a été écrite ou modifiée par IA’.
Les hooks fonctionnent-ils avec les subagents Claude Code ?+
Oui, les hooks configurés dans le settings.json du projet s’appliquent à tous les agents — l’agent principal et les subagents. Un hook de formatage PostToolUse s’exécute que ce soit l’agent principal ou un subagent backend qui écrive le fichier.
Pour les workflows multi-agents, les hooks sont particulièrement utiles pour garantir la cohérence. Un hook de lint qui s’applique à chaque écriture de fichier garantit que le subagent frontend respecte les mêmes règles de style que le subagent backend, sans que vous ayez à le configurer dans chaque prompt de subagent.
Attention : les hooks se déclenchent pour chaque agent indépendamment. Si vous avez 3 subagents actifs et que chacun écrit plusieurs fichiers, vos hooks PostToolUse peuvent se déclencher de nombreuses fois. Assurez-vous que vos hooks sont idempotents (safe à exécuter plusieurs fois sur le même fichier) pour éviter les effets de bord.
Comment partager des hooks entre plusieurs projets sans les dupliquer ?+
Trois approches selon votre besoin. Première approche : le settings.json global (~/.claude/settings.json) pour les hooks qui s’appliquent à tous vos projets. Formatage, scan de secrets, notifications — ces hooks méritent souvent d’être globaux plutôt que dupliqués dans chaque projet.
Deuxième approche : un fichier de hooks shared versionné dans un repo dédié que vous importez dans chaque projet. Un script d’initialisation de projet (make setup, npm run setup) copie ou crée un lien symbolique vers ce fichier de hooks partagé. Cette approche centralise la maintenance.
Troisième approche pour les équipes : un générateur de configuration (CLI interne) qui génère le settings.json adapté au stack du projet (Python → hooks Black + Pytest, JavaScript → hooks Prettier + Jest, Go → hooks gofmt + go test). Chaque projet reçoit les hooks appropriés à son langage sans copier-coller manuel.
Les hooks peuvent-ils modifier le comportement de Claude via leur output ?+
Les agent hooks — contrairement aux command hooks — peuvent envoyer des instructions à Claude via leur sortie standard. Un agent hook reçoit le JSON de l’événement et peut générer du texte que Claude lit et prend en compte dans sa réponse suivante. C’est la forme la plus puissante de hook.
Exemple : un agent hook PostToolUse sur write_file qui analyse le fichier écrit, détecte des anti-patterns spécifiques à votre organisation, et retourne un message structuré à Claude : ‘Tu as utilisé le pattern X — notre convention est Y, peux-tu corriger ?’ Claude reçoit cette instruction et corrige automatiquement.
Les agent hooks demandent un abonnement Claude Pro et consomment des tokens supplémentaires. Pour les cas où un simple script shell suffit (formatage, lint), préférez un command hook. Réservez les agent hooks pour les analyses intelligentes qui nécessitent vraiment une compréhension du code plutôt que de simples règles statiques.
Comment éviter qu’un hook exécute du code dangereux par erreur ?+
Les hooks s’exécutent avec les mêmes permissions que l’utilisateur qui lance Claude Code — ils peuvent lire et écrire des fichiers, lancer des processus, et accéder au réseau. C’est pourquoi il est essentiel de traiter la configuration des hooks avec la même rigueur que n’importe quel script de build.
Bonnes pratiques de sécurité pour les hooks. Évitez les variables non quotées dans les commandes shell (vulnérabilité d’injection si un nom de fichier contient des caractères spéciaux). N’utilisez pas sudo dans vos hooks. Limitez les hooks HTTP aux domaines de confiance. Pour les hooks en production, committez settings.json dans Git et faites le revoir par un pair.
Claude Code lui-même ne peut pas modifier votre settings.json via les hooks — ce serait une backdoor évidente. Mais des plugins mal conçus ou des repos Git compromis pourraient inclure un settings.json malveillant. Vérifiez toujours le settings.json quand vous clonez un nouveau repo avant de lancer Claude Code.
🔗
Pour aller plus loin sur Claude Code
⭐ Ce que disent mes clients
📰 Pour aller plus loin sur l’IA en 2026
Retrouvez-moi sur les réseaux
Analyses SEO, tests IA et veille Claude au quotidien.
