Claude Code agents ou sub-agents pour quel workflow ?

Le bon choix dépend surtout de votre contexte, pas de la mode. Si votre workflow est séquentiel, je pars sur des sub-agents. Si plusieurs agents peuvent avancer en parallèle, je préfère une équipe avec état partagé. Le vrai sujet, c’est le coût en tokens et le contrôle.

Comment fonctionnent les sub-agents ?

Les sub-agents fonctionnent avec un agent principal qui découpe le travail, délègue à des agents spécialisés, récupère leurs résultats, puis synthétise la réponse finale.

Dans Claude Code, le modèle est assez hiérarchique. Il y a un orchestrateur central, l’agent principal, qui garde la main sur le workflow. C’est lui qui comprend votre demande, choisit quoi déléguer, appelle le bon sub-agent, puis reprend le contrôle.

Un sub-agent peut être spécialisé par rôle. Par exemple un agent “recherche”, un agent “développement”, un agent “test”, un agent “sécurité”. Comme le décrit la documentation officielle de Claude Code, chaque sub-agent peut avoir ses propres consignes, ses outils autorisés et son contexte de travail isolé. Le contexte, ici, c’est tout ce que l’agent “voit” pendant sa tâche : les instructions, les fichiers utiles, les échanges, les éléments techniques.

Il faut juste bien nuancer un point. Le contexte interne du sub-agent est séparé de celui de l’orchestrateur pendant son exécution. Mais quand le sub-agent retourne son résultat, ce résultat revient dans l’historique de l’agent principal. Donc l’isolation existe au niveau du travail du sub-agent, pas au sens où rien ne remonte jamais.

Le flux naturel ressemble souvent à ça :

• Vous demandez un objectif, par exemple corriger une feature ou auditer un morceau de code.
• L’orchestrateur analyse la demande et découpe le travail.
• Il lance un sub-agent de recherche pour comprendre le contexte.
• Il lance ensuite un sub-agent de code pour proposer ou appliquer des changements.
• Il peut appeler un sub-agent de test pour valider ce qui a été fait.
• Il reprend tout ça et produit une synthèse claire.

Ce fonctionnement est centralisé, et souvent séquentiel. Tout passe par l’agent principal. Ça donne moins de chaos, surtout quand on veut garder une logique de validation progressive.

J’ai vu ce pattern très bien marcher quand un client voulait automatiser une revue de code avec validation progressive, parce qu’on savait exactement qui faisait quoi et dans quel ordre. C’est bête, mais sur des workflows IA, cette clarté évite beaucoup d’erreurs.

Élément	Rôle	Ce qui revient à l’orchestrateur
Orchestrateur	Découpe, délègue, contrôle et synthétise.	La réponse finale consolidée.
Sub-agent spécialisé	Exécute une tâche précise avec ses consignes et outils.	Un résultat ciblé, exploitable par l’agent principal.
Résultat retourné	Résumé, analyse, code, diagnostic ou validation.	Un nouvel élément dans l’historique de l’orchestrateur.

Quand les sub-agents sont-ils le bon choix ?

Les sub-agents sont le bon choix quand le workflow a des dépendances fortes, des étapes à valider et un besoin clair de contrôle.

C’est le modèle que je choisis quand une étape B dépend vraiment du résultat de l’étape A. Par exemple, un audit de code où un agent analyse d’abord l’architecture, puis un autre vérifie les failles possibles, puis un dernier propose des corrections. Si le premier agent se trompe, tout le reste part de travers. Donc il faut un chef d’orchestre.

L’orchestrateur garde la vision globale. Il sait ce qui a été demandé, ce qui a été répondu, ce qui est valide ou non. Il peut relancer une étape, gérer une erreur, demander une correction à un sub-agent, ou stopper le workflow si quelque chose ne colle pas. C’est très utile sur des sujets comme :

• Audit de code : Un agent lit, un autre critique, un autre synthétise les risques.
• Migration technique : Un agent identifie les changements, un autre modifie, un autre vérifie la compatibilité.
• Génération puis vérification : Un agent produit du code ou de la doc, un autre contrôle la qualité.
• Analyse de bug : Un agent lit les logs, un autre inspecte le code, un autre propose une hypothèse.
• Pipeline sensible : Chaque étape doit être validée avant de passer à la suivante.

Ce modèle rassure souvent les équipes techniques. On comprend mieux ce qui se passe. On peut journaliser chaque décision, garder une trace des entrées et sorties, auditer le raisonnement, et surtout savoir où la décision a été prise. Ce n’est pas juste “l’agent a fait un truc”. On peut ouvrir la boîte.

Quand j’automatise un process pour une équipe qui découvre les agents, je commence souvent par là, parce que c’est plus simple à expliquer et à déboguer.

Il y a aussi un point important : on peut créer des points de reprise. Si l’étape 4 plante, on ne recommence pas forcément tout depuis le début. On reprend au bon endroit. Dès qu’on automatise un workflow sensible, ça change tout.

La limite, elle arrive assez vite sur les workflows longs. Plus l’orchestrateur reçoit de résultats, plus il grossit. Il doit garder le contexte, comparer, arbitrer, décider. Et c’est souvent là que les ennuis commencent.

Pourquoi le contexte coûte-t-il si cher ?

Le contexte coûte cher parce que l’orchestrateur finit par transporter l’historique, les consignes, les résultats intermédiaires et les synthèses reçues des sub-agents.

C’est le piège classique. On se dit qu’un sub-agent travaille dans son coin, avec son propre espace, donc que ça ne pollue pas le reste. C’est vrai pendant son exécution. Mais dès qu’il renvoie son résultat, ce résultat revient dans la conversation principale. Et cette conversation principale, c’est l’orchestrateur qui doit la relire pour décider quoi faire ensuite.

Sur un petit workflow, franchement, ce n’est pas un sujet. Un agent analyse un fichier, un autre propose une correction, l’orchestrateur tranche. Ça reste lisible. Ça reste rapide. Mais sur un workflow long, ou avec des agents très bavards, ça se dégrade vite.

Le mécanisme est assez simple :

• Chaque étape ajoute de la matière dans le contexte principal.
• L’orchestrateur doit relire davantage d’informations avant chaque nouvelle décision.
• Les réponses suivantes sont produites avec un historique plus lourd.
• Le coût marginal peut augmenter à mesure qu’on avance, parce que chaque nouvelle action s’appuie sur tout ce qui a été accumulé avant.

Quand je parle de coût, je parle de tokens, donc de volume de texte traité par le modèle. Plus il y a de tokens, plus ça peut coûter cher, plus ça peut être lent, et plus la conversation devient difficile à piloter. Même pour un humain, relire un fil avec dix rapports détaillés, c’est pénible. Pour un orchestrateur, c’est pareil, sauf qu’il doit en plus raisonner dessus.

Prenez un cas très concret. Une équipe lance 8 analyses sur un dépôt de code. Un sub-agent regarde la sécurité, un autre la dette technique, un autre les performances, un autre les tests, et ainsi de suite. Chaque sub-agent renvoie un rapport détaillé. Le système marche. Il fait le job. Mais l’orchestrateur doit maintenant garder tout ça pour produire une synthèse, arbitrer les priorités, éviter les contradictions, et préparer la suite. À ce moment-là, on sent que le workflow devient lourd.

C’est exactement pour ça qu’un modèle d’équipe avec état partagé peut être plus propre. Tous les agents n’ont pas forcément besoin de charger toute l’histoire. Ils ont surtout besoin d’accéder à la bonne information, au bon moment.

Comment marchent les équipes d’agents ?

Les équipes d’agents marchent avec une liste de tâches partagée plutôt qu’avec un orchestrateur unique qui centralise tout. C’est un changement assez simple, mais il change beaucoup de choses dans le workflow.

Au lieu d’avoir un chef d’orchestre qui lit tout, décide tout, puis distribue les consignes, on initialise un état commun. Chaque agent vient lire ce qui le concerne, prend une tâche, produit un résultat, puis écrit ce résultat dans l’état partagé. Les autres agents peuvent ensuite le relire directement, sans attendre qu’un agent central leur résume la situation.

Cette liste de tâches partagée peut être très simple. Ça peut être une structure JSON, un fichier dans le projet, une table de base de données, ou un état persistant dans un outil d’automatisation. Le point important, ce n’est pas l’outil. C’est que l’historique complet existe quelque part, et que chaque agent ne charge que la partie utile pour son action. Ça évite de bourrer chaque agent avec tout le contexte du projet.

{
  "tasks": [
    {
      "id": "task_001",
      "statut": "todo",
      "owner": "agent_backend",
      "dependances": [],
      "input": "Créer l'API de login",
      "output": null,
      "created_at": "2026-06-19T09:00:00Z",
      "updated_at": "2026-06-19T09:00:00Z"
    },
    {
      "id": "task_002",
      "statut": "blocked",
      "owner": "agent_tests",
      "dependances": ["task_001"],
      "input": "Tester l'API de login",
      "output": null,
      "created_at": "2026-06-19T09:05:00Z",
      "updated_at": "2026-06-19T09:05:00Z"
    }
  ]
}

Dans ce modèle, la communication devient plus latérale, presque pair-à-pair. Un agent backend peut produire une route API. Un agent test peut voir que la tâche est terminée et générer les tests. Un agent documentation peut lire le même output et mettre à jour le README. Personne n’a besoin de tout savoir, mais tout le monde travaille sur une source commune.

Les avantages sont assez nets :

• Meilleur parallélisme : plusieurs agents peuvent avancer en même temps sur des tâches indépendantes.
• Moins de contexte individuel : chaque agent lit seulement ce dont il a besoin.
• Plus d’autonomie : un agent peut prendre une tâche disponible sans attendre une instruction détaillée.
• Création de nouvelles tâches : un agent peut découvrir un problème et l’ajouter à la liste.

La contrepartie, je l’ai vue chez un client qui voulait faire bosser trois agents sur le même backlog produit : si l’état partagé est sale, tout part vite en vrille. Il faut gérer les conflits, les statuts, les doublons, les dépendances et la qualité des outputs. Une équipe d’agents marche bien quand la règle de coordination est claire. Sinon, c’est juste plusieurs IA qui écrivent dans le même fichier en espérant que ça se passe bien.

Quel modèle choisir en pratique ?

Je choisis les sub-agents pour contrôler une chaîne séquentielle, et les équipes d’agents quand le travail peut être distribué avec un état partagé propre.

Dans la pratique, je regarde d’abord la forme du workflow. Si une tâche dépend fortement de la précédente, avec des validations à chaque étape, le modèle sub-agents est souvent plus simple. Un agent principal garde la main, délègue, récupère, décide. C’est rassurant, surtout au début.

Mais il y a un piège. Le modèle hiérarchique devient vite cher quand tout remonte au même endroit. Chaque résultat revient dans le contexte central, chaque décision repasse par le même agent, et les tokens montent. Les tokens, c’est simplement le volume de texte envoyé et traité par le modèle. Plus on en consomme, plus ça coûte et plus ça ralentit.

Je tranche souvent avec ces critères très simples :

• Dépendances entre tâches. Si l’ordre est strict, je pars sur des sub-agents.
• Besoin de contrôle. Si je veux valider chaque étape, sub-agents aussi.
• Volume de sorties. Si beaucoup d’agents produisent beaucoup de contenu, l’équipe d’agents tient mieux.
• Parallélisme. Si plusieurs tâches peuvent avancer en même temps, l’équipe est plus adaptée.
• Débogage. Si l’équipe n’est pas encore à l’aise, le modèle hiérarchique est plus facile à lire.
• Maturité de l’équipe. Si personne ne maintient les conventions, l’équipe d’agents devient vite un bazar.

Le modèle équipe est plus scalable sur les workflows longs. Mais il demande une vraie discipline d’architecture. Il faut un schéma d’état clair, des conventions de statut, des règles d’écriture, des logs, et une reprise sur erreur. Sinon chaque agent écrit à sa façon, personne ne sait qui a fait quoi, et le workflow devient fragile.

Mon avis est assez simple. Dans les projets business, je ne cherche pas le pattern le plus élégant. Je cherche celui qui reste maintenable dans trois mois, quand l’équipe aura modifié deux prompts et ajouté quatre cas particuliers. J’ai vu trop de beaux workflows devenir incompréhensibles juste parce qu’on avait sous-estimé la maintenance.

Sub-agents	Équipes d’agents
Communication : Centralisée via un agent principal.	Communication : Distribuée via un état partagé.
Contexte : Remonte souvent au même endroit.	Contexte : Stocké et structuré dans un espace commun.
Parallélisme : Limité, plutôt séquentiel.	Parallélisme : Fort, plusieurs agents avancent en même temps.
Coût tokens : Peut grimper vite si tout repasse par le superviseur.	Coût tokens : Mieux réparti, mais dépend de la qualité de l’état partagé.
Debug : Plus simple au départ.	Debug : Plus exigeant, logs et statuts obligatoires.
Meilleur cas d’usage : Workflow contrôlé, validation étape par étape.	Meilleur cas d’usage : Workflow long, distribué, avec tâches parallèles.

Alors je pars sur quel modèle pour mon workflow ?

Je partirais simple. Si votre workflow a besoin d’un chef d’orchestre, avec des étapes dépendantes, des validations et des reprises propres, les sub-agents restent très solides. Si votre problème ressemble plutôt à une équipe qui se répartit du travail, avec beaucoup de tâches indépendantes et des résultats à partager, une liste de tâches commune devient plus intéressante.

Le vrai critère, c’est le contexte. Qui doit lire quoi, à quel moment, et combien ça coûte en tokens. En posant ça dès le départ, vous évitez les agents brillants mais ingérables. Le bénéfice pour vous est clair : des automatisations IA plus fiables, moins coûteuses et plus faciles à maintenir.

FAQ

• Quelle est la différence entre sub-agents et équipes d’agents dans Claude Code ?
  Les sub-agents suivent une logique hiérarchique : un agent principal délègue, récupère les résultats et décide de la suite. Les équipes d’agents utilisent plutôt un état partagé, comme une liste de tâches, où chaque agent lit et écrit ce qui le concerne.
• Les sub-agents réduisent-ils toujours le coût en tokens ?
  Pas toujours. Un sub-agent peut travailler avec son propre contexte, ce qui aide à isoler une tâche. Mais si l’orchestrateur récupère beaucoup de sorties détaillées, son historique grossit quand même. Sur des workflows longs, c’est souvent là que le coût augmente.
• Quand utiliser une liste de tâches partagée avec des agents IA ?
  Je l’utilise quand plusieurs agents peuvent avancer en parallèle, quand les résultats doivent être consultés par d’autres agents, et quand il serait inutile de faire transiter toute l’information par un seul orchestrateur.
• Quel modèle est le plus facile à déboguer ?
  Le modèle sub-agent est souvent plus simple au début, parce que tout passe par l’orchestrateur. Le modèle équipe peut être très propre aussi, mais seulement si l’état partagé est bien structuré avec des statuts, des logs et des règles d’écriture claires.
• Peut-on mélanger sub-agents et équipes d’agents ?
  Oui, et c’est souvent le plus réaliste. On peut garder un orchestrateur léger pour cadrer l’objectif, puis laisser des agents spécialisés travailler via une liste de tâches partagée. L’important, c’est d’éviter que tout l’historique remonte inutilement dans le même contexte.

 

 

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 très concrets. Si vous voulez cadrer vos workflows agents, réduire vos coûts tokens ou industrialiser vos automatisations IA, contactez-moi.