En bref

Quand on construit un système avec plusieurs agents LLM, l’instinct est de vouloir le meilleur modèle possible. Choisir GPT-4o plutôt que GPT-4o-mini, Opus plutôt que Sonnet. Plus puissant = plus fiable, non ?

Les données disent le contraire. Ce qui détermine la fiabilité d’un système multi-agents, ce n’est pas le modèle utilisé — c’est la façon dont les agents sont organisés, coordonnés et contraints. L’architecture d’abord. Le modèle, ensuite.

Explication

Ce qu’on entend par “architecture”

Un système multi-agents, c’est plusieurs LLM qui travaillent ensemble : l’un décompose une tâche, d’autres l’exécutent en parallèle, un dernier consolide les résultats. Chaque agent a un rôle, des outils, un scope limité.

L‘“architecture” désigne ici l’ensemble des décisions structurelles : comment les agents se partagent le travail, comment ils communiquent, dans quel ordre ils s’exécutent, comment les erreurs sont gérées et signalées. Ce n’est pas le code du modèle — c’est la façon dont les pièces s’assemblent.

Pourquoi l’architecture domine

Un LLM plus puissant génère du texte plus précis. Mais un système multi-agents échoue rarement à cause d’un token mal prédit. Il échoue parce qu’un agent reçoit un contexte tronqué, parce qu’une dépendance entre tâches n’est pas respectée, parce qu’un résultat intermédiaire mal formaté casse la chaîne suivante, parce que deux agents écrivent dans le même fichier sans coordination.

Ces défaillances sont structurelles. Elles ne disparaissent pas en passant au modèle d’au-dessus.

La recherche MAESTRO (arXiv 2601.00481) l’a mesuré empiriquement sur 12 systèmes multi-agents : l’architecture du système est le facteur dominant pour la reproductibilité, le coût et la précision — devant le choix du modèle. Les expériences montrent que les performances varient significativement d’un run à l’autre sur le même système, et que cette variance s’explique par les choix structurels, pas par les capacités brutes du modèle.

Le paradoxe des gains de capacité

Princeton University a publié en février 2026 une étude évaluant 14 modèles sur deux benchmarks avec 12 métriques de fiabilité (consistance, robustesse, prédictibilité, sécurité). Résultat : les gains récents de capacité n’ont produit que de faibles améliorations de fiabilité (“Towards a Science of AI Agent Reliability”, arXiv 2602.16666).

Dit autrement : les modèles deviennent plus capables, mais pas proportionnellement plus fiables. La fiabilité dépend d’autre chose — et cet “autre chose”, c’est l’architecture.

La racine des pannes

Une troisième étude, “Characterizing Faults in Agentic AI” (arXiv 2603.06847), a analysé 13 602 issues et pull requests sur des systèmes agentiques réels. Sa conclusion : la majorité des défaillances vient d’un mismatch entre des sorties générées probabilistiquement et des contraintes d’interface déterministes.

En clair : le modèle génère du texte probabiliste (il ne produit jamais deux fois exactement le même output), mais le reste du système attend des entrées déterministes (un JSON valide, un nom de fichier exact, une réponse dans un format précis). Quand l’interface entre les deux est mal conçue, le système casse. Régulièrement. Et un modèle plus puissant ne résout pas ce problème — une architecture avec des validations et des contrats clairs, si.

Dispatch par type cognitif, pas par modèle

Une conséquence pratique de ce principe : il vaut mieux choisir un modèle en fonction de ce qu’un agent doit faire cognitivement, pas en fonction du nombre de fichiers qu’il doit lire ou de la “complexité” perçue de la tâche.

Nos tests montrent que le facteur discriminant entre modèles n’est pas quantitatif. Ce n’est pas “beaucoup de données → grand modèle”. C’est : “extraction mécanique → modèle léger suffit”, “jugement critique, nuance, détection de contradictions → modèle plus analytique requis”. Un agent chargé de lister des faits dans un document n’a pas besoin du même modèle qu’un agent chargé de concevoir un protocole d’expérience.

Exemples concrets

Sonnet ≈ Opus sur les tâches analytiques

Nos tests (30 runs comparatifs, 10 tâches de difficulté croissante) n’ont détecté aucune différence de qualité observable entre Sonnet et Opus sur des tâches analytiques : extraction, résumé, comparaison de sources, détection de contradictions, conception de protocole. Sur la tâche la plus complexe, Opus a utilisé 3 fois plus d’appels d’outils que Sonnet (15 vs 5), a pris 42% plus de temps (195s vs 138s), et a produit un livrable de qualité non significativement différente.

Ce n’est pas une critique d’Opus — c’est une confirmation que sur cette gamme de tâches analytiques, le facteur limitant n’est pas la capacité du modèle. C’est la qualité du prompt, la clarté du scope, la structure des données d’entrée.

Haiku tient plus loin qu’attendu

Sur les tâches d’extraction et de résumé (T1 à T5 dans nos tests), Haiku produit des résultats exploitables à 100%. Il continue à produire des résultats exploitables — mais minimaux — jusqu’à la tâche la plus difficile (T10, conception de protocole sur 5 fichiers). Le seuil n’est pas là où on l’attendait.

La différence entre Haiku et Sonnet n’est pas “fonctionne / ne fonctionne pas”. C’est un gradient de profondeur : Haiku est correct et minimal, Sonnet est correct et nuancé. Pour un agent de collecte de données, Haiku suffit. Pour un agent chargé d’identifier des tensions méthodologiques, il ne suffit plus.

Mistral 7B : la limite n’était pas la capacité

Dans un test comparatif de recherche documentaire, Mistral 7B local (via Ollama) a obtenu 64% de couverture contre 100% pour Sonnet et Opus. Ce n’est pas l’écart le plus révélateur. Le plus révélateur : Mistral a ignoré les contraintes de format dans 2 cas sur 3 (sections attendues, structure markdown). Les outputs étaient inutilisables non pas parce que le modèle était “moins intelligent”, mais parce qu’il ne suivait pas les instructions structurelles.

Le problème principal n’était pas la qualité factuelle — c’était le suivi d’instructions. Une contrainte architecturale (valider le format de sortie avant de passer au prochain agent) aurait détecté l’échec immédiatement.

12 agents parallèles sans dégradation

Nos tests montrent que 12 agents Sonnet peuvent s’exécuter en parallèle sans rate limit ni dégradation de qualité (16 secondes au total). Ce n’est pas trivial : cela signifie qu’un système bien architecturé peut paralléliser massivement sans avoir besoin de modèles plus puissants. La performance vient de l’architecture de dispatch, pas du modèle individuel.

Ce qu’il faut retenir

  • L’architecture détermine la fiabilité, pas le modèle. Trois équipes de recherche indépendantes (MAESTRO, Princeton, Berkeley/CMU) arrivent à la même conclusion par des méthodes différentes. Nos propres observations vont dans le même sens.
  • Choisir un modèle plus puissant ne corrige pas un problème architectural. Si des agents reçoivent des contextes mal formés, si les dépendances entre tâches ne sont pas respectées, si les erreurs ne sont pas détectées et signalées — un meilleur modèle ne change rien à cela.
  • Le dispatch par type cognitif est plus efficace que le dispatch par “complexité”. La question n’est pas “ce fichier est-il grand ?” mais “cet agent doit-il exercer un jugement critique ?”. Extraction mécanique → modèle léger. Analyse nuancée → modèle analytique. Le reste est sur-ingénierie.
  • Les économies de coût sont réelles et immédiates. Sur des tâches analytiques courantes, Sonnet produit la même qualité qu’Opus à moindre coût. Haiku suffit pour l’extraction. Les économies de compute ne viennent pas du modèle choisi — elles viennent de la précision du dispatch.

Sources

  • MAESTRO : Multi-Agent Evaluation Suite for Testing, Reliability, and Observability Zhao et al., arXiv 2601.00481, janvier 2026. https://arxiv.org/abs/2601.00481

  • Towards a Science of AI Agent Reliability Rabanser, Kapoor et al., Princeton University, arXiv 2602.16666, février 2026. https://arxiv.org/abs/2602.16666

  • Characterizing Faults in Agentic AI arXiv 2603.06847, mars 2026.

  • Nos observations internes : 30 runs comparatifs Haiku / Sonnet / Opus sur tâches analytiques, et tests de recherche documentaire Sonnet / Opus / Mistral 7B (mars 2026).