Claude Code Agent Teams : l’orchestration multi-agents qui change la donne

Depuis des années, les agents IA travaillent seuls. Un modèle, un contexte, une tâche à la fois. Cette architecture séquentielle a suffi pour automatiser des flux simples, mais elle bute sur un plafond évident : certains problèmes sont trop vastes pour tenir dans une seule fenêtre de contexte, trop complexes pour s’exécuter sans parallélisme. Claude Code vient de franchir un cap avec les Agent Teams — une fonctionnalité expérimentale qui permet à plusieurs instances de Claude de former une véritable équipe de travail, avec un chef de projet, des coéquipiers spécialisés et un système de communication entre agents.

De l’agent solo à l’équipe d’agents : pourquoi ça change tout

Un agent IA classique est fondamentalement séquentiel. Il reçoit une instruction, exécute des étapes les unes après les autres, et rapporte un résultat. Cette approche convient parfaitement pour des tâches bien délimitées — corriger un bug, générer un composant, écrire une fonction. Mais dès qu’on s’attaque à des projets d’envergure — refactoriser une base de code entière, développer plusieurs modules interdépendants, explorer simultanément plusieurs hypothèses techniques — le modèle solo montre ses limites.

La contrainte n’est pas seulement de capacité. C’est une contrainte architecturale. Un agent unique ne peut travailler que sur une chose à la fois. Le reste attend.

L’IA agentique a toujours promis de dépasser ce plafond. Avec les Agent Teams, Claude Code franchit un pas concret dans cette direction : plusieurs agents s’exécutent en parallèle, chacun dans sa propre fenêtre de contexte, coordonnés par un lead qui organise le travail, suit les dépendances et synthétise les résultats.

La parallélisation change la nature de ce qui est possible. Un projet qui prendrait des heures en séquentiel peut être découpé en blocs indépendants et traité simultanément. Des équipes réelles de développeurs fonctionnent exactement ainsi — l’IA commence à faire de même.

Comment fonctionnent les Agent Teams

L’architecture des Agent Teams, documentée sur le site officiel de Claude Code, repose sur quatre composants qui travaillent ensemble.

Le lead et les coéquipiers

Chaque équipe dispose d’un agent lead qui joue le rôle de chef de projet. C’est lui qui reçoit la mission initiale, décompose le travail en tâches, instancie les coéquipiers (les teammates) et coordonne l’avancement. Les coéquipiers, de leur côté, opèrent en autonomie complète dans leur propre fenêtre de contexte — jusqu’à 1 million de tokens chacun selon les informations de la documentation. Ils n’ont pas accès au contexte des autres agents, mais ils peuvent communiquer avec eux.

Cette séparation des contextes est un choix délibéré. Elle évite que les agents se parasitent mutuellement et garantit que chacun reste concentré sur sa portion du travail.

Dans la pratique, les équipes peuvent être composées de profils différents selon la nature du projet : un lead en Claude Opus 4.6 pour la coordination, des développeurs en Claude Sonnet pour l’implémentation, et des agents de vérification en Haiku pour les tâches plus légères — comme les tests ou les révisions de syntaxe. Cette stratification permet d’optimiser les coûts tout en conservant la qualité de coordination au sommet.

La liste de tâches partagée

Le backbone de coordination s’appuie sur une liste de tâches partagée, stockée localement dans ~/.claude/tasks/{nom-de-l-equipe}/. Chaque tâche possède un statut, un propriétaire et des dépendances déclarées.

Le mécanisme de dépendances est particulièrement intéressant : quand un coéquipier complète une tâche dont d’autres tâches dépendent, les tâches bloquées se débloquent automatiquement. Il n’y a pas besoin d’intervention manuelle pour orchestrer la chaîne. Les agents réclament des tâches disponibles, les marquent en cours, puis les finalisent — le système gère la concurrence.

Pour éviter les conflits sur les fichiers partagés, les Agent Teams utilisent un mécanisme de lock files couplé à la synchronisation Git. Un agent qui modifie un fichier pose un verrou ; les autres agents en sont informés et adaptent leur travail en conséquence.

Le système de boîte aux lettres

La deuxième innovation architecturale est le système de mailbox. Contrairement à ce qu’on pourrait imaginer, les agents ne se contentent pas de déposer des résultats dans une file d’attente que le lead consulte. Ils peuvent s’envoyer des messages directement, en pair-à-pair, sans passer par l’intermédiaire.

Concrètement, un coéquipier qui découvre une contrainte technique importante peut en notifier immédiatement un autre coéquipier dont le travail serait impacté. Le lead n’a pas besoin de jouer les centraux téléphoniques pour chaque échange. Cette communication directe entre agents est l’une des caractéristiques qui différencient fondamentalement les Agent Teams d’une architecture de sous-agents classique.

La différence avec les sous-agents classiques

Les sous-agents de Claude Code existent depuis plus longtemps. Ils fonctionnent au sein d’une session unique et ne peuvent remonter des résultats qu’à l’agent principal. Ils ne se parlent pas entre eux. Chaque échange passe obligatoirement par le nœud central.

Les Agent Teams retirent ce goulet d’étranglement. La communication est distribuée, les agents persistent au-delà d’une interaction, et l’utilisateur peut interagir directement avec un coéquipier individuel sans passer par le lead. C’est une différence qualitative, pas seulement quantitative.

Activer la fonctionnalité

Les Agent Teams sont disponibles pour les abonnés Claude Pro et Max (à partir de 20 $ par mois), sous réserve d’utiliser Claude Opus 4.6 ou une version ultérieure. La fonctionnalité est expérimentale et désactivée par défaut.

L’activation se fait en deux étapes. D’abord, définir la variable d’environnement :

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

Ensuite, l’ajouter dans le fichier settings.json de Claude Code pour qu’elle persiste entre les sessions :

{
  "experimentalAgentTeams": true
}

Une fois activée, la commande /team devient disponible dans Claude Code. On peut alors définir une mission, préciser les rôles souhaités (le système peut aussi les inférer automatiquement), et lancer l’équipe.

Pour le monitoring, l’outil tmux est souvent recommandé par la communauté : il permet d’afficher plusieurs panneaux côte à côte, un par agent, pour suivre l’avancement en temps réel et intervenir sur un coéquipier spécifique si nécessaire.

L’expérience emblématique : 16 agents construisent un compilateur C

Pour démontrer les capacités des Agent Teams, Anthropic a conduit une expérience de référence : construire un compilateur C complet, implémenté en Rust, capable de compiler le noyau Linux — sans aucune intervention humaine dans l’écriture du code.

Le résultat : 100 000 lignes de Rust, produites au fil de 2 000 sessions Claude Code, impliquant 16 agents travaillant en parallèle, le tout en moins de deux semaines. Le coût total en appels API : 20 000 dollars.

Le compilateur n’est pas un jouet. Il compile QEMU, FFmpeg, SQLite, PostgreSQL et Redis. Il passe 99 % des suites de tests du compilateur GCC. Il compile et exécute Linux 6.9 sur les architectures x86, ARM et RISC-V. Et il compile Doom — le test ultime, selon la tradition.

Ce qui rend cette expérience particulièrement instructive, c’est la contrainte posée dès le départ : Claude n’avait pas accès à internet pendant le développement. L’implémentation est une création originale, qui ne dépend que de la bibliothèque standard Rust. Ce n’est pas une réécriture automatisée d’un code existant.

Les 16 agents travaillaient dans des conteneurs Docker séparés, partageant un dépôt Git commun comme mécanisme de collaboration. Chaque agent traitait une section du compilateur, sans voir le travail des autres en temps réel — la coordination passait par les commits et les interfaces définies en amont.

Il faut cependant noter ce que cette expérience ne dit pas : les 20 000 $ couvrent uniquement les coûts API. L’effort humain d’ingénierie pour concevoir le workflow, décomposer le compilateur en tâches parallélisables, gérer les agents et résoudre les impasses d’intégration n’est pas comptabilisé. Les ingénieurs d’Anthropic ont joué un rôle d’architectes et d’orchestrateurs. La réussite de l’expérience dépend autant de la qualité de la décomposition du problème que des capacités brutes du modèle.

Quand utiliser les Agent Teams (et quand ne pas le faire)

Les Agent Teams ne sont pas la réponse universelle à tous les problèmes de développement. La coordination entre agents a un coût — en tokens, en temps, et en complexité de debugging. Il faut choisir le bon outil selon la nature du travail.

Les cas d’usage où les Agent Teams brillent :

• Refactorisation à grande échelle : modifier l’architecture d’un projet qui touche des dizaines de fichiers et de modules. Plusieurs agents peuvent travailler sur des parties distinctes simultanément, avec des réductions de temps significatives. Les retours d’expérience rapportent des accélérations de l’ordre de 12x sur des projets de refactorisation conséquents.

• Implémentation multi-couches : quand un projet nécessite de travailler simultanément sur le backend, le frontend, les tests et la documentation, les agents spécialisés par couche avancent en parallèle.

• Exploration d’hypothèses concurrentes : tester plusieurs approches architecturales en même temps et comparer les résultats, plutôt que de les évaluer séquentiellement.

• Tâches trop volumineuses pour un seul contexte : quand la codebase dépasse ce qu’une seule fenêtre de contexte peut gérer efficacement.

Les cas où un agent unique (ou des sous-agents) reste préférable :

• Tâches fondamentalement séquentielles avec de nombreuses dépendances entre étapes — la coordination ajouterait de la friction sans gain.

• Travail intensif sur les mêmes fichiers par plusieurs agents simultanément — les conflits de merge deviennent un problème difficile à gérer.

• Débogage fin sur un problème localisé — un seul agent avec tout le contexte est plus efficace.

Recommandations pratiques issues du terrain :

Les équipes qui ont utilisé les Agent Teams en production recommandent généralement de limiter à 3 ou 5 agents et de ne pas dépasser 5 ou 6 tâches par agent. Au-delà, la coordination devient un problème en soi. Il vaut mieux plusieurs équipes petites et bien définies qu’une grande équipe désorganisée.

La qualité du prompt de mission est déterminante. Un prompt vague génère une décomposition vague. Définir explicitement les rôles, les livrables attendus et les interfaces entre modules donne des résultats nettement meilleurs.

Les limites actuelles à connaître

La fonctionnalité est expérimentale, et cela se ressent. Plusieurs limitations connues méritent d’être anticipées avant d’engager un projet important.

La reprise de session ne restaure pas les coéquipiers actifs. Si on utilise /resume ou /rewind, les coéquipiers en cours de travail ne sont pas restaurés. L’état de l’équipe est perdu. C’est une contrainte majeure pour les projets longs.

Le suivi de statut des tâches est parfois défaillant. Il arrive que des coéquipiers oublient de marquer leurs tâches comme terminées. Le système de coordination peut alors penser que du travail est encore en cours alors qu’il est achevé. Un monitoring humain reste nécessaire sur des projets conséquents.

L’arrêt de l’équipe peut être lent. Interrompre une session avec des coéquipiers actifs ne les arrête pas instantanément. Le processus de shutdown peut prendre du temps, ce qui peut surprendre lors des premières utilisations.

Un lead ne peut gérer qu’une seule équipe à la fois. Impossible d’imbriquer des équipes — un coéquipier ne peut pas à son tour créer une sous-équipe. L’architecture est plate, pas hiérarchique.

La consommation de tokens est élevée. Plusieurs agents avec chacun leur propre contexte d’un million de tokens, communiquant entre eux, peuvent générer des coûts significatifs sur des projets longs. Le modèle d’abonnement Pro ou Max est dimensionné pour absorber cela, mais les utilisateurs à l’usage mesuré doivent en être conscients.

Ces limitations sont connues d’Anthropic et figurent dans la documentation officielle. Elles seront vraisemblablement adressées au fil des versions, mais dans l’état actuel, elles définissent le périmètre d’utilisation raisonnable de la fonctionnalité.

L’avenir de l’orchestration multi-agents

Les Agent Teams s’inscrivent dans une tendance plus large que nous avons explorée en détail dans notre analyse de l’émergence de l’IA agentique : le passage d’une IA réactive, sollicitée à la demande, vers une IA proactive, capable d’opérer en autonomie sur des horizons temporels longs.

L’expérience du compilateur C illustre ce que cette trajectoire rend possible. Un projet de 100 000 lignes de code, conçu et implémenté sans intervention humaine dans l’écriture. Ce n’était pas envisageable il y a deux ans. C’est un fait accompli aujourd’hui.

Ce qui évolue en parallèle, c’est la capacité à connecter ces agents à des systèmes externes. Le protocole MCP joue ici un rôle clé : en standardisant la façon dont les modèles accèdent aux outils, aux APIs et aux bases de données, il permet à des équipes d’agents de travailler non seulement sur du code, mais sur des systèmes d’information complexes. La combinaison des Agent Teams avec MCP ouvre des possibilités d’automatisation que les architectures précédentes ne permettaient tout simplement pas d’atteindre.

La question n’est plus « est-ce que l’IA peut faire ça ? » mais « comment orchestrer les agents pour que ça se passe bien ? » — une question d’ingénierie et de design, pas de capacité brute. C’est un changement de paradigme.

Les développeurs qui adoptent Claude Code aujourd’hui face à des concurrents comme Google Antigravity ne se positionnent pas seulement sur un outil d’assistance au code. Ils intègrent une plateforme qui, progressivement, devient capable de prendre en charge des pans entiers du travail de développement — avec des équipes d’agents qui travaillent pendant qu’ils dorment.