LLM observability pour Claude : comparatif UE 2026

TL;DR

La LLM observability de Claude en Europe repose sur trois couches : les métriques du cloud pour la latence, les tokens et les erreurs, un journal des requêtes que vous maîtrisez, et des traces avec évaluations pour la qualité. Sur Bedrock, la journalisation est désactivée par défaut et CloudWatch garde tout sans limite. Vertex journalise Claude dans BigQuery en Preview.

Que faut-il observer quand Claude tourne en production ?

La LLM observability répond à cinq questions par requête : combien de temps, combien de tokens, quel coût, quelle erreur, et la réponse était-elle bonne ? Les quatre premières viennent presque gratuitement du cloud. La qualité demande des traces, des scores et une relecture humaine. Un prompt contenant des données personnelles fait de chaque journal un traitement au sens du RGPD.

Nous séparons les signaux ainsi :

Signal	Source	Données personnelles ?
Latence, délai avant le premier token	Métriques cloud (InvocationLatency, TimeToFirstToken sur Bedrock)	Non
Tokens d’entrée, de sortie et de cache	Métriques cloud et journaux d’invocation	Non
Coût par équipe ou application	Tokens multipliés par le prix, regroupés par appelant	Non
Erreurs et limitations de débit	Métriques cloud, codes d’erreur côté client	Rarement
Texte des prompts et des réponses	Journaux d’invocation, traces	Souvent
Scores de qualité, évaluations	Langfuse ou un outil de traces équivalent	Selon ce que vous notez

Cette séparation est le cœur du sujet RGPD. Les métriques sont des agrégats sans contenu : elles peuvent être conservées longtemps et lues largement. Les journaux de prompts sont du contenu. Traitez-les comme une base clients : rétention courte, lecteurs restreints, finalité inscrite au registre des traitements. Si vous ne savez pas nommer la finalité, n’activez pas la journalisation du texte.

Claude Code est une source à part, avec sa propre télémétrie. La documentation de suivi de Claude Code exige CLAUDE_CODE_ENABLE_TELEMETRY=1 et exporte des métriques comme claude_code.token.usage et claude_code.cost.usage toutes les 60 secondes, les journaux toutes les 5 secondes. Le texte des prompts n’est journalisé qu’avec OTEL_LOG_USER_PROMPTS=1. Nous gardons ce réglage par défaut. La configuration côté Bedrock est dans notre guide Claude Code sur Bedrock en Europe.

Journalisation Bedrock et CloudWatch face aux alternatives : que choisir ?

Bedrock fournit les métriques d’office et un journal complet des requêtes sur demande. Vertex fournit un tableau de bord et un journal BigQuery en Preview. OpenTelemetry fournit des traces portables, envoyées où vous voulez. Langfuse ajoute les évaluations. Pour une entreprise française, trois colonnes décident : où atterrit le texte, combien de temps il reste, qui peut le démasquer.

Option	Où sont les données	Localisation UE	Rétention par défaut	Masquage	Modèle de coût	Évaluations
Journalisation Bedrock + CloudWatch Logs	Votre groupe de journaux ou bucket S3, même compte et même région que l’appel	Toute région UE d’où vous appelez Bedrock, Paris compris	Illimitée tant que vous ne fixez pas 1 à 3653 jours	Protection des données CloudWatch à l’ingestion	0,50 USD/Go ingéré, 0,12 USD/Go masqué (catalogue US East)	Aucune
Journalisation requête-réponse Vertex	Votre table BigQuery	Multirégion EU ou une région UE	La table n’expire jamais sans réglage	Aucun dans la fonction de journalisation	Stockage BigQuery ; échantillonnage de 0 à 1	Aucune
Cloud Logging (audit et journaux applicatifs)	Bucket de journaux du projet	Emplacement du bucket au choix	30 jours, réglable de 1 à 3650	À expurger dans l’application	0,50 USD/Gio, 50 Gio gratuits par projet	Aucune
OpenTelemetry + votre backend	Là où exporte votre collecteur	À vous de décider	À vous de décider	Attributs de contenu en Opt-In	Votre infrastructure	Selon le backend
Langfuse (cloud EU ou auto-hébergé)	Cloud EU de Langfuse en Irlande, ou votre cluster	AWS eu-west-1 ou votre VPC	30 jours Hobby, 90 Core, 3 ans Pro	Fonction de masquage côté client dans le SDK	Gratuit, 29 USD, 199 USD ; 8 USD par 100k unités	LLM-as-a-judge, datasets, files d’annotation

Les prix sont des prix catalogue issus de la page tarifaire de CloudWatch, qui affiche US East (N. Virginia) et prévient que les régions diffèrent, de la page tarifaire de Google Cloud Observability et de la page tarifaire de Langfuse. Vérifiez le prix de votre région UE avant de budgéter.

Notre position : commencez par la couche native du cloud qui vous sert déjà Claude. Elle est couverte par votre DPA existant avec AWS ou Google, n’ajoute aucun sous-traitant et connaît déjà les volumes de tokens. Ajoutez OpenTelemetry pour tracer l’application. N’ajoutez Langfuse que si quelqu’un mènera vraiment des évaluations. Une équipe qui démarre avec un outil de traces sans métriques cloud passe à côté des limitations de débit, que seul le cloud voit.

Comment activer la journalisation des invocations Bedrock avec l’AWS CLI ?

La journalisation des invocations de modèle est désactivée par défaut et se règle région par région. Une fois active, elle capture la requête complète, la réponse et les métadonnées pour Converse, ConverseStream, InvokeModel et InvokeModelWithResponseStream sur le point de terminaison bedrock-runtime. Les destinations doivent être dans le même compte et la même région. Fixez d’abord la rétention.

Le guide de journalisation des invocations liste les prérequis : un groupe de journaux, un rôle IAM que bedrock.amazonaws.com peut assumer avec logs:CreateLogStream et logs:PutLogEvents, et en option un bucket S3 pour les corps de plus de 100 Ko.

1. Créez le groupe de journaux dans la région d’où vous appelez Bedrock, par exemple Paris (eu-west-3) ou Francfort.
2. Fixez la rétention. La référence de put-retention-policy accepte des valeurs fixes de 1 à 3653 jours. Pour du texte de prompt, nous prenons 30.
3. Créez le rôle IAM avec la politique d’approbation du guide AWS, limitée à votre compte et à votre région.
4. Activez la journalisation, texte activé, modalités inutiles désactivées.
5. Relisez la configuration et envoyez une requête de test.

aws logs create-log-group --log-group-name /bedrock/invocations --region eu-west-3
aws logs put-retention-policy --log-group-name /bedrock/invocations --retention-in-days 30 --region eu-west-3
aws bedrock put-model-invocation-logging-configuration --region eu-west-3 --logging-config '{"cloudWatchConfig":{"logGroupName":"/bedrock/invocations","roleArn":"arn:aws:iam::123456789012:role/BedrockInvocationLogging","largeDataDeliveryS3Config":{"bucketName":"example-bedrock-logs-eu","keyPrefix":"large"}},"textDataDeliveryEnabled":true,"imageDataDeliveryEnabled":false,"embeddingDataDeliveryEnabled":false,"videoDataDeliveryEnabled":false}'
aws bedrock get-model-invocation-logging-configuration --region eu-west-3

Chaque entrée porte identity.arn, modelId, inputTokenCount, outputTokenCount et, en option, un objet requestMetadata que vous passez à chaque appel. Vous obtenez ainsi le coût par équipe sans outil supplémentaire : regroupez par identity.arn dans Logs Insights. La journalisation émet aussi ses propres métriques de livraison, dont ModelInvocationLogsCloudWatchDeliveryFailure. Mettez une alarme dessus, sinon un rôle IAM cassé se découvre pendant l’audit.

Deux pièges. D’abord, les appels via bedrock-mantle ne sont pas capturés. Si vous utilisez Sonnet 5 en mono-région via mantle, vous avez les métriques et CloudTrail, pas de journal d’invocation. Ensuite, la configuration vaut par région. Avec le profil géographique EU, vous appelez depuis une région source : configurez chaque région source utilisée par vos applications. Les identifiants de modèle concernés sont détaillés dans notre guide Claude sur AWS Bedrock en Europe.

Pour les données personnelles, attachez une politique de protection des données CloudWatch Logs avant d’activer le texte. Elle masque les correspondances à l’ingestion. Les événements écrits avant la politique restent en clair. Seuls les principaux disposant de logs:Unmask voient les valeurs brutes, ce qui vous donne un contrôle d’accès documentable face à la CNIL.

Que propose Google Cloud pour Claude sur Vertex AI ?

Google fournit un tableau de bord d’observabilité prêt à l’emploi pour les modèles gérés, modèles partenaires compris, et une journalisation requête-réponse vers BigQuery. Cette journalisation est en Preview, prend en charge Claude via rawPredict et streamRawPredict, et ne se configure pour les modèles Anthropic que par l’API REST. Le taux d’échantillonnage se choisit entre 0 et 1.

La page de journalisation requête-réponse utilise setPublisherModelConfig avec publisher à anthropic. Le corps fixe enabled, samplingRate, une outputUri BigQuery et en option enableOtelLogging, qui ajoute une colonne otel_log au format OpenTelemetry. Les paires dépassant la limite de 10 Mo par ligne de BigQuery ne sont pas enregistrées. Une longue transcription d’agent peut donc disparaître du journal sans bruit.

L’emplacement est votre affaire. Créez le dataset dans la multirégion EU ou dans une région UE avant d’y pointer la configuration. BigQuery indique que les données de la multirégion EU sont stockées dans europe-west1 (Belgique) ou europe-west4 (Pays-Bas). Une table n’expire jamais sans expiration définie : fixez-en une sur le dataset. Les points de terminaison UE pour Claude lui-même sont dans notre guide Claude sur Vertex AI en Europe.

Un réglage mérite une règle. Pour Claude Mythos Preview, Claude Mythos 5 et Claude Fable 5 sur Google Cloud, Vertex peut partager en temps réel les requêtes et réponses journalisées avec Anthropic dès que dataSharingEnabledProvider vaut ANTHROPIC, dans le cadre de l’Advanced AI Safety Addendum. C’est une communication à un second destinataire. Pour l’empêcher, Google documente une contrainte personnalisée de règle d’administration qui interdit ce champ ; les périmètres VPC Service Controls bloquent ce partage par défaut.

Cloud Logging sert aux journaux d’audit et à vos journaux applicatifs, pas aux charges utiles du modèle. Les buckets gardent 30 jours par défaut et acceptent de 1 à 3650. L’ingestion coûte 0,50 USD par Gio avec 30 jours inclus, et 50 Gio par projet et par mois sont gratuits.

Où se placent OpenTelemetry et Langfuse ?

OpenTelemetry est la voie neutre pour tracer votre propre application : un span par appel Claude, relié à la requête HTTP et aux appels d’outils autour. Les conventions sémantiques GenAI nomment le modèle, le fournisseur et la consommation de tokens. Langfuse exploite ces traces et ajoute ce qui manque aux clouds : datasets, notation LLM-as-a-judge et annotation humaine.

Les conventions sémantiques GenAI ont déménagé dans leur propre dépôt et restent au statut Development. Attendez-vous à des renommages. Pour Claude, gen_ai.provider.name vaut anthropic, ou aws.bedrock via Bedrock. Les tokens vont dans gen_ai.usage.input_tokens et gen_ai.usage.output_tokens, avec des attributs distincts pour la lecture et l’écriture du cache. Le point RGPD : gen_ai.input.messages et gen_ai.output.messages sont Opt-In. Une instrumentation conforme n’enregistre pas le texte du prompt sauf demande explicite.

Nous restons brefs sur Langfuse et nous tenons aux faits européens. Le cloud EU tourne sur cloud.langfuse.com en Irlande, sur AWS eu-west-1. L’auto-hébergement est gratuit. Le point OTLP est /api/public/otel en HTTP/JSON ou HTTP/protobuf. gRPC n’est pas pris en charge : un exportateur réglé sur OTEL_EXPORTER_OTLP_PROTOCOL=grpc n’y arrivera pas. Le masquage s’exécute côté client dans le SDK, avant l’export.

La stack de référence que nous monterions pour une entreprise européenne sur Bedrock :

1. Alarmes CloudWatch sur InvocationThrottles, InvocationServerErrors et TimeToFirstToken par ModelId.
2. Journalisation des invocations dans chaque région source UE, rétention de 30 jours, politique de protection des données, gros corps vers un bucket S3 UE avec règle de cycle de vie.
3. OpenTelemetry dans l’application, attributs de contenu désactivés, export vers un collecteur dans votre VPC UE.
4. Langfuse auto-hébergé, ou cloud EU sous DPA, alimenté par un échantillon de traces pour les évaluations.
5. Télémétrie Claude Code vers le même collecteur, métriques seulement.

Sur Google Cloud, remplacez l’étape 1 par le tableau de bord d’observabilité et l’étape 2 par la journalisation BigQuery échantillonnée. Si une passerelle auto-hébergée se trouve devant Claude, elle produit aussi des journaux de coûts ; notre article sur la passerelle LiteLLM en Europe montre où ils sont stockés.

Exploiter en interne ou externaliser ?

Exploiter la LLM observability en interne, c’est surtout du travail récurrent, peu de mise en place. Il faut ajuster les seuils d’alerte quand le trafic change, tenir rétention et suppression en phase avec le registre des traitements, entretenir les tableaux de bord et faire vivre la boucle d’évaluation. La mise en place prend quelques jours à un ingénieur plateforme expérimenté. C’est la durée qu’on sous-estime.

Charge interne par rôle (notre estimation, pas une référence sourcée) :

Tâche	Qui	Rythme
Réglage des alertes (débit limité, latence, taux d’erreur)	Plateforme ou SRE	Hebdomadaire au début, puis mensuel
Rétention, suppression, revues d’accès des journaux de prompts	Plateforme avec le DPO	Trimestriel
Tableaux de bord par équipe, imputation des coûts	Plateforme ou FinOps	Mensuel
Datasets d’évaluation, prompts de juge, annotation	Product owner et experts métier	En continu
Mises à jour du collecteur et de Langfuse en auto-hébergement	Plateforme	À chaque version

Externaliser a du sens si vous avez plusieurs applications Claude sans équipe SRE, si une astreinte sur un pipeline de journaux est exclue, ou s’il vous faut vite des preuves de rétention prêtes pour l’audit. Pour les évaluations, beaucoup moins : un prestataire ne peut pas juger si une réponse est juste dans votre métier. Gardez cela en interne.

Ce qu’il faut exiger d’un prestataire de services managés sur ce sujet :

• Un SLA sur la livraison des journaux et le délai de réaction aux alertes, pas seulement sur la disponibilité des tableaux de bord.
• Un DPA qui nomme chaque lieu de stockage du texte des prompts, avec la liste des sous-traitants, y compris tout SaaS d’observabilité ajouté par le prestataire.
• Un modèle d’accès au moindre privilège, démasquage réservé à un rôle nommé, chaque accès journalisé.
• Une rétention alignée sur votre registre des traitements, avec une suppression vérifiable.
• Une réversibilité claire : journaux et tableaux de bord restent dans votre propre compte AWS ou Google Cloud, exportables, sans agent propriétaire impossible à retirer.

FAQ

Combien coûte la LLM observability de Claude sur AWS ?

Les métriques de l’espace AWS/Bedrock sont fournies avec le service. Les journaux d’invocation coûtent l’ingestion CloudWatch Logs, affichée à 0,50 USD par Go en US East, plus 0,03 USD par Go archivé et 0,12 USD par Go si une politique de protection des données les analyse. 5 Go sont gratuits. Les régions UE ont leurs propres prix.

CloudWatch ou Langfuse : lequel vous faut-il ?

Les deux, pour des rôles différents. CloudWatch voit ce que seul AWS voit : limitations de débit, erreurs serveur, délai avant le premier token et un journal lié à l’identité IAM. Langfuse ajoute évaluations, datasets et relecture humaine. Si personne ne note les réponses, CloudWatch suffit.

Bedrock journalise-t-il les prompts par défaut ?

Non. La journalisation des invocations est désactivée par défaut. Une fois activée avec le texte, les corps de requête et de réponse jusqu’à 100 Ko vont dans votre groupe de journaux CloudWatch, les plus gros dans S3. La rétention est illimitée tant que vous ne la fixez pas.

La journalisation capture-t-elle les appels bedrock-mantle ?

Non. AWS précise que la journalisation des invocations ne couvre que bedrock-runtime. Les appels via bedrock-mantle, y compris l’API Messages d’Anthropic sur ce point de terminaison, n’y figurent pas. Les métriques CloudWatch et CloudTrail restent disponibles pour mantle.

Google peut-il partager mes journaux Claude avec Anthropic ?

Seulement si quelqu’un l’active. Pour Claude Mythos Preview, Mythos 5 et Fable 5 sur Google Cloud, dataSharingEnabledProvider à ANTHROPIC partage en temps réel les requêtes et réponses journalisées. Une contrainte personnalisée de règle d’administration ou un périmètre VPC Service Controls l’empêche.

Les conventions GenAI d’OpenTelemetry enregistrent-elles le texte des prompts ?

Pas par défaut. Dans les conventions sémantiques GenAI, gen_ai.input.messages et gen_ai.output.messages sont des attributs Opt-In. Les conventions sont encore au statut Development : figez la version de votre instrumentation et prévoyez des renommages.

Sources

1. AWS : journalisation des invocations de modèle (CloudWatch Logs et S3) (1 octobre 2026)
2. AWS : métriques CloudWatch de bedrock-runtime (1 octobre 2026)
3. AWS CLI : put-model-invocation-logging-configuration (1 octobre 2026)
4. AWS : protection des données dans CloudWatch Logs (masquage) (1 octobre 2026)
5. AWS : groupes de journaux et rétention (1 octobre 2026)
6. AWS CLI : logs put-retention-policy (1 octobre 2026)
7. Tarifs Amazon CloudWatch (1 octobre 2026)
8. Google Cloud : journaliser et partager requêtes et réponses (1 octobre 2026)
9. Google Cloud : surveiller les modèles (1 octobre 2026)
10. Google Cloud : emplacements BigQuery (1 octobre 2026)
11. Google Cloud : configurer les buckets de journaux (1 octobre 2026)
12. Tarifs Google Cloud Observability (1 octobre 2026)
13. Conventions sémantiques GenAI d'OpenTelemetry (1 octobre 2026)
14. Claude Code : suivi de l'usage (1 octobre 2026)
15. Langfuse : régions de données (1 octobre 2026)
16. Tarifs Langfuse (1 octobre 2026)
17. Langfuse : intégration OpenTelemetry (1 octobre 2026)
18. AWS : fiche du modèle Claude Sonnet 5 (1 octobre 2026)