TL;DR

• L’appel d’offres de €180 millions de la Commission européenne d’avril 2026 sur le cloud souverain (IP/26/833) a codifié un Cloud Sovereignty Framework autour de huit dimensions techniques : souveraineté stratégique, juridique, opérationnelle, environnementale, transparence de la chaîne d’approvisionnement, ouverture technologique, sécurité et conformité au droit européen. Chaque dimension correspond à une décision concrète d’ingénierie de plateforme, pas à une case à cocher dans un appel d’offres.
• La résidence des données (où se trouve le matériel) et la souveraineté des données (qui peut contraindre l’accès) ne sont pas la même chose. Une région AWS à Francfort ne vous isole pas d’une demande au titre du CLOUD Act américain. Les équipes platform qui construisent pour des charges de travail couvertes par DORA ou NIS2 doivent concevoir autour des contrôles d’accès juridictionnels, pas seulement de la géographie.
• Gartner prévoit que les dépenses mondiales IaaS de cloud souverain atteindront 80 milliards de dollars en 2026, soit une augmentation de 35,6 % par rapport à 2025, l’Europe progressant de 83 % pour atteindre 12,6 milliards de dollars, avant de dépasser entièrement l’Amérique du Nord en 2027 — signal de marché indiquant que la souveraineté est un changement structurel, pas un cycle réglementaire.
• Le plan de contrôle de l’IDP est l’endroit où la souveraineté s’effondre en pratique. Quand les développeurs s’auto-servent via une plateforme SaaS dont le plan de contrôle se trouve en dehors de la juridiction européenne, les métadonnées de provisionnement, les journaux d’identité et les enregistrements d’approbation quittent tous le périmètre réglementé, même si l’infrastructure déployée ne le fait pas.
• Une infrastructure as code portable, GitOps-first, constitue la couverture pratique contre l’évolution des exigences de souveraineté. Quand le CADA arrive avec de nouveaux critères d’éligibilité, les organisations disposant d’IaC dans des backends d’état auto-contrôlés peuvent migrer de fournisseur sans reconstruire leur pipeline de livraison.
• Toutes les charges de travail d’une organisation réglementée n’ont pas besoin d’une infrastructure souveraine. La bonne réponse d’ingénierie est une matrice de classification des charges de travail : les données personnelles et les services couverts par DORA vont sur infrastructure souveraine ; les charges de travail non réglementées peuvent rester sur les hyperscalers, à condition que les flux de données entre environnements soient audités et contrôlés au niveau de la plateforme.

Ce que la souveraineté cloud signifie pour les équipes platform

La souveraineté cloud est la capacité à contrôler où l’infrastructure s’exécute, qui peut y accéder, quelle juridiction légale la régit et si des entités externes peuvent contraindre l’accès aux données, aux métadonnées, aux clés de chiffrement ou aux systèmes opérationnels. Pour les équipes platform, cela cesse très vite d’être une discussion juridique. Cela devient un problème de conception d’infrastructure impliquant les systèmes d’identité, la gestion des clés, les pipelines de déploiement, les pistes d’audit et les dépendances aux fournisseurs.

Une charge de travail s’exécutant dans une région de Francfort n’est pas automatiquement souveraine. Si le fournisseur cloud, l’organisation de support, le plan de contrôle ou la hiérarchie de chiffrement reste soumis à une juridiction étrangère, les régulateurs peuvent toujours considérer l’environnement comme exposé extérieurement. C’est la distinction que beaucoup d’équipes ratent lors de l’adoption initiale du cloud : la résidence des données répond seulement à la question de l’emplacement du matériel, tandis que la souveraineté demande aussi qui contrôle finalement l’accès à l’environnement et dans quel cadre juridique.

Cela est important parce que les plateformes internes de développement (IDP) modernes, les pipelines CI/CD et les systèmes d’infrastructure as code (IaC) échangent continuellement des métadonnées opérationnelles en dehors de la charge de travail elle-même. Les approbations de déploiement, les fichiers d’état Terraform, les journaux d’audit, les événements RBAC et les pipelines GitOps traversent souvent des systèmes exploités par des éditeurs SaaS tiers. Dans les secteurs réglementés couverts par DORA, NIS2, GDPR ou les règles d’achat du secteur public, ces systèmes opérationnels entrent désormais aussi dans le périmètre de conformité.

La conversation en termes d’ingénierie a changé significativement en avril 2026 quand la Commission européenne a attribué un contrat de cloud souverain de €180 millions à quatre fournisseurs européens dans le cadre d’un Cloud Sovereignty Framework formel. Le changement important n’était pas la valeur du contrat elle-même, mais l’introduction de critères d’évaluation techniques mesurables pour la souveraineté. Au lieu de traiter « cloud souverain » comme un langage marketing, le framework évaluait les fournisseurs sur l’indépendance opérationnelle, l’exposition à la juridiction légale, la transparence de la chaîne d’approvisionnement, l’ouverture technologique, les contrôles de gestion des clés et la conformité au droit européen.

Pour les équipes platform, cela transforme la souveraineté d’une préférence d’achat en exigence d’architecture système. Des questions comme l’endroit où est stocké l’état Terraform, qui contrôle les clés de chiffrement, si les journaux d’audit restent dans la juridiction européenne et si les pipelines de déploiement dépendent de plans de contrôle SaaS exploités à l’étranger font désormais partie des revues de conception d’infrastructure plutôt que des discussions de conformité post-déploiement.

Le Cloud Sovereignty Framework de l’UE et ses exigences

Le 17 avril 2026, la Commission européenne a attribué des contrats dans le cadre d’IP/26/833 à quatre fournisseurs cloud européens : Post Telecom (en partenariat avec CleverCloud et OVHcloud), STACKIT, Scaleway et Proximus (en partenariat avec S3NS, une coentreprise Thales-Google Cloud, ainsi que Clarence et Mistral). L’appel d’offres, lancé dans le cadre du Cloud III Dynamic Purchasing System en octobre 2025, permet aux institutions européennes de se procurer des services cloud souverains pour un maximum de €180 millions sur six ans.

Les fournisseurs ont été sélectionnés selon le Cloud Sovereignty Framework de la Commission, qui évalue huit dimensions : la souveraineté stratégique (ancrage financier et juridique dans le droit européen), la souveraineté juridique et juridictionnelle (protection contre l’accès par des autorités étrangères), la souveraineté opérationnelle (capacité à fonctionner indépendamment d’un seul fournisseur), la souveraineté environnementale (conformité en matière de durabilité), la transparence de la chaîne d’approvisionnement (documentation matérielle et logicielle), l’ouverture technologique (utilisation de standards ouverts), la sécurité (respect des niveaux d’assurance EUCS ou équivalents) et la conformité au droit européen (aucune exposition à une juridiction étrangère conflictuelle).

Deux résultats de l’appel d’offres sont particulièrement importants pour les ingénieurs platform. Premièrement, la Commission a évalué le contrôle opérationnel, pas les déclarations marketing. Dans les dimensions juridique, opérationnelle et de transparence de la chaîne d’approvisionnement, les fournisseurs devaient démontrer comment les entités non européennes étaient limitées dans leur accès à l’infrastructure, aux systèmes opérationnels, aux hiérarchies de chiffrement et aux environnements clients. Cela incluait l’examen de la propriété de la gestion des clés, des contrôles d’accès du personnel, des chemins d’escalade opérationnelle et de la documentation des dépendances d’infrastructure. En pratique, la souveraineté a été traitée comme une propriété système vérifiable plutôt qu’une déclaration contractuelle.

Deuxièmement, l’appel d’offres a montré que la souveraineté n’exclut pas automatiquement les stacks technologiques non européennes. Dans les dimensions de souveraineté opérationnelle et de conformité au droit européen, les fournisseurs pouvaient se qualifier si la frontière de contrôle opérationnel restait dans la juridiction européenne. Proximus, par exemple, s’est qualifié en partie grâce à son partenariat S3NS, où l’infrastructure Google Cloud fonctionne derrière une gestion des clés contrôlée par l’UE, un personnel opérationnel résidant dans l’UE et des procédures d’accès gouvernées localement. Pour les équipes platform qui exécutent déjà des charges de travail sur AWS, Azure ou GCP, cela change significativement la discussion sur la migration. Le facteur décisif n’est souvent pas la technologie d’infrastructure sous-jacente elle-même, mais qui contrôle la couche opérationnelle qui l’entoure.

L’exposition au CLOUD Act américain et pourquoi la résidence des données seule est insuffisante

L’une des dimensions les plus importantes du Cloud Sovereignty Framework de l’UE est la souveraineté juridique et juridictionnelle : plus précisément, si l’infrastructure reste exposée à des demandes d’accès de gouvernements étrangers en dehors du contrôle juridique européen. C’est là que la discussion va au-delà de la géographie des centres de données et entre dans la propriété du fournisseur, le contrôle opérationnel et la juridiction applicable. Une charge de travail s’exécutant entièrement dans une région européenne peut toujours échouer aux exigences de souveraineté si le fournisseur qui exploite cette infrastructure reste soumis aux lois étrangères de divulgation.

Le problème juridique spécifique est le suivant : un fournisseur cloud constitué sous le droit américain, quel que soit l’endroit où il exploite des centres de données, peut recevoir une ordonnance légale en vertu du Clarifying Lawful Overseas Use of Data Act (CLOUD Act) pour produire des données stockées n’importe où dans le monde. Une région AWS à Francfort ne crée pas de juridiction européenne exclusive sur ces données. Les hyperscalers américains détiennent plus de 70 % du marché cloud européen, et chaque organisation qui les utilise est, à des degrés divers, exposée à ce risque.

La distinction que les équipes platform doivent intégrer dans leur conception est celle entre la résidence des données (où se trouve le matériel) et la souveraineté des données (qui peut contraindre l’accès, sous quelle juridiction et à quel niveau de la stack). En pratique, cela affecte des décisions comme l’endroit où est stocké l’état Terraform, qui contrôle les clés de chiffrement, si des ingénieurs de support hors de l’UE peuvent accéder aux systèmes de production, où les journaux d’audit sont traités et si les métadonnées de déploiement transitent par des plans de contrôle SaaS exploités sous une juridiction étrangère. Une charge de travail peut s’exécuter entièrement dans une région européenne tandis que ses journaux CI/CD, les événements de son fournisseur d’identité, ses workflows d’approbation ou ses systèmes de sauvegarde restent accessibles à une société mère non européenne sous des lois étrangères de divulgation. La Cour des comptes des Pays-Bas a constaté que 67 % de l’infrastructure cloud du gouvernement néerlandais est fournie par Google, Amazon et Microsoft. Une récente étude Bitkom a révélé que 78 % des entreprises allemandes interrogées estiment que l’Allemagne est trop dépendante des fournisseurs cloud américains. Ce ne sont pas des préoccupations abstraites — ce sont les conclusions d’audit qui motivent les actions réglementaires.

DORA change la façon dont les organisations financières évaluent les dépendances cloud. Avant DORA, beaucoup d’équipes traitaient le risque lié aux hyperscalers comme une question contractuelle gérée via des accords avec les fournisseurs et des revues d’achat. DORA déplace cette responsabilité vers la supervision opérationnelle continue. Les institutions financières doivent désormais identifier quels fournisseurs cloud supportent les services critiques, documenter ces dépendances, prouver qu’elles peuvent se remettre des défaillances des fournisseurs et démontrer que les régulateurs peuvent auditer la relation d’infrastructure sous-jacente si nécessaire.

Pour les équipes platform, cela crée des exigences d’infrastructure directes. Les charges de travail critiques ne peuvent pas dépendre entièrement d’un seul fournisseur pour le calcul, l’identité, la journalisation, les sauvegardes et le contrôle du déploiement simultanément. L’état Terraform, les pistes d’audit, les enregistrements d’approbation et les pipelines de déploiement doivent rester traçables et récupérables même lors d’une panne du fournisseur ou d’une enquête réglementaire. La question n’est plus seulement « Où la charge de travail s’exécute-t-elle ? » mais aussi « Qui contrôle les systèmes opérationnels qui l’entourent, et que se passe-t-il si l’accès à ce fournisseur est interrompu ? »

NIS2 étend des attentes similaires au-delà de la finance à des secteurs tels que l’énergie, la santé, le transport, la fabrication, l’administration publique et l’infrastructure numérique. Les organisations doivent documenter les dépendances cloud externes, segmenter les environnements réglementés des non réglementés, maintenir des processus de signalement des incidents et prouver que les fournisseurs respectent des normes de résilience équivalentes. En pratique, cela pousse les équipes platform vers la classification des charges de travail, l’isolation des environnements basée sur les politiques, des pipelines GitOps auditables et un contrôle plus strict de l’endroit où les métadonnées opérationnelles sont stockées et traitées.

Cartographier la stack réglementaire de souveraineté de l’UE vers des décisions d’infrastructure

Les réglementations produisent des exigences, et les exigences produisent des architectures. Le problème est que NIS2, DORA, GDPR et le Cloud Sovereignty Framework adressent chacun des préoccupations qui se chevauchent depuis des angles différents, et les équipes platform les rencontrent souvent lors d’audits plutôt que lors de la conception. Les sections ci-dessous font correspondre chaque réglementation à la décision d’infrastructure spécifique qu’elle implique.

Les obligations NIS2 et ce qu’elles signifient pour la segmentation réseau multi-cloud

NIS2 exige que les entités moyennes et grandes dans 18 secteurs signalent les incidents dans les 24 heures suivant la découverte (six heures dans certains États membres, dont Chypre), maintiennent des mesures documentées de sécurité de la chaîne d’approvisionnement et démontrent des obligations contractuelles de résilience avec chaque dépendance cloud externe.

Pour les équipes platform opérant dans des environnements multi-cloud, ces exigences affectent la façon dont les environnements sont séparés et gouvernés en pratique. Considérons une organisation de santé qui exécute des systèmes patients sur un cloud souverain européen tout en hébergeant des charges de travail analytiques internes sur AWS. Dans le cadre de NIS2, ces deux environnements ne peuvent pas partager nonchalamment un réseau, une fédération IAM ou des pipelines de journalisation centralisés si des données réglementées pouvaient traverser vers l’environnement non souverain lors d’une compromission.

Un schéma d’implémentation courant est d’isoler les charges de travail réglementées dans des clusters Kubernetes séparés, des fournisseurs d’identité séparés et des backends de journalisation entièrement séparés. Par exemple, les API orientées patients peuvent s’exécuter dans un cluster hébergé dans l’UE avec du stockage objet géré dans l’UE et de l’observabilité auto-hébergée, tandis que les outils de développement internes continuent de tourner sur l’infrastructure hyperscaler standard. Des network policies bloquent alors explicitement le trafic est-ouest entre les environnements réglementés et non réglementés, à moins que le trafic ne passe par des passerelles approuvées avec journalisation d’audit activée.

apiVersion

L’exigence d’audit est là où beaucoup d’équipes peinent lors de leur première revue NIS2. Les régulateurs ne demandent pas seulement si la segmentation existe ; ils demandent des preuves montrant quand les politiques ont changé, qui les a approuvées et si les contrôles ont été testés. Un pipeline GitOps avec des network policies versionnées et une validation policy-as-code produit ces preuves automatiquement. Un diagramme d’architecture maintenu manuellement ou une page Confluence ne le fait pas.

Les exigences de risque tiers de DORA et les preuves d’audit IaC

L’Article 28 de DORA et les RTS associés exigent que les entités financières documentent chaque dépendance de service ICT et démontrent que le risque de concentration est activement géré. Le risque de concentration, dans le cadre de DORA, signifie que si le même fournisseur sous-tend les sauvegardes, le calcul et la gestion des identités, un seul incident ou une divulgation contrainte se propage aux trois. Les équipes platform doivent être en mesure de montrer qu’aucune défaillance d’un seul tiers ne peut faire tomber l’ensemble de la stack technologique.

Pour l’infrastructure spécifiquement, chaque ressource dans un environnement couvert par DORA doit avoir un enregistrement de déploiement versionné et traçable par audit. Un fichier d’état Terraform stocké dans un bucket S3 contrôlé par AWS ne satisfait pas cette exigence si AWS est une entité constituée aux États-Unis et que l’état contient des preuves de configuration dont les régulateurs ont besoin. L’état doit se trouver dans un backend auto-contrôlé dans la juridiction réglementée, soutenu par des journaux immuables qui tracent chaque modification à une identité, une exécution de pipeline et un commit Git.

Les modèles de déploiement GitOps-first — où chaque modification d’infrastructure transite par un pipeline versionné avec un enregistrement d’approbation — produisent exactement les preuves que les auditeurs DORA recherchent. L’historique Git est le journal de contrôle des changements. L’exécution de pipeline est l’enregistrement de déploiement. L’étape d’approbation est la preuve d’autorisation. Les équipes qui ont construit l’infrastructure via le click-ops ou des commandes CLI non tracées font face à un travail de remédiation significatif pour produire ces preuves rétroactivement.

Ce que les huit dimensions du Cloud Sovereignty Framework de l’UE signifient pour l’architecture de plateforme

Le framework de la Commission offre aux ingénieurs un moyen structuré d’évaluer à la fois les fournisseurs cloud et leur propre conception de plateforme. Chaque dimension correspond à une décision concrète :

1. La souveraineté stratégique affecte la sélection des fournisseurs au niveau de l’environnement. Un environnement de production réglementé gérant des charges de travail couvertes par DORA ou NIS2 peut n’être autorisé à se déployer que chez des fournisseurs légalement domiciliés dans l’UE, tandis que les environnements de développement à moindre risque continuent de tourner sur des hyperscalers standard.
2. La souveraineté juridique et juridictionnelle affecte les systèmes d’identité, l’architecture de chiffrement et l’accès opérationnel. En pratique, cela signifie décider où vivent les clés racines du Key Management Service (KMS), si l’état Terraform est chiffré avec des clés contrôlées par l’UE, si des ingénieurs de support hors de l’UE peuvent accéder aux clusters de production et si les journaux d’audit restent dans la juridiction européenne.
3. La souveraineté opérationnelle affecte la reprise après sinistre et l’architecture de déploiement. Les équipes doivent supposer un scénario de panne du fournisseur, de litige juridique ou de migration forcée. Cette exigence influence la façon dont l’infrastructure as code est stockée, si les sauvegardes peuvent être restaurées indépendamment du fournisseur, si les registres de conteneurs sont mis en miroir localement et si le plan de contrôle de l’IDP peut continuer à fonctionner si une dépendance SaaS tierce devient indisponible.
4. La souveraineté environnementale apparaît directement dans la planification des déploiements et la gouvernance des coûts. Les charges de travail du secteur public exigent de plus en plus de rapporter les données d’empreinte carbone par région, fournisseur et déploiement. Cela modifie les décisions de sélection d’environnement lors du provisionnement, surtout pour les organisations soumissionnant sur des marchés publics européens.
5. La transparence de la chaîne d’approvisionnement affecte les pipelines CI/CD et la gestion des artefacts. Les images de conteneurs, les modules Terraform, les paquets de systèmes d’exploitation et les binaires tiers doivent être traçables via des Software Bills of Materials (SBOM) et des chaînes de dépendances documentées. Les équipes platform implémentent souvent cela via des registres de conteneurs signés, des pipelines d’analyse d’artefacts et une validation de provenance avant le déploiement.
6. L’ouverture technologique affecte la portabilité de l’environnement dans le temps. Les équipes qui dépendent fortement de services managés propriétaires peuvent avoir du mal à migrer les charges de travail plus tard si les exigences d’éligibilité à la souveraineté changent. C’est pourquoi beaucoup d’environnements réglementés se standardisent autour de Kubernetes, Terraform, PostgreSQL et du stockage objet compatible S3 plutôt que des abstractions propriétaires aux fournisseurs.
7. La sécurité affecte les frontières de chiffrement, la conception RBAC, l’intégration HSM, la segmentation réseau et l’architecture de journalisation d’audit. Les environnements alignés EUCS nécessitent généralement une séparation plus stricte entre les charges de travail réglementées et non réglementées, des workflows d’approbation plus rigoureux et des pistes d’audit immuables liées à l’activité de déploiement.
8. La conformité au droit européen affecte l’ensemble du périmètre opérationnel entourant la charge de travail. Même si les ressources de calcul s’exécutent dans l’UE, l’environnement peut toujours échouer aux exigences de souveraineté si les journaux CI/CD, les workflows d’approbation, les pipelines d’observabilité ou les plans de contrôle SaaS restent accessibles sous une juridiction étrangère.

Schémas d’architecture cloud souveraine pour les équipes platform

La plupart des environnements conformes à la souveraineté suivent une architecture en couches où le contrôle des déploiements, l’exécution des charges de travail, la journalisation d’audit et les systèmes d’identité restent dans la frontière de la juridiction réglementée. Au lieu de s’appuyer sur un seul plan de contrôle SaaS, les équipes séparent l’environnement en couches d’infrastructure contrôlées indépendamment.

Une architecture de déploiement souveraine typique ressemble à ceci :

Dans ce modèle :

• les approbations de déploiement restent dans des systèmes contrôlés par l’UE
• l’état Terraform demeure dans un stockage auto-hébergé
• l’évaluation des politiques intervient avant le provisionnement de l’infrastructure
• les journaux ne quittent jamais le périmètre réglementé
• les charges de travail réglementées et non réglementées s’exécutent dans des environnements isolés

Les sections ci-dessous expliquent comment les équipes implémentent ces frontières d’isolation en pratique.

Exemple : environnements souverains air-gappés et à accès restreint

Un environnement souverain air-gappé ou à accès restreint supprime généralement entièrement l’accès direct à Internet des systèmes de production. Au lieu de télécharger des providers Terraform, des images de conteneurs ou des paquets OS depuis des registres publics lors du déploiement, chaque dépendance est mise en miroir en interne et revue avant de devenir disponible dans l’environnement réglementé.

L’air-gap total est la bonne architecture pour un ensemble étroit de cas d’usage : les charges de travail gouvernementales classifiées, les systèmes de défense traitant des données de sécurité nationale et les chambres de compensation financières spécifiques opérant sous les classifications de sécurité les plus élevées. Pour la plupart des organisations couvertes par NIS2 ou DORA, l’air-gap complet est opérationnellement inutile et comporte un coût de maintenance qui devient rapidement prohibitif.

Ce qu’implique réellement l’air-gapping — au-delà de la déconnexion d’Internet — est : des miroirs locaux de paquets pour chaque écosystème OS, conteneur et langage utilisé ; des autorités de certification internes remplaçant les CA publiques ; des registres de conteneurs air-gappés avec un processus documenté pour intégrer de nouvelles images après revue de sécurité ; et des pipelines de mise à jour qui puisent depuis des miroirs internes sans atteindre des endpoints externes. Chaque mise à jour de dépendance est une opération manuelle. Les correctifs de sécurité qui prennent des heures dans un environnement connecté peuvent prendre des jours dans un environnement air-gappé, ce qui crée son propre risque de sécurité.

Le juste milieu qui satisfait la plupart des exigences NIS2 et DORA pour les charges de travail non classifiées est le déploiement à réseau restreint : pas d’accès Internet entrant, sortant contrôlé et journalisé vers un petit ensemble d’endpoints approuvés, providers Terraform et images de conteneurs servis depuis des miroirs internes, et gestion des clés appuyée sur des systèmes internes ou HSM. La plateforme Dedicated de Cycloid se déploie entièrement dans l’infrastructure client, air-gappée ou isolée, avec le plan de contrôle, le plan de données et les journaux d’audit restant tous dans le périmètre réglementé.

Les plateformes internes de développement auto-hébergées comme couche de gouvernance

L’IDP est l’endroit où les contrôles de souveraineté deviennent opérationnels, et c’est aussi là où ils échouent le plus souvent. Un développeur qui provisionne de l’infrastructure via un portail libre-service interagit avec un plan de contrôle. Si ce plan de contrôle est une plateforme SaaS hébergée en dehors de la juridiction européenne, alors les instructions de provisionnement, les données d’identité des utilisateurs, les enregistrements d’approbation et les journaux d’audit quittent tous l’environnement réglementé, même si l’infrastructure elle-même se déploie dans un centre de données de Francfort.

En pratique, cela signifie qu’un développeur n’accède jamais directement aux credentials de l’infrastructure souveraine. La plateforme valide la demande, vérifie les politiques de juridiction, enregistre la chaîne d’approbation et exécute le déploiement via un pipeline contrôlé dont les journaux restent dans l’environnement réglementé.

Auto-héberger l’IDP signifie exécuter le plan de contrôle et le plan de données de la plateforme dans la juridiction réglementée. Rien dans le workflow de provisionnement ne devrait créer de sortie de métadonnées, d’activité utilisateur ou de données de configuration vers des systèmes externes. En pratique, cela inclut : les stacks du catalogue de services et leurs templates de configuration, le moteur de pipeline qui exécute les déploiements, l’intégration du fournisseur d’identité, les enregistrements du workflow d’approbation et l’inventaire d’actifs qui suit ce qui s’exécute où.

Le RBAC est ici autant une question d’audit qu’une question de contrôle d’accès. Chaque déploiement doit être attribuable à une identité, et chaque approbation doit produire un enregistrement qui survit à une demande réglementaire. Si l’enregistrement d’approbation se trouve dans le système d’un éditeur SaaS hors de la juridiction européenne, il peut ne pas être produisible en vertu du droit européen. Le modèle RBAC multi-organisation de Cycloid, les InfraPolicies et le versionnement des Stacks appliquent des frontières de déploiement avec des pistes d’audit stockées dans le dépôt Git propre au client — versionnées, immuables et opposables en vertu du droit européen.

Policy-as-code pour les garde-fous des charges de travail transfrontalières

Quand les équipes exécutent simultanément des charges de travail réglementées et non réglementées — ce qui est l’état courant pendant une migration vers la souveraineté —, la plateforme doit appliquer les règles de placement sans que chaque développeur ait besoin de savoir quels services sont couverts par DORA ou par NIS2.

Le policy-as-code, utilisant Open Policy Agent, Sentinel ou les InfraPolicies natives de la plateforme, encode les règles de juridiction sous forme de contraintes lisibles par machine : bloquer le déploiement de stacks contenant des données personnelles vers des comptes de fournisseurs non européens ; exiger la sélection dans une liste de fournisseurs souverains approuvés pour les services tagués comme couverts par DORA ; signaler toute stack routant des métriques ou journaux vers des endpoints hors de la région désignée. La politique s’exécute lors de la soumission du StackForm, avant l’application des plans Terraform ou des manifests Kubernetes. Un déploiement ciblant un fournisseur non approuvé échoue immédiatement, empêchant les charges de travail réglementées d’atteindre accidentellement une infrastructure non souveraine.

Le mode de défaillance de l’enforcement basé uniquement sur la revue humaine est prévisible. Un développeur qui crée un nouveau microservice ne sait pas s’il traite des données personnelles au moment de sélectionner une cible de déploiement. Au moment où le service est en production, la violation a déjà eu lieu. Le policy-as-code détecte la violation au niveau du StackForm, avant le déploiement, quand la corriger ne coûte rien.

Sélection d’un fournisseur cloud souverain : critères techniques au-delà des déclarations marketing

Chaque grand fournisseur cloud a désormais un discours sur la souveraineté. Évaluer ces discours nécessite de poser des questions techniques spécifiques, pas de lire des pages marketing. L’appel d’offres de la Commission d’avril 2026 fournit un modèle utile : il exigeait des preuves d’assurance, pas des assertions.

Comment l’évaluation en huit dimensions de la Commission fonctionne en pratique

Les fournisseurs dans l’appel d’offres d’avril 2026 devaient documenter leur chaîne d’approvisionnement, démontrer l’architecture de gestion des clés, préciser quels membres du personnel ont accès aux données clients et dans quel cadre juridique, et fournir une documentation sur la sortie et la portabilité. L’exigence de niveau d’assurance — que les tiers non européens ont un contrôle limité — n’est pas satisfaite par un seul engagement contractuel. Elle exige une architecture technique où les entités résidant dans l’UE détiennent les clés racines, où l’accès du helpdesk et des SRE nécessite une autorisation basée dans l’UE et où le fournisseur peut démontrer une continuité opérationnelle sans la société mère non européenne.

La sélection de Proximus illustre la frontière. Proximus s’associe à S3NS, une coentreprise de Thales (français) et Google Cloud (américain). Google Cloud fournit la technologie d’infrastructure sous-jacente ; Thales détient les clés de chiffrement et contrôle l’accès opérationnel. Le résultat satisfait le cadre de la Commission parce que l’entité européenne — pas Google — contrôle les mécanismes par lesquels les données pourraient être accédées. Pour les ingénieurs platform qui évaluent des fournisseurs, les bonnes questions sont : qui détient les clés racines et sous quelle entité juridique ; où se trouvent les SRE et le personnel de support et quelle autorisation nécessitent-ils pour accéder aux données clients ; quelles sont les procédures de sortie documentées et quels formats le fournisseur supporte-t-il pour l’export des données et configurations ?

Clouds souverains construits sur infrastructure européenne : STACKIT, Scaleway, Outscale et IONOS

Les quatre fournisseurs sélectionnés dans l’appel d’offres de la Commission représentent différents points sur le spectre de la souveraineté.

1. STACKIT, la division cloud du Groupe Schwarz (qui exploite Lidl), est basé en Allemagne avec une infrastructure exclusivement européenne, sans société mère américaine, et une certification ISO 27001. Le Groupe Schwarz s’est engagé à investir €11 milliards dans une infrastructure de centres de données souverains pour STACKIT, dont un nouveau site majeur à Lübbenau, Brandebourg. Le catalogue de services est plus étroit qu’AWS ou Azure, mais les garanties juridictionnelles sont plus claires car il n’y a pas de société mère étrangère pour compliquer l’analyse CLOUD Act.
2. Scaleway, membre du groupe Iliad français, est conçu explicitement comme une alternative européenne aux hyperscalers. Les centres de données opèrent à Paris, Amsterdam et Varsovie. La tarification est en euros. Le fournisseur participe à GAIA-X et détient la qualification SecNumCloud pour certains niveaux de service.
3. Outscale, filiale de Dassault Systèmes, opère sous certification française SecNumCloud — la plus haute qualification nationale française en cybersécurité. La certification SecNumCloud inclut des exigences spécifiques sur les contrôles d’accès, la gestion des clés et l’habilitation de sécurité du personnel, en faisant l’une des certifications de souveraineté les plus rigoureuses disponibles en Europe.
4. IONOS, basé en Allemagne, offre une architecture nativement GDPR et documente explicitement sa non-exposition au CLOUD Act américain compte tenu de sa structure d’entreprise européenne.

Le compromis est cohérent pour les quatre : des garanties juridictionnelles plus fortes s’accompagnent de catalogues de services managés plus étroits, de moins de zones de disponibilité et de services de plateforme moins matures comparés à AWS, Azure ou GCP. La décision d’ingénierie est de savoir si l’exigence de souveraineté s’applique à toutes les charges de travail ou seulement aux charges réglementées — ce qui mène directement à la classification des charges de travail.

Évaluer le risque de sortie et la portabilité en cas d’évolution des exigences de souveraineté

Les exigences de souveraineté se renforcent, elles ne se stabilisent pas. Le CADA à venir pourrait introduire des critères d’éligibilité nécessitant de ré-architecturer les charges de travail sur des fournisseurs qui ne se qualifient pas. Les équipes qui n’ont pas conçu pour la portabilité feront face à cela sous contrainte de délai.

Évaluer le risque de sortie signifie se demander : le fournisseur utilise-t-il des formats et standards ouverts — Kubernetes, Terraform, les APIs OpenStack, le stockage objet compatible S3 — ou des interfaces propriétaires créant du lock-in ? L’IaC qui provisionne l’environnement produit-il un état portable, ou un état qui ne se résout que contre le backend de ce fournisseur ? Le fournisseur fournit-il des procédures documentées d’export de données fonctionnant à l’échelle ?

Avec Cycloid Infra Import, vous pouvez reprendre le contrôle de votre infrastructure existante.

L’infrastructure as code, versionnée dans Git avec des backends d’état auto-contrôlés, est la réponse pratique aux trois questions. Quand le fournisseur change, la définition d’infrastructure suit l’organisation. La capacité Infra Import de Cycloid, adossée à l’outil open-source TerraCognita, lit les ressources existantes depuis AWS, Azure, GCP et VMware et génère des fichiers de configuration Terraform. Pour les organisations dont l’infrastructure existe dans un hyperscaler sans IaC versionné, c’est le point de départ de toute migration vers la souveraineté — car les équipes ne peuvent pas planifier ce qu’elles n’ont pas inventorié.

Architecture de gouvernance et d’audit pour les équipes platform conformes à la souveraineté

La souveraineté n’est pas maintenue par l’architecture seule. Les auditeurs, les régulateurs et les organismes de certification ont besoin de preuves — des enregistrements structurés, datés et attribuables qui prouvent que les contrôles ont fonctionné comme prévu. Intégrer la piste d’audit dans l’architecture de plateforme dès le départ coûte bien moins que de la reconstituer après une demande d’audit.

Structurer les pistes d’audit satisfaisant NIS2, DORA et les audits de certification internes

Les auditeurs NIS2 et DORA ne cherchent pas des journaux ; ils cherchent des preuves de contrôle des changements. Chaque déploiement d’infrastructure doit être traçable via : un commit Git qui enregistre ce qui a changé et qui l’a autorisé ; une exécution de pipeline qui enregistre quand le changement a été appliqué et s’il a réussi ; un enregistrement d’identité qui confirme quel utilisateur autorisé a déclenché le pipeline ; un enregistrement d’approbation si l’environnement l’exige ; et un enregistrement de résultat montrant l’état post-déploiement.

Le mode de défaillance spécifique des IDPs uniquement SaaS est que les enregistrements d’approbation, les journaux de pipeline et les pistes d’audit vivent dans le système du fournisseur. Si le fournisseur est en dehors de la juridiction européenne, produire ces enregistrements lors d’une enquête réglementaire peut nécessiter une procédure juridique qui prend des semaines et peut ne pas produire des enregistrements complets. Un IDP auto-hébergé et soutenu par Git stocke chaque enregistrement dans l’environnement réglementé, sous les contrôles d’accès propres à l’organisation, opposables en vertu du droit européen.

Cycloid conserve des pistes d’audit détaillées pour toutes les actions et modifications de la plateforme, avec tous les enregistrements stockables dans l’infrastructure propre au client lorsqu’il est déployé en mode dédié ou auto-hébergé. Chaque déploiement de stack, chaque approbation et chaque modification de configuration produit un enregistrement immuable dans le dépôt Git du client — dans le format que les auditeurs peuvent lire et que les procédures légales peuvent contraindre depuis les systèmes propres de l’organisation, pas ceux d’un tiers.

Conception RBAC pour les environnements souverains multi-tenants

Les prestataires de services managés, les centres de services partagés et les grandes entreprises exécutant à la fois des charges de travail réglementées et non réglementées partagent un problème RBAC commun : les frontières de souveraineté doivent être appliquées au niveau de la plateforme sans que chaque opérateur ait besoin de vérifier manuellement quel environnement chaque développeur est autorisé à atteindre.

L’exigence de conception est la multi-location avec une isolation stricte entre les domaines d’autorisation. Les organisations, équipes, environnements et stacks doivent être des périmètres d’autorisation séparés pour qu’un développeur autorisé pour l’environnement non réglementé ne puisse pas, par mauvaise configuration ou accident, déployer dans un environnement réglementé. Le RTS de DORA ajoute la dimension de risque de concentration : une défaillance ou une violation dans l’environnement d’un tenant ne doit pas affecter celui d’un autre — ce qui nécessite une isolation réseau, des périmètres d’identité séparés et des contextes de pipeline séparés.

Le modèle RBAC multi-organisation de Cycloid applique ces frontières via les InfraPolicies et le versionnement des Stacks. Les équipes platform définissent quelles stacks sont disponibles pour quelles organisations, quels environnements nécessitent des workflows d’approbation et quels fournisseurs sont éligibles pour chaque périmètre réglementaire. Les MSPs utilisant Cycloid peuvent gérer plusieurs environnements clients avec une isolation forte, des pistes d’audit séparées par tenant et un RBAC qui empêche tout opérateur de traverser les frontières de tenant sans autorisation explicite.

Gouvernance carbone et des coûts dans le cadre de la souveraineté

La souveraineté environnementale est l’une des huit dimensions d’évaluation de la Commission, et pour les marchés publics du secteur public dans l’UE, elle fonctionne comme un critère de notation. Les équipes qui construisent pour des contrats publics ont besoin de données d’empreinte carbone par déploiement en parallèle des données de coût, visibles avant le déploiement — pas rapportées rétrospectivement.

L’estimation des coûts et du carbone avant déploiement, exposée au niveau du libre-service, change le point de décision. Un développeur choisissant entre deux options de déploiement qui peut voir que l’option A coûte €200/mois et produit 12 kg CO₂e tandis que l’option B coûte €180/mois et produit 8 kg CO₂e prend une meilleure décision que celui qui ne voit ni l’un ni l’autre chiffre. Escalader chaque décision de dimensionnement d’environnement à une équipe platform pour vérifier la conformité n’est pas extensible ; exposer les données au niveau du StackForm place la décision là où le choix est fait.

Les modules FinOps et GreenOps de Cycloid exposent les données de coût et de carbone par projet, région, fournisseur et tag, filtrables en temps réel. L’estimation des coûts s’exécute avant le déploiement, au niveau du StackForm, donnant aux développeurs les chiffres avant qu’ils ne s’engagent. Pour les organisations qui soumissionnent sur des marchés publics notés selon la dimension de souveraineté environnementale de la Commission, ces données constituent des preuves d’audit prêtes à l’emploi d’un comportement d’achat conforme au niveau de l’infrastructure.

Chemins de migration depuis une architecture dépendante des hyperscalers vers une architecture conforme à la souveraineté

La migration vers la souveraineté est un programme d’ingénierie pluriannuel dans la plupart des organisations — pas un événement de bascule. Le chemin pratique commence par la classification, progresse via la génération d’IaC et aboutit dans un pipeline de livraison abstrait du fournisseur qui peut s’adapter à des cibles souveraines sans reconstruire de zéro.

Classification des charges de travail : quels services nécessitent réellement une infrastructure souveraine

Toutes les charges de travail d’une organisation réglementée n’ont pas besoin de s’exécuter sur un cloud souverain. Le cadre propre de la Commission reconnaît que les technologies non européennes peuvent satisfaire les exigences minimales de souveraineté dans le bon contexte opérationnel. L’objectif d’ingénierie est d’identifier quelles charges de travail nécessitent réellement une infrastructure souveraine et d’architecturer en conséquence.

Une matrice de classification des charges de travail fonctionne selon trois axes : la sensibilité des données (données personnelles sous GDPR, données métier confidentielles, informations classifiées), le périmètre réglementaire (services financiers couverts par DORA, services essentiels NIS2, réglementations sectorielles spécifiques) et la criticité opérationnelle (ce qui échoue si cet environnement est indisponible ou compromis). Les charges de travail qui scorent haut sur la sensibilité des données et le périmètre réglementaire nécessitent une infrastructure souveraine. Celles qui scorent bas sur les deux peuvent rester sur les hyperscalers, à condition que les flux de données entre les deux environnements soient journalisés et contrôlés.

Une architecture hybride est le résultat correct pour la plupart des organisations — pas un échec de l’intention de souveraineté. La matrice de classification rend la frontière explicite et défendable : les régulateurs peuvent voir exactement quelles charges de travail sont sur infrastructure souveraine et pourquoi, et lesquelles ne le sont pas et pourquoi c’est conforme. La classification détermine aussi quels environnements ont besoin de l’architecture de gouvernance complète (plan de contrôle IDP auto-hébergé, isolation RBAC, enforcement policy-as-code) et lesquels peuvent opérer avec des contrôles allégés.

Migration IaC-first : utiliser Infra Import pour générer une baseline portable

Les organisations dont l’infrastructure existe dans un hyperscaler sans IaC versionné partent d’une migration vers la souveraineté dans un angle mort. Sans baseline documentée, les équipes ne savent pas ce qu’elles déplacent, quelles dépendances existent entre les ressources, ni quelle dérive de configuration s’est accumulée depuis le déploiement initial.

La capacité Infra Import de Cycloid, adossée à l’outil open-source TerraCognita, lit les ressources cloud existantes depuis AWS, Azure, GCP et VMware et génère des fichiers de configuration Terraform. La sortie est une baseline versionnée et portable à partir de laquelle la planification de la migration peut commencer. Les équipes peuvent revoir l’IaC généré pour y trouver la dérive (ressources qui existent dans le cloud mais pas dans la configuration), les dépendances non documentées (ressources qui se référencent mutuellement sans déclaration explicite) et les configurations héritées qui ne satisfont pas les exigences actuelles de souveraineté.

L’IaC généré devient ensuite la source autoritaire pour la planification de la migration. Les environnements sont recréés depuis le code chez le fournisseur souverain cible, avec l’IaC revu et approuvé via le même pipeline GitOps que toute autre modification d’infrastructure. Le backend d’état se déplace vers un endpoint auto-contrôlé dans la juridiction réglementée, et le pipeline de livraison se connecte au nouveau compte fournisseur. Le résultat est une migration documentée et auditable avec un historique de changement complet.

Onboarding sur le cloud souverain sans reconstruire le pipeline de livraison

L’un des obstacles pratiques les plus importants à la migration vers la souveraineté est l’hypothèse que changer de fournisseur cloud signifie reconstruire les pipelines CI/CD, les catalogues de services et les automatisations de déploiement. Sur un IDP GitOps-first, le fournisseur est une variable d’entrée, pas le fondement de l’architecture de livraison.

Un développeur interagissant avec un StackForm ne voit pas l’API du fournisseur sous-jacente. Le formulaire demande quel environnement déployer, quelle taille, quelle région — et la plateforme traduit ces inputs en appels API spécifiques au fournisseur en coulisses. Changer la cible de déploiement d’AWS Francfort vers Scaleway Paris, pour des stacks conçues pour être indépendantes du fournisseur, nécessite d’ajouter un nouveau compte fournisseur à la plateforme et de l’exposer aux tenants concernés. Le StackForm ne change pas. Le template de pipeline ne change pas.

Ce qui change à la place, c’est la destination de l’infrastructure et la politique de gouvernance qui lui est attachée. La couche d’inventaire d’actifs de Cycloid offre aux équipes platform une visibilité en temps réel sur les charges de travail, les stacks Terraform, les comptes cloud et les ressources Kubernetes qui existent dans les environnements réglementés et non réglementés. Pendant la migration vers la souveraineté, cela devient la source de vérité opérationnelle pour identifier quels services dépendent encore d’une infrastructure non souveraine et quels environnements ont déjà migré.

Les capacités InfraView et InfraMap open-source de Cycloid génèrent ensuite la topologie d’infrastructure directement depuis l’état Terraform en direct, produisant automatiquement la documentation d’environnement au lieu de s’appuyer sur des diagrammes d’architecture maintenus manuellement. Pour les équipes qui se préparent à des audits NIS2 ou DORA, cela crée des preuves d’infrastructure continuellement mises à jour montrant les frontières réseau, les dépendances aux fournisseurs et les relations entre ressources dans les environnements souverains et non souverains.

Les StackForms de Cycloid permettent la sélection du compte cloud comme variable de formulaire, ce qui signifie que les équipes platform peuvent ajouter un fournisseur souverain comme nouvelle option de compte et le rendre immédiatement disponible pour les tenants qui en ont besoin — sans reconstruire le catalogue de services ni réoutiller le pipeline de livraison. Les stacks existantes qui se déploient déjà via les pipelines Concourse continuent de le faire. Le compte fournisseur est simplement une autre destination.

La couche Components de Cycloid devient particulièrement utile lors de migrations vers la souveraineté par phases où les services spécifiques aux fournisseurs doivent être échangés progressivement plutôt que de reconstruire des stacks entières. Les équipes peuvent remplacer des composants d’infrastructure individuels — par exemple en passant de bases de données managées AWS vers des équivalents Scaleway ou Outscale — sans redesigner le workflow de déploiement environnant. L’abstraction intervient au niveau de la couche composant plutôt que d’obliger les équipes à reconstruire l’ensemble du catalogue de services.

C’est là que le modèle de souveraineté de Cycloid diffère d’une plateforme interne de développement SaaS standard. La plateforme elle-même peut s’exécuter dans des environnements dédiés, auto-hébergés, isolés ou entièrement air-gappés tout en préservant le même modèle RBAC, le même pipeline d’audit, le même moteur de politiques, les mêmes StackForms et les mêmes contrôles de gouvernance. La souveraineté est appliquée non seulement au niveau de l’infrastructure, mais au niveau du plan de contrôle où les approbations de déploiement, l’accès à l’état Terraform, les journaux d’audit et les métadonnées opérationnelles sont générés et stockés.

Conclusion

La souveraineté cloud est passée d’une étiquette de conformité à une spécification de conception système. Le Cloud Sovereignty Framework en huit dimensions de la Commission européenne d’avril 2026, les exigences de risque tiers et de risque de concentration de DORA, les obligations de documentation de la chaîne d’approvisionnement de NIS2 et les restrictions de transfert du GDPR définissent collectivement une architecture technique — une qui nécessite des backends d’état IaC auto-contrôlés, des plans de contrôle de plateforme qui ne routent pas les métadonnées en dehors de la juridiction réglementée, du policy-as-code qui applique le placement des charges de travail avant l’exécution des déploiements et des définitions d’infrastructure portables qui ne créent pas de risque de sortie.

Les équipes qui traitent la souveraineté comme une décision d’achat s’enfermeront dans une impasse. Quand le CADA formalisera les critères d’éligibilité à travers le marché unique européen, les organisations dont l’infrastructure est opaque (pas d’IaC versionné), dont le plan de contrôle IDP est un système SaaS étranger (enregistrements d’approbation hors de la juridiction européenne) et dont la classification des charges de travail est non documentée (pas de base pour démontrer la conformité) feront face à une remédiation coûteuse sous contrainte de délai. Les équipes qui intègrent l’architecture de gouvernance dans la couche de plateforme maintenant — plans de contrôle auto-hébergés, pipelines GitOps-first, enforcement policy-as-code, frontières de charges de travail classifiées — disposeront des preuves d’audit, de l’IaC portable et de la flexibilité architecturale pour répondre à toute prochaine spécification réglementaire.

FAQ

1. Quelle est la différence entre la souveraineté cloud, la souveraineté des données et la résidence des données pour les équipes d’ingénierie ?

La résidence est l’emplacement du matériel, tandis que la souveraineté des données concerne la juridiction légale et l’accès. La souveraineté cloud ajoute huit dimensions comme l’indépendance opérationnelle et la visibilité de la chaîne d’approvisionnement. Les fournisseurs américains à Francfort satisfont la résidence, mais le CLOUD Act peut entraîner un échec à la souveraineté.

2. Comment l’évaluation en huit dimensions du Cloud Sovereignty Framework de l’UE affecte-t-elle le choix de la chaîne d’outils IDP ?

L’accent du framework sur l’ouverture technologique favorise les standards ouverts comme Kubernetes et Terraform pour prévenir le risque de sortie. Pour satisfaire les exigences juridiques et juridictionnelles, le plan de contrôle de l’IDP doit opérer dans la juridiction réglementée. Cette règle restreint les plateformes SaaS hébergées en dehors de l’UE pour les organisations suivant les standards DORA ou NIS2.

3. Quelles obligations DORA spécifiques nécessitent des changements dans la façon dont les équipes platform stockent l’état Terraform et les pistes d’audit de déploiement ?

L’Article 28 de DORA exige des dépendances ICT documentées et un risque de concentration géré — ce qui n’est pas satisfait si l’on utilise un stockage contrôlé par les États-Unis pour l’état d’infrastructure. L’état doit résider dans des backends européens auto-contrôlés où l’historique des changements est traçable jusqu’aux utilisateurs autorisés et aux exécutions de pipeline. Cela garantit que les enregistrements de configuration restent dans le territoire réglementé à des fins d’audit.

4. Les organisations peuvent-elles utiliser AWS ou Azure et néanmoins satisfaire les exigences de souveraineté cloud de l’UE dans le cadre du framework 2026 de la Commission ?

Les organisations peuvent utiliser les hyperscalers si la technologie est opérée dans un cadre contrôlé par l’UE où un personnel résidant dans l’UE gère les clés de chiffrement. Bien que des modèles comme AWS European Sovereign Cloud visent la séparation, la conformité repose sur l’architecture technique plutôt que sur les déclarations du fournisseur. Une revue tierce selon le framework en huit dimensions est nécessaire pour vérifier ces affirmations de souveraineté.