Hébergement de données de santé : HDS, RGPD et architecture
·5 min de lecture·Bryan van Paemel, CTO
Un planning de tournées, un outil de suivi des patients, une application de prise de rendez-vous : dès qu’un logiciel stocke des informations sur la santé d’une personne, une question précède toutes les autres. Où vivent ces données, et qui a le droit de les héberger ? En France, la réponse a un nom : l’hébergement des données de santé, et la certification HDS qui l’encadre. Voici ce qu’elle impose, ce que sa nouvelle version a changé, et ce que cela veut dire concrètement pour l’architecture de votre outil.
À retenir
- Héberger des données de santé pour le compte d’autrui exige un hébergeur certifié HDS : c’est une obligation légale, pas un label marketing.
- Le référentiel HDS 2024 impose un stockage physique dans l’Espace économique européen et plus de transparence sur les accès depuis l’extérieur.
- Choisir un hébergeur certifié ne suffit pas : l’architecture de l’application, ses accès, ses journaux et ses services satellites font la conformité réelle.
L’obligation : qui doit être certifié HDS
Le cadre est posé par les articles L.1111-8 et R.1111-10 du Code de la santé publique. La notification du référentiel HDS à la Commission européenne les résume ainsi : tout hébergeur de données de santé à caractère personnel doit être titulaire d’un certificat de conformité délivré par un organisme de certification, sur la base d’un référentiel approuvé par arrêté du ministre chargé de la santé. Le même document rappelle la finalité : garantir aux usagers et aux professionnels que ces données, sensibles au sens du RGPD, sont sécurisées.
Pour une PME de santé ou un éditeur, la conséquence pratique est simple. Si votre outil stocke des données de santé de patients, il doit tourner chez un prestataire certifié pour les activités qu’il assure : l’infrastructure physique, mais aussi l’administration et l’exploitation du système. Un serveur loué chez un hébergeur généraliste non certifié, aussi sérieux soit-il, ne fait pas l’affaire.
Le référentiel HDS 2024 : ce qui a changé
Le arrêté du 26 avril 2024, publié au Journal officiel le 16 mai 2024, a approuvé une nouvelle version du référentiel HDS, entrée en vigueur six mois après sa publication pour les nouvelles demandes de certification. Selon l’analyse publiée par le cabinet CMS, les hébergeurs déjà certifiés disposaient de 24 mois pour se mettre en conformité, soit au plus tard le 16 mai 2026. Cette date est passée : un hébergeur qui se dit « HDS » aujourd’hui doit l’être selon la nouvelle version.
Les évolutions qui comptent pour vous, d’après la notification européenne :
- Souveraineté : le stockage des données de santé est restreint au territoire d’un État de l’Espace économique européen.
- Transparence envers le client : l’hébergeur doit l’informer de tout transfert ou accès distant depuis un pays hors EEE sans niveau de protection adéquat, et de toute exposition à une réglementation extra-européenne pouvant donner accès aux données.
- Transparence publique : l’hébergeur rend publiques et tient à jour les informations sur les transferts éventuels hors EEE.
- Clarification des activités certifiées, notamment l’administration et l’exploitation des systèmes, et intégration des évolutions de la norme ISO 27001.
Ce que ça change pour votre logiciel
La certification couvre l’hébergeur. La conformité de votre outil, elle, se joue dans son architecture. C’est là que la plupart des projets se trompent : on choisit un cloud certifié, puis on y branche un service d’envoi d’e-mails, un outil de suivi d’erreurs et une API d’IA hébergés n’importe où.
Tracer le périmètre des données
Première étape, avant toute ligne de code : lister ce qui est une donnée de santé dans votre outil et ce qui ne l’est pas. Un créneau de planning avec le nom d’un patient et le motif de passage en est une. Le nombre de tournées de la semaine, sans identité, n’en est pas. Ce découpage dicte l’architecture : tout ce qui est dans le périmètre vit dans l’environnement certifié, y compris les sauvegardes, les copies de base de données et les fichiers joints.
Il interdit aussi une habitude répandue chez les développeurs : copier la base de production sur un poste ou un serveur de test pour reproduire un bug. Avec des données de santé, les environnements de test travaillent sur des données fictives, point.
Droits et journalisation des accès
Une infirmière coordinatrice n’a pas besoin des mêmes informations qu’une secrétaire médicale ou qu’un comptable. Les droits se définissent par rôle, au plus juste, et chaque consultation d’un dossier est tracée : qui, quand, quoi. Ce journal des accès doit être lui-même protégé contre la modification. C’est souvent ce qui manque aux outils bricolés sur un tableur partagé ou un logiciel no-code, où tout le monde voit tout et où personne ne sait qui a ouvert quoi.
Les services satellites, angle mort classique
Les notifications par e-mail ou SMS, la mesure d’audience, le suivi d’erreurs, et désormais les API d’intelligence artificielle sont autant de portes de sortie. La règle que nous appliquons : aucun de ces services ne reçoit de donnée de santé. Un e-mail dit « vous avez un nouveau message dans votre espace », jamais le contenu. Une erreur remontée contient un identifiant technique, pas un nom. Pour l’IA, la question mérite un article entier : nous l’avons traitée dans où vont vos données quand vous utilisez une IA.
Les questions à poser avant de signer
Que vous achetiez un logiciel ou que vous en fassiez construire un, ces questions séparent un prestataire qui maîtrise le sujet d’un prestataire qui découvre l’acronyme.
- Chez quel hébergeur tourne la production, et pour quelles activités est-il certifié HDS selon le référentiel en vigueur ?
- Où sont physiquement stockées les données et leurs sauvegardes, et l’hébergeur est-il soumis à une loi extra-européenne ?
- Qui administre le système au quotidien, et cette administration est-elle couverte par la certification ?
- Quels services tiers reçoivent des données, lesquelles, et comment s’assure-t-on qu’aucune donnée de santé n’y transite ?
- Comment les accès sont-ils tracés, combien de temps les journaux sont-ils conservés, et qui peut les consulter ?
Pour le choix de l’hébergeur lui-même, les grandes familles de cloud et leurs compromis sont présentés dans quel hébergeur cloud choisir ; ici, le filtre HDS réduit la liste avant toute comparaison de prix. Et pour un exemple d’outil métier concerné au premier chef, voyez notre article sur le planning des soignants et des tournées.
Chez pragma once, ces questions sont tranchées au cadrage, avant le premier écran. C’est la condition pour construire la couche organisation qui manque aux structures de soins sans créer un nouveau risque, comme nous le décrivons sur la page logiciel sur-mesure pour la santé. Pour les applications web en général, notre méthode est sur la page application web et SaaS.
Une donnée de santé ne sort jamais du périmètre certifié. Tout le reste de l’architecture se déduit de cette phrase.
Mis à jour le 6 octobre 2026.
← Tous les articles