Observabilité des agents IA : traces, evals, replay (2026)

L’observabilité, c’est le vrai “framework” de la prod

On peut construire un agent en une soirée. On peut aussi passer trois semaines à comprendre pourquoi il se trompe “une fois sur dix”.

La différence, c’est rarement le modèle. C’est presque toujours la visibilité.

Quand un agent échoue, vous devez pouvoir répondre à quatre questions simples :

1. Qu’est-ce qu’il a vu ? (inputs, contexte, sources)
2. Qu’est-ce qu’il a décidé ? (plan, raisons, contraintes)
3. Qu’est-ce qu’il a fait ? (outils appelés, paramètres, résultats)
4. Pourquoi ça a cassé ? (erreur outil, ambiguïté, policy, données manquantes)

Les SDK modernes poussent cette idée. Par exemple, l’OpenAI Agents SDK met en avant le fait de conserver une trace complète (“full trace”) de ce qui s’est passé.¹

Et OpenAI documente des mécanismes de “trace grading” : noter des traces d’agents pour industrialiser la qualité.²

Traduction : on sort du folklore (“j’ai l’impression que l’agent est moins bon”) pour aller vers l’ingénierie (“voici 200 traces, voici les erreurs, voici la régression”).

Traces : quoi logguer (et comment éviter la bouillie)

Le piège #1 : “on loggue tout”.

Résultat :

• trop de bruit,
• trop de données sensibles,
• et personne ne sait lire.

Le piège #2 : “on loggue rien”.

Résultat :

• debugging à la divination,
• audit impossible,
• et régressions invisibles.

Le minimum viable d’une trace d’agent

Pour un agent outillé, une trace utile ressemble à ça :

1. Entrée

   • prompt système (versionné),
   • message utilisateur,
   • contexte injecté (RAG chunks, mémoire),
   • variables (tenant, langue, mode).

2. Décisions

   • plan (même succinct),
   • transitions d’état (si vous êtes graph-first),
   • pourquoi l’agent a choisi tel outil (si disponible).

3. Actions (tools)

   • nom de l’outil,
   • paramètres structurés,
   • durée,
   • réponse (résumée + hash si besoin),
   • erreurs (429/500/timeout).

4. Vérifications

   • validateurs exécutés,
   • règles appliquées,
   • anomalies détectées.

5. Sortie

   • réponse utilisateur,
   • actions exécutées,
   • escalade déclenchée (oui/non, pourquoi).

Exemple : une trace “lisible” (et pas juste un dump de logs)

Une trace doit être lisible par :

• un dev (debug),
• un ops (incident),
• et parfois un métier (audit).

Donc vous visez un format “narratif”.

Exemple minimal (simplifié) :

{
  "trace_id": "01J7...XYZ",
  "agent_version": "claims-triage@2026-03-05",
  "input": {
    "channel": "email",
    "tenant": "assureur-A",
    "user_message": "...",
    "rag_sources": ["CG-2026-02#p12", "Proc-IT-17#v3"]
  },
  "steps": [
    { "type": "plan", "content": "Extraire champs, verifier complétude, créer ticket." },
    { "type": "tool_call", "tool": "extract_fields", "duration_ms": 240, "result": "ok" },
    { "type": "tool_call", "tool": "create_ticket", "duration_ms": 310, "result": "ok" }
  ],
  "output": { "status": "escalate", "reason": "pièce manquante" }
}

Ce n’est pas un standard universel. Mais c’est un bon objectif : une histoire courte, structurée, corrélable.

Et, point crucial : vous ne stockez pas tout “en clair”. Vous versionnez, vous hash, vous redigez.

Corrélation : relier l’agent à votre SI

Un agent B2B ne vit pas seul. Il vit dans une architecture distribuée.

Donc vous voulez pouvoir relier :

• la trace agent,
• la trace de votre API,
• la trace de votre base,
• et la trace de votre bus/queue.

OpenTelemetry formalise la notion de trace (spans, trace_id) comme signal d’observabilité.³ Et W3C Trace Context standardise la propagation de contexte entre services via des headers (traceparent).⁴

Concrètement : si votre agent appelle un outil “create_ticket”, vous voulez voir ce span dans la même trace que l’appel HTTP correspondant.

Conventions GenAI : tracer avec un vocabulaire standard

Tracer, c’est bien. Tracer “proprement”, c’est mieux.

Sinon, chaque équipe invente ses champs :

• modelName vs llm_model vs model,
• toolLatency vs duration_ms,
• etc.

OpenTelemetry publie des conventions sémantiques GenAI (attributs standardisés pour les appels LLM, agents et frameworks).⁵

Vous n’êtes pas obligé de tout suivre. Mais si vous adoptez un standard, vos dashboards survivent aux refactors.

Tracer sans fuiter : redaction, PII, et politiques de rétention

L’observabilité n’est pas une excuse pour stocker de la donnée sensible partout.

Trois pratiques simples (qui évitent des sueurs froides) :

1. Hash des prompts et versioning
   Vous logguez une version (“prompt_v12”) et un hash, pas forcément tout le texte système en clair.

2. Redaction des PII
   Noms, emails, numéros de contrat : vous redigez avant stockage, ou vous stockez dans un coffre isolé avec accès restreint.

3. TTL / rétention
   Vous définissez combien de temps une trace vit, qui peut y accéder, et comment la supprimer.

Un agent observable doit aussi être gouvernable. Sinon, vous déplacez le risque : vous ne le réduisez pas.

Métriques : ce qui compte (et ce qui trompe)

Les métriques, c’est délicat.

Parce qu’un agent peut “réussir” en apparence, mais échouer en business. Ou l’inverse.

Les métriques qui aident vraiment

1. Taux de réussite par tâche
   Définissez “réussite” par résultat, pas par texte.

2. Taux d’escalade
   Pas “moins d’escalade = mieux”.
   “Escalade utile” = l’humain intervient quand ça vaut le coup.

3. Latence P95/P99
   La moyenne est un mensonge confortable.

4. Coût par tâche résolue
   Tokens + outils + retrys.
   (Et oui, parfois votre outil coûte plus que votre LLM.)

5. Tool error rate
   429/500/timeout : c’est souvent la vraie cause des comportements “bizarres”.

6. Régressions
   “Ça marchait hier” est une métrique.
   Il faut juste l’outiller.

Les métriques qui trompent

• “Nombre de messages” (souvent du bruit)
• “Nombre d’actions” (souvent du risque)
• “Score moyen” sans distribution (cache les cas catastrophiques)

SLOs : mettre des budgets, sinon l’agent “dépense”

Une métrique sans seuil, c’est un chiffre. Un SLO (Service Level Objective), c’est une décision.

Pour un agent, des SLOs utiles ressemblent à :

• latence “acceptable” (pas juste en moyenne, mais au P95/P99),
• coût “acceptable” par tâche résolue,
• taux d’erreur outil maximal (sinon le système devient instable),
• et un plafond d’actions par exécution (budget d’outils).

Ce dernier point est souvent oublié.

Un agent sans budget, c’est un stagiaire qui a une carte corporate sans plafond. Il peut “réessayer”, “vérifier”, “double-check”… jusqu’à ce que votre facture ressemble à une blague de mauvais goût.

Un budget simple :

• max tool calls,
• max tokens,
• max durée,
• et une stratégie d’échec (“escalade si dépassement”).

Ce n’est pas une limitation. C’est une façon de rendre l’agent gouvernable.

Évaluation : passer de la démo à la régression

Le piège des agents : on les évalue comme des chatbots.

Un agent n’est pas seulement un texte. C’est un process.

Donc vos évaluations doivent capturer :

• le résultat final,
• la qualité des tool calls,
• la conformité (policies),
• et la robustesse (erreurs, ambiguïté).

OpenAI documente des “agent evals” et des approches de grading (dont trace grading).⁶²

Et côté outillage “agnostique”, des plateformes comme LangSmith décrivent l’évaluation et la traçabilité comme des primitives d’observabilité.⁷

Trois types d’évaluations (à combiner)

1. Tests d’outils
   C’est du “logiciel classique” : schémas, erreurs, idempotence.

2. Evals de conversations / tâches
   Dataset de cas réels, scoring (0/1/2), critères métier.

3. Evals de traces
   Vous notez la trace : l’agent a-t-il appelé le bon outil ? Au bon moment ? Avec les bons paramètres ?

Le gros avantage de l’évaluation trace : vous pouvez améliorer l’agent même quand la réponse finale “semble” correcte.

Replay : le superpouvoir des équipes qui shipent

Vous avez déjà vécu ça :

• “Ça a cassé chez un client.”
• “On n’arrive pas à reproduire.”
• “On patch au hasard.”

Replay = vous rejouez une exécution.

En pratique, ça demande de capturer :

• les inputs (message, contexte),
• les sources RAG (versionnées),
• les tool calls et leurs réponses (ou au moins des stubs),
• et la configuration (agent version, policies).

Ce n’est pas “déterministe” au sens strict (un LLM est probabiliste). Mais c’est suffisamment stable pour détecter des régressions : un outil appelé différemment, un paramètre manquant, un nouveau timeout, etc.

Si vous ne pouvez pas rejouer, vous ne pouvez pas faire de regression testing. Et si vous ne pouvez pas faire de regression testing, vous ne pouvez pas itérer vite sans casser.

Auto-grading vs humain : la vérité et le budget

En prod, vous finissez toujours avec un mix :

• humain pour les cas sensibles,
• auto-grading pour industrialiser,
• et audit périodique pour détecter les dérives.

Des frameworks comme Ragas documentent des approches d’évaluation orientées retrieval/RAG (utile quand vos agents reposent sur des sources).⁸

Méthode “10 jours” : bâtir un harness d’évaluation qui tient

Voici un plan simple. Pas “académique”. Fonctionnel.

Outillage : OpenAI tracing, OTel, LangSmith (et les limites)

Tracing SDK (provider-first)

L’OpenAI Agents SDK a une documentation dédiée au tracing.⁹

Point important : selon les politiques de rétention (ex. ZDR), certaines capacités de tracing peuvent être indisponibles.⁹

Traduction : l’observabilité est aussi une décision de gouvernance.

OpenTelemetry (standard)

OpenTelemetry vous donne :

• une sémantique de traces,
• un écosystème (collectors, exporters),
• et une interop avec vos services existants.³⁵

Plateformes d’observabilité LLM

LangSmith décrit des primitives de tracing et d’évaluation, avec une trace qui “capture le record complet”.¹⁰

Vous pouvez voir ces outils comme des “DevTools” de l’agentic. Pas comme une religion.

Shadow mode : tester en prod sans casser

Un pattern très utile pour les agents :

• l’agent tourne sur des cas réels,
• il produit une décision,
• mais il n’exécute pas l’action (ou il exécute en “dry-run”).

Vous comparez ensuite :

• ce que l’agent aurait fait,
• ce que l’humain a fait,
• et pourquoi ça diverge.

Le shadow mode transforme la prod en dataset. Sans transformer la prod en zone de guerre.

Taxonomie des erreurs : arrêter de mettre “ça bug” dans le même sac

Pour piloter, vous avez besoin d’une taxonomie.

Sinon, toutes les erreurs ressemblent à “le modèle est nul”, alors que :

• parfois, c’est un outil qui rate,
• parfois, c’est une donnée manquante,
• parfois, c’est un guardrail trop strict,
• parfois, c’est une régression de prompt.

Une taxonomie simple (qui marche) :

1. Data : source absente, doc non à jour, RAG bruité
2. Tool : 429/500/timeout, schéma invalide, permission refusée
3. Model : mauvaise décision, confusion, hallucination
4. Policy : action bloquée, sortie refusée, DLP
5. Infra : latence, queue saturée, dépendance down

Quand vous avez ça, vos dashboards deviennent actionnables. Sans ça, vous avez des graphiques jolis.

Avant de changer de modèle, changez de visibilité.

Dans 80% des cas, vos gains viennent de :

• meilleurs outils (contrats, erreurs, idempotence),
• meilleures sources (RAG gouverné),
• et meilleure boucle d’évaluation (replay + régressions).

Le modèle compte, oui. Mais l’observabilité décide si vous pouvez progresser sans casser.

C’est la base.

FAQ