Certification dispositif médical logiciel (MDR/SaMD) : guide pour éditeurs
05/03/2026
Votre application de santé aide les médecins à poser un diagnostic, surveille les constantes d'un patient, ou propose une aide à la décision thérapeutique. À un moment, quelqu'un va vous poser la question : "Est-ce que c'est un dispositif médical ?"
Si la réponse est oui, votre logiciel est soumis au règlement européen MDR (Medical Device Regulation) 2017/745. Ce qui implique un marquage CE, une documentation technique structurée, et potentiellement un audit par un organisme notifié. Le processus est long, coûteux, et les erreurs se paient cher.
Ce guide explique comment fonctionne la qualification et la certification d'un dispositif médical logiciel en France et en Europe, ce que ça coûte, et comment s'y préparer dès le début du projet.
Qu'est-ce qu'un dispositif médical logiciel ?
La définition réglementaire
Le règlement MDR (article 2) définit un dispositif médical comme tout instrument, appareil, logiciel, ou autre article destiné par le fabricant à être utilisé chez l'être humain pour une ou plusieurs des finalités suivantes :
- Diagnostic : détection, prévention, diagnostic d'une maladie
- Traitement : traitement ou atténuation d'une maladie
- Monitoring : surveillance, mesure, remplacement ou modification d'un processus physiologique
- Investigation : examen, remplacement ou modification de l'anatomie
Un logiciel qui remplit une de ces finalités est un dispositif médical logiciel, aussi appelé SaMD (Software as a Medical Device). Le terme important est "destiné par le fabricant" : c'est la finalité prévue (intended purpose) qui détermine la qualification, pas ce que le logiciel fait techniquement.
SaMD vs SiMD
Il faut distinguer deux catégories :
SaMD (Software as a Medical Device) : le logiciel EST le dispositif médical. Il fonctionne de manière autonome, sans être intégré dans un autre dispositif matériel. Exemple : une application d'aide au diagnostic dermatologique par analyse d'image.
SiMD (Software in a Medical Device) : le logiciel fait partie d'un dispositif médical matériel. Exemple : le firmware d'un moniteur cardiaque.
Ce guide se concentre sur le SaMD, qui est le cas le plus fréquent pour les startups et éditeurs de logiciels.
Mon logiciel est-il un SaMD ?
C'est la question que se posent tous les éditeurs. Voici un arbre de décision simplifié :
| Votre logiciel... | SaMD ? |
|---|---|
| Analyse des données patient pour proposer un diagnostic | Oui |
| Calcule un score de risque clinique et recommande une action | Oui |
| Surveille des constantes vitales et déclenche des alertes médicales | Oui |
| Pilote un dispositif médical matériel (ex: pompe à insuline) | Oui (SiMD) |
| Affiche des données médicales sans les interpréter | Non (en général) |
| Gère des rendez-vous ou de l'administratif | Non |
| Stocke des dossiers médicaux | Non |
| Envoie des rappels de prise de médicament (sans calcul de dose) | Non (en général) |
| Propose un coaching bien-être sans revendication médicale | Non |
Zone grise : les logiciels de "bien-être" qui collectent des données de santé (rythme cardiaque, glycémie, poids) et proposent des recommandations. Si les recommandations ont une finalité médicale (même implicite), le logiciel peut être requalifié en SaMD par les autorités. En cas de doute, faites évaluer votre qualification par un consultant réglementaire avant de commercialiser.
La classification des SaMD
Les classes de risque
Le règlement MDR classe les dispositifs médicaux en quatre catégories selon le niveau de risque :
| Classe | Niveau de risque | Exemples SaMD | Organisme notifié requis ? |
|---|---|---|---|
| Classe I | Faible | Logiciel d'aide à la décision sans impact direct sur le traitement | Non (auto-certification) |
| Classe IIa | Modéré | Logiciel de monitoring qui génère des alertes cliniques | Oui |
| Classe IIb | Élevé | Logiciel d'aide au diagnostic pour pathologies graves | Oui |
| Classe III | Très élevé | Logiciel qui pilote un dispositif implantable | Oui |
Comment déterminer la classe de votre SaMD
La règle 11 de l'annexe VIII du MDR est spécifique aux logiciels. En résumé :
- Classe III : si le logiciel est destiné à fournir des informations utilisées pour prendre des décisions à des fins thérapeutiques ou diagnostiques, ET que ces décisions peuvent causer la mort ou une détérioration irréversible de la santé
- Classe IIb : si les décisions peuvent causer une détérioration grave de la santé ou une intervention chirurgicale
- Classe IIa : pour tous les autres logiciels à finalité diagnostique ou thérapeutique
- Classe I : logiciels destinés au stockage, à l'archivage, à la communication ou à la recherche simple de données
En pratique, la grande majorité des SaMD tombent en classe IIa ou IIb. La classe I est rare pour les SaMD parce que dès qu'un logiciel interprète des données pour une finalité médicale, il dépasse le simple stockage/affichage.
Attention : le MDCG (Medical Device Coordination Group) a publié des guidances qui clarifient l'application de la règle 11. Les lire est indispensable avant de fixer votre classification.
Le processus de marquage CE
Pour un SaMD de classe I
Le fabricant (vous) peut auto-certifier la conformité. Pas besoin d'organisme notifié. Mais vous devez quand même :
- Rédiger la documentation technique complète
- Mettre en place un système de management de la qualité (QMS)
- Réaliser l'évaluation clinique
- Enregistrer le dispositif dans la base EUDAMED
- Rédiger la déclaration de conformité UE
- Apposer le marquage CE
Pour un SaMD de classe IIa, IIb ou III
Le processus est le même, avec une étape supplémentaire : l'audit par un organisme notifié (Notified Body). C'est un organisme tiers accrédité par une autorité compétente (en France : l'ANSM) qui vérifie votre conformité au règlement MDR.
Les étapes :
- Qualification et classification : confirmer que votre logiciel est bien un SaMD et déterminer sa classe
- Mise en place du QMS : système qualité conforme à la norme ISO 13485
- Rédaction du dossier technique : documentation du dispositif (voir section suivante)
- Évaluation clinique : prouver que le dispositif est sûr et performant
- Choix de l'organisme notifié : sélection et contractualisation
- Audit de l'organisme notifié : revue documentaire + audit sur site
- Obtention du certificat CE : si l'audit est concluant
- Déclaration de conformité + marquage CE
- Enregistrement EUDAMED
- Surveillance post-commercialisation : obligation continue
La documentation technique
Le dossier technique (Technical File)
Le dossier technique est le document central de votre certification. Il décrit votre dispositif de manière exhaustive. Pour un SaMD, il doit inclure :
Description du dispositif :
- Finalité prévue (intended purpose)
- Population cible (patients, utilisateurs professionnels)
- Environnement d'utilisation prévu
- Principes de fonctionnement (algorithmes, logique de décision)
- Architecture logicielle
- Interfaces avec d'autres systèmes
Exigences de sécurité et performances :
- Analyse des risques (norme ISO 14971)
- Exigences essentielles de sécurité et performance (annexe I du MDR)
- Spécifications de cybersécurité
Vérification et validation :
- Plan de test
- Résultats des tests unitaires, d'intégration, système
- Tests d'utilisabilité (IEC 62366)
- Validation du logiciel (IEC 62304 pour le cycle de vie du logiciel)
Évaluation clinique :
- Revue de la littérature scientifique
- Données cliniques (essais si nécessaire)
- Rapport d'évaluation clinique
Informations fournies à l'utilisateur :
- Instructions d'utilisation (IFU - Instructions For Use)
- Étiquetage
Les normes clés
| Norme | Objet | Obligatoire ? |
|---|---|---|
| ISO 13485 | Système de management de la qualité pour les dispositifs médicaux | Oui (exigé par les organismes notifiés) |
| ISO 14971 | Gestion des risques | Oui |
| IEC 62304 | Cycle de vie du logiciel médical | Oui pour les SaMD |
| IEC 62366 | Ingénierie de l'utilisabilité | Oui |
| IEC 82304 | Logiciel de santé autonome | Recommandée |
IEC 62304 est la norme que les développeurs logiciels doivent connaître. Elle définit trois classes de sécurité pour le logiciel (A, B, C) et les exigences de développement correspondantes : planification, architecture, conception détaillée, tests, maintenance. La classe C (risque le plus élevé) exige le niveau de documentation le plus complet.
L'évaluation clinique
L'évaluation clinique prouve que votre dispositif est sûr et atteint les performances revendiquées. Pour un SaMD, elle repose sur :
La revue de littérature
Rassembler les publications scientifiques qui démontrent que la technologie sous-jacente (l'algorithme, la méthode de mesure, le principe de fonctionnement) est validée. C'est la base minimale.
Les données cliniques propres
Selon la classe et la nouveauté du dispositif, vous devrez peut-être conduire vos propres études cliniques :
- Classe IIa : une étude de performance (sensibilité, spécificité, valeur prédictive) sur un jeu de données cliniques peut suffire
- Classe IIb/III : des investigations cliniques (essais) avec des patients réels sont souvent nécessaires
Le rapport d'évaluation clinique (CER)
Document structuré qui synthétise toutes les données cliniques et conclut sur la conformité aux exigences de sécurité et de performance. Ce document est audité par l'organisme notifié.
La surveillance post-commercialisation (PMS)
Le marquage CE n'est pas une étape ponctuelle. Le fabricant doit assurer une surveillance continue :
Le plan PMS
Document qui décrit comment vous allez collecter et analyser les données après la mise sur le marché : retours utilisateurs, incidents, plaintes, données de vigilance.
Le rapport PSUR (Periodic Safety Update Report)
Rapport périodique (annuel pour les classes IIa+) qui actualise l'évaluation bénéfice/risque du dispositif à la lumière des données post-commercialisation.
La matériovigilance
Obligation de signaler tout incident grave (dysfonctionnement ayant entraîné ou pouvant entraîner un décès ou une détérioration grave de la santé) à l'ANSM dans les délais réglementaires (24h à 15 jours selon la gravité).
Pour un SaMD, ça inclut les bugs logiciels qui ont un impact clinique. Un faux négatif dans un algorithme de détection, un calcul de dose erroné, une alerte qui ne se déclenche pas : ce sont des incidents de matériovigilance.
Les organismes notifiés
Comment les choisir
Il y a un nombre limité d'organismes notifiés accrédités sous le MDR en Europe. Les principaux qui travaillent avec des éditeurs de SaMD :
| Organisme | Pays | Spécialisation |
|---|---|---|
| BSI | Royaume-Uni/Pays-Bas | Large spectre, expérience SaMD |
| TÜV SÜD | Allemagne | Fort en logiciel médical |
| TÜV Rheinland | Allemagne | Large spectre |
| GMED | France | Organisme français, connaissance du marché local |
| SGS | Suisse | Large spectre |
GMED est l'organisme notifié français. Travailler avec un organisme qui connaît le marché français peut simplifier certaines interactions, mais ce n'est pas obligatoire. Votre certificat CE est valable dans toute l'UE quel que soit l'organisme.
Les délais
Le goulot d'étranglement principal est la disponibilité des organismes notifiés. Depuis l'entrée en vigueur du MDR, la demande a explosé et les capacités d'audit sont limitées. Comptez :
- 3 à 6 mois pour la contractualisation avec l'organisme notifié
- 6 à 12 mois pour l'audit et l'obtention du certificat
- Soit 12 à 18 mois au total entre le moment où votre dossier est prêt et l'obtention du marquage CE
C'est un délai incompressible qu'il faut intégrer dans votre roadmap produit.
Combien ça coûte
Les ordres de grandeur pour un SaMD :
| Poste | Coût estimé |
|---|---|
| Consultant réglementaire (qualification + accompagnement) | 15 000 – 50 000 € |
| Mise en place du QMS (ISO 13485) | 20 000 – 60 000 € |
| Rédaction du dossier technique | 30 000 – 80 000 € |
| Évaluation clinique (revue littérature + étude de performance) | 10 000 – 100 000 € |
| Audit organisme notifié (classe IIa) | 15 000 – 30 000 € |
| Audit organisme notifié (classe IIb/III) | 30 000 – 80 000 € |
| Maintenance annuelle (PMS, PSUR, renouvellement) | 10 000 – 30 000 €/an |
Total pour un SaMD classe IIa : 80 000 à 250 000 € pour la première certification, puis 10 000 à 30 000 €/an pour le maintien.
Ces coûts s'ajoutent au développement de l'application elle-même. Pour les budgets de développement, consultez notre article sur les coûts d'une application e-santé.
Conseils pour les startups
Clarifiez votre qualification tôt
Ne développez pas pendant 18 mois avant de vous poser la question "est-ce un SaMD ?". Faites évaluer la qualification dès la phase de conception. Si votre logiciel est un SaMD, ça change votre processus de développement, votre documentation, votre budget et votre timeline.
Adoptez IEC 62304 dès le début
Même si vous n'êtes pas encore certain d'être un SaMD, structurer votre développement selon IEC 62304 dès le départ est bien plus simple que de rattraper la documentation après coup. Les exigences de base (traçabilité des exigences, gestion de configuration, plan de test) sont des bonnes pratiques de toute façon.
Séparez le SaMD du reste
Si votre application a des fonctionnalités médicales ET des fonctionnalités non médicales (gestion de rendez-vous, messagerie, facturation), isolez les modules SaMD architecturalement. Seul le module à finalité médicale doit être certifié. Un bon découpage réduit le périmètre de certification et donc les coûts.
Ne sous-estimez pas les délais des organismes notifiés
Le plus gros risque pour une startup SaMD n'est pas technique, c'est le calendrier réglementaire. Commencez les démarches avec l'organisme notifié le plus tôt possible. Chaque mois de retard dans la contractualisation est un mois de retard sur votre mise sur le marché.
Ce que nous faisons chez Bob le développeur
Chez Bob le développeur, nous accompagnons les startups e-santé sur la partie technique : architecture logicielle conforme IEC 62304, développement structuré, documentation technique du code. Notre expérience en startup e-santé (exit 2018) nous a confrontés directement à ces contraintes réglementaires.
On ne remplace pas un consultant réglementaire (et on vous recommandera d'en prendre un), mais on s'assure que le code et l'architecture de votre application sont compatibles avec les exigences MDR dès le départ. C'est bien moins cher que de refactoriser après coup pour passer un audit.