Cloud souverain : le cadre juridique en 2026

Le 10 juin 2025, devant la commission d’enquête du Sénat sur la commande publique, le directeur juridique de Microsoft France a répondu sous serment qu’il ne pouvait pas garantir que les données de l’État français échapperaient à une injonction judiciaire américaine. Neuf mois plus tard, le décret n° 2026-272 du 14 avril 2026 obligeait une partie des administrations à migrer vers des offres qualifiées. Entre les deux, beaucoup de DSI et de DPO ont découvert que « cloud souverain » n’était pas un label mais une question à quatre étages — dont un seul est réellement contraignant pour le secteur privé.

Voici ce que le droit impose réellement en septembre 2026, ce qu’il n’impose pas, et comment arbitrer sans se payer de mots.

Cloud souverain : ce que l’expression recouvre juridiquement

L’expression n’a aucune définition légale en droit français. C’est la première chose à comprendre : quand un fournisseur vous vend du « cloud souverain », il peut désigner quatre réalités très différentes, dont trois sont assez faibles.

Niveau 1 — la localisation des données. Les serveurs sont dans l’Union européenne. C’est le niveau que la plupart des hyperscalers américains atteignent depuis des années avec leurs régions européennes. C’est aussi le plus trompeur : la localisation physique ne dit rien du droit applicable au fournisseur.

Niveau 2 — la localisation du support et de l’exploitation. Non seulement les données, mais aussi l’administration technique (support de niveau 3, télémaintenance, journaux d’exploitation) restent dans l’UE. C’est ce que visent les offres « EU Data Boundary » et assimilées. Le progrès est réel, mais l’administration reste opérée par des salariés d’un groupe soumis à un droit tiers.

Niveau 3 — l’immunité aux lois extraterritoriales. Le fournisseur n’est pas juridiquement contraignable par une autorité étrangère : ni lui, ni sa maison mère, ni aucune entité de son groupe ne relève de la juridiction américaine, chinoise ou autre. C’est le niveau visé par la qualification SecNumCloud de l’ANSSI dans sa version 3.2.

Niveau 4 — le contrôle capitalistique. Le siège, l’actionnariat de contrôle et le centre de décision sont européens. C’est le critère le plus exigeant, et celui qui a fait exploser les négociations européennes des trois dernières années.

Dans mon expérience de conseil, la quasi-totalité des malentendus contractuels sur ce sujet vient de la confusion entre les niveaux 1 et 3. Un contrat qui garantit l’hébergement en France ne garantit rien sur l’accès des autorités étrangères. Ce sont deux clauses distinctes, et la seconde est presque toujours absente.

Le conflit Cloud Act / RGPD : pourquoi il n’est pas soluble par contrat

Le CLOUD Act américain du 23 mars 2018 permet aux autorités des États-Unis d’exiger d’un fournisseur soumis à leur juridiction la communication de données qu’il « possède, détient ou contrôle », y compris lorsque ces données sont stockées hors du territoire américain. Le critère est le rattachement du fournisseur, pas celui de la donnée.

Côté européen, l’article 48 du RGPD pose le principe inverse : une décision d’une autorité d’un pays tiers exigeant le transfert de données personnelles n’est exécutoire que si elle repose sur un accord international en vigueur, du type traité d’entraide judiciaire. Aucun accord de ce type ne couvre aujourd’hui les injonctions CLOUD Act adressées directement aux fournisseurs.

Le fournisseur placé entre les deux est donc dans une situation de conflit de lois qu’aucune clause contractuelle ne résout. Il violera soit le droit américain, soit le RGPD. C’est exactement ce qu’a reconnu Microsoft France devant le Sénat, et c’est la même logique juridique qui avait conduit la CJUE à invalider le Privacy Shield dans l’arrêt Schrems II du 16 juillet 2020.

Deux précisions s’imposent, parce qu’elles sont systématiquement oubliées.

D’abord, le Data Privacy Framework ne règle pas ce problème. Il traite de l’accès des agences de renseignement américaines au titre de la section 702 FISA et de l’EO 12333, avec des garanties de proportionnalité et un mécanisme de recours. Le CLOUD Act, lui, relève de la coopération pénale ordinaire et n’entre pas dans le champ de la décision d’adéquation.

Ensuite, le risque est statistiquement faible mais juridiquement certain. Le nombre d’injonctions CLOUD Act visant des données européennes reste modeste au regard du volume total. Mais en matière de conformité, on ne raisonne pas en probabilité : on raisonne en capacité à démontrer une garantie. Si vous ne pouvez pas démontrer que l’accès est impossible, vous devez le documenter comme un risque résiduel dans votre analyse d’impact sur le transfert.

Ce que le RGPD impose réellement (et ce qu’il n’impose pas)

Point capital, et contre-intuitif pour beaucoup : le RGPD n’impose pas le cloud souverain. Il n’impose même pas l’hébergement dans l’Union européenne.

Ce qu’il impose est plus subtil :

• Art. 5(1)(f) et art. 32 — une sécurité appropriée au risque, ce qui inclut la confidentialité vis-à-vis de tiers non autorisés. Voir le détail des mesures attendues dans notre guide sur l’article 32 du RGPD.
• Art. 28 — un contrat de sous-traitance en bonne et due forme avec le fournisseur cloud, incluant l’encadrement des sous-traitants ultérieurs. Les hyperscalers ont tous un DPA standard : encore faut-il vérifier qu’il couvre l’ensemble des exigences de l’article 28 et que la liste des sous-traitants ultérieurs est réellement à jour.
• Art. 44 à 49 — l’encadrement des transferts hors UE, par décision d’adéquation, clauses contractuelles types ou dérogation.
• Art. 48 — le refus des injonctions étrangères non fondées sur un accord international.

Autrement dit : le RGPD vous laisse choisir un fournisseur américain, à condition que vous ayez évalué le risque, documenté les mesures supplémentaires et pu conclure que le niveau de protection reste essentiellement équivalent. C’est précisément ce que la plupart des organisations ne font pas sérieusement.

Il est recommandé, quand vous instruisez ce type de dossier, de distinguer trois catégories de traitements plutôt que d’appliquer une règle unique : les traitements courants sans sensibilité particulière (bureautique, marketing), les traitements sensibles au sens de l’article 9 ou porteurs d’un risque élevé, et les traitements couverts par un secret protégé (secret médical, secret des affaires, secret de la défense nationale). L’arbitrage cloud n’a pas à être le même pour les trois.

Le décret SREN du 14 avril 2026 : la première obligation dure en droit français

L’article 31 de la loi n° 2024-449 du 21 mai 2024 visant à sécuriser et réguler l’espace numérique (SREN) avait posé le principe : les administrations, opérateurs de l’État et certains groupements d’intérêt public ne peuvent recourir à un service cloud privé pour traiter des données d’une sensibilité particulière que sous réserve d’exigences renforcées de sécurité, de protection et de contrôle. Il restait à définir « sensibilité particulière ». C’est chose faite depuis le décret n° 2026-272 du 14 avril 2026.

Quelles données sont visées

Deux catégories, alternatives :

1. Les données relevant de secrets protégés par la loi, notamment au titre des articles L. 311-5 et L. 311-6 du code des relations entre le public et l’administration : secret de la défense nationale, secret médical, secret des affaires, secret de l’enquête et de l’instruction.
2. Les données nécessaires à l’accomplissement des missions essentielles de l’État : sauvegarde de la sécurité nationale, maintien de l’ordre public, protection de la santé et de la vie des personnes.

Le décret liste également les six GIP concernés : agence du numérique en santé, centre d’accès sécurisé aux données, centre ressources prévention de la radicalisation, collecteur analyseur de données, modernisation des déclarations sociales, système national d’enregistrement de la demande de logement social.

Dix domaines d’exigences, un référentiel à venir

Le décret ne fixe pas les exigences techniques lui-même : il renvoie à un référentiel de sécurité que l’ANSSI doit élaborer, et énumère les dix domaines qu’il couvrira. Trois méritent d’être signalés dès maintenant, parce qu’ils auront un impact contractuel direct :

• La réversibilité : le contrat devra comporter une clause permettant la récupération effective des données. C’est une convergence bienvenue avec les obligations de portabilité du Data Act.
• La localisation et l’actionnariat : localisation de l’hébergement, conditions de transfert vers un État tiers, localisation du siège ou du principal établissement du prestataire, et structure de son actionnariat. Le niveau 4 de notre typologie entre ici dans le droit positif.
• La protection contre l’accès d’autorités étrangères non autorisées : le niveau 3, formulé sans ambiguïté.

Le décret prévoit par ailleurs que les prestataires respectant le futur référentiel feront l’objet d’une certification ou d’une qualification de type SecNumCloud ou équivalente.

Le régime dérogatoire, révélateur

L’article 3 du décret organise des dérogations pour les projets engagés avant son entrée en vigueur. La dérogation est accordée par le ministre compétent, après validation du Premier ministre, pour une durée limitée : jusqu’à dix-huit mois lorsqu’une offre « acceptable » existe en France, un an renouvelable lorsqu’aucune offre acceptable n’est disponible. Une offre est acceptable quand elle répond aux besoins fonctionnels de l’organisme, coût compris.

Cette dernière formule est très large et laisse une marge d’appréciation considérable. Elle en dit long sur la difficulté réelle de la migration : le législateur sait que certaines briques logicielles n’ont pas d’équivalent souverain à ce jour.

Si vous travaillez pour une collectivité territoriale, notez que le dispositif vise les administrations et opérateurs de l’État : les collectivités ne sont pas directement dans le champ de l’article 31. Elles restent en revanche soumises au RGPD, à NIS2 lorsqu’elles sont désignées, et à la doctrine « cloud au centre » lorsqu’elles utilisent des services mutualisés de l’État.

SecNumCloud 3.2 : ce que la qualification garantit vraiment

Le référentiel SecNumCloud de l’ANSSI est aujourd’hui le seul dispositif européen à intégrer un critère d’immunité aux lois extraterritoriales. La version 3.2, publiée en 2022, exige notamment que le siège social du prestataire soit établi dans l’UE, et que le contrôle capitalistique ne permette pas à une entité soumise à un droit tiers d’imposer un accès aux données.

Ce que la qualification apporte :

• plus de 360 exigences techniques et organisationnelles, auditées par un prestataire d’audit qualifié PASSI ;
• une immunité juridique documentée, opposable ;
• la présomption de conformité pour les usages du secteur public soumis à l’article 31 SREN ;
• un socle solide au regard de l’article 32 du RGPD.

Ce qu’elle n’apporte pas, et c’est là que les projets déraillent :

• Elle ne porte que sur le périmètre qualifié. Un fournisseur peut être qualifié sur son IaaS et pas sur son PaaS managé. Vérifiez systématiquement le scope exact sur le site de l’ANSSI, pas la plaquette commerciale.
• Elle ne vous dispense d’aucune obligation RGPD. Registre, AIPD quand elle est requise, contrat de sous-traitance, information des personnes : tout reste dû.
• Elle ne dit rien de la sécurité de votre configuration. La responsabilité partagée reste la règle : le fournisseur sécurise le service, vous sécurisez ce que vous y déployez. Un bucket mal configuré chez un prestataire qualifié reste une violation de données.
• Elle ne couvre pas la couche applicative que vous achetez par-dessus. C’est le point aveugle des offres SaaS revendues « hébergées SecNumCloud ».

Sur le fond du sujet et la liste des offres actuellement qualifiées, voir notre article dédié à la qualification SecNumCloud, et pour le cadre général des obligations, notre guide sur la sécurité du cloud.

EUCS et CADA : où en est l’Europe

Le schéma européen de certification de cybersécurité des services cloud (EUCS), élaboré par l’ENISA au titre du Cybersecurity Act, devait transposer au niveau européen la logique SecNumCloud. Il prévoyait initialement, pour son niveau d’assurance le plus élevé, des exigences de souveraineté proches du référentiel français.

Ces exigences ont été retirées sous la pression conjointe de plusieurs États membres et de l’industrie, et l’adoption du schéma reste gelée. Conséquence pratique : un service certifié EUCS au niveau « élevé » n’exclut pas l’exposition au CLOUD Act. Si vous voyez apparaître cette certification dans une réponse à appel d’offres comme preuve de souveraineté, la démonstration est incomplète.

La Commission a présenté le 3 juin 2026 un projet de règlement Cloud and AI Development Act (CADA), qui réintroduit le critère par une autre porte : celle de la commande publique. Le texte propose une grille d’évaluation de la souveraineté à quatre niveaux, allant de la simple localisation européenne des infrastructures jusqu’à l’absence d’ingérence d’un pays tiers et au contrôle capitalistique européen du fournisseur. Ses articles 29 et 30 imposeraient aux administrations d’évaluer la dépendance de leurs systèmes aux services cloud externes, de les classer selon un niveau d’assurance requis, puis d’acheter en conséquence.

Attention au calendrier : il s’agit d’une proposition. Entre les négociations en trilogue et la période transitoire, une entrée en application avant deux à trois ans est peu vraisemblable. Ne construisez pas votre feuille de route sur ce texte ; construisez-la sur le décret SREN et sur vos obligations sectorielles, qui sont déjà là.

Les régimes sectoriels qui priment sur le débat général

Pour beaucoup d’organisations, la question du cloud souverain est en réalité tranchée en amont par une réglementation sectorielle.

Santé. L’hébergement de données de santé à caractère personnel impose la certification HDS, avec des exigences propres et une articulation spécifique avec le RGPD. C’est un régime distinct de SecNumCloud, même si les deux se recoupent partiellement. Voir notre guide sur l’hébergement de données de santé.

Finance. Le règlement DORA encadre le recours aux prestataires TIC : registre des accords, clauses obligatoires, stratégie de sortie, tests de résilience. La souveraineté n’y est pas une exigence en soi, mais la maîtrise de la concentration et de la réversibilité l’est. Voir notre guide DORA et l’article sur la sous-traitance TIC.

Entités essentielles et importantes. NIS2 impose une gestion des risques de la chaîne d’approvisionnement, ce qui inclut vos fournisseurs cloud. La sous-traitance sous NIS2 devient un objet d’audit à part entière.

Tous secteurs. Le Data Act, applicable depuis le 12 septembre 2025, crée des droits de changement de fournisseur cloud, de suppression progressive des frais de transfert et d’interopérabilité. Il ne traite pas de souveraineté, mais il détruit un des arguments classiques contre la migration : le coût de sortie. Voir aussi ce que le Data Act change pour les sous-traitants cloud.

Méthode : arbitrer en six questions

Voici la grille que j’utilise en mission. Elle tient en une page et évite les débats idéologiques.

1. Le traitement relève-t-il d’une obligation dure ? Article 31 SREN, HDS, opérateur d’importance vitale, données classifiées. Si oui, la question est fermée : vous prenez une offre qualifiée, point.

2. Quelle est la sensibilité réelle des données ? Cartographiez à partir de votre registre des traitements. Bureautique commerciale et dossiers médicaux ne relèvent pas du même arbitrage.

3. Quel est le niveau de souveraineté annoncé — et lequel est contractualisé ? Faites l’exercice littéral : ouvrez le contrat, cherchez la clause qui traite des demandes d’autorités étrangères. Si elle se limite à « nous contesterons les demandes que nous estimons infondées et vous informerons dans la mesure permise par la loi », vous êtes au niveau 1, quel que soit le discours commercial. Notre analyse des contrats SaaS détaille les clauses à négocier.

4. Quelles mesures supplémentaires sont techniquement effectives ? Le chiffrement n’est une mesure supplémentaire au sens de Schrems II que si le fournisseur n’a jamais accès aux clés. Un chiffrement au repos avec clés gérées par le fournisseur ne protège de rien face à une injonction. Le chiffrement côté client avec HSM sous votre contrôle, oui. Anticipez également l’échéance post-quantique sur les données à longue durée de conservation.

5. Le risque résiduel est-il documenté ? Transfer impact assessment quand il y a transfert, AIPD quand le traitement l’exige, décision formalisée et datée. En cas de contrôle, ce dossier vaut infiniment plus que l’absence de fournisseur américain.

6. La sortie est-elle réellement possible ? Format d’export, délai, coût, dépendance aux services managés propriétaires. Testez-la, ne la supposez pas. C’est le point sur lequel les plans de continuité sont le plus souvent théoriques.

Les clauses à exiger, quel que soit le fournisseur

Sur la base des dix domaines du décret du 14 avril 2026 et de la pratique contractuelle, six clauses méritent d’être systématiquement négociées :

1. Localisation : hébergement, sauvegardes, plan de reprise, et surtout support et administration technique — chacun explicitement listé, avec obligation de notification préalable en cas de changement.
2. Demandes d’autorités étrangères : obligation de contester par tous moyens de droit, d’informer sans délai le client sauf interdiction légale, et de fournir un rapport de transparence chiffré.
3. Sous-traitants ultérieurs : liste nominative, localisation, droit d’opposition motivé, préavis raisonnable avant tout ajout, conformément à l’article 28 du RGPD.
4. Réversibilité : format d’export documenté, délai maximal, gratuité, assistance à la migration, suppression certifiée à l’issue.
5. Audit : droit d’audit effectif, sur pièces et sur site, ou à défaut communication des rapports ISO 27001 et SecNumCloud complets, annexes de périmètre incluses.
6. Notification de violation : délai contractuel compatible avec vos 72 heures RGPD, ce qui suppose en pratique 24 heures, avec contenu minimal défini. Voir notre article sur la gestion des incidents.

Ce travail de mise en cohérence entre le registre, les contrats de sous-traitance et les analyses de risque est exactement ce que Legiscope automatise, pour éviter que ces clauses ne vivent dans un tableur que personne ne rouvre.

Ce qu’il faut retenir

• « Cloud souverain » n’a pas de définition légale. Quatre niveaux coexistent — localisation des données, localisation de l’exploitation, immunité aux lois extraterritoriales, contrôle capitalistique — et seuls les deux derniers protègent réellement contre le CLOUD Act.
• Le RGPD n’impose pas le cloud souverain. Il impose une sécurité appropriée (art. 32), un contrat de sous-traitance conforme (art. 28), l’encadrement des transferts (art. 44 à 49) et le refus des injonctions étrangères non fondées sur un accord international (art. 48). Le risque doit être évalué et documenté, pas éliminé par principe.
• Le décret n° 2026-272 du 14 avril 2026 est la première obligation dure en droit français. Il vise les administrations, opérateurs et six GIP de l’État, pour les données couvertes par un secret protégé ou nécessaires aux missions essentielles, avec un régime dérogatoire de 12 à 18 mois. Les exigences opérationnelles restent suspendues à un référentiel ANSSI à paraître.
• SecNumCloud 3.2 reste la seule qualification européenne intégrant l’immunité extraterritoriale, mais uniquement sur son périmètre qualifié, et sans dispenser d’aucune obligation RGPD.
• L’EUCS a perdu son critère de souveraineté et reste gelé. Le règlement CADA, présenté le 3 juin 2026, le réintroduit par la commande publique avec une grille à quatre niveaux, mais son application effective est à deux ou trois ans.

FAQ

Le RGPD oblige-t-il à héberger les données en France ?

Non. Le RGPD ne comporte aucune obligation de localisation géographique. Il encadre les transferts hors de l’Espace économique européen (art. 44 à 49) et impose une sécurité proportionnée au risque (art. 32), mais un hébergement en Irlande ou aux Pays-Bas est un traitement intra-UE parfaitement licite. Les obligations de localisation en France proviennent de textes sectoriels — article 31 de la loi SREN, certification HDS, doctrine applicable aux données classifiées — et non du RGPD.

Une région européenne d’un fournisseur américain suffit-elle à écarter le CLOUD Act ?

Non. Le CLOUD Act se rattache à la juridiction sur le fournisseur, pas à la localisation physique des serveurs. Une filiale européenne d’un groupe américain reste, en pratique, susceptible d’être atteinte via sa maison mère au titre du contrôle qu’elle exerce sur les données. C’est précisément ce qu’a reconnu Microsoft France devant la commission d’enquête sénatoriale en juin 2025. Seule une immunité structurelle — siège, actionnariat et exploitation hors de portée d’un droit tiers — écarte réellement ce risque.

Une entreprise privée est-elle concernée par le décret SREN du 14 avril 2026 ?

Pas directement. Le dispositif de l’article 31 de la loi SREN vise les administrations de l’État, ses opérateurs et six groupements d’intérêt public limitativement énumérés. En revanche, une entreprise privée qui candidate à un marché public portant sur ces données devra démontrer sa conformité au futur référentiel ANSSI. Et par effet d’entraînement, les exigences de ce référentiel deviendront un standard de fait dans les grands comptes privés, comme cela s’est produit avec l’HDS dans le secteur de la santé.

Le chiffrement suffit-il à sécuriser un cloud non souverain ?

Cela dépend entièrement de la gestion des clés. Un chiffrement au repos dont les clés sont détenues ou accessibles par le fournisseur n’oppose aucun obstacle à une injonction judiciaire : le fournisseur peut techniquement déchiffrer. Un chiffrement côté client, avec des clés conservées dans un module matériel sous votre contrôle exclusif, constitue en revanche une mesure supplémentaire effective au sens de l’arrêt Schrems II — mais il limite fortement les fonctionnalités des services managés, ce qui explique qu’il soit rarement retenu au-delà des traitements les plus sensibles.

Que vaut la certification EUCS pour prouver la souveraineté d’une offre ?

Peu de chose sur ce point précis. Le critère de souveraineté a été retiré du projet de schéma et l’adoption reste gelée. L’EUCS, s’il aboutit, attestera d’un niveau de sécurité technique harmonisé au niveau européen, ce qui a sa valeur, mais il n’établira pas l’immunité aux lois extraterritoriales. Pour cette dimension, seule la qualification SecNumCloud fait aujourd’hui foi en droit français.

---

Vous suivez ces sujets ? Chaque semaine, je publie une analyse des textes et décisions qui comptent en protection des données et conformité numérique — décret SREN, référentiel ANSSI, CADA, jurisprudence CNIL. Inscrivez-vous à la newsletter.