En bref

Sur 15 déploiements d’orchestration multi-agents et 174 agents lancés en parallèle, nos tests enregistrent un seul incident — classé “partiel”, non “échoué”. Le taux de succès affiché est de 99,4 %. Avant de tirer des conclusions sur la robustesse de ces systèmes, trois questions s’imposent : qui définit le succès ? que mesure-t-on exactement ? et que laisse-t-on de côté ?

Ce que le chiffre 99,4 % dit réellement

Un système d’orchestration multi-agents décompose une tâche complexe en sous-tâches confiées à des agents indépendants qui s’exécutent en parallèle. Dans notre protocole, chaque agent reçoit un périmètre délimité, produit un livrable textuel, et l’orchestrateur consolide les résultats.

Sur 174 exécutions d’agents individuels, 173 ont produit un livrable jugé recevable. Un seul a été marqué “partiel” — l’agent avait rendu un output incomplet mais non vide — et aucun n’a été déclaré en échec. Le taux de 99,4 % est donc un taux de complétion déclarée, pas un taux de qualité.

La distinction est importante : un agent qui génère un texte plausible mais factuellement faux est compté comme succès. Un agent dont l’accès réseau a été bloqué en cours d’exécution — cas observé lors d’un test de collecte — l’est aussi, si son output reste exploitable aux yeux de l’opérateur.

Le biais de déclaration : l’opérateur juge son propre système

Dans nos tests, c’est l’opérateur qui évalue chaque agent : succès, partiel ou échec. Il n’y a pas de juge tiers, pas de critère automatisé appliqué uniformément, pas d’audit indépendant des livrables.

Ce type de biais est bien documenté dans la littérature sur l’évaluation de systèmes automatisés [NON VÉRIFIÉ sur ce contexte précis]. L’opérateur qui a conçu le système est naturellement porté à interpréter les cas ambigus en faveur du succès. Un livrable “suffisant pour la tâche visée” et un livrable “de qualité reproductible” sont deux choses différentes.

Cette dynamique n’est pas propre à nos tests. Dans les benchmarks académiques de LLMs, les auteurs qui définissent et mesurent eux-mêmes le critère de succès obtiennent systématiquement de meilleurs résultats que ceux soumis à évaluation externe — l’écart moyen documenté atteint plusieurs points de pourcentage [NON VÉRIFIÉ]. La rigueur ici consisterait à définir par avance, par écrit, ce qui constitue un échec, puis à s’y tenir même lorsque l’output est “presque bon”.

Dans notre cas : le seul agent PARTIAL a été observé lors d’un test traitant 123 sources. La frontière entre PARTIAL et succès aurait pu être tracée autrement — et le taux global aurait changé. Si deux agents supplémentaires avaient été classés PARTIAL sur l’ensemble des tests, le titre “174 agents, 0 échec” devenait “174 agents, 3 partiels”.

Ce que le log ne mesure pas

Le registre de nos tests capture des métriques de processus : nombre d’agents lancés, statut de complétion, durée approximative. Il ne capture pas :

  • La qualité intrinsèque des outputs. Un agent peut produire un texte structuré, cohérent et erroné. Aucune vérification factuelle systématique n’est incluse dans le suivi.
  • Les hallucinations. Si un agent invente une source, reformule incorrectement un fait ou extrapole au-delà de ses données, cela n’apparaît pas dans les métriques de fiabilité.
  • Les dégradations silencieuses. Un output qui répond à la consigne mais perd 30 % de l’information pertinente est compté comme succès.
  • Les incidents de contexte. Lors d’un test, plusieurs agents ont rencontré un blocage d’accès réseau. L’incident est mentionné dans les notes, pas dans le compteur d’échecs.

Ces angles morts sont structurels : ils résultent du fait que “fiabilité” a été définie comme “l’agent a rendu quelque chose”, pas comme “l’agent a rendu quelque chose de juste”.

Ce qu’une mesure rigoureuse devrait inclure

Les benchmarks existants pour les systèmes agentiques — AgentBench, WebArena, SWE-bench — partagent une caractéristique : ils définissent le succès par un critère externe vérifiable automatiquement. L’agent a-t-il accompli la tâche telle qu’un oracle indépendant peut le constater ? Pas : l’opérateur estime-t-il que l’output est satisfaisant ?

Transposé à l’orchestration multi-agents, cela impliquerait au minimum :

  • Un critère de succès écrit avant l’exécution, non ajusté après coup.
  • Une vérification automatique ou tierce sur un échantillon de livrables (exactitude factuelle, couverture, cohérence interne).
  • Le suivi des dégradations de qualité, même quand l’agent “complète” formellement sa tâche.
  • La traçabilité des incidents non bloquants — accès réseau interrompu, truncation silencieuse, source inaccessible — qui n’apparaissent pas dans le compteur d’échecs mais affectent la qualité finale.

Aucun de ces éléments n’est exotique. Ils représentent la pratique standard de tout test de régression sérieux. Leur absence dans nos métriques actuelles n’invalide pas les résultats observés, mais elle en circonscrit la portée.

Les conditions qui favorisent la réussite

Nos tests ont été conduits dans des conditions contrôlées : tâches bien délimitées, agents à périmètre restreint, livrables textuels sans vérification externe nécessaire. Ce cadre favorise mécaniquement les taux élevés.

Les montées en charge observées — jusqu’à 22 agents en parallèle — n’ont pas produit d’échecs déclarés. Mais elles n’ont pas non plus été testées sur des tâches à fort risque d’erreur : aucun agent n’était responsable d’une décision critique, d’une action irréversible, ou d’une sortie soumise à validation externe indépendante.

La robustesse d’un système d’orchestration dans des environnements moins contrôlés — APIs instables, données ambiguës, critères de succès objectifs — reste une question ouverte que nos chiffres ne permettent pas de trancher.

Un autre facteur à considérer : la sélection des tâches testées. Nos déploiements ont ciblé des cas où l’orchestration multi-agents apporte un gain évident. Les cas difficiles — tâches à forte interdépendance entre agents, livrables nécessitant une cohérence globale, contraintes de temps réel — n’ont pas été inclus dans les tests documentés ici. Le taux de 99,4 % est donc aussi un reflet du périmètre choisi, pas seulement de la robustesse du système.

Ce qu’il faut retenir

  • Le taux de 99,4 % mesure des complétions déclarées par l’opérateur, pas la qualité ou la justesse des outputs produits.
  • Le seul incident classé “partiel” aurait pu être classé “échec” selon une définition plus stricte — le taux global dépend de la frontière choisie.
  • Les hallucinations, dégradations silencieuses et incidents d’accès réseau ne sont pas intégrés dans les métriques de fiabilité.
  • La montée à 22 agents en parallèle sans échec déclaré est un signal positif, mais obtenu sur des tâches à faible risque d’erreur vérifiable.
  • Avant de généraliser ces résultats, il faudrait : un juge tiers, des critères de succès objectifs, et des tests sur des tâches à vérification externe.

Sources