Six semaines de préparation pour quatre heures de coupure réelle, programmée un dimanche matin : c’est le rapport de force qu’a imposé la migration d’un site hospitalier vers un hébergeur HDS (hébergeur de données de santé), après que le prestataire précédent a perdu sa certification faute de renouvellement. La direction de la communication de l’établissement n’avait posé qu’une seule question avant toute considération technique : quelle durée d’indisponibilité fallait-il annoncer aux patients ?
Les critères de choix d’un hébergeur HDS ayant déjà été détaillés en amont sur ce blog, ce retour se concentre exclusivement sur le déroulé réel de la migration une fois le nouvel hébergeur sélectionné, avec les écueils propres au secteur santé qui ne se lisent dans aucune documentation générique de migration de site.
Pourquoi la migration ne pouvait pas attendre
Le site en question ne traite pas de données de santé identifiantes à proprement parler dans son contenu public, mais héberge un espace patient avec prise de rendez-vous et formulaires de pré-admission, suffisant pour tomber sous le régime de la certification HDS. La perte de cette certification chez l’hébergeur précédent créait un risque de non-conformité immédiat, sans marge de manœuvre pour une migration progressive étalée sur plusieurs mois.
Préparer la migration : six semaines, pas six jours
La première leçon de cette migration concerne le temps de préparation nécessaire, largement sous-estimé au départ par toutes les parties prenantes. Six semaines ont été nécessaires pour : auditer le contrat du nouvel hébergeur clause par clause, cartographier l’ensemble des flux de données entrants et sortants du site, et surtout coordonner un créneau de bascule compatible avec les contraintes d’astreinte de l’établissement.
- Audit contractuel du nouvel hébergeur, au-delà de la seule certification affichée
- Cartographie complète des flux de données (formulaires, intégrations tierces, sauvegardes)
- Coordination avec les équipes d’astreinte hospitalière pour caler la fenêtre de coupure
- Test de restauration complet sur l’infrastructure cible avant la bascule réelle
Le piège de la certification affichée sans vérification contractuelle
Un hébergeur certifié HDS ne l’est jamais dans l’absolu : la certification porte sur un périmètre précis de services, documenté dans son certificat officiel. Le premier écueil rencontré a été la découverte que l’offre initialement proposée par le nouveau prestataire ne couvrait pas, dans son périmètre certifié, le service de sauvegarde externalisée envisagé, nécessitant une renégociation contractuelle avant de poursuivre.
Cette vérification, réalisée en croisant le certificat HDS officiel du prestataire avec le détail précis des services souscrits, a permis d’éviter une non-conformité qui serait restée invisible jusqu’au prochain audit du client, potentiellement des mois plus tard.
La fenêtre de bascule, contrainte par le rythme hospitalier
Contrairement à un site vitrine classique où une coupure nocturne suffit généralement à limiter l’impact, un établissement de santé fonctionne en continu. Le créneau retenu, un dimanche matin entre 6 heures et 10 heures, a été choisi en concertation directe avec les équipes d’astreinte, pour s’assurer qu’aucune procédure de prise de rendez-vous urgent ne dépende du site pendant la fenêtre de bascule.
Déroulé de la fenêtre de coupure
- Gel des écritures sur le site source, message de maintenance affiché
- Synchronisation finale de la base de données vers l’infrastructure cible
- Bascule DNS avec un TTL préalablement abaissé plusieurs jours à l’avance
- Vérification fonctionnelle complète sur l’infrastructure cible avant réouverture
- Levée du message de maintenance et surveillance renforcée les 48 heures suivantes
Sur une migration en secteur santé, nous ne validons jamais une bascule sur la seule base d’un test technique réussi : la validation fonctionnelle par une personne du service concerné, qui connaît les usages réels du formulaire de pré-admission, reste indispensable avant de lever le message de maintenance.
Documenter pour l’audit suivant, pas seulement pour la migration
Un point souvent négligé une fois la migration terminée : la documentation produite pendant cette phase (cartographie des flux, preuves de test de restauration, échanges contractuels avec l’hébergeur) constitue une pièce essentielle pour le prochain audit de conformité du client. Nous avons livré un dossier de migration complet, distinct de la documentation technique courante, pensé spécifiquement pour cet usage.
Notre retour d’expérience en synthèse
La migration technique proprement dite, une fois la préparation achevée, s’est déroulée sans incident notable dans la fenêtre des quatre heures prévues. La vraie difficulté de ce type de projet ne réside jamais dans le transfert des fichiers ou de la base de données, mais dans la coordination contractuelle et organisationnelle propre au secteur santé, largement sous-estimée si l’on se contente de suivre une checklist de migration générique.
