Souveraineté numérique : ce que le cloud souverain change vraiment

La souveraineté numérique, c'est la capacité à garder la maîtrise de ses données et de ses systèmes sans dépendre de décisions prises hors de son cadre juridique. En France, le débat se cristallise sur le cloud souverain : faut-il héberger ses données sensibles chez un opérateur européen qualifié, ou un datacenter en Europe chez un géant américain suffit-il ? La réponse tient en une idée, que cet article déroule : ce n'est pas le lieu de stockage qui protège, c'est la juridiction du fournisseur. Pour le détail de la qualification de l'ANSSI, voyez notre article sur SecNumCloud.

Le 10 juin 2025, devant la commission d'enquête du Sénat sur la commande publique, le rapporteur a demandé au directeur des affaires publiques et juridiques de Microsoft France s'il pouvait garantir que les données des administrations, achetées via l'UGAP, ne seraient jamais transmises aux autorités américaines sans l'accord des autorités françaises. Réponse : « Non, je ne peux pas le garantir », en précisant que cela ne s'était encore jamais produit. Cette réponse résume le débat : un engagement contractuel ne lie pas les autorités d'un autre pays.

Quelques mois plus tard, le 31 octobre 2025, la Cour des comptes publiait un rapport sur les enjeux de souveraineté des systèmes d'information civils de l'État. Elle y relève l'opacité de l'application des lois américaines (CLOUD Act et section 702 du FISA), constate que la doctrine « cloud au centre » de juillet 2021 a été affaiblie dans sa mise en œuvre, que les clouds ministériels (Nubo et Pi) restent peu utilisés, et cite l'hébergement du Health Data Hub chez Microsoft Azure. Pour la Cour, la maîtrise des données sensibles est la voie d'accès à la souveraineté.

Le sujet ne concerne pas que l'État. Collectivités, hôpitaux, industriels et entreprises régulées se posent la même question à chaque renouvellement de contrat : quelles données peut-on confier à quel fournisseur ?

Beaucoup d'offres mettent en avant des « données hébergées en France ». C'est utile, mais cela ne répond pas à la question de l'accès par une autorité étrangère. Le CLOUD Act, adopté par le Congrès américain en 2018, oblige les fournisseurs soumis au droit américain à préserver et communiquer les données « en leur possession, sous leur garde ou sous leur contrôle », que ces données soient situées aux États-Unis ou à l'étranger. Une filiale européenne ou un datacenter à Paris ne changent rien si la maison mère peut être contrainte.

Deux autres confusions reviennent souvent :

• Transfert RGPD et accès extraterritorial : le cadre de protection des données UE–États-Unis (Data Privacy Framework), validé par le Tribunal de l'Union européenne le 3 septembre 2025, encadre les transferts de données personnelles. Il ne rend pas un fournisseur américain imperméable aux demandes de ses autorités, et il ne couvre pas vos données non personnelles, comme vos secrets d'affaires.
• Chiffrement : il réduit le risque, à condition que le fournisseur n'ait pas accès aux clés. Si le service doit déchiffrer les données pour les traiter, la protection dépend de nouveau de la juridiction de l'opérateur.

Aucun texte ne définit le « cloud souverain ». Le terme recouvre des offres très différentes, qu'on peut classer selon ce qu'elles garantissent réellement :

En France, la seule garantie vérifiée par un tiers est la qualification SecNumCloud. L'ANSSI la présente comme un moyen de protéger les données sensibles à la fois contre la cybercriminalité et contre l'application de lois extraterritoriales. Au niveau européen, le schéma de certification EUCS, en discussion depuis 2020, devait jouer ce rôle : ses critères de souveraineté ont été retirés du projet en 2024. Faute de critère européen commun, ce sont les États, comme la France, qui fixent leurs propres exigences.

Pour l'État : la loi SREN et le décret d'avril 2026

L'article 31 de la loi du 21 mai 2024 visant à sécuriser et réguler l'espace numérique (loi SREN) a posé le principe. Son décret d'application, le décret n° 2026-272 du 14 avril 2026, et un arrêté du même jour l'ont rendu opérationnel. Selon la fiche technique de la direction des affaires juridiques de Bercy publiée le 6 mai 2026 :

• les administrations de l'État, leurs opérateurs et les groupements d'intérêt public qui confient à un cloud privé des données d'une sensibilité particulière doivent recourir à une offre qualifiée SecNumCloud, qui les protège contre l'accès d'autorités d'États tiers non autorisé par le droit de l'Union ;
• une dérogation temporaire est possible lorsqu'aucune offre adaptée n'existe ;
• des clauses types (sécurité, réversibilité, souveraineté) sont proposées aux acheteurs.

Les collectivités ne sont pas visées par ce décret, mais elles peuvent s'en inspirer dans leurs marchés. Notre page cybersécurité du secteur public détaille les autres exigences qui s'appliquent aux administrations.

Pour la santé : HDS, et peut-être plus

Les données de santé relèvent de la certification HDS, qui ne comporte pas aujourd'hui de critères d'immunité équivalents. La Cour des comptes recommande justement d'aligner le référentiel HDS sur les exigences de SecNumCloud, ce qui en ferait un sujet de souveraineté pour tous les hébergeurs de santé.

Pour les entreprises : pas d'obligation générale

NIS 2 n'impose pas de cloud souverain. Elle impose en revanche de maîtriser les risques liés à la chaîne d'approvisionnement, ce qui inclut le choix des hébergeurs (voir notre article sur les exigences de NIS 2 et DORA envers les tiers). Le risque d'accès par une autorité étrangère fait partie des risques à évaluer, au même titre que la disponibilité ou la réversibilité.

Pour le cloud souverain

• Une protection vérifiable : la qualification SecNumCloud est contrôlée par l'ANSSI, là où une promesse contractuelle d'un fournisseur soumis à une loi étrangère ne lie pas ses autorités.
• Une dépendance moindre : la Cour des comptes pointe le risque de dépendance technologique et recommande de fixer dès 2026 un calendrier pour des outils bureautiques souverains, et de faire converger les clouds ministériels.
• Un levier pour l'écosystème : la commande publique oriente le marché. Sans clients, les offres européennes ne peuvent pas rattraper leur retard fonctionnel.

Les limites

• Le coût et le catalogue : les offres qualifiées proposent souvent moins de services avancés (IA, analyse de données) et peuvent coûter plus cher, d'où la dérogation prévue par le décret.
• La souveraineté n'est pas la sécurité : l'ANSSI rappelle que la qualification d'un prestataire ne préjuge pas de la sécurité du système d'information du client. Une application mal configurée sur un cloud qualifié reste vulnérable.
• Le cloud n'est qu'une couche : messagerie, bureautique, logiciels métier et outils d'IA posent la même question. Héberger ses serveurs en France tout en confiant ses documents à une suite bureautique américaine ne règle qu'une partie du problème.

Plutôt que de trancher le débat dans l'absolu, traitez-le comme une décision de risque, donnée par donnée :

1. Classer les données : évaluez leur sensibilité en disponibilité, intégrité, confidentialité et traçabilité (la méthode DICP), et repérez celles qui relèvent d'une obligation (données de l'État, santé, secret des affaires, données classifiées).
2. Évaluer le risque juridique : intégrez l'accès par une autorité étrangère à votre analyse de risques, avec sa vraisemblance et sa gravité, à côté des menaces techniques. C'est ce qui permet de justifier, ou non, le surcoût d'une offre qualifiée.
3. Interroger les fournisseurs : dans votre questionnaire de sécurité fournisseur, demandez la nationalité de la maison mère et la structure de l'actionnariat, le lieu de stockage et d'administration, la liste des sous-traitants, les certifications (SecNumCloud, HDS, ISO 27001) et la politique de réponse aux demandes des autorités. C'est le cœur d'une démarche de gestion des risques tiers.
4. Contractualiser la sortie : prévoyez la réversibilité (formats, délais, assistance) dans le contrat ou le plan d'assurance sécurité. Une souveraineté sans possibilité de partir n'en est pas une.