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é.
Comment se déroule une migration HDS, étape par étape ?
Le projet suit cinq phases, du cadrage à la vérification finale.
Cadrage et audit préalable
Avant tout transfert, il faut délimiter le périmètre : quelles données de santé sont concernées, quelles applications les traitent, où se trouvent les sauvegardes. Cette étape détermine les activités du référentiel réellement mobilisées et les exigences de localisation à tenir, copies de secours comprises.
Contractualisation HDS
L’hébergement de données de santé suppose la signature d’un contrat spécifique entre le client et l’hébergeur. Il s’agit d’une exigence du référentiel, non d’une formalité commerciale : ce document fixe la répartition des responsabilités et doit être en place avant la mise en production.
Transfert et synchronisation des données
Vient l’opération centrale : copie puis synchronisation des données, déploiement des applications, remise en place des tâches planifiées et de la supervision. Le chiffrement au repos (encryption at rest) s’active à la création des bases et des espaces de stockage. Selon l’infrastructure de départ, cette phase peut aussi imposer d’adapter des formats de fichiers hérités d’un stockage tiers.
La bascule DNS, seule interruption possible
Tant que l’ancienne et la nouvelle plateforme coexistent, le service continue de fonctionner sur la première. Le basculement du DNS vers le nouvel hébergement constitue le seul moment où une interruption est possible. Correctement préparé, il reste imperceptible côté utilisateurs.
Vérification de conformité post-migration
L’opération ne s’achève pas au basculement. Il reste à contrôler que le périmètre certifié couvre bien l’ensemble déployé, que les sauvegardes suivent les mêmes règles de localisation que les données primaires, et que la réversibilité demeure garantie.
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.
-
01
01 Périmètre partiellement certifié
Certaines offres ne couvrent qu’une partie des six activités du référentiel, souvent les seules couches d’infrastructure. Une couverture incomplète laisse des zones hors conformité à la charge du client.
0202 Localisation des sauvegardes
Une donnée primaire hébergée en France mais sauvegardée ailleurs déplace le risque sans le résoudre. Les copies doivent respecter les mêmes exigences que les données d’origine.
0303 Accès distant depuis un pays tiers.
Même stockées en France, des données restent exposées si la plateforme est administrée depuis un pays soumis à une législation extra-européenne. Le référentiel oblige l’hébergeur à informer son client dans ce cas.
0404 Réversibilité
L’incapacité à récupérer l’intégralité de ses données dans un format exploitable crée un verrouillage, qui peut empêcher une mise en conformité ultérieure.
0505 Frontière de responsabilité
Recourir à un hébergeur certifié ne rend pas le client lui-même certifié HDS. La conformité applicative et RGPD reste de son ressort.
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é.
Checklist, étapes, erreurs fréquentes et critères de choix d’hébergeur. Retrouvez ces éléments dans notre Guide pratique de la migration HDS.
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.
Blog
À lire également
Migration HDS : migrer vos données de santé sans interruption perceptible
Une migration HDS consiste à transférer une application et ses données de santé d'un hébergement vers un autre, tout en conservant la certification requise et la continuité du service. Menée avec méthode, l'interruption perçue peut se réduire à une simple bascule DNS : par exemple, lors du passage de Madietenligne, éditeur d'une solution e-santé pour diététiciens, vers Clever Cloud, les environnements de test et de production ont migré en moins de quinze jours, pour un volume de 500 Go, sans coupure perçue par les utilisateurs.Gravitee et Clever Cloud annoncent un partenariat stratégique pour la souveraineté de l’IA en Europe.
Gravitee et Clever Cloud proposent un control plane open source et déployable partout, garantissant que l'IA européenne fonctionne strictement selon vos conditions.Magnetar : un client Apache Pulsar en Rust conçu pour la simulation déterministe
Une partie importante de la fiabilité des systèmes distribués commence par une idée simple : si un système peut échouer en production à cause du temps, de l'ordonnancement, du réseau ou d'un interval malchanceux, alors ces forces doivent pouvoir être amenées dans les tests sous contrôle.