Essaims d'agents IA : pourquoi la multiplication des agents ne produit pas de meilleurs résultats

Depuis deux ans, un consensus s'est installé dans les équipes tech et dans les salles de direction : pour résoudre un problème complexe, on divise le travail entre plusieurs agents IA qui collaborent en parallèle. Des dizaines de startups vendent cette vision. Des conférences entières y sont consacrées. La promesse est intuitive, presque rassurante : si un agent est bien, dix agents sont forcément mieux.

Un développeur travaillant sur OpenAI Codex a contesté ce raisonnement de façon documentée. Son verdict, relayé par The Decoder en 2026 : les essaims d'agents (ou "agent swarms") sont une dépense massive de tokenstokensUn token est l'unité de base de texte que traitent les modèles de langage : le plus souvent un fragment de mot, un mot entier ou un signe de ponctuation, plutôt qu'un simple caractère.Voir la définition complète → sans gain de qualité mesurable.

Ce que défend le consensus, et pourquoi il n'est pas absurde

La thèse des essaims repose sur une analogie avec les organisations humaines. Une équipe de spécialistes produit de meilleurs résultats qu'un généraliste seul. Décomposer une tâche complexe en sous-tâches distribuées à des agents spécialisés semble donc logique. Anthropic, justement, pousse dans cette direction : en septembre 2026, The Decoder signale que Claude Code intègre désormais des workflows d'agents parallèles pour les tâches de codage autonome. Google et l'ONU ont lancé le UN System Data Commons en mobilisant des agents pour rendre accessibles des données globales difficiles à interroger, selon Google (qui commercialise les services sous-jacents, ce que le partenariat ne rend pas toujours visible).

L'argument de performance parallèle a aussi une base réelle. Pour certaines tâches de recherche intensive, distribuer la charge entre agents réduit la latence. Et TechCrunch soulève un problème de surveillance légitime : quand un agent unique agit vite et longtemps sans supervision humaine, les erreurs s'accumulent sans que personne ne les détecte. Multiplier les agents peut, en théorie, introduire des mécanismes de vérification croisée.

Ces arguments méritent d'être pris au sérieux. Ils ne sont pas faux. Ils sont incomplets.

Les angles morts que le consensus préfère ignorer

Le problème central est arithmétique. Chaque agent dans un essaim consomme du contexte : il reçoit des instructions, lit l'état courant de la tâche, produit une sortie, transmet à l'agent suivant. Ce passage de relais génère des tokens à chaque étape. Sur une chaîne de dix agents, le coût total explose sans que la qualité de la sortie finale ne suive. C'est exactement ce que documente l'analyse du développeur de Codex : les tokens brbrLe pourcentage de visiteurs qui repartent après avoir vu une seule page, souvent le signe d'une pertinence insuffisante, d'un décalage d'intention ou d'une expérience utilisateur faible.Voir la définition complète →ûlés en coordination et en répétition de contexte ne produisent aucune amélioration mesurable sur les benchmarks testés.

KDnuggets a publié une étude sur la composition des résultats de recherche ingérés par des agents : en passant d'un format brut à un format Markdown optimisé, la consommation de tokens chute de 74 %. Ce chiffre illustre un principe que les architectures multi-agents violent systématiquement : le tokentokenUn token est l'unité de base de texte que traitent les modèles de langage : le plus souvent un fragment de mot, un mot entier ou un signe de ponctuation, plutôt qu'un simple caractère.Voir la définition complète → le moins cher est celui qu'on ne génère pas. Or un essaim d'agents, par construction, multiplie les échanges intermédiaires.

Il y a un deuxième angle mort, plus discret. La coordination entre agents introduit des points de défaillance que les équipes sous-estiment au moment du déploiement. Pour comprendre ce que signifie fiabiliser un agent unique en production, pensez déjà aux questions de coût, de latence et de reprise sur erreur. Ajouter plusieurs agents en parallèle multiplie ces contraintes sans les résoudre. TechCrunch l'a noté dans un article de 2026 sur la surveillance des agents : les entreprises qui déploient des systèmes multi-agents constatent que les agents agissent à un volume et une vitesse que les équipes humaines ne peuvent pas auditer en temps réel.

Le troisième problème est un biais de narration. Les essaims sont spectaculaires à démontrer. Un agent qui en orchestre neuf autres produit une interface visuelle impressionnante, un diagramme de flux propre à alimenter une présentation investisseurs. Ce n'est pas une raison pour les déployer.

Enfin, l'analogie avec les équipes humaines tient mal à l'examen. Un consultant humain qui passe le dossier à un collègue partage une compréhension implicite du contexte. Deux agents qui se transmettent une tâche doivent réexpliciter ce contexte à chaque transfert, en tokens facturables, avec un risque de dégradation à chaque étape. La mécanique de lacoordination entre agents IA, avec ses orchestrateurs, ses workers et ses handoffs, est coûteuse d'une façon que l'analogie humaine masque.

Ce qu'un opérateur rigoureux devrait faire à la place

La question utile n'est pas "combien d'agents faut-il ?", c'est "est-ce qu'un agent est même le bon outil ici ?". Pour la grande majorité des tâches d'entreprise, la réponse est non. Un workflow déterministe, avec des étapes définies et des sorties prévisibles, résout le problème moins cher, plus vite et avec moins de surface d'erreur.

Quand un agent est justifié, voici les critères qui le distinguent d'un essaim inutile :

• La tâche requiert une vraie adaptation en cours d'exécution, pas seulement une séquence de sous-tâches prévisibles.
• Un agent unique ne peut pas tenir l'ensemble du contexte nécessaire dans sa fenêtre de contexte. Ce n'est pas un problème de volonté ou de configuration : c'est une contrainte physique. Dans ce cas seulement, diviser le travail entre agents a un sens technique.
• Les sous-tâches sont réellement indépendantes et peuvent s'exécuter en parallèle sans se transmettre d'état. Dès qu'elles doivent se passer des informations, le coût de coordination revient.

Pour les équipes qui évaluent des outils comme Codex ou Claude Code,distinguer ce qui relève d'un agent, d'un workflow ou d'une simple automatisation avant de choisir une architecture évite de dépenser des budgets tokens sur une complexité non justifiée.

La tendance aux essaims d'agents survivra probablement encore quelques cycles de conférences, portée par des démos convaincantes et des vendors qui ont intérêt à vendre de la complexité. Le test de réalité est simple : mesurez le coût en tokens de votre architecture multi-agents et comparez-le à un agent unique bien conçu sur la même tâche. Si la qualité est identique et le coût supérieur, vous avez votre réponse. Les équipes qui posent cette question systématiquement en 2026 sont celles qui livrent des systèmes en production, pas des prototypes impressionnants.