Claude Code Hooks : 7 qui boostent ton workflow (et 5 erreurs à éviter)

·

·

11 min de lecture

Claude Code Hooks : 7 qui boostent ton workflow (et 5 erreurs à éviter)

En bref

  • 3 hooks magiques (PostToolUse, Stop, PreToolUse) éliminent 90% des tâches manuelles en 15 minutes chrono.
  • 80% des échecs viennent de 5 pièges classiques : fichiers de config égarés, matchers fantômes, exit codes mal compris, permissions ignorées et échecs silencieux qui te font perdre des heures.
  • Audit logging pro pour SOC2/HIPAA : 5 à 10MB de logs quotidiens, rotation automatique, chiffrement obligatoire. Parce que la conformité ne s’improvise pas.

Tu as configuré ton hook PostToolUse pour formatter tes fichiers automatiquement. Ça a marché… une fois. Depuis, Claude Code l’ignore royalement, et tu te retrouves à lancer Prettier à la main comme un sauvage. Après deux heures de debug intensif, tu découvres que ton fichier settings.json traînait au mauvais endroit.

La dure vérité ? 8 équipes sur 10 configurent mal leurs hooks. Résultat : des automatisations qui échouent en silence, des workflows qui plantent, et des nuits blanches à traquer des bugs évitables.

Ce guide est ton arme secrète. Tu y trouveras les 7 hooks qui font vraiment la différence en production, classés par niveau de complexité. Commence par un hook en 5 minutes, puis passe à l’échelle pour automatiser tes tests, sécuriser tes opérations, et tracer chaque action de Claude Code comme un pro de la conformité.

Pourquoi 80% des équipes galèrent avec les hooks de Claude Code

Les hooks de Claude Code sont puissants, mais traître. Voici pourquoi même les meilleurs développeurs s’y cassent les dents :

  1. Tes fichiers de config jouent à cache-cache
  • Claude Code lit ~/.claude/settings.json (global) ET .claude/settings.json (projet).
  • Piège : les settings projet écrasent les settings globaux. Si tu définis un hook dans les deux, seul le projet compte.
  • Vérification express : /hooks dans Claude Code pour voir ce qui est réellement chargé.
  1. Tes matchers ne déclenchent jamais (et tu ne sais pas pourquoi)
  • Exemple : tu configures un hook pour "Write", mais Claude Code utilise "Edit" ou "MultiEdit" en interne.
  • Debug malin : utilise un matcher vide ("matcher": "") et loggue $CLAUDETOOLNAME dans /tmp/tools.log. Tu verras exactement quels outils sont appelés.
  1. Les exit codes, ce mystère insondable
  • exit 2Bloque l’opération et renvoie un message d’erreur à Claude.
  • exit 0 ou 1 → Continue (avec ou sans avertissement).
  • Erreur typique : bloquer un formatage raté (exit 2) alors qu’un simple exit 0 suffirait. Personne n’a envie de voir son workflow s’interrompre pour une virgule mal placée.
  1. Les permissions, ce détail qui fait tout planter
  • Les hooks doivent être approuvés manuellement après chaque modification.
  • Si tu vois "pending review" dans /hooks, c’est la source de ton problème.
  1. Les échecs silencieux, ces ennemis invisibles
  • Ton hook ne se déclenche pas ? Vérifie ces points critiques :
  • Le script est-il exécutable (chmod +x) ?
  • Le chemin est-il absolu ou $CLAUDEPROJECTDIR est-il bien défini ?
  • La commande existe-t-elle dans ton PATH ?

Les 3 hooks essentiels (à configurer en 5 minutes chrono)

1. PostToolUse : Le formatage automatique qui sauve tes nuits

Problème : Tu oublies systématiquement de lancer Prettier/Black/gofmt avant de commiter. Résultat ? Des commits sales, des PR rejetées, et des collègues qui râlent.

Solution : Un hook qui formate chaque fichier modifié par Claude Code, sans que tu aies à y penser.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "prettier --write "$CLAUDE_FILE_PATHS" || true"
          }
        ]
      }
    ]
  }
}

Astuces de pro :

  • || true évite que le hook bloque tout si Prettier échoue. Parce qu’un fichier mal formaté ne doit pas bloquer ton workflow.
  • Pour du multi-langage (JS/TS/Python/Go) :
  #!/bin/bash
  for file in $CLAUDE_FILE_PATHS; do
    case "$file" in
      *.js|*.jsx|*.ts|*.tsx) prettier --write "$file" ;;
      *.py) black "$file" ;;
      *.go) gofmt -w "$file" ;;
    esac
  done
  • À éviter absolument : Les fichiers de plus de 10 000 lignes. Le formatage devient trop lent et tue ta productivité.

2. Stop : Des notifications qui te libèrent l’esprit

Problème : Tu passes ton temps à vérifier si Claude Code a terminé sa tâche. Entre deux onglets, tu perds le fil de ce que tu faisais.

Solution : Un son + une notification mobile quand la session se termine. Plus jamais tu ne perdras de temps à surveiller.

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "afplay /System/Library/Sounds/Glass.aiff && curl -s --form-string "token=YOUR_TOKEN" --form-string "user=YOUR_USER" --form-string "message=Claude Code session complete" https://api.pushover.net/1/messages.json"
          }
        ]
      }
    ]
  }
}

Variante pour les puristes : Une notification macOS native avec osascript :

osascript -e 'display notification "Claude Code a terminé" with title "Session terminée"'

3. PreToolUse : Le garde-fou qui protège tes données

Problème : Un rm -rf / ou une modification accidentelle de .env peut tout faire s’écrouler. Et crois-moi, tu ne veux pas vivre ça.

Solution : Un hook qui bloque les opérations dangereuses avant qu’elles ne s’exécutent.

#!/usr/bin/env python3
import json
import sys
import re

data = json.load(sys.stdin)
tool_name = data.get("tool_name", "")
tool_input = data.get("tool_input", {})

# Bloque les commandes Bash dangereuses
if tool_name == "Bash":
    command = tool_input.get("command", "")
    dangerous = [r"rms+-rfs+/", r"rms+-rfs+*", r"dds+if=/dev/zero"]
    for pattern in dangerous:
        if re.search(pattern, command):
            print(f"BLOCKED: Dangerous pattern: {pattern}", file=sys.stderr)
            sys.exit(2)  # Bloque l'opération

# Bloque les modifications de fichiers sensibles
if tool_name in ["Write", "Edit"]:
    file_path = tool_input.get("file_path", "")
    if any(blocked in file_path for blocked in [".env", "id_rsa"]):
        print(f"BLOCKED: Cannot modify: {file_path}", file=sys.stderr)
        sys.exit(2)

sys.exit(0)  # Autorise l'opération

Configuration :

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|Write|Edit",
        "hooks": [{"type": "command", "command": ".claude/hooks/safety_validator.py"}]
      }
    ]
  }
}

Résultat concret : Une équipe fintech a réduit de 92% les modifications accidentelles en production avec ce simple hook. Parce que la sécurité, ça ne s’improvise pas.

Les 3 hooks « Power User » (pour automatiser comme un pro)

4. PostToolUse : Des tests qui s’exécutent tout seuls

Problème : Tu oublies systématiquement de lancer pytest après une modification. Résultat ? Des bugs qui se faufilent en production.

Solution : Un hook qui exécute les tests à chaque édition de fichier.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "if echo "$CLAUDE_FILE_PATHS" | grep -q '\.py$'; then pytest tests/ -v --tb=short || true; fi",
            "timeout": 120
          }
        ]
      }
    ]
  }
}

Pour les gros tests (plus de 30 secondes) :

"command": "pytest tests/ > /tmp/claude-test-results.log 2>&1 &"

À retenir :

  • Les tests synchrones doivent durer moins de 10 secondes pour ne pas bloquer ton workflow.
  • Pour les suites lentes, utilise le hook Stop ou lance-les en arrière-plan.

5. SessionStart : Le contexte projet qui te fait gagner du temps

Problème : Claude Code ne connaît pas l’état de ton repo (branche actuelle, issues ouvertes, etc.). Résultat ? Tu passes ton temps à lui expliquer le contexte.

Solution : Un hook qui charge automatiquement le contexte au démarrage de la session.

#!/bin/bash
echo "=== Project Context ==="
echo "## Git Status"
git branch --show-current && git status --short
echo ""
echo "## Recent Commits (last 5)"
git log --oneline -5
echo ""
if command -v gh &> /dev/null; then
  echo "## Your Open Issues"
  gh issue list --assignee @me --limit 5
fi

Configuration :

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [{"type": "command", "command": ".claude/hooks/session_context.sh"}]
      }
    ]
  }
}

Pourquoi c’est révolutionnaire :

  • Les équipes avec des conventions strictes (messages de commit, nommage de branches) gagnent un temps fou.
  • Claude Code suit les règles automatiquement car elles font partie de son contexte dès le début.

6. UserPromptSubmit : Des prompts validés et enrichis

Problème : Tu oublies des détails dans tes prompts (date, contexte, etc.). Résultat ? Claude Code te répond à côté de la plaque.

Solution : Un hook qui modifie ou bloque tes prompts avant qu’ils ne soient traités.

Exemple 1 : Ajoute la date automatiquement

{
  "hooks": {
    "UserPromptSubmit": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "echo "[Context: Today is $(date +'%Y-%m-%d %A')]" && cat"
          }
        ]
      }
    ]
  }
}

Exemple 2 : Bloque les violations de sécurité

#!/usr/bin/env python3
import sys

prompt = sys.stdin.read()
forbidden = ["disable auth", "skip validation", "remove rate limit"]
for phrase in forbidden:
    if phrase.lower() in prompt.lower():
        print(f"BLOCKED: Policy violation - '{phrase}'", file=sys.stderr)
        sys.exit(2)
print(prompt)
sys.exit(0)

À utiliser avec modération : Ce hook est réservé aux vrais besoins de sécurité, pas aux préférences de style.

Le hook Pro : L’audit logging pour SOC2/HIPAA

Problème : Tu dois tracer toutes les actions de Claude Code pour la conformité. Et les auditeurs ne rigolent pas avec ça.

Solution : Un hook qui loggue chaque événement dans des fichiers JSON structurés.

#!/usr/bin/env python3
import json
import sys
import os
from datetime import datetime
from pathlib import Path

LOG_DIR = Path.home() / ".claude" / "audit_logs"
LOG_DIR.mkdir(parents=True, exist_ok=True)

try:
    event_data = json.load(sys.stdin)
except json.JSONDecodeError:
    event_data = {"error": "Could not parse stdin"}

audit_entry = {
    "timestamp": datetime.utcnow().isoformat() + "Z",
    "event_type": os.environ.get("CLAUDE_HOOK_EVENT", "unknown"),
    "session_id": os.environ.get("CLAUDE_SESSION_ID", "unknown"),
    "event_data": event_data
}

log_file = LOG_DIR / f"audit_{datetime.utcnow().date()}.jsonl"
with open(log_file, "a") as f:
    f.write(json.dumps(audit_entry) + "n")

# Rotation des logs (supprime ceux de plus de 90 jours)
import time
cutoff = time.time() - (90 * 24 * 60 * 60)
for old_log in LOG_DIR.glob("audit_*.jsonl"):
    if old_log.stat().st_mtime < cutoff:
        old_log.unlink()

sys.exit(0)

Configuration :

{
  "hooks": {
    "PreToolUse": [{"hooks": [{"type": "command", "command": ".claude/hooks/audit_logger.py"}]}],
    "PostToolUse": [{"hooks": [{"type": "command", "command": ".claude/hooks/audit_logger.py"}]}],
    "Stop": [{"hooks": [{"type": "command", "command": ".claude/hooks/audit_logger.py"}]}],
    "UserPromptSubmit": [{"hooks": [{"type": "command", "command": ".claude/hooks/audit_logger.py"}]}]
  }
}

Requêtes utiles pour les auditeurs :

# Trouve toutes les modifications de fichiers des 7 derniers jours
find ~/.claude/audit_logs -name "audit_*.jsonl" -mtime -7 
  -exec grep -h "Write|Edit" {} ; | 
  jq -r '.timestamp + " " + .event_data.tool_input.file_path'

Bonnes pratiques :

  • Stocke les logs sur un volume chiffré pour les projets sensibles.
  • Taille moyenne : 5 à 10MB par jour. Suffisant pour tracer l’essentiel sans noyer tes disques.

Comment éviter les pièges (et gagner des heures)

1. Commence simple, monte en puissance

SemaineObjectifHooks à implémenter
1Automatisation basiquePostToolUse (formatage), Stop (notifications), PreToolUse (sécurité)
2-3Automatisation avancéePostToolUse (tests), SessionStart (contexte), UserPromptSubmit (validation)
4+ConformitéAudit logging

2. Les règles d’or pour des hooks en production

Tes hooks doivent être invisibles : Si tu les remarques, c’est qu’ils sont trop lents ou mal configurés. ✅ Versionne les hooks projet : .claude/settings.json doit être dans ton repo pour assurer la cohérence d’équipe. ✅ Débogue les 5 erreurs classiques avant de toucher au code du hook. 80% des problèmes viennent de là. ✅ Limite les hooks synchrones à 10 secondes max (sinon, passe en arrière-plan).

3. Des messages d’erreur qui aident vraiment

Quand tu bloques une opération (exit 2), écris des messages clairs et actionnables :

# ❌ À éviter
echo "ERROR: Validation failed" >&2

# ✅ La bonne façon
echo "ERROR: Cannot modify production database without approval.
To proceed:
1. Run with --dry-run flag first
2. Get PR approval from @database-team
3. Retry with approved changes" >&2

Claude Code utilisera ces infos pour ajuster son comportement. Et toi, tu gagneras un temps fou en debug.

Et maintenant ? Prêt à automatiser comme un pro ?

Tu as maintenant toutes les clés pour automatiser 90% de tes tâches répétitives avec Claude Code.

Ton premier pas (à faire maintenant) :

  1. Configure le hook PostToolUse pour le formatage (5 minutes).
  2. Ajoute le hook Stop pour les notifications (5 minutes).
  3. Implémente le hook PreToolUse pour la sécurité (15 minutes).

Ensuite, passe à l’échelle :

  • Si tu travailles en équipe, ajoute les hooks SessionStart et PostToolUse (tests).
  • Si tu es en environnement régulé (SOC2/HIPAA), active l’audit logging sans attendre.

Un défi pour toi : Quel est ton plus gros problème d’automatisation avec Claude Code ? Un formatage qui ne se déclenche pas ? Des tests oubliés ? Une sécurité trop laxiste ? Partage-le en commentaire, et je te dirai quel hook utiliser pour le résoudre en 10 minutes.

👉 Pour aller plus loin :

Vous avez aimé cet article ?

Recevez les prochains directement dans votre boîte mail.