Automatisation

Automatisation Claude Code : Hooks, Skills et Rules Expliqués

Charles Krzentowski10 min read

Ça fait un moment que vous utilisez Claude Code. Il lit vos fichiers, écrit du code, lance des commandes. Ça marche bien. Mais soyons honnêtes : vous faites encore à la main plein de trucs qui pourraient se passer tout seuls. Reformater le code après chaque modif. Vérifier que personne n'a lancé un rm -rf / par accident. Suivre le même enchaînement de cinq étapes pour déployer, encore et encore.

Claude Code a trois mécanismes qui automatisent tout ça : les hooks, les skills et les rules. Seulement 12% des configurations dans notre analyse utilisent des hooks, mais celles qui le font atteignent 6.8/10 en moyenne, contre 2.1 sans. L'écart est énorme — et la mise en place prend dix minutes.

On commence par quelque chose de concret, tout de suite.

Votre premier hook : formater automatiquement chaque fichier que Claude touche

Voici le scénario. Claude modifie un fichier TypeScript. Le code tourne, mais l'indentation est bancale, il manque des points-virgules — bref, votre config Prettier n'est pas respectée. Vous demandez à Claude de corriger le formatage. C'est un échange gaspillé.

Au lieu de ça, on va faire en sorte que le formatage se fasse tout seul, après chaque modification.

Créez ce fichier dans .claude/hooks/format-on-save.sh :

#!/bin/bash
# S'exécute après que Claude crée ou modifie un fichier

INPUT=$(cat)
FILE=$(echo "$INPUT" | jq -r '.input.file_path // empty')

if [ -z "$FILE" ]; then
  exit 0
fi

# Formater selon le type de fichier
case "$FILE" in
  *.ts|*.tsx|*.js|*.jsx)
    npx prettier --write "$FILE" 2>/dev/null
    ;;
  *.py)
    ruff format "$FILE" 2>/dev/null
    ;;
  *.go)
    gofmt -w "$FILE" 2>/dev/null
    ;;
esac

Rendez-le exécutable :

chmod +x .claude/hooks/format-on-save.sh

Puis enregistrez-le dans .claude/settings.json :

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "command": ".claude/hooks/format-on-save.sh"
      }
    ]
  }
}

C'est tout. La prochaine fois que Claude touche un fichier, Prettier (ou ruff, ou gofmt) passe automatiquement derrière. Zéro prompt supplémentaire, zéro nettoyage manuel.

Essayez maintenant. Demandez à Claude de créer une petite fonction dans un fichier TypeScript. Regardez la sortie — le fichier est reformaté automatiquement après l'édition. Plus jamais besoin d'y penser.

Hooks, skills, rules : c'est quoi la différence ?

Avant d'aller plus loin, mettons les idées au clair. Tout le monde confond les trois au début, donc voici la version simple :

  • Les hooks exécutent du code avant ou après chaque appel d'outil. Ils sont automatiques — vous ne les déclenchez pas, ils se lancent tout seuls. C'est comme des event listeners.
  • Les skills sont des commandes slash que vous tapez : /deploy, /review, /ticket PROJ-123. Chacun emballe un workflow multi-étapes que vous pouvez lancer par son nom.
  • Les rules sont des instructions qui se chargent automatiquement selon les fichiers sur lesquels Claude travaille. Quand il touche un .tsx, vos conventions frontend apparaissent. Quand il touche du SQL, vos règles de base de données prennent le relais.
Mécanisme Quand ça tourne Ce que ça fait Vous le déclenchez ?
Hooks Avant/après chaque appel d'outil Intercepter, bloquer ou transformer Non — automatique
Skills Quand vous tapez une commande slash Exécuter un workflow complet Oui — c'est vous qui lancez
Rules Quand Claude touche des fichiers correspondants Injecter des instructions adaptées Non — automatique

Maintenant, regardons chacun en détail.

Les hooks : votre filet de sécurité et votre pilote automatique

Un hook, c'est un script shell que Claude Code exécute à un moment précis. Il y a quatre types :

  • PreToolUse — se lance avant un appel d'outil. Il peut le bloquer.
  • PostToolUse — se lance après un appel d'outil. Il peut transformer la sortie.
  • Stop — se lance quand Claude finit son tour.
  • SessionStart — se lance une seule fois, au démarrage de la session.

Vous venez de voir PostToolUse avec le formateur. Passons au plus important : une garde de sécurité.

La garde de sécurité PreToolUse

Ce hook intercepte les commandes dangereuses avant qu'elles ne s'exécutent. Copiez ceci dans .claude/hooks/pre-tool-guard.sh :

#!/bin/bash
# Bloquer les commandes shell destructrices

INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.tool')
COMMAND=$(echo "$INPUT" | jq -r '.input.command // empty')

if [ "$TOOL" = "Bash" ]; then
  if echo "$COMMAND" | grep -qE 'rm -rf /|git push --force|git reset --hard|DROP TABLE'; then
    echo '{"blocked": true, "reason": "Commande destructrice bloquée par la garde de sécurité"}'
    exit 0
  fi
fi

echo '{"blocked": false}'

chmod +x .claude/hooks/pre-tool-guard.sh

Enregistrez-le dans settings.json :

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "command": ".claude/hooks/pre-tool-guard.sh"
      }
    ]
  }
}

À partir de maintenant, si Claude essaie de lancer rm -rf / ou git push --force, le hook l'intercepte, renvoie blocked: true, et Claude voit la raison. La commande ne s'exécute jamais.

Vous pouvez le tester tout de suite, sans même ouvrir Claude :

echo '{"tool":"Bash","input":{"command":"rm -rf /"}}' | .claude/hooks/pre-tool-guard.sh

Vous devriez voir {"blocked": true, "reason": "Commande destructrice bloquée par la garde de sécurité"}. Votre filet de sécurité fonctionne.

SessionStart : donner du contexte à Claude dès le départ

Ce hook se lance une seule fois à l'ouverture de Claude Code. Il injecte du contexte pour que Claude s'oriente immédiatement :

#!/bin/bash
# .claude/hooks/session-start.sh

echo "## État Git Actuel"
echo "Branche : $(git branch --show-current)"
echo "Dernier commit : $(git log --oneline -1)"
echo "Fichiers modifiés :"
git status --short
echo ""
echo "## TODOs récents"
grep -r "TODO\|FIXME\|HACK" src/ --include="*.ts" -l 2>/dev/null | head -10

Chaque session démarre avec Claude sachant sur quelle branche vous êtes, quel était le dernier commit, et quels fichiers ont des TODOs ouverts. Fini le « sur quelle branche je suis ? » comme première question.

Les skills : vos commandes slash personnelles

Les skills, c'est là que ça devient vraiment fun. Vous écrivez un fichier markdown qui décrit un workflow, et il devient une commande slash que vous pouvez taper quand vous voulez.

Votre premier skill : une commande de déploiement

Créez .claude/skills/deploy.md :

---
name: deploy
description: Déployer la branche courante en staging ou production
---

# Workflow de déploiement

1. Lancer `npm run build` pour vérifier que le build passe
2. Lancer `npm run test` pour confirmer que tous les tests passent
3. Vérifier la branche courante : `git branch --show-current`
4. Si sur `main` :
   - Déployer en production : `railway up --service production`
   - Vérifier le health check : `curl -s https://api.example.com/health`
5. Si sur une autre branche :
   - Déployer en staging : `railway up --service staging`
   - Afficher l'URL de staging pour revue

Toujours reporter le statut de déploiement et l'URL.

Maintenant tapez /deploy dans Claude Code. Claude build, teste, vérifie la branche, déploie dans le bon environnement et vérifie le health check. Une seule commande au lieu de cinq étapes manuelles.

Un skill de revue de code

Celui-ci, vous allez l'utiliser tous les jours. Sauvegardez-le dans .claude/skills/review.md :

---
name: review
description: Revoir les changements stagés avant de commiter
---

# Revue de code

1. Lancer `git diff --staged` pour voir tous les changements
2. Pour chaque fichier, vérifier :
   - Gestion d'erreurs : les opérations async sont-elles dans un try/catch ?
   - Sécurité : des secrets en dur, injection SQL ou XSS ?
   - Types : des `any` qui devraient être spécifiques ?
   - Tests : les fonctions modifiées ont-elles des mises à jour de tests ?
3. AUTO-CORRIGER les problèmes mécaniques (formatage, types manquants, bugs évidents)
4. Reporter les issues CRITIQUES (à corriger impérativement) et INFORMATIONNELLES (à considérer)
5. Si pas d'issue critique : suggérer un message de commit

Tapez /review avant de commiter et Claude vérifie votre travail. Les problèmes mécaniques sont corrigés sur place. Les décisions ambiguës sont signalées pour que vous tranchiez.

Des skills qui acceptent des arguments

Les skills peuvent recevoir des paramètres. Sauvegardez comme .claude/skills/ticket.md :

---
name: ticket
description: Commencer le travail sur un ticket spécifique
---

L'utilisateur fournira un ID de ticket (ex. `/ticket PROJ-123`).

1. Récupérer les détails du ticket
2. Créer une nouvelle branche : `git checkout -b feat/PROJ-123-description`
3. Lire les fichiers concernés mentionnés dans le ticket
4. Proposer un plan d'implémentation avant d'écrire du code
5. Attendre l'approbation avant de continuer

Tapez /ticket PROJ-123 et Claude lit le ticket, crée une branche, trouve les fichiers pertinents et propose un plan — le tout avant d'écrire une seule ligne de code.

Les rules : des instructions qui se chargent au bon moment

Vous avez déjà vu les rules dans le guide de configuration. Voici pourquoi elles sont cruciales pour l'automatisation : elles gardent le contexte de Claude propre et léger.

Imaginez que vous avez 200 lignes de conventions frontend, 150 lignes de règles backend et 100 lignes de standards base de données. Si vous fourrez les 450 lignes dans CLAUDE.md, Claude charge tout à chaque interaction — même quand vous éditez juste un fichier CSS.

Avec les rules, Claude charge les conventions frontend uniquement quand il touche des fichiers .tsx, les règles de base de données uniquement quand il travaille sur des migrations, et les avertissements de sécurité uniquement près de fichiers sensibles.

Voici une rule de sécurité qui fait la différence :

<!-- .claude/rules/security.md -->
---
globs: [".env*", "*.pem", "*.key", "*secret*", "*credential*"]
---

- JAMAIS commiter ce fichier dans le contrôle de version
- JAMAIS logger son contenu
- JAMAIS inclure ces valeurs dans des messages d'erreur ou réponses API
- Si ce fichier doit être modifié, expliquer les changements nécessaires mais ne pas afficher les valeurs actuelles

Quand Claude touche un fichier qui matche ces patterns, ces rules apparaissent automatiquement. Quand il travaille sur du code sans rapport, elles restent à l'écart.

L'aide-mémoire : quand utiliser quoi

C'est la question que tout le monde pose. Voici comment décider :

Utilisez un hook quand l'action doit se produire à chaque fois, sans que personne n'y pense. Formatage à la sauvegarde. Blocage de commandes dangereuses. Log de chaque appel d'outil. Si un humain ne devrait pas avoir à s'en souvenir, c'est un hook.

Utilisez un skill quand vous avez un process multi-étapes que vous répétez régulièrement. Déployer. Revoir du code. Démarrer un ticket. Écrire une migration. Si vous en feriez une checklist, c'est un skill.

Utilisez une rule quand les instructions dépendent du fichier sur lequel Claude travaille. Conventions frontend pour les .tsx. Sécurité SQL pour les migrations. Avertissements pour les .env. Si le conseil c'est « quand tu bosses sur X, suis ces consignes », c'est une rule.

Les trois ensemble : un exemple concret

Voici comment hooks, skills et rules fonctionnent en tandem sur un workflow de migration de base de données :

  1. Rule (.claude/rules/database.md) — quand Claude touche des fichiers de migration, elle charge automatiquement vos conventions : requêtes paramétrées, exigences de rollback, conventions de nommage.

  2. Hook (PreToolUse sur Bash) — si Claude essaie de lancer une commande de migration, le hook vérifie qu'un fichier de rollback existe. Pas de rollback ? La commande est bloquée.

  3. Skill (/migrate) — une commande slash qui crée le fichier de migration à partir d'un template, génère le rollback correspondant, exécute la migration contre une base de test, et rapporte le résultat.

La rule apporte la connaissance. Le hook impose la contrainte. Le skill emballe le workflow. Chaque pièce fait un seul job, bien.

Quand ça ne marche pas

Si vos hooks, skills ou rules ne se déclenchent pas, voici comment déboguer :

# Lancer Claude en mode verbose pour voir l'exécution des hooks
claude --verbose

# Tester un hook indépendamment
echo '{"tool":"Bash","input":{"command":"rm -rf /"}}' | .claude/hooks/pre-tool-guard.sh

Les suspects habituels :

  • Script de hook sans permissions d'exécution. Corrigez avec chmod +x .claude/hooks/votre-hook.sh
  • Pattern glob qui ne matche pas. Le pattern **/api/**/*.ts est différent de api/**/*.ts. Testez le vôtre contre des chemins de fichiers réels.
  • Skill introuvable. Assurez-vous qu'il est dans .claude/skills/ avec le bon name: dans le frontmatter.

Ce que vous avez construit

Si vous avez suivi, vous avez maintenant :

  • Une garde de sécurité qui bloque les commandes destructrices avant qu'elles ne s'exécutent
  • Un auto-formateur qui nettoie chaque fichier que Claude touche
  • Un skill de déploiement qui condense tout votre workflow de deploy en une seule commande
  • Un skill de revue qui vérifie votre code avant que vous ne commitiez
  • Des rules qui injectent les bonnes conventions au bon moment

La plupart des utilisateurs de Claude Code n'arrivent jamais là. Vous venez de construire un environnement de développement sur mesure qui bosse pour vous automatiquement.

Prêt pour la suite ? Voici où aller :

Questions fréquentes

Les hooks ralentissent-ils les choses ?

Un guard de sécurité basé sur grep ajoute 10 à 50 millisecondes par appel d'outil — vous ne le sentirez pas. Par contre, un hook PostToolUse qui lance Prettier ajoute 200 à 500 ms par édition. Gardez vos hooks rapides. Si un hook doit faire du travail lourd, lancez le processus en arrière-plan pour que Claude n'attende pas.

Puis-je partager des hooks entre tous mes projets ?

Oui. Placez les hooks partagés dans ~/.claude/hooks/ et référencez-les avec des chemins absolus dans votre ~/.claude/settings.json global. Les hooks propres au projet vont dans .claude/hooks/ avec des chemins relatifs dans les réglages du projet.

Que se passe-t-il si un hook plante ?

Claude Code attrape les erreurs de hooks et continue comme si le hook n'existait pas — l'appel d'outil s'exécute normalement. L'erreur apparaît en mode verbose. C'est un design safety-first : un hook cassé n'empêche jamais Claude de fonctionner. Mais testez vos hooks sérieusement — une garde de sécurité cassée qui échoue en silence, c'est pire que pas de garde du tout.

Un skill peut-il appeler un autre skill ?

Pas directement. Il n'y a pas de mécanisme où /deploy appelle /review. Si vous avez besoin d'un workflow composé, construisez un seul skill qui inclut toutes les étapes. Sinon, utilisez un hook pour déclencher de la logique supplémentaire après qu'un skill se termine.

Comment les rules interagissent-elles avec CLAUDE.md ?

Les deux sont chargées dans le contexte, et Claude suit tout. Si une rule contredit CLAUDE.md, l'instruction la plus spécifique l'emporte généralement. Mais évitez les contradictions dès le départ — utilisez CLAUDE.md pour les instructions globales du projet et les rules pour les surcharges spécifiques à certains types de fichiers.