Claude Code agent teams ou sub-agents quel choix ?

Je choisis selon le workflow, pas selon la mode. Les sub-agents gardent le contrôle quand les tâches s’enchaînent. Les agent teams encaissent mieux le parallélisme et les coûts de contexte. Le vrai sujet, c’est qui doit lire quoi, quand, et à quel prix.

Comment fonctionnent les sub-agents ?

Les sub-agents fonctionnent avec un agent orchestrateur qui découpe le travail, appelle des agents spécialisés, récupère leurs réponses puis synthétise le résultat final.

Le modèle est assez simple à visualiser. Vous avez un agent principal, l’orchestrateur, qui garde la vue d’ensemble. Il sait où on en est, ce qui a déjà été fait, ce qui manque, et quelle étape doit venir ensuite. Les sous-agents, eux, reçoivent une mission précise. Ils travaillent chacun dans leur propre fenêtre de contexte, c’est-à-dire leur propre espace de travail avec les informations utiles pour leur tâche.

Mais il y a un point important. Les sous-agents ne discutent pas librement entre eux comme une équipe autour d’une table. Toute la communication remonte vers l’orchestrateur. C’est lui qui lit, arbitre, valide, relance si besoin, puis assemble. Dans ce modèle, l’orchestrateur devient la source centrale de vérité. Si une information n’est pas remontée à lui, elle n’existe pas vraiment pour le workflow global.

Ce fonctionnement est propre quand vous avez un processus avec des étapes bien identifiées. C’est souvent le cas dans des workflows d’automatisation dans Claude Code, où on veut garder du contrôle sans partir dans une architecture trop abstraite.

• Tâches séquentielles : Un agent travaille après l’autre, dans un ordre clair.
• Dépendances fortes : Une correction dépend d’une analyse précédente, une synthèse dépend des corrections validées.
• Besoin de validation : L’orchestrateur peut vérifier avant de passer à l’étape suivante.
• Gestion d’erreurs : Si un sous-agent répond mal, l’orchestrateur peut demander une reprise.
• Retries : Une étape peut être relancée sans refaire tout le workflow.
• Contrôle centralisé : Une seule logique décide, ce qui évite les comportements divergents.

Un exemple simple. Un premier agent analyse un fichier ou une demande. L’orchestrateur récupère son diagnostic. Un deuxième agent corrige ce qui a été identifié. L’orchestrateur vérifie si la correction répond bien au problème. Un troisième agent synthétise le résultat pour produire une sortie propre. À chaque fois, l’orchestrateur décide si on avance, si on recommence, ou si on arrête.

J’ai souvent vu ce pattern rassurer les équipes, parce qu’il ressemble à une chaîne de décision classique. Quelqu’un coordonne, quelqu’un exécute, quelqu’un valide. C’est lisible. C’est gouvernable. Mais ce contrôle a un prix, surtout quand les sorties des sous-agents deviennent longues.

Pourquoi le contexte coûte si cher ?

Le contexte coûte cher parce que l’orchestrateur accumule progressivement les résultats des sous-agents dans sa propre fenêtre de contexte.

Au début, ça paraît propre. J’ai un agent qui pilote, il délègue à deux ou trois sub-agents, chacun renvoie son analyse, et l’orchestrateur fait la synthèse. Rien de choquant. Le problème arrive quand les réponses s’empilent. Chaque retour devient une pièce de plus à garder, relire, transmettre et résumer.

Les tokens, c’est simplement les morceaux de texte que le modèle lit et produit. Plus l’orchestrateur porte d’historique, plus il consomme de tokens. Et ce n’est pas linéaire dans la sensation d’usage. Sur une petite tâche, ça passe très bien. Sur un workflow plus large, avec dix agents, des audits, du code, des logs, des recommandations, là on sent vite que l’orchestrateur devient le goulot d’étranglement.

Je l’ai vu chez un client sur un workflow d’analyse documentaire. Chaque sub-agent faisait bien son travail, mais l’agent central finissait avec tellement de matière qu’il passait plus de temps à trier qu’à décider. C’est exactement le piège. Il doit garder assez d’informations pour coordonner, mais il finit par transporter trop de texte.

Situation	Effet sur le contexte	Risque
Peu de sub-agents	Le volume reste limité et l’orchestrateur garde une vue claire.	Risque faible, le modèle sub-agent reste acceptable.
Beaucoup de sub-agents	Les retours s’accumulent vite dans la fenêtre de contexte.	Risque de surcharge, de coût élevé et de synthèses moins fiables.
Sorties courtes	Le contexte reste facile à relire et à transmettre.	Risque maîtrisé, surtout si les réponses sont bien cadrées.
Sorties longues	L’orchestrateur transporte beaucoup trop de matière.	Risque de lenteur, de confusion et de perte d’information utile.

Le vrai sujet n’est donc pas seulement le coût. C’est aussi la lisibilité du système et sa capacité à scaler. Un agent central qui garde tout dans sa tête, c’est pratique au début. Mais dès que le workflow grossit, il faut penser autrement.

Comment travaillent les agent teams ?

Les agent teams travaillent autour d’une liste de tâches partagée ou d’un état partagé, plutôt qu’autour d’un orchestrateur qui centralise toutes les communications. L’idée est simple : au lieu d’avoir un “chef d’orchestre” qui reçoit tout, décide tout, reformule tout et garde tout l’historique dans son contexte, on met les informations utiles dans un espace commun que les agents consultent directement.

Concrètement, on initialise une liste de tâches. Chaque agent la surveille, prend une tâche adaptée à son rôle, produit un résultat, puis écrit ce résultat dans l’état partagé. Si son travail révèle un nouveau besoin, il peut créer une nouvelle tâche. Par exemple, un agent qui analyse le code peut découvrir qu’il manque des tests, et ajouter une tâche pour l’agent QA.

Quand je parle de liste de tâches partagée, je ne parle pas juste d’une todo list jolie dans une interface. Je parle d’un magasin structuré qui contient les tâches, leur statut, les résultats, les dépendances, parfois des références vers des fichiers ou des décisions déjà prises. Ça peut être représenté en JSON, dans un fichier, dans une base de données, peu importe à ce niveau. Le point important, c’est que l’information est organisée et réutilisable.

Un exemple très simplifié pourrait ressembler à ça :

{
  "tasks": [
    {
      "id": "task_12",
      "type": "review_code",
      "status": "done",
      "result_ref": "reviews/module_auth.md"
    },
    {
      "id": "task_13",
      "type": "write_tests",
      "status": "todo",
      "depends_on": ["task_12"]
    }
  ]
}

L’intérêt business est assez clair. On gagne en parallélisme, parce que plusieurs agents peuvent avancer en même temps. On gagne en évolutivité, parce qu’ajouter un agent ne veut pas dire faire grossir un énorme prompt central. Et on réduit l’empreinte contextuelle par agent, c’est-à-dire la quantité d’informations qu’il doit charger pour travailler correctement. Chaque agent ne lit que ce qui est pertinent pour sa tâche.

J’ai vu ce point faire une grosse différence sur des workflows d’analyse documentaire. Le problème n’était pas l’IA, c’était le fait de tout remettre dans le même contexte à chaque étape. Avec un état partagé propre, on arrête de faire relire 80 pages à un agent qui a seulement besoin de 3 décisions.

Mais soyons honnêtes, ce modèle demande plus de discipline. Si l’état partagé est mal structuré, si les résultats sont flous, si les tâches n’ont pas de statut clair, on ne résout pas le bazar. On le déplace juste ailleurs. Le vrai choix entre agent teams et sub-agents dépend surtout d’un point : le type de dépendances entre les tâches.

Quel pattern choisir en pratique ?

Je choisis les sub-agents pour les workflows séquentiels et contrôlés, et les agent teams pour les workflows parallèles, évolutifs et sensibles au coût de contexte.

Dans la vraie vie, les deux patterns ont leur place. Les sub-agents ne sont pas dépassés. Ils sont très utiles quand il faut une décision centrale, une validation claire, ou une logique métier qui ne doit pas partir dans tous les sens. J’ai vu ça chez un client sur un workflow de conformité. Chaque étape devait être validée avant de passer à la suivante. Là, un orchestrateur central, c’était rassurant et propre.

Les agent teams, eux, ne sont pas magiques. Ils marchent bien quand les tâches peuvent avancer en parallèle, avec un état partagé propre. L’état partagé, c’est simplement une mémoire commune structurée, où chaque agent lit seulement ce dont il a besoin au lieu de traîner tout l’historique complet dans son contexte.

Sub-agents	Agent teams
Structure de communication. Orchestrateur central qui distribue les tâches.	Structure de communication. Agents qui collaborent via un état partagé.
Gestion du contexte. Le contexte remonte souvent vers le centre.	Gestion du contexte. Chaque agent lit les fragments utiles.
Parallélisme. Limité, souvent étape par étape.	Parallélisme. Naturel, plusieurs agents peuvent avancer ensemble.
Contrôle. Très fort, décisions centralisées.	Contrôle. Plus distribué, demande une bonne discipline.
Coût en tokens. Peut grimper quand l’orchestrateur accumule tout.	Coût en tokens. Mieux maîtrisé si l’état partagé est bien découpé.
Meilleur usage. Workflows validés, séquentiels, sensibles au contrôle.	Meilleur usage. Production parallèle, enrichissement, revue, correction.

Ma règle est simple. Si l’étape B dépend fortement de la validation de l’étape A, je pars plutôt sur des sub-agents. Si plusieurs agents peuvent produire, enrichir ou corriger des éléments en parallèle en lisant seulement les fragments utiles, je pars plutôt sur des agent teams.

Je commence simple. Je mesure la croissance du contexte, le coût en tokens, les lenteurs, les répétitions inutiles. Quand l’orchestrateur devient trop lourd et qu’il passe son temps à tout porter sur ses épaules, je bascule vers un état partagé. C’est souvent là que les agent teams commencent vraiment à payer.

Alors on garde le contrôle ou on partage le travail ?

Je vois les sub-agents comme un bon choix quand le workflow a besoin d’un chef d’orchestre clair, avec des étapes qui se suivent et une décision centrale. C’est lisible, contrôlable, pratique pour gérer les erreurs. Le problème arrive quand l’orchestrateur commence à porter trop d’historique.

Les agent teams répondent mieux à ce cas-là. La liste de tâches partagée permet aux agents de lire seulement les fragments utiles, de travailler en parallèle et de limiter le coût contextuel. Le bon choix dépend donc de vos dépendances, pas du buzz autour du pattern. Le bénéfice pour vous : une architecture Claude Code plus propre, plus scalable et moins coûteuse.

FAQ

• Quelle est la différence entre sub-agents et agent teams dans Claude Code ?
  Les sub-agents suivent une logique hiérarchique avec un orchestrateur central qui distribue les tâches et synthétise les résultats. Les agent teams s’appuient plutôt sur une liste de tâches ou un état partagé, que les agents lisent et enrichissent directement.
• Quand choisir les sub-agents ?
  Je les choisis quand les tâches ont des dépendances séquentielles fortes, quand une validation centrale est nécessaire ou quand je veux garder un contrôle précis sur les erreurs, les retries et la synthèse finale.
• Pourquoi les sub-agents peuvent coûter plus cher en tokens ?
  Parce que l’orchestrateur accumule les sorties des sous-agents dans son propre contexte. Plus il y a d’agents et plus leurs réponses sont longues, plus l’historique à conserver grossit, ce qui augmente l’empreinte contextuelle.
• Quel est l’intérêt principal des agent teams ?
  Leur intérêt principal, c’est de réduire la charge de contexte par agent. Chaque agent peut lire seulement les éléments utiles dans l’état partagé, au lieu de dépendre d’un orchestrateur qui transporte tout l’historique.
• Les agent teams remplacent-ils toujours les sub-agents ?
  Non. Les agent teams sont meilleurs pour le parallélisme, l’évolutivité et les workflows où le contexte doit rester léger. Les sub-agents restent très utiles quand il faut une chaîne de décision claire et un contrôle centralisé.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes qui veulent industrialiser leurs workflows data, IA et automatisation sans empiler des systèmes ingérables. Références : Logis Hôtel, Yelloh Village, BazarChic, Fédération Française de Football, Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez structurer vos agents IA, vos automatisations ou vos architectures data proprement, contactez-moi.