Cédric Millauriaux

Cédric Millauriaux

Fondateur de Dinno, agence de développement d'applications de santé

Révision réglementaire :

11 min de lecture

En bref

L'article L.1111-8 du code de la santé publique impose que toute personne physique ou morale qui héberge des données de santé à caractère personnel recueillies à l'occasion d'activités de prévention, de diagnostic, de soins ou de suivi médico-social pour le compte de tiers soit certifiée. Dans l'immense majorité des projets, la réponse n'est pas de se certifier soi-même mais de s'appuyer sur un hébergeur déjà certifié — décision qui ne coûte presque rien si elle est prise au cadrage, et une migration si elle est prise après.

Hébergement des données de santé (HDS) : ce que votre projet doit prévoir

L’hébergement HDS est le sujet sur lequel les porteurs de projet se trompent le plus — dans les deux sens. Certains croient devoir se certifier alors qu’ils n’ont qu’à choisir le bon hébergeur. D’autres pensent être hors périmètre parce que leur application est « grand public », et découvrent l’inverse au moment du premier partenariat avec un établissement.

Ce que dit le texte

L’article L.1111-8 du code de la santé publique, dans sa rédaction issue de la loi n° 2016-41 du 26 janvier 2016, pose le principe : toute personne physique ou morale qui héberge des données de santé à caractère personnel recueillies à l’occasion d’activités de prévention, de diagnostic, de soins ou de suivi médico-social doit être agréée ou certifiée à cet effet.

Trois éléments de cette phrase méritent l’attention, parce que c’est là que se joue la qualification :

  • « héberge » — l’obligation porte sur l’activité d’hébergement, pas sur le fait de manipuler des données ;
  • « données de santé à caractère personnel » — la nature des données, pas leur volume ;
  • « recueillies à l’occasion d’activités de prévention, de diagnostic, de soins ou de suivi médico-social » — le contexte du recueil, qui est le critère le plus discriminant en pratique.

Une exception importante : les établissements de santé qui gèrent leur propre système d’information ne sont pas tenus de se faire certifier. L’obligation vise l’hébergement pour le compte de tiers.

Deux façons d’y répondre, et une seule qui vous concerne probablement

S’appuyer sur un hébergeur certifié

C’est la réponse dans la très grande majorité des projets. Vous n’êtes pas hébergeur : vous éditez une application. Vous retenez un prestataire déjà certifié, et vous contractualisez avec lui sur le périmètre couvert par son certificat.

Le coût marginal est faible — les grands fournisseurs proposent des offres certifiées — mais la contractualisation demande de l’attention : le certificat de votre hébergeur couvre certaines activités et pas d’autres, et l’écart entre ce qu’il couvre et ce dont vous avez besoin reste votre responsabilité.

Se certifier soi-même

Cela ne se justifie que si vous exercez vous-même une activité d’hébergement pour le compte de tiers. C’est le cas d’un éditeur qui opère l’infrastructure de ses clients, pas d’un éditeur qui déploie son SaaS chez un fournisseur certifié.

Le dispositif distingue deux catégories de certificat : hébergeur d’infrastructure physique — mise à disposition et maintien de l’infrastructure matérielle et des sites physiques — et hébergeur infogéreur — mise à disposition de l’infrastructure virtuelle, administration du système d’information, sauvegarde externalisée des données.

Ce que le référentiel de 2024 a changé

Le nouveau référentiel, publié au Journal officiel le 16 mai 2024 et entré en vigueur le 16 novembre 2024, a modifié le paysage sur trois points.

La souveraineté des données. Le stockage physique doit désormais être réalisé exclusivement sur le territoire d’un pays situé au sein de l’Espace économique européen. Les hébergeurs doivent en outre déclarer à leurs clients les accès distants depuis des pays tiers et les risques associés, et cartographier publiquement les transferts hors EEE.

La clarification du périmètre des activités, en particulier de l’activité d’administration et d’exploitation, qui était la source principale d’ambiguïté sur « qui couvre quoi ».

L’articulation avec SecNumCloud de l’ANSSI, et l’intégration des évolutions de la norme ISO 27001 dans sa version 2022.

Les hébergeurs déjà certifiés disposaient de vingt-quatre mois pour se mettre en conformité, au plus tard le 16 mai 2026 — échéance désormais passée. Si votre contrat d’hébergement date d’avant novembre 2024, c’est le moment de vérifier le périmètre exact du certificat en vigueur de votre prestataire.

Le point de vigilance que presque tout le monde manque

S’appuyer sur un hébergeur certifié HDS ne rend pas votre application conforme. Le certificat couvre l’hébergement. Tout ce qui se passe dans votre code — authentification, habilitations, journalisation, chiffrement applicatif, imputabilité des actions — reste votre responsabilité, et relève de la PGSSI-S.

C’est la confusion la plus fréquente, et la plus coûteuse en audit client : « nous sommes hébergés HDS » n’est pas une réponse à « votre solution est-elle sécurisée ».

Pourquoi trancher au cadrage change tout

L’obligation HDS est, avec l’INS, l’une des deux décisions dont le coût dépend entièrement du moment où on la prend.

Identifiée au cadrage, elle se résume à un choix de fournisseur — quelques jours de comparaison et de contractualisation. Découverte après la mise en production, elle impose une migration d’infrastructure, une reprise de données, une renégociation contractuelle, et souvent une interruption de service.

Les pages ci-dessous détaillent chaque volet du sujet.

Questions fréquentes

Dans ce dossier

Hébergement de données de santé

Faites qualifier votre besoin HDS par un expert e-santé

Analyse de vos flux de données, détermination du périmètre soumis à l'obligation, choix hébergeur certifié ou certification propre, et impact sur votre architecture. Réponse écrite.

Demander une qualification HDS

Édité par Dinno, agence de développement d'applications de santé.