Certification HDS : qui est concerné et comment l'obtenir ?

Vous éditez une solution SaaS pour les professionnels de santé, une application de suivi patient, une plateforme de téléconsultation ? La question arrive toujours, souvent posée par un prospect ou un acheteur hospitalier : êtes-vous certifié HDS ? Derrière ce sigle se cache une obligation légale française parmi les plus structurantes du numérique en santé. Voici qui est concerné, ce que la certification exige, et comment s'organiser si vous ne l'avez pas.

La certification HDS, c'est quoi ?

HDS signifie Hébergeur de Données de Santé. Le principe est posé par l'article L1111-8 du Code de la santé publique : 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 d'un tiers, doit être titulaire d'un certificat de conformité.

Le dispositif a remplacé l'ancien agrément ministériel en 2018. La certification est délivrée par des organismes certificateurs accrédités par le COFRAC, sur la base d'un référentiel publié par l'Agence du Numérique en Santé (ANS). Elle s'appuie sur la norme ISO 27001, complétée d'exigences propres aux données de santé.

Deux éléments déclenchent l'obligation, et les deux doivent être réunis :

• la nature des données : des données de santé à caractère personnel issues d'activités de soins, de prévention, de diagnostic ou de suivi médico-social ;
• l'hébergement pour le compte d'un tiers : vous stockez ou traitez ces données pour un client (établissement, professionnel de santé, patient), pas pour votre propre compte exclusif.

À l'inverse, le professionnel ou l'établissement qui conserve ses propres dossiers patients sur ses propres serveurs n'a pas besoin de la certification. C'est l'externalisation qui déclenche l'obligation, chez celui qui héberge.

Qui est concerné en pratique ?

Le champ est bien plus large que les hébergeurs d'infrastructure classiques :

• les éditeurs SaaS santé : logiciel de gestion de cabinet, dossier patient informatisé, prise de rendez-vous avec motifs médicaux, téléconsultation, plateforme de coordination de soins ;
• les prestataires cloud et infogéreurs qui opèrent des environnements contenant des données de santé pour des clients du secteur ;
• les startups e-santé dont l'application collecte des données de suivi médical, y compris lorsque le client est le patient lui-même ;
• certains acteurs périphériques : solutions RH ou assurantielles dès lors qu'elles traitent des données médicales issues du parcours de soins, prestataires de sauvegarde externalisée pour des établissements.

Une zone grise fréquente : les données de bien-être. Un tracker de sommeil grand public ne relève pas en principe de l'hébergement HDS, car les données ne sont pas produites dans un cadre de soins. Mais dès qu'un professionnel de santé entre dans la boucle, ou que les données servent à un suivi médical, la qualification bascule. La frontière se juge au cas par cas et mérite une analyse écrite : c'est elle que vous opposerez en cas de contrôle ou de question d'un client.

Les six activités d'hébergement certifiables

Le référentiel découpe l'hébergement en six activités, et le certificat précise lesquelles sont couvertes :

1. la mise à disposition de sites physiques d'hébergement ;
2. la mise à disposition d'infrastructure matérielle ;
3. la mise à disposition d'infrastructure virtuelle ;
4. la mise à disposition de plateforme d'hébergement d'applications ;
5. l'administration et l'exploitation du système d'information de santé ;
6. la sauvegarde externalisée.

Les activités 1 et 2 correspondent au certificat dit hébergeur d'infrastructure physique, les activités 3 à 6 au certificat hébergeur infogéreur. Ce découpage a une conséquence pratique majeure : s'appuyer sur un cloud certifié HDS ne vous dispense pas de votre propre certification. Si votre plateforme SaaS tourne sur un IaaS certifié pour les activités 1 à 3, mais que vous opérez vous-même la plateforme applicative et son administration (activités 4 et 5), c'est à vous d'être certifié pour ces activités. C'est l'erreur la plus répandue chez les éditeurs, et le premier point que vérifient les acheteurs hospitaliers avertis.

Le référentiel v2 : ce qui a changé

Un référentiel révisé a été adopté en 2023 et s'applique aux certifications délivrées depuis fin 2024, les certificats émis sous l'ancienne version restant valables jusqu'à leur échéance. Les évolutions principales :

• souveraineté et localisation : les données doivent être hébergées dans l'Espace économique européen, et l'hébergeur doit faire preuve de transparence sur tout transfert hors EEE ainsi que sur son exposition à des législations extraterritoriales, avec une information contractuelle claire du client ;
• mise à jour des exigences de sécurité, alignées sur les versions récentes des normes ISO ;
• clarification du périmètre des activités et des responsabilités entre hébergeur et client.

Pour les éditeurs qui s'appuient sur des clouds américains, l'exigence de transparence sur l'exposition aux lois extraterritoriales est le point sensible : elle ne l'interdit pas en soi, mais elle oblige à documenter la situation et à l'assumer contractuellement face aux clients. Certains acheteurs publics en font désormais un critère éliminatoire, indépendamment du droit.

Comment obtenir la certification ?

Le parcours type se déroule en cinq étapes :

1. Cadrage : définir le périmètre (quelles activités, quels services, quels sites) et réaliser une analyse d'écart par rapport au référentiel. Si vous êtes déjà ISO 27001, une partie substantielle du chemin est faite.
2. Mise à niveau : politique de sécurité, gestion des risques, contrôle des accès, journalisation, gestion des incidents, plan de continuité, encadrement des sous-traitants. Le volet documentaire est lourd et doit refléter la réalité opérationnelle.
3. Volet juridique : contrats clients conformes aux exigences du référentiel (le contrat d'hébergement de données de santé comporte des mentions obligatoires), DPA au titre de l'article 28 du RGPD, chaîne de sous-traitance documentée.
4. Audit de certification : audit documentaire puis audit sur site par l'organisme certificateur accrédité. Les écarts mineurs font l'objet d'un plan d'action, les écarts majeurs bloquent la délivrance.
5. Vie du certificat : validité de trois ans, avec audits de surveillance annuels. Toute évolution significative du périmètre (nouvelle activité, nouveau site, changement d'infrastructure) doit être déclarée.

Côté budget et délais, comptez généralement entre six et douze mois entre le lancement et l'obtention, selon votre maturité sécurité de départ. Le coût combine l'accompagnement, les éventuels chantiers techniques et les frais d'audit. Pour une startup, c'est un investissement sérieux, mais c'est aussi un actif commercial : la certification est devenue un prérequis dans la plupart des appels d'offres du secteur.

Que risque-t-on sans certification ?

Héberger des données de santé pour le compte de tiers sans certificat expose sur plusieurs fronts :

• pénal : le non-respect des obligations d'hébergement prévues par le Code de la santé publique est pénalement sanctionné ;
• RGPD : les données de santé sont des données sensibles au sens de l'article 9. Un hébergement non conforme caractérise facilement un manquement à l'obligation de sécurité de l'article 32, avec des amendes pouvant atteindre 4 % du chiffre d'affaires mondial et une exposition médiatique immédiate en cas de violation de données ;
• contractuel et commercial : résiliation par les clients, responsabilité contractuelle, exclusion des marchés publics et des référencements, deals perdus en due diligence. Dans les levées de fonds e-santé, la question HDS figure systématiquement dans l'audit juridique ;
• civil : en cas d'incident affectant des patients, l'absence de certification pèsera lourd dans l'appréciation des fautes.

Vous n'êtes pas certifié : les trois scénarios

Selon votre situation, trois stratégies s'offrent à vous :

• Scénario 1 : vous n'hébergez pas réellement. Si votre rôle se limite à éditer un logiciel installé et opéré par le client sur sa propre infrastructure, vous pouvez rester hors du champ. Encore faut-il que le contrat et la réalité technique le confirment : pas d'accès en production aux données, pas d'administration de l'environnement. Ce positionnement se construit juridiquement.
• Scénario 2 : vous déléguez l'hébergement au maximum. Vous architecturez votre service pour que les activités certifiables soient portées par un partenaire certifié, et vous réduisez contractuellement et techniquement votre propre rôle. Attention : l'administration applicative que vous conservez peut suffire à vous faire entrer dans l'activité 5. L'analyse doit être fine et documentée.
• Scénario 3 : vous visez la certification. C'est la voie obligée dès que vous opérez la plateforme et son exploitation. Lancez le chantier tôt : les clients acceptent parfois une trajectoire de certification contractualisée, rarement une absence de réponse.

HDS, ISO 27001, SecNumCloud, RGPD : ne pas tout confondre

Les acheteurs mélangent souvent les référentiels, et les éditeurs entretiennent parfois le flou. Remettons chaque brique à sa place :

• ISO 27001 est une norme internationale de management de la sécurité de l'information. Elle est le socle de la certification HDS, mais elle ne suffit pas : être ISO 27001 ne rend pas conforme à l'article L1111-8.
• La certification HDS est l'obligation légale française propre aux données de santé hébergées pour des tiers. C'est elle, et elle seule, qui répond à l'exigence du Code de la santé publique.
• SecNumCloud est la qualification de sécurité de l'ANSSI pour les offres cloud de confiance. Elle n'est pas obligatoire pour héberger des données de santé, mais elle devient un critère de choix pour les données les plus sensibles de la sphère publique et peut être exigée dans certains appels d'offres.
• Le RGPD s'applique dans tous les cas, certification ou pas : base juridique du traitement des données de santé (article 9), sécurité (article 32), encadrement des sous-traitants (article 28), analyses d'impact.

En clair : un éditeur SaaS santé sérieux répond aux quatre étages. La certification HDS pour l'obligation légale d'hébergement, ISO 27001 comme socle méthodologique, le RGPD pour le traitement, et SecNumCloud comme option différenciante selon les marchés visés.

Le contrat d'hébergement HDS : des mentions obligatoires

On l'oublie souvent : la réglementation impose un contrat entre l'hébergeur et son client, avec un contenu minimal. Le contrat de prestation d'hébergement de données de santé doit notamment décrire le périmètre du certificat et les prestations couvertes, les lieux d'hébergement, les mesures mises en œuvre pour garantir la sécurité, la disponibilité, l'intégrité et la confidentialité des données, les modalités d'accès des personnes concernées, l'information du client en cas d'incident, et surtout les conditions de restitution des données en fin de contrat, sans possibilité pour l'hébergeur de les conserver ou de les exploiter pour son propre compte.

Pour un éditeur, cela signifie que la trame contractuelle est un livrable de la certification au même titre que la documentation sécurité : les auditeurs la vérifient, et un contrat client non conforme constitue un écart. Pour un client, c'est une grille de lecture : si votre prestataire vous propose un contrat muet sur ces points, vous tenez un signal d'alerte fiable sur sa maturité.

Les questions à poser à votre hébergeur ou éditeur

Que vous soyez établissement, professionnel de santé ou éditeur qui choisit son socle d'infrastructure, sept questions suffisent à faire le tri :

1. Pouvez-vous produire votre certificat HDS en cours de validité, et pour quelles activités exactement ?
2. Qui opère concrètement chaque couche : sites, infrastructure, plateforme, administration, sauvegarde ?
3. Où sont localisées les données, sauvegardes comprises, et existe-t-il un quelconque transfert hors EEE ?
4. Êtes-vous exposé à des législations extraterritoriales, et comment l'assumez-vous contractuellement ?
5. Que prévoit votre contrat en matière de restitution et de destruction des données en fin de relation ?
6. Comment serai-je informé en cas d'incident de sécurité, et dans quel délai ?
7. Vos sous-traitants d'hébergement sont-ils eux-mêmes certifiés, et puis-je en obtenir la liste ?

Un prestataire solide répond aux sept par écrit, sans détour. Les réponses évasives sur le périmètre du certificat (question 1) et sur la chaîne de sous-traitance (question 7) sont les deux signaux d'alerte les plus fréquents que nous rencontrons en audit.

Marchés publics et référencements : le HDS comme ticket d'entrée

Au-delà de l'obligation légale, la certification est devenue une condition d'accès au marché. Les centrales d'achat hospitalières, les GHT et les programmes de référencement nationaux l'exigent en amont, pièces justificatives à l'appui. Une startup e-santé qui vise l'hôpital public sans certification ni trajectoire crédible s'exclut d'elle-même de la consultation. À l'inverse, une certification bien périmétrée, annoncée dans la réponse avec le détail des activités couvertes, crédibilise immédiatement le dossier. Notre conseil aux éditeurs en croissance : traitez le HDS comme un projet produit à part entière, budgété et daté, et contractualisez la trajectoire avec vos premiers clients grands comptes plutôt que de la subir en urgence lors d'un appel d'offres.

Et demain : l'espace européen des données de santé

Le cadre ne va pas se simplifier. Le règlement sur l'espace européen des données de santé (EHDS) organise le partage des données de santé à l'échelle de l'Union, pour les soins comme pour la recherche, avec des obligations nouvelles pour les fabricants de systèmes de dossiers médicaux électroniques et les détenteurs de données. Pour les hébergeurs et éditeurs, cela signifie des exigences supplémentaires d'interopérabilité, de journalisation et de mise à disposition des données, qui viendront se superposer au socle HDS et RGPD. Une architecture pensée aujourd'hui pour la conformité HDS doit déjà intégrer cette trajectoire : formats structurés, traçabilité des accès, capacité d'export. Nous détaillons les obligations de l'EHDS dans un article dédié.

Ce qu'il faut retenir

La certification HDS s'impose à quiconque héberge des données de santé issues du parcours de soins pour le compte de tiers, éditeurs SaaS compris. Le certificat se lit activité par activité : s'adosser à un cloud certifié ne couvre pas la plateforme et l'exploitation que vous opérez vous-même. Le référentiel v2 ajoute des exigences de localisation dans l'EEE et de transparence sur les lois extraterritoriales. Sans certification, l'exposition est à la fois pénale, RGPD, contractuelle et commerciale.

Le cabinet Mirabile Avocat accompagne les éditeurs et hébergeurs du secteur santé : qualification de votre situation au regard de l'article L1111-8, structuration du périmètre de certification, mise en conformité des contrats clients et de la chaîne de sous-traitance. Faites le test ci-dessous pour situer votre exposition, puis parlons stratégie.