Claude Code hooks : automatiser build, format et notifications sans compter sur le modèle
Les hooks déplacent certaines garanties hors du prompt. Tu peux formater, bloquer une commande, lancer une vérification ou notifier sans espérer que l'agent s'en souvienne.
Durée
10 min
Niveau
Avancé
Outils
Claude Code · Hooks
Un prompt n’est pas un garde-fou.
Tu peux écrire “lance le build à la fin” dix fois. Un agent peut oublier, être interrompu, changer de stratégie, ou décider que ce n’est pas nécessaire. Les hooks existent pour sortir certaines garanties du texte et les mettre dans le cycle de vie de l’outil.
Le but n’est pas d’automatiser tout. Le but est d’automatiser ce qui ne devrait pas dépendre de la mémoire du modèle.
1. Choisis les bons hooks
Les hooks sont utiles pour :
- formater après une édition;
- bloquer une commande dangereuse;
- injecter du contexte au démarrage;
- notifier quand l’agent attend une réponse;
- lancer une vérification ciblée.
Ils sont mauvais pour :
- prendre une décision produit;
- corriger automatiquement un gros diff;
- masquer une suite de tests instable;
- remplacer une CI.
Un hook doit être prévisible, court, et facile à expliquer.
2. Commence par les notifications
Le premier hook utile est souvent le plus simple : signaler qu’une tâche est terminée ou bloquée.
Pourquoi ? Parce que les sessions agentiques durent. Si tu dois regarder l’écran toutes les deux minutes, tu perds l’intérêt de la délégation.
La règle : notification en fin de tâche, pas spam à chaque micro-étape.
3. Ajoute des vérifications ciblées
Évite le hook qui lance toute la suite de tests après chaque fichier. Tu vas ralentir l’agent et créer du bruit.
Préférable :
- format sur les fichiers modifiés;
- typecheck après une série d’éditions;
- build final;
- test ciblé quand un dossier précis change.
Dans un repo Astro, le minimum raisonnable après contenu ou UI reste bun run build.
4. Bloque seulement ce qui est vraiment dangereux
Les hooks peuvent empêcher des commandes. Utilise cette force avec parcimonie.
Bons blocages :
- suppression destructive non demandée;
- modification de secrets;
- commande package manager interdite;
- push ou merge sans demande.
Mauvais blocage :
- toute commande inconnue;
- tout accès réseau;
- tout script long.
Un hook trop strict pousse l’agent à contourner ou à s’arrêter. Un hook utile clarifie la frontière.
5. Écris la règle dans le repo
Les hooks vivent dans une config, mais la politique doit être lisible dans le repo :
- quelles commandes valident quoi;
- quand le build est obligatoire;
- quels fichiers sont sensibles;
- quand demander confirmation.
Sans cette couche écrite, tu as de l’automatisation sans contrat.
Sources
Aller plus loin