Articles connexes : Guide pratique de conception d’agents IA | Les briques fondamentales pour construire un agent | Les 11 patterns d’orchestration multi-agents

Agents mono et multi-agents basés sur des LLM

Version : 1.0 Date : Janvier 2026 Méthodologie : Analyse systématique basée sur publications empiriques (2023-2025)

1. Introduction

1.1 Objectif de l’analyse

Cette analyse identifie, classifie et évalue les patterns liés aux agents IA basés sur des LLM (Large Language Models) qui paraissent prometteurs mais dont la réalisabilité reste structurellement limitée avec les architectures actuelles. L’objectif est de fournir un cadre critique, falsifiable et non spéculatif pour évaluer les capacités réelles des systèmes agentiques.

1.2 Périmètre

Inclus :

• Agents basés sur des LLM (GPT-4, Claude, Llama, etc.)
• Architectures mono-agent et multi-agents
• Systèmes d’orchestration, mémoire, outils et supervision
• Cas observables et reproductibles documentés dans la littérature

Exclu strictement :

• Intelligence Générale Artificielle (AGI) spéculative
• Affirmations marketing sans données empiriques
• Descriptions anthropomorphiques des capacités
• Hypothèses non testables

1.3 Définitions opérationnelles

Agent IA : Système basé sur un LLM capable de percevoir un état, produire du raisonnement local (génération de tokens) et déclencher des actions via une orchestration explicite (code, API, outils).

Système Multi-agents : Ensemble d’agents coordonnés par un protocole explicite. Le multi-agents n’implique aucune intelligence collective émergente par défaut ; toute apparence de coordination supérieure provient de l’orchestrateur ou du protocole de communication.

Scaling : Augmentation des paramètres du modèle, des données d’entraînement ou du compute d’inférence.

1.4 Synthèse des conclusions principales

Constats critiques

1. Le scaling ne résout pas les limitations structurelles : L’augmentation de la taille des modèles améliore la connaissance factuelle et la fluence linguistique, mais ne corrige pas l’absence de planification autonome, de raisonnement causal ou de compréhension logique profonde (Kambhampati et al., 2024; Valmeekam et al., 2025).
2. Les systèmes multi-agents échouent dans 41-87% des cas : L’étude MAST (Cemri et al., 2025) identifie 14 modes d’échec distincts, dont 79% proviennent de problèmes de spécification et de coordination, non de limitations techniques d’infrastructure.
3. L’auto-correction sans feedback externe est illusoire : Les agents ne peuvent pas détecter leurs propres erreurs sans vérificateur externe déterministe (compilateur, test, oracle). L’auto-critique augmente la confiance sans améliorer la précision (Huang et al., 2024; Stechly et al., 2024).
4. Le multi-agent ne surpasse pas le mono-agent sur la majorité des benchmarks : Les gains de performance sont marginaux et souvent inférieurs à des approches simples comme le best-of-N sampling (Kapoor et al., 2024; Wang et al., 2024).
5. Les “capacités émergentes” sont des artefacts métriques : Les sauts qualitatifs apparents lors du scaling résultent de choix de métriques non-linéaires, non de réelles transitions de phase cognitive (Schaeffer et al., 2023).

Patterns viables vs. patterns prématurés

1.5 Recommandations de design

1. Privilégier les boucles fermées : Le succès agentique nécessite un vérificateur externe déterministe (compilateur, simulateur, test automatisé).
2. Limiter le scope par agent : Les agents performants opèrent dans des domaines étroits et bien définis, non en “généralistes”.
3. Traiter le multi-agent comme orchestration, non comme intelligence collective : Le “locus de décision” réel est l’orchestrateur (souvent du code Python), pas les agents eux-mêmes.
4. Assumer 85-90% comme plafond de fiabilité : Pour les derniers 10%, investir dans la supervision humaine plutôt que dans l’augmentation du modèle.
5. Documenter les dépendances cachées : Tout système “autonome” doit expliciter ses dépendances humaines implicites (prompt engineering, sélection de données, validation).

2. TABLEAU SYNTHÉTIQUE DES PATTERNS ANALYSÉS

Légende des catégories

2.1 Patterns de planification et raisonnement

2.2 Patterns multi-agents

2.3 Patterns mémoire et contexte

2.4 Patterns outils et exécution

2.5 Patterns de scaling

3. ANALYSE DÉTAILLÉE DES PATTERNS CRITIQUES

3.1 Pattern : Planification Autonome

Grille d’analyse complète

Publications de référence

• Kambhampati et al. (2024) — “LLMs Can’t Plan, But Can Help Planning in LLM-Modulo Frameworks” — ICML 2024. Démontre formellement que les LLM auto-régressifs ne peuvent pas planifier par eux-mêmes.
• Valmeekam et al. (2023) — Série PlanBench. Montre que les performances de planification s’effondrent avec de simples renommages de variables.
• Stechly et al. (2024) — Analyse de l’échec du backtracking.

3.2 Pattern : Systèmes Multi-Agents avec Débat

Grille d’analyse complète

Publications de référence

• Liang et al. (2023) — Montre que le débat n’améliore que si la solution est déjà dans les données.
• Du et al. (2024) — Social Contagion : l’agent verbeux l’emporte sur l’agent logique.
• Cemri et al. (2025) — MAST Framework : 36.94% des échecs multi-agents sont des problèmes de coordination.
• Gandhi et al. (2024) — Theory of Mind Gap : les agents échouent à modéliser les croyances des autres agents.

3.3 Pattern : Auto-Correction / Self-Refinement

Grille d’analyse complète

Publications de référence

• Huang et al. (2024) — “Self-Correction Fallacy” : sans feedback externe, le modèle valide ses erreurs.
• Madaan et al. (2023) — Self-Refine : succès conditionnel à la qualité du feedback.
• Shinn et al. (2023) — Reflexion : amélioration uniquement avec évaluateur déterministe.
• Liu et al. (2024) — Sycophancy Trap : l’agent change une bonne réponse pour plaire au “critique”.

3.4 Pattern : Capacités Émergentes par Scaling

Grille d’analyse complète

Publications de référence

• Schaeffer et al. (2023) — “Emergence or Metrics?” : démontre que l’émergence apparente résulte de choix métriques.
• Zhu et al. (2025) — Emergence Mirage : les capacités observées sont des optimisations métriques mal interprétées.
• Gudibande et al. (2024) — The Imitation Trap : la distillation copie le style, pas la logique.

3.5 Pattern : Coordination Multi-Agents Autonome

Grille d’analyse complète

Publications de référence

• Cemri et al. (2025) — MAST : 14 modes d’échec identifiés, 36.94% liés à la coordination.
• Zhang et al. (2025) — Orchestrator Bottleneck : 90% du succès dépend de l’orchestrateur central.
• Nguyen et al. (2024) — Self-Organizing Fallacy : l’auto-organisation mène au chaos sans script.

4. SYNTHÈSE TRANSVERSALE DES LIMITATIONS

4.1 Limitations structurelles (inhérentes aux LLM)

Ces limitations découlent directement de l’architecture des modèles de langage auto-régressifs et ne peuvent être résolues par scaling ou prompt engineering.

4.1.1 Absence de World Model

4.1.2 Raisonnement comme Pattern-Matching

4.1.3 Temps Constant par Token

4.1.4 Reversal Curse

4.2 Limitations systémiques (inhérentes aux architectures agentiques)

4.2.1 Cascade d’erreurs

4.2.2 Dilution de responsabilité

4.2.3 Homogénéité des erreurs

4.2.4 Coût exponentiel

4.3 Tableau récapitulatif : Mur de verre du scaling

5. LISTE DES ILLUSIONS RÉCURRENTES

Cette section recense les patterns qui sont régulièrement présentés comme des capacités acquises mais qui sont, à l’analyse, des illusions ou des surinterprétations.

5.1 Illusion : L’agent “comprend” la tâche

5.2 Illusion : Le multi-agent est plus intelligent qu’un mono-agent

5.3 Illusion : L’agent apprend de ses erreurs

5.4 Illusion : Le débat améliore la précision

5.5 Illusion : Les capacités émergent avec le scaling

5.6 Illusion : L’agent est autonome

5.7 Illusion : Le RAG “comprend” les documents

5.8 Illusion : L’agent planifie

6. PRINCIPES DE DESIGN RÉALISTES

6.1 Principe 1 : Boucle fermée obligatoire

Un agent ne peut améliorer sa performance que si un vérificateur externe et déterministe fournit un feedback exploitable.

Implémentation :

• Toujours coupler l’agent avec un compilateur, un interpréteur, un test automatisé ou un simulateur.
• Le feedback doit être binaire (succès/échec) ou contenir une information d’erreur structurée.
• Ne jamais compter sur l’auto-évaluation de l’agent.

Exemples viables :

• Code + Tests unitaires automatisés
• SQL + Validation de schéma
• Robot + Simulateur physique

6.2 Principe 2 : Scope limité et explicite

Chaque agent doit opérer dans un domaine étroit, bien défini, où ses patterns sont surreprésentés dans les données d’entraînement.

Implémentation :

• Définir explicitement les limites du domaine d’action.
• Refuser les tâches hors domaine plutôt que de tenter une généralisation.
• Utiliser plusieurs agents spécialisés plutôt qu’un agent “généraliste”.

Anti-pattern à éviter :

• “Agent universel” qui fait tout
• Prompt vague du type “Résous ce problème”

6.3 Principe 3 : Orchestration explicite

Dans un système multi-agents, toute la logique de coordination doit être dans l’orchestrateur (code), pas dans les prompts.

Implémentation :

• Le flux de travail est défini en code (Python, etc.), pas en langage naturel.
• Les transitions entre états sont déterministes.
• Les agents sont des “fonctions” appelées par l’orchestrateur, pas des entités autonomes.

Corollaire :

• Le “multi-agent” est souvent un workflow déguisé. Assumer cette réalité plutôt que de la masquer.

6.4 Principe 4 : Supervision humaine au-delà de 85%

Pour atteindre une fiabilité supérieure à 85-90%, investir dans la supervision humaine, pas dans l’augmentation du modèle.

Implémentation :

• Définir des checkpoints où un humain valide les décisions critiques.
• Prévoir un mode “escalade” vers un opérateur humain.
• Mesurer le vrai coût (humain + compute) et non juste le coût API.

Réalité économique :

• Le coût de la supervision humaine pour les derniers 10% est souvent inférieur au coût d’une architecture complexe qui échoue de manière imprévisible.

6.5 Principe 5 : Documentation des dépendances cachées

Tout système présenté comme “autonome” doit expliciter ses dépendances humaines implicites.

Checklist obligatoire :

• Qui a écrit et optimisé les prompts ?
• Qui sélectionne les exemples few-shot ?
• Qui valide les résultats en démo ?
• Quels cas d’échec sont filtrés des métriques ?
• Quelle intervention humaine est nécessaire en production ?

6.6 Principe 6 : Métriques réalistes

Mesurer la performance en conditions réelles, pas sur des benchmarks contaminés.

Implémentation :

• Utiliser des données de test vraiment inédites (post-training cutoff).
• Inclure les coûts (tokens, latence, supervision humaine) dans les métriques.
• Mesurer la robustesse aux perturbations, pas juste la performance nominale.

Métriques à éviter :

• Accuracy sur benchmark public (contamination)
• “Success rate” sans définition du succès
• Comparaisons cherry-picked

6.7 Tableau récapitulatif : Ce qui fonctionne vs. Ce qui ne fonctionne pas

7. CORPUS BIBLIOGRAPHIQUE DE RÉFÉRENCE

7.1 Publications clés (Top 20)

7.2 Classification détaillée des sources

Catégorie A : Capacité démontrée et robuste

Catégorie B : Capacité conditionnelle / fragile

Catégorie C : Limitation structurelle identifiée

Catégorie D : Échec documenté

Catégorie E : Promesse prématurée / surinterprétation

7.3 Mapping publications ↔ patterns

7.4 Zones sans preuves identifiées

Les domaines suivants manquent de preuves empiriques robustes malgré des affirmations fréquentes :

8. ANNEXES

8.1 Checklist d’évaluation de pattern

Pour tout pattern agentique présenté, appliquer cette checklist :

□ 1. Le pattern reste-t-il valide si le prompt est réduit à l'essentiel ?
□ 2. Fonctionne-t-il sans intervention humaine implicite ?
□ 3. Résiste-t-il à du bruit ou de l'ambiguïté dans l'entrée ?
□ 4. Tient-il dans la durée (au-delà d'une session courte) ?
□ 5. Reste-t-il valide lorsque plusieurs instances du même modèle interagissent ?
□ 6. Les résultats sont-ils reproductibles avec d'autres modèles de même classe ?
□ 7. Le benchmark utilisé est-il exempt de contamination ?
□ 8. Les métriques capturent-elles le succès réel de la tâche ?
□ 9. Le coût total (tokens, latence, supervision) est-il viable ?
□ 10. Les dépendances humaines sont-elles explicitement documentées ?

VERDICT :
- 10/10 → Capacité démontrée robuste (rare)
- 7-9/10 → Capacité conditionnelle (documenter les conditions)
- 4-6/10 → Pattern fragile (ne pas promettre en production)
- 0-3/10 → Illusion ou promesse prématurée

8.2 Glossaire technique

8.3 Références bibliographiques complètes

Publications académiques

1. Kambhampati, S., Valmeekam, K., Guan, L., et al. (2024). “LLMs Can’t Plan, But Can Help Planning in LLM-Modulo Frameworks.” Proceedings of ICML 2024, 235
   .
2. Cemri, M., Pan, M. Z., Yang, S., et al. (2025). “Why Do Multi-Agent LLM Systems Fail?” arXiv
   .13657.
3. Valmeekam, K., Marquez, M., Sreedharan, S., & Kambhampati, S. (2023). “On the Planning Abilities of Large Language Models—A Critical Investigation.” NeurIPS 2023.
4. Schaeffer, R., Miranda, B., & Koyejo, S. (2023). “Are Emergent Abilities of Large Language Models a Mirage?” NeurIPS 2023.
5. Huang, J., Shao, Z., et al. (2024). “Large Language Models Cannot Self-Correct Reasoning Yet.” ICLR 2024.
6. Dziri, N., Lu, X., Sclar, M., et al. (2023). “Faith and Fate: Limits of Transformers on Compositionality.” NeurIPS 2023.
7. Madaan, A., Tandon, N., et al. (2023). “Self-Refine: Iterative Refinement with Self-Feedback.” NeurIPS 2023.
8. Shinn, N., Cassano, F., et al. (2023). “Reflexion: Language Agents with Verbal Reinforcement Learning.” NeurIPS 2023.
9. Yao, S., Zhao, J., et al. (2023). “ReAct: Synergizing Reasoning and Acting in Language Models.” ICLR 2023.
10. Park, J. S., O’Brien, J., et al. (2023). “Generative Agents: Interactive Simulacra of Human Behavior.” UIST 2023.
11. Liang, T., He, Z., et al. (2023). “Encouraging Divergent Thinking in Large Language Models through Multi-Agent Debate.” arXiv
    .19118.
12. Gandhi, K., et al. (2024). “Understanding Social Reasoning in Language Models with Language Models.” NeurIPS 2024.
13. Liu, N. F., Lin, K., et al. (2023). “Lost in the Middle: How Language Models Use Long Contexts.” TACL 2024.
14. Greshake, K., et al. (2024). “Not What You’ve Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection.” AISec 2023.
15. Stechly, K., Marquez, M., & Kambhampati, S. (2024). “GPT-4 Doesn’t Know It’s Wrong: An Analysis of Iterative Prompting for Reasoning Problems.” NeurIPS FM4DM Workshop.

9. CONCLUSION

Cette méta-analyse établit un cadre critique pour évaluer les capacités réelles des agents IA basés sur des LLM. Les constats principaux sont :

1. Les limitations sont structurelles, pas conjoncturelles : L’architecture auto-régressive des LLM impose des plafonds de performance que le scaling seul ne peut dépasser.
2. Le multi-agent n’est pas une solution aux limitations du mono-agent : Les systèmes multi-agents héritent des limitations de leurs composants et ajoutent des modes d’échec propres (coordination, cascade d’erreurs).
3. L’autonomie est une illusion soigneusement entretenue : Les systèmes “autonomes” dépendent de prompts optimisés, d’orchestrateurs codés et de supervision humaine implicite.
4. Les succès réels sont dans les domaines à feedback déterministe : Code avec tests, SQL avec validation, robotique avec simulateur — les boucles fermées fonctionnent.
5. La fiabilité au-delà de 85-90% nécessite l’humain : Pour les cas critiques, la supervision humaine reste plus efficace et économique que l’augmentation architecturale.

Cette analyse ne vise pas à décourager le développement d’agents IA, mais à établir des attentes réalistes et des principes de design robustes. Les agents IA sont des outils puissants lorsqu’ils sont utilisés dans leurs domaines de validité, avec une conscience claire de leurs limitations.

Pour aller plus loin

• Guide de Conception d’Agents IA : Ce qui Fonctionne, Ce qui Échoue — Synthèse pratique avec arbres de décision et matrices d’évaluation
• Construire un Agent : L’Art d’Assembler les Bonnes Briques — Langages, orchestration, modèles, télémétrie, storage et runtime
• Les 11 Patterns d’Orchestration Multi-Agents — Pipeline, Supervisor, Swarm, Council : guide pratique avec cas d’usage
• Agent Skills : Le Manuel d’Onboarding — Structurer les instructions pour des agents spécialisés

Fin du document