HDS en 2026 : référentiel v2, décret du 24 mars, ce que les éditeurs doivent vérifier

Si vous éditez un logiciel qui traite des données de santé, 2026 vous impose deux vérifications, pas une. La première est derrière vous et beaucoup l'ont manquée : depuis le 16 mai 2026, un certificat HDS délivré sous l'ancien référentiel ne vaut plus rien. La seconde arrive : le décret n° 2026-209 du 24 mars 2026 inscrit dans le code de la santé publique l'obligation de stocker les données de santé dans l'Espace économique européen, et ses dispositions les plus contraignantes s'appliquent six mois après sa publication, donc à partir de fin septembre 2026.

Ces deux échéances ne concernent pas seulement les hébergeurs. Elles changent le contenu de votre contrat d'hébergement, la liste des pièces que vous devez pouvoir produire en cas de contrôle, et parfois la configuration de vos déploiements cloud.

Ce guide fait le point sur ce qui a changé, ce que la certification de votre hébergeur ne couvre pas, et les vérifications à mener maintenant.

Ce qui a changé le 16 mai 2026

Le référentiel de certification HDS a été révisé et approuvé par l'arrêté du 26 avril 2024. Cette version 2.0 s'applique aux nouvelles certifications depuis fin 2024, et les hébergeurs déjà certifiés sous l'ancien référentiel de 2018 (v1.1) avaient jusqu'au 16 mai 2026 pour basculer.

Depuis cette date, seuls les prestataires conformes au référentiel v2.0 peuvent exercer une activité d'hébergement de données de santé. Concrètement, cela veut dire que la mention « certifié HDS » dans une plaquette commerciale ne suffit plus : il faut regarder la version du référentiel sur le certificat, et ses dates de délivrance et de renouvellement.

C'est la première vérification à faire, et elle prend cinq minutes : demandez le certificat, pas une capture d'écran de logo.

La fin de la distinction infrastructure physique / infogéreur

Le changement de structure le plus important de la v2 est passé sous les radars. L'ancien référentiel séparait deux blocs de certification : hébergeur d'infrastructure physique d'un côté, hébergeur infogéreur de l'autre. Cette distinction a été supprimée dans la version 2.0.

Les six activités du décret de 2018 restent la base du périmètre :

1. Mise à disposition et maintien en condition opérationnelle de sites physiques (datacenters)
2. Mise à disposition et maintien en condition opérationnelle de l'infrastructure matérielle
3. Mise à disposition et maintien en condition opérationnelle de l'infrastructure virtuelle
4. Mise à disposition et maintien en condition opérationnelle de la plateforme d'hébergement d'applications
5. Administration et exploitation du système d'information contenant les données de santé
6. Sauvegarde externalisée des données de santé

Ce qui change est la lecture : au lieu de se demander dans quelle catégorie tombe un prestataire, on lit quelles activités son certificat couvre, une par une. Un hébergeur peut être certifié sur les activités 1 à 4 et pas sur l'activité 5. Si vous lui confiez l'exploitation de votre système, cette activité n'est alors pas couverte, et l'écart est le vôtre.

L'activité 5 a d'ailleurs été précisée dans la v2, avec des exigences détaillées de contrôle des accès. C'est logique : c'est l'activité où quelqu'un a techniquement les moyens de lire vos données.

Le décret du 24 mars 2026 : le stockage dans l'EEE devient une obligation du code de la santé publique

Jusqu'ici, la localisation des données relevait surtout du référentiel de certification. Le décret n° 2026-209 du 24 mars 2026 la fait passer dans le code de la santé publique, en modifiant les articles R. 1111-9 à R. 1111-11 et en créant un article R. 1111-9-1.

Ce que dit le nouvel article R. 1111-9-1

Le stockage des données de santé à caractère personnel doit être réalisé exclusivement sur le territoire d'un État membre de l'Union européenne ou partie à l'accord sur l'Espace économique européen.

Attention à la nuance, souvent mal rapportée : le texte n'interdit pas tout transfert hors EEE de façon absolue. Un transfert reste possible si la Commission européenne a constaté un niveau de protection adéquat au sens de l'article 45 du RGPD, ou si des garanties appropriées au sens de l'article 46 sont mises en place, avec des recours effectifs pour les personnes concernées. En revanche, le contrat d'hébergement doit alors mentionner l'absence de décision d'adéquation et décrire précisément les mesures de protection retenues.

Autrement dit, ce n'est pas un interdit, c'est une obligation de transparence adossée à une obligation de localisation du stockage. Ce qui disparaît, c'est la zone grise.

Ce que le décret ajoute au contenu du contrat

L'article R. 1111-11, qui liste ce que le contrat d'hébergement doit prévoir, a été nettement enrichi :

• Les droits des personnes ne se limitent plus à la portabilité : accès, rectification, effacement et opposition au sens des articles 15 à 21 du RGPD.
• Le contrat doit exposer les transferts vers des pays tiers et les accès distants depuis l'extérieur de l'EEE.
• Il doit indiquer les législations de pays tiers susceptibles de permettre un accès aux données, l'existence ou non d'une décision d'adéquation, et les risques résiduels.
• Il doit s'accompagner d'une cartographie publique des transferts et des risques d'accès non autorisé.

Le calendrier

Le décret est entré en vigueur le lendemain de sa publication, à l'exception des points 2° et 3° de son article 1er, c'est-à-dire précisément le nouvel article R. 1111-9-1 sur la localisation et l'enrichissement du contenu du contrat. Ces deux points sont différés de six mois, donc applicables à partir de fin septembre 2026.

Si votre contrat d'hébergement date d'avant 2026, il y a peu de chances qu'il contienne la cartographie des transferts et le détail des législations extra-européennes applicables. C'est le moment de le faire évoluer, pas en octobre.

Ce que la certification de votre hébergeur ne couvre pas

C'est le malentendu le plus fréquent chez les éditeurs e-santé, et il coûte cher en audit client : « mon hébergeur est certifié HDS » ne signifie pas « je suis conforme ».

Trois raisons.

La responsabilité du traitement reste la vôtre (ou celle de votre client). La certification HDS porte sur les activités d'hébergement. Elle ne dit rien de la licéité de votre traitement, de votre base légale, de votre analyse d'impact, de votre gestion des habilitations applicatives ni de votre politique de conservation. Ces sujets relèvent du RGPD et restent entiers, comme nous le détaillons dans notre guide RGPD et données de santé pour les éditeurs de logiciels.

Le périmètre du certificat peut ne pas couvrir ce que vous faites faire. Si vous administrez vous-même le système d'information qui contient les données de santé pour le compte de vos clients, vous exercez une activité que le référentiel décrit, la cinquième. La question de savoir si votre propre structure doit être certifiée se pose alors sérieusement, et elle se tranche au cas par cas selon qui est responsable de traitement et ce que prévoient vos contrats. Beaucoup d'éditeurs SaaS e-santé sont certifiés HDS pour cette raison précise, et pas par coquetterie commerciale.

La chaîne de sous-traitance doit être visible. La v2 impose à l'hébergeur de communiquer les certificats HDS de ses sous-traitants participant aux activités d'hébergement. Un hébergeur qui s'appuie sur un tiers pour la sauvegarde ou l'exploitation doit pouvoir le montrer. Si personne ne vous a jamais transmis ces pièces, vous n'avez pas la chaîne complète.

La checklist à passer maintenant

Huit vérifications, dans cet ordre.

1. Le certificat HDS de votre hébergeur, en version 2.0 du référentiel, avec ses dates de délivrance et de renouvellement. Pas le logo, le document.
2. Le périmètre du certificat, activité par activité, comparé à ce que vous lui confiez réellement. L'écart le plus fréquent porte sur l'activité 5, l'administration et l'exploitation.
3. Les certificats des sous-traitants qui participent à l'hébergement.
4. Le tableau de garanties que l'hébergeur doit fournir, où figurent notamment son statut au regard de SecNumCloud, les risques d'accès par des autorités de pays tiers et les législations extra-européennes applicables.
5. La localisation réelle du stockage, région par région, service par service. Un compte cloud mal configuré peut répliquer des données hors EEE sans que personne ne l'ait décidé.
6. Les accès distants depuis l'extérieur de l'EEE, en particulier le support technique et l'astreinte. C'est le point que les éditeurs oublient le plus souvent, alors qu'il doit désormais figurer au contrat.
7. La clause de réversibilité, avec les coûts et les délais de restitution des copies de données. Une clause de réversibilité sans chiffres ne vous sert à rien le jour où vous en avez besoin.
8. La cartographie des transferts et des risques d'accès non autorisé, que le décret rend publique.

Si vous ne pouvez pas produire les points 1 à 4 en une journée, votre dossier de conformité n'est pas prêt pour un audit client, et encore moins pour un marché public de santé où ces pièces sont demandées à l'appui de la candidature.

Le cas des hyperscalers : AWS, Azure, Google Cloud

Les trois grands fournisseurs américains disposent de régions françaises certifiées, et beaucoup de startups e-santé y déploient sans difficulté. Deux points de vigilance, renforcés par le décret.

La configuration ne se déduit pas de la certification. Certains services peuvent, par défaut, traiter ou répliquer des données en dehors de la région choisie. Restreindre explicitement les régions autorisées au niveau de l'organisation, chiffrer avec des clés que vous maîtrisez et auditer la configuration en continu ne sont pas des raffinements, ce sont les conditions pour que la localisation annoncée soit vraie.

L'exposition aux législations extra-européennes doit être écrite. Une entreprise de droit américain reste soumise à son droit national, indépendamment de la localisation physique des serveurs. Ce n'est pas rédhibitoire en soi, le décret prévoit d'ailleurs le cas, mais cela doit apparaître dans le contrat, avec les mesures de protection et les risques résiduels. Pour les projets destinés à des établissements publics, c'est souvent le critère qui tranche le choix de l'hébergeur.

Pour le choix lui-même, les prix et les gammes de services, voir notre comparatif des hébergeurs HDS en France.

Questions fréquentes

Mon hébergeur est certifié HDS, suis-je conforme ?

Non. Sa certification couvre ses activités d'hébergement, dans le périmètre listé sur son certificat. Votre conformité au RGPD, vos habilitations applicatives, votre durée de conservation, votre analyse d'impact et le contenu de votre contrat d'hébergement restent votre affaire. La certification est une condition, pas une preuve.

Un éditeur de logiciel doit-il être certifié HDS ?

Cela dépend de ce qu'il fait. S'il se contente de développer et de fournir un logiciel déployé chez un hébergeur certifié, la certification n'a pas d'objet pour lui. S'il héberge les données pour le compte de ses clients ou s'il administre et exploite le système d'information qui les contient, il exerce une des six activités du référentiel et la question se pose vraiment. C'est un arbitrage juridique qui dépend de qui est responsable de traitement et de la rédaction des contrats.

Que faire si mon hébergeur n'est pas certifié sur le référentiel v2 ?

Depuis le 16 mai 2026, il ne peut plus exercer l'activité d'hébergement de données de santé. Demandez-lui son certificat et son échéance. En cas de doute, la liste des hébergeurs certifiés est publiée par l'Agence du numérique en santé. Si le certificat n'est pas à jour, la migration est une opération à planifier tôt, et c'est exactement le moment où une clause de réversibilité chiffrée montre son utilité.

Le décret interdit-il totalement les transferts hors Union européenne ?

Non. Il impose que le stockage soit réalisé dans l'EEE, et encadre les transferts : ils restent possibles sous décision d'adéquation de la Commission européenne ou sous garanties appropriées au sens de l'article 46 du RGPD, avec des recours effectifs. Ce qui devient obligatoire, c'est de déclarer ces transferts, les législations de pays tiers applicables et les risques résiduels dans le contrat.

À partir de quand ces obligations s'appliquent-elles ?

La bascule vers le référentiel v2 est effective depuis le 16 mai 2026. Les dispositions du décret du 24 mars 2026 sur la localisation du stockage et sur le contenu du contrat s'appliquent six mois après sa publication, donc à partir de fin septembre 2026. Le reste du décret est en vigueur depuis mars.

Faut-il un hébergeur SecNumCloud plutôt que HDS ?

Ce sont deux visas différents. HDS est obligatoire pour héberger des données de santé. SecNumCloud est un visa de sécurité délivré par l'ANSSI, plus exigeant sur la protection contre les législations extra-européennes, et souvent demandé dans les projets publics sensibles. Certains hébergeurs cumulent les deux. Le tableau de garanties de votre hébergeur doit indiquer où il en est.

En résumé

• Depuis le 16 mai 2026, seuls les hébergeurs conformes au référentiel HDS v2.0 (arrêté du 26 avril 2024) peuvent héberger des données de santé.
• La v2 supprime la distinction entre hébergeur d'infrastructure physique et hébergeur infogéreur : on lit désormais le périmètre activité par activité sur le certificat.
• Le décret n° 2026-209 du 24 mars 2026 crée l'article R. 1111-9-1 du code de la santé publique : stockage dans l'EEE, transferts encadrés, et un contenu de contrat nettement enrichi. Applicable à partir de fin septembre 2026 pour ces deux volets.
• « Mon hébergeur est certifié HDS » ne vaut pas conformité : le traitement, le périmètre réel et la chaîne de sous-traitance restent à démontrer.
• Huit pièces à réunir : certificat v2, périmètre par activité, certificats des sous-traitants, tableau de garanties, localisation du stockage, accès distants hors EEE, réversibilité chiffrée, cartographie des transferts.

Vous préparez un audit client, une réponse à un marché public ou une mise à jour de contrat d'hébergement avant fin septembre ? Nous accompagnons les éditeurs et les établissements sur ces sujets depuis des projets menés avec l'AP-HP et des startups e-santé : voir notre accompagnement HDS et notre page données de santé. Un appel de 30 minutes suffit à savoir où sont vos écarts, prenons-le.