Équipes d'agents Claude Code : orchestrez une vraie équipe d'IA
Plusieurs agents Claude qui se parlent, se contredisent, et travaillent en parallèle sur votre projet. Découvrez les équipes d’agents et boostez votre productivité !
TL;DR
Agent Teams, ce sont plusieurs instances Claude Code qui communiquent directement entre elles, et plus seulement avec l’orchestrateur
Différence clé avec les subagents : communication maillée
Une ligne pour activer cette feature expérimentale
Cas d’usage fort : debug par hypothèses concurrentes, review parallèle, refacto cross-layers
Coût réel : ~3-4x les tokens d’une session solo : à utiliser avec discernement
Lorsque je travaillais pour un gros client dans le domaine du voyage, j’ai rencontré un problème avec le composant de checkout qui flashait à chaque interaction. Mais c’était parfois, pas tout le temps. Vous avez sûrement déjà rencontré ce genre de bugs.
Mais d’où ça pouvait venir ? État désynchronisé ? useEffect avec les mauvaises dépendances ? Re-render du parent non mémoïsé ? Problème de reconciliation React ? Animation CSS qui conflicte avec un setState async ? Beaucoup trop de pistes à explorer.
Jusqu’ici, avec une seule instance Claude Code, vous choisissez une piste et vous l’explorez à fond. Et l’agent s’y ancre même si c’est la mauvaise. C’est le biais de confirmation appliqué à l’IA : la première théorie plausible devient la réponse par défaut.
Anthropic a récemment trouvé et proposé la solution à ce problème. La feature Agent Teams (ou “équipes d’agents” en bon français) permet de lancer plusieurs Claude Code en parallèle, de les faire communiquer directement entre eux, et de les faire se contredire jusqu’à ce que la vérité émerge. À partir de là, on ne délègue plus à des sous-traitants isolés : vous managez une “vraie” équipe avec tout ce que ça implique de coût (vos précieux tokens), de coordination, et de puissance.
La distinction qui change tout
Vous connaissez peut-être les subagents (si ce n’est pas le cas, je vous en parle dans cet article). Un agent principal délègue à des workers, les workers exécutent, rapportent leur résultat, et l’agent synthétise. C’est propre, prévisible, efficace pour les tâches isolées.
Mais avec Agent Teams, l’architecture différente.
La différence tient en un mot : maillage. Dans un système de subagents, tout passe par le chef. Agent A veut partager une découverte avec Agent B ? Il doit passer par l’orchestrateur, qui relaie. C’est ce qu’on appelle du hub-and-spoke : central, contrôlé... mais lent.
Avec Agent Teams, les teammates comme les appelle Anthropic, se parlent directement. Agent A envoie un message à Agent B sans intermédiaire. Ils partagent une task list commune, se répartissent le travail, et peuvent contester les conclusions des autres en temps réel.
L’architecture : quatre briques
Un Agent Team repose sur quatre composants qui travaillent ensemble (j’ai repris les termes de la documentation officielle de Claude Code en anglais, pour que vous puissiez vous y retrouver si vous souhaitez faire davantage de recherches par la suite) :
le Team Lead : votre session principale. Elle crée l’équipe, répartit les tâches, synthétise les résultats. C’est vous, en tant que manager, qui lui donnez les instructions.
les Teammates : des instances Claude Code indépendantes. Chacune a sa propre fenêtre de contexte, comme les sub-agents. Elles ne partagent pas l’historique du lead, mais elles lisent le CLAUDE.md et chargent les MCPs de votre projet au démarrage.
la Task List : une liste partagée que tous les agents lisent et modifient. Chaque tâche a un état : pending, in progress, completed, ou blocked. Le verrouillage de fichiers évite les race conditions quand deux agents tentent de prendre la même tâche simultanément.
la Mailbox : le système de messagerie inter-agents. Les messages sont délivrés automatiquement.
Les teammates sont générés en 20 à 30 secondes.
Activer et lancer votre première team
C’est expérimental et désactivé par défaut, mais une variable d’environnement suffit :
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1Ou dans votre settings.json pour la persistance :
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}Vous avez besoin de Claude Code v2.1.32 ou plus récent, ce qui devrait être le cas lorsque vous lirez ces lignes. Vous pouvez vérifier avec claude --version.
Ensuite, vous décrivez votre équipe en langage naturel. Comme d’habitude, la granularité du prompt détermine la qualité du résultat : vague et votre équipe sera mal définie, précis et chaque teammate connaîtra exactement son périmètre.
Exemple pour une review de PR :
Crée une équipe d'agents pour examiner la PR #89. Lance trois teammates :
- **revue de sécurité** : audite les vulnérabilités, vérifie la gestion des tokens et des sessions
- **analyse de performance** : profile les temps de réponse, identifie les goulots d'étranglement, signale les requêtes N+1
- **vérification de couverture de tests** : valide les cas limites, repère les chemins non testés, examine les tests d'intégration
Fais en sorte qu'ils partagent leurs constats, remettent en question les conclusions les uns des autres, et produisent un rapport unifié.Claude crée le lead, génère les trois instances et distribue les tâches via la task list. Vous pouvez parler à chaque teammate directement sans passer par le lead.
Les cas d’usage qui valent le “coût”
Disons-le dès maintenant : les Agent Teams consomment beaucoup de tokens. Une équipe de 3 teammates, c’est 3 à 4 fois les tokens d’une session solo. Du coup, il ne s’agit pas de se demander si vous pouvez vous le permettre mais plutôt si le gain le justifie.
Pour vous aider, voici quelques cas pour lesquels la réponse est oui.
le debug par hypothèses concurrentes. C’est le cas d’usage le plus puissant, et le plus contre-intuitif. Un seul agent explore une théorie et s’y ancre, alors que cinq agents vont tenter activement de se réfuter mutuellement. La théorie qui survit est presque toujours la bonne.
la review parallèle multi-dimensions. Un agent focalisé sécurité, un autre perfs, un troisième couverture de tests, simultanément, sans se gêner. La review est terminée deux à trois fois plus vite, et chaque dimension reçoit une attention optimale.
le refacto cross-layers. Frontend, backend, tests, etc., chacun géré par un teammate distinct, chacun propriétaire de son périmètre de fichiers, sans conflits, ni attente. Assurez-vous que les teammates ne touchent pas aux mêmes fichiers.
l’exploration architecturale. Trois agents défendent trois approches différentes pour un problème de design et vous, vous arbitrez sur la base du débat. C’est différent de demander à un seul Claude “quelle est la meilleure approche” : ici, vous obtenez une confrontation réelle, et non pas une réponse optimisée pour vous plaire, ce que l’IA a tendance à proposer.
Quand ne pas l’utiliser
À l’inverse, voici quelques cas pour lesquels il ne faut pas utiliser les Agent Teams : si vos tâches sont séquentielles (l’output de A est nécessaire à B), les subagents suffisent. Si vos agents doivent modifier les mêmes fichiers, vous aurez des conflits. Si la tâche est rapide et indépendante, la coordination overhead mange le bénéfice.
Veillez également à ne lancer que 3 à 5 teammates maximum et leur assigner 5 à 6 tâches au plus. Au-delà, la coordination devient le problème et vous évitez ainsi du context switching excessif.
Les limites à connaître
Comme dit plus haut, cette feature est expérimentale. Vous risquez donc de rencontrer quelques soucis.
Par exemple, si vous reprenez une session interrompue, les agents n’existent plus : le lead va essayer de leur parler et échouer. Il faudra les relancer manuellement.
Aussi, les tâches peuvent rester bloquées en in progress alors que le travail est terminé. Le teammate peut oublier de mettre à jour la task list. Vous devez donc surveiller et corriger, soit manuellement, soit en demandant au lead de relancer.
Pour l’instant, réservez Agent Teams aux moments où le gain est évident et le risque gérable. Pour le reste, les subagents classiques et sessions parallèles via git worktrees (on en a parlé récemment) font très bien le travail.
Que faire à partir de maintenant ?
Pour l’anecdote, la version v1.109 de VS Code est sortie en février 2026 avec le support natif des agents Claude et une Agent Sessions view unifié. Du coup, Microsoft positionne désormais son IDE comm une “home for multi-agent development”.
Vous le savez peut-être, l’orchestration multi-agents est à la mode et sort du stade de l’expérimentation de niche : elle devient commune et habituelle. Agent Teams de Claude Code est expérimentale, certes mais c’est la direction prise par l’industrie ces dernières semaines. Si vous les comprenez et commencez à les utiliser maintenant, il y a fort à parier que vous aurez une longueur d’avance quand ça deviendra stable.
Mon conseil : activez la feature et utilisez-la uniquement lorsque ce sera nécessaire. Testez sur un vrai bug ou une vraie review et mesurez le delta avec votre workflow actuel. La prochaine évolution de la productivité des développeurs, quelle que soit leur spécialité, résidera dans leur capacité à orchestrer plusieurs contextes en parallèle.
Cet article vous a été utile ? Partagez-le à un collègue dev ! Et si vous ne vous êtes pas encore abonné à CodeCodeCoders, c’est le moment : je couvre chaque semaine les outils et pratiques qui changent vraiment votre quotidien de développeur.