Qu'est-ce que la certification HDS et pourquoi est-elle obligatoire ?
Boucif Faradji
Fondateur DevEvoke
Découvrez les enjeux de l'Hébergement de Données de Santé (HDS) et pourquoi cette certification est une exigence légale absolue pour tout logiciel médical en France.
1. Introduction : La nature ultra-sensible de la donnée de santé
Dans l'écosystème numérique contemporain, la donnée est souvent qualifiée de "nouvel or noir". Cependant, lorsqu'il s'agit de données de santé, nous quittons le domaine du simple commerce pour entrer dans la sphère intime de la vie privée. En France et en Europe, la donnée de santé n'est pas une donnée comme les autres. Elle est qualifiée de "donnée sensible" par l'article 9 du Règlement Général sur la Protection des Données (RGPD) et fait l'objet de dispositions spécifiques dans le Code de la Santé Publique. Une donnée de santé révèle des informations cruciales sur l'état physique ou mental d'une personne, ses antécédents médicaux, ses traitements en cours, son patrimoine génétique, ou même ses habitudes de vie. La compromission de telles données peut avoir des conséquences dévastatrices. Contrairement à un numéro de carte bancaire qui peut être bloqué en quelques minutes après une fraude, un dossier médical est immuable. Une fuite concernant le statut sérologique, une pathologie psychiatrique ou une addiction peut entraîner des discriminations majeures à l'embauche, lors de la souscription d'un prêt immobilier ou d'une assurance. C'est cette permanence et cette gravité qui justifient la mise en place d'un cadre législatif extrêmement coercitif et rigoureux, unique au monde par son niveau d'exigence : la certification HDS (Hébergeur de Données de Santé).
2. De l'agrément à la certification : L'évolution du cadre réglementaire français
La protection des données de santé en France ne date pas d'hier. Dès la fin des années 2000, le gouvernement français avait instauré un système d"agrément" délivré par le Ministère de la Santé (après avis de la CNIL et de l'ASIP Santé, devenue l'ANS). Ce système était déclaratif et documentaire. Cependant, avec l'explosion du Cloud Computing, de la télémédecine et des objets connectés (IoT), ce modèle a montré ses limites. Il ne permettait pas de garantir un niveau de sécurité technique homogène face à des cybermenaces de plus en plus sophistiquées (notamment l'émergence des ransomwares ciblant les hôpitaux). En 2018, la France a donc opéré une transition majeure : le passage de l'agrément à la certification HDS. La différence est fondamentale. La certification n'est plus accordée sur la base d'un simple dossier administratif, mais à l'issue d'audits sur site extrêmement poussés, réalisés par des organismes certificateurs indépendants (comme l'AFNOR ou le BSI). Ces auditeurs vérifient non seulement la solidité de l'architecture technique, mais aussi la réalité des processus organisationnels. Le référentiel HDS est devenu un standard d'excellence, redéfinissant les règles du jeu pour tous les éditeurs de logiciels médicaux, les startups MedTech, les cliniques et les EHPAD.
3. L'anatomie de la certification HDS : Les six périmètres décryptés
La force du référentiel HDS réside dans sa granularité. Il ne traite pas l'hébergement comme un bloc monolithique, mais décompose la chaîne de valeur de l'hébergement en six "périmètres" distincts. Cette approche permet de couvrir l'intégralité des risques, de la brique physique jusqu'à l'interface utilisateur. Les deux premiers périmètres concernent l"hébergeur d'infrastructure physique". Le Périmètre 1 certifie la mise à disposition de locaux hébergeant le matériel (les datacenters). Il s'assure que les bâtiments sont protégés contre les intrusions physiques (gardiens 24/7, biométrie, sas de sécurité), les incendies (gaz inertes), les coupures de courant (groupes électrogènes redondants) et les catastrophes naturelles. Le Périmètre 2 concerne la mise à disposition de l'infrastructure matérielle (les serveurs physiques et les baies de stockage). Les quatre périmètres suivants s'adressent à l"hébergeur d'infogérance". Le Périmètre 3 certifie la plateforme (PaaS) ou l'infrastructure virtuelle (IaaS) mise à disposition. Le Périmètre 4 couvre la mise à disposition de l'infrastructure virtuelle elle-même. Le Périmètre 5 est le plus critique pour l'exploitation quotidienne : il certifie l'administration et l'exploitation du système d'information (la gestion des mises à jour, la surveillance des failles, l'administration des bases de données). Enfin, le Périmètre 6 concerne la sauvegarde externalisée des données. Pour garantir une conformité totale, une solution logicielle SaaS doit s'appuyer sur des partenaires (ou posséder en propre) couvrant l'ensemble de ces six périmètres, créant ainsi une chaîne de confiance ininterrompue.
4. Les fondations normatives : ISO 27001, ISO 27018 et ISO 20000
Le référentiel HDS ne sort pas de nulle part ; il s'appuie sur les standards internationaux les plus exigeants en matière de sécurité de l'information. La colonne vertébrale de la certification HDS est la norme ISO/IEC 27001. Obtenir l'ISO 27001 est d'ailleurs un prérequis absolu pour candidater à l'HDS. L'ISO 27001 impose la mise en place d'un Système de Management de la Sécurité de l'Information (SMSI). Ce SMSI est un cadre systématique qui implique une analyse continue des risques (via des méthodes comme EBIOS Risk Manager), l'élaboration de politiques de sécurité, et une amélioration continue basée sur le cycle PDCA (Plan, Do, Check, Act). Le référentiel HDS ajoute à l'ISO 27001 des exigences spécifiques tirées d'autres normes clés. Par exemple, il intègre des éléments de la norme ISO 27018, qui traite spécifiquement de la protection des données à caractère personnel dans le Cloud Computing, imposant des règles strictes sur la confidentialité et le consentement. Il intègre également des exigences issues de l'ISO 20000, qui régit la gestion des services informatiques (ITSM), garantissant que les processus de support (Helpdesk), de gestion des incidents et de déploiement sont maîtrisés et documentés. En combinant ces normes mondiales avec les exigences spécifiques de la loi française (comme le droit d'opposition du patient), le référentiel HDS crée un bouclier juridique et technique d'une robustesse inégalée.
5. La forteresse cryptographique : Chiffrement et gestion des clés
Au cœur de la protection technique exigée par l'HDS se trouve la cryptographie. Les données de santé ne doivent jamais exister "en clair" sur un système exposé. Le chiffrement s'applique à deux niveaux distincts. Premièrement, le chiffrement "au repos" (Data at Rest). Toutes les bases de données, tous les disques durs, toutes les archives de sauvegarde (backups) doivent être chiffrés avec des algorithmes d'état de l'art, tels que l'Advanced Encryption Standard (AES) avec des clés de 256 bits. Ainsi, si un attaquant parvenait à dérober physiquement un disque dur dans un datacenter, il ne récupérerait qu'une suite de caractères incompréhensibles. Deuxièmement, le chiffrement "en transit" (Data in Transit). Lorsque le médecin consulte le dossier patient depuis sa tablette, les informations transitent via Internet. Elles doivent être systématiquement protégées par des tunnels sécurisés utilisant le protocole TLS (Transport Layer Security) dans sa version la plus récente (1.2 ou 1.3), avec des suites cryptographiques fortes (Perfect Forward Secrecy). Mais le chiffrement n'est rien sans une gestion stricte des clés (Key Management). Le référentiel HDS exige que les clés de chiffrement soient générées, stockées et gérées de manière totalement sécurisée, idéalement via des modules de sécurité matériels (HSM - Hardware Security Modules). La compromission d'une clé équivaut à la compromission des données ; la rotation des clés et le contrôle d'accès à ces dernières sont donc audités sans aucune concession.
6. Architecture Zero Trust et segmentation réseau
Les modèles de sécurité périmétrique traditionnels (le concept du "château fort" avec un pare-feu à l'entrée et une confiance totale à l'intérieur) sont obsolètes. Face à des attaques furtives, le référentiel HDS pousse les éditeurs et les hébergeurs vers le modèle "Zero Trust". L'adage de l'architecture Zero Trust est "Never trust, always verify" (Ne jamais faire confiance, toujours vérifier). Dans une infrastructure HDS, la segmentation du réseau est poussée à l'extrême (micro-segmentation). Les serveurs hébergeant la base de données de santé sont isolés dans des VLANs ultra-restreints, inaccessibles directement depuis Internet. Les serveurs frontaux (serveurs web) ne peuvent communiquer avec les bases de données que via des ports spécifiques et des API authentifiées. Chaque flux réseau est analysé en temps réel par des systèmes de détection et de prévention d'intrusions (IDS/IPS) et des Web Application Firewalls (WAF). Si un attaquant parvient à compromettre une application secondaire, la micro-segmentation l'empêche de se déplacer latéralement vers les bases de données médicales critiques.
7. Authentification forte, MFA et gestion des habilitations
L'accès à la donnée de santé est le maillon le plus ciblé par les pirates. Le vol d'identifiants (via des campagnes de phishing) est le principal vecteur d'attaque contre les cliniques et les EHPAD. C'est pourquoi le référentiel HDS impose des règles drastiques concernant la gestion des accès (IAM - Identity and Access Management). Le mot de passe simple n'est plus acceptable. L'authentification multifacteur (MFA) est devenue la norme absolue pour tout accès administrateur (infogérance) et est fortement recommandée, voire imposée, pour les accès utilisateurs finaux (soignants). Le MFA oblige l'utilisateur à fournir une preuve supplémentaire (un code SMS, un jeton généré par une application authenticator, une clé matérielle FIDO2, ou la carte CPS/e-CPS française) pour valider sa connexion. De plus, les habilitations doivent suivre le principe du "moindre privilège" (Need-to-Know). Un aide-soignant n'a pas besoin de voir les informations de facturation, tout comme le comptable n'a pas besoin d'accéder aux notes psychiatriques d'un résident. Les revues de droits doivent être menées trimestriellement, et toute désactivation de compte (suite au départ d'un collaborateur) doit être instantanée pour éviter les comptes "zombies" qui constituent des portes d'entrée béantes.
8. Traçabilité absolue : L'exigence de journalisation (Logging)
Dans le secteur de la santé, le secret médical est inviolable. Pour s'en assurer, la confiance n'exclut pas le contrôle. La certification HDS exige une traçabilité exhaustive, inaltérable et horodatée de l'intégralité des événements du système d'information. Il ne s'agit pas seulement de tracer les accès réussis, mais aussi les tentatives échouées, les modifications de données, les suppressions (logiques), et les accès en lecture (qui a consulté tel dossier). Cette montagne de journaux d'événements (logs) doit être centralisée dans un outil de gestion des événements de sécurité (SIEM - Security Information and Event Management). Ces logs doivent être eux-mêmes protégés contre la falsification : un administrateur système corrompu ou un pirate informatique ne doit pas pouvoir effacer ses traces. Ces données de journalisation doivent être conservées sur une durée légale (souvent 1 an minimum) pour permettre des investigations judiciaires ou des audits internes (forensics) en cas de suspicion de violation de données (Data Breach).
9. Résilience extrême : PCA, PRA et lutte contre les ransomwares
La cybersécurité moderne part du postulat que l'attaque finira par réussir. La question n'est pas "si", mais "quand". Par conséquent, la capacité à maintenir le service ou à le restaurer rapidement est vitale. Le référentiel HDS consacre un chapitre entier à la gestion de la continuité. Un Hébergeur de Données de Santé doit concevoir et tester régulièrement un Plan de Continuité d'Activité (PCA) et un Plan de Reprise d'Activité (PRA). Cela implique la mise en place d'infrastructures redondées (Clusters Haute Disponibilité) réparties sur plusieurs sites géographiques (Datacenters Distants). En cas de sinistre majeur (incendie d'un datacenter comme ce fut le cas pour OVH à Strasbourg, ou attaque massive par ransomware bloquant les serveurs locaux d'un CHU), le système de secours doit pouvoir prendre le relais presque instantanément. Les indicateurs clés sont le RTO (Recovery Time Objective), qui est le temps d'interruption toléré, et le RPO (Recovery Point Objective), qui définit la perte de données acceptable (généralement quasi nulle en santé). Pour se prémunir contre les ransomwares, les sauvegardes (Périmètre 6) doivent être déconnectées du réseau de production (Air-Gapped) et immuables (Write-Once-Read-Many), empêchant ainsi tout chiffrement malveillant par le virus.
10. La gouvernance : Rôle du DPO et du RSSI
La conformité HDS n'est pas qu'une affaire de câbles et de logiciels ; c'est avant tout une affaire d'humains et de gouvernance. Toute structure gérant des données de santé doit nommer un Délégué à la Protection des Données (DPO - Data Protection Officer) et un Responsable de la Sécurité des Systèmes d'Information (RSSI). Le DPO est le garant du respect du RGPD. Il tient à jour le registre des traitements, s'assure que le consentement des patients est recueilli de manière libre et éclairée, et réalise les Analyses d'Impact relatives à la Protection des Données (AIPD / DPIA). Ces AIPD sont obligatoires pour tout traitement de données de santé à grande échelle. Le RSSI, quant à lui, pilote le SMSI (Système de Management de la Sécurité de l'Information). Il supervise les audits de sécurité réguliers (tests d'intrusion ou pentests), forme les collaborateurs aux bonnes pratiques d'hygiène informatique (sensibilisation au phishing), et gère les incidents de sécurité de concert avec les autorités compétentes.
11. Violation de données : Le protocole strict de notification
Que se passe-t-il lorsque, malgré toutes les précautions, une faille est exploitée ? Le RGPD et le Code de la Santé Publique imposent une transparence totale. En cas de violation de données (Data Breach) entraînant un risque pour les droits et libertés des personnes (vol de la base de données des patients, accès non autorisé par un tiers, indisponibilité prolongée du système de soin due à un ransomware), le responsable de traitement (la clinique, l'EHPAD) a l'obligation stricte de notifier la CNIL dans un délai maximal de 72 heures. Si le risque est élevé, l'établissement doit également informer chaque patient concerné individuellement. De plus, tout incident de sécurité grave dans un établissement de santé doit être signalé sans délai au portail des signalements des événements sanitaires indésirables de l'Agence Régionale de Santé (ARS) et de l'Agence du Numérique en Santé (ANS). La réactivité de l'hébergeur HDS est ici cruciale : il doit alerter son client (l'établissement de soins) dans les plus brefs délais dès la détection de l'incident, lui fournir tous les logs nécessaires à l'investigation, et l'accompagner dans la résolution de la crise (Incident Response).
12. Conclusion : L'HDS comme avantage concurrentiel et éthique
Pour un éditeur de logiciels SaaS, concevoir une architecture conforme aux exigences réglementaires et de sécurité représente un investissement important en compétences et en rigueur. Le coût de l'infrastructure redondée, du chiffrement et des audits est réel. Cependant, pour les organisations médico-sociales, choisir un partenaire technologique ne garantissant pas la sécurité de ses données n'est tout simplement plus une option envisageable. Le risque pénal, réputationnel et organisationnel est beaucoup trop important. En s'associant à une agence de développement et de conseil comme DevEvoke, qui place le respect du RGPD, de la souveraineté des données et de la sécurité web au sommet de son cahier des charges "Security by Design", les acteurs médico-sociaux font le choix de la sérénité. Ils protègent non seulement leur responsabilité de dirigeants, mais ils garantissent surtout la confidentialité des personnes accompagnées.