Pose un garde-fou : les hooks

Le risque : publier une erreur

Ton skill rédige et publie. Mais que se passe-t-il si un post contient un tiret long que tu détestes, dépasse la limite de caractères de la plateforme, ou part sur Instagram sans image ? Pour l'instant, rien ne l'arrête. Tu pourrais relire chaque post à la main — mais alors à quoi bon automatiser ? Tu pourrais ajouter « vérifie bien avant de publier » dans le skill — mais une instruction dans un prompt reste probabiliste : le modèle la suit presque toujours, et « presque » ne suffit pas quand l'erreur est publique et instantanée.

Il te faut un garde-fou d'une autre nature : une vérification qui s'exécute systématiquement, que Claude ne peut ni oublier ni contourner. C'est exactement ce que sont les hooks.

C'est quoi un hook ?

Un hook exécute du code à des moments clés du cycle de vie de Claude Code. Il se déclenche automatiquement : tu n'as pas à penser à l'appeler, et Claude n'a pas à penser à le respecter — il s'impose à lui. Un hook peut formater des fichiers après modification, bloquer une commande avant son exécution, injecter du contexte au démarrage d'une session, ou notifier quand une tâche se termine.

Les moments de déclenchement (les « événements ») couvrent tout le cycle de vie : avant qu'un outil s'exécute (l'événement PreToolUse — c'est lui qui nous intéresse pour bloquer une publication), après son exécution (PostToolUse — parfait pour reformater un fichier modifié), à la soumission de ton message, au démarrage de la session, ou quand Claude termine sa réponse. Chaque hook est associé à un événement et, optionnellement, à un filtre (par exemple : seulement les commandes Bash qui contiennent « publish »).

Les trois façons de valider

La règle de choix : prends le moins puissant qui suffit. Vérifier une limite de caractères avec un agent hook, c'est sortir le bulldozer pour planter une salade — lent, cher, et plus fragile. Notre quality gate combine des règles simples et objectives : un command hook est le bon outil.

Où vivent les hooks

Les hooks se configurent dans tes fichiers de réglages (.claude/settings.json pour les partager avec le projet, ou settings.local.json pour toi seul). La structure associe un événement, un filtre (« matcher ») et la commande à lancer. Voici la forme générale d'un hook qui se déclenche avant les commandes Bash :

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "node .claude/hooks/quality-gate.js"
          }
        ]
      }
    ]
  }
}

Le mécanisme de blocage est élégant de simplicité : le script du hook reçoit les détails de l'action en entrée, et son code de sortie décide de la suite. Sortie 0 : tout va bien, l'action continue. Sortie 2 : l'action est bloquée, et ce que le script a écrit sur la sortie d'erreur est renvoyé à Claude — qui le lit et corrige. Le hook ne se contente donc pas de dire non : il explique pourquoi, et Claude utilise cette explication pour réparer.

Construire le quality gate

On crée un hook qui se déclenche avant toute publication et vérifie le contenu. S'il échoue, la commande est bloquée et Claude voit précisément quoi corriger :

crée un command hook qui se déclenche avant toute commande Bash de publication.

le hook vérifie le contenu du post :
- tirets longs (à remplacer par « ... »)
- dépassement de la limite de caractères de la plateforme
- média manquant pour les plateformes qui en exigent un
- mots bannis de mon guide de voix de marque

si une vérification échoue : bloque la commande et affiche précisément quoi corriger.

flowchart TD
  P["Tentative de publication"] --> H{"Hook : quality gate"}
  H -->|"Conforme"| OK["Publication"]
  H -->|"Non conforme"| KO["Bloqué + liste des corrections"]
  KO --> F["Claude corrige le contenu"]
  F --> P

Observe la boucle dans le diagramme : bloqué ne veut pas dire mort. Claude lit le message d'erreur, corrige le contenu et retente — le plus souvent sans aucune intervention de ta part. Le garde-fou ne ralentit pas le système : il le rend auto-correcteur.

Tester le hook (en provoquant l'échec)

Un garde-fou non testé est un garde-fou décoratif. La méthode : provoquer volontairement chaque type d'échec et vérifier le blocage. C'est le même réflexe qu'un développeur qui teste ses cas d'erreur, pas seulement son chemin heureux :

teste le hook sur un tweet qui dépasse la limite de caractères

teste le hook sur un post instagram sans image

teste le hook sur un post contenant le mot "révolutionnaire"

Pour chaque test, la sortie doit indiquer que l'action a été bloquée (« validation échouée ») avec la raison exacte. Si un cas passe alors qu'il devrait bloquer, c'est maintenant qu'on l'apprend — pas le jour où un post non conforme part en production. Parfait : ton pipeline ne publiera jamais un contenu non conforme.

Au-delà du quality gate

Une fois le mécanisme compris, les hooks deviennent un réflexe pour tout ce qui doit être systématique. Quelques usages classiques : reformater automatiquement chaque fichier modifié (PostToolUse), interdire toute commande touchant à un dossier sensible, charger l'état du projet au démarrage de session, ou envoyer une notification quand une longue tâche se termine. La question à se poser est toujours la même : « est-ce que je veux que ça arrive à chaque fois, sans dépendre de la mémoire de qui que ce soit ? » Si oui, c'est un hook.

Pour Léa, ce chapitre change la nature de son système : avant, l'automatisation était rapide mais demandait sa relecture ; maintenant elle est rapide et digne de confiance. C'est ce qui rendra possible le passage à l'échelle des deux prochains chapitres — on ne parallélise que ce qu'on a sécurisé.