Réponse courte : lorsqu'un logiciel a une finalité médicale (diagnostic, prévention, surveillance, prédiction, pronostic, traitement), il est considéré comme un dispositif médical selon le Règlement européen sur les dispositifs médicaux (MDR, 2017/745) et reçoit une classe de risque : I, IIa, IIb ou III, principalement selon la Règle 11 de l'Annexe VIII. La classe détermine si vous pouvez vous auto-certifier (classe I uniquement) ou si vous avez besoin d'un organisme notifié, ainsi que la profondeur de l'évaluation clinique et le déroulement de la surveillance post-commercialisation. Parallèlement, la norme d'ingénierie IEC 62304 attribue au logiciel une classe de sécurité : A (aucun dommage possible), B (dommage non grave possible) ou C (mort ou dommage grave possible), qui définit la documentation, la conception et les tests requis pour le cycle de vie. Les deux classifications sont liées mais indépendantes, et toutes deux sont déterminées par le préjudice que le logiciel pourrait causer, et non par sa complexité.
Étape 1 : Est-ce un dispositif du tout ?
Un logiciel est considéré comme un dispositif médical selon le MDR européen lorsque son usage prévu est médical : diagnostic, prévention, surveillance, prédiction, pronostic ou traitement (Article 2(1)). Un logiciel qui se contente de stocker, archiver, communiquer, afficher ou rechercher des données n'est pas un dispositif ; un logiciel qui crée ou modifie des informations médicales pour soutenir une décision de diagnostic ou de traitement l'est, selon le MDCG 2019-11.
La définition du MDR (Article 2(1)) repose sur la finalité. Les logiciels qui stockent, archivent, communiquent, affichent ou effectuent des recherches simples sur des données ne sont pas des dispositifs (le MDCG 2019-11 le précise). Les logiciels qui créent ou modifient des informations médicales pour soutenir une décision de diagnostic ou de traitement le sont. Un enregistrement qui montre une valeur de laboratoire avec la plage de référence du laboratoire ne l'est pas ; un logiciel qui indique à l'utilisateur que la valeur indique une condition, ou recommande une dose, l'est. Voir Une application de santé est-elle un dispositif médical ? pour plus de détails sur l'étape de qualification.
Étape 2 : La classe de risque MDR, Règle 11
La Règle 11 du MDR classe les logiciels de dispositifs médicaux en fonction du préjudice qu'une décision erronée pourrait causer. Les logiciels fournissant des informations pour des décisions diagnostiques ou thérapeutiques sont de classe IIa par défaut, de classe IIb si de telles décisions peuvent entraîner une grave détérioration ou une chirurgie, et de classe III si elles peuvent entraîner la mort ou une détérioration irréversible. Les logiciels de surveillance sont de classe IIa, ou IIb pour les paramètres vitaux.
| Logiciel destiné à… | Classe MDR |
|---|---|
| fournir des informations utilisées pour prendre des décisions à des fins diagnostiques ou thérapeutiques (par défaut) | IIa |
| …où de telles décisions peuvent entraîner la mort ou une détérioration irréversible de la santé | III |
| …où de telles décisions peuvent entraîner une grave détérioration de la santé ou une intervention chirurgicale | IIb |
| surveiller des processus physiologiques (par défaut) | IIa |
| …surveiller des paramètres physiologiques vitaux dont les variations pourraient entraîner un danger immédiat pour le patient | IIb |
| tout autre cas (logiciel qui est un dispositif mais aucun des cas ci-dessus) | I |
La Règle 11 a fait passer la plupart des logiciels auparavant classés en classe I à la classe IIa ou supérieure, ce qui explique principalement pourquoi le MDR a été perçu comme un changement majeur pour la santé numérique. Le MDCG 2019-11 et le cadre de risque de l'IMDRF (importance de l'information × état de la situation sanitaire) aident à classer les cas limites. Les logiciels qui pilotent ou influencent un dispositif matériel reprennent la classe de ce dispositif (Règle 3.3 des règles de mise en œuvre).
Conséquences par classe : la classe I est auto-déclarée avec un dossier technique et un enregistrement, sans organisme notifié (sauf Im, Is, Ir) ; la classe IIa nécessite une évaluation par un organisme notifié du système qualité et un échantillon de documentation technique ; la classe IIb la même chose avec un examen plus approfondi de la documentation ; la classe III un examen complet de la documentation technique et, le cas échéant, une consultation d'un groupe d'experts. Toutes les classes nécessitent un système de management de la qualité, une évaluation clinique proportionnée à la classe, une personne responsable de la conformité réglementaire, un UDI, un enregistrement dans EUDAMED, une surveillance post-commercialisation et une vigilance.
Étape 3 : La classe de sécurité logicielle IEC 62304
La classe de sécurité logicielle IEC 62304 évalue les logiciels de dispositifs médicaux en fonction du pire préjudice auquel ils pourraient contribuer, après les contrôles de risque externes : classe A lorsqu'aucun préjudice n'est possible, classe B lorsqu'un préjudice non grave est possible, classe C lorsqu'un décès ou un préjudice grave est possible. La classe détermine le niveau d'exigence en matière de conception, de vérification et de documentation pour le cycle de vie du logiciel.
La norme IEC 62304 (2006, amendée en 2015) est la norme harmonisée pour les processus du cycle de vie des logiciels de dispositifs médicaux. Sa classe de sécurité découle de la pire situation dangereuse à laquelle le logiciel peut contribuer, après prise en compte des mesures de maîtrise des risques externes au logiciel :
| Classe | Situation dangereuse pourrait entraîner… | Ce que le cycle de vie exige |
|---|---|---|
| A | aucun dommage ou atteinte à la santé | Plan de développement logiciel, exigences, publication ; résolution de problèmes ; gestion de la configuration |
| B | dommage non grave | A : plus conception architecturale, vérification de l'intégration et des tests système, vérification unitaire documentée |
| C | mort ou dommage grave | B : plus conception détaillée pour chaque unité, ségrégation architecturale supplémentaire, vérification plus rigoureuse |
Les classes sont attribuées par système logiciel et peuvent être attribuées par élément logiciel après décomposition, de sorte que seules les parties à risque portent la rigueur de la classe C ; la norme explique l'argument de ségrégation requis. L'ISO 14971 (gestion des risques) alimente la classification ; l'IEC 82304-1 ajoute des exigences au niveau du produit pour les logiciels de santé exécutés sur des plateformes à usage général (téléphones, cloud).
Comment les deux interagissent
La classe de risque MDR et la classe de sécurité IEC 62304 sont indépendantes : la classe MDR (I à III) détermine la voie réglementaire et l'implication d'un organisme notifié, tandis que la classe IEC 62304 (A à C) détermine la rigueur du processus d'ingénierie. Une application de classe IIa peut être de classe 62304 B ou C en fonction du préjudice qu'une sortie erronée pourrait causer.
La classe MDR concerne la voie réglementaire ; la classe IEC 62304 concerne le processus d'ingénierie. Une application de classe IIa selon la Règle 11 pourrait être de classe IEC 62304 B (des informations erronées pourraient entraîner un retard non grave dans les soins) ou C (si une suggestion de dose erronée pouvait être mortelle). Un dispositif de classe I est généralement de classe 62304 A, mais pas nécessairement. Les organismes notifiés s'attendent à ce que le dossier technique montre la classe 62304 avec sa justification, les documents du cycle de vie à ce niveau, et le lien avec le dossier de gestion des risques. La cybersécurité (MDCG 2019-16, IEC 81001-5-1) est évaluée en parallèle.
Exemple concret
Exemple concret de SaMD : une application de suivi des symptômes qui enregistre, affiche et partage les symptômes n'est pas un dispositif médical. L'ajout d'une fonctionnalité qui évalue les symptômes selon une échelle validée et indique à l'utilisateur quand consulter fait de cette application un dispositif, de classe IIa par défaut selon la Règle 11 du MDR, avec une classe IEC 62304 B, ou classe C pour un cas d'usage cardiaque.
Une application de suivi des symptômes qui permet aux utilisateurs d'enregistrer leurs symptômes, de visualiser les tendances et de les partager avec leur médecin : pas un dispositif (stockage, affichage, communication). La même application ajoute une fonctionnalité qui évalue les symptômes enregistrés par rapport à une échelle validée et indique à l'utilisateur quand le score suggère qu'il devrait consulter : maintenant un dispositif, classe IIa par défaut selon la Règle 11 (informations pour une décision diagnostique ; un "pas besoin de consulter" erroné pourrait retarder le traitement, grave mais pas typiquement irréversible, donc pas IIb ou III sauf si la condition ciblée le rend ainsi). IEC 62304 : un faux sentiment de sécurité pourrait entraîner un retard de soins, non grave à grave selon la condition, donc classe B, potentiellement C pour un cas d'utilisation cardiaque. Voie : ISO 13485 QMS, organisme notifié, évaluation clinique de l'échelle, ingénierie de l'utilisabilité (IEC 62366-1), surveillance post-commercialisation.
Les États-Unis, brièvement
Aux États-Unis, la FDA réglemente les logiciels en tant que dispositifs médicaux selon leur usage prévu, avec les classes I, II et III et les voies d'approbation 510(k), De Novo et PMA. Le 21st Century Cures Act exclut les logiciels administratifs, les produits de bien-être général, les dossiers de santé électroniques et certains dispositifs d'aide à la décision clinique du statut de dispositif. La FDA reconnaît l'IEC 62304 comme une norme consensuelle.
La FDA réglemente les logiciels en tant que dispositifs médicaux selon la même logique de finalité, avec les classes I, II et III et les voies 510(k), De Novo et PMA. Le 21st Century Cures Act (section 3060) a retiré plusieurs catégories du statut de dispositif : logiciels administratifs, bien-être général, dossiers de santé électroniques et aide à la décision clinique qui permet au clinicien d'examiner indépendamment la base de la recommandation (la guidance 2022 de la FDA sur le CDS l'interprète de manière restrictive). La FDA reconnaît l'IEC 62304 comme une norme consensuelle et, depuis 2023, exige une documentation sur la cybersécurité pour les "dispositifs cyber". L'ISO 13485 est devenue la base du règlement sur les systèmes qualité américains (QMSR) en 2026.
Chez Anpheros
Anpheros Daily stocke, affiche et partage ; il n'évalue pas, n'interprète pas et ne recommande pas, et sa finalité l'indique. Il n'est donc pas un dispositif médical selon la Règle 11 ou les exclusions du Cures Act, et l'équipe applique une sécurité de type ISO 27001 et des pratiques logicielles documentées sans passer par la voie des dispositifs. Si une fonctionnalité avec une finalité médicale était ajoutée, elle serait classifiée selon la Règle 11 et développée selon l'IEC 62304 avant sa mise sur le marché. Voir Transparence de la santé.
Cette page explique la réglementation pour les équipes produit et ingénierie. Il ne s'agit pas d'un avis juridique ; les textes liés dans Sources font autorité, et votre délégué à la protection des données, organisme notifié ou conseiller décide pour votre cas. Dernière révision : Octobre 2026.
Pages connexes
- Une application de santé est-elle un dispositif médical ? Règle 11 du MDR UE
- MDR vs IVDR
- Explication de CDS Hooks
- Carte de la réglementation des données de santé
- Le règlement européen sur l'IA et l'IA dans la santé
Sources
- Règlement (UE) 2017/745 (MDR), Annexe VIII, EUR-Lex
- MDCG 2019-11 : Qualification et classification des logiciels
- IEC 62304:2006+AMD1:2015, Processus du cycle de vie des logiciels de dispositifs médicaux
- IEC 82304-1:2016, Sécurité des produits logiciels de santé
- FDA : Guidance sur les logiciels d'aide à la décision clinique (2022)
- FDA : Logiciel en tant que dispositif médical
Questions fréquentes
Un logiciel peut-il être de classe I selon le MDR ?
Oui, mais rarement : uniquement les logiciels ayant une finalité médicale qui n'informent pas les décisions diagnostiques ou thérapeutiques et ne surveillent pas les processus physiologiques. La plupart des applications qui sont considérées comme des dispositifs entrent dans la classe IIa.
Un dispositif de classe IIa nécessite-t-il des essais cliniques ?
Il nécessite une évaluation clinique, qui peut s'appuyer sur la littérature, l'équivalence et les données de performance ; une investigation clinique est requise lorsque les preuves existantes sont insuffisantes. Les logiciels qui revendiquent une performance diagnostique nécessitent généralement leur propre étude de performance.
L'IEC 62304 est-elle obligatoire ?
C'est une norme harmonisée, donc son respect est la présomption de conformité aux exigences logicielles du MDR (Annexe I, 17). Vous pouvez utiliser une autre approche, mais vous devez alors prouver l'équivalence, ce que personne ne fait en pratique.
Qu'en est-il des fonctionnalités d'IA ?
Les mêmes règles s'appliquent, ainsi que le règlement européen sur l'IA : un dispositif avec une évaluation par un organisme notifié est un système d'IA à haut risque selon l'Annexe I, avec des exigences sur les données, la journalisation, la transparence et la supervision humaine évaluées conjointement avec le MDR.
Essayez gratuitement dans le sandbox
Votre premier appel FHIR en 5 minutes. Une API HL7 FHIR R4 avec le consentement du patient intégré : essayez-la dans le bac à sable, puis connectez votre propre application ou système de clinique.
Gratuit · 30 patients synthétiques · sans carte
Anpheros développe un dossier médical que le patient contrôle et peut partager avec n'importe quelle clinique, sur une plateforme HL7 FHIR R4, basée en UE. Ces guides vous aident à comprendre et organiser votre santé ; ils ne remplacent pas votre médecin.
À propos d'Anpheros →