Introduction à l'observabilité : traces, juges et évaluations

Partie réécrite le 2 novembre 2026 d’après la documentation Observability de Mistral et le SDK mistralai 3.7.0 : l’observabilité repose désormais sur des traces OpenTelemetry explorées dans Studio, des juges LLM et des évaluations hors ligne (mistralai-evaluations). Les « Campaigns » et l’API chat_completion_events des anciennes leçons n’existent plus. Sources : Distributed tracing · Offline evaluations.

Pourquoi l’observabilité est indispensable

Vos tableaux de bord habituels — latence, taux d’erreur, disponibilité — peuvent rester verts pendant qu’un assistant répond à côté, invente une procédure ou change de ton après une mise à jour de prompt. Un LLM en production échoue rarement par une exception : il échoue par une mauvaise réponse, servie avec assurance. L’observabilité LLM consiste à rendre ces échecs visibles, mesurables et corrigeables.

Les trois piliers de l’observabilité

1. Visibilité — voir ce qui se passe

Chaque requête de votre application devient une trace : un arbre de spans qui représente chaque étape de l’exécution — appel au modèle, appel d’outil, étape de workflow —, avec son entrée, sa sortie, sa durée, ses tokens et son statut. Ces traces suivent le standard OpenTelemetry, et l’Explorer de Studio permet de les rechercher et de les inspecter.

2. Signaux de qualité — mesurer automatiquement

Relire des milliers de conversations à la main est impossible. Les juges sont des évaluateurs fondés sur un LLM, que l’on configure une fois — instructions, modèle, format de sortie — puis que l’on applique à des conversations ou à des enregistrements de jeux de données, pour obtenir un label ou un score.

3. Boucles d’itération — améliorer en continu

Les datasets rassemblent des cas de test, souvent tirés de traces réelles, et les évaluations hors ligne y mesurent une version de votre application — modèle, prompt, paramètres — avant de la déployer. On compare les versions, on garde la meilleure, et on recommence.

Les quatre composants

Prérequis et statut

Trois points sont à connaître avant de commencer :

• Statut : l’observabilité de Mistral est en Private Preview, et son intégration au SDK évolue vite. Mistral recommande la dernière version du SDK.
• Envoyer des traces ne demande qu’une clé d’API valide. Le traçage est désactivé par défaut et s’active source par source (leçon suivante).
• Lire les traces dans Studio exige une organisation Enterprise et un rôle adapté (Org Admin, Workspace Admin ou Observability Viewer). Les évaluations hors ligne, et l’ajout de spans à un dataset, sont également réservés aux organisations Enterprise. Les traces sont conservées 30 jours.

Si votre organisation n’y a pas accès, cette partie reste un bon investissement : les concepts — tracer, juger, constituer des jeux de test, évaluer avant de déployer — valent pour n’importe quel outillage OpenTelemetry.

Le workflow typique

Les composants s’enchaînent dans une boucle :

1. Tracer et explorer — vous instrumentez l’application, puis repérez dans l’Explorer les traces problématiques (erreurs, lenteurs, réponses douteuses)
2. Juger — vous créez un juge qui formalise le critère de qualité en cause
3. Constituer un dataset — vous transformez des spans réels en cas de test
4. Évaluer — vous mesurez la version actuelle, puis chaque variante, sur ce dataset

Chaque cycle vous rapproche d’un système plus fiable et mieux calibré.

Points clés à retenir

• L’observabilité LLM rend visibles des échecs que le monitoring classique ne voit pas : les mauvaises réponses
• Traces OpenTelemetry (et leur Explorer), juges, datasets et évaluations hors ligne forment la boucle d’amélioration
• L’observabilité Mistral est en Private Preview ; envoyer des traces ne demande qu’une clé, les lire et évaluer hors ligne exigent une organisation Enterprise
• Les traces sont conservées 30 jours