Souveraineté numérique en santé : le guide de décision
« Nos données sont chiffrées et hébergées en Europe. » Cette phrase rassure les directions et trompe les juristes. En santé, la protection réelle d'une donnée dépend d'abord du droit auquel votre fournisseur est soumis — pas seulement de l'endroit où tournent ses serveurs.
- Un enjeu clinique, pas seulement informatique
- L'angle mort juridique : au-delà du chiffrement
- Transferts transatlantiques : l'illusion de stabilité
- Les quatre dimensions de la souveraineté
- Les repères de confiance (et leurs limites)
- Une matrice de décision par sensibilité
- Feuille de route pour un établissement
- Idées reçues
- Questions fréquentes
1. Un enjeu clinique, pas seulement informatique
Longtemps, la souveraineté numérique a été traitée comme un sujet d'infrastructure, cantonné à la direction des systèmes d'information. Cette époque est révolue. Dès lors qu'un dossier patient, un compte rendu d'imagerie ou un flux de biologie transite par une plateforme d'IA ou un cloud, la question du qui peut y accéder, sous quelle contrainte légale, et qui décide de la continuité du service devient une question de soin.
La raison est simple : une donnée de santé n'est pas un actif comme un autre. Elle est irréversiblement identifiante — on peut changer un mot de passe volé, pas un antécédent médical — et sa divulgation expose le patient à des discriminations durables (assurance, emploi, réputation). Le Règlement général sur la protection des données (RGPD) la classe pour cela parmi les données sensibles de l'article 9, soumises à un régime renforcé. La souveraineté n'est donc pas un supplément d'âme géopolitique : c'est la condition de tenue d'une promesse déontologique, le secret médical, dans un environnement technique que le praticien ne maîtrise plus directement.
2. L'angle mort juridique : au-delà du chiffrement
L'erreur la plus répandue consiste à réduire la protection des données à une question de chiffrement. Le chiffrement est nécessaire, mais il répond à une menace — l'interception ou le vol — et pas à une autre : la contrainte légale exercée sur le fournisseur lui-même.
Le Clarifying Lawful Overseas Use of Data Act (Cloud Act, États-Unis, 2018) autorise les autorités américaines à exiger d'un fournisseur soumis au droit américain la communication de données qu'il « possède, garde ou contrôle », quel que soit le lieu de stockage. En parallèle, la section 702 du FISA encadre des programmes de surveillance des communications d'étrangers. Concrètement : un hyperscaler dont la maison mère est américaine peut, en théorie, être enjoint de produire des données hébergées dans un centre de données européen — et l'injonction peut être assortie d'une interdiction d'en informer le client.
Si le fournisseur détient les clés de chiffrement, ou peut techniquement y accéder (ce qui est le cas de la plupart des services managés), le chiffrement « au repos » n'oppose alors aucun obstacle réel à une telle demande. C'est ici que se joue la souveraineté : non pas dans l'algorithme, mais dans la capacité juridique d'un tiers à contraindre votre prestataire.
La bonne question n'est pas « mes données sont-elles chiffrées ? » mais « qui peut légalement obliger mon fournisseur à ouvrir la porte, et puis-je l'en empêcher ? »
3. Transferts transatlantiques : l'illusion de stabilité
Depuis l'arrêt Schrems II de la Cour de justice de l'Union européenne (2020), qui a invalidé le « Privacy Shield », les transferts de données vers les États-Unis reposent sur un équilibre instable. Le mécanisme actuel, le Data Privacy Framework (décision d'adéquation de la Commission, 2023), a été confirmé par le Tribunal de l'Union le 3 septembre 2025 dans l'affaire Latombe — mais un pourvoi est pendant devant la Cour de justice, et le Comité européen de la protection des données a demandé à la Commission d'en réexaminer la solidité à la lumière d'évolutions institutionnelles américaines.
Autrement dit : le cadre est valide aujourd'hui, mais son horizon est incertain. Fonder l'architecture de données d'un hôpital sur un mécanisme qui a déjà été annulé deux fois par le passé, et dont la troisième version est de nouveau contestée, revient à construire sur une faille active. La prudence n'impose pas de bannir tout outil américain ; elle impose de ne pas faire de ce cadre le seul rempart pour les données les plus sensibles, et de conserver une capacité de repli.
4. Les quatre dimensions de la souveraineté
Pour sortir des slogans, il est utile de décomposer la souveraineté numérique en quatre dimensions que l'on peut évaluer fournisseur par fournisseur.
| Dimension | La question à poser | Pourquoi ça compte en santé |
|---|---|---|
| Juridiction | À quel(s) droit(s) le fournisseur et sa maison mère sont-ils soumis ? | Détermine qui peut le contraindre à livrer des données, même hébergées dans l'UE. |
| Hébergement | Où les données sont-elles physiquement stockées et traitées, y compris en sauvegarde et en support ? | Le support technique depuis un pays tiers peut rouvrir un accès que l'hébergement ferme. |
| Gouvernance | Qui décide des évolutions, des mises à jour, de la roadmap ? Qui détient les clés de chiffrement ? | La maîtrise réelle d'un outil dépend de qui en tient les commandes — pas de son adresse. |
| Réversibilité | Puis-je récupérer toutes mes données, dans un format ouvert, et changer de fournisseur sans blocage ? | Sans porte de sortie, la dépendance devient un risque de continuité des soins. |
Un fournisseur peut cocher une dimension et échouer sur une autre : un acteur européen qui verrouille vos données dans un format propriétaire pèche par réversibilité ; un acteur américain qui héberge en Europe pèche par juridiction. La souveraineté est un profil, pas une case à cocher.
5. Les repères de confiance (et leurs limites)
Plusieurs dispositifs aident à objectiver ce profil. Aucun n'est une garantie absolue ; ensemble, ils réduisent l'incertitude.
Certifications d'hébergement santé
La certification française HDS (Hébergeur de Données de Santé) impose des exigences de sécurité et de traçabilité aux hébergeurs de données de santé à caractère personnel. Elle est souvent exigée dans les marchés francophones et constitue un signal utile, même si elle ne préjuge pas à elle seule de la question de juridiction.
Qualifications de cloud de confiance
Le référentiel SecNumCloud de l'ANSSI (France) va plus loin : il intègre des critères d'immunité aux lois extraterritoriales et de contrôle capitalistique, ce qui en fait aujourd'hui l'un des rares labels adressant frontalement la dimension « juridiction ». Au niveau européen, le schéma EUCS porté par l'ENISA devait comporter un niveau « souverain » ; les critères les plus stricts (siège dans l'UE, localisation) ont toutefois été retirés des projets récents au profit d'une simple déclaration de juridiction, et le dossier reste ouvert. Un Cloud Sovereignty Framework est par ailleurs discuté comme critère d'achat public. Conclusion opérationnelle : ne présumez pas qu'« EUCS » signifiera « souverain » — vérifiez le niveau exact.
Initiatives d'écosystème et chiffrement maîtrisé
Des cadres comme Gaia-X visent l'interopérabilité et la portabilité entre fournisseurs de confiance. Enfin, deux leviers techniques renforcent la maîtrise : la gestion des clés par le client (BYOK/HYOK), qui empêche le fournisseur de déchiffrer sans vous, et l'auto-hébergement de solutions ouvertes, où la donnée ne quitte jamais votre périmètre. En Belgique, ces choix s'apprécient dans le cadre du RGPD et sous le contrôle de l'Autorité de protection des données, en articulation avec les plateformes sectorielles existantes.
6. Une matrice de décision par sensibilité
Toutes les données n'appellent pas le même niveau d'exigence. Classer avant d'arbitrer évite deux écueils symétriques : sur-contraindre des usages anodins, ou sous-protéger des données critiques.
| Niveau | Exemples | Exigence de souveraineté |
|---|---|---|
| Public / non lié au patient | Documentation, contenu pédagogique, modèles de courrier vierges | Faible — outils grand public acceptables |
| Interne pseudonymisé | Statistiques agrégées, cas anonymisés à visée pédagogique | Moyenne — hébergement UE, contrat de sous-traitance |
| Donnée de santé identifiante | Dossier patient, imagerie, biologie, comptes rendus | Élevée — hébergement santé, juridiction UE, clés maîtrisées |
| Donnée critique / population vulnérable | Psychiatrie, addictologie, santé sexuelle, données de mineurs | Maximale — souveraineté pleine, auto-hébergement à privilégier |
Cette grille se double d'un principe : plus une ré-identification serait dommageable, plus la juridiction du fournisseur doit être maîtrisée. Une donnée psychiatrique exposée n'a pas le même coût humain qu'une statistique agrégée.
7. Feuille de route pour un établissement
- Cartographier : lister les traitements, les données concernées et, pour chacun, le fournisseur, sa juridiction et le lieu d'hébergement (y compris support et sauvegardes).
- Classer selon la matrice ci-dessus et identifier les points de rupture (données sensibles chez un fournisseur non souverain).
- Contractualiser : exiger un contrat de sous-traitance RGPD interdisant toute réutilisation, précisant l'hébergement, la gestion des clés et les délais de notification d'incident.
- Exiger la réversibilité : formaliser dans chaque contrat les modalités et le coût de récupération des données en formats ouverts.
- Prioriser les migrations : traiter d'abord les données critiques, sans attendre une refonte globale ; la souveraineté se conquiert par paliers.
- Documenter : tenir à jour le registre des traitements et une analyse d'impact (AIPD) pour les usages à risque — c'est aussi votre meilleure protection en cas de contrôle.
- Chiffrement ≠ souveraineté : la juridiction du fournisseur est la variable décisive.
- Un hébergement « en Europe » par un acteur non-européen ne neutralise pas les lois extraterritoriales.
- Le Data Privacy Framework est valide mais contesté : n'en faites pas votre unique rempart.
- Classez vos données par sensibilité et faites monter l'exigence en conséquence.
- Réversibilité et clés maîtrisées sont vos garanties de liberté et de continuité.
8. Idées reçues
« Nous sommes trop petits pour intéresser qui que ce soit. » — La taille n'est pas un bouclier : les campagnes automatisées ciblent les maillons faibles, et un cabinet vaut, pour un attaquant, autant que la valeur de revente de ses dossiers.
« C'est un sujet de DSI, pas de médecin. » — Le choix d'un outil engage le secret médical, dont le praticien reste garant. La décision est technique dans ses moyens, mais déontologique dans sa portée.
« La souveraineté, c'est renoncer aux meilleurs outils. » — Faux dilemme. Il s'agit d'aligner le niveau d'exigence sur la sensibilité de la donnée, et de conserver une porte de sortie — pas de s'interdire l'innovation.
9. Questions fréquentes
Le chiffrement suffit-il à protéger des données de santé dans le cloud ?
Non. Il protège contre l'interception, mais pas contre une injonction légale visant le fournisseur. Si celui-ci peut techniquement déchiffrer, la protection juridique reste ouverte. La maîtrise des clés (BYOK/HYOK) et la juridiction du fournisseur sont déterminantes.
Un hébergement « en Europe » par un fournisseur américain est-il suffisant ?
Pas nécessairement. La localisation réduit certains risques mais ne met pas le fournisseur hors d'atteinte des injonctions de son pays d'origine. Il faut examiner le siège juridique, la chaîne de sous-traitance (dont le support) et les garanties contractuelles.
Le Data Privacy Framework sécurise-t-il définitivement les transferts ?
Il fournit une base légale valide à ce jour, mais fragilisée par un contentieux pendant. Une organisation prudente conserve une capacité de repli plutôt que d'en dépendre pour ses données les plus sensibles.
Faire le point sur votre exposition ?
Singulr accompagne les acteurs de santé pour cartographier leurs traitements, objectiver le profil de souveraineté de leurs fournisseurs et prioriser les actions. Un échange sans engagement pour situer vos points de rupture.
Nous contacter- RGPD (Règlement (UE) 2016/679), article 9 — données sensibles.
- U.S. CLOUD Act (2018) ; FISA section 702 — accès extraterritorial aux données.
- CJUE, Schrems II (C-311/18, 2020) — invalidation du Privacy Shield.
- Commission européenne, décision d'adéquation « Data Privacy Framework » (2023) ; Tribunal de l'UE, Latombe (3 sept. 2025) ; pourvoi C-703/25 P pendant devant la CJUE.
- ANSSI — référentiel SecNumCloud ; certification HDS (Hébergeur de Données de Santé).
- ENISA — schéma de certification cloud EUCS (critères de souveraineté en débat) ; Cloud Sovereignty Framework.
Ce guide est fourni à titre d'information générale et ne constitue pas un conseil juridique. Les échéances et jurisprudences citées sont à jour à la date de mise à jour ; pour une situation précise, consultez votre délégué à la protection des données ou un juriste spécialisé.