Souveraineté des données : HDS, SecNumCloud, RGPD — décryptage 2026

TL;DR — En 2026, la souveraineté numérique n'est plus un débat philosophique : c'est un risque juridique mesurable. HDS V2, SecNumCloud 3.2, RGPD, NIS2, Cloud Act US s'empilent. Décryptage clair de qui s'applique à quoi, et comment construire une architecture conforme sans se ruiner.

Pourquoi le sujet revient en force en 2026

Quatre facteurs ont accéléré la prise de conscience :

1. Schrems II (CJUE 2020) puis Schrems III annoncé : transferts de données UE→US fragilisés juridiquement.
2. Cloud Act US (2018) toujours en vigueur : un éditeur US peut être contraint de transmettre des données EU sans informer le client.
3. Sanctions économiques géopolitiques (Russie, Chine, Iran) qui ont rappelé que le cloud peut être coupé du jour au lendemain.
4. Affaires concrètes : Microsoft France visée par une enquête CNIL en 2024 sur Microsoft 365 Education ; Doctolib fortement challengé sur son hébergement AWS pour les données de santé.

Résultat : les RSSI et DPO français mettent désormais des clauses de souveraineté dans tous les nouveaux marchés.

Les 5 référentiels à connaître

1. RGPD (Règlement Général sur la Protection des Données)

• Qui : toute organisation traitant des données personnelles d'européens.
• Ce qui compte pour la souveraineté : article 44+ sur les transferts internationaux ; article 28 sur les sous-traitants.
• En pratique : tout transfert hors UE doit avoir une base légale (clauses contractuelles types, BCR, décision d'adéquation).
• Trou juridique majeur : les sous-traitants ultimes US (CDN, monitoring, sauvegarde) sont rarement listés.

2. HDS V2 (Hébergement de Données de Santé)

• Qui : tout hébergeur de données de santé françaises.
• Référentiel : publié par l'ANS en 2024, applicable depuis 2025 (cf. notre article HDS V2).
• Niveau de souveraineté : exige hébergement France ou UE, déclaration des injonctions extra-européennes.

3. SecNumCloud (ANSSI, version 3.2)

• Qui : organismes traitant des données sensibles État, OIV/OSE, certains opérateurs santé/finance.
• Référentiel : le plus exigeant en France en matière de souveraineté.
• Critères clés : capital majoritairement européen, gouvernance européenne, immunité au droit extra-européen, infrastructure et personnel européens.
• Hébergeurs qualifiés (mai 2026) : OVHcloud, Outscale, Numspot, S3NS (Thales/Google), Bleu (en cours), etc.
• Important : SecNumCloud n'est pas équivalent à HDS — il ne couvre pas les exigences spécifiques santé.

4. NIS2 (transposée en France fin 2025)

• Qui : 15 000+ entités essentielles ou importantes en France.
• Article 21 : exige des mesures techniques dont la « sécurité de la chaîne d'approvisionnement » et la « gestion des incidents ».
• Implication souveraineté : un fournisseur cyber compromis = compromission de la chaîne. Devient un critère d'audit.

5. DORA (Digital Operational Resilience Act)

• Qui : entités financières (banques, assurances, prestataires services financiers).
• Spécificité : registre des « ICT third-party providers » avec catégorisation critique, droit d'audit, capacité d'exit documentée.
• Implication souveraineté : si vos données financières sont chez AWS Frankfurt, vous devez documenter votre plan de migration vers un autre fournisseur en cas de défaillance ou de risque géopolitique.

Tableau comparatif synthétique

Le piège « cloud public US conforme »

Beaucoup d'éditeurs SaaS s'appuient sur AWS Paris, Azure France Central, GCP Europe et affichent « hébergé en France ». C'est trompeur car :

• Capital US de l'opérateur cloud → soumis au Cloud Act.
• Plan de contrôle souvent géré depuis les États-Unis (les ingénieurs Microsoft/Amazon peuvent voir vos métadonnées).
• Services managés opaques : RDS, S3, Lambda — qui contrôle vraiment les clés ?

Pour de la donnée vraiment sensible (santé, défense, finance critique, OIV), AWS/Azure France ne suffit pas. Il faut SecNumCloud, ou un opérateur français pure-player (type Unitel pour UniSOC).

Construire une architecture conforme : 4 niveaux de sensibilité

Niveau 1 — Données peu sensibles (marketing, blog public, analytics anonymisé)

• Cloud public OK (AWS, Azure, GCP, OVH, Scaleway).
• Conformité : RGPD basique, mentions légales, cookies.

Niveau 2 — Données personnelles non sensibles (CRM, ERP, RH classique)

• Cloud public UE acceptable mais avec garanties contractuelles renforcées.
• Préférence : OVHcloud, Scaleway, Outscale, Clever Cloud (FR pure-player).
• Conformité : RGPD, DPA strict, sous-traitants documentés.

Niveau 3 — Données sensibles régulées (santé, finance, OIV/OSE)

• HDS V2 obligatoire pour santé — voir notre offre dédiée aux collectivités et établissements de santé publics.
• DORA structurant pour finance.
• Hébergement chez un acteur français certifié (Unitel, OVHcloud HDS, Equinix FR HDS, etc.).
• SOC 24/7 obligatoire en pratique pour preuves d'audit.

Niveau 4 — Données ultra-sensibles (défense, classifié, OIV critique)

• SecNumCloud ou hébergement on-premise.
• Personnel habilité Confidentiel Défense côté opérateur.
• Audit ANSSI régulier.

Le cas UniSOC : architecture souveraine concrète

Pour illustrer, voici comment UniSOC construit sa souveraineté :

Cette architecture est plus chère qu'un déploiement AWS pur (~15-25 % de surcoût), mais elle ouvre l'accès aux secteurs régulés où le cloud public US est désormais interdit ou risqué.

Cas d'usage : un éditeur SaaS santé qui doit tout repenser

Scénario observé chez un client :

• Editeur de logiciel de gestion de cabinet médical.
• Hébergé chez AWS Paris depuis 5 ans.
• Croissance forte → 80 cabinets clients = ~150 000 patients.
• DPO + nouveau RSSI alertent en 2026 : ne sera plus conforme HDS V2.

Plan de migration sur 12 mois :

1. Mois 1-2 : audit du périmètre exact des données stockées vs traitées (PII, PMI, données médicales sensibles).
2. Mois 3-4 : sélection d'un hébergeur HDS V2 pure-player (Unitel, OVHcloud HDS, ou autres).
3. Mois 5-8 : migration progressive avec double-run.
4. Mois 9-10 : audit blanc HDS V2.
5. Mois 11-12 : audit officiel + certification.
6. Coût total : 350-700 k€ projet + 15-25 % surcoût annuel hébergement.

C'est un projet, pas un quick-win — mais sans lui, l'éditeur perd ses clients.

Erreurs fréquentes à éviter

1. Confondre HDS et SecNumCloud — ce ne sont pas équivalents. HDS = santé, SecNumCloud = État/sensible.
2. Penser qu'AWS Paris = souverain — c'est faux juridiquement (Cloud Act US).
3. Oublier les sous-traitants ultimes (CDN, monitoring, captcha, fonts) qui ramènent des dépendances US.
4. Surinvestir : tout ne nécessite pas SecNumCloud. Calibrer le niveau au type de donnée.
5. Sous-investir sur le SOC — la souveraineté du datacenter ne sert à rien sans détection.

Conclusion

La souveraineté des données en 2026 est un continuum, pas un binaire. Les bons RSSI cartographient les données par sensibilité, choisissent le bon référentiel par niveau, et construisent une chaîne complète sans angle mort (datacenter, compute, IA, monitoring, sauvegarde, personnel).

Le bon partenaire SOC peut soit accélérer cette mise en conformité (en fournissant les preuves d'audit clé en main), soit la torpiller (en renvoyant vos logs vers OpenAI ou en hébergeant chez un acteur US). Choisissez bien — c'est exactement le positionnement de la plateforme SOC managé UniSOC.

---

Vérifier la souveraineté de votre stack actuel : Demandez un audit gratuit → — 30 minutes de cadrage, on vous remet une cartographie de vos dépendances cloud sensibles.