L'emplacement des données compte, mais ne résout pas à lui seul la juridiction

Savoir dans quelle région une ressource est stockée aide à évaluer les exigences de résidence, de latence, de redondance et de récupération. L'emplacement doit être examiné par service et par ressource : dans Cloud Storage, par exemple, le type d'emplacement détermine comment l'information est répliquée.

Pour une migration réglementée, séparez trois questions : où sont stockées les données principales, où elles peuvent être répliquées ou traitées et quelles entités peuvent y accéder. L'emplacement doit être évalué par ressource et par service, ainsi que les conditions applicables à l'organisation.

L'emplacement affecte également les décisions techniques. Dans Google Cloud Storage, une région, une double-région et une multi-région ont des comportements de redondance et de coût distincts ; placer le stockage près du calcul peut aider les performances. Choisissez l'emplacement selon l'exigence concrète, pas parce que le nom géographique semble suffisant.

Région, zone et centre de données ne signifient pas la même chose

Dans Google Cloud Storage, une région est un lieu géographique spécifique ; une double-région comprend deux régions et une multi-région couvre une zone géographique vaste avec deux régions ou plus. Le type d'emplacement détermine comment l'information est répliquée et facturée. Les options concrètes dépendent du service.

Ne supposez pas qu'un code de région identifie un bâtiment unique. Dans Cloud Storage, Google distingue les emplacements régionaux, double-régionaux et multi-régionaux ; les objets d'une double-région sont répliqués dans les régions qui la composent, tandis qu'une multi-région couvre une zone géographique plus large. La granularité configurée par le client dépend du service et ne doit pas être confondue avec la localisation physique de chaque copie.

Tous les services d'un même projet n'héritent pas non plus d'un emplacement unique. La documentation Firebase indique que des produits comme Cloud Firestore et Cloud Storage nécessitent des emplacements configurés par instance ou bucket, et que certaines fonctions ont une région par défaut si aucune n'est spécifiée. Une configuration de projet ne prouve pas automatiquement où se trouvent toutes ses ressources.

Vérifiez chaque ressource dans la console et les métadonnées

Commencez par inventorier les services qui contiendront des données personnelles ou confidentielles : bases de données, buckets, disques, sauvegardes, files, journaux et services d'analytique. Pour chaque élément, notez l'identifiant de la ressource, le service, la région configurée, le compte ou projet propriétaire et les dépendances pouvant générer des copies ou un traitement supplémentaire. L'unité de vérification est la ressource, pas seulement le compte cloud.

Dans Google Cloud Storage, l'emplacement fait partie des métadonnées du bucket et peut être consulté avec les permissions appropriées. La documentation officielle distingue région, double-région et multi-région, et spécifie que l'emplacement choisi influence la réplication et le prix. Dans Firebase, le guide des emplacements décrit où vérifier l'emplacement des bases de données, buckets, backends et fonctions ; certains produits, comme Gemini Developer API dans Firebase AI Logic, sont décrits comme globaux.

Le guide AWS DataSync indique que, pour transférer des données vers un bucket Amazon S3 ou depuis celui-ci, un emplacement de transfert est créé et DataSync reçoit l'accès au bucket via un rôle IAM. Cette configuration décrit l'accès nécessaire pour le transfert.

Azure Portal permet de gérer les ressources et de les voir organisées par service et groupe de ressources. Pour vérifier la résidence, identifiez la région concrète de chaque ressource et vérifiez séparément les fonctions qui l'accompagnent, comme la redondance géographique, la récupération après sinistre et les services de surveillance. Une région de déploiement ne démontre pas que toutes les données dérivées ou auxiliaires ont la même portée territoriale.

Certifications : utiles pour les contrôles, insuffisantes pour localiser les données

ISO/IEC 27001 se réfère à un système de gestion de la sécurité de l'information dans un périmètre défini ; ce n'est pas une carte des centres de données ni une certification universelle de résidence. Avant de lui attribuer une valeur pour une migration, identifiez quelle entité, quel service, quelle région et quelles activités le certificat couvre, en plus de sa validité et de son organisme émetteur.

Les fournisseurs publient des périmètres qui peuvent varier par service ou géographie. Par exemple, Esri explique que le périmètre de sa certification ISO 27001 pour ArcGIS ISO Cloud s'applique aux services hébergés dans son emplacement régional européen et ne s'étend pas automatiquement à l'APAC. Il précise également que les certifications AWS ou Microsoft Azure sur l'infrastructure sous-jacente n'élargissent pas d'elles-mêmes le périmètre de la certification d'Esri.

La page de conformité d'OVHcloud distingue les services inclus et signale un périmètre spécifique pour les centres de données des États-Unis. En tant que vérification pratique, demandez le certificat et examinez son périmètre pour le service contracté. Une certification soutient les contrôles inclus dans ce périmètre.

Évaluez séparément la sécurité, la confidentialité, la conformité et la localisation. Vérifiez le périmètre concret de chaque certificat ou rapport : il peut identifier l'entité, les services et les emplacements inclus. OVHcloud, par exemple, indique que ses certificats et rapports couvrent les services hébergés dans ses centres de données, avec un périmètre spécifique pour les États-Unis.

Certificaciones: útiles para controles, insuficientes para localizar datos ISO/IEC 27001 se refiere a un sistema de gestión de seguridad de la información dentro de un alcance defi...
Imagen generada con IA por BytePreview · AI generated editorial image

Erreurs fréquentes lors de l'inférence de l'emplacement

Pour connaître l'emplacement d'une ressource, consultez les métadonnées ou la configuration d'emplacement offerte par le service. Dans Cloud Storage, l'emplacement du bucket fait partie de ses métadonnées et peut être consulté avec les permissions appropriées.

Une autre erreur est de supposer que tous les services d'un même projet ont un emplacement unique. Firebase distingue les ressources dont l'emplacement est configuré par instance, bucket ou backend, et les produits pour lesquels un emplacement ne peut pas être sélectionné, comme Gemini Developer API dans Firebase AI Logic. Examinez l'emplacement selon le produit et la ressource.

Enfin, ne confondez pas la disponibilité régionale avec l'emplacement de chaque objet. Les options de redondance peuvent impliquer des répliques dans plusieurs régions ; cela peut être souhaitable pour la résilience, mais doit s'aligner avec les restrictions de résidence. Confirmez quelle modalité est active, comment se comporte la récupération et s'il existe des restrictions pour changer ou déplacer l'emplacement.

Checklist avant de migrer des données sensibles

Avant d'approuver le transfert, convertissez l'exigence légale et opérationnelle en vérifications démontrables et maintenables. Une capture d'écran peut servir d'enregistrement ponctuel, mais ne remplace pas une clause contractuelle ni une procédure de contrôle des changements. Conservez la configuration et sa date de révision dans l'inventaire des actifs.

  • Identifiez chaque service et ressource qui stockera, répliquera ou traitera des données sensibles.
  • Enregistrez la région, la zone si applicable, la modalité de redondance et l'emplacement des sauvegardes.
  • Vérifiez l'emplacement effectif et qui a les permissions pour le modifier dans la console ou les métadonnées.
  • Examinez les emplacements des journaux, du support, de la surveillance, de l'analytique et des services connectés.
  • Demandez des certificats et rapports avec un périmètre, une entité, un service, une géographie et une validité identifiables.
  • Contrastez la résidence et les transferts avec le contrat, les conditions de service et l'analyse juridique applicable.
  • Définissez qui examinera les changements de région, les nouvelles répliques et les exceptions après la migration.

La décision finale ne consiste pas à choisir un pays à partir d'une étiquette de produit, mais à vérifier que l'architecture satisfait l'exigence. Documentez les emplacements et les modalités de redondance configurés pour chaque ressource et évaluez tout composant dont l'emplacement vous ne pouvez pas déterminer par rapport aux besoins de la charge de travail.

Le résultat pratique est un dossier par charge de travail : ressources identifiées, emplacements documentés, périmètre contractuel et certifications pertinentes, ainsi que responsables et contrôles de changement. Si vous ne pouvez pas démontrer l'emplacement d'une pièce critique, ne la traitez pas comme équivalente aux autres ni supposez qu'elle est couverte par la région principale.

Vérifier la résidence des données avant une migration cloud

Parcourez ces étapes pour examiner les emplacements configurés, les copies et traitements associés, puis la portée des engagements et certifications.

  1. Inventaire

    Services et ressources concernés

  2. Emplacement

    Vérification par ressource

  3. Réplication

    Copies et services associés

  4. Accès de transfert

    Rôles et permissions

  5. Périmètre de certification

    Services et géographies inclus

  6. Suivi

    Configuration et révisions

Préparation d’une migration vers le cloud

L’emplacement configuré ne permet pas, à lui seul, de déterminer tous les accès, traitements ou obligations juridictionnelles.

Sources et références4