Claude Code Agent Teams : Passer d'un Agent Solo à une Équipe Coordonnée

La communauté OpenClaw avait trouvé le filon avant tout le monde. Ils avaient construit des skills custom pour orchestrer plusieurs sessions Claude Code en parallèle sur un même projet. Ça fonctionnait, c’était malin — et visiblement, Anthropic a pris des notes.

Parce qu’ils viennent de shipper exactement la même chose, nativement dans Claude Code. Pas de plugin, pas de workaround. C’est intégré, et ça s’appelle Agent Teams.

D’un agent solo à un chef de projet avec son équipe

Jusqu’ici, Claude Code fonctionnait comme un employé seul. Tu lui donnes un job, il fait l’étape 1, puis l’étape 2, puis l’étape 3. Séquentiellement. Une tâche à la fois.

Les Agent Teams changent complètement la donne.

Tu décris ce que tu veux, et au lieu d’un agent qui grind tout seul, un lead agent analyse la tâche, la découpe en morceaux, et spin up des teammates séparés pour gérer différentes parties en même temps.

• Un teammate peut explorer ton codebase
• Pendant qu’un autre debug une fonction
• Pendant qu’un troisième écrit les tests

Chaque teammate a sa propre fenêtre de contexte, son propre workspace, et ils peuvent se parler directement pour partager leurs découvertes.

Le lead reste au-dessus de tout ça : il coordonne, gère une task list partagée, et assemble le tout une fois que les teammates ont fini. Et toi, tu peux intervenir directement sur n’importe quel teammate sans passer par le lead.

Sub-agents vs Agent Teams : la vraie différence

Si tu utilises déjà Claude Code, tu connais les sub-agents. Ils spin up dans ta session, font une tâche ciblée, et renvoient le résultat au main agent. Simple, efficace, léger en tokens.

Les Agent Teams, c’est un autre animal.

	Sub-agents	Agent Teams
Session	Dans le contexte parent	Session indépendante par teammate
Communication	Report au parent uniquement	Parlent entre eux + au lead
Coordination	Aucune entre sub-agents	Task list partagée, messages directs
Coût tokens	Léger	Significativement plus élevé
Cas d’usage	Tâche ciblée, réponse rapide	Travail complexe multi-parties

La question clé : est-ce que tes workers ont besoin de communiquer entre eux ?

• Non → Sub-agents. Moins cher, plus rapide.
• Oui → Agent Teams. Le surcoût est justifié par la collaboration.

Si tu veux comprendre comment j’utilisais déjà les sub-agents experts via MCP avant cette update, j’en parle dans mon article sur GLM Delegator et les sous-agents experts.

Quand utiliser les Agent Teams (et quand c’est overkill)

Les Agent Teams ne sont pas un “use this for everything”. Ils ajoutent de l’overhead de coordination et brûlent des tokens significativement plus vite qu’une session solo.

Les sweet spots

• Research & review : plusieurs teammates investigent différents angles d’un problème en parallèle, puis comparent leurs notes
• Nouvelles features modulaires : chaque teammate possède un module ou un fichier distinct
• Debugging multi-hypothèses : au lieu d’un agent qui suit une seule piste (potentiellement la mauvaise), plusieurs teammates testent des hypothèses concurrentes. Le premier qui trouve gagne
• Travail cross-layer : un sur le frontend, un sur le backend, un sur les tests. Chacun possède sa partie

Les anti-patterns

• Travail séquentiel : si l’étape 2 dépend de l’étape 1, pas d’intérêt à paralléliser
• Édition du même fichier : deux teammates sur le même fichier = overwrites garantis
• Tâches simples : l’overhead de coordination coûte plus cher que laisser un agent solo faire le job

Règle d’or : avant de spin up une team, demande-toi si le travail peut genuinement être découpé en pièces indépendantes. Si oui, go. Sinon, un agent solo ou des sub-agents feront mieux pour moins cher.

Installation : 30 secondes

Les Agent Teams sont expérimentaux et désactivés par défaut. Deux options pour les activer.

Option 1 : settings.json (recommandé)

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

Option 2 : variable d’environnement

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

Le settings.json est plus propre si tu veux que ça persiste entre les sessions.

Premier lancement : quoi dire au lead

Pas de syntaxe spéciale à apprendre. Tu décris ce que tu veux en langage naturel et tu dis à Claude de créer une team.

Je design un outil CLI qui aide les développeurs à tracker les TODO
dans leur codebase. Crée une agent team pour explorer ça sous
différents angles : un teammate sur l'UX, un sur l'architecture
technique, un qui joue l'avocat du diable.

Le lead crée la team, spin up les teammates, leur assigne des rôles via la task list partagée, et c’est parti.

La clé d’un bon prompt initial

Sois spécifique sur ce que chaque teammate doit focus. Plus c’est précis, moins le lead perd de tokens à structurer le travail lui-même.

Tu peux aussi contrôler le nombre de teammates et le modèle :

Crée une team de 4 teammates pour refactorer ces modules en
parallèle. Utilise Sonnet pour chaque teammate.

Deux modes d’affichage

• In-process (défaut) : tous les teammates tournent dans ton terminal principal. Shift+Up/Down pour naviguer entre eux
• Split-pane : chaque teammate a son propre pane (nécessite tmux ou iTerm2)

Contrôler sa team en live

Parler directement à un teammate

Pas besoin de passer par le lead. En in-process : Shift+Up/Down pour sélectionner, puis tape. En split-pane : clique dans le pane.

Delegate mode (important)

Parfois le lead décide de faire le travail lui-même au lieu de déléguer. Delegate mode le verrouille en coordination-only : il ne peut que spawner des teammates, assigner des tâches, et envoyer des messages.

→ Shift+Tab pour l’activer.

Gestion des tâches

Les tâches peuvent être assignées par le lead ou auto-claimed par les teammates. Quand un teammate finit sa tâche, il peut automatiquement prendre la suivante non-assignée dans la liste.

Shutdown propre

Quand un teammate a fini : demande au lead de le shutdown. Le lead envoie une shutdown_request, le teammate confirme, et il sort proprement. Une fois tous les teammates arrêtés, le lead peut cleanup les ressources partagées.

Best practices pour ne pas cramer ses tokens

1. Des spawn prompts détaillés

Les teammates chargent automatiquement le contexte projet (CLAUDE.md, MCP servers), mais ils n’héritent pas de l’historique de conversation du lead. Tout le contexte nécessaire doit être dans le prompt de spawn.

2. Des tâches bien dimensionnées

• Trop petit → l’overhead de coordination coûte plus que le bénéfice
• Trop grand → le teammate travaille trop longtemps sans check-in, risque de travail gaspillé
• Sweet spot → une unité autonome avec un livrable clair (une fonction, un fichier de tests, une review)

3. Un fichier par teammate

Deux teammates sur le même fichier = overwrites. Découpe le travail pour que chacun possède ses propres fichiers.

4. Commencer par du research/review

Avant de se lancer dans de l’implémentation parallèle, teste avec des tâches de review. Fais reviewer une PR sous différents angles, ou investiguer un bug avec des hypothèses concurrentes. Ça montre la valeur du parallélisme sans la complexité de la coordination de code.

5. Check-in régulier

Ne laisse pas la team tourner trop longtemps sans supervision. Plus un teammate part dans une mauvaise direction sans correction, plus tu gaspilles de tokens.

Les limites actuelles (research preview)

Pas de dealbreakers, mais il faut les connaître :

• Session resumption cassée : /resume et /rewind ne ramènent pas les teammates in-process. Si ça arrive, dis au lead d’en spawner de nouveaux
• Task status qui lag : parfois un teammate finit son travail mais ne marque pas la tâche comme terminée, ce qui bloque les dépendances. Vérifie manuellement si nécessaire
• Une seule team par session : les teammates ne peuvent pas spawner leurs propres teams. Le créateur de la team reste le lead pour toute sa durée de vie
• Split-pane limité : fonctionne uniquement avec tmux ou iTerm2. Pas supporté dans le terminal intégré de VS Code, Windows Terminal, ou Ghostty

Ce que ça change concrètement

Les Agent Teams sont le passage de “un freelance qui fait tout” à “un chef de projet qui arrive avec son équipe”. C’est la suite logique de ce que la communauté avait déjà construit — et c’est maintenant natif.

Combiné avec des outils comme GLM Delegator pour les experts MCP, et une bonne intégration de l’IA dans le workflow quotidien, on arrive à un setup où Claude Code n’est plus un assistant, c’est un orchestrateur qui gère une équipe d’agents spécialisés.

Aller plus loin : GLM Delegator + Agent Teams

Les Agent Teams gèrent la coordination native entre agents. Mais pour ajouter des experts spécialisés (architecture, sécurité, code review) à tes teammates, tu peux coupler ça avec GLM Delegator — un serveur MCP qui expose 5 agents experts dans Claude Code.

GLM Delegator utilise le modèle GLM-4.7 via Z.AI, qui propose un plan dédié aux outils de coding (Claude Code, Cline, et 10+ outils) à partir de 3$/mois. C’est ce qui fait tourner le ccm-manager et les experts du repo.

→ S’abonner au GLM Coding Plan sur Z.AI

Le combo Agent Teams natifs + experts GLM Delegator via MCP donne un setup où chaque teammate peut consulter un expert spécialisé pendant son travail. Le frontend dev demande un avis sécurité, le backend dev fait valider son architecture — le tout en parallèle.

C’est en research preview. C’est rough sur les bords. Mais ceux qui commencent à builder leur muscle memory maintenant auront une longueur d’avance quand ça sortira en stable.

Documentation officielle : code.claude.com/docs/en/agent-teams