Article dans mt|medizintechnik 2.2026 : comment les établissements de santé encadrent l’usage de l’IA par la gestion des risques
19 octobre 2026
Paru dans mt|medizintechnik, Numéro 2.2026
Paru dans mt|medizintechnik, numéro 2.2026
Dans la revue mt|medizintechnik, Valeri Milke montre comment les établissements de santé encadrent l’usage des systèmes d’IA par la gestion des risques. Son article en allemand « Risikomanagement für KI-Systeme im Medizinbetrieb », sous-titré « Therapieentscheidungen durch Algorithmen » (des décisions thérapeutiques confiées à des algorithmes), occupe les pages 8 à 12 du numéro 2.2026, paru en avril 2026 et consacré à la médecine personnalisée ; il compte trois illustrations et un tableau. La revue est éditée par TÜV Media GmbH à Cologne. Auteur : Valeri Milke, CEO de VamiSec GmbH, Lead Auditor ISO/IEC 27001 et ISO/IEC 42001. L’article relie les exigences du règlement sur les dispositifs médicaux (MDR), du règlement européen sur l’IA (AI Act) et du Cyber Resilience Act (CRA) à une démarche pratique pour le quotidien clinique – du modèle de menaces à l’évaluation des conséquences, jusqu’aux mesures et aux preuves. Cette actualité reformule ses messages clés et les situe dans le cadre réglementaire d’octobre 2026.
La thèse centrale : qui utilise l’IA en partage la responsabilité
L’IA est arrivée dans de nombreux hôpitaux : elle signale des anomalies sur les radiographies et les images de scanner, propose des options thérapeutiques ou aide à planifier rendez-vous, lits et médication. Plus ces systèmes pèsent sur les décisions, plus la qualité des soins dépend de la fiabilité de leurs résultats. Un modèle entraîné sur des données déséquilibrées, une nouvelle version du modèle installée à l’insu de tous ou une dégradation progressive en exploitation peuvent mettre directement en danger les patients – et ébranler la confiance dans la médecine assistée par l’IA. L’article met donc au premier plan une perspective souvent négligée : celle des exploitants, que l’AI Act appelle déployeurs. Les fabricants ne sont pas seuls concernés : hôpitaux, laboratoires et cabinets doivent eux aussi piloter activement les risques de l’IA – une tâche permanente sur tout le cycle de vie, qui associe technique, organisation et éthique.
Quand une IA médicale est-elle un système à haut risque ?
En règle générale, c’est le droit des dispositifs médicaux qui fait d’une IA médicale un système à haut risque : si le système d’IA est lui-même un dispositif médical ou le composant de sécurité d’un tel dispositif et qu’un organisme notifié doit en évaluer la conformité, il est aussi à haut risque au sens de l’AI Act. Un logiciel qui fournit des informations pour des décisions diagnostiques ou thérapeutiques relève en principe au moins de la classe IIa selon le MDR et requiert donc un organisme notifié – c’est le cas de la plupart des applications cliniques d’IA. L’organisme notifié contrôle les exigences de l’AI Act dans la procédure MDR existante ; aucune seconde certification n’est nécessaire. L’AI Act classe en outre directement à haut risque certains usages en santé, comme le triage des patients aux urgences. Le guide MDCG 2025-6 de juin 2025 explique cette articulation en 36 questions ; l’échéance de 2027 qu’il cite a depuis été reportée à 2028 par le législateur.
Responsabilité partagée : ce qui incombe au fournisseur et au déployeur
Juridiquement, les rôles sont distincts ; en pratique, ils dépendent l’un de l’autre. Le fournisseur met en place un système de gestion des risques, assure une gouvernance des données solide et démontre la conformité. Le déployeur – à l’hôpital, l’établissement et non le médecin pris isolément – utilise le système selon la notice d’utilisation, confie le contrôle humain à des personnes formées et habilitées, veille à la pertinence et à la représentativité des données d’entrée qu’il fournit, surveille le fonctionnement et signale les anomalies au fournisseur. Il conserve en règle générale pendant au moins six mois les journaux générés automatiquement sous son contrôle. L’AI Act n’impose pas de système formel de gestion des risques aux déployeurs ; une gestion des risques propre à l’exploitant, par exemple selon l’IEC 80001-1, est pourtant la base pratique de ces obligations. Attention : quiconque commercialise un système sous son propre nom, le modifie substantiellement ou l’affecte à une finalité à haut risque endosse lui-même les obligations d’un fournisseur.
Identifier les menaces : STRIDE, OWASP et dérive des modèles
Pour identifier les risques, l’article recommande une modélisation des menaces (threat modeling) le long des flux de données et des interfaces. Le schéma STRIDE, né chez Microsoft, classe les menaces en six catégories : usurpation d’identité (Spoofing), falsification (Tampering), répudiation (Repudiation), divulgation d’informations (Information Disclosure), déni de service (Denial of Service) et élévation de privilèges (Elevation of Privilege). Exemples cliniques : un faux appareil d’imagerie injecte des images étrangères, un fichier de modèle altéré déplace les seuils diagnostiques, un compte d’intégration aux droits excessifs ouvre l’accès à la configuration. Pour les applications à base de modèles de langage, l’OWASP Top 10 for LLM Applications 2026 recense d’autres attaques, comme l’injection d’instructions (Prompt Injection) ou l’empoisonnement des données et des modèles (Data and Model Poisoning). S’y ajoute la dérive du modèle (model drift) : une baisse progressive des performances, parce que patients, appareils ou pratique clinique s’écartent des conditions de validation.
Évaluer les conséquences, agir, documenter
Après l’identification vient l’évaluation : que signifie un dysfonctionnement pour les patients, le personnel et la prise en charge ? L’article croise probabilité et gravité dans une matrice ; la gravité couvre les conséquences médicales, sociétales et pour la protection des données. Il regroupe les mesures en quatre champs : prévenir, détecter, corriger et documenter – par exemple des données de test représentatives, une surveillance avec alertes, un contrôle humain aux points critiques et le retour à la version précédente. Cadres de référence : l’ISO 14971 pour le risque produit, l’ISO/IEC 23894 comme guide propre à l’IA et l’ISO/IEC 42001, système de management volontaire qui structure les obligations légales sans les remplacer. L’AI Act n’exige une analyse d’impact sur les droits fondamentaux que pour certains usages, comme le triage aux urgences, et uniquement de la part d’organismes de droit public ou d’entités privées fournissant des services publics ; pour les dispositifs médicaux à base d’IA, l’évaluation repose sur l’analyse d’impact relative à la protection des données (AIPD) et la gestion des risques cliniques.
Pourquoi le sujet presse – et ce que vous pouvez faire
L’AI Act est en vigueur depuis le 1er août 2024 ; les interdictions et l’obligation de favoriser la maîtrise de l’IA s’appliquent depuis le 2 février 2025, les obligations de transparence depuis le 2 août 2026. Le Digital Omnibus on AI, en vigueur depuis le 27 juillet 2026, fixe les échéances haut risque : 2 décembre 2027 pour les usages directement listés, 2 août 2028 pour les dispositifs médicaux à base d’IA – pour fournisseurs comme déployeurs. Les systèmes mis sur le marché ou mis en service auparavant ne sont concernés qu’après des modifications importantes de leur conception. Le Cyber Resilience Act exclut les dispositifs médicaux, mais vise les produits informatiques non médicaux achetés par les hôpitaux : leurs fabricants notifient depuis le 11 septembre 2026 les vulnérabilités activement exploitées, les autres obligations suivront le 11 décembre 2027. Cinq étapes sont recommandées : tenir un registre des applications d’IA avec rôle et classification ; attribuer clairement contrôle humain et formation ; régler par contrat surveillance, journaux et signalements avec les fournisseurs ; établir un modèle de menaces pour chaque système critique ; exiger à l’achat des engagements de mise à jour et une nomenclature logicielle (Software Bill of Materials, SBOM).
Nouveau sur vamisec.com : la page de connaissances sur le sujet
Nouveau sur vamisec.com : la page de connaissances « Gestion des risques IA en milieu de soins ». Elle reprend les thèses de l’article, les actualise à octobre 2026 et les approfondit du point de vue des exploitants – avec la classification de l’IA médicale, la répartition des obligations entre fournisseur et établissement, un modèle de menaces intégrant les attaques propres à l’IA, l’évaluation des risques, des mesures concrètes et les preuves nécessaires, complétés par une FAQ et des sources vérifiées. Vous trouverez la page sur https://vamisec.com/fr/wissen/secure-software-development/ki-risikomanagement-medizin. L’articulation entre AI Act et MDR du point de vue des fabricants est présentée sur https://vamisec.com/fr/ki-vo-medizinprodukte – notre accompagnement MDR est décrit sur https://vamisec.com/fr/mdr.
Tous les liens
Numéro 2.2026 de mt|medizintechnik : https://mt-medizintechnik.de/fokus-auf-personalisierte-medizin/ · Page de connaissances Gestion des risques IA en milieu de soins : https://vamisec.com/fr/wissen/secure-software-development/ki-risikomanagement-medizin · Catégorie Développement sécurisé de logiciels & produits, section Dispositifs médicaux : https://vamisec.com/fr/wissen/secure-software-development#medizinprodukte · AI Act et dispositifs médicaux : https://vamisec.com/fr/ki-vo-medizinprodukte · AI Act de l’UE en bref : https://vamisec.com/fr/wissen/grc/eu-ai-act · Cybersécurité MDR en bref : https://vamisec.com/fr/wissen/grc/mdr-cybersecurity · Threat Modeling : https://vamisec.com/fr/wissen/secure-software-development/threat-modeling · Conseil MDR : https://vamisec.com/fr/mdr
Vous avez des questions sur la sécurité IT de votre organisation ?
Première consultation gratuite →