Logiciel dispositif médical : le guide du développeur

Beaucoup d'applications de santé sont des dispositifs médicaux qui s'ignorent. Le découvrir après le lancement, quand l'organisme notifié réclame une documentation qui n'existe pas, coûte des mois et un budget entier. La qualification de votre logiciel comme dispositif médical ne se règle pas en fin de projet. Elle conditionne l'architecture, le cycle de vie du code et votre accès au marché.

Ce guide s'adresse aux porteurs de projets et aux éditeurs qui veulent comprendre précisément ce qu'implique le développement d'un logiciel dispositif médical, du premier test de qualification jusqu'au marquage CE.

À retenir

• Un logiciel est un dispositif médical dès qu'il a une finalité médicale au sens du règlement européen MDR 2017/745.
• Sa classe (I, IIa, IIb, III) détermine le niveau de contrôle et le coût.
• Le marquage CE est obligatoire avant toute mise sur le marché.
• Le développement doit suivre les normes IEC 62304 et ISO 13485.

Qu'est-ce qu'un logiciel dispositif médical (SaMD) ?

Un logiciel dispositif médical est un logiciel destiné à une finalité médicale : diagnostic, prévention, contrôle, prédiction, pronostic, traitement ou atténuation d'une maladie. Cette finalité, définie par le règlement MDR 2017/745, fait toute la différence. Un même code peut être un simple outil de confort ou un dispositif médical réglementé selon l'usage qu'on lui prête.

On parle souvent de SaMD, pour Software as a Medical Device, c'est-à-dire un logiciel qui remplit une fonction médicale par lui-même, sans être intégré à un appareil physique. Il se distingue du logiciel embarqué, qui pilote un dispositif matériel comme une pompe à insuline ou un scanner.

Le critère qui fait basculer un logiciel dans le statut de dispositif médical est donc la finalité médicale, pas la technologie employée. Une application peut utiliser l'intelligence artificielle sans être un dispositif médical, et une simple règle de calcul peut en être un si elle oriente une décision de soin.

À l'inverse, certains logiciels restent hors du champ réglementaire. Une application de bien-être, un agenda de rendez-vous, un journal de symptômes qui se contente de stocker des informations sans les interpréter ne sont pas des dispositifs médicaux.

Votre logiciel est-il un dispositif médical ?

La qualification suit une logique que la Commission européenne a formalisée dans le guide MDCG 2019-11. En pratique, quelques questions suffisent à dégrossir le sujet.

Un logiciel tend vers le statut de dispositif médical lorsqu'il réunit ces conditions : il poursuit une finalité médicale, il agit sur les données propres à un patient donné, il produit un résultat individuel, et ce résultat sert à orienter une décision médicale. S'il se limite à stocker, archiver ou transmettre des données sans les traiter, il sort généralement du périmètre.

Cette qualification mérite d'être posée noir sur blanc dès le cadrage. Nous avons détaillé la méthode dans un article dédié : votre application est-elle un dispositif médical, avec un arbre de décision en cinq questions.

Les classes de dispositif médical logiciel (I, IIa, IIb, III)

Une fois la qualification établie, le dispositif est rangé dans une classe selon le risque qu'il présente pour le patient. Le MDR a introduit une règle spécifique au logiciel, la règle 11, qui tire la plupart des logiciels dispositifs médicaux vers les classes supérieures.

La règle 11 pose un principe simple : un logiciel destiné à fournir une information utilisée pour prendre des décisions de diagnostic ou thérapeutiques est au minimum en classe IIa, et grimpe en IIb ou III selon la gravité des conséquences possibles. Autrement dit, la classe I reste l'exception pour un logiciel à visée médicale réelle.

La classe détermine directement le délai et le budget du projet. Un dispositif de classe I s'auto-certifie, alors qu'une classe IIa ou supérieure impose l'intervention d'un organisme notifié, avec l'audit et les coûts qui vont avec.

Le marquage CE d'un logiciel de santé, étape par étape

Le marquage CE atteste qu'un dispositif médical respecte les exigences du règlement européen. Aucun logiciel dispositif médical ne peut être mis sur le marché sans lui. Son obtention suit un parcours en six étapes.

1. Qualifier et classer le dispositif. Confirmez que le logiciel est bien un dispositif médical, puis déterminez sa classe selon la règle 11.
2. Mettre en place le système qualité. Structurez un système de management de la qualité conforme à la norme ISO 13485, socle de toute la démarche.
3. Structurer le cycle de vie logiciel. Appliquez la norme IEC 62304 pour encadrer le développement, de la spécification aux tests.
4. Gérer les risques. Menez une analyse de risques selon la norme ISO 14971, tout au long du cycle de vie.
5. Constituer la documentation technique. Rassemblez les preuves de conformité, l'évaluation clinique et les données de vérification.
6. Faire intervenir un organisme notifié. Pour les classes IIa et au-delà, l'organisme notifié audite le dossier et le système qualité avant l'apposition du marquage CE.

Pour un dispositif de classe I, le fabricant appose lui-même le marquage sous sa responsabilité, après avoir constitué la documentation. Pour toutes les classes supérieures, l'organisme notifié est incontournable.

Développer dans les règles : IEC 62304 et ISO 13485

C'est le cœur technique du sujet, celui que les agences généralistes traitent rarement. Développer un dispositif médical numérique ne consiste pas à ajouter de la documentation à la fin. Cela structure la manière même dont l'équipe travaille.

La norme IEC 62304 encadre le cycle de vie du logiciel dispositif médical. Elle impose une traçabilité continue entre les exigences, la conception, le code et les tests. Chaque composant logiciel reçoit une classe de sécurité A, B ou C selon le préjudice possible en cas de défaillance, ce qui module le niveau de rigueur exigé. En pratique, cette norme demande des revues, une gestion documentée des versions et une discipline de traçabilité qui doit être présente dès la première itération.

La norme ISO 13485 définit le système de management de la qualité applicable aux dispositifs médicaux. Elle couvre l'organisation, les processus, la gestion des fournisseurs et la maîtrise de la production.

La norme ISO 14971 organise la gestion des risques, de l'identification des dangers jusqu'à la maîtrise des risques résiduels, sur toute la durée de vie du produit.

Ces trois normes se répondent. Ensemble, elles imposent une équipe qui documente ses choix, trace ses exigences jusqu'au code, versionne avec discipline et conserve les preuves de ce qu'elle a fait. Une équipe qui découvre ces contraintes après avoir codé perd un temps considérable à reconstituer a posteriori ce qui aurait dû exister dès le départ.

Ce que la qualification DM change dans votre projet

Reconnaître que son produit est un dispositif médical inquiète souvent les porteurs de projet. Cette qualification apporte pourtant autant d'opportunités que de contraintes.

Les contraintes à anticiper :

• Un délai plus long, lié à l'évaluation de conformité et à l'organisme notifié.
• Un budget supérieur, absorbé par la documentation, les tests et l'audit.
• Une surveillance après commercialisation, avec suivi des incidents et mises à jour.
• Une documentation technique exigeante, à maintenir sur toute la vie du produit.

Les bénéfices concrets :

• Un accès légal au marché européen, impossible sans marquage CE.
• Une porte ouverte vers le remboursement, via des dispositifs comme la prise en charge anticipée numérique.
• Une crédibilité forte auprès des professionnels de santé et des établissements.
• Une barrière à l'entrée qui protège votre position face aux concurrents non conformes.

Le vrai piège est de découvrir la qualification après le développement. Le produit doit alors être repris en profondeur, avec une architecture et une documentation à refaire. Poser la question dès le cadrage évite ce scénario, et c'est exactement là que l'accompagnement d'une équipe spécialisée fait la différence.

Questions fréquentes

Une application de bien-être est-elle un dispositif médical ?

En général, non. Une application de bien-être, de forme physique ou de mode de vie sans finalité médicale reste hors du champ du MDR. La frontière se déplace dès que l'application prétend prévenir, diagnostiquer ou suivre une maladie précise.

Combien de temps prend un marquage CE de logiciel dispositif médical ?

Le délai varie selon la classe. Un dispositif de classe I s'auto-certifie assez vite une fois la documentation prête. Une classe IIa ou supérieure implique un organisme notifié, ce qui ajoute plusieurs mois d'audit et d'évaluation au calendrier.

Un chatbot santé ou une IA de diagnostic est-il un dispositif médical ?

Cela dépend de sa finalité. Un agent conversationnel qui oriente vers le bon service sans poser de diagnostic reste souvent hors champ. Une intelligence artificielle qui suggère un diagnostic ou un traitement est un dispositif médical, généralement classé en IIa ou au-dessus.

Quelle différence entre MDR et IVDR pour un logiciel ?

Le MDR 2017/745 encadre les dispositifs médicaux, l'IVDR 2017/746 encadre les dispositifs de diagnostic in vitro. Un logiciel qui interprète des résultats d'analyses biologiques relève de l'IVDR, un logiciel à visée clinique directe relève du MDR.

Peut-on développer un dispositif médical logiciel en méthode agile ?

Oui. La norme IEC 62304 est compatible avec une approche itérative, à condition de maintenir la traçabilité et la documentation à chaque cycle. L'agilité ne dispense pas de la rigueur documentaire, elle l'intègre au fil de l'eau.