Les agents LLM sont simplement des systèmes distribués

La communauté IA construit des systèmes multi-agents : des équipes de LLM qui se répartissent le travail, communiquent et collaborent pour résoudre des problèmes qu'aucun modèle seul ne peut gérer. Un agent « chercheur » collecte les informations, un agent « codeur » écrit l'implémentation, un agent « relecteur » vérifie la qualité, et un agent « coordinateur » pilote le workflow. L'argument est séduisant : des agents spécialisés qui collaborent comme une équipe d'ingénierie bien rodée.

Si ça vous semble familier, ce n'est pas un hasard. Les chercheurs en systèmes distribués étudient la coordination de processus indépendants depuis 40 ans. Les systèmes multi-agents LLM redécouvrent, à partir de zéro, des problèmes que la communauté des systèmes distribués a résolus (ou prouvés insolubles) il y a des décennies. Comprendre ces parallèles vous évite de réinventer des solutions, et de construire des systèmes qui tombent en panne de façons prévisibles et bien connues.

Le surcoût de la coordination

La première leçon des systèmes distribués : la coordination a un coût. Deux processus travaillant indépendamment sur des tâches distinctes vont deux fois plus vite qu'un seul. Deux processus travaillant sur la même tâche, et devant se coordonner, sont souvent plus lents qu'un seul, car le surcoût de communication et de synchronisation dépasse le gain de parallélisme.

Les systèmes multi-agents LLM subissent ce phénomène immédiatement. Un agent « chercheur » produit un rapport. L'agent « codeur » doit comprendre ce rapport pour écrire du code. L'agent « relecteur » doit comprendre à la fois le rapport et le code pour donner un retour utile. Chaque passage de relais implique de sérialiser le contexte dans un prompt, que l'agent suivant doit analyser et comprendre. C'est exactement le problème de l'état partagé en systèmes distribués, et il empire à mesure qu'on ajoute des agents.

Single agent vs. multi-agent for a coding task:
Single agent:
1. Understand the problem         (1 LLM call)
2. Research relevant APIs          (2 LLM calls)
3. Write implementation            (1 LLM call)
4. Review and fix                  (1 LLM call)
Total: 5 LLM calls, full context throughout
Multi-agent (researcher + coder + reviewer):
1. Coordinator describes task      (1 LLM call)
2. Researcher reads and plans      (1 LLM call)
3. Researcher does research        (3 LLM calls)
4. Researcher summarizes findings  (1 LLM call)
5. Coder reads summary             (1 LLM call)  ← context lost here
6. Coder writes implementation     (1 LLM call)
7. Reviewer reads code + summary   (1 LLM call)  ← context lost here
8. Reviewer provides feedback      (1 LLM call)
9. Coordinator synthesizes         (1 LLM call)
Total: 11 LLM calls, context degraded at each handoff
More agents = more communication = more cost = worse context.

Dans les systèmes distribués, c'est la loi d'Amdahl appliquée à la communication : le gain du parallélisme est limité par la communication séquentielle qui ne peut pas être parallélisée. Ajouter des agents à une tâche qui exige une coordination serrée rend le système plus lent, pas plus rapide.

Le problème du consensus

Quand plusieurs agents travaillent sur la même tâche, ils doivent se mettre d'accord sur certains points. Quelles sont les exigences ? Quelle approche adopter ? Cette implémentation est-elle correcte ? En systèmes distribués, c'est le problème du consensus, et il est démontrablement difficile : le résultat d'impossibilité FLP montre qu'un consensus déterministe est impossible dans un système asynchrone, même avec un seul processus défaillant.

Les agents LLM sont pires que les processus distribués classiques pour atteindre un consensus, car ils sont non déterministes. Posez deux fois la même question au même agent et vous pourriez obtenir deux réponses différentes. Deux agents relisant le même code peuvent être en désaccord sur sa correction. Un agent « coordinateur » chargé de trancher pourrait bien jouer à pile ou face.

Les frameworks multi-agents gèrent généralement ce point en désignant un agent coordinateur doté de l'autorité finale (un modèle de consensus centralisé, simple, mais qui crée un point de défaillance unique), ou par un vote majoritaire (coûteux : il faut au moins trois agents par décision). Les deux approches fonctionnent, mais elles résolvent un problème qui n'existe que parce que vous avez découpé le travail entre plusieurs agents en premier lieu.

Des modes de panne qui devraient vous sembler familiers

Les systèmes multi-agents tombent en panne de façons que les ingénieurs en systèmes distribués reconnaîtront immédiatement.

• Pannes en cascade. L'agent A produit une mauvaise sortie. L'agent B, qui travaille à partir de la sortie de A, en produit une encore pire. L'agent C, qui relit le travail de B, ne détecte pas l'erreur d'origine car il hérite des mauvaises hypothèses. C'est l'équivalent, en systèmes distribués, de la propagation d'erreurs : garbage in, garbage out, amplifié à chaque étape.
• Interblocages. L'agent A attend la sortie de l'agent B pour avancer. L'agent B attend le retour de l'agent A pour avancer. Aucun ne progresse. En pratique, cela se manifeste par des boucles infinies où les agents se renvoient le travail sans jamais converger.
• Split brain. Deux agents travaillant sur des tâches liées développent des vues incohérentes du problème. L'un suppose que l'API renvoie du JSON ; l'autre suppose du XML. Leurs sorties sont individuellement correctes, mais mutuellement incompatibles.
• Thundering herd. Un agent coordinateur répartit du travail entre plusieurs agents simultanément. Tous frappent la même API, épuisent le même quota de requêtes ou tentent de modifier le même fichier. Une contention de ressources qu'un agent unique ne rencontrerait jamais.

Quand le multi-agent est vraiment utile

Le parallèle avec les systèmes distribués fonctionne dans les deux sens. Ces systèmes apportent des bénéfices réels pour certains problèmes, et les systèmes multi-agents aussi, lorsqu'on les utilise pour des problèmes qui profitent réellement d'une décomposition.

Tâches « embarrassingly parallel ». Si vous devez analyser 50 bases de code à la recherche du même motif, 50 agents travaillant indépendamment sont réellement 50 fois plus rapides. Aucune coordination n'est nécessaire : chaque agent traite une entrée distincte et produit une sortie indépendante. C'est le modèle MapReduce, et il fonctionne aussi bien pour les agents LLM que pour le traitement distribué de données.

Perspectives diversifiées. Demander à trois agents, dotés de prompts système différents, de relire le même code peut faire remonter des problèmes qu'une relecture unique aurait manqués. C'est le modèle de la redondance, comme avoir plusieurs relecteurs sur une PR. Le coût est trois fois plus de calcul, mais la couverture est plus large.

Spécialisation avec des interfaces claires. Un agent de traduction qui prend un texte et renvoie le texte traduit a une interface claire. Un agent de résumé qui prend un document et renvoie un résumé aussi. Les composer (traduire, puis résumer) fonctionne bien parce que l'interface entre les deux est simple. L'équivalent en systèmes distribués : des microservices dotés d'API bien définies fonctionnent mieux que des microservices bavards aux interfaces complexes.

Les leçons des systèmes distribués

Si vous construisez des systèmes multi-agents LLM, des décennies de savoir-faire en systèmes distribués s'appliquent directement.

1. Privilégiez peu d'agents plus capables plutôt que beaucoup d'agents spécialisés. De même qu'un monolithe bien conçu surpasse une architecture de microservices mal conçue, un agent capable doté d'un bon prompting surpasse une équipe d'agents étroits pour la plupart des tâches. N'ajoutez des agents que lorsque vous avez prouvé qu'un agent seul ne peut pas absorber la charge.
2. Définissez des interfaces claires entre les agents. L'entrée et la sortie de chaque agent doivent être bien définies. Les passages de relais vagues (« trouve ce que le chercheur a découvert et implémente-le ») entraînent une perte de contexte et des contresens. Des contrats de données structurés entre agents fonctionnent mieux que du texte libre.
3. Rendez les agents idempotents. Si un agent échoue en cours de route, vous devez pouvoir le relancer avec la même entrée et obtenir un résultat correct. Cela suppose des agents sans état caché et sans effets de bord tant que leur sortie n'a pas été validée.
4. Ajoutez de l'observabilité. Journalisez chaque message inter-agents, chaque décision, chaque échec. Quand un système multi-agents produit une sortie fausse, vous devez pouvoir remonter jusqu'à l'agent qui a pris la mauvaise décision, et comprendre pourquoi. Sans observabilité, le débogage relève de la devinette.
5. Concevez pour les pannes partielles. N'importe quel agent peut échouer, produire n'importe quoi ou expirer. Le système doit gérer cela avec élégance : relancer, revenir à une approche plus simple ou demander à un humain. Ne supposez jamais que tous les agents réussiront.

La vérité qui dérange

La plupart des systèmes multi-agents LLM fonctionneraient mieux sous forme d'un agent unique avec un bon prompt. Le surcoût de coordination, la perte de contexte et les modes de panne des architectures multi-agents l'emportent presque toujours sur les bénéfices pour les tâches qu'un modèle seul peut traiter. À mesure que les outils d'IA évoluent, la tentation de construire des systèmes multi-agents élaborés grandit, mais la leçon des systèmes distribués est claire : ne distribuez pas ce qui n'a pas besoin de l'être.

Les exceptions existent : les tâches embarrassingly parallel, une spécialisation réelle avec des interfaces claires, et les problèmes qui dépassent la fenêtre de contexte d'un modèle unique. Pour le reste, un agent unique doté d'un prompt bien structuré, de bons outils et d'une stratégie de relance réfléchie fera mieux qu'une équipe d'agents. C'est moins excitant d'un point de vue architectural, mais ça marche mieux. Le meilleur système distribué est celui que vous n'avez pas eu à construire.