Partie I. Le cadre

1. Le modèle de la défaillance silencieuse

L’observabilité classique a été conçue pour des défaillances bruyantes : code 500, timeout, exception. Les systèmes à base de LLM défaillent autrement. Leurs trois pathologies dominantes sont silencieuses :

• la qualité se dégrade sans qu’aucune erreur ne soit levée : hallucination, réponse incomplète, dérive lente.
• le coût dérive sans alerte : gonflement de prompt, boucle d’agent.
• la sécurité est compromise au niveau sémantique, pas réseau : tool poisoning, injection.

Énoncé du modèle : pour tout signal qu’on ne mesure pas, la question pertinente n’est pas « le service tombe-t-il ? » mais « combien de temps la défaillance s’accumule-t-elle avant qu’on la voie ? ». La valeur d’un dispositif d’observabilité GenAI se mesure à sa capacité à rendre visible le silencieux. Tout le reste de la méthode en découle et l’analyse d’impact de la partie V le quantifie.

2. Le cadre en quatre dimensions

flowchart TB
  subgraph D1["Dimension 1 : les 4 couches (où se produit le signal)"]
    L1["Infrastructure : GPU, réseau, base vectorielle, serveur MCP"]
    L2["Modèle / inférence : latence, tokens, saturation"]
    L3["Application : RAG, prompt, orchestration, garde-fous"]
    L4["Agent / tâche : trajectoire, outils, succès de bout en bout"]
    L1 --> L2 --> L3 --> L4
  end
  subgraph D2["Dimension 2 : les 4 axes (pourquoi on surveille)"]
    A1["Fiabilité"]
    A2["Disponibilité"]
    A3["Coût"]
    A4["Compliance"]
  end
  subgraph D3["Dimension 3 : les 5 questions (par signal)"]
    Q["Quoi -> Pourquoi -> Comment -> Seuil -> Impact si absent"]
  end
  subgraph D4["Dimension 4 : la maturité (niveaux 0 à 5 du guide)"]
    M["0. Aveugle -> 1. Télémétrie de base -> 2. Traçage -> 3. Évaluation en ligne -> 4. Dérive et retours -> 5. Boucle fermée"]
  end
  D1 --> D2 --> D3 --> D4

Dimension 1 : les quatre couches

Tout signal appartient à une couche. Règle structurante : la cascade. Une défaillance basse remonte en symptôme haut. Sans corrélation par un trace_id unique entre couches, on observe des symptômes sans cause.

flowchart LR
  C2["Couche 2 : rate-limit fournisseur à 10h47"] --> C3["Couche 3 : retries, latence prompt"] --> C4["Couche 4 : taux de succès de tâche en chute"]
  C4 -.->|"diagnostic descendant via trace_id"| C2

Le site décrit la pile d’une application d’IA générative en cinq couches dans L’IA en coupe : données, infrastructure, modèle, orchestration, application. Les quatre couches de la méthode s’y projettent ainsi (attention au mot « application », qui ne désigne pas la même chose) :

Couche de la méthode	Couche(s) de L’IA en coupe
1. Infrastructure : GPU, réseau, base vectorielle, serveur MCP	infrastructure (GPU, réseau, serveurs) ; le contenu indexé de la base vectorielle relève des données ; les outils exposés par un serveur MCP sont appelés depuis l’orchestration
2. Modèle / inférence : latence, tokens, saturation	modèle, à sa frontière avec l’infrastructure : le TTFT, les jetons par seconde et la saturation se mesurent au serveur d’inférence, que le schéma range dans l’infrastructure
3. Application : RAG, prompt, orchestration, garde-fous	orchestration (prompts, recherche documentaire) ; les garde-fous en sortie touchent aussi la couche application (violations de politique, données personnelles en sortie)
4. Agent / tâche : trajectoire, outils, succès de bout en bout	orchestration pour la trajectoire et les appels d’outils ; application pour le succès perçu par l’utilisateur
pas de couche dédiée	données : fraîcheur et couverture des sources, distribution des entrées, que la méthode traite dans la grille RAG de la partie III

Dimension 2 : les quatre axes

Fiabilité, disponibilité, coût, compliance. Chaque composant est lu selon ces quatre axes dans les grilles de la partie III.

Dimension 3 : les cinq questions

Le gabarit appliqué à chaque signal. On n’instrumente jamais sans avoir répondu à « pourquoi » et « impact si absent ».

Question	Ce qu’elle établit
Quoi	Le signal précis : métrique, trace, score, événement
Pourquoi	La décision qu’il éclaire. Un signal sans décision est du bruit
Comment	La source et l’instrument : attribut OTel, exportateur, évaluateur
Seuil	Le SLI et le SLO, donc le déclenchement d’alerte
Impact si absent	La défaillance qui s’accumule sans ce signal et sa gravité

Dimension 4 : la maturité

La méthode avait sa propre échelle en cinq niveaux (Logging, Traçage, Évaluation, Monitoring, Boucle fermée). Le site n’en garde qu’une, celle du guide, chapitre 3, en six niveaux de 0 à 5. Correspondance :

Niveau du guide	Ce qui le caractérise	Ancien niveau de la méthode
0. Exploitation à l’aveugle	métriques HTTP seulement ; coût découvert sur la facture, qualité par les réclamations	aucun : l’échelle de la méthode commençait à la journalisation
1. Télémétrie de base	journaux structurés par requête (prompt, réponse, modèle, jetons, latence), coût agrégé, erreurs en métriques	1. Logging
2. Traçage structuré	conventions OpenTelemetry GenAI, un span par étape logique, attributs interrogeables	2. Traçage
3. Évaluation en ligne	évaluations automatiques rattachées aux traces et exposées en métriques, régressions de qualité alertables	3. Évaluation
4. Dérive et intégration des retours	dérive des plongements, qualité du RAG en lot, retours utilisateurs corrélés aux traces	4. Monitoring (correspondance approchée : la méthode ne détaillait pas ce niveau)
5. Boucle fermée	les traces en échec deviennent des cas de non-régression, changements conditionnés au jeu de non-régression	5. Boucle fermée

Les SLO de qualité de la partie IV supposent au moins le niveau 3 : sans évaluation en ligne, il n’y a pas d’échantillon à mesurer.

À mon avis, beaucoup d’organisations s’arrêtent au niveau 2 et croient observer leur système. Elles voient ce qui s’est passé, pas si c’était bon. Le saut de valeur est au niveau 3, la maîtrise au niveau 5.

3. Les cinq signaux

Les signaux sont ceux du guide, chapitre 1 : journaux, métriques, traces, évaluations, retours utilisateurs, corrélés par l’identifiant de trace. La méthode y ajoute le stockage type de sa configuration de référence :

Signal	Stockage type
Journaux	VictoriaLogs, Loki
Métriques	VictoriaMetrics, Prometheus
Traces	backend OTLP (Tempo, Jaeger)
Évaluations	Langfuse, Arize Phoenix
Retours utilisateurs	rattachés à la trace par son identifiant, à côté des scores d’évaluation

Les « événements de contenu » (prompt, appel d’outil, résultat) que listait la première version de la méthode ne sont pas un signal à part : ils relèvent des journaux et des traces, au titre de la capture du contenu (règle ci-dessous).

4. Le standard : OpenTelemetry GenAI

Base d’instrumentation à adopter : les conventions sémantiques OpenTelemetry GenAI, en statut Development. Leurs versions, leur historique (dont le passage dans un dépôt dédié depuis la 1.42), leurs attributs et la capture du contenu sont détaillés une seule fois sur le site, dans l’article Observer un système LLM, §2. La méthode s’appuie surtout sur gen_ai.request.model et gen_ai.response.model, gen_ai.provider.name, gen_ai.usage.input_tokens et gen_ai.usage.output_tokens (base du coût), gen_ai.response.finish_reasons (signal de fiabilité de premier ordre) et gen_ai.operation.name. Ses recording rules (partie II) partent des métriques des versions 1.40 et 1.41 (gen_ai.client.operation.duration, gen_ai.client.token.usage) : voir la note de révision en bas de page.

Règle de capture du contenu, alignée sur la spécification : les instrumentations ne capturent pas par défaut les instructions, les entrées et les sorties ; leur capture est un opt-in explicite. Trois usages : ne rien enregistrer (le défaut) ; enregistrer le contenu sur les spans (gen_ai.system_instructions, gen_ai.input.messages, gen_ai.output.messages), réservé aux cas où le volume reste maîtrisé et où le stockage respecte la réglementation, par exemple en préproduction ; stocker le contenu en externe et enregistrer une référence sur le span, usage que la spécification recommande en production. En environnement réglementé, la méthode retient le troisième, avec masquage au collecteur. Le contenu ne va jamais en label de métrique (voir le guide, 9.6).

---

Révisé le 2 octobre 2026 : depuis la version 1.42 (juin 2026), les conventions GenAI vivent dans le dépôt semantic-conventions-genai. À cette date, sa branche principale, dont les modifications ne sont pas encore publiées dans une version, classe gen_ai.client.operation.duration en métrique recommandée et non plus requise et remplace gen_ai.client.token.usage par des compteurs gen_ai.client.inference.usage.* (jetons d’entrée, de sortie, de cache et de raisonnement) et des histogrammes gen_ai.client.inference.operation.*. Vérifiez la version que votre instrumentation émet avant d’écrire vos règles.

Révisé le 4 octobre 2026 : signaux alignés sur les cinq du guide (les événements de contenu relèvent des journaux et des traces), table de correspondance vers les cinq couches de L’IA en coupe, échelle de maturité remplacée par les niveaux 0 à 5 du guide, rappel des conventions OpenTelemetry réduit à un résumé avec renvoi à l’article, règle de capture du contenu alignée sur la spécification.

Marquer comme lue