Hooks : automatiser le cycle de vie

Un hook est une action que le harnais exécute lui même sur un événement précis du cycle de vie, jamais une préférence confiée au modèle en espérant qu'il s'en souvienne.

Un hook est une action que le harnais exécute lui même quand un événement précis du cycle de vie survient, jamais une demande que le modèle interprète au moment d'agir. Écrire dans un fichier de mémoire chaque fois que vous committez, lancez les tests reste une préférence : le modèle peut l'oublier après une longue conversation ou une compaction. Un hook déclaré sur l'événement correspondant s'exécute à chaque occurrence, indépendamment de ce que le modèle retient à cet instant.

Le mécanisme : un événement, une commande, une décision

Un hook se déclare dans settings.json, ou dans le fichier hooks.json d'un plugin, associé à un événement du cycle de vie et à un type d'action : une commande shell, un appel HTTP, un outil MCP, une invite ou un agent. Quand l'événement survient, le harnais exécute cette action et attend en retour une décision, avant que la question n'atteigne le modèle.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "./verifier-avant-commande.sh" }
        ]
      }
    ]
  }
}

Cette déclaration associe l'événement PreToolUse, restreint aux appels de l'outil Bash, à un script qui s'exécute avant chaque commande proposée. Chaque type de hook porte son propre délai d'expiration par défaut, différent selon l'événement qui le déclenche : la leçon suivante détaille ces délais événement par événement, ainsi que les champs JSON précis qu'un hook renvoie pour bloquer, autoriser ou enrichir ce que le modèle voit.

Hook contre règle de mémoire : ce que chacun garantit réellement

Une règle de mémoire dépend d'un modèle qui la relit et décide de l'appliquer, dans une fenêtre de contexte qui grossit au fil de la session. Un hook dépend du harnais, qui vérifie l'événement indépendamment de ce que la conversation contient à cet instant. La différence se voit surtout sur une session longue : une instruction répétée vingt fois dans un fichier de mémoire peut se diluer dans un contexte chargé, alors qu'un hook déclaré une seule fois continue de s'exécuter identiquement au millième appel comme au premier.

Traduire un automatisme voulu en hook plutôt qu'en note de mémoire est donc moins une question de style qu'une question de fiabilité mécanique : l'un dépend d'une lecture attentive du modèle, l'autre d'un événement que le harnais constate lui même.

Figure 1

Du déclenchement à la décision

Événement du cycle de vie

Une commande sur le point de s'exécuter, une session qui démarre, un fichier qui change : le harnais détecte l'événement, pas le modèle.

Hook consulté

settings.json ou le hooks.json d'un plugin indique quelle action lancer pour cet événement précis.

Action exécutée

Une commande shell, un appel HTTP, un outil MCP, une invite ou un agent tourne, selon le type déclaré.

Décision rendue

Le hook renvoie sa réponse au harnais, qui l'applique avant que la conversation ne reprenne son cours.

La séquence montre où le harnais intervient et où le modèle n'a plus la main, entre l'événement et la décision, aucune étape ne repose sur ce que le modèle retient.

Figure 2

Règle de mémoire contre hook déclaré

Fiabiliser un automatisme répété	Ce qui déclenche l'action	Comportement sur une session longue	Où l'automatisme se déclare
Règle écrite en mémoire	Une lecture du modèle, qui doit s'en souvenir au bon moment	Peut se diluer après une compaction ou un contexte chargé	Un fichier CLAUDE.md, interprété par le modèle
Hook déclaré	Un événement du cycle de vie, constaté par le harnais lui même	S'exécute identiquement à chaque occurrence de l'événement	settings.json ou le hooks.json d'un plugin, exécuté par le harnais

Le tableau isole trois critères pour distinguer une règle écrite en mémoire, qui dépend d'une lecture du modèle, d'un hook, qui dépend d'un événement constaté par le harnais.

Calibrez vous-même

Un développeur déclare un hook PreToolUse dans settings.json qui bloque tout appel de l'outil Bash contenant le motif rm suivi de -rf. Il demande ensuite à Claude Code d'exécuter une commande contenant ce motif, et voit le hook s'activer.

Écrivez en une phrase ce que cette situation établit, et en une phrase ce qu'elle n'établit pas.

Votre réponse, avant de voir le corrigé

Ce qu’il faut retenir

Un hook se déclenche parce qu'un événement du cycle de vie survient, jamais parce que le modèle décide de l'appliquer au moment d'agir.
Une règle répétée dans un fichier de mémoire peut se diluer dans un contexte chargé, un hook déclaré une seule fois s'exécute identiquement à chaque occurrence de l'événement.
Un hook se déclare dans settings.json ou dans le fichier hooks.json d'un plugin, associé à un type d'action parmi commande shell, appel HTTP, outil MCP, invite ou agent.
Chaque type de hook porte son propre délai d'expiration par défaut, détaillé événement par événement dans la leçon suivante.

À faire maintenant

Créez un fichier .claude/settings.json minimal dans un dépôt de test, déclarez-y un hook PreToolUse qui affiche un message avant chaque commande Bash pour observer le mécanisme se déclencher, puis retirez ce hook une fois la démonstration faite.

Vérifier à la source

Chaque affirmation datable de cette leçon renvoie ici au texte public qui la porte. Une source qui ne s’ouvre pas ne prouve rien.