Surveiller un agent IA : traces, journaux et alertes

Surveiller un agent IA en production consiste à relier ses actions, ses erreurs, ses délais et ses dépenses au résultat réellement obtenu. Les journaux enregistrent les événements, les traces reconstituent les étapes d’une tâche et les métriques déclenchent des alertes lorsque le service se dégrade. Une surveillance utile vérifie aussi la qualité des résultats et les effets des actions, sans enregistrer inutilement des données sensibles.

Partir du résultat métier, pas du tableau de bord

Un agent peut répondre sans erreur technique tout en accomplissant mal sa mission. Un appel au modèle aboutit, un outil accepte la requête, puis la réponse finale annonce un résultat que le système métier ne confirme pas. Une supervision limitée à la disponibilité des API laisserait passer cet échec.

Définissez donc ce que signifie réussir une tâche avant de choisir vos graphiques. Pour un agent de traitement de tickets, cela peut être une proposition correctement enregistrée et validée selon les règles prévues. Pour un agent documentaire, ce sera une réponse étayée par des sources accessibles et pertinentes.

Distinguez plusieurs issues : tâche réussie, échec technique, refus prévu, transfert à une personne, abandon et résultat indéterminé. Un refus conforme aux permissions ne constitue pas nécessairement une panne. Inversement, un message final affirmant que tout est terminé ne prouve pas la réussite.

L’observabilité des LLM sert à expliquer ces résultats à partir des opérations enregistrées. Elle complète le guide pour évaluer un agent IA, qui détaille la construction des jeux de tests et des critères de qualité.

Précisez enfin qui utilise chaque information. L’exploitation doit repérer les tâches bloquées ; le responsable métier doit connaître les résultats incomplets ; la personne chargée de la sécurité doit pouvoir retrouver une action sensible. Un tableau unique, rempli de toutes les données disponibles, répond rarement bien à ces besoins distincts.

Articuler journaux, traces, métriques et audit

Ces signaux répondent à des questions différentes. Les conserver dans une même plateforme peut simplifier les recherches, mais ne rend pas leurs fonctions interchangeables.

Signal	Ce qu’il représente	Utilité principale	Limite
Journal	Un événement daté et contextualisé	Examiner une erreur ou un changement d’état	La succession des événements peut rester ambiguë
Trace	Les opérations reliées à une exécution	Retrouver l’étape responsable d’un délai ou d’un échec	Une instrumentation incomplète laisse des zones aveugles
Métrique	Une mesure agrégée dans le temps	Détecter une dérive et comparer des périodes	Elle masque les détails des cas individuels
Journal d’audit	Une action sensible et son contexte d’autorisation	Établir qui pouvait agir et quel effet a été constaté	Il exige des contrôles d’accès et d’intégrité adaptés

Dans une trace, une opération délimitée s’appelle un span. Elle possède notamment un début, une fin et des liens avec d’autres opérations. La documentation des traces explique ce modèle et les relations entre opérations.

Utilisez un identifiant d’exécution pour passer d’un signal aux autres. Une alerte doit permettre d’ouvrir des traces représentatives, puis les journaux associés, sans chercher manuellement une conversation entière.

Séparez toutefois l’identifiant métier de l’identifiant technique. Une même demande peut connaître plusieurs tentatives, reprises ou traitements différés. Les confondre fausserait les statistiques et compliquerait la recherche d’une action exécutée plusieurs fois.

Instrumenter la tâche entière et chaque action utile

Commencez par une opération englobant la tâche, puis ajoutez des opérations pour les appels au modèle, les recherches documentaires, les validations et chaque appel d’outils. L’objectif est de retrouver le chemin suivi et les dépendances, sans transformer chaque fonction interne en événement.

Pour chaque exécution, prévoyez au minimum :

l’identifiant de tâche, de tentative et de trace ;
l’environnement et la révision du déploiement ;
la révision des instructions et de la configuration ;
le modèle demandé et, si disponible, le modèle effectivement utilisé ;
les horodatages, le statut final et le motif d’arrêt ;
les consommations rapportées et les références des effets métier.

Pour un outil, distinguez la demande d’action, le contrôle d’autorisation, le départ de la requête et le résultat constaté. Une écriture acceptée par une API peut encore nécessiter une vérification dans le système cible.

Les attributs GenAI documentés par OpenTelemetry fournissent un vocabulaire pour décrire notamment modèles, usages et opérations. Vérifiez leur prise en charge par votre instrumentation avant de construire des tableaux de bord dépendant de champs précis.

Soignez surtout les frontières : file d’attente, processus séparé, sous-agent et service distant. Transmettez le contexte de corrélation par un mécanisme maîtrisé. Une reprise peut produire une nouvelle trace, mais elle doit conserver un lien explicite avec la tâche initiale.

Ne cherchez pas à déduire un raisonnement interne à partir des commentaires produits par le modèle. Les éléments vérifiables sont les entrées autorisées, les appels, les résultats et les effets observés.

Mesurer disponibilité, délais, coûts et qualité

Organisez les indicateurs autour de questions opérationnelles. Le service accepte-t-il les demandes ? Les termine-t-il à temps ? Les résultats sont-ils corrects ? Les ressources consommées restent-elles compatibles avec le budget ?

Pour les délais, distinguez l’attente avant traitement, le temps d’exécution et le délai jusqu’au résultat utilisable. Une réponse initiale rapide peut cacher une longue attente avant l’action attendue. Examinez aussi les cas les plus lents : la moyenne seule peut masquer une dégradation concentrée sur certaines tâches.

Pour la fiabilité, suivez les échecs définitifs, les reprises, les tâches sans état final et les dépendances indisponibles. Rapportez chaque taux à un dénominateur explicite. Les tâches reçues, commencées et terminées ne représentent pas la même population.

Pour les coûts, additionnez les appels de toutes les tentatives, les services facturés à l’usage et les évaluations automatisées. Calculez un coût par tâche terminée et un coût par tâche réussie. Un parcours peu cher par appel peut devenir coûteux lorsqu’il multiplie les reprises.

Enfin, distinguez qualité mesurée et simple signal :

une validation de schéma confirme la structure ;
une vérification métier confirme un état attendu ;
une appréciation humaine juge un résultat selon une grille ;
un modèle évaluateur produit une estimation susceptible d’erreur.

Conservez la méthode et sa révision avec chaque évaluation. Un changement de grille peut déplacer les scores sans changement de comportement de l’agent.

Construire des alertes qui entraînent une action

Une alerte utile indique un problème, son impact, un responsable et une procédure de réponse. Une notification signalant seulement une hausse de consommation, sans préciser le périmètre concerné, transfère tout le diagnostic à la personne qui la reçoit.

Les bonnes pratiques d’alerte recommandent de privilégier les symptômes affectant les utilisateurs et d’éviter les notifications sans action possible. Pour un agent, cela conduit à surveiller les tâches non terminées, les résultats invalides et les dérives de dépenses, au-delà des seules exceptions techniques.

Situation	Signal à observer	Réponse prévue
Demandes qui s’accumulent	Âge des tâches en attente et délai global	Examiner la capacité et limiter les nouvelles admissions
Boucle sans progrès	Actions répétées et absence de changement utile	Arrêter la tâche et conserver les éléments de diagnostic
Dépense anormale	Consommation cumulée et vitesse de dépense	Appliquer un plafond ou suspendre le périmètre concerné
Action sensible inattendue	Autorisation absente ou effet incompatible	Bloquer les écritures concernées et ouvrir un incident
Dégradation des résultats	Échecs métier et évaluations concordantes	Examiner le dernier changement et réduire l’exposition

Fixez les seuils à partir des engagements du service, de ses périodes habituelles et du risque acceptable. Une même durée ne convient pas à une conversation interactive et à un traitement documentaire différé.

Regroupez les alertes liées au même incident. Prévoyez une durée de confirmation pour les fluctuations ordinaires, tout en traitant immédiatement les événements qui nécessitent une intervention.

L’alerte ne remplace pas un garde-fou : le plafond de dépense, la limite d’étapes et l’autorisation d’écriture doivent être appliqués pendant l’exécution.

Choisir une plateforme selon les informations manquantes

Une plateforme spécialisée facilite la lecture des parcours et leur rapprochement avec les évaluations. Elle doit compléter la supervision de vos serveurs, files d’attente et services métier. Le répertoire des outils IA permet de situer ces solutions parmi les autres briques d’exploitation.

Voici des capacités documentées dans les sources officielles consultées pour cette page, sans classement de performance.

Solution	Parcours et traces	Évaluation	Point à vérifier pour votre usage
Langfuse	Observations imbriquées, consommations et délais	Scores, jeux de données et expériences	Collecte autorisée, hébergement et organisation des projets
LangSmith	Traces d’agents et suivi de production	Évaluations en ligne et analyse des parcours	Intégrations utilisées et conditions de déploiement
Arize Phoenix	Instrumentation fondée sur OpenTelemetry et OpenInference	Jeux de données, évaluations et expériences	Exploitation de l’instance et compatibilité de l’instrumentation

La documentation de Langfuse, la présentation officielle de LangSmith Observability et le dépôt officiel de Phoenix décrivent ces fonctions. Elles ne démontrent pas leur pertinence pour votre charge.

Comparez les offres sur un parcours représentatif : branche parallèle, reprise après interruption, appel échoué et contenu masqué. Vérifiez aussi l’export des données et la capacité à supprimer une exécution.

Le coût total comprend l’ingestion, le stockage, la conservation, les évaluations et l’exploitation. Un abonnement d’entrée ne suffit donc pas à comparer deux architectures.

Limiter les données collectées et maîtriser leur conservation

Une trace peut contenir une demande privée, un document récupéré, une réponse d’outil ou une information d’authentification. Elle crée ainsi une copie supplémentaire de données qui étaient auparavant dispersées entre plusieurs services.

Définissez une liste de champs autorisés. Collectez d’abord les métadonnées nécessaires au diagnostic ; ouvrez la collecte de contenu uniquement pour un besoin explicite. Une référence de document, sa révision et le résultat d’un contrôle peuvent suffire sans copier son texte intégral.

Appliquez le filtrage avant l’export. La documentation du masquage de Langfuse décrit cette possibilité et précise que le traitement d’un exporteur ne nettoie pas nécessairement les données envoyées par un autre.

Contrôlez donc aussi les exceptions, pièces jointes, noms d’opérations et journaux de secours. Un champ principal masqué ne protège pas une copie conservée ailleurs.

Séparez les accès par environnement et par responsabilité. Définissez des durées de conservation selon l’usage : diagnostic courant, audit d’actions sensibles et exemples destinés aux évaluations n’ont pas nécessairement les mêmes besoins. L’auto-hébergement laisse ces décisions à votre charge.

Le guide pour sécuriser un agent IA couvre les permissions et secrets. L’article sur les agents IA et les données personnelles complète cet inventaire des flux.

Déployer la surveillance par étapes vérifiables

Les prérequis sont organisationnels autant que techniques : un responsable du service, une définition de la réussite, un environnement d’essai et un accès contrôlé aux résultats métier. Sans ces éléments, vous collecterez des données sans pouvoir trancher les incidents.

Définissez les états et identifiants. Documentez les issues possibles, la distinction entre tâche et tentative, puis les liens attendus entre événements.
Tracez un parcours complet. Faites apparaître réception, attente, appels, contrôles, effets et état final. Vérifiez aussi une interruption.
Ajoutez les mesures essentielles. Volume, délais, issues, reprises et consommation doivent pouvoir être rapprochés des exécutions sources.
Appliquez les règles de collecte. Utilisez des données fictives reconnaissables pour vérifier ce qui arrive effectivement dans chaque destination.
Déclenchez les alertes en essai. Simulez une dépendance indisponible, une tâche bloquée et un plafond atteint. Vérifiez réception et procédure.
Ouvrez progressivement le trafic. Comparez le périmètre exposé avec un parcours de référence et conservez un retour arrière possible.

Éprouvez également la panne du collecteur. Une indisponibilité de la plateforme d’observabilité ne doit pas bloquer accidentellement tout le service. Pour les actions dont l’audit est obligatoire dans votre politique, définissez explicitement si elles restent autorisées lorsque l’enregistrement échoue.

Mesurez la surcharge de collecte : mémoire, files d’export et latence. L’envoi asynchrone réduit le couplage, mais ne rend pas l’instrumentation gratuite.

Échantillonner sans effacer les incidents

Conserver tous les contenus de toutes les exécutions augmente le volume stocké et l’exposition des données. L’échantillonnage permet de limiter les traces détaillées, à condition de savoir quelles conclusions restent possibles.

Vous pouvez sélectionner une partie des exécutions ordinaires et appliquer une politique distincte aux erreurs ou aux parcours sensibles. Une sélection fondée sur le résultat final suppose toutefois de conserver temporairement assez d’informations pour prendre cette décision.

Ne calculez pas le taux global d’échec à partir d’un ensemble enrichi volontairement en erreurs. Utilisez des compteurs couvrant l’activité complète pour les métriques générales, puis les traces sélectionnées pour expliquer les cas.

La surveillance doit elle-même laisser des preuves de fonctionnement. Suivez les rejets à l’ingestion, les échecs d’export, les données abandonnées et le retard d’arrivée. Une baisse des traces peut signifier une baisse du trafic ou une panne de collecte.

Enfin, ne laissez pas l’échantillonnage ordinaire supprimer les événements d’audit que votre politique exige de conserver. Traces de diagnostic et preuves d’actions sensibles demandent des règles distinctes.

Problèmes fréquents et réponse aux incidents

Les appels apparaissent sans lien entre eux. Recherchez une perte du contexte à la sortie d’une file ou d’un processus. Vérifiez aussi que les tâches parallèles ne réutilisent pas un contexte devenu incorrect.

La consommation reste incomplète. Distinguez valeur indisponible et consommation nulle. Examinez les reprises, les interruptions de diffusion et les appels effectués hors de l’instrumentation principale.

Le tableau indique une réussite, mais l’action manque. Remplacez le statut fondé sur le texte final par une vérification de l’état cible. Conservez séparément l’affirmation de l’agent et le résultat constaté.

Les traces sont présentes en double. Plusieurs couches peuvent instrumenter le même appel. Identifiez qui crée chaque opération avant d’additionner les durées ou les consommations.

Lors d’un incident, commencez par limiter les effets : suspendre les écritures concernées, arrêter les boucles ou rediriger les demandes. Préservez ensuite les traces utiles et les révisions de configuration.

Construisez une chronologie reliant demande, autorisation, action et état final. Ne rejouez pas directement une trace susceptible d’envoyer un message ou de modifier un enregistrement. Après correction, transformez le cas en test de régression expurgé et vérifiez aussi que l’alerte aurait permis de détecter le problème.

Checklist avant l’ouverture en production

La réussite est vérifiée dans le système métier.
Chaque tentative est reliée à sa tâche et à ses opérations.
Les reprises, attentes et interruptions restent visibles.
Les coûts inconnus sont distingués des coûts nuls.
Les contenus sensibles sont filtrés avant chaque export.
Les alertes désignent un responsable et une action.
Les plafonds et arrêts fonctionnent sans dépendre des notifications.
La panne de collecte et le retour arrière ont été éprouvés.
Les incidents utiles alimentent des tests de régression.

Pages liées

Questions fréquentes

Quelle différence entre supervision et observabilité d'un agent IA ?

La supervision vérifie des conditions prévues, comme une tâche bloquée ou un budget dépassé. L'observabilité fournit aussi les éléments nécessaires pour enquêter sur un comportement inattendu. Les deux se complètent dans l'exploitation quotidienne.

Faut-il enregistrer tous les prompts en production ?

Non. Vous pouvez commencer par les métadonnées, les durées, les statuts et les consommations, puis autoriser une collecte ciblée de contenus expurgés. Cette décision dépend des données traitées et du besoin de diagnostic.

Peut-on surveiller un agent sans plateforme spécialisée ?

Oui, avec des journaux structurés, des métriques et des traces dans votre infrastructure existante. Une plateforme spécialisée facilite surtout la lecture des échanges avec le modèle et leur rapprochement avec des évaluations. Vérifiez d'abord les informations qui vous manquent réellement.

Une trace permet-elle de reproduire exactement une exécution ?

Elle documente les opérations enregistrées, mais ne garantit pas une reproduction identique. Le modèle, les données consultées et l'état des services externes peuvent avoir changé. Rejouer une action d'écriture exige donc un environnement isolé et des effets externes neutralisés.

Comment mesurer la qualité d'un agent après son déploiement ?

Associez des contrôles sur les résultats métier, une revue humaine d'exécutions sélectionnées et des évaluations automatisées. Conservez une catégorie indéterminée lorsque les preuves manquent. Un score automatique doit rester accompagné de sa méthode et de ses limites.

Surveiller un agent IA en production : journaux, traces, alertes, outils d'observabilité