L'observabilité des agents IA est le processus de captation et d'évaluation de l'activité en continu afin de suivre, mesurer et comprendre comment un agent IA prend ses décisions et agit. Elle indique si l'agent a abouti au résultat attendu et quelle étape a provoqué l'échec, et pas seulement si l'exécution a renvoyé une réponse.
La supervision des agents IA fonctionne de trois manières :
- Application performance monitoring (APM) : Surveille l'infrastructure sur laquelle l'agent s'exécute et rapporte la latence et le taux d'erreur.
- Observabilité des LLM : Elle journalise chaque appel de modèle, en enregistrant le prompt envoyé et la complétion renvoyée pour chacun d'eux
- Observabilité des agents : Enregistre l'ordre dans lequel l'agent a pris ses décisions, de sorte qu'un échec à une étape puisse être rattaché à l'étape qui l'a provoqué.
Pourquoi la supervision traditionnelle échoue-t-elle avec les agents ?
La supervision traditionnelle repose sur la surveillance de l'infrastructure et la journalisation des appels de modèle un par un ; elle ne fonctionne pas pour les agents IA, car elle enregistre chaque étape isolément. Les agents parcourent des séquences en plusieurs étapes où une étape donnée peut renvoyer des données incorrectes sans lever d'exception. Les outils standards enregistrent un code de statut réussi, mais les données invalides continuent leur route vers les étapes suivantes.
Par exemple, à l'étape 3, un agent lit dans une base de données un solde de compte obsolète. La base renvoie des données valides : le système de supervision journalise donc une requête réussie. À l'étape 10, l'agent utilise ce même chiffre pour communiquer un solde à un client.
Le système met en forme la réponse et clôt la tâche sans lever d'erreur. Comme les étapes 3 et 10 se sont toutes deux terminées sans exception système, l'outil de supervision journalise l'exécution entière comme réussie. Le solde erroné est communiqué, sans que personne puisse le détecter avant un audit externe.
Voici les cinq mécaniques d'exécution d'un agent qui font échouer la supervision requête par requête :
- Non-déterminisme : L'agent ne se répète pas : la même requête déclenche une séquence d'étapes différente la deuxième fois. Une seule exécution enregistrée ne suffit donc pas à savoir comment l'agent se comporte.
- État multi-tours : L'erreur et l'échec sont éloignés l'un de l'autre : une erreur commise tôt dans une conversation produit un résultat erroné bien plus tard.
- Appels d'outils avec effets de bord : Certaines étapes sont irréversibles : l'agent écrit dans un système de référence alors que l'exécution est toujours en cours. Cette écriture n'est pas toujours réversible.
- Transferts entre sous-agents : Le travail passe d'un agent à l'autre et, si le transfert n'est pas enregistré, il est impossible de reconstituer l'ordre dans lequel les deux agents ont agi.
- Des échecs qui ressemblent à des réussites : l'exécution de l'agent se termine et la sortie paraît valide, mais la tâche confiée à l'agent reste inachevée.
Ce qu'il faut tracer
L'observabilité des agents requiert deux mécanismes distincts : enregistrer l'historique d'exécution d'une exécution, et déterminer si ces actions ont produit un résultat correct. L'historique d'exécution constitue la trace, tandis que des fonctions de scoring automatisées alimentent une couche d'évaluation.
Structure de trace et spans
Une trace est le journal complet d'une seule exécution d'agent. Chaque action individuelle qui contribue à l'observabilité IA durant cette exécution est enregistrée comme un span.
Un span représente une unité de travail unique et stocke l'heure de début, la durée d'exécution et les données de sortie de cette action précise. Les spans conservent en outre une hiérarchie parent-enfant afin de préserver la séquence logique.
Trace et span d'agent
Par exemple, lorsqu'un appel de modèle décide d'exécuter une requête en base de données, le span de la requête est imbriqué dans le span de raisonnement parent. Cette hiérarchie permet aux équipes techniques de remonter d'une réponse finale erronée jusqu'à l'étape antérieure exacte qui a généré des données invalides.
Cet ajout définit un span par ce qu'il est (une unité de travail), ce qu'il contient (heure de début, durée, résultat) et la raison pour laquelle l'ordre parent-enfant compte (un appel d'outil s'imbrique dans l'étape qui l'a déclenché). Cette imbrication permet de remonter d'une réponse erronée à l'étape qui l'a causée.
Évaluations au niveau de l'étape et au niveau de la trace
Une trace complète vous dit ce qui s'est passé, mais elle ne vous dit pas si ce qui s'est passé était correct. C'est le rôle de la couche d'évaluation, qui note l'exécution à deux niveaux.
- Évaluations au niveau de l'étape : Elles testent les actions individuelles, par exemple en vérifiant si l'agent a sélectionné l'outil approprié pour une requête ou récupéré la documentation pertinente dans une base de données.
- Évaluations au niveau de la trace : Elles évaluent l'ensemble de la chaîne d'exécution afin de déterminer si l'agent a accompli la tâche globale.
Normes de télémétrie
Les conventions sémantiques OpenTelemetry GenAI constituent la norme de nommage indépendante des fournisseurs pour la télémétrie des agents. Elles attribuent aux appels de modèle, aux appels d'outil et aux métriques d'exécution les mêmes noms de champs, quel que soit l'outil qui les enregistre. Ces conventions sont encore en cours d'élaboration plutôt que stabilisées : attendez-vous à ce que les noms de champs évoluent.
Une équipe qui enregistre sa télémétrie au format OpenTelemetry, plutôt qu'au format propriétaire d'un fournisseur, conserve ses données de traces dans un format portable. Elle peut changer d'outil d'observabilité IA, ou en ajouter un second, sans modifier la façon dont chaque agent enregistre sa télémétrie. Les comparatifs d'outils publiés par les fournisseurs tendent à passer la norme sous silence, car un format partagé rend leurs produits interchangeables.
Comment se répartissent les outils d'observabilité des agents
Les outils d'observabilité des agents se répartissent en quatre catégories, qui se distinguent par l'endroit où l'outil s'exécute et par les questions auxquelles il est conçu à répondre, et non par leur supériorité respective.
Chacun des outils listés ci-dessous surveille un agent qu'une équipe a construit et exploite elle-même. Aucun ne construit l'agent ni ne l'exploite. C'est la principale différence entre un outil d'observabilité et une plateforme dotée d'une observabilité intégrée, et c'est ce qui détermine lequel des deux un acheteur recherche réellement.
| Category | Example tools | Best at | Weak at |
|---|---|---|---|
| Evaluation-first platforms | Braintrust, DeepEval (Confident AI), Maxim | Scoring whether the agent did the right thing | Running as a high-volume trace backend |
| Open-source, self-hosted tracing | Langfuse, Arize Phoenix, Traceloop OpenLLMetry | Data residency and full control | You run and scale the storage yourself |
| APM tools extended for LLMs | Datadog, New Relic, Dynatrace | One platform for agents and infrastructure | Lighter evaluation depth |
| Enterprise governance and control planes | Fiddler, Arize AX, WhyLabs | Audit trails and compliance reporting | Heavier to adopt for one agent |
Plateformes centrées sur l'évaluation
Ces plateformes partent de l'évaluation et ajoutent le tracing autour. L'objet central est une suite de tests qui vérifie si l'agent a produit le bon résultat, la vue de trace servant à expliquer un score en échec.
Braintrust, qui a levé 80 M$ en série B en février 2026 pour développer son offre d'observabilité IA, DeepEval de Confident AI et Maxim fonctionnent tous de cette manière.
Ces plateformes savent transformer « l'agent se trompe parfois » en un succès ou un échec mesuré par rapport à un critère que vous avez défini, ce qui permet de détecter une régression avant qu'elle n'atteigne la production.
Tracing open source auto-hébergé
Ces outils sont conçus pour capturer et stocker les traces dans l'infrastructure que vous exploitez vous-même, avec une instrumentation conforme aux standards ouverts. Les données de traces ne quittent jamais votre environnement. Langfuse, racheté par ClickHouse en janvier 2026, Arize Phoenix et OpenLLMetry de Traceloop sont les plus répandus, et tous trois s'appuient sur OpenTelemetry.
Ils conviennent lorsque la résidence des données dicte le choix d'achat et lorsque vous souhaitez une instrumentation transposable ultérieurement vers un autre outil. Le coût est opérationnel, car vous êtes responsable du déploiement, de l'exploitation et de la mise à l'échelle du stockage. Par ailleurs, les fonctionnalités d'évaluation et de gouvernance peuvent varier suffisamment pour qu'une équipe doive souvent les assembler à partir de plusieurs projets.
Outils APM étendus aux LLM
Il s'agit des plateformes de supervision applicative qu'une équipe exploite déjà, utilisées pour capturer les spans d'agents aux côtés des métriques d'infrastructure collectées de longue date. Datadog Agent Observability enregistre sept types de spans et prend en charge les conventions GenAI d'OpenTelemetry. New Relic présente sa version comme le premier APM pour l'IA, et Dynatrace ingère les traces d'agents via OpenTelemetry.
Ce sont les outils idéaux lorsque vous voulez une seule plateforme pour l'agent et les services sur lesquels il s'exécute, et lorsque l'ajout des agents à un contrat existant l'emporte sur l'onboarding d'un nouveau fournisseur.
Plans de gouvernance et de contrôle pour l'entreprise
Ces plateformes considèrent la trace et l'évaluation comme des éléments de preuve pour la gouvernance, et pas seulement comme une aide au débogage. Votre entreprise peut les utiliser pour ajouter des pistes d'audit et des contrôles d'accès par-dessus le tracing et la notation. Elles sont en outre efficaces pour générer des rapports de conformité. Fiddler, qui se présente comme un plan de contrôle IA pour les agents d'entreprise, ainsi qu'Arize AX et WhyLabs, se situent à ce niveau.
À qui s'adresse une plateforme avec observabilité intégrée
Acheter une plateforme incluant déjà la supervision convient à une entreprise qui préfère des agents prêts à l'emploi plutôt que de les développer sur mesure à partir de zéro. Lorsqu'une équipe achète une workforce d'agents déjà déployée, la journalisation des traces et l'évaluation intégrées suppriment le besoin de construire un pipeline de supervision distinct.
Construire soi-même son observabilité suppose de définir le comportement correct pour chaque workflow. Cela implique de rédiger ces règles de workflow et de mettre à jour la suite de tests à chaque modification d'un agent. C'est un effectif d'ingénierie permanent, pas un achat ponctuel.
Qui profite le plus de l'observabilité intégrée
- Les acheteurs non techniques en entreprise : l'équipe évite de recruter du personnel de supervision spécialisé, car la journalisation des traces et l'évaluation des performances sont préintégrées à la plateforme d'exécution.
- Les entreprises réglementées : les organisations de la banque, des télécommunications, de l'aviation ou de l'énergie disposent de pistes d'audit et de relevés d'évaluation immédiatement exploitables lors des contrôles de conformité.
- Les dirigeants opérationnels, tels qu'un COO ou un CFO, peuvent vérifier si l'agent a bien résolu la tâche qui lui était confiée, plutôt que si une exécution s'est terminée sans erreur.
HappyRobot illustre ici le modèle de plateforme, car son moteur d'évaluation, les tests antagonistes et les pistes d'audit font partie intégrante de la plateforme qui exécute les agents. Plutôt que de câbler des logiciels de supervision distincts dans ses workflows, HappyRobot associe l'IA agentique à une logique déterministe pour fournir évaluation et conformité aux agents précis qui s'y exécutent.
S'y ajoutent les indicateurs phares dans HappyRobot, des règles auditables qui définissent le comportement correct de chaque agent, la plateforme exécutant des contrôles à leur égard. Ce sont les règles qui définissent le comportement correct, et les audits et tests sont mesurés par rapport à elles.
