Hébergement de données de santé (HDS) : quand la certification s'impose et ce qu'elle change pour une application

Qu'est-ce que l'hébergement de données de santé (HDS) ?

L'hébergement de données de santé désigne la conservation et l'exploitation, pour le compte d'un professionnel, d'un établissement ou d'un patient, de données de santé recueillies dans un contexte de soin ; sur support numérique, il est réservé aux hébergeurs titulaires d'un certificat de conformité.

Ce certificat est délivré par un organisme de certification accrédité, sur la base d'un référentiel approuvé par arrêté du ministre chargé de la santé (article R. 1111-10).

Le cadre tient dans l'article L. 1111-8 du Code de la santé publique et ses articles d'application. Il ajoute ses propres exigences au RGPD, qui classe déjà les données de santé parmi les catégories particulières de données (article 9). Pour un éditeur ou une PME qui fait développer une application dans le secteur de la santé, la question HDS se pose dès qu'il faut choisir où les données seront stockées et qui administrera le système.

Quand la certification HDS est-elle obligatoire ?

Elle s'impose quand quatre conditions sont réunies ; si l'une manque, la certification HDS n'est pas exigée, mais le RGPD continue de s'appliquer.

1. Des données de santé à caractère personnel, relatives à des personnes identifiables.
2. Recueillies à l'occasion d'activités de prévention, de diagnostic, de soins ou de suivi social et médico-social.
3. Hébergées pour le compte d'un tiers : le professionnel ou l'organisme à l'origine de la production ou du recueil des données, ou le patient lui-même.
4. Sur support numérique : l'hébergement sur papier relève d'un agrément distinct, délivré par le ministre chargé de la culture.

Le texte prévoit une exception : ne constitue pas un hébergement le fait de recevoir des données pour une courte période afin d'effectuer une saisie, une mise en forme, une matérialisation ou une dématérialisation (article R. 1111-8-8). Enfin, le responsable de traitement qui confie l'hébergement à un tiers doit s'assurer que celui-ci est certifié.

Les six activités couvertes par la certification

L'article R. 1111-9, dans sa rédaction issue du décret du 24 mars 2026, définit six activités ; assurer tout ou partie d'entre elles pour le compte d'un responsable de traitement ou d'un patient constitue un hébergement soumis à certification.

Le point d'attention pour un projet sur mesure est l'activité 5 : le prestataire qui administre et exploite au quotidien le système de production pour le compte de son client exerce une activité d'hébergement au sens du texte. La répartition des rôles entre éditeur, prestataire et hébergeur doit donc être explicite.

Ce que la réglementation change pour une application

Pour une application métier dans la santé, l'exigence HDS se traduit par quatre décisions concrètes, à prendre avant le développement.

• Le choix de l'hébergeur : un hébergeur certifié dont le certificat couvre les activités dont vous avez besoin. Le périmètre du certificat et ses dates de délivrance et de renouvellement doivent figurer au contrat (article R. 1111-11).
• La localisation : le stockage des données est mis en œuvre exclusivement dans un État de l'Union européenne ou de l'Espace économique européen ; un transfert ou un accès à distance depuis un pays tiers n'est possible que dans les conditions des articles 45 et 46 du RGPD, avec des mentions spécifiques au contrat (articles R. 1111-9-1 et R. 1111-11).
• La chaîne contractuelle : quand vous passez par un prestataire qui recourt lui-même à un hébergeur certifié, votre contrat avec ce prestataire reprend les clauses du contrat hébergeur (article R. 1111-11, II).
• L'architecture : base de données, sauvegardes, fichiers joints, journaux et environnements de test doivent rester dans le périmètre certifié ; un service tiers branché à côté (e-mail, stockage de pièces jointes, IA) peut faire sortir des données de santé du cadre.

Le contrat d'hébergement comporte une liste de clauses obligatoires (quatorze, plus une quinzième lorsque l'hébergeur ou l'un de ses sous-traitants est soumis à la législation d'un pays tiers), dont la réversibilité, la restitution de la totalité des données en fin de prestation et leur destruction sans copie après accord du responsable de traitement.

Une application dans un cabinet traite-t-elle forcément des données de santé ?

Non : tout dépend de ce que l'outil enregistre réellement, et c'est la première question du cadrage.

Un outil de logistique interne, de planning du personnel ou de gestion du matériel peut fonctionner dans un cabinet sans jamais rattacher une information de santé à un patient identifiable. Le robot de livraison conçu pour Sakura France Service, par exemple, orchestre des missions logistiques entre la stérilisation et les salles de soins : ce sont les salles qui passent commande, et le tableau de bord est servi par le robot lui-même sur le réseau du cabinet. À l'inverse, dès qu'un nom de patient est associé à un acte, un résultat ou un rendez-vous de soin, la question HDS se pose. La qualification se fait au cas par cas ; la page logiciel sur mesure pour la santé présente les usages du secteur, et l'article sur le site web d'un professionnel de santé couvre la partie vitrine.

Les erreurs courantes

• Choisir un hébergeur « certifié HDS » sans vérifier le périmètre : un certificat peut couvrir l'infrastructure sans couvrir l'administration de votre application.
• Laisser des copies hors périmètre : sauvegardes chez un autre fournisseur, base de test copiée sur un poste, pièces jointes dans un service de stockage grand public.
• Oublier les sous-traitants techniques : envoi d'e-mails, notifications, outils de suivi d'erreurs, modèles d'IA qui reçoivent des données.
• Confondre HDS et conformité RGPD : la certification de l'hébergeur ne dispense ni du registre, ni de l'analyse d'impact, ni des droits des personnes.
• Négliger l'information du patient : l'hébergement intervient après que la personne prise en charge en a été informée, sauf opposition pour un motif légitime (article L. 1111-8).

Check-list HDS pour un projet d'application

1. Les données de santé traitées et leur contexte de recueil sont identifiés.
2. Les activités d'hébergement nécessaires (1 à 6) sont listées et attribuées.
3. Le certificat de l'hébergeur couvre ces activités ; son périmètre et ses dates figurent au contrat.
4. Le stockage est situé dans l'Union européenne ou l'Espace économique européen.
5. Les clauses de l'article R. 1111-11 sont reprises dans toute la chaîne de contrats.
6. Sauvegardes, journaux et environnements de test restent dans le périmètre.
7. L'analyse d'impact RGPD a été évaluée, le traitement à grande échelle de données de santé y étant soumis (article 35).

Ce que fait YMHB Web

Sur un projet qui touche à la santé, YMHB Web pose la question HDS au cadrage, première étape de sa méthode : quelles données sont réellement collectées, quelles activités d'hébergement sont nécessaires et qui les assure. Chaque activité exercée pour le compte du client, y compris l'administration et l'exploitation de la production, doit l'être par un acteur certifié pour cette activité. Les exigences du RGPD appliqué au logiciel métier sont traitées en même temps. Ce guide présente le cadre réglementaire général ; pour un projet donné, faites valider la qualification par votre délégué à la protection des données ou un conseil spécialisé.