Tracer un agent de l’utilisateur au résultat métier avec OpenTelemetry

Une trace limitée à l’appel du modèle répond à « combien de temps la génération a-t-elle pris ? ». Elle ne permet pas de savoir quel utilisateur a déclenché l’agent, quel outil a été appelé, quelle autorisation a été utilisée, si une reprise a eu lieu ou si le résultat métier a abouti.

Définir une chaîne de corrélation

Le même contexte doit traverser les frontières du système : requête utilisateur, AI Gateway, orchestrateur d’agent, modèle, outil MCP ou API métier, ressource Azure et résultat final. OpenTelemetry fournit les traces et spans ; l’architecture doit décider quels identifiants et attributs sont propagés.

Parmi les dimensions utiles figurent l’identifiant de requête, le produit, l’environnement, l’agent, la version du prompt, le modèle, l’outil, le résultat, le nombre de tentatives et la catégorie d’erreur. Les identités doivent être représentées par des références contrôlées plutôt que par des données personnelles brutes.

Distinguer observation et contenu sensible

Journaliser intégralement prompts, réponses et arguments d’outils peut exposer des secrets, des données personnelles ou des documents confidentiels. Une stratégie de télémétrie doit définir la minimisation, le masquage, l’échantillonnage, la durée de conservation et les accès. Dans certains contextes, un hash, une classe de contenu et des métriques suffisent à établir la preuve sans conserver le texte.

Prouver que la corrélation fonctionne

La présence d’un SDK OpenTelemetry dans le code n’est pas une preuve. Un scénario de test doit partir d’une requête connue, provoquer un appel d’outil et vérifier que les éléments attendus sont retrouvables dans le backend d’observabilité. Une rupture de contexte entre APIM et l’application, ou entre l’agent et l’outil, doit produire un échec visible.

Relier la technique à l’issue métier

Le dernier span ne devrait pas simplement indiquer « réponse générée ». Il doit, lorsque le processus le permet, enregistrer une issue : dossier créé, vérification terminée, commande refusée, approbation requise ou tâche abandonnée. Cette dimension permet ensuite de distinguer le coût d’un appel du coût d’un résultat réellement obtenu.

Actifs de méthode associés : AI Gateway Validation Kit et Azure Agent Runtime Golden Path. Le premier vérifie l’existence d’une preuve corrélée ; le second fournit le chemin instrumenté avec APIM, Application Insights et une observabilité LLM optionnelle.

Une preuve exploitable par plusieurs équipes

La plateforme utilise la trace pour diagnostiquer, la sécurité pour enquêter, le produit pour mesurer l’issue et le FinOps pour attribuer le coût. Un schéma commun évite quatre systèmes d’observation contradictoires et rend la décision de production beaucoup plus défendable.

Vérifier ce point dans votre environnement

Ce que cela change à l’échelle d’un grand compte

• L’explicabilité a un délai. « Que s’est-il passé hier soir ? » doit avoir une réponse en minutes. Ce délai — pas le volume de télémétrie — est la métrique d’une observabilité utile.
• La conformité se joue dans les attributs. Identités en références contrôlées, contenus sensibles minimisés : une trace bien conçue est montrable à un auditeur ; une trace bavarde devient elle-même un risque.
• La corrélation se conçoit, elle ne se rattrape pas. L’observabilité ajoutée après l’incident observera le prochain incident. Le contexte propagé doit faire partie du contrat d’architecture initial.

Frontière de preuveNote de conception. Ce texte décrit un modèle de corrélation OpenTelemetry et les arbitrages associés ; il n’est pas la mesure d’un système client en production. Les dimensions proposées sont un point de départ à adapter à votre pile et à vos contraintes de confidentialité.