Pilier Sovereignty (Souveraineté) sur OUTSCALE

Le 7ᵉ pilier Souveraineté est l’ajout spécifique au Well-Architected pour les architectures déployées sur un cloud souverain. Il couvre quatre mécanismes : la résidence des données (où vivent-elles physiquement, qui peut y accéder juridiquement), la juridiction applicable (droit français et européen vs Cloud Act / FISA), la réversibilité (plan de sortie, formats d’export) et le lock-in technologique (engagement aux APIs propriétaires vs aux standards). Sur OUTSCALE, la région cloudgouv-eu-west-1 qualifiée SecNumCloud 3.2 par l’ANSSI depuis décembre 2023 est la brique principale de ce pilier. Cette page formule les questions clés, propose une checklist actionnable, deux ADR types et les points d’audit correspondants.

Le pilier en deux phrases

Sovereignty évalue la capacité d’une architecture à garantir que les données restent sous une juridiction maîtrisée, que les dépendances opérationnelles ne créent pas de risque géopolitique, et que la sortie vers un autre fournisseur reste réalisable à un coût maîtrisable. Sur OUTSCALE, il se matérialise par le choix de la région cloudgouv-eu-west-1 quand les contraintes l’exigent, par une architecture portable appuyée sur des standards (containers OCI, OpenAPI, formats ouverts), et par une stratégie de réversibilité documentée et testée.

Les questions clés

Une architecture qui revendique une posture Sovereignty doit pouvoir répondre aux questions suivantes :

Résidence des données — les données sont-elles physiquement hébergées sur le territoire français ou européen, dans une région documentée ?
Juridiction du fournisseur — le fournisseur est-il soumis exclusivement au droit français et européen, ou est-il aussi soumis à des lois extraterritoriales (Cloud Act américain, FISA) ?
Personnel du fournisseur — les administrateurs du cloud (côté fournisseur) sont-ils citoyens et résidents européens, soumis aux mêmes contraintes juridiques ?
Qualifications — la région utilisée est-elle qualifiée par un organisme reconnu (SecNumCloud 3.2 par l’ANSSI pour la France, C5 en Allemagne, certifications sectorielles HDS, PCI DSS) ?
Standards et portabilité — les workloads s’appuient-ils sur des standards ouverts (containers OCI, OpenAPI, S3-compatible, PostgreSQL, MySQL) ou sur des APIs propriétaires non portables ?
Stratégie de sortie — un plan de réversibilité est-il documenté et testé au moins annuellement (export complet, restauration sur un autre fournisseur) ?
Formats d’export — les données critiques (BDD, objets, configurations) sont-elles exportables dans des formats ouverts (CSV, JSON, Parquet, dump SQL standard) ?
Dépendances logicielles — la stack applicative repose-t-elle sur des logiciels libres ou intègre-t-elle des composants propriétaires non portables ?
Doctrine Cloud au centre — pour le secteur public français, l’architecture respecte-t-elle la doctrine Cloud au centre (qualification SecNumCloud exigée pour les données sensibles) ?
Conformité NIS 2 — pour les OSE (Opérateurs de Services Essentiels), la qualification SecNumCloud est-elle alignée avec les obligations NIS 2 ?

Application sur OUTSCALE

Choix de région — `eu-west-2` ou `cloudgouv-eu-west-1`

OUTSCALE expose deux régions européennes pertinentes pour le recueil :

eu-west-2 (région commerciale, France) — qualifiée HDS (Hébergement de Données de Santé) et ISO 27001. Adaptée pour la majorité des workloads soumis au RGPD avec un besoin de localisation française mais sans exigence SecNumCloud.
cloudgouv-eu-west-1 (région souveraine, France) — qualifiée SecNumCloud 3.2 par l’ANSSI depuis décembre 2023. Adaptée aux OIV, OSE, données sensibles, périmètres de conformité élevés.

Le choix de région se fait au démarrage du projet, pas après coup : déplacer un workload entre deux régions Outscale demande une migration complète, les régions sont indépendantes (réseaux, comptes, OMI séparés).

Juridiction et personnel

OUTSCALE est une filiale 100 % Dassault Systèmes, société française cotée à Paris, soumise au droit français et européen. Le personnel d’administration des régions souveraines respecte les exigences SecNumCloud (citoyenneté UE, habilitation, formation).

Comparativement, les hyperscalers américains (AWS, Azure, GCP) sont soumis au Cloud Act (2018) qui autorise l’autorité fédérale américaine à exiger l’accès à des données stockées dans une filiale étrangère, ainsi qu’au FISA (Foreign Intelligence Surveillance Act). Ces lois s’appliquent indépendamment de la localisation physique des serveurs et créent un risque juridique que la région européenne d’un hyperscaler ne peut pas écarter.

Le détail des implications SecNumCloud est traité dans SecNumCloud — implications.

Standards et portabilité

La portabilité est l’instrument premier de mitigation du lock-in. Sur OUTSCALE :

OAPI — l’API native est documentée en OpenAPI ; les SDK officiels existent. L’API est aussi compatible AWS sur un grand nombre d’opérations, ce qui permet de réutiliser les outils AWS standards (aws-cli, SDK boto3, Terraform AWS provider sur les opérations compatibles).
OOS — stockage objet compatible S3, donc accessible avec n’importe quel client S3 standard.
OKS — Kubernetes managé conforme à l’API Kubernetes upstream — les manifestes restent portables vers tout autre Kubernetes.
Containers OCI — toute image OCI tourne sans modification sur OKS, sur Talos auto-hébergé, ou sur n’importe quel cloud compatible.

Le bon réflexe architectural : privilégier les standards (OCI, Kubernetes, PostgreSQL, S3-compatible) à chaque décision de stack, et réserver les composants propriétaires aux cas où le bénéfice fonctionnel est clair et documenté.

Stratégie de réversibilité

Un plan de réversibilité documente la procédure de sortie d’un fournisseur cloud. Pour OUTSCALE comme pour tout autre cloud, il doit comporter :

Inventaire des ressources (VMs, BSU, OOS, fGPU, IP publiques, secrets, configurations).
Procédure d’export par type de ressource (snapshots BSU exportables, objets OOS migrables vers un autre stockage S3-compatible, configurations IaC en Terraform, secrets vers un autre gestionnaire).
Délai cible de sortie (ex. 90 jours pour un parc moyen).
Coût estimé de la sortie (transfert de données, durée d’indisponibilité).
Test annuel sur un périmètre réduit — exporter une application complète vers un autre environnement, mesurer le temps réel.

Sans test de réversibilité, le plan reste théorique. La première sortie réelle réserve toujours des surprises (formats incompatibles, dépendances non documentées, dépassement de délai).

Conformité Doctrine Cloud au centre et NIS 2

Pour le secteur public français, la circulaire « Cloud au centre » publiée en 2021 et mise à jour en 2023 impose la qualification SecNumCloud pour les données sensibles. Pour les OSE désignés au titre de NIS 2, la qualification SecNumCloud est un instrument d’alignement avec les exigences sectorielles.

OUTSCALE cloudgouv-eu-west-1 étant qualifiée SecNumCloud 3.2, son utilisation soutient le respect de ces obligations — sans pour autant les remplir intégralement, car la couche client conserve sa part de responsabilité (configuration sécurisée, gestion des accès, journalisation). La matrice de responsabilité partagée est traitée dans SecNumCloud — implications.

Checklist Definition of Done

Région choisie documentée avec justification (RGPD seul vs SecNumCloud).
Données sensibles strictement hébergées sur la région cible — vérifié par audit régulier.
Workloads s’appuient sur des standards (OCI, Kubernetes API, S3-compatible, BDD standard).
Dépendances propriétaires justifiées par un bénéfice fonctionnel documenté.
Plan de réversibilité versionné en Git, à jour, testé annuellement sur un périmètre réduit.
Inventaire automatisé des ressources via oapi-cli (Read*) — base du plan d’export.
Formats d’export validés pour les données critiques (BDD, objets OOS, secrets).
Conformité Doctrine Cloud au centre documentée si applicable.
Conformité NIS 2 documentée si applicable.

ADR types

ADR-SOV-01 — Choix de région SecNumCloud pour les données sensibles

Contexte : un workload manipule des données sensibles soumises à NIS 2 ou à la doctrine Cloud au centre. Le choix de la région OUTSCALE détermine la couverture juridique et certificatoire.

Décision : déployer ce workload exclusivement sur la région cloudgouv-eu-west-1 qualifiée SecNumCloud 3.2. Les workloads non sensibles peuvent rester sur eu-west-2 (région commerciale, qualifiée HDS et ISO 27001).

Conséquences : le compte SecNumCloud impose des contraintes opérationnelles (gestion des accès renforcée, journalisation étendue, traçabilité). Bénéfices : conformité réglementaire alignée, réduction du risque juridique, communication client renforcée pour les contrats sensibles.

ADR-SOV-02 — Stratégie de réversibilité documentée et testée

Contexte : l’organisation s’engage contractuellement (ou réglementairement, au titre de DORA pour le secteur financier) sur sa capacité à changer de fournisseur cloud dans un délai défini. Le plan n’existe pas ou n’a jamais été testé.

Décision : documenter un plan de réversibilité couvrant l’inventaire, les procédures d’export, le délai cible, le coût estimé. Tester annuellement sur une application complète : export depuis OUTSCALE, restauration sur un environnement de test (autre fournisseur ou simulation), mesure du temps réel.

Conséquences : 1 à 2 jours-homme par test annuel. Bénéfices : plan factuel et opérationnel, équipe entraînée, conformité contractuelle ou réglementaire démontrable, négociation renforcée avec le fournisseur (la réversibilité prouvée change le rapport de force).

Points d’audit correspondants

oapi-cli ReadRegions

Lister les régions accessibles depuis le compte. Vérifier que les workloads sensibles ne sont pas accidentellement déployés sur une région non qualifiée.

oapi-cli ReadSubregions

Détailler les sous-régions par région. Sur cloudgouv-eu-west-1, vérifier la répartition multi-AZ.

oapi-cli ReadVms --Filters.VmStateNames[] running
oapi-cli ReadVolumes
oapi-cli ReadImages

Inventaire complet des ressources actives. La sortie de ces appels constitue la base du plan d’export dans le plan de réversibilité.

L’audit complet est traité dans une page dédiée du Volet 5, à venir.

Antipatterns à éviter

Région choisie après le début. Démarrer un projet sur la région commerciale, puis vouloir migrer vers la région SecNumCloud quand un client l’exige. La migration coûte significativement plus que le démarrage direct sur la bonne région.

Lock-in propriétaire « parce que c’est plus simple ». Adopter un service cloud propriétaire pour gagner quelques jours-homme, sans documenter la dépendance ni évaluer le coût de sortie. La dette s’accumule silencieusement.

Plan de réversibilité jamais testé. Maintenir un plan théorique satisfaisant un audit annuel sans jamais l’exécuter. Le jour où le test devient réel, le plan se révèle largement obsolète.

Confusion SecNumCloud / RGPD. Considérer que SecNumCloud remplace le RGPD ou réciproquement. Les deux référentiels sont complémentaires et adressent des sujets différents. SecNumCloud couvre la sécurité technique et organisationnelle du fournisseur ; le RGPD couvre les droits des personnes sur les données personnelles.

SecNumCloud comme totem marketing. Communiquer « hébergé SecNumCloud » sans appliquer côté client les contrôles complémentaires (chiffrement applicatif, gestion fine des accès, journalisation exploitée). La qualification fournisseur ne fait pas la conformité du système global.

À retenir

4 mécanismes : résidence des données, juridiction, réversibilité, lock-in technologique.
Région cloudgouv-eu-west-1 qualifiée SecNumCloud 3.2 par l’ANSSI depuis décembre 2023 — brique de référence pour les charges sensibles.
Cloud Act / FISA restent un risque juridique pour les hyperscalers américains, indépendamment de la localisation des serveurs.
Standards ouverts (OCI, Kubernetes, S3-compatible, BDD standard) — premier levier de portabilité.
Plan de réversibilité documenté ET testé annuellement — sans test, c’est de la fiction.
Doctrine Cloud au centre / NIS 2 — la qualification SecNumCloud soutient l’alignement, sans dispenser des contrôles client.

Prochaines étapes

Volet 5 — Vue d'ensemble Le sommaire des 7 piliers Well-Architected appliqués à OUTSCALE.

SecNumCloud — implications pour l'architecte Le détail opérationnel : ce que la qualification garantit, ce qu'elle laisse au client.

Régions et sous-régions Le choix entre eu-west-2 (commerciale) et cloudgouv-eu-west-1 (SecNumCloud).

Pilier Security Le pilier jumeau côté contrôles techniques — secrets, chiffrement, journalisation.