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.
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.