300 praticiens répartis sur douze sites géographiques, tous connectés à la même plateforme WordPress de gestion de rendez-vous et de dossiers administratifs liés aux patients : ce volume change fondamentalement l’architecture à prévoir par rapport à un cabinet médical isolé. La certification d’hébergement de données de santé (HDS) impose un cadre réglementaire précis, mais elle ne dit rien de la manière d’organiser le réseau, les sauvegardes et les accès à cette échelle — c’est ce que nous avons dû concevoir.
Un malentendu fréquent consiste à croire que choisir un hébergeur certifié HDS suffit à rendre l’ensemble de l’architecture conforme. En réalité, la certification de l’hébergeur couvre l’infrastructure physique et une partie de l’organisationnel, mais la conception applicative — comment les données transitent, où elles sont mises en cache, qui y accède et comment — reste entièrement de la responsabilité du prestataire qui construit la plateforme.
Séparer les flux réseau par nature de donnée
La plateforme distingue trois catégories de flux, chacune isolée sur un sous-réseau dédié : les données administratives de rendez-vous (nom, créneau, praticien), qui transitent sur un réseau applicatif standard ; les échanges contenant des éléments de dossier médical résumé, chiffrés de bout en bout et transitant sur un réseau séparé avec des règles de pare-feu distinctes ; et les flux de supervision technique (logs, métriques), qui ne doivent jamais contenir de donnée patient et sont filtrés en amont pour le garantir.
Architecture réseau retenue
Internet
|
v
[ Pare-feu applicatif (WAF) ]
|
v
[ Répartiteur de charge - TLS 1.3 obligatoire ]
|
+-- [ Frontal web x4 - PHP-FPM ] -- reseau applicatif standard
| |
| v
| [ Cache Redis dedie - donnees non sensibles uniquement ]
|
+-- [ API dossiers resumes - reseau isole VLAN sante ]
|
v
[ Base de donnees primaire - chiffrement au repos AES-256 ]
|
v
[ Replica de secours - datacenter secondaire certifie HDS ]
Le chiffrement au repos ne suffit pas seul
Le chiffrement au repos de la base de données est une exigence de base, mais à cette échelle, la vraie difficulté porte sur le cache applicatif. Le cache Redis utilisé pour accélérer l’affichage des plannings ne doit jamais contenir de fragment de donnée médicale, même temporairement : la plateforme a été revue pour que les objets mis en cache soient strictement limités aux créneaux disponibles et aux informations de praticien, jamais aux notes ou aux résumés de consultation, qui restent systématiquement lus depuis la base chiffrée sans passer par le cache.
Gestion des accès à 300 praticiens
- Chaque praticien dispose d’un compte individuel avec authentification à deux facteurs obligatoire, sans exception, y compris pour les comptes de remplaçants temporaires.
- Les accès sont journalisés avec horodatage et identifiant, conservés vingt-quatre mois conformément aux exigences de traçabilité applicables aux hébergeurs de données de santé.
- Un compte inactif depuis plus de quatre-vingt-dix jours est automatiquement désactivé, avec réactivation manuelle validée par le référent sécurité du cabinet.
Sauvegardes : chiffrées, testées, elles-mêmes certifiées
Les sauvegardes constituent souvent le maillon oublié de ce type d’architecture : une base de données chiffrée au repos, mais dont les sauvegardes transitent en clair vers un stockage tiers non certifié, annule une bonne partie de l’effort de conformité. Sur cette plateforme, les sauvegardes sont chiffrées avant leur transfert, stockées sur un second site également certifié HDS, et restaurées intégralement une fois par trimestre dans un environnement isolé pour vérifier qu’elles sont effectivement exploitables, pas seulement présentes.
Plan de reprise d’activité dimensionné au volume
Avec trois cents praticiens dépendant quotidiennement de la plateforme pour gérer leurs rendez-vous, une indisponibilité prolongée a un impact opérationnel direct sur l’activité de soin. Le plan de reprise retenu vise un temps de rétablissement inférieur à quatre heures, avec bascule automatique vers le replica du datacenter secondaire en cas de défaillance confirmée du site primaire, testée deux fois par an en conditions réelles avec l’équipe du cabinet informée à l’avance.
Une architecture conforme HDS n’est jamais un état figé obtenu une fois pour toutes ; c’est une organisation qui doit continuer à séparer correctement les flux à mesure que la plateforme grossit et que de nouveaux usages s’y ajoutent.
Notre verdict
À l’échelle de trois cents praticiens, la conformité HDS se joue moins dans le choix du certificat d’hébergement que dans la discipline de conception applicative : séparation stricte des flux selon la sensibilité des données, cache limité aux informations non sensibles, et sauvegardes traitées avec la même rigueur que les données de production elles-mêmes.
