Un logiciel en tant que dispositif médical (SaMD) est tout programme qui remplit une fonction médicale de manière autonome, sans faire partie d’une machine physique. Une application qui examine la photo d’un grain de beauté et signale un mélanome possible correspond à cette définition. Le code qui pilote un scanner IRM n’entre pas dans le champ, car il fait partie du matériel.
Cette distinction détermine bien plus de choses sur votre produit que vous ne l’imaginez. Elle façonne les registres que vous tenez, les tests dont vous devez prouver la réalisation et, sur certains marchés, votre droit même de vendre. Beaucoup d’équipes ne se posent pas la question elles-mêmes. Elles l’entendent d’abord d’un investisseur, d’un acheteur hospitalier ou d’un avocat.
Une précision honnête avant d’aller plus loin : cet article ne constitue pas un conseil juridique ou réglementaire. Redwerk prend en charge le développement de logiciels informatiques pour la santé, tandis que la classification de votre produit et le dépôt auprès de la FDA relèvent d’un consultant qualifié. Ce que nous faisons, c’est construire une solution et vous accompagner à chaque contrôle et chaque audit, en travaillant étroitement avec votre équipe pour garantir une conformité totale. Nous renvoyons aux documents officiels tout au long du texte, afin que vous puissiez lire la source plutôt que de vous fier à notre résumé.
Ce qui suit est la moitié technique du tableau. Vous découvrirez ce qui entre dans le champ, comment les catégories de risque sont construites et ce qu’un développement conforme exige réellement des personnes qui écrivent le code.
Ce qui relève du logiciel en tant que dispositif médical
La FDA et l’International Medical Device Regulators Forum, généralement abrégé en IMDRF, définissent le terme comme « un logiciel destiné à être utilisé à une ou plusieurs fins médicales et qui remplit ces fins sans faire partie d’un dispositif médical matériel ».
En le décomposant, on obtient deux questions :
- Le produit poursuit-il une finalité médicale, c’est-à-dire aide-t-il à diagnostiquer, traiter, prévenir ou surveiller une maladie ou un état ?
- Remplit-il cette fonction de manière autonome, plutôt qu’en tant que composant à l’intérieur d’un équipement ?
Deux réponses positives vous placent dans le champ d’application.
Trois familles connues entrent dans cette définition :
- Les outils d’analyse d’imagerie qui mesurent ou interprètent un examen, puis restituent un résultat à un radiologue
- L’aide à la décision clinique qui suggère un diagnostic, une dose ou un protocole de traitement
- Certaines applications de suivi de santé, en particulier celles qui lisent des données de capteurs et alertent l’utilisateur sur un trouble précis
C’est la troisième famille qui surprend. Une mesure de fréquence cardiaque n’est en soi qu’un chiffre. En revanche, dès qu’un produit interprète le schéma et indique à une personne qu’elle présente peut-être un rythme irrégulier, il est passé sur le terrain médical.
Deux types de logiciels de santé restent hors de la définition, et les deux comptent sur le plan commercial. Le premier regroupe tout ce qui est intégré à la fonction principale d’un dispositif. Le micrologiciel embarqué dans une pompe à perfusion relève des règles en tant que partie de ce matériel, et non comme produit à part entière. Le second est la technologie administrative : moteurs de facturation, prise de rendez-vous, planification du personnel et gestion des dossiers touchent tous aux données des patients sans formuler de revendication clinique. Ces outils portent malgré tout des obligations de confidentialité. Ils sont aussi une cible courante pour l’automatisation robotisée des processus dans la santé, que nous traitons séparément.
Quand une application de bien-être devient un dispositif médical
La frontière est plus facile à voir sur un produit qui s’en approche de très près. Redwerk a reconstruit et maintient aujourd’hui Pridefit, une application de fitness sur abonnement destinée à la communauté LGBTQIA+, qui propose des plans de coaching, des défis personnels et le suivi des performances. Elle traite des données de santé tous les jours et modifie le comportement de ses utilisateurs par conception.
Rien de tout cela n’en fait un produit réglementé. Pridefit ne revendique ni diagnostic ni traitement, elle reste donc du côté du bien-être général. Ajoutez à cette même application une seule fonction qui lit les données d’entraînement et alerte l’utilisateur sur un possible problème cardiaque, et la discussion change aussitôt. L’écart entre un outil de bien-être et un produit réglementé peut tenir à une seule phrase de votre argumentaire marketing.
Comment fonctionne la classification SaMD
La classification SaMD ne part pas de votre pile technologique ni de la taille de votre entreprise. Elle part de deux questions sur les conséquences, et les réponses se combinent en une catégorie de risque.
La première porte sur le poids du résultat de votre produit dans une décision clinique :
- Il informe la prise en charge clinique, c’est-à-dire que le clinicien utilise le résultat comme un élément parmi plusieurs
- Il oriente la prise en charge clinique, c’est-à-dire que le résultat détermine l’étape suivante des soins
- Il traite ou diagnostique, c’est-à-dire que le produit délivre lui-même le résultat ou la thérapie
La seconde porte sur le degré de danger dans lequel le patient se trouve déjà :
- Non grave, où une mauvaise réponse a peu de chances de causer un dommage durable
- Grave, où un retard ou une erreur pourrait causer une véritable lésion
- Critique, où un résultat erroné pourrait contribuer au décès ou à un dommage irréversible
Réunissez les deux réponses et vous obtenez l’une des quatre catégories IMDRF, de I pour la plus faible à IV pour la plus élevée. Cette échelle décrit le niveau de risque de votre produit, et rien de plus.
Informe la prise en charge clinique
I
I
II
Oriente la prise en charge clinique
I
II
III
Traite ou diagnostique
II
III
IV
Remarquez comment une même capacité se déplace dans la grille selon le contexte. Un outil qui oriente la prise en charge clinique se situe en I dans une situation bénigne et en III dans une urgence vitale. Votre seule liste de fonctionnalités ne vous dira jamais où vous vous situez.
Classes FDA et catégories IMDRF : ce que chacune détermine
Deux systèmes de classification SaMD distincts utilisent des numéros semblables, et chacun répond à une question différente. Les confondre est l’erreur la plus fréquente des équipes sur ce sujet.
Vous avez déjà vu les catégories IMDRF plus haut. Les exigences de la FDA pour les SaMD suivent une voie distincte, fondée sur trois classes qui traduisent le niveau de surveillance nécessaire :
- La classe I couvre les dispositifs à risque le plus faible, et la plupart n’exigent aucun dépôt avant mise sur le marché.
- La classe II se situe au milieu et demande généralement une notification 510(k) démontrant que votre produit est équivalent à un dispositif déjà autorisé.
- La classe III présente le risque le plus élevé et fait l’objet de l’examen le plus exigeant de l’agence.
Un produit véritablement nouveau, sans équivalent existant, suit sa propre voie, faute de point de comparaison. La classe de votre produit découle de sa destination et du préjudice qu’il pourrait causer, non de la façon dont il a été construit.
Voici comment les deux systèmes se comparent en un coup d’œil :
Ce que c’est
Une manière internationale de décrire le niveau de risque du logiciel
La classification réglementaire américaine d’un dispositif médical
Ce que cela détermine
Aucune portée juridique en soi. Elle donne aux régulateurs et aux développeurs un langage commun pour parler du risque
Ce que vous devez déposer auprès de la FDA avant de vendre aux États-Unis
D’où cela vient
Le groupe de travail IMDRF, présidé par la FDA
La législation américaine sur les dispositifs médicaux
Aucune de ces deux échelles ne se détermine seul. Servez-vous des catégories pour comprendre votre risque, puis laissez un spécialiste réglementaire confirmer la classification américaine. Le Digital Health Policy Navigator de la FDA est un point de départ raisonnable avant cet échange. Les exigences diffèrent aussi selon le marché et évoluent dans le temps, donc vérifiez plutôt que de supposer.
Ce qu’implique le développement d’un logiciel SaMD conforme
Voici ce qui incombe à une équipe d’ingénierie qui développe un logiciel en tant que dispositif médical, et là où un partenaire de développement gagne ou perd sa place. L’essentiel relève des bonnes pratiques de tout projet sérieux, mais le cadre réglementaire les rend obligatoires et vous oblige à les prouver. La FDA attend que l’ensemble du travail se déroule dans un système de management de la qualité : des processus documentés, plus la preuve que vous les avez suivis à chaque fois. Ses recommandations sur l’évaluation clinique expliquent comment démontrer que le produit fait ce que vous annoncez.
Quatre pratiques portent l’essentiel du poids dans le développement logiciel SaMD :
- La traçabilité. Une personne doit pouvoir prendre une ligne de votre cahier des charges et la suivre jusqu’à la décision de conception qui y répond, au code qui l’implémente et au test qui prouve son fonctionnement, puis refaire ce parcours en sens inverse à partir d’un résultat de test. La traçabilité est presque gratuite si vous l’intégrez dès le premier sprint, et terriblement coûteuse à reconstituer ensuite, c’est le problème autour duquel la norme IEC 62304 a été écrite.
- Une documentation rédigée pendant le travail. Les projets réglementés ont besoin tôt d’un cahier des charges clair, car tout ce qui est assemblé à la fin décrit ce que l’équipe aurait aimé construire. Écrire les exigences d’abord fait aussi remonter les désaccords tant qu’ils sont peu coûteux à trancher, c’est la raison même pour laquelle nos services de spécification fonctionnelle existent pour nos clients non réglementés.
- Une trace écrite, pas seulement des tests. Toute équipe sérieuse teste. Le plus dur est de conserver la trace de ce qui s’est passé à chaque fois : quelle version a été vérifiée, qui l’a exécutée, quelle exigence elle couvrait et quel a été le résultat. C’est cette trace qu’un évaluateur demande, et personne ne peut la recréer de mémoire des mois plus tard. La tenir à jour au fil du développement, c’est l’objet de nos services de conseil en assurance qualité, et cela se planifie dès le départ.
- Confidentialité et sécurité, en plus des règles sur les dispositifs. Tout produit qui touche aux informations des patients porte des obligations qui s’ajoutent aux règles sur les dispositifs plutôt qu’elles ne les remplacent. Aux États-Unis, cela signifie généralement HIPAA. Les étapes sont connues : chiffrer les données en transit et au repos, restreindre les accès par rôle, journaliser qui a vu quoi et imposer le même niveau à vos prestataires. Notre checklist de conformité HIPAA pour les logiciels de santé passe chacune de ces étapes en revue. Prévoyez aussi la sécurité comme une obligation continue, avec un moyen de détecter les vulnérabilités et de livrer des correctifs pendant toute la vie du produit, plutôt qu’un seul examen avant le lancement.
Un audit du développement logiciel est le moment où vous apprenez si ces quatre pratiques ont réellement été suivies. Lorsque Redwerk a examiné la base de code de Adoorabelle, une place de marché mobile, l’évaluation a relevé 80 problèmes. Deux d’entre eux comptent le plus pour un travail réglementé : le projet n’avait aucun test développeur et ne conservait aucun journal d’activité. L’absence des deux coûte cher dans un logiciel commercial ordinaire. En revanche, dans un logiciel réglementé, elle peut empêcher le produit d’atteindre les patients. Vous ne pouvez pas montrer pour quelle exigence un morceau de code a été écrit, et vous ne pouvez pas prouver qu’il fonctionne.
Exemples courants de SaMD par catégorie de risque
Les catégories abstraites sont difficiles à retenir, voici donc des exemples de SaMD classés du risque le plus faible au plus élevé. Prenez-les comme des illustrations du schéma général plutôt que comme des décisions sur un produit précis :
- Risque plus faible : les outils qui informent une décision dans une situation non urgente. Une application de référence des symptômes qui aide un patient à décrire une éruption cutanée avant un rendez-vous informe sans rien décider. Sortez complètement du cadre et un tracker de fitness grand public n’est pas réglementé du tout, puisqu’il ne formule aucune revendication clinique.
- Risque modéré : les produits dont le résultat façonne véritablement les soins. On y trouve les logiciels qui examinent la liste des médicaments d’un patient et signalent une interaction dangereuse, orientant ainsi l’étape clinique suivante. Il en va de même pour un outil qui trie les cas entrants et fait remonter les cas urgents dans la file, où leur gravité le place plus haut dans la grille.
- Risque plus élevé : les produits qui diagnostiquent ou traitent directement, en particulier dans des situations critiques. Un logiciel d’imagerie qui repère une suspicion d’accident vasculaire cérébral et alerte l’équipe de garde en est un exemple bien connu. Il en va de même pour toute application qui calcule une dose de radiothérapie, où une erreur entraîne des conséquences irréversibles.
Le schéma reste le même sur les trois niveaux. Le risque augmente quand la réponse du produit remplace le jugement humain au lieu de l’appuyer, et il augmente encore quand le patient a moins de marge pour survivre à une erreur.
Le rôle d’un partenaire de développement, et ses limites
Savoir si votre produit compte comme un logiciel en tant que dispositif médical, dans quelle catégorie il tombe et ce que vous devez déposer sont des questions réglementaires. Ces questions doivent être tranchées par un consultant qualifié. En tant que société de développement, nous ne pouvons pas catégoriser votre produit, et vous devriez vous méfier de tout prestataire qui prétend le contraire.
En revanche, savoir si votre produit peut fournir les preuves qu’un régulateur attend est une question d’ingénierie, et là nous pouvons vous aider. La réponse vient de la lecture du code, des tests et de la documentation que vous avez déjà. Un audit logiciel fait exactement cela, et c’est en général la première étape la moins chère.
La plupart des équipes qui rencontrent des difficultés n’ont pas démarré avec un plan réglementaire. Elles ont livré vite un produit de santé, trouvé des clients, puis entendu la question de la classification de la bouche d’un acheteur. Si cela ressemble à votre entreprise, parlez-nous de votre projet de logiciel de santé et découvrez où en sont réellement votre code et votre documentation.
FAQ
Quelle est la différence entre le SaMD et un logiciel intégré à un dispositif médical ?
Un logiciel en tant que dispositif médical fonctionne de manière autonome. Un logiciel intégré à un dispositif médical est embarqué dans le matériel et le fait fonctionner, comme le micrologiciel d’une pompe à perfusion. Les deux relèvent de la réglementation, mais le second est évalué comme partie de l’équipement auquel il appartient, et non comme un produit à part entière.
Une application de fitness ou de bien-être est-elle un logiciel en tant que dispositif médical ?
En général, non. Suivre des séances, des pas ou le sommeil ne revendique aucun diagnostic ni traitement, les applications de bien-être général restent donc hors des règles. Le facteur décisif est la destination, c’est-à-dire ce que vous dites que votre produit sert à faire. Ajoutez une seule fonction qui signale un possible problème médical et la réponse peut changer.
Faut-il une autorisation de la FDA pour vendre un logiciel de santé ?
Pas toujours. Les outils administratifs comme la facturation et la planification n’en ont pas besoin, et les applications de bien-être général non plus, la plupart du temps. Un logiciel qui diagnostique, traite ou guide une décision clinique en a normalement besoin. Comme la réponse découle de ce que vous affirmez que votre produit fait, tranchez cette question avec un consultant réglementaire bien avant le lancement.
Que se passe-t-il si vous découvrez après le lancement que votre produit est un SaMD ?
C’est fréquent, et cela apparaît le plus souvent quand un investisseur ou un acheteur hospitalier pose la question. Commencez par un consultant réglementaire, qui pourra vous dire où vous en êtes réellement. En parallèle, un audit de votre code, de vos tests et de vos enregistrements montre quelle part des preuves exigées existe déjà et quelle part doit être reconstruite.
Découvrez comment nous avons audité le logiciel Project Science de Complete Network, améliorant la maintenabilité du code de 80 %
