Observabilité des agents IA en production

Q: Un LLM peut-il en évaluer un autre ?

Oui, c'est la technique standard pour évaluer à l'échelle, mais elle doit être calibrée contre des annotations humaines sur un échantillon. Un juge non calibré produit des scores stables sans rapport avec la qualité perçue par les utilisateurs.

Points clés

L'observabilité des agents IA est la discipline consistant à instrumenter, tracer et évaluer les systèmes agentiques en production. En 2026 c'est une spécialité à part entière, distincte de l'APM classique et du logging d'appels LLM isolés.
Un agent échoue dans des séquences multi-tours et multi-outils : la mauvaise réponse de l'étape 10 provient souvent d'un appel à l'étape 3 ou d'une récupération à l'étape 1. Sans trace complète, le diagnostic relève de la devinette.
La règle qui structure tout : les evals disent si l'agent est bon ; le monitoring dit ce qu'il coûte. Il faut les deux, et ils mesurent des choses différentes.
Sans observabilité, un agent en production est un système non auditable. C'est la raison la plus fréquente pour laquelle un pilote qui fonctionnait cesse de fonctionner sans que personne sache l'expliquer.

L'observabilité des agents IA consiste à enregistrer chaque étape de l'exécution d'un agent (raisonnement, appels d'outils, récupérations et réponses) et à en évaluer la qualité de manière systématique. Elle se distingue du monitoring classique car la défaillance n'est pas une exception mais une décision plausible mais incorrecte. Sans traces par étape ni evals automatisés, impossible de savoir si un agent fonctionne.

Pourquoi un agent ne se débogue pas comme une application classique

Dans le logiciel traditionnel, une défaillance produit une erreur : une exception, un code 500, un test rouge. Dans un agent IA, la défaillance produit une réponse bien rédigée et fausse. Pas de stack trace. Pas de signal.

Un agent enchaîne des décisions : il interprète la demande, choisit un outil, l'invoque avec des paramètres, lit le résultat, décide de l'étape suivante. Une exécution réelle compte facilement 5 à 30 étapes. Quand le résultat final est mauvais, la cause racine n'est presque jamais dans la dernière étape : elle est dans une récupération médiocre au départ ou un paramètre mal formé en milieu de chaîne.

Ce que l'observabilité des agents N'EST PAS : ce n'est pas conserver le prompt et la réponse finale. Ce log convient à un appel LLM isolé, pas à un système qui prend des décisions enchaînées. Ce n'est pas non plus l'APM classique : Datadog vous dit que la requête a pris 4 secondes, pas que l'agent a choisi le mauvais outil.

L'analogie : déboguer un agent sans traces par étape, c'est enquêter sur un accident d'avion en ne disposant que de la position finale de l'appareil, sans boîte noire.

Trois niveaux : traces, evals et monitoring

On les confond constamment alors que ce sont trois choses distinctes.

1. Traces (tracing). L'enregistrement structuré de chaque étape d'une exécution : ce que l'agent a reçu, ce qu'il a raisonné, quel outil il a appelé, avec quels paramètres, ce qui est revenu et en combien de temps. C'est la matière première. Sans traces, aucun des deux autres niveaux n'existe. Le standard de fait en 2026 est OpenTelemetry avec les conventions sémantiques GenAI, ce qui évite l'enfermement propriétaire.

2. Evals (évaluations). La mesure systématique de la qualité de ces exécutions. Deux familles :

Evals offline : exécutés contre un jeu de cas figé, avant le déploiement. Ils répondent à « ce changement de prompt améliore-t-il les choses ? ».
Evals online : exécutés sur du trafic réel avec échantillonnage. Ils répondent à « l'agent fonctionne-t-il toujours bien cette semaine ? ».

3. Monitoring opérationnel. Les métriques dont vit l'entreprise : coût par exécution, latence p95, débit, taux d'erreur, consommation de tokens. Elles répondent à « est-ce soutenable à l'échelle ? ».

Niveau	Répond à	Quand	Sans cela...
Traces	Ce qui s'est exactement passé	Toujours, à chaque exécution	Aucun diagnostic possible
Evals offline	Ce changement améliore-t-il ?	Avant chaque déploiement	Vous modifiez les prompts à l'aveugle
Evals online	Cela fonctionne-t-il encore ?	Échantillon de trafic réel	Dégradation silencieuse
Monitoring	Combien ça coûte et ça dure ?	En continu	Surprises de coût et de latence

L'erreur la plus fréquente : des entreprises qui mettent en place un monitoring opérationnel (tableaux de bord de latence et de tokens) sans aucun eval. Elles savent parfaitement ce que coûte un agent et n'ont aucune idée de s'il a raison.

Que mesurer réellement dans un agent

Les métriques d'un chatbot ne conviennent pas à un agent. Voici celles qui comptent, dans l'ordre de ce qu'elles révèlent en premier :

Précision du choix d'outil. A-t-il choisi la bonne fonction ? C'est la défaillance numéro un et la moins coûteuse à détecter.
Validité des paramètres. A-t-il appelé la bonne fonction avec les bons arguments ? Un chercher_client avec le mauvais identifiant renvoie des données valides concernant quelqu'un d'autre : la défaillance la plus dangereuse, car elle n'a pas l'air d'en être une.
Qualité de la récupération (si RAG). Les fragments récupérés contenaient-ils la réponse ? Si la récupération échoue, tout le reste n'est que bruit. Se mesure avec le context recall et la context precision.
Ancrage dans la source (groundedness). La réponse s'appuie-t-elle sur ce qui a été récupéré, ou le modèle a-t-il comblé les trous ? C'est la métrique qui détecte les hallucinations dans les systèmes RAG.
Taux d'achèvement de tâche. L'exécution s'est-elle terminée en atteignant l'objectif, ou a-t-elle bouclé, abandonné, demandé une intervention ?
Étapes par tâche. Un agent qui a besoin de 22 étapes pour ce qui devrait en prendre 4 est mal conçu, même s'il a raison. C'est un indicateur précoce de dégradation.
Coût et latence p95 par tâche accomplie. Pas par appel : par tâche. C'est la seule unité comparable au processus manuel remplacé.
Taux d'escalade humaine. Quand l'agent rend la main. Cela devrait être une métrique cible, pas un échec.

Une mise en garde utile : utiliser un LLM comme juge (LLM-as-a-judge) pour noter les réponses est une technique valable et désormais standard, mais elle doit être calibrée contre des annotations humaines sur un échantillon. Un juge non calibré produit des chiffres qui montent pendant que la qualité baisse.

Données clés du marché

L'observabilité des agents s'est imposée en 2026 comme une discipline d'ingénierie à part entière, distincte de l'APM traditionnel, précisément parce que les agents échouent dans des séquences multi-tours où la cause se situe plusieurs étapes avant le symptôme (Arize, 2026).
46 % des organisations citent l'intégration aux systèmes existants comme principal défi des déploiements d'agents, et le délai médian jusqu'à la valeur est de 5,1 mois. Les déploiements qui ne mesurent rien sont ceux qui allongent cette médiane.
Seules 31 % des entreprises ont au moins un agent en production, contre 62 % qui expérimentent. Le passage du pilote à la production est, en pratique, un problème d'observabilité et de contrôle.

Notre avis : l'écart entre « nous expérimentons des agents » et « nous avons des agents en production » s'explique surtout par l'incapacité à prouver qu'un agent fonctionne de façon constante. Cela ne se prouve pas par des démos, mais par des evals.

La stack : quels outils en 2026

Il n'y a pas de réponse unique, mais des catégories claires :

Plateformes intégrées de traces et evals : Langfuse (open source, auto-hébergeable, l'option par défaut en présence d'exigences RGPD ou de données sensibles), LangSmith (si vous utilisez déjà LangChain/LangGraph), Braintrust et Arize Phoenix/AX (solides sur l'évaluation systématique).
Observabilité générale avec module LLM : Datadog LLM Observability et équivalents, si votre équipe y vit déjà et que vous voulez une seule fenêtre.
Open source léger : Opik (Comet), MLflow pour le suivi d'expériences.

Notre recommandation pragmatique : commencez par OpenTelemetry comme couche d'instrumentation et une plateforme qui la consomme. Instrumenter selon un standard ouvert permet de changer de fournisseur d'observabilité sans réécrire l'agent, ce qui vaut plus que n'importe quelle fonctionnalité dans un marché qui se consolide à cette vitesse.

Si vous manipulez des données personnelles ou réglementées, la décision se simplifie : auto-hébergé. Les traces d'un agent contiennent, par définition, tout ce que l'agent a vu. Cela inclut des données clients. Envoyer des traces complètes vers un SaaS externe sans évaluer le traitement des données est un problème RGPD en attente.

Cas d'usage courants

Cas 1 : Dégradation silencieuse après un changement de modèle.

Problème : un agent de support escalade davantage de cas vers l'humain après une mise à jour du modèle. Personne ne fait le lien pendant des semaines.
Solution : evals online avec échantillonnage quotidien et alerte sur le taux d'achèvement de tâche.
Stack : OpenTelemetry + plateforme d'evals + LLM-as-a-judge calibré.
Résultat : la baisse est détectée en heures, pas en semaines.

Cas 2 : Coût qui s'envole sans hausse d'usage.

Problème : la consommation de tokens augmente de 40 % par mois à volume constant.
Solution : métrique d'étapes par tâche. L'agent était entré dans des boucles de reprise après un changement d'API externe.
Stack : traces par étape + alerte sur le percentile d'étapes par exécution.
Résultat : l'outil renvoyant des erreurs mal formées est identifié et la logique de reprise corrigée.

Cas 3 : Réponses correctes sur les mauvais documents.

Problème : un agent RAG répond avec assurance en s'appuyant sur l'ancienne version d'une procédure.
Solution : mesurer la context precision et ajouter un filtre de version documentaire à la récupération.
Stack : évaluation de la récupération + métadonnées de version dans la base vectorielle.
Résultat : le problème est identifié comme relevant de la récupération, pas du modèle : là où tout le monde cherchait.

Comment le mettre en place, étape par étape

Instrumentez avant de passer à l'échelle. Ajoutez les traces dès le premier prototype, avec OpenTelemetry si possible. Instrumenter un agent déjà en production coûte trois fois plus cher et impose de toucher au code en production.
Constituez un jeu d'évaluation à partir de cas réels. 30 à 50 cas bien choisis issus du trafic réel valent mieux que 500 cas synthétiques. Incluez les cas rares qui ont déjà échoué.
Définissez ce qu'est « correct » pour chaque cas. C'est l'étape que l'on saute et sans laquelle rien d'autre ne fonctionne. Si vous ne savez pas écrire le critère de succès, vous ne pouvez pas l'automatiser.
Automatisez les evals offline dans le pipeline de déploiement. Aucun changement de prompt, de modèle ou d'outil ne passe en production sans franchir le jeu de cas. Traitez les prompts comme du code.
Activez des evals online échantillonnés. Une part du trafic réel évaluée quotidiennement. C'est ce qui détecte la dégradation invisible aux tests offline.
Alertez sur les métriques qui comptent : baisse de l'achèvement de tâche, hausse des étapes par tâche, hausse des escalades. Ne vous limitez pas à la latence et au coût.
Bouclez la boucle. Chaque défaillance détectée en production devient un nouveau cas du jeu d'évaluation. Sans cette étape, le système est observé, pas amélioré.

Erreurs fréquentes (et comment les éviter)

Erreur : mettre en place l'observabilité après l'incident. → La réalité : quand l'incident survient, vous n'avez plus les traces de ce qui s'est passé. L'instrumentation est préventive par définition.

Erreur : ne journaliser que l'entrée et la sortie finale. → La réalité : dans une chaîne de 15 étapes, un log des extrémités ne dit rien. Il faut l'étape intermédiaire où cela a dérapé.

Erreur : confondre monitoring et évaluation. → La réalité : savoir que l'agent répond en 2 secondes et consomme X tokens ne dit rien de sa justesse. Questions différentes, instruments différents.

Erreur : utiliser LLM-as-a-judge sans calibration. → La réalité : un juge jamais confronté à des annotations humaines peut afficher 90 % de justesse pendant que les utilisateurs se plaignent. Calibrez sur un échantillon avant de croire le chiffre.

Erreur : un jeu d'évaluation composé de cas faciles. → La réalité : un jeu que l'agent réussit toujours ne mesure rien. Il doit contenir les cas ambigus et ceux qui ont déjà échoué.

Erreur : envoyer des traces avec données personnelles vers un SaaS sans évaluer le traitement. → La réalité : les traces contiennent tout ce que l'agent a vu. Avec des données réglementées : auto-hébergement ou anonymisation préalable. Ce n'est pas un détail de conformité, c'est la décision qui contraint le choix d'outil.

Délais et effort réalistes

Instrumentation de base avec traces sur un agent existant : 1 à 2 semaines, davantage si l'agent a été construit sans abstraction d'outils.
Premier jeu d'évaluation utile (30 à 50 cas avec critères de succès définis) : 1 à 2 semaines, dont l'essentiel passe à s'accorder sur ce qu'est « correct », pas à écrire du code.
Evals automatisés dans le pipeline de déploiement : une semaine supplémentaire une fois le jeu de cas constitué.
Où se situe l'effort réel : pas dans les outils, qui sont matures. Dans la définition des critères de qualité métier. C'est une conversation produit, pas une conversation d'infrastructure.

Indicateurs à suivre dès le jour 1 : couverture des traces (part d'exécutions entièrement instrumentées), taux d'achèvement de tâche, étapes par tâche, taux d'escalade humaine et coût par tâche accomplie. Si un agent est en production depuis plus d'un mois et que vous ne pouvez pas énoncer son taux de justesse sur des cas réels, il n'est pas en production : il est en liberté.

Questions fréquentes

Qu'est-ce que l'observabilité des agents IA ?

C'est la pratique consistant à instrumenter, tracer et évaluer les systèmes agentiques en production, en enregistrant chaque étape d'exécution (raisonnement, appels d'outils, récupérations et sorties) pour diagnostiquer les défaillances et mesurer la qualité. Elle diffère de l'APM traditionnel car la défaillance d'un agent n'est pas une exception mais une décision plausible mais incorrecte.

Quelle différence entre evals et monitoring ?

Les evals mesurent si l'agent fait bien son travail (précision, ancrage, achèvement de tâche). Le monitoring mesure ce que coûte son exploitation (latence, tokens, débit, erreurs). Un agent peut afficher des métriques opérationnelles parfaites tout en donnant de mauvaises réponses.

Qu'est-ce qu'un eval online et en quoi diffère-t-il d'un eval offline ?

Un eval offline s'exécute contre un jeu de cas figé avant déploiement et répond à « ce changement améliore-t-il les choses ? ». Un eval online s'exécute par échantillonnage sur du trafic réel et répond à « l'agent fonctionne-t-il encore bien aujourd'hui ? ». Ils détectent des problèmes différents et les deux sont nécessaires.

Un LLM peut-il en évaluer un autre ?

Oui, c'est la technique standard en 2026 pour évaluer à l'échelle, mais elle doit être calibrée contre des annotations humaines sur un échantillon. Un juge non calibré produit des scores stables sans rapport avec la qualité perçue par les utilisateurs.

Peut-on utiliser Datadog ou New Relic pour observer des agents IA ?

Ces outils couvrent les métriques opérationnelles et offrent une fenêtre unique si l'équipe y vit déjà, mais ils ne couvrent pas à eux seuls l'évaluation de la qualité ni la trace sémantique par étape. L'usage courant est de combiner l'outil corporate avec une plateforme d'evals dédiée.

Comment le RGPD s'applique-t-il aux traces d'un agent ?

Les traces contiennent tout ce que l'agent a traité, y compris des données personnelles. Avec des données réglementées, l'option raisonnable est une plateforme auto-hébergée ou une anonymisation préalable. À décider avant de choisir l'outil.

Combien de cas faut-il dans un jeu d'évaluation ?

Entre 30 et 50 cas bien choisis issus du trafic réel donnent plus de signal que des centaines de cas synthétiques. L'essentiel est d'inclure les scénarios ambigus et les défaillances connues, pas les cas faciles.

Quelle métrique alerte avant qu'un agent se dégrade ?

Les étapes par tâche. Une hausse du nombre d'étapes nécessaires pour résoudre la même chose précède généralement la baisse du taux de justesse et la hausse du coût, et apparaît avant les plaintes des utilisateurs.

Vous avez un agent en production dont vous ne pouvez pas prouver qu'il fonctionne ?

Chez Naxia, nous instrumentons les agents avec des traces par étape, des jeux d'évaluation construits à partir de vos cas réels et des evals automatisés dans le pipeline de déploiement. Avec des standards ouverts (OpenTelemetry) pour ne dépendre d'aucun fournisseur, et une option auto-hébergée en présence de données réglementées.

Si vous voulez passer de « ça a l'air de marcher » à un chiffre défendable en comité, parlons-en. Sans engagement et sans PowerPoint de 40 pages.

Demandez une démo gratuite →

Ou explorez d'abord notre processus d'implémentation.

Observabilité et évaluation des agents IA en production : comment savoir si votre agent fonctionne