Points clés
- Un incident sur un dispositif médical connecté peut avoir trois types de conséquences : cliniques (impact sur les soins), numériques (propagation dans le SI), et réglementaires/juridiques (obligation de notification, matériovigilance).
- Les conséquences cliniques d'une compromission varient de la désorganisation des soins à l'administration d'une dose incorrecte, avec un impact potentiel direct sur la sécurité patient.
- La notification des incidents impliquant des dispositifs médicaux est encadrée par la matériovigilance (ANSM) et, depuis NIS2, par les obligations de déclaration aux autorités nationales de cybersécurité.
- La gestion de crise IoMT requiert une coordination entre équipes IT, service biomédical, direction médicale et direction générale — une organisation rarement exercée avant qu'un incident survienne.
Impact clinique direct : de la désorganisation à la mise en danger
La compromission d'un dispositif médical connecté peut engendrer des conséquences cliniques d'une gravité variable. Dans le scénario le plus fréquent — ransomware ou attaque par déni de service — l'équipement devient indisponible, forçant un retour aux procédures manuelles. Si celles-ci ne sont pas formalisées et entraînées, la désorganisation des soins est immédiate. Dans des scénarios plus ciblés — manipulation du firmware d'une pompe à perfusion, falsification des données d'un moniteur patient — les conséquences peuvent atteindre le niveau de l'administration d'une dose incorrecte ou d'un diagnostic erroné. La FDA a documenté des vulnérabilités permettant théoriquement ce niveau d'impact sur plusieurs gammes d'équipements commerciaux.
Propagation dans le SI : l'effet domino
Un dispositif médical compromis rarement s'arrête à lui-même. Dans un réseau insuffisamment segmenté, il constitue une tête de pont pour un mouvement latéral vers les systèmes cliniques critiques : DPI, PACS, serveurs de résultats de biologie. La propagation peut être automatisée — worm exploitant des vulnérabilités connues sur des systèmes non patchés — ou manuelle, par un attaquant utilisant le dispositif comme relais vers des actifs à plus haute valeur. Ce scénario d'escalade transforme un incident initialement limité à un équipement biomédical en crise informatique généralisée touchant la continuité de l'ensemble des soins.
Obligations de notification et matériovigilance
Un incident impliquant un dispositif médical connecté génère des obligations de notification multiples. La matériovigilance — encadrée par l'ANSM — impose de déclarer tout incident ou risque d'incident mettant en cause un dispositif médical. Si l'incident implique des données de santé personnelles, le RGPD art. 33 impose une notification à la CNIL dans les 72 heures. NIS2 ajoute une obligation de notification préliminaire à l'ANSSI dans les 24 heures pour les entités essentielles. La coordination de ces obligations de reporting simultanées, adressées à trois autorités distinctes, requiert un processus documenté que peu d'établissements ont formalisé avant d'en avoir besoin.
Gestion de crise IoMT : une organisation spécifique
La gestion d'un incident impliquant des dispositifs médicaux exige une organisation de crise plus complexe que les incidents purement IT. La cellule de crise doit inclure : le RSSI pour la dimension cyber, l'ingénieur biomédical pour l'évaluation de l'impact sur les équipements et les options de contournement, le responsable des soins infirmiers pour la gestion des protocoles de soins dégradés, le directeur médical pour les décisions cliniques, et la direction générale pour les arbitrages stratégiques. Cette coordination multidisciplinaire doit être exercée régulièrement pour être opérationnelle en situation réelle.
Retour à la normale : complexité et délais
La restauration après un incident IoMT est particulièrement complexe. Contrairement aux systèmes IT qui peuvent être réinstallés depuis des images standardisées, les dispositifs médicaux requièrent des procédures de remise en service spécifiques validées par le constructeur, parfois l'intervention d'un technicien agréé sur site, et une vérification de conformité fonctionnelle avant remise en service clinique. Le firmware ne peut être réinstallé depuis n'importe quelle source sans risquer d'invalider la certification CE/MDR du dispositif. Ces contraintes allongent significativement les délais de retour à la normale et doivent être anticipées dans les plans de continuité d'activité.