J'ai construit un agent qui pilote mes autres agents

#Un agent qui en dirige d'autres, c'est quoi exactement ?

Quand tu utilises Claude Code, tu parles à un seul agent. Tu lui demandes une tâche, il lit des fichiers, écrit du code, lance des tests, et te répond. Pour beaucoup de choses, ça suffit.

Mais certaines tâches sont trop grosses pour un seul agent. Refactoriser cinq modules à la fois, relire une pull request sous plusieurs angles, investiguer un bug dont tu ne connais pas la cause : tout ça gagne à être découpé et traité en parallèle, par plusieurs agents spécialisés.

C'est là qu'intervient l'idée d'un agent orchestrateur : un agent dont le rôle n'est pas de faire le travail lui-même, mais de le découper, de le distribuer à d'autres agents, puis de rassembler les résultats. Comme un chef d'équipe technique qui répartit les tickets et synthétise ce que chacun a produit.

Cet article t'explique deux façons de faire ça dans Claude Code — les sous-agents et les équipes d'agents — quand choisir l'une ou l'autre, et comment démarrer.

Un agent ici, c'est une instance de Claude avec son propre contexte (sa propre mémoire de la conversation) et ses propres outils. Deux agents ne partagent pas leur mémoire : c'est justement ce qui permet de les faire travailler chacun dans son coin.

#Pourquoi découper le travail ?

Deux raisons concrètes.

La première, c'est la concentration. Un agent avec un prompt court et précis (« tu es un relecteur de sécurité, cherche uniquement les failles ») est meilleur sur cette tâche qu'un agent généraliste à qui on demande tout en même temps. Chaque sous-agent reçoit une mission étroite et l'exécute bien.

La seconde, c'est le contexte. Chaque agent a une fenêtre de contexte limitée — la quantité d'informations qu'il peut garder en tête. Si un seul agent doit lire 40 fichiers, son contexte se sature et sa qualité baisse. En répartissant la lecture sur plusieurs agents, chacun garde un contexte propre et léger.

Et en prime : les agents qui ne dépendent pas les uns des autres tournent en même temps, ce qui réduit fortement le temps total.

#Deux approches : sous-agents vs équipes d'agents

Claude Code propose deux mécanismes pour faire travailler plusieurs agents. Ils se ressemblent mais répondent à des besoins différents.

	Sous-agents	Équipes d'agents
Communication	Rapportent au seul agent principal	Se parlent entre eux directement
Coordination	L'agent principal gère tout	Liste de tâches partagée, auto-organisation
Idéal pour	Tâches ciblées où seul le résultat compte	Travail complexe nécessitant discussion
Coût en tokens	Plus faible	Plus élevé (chaque agent est indépendant)

Retiens la distinction simple : avec les sous-agents, les travailleurs ne se parlent pas — ils renvoient leur résultat au chef, point. Avec les équipes d'agents, ils partagent une liste de tâches et peuvent se challenger mutuellement.

Commençons par le plus simple et le plus économique : les sous-agents.

#Approche 1 — Les sous-agents

Un sous-agent est un agent que ton agent principal lance pour une mission précise, à l'intérieur de ta session. Le sous-agent fait son travail dans son propre contexte, puis renvoie un résumé à l'agent principal. Il ne communique avec personne d'autre.

#Définir un sous-agent réutilisable

Tu peux décrire un sous-agent une fois pour toutes dans un fichier, et le réutiliser. Crée un fichier dans .claude/agents/ à la racine de ton projet, par exemple .claude/agents/relecteur-securite.md :

---
name: relecteur-securite
description: Relit du code pour trouver des failles de sécurité.
tools: Read, Grep, Glob
model: claude-haiku-4-5-20251001
---

Tu es un relecteur de sécurité. Concentre-toi uniquement sur les
vulnérabilités : injection, mauvaise gestion des secrets, validation
d'entrées manquante. Pour chaque problème, donne le fichier, la ligne
et une gravité (faible / moyenne / élevée). N'écris pas de code.

Décortiquons le frontmatter (le bloc entre les ---) :

name : l'identifiant du sous-agent, pour l'appeler ensuite.
description : à quoi il sert. Claude s'en sert pour décider quand le déclencher tout seul.
tools : la liste blanche des outils autorisés. Ici, lecture seule — il ne peut rien modifier.
model : le modèle utilisé. Pour une tâche cadrée comme celle-ci, un modèle rapide et peu coûteux comme Haiku suffit.

Le texte sous le frontmatter, c'est le prompt système du sous-agent : sa personnalité et ses consignes.

#Le déclencher

Une fois le fichier créé, il te suffit de le mentionner :

Utilise le sous-agent relecteur-securite sur le dossier src/auth/.

Claude lance le sous-agent, qui lit le code en autonomie et renvoie ses trouvailles. Ton agent principal récupère le résumé sans avoir pollué son propre contexte avec les 40 fichiers lus.

Bonne nouvelle pour le portefeuille : réserve les modèles puissants (Opus, Sonnet) à l'orchestrateur, qui doit raisonner et synthétiser. Confie les tâches répétitives et cadrées aux sous-agents sur un modèle rapide comme Haiku. Tu paies la puissance là où elle compte.

#Approche 2 — Les équipes d'agents

Parfois, les travailleurs ont besoin de se parler. Imagine une investigation de bug : plutôt que chaque agent explore une piste dans son coin, tu veux qu'ils confrontent leurs hypothèses, comme un débat scientifique. C'est le rôle des équipes d'agents.

Dans une équipe, ta session principale devient le lead (le chef). Il crée les autres agents, appelés teammates (coéquipiers). Chaque coéquipier est une session Claude Code complète et indépendante, avec son propre contexte. Tous partagent une liste de tâches commune et une messagerie pour communiquer.

Les équipes d'agents sont expérimentales et désactivées par défaut. Elles consomment beaucoup plus de tokens qu'une session seule, puisque chaque coéquipier est une instance Claude à part entière. À réserver aux tâches qui en valent vraiment la peine.

#Activer les équipes

Ajoute cette variable d'environnement dans ton settings.json :

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

#Lancer une équipe

Une fois activées, tu décris la tâche et les coéquipiers que tu veux, en langage naturel. Par exemple, pour une relecture de pull request sous trois angles :

Crée trois coéquipiers pour relire la PR #142 :
- un sur les implications de sécurité
- un sur l'impact performance
- un sur la couverture de tests
Chacun relit et rapporte ses trouvailles.

Le lead crée les trois coéquipiers, remplit la liste de tâches partagée, les laisse travailler en parallèle, puis synthétise les résultats quand ils ont fini. Chaque coéquipier applique son propre filtre sur la même PR, donc aucun angle n'est négligé.

#Le cas où les agents se challengent

L'intérêt vraiment unique des équipes apparaît quand tu demandes aux agents de se contredire. Sur un bug à cause inconnue, un agent seul a tendance à trouver une explication plausible et à s'arrêter là. Une équipe peut éviter ce piège :

Les utilisateurs signalent que l'app se ferme après un seul message.
Crée 5 coéquipiers pour explorer des hypothèses différentes. Fais-les
discuter entre eux pour tenter de réfuter les théories des autres, comme
un débat scientifique. Mets à jour le doc de conclusions avec le consensus.

La théorie qui survit à ce débat est bien plus susceptible d'être la vraie cause. C'est quelque chose qu'un seul agent — ou même des sous-agents qui ne se parlent pas — ne peut pas reproduire.

#Comment choisir entre les deux

Une règle de décision simple :

Le résultat seul te suffit ? → sous-agents. Lecture, recherche, relecture cadrée, vérification. Moins cher, plus simple.
Les travailleurs doivent échanger et se challenger ? → équipe d'agents. Investigation à hypothèses concurrentes, conception multi-perspectives, travail qui s'étale sur frontend + backend + tests.

Et dans les deux cas, garde ces réflexes :

Découpe en tâches bien dimensionnées. Trop petites, le coût de coordination dépasse le gain. Trop grosses, les agents travaillent trop longtemps sans point de contrôle. Vise une unité autonome avec un livrable clair : une fonction, un fichier de test, une relecture.
Évite les conflits de fichiers. Deux agents qui modifient le même fichier finissent par s'écraser. Donne à chacun un périmètre de fichiers distinct.
Commence petit. Pour tes débuts, choisis des tâches sans écriture de code : relire une PR, rechercher une bibliothèque, investiguer un bug. Tu vois la valeur du parallélisme sans les difficultés de coordination.

Pour les équipes, 3 à 5 coéquipiers couvrent la majorité des cas. Au-delà, le coût de coordination grimpe et les gains s'essoufflent. Trois agents concentrés battent souvent cinq agents dispersés.

#Récapitulatif

Un agent orchestrateur ne fait pas le travail : il le découpe, le distribue à d'autres agents, et rassemble les résultats.
Découper le travail apporte deux choses : des agents concentrés sur une mission étroite, et un contexte propre pour chacun — plus le parallélisme, qui réduit le temps total.
Les sous-agents sont lancés par l'agent principal, travaillent isolément et lui renvoient un résumé. Simples, économiques, parfaits quand seul le résultat compte. On les définit dans .claude/agents/.
Les équipes d'agents (expérimentales) font travailler des coéquipiers qui se parlent, partagent une liste de tâches et peuvent se challenger. Plus puissantes, plus coûteuses, idéales pour l'investigation et la conception.
Réserve les modèles puissants à l'orchestrateur ; confie les tâches cadrées à des modèles rapides comme Haiku.

Tu n'as pas besoin de monter une équipe de cinq agents pour commencer. Définis un seul sous-agent réutilisable pour une tâche que tu fais souvent — une relecture, une recherche — et observe la différence. C'est le moyen le plus simple de transformer Claude Code d'un assistant unique en une petite équipe que tu pilotes.