Classification d'un logiciel DM : comprendre la règle 11

La règle 11 est la disposition qui a le plus transformé le marché du logiciel médical européen. Beaucoup d’éditeurs qui étaient confortablement en classe I sous l’ancienne directive se sont retrouvés en classe IIa, c’est-à-dire face à un organisme notifié.

Ce que dit la règle

Le règlement l’a introduite pour traiter spécifiquement les risques liés à l’information fournie par un dispositif actif, catégorie à laquelle appartiennent les logiciels. Sa logique : plus l’information pèse dans la décision de soin, et plus les conséquences d’une erreur sont graves, plus la classe est élevée.

Situation	Classe
Logiciel fournissant des informations utilisées pour des décisions diagnostiques ou thérapeutiques	IIa au minimum
…si ces décisions peuvent entraîner une dégradation grave de l’état de santé ou une intervention chirurgicale	IIb
…si elles peuvent entraîner le décès ou une dégradation irréversible de l’état de santé	III
Logiciel destiné à surveiller des processus physiologiques	IIa
…s’il surveille des paramètres physiologiques vitaux dont la variation peut créer un danger immédiat	IIb
Tous les autres logiciels	I

Pourquoi presque tout finit au moins en IIa

Le seuil d’entrée en classe IIa est bas : il suffit que l’information serve à prendre une décision diagnostique ou thérapeutique. Ni la sophistication du traitement, ni le caractère contraignant de la recommandation ne sont exigés.

Un logiciel qui affiche un score, met en évidence une anomalie, priorise une liste de patients ou signale une valeur hors norme fournit une information utilisée pour décider. C’est la raison pour laquelle l’ANSM constate qu’une grande partie des logiciels ayant le statut de DM relèvent au minimum de la classe IIa depuis le 26 mai 2021.

L’argument « la décision reste au médecin » est le plus souvent avancé et le plus systématiquement écarté : la règle vise l’usage de l’information, pas son caractère impératif.

Ce que chaque classe change réellement

Classe I — Déclaration de conformité établie par le fabricant, sans organisme notifié, sauf sous-catégories particulières. Toutes les autres obligations subsistent : système qualité, dossier technique, évaluation clinique, surveillance après commercialisation.

Classe IIa — Intervention d’un organisme notifié. C’est le vrai saut : disponibilité de l’organisme, délais d’évaluation, coûts d’audit, cycle d’échanges sur le dossier. C’est aussi le point où le calendrier cesse d’être sous votre contrôle.

Classe IIb — Même logique avec un niveau d’exigence supérieur sur l’évaluation clinique et le dossier technique.

Classe III — Régime le plus exigeant, avec des exigences renforcées en matière de preuve clinique.

Les deux difficultés d’application

Apprécier la gravité

Le passage de IIa à IIb ou III repose sur des notions — dégradation grave, irréversible, intervention chirurgicale — qui s’apprécient au regard du scénario clinique réel, pas du pire cas imaginable. Un raisonnement fondé sur des scénarios extrêmes conduit à une sur-classification qui coûte des mois ; un raisonnement complaisant est refusé par l’organisme notifié.

La bonne méthode consiste à s’appuyer sur l’analyse de risques ISO 14971 et à argumenter chaque scénario dans le dossier technique.

Gérer la concurrence entre règles

La règle 11 ne supprime pas les autres règles de l’annexe VIII. Si plusieurs s’appliquent, c’est la classification la plus élevée qui l’emporte. Un logiciel qui pilote un dispositif ou en constitue un accessoire peut relever d’une autre règle et d’une classe supérieure.

L’implication à retenir pour votre feuille de route

La classification n’est pas un jalon administratif : elle détermine votre calendrier commercial. Entre un logiciel de classe I mis sur le marché sur la base d’une déclaration de conformité et un logiciel de classe IIa dépendant de la disponibilité d’un organisme notifié, l’écart de délai se compte en trimestres.

C’est pour cette raison que la classification doit être établie — et si possible confortée par un avis extérieur — avant que les choix d’architecture et de périmètre fonctionnel ne soient figés. Une fonctionnalité qui fait passer de IIa à IIb mérite d’être arbitrée en connaissance de cause, pas découverte en cours d’évaluation.