llm-integration.eu

Claude Code telemetry : OpenTelemetry, RGPD et CSE

Claude Code telemetry avec OpenTelemetry : les 8 métriques, la confidentialité par défaut, les managed settings, un collecteur sans identifiants et le rôle du CSE.

Mis à jour 12 min de lectureFaits vérifiés le 1 octobre 2026

TL;DR

La Claude Code telemetry reste éteinte tant que vous n’activez pas CLAUDE_CODE_ENABLE_TELEMETRY=1 et un exportateur OpenTelemetry. Claude Code envoie alors 8 métriques (sessions, tokens, coût, lignes, commits, PR, décisions d’édition, temps actif) à votre collecteur. Les prompts restent masqués par défaut. Sur Bedrock et Vertex, c’est la seule vue d’usage. Agrégez par équipe, pas par personne.

Que contient la Claude Code telemetry ?

La Claude Code telemetry, ce sont des données OpenTelemetry que Claude Code envoie à un collecteur de votre choix : des métriques en séries temporelles, des événements via le protocole logs, et des traces en bêta. Rien ne part sans configuration. Il faut CLAUDE_CODE_ENABLE_TELEMETRY=1, puis un exportateur par signal, par exemple otlp, prometheus ou console.

La documentation monitoring liste huit métriques. Elles sont exportées toutes les 60 000 ms par défaut, les logs toutes les 5 000 ms. Le meter s’appelle com.anthropic.claude_code. Le service.name vaut claude-code dans le terminal et claude-code-desktop dans l’onglet Code de l’application de bureau. Filtrez sur les deux, sinon l’usage desktop disparaît de vos tableaux.

Métrique Ce qu’elle compte Attributs utiles
claude_code.session.count Sessions démarrées start_type (fresh, resume, continue)
claude_code.token.usage Tokens type (input, output, cacheRead, cacheCreation), model
claude_code.cost.usage Coût estimé en USD model, query_source, effort
claude_code.lines_of_code.count Lignes ajoutées ou supprimées type, model
claude_code.commit.count Commits Git créés attributs standard
claude_code.pull_request.count PR ou MR créées attributs standard
claude_code.code_edit_tool.decision Éditions acceptées ou refusées decision, language
claude_code.active_time.total Temps actif en secondes type (user, cli)

Les événements forment la couche de détail : claude_code.user_prompt, claude_code.api_request avec cost_usd, duration_ms et les tokens par appel, claude_code.tool_result, claude_code.tool_decision, claude_code.api_error et une vingtaine d’autres. Un prompt.id relie chaque appel d’API et chaque outil au prompt qui l’a déclenché. Pour un tableau de bord de coûts, les métriques suffisent. Les événements servent l’audit de sécurité et le SIEM, et c’est précisément ce qui les rend sensibles.

Comment imposer la télémétrie à toute l’organisation ?

Avec le fichier de managed settings sur chaque poste. Les managed settings priment sur les réglages utilisateur, et Claude Code ignore les variables d’exportateur OpenTelemetry du .claude/settings.json d’un dépôt. Un dépôt ne peut donc ni activer la télémétrie, ni la rediriger, ni déclencher la capture des prompts. Un développeur peut encore couper un signal.

La documentation des managed settings donne les chemins : /Library/Application Support/ClaudeCode/managed-settings.json sur macOS, /etc/claude-code/managed-settings.json sur Linux et WSL, C:\Program Files\ClaudeCode\managed-settings.json sur Windows. Si une autre équipe gère déjà ce fichier, ajoutez un 10-telemetry.json dans le répertoire managed-settings.d/ voisin. Claude Code fusionne le fichier principal, puis chaque *.json de ce répertoire par ordre alphabétique.

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "none",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "https://otel.example.internal:4317",
    "OTEL_EXPORTER_OTLP_HEADERS": "Authorization=Bearer REPLACE_ME",
    "OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE": "cumulative",
    "OTEL_METRICS_INCLUDE_ACCOUNT_UUID": "false",
    "OTEL_METRICS_INCLUDE_SESSION_ID": "false",
    "OTEL_RESOURCE_ATTRIBUTES": "department=engineering,team.id=plateforme,cost_center=cc-75"
  }
}

Ce fichier repose sur quatre choix :

  1. OTEL_LOGS_EXPORTER vaut none. Les métriques répondent aux questions de coût et d’adoption. Les événements portent l’identité au niveau du prompt et relèvent, si besoin, d’un pipeline séparé à accès restreint.
  2. Un OTEL_EXPORTER_OTLP_ENDPOINT fixé de façon centrale verrouille la destination. Depuis la v2.1.217, Claude Code supprime au démarrage tous les endpoints par signal définis par le développeur.
  3. Nous choisissons cumulative pour un pipeline Prometheus. La valeur par défaut est delta, et la documentation conseille de basculer si votre backend attend des valeurs cumulées.
  4. OTEL_RESOURCE_ATTRIBUTES ajoute l’équipe et le centre de coûts à chaque point de donnée. Pas d’espaces dans les valeurs : org.name=Equipe_Plateforme, pas Equipe Plateforme. Les guillemets n’échappent rien, ils entrent dans la valeur.

Pour vérifier, ouvrez une session et cherchez claude_code.session.count dans le backend. Si rien n’arrive, lancez claude --debug-file /tmp/cc.log et cherchez [3P telemetry] dans le journal. Les lignes [Anthropic telemetry] concernent la télémétrie opérationnelle d’Anthropic, pas votre configuration.

Quel collecteur garde les données au niveau de l’équipe ?

Un OpenTelemetry Collector qui reçoit l’OTLP, supprime les attributs d’identité, puis seulement exporte vers Prometheus ou votre plateforme d’observabilité. Claude Code joint toujours user.id, joint user.email dès qu’un compte Claude est connecté, et ajoute les UUID de compte sauf désactivation. Retirez-les avant qu’ils n’atteignent un stockage interrogeable par un manager.

L’attributes processor agit sur les traces, métriques et logs, en stabilité bêta, avec les actions delete et hash. Le hachage utilise SHA1 et produit une clé stable par personne : c’est une pseudonymisation au sens de l’article 4, point 5, du RGPD, pas une anonymisation. Un e-mail haché reste une donnée personnelle. Pour un tableau d’équipe, nous supprimons. Le memory limiter et le batch suivent la référence de configuration du collecteur.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  memory_limiter:
    check_interval: 5s
    limit_mib: 512
  attributes/strip_identity:
    actions:
      - { key: user.email, action: delete }
      - { key: user.id, action: delete }
      - { key: user.account_uuid, action: delete }
      - { key: user.account_id, action: delete }
      - { key: session.id, action: delete }
      - { key: enduser.id, action: delete }
  resource/strip_identity:
    attributes:
      - { key: user.email, action: delete }
      - { key: enduser.id, action: delete }
  batch: {}

exporters:
  prometheus:
    endpoint: 0.0.0.0:8889

service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, attributes/strip_identity, resource/strip_identity, batch]
      exporters: [prometheus]

Il reste team.id, department, cost_center, model, type, organization.id et les attributs système. Cela couvre tous les indicateurs ci-dessous. Nous bloquerions en plus tout filtre qui vise moins de cinq personnes. Une équipe de deux, c’est un rapport individuel déguisé. Le seuil de cinq est notre choix éditorial, pas un chiffre légal.

Sans collecteur, Claude Code peut exposer lui-même un endpoint Prometheus sur http://localhost:9464/metrics avec OTEL_METRICS_EXPORTER=prometheus. Pour un poste, ça marche. Pour une équipe, cela veut dire scraper des portables, ce que nous déconseillons.

Quels indicateurs suivre pour le coût et l’adoption ?

Cinq indicateurs couvrent ce que demandent les responsables budget et les leads techniques : sessions par équipe, tokens par type et modèle, coût estimé par centre de coûts, éditions acceptées contre refusées, lignes modifiées. Regroupez par team.id ou cost_center, sur des semaines plutôt que des jours. Rapprochez ensuite le coût de la facture, car la télémétrie ne fait qu’estimer.

Indicateur Métrique source Agrégation Ce qu’il montre
Adoption claude_code.session.count Sessions par équipe et par semaine, hors start_type="agents_view" Le déploiement est-il utilisé ?
Mix de tokens claude_code.token.usage Somme par type et model Part du cache, part Opus contre Sonnet
Coût par équipe claude_code.cost.usage Somme par cost_center et par mois Consommation avant la facture
Taux d’acceptation claude_code.code_edit_tool.decision accept / (accept + reject) par language Où les suggestions échouent
Production claude_code.lines_of_code.count, claude_code.commit.count Somme par équipe et par sprint Tendance, pas note de performance

Le guide des coûts d’Anthropic donne une base pour les alertes : sur les déploiements entreprise, environ 13 USD par développeur et par jour actif, 150 à 250 USD par développeur et par mois, et 90 % des utilisateurs sous 30 USD par jour actif. Nous alerterions quand le coût journalier d’une équipe dépasse son nombre de personnes actives multiplié par 30 USD. Une boucle qui s’emballe est repérée sans désigner qui que ce soit.

La page monitoring précise que les métriques de coût sont des approximations et que la facturation officielle vient du fournisseur : Claude Console, Amazon Bedrock ou Google Cloud. La télémétrie sert à l’imputation et à l’alerte précoce, la facture cloud à la comptabilité. Notre article sur le prix de Claude Code pour les équipes détaille la facture côté sièges et côté tokens API.

Deux changements de version faussent les courbes. Avant la v2.1.214, les passerelles qui diffusent l’usage sur plusieurs trames gonflaient cost.usage et token.usage d’environ une requête par trame supplémentaire. Avant la v2.1.222, mcp_server.name était posé sur chaque requête suivant un appel MCP, donc la part MCP chute après la mise à jour. Annotez ces deux versions sur vos graphiques.

Qu’est-ce qui change sur Bedrock et Vertex ?

Sur Amazon Bedrock et Google Cloud, OpenTelemetry est la seule vue d’usage par équipe. Les tableaux de bord analytics d’Anthropic et la Claude Code Analytics API ne couvrent pas cet usage. Sans compte Claude, user.email n’apparaît jamais. Les server-managed settings n’y arrivent pas non plus : la configuration passe par fichier de managed settings ou par MDM.

La page usage des données indique que les métriques opérationnelles d’Anthropic, les rapports d’erreur et l’envoi /feedback sont désactivés par défaut dès que CLAUDE_CODE_USE_BEDROCK ou CLAUDE_CODE_USE_VERTEX est défini. Les enquêtes de qualité et la vérification de domaine WebFetch tournent toujours. Sur un fournisseur cloud, les seules données d’usage qui quittent le poste sont celles que vous configurez dans OpenTelemetry. La documentation Claude Code nomme désormais l’offre Google Cloud “Agent Platform”.

Claude Team / Enterprise Bedrock ou Vertex
Tableau de bord intégré claude.ai/analytics/claude-code (Admins, Owners) Aucun côté Anthropic
Identité dans la télémétrie user.email, identifiants de compte Seulement user.id et session.id
Diffusion de la configuration Server-managed ou fichier Fichier ou MDM uniquement
Coût de référence Facture Claude ou rapport de dépenses Facture AWS ou Google Cloud

Faute d’identité, la documentation propose d’en ajouter une par utilisateur via OTEL_RESOURCE_ATTRIBUTES. Pour un tableau d’équipe, nous ne le ferions pas : team.id et cost_center par image de poste, sans la personne.

AWS publie une guidance de monitoring pour Claude Code sur Bedrock avec deux modes. Le mode central fait tourner un collecteur ADOT sur ECS Fargate (0,25 vCPU, 0,5 Go) derrière un load balancer, pour environ 30 à 50 USD par mois, avec export vers CloudWatch. Le mode sidecar envoie directement depuis le poste vers l’endpoint OTLP de CloudWatch, sans coût d’infrastructure. Attention : les tableaux fournis affichent les principaux utilisateurs et le coût par utilisateur via user.email, et les requêtes PromQL de CloudWatch sont limitées à 7 jours. Déployez dans une région UE et retirez les panneaux nominatifs si votre accord avec le CSE limite l’analyse à l’équipe. L’installation de Claude Code lui-même est décrite dans notre guide Claude Code sur Bedrock en Europe.

La Claude Code telemetry est-elle une surveillance des salariés au sens du RGPD ?

Oui, dès que les données se rattachent à une personne. user.email, les identifiants de compte et même le user.id aléatoire sont des données personnelles pour l’employeur, et les sessions par personne décrivent l’activité au travail. Il vous faut une base légale, une finalité limitée (coûts, capacité), une durée de conservation courte et la consultation des représentants du personnel.

La CNIL pose trois conditions cumulatives pour un dispositif de contrôle de l’activité : justification et proportionnalité, passage devant les instances représentatives du personnel, information des salariés avant la mise en œuvre. Le CSE doit être consulté dans les entreprises privées de 50 salariés et plus. La CNIL ajoute qu’une surveillance permanente est en général une atteinte excessive. Le 19 décembre 2024, elle a sanctionné une entreprise de 40 000 euros pour un logiciel qui mesurait l’inactivité et prenait des captures d’écran. Un collecteur qui conserve user.email avec les sessions et le temps actif s’en rapproche plus qu’on ne le pense.

Les valeurs par défaut aident. Le texte du prompt n’est pas collecté, seulement prompt_length. Les réponses sont remplacées par <REDACTED>. Arguments d’outils, commandes Bash et chemins de fichiers restent absents tant que personne ne définit OTEL_LOG_TOOL_DETAILS=1. Le contenu des fichiers n’apparaît jamais dans les métriques ni les événements. Les données vont uniquement à votre endpoint, pas chez Anthropic. Chacune des variables OTEL_LOG_USER_PROMPTS, OTEL_LOG_ASSISTANT_RESPONSES, OTEL_LOG_TOOL_DETAILS et OTEL_LOG_RAW_API_BODIES élargit fortement la collecte. Les corps bruts d’API contiennent tout l’historique de conversation. Dans le pipeline de coûts, nous n’en autoriserions aucune.

Le tableau de bord analytics Team et Enterprise pose plus de questions. Il affiche un classement des 10 premiers contributeurs, un export CSV de tous les utilisateurs et, avec l’application GitHub, attribue les lignes de PR fusionnées aux sessions Claude Code, dans une fenêtre de 21 jours avant à 2 jours après la fusion. Ce sont des données de performance individuelle par conception. Décidez qui peut l’ouvrir avant de l’activer.

Exploiter en interne ou externaliser ?

Exploiter la télémétrie en interne, c’est un service de production de plus : un collecteur joignable depuis chaque poste, des certificats TLS, un jeton ou du mTLS, un stockage de métriques et des tableaux qui cassent quand Claude Code modifie ses attributs. Externaliser a du sens sans équipe observabilité. Si vous exploitez déjà Prometheus ou Grafana, gardez-le en interne.

Travail récurrent sur ce sujet, les charges sont notre estimation :

  1. Exploitation du collecteur : mises à jour, renouvellement des certificats, rotation des jetons, capacité. Moins d’une journée par mois une fois stabilisé.
  2. Maintenance des tableaux : Claude Code documente les changements d’attributs version par version. Quelqu’un doit lire ces notes et corriger les panneaux. Environ une demi-journée par mois.
  3. Gouvernance RGPD : durées de conservation, liste des attributs supprimés, revues d’accès, information et consultation du CSE. Surtout au démarrage, puis chaque trimestre.

Si vous externalisez, exigez précisément : un backend hébergé dans l’UE avec une région nommée ; un contrat de sous-traitant au sens de l’article 28 du RGPD qui couvre explicitement les données de télémétrie, e-mails compris si vous les gardez ; la liste complète des sous-traitants ultérieurs ; un modèle d’accès où le personnel du prestataire ne peut pas interroger les séries individuelles ; des durées de conservation que vous maîtrisez ; un SLA sur l’ingestion, pas seulement sur l’interface ; une clause de réversibilité avec remise de la configuration du collecteur et des données brutes en format OTLP ou Prometheus. Si le prestataire veut les données non filtrées, gardez le collecteur de nettoyage chez vous et ne lui envoyez que le flux agrégé.

FAQ

La Claude Code telemetry est-elle active par défaut ?

Non. L’export vers votre backend est opt-in et demande CLAUDE_CODE_ENABLE_TELEMETRY=1 plus un exportateur. À part, la télémétrie opérationnelle d’Anthropic est active par défaut avec la Claude API et désactivée par défaut sur Bedrock, Vertex et Foundry. DISABLE_TELEMETRY=1 la coupe.

Combien coûte l’exploitation de la Claude Code telemetry ?

Les données sont gratuites, vous payez le collecteur et le stockage. La guidance AWS estime environ 30 à 50 USD par mois pour un collecteur central sur ECS Fargate, ou 0 USD d’infrastructure en mode sidecar, hors CloudWatch. Un Prometheus sur un cluster existant pèse peu.

La Claude Code telemetry enregistre-t-elle les prompts ou le code ?

Pas par défaut. Les événements contiennent la longueur du prompt, le texte des réponses est masqué, le contenu des fichiers n’apparaît jamais dans les métriques ni les événements. Prompts, réponses, arguments d’outils et corps d’API n’apparaissent que si un administrateur active la variable OTEL_LOG_* correspondante.

OpenTelemetry ou tableau de bord analytics Claude : lequel choisir ?

Le tableau de bord si vous êtes sur Team ou Enterprise et voulez l’adoption et l’attribution des PR sans configuration. OpenTelemetry si Claude Code passe par Bedrock ou Vertex, si vous voulez le coût par équipe ou des données dans votre propre backend en Europe. Sur un fournisseur cloud, le tableau de bord reste vide.

Faut-il consulter le CSE avant d’activer la télémétrie ?

Dans une entreprise privée de 50 salariés et plus, oui, si le dispositif permet de contrôler l’activité du personnel. C’est la position de la CNIL. Nous conseillons de présenter la configuration agrégée, la liste des attributs supprimés et la durée de conservation dès la consultation.

Un développeur peut-il couper la télémétrie ?

En partie. Un dépôt ne peut ni activer ni rediriger la télémétrie, mais un dépôt ou un développeur peut passer un exportateur à none. Définir OTEL_METRICS_EXPORTER et OTEL_LOGS_EXPORTER dans les managed settings verrouille aussi ce point. Les endpoints et identifiants centraux ne peuvent pas être détournés.

Sources

  1. Documentation Claude Code : Monitoring (OpenTelemetry) (1 octobre 2026)
  2. Documentation Claude Code : tableau de bord analytics (1 octobre 2026)
  3. Documentation Claude Code : usage des données (1 octobre 2026)
  4. Documentation Claude Code : maîtriser les coûts (1 octobre 2026)
  5. Documentation Claude Code : déployer les managed settings (1 octobre 2026)
  6. Documentation Claude Code : configuration des modèles (1 octobre 2026)
  7. OpenTelemetry Collector : configuration (1 octobre 2026)
  8. OpenTelemetry Collector Contrib : attributes processor (1 octobre 2026)
  9. AWS Solutions Library : monitoring de Claude Code sur Amazon Bedrock (1 octobre 2026)
  10. CNIL : le contrôle de l'activité des personnes employées (1 octobre 2026)
  11. CNIL : surveillance excessive des salariés, sanction de 40 000 euros (1 octobre 2026)

Guides associés