SaMD vs SiMD : logiciel dispositif médical selon la FDA et l'EU MDR

TL;DR

Le logiciel en tant que dispositif médical (SaMD) est un logiciel qui remplit une finalité médicale sans faire partie d'un dispositif médical matériel. Le logiciel intégré à un dispositif médical (SiMD) est un logiciel qui pilote un dispositif matériel ou y est intégré. La définition internationale provient de l'International Medical Device Regulators Forum (IMDRF). Celui-ci définit le SaMD comme un "logiciel destiné à être utilisé pour une ou plusieurs finalités médicales qui remplit ces finalités sans faire partie d'un dispositif médical matériel." ¹

Cette distinction détermine la manière dont le logiciel est classé et soumis. Dans l'UE, le SaMD est classé de manière autonome, principalement au titre de la règle 11 du MDR. Le logiciel qui pilote un dispositif prend la classe de ce dispositif. Aux États-Unis, la FDA autorise les fonctions logicielles de dispositifs via 510(k), De Novo ou PMA. La liste des dispositifs intégrant l'IA de la FDA illustre cette tendance. Sur les 1 614 dispositifs figurant sur la liste, 96,2 % ont accédé au marché via 510(k). Le nombre de dispositifs autorisés par an est passé de 18 en 2016 à 335 en 2025. ²

2026 a apporté plusieurs changements. La FDA a révisé ses lignes directrices sur l'aide à la décision clinique et le bien-être général en janvier, ainsi que ses lignes directrices sur la cybersécurité en février. L'UE a reporté les obligations de l'AI Act relatives au haut risque pour les dispositifs médicaux intégrant l'IA au 2 août 2028. Ce guide explique les définitions, comment déterminer si un logiciel constitue ou non un dispositif médical, la manière dont la FDA et l'UE le classent, ce que contient un dossier de soumission et la façon dont les autres grands marchés le traitent.

SaMD, SiMD et MDSW : ce que signifie chaque terme

Le SaMD est un terme défini. Le SiMD est une désignation descriptive sans définition juridique contraignante. L'UE utilise un troisième terme, le MDSW (logiciel dispositif médical), qui englobe les deux.

L'IMDRF est explicite quant à la frontière : "Un logiciel ne répond pas à la définition de SaMD si sa destination est de piloter un dispositif médical matériel." Il précise également que "les applications mobiles qui répondent à la définition ci-dessus sont considérées comme des SaMD." La politique de 2022 de la FDA sur les fonctions logicielles de dispositifs indique qu'elles "peuvent inclure le 'Software as a Medical Device (SaMD)' et le 'Software in a Medical Device (SiMD).'" ³

Dans l'UE, le guide MDCG 2019-11 Rev.1 remplace "logiciel autonome" par MDSW et souligne que l'ancien terme "n'est plus utilisé dans le contexte des règlements relatifs aux dispositifs médicaux." La règle de mise en œuvre 3.3 du MDR fixe les conséquences sur la classification : "Le logiciel qui commande un dispositif ou a une incidence sur son utilisation entre dans la même classe que le dispositif lui-même. Si le logiciel est indépendant de tout autre dispositif, il est classé de manière autonome." ^{4 5}

En Australie, la TGA décrit le SiMD dans les termes les plus concrets. Ce type de logiciel est "généralement fourni préinstallé avec le dispositif matériel", et "le SiMD est réglementé comme faisant partie intégrante du dispositif dans lequel il est installé." ⁶

Première question : le logiciel constitue-t-il un dispositif médical ?

De nombreux logiciels de santé ne sont pas des dispositifs. La destination et, aux États-Unis, cinq exclusions légales en décident.

Aux États-Unis, l'article 520(o) du FD&C Act, ajouté par le 21st Century Cures Act, exclut cinq types de fonctions logicielles de la définition de dispositif médical :

• le soutien administratif ;
• le maintien ou l'encouragement d'un mode de vie sain, sans lien avec une maladie ;
• les dossiers patients informatisés, à moins que la fonction ne les interprète ou ne les analyse ;
• le transfert, le stockage, la conversion ou l'affichage de données, à moins qu'elle n'interprète ou n'analyse ces données ;
• certains systèmes d'aide à la décision clinique (CDS). ⁷

L'exclusion relative aux CDS ne s'applique que lorsque le logiciel n'analyse pas d'images ou de signaux médicaux. Il doit afficher ou analyser des informations médicales, étayer la recommandation d'un professionnel de santé et permettre à ce dernier d'en examiner les fondements de manière indépendante.

La FDA a révisé deux politiques clés en janvier 2026 :

• Aide à la décision clinique. Les lignes directrices ont été republiées le 6 janvier 2026 et corrigées le 29 janvier 2026. Un logiciel qui fournit une directive diagnostique ou thérapeutique spécifique ne satisfait pas au troisième critère. Lorsqu'une seule option est cliniquement appropriée et que le logiciel répond par ailleurs aux critères, la FDA a l'intention d'exercer son pouvoir discrétionnaire d'application. Les logiciels qui fournissent des recommandations aux patients ou aux aidants, plutôt qu'aux professionnels de santé, demeurent des dispositifs médicaux. ⁸
• Bien-être général. La politique révisée du 6 janvier 2026 indique que la FDA "peut considérer certains produits faisant appel à une détection non invasive" pour estimer des paramètres physiologiques, tels que la pression artérielle, la saturation en oxygène ou le glucose, comme des produits de bien-être général. Cela ne s'applique que sous certaines conditions. Le produit doit être non invasif, ne doit pas se substituer à un dispositif autorisé par la FDA et ne doit pas fournir de données de sortie incitant à une action clinique spécifique. ⁹

Dans l'UE, le guide MDCG 2019-11 Rev.1 définit un parcours décisionnel. Un logiciel destiné à "des fins générales, même lorsqu'il est utilisé dans un cadre de soins de santé", ou à "des fins liées au mode de vie et au bien-être" n'est pas un dispositif au titre du considérant 19 du MDR. Un logiciel qui crée ou modifie des informations médicales pour un patient donné l'est généralement. La révision de juin 2025 met l'accent sur une destination clairement rédigée et sur les logiciels modulaires, dont seuls certains modules sont qualifiés de dispositifs médicaux.

Comment les SaMD sont classés par niveau de risque

Le cadre de l'IMDRF constitue le langage commun. Chaque autorité réglementaire le convertit ensuite dans ses propres classes juridiques.

Le cadre de l'IMDRF défini dans le document N12 catégorise les SaMD selon deux facteurs. Le premier est l'état de la situation de soins : critique, grave ou non grave. Le second est l'importance de l'information pour la décision médicale : traiter ou diagnostiquer, guider la prise en charge clinique ou éclairer la prise en charge clinique. ¹⁰

L'IMDRF avertit que cela « n'est pas une classification réglementaire ». En janvier 2025, il a publié le document N81, qui complète le N12 par des considérations de risque propres aux logiciels pour tous les logiciels de dispositifs médicaux, y compris les logiciels intégrés au matériel. ¹¹

La règle 11 du MDR de l'UE traduit cette même logique dans le droit :

« Les logiciels destinés à fournir des informations utilisées pour prendre des décisions à des fins diagnostiques ou thérapeutiques relèvent de la classe IIa, sauf si ces décisions ont une incidence susceptible de causer : — la mort ou une détérioration irréversible de l'état de santé d'une personne, auquel cas ils relèvent de la classe III ; ou — une détérioration grave de l'état de santé d'une personne ou une intervention chirurgicale, auquel cas ils relèvent de la classe IIb. Les logiciels destinés à surveiller des processus physiologiques relèvent de la classe IIa, sauf s'ils sont destinés à surveiller des paramètres physiologiques vitaux, lorsque la nature des variations de ces paramètres est telle qu'elle pourrait entraîner un danger immédiat pour le patient, auquel cas ils relèvent de la classe IIb. Tous les autres logiciels relèvent de la classe I. »

Le document MDCG 2019-11 Rev.1 comprend un tableau illustratif qui met en correspondance les catégories de l'IMDRF et les classes du MDR. À l'exclusion de la classe I, les situations critiques correspondent à la classe III (traiter ou diagnostiquer), IIb (guider) et IIa (éclairer). Les situations graves correspondent aux classes IIb, IIa et IIa, et les situations non graves à la classe IIa pour l'ensemble. En raison de la règle 11, la plupart des SaMD d'aide à la décision dans l'UE nécessitent l'intervention d'un organisme notifié. La proposition de la Commission européenne de décembre 2025 relative à la révision du MDR et de l'IVDR réécrirait la règle 11 autour de la matrice de l'IMDRF. Cette proposition étant toujours en cours d'examen, la règle 11 actuelle s'applique. ¹² Pour le système complet de classification de l'UE, consultez notre guide de classification du MDR de l'UE.

Aux États-Unis, les logiciels sont classés comme tout autre dispositif : par code produit et règlement de classification. La plupart des SaMD relèvent de la classe II. Les logiciels de traitement d'images radiologiques (code produit QIH, 21 CFR 892.2050) et les logiciels radiologiques de tri et de notification assistés par ordinateur (QAS, 21 CFR 892.2080) en sont des exemples typiques. Notre guide de classification FDA explique comment trouver le bon code.

Ce que montrent les données du marché américain

Les logiciels intégrant l'IA constituent le segment à la croissance la plus rapide parmi les autorisations de dispositifs de la FDA, et la quasi-totalité d'entre eux passe par 510(k).

La liste des dispositifs médicaux intégrant l'IA de la FDA comptait 1 614 entrées dans sa mise à jour de septembre 2026, avec des décisions finales arrêtées au 29 juin 2026. 1 553 (96,2 %) étaient des autorisations 510(k), 40 étaient des octrois De Novo et 21 étaient des approbations PMA. La radiologie constituait le principal comité d'évaluation pour 1 230 d'entre eux (76,2 %), suivie par le domaine cardiovasculaire (154) et la neurologie (73). La FDA souligne que cette liste « n'est pas une ressource exhaustive des dispositifs médicaux intégrant l'IA ».

Une seconde mesure provient de l'analyse par Pure Global de l'export openFDA 510(k). Les autorisations relevant de codes produits dont le nom de dispositif selon la FDA inclut « software » sont passées de 7 en 2016 à 187 en 2025, progressant de 0,2 % à 5,8 % de l'ensemble des autorisations 510(k). En 2025, 94 de ces 187 étaient des logiciels automatisés de traitement d'images radiologiques (QIH). ¹³ Cela sous-estime les SaMD, car de nombreux dispositifs logiciels relèvent de codes produits dont le nom ne contient pas « software ». Il s'agit néanmoins d'une ligne de tendance cohérente.

Ce qu'attend la FDA dans une soumission de SaMD

La voie réglementaire est la même que pour le matériel. La documentation est spécifique aux logiciels, et quatre lignes directrices l'encadrent.

1. Niveau de documentation logicielle. La ligne directrice de la FDA de juin 2023 a remplacé l'ancien « niveau de préoccupation » par deux niveaux de documentation. La documentation renforcée s'applique « lorsqu'une défaillance ou un défaut d'une ou plusieurs fonctions logicielles du dispositif pourrait présenter une situation dangereuse avec un risque probable de décès ou de blessure grave ». L'évaluation est effectuée avant l'application des mesures de maîtrise des risques. La documentation de base s'applique dans les autres cas. ¹⁴
2. Cybersécurité. L'article 524B du FD&C Act, entré en vigueur le 29 mars 2023, s'applique aux « cyber-dispositifs » (cyber devices). Il s'agit de dispositifs qui intègrent des logiciels, peuvent se connecter à Internet et pourraient être vulnérables aux menaces de cybersécurité. Les soumissions doivent comprendre un plan de surveillance des vulnérabilités, des processus de mise à jour et de correctifs, ainsi qu'une nomenclature logicielle. ¹⁵ La ligne directrice sur la cybersécurité de la FDA a été révisée pour la dernière fois le 3 février 2026 pour s'aligner sur le QMSR. ¹⁶
3. Plans de contrôle des modifications prédéterminés (PCCP). L'article 515C permet à la FDA d'autoriser à l'avance des modifications futures planifiées, de sorte que les modifications apportées dans le cadre du plan ne requièrent aucune nouvelle soumission. La ligne directrice sur les PCCP de la FDA pour les fonctions logicielles de dispositifs intégrant l'IA a été finalisée le 4 décembre 2024 et révisée le 18 août 2025. Elle couvre les voies 510(k), De Novo et PMA. ¹⁷ Une ligne directrice générale sur les PCCP pour tous les dispositifs est toujours à l'état de projet depuis août 2024. ¹⁸
4. Cycle de vie de l'IA. Le projet de ligne directrice de la FDA du 7 janvier 2025 sur les fonctions logicielles de dispositifs intégrant l'IA définit des recommandations relatives au cycle de vie et aux soumissions préalables à la commercialisation. Celles-ci couvrent la gestion des données, la description du modèle, la validation des performances, les biais, la transparence et la surveillance après commercialisation. Ce document était toujours un projet en octobre 2026. ¹⁹ La FDA a également invité à soumettre des commentaires d'ici le 19 octobre 2026 sur un document de travail consacré à l'IA générative. ²⁰

Dans le cadre du QMSR, la conception et le développement (clause 7.3 de l'ISO 13485) s'appliquent à tous les dispositifs de classe II et III ainsi qu'aux dispositifs de classe I automatisés par logiciel. La validation logicielle relève donc à la fois du système qualité et de la soumission. Consultez notre tableau de correspondance entre le 21 CFR 820 et l'ISO 13485.

Exigences de l'UE au-delà de la règle 11

• Preuve clinique. Le guide MDCG 2020-1 demande trois composantes pour tout MDSW : une association clinique valide (validité scientifique), des performances techniques ou analytiques, et des performances cliniques. Celles-ci suivent le document IMDRF N41. ²¹
• Exigence générale en matière de sécurité et de performances 17. L'annexe I exige que les logiciels soient développés « conformément à l'état de l'art, compte tenu des principes relatifs au cycle de développement, à la gestion des risques, y compris la sécurité de l'information, à la vérification et à la validation ».
• L'AI Act. Le règlement (UE) 2024/1689 traite les systèmes d'IA intégrés à des dispositifs médicaux nécessitant une évaluation de la conformité par un organisme notifié comme présentant un haut risque. L'Omnibus numérique, le règlement (UE) 2026/1744, publié au Journal officiel le 24 juillet 2026, a reporté ces obligations au 2 août 2028. ²² Le document MDCG 2025-6 explique l'interaction entre le MDR et l'AI Act. Il précise que l'AI Act « n'a pas d'incidence sur la classification des risques des dispositifs médicaux ». Sa mention d'une date en août 2027 est antérieure à l'Omnibus. ²³

Comment les autres grands marchés traitent les SaMD

Sources : ²⁴, ²⁵ et ²⁶. Pour l'accès au marché spécifique à l'IA dans plus de 30 pays, consultez notre rapport de recherche sur l'IA en tant que dispositif médical.

Les normes qui sous-tendent un dossier de SaMD

• IEC 62304:2006+A1:2015 définit les processus du cycle de vie du logiciel ainsi que les classes de sécurité logicielle A, B et C. L'édition 2 est encore au stade de projet de comité, et l'IEC prévoit une publication en octobre 2028. Basez-vous sur la version consolidée de 2015. ²⁷
• IEC 82304-1:2016 couvre les produits logiciels de santé fonctionnant sur des plateformes informatiques générales sans matériel dédié, ce qui est caractéristique des SaMD. ²⁸
• IEC 81001-5-1:2021 définit les activités de sécurité tout au long du cycle de vie des logiciels de santé. ²⁹
• La gestion des risques selon l'ISO 14971 et l'ingénierie de l'aptitude à l'utilisation selon l'IEC 62366-1 s'appliquent aux SaMD comme à tout dispositif. Notre guide ISO 14971 traite du dossier de gestion des risques.

SaMD par rapport au SiMD : ce qui change dans votre dossier

Erreurs courantes

• Rédiger la destination en dernier. La classification, les preuves cliniques et le statut de produit de bien-être ou de CDS en découlent tous. Rédigez-la en premier, et veillez à ce que les allégations commerciales restent dans son cadre.
• Supposer qu'« aide à la décision » signifie « non-dispositif ». Aux États-Unis, les quatre critères relatifs aux CDS doivent tous être remplis. Dans l'UE, la règle 11 classe la plupart des logiciels d'aide à la décision en classe IIa ou supérieure.
• Considérer une application mobile comme relevant d'un niveau inférieur. Une application qui répond à la définition de SaMD est un SaMD.
• Citer l'ancien « niveau de préoccupation ». La FDA l'a remplacé par la documentation de base et la documentation renforcée en juin 2023.
• Planifier en fonction de l'échéance de 2027 de l'AI Act. Les obligations relatives au haut risque pour les dispositifs médicaux intégrant l'IA s'appliquent désormais à compter du 2 août 2028.
• Déployer des mises à jour d'algorithmes sans plan. Sans PCCP, une modification importante nécessite généralement une nouvelle soumission.

Comment Pure Global vous aide

Nous déterminons si un logiciel constitue un dispositif et rédigeons la destination. Nous classons le logiciel selon la FDA, la règle 11 de l'EU MDR et d'autres systèmes, et nous préparons les dossiers 510(k) et De Novo avec la documentation de base ou renforcée, la cybersécurité et le contenu lié au PCCP. Notre équipe prend également en charge les soumissions auprès des organismes notifiés de l'UE et les enregistrements sur plus de 30 marchés. Consultez notre page consacrée à la réglementation des SaMD ou contactez notre équipe.

Comment nous avons établi ces chiffres

• Dispositifs intégrant l'IA : notre décompte de la liste des dispositifs médicaux intégrant l'IA de la FDA (CSV), telle que mise à jour en septembre 2026. Les décisions s'étendent jusqu'au 29 juin 2026, et l'année 2026 est une année partielle. La répartition par voie réglementaire provient du préfixe du numéro de soumission (K, DEN ou P).
• Codes produits désignant des logiciels : codes produits du fichier de codes produits de la FDA daté du 12 octobre 2026 dont le nom de dispositif contient « software », mis en correspondance avec l'export openFDA de 510(k) daté du 12 octobre 2026. Pure Global conserve les deux dans son lac de données. Les décomptes sont établis par année civile de la décision.