Localisation, distribution et hébergement des modèles

Contrôle : 23 août 2026. Cette vue indique où un modèle peut être obtenu ou exécuté. Elle distingue le développeur du modèle, son distributeur et l’hébergeur effectif. Une disponibilité commerciale depuis la Belgique ne garantit ni l’exécution ni le stockage dans l’Union européenne — et, sur Google Cloud, la présence d’une région belge (europe-west1, Saint-Ghislain) ne garantit pas que les modèles les plus récents y soient servis.

🏗️ Où se construit la capacité de calcul, et ce que cela ne change pas. Anthropic a signé avec Riot Platforms un bail de vingt ans portant sur 191 MW de capacité informatique sur le site de Rockdale, au Texas, pour environ 9,1 milliards USD sur la durée et jusqu’à environ 16,1 milliards si deux prolongations de cinq ans sont exercées; la montée en charge est annoncée à environ 96 MW fin 2027 et 191 MW fin juin 2028. Ce que cela change pour cette vue : rien, à ce stade. La capacité est américaine, contractée et non encore construite; elle ne crée aucune région nouvelle, ne modifie aucune option de résidence et n’ouvre aucune capacité européenne propre. [Déduction] L’intérêt est indicatif : un engagement de cette taille au Texas confirme que la trajectoire d’infrastructure du fournisseur reste nord-américaine. Fait établi par convergence de presse financière de référence; aucun document contractuel ni dépôt réglementaire n’a pu être ouvert [S207].

📁 Nouveau stockage de premier rang, résidence non publiée — API Files et magasins de mémoire. L’API Files de Claude est passée en disponibilité générale le 19 août 2026, avec un quota publié de 1 To de stockage par organisation et 500 requêtes par minute, et les sessions d’agents gérés exécutées en bac à sable auto-hébergé peuvent désormais attacher des magasins de mémoire, que les workers des SDK Python, TypeScript et Go téléchargent au mount_path puis resynchronisent. Ce que cela change pour cette vue : une surface de stockage persistant de premier rang devient stable, sans que sa localisation soit documentée. L’entrée de notes de version ne publie ni région de stockage, ni durée de rétention par défaut, ni engagement de résidence, et les pages de rétention n’ont pas pu être rouvertes. [Déduction] Deux conséquences pratiques. Un fichier téléversé par l’API Files et un magasin de mémoire attaché doivent être traités, jusqu’à preuve du contraire, comme des données hors résidence maîtrisée : le fait que le bac à sable soit auto-hébergé ne dit rien de l’endroit où réside le magasin qu’il synchronise. En revanche, le format GA rend expires_at explicitement et accepte expires_in_seconds au téléversement, ce qui donne enfin un levier de rétention pilotée côté client — le seul contrôle dont on dispose tant que la résidence n’est pas publiée [S213, S214].

♻️ Cycle de vie — Claude Mythos Preview est déprécié. La page officielle des dépréciations, ouverte directement, place claude-mythos-preview en état déprécié avec migration vers claude-mythos-5, lui-même en disponibilité limitée sur invitation. La même page publie les planchers de retrait des modèles actifs : aucun ne peut être retiré avant le 29 septembre 2026. Ces dates valent pour les plateformes opérées par Anthropic ; Amazon Bedrock et Google Cloud fixent leurs propres calendriers, qui peuvent différer — distinction essentielle pour une exigence de résidence satisfaite par un cloud partenaire [S203].

🆕 Hébergement — les environnements auto-hébergés de Claude Code. En bêta publique sur les formules Team et Enterprise, ils font s’exécuter les sessions infonuagiques de Claude Code sur une infrastructure opérée par l’organisation : une session lancée depuis le web, le mobile, le bureau, le terminal ou une routine planifiée tourne dans le réseau de l’organisation, avec les dépôts, artefacts de compilation, secrets et fichiers créés sur des machines qu’elle provisionne. La distinction qui compte pour cette vue : l’auto-hébergement porte sur l’exécution de la session, pas sur l’inférence. Le modèle continue d’être appelé chez Anthropic ou chez le cloud partenaire configuré, et c’est cette inférence qui détermine la résidence du traitement. Présenter cette option comme une souveraineté de bout en bout serait faux. Fait établi en source primaire durable [S192–S193].

🔒 Confidentialité — la Compliance API couvre désormais les transcriptions de sessions. Les points de terminaison de sessions renvoient un enregistrement consolidé — invites, réponses, activité d’outils — pour les sessions locales Cowork et Claude Code exécutées sur les machines des utilisateurs connectés avec un compte Claude Enterprise, et pour les sessions Cowork distantes exécutées dans des environnements gérés par Anthropic. Autrement dit, le lieu d’exécution d’une session locale ne détermine pas à lui seul qui peut en relire le contenu : la transcription est retenue côté serveur et récupérable par l’organisation avec une Compliance Access Key. Sans effet sur les formules individuelles Pro et Max. Fait établi en source primaire durable [S194].

Lecture rapide

• API directe : le fournisseur du modèle contrôle généralement l’inférence ; la région exacte dépend du produit et du contrat.
• Cloud partenaire : AWS, Azure ou Google Cloud distribuent le modèle, mais le lieu réel d’exécution doit être vérifié modèle par modèle.
• Self-host : l’exploitant choisit la région, sous réserve de la licence, des dépendances et des services externes utilisés.
• À confirmer : aucune preuve assez précise n’a été trouvée pour affirmer une résidence ou une disponibilité belge.

Matrice vérifiée

État de vérification au 23 août 2026

Le contraste de résidence entre les deux API directes majeures est le fait dominant de ce contrôle, et il se lit dans le code distribué. Le module _data_residency.py du paquet openai 3.3.1 — téléchargé depuis PyPI, décompressé et lu localement — définit le type DataResidency comme exactement quatre littéraux : "global", "us", "eu" et "ae", associés respectivement à https://api.openai.com/v1, https://us.api.openai.com/v1, https://eu.api.openai.com/v1 et https://ae.api.openai.com/v1. Le fait a été vérifié trois fois sur trois canaux indépendants : l’archive source distribuée, le même module sur la branche principale du dépôt, et la table équivalente du SDK TypeScript openai-node, artefact distinct généré depuis la même spécification. Chez OpenAI, une zone européenne existe donc et se désigne par son nom depuis le code du client. Chez Anthropic, la relecture du même jour de la documentation de résidence — ouverte directement — établit l’inverse, et l’établit explicitement : la page énonce en limitation courante que « seules "us" et "global" sont disponibles » pour inference_geo, et que le geo d’espace de travail n’admet que « us », sans modification possible après création de l’espace. Autrement dit, non seulement l’inférence ne peut pas être épinglée dans l’EEE sur l’API de premier rang, mais le stockage au repos y est structurellement américain. La page précise en outre que inference_geo ne s’applique pas sur Bedrock ni sur Google Cloud — la région y découle de l’URL d’endpoint ou du profil d’inférence — ni via l’endpoint de compatibilité OpenAI, et que sur Microsoft Foundry le type de déploiement « US Data Zone Standard » joue un rôle équivalent au même multiplicateur de 1,1×. Deux réglages d’espace de travail encadrent le tout : allowed_inference_geos, qui restreint les geos utilisables, et default_inference_geo, qui fixe le repli. La réserve qui commande la décision : l’artefact OpenAI prouve que l’endpoint européen existe et est sélectionnable, non qu’un compte donné y est éligible, ni ce que la résidence couvre exactement. Tant que le fournisseur n’a pas répondu par écrit sur ces deux points, la ligne à retenir est celle d’une capacité technique établie et d’une garantie contractuelle non établie — une distinction qui, sur un dossier de conformité, fait toute la différence [S222, S225].

Deux lignes Anthropic reposent sur une documentation primaire ouverte directement. Pour l’API directe, la documentation de résidence des données établit deux réglages indépendants : le paramètre inference_geo de POST /v1/messages, qui gouverne le lieu d’inférence et n’accepte que « global » — le défaut, où l’inférence peut s’exécuter dans n’importe quelle géographie disponible, au prix standard — et « us », qui la tient sur infrastructure américaine avec un multiplicateur de 1,1× appliqué à toutes les catégories de jetons, entrée, sortie, écritures et lectures de cache ; et le Workspace geo, configuré dans la console, qui gouverne le stockage au repos et les traitements d’endpoint comme le transcodage d’images ou l’exécution de code. La relecture exhaustive de cette page ne fait apparaître aucune valeur européenne : il n’existe pas de pinning d’inférence dans l’EEE sur l’API de premier rang, et le multiplicateur 1,1× est donc une prime d’inférence américaine, non un coût de conformité européenne — nuance que Claude Code 2.1.239 rend visible en intégrant cette prime dans /cost. Le paramètre n’est par ailleurs accepté que sur Claude 4.6 et versions ultérieures : sur Opus 4.5, Sonnet 4.5, Haiku 4.5 et antérieurs, il renvoie une erreur 400. Une exigence de résidence UE sur Claude passe donc par AWS Bedrock ou Google Cloud en région UE. Sur Google Cloud, cette voie a une contrainte que la seule lecture des prix ne montre pas : la région belge europe-west1 (Saint-Ghislain) figure bien au catalogue Claude, mais ses quatre volets monorégionaux ne servent aucun modèle de génération 5. Un besoin combinant génération 5 et inférence tenue dans l’EEE impose EU Multi-Region, à +10 %. La vue d’ensemble des modèles documente par ailleurs Claude Mythos 5 en disponibilité limitée sur invitation, sans condition de résidence propre publiée. Point de vigilance déjà documenté et inchangé : dans Microsoft Foundry, les modèles Anthropic s’exécutent sur l’infrastructure d’Anthropic et non dans la région Azure sélectionnée.

Pour Mistral, la résidence européenne de l’inférence est désormais un produit facturé : api.eu.mistral.ai épingle l’exécution en Europe pour 1,1× le tarif standard, établi par convergence de sources indépendantes à 88/100. Réserve inchangée : un endpoint UE ne signifie pas qu’aucune donnée ne quitte l’UE — la liste des sous-traitants doit être lue avant toute inscription dans un registre de traitement.

Pour Google, la ligne Gemini 3.7 Flash est établie par convergence à 88/100 : la couverture EEE est documentée pour la famille 3.x, mais aucune disponibilité régionale UE n’est confirmée pour cette version précise. C’est exactement le type de raccourci que cette vue existe pour éviter — une famille disponible dans l’EEE ne rend pas chacune de ses versions résidente en UE.

Pour DeepSeek et Z.AI, la publication ou la rétention des poids change la voie défendable depuis la Belgique : auto-hébergement possible pour DeepSeek V4 Pro 0813 sous MIT, impossible pour GLM-5.3 tant que ses poids ne sont pas parus.

Toutes les autres lignes n’ont pas pu être revérifiées : les domaines fournisseurs concernés restent bloqués par la politique de sortie réseau. Elles conservent la confiance obtenue lors de leur dernière vérification effective et portent, dans dashboard/data/latest.json, un statut explicite « non revérifié ».

Règle de décision

Avant une mise en production, conserver une preuve datée pour le modèle précis, la région du endpoint, les journaux, le stockage, les sous-traitants et les fonctions annexes comme la recherche web ou les outils. Cette analyse est informative et ne constitue pas un avis juridique.