Un cloud souverain est une infrastructure dont vous conservez le contrôle juridique, opérationnel et technique sur vos données et vos systèmes, au lieu de louer ce contrôle à un tiers. Les données résident là où vous le décidez, vous détenez les clés de chiffrement, et aucune juridiction étrangère ne peut accéder discrètement à vos systèmes. Pour les organisations en Europe, et en Allemagne tout particulièrement, ce sujet est passé du statut de simple avantage à celui d’exigence au niveau du conseil d’administration, sous l’impulsion du GDPR, de NIS2, de DORA et de la portée du CLOUD Act américain.
La bonne nouvelle : il n’existe aucun produit de cloud souverain unique et « correct » à acheter. Un cloud privé souverain peut se construire de multiples façons, presque entièrement à partir de logiciels open source et de standards ouverts. Ce guide explique ce que recouvre réellement ce terme, puis parcourt l’éventail concret des manières d’en bâtir un, afin que vous puissiez adapter l’approche à vos charges de travail plutôt qu’au discours marketing d’un fournisseur.
Ce que « souverain » signifie réellement
La résidence des données (l’emplacement physique des octets) n’en est qu’une composante. La véritable souveraineté numérique superpose plusieurs éléments :
- Contrôle juridictionnel - vos données restent hors de portée du droit étranger, en cohérence avec les régimes de l’UE comme le GDPR, NIS2, DORA et l’EU Data Act.
- Contrôle des clés - vous détenez les clés de chiffrement (BYOK, ou intégralement HYOK), et non l’opérateur de la plateforme.
- Contrôle opérationnel - vous décidez qui peut accéder à l’environnement, le modifier et l’auditer.
- Portabilité - des interfaces ouvertes et standard (API Kubernetes, OCI, S3) vous permettent de partir ou de migrer sans réécriture.
- Transparence - des composants open source que vous pouvez inspecter, ainsi qu’un confidential computing optionnel (Intel TDX, AMD SEV-SNP) pour la protection à l’exécution.
Des cadres à connaître lorsque vous cadrez un projet : Gaia-X et les labels de son Trust Framework, le futur schéma de certification EUCS de l’ENISA, le catalogue BSI C5 allemand et le Sovereign Cloud Stack (SCS) porté par la communauté. Ils vous donnent un vocabulaire commun avec les auditeurs et les services achats.
La grande idée fausse
Un mythe répandu veut que « cloud privé rime avec OpenStack » ou qu’« il vous faut Proxmox ». Ni l’un ni l’autre n’est vrai. Le cloud privé et l’IaaS sont des catégories, pas des produits. La bonne question n’est pas quel outil, mais quel plan de contrôle convient à votre échelle, à votre équipe et à votre posture de conformité. Il existe au moins trois architectures crédibles, et un cloud souverain peut reposer sur n’importe laquelle d’entre elles.
Voie 1 : un plan de contrôle IaaS complet
C’est le modèle classique « construisez votre propre cloud » : un plan de contrôle abstrait des ressources mutualisées de calcul, de stockage et de réseau en une infrastructure multi-tenant en libre-service, dotée d’API, de quotas et d’une gestion de la tenance. Il convient aux grands parcs, aux fournisseurs de services et aux équipes qui ont réellement besoin d’une élasticité de type cloud sur leur propre matériel.
Les options open source de cette catégorie comprennent :
- OpenStack - le plan de contrôle IaaS le plus complet, désormais sous l’égide de l’OpenInfra Foundation (qui a rejoint la Linux Foundation en 2025). La colonne vertébrale de nombreux clouds souverains européens.
- Apache CloudStack - un IaaS mature et plus simple à exploiter, issu de l’Apache Software Foundation.
- OpenNebula - léger, bien adapté à l’edge et aux clouds privés de taille moyenne.
- Sovereign Cloud Stack (SCS) - des standards ouverts et une implémentation de référence conçus spécifiquement pour la souveraineté, souvent superposés à OpenStack et Kubernetes.
OpenStack est fréquemment la principale alternative à VMware pour les organisations qui veulent un IaaS complet sans verrouillage lié aux licences.
Voie 2 : un hyperviseur ou une pile HCI
Si vous exécutez principalement des machines virtuelles et privilégiez la simplicité opérationnelle plutôt que l’élasticité à grande échelle, un hyperviseur ou une pile hyperconvergée est souvent le meilleur choix. Ils vous offrent le cycle de vie des VM, le clustering et le stockage sans le poids opérationnel d’un plan de contrôle IaaS complet.
- Proxmox VE - plateforme de virtualisation et HCI open source extrêmement populaire, KVM et LXC, de plus en plus utilisée en remplacement de VMware.
- oVirt - la source amont de la gestion de virtualisation d’entreprise, basée sur KVM.
- XCP-ng - l’hyperviseur ouvert fondé sur Xen (XAPI), une alternative directe pour les utilisateurs de Citrix Hypervisor.
- Harvester - HCI bâtie sur Kubernetes et KubeVirt, faisant le pont avec la Voie 3.
Sous toutes ces solutions reposent les mêmes fondations Linux : KVM et libvirt pour les piles basées sur KVM, le Xen Project pour XCP-ng, et Ceph comme couche de stockage défini par logiciel de prédilection.
Voie 3 : du Kubernetes-native, où Kubernetes est le cloud
Un modèle de plus en plus répandu consiste à se passer entièrement d’une couche IaaS traditionnelle et à faire de Kubernetes lui-même le cloud. Les conteneurs sont l’unité principale, et les VM s’exécutent au sein de Kubernetes lorsque c’est nécessaire. Cela convient aux organisations cloud-native et aux équipes de platform engineering.
- KubeVirt - exécute les VM comme des charges de travail Kubernetes de premier rang, aux côtés des conteneurs.
- OpenShift Virtualization (et sa source amont OKD Virtualization) - distribution d’entreprise de la même idée.
- Cluster API (CAPI) - cycle de vie déclaratif des clusters, traitant les clusters eux-mêmes comme des ressources gérées.
- Harvester, Incus - options de HCI et de conteneurs système qui complètent ce modèle.
Ici, le « plan de contrôle » est l’API Kubernetes elle-même, l’écosystème CNCF plus large (Cilium pour le réseau, Rook/Ceph ou Longhorn pour le stockage, OpenBao ou Vault pour les secrets) venant compléter le reste.
Choisir entre ces voies
Il n’y a pas de gagnant universel. À titre indicatif :
- Grand parc multi-tenant ou échelle de fournisseur de services : penchez vers OpenStack / CloudStack / SCS (Voie 1).
- Charges de travail centrées sur les VM, équipe plus réduite, mise en valeur rapide : penchez vers Proxmox VE / oVirt / XCP-ng (Voie 2).
- Culture cloud-native, container-first, platform engineering : penchez vers une approche Kubernetes-native KubeVirt / Harvester (Voie 3).
- De nombreux environnements réels sont hybrides, par exemple OpenStack pour l’IaaS avec Kubernetes par-dessus.
Les couches autour du plan de contrôle
Quelle que soit la voie choisie, la souveraineté dépend des couches de support, et celles-ci sont elles aussi open-source-first :
- Stockage : Ceph, Rook, Longhorn, MinIO (compatible S3) - vos données, sur votre matériel, via CSI et l’API S3.
- Réseau et sécurité : Cilium (eBPF), Calico, WireGuard, ainsi qu’une identité zero-trust avec SPIFFE/SPIRE et mTLS.
- Secrets et clés : OpenBao ou HashiCorp Vault pour le BYOK/HYOK.
- Infrastructure as Code : OpenTofu, Terraform, Pulumi, Crossplane, Ansible et Nix, pour que l’ensemble de la plateforme soit reproductible et auditable.
- GitOps et déploiement : Argo CD ou Flux, avec Tekton, GitHub Actions, GitLab CI ou Jenkins pour les builds.
- Observabilité : OpenTelemetry, Prometheus et la pile Grafana LGTM, le tout sur des standards ouverts pour que la télémétrie reste portable.
Ces standards ouverts (API Kubernetes, OCI, CSI/CNI, OpenTelemetry, S3) sont ce qui maintient un cloud souverain véritablement portable plutôt qu’une nouvelle variante de verrouillage.
FAQ
Le cloud souverain équivaut-il à la résidence des données ?
Non. La résidence des données signifie que vos données se trouvent dans une région choisie. La souveraineté y ajoute le contrôle des clés, le contrôle opérationnel, la protection juridictionnelle et la portabilité.
Dois-je faire tourner OpenStack pour être souverain ?
Non. OpenStack est une excellente option, mais Apache CloudStack, OpenNebula, Proxmox VE, oVirt, XCP-ng et les piles Kubernetes-native (KubeVirt, Harvester) peuvent tous servir de socle à un cloud souverain.
L’open source est-il réellement sûr pour cela ?
Oui, et c’est généralement le choix le plus sûr pour la souveraineté. L’open source est inspectable, évite le verrouillage fournisseur et bénéficie d’une gouvernance neutre (Linux Foundation, CNCF, OpenInfra, Apache).
Puis-je exécuter de l’IA privée dans un cloud souverain ?
Oui. L’inférence auto-hébergée (vLLM, Ollama, llama.cpp) avec des bases vectorielles (pgvector, Qdrant) et la suppression des données personnelles (Presidio) vous permet d’exécuter des LLM privés et du RAG sans que les prompts et les poids ne quittent jamais votre environnement.
Où se situe le confidential computing ?
Intel TDX et AMD SEV-SNP protègent les données en cours d’utilisation, de sorte que même l’opérateur de la plateforme ne peut lire la mémoire des charges de travail. Utile pour les charges de travail exigeant le plus haut niveau d’assurance.
Construisez-le avec le bon partenaire
Un cloud souverain est une décision d’architecture, pas l’achat d’un produit, et le plus difficile consiste à adapter l’approche à vos charges de travail, à votre échelle et à vos obligations de conformité. Rapid Solutions est un cabinet de conseil en ingénierie et de services managés (et non un fournisseur de cloud), avec des bureaux à Amsterdam et Dubaï. Nous concevons et exploitons des clouds privés souverains sur l’ensemble de l’écosystème open source, OpenStack et CloudStack, Proxmox VE et Harvester, ou du Kubernetes-native KubeVirt, avec une résidence des données dans l’UE disponible comme capacité, et un principe simple de bout en bout : vos données, vos clés, votre contrôle.
Que vous souhaitiez construire de zéro ou nous confier la gestion souveraine de ce que vous exploitez déjà, contactez Rapid Solutions pour cadrer la bonne approche.