Un texte publié en plein été rebat les cartes du cloud souverain français. L’arrêté du 12 août 2026, entré en vigueur le 22 août, approuve la version 3.2 du référentiel SecNumCloud de l’ANSSI et lui donne, pour la première fois, une portée pleinement contraignante sur une large partie de la sphère publique centrale.

Le mécanisme juridique s’est construit par étapes, sur près de deux ans.

L’article 31 de la loi SREN de mai 2024 avait posé le principe : les administrations traitant des données sensibles devraient recourir à des prestataires cloud à l’abri des législations extraterritoriales, à commencer par le Cloud Act américain.

L’obligation cible désormais les administrations de l’État, ses opérateurs et les groupements d’intérêt public qui confient à un prestataire privé des données « d’une sensibilité particulière ».

Cette notion est définie de façon cumulative. La donnée doit relever d’un secret protégé par la loi ou d’une mission essentielle de l’État, et sa compromission doit faire courir un risque réel à l’ordre public, à la sécurité publique, à la santé ou à la vie des personnes, ou encore à la propriété intellectuelle.

Le décret d’avril 2026 a par ailleurs nommément désigné six groupements d’intérêt public* soumis à cette obligation.

Un point technique aura des conséquences pratiques immédiates : une administration ne pourra pas isoler artificiellement quelques fichiers sensibles pour ne leur appliquer les règles renforcées qu’à eux, tout en laissant le reste de son système d’information sur une infrastructure moins protégée.

Un contournement assumé du blocage parlementaire

Dès lors que des données sensibles cohabitent avec des données ordinaires sur une même infrastructure cloud, c’est l’ensemble de cette infrastructure qui doit se hisser au niveau d’exigence SecNumCloud. A moins que l’administration ne démontre un cloisonnement technique réellement étanche entre les deux.

En pratique, cette règle ferme une échappatoire évidente et pourrait pousser certains organismes vers des migrations bien plus larges que prévu, faute de pouvoir prouver une séparation solide de leurs environnements.

Le texte prévoit aussi une soupape. Si aucune offre conforme n’existe sur le marché, l’organisme concerné dispose d’une dérogation motivée, renouvelable, jusqu’à ce qu’une solution qualifiée apparaisse ; puis dispose de 18 mois pour basculer une fois qu’elle existe.

Le choix de la voie réglementaire n’est pas neutre.

La transposition de la directive NIS 2,  qui fait l’objet d’un contentieux avec Bruxelles, aurait permis d’étendre des obligations de cybersécurité comparables reste bloquée au Parlement dans le projet de loi Résilience, dont l’examen n’est désormais annoncé qu’en octobre.

En attendant, le gouvernement avance par arrêté. Un instrument qui ne requiert ni majorité ni débat parlementaire mais qui reste, par construction, plus réversible qu’une loi.

Ce que change concrètement le référentiel

Le référentiel technique lui-même n’est pas né en 2026. L’ANSSI en avait publié la version 3.2 dès mars 2022. Ce qu’il change, c’est sa portée juridique. Jusqu’ici, une administration pouvait s’appuyer sur SecNumCloud sans y être tenue par la loi ; désormais, pour les données sensibles concernées, y recourir n’est plus un choix mais une condition de légalité du marché public.

Ce contenu s’organise autour de quatre axes. Le plus disputé porte sur la souveraineté juridique et capitalistique des prestataires.

Concrètement, pour être qualifié, un fournisseur doit remplir trois conditions :

• son siège social, son centre décisionnel et l’administration de ses services doivent se situer dans l’Union européenne ;
• la part de son capital détenue par des acteurs extra-européens est plafonnée ;
• aucune entité hors UE ne peut disposer d’un droit de veto sur les décisions de l’entreprise. Ce critère ne porte donc pas sur la technique mais sur l’actionnariat — et c’est précisément ce qui en fait, pour les fournisseurs, le plus difficile à satisfaire : une faille de sécurité se corrige en quelques semaines, une structure capitalistique ne se réorganise pas du jour au lendemain. C’est ce verrou qui écarte de fait, dès le départ, une bonne partie des grands acteurs cloud mondiaux non européens.

Trois autres évolutions complètent le tableau.

D’abord, les tests d’intrusion, qui n’étaient auparavant réalisés qu’à un instant donné, doivent désormais être menés en continu tout au long de la qualification.

Ensuite, une logique de « composition de services » simplifie la vie des éditeurs SaaS : s’ils s’appuient sur une couche IaaS ou PaaS déjà qualifiée SecNumCloud, ils héritent de ses garanties et n’ont plus à repasser un audit complet — ils ne font certifier que leur propre couche applicative.

Enfin, le référentiel se rapproche délibérément du futur schéma européen EUCS, dont le niveau le plus élevé, dit « High », reste l’objectif de convergence à terme.

Au total, un fournisseur candidat à la qualification doit répondre à plus de 360 exigences, réparties entre sécurité technique, gouvernance, gestion des accès et conformité réglementaire.

Des angles morts persistants

Le nouveau cadre laisse cependant deux zones grises.

D’abord, les tests d’intrusion, qui n’étaient auparavant réalisés qu’à un instant donné, doivent désormais être menés en continu tout au long de la qualification.

Ensuite, une logique de « composition de services » simplifie la vie des éditeurs SaaS : s’ils s’appuient sur une couche IaaS ou PaaS déjà qualifiée SecNumCloud, ils héritent de ses garanties et n’ont plus à repasser un audit complet — ils ne font certifier que leur propre couche applicative.

Enfin, le référentiel se rapproche délibérément du futur schéma européen EUCS, dont le niveau le plus élevé, dit « High », reste l’objectif de convergence à terme.

Au total, un fournisseur candidat à la qualification doit répondre à plus de 360 exigences, réparties entre sécurité technique, gouvernance, gestion des accès et conformité réglementaire.

Un marché en recomposition

Pour les fournisseurs déjà qualifiés (une dizaine d’offres actives, parmi lesquelles OVHcloud, Outscale, Scaleway ou la coentreprise S3NS de Google et Thales) et la douzaine de candidats en cours de qualification, l’élargissement change la nature du marché.

Ce qui était un segment de niche devient un débouché plus prévisible, porté par une demande publique captive. Mais ce débouché reste fragmenté : il touche désormais des acteurs publics aux budgets et à l’expertise technique très inégaux, loin des grands comptes stratégiques habitués à ce type d’exigences.

Un piège guette néanmoins les acheteurs publics : la qualification SecNumCloud ne s’applique pas toujours à l’ensemble d’une offre. Un fournisseur peut être qualifié pour sa brique d’infrastructure (IaaS) sans l’être pour ses services applicatifs (PaaS, SaaS) ou de conteneurs (CaaS). Une administration ne peut donc pas se fier au seul nom du prestataire : elle doit vérifier, marché par marché, quelle couche précise du service est effectivement couverte par le label.

Reste une question de fond, formulée par plusieurs observateurs : ce qu’un arrêté a créé, un arrêté peut le défaire.

À moins d’un an de l’élection présidentielle et d’un possible changement de majorité, la pérennité du dispositif ne sera véritablement testée qu’à l’été 2027.

*Agence du numérique en santé (ANS), Centre d’accès sécurisé aux données (CASD),  Centre ressources prévention de la radicalisation, le collecteur analyseur de données, le GIP Modernisation des déclarations sociales et le Système national d’enregistrement de la demande de logement social

The post SecNumCloud 3.2 : Paris impose le cloud souverain par la voie réglementaire appeared first on Silicon.fr.