#6 Le Cloud Sovereignty Framework européen : Bruxelles fixe les règles

En mars 2026, la Commission européenne attribuait un marché cloud de 180 millions d'euros à quatre consortiums composés exclusivement d'acteurs européens.

L'événement a été largement commenté comme un signal politique fort.
Ce qui l'a été beaucoup moins, c'est le document technique qui a rendu cette attribution possible : le Cloud Sovereignty Framework (v1.2.1), publié par la Direction générale des services numériques de la Commission en octobre 2025.

Ce document de six pages dense et précis est certainement l'un des textes les plus importants produits par Bruxelles sur la souveraineté numérique depuis le RGPD.
Pour la première fois, une institution européenne de premier rang a formalisé ce que signifie concrètement "souverain" pour un service cloud, en décomposant la notion en huit objectifs mesurables, cinq niveaux d'assurance gradués, et une formule de calcul d'un score de souveraineté pondéré.
Ce n'est pas un discours, c'est un cahier des charges !

Et en parallèle, depuis 2020, un autre chantier se poursuit, plus laborieusement, au niveau européen : l'EUCS, le futur schéma de certification cloud de l'Union Européenne, développé par l'ENISA.

Ces deux textes forment ensemble le cadre réglementaire en construction autour duquel se jouent des intérêts considérables : technologiques, industriels et surtout géopolitiques.

🔎 L'ENISA - European Union Agency for Cybersecurity.

L'Agence de l'Union européenne pour la cybersécurité est l'agence spécialisée de l'UE chargée de la cybersécurité à l'échelle européenne.

Fondée en 2004, initialement sous le nom d'Agence européenne chargée de la sécurité des réseaux et de l'information, elle a vu son mandat considérablement renforcé et pérennisé par le Cybersecurity Act (Règlement UE 2019/881), entré en vigueur en juin 2019.

Son siège est à Athènes (Grèce), avec un bureau à Héraklion (Crète) et une présence à Bruxelles.

Elle emploie environ 250 personnes et dispose d'un budget annuel d'environ 24 millions d'euros, modeste au regard de ses missions.

Ses trois missions principales

Expertise et conseil.
L'ENISA produit des rapports, des études et des recommandations sur l'état des menaces cyber en Europe, les bonnes pratiques de sécurité, et les politiques à adopter.
Son rapport annuel "ENISA Threat Landscape" est une référence dans le secteur.
Elle conseille la Commission européenne, le Parlement et les États membres sur les questions de cybersécurité.

Renforcement des capacités.
Elle organise des exercices de cybersécurité à l'échelle européenne — notamment Cyber Europe, le plus grand exercice de simulation de cyberattaque de l'UE, qui réunit tous les deux ans les équipes nationales de réponse aux incidents (CSIRT/CERT) des États membres.
Elle soutient également la montée en compétences des autorités nationales.

Certification.
Depuis le Cybersecurity Act de 2019, l'ENISA s'est vu confier une mission nouvelle et centrale : développer et maintenir des schémas européens de certification de cybersécurité pour les produits, services et processus numériques.
C'est dans ce cadre qu'elle développe l'EUCS (European Union Cybersecurity Certification Scheme for Cloud Services), le futur standard européen de certification cloud décrit dans cet article de cette série.

Ce qu'elle n'est pas

L'ENISA n'est pas une agence opérationnelle de renseignement ou de défense cyber.
Elle n'intervient pas directement sur les incidents de sécurité.
Elle n'a pas non plus de pouvoir réglementaire contraignant.
Elle produit des recommandations et des schémas de certification, mais c'est la Commission européenne qui adopte ces schémas par voie de règlement d'exécution, et ce sont les autorités nationales (ANSSI en France, BSI en Allemagne...) qui délivrent les certifications.

C'est précisément cette limite qui alimente le débat sur l'EUCS : l'ENISA peut proposer, mais elle ne peut pas imposer.
Les États membres conservent leur souveraineté sur l'interprétation et l'application des schémas qu'elle développe.

Le Cloud Sovereignty Framework : anatomie d'un texte fondateur

Le Cloud Sovereignty Framework de la Commission n'est pas une loi.
C'est un document contractuel, un cahier des charges de souveraineté annexé aux appels d'offres cloud de la Commission et de ses agences.

Mais sa portée est bien plus large que son statut formel ne l'indique.
En le publiant et en l'appliquant à un marché de 180 millions d'euros, la Commission a envoyé un signal clair au marché :

• voilà comment nous allons mesurer la souveraineté,
• voilà les critères que nous allons imposer
• voilà les niveaux en deçà desquels nous ne descendrons pas pour nos données sensibles.

Le document s'appuie explicitement sur plusieurs sources européennes : le Trusted Cloud Referential v2 du CIGREF, les règles et l'architecture de Gaia-X, le cadre de certification cybersécurité de l'ENISA (NIS2, DORA), et les stratégies nationales de cloud souverain — notamment le "Cloud de Confiance" français et le "Souveräner Cloud" allemand.

Les huit objectifs de souveraineté

Le cœur du document est une taxonomie de huit objectifs de souveraineté, chacun couvrant une dimension distincte de ce que signifie réellement "être souverain" pour un service cloud.

SOV-1 : Souveraineté stratégique.

Elle juge le degré d'ancrage du prestataire dans l'écosystème juridique, financier et industriel de l'Union européenne.
Elle porte sur la stabilité de l'actionnariat, l'influence sur la gouvernance, et l'alignement avec les priorités stratégiques de l'UE.

En clair : qui possède l'entreprise, qui la dirige, et est-ce que ses intérêts sont alignés avec ceux de l'Europe ?

SOV-2 : Souveraineté juridique et juridictionnelle.

Elle évalue l'environnement légal, l'exposition aux autorités étrangères, et la capacité à faire valoir ses droits dans le cadre des services du prestataire.
C'est la dimension qui couvre directement le risque CLOUD Act, FISA, et les autres lois extraterritoriales documentées dans les articles précédents de cette série.

SOV-3 : Souveraineté des données et de l'IA.

Elle mesure la manière dont les données sont sécurisées, où elles sont traitées, et le degré d'autonomie que les clients conservent sur leurs capacités d'IA.
Elle couvre la résidence des données, le chiffrement, les clés de chiffrement, et les conditions d'utilisation des données pour l'entraînement des modèles.

SOV-4 : Souveraineté opérationnelle.

Elle estime la capacité pratique des acteurs européens à exploiter, maintenir et faire évoluer une technologie de manière indépendante d'un contrôle étranger.
Elle porte sur la continuité des opérations, la disponibilité des compétences, et la résilience face aux dépendances externes.

SOV-5 : Souveraineté de la chaîne d'approvisionnement.

Elle évalue l'origine géographique, la transparence et la résilience de la chaîne d'approvisionnement technologique, en se concentrant sur la mesure dans laquelle les composants et processus critiques restent sous contrôle européen ou sont exposés à des dépendances non-européennes.

C'est la dimension la plus lourde dans la pondération du score — 20 % — ce qui reflète la conviction que la dépendance aux composants étrangers (GPU Nvidia, puces TSMC, matériels américains) est le risque structurel le plus difficile à résorber.

SOV-6 : Souveraineté technologique.

Elle évalue le degré d'ouverture, de transparence et d'indépendance dans la pile technologique sous-jacente, en s'assurant que les acteurs européens peuvent interopérer, auditer et faire évoluer les solutions sans être enfermés dans des systèmes propriétaires étrangers.
Elle couvre l'open source, les formats ouverts, l'interopérabilité et la réversibilité.

SOV-7 : Souveraineté en matière de sécurité et de conformité.

Elle détermine dans quelle mesure les opérations de sécurité, les obligations de conformité et les mesures de résilience sont contrôlées au sein de l'UE, assurant l'indépendance vis-à-vis des juridictions étrangères et une assurance opérationnelle à long terme.
Elle couvre notamment la capacité à développer et appliquer des correctifs de sécurité de manière autonome.

SOV-8 : Durabilité environnementale.

Elle apprécie l'autonomie et la résilience à long terme des services cloud en termes de consommation d'énergie, de dépendance et de pénurie de matières premières.

C'est la seule dimension non strictement liée à la souveraineté géopolitique.
Elle reflète l'intégration par Bruxelles des objectifs du Green Deal dans ses critères d'achat.

✏️ Le Green Deal.

Officiellement European Green Deal en anglais, ou Pacte vert pour l'Europe en français — est le programme politique central de la Commission européenne adopté en décembre 2019.

C'est la feuille de route de l'Union européenne pour transformer son économie en une économie neutre en carbone d'ici 2050, en réduisant les émissions de gaz à effet de serre, en préservant la biodiversité et en favorisant une économie circulaire.

Ses objectifs principaux

L'ambition centrale est de faire de l'Europe le premier continent climatiquement neutre du monde d'ici 2050. Pour y parvenir, le Green Deal fixe plusieurs jalons intermédiaires et couvre un éventail très large de politiques.

Réduction des émissions
L'UE s'est engagée à réduire ses émissions de CO₂ d'au moins 55 % d'ici 2030 par rapport aux niveaux de 1990 (objectif "Fit for 55"), et à atteindre la neutralité carbone en 2050.

Énergie propre.
Accélération du déploiement des énergies renouvelables (solaire, éolien), réduction de la dépendance aux énergies fossiles, fin progressive du charbon.

Industrie et économie circulaire.
Décarbonation des secteurs industriels lourds (acier, ciment, chimie), réduction des déchets, encouragement du recyclage et de la réutilisation des matériaux.

Mobilité durable.
Fin de la vente de voitures à moteur thermique neuf en 2035, développement du ferroviaire et des transports propres.

Agriculture et biodiversité.
Stratégie "De la ferme à la table" visant à réduire l'usage des pesticides et des engrais, développement de l'agriculture biologique.

Pourquoi le Green Deal apparaît dans le Cloud Sovereignty Framework ?

Dans le Cloud Sovereignty Framework, l'objectif SOV-8 (Durabilité environnementale) est directement issu du Green Deal.
Il évalue l'autonomie et la résilience à long terme des services cloud en termes de consommation d'énergie, de dépendance aux matières premières critiques et d'empreinte carbone.

Concrètement, pour un prestataire cloud, SOV-8 couvre trois dimensions.

L'efficacité énergétique
Les datacenters sont des consommateurs d'énergie considérables. Le Green Deal pousse l'UE à exiger des infrastructures numériques qu'elles s'alimentent en énergies renouvelables et améliorent leur indicateur PUE (Power Usage Effectiveness, le ratio entre l'énergie consommée par le datacenter et celle effectivement utilisée pour le calcul).

L'économie circulaire
Le recyclage et reconditionnement des serveurs, traitement responsable des équipements en fin de vie, réduction des déchets électroniques.

La transparence carbone
La mesure et la publication des émissions de CO₂, la consommation d'eau et d'autres indicateurs environnementaux.

Les cinq niveaux SEAL : une échelle graduée de la souveraineté

Le second apport majeur du Cloud Sovereignty Framework est la définition de cinq niveaux d'assurance de souveraineté — les Sovereignty Effectiveness Assurance Levels (SEAL), de 0 à 4.

Cette échelle est destinée à être utilisée comme seuil minimum dans les appels d'offres : tout prestataire qui n'atteint pas le niveau SEAL requis est éliminé.

SEAL-0 : Aucune souveraineté.
Le service, la technologie ou les opérations sont sous le contrôle exclusif de tiers non-européens, régis entièrement par des juridictions non-européennes.
C'est la situation d'un service AWS, Azure ou Google Cloud standard, sans aucune mesure de souveraineté ajoutée.

SEAL-1 : Souveraineté juridictionnelle.
Le droit européen s'applique formellement, mais avec une applicabilité pratique limitée. Le service, la technologie ou les opérations restent sous le contrôle exclusif de tiers non-européens.
C'est la situation des offres "conformes RGPD" des hyperscalers, qui respectent formellement le droit européen sans pour autant être à l'abri du CLOUD Act ou du FISA.

SEAL-2 : Souveraineté des données.
Le droit européen est applicable et applicable en pratique, mais des dépendances non-européennes importantes subsistent.
Le service, la technologie ou les opérations sont sous le contrôle indirect de tiers non-européens.
C'est le niveau atteint par S3NS dans le marché de la Commission — technologie Google, opérée par Thales, sous contrôle européen majoritaire, avec des dépendances technologiques américaines résiduelles.

SEAL-3 : Résilience numérique.
Le droit européen est applicable et applicable, les acteurs européens exercent une influence significative mais pas totale.
Le service, la technologie ou les opérations sont sous le contrôle marginal de tiers non-européens.
C'est le niveau atteint par Scaleway, OVHcloud et StackIT dans le marché de la Commission, acteurs nativement européens, mais dont la chaîne d'approvisionnement matérielle (GPU, processeurs) reste partiellement dépendante d'acteurs non-européens.

SEAL-4 : Souveraineté numérique complète.
La technologie et les opérations sont sous contrôle européen complet, soumis uniquement au droit européen, sans aucune dépendance critique non-européenne.
C'est le niveau théoriquement le plus exigeant — et le moins peuplé.
Aucun acteur ne l'atteint encore pleinement, précisément parce que la chaîne d'approvisionnement matérielle (GPU, puces) reste structurellement dépendante d'acteurs non-européens.

SEAL-4 : le niveau inaccessible
Le niveau SEAL-4 est le seul niveau du Cloud Sovereignty Framework qui exige une souveraineté complète sur l'ensemble de la chaîne : technologie, opérations, droit, approvisionnement matériel.

En pratique, aucun acteur cloud commercial n'atteint aujourd'hui ce niveau, pour une raison structurelle documentée dans un article de cette série : les GPU utilisés pour l'entraînement et l'inférence des modèles d'IA sont à 95 % produits par Nvidia, sur des puces fabriquées par TSMC à Taïwan.

SEAL-4 est donc, pour l'instant, un horizon normatif plutôt qu'une réalité opérationnelle.
Il pose néanmoins un cadre de référence utile : il dit à l'industrie où Bruxelles veut aller, même si personne n'y est encore.

Sa valeur est peut-être surtout politique.
En le définissant, la Commission établit que la dépendance aux composants matériels non-européens est un enjeu de souveraineté à part entière, au même titre que la dépendance juridique aux lois étrangères.
C'est un signal adressé autant aux industries semiconducteurs européennes (ASML, STMicroelectronics, Infineon) qu'aux prestataires cloud.

L'EUCS : cinq ans de débat pour un texte toujours en attente

Si le Cloud Sovereignty Framework est un document de la Commission appliqué de façon pragmatique à ses propres achats, l'EUCS (European Union Cybersecurity Certification Scheme for Cloud Services) est un chantier beaucoup plus ambitieux, et beaucoup plus conflictuel.

Initié en 2019 sous mandat du Cybersecurity Act (Règlement UE 2019/881), confié à l'ENISA, l'EUCS vise à créer un schéma de certification européen harmonisé pour la cybersécurité des services cloud.

L'objectif affiché est d'en finir avec la fragmentation réglementaire — chaque État membre disposant de ses propres critères, avec SecNumCloud en France, BSI C5 en Allemagne, ENS en Espagne — et de créer un label unique reconnu dans toute l'Union.

Conçu comme un cadre de certification technique pour la sécurité cloud, l'EUCS a déclenché des débats plus larges sur la souveraineté numérique européenne.
Les divergences entre États membres ont paralysé l'adoption du schéma, retardant d'autres initiatives numériques européennes et nationales.

Le nœud du conflit est simple à énoncer : faut-il inclure dans l'EUCS des exigences de souveraineté ?
C'est-à-dire des critères portant sur le lieu d'établissement du prestataire, la localisation des données, et le contrôle capitalistique, au-delà des seuls critères de sécurité technique ?

🔎 BSI C5 (Allemagne)

Le BSI C5 (Cloud Computing Compliance Criteria Catalogue) est le référentiel de certification cloud développé par le BSI (Bundesamt für Sicherheit in der Informationstechnik) — l'équivalent allemand de l'ANSSI française.
Il a été publié pour la première fois en 2016, puis mis à jour en 2020 (C5:2020).

Ce qu'il certifie.
Le C5 évalue la sécurité des services cloud selon 17 domaines thématiques couvrant l'organisation de la sécurité, la gestion des risques, la sécurité physique des datacenters, la cryptographie, la gestion des identités et des accès, la continuité d'activité et la gestion des incidents. Il s'inspire largement des normes internationales ISO 27001 et SOC 2.

Sa spécificité.
Contrairement à SecNumCloud, le C5 est avant tout un référentiel de sécurité technique : il n'impose pas explicitement de critères de souveraineté juridictionnelle tels que le contrôle capitalistique européen ou l'immunité vis-à-vis des lois extraterritoriales étrangères.
Un prestataire américain comme AWS, Microsoft ou Google peut obtenir la certification C5 — et l'a effectivement obtenue pour leurs régions allemandes.
C'est précisément la limite que le débat EUCS cherche à combler.

Sa portée.
Le C5 est reconnu et exigé par les autorités fédérales allemandes pour les services cloud utilisés dans l'administration publique.
Il est également largement adopté par le secteur privé allemand, notamment dans les secteurs financier, industriel et de la santé.
Sa reconnaissance est essentiellement nationale, bien que plusieurs pays européens l'utilisent comme référence.

Son rapport avec le Cloud Sovereignty Framework.
Dans la logique des niveaux SEAL, un service certifié C5 sans critères de souveraineté additionnels se situerait typiquement en SEAL-1 : conformité formelle avec le droit européen, sans protection effective contre les injonctions extraterritoriales américaines.
C'est ce décalage entre la rigueur technique du C5 et l'absence de protection juridictionnelle qui alimente les débats sur la nécessité d'un EUCS High+ incluant des critères de souveraineté.

🔎 ENS (Espagne)

L'ENS (Esquema Nacional de Seguridad — Schéma national de sécurité) est le référentiel espagnol de sécurité des systèmes d'information, établi par le Real Decreto 311/2022 du 3 mai 2022, qui abroge et remplace le décret fondateur de 2010 (Real Decreto 3/2010).

Il est administré conjointement par le Centro Criptológico Nacional (CCN), rattaché au Centre national de renseignement (CNI), et le Ministerio de Asuntos Económicos y Transformación Digital.

Ce qu'il certifie.
L'ENS s'applique à l'ensemble des administrations publiques espagnoles et aux prestataires privés qui leur fournissent des services numériques.
Il définit les principes, exigences et mesures de sécurité que doivent respecter les systèmes d'information traitant des données publiques ou supportant des services publics essentiels.
Il couvre la politique de sécurité, la gestion des risques, la protection des données, la continuité d'activité et la gestion des incidents.

Ses trois niveaux d'assurance.
L'ENS distingue trois niveaux selon la criticité des données et des systèmes :
- Básico : basique, pour les systèmes à faible impact,
- Medio :intermédiaire
- Alto : élevé, pour les systèmes critiques.

Chaque niveau impose des mesures de sécurité progressivement plus strictes.
Les services cloud destinés aux données sensibles de l'administration espagnole doivent obtenir la certification ENS "Alto".

Sa spécificité et ses limites.
Comme le BSI C5, l'ENS est principalement orienté vers la sécurité technique et organisationnelle.
Il n'impose pas de critères de souveraineté juridictionnelle explicites comparables à l'article 19.6 de SecNumCloud.
AWS, Microsoft Azure et Google Cloud ont tous obtenu des certifications ENS pour leurs infrastructures espagnoles, ce qui illustre la même limite que le C5 : la certification ne protège pas contre l'extraterritorialité du CLOUD Act ou du FISA.

Sa portée.
L'ENS est obligatoire pour toutes les administrations publiques espagnoles : État, régions autonomes (communautés autonomes), collectivités locales, ainsi que pour leurs prestataires.
Il est également reconnu et référencé dans plusieurs textes réglementaires sectoriels espagnols (santé, justice, éducation).
Sa reconnaissance est strictement nationale.

Son rapport avec le Cloud Sovereignty Framework.
Dans la logique des niveaux SEAL, un service certifié ENS "nivel Alto" sans mesures de souveraineté additionnelles se situerait en SEAL-1, pour les mêmes raisons que le C5 : droit européen formellement applicable, mais absence de protection effective contre les injonctions extraterritoriales.

Le grand désaccord européen : sécurité vs souveraineté

D'un côté, la France, l'Allemagne, l'Espagne et plusieurs pays d'Europe centrale et orientale poussent pour un niveau "High+" intégrant des critères de souveraineté juridictionnelle — à l'image de ce que SecNumCloud 3.2 impose en France.

L'industrie européenne de la défense, de l'aéronautique et de la sécurité (ASD) appelle fermement à la réintégration d'exigences High+ ou équivalentes dans le corps principal du schéma EUCS, estimant que des solutions d'IA robustes et protectrices ne peuvent être construites sans adresser l'infrastructure cloud sous-jacente.

De l'autre côté, les Pays-Bas, la Suède, la Finlande, le Danemark et plusieurs autres États membres résistent à l'inclusion de critères de souveraineté, estimant qu'ils outrepassent le mandat de cybersécurité de l'ENISA et risquent de fragmenter le marché intérieur.

Les versions antérieures de l'EUCS incluaient des restrictions explicites fondées sur la souveraineté, telles que l'obligation de siège social en Europe et des exclusions juridictionnelles pour les prestataires non-européens.

Ces exigences ont été retirées dans des versions plus récentes, mais restent débattues et pourraient être réintroduites via la législation des États membres ou des textes complémentaires.

Le Centre for European Policy (CEP) recommande à la Commission européenne d'adopter l'EUCS sans exigences de souveraineté dans un premier temps, pour ne pas retarder davantage le renforcement de la cybersécurité des services cloud.
Si l'UE juge les exigences de souveraineté pertinentes, elle devrait les réguler par voie législative, et non exclusivement par voie de règlement d'exécution.

Derrière ce désaccord technique se cache une fracture géopolitique plus profonde.

Les États membres qui résistent aux exigences de souveraineté sont souvent ceux dont les entreprises et administrations sont les plus intégrées dans les écosystèmes des hyperscalers américains, et donc les plus exposées aux coûts de migration.

Ils sont aussi, parfois, ceux qui perçoivent le projet de souveraineté numérique comme une forme de protectionnisme déguisé, susceptible d'alimenter des représailles commerciales américaines dans un contexte géopolitique déjà tendu.

✏️ La Forrester Wave et la capture sémantique : quand le marché définit avant Bruxelles

Pendant que Bruxelles débat, le marché a avancé.

La première Forrester Wave dédiée aux "Sovereign Cloud Platforms", publiée en avril 2026, a classé Microsoft, Google Cloud, AWS, Oracle et Tencent comme Leaders, en s'appuyant sur une définition fonctionnelle de la souveraineté : résidence des données, contrôles de chiffrement, isolation opérationnelle, catalogue de services.

Le problème, pointé avec précision par Calipia en avril 2026, est que cette définition ne recoupe pas celle du Cloud Sovereignty Framework de la Commission.

Forrester mesure la souveraineté fonctionnelle.
Bruxelles mesure la souveraineté juridictionnelle, opérationnelle, stratégique et d'approvisionnement.
Ce sont deux instruments qui ne mesurent pas la même chose — et qui aboutissent à des classements radicalement différents.

C'est ce que Calipia appelle la "capture sémantique" : les hyperscalers ont élargi la frontière du mot "souverain" pour y entrer, au moment précis où Bruxelles cherche à la définir avec précision.

Le résultat est une confusion dans le débat public qui profite aux acteurs dont les offres répondent à la définition fonctionnelle mais pas à la définition juridictionnelle.

L'EUCS face au Cybersecurity Act révisé : une fenêtre d'opportunité

Le 11 avril 2025, la Commission européenne a lancé une consultation publique sur la révision du Cybersecurity Act (Règlement UE 2019/881).

Cette consultation s'inscrit dans l'agenda de simplification de la Commission, et couvre notamment le rôle de l'ENISA et le cadre européen de certification de cybersécurité.

Cette révision du Cybersecurity Act représente une fenêtre d'opportunité politique pour trancher le débat sur l'EUCS.
Si la Commission décide d'inscrire explicitement les exigences de souveraineté dans le texte législatif, et non dans un seul règlement d'exécution, elle résoudrait l'un des arguments centraux des opposants, qui estiment que l'ENISA n'a pas le mandat pour imposer des critères de nature juridique et géopolitique dans un texte censé être purement technique.

Le paysage géopolitique en évolution, notamment la réélection de Donald Trump, est en train de remodeler les priorités européennes et pourrait finalement rapprocher les positions des États membres sur l'EUCS.

L'affaire OVHcloud/Canada (décrite dans cet article de cette série), le rapport FOTI sur le risque de "kill switch" américain (avril 2026), la dissolution du PCLOB par l'administration Trump, et la fragilisation du Data Privacy Framework contribuent à modifier l'équilibre politique en faveur des partisans d'exigences de souveraineté plus strictes.

SecNumCloud, EUCS, Cloud Sovereignty Framework : quel rapport entre ces trois instruments ?

La confusion entre ces trois cadres est fréquente.

Une clarification s'impose.

SecNumCloud 3.2

C'est le référentiel national français, élaboré par l'ANSSI.
C'est aujourd'hui l'instrument le plus exigeant en Europe sur la souveraineté cloud — notamment parce que son article 19.6 impose une immunité vis-à-vis des lois extraterritoriales et un contrôle capitalistique européen majoritaire.
Il s'applique aux prestataires cloud souhaitant répondre aux marchés publics français sensibles et aux OIV/OSE. Son périmètre est national.

L'EUCS

C'est le futur schéma de certification européen harmonisé, développé par l'ENISA sous mandat du Cybersecurity Act.
S'il est adopté avec des exigences de souveraineté significatives à son niveau le plus élevé, il pourrait devenir l'équivalent européen de SecNumCloud, reconnu dans les 27 États membres.
Son adoption est toujours en cours de négociation début 2026.

Le Cloud Sovereignty Framework

C'est un outil contractuel opérationnel, appliqué immédiatement aux achats cloud de la Commission et de ses agences.
Il ne remplace pas l'EUCS.
Il préfigure les critères que l'EUCS devrait idéalement incorporer.
Il sert de référence pratique en attendant qu'un cadre réglementaire contraignant soit adopté.

SecNumCloud 3.2 est conçu comme le modèle dont devrait s'inspirer le niveau le plus exigeant de l'EUCS.
Si cette inspiration se confirme dans la version finale, l'Europe se dotera d'un cadre commun crédible — et les qualifications SecNumCloud actuelles (OVHcloud, Scaleway, S3NS, Cloud Temple, 3DS Outscale...) constitueront une base de qualification pour l'EUCS High+.

Ce que cela signifie pour les organisations

Le cadre réglementaire européen autour de la souveraineté cloud est en construction, mais ses contours sont suffisamment clairs pour orienter des décisions dès aujourd'hui.

Pour les organisations soumises à des obligations réglementaires.

NIS2, DORA, secteur de la santé, défense, OIV... la prudence recommande de s'aligner dès maintenant sur les niveaux SEAL-2 ou SEAL-3 du Cloud Sovereignty Framework, et d'exiger pour les données les plus sensibles une qualification SecNumCloud.
Le risque est d'être contraint à une migration coûteuse si le cadre réglementaire durcit.

Pour les organisations qui ne sont pas encore soumises à des obligations spécifiques.

Le Cloud Sovereignty Framework offre une grille de lecture utile pour évaluer objectivement leurs prestataires actuels, indépendamment des discours commerciaux sur la "souveraineté" qu'emploient aujourd'hui à peu près tous les acteurs du marché.

Pour les prestataires cloud.

Les pondérations du score de souveraineté signalent clairement les dimensions sur lesquelles Bruxelles mettra le plus de pression : la chaîne d'approvisionnement (SOV-5, 20 %), la souveraineté stratégique (SOV-1, 15 %), opérationnelle (SOV-4, 15 %) et technologique (SOV-6, 15 %).
Ce sont ces quatre dimensions qui détermineront l'accès aux marchés publics européens les plus exigeants dans les années à venir.

📌 En conclusion

Le Cloud Sovereignty Framework de la Commission européenne est le premier document officiel à définir opérationnellement ce que signifie "souverain" pour un service cloud, via huit objectifs mesurables (SOV-1 à SOV-8) et cinq niveaux d'assurance gradués (SEAL-0 à SEAL-4).

L'EUCS, le futur schéma de certification européen harmonisé, est toujours en négociation après cinq ans de débat.
Le nœud du conflit est politique autant que technique : faut-il inclure des critères de souveraineté juridictionnelle dans un texte conçu pour la certification de cybersécurité ?

La chaîne d'approvisionnement matérielle (SOV-5, pondération 20 %) est l'objectif le plus lourd dans le score de souveraineté de la Commission.
Ceci fait prendre conscience que la dépendance aux GPU Nvidia et aux puces TSMC est le risque structurel le plus difficile à résorber à court terme.

Le niveau SEAL-4 (souveraineté numérique complète) est aujourd'hui inaccessible pour tout acteur commercial, précisément à cause de cette dépendance matérielle.
Il constitue un horizon normatif adressé autant à l'industrie semiconducteur européenne qu'aux prestataires cloud.

Références

1. Commission européenne, Direction générale des services numériques, Cloud Sovereignty Framework, version 1.2.1, octobre 2025. Document primaire du corpus.
2. ENISA, EUCS — Cloud Services Scheme, première consultation publique, décembre 2020
3. ENISA, Cybersecurity Certification Framework
4. European Union Institute for Security Studies (EUISS), "Technical is political: When a cloud certification scheme divides Europe", novembre 2025
5. Centre for European Policy (CEP), "EU Cloud Certification at an Impasse", avril 2025
6. ITIF, "The EU's Cloud Service Restrictions", mai 2025
7. ASD (Aerospace and Defence Industries Association of Europe), "Revision of the Cybersecurity Act", position paper, juin 2025
8. Skadden, "Latest Draft of the European Cybersecurity Certification Scheme for Cloud Services", novembre 2023
9. Global Regulation Tomorrow, "European Commission consults on review of Cybersecurity Act", avril 2025
10. Calipia, "Cloud souverain : Forrester consacre les hyperscaleurs, l'Europe trébuche sur sa propre définition", avril 2026
11. SFEIR / PAC, "De la souveraineté forteresse à la résilience", livre blanc, 2026.
12. ANSSI, SecNumCloud — Référentiel d'exigences, version 3.2, mars 2022
13. LeMagIT, "Cloud souverain : Bruxelles sélectionne OVHcloud, Scaleway et S3NS", mars 2026
14. Hogan Lovells, "EUCS: Controversial Sovereignty Issues Continue to Drive Debate", juin 2024
15. Règlement UE 2019/881 du Parlement européen et du Conseil du 17 avril 2019 relatif à l'ENISA et à la certification de cybersécurité des technologies de l'information et des communications (Cybersecurity Act)