Logiciel médical : critères de choix entre classe I et IIa

Logiciel médical: critères de choix entre classe I et IIa

Depuis le 26 mai 2021, le Règlement (UE) 2017/745 — le fameux RDM — a mis fin à une habitude particulièrement confortable pour les fabricants de logiciels médicaux: déclarer une application en classe I, apposer le marquage CE sans Organisme Notifié et passer à autre chose. La règle 11 de l’annexe VIII a transformé cette facilité en exception.

La question « logiciel dispositif médical classe I ou IIa » ne se résout donc ni par le support utilisé, ni par le fait que le logiciel soit installé sur un ordinateur, déployé dans le cloud ou distribué sous forme d’application mobile. La classe de risque dépend de la destination d’usage et de l’effet attendu sur la décision clinique. Le reste relève souvent de l’habillage marketing — et l’habillage marketing n’a jamais constitué une base juridique très solide.

La règle 11 du RDM a changé la donne

Sous l’ancienne directive 93/42/CEE, une grande partie des logiciels médicaux était déclarée en classe I. Cette pratique permettait une auto-déclaration de conformité par le fabricant, avec un contrôle externe limité, voire inexistant selon le périmètre retenu. Le logiciel pouvait alors arriver sur le marché avec un dossier technique parfois très léger, une analyse de risques peu convaincante et une destination d’usage formulée dans un langage suffisamment vague pour ne pas engager grand monde.

Le RDM a resserré le dispositif. Sa règle 11 prévoit qu’un logiciel destiné à fournir des informations utilisées pour prendre des décisions à des fins diagnostiques ou thérapeutiques doit être classé au minimum en classe IIa. Le même niveau minimal s’applique aux logiciels destinés à contrôler des processus physiologiques, sauf lorsque le contrôle porte sur des paramètres vitaux et que la variation pourrait entraîner un danger immédiat: dans ce cas, la classe de risque peut être supérieure.

La logique est simple, même si ses conséquences industrielles le sont beaucoup moins: plus le logiciel intervient dans la décision médicale ou dans la conduite d’un processus physiologique, moins le fabricant peut prétendre qu’il ne fait que « présenter des données ».

La règle 11 distingue notamment plusieurs situations:

Attention à la formule « au minimum ». Elle ne signifie pas que tout logiciel médical est automatiquement classé en IIa, mais elle interdit de traiter la classe I comme la catégorie par défaut dès qu’un logiciel produit un résultat en lien avec la santé.

La classe I n’est plus le refuge réglementaire des logiciels dont la destination d’usage a été rédigée à la hâte. Sous le RDM, c’est une exception qui doit se démontrer.

Ce qui peut encore relever de la classe I

La classe I existe toujours. Le RDM n’a pas décidé que toute application utilisée dans un environnement médical devait devenir un dispositif de classe IIa. Ce serait juridiquement excessif et techniquement absurde. En revanche, le fabricant doit démontrer que son logiciel ne répond pas aux critères de décision clinique ou de contrôle physiologique visés par la règle 11.

Le guide MDCG 2019-11 apporte une grille de lecture utile pour qualifier les logiciels dispositifs médicaux. Sa révision 1, publiée en juin 2025, confirme une approche plus structurée et plus exigeante: ce n’est pas le nom du produit, ni son interface, ni sa technologie qui détermine la classe, mais sa destination d’usage et la fonction réellement revendiquée.

Peuvent notamment rester en classe I des logiciels qui apportent une aide sans produire d’information destinée à une décision diagnostique ou thérapeutique. La nuance est étroite. Une aide au calcul de fertilité peut relever de cette catégorie lorsqu’elle est conçue comme une assistance à la planification ou à la conception, sans interprétation clinique autonome. De même, une application d’aide à la communication destinée à des personnes présentant un autisme ou une paralysie cérébrale peut relever de la classe I si elle ne fournit pas d’information utilisée pour diagnostiquer, traiter ou surveiller une pathologie.

La frontière ne se trouve donc pas dans l’étiquette « aide ». Un logiciel qui se présente comme une simple aide mais qui calcule un score, hiérarchise des hypothèses diagnostiques, recommande une conduite thérapeutique ou déclenche une intervention n’est plus un innocent tableau de bord. La finalité fonctionnelle prime sur la modestie lexicale.

Les formulations qui font basculer la qualification

Deux logiciels peuvent exploiter des données similaires et pourtant relever de classes différentes, selon ce qu’ils promettent et selon la manière dont leurs résultats sont utilisés.

Un outil qui se contente de stocker des valeurs saisies par un professionnel et de les afficher sous forme de tableau ne produit pas nécessairement une information clinique nouvelle. Un autre qui détecte une anomalie, calcule une probabilité de complication ou recommande une adaptation de traitement franchit un seuil réglementaire différent.

Dans l’analyse de qualification, il faut examiner au moins les éléments suivants:

• la population ciblée: professionnels de santé, patients, aidants ou grand public;
• la nature des données traitées: données administratives, mesures physiologiques, images, résultats biologiques ou historiques cliniques;
• le traitement effectué par le logiciel: stockage, visualisation, calcul, interprétation, recommandation ou alerte;
• la décision susceptible d’être prise à partir du résultat;
• le degré d’autonomie du professionnel face à la sortie du logiciel;
• les conséquences prévisibles d’une information erronée, tardive ou indisponible;
• les revendications présentes dans la notice, l’interface, la documentation commerciale et les supports de formation.

La réalité est que le logiciel ne sera pas évalué uniquement à partir d’un tableau soigneusement rédigé par le service réglementaire. Les captures d’écran, les vidéos de démonstration et les messages commerciaux peuvent révéler une destination d’usage plus ambitieuse que celle déclarée dans le dossier technique. Une application officiellement limitée à l’affichage de données, mais présentée aux hôpitaux comme un outil de détection précoce, risque de rencontrer quelques difficultés lors d’un audit.

La destination d’usage reste le point de départ

Pour déterminer si un logiciel est un dispositif médical et pour établir sa classe de risque, il faut commencer par sa destination d’usage. C’est le socle de la qualification SaMD, même si l’acronyme anglo-saxon ne dispense personne de respecter le RDM.

La destination d’usage doit décrire ce que le fabricant entend faire du logiciel, pour qui, dans quel contexte et avec quelles conséquences. Une phrase comme « plateforme intelligente d’optimisation des parcours de soins » est peu utile juridiquement. Elle sonne bien dans une présentation commerciale, mais elle ne dit presque rien sur la fonction médicale revendiquée.

À l’inverse, une formulation exploitable doit permettre de comprendre:

1. quelles données entrent dans le système;

2. quelles opérations sont réalisées;

3. quel résultat est fourni;

4. qui utilise ce résultat;

5. dans quelle décision ce résultat peut intervenir;

6. quel risque est associé à une erreur ou à une indisponibilité.

Cette description doit rester cohérente avec le produit réel. Il est inutile de déclarer une fonction strictement administrative si l’algorithme analyse des données cliniques et fournit une recommandation au médecin. Le RDM ne sanctionne pas seulement les logiciels mal conçus; il sanctionne aussi les qualifications artificielles.

Classe I contre classe IIa: le véritable arbitrage

La comparaison entre classe I et classe IIa n’est pas un choix stratégique au sens où le fabricant pourrait sélectionner la catégorie qui lui convient le mieux. C’est une conclusion réglementaire tirée de la destination d’usage, de la fonction et du risque.

La différence est toutefois très concrète pour le calendrier et les ressources du projet.

En classe I standard, le fabricant peut en principe établir lui-même la déclaration de conformité, sous réserve de respecter l’ensemble des exigences applicables du RDM. Cette possibilité ne signifie pas que le dossier technique soit facultatif. Elle signifie que la conformité n’est pas systématiquement vérifiée par un Organisme Notifié avant l’apposition du marquage CE.

En classe IIa, l’intervention d’un Organisme Notifié devient obligatoire. Le fabricant doit préparer une évaluation de conformité adaptée, démontrer la maîtrise de son système qualité et présenter les preuves techniques et cliniques nécessaires. Le passage par un Organisme Notifié ajoute du temps, des échanges documentaires, des écarts à traiter et une contrainte que les présentations investisseurs ont tendance à oublier.

Ne vous y trompez pas: la classe I n’est pas une version « allégée » de la conformité. Elle réduit principalement l’intervention préalable d’un tiers. Les obligations relatives à la sécurité, à la performance, à la gestion des risques, à la documentation et à la surveillance après commercialisation demeurent.

Le guide MDCG 2019-11 impose de regarder chaque module

Les logiciels contemporains sont rarement monolithiques. Ils associent un module de collecte, un moteur de calcul, une interface destinée au professionnel, une application patient, des fonctions d’administration et parfois des services d’hébergement ou d’échange de données. Le fabricant qui classe l’ensemble sous une seule étiquette en espérant que la partie non médicale neutralisera la partie clinique prend une liberté difficile à défendre.

La révision 1 du guide MDCG 2019-11, publiée le 17 juin 2025, introduit une approche modulaire stricte. Chaque module logiciel doit être évalué et classé séparément. Les interactions entre modules médicaux et non médicaux doivent également être documentées.

Cette approche répond à une réalité industrielle: un module de gestion des comptes utilisateurs ne présente pas le même profil qu’un module qui interprète une image médicale, et un module d’affichage ne joue pas le même rôle qu’un moteur qui produit une alerte de risque. Mais si ces modules communiquent, l’analyse ne peut pas s’arrêter à la classification isolée de chacun.

Cartographier les fonctions, pas les écrans

La première erreur consiste à découper le logiciel selon ses écrans ou ses composants techniques. Or la classification doit suivre les fonctions revendiquées et leurs conséquences.

Un logiciel peut comporter:

• un module d’importation de données;
• un module de stockage et de consultation;
• un module de calcul ou d’analyse;
• un module de recommandation;
• un module de notification;
• un module d’administration;
• un module d’interopérabilité avec un dossier médical électronique;
• un module de facturation ou de gestion organisationnelle.

Certains de ces modules peuvent relever d’une fonction médicale, d’autres non. La séparation n’est pas automatique: il faut documenter les flux de données, les dépendances et les effets de bord.

Prenons un exemple simple. Un module d’affichage peut sembler neutre. Mais s’il filtre les résultats, les hiérarchise ou masque certaines valeurs selon un seuil clinique, il ne se contente plus de présenter l’information. Il participe à son interprétation. De la même manière, une alerte peut être classée différemment selon qu’elle signale une échéance administrative ou une suspicion de détérioration clinique.

Le dossier technique doit donc permettre de répondre à une question peu spectaculaire mais décisive: quelle fonction exacte produit quelle information, pour quelle décision, avec quel niveau de risque?

Un logiciel ne devient pas non médical parce que son fabricant a placé la fonction clinique dans un sous-menu baptisé « assistance ». La qualification suit la fonction, pas l’architecture marketing.

Les interfaces doivent être documentées

La modularité impose aussi de documenter les interfaces entre le logiciel médical et les composants externes. Cela concerne les systèmes hospitaliers, les dispositifs connectés, les dossiers médicaux électroniques et les services cloud.

L’hébergement — local, cloud ou hybride — ne modifie pas en lui-même la classe de risque. Une application mobile et un logiciel installé sur un serveur hospitalier sont soumis à la même logique de classification si leur destination d’usage et leur fonction clinique sont identiques.

En revanche, l’environnement technique peut modifier les risques à traiter. Une perte de connexion, une synchronisation incomplète, un horodatage erroné ou une conversion de format peuvent altérer l’information fournie au professionnel. Ces événements doivent apparaître dans l’analyse de risques selon l’ISO 14971, et être couverts par des mesures de maîtrise vérifiables.

La révision 2025 du guide intègre également les exigences d’interopérabilité liées à l’Espace européen des données de santé. Les logiciels connectés aux dossiers médicaux électroniques ne peuvent donc plus considérer l’interopérabilité comme une promesse d’intégration future, séparée du dossier réglementaire. Les formats, les échanges, les droits d’accès, la cohérence des données et la conservation des traces peuvent avoir un impact direct sur la sécurité et les performances du dispositif.

La conformité ne s’arrête pas à la classification

Une fois la classe de risque déterminée, le fabricant doit encore démontrer que le logiciel est conforme aux exigences générales de sécurité et de performance du RDM. C’est ici que certains projets découvrent que la classification n’était pas leur seul problème.

Un logiciel de classe IIa doit disposer d’un dossier technique suffisamment robuste pour permettre à l’Organisme Notifié d’évaluer la conception, les risques, les performances et la documentation clinique. Le produit doit également être intégré dans un système de management de la qualité adapté à son activité.

IEC 62304: le cycle de vie logiciel comme preuve de maîtrise

La norme IEC 62304 constitue une référence structurante pour le cycle de vie du logiciel. Elle ne transforme pas mécaniquement un produit en dispositif conforme, mais elle fournit une méthode reconnue pour organiser les activités de développement, de maintenance, de gestion de configuration, de résolution des anomalies et de mise à jour.

Le fabricant doit notamment être en mesure de montrer:

• comment les exigences logicielles ont été définies;
• comment l’architecture répond à ces exigences;
• comment les composants sont identifiés et maîtrisés;
• comment les tests de vérification ont été conçus et exécutés;
• comment les anomalies sont enregistrées, analysées et clôturées;
• comment les versions sont contrôlées;
• comment les modifications sont évaluées avant déploiement;
• comment la maintenance et les mises à jour sont intégrées au cycle de vie.

Une démonstration réalisée sur la dernière version ne remplace pas l’historique de développement. Un procès-verbal de test sans exigence correspondante ne constitue pas une preuve de couverture. Et une correction déployée directement en production, sans évaluation de son impact réglementaire, n’est pas une stratégie de maintenance: c’est un incident en attente de qualification.

ISO 14971: traiter les risques du logiciel et de son usage

La norme ISO 14971 impose une gestion des risques liée au dispositif dans son ensemble. Pour un logiciel médical, le risque ne se limite pas à une erreur de code.

Il faut examiner les conséquences d’une donnée absente, incorrecte, dupliquée, mal interprétée ou présentée hors contexte. Il faut aussi considérer l’utilisateur, l’environnement d’emploi, la dépendance à d’autres systèmes et les scénarios raisonnablement prévisibles de mauvaise utilisation.

Quelques risques typiques peuvent concerner:

• une unité de mesure mal interprétée;
• un seuil clinique configuré sur une mauvaise population;
• une alerte générée avec un retard incompatible avec la décision attendue;
• une donnée provenant d’un dispositif tiers associée au mauvais patient;
• une mise à jour qui modifie le comportement de l’algorithme;
• une indisponibilité du service cloud pendant une période critique;
• une interface qui présente une recommandation sans afficher les limites ou les données sous-jacentes.

L’analyse de risques doit être reliée aux exigences, aux tests et aux mesures de maîtrise. La phrase « le professionnel conserve la décision finale » ne suffit pas à neutraliser un risque si, dans les faits, le logiciel présente une recommandation comme la conclusion la plus probable et la plus visible.

Évaluation clinique et surveillance après commercialisation

La classe IIa implique une attention particulière à l’évaluation clinique. Le fabricant doit démontrer que le logiciel atteint les performances revendiquées et qu’il peut être utilisé dans les conditions prévues avec un niveau de sécurité acceptable.

La preuve clinique doit être cohérente avec la destination d’usage. Une étude portant sur un logiciel différent, une population différente ou une fonction différente ne devient pas pertinente par simple proximité technologique. Les performances d’un algorithme ne se déduisent pas non plus d’une démonstration commerciale réalisée sur quelques cas favorables.

Après la mise sur le marché, la surveillance se poursuit. Les réclamations, incidents, erreurs récurrentes, écarts de performance, retours utilisateurs et tendances doivent être analysés. La matériovigilance ne constitue pas une formalité administrative déclenchée uniquement lorsqu’un événement fait la une. Elle doit permettre de détecter les signaux faibles avant qu’ils ne deviennent un problème de sécurité ou un rappel.

Un logiciel modifié de manière substantielle peut aussi nécessiter une nouvelle analyse de conformité. Ajouter une fonction d’interprétation clinique, modifier un algorithme, changer une population cible ou connecter une nouvelle source de données ne relève pas nécessairement d’une simple mise à jour technique. La qualification de la modification doit être documentée.

Comment arbitrer entre classe I et classe IIa sans fabriquer une fiction réglementaire

Le choix ne consiste pas à rechercher la formulation la moins contraignante. Il consiste à établir une qualification défendable, cohérente avec le produit, sa documentation et son usage réel.

Pour un projet en phase de conception, une méthode pragmatique peut suivre cinq étapes:

1. Fixer la destination d’usage avant la stratégie commerciale.

Décrivez la fonction médicale, l’utilisateur, les données et les décisions concernées. Si la promesse commerciale vient ensuite contredire cette description, le problème est déjà identifié.

2. Décomposer les fonctions et les modules.

Séparez les fonctions de stockage, d’affichage, de calcul, d’interprétation, d’alerte et d’administration. Analysez les interactions plutôt que de classer le produit comme un bloc indifférencié.

3. Appliquer la règle 11 à chaque fonction clinique.

Demandez si le logiciel fournit une information utilisée pour une décision diagnostique ou thérapeutique, ou s’il contrôle un processus physiologique. Si la réponse est oui, la classe IIa devient le point de départ réglementaire, pas une hypothèse lointaine.

4. Évaluer les conséquences d’une erreur.

Une erreur sans conséquence clinique ne se traite pas comme une alerte erronée susceptible de retarder une prise en charge. Les paramètres vitaux et les décisions immédiates peuvent conduire à une classe supérieure.

5. Aligner le dossier sur le produit réellement déployé.

Les versions, interfaces, connexions, algorithmes et supports commerciaux doivent raconter la même histoire réglementaire. Un dossier prudent et un produit présenté comme révolutionnaire ne resteront pas longtemps compatibles.

Cette démarche évite deux excès fréquents. Le premier consiste à surclasser systématiquement tous les logiciels par prudence, sans analyser les fonctions. Le second consiste à maintenir artificiellement la classe I en supprimant les mots qui dérangent, tout en conservant les fonctionnalités qui justifient précisément une classe IIa.

Le verdict: la classe IIa est souvent la qualification réaliste

Pour un logiciel qui fournit une information utilisée dans une décision diagnostique ou thérapeutique, la réponse est claire: la règle 11 du RDM impose une classe IIa au minimum. Le fabricant doit prévoir l’intervention d’un Organisme Notifié, structurer son système qualité et constituer un dossier technique capable de soutenir une évaluation externe.

La classe I reste possible lorsqu’il n’existe pas d’impact décisionnel clinique direct ni de fonction de contrôle physiologique relevant de la règle 11. Les applications d’aide à la conception ou d’aide à la communication peuvent entrer dans ce périmètre, à condition que leur destination d’usage et leurs fonctionnalités réelles le justifient.

Le meilleur critère de choix n’est donc pas le coût immédiat de la procédure, ni la rapidité d’un marquage CE obtenu sur déclaration. C’est la cohérence entre la fonction revendiquée, la classe de risque, les preuves produites et l’usage réel du logiciel. Une qualification en classe I qui ne résiste pas à l’examen d’un Organisme Notifié, d’une autorité compétente ou d’un dossier de matériovigilance n’est pas une économie: c’est un passif réglementaire différé.

La réalité est que le RDM a déplacé la question. Il ne s’agit plus de savoir comment faire entrer un logiciel médical en classe I, mais de démontrer honnêtement pourquoi il pourrait encore y rester. Pour les logiciels qui influencent une décision clinique, la classe IIa n’est pas une punition administrative. C’est la conséquence prévisible de la fonction que le fabricant a choisi de vendre.