Données de santé sous cyberattaque : ce que la vague d'août 2026 impose à votre programme HDS et NIS2

En août 2026, la compromission d'Alaxione a exposé les données de 6,8 millions de patients, dont des IBAN, des numéros de sécurité sociale et des motifs de consultation. La vague révèle un décalage persistant entre la conformité formelle HDS/NIS2 et la résilience opérationnelle réelle. Ce que cet événement impose concrètement à votre programme.

Écran d'ordinateur portable ouvert dans un bureau sombre, affichant du code en couleurs vives dans un éditeur, avec un pot à crayons au premier plan

Le 22 août 2026, la plateforme Alaxione, hébergeur de données de santé, annonce une compromission. Le bilan : 6,8 millions de patients touchés, données personnelles, coordonnées bancaires, numéros de sécurité sociale et motifs de consultation exposés. Cette brèche survient dans une semaine qui voit simultanément la DGFiP et le ministère de l'Éducation nationale faire état d'incidents majeurs. Le volume n'est pas l'angle le plus utile. La question qui compte pour les RSSI et les DPO du secteur de la santé : qu'est-ce que cet événement révèle des lacunes dans vos programmes HDS et NIS2 ?

Les données de santé ne sont pas des données comme les autres

Le RGPD distingue les données de santé des données personnelles ordinaires. L'article 9 les classe parmi les catégories dites "particulières", dont le traitement est en principe interdit sauf exception explicite. Cette classification a des conséquences concrètes sur votre programme de conformité.

La première : une violation portant sur des données de santé est systématiquement considérée comme susceptible d'engendrer un risque élevé pour les droits et libertés des personnes. Cela active automatiquement l'article 34 du RGPD, c'est-à-dire l'obligation de notifier les personnes concernées en plus de la CNIL. Pour 6,8 millions de personnes, cette notification individuelle est logistiquement considérable. Elle doit être intelligible, mentionner la nature des données exposées, les conséquences probables et les mesures prises. Elle ne peut pas attendre.

La seconde conséquence : le seuil de risque pour déclencher une analyse d'impact (AIPD) est atteint par nature dès que des données de santé sont traitées. Tout hébergeur ou sous-traitant qui n'a pas conduit d'AIPD avant de déployer un système traitant ces données est en situation de non-conformité structurelle, indépendamment de tout incident.

La certification HDS : ce qu'elle couvre et ce qu'elle ne garantit pas

L'hébergement de données de santé en France est soumis à la certification HDS (Hébergeur de Données de Santé), délivrée par des organismes accrédités par le COFRAC. Cette certification exige une conformité à la norme ISO 27001, couvrant les processus de sécurité, de gestion des incidents et de continuité. Elle est nécessaire pour tout hébergeur ou infogéreur traitant des données de santé pour le compte d'établissements de santé ou de professionnels de santé.

Deux points restent systématiquement mal compris. HDS est une certification de l'organisation hébergeante, pas une garantie de sécurité absolue du contenu hébergé. Une organisation peut être certifiée HDS et subir une compromission si un vecteur d'attaque n'est pas couvert par le périmètre de la certification : un sous-traitant non audité, un accès administrateur compromis, une vulnérabilité dans une application tierce. La certification atteste que les processus existent, pas qu'ils résistent à toutes les attaques.

Le second point : la certification HDS ne dispense pas des obligations NIS2. Ce sont deux cadres distincts, avec des autorités distinctes et des exigences complémentaires. En France, selon le décret de transposition NIS2, les établissements de santé, les laboratoires de biologie médicale et les fabricants de dispositifs médicaux critiques sont classés comme "entités essentielles". Les hébergeurs de données de santé de taille significative entrent dans cette catégorie. Cela signifie que le régime NIS2 s'applique en plus de HDS, pas à sa place.

La double notification, une fois de plus

Un incident sur des données de santé déclenche au moins deux circuits de notification parallèles, avec des délais différents.

Sous le RGPD, l'article 33 impose une notification à la CNIL dans les 72 heures suivant la prise de connaissance de la violation, si celle-ci est susceptible d'engendrer un risque pour les droits et libertés. Pour des données de santé, ce risque est présumé élevé. Le délai de 72 heures s'applique au responsable de traitement, pas à l'hébergeur : si votre prestataire HDS est compromis, c'est à vous, en tant que responsable des données de vos patients, de notifier la CNIL, pas à l'hébergeur à votre place.

Sous NIS2, l'article 23 impose une alerte précoce dans les 24 heures suivant la détection d'un incident significatif, puis une notification complète dans les 72 heures, auprès de l'ANSSI via la plateforme nationale. La définition d'"incident significatif" dans le secteur de la santé inclut tout événement affectant la disponibilité, la confidentialité ou l'intégrité des systèmes ou des données. Un hébergeur de données de santé compromis remplit cette définition.

La coordination de ces deux circuits reste le principal point de friction opérationnel. L'article sur les pièges de la double notification RGPD et NIS2 détaille les mécanismes pour tenir les deux délais sans improviser. L'essentiel : les deux notifications ne peuvent pas se partager les mêmes heures sans une organisation dédiée. La rédaction d'une notification CNIL solide prend du temps. La collecte des éléments techniques pour la notification ANSSI en prend aussi. Si vous n'avez pas testé ce processus avant un incident, vous le découvrirez sous pression.

Ce que la vague d'août 2026 révèle

L'incident Alaxione n'est pas isolé. Sur la semaine du 18 au 25 août 2026, plusieurs incidents majeurs ont été signalés simultanément en France : les brèches à la DGFiP et au ministère de l'Éducation nationale revendiquées par le groupe ZeroBytes, l'incident Alaxione, et des incidents de moindre amplitude dans le secteur assurantiel. Cette simultanéité suggère soit une campagne coordonnée, soit une exposition commune à un même vecteur technique non corrigé.

Selon le Panorama de la cybermenace 2025 de l'ANSSI, publié en mars 2026, le secteur de la santé représente 10 % des incidents traités par le CERT-FR, ce qui en fait le deuxième secteur le plus ciblé derrière les collectivités territoriales. Ce chiffre couvrait l'année 2025. Les événements d'août 2026 confirment que la tendance ne s'est pas inversée.

L'exposition principale n'est pas technique au sens où on l'entend habituellement. Les audits de maturité menés dans le secteur de la santé révèlent régulièrement trois lacunes récurrentes : la cartographie incomplète des accès tiers aux systèmes d'information cliniques, l'absence de segmentation réseau entre le système d'information hospitalier et les applications administratives, et des plans de réponse aux incidents non testés depuis plus de douze mois. Ces trois points sont adressés par NIS2 (article 21, mesures de gestion des risques) et par les exigences HDS (gouvernance des accès, plan de continuité). Le fait qu'ils restent des lacunes persistantes signifie que la conformité formelle ne se traduit pas encore en pratiques opérationnelles solides.

Trois actions à engager avant la fin du trimestre

Revoir la cartographie de vos sous-traitants HDS. L'article 28 du RGPD et l'article 21 de NIS2 exigent que vos contrats avec les hébergeurs et les sous-traitants couvrent des clauses de sécurité précises. Si votre prestataire HDS est compromis, vérifiez : votre contrat prévoit-il une obligation de notification vers vous dans quel délai ? Dispose-t-il d'un contact de crise disponible 24h/24 ? Ces clauses doivent être vérifiées maintenant, pas lors d'un incident.

Tester votre processus de notification. Un exercice de simulation d'incident ne prend pas plus d'une demi-journée. Il implique votre équipe sécurité, votre DPO et votre direction juridique. L'objectif est de vérifier que vous êtes en mesure de rédiger une notification CNIL recevable et une alerte ANSSI complète dans les délais, avec les informations dont vous disposez à chaud. Si vous ne l'avez pas fait dans les douze derniers mois, faites-le avant la fin du trimestre.

Vérifier le périmètre de votre certification HDS. Si votre organisation est certifiée HDS, vérifiez que le périmètre de la certification couvre bien tous les systèmes qui traitent des données de santé, y compris les applications développées récemment et les outils SaaS intégrés depuis la dernière revue. Un périmètre qui glisse sans être mis à jour expose votre organisation à un écart de conformité que ni la CNIL ni l'ANSSI ne considèrent comme une circonstance atténuante.

Le signal que cet été envoie

L'intérieur Lecornu a annoncé le 25 août 2026 la création d'une cellule de crise interministérielle et un budget d'urgence de 200 millions d'euros pour la réponse cyber. Ce signal ne doit pas être lu comme une assurance : l'État renforce sa capacité de réponse, mais les obligations de sécurité reposent sur les organisations elles-mêmes. NIS2 ne change pas de nature parce que l'État a mobilisé des ressources. Les délais de notification ne s'allongent pas. Les exigences de gestion des risques ne se suspendent pas.

Pour les entités du secteur de la santé classées essentielles sous NIS2, la vague d'août 2026 est une occasion de vérifier que la distance entre votre programme de conformité et votre résilience réelle est mesurée, documentée et réduite. Les autorités de supervision ne cherchent pas des organisations parfaites ; elles cherchent des organisations qui progressent de façon traçable.

Un projet ? Une question ?

Nous contacter →