Technologie

Bedrock garde Gemma 4 dans l’UE, mais isole aussi les outils AWS

|Auteur: Équipe éditoriale de QUASA|5 min de lecture
Bedrock garde Gemma 4 dans l’UE, mais isole aussi les outils AWS

Le 17 septembre 2026, AWS a rendu généralement disponibles Gemma 4 31B, Gemma 4 26B-A4B et Gemma 4 E2B dans Amazon Bedrock sur l’AWS European Sovereign Cloud. L’annonce d’AWS publiée ce jour-là situe toute l’inférence dans la région eusc-de-east-1 et exclut le routage global vers les régions commerciales.

La garantie porte donc sur le lieu de traitement des requêtes, mais elle s’accompagne d’une frontière opérationnelle. L’analyse indépendante de Musthave.AI confirme l’inférence dans cette région souveraine, l’absence de routage mondial et la disponibilité des interfaces Responses et Chat Completions compatibles avec les SDK OpenAI.

L’inférence et les métadonnées restent dans l’Union

Les prompts, les images éventuellement envoyées et les réponses de Gemma 4 sont traités dans eusc-de-east-1, au Brandebourg. Bedrock ne peut pas déplacer automatiquement ces requêtes vers une région de la partition commerciale pour répartir la charge ou répondre à un pic de demande.

Le périmètre souverain couvre aussi les métadonnées créées par le client, notamment les rôles, autorisations, étiquettes de ressources et configurations. Les opérations quotidiennes sont contrôlées par des salariés d’AWS résidant dans l’Union européenne ; l’exploitation doit progressivement passer à des citoyens de l’UE qui y résident, mais cette transition n’est pas encore présentée comme achevée.

Pour les données d’inférence, Bedrock applique par défaut un modèle sans accès des opérateurs aux entrées et sorties et sans conservation de celles-ci. Une rétention limitée peut toutefois exister pour certains modèles afin de détecter les abus, sans indication publique que cette exception concerne précisément les variantes de Gemma 4 disponibles dans le cloud souverain.

L’API Responses peut, de son côté, gérer des conversations avec état. Cette fonction constitue un stockage demandé par l’application et doit être distinguée de la conservation par défaut des entrées et sorties : la résidence européenne ne signifie pas nécessairement qu’aucune donnée applicative n’est enregistrée.

La souveraineté repose sur une partition AWS distincte

L’AWS European Sovereign Cloud appartient à la partition aws-eusc, séparée de la partition commerciale aws. Le guide d’architecture AWS décrit un plan de contrôle, une console, des instances IAM et IAM Identity Center, des points de terminaison, une organisation et une facturation propres à cet environnement.

Les ressources souveraines utilisent le préfixe arn:aws-eusc et les services le domaine amazonaws.eu. Une entreprise déjà organisée dans AWS commercial ne peut donc pas traiter eusc-de-east-1 comme une région supplémentaire de son organisation existante : elle doit exploiter une seconde landing zone et un compte payeur distinct, facturé en euros.

IAM Identity Center peut être relié au même fournisseur d’identité d’entreprise par SAML ou SCIM. Les utilisateurs peuvent ainsi conserver leurs identifiants habituels, mais les jeux d’autorisations, groupes et affectations de comptes restent administrés séparément dans chaque partition. Un rôle créé dans aws ne peut pas assumer un rôle situé dans aws-eusc, ni l’inverse.

Les garanties et les contraintes, dimension par dimension

La résidence des données ne produit pas la même conséquence sur toutes les couches de l’architecture :

  • Inférence : les requêtes Gemma 4 restent dans eusc-de-east-1 ; le routage global interrégional n’est pas disponible.
  • Rétention : les entrées et sorties ne sont pas conservées par défaut, mais une application peut demander un état conversationnel ; une exception limitée demeure possible pour la détection des abus sur certains modèles.
  • Opérateurs et métadonnées : les opérations quotidiennes sont contrôlées depuis l’UE et les métadonnées créées par le client y demeurent.
  • Identités : un fournisseur d’identité commun peut desservir les deux environnements, tandis que les instances IAM, les rôles et les autorisations restent propres à chaque partition.
  • Réplication et réseau : AssumeRole, le peering de VPC, Transit Gateway, AWS Resource Access Manager et la réplication S3 ne franchissent pas la limite entre aws et aws-eusc.
  • Comptes et facturation : l’organisation, le compte payeur, la console et le regroupement des coûts sont séparés de leurs équivalents commerciaux.

Cette frontière touche aussi les déploiements. Les images de conteneurs, les images machine, les artefacts applicatifs et les journaux ne disposent pas d’un mécanisme automatique de copie entre les deux partitions. Leur transfert passe par une intégration réseau ou une API, avec des identifiants propres à chaque côté, puis par un stockage ou un registre situé dans aws-eusc.

La compatibilité OpenAI ne supprime pas la séparation

Gemma 4 est servi par le point de terminaison bedrock-mantle, qui expose les API Responses et Chat Completions. Une application fondée sur un SDK OpenAI peut conserver une partie de son code, sous réserve de modifier notamment l’URL de base, l’identifiant du modèle et le mécanisme d’authentification.

Cette compatibilité concerne l’interface d’appel, pas l’administration. Les clés, rôles, projets Bedrock, règles de réseau et données de facturation du cloud commercial ne sont pas transférés dans aws-eusc. Les autorisations nécessaires à l’inférence doivent être accordées dans la partition souveraine.

Une disponibilité effective, sans continuité inter-partitions

Gemma 4 est disponible en production dans Bedrock sur l’AWS European Sovereign Cloud, et non sous la forme d’une préversion annoncée pour plus tard. Le périmètre actuellement documenté associe une inférence cantonnée à la région souveraine, des métadonnées client conservées dans l’Union et des opérations quotidiennes contrôlées par des résidents de l’UE.

La contrepartie est durable : l’absence de rôles, de réplication, de réseau partagé et de facturation consolidée entre aws et aws-eusc découle de la partition qui porte ces garanties. De futures régions souveraines pourraient étendre les possibilités à l’intérieur d’aws-eusc, mais aucune continuité automatique avec AWS commercial n’est actuellement annoncée.

À lire aussi:

Partager:

Abonnez-vous à notre newsletter

Recevez directement les dernières actualités sur le Web3, l’IA et les cryptomonnaies.

0