Décret SREN : ce que les acteurs publics doivent savoir

Souveraineté numérique & conformité réglementaire

L’essentiel du décret d’application de l’article 31 de la loi SREN, en trois questions clés pour les administrations et opérateurs de l’État.

Publié au Journal officiel le 16 avril 2026, le décret d’application de l’article 31 de la loi SREN (Sécuriser et réguler l’espace numérique) marque un tournant pour la souveraineté numérique française. Il ne s’agit pas d’une formalité administrative supplémentaire, mais de la traduction juridique d’une prise de conscience : la dépendance technologique vis-à-vis de prestataires non souverains constitue un risque opérationnel réel, accentué par les tensions géopolitiques, l’instabilité des modèles économiques et les restrictions commerciales imprévisibles. Pour les organismes concernés, le compte à rebours est lancé : 18 mois pour se mettre en conformité. Cet article fait le point sur les trois questions essentielles à se poser.

1Qui est touché ?

La première erreur serait de croire que tout le monde est concerné. Le décret vise un périmètre précis et explicitement défini : les administrations de l’État, les opérateurs de l’État et une liste nominative de six groupements d’intérêt public (GIP).

À l’inverse, une collectivité territoriale, un hôpital ou une structure parapublique qui ne figure pas dans ce périmètre n’est pas soumis aux mêmes obligations par défaut. La bonne première question n’est donc pas « que dois-je faire ? », mais « ce texte me concerne-t-il, et sur quels projets ? ».

Car même au sein des organismes visés, le décret ne s’applique pas à l’ensemble des traitements cloud. Il cible uniquement les données qui répondent à deux conditions cumulatives, c’est-à-dire qui doivent être réunies simultanément :

2Quels sont les enjeux ?

L’enjeu central du décret est de garantir que les données publiques les plus sensibles échappent à toute forme d’ingérence étrangère. Son article 2 mandate un référentiel élaboré par l’ANSSI, couvrant dix domaines d’exigence : organisation de la sécurité, gestion des ressources humaines impliquées dans le service, sécurité des systèmes d’information, cryptologie et contrôle d’accès, continuité d’activité, réversibilité, localisation de l’hébergement, contrôle capitalistique du prestataire, et — point d’orgue du dispositif — la protection contre tout accès par des autorités publiques d’un État tiers non autorisé par le droit de l’Union européenne.

Ce dernier critère est le cœur du sujet. Il vise directement les lois à portée extraterritoriale (de type Cloud Act) qui permettent à un État étranger d’exiger l’accès à des données hébergées par un prestataire relevant de sa juridiction, même si ces données sont physiquement stockées en Europe. C’est cette vulnérabilité que le décret entend neutraliser.

En pratique, ce référentiel reprend très largement les exigences de SecNumCloud, qui constitue à ce jour le seul niveau de conformité réellement opérationnel pour satisfaire à l’article 2. Le texte laisse la porte ouverte à une certification européenne d’un niveau au moins équivalent (le schéma EUCS niveau High+), mais ce dernier n’existe pas encore sur le marché. Concrètement, les organismes concernés n’ont donc, pour l’instant, qu’une voie crédible.

Le deuxième enjeu est procédural et concerne les achats. Le décret introduit la notion d’« offre acceptable » : une offre est jugée acceptable si elle répond au besoin fonctionnel du projet, en tenant compte de son coût. Cette définition, en apparence anodine, change la donne dans les marchés publics. Elle oblige les acheteurs à documenter leur analyse de marché : quelles offres conformes existent, à quel prix, et pourquoi elles répondent (ou non) au besoin.

Trois conséquences en découlent pour les consultations à venir. D’abord, les critères de qualification cloud (conformité au référentiel, SecNumCloud) doivent apparaître explicitement dans les dossiers d’appel d’offres. Ensuite, les arbitrages économiques doivent être étayés par écrit, et non simplement invoqués. Enfin, la réversibilité — la capacité à récupérer et migrer ses données — devient un critère à part entière : un prestataire incapable de garantir la portabilité s’expose à une exclusion documentée.

3Comment répondre à cette obligation ?

Le délai de 18 mois peut sembler confortable ; il ne l’est pas, compte tenu de la complexité des migrations d’infrastructure et des contraintes de marchés publics. Voici la marche à suivre.