Par David Joseph Atias, avocat au Barreau de Paris · LinkedIn · Juillet 2026
Les données de santé sont les plus sensibles qui soient. Leur hébergement n’est pas libre : il est strictement encadré. En France, héberger des données de santé pour le compte d’un tiers impose de recourir à un hébergeur certifié. L’hébergement HDS (Hébergeur de Données de Santé) est une obligation légale, prévue par le Code de la santé publique, qui se cumule avec le RGPD. Un manquement expose à de lourdes sanctions pénales et administratives. Cet article décrypte l’obligation de certification, le cadre juridique, les clauses essentielles du contrat et les pièges à éviter pour sécuriser un hébergement HDS conforme.
SOMMAIRE
- Pourquoi l’hébergement HDS est stratégique en 2026
- Le cadre juridique applicable
- Les 7 clauses essentielles du contrat
- Tableau de synthèse des clauses
- Les 5 pièges à éviter
- Pourquoi faire appel à Atias Avocats
- FAQ — Questions fréquentes
1. Pourquoi l’hébergement HDS est stratégique en 2026
L’hébergement HDS est un enjeu central de la santé numérique. Le secteur explose, et la donnée de santé est au cœur de cette transformation. Trois dynamiques renforcent son importance en 2026.
1.1 L’essor de la santé numérique
La e-santé connaît une croissance rapide : téléconsultation, dossiers patients numériques, objets connectés, intelligence artificielle médicale. Toutes ces solutions traitent des données de santé. Or, leur hébergement impose la certification. Il devient donc un prérequis technique et juridique pour tout acteur de la santé numérique. Sans lui, aucune solution de santé ne peut être déployée légalement.
1.2 Un critère d’accès au marché
La conformité HDS conditionne l’accès au marché de la santé. Les hôpitaux, cliniques et acteurs publics exigent un hébergement certifié de leurs prestataires. C’est souvent une condition des appels d’offres. Pour une startup de e-santé, la certification de l’hébergeur est aussi vérifiée lors des levées de fonds. La conformité HDS est donc un actif commercial autant qu’une obligation. Pour aller plus loin, consultez nos services en matière de protection des données personnelles.
2. Le cadre juridique applicable
L’hébergement de données de santé repose sur un socle juridique double : le droit de la santé et le droit des données. Quatre fondements principaux le structurent.
2.1 L’obligation de certification (article L.1111-8 CSP)
L’article L.1111-8 du Code de la santé publique (CSP) pose le principe. Toute personne qui héberge des données de santé pour le compte de tiers doit être certifiée. La certification HDS atteste du respect d’un référentiel de sécurité strict. Elle est délivrée par un organisme accrédité, après audit. Recourir à un hébergeur non certifié pour des données de santé constitue une infraction. C’est le pilier du dispositif.
2.2 Le RGPD et les données sensibles (article 9)
Le RGPD (Règlement UE 2016/679) classe les données de santé parmi les données sensibles. L’article 9 interdit en principe leur traitement, sauf exceptions (consentement, soins, etc.). Leur sécurité doit être renforcée (article 32). La certification HDS s’ajoute à ces exigences, sans les remplacer. Un hébergement de données de santé doit donc respecter à la fois le RGPD et le référentiel HDS. Les deux cadres se cumulent.
2.3 Le contrat de sous-traitance (article 28 du RGPD)
L’hébergeur agit comme sous-traitant du responsable de traitement. L’article 28 du RGPD impose un contrat écrit, le DPA (Data Processing Agreement, l’accord de sous-traitance). Ce contrat encadre les conditions du traitement, la sécurité et la sous-traitance ultérieure. Pour un hébergement HDS, le DPA doit intégrer les spécificités des données de santé. Il s’articule avec l’annexe TOMS (mesures techniques et organisationnelles de sécurité).
2.4 L’AI Act et l’IA médicale
En 2026, de nombreuses solutions de santé intègrent de l’IA : aide au diagnostic, analyse d’images médicales. Le Règlement UE 2024/1689 (AI Act) classe souvent ces systèmes en haut risque (Annexe III). Ils sont alors soumis à des obligations renforcées : surveillance humaine (article 14), documentation, gestion des risques. L’hébergement de ces solutions doit donc tenir compte de l’AI Act, en plus du HDS. Pour aller plus loin, consultez nos services en matière de contrats commerciaux et IT.
3. Les 7 clauses essentielles du contrat
Un contrat d’hébergement HDS solide s’articule autour de sept clauses essentielles. Chacune sécurise un point sensible propre aux données de santé.
3.1 La preuve et le périmètre de la certification
La première clause vérifie la certification. Le contrat doit imposer à l’hébergeur de fournir son certificat HDS en cours de validité. Il doit préciser le périmètre couvert par la certification (les activités d’hébergement concernées). L’hébergeur doit aussi s’engager à maintenir sa certification pendant toute la durée du contrat et à informer le client de toute évolution. Sans cette preuve, l’hébergement n’est pas sécurisé.
3.2 La conformité RGPD et le DPA
La deuxième clause intègre le RGPD. Le contrat doit comporter un DPA (accord de sous-traitance) conforme à l’article 28. Ce document encadre les finalités, la durée, la sécurité et la sous-traitance ultérieure. Pour des données de santé, les exigences sont renforcées. La clause doit garantir que l’hébergeur agit uniquement sur instruction du responsable de traitement, sans usage propre des données de santé.
3.3 Les mesures de sécurité (annexe TOMS)
La troisième clause détaille la sécurité. Une annexe TOMS (mesures techniques et organisationnelles) doit décrire les mesures concrètes : chiffrement, contrôle d’accès, journalisation, sauvegarde. Pour des données de santé, ces mesures doivent être à la hauteur de la sensibilité. La clause doit interdire toute dégradation du niveau de sécurité. La certification HDS encadre ces mesures, mais le contrat doit les rendre opposables.
3.4 La localisation des données
La quatrième clause fixe la localisation. Pour des données de santé, le client doit savoir précisément où elles sont hébergées. Un hébergement dans l’Union européenne est fortement préférable, pour éviter les risques liés aux transferts hors UE (arrêt Schrems II). La clause doit interdire tout transfert non autorisé et garantir la localisation convenue. C’est un point particulièrement sensible pour les données de santé.
3.5 La disponibilité et la continuité (SLA)
La cinquième clause garantit la disponibilité. Un SLA (Service Level Agreement, accord de niveau de service) doit fixer le taux de disponibilité, les délais de rétablissement et les sauvegardes. Pour des données de santé, l’indisponibilité peut avoir des conséquences graves sur les soins. La clause doit prévoir un plan de continuité d’activité et des pénalités en cas de manquement. La continuité est vitale dans le secteur médical.
3.6 La réversibilité des données
La sixième clause organise la sortie. La réversibilité permet de récupérer les données de santé et de migrer vers un autre hébergeur certifié. Le contrat doit prévoir le format d’export, le périmètre, les délais et la suppression certifiée après transfert. Pour des données de santé, la continuité du soin impose une réversibilité sans rupture. Sans cette clause, le client risque l’enfermement chez son hébergeur.
3.7 La responsabilité et les sanctions
La septième clause répartit la responsabilité. En cas de violation de données de santé, les conséquences sont majeures. Le contrat doit clarifier la responsabilité de l’hébergeur et prévoir des plafonds proportionnés au risque, distincts du prix de la prestation. Une clause limitative trop large peut être écartée (article 1170 du Code civil). Pour des données aussi sensibles, le plafond doit être à la hauteur de l’enjeu réel.
4. Tableau de synthèse des clauses
Le tableau ci-dessous synthétise les 7 clauses d’un contrat d’hébergement de données de santé, leur enjeu et leur criticité.
| Clause | Enjeu principal | Criticité |
|---|---|---|
| 1. Preuve de certification | Garantir le respect de la loi | 🔴 Critique |
| 2. Conformité RGPD / DPA | Encadrer la sous-traitance | 🔴 Critique |
| 3. Mesures de sécurité (TOMS) | Protéger les données sensibles | 🔴 Critique |
| 4. Localisation des données | Maîtriser les transferts | 🟠 Élevée |
| 5. Disponibilité (SLA) | Assurer la continuité du soin | 🟠 Élevée |
| 6. Réversibilité | Préserver la liberté de sortie | 🟠 Élevée |
| 7. Responsabilité | Couvrir le risque réel | 🔴 Critique |
5. Les 5 pièges à éviter
Au-delà des clauses, plusieurs pièges récurrents fragilisent la conformité. Les identifier permet de sécuriser un hébergement de données de santé.
5.1 Croire que le RGPD suffit
Le premier piège est la confusion des cadres. Beaucoup pensent qu’être conforme au RGPD suffit pour héberger des données de santé. C’est faux. La certification HDS est une exigence supplémentaire, propre au droit français de la santé. Respecter le RGPD sans recourir à un hébergeur certifié reste un manquement. Les deux cadres se cumulent et doivent être traités ensemble. La conformité RGPD ne dispense jamais du HDS.
5.2 Ne pas vérifier la certification de l’hébergeur
Le deuxième piège est l’absence de vérification. Certains clients supposent que leur prestataire est certifié, sans le contrôler. Or, la responsabilité leur revient. Il faut exiger le certificat HDS en cours de validité et vérifier son périmètre. Une certification expirée ou ne couvrant pas l’activité concernée est inopérante. La vérification documentée de la certification est une étape incontournable avant tout hébergement de données de santé.
5.3 Négliger la qualification de son activité
Le troisième piège est l’erreur de qualification. Il faut déterminer précisément si l’on doit être certifié, ou seulement recourir à un hébergeur certifié. La frontière dépend du rôle exact dans le traitement des données de santé. Un éditeur qui héberge pour ses clients peut devoir être certifié lui-même. Cette analyse juridique est essentielle. Une mauvaise qualification conduit à une non-conformité, même de bonne foi.
5.4 Sous-estimer la localisation et les transferts
Le quatrième piège est la localisation négligée. Pour des données de santé, héberger ou transférer hors de l’Union européenne crée un risque majeur. L’arrêt Schrems II impose des garanties strictes pour ces transferts. Beaucoup de contrats restent flous sur ce point. Il faut exiger une localisation dans l’UE et interdire tout transfert non autorisé. La sensibilité des données de santé rend ce point particulièrement critique.
5.5 Oublier l’AI Act pour l’IA médicale
Le cinquième piège, spécifique à 2026, concerne l’IA. De nombreuses solutions de santé intègrent une IA d’aide au diagnostic. Ces systèmes sont souvent classés à haut risque par l’AI Act. Ils sont alors soumis à des obligations strictes, en plus du HDS et du RGPD. Héberger une telle solution sans tenir compte de l’AI Act crée une non-conformité supplémentaire. L’articulation des trois cadres est devenue indispensable dans la santé numérique.
6. Pourquoi faire appel à Atias Avocats
Sécuriser un hébergement de données de santé exige une combinaison rare de compétences : maîtrise du droit de la santé (article L.1111-8 du Code de la santé publique, certification HDS), expertise du RGPD et des données sensibles (article 9, article 28, sécurité), pratique des contrats IT (DPA, SLA, réversibilité, responsabilité) et connaissance de l’AI Act pour l’IA médicale. Cette pluridisciplinarité, à la croisée du droit de la santé et du droit du numérique, est précisément la valeur ajoutée d’un cabinet spécialisé.
Atias Avocats accompagne startups de e-santé, éditeurs de logiciels médicaux, établissements de santé, DPO, DSI et fondateurs sur l’ensemble du sujet : analyse de l’obligation HDS et qualification de l’activité, rédaction ou revue du contrat d’hébergement, intégration du DPA et de l’annexe de sécurité, mise en conformité RGPD des données de santé, articulation avec l’AI Act, accompagnement en levée de fonds et appels d’offres de santé. Pour aller plus loin, consultez nos services en matière de protection des données personnelles.
Conclusion
L’hébergement de données de santé n’admet pas l’approximation. La certification HDS est une obligation légale qui se cumule avec le RGPD, et le manquement coûte cher : sanctions pénales, sanctions RGPD, perte de marchés, échec de levée de fonds. Les sept clauses présentées ici — certification, DPA, sécurité, localisation, disponibilité, réversibilité, responsabilité — combinées à la vigilance sur les cinq pièges classiques, offrent un référentiel directement utilisable par les acteurs de la santé numérique.
L’investissement requis pour sécuriser cette conformité est sans commune mesure avec le coût d’une non-conformité dans un secteur aussi surveillé. À l’heure de l’explosion de la e-santé et de l’IA médicale, l’hébergement HDS n’est pas une formalité technique : c’est la condition d’accès au marché et la garantie de la confiance des patients. Le réflexe à adopter est clair : qualifier son activité, vérifier la certification, cumuler RGPD et HDS, maîtriser la localisation et anticiper l’AI Act. C’est précisément cette rigueur qui transforme une contrainte réglementaire en avantage concurrentiel durable.
FAQ — Questions fréquentes
Qu’est-ce que l’hébergement HDS ?
L’hébergement HDS (Hébergeur de Données de Santé) désigne l’hébergement de données de santé à caractère personnel par un prestataire certifié. La certification HDS est une obligation légale prévue par l’article L.1111-8 du Code de la santé publique. Toute structure qui héberge des données de santé pour le compte de tiers (établissements de santé, éditeurs de logiciels médicaux, startups de la santé numérique) doit recourir à un hébergeur certifié HDS, ou être elle-même certifiée. La certification est délivrée par un organisme accrédité, après audit du respect d’un référentiel strict de sécurité. L’hébergement HDS garantit un niveau de protection renforcé pour ces données particulièrement sensibles. Recourir à un hébergeur non certifié pour des données de santé constitue un manquement grave, exposant à des sanctions pénales et administratives.
Quand la certification HDS est-elle obligatoire ?
La certification est obligatoire dès qu’une personne héberge des données de santé à caractère personnel pour le compte d’un tiers, dans le cadre d’une activité de soin, de diagnostic, de prévention ou de suivi médico-social. L’article L.1111-8 du Code de la santé publique pose ce principe. Concrètement, un éditeur de logiciel médical, une startup de e-santé, une plateforme de téléconsultation ou un établissement qui externalise son hébergement doivent s’assurer que l’hébergeur est certifié. L’hébergement HDS n’est en revanche pas exigé si la structure héberge ses propres données pour son propre compte, sans intervention pour un tiers. La frontière peut être subtile, d’où l’intérêt d’une analyse juridique. En cas de doute, mieux vaut sécuriser : le risque d’un hébergement non conforme est trop élevé.
Quelle différence entre HDS et RGPD ?
Le HDS et le RGPD sont complémentaires, pas alternatifs. Le RGPD (Règlement UE 2016/679) encadre tous les traitements de données personnelles, et classe les données de santé parmi les données sensibles (article 9), soumises à une protection renforcée. La certification HDS est une exigence française supplémentaire, propre à l’hébergement des données de santé, fixée par le Code de la santé publique. Autrement dit, héberger des données de santé impose de respecter à la fois le RGPD (licéité, sécurité, droits des personnes) et la certification HDS (référentiel d’hébergement). Un hébergement conforme suppose donc un contrat respectant l’article 28 du RGPD (DPA), une annexe de sécurité, et la preuve de la certification. Les deux cadres se cumulent et doivent être traités ensemble dans le contrat.
Contact : david@atiasavocats.com | LinkedIn: David Joseph Atias | https://www.atiasavocats.com | 42 rue de la Clef, 75005 Paris
Atias Avocats — RGPD, Données de santé, HDS, Contrats IT
