Observabilité des applications LLM : suivi, coûts, latence, dérive de la qualité

Les applications LLM se dégradent autrement que les logiciels traditionnels. Une anomalie classique produit une pile d’appels ; une anomalie liée à un LLM peut être une dérive de qualité que l’on ne remarque qu’après les plaintes des utilisateurs. Une latence classique vient d’un point de terminaison lent ; avec un LLM, elle peut prendre la forme d’un raisonnement de 30 secondes pendant lequel l’utilisateur fixe un indicateur de chargement.

L’observabilité traditionnelle — Datadog, New Relic ou Sentry — indique qu’un appel d’API a réussi en 8,4 secondes et consommé 12 847 jetons en entrée. Elle ne précise pas si la réponse était bonne, si le modèle a inventé des informations, si le mauvais outil a été appelé ou si la qualité a dérivé depuis la semaine précédente.

Les systèmes LLM en production ont besoin d’une pile d’observabilité différente. Ou du moins, de couches supplémentaires sur les systèmes traditionnels. Cet article couvre ce qui est distinct, ce qu’il faut instrumenter et les modèles qui fonctionnent.

Ce qui est différent dans l’observabilité LLM

Quelques caractéristiques des systèmes LLM que l’observabilité traditionnelle ne traite pas :

Non-déterminisme de chaque appel. Une même entrée peut produire des résultats différents. Les codes d’état ne suffisent pas à déterminer si le traitement a correctement fonctionné.

La qualité comme métrique principale. La latence et le coût comptent, mais la qualité est la plus importante — et la plus difficile à mesurer.

Traces multi-étapes. Une requête utilisateur peut déclencher 5 à 50 appels LLM (boucles agent, récupération RAG, extraction structurée, réflexion). Chaque appel fait partie d’une trace plus large.

Variabilité des coûts par jeton. Un appel peut coûter de 0,001 € à 1,00 € selon la taille du prompt, la longueur du résultat et le modèle. Le suivi des coûts cumulés exige une attribution par appel.

Dérive au fil du temps. Les modèles sont mis à jour. Les prompts évoluent. Les distributions d’entrée changent. La qualité se déplace ; vous devez voir ce mouvement.

Charges utiles sensibles. Les entrées et sorties sont souvent les données diagnostiques les plus précieuses, mais aussi les plus sensibles. La discipline de journalisation est essentielle.

Flux asynchrones longs. Des exécutions d’agents qui prennent des minutes. Des tâches en arrière-plan. Des réponses en flux. L’observabilité traditionnelle de la demande/réponse ne s’applique pas.

Ce ne sont pas des préoccupations théoriques. Toute équipe en production exécutant des systèmes LLM les rencontre.

La pile d’observabilité

Une pile d’observabilité LLM complète comprend les couches suivantes :

1. Instrumentation au niveau de l’appel. Chaque appel LLM est journalisé : entrée, sortie, latence, coût, modèle, statut.

2. Instrumentation au niveau de la trace. Les flux comportant plusieurs appels sont regroupés en traces afin d’afficher la chaîne complète correspondant à une demande.

3. Métriques au niveau de l’application. Agrégations par fonctionnalité, par utilisateur, par client.

4. Surveillance de la qualité. Évaluation automatique de la qualité sur des échantillons ou complète.

5. Capture des retours utilisateurs. Signaux explicites — pouce levé ou baissé — et implicites — nouvelle génération ou abandon.

6. Alertes. Alertes en temps réel sur les pics de coûts, la dégradation de la latence, la baisse de la qualité, l’augmentation du taux d’erreur.

7. Outils de débogage. Lorsqu’une chose se brise, vous pouvez trouver la trace, voir les entrées et sorties, comprendre ce qui s’est passé.

Nous aborderons chacun de ces points.

Instrumentation au niveau de l’appel

Chaque appel LLM devrait produire un enregistrement de journal avec :

{
  "call_id": "uuid",
  "timestamp": "2026-05-15T14:23:45Z",
  "trace_id": "uuid",  // for grouping into traces
  "span_id": "uuid",   // for parent-child relations
  "feature": "summarize_document",
  "prompt_version": "v3.2",
  "model": "claude-4-sonnet",
  "provider": "anthropic",
  "input_messages": [...],
  "output_message": "...",
  "input_tokens": 1842,
  "output_tokens": 384,
  "total_tokens": 2226,
  "cost_usd": 0.0084,
  "latency_ms": 2340,
  "first_token_ms": 1240,  // streaming
  "status": "success",
  "error": null,
  "user_id": "user_123",
  "tenant_id": "tenant_45",
  "metadata": {
    "session_id": "...",
    "experiment_arm": "v3_test"
  }
}

Il s’agit du minimum. Consignez tous ces champs.

Choix clés d’implémentation :

Où journaliser. Options :

• Un outil dédié à l’observabilité (Helicone, LangSmith, Phoenix, Braintrust, Arize).
• Une plateforme d’observabilité générale avec des extensions LLM (Datadog LLM Observability, Sentry).
• Vos propres journaux/base de données.

Pour la plupart des équipes, un outil dédié est préférable. Ces solutions offrent des interfaces conçues pour examiner les appels LLM, avec une courbe d’apprentissage modérée par rapport au développement d’un outil interne.

Pour les grandes équipes : un mélange. Utilisez un outil dédié pour l’interface utilisateur spécifique LLM, mais envoyez également les données à votre plateforme d’observabilité centrale pour la corrélation entre systèmes.

Comment instrumenter. Options :

• Une passerelle située entre l’application et le fournisseur LLM, comme Helicone.
• Un SDK d’instrumentation intégré au code de l’application.
• Une classe d’adaptation appelée manuellement pour chaque appel LLM.

Les passerelles sont les plus simples, mais ajoutent de la latence. Les SDK offrent une intégration propre, au prix d’un travail initial. L’instrumentation manuelle est la plus flexible, mais aussi la plus facile à oublier.

Approche pragmatique : instrumentez, au moyen d’un SDK, le point unique où l’application appelle le LLM. Tout le trafic passe ainsi par un seul emplacement contrôlé.

Ce qu’enregistrer. Quelques considérations pratiques :

• Tronquer les entrées/sorties très longues (mais enregistrer la troncature).
• Hacher ou masquer les données à caractère personnel, tout en permettant si nécessaire de retrouver l’original par une recherche séparée et sécurisée.
• Ne jamais consigner les identifiants et secrets d’authentification, même dans les chemins d’erreur.
• Pour la diffusion en continu, enregistrer à la fois le délai avant le premier jeton et la latence totale.

Instrumentation au niveau de la trace

Une seule action utilisateur implique souvent de nombreux appels LLM. Sans instrumentation au niveau de la trace, vous avez mille journaux d’appel et aucun moyen de savoir quels appels faisaient partie de quelle action utilisateur.

Implémentation :

Génération de l’ID de trace. Générez un ID de trace unique au début d’une requête utilisateur. Transmettez-le à tous les appels suivants.

Segments parent-enfant. Dans une trace, chaque appel possède un identifiant de segment et, facultativement, celui de son parent. L’ensemble forme un arbre qui représente la hiérarchie des appels.

Nommage des opérations. Chaque segment porte un nom, tel que « summarize_document », « extract_entities » ou « tool_call:search ». La trace affiche ainsi la chaîne complète des opérations.

Une vue de trace dans votre interface utilisateur :

Trace abc-123 (12.3s total)
├─ classify_intent (450ms) [gpt-5-mini]
├─ retrieve_documents (1.2s) [embedding + search]
├─ generate_response (8.5s) [claude-4-sonnet]
│   ├─ tool_call: search_internal (320ms)
│   ├─ tool_call: lookup_customer (180ms)
│   └─ generate_final_text (7.5s)
└─ judge_response_quality (2.1s) [claude-4-haiku]

Maintenant, vous pouvez voir ce que votre système a fait pour cette requête utilisateur. Vous pouvez trouver les appels lents, coûteux, échoués — dans le contexte.

Outils qui gèrent bien cela : LangSmith, Phoenix (Arize), Helicone avec une intégration personnalisée. Plus les outils d’observabilité généraux (Datadog, OpenTelemetry) pour le suivi inter-systèmes.

Métriques au niveau de l’application

Au-delà des appels individuels, des métriques agrégées :

Par fonctionnalité.

• Volume d’appels.
• Latence moyenne.
• Latence p50, p95, p99.
• Coût moyen par appel.
• Taux d’erreur.
• Score de qualité (si mesuré).

Par utilisateur/par client.

• Appels par utilisateur par jour.
• Coût par utilisateur.
• Utilisateurs intensifs et comportements abusifs.

Par modèle.

• Volume par modèle.
• Part de coût par modèle.
• Taux d’erreur par modèle.
• Qualité (si mesurée) par modèle.

Par fonctionnalité × par modèle.

• Quelles fonctionnalités utilisent quels modèles ?
• Où pourrions-nous diriger vers des modèles moins coûteux ?

Ces tableaux de bord influencent les décisions opérationnelles : quelles fonctionnalités sont coûteuses, lentes, nécessitent une optimisation.

Surveillance de la qualité

La couche la plus difficile : évaluation automatique de la qualité.

Pour les évaluations (que nous avons abordées séparément), vous les exécutez sur un ensemble de données défini. Pour la surveillance de la qualité en ligne, vous évaluez le trafic de production.

Approches :

Juge LLM sur un échantillon. Échantillonnez, disons, 1 % du trafic de production. Pour chacun, exécutez un juge LLM qui évalue la réponse sur des dimensions pertinentes. Suivez les scores au fil du temps. Alertez en cas de baisse.

Signaux implicites. Suivez les régénérations, les abandonnements, les taux d’erreur, le temps de complétion, la fréquence des messages de suivi. Ce sont des signaux faibles mais peu coûteux. Utilisez-les comme indicateurs précurseurs.

Retour explicite des utilisateurs. Boutons de vote (pouce haut/bas), “a-t-il aidé ?” boutons, rapports explicites. Le signal le plus fort mais le volume le plus faible.

Détection de motifs. Des motifs spécifiques de mauvaise qualité (“Je ne peux pas vous aider avec cela”, “Je suis juste un IA”, refus répétés) signalés automatiquement. Détecte certains régressions immédiatement.

Une configuration type :

• Échantillonnez 1 % du trafic de production.
• Exécutez un juge LLM sur chacun, évaluant multidimensionnellement.
• Agrégez en scores quotidiens par fonctionnalité.
• Alertez si une fonctionnalité baisse de plus de 10 % semaine sur semaine.

Le coût est réel mais limité (1 % du trafic × petit modèle juge = gérable pour la plupart des équipes).

Observabilité des coûts

Les coûts LLM peuvent s’envoler. Un seul bug — une boucle de réessai infinie, une fonctionnalité qui utilise 10 fois plus de tokens que prévu — peut produire une facture 10 fois plus élevée avant que personne ne s’en aperçoive.

Couches d’observabilité des coûts :

Coût par appel. Le coût de chaque appel calculé au moment du journal. Les agrégations sont disponibles immédiatement.

Alertes budgétaires. Budgets quotidiens, hebdomadaires, mensuels par fonctionnalité/client. Alertez lorsqu’on franchit les seuils (50 %, 75 %, 90 %, 100 %).

Détection d’anomalies. Le coût quotidien est 5 fois plus élevé que la normale ? Alertez. Le coût d’un seul appel est 100 fois plus élevé que la normale ? Alertez.

Attribution des coûts. Coûts par fonctionnalité, par client, par utilisateur. Identifiez les principaux contributeurs.

Prévision. En se basant sur la trajectoire actuelle, quelle sera la facture à la fin du mois ?

Une vue utile du tableau de bord : un seul panneau montrant le coût d’aujourd’hui par rapport au reste de la semaine et à la semaine précédente, détaillé par fonctionnalité.

Conseil pratique : définissez des limites strictes lorsque cela est possible. Une fonctionnalité censée coûter X € par jour doit être arrêtée automatiquement à 10 × X. Une dérive des coûts peut être très rapide ; cette limite l’interrompt.

Observabilité de la latence

La latence LLM est plus nuancée que les API classiques :

Latence totale. De la demande à la réponse finale.

Délai avant le premier jeton (TTFT). En diffusion continue, quand l’utilisateur voit-il le premier caractère ? Cette mesure détermine largement la latence perçue dans une interface de conversation.

Temps jusqu’au dernier token (TTLT). Combien de temps avant que la réponse soit complète ?

Jetons par seconde. Débit de génération. Certains modèles diffusent leurs résultats plus lentement que d’autres.

Latence des appels d’outils. Pour les flux d’agents, le temps passé dans les appels d’outils par rapport aux appels LLM.

Suivez tous ces éléments. Différentes stratégies d’optimisation ciblent différentes métriques.

Pour une interface de conversation, le TTFT est déterminant. Un premier jeton tardif donne l’impression d’un système défaillant, tandis qu’un faible débit semble simplement progressif.

Pour les lots : la latence totale compte ; le débit compte davantage.

Pour les agents : la latence des appels d’outils domine souvent ; optimiser le LLM n’aide pas si les outils sont lents.

Observabilité des erreurs

Erreurs spécifiques LLM :

Erreurs d’API. Limites de débit, échecs d’authentification et erreurs serveur, comme pour toute autre API.

Erreurs de validation. La sortie structurée ne correspond pas au schéma. Suivez la fréquence par fonctionnalité.

Erreurs de filtre de contenu. Le fournisseur a bloqué la demande. Suivez pour détecter les problèmes de prompt.

Erreurs d’outils. Échecs d’outils spécifiques. Suivez par outil.

Erreurs de qualité. Le juge LLM a évalué la sortie comme mauvaise. Suivez au fil du temps.

Signaux d’informations inventées. Détection des cas probables où le modèle affirme un élément absent de la source. Cette détection automatique est difficile, mais peut être approximée.

Erreurs de coût. Appels qui coûtent beaucoup plus que prévu. Souvent indiquent un bug.

Chacun a son propre tableau de bord. Chacun peut déclencher des alertes.

Outils de débogage

Lorsqu’une chose se brise, vous devez la trouver et la comprendre. La surface de débogage inclut :

Recherche de trace. Trouvez une requête utilisateur spécifique par ID de trace, ID utilisateur ou horodatage.

Inspecteur d’appel. Pour tout appel, voyez la demande complète, la réponse, les paramètres, la latence, le coût.

Chronologie de trace. Pour les flux complexes, voyez la chaîne d’appels visuellement.

Capacité de relecture. Étant donné un ancien appel, pouvez-vous le relancer avec un autre prompt/modèle et voir ce qui se serait produit ? Essentiel pour tester les correctifs.

Vue de comparaison. Comparez deux appels — différentes versions du même prompt, différents modèles — côte à côte.

Recherche par contenu. Recherchez le corpus des appels passés pour des motifs spécifiques (“affichez les appels où le modèle a dit ‘Je ne peux pas vous aider’”).

Ces capacités sont ce que les outils dédiés à l’observabilité LLM fournissent. Construire vous-même est un travail considérable ; utiliser un outil est généralement moins coûteux.

Confidentialité et données à caractère personnel

Les journaux d’observabilité des LLM sont sensibles. Les entrées comme les sorties peuvent contenir des données à caractère personnel. Leur conservation est parfois nécessaire au diagnostic, mais doit rester strictement encadrée.

Pratiques :

Pseudonymisation et hachage. Remplacez les identifiants par des jetons. L’original ne doit être accessible que par une recherche séparée et sécurisée, afin que la majorité des journaux ne contienne aucune donnée personnelle directement identifiable.

Expurgation avant journalisation. Détectez et masquez les données personnelles avant leur arrivée dans le stockage d’observabilité. Remplacez les adresses e-mail, numéros de téléphone ou identifiants nationaux par des marqueurs neutres.

Isolation par client. Dans un système mutualisé, isolez strictement les données d’observabilité de chaque client afin qu’elles ne soient jamais visibles par un autre.

Contrôles d’accès. Limitez l’accès aux entrées et sorties brutes et journalisez toute consultation.

Politiques de conservation. Supprimez les journaux de plus de X jours ou déplacez-les vers un stockage d’archives approprié. La conservation des données personnelles est juridiquement limitée dans de nombreuses juridictions.

Droit à l’effacement. Lorsqu’un utilisateur exerce ce droit au titre du RGPD, ses journaux doivent pouvoir être retrouvés et supprimés.

Ces pratiques sont indispensables pour tout système qui traite des données personnelles. Mettez-les en place dès le départ ; leur ajout a posteriori est difficile et risqué.

Alertes

Seuils et signaux qui justifient des alertes :

Coûts.

• Coût quotidien > 2 fois la normale.
• Coût d’un seul appel > 5 €.
• Pic de coût horaire > 5 fois.

Latence.

• Latence p95 > 2 fois la normale.
• TTFT > 5 s pour l’UX de chat.
• Augmentation des temps d’expiration des appels d’outils.

Taux d’erreur.

• Taux d’erreur > 1 % (la normale typique est de 0,1 à 0,5 %).
• Pic d’un type d’erreur spécifique (erreurs de validation, limites de taux).

Qualité.

• Score de qualité baissé > 10 % semaine sur semaine sur toute fonctionnalité.
• Taux de retours négatifs des utilisateurs > seuil.
• Taux de régénération > seuil.

Motifs.

• Phrases spécifiques mauvaises apparaissant plus souvent.
• Changement soudain de la distribution d’entrée.

Chaque alerte doit être précise et permettre une action. « Le coût est élevé » est peu utile ; « la fonctionnalité X a consommé dix fois son budget en 30 minutes, probablement à cause d’une boucle dans la session du client Y » permet d’agir.

Considérations relatives aux environnements mutualisés

Pour les applications SaaS B2B :

Métriques par client. Chaque client peut voir son propre usage, coûts et qualité.

Alertes par client. Spécifiques à leurs seuils.

Diagnostic par client. L’équipe d’assistance peut consulter les traces d’un client, sous réserve des contrôles d’accès appropriés.

Configuration par client. Certains clients peuvent avoir des modèles, prompts ou politiques différents. La couche d’observabilité reflète cela.

Cette approche ajoute de la complexité, mais elle est essentielle pour un service B2B à grande échelle. L’assistance ne peut pas diagnostiquer une plainte telle que « l’IA ne fonctionne pas pour moi » sans accès aux traces du client concerné.

Écosystème d’outils (2026)

Une vue d’ensemble des outils d’observabilité LLM à l’écriture de cet article :

Observabilité dédiée aux LLM :

• Helicone. Basé sur un proxy ; simple à intégrer ; tableaux de bord solides.
• LangSmith. Lié à l’écosystème LangChain ; suivi approfondi.
• Phoenix (Arize). Adapté à l’open source et performant pour la surveillance de la qualité.
• Braintrust. Fort sur les évaluations + observabilité combinées.
• PromptLayer. Axé sur les prompts ; solide sur le suivi des versions.
• Weights & Biases Weave. Adapté aux équipes de ML et intégré à l’écosystème W&B.

APM général avec extensions LLM :

• Datadog LLM Observability. Niveau entreprise ; coûteux.
• New Relic LLM Observability. Similaire.
• OpenTelemetry + votre APM de choix. OTel a des conventions sémantiques pour le GenAI ; instrumentez une fois, visualisez dans plusieurs outils.

Construire vous-même :

• Une table PostgreSQL contenant une ligne par appel répond déjà à de nombreux besoins.
• Ajoutez une interface utilisateur simple pour chercher et afficher.
• Intégrez avec votre infrastructure de journalisation existante.

Le bon choix dépend de la taille de l’équipe, de l’échelle, du budget et des outils existants. La plupart des équipes commencent avec un outil dédié, puis adoptent une configuration plus complète à mesure qu’elles grandissent.

Une mise en place pratique

Pour une équipe de taille moyenne qui part de zéro :

Semaine 1 : Choisissez un outil (Helicone est un point de départ commun). Intégrez-le à votre chemin principal d’appel LLM. Vérifiez que les appels sont journalisés.

Semaine 2 : Configurez des tableaux de bord de base. Coût, latence, taux d’erreur par fonctionnalité.

Semaine 3 : Configurez des alertes sur les pics de coût et l’augmentation du taux d’erreur.

Semaine 4 : Ajoutez l’instrumentation au niveau de la trace. Connectez les spans dans les flux multi-appels.

Mois 2 : mettez en place un échantillonnage de qualité. Choisissez quelques fonctionnalités et configurez la notation par un LLM utilisé comme juge sur 1 % du trafic.

Mois 3 : Ajoutez la capture des retours utilisateurs. Connectez des boutons de vote (pouce haut/bas) ou similaires.

Mois 4 : ajoutez la prise en charge des environnements mutualisés, des alertes détaillées et des outils de diagnostic.

Vous disposez alors d’une pile d’observabilité fonctionnelle. Chaque couche apporte une capacité utile ; en omettre une crée un angle mort.

Ce qui se passe sans elle

Voici quelques incidents récurrents dans les équipes dépourvues d’une observabilité LLM adéquate :

• Un bug a causé une fonctionnalité à répéter des appels dans une boucle serrée. Des dépenses inattendues de cinq chiffres se sont accumulées pendant le week-end. Détecté uniquement lorsqu’on a reçu la facture mensuelle. (Des variantes de cette histoire se répètent assez souvent pour que les chiffres spécifiques importent moins que le modèle.)

• Une mise à jour de modèle a changé silencieusement le comportement. La qualité a baissé sur une fonctionnalité clé. Les utilisateurs se sont plaints mais l’ingénierie a pensé que c’était “une bizarrerie occasionnelle.” Deux mois avant de la corrélater avec la mise à jour du modèle.

• Une nouvelle version de prompt a été déployée. Elle a accidentellement régressé un flux utilisateur important. Sans des métriques par flux, personne n’a remarqué pendant des semaines.

• Un système agentique a commencé à boucler. Certaines sessions utilisateur comportaient plus de 200 appels LLM. Il a fallu des heures d’enquête pour trouver la boucle, faute d’instrumentation au niveau de la trace.

• Une erreur d’authentification d’outil a entraîné une confusion chez l’agent. L’agent a continué à “essayer des choses” et à accumuler des coûts. Sans alertes, cela a duré des heures.

• Une injection de prompt a amené l’IA à divulguer ses instructions système et des données personnelles. Sans observabilité, l’équipe n’a pas pu identifier facilement les utilisateurs concernés.

Ces incidents ne sont pas théoriques. L’observabilité en prévient la plupart ou permet de les détecter rapidement.

Instrumentez avant l’incident

L’observabilité LLM est une discipline à part entière. L’APM traditionnel est nécessaire mais insuffisant. Les couches spécifiques — au niveau de l’appel, de la trace, de la qualité, du coût, de la latence, de l’erreur, du débogage — sont toutes nécessaires.

Des outils existent. Choisissez-en un, intégrez-le tôt et investissez dans les tableaux de bord, les alertes et les processus qui détectent les problèmes avant les utilisateurs.

Les équipes qui le font :

• Détectent les bugs en heures plutôt qu’en semaines.
• Gèrent les coûts de manière prévisible plutôt que de recevoir des factures surprises.
• Maintiennent la qualité au fil du temps plutôt que de la laisser dériver.
• Diagnostiquent les problèmes de manière systématique plutôt que par hasard.

Les équipes qui ne le font pas finissent par avoir un incident qui les force à le faire. Mieux vaut instrumenter avant l’incident qu’après.