Claude Code agents quel pattern d’orchestration choisir ?

Je choisis les sub-agents quand j’ai besoin de contrôle, et les agent teams quand le travail peut avancer en parallèle avec un état partagé. Le vrai sujet, ce n’est pas le nom du pattern. C’est le coût en tokens, la latence et la complexité de coordination.

Comment fonctionnent les sub-agents ?

Les sub-agents fonctionnent comme une architecture hiérarchique avec un agent principal qui orchestre le travail.

L’utilisateur parle à l’orchestrateur. L’orchestrateur découpe la demande, appelle des sous-agents spécialisés, récupère leurs résultats, puis synthétise la réponse finale. Les sous-agents, eux, ne se coordonnent pas directement entre eux. Ils ne discutent pas dans leur coin pour décider quoi faire. Ils reçoivent une tâche, ils la traitent, ils renvoient un résultat.

Ce point est important : chaque sous-agent démarre dans un contexte frais. Ça veut dire qu’il ne traîne pas tout l’historique de la conversation ou les hésitations des autres agents. C’est propre. C’est rassurant aussi, surtout quand on veut isoler une tâche précise. Un agent qui analyse la sécurité n’a pas besoin de se polluer avec les détails d’un agent qui reformule la documentation.

Ce modèle marche bien quand les étapes dépendent les unes des autres. Une première étape produit une analyse. Une deuxième utilise cette analyse pour proposer une action. Une troisième vérifie que l’action ne casse rien. On est sur une chaîne contrôlée, pas sur une discussion ouverte entre plusieurs IA.

Sur un projet de code, je peux très bien imaginer ce flux : un premier agent analyse l’architecture du repo, un deuxième propose les modifications à faire, un troisième vérifie les impacts possibles sur les tests, les dépendances ou les fichiers sensibles. L’orchestrateur garde le fil. Il sait qui a produit quoi, dans quel ordre, et quoi faire si une étape répond mal.

Moi, j’aime ce pattern quand je veux garder la main. Surtout sur des workflows où les erreurs doivent être captées, relancées ou corrigées proprement. Si un sous-agent échoue, je peux faire un retry, donc relancer seulement cette partie. Je peux aussi changer l’instruction, demander une sortie plus stricte, ou arrêter le workflow avant de faire une bêtise. C’est moins magique, mais beaucoup plus pilotable. Et sur des projets clients, franchement, c’est souvent ce qu’on veut.

Ce que l’orchestrateur contrôle	Le découpage, l’ordre des étapes, les appels aux sous-agents, les retries, la synthèse finale.
Ce que les sous-agents produisent	Des résultats spécialisés, isolés, avec un contexte frais pour chaque tâche.
Type de workflow adapté	Des workflows séquentiels, dépendants, où chaque étape nourrit la suivante.

Pourquoi les sub-agents coûtent cher ?

Les sub-agents peuvent coûter cher parce que l’orchestrateur accumule les sorties des sous-agents dans son propre contexte.

Même si chaque sous-agent démarre avec un contexte frais, l’agent principal, lui, doit garder assez d’historique pour comprendre ce qui s’est passé, décider quoi faire ensuite et produire une synthèse cohérente. Le contexte, c’est simplement la quantité d’information que le modèle reçoit en entrée. Et les tokens, ce sont les petits morceaux de texte que le modèle lit et génère.

Le coût caché est là. Plus les sous-agents produisent des résultats longs, plus le contexte de l’orchestrateur grossit. À chaque nouvel appel, à chaque arbitrage, à chaque synthèse, une partie de ce contenu peut être relue, manipulée ou reformulée. Ça augmente les coûts, et ça peut aussi ralentir l’exécution.

Le problème ne vient donc pas seulement du nombre d’agents. Il vient surtout de la quantité d’information qui remonte vers le centre. Un système avec peu de sous-agents très bavards peut coûter plus cher qu’un système avec plusieurs sous-agents très concis.

Prenons un exemple simple. Trois sous-agents produisent chacun une analyse détaillée : un sur le code, un sur les tests, un sur l’architecture. L’orchestrateur doit relire tout ça pour décider de la suite. Jusque-là, ça va. Mais si on ajoute cinq étapes derrière, avec de nouvelles analyses, des corrections, des validations et une synthèse finale, le contexte central devient vite lourd.

Sur le papier, le contrôle hiérarchique est confortable. Je l’ai vu chez des clients, ça rassure beaucoup au début parce qu’on a l’impression que tout passe par un cerveau central. En production, ce confort se paie quand les tâches deviennent nombreuses, longues ou très bavardes.

Critère	Avantage	Limite
Contrôle	Décisions centralisées, plus faciles à suivre.	L’orchestrateur peut devenir un goulot d’étranglement.
Lisibilité	Chaque sous-agent a un rôle clair.	La synthèse globale peut devenir difficile à maintenir.
Coût en tokens	Chaque sous-agent travaille dans un contexte propre.	Les sorties remontées gonflent le contexte central.
Parallélisme	Plusieurs tâches peuvent avancer en même temps.	La consolidation finale peut annuler une partie du gain.

Que changent les agent teams ?

Les agent teams changent surtout une chose : on ne pilote plus tout avec un orchestrateur central qui distribue chaque action. On passe à une coordination par état partagé. Les agents travaillent plus comme des pairs. Ils lisent une liste de tâches commune, prennent une tâche, écrivent leur résultat, puis un autre agent peut repartir de ce résultat.

Une shared task list, ce n’est pas magique. C’est juste une structure accessible par les agents. Ça peut être un objet JSON, un fichier dans le repo, une ligne en base de données, ou un petit store partagé. L’idée, c’est que chaque agent n’a pas besoin de relire toute l’histoire depuis le début. Il charge surtout ce qui concerne sa mission : la tâche, les critères, les dépendances, les sorties précédentes utiles.

Le flux ressemble souvent à ça :

• On initialise une liste de tâches avec un statut, une priorité et parfois une dépendance.
• Les agents surveillent cet état partagé.
• Un agent prend une tâche disponible et la marque comme “en cours”.
• Il écrit sa sortie dans le store commun.
• Il peut créer une nouvelle tâche s’il découvre un problème ou une suite logique.
• Un autre agent continue à partir de là.

La coordination ne passe donc pas par une conversation permanente avec un chef d’orchestre. Elle passe par le store partagé. C’est plus sobre, et souvent plus scalable.

Prenons un chantier de refactoring. Un agent commence par lister les fichiers à inspecter. Un autre prend les fichiers liés aux API. Un autre traite les composants front. Un dernier vérifie que les changements respectent les conventions et ne cassent pas les tests. Chacun met à jour la liste commune : “à faire”, “en cours”, “fait”, “bloqué”, “à vérifier”. J’ai vu ce pattern très bien marcher chez un client sur une grosse base legacy, parce qu’on pouvait découper le travail sans faire exploser le contexte de chaque agent.

Ce modèle favorise naturellement le parallélisme. Si les tâches sont indépendantes, ou seulement faiblement dépendantes, plusieurs agents peuvent avancer en même temps. La limite est simple : il faut une convention claire sur l’état partagé. Sinon les agents se marchent dessus, reprennent le même travail, ou écrivent des résultats incompatibles.

Point	Ce que ça change
État partagé	La coordination se fait via une liste commune plutôt que via un orchestrateur central.
Contexte chargé par agent	Chaque agent charge surtout la partie utile à sa tâche, pas tout l’historique.
Parallélisme	Plusieurs agents peuvent travailler en même temps si les dépendances sont limitées.
Risque principal	Sans règles claires sur le store partagé, les agents peuvent se marcher dessus.

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 travaux parallélisables avec beaucoup d’état partagé. Le bon choix dépend moins de la techno que de la forme réelle du travail. C’est souvent là que les architectures IA partent trop loin. On dessine un système très élégant, puis on découvre qu’il est pénible à debugger, cher en tokens, et fragile dès qu’un agent comprend mal une consigne.

Ma grille est assez simple. Si l’étape B dépend clairement de l’étape A, je pars plutôt sur des sub-agents. Un agent principal garde la vision d’ensemble, délègue une tâche précise, récupère un résultat, décide de la suite. C’est propre, contrôlable, et ça ressemble à un workflow classique.

Les sub-agents sont aussi plus confortables quand je dois gérer les erreurs finement. Par exemple, chez un client, on avait un pipeline d’analyse de contrats. Extraction, contrôle qualité, scoring, synthèse. Chaque étape devait être validée avant la suivante. Là, une agent team aurait ajouté du bruit. Le vrai besoin, c’était de maîtriser le passage de relais.

Je bascule vers une agent team quand plusieurs tâches peuvent avancer en même temps, ou quand l’historique complet devient trop lourd pour un agent central. Une agent team, c’est une équipe d’agents qui travaillent sur des portions utiles de l’état. Chaque agent ne lit pas tout, il lit ce dont il a besoin. Ça devient intéressant quand le contexte grossit vite, ou quand le parallélisme fait vraiment gagner du temps.

Sur les critères business, voilà comment je le vois :

• Coût en tokens : Les sub-agents coûtent souvent moins cher sur des workflows courts. Les agent teams évitent de recopier tout le contexte partout, mais demandent une vraie discipline sur l’état partagé.
• Latence : Les sub-agents sont plus lents si tout s’enchaîne étape par étape. Les agent teams gagnent quand les tâches tournent en parallèle.
• Robustesse : Les sub-agents sont plus prévisibles. Les agent teams sont puissantes, mais la coordination peut devenir le point faible.
• Debug : Les sub-agents sont plus simples à inspecter. Les agent teams demandent de tracer qui a lu quoi, qui a produit quoi, et pourquoi.

Donc je commence simple. Si le workflow est court, linéaire, très contrôlé, je prends des sub-agents. Si le volume, le parallélisme ou l’accumulation de contexte deviennent le vrai problème, je passe à une logique d’agent team.

Choisissez sub-agents si	Choisissez agent teams si
L’étape B dépend clairement de l’étape A.	Plusieurs tâches peuvent avancer en même temps.
Vous voulez une synthèse centrale forte.	L’historique complet est trop lourd pour un agent central.
Les erreurs doivent être gérées finement.	Chaque agent doit consulter seulement une portion utile de l’état.
Vous voulez debugger facilement.	Le parallélisme est un vrai levier de performance.

Le but n’est pas d’avoir l’architecture la plus brillante, c’est de livrer plus vite, payer moins de tokens inutiles et garder un système compréhensible.

Et maintenant vous partez sur quel modèle ?

Je ne choisirais pas un pattern Claude Code agents parce qu’il sonne plus moderne. Je regarderais d’abord la forme du travail. Si le workflow est séquentiel, avec des dépendances claires et un besoin de contrôle, les sub-agents font très bien le job. Si les tâches peuvent avancer en parallèle et que le contexte central devient trop lourd, les agent teams sont souvent plus propres.

Le vrai arbitrage se joue sur les tokens, la latence et la coordination. Une bonne architecture d’agents, c’est celle qui reste lisible quand le projet grossit. Le bénéfice pour vous : moins de coût inutile, moins de friction, et des automatisations IA plus fiables.

FAQ

• Quelle est la différence entre sub-agents et agent teams dans Claude Code ?
  Les sub-agents suivent une logique hiérarchique : un agent principal orchestre, délègue et synthétise. Les agent teams utilisent plutôt un état partagé, comme une liste de tâches commune, où plusieurs agents lisent, écrivent et avancent sans passer en permanence par un orchestrateur central.
• Quand utiliser des sub-agents ?
  J’utiliserais des sub-agents 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 fin sur les erreurs, les reprises et la synthèse finale. C’est souvent le choix le plus lisible pour des processus courts et bien cadrés.
• Pourquoi les sub-agents peuvent augmenter les coûts en tokens ?
  Le coût peut monter parce que l’orchestrateur récupère les résultats des sous-agents et les garde dans son contexte pour décider de la suite. Plus les sorties sont longues et nombreuses, plus ce contexte central grossit. À force, chaque nouvelle décision peut devenir plus coûteuse.
• Quand les agent teams sont-elles plus adaptées ?
  Les agent teams sont plus adaptées quand plusieurs tâches peuvent avancer en parallèle, quand l’état du projet est trop gros pour être porté par un seul agent central, ou quand chaque agent n’a besoin que d’une partie précise des informations pour travailler correctement.
• Quel pattern est le plus simple à maintenir ?
  Pour un workflow simple, les sub-agents sont souvent plus faciles à comprendre et à debugger. Pour un système plus large, avec beaucoup de tâches en parallèle, une agent team bien structurée peut devenir plus maintenable. Le point clé, c’est la clarté de la coordination et de l’état partagé.

 

 

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. Avec webAnalyste et Formations Analytics, j’accompagne des équipes qui veulent rendre leurs systèmes data, IA et automatisation plus fiables, pas juste plus impressionnants. J’ai travaillé avec des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez cadrer vos agents IA, vos workflows ou vos automatisations business, contactez-moi.