Conseil d’État 2026 — Health Data Hub: impact DLP et transferts UE

Le 20 mars 2026, le Conseil d’État a confirmé l’autorisation CNIL du Health Data Hub opéré sur des centres de données Microsoft situés en France, en jugeant qu’il n’y a pas de transfert vers les États‑Unis. Message clé: ce sont les flux réels qui déclenchent le chapitre V, pas l’identité du fournisseur.

Les faits

Le Conseil d’État a rejeté les recours contre la délibération n° 2025‑014 autorisant, pour trois ans, l’extraction et le traitement de données issues du SNDS pour des études menées dans DARWIN EU, avec hébergement chez Microsoft Ireland en France. L’arrêt souligne que l’autorisation « a pour seul objet d’autoriser le traitement de données de santé hébergées dans des centres de données situés en France, et n’autorise pas leur transfert vers les États‑Unis », et que les rares données potentiellement transférées (liées aux utilisateurs) sont couvertes par des garanties RGPD (pseudonymisation, limitation de conservation, encadrement contractuel) (Conseil d’État, 20/03/2026).

Cette clarification met l’accent sur la preuve d’absence de flux hors UE/EEE par des mesures juridiques et techniques concrètes (localisation, pseudonymisation, clauses, gouvernance de sécurité) et non de simples déclarations.

Le cadre légal qui s’applique

• RGPD, chapitre V (art. 44 et s.): transferts vers des pays tiers soumis aux conditions prévues (adéquation, clauses types, BCR, dérogations, TIA, mesures complémentaires). Références: EUR‑Lex — RGPD (FR) et synthèse CNPD: CNPD — Chapitre V. Pour un rappel pratique, voir notre page dédiée au chapitre V du RGPD.
• RGPD, article 32: sécurité appropriée (pseudonymisation/chiffrement, confidentialité, intégrité, résilience, tests). Référence: EUR‑Lex — art. 32.
• L’arrêt du 20 mars 2026 retient: (1) pas d’autorisation de transfert de données de santé hors UE; (2) les risques d’accès extraterritorial s’apprécient au regard des garanties mises en place (pseudonymisation, localisation en France, clauses et gouvernance).

Conséquence pratique: si vos données restent dans l’UE et que vous pouvez démontrer l’absence de flux sortants (ou leur encadrement strict), vous respectez le chapitre V. L’obligation devient probatoire et technique: documenter, surveiller et empêcher les sorties.

La solution technique: une DLP orientée « souveraineté des flux »

Pour satisfaire à la fois l’article 32 (sécurité) et le chapitre V (transferts), une DLP moderne devient l’outil pivot pour empêcher, détecter et documenter tout transfert non autorisé hors UE/EEE.

• Contrôle des canaux: e‑mail, web/HTTP(S), messageries, postes de travail (USB, impression), SaaS, API, flux batch; politiques par classification (personnelles, art. 9, secrets d’affaires).
• Géofencing et résidence: blocage/quarantaine des envois vers domaines/IP hors UE/EEE, ou tenants cloud non conformes.
• Reconnaissance et classification: dictionnaires, regex, modèles ML, étiquettes Sensitivity Labels, tags dynamiques (ex.: « SNDS », « patient‑pseudonymisé »).
• Pseudonymisation/masquage en sortie: masquage irréversible avant tout partage nécessaire, avec journalisation.
• Journalisation et preuve: logs signés/horodatés, motifs de blocage, exceptions approuvées, artefacts d’audit ILR/CNPD/CSSF.
• Alignement standards: ISO/IEC 27001 (A.5.12, A.8.10, A.8.24, A.5.23), NIST CSF 2.0 (PR.DS‑Exfil, PR.AC‑03), CIS Controls 3/13.

Comment Luxgap déploie cela

• Gouvernance ISO 27001: cadrage de la classification et des règles DLP par familles de données et par zones (UE/EEE/tiers), ancrage dans le registre et les TOMs (art. 32).
• Consultants DPO et CISO externalisés: cartographie des flux réels, matrice « autorisés/interdits » assortie de preuves techniques, clauses sous‑traitants, TIA, et politique d’exceptions encadrées.
• SOC managé: supervision 24/7 des événements DLP et corrélation avec les identités, rapports de conformité (chapitre V) et sécurité (art. 32). Découvrez notre SOC managé pour industrialiser la supervision.

Concrètement, nous lançons un « DLP Residency Sprint » de 4 à 6 semaines: sources prioritaires, labellisation, géofencing, tests, comitologie d’exceptions, puis passage en run.

Cas concret au Luxembourg ou en UE

Une fiduciaire luxembourgeoise soumise à NIS 2 a migré vers Microsoft 365 et un entrepôt analytics UE‑only. En 6 semaines, nous avons classifié trois familles de données, posé des labels « UE‑only », bloqué les envois vers domaines extra‑UE et exigé la pseudonymisation pour tout support hors UE, avec journaux signés et rapports mensuels. Résultat: zéro flux non autorisé et une preuve prête pour audit ILR/CNPD, utile pour la conformité CNPD au Luxembourg.

Premiers pas concrets

1. Cartographiez vos flux: inventaire des canaux (email, Teams/Slack, CRM, SFTP, API) et des zones de destination.
2. Étiquetez vos données critiques: au moins « UE‑only » et « Art. 9 — pseudonymiser avant sortie » sur deux sources cœur.
3. Activez un géofencing simple: démarrez en audit, puis passez en blocage après 2–3 semaines d’observation.
4. Instituez des exceptions: pseudonymisation + clauses + TIA documentée, avec approbation DPO/CISO.
5. Préparez la preuve: centralisez logs DLP et éditez un rapport mensuel « flux arrêtés/exceptions ».

Sources officielles

• Conseil d’État (France), 20 mars 2026
• CNIL — Délibération 2025‑013 (Légifrance)
• RGPD (UE 2016/679) — EUR‑Lex
• CNPD Luxembourg — Chapitre V
• EMA — Data protection notice (DARWIN EU)

En bref: l’arrêt ne relâche pas le RGPD; il exige de prouver concrètement l’absence de transferts non autorisés. Une DLP bien gouvernée, avec géofencing UE, pseudonymisation en sortie et journaux probants, rend cette démonstration simple et vérifiable. Pour un accompagnement global (registre, TIA, politiques et contrôles), nos DPO certifiés peuvent piloter votre dispositif.