Application santé : ce que l'hébergement HDS impose vraiment

La certification HDS porte sur l'hébergeur, pas sur votre application. C'est la phrase qui règle la moitié des malentendus sur le sujet. Si votre produit traite des données de santé recueillies dans un contexte de soin et que vous confiez leur hébergement à un tiers, ce tiers doit détenir un certificat de conformité. Rien dans ce certificat ne rend votre code conforme, ne remplace vos obligations RGPD, ni ne couvre automatiquement toutes les briques de votre infrastructure.

Depuis le 16 mai 2026, tous les hébergeurs certifiés doivent l'être au titre du nouveau référentiel, celui de 2024. C'est un bon moment pour reprendre le sujet proprement : qui est réellement concerné, ce que le certificat couvre activité par activité, ce qu'il ne couvre pas, et ce qui reste à votre charge quand vous éditez l'application.

Ce que dit la loi, exactement

Le fondement tient dans l'article L1111-8 du code de la santé publique. Il vise toute personne qui héberge des données de santé à caractère personnel recueillies à l'occasion d'activités de prévention, de diagnostic, de soins ou de suivi social et médico-social, pour le compte des personnes physiques ou morales à l'origine de leur production ou de leur recueil, ou pour le compte du patient lui-même.

Sur support numérique, cet hébergeur doit être titulaire d'un certificat de conformité délivré par des organismes accrédités par l'instance française d'accréditation, le Cofrac, ou par celle d'un autre État membre de l'Union. Le texte ajoute une règle souvent oubliée côté produit : l'hébergement est réalisé après que la personne prise en charge en a été dûment informée, et sauf opposition de sa part pour un motif légitime. Cette information doit donc exister quelque part dans votre parcours utilisateur, pas seulement dans un contrat entre vous et votre prestataire.

Le même article pose une interdiction absolue : tout acte de cession à titre onéreux de données de santé identifiantes est interdit, y compris avec l'accord de la personne concernée. Le manquement renvoie à l'article 226-21 du code pénal, qui punit le détournement de finalité de cinq ans d'emprisonnement et de 300 000 euros d'amende. À titre de comparaison, on est très au-dessus des montants administratifs habituels, et sur un terrain pénal.

Détail utile si vous numérisez de l'existant : pour les données sur support papier, ce n'est plus une certification mais un agrément du ministre chargé de la culture qui s'applique.

Deux critères décident si vous êtes concerné

Le premier critère porte sur la donnée. Le texte ne dit pas « toute donnée de santé », il dit « recueillie à l'occasion d'activités de prévention, de diagnostic, de soins ou de suivi social et médico-social ». Une application de bien-être, de nutrition ou de suivi sportif qui collecte du poids, du sommeil ou une fréquence cardiaque hors de tout contexte de prise en charge ne bascule pas mécaniquement dans le régime HDS. Attention à ne pas en tirer la conclusion inverse : ces données restent très probablement des données de santé au sens du RGPD, donc des données sensibles, avec tout ce que cela implique. Les deux régimes se recoupent sans se confondre, et c'est exactement là que les projets se trompent.

Le second critère porte sur le rôle. La certification vise l'hébergement réalisé pour le compte d'un tiers. Un établissement ou une structure qui héberge ses propres données sur sa propre infrastructure, pour son propre compte, n'a pas à être certifié pour cela. En revanche, si vous êtes éditeur et que votre application en mode logiciel comme service stocke les données de vos clients soignants, vous hébergez pour le compte de tiers. Selon votre architecture, cela signifie soit vous appuyer intégralement sur un hébergeur certifié pour les activités concernées, soit vous certifier vous-même.

Six activités, et pourquoi « mon hébergeur est HDS » ne veut rien dire

C'est le point le plus mal compris, et le plus coûteux quand on le découvre tard. Le référentiel découpe l'hébergement en six activités distinctes, et un certificat ne couvre que celles pour lesquelles l'organisme a été audité.

• La mise à disposition et le maintien en condition opérationnelle des sites physiques, autrement dit les centres de données.
• La mise à disposition et le maintien en condition opérationnelle de l'infrastructure matérielle : serveurs, stockage, réseau.
• La mise à disposition et le maintien en condition opérationnelle de l'infrastructure virtuelle, virtualisation et conteneurs compris.
• La mise à disposition et le maintien en condition opérationnelle de la plateforme d'hébergement applicative : systèmes d'exploitation, bases de données gérées.
• L'administration et l'exploitation du système d'information contenant les données de santé.
• La sauvegarde externalisée des données de santé.

Ces six activités se regroupent en deux certificats distincts. L'hébergeur d'infrastructure physique couvre les deux premières. L'hébergeur infogéreur couvre les quatre suivantes. Un grand fournisseur de cloud peut donc être parfaitement certifié sur l'infrastructure sans couvrir l'administration et l'exploitation de votre système, ni votre sauvegarde externalisée. Si c'est vous, ou une société d'infogérance non certifiée, qui assurez ces activités, elles sortent du périmètre couvert.

La bonne pratique tient en une question à poser avant de signer : sur laquelle des six activités votre certificat porte-t-il, et qui couvre les autres ? Demandez le certificat lui-même, pas une mention commerciale, et recoupez-le avec la liste publique des hébergeurs certifiés que tient l'Agence du numérique en santé. La liste précise le périmètre et la validité, et elle est le seul juge de paix.

Ce que le référentiel de 2024 a changé

La nouvelle version du référentiel a été approuvée par un arrêté du 26 avril 2024, publié au Journal officiel le 16 mai 2024. Le calendrier a été le suivant : les nouveaux candidats sont évalués sur cette version depuis le 16 novembre 2024, et les hébergeurs déjà certifiés disposaient de vingt-quatre mois pour s'y conformer, soit au plus tard le 16 mai 2026. Concrètement, un certificat en cours de validité aujourd'hui repose nécessairement sur cette version.

Trois évolutions comptent pour un éditeur. La première est une exigence de localisation physique des données dans l'Espace économique européen, ce qui ferme un débat qui traînait depuis des années. La deuxième est une exigence de transparence vis-à-vis des clients et du public sur les risques d'accès extra-communautaire aux données : un hébergeur européen filiale d'un groupe non européen doit désormais l'exposer, pas le laisser deviner. La troisième est l'alignement sur la version 2022 de la norme ISO 27001, socle du référentiel.

Cette évolution rejoint une tendance de fond que nous observons sur d'autres réglementations, de NIS 2 à la commande publique : la localisation et la maîtrise juridique de la donnée deviennent des critères de conformité, plus seulement des arguments commerciaux.

Sur le fonctionnement, retenez que le certificat est délivré pour trois ans, avec un audit de surveillance chaque année et un audit de renouvellement au terme. Un certificat n'est donc jamais un acquis définitif, et sa date de validité mérite d'être vérifiée, pas supposée.

Ce que la certification HDS ne couvre pas

Un hébergeur certifié vous apporte un socle : sécurité physique, disponibilité, gestion des accès à l'infrastructure, journalisation technique, réversibilité. Il ne dit rien de votre application, et c'est pourtant là que se produisent la plupart des incidents que nous voyons.

Restent intégralement à votre charge l'authentification et la gestion des habilitations, le cloisonnement entre clients dans une architecture mutualisée, le chiffrement applicatif des champs sensibles, la journalisation métier permettant de retracer qui a consulté quel dossier, la gestion des exports et la robustesse de vos API. Aucun certificat d'hébergement ne compense une API qui répond à un identifiant incrémental sans contrôle de droits. Nous en avons tiré les mêmes conclusions à propos d'un incident public dans notre article sur la sécurisation des applications, et les fondamentaux sont rappelés dans notre guide sur la sécurité d'un site internet.

La certification ne remplace pas non plus le RGPD. Base légale du traitement, analyse d'impact, durées de conservation, information des personnes, exercice des droits, encadrement contractuel de la sous-traitance : tout cela reste à produire, et la CNIL traite les données de santé comme des données sensibles au sens de l'article 9. Notre article sur la conformité RGPD d'un site pose le cadre général.

Enfin, elle ne dit rien de vos intégrations tierces. Un outil de mesure d'audience, un enregistreur de session, un support par messagerie instantanée ou un service d'e-mails transactionnels peuvent tous faire sortir de la donnée de santé d'un environnement certifié, parfois par une simple URL contenant un identifiant de dossier. C'est une raison de plus de préférer une mesure d'audience sobre et hébergée en Europe, sujet que nous avons traité dans notre comparatif des alternatives à Google Analytics.

Le contrat, la partie que personne ne lit

Le régime HDS est autant contractuel que technique. Le contrat d'hébergement doit décrire précisément les prestations couvertes, activité par activité, et non renvoyer à une mention générique. Vérifiez trois choses en particulier.

La réversibilité et la restitution : dans quel format, dans quel délai, à quel coût récupérez-vous l'intégralité des données si vous partez, et sous quelle forme les sauvegardes vous sont-elles rendues. C'est la clause la plus négligée et la plus chère à découvrir tardivement.

La chaîne de sous-traitance : qui intervient réellement derrière votre hébergeur, depuis quels pays, et selon quelles modalités d'information préalable en cas de changement. Le référentiel impose désormais de la transparence sur les risques d'accès extra-communautaire, servez-vous en.

Le partage des responsabilités, enfin, formalisé activité par activité. Un tableau de répartition annexé au contrat vaut mieux qu'une conversation commerciale, parce qu'en cas d'incident la première question posée sera celle du périmètre.

Ce que ça coûte réellement

L'hébergement certifié coûte plus cher qu'un cloud standard, mais ce surcoût n'est presque jamais le poste principal. Le coût réel se trouve dans l'architecture : cloisonnement des environnements, chiffrement, journalisation exploitable, procédures de restauration testées, gestion documentée des habilitations. Ce sont des choix de conception, et ils sont bien moins onéreux pris au départ qu'ajoutés après coup.

Si vous devez vous certifier vous-même en tant qu'éditeur, comptez une démarche de niveau système de management de la sécurité, adossée à ISO 27001, avec un audit initial, un audit de surveillance annuel et un renouvellement à trois ans. C'est un projet d'entreprise, pas une case à cocher dans un cahier des charges. La question de savoir si vous devez le porter ou vous appuyer sur un tiers certifié mérite d'être tranchée tôt, parce qu'elle détermine votre architecture.

Dans les deux cas, la place naturelle de ces exigences est le cahier des charges, au même titre que les critères de performance ou d'accessibilité.

Par où commencer, en quatre étapes

Qualifiez d'abord la donnée. Est-elle recueillie à l'occasion d'une activité de prévention, de diagnostic, de soins ou de suivi social et médico-social ? Si oui, le régime HDS s'applique dès qu'un tiers héberge. Si non, vous restez sur le terrain du RGPD, ce qui n'est pas rien.

Qualifiez ensuite votre rôle. Hébergez-vous pour votre propre compte, ou pour le compte de vos clients ? La réponse détermine si vous devez choisir un hébergeur certifié, ou le devenir.

Vérifiez le certificat, activité par activité, sur la liste tenue par l'Agence du numérique en santé, en contrôlant le périmètre et la date de validité. Identifiez qui couvre les activités absentes, en particulier l'administration et l'exploitation, et la sauvegarde externalisée.

Traitez enfin ce que le certificat ne couvre pas : analyse d'impact, information du patient et droit d'opposition, habilitations, journalisation métier, revue de vos intégrations tierces, réversibilité contractuelle. C'est la moitié du travail, et c'est celle qui vous appartient.

Ce que nous en retenons

Le HDS n'est pas un label que l'on affiche, c'est un périmètre que l'on vérifie. Un certificat couvre certaines des six activités, pour trois ans, sous audit annuel, et depuis mai 2026 nécessairement au titre du référentiel de 2024, avec ses exigences de localisation dans l'Espace économique européen et de transparence sur les accès extra-communautaires.

Le reste vous appartient : la qualification de vos données, votre conformité RGPD, la sécurité de votre application et la maîtrise de vos intégrations. Un hébergeur irréprochable ne protège pas d'une API trop bavarde, et c'est pourtant par là que passent les incidents que le public retient.

Nous concevons et reprenons des applications métier dans le secteur de la santé, avec cette contrainte posée dès le cadrage plutôt que découverte en recette. Si vous voulez savoir où vous en êtes, parlons-en.