Le logiciel en tant que dispositif médical (SaMD) dans le cadre du MDR de l'UE : ce que les équipes de développement doivent savoir

La qualification passe avant le classement

Commencez par l’objectif médical prévu, les utilisateurs et les décisions prises en charge par chaque module. Une fonctionnalité de stockage ou de communication n’est pas automatiquement un dispositif médical ; un module d’interprétation peut nécessiter une évaluation distincte. La classification suit la qualification et les règles applicables, et non le label technologique « IA ». Consulter MDCG 2019-11 rév.1.

Pour une révision de conception, notez ce qu'une sortie incorrecte pourrait provoquer et comment l'utilisateur agit en conséquence. Gardez cette évaluation à côté du carte plus large de conformité des soins de santé dans l’UE.

Introduction

Si vous développez un logiciel de santé en Europe, il y a une question à laquelle votre équipe doit répondre rapidement : Votre logiciel est-il considéré comme un dispositif médical au sens du règlement européen sur les dispositifs médicaux (RMD) ?

Avant de mettre sur le marché ou de mettre en service un logiciel éligible, déterminez la voie de conformité applicable et les éventuelles exemptions spécifiques avec le propriétaire réglementaire. L’objectif prévu, le contexte de fonctionnement et les conséquences d’une sortie incorrecte comptent tous ; une étiquette de logiciel générique ne constitue pas une évaluation de la conformité.

En tant que développeur qui crée des applications de soins de santé, notamment des outils d'aide à la décision clinique et des intégrations de DSE améliorées par l'IA, j'ai parcouru ce paysage réglementaire sur plusieurs projets. Cet article couvre ce que les équipes de développement doivent réellement savoir.

Quand un logiciel devient-il un dispositif médical ?

Le MDR de l’UE (Règlement 2017/745) définit un dispositif médical au sens large. Un logiciel est considéré comme un dispositif médical s'il est destiné par le fabricant à une ou plusieurs de ces fins médicales :

Diagnostic — identifier une maladie, une condition ou un facteur de risque
Prévention — prévenir une maladie ou une blessure
Surveillance — suivi des processus physiologiques ou pathologiques
Prédiction — prédire la progression de la maladie ou les résultats du traitement
Traitement — fournir des recommandations thérapeutiques ou contrôler la délivrance du traitement

Exemples nécessitant une évaluation des dispositifs médicaux

Aide à la décision clinique qui recommande des diagnostics ou des traitements spécifiques
Des modèles IA/ML qui interpréter des images médicales (radiologie, pathologie, dermatologie)
Logiciel qui calcule les doses de médicaments basé sur les paramètres du patient
Des applications mobiles qui surveiller les maladies chroniques et déclencher des alertes cliniques
Logiciel qui commandes ou interfaces avec des dispositifs médicaux physiques
Des outils de stratification des risques qui prédire événements cliniques (septicémie, réadmission, détérioration)

Fonctions généralement en dehors de la qualification lorsqu'elles sont limitées à ces fins

Logiciel pour à des fins administratives uniquement (planification, facturation, RH)
Des systèmes de DSE qui stocker et exposer des données sans les interpréter
Outils de communication (plateformes vidéo de télésanté sans fonctionnalités de décision clinique)
Logiciel pour bien-être général (trackers de fitness, applications de méditation)
Bases de données de référence clinique et outils pédagogiques

La distinction clé est objectif prévu. La même fonctionnalité logicielle peut être un dispositif médical ou non, selon la manière dont vous le commercialisez et le décrivez. Si les allégations marketing de votre produit incluent des mots tels que « diagnostiquer », « prédire », « détecter » ou « recommander un traitement », vous êtes probablement sur le territoire des dispositifs médicaux.

Classification MDR pour les logiciels

Si votre logiciel est un dispositif médical, l'étape suivante est la classification. Le MDR utilise Règle 11 (Annexe VIII) spécifiquement pour les logiciels :

Règle 11 Classement

Les logiciels destinés à fournir des informations permettant de prendre des décisions à des fins diagnostiques ou thérapeutiques sont classés comme suit :

Branche de la règle 11	Classement
Informations appuyant les décisions diagnostiques ou thérapeutiques, sans les conséquences à risque plus élevé ci-dessous	IIa
De telles décisions peuvent entraîner une détérioration grave ou nécessiter une intervention chirurgicale	IIb
De telles décisions peuvent entraîner la mort ou une détérioration irréversible	III
Surveillance des processus physiologiques	IIa
Surveillance des paramètres vitaux dont les variations pourraient créer un danger immédiat	IIb
Autres logiciels dans la règle	Je

Ces branches paraphrasent Annexe VIII du MDR, règle 11. Les autres règles applicables doivent également être évaluées. Un nom de produit ou un exemple générique est insuffisant pour attribuer une classe.

Le cycle de vie du développement sous MDR

CEI 62304 : Norme sur le cycle de vie des logiciels

CEI 62304 décrit les processus du cycle de vie des logiciels des dispositifs médicaux. Vérifiez l’édition applicable et l’état d’harmonisation actuel pour votre stratégie de conformité. Elle définit trois classes de sécurité des logiciels :

Classe A — aucune blessure ou atteinte à la santé possible
Classe B — blessures non graves possibles
Classe C — mort ou blessure grave possible

La classe de sécurité détermine la rigueur de vos processus de développement :

                    Class A        Class B        Class C
                    ────────       ────────       ────────
Development Plan    Required       Required       Required
Requirements        Required       Required       Required
Architecture        Optional       Required       Required
Detailed Design     Optional       Optional       Required
Unit Testing        Optional       Required       Required
Integration Testing Required       Required       Required
System Testing      Required       Required       Required
Traceability        Req → Test     Req → Arch     Full trace
                                   → Test         Req → Arch
                                                  → Design
                                                  → Code
                                                  → Test

Ce que cela signifie pour votre processus de développement

Gestion des exigences

Chaque exigence logicielle doit être :

Documenté et identifié de manière unique
Traçable jusqu'aux éléments de conception, au code et aux tests
Révisé et approuvé avant la mise en œuvre
Lié aux résultats de l’analyse des risques

Cela ne veut pas dire cascade. Vous pouvez utiliser des méthodologies agiles, mais vous devez maintenir la traçabilité. Chaque sprint doit produire des exigences traçables et documentées liées aux cas de test.

Documentation architecturale

Pour les logiciels de classes B et C, vous devez documenter votre architecture logicielle :

Architecture du système et décomposition des composants
Interfaces externes (API, bases de données, services tiers)
Exigences fonctionnelles et de performances attribuées aux composants
SOUP (Logiciel de Provenance Inconnue) — chaque bibliothèque et framework tiers doivent être identifiés, évalués et surveillés

Cette exigence SOUP a un impact particulièrement important pour les applications modernes JavaScript/TypeScript. Chaque package npm de votre arborescence de dépendances est techniquement SOUP. Vous devez :

Tenir un inventaire de tous les articles SOUP (nom, version, utilisation prévue)
Évaluer le risque de défaillance ou de comportement inattendu de chaque élément SOUP
Documentez les critères d’évaluation (est-il activement maintenu ? est-il largement utilisé ? existe-t-il des vulnérabilités connues ?)
Surveillez les mises à jour, les avis de sécurité et les annonces de fin de vie

Gestion des risques (ISO 14971)

La gestion des risques est l’épine dorsale de la conformité au MDR. OIN 14971 définit le processus :

Analyse des risques — identifier les dangers et estimer les risques (gravité × probabilité)
Évaluation des risques — déterminer si les risques sont acceptables
Contrôle des risques — mettre en œuvre des mesures pour réduire les risques inacceptables
Évaluation des risques résiduels — vérifier que les contrôles des risques sont efficaces et n'introduisent pas de nouveaux risques
Analyse risques-avantages — pour les risques résiduels, confirmer que les bénéfices cliniques sont supérieurs aux risques restants

Pour les systèmes basés sur l’IA/ML, l’analyse des risques doit également aborder :

Dégradation des performances du modèle au fil du temps (dérive des données)
Biais dans les données de formation cela pourrait conduire à un diagnostic erroné dans des populations spécifiques
Cas extrêmes où la confiance du modèle est indûment élevée ou faible
Contributions contradictoires qui pourrait manipuler les sorties du modèle

Système de gestion de la qualité (ISO 13485)

Le MDR exige que les fabricants opèrent selon un Système de gestion de la qualité (QMS) conforme à la norme ISO 13485. Cela couvre :

Contrôle des documents — procédures de création, de révision et d'approbation de la documentation
Conception et développement — des processus structurés depuis la planification jusqu'à la validation
Achats — contrôles sur SOUP et composants tiers
Production et service — processus de déploiement, de surveillance et de maintenance
Actions correctives et préventives (CAPA) — approche systématique pour résoudre les problèmes
Audits internes — évaluation régulière de l'efficacité du système de gestion de la qualité

Pour les petites équipes de développement, la mise en œuvre d’un système de gestion de la qualité complet peut sembler fastidieuse. Mon conseil : commencez par l'essentiel (contrôle des documents, contrôle de la conception, CAPA) et développez progressivement. Il existe des outils QMS légers conçus pour les éditeurs de logiciels qui rendent cela gérable sans frais généraux de niveau entreprise.

Évaluation clinique

MDR nécessite un évaluation clinique pour démontrer que votre logiciel atteint les avantages cliniques escomptés. Pour les logiciels, cela implique généralement :

Revue de la littérature — des preuves issues d'études publiées soutenant l'approche clinique du logiciel
Données d'investigation clinique — si disponibles, données de vos propres études cliniques ou déploiements pilotes
Revendications d'équivalence — comparaison avec des dispositifs similaires déjà sur le marché (le MDR a des exigences d'équivalence plus strictes que le précédent MDD)
Suivi clinique post-commercialisation (PMCF) — collecte continue de données après la mise sur le marché

Pour les systèmes AI/ML, l’évaluation clinique doit inclure des données de performance sur des populations de patients européennes représentatives, et pas seulement l’ensemble de données sur lequel le modèle a été formé.

Processus de marquage CE

Pour placer légalement votre logiciel de dispositif médical sur le marché de l'UE, vous avez besoin du marquage CE :

1. Classification (Rule 11)
       │
       ▼
2. Quality Management System (ISO 13485)
       │
       ▼
3. Technical Documentation
   ├── Device description and specifications
   ├── Design and manufacturing information
   ├── Risk management file (ISO 14971)
   ├── Clinical evaluation report
   ├── IEC 62304 lifecycle documentation
   └── Labeling and instructions for use
       │
       ▼
4. Conformity Assessment
   ├── Class I → Self-assessment (no Notified Body)
   └── Class IIa/IIb/III → Notified Body audit
       │
       ▼
5. EU Declaration of Conformity
       │
       ▼
6. CE Marking → Market Placement
       │
       ▼
7. Post-Market Surveillance (ongoing)

Le goulot d’étranglement des organismes notifiés

L’un des plus grands défis pratiques en 2025-2026 est nombre limité d'organismes notifiés désigné sous le MDR. Les délais d'attente pour les évaluations de conformité peuvent être de 6 à 12 mois, voire plus. Planifiez en conséquence : le marquage CE n'est pas quelque chose que vous pouvez précipiter à la fin du développement.

Conseils pratiques pour les équipes de développement

Déterminez votre classification tôt - engagez-vous avec un consultant en réglementation avant d'écrire un code important. Découvrir que vous avez besoin d’une conformité MDR tard dans le développement coûte cher.
Intégrez la CEI 62304 dans votre processus agile — il est possible d'être agile et conforme. Utilisez des outils prenant en charge la traçabilité (exigences → code → tests) et automatisez la documentation lorsque cela est possible.
Gérez votre SOUPE avec rigueur — créer et maintenir un inventaire SOUP dès le premier jour. Utiliser npm audit et Dependabot, mais maintiennent également un inventaire de niveau réglementaire avec des évaluations des risques.
Conception pour la surveillance post-commercialisation — votre système déployé doit renvoyer des données de performances pour une évaluation clinique continue. Créez une surveillance et des analyses dès le départ.
Démarrez le processus d’organisme notifié plus tôt — n'attendez pas que votre logiciel soit « prêt ». Collaborez avec un organisme notifié pendant le développement pour éviter les surprises lors de l’évaluation de la conformité.

Conclusion

Développer un logiciel pour dispositifs médicaux dans le cadre du MDR de l'UE est une entreprise importante, mais elle est réalisable, surtout si vous le planifiez dès le départ plutôt que d'adapter la conformité à un produit existant. La clé est de traiter les exigences réglementaires comme faisant partie intégrante de votre processus de développement, et non comme un flux de travail de conformité distinct.

Si vous créez un logiciel de santé et avez besoin d'aide pour déterminer votre classification MDR ou structurer votre processus de développement pour la conformité, je serai heureux de discuter de votre situation.