La thèse en une phrase : monter un système multi-agent en entreprise est à la mode, et c’est presque toujours la mauvaise réponse. Sur LinkedIn, on adore l’essaim : cinq, dix, vingt agents qui se répartissent le travail et se passent les tâches comme une équipe humaine. Ça sonne comme l’avenir. En pratique, un seul agent bien monté —avec de bons outils et un contexte continu— bat presque toujours une armée d’agents qui se refilent la patate chaude. Orchestrer plusieurs agents a son moment, mais c’est l’exception, pas le point de départ.
Le système multi-agent en entreprise : pourquoi il est à la mode (et pourquoi il est presque toujours de trop)
Le multi-agent se vend parce qu’il raconte une jolie histoire : si un agent est intelligent, plusieurs agents coordonnés formeront une équipe imbattable. C’est le même réflexe qui nous fait dessiner des organigrammes —diviser pour régner—. Le problème, c’est que les agents d’IA ne sont pas des personnes, et ce qui dans une équipe humaine est déléguer devient, entre agents, découper le contexte. Chaque agent qu’on ajoute est une copie qui ne voit que sa part du problème et devine le reste. On multiplie les têtes et on multiplie les malentendus.
Ce n’est pas une posture à contre-courant pour le plaisir. Cognition —les gens derrière Devin— l’a titré sans détour dans son ingénierie : ne construisez pas de multi-agents. Leur argument : l’architecture de sous-agents en parallèle est fragile par conception : en isolant le contexte entre agents, ceux-ci prennent des décisions qui se contredisent et le résultat ne colle pas («Don’t Build Multi-Agents», Cognition). Anthropic arrive à la même prudence par un autre chemin : recommande de partir du plus simple qui marche et d’ajouter des agents seulement quand ils apportent une valeur mesurable, et prévient que son propre système multi-agent consommait environ 15× plus de tokens qu’un chat normal pour résoudre le même problème («Building Effective Agents», Anthropic).
Pourquoi un agent bien monté gagne presque toujours
L’alternative ennuyeuse —et presque toujours meilleure— est un seul agent avec un contexte continu et de bons outils. Au lieu de répartir le travail entre cinq têtes qui ne se parlent pas, on en donne une seule tout le contexte et les outils pour faire le boulot de bout en bout. La clé n’est pas combien d’agents on a, c’est ce que celui qu’on a peut toucher. Un agent avec un accès ordonné à tes systèmes —ton CRM, ton e-mail, tes données— résout plus qu’un essaim aveugle. Comment monter cet agent pour qu’il tienne face au vrai travail, on le détaille dans créer un agent IA pour les entreprises, et de quoi dépend sa justesse —l’accès à ton information— dans l’entraîner sur ta propre information.
Le saut de qualité vient rarement d’ajouter des agents ; il vient de donner à celui qu’on a déjà de bons outils. Un agent qui peut interroger ta base de données, ouvrir un ticket ou envoyer un e-mail avec des outils clairs et bien typés fait plus que dix agents qui savent seulement se parler entre eux. C’est justement le changement qu’a apporté le standard de connexion d’outils pour agents, et pourquoi ça compte, on le raconte dans ce qu’est le MCP et pourquoi il change les agents d’entreprise. De bons outils, un agent. Pas vingt agents manchots.
Quand orchestrer plusieurs agents a vraiment du sens
Ce n’est pas un non catégorique au multi-agent. Il y a des cas où séparer le travail entre agents est le bon choix, pas de la frime. La règle est simple : on orchestre plusieurs agents quand le travail peut vraiment se découper en morceaux indépendants qui n’ont pas besoin de se parler à chaque étape.
- Des tâches vraiment parallèles. Quand il faut lancer vingt recherches indépendantes à la fois puis rassembler les résultats, répartir entre agents fait gagner du temps. Le travail se divise proprement et se recompose à la fin ; personne ne dépend du voisin à mi-chemin.
- Des spécialités qui ne partagent pas de contexte. Un agent qui rédige et un autre qui relit avec des critères différents peuvent cohabiter si la frontière entre eux est nette et l’information qu’ils se passent est réduite et claire.
- Isoler pour contenir le risque. Parfois on sépare un agent aux permissions dangereuses —toucher la production, déplacer de l’argent— du reste, précisément pour qu’aucune autre pièce ne puisse déclencher ce que lui seul doit faire sous contrôle.
| Situation | Un agent bien monté | Système multi-agent |
|---|---|---|
| Travail séquentiel à contexte partagé | Gagne : contexte continu, sans pertes | Fragile : les agents se contredisent |
| Tâches parallèles indépendantes | Cale sur l’échelle | Gagne : répartit et recompose |
| Coût et latence | Faible, un seul fil | Élevé : jusqu’à ~15× plus de tokens |
| Débogage en cas d’échec | Traçable, un seul fil | Opaque : quel agent a merdé ? |
La question qui décide de l’architecture (pas la mode LinkedIn)
La décision n’est pas «multi-agent oui ou non» comme un drapeau. C’est «quelle est la forme la plus simple qui résout ce travail». Commence par un agent avec de bons outils. S’il cale sur une échelle réelle —pas une échelle imaginée—, alors, et seulement alors, tu orchestres. La plupart des tâches de bureau —classer, rédiger, rapprocher, répondre— sont largement gérées par un agent bien monté, comme l’agent administratif IA qui vide la boîte de réception sans un comité de bots derrière. Et quand le travail traverse plusieurs systèmes, ce qui décide n’est pas le nombre d’agents : c’est que quelqu’un monte le processus et le tienne, ce que fait justement l’automatisation des opérations.