Dans quel centre de données Claude effectue-t-il ses calculs ? Suivre la connexion et limiter le traitement à la Suisse ou à l’UE

Quiconque utilise Claude via claude.ai, Claude Code ou l’API ne sait pas dans quel centre de données le modèle traite sa requête. Seul le premier tronçon de la connexion, jusqu’au nœud edge le plus proche, est visible. Pour les entreprises qui transmettent des données personnelles ou des contenus confidentiels à un modèle de langage, cela ne suffit pas : elles doivent pouvoir démontrer à leurs clients, conseillers en protection des données ou à l’audit où le traitement a lieu.

Cet article montre jusqu’où la connexion peut être suivie, ce qui est publiquement connu des centres de données d’Anthropic et par quelles voies le traitement peut être limité de manière contraignante à l’UE ou à l’espace UE plus Suisse. Les prix et les régions correspondent à la situation au 2 octobre 2026.

Focus Suisse : La loi fédérale révisée sur la protection des données (revLPD) est déterminante. Une communication de données personnelles à l’étranger est autorisée selon l’art. 16 revLPD lorsque le Conseil fédéral atteste que l’État de destination assure une protection adéquate (annexe 1 de l’ordonnance sur la protection des données, OPDo) ou lorsque des garanties appropriées, telles que des clauses contractuelles types, existent. Les États de l’UE et de l’EEE figurent sur cette liste ; les États-Unis uniquement pour les entreprises certifiées selon le Swiss-U.S. Data Privacy Framework. Un lieu de traitement dans l’UE simplifie donc considérablement la justification, sans remplacer les autres obligations (contrat de sous-traitance, information des personnes concernées, sécurité des données).

Remarque UE : Pour les entreprises établies dans l’UE, les art. 44 et suivants du RGPD s’appliquent à la place. La Commission européenne a reconnu à la Suisse un niveau adéquat de protection des données (décision d’adéquation 2000/518/CE, confirmée en janvier 2024) ; un traitement à Zurich ne constitue donc pas, pour les entreprises de l’UE, un transfert vers un pays tiers au sens problématique du terme.

Quelles étapes une requête vers Claude traverse

Une requête vers claude.ai ou api.anthropic.com passe par trois étapes :

Les noms d’hôte claude.ai et api.anthropic.com pointent tous deux vers l’adresse 160.79.104.10. Elle appartient au préfixe 160.79.104.0/23, enregistré au nom d’Anthropic (AS399358) et dont l’origine Anthropic est valide selon RPKI. Dans le routage mondial, ce préfixe est toutefois annoncé exclusivement via Cloudflare (AS13335) : Anthropic introduit ses propres adresses IP dans le réseau Anycast de Cloudflare. La même adresse répond ainsi depuis chaque emplacement Cloudflare dans le monde, et la connexion aboutit au nœud edge le plus proche.

Déterminer le nœud edge lui-même

Cloudflare révèle le site qui répond sur une page de diagnostic et dans l’en-tête cf-ray. Le code situé après l’ID Ray est un code aéroportuaire IATA : ZRH désigne Zurich, GVA Genève, FRA Francfort, MRS Marseille.

curl -s https://api.anthropic.com/cdn-cgi/trace

Dans la sortie, les lignes colo= (emplacement edge) et loc= (pays auquel Cloudflare associe votre adresse source) sont pertinentes. Sous Windows, PowerShell fournit le même résultat :

$trace = Invoke-WebRequest -Uri "https://api.anthropic.com/cdn-cgi/trace" -UseBasicParsing
$trace.Content

Vous pouvez lire l’en-tête au moyen d’une requête HEAD :

curl -sI https://api.anthropic.com/ \
  | grep -i -E '^(server|cf-ray):'

Options expliquées

Option	Effet
-s	Supprime l’indicateur de progression et les messages d’erreur de curl
-I	Envoie une requête HEAD et n’affiche que les en-têtes de réponse
grep -i	Recherche sans tenir compte de la casse
-E '^(server|cf-ray):'	Expression régulière étendue : uniquement les lignes qui commencent par server: ou cf-ray:

Depuis un réseau suisse, il faut généralement s’attendre à ZRH ou GVA. Si la sortie Internet se trouve ailleurs, par exemple dans un réseau d’entreprise avec une sortie centralisée à l’étranger, le nœud edge répond depuis cet endroit, par exemple avec colo=FRA ou colo=MRS. L’emplacement edge suit donc votre sortie réseau, et non le lieu du traitement.

Pourquoi le traceroute s’arrête à l’edge

Un traceroute montre le chemin jusqu’au nœud edge, mais pas au-delà :

Test-NetConnection -ComputerName api.anthropic.com -TraceRoute -Hops 20

Options expliquées

Option	Effet
-ComputerName api.anthropic.com	Hôte cible de la mesure
-TraceRoute	Détermine les sauts de routeurs sur le chemin vers la cible
-Hops 20	Nombre maximal de sauts vérifiés

Sous Linux et macOS, l’équivalent est traceroute -n api.anthropic.com (-n supprime la résolution DNS des sauts). Dans la mesure, les derniers sauts avant 160.79.104.10 se trouvaient dans la plage d’adresses 162.158.0.0/15, qui appartient à Cloudflare. Ensuite, la trace s’arrête : la connexion est terminée au nœud edge, et l’acheminement vers le backend se fait via une nouvelle connexion interne, non visible depuis l’extérieur.

RIPEstat indique à qui appartient le préfixe et par quel réseau il est annoncé :

curl -s "https://stat.ripe.net/data/prefix-overview/data.json?resource=160.79.104.10"
curl -s "https://stat.ripe.net/data/bgp-state/data.json?resource=160.79.104.0/23"

Dans le second résultat, tous les chemins AS se terminent par 13335 399358 : Cloudflare est le seul upstream du préfixe Anthropic.

D’après mes recherches, il n’existe aucune mesure publique permettant de retracer le chemin jusqu’à un centre de données d’inférence et, en raison de la terminaison à l’edge, cela n’est pas non plus possible avec des outils réseau. Les services de mesure tels que llmlatency.dev ne mesurent que le temps de réponse jusqu’au premier octet à l’edge (en septembre 2026 : médiane de 96 ms depuis US-Central, 199 ms depuis l’Allemagne). Il serait certes possible de comparer le délai jusqu’au premier token (Time to First Token) depuis plusieurs sites, mais il dépend davantage du modèle, de la longueur du prompt et de la charge que de la distance. En déduire un emplacement ne serait donc pas fiable.

Ce que l’on sait des centres de données d’Anthropic

Anthropic n’exploite à ce jour aucun centre de données d’inférence propre publiquement associé à une adresse. La puissance de calcul provient de partenariats compilés par Tim Cadenbach dans le blog TCDEV :

L’entraînement et l’inférence n’ont pas nécessairement lieu au même endroit. L’inférence peut s’exécuter dans n’importe quelle région AWS ou Google Cloud, et Anthropic ne révèle pas quel site calcule la réponse pour un utilisateur en Suisse. Seul ce que prévoit la déclaration de confidentialité est établi : le partenaire contractuel et responsable des clients de l’EEE, du Royaume-Uni et de Suisse est Anthropic Ireland, Limited à Dublin ; les données sont transférées vers des serveurs aux États-Unis ou dans d’autres pays hors EEE sur la base de clauses contractuelles types.

Le contrôle directement chez Anthropic : États-Unis ou global uniquement

Depuis les modèles de génération 4.6, l’API Claude connaît le paramètre inference_geo. Il comporte exactement deux valeurs :

Il n’existe aucune valeur pour l’UE ou la Suisse. Le lieu de stockage du workspace (workspace geo) ne peut actuellement être défini que sur us. La réponse indique dans le champ usage.inference_geo quel réglage a été appliqué, mais pas de région concrète. Pour Haiku 4.5 et les modèles plus anciens, l’API renvoie une erreur 400 pour ce paramètre.

Pour claude.ai et Claude Code avec un abonnement (Pro, Max, Team, Enterprise), il n’existe aucun réglage du lieu de traitement. Les offres directes d’Anthropic ne permettent donc de limiter le traitement ni à l’UE ni à la Suisse. Cela n’est possible qu’au moyen des fournisseurs cloud qui exploitent Claude dans leurs propres régions.

AWS Bedrock : espace UE plus Suisse depuis Zurich

AWS Bedrock exploite Claude sur l’infrastructure AWS. Selon AWS, Anthropic n’a pas accès aux prompts, réponses ou journaux des clients. Vous choisissez la région par la région source de votre appel API et par l’Inference Profile :

Pour la Suisse, la région eu-central-2 (Zurich) est déterminante. Opus 5.5, Sonnet 5.5 et Haiku 4.5 y sont disponibles, mais uniquement sous forme de profils Global ou EU, et non In-Region. Il n’existe pas de profil qui calcule exclusivement à Zurich. Lorsque le profil EU est appelé depuis Zurich, AWS répartit les requêtes, selon la carte de modèle (documenté pour Haiku 4.5 et Sonnet 4.6), entre les régions suivantes :

Zurich n’est une destination possible que si la requête provient de Zurich. Le traitement reste donc dans l’espace UE plus Suisse. Pour Opus 5.5 et Sonnet 5.5, la carte de modèle ne mentionne pas les régions cibles ; l’API renvoie la liste effective :

aws bedrock get-inference-profile \
  --region eu-central-2 \
  --inference-profile-identifier eu.anthropic.claude-sonnet-5-5 \
  --query "models[].modelArn"

Options expliquées

Option	Effet
bedrock get-inference-profile	Lit la définition d’un Inference Profile
--region eu-central-2	Région source Zurich ; la liste des destinations dépend de la région source
--inference-profile-identifier	ID du profil EU pour Sonnet 5.5
--query "models[].modelArn"	Affiche uniquement les ARN de modèle ; la région figure dans chaque ARN

Par défaut, les données ne sont stockées que dans la région source. Les contenus conservés pour la détection des abus constituent une exception : ils sont stockés dans la région cible. Le transport entre régions est chiffré via le réseau AWS.

Prouver la région de traitement pour chaque requête

Bedrock est la seule des voies décrites qui consigne la région de traitement effective pour chaque requête. CloudTrail l’écrit dans la région source, dans le champ additionalEventData.inferenceRegion :

aws cloudtrail lookup-events \
  --region eu-central-2 \
  --lookup-attributes AttributeKey=EventSource,AttributeValue=bedrock.amazonaws.com \
  --max-results 20 \
  --query "Events[].CloudTrailEvent" \
  --output text \
  | jq -r '[.eventTime, .eventName, .additionalEventData.inferenceRegion] | @tsv'

Options expliquées

Option	Effet
cloudtrail lookup-events	Recherche les événements CloudTrail des 90 derniers jours
--region eu-central-2	Région source dans laquelle les appels sont consignés
--lookup-attributes AttributeKey=EventSource,AttributeValue=bedrock.amazonaws.com	Filtre les événements Bedrock
--max-results 20	Limite la sortie à 20 événements
--query "Events[].CloudTrailEvent"	N’affiche que l’événement complet sous forme de texte JSON
--output text	Sortie sans enveloppe JSON, un événement par ligne
jq -r '… | @tsv'	Extrait l’heure, l’action et la région de traitement sous forme de ligne séparée par des tabulations

En outre, une Service Control Policy (SCP) dans AWS Organizations permet de bloquer toutes les régions hors de l’UE et de la Suisse. Si une région cible d’un profil est bloquée, la requête échoue au lieu de basculer vers une autre région. Avec cette combinaison, le lieu de traitement est techniquement imposé et peut être prouvé pour chaque requête.

Claude Code via Bedrock dans l’UE

Claude Code peut également fonctionner via Bedrock. Dans une région eu-*, Claude Code sélectionne automatiquement le préfixe eu. :

export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=eu-central-2
claude

Le préfixe peut être remplacé avec ANTHROPIC_BEDROCK_REGION_PREFIX. L’authentification AWS s’effectue par les mécanismes habituels (profil, SSO, variables d’environnement). La facturation passe par le compte AWS, et non par un abonnement Claude.

Google Vertex AI : UE uniquement, Suisse explicitement exclue

Sur Google Cloud (Vertex AI, désormais sous le nom Gemini Enterprise Agent Platform), la situation est moins favorable pour la Suisse :

Google exclut explicitement la Suisse du point de terminaison multi-région UE : il ne couvre que les États membres de l’UE ; le Royaume-Uni et la Suisse n’en font pas partie. Plusieurs pages de conseil suisses présentent europe-west6 comme une voie vers Claude à Zurich ; selon le tableau officiel des emplacements de Google, aucun modèle Claude n’y est disponible. Google ne documente pas de champ de journal indiquant la région de traitement effective pour chaque requête. Pour le point de terminaison global, Google précise que la région de traitement ne peut être ni contrôlée ni déterminée.

Vertex AI convient donc à un traitement exclusivement dans l’UE, mais non à un traitement en Suisse.

Microsoft Foundry : actuellement aucune option UE

Microsoft propose Claude dans Foundry sous deux variantes. « Hosted on Azure » calcule sur l’infrastructure Azure, en Global Standard ou en Data Zone Standard ; pour Claude, la Data Zone n’existe que pour les États-Unis. « Hosted on Anthropic » calcule sur l’infrastructure Anthropic, et Microsoft précise que les données peuvent être traitées en dehors d’Azure et en dehors de la région sélectionnée. Anthropic indique Foundry pour l’Europe comme « Coming soon ». Dans Microsoft 365 Copilot et Copilot Studio, les modèles Anthropic sont exclus de la EU Data Boundary et sont désactivés par défaut dans l’UE, l’AELE (donc aussi en Suisse) et au Royaume-Uni.

Vue d’ensemble : quelle voie garantit quel lieu de traitement

Aucun fournisseur ne propose actuellement de voie garantissant que le traitement de Claude soit limité à la Suisse. AWS Bedrock avec région source Zurich et profil EU s’en approche le plus. S’il faut également exclure que les données quittent l’UE, par exemple en raison d’engagements contractuels envers des clients de l’UE, le profil EU peut être appelé depuis une région UE telle que Francfort ; Zurich ne constitue alors plus une destination.

Ce que coûte l’ancrage régional

Les trois fournisseurs cloud et Anthropic facturent eux-mêmes un supplément de 10 % pour l’ancrage à une région ou à une géographie par rapport au point de terminaison global. Chez Bedrock, les prix dépendent de la région source ; Zurich, Francfort et Virginie du Nord coûtent la même chose. Le routage entre régions n’est pas facturé en supplément.

Prix catalogue en USD par million de tokens (entrée / sortie) :

Pour Vertex AI, le prix de la colonne UE s’applique à Haiku 4.5 et Sonnet 4.6 dans la région europe-west1. Exemple de calcul pour une application interne avec 50 millions de tokens d’entrée et 10 millions de tokens de sortie par mois :

L’ancrage régional coûte donc 10 % de plus que le point de terminaison global. Par rapport au prix catalogue directement chez Anthropic avec inference_geo: "us", un profil EU sur Bedrock coûte le même prix. Les coûts annexes pèsent davantage dans le choix : un compte AWS ou Google Cloud avec des politiques d’organisation, de la journalisation et des alertes budgétaires doit être mis en place et exploité, et les prix mensuels fixes des abonnements Claude cèdent la place à une facturation purement à la consommation. La rentabilité du changement dépend du volume ; un abonnement a un prix fixe par personne, mais n’offre aucun contrôle sur le lieu de traitement.

Conservation et entraînement

Outre le lieu, la durée de conservation des données est importante :

• API Anthropic : les prompts et les réponses ne sont pas utilisés pour l’entraînement sans consentement explicite. La Zero Data Retention (ZDR) est disponible sur demande par organisation et peut être combinée avec inference_geo. Les contenus signalés par la détection des abus restent stockés jusqu’à deux ans, même avec ZDR. Pour les modèles Fable et Mythos, une conservation de 30 jours est obligatoire.
• AWS Bedrock : les contenus ne sont pas transmis à Anthropic. La conservation peut être choisie par modèle entre none, default et aws_review; Fable exige aws_review avec jusqu’à 30 jours de stockage pour examen par AWS.
• Google Vertex AI : Google n’utilise les données pour l’entraînement ou le fine-tuning qu’avec un consentement préalable.