S’appuyer sur une seule session d’IA pour des workflows complexes et multidomaines est intrinsèquement lent. Les équipes d’agents Claude résolvent ce problème en exécutant des agents spécialisés en parallèle, pour produire des résultats plus approfondis à des vitesses nettement supérieures. Ce guide explique le fonctionnement des équipes d’agents Claude Code, leur configuration et les bonnes pratiques pour en tirer le meilleur parti.
Que sont les équipes d’agents Claude
Les équipes d’agents Claude Code sont un système de coordination multi-instance dans lequel plusieurs sessions Claude travaillent en parallèle sur la même base de code. Une session est désignée comme agent responsable : elle reçoit la tâche globale, la décompose en sous-tâches et synthétise le résultat final. Les autres sous-agents sont des coéquipiers ; chacun s’exécute dans sa propre fenêtre de contexte isolée, prend en charge une partie distincte du travail et communique directement avec les autres coéquipiers.
Avantages des équipes d’agents
Les équipes d’agents se distinguent des assistants IA classiques, qui traitent les tâches séquentiellement, une par une. Elles lèvent cette contrainte : lorsque le travail peut réellement être parallélisé, le temps écoulé diminue d’autant.
Les équipes d’agents ne se résument pas pour autant à plusieurs sessions : leur couche de coordination apporte trois capacités absentes du travail multi-session manuel :
Messagerie pair à pair : les coéquipiers peuvent s’envoyer des messages directement, sans passer par vous ni par le responsable. Par exemple, dans une équipe d’agents comprenant un relecteur sécurité, celui-ci peut signaler une découverte au relecteur performance en cours d’exécution, sans bloquer toute l’équipe.
Verrouillage des fichiers : lorsqu’un coéquipier écrit dans un fichier, il acquiert un verrou qui empêche les autres agents d’écrire simultanément. Cela évite les conflits de fusion de type écrasement silencieux.
Suivi des dépendances : le responsable encode les dépendances entre tâches lors de la décomposition. La couche de coordination les applique, de sorte qu’aucun agent ne démarre avant que ses prérequis soient satisfaits, sans vérification manuelle répétée.
Fonctionnement concret des équipes d’agents
Une équipe d’agents se compose des éléments suivants, chacun ayant un rôle précis :
Le responsable d’équipe est la session Claude Code principale. Il crée l’équipe, lance les coéquipiers, coordonne leur travail et synthétise le résultat final. C’est la session avec laquelle vous interagissez directement.
Les coéquipiers sont des instances Claude Code distinctes, chacune travaillant de façon indépendante sur les tâches qui lui sont assignées, dans sa propre fenêtre de contexte. Ils ne partagent pas leur contexte avec le responsable ni entre eux ; leur communication se fait explicitement, via la liste de tâches et la boîte aux lettres.
La liste de tâches partagée et la boîte aux lettres assurent la coordination**.** La liste de tâches partagée est une file en temps réel dans laquelle le groupe d’agents lit et écrit. Le responsable l’alimente au moment de la décomposition, puis les coéquipiers revendiquent des tâches, les exécutent et les marquent comme terminées. Les dépendances sont appliquées automatiquement : lorsqu’un coéquipier termine une tâche, toutes celles qui en dépendaient sont débloquées sans intervention manuelle. La boîte aux lettres est le système de messagerie destiné à la communication directe d’agent à agent. Les messages circulent automatiquement entre les coéquipiers et le responsable.
La configuration de l’équipe et la liste des tâches sont stockées localement (~/.claude/teams/ et ~/.claude/tasks/). Claude Code génère et maintient automatiquement ces fichiers. Ne les modifiez pas à la main, car tout changement sera écrasé lors de la prochaine mise à jour de l’état.
Configurer des équipes d’agents Claude Code
Les équipes d’agents Claude sont désactivées par défaut dans Claude Code. Elles sont signalées comme expérimentales et nécessitent une activation explicite. Voici le parcours de configuration complet. Avant d’activer les équipes d’agents, vérifiez que votre version de Claude Code est v2.1.32 ou ultérieure**.** Vous pouvez exécuter claude --version dans le terminal pour le vérifier.
Étape 1 : activer le feature flag
Définissez la variable d’environnement CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS sur 1. Trois méthodes sont possibles :
Option A : ~/.claude/settings.json (recommandée)
Option B : profil shell (~/.bashrc ou ~/.zshrc)
Option C : en ligne, pour une seule session
Si vous avez modifié settings.json ou votre profil shell, redémarrez Claude Code pour que le flag soit pris en compte.
Étape 2 : installer tmux (recommandé, non obligatoire)
Les équipes d’agents peuvent s’afficher selon deux modes : in-process (tous les coéquipiers s’exécutent dans le terminal principal) et volets fractionnés (chaque coéquipier dispose de son propre volet, ce qui nécessite tmux ou iTerm2). Exécuter chaque coéquipier dans son propre volet de terminal facilite nettement le suivi de l’équipe en temps réel.
Pour rester en mode volets fractionnés, définissez teammateMode dans ~/.claude/settings.json :
Pour remplacer le réglage par défaut "auto", définissez teammateMode sur in-process dans ~/.claude/settings.json. Pour forcer le mode in-process pour une seule session, passez-le comme flag : claude --teammate-mode in-process.
Étape 3 : utiliser un prompt pour démarrer votre équipe d’agents
Après avoir activé l’équipe d’agents, indiquez simplement à Claude, en langage naturel, les tâches, le livrable et la structure d’équipe que vous souhaitez. Vous pouvez préciser chaque rôle dans le prompt ; Claude créera l’équipe, lancera les coéquipiers et planifiera les tâches en conséquence.
Exemple de prompt :
Vous pouvez préciser le modèle utilisé par vos équipes d’agents, par exemple "Use Sonnet for every teammate". Les coéquipiers n’héritent pas du modèle de l’agent responsable. Les utilisateurs doivent préciser le modèle dans le frontmatter du fichier de rôle ou définir un modèle de coéquipier par défaut via /config.
Étape 4 : demander l’approbation du plan pour les tâches complexes (facultatif)
Pour les tâches à haut risque et complexes, vous pouvez exiger que l’équipe élabore un plan avant l’exécution. Les coéquipiers du groupe d’agents travailleront en mode lecture seule, tandis que le responsable examinera, révisera puis validera le plan. Les coéquipiers ne commenceront la mise en œuvre qu’une fois le plan approuvé par le responsable.
Notez que l’agent responsable prendra les décisions ; vous pouvez donc aussi fournir des critères de décision.
Exemple de prompt :
Étape 5 : configurer des worktrees git pour l’isolation des fichiers (facultatif, recommandé)
Si un coéquipier écrit des fichiers, les worktrees Claude Code sont fortement recommandés. Un worktree git est un répertoire de travail distinct, sur sa propre branche, qui partage le même historique .git que votre checkout principal. Chaque agent bénéficie d’un accès isolé aux fichiers, et les modifications d’un worktree n’affectent jamais le travail en cours d’un autre agent.
Pour l’activer par agent, ajoutez simplement isolation: worktree au frontmatter YAML de l’agent. Claude Code provisionne un nouveau worktree pour chaque invocation d’agent parallèle et le nettoie automatiquement lorsque l’agent a terminé.
Pour une utilisation en CLI : claude --worktree ou claude -w démarre une session dans son propre worktree. L’application de bureau crée automatiquement un worktree Claude Code par session.
Étape 6 : surveiller régulièrement
Les équipes d’agents ne fonctionnent pas en mode « lancer et oublier », et les équipes de longue durée peuvent dériver. Des agents peuvent rester bloqués sur des demandes d’autorisation, marquer des tâches comme terminées trop tôt ou perdre de vue le périmètre. Vous pouvez faire un point toutes les 10 à 15 minutes et consulter la liste de tâches partagée pour repérer les tâches bloquées ou non revendiquées. Si une tâche n’a pas avancé depuis 20 à 30 minutes, il peut s’agir d’un blocage lié aux autorisations ou d’un rôle mal défini nécessitant une intervention manuelle.
Comparaison côte à côte : sous-agents vs équipes d’agents
Les sous-agents relèvent d’un modèle de délégation. Les équipes d’agents relèvent d’un modèle de collaboration. Cette différence influe sur tout, de la gestion du contexte au coût d’une exécution.
| Sous-agents | Équipes d’agents | |
|---|---|---|
| Communication | À sens unique : le responsable délègue, les sous-agents rendent compte | Pair à pair + coordination par le responsable |
| État partagé | Aucun | Liste de tâches partagée avec suivi des dépendances |
| Fenêtres de contexte | Fenêtre de contexte propre ; les résultats reviennent au responsable | Chaque coéquipier a la sienne (jusqu’à 1 M de tokens) |
| Prévention des conflits de fichiers | Non intégré | Verrouillage des fichiers inclus |
| Coût en tokens | Plus faible | Plus élevé (chaque coéquipier est une instance distincte) |
| Reprise de session | Pris en charge | /resume and /rewind don't restore in-process teammates |
| Agents imbriqués | Pris en charge | Non pris en charge ; seul le responsable peut lancer des coéquipiers |
| Idéal pour | Délégation ciblée, workflows répétables | Travail parallélisable, interdépendant et multidomaine |
Les sous-agents suivent un modèle de délégation à sens unique : le responsable envoie une tâche, le sous-agent l’exécute dans sa propre fenêtre de contexte, puis renvoie le résultat. Il n’y a ni état partagé, ni communication directe entre agents pairs, ni couche de coordination : seulement une boucle nette d’envoi et de retour.
Les équipes d’agents travaillent sur une liste de tâches partagée avec application automatique des dépendances, et les coéquipiers échangent en pair à pair via la boîte aux lettres.
En bref, les équipes d’agents sont pertinentes lorsque le travail se divise en axes parallèles réellement indépendants, qui doivent partager leurs constats et se coordonner. Pour obtenir rapidement un résultat, traiter des tâches séquentielles, modifier un seul fichier ou privilégier la prévisibilité des coûts plutôt que la vitesse, les sous-agents restent le meilleur choix.
Quand choisir les équipes d’agents plutôt que les sous-agents
Utilisez les équipes d’agents lorsque :
Les coéquipiers doivent communiquer directement entre eux
Le travail exige une liste de tâches partagée avec suivi des dépendances entre plusieurs flux parallèles
La tâche est trop vaste pour une seule session, et chaque intervenant a besoin de son propre contexte entièrement indépendant
Utilisez les sous-agents lorsque :
Vous n’avez besoin que de la synthèse finale, pas de l’intégralité des résultats intermédiaires
Le travail est suffisamment autonome pour produire un résultat propre
Vous voulez restreindre les outils ou orienter la tâche vers un modèle moins coûteux
Vous avez besoin de pistes de recherche parallèles qui ne dépendent pas les unes des autres
Si vous ne parvenez pas à identifier au moins trois flux de travail parallèles réellement indépendants, une session unique ou des sous-agents feront probablement mieux qu’une équipe d’agents, à moindre coût.
Cas d’usage concrets des équipes d’agents
Lorsque le travail se divise naturellement en flux cadrés et délimités, que ces flux peuvent avancer sans s’attendre mutuellement (ou que leurs dépendances peuvent être encodées explicitement), et que le surcoût de coordination reste faible au regard du temps gagné par l’exécution parallèle. Voici cinq cas d’usage où les équipes d’agents surpassent une session unique.
Revue de code en parallèle
Affectez simultanément trois relecteurs à une pull request : un agent sécurité, un agent performance et un agent couverture de tests. Le responsable synthétise les trois rapports parallèles en une liste d’actions priorisée. Ce modèle fonctionne aussi pour les revues d’architecture (agent scalabilité, agent sécurité, agent maintenabilité) ou les contrôles de conformité selon différents cadres réglementaires.
Débogage par hypothèses concurrentes
Lancez cinq agents, chacun avec une hypothèse unique, pour tester des fichiers ou journaux précis afin d’analyser un bug de production. Le premier agent qui confirme son hypothèse fait émerger le correctif, et les autres peuvent être arrêtés. C’est plus efficace que d’examiner chaque théorie l’une après l’autre, en passant des heures à déboguer une piste, revenir en arrière, puis passer à la suivante.
Refactorisations transverses
Une refactorisation transverse comporte à la fois des étapes séquentielles et parallèles. Par exemple, un changement d’API incompatible nécessite de mettre à jour les endpoints backend, les composants frontend qui les consomment et la suite de tests couvrant l’ensemble. Le travail backend doit être terminé avant que le frontend puisse commencer. Une fois la tâche backend lancée, l’agent chargé de la suite de tests peut commencer en parallèle à échafauder la nouvelle structure de tests. Dans une équipe d’agents, le responsable utilise le suivi des dépendances de la liste de tâches partagée pour encoder cet ordre.
Recherche exploratoire sans contamination du contexte
Une décision technique peut nécessiter d’examiner plusieurs ensembles d’éléments probants indépendants : choisir un moteur de base de données, évaluer trois API tierces ou apprécier les outils de build. Attribuez à chaque agent un domaine sans chevauchement ; chacun publie une synthèse structurée. Le responsable agrège le tout dans un document comparatif. L’isolation préserve un point de vue indépendant, ce qui améliore la qualité des résultats.
Migration d’une grande base de code
La mise à niveau d’une dépendance majeure dans une grande base de code implique généralement de modifier plusieurs modules. Si ces modules ont des frontières nettes et peuvent migrer simultanément, les équipes d’agents sont utiles. Affectez un agent à chaque module indépendant ; chaque agent migre son module, exécute sa propre suite de tests et rend compte avec une synthèse de migration incluant les interfaces modifiées. Le responsable examine les changements d’interface avant de déclarer la migration terminée et coordonne l’ordre de fusion.
À faire et à éviter pour concevoir votre équipe d’agents
Construire un système d’agents parallèles avec Claude Code est simple à configurer, mais facile à mal concevoir. Voici les principes de conception qui déterminent si votre équipe d’agents sera performante ou fera perdre du temps.
Conseils d’expert pour construire votre système d’agents parallèles
Préapprouvez les autorisations : Les coéquipiers démarrent avec les réglages d’autorisation du responsable. Si le responsable s’exécute avec --dangerously-skip-permissions, tous les coéquipiers en héritent également. Vous pouvez ajuster les modes individuels des coéquipiers après leur lancement, mais les modes par coéquipier ne peuvent pas être configurés au moment du lancement. Définissez votre posture d’autorisation via le responsable avant de lancer l’équipe.
Rédigez des prompts de rôle précis : Chaque prompt de rôle doit spécifier quatre éléments : quoi faire, dans quels fichiers ou domaines travailler, sur quoi se concentrer et quoi exclure, ainsi que la forme attendue du livrable. Lors du lancement des coéquipiers, vous pouvez référencer des types de sous-agents depuis n’importe quel périmètre de sous-agent : projet, utilisateur, plugin ou définition CLI. Vous pouvez ainsi définir un rôle une seule fois — par exemple relecteur sécurité ou lanceur de tests — puis le réutiliser à la fois comme sous-agent délégué et comme coéquipier d’une équipe d’agents.
Imposez l’isolation des fichiers : Pour tout agent qui écrit sur le disque, utilisez l’isolation. Deux agents qui modifient simultanément le même fichier constituent l’un des moyens les plus sûrs de produire une sortie corrompue.
Faites des points réguliers : Toutes les 10 à 15 minutes pour les équipes d’agents actives. Consultez la liste de tâches partagée pour repérer celles qui n’ont pas avancé. Une tâche bloquée plus de 20 à 30 minutes peut être due à un problème d’autorisation, à un rôle mal défini ou à une dépendance circulaire, ce qui peut nécessiter une résolution manuelle.
Encodez explicitement les dépendances : Si la tâche B suit logiquement la tâche A, inscrivez cette dépendance dans la liste de tâches au moment de la décomposition, plutôt que comme instruction dans un prompt de rôle. La couche de coordination applique automatiquement les dépendances ; les instructions dans les prompts peuvent être mal comprises ou ignorées.
Définissez les périmètres de responsabilité dans votre fichier md : Pour les projets multi-sessions, écrivez une règle indiquant que chaque module ou répertoire a exactement un agent propriétaire. Cela évite les chevauchements avant même le lancement de l’équipe.
Nettoyez toujours via le responsable, jamais via un coéquipier : Le responsable vérifie les coéquipiers actifs avant de libérer les ressources. Les coéquipiers ne disposent pas du contexte complet de l’équipe pour nettoyer en toute sécurité ; le faire risque de laisser la session dans un état incohérent.
Erreurs courantes à éviter avec votre équipe d’agents
Ne lancez pas une équipe pour une tâche qu’une seule session peut traiter proprement : Avant d’écrire le moindre fichier de rôle ou d’envoyer le moindre prompt de swarm, dessinez le graphe des tâches. Quelles sous-tâches sont réellement indépendantes ? Lesquelles ont des dépendances ? Le travail est-il dépendant de manière séquentielle ? Si vous ne pouvez pas formuler trois axes parallèles aux frontières nettes, une session unique fera mieux que l’équipe.
N’affectez pas deux agents au même fichier. C’est la source la plus fréquente de conflits de fusion et d’écrasements silencieux. Si votre décomposition de tâches aboutit à deux agents devant modifier le même composant, le travail sur ce composant doit être séquentiel : confiez-le à un agent, puis au suivant une fois le premier terminé.
Ne faites pas l’impasse sur la préapprobation des autorisations dans Claude Code. Les demandes d’autorisation qui apparaissent en cours d’exécution bloquent le parallélisme et nécessitent une intervention manuelle. Cette surcharge annule une grande partie du bénéfice. Préapprouvez les écritures de fichiers et les commandes shell dans le répertoire de travail avant de lancer l’équipe.
Ne comptez pas restaurer votre équipe Claude Code. Si une session est nettoyée, /resume et /rewind ne restaurent pas les coéquipiers en cours d’exécution. Enregistrez les sorties intermédiaires importantes avant les longues exécutions.
Ne dépassez pas cinq agents sans raison claire. Les coûts en tokens augmentent linéairement, mais la surcharge de coordination croît plus vite. Trois agents ciblés, aux rôles bien cadrés, surpassent régulièrement cinq agents aux rôles flous. N’ajoutez des coéquipiers que lorsqu’un flux de travail parallèle explicite les attend — pas simplement parce que « plus » semble forcément mieux.
Un autre paradigme : constituez votre équipe multi-agent dans Kimi Agent Swarm
Les équipes d’agents Claude Code excellent dans les scénarios propres aux développeurs, avec une intégration poussée aux workflows de terminal et à l’écosystème Git. Mais le paradigme de la collaboration multi-agent va bien au-delà de la ligne de commande. Kimi Agent Swarm est l’endroit où ce paradigme devient accessible à tous.
Kimi Agent Swarm est le système de collaboration multi-agent de Kimi, conçu pour les tâches complexes et de grande ampleur. Il décompose un objectif large en sous-tâches distinctes et planifie différents agents et compétences pour gérer simultanément la recherche, la lecture, l’analyse, la rédaction, le codage, la génération de feuilles de calcul, la création de diapositives et la construction de pages web. Aucun flag env. Aucune configuration git requise.
Fonctionnalités clés de Kimi Agent Swarm
Collaboration parallèle avec jusqu’à 300 sous-agents : Kimi Agent Swarm décompose une tâche complexe et planifie plusieurs sous-agents pour traiter les sous-tâches simultanément. Le système peut coordonner jusqu’à 300 sous-agents afin d’exécuter plus de 4 000 appels d’outils en une seule exécution.
Exécution composée multi-compétences : Le Swarm peut combiner plusieurs compétences spécialisées en une seule exécution, notamment la recherche approfondie, le pptx, la rédaction de rapports, le vibe-coding, la création de sites web et la rédaction d’articles, avec une profondeur de sortie et une couverture de formats supérieures à celles d’un agent unique.
Traitement documentaire à grande échelle : Agent Swarm peut traiter des fichiers par lots dans plus de 20 formats (PDF, Word, Excel, PPT, images, etc.), lire, extraire les informations et résumer le contenu en parallèle sur l’ensemble des documents, avec la capacité de référencer des bibliothèques, des fichiers de veille concurrentielle ou des données ingérées depuis plusieurs sources.
Recherche large et proactive : Pour les tâches qui exigent de couvrir de vastes champs d’information, Agent Swarm envoie des sous-agents rechercher sur le web, localiser des sources, télécharger du contenu, catégoriser les résultats et générer des synthèses structurées en parallèle.
Raisonnement multi-perspectives : Agent Swarm peut mobiliser simultanément plusieurs points de vue experts sur un même problème. On obtient ainsi une analyse plus complète qu’avec un passage à point de vue unique, et des angles morts que la revue séquentielle laisse souvent passer.
Production de contenus approfondis : L’architecture parallèle d’Agent Swarm est conçue pour des livrables de grande profondeur, comme des rapports de recherche de plusieurs centaines de pages, des analyses sectorielles longues, des revues de littérature académique, des guides d’apprentissage structurés et des contenus narratifs étendus.
Sortie multiformat en une seule exécution : Agent Swarm peut produire simultanément plusieurs types de livrables pour une même tâche, par exemple un rapport PDF, une présentation PPT, une page web, un jeu de données Excel et un projet de code.
Comment lancer une équipe d’agents dans Kimi Agent Swarm
Étape 1 : ouvrez Kimi Agent Swarm et saisissez votre prompt
Ouvrez la page Agent Swarm et décrivez votre tâche dans la zone de saisie. Pour de meilleurs résultats, soyez précis sur le périmètre, les livrables attendus et les éventuelles contraintes, comme la période, les sources ou les exigences de format.
Exemple de prompt :
Étape 2 : laissez Kimi Agent Swarm travailler
Après l’envoi de votre prompt, Agent Swarm décompose la tâche en sous-tâches et répartit les sous-agents pour travailler en parallèle. Vous pouvez suivre la progression en temps réel, notamment la planification des tâches, le lancement des sous-agents et l’exécution parallèle.
Étape 3 : recevez les résultats, prévisualisez-les, puis téléchargez-les ou partagez-les
Une fois l’exécution terminée, vos livrables sont prêts à être prévisualisés directement dans l’interface. Selon votre tâche, les sorties peuvent inclure des rapports de recherche, des analyses de données, des présentations PPT, des pages web, des projets de code ou une combinaison de ces éléments. Vous pouvez télécharger les fichiers et les partager directement.
Cas d’usage où Kimi Agent Swarm excelle
Rédaction d’appels d’offres et de propositions : Affectez en parallèle des agents aux spécifications techniques, aux exigences de conformité, aux modèles de tarification et aux études de cas ; l’orchestrateur les intègre dans une proposition cohérente.
Analyse financière : Affectez en parallèle des agents aux données de marché, aux publications des concurrents, aux indicateurs macroéconomiques et aux modèles internes ; l’orchestrateur les synthétise dans une analyse unifiée.
Recherche business : Affectez en parallèle des agents aux panoramas concurrentiels, aux entretiens clients, aux rapports sectoriels et au contexte réglementaire issus de différentes sources ; l’orchestrateur produit une sortie structurée.
Tests de sécurité : Lancez des agents en parallèle pour la reconnaissance, l’analyse de vulnérabilités, l’audit des dépendances et les contrôles d’élévation de privilèges ; l’orchestrateur agrège les constats dans un rapport final.
Développement full-stack : Créez des agents parallèles pour les composants frontend, les endpoints backend, le schéma de base de données et les suites de tests ; l’orchestrateur coordonne l’intégration sur l’ensemble de la stack.
Conclusion
Les équipes d’agents Claude Code sont conçues pour les workflows d’ingénierie : elles apportent l’exécution parallèle aux bases de code complexes directement depuis le terminal. Si votre travail va au-delà du code, Kimi Agent Swarm transpose le même paradigme multi-agent à la recherche, à l’analyse, au contenu et bien plus encore. Décrivez simplement votre tâche et laissez le swarm gérer le reste.