L'équipe Foundry de Microsoft a ajouté le traçage basé sur OpenTelemetry à son framework d'agents, offrant ainsi aux développeurs un moyen de visualiser l'exécution de bout en bout à travers des agents hétérogènes alimentés par des LLM.

Pourquoi les systèmes multi-agents ont besoin de plus que de simples fichiers journaux

Un exercice typique de réponse aux incidents piloté par l'IA utilise un agent « commandant » qui orchestre plusieurs agents spécialistes : l'un analyse les journaux, un autre détecte les anomalies de métriques, un troisième fait correspondre les symptômes aux guides d'intervention (runbooks), et un routeur choisit le meilleur modèle de langage pour chaque sous-tâche. Chaque spécialiste peut appeler un modèle différent — par exemple, une variante « gpt-5-mini » — et invoquer ses propres outils. En cas de problème, les ingénieurs se retrouvent face à des journaux isolés qui montrent ce que chaque composant a fait, mais sans aucune vue d'ensemble de la manière dont les éléments s'articulent.

Sans un traçage unifié, la cause racine se cache dans le passage de relais entre les agents. Le commandant peut envoyer une requête que le lecteur de journaux traite correctement, mais le spécialiste des métriques interprète mal les données et suggère le mauvais guide d'intervention. Déboguer cette chaîne manuellement prend du temps et favorise les erreurs.

Comment OpenTelemetry assemble le flux de travail

OpenTelemetry définit deux concepts fondamentaux : les traces et les spans. Une trace est un identifiant unique qui suit une requête de son entrée jusqu'à la réponse finale. Un span enregistre une opération unique — telle qu'un appel à un modèle de langage ou une invocation d'outil — au sein de cette trace.

Lorsqu'un agent reçoit une requête, il extrait l'ID de trace (Trace ID) entrant des métadonnées de la requête et crée un span enfant qui hérite du même ID. Le span enfant enregistre son heure de début, sa durée, ses attributs (nom du modèle, outil utilisé) et toutes les erreurs éventuelles. Le processus se répète pour chaque agent en aval, construisant un arbre qui reflète le flux logique de la tâche globale.

OpenTelemetry prend également en charge le Baggage, un support léger pour des paires clé-valeur personnalisées. En attachant un « drill-id » ou un autre contexte métier au baggage au sommet de la trace, chaque span en aval hérite automatiquement de cet identifiant. Un processeur de spans transforme ensuite le baggage en attributs réguliers, ce qui permet de requêter facilement tous les spans appartenant à un exercice d'incident particulier.

À quoi ressemble la nouvelle interface de traçage

Avec l'instrumentation en place, Azure Monitor (ou tout backend compatible OpenTelemetry) affiche une hiérarchie visuelle :

  • Nom / ID de l'agent – indique quel composant a effectué l'opération.
  • Utilisation des outils – enregistre quel service externe ou quelle fonction a été appelée.
  • Version du modèle – consigne le LLM exact utilisé, ce qui est utile pour suivre les régressions après une mise à niveau du modèle.
  • Consommation de tokens – capture le nombre de tokens envoyés au modèle et reçus de celui-ci, aidant les équipes à gérer les coûts.
  • Latence / durée – met en évidence l'apparition de goulots d'étranglement, que ce soit lors de l'inférence du modèle ou des entrées/sorties (I/O) des outils.

Dans l'exemple de l'exercice d'incident, le span racine du commandant génère des spans enfants pour chaque spécialiste, et chaque spécialiste génère d'autres enfants pour ses appels de modèle. Cliquer sur n'importe quel nœud révèle l'ensemble complet des attributs, permettant à un ingénieur de voir instantanément les détails de chaque opération.

Les enjeux pour les opérations centrées sur l'IA

  • Rapidité de l'analyse de la cause racine – Les équipes remontent une défaillance jusqu'au span exact qui a généré une erreur, réduisant ainsi le temps moyen de résolution.
  • Visibilité des coûts – Le nombre de tokens est affiché à côté de la latence, permettant aux services financiers de repérer une utilisation excessive avant que les factures cloud ne s'envolent.
  • Optimisation des performances – Les spans à haute latence entre les agents indiquent où la mise en cache, la sélection du modèle ou la refonte des outils pourraient améliorer le débit.

À surveiller ensuite

Les projets basés sur LangChain, l'OpenAI SDK ou d'autres couches d'orchestration peuvent adopter les mêmes conventions sémantiques pour la GenAI, ouvrant la voie à des traces circulant entre les fournisseurs de cloud et les déploiements sur site (on-premise).

Les organisations n'ont qu'à activer l'OpenTelemetry SDK dans leurs agents et envoyer les données vers Azure Monitor ou un collecteur open-source.

À retenir

OpenTelemetry apporte aux systèmes d'IA multi-agents le lien manquant qui transforme un éparpillement de journaux en un récit cohérent. En propageant un identifiant de trace (Trace ID) unique à travers des LLM hétérogènes, des routeurs et des appels d'outils, les développeurs peuvent localiser les défaillances, surveiller les coûts et optimiser les performances sans avoir à réinventer l'infrastructure de traçage.