---
title: Observabilité LLM : les 6 métriques à suivre avant de passer à l'échelle
description: Coût, latence, erreurs, qualité par évals, usage, dérive : la checklist des 6 métriques d'observabilité LLM à suivre avant la montée en charge.
url: https://keltio.fr/blog/observabilite-llm-les-6-metriques-a-suivre-avant-de-passer-a-l-echelle
author: Keltio
language: fr
---

# Observabilité LLM : les 6 métriques à suivre avant de passer à l'échelle


Un service LLM peut se dégrader sans qu'aucune alerte classique ne se déclenche : les requêtes répondent en 200, la latence reste correcte, mais les réponses sont moins justes depuis le dernier changement de modèle. Le monitoring applicatif ne suffit pas. Voici les six métriques que nous mettons en place avant toute montée en charge, avec ce qu'il faut mesurer, comment le découper et quand alerter.

## Le prérequis : une trace par appel, avec des dimensions métier

Chaque métrique ci-dessous n'est utile que si elle peut être découpée. Une moyenne globale masque presque tous les problèmes : un agent qui dérive parmi quatre, une langue qui échoue, un client dont les données sont atypiques.

Chaque appel au modèle produit donc une trace avec au minimum :

- l'identifiant de la feature ou de l'agent (assistant de rédaction, agent de réponse, connecteur) ;
- le client (tenant), et si pertinent l'entité métier : marque, enseigne, restaurant, canal de vente ;
- la langue et le type de document ou de requête ;
- le modèle et sa version exacte, la version du prompt, la version de l'index RAG ;
- les tokens (entrée, entrée lue en cache, sortie), la latence, le statut.

Les conventions sémantiques OpenTelemetry pour l'IA générative (attributs `gen_ai.*`, comme `gen_ai.request.model` ou `gen_ai.usage.input_tokens`) donnent une base de nommage. Des outils open source comme Langfuse ou Arize Phoenix stockent et visualisent ces traces ; un entrepôt de données classique fait aussi l'affaire.

```python
with tracer.start_as_current_span("llm.call") as span:
    span.set_attribute("gen_ai.request.model", model)
    span.set_attribute("app.feature", "reponse_avis")
    span.set_attribute("app.tenant_id", tenant_id)
    span.set_attribute("app.brand", brand)
    span.set_attribute("app.lang", lang)
    span.set_attribute("app.prompt_version", "reponse_avis@v14")
    resp = client.generate(model=model, messages=messages)
    span.set_attribute("gen_ai.usage.input_tokens", resp.usage.input_tokens)
    span.set_attribute("gen_ai.usage.output_tokens", resp.usage.output_tokens)
```

## 1. Coût par requête, par client et par feature

**Ce qu'on mesure** : le coût de chaque appel, calculé à partir des tokens et d'une grille tarifaire versionnée, puis agrégé par feature, par client et par unité métier (dossier, conversation, réservation).

**Pourquoi** : une fonctionnalité IA peut devenir déficitaire sur certains clients sans que la facture globale n'alerte. Chez un éditeur, le coût d'inférence par client devient vite un sujet de marge, surtout sur des contrats à prix fixe.

**Découpage utile** :

- coût moyen et coût au 95e centile par requête (les requêtes extrêmes révèlent les contextes qui explosent) ;
- coût mensuel par client rapporté à son abonnement ;
- coût par feature, pour savoir laquelle optimiser en premier ;
- part des tokens lus en cache, pour vérifier que le cache fonctionne toujours.

**Alerte** : coût par unité métier supérieur de 50 % à sa moyenne mobile sur 7 jours ; client qui dépasse son budget.

## 2. Latence

**Ce qu'on mesure** : trois temps distincts, car ils ne se dégradent pas pour les mêmes raisons.

- **Temps jusqu'au premier token** (TTFT) : ce que l'utilisateur perçoit en streaming. Il dépend de la taille du contexte, de la file d'attente chez le fournisseur et du cache.
- **Débit de génération** (tokens par seconde) : détermine la durée des longues réponses.
- **Latence de bout en bout** : du clic à la réponse complète, en incluant la recherche RAG, les appels d'outils, et pour la voix la transcription et la synthèse.

Suivez les percentiles 50, 95 et 99, jamais la moyenne seule.

**Pourquoi** : dans un usage en direct (webinar traduit, agent vocal, assistant de réservation au téléphone), la latence compte autant que la justesse. Un agent vocal qui met trois secondes à répondre perd l'interlocuteur, même si sa réponse est parfaite.

**Découpage utile** : par langue, par client, par modèle, par étape de la chaîne. Une langue peut être plus lente parce qu'elle consomme plus de tokens pour le même texte.

**Alerte** : p95 au-delà d'un seuil défini par usage (par exemple un budget de latence par tour de conversation pour la voix).

## 3. Taux d'erreur et d'hallucination

Deux familles à ne pas confondre.

**Les erreurs techniques**, faciles à compter :

- limitations de débit (HTTP 429), erreurs serveur, délais dépassés ;
- sorties tronquées (limite de tokens de sortie atteinte) ;
- JSON invalide ou non conforme au schéma attendu ;
- appels d'outils en échec, boucles d'agent qui atteignent leur nombre maximal d'itérations ;
- refus du modèle.

**Les erreurs de contenu**, plus difficiles à mesurer :

- **hallucination factuelle** : un prix, un stock, une date ou une référence juridique inventés ;
- **infidélité aux sources** en RAG : une affirmation absente des documents fournis ;
- **erreur de ton ou de périmètre** : un message rédigé au nom d'un client qui sort de sa charte.

Pour les secondes, trois méthodes se combinent : contrôles déterministes (le prix cité existe-t-il dans le catalogue ? la citation renvoie-t-elle à un passage réel ?), notation par un modèle juge sur un échantillon, et revue humaine d'un échantillon plus petit.

**Découpage utile** : par agent, par langue, par client. Quand un agent écrit au nom de vos clients, son taux d'erreur par client protège aussi leur réputation et, pour l'email, leur délivrabilité.

**Alerte** : taux d'erreur technique au-delà de 1 à 2 % sur une heure ; hausse du taux d'échec des contrôles déterministes.

## 4. Qualité mesurée par des évaluations automatiques

C'est la métrique la plus souvent absente, et la plus importante avant de changer de modèle ou de prompt.

**Le principe** : pour chaque assistant ou agent, un jeu d'évaluation de cas réels (50 à 300 au départ), avec des critères notés automatiquement.

- Critères déterministes quand c'est possible : champ extrait correct, code attendu présent, format respecté.
- Modèle juge avec une grille explicite pour le reste : exactitude, complétude, ton, respect des sources.
- Calibration du juge sur quelques dizaines de cas notés par un expert métier.

Dans un produit de santé, par exemple, un jeu d'évaluation pour un agent de rédaction de notes vérifie la présence des éléments cliniques attendus, et un autre pour un agent de codage vérifie les codes proposés contre une référence validée. Un changement de modèle qui dégrade l'un sans l'autre se voit immédiatement.

**Quand les faire tourner** :

- à chaque changement de modèle, de version de modèle, de prompt ou d'index RAG, en CI, avant mise en production ;
- en continu sur un échantillon du trafic réel (évaluation en ligne, sans référence, avec le juge).

**Pourquoi par assistant** : avec plusieurs assistants en production, la question n'est pas « le nouveau modèle est-il meilleur ? » mais « lequel de mes assistants se dégrade ? ». Sans évals par assistant, c'est le support qui vous l'apprend.

**Alerte** : baisse du score au-delà d'un seuil fixé à l'avance ; blocage du déploiement en CI.

## 5. Usage par feature

**Ce qu'on mesure** : volume de requêtes, utilisateurs actifs, requêtes par utilisateur, taux d'adoption par feature et par client. Et surtout des signaux de résultat :

- taux d'acceptation d'une suggestion (réponse envoyée telle quelle, modifiée, rejetée) ;
- taux de relance ou de reformulation de la même question ;
- taux d'abandon de la conversation ;
- signal métier aval : offre acceptée ou rejetée par une marketplace, ticket rouvert, réservation annulée.

**Pourquoi** : l'usage révèle ce que les métriques techniques ne voient pas. Sur un connecteur qui laisse vos clients interroger leurs données via leur propre assistant, suivre les questions posées, les erreurs et la latence par type de question montre vite lesquelles posent problème. Sur un flux de descriptions produit, le taux de rejet par canal de vente est souvent le premier indicateur d'un problème de modèle.

**Découpage utile** : par feature, par client, par canal, par type de question (classé automatiquement).

**Alerte** : chute d'usage ou hausse du taux de rejet sur un segment.

## 6. Dérive

La dérive est ce qui change sans que vous ayez rien déployé. Elle a quatre sources :

- **Le modèle** : le fournisseur met à jour un alias, retire une version, modifie un filtrage. Épinglez des versions précises plutôt que des alias « latest ».
- **Les entrées** : les utilisateurs posent d'autres questions, une nouvelle marque arrive avec un catalogue atypique, une nouvelle langue apparaît.
- **Le contexte récupéré** : l'index RAG grossit, des documents obsolètes remontent, des exemples ajoutés en continu à la boucle d'apprentissage finissent par tirer les réponses dans une mauvaise direction.
- **Le monde** : réglementation, prix, offres qui changent alors que le prompt ne bouge pas.

**Ce qu'on mesure** :

- distribution des entrées (longueur, langue, type de document, thèmes) comparée à une période de référence ;
- distribution des sorties (longueur, taux de refus, format, sentiment) ;
- score d'évaluation en ligne sur une fenêtre glissante ;
- score du jeu d'évaluation fixe, rejoué chaque semaine même sans déploiement.

**Découpage utile** : par agent, par modèle, par type de document, par marque ou enseigne, par client. Une dérive de qualité sur un seul segment passe inaperçue dans la moyenne. Une réponse d'avis mal calibrée pour une enseigne se voit publiquement ; une hallucination sur le stock d'une marque se voit avant un pic commercial.

**Alerte** : écart significatif de distribution sur une semaine, baisse du score en ligne sur un segment.

## Encadré : checklist avant montée en charge

Traces

- Chaque appel est tracé avec feature ou agent, client, langue, modèle et version, version du prompt.
- Les traces sont conservées selon une politique compatible RGPD (données personnelles masquées ou durée limitée).

Coût

- Coût par requête, par client et par feature visible sur un tableau de bord.
- Budget par client et alerte d'anomalie en place.

Latence

- TTFT, débit et latence de bout en bout suivis en p50, p95, p99.
- Budget de latence défini pour chaque usage temps réel.

Erreurs

- Erreurs techniques comptées par type (429, 5xx, timeout, JSON invalide, troncature, refus).
- Contrôles déterministes contre les hallucinations critiques (prix, stock, références).

Qualité

- Un jeu d'évaluation par assistant ou agent, rejoué en CI à chaque changement.
- Évaluation en ligne sur un échantillon du trafic, juge calibré par un expert.

Usage

- Taux d'acceptation, de reformulation et d'abandon par feature.
- Au moins un signal métier aval suivi par canal ou par client.

Dérive

- Versions de modèles épinglées.
- Jeu d'évaluation rejoué chaque semaine sans déploiement.
- Comparaison hebdomadaire des distributions d'entrées et de sorties par segment.

## Par où commencer

1. Ajoutez aux traces existantes les dimensions feature, client, langue, modèle et version de prompt.
2. Construisez un premier jeu d'évaluation de 50 cas réels pour l'assistant le plus utilisé, avec une grille de notation écrite par un expert métier.
3. Branchez ce jeu d'évaluation en CI pour qu'il bloque tout changement de modèle ou de prompt qui dégrade le score.
4. Mettez en place trois alertes : coût par client, latence p95, taux d'erreur technique.
5. Planifiez un rejeu hebdomadaire des évaluations pour détecter la dérive sans attendre un déploiement.

Nous accompagnons les éditeurs dans la mise en place de l'observabilité et des évaluations de leurs fonctionnalités IA. Si vous voulez en parler : contact@keltio.fr