Guide 2026 : Logiciel devenu dispositif médical, MDR & AI Act

L'essentiel en 30 secondes

Introduction

Lorsqu’un hôpital décide de moderniser son dossier patient informatisé (DPI), le questionnaire d’achat pose souvent une question apparemment simple : « Le logiciel est‑il un dispositif médical ? » La réponse détermine si le fournisseur doit fournir un marquage CE, un dossier technique et un plan de surveillance post‑commercialisation au titre du Règlement Européen sur les Dispositifs Médicaux (MDR) ¹. En parallèle, l’AI Act de l’UE, entré en vigueur en 2024, ajoute une seconde série d’obligations pour toute fonction d’IA qui influence les décisions cliniques.

Le DPI intelligent de Galeon a été construit main‑dans‑la‑main avec les cliniciens depuis 2016, est aujourd’hui déployé dans 19 hôpitaux (dont deux centres universitaires) et traite plus de trois millions de dossiers patients. Son modèle de données est validé par les soignants, prêt à la recherche, et conforme à la certification HDS 2024 – le référentiel français d’hébergement de données de santé aligné sur la norme ISO 27001:2022 ². Galeon montre ainsi comment un DPI moderne peut rester dans le périmètre « non‑dispositif » tout en proposant une assistance à la décision enrichie par l’IA.

« Le but médical prévu est le seul déterminant de l’applicabilité du MDR », indique le guide de la Commission européenne sur les logiciels médicaux ³. Cet article précise ce critère, parcourt les classifications, fait le lien avec l’AI Act et propose une checklist de questions à poser à tout fournisseur avant de signer.

L’usage médical prévu suffit‑il à qualifier le logiciel de dispositif médical ?

Oui. Selon l’article 2(1) du MDR, un « dispositif médical » désigne tout instrument ou logiciel dont le but prévu est de diagnostiquer, prévenir, surveiller, traiter ou soulager une maladie.

Ainsi, un module qui se contente de stocker ou transmettre des données patients – même hébergé sur un serveur certifié HDS – n’est pas un dispositif médical. En revanche, un algorithme qui prédit le risque de sepsis et déclenche une alerte pour les cliniciens constitue un dispositif médical logiciel, son usage étant l’aide à la décision clinique.

Pour les DSI, la mise en pratique consiste à consigner l’usage prévu dans le dossier d’achat ; le régulateur examinera d’abord cette description.

Quelles sont les classes de classification MDR pour les logiciels médicaux ?

Classes I, IIa, IIb et III. La classification dépend du risque que le logiciel représente pour la santé du patient.

• Classe I (risque faible) : Outils de gestion de données non invasifs, par exemple des modules de planification simples.
• Classe IIa : Logiciels fournissant une information qui influence la décision clinique sans agir de façon autonome, comme les calculateurs de risque.
• Classe IIb : Logiciels qui pilotent des interventions thérapeutiques ou proposent des recommandations de dosage automatisées.
• Classe III (risque élevé) : Logiciels de support ou de maintien de fonctions vitales, par exemple les pompes à insuline en boucle fermée.

Chaque classe déclenche un parcours d’évaluation de conformité spécifique (auto‑déclaration pour la classe I, recours à un organisme notifié à partir de la classe IIa) ⁴. Les responsables informatiques doivent vérifier que le dossier technique du fournisseur correspond à la classe déclarée.

Où le DPI s’arrête‑t‑il et où le dispositif médical commence‑t‑il ?

La frontière se situe dès que le logiciel effectue une interprétation clinique autonome. Un DPI qui se contente d’afficher les résultats de laboratoire reste un dépôt de données (non‑dispositif). Ajouter un moteur de règles qui signale des valeurs anormales et propose un protocole de traitement vous fait entrer dans le domaine de la classe IIa.

Le DPI de Galeon illustre cette scission : la couche de stockage de base est un entrepôt de données certifié HDS, tandis que le module prédictif alimenté par Swarm Learning® – qui ne fait jamais sortir les données du site – est certifié CE comme classe IIa.

Les chefs de division clinique devraient demander un cartographie claire de chaque fonctionnalité par rapport à la classification MDR.

Comment le MDR et l’AI Act se recoupent‑ils pour les logiciels hospitaliers ?

Les deux régimes s’appliquent lorsqu’une IA a un but médical et est classée « high‑risk » au titre de l’AI Act. L’AI Act définit l’« IA à haut risque » comme les systèmes utilisés pour le diagnostic, le traitement ou le triage médical – exactement les fonctions que le MDR considère comme des dispositifs médicaux.

Points d’intersection clés :

• Évaluation de conformité : Le MDR impose le marquage CE ; l’AI Act ajoute un dossier d’évaluation de conformité pour les IA à haut risque, incluant la gouvernance des données et les mesures de transparence.
• Surveillance post‑commercialisation : Les deux textes exigent une veille, mais l’AI Act introduit un volet de suivi des risques systémiques pour les modèles d’IA qui évoluent après le déploiement.
• Documentation : L’AI Act requiert un « registre du système d’IA » en complément du dossier technique MDR – un élément naturellement présent dans les traces d’audit générées par Swarm Learning®.

Il est important de noter que toutes les fonctions d’IA ne sont pas à haut risque. Un tableau de bord qui visualise les tendances à l’échelle de la population est uniquement soumis au MDR (s’il a un but médical) et n’entre pas dans les dispositions haut‑risque de l’AI Act ⁵.

Quelles questions poser à un éditeur avant de signer ?

Concentrez‑vous sur l’usage prévu, la classification et les preuves de conformité.

• Quel est le but médical déclaré de chaque module ?
• À quelle classe MDR le logiciel appartient‑il, et pouvez‑vous fournir le certificat CE ?
• L’IA est‑elle considérée comme à haut risque selon l’AI Act ? Le cas échéant, pouvez‑vous partager le registre du système d’IA ?
• Comment garantissez‑vous que les données ne quittent jamais l’hôpital (par ex. architecture Swarm Learning®) ?
• L’environnement d’hébergement est‑il certifié HDS 2024 ?
• Quel est votre plan de surveillance post‑commercialisation et comment gérez‑vous les mises à jour ?
• Pouvez‑vous fournir une cartographie de chaque bloc fonctionnel avec son statut réglementaire ?

Des réponses précises protègent l’hôpital des sanctions de non‑conformité et assurent que la technologie s’intègre aux flux de travail cliniques.

Comment les approches traditionnelles se comparent‑elles au DPI intelligent de Galeon ?

Limites et défis à connaître

• Retard réglementaire : Le MDR et l’AI Act évoluent ; des réinterprétations peuvent faire passer un logiciel de classe IIa à IIb après une mise à jour.
• Charge de travail du dossier technique : Maintenir un dossier CE pour chaque module d’IA nécessite du personnel dédié et peut ralentir l’innovation.
• Contraintes d’interopérabilité : Bien que Swarm Learning® préserve la souveraineté des données, l’intégration aux PACS ou systèmes de laboratoire legacy peut requérir des adaptateurs spécifiques.
• Fardeau de la surveillance post‑commercialisation : Les hôpitaux doivent collecter et déclarer les performances réelles, ce qui impose une infrastructure de suivi robuste.
• Manque de compétences : Le personnel clinique doit comprendre la différence entre fonctions purement de données et assistance à la décision régulée afin d’éviter les usages détournés.

FAQ

Dois‑je marquer CE chaque module de mon DPI ?
Seuls les modules destinés à un usage clinique nécessitent le marquage CE ; les outils purement administratifs sont exclus.

Un logiciel classé Classe I peut‑il être commercialisé sans organisme notifié ?
Oui, les dispositifs de Classe I reposent sur une auto‑déclaration de conformité, mais un dossier technique doit néanmoins être conservé.

Mon outil de triage basé sur l’IA est‑il automatiquement « high‑risk » au titre de l’AI Act ?
Si l’outil influence les décisions de triage des patients, il est considéré à haut risque et doit satisfaire aux exigences de l’AI Act.

Comment Swarm Learning® impacte‑t‑il la conformité au RGPD ?
Comme les données ne quittent jamais le pare‑feu de l’hôpital, les règles de transfert transfrontalier du RGPD ne s’appliquent pas ; il faut néanmoins une base légale de traitement.

Que se passe‑t‑il lorsqu’un modèle IA marqué CE est mis à jour ?
Les mises à jour mineures peuvent être couvertes par l’évaluation de conformité initiale ; les changements majeurs affectant la classe de risque exigent un nouveau marquage CE.

En résumé

Le facteur décisif pour savoir si un logiciel hospitalier est un « dispositif médical logiciel » réside dans son usage médical prévu, tel que défini par le MDR. Une fois cet usage confirmé, la classe de risque (I‑III) conditionne la profondeur de l’évaluation de conformité, le besoin de marquage CE et les obligations de surveillance post‑commercialisation. L’AI Act ajoute un jeu parallèle d’obligations pour les systèmes d’IA à haut risque, dont la plupart recoupent les exigences du MDR, créant ainsi un paysage de conformité unifié qui peut être maîtrisé à l’aide d’un dossier technique structuré.

Le DPI intelligent de Galeon montre qu’un DPI moderne peut garder son noyau de stockage de données hors du périmètre dispositif tout en offrant des modules d’aide à la décision IA marqués CE, respectueux de la souveraineté des données grâce à Swarm Learning®. En posant les bonnes questions dès le départ – usage, classe, preuve CE, statut AI Act et certification d’hébergement – les hôpitaux limitent les risques de non‑conformité, protègent la sécurité des patients et tirent profit de l’innovation IA.

Découvrez comment un DPI intelligent simplifie conformité et innovation

Sources

• Règlement Européen sur les Dispositifs Médicaux (MDR) 2017/745
• Proposition d’AI Act de l’UE 2021/0806
• CNIL – certification HDS 2024 (alignée ISO 27001:2022)
• Ministère des Solidarités et de la Santé – statistiques des données de santé 2025
• Galeon – Certification HDS en 2026, ce que chaque hôpital doit vérifier avant de signer
• Galeon – DPI intelligent vs DPI traditionnel, pourquoi les hôpitaux basculent vers l’IA

‍