Le cloud souverain est l'un des termes les plus surchargés des achats IT de défense. Les fournisseurs l'appliquent à tout, d'une région d'hyperscaler dont les bâtiments sont à l'intérieur des frontières nationales à un cloud privé totalement air-gappé exploité exclusivement par des ressortissants habilités. L'étiquette cache des décisions architecturales qui déterminent, en pratique, si un gouvernement étranger peut contraindre à la divulgation de vos données, si un service de renseignement adverse peut coopter le personnel de l'opérateur cloud, et si votre plan de continuité d'opérations survit à une fracture géopolitique. Pour des charges de défense, ces questions sont structurantes.
Cet article parcourt le paysage pratique du cloud souverain en 2026 : les régions gouvernementales des hyperscalers US, la nouvelle génération d'offres souveraines UE (Bleu, Delos, T-Systems, OVH), les clouds défense NATO et nationaux, et la référence on-prem que toutes finissent par concurrencer. Il est écrit pour les architectes prenant des décisions de placement, pas pour les équipes achats rédigeant des RFP.
1. Ce que signifie réellement « cloud souverain »
La souveraineté dans le cloud n'est pas une propriété — c'est trois vecteurs orthogonaux, et toute évaluation honnête doit noter chacun indépendamment.
La résidence des données est le plus facile et le plus surévalué. Elle demande : où vivent physiquement les octets ? Une région à Francfort, Paris ou Varsovie satisfait la résidence pour les acheteurs UE. Mais la résidence seule est la plus faible garantie de souveraineté offerte, car elle ne dit rien sur qui peut atteindre ces octets via le plan de contrôle.
La souveraineté opérateur demande : qui peut administrer l'infrastructure ? Les régions commerciales des hyperscalers US sont administrées par des équipes d'ingénierie globalement distribuées — un ticket L2 touchant votre locataire peut être traité depuis l'Inde, l'Irlande ou Seattle. Les offres souveraines de grade gouvernemental restreignent cela à un ensemble défini de ressortissants habilités, avec des pistes d'audit suffisantes pour démontrer la conformité. SecNumCloud (France) et C5 (Allemagne) exigent tous deux que les opérateurs soient des ressortissants UE travaillant sous juridiction UE.
La souveraineté juridictionnelle est le vecteur qui brise le plus d'hypothèses d'achat. Le CLOUD Act US de 2018 permet aux autorités américaines de contraindre toute société constituée aux US à produire des données sous son contrôle, indépendamment de leur localisation physique. Donc un hyperscaler avec siège US exploitant une infrastructure à Francfort reste légalement atteignable depuis un tribunal américain. La réponse de l'UE — RGPD, Schrems II, Data Act — a affûté la question mais ne l'a pas résolue. La seule réponse structurelle est de placer à la fois les données et l'entité corporative qui les contrôle sous juridiction UE.
Un diagnostic utile : demandez si une décision judiciaire étrangère, signifiée au fournisseur cloud, pourrait en principe contraindre à la divulgation des données de votre charge sans l'implication de votre gouvernement. Si la réponse honnête est « oui », vous n'avez pas un cloud souverain — vous avez un cloud régional.
2. Offres souveraines des hyperscalers US
Les hyperscalers US ont passé quinze ans à construire une isolation de grade gouvernemental. Le résultat est le tier de cloud souverain le plus mature de la planète — pour les acheteurs affiliés aux US.
AWS GovCloud (US-East et US-West) est physiquement isolé, administré uniquement par des US-persons et accrédité FedRAMP High et DoD IL4/IL5. AWS Secret Region et AWS Top Secret Region existent pour les tiers classifiés mais ne sont atteignables que par les acheteurs gouvernementaux US et contractants accrédités. AWS a annoncé un European Sovereign Cloud (Brandebourg) pour livraison en 2026, exploité entièrement par des ressortissants UE — le premier hyperscaler US à s'engager sur cette structure pour les acheteurs UE.
Azure Government reflète le modèle AWS avec Azure Government (FedRAMP High, IL5), Azure Government Secret (IL6) et Azure Government Top Secret. Microsoft a la plus vaste empreinte accréditée au niveau classifié, et Azure Government hérite de la plupart des services Azure commerciaux avec un décalage de six à douze mois. Microsoft exploite également Microsoft Cloud for Sovereignty comme couche configurable au-dessus d'Azure commercial pour les acheteurs voulant des contrôles de souveraineté sans la pleine charge d'accréditation Azure Government — voir notre comparaison d'architecture GovCloud pour le détail de placement Azure-vs-AWS.
Google Assured Workloads est le plus léger des trois : une surcouche de plan de contrôle sur Google Cloud commercial qui impose résidence, personnel et contraintes de gestion de clés. Il cible FedRAMP High et IL5 pour des configurations spécifiques mais n'exploite pas de région séparée. Pour les charges où une région commerciale configurée est acceptable, cela peut raccourcir le temps jusqu'à l'ATO ; pour IL6 et au-dessus, il n'est pas compétitif.
La contrainte dure pour les acheteurs non-US : GovCloud, Azure Government et les tiers IL5/IL6 sont filtrés par accès US-persons uniquement et contrôle d'export US. Une unité de l'armée de l'air française ne peut pas acheter de capacité GovCloud. C'est la raison structurelle pour laquelle le tier de cloud souverain UE existe.
3. Offres souveraines UE
Bleu est la coentreprise cloud souverain française entre Capgemini et Orange. Il fait tourner la technologie Microsoft Azure sous licence à l'intérieur de datacenters français, exploités uniquement par des nationaux français, avec contrôle corporatif entièrement sous droit français — explicitement hors de portée du CLOUD Act. La qualification SecNumCloud est l'accréditation phare. Bleu est l'exemple le plus clair du modèle « hyperscaler sous licence sous opérateur souverain » et constitue le placement de choix pour les charges défense françaises, ministérielles et OIV (opérateur d'importance vitale).
Delos est le cloud souverain allemand construit par SAP et Arvato Systems, à nouveau sur technologie Microsoft sous licence, visant l'accréditation C5 et destiné aux charges Bund (fédéral) et Länder (états). Delos et Bleu sont jumeaux : même motif technique, juridictions nationales différentes.
T-Systems Sovereign Cloud est l'offre plus ancienne de Deutsche Telekom — cloud souverain construit sans couche de licence hyperscaler, sur OpenStack et orchestration propriétaire Telekom. Il vise la même base d'acheteurs que Delos mais avec un plafond fonctionnel plus bas et un historique opérationnel plus long. Pour les charges qui n'ont pas besoin de la surface d'API hyperscaler complète, T-Systems est souvent moins cher et plus rapide à onboarder.
OVHcloud occupe une niche distincte : une alternative hyperscale entièrement détenue par des Européens avec pods bare-metal, cloud dédié et tier cloud public, tous sous juridiction française. OVH ne prétend pas égaler la parité fonctionnelle d'AWS, mais pour les charges intensives en calcul et stockage il est compétitif en prix et délivre une véritable souveraineté juridictionnelle sans dépendance de licence US. Pour une analyse de placement UE-vs-US plus approfondie voir notre comparaison cloud souverain UE vs US.
4. Clouds défense NATO et nationaux
Au-dessus du tier souverain commercial siège une couche qui n'apparaît pas dans les brochures des fournisseurs : les clouds NATO et MoD nationaux. Ce sont les destinations pour les charges classifiées où même SecNumCloud ou FedRAMP High est insuffisant.
La NCIA Software Factory et le programme cloud plus large de l'OTAN fournissent la plateforme au niveau alliance pour les charges classifiées multi-nations (NATO Secret et en dessous). Les MoD nationaux exploitent des clouds souverains parallèles — MODCloud au Royaume-Uni, le cloud BWI de la Bundeswehr en Allemagne, le néerlandais CC-NDC, le cloud MOD polonais — chacun accrédité au tier classifié national et intégré aux protocoles de partage allié.
En dessous siège le tier air-gappé proprement dit, pour les charges équivalentes TS/SCI. Nous avons couvert le motif architectural dans déploiement air-gappé pour la défense. Le point pertinent ici est que les décisions de placement de charge doivent inclure ce tier explicitement — déplacer une charge de NATO Secret vers un cloud souverain commercial est rare, mais remonter est commun, et l'architecture doit survivre à cette transition sans refonte.
5. Hybride et référence on-prem
Le cloud souverain n'est pas toujours la bonne réponse. La référence private cloud on-prem — VMware vSphere, OpenStack ou Kubernetes sur bare metal dans un datacenter national accrédité — gagne encore dans trois scénarios.
Premièrement, pour les charges classifiées ou air-gappées qui ne tolèrent aucune dépendance réseau externe. Les hyperscalers souverains offrent des modes déconnectés (Azure Stack Hub, AWS Outposts, Google Distributed Cloud Air-Gapped) mais le tarif, le modèle de support et les contraintes d'accès opérateur ramènent souvent le calcul vers le private cloud.
Deuxièmement, pour les charges en régime permanent où l'amortissement capex bat la marge hyperscaler. Une charge qui tourne 24/7 à charge prévisible pendant cinq ans est le pire match économique possible pour tout cloud — souverain ou non. La marge hyperscaler sur du bare metal amorti est typiquement 3-5× annualisée.
Troisièmement, pour les organisations qui exploitent déjà des datacenters certifiés. Le coût marginal d'un rack supplémentaire est faible. Le coût marginal de construire une capacité d'opérations cloud-souverain hyperscaler est élevé. Pour les organisations IT MoD en place, l'extension on-prem est généralement le chemin de transition moins cher.
Point clé : La question de placement est rarement « cloud souverain ou non ». C'est « quel tier de souveraineté par charge, et quels transferts inter-tiers sont requis ? » Un patrimoine défense moderne fait tourner les quatre — cloud commercial pour le marketing, cloud souverain pour les CUI, cloud MoD national pour le Restricted-and-above, private cloud air-gappé pour Secret-and-above — et l'architecture vit dans les connecteurs entre eux. Voir le guide complet de la cybersécurité défense pour le cadre de contrôle environnant.
6. Décisions de placement de charge
Le placement de charge se réduit à un petit ensemble de tiers de classification et à un petit ensemble d'arbitrages coût-et-contrôle. La matrice pratique :
Non classifié, face publique (sites web, portails de recrutement, API publiques) appartient aux régions hyperscaler commerciales dans votre juridiction. Les contrôles de souveraineté ajoutent coût et friction opérationnelle sans valeur proportionnelle.
Non classifié, CUI interne (RH, finance, collaboration interne) appartient au cloud souverain — classe Bleu/Delos/Azure Gov — pour la protection juridictionnelle des données du personnel et opérationnelles, même si aucun marquage classifié formel ne s'applique. L'exposition au CLOUD Act est le facteur déterminant.
Restricted et NATO Restricted appartient au cloud MoD national ou au tier allié équivalent. Le cloud souverain commercial est généralement insuffisant ici pour des raisons d'accréditation plus que techniques.
Secret et au-dessus appartient à l'infrastructure nationale ou d'alliance air-gappée. Aucune accréditation cloud commercial n'atteint ce tier en 2026.
Le coût que les équipes achats sous-budgétisent est le transfert cross-domain : chaque fois que des données traversent des tiers, une solution cross-domain (diode unidirectionnelle, garde par inspection de contenu, ou appliance cross-domain accréditée) est requise. Elles sont lentes, chères, et constituent le goulot d'étranglement opérationnel des architectures multi-tier. Concevoir pour minimiser les transferts requis est plus précieux qu'optimiser au sein d'un tier unique.
7. Motifs architecturaux
Trois motifs récurrents apparaissent dans les patrimoines défense bien architecturés.
Plan de contrôle en cloud souverain, plan de données en cloud mission. Identité, politique, supervision et CI/CD vivent dans un cloud tier-souverain où accès opérateur et audit sont serrés. Les charges mission — traitement capteurs, services C2, géo-analytiques — tournent là où la latence et la classification l'exigent, souvent sur infrastructure edge ou cloud-mission. Le plan de contrôle gère le plan mission via des interfaces étroites et auditées. C'est la même séparation que la mise en réseau militaire zero-trust formalise au niveau réseau.
Identité fédérée à travers les tiers. L'identité doit traverser le patrimoine — un analyste ne devrait pas avoir besoin de trois identifiants séparés pour cloud souverain, cloud MoD et enclave air-gappée. Identité fédérée avec autorisation à base de claims, ancrée dans un fournisseur d'identité cloud souverain et projetée (via mécanismes cross-domain approuvés) dans les tiers de classification supérieure, est le motif standard. Le problème dur est le cycle de vie des identifiants à travers l'air-gap.
Topologie de déploiement régionale. Les régions de cloud souverain sont plus éparses que les régions commerciales. Un déploiement multi-région actif-actif trivial en AWS commercial devient un exercice de conception soigneux en GovCloud (deux régions) ou Bleu (initialement une). Le calcul de domaine de panne change : la résilience régionale signifie souvent résilience hybride, avec un primaire cloud-souverain basculant sur un secondaire on-prem dans la même juridiction. Voir stratégie défense multi-cloud pour le détail du motif de résilience.
8. Verrouillage fournisseur et plan de sortie
Le verrouillage en cloud souverain est plus difficile que celui en cloud commercial car l'ensemble de substituts est plus petit. Il y a cinq options souveraines UE viables. Il y a deux véritables options US de tier GovCloud. L'effet de levier qu'un fournisseur unique a sur un client défense captif est d'autant plus grand.
L'atténuation a trois couches.
Abstractions d'infrastructure. Terraform avec modules agnostiques fournisseur, ou Crossplane au-dessus de Kubernetes, permet à l'artefact de déploiement de survivre à un changement de fournisseur. La discipline plus dure est d'éviter les services propriétaires fournisseur quand une alternative portable existe — utiliser du Kubernetes managé (EKS, AKS, OVH Managed Kubernetes) plutôt que du PaaS spécifique au fournisseur, utiliser du stockage objet compatible S3 plutôt que les API blob natives, utiliser PostgreSQL ou des moteurs de données open-source plutôt que des bases propriétaires. Le coût de la portabilité est réel mais borné ; le coût d'une migration tardive est non borné.
L'exercice de sortie. L'exercice « sortir de GovCloud » — faire effectivement un tabletop ou une migration pilote d'une charge non critique hors du cloud souverain choisi, vers un autre fournisseur souverain ou vers on-prem — fait surgir concrètement le coût du verrouillage. Les organisations de défense devraient réaliser cet exercice au moins tous les deux ans par charge majeure. La sortie est un runbook de migration documenté avec estimations de durée et coût, qui alimente le registre de risque procurement et le plan BCP/DR.
Clauses contractuelles. Les achats doivent imposer l'export de données lisible par machine dans une fenêtre définie, les droits IP sur l'automatisation de déploiement, aucun surcoût d'egress aux fins de sortie fournisseur, et des conditions d'assistance à la transition. C'est là que l'approvisionnement logiciel ITAR-free et le langage de sortie fournisseur convergent : l'objectif dans les deux cas est de préserver l'optionnalité souveraine indépendamment de la coopération continue d'un seul fournisseur étranger.
Le cloud souverain, bien fait, n'est pas une seule décision d'achat mais une posture de portefeuille : placement explicite par charge, conception délibérée des transferts inter-tier, abstractions d'infrastructure qui préservent la sortie, et un exercice récurrent pour vérifier que la sortie fonctionne réellement. Les fournisseurs continueront d'ajouter des étiquettes souveraines. L'architecture est ce qui détermine si ces étiquettes signifient quelque chose.