SaMD : concevoir, certifier et faire évoluer votre logiciel

Introduction

Le développement d’un Software as a Medical Device (SaMD) s’inscrit dans un double impératif : répondre dès la conception aux exigences du Règlement (UE) 2017/745 (RDM) et, une fois sur le marché, renouveler ou enrichir le logiciel sans compromettre ni sa conformité ni son marquage CE.

Chez Certeafiles, nous œuvrons pour abaisser les barrières réglementaires et libérer votre innovation. Suivez notre guide pratique et transformez la certification en véritable levier de performance pour votre entreprise éditrice de SaMD.

Faisons le point en deux volets :

1. Conception réglementaire et technique d’un SaMD conforme au RDM.
2. Pilotage des évolutions – mises à jour, nouvelles fonctions et correctifs – tout en préservant la validité du marquage CE.

1. Conception réglementaire et technique sous le RDM

1.1 Qualification et classification : la première brique

Qualification (article 2, MDCG 2019-11)

• Déterminez si votre logiciel répond à la définition d’un dispositif médical en fonction de son utilisation prévue (diagnostic, prévention, pronostic, suivi ou aide à la décision médicale).
• Formulez ce choix dans un mémo de qualification qui vous suivra jusqu’à la certification et facilitera toute réévaluation.

Classification (annexe VIII, MDCG 2019-11, MDCG 2021-24)

Toutes les règles de classification s’appliquent et un SaMD est un dispositif médical actif. La règle 11, Annexe VIII est dédiée aux logiciels, y compris les SaMD :

• Logiciels destinés à fournir des informations utilisées pour prendre des décisions à des fins diagnostiques ou thérapeutiques, ou à surveiller des processus physiologiques, sont classés au minimum en classe IIa (voire en IIb ou III si l’impact peut être grave ou mettre le patient en danger). Ils justifient un examen par un organisme notifié (ON).
• Seuls les autres logiciels peuvent prétendre à la classe I.

1.2 Normes applicables : piliers de votre conformité

1.3 Documentation requise par l’IEC 62304

La norme IEC 62304 traite le cycle de vie des logiciels de dispositifs médicaux, incluant les SaMD, en fonction de leur classe de sécurité logicielle (A, B ou C). La documentation nécessaire pour le dossier logiciel est directement liée à la classification et aux facteurs de risque. Toutefois certains éléments sont indispensables quelle que soit la classe du dispositif :

1.Conception et Développement logiciel
Il est attendu dans le cadre de la conception un plan de développement logiciel détaillant les processus, livrables, la traçabilité des exigences, la gestion de la configuration et la résolution des problèmes logiciels. Ce plan est mis à jour tout au long du développement logiciel.
La liste des exigences logiciels doit être également documentée, elle détaille chaque exigence avec la vérification associée et la liste doit aborder les thèmes suivants : entrées/sortie du sysème logiciel, interfaces avec les autres systèmes, alarmes, sûreté, base de données, installation/acceptation, exploitation /maintenance, documentation utilisateur, exigences réglementaires.
Un « cycle en V » de développement logiciel doit être mis en place, ce dernier consistant à décomposer le système logiciel en unités logicielles (branche descendante du V) puis à valider ces unités logicielles avant de remonter vers le système (branche ascendante du V).
Ainsi, une fois le logiciel décomposé en unités logicielles, un plan de mise en œuvre et de vérification des unités logicielles doit être mis en place.
Une liste des versions logicielles diffusées doit être documentée et un plan de maintenance du logiciel doit être établi.

2.Gestion des problèmes logiciels
Les retours d’information doivent être contrôlés, consignés et évalués, dans le cadre d’un processus de résolution des problèmes logiciel. Ces retours d’informations doivent être tracés et enregistrés selon leur type, domaine d’application et criticité, ils permettant ensuite de formaliser une demande de modification.
Dans certains cas, des analyses de tendance peuvent être utiles pour identifier des récurrences ou anticiper des défaillances futures. La gestion des configurations est également cruciale : il convient de maintenir à jour un inventaire précis des éléments logiciels, de leurs versions, et de leur documentation associée. Cela inclut l’identification des composants logiciels tiers (appelés SOUP, pour Software of Unknown Provenance), dont les éventuelles défaillances ou absences de support doivent être prises en compte dans la gestion des risques.

3.Gestion des modifications
La gestion des modifications est un élément également fondamental dans le cadre de la maîtrise du cycle de vie logiciel. Chaque changement doit faire l’objet d’une évaluation formelle pour en mesurer les impacts techniques et réglementaires. Il doit ensuite être approuvé, documenté, et communiqué aux parties concernées : utilisateurs, organismes de certification, ... L’implémentation des modifications doit s’accompagner d’une vérification complète, garantissant la conformité du logiciel mis à jour avec les exigences initiales. La traçabilité des modifications doit être garantie jusqu’à la diffusion de la nouvelle version.

1.4 Évaluation clinique : adapter l’effort au risque

1.Revue de littérature
Pour un calcul ou score établi, une synthèse bibliographique ciblée + tests de non-régression peut suffire.

2.Étude clinique/Étude des performances techniques et cliniques
Incontournable dès que vous introduisez un algorithme nouveau (IA, apprentissage automatique) : pensez à un dataset indépendant, une métrique AUC/Se-Sp et un protocole adapté au risque.

3.Compilation des données
Les données cliniques sont compilées dans un rapport d’évaluation clinique.

4.Surveillance post-market (PMCF)
Complète l’évaluation initiale : retours d’expérience, incidents, indicateurs de performance en vie réelle.

Recommandation : dimensionner votre plan d’évaluation clinique sur la classe de risque et le degré d’innovation, non sur un format unique.

2. Gestion des évolutions : maintenir le marquage CE à jour

2.1 Soumission des demandes de changement à l’organisme notifié

Le MDR (UE 2017/745) encadre la gestion des modifications :

• Fabricant : chaque évolution est traitée dans le SMQ (art. 10 § 9) et doit être notifiée à l’ON avant mise en œuvre dès qu’elle peut affecter la sécurité, la performance ou l’usage prévu (annexe IX § 4.10).
• Organisme notifié : conformément à l’annexe VII § 4.9, il reçoit, évalue l’impact, puis statue – addendum au certificat ou ré-évaluation complète – au moyen d’une décision motivée.
• Pour les dispositifs (« legacy MD »), certifiés sous AIMDD/MDD avant l’entrée en vigueur du MDR et régis par l’article 120, selon la guidance MDCG 2020-3 :
  • un changement non significatif peut être implémenté durant la période de transition ;
  • un changement significatif impose le basculement complet sous MDR avant déploiement.

2.2 Plan de contrôle des changements prédéterminés (PCCP) pour l’IA

L’AI Act (UE 2024/1689) oblige les fournisseurs de systèmes IA à haut risque à documenter les modifications prévues et les mesures garantissant la conformité continue. Le MDCG 2025-6 (section V) précise qu’un DM intégrant un système apprenant dont les évolutions ont été évaluées lors de l’examen initial n’a pas à repasser une procédure complète : d’où l’intérêt d’intégrer, dès le dépôt du dossier CE, un PCCP inspiré de la FDA et adapté au cadre européen.

Un PCCP solide repose sur cinq principes directeurs :

• Concentré et délimité : Périmètre défini des évolutions autorisées (hyperparamètres, seuils, versions, ré-entraînement)
• Basé sur le risque : Intégration au SMQ ISO 13485 et à la gestion des risques ISO 14971
• Fondé sur des preuves : Protocoles de test et KPI figés pour revalider chaque mise à jour
• Transparent : Seuils d’alerte et processus formel de notification à l’organisme notifié
• Perspective cycle de vie total (TPLC) : Revues périodiques et audits internes pour vérifier en continu la conformité

Ainsi, le fabricant évite une re-certification à chaque itération tout en préservant sécurité, performance et agilité.

3. Synthèse des réflexes pour une conformité agile

• Modularité : isoler UI, moteur clinique et pipeline IA pour limiter l’étendue de chaque évolution.
• Traçabilité automatisée : chaque merge request nourrit votre dossier technique (commit → tickets → annexes CE).
• Surveillance post-market “live” : dashboard anonyme de performance, incidents et KPI à jour.
• Mémos “no-notify” standardisés : trois pages, références croisées aux MDCG et signés RA/QA.
• Rituels croisés : sprint review avec RA/QA et revue des risques avec les devs pour maintenir une langue commune.

Conclusion

Concevoir et faire évoluer un SaMD sous le RDM n’est pas une contrainte figée, mais un processus dynamique :

• Des normes solides (ISO 13485, IEC 62304, ISO 14971) vous apportent un cadre clair.
• Un pilotage structuré des modifications vous protège sans ralentir l’innovation.
• Un partenariat proactif avec votre ON transforme un audit en simple étape de vérification.

Prêt à transformer la certification de votre SaMD en un véritable atout ?
Chez Certeafiles, nous vous accompagnons à chaque étape :

• Accompagnement personnalisé par nos experts.
• Formations sur-mesure pratiques et adaptées à vos besoins.
• Audits internes.
• Bientôt disponible : notre outil digital pour vous guider pas-à-pas de A à Z vers la certification CE de votre logiciel dispositif médical.

👉 Contactez-nous pour un premier échange gratuit et découvrez comment Certeafiles peut accélérer et sécuriser votre mise sur le marché.