Où vont physiquement vivre vos applications quand vous cliquez sur « Deploy » ? Cette question apparemment triviale détermine la latence vue par vos utilisateurs, la résilience face aux pannes, la conformité réglementaire vis-à-vis du RGPD, et la facture mensuelle. Tous les fournisseurs cloud structurent leur infrastructure sur deux niveaux géographiques — la région et la zone de disponibilité (AZ) — dont le vocabulaire varie mais le concept est universel. Cette page pose les définitions, donne les critères de choix d'une région, explique comment architecturer en multi-AZ, traite le cas spécifique des régions souveraines européennes et défend une opinion claire sur le défaut 2026.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- La différence entre région et zone de disponibilité, avec la terminologie de chaque fournisseur
- Les 4 critères de choix d'une région : latence, conformité, services, coûts
- Comment architecturer en multi-AZ pour la haute disponibilité
- Le cas spécifique des régions souveraines (SecNumCloud, EUCS, sovereign clouds)
- Les pièges classiques des choix géographiques cloud
Prérequis : connaître les bases du cloud. Si besoin, démarrez par Définition et promesses du cloud.
1. Pourquoi la géographie compte dans le cloud
Section intitulée « 1. Pourquoi la géographie compte dans le cloud »Quand vous utilisez le cloud, vos applications tournent sur des serveurs physiques bien réels, situés dans des datacenters quelque part dans le monde. Ce « quelque part » a quatre conséquences directes que le marketing fournisseur tend à minimiser.
La latence réseau est incompressible. Un utilisateur à Paris qui accède à un serveur en Virginie subit ~80 ms de latence réseau, et ce chiffre ne baissera pas — c'est la vitesse de la lumière dans la fibre, pas un défaut de configuration. Cette latence est perceptible sur les applications interactives et critique sur les jeux en ligne ou la vidéo bas-latence.
Les pannes sont géographiquement corrélées. Une coupure électrique, un incendie de datacenter, un attentat terroriste, une catastrophe naturelle peuvent affecter simultanément tous les serveurs d'une même zone physique. La résilience exige une distribution géographique que le cloud rend possible mais que vous devez configurer explicitement.
Les lois sur les données suivent la frontière. Les données stockées en Virginie sont soumises au CLOUD Act américain. Les données stockées à Francfort sont soumises au RGPD européen. Cette différence juridique est aussi structurante que la différence technique, et elle est traitée en détail dans Souveraineté technologique de la stack.
Les coûts varient selon la géographie. Les régions ne sont pas facturées au même prix : Sao Paulo coûte typiquement 30 % plus cher qu'Ohio chez AWS, le Japon plus cher que l'Europe. Et le transfert de données entre régions s'ajoute à la facture, comme on l'a vu dans Egress et data transfer economics.
Tous les fournisseurs ont donc structuré leur infrastructure en deux niveaux géographiques pour vous permettre de faire des choix éclairés : les régions et les zones de disponibilité.
2. La hiérarchie universelle : région → zone de disponibilité
Section intitulée « 2. La hiérarchie universelle : région → zone de disponibilité »Imaginez le cloud comme une chaîne de supermarchés. La région est un pays où la chaîne est implantée (France, États-Unis, Japon). La zone de disponibilité (AZ) est un magasin dans ce pays (Paris Nord, Paris Sud). Chaque niveau offre un compromis différent entre isolation (protection contre les pannes) et proximité (performance et coûts).
| Niveau | Ce que c'est | Isolation | Latence interne | Cas d'usage |
|---|---|---|---|---|
| Région | Zone géographique large (pays / continent) | Maximale (datacenters séparés de centaines de km) | 50–150 ms entre régions | Conformité, DR, présence mondiale |
| Zone de disponibilité | Datacenter(s) isolé(s) dans une région | Forte (alimentation, réseau, refroidissement séparés) | < 2 ms entre AZ | Haute disponibilité, multi-AZ |
La terminologie varie selon les fournisseurs
Section intitulée « La terminologie varie selon les fournisseurs »Le concept est universel mais chaque fournisseur a son vocabulaire propre. Ce tableau évite les confusions classiques quand vous lisez une documentation multi-cloud.
| Concept | AWS | Azure | GCP | Outscale | OVHcloud |
|---|---|---|---|---|---|
| Région | Region | Region | Region | Region | Region |
| Zone de disponibilité | Availability Zone (AZ) | Availability Zone | Zone | Subregion (sous-région) | Availability Zone |
| Code région France | eu-west-3 (Paris) | francecentral | europe-west9 | eu-west-2 | gra (Gravelines) |
L'expression « sous-région » d'Outscale et l'expression « Availability Zone » d'AWS désignent exactement le même concept technique : un datacenter ou groupe de datacenters isolé au sein d'une région. Dans la suite de cette page, j'utilise indifféremment les deux termes selon le fournisseur cité, en privilégiant AZ comme terme générique.
3. Comment choisir sa région principale
Section intitulée « 3. Comment choisir sa région principale »Le choix de votre région principale repose sur quatre critères à pondérer selon votre contexte. C'est rarement un seul qui décide — les vrais arbitrages se font en pesant plusieurs facteurs simultanément.
-
La proximité de vos utilisateurs (latence)
C'est souvent le critère n°1. Chaque milliseconde compte pour l'expérience utilisateur sur une application interactive.
Distance serveur ↔ utilisateur Latence typique Impact perçu Même pays / agglomération 10–30 ms Imperceptible Même continent 30–80 ms Léger délai Intercontinental 100–300 ms Notable, gêne sur les apps temps réel Pour des utilisateurs majoritairement français, privilégier une région française (
eu-west-3AWS,francecentralAzure,europe-west9GCP,eu-west-2Outscale,graourbxOVHcloud) selon votre fournisseur. Pour des utilisateurs européens dispersés, une région centrale (Francfort, Paris, Dublin) couvre raisonnablement. -
Les contraintes légales et réglementaires
Certaines données doivent rester dans certains périmètres juridiques :
- RGPD (UE) : les données personnelles des Européens doivent être traitées selon les règles européennes, ce qui implique typiquement de privilégier les régions UE.
- Données gouvernementales françaises : doctrine « Cloud au centre » impose un fournisseur SecNumCloud (Outscale, OVHcloud, Cloud Temple, Cegedim, Worldline, Orange Business).
- Données de santé : conformité HDS (Hébergement de Données de Santé) à vérifier selon le fournisseur et la région.
-
La disponibilité des services
Toutes les régions ne proposent pas tous les services. Les fournisseurs déploient typiquement les nouveaux services dans 1 ou 2 régions phares, puis les étendent progressivement. Une région récente ou périphérique peut manquer du service que vous comptiez utiliser.
Vérifiez systématiquement avant de vous engager sur une région : AWS Regional Services Page, Azure Products by Region, GCP Locations, ou la documentation officielle du fournisseur souverain choisi.
-
Les coûts
Les prix varient sensiblement entre régions en fonction des coûts d'infrastructure locaux (énergie, immobilier, salaires). Une bonne pratique consiste à comparer 2 ou 3 régions candidates sur les 5 services principaux que vous comptez utiliser, avant de figer votre choix.
Le différentiel typique entre la région la moins chère et la plus chère d'un fournisseur tourne autour de 20 à 40 % sur le compute, parfois plus sur le stockage objet. Et le tarif egress varie d'un facteur 10 entre hyperscalers américains et fournisseurs souverains européens, comme détaillé dans Egress et data transfer economics.
4. Les régions disponibles par fournisseur en 2026
Section intitulée « 4. Les régions disponibles par fournisseur en 2026 »Vue d'ensemble des régions principales utiles pour un projet francophone ou européen. La liste complète vit dans la documentation officielle de chaque fournisseur — ce tableau couvre les choix typiques.
| Fournisseur | Régions UE principales | Particularité |
|---|---|---|
| AWS | eu-west-1 Dublin, eu-west-3 Paris, eu-central-1 Francfort | Soumis au CLOUD Act |
| Azure | francecentral Paris, westeurope Amsterdam, northeurope Dublin | Soumis au CLOUD Act |
| GCP | europe-west9 Paris, europe-west1 Saint-Ghislain, europe-west3 Francfort | Soumis au CLOUD Act |
| Outscale | eu-west-2 Île-de-France, cloudgouv-eu-west-1 Île-de-France SecNumCloud | Sovereign cloud français, SecNumCloud |
| OVHcloud | gra Gravelines, rbx Roubaix, sbg Strasbourg | Sovereign cloud français, SecNumCloud sur certains environnements |
| Scaleway | fr-par Paris, nl-ams Amsterdam, pl-waw Varsovie | Sovereign cloud français |
| Cloud Temple | Île-de-France | Sovereign cloud SecNumCloud |
| OVH Public Cloud SecNumCloud | Environnements dédiés | Qualification ANSSI 3.2 |
5. Les zones de disponibilité, clé de la haute disponibilité
Section intitulée « 5. Les zones de disponibilité, clé de la haute disponibilité »Une zone de disponibilité (AZ, ou sous-région chez Outscale) est un ou plusieurs datacenters physiquement séparés au sein d'une même région, mais reliés par un réseau à très faible latence (typiquement < 2 ms entre AZ d'une même région).
L'objectif est simple : survivre aux pannes locales sans sacrifier la performance. Imaginez une région sans AZ, où tous les serveurs sont dans le même datacenter. Une panne (incendie, inondation, coupure électrique majeure) tombe l'ensemble simultanément. Avec plusieurs AZ, chaque zone dispose de :
- Une alimentation électrique indépendante.
- Une connexion réseau séparée vers Internet et entre datacenters.
- Un système de refroidissement distinct.
- Une séparation physique de plusieurs kilomètres, parfois jusqu'à 100 km, pour éviter qu'une catastrophe locale n'affecte plusieurs zones simultanément.
Comment fonctionnent les AZ techniquement
Section intitulée « Comment fonctionnent les AZ techniquement »Les zones de disponibilité d'une même région sont conçues pour offrir le meilleur des deux mondes : isolation contre les pannes, performance quasi-identique à un déploiement sur une seule zone.
| Caractéristique | Valeur typique | Bénéfice |
|---|---|---|
| Distance entre AZ | 10–100 km | Protection contre catastrophes locales |
| Latence inter-AZ | 1–2 ms | Performance quasi-identique |
| Bande passante inter-AZ | Très haute (10+ Gbps) | Réplication temps réel possible |
| Isolation électrique | Totale | Une panne n'affecte qu'une AZ |
| Isolation réseau | Totale | Problème de routage isolé |
Architecture mono-AZ vs multi-AZ : la différence de résilience
Section intitulée « Architecture mono-AZ vs multi-AZ : la différence de résilience »| Scénario | Mono-AZ | Multi (2 AZ) | Multi (3 AZ) |
|---|---|---|---|
| Panne d'une AZ | Indisponibilité totale | 50 % de capacité restante | 66 % de capacité restante |
| Disponibilité théorique | 99,9 % | 99,99 % | 99,999 % |
| Indisponibilité annuelle | ~8h45 | ~52 min | ~5 min |
6. Concevoir une architecture multi-AZ
Section intitulée « 6. Concevoir une architecture multi-AZ »Voici les composants typiques d'une architecture multi-AZ résiliente, avec la terminologie standard et les noms par fournisseur. Ces étapes sont applicables sur tout fournisseur cloud, seules les commandes diffèrent.
-
Créer un VPC dans la région cible
Le VPC (Virtual Private Cloud), équivalent du VNet chez Azure ou du Net chez Outscale, est l'enveloppe logique de votre réseau privé. Il s'étend sur toutes les AZ d'une région. Vous le créez une seule fois.
Fenêtre de terminal # AWSaws ec2 create-vpc --cidr-block 10.0.0.0/16# Azureaz network vnet create --name myvnet --address-prefix 10.0.0.0/16# Outscaleoapi-cli CreateNet --IpRange "10.0.0.0/16" -
Créer des subnets dans chaque AZ
Vous découpez votre VPC en sous-réseaux (
subnets), avec un subnet par couche applicative et par AZ. Un design typique 3-tier sur 2 AZ donne 6 subnets : web-az1, web-az2, app-az1, app-az2, db-az1, db-az2. -
Déployer des instances dans chaque AZ
Pour chaque tier applicatif, lancez au minimum deux instances réparties dans deux AZ différentes. Une seule instance dans une AZ reste un SPoF même en architecture « multi-AZ ».
-
Configurer un Load Balancer multi-AZ
Le Load Balancer distribue le trafic entre les instances de toutes les AZ et détecte automatiquement les instances défaillantes. Sur AWS c'est ALB ou NLB, sur Azure Application Gateway ou Load Balancer, sur GCP Load Balancing, sur Outscale LBU. Tous ces services sont nativement multi-AZ quand vous les configurez dessus.
-
Répliquer vos données
Pour les bases de données, configurez la réplication multi-AZ. Sur les services managés (RDS Multi-AZ, Azure SQL Geo-Replication, Cloud SQL HA, Outscale RDS), c'est typiquement une option à activer au provisioning. Sur des bases auto-gérées, vous configurez vous-même la réplication maître-esclave entre AZ.
Coût du multi-AZ
Section intitulée « Coût du multi-AZ »Le multi-AZ a un coût qu'il faut connaître pour faire des choix éclairés. Sur la plupart des fournisseurs, vous payez chaque instance répliquée, le stockage dupliqué, et le transfert inter-AZ (typiquement 0,01 €/Go dans chaque sens, gratuit chez Azure depuis 2025). Pour la plupart des architectures applicatives, le surcoût total tourne entre × 2 et × 3 par rapport à un déploiement mono-AZ.
7. Multi-région : DR et présence mondiale
Section intitulée « 7. Multi-région : DR et présence mondiale »Pour les applications vraiment critiques, une seule région ne suffit pas. Une catastrophe régionale (tremblement de terre, cyberattaque massive, panne de fournisseur prolongée) pourrait tout affecter, même avec une architecture multi-AZ irréprochable.
| Besoin | Solution multi-région |
|---|---|
| Reprise d'activité (DR) | Région secondaire passive avec backups répliqués |
| Haute disponibilité globale | Régions actives simultanées en active-active |
| Faible latence mondiale | Régions multiples proches des utilisateurs |
| Séparation données sensibles | Région souveraine pour le sensible, région standard pour le reste |
Active-passive (DR)
Section intitulée « Active-passive (DR) »Principe : une région principale active sert tout le trafic, une région secondaire en standby reçoit les réplications de données et est prête à prendre le relais. Le passage de l'une à l'autre (failover) prend de quelques minutes à plusieurs heures selon la maturité de votre runbook.
Avantages : coût modéré (région secondaire sous-dimensionnée, on dimensionne pour la reprise pas pour la charge nominale), simple à mettre en œuvre. Inconvénients : RTO de quelques minutes à heures, possible perte de données (RPO) selon la réplication choisie.
Coût typique : +30 à 50 % du coût mono-région.
Active-active
Section intitulée « Active-active »Principe : plusieurs régions servent du trafic simultanément, le routage se fait via DNS géographique ou anycast. Une panne d'une région bascule automatiquement le trafic sur les autres.
Avantages : latence optimale pour tous les utilisateurs, bascule instantanée sans intervention humaine, pas de perte de données si réplication synchrone. Inconvénients : complexité élevée (synchronisation des données entre régions, gestion des conflits), coût doublé ou triplé.
Coût typique : × 2 à × 3 du coût mono-région.
Le piège du transfert inter-région
Section intitulée « Le piège du transfert inter-région »Le multi-région augmente significativement les coûts de transfert — c'est le piège financier principal. Si vous répliquez une base de 1 To entre eu-west-3 et us-east-1 AWS avec des changements fréquents, le coût mensuel de transfert seul atteint plusieurs centaines d'euros. Ajoutez le stockage doublé, les instances doublées : faites le calcul TCO complet (cf. TCO cloud vs on-premise) avant de vous lancer.
8. Régions souveraines : le cas spécifique 2026
Section intitulée « 8. Régions souveraines : le cas spécifique 2026 »Le concept de région souveraine s'est imposé en Europe depuis 2020 pour répondre aux exigences de souveraineté juridique vis-à-vis du CLOUD Act et du FISA américains. Une région souveraine est plus qu'un datacenter géographiquement européen : c'est une infrastructure opérée par une entité européenne sous juridiction européenne.
Les qualifications réglementaires en France
Section intitulée « Les qualifications réglementaires en France »SecNumCloud 3.2 (ANSSI) : référentiel de qualification français qui impose plus de 360 critères sur 14 thèmes (organisation, gestion des risques, sécurité physique, sécurité du personnel, gestion des actifs, contrôle d'accès, cryptographie, sécurité opérationnelle, sécurité réseau, etc.). Fournisseurs qualifiés en 2026 : Outscale, OVHcloud (sur certains environnements), Cloud Temple, Cegedim Cloud, Orange Business, Worldline.
EUCS (European Cybersecurity Certification Scheme for Cloud Services) : équivalent européen en cours de finalisation 2024–2026, avec 3 niveaux (Basic, Substantial, High). Le niveau High vise à fournir une qualification équivalente à SecNumCloud à l'échelle UE.
HDS (Hébergement de Données de Santé) : certification spécifique aux données de santé, indépendante de SecNumCloud mais souvent cumulative.
Régions souveraines disponibles en 2026 chez les sovereign clouds français
Section intitulée « Régions souveraines disponibles en 2026 chez les sovereign clouds français »| Fournisseur | Région standard | Région SecNumCloud |
|---|---|---|
| Outscale | eu-west-2 (Île-de-France) | cloudgouv-eu-west-1 (Île-de-France) |
| OVHcloud | gra, rbx, sbg | Environnements dédiés Bare Metal SecNumCloud |
| Cloud Temple | Île-de-France | Tout l'environnement qualifié |
| Cegedim Cloud | Île-de-France | Spécialisé santé HDS + SecNumCloud |
Quand choisir une région souveraine
Section intitulée « Quand choisir une région souveraine »- Données réglementées : santé (HDS), administration française (doctrine « Cloud au centre »), banque (PCI-DSS sensible), défense.
- Données sensibles d'entreprise : propriété intellectuelle critique, R&D stratégique, données RH, relations client en B2C.
- Anticipation NIS2 : la directive européenne NIS2 impose des exigences de cybersécurité pour les opérateurs de services essentiels et importants — privilégier souverain par anticipation est défensable.
9. Les pièges courants des choix géographiques
Section intitulée « 9. Les pièges courants des choix géographiques »Dans la pratique courante, voici les cinq pièges récurrents qui font dériver les projets, classés par fréquence.
Piège 1 — Tout déployer dans une seule AZ pour faire simple. Même en environnement de test, prendre l'habitude du multi-AZ évite les mauvaises surprises au moment du passage en production. Le surcoût est faible et la pédagogie acquise est précieuse.
Piège 2 — Choisir la région la moins chère sans analyser la latence. La région la moins chère n'est pas toujours la meilleure. Pour des utilisateurs français, une région française est presque toujours le bon choix, même si elle coûte 10 % plus cher qu'une région irlandaise — la perte de qualité d'expérience utilisateur se paye plus cher en pertes de conversion.
Piège 3 — Croire que multi-AZ protège de tout. Une catastrophe régionale (rare mais possible) impacte l'ensemble des AZ d'une région. Pour les applications vraiment critiques, ajoutez une stratégie de reprise multi-région au moins en mode active-passive avec backups distants.
Piège 4 — Tout répliquer entre régions « pour être safe ». La facture de transfert de données peut devenir astronomique. Répliquez uniquement ce qui est nécessaire, à la fréquence nécessaire. Les données froides peuvent être répliquées une fois par jour, pas en continu. Utilisez la réplication incrémentale chaque fois que possible.
Piège 5 — Considérer les AZ comme interchangeables. Certains services ou types d'instances ne sont pas disponibles dans toutes les AZ d'une même région — c'est rare mais ça arrive sur les services récents ou les types d'instances exotiques (GPU, instances très grandes). Vérifiez la disponibilité avant de concevoir votre architecture.
10. Récapitulatif — comment articuler région et AZ
Section intitulée « 10. Récapitulatif — comment articuler région et AZ »Pour résumer les concepts de cette page sous forme actionnable.
Au niveau région : choix qui dépend de quatre critères à pondérer selon le contexte — proximité utilisateurs, contraintes réglementaires (RGPD, HDS, SecNumCloud), services disponibles, coûts. La proximité utilisateurs prime généralement sur les autres critères pour les applications interactives.
Au niveau AZ : déployer dans au moins 2 AZ d'une même région pour la haute disponibilité de production. 3 AZ pour les workloads critiques. 1 seule AZ acceptable pour les environnements de test ou les MVP.
Pour la résilience géographique forte : ajouter une région secondaire en active-passive ou active-active selon le RTO/RPO exigé. À pondérer avec les coûts de transfert inter-région qui peuvent être significatifs.
Pour la souveraineté juridique : si les données traitées sont soumises à des contraintes réglementaires (RGPD strict, données de santé, données gouvernementales), vérifier la juridiction applicable au fournisseur cloud et privilégier les régions qualifiées (SecNumCloud en France, EUCS en cours pour l'UE). Cf. Souveraineté technologique de la stack pour le détail.
À retenir
Section intitulée « À retenir »- Région et zone de disponibilité (AZ) sont les deux niveaux géographiques universels du cloud, avec des terminologies variables par fournisseur (sous-région chez Outscale, zone chez GCP).
- Quatre critères de choix d'une région : latence utilisateurs, conformité réglementaire, services disponibles, coûts.
- Multi-AZ = haute disponibilité par répartition sur plusieurs datacenters d'une même région, surcoût × 2 à × 3 mais protection contre les pannes locales.
- Multi-région = résilience contre les catastrophes régionales (active-passive + 30–50 %, active-active × 2 à × 3).
- Les régions souveraines (SecNumCloud, EUCS) répondent aux exigences juridiques européennes — Outscale, OVHcloud, Cloud Temple, Cegedim, Orange Business, Worldline les fournissent en France.
- Cinq pièges classiques : mono-AZ par simplicité, région la moins chère sans latence, multi-AZ confondu avec multi-région, sur-réplication, AZ supposées interchangeables.
- Le défaut 2026 pour les projets français est région souveraine française sauf contrainte écosystème spécifique.