Données de santé : quand la souveraineté numérique devient une question de survie pour les DSI

Données de santé : quand la souveraineté numérique devient une question de survie pour les DSI

Un hôpital paralysé pendant des jours, des dossiers patients exfiltrés et revendus sur des forums darknet, une direction générale convoquée par la CNIL. Ce scénario n'est plus une hypothèse de travail pour les exercices de crise : c'est le quotidien de plusieurs établissements et éditeurs de logiciels médicaux ces dernières années. La question n'est plus de savoir si une violation de données de santé peut vous arriver, mais comment vous préparez-vous à l'inévitable.

Et pendant que certaines DSI restent focalisées sur la conformité réglementaire comme finalité, d'autres ont compris que la souveraineté des données n'est pas un sujet politique abstrait. C'est une décision d'architecture avec des conséquences très concrètes sur la résilience opérationnelle.

Ce qui a changé ces deux dernières années

Le secteur de la santé est devenu, structurellement, l'une des cibles les plus attractives pour les acteurs malveillants. Pas uniquement parce que les données médicales se monnaient cher — un dossier de santé complet vaut bien davantage sur les marchés illicites qu'un numéro de carte bancaire, révocable en quelques minutes — mais parce que les établissements de santé combinent deux vulnérabilités rarement réunies ailleurs : une dépendance critique à la continuité de service et un retard historique en matière de sécurité informatique.

L'Agence du Numérique en Santé (ANS) a intensifié depuis 2022 ses programmes de cybersécurité à destination des établissements, avec des référentiels et des audits renforcés. L'ANSSI, de son côté, a intégré de nombreux établissements de santé dans le périmètre des Opérateurs de Services Essentiels (OSE) puis des entités essentielles sous NIS2. Ce n'est pas anodin : ça signifie des obligations de déclaration d'incident, des exigences de gouvernance, et une responsabilité personnelle des dirigeants qui devient très concrète.

Mais la vraie rupture de 2025-2026, c'est la convergence de trois dynamiques simultanées : le durcissement du cadre réglementaire européen (NIS2 pleinement applicable, RGPD dont les sanctions ont atteint des niveaux records), la multiplication des attaques par ransomware ciblant spécifiquement les infrastructures de santé, et — sujet moins visible mais tout aussi structurant — la remise en question progressive des dépendances aux hyperscalers américains pour les données les plus sensibles.

HDS : le label qui rassure, et celui qui trompe

Toute infrastructure hébergeant des données de santé à caractère personnel doit, en France, être certifiée Hébergeur de Données de Santé (HDS). Le principe est sain. La réalité d'application l'est moins.

Premier point d'attention : la certification HDS d'un hébergeur ne vous décharge pas de vos responsabilités en tant que responsable de traitement. C'est une erreur fréquente. Un éditeur ou un prestataire certifié HDS peut tout à fait stocker vos données sur une infrastructure dont vous n'avez pas évalué les sous-traitants, les flux de données transatlantiques, ou les procédures de réponse à incident. La certification atteste d'une organisation et de processus. Elle n'atteste pas que vos données ne quitteront jamais le territoire européen.

Deuxième point, plus inconfortable : plusieurs grands acteurs cloud américains opèrent des régions européennes certifiées HDS. AWS Paris, Azure France Central — ces environnements répondent techniquement aux exigences. Mais depuis l'invalidation du Privacy Shield et les débats autour du EU-US Data Privacy Framework, une question juridique persiste : une entreprise américaine soumise au Cloud Act peut-elle garantir durablement la confidentialité de données hébergées en Europe face à une injonction des autorités américaines ? La réponse honnête est : personne ne le sait avec certitude. Les juristes se divisent, les contrats de DPA ne règlent pas la question, et les arrêts Schrems ont démontré que les accords politiques ne suffisent pas à sécuriser un modèle juridique.

Ce n'est pas un argument pour bannir les hyperscalers de vos infrastructures de santé — la réalité opérationnelle est plus nuancée. Mais c'est un argument sérieux pour cartographier précisément quelles données vous leur confiez, et lesquelles méritent un traitement différent.

Ce que les DSI sous-estiment encore : la surface d'attaque applicative

Les violations de données de santé ne passent pas toujours par les vecteurs spectaculaires qu'on imagine. Oui, les ransomwares font les gros titres. Mais une proportion significative des incidents sérieux commence plus discrètement : un credential compromis sur un portail patient, une API mal sécurisée dans un logiciel de gestion de cabinet, un SaaS médical dont la politique de mots de passe date de 2015.

Le DPI (Dossier Patient Informatisé) est souvent le point de départ de l'analyse de risque. Mais autour de lui gravite une constellation d'outils — messagerie sécurisée de santé, télémédecine, PACS pour l'imagerie, outils de coordination de soins, applications mobiles pour les soignants — dont chacun représente un point d'entrée potentiel. L'enjeu n'est pas de sécuriser un système : c'est de sécuriser un écosystème interconnecté, souvent hétérogène, souvent partiellement géré par des éditeurs tiers dont vous ne maîtrisez pas les pratiques de développement.

C'est là que la question de la souveraineté rejoint concrètement la sécurité opérationnelle. Un éditeur européen, soumis aux mêmes réglementations que vous, auditable selon les mêmes référentiels, avec des équipes accessibles dans votre fuseau horaire et compréhensibles dans votre langue — ce n'est pas uniquement un choix politique. C'est un choix de gestion du risque.

Des acteurs comme Atos (via ses offres BDS Healthcare) ou Inria Health Data Hub illustrent des approches différentes : l'un côté intégration industrielle, l'autre côté recherche et gouvernance publique. Sans entrer dans l'évaluation commerciale de ces acteurs, ils incarnent un fait : il existe en Europe une offre crédible pour les données de santé les plus sensibles, à condition de ne pas la chercher uniquement dans les catalogues des trois grands américains.

Trois réflexes concrets pour une DSI sous pression

Cartographier avant de protéger. Vous ne pouvez pas sécuriser ce que vous ne connaissez pas. Avant tout investissement en outillage de sécurité, posez-vous la question fondamentale : où sont réellement vos données de santé ? Pas où elles devraient être selon vos politiques — où elles sont effectivement. Shadow IT, fichiers Excel de coordination partagés sur des drives personnels, applications SaaS souscrites directement par des services cliniques sans validation IT. Ce mapping est rarement agréable à faire. Il est toujours utile.

Distinguer les niveaux de sensibilité. Toutes vos données ne méritent pas le même niveau de protection, et vouloir tout sécuriser de manière identique est une erreur budgétaire et opérationnelle. Les données nominatives de patients — diagnostics, prescriptions, historiques — ne supportent pas les mêmes compromis que les données agrégées et anonymisées utilisées pour le reporting. Appliquez une logique de tiering : les données les plus sensibles dans les environnements les mieux contrôlés, avec des exigences explicites sur la localisation et les accès.

Traiter la réponse à incident comme un actif, pas une formalité. Le Plan de Reprise d'Activité (PRA) et le Plan de Continuité d'Activité (PCA) existent dans la plupart des établissements. Ce qui manque souvent, c'est leur test réel. Un PRA qui n'a jamais été exercé est essentiellement un document qui dormira dans un serveur pendant que votre système sera hors ligne. La réglementation NIS2 va dans ce sens en imposant des tests réguliers pour les entités essentielles. Ne le faites pas parce que la loi l'exige. Faites-le parce que le jour où vous en aurez besoin, vous n'aurez pas le temps d'apprendre.

La vraie question de fond : peut-on externaliser la responsabilité ?

Il y a une tentation, compréhensible, de résoudre la complexité de la sécurité des données de santé par l'externalisation totale. Confier l'infrastructure à un hébergeur certifié, les applications à des éditeurs reconnus, la supervision à un SOC externalisé — et considérer que la responsabilité suit les contrats.

Elle ne suit pas. Ou plutôt : elle se partage, mais ne disparaît pas du côté du responsable de traitement. Les scandales récents — des établissements ayant découvert a posteriori que leur éditeur sous-traitait à des prestataires non certifiés, ou que des données étaient répliquées dans des régions cloud non déclarées — illustrent que la diligence ne peut pas s'arrêter à la signature du contrat.

Cela ne signifie pas qu'il faut tout internaliser, ce qui serait souvent ni réaliste ni pertinent pour une PME ou une ETI de santé. Cela signifie qu'il faut des clauses contractuelles précises sur la localisation des données, le droit d'audit, la gestion des sous-traitants, et les procédures de notification d'incident. Et que ces clauses doivent être vérifiées, pas seulement signées.

En guise d'ouverture

La souveraineté numérique en santé n'est pas une posture idéologique réservée aux partisans d'un Internet européen fermé. C'est une réponse pragmatique à un environnement géopolitique et réglementaire dans lequel les certitudes d'hier — que les grands acteurs américains offriraient une stabilité juridique durable — se sont révélées fragiles.

Pour les DSI et CTO d'établissements de santé ou d'éditeurs de logiciels médicaux, la question n'est pas « faut-il migrer vers un cloud souverain ? » mais plutôt : « pour quelles données, dans quel calendrier, avec quelles contreparties opérationnelles ? »

C'est une décision d'architecture autant qu'une décision politique. Et c'est précisément ce qui en fait un sujet de DSI, pas uniquement un sujet de juriste ou de DPO.

La vraie difficulté, en 2026, n'est plus de convaincre les directions générales que le risque est réel. C'est de transformer cette conviction en feuille de route concrète, sans paralyser les équipes ni sacrifier l'innovation au nom de la conformité. Cet équilibre-là n'a pas de solution universelle. Et c'est peut-être la conversation la plus utile que les DSI du secteur santé pourraient avoir entre eux.