Hébergement HDS : choisir un hébergeur de données de santé certifié — le guide 2026

Qui doit être certifié HDS, comment vérifier qu'un hébergeur de données de santé l'est vraiment, les 6 clauses contractuelles à exiger — et ce que la v2.1 change d'ici décembre 2026.
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 — et elle évolue : la version 2.1 du référentiel, attendue en octobre 2026, s'appliquera dès décembre 2026.
v2.1 : ce qui change d'ici décembre 2026
L'Agence du Numérique en Santé a annoncé la publication du référentiel v2.1 pour octobre 2026, avec une entrée en application trois mois plus tard, en décembre 2026. Les évolutions sont ciblées : elles renforcent la transparence sur les éventuels transferts de données et sur la soumission de l'hébergeur à des législations de pays tiers à l'Union européenne. Pas d'audit supplémentaire à prévoir : le contrôle et l'émission du nouveau certificat se feront à l'occasion de l'audit de surveillance annuel ou de renouvellement.
Conséquence très concrète côté clients : les contrats d'hébergement — y compris ceux déjà signés — devront, le cas échéant, être modifiés pour intégrer cette transparence sur les lois extra-européennes. Si vous êtes établissement ou éditeur, c'est maintenant qu'il faut relire vos contrats, pas en décembre.
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.
Comment vérifier qu'un hébergeur est réellement certifié HDS
Ne vous contentez jamais d'un logo « HDS » sur une plaquette commerciale : la certification se vérifie sur pièces, à la source. L'Agence du Numérique en Santé publie la liste officielle des hébergeurs certifiés — c'est le premier réflexe, avant toute signature.
Trois contrôles en pratique. Un : l'hébergeur figure dans la liste officielle, avec un certificat en cours de validité (trois ans, audits de surveillance annuels) délivré par un organisme accrédité. Deux : le périmètre du certificat couvre exactement les activités que vous achetez — le référentiel distingue six activités certifiables, de la mise à disposition de locaux (activité 1) à l'infrastructure (2-3), la plateforme applicative (4), l'administration-exploitation (5) et la sauvegarde externalisée (6) ; un hébergeur certifié pour les activités 1 à 3 n'est pas certifié pour infogérer votre système. Trois : l'entité juridique certifiée est bien celle qui signe votre contrat — pas une maison mère, pas une filiale non couverte.
Demandez le certificat lui-même (numéro, périmètre, dates) et consignez sa référence dans votre registre des traitements, avec une revue annuelle planifiée : un certificat, ça se suspend et ça expire.
Les 6 clauses contractuelles à exiger de votre hébergeur
La certification du prestataire ne remplace jamais le contrat : l'article 28 du RGPD et les exigences du Code de la santé publique s'y ajoutent. Six clauses font la différence entre un contrat protecteur et une coquille vide. Un — le périmètre : les activités HDS couvertes, annexées au contrat, alignées sur le certificat. Deux — la localisation : lieu d'hébergement des données, engagement sur l'EEE, et transparence sur toute soumission à des législations extra-européennes — précisément le point que la v2.1 renforcera ; anticipez-le dès maintenant. Trois — la chaîne de sous-traitance : identité des sous-hébergeurs, leur propre certification, et votre droit d'objection en cas de changement. Quatre — la sécurité et les incidents : mesures techniques, et notification des violations dans des délais compatibles avec vos propres obligations de l'article 33 du RGPD. Cinq — la réversibilité : restitution des données dans un format exploitable, délais chiffrés, et clause de test — une réversibilité jamais testée n'existe pas. Six — l'audit : votre droit de vérifier, la transmission des rapports pertinents, et l'obligation d'information immédiate si le certificat est suspendu ou retiré.
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 la v2.1 renforcera encore cette exigence de transparence. « 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. « Mes contrats déjà signés devront-ils changer avec la v2.1 ? » Le cas échéant, oui : les exigences de transparence sur les législations extra-européennes s'appliqueront aussi aux contrats en cours — d'où l'intérêt de les relire dès maintenant.
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.
Partager cet article
