Vous monitorez vos API avec Prometheus, vous tracez vos microservices avec Jaeger. Mais vos appels LLM ? Ils arrivent comme une boîte noire dans vos logs. Voici comment instrumenter sérieusement une application IA.  

Le problème avec "ça marche, non ?"

Quand on demande à une équipe si son intégration LLM est monitorée, la réponse est souvent la même : "Oui, on a les temps de réponse et les codes HTTP."  C'est comme dire qu'on monitore une base de données en regardant uniquement si les requêtes renvoient un 200. Un LLM peut répondre 200 OK en 800ms et produire une réponse complètement hors-sujet, halluciner un fait critique, ou dépenser 10× le budget token prévu. Aucun de ces problèmes n'apparaît dans vos métriques classiques. Le vrai contrat d'un LLM n'est pas technique, il est sémantique. Ce n'est pas "est-ce que l'API a répondu ?" mais "est-ce que la réponse était juste, utile, et dans les clous du business ?"    

Les 4 dimensions de l'observabilité LLM

1.La dimension opérationnelle (ce que vous avez déjà)

Latence, taux d'erreur, disponibilité — les métriques RED classiques. Elles restent indispensables, mais elles ne couvrent qu'une fraction du problème. Note sur le streaming : si vous servez des réponses en stream (SSE), la latence globale est une mauvaise métrique. Ce qui compte pour l'UX, c'est le time to first token — le délai avant que le premier caractère apparaisse à l'écran.  

2.La dimension économique (ce que vous regardez rarement)

Les tokens coûtent de l'argent. Mais le coût par requête varie d'un facteur 10 ou 20 selon comment vous construisez vos prompts. Sans visibilité fine sur la consommation, vous découvrez le dérapage sur la facture du mois suivant. L'attribut llm.feature est souvent oublié. Sans lui, impossible de savoir si c'est votre feature de résumé ou votre chatbot qui explose votre budget.  

3.La dimension qualité (ce qui est difficile à mesurer)

C'est là que ça devient intéressant — et complexe. Comment détecter automatiquement qu'une réponse est mauvaise ? La stratégie pragmatique : commencer par les assertions structurelles et le feedback utilisateur. Le LLM-as-judge est puissant mais coûteux — réservez-le à l'évaluation offline ou aux cas critiques.  

4.La dimension sécurité & dérive (ce qu'on oublie)

Les prompts de vos utilisateurs évoluent. Si vous ne les analysez pas dans le temps, vous raterez deux phénomènes dangereux :

• Le prompt drift : la distribution des inputs change, et votre système prompt n'est plus adapté.
• Les tentatives d'injection : des patterns inhabituels qui tentent de contourner vos guardrails.

 

L'outillage en 2026 : ce qui existe vraiment

L'écosystème s'est structuré autour de quelques approches. Voici un état des lieux honnête. OpenTelemetry reste la base. Le Semantic Conventions GenAI d'OTel standardise enfin les attributs LLM (gen_ai.system, gen_ai.usage.input_tokens, etc.). Adoptez-les dès maintenant pour ne pas avoir à tout refactorer dans 6 mois. Langfuse et Arize Phoenix sont les deux solutions open-source les plus matures pour la traçabilité spécifique LLM. Langfuse est particulièrement bien intégré avec LangChain et LlamaIndex. Si vous êtes déjà sur un stack Datadog ou Grafana, des intégrations natives existent — privilégiez-les plutôt qu'un outil de plus à maintenir. Pour les équipes qui ne veulent pas gérer d'infrastructure supplémentaire : envoyez vos traces enrichies directement dans votre stack existante. Un attribut llm.feature dans vos spans Jaeger, c'est déjà 80% de la valeur.  

Ce qu'il faut instrumenter en premier

Si vous partez de zéro, voici l'ordre de priorité : 1.Les tokens input/output par feature — pour comprendre d'où vient le coût. 2.Le TTFT en streaming — l'UX en dépend directement. 3.Le taux de régénération — signal proxy fort de la qualité perçue. 4.Les erreurs fournisseur — rate-limits et timeouts avec backoff. 5.Les assertions structurelles — validation de format en sortie. Ne cherchez pas à tout mesurer d'un coup. Un dashboard de 5 métriques actionnable est infiniment plus utile que 50 graphiques que personne ne regarde. L'observabilité LLM, ce n'est pas une couche supplémentaire à ajouter après coup. C'est une contrainte de conception. Si vous ne savez pas aujourd'hui combien coûte votre feature IA par utilisateur actif, si vous ignorez où vos réponses se dégradent, vous pilotez à l'aveugle. Et dans un domaine où les coûts et la qualité sont aussi volatils que les modèles eux-mêmes, ça ne pardonne pas longtemps.