Hébergement de données de santé (HDS) : ce qu'un éditeur doit savoir avant de choisir son architecture
Qui doit être certifié HDS, ce que le référentiel v2 et le décret du 24 mars 2026 ont changé, comment répartir les six activités entre IaaS et éditeur, et la checklist d'architecture à valider avant l'audit.
Ala Ben Aicha
Réponse directe
La certification HDS s'impose à toute personne qui héberge des données de santé à caractère personnel pour le compte d'un tiers (établissement, professionnel de santé, patient) lorsque ces données ont été recueillies à l'occasion d'activités de prévention, de diagnostic, de soins ou de suivi social et médico-social. Un éditeur SaaS installé sur un IaaS certifié n'est pas couvert d'office : si ses équipes administrent la production, il exerce l'activité 5 et doit être certifié pour celle-ci. Depuis le 16 mai 2026, tous les certificats valides relèvent du référentiel v2, et depuis fin septembre 2026 le stockage des données doit, par décret, se faire exclusivement dans l'UE ou l'EEE.
Le périmètre : qui est « hébergeur » ?
Le régime vient de l'article L.1111-8 du Code de la santé publique. L'ANS en résume le champ d'application : il vise l'hébergement pour le compte d'un responsable de traitement, de données collectées dans un contexte de prise en charge. Trois conséquences pratiques :
- Un établissement qui exploite son DPI sur sa propre infrastructure n'est pas hébergeur au sens du texte. Le RGPD et ses obligations de sécurité s'appliquent toujours.
- Un établissement qui héberge pour d'autres (un GHT pour ses membres, par exemple) entre dans le champ. L'ANS recensait d'ailleurs 14 établissements de santé certifiés en octobre 2025.
- Une application de bien-être qui collecte des données hors de tout parcours de soins pose une question de qualification. Lisez la FAQ de l'ANS et documentez votre analyse plutôt que de supposer.
La certification est délivrée par des organismes accrédités et l'ANS publie la liste des hébergeurs certifiés sur sa page certification des hébergeurs de données de santé. Un certificat indique le service, les sites, les dates et les activités couvertes. C'est ce périmètre qu'il faut lire, pas le logo sur la plaquette commerciale.
Les six activités
L'article R.1111-9 du CSP découpe l'hébergement en six activités. Le référentiel v1 regroupait ces activités en deux certificats (infrastructure physique et infogérance) ; en v2, le périmètre s'exprime activité par activité.
| Activité | Contenu (R.1111-9) | Qui l'exerce en général |
|---|---|---|
| 1 | Mise à disposition et maintien en condition opérationnelle des sites physiques | Opérateur de datacenter |
| 2 | Infrastructure matérielle du SI | Opérateur de datacenter ou de cloud |
| 3 | Infrastructure virtuelle du SI | Fournisseur IaaS |
| 4 | Plateforme d'hébergement d'applications | Fournisseur PaaS, ou l'éditeur s'il gère son propre middleware |
| 5 | Administration et exploitation du SI contenant les données de santé | Celui qui détient les accès d'administration, souvent l'éditeur |
| 6 | Sauvegarde des données de santé, y compris l'archivage électronique depuis le décret 2026-209 | Prestataire de sauvegarde ou de tiers-archivage |
L'activité 5 est celle qui piège les éditeurs. Lors de son webinaire du 15 octobre 2025, l'ANS l'a définie comme la maîtrise des interventions sur les ressources mises à disposition, avec quatre activités annexes : attribution et revue annuelle de droits d'accès nominatifs, sécurisation de la procédure d'accès, collecte et conservation des traces d'accès et de leurs motifs, validation préalable des interventions. La règle énoncée est nette : un hébergeur qui met en œuvre une seule de ces activités annexes doit être certifié pour l'activité 5.
Ce que le référentiel v2 et le décret de 2026 ont changé
Le référentiel v2 a été approuvé par arrêté du 26 avril 2024 et publié au Journal officiel le 16 mai 2024. Les nouveaux candidats sont audités sur la v2 depuis le 16 novembre 2024 ; les hébergeurs déjà certifiés avaient jusqu'au 16 mai 2026 pour basculer. Le référentiel s'appuie sur ISO/IEC 27001 et y ajoute des exigences propres à la santé. Un certificat ISO 27001 aide si son périmètre recouvre exactement le service à certifier ; un certificat obtenu pour une autre offre ou une autre entité du groupe ne règle rien.
Le volet souveraineté tient en quatre exigences :
| Exigence v2 | Ce qu'elle impose |
|---|---|
| 28 | Stockage des données dans l'EEE, par l'hébergeur et par ses sous-traitants. Seuls des sites situés dans l'EEE peuvent être certifiés pour les activités 1, 2 ou 6 |
| 29 | Accès à distance depuis un pays hors EEE fondé sur une décision d'adéquation ou sur des garanties de l'article 46 du RGPD, détaillées dans le contrat |
| 30 | Le contrat liste les législations extra-européennes qui pourraient contraindre l'hébergeur ou un sous-traitant à un transfert ou à un accès non autorisé (au sens de l'article 48 du RGPD), les mesures d'atténuation et les risques résiduels |
| 31 | Publication d'une URL : soit la cartographie des transferts et le tableau des garanties, soit la mention « Aucun risque d'accès imposé par la législation d'un pays tiers en violation du droit de l'Union » (cas notamment d'un hébergeur qualifié SecNumCloud 3.2) |
La loi SREN du 21 mai 2024 a ensuite fait remonter ces règles dans le code. Le décret n° 2026-209 du 24 mars 2026 crée l'article R.1111-9-1 : lorsque l'hébergement donne lieu à un stockage, celui-ci est « mis en œuvre exclusivement sur le territoire d'un Etat membre de l'Union européenne ou partie à l'accord sur l'Espace économique européen ». Il enrichit aussi le contenu obligatoire du contrat (R.1111-11). Ces deux volets sont entrés en vigueur six mois après la publication au JO du 26 mars, soit fin septembre 2026.
Prochaine étape : l'ANS a annoncé une version 2.1 du référentiel, alignée sur le décret, dont la publication est prévue en octobre 2026, avec des exigences applicables trois mois plus tard et contrôlées lors de l'audit de surveillance ou de renouvellement. Vérifiez si l'arrêté est paru au moment où vous lisez ces lignes. Dans tous les cas, les contrats existants devront peut-être être amendés.
HDS et SecNumCloud ne sont pas interchangeables
HDS n'exige pas la qualification SecNumCloud de l'ANSSI. Les deux régimes couvrent des périmètres différents : un hébergeur qualifié SecNumCloud reste soumis à HDS s'il héberge des données de santé pour le compte de tiers, et une certification HDS ne vaut pas qualification SecNumCloud.
SecNumCloud devient une obligation par une autre voie. L'article 31 de la loi SREN et le décret n° 2026-272 du 14 avril 2026 imposent, pour les données d'une sensibilité particulière, un cloud protégé contre les législations extraterritoriales aux administrations de l'État, à certains opérateurs et à certains GIP ; la liste couvre la Plateforme des données de santé et l'ANS. Si vous vendez à ces acheteurs, attendez-vous à voir SecNumCloud dans le cahier des charges. Pour une clinique ou un cabinet, HDS reste la base légale ; lisez quand même le cahier des charges, certains acheteurs vont au-delà.
Matrice de décision : l'éditeur doit-il être certifié ?
Le schéma « IaaS pour les activités 1 à 4, éditeur pour 5 et 6 » circule beaucoup. Comme règle générale, il est faux. Deux questions tranchent : qui contracte l'hébergement avec le client, et qui fait réellement quoi en production.
| Situation | Activités exercées par l'éditeur | Certification de l'éditeur |
|---|---|---|
| Logiciel installé dans le datacenter de l'établissement, exploité par sa DSI | Aucune | Non requise. Contrat de sous-traitance RGPD si l'éditeur intervient à distance |
| L'établissement contracte lui-même avec un hébergeur certifié 1 à 6 ; l'éditeur livre le logiciel sans accès d'administration à la production | Aucune | En principe non requise ; le contrat et les accès réels doivent le démontrer |
| SaaS de l'éditeur sur un IaaS certifié 1, 2, 3 et 6 ; l'équipe de l'éditeur gère OS, bases, déploiements et comptes | 4 et 5 | Requise pour les activités réellement exercées |
| SaaS sur un PaaS managé certifié 1 à 5, mais des développeurs gardent un accès en lecture à la base de production | Une partie de la 5 | Requise pour la 5, puisqu'une activité annexe est exercée |
| Sauvegarde ou archivage externalisé chez un tiers | Aucune si c'est le tiers qui l'opère | Le tiers doit être certifié pour la 6, archivage électronique compris |
Faites valider votre découpage par l'organisme certificateur avant l'audit. Le webinaire de l'ANS signale un cas récurrent : des modèles de responsabilité partagée qui renvoient la gestion des comptes et des identités au seul client, alors que c'est précisément le cœur de l'activité 5.
HDS est un régime français. La Suisse et la Belgique ont leurs propres cadres, que cet article ne traite pas.
Checklist d'architecture avant de choisir un hébergeur
Localisation de toutes les copies. La base principale en région française ne suffit pas. Réplicas, sauvegardes, site de reprise, index de recherche, journaux applicatifs qui contiennent des données, exports analytiques : tout doit rester dans l'EEE, y compris chez les sous-traitants.
Chiffrement et clés. Chiffrement au repos et en transit, clés dans un KMS ou un HSM situé dans l'EEE. Décidez qui peut utiliser les clés : le fournisseur, l'éditeur, le client. C'est un argument concret pour le tableau des risques résiduels de l'exigence 30.
Traces d'accès. L'activité 5 suppose de collecter et conserver les traces des accès et leurs motifs. Concrètement : comptes nominatifs, référence de ticket obligatoire pour toute session de production, journaux immuables. Ces journaux contiennent souvent des données de santé et suivent donc les mêmes règles de localisation.
Accès du support. Pas d'accès permanent à la production. Accès juste-à-temps, MFA, sessions enregistrées, revue annuelle des droits, validation préalable des interventions. Une équipe de support hors EEE constitue un accès à distance depuis un pays tiers : il faut une décision d'adéquation ou des garanties de l'article 46, écrites dans le contrat. L'authentification des professionnels de santé dans l'application est un sujet distinct, traité par Pro Santé Connect.
Sous-traitants. Inventoriez chaque service qui reçoit des données : suivi d'erreurs, APM, e-mail, SMS, outil de ticketing où l'on colle des captures d'écran, API de LLM. L'ANS note que démontrer le respect des contraintes de souveraineté par chaque sous-traitant prend du temps. Un registre versionné avec le code aide (prestataires fictifs, revu à chaque release) :
service: example-dpi-saas
hds_scope:
iaas_provider:
certificate_activities: [1, 2, 3, 6]
regions: [eu-fr-paris-1, eu-fr-paris-2]
vendor:
certificate_activities: [4, 5]
data_stores:
- name: postgres-primary
region: eu-fr-paris-1
encryption_at_rest: true
key_ref: kms://eu-fr-paris-1/keys/dpi-prod
- name: backups
region: eu-fr-paris-2
retention_days: 35
sub_processors:
- name: error-tracking
region: eu-de-frankfurt
receives_health_data: false
scrubbing: request-body-and-headers
- name: transactional-email
region: eu-ie-dublin
receives_health_data: false
remote_access:
- team: support-l2
location: EEA
mode: just-in-time, ticket-required, session-recorded
Une ligne receives_health_data: false n'a de valeur que si un test le vérifie : par exemple, un test d'intégration qui déclenche une erreur sur un dossier synthétique (DOE^JANE) et contrôle que la charge utile envoyée à l'outil de suivi d'erreurs ne contient ni nom, ni INS, ni texte clinique.
Réversibilité. Le contrat d'hébergement doit prévoir la restitution des données en fin de prestation. Définissez le format (FHIR, CSV avec dictionnaire de données), le délai, la preuve de suppression, et testez l'export au moins une fois par an.
Environnements. Aucune donnée réelle en recette ou en développement. Si un incident exige un jeu de données de production, il se traite dans l'environnement certifié, avec trace.
RGPD, AIPD et NIS2 : ce que HDS ne couvre pas
HDS certifie un hébergeur ; il ne rend pas un traitement conforme. Le traitement de données de santé à grande échelle impose une analyse d'impact au titre de l'article 35 du RGPD. L'éditeur est le plus souvent sous-traitant au sens de l'article 28 et doit aider le responsable de traitement à la réaliser : fournissez une description technique réutilisable (flux, localisations, sous-traitants, mesures). Les choix d'architecture correspondants sont détaillés dans l'architecture de données de santé conforme au RGPD.
NIS2 ajoute ses propres obligations de gestion des risques et de notification d'incidents pour les entités concernées, établissements comme fournisseurs ; voir NIS2 pour les équipes IT santé. Pour situer HDS parmi les autres textes européens (MDR, AI Act, EHDS), la cartographie de la conformité santé en Europe sert de point de départ.
Pièges fréquents
- Accepter « certifié HDS » sans lire le certificat : activités, sites, service exact.
- Base de données en France, mais journaux et traces envoyés vers un SaaS d'observabilité hors EEE.
- Support de niveau 2 externalisé hors EEE sans clause contractuelle sur l'accès à distance.
- Oublier les contrats déjà signés lors du passage à la v2, puis à la v2.1.
- Confondre HDS et SecNumCloud dans une réponse à appel d'offres.
Si vous devez répartir les activités entre votre hébergeur et votre équipe, ou préparer l'architecture avant un audit HDS, je peux intervenir sur ce cadrage technique dans le cadre du développement HealthTech.