Claude Code au-delà du chat : hooks, sous-agents et mode headless

Automatiser des actions avec les hooks

Les hooks permettent d'exécuter une commande shell à des moments précis du cycle de vie de l'agent : avant ou après un appel d'outil, à l'arrêt de la session, etc. Contrairement aux instructions dans un CLAUDE.md (que le modèle peut ignorer), un hook s'exécute systématiquement, ce qui en fait le bon endroit pour imposer des garde-fous durs.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "npx prettier --write \"$CLAUDE_FILE_PATH\"" }
        ]
      }
    ]
  }
}

Ce hook reformate automatiquement chaque fichier modifié, sans dépendre de la mémoire du modèle. On peut aussi bloquer une action en faisant échouer le hook (code de sortie non nul), par exemple pour interdire toute écriture dans .env.

Sous-agents pour isoler le contexte

Un sous-agent (défini dans .claude/agents/*.md) tourne dans son propre contexte, avec son propre prompt système et éventuellement un accès restreint aux outils. C'est utile pour deux raisons distinctes : paralléliser des recherches indépendantes, et éviter de polluer le contexte principal avec des résultats volumineux (logs de build, sortie de grep massive). Un agent Explore en lecture seule, par exemple, peut cartographier un module entier et ne renvoyer qu'un résumé de dix lignes.

Scripter Claude Code en mode headless

Le flag -p (print) transforme le CLI en outil scriptable, sans interface interactive — précieux en CI ou dans un pipeline de revue automatisée :

claude -p "Liste les fonctions exportées sans test associé" \
  --output-format json \
  --allowedTools "Read,Grep" > report.json

La sortie JSON structurée (avec coût, tours utilisés, résultat) s'intègre facilement dans un script qui décide, par exemple, de faire échouer un job GitHub Actions si des fonctions critiques ne sont pas testées.

Étendre les capacités via MCP

Le Model Context Protocol connecte Claude Code à des systèmes externes (base de données, tracker de tickets, API interne) via des serveurs MCP déclarés dans la configuration. Une fois connecté, un serveur expose ses outils au même titre que Read ou Bash : le modèle peut interroger une table Postgres ou créer un ticket Linear sans code d'intégration ad hoc côté projet.

En pratique, ces quatre mécanismes se combinent : un hook garantit la sécurité de base, un sous-agent isole une exploration coûteuse, le mode headless orchestre le tout depuis un script, et MCP relie l'agent au reste de votre système d'information.