Cet article distingue trois choses souvent confondues : ce que la certification garantit, ce qu'elle laisse de côté, et les points à contrôler avant de confier des données de santé à un prestataire.

Certification HDS et conformité HDS : deux notions distinctes

La certification est un statut délivré à l'hébergeur après audit. La conformité, elle, est une obligation qui reste partagée entre l'hébergeur et son client. Confondre les deux conduit à une fausse sécurité : croire qu'externaliser chez un prestataire certifié suffit à couvrir l'ensemble de ses propres obligations.

Ce que porte l'hébergeur certifié

La certification est délivrée par un organisme accrédité, à l'issue d'un audit portant sur les six activités du référentiel HDS. Elle atteste que l'hébergeur maintient un niveau de sécurité défini pour héberger, exploiter et sauvegarder des données de santé à caractère personnel.

Ce qui reste à la charge du client

Utiliser un hébergeur certifié ne rend pas le client lui-même certifié. La certification demeure celle de l'hébergeur ; le client est mis en conformité sur le seul volet hébergement. Ses obligations applicatives et ses obligations au titre du RGPD restent les siennes. À cela s'ajoute une exigence propre au référentiel : l'hébergement de données de santé suppose la signature d'un contrat spécifique entre le client et l'hébergeur, qui formalise la répartition des responsabilités.

Ce que la certification atteste, et ce qu'elle ne couvre pas

Le périmètre des 6 activités : une certification partielle laisse des zones non couvertes

Le référentiel HDS distingue six activités, de la mise à disposition des sites physiques jusqu'à la sauvegarde externalisée, en passant par l'administration et l'exploitation du système d'information. Une offre peut n'être certifiée que sur une partie de ce périmètre, souvent les seules couches d'infrastructure. Dans ce cas, l'administration-exploitation ou la sauvegarde restent hors du champ certifié, et l'écart devient une charge de conformité pour le client. Vérifier l'étendue exacte de la certification, activité par activité, est donc un préalable, pas un détail.

La frontière entre sécurité de l'hébergement et souveraineté juridique

La certification atteste la sécurité technique et organisationnelle de l'hébergement. Elle ne dit rien de la question juridique : qui peut être légalement contraint de communiquer les données. Ce sont deux plans différents. Un hébergeur peut satisfaire aux exigences de sécurité du référentiel tout en restant soumis à une législation extra-européenne. La Cour des comptes le formule sans ambiguïté : à ce stade, le référentiel HDS ne comporte pas les exigences de souveraineté propres à la qualification SecNumCloud, en particulier le contrôle capitalistique et la protection contre les législations extraterritoriales. Un hébergeur certifié HDS n'est donc pas automatiquement immunisé contre ces lois.

Certification HDS et lois extraterritoriales (Cloud Act, FISA)

Ce que la réglementation HDS impose réellement

Le cadre s'est resserré début 2026. Le décret n° 2026-209 du 24 mars 2026, publié au Journal officiel le 26 mars et pris en application de l'article 32 de la loi SREN du 21 mai 2024, inscrit dans le code de la santé publique des obligations jusque-là portées par le seul référentiel de certification. Son nouvel article R. 1111-9-1 pose le principe d'un stockage des données de santé réalisé exclusivement sur le territoire d'un État membre de l'Union européenne ou partie à l'accord sur l'Espace économique européen (EEE). Un transfert vers un pays tiers, y compris sous la forme d'un accès distant, demeure possible, mais aux conditions du RGPD : décision d'adéquation de la Commission européenne ou, à défaut, garanties appropriées.

Le texte renforce également le contrat d'hébergement et l'information due au client. L'hébergeur doit y préciser les consultations à distance depuis des pays tiers, les législations extra-européennes susceptibles d'imposer une communication de données au sens de l'article 48 du RGPD, les mesures d'atténuation et les risques résiduels. Il crée enfin une obligation de transparence jusqu'alors absente : publier et tenir à jour une cartographie des transferts hors EEE, des accès distants et des risques d'accès non autorisé par des États tiers.

Ces dispositions structurantes n'entrent toutefois en vigueur que six mois après la publication, soit fin septembre 2026 ; les autres modifications s'appliquent depuis le lendemain du décret.

Ce que la certification HDS ne traite pas

Le risque extraterritorial lui-même. La réglementation oblige l'hébergeur à informer, pas à immuniser. Un hébergeur peut être certifié HDS, stocker en France, et rester atteignable par une loi extra-européenne lorsque sa maison mère y est soumise. La configuration de Microsoft Ireland l'illustre : l'entité dispose de la certification HDS et stocke en France, mais ne peut obtenir la qualification SecNumCloud du fait de son rattachement à un groupe soumis au droit américain. Stocker sur le territoire national est nécessaire, mais ne suffit pas à écarter l'exposition juridique.

Immunité juridique et souveraineté : deux exigences distinctes

Pour les données les plus sensibles (grandes bases de santé, données de mineurs, données d'infractions), la CNIL recommande de recourir soit à un hébergeur soumis exclusivement au droit européen, soit à un prestataire bénéficiant d'une qualification de type SecNumCloud, qui intègre un critère d'immunité aux lois extra-européennes.

Une nuance mérite d'être posée. La qualification apporte l'immunité juridique, mais elle peut coexister avec une dépendance technologique : certaines offres qualifiées reposent sur des composants américains exploités sous licence. La souveraineté ne se déduit donc pas d'un seul label ; elle tient aussi à la structure capitalistique du prestataire et à l'origine de sa technologie.

Cette recommandation vise les traitements les plus sensibles. Recourir à un hébergeur HDS non souverain reste, en dehors de ces cas, autorisé : la CNIL indique qu'aucune sanction n'a été prononcée au seul motif du recours à un hébergeur non souverain. Le bon réflexe n'est pas de trancher par principe, mais d'évaluer le risque au regard de la sensibilité des données traitées.

Vérifier la conformité réelle d'un hébergeur

Validité du certificat et accréditation

Un certificat expiré, en cours de renouvellement, ou délivré par un organisme non accrédité n'offre pas la garantie attendue. Deux vérifications simples : le certificat est-il en cours de validité, et l'organisme qui l'a délivré est-il accrédité COFRAC pour le référentiel HDS. Le statut d'un hébergeur est par ailleurs consultable au registre officiel des hébergeurs certifiés tenu par l'Agence du numérique en santé.

Localisation du stockage et des opérations

Le stockage en France est nécessaire, mais ne referme pas à lui seul le risque. Un accès distant, pour l'administration ou l'exploitation, depuis un pays tiers rouvre l'exposition même lorsque les données restent stockées sur le territoire. La bonne question à poser au fournisseur porte donc sur les deux plans : où sont stockées les données, et depuis quel pays, par quelles équipes, la plateforme est-elle administrée.

Réversibilité et transparence des transferts

L'absence de réversibilité crée une dépendance technique qui peut empêcher une mise en conformité ultérieure, par exemple une migration imposée vers une solution souveraine. Sur la transparence, la cartographie des transferts hors EEE que la réglementation rend obligatoire constitue un point de contrôle direct : son absence est un signal d'alerte.

Ces points peuvent se contrôler de façon structurée, à l'aide de notre grille des dix points à vérifier sur la souveraineté d'un hébergeur HDS. 

Le positionnement de Clever Cloud

Clever Cloud est certifié HDS sur l'intégralité du périmètre du référentiel. Sur le volet extraterritorial, notre garantie ne repose pas sur une qualification SecNumCloud détenue en propre, mais sur la voie du statut juridique : capital et siège français, aucune filiale aux États-Unis, hébergement et opérations réalisés en France, et engagement de ne transférer aucune donnée de santé hors de l'Espace économique européen. Cette configuration place l'entreprise sous la seule application du droit européen.

FAQ

La certification HDS protège-t-elle du Cloud Act ?

Non. La certification atteste la sécurité de l'hébergement des données de santé. Elle n'a pas pour objet l'immunité face aux lois extraterritoriales. Un hébergeur certifié peut rester soumis à une législation extra-européenne selon sa structure capitalistique.

Un hébergeur certifié HDS peut-il être soumis au droit américain ?

Oui, lorsque sa maison mère relève du droit américain. Une entité peut détenir la certification HDS et stocker en France tout en restant atteignable par le Cloud Act ou le FISA.

Les données de santé doivent-elles obligatoirement être stockées en France ?

Non. Le référentiel HDS et le décret n° 2026-209 du 24 mars 2026 imposent un stockage exclusivement au sein de l'Espace économique européen (l'Union européenne, plus la Norvège, l'Islande et le Liechtenstein) et non sur le seul territoire français. Cette règle est codifiée à l'article R. 1111-9-1 du code de la santé publique. Un accès distant depuis un pays tiers reste possible, mais aux conditions du chapitre V du RGPD (décision d'adéquation ou garanties appropriées), et il doit être porté à la connaissance du client dans le contrat d'hébergement. Un hébergement situé en France relève donc d'un engagement contractuel du prestataire, non d'une obligation réglementaire.

Être hébergé chez un prestataire certifié me rend-il « conforme HDS » ?

Non. La certification reste celle de l'hébergeur. Le client est mis en conformité sur le seul volet hébergement ; ses obligations applicatives et RGPD demeurent, de même que la signature d'un contrat d'hébergement spécifique.

HDS et SecNumCloud : quelle différence ?

La certification HDS est obligatoire pour héberger des données de santé et atteste la sécurité de cet hébergement. La qualification SecNumCloud, délivrée par l'ANSSI, est volontaire et intègre notamment un critère d'immunité aux lois extra-européennes. Le référentiel HDS ne comporte pas, à ce jour, les exigences de souveraineté propres à SecNumCloud.

Reste à savoir quand une telle opération s'impose, comment elle se déroule et quels écueils l'accompagnent.

Qu'est-ce qu'une migration HDS ?

Une migration HDS n'est pas un simple changement d'infrastructure : elle déplace des données de santé à caractère personnel, dont l'hébergement est encadré par la loi. L'enjeu tient en une phrase : changer de prestataire sans sortir du périmètre de conformité, ni pendant le transfert, ni après.

La certification, elle, reste portée par l'hébergeur, au titre du référentiel HDS et de ses six activités. Migrer ne remet pas cette conformité en cause : l'enjeu est de la préserver d'un hébergement à l'autre.

Quand faut-il envisager une migration HDS ?

Trois situations justifient de changer d'hébergement pour des données de santé.

Un hébergement non certifié HDS

En France, confier ses données de santé à un hébergeur suppose que ce dernier soit certifié HDS (article L.1111-8 du Code de la santé publique). Une application e-santé installée sur une infrastructure non certifiée se situe alors hors de ce cadre, quelle que soit sa qualité technique. La migration vers un prestataire certifié répond à cette exigence sur le volet hébergement, sans lever à elle seule les autres obligations de l'éditeur, applicatives ou RGPD.

Un hébergement non souverain ou exposé aux lois extraterritoriales

Certification et souveraineté juridique ne se confondent pas. Un hébergeur peut être certifié HDS tout en restant soumis à une législation extra-européenne susceptible d'imposer la communication de données, comme le Cloud Act ou le FISA. Pour les données de santé les plus sensibles, la CNIL recommande une protection renforcée contre les accès des autorités de pays tiers, notamment un hébergement placé exclusivement sous droit européen. La distinction entre conformité HDS et souveraineté mérite un examen à part entière ; à l'échelle d'une migration, elle se traduit surtout par un critère de choix de l'hébergeur.

Une charge d'exploitation trop lourde sur infrastructure auto-gérée

Une infrastructure conforme mais administrée en interne (typiquement du bare-metal) fait peser sur les équipes la configuration serveur, la supervision, les montées de version et la réversibilité. À mesure que la plateforme grandit, cette charge devient structurante. Elle pousse des éditeurs déjà conformes HDS à rejoindre une offre managée : alléger le temps consacré à l'exploitation sans renoncer à la conformité.

Les points de vigilance d'une migration HDS

Cinq pièges reviennent régulièrement. Chacun mérite une question posée au futur hébergeur.

Comment choisir son hébergeur pour une migration HDS ?

Cinq critères permettent de trancher :

• une certification couvrant les six activités du référentiel, pas seulement l'infrastructure ;
• un certificat délivré par un organisme accrédité et en cours de validité ;
• une souveraineté réelle : capital et siège en France, absence de filiale sous droit tiers, hébergement sur le territoire ;
• une plateforme managée de bout en bout, qui prend en charge chiffrement, supervision, sauvegardes et mises à jour, plutôt que de les laisser au client ;
• une réversibilité documentée, garantissant une sortie sans dépendance technique.

Le dernier critère mérite attention : une plateforme qui opère un cloud HDS de bout en bout décharge le client des couches d'exploitation où se logent la plupart des écarts de conformité.

Retour d'expérience : la migration de Madietenligne

Clever Cloud accompagne plusieurs acteurs de l'e-santé. La migration de Madietenligne, plateforme dédiée aux diététiciens, en offre un exemple documenté : passée d'un hébergement bare-metal auto-géré au PaaS souverain de Clever Cloud, sans quitter le cadre HDS. Le cas illustre le motif de l'allègement d'exploitation, et non un passage de non-conforme à conforme : le référentiel était déjà respecté avant la bascule.

Faits marquants :

• migration des environnements de test et de production en moins de quinze jours ;
• 500 Go transférés et synchronisés ;
• plateforme utilisée par plus de 2 500 diététiciens ;
• déploiements sans downtime, support répondant dans la journée ;
• conformité HDS maintenue, chiffrement au repos activé, et sortie d'Azure pour le stockage de fichiers, qui retire une dépendance à un acteur sous droit américain.

Ce qu'il faut retenir d'une migration HDS

Une migration HDS bien conduite répond à trois questions dans l'ordre : pourquoi migrer, comment procéder, comment vérifier. Le déroulé se maîtrise, l'interruption se réduit à la bascule DNS, et la conformité se contrôle à chaque étape.

Pour évaluer votre situation ou préparer votre projet

FAQ

Combien de temps prend une migration HDS ?

La durée dépend du volume, de l'architecture et du nombre d'environnements. À titre de repère, un projet documenté portant sur les environnements de test et de production s'est déroulé en moins de quinze jours. Ce chiffre vaut pour ce cas et ne préjuge pas d'un autre contexte.

Une migration HDS coupe-t-elle le service ?

Tant que l'ancien et le nouvel hébergement coexistent, le service reste actif. Le seul moment d'interruption possible est la bascule DNS ; bien préparée, elle passe inaperçue côté utilisateurs.

Faut-il un nouveau contrat pour migrer en HDS ?

Oui. L'hébergement de données de santé exige un contrat spécifique avec l'hébergeur, prévu par le référentiel. Il doit être signé avant la mise en production. 

Après la migration, qu'est-ce qui reste à ma charge pour être conforme HDS ?

La certification reste portée par l'hébergeur. L'éditeur, lui, demeure responsable de la conformité de son application et du respect du RGPD : la migration met en conformité le volet hébergement, pas l'ensemble des obligations.

Peut-on migrer depuis un hébergeur non souverain (Azure, AWS) ?

Oui. Une migration peut précisément viser à retirer une dépendance à un hébergeur soumis à une législation extra-européenne, par exemple en quittant un stockage de fichiers opéré par un fournisseur non européen.