Protection des données de santé et HDS

Un contrat commercial perd sa valeur en quelques années. Un diagnostic psychiatrique, une séropositivité, un antécédent oncologique restent sensibles toute la vie du patient. Une donnée génomique va plus loin encore : elle identifie aussi les apparentés, et elle reste exploitable des décennies après le prélèvement.

Appliquez le théorème de Mosca à un horizon de confidentialité illimité : la somme de la durée de sensibilité et de la durée de migration dépasse forcément le délai avant la rupture cryptographique. Pour la santé, la migration post-quantique n'est pas une hypothèse mais une conclusion.

Le principe de la moisson anticipée achève la démonstration : un flux capté aujourd'hui sera lisible demain, et aucun dossier ne peut être rechiffré rétroactivement.

La santé cumule deux risques qui appellent des réponses différentes. La confidentialité d'abord : un dossier patient divulgué ne se répare pas. La disponibilité ensuite : les attaques par rançongiciel contre les établissements ont montré qu'elles visent la continuité des soins autant que les données elles-mêmes.

C'est pourquoi un projet de sécurité en santé ne peut pas se limiter au chiffrement. Il traite dans le même mouvement les sauvegardes immuables, les restaurations testées, le cloisonnement des comptes à privilèges et la journalisation probante.

Ajoutez une contrainte que peu de secteurs connaissent : aucune fenêtre d'arrêt. Un bloc opératoire ne se met pas en maintenance pour une bascule cryptographique.

L' hébergement de données de santé à caractère personnel est encadré par le code de la santé publique : il doit être assuré par un hébergeur certifié HDS. Le référentiel s'appuie sur les normes internationales de management de la sécurité, complétées d'exigences propres aux données de santé, et la certification est délivrée par un organisme accrédité indépendant.

Point souvent mal compris : l'obligation pèse sur l'hébergeur, pas sur le responsable de traitement. Un hôpital, une clinique, un laboratoire ou un éditeur e-santé n'a généralement pas à être certifié — il doit en revanche démontrer que ses données sont hébergées chez un prestataire qui l'est, et que le contrat le prévoit explicitement.

Un certificat HDS couvre l'infrastructure, les locaux et les procédures de l'hébergeur. Il ne couvre ni votre application, ni vos clés de chiffrement, ni vos comptes à privilèges, ni vos postes de travail, ni vos exports. La responsabilité du traitement reste la vôtre.

Or c'est presque toujours dans ce périmètre-là que se produisent les incidents réels : un export de données patients dans un tableur partagé, une sauvegarde non chiffrée sur un stockage secondaire, un accès prestataire jamais révoqué, une clé de chiffrement conservée à côté des données qu'elle protège.

Notre rôle est celui-là. Nous ne délivrons aucune certification — c'est juridiquement impossible pour l'intervenant technique — mais nous rendons l'audit franchissable et nous sécurisons ce que l'hébergeur ne prend pas en charge.

Les données de santé ne vivent pas dans un seul système. Elles circulent entre un dossier patient, des automates, des flux d'imagerie, des laboratoires partenaires et des prestataires en cascade.

La priorité découle du croisement entre la durée de sensibilité de la donnée et le risque dominant : déchiffrement rétrospectif, indisponibilité ou falsification.

Les données de santé relèvent des catégories particulières du RGPD : leur traitement est interdit par principe, sauf exception encadrée, et l' article 32 impose des mesures techniques adaptées à l'état de l'art. Pour des données conservées plusieurs décennies, cette notion d'état de l'art est exactement ce qui rend la trajectoire post-quantique défendable devant un contrôle.

S'y ajoutent l'obligation d' hébergement certifié HDS, la politique générale de sécurité des systèmes d'information de santé pour les référentiels d'identification et d'authentification, et NIS2, qui range le secteur parmi les activités les plus critiques et impose des politiques de cryptographie documentées.

Les dispositifs médicaux sont soumis à des exigences de cybersécurité propres, avec une contrainte structurelle : le logiciel validé ne se modifie pas librement. La sécurité s'obtient donc par l'architecture qui entoure l'équipement, et par les clauses imposées à l'achat.

Les programmes nationaux de financement de la cybersécurité hospitalière conditionnent leurs aides à des livrables concrets : inventaire, cloisonnement, sauvegardes testées, exercices de crise. Ce sont précisément les pièces que produit un projet mené correctement.

Enfin, pour la recherche clinique et les biotechs, s'ajoute la protection du patrimoine scientifique : des résultats captés aujourd'hui conservent leur valeur brevetable dans dix ans — l'horizon exact de l'attaquant.

Les briques techniques sont les mêmes qu'ailleurs. Ce sont les conditions d'exploitation qui changent : continuité des soins, matériel réglementé, volumétrie et sous-traitance en cascade.

Calibrée pour un établissement ou un éditeur e-santé, avec des livrables opposables à chaque étape. La version générique est décrite sur notre page migration quantum-safe.

Un hébergeur certifié vous garantit un socle sérieux : sécurité physique des sites, procédures d'exploitation, gestion des incidents, disponibilité contractuelle, encadrement de ses propres sous-traitants. C'est une condition nécessaire, et elle est vérifiée par un tiers indépendant.

Sur ce périmètre, il n'y a rien à refaire. Notre travail commence à la frontière du contrat.

Vos clés de chiffrement et l'endroit où elles sont conservées. Vos comptes à privilèges et ceux de vos prestataires. La configuration de votre application et de ses API. Vos exports, vos tableurs, vos environnements de test alimentés par des données réelles. Vos postes de travail. Et le choix des algorithmes qui protègent des données conservées trente ans.

Le raccourci « hébergé HDS donc conforme » est la cause la plus fréquente des écarts constatés en audit. Voir notre

pour le détail des briques concernées.

Poursuivre la lecture