Observabilité des LLM : mesurer coût, latence et qualité en production

Un assistant conversationnel répond en trois secondes un lundi, puis en douze secondes le mardi suivant, pour un coût qui a doublé sans que personne n'ait touché au code. Ailleurs, un chatbot d'entreprise promet une remise qu'aucune politique commerciale n'autorise, et un tribunal canadien condamne l'entreprise à indemniser le client. La première est un scénario type, la seconde est bien réelle ; toutes deux illustrent le même point aveugle : une application bâtie sur un grand modèle de langage (LLM) est un système vivant, dont le comportement varie d'une requête à l'autre, d'un fournisseur à l'autre, d'une version de modèle à l'autre. Sans instrumentation dédiée, une équipe pilote à l'estime. C'est précisément le rôle de l'observabilité des LLM : rendre visibles, mesurables et pilotables trois grandeurs qui déterminent la santé d'une application en production — le coût, la latence et la qualité.

Cet article propose un tour d'horizon pratique de cette discipline encore jeune mais déjà structurée. Nous verrons pourquoi la supervision classique, pensée pour du code déterministe, ne suffit plus face à des systèmes probabilistes qui produisent un texte différent à chaque appel. Puis nous détaillerons les trois familles de métriques à instrumenter, la manière de tracer une requête de bout en bout avec les standards ouverts qui émergent, les enseignements de plusieurs incidents publics documentés, et un panorama des outils qui ont structuré ce marché depuis 2023-2024. L'objectif : donner à un développeur, un data scientist ou un responsable technique des repères concrets, sans jargon inutile.

L'observabilité n'est pas un luxe réservé aux très grandes plateformes. Dès qu'une application LLM sert de vrais utilisateurs — un support client, un moteur de recherche interne, un assistant de rédaction — les trois mêmes questions reviennent : combien ça coûte, à quelle vitesse ça répond, et la réponse est-elle correcte. Les sections qui suivent répondent à chacune, exemples et sources vérifiables à l'appui.

Pourquoi la supervision classique ne suffit plus

Superviser une application web traditionnelle est un problème relativement bien balisé : on surveille le taux d'erreur HTTP, le temps de réponse d'une base de données, l'usage CPU d'un serveur. Le comportement du code est déterministe — à requête identique, réponse identique. Une application bâtie sur un LLM casse cette hypothèse de base. Le même prompt, envoyé deux fois au même modèle, peut produire deux réponses différentes. La qualité d'une réponse ne se réduit pas à un code de statut HTTP 200 : un appel peut « réussir » techniquement tout en produisant une réponse fausse, hors sujet, ou nuisible pour l'image de l'entreprise qui l'expose.

Les praticiens décrivent généralement trois familles de défis qui se cumulent en production : opérationnels (latence, débit, disponibilité), économiques (coût des tokens, efficacité des prompts) et de qualité (exactitude, sécurité, dérive des sorties dans le temps). Un système de supervision classique — celui qui surveille serveurs et bases de données — répond bien au premier, très partiellement au deuxième, et pratiquement pas au troisième. C'est ce manque qui a fait émerger, entre 2023 et 2025, une catégorie d'outils à part entière : l'observabilité LLM, qui relie entrées, sorties et comportements internes du modèle pour comprendre pourquoi un système réussit ou échoue, et pas seulement s'il a répondu.

Trois grandeurs, trois logiques différentes

Concrètement, ces trois familles se traduisent par des questions très différentes posées à un même système :

• Coût : combien de tokens consomme chaque requête, quel est le prix par appel, quel est le coût moyen par utilisateur ou par session, et ce coût est-il proportionné à la valeur produite ?
• Latence : combien de temps s'écoule avant le premier mot affiché, combien de temps avant la réponse complète, combien de tokens le système génère-t-il par seconde, et cette vitesse est-elle stable dans le temps ?
• Qualité : la réponse est-elle exacte, s'appuie-t-elle sur les bonnes sources, respecte-t-elle le ton et les consignes attendues, et cette qualité se maintient-elle après un changement de version du modèle ou du prompt ?

Ces trois axes ne sont pas indépendants : optimiser aveuglément l'un dégrade souvent les deux autres. Réduire le coût en basculant vers un modèle plus petit peut accélérer la latence tout en abîmant la qualité. Améliorer la qualité en ajoutant plusieurs passes de vérification améliore la fiabilité mais alourdit le coût et la latence. Toute la discipline de l'observabilité LLM consiste à mesurer ces trois grandeurs simultanément, sur les mêmes requêtes, pour arbitrer en connaissance de cause plutôt qu'au jugé.

Mesurer le coût : tokens, prix et budgétisation

Le coût d'une application LLM se compte en tokens — les unités de texte, proches d'un mot ou d'une syllabe, que le modèle consomme en entrée et produit en sortie. La plupart des fournisseurs facturent séparément les tokens d'entrée (le prompt, le contexte, l'historique de conversation) et les tokens de sortie (la réponse générée), avec un tarif par million de tokens qui varie selon le modèle choisi.

Cette tarification a beaucoup évolué depuis l'explosion des usages en 2023. À titre d'illustration, OpenAI a lancé GPT-4o en mai 2024 à 5 dollars par million de tokens en entrée et 15 dollars en sortie. Quelques mois plus tard, en août 2024, l'entreprise a publié une nouvelle version du modèle à 2,50 dollars en entrée et 10 dollars en sortie — une baisse de 50 % sur l'entrée et 33 % sur la sortie par rapport à la version de mai, tout en portant la limite de tokens de sortie de 4 096 à 16 384. Dans le même mouvement, OpenAI a introduit en juillet 2024 un modèle plus compact, GPT-4o mini, facturé 0,15 dollar par million de tokens en entrée et 0,60 dollar en sortie, positionné comme une option nettement moins coûteuse pour les tâches qui ne réclament pas la pleine puissance du modèle principal. Cette dynamique de baisse des prix, observée chez plusieurs fournisseurs concurrents sur la même période, change la donne pour les équipes qui dimensionnent leurs budgets : un choix de modèle figé six mois plus tôt mérite d'être réévalué régulièrement.

Les métriques économiques à instrumenter

Pour transformer cette tarification en pilotage concret, plusieurs métriques doivent être suivies en continu, requête par requête puis agrégées :

• Le nombre de tokens d'entrée et de sortie par appel, seul moyen de comprendre d'où vient la facture ;
• Le coût par requête, calculé en multipliant les tokens par le tarif du modèle utilisé ;
• Le coût par utilisateur ou par session, qui révèle si une minorité d'usages extrêmes tire la facture globale vers le haut ;
• Le coût par fonctionnalité ou par route applicative, pour identifier quelle partie du produit consomme le budget.

Un piège fréquent mérite d'être signalé : le contexte envoyé au modèle grossit souvent silencieusement. Un historique de conversation qui s'accumule, un moteur de recherche documentaire qui injecte toujours plus de passages, un prompt système enrichi à chaque itération — tout cela alourdit les tokens d'entrée sans que la fonctionnalité perçue ait changé. Sans suivi de la taille moyenne des prompts dans le temps, cette dérive passe inaperçue jusqu'à ce que la facture mensuelle surprenne l'équipe.

Les leviers d'optimisation une fois le coût mesuré

Une fois ces métriques en place, plusieurs leviers permettent d'agir : réduire la taille du contexte envoyé en ne conservant que les passages réellement pertinents, mettre en cache les réponses aux questions répétitives, router les requêtes simples vers un modèle plus économique et réserver le modèle le plus capable aux cas complexes, ou encore compresser les instructions système redondantes. Aucun de ces choix n'est pertinent sans données : c'est la mesure qui indique où se trouve le gaspillage, et non l'intuition.

Deux leviers qui changent l'échelle des coûts : caching et batching

Deux de ces leviers méritent un développement particulier, car les fournisseurs les ont industrialisés en 2024 avec des gains chiffrés et vérifiables. Le premier est la mise en cache de prompt (prompt caching). Beaucoup d'applications réenvoient à chaque appel un préfixe identique — un long prompt système, une base de règles, une série d'exemples, un document de référence. Anthropic a ouvert cette possibilité le 14 août 2024 : écrire une portion de contexte dans le cache coûte 25 % de plus que le tarif d'entrée normal, mais la relire ensuite ne coûte plus que 10 % de ce tarif, soit jusqu'à 90 % d'économie sur les portions réutilisées et jusqu'à 85 % de latence en moins sur les longs prompts. OpenAI a suivi le 1^er octobre 2024 avec une mise en cache automatique, sans configuration, sur les prompts dépassant 1 024 tokens : 50 % de réduction sur les tokens d'entrée déjà vus et jusqu'à 80 % de temps gagné avant le premier mot. Ce levier illustre pourquoi la mesure précède l'optimisation : sans suivi de la part de contexte réellement stable d'un appel à l'autre, impossible de savoir si le caching rapportera 5 % ou 80 % d'économie.

Le second levier est le traitement par lots (batch). Pour toutes les tâches qui n'exigent pas de réponse immédiate — classification de documents, génération d'embeddings, campagnes d'évaluation, enrichissement de catalogue — l'API de traitement par lots d'OpenAI, disponible depuis 2024, applique une réduction de 50 % sur les tokens d'entrée comme de sortie, en échange d'un délai de traitement pouvant aller jusqu'à 24 heures. Une part souvent importante de la charge d'une application n'a pas besoin de la seconde près ; l'identifier dans les tableaux de bord de coût, puis la basculer en asynchrone, divise mécaniquement la facture correspondante par deux.

Levier	Mécanisme	Économie annoncée	Contrepartie
Mise en cache de prompt	Réutilise un préfixe déjà calculé	50 à 90 % sur la part en cache	Écriture initiale plus chère ; cache éphémère
Traitement par lots	Requêtes asynchrones groupées	50 % entrée et sortie	Délai jusqu'à 24 h
Routage de modèle	Modèle économique pour les cas simples	Variable selon la répartition	Qualité à surveiller sur les cas limites
Réduction du contexte	Ne garder que les passages pertinents	Proportionnelle aux tokens retirés	Risque de perdre un passage utile

Latence : temps de première réponse, débit et expérience utilisateur

La latence d'une application LLM ne se résume pas à un seul chiffre. Contrairement à un appel d'API classique qui renvoie une réponse d'un bloc, la plupart des applications conversationnelles modernes diffusent leur réponse mot par mot, en flux continu (streaming). Cela introduit une distinction essentielle entre deux mesures : le temps jusqu'au premier token (time to first token, ou TTFT), c'est-à-dire le délai avant que l'utilisateur voie apparaître le premier mot de la réponse, et la latence totale de génération, c'est-à-dire le temps complet nécessaire pour produire l'intégralité de la réponse.

Ces deux mesures racontent des histoires différentes. Un modèle peut afficher un TTFT excellent — le texte commence presque immédiatement — tout en mettant plusieurs secondes à terminer une réponse longue. À l'inverse, un système qui doit d'abord interroger une base documentaire puis réordonner les résultats peut afficher un TTFT élevé même si la génération, une fois lancée, est rapide. Or l'expérience perçue dépend surtout du TTFT : un début de réponse rapide se ressent comme réactif, alors qu'un silence de plusieurs secondes avant le premier mot se ressent comme une application qui a « planté ».

Les métriques opérationnelles à instrumenter

• Le TTFT, mesuré en millisecondes, idéalement décomposé entre le temps réseau, le temps de traitement en amont (récupération de documents, construction du prompt) et le temps propre au modèle ;
• La latence totale de génération, du premier au dernier token ;
• Le débit de génération, exprimé en tokens par seconde, qui indique la vitesse de frappe perçue une fois la génération lancée ;
• Le taux de requêtes en erreur ou en timeout, distinct d'une réponse simplement lente ;
• La disponibilité du service, en particulier lorsque plusieurs fournisseurs de modèles sont utilisés en parallèle ou en secours l'un de l'autre.

Un point de vigilance propre aux LLM : la latence ne dépend pas seulement de la charge du service, mais aussi de la longueur du prompt en entrée et de la réponse demandée. Une même application affiche des temps très hétérogènes selon que l'utilisateur pose une question courte ou colle un document entier à résumer — d'où l'importance de segmenter les tableaux de bord par type de requête, plutôt que de tout fondre dans une moyenne trompeuse.

La latence perçue par un utilisateur n'est pas la latence du modèle : c'est la somme de tout ce qui se passe avant et après lui — récupération de contexte, mise en forme, réseau. Mesurer le modèle seul donne une fausse impression de maîtrise.

TTFT, TPOT et le piège des moyennes

Le débit de génération évoqué plus haut se mesure en réalité à travers une grandeur plus fine : le temps par token de sortie (time per output token, ou TPOT), c'est-à-dire l'intervalle moyen entre deux mots successifs une fois la génération lancée. La latence totale d'une réponse suit alors une décomposition simple : elle vaut approximativement le TTFT, augmenté du TPOT multiplié par le nombre de tokens produits. Cette formule a une conséquence pratique immédiate : sur une réponse longue, c'est le TPOT qui domine ; sur une réponse courte, c'est le TTFT. Optimiser la mauvaise grandeur pour son cas d'usage revient à investir là où l'utilisateur ne le percevra pas.

Le second piège est celui de la moyenne. Une application peut afficher un TTFT moyen flatteur de 400 millisecondes tout en infligeant à un utilisateur sur cent une attente de plusieurs secondes. C'est pourquoi la pratique consiste à suivre non pas une moyenne mais des centiles : le p50 (la médiane, l'expérience typique), le p95 (les 5 % les moins chanceux, souvent la base des engagements de service) et le p99 (le quasi pire cas). Un p99 qui se dégrade pendant que le p50 reste stable est un signal d'alerte précoce — file d'attente qui s'allonge, pression sur la mémoire — bien avant que la moyenne, elle, ne bouge.

Suivre la moyenne d'une latence, c'est décrire une expérience que personne ne vit vraiment. Ce sont les centiles hauts — p95, p99 — qui décrivent les utilisateurs qui s'en vont.

Ces seuils ne sont pas abstraits. Les benchmarks publics MLPerf Inference, référence de l'industrie pour mesurer la vitesse d'inférence, ont introduit en 2025 un scénario « interactif » pensé pour les assistants conversationnels : il exige, au 99^e centile, un TTFT inférieur à 450 millisecondes et un TPOT inférieur à 40 millisecondes — soit au moins 25 tokens par seconde et par utilisateur. Le scénario « serveur », plus permissif, tolère jusqu'à 2 secondes de TTFT et 200 millisecondes par token. L'écart entre ces deux budgets montre qu'un même modèle peut être « assez rapide » ou « trop lent » selon l'exigence d'interactivité visée.

Scénario MLPerf Inference	TTFT (p99)	TPOT (p99)	Débit implicite
Interactif (chat temps réel)	450 ms	40 ms	≈ 25 tokens/s par utilisateur
Serveur (débit maximal)	2 000 ms	200 ms	≈ 5 tokens/s par utilisateur

Qualité : hallucinations, dérive et méthodes d'évaluation

Le troisième pilier, la qualité, est le plus difficile à automatiser — et le plus important. Un LLM peut produire une réponse fluide, bien construite, grammaticalement irréprochable, et pourtant factuellement fausse. Ce phénomène, connu sous le nom d'hallucination, ne se détecte pas avec les outils de supervision classiques : rien dans le code de statut HTTP ni dans le temps de réponse ne signale qu'une information inventée vient d'être servie à un utilisateur.

Pour objectiver ce risque, plusieurs initiatives publiques mesurent la propension des modèles à halluciner dans des conditions contrôlées. La société Vectara a lancé en novembre 2023 un classement ouvert, le Hallucination Leaderboard, construit à partir de son modèle d'évaluation Hughes Hallucination Evaluation Model (HHEM). La méthode est simple à comprendre : on demande à chaque modèle de résumer un même corpus de documents en n'utilisant que les faits qu'ils contiennent, puis on mesure la proportion de résumés qui introduisent des informations absentes du texte source. Ce type de classement, mis à jour régulièrement et publié en open source, donne un point de repère chiffré plutôt qu'une impression subjective sur la fiabilité relative des modèles.

Les écarts mesurés sont loin d'être anecdotiques. Sur le corpus d'origine du classement, les meilleurs modèles introduisaient, à l'été 2025, moins de 1 à 2 % d'informations non étayées dans leurs résumés — GPT-4o se situait autour de 1,5 % — tandis que certains modèles, notamment parmi les premières générations testées fin 2023, dépassaient 10 à 15 %. Autrement dit, à tâche identique, le seul choix du modèle peut faire varier d'un ordre de grandeur la fréquence des affirmations inventées. C'est exactement le genre d'information qu'un tableau de bord d'observabilité doit rendre visible, au lieu de la laisser à l'appréciation de quelques tests manuels.

Un modèle qui n'invente presque jamais et un modèle qui invente une fois sur sept peuvent produire, sur un cas isolé, la même réponse convaincante. Seule une mesure agrégée sur un corpus contrôlé révèle l'écart.

L'évaluation par LLM-juge

Au-delà des hallucinations pures, évaluer la qualité d'une réponse ouverte — une synthèse, une explication, une recommandation — pose un problème de passage à l'échelle. Faire relire chaque réponse par un humain est fiable mais ne tient pas la cadence d'une application en production traitant des milliers de requêtes par jour. Une méthode s'est imposée depuis 2023 pour combler cet écart : utiliser un LLM comme évaluateur d'un autre LLM, une approche baptisée « LLM-as-a-judge ».

Le papier de référence sur le sujet, publié par une équipe de l'université de Californie à Berkeley et de l'université Carnegie Mellon en juin 2023, a introduit deux protocoles d'évaluation : MT-Bench, un jeu de questions à plusieurs tours de dialogue, et Chatbot Arena, une plateforme de comparaison en aveugle entre modèles alimentée par des votes d'utilisateurs. Les auteurs ont montré que les modèles les plus puissants, utilisés comme juges pour noter les réponses d'autres modèles, atteignent un taux d'accord de plus de 80 % avec des évaluateurs humains experts — un niveau comparable à l'accord que l'on observe entre deux évaluateurs humains entre eux. Le papier détaille aussi les limites de la méthode : les modèles-juges peuvent être influencés par la position d'une réponse dans la comparaison, par sa longueur, ou favoriser les réponses qui ressemblent à leur propre style. Des correctifs existent pour atténuer chacun de ces biais, mais ils rappellent qu'un juge automatique reste un outil à calibrer, pas un oracle.

Évaluer un système RAG : les quatre métriques de fidélité

Lorsqu'une application s'appuie sur une base documentaire — le schéma dit RAG, pour génération augmentée par récupération —, la qualité se joue en deux temps distincts : la récupération des bons documents, puis la génération d'une réponse fidèle à ces documents. Un cadre d'évaluation devenu courant, RAGAS, formalise cette décomposition en quatre indicateurs complémentaires, chacun mesurable automatiquement :

• Fidélité (faithfulness) : la réponse s'appuie-t-elle uniquement sur le contexte récupéré, ou ajoute-t-elle des affirmations non étayées ? C'est la mesure la plus directe du risque d'hallucination.
• Pertinence de la réponse (answer relevancy) : la réponse traite-t-elle réellement la question posée, sans digression ni remplissage ?
• Précision du contexte (context precision) : les passages récupérés et placés en tête sont-ils bien les plus utiles, ou noyés dans du bruit ?
• Rappel du contexte (context recall) : la base a-t-elle remonté toute l'information nécessaire pour répondre, ou en manque-t-il une partie ?

Ce découpage a une vertu diagnostique : il indique si un échec vient de la recherche (mauvais documents remontés) ou de la génération (bons documents, mais réponse infidèle). Sans lui, une réponse fausse reste un symptôme dont on ignore la cause — et donc le correctif à appliquer.

Ce qu'il faut suivre en continu

• Un taux d'hallucination ou de non-conformité, mesuré sur un échantillon régulier de production, pas seulement au moment du lancement ;
• Un score de pertinence ou de fidélité aux sources, en particulier pour les systèmes qui s'appuient sur une base documentaire (RAG) ;
• Le taux de refus ou d'esquive, qui peut signaler un excès de prudence aussi problématique qu'un excès de confiance ;
• La dérive de ces indicateurs dans le temps, notamment après une mise à jour silencieuse du modèle sous-jacent par le fournisseur, un changement de prompt, ou une évolution du type de questions posées par les utilisateurs.

Ce dernier point mérite d'être souligné : contrairement à un modèle de machine learning entraîné une fois puis figé, un LLM appelé via une API tierce peut changer de comportement sans prévenir, au gré d'une mise à jour du fournisseur. Une application qui fonctionnait bien un mois peut se dégrader le suivant sans qu'aucune ligne de code n'ait bougé côté équipe. Seul un suivi continu de la qualité, comparé à une référence stable, permet de détecter cette dérive avant qu'elle n'atteigne massivement les utilisateurs.

Tracer une requête de bout en bout

Coût, latence et qualité ne prennent tout leur sens que reliés à une même requête, du premier appel de l'utilisateur jusqu'à la réponse affichée. C'est le rôle du traçage (tracing) : capturer, pour chaque interaction, la chaîne complète des étapes traversées — récupération de documents, appel au modèle, éventuel appel à un outil externe, post-traitement — avec, à chaque étape, ses métriques propres.

Un effort de standardisation notable a émergé autour d'OpenTelemetry, le cadre ouvert de référence pour l'instrumentation des applications. Un groupe de travail dédié aux applications d'intelligence artificielle générative a défini des conventions sémantiques communes : des attributs nommés de façon homogène, comme gen_ai.request.model pour identifier le modèle appelé, gen_ai.usage.input_tokens et gen_ai.usage.output_tokens pour les volumes de tokens consommés, ou gen_ai.response.finish_reasons pour comprendre pourquoi une génération s'est arrêtée. L'intérêt de cette standardisation est direct : un outil de traçage qui respecte ces conventions peut afficher, comparer et alerter sur les données issues de fournisseurs de modèles différents, sans adaptateur sur mesure pour chacun.

En pratique, une trace bien construite répond à des questions autrement difficiles à démêler : sur une requête lente, le temps a-t-il été perdu dans la recherche documentaire ou dans la génération ? Sur une réponse médiocre, le prompt contenait-il les bons documents de contexte ? Sur un pic de coût, quelle étape du pipeline a consommé le plus de tokens ? Sans traçage structuré, on fouille des journaux dispersés ; avec, la réponse tient en quelques clics.

Ce que révèlent des incidents réels

Au-delà de la théorie, plusieurs épisodes largement documentés illustrent concrètement pourquoi ces trois axes de supervision comptent. Deux cas, distincts par leur nature, sont devenus des références régulièrement citées dans l'industrie.

Le premier concerne un chatbot d'Air Canada. En 2022, un client en deuil a consulté l'assistant conversationnel du site pour connaître la politique de tarifs réduits en cas de décès dans la famille. Le chatbot lui a indiqué qu'il pouvait demander le tarif réduit rétroactivement, dans les 90 jours suivant l'achat — une information erronée, contraire à la politique réelle de la compagnie. Après le refus de remboursement, l'affaire a été portée devant le tribunal des petites créances de Colombie-Britannique. Air Canada a soutenu que le chatbot devait être considéré comme une entité distincte, responsable de ses propres propos. Le tribunal a tranché en sens contraire le 14 février 2024, condamnant la compagnie à rembourser le client : selon le membre du tribunal Christopher Rivers, il devrait être évident pour Air Canada qu'elle est responsable de l'ensemble des informations présentes sur son site, chatbot compris.

« Il devrait être évident pour Air Canada qu'elle est responsable de toutes les informations figurant sur son site » — tribunal des petites créances de Colombie-Britannique, décision Moffatt c. Air Canada, 14 février 2024.

Le second cas, survenu quelques mois plus tôt, concerne un concessionnaire automobile américain. En décembre 2023, un utilisateur a manipulé le chatbot commercial d'un site de concession Chevrolet en lui demandant, par une série d'instructions habilement formulées, d'accepter n'importe quelle proposition du client et de conclure chaque message par une formule d'engagement contractuel. Le chatbot a fini par « accepter » de vendre un véhicule pour un dollar. La capture d'écran, partagée publiquement, a été vue des millions de fois, et l'épisode a contribué à populariser la notion d'injection de prompt comme catégorie de risque à part entière pour les applications conversationnelles exposées au public.

Un troisième cas, documenté par une enquête de la rédaction The Markup publiée le 29 mars 2024, ajoute une nuance instructive. La ville de New York avait lancé fin 2023 un assistant conversationnel officiel, MyCity, pour aider les entrepreneurs à s'orienter dans la réglementation locale. Cinq mois après son lancement, des journalistes ont constaté qu'il délivrait des réponses erronées, parfois contraires à la loi : il affirmait par exemple qu'un propriétaire pouvait refuser un locataire bénéficiant d'une aide au logement, ou qu'un employeur pouvait prélever une part des pourboires de ses salariés — deux pratiques pourtant illégales dans la ville. Détail révélateur pour notre sujet : le chatbot ne répondait pas toujours la même chose à la même question. Interrogé à plusieurs reprises sur l'obligation d'accepter les aides au logement, il donnait tantôt une réponse correcte, tantôt une réponse fausse. Cette instabilité, caractéristique des systèmes probabilistes, illustre pourquoi un test unique au lancement ne suffit jamais : seule une mesure répétée, sur un échantillon régulier de production, révèle la dispersion des réponses derrière une façade parfois rassurante.

Ces trois histoires n'ont techniquement pas grand-chose en commun — deux relèvent d'une réponse incorrecte issue d'un manque de contrôle sur les sources d'information, celle du concessionnaire d'une manipulation délibérée du comportement du système par un utilisateur habile. Mais elles partagent un point commun instructif : dans chaque cas, un dispositif de supervision de la qualité des réponses — un contrôle de cohérence avant diffusion, une alerte sur les réponses inhabituelles, un audit des transcriptions publiées — aurait pu aider à détecter l'anomalie plus tôt. L'observabilité n'élimine pas le risque qu'un modèle se trompe ou soit détourné ; elle donne les moyens de le repérer tôt, avant que l'écart n'atteigne un utilisateur ou la presse.

Panorama des outils d'observabilité LLM

Face à ces besoins, un écosystème d'outils dédiés s'est structuré rapidement à partir de 2023. Deux approches coexistent : des plateformes d'observabilité généraliste qui ont étendu leur couverture aux applications LLM, et des outils nés spécifiquement pour ce cas d'usage.

Dans la première catégorie, Datadog a annoncé la disponibilité générale de son module LLM Observability le 26 juin 2024. La particularité de cette offre est de relier les traces spécifiques aux LLM — prompts, tokens, latence de génération — aux traces de performance applicative (APM) déjà collectées par ailleurs, afin de montrer comment la latence d'un appel au modèle affecte la performance globale de l'application qui l'englobe. Cette approche s'adresse en priorité aux équipes déjà équipées d'une plateforme d'observabilité classique, qui souhaitent étendre leur couverture existante plutôt que d'ajouter un outil isolé.

Dans la seconde catégorie, plusieurs outils nés spécifiquement pour les applications LLM ont gagné une adoption large. Langfuse, une plateforme d'ingénierie LLM en open source fondée en 2022 et passée par le programme d'accélération Y Combinator au premier trimestre 2023, propose traçage, évaluation et gestion de prompts dans un même outil, avec la possibilité de l'héberger soi-même — un critère apprécié des équipes soumises à des contraintes de confidentialité des données. D'autres plateformes du même segment couvrent des besoins voisins : suivi des coûts, journalisation des prompts, tableaux de bord de qualité, souvent avec une intégration directe aux principaux frameworks de développement d'applications LLM.

Cet écosystème s'est notamment enrichi d'outils bâtis directement sur les standards ouverts de traçage. Arize Phoenix, plateforme open source d'observabilité et d'évaluation, s'auto-héberge dans un conteneur unique et repose sur OpenTelemetry, avec des évaluateurs prêts à l'emploi et une analyse des embeddings. LangSmith, développé par l'équipe à l'origine du framework LangChain, offre une intégration native à cet environnement et des outils de débogage qui comprennent la structure interne des chaînes d'appels. Helicone se positionne comme une passerelle légère, compatible avec l'API d'OpenAI : il suffit de rediriger l'URL de base des appels pour qu'il journalise immédiatement chaque requête, sa consommation de tokens, son coût et ses erreurs. En version hébergée, vos prompts, vos réponses et l'en-tête portant votre clé transitent alors par les serveurs d'Helicone : à vérifier au regard de vos contrats et du RGPD, ou à auto-héberger. Enfin, des bibliothèques comme OpenLLMetry apportent, en une ligne d'initialisation, une instrumentation neutre vis-à-vis du fournisseur, en produisant des traces au format OpenTelemetry standard.

Un outil réellement « OpenTelemetry-natif » produit des traces standard : la même instrumentation peut alimenter une plateforme aujourd'hui, une autre demain, sans réécrire une ligne de code applicatif. C'est la meilleure assurance contre l'enfermement propriétaire.

Comment choisir

Le choix entre ces familles dépend surtout du point de départ de l'équipe. Une organisation déjà équipée d'une plateforme de supervision généraliste gagne à vérifier si son fournisseur propose une extension LLM native, pour éviter de multiplier les tableaux de bord. Une équipe qui démarre sans historique de supervision, ou soumise à de fortes exigences de confidentialité sur les données envoyées au modèle, se tourne plus naturellement vers un outil open source auto-hébergeable, quitte à migrer plus tard. Dans tous les cas, le critère décisif reste la compatibilité avec les conventions de traçage ouvertes, seule garantie contre un choix technologique irréversible.

Mettre en place l'observabilité : une démarche progressive

Instrumenter une application LLM ne suppose pas de tout construire d'un coup. Une progression par étapes procure des bénéfices rapides sans attendre un chantier d'infrastructure complet. La première étape consiste à journaliser systématiquement chaque appel — prompt, réponse, tokens de chaque côté, modèle exact, temps de réponse. Réalisable en quelques lignes autour de l'appel API existant, elle offre déjà une visibilité immédiate sur les axes coût, latence et volume. La deuxième ajoute le traçage de bout en bout, indispensable dès qu'une requête enchaîne plusieurs étapes — récupération de documents, appels d'outils, orchestration d'agents ; c'est là que les conventions ouvertes évitent de réinventer un format propriétaire.

La troisième étape introduit l'évaluation systématique de la qualité, sur un échantillon restreint de requêtes représentatives, en combinant relecture humaine ponctuelle et LLM-juge pour couvrir un plus grand volume : l'enjeu n'est pas la perfection de la mesure, mais sa régularité. La quatrième, souvent négligée, fixe des seuils d'alerte sur chaque métrique — un coût par requête qui dépasse un plafond, un TTFT qui franchit un seuil, un taux d'hallucination qui grimpe sur l'échantillon surveillé — plutôt que de s'en remettre à un tableau de bord consulté par intermittence. C'est elle qui transforme l'observabilité d'un exercice de reporting en un filet de sécurité opérationnel.

Avant de journaliser : les prompts et réponses contiennent souvent des données personnelles ; limitez ce que vous gardez, fixez une durée de conservation, et masquez les champs sensibles (principe de minimisation, RGPD art. 5).

• Journaliser chaque appel : prompt, réponse, tokens, modèle, durée ;
• Tracer les pipelines multi-étapes avec un format ouvert et interopérable ;
• Évaluer la qualité en continu, sur échantillon, avec relecture humaine et LLM-juge combinés ;
• Alerter automatiquement sur les seuils de coût, de latence et de qualité, plutôt que de se fier à une lecture manuelle des tableaux de bord.

Ce qu'il faut retenir

L'observabilité des LLM répond à une réalité simple : une application bâtie sur un modèle de langage n'est pas un logiciel classique, et sa supervision ne peut pas se limiter aux outils conçus pour du code déterministe. Le coût se mesure en tokens et se pilote par le suivi de la taille des prompts et du choix de modèle. La latence se décompose entre le temps avant le premier mot affiché et la vitesse de génération complète, deux grandeurs qui racontent des histoires différentes de l'expérience utilisateur. La qualité, enfin, est la plus difficile à automatiser, mais des méthodes désormais bien documentées — classements de référence sur les hallucinations, évaluation par LLM-juge, suivi de la dérive dans le temps — permettent de la mesurer sans dépendre uniquement d'une relecture humaine impossible à faire tenir à l'échelle.

Les incidents publics survenus depuis 2023 autour de chatbots d'entreprise rappellent que ces trois grandeurs ne sont pas de simples indicateurs de confort technique : elles conditionnent directement la confiance que les utilisateurs, et parfois les tribunaux, accordent aux réponses produites par une IA exposée au public. Pour une équipe qui démarre, la bonne approche n'est pas de viser d'emblée une instrumentation exhaustive, mais de journaliser d'abord chaque appel, puis d'ajouter progressivement le traçage, l'évaluation continue et les alertes. C'est cette discipline graduelle, plus que le choix d'un outil particulier, qui transforme une application LLM d'un système opaque en un système que l'on comprend, que l'on peut améliorer, et en lequel on peut avoir confiance.

Sources

Cet article s'appuie sur des sources publiques et vérifiables :

• Braintrust, « What is LLM monitoring? (Quality, cost, latency, and drift in production) » — braintrust.dev (métriques opérationnelles, économiques et de qualité).
• Datadog / PR Newswire, « Datadog LLM Observability Is Now Generally Available » (26 juin 2024) — prnewswire.com.
• Traceloop, « GenAI Semantic Conventions » (conventions OpenTelemetry pour les applications d'IA générative) — traceloop.com.
• Forbes, « What Air Canada Lost In 'Remarkable' Lying AI Chatbot Case » (19 février 2024) — forbes.com.
• Boing Boing, « It's easy to trick Chevrolet's AI chatbot into selling you a car for a dollar » (19 décembre 2023) — boingboing.net.
• Y Combinator, page entreprise Langfuse (LLM engineering platform open source, YC W23) — ycombinator.com.
• Zheng, Chiang, Sheng et al., « Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena » (juin 2023) — arXiv 2306.05685.
• Vectara, dépôt du Hallucination Leaderboard (lancé le 6 novembre 2023, modèle HHEM) — github.com/vectara.
• OpenAI, « GPT-4o mini: advancing cost-efficient intelligence » (juillet 2024) — openai.com.
• The Decoder, « OpenAI cuts GPT-4o prices and quadruples output tokens » (août 2024) — the-decoder.com.
• Anthropic, « Prompt caching with Claude » (14 août 2024) — anthropic.com (cache : lecture à 10 % du prix d'entrée, écriture +25 %).
• OpenAI, « Prompt Caching in the API » (1er octobre 2024) — openai.com (50 % sur les tokens d'entrée en cache).
• OpenAI, documentation « Batch API » (traitement asynchrone, 50 % de réduction, 24 h) — developers.openai.com.
• MLCommons, « MLPerf Inference v5.0 Advances Language Model Capabilities for GenAI » (avril 2025, scénario interactif Llama 2 70B) — mlcommons.org.
• The Markup, « NYC's AI Chatbot Tells Businesses to Break the Law » (29 mars 2024) — themarkup.org.
• Vectara, « HHEM-2.1: A Better Hallucination Detection Model » (modèle et classement d'hallucination) — vectara.com.
• Es, James, Espinosa-Anke, Schockaert, « RAGAS: Automated Evaluation of Retrieval Augmented Generation » (septembre 2023, EACL 2024) — arXiv 2309.15217 (faithfulness, answer relevancy, context precision/recall).
• Arize, dépôt open source Phoenix (observabilité et évaluation LLM, OpenTelemetry) — github.com/Arize-ai.