Comment monitorer les agents IA en production

Le monitoring d'uptime ne suffit pas. Voici ce qu'il faut vraiment tracer, pourquoi les pannes des agents sont le plus souvent silencieuses, et quels outils le marché utilise aujourd'hui.

Pour CTO, VP Engineering et responsables IT · 12 min de lecture

Pourquoi monitorer un agent IA est différent

Le monitoring traditionnel repose sur un contrat simple : le système fonctionne ou il ne fonctionne pas. Un serveur est up ou down. Une API renvoie 200 ou 500. Les alertes se déclenchent, quelqu'un corrige.

Les agents IA cassent ce contrat. Un agent peut être pleinement disponible — pas de crash, pas de timeout, pas de code d'erreur — tout en produisant des réponses fausses, en appelant le mauvais outil, ou en inventant des informations. Du point de vue infrastructure, tout semble sain. Du point de vue utilisateur, l'agent est cassé.

Le problème des pannes silencieuses. Les plus gros incidents en production avec des agents ne lèvent pas d'exception. Ils ressemblent à : une réponse assurée mais factuellement fausse, un appel d'outil partiellement réussi, un workflow qui boucle jusqu'au timeout. Aucun de ces cas ne déclenche une alerte standard.

C'est pourquoi l'industrie IA a convergé vers un concept plus large que le monitoring : l'observabilité. L'objectif n'est pas seulement de savoir si l'agent tourne — c'est de comprendre ce qu'il fait, étape par étape, et s'il le fait correctement.

Que tracer : les cinq couches

Un agent IA en production génère plusieurs types distincts de télémétrie. Il vous faut tous — chaque couche révèle des pannes que les autres ne voient pas.

1. Traces

Une trace est l'enregistrement complet d'exécution d'une interaction agent : chaque étape, chaque décision, chaque appel d'outil, chaque sortie intermédiaire, avec horodatage. Pour un agent multi-étapes, une seule requête utilisateur peut déclencher des dizaines d'opérations internes. Sans traces, quand quelque chose tourne mal vous ne savez pas à quelle étape ni pourquoi.

Une bonne traçabilité : vous pouvez rejouer toute interaction passée telle qu'elle s'est déroulée, inspecter chaque étape isolément, et comparer le chemin d'exécution quand l'agent a bien fonctionné versus quand il a échoué.

2. Métriques de qualité

C'est ce qui sépare le monitoring IA du monitoring infrastructure. Il faut mesurer si les sorties de l'agent sont vraiment correctes — pas seulement rapides et disponibles.

• Taux de complétion de tâche — l'agent a-t-il accompli ce que l'utilisateur demandait ?
• Détection d'hallucination — l'agent a-t-il produit des affirmations non ancrées dans ses sources ou sorties d'outils ? Mesuré via évaluation automatisée "LLM-as-judge" sur un échantillon de trafic
• Qualité de sélection des outils — l'agent a-t-il appelé le bon outil, avec les bons paramètres ?
• Respect des instructions — l'agent a-t-il suivi son prompt système, les règles de format, les contraintes de politique ?
• Cohérence multi-tours — l'agent se contredit-il d'un tour de conversation à l'autre ?

3. Latence — par percentile, pas en moyenne

La latence moyenne masque le problème. Un agent multi-étapes peut répondre en 800 ms la plupart du temps, mais mettre 15 secondes pour les requêtes complexes. Les utilisateurs qui subissent ces 15 secondes génèrent les plaintes et le churn — la moyenne ne le montre jamais.

Suivez p50, p95 et p99. Le p99 (le 1 % des requêtes les plus lentes) définit la pire expérience utilisateur. Définissez des alertes sur p95 et p99, pas sur les moyennes.

4. Coût par requête

Les coûts en tokens ne sont pas uniformément répartis. Une petite proportion de requêtes représente souvent une part disproportionnée de votre budget LLM. Sans suivi du coût par requête, vous ne pouvez pas identifier quelles requêtes, workflows ou segments d'utilisateurs brûlent le budget — et vous ne pouvez pas optimiser.

Suivez le coût au niveau de la trace, ventilé par modèle, endpoint, et si possible par segment utilisateur ou type de workflow.

5. Dérive dans le temps

Un agent performant au lancement peut se dégrader en quelques semaines sans aucun changement de code. Causes possibles : évolution de la formulation des requêtes par les utilisateurs, dégradation de la qualité des données en amont, mises à jour des modèles chez le fournisseur, ou régressions subtiles de prompt après un déploiement. Sans suivi longitudinal de la qualité, la dérive reste invisible jusqu'à ce qu'elle soit sévère.

Exécutez des évaluations de qualité automatisées en continu sur un échantillon du trafic de production, et comparez les scores semaine après semaine. Une tendance à la baisse régulière est un signal d'agir avant que les utilisateurs ne s'en rendent compte.

À quoi ressemblent vraiment les pannes d'agents en production

Comprendre les modes de défaillance aide à configurer les bonnes alertes. Les pannes d'agents en production tendent à suivre quelques schémas récurrents :

Le mauvais outil, appelé avec assurance — L'agent choisit un outil plausible mais incorrect pour la tâche. L'appel réussit (pas d'erreur), il renvoie des données, et l'agent construit sa réponse dessus — données non pertinentes ou trompeuses. Toute la sortie en aval est fausse, mais rien dans les logs infrastructure ne le signale.

Boucles infinies — L'agent réessaie indéfiniment une opération en échec, ou continue à traiter une tâche déjà terminée. Cela consomme compute et budget tokens en silence, et peut corrompre les données par des opérations dupliquées. Définir des conditions de terminaison explicites et des coupe-circuits sur les boucles de retry.

Perte de contexte en conversations multi-tours — Sur des sessions longues, l'agent perd la trace des contraintes ou décisions prises plus tôt. Il se contredit ou ignore des instructions qu'il avait reconnues quelques tours avant. Difficile à détecter avec du monitoring par requête — visible seulement avec une analyse au niveau session.

Dérive de prompt après déploiement — Un changement de prompt qui semblait correct en test dégrade les performances sur une classe de requêtes de prod non représentée dans les tests. Cela se traduit par une baisse progressive des scores de qualité pour un type d'intention donné — détectable avec une évaluation par segment, invisible avec des métriques agrégées.

Les outils que le marché utilise aujourd'hui

L'écosystème d'observabilité pour les agents IA a mûri. OpenTelemetry s'est imposé comme standard pour collecter la télémétrie — neutre vis-à-vis des fournisseurs, donc vos données de trace restent portables. La plupart des frameworks majeurs (LangChain, CrewAI, OpenAI Agents SDK) émettent des traces compatibles OpenTelemetry nativement.

Au-dessus de cette base, plusieurs plateformes dédiées ont émergé :

• Langfuse (open-source, auto-hébergeable) : replay de traces complet, versioning des prompts, suivi des coûts, évaluations LLM-as-judge. Choix standard pour les équipes qui veulent la souveraineté des données et le contrôle total.

• Arize Phoenix (open-source, option cloud) : fort sur la détection de dérive et le monitoring des embeddings. Adapté aux équipes qui doivent suivre la dégradation au niveau modèle en plus du comportement des agents.

• LangSmith (écosystème LangChain) : intégration profonde pour les stacks LangChain/LangGraph. Visualisation du graphe d'exécution, comparaison de prompts, tests de régression sur jeux de données.

• Datadog LLM Observability (entreprise, full-stack) : connecte le monitoring IA à votre observabilité infrastructure existante. Idéal pour les équipes déjà sur Datadog qui veulent des tableaux de bord unifiés infra + agents.

Les quatre s'appuient sur OpenTelemetry comme source de données, donc vous n'êtes pas enfermé. Le choix pratique dépend de ce que vous priorisez : contrôle des données (Langfuse, Arize), adéquation écosystème (LangSmith), ou consolidation infra (Datadog).

Monitoring pour conformité et gouvernance

Pour les équipes dans les secteurs réglementés — finance, santé, juridique, RH — le monitoring n'est pas qu'opérationnel. Il est juridique.

Un agent IA qui influence des décisions (recommandation de prêt, présélection de candidat, réponse client) a besoin d'une piste d'audit qui permette de répondre : quelles entrées a reçues l'agent, quelles sorties a-t-il produites, quels outils a-t-il appelés, et quelle version de modèle tournait à ce moment ? Sans cela, vous ne pouvez pas répondre à une demande de conformité ou à un audit réglementaire.

Cela implique que l'infrastructure de monitoring doit capturer et stocker, de façon à détecter les altérations : logs complets entrées/sorties avec horodatage, version et configuration du modèle au moment de l'exécution, appels d'outils et leurs résultats, et tout événement d'approbation ou de contournement humain.

Ce que l'équipe Azure AI Foundry note : l'observabilité traditionnelle couvre métriques, logs et traces. L'observabilité des agents ajoute deux couches : les évaluations (l'agent a-t-il atteint le bon résultat ?) et la gouvernance (a-t-il opéré dans les contraintes de politique et de conformité ?). Les deux sont nécessaires en production dans les environnements réglementés.

Une configuration pratique pour commencer

Si vous instrumentez un agent en production pour la première fois, voici une séquence raisonnable sans des mois de travail infrastructure :

• Jour 1 : Traces. Instrumentez votre agent avec OpenTelemetry ou branchez-vous directement sur Langfuse. Chaque exécution doit générer une trace avec entrées, sorties, appels d'outils et latence par étape. Cela seul vous donne la capacité de déboguer les pannes.

• Semaine 1 : Tableaux de bord latence et coût. Mettez en place le suivi du coût par requête et le monitoring de latence p95/p99. Définissez des alertes sur les anomalies de coût (pics soudains de consommation de tokens) et sur les régressions de latence après déploiements.

• Semaine 2 : Évaluations de qualité. Définissez 3 à 5 critères d'évaluation spécifiques à votre cas d'usage (pertinence, ancrage factuel, respect des politiques). Exécutez-les automatiquement sur un échantillon du trafic de production. Établissez un score de référence.

• Mois 1 : Monitoring de la dérive. Comparez les scores de qualité semaine après semaine. Ajoutez des ventilations par segment (type d'intention, segment utilisateur, workflow) pour détecter les régressions invisibles dans les métriques agrégées.

• Au fil du temps : Piste d'audit. En contexte réglementé, assurez-vous que les logs sont stockés avec le contexte de version (modèle, hash du prompt, config) et accessibles pour revue de conformité.

Monitoring intégré, pas ajouté après coup

Origin 137 intègre traces, tableaux de bord de coût et observabilité de la qualité en natif — pas besoin d'instrumentation séparée. Chaque exécution d'agent est enregistrée avec une piste d'audit complète dès le premier jour.

Commencer gratuitement — sans carte requise

Sources

• OpenTelemetry, AI Agent Observability: Evolving Standards and Best Practices, 2025
• Microsoft Azure, Agent Factory: Top 5 agent observability best practices, Sept. 2025
• UptimeRobot, AI Agent Monitoring: Best Practices, Tools and Metrics, 2026
• Stack AI, The Complete Guide to AI Agent Observability and Monitoring, 2025
• Vellum, Understanding your agent's behavior in production, Sept. 2025