Fondateur de Dinno, agence de développement d'applications de santé
Révision réglementaire :
9 min de lecture
En bref
Un logiciel est un dispositif médical s'il a une finalité médicale : diagnostic, prévention, contrôle, traitement ou atténuation d'une maladie. Ni la technologie, ni le type d'utilisateur, ni le canal de vente n'entrent en jeu. Le critère décisif est la destination que vous revendiquez — dans votre notice, votre site, vos supports commerciaux. Le raisonnement doit être documenté : un partenaire, un investisseur ou une autorité vous demandera pourquoi vous avez conclu ce que vous avez conclu.
Questionnaire de qualification : votre logiciel est-il un dispositif médical ?
Six questions au maximum, fondées sur les critères du règlement (UE) 2017/745 et du guide MDCG 2019-11. Le résultat est une orientation argumentée, pas un avis réglementaire : la qualification reste de la responsabilité du fabricant.
Votre logiciel produit-il une information nouvelle à partir de données de santé ?
Répondez « non » s'il se contente de stocker, transmettre, archiver ou afficher des données sans les traiter. La compression, la reconstruction ou l'amélioration d'image comptent comme un traitement.
Cette information concerne-t-elle un patient identifié, dans un contexte de prévention, de diagnostic, de soin ou de suivi médico-social ?
Un outil de pilotage, de statistiques agrégées ou de gestion administrative répond « non ».
Revendiquez-vous une finalité de diagnostic, de prévention, de contrôle, de traitement ou d'atténuation d'une maladie ?
Regardez ce que dit votre site et votre argumentaire commercial, pas seulement votre notice. C'est la destination revendiquée qui qualifie.
Cette information est-elle utilisée pour prendre une décision diagnostique ou thérapeutique ?
Le fait que la décision finale revienne au professionnel ne change rien : la règle 11 vise l'usage de l'information, pas son caractère contraignant.
Un professionnel de santé utilise-t-il votre outil dans la prise en charge de ses patients, ou visez-vous ce marché ?
Le même produit peut être hors périmètre en usage grand public autonome et dans le périmètre dès qu'il entre dans un parcours de soin.
Une erreur de cette information pourrait-elle entraîner le décès ou une dégradation irréversible de l'état de santé ?
Raisonnez sur le scénario clinique réel, pas sur le pire cas théorique. Une dégradation grave ou une intervention chirurgicale oriente vers la classe IIb.
Votre logiciel n'est probablement pas un dispositif médical
Sur la base de vos réponses, la finalité médicale n'est pas caractérisée. Documentez ce raisonnement par écrit : c'est ce qu'un investisseur, un client en audit ou une autorité vous demandera. Attention au glissement fonctionnel — l'ajout d'une alerte, d'un score ou d'une aide à la prescription rouvre la question. Restent applicables selon votre cas : l'hébergement HDS, le RGPD et la PGSSI-S.
Vous êtes sur la frontière — et c'est la position la plus risquée
Votre produit ne revendique pas de finalité médicale, mais il est utilisé, ou destiné à être utilisé, dans un parcours de soin. C'est le cas de figure où la qualification bascule le plus souvent, généralement au moment du premier partenariat avec un établissement. Deux options : assumer la promesse et en tirer les conséquences réglementaires, ou cadrer précisément la destination revendiquée pour rester hors champ. Les deux se décident, aucune ne se subit.
Probablement un dispositif médical, classe IIa au minimum
Un logiciel destiné à surveiller des processus physiologiques relève de la classe IIa selon la règle 11 — et de la classe IIb s'il surveille des paramètres physiologiques vitaux dont la variation peut créer un danger immédiat pour le patient. Vous aurez besoin d'un organisme notifié, d'un système qualité et d'un dossier technique.
Probablement un dispositif médical de classe IIa
Votre logiciel fournit des informations utilisées pour des décisions diagnostiques ou thérapeutiques : la règle 11 le place au minimum en classe IIa. Conséquence directe : intervention d'un organisme notifié, système de management de la qualité, dossier technique, évaluation clinique et surveillance après commercialisation. L'appréciation de la gravité doit être argumentée dans votre analyse de risques — c'est le point que l'organisme examinera en premier.
Probablement un dispositif médical de classe IIb
Si une erreur peut entraîner une dégradation grave de l'état de santé ou une intervention chirurgicale, la règle 11 vous place en classe IIb. Le niveau d'exigence sur l'évaluation clinique et le dossier technique est nettement supérieur à la classe IIa, et le calendrier dépend de la disponibilité de l'organisme notifié. Cette différence de classe doit être arbitrée avant de figer votre périmètre fonctionnel.
Probablement un dispositif médical de classe III
Lorsque les décisions prises à partir de l'information peuvent entraîner le décès ou une dégradation irréversible de l'état de santé, la règle 11 conduit à la classe III — le régime le plus exigeant, avec des attentes renforcées en matière de preuve clinique. Le calendrier et le budget sont d'un autre ordre : cette conclusion mérite d'être confortée par un avis extérieur avant d'engager le développement.
Mon logiciel est-il un dispositif médical ? La méthode de qualification
La qualification est un raisonnement, pas une intuition. Elle se conduit en quatre temps et se conclut par un document écrit.
1. Formuler la destination revendiquée
Tout part de là. La destination — ce à quoi vous dites que votre produit sert — est ce qui déclenche ou non la qualification. Elle s’apprécie à travers l’ensemble de vos supports : notice, documentation, site, argumentaire commercial, démonstrations.
Écrivez-la en une phrase. Si vous n’y arrivez pas, la qualification est impossible — et c’est déjà un signal sur la maturité du positionnement produit.
Un exercice utile : comparer la phrase que vous écririez dans un dossier réglementaire à celle que votre commercial emploie face à un prospect. Quand les deux divergent, c’est presque toujours la seconde qui vous sera opposée.
2. Vérifier la finalité médicale
Le règlement vise les produits destinés à un usage de diagnostic, prévention, contrôle, traitement ou atténuation d’une maladie, d’une blessure ou d’un handicap.
Trois questions concrètes :
- Votre logiciel produit-il une information nouvelle à partir de données de santé, ou se contente-t-il de les stocker, transmettre, afficher ?
- Cette information est-elle utilisée pour une décision concernant un patient identifié ?
- Cette décision est-elle de nature diagnostique ou thérapeutique ?
Trois « oui » orientent fortement vers la qualification. Le MDCG 2019-11 fournit l’arbre de décision détaillé et les cas d’illustration.
3. Passer les cas frontières en revue
C’est là que se joue la difficulté réelle.
Le stockage et la transmission. Un système qui archive, transfère ou affiche sans traitement n’a pas de finalité médicale propre. Attention toutefois : compresser, reconstruire ou améliorer une image peut déjà constituer un traitement.
Le calcul simple. Restituer une formule connue est généralement neutre. Interpréter le résultat, l’assortir d’un seuil ou d’une recommandation ne l’est plus.
Le module dans un ensemble. Un module peut être un dispositif médical alors que le logiciel qui l’héberge ne l’est pas. La qualification s’apprécie module par module, ce qui ouvre une stratégie utile : isoler le module concerné plutôt que de faire basculer tout le produit.
L’aide à la décision « non contraignante ». Beaucoup d’équipes espèrent échapper à la qualification en précisant que la décision finale revient au professionnel. Cet argument est faible : la règle 11 vise précisément les logiciels fournissant des informations utilisées pour prendre des décisions, sans exiger qu’elles s’imposent.
Le bien-être. Un produit de bien-être qui ne revendique aucune finalité médicale reste hors champ. Mais la revendication compte plus que l’intention : « améliorez votre sommeil » et « détectez vos apnées du sommeil » ne relèvent pas du même régime.
4. Documenter la conclusion
Quelle que soit la réponse, produisez un document qui expose la destination revendiquée, les critères examinés, les cas frontières écartés et la conclusion.
Ce document vous servira trois fois : en due diligence d’investissement, en audit client, et le jour où une autorité vous interroge. Une conclusion « nous ne sommes pas un dispositif médical » sans raisonnement écrit ne vaut rien dans ces trois situations.
Le piège du glissement fonctionnel
La qualification n’est pas acquise une fois pour toutes. Le scénario le plus fréquent d’entrée involontaire dans le champ réglementaire n’est pas une erreur d’analyse initiale : c’est l’ajout d’une fonctionnalité.
Un logiciel de suivi ajoute une alerte de dégradation. Un outil de gestion ajoute une détection d’interactions médicamenteuses. Une plateforme de téléconsultation ajoute un questionnaire d’orientation.
À chaque évolution fonctionnelle significative, la question doit être reposée — et c’est un point de contrôle à intégrer à votre processus produit, pas un exercice annuel.
Si la réponse est oui
Elle ne signifie pas l’arrêt du projet, mais un projet différent : une classification selon la règle 11, un organisme notifié dès la classe IIa, un système qualité et un cycle de vie logiciel structurés. Toutes ces exigences sont plus simples à intégrer au démarrage qu’à rattraper.
Questions fréquentes
Sources officielles
- Logiciels et applications mobiles en santé — ANSM
- MDCG 2019-11 — Guidance on Qualification and Classification of Software — Commission européenne
- Règlement (UE) 2017/745, article 2 — définitions — Union européenne
Qualification DM
Obtenez un avis écrit sur la qualification de votre logiciel (DM ou non) et sa classe
Analyse de votre destination revendiquée, confrontation aux critères du MDCG 2019-11, conclusion argumentée et conséquences chiffrées. Un document opposable à vos partenaires et investisseurs.
Demander un avis de qualificationÉdité par Dinno, agence de développement d'applications de santé.