A mid-August decree has sharply changed the rules of French sovereign cloud policy. The order of 12 August 2026, effective 22 August, approves version 3.2 of ANSSI’s SecNumCloud framework and, for the first time, gives it fully binding force across a large part of central government.

The legal architecture was assembled in stages over nearly two years. Article 31 of the SREN law of May 2024 established the principle that administrations handling sensitive data must use cloud providers protected from extraterritorial laws, above all the US Cloud Act. The obligation now applies to state administrations, their operators and public-interest groups (GIP) that entrust a private provider with data deemed “of particular sensitivity.”

That category is defined cumulatively: the data must fall under a legally protected secret or an essential state mission, and its compromise must create a real risk to public order, public safety, health or human life, or to intellectual property. An April 2026 decree also explicitly named six GIP subject to the rule: the Agence du numérique en santé (ANS), the Centre d’accès sécurisé aux données (CASD), the Centre ressources prévention de la radicalisation, the collecteur analyseur de données, the GIP Modernisation des déclarations sociales, and the Système national d’enregistrement de la demande de logement social.

The new framework also closes an obvious loophole. An administration can no longer isolate a few sensitive files and apply the stricter rules only to them while leaving the rest of its information system on a less protected infrastructure. If sensitive and ordinary data coexist on the same cloud infrastructure, the whole environment must meet SecNumCloud requirements unless the administration can prove genuinely watertight technical segregation. In practice, that could force much broader migrations than some public bodies had planned.

The decree does include a safety valve: if no compliant offer exists on the market, the body concerned can obtain a reasoned, renewable exemption until a qualified solution appears, then has 18 months to switch once one is available.

Paris’s choice of a regulatory route is politically significant. A comparable extension of cybersecurity obligations through the transposition of NIS 2 remains blocked in Parliament in the “Résilience” bill, now not expected to be examined until October amid a dispute with Brussels. By moving through an order rather than a law, the government avoids a parliamentary majority and debate — but also relies on a tool that is, by nature, easier to reverse.

The technical reference itself is not new: ANSSI published SecNumCloud 3.2 back in March 2022. What changes is its legal status. Until now, administrations could choose to rely on SecNumCloud; from now on, for the sensitive data covered by the decree, it becomes a condition of legality for public procurement.

The most contested part of the framework concerns the provider’s legal and capital structure. To qualify, a supplier must have its headquarters, decision-making centre and service administration in the European Union; the share of capital held by non-European actors is capped; and no entity outside the EU may hold a veto right over company decisions. This is not a technical requirement but an ownership one, which makes it especially hard to satisfy. Security flaws can be fixed in weeks; capital structures cannot be reorganised overnight. The result is to exclude, from the outset, most major non-European cloud players.

Three other changes round out the update. First, penetration testing, previously carried out at a single point in time, must now be continuous throughout the qualification process. Second, a “service composition” model makes life easier for SaaS vendors: if they rely on an IaaS or PaaS layer already qualified under SecNumCloud, they inherit its guarantees and only need certification for their own application layer. Third, the framework is deliberately aligned more closely with the future EUCS European scheme, whose highest level, “High,” remains the long-term convergence target. In total, a candidate provider must meet more than 360 requirements spanning technical security, governance, access management and regulatory compliance.

For the market, the shift is substantial. Already-qualified providers — around a dozen active offers, including OVHcloud, Outscale, Scaleway and the Google-Thales joint venture S3NS — plus roughly a dozen candidates in the qualification pipeline, now face a larger and more predictable public-sector demand. But the market remains fragmented, serving public bodies with very uneven budgets and technical maturity, far from the strategic enterprise accounts usually associated with such requirements.

Public buyers still face a trap: SecNumCloud qualification does not always cover an entire product suite. A provider may be certified for infrastructure (IaaS) without being qualified for application services (PaaS, SaaS) or container services (CaaS). Administrations therefore cannot rely on the vendor’s name alone; they must verify, contract by contract, which layer of the service is actually covered by the label.

One broader uncertainty remains: what an order creates, an order can also undo. With less than a year to the presidential election and a possible change of majority, the durability of the system will not truly be tested until summer 2027.

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.