Cloud souverain : les 8 dimensions qui permettent enfin de mesurer la souveraineté
Le Cloud Sovereignty Framework de la Commission européenne transforme la souveraineté en critères mesurables, avec huit dimensions et des niveaux SEAL.
Le Cloud Sovereignty Framework de la Commission européenne transforme la souveraineté en critères mesurables, avec huit dimensions et des niveaux SEAL.
Action : identifiez les actifs, dépendances et preuves concernés avant de traiter le sujet comme une exigence isolée.
« Les données sont hébergées en Europe. »
Cette phrase est souvent utilisée pour justifier le caractère souverain d’une offre cloud.
Elle ne suffit pourtant pas à décrire la souveraineté d’un service numérique.
Une plateforme peut héberger ses données dans l’Union européenne tout en dépendant fortement d’une technologie, d’une chaîne d’approvisionnement, d’un contrôle opérationnel ou d’un fournisseur extérieur à l’UE.
En 2026, la Commission européenne a commencé à rendre cette notion beaucoup plus mesurable.
Son Cloud Sovereignty Framework transforme la souveraineté numérique en critères d’évaluation structurés et introduit plusieurs niveaux de garantie, les Sovereignty Effectiveness Assurance Levels — SEAL.1
L’intérêt de ce cadre dépasse largement les marchés publics européens.
Il permet surtout de poser une meilleure question lorsqu’une entreprise choisit un cloud : de quoi ce service dépend-il réellement, et qui conserve le pouvoir de le faire fonctionner ?
La localisation des données n’est qu’une dimension
La souveraineté des données reste importante.
Il faut savoir où les données sont stockées, où elles sont traitées, qui peut techniquement y accéder, quelle juridiction s’applique et comment sont gérées les clés cryptographiques.
Mais le Cloud Sovereignty Framework va plus loin.
La Commission évalue la souveraineté selon huit objectifs, couvrant notamment les dimensions stratégique, juridique, données & IA, opérationnelle, supply chain, technologique, sécurité/conformité et environnementale.1
La souveraineté devient donc une propriété de l’architecture dans son ensemble.
1. Souveraineté stratégique
La première question est celle du contrôle à long terme.
Qui possède la technologie ? Où sont détenus les droits de propriété intellectuelle ? Qui contrôle les principales décisions d’évolution ?
Une solution peut être opérée en Europe tout en dépendant entièrement d’une technologie contrôlée ailleurs.
Cela ne signifie pas nécessairement qu’elle est inadaptée, mais le niveau de dépendance stratégique doit être connu.
La question à poser n’est donc pas uniquement « où est situé le fournisseur ? », mais « qui contrôle les actifs technologiques sans lesquels le service ne peut plus évoluer ? ».
2. Souveraineté juridique et juridictionnelle
La localisation physique d’un datacenter et la juridiction applicable à son fournisseur sont deux sujets différents.
Une entreprise peut exploiter une infrastructure située en France tout en étant soumise à des obligations juridiques provenant d’un autre pays.
L’analyse doit donc prendre en compte la localisation de l’entité contractante, la structure du groupe, les juridictions applicables, les conditions d’accès potentiel aux données et les mécanismes juridiques de protection.
La souveraineté juridique ne peut pas être déduite uniquement de l’adresse du datacenter.
3. Souveraineté des données et de l’IA
Le cadre européen s’intéresse notamment au contrôle effectif des données, à leur stockage, à leur traitement, aux mécanismes cryptographiques et aux dépendances liées aux modèles et pipelines d’IA.1
Pour le client, plusieurs questions deviennent déterminantes : qui contrôle réellement les clés de chiffrement ? le fournisseur peut-il accéder aux données sans intervention du client ? les données peuvent-elles être déplacées hors de la juridiction prévue ? les services d’IA utilisent-ils ou conservent-ils certaines données ? peut-on démontrer leur suppression ?
Deux offres hébergeant les données dans le même pays peuvent avoir des réponses très différentes.
4. Souveraineté opérationnelle
Un service peut être hébergé et juridiquement encadré en Europe tout en dépendant d’équipes ou de composants opérationnels situés ailleurs.
Il faut donc regarder qui administre réellement la plateforme, qui possède les droits les plus élevés, quelles équipes peuvent intervenir, où sont opérés les services critiques et ce qui se produit si certaines équipes ou technologies deviennent indisponibles.
La souveraineté opérationnelle mesure en quelque sorte la capacité à continuer à exploiter le service même lorsque certaines dépendances externes disparaissent.
5. Souveraineté de la chaîne d’approvisionnement
C’est probablement l’une des dimensions les moins visibles.
Un fournisseur cloud possède lui-même des fournisseurs : serveurs, composants électroniques, hyperviseurs, logiciels, services réseau, outils de sécurité et technologies d’orchestration.
Une offre peut donc apparaître européenne au niveau commercial tout en reposant fortement sur une supply chain extérieure.
Le niveau SEAL le plus élevé décrit justement une exigence très forte de chaîne d’approvisionnement européenne, jusqu’aux couches technologiques profondes.2
La souveraineté devient ici une carte de dépendances, pas un label.
6. Souveraineté technologique
Une question simple permet de mesurer cette dimension : que se passerait-il si le fournisseur principal de la technologie arrêtait demain de fournir des mises à jour ou des licences ?
Un cloud peut être exploité en Europe tout en dépendant profondément d’un hyperviseur propriétaire, d’une base de données propriétaire, d’une plateforme logicielle externe ou d’une architecture matérielle spécifique.
La capacité à maintenir, faire évoluer ou remplacer ces briques détermine une partie de l’autonomie technologique.
La portabilité est donc importante. Mais elle doit être mesurée réellement.
Pouvoir exporter une machine virtuelle n’est pas équivalent à pouvoir migrer une application utilisant quinze services managés propriétaires.
7. Sécurité et conformité
Souveraineté et cybersécurité ne sont pas synonymes.
Un service peut être souverain et mal sécurisé. Un service peut également disposer d’excellentes certifications sans offrir un niveau élevé de souveraineté.
Le cadre de la Commission traite donc séparément les dimensions relatives à la sécurité et à la conformité.1
Cela évite un raccourci fréquent : certifié = souverain.
Une certification répond à un référentiel déterminé. Elle ne décrit pas nécessairement toutes les dépendances géopolitiques, technologiques ou opérationnelles du service.
8. Dimension environnementale
La Commission intègre aussi une dimension environnementale dans son cadre d’évaluation.1
Cette présence peut surprendre.
Elle reflète pourtant une conception plus large de la souveraineté : la capacité à disposer durablement d’une infrastructure numérique dépend également de son efficacité, de son approvisionnement énergétique et de la soutenabilité de son exploitation.
Pour une entreprise, cette dimension sera souvent moins déterminante que la juridiction ou la technologie, mais elle complète l’analyse.
Les niveaux SEAL permettent de sortir du débat binaire
L’un des apports les plus intéressants du framework est d’éviter la classification souverain / non souverain.
La Commission utilise plusieurs niveaux SEAL, de SEAL-0 à SEAL-4.2
Dans le marché cloud attribué en avril 2026, les fournisseurs devaient atteindre au moins SEAL-2, correspondant à un niveau de souveraineté des données.
La majorité des offres retenues ont atteint SEAL-3, que la Commission associe à un niveau de résilience numérique plus élevé face aux perturbations provenant de fournisseurs non européens.2
Cette approche est beaucoup plus réaliste.
La souveraineté devient un niveau de maîtrise, pas une propriété absolue.
Cas construit : trois clouds, trois profils de souveraineté
Prenons trois fournisseurs fictifs.
Le Cloud A héberge les données en France et est exploité par une entreprise française, mais utilise une technologie propriétaire contrôlée par une entreprise extra-européenne. Le niveau de souveraineté des données peut être élevé, la souveraineté technologique plus faible.
Le Cloud B développe sa propre stack et garde ses opérations et données dans l’Union européenne, mais certains composants matériels et logiciels critiques sont issus de fournisseurs extérieurs à l’UE. Son autonomie technologique est meilleure, mais sa supply chain n’est pas entièrement européenne.
Le Cloud C stocke également les données en Europe, utilise largement des technologies ouvertes et possède une forte capacité de portabilité, mais certaines fonctions d’administration reposent sur un groupe soumis à une juridiction extérieure.
Les trois offres peuvent communiquer sur la souveraineté. Elles ne présentent pourtant pas le même profil.
Il faut donc cartographier la souveraineté
Une analyse concrète pourrait utiliser une représentation simple : service cloud → données → juridiction → opérations → technologies → composants critiques → fournisseurs → dépendances externes → alternatives.
Pour chaque relation, l’entreprise peut ensuite évaluer localisation, contrôle, possibilité d’interruption, difficulté de remplacement, dépendance à une juridiction extérieure et délai de migration.
On passe alors d’une discussion marketing à une analyse d’architecture.
La Commission a déjà utilisé son propre cadre dans un marché de 180 millions d’euros
Le framework n’est pas uniquement théorique.
En avril 2026, la Commission a attribué quatre contrats de cloud souverain représentant jusqu’à 180 millions d’euros sur six ans.2
Les fournisseurs retenus ont été évalués selon ce cadre.
La Commission explique explicitement que l’objectif était de transformer la souveraineté numérique en critères mesurables et standardisés.2
La souveraineté commence donc à devenir une caractéristique pouvant être comparée, documentée et auditée.
Un exercice simple avant un prochain choix cloud
Avant de sélectionner un fournisseur, prendre un service critique et répondre à huit questions : qui contrôle la technologie ? quelle juridiction s’applique réellement ? qui contrôle les données et les clés ? qui exploite le service ? de quels fournisseurs dépend-il ? peut-on remplacer les briques technologiques ? quel est son niveau réel de sécurité et de conformité ? quels facteurs environnementaux conditionnent son exploitation ?
Si une réponse repose uniquement sur une brochure commerciale, l’analyse n’est probablement pas terminée.
Le principal apport du Cloud Sovereignty Framework est peut-être précisément celui-ci : la souveraineté n’est plus seulement quelque chose qu’un fournisseur affirme. Elle peut devenir quelque chose qu’un client vérifie.
RÉFÉRENCES
Sources vérifiées le 7 septembre 2026 · 3 sources
- [1] Source officielleSovereign Cloud Framework explained
- [2] Source officielleCommission advances cloud sovereignty through strategic procurement
- [3] Source officielleCloud Sovereignty Framework - Implementation guidance
Les références sont affichées pour permettre la vérification. Une source officielle ne signifie pas que Cybercoria lui attribue une conclusion qu’elle ne formule pas.