#Agentic101 – Comment évaluer et superviser l’IA agentique à l’échelle ?

David Guede a construit l’agent Sharlie : un agent vocal qui fait office de service client pour Sosh. Pour la rentrée, il vous partage son expertise pour une session de rattrapage sur les bases de l’agentification.

La squad des Achats est fière, et elle a de quoi : « L’agent est prêt. On l’a testé sur 50 contrats, il est bon. »

Inès pose alors trois questions :

• Qui a jugé que les réponses étaient bonnes ? L’équipe répond qu’elle les a relues elle-même.
• Que se passera-t-il à la prochaine montée de version du modèle ? La squad hésite, imaginant devoir retester les 50 contrats à la main.
• Et une fois en production, qui verra la dérive avant les utilisateurs ? Silence.

La squad n’a rien fait de mal. Elle a testé, sérieusement et manuellement. Elle vient cependant de découvrir la différence fondamentale entre tester et prouver. Tester est un événement (une action ponctuelle menée sur un échantillon). Prouver est une infrastructure (un système qui rejuge, à chaque évolution, sur tous les cas, sans se fatiguer). Une fabrique qui produit des dizaines de processus ne peut pas vivre d’événements isolés. Cette étape de la chaîne, la preuve, décide si votre organisation inspire confiance ou si elle ne fabrique que des démos.

Définition des critères d’acceptabilité : le rôle exclusif de l’expert métier

Commençons par rendre à l’humain ce qui n’appartient qu’à lui : la définition de ce qui est juste. Aucun dispositif automatique ne sait, de lui-même, ce qu’est une bonne analyse de contrat, une bonne réponse à un client mécontent ou un bon commentaire de reporting. Cette connaissance vit chez les experts métier, et la fabrique la capte à deux moments précis.

En amont d’abord : les critères d’acceptabilité, écrits scénario par scénario, représentent le jugement métier mis en mots avant même la construction. En bout de chaîne ensuite : avant toute mise en production, des experts éprouvent l’agent en conditions réelles (vrais cas, vraies formulations, y compris les plus bancales) et tranchent ce que le critère écrit n’avait pas prévu.

L’humain ne tient cependant pas l’échelle. Relire cinquante contrats manuellement est faisable. Rejouer des centaines de scénarios à chaque évolution de prompt, à chaque montée de version du modèle, et sur des dizaines de processus : c’est impossible. Demander aux experts de porter la preuve dans la durée garantit un échec à court terme.

Industrialisation de la preuve : LLM-as-a-judge et automatisation des tests

C’est ici que la preuve s’industrialise, en s’appuyant sur un matériau de départ existant. Les critères d’acceptabilité deviennent des jeux d’évaluation : les cas courants, les cas limites, et surtout les cas réels et mal formés.

Un client virtuel rejoue les conversations. Les tests de non-régression garantissent que ce qui marchait hier marche encore. Pour les sorties qualitatives (un commentaire, une reformulation), un modèle juge les réponses au regard des critères explicites. Ce procédé, le LLM-as-a-judge, rend évaluable à grande échelle ce qu’on croyait condamné à la relecture humaine.

Il y a une condition non négociable : le juge algorithmique doit être calibré contre le jugement humain. Sans ce calibrage, le juge dérive et automatise une preuve fausse (ce qui est pire qu’une absence de preuve). Le partage des rôles tient en une phrase : l’humain définit le bon, la machine vérifie qu’on y reste.

S’y ajoute une famille de tests souvent oubliée car inconfortable : la sécurité offensive (Red Teaming). Un agent branché au système d’information est une surface d’attaque potentielle (injection d’instructions, détournement, fuite de données). Il faut attaquer son propre agent, méthodiquement, avant que d’autres ne s’en chargent. Ce travail est porté par les profils dédiés de ce tronçon (QA, AI Test Engineer, Quality Analyst) via l’outillage commun du socle. La qualité, elle aussi, vit en hub-and-spoke : le harnais est central, les cas et les jugements restent au métier.

Du déploiement au Run : gouvernance computationnelle et monitoring continu

Cette preuve s’articule en deux temps, qu’il ne faut sous aucun prétexte confondre.

Avant la production, la preuve est un sas. Aucun passage en production n’est autorisé sans un score suffisant, et aucune exception ne se négocie en réunion. C’est la gouvernance computationnelle appliquée à son cas le plus critique. Une fois le sas franchi, le déploiement ne s’effectue jamais d’un coup. Il procède par paliers progressifs, avec une phase de vigilance renforcée pour observer l’agent affronter ses premiers jours de charge réelle.

Après la production, la preuve devient une vigie. Un processus en production n’est jamais figé : les usages dérivent, les données changent, les modèles évoluent. Le juge calibré se mue en sonde continue. Le monitoring suit la qualité des réponses, la latence et les incidents ; l’alerting gradue les sévérités ; le FinOps surveille la seule unité de coût qui compte (non pas le coût au token, mais le coût par tâche correctement résolue). Un agent bon marché qui échoue une fois sur sept est un agent cher, et seule l’évaluation continue sait le révéler.

Ce Run, contrairement à la construction, ne se fédère pas. La raison est prosaïque : on ne fédère pas une astreinte. Une seule équipe de garde, un seul jeu de tableaux de bord, et une seule chaîne d’alerte pour tout le portefeuille sont nécessaires. Les squads restent responsables des corrections, mais le centre est responsable de la détection. Construire se fédère, veiller se centralise.

Amélioration continue : la boucle de feedback vers l’amont

L’aspect le plus élégant de cette architecture réside dans l’exploitation des données. Ce que la vigie observe ne meurt pas dans un tableau de bord. Les demandes hors périmètre, les intentions nouvelles, les usages récurrents qui ressemblent à des doublons, les dérives qui trahissent un besoin mal cadré : tout cela repart vers l’amont pour alimenter la détection continue des besoins.

Le Run n’est pas la fin de la chaîne, il en est le capteur. Une fabrique mûre n’est pas une ligne de production linéaire, c’est une boucle qui apprend. C’est cette boucle, et non un comité d’idéation, qui maintient le portefeuille de projets vivant.

Le curseur des régimes de gouvernance s’applique une dernière fois. À l’externe, tout se resserre : paliers plus prudents, vigilance renforcée plus longue, et chaque évolution verrouillée par la qualité centrale (l’agent parlant au nom de la marque, la preuve précède toujours la parole). À l’interne, la même preuve s’industrialise pour l’échelle : des dizaines de processus ne se valident pas en comité, ils se valident en pipeline. Les agents invisibles du RPA 2.0 cumulent les deux exigences : l’humain n’étant pas présent pour rattraper les erreurs, les seuils de validation montent et des points de contrôle demeurent aux étapes qui engagent l’entreprise.