Hooks et automatisation
Connecte les hooks SessionStart pour charger automatiquement le contexte. Utilise PreToolUse pour bloquer les commandes dangereuses. Exécute Claude sur cron avec des portes d'approbation.
Les hooks sont des commandes que Claude Code exécute à des événements de cycle de vie spécifiques. Configure-les une fois dans ~/.claude/settings.json ; ils se déclenchent automatiquement. Les hooks imposent une discipline que tu oublierais autrement : charger STATE.md à chaque session, vérifier les fichiers .env stagés avant de commiter. Le coût de configuration est de 10 minutes. Le gain est permanent.
SessionStart se déclenche au moment où une session s'ouvre ; tout ce qu'il imprime devient du contexte avant ton premier message :
{
"hooks": {
"SessionStart": [
{
"command": "cat ~/notes/STATE.md ~/notes/MEMORY.md 2>/dev/null || true"
}
]
}
}Le || true est important : ne pas interrompre le démarrage de la session si des fichiers sont manquants. Garde les hooks sous 50 ms et ne fais aucun appel réseau à l'ouverture de la session. Besoin de données API fraîches ? Exécute un cron qui écrit un fichier local ; charge le fichier dans le hook.
Quatre autres événements de hook :
Stop : se déclenche à la fin d'une session. Utilise-le pour des rappels : "Avant de fermer : mets à jour STATE.md."
PreToolUse : se déclenche avant que Claude n'appelle un outil. Ta couche d'application de sécurité : bloque les commandes dangereuses, logue les appels pour les pistes d'audit. La sortie 0 autorise l'appel ; la sortie 2 le bloque.
PostToolUse : se déclenche après le retour d'un outil. Exécute un linter après l'écriture d'un fichier, vérifie les politiques RLS après une migration SQL.
UserPromptSubmit : se déclenche lorsque tu appuies sur Entrée. Injecte du contexte ou applique des défenses contre l'injection d'invite pour le contenu externe.
Un hook PreToolUse qui bloque tout appel Bash contenant rm -rf :
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"command": "if echo \"$CLAUDE_TOOL_INPUT\" | grep -q 'rm -rf'; then echo 'BLOQUÉ : rm -rf non autorisé' >&2; exit 2; fi"
}
]
}
}Le champ matcher cible un outil spécifique. Sans lui, le hook se déclenche à chaque appel d'outil. Utilise les matchers pour que les hooks restent rapides et ciblés.
Quand un hook ne se déclenche pas, vérifie dans l'ordre :
Syntaxe : JSON valide ? Exécute cat ~/.claude/settings.json | python3 -m json.tool.
Chemin du fichier : teste la commande du hook manuellement dans ton terminal.
Code de sortie : || true est-il manquant ?
Vitesse : plus de 3 secondes ? Déplace la partie lente vers un cron.
Deux pièges de production. Définis un champ timeout explicite sur chaque hook pour que le comportement reste prévisible. Et les hooks s'exécutent dans un environnement dépouillé, pas ton shell complet : si un hook a besoin d'une variable d'environnement (comme un jeton Slack), source ton .env explicitement dans la commande du hook. C'est la cause la plus fréquente des hooks qui fonctionnent dans ton terminal mais échouent silencieusement dans Claude Code.
Claude Code piloté par Cron. Le même agent peut s'exécuter selon un calendrier via claude --headless : un briefing matinal à 7h posté sur Slack, une surveillance des médias sociaux toutes les 4 heures, un contrôle de santé de déploiement toutes les 30 minutes.
Le modèle critique : les portes d'approbation. Le cron rédige, tu révises, le système envoie. Un agent autonome qui envoie des messages sortants sans révision finira par envoyer quelque chose de faux : mauvais modèle, mauvais public, mauvais timing. L'architecture : l'agent découvre et rédige, l'humain révise et publie. Implémentation : l'agent écrit les brouillons dans un canal Slack ; rien ne sort tant qu'un humain n'a pas approuvé. Cela s'adapte à des dizaines d'agents sans qu'aucun ne devienne incontrôlable.
Construis le système de hooks par phases :
Phase 1 (semaines 1-2), hooks de chargement : SessionStart charge STATE.md et MEMORY.md ; Stop te rappelle de mettre à jour.
Phase 2 (semaines 3-4), hooks de garde : PreToolUse bloque les commandes irréversibles (force-push vers main, DROP TABLE, rm -rf).
Phase 3 (mois 2+), hooks d'audit : PostToolUse vérifie ce qui a été réellement écrit : migrations SQL sans politiques RLS, nouvelles routes API sans limitation de débit, secrets dans tout fichier écrit.
PostToolUse est plus fort que PreToolUse pour les audits car il lit le contenu du fichier écrit, la vérité, pas seulement ce que Claude avait l'intention de faire. Construis des hooks autour de tes modes de défaillance réels : deux hooks qui résolvent de vrais problèmes valent mieux que dix théoriques.
SessionStart charge le contexte, Stop rappelle, PreToolUse bloque les commandes dangereuses (sortie 2), PostToolUse audite ce qui a été écrit, et cron plus les portes d'approbation transforment Claude en un système planifié avec un humain sur le bouton d'envoi. Commence par un hook : cat ~/notes/STATE.md 2>/dev/null || true dans SessionStart. Ajoute la phase suivante chaque mois.