Loïc BoninLB
← Veille

ia

Évaluer et observer ses agents en production : le guide LLMOps

14 juillet 2026·5 min de lecture

Intro

Contrairement aux applications web classiques, un système agentique ne plante pas proprement avec un code d'erreur HTTP ou une exception système bien visible. Il dérive silencieusement. Il commence par interpréter une consigne de travers, prend une décision d'outil inattendue, et s'enfonce dans une boucle infinie de réflexion en consommant votre budget d'API à vitesse grand V.

Pour déployer des agents de production sereinement sur de grands projets, il faut appliquer un nouveau style d'évaluation. L'observabilité ne consiste plus à lire des lignes de log à plat, et la qualité ne se valide pas par de simples tests fonctionnels déterministes. Bienvenue dans le monde de l'LLMOps.

Les trois étapes de maturité de l'évaluation d'agents

Étape 1 : l'évaluation manuelle

L'évaluation repose sur des prompts et une inspection informelle des résultats, sans dataset de référence ni critère de réussite documenté. Un ingénieur exécute l'agent sur quelques scénarios représentatifs, lit les sorties, et juge à l'œil si le comportement lui semble correct. Pour des prototypes, c'est suffisant. Pour des agents de production, il faut passer à l'étape 2.

Étape 2 : l'évaluation structurée et automatisée

La deuxième étape marque un changement d'échelle. On y introduit des grilles d'évaluation écrites, des jeux de tests avec des résultats attendus, des vérifications automatisées qui tournent sans intervention humaine à chaque changement de code. C'est le niveau des tests unitaires appliqués aux sorties LLM : vérifier qu'une réponse contient bien certains mots-clés, qu'elle respecte une longueur minimale, ou qu'un format de sortie attendu est bien respecté.

Cette étape apporte une vraie valeur : une évaluation reproductible à chaque commit, une détection immédiate des régressions, et une couverture des cas déjà identifiés comme problématiques. Mais elle à une limite: une réponse peut contenir tous les mots-clés attendus, respecter le format demandé, et malgré tout être maladroite, incomplète ou légèrement à côté de l'intention réelle de l'utilisateur. Autrement dit, il est parfaitement possible de faire passer 100 % des tests automatisés tout en livrant une réponse médiocre, simplement parce que ce type de test ne sait mesurer que des critères mécaniques, jamais la pertinence ou la nuance du contenu.

Étape 3 : l'observabilité par traces et l'évaluation multi-couches

Une fois que l'évaluation automatisée montre ses limites, il faut passer à une évaluation statistique et continue, intégrée à un pipeline CI/CD, capable de détecter une dérive de qualité en production et pas seulement une régression au moment du commit. Cela suppose de sortir du simple test pass/fail pour aller vers des métriques quantifiées, des comparaisons statistiquement significatives par rapport à une base de référence, et un suivi continu du comportement de l'agent en conditions réelles.

C'est précisément à ce niveau de maturité qu'interviennent le traçage structuré façon OpenTelemetry et les trois couches d'évaluation détaillées ci-dessous : validation déterministe, LLM-as-a-judge, et simulation en sandbox. Ces briques ne remplacent pas les étapes précédentes, elles les complètent.

L'observabilité des agents : au-delà du log, le graphe de traces

Il faut aborder l'observabilité sous forme de graphes de traces et de sous-étapes (spans). Chaque action de l'agent doit être instrumentée pour capturer :

  • Le contexte complet (les variables système, l'historique récent).
  • Les arguments précis passés aux outils et leurs réponses brutes.
  • Le raisonnement interne de l'IA (ses tokens de pensée).

Le rôle d'OpenTelemetry (OTel)

Pour éviter de lier votre infrastructure à une plateforme d'observabilité propriétaire, l'utilisation d'OpenTelemetry (OTel) s'est imposée comme un standard fiable. Les conventions sémantiques GenAI d'OpenTelemetry permettent de structurer et d'exporter ces traces de manière universelle. Que vous utilisiez une solution open-source ou un outil SaaS, votre code reste inchangé : il émet des spans standardisés que n'importe quel collecteur peut ingérer.

L'importance du rejeu (replay)

En production, vous ferez face à des cas marginaux où l'agent prend une décision aberrante au milieu d'un long cycle de travail. Pour corriger cela, le traçage doit permettre le rejeu. Les plateformes modernes permettent de cibler une trace défaillante, d'extraire l'état exact de l'agent à une étape intermédiaire précise, et de le charger dans un espace de test pour ajuster le prompt système ou corriger l'outil fautif. Sans cette capacité à isoler et rejouer un état, le débogage d'agents complexes est un travail beaucoup trop fastidieux.

Les trois couches de l'évaluation d'agents (Agent Evals)

L'évaluation des agents s'articule autour de trois couches complémentaires.

Première couche : Les garde-fous de base

Avant de lancer des évaluations coûteuses, comme pour l'étape de maturité n°2, il faut des tests unitaires classiques. Si votre agent doit générer du code, compile-t-il ? Si votre outil doit renvoyer une structure de données, respecte-t-elle le schéma JSON attendu ? Ces assertions rapides et peu coûteuses permettent d'éliminer immédiatement les erreurs grossières de syntaxe et de typage.

Deuxième couche : le modèle comme juge (LLM-as-a-Judge)

Pour évaluer la pertinence fonctionnelle ou la fidélité d'une réponse, il faut un autre agent spécialisé, le "LLM as a judge", doté d'une grille d'évaluation très stricte. On lui fournit la requête de départ, la réponse de l'agent et, si possible, une réponse idéale de référence. Le modèle juge attribue une note (par exemple sur une échelle de un à cinq) et doit obligatoirement justifier sa note par une explication textuelle. Cette méthode probabiliste permet de suivre l'évolution de la qualité globale au fil des commits.

Troisième couche : la simulation en environnement isolé (Sandbox)

La forme d'évaluation la plus sécurisée pour un agent consiste à le laisser exécuter sa tâche dans une sandbox et à vérifier les effets de bord. Par exemple, si vous testez un agent de débogage de base de données, vous l'exécutez sur une copie anonymisée de votre base de production, et vous vérifiez à la fin que l'anomalie a bien disparu et que les données connexes sont toujours intègres. C'est l'évaluation par le résultat réel.

Les jeux de données de référence

Bâtir ces évaluations nécessite de constituer un jeu de tests de référence. Ne cherchez pas à tout anticiper le premier jour. Il faut commencer avec une dizaine de cas d'usage, puis enrichir systématiquement cette suite en y injectant chaque bug ou comportement indésirable rencontré en production. Ce jeu de données devient le patrimoine de qualité de votre agent.

Le panorama des outils LLMOps

L'écosystème s'est structuré pour fournir des outils d'observabilité et d'évaluation. La vraie différenciation se joue sur la profondeur de l'évaluation des agents, le couplage à un framework donné, et la possibilité d'auto-hébergement. Voici les approches dominantes actuelles.

  • DeepEval : s'intègre nativement dans pytest, avec plus de 50 métriques prêtes à l'emploi couvrant hallucination, fidélité, pertinence et biais, ce qui en fait l'outil le plus souvent recommandé pour exécuter des évaluations LLM aux côtés des tests unitaires classiques.
  • Promptfoo : cible spécifiquement les tests en ligne de commande avec configuration YAML, avec une détection d'injections de prompt, et une intégration CI/CD immédiate via GitHub Actions.
  • Braintrust (Payant) : C'est l'une des plateformes de référence pour les équipes qui souhaitent intégrer les évaluations dans leur cycle de CI/CD. Braintrust excelle dans la gestion des versions de prompts, l'exécution rapide de suites de tests parallèles et la comparaison visuelle des performances entre deux commits.
  • Arize Phoenix (Auto-hébergé) : Une solution open-source de premier plan, particulièrement appréciée pour son approche native OpenTelemetry. Phoenix permet d'analyser vos traces de production en local ou de manière auto-hébergée, et d'y appliquer des modèles d'évaluation de la qualité des données de façon très fine.
  • LangSmith (Payant): développé par l'équipe LangChain, il offre l'intégration la plus profonde du marché avec LangChain et LangGraph, permettant de voir précisément où l'agent a pris une mauvaise décision ou quel outil a surconsommé des tokens..
  • Langfuse (Payant ou Auto-hébergé): Langfuse a été racheté par ClickHouse debut 2026, ClickHouse s'engageant à maintenir le projet open source. L'outil est un très bon choix pour l'évaluation auto-hébergée, ses fonctionnalités d'évaluation ayant nettement rattrapé celles de LangSmith au cours de la dernière année.

Exemple concret : Un évaluateur de cohérence en Python

Voici un script d'évaluation minimaliste utilisant l'API d'Anthropic. Il implémente le pattern "LLM-as-a-judge" pour attribuer un score de cohérence à une réponse d'agent en fonction des consignes initiales. Ce type d'évaluateur trouve sa place dans un module dédié aux évaluations (par exemple evals/consistency_evaluator.py), séparé du code applicatif de l'agent. Il est conçu pour être appelé depuis une suite pytest exécutée en CI/CD à chaque pull request, ce qui permet de bloquer un merge si la qualité moyenne des réponses chute sous un seuil défini, sans dépendre d'une relecture humaine systématique.

python
from __future__ import annotations
 
import os
from typing import Any
 
import anthropic
from anthropic.types import Message
 
 
class ConsistencyEvaluator:
"""
Evaluateur probabiliste appliquant le pattern LLM-as-a-Judge.
Utilise un modele de reference et une sortie structuree en mode strict
pour garantir la conformite au schema, sans parsing fragile de texte libre.
"""
 
JUDGE_TOOL: dict[str, Any] = {
"name": "submit_evaluation",
"description": "Soumet le score de coherence et sa justification.",
"strict": True,
"input_schema": {
"type": "object",
"properties": {
"score": {
"type": "integer",
"description": "Score de 1 (incoherent) a 5 (parfaitement coherent).",
"minimum": 1,
"maximum": 5,
},
"justification": {
"type": "string",
"description": "Explication detaillee du score attribue.",
},
},
"required": ["score", "justification"],
},
}
 
def __init__(self, judge_model: str = "claude-opus-4-8") -> None:
api_key = os.environ.get("ANTHROPIC_API_KEY")
if not api_key:
raise ValueError("La variable d'environnement ANTHROPIC_API_KEY est requise.")
self.client = anthropic.Anthropic(api_key=api_key)
self.judge_model = judge_model
 
def evaluate(self, prompt: str, agent_response: str) -> dict[str, Any]:
"""
Evalue la coherence de la reponse par rapport au prompt initial.
Retourne un score de 1 a 5 et une justification, via un appel d'outil strict.
"""
system_instruction = (
"Tu es un juge technique impartial chargé de valider la qualité de réponses d'agents IA. "
"Base ton jugement uniquement sur la précision technique, le respect des consignes du "
"prompt et l'absence d'hallucinations. Utilise systématiquement l'outil submit_evaluation "
"pour rendre ton verdict."
)
 
judge_prompt = (
f"Voici le prompt initial de l'utilisateur :\n"
f"<prompt>\n{prompt}\n</prompt>\n\n"
f"Voici la réponse fournie par l'agent :\n"
f"<response>\n{agent_response}\n</response>\n\n"
f"Évalue cette réponse et soumets ton verdict via l'outil submit_evaluation."
)
 
try:
response = self.client.messages.create(
model=self.judge_model,
max_tokens=1000,
temperature=0,
system=system_instruction,
tools=[self.JUDGE_TOOL],
tool_choice={"type": "tool", "name": "submit_evaluation"},
messages=[{"role": "user", "content": judge_prompt}],
)
except anthropic.APIError as exc:
raise RuntimeError(f"Échec de l'appel au modèle juge : {exc}") from exc
 
return self._extract_evaluation(response)
 
def _extract_evaluation(self, response: Message) -> dict[str, Any]:
"""Extrait le score et la justification depuis le bloc tool_use structuré."""
for block in response.content:
if block.type == "tool_use" and block.name == "submit_evaluation":
score = int(block.input["score"])
if not 1 <= score <= 5:
raise ValueError(f"Score hors bornes reçu du modèle juge : {score}")
justification = block.input["justification"]
return {
"score": score,
"justification": justification,
"passed": score >= 4,
}
 
raise RuntimeError("Le modèle juge n'a pas retourné d'évaluation structurée.")
 
 
if __name__ == "__main__":
evaluator = ConsistencyEvaluator()
 
consigne = "Rédige une fonction Python qui calcule la factorielle d'un nombre entier de manière récursive."
reponse_a_tester = (
"Voici la fonction récursive : \n"
"def factorielle(n):\n"
" return 1 if n <= 1 else n * factorielle(n - 1)"
)
 
result = evaluator.evaluate(prompt=consigne, agent_response=reponse_a_tester)
 
print(f"Validation passee : {result['passed']}")
print(f"Score attribue : {result['score']}/5")
print(f"Justification : {result['justification']}")

Dans ce code, l'évaluateur interroge un modèle tiers pour obtenir un rapport structuré contenant une note et un texte de justification. Cette fonction de validation peut ensuite être appelée dans un script de test au sein de votre pipeline d'intégration continue, bloquant la fusion d'une branche si le score moyen de cohérence de votre suite de tests descend en dessous d'un certain seuil (par exemple, un score moyen de quatre sur cinq).

Conclusion

L'observabilité et l'évaluation ne sont pas des surcouches optionnelles à ajouter en fin de projet. Elles constituent une continuité à faire évoluer tout au long du cycle de vie de toute architecture agentique de production. En faisant progresser une équipe du test manuel vers l'automatisation par assertions, puis vers le traçage structuré et avec des standards comme OpenTelemetry et en validant chaque commit avec des épreuves combinant assertions déterministes et évaluations probabilistes (comme le pattern "LLM-as-a-judge"), on transforme l'évaluation des réponses des agents en un élément fiable du développement logiciel.

Liens utiles:

IABonnes pratiquesProductivité