Claude Code agent teams ou sub-agents que choisir ?

Je choisis les sub-agents quand le contrôle prime, les agent teams quand le contexte et le parallélisme comptent. Le vrai sujet, c’est la circulation de l’état. C’est là que les coûts, la vitesse et les bugs se décident.

Comment fonctionnent les sub-agents ?

Les sub-agents fonctionnent avec une logique hiérarchique : un orchestrateur reçoit la demande, découpe le travail, lance des agents spécialisés avec des consignes précises, récupère leurs résultats, puis construit la réponse finale.

C’est assez proche d’une équipe projet très cadrée. Vous avez une personne qui garde la vision globale, puis des experts qui interviennent sur une partie précise. Dans Claude Code, l’orchestrateur est cette source unique de vérité. Il connaît l’objectif, le plan, les dépendances entre les tâches, et surtout l’ordre dans lequel les choses doivent être faites.

L’orchestrateur décide qui fait quoi. Il transmet uniquement les informations utiles à chaque sub-agent. Il peut demander à un agent d’analyser un fichier, à un autre de proposer une modification, à un autre de vérifier un risque de régression. Si une étape échoue, c’est lui qui arbitre. Il peut relancer, changer de stratégie, ou intégrer un résultat partiel dans la réponse finale.

Chaque sub-agent travaille dans sa propre fenêtre de contexte. Le contexte, c’est la mémoire de travail disponible pendant une tâche : les consignes, les fichiers, les échanges, les contraintes. Un sub-agent ne voit pas automatiquement ce que les autres ont fait. Il ne connaît leur travail que si l’orchestrateur lui transmet l’information. C’est important, parce que ça évite le bruit, mais ça impose aussi une bonne coordination.

J’ai souvent vu ce modèle bien marcher quand une équipe veut garder une exécution très cadrée, surtout sur des workflows où l’ordre des étapes compte. Par exemple, analyse d’abord, modification ensuite, test après. Quand tout le monde part dans tous les sens, les résultats deviennent vite incohérents. Avec des sub-agents, on garde une chaîne de décision plus propre.

Élément du pattern	Rôle concret
Orchestrateur	Garde la vision globale, découpe le travail, assigne les tâches et arbitre les problèmes.
Sub-agent	Exécute une mission limitée avec des consignes précises et un périmètre clair.
Contexte séparé	Isole le travail de chaque agent pour réduire le bruit et éviter les interférences.
Synthèse finale	Regroupe les résultats utiles et produit une réponse cohérente pour l’utilisateur.

Quel est le coût caché du contrôle ?

Le coût caché des sub-agents vient surtout de l’accumulation de contexte dans l’orchestrateur. Le contrôle centralisé est utile, mais il n’est pas gratuit. Dans Claude Code, l’orchestrateur garde la vue d’ensemble, distribue les tâches, récupère les résultats, décide de la suite. C’est confortable, surtout quand le workflow doit rester maîtrisé.

Les sub-agents excellent quand le travail est séquentiel. L’étape B dépend de l’étape A, donc il faut garder un fil clair. Par exemple : analyse du code, puis correction, puis synthèse. Ou audit d’un projet, puis priorisation des problèmes, puis plan d’action. Dans ce genre de cas, j’aime bien avoir un agent principal qui pilote, parce qu’il peut relancer une étape, gérer une erreur, ajuster le plan, ou dire “stop, on repart autrement”.

Le sujet moins visible, c’est la fenêtre de contexte. C’est la quantité d’information que le modèle peut garder en mémoire pendant l’échange. Chaque résultat de sub-agent remonte vers l’orchestrateur. Si 10 sub-agents produisent chacun 2 000 tokens, l’orchestrateur peut se retrouver avec environ 20 000 tokens d’état accumulé. Un token, pour faire simple, c’est un petit morceau de texte consommé par le modèle. Plus il y en a, plus ça coûte, plus les échanges deviennent lourds, et plus la qualité peut se dégrader si le workflow devient complexe ou très bavard.

Le piège classique, je l’ai vu plusieurs fois chez des clients, c’est de croire que découper en agents rend toujours le système plus léger. En vrai, parfois on ne réduit pas le poids, on le déplace juste vers l’orchestrateur. Et là, le système a l’air propre sur le papier, mais il devient cher et lent à l’usage.

Sujet	Bénéfice	Limite
Contrôle centralisé	Garde une vue globale du workflow	Accumule beaucoup de contexte
Gestion d’erreur	Permet de relancer ou corriger une étape	Ajoute des échanges supplémentaires
Dépendances séquentielles	Très adapté quand chaque étape dépend de la précédente	Moins efficace pour des tâches vraiment indépendantes
Volume de sortie	Chaque agent peut produire un résultat riche	Peut saturer l’orchestrateur si tout remonte
Coût tokens	Le suivi complet améliore le contrôle	Le coût augmente vite avec le nombre d’agents

Pourquoi les agent teams changent le contexte ?

Les agent teams changent le contexte parce que l’état n’est plus porté principalement par un orchestrateur, mais par une task list partagée.

Avec des sub-agents classiques, on pense souvent en vertical. Un agent principal découpe, délègue, récupère, résume, redonne une consigne. Ça marche, mais le contexte passe beaucoup par lui. Avec une agent team, le modèle devient plus pair-à-pair. Les agents lisent et écrivent dans un état commun, un peu comme un tableau kanban partagé, au lieu de tout faire transiter par une seule tête de pont.

Le flux typique est assez simple. Un humain, ou un agent coordinateur léger, initialise une liste de tâches. Chaque agent regarde ce qui est disponible, prend une tâche qu’il sait traiter, la marque comme en cours, puis publie sa sortie dans l’état partagé. Un autre agent peut lire cette sortie si elle l’aide. Et si le travail révèle un nouveau besoin, n’importe quel agent peut créer une nouvelle tâche. C’est là que ça devient intéressant, parce que le système avance sans attendre que tout repasse par un chef d’orchestre.

Une task list partagée, ce n’est pas une idée floue. C’est généralement une structure de données accessible par tous les agents. Ça peut être un fichier JSON, une ligne en base de données, ou un store partagé, c’est-à-dire un espace de stockage commun. L’historique complet reste dans ce store, mais chaque agent ne recharge que ce qui est utile pour sa tâche actuelle. J’ai vu ça débloquer des projets où le contexte devenait énorme. On arrêtait de tout donner à tout le monde, tout le temps.

Un exemple conceptuel peut ressembler à ça, sans entrer dans le code applicatif :

{
  "task_id": "T-042",
  "status": "in_progress",
  "owner": "agent_tests",
  "dependencies": ["T-038", "T-039"],
  "output": "Rapport de tests disponible",
  "next_action": "Corriger les erreurs bloquantes"
}

Ce qui compte ici, ce n’est pas le format exact. C’est le contrat entre agents. Chaque agent sait où lire, où écrire, et comment ne pas polluer son propre contexte avec tout l’historique du projet.

Élément	Rôle
Contexte local agent	Ce que l’agent charge pour faire sa tâche maintenant.
État partagé	La source commune où les agents lisent et écrivent l’avancement.
Historique complet	La mémoire globale du travail, conservée dans le store partagé.
Tâche active	Le morceau de travail pris en charge par un agent à un instant donné.

Quel pattern choisir selon votre workflow ?

Choisissez les sub-agents pour les workflows séquentiels et contrôlés, choisissez les agent teams pour les workflows parallèles, volumineux ou évolutifs. C’est la règle simple. Après, je nuance tout de suite, parce que le vrai sujet, c’est la circulation de l’état. L’état, c’est la mémoire utile du workflow : les décisions prises, les données métier, les résultats intermédiaires, les contraintes à respecter.

Avec des sub-agents, la communication est verticale. Un orchestrateur donne le plan, délègue une tâche, récupère le résultat, puis décide de la suite. C’est rassurant. L’orchestrateur accumule les résultats et garde une autorité centrale. Si quelque chose casse, on sait souvent où regarder.

Avec des agent teams, la logique change. Les agents communiquent plutôt via un état partagé. Chaque agent charge seulement ce dont il a besoin, au lieu de recevoir tout l’historique. C’est plus efficace quand le volume monte, mais ça demande une vraie discipline sur la structure de l’état. Sinon, ça devient vite un bazar distribué, et j’ai déjà vu ça sur des automatisations censées “juste gagner du temps”.

Si les étapes sont fortement dépendantes, par exemple analyse puis validation puis génération puis contrôle qualité, je tends vers les sub-agents. Même chose si la conformité du plan compte, ou si les sorties restent raisonnables. On garde une ligne claire.

Si le travail peut être parallélisé, comme analyser 80 fichiers, générer plusieurs variantes, auditer différents modules ou enrichir plusieurs blocs de données, les agent teams deviennent plus intéressants. Surtout quand beaucoup d’agents produisent beaucoup de contenu et que tout recopier dans le contexte coûte trop cher en tokens. Les tokens, c’est l’unité de texte lue ou générée par le modèle, donc ça impacte directement le coût et parfois la vitesse.

Dans les projets data, IA ou low code, je regarde d’abord où se trouve la vérité métier. Si elle doit rester centralisée, je tends vers l’orchestrateur. Si elle doit être consultée par plusieurs agents sans tout recopier, je tends vers l’état partagé.

Critère	Sub-agents	Agent teams	Pattern recommandé
Dépendances	Fortes et séquentielles	Faibles ou découpables	Sub-agents si les étapes se suivent
Volume de sortie	Raisonnable	Élevé ou distribué	Agent teams si beaucoup de contenu est produit
Coût tokens	Peut monter vite avec l’historique	Mieux maîtrisé si l’état est bien structuré	Agent teams si le contexte devient lourd
Parallélisme	Limité	Naturel	Agent teams pour travailler en parallèle
Débogage	Plus simple avec une autorité centrale	Plus délicat à tracer	Sub-agents si la lisibilité prime
Complexité de coordination	Plus faible	Plus élevée	Sub-agents pour démarrer, agent teams pour scaler

Et vous voulez contrôler quoi exactement ?

Au fond, je ne choisis pas un pattern d’agents parce qu’il est plus élégant. Je le choisis parce qu’il colle au workflow. Si les étapes dépendent les unes des autres, les sub-agents restent très propres. L’orchestrateur garde la main, corrige, relance, synthétise. Si le travail est large, parallèle, avec beaucoup de sorties, les agent teams évitent de gonfler inutilement la fenêtre de contexte. La task list partagée devient le point d’appui. Mon conseil est simple, regardez où vit l’état, qui doit le lire, et combien il pèse. C’est là que vous gagnez du temps, des tokens et de la fiabilité.

FAQ

• Quelle est la différence entre sub-agents et agent teams dans Claude Code ?
  Les sub-agents suivent une logique hiérarchique. Un orchestrateur découpe le travail, délègue, récupère les résultats et synthétise. Les agent teams fonctionnent plutôt avec un état partagé. Les agents lisent et écrivent dans une task list commune, sans tout faire passer par un orchestrateur central.
• Quand choisir des sub-agents ?
  Je les choisis quand le workflow est séquentiel, quand une étape dépend clairement de la précédente, ou quand j’ai besoin d’un contrôle fort. L’orchestrateur peut gérer les erreurs, relancer une étape et garder une vision unique du plan.
• Pourquoi les sub-agents peuvent coûter plus cher en tokens ?
  Parce que l’orchestrateur accumule les résultats des sub-agents dans sa fenêtre de contexte. Si 10 agents produisent chacun 2 000 tokens, l’orchestrateur peut porter environ 20 000 tokens d’état. Sur des workflows lourds, ça pèse vite.
• C’est quoi une task list partagée pour des agent teams ?
  C’est un état commun accessible aux agents. Ça peut être une structure JSON, un fichier, une ligne de base de données ou un store partagé. Chaque agent lit ce dont il a besoin, publie ses sorties et peut créer de nouvelles tâches.
• Les agent teams sont-ils toujours meilleurs pour le parallélisme ?
  Ils sont souvent plus adaptés quand plusieurs tâches peuvent avancer en même temps, surtout si les sorties sont volumineuses. Mais ils demandent une task list propre et une coordination solide. Sinon, on gagne du parallélisme mais on crée du désordre.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No Code et Low Code avec n8n, intégration de l’IA en entreprise et SEO GEO. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. J’accompagne des équipes chez Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football, Texdecor et d’autres sur des sujets où la donnée, l’automatisation et l’IA doivent produire du concret. Si vous voulez structurer vos agents, vos workflows IA ou vos automatisations business, contactez-moi.