Module 1 : pourquoi un LLM ne s'observe pas comme une application classique

Deux comportements opposés

	Application classique	Application LLM
Comportement	déterministe : même entrée, même sortie	statistique : même entrée, sorties variables
Erreurs	visibles (4xx, 5xx, exceptions)	sémantiques : le modèle se trompe poliment, en 200 OK
Métriques infra	suffisent souvent	peuvent rester vertes pendant une dégradation de la qualité
Garantie de qualité	tests unitaires	évaluation continue en production
Coût	lié à l’infrastructure (CPU, RAM, IO)	à la requête, dépendant de la taille du contexte

Concrètement, un tableau de bord d’APM classique peut afficher une latence parfaite et zéro erreur pendant que l’assistant répond faux à une partie des utilisateurs.

Trois axes d’observation à industrialiser

Ces trois axes ne sont pas des signaux : ce sont les trois questions que l’on pose à un système LLM et qu’il faut lire ensemble. Pour y répondre, on mobilise les cinq signaux définis au chapitre 1 du guide : journaux, métriques, traces, évaluations et retours utilisateurs.

Axe	Question	Métriques typiques	Signaux mobilisés
Qualité	la réponse est-elle pertinente, fidèle au contexte, correcte ?	faithfulness, context recall, taux d’hallucination, retours utilisateurs	évaluations, retours utilisateurs ; traces pour le diagnostic
Coût	combien par requête, par client, par fonctionnalité, par modèle ?	jetons en entrée et en sortie, euros par requête, coût mensuel, taux de cache	métriques (jetons), traces (usage de chaque requête)
Performance	l’utilisateur reçoit-il sa réponse à temps et sans erreur ?	temps au premier jeton (TTFT), latence p95 et p99, taux d’erreur, débit	métriques, traces (latence par étape), journaux (erreurs)

Regarder un axe seul induit en erreur. Une baisse de coût peut venir d’un contexte tronqué qui dégrade la qualité ; une hausse de latence peut venir d’un meilleur modèle qui améliore la qualité.

Où instrumenter

Un appel LLM traverse cinq étapes. Chacune produit des spans, des métriques et des logs et porte ses propres attributs.

Client          Pré-traitement     Modèle          Post-traitement     Réponse
app, API,  -->  prompt,       -->  inférence  -->  parsing,       -->  évaluation,
agent           récupération RAG   LLM             garde-fous          journal

tenant_id       rag_stage          model           guardrail_action    quality_score
feature         top_k              tokens          parser_status       hallucination
user_id         docs_retrieved     latency

L’observabilité d’un appel couvre ces cinq points. Si l’on n’instrumente que l’appel au modèle, les quatre autres étapes restent dans l’ombre.

Cardinalité

user_id est utile sur une trace, dangereux sur une métrique. Gardez les identifiants non bornés dans les traces et les logs ; sur les métriques, limitez-vous à des dimensions bornées comme le client, la fonctionnalité et le modèle.

Choisir une pile

Les labs n’ont besoin que de situer leur pile parmi trois familles d’outils, auxquelles s’ajoute une couche d’instrumentation commune :

Famille	Exemples
Plateformes d’observabilité généralistes en SaaS	Datadog LLM Observability, New Relic AI Monitoring, Grafana Cloud
Plateformes spécialisées LLM, en SaaS ou autohébergées	Langfuse, Arize Phoenix ou Arize AX, LangSmith, Helicone
Pile autohébergée assemblée	OpenTelemetry Collector, VictoriaMetrics, Prometheus ou Mimir, Tempo ou Jaeger, Grafana, Loki
Couche d’instrumentation (bibliothèques, pas des produits de stockage)	SDK et instrumentations OpenTelemetry avec les conventions GenAI, OpenLLMetry (Traceloop), OpenInference (Arize)

Le paysage complet des outils, les critères de choix (souveraineté des données, coût, intégration) et les licences sont traités au chapitre 6 du guide. Les versions et licences des briques du kit figurent dans la présentation ; retenez que Phoenix est sous Elastic License 2.0 (source disponible, pas open source).

Ces labs retiennent une pile autohébergée, complétée par Phoenix, pour une raison pédagogique : on voit chaque maillon. Le choix reste réversible, parce que l’instrumentation OpenTelemetry est portable : les mêmes spans et métriques peuvent partir vers n’importe laquelle des familles ci-dessus.

L’architecture cible

flowchart TB
  APP["Application LLM<br/>Python, SDK OTel,<br/>conventions GenAI"] -->|"OTLP"| COL["OTel Collector<br/>réception, enrichissement,<br/>routage"]
  COL -->|"métriques"| VM["VictoriaMetrics"]
  COL -->|"traces"| TP["Tempo"]
  COL -->|"traces"| PX["Phoenix<br/>exploration, évaluation"]
  VM --> GR["Grafana<br/>tableaux de bord, alertes"]
  TP --> GR

L’application n’est instrumentée qu’une fois. Le Collector répartit ensuite les signaux : les métriques vers VictoriaMetrics, les mêmes traces vers Tempo et vers Phoenix. Grafana sert de point de lecture pour les métriques, les traces et les alertes ; Phoenix a sa propre interface pour explorer et évaluer les conversations.

En résumé

Un LLM échoue en silence, avec des erreurs sémantiques plutôt que techniques, ce qui oblige à lire qualité, coût et performance ensemble. L’instrumentation couvre les cinq étapes de la chaîne et pas seulement l’appel au modèle. Avec OpenTelemetry au centre, le choix des backends reste réversible.

Révisé le 2 octobre 2026 : les familles d’outils sont comparées sur les mêmes critères (mise en route, coût, localisation des données, exploitation), les bibliothèques d’instrumentation sont séparées des produits de stockage, les licences sont précisées (Phoenix sous Elastic License 2.0, source disponible) et Phoenix reçoit désormais les traces du Collector.

Révisé le 4 octobre 2026 : les trois axes sont présentés comme des questions et rattachés aux cinq signaux du guide ; la section « Choisir une pile » est réduite à ce dont les labs ont besoin et renvoie au chapitre 6 du guide pour le paysage des outils et les licences.

Marquer comme lue