Claude Code agents ou sub-agents lequel choisir ?

Le bon choix dépend surtout de votre dépendance entre tâches, du contexte à garder et du coût en tokens. Je compare ici les sub-agents et les agent teams dans Claude Code, avec une lecture simple : contrôle centralisé d’un côté, état partagé et coordination plus légère de l’autre.

Comment fonctionnent les sub-agents ?

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

Dans Claude Code, le pattern est assez simple à visualiser. J’ai un agent principal, l’orchestrateur, qui garde la main. C’est lui qui comprend l’objectif global, décide du plan, choisit quel sub-agent appeler, gère les erreurs, puis reconstruit une réponse cohérente à la fin.

Le point important, c’est que chaque sub-agent travaille dans sa propre fenêtre de contexte indépendante. Une fenêtre de contexte, c’est la mémoire temporaire utilisée par le modèle pendant son travail. Donc un sub-agent peut recevoir uniquement les fichiers, les consignes ou les morceaux d’information utiles à sa mission. Il ne voit pas tout le reste par défaut.

Et surtout, les sub-agents ne se connaissent pas entre eux. Un agent test ne sait pas ce que l’agent analyse a répondu, sauf si l’orchestrateur lui transmet explicitement cette information. Ça évite pas mal de bruit. Ça force aussi à être clair dans la manière dont on découpe le travail.

Par exemple, sur une tâche de développement assez classique, je peux organiser le travail comme ça :

• Agent analyse : Il lit le besoin, inspecte le code existant et propose une approche.
• Agent code : Il implémente la modification à partir de l’analyse validée.
• Agent test : Il écrit ou adapte les tests, puis vérifie les cas limites.
• Agent documentation : Il met à jour le README, les commentaires ou la documentation interne.

Tout remonte ensuite vers l’orchestrateur. Il compare les retours, détecte les incohérences, demande une correction si besoin, puis produit le résultat final. J’ai vu ce modèle bien marcher chez un client qui avait beaucoup de petites évolutions produit. Le gain ne venait pas juste du “plusieurs agents en parallèle”, mais du fait que chaque agent avait un rôle propre, sans se perdre dans tout le contexte du projet.

Ce modèle devient vraiment intéressant quand les dépendances sont claires et que je veux garder un contrôle fin. Si les tâches sont trop floues ou trop liées entre elles, ça peut vite créer plus de coordination que de valeur.

Quand utiliser les sub-agents ?

Les sub-agents sont utiles quand les tâches suivent une logique séquentielle claire et quand l’orchestrateur doit garder une vision complète de ce qui se passe.

Je les utilise surtout quand le travail ressemble à une chaîne. Une étape A produit quelque chose. Une étape B s’appuie dessus. Une étape C vérifie ou transforme le résultat de B. Dans ce cas, laisser un orchestrateur piloter les sub-agents a du sens, parce qu’il garde le fil.

Le pattern devient vraiment pertinent dans quelques cas assez simples :

• Une étape dépend directement du résultat précédent, par exemple analyser un fichier avant de générer un correctif.
• Une validation doit être faite avant de continuer, par exemple vérifier qu’un test passe avant de modifier une autre partie du code.
• Une décision doit être expliquée, par exemple choisir une stratégie de refactorisation après avoir comparé plusieurs options.
• Une erreur doit pouvoir être isolée, relancée, ou corrigée sans refaire tout le workflow.

Ce modèle aide aussi beaucoup sur la traçabilité. La traçabilité, c’est simplement la capacité à comprendre ce qui s’est passé, dans quel ordre, avec quels résultats. L’orchestrateur voit les sorties des sub-agents, les erreurs, les choix intermédiaires et les validations. Ça évite le côté “boîte noire” où on obtient un résultat final sans trop savoir comment il a été fabriqué.

Sur le terrain, sur des workflows d’automatisation ou d’analyse, j’aime ce modèle quand il faut pouvoir relancer une étape, corriger une instruction ou expliquer pourquoi le résultat final a été produit. J’ai déjà vu des automatisations très propres techniquement devenir inutilisables juste parce qu’on ne savait plus où une mauvaise décision avait été prise. Avec des sub-agents bien orchestrés, on retrouve plus vite le point de rupture.

La limite, elle est très pratique. Plus l’orchestrateur collecte de résultats, plus son contexte grossit. Le contexte, c’est la mémoire de travail du modèle pendant l’exécution. Et cette mémoire se paie en tokens. Donc oui, les sub-agents donnent du contrôle et de la lisibilité, mais ils peuvent aussi créer un coût caché assez vite. C’est justement là que le sujet des tokens devient important.

Pourquoi le contexte coûte cher ?

Le contexte coûte cher parce que l’orchestrateur accumule les sorties des sub-agents et doit souvent les réinjecter dans les appels suivants.

Dans Claude Code, c’est très pratique au début. Un agent principal délègue une tâche à un sub-agent, récupère son résultat, puis s’en sert pour décider de la suite. Ça donne du contrôle. On garde une vision centrale. On évite que chaque agent parte dans son coin.

Le souci, c’est la fenêtre de contexte. C’est la quantité d’information que le modèle peut lire à un instant donné dans un prompt. Un prompt, ce n’est pas juste votre instruction. C’est aussi l’historique, les fichiers utiles, les résultats précédents, les consignes système, parfois des morceaux de code. Tout ça est découpé en tokens, des petits bouts de texte que le modèle facture et traite.

Dans une architecture hiérarchique, l’orchestrateur conserve les informations nécessaires pour piloter la suite. C’est logique. Mais plus il garde de choses, plus ses appels suivants deviennent lourds. Ce n’est pas juste une question de stockage quelque part. C’est surtout que ces données doivent souvent être relues par le modèle pour prendre la prochaine décision.

Un exemple simple. Si 10 sub-agents produisent chacun environ 2 000 tokens, l’orchestrateur accumule environ 20 000 tokens d’état. Ce n’est pas énorme dans l’absolu, mais si cet état repart dans plusieurs appels derrière, le coût monte vite. Et parfois, le modèle passe plus de temps à relire l’historique qu’à résoudre le vrai problème. Je l’ai vu chez un client sur un workflow d’analyse documentaire, le système marchait bien, puis il devenait lent et cher dès qu’on ajoutait des étapes intermédiaires.

Situation	Effet	Risque
Petit workflow	Peu de résultats à conserver	Coût généralement maîtrisé
Workflow avec plusieurs sub-agents	L’orchestrateur accumule les sorties	Prompts plus longs et appels plus chers
Workflow long avec beaucoup de résultats intermédiaires	L’état devient lourd à transporter	Latence, coût élevé, perte de clarté dans le raisonnement

C’est là que les agent teams deviennent intéressantes. Quand l’état devient trop gros pour transiter par un chef d’orchestre unique, un état partagé peut réduire la redondance. Au lieu de tout faire repasser par le même agent central, chaque agent peut accéder aux informations utiles sans recopier tout l’historique à chaque fois.

Comment marchent les agent teams ?

Les agent teams marchent avec une liste de tâches partagée ou un store d’état commun que les agents lisent et mettent à jour directement.

J’aime bien voir ça comme un tableau kanban. Au départ, un humain ou un agent coordinateur crée les cartes : analyser le code, écrire les tests, vérifier la sécurité, préparer la doc, corriger une erreur précise. Chaque agent regarde le tableau, prend une tâche qu’il sait traiter, bosse dessus, puis écrit son résultat dans l’état partagé.

Ce résultat peut être une décision, un bout de code, une analyse, une liste de fichiers modifiés, une erreur trouvée, ou une nouvelle tâche à créer. Par exemple, un agent “review” peut découvrir qu’un test manque, donc il ajoute une tâche pour l’agent “tests”. On n’est plus dans un modèle où tout passe forcément par un chef qui redistribue chaque message.

État partagé veut dire un support commun accessible par les agents. Ça peut être très simple ou plus structuré :

• Un fichier JSON avec les tâches, les statuts et les résultats.
• Un fichier Markdown maintenu comme journal de travail.
• Une ligne ou une table dans une base de données.
• Un store clé-valeur, si vous voulez juste lire et écrire des morceaux d’état.

Le point important, c’est que chaque agent ne recharge que ce dont il a besoin. Il ne traîne pas tout l’historique dans sa fenêtre de contexte. La fenêtre de contexte, c’est la quantité d’information que le modèle peut lire à un instant donné. Si vous la remplissez avec 40 échanges inutiles, vous perdez en précision et en coût.

Sub-agents	Communication verticale. Le parent délègue, reçoit, puis redonne du contexte.
Agent teams	Communication latérale. Les agents lisent et écrivent dans un état commun.

Dans la pratique, les agent teams évitent pas mal de duplication. Les agents peuvent bosser en parallèle, se passer le relais sans recopier toute la conversation, et construire sur le travail des autres. Mais il y a un prix : l’état partagé doit être propre, lisible, et pas rempli de bruit. J’ai vu des équipes automatiser ça trop vite, avec un JSON qui devient une poubelle. Et là, les agents prennent de mauvaises décisions, simplement parce que le tableau n’est plus fiable.

Quel pattern choisir ?

Je choisis les sub-agents quand je veux du contrôle centralisé, et les agent teams quand je veux limiter la redondance de contexte et faire collaborer plusieurs agents autour d’un état partagé.

Dans Claude Code, la vraie question n’est pas “quel pattern est le plus avancé ?”. C’est plutôt “où est-ce que je veux mettre la coordination ?”. Avec les sub-agents, je garde un agent principal qui pilote, délègue, récupère les résultats, puis décide de la suite. C’est plus simple à raisonner, surtout quand les actions sont sensibles, comme modifier du code de production, lancer des tests, ou toucher à une architecture existante.

Avec les agent teams, je pense plus “équipe de travail”. Plusieurs agents peuvent avancer sur des sujets différents, avec moins de duplication de contexte, parce qu’ils partagent un état commun. C’est utile quand on découpe un gros chantier en morceaux indépendants. Par exemple, un agent analyse les tests, un autre regarde la documentation, un autre inspecte les dépendances. J’ai vu ce pattern bien marcher sur des audits de code assez larges, là où un seul fil de discussion devenait vite trop lourd.

Sub-agents	Agent teams
Communication : Un agent central parle aux agents spécialisés et consolide leurs réponses.	Communication : Plusieurs agents collaborent autour d’un état partagé, avec moins d’allers-retours vers un superviseur unique.
Contexte : Le contexte peut être répété entre les appels, donc il faut rester vigilant.	Contexte : Le contexte partagé limite la redondance, surtout sur les tâches larges.
Coordination : La coordination est explicite et centralisée, donc plus prévisible.	Coordination : La coordination est plus distribuée, donc plus puissante mais parfois moins lisible.
Coût token : Le coût peut monter si chaque sub-agent reçoit beaucoup de contexte.	Coût token : Le coût peut être meilleur sur les gros sujets, si l’état partagé est bien géré.
Débogage : Plus facile à tracer, parce qu’on suit la chaîne de décision.	Débogage : Plus délicat, parce que plusieurs agents peuvent influencer le résultat.
Meilleurs cas d’usage : Workflow séquentiel, revue contrôlée, opérations sensibles, décisions étape par étape.	Meilleurs cas d’usage : Analyse parallèle, refactoring large, audit multi-fichiers, recherche distribuée.

Ma règle est simple. Si les étapes sont séquentielles et sensibles, je pars sur les sub-agents. Si plusieurs agents peuvent travailler en parallèle sur des morceaux indépendants avec un état partagé, je regarde les agent teams.

Je ne choisis pas le pattern le plus élégant sur le papier. Je choisis celui qui garde le système compréhensible, traçable et économique. C’est souvent ça qui fait la différence entre une démo impressionnante et un workflow qu’on peut vraiment maintenir.

Alors je choisis quel modèle pour mon système ?

Pour moi, le sujet n’est pas de savoir si les sub-agents sont meilleurs que les agent teams. Le vrai sujet, c’est l’architecture du travail. Les sub-agents sont propres quand le workflow est séquentiel, contrôlé, facile à tracer depuis un orchestrateur. Les agent teams deviennent plus intéressantes quand l’état grossit, que plusieurs agents peuvent avancer en parallèle et qu’on veut éviter de faire voyager trop de contexte partout. Dans Claude Code, le bon pattern est celui qui réduit la complexité réelle, pas celui qui semble le plus sophistiqué. Votre bénéfice est simple : moins de tokens gaspillés, moins de confusion, plus de systèmes IA maintenables.

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. Les agent teams travaillent plutôt autour d’un état partagé, comme une liste de tâches commune. Dans le premier cas, l’information remonte au centre. Dans le second, les agents lisent et écrivent directement dans un store partagé.
• Quand faut-il préférer les sub-agents ?
  Je les préfère quand les étapes dépendent clairement les unes des autres. Si une tâche B a besoin du résultat de A, et que je veux garder la main sur les erreurs, les relances et la synthèse, le pattern sub-agents reste très lisible.
• Pourquoi les sub-agents peuvent coûter plus cher en tokens ?
  Parce que l’orchestrateur accumule les résultats des agents. Si plusieurs sub-agents produisent beaucoup de texte, ce contexte peut grossir vite. Exemple simple : 10 agents qui produisent chacun 2 000 tokens, ça fait environ 20 000 tokens d’état à gérer côté orchestrateur.
• À quoi sert la liste de tâches partagée dans une agent team ?
  Elle sert de point de coordination. Chaque agent peut voir les tâches disponibles, prendre ce qu’il sait traiter, écrire son résultat, puis laisser les autres agents s’appuyer dessus. L’intérêt, c’est que chaque agent charge seulement l’information utile au lieu de recevoir tout l’historique.
• Quel modèle est le plus simple à déboguer ?
  Les sub-agents sont souvent plus simples à déboguer quand on veut une trace centralisée, parce que l’orchestrateur voit tout. Les agent teams demandent un état partagé bien structuré, sinon ça peut devenir flou. Mais sur des workflows larges ou parallèles, elles peuvent réduire la redondance et rendre le système plus économique.

 

 

A propos de l’auteur

Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne des entreprises sur le tracking avancé server-side, l’Analytics Engineering, l’automatisation No/Low Code avec n8n, l’intégration de l’IA dans les process business et le SEO/GEO. J’ai travaillé avec des équipes chez Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez structurer des workflows IA plus fiables, plus mesurables et plus utiles dans votre entreprise, contactez-moi.