Sub-agents vs agent teams Claude : comment choisir

Le multi-agents n'est pas la réponse par défaut

Dès qu'une tâche devient un peu ambitieuse, le réflexe surgit : "il me faut plusieurs agents."

Dans la majorité des cas, c'est prématuré.

La bonne question, ce n'est pas "combien d'agents ?". C'est "quel type de coordination ce problème exige-t-il ?"

La réponse change tout. Architecture, coûts, latence, maintenabilité.

Claude propose deux paradigmes : les sub-agents et les agent teams. En surface, on pourrait les confondre. En réalité, ils répondent à des problèmes très différents.

Sub-agents : isoler pour mieux compresser

Un sub-agent, c'est une instance Claude spécialisée qui tourne dans sa propre fenêtre de contexte, isolée du reste.

Imaginez un directeur de recherche. Il ne lit pas chaque source primaire lui-même. Il confie des questions précises à des chercheurs, chacun revient avec un résumé, et il synthétise l'ensemble.

C'est exactement ce que font les sub-agents.

Chaque sub-agent reçoit :

• Un system prompt dédié qui définit sa spécialité
• Des outils spécifiques — pas tous, juste les siens
• Une fenêtre de contexte vierge et cloisonnée
• Un seul objectif à remplir

Quand il a terminé, seul le résultat final remonte au parent. Pas la chaîne de raisonnement. Pas les tâtonnements. Juste le signal utile.

Une contrainte qui rend le système lisible

Les sub-agents ne peuvent pas en créer d'autres. Ils ne se parlent pas entre eux. Chaque résultat remonte au parent, point.

Cette limitation est délibérée. Elle rend le flux d'information prévisible : on sait toujours où circule la donnée, et qui prend les décisions.

Pas de surprises. Pas de chaîne de délégation incontrôlée.

En pratique : définir des sub-agents avec le SDK

from claude_agent_sdk import query, ClaudeAgentOptions, AgentDefinition
 
async def main():
    async for message in query(
        prompt="Audite le module d'authentification pour les failles de sécurité",
        options=ClaudeAgentOptions(
            allowed_tools=["Read", "Grep", "Glob", "Agent"],
            agents={
                "security-reviewer": AgentDefinition(
                    description="Spécialiste sécurité. Pour les audits de vulnérabilités.",
                    prompt="Tu es un spécialiste sécurité, expert en identification de failles.",
                    tools=["Read", "Grep", "Glob"],
                    model="claude-opus-4-6",  # sécurité = mission critique → modèle le plus capable
                ),
                "performance-optimizer": AgentDefinition(
                    description="Spécialiste performance. Pour les problèmes de latence.",
                    prompt="Tu es un ingénieur performance, expert en bottlenecks.",
                    tools=["Read", "Grep", "Glob"],
                    model="claude-sonnet-4-6",  # perf = tâche analytique → bon ratio coût/qualité
                ),
            },
        ),
    ):
        print(message)

Le champ description est le signal de routage. C'est lui qui dit au parent quel sub-agent appeler. Quand le prompt mentionne "failles de sécurité", le parent choisit security-reviewer. S'il mentionne "latence", il choisit performance-optimizer.

La description doit être spécifique. Vague = mauvais routage.

Agent teams : travailler ensemble, pas chacun dans son coin

Les agent teams, c'est un tout autre modèle.

Là où les sub-agents sont des travailleurs éphémères — une mission, un résultat, au revoir —, les agent teams sont des instances qui durent. Elles communiquent directement entre elles. Elles partagent un état.

L'analogie la plus juste : la différence entre embaucher des freelances pour des missions ponctuelles… et constituer une vraie équipe qui bosse dans la même pièce.

Les trois rouages

Un agent team repose sur trois piliers :

1. Un team lead — il répartit le travail, coordonne, synthétise
2. Des teammates — des instances autonomes, chacune avec sa fenêtre de contexte, qui avancent en parallèle
3. Une task list partagée — ce qui reste à faire, ce qui est en cours, ce qui est fini, avec les dépendances entre tâches

Un cycle de vie concret

Claude (Team Lead) :
└── spawnTeam("auth-feature")
    Phase 1 — Conception :
    └── spawn("architect", prompt="Concevoir le flux OAuth",
              plan_mode_required=true)
    Phase 2 — Implémentation (en parallèle) :
    └── spawn("backend-dev",  prompt="Implémenter le contrôleur OAuth")
    └── spawn("frontend-dev", prompt="Construire les composants login")
    └── spawn("test-writer",  prompt="Écrire les tests d'intégration",
              blockedBy=["backend-dev"])

Remarquez le blockedBy sur le test writer. Il attend que le backend ait terminé avant de démarrer — sans intervention manuelle du lead.

C'est la task list partagée qui orchestre ça. Pas un humain.

Les teammates se parlent directement

C'est la grande différence avec les sub-agents. Les teammates peuvent s'envoyer des messages entre eux. Remonter un blocage, partager une découverte, ajuster un choix — sans que tout transite par le lead.

On peut aussi interagir directement avec un teammate individuel. On n'est pas obligé de passer par le chef pour tout.

Face à face : sub-agents vs agent teams

En deux phrases :

• Sub-agents = on délègue, on récupère, c'est fini. Pas de conversation entre eux. Pas de mémoire partagée.
• Agent teams = on collabore dans la durée. Les agents accumulent du contexte, et quand l'un fait une découverte, les autres en bénéficient immédiatement.

La vraie règle : découper par contexte, pas par rôle

C'est là que la plupart des architectures multi-agents se plantent.

L'instinct naturel, c'est de découper par rôle : un planificateur, un implémenteur, un testeur. Ça a l'air propre. En réalité, ça crée un jeu du téléphone où l'information se dégrade à chaque passage de main.

• L'implémenteur ne sait pas ce que le planificateur avait en tête
• Le testeur ne sait pas ce que l'implémenteur a décidé
• La qualité chute à chaque frontière

Le bon réflexe : raisonner par contexte

Posez-vous une seule question : de quel contexte cette sous-tâche a-t-elle besoin ?

Si deux sous-tâches ont besoin d'informations qui se recoupent fortement, elles appartiennent au même agent. Si elles peuvent fonctionner avec des informations réellement séparées et des interfaces propres entre elles — là, on découpe.

Un cas concret : un agent qui implémente une fonctionnalité devrait aussi écrire ses tests. Il a déjà tout le contexte. Séparer implémentation et tests dans deux agents crée un problème de transmission qui coûte plus cher que le parallélisme ne rapporte.

On ne sépare que quand le contexte est véritablement isolable.

Cinq patterns d'orchestration qui tiennent en production

Peu importe le paradigme choisi, cinq patterns couvrent l'essentiel des besoins réels.

1. Chaînage séquentiel (prompt chaining)

Chaque étape traite la sortie de la précédente. On l'utilise quand l'ordre compte et que les étapes dépendent les unes des autres.

Étape 1 → Étape 2 → Étape 3
              ↓
       vérification optionnelle

2. Routage (routing)

Un classifieur décide quel spécialiste traite la requête. Les questions simples vont vers un modèle rapide et peu coûteux. Les questions complexes vers un modèle plus capable. C'est comme ça qu'on évite l'explosion des coûts.

                 ┌→ Simple → Haiku
Classifieur ─────┤
                 └→ Complexe → Sonnet / Opus

3. Parallélisation

Des sous-tâches indépendantes qui tournent en même temps. Soit la même tâche est exécutée plusieurs fois pour obtenir des sorties variées (vote), soit des sous-tâches différentes avancent simultanément (sectionnement).

4. Orchestrateur-workers

Un agent central découpe le travail, le distribue à des workers, et recolle les morceaux. C'est le pattern dominant en production — pour les sub-agents comme pour les agent teams.

5. Évaluateur-optimiseur

Un agent produit, un autre évalue et renvoie du feedback. On boucle jusqu'à ce que ce soit bon. Utile quand la qualité prime sur la vitesse.

Quand ne PAS passer au multi-agents

C'est la partie que personne n'écrit.

On a vu des équipes passer des mois à construire des pipelines multi-agents sophistiqués… pour découvrir qu'un meilleur prompting sur un seul agent donnait le même résultat.

On commence simple. On n'ajoute de la complexité que quand on peut mesurer qu'elle est nécessaire.

Trois situations où ça se justifie

1. Protection du contexte — une sous-tâche produit du bruit non pertinent pour la tâche principale. La confiner dans un sub-agent évite de saturer le contexte.
2. Vraie parallélisation — des recherches ou explorations indépendantes qui gagnent à tourner en même temps.
3. Spécialisation — la tâche exige des system prompts contradictoires, ou un agent croule sous tellement d'outils que ses performances se dégradent.

Trois situations où c'est le mauvais choix

• Les agents ont en permanence besoin du contexte des autres
• Les dépendances inter-agents créent plus de surcoût que de valeur
• La tâche est suffisamment simple pour qu'un agent bien prompté la gère seul

Trois échecs récurrents (et comment les éviter)

1. Des descriptions floues = du travail en double

Si la mission de chaque agent n'est pas claire — objectif précis, format de sortie attendu, outils autorisés, périmètre explicite —, deux agents vont explorer la même chose sans s'en rendre compte.

Une bonne description, c'est un contrat. Pas une vague intention.

2. Les agents de vérification déclarent "c'est bon" sans vérifier

Sans instructions concrètes — exécuter toute la suite de tests, couvrir ces cas précis, ne rien valider tant que chaque test n'est pas vert — les agents de vérification produisent des faux positifs.

La rigueur ne se suggère pas. Elle se prescrit.

3. Les coûts en tokens s'envolent sans qu'on s'en aperçoive

Chaque agent consomme des tokens. Chaque échange entre agents en consomme davantage. Sans garde-fous, la facture grimpe vite.

La parade :

• Réserver le modèle le plus capable aux décisions à fort enjeu
• Router le travail de routine vers des modèles rapides et économiques
• Poser des limites de budget : tokens, tours de boucle, durée

Méthode : passer du mono-agent au multi-agents sans se brûler

FAQ