5 patterns d'agents Claude Code que tout dev devrait connaître

La plupart des utilisateurs de Claude Code n'utilisent que 10% de ses capacités : ils lui envoient des prompts, il répond, ils mergent. C'est déjà utile. Mais la vraie valeur apparaît quand on bascule dans les sous-agents : des agents spécialisés, déclenchés par votre agent principal, avec leur propre contexte et leur propre règlement.

Voici les cinq patterns qu'on utilise quotidiennement en formation, et qu'on recommande à tout dev qui veut sortir du niveau 1.

Pattern 1 — Le reviewer silencieux

Problème : vous codez avec Claude Code, et il pousse des changements qui cassent vos conventions d'équipe. Nommage, gestion des erreurs, patterns interdits — vous passez votre temps à corriger.

Solution : un sous-agent code-reviewer avec un CLAUDE.md dédié qui liste vos règles. À chaque modification d'un fichier critique, l'agent principal consulte le reviewer avant de finaliser.

# .claude/agents/reviewer.md

Tu es un reviewer strict. Tu vérifies :
- Pas de `any` dans les nouveaux fichiers TypeScript
- Pas de `console.log` — utilise `@/lib/logger`
- Pas de try/catch vide — documenter la raison sinon rethrow
- Les imports absolus via alias `@/*`
- Une seule responsabilité par fonction exportée

Résultat : le code qui sort de Claude Code est déjà passé par votre linter humain avant d'arriver dans votre diff. On a mesuré −70% de "comments de review" évitables sur les PRs générées par l'agent.

Pattern 2 — Le test-runner paranoïaque

Problème : Claude modifie une fonction, les tests unitaires passent, mais vous avez une régression cachée dans un test d'intégration lointain.

Solution : un sous-agent test-runner qui, après chaque modification d'un fichier "noyau" (déclaré dans CLAUDE.md), lance les tests d'intégration associés. Si un test échoue, il revient en arrière et signale.

Le gain est subtil mais massif : Claude Code arrête d'être "optimiste" sur ses changements. Il devient paranoïaque à votre place. Sur un monorepo de 80 développeurs, on est passé de 3 régressions par mois causées par l'IA à zéro sur le trimestre suivant.

Pattern 3 — Le docs-keeper automatique

Problème : la documentation de votre API se désynchronise dès que vous changez un endpoint. Vous le savez, vous n'avez jamais le temps de la mettre à jour.

Solution : un sous-agent docs-keeper déclenché automatiquement par un hook après toute modification d'un fichier dans /app/api/. Son unique job : relire le endpoint, régénérer la section correspondante de docs/api.md, et pousser le tout dans la même PR.

Le côté "automatique" est clé. Personne ne pense à lancer la mise à jour des docs manuellement. En la rendant implicite, on résout le vrai problème.

Pattern 4 — L'orchestrateur qui paralellise

Problème : vous avez 14 micro-tâches indépendantes (renommer une variable dans 14 fichiers, ajouter le même header à 14 composants, migrer 14 tests de Jest à Vitest). Faire tourner Claude Code 14 fois prend 45 minutes.

Solution : un agent orchestrator qui reçoit la tâche de haut niveau, la décompose, et lance 14 sous-agents en parallèle, chacun sur un fichier. Temps total : 3 minutes, parce que la latence d'un appel LLM est dominante.

Ce pattern est le plus sous-exploité. Il demande de la discipline : décomposer une tâche pour qu'elle soit réellement parallèle (pas d'ordre entre les sous-tâches, pas de dépendance d'état) n'est pas toujours possible. Mais quand ça l'est, le gain de temps est d'un ordre de grandeur.

Pattern 5 — Le critic asymétrique

Problème : Claude Code, par nature, veut vous faire plaisir. Il confirme vos hypothèses. Il valide vos solutions. Même quand elles sont bancales.

Solution : un sous-agent critic dont le rôle est de chercher les failles. Son prompt commence par "Tu es un senior principal engineer qui a vu trop de codebases pourrir. Trouve les raisons pour lesquelles cette solution va poser problème dans 12 mois."

On le lance à la fin des missions critiques, juste avant de finaliser. Dans 3 cas sur 10, il identifie un vrai problème que l'agent principal a manqué. Dans les autres cas, il rassure. Dans zéro cas, il fait perdre du temps.

Le secret : ne lui donnez pas le même contexte qu'à l'agent principal. S'il partage le même CLAUDE.md, il partage les mêmes biais. On lui donne une version allégée, centrée sur les invariants métier et les contraintes business. Il voit alors ce que l'autre a oublié.

Comment commencer

Créez un dossier .claude/agents/ à la racine de votre repo. Commencez par un seul sous-agent, celui qui vous rend service aujourd'hui. Le plus universel est le reviewer. Écrivez 10 règles, pas 50. Testez pendant deux semaines. Itérez.

L'erreur classique est de vouloir tout déployer d'un coup. Les sous-agents, comme les outils, s'adoptent par convictions successives. Un sous-agent moyen utilisé est mieux qu'un sous-agent parfait ignoré.

Pour aller plus loin

Les 5 patterns ci-dessus sont la matière de la deuxième journée de notre formation Claude Code Mastery. Le jour 3 couvre des patterns plus avancés — planner/executor/critic, MCP servers d'entreprise, orchestration multi-repos — mais c'est une autre histoire.