Bonnes pratiques de logging LLM : 9 règles que nous suivons en production [2026]

Bonnes pratiques de logging LLM : 9 règles que nous suivons en production [2026]

Ces neuf bonnes pratiques de logging LLM sont les règles que notre stack de production suit réellement : nous loguons 1,2 million de requêtes LLM par mois réparties sur quatre services, et chacune atterrit dans Grafana Loki sous la forme d'une unique ligne JSON avec model, tokens, latency, cost_usd et trace_id. structlog 25.4.0 écrit l'enregistrement, Presidio retire les PII en amont, et tout le pipeline forme le volet logging de notre stack d'observabilité.

Points clés

• Loguez chaque requête LLM en JSON structuré avec au moins 14 champs nommés, jamais en texte libre.
• Masquez les PII avant l'écriture du log avec Presidio ou équivalent, pas après.
• Attachez les attributs des conventions sémantiques OpenTelemetry GenAI à chaque trace.
• À 1 million de requêtes/jour, les mêmes 60 Go coûtent 108 $/mois chez Datadog, 30 $ dans Loki et 1,20 $ dans ClickHouse.

Ce que signifie réellement le logging LLM (et pourquoi « tout logger » ne marche pas)

Le logging LLM consiste à capturer un enregistrement structuré de chaque requête et de chaque réponse du modèle : le prompt, la complétion, le nombre de tokens, la latence, le coût, et la trace qui relie le tout à une session utilisateur. Ce n'est pas du logging d'infrastructure. CPU, mémoire et redémarrages de pods relèvent de votre stack de métriques ; cet article ne couvre que l'enregistrement au niveau requête, celui qui permet de déboguer, de chiffrer et d'auditer le comportement du modèle.

Le réflexe « il suffit de tout logger » a la vie dure, et il coûte cher. Des prompts et complétions complets, à raison d'un million de requêtes par jour, produisent environ 60 Go de texte par mois, et une bonne partie de ce texte est constituée de PII clients que vous stockez désormais indéfiniment. Le principe de minimisation des données de l'article 5 du RGPD exige que les données personnelles soient « adéquates, pertinentes et limitées à ce qui est nécessaire », et un déversement brut de prompts échoue à ce test dès le premier jour. Tout logger n'est pas une stratégie ; c'est un passif avec une facture mensuelle.

Quelles sont les 9 règles de logging LLM ?

Neuf règles, dans l'ordre où nous les mettrions en place : logger les prompts et réponses complets avec des identifiants hachés, émettre du JSON structuré, capturer les tokens et le coût par requête, attacher le contexte de trace OpenTelemetry, masquer les PII avant l'écriture, échantillonner à haut volume, définir des niveaux de rétention, séparer les événements de sécurité et rendre le résultat interrogeable. Chacune des règles ci-dessous est accompagnée du code ou du tableau qui la fait respecter.

Règle 1 : logger le prompt et la réponse en entier (avec des hashs, pas des PII brutes)

Loguez le prompt complet et la complétion complète de chaque requête, car les logs partiels sont la meilleure façon de se retrouver devant un incident sans aucune trace de ce que le modèle a réellement vu. La seule exception concerne l'identité : n'écrivez jamais d'ID utilisateur, d'e-mail ou de nom brut dans l'enregistrement. Stockez plutôt un hash SHA-256 de l'ID utilisateur. Un hash permet toujours de reconstituer l'historique complet d'un utilisateur via une recherche hors ligne, tandis que la ligne de log elle-même reste inutilisable pour quiconque ne devrait pas la lire. Même logique pour les prompts système : hachez-les, loguez le hash et conservez le texte en clair dans votre registre de prompts, où il est déjà versionné.

Règle 2 : utiliser du JSON structuré : chaque champ nommé, rien en texte libre

Pour de bonnes pratiques de logging LLM en Python ou dans tout autre langage, le logging structuré en JSON est le point non négociable : chaque champ nommé, typé et interrogeable, rien n'est déversé sous forme de chaîne formatée. Une ligne en texte libre comme INFO called gpt-4o, took 812ms ne peut être qu'inspectée par grep. Un enregistrement JSON peut être agrégé par modèle, sommé par coût et joint à une trace. Les bonnes pratiques de production d'OpenAI vont dans le même sens : capturer des métadonnées structurées au niveau du SDK plutôt qu'avec des print.

Voici le schéma émis par chaque service Techsy, quatorze champs :

{
  "request_id": "req_01J9XK4M7Q",
  "timestamp": "2026-07-18T09:24:31.482Z",
  "environment": "production",
  "model": "claude-sonnet-4-20250514",
  "prompt_tokens": 1284,
  "completion_tokens": 396,
  "latency_ms": 812,
  "cost_usd": 0.0098,
  "system_prompt_hash": "sha256:9f2c1a4e...",
  "user_id_hash": "sha256:b7e4d831...",
  "rag_sources": ["kb/pricing-2026.md", "kb/refund-policy.md"],
  "guardrail_result": "pass",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "span_id": "00f067aa0ba902b7"
}

Trois champs méritent une note. cost_usd est calculé au moment de la requête à partir du nombre de tokens et du tarif publié du modèle, jamais recalculé a posteriori par un job nocturne. Les deux champs de hash sont le compromis de la règle 1 : corrélables hors ligne, opaques dans le log. Et trace_id et span_id sont des valeurs de contexte de trace W3C, ce qui est précisément l'objet de la règle 4.

Si quatre services appelant directement les fournisseurs vous semblent être quatre endroits à instrumenter, un proxy LiteLLM centralise le tout : un seul point d'accroche de logging devant chaque fournisseur.

Règle 3 : capturer le nombre de tokens et le coût par requête

Le suivi de la consommation de tokens appartient à la ligne de log elle-même, pas à un job d'entrepôt de données qui tournera demain. Chaque fournisseur renvoie le nombre de tokens d'entrée et de sortie dans la réponse ; multipliez par le tarif par token du modèle à cet instant précis et écrivez cost_usd dans l'enregistrement. Les tarifs changent, et diffèrent entre tokens d'entrée en cache et tokens frais, si bien que calculer le coût plus tard avec une table de prix statique réécrit l'histoire en silence. Avec un coût sur chaque ligne, « quelle fonctionnalité coûte cher ? » devient une requête d'une ligne au lieu d'un projet financier, et cela alimente directement le travail visant à réduire vos coûts d'API LLM.

Règle 4 : attacher le contexte de trace (Semconv OpenTelemetry GenAI)

Une ligne de log sans ID de trace est orpheline : vous pouvez la lire, mais impossible de dire quelle tentative, quelle étape RAG ou quel tour utilisateur l'a produite. La solution passe par les conventions sémantiques GenAI d'OpenTelemetry, les noms d'attributs standard pour instrumenter les appels de modèle. Émettez le log à l'intérieur d'un span actif et le trace_id et le span_id s'attachent d'eux-mêmes, si bien qu'un clic dans Grafana vous mène de la cascade de trace directement à l'enregistrement brut.

Les attributs à définir sur chaque span gen_ai :

from opentelemetry import trace

tracer = trace.get_tracer("ai-sdr")

with tracer.start_as_current_span("chat.completion") as span:
    span.set_attribute("gen_ai.system", "anthropic")
    span.set_attribute("gen_ai.request.model", "claude-sonnet-4-20250514")
    response = client.messages.create(**payload)
    span.set_attribute("gen_ai.usage.input_tokens", response.usage.input_tokens)
    span.set_attribute("gen_ai.usage.output_tokens", response.usage.output_tokens)
    span.set_attribute("gen_ai.response.finish_reasons", [response.stop_reason])
    log.info("llm.request", cost_usd=cost)  # Rule 2 record, trace IDs auto-attached

Règle 5 : masquer les PII avant l'écriture du log

Le masquage des PII doit intervenir avant l'écriture de l'enregistrement, pas par un nettoyage après coup. Une fois qu'une adresse e-mail est dans Loki, elle se trouve aussi dans vos sauvegardes sur stockage objet, et « nous l'avons supprimée ensuite » n'est pas une réponse recevable au RGPD. Dans notre configuration, Microsoft Presidio tourne comme processeur structlog et intercepte 94 % des e-mails et numéros de téléphone avant qu'ils n'atteignent Loki ; les cas manqués sont presque tous des formats inhabituels, que nous ajoutons à des reconnaisseurs personnalisés au fil de leur découverte.

L'accroche entière tient en quinze lignes :

from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine

analyzer = AnalyzerEngine()
anonymizer = AnonymizerEngine()

PII_ENTITIES = ["PERSON", "EMAIL_ADDRESS", "PHONE_NUMBER", "CREDIT_CARD", "IBAN_CODE"]

def redact_pii(text: str) -> str:
    results = analyzer.analyze(text=text, language="en", entities=PII_ENTITIES)
    return anonymizer.anonymize(text=text, analyzer_results=results).text

# In the structlog processor chain, before JSONRenderer:
# event_dict["prompt"] = redact_pii(event_dict["prompt"])

Le masquage siège dans la même couche du pipeline que vos filtres d'entrée et de sortie, et il doit être testé de la même manière. Notre pipeline de guardrails traite un e-mail ayant fuité dans un log comme un eval en échec, pas comme une note de bas de page d'exploitation.

Règle 6 : échantillonner intelligemment à haut volume

En dessous d'environ 100 000 requêtes par jour, loguez tout. Au-delà, le logging à volume complet est une taxe de stockage sur des données que vous ne lirez jamais, et l'échantillonnage est la façon de conserver les enregistrements qui comptent. Le piège : l'échantillonnage aléatoire est la pire option pour le trafic LLM, car les échecs, les refus et les requêtes à cinq dollars sont rares par définition, si bien qu'un taux uniforme de 10 % écarte précisément les événements que vous déboguez. Échantillonnez par résultat, pas à pile ou face.

Une configuration courante consiste en des règles aux extrémités (production et tenants entreprise : toujours logger) complétées par une sélection par la queue au milieu. L'angle propre aux logs dans ce cadre : vos champs guardrail_result et cost_usd sont les signaux d'échantillonnage, déjà présents si vous avez suivi les règles 2 et 8.

Règle 7 : définir une politique de rétention avant d'en avoir besoin

Une politique de rétention des logs est une décision que l'on prend au calme, car l'alternative est de la prendre pendant une revue de coûts à volume doublé. Le principe de limitation de la conservation de l'article 5 du RGPD dit que les données personnelles doivent être conservées « pas plus longtemps que nécessaire », ce qui signifie en pratique une rétention par niveaux :

Le niveau hot répond vite et cher à « que s'est-il passé il y a dix minutes ? » ; le niveau cold répond lentement et pour pas cher à « qu'avons-nous dit à ce client en mars ? ». Supprimez selon un calendrier, automatiquement, ou les niveaux ne sont qu'un schéma.

Règle 8 : logger séparément les événements de guardrail et de sécurité

Les événements de sécurité (blocages par guardrail, refus, violations de politique) ne sont pas de la télémétrie ; ce sont des enregistrements d'audit, et ils appartiennent à leur propre flux. Trois raisons. L'alerte : un pic d'injections de prompt bloquées doit réveiller quelqu'un, et vous ne pouvez pas régler cette alerte au milieu d'un million de lignes routinières. La rétention : la conformité peut exiger que les enregistrements de sécurité survivent aux logs de débogage de plusieurs années. L'accès : les auditeurs reçoivent le flux de sécurité, pas tout votre torrent. Taguez le verdict dans l'enregistrement principal (guardrail_result: "block") et routez l'enregistrement complet vers le flux séparé. Ce qui compte comme événement de sécurité est traité dans notre guide des événements de guardrail.

Règle 9 : rendre les logs interrogeables, pas seulement stockés

Un log que vous ne pouvez pas interroger en moins d'une minute est une sauvegarde, pas un signal d'observabilité. Interrogeable signifie des champs indexés, un langage de requête que votre astreinte maîtrise vraiment, et des tableaux de bord construits avant l'incident. Nous utilisons Loki et l'interrogeons plus de 30 fois par semaine pour les anomalies de coût, les régressions de latence et les « montre-moi chaque refus du tenant X hier ». La documentation de Grafana Loki est la référence pour la syntaxe ; le modèle qui rentabilise son usage consiste à filtrer directement sur les champs JSON parsés :

{service="ai-sdr"} |= "llm.request" | json
  | model = "claude-sonnet-4-20250514"
  | cost_usd > 0.05
  | line_format "{{.timestamp}} {{.request_id}} ${{.cost_usd}} {{.latency_ms}}ms"

Cinq lignes, aucun export vers un notebook. Si votre stockage actuel ne sait pas faire cela, c'est le problème à corriger en premier.

Ce que nous loguons réellement en production

Assez de théorie. Voici la configuration expurgée de notre pipeline d'AI SDR, le service derrière le chiffre de 1,2 million de requêtes par mois de l'introduction. Il fait tourner structlog 25.4.0 qui produit du JSON, expédié vers Grafana Cloud Loki via Promtail. Le modèle sur ce pipeline est claude-sonnet-4-20250514, et chaque appel traverse exactement la chaîne de processeurs des règles 2 et 5 :

import structlog

structlog.configure(
    processors=[
        structlog.contextvars.merge_contextvars,
        structlog.processors.add_log_level,
        structlog.processors.TimeStamper(fmt="iso"),
        redact_pii,          # Rule 5: Presidio, before serialization
        add_otel_trace_ids,  # Rule 4: trace_id + span_id from the active span
        structlog.processors.JSONRenderer(),
    ],
)
log = structlog.get_logger()

Deux chiffres du premier trimestre avec cette configuration. L'ingestion mensuelle s'est stabilisée à 47 Go sur quatre services, et la latence p95 d'écriture de log est de 3 ms, ce qui signifie que le pipeline n'ajoute rien de mesurable au temps de requête.

Le changement de configuration qui s'est remboursé tout seul : nous avons ajouté cost_usd à chaque entrée de log en mars 2026. En une semaine, nous avons trouvé un template de prompt qui brûlait 340 $/mois dans des boucles de retries. Une erreur API transitoire déclenchait trois retries, chacun renvoyant l'intégralité du contexte de 4 000 tokens. Les logs en ont fait une requête d'une ligne ; sans coût par requête, cela serait apparu comme une ligne inexpliquée dans la prochaine revue budgétaire trimestrielle.

Combien coûte le stockage des logs LLM à grande échelle ?

À un million de requêtes par jour, le stockage des logs LLM coûte entre environ 1,20 $ et 108 $ par mois pour les mêmes données, selon le stockage. Le calcul : un enregistrement structuré complet pèse en moyenne 2 Ko, donc un million de requêtes par jour représente 2 Go par jour, soit 60 Go par mois. Les tarifs publiés par les éditeurs ci-dessous (juillet 2026) correspondent au coût de ces 60 Go dans trois backends courants.

Sources : tarification Datadog, Grafana Loki et la documentation observabilité de ClickHouse.

Deux réserves, car il s'agit de notre calcul à partir des tarifs éditeurs, pas d'un benchmark que nous avons mené. D'abord, le chiffre de Datadog suppose que vous indexiez tout ; la plupart des équipes n'indexent qu'un sous-ensemble et paient bien moins, tandis que Loki et ClickHouse facturent surtout ce que vous stockez. Ensuite, le 1,20 $ de ClickHouse auto-hébergé cache une vraie facture : le calcul pour faire tourner le cluster et les heures d'ingénieur pour l'exploiter. À 60 Go par mois, un service managé est presque toujours la réponse la moins chère au total. L'auto-hébergement commence à avoir du sens au-delà d'environ 1 To par mois, quand l'écart par Go submerge les frais d'exploitation.

L'écart est l'enseignement à retenir. À un million de requêtes par jour, la différence entre Datadog indexé et ClickHouse auto-hébergé est d'environ 90x : 108 $ contre 1,20 $ pour les mêmes 60 Go. Choisissez le stockage au moment de l'architecture, pas après l'arrivée de la facture.

Quel outil de logging choisir ?

Pour la plupart des équipes, le choix se ramène à quatre options : une plateforme native LLM (Langfuse ou LangSmith), un outil de couche proxy (Helicone), ou un simple pipeline OpenTelemetry vers l'infrastructure que vous exploitez déjà. Le tableau couvre les points de décision qui diffèrent réellement ; les tableaux de bord, la relecture et le versionnage de prompts sont le minimum syndical chez les quatre.

Notre avis, franchement : nous utilisons OTel natif plus Loki parce que nous avions déjà la stack Grafana pour tout le reste, et ajouter une source de données de plus l'a emporté sur l'adoption d'un quatrième fournisseur. Si vous partez de zéro sans aucune stack d'observabilité, le modèle de tracing de Langfuse et son offre gratuite sont le chemin le plus rapide vers l'utile, et l'option d'auto-hébergement garde la porte de sortie ouverte. Si vous hésitez entre les deux leaders natifs LLM, notre comparatif Langfuse vs LangSmith déroule la comparaison complète. Et si le logging n'est qu'une pièce d'une décision de monitoring plus large, le comparatif complet des plateformes couvre l'ensemble du champ.

Quelles sont les erreurs de logging LLM les plus courantes ?

Six erreurs expliquent l'essentiel des configurations de logging LLM cassées que nous avons examinées. Chacune coûte peu à éviter si vous la repérez avant que le volume de logs ne le fasse :

• Logger des PII brutes sans masquage. La plus courante et la plus coûteuse. Un export de support ou un bucket compromis suffit à transformer des logs de prompts en incident de protection des données. Masquez avant l'écriture (règle 5), pas à la lecture.
• Aucune politique de rétention. Le stockage indéfini est la valeur par défaut partout, et il double discrètement votre facture chaque année. Si vous ne supprimez jamais, vous n'avez pas un système de logging ; vous avez une archive qui se prend pour un système.
• Logs en texte non structuré. Une sortie de print que l'on ne peut qu'inspecter par grep fonctionne à l'échelle d'une démo et s'effondre à 100 000 requêtes par jour, quand « trouver chaque requête en échec du modèle X » devient un après-midi de script shell au lieu d'une requête.
• Ne logger que les erreurs. Les requêtes réussies sont la référence par rapport à laquelle vous détectez la dérive, et elles sont la matière première de votre pipeline d'évaluation. Loguez aussi les succès, échantillonnés si le volume l'impose.
• Ignorer les champs de coût. Sans cost_usd par requête, pas d'alertes de coût, pas d'attribution par fonctionnalité, et la boucle de retries à 340 $/mois de la section production ci-dessus reste invisible jusqu'à la facture trimestrielle.
• Aucune corrélation de trace. Des logs déconnectés des spans transforment le débogage d'agents multi-étapes en devinettes. Si votre ligne de log n'a pas de trace_id, la règle 4 est la solution.

Questions fréquemment posées

Que faut-il logger pour chaque requête LLM ?

Au minimum : le prompt complet et la complétion complète avec les PII masquées, le nom du modèle, le nombre de tokens d'entrée et de sortie, la latence, le coût en USD, un identifiant utilisateur haché, ainsi que les ID de trace et de span OpenTelemetry. Ajoutez les ID de sources RAG et le verdict du guardrail si votre pipeline comporte ces étapes. Quatorze champs nommés, une ligne JSON par requête.

Quel est le meilleur format pour les logs LLM ?

Du JSON structuré, un objet par requête, avec chaque champ explicitement nommé. Les logs en texte libre ne peuvent être qu'inspectés par grep ; les enregistrements JSON peuvent être agrégés par modèle, sommés par coût et joints aux traces. Émettez l'enregistrement avec un logger structuré comme structlog en Python ou pino en Node, et rendez-le avec un sérialiseur JSON, jamais avec du formatage de chaîne.

Comment gérer les PII dans les logs LLM ?

Masquez avant l'écriture du log, pas après. Faites passer le prompt et la complétion dans un détecteur comme Microsoft Presidio à l'intérieur de votre pipeline de logging, en remplaçant noms, e-mails et numéros de téléphone par des jetons tels que <EMAIL_ADDRESS>. Une fois que des PII brutes atteignent votre stockage de logs, elles se trouvent aussi dans vos sauvegardes, et une suppression rétroactive satisfait rarement au test de minimisation du RGPD.

Combien coûte le stockage des logs LLM à grande échelle ?

Pour un million de requêtes par jour, environ 60 Go par mois à 2 Ko par enregistrement, comptez environ 108 $/mois au tarif indexé de Datadog LLM Observability, 30 $/mois sur Grafana Cloud Loki, ou environ 1,20 $/mois en stockage S3 compressé pour ClickHouse auto-hébergé, plus le calcul. Ce sont les tarifs publiés par les éditeurs en juillet 2026 ; l'auto-hébergement ajoute du temps d'ingénierie par-dessus.

Que sont les conventions sémantiques OpenTelemetry GenAI ?

Ce sont les noms d'attributs standard d'OpenTelemetry pour instrumenter les appels LLM : gen_ai.system pour le fournisseur, gen_ai.request.model pour le modèle, gen_ai.usage.input_tokens et output_tokens pour le nombre de tokens, et gen_ai.response.finish_reasons pour la raison d'arrêt de la génération. Les utiliser signifie que n'importe quel backend compatible OTel, de Jaeger à Tempo en passant par Langfuse, lit vos traces sans parseurs personnalisés.

Comment échantillonner les logs LLM à fort trafic ?

Conservez chaque erreur, chaque blocage de guardrail et chaque requête au-dessus d'un seuil de coût, puis échantillonnez le reste. Cette approche par la queue préserve les événements rares que vous déboguez réellement, tandis qu'un échantillonnage aléatoire uniforme les écarte au même rythme que le trafic banal. En dessous de 100 000 requêtes par jour, sautez entièrement l'échantillonnage et loguez tout.

Combien de temps conserver les logs LLM ?

Par niveaux : 7 jours en hot pour le débogage en direct, 30 jours en warm pour la revue d'incidents et l'analyse de coûts, et jusqu'à 1 an en cold sur stockage objet compressé pour la conformité et les audits. Le principe de limitation de la conservation du RGPD interdit de garder les données personnelles plus longtemps que nécessaire, alors associez à chaque niveau une suppression automatique plutôt qu'un nettoyage manuel.

Quelle différence entre logging LLM et tracing LLM ?

Un log est un enregistrement plat d'un événement : cette requête a eu lieu, avec ces champs. Une trace est un arbre causal de spans couvrant tout le chemin d'une requête, par exemple la récupération, puis l'appel au modèle, puis deux appels d'outils. Les logs disent quoi ; les traces disent où et pourquoi. Les configurations de production émettent les deux, joints par trace_id.

Conclusion

Récapitulatif : loguez chaque requête en JSON à champs nommés, calculez le coût au moment de la requête, attachez le contexte de trace OTel, masquez les PII avant l'écriture, échantillonnez par résultat une fois passé 100 000 requêtes par jour, et choisissez un stockage que vous savez réellement interroger. Les neuf règles sont ordonnées pour que vous puissiez en adopter une par sprint, et les règles 2, 4 et 5 sont les trois qui se remboursent le plus vite. Si vous choisissez la stack de monitoring plus large autour des logs, commencez par notre sélection des meilleures plateformes d'observabilité IA. Et si vous avez besoin d'aide pour mettre en place le logging structuré de votre stack LLM, obtenez une consultation gratuite.