top of page

Comment évaluer et gouverner un système multi-agents

  • il y a 2 jours
  • 5 min de lecture

Beaucoup d'entreprises qui déploient leurs premiers agents IA appliquent encore, sans y penser, la même grille d'évaluation qu'elles utilisaient pour un modèle de langage.


Cela devient de plus en plus coûteux à mesure que les systèmes se complexifient : évaluer un LLM seul, un pipeline RAG, un agent capable d'agir, ou un système multi-agents orchestrés, ce sont quatre exercices différents, avec quatre grilles de notation différentes. 


Quatre systèmes, quatre grilles d'évaluation


Un LLM seul reçoit un prompt et produit du texte. L'évaluation porte sur ce que le modèle brut sait faire par lui-même : sécurité, capacité de code, respect des instructions. Le juge est le plus souvent un autre modèle (LLM-as-judge) qui note la réponse finale.


Un pipeline RAG ajoute un système de récupération documentaire avant le LLM. L'évaluation se dédouble alors : a-t-on récupéré les bons documents (qualité du retrieval), et la réponse générée est-elle fidèle à ces documents (qualité de la génération) ? Une réponse peut être parfaitement formulée et totalement fausse si le retrieval a échoué en amont, un piège que beaucoup d'organisations ne détectent qu'après coup.


Un agent doté d'outils et d'une boucle d'itération change encore la nature du problème. Les tâches s'exécutent de bout en bout, comme corriger un bug ou planifier une action sur plusieurs étapes. L'évaluation devient alors majoritairement fondée sur le code : on exécute des tests unitaires sur le résultat final produit par l'agent, pas seulement sur son discours.


Un système multi-agents, enfin, introduit plusieurs agents coordonnés par un orchestrateur. Les tâches se déplacent vers la coordination et le respect des rôles assignés. L'évaluation devient hybride : tests fondés sur le code, jugement par un LLM tiers, et revue humaine, souvent les trois à la fois, parce qu'aucune méthode seule ne couvre la totalité de ce qui peut mal se passer.


Chaque nouveau composant ajouté dans un pipeline est un nouvel endroit où quelque chose peut se dérégler, et une nouvelle chose que votre grille d'évaluation doit être capable de détecter. Une organisation qui continue d'évaluer son système multi-agents avec la grille d'un simple LLM ne mesure, au mieux, qu'une fraction infime de ce qui détermine réellement la fiabilité du système en production.


Le risque le plus sournois est une évaluation figée au moment du déploiement initial, jamais rejouée depuis. Un corpus de connaissance évolue, un agent gagne un nouvel outil, un orchestrateur change de règle de routage : chacun de ces changements peut faire dériver la performance mesurée sans que personne ne s'en aperçoive, jusqu'à ce qu'un incident en production révèle l'écart.


Ce que cela signifie pour la gouvernance, pas seulement pour la qualité


Dans notre métamodèle de gouvernance de l'IA agentique, deux attributs dépendent directement de la rigueur de cette évaluation. 


  • Le premier est le score de qualité du retrieval, rattaché à l'entité Corpus de connaissance : c'est la première ligne de défense contre les hallucinations, et c'est un chiffre qui doit être mesuré en continu, pas vérifié une fois lors du déploiement initial. 

  • Le second est l'attribut « validée par », rattaché à chaque décision agentique à haut risque : sans une évaluation capable de détecter qu'une décision sort de la zone de confiance attendue, l'escalade vers un humain nommé n'a aucune chance de se déclencher au bon moment.


C'est là que la question dépasse la simple performance technique pour devenir un sujet de conformité.


L'ISO 42001 exige une revue périodique des systèmes d'IA déployés par une instance de gouvernance ; l'EU AI Act exige, pour les systèmes à haut risque, une supervision humaine effective et une journalisation des décisions.


Une organisation qui ne dispose pas d'une grille d'évaluation adaptée à la complexité réelle de son système multi-agents ne peut tout simplement pas démontrer, de façon crédible, qu'elle respecte ces deux exigences. 


Elle produit de la documentation, pas de la preuve.


À quelle cadence rejouer l'évaluation


Une question revient : à quelle fréquence faut-il rejouer cette évaluation ? La réponse est un principe événementiel. 


Trois signaux devraient déclencher automatiquement une nouvelle évaluation, sans attendre la revue périodique annuelle : 


  1. L'ajout d'un nouvel outil ou d'une nouvelle capacité à l'un des agents de la chaîne, 

  2. Une mise à jour significative du corpus de connaissance sous-jacent, 

  3. Tout changement dans la règle de routage ou d'orchestration entre agents.


Chacun de ces trois événements modifie la surface de risque du système, exactement comme l'ajout d'une nouvelle capacité change le profil de risque d'un agent au sens de l'EU AI Act.


Une organisation qui aligne sa cadence d'évaluation sur ces événements, plutôt que sur un cycle calendaire arbitraire, transforme l'évaluation en un contrôle vivant plutôt qu'en un rituel de conformité déconnecté de la réalité du système.


Un exemple concret, secteur bancaire


Imaginons un système multi-agents de recommandation crédit :


  • un agent de collecte de documents, 

  • un agent d'analyse de dossier, 

  • un agent de scoring, 

  • un agent de décision finale. 


Évalué avec une grille de type LLM seul (est-ce que chaque réponse individuelle est bien formulée), le système peut sembler parfaitement fonctionnel.


Évalué avec une grille adaptée à un système multi-agents (est-ce que l'agent d'analyse a bien récupéré les bons documents, est-ce que l'agent de scoring respecte son périmètre sans empiéter sur celui de l'agent de décision, est-ce que la chaîne complète produit une décision explicable et traçable jusqu'à un consultant humain nommé), le même système peut révéler des failles de coordination invisibles au niveau individuel : un agent qui compense silencieusement l'erreur d'un autre, une décision de crédit qui ne peut pas être reconstituée a posteriori, faute de traçabilité de la chaîne de délégation.


Ce que nous recommandons


Chez Gabriel Greenfield, nous intégrons cette grille d'évaluation à quatre niveaux dès la phase de cadrage de nos missions Meridian, au même titre que le registre des agents et le métamodèle de gouvernance.


Concrètement, cela signifie documenter, pour chaque système déployé, à quel niveau de la pile il se situe (LLM seul, RAG, agent, ou multi-agents), et s'assurer que la méthode d'évaluation choisie correspond réellement à ce niveau, pas à celui qui était pertinent pour le projet précédent.


Cette grille devient elle-même un livrable de nos quality gates entre les phases de déploiement, exactement le type de preuve qu'un auditeur ISO 42001 s'attend à trouver documentée, pas improvisée après coup.


Cette grille se matérialise concrètement par un tableau de bord partagé entre l'équipe technique et l'instance de gouvernance : pour chaque agent du système, le niveau de la pile auquel il appartient, la dernière date d'évaluation, le score de retrieval le plus récent quand un corpus est impliqué, et le taux de décisions escaladées vers un humain rapporté au volume traité.


Ce dernier indicateur mérite une attention particulière : un taux d'escalade qui chute brutalement sans amélioration démontrée du système est aussi suspect qu'un taux qui grimpe sans explication, parce que les deux peuvent signaler un seuil de confiance mal calibré plutôt qu'un système réellement plus fiable.


Gabriel Greenfield est un cabinet spécialisé en transformation IA, gouvernance des données et IA responsable, opérant entre France et Hong Kong.

bottom of page