MDR 2017/745 : ce que le règlement change pour les logiciels

Le passage de la directive 93/42/CEE au règlement (UE) 2017/745 n’a pas été une mise à jour : c’est un changement de régime. Applicable depuis le 26 mai 2021, le règlement s’impose directement dans toute l’Union, sans transposition nationale.

Pour un éditeur de logiciel, quatre évolutions comptent vraiment.

1. La classification a changé d’échelle

C’est l’effet le plus visible. La règle 11 de l’annexe VIII, spécifique aux logiciels, a fait basculer en classe IIa ou au-delà une grande partie des produits qui étaient auparavant en classe I.

La conséquence n’est pas symbolique : l’auto-certification laisse place à l’intervention d’un organisme notifié, avec ce que cela suppose de délais, de coûts et de dépendance à une capacité de marché contrainte.

2. La preuve clinique est devenue centrale

Le règlement renforce nettement les exigences d’évaluation clinique, et surtout il en fait un processus continu plutôt qu’un livrable ponctuel. L’évaluation initiale doit être maintenue à jour par les données collectées après la mise sur le marché.

Pour un logiciel, cela signifie qu’il faut concevoir, dès le départ, les moyens de collecter ces données — ce qui a des implications produit, techniques et contractuelles avec vos clients.

3. La surveillance après commercialisation est un processus, pas une boîte aux lettres

Le fabricant doit mettre en place un système de surveillance après commercialisation proportionné à la classe, planifié, et dont les résultats alimentent en retour la gestion des risques, l’évaluation clinique et, le cas échéant, des actions correctives.

La matériovigilance — le signalement des incidents — n’en est qu’une composante. Beaucoup d’organisations réduisent la surveillance à ce signalement et se retrouvent en difficulté à l’audit.

4. La conformité doit être portée par quelqu’un

Le règlement impose au fabricant de disposer, au sein de son organisation, d’au moins une personne chargée de veiller au respect de la réglementation, possédant l’expertise requise. Elle est notamment responsable de la conformité des dispositifs avant leur libération, de la documentation technique et des obligations de surveillance.

Des aménagements existent pour les micro et petites entreprises, mais la fonction doit exister et être identifiée. Pour une startup, c’est souvent la première décision d’organisation qu’impose la conformité.

Ce que cela change dans le quotidien d’une équipe produit

Trois pratiques deviennent structurantes :

La traçabilité des exigences. Chaque exigence doit pouvoir être reliée à sa justification, à sa vérification et aux risques qu’elle traite. Cela n’est pas incompatible avec un développement itératif, mais impose un outillage et une discipline.

La gestion des modifications. Toute évolution doit être évaluée quant à son impact sur la sécurité, les performances et la destination. Une modification substantielle peut déclencher une nouvelle évaluation par l’organisme notifié.

La maîtrise des composants tiers. Bibliothèques, dépendances, services externes, modèles pré-entraînés : leur usage doit être justifié, leur comportement caractérisé, leurs vulnérabilités suivies. C’est l’un des points sur lesquels les équipes logicielles sont le plus souvent prises en défaut.

Le rôle des guides MDCG

Le Medical Device Coordination Group publie des guides qui constituent la doctrine d’application du règlement. Ils ne sont pas juridiquement contraignants, mais les organismes notifiés et les autorités s’y réfèrent.

Pour un logiciel, le MDCG 2019-11 sur la qualification et la classification est incontournable. D’autres traitent de la cybersécurité, des dispositifs logiciels et de l’évaluation clinique. Les ignorer revient à s’écarter de la doctrine sans le savoir.

Et les dispositions transitoires ?

Des dispositions transitoires permettent, sous conditions, la poursuite de la commercialisation de dispositifs certifiés sous l’ancienne directive. Elles ont été aménagées à plusieurs reprises, et sont assorties de dates limites et d’exigences précises — notamment en matière de système qualité et de surveillance.

C’est un sujet où la règle générale ne suffit pas : la situation dépend de la classe, de la date du certificat et de la nature des modifications apportées depuis. Une vérification au cas par cas s’impose.