Les valeurs par défaut de Claude Code vous emmènent loin. Mais il y a un point — généralement vers le troisième mois d'usage sérieux — où vous les avez dépassées. Vous voulez un effet de bord déterministe après chaque appel d'outil. Vous voulez que l'agent lise votre wiki interne. Vous voulez livrer un outil custom qui parle à l'API maison de votre entreprise.

C'est à ça que sert cet article. Quatre patterns :

1. Hooks — colle déterministe entre les étapes de l'agent.
2. Serveurs MCP — données d'entreprise que l'agent peut lire.
3. Outils custom — vos propres commandes câblées dans l'agent.
4. Chirurgie de system prompt — quand les prompts seuls ne suffiront pas.

1. Hooks — colle déterministe

Un hook est un script qui se déclenche sur un événement connu : onFileEdit, onShellRun, onSessionStart, onSessionEnd, etc. Ce ne sont pas de l'« IA » ; c'est du shell pur.

Pourquoi ils comptent : ils permettent d'ajouter des garanties déterministes autour d'un agent par ailleurs probabiliste.

Des exemples que je fais tourner sur chaque projet :

{
  "hooks": {
    "onSessionStart": "scripts/claude-onstart.sh",
    "onFileEdit": "scripts/claude-onedit.sh",
    "onSessionEnd": "scripts/claude-onend.sh"
  }
}

scripts/claude-onstart.sh :

#!/usr/bin/env bash
# Snapshot du working tree avant que l'agent démarre.
git stash push -u -m "claude-pre-session-$(date +%s)" --keep-index || true

scripts/claude-onedit.sh :

#!/usr/bin/env bash
# Après chaque édition, prettier sur le fichier modifié uniquement.
file="$1"
if [ -f "$file" ]; then
  pnpm prettier --write "$file" --log-level silent
fi

scripts/claude-onend.sh :

#!/usr/bin/env bash
# En fin de session, on archive le transcript.
cp ~/.claude/sessions/last.jsonl /var/log/claude/$(date +%F-%H%M).jsonl

Trois hooks. Chaque session est désormais snapshot-able, formatée et auditée. Aucun n'est de l'IA ; tous sont de l'infrastructure.

2. Serveurs MCP — vos données dans l'agent

Le Model Context Protocol (MCP) est le standard pour permettre à un agent de lire des sources de données externes au moment de la session. Au lieu de coller une page Confluence, vous branchez le serveur MCP et l'agent peut le parcourir à la demande.

Les patterns que j'ai vus payer :

• MCP pour le bug tracker. L'agent lit le ticket, commentaires inclus, avant de commencer à implémenter.
• MCP pour le schéma de la DB de staging. L'agent peut introspecter les tables au lieu de deviner.
• MCP pour les runbooks. L'agent lit docs/runbooks/<incident-type>.md automatiquement.

La configuration vit dans .claude/mcp.json :

{
  "servers": {
    "linear": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-linear"],
      "env": { "LINEAR_API_KEY": "${LINEAR_API_KEY}" }
    },
    "company-docs": {
      "command": "node",
      "args": ["./mcp/company-docs.js"]
    }
  }
}

Deux avertissements :

• Les serveurs MCP tournent avec vos privilèges. Traitez-les comme des CLIs ; revoyez leur code avant de les brancher.
• MCP peut fuir. Si vous branchez un serveur qui expose des données client, chaque session peut les lire. Scopez serré.

3. Outils custom — vos propres verbes

Les sub-agents et slash commands vous permettent de réutiliser du texte. Les outils custom vous permettent d'ajouter des verbes appelables.

Exemple : un outil deploy-preview. L'agent ne devrait pas lancer un shell pour déployer un preview — trop de façons pour que ça parte mal. À la place, exposez un outil :

{
  "tools": {
    "deploy-preview": {
      "description": "Déploie un preview environment pour la branche courante.",
      "schema": {
        "type": "object",
        "properties": {
          "branch": { "type": "string" }
        },
        "required": ["branch"]
      },
      "command": "scripts/deploy-preview.sh"
    }
  }
}

L'agent voit maintenant un verbe deploy-preview avec une entrée typée. Le script que vous écrivez décide ce qu'il fait. L'agent ne peut pas s'évader du contrat.

C'est le même pattern que j'utiliserais pour :

• run-load-test
• migrate-staging
• tail-prod-logs (lecture seule)
• notify-pager-duty

Chacun est un garde-fou qui dit « l'agent peut faire cette chose, exactement comme ça, jamais plus profond ».

4. Chirurgie de system prompt

Parfois le comportement d'un sub-agent est presque bon et un ajustement du system prompt comble l'écart. Trois patterns :

4a. Le bloc « rules »

Mettez toujours les non-négociables sous un header nommé rules :

# rules
- Ne jamais ajouter @ts-ignore.
- Ne jamais modifier les fichiers dans /infra/.
- Toujours lancer `pnpm test` avant de déclarer le succès.

L'agent les traite comme plus dures que de simples instructions parce qu'elles ressemblent à une liste de lois.

4b. Schéma de sortie en premier

Si vous voulez une sortie structurée (handoffs, JSON, YAML), mettez le schéma avant l'explication en prose. Les agents s'ancrent sur les 200 premiers tokens.

# schéma de sortie (toujours en haut du system prompt)
status: ok | needs-human | failed
artifacts: [path: string]
notes: string
next: code-reviewer | release-bot | done

# rationale (sous le schéma, jamais au-dessus)
# Tu produis ceci pour que le prochain agent du pipeline sache exactement où tu en es.

4c. Contre-exemples

Montrez ce qu'il ne faut PAS faire :

# mauvaise sortie
"Fait. Le cache est implémenté."

# bonne sortie
status: ok
artifacts: [{path: "lib/cache.ts"}]
notes: "LRU + TTL implémentés. Tous les tests verts."
next: code-reviewer

Les contre-exemples sont bizarrement plus efficaces que les exemples positifs pour obtenir la conformité. Je n'ai pas de théorie profonde du pourquoi ; empiriquement, ça marche.

Quand vous avez besoin des quatre ensemble

Le workflow avancé qui éclaire les vraies équipes :

hook (onSessionStart)         → snapshot stash
l'agent lit CLAUDE.md         → contexte
l'agent appelle un MCP        → lit le ticket Linear
l'agent appelle un outil custom → run-load-test
hook (onFileEdit)             → prettier
l'agent émet un handoff structuré → code-reviewer
hook (onSessionEnd)           → archive le transcript

Chaque couche ajoute du déterminisme, de la traçabilité ou de la capacité. Aucune n'est « l'agent ». Toutes sont de l'échafaudage.

C'est la leçon, quatre articles dans les patterns avancés : l'agent est la petite partie. L'échafaudage est le travail d'ingénierie.

---

Dernier article de la série : L'avenir du développement agentique — vers où ça va en 2026, sur quoi je parierais, et la ligne au-delà de laquelle je serais sceptique.