SecNumCloud 3.2 : trois chemins vers la conformité, trois visions différentes de la souveraineté

# SecNumCloud 3.2 : trois chemins vers la conformité, trois visions différentes de la souveraineté

En 2026, SecNumCloud 3.2 n'est plus un label optionnel réservé aux administrations centrales. Son périmètre élargi touche désormais des opérateurs d'importance vitale, des établissements de santé et une partie croissante des ETI traitant des données sensibles au sens de NIS2. Pour les DSI et RSSI concernés, la question n'est plus « faut-il s'y conformer ? » mais « par quel chemin, avec quelles implications architecturales et quelle vision de la souveraineté ? »

Il n'existe pas une seule réponse à cette obligation. Il en existe au moins trois, chacune portant des compromis techniques et des postures réglementaires radicalement différentes. Cet article les compare sur quatre critères concrets : architecture de confiance, cloisonnement des données, gouvernance opérationnelle, et exposition aux risques d'extraterritorialité.

Ce que SecNumCloud 3.2 change réellement

La version 3.2 du référentiel de l'ANSSI durcit plusieurs exigences qui avaient jusqu'ici laissé des marges d'interprétation. Trois évolutions structurantes méritent d'être identifiées.

Premièrement, l'immunité juridique vis-à-vis du droit extraterritorial étranger devient un critère de qualification formel. Un prestataire soumis au Cloud Act américain, au FISA ou à toute législation permettant un accès unilatéral à des données hébergées en Europe ne peut obtenir — ni conserver — la qualification. Ce point invalide de facto les offres d'acteurs américains, y compris leurs filiales européennes, dès lors que la maison mère relève du droit américain.

Deuxièmement, les exigences de localisation ne se limitent plus aux données au repos. Les flux de traitement, les métadonnées, les journaux d'audit et les mécanismes de supervision doivent rester dans le périmètre qualifié. Une architecture qui exfiltre des métadonnées vers des serveurs hors zone qualifiée — même pour des raisons de performance ou de monitoring — est non conforme.

Troisièmement, la chaîne de sous-traitance est désormais auditée en profondeur. Un cloud qualifié qui s'appuie sur des composants logiciels dont l'éditeur est soumis à une juridiction étrangère doit démontrer l'absence de vecteur d'accès distant non contrôlé. C'est un point de friction majeur pour les offres construites sur des briques open source américaines sans fork souverain documenté.

Trois approches comparées

Approche A — Cloud qualifié natif souverain

Il s'agit ici d'un hébergement chez un prestataire ayant obtenu ou étant en cours d'obtention de la qualification SecNumCloud 3.2 dans sa version intégrale, sans recours à des sous-traitants hors périmètre. En France, ce segment est occupé par un nombre limité d'acteurs, dont **3DS Outscale** (filiale de Dassault Systèmes) figure parmi les plus avancés sur le plan de la qualification formelle.

Architecture de confiance : le modèle repose sur une séparation physique et logique totale entre les environnements clients, une cryptographie sous contrôle exclusif du client, et une absence de canal d'administration accessible depuis l'extérieur du territoire européen. Les HSM (modules matériels de sécurité) sont localisés et certifiés.

Cloisonnement des données : natif et documenté. Les flux inter-régions, lorsqu'ils existent, restent dans des datacenters qualifiés ou en cours de qualification. Aucune dépendance à une infrastructure parente soumise à droit étranger.

Gouvernance opérationnelle : les équipes d'astreinte, d'administration et de réponse aux incidents sont localisées sur le territoire européen. Les accès privilegiés sont tracés et auditables en temps réel par le client.

Exposition extraterritoriale : nulle par construction, dès lors que la qualification est maintenue. C'est la seule approche qui élimine structurellement le risque Cloud Act.

Contrainte principale : le catalogue de services est plus étroit que celui des acteurs américains dominants. Certaines fonctionnalités avancées — IA générative intégrée, services managés spécialisés — sont absentes ou en développement. La migration depuis une architecture existante peut nécessiter une refonte applicative substantielle.

Approche B — Cloud souverain en partenariat avec un acteur américain (modèle « S3NS / Bleu »)

Ce modèle, incarné notamment par **S3NS** (joint-venture entre Thales et Google Cloud) ou les structures analogues qui ont émergé depuis 2024, propose une qualification SecNumCloud portée par une entité française juridiquement autonome, opérant une infrastructure Google isolée et sans accès depuis la maison mère américaine.

Architecture de confiance : l'isolation repose sur une séparation contractuelle et opérationnelle entre l'entité qualifiée et Google LLC. Les clés de chiffrement sont gérées par l'entité française. L'accès de Google aux données est contractuellement et techniquement coupé — en théorie.

Cloisonnement des données : les données au repos et en transit restent dans le périmètre européen qualifié. Mais la question de la dépendance aux mises à jour logicielles, aux correctifs de sécurité et aux évolutions de la plateforme sous-jacente reste un point de débat technique ouvert : qui contrôle réellement le cycle de vie du logiciel ?

Gouvernance opérationnelle : les équipes opérationnelles sont françaises et soumises au droit français. Mais la gouvernance produit — roadmap, décisions d'architecture, priorités de développement — reste aux États-Unis. Un RSSI lucide mesurera cet écart entre gouvernance opérationnelle et gouvernance stratégique.

Exposition extraterritoriale : c'est ici que le débat est le plus vif dans la communauté juridique et technique. La qualification ANSSI atteste d'une conformité au référentiel au moment de l'audit. Mais le Cloud Act s'applique à Google LLC, entité mère. Si une injonction américaine visait les données traitées par S3NS, la réponse pratique dépendrait de l'effectivité de l'isolation — et de la capacité de résistance juridique de l'entité française face à sa maison mère. Aucun cas de jurisprudence consolidé n'existe à ce jour.

**Contrainte principale** : cette approche offre un catalogue de services bien plus riche et une continuité fonctionnelle pour les organisations déjà sur Google Workspace ou GCP. Elle est souvent choisie comme étape de transition. Mais elle ne résout pas fondamentalement la question de la dépendance stratégique.

Approche C — Infrastructure on-premise qualifiée avec cloud souverain en extension

Certaines organisations — en particulier dans les secteurs défense, santé critique et OIV — font le choix d'une infrastructure on-premise maîtrisée, qualifiée au sens SecNumCloud pour les composants concernés, avec un recours limité au cloud souverain pour des usages spécifiques (sauvegarde, PRA, calcul à la demande). **Oodrive**, qualifié SecNumCloud pour la gestion documentaire sensible, illustre ce type d'architecture hybride orientée données critiques.

Architecture de confiance : maximale sur le périmètre on-premise. La surface d'attaque externe est réduite. Le RSSI conserve une visibilité directe sur l'infrastructure physique.

Cloisonnement des données : absolu pour les données les plus sensibles. Les flux vers le cloud souverain sont définis, documentés et auditables. Aucune donnée critique ne transite par une infrastructure non qualifiée.

Gouvernance opérationnelle : totale sur le périmètre interne. En revanche, cette approche exige des compétences internes élevées, des équipes dimensionnées pour l'exploitation et la maintenance, et une discipline documentaire rigoureuse pour maintenir la conformité dans la durée.

Exposition extraterritoriale : nulle sur le périmètre on-premise. Résiduelle sur les extensions cloud, selon le prestataire retenu.

Contrainte principale : le coût humain et organisationnel est significatif. La scalabilité est limitée. Cette approche convient aux organisations disposant déjà d'une DSI structurée et d'un appétit faible pour les services managés.

Tableau comparatif synthétique

| Critère | Cloud natif souverain | Cloud souverain (JV franco-américaine) | On-premise qualifié + extension |

|---|---|---|---|

| Conformité SecNumCloud 3.2 | Complète (qualification directe) | Possible (qualification de l'entité française) | Complète sur périmètre interne |

| Risque Cloud Act | Nul | Débattu — isolation contractuelle/technique | Nul (on-premise) / Faible (extension) |

| Richesse du catalogue services | Moyenne | Élevée | Faible à moyenne |

| Dépendance stratégique à un acteur US | Nulle | Structurelle (roadmap produit) | Nulle |

| Complexité opérationnelle | Modérée | Faible à modérée | Élevée |

| Conformité RGPD / NIS2 / DORA | Forte | Forte (sous réserve d'audit) | Forte (exige rigueur documentaire) |

Ce que cela implique pour votre stratégie

SecNumCloud 3.2 n'est pas seulement une contrainte de conformité. C'est un révélateur de posture. L'approche choisie dit quelque chose de précis sur la vision qu'une organisation a de sa dépendance technologique à long terme.

L'approche B — la plus adoptée en 2025-2026 pour des raisons de continuité fonctionnelle — est celle qui demande la lecture la plus critique. Elle offre une conformité réglementaire attestée, mais maintient une dépendance architecturale et stratégique à un acteur dont les intérêts, les obligations légales et la roadmap produit sont définis hors d'Europe. Pour un DSI ou un RSSI qui doit justifier ses choix devant un conseil d'administration ou un autorité de contrôle sectorielle, cette nuance mérite d'être documentée explicitement — et non dissimulée derrière le label.

L'approche A reste la seule qui réponde à la fois à la lettre et à l'esprit de SecNumCloud 3.2 tel que l'ANSSI le conçoit : un outil de reconquête de la maîtrise numérique, pas seulement un mécanisme d'audit.

L'approche C, enfin, est celle des organisations qui ont choisi de ne pas déléguer leur sécurité — au prix d'un investissement interne que toutes ne peuvent pas assumer.

Le choix entre ces trois chemins n'est pas neutre. Il engage une organisation pour plusieurs années, dans un contexte réglementaire européen qui va continuer à durcir ses exigences d'autonomie numérique.