La conversation démarre toujours par le nom d’un outil. Quelqu’un a vu une démo, quelqu’un a lu un fil, et la question qui arrive en réunion c’est : on héberge Langfuse ou on paie une plateforme ? C’est la mauvaise question, et ça se voit trois semaines plus tard : le traçage est en place, le tableau de bord existe, et personne ne sait dire si l’agent répond moins bien que le mois dernier.
La thèse en une phrase : l’observabilité des agents IA n’est pas un outil, ce sont quatre couches qu’on décide séparément, et les briques ouvertes couvrent les quatre aujourd’hui. Ce qui casse, ce n’est pas l’outil — les ouverts fonctionnent — mais les deux choses que personne ne met dans le tableau comparatif : la convention de données est encore en développement et sa documentation a déménagé, et « ouvert » désigne au moins trois licences qui ne permettent pas la même chose.
Les outils d’observabilité des agents IA que tu peux héberger toi-même : quatre couches, pas une
L’erreur de départ, c’est de traiter ça comme un achat unique. On emploie « observabilité » comme s’il s’agissait d’un produit, alors que dans un agent ce sont quatre métiers différents, qui échouent différemment et dont on a presque jamais besoin des quatre le même jour. Les séparer, c’est ce qui transforme un choix de marque en décision d’ingénierie.
| Couche | À quelle question elle répond | Ce qui arrive sans elle |
|---|---|---|
| Traces corrélées | Qu’a fait l’agent, dans quel ordre, avec quels outils et quelle entrée à chaque étape ? | Tu débogues à l’aveugle : tu as le résultat final et aucun moyen de savoir à quelle étape ça a dérapé |
| Évaluation avant production | Ce changement de prompt ou de modèle fait-il mieux que la référence, ou moins bien ? | Chaque changement est un pari, et le seul test c’est d’attendre qu’on se plaigne |
| Attribution du coût | Que coûte chaque cas, chaque agent, chaque outil — et non la facture agrégée ? | Tu vois le total du fournisseur en fin de mois sans pouvoir l’attribuer ni le couper |
| Détection de dérive | Répond-il encore comme il y a un mois, avec le même modèle derrière ? | La qualité glisse doucement, la supervision classique affiche tout en vert, et c’est un client qui le découvre |
Les deux premières, n’importe quelle brique ouverte sérieuse les couvre aujourd’hui. La troisième suppose d’avoir instrumenté à la bonne granularité dès le début — l’ajouter après, c’est réinstrumenter. La quatrième n’est pas une fonction qu’on active : c’est une cadence que quelqu’un doit exécuter, et c’est celle qui se retrouve le plus souvent sans propriétaire. Pourquoi la dérive produit un glissement et non une erreur, on le développe dans ce qui se passe quand le modèle d’IA change sous tes automatisations ; ici, ce qui compte c’est quelle couche aurait dû l’attraper.
Ce qui casse en premier, ce n’est pas l’outil : c’est la convention
Pour que les quatre couches se parlent, il faut que toutes appellent les mêmes choses pareil : ce qu’est un appel au modèle, ce qu’est une invocation d’agent, ce qu’est une exécution d’outil. C’est une convention sémantique, et c’est la partie du stack que presque personne ne regarde avant de choisir. C’est aussi la moins stabilisée.
Deux faits concrets, vérifiables à la source primaire. Un : les conventions GenAI d’OpenTelemetry — les attributs gen_ai.* — sont toujours marquées en développement, pas stables. Deux, et c’est celui qui va vraiment te mordre : cette documentation ne vit plus là où ton moteur de recherche va t’envoyer. La page historique du dépôt de conventions sémantiques indique désormais seulement que le contenu a été déplacé vers le dépôt des conventions GenAI et que l’ancienne n’est plus maintenue.
Par-dessus, une seconde convention circule : OpenInference, la couche sémantique qu’Arize maintient et sur laquelle tourne son outil ouvert. Ce n’est pas un problème en soi — les exportateurs traduisent — mais c’est la raison pour laquelle deux briques toutes deux « compatibles OpenTelemetry » peuvent arriver avec des arbres de spans qui ne s’emboîtent pas. Choisis-en une et fais-en la norme maison ; ne laisse pas chaque équipe qui instrumente décider.
« Ouvert » désigne trois licences différentes, et une seule te permet ce que tu crois
C’est ici que le stack ouvert ressemble beaucoup plus qu’on ne l’admet au débat qui existe déjà en automatisation. C’est exactement le piège qu’on démonte dans les outils open source d’automatisation avec l’IA : « 0 € de licence » n’est pas « 0 € de coût », et « open source » n’est pas toujours ce que le mot suggère. En observabilité d’agents, c’est pareil, avec une nuance propre.
| Brique | Ce que dit sa propre documentation | Ce que ça veut dire en pratique |
|---|---|---|
| Langfuse | Open source et auto-hébergeable avec Docker sur ton infrastructure ; certaines fonctions complémentaires exigent une clé de licence | Pour opérer ta propre flotte, le cœur suffit. Sa liste de fonctions d’auto-hébergement en marque trois comme entreprise — créateurs d’organisation, API de gestion d’instance et personnalisation d’interface |
| Arize Phoenix | Publié sous Elastic License 2.0 ; l’auto-hébergement sur ton infrastructure ou ton compte cloud est gratuit et pleinement autorisé, sans fonctions payantes | En interne, tu n’as aucune fonction rognée. L’ELv2 n’est pas approuvée par l’OSI et sa restriction centrale, c’est de le proposer à des tiers comme service géré |
| OpenTelemetry | Projet de la CNCF ; les conventions GenAI sont en développement | La tuyauterie est la partie la plus solide et la moins discutable du stack. L’instabilité est dans le vocabulaire, pas dans le transport |
La lecture opérationnelle : si tu montes ça pour ta propre exploitation, les trois licences te le permettent et la conversation juridique est courte. Si à un moment tu comptes revendre le tableau de bord à tes clients comme service — une agence, un prestataire de services gérés — l’ELv2 est précisément ce qui l’interdit, et mieux vaut le savoir avant de construire le business dessus, pas après.
À quel moment le stack ouvert cesse d’être rentable (et ce n’est pas un nombre d’agents)
La réponse attendue ici, c’est un chiffre : jusqu’à X agents tu héberges, au-delà tu achètes. Ce chiffre n’existe pas, et qui te le donne te vend le côté qui l’arrange. Le seuil n’est pas de volume : il est de garanties.
C’est l’éditeur qui le dit dans sa propre documentation, et c’est la phrase la plus honnête de toute la catégorie. Dans le tableau des options de déploiement de Langfuse, le démarrage par Docker Compose est décrit comme une seule machine virtuelle sans haute disponibilité, sans mise à l’échelle et sans sauvegardes, et l’auto-hébergement de production — Kubernetes, AWS, Azure, GCP — affiche la responsabilité dans une seule colonne : ton infrastructure.
Voilà le vrai seuil, et il n’a rien à voir avec le nombre d’agents. Le stack ouvert cesse d’être rentable le jour où le tableau de bord devient une infrastructure critique : quand quelqu’un de l’extérieur remarque la panne, quand la trace est la preuve dont tu as besoin pour répondre à un client ou à un auditeur, ou quand conserver six mois de traces devient une exigence et non une préférence. Ce jour-là tu ne choisis plus un outil, tu décides qui se lève pour le réparer. C’est la même question — posée pour les automatisations — que qui répond quand une automatisation tombe.
Il faut aussi lire à distance les chiffres d’échelle que publie n’importe quel éditeur. Langfuse affirme dans sa documentation traiter plus de 90 milliards d’observations par mois et être utilisé par 21 des Fortune 50. Ce sont des données de l’éditeur sur son propre produit, pas une mesure indépendante ni un résultat de notre part ; ça dit que la brique tient la charge, pas ce qu’elle tiendra chez toi.
Quand NE PAS monter le stack ouvert
Quatre situations où ce projet est un détour, pas une avancée. Les quatre sont réelles et les quatre se présentent déguisées en bonne idée :
- Tu as un agent et il n’est pas instrumenté. Il ne te manque pas une plateforme d’observabilité : il te manque le traçage. Instrumente d’abord avec la convention figée et décide ensuite où tu l’envoies ; l’ordre inverse te fait choisir un outil avec zéro donnée sur ce que tu as besoin de voir.
- Personne ne va regarder le tableau de bord. Un tableau de bord sans astreinte, ce n’est pas de l’observabilité, c’est de la dépense d’infrastructure avec des courbes. S’il n’y a pas une personne nommée avec un tour de garde, commence par ça.
- Ton problème est de qualité, pas de santé. Si la plainte c’est « il répond mal », aucune trace ne le corrige : il te faut une grille et une banque de cas, ce qui est un autre travail — on le traite dans évaluer la qualité des agents IA.
- L’agent écrit dans un système d’enregistrement et n’a pas encore sa matrice d’accès. L’observabilité te dit ce qu’il a fait ; elle ne l’empêche pas de pouvoir le faire. Cet ordre est dans quelles permissions donner à un agent IA, et il passe avant.
Ce qu’on mesure le premier mois
Le signe que le stack est vraiment monté, ce n’est pas que le tableau de bord charge. Ce sont quatre questions auxquelles tu ne pouvais pas répondre et auxquelles tu réponds maintenant en une minute, la trace sous les yeux :
- Sur les pannes du mois, combien ont été détectées par une alerte et combien par une personne de l’extérieur. C’est la seule métrique qui dit si le tableau de bord sert.
- Ce qu’a coûté le cas le plus cher, et pourquoi. Si la réponse est « on ne peut pas le ventiler », la couche d’attribution n’est pas là, graphique de tokens ou pas.
- Combien de temps il te faut pour reconstituer ce qui s’est passé sur un cas précis d’il y a trois semaines. Si c’est des heures, les traces sont là mais pas la corrélation.
- Combien de changements de prompt ou de modèle sont passés sans repasser par la référence. Ce nombre devrait être zéro, et il ne l’est presque jamais le premier mois.
Aucune des quatre n’est une métrique de l’outil. Ce sont des métriques de l’exploitation, et c’est pour ça que le stack ouvert ne se termine pas le jour du déploiement : ce que Docker te donne, c’est la moitié bon marché. Quand l’équipe ne peut pas porter ce travail continu, la conversation c’est superviser l’IA en production comme fonction, pas comme tableau de bord.
La phrase pour la prochaine réunion
La prochaine fois qu’on demande quel outil d’observabilité d’agents on monte, la réponse utile n’est pas un nom. C’est : dis-moi laquelle des quatre couches te manque, quelle convention tu figes, et qui se lève quand ça tombe. Avec ces trois réponses, le choix de l’outil se fait tout seul, et c’est presque toujours l’ouvert.