Mes vrais garde-fous, et ce qu'ils m'évitent

Pas un seul hook écrit à la main

Pour préparer cette leçon, j'ai ouvert mon fichier de réglages personnel, ~/.claude/settings.json. Il ne contient pas une seule ligne de hook. Pourtant, une vingtaine sont actifs chez moi.

Ils arrivent tous par des plugins, des paquets d'extensions pour Claude Code. Un plugin peut apporter ses propres hooks dans un fichier hooks/hooks.json, qui s'ajoutent aux tiens. La plupart des miens viennent d'un plugin appelé ECC. Pour les voir, tape /hooks dans Claude Code : chaque hook y est listé avec sa provenance. Ceux d'un plugin sont marqués comme tels, et le détail d'un hook donne le nom de son plugin.

Voici la forme de l'un d'eux, tirée du fichier du plugin. La commande est raccourcie, le reste est tel quel :

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Write|Edit|MultiEdit",
        "hooks": [
          {
            "type": "command",
            "command": "node ... config-protection.js",
            "timeout": 5
          }
        ]
      }
    ]
  }
}

Lis-le de haut en bas. Avant l'utilisation d'un outil (PreToolUse), si cet outil est Write, Edit ou MultiEdit, les outils qui écrivent des fichiers, lance ce script. S'il n'a pas fini en 5 secondes, abandonne-le. On décortique chaque champ au chapitre 2.

La porte qui exige des faits

Le hook qui me sert le plus s'appelle GateGuard. Dans ses messages, il se présente comme « Fact-Forcing Gate » : la porte qui force les faits. Il se place avant les outils d'écriture et avant les commandes, et il refuse la première tentative.

J'ai lu son code. Voici ce qu'il exige avant d'ouvrir :

• avant la première modification d'un fichier : la liste des fichiers qui l'importent, les fonctions publiques touchées, la forme des données qu'il lit ou écrit, et ma demande citée mot pour mot ;
• avant la première commande de la session : ma demande en une phrase, et ce que la commande va vérifier ou produire ;
• avant une commande destructrice, comme une suppression récursive : la liste de ce qui sera modifié ou supprimé, un moyen de revenir en arrière, et ma demande citée mot pour mot.

Claude doit répondre par écrit, puis relancer la même action. La deuxième fois, la porte s'ouvre.

Il a servi pendant l'écriture de cette formation

Pour vérifier les scripts de cette formation, Claude a voulu lancer un test qui créait un dépôt git temporaire, puis le supprimait. La porte l'a arrêté avec ce message, copié tel quel :

[Fact-Forcing Gate]

Destructive command detected. Before running, present:

1. List all files/data this command will modify or delete
2. Write a one-line rollback procedure
3. Quote the user's current instruction verbatim

Present the facts, then retry the same operation.

En dressant la liste demandée, Claude a vu que ce dossier temporaire sortait de la zone où je l'avais autorisé à écrire. Il a retiré cette partie du test avant de relancer. Sans la question, la commande serait passée.

Le commentaire en tête du script explique l'idée : au lieu de demander « tu es sûr ? », question à laquelle un modèle répond toujours oui, il exige des faits concrets. Le hook ne vérifie pas les réponses. Il refuse une fois, note l'action comme vue, et laisse passer la suivante. Sa force est ailleurs : les réponses s'écrivent sous mes yeux, et une liste vide ou fausse se voit avant les dégâts.

Le verrou sur la configuration du linter

Le deuxième hook est celui de l'exemple plus haut. Il protège les fichiers de configuration des outils de contrôle : eslint.config.mjs, .prettierrc, biome.json et leurs variantes. Un linter est un outil qui signale les erreurs de style et les pièges dans le code.

Si Claude tente de modifier une de ces configurations alors qu'elle existe déjà, le hook refuse avec le code de sortie 2 et ce message :

BLOCKED: Modifying eslint.config.mjs is not allowed. Fix the source code to satisfy linter/formatter rules instead of weakening the config. If this is a legitimate config change, disable the config-protection hook temporarily.

En clair : corrige le code au lieu d'affaiblir la règle. Sur ce site, la configuration ESLint livrée par le modèle de départ ne fonctionne pas avec la version 16 de eslint-config-next. Le raccourci facile serait de réécrire la configuration jusqu'à ce que le contrôle passe. Le hook ferme cette porte. La correction attend mon accord, notée dans le CLAUDE.md du projet avec la mention « un hook protège ce fichier ».

Les fichiers .env : ce que j'ai découvert

Troisième garde-fou, celui de la première leçon. Dans le dossier de ma chaîne de vidéos, la consigne de CLAUDE.md est doublée par une règle dans .claude/settings.json :

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

Ce n'est pas un hook, c'est une règle de permission « deny » : un refus que Claude Code applique lui-même. L'esprit est le même. La documentation le dit : ces règles « sont appliquées par Claude Code, pas par le modèle ».

Puis j'ai vérifié le projet de ce site. La phrase de CLAUDE.md y était seule : aucune règle deny, aucun hook ne la doublait. Exactement le cas de la première leçon, une consigne que Claude « essaie » de suivre.

Et même la règle deny a une limite, écrite dans la documentation. Elle couvre les outils de fichiers de Claude et les commandes qu'il reconnaît, comme cat, head ou tail. Elle ne voit pas une commande qui lit sans nommer le fichier, ni un script Node ou Python qui l'ouvre lui-même.

Attention pour la troisième couche : d'après la page d'installation, le bac à sable ne fonctionne pas sous Windows natif. Il demande WSL 2, le Linux intégré à Windows. Sur ma machine Windows, ce sont donc les deux premières couches qui tiennent.

Ce que la suite t'apporte

La suite t'apprend à écrire tes propres garde-fous, sans dépendre d'un plugin :

• Chapitre 2 : les événements, le fichier settings.json et sa portée, puis le code de sortie 2 et la réponse JSON. Tu repars avec le hook qui protège tes fichiers .env, testé sous Windows avec des chemins comme C:\projet\.env.
• Chapitre 3 : Prettier après chaque modification, les tests lancés avant que Claude s'arrête, une notification quand il t'attend. Puis la sécurité : lire un hook avant de l'activer, et le déboguer. En lisant les miens, j'en ai trouvé un qui ne fait rien sous Windows. Je te dis lequel.