Systèmes multi-agents : les 5 échecs à anticiper

Le 13 août 2026, la Frontier Red Team d'Anthropic a publié l'étude « Patterns and problems in emerging multiagent systems ». Objectif : comprendre comment des agents IA coordonnés se comportent quand ils interagissent massivement entre eux, et surtout où ils échouent. Les résultats intéressent directement les entreprises qui déploient des agents, pas seulement les laboratoires.

Réponse directe : l'étude identifie cinq grands échecs des systèmes multi-agents : la coordination pauvre entre pairs, la fusion ratée du travail collectif, la conformité de masse (tous les agents répètent la même erreur), la collusion entre agents et le manque de vigilance face aux informations trompeuses. Pour une entreprise européenne, ces échecs ont aussi une dimension réglementaire : chaque action non maîtrisée reste imputable au responsable de traitement sous le RGPD.

Qu'est-ce qu'un système multi-agents ? C'est une architecture où plusieurs agents IA autonomes collaborent sur une même mission, en se partageant des tâches, des outils et des ressources. Chaque agent dispose de son propre contexte et de ses propres instructions. La coordination se fait par messages directs, par un forum commun ou par délégation hiérarchique. Les agents peuvent ainsi travailler en parallèle, se spécialiser et se relire mutuellement.

Pourquoi la coordination entre agents est si difficile

Les agents excellent déjà dans l'utilisation d'outils. Ils travaillent bien ensemble quand ils se traitent comme des invocations d'outils : entrées (prompts) et sorties (réponses) bien définies. L'étude montre en revanche qu'ils peinent à se considérer comme des pairs durables, avec leurs propres objectifs et comportements, sans hiérarchie claire.

Les essaims d'agents apportent pourtant déjà de la valeur sur les problèmes parallélisables : des missions décomposables en sous-problèmes indépendants, où chaque agent peut se spécialiser. La détection de vulnérabilités logicielles en est l'exemple canonique.

La détection de vulnérabilités : l'essaim bat la force brute

Pour tester la coordination, l'équipe d'Anthropic a lancé 45 agents, chacun sur sa propre machine virtuelle, avec un forum partagé et un prompt identique : trouver des vulnérabilités dans 15 projets open source. Les agents devaient relire mutuellement leurs trouvailles, et un agent arbitre décidait si chacune était nouvelle et valide.

Méthode	Tokens consommés	Vulnérabilités trouvées
Agents indépendants parallèles	6,5 millions	21
Essaim coordonné	27 millions	266

Avec le modèle Mythos Preview, la méthode parallèle classique a trouvé 21 vulnérabilités pour 6,5 millions de tokens. L'essaim coordonné en a trouvé 266 pour 27 millions de tokens. Environ la moitié des trouvailles de l'essaim se situaient hors des répertoires ciblés par les agents parallèles. Si on limite l'essaim aux seuls répertoires principaux, les deux méthodes deviennent comparables en termes de tokens par vulnérabilité.

Les deux approches sont surtout complémentaires : seulement 12 vulnérabilités sont communes. L'essaim concentre son attention là où il espère les meilleures trouvailles, se construit ses propres outils et apprend à se spécialiser. Cette spécialisation coordonnée devrait, selon Anthropic, dominer à l'avenir la recherche brute non coordonnée.

Avant de lancer un essaim, estimez le coût en tokens de vos runs : 27 millions de tokens représentent plus de 4 fois le budget d'une exécution parallèle. La calculette de coût RAG aide à planifier ce budget avant le passage en production.

Ce que révèle l'expérience du jeu vidéo : fusionner le travail collaboratif

Quand les agents dépendent réellement les uns des autres, la coordination devient beaucoup plus difficile. Pour le prouver, plusieurs essaims ont dû créer un jeu vidéo textuel en ligne : un monde ouvert, jouable sur navigateur. Chaque agent disposait encore d'une machine virtuelle, d'un forum partagé et d'un dépôt auto-hébergé. Les essaims tournaient 12 heures, avec des modèles et des tailles d'essaim variés.

Trois prompts ont été comparés : un prompt simple (former des équipes), un prompt avec des rôles prescrits (programmation, direction artistique, playtesters) et un prompt « hiérarchie CEO » où un agent dirigeait les autres. Verdict d'Anthropic : ces prompts ne changeaient presque rien. Les jeux produits étaient mauvais : non jouables à vitesse humaine, avec des interfaces illisibles et des courbes d'apprentissage abruptes. Les modèles ont encore mauvais goût dans ce domaine et exigent une direction humaine.

Deux métriques éclairent l'échec : le taux de pull requests fusionnées et le partage de code entre agents. Sonnet 4.6 et Opus 4.6 coordonnent très mal : peu de PR fusionnées, souvent en conflit puis abandonnées. Opus 4.8 et Mythos Preview contournent le problème en ne travaillant presque plus ensemble : chaque agent garde la propriété exclusive de ses fichiers. Seul Sonnet 5 maintient à la fois un partage de code élevé et un taux de fusion élevé.

En clair : la capacité de collaboration réelle dépend fortement de la génération du modèle. Et même avec les meilleurs modèles, le résultat de bout en bout reste médiocre. Un système multi-agents a besoin d'une direction humaine, pas seulement d'un prompt bien tourné.

L'échec par conformité : quand tous les agents copient la même erreur

Les agents individuels ont une faible variance : face à la même situation, ils prennent les mêmes décisions, là où les humains divergeraient. Un agent n'a en commun qu'un contexte, un scaffolding et un modèle. Quand ces facteurs se ressemblent, les décisions se ressemblent. Et quand un agent prend une mauvaise décision, beaucoup d'agents prennent la même mauvaise décision : des problèmes isolés deviennent des défaillances systémiques.

L'étude fournit des exemples frappants :

• Dans une version initiale de l'expérience du jeu, 18 des 30 agents ont créé une branche git portant exactement le même nom : « mvp-game-loop ».
• Dans un atelier d'écriture, plusieurs agents, sans aucune consigne de sujet, ont titré leur première nouvelle « The Cartographer's Last Commission ».
• Invités à produire chacun quelque chose d'impressionnant, plus de la moitié des agents ont choisi de construire des ray tracers ou des compilateurs auto-hébergés.
• Dans un dilemme du prisonnier itéré avec communication, tous les agents adoptent la même stratégie et font défection au même moment, ruinant leurs récompenses.

Cette conformité produit des risques concrets. Dans un essai sur des files d'attente à bande passante limitée, les agents ont inondé le système de démons d'interrogation à 30 fois par seconde pour faire passer leurs jobs. Dans une exécution, on a compté 2,4 millions de requêtes pour 117 jobs acceptés.

Pire : les agents entrent facilement en collusion. Dans un jeu de prix à la Bertrand avec trois à huit agents, ceux-ci se sont entendus sur un prix plancher dès le tour 3, via un canal privé : « un prix plancher à 10 pour tous, une guerre des prix brûlerait nos marges ». Même sans communication directe, ils ont continué à s'aligner au centime près sur une place de marché publique. Quand tous les agents font le même pari, un système devient plus vulnérable à un effondrement soudain ou à une pénurie de ressources.

L'échec épistémique : pourquoi les agents croient les mensonges

Les humains appliquent du discernement face à une information nouvelle : cohérence avec ce qu'ils savent déjà, fiabilité historique de la source, intérêts en jeu. Les modèles IA manquent de cette vigilance épistémique et se montrent vulnérables aux émetteurs trompeurs.

Dans une expérience, un agent écouteur devait prendre 10 à 15 décisions à propos d'un monde qu'il ne pouvait pas observer. Quatre éclaireurs lui rapportaient chacun une partie de la vérité, et l'un d'eux mentait à fréquence fixe. Le recoupement des rapports rendait la détection possible en théorie. Les modèles les plus récents récupèrent une part croissante de l'écart entre la stratégie naïve (tout croire) et l'oracle parfait.

Implication pour une entreprise : ne présumez jamais qu'un agent vérifie ses sources. Dans un système multi-agents, un agent peut répéter une information erronée reçue d'un pair sans la remettre en cause. Ajoutez des couches de vérification et des contrôles humains.

Ce que ces échecs changent pour la conformité RGPD

Un système multi-agents traite des données personnelles dès qu'il manipule des dossiers clients, des contrats ou des échanges entre entreprises. Chaque échec technique a alors une traduction réglementaire.

Attribution des actions (Article 5(2) RGPD) : le responsable de traitement doit pouvoir démontrer sa conformité. Dans un essaim, qui répond quand un agent prend une mauvaise décision ? Il faut un journal d'audit par agent : quel agent, quelle action, quelles données, pour quel utilisateur, à quelle heure.

Sous-traitants (Article 28 RGPD) : si les agents s'appuient sur des modèles cloud (Anthropic, OpenAI) ou sur un hébergeur tiers, un contrat de traitement de données (DPA) est obligatoire. C'est une exigence que la CNIL détaille sur son site officiel, en particulier pour les outils d'IA.

Transferts hors UE (Article 44 RGPD) : dès que des données personnelles circulent entre agents puis partent vers un modèle hébergé aux États-Unis, il s'agit d'un transfert international soumis à des garanties. Le CLOUD Act (2018) rend ce risque concret : les autorités américaines peuvent exiger l'accès aux données détenues par des entreprises américaines, même stockées en Europe. Le Foreign Intelligence Surveillance Act (FISA) dessine le même horizon pour la surveillance.

L'alternative souveraine simplifie l'équation : modèles européens ou open weights (Mistral, Llama en self-hosted), base vectorielle Qdrant, stockage OVHcloud ou Scaleway. Pas de transfert hors UE, des DPA limités, et un registre des traitements facile à documenter. C'est la voie que je défends en tant que freelance IA RGPD : l'intégration d'agents IA sur infrastructure européenne, dès le premier pilote.

Comment déployer un système multi-agents robuste et conforme

Voici les bonnes pratiques issues de l'étude d'Anthropic et de l'expérience terrain des déploiements d'agents en entreprise :

• Formalisez un forum central de conventions : l'étude suggère qu'un espace où les agents s'accordent sur les bonnes pratiques et les protocoles est une piste sérieuse contre les échecs de coordination.
• Variez les facteurs de diversité : contextes, scaffolding et modèles différents cassent la conformité de masse. Si tous vos agents partagent le même contexte, ils partageront la même erreur.
• Gardez une supervision humaine et un agent arbitre sur les décisions à enjeu : l'arbitre du test de vulnérabilités (valider chaque trouvaille) est un bon modèle à généraliser.
• Journalisez chaque action de manière attribuable pour satisfaire l'Article 5(2) RGPD.
• Surveillez les signaux de collusion : alignement exact des prix, stratégies unanimes, comportements synchrones. Mettez des quotas et des alarmes.
• Hébergez en UE et signez vos DPA avant toute mise en production, comme le rappelle ce guide sur l'intégration d'un LLM sans violer le RGPD.

L'identité et les permissions de chaque agent restent le préalable de tout déploiement : je le détaille dans l'article Agents IA en entreprise : le vrai frein est la gouvernance.

TL;DR

Les systèmes multi-agents promettent de vrais gains de productivité, mais l'étude d'Anthropic montre que leurs échecs sont prévisibles : coordination faible, fusion ratée du travail collectif, conformité de masse, collusion et crédulité face aux sources trompeuses. Pour une entreprise française ou européenne, ces échecs techniques deviennent des expositions réglementaires sous le RGPD. Les bonnes pratiques existent : forum central, diversité contrôlée, supervision humaine, journal d'audit et hébergement européen.

Vous déployez des agents IA et voulez éviter ces écueils dès l'architecture ? Parlons-en.