6. Le paysage des outils

L’écosystème de l’observabilité de l’IA est dense et évolue vite. Le tableau ci-dessous classe des options répandues par catégorie et par mode d’hébergement, par ordre alphabétique. Y figurer ne vaut pas recommandation : le choix dépend des contraintes propres à chaque déploiement. Ce chapitre est la référence du site pour le paysage des outils et pour les licences (section 6.4) ; les autres contenus y renvoient.

Catégorie	Logiciels auto-hébergeables	Services gérés (SaaS)
Instrumentation	OpenInference (Arize), OpenLLMetry (Traceloop), SDK OpenTelemetry GenAI	SDK des éditeurs (Arize, Datadog, New Relic)
Dorsal de traces	Grafana Tempo, Jaeger, Langfuse, OpenObserve, Phoenix, SigNoz	Arize AX, Datadog LLM Observability, Langfuse Cloud, New Relic AI Monitoring
Dorsal de métriques	Grafana Mimir, Prometheus, Thanos, VictoriaMetrics	Chronosphere, Datadog, Grafana Cloud, New Relic
Dorsal de journaux	Elasticsearch, Grafana Loki, OpenObserve, VictoriaLogs	Datadog, Elastic Cloud, Grafana Cloud, Splunk
Cadre d’évaluation	DeepEval, OpenAI Evals, Phoenix evals, promptfoo, Ragas	Arize, Braintrust, Galileo, Patronus AI
Dérive et plongements	Evidently, NannyML, Phoenix, WhyLabs	Arize, Fiddler
Visualisation	Apache Superset, Grafana, Perses, interface Phoenix	Tableaux de bord Datadog, Grafana Cloud, New Relic
Gestion des prompts	Langfuse, Phoenix	Langfuse Cloud, PromptLayer, Vellum

Licences et rachats

La plupart des logiciels de la colonne auto-hébergeable sont open source (licences Apache 2.0, MIT ou AGPL v3). Deux exceptions à connaître, Phoenix (Elastic License 2.0, source disponible) et les distributions binaires d’Elasticsearch (ELv2) : le détail par brique est en section 6.4.

Le marché se consolide : Langfuse a été racheté par ClickHouse en janvier 2026 ; Traceloop, qui maintient OpenLLMetry, a été racheté par ServiceNow en mars 2026 ; WhyLabs a publié sa plateforme sous Apache 2.0 et fermé son service géré ; Humanloop a fermé le 8 septembre 2025.

6.1 Choisir entre auto-hébergement et service géré

Trois facteurs dominent la décision.

Souveraineté des données

Les secteurs régulés (banque, défense, santé, secteur public) demandent souvent un déploiement sur site ou dans un nuage souverain. Ni NIS2 ni DORA n’imposent en eux-mêmes que le dorsal d’observabilité réside dans une juridiction donnée. Cette exigence peut en revanche venir d’une politique interne, d’un régulateur sectoriel ou d’un contrat. DORA impose aux entités financières une gestion du risque lié aux prestataires tiers de services TIC et la tenue d’un registre d’information qui recense notamment les pays de stockage et de traitement des données (règlement d’exécution (UE) 2024/2956) : un dorsal d’observabilité qui stocke des prompts y figure comme les autres services. Quand une contrainte de localisation s’applique, le choix se réduit aux logiciels auto-hébergés ou aux éditeurs disposant de régions conformes et les pistes d’audit doivent couvrir l’accès aux prompts stockés.

Coût

L’observabilité LLM commerciale est facturée au span, au jeton ou à l’utilisateur. À un volume de production significatif, son coût peut rivaliser avec celui des appels LLM eux-mêmes. Ordre de grandeur : 100 spans par requête à 1 000 requêtes par seconde en continu donnent 8,64 milliards de spans par jour, soit environ 3 150 milliards de spans par an, pour le seul traçage. Multipliez ce volume par le prix par span (ou par million de spans) de votre fournisseur. Les prix changent vite et varient selon les contrats : ce guide n’en donne pas ; utilisez la grille datée de votre fournisseur.

L’auto-hébergement n’est pas gratuit pour autant : il déplace le coût vers l’infrastructure et le temps d’exploitation, à chiffrer avec la même rigueur.

Intégration

La pile d’observabilité existante dicte souvent le choix pour l’IA. Un site qui exploite déjà Grafana, Prometheus et Tempo peut garder ses dorsaux et ajouter une instrumentation GenAI et un outil d’exploration propre à l’IA (Phoenix, Langfuse ou équivalent). Un site déjà équipé de Datadog ou de New Relic peut activer le module LLM de son éditeur. Chaque outil supplémentaire ajoute de la charge d’exploitation (un logiciel à maintenir, un modèle de données, des droits d’accès) : ajoutez-en un seulement quand il répond à une question que la pile en place ne sait pas traiter et gardez l’OpenTelemetry Collector comme point d’entrée commun.

6.2 Une pile auto-hébergée de référence

Voici la pile que je recommande comme point de départ pour des déploiements européens soumis à des exigences de souveraineté. C’est une proposition à adapter : chaque couche est remplaçable et d’autres combinaisons répondent aux mêmes critères.

La figure, issue de la première version de ce guide, titre « open source stack » : Phoenix, qui y figure, est sous licence source disponible (Elastic License 2.0), voir ci-dessus.

Figure 9. Architecture de référence d’une pile auto-hébergée. Chaque couche est remplaçable indépendamment. L’OpenTelemetry Collector est le point d’intégration : il découple l’instrumentation des dorsaux.

Critères de choix des composants

• Métriques (VictoriaMetrics dans la figure) : à envisager si vos métriques d’IA ont une forte cardinalité et que vous voulez un binaire unique avec une longue rétention. L’éditeur annonce une meilleure tenue de la cardinalité que Prometheus ; mesurez-la sur votre charge. Alternatives : Prometheus avec un stockage distant, Thanos ou Grafana Mimir.
• Traces et évaluation IA (Phoenix) : interface de traces et d’évaluation propre à l’IA dans un seul outil, ce qui réduit la surface d’intégration. Licence source disponible (ELv2), à valider. Alternative open source : Langfuse (MIT pour le cœur).
• Traces généralistes (Tempo) : traçage distribué pour les services hors IA, utile quand la plateforme mêle services traditionnels et fonctionnalités d’IA. Alternatives : Jaeger, SigNoz.
• Journaux (VictoriaLogs) : binaire unique, exploitation proche de celle de VictoriaMetrics, mais avec son propre langage de requête (LogsQL), distinct de MetricsQL. Alternatives : Grafana Loki, OpenObserve, Elasticsearch.
• Instrumentation (OpenInference dans la figure) : un arbitrage, pas une recommandation inconditionnelle. OpenInference couvre de nombreux cadres LLM, exporte en OTLP et constitue la convention native de Phoenix. Mais il utilise ses propres attributs (openinference.span.kind, llm.*) et non les attributs gen_ai.* des conventions OpenTelemetry, que ce guide prend pour référence. Deux voies cohérentes : OpenInference si Phoenix est votre outil d’exploration principal et que vous acceptez sa convention, en convertissant au besoin vers gen_ai.* avec le processeur transform du Collector pour les autres dorsaux ; ou les instrumentations OpenTelemetry GenAI natives (ou OpenLLMetry), qui émettent gen_ai.*, si vous privilégiez une convention unique et portable entre outils, au prix de conventions encore en développement. Dans les deux cas, une seule convention doit alimenter les tableaux de bord et les alertes.
• Évaluation RAG (Ragas) : cadre Python dédié aux métriques RAG. À comparer avec DeepEval ou Phoenix evals selon les métriques dont vous avez besoin.
• Visualisation (Grafana) : la couche de visualisation opérationnelle. L’interface de l’outil de traces IA prend en charge l’exploration propre à l’IA.

6.3 Une pile en service géré

Pour les organisations sans contrainte de localisation et déjà équipées d’un éditeur d’observabilité commercial, quatre configurations courantes.

• Déjà sur un éditeur généraliste (Datadog, New Relic ou équivalent) : activez son module d’observabilité LLM. Une seule facture, une seule interface ; vérifiez la couverture des évaluateurs et le coût au volume.
• Qualité et évaluation sont prioritaires : une plateforme spécialisée comme Arize AX ou Braintrust, ou Langfuse Cloud. Comparez-les sur les évaluateurs fournis, la possibilité d’écrire les vôtres et l’export des données.
• L’évaluation est prioritaire, le traçage secondaire : Galileo, Patronus AI ou Braintrust.
• La gestion des prompts est le besoin central : Langfuse Cloud, PromptLayer ou Vellum.

6.4 Licences des briques

Cette section est la référence du site sur les licences ; les autres contenus y renvoient. « Open source » recouvre des régimes très différents et certaines licences dites « source disponible » n’en font pas partie. La confusion se paie au moment de l’industrialisation. Les licences changent : vérifiez celle de la version que vous déployez.

Brique	Rôle	Licence	Point de vigilance
OpenTelemetry Collector	passerelle	Apache-2.0	aucun
Jaeger	traces	Apache-2.0	aucun
Prometheus	métriques	Apache-2.0	aucun
VictoriaMetrics	métriques	Apache-2.0 (édition communautaire, version cluster comprise)	sous-échantillonnage (downsampling), rétentions multiples et détection d’anomalies réservés à l’édition entreprise
ClickHouse	stockage en colonnes	Apache-2.0	aucun
OpenLIT, OpenLLMetry	instrumentation	Apache-2.0	aucun
Ragas, DeepEval	évaluation	Apache-2.0	coût des appels au juge
Grafana, Tempo, Loki	visualisation, traces, journaux	AGPL-3.0	obligations en cas de redistribution et aussi quand une version modifiée est mise à disposition d’utilisateurs par le réseau
Langfuse	observabilité LLM	MIT pour le cœur	certaines fonctions sous licence commerciale ; racheté par ClickHouse le 16 janvier 2026
Arize Phoenix	observabilité LLM	Elastic License 2.0 (source disponible)	pas open source au sens de l’OSI : interdit de proposer le logiciel comme service géré à des tiers
Elasticsearch	journaux	code source des fonctions gratuites au choix sous AGPL v3, SSPL ou ELv2	distributions binaires officielles sous ELv2

Deux régimes posent problème en revue juridique. La licence Elastic 2.0 interdit de proposer le produit comme service géré à des tiers : sans effet pour un usage interne, bloquant pour un éditeur qui embarque la brique dans son offre. L’AGPL de Grafana, Tempo et Loki n’est en général pas un obstacle pour un déploiement interne non modifié ; elle s’applique en revanche à la redistribution et à l’interaction par le réseau avec une version modifiée : modifier Grafana et l’ouvrir à des utilisateurs, même sans le distribuer, oblige à leur proposer le code source modifié. Signalez-le avant que quelqu’un ne construise un produit par-dessus.

Pour choisir la brique propre aux LLM, trois critères à appliquer de la même façon à toutes les options : la licence (open source au sens de l’OSI ou source disponible), la possibilité d’auto-héberger et la capacité à recevoir de l’OTLP avec les conventions gen_ai.* sans SDK propriétaire. L’article de mise en production applique ces critères à sa propre pile.

Suite : 7. Exploiter la plateforme.

Révisé le 2 octobre 2026 : prix retirés, retrait de Humanloop (fermé), rachats de Langfuse et de Traceloop, WhyLabs passé en open source, licences de Phoenix et d’Elasticsearch précisées, colonnes du tableau rendues neutres, exigences de localisation de NIS2 et DORA corrigées.

Révisé le 4 octobre 2026 : chapitre désigné comme référence du site pour les outils et les licences, section 6.4 sur les licences par brique (reprise de l’article de mise en production), choix d’OpenInference présenté comme un arbitrage avec les conventions gen_ai.*.

Marquer comme lue