Infrastructure mondiale du cloud et organisation des ressources

Une région est une zone géographique où un fournisseur propose des services cloud à partir d’un groupe de centres de données. Le choix d’une région place la plupart des ressources, comme une base de données, dans cette zone. Les régions sont conçues pour fonctionner indépendamment, ce qui aide à contenir les pannes régionales.

Identifier correctement l’emplacement

AWS, Microsoft Azure et Google Cloud utilisent des noms différents pour des emplacements similaires. Un nom affiché aide à reconnaître un lieu ; un code l’identifie dans les commandes et les modèles.

Un nom seul peut induire en erreur. Azure West Europe (westeurope) se trouve aux Pays-Bas ; North Europe se trouve en Irlande. La région Google Cloud europe-west4 se trouve aux Pays-Bas, tandis que europe-west1 se trouve en Belgique. AWS Europe (Frankfurt) utilise eu-central-1. Si une exigence porte sur le pays, vérifie l’emplacement physique indiqué dans la documentation.

Les fournisseurs exploitent plusieurs dizaines de régions dans les Amériques, en Europe, en Asie-Pacifique, au Moyen-Orient et en Afrique. Leur présence continue de s’étendre. Pour choisir un emplacement, une carte actuelle de l’infrastructure est plus utile qu’un nombre de régions mémorisé.

Distinguer l’emplacement de la portée

La portée d’une ressource décrit la zone à laquelle elle appartient ou qu’elle peut servir.

La seule mention « régionale » indique peu de choses sur la protection contre les pannes. Une ressource régionale peut être accessible depuis plusieurs zones tout en dépendant d’une infrastructure située dans une seule. Vérifie son paramètre de redondance pour savoir si elle résiste à une panne de zone.

L’emplacement impose aussi de vérifier les flux de données. Une base de données peut fonctionner dans la région choisie tandis qu’une fonction de sauvegarde ou de réplication copie ses données ailleurs. Le stockage géoredondant Azure en est un exemple. Vérifie où vont les données principales, les sauvegardes et les répliques avant de considérer la région comme une limite complète de résidence des données.

Vérifier les offres de la région

Les listes de services et les prix varient selon la région. Vérifie que la fonctionnalité de base de données, la taille de machine et les options de résilience nécessaires sont disponibles. Il peut aussi être nécessaire d’activer l’accès pour un compte : les régions AWS introduites après le 20 mars 2019 sont désactivées par défaut et certaines régions Azure sont à accès restreint.

Supposons qu’une machine ait été créée dans eu-west-1, mais qu’une liste de ressources AWS affiche maintenant us-east-1. Une liste vide ne signifie pas que la machine a été supprimée. Passe à la région de création et vérifie le compte sélectionné et les filtres. Changer l’affichage laisse la machine en fonctionnement et les frais continuent de s’accumuler.

Une zone de disponibilité est un groupe isolé d’un ou plusieurs centres de données au sein d’une région. Son alimentation électrique, son refroidissement et son réseau sont indépendants de ceux des autres zones. AWS et Azure l’appellent zone de disponibilité ; Google Cloud l’appelle zone.

Comprendre les niveaux physiques

Un centre de données est un bâtiment qui contient des serveurs et les équipements nécessaires à leur fonctionnement. Une zone peut utiliser plusieurs bâtiments de ce type, et une région regroupe des zones. Considérer qu’une zone correspond exactement à un bâtiment donne une idée fausse des limites de propagation des pannes chez le fournisseur.

Les zones sont assez éloignées pour réduire leur exposition commune à un incendie local, un problème électrique ou une inondation, mais assez proches pour communiquer rapidement. AWS place ses zones à environ 100 km au maximum les unes des autres ; Azure indique que ses zones sont généralement distantes de 100 km au maximum et vise des communications aller-retour de moins d’environ 2 ms. Les liaisons rapides rendent possible la réplication synchrone : une écriture n’est confirmée qu’après le stockage des copies requises dans plusieurs zones.

Un événement régional de grande ampleur peut tout de même toucher plusieurs zones. Plusieurs zones protègent contre la panne d’une zone ; une deuxième région fournit un emplacement distinct pour la reprise après une panne régionale.

Lire les identifiants de zone

AWS ajoute une lettre au code de région, comme dans eu-central-1a. Google Cloud ajoute un trait d’union et une lettre, comme dans europe-west4-a. Azure utilise des numéros de zone logique comme 1, 2 et 3.

Des noms identiques chez différents clients peuvent induire en erreur. La zone 1 d’Azure peut correspondre à des zones physiques différentes selon les abonnements. AWS a établi une correspondance indépendante des noms dans ses régions les plus anciennes pour les comptes créés avant novembre 2025 ; les comptes plus récents utilisent une correspondance cohérente. Un identifiant de zone de disponibilité AWS, comme euc1-az1, désigne la même zone physique dans tous les comptes. Les équipes qui coordonnent le placement physique comparent les identifiants de zone de disponibilité ou les correspondances de zones physiques documentées.

AWS indique que chaque région possède au moins trois zones. De nombreuses régions Azure en ont trois, mais certaines n’en ont aucune. Les régions Google Cloud possèdent plusieurs zones. Vérifie à la fois la région choisie et la prise en charge des zones par le service.

Choisir la protection nécessaire

Azure Storage montre pourquoi le seul nombre de copies ne suffit pas. Le stockage localement redondant (LRS) conserve trois copies locales dans un centre de données. Le stockage redondant interzone (ZRS) répartit les copies entre trois zones. Le stockage géoredondant (GRS) ajoute une copie dans une deuxième région pour la reprise. Trois copies dans un bâtiment partagent toujours les risques liés à ce bâtiment ; une répartition sur trois zones supprime cette dépendance particulière.

Les fournisseurs échelonnent les mises à jour entre les zones pour limiter les effets d’une modification défectueuse. Les copies peuvent aussi entraîner des frais de transfert : en octobre 2026, AWS et Google Cloud facturent de nombreux transferts entre zones, tandis qu’Azure ne facture pas les transferts entre zones d’une même région. La tarification propre à chaque service reste importante pour comparer une architecture complète.

Un emplacement périphérique, ou point de présence (PoP), rapproche certains services des utilisateurs. Ces sites proposent des services de mise en cache et des points d’entrée réseau. Ils n’offrent pas le vaste catalogue de services de calcul et de bases de données d’une région. Les fournisseurs possèdent des centaines de sites périphériques, répartis plus largement que leurs régions.

Suivre une requête dans un CDN

Un réseau de diffusion de contenu (CDN) stocke des copies réutilisables près des lecteurs. Amazon CloudFront, Azure Front Door et Google Cloud CDN en sont des exemples.

1. Le routage envoie la requête vers un site périphérique adapté. CloudFront utilise une sélection fondée sur le DNS ; d’autres services utilisent l’anycast, où plusieurs sites annoncent la même adresse IP, ou une combinaison des deux.
2. Le site vérifie son cache, un espace de stockage de contenu réutilisable.
3. En cas de succès de cache, il renvoie une copie stockée utilisable. En cas de défaut de cache, il récupère l’objet à l’origine, le stockage ou le serveur qui fait autorité.
4. Le contenu admissible reste en cache pour les requêtes ultérieures, selon sa durée de vie (TTL) et les règles de mise en cache.

CloudFront utilise aussi des caches périphériques régionaux plus grands entre de nombreux sites périphériques et l’origine. Un objet évincé d’un petit cache peut encore y être disponible, ce qui évite un nouveau trajet vers l’origine.

Les images d’un site d’actualités proviennent de Francfort. Un lecteur à São Paulo se trouve à environ 9 800 km à vol d’oiseau. Même un aller-retour idéal dans la fibre prend environ 98 ms, et les trajets réels prennent plus de temps. Un défaut de cache nécessite toujours une récupération à l’origine. Les lecteurs suivants peuvent recevoir localement l’image en cache en quelques millisecondes.

Les images, vidéos, scripts, feuilles de style et téléchargements se prêtent bien à la mise en cache, car de nombreuses personnes demandent les mêmes octets. Un panier d’achat privé nécessite normalement une nouvelle réponse de l’origine. La périphérie peut aider à accélérer la connexion sans rendre toutes les réponses admissibles à la mise en cache. Les sites périphériques peuvent aussi répondre aux requêtes DNS, comme avec Route 53, ou faire entrer le trafic sur le réseau fédérateur d’un fournisseur, comme avec AWS Global Accelerator.

Distinguer les solutions d’infrastructure de proximité

Azure Arc ajoute une connexion de gestion : Azure Resource Manager peut gérer des serveurs et des clusters Kubernetes hors d’Azure, notamment sur site et dans d’autres clouds. Il ne transforme pas le bâtiment d’un client en région Azure.

Suivre les données en cache au-delà des frontières

Un CDN mondial peut stocker du contenu dans plusieurs pays. Une règle qui bloque les visiteurs étrangers contrôle l’accès du public ; elle ne détermine pas où les copies en cache sont conservées ni où le traitement a lieu. Un contenu soumis à une limite nationale stricte nécessite un CDN qui garantit les emplacements autorisés, ou un mode de diffusion qui évite sa mise en cache à l’étranger. Vérifie ce point indépendamment de la région de l’origine.

La haute disponibilité consiste à continuer de servir les utilisateurs lorsque des composants tombent en panne. Un point unique de défaillance est toute dépendance dont la perte arrête l’application. Deux serveurs web partagent toujours un point unique de défaillance s’ils dépendent tous deux d’une seule base de données non protégée.

Protéger tout le parcours d’une requête

Exécute les instances de l’application dans des zones différentes. Un répartiteur de charge contrôle leur état et envoie les requêtes aux instances opérationnelles. Protège aussi la couche de données avec une base de données redondante interzone ou une réplique de secours synchrone dans une autre zone, comme dans une configuration Amazon RDS Multi-AZ.

Dans la mesure du possible, garde les instances de l’application sans état. Stocke la session d’un utilisateur dans un service de données partagé et résilient, au lieu de la conserver uniquement dans la mémoire d’une instance. Une instance opérationnelle dans une autre zone peut alors répondre à la requête suivante sans que l’utilisateur perde son panier ou sa session.

Une machine virtuelle seule reste dans la zone choisie. Choisis plusieurs instances zonales ou une option de service qui assure la redondance de zone.

Convertir la disponibilité en durée d’indisponibilité

Une année de 365 jours compte 8 760 heures. Exprime la disponibilité sous forme décimale, soustrais-la de un et multiplie le résultat par la durée de la période :

À 99,9 %, la proportion d’indisponibilité est de 0,001, soit 8,76 heures par an. À 99,95 %, elle est de 4,38 heures. À 99,99 %, elle est d’environ 52,6 minutes. Ces conversions décrivent un pourcentage sur cette période ; un accord de service réel définit aussi la manière dont la disponibilité est mesurée.

Pour illustrer le cas idéal, supposons que chacune des deux zones puisse exécuter l’application complète, qu’elle soit disponible 99,9 % du temps et que leurs pannes soient indépendantes. La probabilité que les deux soient en panne est :

La disponibilité obtenue est de 99,9999 %, soit environ 32 secondes d’indisponibilité par an. Des défauts logiciels partagés, des erreurs de configuration et des dépendances régionales invalident l’hypothèse d’indépendance. Ce calcul explique l’avantage de la redondance ; il ne représente pas la disponibilité promise pour l’application.

Prévoir une capacité restante suffisante

Une boutique en ligne a besoin de six instances en période de pointe. Deux instances dans chacune des trois zones en fournissent normalement six, mais seulement quatre après la panne d’une zone. Pour en conserver six après la perte de n’importe quelle zone, chacune des deux zones restantes doit fournir trois instances. Déploie-en neuf au total.

Avec deux zones, chacune doit accueillir les six instances, ce qui porte le total à 12. De manière générale, pour un nombre égal d’instances dans chaque zone :

Ici, $N$ est la capacité nécessaire en période de pointe et $z$ le nombre de zones. Arrondis à l’entier supérieur, car une instance est une unité entière. Pour dix instances réparties sur quatre zones, dix divisé par trois s’arrondit à quatre par zone : 16 au total. La perte d’une zone en laisse 12, ce qui suffit. Ce plan suppose que la capacité requise fonctionne déjà ; attendre de nouvelles instances ajoute une dépendance pour la reprise.

Une deuxième région permet de reprendre l’activité après un sinistre régional. Elle peut aussi servir des utilisateurs éloignés, respecter des règles nationales sur l’emplacement des données ou fournir un service ou une capacité indisponible dans la première région. Chacune de ces raisons ajoute des exigences différentes à la conception.

Définir deux objectifs de reprise

L’objectif de point de reprise (RPO) est la perte maximale de données acceptable, exprimée en temps. L’objectif de temps de reprise (RTO) est le délai maximal acceptable pour rétablir le service. Une sauvegarde peut préserver des données récentes tout en prenant trop de temps à restaurer ; un redémarrage rapide peut malgré tout entraîner une perte de données trop importante.

Une entreprise copie sa sauvegarde nocturne à 01 h 00 et perd la région principale à 17 h 00. La copie disponible pour la reprise ne contient pas 16 heures de modifications. Elle ne respecte donc pas un RPO d’une heure. Il faut des sauvegardes achevées plus fréquentes ou une réplication continue ; une planification n’est utile que si les copies atteignent réellement le lieu de reprise à temps.

Adapter le niveau de préparation au temps de reprise

Maintenir davantage de ressources en fonctionnement coûte généralement plus cher et réduit le travail de reprise. La sauvegarde et restauration prend couramment plusieurs heures ou plus. Le mode actif-actif peut permettre une reprise en quelques secondes à quelques minutes, mais le résultat dépend de la conception de l’application complète.

Comprendre l’écart entre les données

Entre régions, la réplication est généralement asynchrone : une écriture est confirmée avant que la copie distante soit terminée. Francfort et la région de Washington, D.C., sont distantes d’environ 6 500 km : un aller-retour idéal dans la fibre prend donc à lui seul environ 65 ms. Attendre cet aller-retour à chaque écriture ajouterait un délai.

L’écart entre les données actuelles et la copie distante est le retard de réplication. Il peut augmenter en cas de forte charge ou de problèmes réseau. Surveille-le par rapport au RPO. Une deuxième région contenant une réplique ancienne assure une séparation géographique sans respecter l’objectif de perte de données.

Utiliser correctement les paires Azure

Azure associe de nombreuses régions par paires, comme North Europe avec West Europe et East US avec West US. Ces paires permettent d’échelonner les mises à jour de la plateforme, de définir des priorités de reprise et d’assurer la géoréplication de certains services. La plupart restent dans une même zone géographique. Brazil South fait exception : sa région associée est South Central US.

Une paire ne déploie pas de copie de l’application et n’organise pas toutes les étapes du basculement. De nombreuses régions Azure plus récentes n’ont pas de région associée, et un client peut choisir une autre région secondaire autorisée. Vérifie le fonctionnement de la réplication pour chaque service.

Le routage mondial peut diriger les utilisateurs vers les régions opérationnelles par l’intermédiaire de Route 53, d’Azure Front Door ou de la répartition de charge mondiale de Google Cloud. Prévois le coût des ressources dupliquées et des transferts interrégionaux, et teste tout le processus de reprise, y compris les quotas et les étapes manuelles. Si les données doivent rester dans un pays qui ne possède qu’une seule région, utilise les zones et les options de reprise locales de cette région ; une copie à l’étranger enfreindrait l’exigence d’emplacement.

La latence est le délai de transmission. Le temps aller-retour (RTT) mesure le temps nécessaire à une requête et à sa réponse, généralement en millisecondes. La bande passante mesure la quantité de données qu’une connexion transporte chaque seconde. Une bande passante plus large aide à transférer un gros fichier, mais ne peut pas supprimer le temps de trajet jusqu’à une région éloignée.

Estimer le minimum physique

La lumière parcourt environ 200 000 km/s dans la fibre. Chaque kilomètre ajoute environ 5 microsecondes à l’aller. Pour estimer un temps aller-retour minimal, double la distance pour l’aller et le retour, divise par cette vitesse, puis convertis les secondes en millisecondes :

Cela donne environ 1 ms par tranche de 100 km. Une distance à vol d’oiseau constitue une borne minimale : les câbles réels suivent des trajets plus longs, et les routeurs, les files d’attente et les traitements ajoutent un délai.

Pour les utilisateurs à Sydney, Singapour est à environ 6 300 km. En doublant, on obtient 12 600 km. La division par 200 000 donne 0,063 seconde, soit environ 63 ms. Le nord de la Virginie se trouve à environ 15 700 km, soit au moins environ 157 ms. Une région à Sydney peut réduire le temps de trajet à quelques millisecondes.

Compter les trajets répétés

Un délai peut sembler faible jusqu’à ce qu’une tâche le répète. Supposons que l’ouverture d’une connexion et l’obtention d’une première réponse nécessitent quatre allers-retours successifs. À 157 ms chacun, le temps de trajet représente 628 ms. À 5 ms chacun, il représente 20 ms. Le nombre exact d’allers-retours dépend de la réutilisation de la connexion et du fonctionnement du protocole ; compte ceux que la charge de travail effectue réellement.

Le même effet se produit entre les parties d’une application. Une page effectue 50 requêtes de base de données les unes après les autres. Si chaque requête distante ajoute 15 ms, la séquence ajoute 750 ms. À 1 ms dans la même région, elle ajoute 50 ms. Il s’agit des temps de communication des requêtes ; le travail de la base de données peut ajouter du temps. Placer ensemble les composants qui communiquent fréquemment évite de subir plusieurs fois le délai lié à la distance.

Choisir la modification adaptée

Un cache périphérique aide lorsqu’il peut répondre à la requête. Il ne peut pas rendre locale pour chaque utilisateur une transaction de base de données qui n’est pas en cache. De même, augmenter la bande passante ne change pas la distance jusqu’à l’origine.

Mesurer depuis les lieux réels des utilisateurs

Les trajets réseau suivent les connexions disponibles, les appairages et les conditions de trafic, pas la ligne la plus courte sur une carte. Compare les temps aller-retour mesurés ou les temps de réponse de l’application depuis les lieux où les utilisateurs se connectent réellement. Teste des horaires et des requêtes représentatifs avant de choisir une région. Une région proche est une bonne candidate ; les mesures déterminent si son trajet réel convient à la charge de travail.

Pour bien choisir une région, commence par la charge de travail : qui l’utilise, quels services lui sont nécessaires, où ses données peuvent aller et comment elle doit être restaurée. Comparer les régions sans tenir compte de ces exigences peut conduire à choisir un emplacement peu coûteux qui ne peut pas exécuter l’application.

Filtrer avant de noter

Six critères comptent généralement : la conformité et la résidence des données, la latence pour les utilisateurs, la disponibilité des services et des fonctionnalités, le prix, les options de résilience et le développement durable. Distingue les exigences impératives des préférences. Une restriction concernant le pays ou l’absence d’un service essentiel élimine une région. Un bon prix ne peut pas compenser le non-respect de cette exigence.

Pour les régions restantes, choisis une échelle de notation cohérente et des poids dont la somme est égale à 100 %. Une note plus élevée doit toujours indiquer une meilleure adéquation, y compris une meilleure note de prix pour un coût inférieur. Multiplie chaque note par son poids et additionne les résultats.

Étudier une décision

Une entreprise en Allemagne exige que les données soient stockées dans l’UE. Elle élimine une région américaine avant de comparer deux régions candidates autorisées. Les notes vont de 1 à 5, 5 étant la meilleure.

L’entreprise attribue un poids de 50 % à la latence, de 30 % au prix et de 20 % aux services :

B arrive légèrement en tête. Pour un écran de négociation, l’entreprise modifie les poids et leur attribue respectivement 70 %, 20 % et 10 % :

La recommandation change parce que la priorité de l’entreprise a changé. Indique les poids et les éléments qui justifient les notes afin qu’une autre personne puisse comprendre le choix. Un total qui paraît précis ne vaut que par la qualité des données utilisées.

Chiffrer l’ensemble de la solution

Les prix du calcul varient d’une région à l’autre selon l’énergie, le foncier, la demande et d’autres coûts locaux. Inclus dans la comparaison le stockage, les sauvegardes, la capacité dans une deuxième région et les transferts de données. Les transferts entre régions et vers Internet sont couramment facturés ; les données entrantes sont généralement gratuites. Placer dans différentes régions des parties d’application qui échangent beaucoup de données peut annuler une petite économie sur le prix du calcul.

Pour évaluer la résilience, vérifie la prise en charge des zones et l’existence d’un lieu de reprise autorisé. Pour le développement durable, examine l’électricité utilisée dans la région ; les fournisseurs publient des indicateurs comme la part d’énergie décarbonée par région Google Cloud. Une électricité moins carbonée peut réduire l’empreinte d’une même charge de travail.

Enfin, teste les régions en tête avec des mesures réelles de latence et le calculateur de prix du fournisseur. Consigne l’emplacement choisi, les exigences impératives, les poids et les raisons du choix. La migration des ressources et des données stockées demande du travail : réexamine donc le choix lorsque les lieux où se trouvent les utilisateurs, les lois, les services ou la présence régionale du fournisseur changent.

La résidence des données décrit les lieux où les données sont stockées et traitées. La localisation des données est une exigence légale imposant de conserver certaines données dans un pays. La souveraineté des données concerne les lois et les autorités qui peuvent régir les données, notamment par l’intermédiaire de l’entreprise qui les détient. Le stockage local et le contrôle juridique sont liés, mais répondent à des questions différentes.

Suivre les données au-delà de la base

Une base de données dans la région Azure germanywestcentral place son stockage principal en Allemagne. Examine aussi les sauvegardes, les répliques, les journaux, les accès du support, les services mondiaux de gestion des identités et les caches des CDN. Chacun peut introduire un autre emplacement. L’EU Data Boundary de Microsoft, achevé en février 2025, ajoute des engagements de stockage et de traitement dans l’UE et l’AELE pour les services et données concernés, avec un périmètre et des exceptions documentés.

Un examen efficace cherche à savoir où va chaque copie et quelle organisation peut obtenir un accès. Des politiques peuvent limiter les emplacements des ressources ; les clés de chiffrement contrôlées par le client et les contrôles d’accès du support répondent à d’autres aspects du problème. Un seul contrôle ne peut pas répondre à toutes les questions.

Appliquer le cadre de transfert du RGPD

Le règlement général sur la protection des données (RGPD) s’applique aux traitements entrant dans son champ d’application territorial. Cela inclut les établissements situés dans l’EEE et certaines organisations à l’étranger qui proposent des biens ou des services à des personnes dans l’UE ou suivent leur comportement. L’EEE comprend l’UE, l’Islande, le Liechtenstein et la Norvège. Le RGPD autorise le stockage à l’étranger lorsque les conditions applicables sont remplies ; il n’impose pas de règle générale de stockage limité à l’EEE.

Pour un transfert vers un destinataire distinct situé hors de l’EEE, le chapitre V prévoit les voies suivantes :

Le Japon, le Royaume-Uni et la Suisse sont des exemples de destinations bénéficiant d’une décision d’adéquation. Le cadre de protection des données UE–États-Unis (DPF), adopté le 10 juillet 2023, couvre les organisations américaines participantes et certifiées. Il a remplacé l’ancien mécanisme Privacy Shield, invalidé dans l’arrêt Schrems II le 16 juillet 2020. Le Tribunal de l’Union européenne a rejeté un recours contre le DPF en septembre 2025 ; un pourvoi était en cours en octobre 2026. Une décision de transfert nécessite de vérifier le statut actuel du cadre et la certification du destinataire.

Distinguer l’accès du stockage

Mettre des données détenues dans l’EEE à la disposition d’une organisation de support distincte située hors de l’EEE peut constituer un transfert, même si la base de données reste sur place. Le Comité européen de la protection des données distingue ce cas de celui d’un salarié du même responsable du traitement qui accède aux données depuis l’étranger ; ce dernier cas n’est pas un transfert vers un autre destinataire au sens du chapitre V. Le traitement nécessite malgré tout une protection appropriée.

Le CLOUD Act américain de 2018 peut obliger, selon les procédures légales applicables, les fournisseurs soumis à la juridiction américaine à produire les données en leur possession, sous leur garde ou sous leur contrôle, y compris celles stockées à l’étranger. L’adresse d’un serveur ne suffit donc pas à elle seule à régler la question de la souveraineté.

Une clinique néerlandaise qui utilise un fournisseur établi aux États-Unis choisit une région de l’UE, recense les destinataires et les flux de support à l’étranger, vérifie la voie applicable du DPF ou des clauses contractuelles types, et gère les clés de chiffrement ainsi que les politiques relatives aux emplacements autorisés. Elle documente ces choix avec ses autres obligations de protection des données. D’autres pays et contrats ajoutent leurs propres restrictions, en particulier pour les dossiers médicaux, financiers et administratifs.

Un cloud souverain ajoute des contrôles sur les données, les opérations et la dépendance aux systèmes mondiaux afin de répondre aux exigences d’une juridiction. Une région ordinaire dans le bon pays offre un choix d’emplacement. Une offre souveraine peut aussi changer qui exploite le service et dans quelle mesure il peut fonctionner indépendamment.

Poser trois questions différentes

La souveraineté des données concerne le lieu où les données sont détenues et les personnes qui contrôlent les accès et les clés de chiffrement. La souveraineté opérationnelle concerne les personnes qui administrent le service et en assurent le support, ainsi que leur lieu de travail. La souveraineté technique concerne la capacité de l’environnement à fonctionner sans les systèmes mondiaux du fournisseur. Évalue chaque dimension selon l’exigence juridique, contractuelle ou de sécurité réelle.

Comparer des environnements distincts

Les environnements gouvernementaux prennent en charge des programmes comme FedRAMP, avec une couverture propre à chaque service et des responsabilités pour le client. Les environnements chinois sont séparés des services mondiaux et nécessitent les comptes et les points de terminaison appropriés. Des partitions cloud distinctes possèdent leurs propres limites d’identité et d’API ; une connexion au cloud mondial ne donne pas automatiquement accès à leurs ressources.

Identifier le niveau de l’offre européenne

En octobre 2026, AWS European Sovereign Cloud est disponible ; sa première région a été lancée dans le Brandebourg, en Allemagne, en janvier 2026. Il est séparé physiquement et logiquement des autres régions AWS et exploité depuis l’UE par des résidents de l’UE au sein de sociétés immatriculées en Allemagne.

Microsoft Sovereign Cloud comprend des contrôles Sovereign Public Cloud dans les régions publiques, Sovereign Private Cloud utilisant Azure Local sur le site du client, et des clouds nationaux exploités par des partenaires comme Bleu en France et Delos Cloud en Allemagne. Ces choix proposent des modalités d’exploitation différentes.

La gamme Google Cloud comprend les contrôles Data Boundary dans le cloud public, les offres Dedicated sur une infrastructure distincte exploitée par un partenaire et les environnements Air-Gapped fondés sur Google Distributed Cloud qui fonctionnent sans connexion à Google ni à Internet. S3NS en France et l’offre de Thales en Allemagne illustrent l’approche par partenaire local. Les noms des produits ne suffisent pas à établir les services, les emplacements ou les engagements d’indépendance prévus par un contrat.

Choisir des contrôles suffisants sans perdre les capacités nécessaires

Un commerçant peut répondre à ses exigences avec une région ordinaire de l’UE, des garanties de transfert et des clés gérées par le client. Un organisme soumis à une exigence de qualification nationale vérifie si une offre précise d’un partenaire ou une offre souveraine possède cette qualification pour les services nécessaires. Des travaux classifiés hors ligne peuvent nécessiter un environnement isolé physiquement.

Une isolation plus stricte peut réduire le choix des services, retarder l’arrivée de nouvelles fonctionnalités, augmenter le coût et laisser moins de régions de reprise. Compare le catalogue de services réel, les conditions d’accès, les engagements d’exploitation et les lieux de reprise autorisés. La seule mention « souverain » ne garantit pas une protection contre toutes les lois étrangères.

Les fournisseurs placent les ressources des services déployés dans des conteneurs de gestion. Ces conteneurs séparent les coûts, les accès et les limites de service. Leurs noms diffèrent : un compte AWS, un abonnement Azure et un projet Google Cloud jouent des rôles globalement comparables.

Distinguer un conteneur d’une personne

Une personne peut accéder à plusieurs conteneurs et un conteneur peut servir de nombreuses personnes. Partager un accès ne place pas une ressource dans un deuxième conteneur. Par exemple, autoriser un analyste à interroger un jeu de données dans un autre projet laisse ce jeu de données rattaché à son projet d’origine.

Un compte AWS possède un identifiant à 12 chiffres. Son utilisateur racine est associé à l’adresse e-mail de création du compte et dispose de privilèges exceptionnels. Protège-le par une authentification multifacteur et réserve-le aux tâches qui nécessitent l’utilisateur racine. Le travail quotidien utilise normalement des rôles et d’autres identités autorisées. Un identifiant de compte désigne une limite pour les ressources, pas un salarié nommé.

Comprendre le lien avec l’annuaire Azure

Un locataire Microsoft Entra est l’annuaire des identités d’une organisation. Un abonnement délimite la gestion et la facturation des ressources et fait confiance à un seul locataire. Un locataire peut prendre en charge de nombreux abonnements. Une personne connectée peut avoir des permissions dans certains d’entre eux et aucune dans d’autres.

L’expression « compte Azure » peut désigner une identité de connexion ou une organisation de la facturation ; elle est donc trop vague pour parler de l’appartenance d’une machine virtuelle. Identifie séparément l’abonnement et le locataire.

Lire les identifiants de projet Google Cloud

Un projet possède un nom affiché, un identifiant de projet permanent et un numéro de projet attribué par le fournisseur. Le nom peut changer et n’a pas besoin d’être unique. L’identifiant est unique au monde et ne peut pas changer après la création. Il comporte de 6 à 30 lettres minuscules, chiffres ou traits d’union, commence par une lettre et ne peut pas se terminer par un trait d’union. Par exemple, lumen-shop-prod est un identifiant de projet, tandis que « Lumen Shop Production » peut être son nom affiché.

Les projets organisent les services déployés, tandis que les ressources organisation et dossier organisent les projets au niveau supérieur. La facturation est associée séparément : plusieurs projets peuvent donc partager un compte de facturation sans devenir un seul projet.

Répartir le travail selon des limites utiles

Une entreprise sépare sa boutique en environnements de développement, de test et de production. Elle utilise trois comptes AWS, trois abonnements Azure ou trois projets Google Cloud. Chaque environnement dispose de sa propre étendue de permissions et d’une vue distincte des coûts. La séparation limite les dommages qu’une erreur de développement peut causer lorsque les permissions sont configurées en conséquence.

Les conteneurs comportent aussi des quotas, comme des limites régionales de processeurs virtuels. Les nouveaux conteneurs peuvent commencer avec des quotas bas, et beaucoup de limites peuvent être augmentées sur demande. Un environnement de reprise doit disposer d’un quota suffisant avant qu’une panne ne se produise ; un modèle fonctionnel ne réserve pas à lui seul de capacité et n’augmente pas ces limites.

Les équipes répartissent généralement les conteneurs par environnement, service ou produit afin de garder les coûts et les accès compréhensibles. Le placement géographique est un choix distinct : un conteneur peut contenir des ressources dans plusieurs régions.

Les ressources créées, modifiées et supprimées ensemble partagent un cycle de vie. Les groupes de ressources Azure font de ce cycle de vie une limite de gestion. Les balises et les libellés ajoutent aux ressources des descriptions qui facilitent la recherche sans modifier leur emplacement physique.

Utiliser les groupes de ressources Azure

Pour les ressources ordinaires des services Azure déployés, un groupe de ressources se trouve dans un abonnement. Chaque ressource de ce type appartient à un groupe ; les groupes ne peuvent pas contenir d’autres groupes. Les ressources et objets de gestion au niveau de l’abonnement existent à des niveaux supérieurs : la hiérarchie comporte donc aussi des objets extérieurs aux groupes de ressources.

Un groupe possède un emplacement pour ses métadonnées, les informations qui décrivent le groupe et ses ressources. Cet emplacement n’impose pas à chaque ressource du groupe de se trouver dans la même région. Un serveur web dans une région et sa ressource de reprise dans une autre peuvent partager un groupe.

Supprimer un groupe de ressources supprime son contenu. C’est pratique pour un travail temporaire et dangereux si des ressources de production sans lien avec celui-ci y sont incluses. Un verrou de suppression peut empêcher une suppression accidentelle jusqu’à ce qu’une personne autorisée le retire. Choisis un groupe dont les membres peuvent sans risque partager les décisions de création, d’accès et de mise hors service.

Par exemple, cette commande de l’interface en ligne de commande Azure crée un groupe pour la boutique en production :

az group create --name rg-shop-prod-weu --location westeurope

Un groupe distinct rg-shop-test contient un environnement de test temporaire. La suppression de ce groupe de test supprime son contenu en une fois. Le groupe de production reste distinct. La structure du nom indique le type de ressource, l’application, l’environnement et l’emplacement, ce qui facilite la lecture rapide des listes.

Un accès attribué à un groupe, comme Reader, s’applique à ses ressources. De nombreux types de ressources peuvent être déplacés entre groupes ou abonnements, sous réserve des restrictions du service. Un tel déplacement change leur place dans l’organisation de gestion ; il ne migre pas une ressource vers une autre région.

Comparer le regroupement dans AWS

AWS Resource Groups peut rassembler des ressources à partir de balises correspondantes ou d’une pile CloudFormation. Une ressource peut apparaître dans plusieurs de ces groupes. La suppression d’un groupe AWS Resource Group supprime le regroupement, mais laisse ses ressources. Cela diffère du conteneur de cycle de vie qu’Azure impose aux ressources ordinaires déployées. Dans Google Cloud, les projets constituent la principale limite de regroupement des ressources de service.

Ajouter des balises et des libellés utiles

Les balises dans AWS et Azure et les libellés dans Google Cloud associent des descriptions sous forme de paires clé-valeur. Par exemple : environment=prod, cost-center=4120 et owner=web-team. Ils aident à filtrer les inventaires et les rapports de coûts ou à sélectionner des ressources pour l’automatisation.

Utilise des clés et des valeurs convenues. Si une équipe écrit « prod » et une autre « Prod », un rapport peut séparer des ressources qui vont ensemble. Les balises d’un groupe de ressources Azure ne sont pas transmises par défaut aux ressources du groupe ; une stratégie ou une automatisation peut appliquer les valeurs voulues.

Une balise est une métadonnée descriptive. Un libellé indiquant « privé » n’isole pas le trafic réseau, et nommer un groupe « Europe » n’y déplace pas ses ressources. Ces contrôles sont assurés par les règles d’accès, les réseaux et les paramètres de région.

Une hiérarchie de gestion organise les conteneurs en arborescence. Les étendues parentes permettent à une organisation de gérer ensemble de nombreux comptes, abonnements ou projets. L’héritage signifie que les paramètres applicables d’un parent sont transmis à ses descendants.

Comparer les arborescences des fournisseurs

Azure attribue à chaque locataire un groupe d’administration racine, appelé par défaut « Tenant root group ». Les groupes d’administration peuvent être imbriqués sur six niveaux, sans compter la racine et le niveau des abonnements. Chaque groupe d’administration ou abonnement possède un parent.

AWS Organizations possède un compte de gestion qui crée l’organisation et paie les factures consolidées. Les unités d’organisation regroupent les comptes et peuvent être imbriquées sur cinq niveaux sous la racine. Un compte appartient à une seule organisation à la fois. Le compte de gestion joue un rôle distinct et n’est pas soumis aux politiques de contrôle des services de l’organisation.

L’organisation Google Cloud est associée au domaine de l’entreprise. Les dossiers nécessitent une organisation et peuvent contenir des dossiers imbriqués. Une personne utilisant un essai gratuit peut posséder un projet sans organisation.

Suivre une règle héritée

Une entreprise sépare le Commerce de détail et la Logistique, chacun avec un environnement de production et un environnement de développement. Azure utilise des groupes d’administration par service, sous lesquels se trouvent des abonnements. AWS utilise des unités d’organisation par service, sous lesquelles se trouvent des comptes. Google Cloud utilise des dossiers par service, sous lesquels se trouvent des projets.

Si une stratégie de groupe d’administration Azure autorise les déploiements uniquement dans les régions de l’UE, les abonnements situés en dessous héritent de cette restriction. Le nom du groupe est une simple désignation ; c’est la stratégie qui impose la règle d’emplacement. Dans AWS, une politique de contrôle des services (SCP) d’une unité d’organisation peut fixer une limite maximale de permissions pour les comptes membres. Une SCP n’accorde pas elle-même à un utilisateur la permission de travailler dans ces comptes.

Comprendre les accès hérités

Dans le contrôle d’accès fondé sur les rôles d’Azure et les politiques d’autorisation IAM de Google Cloud, les accès accordés se cumulent entre les niveaux. Un accès en lecture seule accordé à un enfant n’annule pas un accès en écriture hérité d’un parent. Pour retirer cet accès étendu, modifie le niveau auquel il est accordé ou utilise un contrôle de refus approprié.

Azure Policy peut rejeter des configurations de ressources non conformes, comme un emplacement interdit. Elle est distincte des affectations de rôles qui accordent les accès. Les politiques de refus Google Cloud peuvent bloquer des permissions précises. Les politiques AWS Organizations diffèrent elles aussi des accès accordés aux comptes ; IAM Identity Center peut attribuer des ensembles de permissions à plusieurs comptes.

Une équipe d’audit qui dispose d’un accès en lecture approprié au sommet d’une hiérarchie Azure ou Google Cloud peut lire les ressources des services situés en dessous. Dans AWS, l’appartenance à une unité d’organisation ne donne pas à elle seule à cette équipe l’accès aux comptes.

Distinguer l’arborescence de la carte

Déplacer un abonnement ou un projet modifie les politiques et les accès dont il hérite. Les ressources restent dans leurs régions actuelles. Examine les règles effectives de la nouvelle branche avant un déplacement : une réorganisation logique peut affecter les permissions de nombreuses personnes sans déplacer un seul serveur.

Un bouton dans un navigateur, une commande et un programme peuvent tous demander la même opération cloud. Chacun envoie une requête authentifiée à une interface de programmation d’application (API). L’interface change la manière dont une personne ou une application travaille ; les permissions et les limites de service continuent de s’appliquer.

Adapter l’interface à la tâche

Les outils graphiques sont l’AWS Management Console, le portail Azure et la console Google Cloud. Les principaux programmes en ligne de commande sont aws, az et gcloud. Azure PowerShell et AWS Tools for PowerShell proposent un autre style de commande. Les applications mobiles sont utiles pour vérifier l’état et les alertes.

Par exemple, aws ec2 describe-instances --region eu-central-1 liste les instances EC2 à Francfort. az group list liste les groupes de ressources Azure et gcloud compute zones list liste les zones Google Cloud. Ce sont des clients d’API, pas des inventaires de ressources distincts.

AWS CloudShell, Azure Cloud Shell et Google Cloud Shell fournissent l’interface en ligne de commande correspondante dans un navigateur. Ils réduisent le travail d’installation et utilisent le contexte cloud de la session ouverte. Tu dois tout de même vérifier le compte, l’abonnement ou le projet ciblé par la session.

Suivre le bon chemin vers l’API

Dans Azure, les opérations du plan de contrôle créent, modifient ou suppriment des ressources par l’intermédiaire d’Azure Resource Manager. Celui-ci applique les autorisations et les stratégies aux requêtes de gestion des ressources. Les opérations du plan de données utilisent le point de terminaison propre au service, par exemple pour charger un fichier dans un compte de stockage existant. Un programme peut effectuer les deux types d’opérations à l’aide de clients différents.

Les SDK prennent en charge des langages comme Python, JavaScript, Java, C# et Go. Ils facilitent la signature des requêtes, les appels de services et les nouvelles tentatives après des pannes temporaires. Une application web utilise un SDK lorsque chaque fichier chargé par un utilisateur doit déclencher une opération de stockage ; elle n’a pas besoin qu’une personne utilise la console.

Vérifier le contexte cible

Les valeurs par défaut peuvent sélectionner la mauvaise destination sans avertissement. La configuration AWS peut définir une région par défaut. La configuration Google Cloud peut sélectionner un projet et une région de calcul, par exemple avec gcloud config set project lumen-shop-prod et gcloud config set compute/region europe-west4.

Azure utilise un abonnement sélectionné, tandis que les commandes de création de ressources utilisent leurs paramètres d’emplacement ou leurs valeurs par défaut documentés. L’emplacement des métadonnées d’un groupe de ressources ne détermine pas systématiquement l’emplacement de chacune de ses ressources. Vérifie la destination de la commande avant de l’exécuter.

Utilise des informations d’identification de courte durée, comme des rôles ou des sessions ouvertes, lorsqu’elles sont disponibles. Ne place pas de clés d’accès dans le code source ni dans des documents partagés. Passer de la console à une interface en ligne de commande ne contourne pas les contrôles d’accès : une opération d’API refusée le reste quel que soit le client qui l’envoie.

Créer manuellement une ressource temporaire peut être pratique. Reconstruire le même environnement pour les tests, la production et la reprise exige un processus qui évite les petites différences dues à la répétition des clics. L’infrastructure en tant que code (IaC) stocke la description des ressources dans des fichiers texte et utilise un outil de déploiement pour créer ou mettre à jour l’environnement.

Décrire un état ou une séquence

Un modèle déclaratif indique ce qui doit exister, par exemple deux machines virtuelles d’une taille donnée dans un emplacement choisi. L’outil de déploiement compare cet état souhaité à l’environnement actuel et détermine les modifications à apporter. Un script impératif énumère les actions dans l’ordre, par exemple « créer le groupe, puis créer les machines ».

Une pile regroupe les ressources gérées par un déploiement CloudFormation. Les valeurs des paramètres permettent à une équipe de réutiliser un modèle pour différents emplacements ou tailles sans maintenir plusieurs copies du fichier.

Réutiliser un environnement testé

Une équipe possède un modèle de boutique en ligne testé à Francfort, eu-central-1. Pour préparer son infrastructure de reprise en Irlande, elle fournit eu-west-1 comme paramètre de région. Pour les tests, elle fournit une taille de machine plus petite. La gestion de versions conserve le modèle et ses modifications examinées, ce qui rend la configuration prévue visible pour l’équipe.

Réutiliser le code d’infrastructure ne copie pas les données actives de l’application. Les sauvegardes ou la réplication fournissent toujours ces données, et la région de reprise choisie doit toujours disposer des services, permissions et quotas nécessaires et respecter les exigences juridiques. Les modèles rendent reproductible la construction d’une infrastructure cohérente ; le plan de reprise complet comprend ces autres dépendances.

Appliquer les modifications de façon cohérente

Une opération idempotente peut être répétée sans ajouter de modification une fois son résultat visé atteint. Si la configuration, les paramètres et les ressources restent inchangés, un déploiement déclaratif qui a atteint l’état souhaité ne devrait plus modifier l’infrastructure. Un script composé uniquement de commandes de création peut échouer ou créer des doublons lorsqu’il est exécuté à nouveau.

La dérive de configuration est un écart entre la configuration déclarée et les ressources en fonctionnement. Une personne peut par exemple augmenter la taille d’une machine dans la console sans mettre à jour son modèle. La détection de dérive de CloudFormation ou un terraform plan peut aider à identifier ces différences. Un plan Terraform affiche les modifications proposées ; examine-les avant de les appliquer.

L’infrastructure en tant que code permet d’examiner les modifications, conserve leur historique et aide à reconstruire les environnements perdus. Elle exige aussi de maintenir les fichiers et de comprendre l’outil. Utilise l’interface manuelle pour une exploration ponctuelle, puis inscris dans le code les modifications stables et répétées de l’environnement afin que la description examinée reste exacte.