Particularités des logiciels
Les logiciels diffèrent des dispositifs médicaux traditionnels sur un point essentiel : ils évoluent rapidement. Les versions, les correctifs, l'environnement des clouds, les interfaces, les fonctions d'IA et les risques en lien avec la cybersécurité font tous partie intégrante de son cycle de vie. Le MDR en tient compte. Pour les logiciels, l'annexe I exige, entre autres, une approche dernier cri du cycle de développement, du management des risques, de la vérification et de la validation, ainsi que des exigences minimales pour le matériel, les réseaux informatiques et la protection contre les accès non autorisés. La cybersécurité n'est donc pas une question informatique secondaire, mais fait partie intégrante de la sécurité et des performances du produit.
En ce qui concerne les logiciels en particulier, ce n'est pas le code qui compte, mais l'objectif médical. Une application de bien-être n'est pas considérée comme un logiciel médical simplement parce qu'elle est techniquement complexe. À l'inverse, une application apparemment simple peut très bien relever du MDR si les informations qu'elle contient sont utilisées pour des décisions diagnostiques ou thérapeutiques. Le guide actuel du MDCG sur la qualification et la classification des logiciels clarifie précisément cette distinction.
Exigences du MDR - où peut-on les trouver ?
Toute personne souhaitant mettre un logiciel sur le marché dans le cadre du MDR doit lire très attentivement les sections pertinentes du règlement. Les sections les plus importantes sont les suivantes :
L'annexe I, qui définit les exigences générales en matière de sécurité et de performance. Pour les logiciels, les exigences relatives au processus de développement, au management des risques, à la sécurité de l'information, à la validation et à l'environnement informatique sont particulièrement importantes.
Les annexes II et III régissent la documentation technique ainsi que les exigences en matière de surveillance postérieure à la mise sur le marché. Pour les logiciels, cela inclut également la preuve de la vérification et de la validation du logiciel dans le cadre de la documentation du produit.
L'annexe VIII, en particulier la règle 11, est essentielle pour la classification des logiciels médicaux. Le GCDM 2019-11, révisé en 2025, explique les trois principes de base de la règle 11 : les logiciels qui fournissent des informations pour les décisions diagnostiques ou thérapeutiques ; les logiciels qui surveillent les processus physiologiques ; et "tous les autres logiciels". En fonction de la pertinence clinique, la classification peut aller de la classe I à la classe III.
L'article 52 et les annexes IX à XI décrivent l'évaluation de la conformité. Pour les dispositifs de classe I, la déclaration de conformité est généralement délivrée par le fabricant lui-même ; pour les dispositifs de classe IIa et plus, l'intervention d'un organisme notifié est requise.
Enfin, l'annexe XIV est la référence centrale pour l'évaluation clinique et le suivi clinique après commercialisation. Il s'agit d'un domaine qui est souvent mis en place systématiquement trop tard, surtout en ce qui concerne les logiciels.
Les normes les plus importantes pour les logiciels médicaux
Le MDR précise les exigences réglementaires. Toutefois, dans la mise en œuvre pratique, certaines normes sont particulièrement importantes car elles définissent "le dernier cri".
La norme CEI 62304 est la norme de base pour le cycle de vie des logiciels médicaux. Elle décrit les processus de développement et de maintenance des logiciels lorsque le logiciel lui-même est un dispositif médical ou une partie intégrante d'un dispositif médical.
La norme ISO 14971 est la norme de référence pour le management des risques des dispositifs médicaux, incluant explicitement les logiciels en tant que dispositifs médicaux.
La norme ISO 13485 est la norme centrale de management de la qualité pour les dispositifs médicaux tout au long du cycle de vie du produit. Pour les fabricants qui cherchent à mettre en place une organisation solide conforme au MDR, elle sert de base opérationnelle pratique.
La norme CEI 62366-1 couvre l'ingénierie de l'utilisabilité. Elle est particulièrement pertinente pour les logiciels, car un fonctionnement incorrect, des conseils d'utilisation trompeurs ou des alarmes peu claires peuvent avoir des conséquences immédiates sur la sécurité.
La norme CEI 82304-1 est particulièrement pertinente pour les logiciels de santé sur les plates-formes informatiques générales, c'est-à-dire pour les produits sans matériel dédié. La norme traite de la sûreté et de la sécurité au niveau du produit et revêt donc une grande importance pour de nombreux logiciels autonomes ou logiciels en tant que dispositifs médicaux (SaMD - Software as Medical Device). Il est particulièrement intéressant de noter que la CEI 82304-1 définit des exigences spécifiques pour la validation des SaMD et qu'elle est simultanément référencée dans la CEI 62304, qui est harmonisée dans le cadre du MDR.
La classification : La première étape cruciale
La question initiale la plus courante et la plus importante est la suivante : dans quelle classe se situe mon logiciel ? C'est précisément à ce stade que de nombreux projets échouent, non pas en raison de la technologie, mais parce que l'objectif visé n'est pas clair. Selon le MDCG 2019-11 Rev.1, la règle 11 est essentiellement appliquée en fonction du fait que le logiciel fournit des informations pour des décisions diagnostiques ou thérapeutiques, surveille des processus physiologiques ou tombe dans la catégorie résiduelle. Des exemples dans le guide montrent que les logiciels de diagnostic ou d'aide à la thérapie peuvent rapidement tomber dans la classe IIa, IIb ou III, tandis que "tous les autres logiciels" relèvent de la classe I.
Du point de vue de l'organisme notifié, il est donc clair que la classification n'est pas une étape administrative finale, mais le fondement de toute la stratégie d'autorisation de mise sur le marché. Elle influence le scope des preuves cliniques, la profondeur de la documentation technique, les exigences du PMS/PMCF et, bien sûr, la question de savoir si et dans quelle mesure un organisme notifié doit être impliqué.
Données cliniques : Cela ne fonctionnera pas sans preuves cliniques
Pour les logiciels médicaux, les données cliniques ne sont pas un "plus". Le document MDCG 2020-1 stipule explicitement que les logiciels médicaux ayant une finalité propre et un bénéfice clinique revendiqué nécessitent des preuves cliniques dans le cadre de l'évaluation de leur conformité. L'objectif est de démontrer que le logiciel est sûr, qu'il atteint ses performances et qu'il apporte le bénéfice clinique revendiqué.
En pratique, cela signifie pour les logiciels, qu'il ne suffit pas de montrer que l'algorithme fonctionne techniquement. Il faut également évaluer si le logiciel fournit les informations correctes dans un contexte clinique, comment ces informations sont utilisées et s'il en résulte effectivement un bénéfice démontrable. L'évaluation clinique n'est pas un document unique, mais un processus continu.
Suivi clinique après la mise sur le marché (PMCF - Post-Market Clinical Follow-Up)
Le suivi clinique post-commercialisation est souvent sous-estimé dans le contexte des logiciels. Le MDR définit le suivi clinique post-commercialisation comme un processus continu qui met à jour l'évaluation clinique et doit être ancré dans le plan PMS du fabricant. C'est précisément ce que décrit explicitement le modèle de PMCF du MDCG.
Le PMCF est particulièrement important pour les logiciels, car les contextes d'utilisation, les systèmes d'exploitation, les interfaces, les cybermenaces et les modèles d'utilisation clinique changent constamment. Les fabricants ont donc besoin non seulement d'une stratégie d'autorisation de mise sur le marché solide, mais aussi d'un système robuste pour collecter et évaluer les données relatives à la performance et à la sécurité dans le monde réel après le lancement sur le marché et pour en tenir compte dans l'amélioration des produits.
Comment fonctionne le processus de certification du point de vue d'un organisme notifié ?
Le processus de certification peut être résumé en six étapes clés.
Premièrement : L'utilisation prévue doit être définie avec précision. C'est la seule façon de déterminer clairement si le logiciel relève du MDR.
Deuxièmement : le logiciel doit être correctement classé, généralement sur la base de l'annexe VIII et de la règle 11.
Troisièmement : l'entreprise doit disposer d'un système de gestion de la qualité approprié et d'un processus de développement vérifiable et conforme à l'état de l'art, généralement basé sur les normes ISO 13485, IEC 62304, ISO 14971 et d'autres normes en fonction du produit.
Quatrièmement, la documentation technique doit être complète, structurée et traçable, y compris la vérification et la validation des logiciels.
Cinquièmement : l'évaluation clinique, le PMS et le PMCF doivent être structurés de manière appropriée pour le produit.
Sixièmement : si la classification nécessite l'intervention d'un organisme notifié, l'évaluation formelle de la conformité suit les procédures définies dans le MDR.
