Certification HDS : ce que l'hébergeur de données de santé garantit, et ce qui reste à
votre charge

La certification HDS atteste qu'un prestataire qui héberge des données de santé à caractère personnel pour le compte d'un tiers respecte un référentiel approuvé par arrêté, audité par un organisme accrédité, sur tout ou partie de six activités d'hébergement définies par le code de la santé publique. Voilà pour la définition. Elle tient en une phrase et elle est exacte.

Elle est aussi la source du malentendu le plus coûteux du secteur. Un logo HDS sur la plaquette d'un hébergeur ne dit rien de l'application que vous avez déployée chez lui, de la qualité de ses comptes d'accès, ni de ce que son portail expose sur internet. Le certificat borne son objet avec précision, et tout ce qui est en dehors de ce cadre vous revient. Les cas français d'hôpitaux attaqués dont on reparle plus bas sont tous entrés par cet en-dehors, ce qui vaut la peine de regarder où la ligne passe, article du code à l'appui.

Ce que la loi impose, et à qui

Le texte de base est l'article L. 1111-8 du code de la santé publique. Toute personne 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 social et médico-social, pour le compte des personnes qui les ont produites ou pour le compte du patient lui-même, le fait dans les conditions de cet article. Pour l'hébergement sur support numérique, cela veut dire détenir un certificat de conformité délivré par un organisme accrédité. L'hébergement sur papier relève d'un autre régime, un agrément du ministre de la Culture, qu'on laisse de côté.

Le critère décisif est pour le compte d'un tiers. L'article R. 1111-8-8 le précise : l'activité d'hébergement consiste à héberger ces données pour le compte du responsable de traitement à l'origine de leur production, ou pour le compte du patient. Il ajoute une exclusion utile : recevoir des données pour une courte période afin de les saisir, de les mettre en forme ou de les dématérialiser n'est pas de l'hébergement. Et il pose l'obligation miroir, celle qui vous concerne si vous êtes client : le responsable de traitement qui confie l'hébergement à un tiers doit s'assurer que ce tiers détient le certificat. Le référentiel de certification traduit la même idée en langage RGPD, en visant le prestataire qui a la qualité de sous-traitant au sens de l'article 28.

Un hôpital qui garde son dossier patient informatisé sur ses propres serveurs, pour son propre compte, n'a donc pas à être certifié. Un éditeur SaaS de logiciel de cabinet qui stocke les dossiers de ses clients médecins, lui, est un hébergeur au sens du texte, ou doit s'appuyer sur un hébergeur certifié pour les activités qu'il ne réalise pas lui-même. Et le professionnel de santé qui choisit cet éditeur porte l'obligation de vérification. La sanction pénale n'est pas décorative : l'article L. 1115-1 punit de trois ans d'emprisonnement et de 45 000 euros d'amende le fait de procéder ou de faire procéder à un hébergement sans le certificat prévu.

Les six activités d'hébergement, et pourquoi le certificat en liste certaines

L'article R. 1111-9 découpe l'hébergement en six activités, numérotées de 1° à 6°. Un hébergeur est certifié pour tout ou partie d'entre elles, et c'est le point que les clients lisent le moins : le certificat mentionne son périmètre sous la forme d'une liste d'activités, et l'organisme de certification remonte ce périmètre chaque mois à l'Agence du numérique en santé pour la liste publique des hébergeurs certifiés. Deux prestataires "certifiés HDS" peuvent donc couvrir des choses très différentes.

Le référentiel de certification v2.0 redéfinit l'activité 5 comme la maîtrise des interventions sur les ressources du client : attribution et revue annuelle de droits nominatifs, sécurisation de la procédure d'accès, conservation des traces, validation préalable des interventions. Ces tâches sont considérées comme intrinsèques aux activités 1 à 4, si bien qu'un hébergeur qui ne les réalise qu'en accompagnement de ces activités n'a pas à être certifié pour la 5 en tant que telle ; il ne l'est que s'il n'exerce que celle-là. L'activité 6, de son côté, ne vise que les sauvegardes externalisées ; celles que les activités 1 à 5 impliquent de toute façon leur restent rattachées.

Le vocabulaire "hébergeur d'infrastructure physique" pour les activités 1 et 2 et "hébergeur infogéreur" pour les activités 3 à 6 est hérité du dispositif de 2018, et on le croise encore dans la plupart des plaquettes. Il reste un raccourci commode, à condition de vérifier derrière la liste d'activités effectivement portée par le certificat, car c'est elle qui fait foi.

Le socle : ISO 27001 plus 31 exigences

La première exigence du référentiel dit tout de sa structure. Pour être certifié, un hébergeur doit avoir mis en oeuvre un système de management de la sécurité de l'information certifié selon ISO 27001, dont le domaine d'application couvre l'ensemble de ses activités d'hébergement de données de santé, complété par les exigences propres au référentiel. Autrement dit, HDS est une surcouche. Le référentiel v2.0 s'appuie explicitement sur NF ISO/IEC 27001:2023, l'édition française de la version 2022 de la norme, et compte 31 exigencesnumérotées EXI 01 à EXI 31, réparties en quatre blocs : les compléments au SMSI, les clauses contractuelles imposées par l'article R. 1111-11, la souveraineté des données, et la représentation des garanties que l'hébergeur doit communiquer à ses clients.

Si vous voulez comprendre ce que coûte et ce que prouve la brique du dessous, la certification ISO 27001, son cycle et ses preuves techniques sont détaillés ailleurs sur ce blog. Retenez pour HDS que le référentiel d'accréditation autorise un candidat déjà certifié ISO 27001 à faire prévaloir cette certification, sous conditions : périmètre incluant celui demandé pour HDS, rapports d'audit fournis sur demande, déclaration d'applicabilité justifiant chaque exclusion, certificat délivré par un organisme accrédité. Le candidat est alors évalué sur les seules exigences que son ISO 27001 ne couvre pas.

Le référentiel révisé de 2024 : localisation EEE et transparence

Le référentiel de 2018 a été remplacé par l'arrêté du 26 avril 2024, publié au Journal officiel du 16 mai 2024 après un avis de la CNIL du 13 juillet 2023. Il approuve à la fois le référentiel d'accréditation des organismes de certification et le référentiel de certification, tous deux en version 2.0, et prévoit que les nouvelles dispositions entrent en vigueur six mois après sa publication pour les demandes de certificat et de renouvellement, soit à partir du 16 novembre 2024. L'Agence du numérique en santé a communiqué sur une période de transition de 24 mois pour les hébergeurs déjà certifiés, jusqu'au 16 mai 2026 ; ce délai ne figure pas dans le corps de l'arrêté lui-même.

Le chapitre 7, "souveraineté des données", est la vraie nouveauté. Il faut le lire pour ce qu'il dit et pas pour ce qu'on en vend :

• EXI 28, stockage dans l'EEE : dès qu'une activité implique un stockage de données de santé, l'hébergeur et ses sous-traitants les stockent exclusivement au sein de l'Espace économique européen, et documentent cette localisation au client.
• EXI 29, accès à distance depuis un pays tiers : il n'est pas interdit. Il doit reposer sur une décision d'adéquation de l'article 45 du RGPD ou, à défaut, sur une garantie appropriée de l'article 46, avec information du client et prise en compte des recommandations 01/2020 du Comité européen de la protection des données.
• EXI 30, lois extra-européennes : si l'hébergeur ou un sous-traitant est soumis à la législation d'un pays tiers non adéquat, le contrat liste ces lois, les mesures d'atténuation et les risques résiduels d'accès non autorisé. C'est une obligation de déclaration, pas d'immunité.
• EXI 31, cartographie publique : l'hébergeur publie sur une page web dédiée la cartographie de ses transferts hors EEE et des risques déclarés. Seul un hébergeur qui bénéficie en plus d'une qualification SecNumCloud 3.2 peut afficher "aucun risque d'accès imposé par la législation d'un pays tiers".

Cette dernière mention règle une confusion fréquente. HDS v2.0 impose la localisation du stockage, pas l'immunité juridique, et le référentiel annonce lui-même que des exigences renforcées de souveraineté suivront au plus tard en 2027, en cohérence avec le futur schéma européen EUCS. Ce que la qualification SecNumCloud garantit en matière de droit extra-européen reste donc, à ce jour, le seul niveau au-dessus. Et la réglementation a bougé une nouvelle fois depuis : le décret n° 2026-209 du 24 mars 2026 a complété le 6° de l'article R. 1111-9, où la sauvegarde inclut désormais expressément la conservation dans le cadre d'un archivage électronique, et créé un article R. 1111-9-1 qui inscrit dans le code lui-même le stockage exclusif sur le territoire d'un État membre de l'Union ou de l'EEE, avec une entrée en vigueur au 26 septembre 2026. Une exigence de référentiel est devenue une règle du code.

Le cycle de certification : COFRAC, trois ans, surveillance annuelle

L'article R. 1111-10 fixe la mécanique. Le certificat est délivré par un organisme de certification, sur la base d'un référentiel élaboré par l'Agence du numérique en santé et approuvé par arrêté après avis de la CNIL. L'organisme doit être accrédité par le Comité français d'accréditation, le COFRAC, ou par tout autre organisme d'accréditation signataire d'un accord de reconnaissance mutuelle multilatéral pris dans le cadre de la coordination européenne des organismes d'accréditation. Le référentiel d'accréditation formule la même chose en visant les instances nationales définies par le règlement (CE) n° 765/2008. Le référentiel d'accréditation calque le processus sur la norme NF EN ISO/IEC 17021-1, celle qui régit déjà les certifications de systèmes de management : un organisme déjà accrédité pour ISO 27001 demande une extension de portée, un nouvel entrant part de zéro.

Deux détails du référentiel d'accréditation disent l'esprit du dispositif. Le certificat HDS porte une mention explicite indiquant qu'il n'est valable que sous condition d'une certification ISO 27001 valide pour le même périmètre, et une non-conformité ISO relevée pendant un audit HDS est transmise à l'organisme qui a délivré l'ISO 27001. Ensuite, avant toute intervention, l'organisme de certification doit s'assurer avec le candidat qu'aucune donnée de santé ne lui sera communiquée pendant l'audit. L'auditeur HDS ne regarde pas vos données, et il ne regarde pas non plus votre application. Il audite un système de management.

Ce que la certification HDS ne couvre pas

Reprenez la pile plus haut. Le certificat s'arrête à la plateforme d'hébergement et à son exploitation. Au-dessus, trois couches restent entièrement à votre charge, et ce sont elles qu'un attaquant regarde en premier.

L'application et son code

Un portail patient, un logiciel de gestion de cabinet, une plateforme de télé-expertise sont des applications web. Elles ont des injections SQL, des contrôles d'accès cassés entre deux dossiers patients, des dépendances vulnérables, des uploads de documents mal filtrés. Rien dans les 31 exigences ne demande à l'hébergeur de les tester, et pour cause : ce n'est pas son code. Le référentiel prévoit même l'inverse, dans son exigence EXI 15 : quand l'hébergeur met à disposition des ressources spécifiques à un client, ce client peut réaliser ou mandater des audits de sécurité technique sur ces ressources, et l'hébergeur l'assiste. Le texte vous donne la main. Un pentest web en boîte blanche, code et environnement de déploiement sous les yeux, est la manière la plus directe de l'utiliser.

Les comptes et les accès

L'activité 5 encadre les droits d'accès des opérateurs de l'hébergeur. Elle ne dit rien des comptes de vos secrétaires médicales, de vos praticiens, de vos prestataires de maintenance applicative, ni du compte partagé qui traîne depuis la migration. Les cas rassemblés dans l'article sur les cyberattaques d'hôpitaux documentées en France ont tous commencé par un accès légitime, joignable depuis internet, protégé par un mot de passe seul.

La surface exposée

Le certificat porte sur un périmètre déclaré. Il ignore par construction ce qui n'a pas été déclaré : l'environnement de recette accessible sans authentification, le sous-domaine oublié qui pointe encore vers une instance décommissionnée, le bucket de stockage ouvert par un prestataire, l'interface d'administration exposée sur un port non standard. Cette surface d'attaque se cartographie de l'extérieur, avec le regard de l'attaquant, et personne d'autre que le responsable de traitement n'a intérêt à le faire.

HDS, NIS2 et la gouvernance qui relie les deux

La santé figure à l'annexe I de la directive (UE) 2022/2555, celle des secteurs hautement critiques, avec les prestataires de soins, les laboratoires de référence de l'Union, les entités de recherche et développement de médicaments et les fabricants de dispositifs médicaux critiques. La directive devait être transposée pour le 17 octobre 2024. En septembre 2026, soit près de deux ans après cette échéance, le dossier législatif du Sénat consacré au projet de loi de résilience des infrastructures critiques et de renforcement de la cybersécurité, mis à jour le 17 mars 2026, n'affiche aucune étape postérieure au dépôt du texte de la commission spéciale de l'Assemblée nationale, le 10 septembre 2025. La loi de transposition n'est donc pas promulguée à cette date et le régime français n'est pas applicable ; il faut lire tout calendrier avec cette réserve, et vérifier l'état du texte au moment où vous lisez. Le détail des obligations est dans l'article consacré à la directive NIS2, ses entités et son calendrier.

Le lien avec HDS tient à l'article 21, paragraphe 2, point d) de la directive : la sécurité de la chaîne d'approvisionnement, y compris les relations avec les fournisseurs directs. Pour un établissement de santé, l'hébergeur de son dossier patient est le premier de ces fournisseurs, et le certificat HDS est la pièce contractuelle qu'on lui demandera. Mais un certificat ne remplace pas une gestion des risques fournisseurs, et c'est ce que développe l'article sur le TPRM et ce que NIS2 et DORA exigent de vos fournisseurs. La question qui compte n'est pas "l'hébergeur a-t-il le logo", mais "quelles activités couvre son certificat, quelles ressources me sont spécifiques, et qu'ai-je testé moi-même sur ce qu'il ne couvre pas".

C'est le genre d'arbitrage que la gouvernance, gestion des risques et conformité en cybersécurité est censée organiser : distinguer ce qu'un tiers atteste, ce que vous devez vérifier vous-même, et ce qui doit être prouvé par un test plutôt que par un document. La certification HDS est une bonne illustration de la règle, parce que son périmètre est écrit noir sur blanc et que la tentation de le lire plus large est permanente.

À retenir

• La certification HDS est obligatoire pour qui héberge sur support numérique des données de santé à caractère personnel pour le compte d'un tiers (art. L. 1111-8 CSP). Héberger ses propres données pour son propre compte est hors champ. Sans certificat : trois ans de prison et 45 000 euros d'amende (art. L. 1115-1).
• Six activités (art. R. 1111-9) : sites physiques, matériel, infrastructure virtuelle, plateforme applicative, administration et exploitation, sauvegarde. Le certificat en liste une partie ou la totalité : lisez la liste avant le logo.
• Le socle est un SMSI certifié ISO 27001, complété par 31 exigences (référentiel v2.0, arrêté du 26 avril 2024). Certificat de trois ans, surveillance annuelle, organisme accrédité COFRAC selon ISO/IEC 17021-1.
• La révision 2024 impose le stockage dans l'EEE et la transparence sur les lois extra-européennes, sans immunité juridique ; le décret n° 2026-209 inscrit la localisation dans le code au 26 septembre 2026.
• Le certificat s'arrête à la plateforme et à son exploitation. L'application, ses comptes utilisateurs et sa surface exposée restent à votre charge, et l'exigence EXI 15 vous donne le droit de les auditer.

Votre hébergeur est certifié, votre dossier HDS est en ordre, et le portail que vous avez déployé chez lui n'a jamais été attaqué par quelqu'un qui vous en rende compte. Monter ce dossier ou préparer le SMSI qui va avec ne relève pas d'own2pwn, qui n'est ni hébergeur, ni organisme de certification. La couche du dessus, en revanche, se teste, en pentest web en boîte blanche avec le code et l'environnement de déploiement, ou en boîte noire depuis internet, avec un rapport daté que votre DPO et votre auditeur peuvent verser au dossier. Une réponse arrive sous 24 heures via la page contact.

Questions fréquentes sur la certification HDS