Hébergement des données de santé (HDS) : ce qu'il faut savoir en 2026

Qui est concerné par la certification HDS, quelles obligations pour les éditeurs et établissements, et comment cadrer un projet d'hébergement conforme.
Toute structure qui héberge des données de santé à caractère personnel pour le compte d'un tiers doit recourir à un hébergeur certifié HDS. Cette obligation, issue du Code de la santé publique, structure aujourd'hui l'ensemble de l'écosystème de la santé numérique.
Qui est concerné ?
Les établissements de santé qui externalisent leur infrastructure, mais aussi les éditeurs de logiciels qui hébergent les données de leurs clients, sont directement concernés. La question se pose dès la conception du produit.
Déterminer si l'on est responsable de traitement, sous-traitant ou hébergeur est la première étape — et celle qui conditionne toutes les obligations suivantes.
Cadrer un projet conforme
Un projet d'hébergement conforme repose sur une analyse de risques, un contrat d'hébergement précis et une répartition claire des responsabilités. Un accompagnement en conformité en amont évite les reprises coûteuses.
Le cadre : l'article L.1111-8 du Code de la santé publique
Depuis 2018, l'ancien agrément a laissé place à une certification délivrée par des organismes accrédités par le COFRAC (ou par l'organisme national d'accréditation d'un autre État membre de l'Union), sur la base d'un référentiel publié par l'Agence du Numérique en Santé et adossé aux normes ISO 27001 et ISO 20000. Le certificat est valable trois ans, avec audits de surveillance annuels ; depuis le 16 mai 2026, seule la version v2 du référentiel (arrêté du 26 avril 2024, publié le 16 mai 2024) fait foi.
Le principe est simple à énoncer : toute personne qui héberge des données de santé recueillies à l'occasion d'activités de prévention, de diagnostic, de soins ou de suivi social et médico-social, pour le compte d'un tiers, doit être certifiée. Toute la difficulté est dans l'application : qui héberge « pour le compte d'un tiers » ?
Êtes-vous hébergeur sans le savoir ?
L'éditeur SaaS qui stocke les données de santé de ses clients établissements est hébergeur — c'est le cas le plus fréquent, et le plus souvent découvert tardivement, parfois au détour d'un appel d'offres perdu. Le prestataire d'infogérance qui administre un système d'information contenant des données de santé exerce l'activité 5. À l'inverse, l'établissement qui héberge ses propres données pour son propre compte n'a pas à être certifié — mais le jour où il mutualise son infrastructure au bénéfice d'autres structures, la question se repose.
Pour un éditeur, deux voies : se certifier (investissement lourd, différenciant) ou s'adosser à un hébergeur certifié en conservant un partage de responsabilités limpide. Le choix se fait dès l'architecture produit — le refaire après coup coûte dix fois plus cher.
Choisir et contractualiser : la checklist
Certificat v2 en cours de validité, vérifié à la source ; périmètre d'activités couvrant exactement les prestations achetées ; localisation des données et conditions d'accès depuis des pays tiers ; chaîne de sous-traitance documentée (l'hébergeur de votre éditeur est-il lui-même certifié ?) ; clauses de réversibilité et de restitution des données testables ; contrat combinant les exigences de l'article 28 du RGPD et celles du Code de la santé publique ; enfin, référence du certificat consignée dans votre registre des traitements, avec une revue annuelle planifiée.
Un point souvent négligé : les environnements de test et de recette. Y copier des données réelles de patients sans les mêmes garanties d'hébergement et de sécurité est l'un des écarts les plus fréquents que nous rencontrons en audit.
Les questions qu'on nous pose le plus souvent
« Mon cabinet médical doit-il être certifié ? » Non : le professionnel qui héberge ses propres dossiers pour son propre exercice n'est pas hébergeur au sens du texte — mais son éditeur de logiciel en mode SaaS, lui, doit l'être. « Un cloud américain certifié HDS, est-ce conforme ? » La certification v2 l'exige : hébergement dans l'EEE et transparence sur les accès des pays tiers ; la conformité formelle existe, l'analyse de risque reste à faire et à documenter. « Et les sauvegardes ? » La sauvegarde externalisée est l'activité certifiable n° 6 : un prestataire de backup qui reçoit des données de santé doit être certifié pour cette activité. « La certification du prestataire me dispense-t-elle d'un contrat ? » Jamais : l'article 28 du RGPD et les exigences du Code de la santé publique s'ajoutent à la certification, ils ne s'y substituent pas.
Un projet d'hébergement conforme, étape par étape
Étape 1 — qualifier : qui est responsable de traitement, qui est sous-traitant, qui héberge quoi. Étape 2 — cartographier les données et les flux, environnements de test compris. Étape 3 — sélectionner l'hébergeur sur pièces : certificat v2, périmètre d'activités, localisation, chaîne de sous-traitance, réversibilité. Étape 4 — contractualiser : DPA article 28, clauses CSP, niveaux de service, audit et restitution. Étape 5 — documenter : registre, analyse de risques, AIPD si le traitement le justifie. Étape 6 — surveiller : revue annuelle du certificat et des sous-traitants, test de réversibilité. Compter plusieurs semaines pour un projet simple, plusieurs mois quand une migration de données est en jeu — et toujours moins cher en amont qu'en correction.
Sources officielles
- Certification des hébergeurs de données de santé — Agence du Numérique en Santé
- Arrêté du 26 avril 2024 (référentiel HDS) — Légifrance
- Règlement (UE) 2016/679 « RGPD », article 28 — EUR-Lex
Dernière vérification juridique : 17 août 2026
