Site médical sécurisé : TLS, sauvegardes et disponibilité

Quand un patient visite votre site et tente de vous contacter ou de prendre rendez-vous, il fait confiance à votre infrastructure numérique pour protéger ses données. Cette confiance repose sur des fondations techniques précises. La page sur l’hébergement conforme d’un site médical pose le cadre réglementaire ; voici les exigences techniques qui le concrétisent.

Le certificat TLS : le minimum non négociable

Le protocole HTTPS (HTTP Secure) chiffre les échanges entre le navigateur du visiteur et le serveur du site grâce à un certificat TLS (Transport Layer Security). Sans ce chiffrement, toute donnée transmise via un formulaire de contact ou une prise de rendez-vous circule en clair sur le réseau et peut être interceptée par un tiers malveillant. La CNIL considère l’absence de HTTPS comme un manquement à l’obligation de sécurité de l’article 32 du RGPD, qui impose de mettre en œuvre des mesures techniques appropriées pour garantir un niveau de sécurité adapté au risque. Pour un site médical, il s’agit d’une exigence absolue dès la mise en ligne, sans exception.

Les certificats TLS sont désormais gratuits (via l’autorité de certification Let’s Encrypt) et pris en charge par la quasi-totalité des hébergeurs modernes. Vérifiez que votre certificat est valide — un cadenas fermé s’affiche dans la barre d’adresse du navigateur — et qu’il se renouvelle automatiquement sans intervention manuelle de votre part. Un certificat expiré déclenche des avertissements de sécurité bloquants dans les navigateurs, ce qui éloigne les visiteurs et signale une infrastructure peu entretenue. Par ailleurs, depuis 2021, Google pénalise activement les sites en HTTP dans son classement, ce qui représente une double conséquence : juridique et pratique. Les données du formulaire de contact, dont les implications sont détaillées dans notre page sur le formulaire de contact sur un site médical, ne doivent jamais transiter en clair.

Sur le plan technique, il convient également de s’assurer que la version du protocole TLS utilisée est à jour. Les versions TLS 1.0 et TLS 1.1 sont considérées comme obsolètes et présentent des vulnérabilités connues. Un hébergeur sérieux propose TLS 1.2 au minimum, et idéalement TLS 1.3, qui offre de meilleures performances et une sécurité renforcée.

Les sauvegardes : fréquence, stockage et tests

Une sauvegarde qui n’a jamais été testée est une sauvegarde dont on ne peut pas garantir l’efficacité. L’article 32 du RGPD impose des mesures permettant de « rétablir la disponibilité des données à caractère personnel et l’accès à celles-ci dans des délais appropriés en cas d’incident physique ou technique ». Pour un site médical, cela implique des sauvegardes quotidiennes au minimum, stockées sur un support distinct du serveur principal.

La règle dite du 3-2-1 constitue la référence en la matière : trois copies des données, sur deux supports différents, dont une copie conservée hors site (sur un serveur distant ou dans un espace de stockage en nuage séparé). Cette règle est recommandée par l’ANSSI et protège contre les scénarios les plus courants : défaillance matérielle, ransomware affectant le serveur principal, sinistre physique dans le datacenter. Le délai de rétablissement après incident (RTO — Recovery Time Objective) et le volume de données acceptable en cas de perte (RPO — Recovery Point Objective) doivent être définis, documentés et intégrés au registre des traitements RGPD. Un hébergeur certifié HDS doit intégrer ces engagements dans son contrat de service et être en mesure de les justifier lors d’un contrôle.

La fréquence des sauvegardes doit être calibrée selon le volume et la sensibilité des données traitées. Un site vitrine sans formulaire actif peut se satisfaire d’une sauvegarde quotidienne. Un site proposant une prise de rendez-vous en ligne ou un espace de transmission de documents justifie des sauvegardes plus fréquentes, voire une réplication en temps réel des données critiques.

Ce qui est interdit ou insuffisant

• Considérer la sauvegarde du CMS comme suffisante : une sauvegarde des fichiers du site web ne couvre pas nécessairement la base de données associée, ni les fichiers uploadés par les patients (documents transmis via le site). Une sauvegarde complète inclut le code source, la base de données et les médias. Ces trois composantes doivent être sauvegardées ensemble et de manière cohérente pour permettre une restauration fonctionnelle.
• Ne jamais tester la restauration : une sauvegarde non testée peut s’avérer corrompue ou incomplète au moment d’en avoir besoin. Les bonnes pratiques recommandent de tester la restauration complète au moins une fois par an et après chaque mise à jour majeure du système. Ce test doit être documenté et archivé pour démontrer la robustesse du dispositif.
• Stocker les sauvegardes sur le même serveur que les données de production : si le serveur principal est compromis ou tombe en panne, les sauvegardes colocalisées sont perdues en même temps. L’isolation physique ou logique des sauvegardes est indispensable.
• Promettre une restauration garantie sans SLA documenté : un prestataire qui s’engage verbalement sur des délais de restauration sans les formaliser dans un contrat ne vous offre aucune garantie opposable. Exigez des engagements écrits.

Cas particulier : la disponibilité pour une structure avec prise de rendez-vous

Pour un cabinet qui dépend d’un module de prise de rendez-vous en ligne, la disponibilité du site devient un enjeu opérationnel direct. Une panne de plusieurs heures signifie des patients qui ne peuvent pas s’inscrire, des créneaux non pourvus et une perte de confiance potentiellement durable. Le contrat avec l’hébergeur doit prévoir un SLA (Service Level Agreement) avec un taux de disponibilité garanti — généralement 99,9 % pour un service professionnel, soit moins de neuf heures d’indisponibilité par an — et non un SLA à 99 % qui autorise jusqu’à 87 heures d’interruption annuelle.

Ce SLA doit prévoir des pénalités financières en cas de non-respect, un délai d’intervention garanti en cas d’incident (souvent exprimé en GTR — Garantie de Temps de Rétablissement) et un système de surveillance active (monitoring) qui détecte les pannes sans attendre qu’un patient vous les signale. Les implications contractuelles des outils de prise de rendez-vous sont développées dans notre page sur la qualification de sous-traitant RGPD en santé.

Il est également recommandé de prévoir une page de maintenance informative, activée automatiquement en cas d’indisponibilité planifiée, qui indique aux patients les autres moyens de vous contacter. Cette disposition, simple à mettre en place, évite que l’indisponibilité du site ne génère de l’inquiétude ou des appels d’urgence non justifiés.

Surveiller en continu : le monitoring du site

La sécurité technique d’un site médical ne se vérifie pas uniquement à la mise en ligne. Elle nécessite une surveillance continue qui détecte rapidement les anomalies : expiration du certificat TLS, indisponibilité du serveur, modification non autorisée des fichiers (signe potentiel d’une compromission), ou pic de trafic inhabituel pouvant indiquer une tentative d’attaque par déni de service. Des outils de monitoring comme Uptime Robot, Checkly ou les fonctions intégrées aux offres d’hébergement managé permettent d’être alerté par email ou SMS en quelques minutes en cas d’incident.

Pour un professionnel de santé, l’intérêt de ce monitoring est double. D’une part, il permet d’intervenir rapidement et de limiter la durée d’indisponibilité. D’autre part, il constitue un élément de preuve documentaire en cas de contrôle : les journaux de disponibilité démontrent que des mesures actives de surveillance ont été mises en place, ce qu’exige l’article 32 du RGPD en matière de « processus permettant de tester, d’évaluer et d’apprécier régulièrement l’efficacité des mesures techniques et organisationnelles ».

Ce qu’il faut faire concrètement

Commencez par un audit technique de votre site : votre certificat TLS est-il valide ? Se renouvelle-t-il automatiquement ? La version du protocole utilisée est-elle à jour (TLS 1.2 ou 1.3) ? Vérifiez ensuite votre politique de sauvegarde : où sont stockées les sauvegardes, quelle est leur fréquence, qui est responsable de les déclencher et de les tester, et la règle du 3-2-1 est-elle respectée ?

Lisez votre contrat d’hébergement et identifiez les engagements de disponibilité, le SLA, la GTR et les conditions de pénalité. Si ces informations sont absentes du contrat, c’est un signal d’alarme qui justifie une remise à plat de votre infrastructure. Pour un site traitant des données de santé, demandez à votre hébergeur la documentation de ses processus de sauvegarde dans le cadre de sa certification HDS : tout hébergeur certifié doit être en mesure de fournir cette documentation sur demande.

Questions fréquentes

Mon site affiche un cadenas vert : est-ce suffisant pour être conforme ?

Le cadenas indique que la connexion est chiffrée via HTTPS, ce qui est nécessaire mais pas suffisant. La conformité RGPD et HDS repose aussi sur la politique de sauvegarde, la disponibilité, le contrat d’hébergement et les mesures organisationnelles. Le HTTPS est le prérequis technique de base, non le certificat de conformité global. D’autres obligations s’appliquent en parallèle : mentions légales, politique de confidentialité, gestion des cookies et registre des traitements.

Quelle fréquence de sauvegarde est recommandée pour un site médical ?

Une sauvegarde quotidienne est le minimum pour un site avec formulaire ou prise de rendez-vous. Pour un site disposant d’un espace patient ou d’un volume important de données, des sauvegardes plus fréquentes (toutes les heures ou en temps réel avec réplication) peuvent être justifiées selon l’analyse des risques RGPD. La fréquence doit être proportionnelle à la quantité de données susceptibles d’être perdues entre deux sauvegardes et à l’impact de cette perte pour les patients concernés.

Que se passe-t-il si mon site est victime d’une cyberattaque ?

Si la cyberattaque entraîne une violation de données à caractère personnel, l’article 33 du RGPD impose de notifier la CNIL dans les 72 heures suivant la prise de connaissance de l’incident. Si la violation est susceptible d’engendrer un risque élevé pour les personnes concernées, elles doivent également être notifiées (article 34 du RGPD). Des sauvegardes à jour permettent de limiter les dommages, de rétablir le service rapidement et de démontrer à la CNIL que des mesures préventives appropriées avaient été mises en place.

Mon hébergeur dit qu’il fait des sauvegardes : dois-je lui faire confiance ?

Les déclarations verbales ou commerciales ne suffisent pas. Demandez à voir les clauses contractuelles précises : fréquence des sauvegardes, localisation des copies, délai de restauration garanti et procédure de test. Dans le cadre d’un hébergement HDS, ces éléments doivent être formalisés dans le contrat de sous-traitance. Si votre hébergeur ne peut pas vous fournir ces informations par écrit, envisagez de changer de prestataire avant qu’un incident ne survienne.

Sources

• Règlement (UE) 2016/679 (RGPD), articles 32, 33 et 34.
• Article L.1111-8 du code de la santé publique — sécurité des données de santé.
• Guide de sécurité des systèmes d’information de santé, ANS, disponible sur esante.gouv.fr.
• Recommandations ANSSI sur les sauvegardes, disponibles sur ssi.gouv.fr.
• Délibération CNIL sur les obligations de sécurité issues de l’article 32 du RGPD.

Article informatif. Il ne constitue pas un conseil juridique : en cas de doute, rapprochez-vous de votre conseil de l’ordre.