Un logiciel dispositif médical est un programme dont la finalité est médicale et qui produit cet effet par lui-même, sans être intégré à un appareil. Aux États-Unis, il relève de la FDA au même titre qu’un scanner ou une prothèse, et cette qualification surprend encore beaucoup d’éditeurs français.
La question qui compte n’est donc pas de savoir si votre produit est un logiciel. Elle est de savoir si sa finalité déclarée le fait entrer dans la catégorie des dispositifs.
Voyons où passe cette frontière, puis ce qu’elle implique concrètement.
Quand un logiciel dispositif médical relève de la FDA
Toutes les applications de santé ne sont pas réglementées. Le législateur américain a explicitement sorti plusieurs familles du champ.
Sont ainsi exclues les fonctions purement administratives, les outils de bien-être général, les dossiers patients informatisés, ainsi que les logiciels qui se contentent de transférer, stocker ou afficher des données sans les interpréter.
Le cas le plus délicat est celui de l’aide à la décision clinique. Un logiciel qui formule une recommandation à un professionnel de santé peut échapper à la qualification, mais à une condition exigeante : le praticien doit pouvoir examiner de façon indépendante les fondements de la recommandation, afin de ne pas s’y fier aveuglément.
Autrement dit, une boîte noire qui dit quoi faire est un dispositif. Un outil qui montre son raisonnement et laisse le praticien juger a des chances de ne pas l’être.
Attention également à ce critère : dès que votre logiciel analyse une image médicale ou un signal issu d’un appareil de mesure, l’exclusion tombe. Beaucoup de solutions d’imagerie françaises se croient hors champ pour cette raison précise, à tort.
Le rôle décisif de vos propres formulations
Voici le point que je souligne systématiquement en réunion, parce qu’il est sous votre contrôle direct.
La qualification dépend largement de l’usage revendiqué, c’est-à-dire de ce que vous écrivez sur votre site, dans vos brochures et dans vos argumentaires commerciaux.
Écrire que votre outil aide à détecter une pathologie vous place dans le champ. Écrire qu’il organise le flux de travail d’un service ne vous y place pas.
Cette différence n’est pas un jeu de mots. Elle décide de votre calendrier, de votre budget et de votre modèle commercial. J’ai vu une équipe française déclencher une obligation réglementaire entière à cause d’une accroche marketing traduite un peu vite.
Ma recommandation : faites relire toute votre communication américaine sous cet angle avant la mise en ligne, pas après.
Les voies d’autorisation possibles
Si votre logiciel dispositif médical entre bien dans le champ, trois chemins existent, selon le niveau de risque.
La voie de l’équivalence. Vous démontrez que votre produit est substantiellement équivalent à un dispositif déjà autorisé. C’est la voie la plus fréquente, et je l’ai détaillée dans la procédure 510(k) pour un dispositif médical français.
La voie du produit nouveau. Quand aucun équivalent n’existe et que le risque reste modéré, une procédure spécifique permet de créer une nouvelle catégorie. Elle est plus longue, mais elle vous rend référence pour vos futurs concurrents.
L’autorisation préalable complète. Réservée aux dispositifs à haut risque, elle exige des données cliniques substantielles.
Les délais réels observés sur la première voie sont documentés dans mon article sur le parcours 510(k) d’une healthtech française.
La bonne nouvelle pour les éditeurs français
Un changement récent joue franchement en votre faveur, et peu d’équipes françaises l’ont mesuré.
La FDA a remplacé son ancien référentiel qualité par un nouveau texte, entré en application le 2 février 2026, qui s’aligne sur la norme internationale ISO 13485.
Or c’est précisément la norme que vous appliquez déjà si vous portez un marquage européen. Votre système qualité existant devient donc une base largement réutilisable, là où il fallait auparavant maintenir deux dispositifs distincts.
Cet alignement ne supprime pas le travail d’adaptation, car des exigences américaines propres subsistent. Il réduit néanmoins nettement le doublon. Les ressources officielles sont réunies sur le portail santé numérique de la Food and Drug Administration.
Le cas particulier de l’intelligence artificielle
Un modèle qui apprend pose une difficulté évidente au régulateur : le produit autorisé n’est plus tout à fait celui qui fonctionne six mois plus tard.
La FDA a répondu par un mécanisme intéressant, le plan de contrôle des modifications déterminé à l’avance. Vous décrivez dans votre dossier initial les évolutions que vous prévoyez, la méthode de validation et les limites que vous vous fixez.
Si l’autorité l’accepte, vous pouvez ensuite déployer ces évolutions sans redéposer un dossier complet.
Deux limites méritent d’être connues. Les modifications doivent rester dans le cadre de l’usage revendiqué et préserver la sécurité et l’efficacité du produit. Par ailleurs, un apprentissage continu et non supervisé en conditions réelles n’entre pas dans ce cadre : chaque modification suit un protocole prédéfini et se valide avant sa mise à disposition.
Pour une équipe française habituée à livrer en continu, cette contrainte impose de repenser le cycle de développement. Mieux vaut l’intégrer dès la conception.
Ce qui vient après l’autorisation
Obtenir le feu vert ne clôt pas le sujet. Trois obligations continues s’ouvrent.
La cybersécurité. Les dispositifs connectés doivent documenter leur sécurité et fournir un inventaire des composants logiciels utilisés. Cette exigence a pris beaucoup d’importance ces dernières années.
La surveillance après commercialisation. Déclaration des incidents, suivi des réclamations, actions correctives.
La protection des données de santé. Elle relève d’un cadre distinct, que j’ai traité dans conformité HIPAA pour un éditeur SaaS santé français. Une autorisation FDA ne vous en dispense pas.
Ajoutez-y les attentes contractuelles des hôpitaux, qui réclament souvent un rapport d’audit de sécurité en plus du dossier réglementaire. Le sujet est traité dans certification SOC 2 pour un éditeur SaaS français.
Les erreurs que je vois le plus souvent
Transposer le dossier européen tel quel. Les deux systèmes reposent sur des logiques différentes. Le vôtre est réutilisable en partie, pas en totalité.
Repousser la qualification. Tant que vous ignorez si votre logiciel dispositif médical relève ou non de la FDA, vous ne pouvez ni chiffrer ni planifier quoi que ce soit.
Confondre autorisation et remboursement. Ce sont deux mondes séparés, avec des acteurs distincts, comme je l’explique dans medtech française aux USA, FDA, distribution et remboursement.
Négliger le choix du prédicat. Sur la voie de l’équivalence, le dispositif de référence retenu conditionne toute la démonstration.
Par où commencer
Faites établir une analyse de qualification écrite avant toute autre dépense. Elle vous dira si vous êtes dans le champ, et sur quelle voie.
Alignez ensuite votre communication américaine sur cette analyse, sans exception.
Vérifiez enfin l’écart entre votre système qualité actuel et les attentes américaines. Depuis l’alignement sur la norme internationale, cet écart est souvent plus étroit que redouté.
Un logiciel dispositif médical bien qualifié dès le départ entre sur le marché américain avec des mois d’avance sur un concurrent qui a improvisé.
Si vous êtes à ce stade, prenez rendez-vous avec moi et nous regarderons votre positionnement réglementaire et commercial ensemble. Vous pouvez aussi découvrir la méthode que j’ai développée pour séquencer une entrée sur le marché américain.
Les informations présentées dans cet article sont fournies à titre informatif uniquement et ne constituent pas un conseil juridique. La réglementation des dispositifs médicaux évolue régulièrement. Je vous recommande de consulter un professionnel qualifié en affaires réglementaires pour votre situation spécifique.
