3. La feuille de route de maturité

La capacité d’observabilité de l’IA progresse sur six niveaux (de 0 à 5). Chaque niveau s’appuie sur le précédent. Une fonctionnalité d’IA livrée sans stratégie d’observabilité explicite reste au niveau 0 et un simple journal des appels la fait passer au niveau 1. À mon avis, l’objectif réaliste d’un programme de six mois est le niveau 3. Le niveau 5 est rare : il caractérise une organisation qui fait de l’observabilité le moteur de l’amélioration continue plutôt qu’une couche de supervision passive.

Cette échelle de 0 à 5 est la référence pour tous les contenus du site : la grille de maturité de la méthode GenAI et les jalons à 30, 60 et 90 jours des labs se lisent par rapport à ces niveaux.

Figure 5. L’échelle de maturité, du niveau 0 (exploitation à l’aveugle) au niveau 5 (boucle fermée). Le niveau 3 est, à mon avis, un objectif réaliste à six mois.

3.1 Niveau 0 : exploitation à l’aveugle

Le système tourne en production sans autre télémétrie que des métriques au niveau HTTP. Le coût se découvre sur la facture en fin de mois. La qualité se découvre par les réclamations des utilisateurs. C’est l’état par défaut d’une fonctionnalité LLM livrée sans stratégie d’observabilité explicite.

Les signes que vous êtes au niveau 0

• Vous ne savez pas dire combien de jetons ont été consommés hier, par fonctionnalité ou par locataire.
• Vous ne pouvez pas retrouver le prompt et la réponse liés à une réclamation précise.
• Vous découvrez les hallucinations uniquement par les signalements des utilisateurs.
• Vous n’avez aucune référence de comparaison au moment de changer de modèle.
• Votre seule remédiation possible est le retour arrière.

3.2 Niveau 1 : télémétrie de base

Des journaux structurés par requête capturent le prompt, la réponse, l’identité du modèle, le nombre de jetons et la latence. Le coût est calculé et agrégé. Les erreurs sont suivies sous forme de métriques.

Ce que vous gagnez

• L’attribution des coûts par fonctionnalité, utilisateur, locataire ou environnement.
• Des budgets de latence par modèle.
• Un historique interrogeable des requêtes passées pour l’analyse post-incident.

Ce qui vous manque encore

• L’exécution multi-étapes reste opaque : un RAG ou un agent ressemble à un seul appel LLM.
• Aucun signal de qualité en dehors des retours utilisateurs.
• Aucune détection de dérive.
• Aucun moyen de conditionner les changements à la qualité.

Le risque, à ce niveau, est de s’arrêter là et de stagner : les journaux seuls ne produisent aucune amélioration. Le passage au niveau 2 est celui qui débloque tout le reste.

3.3 Niveau 2 : traçage structuré

Adoption des conventions sémantiques OpenTelemetry GenAI. Chaque requête émet un arbre de traces avec un span par étape logique. Les spans sont interrogeables par attributs, notamment modèle, utilisateur, fonctionnalité et locataire.

Ce que vous gagnez

• La visualisation des flux RAG et agents sous forme d’arbres de traces.
• La décomposition de la latence par étape.
• Des attributs normalisés entre fournisseurs (pas d’enfermement propriétaire au niveau des données).
• L’interopérabilité avec l’infrastructure OpenTelemetry existante.

Composants nécessaires

• Une instrumentation compatible OTel (SDK OTel natifs, OpenLLMetry, ou OpenInference, qui exporte en OTLP avec ses propres attributs : voir le chapitre 6).
• Un OpenTelemetry Collector.
• Un dorsal de traces (trace backend) comme Tempo, Phoenix, SigNoz ou Jaeger.

3.4 Niveau 3 : évaluation en ligne

Chaque trace de production déclenche des évaluations automatiques. Les résultats sont rattachés comme attributs à la trace d’origine et exposés comme métriques pour l’agrégation. La qualité devient une mesure et non plus une déduction.

Évaluateurs courants à ce niveau

• Fidélité : la réponse est-elle ancrée dans le contexte fourni ?
• Pertinence de la réponse : la réponse traite-t-elle la question ?
• Conformité de format : la sortie respecte-t-elle le schéma attendu ?
• Toxicité : présence de contenu nuisible.
• Fuite de données personnelles : présence de données sensibles dans la sortie.

Ce que vous gagnez

• Un signal de qualité continu, indépendant des retours utilisateurs.
• Des régressions de qualité alertables, détectées avant que les utilisateurs ne les remarquent.
• Une référence pour comparer les changements de modèle et de prompt.

3.5 Niveau 4 : dérive et intégration des retours

Trois ajouts à une plateforme de niveau 3.

• Dérive des plongements : suivre dans le temps la distribution des plongements d’entrée et de sortie, avec la divergence de Kullback-Leibler, la distance de Wasserstein ou, plus simplement, des indices de stabilité de population (PSI).
• Qualité du RAG : suivre en lot la précision et le rappel de la recherche par rapport à un jeu de référence entretenu.
• Retours utilisateurs : capturer les pouces, les modifications, les nouvelles tentatives et les conversions, corrélés aux identifiants de trace.

Ce que vous gagnez

• Une alerte précoce quand la distribution des entrées change (nouveaux usages, tentatives de contournement (jailbreak), changements de langue).
• Un signal fiable de l’utilité réelle et pas seulement d’une qualité mesurée par une grille.
• Des données pour affiner les moteurs de recherche, les modèles de reclassement et les gabarits de prompts.
• La corrélation entre scores automatiques et satisfaction des utilisateurs (le signal le plus utile pour régler vos évaluateurs).

3.6 Niveau 5 : boucle fermée

Les données d’évaluation et de retours alimentent le système lui-même. C’est ce qui fait de l’observabilité un moteur d’amélioration plutôt qu’un dispositif de supervision passif.

• Les traces en échec deviennent des cas de test de non-régression en intégration continue.
• Les traces de haute qualité deviennent des exemples few-shot ou des données d’affinage (fine-tuning).
• La dérive déclenche une réindexation automatique ou une nouvelle sélection de modèle.
• Les retours entraînent des modèles de préférence ou des évaluateurs spécialisés.
• Les changements de modèle et de prompt sont conditionnés au jeu de non-régression.

Figure 6. La boucle fermée. Les traces de production alimentent l’évaluation et les retours, qui alimentent la curation des données, qui alimente l’itération sur les prompts et les modèles, laquelle est redéployée en production.

Suite : 4. La mise en œuvre en sept étapes.

Révisé le 4 octobre 2026 : échelle de 0 à 5 présentée comme la référence du site, avec renvoi vers la méthode et les labs.

Marquer comme lue