# AI Evals pour MCP dans AIOps : Comment évaluer et améliorer vos agents IA

> Découvrez comment mettre en place des évaluations rigoureuses pour les agents IA utilisant le Model Context Protocol dans les environnements AIOps.

- Date : 2025-10-10
- Lecture : 10 min
- Catégorie : mlops
- Tags : AIOps, MCP, Model Context Protocol, AI Evaluation, MLOps, Testing
- URL : https://www.adservio.fr/insights/articles/ai-evals-pour-mcp-dans-aiops-comment-evaluer-et-ameliorer

## L'essentiel

- Le Model Context Protocol (MCP) donne aux agents IA AIOps un accès standardisé à des contextes riches (logs, métriques, CMDB) et une capacité d'action réelle, ce qui rend leur évaluation d'autant plus critique.
- Les tests unitaires, tests d'intégration et monitoring classiques sont inadaptés au caractère probabiliste et aux comportements émergents des agents IA : il faut des évaluations statistiques sur des distributions d'inputs.
- Un framework en 5 dimensions structure l'évaluation : correction fonctionnelle, sécurité et guardrails, utilisation du contexte, latence et performance, robustesse et fiabilité.
- L'évaluation continue s'intègre au pipeline CI/CD (pre-commit, pre-merge, nightly, weekly, production) avec des gates de déploiement bloquants sur des seuils précis (score fonctionnel, action interdite, latence, robustesse).
- Un cas d'étude réel montre une amélioration en trois itérations : taux d'action interdite ramené à 0 %, latence P95 réduite de 145 à 98 secondes, précision du diagnostic portée de 82 à 88 %, pour un MTTR réduit de 35 % en production.

## 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 ?

> À lire aussi : [Le Model Context Protocol : au-delà de la tendance, le standard des agents IA](https://www.adservio.fr/insights/articles/le-protocole-model-context-au-dela-de-la-tendance): Architecture, spécification 2026, registre officiel, sécurité : comment le Model Context Protocol est passé du buzz au standard des agents IA en production.

## 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.

> À lire aussi : [Comment évaluer un système LLM](https://www.adservio.fr/insights/articles/comment-evaluer-un-systeme-llm): Évaluer un système LLM en production : métriques de qualité, jeux d'évaluation, LLM-as-judge, tests de régression de prompts et monitoring continu des dérives.

## 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.

## FAQ

### Pourquoi les tests logiciels classiques ne suffisent-ils pas pour évaluer un agent IA ?

Parce que les LLM sont non déterministes (un même input peut générer des outputs différents), que les agents IA ont des comportements émergents impossibles à énumérer exhaustivement, et que les KPIs IT classiques comme l'uptime ne capturent pas la qualité des décisions prises.

### Quelles sont les 5 dimensions du framework d'évaluation ?

Functional Correctness (l'agent accomplit-il la tâche correctement ?), Safety & Guardrails (évite-t-il les actions dangereuses ?), Context Utilization (utilise-t-il efficacement les contextes MCP ?), Latency & Performance (répond-il assez vite ?) et Robustness & Reliability (reste-t-il performant face à l'imprévu ?).

### Quels seuils bloquent un déploiement en production ?

Un score fonctionnel global inférieur à 0,75, un taux d'action interdite non nul, un taux d'escalade manquante supérieur à 5 %, une latence P95 supérieure à 120 secondes, un coût par incident supérieur à 0,50 $, ou un taux de succès adversarial inférieur à 95 % : si l'une de ces gates échoue, le déploiement est bloqué automatiquement.