Les métriques disent qu’il y a un problème ; la trace dit pourquoi. L’observation boucle avec le test pour améliorer l’agent en continu.
À retenir avant de commencer
Un agent qui tourne sans observation est une boîte noire : on découvre les problèmes quand un client les signale. La production doit commencer avec un minimum de visibilité (quatre métriques, une trace par exécution, des seuils d’alerte), par exemple : taux d’erreur au-delà de 3 % sur une journée, latence moyenne qui double, coût quotidien qui dépasse le budget fixé, ou validation humaine refusée plus d’une fois sur cinq.
L’observation remplit trois missions : corriger vite, justifier le budget et améliorer l’agent sur des faits plutôt que sur des impressions.
Quatre métriques de base
Quatre mesures suffisent pour commencer :
- Le volume et les erreurs : combien de demandes, combien d’échecs, combien de garde-fous déclenchés. Microsoft documente le monitoring des modèles Azure OpenAI avec métriques, logs et alertes ; le même principe s’applique à tout agent. [55]
- Le coût : les appels de modèles sont facturés à chaque exécution ; sans suivi, la facture surprend. OpenAI documente le comptage de tokens pour mesurer précisément la consommation. [56]
- La latence : le temps de réponse perçu par les utilisateurs, car un agent lent est abandonné. Les traces mesurent la durée de chaque étape. [51]
- L’usage : quelles demandes, quels utilisateurs, quels outils, pour savoir ce qui sert vraiment.
La trace : le « pourquoi »
Les métriques disent qu’il y a un problème ; la trace dit pourquoi. Une trace est la séquence complète d’exécution d’une demande : les appels au modèle, les outils utilisés, les décisions prises, les garde-fous déclenchés. LangSmith formalise l’idée avec les spans : chaque étape de l’exécution devient un segment tracé, avec ses entrées, sorties et durées : une inspection fine des trajectoires réussies et échouées. [51]
Arize Phoenix pousse la même approche en open source : construit sur OpenTelemetry, il reçoit les traces au format standard et s’instrumente sur les frameworks et fournisseurs courants (OpenAI, Anthropic, Bedrock, LangChain). [52]
Pour une PME, la trace répond à la question essentielle (« pourquoi l’agent a-t-il fait ça ? ») au moment où ça compte.
Le tableau de bord de l’agent
Ce tableau de bord minimal montre un agent en production. Clique sur « Simuler une journée » pour voir comment les alertes fonctionnent.
Interaction-signature
Le tableau de bord de l’agent
Lance une journée simulée pour suivre une alerte jusqu’à sa correction.
Lire le tableau
- Erreurs 24 h : les échecs et refus. Une hausse soudaine mérite une trace.
- Coût / jour : la facture des appels. Une hausse régulière = un volume qui dérive.
- Latence p95 : le temps ressenti par l’utilisateur dans 95 % des cas.
- Demandes / jour : le volume réel, la base de toutes les autres mesures.
Les standards existent
L’observabilité des agents n’est plus à inventer : elle s’appuie sur des standards. OpenTelemetry a publié des conventions sémantiques spécifiques pour les applications à base de modèles (LLM, embeddings, vector stores, agents), avec des noms de champs communs pour mesurer partout pareil. [50]
Des plateformes comme Weights & Biases Weave documentent le suivi des exécutions d’agents avec des évaluations intégrées, et acceptent les traces OpenTelemetry sans SDK supplémentaire. [53] Microsoft intègre le monitoring dans ses tableaux de bord Azure AI avec des métriques prêtes à l’emploi. [55]
Pour une PME, l’essentiel dès le premier jour : les quatre métriques et la possibilité de remonter d’une alerte à la trace correspondante, quel que soit l’outil.
Ce que l’observation déclenche
Les données ne servent à rien si elles ne déclenchent rien. Trois boucles simples :
- Erreurs au-dessus du seuil → ouvrir la trace, corriger, rejouer la grille de tests de l’article précédent.
- Coût qui dérive → vérifier le volume et la consommation de tokens par appel ; Anthropic documente le comptage de tokens pour comprendre où part la consommation. [54]
- Latence qui explose → vérifier les étapes lentes de la trace, simplifier le parcours.
L’observation boucle avec le test : chaque incident en production devient un scénario de plus dans la grille de passage, et c’est ainsi qu’un agent s’améliore en continu.
Le résumé utile
Quatre métriques suffisent pour commencer : volume et erreurs, coût, latence, usage.
La trace explique le « pourquoi » : la séquence complète d’exécution d’une demande.
Des standards existent (OpenTelemetry GenAI, plateformes d’observabilité) ; inutile d’inventer.
L’observation boucle avec le test : chaque incident devient un scénario de régression.
Dernier article de la série : comment déployer un agent 24/7, et s’en sortir quand ça casse la nuit.