Un éditeur nous appelle. Son logiciel est sur le marché depuis six ans, marqué CE en classe I sous la directive 93/42/CEE, auto-certifié. Il vient de recevoir une demande de justification. Sa question tient en une phrase : est-ce qu'on est toujours en classe I ?
Dans la majorité des cas que nous voyons, la réponse est non. Et le décalage vient rarement d'une erreur d'origine : il vient de ce que le MDR a créé une règle qui n'existait pas dans la directive. La règle 11.
1. D'abord la qualification, ensuite la classification
Une confusion revient sans cesse, et elle fait perdre des semaines : la règle 11 ne sert pas à déterminer si votre logiciel est un dispositif médical. Elle ne s'applique qu'après que cette question a été tranchée.
Deux étapes, dans cet ordre :
- La qualification — mon produit est-il un dispositif médical ? Elle se décide sur la définition de l'article 2 du MDR.
- La classification — si oui, dans quelle classe ? C'est là qu'intervient l'annexe VIII et sa règle 11.
Pour la qualification, le critère est la destination revendiquée par le fabricant. Pas la technologie, pas la complexité, pas le fait qu'un professionnel de santé l'utilise. Un logiciel est un dispositif médical s'il est destiné par son fabricant à un usage de diagnostic, prévention, contrôle, prédiction, pronostic, traitement ou atténuation d'une maladie.
Le guide MDCG 2019-11 pose un critère utile : un logiciel doit effectuer une action sur des données allant au-delà du stockage, de l'archivage, de la communication ou d'une recherche simple. Un système qui range des documents n'est pas un dispositif médical. Un système qui calcule, interprète, croise ou score l'est probablement.
Un logiciel de gestion de cabinet, un DPI, un outil de facturation, une messagerie sécurisée de santé ne sont pas des dispositifs médicaux. Ils manipulent des données de santé — ce qui pose d'autres obligations, notamment RGPD et hébergement de données de santé — mais ce n'est pas la même question.
2. Ce que dit exactement la règle 11
Le texte tient en trois alinéas. Le voici, parce que la plupart des discussions viennent de ce que personne ne l'a lu en entier :
« Les logiciels destinés à fournir des informations utilisées pour prendre des décisions à des fins diagnostiques ou thérapeutiques relèvent de la classe IIa, sauf si ces décisions ont une incidence susceptible de causer :
- la mort ou une détérioration irréversible de l'état de santé d'une personne, auquel cas ils relèvent de la classe III, ou
- une grave détérioration de l'état de santé d'une personne ou une intervention chirurgicale, auquel cas ils relèvent de la classe IIb.
Les logiciels destinés à contrôler des processus physiologiques relèvent de la classe IIa, sauf s'ils sont destinés à contrôler des paramètres physiologiques vitaux, lorsque la nature des variations de ces paramètres est telle qu'elle pourrait présenter un danger immédiat pour le patient, auquel cas ils relèvent de la classe IIb.
Tous les autres logiciels relèvent de la classe I. »
3. Les trois branches, et pourquoi la première avale tout
La règle se décompose en trois branches qu'il faut examiner dans l'ordre.
Branche A — décisions diagnostiques ou thérapeutiques
C'est la branche la plus large et de très loin la plus fréquente. Elle capture tout logiciel qui fournit une information servant à décider quelque chose de diagnostique ou thérapeutique.
Trois mots méritent qu'on s'y arrête.
« Fournir des informations » : le logiciel n'a pas besoin de poser un diagnostic. Il suffit qu'il produise un élément qui entre dans la décision. Un score, une courbe de tendance, une alerte, une segmentation d'image, une valeur calculée.
« Utilisées pour prendre des décisions » : c'est le cœur du sujet. Beaucoup de fabricants plaident que la décision reste au médecin, que le logiciel n'est qu'une aide. Cet argument ne fonctionne pas. La règle ne dit pas « logiciels qui prennent des décisions », elle dit « informations utilisées pour prendre des décisions ». La présence d'un professionnel de santé dans la boucle ne fait pas sortir de la branche A.
« À des fins diagnostiques ou thérapeutiques » : c'est ici que se joue la marge de manœuvre réelle, et elle est étroite. Une information de confort, d'organisation ou de documentation n'est ni diagnostique ni thérapeutique. Une information qui oriente une conduite à tenir l'est.
Branche B — contrôle de processus physiologiques
Beaucoup plus étroite. Elle vise les logiciels qui pilotent : régulation d'une pompe, ajustement d'un paramètre de ventilation, asservissement d'un traitement. Un logiciel qui affiche des paramètres sans agir dessus n'entre pas dans cette branche — il retombe dans la branche A si l'affichage sert à décider.
Branche C — tous les autres
La branche résiduelle, celle qui donne la classe I. Elle ne se revendique pas : elle se démontre par élimination, en établissant qu'on n'entre ni dans A ni dans B.
Une classification en classe I par la règle 11 n'est jamais un point de départ. C'est le résultat d'une démonstration écrite que les deux premières branches ne s'appliquent pas.
4. IIa, IIb ou III : la gradation
Une fois dans la branche A, la classe dépend de la conséquence potentielle d'une décision erronée prise sur la base de l'information fournie.
| Conséquence possible | Classe |
|---|---|
| Décision diagnostique ou thérapeutique, sans gravité particulière identifiée | IIa |
| Grave détérioration de l'état de santé, ou intervention chirurgicale | IIb |
| Mort, ou détérioration irréversible de l'état de santé | III |
Deux remarques d'expérience.
D'abord, cette gradation raisonne sur le potentiel, pas sur le probable. La question n'est pas « quelle est la probabilité qu'une erreur cause un décès », mais « une décision erronée fondée sur cette information pourrait-elle causer un décès ». Les mesures de maîtrise que vous avez mises en place n'entrent pas dans le raisonnement de classification — elles relèvent de la gestion des risques, qui est un autre exercice.
Ensuite, la frontière IIa/IIb est régulièrement sous-évaluée. Dès qu'une décision peut conduire à une intervention chirurgicale — y compris une intervention évitée à tort — on est en IIb.
5. Quatre pièges classiques
Piège n°1 : « c'est le médecin qui décide »
Nous l'avons dit, c'est l'argument le plus fréquent et il ne tient pas. Le texte vise l'information utilisée pour décider, pas l'auteur de la décision. Si cet argument suffisait, la règle 11 ne s'appliquerait à presque aucun logiciel destiné aux professionnels de santé — ce qui n'est manifestement pas l'intention du législateur.
Piège n°2 : croire que la destination se lit dans la notice
La destination revendiquée se lit dans toute votre communication : notice, site web, plaquettes commerciales, présentations en congrès, démonstrations en salon, publications, communiqués, et jusqu'aux publications de vos dirigeants sur les réseaux sociaux.
C'est le point le plus sous-estimé, et c'est celui qui fait échouer les stratégies de classe I les mieux argumentées. Vous pouvez avoir une notice parfaitement prudente : si une page de votre site parle de « test », de « détection » ou de « diagnostic », une autorité compétente s'appuiera dessus. Une stratégie de classe I qui repose sur une destination restreinte impose une discipline de communication absolue, tenue par tout le monde, en permanence.
Piège n°3 : oublier les autres règles
La règle 11 n'est pas la seule à pouvoir s'appliquer à un produit logiciel. Si votre logiciel pilote un dispositif ou en est un accessoire, d'autres règles peuvent le classer plus haut — et en cas de conflit, c'est la classe la plus élevée qui l'emporte (annexe VIII, section 3.5).
Le cas typique : une solution qui associe un logiciel et un matériel de mesure. On raisonne sur le logiciel via la règle 11, on oublie que le matériel relève d'une règle qui le classe ailleurs, et la solution complète bascule.
Piège n°4 : le « bien-être » comme échappatoire
Positionner un produit sur le bien-être plutôt que sur la santé peut le faire sortir du champ du MDR. Mais ce positionnement doit être réel, pas cosmétique. Si les fonctionnalités, l'argumentaire commercial et la population visée décrivent un usage médical, l'étiquette « bien-être » ne protège de rien. Et elle a un coût commercial : sans revendication médicale, il devient très difficile de vendre à un établissement de santé ou d'obtenir un remboursement.
6. Une méthode en cinq questions
Voici comment nous instruisons concrètement le sujet, dans cet ordre :
Quelle est la destination, écrite noir sur blanc ?
Rédigez-la en trois lignes, sans adjectif commercial. Puis confrontez-la à tout ce que vous publiez. Les écarts que vous trouverez à cette étape sont déjà le cœur du problème.
Le logiciel fait-il plus que stocker, transmettre ou chercher ?
S'il ne fait que ça, il n'est probablement pas un dispositif médical et l'exercice s'arrête. Sinon, on continue.
L'information produite entre-t-elle dans une décision diagnostique ou thérapeutique ?
Décrivez le parcours réel : qui lit la sortie du logiciel, et qu'en fait-il ensuite ? Si la réponse contient « il ajuste », « il oriente », « il décide de », vous êtes en branche A.
Quelle est la pire conséquence d'une information erronée ?
Non pas la plus probable — la pire plausible. Cette réponse donne le classement IIa, IIb ou III.
Une autre règle s'applique-t-elle ?
Passez en revue les règles de l'annexe VIII qui pourraient viser votre produit ou ses composants. La plus élevée gagne.
Le livrable de cet exercice est une note de classification : un document qui applique chaque règle pertinente, en tire une conclusion et documente les alternatives écartées avec leur justification. C'est ce document que vous produirez si votre classification est contestée — et ne pas l'avoir est en soi un signal défavorable.
7. Ce que ça change si vous basculez
Passer de classe I à classe IIa n'est pas un ajustement administratif. C'est un changement de régime complet.
| Classe I | Classe IIa | |
|---|---|---|
| Organisme notifié | Non | Oui |
| Système qualité certifié | Requis mais non certifié | Audité et certifié |
| Dossier technique | Requis, non évalué par un tiers | Évalué par échantillonnage |
| Évaluation clinique | Requise | Requise, exigences renforcées |
| Délai | Auto-certification | 12 à 24 mois, file d'attente comprise |
À cela s'ajoute une question de fond souvent négligée : que faire des unités déjà sur le marché ? Si votre dispositif est commercialisé depuis des années sous une classification qui s'avère erronée, la situation ne se règle pas seulement en préparant l'avenir. Elle appelle une analyse de risque sur l'existant, et une décision documentée quant aux mesures à prendre.
C'est aussi pour cette raison qu'il vaut mieux instruire la question soi-même, tôt, plutôt que de la découvrir dans un courrier. Une reclassification anticipée est un projet. Une reclassification imposée est une crise.
Cet article expose une méthode d'analyse générale. Il ne constitue pas un avis juridique et ne remplace pas l'examen de votre produit, de sa destination et de votre documentation. Les cas limites de la règle 11 se tranchent sur pièces.