Hébergement HDS : ce qu'une application de santé doit respecter en 2026

Si votre application conserve des données de santé de patients pour le compte de professionnels, d'établissements de santé ou des patients eux-mêmes, elle doit être hébergée par un hébergeur certifié HDS. Au plus tard depuis le 26 septembre 2026, ces données doivent en plus être stockées dans l'Union européenne ou l'Espace économique européen. Le vrai travail n'est pas de choisir un cloud « HDS » : c'est de vérifier que les certificats couvrent toute la chaîne, de la salle machine à la sauvegarde, y compris ce que fait votre éditeur ou votre prestataire de développement.

Cet article s'adresse au dirigeant qui lance ou fait développer une application de santé : prise de rendez-vous, suivi de patients, téléservice, logiciel pour un centre de soins, SaaS pour des professionnels de santé. Il fait le point au 7 novembre 2026 à partir des textes officiels. Il ne remplace pas l'avis d'un juriste spécialisé, indispensable dès que le périmètre de votre projet est ambigu.

Les textes qui font foi

Trois sources, à lire dans cet ordre :

• l'article L1111-8 du code de la santé publique, en vigueur depuis le 1^er juillet 2025, qui pose l'obligation ;
• les articles R1111-9 à R1111-11, qui définissent les activités d'hébergement et le contenu du contrat, modifiés par le décret n° 2026-209 du 24 mars 2026 ;
• le référentiel de certification de l'Agence du numérique en santé (ANS), qui décrit les exigences auditées, et la liste des hébergeurs certifiés.

Beaucoup d'articles en ligne datent d'avant le décret de mars 2026 ou confondent l'ancien agrément et la certification actuelle. En cas de doute, le texte de Légifrance prime.

Êtes-vous concerné ? Les trois questions à se poser

L'obligation tient en une phrase de l'article L1111-8 : 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 de ceux qui les produisent ou du patient lui-même, doit être certifiée. D'où trois questions.

1. S'agit-il de données de santé ? La CNIL en donne une définition large dans sa fiche Qu'est-ce qu'une donnée de santé : données de santé par nature (antécédents, traitements, résultats d'examens), par croisement avec d'autres données (un poids croisé avec une activité physique), ou par leur destination médicale.

2. Ont-elles été recueillies dans un contexte de soins ou de prévention ? C'est ce qui fait entrer dans le champ HDS. Le compte rendu d'un médecin, le suivi d'un patient par une infirmière, une téléconsultation : oui. Une application de course à pied grand public, sans professionnel de santé : en général non, même si ses données restent des données de santé au sens du RGPD.

3. Les hébergez-vous pour le compte de quelqu'un d'autre ? Un cabinet qui garde ses dossiers sur son propre serveur, dans ses locaux, n'héberge pas pour un tiers. Un éditeur qui stocke dans son SaaS les dossiers de ses clients médecins, si.

Les cas « à faire trancher » existent vraiment : arrêts de travail, données de la médecine du travail, mutuelles, prévention en entreprise. Pour eux, une consultation écrite d'un juriste coûte bien moins cher qu'une architecture à refaire.

Les six activités : pourquoi « mon cloud est HDS » ne suffit pas

L'article R1111-9 découpe l'hébergement en six activités. Un hébergeur est certifié pour certaines d'entre elles, pas forcément pour toutes.

La certification d'hébergeur d'infrastructure physique couvre la première activité ; celle d'hébergeur infogéreur couvre les suivantes. Un grand fournisseur cloud certifié sur les activités 1 à 4 ne couvre donc pas, par principe, l'administration de votre application ni vos sauvegardes externalisées.

Le point délicat est l'activité 5. L'ANS a publié un guide d'accompagnement sur cette activité (webinaire de présentation), parce que la frontière entre « administrer le système d'information » et « maintenir une application » fait débat. Retenez la méthode plutôt qu'une règle simpliste :

1. listez chaque intervenant qui touche à la production (cloud, éditeur, infogéreur, prestataire de développement, outil de sauvegarde) ;
2. pour chacun, notez les activités qu'il exerce réellement ;
3. vérifiez, sur les certificats et la liste de l'ANS, que chaque activité est couverte par quelqu'un de certifié ;
4. faites valider la cartographie par votre juriste ou par l'organisme certificateur.

Selon la page de l'ANS sur la certification, le certificat est délivré pour trois ans par un organisme certificateur accrédité, avec un audit de surveillance chaque année. Demandez le certificat en vigueur, pas une plaquette commerciale.

Ce que le décret du 24 mars 2026 a changé

Le décret n° 2026-209 applique la loi du 21 mai 2024 visant à sécuriser et réguler l'espace numérique. Il est entré en vigueur au lendemain de sa publication, sauf deux points de son article 1^er applicables six mois après, soit le 26 septembre 2026 : vérifiez sur Légifrance la date qui s'attache à chaque obligation. Trois changements concernent directement un éditeur.

• Stockage dans l'UE ou l'EEE. Le nouvel article R1111-9-1 impose que le stockage des données de santé hébergées se fasse exclusivement sur le territoire d'un État membre de l'Union européenne ou partie à l'accord sur l'Espace économique européen.
• Transferts et accès à distance encadrés. Un transfert hors de cette zone, y compris un simple accès à distance (un support technique situé hors d'Europe, par exemple), n'est possible qu'avec une décision d'adéquation de la Commission européenne ou, à défaut, des garanties appropriées au sens du RGPD. Le contrat doit alors le dire et décrire ces garanties.
• Transparence sur les lois étrangères. Si l'hébergeur ou l'un de ses sous-traitants est soumis au droit d'un pays tiers, le contrat doit lister les règles qui pourraient imposer un transfert ou un accès non autorisé, les mesures prises et les risques résiduels. L'hébergeur doit aussi publier une cartographie de ces transferts et de ces risques.

Ce dernier point vise directement les fournisseurs soumis à des lois extraterritoriales. Le décret ne les interdit pas, mais il oblige à écrire noir sur blanc le risque. Pour un éditeur qui vend à des hôpitaux ou à des collectivités, cette transparence pèse désormais dans le choix de l'hébergeur. Notre article sur l'hébergement d'une application métier en France ou en Europe compare aussi les options SecNumCloud.

Le contrat d'hébergement : les clauses obligatoires

L'article R1111-11 liste ce que le contrat entre l'hébergeur et son client doit contenir au minimum. Les plus importantes pour un dirigeant :

• le périmètre du certificat de l'hébergeur et ses dates ;
• la localisation de l'hébergement ;
• les indicateurs de qualité et niveaux de service, avec d'éventuelles pénalités ;
• le recours à des prestataires techniques externes ;
• l'interdiction d'utiliser les données à d'autres fins que l'hébergement ;
• la réversibilité, la restitution des données en fin de contrat et leur destruction sans copie, y compris en cas de perte de certification ;
• depuis septembre 2026, les transferts hors UE et EEE et les lois étrangères applicables.

Si vous êtes éditeur et que vous vous appuyez sur un hébergeur certifié, le II du même article vous oblige à reprendre ces clauses dans votre propre contrat avec vos clients. Concrètement, vos conditions générales ou votre contrat SaaS doivent refléter ce que garantit votre hébergeur. Notre article sur les clauses d'un contrat SaaS et celui sur la réversibilité détaillent ces points.

Ce que l'hébergement HDS ne règle pas

La certification porte sur l'hébergeur. Elle ne rend pas votre application conforme à elle seule. Restent à votre charge, notamment :

• le RGPD : base légale, information des patients, registre, durées de conservation, droits des personnes. Les données de santé sont des données sensibles, et une analyse d'impact (AIPD) est souvent requise : vérifiez la liste publiée par la CNIL. Notre check-list RGPD pour une application métier sert de point de départ ;
• la sécurité applicative : gestion des droits par rôle, journalisation des accès, chiffrement, tests d'intrusion. Un hébergeur certifié ne protège pas une application qui laisse un patient lire le dossier d'un autre ;
• les copies oubliées : journaux techniques, outil de suivi des erreurs, messagerie, support client, environnement de test alimenté avec de vraies données. Chacune de ces copies est hébergée quelque part.

Pour la partie applicative, notre article sur la sécurité d'une application métier liste les contrôles de base.

Les erreurs les plus fréquentes

• Croire que le cloud certifié couvre tout. C'est l'erreur numéro un : les activités 5 et 6 sont souvent exercées par l'éditeur ou un tiers.
• Envoyer des données de santé dans des outils annexes. Un outil de support, d'envoi d'e-mails ou de suivi d'erreurs qui reçoit le contenu d'un dossier devient un maillon de la chaîne.
• Tester avec de vraies données. Un environnement de recette alimenté par une copie de la production doit être aussi protégé que la production, ou utiliser des données fictives.
• Oublier les accès à distance. Depuis le décret de 2026, un développeur ou un support hors d'Europe qui peut lire les données relève des règles de transfert.
• Signer sans vérifier le certificat. Demandez le certificat, son périmètre d'activités et sa date de validité, et recoupez-le avec la liste de l'ANS.
• Décider trop tard. Migrer une application en production vers un hébergeur certifié coûte plus cher que de la concevoir pour lui dès le départ.

Combien cela coûte, et ce qui fait varier le budget

Nous ne publions pas de grille de prix : les offres d'hébergement certifié varient trop selon l'architecture, et aucune source officielle ne donne de référence. Ce qui fait réellement varier le budget :

• le niveau de service géré : une base de données managée certifiée coûte plus cher qu'une machine virtuelle, mais vous évite d'exercer vous-même une activité certifiable ;
• l'exploitation : qui administre la production, et avec quelle astreinte ;
• les sauvegardes et l'archivage, désormais explicitement dans le périmètre ;
• la conformité du reste de la chaîne : outils de support, de messagerie et de supervision compatibles.

Demandez au moins deux devis d'hébergeurs certifiés sur la même architecture, avec le même niveau de service. Notre article sur le prix d'une application métier sur mesure aide à situer la part de l'hébergement dans le coût total.

Faut-il faire développer, ou acheter un logiciel du marché ?

Si un logiciel de santé du marché, déjà hébergé chez un hébergeur certifié, couvre votre besoin, il vous évite de porter vous-même la chaîne d'hébergement : c'est souvent le bon choix pour un cabinet ou un établissement. Le développement sur mesure se justifie quand votre parcours de soins, votre organisation ou votre modèle de service ne rentrent pas dans ces produits, ou quand vous êtes vous-même éditeur d'un service de santé.

Dans ce cas, posez les questions d'hébergement avant d'écrire une ligne de code : quelles données, pour le compte de qui, quel hébergeur, qui administre la production, quelles copies. Un prototype permet de valider le parcours métier avec des données fictives, sans rien héberger de réel. C'est le principe de notre prototype gratuit présenté avant tout engagement : vous voyez l'application avant de décider où, et chez qui, elle tournera.