Le défi de l'évaluation des agents IA en production
Les systèmes AIOps (Artificial Intelligence for IT Operations) reposent de plus en plus sur des agents IA autonomes pour monitorer, diagnostiquer et résoudre les incidents IT. Avec l'émergence du Model Context Protocol (MCP), ces agents peuvent maintenant accéder à des contextes riches et exécuter des actions complexes.
Cette autonomie croissante soulève des questions critiques de gouvernance et de fiabilité. Comment s'assurer que ces agents fonctionnent correctement ? Comment mesurer leur performance, détecter les régressions et garantir qu'ils ne commettent pas d'erreurs critiques en production ?
C'est là qu'interviennent les AI Evaluations (Evals) : des frameworks rigoureux pour tester, mesurer et améliorer continuellement les agents IA. Cet article partage la méthodologie complète qu'Adservio a développée pour les agents IA en contexte AIOps, particulièrement ceux utilisant MCP.
Qu'est-ce que le Model Context Protocol (MCP) ?
Model Context Protocol (MCP) est un standard ouvert qui permet aux agents IA d'accéder à des contextes riches et d'interagir avec des systèmes externes de manière standardisée. Développé par Anthropic, MCP résout un problème fondamental : comment donner aux LLM accès aux données et outils dont ils ont besoin pour être utiles en production ?
MCP repose sur quatre composants : des Context Servers, qui exposent des données issues de multiples sources (bases de données, API, systèmes de fichiers) dans un format unifié et interrogeable ; un protocole standardisé, qui évite les adaptateurs spécifiques à chaque source ; un mécanisme sécurisé d'exécution d'outils, qui permet d'agir au-delà de la simple lecture ; et une couche de sécurité offrant contrôles d'accès granulaires, authentification et audit complet.
Dans un contexte opérationnel réel, un agent AIOps utilisant MCP peut orchestrer l'ensemble du cycle de vie d'un incident : interroger les logs via un Context Server Elasticsearch pour identifier les patterns d'erreurs, corréler les anomalies avec les métriques Prometheus, consulter la CMDB pour comprendre les dépendances, puis exécuter des actions de remédiation via des Tools MCP (redémarrage, scaling, rollback).
Le problème : avec un tel pouvoir, accès aux systèmes critiques et capacité d'action, comment s'assurer que l'agent ne commet pas d'erreurs catastrophiques ?
Pourquoi les évaluations classiques ne suffisent pas
Les approches traditionnelles de testing logiciel sont inadéquates pour les agents IA, et ce pour trois raisons structurelles.
Les tests unitaires supposent le déterminisme : or un LLM peut générer des outputs différents pour un même input, ce qui invalide le paradigme « fonction(X) doit retourner Y ». Les tests d'intégration supposent des scénarios énumérables : or les agents IA ont des comportements émergents dans un espace d'états quasi infini, ce qui impose une couverture par distributions statistiques plutôt que par cas isolés. Enfin, le monitoring de production classique mesure l'uptime et la latence, pas la qualité des décisions : un agent peut afficher 99,9 % de disponibilité tout en prenant de mauvaises décisions 30 % du temps.
Cinq exigences s'imposent donc : évaluer la qualité sémantique et factuelle des réponses, tester sur des distributions statistiques d'inputs, mesurer la robustesse et la dégradation gracieuse, détecter hallucinations et dérives comportementales, et garantir l'alignement continu avec les objectifs métier et les contraintes réglementaires.
Framework d'évaluation pour agents IA AIOps
Chez Adservio, nous utilisons un framework d'évaluation en 5 dimensions qui s'inspire des meilleures pratiques de l'industrie tout en intégrant les spécificités du contexte AIOps.
Dimension 1 : correction fonctionnelle
L'agent accomplit-il la tâche demandée correctement ? L'évaluation repose sur des golden datasets : des corpus de référence annotés par des experts métier, associant des inputs réels à des outputs attendus. Par exemple, une alerte « High CPU usage on prod-web-01 » avec son contexte (CPU à 95 %, déploiement récent d'api-service v2.3.1) est associée à un diagnostic attendu pointant ce déploiement comme cause probable, avec des actions recommandées : vérifier les logs, revoir les changements, envisager un rollback.
Le scoring automatique compare ensuite l'output de l'agent au golden output selon trois métriques : l'exact match (trop strict pour les LLM, réservé aux formats structurés), la similarité sémantique (cosinus d'embeddings) et le component match (présence des éléments business-critiques). Les seuils typiques : similarité de diagnostic supérieure à 0,85, rappel des actions supérieur à 0,70 et score global supérieur à 0,75, réévalués à chaque changement de modèle ou de prompt.
Dimension 2 : sécurité et guardrails
L'agent évite-t-il les actions dangereuses ? Trois catégories de tests structurent cette dimension. Les actions interdites d'abord : l'agent ne doit jamais exécuter certaines commandes (rm -rf /, DROP DATABASE, désactivation des firewalls), même quand le scénario semble les justifier, face à des logs qui saturent le disque, il doit recommander une rotation, jamais une suppression brutale. L'escalade appropriée ensuite : pour les situations critiques ou ambiguës, déléguer à un humain plutôt qu'agir seul. Le respect des politiques enfin : pas de redémarrage en heures de pointe, pas de changement sans ticket ITSM, en cohérence avec les frameworks de gouvernance des clients (ITIL, COBIT).
Les métriques associées visent un taux d'action interdite de 0 %, un taux d'escalade inutile inférieur à 5 % et un taux d'escalade manquante de 0 %. En complément, un red team dédié tente activement de faire dérailler l'agent (prompt injection, manipulation contextuelle, cas ambigus) pour découvrir les failure modes non anticipés, chez Adservio, un exercice trimestriel avec rotation d'équipes.
Dimension 3 : utilisation du contexte
L'agent exploite-t-il efficacement les contextes MCP disponibles ? Trois aspects sont évalués. La précision de récupération : ne récupérer que les données pertinentes, face à un pic de latence sur l'API /users, interroger les logs et métriques de l'API et les métriques de la base de données, pas les logs frontend ni le serveur mail, avec une précision attendue supérieure à 0,8 et un rappel supérieur à 0,9. L'intégration de contexte : combiner intelligemment plusieurs sources, relier un pic CPU à 14 h 32, un déploiement démarré à 14 h 30 et l'entrée CMDB identifiant api-service v2.1, pour formuler l'hypothèse causale. L'optimisation des requêtes : minimiser le nombre de queries tout en maintenant la qualité du diagnostic.
Les métriques : précision et rappel de contexte, nombre moyen de requêtes par incident résolu, et score humain sur la qualité de la synthèse multi-contextes.
Dimension 4 : latence et performance
L'agent répond-il assez vite pour être utile en production, où chaque seconde compte pour le MTTR ? La latence de bout en bout se mesure en distribution complète (P50, P95, P99) pour capturer les comportements de queue, et se décompose en quatre postes : inférence LLM, récupération de contexte, exécution d'outils et overhead système. Un diagnostic type se profile ainsi : environ 1,2 seconde de récupération de contexte, 3,5 secondes d'inférence LLM et 0,8 seconde d'exécution d'outils lorsqu'une action est nécessaire.
Les optimisations courantes suivent une hiérarchie d'impact mesurable : caching des contextes fréquemment accédés (40 à 60 % d'appels MCP en moins), récupération parallèle de plusieurs contextes (30 à 50 % de latence totale en moins), streaming des réponses pour la réactivité perçue, et modèles rapides pour le triage en réservant les modèles de raisonnement aux analyses profondes. S'y ajoute l'efficience économique : minimiser le coût par incident résolu (appels LLM, requêtes MCP, infrastructure) sans sacrifier la qualité.
Dimension 5 : robustesse et fiabilité
L'agent reste-t-il performant face à l'inattendu ? Quatre familles de tests couvrent cette dimension. Les inputs adversariaux : alerte vide, alerte de dizaines de milliers de caractères, alerte vague (« Help!!! EVERYTHING IS DOWN ») ou contradictoire, l'agent ne doit jamais planter, mais demander une clarification ou décliner gracieusement. Le contexte manquant : si le context server de logs tombe, l'agent doit signaler explicitement l'absence de cette source, poursuivre son diagnostic avec les données disponibles et abaisser son niveau de confiance, typiquement sous 0,7. Le distribution shift : mesurer la dégradation sur un dataset out-of-distribution représentatif de scénarios émergents, avec un objectif inférieur à 20 %. La stabilité temporelle enfin : une évaluation hebdomadaire sur le golden dataset fixe, avec alerte dès que le score chute sous 90 % de la référence.
Les métriques cibles : plus de 95 % d'inputs adversariaux gérés correctement, un score de dégradation gracieuse supérieur à 0,7 et une rétention de performance hors distribution supérieure à 0,8.
Pipeline d'évaluation continue
L'évaluation n'est pas un événement ponctuel mais un processus continu intégré dans le cycle de développement et de déploiement : tout changement de code, de prompt ou de modèle déclenche automatiquement la suite d'évaluation (tests fonctionnels, de sécurité et de performance), dont les résultats agrégés (score global, scores par dimension, détection de régressions) décident du passage en staging ou du blocage du déploiement avec alerte à l'équipe.
Le rythme suit une progression de granularité alignée sur les cycles de développement : smoke tests en pre-commit (moins d'une minute, tests critiques uniquement), suite complète en pre-merge (10 à 15 minutes), évaluation étendue et tests adversariaux chaque nuit (1 à 2 heures), évaluation humaine et exercices red team chaque semaine, monitoring continu et échantillonnage d'interactions en production.
Les critères de gate définissent les seuils infranchissables pour autoriser un déploiement : un score fonctionnel global d'au moins 0,75 sans aucune régression ; un taux d'action interdite strictement nul et un taux d'escalade manquante inférieur à 5 % côté sécurité ; une latence P95 inférieure à 120 secondes et un coût par incident inférieur à 0,50 $ côté performance ; un taux de succès adversarial supérieur à 95 % et une rétention hors distribution supérieure à 80 % côté robustesse. Si l'une de ces gates échoue, le déploiement est bloqué automatiquement.
Outils et frameworks pour AI Evals
L'écosystème d'outils d'évaluation d'IA a considérablement mûri. Quatre familles se distinguent : OpenAI Evals, librairie extensible de référence pour créer et exécuter des évaluations LLM multi-modèles avec des scorers personnalisés ; LangSmith (LangChain), plateforme de testing et de monitoring avec tracing de bout en bout, datasets versionnés et A/B testing de prompts ; PromptFoo, framework de testing de prompts data-driven avec CLI et intégration CI/CD native ; et les frameworks internes, indispensables pour les métriques AIOps-native profondément intégrées à l'infrastructure existante (MCP, stack d'observabilité).
La stack type chez Adservio combine ces briques dans une stratégie hybride : l'orchestration des évaluations est pilotée par Airflow, qui exécute des évaluations OpenAI Evals et des évaluations internes personnalisées, stocke les résultats dans PostgreSQL et les expose dans des tableaux de bord Grafana pour un suivi continu.
Cas d'étude : Évaluation d'un agent de diagnostic d'incidents
Un client exploitait un agent IA de diagnostic automatique d'incidents de production critiques, utilisant MCP pour accéder aux logs (Elasticsearch), aux métriques (Prometheus), à la CMDB et aux runbooks (Confluence). Objectif business : diagnostiquer plus de 70 % des incidents sans intervention humaine pour réduire le MTTR de 35 %.
Le golden dataset a demandé trois mois de collecte et d'annotation par les équipes SRE : 500 incidents réels anonymisés des 12 derniers mois, chacun annoté avec sa root cause validée en double par un SRE senior et les actions de remédiation qui ont fonctionné ; un split stratifié de 400 cas pour le prompt tuning et le few-shot et de 100 cas pour l'évaluation finale ; une distribution de 60 % d'incidents applicatifs, 25 % d'infrastructure et 15 % de réseau.
L'évaluation baseline a donné : 68 % d'exact match et 82 % de justesse sémantique en correction fonctionnelle ; 2 actions interdites tentées sur 50 scénarios adversariaux (4 %), échec de la gate sécurité ; 8,3 requêtes MCP par diagnostic (objectif : moins de 5) pour une précision de contexte de 0,91 ; une latence P95 de 145 secondes (objectif : moins de 120), second échec de gate, pour un coût de 0,32 $ par diagnostic ; et une rétention hors distribution de 71 %. Deux gates en échec : déploiement bloqué.
Trois itérations sur six semaines ont corrigé le tir. La première a traité la sécurité : guardrails explicites dans le system prompt, couche de validation avant exécution d'outil et 30 nouveaux cas adversariaux dans le dataset red team, taux d'action interdite ramené à 0 %. La deuxième a optimisé la latence : récupération parallèle de trois contextes MCP, modèle plus rapide pour le triage en réservant un modèle de raisonnement aux cas complexes, caching des runbooks fréquents (65 % de hit rate),P95 ramenée de 145 à 98 secondes (-32 %). La troisième a amélioré la précision : few-shot par type d'incident, fine-tuning léger sur les 400 cas d'entraînement et raisonnement guidé dans le prompt, justesse sémantique portée de 82 à 88 %.
Toutes les gates passées, le déploiement a été approuvé. Trois mois après : 73 % des incidents diagnostiqués automatiquement (objectif 70 %), MTTR réduit de 35 % (de 45 à 29 minutes en moyenne), satisfaction SRE de 4,3/5, aucun incident de sécurité sur 1 247 incidents traités, et environ 180 k€ d'économies annuelles en coûts opérationnels.
Meilleures pratiques
Les enseignements tirés de nos déploiements clients convergent vers six principes directeurs.
Commencer avec un golden dataset de qualité : il détermine le plafond de performance atteignable. Comptez 3 à 6 mois pour un dataset mature, diversifié (70 % de cas communs, 20 % de cas complexes, 10 % d'edge cases adversariaux) et mis à jour régulièrement.
Automatiser au maximum : évaluations intégrées au CI/CD, alertes automatiques sur régression, tableaux de bord temps réel, automatiser la routine, escalader l'exceptionnel.
Combiner métriques automatiques et revues humaines : l'automatique pour le volume et la vitesse, l'humain pour le jugement contextuel, typiquement 95 % d'évaluation automatique et 5 % de revue humaine sur échantillon stratifié, centrée sur les prédictions à faible confiance.
Versionner tout : datasets (Git LFS, DVC), prompts (Git avec review), modèles (MLflow, Weights & Biases) et résultats d'évaluation, pour garantir reproductibilité et analyse causale des régressions.
Itérer rapidement : des evals de moins de 15 minutes, un A/B testing systématique des prompts et un data flywheel vertueux, production, dataset enrichi, amélioration, avec un cycle complet inférieur à une semaine.
Surveiller la production : métriques temps réel avec alerting proactif, échantillonnage de 1 à 5 % du trafic pour revue humaine, détection automatique de drift et feedback structuré des SRE. La production est l'environnement d'évaluation ultime.
Conclusion
L'évaluation rigoureuse des agents IA n'est pas optionnelle, c'est un impératif stratégique pour tout déploiement production sérieux, particulièrement dans des domaines critiques comme AIOps où les décisions automatisées impactent directement la continuité opérationnelle.
Le framework en 5 dimensions (correction fonctionnelle, sécurité, utilisation du contexte, performance, robustesse) fournit une couverture complète des aspects à évaluer, et son intégration dans un pipeline continu garantit que les changements ne dégradent pas la qualité tout en permettant une vélocité d'itération élevée.
Avec MCP qui donne aux agents l'accès à des contextes riches et la capacité d'exécuter des actions critiques, les enjeux de qualité et de sécurité sont encore plus élevés. Chez Adservio, nous accompagnons nos clients dans la mise en place de ces frameworks, adaptés à leurs contraintes réglementaires : l'investissement initial (3 à 6 mois) est largement compensé par des agents plus fiables, plus sûrs et plus performants.
L'ère des agents IA en production est là. L'évaluation rigoureuse n'est pas un frein à l'innovation, mais l'enabler qui permet de déployer l'IA de manière responsable et à grande échelle. Assurons-nous d'évaluer ces agents à la hauteur de leurs responsabilités.
Note : Les déclarations et opinions exprimées dans cet article sont celles de l'auteur et ne reflètent pas nécessairement les positions d'Adservio.
RÉCUPÉRER CET ARTICLE
Téléchargez l'article complet en PDF pour le lire hors ligne ou le partager.
RESTER INFORMÉ
Recevez nos prochaines analyses et retours d'expérience directement dans votre boîte mail.
