En février 2026, plus d’un tiers des hébergeurs français certifiés n’avaient toujours pas basculé sur le nouveau référentiel de sécurité. Le chiffre surprend, car l’échéance était connue depuis 2024. Pour poser les bases, notre guide pour comprendre la certification d’hébergeur de données de santé reste un bon point de départ, mais la nouvelle version du référentiel HDS change plusieurs règles du jeu.
Ce retard n’est pas anodin. Depuis le 16 mai 2026, un hébergeur resté en version 1.1 ne peut plus héberger légalement des données de santé pour le compte de tiers. Selon une estimation de l’ANS, cette proportion atteignait 36 % du parc en février 2026. La migration est donc devenue un sujet de continuité d’activité, pas seulement de conformité administrative.
Ce que recouvre la certification HDS v2
La Certification HDS V2 est la version révisée du référentiel qui encadre l’hébergement des données de santé à caractère personnel en France. Elle remplace la version 1.1 en vigueur depuis 2018. Le principe de base ne change pas : toute entité qui héberge ou traite ces données pour le compte d’un tiers doit être certifiée.
La différence tient au niveau d’exigence. Le nouveau référentiel demande de prouver une résilience organisationnelle, pas seulement d’empiler des dispositifs techniques. Il précise aussi qui doit se faire certifier et sur quelles activités. Un datacenter, un fournisseur cloud et un éditeur de logiciel ne portent pas les mêmes obligations, même s’ils travaillent sur la même chaîne de traitement.
Cette clarification vise un objectif simple : rendre lisible la répartition des responsabilités. Quand une fuite touche un système d’information de santé, la question de savoir qui était responsable de quoi devient centrale. Le référentiel v2 répond en amont à cette question.
Le 16 mai 2026, la fin des certificats v1.1
Le calendrier est le point le plus concret pour les établissements. L’arrêté publié au Journal officiel le 16 mai 2024 a approuvé le référentiel révisé. Les hébergeurs déjà certifiés ont bénéficié d’un délai de transition de 24 mois. Cette période s’est achevée le 16 mai 2026.
Concrètement, deux dates structurent la bascule. D’abord, tout nouveau candidat à la certification applique le référentiel v2 depuis le 16 novembre 2024. Ensuite, les structures déjà certifiées devaient finaliser leur transition avant le 16 mai 2026. Vous pouvez retrouver le texte de référence et les exigences détaillées dans le référentiel publié par l’ANS.
Pour un établissement, l’enjeu se déplace vers ses prestataires. Si votre hébergeur ou votre éditeur est resté en v1.1, votre chaîne de traitement n’est plus conforme. Le risque juridique rejoint alors le risque technique. Pour sécuriser cette relation de confiance, notre dossier sur la confiance apportée par la certification HDS détaille les garanties à exiger.
Les six activités couvertes par le référentiel
La certification ne fonctionne pas en bloc. Elle se décompose en six activités distinctes. Un prestataire peut être certifié sur une seule, plusieurs, ou l’ensemble. Comprendre ce découpage vous évite de mauvaises surprises lors du choix d’un partenaire.
- Mise à disposition de sites physiques hébergeant l’infrastructure matérielle.
- Mise à disposition de l’infrastructure matérielle du système d’information.
- Mise à disposition de l’infrastructure virtuelle.
- Mise à disposition de la plateforme d’hébergement d’applications.
- Administration et exploitation du système d’information contenant les données de santé.
- Sauvegarde externalisée des données de santé.
Les activités 1 à 4 concernent surtout les hébergeurs d’infrastructure et les fournisseurs cloud. Les activités 5 et 6 visent davantage les éditeurs de logiciels et les prestataires d’exploitation. L’activité 5 est celle qui piège le plus souvent. Dès qu’un technicien accède à un environnement contenant des données de santé pour du support ou de la maintenance, il exerce cette activité, soumise à certification.
Ce que change la version 2 du référentiel
Trois évolutions ressortent. La première est l’alignement sur la norme ISO 27001:2022, qui modifie la façon d’évaluer les risques cyber et intègre des événements prédéfinis dans l’analyse. La deuxième est la souveraineté : l’hébergement physique des données doit se faire dans l’Espace économique européen, et les accès distants depuis un pays hors UE doivent être transparents.
La troisième évolution touche les contrats. Le référentiel v2 impose des clauses renforcées de sécurité, de traçabilité et de continuité. Selon une analyse juridique du cabinet Squire Patton Boggs, l’exigence 27 impose notamment une clause de réversibilité précisant les coûts et délais de restitution des données. Un décret du 24 mars 2026 complète ce dispositif sur la souveraineté et la transparence contractuelle.
Ces changements rejoignent une logique déjà connue des équipes sécurité : la conformité HDS s’appuie sur un système de management de la sécurité de l’information solide. Pour approfondir ce socle, notre analyse des critères ISO 27001 pour un hébergement souverain détaille les prérequis à couvrir.
Ce que change la version 2 du référentiel
Trois évolutions ressortent. La première est l’alignement sur la norme ISO 27001:2022, qui modifie la façon d’évaluer les risques cyber et intègre des événements prédéfinis dans l’analyse. La deuxième est la souveraineté : l’hébergement physique des données doit se faire dans l’Espace économique européen, et les accès distants depuis un pays hors UE doivent être transparents.
La troisième évolution touche les contrats. Le référentiel v2 impose des clauses renforcées de sécurité, de traçabilité et de continuité. Selon une analyse juridique du cabinet Squire Patton Boggs, l’exigence 27 impose notamment une clause de réversibilité précisant les coûts et délais de restitution des données. Un décret du 24 mars 2026 complète ce dispositif sur la souveraineté et la transparence contractuelle.
Ces changements rejoignent une logique déjà connue des équipes sécurité : la conformité HDS s’appuie sur un système de management de la sécurité de l’information solide. Pour approfondir ce socle, notre analyse des critères ISO 27001 pour un hébergement souverain détaille les prérequis à couvrir.
Hébergement pour compte propre ou pour un tiers
Une question revient sans cesse chez les DSI. Faut-il certifier ses propres serveurs ? Le cadre est clair : l’hébergement « pour son propre compte » n’est pas soumis à certification. Un cabinet ou un hôpital qui gère ses dossiers patients sur ses serveurs internes n’a pas cette obligation.
La certification s’impose dès que l’hébergement se fait pour le compte d’un tiers, pas quand une structure gère ses propres données en interne.
La réalité est plus nuancée. Dès qu’un éditeur tiers installe une solution sur vos serveurs et en assure la maintenance, il exerce une activité d’exploitation. Il doit alors être certifié sur les activités concernées. Un éditeur en mode SaaS n’a pas toujours besoin d’être lui-même certifié, à condition que son hébergeur le soit sur les bonnes activités et qu’un contrat encadre la relation.
Cette subtilité explique pourquoi la vérification du périmètre reste une étape indispensable. Ne vous contentez jamais d’un « nous sommes certifiés HDS » : demandez sur quelles activités précises porte le certificat.
Préparer et obtenir la certification
La démarche ressemble à un audit ISO classique, avec une couche santé supplémentaire. Elle passe par une phase de préparation, souvent un pré-audit, puis un audit sur site, une restitution, un passage en comité et la décision. Une fois obtenue, la certification dure trois ans avec un audit de surveillance annuel.
Le budget compte aussi. D’après un guide spécialisé de Legiscope, la certification coûte typiquement de 20 000 à 80 000 euros sur trois ans, selon le périmètre et la taille de la structure. La certification d’un système de management de la sécurité de l’information conforme à ISO 27001 en constitue le prérequis.
Pour beaucoup d’établissements, externaliser l’hébergement auprès d’un prestataire déjà certifié reste la voie la plus rapide. Cela transfère la charge de la conformité tout en gardant la maîtrise de vos données. Si vous cherchez une base conforme au référentiel v2, notre offre d’hébergement de données de santé HDS couvre ce besoin.
Ce qu’il faut retenir pour rester conforme
La version 2 du référentiel HDS n’est plus une échéance à venir : c’est le cadre applicable depuis le 16 mai 2026. L’action la plus utile aujourd’hui consiste à auditer le périmètre de certification de chacun de vos prestataires, en particulier sur l’activité 5. Vérifiez la localisation de vos données dans l’Espace économique européen et la présence des clauses contractuelles renforcées. Une chaîne de traitement conforme protège autant vos patients que la continuité de vos soins.
Passez à l’action avec gplexpert
Migrer vers le référentiel v2, vérifier le périmètre de vos éditeurs, aligner vos contrats sur les nouvelles clauses de souveraineté : ces chantiers demandent du temps et une expertise dédiée à la santé. C’est exactement le terrain sur lequel nous accompagnons les établissements de santé et leurs équipes DSI et SSI.
Nous hébergeons vos données de santé dans le respect du référentiel et du RGPD, avec l’infogérance et la supervision managée (SOC, NOC), l’audit de sécurité et les plans PSSI, PCA et PRA.
Pour sécuriser votre système d’information de santé sur une base conforme, découvrez nos services d’hébergement HDS et échangez avec nos équipes.
FAQ – HDS V2
Quelle est la différence entre HDS v1.1 et v2 ?
La version 2 s’aligne sur la norme ISO 27001:2022 et renforce les exigences de souveraineté des données. Elle impose l’hébergement physique dans l’Espace économique européen et clarifie mieux les six activités. Elle durcit aussi les clauses contractuelles entre hébergeurs et clients.
Depuis quand la version 2 est-elle obligatoire ?
Le référentiel v2 s’impose aux nouveaux candidats depuis le 16 novembre 2024. Les structures déjà certifiées devaient finaliser leur transition avant le 16 mai 2026. Passé ce délai, un certificat v1.1 n’est plus valable pour héberger des données de santé pour le compte de tiers.
Mon éditeur de logiciel doit-il être certifié HDS ?
Cela dépend de son rôle. Dès qu’un technicien accède à un environnement contenant des données de santé pour la maintenance, l’éditeur exerce l’activité 5, soumise à certification. Un éditeur SaaS peut s’appuyer sur l’hébergeur certifié, à condition qu’un contrat encadre formellement cette relation.
Vous pourriez également être intéressé par les articles suivants :
RSSI externalisé : sécuriser un établissement de santé sans recruter
Audit NIS2 en santé : cadrer votre mise en conformité
