Cloud souverain pour la Défense : résidence des données, plans de contrôle et architecture nationale

Par l'équipe d'ingénierie de Corvus Intelligence · À propos de l'équipe →

25 juin 2026 Mis à jour : 25 juin 2026 12 min de lecture

Tout ministère de la Défense ayant déplacé des charges de travail vers le cloud finit par affronter la même tension : les hyperscalers commerciaux fournissent des capacités — bases de données gérées, plateformes IA/ML, réseau mondial — qu'aucun fournisseur national ne peut égaler, pourtant ces mêmes hyperscalers sont des sociétés étrangères soumises au processus juridique de leur gouvernement d'origine, aux contrôles des exportations et aux exigences d'accès de leurs services de renseignement. L'expression « cloud souverain » décrit la tentative de résoudre cette tension sans accepter l'un ou l'autre des extrêmes : ni la dépendance totale aux hyperscalers, ni un mainframe national figé technologiquement. L'architecture qui en résulte n'est jamais simple, et les arbitrages sont rarement évidents avant d'avoir été faits en production.

Cet article examine l'architecture technique du cloud souverain pour les ministères de la Défense — non comme une liste de contrôle d'acquisition, mais comme un problème d'ingénierie. Nous couvrons ce que la souveraineté signifie réellement dans chacune de ses trois dimensions, comment concevoir un plan de contrôle national qui survit à une rupture du fournisseur, quels composants d'hyperscaler introduisent un risque de souveraineté inacceptable, à quoi ressemble la pile souveraine open source en production, et comment équilibrer les contraintes de souveraineté avec les exigences de capacités opérationnelles de la défense moderne. Pour le contexte des exigences plus larges de sécurité des charges de travail, voir notre guide sur la sécurité cloud des charges de travail militaires.

1. Ce que la souveraineté du cloud signifie pour un ministère de la Défense

L'expression « cloud souverain » est utilisée par les fournisseurs pour dire presque n'importe quoi — un centre de données dans le pays, un engagement contractuel de résidence des données, une entité juridique locale — et presque rien de ce qu'elle signifie dans le marketing des fournisseurs ne suffit à un sérieux examen d'architecture par un ministère de la Défense. La véritable souveraineté du cloud pour la défense couvre trois exigences distinctes qui doivent être évaluées indépendamment, car en satisfaire une n'implique pas de satisfaire les autres.

La résidence des données est la garantie que les données classifiées ou sensibles sont stockées, traitées et transmises exclusivement sur le territoire national ou dans une limite juridictionnelle approuvée — et que le ministère, et non le fournisseur de cloud, contrôle les clés de chiffrement qui les protègent. La résidence des données est l'exigence de souveraineté la plus souvent discutée et la plus facile à falsifier : un engagement contractuel de garder les données dans le pays est juridiquement inexécutable face à une assignation du renseignement d'un gouvernement étranger et ne fournit aucune protection technique contre une tâche de réplication mal configurée qui copie les données vers une zone de disponibilité hors du pays.

La souveraineté opérationnelle est la capacité à continuer d'exploiter la plateforme cloud sans la coopération continue d'un fournisseur étranger — y compris la capacité de survivre à la faillite du fournisseur, à des sanctions commerciales, à des changements de contrôle des exportations, ou à un gouvernement étranger contraignant le fournisseur à refuser ou dégrader le service. La souveraineté opérationnelle exige que le ministère puisse exploiter chaque composant de la plateforme à partir de la documentation et du code source seuls, sans dépendance continue à un support propriétaire du fournisseur qui pourrait être retiré.

La souveraineté de la chaîne d'approvisionnement est le contrôle des composants logiciels et matériels utilisés pour construire et exploiter le cloud. Une plateforme construite sur des logiciels open source auditables exécutés sur des serveurs d'un fabricant non allié ne satisfait aucune des deux dimensions : la couche logicielle peut être auditable, mais le micrologiciel du matériel ne l'est peut-être pas. Une analyse complète de la souveraineté de la chaîne d'approvisionnement couvre le micrologiciel des processeurs, les systèmes d'exploitation des équipements réseau, le micrologiciel des contrôleurs de stockage et les dépendances de bibliothèques logicielles de chaque composant de la pile souveraine.

La plupart des architectures actuelles de cloud souverain des ministères de la Défense satisfont partiellement la résidence des données, partiellement la souveraineté opérationnelle, et minimalement la souveraineté de la chaîne d'approvisionnement. L'intérêt de rendre les trois dimensions explicites est de permettre une évaluation honnête des risques plutôt qu'une fausse assurance tirée d'une certification « cloud souverain » qui ne traite que la dimension la plus visible.

2. Application de la résidence des données

Les contrôles techniques de résidence des données opèrent sur trois couches : la résidence des clés de chiffrement, l'application des politiques de localisation des données, et l'audit et la vérification. Les trois sont nécessaires ; une seule ne suffit jamais.

La résidence des clés de chiffrement est le contrôle technique le plus important, car elle détermine si les données peuvent être déchiffrées hors de la limite approuvée même en cas d'exfiltration physique. L'exigence est que le module matériel de sécurité (HSM) ou le service de gestion de clés (KMS) détenant les clés de chiffrement des données soit physiquement situé sur le territoire national et sous le contrôle opérationnel du ministère ou d'un organisme accrédité nationalement — et non un KMS géré d'un fournisseur de cloud étranger, où le matériel de clé ultime est détenu dans du matériel contrôlé par le fournisseur. En pratique, cela signifie :

HSM sur site (Thales Luna, Utimaco SecurityServer ou équivalent) pour les niveaux de classification les plus élevés, le HSM étant physiquement protégé et audité selon la politique de sécurité physique du ministère
KMS d'un fournisseur de cloud national adossé à du matériel HSM dans le pays, pour les niveaux de classification inférieurs où les services de gestion de clés gérés sont acceptables
Chiffrement par enveloppe : les clés de chiffrement des données (DEK) sont générées par objet ou par volume et chiffrées avec des clés de chiffrement des clés (KEK) détenues dans le HSM — le HSM ne détient jamais de données brutes, seulement du matériel de clé
Journalisation des accès aux clés, séparée et indépendante du journal d'audit du système de stockage, afin que les tentatives d'accès non autorisé aux clés soient visibles même si la couche de stockage est compromise

L'application des politiques de localisation des données exige que les services de stockage — stockage objet, volumes bloc, instances de base de données — soient contraints aux zones de disponibilité nationales au niveau de la configuration de la plateforme, et non par simple déclaration de politique. Dans un déploiement OpenStack, cela signifie configurer des règles d'affinité de zone de disponibilité dans Cinder et Swift qui empêchent le placement de répliques hors de la zone définie. Dans un déploiement chez un hyperscaler, cela signifie utiliser des politiques de contrôle des services (AWS) ou des définitions Azure Policy qui refusent toute création de ressource de stockage dans des régions hors du pays, appliquées au niveau du compte de gestion ou du groupe d'administration, pour que les équipes de charges de travail individuelles ne puissent pas les contourner.

L'audit et la vérification sont le processus opérationnel continu qui confirme que les contrôles de résidence des données fonctionnent comme prévu. La couche d'audit doit être indépendante de la couche de stockage — l'entité qui stocke les données ne peut pas être la seule à vérifier où elles sont stockées. Composants requis :

Vérification quotidienne automatisée que tous les points de terminaison de stockage utilisés par les charges de travail résolvent vers des adresses IP nationales, avec alerte sur tout nouveau point de terminaison
Surveillance des flux réseau qui signale tout trafic sortant vers des plages IP hors du pays depuis les services de stockage
Audit technique trimestriel par un tiers des contrôles de résidence des données, avec rapport des constats à l'autorité de sécurité du ministère
Configuration-as-code pour toutes les politiques de localisation des données, versionnée dans un dépôt immuable, afin que les changements de politique génèrent un diff détectable avant de prendre effet

Les contrôles contractuels — accords de traitement des données, clauses de localisation des données — sont un complément nécessaire aux contrôles techniques, mais ne doivent jamais être le mécanisme principal. Les contraintes contractuelles couvrent ce qu'un fournisseur coopératif fera ; elles ne couvrent pas ce qu'un fournisseur fait sous contrainte juridique de son gouvernement d'origine, et elles ne protègent pas contre une erreur de configuration technique.

3. Conception du plan de contrôle national

Le plan de contrôle d'une plateforme cloud — l'ensemble des services qui gèrent l'orchestration, l'identité et les secrets — est là où réside le risque de souveraineté à l'impact le plus élevé. Dans un environnement Kubernetes, les composants du plan de contrôle sont le serveur API, la grappe etcd, le planificateur, le gestionnaire de contrôleurs et les webhooks d'admission qui appliquent la politique au moment de la création des charges de travail. Si l'un de ces composants s'exécute sur une infrastructure gérée par le personnel d'exploitation d'un hyperscaler étranger, ce personnel a la capacité technique (même si c'est interdit par contrat) de modifier les configurations des charges de travail, d'extraire des secrets d'etcd ou de perturber la planification sur instruction de son gouvernement d'origine.

Une conception de plan de contrôle national place tous ces composants sur une infrastructure physiquement et organisationnellement sous le contrôle du ministère. L'architecture pratique :

Serveur API Kubernetes et etcd. Déployez une distribution Kubernetes auto-gérée — kubeadm pour une flexibilité maximale, k0s pour des opérations simplifiées, ou Talos Linux pour une approche de système d'exploitation immuable — sur du bare-metal ou des machines virtuelles exécutées sur des hyperviseurs contrôlés par le ministère. La grappe etcd exige trois ou cinq nœuds pour le quorum, exécutés sur du matériel dédié non partagé avec les nœuds de charges de travail. Les données etcd doivent être chiffrées au repos via le plugin fournisseur KMS connecté au HSM national. Sauvegardez les instantanés etcd vers un stockage objet national chiffré, avec tests automatisés de restauration.

# Example kube-apiserver flag for national KMS encryption provider
--encryption-provider-config=/etc/kubernetes/encryption-config.yaml

# encryption-config.yaml (excerpt)
resources:
  - resources: [secrets, configmaps]
    providers:
      - kms:
          name: national-hsm-kms
          endpoint: unix:///var/run/kmsplugin/socket.sock
          cachesize: 1000
          timeout: 3s
      - identity: {}

Fournisseur d'identité. Keycloak est le fournisseur d'identité open source standard OIDC/SAML pour les déploiements de cloud souverain. Déployez Keycloak sur une infrastructure nationale dédiée, intégré à l'annuaire existant du ministère (Active Directory ou LDAP via les connecteurs de fédération de Keycloak). Configurez le serveur API Kubernetes pour utiliser Keycloak comme authentificateur OIDC :

# kube-apiserver OIDC flags
--oidc-issuer-url=https://keycloak.national.mil/realms/defense
--oidc-client-id=kubernetes
--oidc-username-claim=preferred_username
--oidc-groups-claim=groups
--oidc-ca-file=/etc/kubernetes/pki/keycloak-ca.crt

La disponibilité de Keycloak est désormais sur le chemin critique de l'authentification de la grappe. Déployez en mode haute disponibilité (au minimum trois instances Keycloak derrière un répartiteur de charge interne, avec un cache distribué pour l'état des sessions) et documentez la procédure d'urgence break-glass pour l'accès au serveur API lorsque Keycloak est indisponible — typiquement un kubeconfig local avec un certificat client pour un accès d'administrateur de grappe d'urgence, conservé dans un lieu physiquement sécurisé.

Gestion des secrets. HashiCorp Vault (ou sa fourche open source OpenBao), déployé sur une infrastructure nationale, fournit la couche de gestion des secrets. Vault se déverrouille automatiquement via le HSM national, éliminant le processus de déverrouillage manuel qui serait sinon un point de défaillance unique pour la reprise du plan de contrôle. Le journal d'audit de Vault — chaque lecture et écriture de secret — est transmis en temps réel au SIEM national, hors du rayon d'impact d'un déploiement Vault compromis.

4. Évaluation de la dépendance aux hyperscalers

La plupart des environnements cloud des ministères de la Défense utilisent au moins un hyperscaler pour un certain niveau de leur infrastructure — que ce soit pour une topologie souveraine connectée, une zone de reprise après sinistre ou des charges de travail héritées non encore migrées. Comprendre quels composants d'hyperscaler introduisent un risque de souveraineté est essentiel pour décider, composant par composant, entre service géré et exploitation en propre.

Risque de souveraineté élevé — à remplacer ou à exploiter indépendamment :

Plans de contrôle Kubernetes gérés (EKS, AKS, GKE) — le serveur API et etcd sont exploités par le personnel de l'hyperscaler avec un accès privilégié ; remplacer par un Kubernetes auto-géré sur des primitives IaaS
Fournisseurs d'identité gérés (AWS IAM, Azure Active Directory comme IdP principal) — assertions d'identité faisant autorité émises par des services exploités par des acteurs étrangers ; remplacer par Keycloak ou un équivalent sur infrastructure nationale
Magasins de secrets gérés (AWS Secrets Manager, Azure Key Vault avec des HSM contrôlés par l'hyperscaler) — matériel de clé détenu dans des HSM étrangers ; remplacer par un Vault auto-géré sur HSM national
CDN mondiaux et réseaux de périphérie — trafic routé par des points de présence hors du pays ; désactiver ou restreindre aux nœuds de périphérie nationaux uniquement

Risque de souveraineté moyen — acceptable avec des contrôles supplémentaires :

Stockage objet d'hyperscaler dans une zone de disponibilité nationale — acceptable s'il est chiffré avec des clés contrôlées par le ministère depuis un HSM national, avec réplication verrouillée sur les zones nationales
Bases de données gérées d'hyperscaler dans des zones nationales — acceptables pour les données non classifiées si la gestion des clés de chiffrement est nationale, avec réplication inter-régions désactivée
Réseau virtuel d'hyperscaler — VPC, sous-réseaux et groupes de sécurité sont des primitives IaaS à faible risque ; le risque de souveraineté réside dans le plan de contrôle qui les gère, pas dans les primitives elles-mêmes

Risque de souveraineté plus faible :

Calcul IaaS (machines virtuelles) sans infrastructure d'agents gérés — l'hyperscaler fournit le matériel ; le ministère exploite la pile logicielle et contrôle tout le chiffrement
Stockage bloc avec clés gérées par le client depuis un KMS national — l'hyperscaler détient des blocs chiffrés qui ne peuvent pas être déchiffrés sans la clé détenue par le ministère

Le résultat de l'évaluation est une carte des risques au niveau des composants, et non une décision binaire « utiliser l'hyperscaler » ou « ne pas utiliser l'hyperscaler ». La plupart des architectures de cloud souverain conserveront certains composants d'hyperscaler à la couche IaaS, tout en remplaçant les composants du plan de contrôle et d'identité par des alternatives nationales. Pour une vue plus large des modèles de déploiement et de leurs implications de classification, voir notre article sur les modèles de déploiement de cloud classifié.

5. Modèles d'architecture : souverain connecté ou souverain isolé

Deux modèles d'architecture principaux existent pour les déploiements de cloud souverain, avec des profils de coût, de capacités et de complexité opérationnelle nettement différents.

La topologie souveraine connectée utilise une zone de disponibilité du centre de données dans le pays d'un hyperscaler comme couche IaaS, le ministère exploitant son propre plan de contrôle (Kubernetes, Keycloak, Vault) au-dessus des primitives de calcul et de stockage de l'hyperscaler. L'hyperscaler fournit les cycles de renouvellement du matériel, l'exploitation du centre de données et la sécurité physique ; le ministère fournit l'exploitation logicielle, la gestion des clés de chiffrement et tous les composants du plan de contrôle.

Cette topologie donne au ministère accès aux économies d'échelle de l'hyperscaleur, à la fiabilité de son matériel et à ses services gérés de stockage et de base de données (avec les contrôles appropriés), tout en préservant la souveraineté opérationnelle au niveau logiciel. La faille de souveraineté se situe à la couche matérielle physique : les techniciens du centre de données de l'hyperscaleur ont un accès physique aux serveurs, et la chaîne d'approvisionnement de l'hyperscaleur détermine le matériel disponible. Pour la plupart des ministères de la Défense hors des environnements de menace à plus haut risque, c'est un risque résiduel acceptable — à condition que l'architecture de chiffrement et du plan de contrôle fasse en sorte qu'un accès physique au matériel ne donne ni données en clair ni accès au plan de contrôle.

La topologie connectée souveraine permet aussi une capacité de débordement : lorsque l'infrastructure nationale de cloud du ministère atteint sa capacité maximale, les charges de travail peuvent déborder vers la zone de l'hyperscaleur dans le pays, sans franchir de frontières juridictionnelles. Cela en fait le choix pratique pour les ministères qui doivent satisfaire à la fois aux exigences de souveraineté et aux besoins de capacités modernes, sans la dépense d'investissement qu'exigerait le dimensionnement de l'infrastructure nationale pour la charge de pointe.

Le cloud entièrement national supprime totalement la dépendance à l'hyperscaleur. Toute l'infrastructure physique — serveurs, équipements réseau, baies de stockage et le centre de données qui les abrite — est achetée, détenue et exploitée par le ministère ou par une organisation accréditée au niveau national. OpenStack fournit la couche IaaS au-dessus de ce matériel ; Ceph assure le stockage distribué ; Kubernetes assure l'orchestration.

Les compromis sont importants. La dépense d'investissement est nettement plus élevée que pour une topologie connectée souveraine. Les cycles d'acquisition de serveurs et d'équipements réseau sont longs — typiquement 12-24 mois du besoin à la capacité opérationnelle. Le renouvellement du matériel exige de nouveaux cycles d'acquisition. Les besoins en personnel d'exploitation sont bien plus importants : exploiter OpenStack, Ceph, Kubernetes et Keycloak en production exige une équipe possédant une expertise approfondie des quatre composants, très difficile à recruter aux niveaux de rémunération de la fonction publique. Et l'écart de capacités avec les hyperscaleurs se creuse avec le temps, à mesure que ceux-ci investissent massivement dans les plateformes AI/ML gérées, l'analytique de données et les plateformes serverless.

Le cloud entièrement national est le bon choix pour les charges de travail de classification la plus élevée, les charges avec de strictes exigences d'isolement air-gap (aucune connexion physique ou réseau à une infrastructure commerciale) et les capacités où la souveraineté de la chaîne d'approvisionnement au niveau matériel est une exigence ferme. Ce n'est pas le bon choix pour le portefeuille général de charges de travail d'un ministère de la Défense moderne — la complexité opérationnelle et l'écart de capacités coûtent trop cher pour des exigences de souveraineté qu'une topologie connectée souveraine bien conçue peut satisfaire.

6. Pile souveraine open source

La pile open source souveraine de référence pour la défense repose sur quatre composants qui fournissent ensemble la plateforme complète d'IaaS, de stockage, d'orchestration et d'identité, sans dépendance propriétaire et avec un code source entièrement auditable.

OpenStack est la couche IaaS : Nova pour le calcul, Neutron pour le réseau virtuel, Cinder pour le stockage en mode bloc, Swift pour le stockage objet, Glance pour la gestion des images, Keystone pour l'identité et le catalogue de services. OpenStack compte 15 ans d'historique en production dans les environnements télécom, gouvernementaux et de calcul scientifique. La complexité opérationnelle est réelle — les déploiements OpenStack exigent une équipe plateforme dédiée et une gestion des changements rigoureuse — mais l'écosystème d'opérateurs, d'intégrateurs et de documentation est mature. L'outillage de déploiement Kolla-Ansible rend le déploiement initial maîtrisable ; le défi opérationnel permanent est la gestion des montées de version, à planifier soigneusement dans un environnement de défense où les processus de contrôle des changements sont lents.

Ceph est le backend de stockage distribué. Il fournit le stockage en mode bloc (RBD) pour les volumes Cinder, le stockage objet (RGW) pour les API compatibles Swift et un système de fichiers partagé (CephFS) pour les charges de travail exigeant la sémantique POSIX. L'architecture de Ceph répartit les données sur tous les nœuds du cluster avec des facteurs de réplication configurables, offrant une résilience aux pannes de nœud ou de disque individuels sans baies de stockage propriétaires. La complexité opérationnelle porte sur le réglage des performances — Ceph exige une sélection matérielle rigoureuse (SSD NVMe pour les journaux des OSD, réseau à haute bande passante entre les nœuds) et une surveillance continue des performances pour éviter les cascades d'« OSD lent » qui peuvent dégrader les performances du cluster sous forte charge d'écriture.

Keycloak est le fournisseur d'identité. Il prend en charge OIDC, SAML 2.0, OAuth 2.0 et la fédération LDAP/AD, ce qui en fait le point d'intégration de toute l'authentification dans la pile souveraine : authentification du serveur API Kubernetes, fédération d'identité OpenStack Keystone, authentification JWT de Vault et authentification des utilisateurs. L'interface d'administration et l'API REST de Keycloak fournissent les outils opérationnels de gestion des utilisateurs, des groupes et des clients (applications). Le modèle de déploiement à haute disponibilité — plusieurs instances Keycloak partageant un cache distribué Infinispan et une base de données PostgreSQL commune — est bien documenté et éprouvé en production.

Kubernetes est la couche d'orchestration de conteneurs. Déployé avec kubeadm ou Talos Linux sur des instances de calcul OpenStack Nova, Kubernetes fournit la couche d'ordonnancement des charges de travail, de découverte de services et de gestion de configuration que consomment les équipes applicatives. L'exigence architecturale clé pour la pile souveraine est que la distribution Kubernetes soit compatible amont — pas une variante gérée d'hyperscaleur — afin que le plan de contrôle reste sous le contrôle du ministère. Pour le réseau de conteneurs, Cilium est le CNI préféré en environnement de défense grâce à son application des politiques fondée sur eBPF et son observabilité profonde sans proxy sidecar. Pour l'intégration du stockage, le pilote Ceph CSI assure la liaison entre les PersistentVolumes Kubernetes et Ceph RBD.

Il ne faut pas sous-estimer la complexité opérationnelle de cette pile. Exploiter OpenStack, Ceph, Kubernetes et Keycloak en production exige une expertise spécialisée sur les quatre composants, difficile à recruter et à retenir dans les organisations gouvernementales. Réalistement, un ministère qui déploie cette pile a besoin soit d'une grande équipe plateforme interne (20+ ingénieurs pour un déploiement d'échelle moyenne), soit d'un intégrateur souverain sous contrat disposant d'une expertise approfondie des quatre composants. L'alternative — réduire la complexité opérationnelle en adoptant un service géré d'hyperscaleur pour certains composants — doit être évaluée au regard des exigences de souveraineté qu'elle compromet. Pour les contrôles de sécurité qui doivent s'exécuter au-dessus de cette pile, voir notre article sur le CSPM pour le cloud de défense.

7. Concilier souveraineté et capacités modernes du cloud

Le problème architectural le plus difficile du cloud souverain pour un ministère de la Défense n'est pas les contrôles de souveraineté eux-mêmes — c'est de maintenir ces contrôles tout en fournissant les capacités de cloud modernes que les organisations de défense exigent de plus en plus : entraînement et inférence de modèles AI/ML, analytique de données en temps réel, architectures événementielles serverless et plateformes de collaboration mondiales. Les hyperscaleurs ont investi des milliards dans des versions gérées de ces capacités que la pile souveraine open source ne peut pas égaler à l'horizon d'une décennie.

La portabilité de l'IaC par l'abstraction des fournisseurs Terraform est le mécanisme le plus pratique pour gérer cette tension. La stratégie consiste à définir toute l'infrastructure dans des modules Terraform indépendants du fournisseur — des abstractions internes qui acceptent des entrées cohérentes et produisent des sorties cohérentes, que le fournisseur sous-jacent soit OpenStack, AWS ou Azure. L'interface du module d'un « cluster de calcul » est la même qu'il se déploie sur OpenStack Nova ou sur AWS EC2 ; seule la liaison au fournisseur change. Cette abstraction préserve la possibilité de migrer des charges de travail entre la pile nationale souveraine et une zone hyperscaleur connectée souveraine sans réarchitecturer l'infrastructure applicative.

# Example provider-agnostic compute module interface
module "compute_cluster" {
  source        = "internal/modules/compute-cluster"
  name          = "sensor-processing"
  instance_type = "c5.4xlarge"  # resolved per provider
  count         = 3
  subnet_id     = module.network.private_subnet_id
  security_groups = [module.security.workload_sg_id]
  user_data     = file("cloud-init/sensor-processor.yaml")
}

# Bind to provider via workspace variable
# terraform.tfvars.national:  provider = "openstack"
# terraform.tfvars.govcloud:  provider = "aws-govcloud"

Alternatives aux services gérés pour les écarts de capacités les plus stratégiques :

Entraînement AI/ML : clusters GPU sur site exécutant Kubeflow ou MLflow, acquis auprès de fournisseurs à la posture de chaîne d'approvisionnement acceptable ; débordement connecté souverain vers des instances GPU de l'hyperscaleur dans le pays pour les travaux d'entraînement qui dépassent la capacité sur site
Analytique de données : Apache Spark sur Kubernetes (via l'opérateur Spark) remplace les services d'analytique gérés ; ClickHouse ou Apache Druid pour les charges de requêtes analytiques en temps réel
Base de données gérées : les opérateurs pour PostgreSQL (CloudNativePG), Redis (Redis Operator) et Kafka (Strimzi) offrent une expérience opérationnelle proche d'un service géré sur un Kubernetes auto-géré
Observabilité : Prometheus, Loki et Grafana fournissent la pile de métriques, de journalisation et de visualisation, sans dépendance propriétaire d'observabilité gérée

La feuille de route des capacités du cloud souverain doit être traitée comme un programme vivant, pas comme un déploiement unique. L'écart entre les capacités de la pile souveraine et les services gérés des hyperscaleurs est réel mais non statique — l'écosystème open source produit en continu de nouvelles alternatives souveraines aux services gérés propriétaires. Une revue structurée des capacités tous les six mois — comparant les capacités actuelles de la pile souveraine aux exigences opérationnelles actuelles et aux alternatives actuelles des hyperscaleurs — permet au ministère de hiérarchiser les écarts à combler par l'adoption open source, ceux à combler par un accès connecté souverain aux services de l'hyperscaleur dans le pays, et ceux à accepter comme contraintes résiduelles de capacités en échange de garanties de souveraineté.

Constat clé : le cloud souverain pour les ministères de la Défense n'est pas un produit que l'on peut acheter — c'est une posture architecturale qu'il faut concevoir, construire, exploiter et maintenir en continu. Les ministères qui réussissent traitent la souveraineté comme une exigence d'ingénierie de premier plan, au même titre que la performance, la fiabilité et le coût, arbitrent explicitement entre dimensions de souveraineté et capacité, et construisent la compétence opérationnelle nécessaire pour exploiter la pile souveraine avec une qualité de production. Ceux qui la traitent comme une simple case de conformité — en acquérant une certification « cloud souverain » d'un fournisseur sans évaluer si les contrôles techniques délivrent réellement la localisation des données, la souveraineté opérationnelle et la souveraineté de la chaîne d'approvisionnement — découvriront l'écart le jour où une rupture géopolitique ou un changement de politique du fournisseur l'exposera.

Le cloud souverain pour les ministères de la Défense est en définitive une décision de gestion des risques, pas une décision technologique. L'architecture décrite ici — plan de contrôle national, contrôles techniques de localisation des données, pile souveraine open source, abstraction des fournisseurs Terraform pour la portabilité — est un ensemble d'outils pour gérer un ensemble spécifique de risques. La bonne architecture pour un ministère donné dépend des risques les plus significatifs dans son environnement de menace, de la capacité opérationnelle réalistement maintenable avec le personnel et le budget disponibles, et de l'endroit où ses exigences de charges de travail classifiées se situent sur la courbe d'arbitrage souveraineté-capacité. Réussir ce calibrage exige une évaluation honnête des menaces et un jugement d'ingénierie — pas l'assurance d'un fournisseur.

Discutez de votre projet

Nous concevons et construisons des architectures de cloud souverain pour les ministères de la Défense — du déploiement du plan de contrôle national et de l'application de la localisation des données à l'exploitation de la pile open source et à la portabilité de l'IaC.

Services de cloud sécurisé → Réserver un briefing

Cette analyse a été préparée par les ingénieurs de Corvus Intelligence qui développent des logiciels critiques pour les organisations de défense et gouvernementales. En savoir plus sur notre équipe →

Questions fréquentes

Qu'est-ce que la souveraineté du cloud pour un ministère de la Défense ?

La souveraineté du cloud pour un ministère de la Défense couvre trois exigences distinctes mais liées. La résidence des données est la garantie juridique et technique que les données classifiées ou sensibles sont stockées, traitées et transmises exclusivement sur le territoire national ou dans des juridictions approuvées — et que le ministère, et non un fournisseur, contrôle les clés de chiffrement. La souveraineté opérationnelle est la capacité à continuer d'exploiter la plateforme cloud indépendamment de la coopération continue d'un fournisseur étranger, de ses licences ou de la disponibilité de son service, y compris la capacité de survivre à des sanctions, à la faillite du fournisseur ou à une rupture géopolitique. La souveraineté de la chaîne d'approvisionnement est le contrôle des composants logiciels et matériels utilisés pour construire et exploiter le cloud — garantissant qu'aucun gouvernement étranger ne puisse contraindre un fournisseur à insérer des portes dérobées ou à refuser le service. Un cloud réellement souverain pour la défense doit traiter les trois dimensions simultanément ; les choix d'architecture qui satisfont la résidence des données mais sacrifient la souveraineté opérationnelle ou celle de la chaîne d'approvisionnement offrent une protection plus faible qu'il n'y paraît sur le papier.

Qu'est-ce que l'application de la localisation des données dans un contexte de cloud de défense ?

L'application de la résidence des données dans un cloud de défense signifie mettre en œuvre des contrôles techniques qui rendent physiquement et cryptographiquement impossible — et pas simplement interdit par contrat — que les données sortent de la limite géographique ou juridictionnelle définie. Les couches clés sont : la résidence des clés de chiffrement (le HSM ou le KMS détenant les clés de chiffrement des données doit être physiquement situé dans le pays et sous contrôle national, de sorte que les données chiffrées avec ces clés ne puissent pas être déchiffrées hors de la limite, même en cas d'exfiltration physique) ; les politiques de localisation des données appliquées à la couche de stockage (le stockage objet, les volumes bloc et les répliques de base de données doivent être contraints aux zones de disponibilité nationales) ; les contrôles du trafic réseau sortant (règles de pare-feu et politiques DNS qui bloquent les chemins de données vers des points de terminaison hors du pays) ; et l'audit et la vérification (surveillance continue que les contrôles des données au repos et en mouvement n'ont pas été contournés, avec des journaux inviolables examinés par l'équipe des opérations de sécurité du ministère plutôt que par celle du fournisseur).

Qu'est-ce qu'un plan de contrôle national et pourquoi est-il important ?

Le plan de contrôle d'une plateforme cloud est l'ensemble des services qui gèrent l'orchestration des charges de travail, l'identité et les secrets — dans un environnement Kubernetes, ce sont le serveur API, etcd, le planificateur et le gestionnaire de contrôleurs ; dans un contexte cloud plus large, il comprend le fournisseur d'identité, le système de gestion des secrets et les API de gestion. Si le plan de contrôle s'exécute sur une infrastructure gérée par un hyperscaler étranger, le personnel d'exploitation de l'hyperscaler a la capacité — en principe — de modifier les configurations des charges de travail, d'extraire des secrets ou de perturber les opérations sur instruction de son gouvernement d'origine. Un plan de contrôle national exécute ces composants sur une infrastructure physiquement et organisationnellement sous le contrôle du ministère, éliminant cette dépendance. Même en utilisant un centre de données de l'hyperscaler dans le pays, un plan de contrôle national signifie que le serveur API Kubernetes, la grappe etcd et le fournisseur d'identité s'exécutent sur du matériel possédé ou contrôlé par le ministère, l'hyperscaler ne fournissant que les primitives de calcul, de réseau et de stockage.

Quels composants d'hyperscaleur introduisent le plus grand risque de souveraineté ?

Les composants d'hyperscaler les plus à risque pour un ministère de la Défense sont : les plans de contrôle Kubernetes gérés (EKS, AKS, GKE), où le serveur API et etcd s'exécutent sur l'infrastructure de l'hyperscaler et où son personnel d'exploitation dispose d'un accès privilégié ; les fournisseurs d'identité gérés, où l'assertion d'identité faisant autorité est émise par des services contrôlés par l'hyperscaler ; les couches mondiales de CDN et de mise en cache en périphérie, qui routent le trafic par des points de présence hors du pays ; les fonctions de réplication inter-régions, qui peuvent copier des données vers des zones de disponibilité hors de la juridiction approuvée ; et les magasins de secrets gérés dont le matériel de clé est en fin de compte détenu dans des HSM contrôlés par l'hyperscaler. Les composants IaaS d'hyperscaler — calcul brut, stockage bloc et réseau virtuel sans plan de contrôle géré — introduisent un risque de souveraineté nettement moindre, car le ministère exploite la pile logicielle au-dessus d'eux et contrôle toutes les clés de chiffrement indépendamment.

Quelle est la différence entre cloud connecté souverain et cloud entièrement national ?

La topologie souveraine connectée utilise un centre de données de l'hyperscaler dans le pays avec un plan de contrôle contrôlé par le ministère exécuté au-dessus. L'hyperscaler fournit l'IaaS — calcul, stockage, réseau — mais toutes les couches d'orchestration, d'identité et de gestion des secrets sont exploitées par le ministère ou un intégrateur national de confiance. Cela donne accès aux économies d'échelle et aux services gérés de l'hyperscaler, au prix d'une dépendance continue à l'exploitation du matériel et à la chaîne d'approvisionnement de l'hyperscaler. Un cloud pleinement national élimine entièrement la dépendance à l'hyperscaler — toute l'infrastructure physique est acquise, possédée et exploitée par le ministère ou un fournisseur souverain national. Les arbitrages sont des dépenses d'investissement nettement plus élevées, des cycles d'acquisition plus longs, une complexité opérationnelle accrue et un écart de capacités par rapport aux services gérés des hyperscalers — mais une souveraineté opérationnelle et de chaîne d'approvisionnement maximale.

Quels composants open source forment le cœur d'une pile de cloud souverain ?

La pile canonique de cloud souverain open source se compose de : OpenStack pour l'IaaS (calcul via Nova, stockage objet via Swift, stockage bloc via Cinder, réseau via Neutron, gestion des images via Glance, identité via Keystone) ; Ceph comme couche de stockage distribué soutenant les volumes Cinder et le stockage objet Swift d'OpenStack ; Kubernetes comme couche d'orchestration de conteneurs déployée avec une distribution amont (et non une variante gérée d'hyperscaler), afin que le serveur API et etcd restent sous contrôle du ministère ; et Keycloak comme fournisseur d'identité, tant pour les utilisateurs humains (via OpenID Connect et SAML) que pour les charges de travail (via les identifiants client OAuth 2.0). Ensemble, ces quatre composants fournissent la pile complète de plateforme cloud sans dépendance propriétaire. La complexité opérationnelle est substantiellement plus élevée que celle des services gérés d'hyperscaler, et le ministère doit maintenir l'expertise nécessaire pour exploiter et corriger chaque composant — mais les garanties de souveraineté sont absolues, car le code source de chaque composant est auditable et aucun fournisseur étranger n'a d'accès opérationnel privilégié.

Comment Terraform favorise-t-il la portabilité entre environnements de cloud souverain ?

L'abstraction de fournisseur de Terraform permet de décrire l'infrastructure dans des modules indépendants du fournisseur, les implémentations spécifiques étant échangées au niveau du module racine. Un modèle de portabilité de cloud souverain définit des interfaces de modules internes — un module de grappe de calcul, un module de base de données gérée, un module de compartiment de stockage objet — qui acceptent les mêmes entrées et produisent les mêmes sorties, que le fournisseur sous-jacent soit un déploiement OpenStack, un fournisseur de cloud national ou une zone dans le pays d'un hyperscaler. Lorsque le ministère doit migrer d'une plateforme sous-jacente vers une autre en raison du risque fournisseur, d'un changement réglementaire ou de l'évolution des capacités, seule la liaison au fournisseur change — les définitions de modules de charges de travail, les pipelines de déploiement et les tests d'infrastructure restent inchangés. La limite pratique de cette portabilité réside dans les services gérés : un module qui encapsule un service de base de données géré propre à un hyperscaler ne peut pas être porté trivialement vers OpenStack sans remplacer le service sous-jacent par un déploiement équivalent géré en interne.

Quels sont les risques majeurs du cloud souverain pour un ministère de la Défense ?

Les risques principaux sont : l'écart de capacités (les fournisseurs de cloud nationaux et les piles open source accusent souvent plusieurs années de retard sur les hyperscalers en services gérés d'IA/ML, plateformes sans serveur et performances réseau mondiales — ce qui contraint la feuille de route de capacités modernes) ; la complexité opérationnelle (exploiter en interne OpenStack, Ceph, Kubernetes et Keycloak exige une expertise profonde, difficile à recruter et à retenir dans l'administration) ; le risque de chaîne d'approvisionnement matériel (serveurs, équipements réseau et matériel de stockage provenant de fournisseurs non nationaux portent leurs propres risques de souveraineté de chaîne d'approvisionnement — même un cloud pleinement national peut être compromis à la couche matérielle) ; et la fausse souveraineté (un cloud qui satisfait la résidence des données sur le papier, mais dont le personnel d'exploitation de l'hyperscaler dispose d'un accès privilégié, ou qui utilise des HSM étrangers pour la gestion des clés, offre des garanties plus faibles que sa documentation d'architecture ne le suggère). La gestion du risque exige de traiter la souveraineté comme un spectre à dimensions multiples, vérifiables indépendamment, plutôt que comme une certification binaire.

Comment séparer les charges de travail classifiées et non classifiées dans un cloud souverain ?

Les charges de travail classifiées et non classifiées doivent être séparées à la couche physique — des grappes Kubernetes distinctes exécutées sur des pools de nœuds séparés, sans etcd partagé, sans plan de contrôle partagé et sans infrastructure réseau partagée entre les niveaux de classification. La séparation logique au sein d'une seule grappe (isolation d'espaces de noms, NetworkPolicy) est insuffisante pour des charges de travail de niveaux de classification différents, car une vulnérabilité du plan de contrôle ou une évasion de conteneur peut franchir les frontières des espaces de noms. En pratique, cela signifie des locataires OpenStack distincts avec des grappes de stockage Ceph physiquement séparées pour chaque niveau de classification, des realm Keycloak distincts ou des fournisseurs d'identité entièrement séparés, et des pipelines CI/CD distincts avec des clés de signature séparées, afin qu'une compromission du pipeline non classifié ne puisse pas introduire d'images malveillantes dans le niveau classifié. Le transfert de données entre niveaux doit passer par une solution inter-domaines formellement évaluée, et non par une connectivité réseau.

À quoi devrait ressembler la feuille de route des capacités de cloud souverain d'un ministère de la Défense ?

Une feuille de route réaliste de capacités de cloud souverain pour un ministère de la Défense comporte trois phases. La phase 1 (années 1-2) établit les fondations : déployer la couche IaaS nationale (OpenStack ou équivalent), migrer les charges de travail du cloud commercial vers l'infrastructure nationale, mettre en œuvre les contrôles de résidence des données et la gestion nationale des clés, et déployer le plan de contrôle Kubernetes national. La phase 2 (années 2-4) construit la couche plateforme : déployer Keycloak pour l'identité fédérée, mettre en œuvre l'IaC fondé sur Terraform avec abstraction de fournisseur, construire un registre interne de conteneurs avec des contrôles de chaîne d'approvisionnement (signature d'images, analyse de vulnérabilités) et établir une topologie souveraine connectée avec une zone dans le pays d'un hyperscaler pour la capacité de pointe et la résilience. La phase 3 (années 4+) vise la parité de capacités : construire ou acquérir des services souverains de bases de données gérées et d'analytique, déployer une infrastructure d'entraînement IA/ML sur site, mettre en œuvre une architecture zéro confiance sur tous les niveaux et établir un cadre d'automatisation de conformité continue couvrant tous les composants de la pile souveraine.

Quelle est la différence entre un cloud souverain connecté et un cloud pleinement national ?

À quoi devrait ressembler la feuille de route de capacités d'un ministère de la Défense pour le cloud souverain ?