Sous-agents, MCP et hooks : personnaliser Claude Code pour son équipe

Claude Code sort de sa boîte avec des valeurs par défaut très correctes. Mais à partir d’une équipe de 3 à 5 développeurs sur un même codebase, la personnalisation devient le facteur qui sépare les gains marginaux des gains réels. Ce guide est pour les tech leads et les équipes plateforme qui veulent structurer Claude Code pour leur contexte.

Les trois leviers de personnalisation

Trois mécanismes, complémentaires :

Mécanisme	Pour quoi	Partagé en équipe ?
Sous-agents	Spécialiser un mini-Claude pour une tâche (revue sécu, génération doc, etc.)	Oui, via plugins
MCP servers	Brancher Claude sur vos outils internes (DB, Sentry, Jira, docs…)	Oui
Hooks	Automatiser avant/après les actions de Claude	Oui, via settings.json

On les combine : un sous-agent « dbrev » qui se branche à un MCP Postgres, avec un hook qui le déclenche sur chaque PR touchant aux migrations.

Partie 1 — Les sous-agents

Le principe

Un sous-agent est un Claude indépendant, invoqué par le Claude principal, avec son propre système prompt, ses outils autorisés et (parfois) ses propres MCP servers. Il reçoit une tâche, l’exécute, et rend un rapport.

Points clés (Claude Code Docs, 2026) :

• Les sous-agents peuvent utiliser tous les outils internes de Claude Code.
• Par défaut, ils héritent des outils et MCP de la conversation principale.
• Vous pouvez restreindre avec tools (allowlist) ou disallowedTools (denylist).
• Claude peut auto-déléguer à un sous-agent sur la base de sa description.
• Les sous-agents ne se parlent pas entre eux — ils remontent au parent.

Écrire son premier sous-agent

Dans .claude/agents/db-reviewer.md :

---
name: db-reviewer
description: Revue spécialisée des migrations SQL et du schéma Postgres.
tools: Read, Grep, Bash
model: claude-sonnet-4-6
---

Tu es un relecteur spécialisé en Postgres. À chaque invocation :

1. Lis la migration fournie.
2. Vérifie les contraintes, index, types, cascade.
3. Signale tout risque (lock, downtime, migration non-réversible, row-level lock sur table chaude).
4. Propose un plan de rollback.
5. Renvoie un rapport en Markdown structuré.

Dans une session :

Utilise db-reviewer sur migrations/0042_add_user_roles.sql

Claude Code lance un sous-agent avec seulement les outils listés, applique le système prompt dédié, et remonte le rapport.

Les Agent Teams (lancés en février 2026)

En février 2026, Anthropic a lancé les Agent Teams en parallèle d’Opus 4.6. Plusieurs sessions Claude indépendantes coordonnent, se transmettent des messages et se partagent le travail en parallèle (alexop.dev, 2026).

La différence avec les sous-agents :

• Sous-agents = système prompts et permissions définis en YAML.
• Agent Teams = rôles décrits dans le prompt, orchestration gérée par l’agent chef.

Cas d’usage typique : un chef d’équipe fait un audit, délègue la revue sécu à un agent, la revue de performance à un autre, la doc à un troisième, et consolide un rapport final. Utile pour les gros refactors ou les audits mensuels.

Bonnes pratiques

• Un sous-agent = une tâche claire. « Relecteur SQL » > « assistant backend ».
• Restreindre les outils. Un reviewer n’a pas besoin de Write ou de Bash entier.
• Documenter description précisément. C’est sur cette base que Claude auto-délègue.
• Commiter les agents dans le repo (.claude/agents/). Toute l’équipe en bénéficie.

Note : les sous-agents distribués via plugins ne supportent pas les champs hooks, mcpServers ou permissionMode dans leur frontmatter, pour raisons de sécurité.

Partie 2 — Les MCP servers

Le principe

Le Model Context Protocol est un standard ouvert. N’importe quel serveur qui l’implémente peut être branché à Claude Code, et ses prompts et outils deviennent accessibles au format /mcp__nom-serveur__commande.

En avril 2026, la communauté maintient plus de 50 serveurs MCP publics pour Claude Code (ClaudeFast, 2026).

Les MCP les plus utiles en équipe

MCP	Utilité concrète
GitHub	Lire issues/PR, commenter, créer des reviews
Postgres / MySQL	Requêtes en lecture sur votre base, inspection du schéma
Sentry	Récupérer stack trace et contexte d’une erreur prod
Linear / Jira	Lire une spec avant de coder, mettre à jour le statut
Confluence / Notion	Contexte doc interne (API, processus, décisions passées)
Filesystem distant	Accéder à un montage partagé (souvent pour des datasets)

Installation d’un MCP

Dans votre settings.json (projet ou utilisateur) :

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres", "postgres://readonly@localhost/mydb"]
    }
  }
}

Puis /mcp dans Claude Code confirme la connexion. Les outils du serveur apparaissent dans la liste disponible pour Claude.

La règle d’or : droits lecture seule par défaut

Branchez vos MCP en lecture seule sauf raison très précise. Un agent qui peut écrire dans Postgres sur prod est un accident en attente d’arriver. Commencez par du read-only, observez les patterns d’usage, puis élargissez au cas par cas.

Partager les MCP avec son équipe

Deux niveaux :

• settings.json à la racine du repo → partagé via git, tous les devs du repo en héritent.
• ~/.claude/settings.json → personnel à chaque dev.

Mettez dans le settings.json projet ce qui est spécifique au codebase (DB de dev, docs internes), et dans le personnel ce qui est spécifique à l’individu (clé GitHub, tokens).

Partie 3 — Les hooks

Le principe

Un hook est une commande shell exécutée par Claude Code sur un événement de cycle de vie. Il ne remplace pas Claude — il encadre ses actions.

Événements disponibles :

• PreEdit / PostEdit — avant/après une modification de fichier
• PreBash / PostBash — avant/après une commande shell
• PreCommit — avant un git commit
• Stop — quand Claude termine une tâche
• SubagentStop — quand un sous-agent termine

5 hooks qui changent la vie

1. Formatter automatique après édition

{
  "hooks": {
    "PostEdit": "npx prettier --write \"$FILE\""
  }
}

Claude ne vous rendra plus jamais de code mal formaté.

2. Type check après édition TypeScript

{
  "hooks": {
    "PostEdit": {
      "pattern": "\\.ts$",
      "command": "npx tsc --noEmit"
    }
  }
}

Rejette les changements qui cassent le typage.

3. Alerte Slack à la fin d’une tâche longue

{
  "hooks": {
    "Stop": "curl -X POST $SLACK_WEBHOOK -d '{\"text\":\"Claude a fini\"}'"
  }
}

Utile quand vous déléguez une tâche de 20 minutes et partez en réunion.

4. Interdire les commits sur main

{
  "hooks": {
    "PreCommit": "[ \"$(git branch --show-current)\" != \"main\" ] || (echo 'Pas de commit sur main' && exit 1)"
  }
}

Filet de sécurité pour les équipes.

5. Scan secrets avant edit

{
  "hooks": {
    "PreEdit": "grep -qE '(API_KEY|PASSWORD|SECRET)=' \"$FILE\" && exit 1 || exit 0"
  }
}

Empêche Claude d’écrire par-dessus un fichier contenant des secrets.

Philosophie

Les hooks ne sont pas là pour contrôler Claude, ils sont là pour automatiser ce qui serait fait de toute façon : formatter, tester, typer, notifier. Ils transforment un assistant qui rend du code en un assistant qui rend du code conforme aux standards de votre équipe, sans que vous ayez à le répéter dans chaque prompt.

Combiner les trois : une architecture typique d’équipe

Pour une équipe de 6 développeurs sur un monorepo TypeScript :

.claude/
├── agents/
│   ├── db-reviewer.md          # Revue des migrations SQL
│   ├── security-auditor.md     # Audit OWASP sur les PR auth/paiement
│   └── doc-writer.md           # Génération doc API depuis le code
├── commands/
│   ├── commit-push-pr.md       # Fin de cycle en un mot
│   ├── migrate-file.md         # Migration framework, lot par lot
│   └── audit-geo.md            # Audit GEO d'une page
└── settings.json               # MCP (GitHub, Postgres RO, Sentry) + hooks (prettier, tsc)

Le tout versionné dans le repo. Un nouveau dev qui clone récupère immédiatement tout l’environnement — agents, commandes, intégrations, garde-fous. C’est l’équivalent d’un .vscode/ ou d’un .editorconfig, mais pour l’assistant IA.

ROI et coûts cachés

Un investissement de 4 à 8 heures en setup initial d’une équipe paie en typiquement 2 à 3 semaines d’usage. À partir du moment où l’équipe converge sur un setup commun :

• Moins de prompts répétés (« n’oublie pas de lancer tsc… »).
• Moins de revues de code humaines sur des détails de style.
• Moins d’onboarding pour les nouveaux arrivants.

Les coûts cachés à surveiller :

• Dérive des MCP : si personne ne maintient la liste, elle se périme.
• Conflits de hooks : deux hooks qui touchent au même fichier peuvent entrer en boucle.
• Sous-agents qui dupliquent Claude principal : si un sous-agent fait la même chose que l’agent principal, il n’a pas de raison d’être.

Une revue trimestrielle du dossier .claude/ prévient la plupart de ces dérives.

Pour aller plus loin

• Guide d’entrée : Claude Code en 2026, le guide complet.
• Workflows quotidiens : 10 workflows qui font gagner une journée par semaine.
• Usage GEO : Utiliser Claude pour auditer son site (à paraître).

En résumé

Sous-agents, MCP et hooks ne sont pas des gadgets. Ce sont les trois couches qui transforment Claude Code d’un outil individuel en un outil d’équipe. Comme tout outil partagé, le vrai enjeu n’est pas technique, il est organisationnel : désigner un owner du dossier .claude/, documenter les conventions, et réviser régulièrement. Les équipes qui font ça récoltent les 26 à 55 % de gains ; les autres restent à 10-15 % et s’étonnent que l’effet annoncé ne soit pas au rendez-vous.