Claude Code agents ou sub-agents que choisir ?

Je choisirais les sub-agents pour un workflow contrôlé et séquentiel, et les agent teams quand plusieurs agents doivent avancer en parallèle sans exploser le contexte. Le vrai sujet, ce n’est pas le style d’orchestration. C’est le coût en tokens, la latence et les bugs de coordination.

Comment fonctionnent les sub-agents ?

Les sub-agents Claude Code fonctionnent comme une petite équipe pilotée par un chef d’orchestre. J’ai un agent principal, l’orchestrateur, qui comprend la demande globale, découpe le problème en morceaux, appelle des agents spécialisés, récupère leurs réponses, puis reconstruit une réponse finale cohérente.

Ce qui est important, c’est que chaque sub-agent travaille dans sa propre fenêtre de contexte. La fenêtre de contexte, c’est la quantité d’informations que l’agent “voit” pendant son travail. Un sub-agent peut donc se concentrer sur une mission précise sans être pollué par tout le reste. Par exemple, un agent lit le code existant, un autre propose un correctif, un autre vérifie les tests ou cherche les effets de bord.

J’aime bien ce modèle sur des sujets de dev ou d’automatisation parce qu’il reste très contrôlable. Si je demande à Claude Code de corriger un bug dans un workflow Make, un script Python ou une base de code un peu large, je préfère qu’il ne mélange pas tout dans une seule réflexion géante. Je peux avoir un agent qui analyse la logique métier, un agent qui regarde les appels API, un agent qui vérifie les tests, puis l’orchestrateur qui reprend uniquement ce qui compte. C’est plus propre.

Il y a quand même un point à ne pas oublier. Même si les sub-agents ont leur propre contexte, l’orchestrateur doit intégrer les retours utiles dans son propre contexte pour décider quoi faire ensuite. Sinon, les agents travaillent bien chacun dans leur coin, mais la décision finale devient bancale. J’ai déjà vu ce problème chez un client avec des automatisations trop découpées. Chaque brique était correcte, mais personne ne portait vraiment la vision d’ensemble.

Les éléments clés du modèle sub-agent sont assez simples :

• Orchestrateur : L’agent central qui garde la vision globale.
• Découpage : Le problème est séparé en tâches plus petites.
• Appel spécialisé : Chaque sub-agent reçoit une mission précise.
• Contexte séparé : Chaque agent travaille avec ses propres informations.
• Synthèse finale : L’orchestrateur rassemble, filtre et décide.

Ce modèle est rassurant parce qu’il donne un point de contrôle central. Et c’est justement là que les sub-agents deviennent vraiment intéressants, surtout quand les étapes dépendent les unes des autres.

Quand les sub-agents sont utiles ?

Les sub-agents sont utiles quand les étapes dépendent fortement les unes des autres et quand je veux garder une logique de pilotage centrale. C’est vraiment le cas typique où l’ordre compte, où chaque résultat change la suite, et où je ne veux pas lancer tout le monde en parallèle en espérant que ça converge.

Dans un workflow séquentiel, l’étape 2 dépend du résultat de l’étape 1. Une analyse produit un diagnostic. Ce diagnostic décide de la correction. La correction déclenche une vérification. Et si la vérification échoue, l’orchestrateur peut adapter le plan, relancer une étape, demander une correction plus ciblée ou arrêter proprement au lieu de continuer dans le brouillard.

Ce modèle marche bien sur des tâches comme l’audit de code, la migration progressive, l’analyse puis correction, ou la génération puis validation. Par exemple, je peux avoir un orchestrateur qui demande d’abord une analyse d’un fichier ou d’un module. Il récupère le diagnostic, repère les zones à risque, puis déclenche une correction ciblée. Une fois la correction faite, il demande une vérification pour confirmer que le problème est bien traité. C’est simple, mais c’est souvent là que les sub-agents deviennent vraiment utiles.

Ce que je vois souvent chez des clients, c’est que le vrai problème n’est pas le modèle IA. C’est le découpage. La tâche est floue, trop large, avec trois objectifs mélangés dans le même prompt. Les sub-agents forcent à clarifier les responsabilités. Qui analyse ? Qui corrige ? Qui valide ? Rien que cette séparation évite pas mal de réponses moyennes et de boucles inutiles.

Situation	Intérêt des sub-agents
Audit de code	Découper l’analyse, le diagnostic et la vérification
Migration progressive	Avancer étape par étape sans perdre le contrôle
Analyse puis correction	Corriger à partir d’un diagnostic clair
Génération puis validation	Contrôler la qualité avant de passer à la suite
Gestion d’erreur	Relancer une étape ou adapter le plan proprement

Quel est le coût caché ?

Le coût caché des sub-agents, c’est le gonflement du contexte de l’orchestrateur. Chaque fois qu’un agent spécialisé renvoie un résultat utile, l’orchestrateur peut le réinjecter dans son contexte central pour continuer à raisonner avec. Sur le papier, c’est propre. Dans la vraie vie, ça veut dire que les prompts suivants deviennent plus gros, consomment plus de tokens, prennent plus de temps, et peuvent devenir plus difficiles à piloter.

Le contexte, c’est simplement la mémoire de travail du modèle pendant une tâche. Plus on y met de texte, plus le modèle doit relire, comparer, trier, ignorer, garder. Et là, le piège est assez simple.

• Plus l’orchestrateur garde d’informations, plus les appels suivants deviennent lourds.
• Plus il résume, plus il risque de perdre un détail important.
• Plus il reçoit de retours longs, plus la synthèse finale peut contenir du bruit.

Imaginez cinq sub-agents. Un analyse le code, un vérifie la sécurité, un regarde la performance, un relit la documentation, un propose une stratégie de test. Si chacun produit une réponse longue, l’orchestrateur se retrouve avec une pile de contenu à conserver, trier et synthétiser. Ce n’est pas juste “cinq réponses”. C’est cinq angles d’analyse, avec parfois des doublons, des contradictions, des détails utiles noyés dans du texte moyen.

Je vois souvent le même problème dans les projets data ou automatisation. Tout le monde remonte ses notes dans un document central. Au début c’est pratique. Puis le document devient le point de passage obligatoire, il grossit, il ralentit les décisions, et personne ne sait vraiment ce qu’il faut garder ou supprimer. Les sub-agents peuvent créer exactement cette sensation si l’orchestration n’est pas pensée proprement.

Le vrai coût n’est donc pas seulement le prix d’un appel modèle. C’est l’accumulation de contexte, les appels qui deviennent plus coûteux, le ralentissement progressif, et le risque de synthèses moins nettes. C’est là qu’on comprend pourquoi un autre modèle devient intéressant : les agent teams avec état partagé, où l’information n’a pas forcément besoin de remonter en bloc dans un seul cerveau central.

Comment marchent les agent teams ?

Les agent teams Claude Code fonctionnent avec une coordination latérale autour d’une liste de tâches partagée, ou d’un état commun, plutôt qu’avec un orchestrateur qui centralise tout. Chaque agent lit l’état, prend une tâche adaptée à son rôle, écrit son résultat, puis crée éventuellement une nouvelle tâche si le travail révèle autre chose à faire.

Concrètement, cette liste partagée peut être un objet structuré. Un JSON par exemple, c’est juste un format texte très pratique pour représenter des données avec des clés et des valeurs. Ça peut aussi être un fichier, une entrée en base de données, ou n’importe quel support que les agents peuvent consulter et mettre à jour proprement.

Le point important, c’est que chaque agent n’a pas besoin de charger tout l’historique de la conversation ou tout le projet. Il charge seulement la partie utile pour sa tâche. C’est là que ça devient intéressant avec Claude Code, parce qu’on évite de remplir le contexte avec du bruit. Un agent front n’a pas besoin de lire toute l’analyse sécurité. Un agent test n’a pas besoin de connaître tous les choix UX, sauf si ça impacte ses scénarios.

Ça peut ressembler à une structure très simple comme ça :

Tâche	Statut	Propriétaire	Dépendance	Résultat
Créer l’API login	En cours	Agent backend	Aucune	Endpoint prêt à tester
Écrire les tests login	Bloqué	Agent QA	Créer l’API login	En attente
Corriger le formulaire	À faire	Agent frontend	Aucune	Non démarré

Le format exact n’est pas le sujet. Ce qui compte, c’est la discipline de l’état partagé. Qui fait quoi. Ce qui est fini. Ce qui bloque. Ce qui doit être repris. J’ai vu des équipes se compliquer la vie avec des workflows énormes, alors qu’un fichier bien tenu suffisait largement.

Le bénéfice est assez net : meilleur parallélisme, contexte plus léger, moins de dépendance à un cerveau central qui doit tout comprendre et tout redistribuer. Les agents peuvent avancer en même temps, chacun dans son périmètre.

Il y a quand même un prix à payer. Il faut gérer les conflits, les priorités, les tâches en doublon et l’état périmé. Si deux agents modifient la même chose, il faut une règle. Si une tâche n’est plus valide, il faut la nettoyer. C’est souvent là que se joue le choix d’architecture : agent team distribué, sub-agents plus contrôlés, ou un mix des deux.

Quel modèle choisir pour son projet ?

Je choisis les sub-agents quand j’ai besoin de contrôle centralisé, et les agent teams quand j’ai besoin de parallélisme, d’un contexte plus léger et d’une collaboration distribuée. C’est vraiment le critère le plus simple. Pas besoin de rendre ça plus théorique que ça.

Avec des sub-agents, la communication passe surtout par un orchestrateur. C’est lui qui donne les consignes, récupère les résultats, arbitre, relance si besoin. C’est propre quand le workflow ressemble à une chaîne de validation. Un agent analyse, un autre corrige, un autre teste, puis l’orchestrateur décide. J’aime bien ce modèle quand il faut garder une trace claire de “qui fait quoi” et éviter les décisions trop dispersées.

Le revers, c’est le coût de contexte. Le contexte, c’est la mémoire utile donnée au modèle à chaque appel : consignes, fichiers, historique, décisions précédentes. Si l’orchestrateur doit tout porter, il grossit vite. Et quand il grossit, ça coûte plus cher, ça devient plus lent, et parfois ça raisonne moins bien parce qu’il y a trop d’informations à tenir en même temps.

Les agent teams sont plus intéressantes quand le travail peut avancer en parallèle. Chaque agent prend une tâche, bosse avec un contexte plus léger, puis pousse son résultat. Ça ressemble plus à une équipe qui pioche dans un backlog. Un agent traite les tests, un autre la doc, un autre le refactoring. Ça peut aller beaucoup plus vite, surtout sur des tâches indépendantes.

Mais là, le risque change. Si l’état partagé est flou, les agents se marchent dessus. Deux agents modifient la même zone, prennent des décisions incompatibles, ou répètent le même travail. J’ai vu ça chez un client sur une automatisation de revue de code : le problème n’était pas l’IA, c’était l’absence de règles simples sur les fichiers, les priorités et la validation finale.

La règle que je retiens est simple :

• Si le workflow ressemble à une chaîne de validation, je pars sur des sub-agents.
• Si le workflow ressemble à une équipe qui pioche dans un backlog, je pars sur des agent teams.

Besoin	Meilleur choix	Pourquoi
Contrôle centralisé	Sub-agents	L’orchestrateur garde la main sur les décisions et les validations.
Contexte plus léger	Agent teams	Chaque agent travaille avec moins d’informations, donc moins de coût et moins de bruit.
Latence faible sur tâches parallèles	Agent teams	Plusieurs tâches avancent en même temps au lieu d’attendre une séquence complète.
Reprise facile après erreur	Sub-agents	Le point de contrôle est clair, donc on sait où relancer.
Coordination simple	Sub-agents	Moins d’agents prennent des initiatives en même temps.
Gros volume de tâches indépendantes	Agent teams	Le modèle distribué absorbe mieux la charge.
Réduction du risque d’erreur	Ça dépend	Les sub-agents limitent les conflits, les agent teams limitent la surcharge de contexte.

L’architecture multi-agents n’est pas une question de mode, c’est une question de coût, de contexte et de coordination.

Alors on orchestre comment maintenant ?

Je retiens une règle simple. Les sub-agents Claude Code sont très bons quand je veux garder la main, enchaîner des étapes dépendantes et centraliser les décisions. Les agent teams deviennent plus intéressantes quand plusieurs agents doivent avancer en parallèle autour d’une liste de tâches partagée, sans remplir inutilement le contexte d’un orchestrateur. Le point à surveiller, c’est rarement le nombre d’agents. C’est ce qu’ils se transmettent, où l’information vit, et combien ça coûte à chaque appel. Si vous choisissez le bon pattern dès le départ, vous gagnez en vitesse, en clarté et en budget tokens.

FAQ

• Quelle est la différence entre sub-agents et agent teams dans Claude Code ?
  Les sub-agents suivent un modèle hiérarchique avec un orchestrateur central qui appelle des agents spécialisés. Les agent teams utilisent plutôt une liste de tâches ou un état partagé, où les agents coopèrent de façon plus latérale. La vraie différence se joue sur la circulation de l’information et la taille du contexte.
• Quand faut-il utiliser des sub-agents Claude Code ?
  Je les utiliserais quand le workflow est séquentiel, avec des dépendances fortes entre les étapes. Par exemple une analyse, puis une correction, puis une validation. L’orchestrateur garde une vision globale et peut ajuster le plan si un agent remonte une erreur ou un résultat incomplet.
• Pourquoi les sub-agents peuvent coûter plus cher en tokens ?
  Parce que l’orchestrateur récupère les résultats des sub-agents et peut accumuler beaucoup de contenu dans son propre contexte. Plus ce contexte grossit, plus les appels suivants deviennent lourds. Ça peut augmenter le coût en tokens, ralentir les traitements et rendre la synthèse moins propre.
• À quoi sert une liste de tâches partagée dans une agent team ?
  Elle sert de point de coordination commun. Les agents peuvent lire les tâches disponibles, prendre celles qui les concernent, écrire leurs résultats et créer de nouvelles tâches. L’intérêt, c’est qu’ils n’ont pas besoin de tout se transmettre directement ni de charger tout l’historique dans leur contexte.
• Quel pattern choisir pour un projet IA complexe ?
  Si le projet ressemble à une chaîne de décision avec contrôle central, je pars sur des sub-agents. Si le projet ressemble à une équipe qui travaille sur un backlog partagé, je regarde plutôt les agent teams. Dans les deux cas, je commence par clarifier les tâches, les dépendances et l’endroit où l’état du travail est stocké.

 

 

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. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. J’accompagne des équipes comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor sur des sujets data, IA et automatisation vraiment opérationnels. Si vous voulez structurer vos workflows IA, vos agents ou vos automatisations business sans partir dans tous les sens, contactez-moi.