Certification dispositif médical logiciel (MDR/SaMD) : guide pour éditeurs

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 :

• Maladie : diagnostic, prévention, surveillance, prédiction, pronostic, traitement ou atténuation
• Blessure ou handicap : diagnostic, contrôle, traitement, atténuation ou compensation
• Anatomie et physiologie : investigation, remplacement ou modification d'une structure ou fonction anatomique, ou d'un processus ou état physiologique ou pathologique
• Examen in vitro : communication d'informations à partir d'échantillons provenant du corps humain

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	Application d'aide à la conception qui calcule la période de fertilité (exemple du guide MDCG 2019-11)	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 d'analyse d'images qui pose le diagnostic et oriente le traitement d'un AVC aigu (exemple du guide MDCG 2019-11)	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 qui fournissent des informations utilisées pour une décision diagnostique ou thérapeutique
• Classe IIa ou IIb : les logiciels destinés à surveiller des processus physiologiques relèvent de la classe IIa, et de la classe IIb s'ils surveillent des paramètres vitaux dont les variations peuvent présenter un danger immédiat pour le patient
• Classe I : tous les autres logiciels dispositifs médicaux, ceux qui n'entrent dans aucun des cas ci-dessus

Les logiciels de simple stockage, d'archivage, de communication ou de recherche de données ne sont pas des dispositifs médicaux : ils ne sont donc pas classés.

En pratique, la grande majorité des SaMD tombent en classe IIa ou IIb. La classe I est rare pour les SaMD : dès qu'un logiciel fournit une information qui sert à une décision diagnostique ou thérapeutique, ou qu'il surveille un processus physiologique, la règle 11 le place au moins en classe IIa.

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 :

1. Rédiger la documentation technique complète
2. Mettre en place un système de management de la qualité (QMS)
3. Réaliser l'évaluation clinique
4. Enregistrer le dispositif dans la base EUDAMED
5. Rédiger la déclaration de conformité UE
6. 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 désigné et surveillé par l'autorité responsable des organismes notifiés de son pays (en France : l'ANSM), qui vérifie votre conformité au règlement MDR.

Les étapes :

1. Qualification et classification : confirmer que votre logiciel est bien un SaMD et déterminer sa classe
2. Mise en place du QMS : système qualité conforme à la norme ISO 13485
3. Rédaction du dossier technique : documentation du dispositif (voir section suivante)
4. Évaluation clinique : prouver que le dispositif est sûr et performant
5. Enregistrement du fabricant dans EUDAMED et choix de l'organisme notifié : vous obtenez votre numéro d'enregistrement unique (SRN) avant de déposer votre demande, puis vous contractualisez
6. Audit de l'organisme notifié : revue documentaire + audit sur site
7. Obtention du certificat CE : si l'audit est concluant
8. Déclaration de conformité + marquage CE
9. Enregistrement du dispositif dans EUDAMED : obligatoire depuis le 28 mai 2026, avant la mise sur le marché
10. 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 générales en matière de sécurité et de performances (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-1)
• 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	Statut
ISO 13485	Système de management de la qualité pour les dispositifs médicaux	Norme harmonisée MDR, attendue par les organismes notifiés
ISO 14971	Gestion des risques	Norme harmonisée MDR
IEC 62304	Cycle de vie du logiciel médical	Référence d'état de l'art, attendue par les organismes notifiés (non harmonisée MDR à ce jour)
IEC 62366-1	Ingénierie de l'utilisabilité	Référence d'état de l'art (non harmonisée MDR à ce jour)
IEC 82304-1	Sécurité des logiciels de santé autonomes	Recommandée

Le MDR ne rend aucune norme obligatoire. Une norme harmonisée donne une présomption de conformité aux exigences qu'elle couvre. Les autres servent de référence pour démontrer que vous développez selon l'état de l'art, ce que l'annexe I exige.

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 qui actualise l'évaluation bénéfice/risque du dispositif à la lumière des données post-commercialisation. Il est mis à jour au moins une fois par an pour les classes IIb et III, et au moins tous les deux ans pour la classe IIa. En classe I, vous établissez un rapport de surveillance après commercialisation, sans PSUR.

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 immédiatement, et au plus tard 15 jours après en avoir eu connaissance. Ce plafond tombe à 10 jours en cas de décès ou de détérioration grave inattendue de l'état de santé, et à 2 jours en cas de menace grave pour la santé publique.

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 désignés au titre du MDR en Europe. Les principaux qui travaillent avec des éditeurs de SaMD :

Organisme	Pays de l'entité notifiée	À noter
GMED	France	Organisme français historique (n° 0459)
AFNOR Certification	France	Second organisme français, désigné le 23 avril 2024 (n° 0333)
BSI	Pays-Bas	L'entité britannique n'est plus notifiée depuis fin 2020
TÜV SÜD	Allemagne
TÜV Rheinland	Allemagne
SGS	Belgique, Finlande	Deux entités notifiées

Tous ont le logiciel dans leur périmètre de désignation. La liste à jour se consulte dans la base NANDO de la Commission européenne.

La France compte deux organismes notifiés au titre du MDR : GMED et AFNOR Certification. 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 reste la capacité des organismes notifiés. L'enquête de la Commission européenne (données à fin février 2026, tous dispositifs confondus) donne les ordres de grandeur :

• le contrat est signé moins de 2 mois après le dépôt de la demande dans 65 % des dossiers ;
• il faut ensuite 13 à 18 mois entre la signature et le certificat chez la majorité des organismes ;
• près d'un tiers des organismes annoncent 19 à 24 mois quand le certificat couvre aussi le produit.

Ce délai va être encadré. Pour les contrats signés à partir du 25 février 2027, le règlement d'exécution (UE) 2026/977 impose des délais maximaux : 30 jours pour l'examen de la demande et la signature du contrat, 120 jours pour l'audit du système qualité, 90 jours pour la vérification du produit, 20 jours pour la décision et la certification. Le compteur est suspendu chaque fois que l'organisme attend de vous une information complémentaire : la qualité de votre dossier pèse autant que son calendrier.

---

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 €
Organisme notifié (certification initiale)	À faire chiffrer : chaque organisme publie son barème. Au GMED en 2026, l'audit démarre à 15 315 € HT et l'évaluation de la documentation technique coûte de 18 564 à 48 552 € HT, hors évaluation clinique (9 730 à 16 218 € HT)
Maintenance annuelle (PMS, PSUR, renouvellement)	10 000 à 30 000 €/an

Total pour un SaMD classe IIa : additionnés, ces postes dépassent 100 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é.

---

Et si votre logiciel embarque de l'IA ?

Depuis l'AI Act, un dispositif médical logiciel qui intègre un modèle cumule deux cadres. La bonne nouvelle est qu'ils ont été articulés pour éviter le doublon.

Un système d'IA est à haut risque au titre de l'annexe I de l'AI Act lorsque deux conditions sont réunies (article 6, paragraphe 1) : il est un composant de sécurité d'un produit couvert par l'annexe I, ou constitue lui-même un tel produit, et ce produit est soumis à une évaluation de la conformité par un tiers. Le MDR est le point 11 de la section A de cette annexe.

Traduit en classes : un SaMD de classe IIa, IIb ou III dont la fonction médicale repose sur un système d'IA est à haut risque. Depuis le règlement (UE) 2026/1744, une IA utilisée uniquement pour des aspects non liés à la sécurité (assistance aux utilisateurs, optimisation des performances, commodité) n'est pas considérée comme un composant de sécurité, sauf si sa défaillance mettrait en danger la santé ou la sécurité. Un SaMD de classe I ne l'est pas, faute d'organisme notifié. Et l'article 43, paragraphe 3, précise qu'un fabricant n'est pas tenu de choisir une procédure impliquant un tiers uniquement parce que son produit intègre une IA, si le MDR ne l'exige pas : ajouter un modèle ne vous fait pas changer de classe ni de procédure.

Trois autres points à connaître :

• Un seul système qualité. L'article 17, paragraphe 3, permet d'intégrer les aspects relevant de l'AI Act au SMQ tenu au titre du MDR. Vous étendez votre ISO 13485, vous n'en montez pas un second.
• Le calendrier. Le règlement (UE) 2026/1744 du 8 juillet 2026 a repoussé au 2 août 2028 les obligations de fond pour les dispositifs médicaux. Les organismes notifiés MDR doivent demander leur désignation au titre de l'AI Act avant le 28 janvier 2028.
• Ce qui court déjà. Si votre produit génère des contenus de synthèse et qu'il est déjà sur le marché, l'article 50, paragraphe 2, est dû au 2 décembre 2026.

Nous traitons le sujet en détail dans notre guide sur l'AI Act en santé, et l'arbre de décision en 5 questions permet de qualifier votre produit. Notre page développement d'IA en santé décrit ce que ces exigences changent concrètement dans l'architecture.

FAQ : dispositif médical logiciel et MDR

Quelle est la définition d'un dispositif médical logiciel selon le MDR ?

Selon le règlement MDR (UE) 2017/745, un logiciel est un dispositif médical lorsqu'il a une finalité médicale propre : diagnostic, prévention, surveillance, prédiction, pronostic, traitement ou atténuation d'une maladie. Un logiciel qui se contente de stocker, d'archiver ou de transmettre des données sans interprétation à visée médicale n'est généralement pas qualifié de dispositif médical.

Qu'est-ce qu'un dispositif médical logiciel de classe I ?

Un SaMD de classe I est un logiciel dispositif médical qui n'entre dans aucun des cas de la règle 11 : il ne fournit pas d'information servant à une décision diagnostique ou thérapeutique et ne surveille pas de processus physiologique. Le guide MDCG 2019-11 cite une application d'aide à la conception qui calcule la période de fertilité. Il relève de l'auto-certification (déclaration de conformité par le fabricant), mais le marquage CE, la documentation technique, le système qualité et l'évaluation clinique restent obligatoires. Un logiciel de simple stockage, d'archivage ou de communication n'est pas un dispositif médical.

Faut-il un organisme notifié pour un SaMD de classe I ?

Non. La classe I se fait en auto-certification, sans organisme notifié. En revanche, dès la classe IIa, l'intervention d'un organisme notifié devient obligatoire pour obtenir le marquage CE.

Un SaMD qui embarque de l'IA change-t-il de classe ?

Non. La classification suit la règle 11 de l'annexe VIII du MDR, indépendamment de l'AI Act. L'article 43, paragraphe 3, de l'AI Act précise même que la classification comme système d'IA à haut risque n'affecte pas le choix de la procédure d'évaluation de la conformité offerte par le MDR. En revanche, un SaMD de classe IIa ou plus dont la fonction médicale repose sur un modèle devient un système d'IA à haut risque, avec les exigences des articles 8 à 15 à satisfaire dans la même évaluation, à partir du 2 août 2028.

Quelle différence entre SaMD et SiMD ?

Le SaMD (Software as a Medical Device) est un logiciel autonome ayant une finalité médicale en lui-même. Le SiMD (Software in a Medical Device) est un logiciel embarqué qui pilote ou fait fonctionner un dispositif médical physique. La qualification réglementaire et la classe de risque s'évaluent différemment selon le cas.

---

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.

Sources

Faits relevés le 13 octobre 2026.

• Règlement (UE) 2017/745, version consolidée : article 2, annexe VIII (règle 11), articles 85 à 87
• Guide MDCG 2019-11 rev.1 sur la qualification et la classification des logiciels
• Base NANDO des organismes notifiés, Commission européenne
• Désignation d'AFNOR Certification et enregistrement dans EUDAMED, ANSM
• Enquête de la Commission européenne sur les organismes notifiés, données au 28 février 2026
• Règlement d'exécution (UE) 2026/977 du 4 mai 2026
• Barème 2026 du GMED