En bref
Un logiciel n'est pas automatiquement un dispositif médical parce qu'il traite des données de santé, utilise une intelligence artificielle ou est employé par un médecin.
En Europe, sa qualification dépend notamment de sa destination prévue, de ses fonctions et de la manière dont les informations qu'il produit sont destinées à être utilisées.
La première question n'est donc pas :
« Ce logiciel contient-il de l'IA ? »
mais :
« Quelle est exactement sa finalité prévue ? »
Cette distinction est essentielle, car lorsqu'un logiciel est qualifié de dispositif médical, le règlement européen relatif aux dispositifs médicaux (MDR) — ou, selon sa destination, le règlement IVDR — peut entraîner des exigences substantielles en matière de classification, gestion des risques, évaluation, documentation, cybersécurité, surveillance et conformité.
Points clés
Logiciel utilisé en santé ≠ automatiquement dispositif médical.
IA ≠ automatiquement dispositif médical.
Données de santé ≠ automatiquement dispositif médical.
La destination prévue constitue un élément central de la qualification.
Il faut distinguer qualification et classification.
Un logiciel fournissant des informations utilisées pour des décisions diagnostiques ou thérapeutiques peut relever de la règle 11 du MDR.
La validation du résultat par un médecin ne suffit pas, à elle seule, à exclure la qualification de dispositif médical.
L'analyse MDR/IVDR et l'analyse AI Act sont distinctes, même lorsqu'elles se superposent.
1. Un logiciel médical n'est pas simplement un logiciel utilisé par un médecin
Un logiciel peut être utilisé quotidiennement dans un cabinet, une clinique ou un hôpital sans être pour autant un dispositif médical.
Le règlement (UE) 2017/745 relatif aux dispositifs médicaux — MDR — apporte une distinction fondamentale.
Son considérant 19 précise en substance qu'un logiciel spécifiquement destiné par son fabricant à une ou plusieurs finalités médicales entrant dans la définition d'un dispositif médical peut constituer un dispositif médical.
À l'inverse, un logiciel à usage général ne devient pas un dispositif médical simplement parce qu'il est utilisé dans un environnement de soins.
Il en va de même des logiciels destinés à des finalités de mode de vie ou de bien-être.
Cette distinction est capitale.
Un hôpital utilise :
des logiciels de comptabilité ;
des systèmes de messagerie ;
des agendas ;
des outils de gestion des ressources humaines ;
des logiciels documentaires ;
des solutions de visioconférence ;
des outils d'archivage ;
des systèmes de facturation.
Le contexte médical dans lequel ces logiciels sont utilisés ne suffit pas à leur conférer une finalité médicale.
Le lieu d'utilisation ne détermine donc pas, à lui seul, la qualification réglementaire du logiciel.
2. La question fondamentale : quelle est la destination prévue ?
La qualification commence par l'analyse de la destination prévue (*intended purpose*).
Il faut déterminer ce que le fabricant destine réellement le logiciel à accomplir.
La question doit être formulée précisément :
Quelle fonction ce logiciel est-il destiné à accomplir pour un patient, un professionnel ou une décision médicale ?
Il faut notamment examiner :
les fonctionnalités du produit ;
les informations qu'il reçoit ;
les traitements qu'il réalise ;
les résultats qu'il produit ;
la manière dont ces résultats sont destinés à être utilisés ;
les utilisateurs auxquels il est destiné ;
les revendications du fabricant ;
sa documentation ;
ses instructions d'utilisation ;
son environnement fonctionnel.
Une description marketing ne suffit donc pas à résoudre la qualification.
Il faut comprendre ce que le système fait réellement et à quelle finalité il est destiné.
3. Qualification et classification : deux questions différentes
C'est probablement l'une des distinctions les plus importantes de toute la réglementation des logiciels médicaux.
Première question
Le logiciel est-il un dispositif médical ?
C'est la qualification.
Deuxième question
S'il est un dispositif médical, de quelle classe relève-t-il ?
C'est la classification.
Il est dangereux de commencer directement par demander :
« Est-ce une classe I ou IIa ? »
sans avoir préalablement établi que le logiciel entre effectivement dans le champ du MDR.
La logique correcte est donc :
Logiciel
↓
Destination prévue
↓
Finalité médicale ?
↓
Qualification éventuelle comme dispositif médical
↓
Classification
↓
Exigences réglementaires applicables
4. SaMD et MDSW : de quoi parle-t-on ?
Deux expressions sont fréquemment rencontrées.
SaMD — Software as a Medical Device
Le terme Software as a Medical Device (SaMD) a notamment été structuré au niveau international par l'International Medical Device Regulators Forum — IMDRF.
Il vise un logiciel destiné à être utilisé pour une ou plusieurs finalités médicales et qui réalise ces finalités sans faire partie d'un dispositif médical matériel.
Cette terminologie est particulièrement utile lorsqu'on travaille dans un environnement international.
MDSW — Medical Device Software
Dans l'environnement réglementaire européen, la documentation du Medical Device Coordination Group utilise couramment la notion de :
Medical Device Software — MDSW.
La guidance MDCG 2019-11 rev.1, actualisée en juin 2025, constitue aujourd'hui un document essentiel pour analyser la qualification et la classification des logiciels sous MDR et IVDR.
Ces termes ne doivent toutefois pas détourner de la première question :
Le logiciel possède-t-il réellement une destination qui le fait entrer dans le champ du dispositif médical ?
5. L'arbre de décision
LOGICIEL
↓
Quelle est sa destination prévue ?
↓
Finalité médicale pertinente ?
NON → Pas de dispositif médical sur ce seul fondement
OUI → Analyse MDR ou IVDR
↓
Que fait réellement le logiciel ?
Fonction administrative → Pas DM
Information pour décision clinique → Qualification requise
Monitoring / autre fonction médicale → Qualification requise
↓
Classification
↓
Exigences applicables
Cet arbre constitue un outil d'orientation. Il ne remplace pas l'analyse réglementaire complète d'un produit particulier.
6. Cas pratiques : agenda, facturation et transcription
Cas 1 — Agenda médical intelligent
Une intelligence artificielle optimise les créneaux d'une clinique en fonction :
des disponibilités ;
des annulations ;
des durées moyennes de consultation ;
des ressources disponibles.
Elle ne produit aucune information diagnostique ou thérapeutique.
Conclusion
Pas automatiquement un dispositif médical.
Le fait que l'agenda soit utilisé par des médecins ou contienne certaines informations relatives aux rendez-vous ne crée pas à lui seul une finalité médicale au sens du MDR.
Cas 2 — Logiciel de facturation médicale
Le logiciel génère les factures, suit les paiements et organise les éléments administratifs.
Conclusion
Pas un dispositif médical sur ce seul fondement.
La fonction est administrative.
Cas 3 — Transcription automatique d'une consultation
Le système transforme automatiquement une conversation médecin-patient en texte.
Conclusion
Pas automatiquement un dispositif médical.
Il faut examiner ses fonctions exactes.
Un système réalisant uniquement une transcription ne doit pas être assimilé automatiquement à un système qui interprète les données pour produire une recommandation médicale.
Mais si des fonctions supplémentaires sont ajoutées, l'analyse peut changer.
7. Le cas beaucoup plus subtil du résumé médical automatique
Prenons maintenant un système qui :
1. écoute ou reçoit la transcription d'une consultation ;
2. identifie certaines informations ;
3. les organise ;
4. propose un résumé structuré au médecin.
Il serait imprudent de répondre :
« C'est un dispositif médical. »
Mais il serait tout aussi imprudent de répondre :
« Ce n'est jamais un dispositif médical. »
Il faut déterminer notamment :
Que produit exactement le système ?
et surtout :
À quoi l'information produite est-elle destinée ?
La différence entre :
« Le patient indique avoir mal au genou depuis trois semaines »
et :
« Présentation compatible avec une pathologie nécessitant tel examen »
est réglementairement considérable.
Le premier résultat peut relever d'une fonction de documentation.
Le second peut participer à une décision clinique.
La frontière ne se situe donc pas simplement entre "IA" et "pas IA".
Elle se situe dans la fonction et la finalité du système.
8. Consentement numérique
Un système remet au patient :
un document d'information ;
enregistre sa lecture ;
permet de poser des questions ;
recueille une décision ;
réalise une authentification ;
recueille une signature ;
horodate les événements ;
assure l'intégrité du document.
Le fait que ce processus concerne un acte médical ne signifie pas automatiquement que le logiciel est lui-même un dispositif médical.
Il faut distinguer :
la gestion d'un processus médico-administratif et probatoire
de :
la production d'une information ayant elle-même une finalité diagnostique ou thérapeutique.
Cette distinction est particulièrement importante dans les plateformes numériques de parcours patient.
9. Chatbot patient : le mot « chatbot » ne permet aucune conclusion
Deux interfaces peuvent se ressembler tout en ayant des statuts réglementaires radicalement différents.
Chatbot A
Il répond :
« Votre rendez-vous est prévu mardi à 14 h. »
Chatbot B
Il analyse les symptômes du patient et produit une information destinée à orienter une décision diagnostique ou thérapeutique.
Les interfaces peuvent être presque identiques.
Mais leurs finalités prévues sont différentes.
Dire :
« C'est juste un chatbot »
n'a donc pratiquement aucune valeur pour la qualification réglementaire.
10. Analyse d'imagerie médicale
Prenons un algorithme destiné à analyser une image radiologique pour identifier une anomalie susceptible d'être utilisée par le radiologue dans son diagnostic.
Nous nous trouvons beaucoup plus clairement dans une situation nécessitant une analyse au titre du dispositif médical.
Le système ne se contente plus :
d'archiver l'image ;
de la transmettre ;
ou de l'afficher.
Il produit une information destinée à participer à une finalité médicale.
Il faut alors déterminer la qualification puis la classification appropriées.
11. Recommandation thérapeutique
Prenons maintenant un logiciel qui analyse :
les données cliniques ;
certains résultats biologiques ;
les traitements en cours ;
différents paramètres médicaux ;
et produit une information destinée à guider le choix thérapeutique.
Nous entrons directement dans l'un des domaines où la règle 11 du MDR devient particulièrement importante.
12. La règle 11 du MDR
La règle 11 constitue l'un des textes fondamentaux pour la classification des logiciels médicaux sous MDR.
Elle prévoit notamment que les logiciels destinés à fournir des informations utilisées pour prendre des décisions à des fins thérapeutiques ou diagnostiques relèvent en principe de la :
classe IIa.
Mais cette classification peut augmenter en fonction des conséquences potentielles de la décision.
Mort ou détérioration irréversible de l'état de santé
→ Classe III
Grave détérioration de l'état de santé ou intervention chirurgicale
→ Classe IIb
Dans les autres situations visées par cette partie de la règle :
→ Classe IIa
La règle traite également les logiciels destinés à contrôler des processus physiologiques.
Ils relèvent en principe de la :
→ Classe IIa
mais lorsqu'ils sont destinés à surveiller des paramètres physiologiques vitaux dont les variations pourraient présenter un danger immédiat pour le patient :
→ Classe IIb
Enfin, la règle prévoit que les autres logiciels relevant du MDR sont classés :
→ Classe I
La classification dépend donc non seulement de la fonction du logiciel, mais aussi du niveau de conséquence associé à l'information ou au processus concerné.
13. Un score clinique peut être beaucoup plus réglementé qu'il n'en a l'air
Imaginons un logiciel produisant un score.
À première vue :
« Ce n'est qu'un score. »
Mais cette formulation ne dit pratiquement rien.
Il faut demander :
Score de quoi ?
Produit à partir de quelles informations ?
Pour quelle finalité ?
Destiné à être utilisé par qui ?
Pour prendre quelle décision ?
Avec quelles conséquences potentielles ?
Un score destiné uniquement à organiser certaines priorités administratives n'a pas nécessairement le même statut qu'un score destiné à identifier un risque clinique utilisé dans une décision diagnostique ou thérapeutique.
Le format du résultat ne détermine pas son statut réglementaire. C'est sa finalité.
14. Les sept faux critères
« Il traite des données de santé, donc c'est un dispositif médical. »
Non.
Un système peut traiter des données de santé pour de nombreuses finalités sans nécessairement être un dispositif médical.
La protection des données et la réglementation des dispositifs médicaux constituent deux analyses différentes.
« Il est utilisé dans un hôpital, donc c'est un dispositif médical. »
Non.
Le MDR distingue les logiciels ayant une destination médicale des logiciels généraux simplement utilisés dans un environnement de soins.
« Il utilise de l'intelligence artificielle, donc c'est un dispositif médical. »
Non.
L'utilisation de l'IA ne suffit pas.
La qualification au titre du MDR/IVDR et celle au titre de l'AI Act doivent être analysées séparément.
« Il est utilisé par un médecin, donc c'est un dispositif médical. »
Non.
Le statut professionnel de l'utilisateur ne suffit pas à qualifier le logiciel.
« Il produit un PDF médical, donc c'est un dispositif médical. »
Pas nécessairement.
Produire ou structurer un document n'équivaut pas automatiquement à produire une information ayant une finalité médicale au sens réglementaire.
« Le médecin valide le résultat, donc ce n'est pas un dispositif médical. »
Ce raisonnement n'est pas suffisant.
L'intervention humaine doit être prise en compte dans l'analyse du système, mais la présence d'un médecin en bout de chaîne ne neutralise pas automatiquement la destination médicale du logiciel.
« Nous écrivons "outil d'aide" dans les CGU, donc le MDR ne s'applique pas. »
Ce serait une approche dangereusement simplificatrice.
La destination prévue doit être appréciée au regard de l'ensemble des éléments pertinents relatifs au produit et à son utilisation prévue.
Une formule contractuelle isolée ne doit pas être utilisée comme mécanisme artificiel de contournement réglementaire.
15. Le cas de l'intelligence artificielle
Supposons maintenant que le logiciel qualifié de dispositif médical utilise également de l'intelligence artificielle.
Une seconde analyse commence.
Il faut alors examiner son statut au regard du :
Règlement (UE) 2024/1689 — AI Act.
Deux raisonnements doivent donc être conservés séparément :
LOGICIEL
↓
MDR / IVDR — Dispositif médical ? → Classification
AI ACT — Système IA ? → Classification réglementaire
↓
Articulation des obligations
C'est précisément cette articulation qui fait l'objet de la FAQ MDCG 2025-6 publiée en juin 2025.
Une IA médicale peut donc être confrontée simultanément à plusieurs couches réglementaires.
16. Attention aux évolutions du logiciel
La qualification réglementaire ne doit pas être considérée comme une photographie prise une seule fois au lancement du produit.
Un logiciel évolue.
De nouvelles fonctionnalités apparaissent.
Un outil initialement destiné à :
« retranscrire une consultation »
peut progressivement devenir :
« structurer les informations »
puis :
« détecter des anomalies »
puis :
« proposer des examens »
puis :
« recommander une conduite thérapeutique ».
À chaque évolution significative, la destination, les fonctions, les performances et les risques doivent être réévalués au regard du cadre applicable.
Une fonctionnalité supplémentaire peut donc modifier profondément le profil réglementaire d'un produit.
17. Le test Elysium MedTech en huit questions
Avant de conclure qu'un logiciel est — ou n'est pas — un dispositif médical, huit questions devraient au minimum être documentées.
1. Quelle est sa destination prévue ?
Décrire précisément ce que le système est destiné à accomplir.
2. Existe-t-il une finalité médicale relevant du cadre réglementaire ?
Ne pas déduire cette finalité uniquement du contexte hospitalier.
3. Que fait réellement le logiciel avec les données ?
Stockage ? Transmission ? Organisation ? Calcul ? Analyse ? Interprétation ? Prédiction ? Recommandation ?
4. Quelle information produit-il ?
Un document ? Une alerte ? Un score ? Une détection ? Une recommandation ? Une prédiction ?
5. Cette information est-elle destinée à une décision diagnostique ou thérapeutique ?
Si oui, la règle 11 doit notamment être examinée.
6. Surveille-t-il un processus physiologique ?
Et, le cas échéant, des paramètres physiologiques vitaux ?
7. Quelles seraient les conséquences d'une information erronée ?
Cette question devient déterminante pour la classification.
8. Quelle réglementation et quelle classification en découlent ?
MDR ? IVDR ? AI Act ? Plusieurs cadres simultanément ?
18. Le piège du « disclaimer réglementaire »
Une MedTech ne devrait jamais construire son modèle de conformité autour d'une phrase telle que :
« Cet outil ne remplace pas l'avis d'un médecin. »
Cette mention peut être pertinente dans certains contextes.
Mais elle ne constitue pas à elle seule une stratégie de qualification réglementaire.
De la même manière, écrire :
« À titre informatif uniquement »
ne transforme pas automatiquement un système destiné en pratique à produire une information médicale en logiciel administratif.
La gouvernance réglementaire doit commencer par les fonctions et la destination réelle du produit, puis se traduire de manière cohérente dans :
les spécifications ;
la documentation ;
l'interface ;
les communications commerciales ;
les instructions ;
la gestion des risques ;
la validation ;
la surveillance.
19. Qualification by design
La bonne question ne devrait donc pas apparaître six mois après le développement :
« Notre logiciel est-il un dispositif médical ? »
Elle devrait apparaître dès la conception.
IDÉE PRODUIT
↓
FINALITÉ PRÉVUE
↓
FONCTIONS
↓
QUALIFICATION
↓
CLASSIFICATION
↓
RISQUES
↓
ARCHITECTURE
↓
VALIDATION
↓
DOCUMENTATION
↓
MISE SUR LE MARCHÉ / DÉPLOIEMENT
↓
SURVEILLANCE
Cette approche évite de découvrir tardivement qu'une fonctionnalité centrale modifie la qualification du produit.
Elle permet surtout de faire de la réglementation une composante de l'architecture du produit plutôt qu'un correctif juridique ajouté à la fin du développement.
20. Ce qu'il faut retenir
Un logiciel ne devient pas un dispositif médical parce qu'il :
utilise de l'intelligence artificielle ;
contient des données de santé ;
est installé dans une clinique ;
est utilisé par un médecin ;
produit un document médical.
La qualification repose sur une analyse réglementaire plus profonde.
Il faut comprendre :
sa destination prévue
↓
ses fonctions
↓
les informations qu'il produit
↓
l'utilisation prévue de ces informations
↓
leur influence éventuelle sur une décision médicale
↓
les conséquences potentielles
Ce n'est qu'ensuite que l'on peut déterminer correctement le cadre réglementaire et, lorsque le logiciel constitue un dispositif médical, sa classification.
Un logiciel ne devient pas médical parce qu'il entre dans un hôpital. Il entre dans le champ du dispositif médical lorsque sa destination prévue et ses fonctions répondent aux critères réglementaires applicables.
Sources réglementaires principales
Union européenne — Règlement (UE) 2017/745 relatif aux dispositifs médicaux (MDR) — notamment définition du dispositif médical, considérant 19 et annexe VIII, règle 11.
European Commission / Medical Device Coordination Group — MDCG 2019-11 rev.1, juin 2025 — *Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR.*
European Commission / MDCG — MDCG 2025-6, juin 2025 — *FAQ on Interplay between the Medical Devices Regulation (MDR) & In Vitro Diagnostic Medical Devices Regulation (IVDR) and the Artificial Intelligence Act (AIA).*
International Medical Device Regulators Forum — IMDRF/SaMD WG/N10FINAL:2013 — *Software as a Medical Device (SaMD): Key Definitions.*
Union européenne — Règlement (UE) 2024/1689 — *Artificial Intelligence Act.*
Note méthodologique
Les documents MDCG constituent des documents d'orientation destinés à favoriser une compréhension et une mise en œuvre harmonisées des règlements MDR et IVDR. Ils ne remplacent pas les textes juridiquement contraignants.
La qualification et la classification d'un logiciel doivent être établies individuellement au regard de sa destination prévue, de ses fonctions et des caractéristiques du produit concerné.
Note éditoriale
Cet article fournit une information générale relative au cadre réglementaire européen des logiciels médicaux. Il ne constitue ni une décision de qualification ou de classification réglementaire d'un produit déterminé, ni un avis juridique ou réglementaire individualisé.
Elysium MedTech
*Intelligence médicale. Technologie responsable. Gouvernance by design.*