Donneespersonnelles.fr

Plateforme de veille en conformite numerique

Mardi 21 juillet 2026
RGPD

Hébergement de données de santé (HDS) : le guide 2026

Certification HDS : nouveau référentiel v2, souveraineté EEE, contrat, articulation RGPD. Qui est concerné et comment se mettre en conformité en 2026.

Depuis le 16 mai 2026, tout hébergeur de données de santé certifié doit l’être selon le nouveau référentiel HDS v2, publié au Journal officiel le 16 mai 2024. La règle qui fait le plus de bruit : les données de santé doivent désormais être physiquement hébergées dans un pays de l’Espace économique européen. Dans les audits que je mène auprès d’éditeurs de logiciels de santé et de structures de soins, la certification HDS reste la zone la plus mal comprise du dossier de conformité — souvent confondue avec le RGPD, parfois ignorée par des acteurs qui y sont pourtant soumis. Voici ce qu’il faut comprendre, et ce qu’il faut vérifier concrètement.

Ce qu’est réellement la certification HDS

L’hébergement de données de santé à caractère personnel est encadré par l’article L.1111-8 du Code de la santé publique (CSP). Le principe est simple : toute personne qui héberge des données de santé pour le compte d’un tiers — un professionnel de santé, un établissement, un patient — doit être titulaire d’un certificat de conformité délivré par un organisme certificateur accrédité. La certification a remplacé l’ancien régime d’agrément depuis 2018.

Il ne s’agit pas d’un label marketing. C’est une obligation légale dont le non-respect expose l’hébergeur à des sanctions pénales prévues par le CSP, et le responsable de traitement qui confie ses données à un hébergeur non certifié à un manquement à son obligation de sécurité au sens de l’Art. 32 du RGPD.

La certification repose sur un référentiel technique. Depuis mai 2024, ce référentiel est aligné sur la norme ISO/IEC 27001 dans sa version 2022, ce qui rapproche la démarche HDS des standards internationaux de sécurité de l’information tout en y ajoutant des exigences propres au secteur de la santé.

Les deux certificats et les six activités

La certification HDS ne couvre pas un « service » unique. Elle se décline en six activités d’hébergement, réparties en deux certificats distincts.

Le certificat « hébergeur d’infrastructure physique » couvre la mise à disposition et le maintien en condition opérationnelle des sites physiques (data centers) et de l’infrastructure matérielle (serveurs). C’est le métier des exploitants de centres de données.

Le certificat « hébergeur infogéreur » couvre la mise à disposition de l’infrastructure virtuelle, de la plateforme logicielle, l’administration et l’exploitation du système d’information contenant les données de santé, ainsi que la sauvegarde externalisée. C’est le périmètre des éditeurs SaaS, des infogéreurs et des opérateurs cloud qui exploitent la donnée.

Un même prestataire peut détenir les deux certificats, ou un seul. Le point de vigilance pour vous, en tant que client : vérifier que le certificat de votre hébergeur couvre effectivement les activités qu’il réalise pour vous. Un hébergeur certifié uniquement pour l’infrastructure physique ne couvre pas l’infogérance applicative que vous lui confiez.

Qui est concerné — et qui ne l’est pas

C’est la question qui provoque le plus d’erreurs de qualification. Trois conditions cumulatives déclenchent l’obligation HDS.

Il faut d’abord des données de santé à caractère personnel. La notion est large : au-delà des diagnostics et traitements, elle englobe toute donnée révélant l’état de santé d’une personne, y compris déduit. Ces données relèvent des catégories particulières de l’Art. 9 du RGPD, dont le traitement est interdit par principe sauf exception.

Il faut ensuite que ces données soient collectées à l’occasion d’activités de prévention, de diagnostic, de soins ou de suivi médico-social. Une donnée de santé collectée dans un tout autre contexte (assurance, ressources humaines) ne relève pas nécessairement du régime HDS, même si elle reste soumise au RGPD.

Il faut enfin que l’hébergement soit réalisé pour le compte d’un tiers. C’est le critère décisif. Une structure qui héberge elle-même, sur ses propres serveurs, les données qu’elle a collectées — ce qu’on appelle l’hébergement « pour soi-même » — n’est pas soumise à la certification HDS. Un hôpital qui gère son propre datacenter interne n’a pas à se faire certifier pour ses propres données. En revanche, dès qu’il externalise vers un prestataire, ce prestataire doit être certifié.

Concrètement, sont soumis à HDS : les hébergeurs cloud, les éditeurs de logiciels métier de santé en mode SaaS (dossier patient informatisé, logiciel de gestion d’officine, plateformes de télémédecine), les infogéreurs et les prestataires de sauvegarde externalisée. Ne le sont pas : les responsables de traitement qui hébergent leurs propres données en interne, ni les hébergeurs de données de santé anonymisées (qui ne sont plus des données personnelles).

Le grand changement 2024-2026 : la souveraineté

L’évolution la plus structurante du référentiel v2 concerne la localisation des données. Là où la version précédente restait silencieuse, le nouveau référentiel impose que les données de santé soient physiquement hébergées dans un pays de l’Espace économique européen — l’Union européenne, plus la Norvège, l’Islande et le Liechtenstein.

Cette exigence de localisation ne règle pas à elle seule la question de l’exposition aux droits extra-européens. Le référentiel prévoit donc un second niveau d’exigence : en cas d’accès distant aux données depuis un pays tiers à l’UE — par l’hébergeur lui-même ou l’un de ses sous-traitants — ou lorsque l’hébergeur est soumis à une législation extra-européenne qui ne garantit pas un niveau de protection adéquat au sens de l’Art. 45 du RGPD, l’hébergeur doit informer son client dans le contrat. Il doit préciser les risques associés et détailler les mesures techniques et juridiques mises en œuvre pour les limiter.

C’est un point d’attention majeur pour tout responsable de traitement qui recourt à un hyperscaler américain, même lorsque les serveurs sont situés en Europe. La localisation physique en EEE ne neutralise pas, à elle seule, l’exposition à une législation comme le CLOUD Act. Cette articulation rejoint directement la problématique des transferts de données hors UE, qu’il faut analyser en parallèle de la certification.

Le référentiel v2 a été élaboré en concertation avec l’ensemble des parties prenantes — fédérations d’établissements de santé, industriels, organismes certificateurs, DGE, ANSSI, CNIL et Commission européenne. La dimension souveraineté n’est donc pas un ajout isolé, mais le résultat d’un arbitrage assumé au niveau interministériel.

Analyse de risque : huit scénarios imposés

Autre nouveauté concrète : le référentiel v2 encadre l’analyse de risque prévue au chapitre 6.1.2 de l’ISO 27001 en imposant huit événements redoutés prédéfinis que l’hébergeur doit obligatoirement intégrer à son analyse. Fini l’analyse de risque à géométrie variable où chaque hébergeur choisissait ses propres scénarios : le référentiel fixe un socle commun (accès illégitime, altération, perte de disponibilité des données, etc.), ce qui permet de comparer les hébergeurs sur une base homogène.

La clause de réversibilité devient obligatoire

L’exigence 27 du référentiel v2 impose que le contrat contienne une clause de réversibilité. Cette clause doit prévoir les modalités de calcul des coûts et des délais de restitution des données, et le cas échéant les modalités de déplacement des machines virtuelles ou conteneurs. Pour le client, c’est une garantie précieuse : la fin du contrat ne doit pas se transformer en prise d’otage de vos données de santé. Vérifiez systématiquement que cette clause figure au contrat et qu’elle est chiffrée, pas seulement mentionnée par principe.

Articuler HDS et RGPD : deux régimes, un seul dossier

L’erreur la plus répandue consiste à traiter HDS et RGPD comme deux sujets étanches. Ils se superposent, et c’est le responsable de traitement qui doit assurer la cohérence de l’ensemble.

L’hébergeur HDS est, dans l’immense majorité des cas, un sous-traitant au sens de l’Art. 28 du RGPD. La certification HDS ne dispense donc jamais de conclure un contrat de sous-traitance conforme à l’Art. 28(3) : finalités, durée, obligations de sécurité, sort des données en fin de contrat, encadrement de la sous-traitance ultérieure. En pratique, le contrat d’hébergement HDS et le contrat de sous-traitance RGPD sont souvent réunis dans un même document — à condition qu’il couvre bien les deux régimes.

Côté sécurité, la certification HDS constitue un élément de preuve solide de la mise en œuvre de mesures techniques et organisationnelles appropriées au sens de l’Art. 32. Mais elle ne couvre que le périmètre de l’hébergeur. Le responsable de traitement conserve la charge de sécuriser sa propre partie du système : postes de travail, gestion des habilitations, authentification, journalisation applicative.

Enfin, le recours à un hébergeur certifié ne modifie pas les obligations propres au responsable de traitement en cas d’incident : une violation de données de santé doit être notifiée à la CNIL dans les conditions de l’Art. 33 du RGPD, et une analyse d’impact au sens de l’Art. 35 reste en principe requise pour tout traitement de données de santé à grande échelle.

Le rappel des sanctions : l’affaire Dedalus

Le risque n’est pas théorique. En avril 2022, la CNIL a prononcé une sanction de 1,5 million d’euros à l’encontre de la société Dedalus Biologie (délibération SAN-2022-009), à la suite d’une fuite ayant exposé les données de santé de près de 500 000 personnes — pathologies, traitements, données génétiques. La sanction visait des manquements à l’Art. 28 (absence d’instructions documentées du responsable de traitement) et à l’Art. 32 (défaut de sécurité). Cette affaire illustre une réalité : dans le secteur de la santé, les défaillances de sous-traitance et de sécurité se paient au prix fort, et la certification HDS n’est que l’un des maillons d’une chaîne de conformité qui doit tenir de bout en bout.

Se mettre en conformité : la marche à suivre côté client

Si vous êtes responsable de traitement — établissement de santé, cabinet, éditeur qui confie l’hébergement à un tiers — voici la démarche concrète.

Commencez par cartographier vos flux de données de santé : quelles données, collectées dans quel contexte, hébergées où et par qui. Cette cartographie détermine si le régime HDS s’applique.

Vérifiez ensuite le certificat de chaque prestataire : sa validité, sa date, et surtout le périmètre d’activités couvert au regard de ce que le prestataire réalise réellement pour vous. Un certificat valable pour l’infrastructure physique ne suffit pas si le prestataire fait aussi de l’infogérance.

Examinez la localisation des données et les accès distants. Depuis le référentiel v2, exigez la confirmation d’un hébergement en EEE et, en cas d’accès depuis un pays tiers, l’information contractuelle sur les risques et les mesures. C’est ici que se joue l’essentiel de la souveraineté.

Revisitez enfin votre contrat : clauses Art. 28, clause de réversibilité chiffrée, engagement de localisation, encadrement de la sous-traitance ultérieure. C’est précisément ce travail de mise en cohérence contractuelle et documentaire — cartographie, registre, contrats de sous-traitance, suivi des certifications — que Legiscope permet de structurer et de tenir à jour sans repartir de zéro à chaque audit.

Cette démarche s’inscrit dans un dossier de conformité plus large, commun à tous les acteurs de santé — voir nos guides dédiés au RGPD en cabinet médical et au RGPD en pharmacie d’officine.

Ce qu’il faut retenir

  • HDS est une obligation légale (article L.1111-8 CSP), pas un label : héberger des données de santé pour le compte d’un tiers sans certification est sanctionnable, et confier ses données à un hébergeur non certifié constitue un manquement à l’Art. 32 du RGPD.
  • Le nouveau référentiel v2 (JO du 16 mai 2024) s’impose à tous les hébergeurs certifiés depuis le 16 mai 2026 ; il est aligné sur l’ISO/IEC 27001:2022.
  • Souveraineté : les données de santé doivent être physiquement hébergées dans l’EEE ; tout accès distant depuis un pays tiers doit être documenté dans le contrat avec ses risques et ses mesures.
  • HDS ne remplace pas le RGPD : l’hébergeur reste un sous-traitant Art. 28, le responsable de traitement conserve ses obligations de sécurité, d’AIPD et de notification de violation.
  • Côté client, vérifiez le périmètre exact du certificat, la localisation des données et la présence d’une clause de réversibilité chiffrée au contrat.

FAQ

La certification HDS est-elle obligatoire pour tous ?

Non. Elle s’impose uniquement à ceux qui hébergent des données de santé à caractère personnel pour le compte d’un tiers. Une structure qui héberge elle-même ses propres données sur ses propres infrastructures (hébergement « pour soi-même ») n’est pas soumise à la certification, mais reste tenue à ses obligations de sécurité au titre du RGPD.

Quelle est la différence entre HDS et RGPD ?

Le RGPD encadre le traitement des données personnelles de façon générale ; la certification HDS est une exigence sectorielle française, issue du Code de la santé publique, qui porte spécifiquement sur la sécurité de l’hébergement des données de santé. Les deux régimes se cumulent : un hébergeur HDS est presque toujours un sous-traitant au sens de l’Art. 28 du RGPD, avec lequel un contrat de sous-traitance conforme reste indispensable.

Un hébergeur américain peut-il être certifié HDS ?

Un prestataire peut être certifié HDS s’il héberge physiquement les données dans l’EEE et respecte le référentiel. En revanche, sa soumission à une législation extra-européenne (comme le CLOUD Act) impose, depuis le référentiel v2, d’informer le client dans le contrat des risques et des mesures prises. La localisation en Europe ne neutralise pas à elle seule l’exposition au droit américain : c’est un point à analyser au titre des transferts de données.

Que risque-t-on à confier ses données à un hébergeur non certifié ?

Le responsable de traitement s’expose à un manquement à son obligation de sécurité (Art. 32 du RGPD), susceptible d’une sanction de la CNIL, et l’hébergeur lui-même encourt les sanctions pénales prévues par le Code de la santé publique. L’affaire Dedalus (1,5 M€ en 2022) rappelle que les défaillances de sécurité et de sous-traitance dans le secteur de la santé sont lourdement sanctionnées.


Vous souhaitez suivre l’actualité de la conformité RGPD et de la protection des données de santé ? Recevez nos analyses chaque semaine — décryptages, décisions CNIL et guides pratiques, directement dans votre boîte mail.

Thiébaut Devergranne
Docteur en droit des nouvelles technologies (Paris II)

Docteur en droit, Thiébaut Devergranne travaille en droit des nouvelles technologies et en protection des données personnelles depuis plus de 20 ans. Il a accompagné des centaines d'organisations dans leur mise en conformité RGPD et est le fondateur de Legiscope, logiciel de conformité RGPD.

En savoir plus sur l'auteur →