Coordination multi-agents : sous-agents, worktrees, relecteurs et journaux d’événements
Confier une tâche à plusieurs agents ne pose pas d’abord la question de leur nombre, mais trois autres : ce que chaque agent peut voir, ce qu’il peut modifier, et qui réunit les résultats pour les vérifier. La façon dont un agent seul propose des actions dans une boucle contrôlée est décrite dans Harness et Boucles d’agent bornées ; cette page traite de ce qui change quand plusieurs de ces boucles tournent en même temps.
Le cas principal est Muse Code, de Meta, lancé en bêta le 5 août 2026 et sorti de bêta le 31 août, conçu dès le départ autour d’agents qui se coordonnent. L’Agents API d’OpenAI, Claude Code et Antigravity servent de points de comparaison. Les détails produits ont été vérifiés le 1er octobre 2026.
Quatre rôles
Un système multi-agents combine en général quatre rôles aux responsabilités distinctes :
- un coordinateur, qui découpe la tâche, répartit les morceaux, réunit les résultats et répond du résultat final ;
- des workers bornés, qui n’accomplissent que leur part et rendent quelque chose de vérifiable ;
- des observateurs en arrière-plan, qui ne prennent aucune tâche et surveillent une seule dimension de qualité en formulant des suggestions ;
- des relecteurs explicites, qui examinent un résultat une fois terminé.
Muse Code réunit les quatre. La session principale (lead) lance des sous-agents, chacun chargé d’une tâche bornée. Un ensemble d’observateurs en arrière-plan s’occupe du rappel de mémoire, du rappel de skills, du suivi des objectifs et de la vérification ; selon Meta, ces agents d’arrière-plan « restent actifs pendant toute la session, au lieu d’être lancés pour des tâches individuelles » (annonce). Un observateur ne fait que conseiller : « il propose, un réconciliateur décide », et seule une proposition acceptée atteint le tour suivant de l’agent principal. La relecture n’interrompt donc pas l’agent principal et ne le contourne pas pour modifier le code.
Trois frontières à ne pas confondre
« Donner à chaque sous-agent son propre environnement » semble être une seule décision. Il s’agit en réalité d’au moins trois frontières distinctes :
Les deux premières sont les plus faciles à confondre. Des contextes séparés ne signifient pas des fichiers séparés : la documentation d’OpenAI précise que le coordinateur et ses sous-agents partagent le système de fichiers d’un même environnement, et que « créer un sous-agent ne crée pas d’autre environnement ». Des fichiers séparés ne signifient pas non plus que tout est séparé. D’après le manuel de Git, un worktree ne garde pour lui que des fichiers propres à chaque arbre de travail, comme HEAD et index, et partage le reste du dépôt, y compris le stockage des objets et, par défaut, la configuration du dépôt. Deux workers qui lancent chacun un serveur de développement dans leur worktree peuvent encore se disputer un port ou écrire dans la même base de test.
Les permissions cachent un autre piège. La documentation de Claude Code rappelle que désactiver seulement Write et Edit n’empêche pas d’écrire des fichiers, puisque Bash reste disponible. Une restriction d’outils se juge aux effets qui restent possibles, pas aux noms des outils. La relation d’ensemble entre permissions, approbations et bacs à sable est traitée dans Sécurité des agents.
Une modification parallèle bornée
Un exemple fictif : un service doit recevoir un nouveau champ d’API, un affichage frontal mis à jour et la documentation correspondante, en même temps.
- Le coordinateur fixe d’abord l’interface. Le nom du champ, son type et sa valeur par défaut figurent dans la description de tâche de chaque worker. C’est la seule décision que les workers doivent partager ; elle doit donc être prise avant la répartition.
- Attribuer les répertoires selon que le worker écrit du code ou non. Les workers du backend et du frontend reçoivent chacun un worktree ; un worker qui se contente de rassembler des informations reste dans le checkout partagé, comme le recommande la documentation de Muse Code.
- Les workers rendent des preuves, pas des conclusions. Chacun rend ses commits et ses propres résultats de test, pas une simple déclaration de fin.
- Le coordinateur intègre une fois et lance une seule vérification commune. Seuls des tests sur le résultat fusionné repèrent deux moitiés qui passent chacune mais ne s’accordent pas.
- Les conflits reviennent au coordinateur. Si l’interface doit changer, le coordinateur décide et redistribue ; les workers ne modifient pas le code des autres.
Pour ce site, l’étape 1 mérite le plus d’attention. En juin 2025, Cognition a montré, exemples à l’appui, que des agents parallèles prennent des décisions implicites qui peuvent ne pas s’accorder ; chaque action devrait donc tenir compte de toutes les décisions pertinentes prises par les autres parties du système (billet). C’est un argument d’ingénierie fondé sur des cas, pas une comparaison contrôlée, et il ne mesure pas la fréquence de cet échec, mais il décrit une façon dont un travail découpé peut mal tourner.
Messages, annulation et capacité
Quand des agents s’échangent des messages, établissez d’où vient un message et ce qu’il est autorisé à faire. La messagerie entre sessions de Muse Code relie des sessions interactives indépendantes d’un même utilisateur sur une même machine macOS ou Linux, avec du texte brut de 8 192 octets au plus ; un message reçu est traité comme une « donnée non vérifiée fournie par un agent » et ne transmet pas l’autorité de l’expéditeur. Antigravity CLI 1.2.9 a ajouté la syntaxe @<sous-agent> <message> pour écrire directement dans la conversation d’un sous-agent, et l’application Antigravity 2.0 a ajouté des cartes de sous-agents en direct et des messages directs fin septembre.
L’annulation n’est généralement pas instantanée. Muse Code la décrit comme coopérative : un sous-agent annulé qui n’a pas atteint de point de contrôle continue de tourner, et celui qui est en pleine écriture la termine. Après avoir arrêté tous les agents, vérifiez l’état réel des répertoires de travail.
La capacité est elle aussi bornée. Par défaut, un arbre d’agents Muse Code exécute au plus huit agents à la fois, lead compris, et une racine ultra non configurée en exécute 64 ; la limite se règle de 1 à 64, et les petits-enfants partagent la même capacité. Quand l’arbre est plein, une nouvelle demande de lancement est refusée.
Ce qu’un journal d’événements permet de récupérer
Muse Code enregistre chaque exécution dans un journal d’événements en ajout seul qui couvre les appels au modèle, les appels d’outils et leurs résultats, ainsi que les décisions d’approbation. Après une interruption, reprendre signifie reconstruire la conversation à partir de ce journal. Le journal distingue aussi deux sortes d’effets de bord : ceux dont l’achèvement est confirmé comptent comme faits, tandis qu’un effet annoncé mais jamais confirmé oblige l’agent à vérifier l’état réel avant de décider s’il réessaie (audit et reprise).
« Rejouable » doit être compris précisément. La relecture déterministe de Muse Code reconstruit le contexte enregistré à partir des événements et « n’appelle pas de modèle, n’exécute pas d’outil et n’utilise pas le réseau ». Elle sert à l’audit et aux tests de non-régression, mais ne garantit pas qu’un effet externe ne se produise qu’une fois. Éviter qu’une nouvelle tentative débite deux fois une carte ou envoie deux fois un message dépend toujours des clés d’idempotence et des vérifications d’état décrites dans Agents de longue durée.
Quand plusieurs agents en valent la peine
Les données publiques vont dans le même sens : les tâches indépendantes se découpent bien, les tâches étroitement couplées non. En juin 2025, Anthropic a indiqué que son système de recherche multi-agents dépassait de 90,2 % un agent Opus 4 seul sur une évaluation de recherche interne, en consommant environ 15 fois plus de tokens qu’une conversation, et qu’il convient moins aux tâches très interdépendantes (billet). Ce sont des résultats internes du fournisseur, valables pour les tâches de recherche mesurées.
La relecture a aussi un coût. Sur la page de sortie de Sonnet 5.5, Anthropic explique qu’à l’effort maximal le modèle lançait plus souvent une revue de code répartie entre de nombreux sous-agents ; dans deux cas examinés par Cognition, cela a provoqué un dépassement de délai ou des modifications hors du périmètre, et le score FrontierCode est tombé sous celui du niveau inférieur. Cela établit un mécanisme d’échec, pas sa fréquence.
Lecture de ce site : faire d’abord fonctionner la tâche avec un seul agent, puis détacher les parties réellement indépendantes et vérifiables séparément, comme lire des documents différents, examiner des problèmes dans des modules distincts ou mener en parallèle des expériences sans lien. Les modifications étroitement couplées, les conceptions qui reposent sur de nombreuses décisions implicites partagées et les relectures répétées tendent à devenir plus lentes et plus coûteuses une fois découpées. Comparez sur les mêmes tâches le temps d’exécution, les tokens et les reprises, pas le nombre d’agents lancés en même temps.
Comment les outils actuels s’y prennent
Vérifié le 1er octobre 2026 :
La persistance des terminaux est encore une autre couche. Herdr restaure les terminaux de plusieurs agents après un redémarrage, mais ne découpe pas les tâches, ne fusionne pas les résultats et n’isole pas les répertoires de travail. Avant de choisir des outils, déterminez de quelle couche vous avez réellement besoin.