Claude Code agents quel pattern choisir ?

Je choisis selon le besoin de contrôle, de parallélisation et de coût en tokens. Les sub-agents cadrent bien les workflows séquentiels. Les agent teams respirent mieux quand plusieurs agents avancent en parallèle via un état partagé. Le vrai sujet, c’est le contexte.

Comment fonctionnent les sub-agents ?

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

Dans Claude Code, c’est un pattern hiérarchique assez simple. L’orchestrateur reçoit votre demande, comprend l’objectif, choisit l’ordre des tâches, puis appelle un ou plusieurs sub-agents avec des consignes précises. Une fois qu’un sub-agent a terminé, l’orchestrateur reprend la main. Il peut accepter le résultat, demander une correction, relancer une étape, ou passer au sub-agent suivant.

Le point important, et souvent sous-estimé, c’est que chaque sub-agent démarre avec un contexte frais. Il ne sait pas naturellement ce que les autres agents ont fait. Il ne connaît que ce que l’orchestrateur lui transmet. Si je veux qu’un agent de test tienne compte d’un bug trouvé par un agent d’analyse, je dois faire passer cette information via l’orchestrateur. C’est moins magique, mais beaucoup plus propre.

Claude Code permet de définir un sub-agent avec plusieurs éléments utiles :

• Une description, pour que l’orchestrateur sache quand l’utiliser.
• Un prompt système propre, c’est-à-dire ses règles, son rôle, sa manière de travailler.
• Des outils autorisés spécifiques, par exemple lecture de fichiers, édition, recherche, commandes terminal.
• Une configuration au niveau projet ou utilisateur, pratique pour réutiliser les mêmes spécialistes partout.

Ça permet de créer des assistants spécialisés pour du code review, du debugging, de l’analyse sécurité, de la documentation ou des tests. J’aime bien ce modèle parce qu’il me laisse une source unique de vérité. L’orchestrateur voit le plan, les erreurs, les résultats, et garde le fil. Chez un client, on avait justement évité un beau bazar comme ça. Un agent sécurité avait signalé un problème, mais l’orchestrateur a empêché l’agent de correction de partir dans une refonte inutile.

Un workflow typique ressemble à ça : A, un sub-agent analyse la base de code et localise la zone suspecte. B, un sub-agent debugging corrige le bug avec un périmètre clair. C, un sub-agent tests écrit ou met à jour les tests pour verrouiller le comportement. À la fin, l’orchestrateur relit tout et produit une réponse cohérente.

Élément	Ce que ça veut dire
Rôle de l’orchestrateur	Il planifie, délègue, récupère les sorties, gère les erreurs et synthétise le résultat final.
Contexte des sub-agents	Chaque sub-agent démarre avec un contexte frais et ne reçoit que les informations transmises.
Niveau de contrôle	Je garde la main sur l’ordre des tâches, les outils utilisés et la qualité du résultat.

Où les sub-agents sont-ils vraiment utiles ?

Les sub-agents sont utiles quand le travail est séquentiel, sensible aux dépendances et qu’on veut garder un contrôle serré sur l’exécution.

Typiquement, je les choisis quand j’ai une tâche A, puis une tâche B, puis une tâche C, et que B n’a aucun sens tant que A n’est pas proprement terminée. Un agent analyse le code. Un autre propose une correction. Un troisième vérifie que la correction ne casse rien. Là, l’orchestration devient naturelle, parce que chaque étape dépend clairement du résultat précédent.

C’est aussi très efficace quand il faut des validations intermédiaires. Par exemple, avant de lancer une migration, je veux d’abord un inventaire fiable, puis une estimation des risques, puis un plan d’exécution, puis seulement après les modifications. Si une étape échoue, je peux reprendre à cet endroit précis au lieu de relancer tout le bazar. C’est bête, mais sur des workflows longs, ça change tout.

C’est souvent le pattern que je choisis quand je veux éviter que plusieurs agents partent chacun dans leur direction. Chez des clients, je le vois surtout sur des audits ou des migrations. On veut savoir précisément qui a fait quoi, dans quel ordre, avec quel résultat. Pas juste avoir cinq réponses intelligentes qui se contredisent à moitié. Un acteur central garde le fil, compare les sorties, tranche, puis produit une synthèse finale.

Le contrôle a un prix. L’orchestrateur doit lire, retenir et synthétiser beaucoup d’informations. Plus les sub-agents renvoient des sorties longues, plus son contexte grossit. Le contexte, c’est la mémoire de travail du modèle pendant l’exécution. Quand elle se remplit avec du bruit, la qualité baisse. Donc je demande rarement des romans. Je veux des sorties courtes, structurées, exploitables.

Dans la pratique, je garde quelques règles simples :

• Donner une mission claire à chaque sub-agent, avec un périmètre précis.
• Limiter ses outils pour éviter qu’il parte explorer trop large.
• Demander un format de sortie stable, toujours le même.
• Exiger un résumé court, avec les décisions et les preuves utiles.
• Faire remonter uniquement ce qui aide l’orchestrateur à décider.

Le bon sub-agent ne cherche pas à briller. Il fait son morceau proprement, il laisse des traces lisibles, et il passe le relais.

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

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

C’est le coût un peu caché du pattern hiérarchique. Au départ, tout semble propre. Chaque sub-agent travaille dans son coin, avec son propre contexte, sa mission, ses fichiers, ses contraintes. C’est même l’intérêt du modèle. On évite de tout mélanger.

Mais dès qu’un sub-agent renvoie son résultat, l’orchestrateur l’ajoute à son propre historique. Et là, ça gonfle vite. Si dix sub-agents produisent chacun environ 2000 tokens, l’orchestrateur peut se retrouver avec environ 20000 tokens de résultats à porter, avant même de faire sa synthèse ou d’appeler l’agent suivant. Un token, pour simplifier, c’est un petit morceau de texte que le modèle lit et facture. Donc plus il y en a, plus ça coûte.

Le sujet n’est pas dramatique, mais il est très concret. Plus de tokens veut dire plus de coût, parfois plus de latence, et surtout plus de risque de noyer les infos importantes. J’ai déjà vu des agents centraux prendre de mauvaises décisions juste parce qu’ils avaient trop de matière moyenne sous les yeux. Le problème n’est pas seulement technique. Il touche directement la qualité de décision de l’agent central.

La bonne pratique, c’est de faire remonter moins de texte, mais mieux choisi. Je préfère forcer les sub-agents à produire une synthèse courte, stocker les détails ailleurs, puis ne remonter que ce qui sert vraiment à décider.

• Forcer les sub-agents à répondre avec un résumé court et exploitable.
• Stocker les détails dans des fichiers, une base ou un état externe.
• Remonter uniquement les décisions, les risques, les preuves clés et les prochaines actions.
• Utiliser du JSON quand il faut une sortie structurée et facile à relire par l’orchestrateur.
• Séparer les preuves détaillées du résumé vraiment utile.

Pattern	Effet sur le contexte	Coût probable
Beaucoup de sub-agents verbeux	Le contexte de l’orchestrateur grossit très vite.	Élevé
Sub-agents avec synthèse courte	Le contexte reste plus lisible et plus stable.	Modéré
État partagé externe	Les détails restent hors conversation, seuls les éléments utiles remontent.	Plus faible

Comment marchent les agent teams ?

Les agent teams marchent avec une liste de tâches ou un état partagé que plusieurs agents lisent et enrichissent sans passer systématiquement par un orchestrateur central.

Je le vois comme un tableau Kanban. Au départ, une personne ou un agent coordinateur amorce la liste avec quelques tâches. Ensuite, chaque agent surveille ce qui est disponible, prend ce qui correspond à sa spécialité, fait le boulot, puis publie son résultat dans l’état partagé. S’il découvre un nouveau sujet, il peut créer une nouvelle tâche. C’est simple, mais ça change beaucoup de choses.

La communication devient latérale plutôt que centrale. Un agent n’a pas besoin d’attendre que l’orchestrateur lui résume tout. Il peut lire directement le résultat d’un autre agent dans le store partagé. Ce store peut être un fichier JSON, un markdown structuré, une base de données, ou n’importe quel système accessible aux agents. Le point important, c’est que l’historique complet reste dans ce store, pendant que chaque agent ne charge que ce dont il a vraiment besoin.

Élément	Rôle
Task list	Centralise les choses à faire, leur statut et leurs dépendances.
Store partagé	Garde les résultats, décisions, fichiers analysés et observations.
Agents spécialisés	Travaillent en parallèle sur leur périmètre sans tout relire.

Ce pattern réduit la pression sur le contexte individuel. Chaque agent garde une vue partielle, mais pertinente. Pour des explorations de code indépendantes, des audits, des migrations ou des gros chantiers où plusieurs sujets avancent en même temps, c’est souvent plus robuste qu’un seul agent qui essaie de tout porter dans sa fenêtre de contexte.

Par exemple, je peux avoir une team avec un agent analyse code, un agent tests, un agent documentation et un agent sécurité. Ils partagent une task list structurée. L’agent analyse code repère les zones risquées. L’agent tests ajoute les cas manquants. L’agent sécurité vérifie les dépendances et les entrées utilisateur. L’agent documentation met à jour les explications à partir des changements réels.

Il faut quand même des règles claires, sinon ça devient vite un bazar. Je demande toujours au minimum :

• Un statut de tâche clair, comme todo, in progress, blocked, done.
• Un propriétaire, même temporaire.
• Des dépendances explicites entre tâches.
• Une définition de terminé.
• Un format de résultat stable, court, relisible par les autres agents.

Quel pattern choisir en pratique ?

Je choisis les sub-agents quand le contrôle prime, et les agent teams quand la parallélisation et la maîtrise du contexte priment.

Dans la vraie vie, le choix se fait rarement sur une préférence technique. Il se fait sur le risque principal. Est-ce que je veux garder une chaîne de décision très claire ? Ou est-ce que je veux faire avancer plusieurs chantiers en même temps sans exploser la fenêtre de contexte, c’est-à-dire la quantité d’information que le modèle peut garder en mémoire pendant son travail ?

Les sub-agents sont plus simples mentalement. J’ai un chef d’orchestre, des spécialistes, puis une synthèse. C’est très lisible. La communication passe par un point central, donc je contrôle mieux ce qui entre, ce qui sort, et ce qui est validé. Pour un audit, une migration sensible, une analyse de sécurité, c’est rassurant. J’ai vu ça chez un client sur une revue de pipeline data : un agent lisait les jobs, un autre vérifiait les dépendances, un autre cherchait les risques. L’orchestrateur gardait la main. Propre, traçable, pas magique.

Le problème, c’est que ça peut devenir lourd. Si dix agents produisent chacun trois pages de conclusions, l’orchestrateur se retrouve avec un roman à condenser. Le coût en tokens monte, la synthèse devient fragile, et la lisibilité baisse.

Les agent teams scalent mieux quand les tâches sont indépendantes. Chaque agent avance sur son flux, avec une task list partagée. La task list, c’est simplement une liste d’actions, de statuts et de décisions visibles par tous. Ça évite de tout faire passer par un cerveau central. Mais il faut de la discipline. Sans règles claires sur qui crée les tâches, qui les ferme, qui arbitre les conflits, ça devient vite flou.

Ma recommandation est simple. Je commence avec des sub-agents pour les workflows linéaires ou critiques. Je passe aux agent teams quand le projet nécessite plusieurs flux parallèles et un état partagé robuste. Et souvent, le meilleur compromis est hybride : un orchestrateur léger définit les objectifs et les règles, puis les agents travaillent via une task list partagée.

Situation	Meilleur choix	Raison
Workflow séquentiel	Sub-agents	Le contrôle reste simple, avec une logique étape par étape.
Audit contrôlé	Sub-agents	La traçabilité et la validation centrale priment sur la vitesse.
Refonte large	Agent teams	Plusieurs chantiers peuvent avancer en parallèle avec un état partagé.
Exploration parallèle	Agent teams	Les agents testent plusieurs pistes sans saturer un orchestrateur unique.
Contrainte forte sur les tokens	Agent teams ou hybride	Le contexte est mieux réparti, à condition de garder une task list propre.

Alors je pars sur quel modèle maintenant ?

Je ne choisirais pas un pattern parce qu’il a l’air plus moderne. Je regarderais d’abord la forme du travail. Si les étapes dépendent les unes des autres et que je veux garder la main, je pars sur des sub-agents. Si plusieurs agents peuvent avancer en parallèle, avec un état partagé propre, les agent teams deviennent plus intéressantes.

Le vrai piège, c’est le contexte. Un orchestrateur qui avale toutes les sorties peut coûter cher et perdre en clarté. Une task list partagée demande plus de rigueur, mais elle garde les agents plus légers. Le bénéfice pour vous : moins de tokens gaspillés, moins de confusion, et une orchestration Claude Code plus fiable.

FAQ

• Quelle est la différence entre sub-agents et agent teams dans Claude Code ?
  Les sub-agents suivent une logique hiérarchique : un orchestrateur délègue, récupère les résultats et synthétise. Les agent teams utilisent plutôt une liste de tâches ou un état partagé. Les agents lisent ce qui les concerne, publient leurs résultats et peuvent créer de nouvelles tâches.
• Quand utiliser des sub-agents Claude Code ?
  J’utilise les sub-agents quand le travail est séquentiel, quand une étape dépend de la précédente, ou quand je veux garder un contrôle fort sur les décisions. C’est pratique pour l’audit, le debugging encadré, la génération de tests après analyse, ou les workflows avec validation intermédiaire.
• Pourquoi les sub-agents peuvent coûter plus cher en tokens ?
  Le coût vient surtout de l’orchestrateur. Chaque sub-agent travaille dans un contexte propre, mais ses résultats remontent vers l’agent central. Si beaucoup d’agents produisent des sorties longues, le contexte de l’orchestrateur grossit vite, ce qui augmente les tokens et peut ralentir les appels suivants.
• Qu’est-ce qu’une liste de tâches partagée pour des agents IA ?
  C’est un état commun que les agents peuvent lire et modifier. En pratique, ça peut être un fichier JSON, un document structuré ou une base de données. Chaque tâche peut avoir un statut, un propriétaire, des dépendances et un résultat. L’intérêt, c’est que chaque agent ne charge que les informations utiles à son travail.
• Peut-on mélanger sub-agents et agent teams ?
  Oui, et c’est souvent le modèle le plus propre. Je peux garder un orchestrateur léger pour définir l’objectif, les règles et les priorités, puis laisser plusieurs agents travailler via une task list partagée. Ça évite de tout centraliser dans un seul contexte tout en gardant une direction claire.

 

 

A propos de l’auteur

Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne les 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 comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez structurer vos automatisations IA proprement, sans empiler des prompts au hasard, contactez-moi.