Superviser des agents en production : quoi journaliser, quoi alerter
Un service classique est en bonne santé s'il répond vite et ne lève pas d'erreurs. Un agent peut faire les deux et se tromper complètement : chaque requête répondue en deux secondes, et toutes citant une politique retirée en mars.
Superviser des agents est donc une autre discipline. Elle repose sur deux choses : une trace par exécution assez détaillée pour reconstituer ce qui s'est passé, et une poignée de métriques de comportement dont le mouvement signifie quelque chose. Le reste est de la décoration.
Ce que contient une trace utile#
- Un identifiant d'exécution sur chaque ligne de log, chaque appel et chaque requête sortante.
- Le contexte exact envoyé au modèle à chaque étape, ou une empreinte et les parties assemblées.
- Chaque appel d'outil avec arguments, résultat, durée et issue.
- Nom et version du modèle par appel, plus le décompte de tokens.
- La raison d'arrêt : terminé, plafond d'étapes, plafond de dépense, porte humaine, erreur.
- La sortie finale et si quelqu'un l'a corrigée ou annulée ensuite.
Six métriques qui bougent vraiment#
| Métrique | À surveiller | Signifie souvent |
|---|---|---|
| Taux de réussite | Baisse durable | Changement de modèle, dérive de données, API modifiée |
| Étapes par exécution | Hausse lente | Erreurs d'outil réessayées ; recherche dégradée |
| Erreurs par outil | Pic sur un outil | Système amont cassé, pas l'agent |
| Intervention humaine | Hausse | La confiance baisse ou nouvelle catégorie |
| Affirmations non étayées | Toute hausse | La recherche échoue en silence |
| Coût par tâche | Hausse à volume constant | Contexte gonflé ou reprises |
Alertez sur le comportement, pas seulement sur les erreurs#
Un agent échoue rarement bruyamment. Il se dégrade : un peu plus d'étapes, un peu plus de reprises, un peu plus d'escalades, et un matin il répond avec des documents périmés. Alertez sur le rythme de changement en fenêtre glissante plutôt que sur des seuils absolus. Et joignez à chaque alerte la trace d'une exécution représentative ; une alerte inexploitable finit muette.
Échantillonnez et lisez de vraies exécutions, chaque jour#
Aucun tableau de bord ne remplace la lecture. Choisissez chaque jour quelques exécutions — des succès, toutes les escalades, toutes celles au plafond — et lisez-les en entier. Chaque problème sérieux que nous avons trouvé en production était visible dans une trace avant de l'être dans une métrique. Faites tourner qui lit : la personne qui a écrit le prompt est la moins susceptible de voir ce qu'il fait de travers.
Ajoutez le jour même au jeu d'évaluation tout ce qui surprend. Cette habitude transforme la supervision en amélioration.
Journaliser sans collecter ce qu'il ne faut pas#
Les traces contiennent par construction des données clients. Masquez les identifiants au moment de la journalisation, donnez aux contextes complets une rétention plus courte qu'aux métriques et soumettez les arguments d'outils aux mêmes contrôles d'accès que le système sous-jacent.
Questions fréquentes
Combien de temps garder les traces complètes ?
Assez pour déboguer et auditer : souvent 30 à 90 jours pour les contextes complets, tandis que métriques et résumés durent bien plus. Décidez-le volontairement : c'est ce que vos utilisateurs ont écrit.
Quelle est l'alerte la plus utile ?
Une hausse des escalades ou des corrections humaines. C'est le signal honnête le plus précoce de dérive et il ne demande aucun étiquetage.
Faut-il un outil d'observabilité dédié ?
Pas pour commencer. Une table de traces interrogeable couvre l'essentiel. Les outils dédiés aident quand comparer des exécutions et versionner des prompts devient un travail quotidien à plusieurs.
supervision d'agentsobservabilité llmtraces d'agentsmétriques ia productiondérive d'agent
