L’observabilité pour les agents AI d’entreprise avec Langfuse et OCI
Pourquoi les journaux, les métriques et les traces ne suffisent pas pour les agents GenAI, et comment tracer les prompts, les appels d’outils, les tokens et les sessions à l’aide de Langfuse open-source sur OCI Agents.
Sources: Observability for Enterprise AI Agents: an open-source solution
Les journaux, les métriques et les traces ne vous indiqueront pas pourquoi un agent d’IA d’entreprise a donné une mauvaise réponse. Pour comprendre ces systèmes, il vous faut également examiner les prompts, le contexte transmis au modèle, les appels aux outils, l’utilisation des tokens, les temps de réponse ainsi que la qualité du résultat. Cet article explique pourquoi l’IA générative a besoin d’une approche différente en matière d’observabilité, puis présente une configuration concrète utilisant Langfuse, qui s’intègre aux agents d’IA d’OCI Enterprise grâce à sa compatibilité avec l’API OpenAI Responses.
Pourquoi c’est important
Le terme « agent » est utilisé pour tout flux de travail qui fait appel à un ou plusieurs grands modèles de langage afin d’obtenir un résultat. Cela brouille une distinction réelle. Un véritable agent offre de l’autonomie, la capacité d’utiliser des outils et une gestion du contexte, ce qui entraîne une complexité opérationnelle bien plus élevée.
Un deuxième problème est encore plus urgent dans les entreprises. L’attention se porte sur le « miracle » de l’IA, tandis que le travail nécessaire pour faire fonctionner ces systèmes de manière fiable, sous contrôle et avec une bonne qualité est négligé. L’observabilité figure en tête de cette liste. Pour un agent d’IA générative complexe, il ne s’agit pas d’une simple subtilité technique : c’est ce qui permet de comprendre le comportement, d’analyser les erreurs, d’évaluer la qualité des réponses et de maîtriser les coûts et les délais.
La première partie ci-dessous définit l’observabilité et son rôle dans l’IA générative. La seconde partie présente une configuration open source facile à mettre en œuvre sur OCI, avec des exemples de ce qu’elle collecte et des raisons pour lesquelles ces données sont utiles.
Que signifie l’observabilité
L’observabilité est une propriété des systèmes complexes. En termes simples, un système est observable si l’on peut déterminer son comportement interne à partir des signaux qu’il émet et que l’on est capable de collecter et d’analyser. Plus formellement, deux états internes différents doivent être distinguables à partir des signaux émis. Ce que le système émet doit révéler de manière fiable ce qui se passe à l’intérieur.
Deux conséquences en découlent. L’observabilité est particulièrement importante là où il y a de nombreuses composantes, dépendances et interactions. De plus, observer de l’extérieur ne suffit pas, car le système doit être conçu et équipé de moyens permettant de générer des informations utiles. Faire fonctionner correctement un agent d’IA d’entreprise signifie collecter des données de télémétrie qui révèlent son état, son comportement, ses anomalies et ses performances.
C’est là que l’observabilité diffère du monitoring classique. Le monitoring répond aux questions que l’on a prévu à l’avance, comme la quantité de CPU utilisée par un service ou la lenteur d’une requête. L’observabilité doit également permettre d’enquêter sur les imprévus, les problèmes et les questions que personne n’avait anticipés lors de la conception, souvent appelés les « inconnus inconnus ».
Observabilité avant l’IA générative
Par « systèmes traditionnels », on entend ici les applications développées avant que l’IA générative ne devienne courante, approximativement avant 2023. Leur observabilité reposait sur trois types de données : les journaux, les métriques et les traces.
Les journaux et les métriques nous sont familiers. Une trace représente l’enregistrement bout en bout d’une seule requête ou interaction, composée de segments qui décrivent les étapes individuelles. Dans une architecture de microservices, une trace peut couvrir toute une transaction d’application, avec des segments pour une appel API, une requête de base de données ou un appel à un service externe. Pour être efficace, cette approche doit suivre la requête à travers chaque composant qu’elle touche.
Pour les agents GenAI, ce modèle classique ne suffit pas à lui seul. En plus des journaux, des métriques et des traces, il faut également observer ce que fait le modèle, quel contexte il a reçu, quels outils il a utilisés et à quel point ses réponses étaient réellement bonnes.
Quels changements avec GenAI
Le logiciel conventionnel est assez prévisible. Les systèmes basés sur l’IA générative le sont moins, surtout lorsqu’ils disposent d’une certaine liberté pour prendre des décisions. La sortie d’un LLM dépend de bien plus que l’entrée de l’utilisateur, et tous ces facteurs doivent être visibles.
Une configuration d’observabilité pour un système LLM doit permettre de capturer au moins quatre éléments :
- le modèle et les paramètres de l’appel
- les instructions et le prompt réel envoyé
- le contexte fourni, y compris l’historique des conversations précédentes
- la manière dont le système a été exécuté, y compris les appels aux outils, les sorties intermédiaires, la latence et l’utilisation des tokens
Se contenter de l’ réponse finale est insuffisant. Pour comprendre un système GenAI, il faut pouvoir reconstituer, pour chaque trace, tout ce qui a contribué à la réponse.
Cela est d’autant plus vrai lorsque le modèle dispose de liberté opérationnelle. S’il peut choisir quels outils invoquer, l’ordre des actions, quels sources consulter ou quand s’arrêter, alors les prompts et les résultats ne suffisent pas. Il faut pouvoir observer le processus de décision lui-même, y compris la séquence des appels aux outils, les délais et les résultats intermédiaires.
Même un suivi complet ne permet souvent pas de déterminer si le résultat est de bonne qualité. À cette fin, chaque suivi nécessite généralement des scores associés. Ces scores peuvent provenir d’une logique conventionnelle ou d’un autre LLM, grâce à la technique courante du « LLM en tant que juge ».
Envisagez d’évaluer une réponse RAG. Elle peut être partiellement correcte, ou sembler plausible sans être étayée par les sources consultées. Il vous faudra alors distinguer au moins deux problématiques : la cause racine, telle que la récupération des données, le réclassement ou la génération, et le fondement, c’est-à-dire si la réponse repose réellement sur les documents consultés. Les vérifications de fondement permettent de détecter des affirmations non étayées et donc des hallucinations possibles.
Tout cela signifie qu’une plateforme d’observabilité générale ne suffit pas pour l’GenAI. Vous avez besoin d’un outil qui capte ces informations de manière native tout en minimisant les efforts d’instrumentation. La véritable différence réside dans la portée : pour l’GenAI, vous surveillez l’infrastructure et la vitesse comme auparavant, mais en plus le contexte vu par le modèle, les décisions qu’il a prises, la qualité de ce qu’il produit et la régularité de son comportement.
De la théorie à une configuration fonctionnelle
Ainsi, l’observabilité des agents d’entreprise doit inclure des prompts, du contexte, des appels d’outils, des temps de réponse, la consommation de tokens, la qualité des résultats, ainsi que les causes probables d’erreurs ou de réponses insatisfaisantes, en plus des signaux classiques. La question pratique est de savoir comment obtenir tout cela de manière simple et efficace, adaptée à un environnement d’entreprise. La solution présentée ci-dessous est une solution open source facile à adopter sur OCI.
Langfuse
Parmi les outils open source pour l’observabilité des LLM et des agents, Langfuse se distingue. Il s’agit d’une plateforme de suivi, d’observabilité et d’évaluation (notation) des applications basées sur des LLM, couvrant la majeure partie des données mentionnées précédemment : prompts, résultats, traces, métadonnées, temps de réponse, utilisation des tokens, appels aux outils et scores d’évaluation. Il s’agit de plus qu’un service de journalisation ; il vous offre une vue structurée du comportement réel d’une application GenAI, organisée autour de traces et de sessions plutôt que d’un flux plat de lignes de texte qu’il faudrait parcourir manuellement.
Pourquoi OCI facilite l’intégration
OCI Enterprise AI Agents met à disposition une API pleinement compatible avec l’API OpenAI Responses. Cela revêt une importance qui dépasse le simple aspect pratique, car il vous permet de réutiliser les outils, les bibliothèques et les modèles de développement de l’ample écosystème compatible avec OpenAI. Pour Langfuse, cela réduit considérablement le travail de collecte des données de telemétrie issues des appels aux modèles ainsi que la création de la couche d’observabilité, ce qui permet d’allouer plus de temps à l’analyse et moins aux tâches techniques. C’est là l’une des raisons pour lesquelles OCI et Langfuse s’associent bien dans un environnement d’entreprise.
Un déploiement rapide de preuve de concept
Pour une démonstration, Langfuse s’installe facilement sur OCI, par exemple sur une machine virtuelle Linux, en utilisant la configuration Docker Compose officielle provenant du répertoire de Langfuse. Il ne s’agit pas nécessairement de l’architecture finale pour un environnement d’entreprise de niveau production. Cela suffit amplement pour valider l’idée, collecter des données de telemétrie réelles et voir quelles analyses sont possibles après intégration. En pratique, cela a permis de créer rapidement une plateforme fonctionnelle, accessible depuis un navigateur et prête à recevoir des traces provenant d’applications LLM en Python.
Connexion du code
Lorsqu’une instance Langfuse est en cours d’exécution, l’étape suivante consiste à instrumenter l’application afin que les données de telemétrie relatives aux appels au modèle soient transmises automatiquement. Grâce à la compatibilité avec l’API Responses, cela est simple pour les applications Python déjà écrites en utilisant un appel de type OpenAI. L’application continue d’appeler le modèle de la même manière qu’auparavant, et Langfuse enregistre les détails importants.
Les modifications sont mineures :
- Définir quelques variables d’environnement.
- Utiliser le client fourni par la bibliothèque Langfuse, qui est déjà préparé pour collecter et envoyer des traces.
- Transmettre
conversation_idau lieu desession_id, de sorte que les requêtes d’une même conversation soient regroupées dans la même session. - Optionnellement, forcer un envoi immédiat des traces en effectuant un flush. Sinon, elles sont envoyées automatiquement après quelques secondes.
Qu’est-ce qui est collecté
Après l’intégration, Langfuse collecte automatiquement de nombreuses informations utiles. Pour les agents, cela inclut bien plus que les entrées et sorties du modèle. Il couvre également le flux d’exécution, avec les étapes intermédiaires, les appels aux outils et les temps de traitement, ce qui vous aide à reconstituer comment un résultat a été obtenu.
Les éléments les plus importants sont :
- le modèle et sa version
- le prompt envoyé
- la sortie générée
- les métadonnées associées à l’appel
- la structure du suivi et toutes les étapes correspondantes
- les mesures de latence, y compris celles visibles par l’utilisateur comme le temps jusqu’au premier token
- le nombre de tokens d’entrée et de sortie, utilisés pour l’analyse des coûts
- les appels aux outils et leurs détails
- les scores et évaluations liés au suivi
Tout ce qui est utile n’arrive pas automatiquement, et c’est intentionnel, car la plateforme ne peut pas savoir ce que votre entreprise considère comme une bonne réponse. Des scores spécifiques au domaine, des indicateurs personnalisés et des métadonnées métier peuvent, et doivent parfois, être ajoutés par l’application. C’est la combinaison de la collecte automatique et de l’enrichissement délibéré qui rend l’outil efficace.
Séances
Langfuse peut relier plusieurs traces d’une même session utilisateur grâce à un session_id. Dans ce cas, la conversation est identifiée par le conversation_id standard de l’API Responses, de sorte que la mise à égalité de session_id avec celui-ci permet de corrélater toutes les requêtes provenant de la même conversation. Les séances peuvent ensuite être consultées dans l’interface utilisateur, où chacune contient plusieurs traces.
Explorer une trace
Les résultats apparaissent lors de l’analyse. L’interface Langfuse vous permet d’examiner en détail chaque interaction, mettant en évidence des éléments qui, sinon, seraient dispersés dans les journaux d’application, les métadonnées et le code. Pour une seule trace, vous pouvez voir le prompt réellement envoyé, le modèle, ses paramètres, les temps d’exécution, les tokens consommés, la séquence de toutes les appels ainsi que les résultats à chaque étape. Cela est particulièrement important lorsque vous enquêtez sur un comportement anormal, des problèmes de latence, des coûts en hausse ou des réponses de qualité insatisfaisante. Une réponse lente, par exemple, peut être due à une longue chaîne d’appels d’outils, à un prompt trop long ou à un premier token lent, et chacun de ces problèmes nécessite une solution différente. Sans les données de chronométrage au niveau de chaque segment et le comptage des tokens présentés côte à côte, vous devriez deviner lequel est le problème.
Une habitude pratique qui en découle est de considérer chaque conversation comme quelque chose que l’on peut rejouer plus tard. Lorsqu’un utilisateur signale une mauvaise réponse une semaine plus tard, la vue de la session permet d’ouvrir les traces exactes, de lire la demande et le contexte réels, et de voir quel outil a fourni quoi, au lieu de tenter de reconstituer la situation à partir de sa mémoire.
Limites à garder à l’esprit
Adopter Langfuse ne résout pas tous les défis liés à l’observabilité et à l’évaluation dans un système GenAI. Des traces riches en contexte sont nécessaires, mais pas toujours suffisantes. Les scores les plus utiles dépendent généralement du domaine d’application et doivent être conçus intentionnellement. De plus, les environnements d’entreprise réels exigent une réflexion approfondie sur la sécurité, les données sensibles, la conservation des données de télémétrie, le contrôle d’accès et l’architecture de déploiement.
Même ainsi, une plateforme open source associée à une compatibilité API complète avec OCI constitue un point de départ solide pour une solution concrète d’observabilité destinée aux agents d’entreprise.
En résumé
Pour les agents d’IA d’entreprise, l’observabilité n’est pas un détail technique ni un ajout optionnel. C’est une condition préalable pour comprendre le comportement, analyser les erreurs, évaluer la qualité des réponses, ainsi que pour réduire les délais de réponse et les coûts de fonctionnement. Se contenter d’observer l’infrastructure, les journaux d’application et les métriques standard ne suffit pas. Il faut également des données beaucoup plus proches de ce que fait l’agent : les prompts, le contexte, les appels aux outils, la consommation de tokens, la latence perçue par l’utilisateur et les scores d’évaluation.
Langfuse est une option open source particulièrement intéressante, car elle permet de capturer et d’organiser une grande partie de ces données de télémétrie, et l’API compatible OpenAI présente dans OCI Enterprise AI Agents facilite l’intégration. Cependant, aucune plateforme ne peut résoudre tout seule tous les problèmes : la sécurité, la gouvernance, la gestion des données sensibles ainsi que la conception de scores spécifiques à chaque domaine restent essentielles.
Si ces agents doivent passer des démos pour devenir des composants fiables au sein de systèmes réels, l’observabilité ne peut pas rester une considération secondaire. Leur complexité ne peut être éliminée, mais elle peut et doit être rendue visible.
Une étape logique consiste à enrichir les traces de scores permettant d’évaluer plus systématiquement la qualité, en particulier des scores générés par un modèle de langage en tant que juge, afin que chaque trace contienne à la fois des données d’exécution technique et des évaluations de la qualité de la réponse.
Lectures complémentaires
- Comment le stockage du navigateur corrompt silencieusement les données des utilisateurs et comment y remédier — Les mises à jour perdues, les snapshots obsolètes, les écarts de schéma et les fuites sur des appareils partagés peuvent endommager les données localStorage sans aucun erreur. Modèles de gestion de la propriété, de versionnement et de validation.
- Notes pratiques : Systèmes RAG : Le guide complet de zéro à héros (édition 2026) — Guide pas à pas détaillé des Notes pratiques : Systèmes RAG : Le guide complet de zéro à héros (édition 2026) : contrats, vérifications et emplacements de code prêts à l’emploi pour les équipes souhaitant mettre en œuvre ce modèle.