Introduction aux hooks

Introduction aux hooks

Les hooks permettent d’exécuter des commandes avant ou après que Claude tente d’utiliser un outil. Formulé ainsi, cela ressemble à un détail d’implémentation ; en pratique, c’est le mécanisme qui vous rend le contrôle. Formater le code après chaque modification, lancer les tests dès qu’un fichier change, interdire l’accès à certains fichiers : autant de règles que vous cessez de répéter à Claude au fil des sessions, parce qu’elles sont désormais appliquées par votre machine, systématiquement et sans négociation possible.

Comment fonctionnent les hooks

Rappelons d’abord le flux normal de Claude Code. Quand vous posez une question, votre requête est envoyée au modèle Claude avec les définitions d’outils. Claude peut décider d’utiliser un outil en fournissant une réponse formatée, puis Claude Code exécute cet outil et renvoie le résultat. Ce cycle se répète jusqu’à ce que la tâche soit terminée.

Les hooks s’insèrent dans ce processus, vous permettant d’exécuter du code juste avant ou juste après l’exécution de l’outil. Le point décisif est qu’ils s’exécutent chez vous, dans Claude Code, et non dans le modèle. Ce n’est donc pas une consigne que Claude pourrait interpréter de travers ou perdre de vue au bout de quarante messages : c’est une commande qui tourne à chaque fois, indépendamment de ce que le modèle a compris.

De cette position dans le cycle découlent deux types de hooks, aux pouvoirs très inégaux :

Configuration des hooks

Les hooks sont définis dans les fichiers de paramètres de Claude, et l’emplacement que vous choisissez détermine leur portée. ~/.claude/settings.json est global et affecte tous vos projets : c’est là que vivent vos habitudes personnelles, celles que vous voulez retrouver partout. .claude/settings.json appartient au projet et est partagé avec l’équipe, ce qui en fait la bonne place pour une règle de formatage que tout le monde doit respecter. .claude/settings.local.json, enfin, reste dans le projet mais ne concerne que vous, pour les réglages que vos collègues n’ont aucune raison d’hériter.

Vous pouvez écrire les hooks à la main dans ces fichiers ou passer par la commande /hooks dans Claude Code, qui vous guide dans la création de l’entrée sans que vous ayez à mémoriser la structure JSON.

Hooks PreToolUse

Les hooks PreToolUse s’exécutent avant l’exécution d’un outil. Ils incluent un matcher qui spécifie quels types d’outils cibler :

{
  "PreToolUse": [
    {
      "matcher": "Read",
      "hooks": [
        {
          "type": "command",
          "command": "node /chemin/vers/hooks/read_hook.js"
        }
      ]
    }
  ]
}

Votre commande reçoit les détails de l’appel d’outil que Claude veut faire, et vous pouvez laisser passer ou bloquer l’opération. Avec le matcher Read ci-dessus, chaque tentative de lecture traverse votre script avant que le moindre octet ne soit transmis au modèle. C’est le seul instant où vous pouvez encore dire non.

Hooks PostToolUse

Les hooks PostToolUse s’exécutent après l’exécution d’un outil :

{
  "PostToolUse": [
    {
      "matcher": "Write|Edit|MultiEdit",
      "hooks": [
        {
          "type": "command",
          "command": "node /chemin/vers/hooks/edit_hook.js"
        }
      ]
    }
  ]
}

Comme l’outil a déjà été exécuté, les hooks PostToolUse ne peuvent pas bloquer l’opération. En revanche, ils peuvent exécuter des opérations de suivi ou fournir du feedback supplémentaire à Claude. Le matcher couvre ici les trois outils d’écriture : dès que Claude touche à un fichier, votre script se lance, et ce qu’il renvoie remonte à Claude, qui peut en tenir compte pour la suite de son travail.

Applications pratiques

Ces deux moments couvrent l’essentiel des besoins réels. Côté PostToolUse, le formatage automatique après édition épargne les diffs pollués par des questions d’indentation, et le lancement des tests dès qu’un fichier change signale la régression pendant que Claude a encore la modification en tête plutôt qu’une heure plus tard. Un linter ou un vérificateur de types joue le même rôle sur la qualité du code, tandis qu’un simple journal des fichiers consultés ou modifiés vous laisse, en fin de session, une trace exploitable de ce qui s’est passé. Côté PreToolUse, le contrôle d’accès empêche Claude de lire ou de modifier certains fichiers, et la validation vérifie vos conventions de nommage ou vos standards de code avant qu’un fichier mal nommé n’atterrisse dans le dépôt.

Retenez la distinction : les hooks PreToolUse vous donnent le contrôle sur ce que Claude peut faire, tandis que les hooks PostToolUse vous permettent d’améliorer ce que Claude a fait.