Dispositif médical logiciel : le parcours réglementaire complet

C’est la question la plus structurante de tout projet de santé, et celle que le plus grand nombre d’équipes repoussent : votre logiciel est-il un dispositif médical ?

Elle mérite d’être posée tôt, parce que la réponse ne modifie pas le projet à la marge — elle le change de nature. Un logiciel non-DM se développe et se commercialise comme n’importe quel produit numérique. Un dispositif médical de classe IIa impose un organisme notifié, un système de management de la qualité, un dossier technique, une évaluation clinique et une surveillance après commercialisation. L’écart se compte en mois de calendrier et en centaines de milliers d’euros.

Le critère unique : la finalité médicale

L’ANSM le formule clairement : certains logiciels sont des dispositifs médicaux parce qu’ils ont une finalité médicale. Ni la technologie employée, ni le canal de distribution, ni le type d’utilisateur n’entrent en ligne de compte.

Est concerné le logiciel destiné à un usage de diagnostic, de prévention, de contrôle, de traitement ou d’atténuation d’une maladie — qu’il soit embarqué dans un matériel ou entièrement autonome. On parle alors de MDSW, medical device software.

Ne le sont pas : la gestion de cabinet, la facturation, la prise de rendez-vous, l’archivage documentaire, la téléconsultation en tant que canal de communication. Le sont en revanche, potentiellement : l’aide à la prescription, le calcul de dose, l’interprétation d’images ou de signaux, le triage, la détection d’événements, l’algorithme de suivi qui alerte un soignant.

Le document de référence est le MDCG 2019-11, qui détaille les critères de qualification et de classification des logiciels au regard du règlement (UE) 2017/745. C’est le texte à lire avant tout autre.

La règle 11 : pourquoi presque tout finit en classe IIa

Si votre logiciel est qualifié, il est classé. Et le règlement a introduit une règle spécifique aux logiciels — la règle 11 de l’annexe VIII — dont l’effet a été massif.

Un logiciel destiné à fournir des informations utilisées pour prendre des décisions à des fins diagnostiques ou thérapeutiques relève au minimum de la classe IIa. Il monte en classe IIb si ces décisions peuvent entraîner une dégradation grave de l’état de santé ou une intervention chirurgicale, et en classe III si elles peuvent causer le décès ou une dégradation irréversible.

La conséquence pratique : depuis l’application du règlement, le 26 mai 2021, une grande partie des logiciels ayant le statut de dispositif médical relèvent au minimum de la classe IIa — c’est-à-dire qu’ils ne peuvent plus être auto-certifiés et nécessitent un organisme notifié. Sous l’ancienne directive, beaucoup de ces mêmes logiciels étaient en classe I.

Le parcours, une fois la qualification établie

1. Déterminer la classe selon la règle 11 et les autres règles de l’annexe VIII.
2. Mettre en place un système de management de la qualité, en pratique structuré selon l’ISO 13485.
3. Structurer le cycle de vie logiciel selon l’IEC 62304, qui définit trois classes de sécurité logicielle — A, B, C — indépendantes de la classe du dispositif.
4. Conduire la gestion des risques selon l’ISO 14971, et l’aptitude à l’utilisation selon l’IEC 62366-1.
5. Constituer le dossier technique et mener l’évaluation clinique.
6. Faire intervenir un organisme notifié dès la classe IIa.
7. Apposer le marquage CE et organiser la surveillance après commercialisation et la matériovigilance.

Chacune de ces étapes fait l’objet d’une page dédiée ci-dessous.

Les trois erreurs les plus coûteuses

Décider de la qualification implicitement. Ne pas se poser la question revient à répondre « non » sans l’avoir instruit. C’est la position la plus fragile, parce qu’elle ne repose sur aucun raisonnement documenté — et c’est précisément ce qu’un partenaire, un investisseur ou une autorité demandera.

Développer d’abord, qualifier ensuite. L’IEC 62304 porte sur le cycle de vie : elle exige des traces de conception, de vérification et de gestion des changements. Un logiciel développé sans ces traces ne peut pas les produire rétroactivement de façon crédible. Il faut souvent reprendre le processus, parfois le code.

Confondre les classes. La classe du dispositif — I, IIa, IIb, III — relève du règlement. La classe de sécurité logicielle — A, B, C — relève de l’IEC 62304 et dépend de la gravité des conséquences d’une défaillance. Les deux sont indépendantes, et les mélanger conduit à dimensionner de travers l’effort d’ingénierie.

Le bon moment pour trancher

Avant le premier sprint. Pas parce que la conformité doit précéder le produit, mais parce que la réponse détermine la façon même de développer : traçabilité des exigences, gestion documentaire des changements, plan de vérification. Ces pratiques s’installent au démarrage pour un coût marginal, et se rétro-installent pour un coût prohibitif.

Si vous hésitez, l’ANSM met à disposition un Guichet Innovation et Orientation pour les questions d’orientation sur les produits. C’est un point d’entrée utile, qui ne dispense pas d’un raisonnement documenté de votre côté.