La souveraineté expliquée
Ce que « cloud souverain » veut vraiment dire
Le « cloud souverain » se vend comme une fonctionnalité unique. C’est en réalité trois garanties distinctes, et un fournisseur peut en offrir une tout en laissant filer les deux autres. Cette page sépare la résidence des données, la souveraineté opérationnelle et l’immunité juridique, pour que vous sachiez laquelle un fournisseur vous vend réellement, et laquelle votre régulateur ou votre direction a réellement demandée.
Ceci est une information générale sur la souveraineté du cloud, pas un conseil juridique. Pour un avis contraignant sur vos obligations, consultez un juriste qualifié.
Les trois couches que l’on confond
La souveraineté n’est pas une propriété unique. La résidence des données concerne l’endroit où les octets reposent. La souveraineté opérationnelle concerne qui peut toucher au système en marche : quel personnel, sous quelle juridiction, avec quel accès d’administration. La souveraineté juridique, parfois appelée immunité aux lois extraterritoriales, concerne la loi qui peut contraindre le fournisseur à livrer les données, où qu’elles soient stockées.
Un fournisseur peut réussir la première et échouer à la dernière. Une région européenne détenue par une société américaine garde vos données à Francfort et laisse tout de même la maison mère soumise aux injonctions américaines. La résidence répond à une question de stockage ; l’immunité répond à une question de contrôle. Les acheteurs demandent souvent la première quand leur régulateur pensait à la troisième.
La résidence des données : nécessaire, pas suffisante
La résidence des données, c’est l’engagement du fournisseur à stocker, et souvent traiter, vos données dans une géographie choisie, en général l’UE ou un seul État membre. C’est la couche la plus simple à livrer et à vérifier : vous choisissez une région européenne et vos objets, bases et sauvegardes y restent.
Et cela s’arrête là. La résidence ne dit rien de qui administre la plateforme, d’où sont assis les ingénieurs de support, ni du gouvernement qui peut légalement en exiger une copie. Prendre une « région européenne » pour de la souveraineté est le contresens le plus fréquent et le plus coûteux : on croit la case cochée alors que seule la couche la plus superficielle l’est.
La souveraineté opérationnelle : qui détient les clés
La souveraineté opérationnelle couvre les humains et les processus disposant d’un accès privilégié. Un ingénieur de support hors UE peut-il endosser un rôle d’administration sur votre tenant ? Les clés de chiffrement sont-elles détenues par vous, par le fournisseur, ou par un module matériel que le fournisseur contrôle in fine ? Le plan de contrôle, les API qui créent et détruisent vos ressources, est-il exploité depuis la même juridiction que les données ?
C’est là que fuient les offres « souveraines » limitées à la résidence. Les données restent en région, mais la plateforme est toujours administrée, corrigée et supportée à l’échelle mondiale. Pour une charge régulée, la frontière administrative compte autant que la frontière de stockage.
La souveraineté juridique : quelle loi atteint le fournisseur
La souveraineté juridique est la couche que la résidence ne peut pas acheter. Elle pose une seule question : si une autorité hors UE signifie une injonction légale au fournisseur ou à sa maison mère, celui-ci est-il contraint d’obéir ? Pour une société soumise au droit américain, la réponse sous le CLOUD Act est oui, où que soient les serveurs.
L’immunité aux lois extra-européennes est donc fonction de la propriété et du contrôle, pas de la géographie. C’est le critère que la qualification française SecNumCloud place en son cœur, et celui qu’une garantie de résidence, seule, n’aborde jamais.
Ce que « souverain » ne garantit pas
Il n’existe pas de définition juridique unique du « cloud souverain » en droit de l’UE, et c’est précisément pour cela que le mot est disputé. Le schéma européen de certification (EUCS) a passé des années à débattre de l’opportunité d’exiger, pour un niveau « élevé », l’immunité aux lois non européennes ; les critères de souveraineté ont été atténués puis réintroduits plus d’une fois. Un fournisseur qui se dit souverain décrit une position marketing, pas un fait certifié, tant qu’il ne nomme pas un schéma et un niveau précis.
La réponse honnête tient donc en une question : de quelle couche parle-t-on ? « Souverain » sans qualificatif signifie en général la résidence. Si votre exigence est l’immunité juridique, la résidence n’y suffira pas, et aucun nombre de datacentres européens ne change la juridiction dont répond la maison mère du fournisseur.
Questions fréquentes sur le cloud souverain
- Une région européenne d’un fournisseur américain est-elle souveraine ?
- Elle vous donne la résidence des données, pas la souveraineté juridique. Les données restent dans l’UE, mais la maison mère américaine reste soumise au droit américain, CLOUD Act compris, et peut donc être contrainte de produire des données détenues n’importe où dans son parc. Si votre exigence est l’immunité à une juridiction non européenne, une région européenne seule n’y répond pas.
- Le chiffrement rend-il un cloud souverain ?
- Seulement si vous détenez les clés en exclusivité, hors de portée du fournisseur. Si le fournisseur gère les clés, ou peut être contraint de les produire avec les données, le chiffrement augmente l’effort mais ne change pas qui détient le contrôle juridique. Des clés détenues par le client aident la souveraineté opérationnelle ; elles n’accordent pas à elles seules l’immunité juridictionnelle.
- Quelle couche de souveraineté mon régulateur vise-t-il ?
- Cela dépend du régime. Le RGPD porte sur le transfert et l’accès licites aux données personnelles. Des règles sectorielles comme DORA et NIS2 visent la résilience opérationnelle et le contrôle des tiers. La doctrine de l’État français et SecNumCloud ciblent l’immunité juridique des données sensibles. Reliez votre exigence à la bonne couche avant de présélectionner des fournisseurs.