IA médicale : le projet de la FDA impose un nouveau cap aux startups

L’intelligence artificielle promet de faciliter le dépistage, l’interprétation d’images médicales ou l’aide à la décision clinique. Mais lorsqu’un logiciel peut influencer un diagnostic ou une prise en charge, son développement ne se résume pas à entraîner un modèle performant. Il faut aussi démontrer qu’il est suffisamment sûr, fiable et compréhensible dans les conditions réelles de soins. C’est le message central du projet de guide que la Food and Drug Administration, la FDA américaine, a publié en janvier 2025.

Pour les jeunes entreprises de la santé numérique, le document est important à deux titres. Il ne ferme pas la porte aux outils fondés sur l’apprentissage automatique, bien au contraire. Il précise toutefois le niveau de préparation attendu lorsque ces outils relèvent de la réglementation des dispositifs médicaux. Données d’entraînement, validation, gestion des risques, informations destinées aux utilisateurs et surveillance du produit après sa mise sur le marché font partie d’un même dossier, et non d’étapes séparées.

Un projet de guide, pas encore une règle définitive

Le texte de la FDA porte le titre anglais Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations. Il concerne les fonctions logicielles intégrant de l’IA et utilisées dans des dispositifs médicaux. Son objet est d’aider les fabricants à préparer les éléments qui peuvent être attendus lors d’une demande de commercialisation auprès de l’agence.

Au 14 juillet 2025, il s’agit toujours d’un projet de guide. Cette nuance est essentielle. Aux États-Unis, un projet de guide expose la position envisagée de l’administration et sollicite des commentaires. Il ne crée pas, à lui seul, de nouvelles obligations juridiquement contraignantes. En revanche, il donne une indication très concrète de la manière dont la FDA pourrait examiner les produits à l’avenir, dans le cadre des lois et exigences déjà applicables aux dispositifs médicaux.

La FDA cherche ici à répondre à une difficulté propre à l’IA médicale. Un programme informatique classique produit généralement le même résultat à partir des mêmes règles. Un modèle d’apprentissage automatique, lui, tire ses capacités de données et peut être modifié, réentraîné ou voir ses performances évoluer une fois déployé. Cette évolution est utile, mais elle oblige à surveiller en permanence les risques pour les patients.

Le périmètre doit également être compris avec précision. Toute application utilisant l’IA dans un contexte lié à la santé ne devient pas automatiquement un dispositif médical. La qualification dépend notamment de l’usage prévu par son fabricant. Un outil administratif ou de bien-être n’est pas examiné de la même façon qu’un logiciel destiné à aider à détecter une anomalie sur une image médicale ou à orienter une décision thérapeutique.

Ce que la FDA veut mieux encadrer dans l’IA médicale

L’ambition de la FDA est de maintenir un équilibre délicat : permettre l’arrivée d’innovations utiles sans laisser les patients devenir les testeurs involontaires de systèmes insuffisamment évalués. Pour cela, le projet adopte une logique de cycle de vie complet. La question n’est pas seulement de savoir si un modèle fonctionne dans une démonstration technique, mais s’il continue à fonctionner correctement lorsqu’il est utilisé par des professionnels, avec des données et des patients qui peuvent différer de ceux rencontrés pendant son développement.

Le document insiste notamment sur la gestion des données, le développement et l’évaluation des modèles, la gestion des risques, la transparence des informations fournies et le suivi des performances. Une entreprise doit pouvoir expliquer la place exacte de son logiciel dans le parcours de soin, les utilisateurs auxquels il est destiné, les décisions qu’il peut influencer et les garde-fous prévus lorsqu’il se trompe ou lorsqu’il rencontre une situation inhabituelle.

Les données sont au cœur de cet examen. Un système entraîné sur des informations incomplètes, mal documentées ou trop éloignées des conditions d’utilisation prévues peut afficher de bonnes performances en laboratoire tout en étant moins fiable ailleurs. La FDA attend donc que les fabricants soient en mesure de présenter les données utilisées et la manière dont elles ont servi à développer puis à tester le produit.

Cela ne signifie pas qu’un seul indicateur suffit. Selon la fonction médicale du logiciel, l’évaluation peut inclure des résultats cliniques et des données de performance. Les notions de précision, de sensibilité et de spécificité sont souvent centrales : la sensibilité mesure la capacité à repérer les cas réellement positifs, tandis que la spécificité mesure la capacité à ne pas signaler à tort les cas négatifs. Leur importance dépend de l’usage revendiqué et des conséquences d’une erreur.

La transparence n’implique pas nécessairement de révéler publiquement tout le code ou l’ensemble des secrets industriels. Elle consiste plutôt à fournir à la FDA, aux professionnels et aux utilisateurs les informations nécessaires pour comprendre l’objectif du système, ses performances, ses limites connues et les conditions dans lesquelles il doit être employé.

Pourquoi les jeunes pousses sont-elles directement concernées ?

Pour une startup, les attentes décrites par la FDA changent la façon d’organiser un projet. Une jeune entreprise peut être tentée de consacrer l’essentiel de ses ressources au modèle, à l’interface et à la démonstration de sa capacité technique. Or, dans la santé, la valeur d’un produit dépend aussi de sa capacité à être évalué, utilisé correctement et surveillé au fil du temps.

La documentation ne doit donc pas être considérée comme une formalité ajoutée à la fin du développement. Si les choix relatifs aux données, aux versions du modèle ou aux tests ne sont pas consignés au fur et à mesure, il devient difficile de reconstituer un dossier cohérent. Le même problème se pose pour les changements apportés après les premiers résultats : il faut pouvoir comprendre ce qui a évolué, pourquoi, et quelles conséquences cette évolution peut avoir sur les performances et les risques.

Cette exigence peut peser plus lourdement sur les petites structures, qui disposent d’équipes réglementaires et cliniques moins étoffées que les grands fabricants. Elle peut rallonger certaines phases de préparation et imposer des compétences variées, à la croisée de l’ingénierie, de la médecine, de la qualité et des affaires réglementaires. Les inquiétudes de l’écosystème technologique portent précisément sur le risque qu’un cadre trop complexe ralentisse l’expérimentation et pénalise les entreprises les moins financées.

Mais l’effet peut aussi être inverse. Une startup qui anticipe la qualité des données, les tests et le suivi post-commercialisation peut gagner en crédibilité auprès d’établissements de santé, d’investisseurs et de partenaires industriels. Dans un secteur où une erreur de diagnostic ou de triage peut avoir de graves conséquences, la confiance est une condition de l’adoption, pas un supplément optionnel.

De la performance technique à la preuve clinique

La différence entre une preuve technique et une preuve adaptée à la santé est fondamentale. Un modèle peut obtenir un résultat élevé sur une base de test et pourtant ne pas être prêt pour une utilisation médicale. Les conditions de déploiement sont souvent plus variables : équipements différents, qualité inégale des images ou des dossiers, pratiques cliniques hétérogènes, utilisateurs aux niveaux de formation variés.

Le projet de la FDA invite les fabricants à examiner ces réalités. L’entreprise doit notamment réfléchir à la manière dont les utilisateurs interagiront avec la fonction logicielle. Un résultat fourni par une IA peut être interprété comme une certitude, même lorsque le produit n’est conçu que comme une aide. L’interface, les instructions et les avertissements ont donc une dimension de sécurité. Ils doivent éviter que le logiciel soit utilisé au-delà de ce qu’il a été évalué pour faire.

La surveillance après commercialisation est tout aussi importante. Les performances d’un système peuvent se dégrader si les caractéristiques des données évoluent avec le temps ou si l’environnement clinique change. Ce phénomène est parfois appelé dérive du modèle. Le projet de guide encourage les fabricants à anticiper la collecte et l’analyse d’informations permettant de détecter ce type de problème, ainsi que les mesures à prendre en cas de signal préoccupant.

Cette logique est particulièrement importante pour les modèles susceptibles d’être modifiés. Une mise à jour peut améliorer une fonction, mais elle peut aussi modifier des comportements qui avaient été évalués auparavant. Prévoir la gestion de ces changements dès la conception est moins coûteux et plus sûr que de tenter de les justifier après coup.

Une régulation qui ne signifie pas l’arrêt de l’innovation

Présenter la démarche de la FDA comme une opposition entre régulation et innovation serait réducteur. L’agence américaine a déjà autorisé la commercialisation de dispositifs médicaux utilisant l’IA ou l’apprentissage automatique par différentes voies réglementaires. Le projet de janvier 2025 ne pose donc pas un principe d’interdiction. Il cherche à rendre plus lisibles les informations attendues à mesure que les technologies deviennent plus complexes et plus répandues.

Le véritable enjeu est celui de la proportionnalité. Les preuves demandées doivent correspondre au risque associé à l’usage du produit. Un outil qui intervient dans un contexte clinique sensible appelle logiquement un examen plus approfondi qu’une fonctionnalité dont les conséquences sur le patient sont limitées. La FDA doit aussi tenir compte du rythme de l’innovation : un cadre incapable de s’adapter aux évolutions technologiques risquerait de devenir rapidement obsolète.

Le dialogue entre le régulateur et les entreprises est donc déterminant. Les commentaires sur les projets de guide, les échanges réglementaires et la clarté des documents d’accompagnement peuvent aider les concepteurs à interpréter les attentes sans transformer la conformité en obstacle imprévisible. Pour les startups, demander conseil tôt et construire une stratégie réglementaire au même rythme que la stratégie produit peut éviter de découvrir trop tard qu’une démonstration ne répond pas aux exigences d’un usage médical.

Ce qu’il faut surveiller avant la version finale

Au 14 juillet 2025, les entreprises concernées doivent surtout suivre l’évolution de ce projet et mesurer l’écart entre leurs pratiques actuelles et les recommandations proposées. La version finale, si elle est publiée, pourra préciser ou ajuster certains points à partir des retours reçus. Les termes employés par la FDA compteront : une recommandation générale n’a pas le même effet opérationnel qu’une attente détaillée sur les données, les essais ou le suivi du produit.

Pour les fondateurs, les priorités sont déjà assez nettes. Il faut identifier si le logiciel relève du dispositif médical au regard de son usage prévu, cartographier les données utilisées, documenter les versions du modèle, définir les critères de performance pertinents et prévoir ce qui sera observé après le lancement. Il faut également associer les futurs utilisateurs, car la sécurité dépend autant de l’algorithme que de son intégration dans une pratique de soin.

L’IA médicale ne sera durablement utile que si les soignants et les patients peuvent lui accorder une confiance raisonnable. Le projet de la FDA rappelle une évidence parfois oubliée dans la course aux modèles : dans la santé, innover consiste non seulement à produire une technologie capable, mais aussi à démontrer de façon rigoureuse quand elle doit être utilisée, par qui, avec quelles limites et sous quelle surveillance.