Du POC au dispositif médical : faire vivre un modèle d'IA sans casser son marquage CE

Le POC marche. Les métriques sont bonnes, le comité scientifique est convaincu, un service pilote veut l'essayer. C'est précisément le moment où la plupart des projets d'IA en santé s'arrêtent, et rarement pour des raisons techniques.

La cause profonde tient en une phrase : le règlement sur les dispositifs médicaux est conçu pour un produit qui ne change pas, et un modèle d'IA change. Il se réentraîne, il dérive, il s'améliore. Un cadre pensé pour des objets stables rencontre un objet qui ne l'est pas.

Ce guide traite ce point de friction, parce que c'est celui qui décide si votre POC devient un produit. Il suppose que la qualification est faite ; sinon, commencez par notre arbre de décision en 5 questions.

Les quatre morts d'un POC d'IA en santé

Avant le sujet réglementaire, un constat de terrain. Quand un POC ne passe pas en production, c'est presque toujours pour l'une de ces quatre raisons, et aucune n'est un problème de modèle.

Le jeu de données n'est pas reproductible. L'entraînement a été fait sur un export figé, dans un notebook, sans versionnement. Personne ne sait reconstituer exactement ce qui a produit ces poids. Le modèle existe, il n'est pas documentable, donc pas certifiable.

Il n'y avait pas de protocole d'évaluation. Les métriques ont été calculées après coup, sur un découpage décidé en même temps que le résultat. Un organisme notifié ne saura pas quoi en faire, et un clinicien non plus.

L'intégration n'a pas été pensée. Le POC tourne sur un export de données, pas dans le flux réel. Entre les deux, il y a le PACS, le dossier patient, l'authentification, les droits, les performances. C'est systématiquement la moitié du travail restant.

La qualification arrive trop tard. L'équipe découvre au bout d'un an qu'elle construit un dispositif de classe IIb. Les choix d'architecture faits entretemps sont à reprendre.

Les trois premières se préviennent avec de la discipline d'ingénierie. La quatrième se prévient en posant la question au début. La suite de cet article traite ce qui reste une fois ces quatre pièges évités : faire vivre le produit.

Le protocole d'évaluation se définit avant l'entraînement

C'est la première règle, et elle est contre-intuitive pour une équipe habituée à itérer.

Sur un produit logiciel classique, on essaie, on mesure, on ajuste. Sur un dispositif médical, les performances que vous déclarez deviennent une revendication réglementaire. Elles figureront dans la notice, elles engagent, et elles seront vérifiées.

Ce qui se fixe avant de lancer le premier entraînement :

• Les métriques, et lesquelles priment. Sensibilité et spécificité ne s'optimisent pas ensemble ; le compromis est un choix clinique, pas un choix technique.
• La population de validation, décrite précisément : âge, pathologies, appareils, centres, période. C'est ce qui permettra de dire sur quelle population le modèle est validé, et surtout sur laquelle il ne l'est pas.
• Le niveau de validation visé. Validation interne sur des données mises de côté, validation externe sur des données indépendantes provenant d'autres centres, ou validation en conditions réelles. Les trois n'ont pas la même valeur probante, et le projet de guide HAS/CNIL soumis à consultation au printemps 2026 demande que cette distinction figure au contrat avec l'établissement acheteur.
• Le jeu de test scellé, qui n'est jamais utilisé pour ajuster quoi que ce soit. S'il a servi à choisir un hyperparamètre, ce n'est plus un jeu de test.

Cette discipline coûte quelques jours au début du projet. Elle évite de devoir tout réentraîner proprement dix-huit mois plus tard.

Le mécanisme qui rend un modèle évolutif compatible avec la certification

Voici le point central, et il est méconnu parce qu'il est récent.

L'article 43, paragraphe 4, de l'AI Act prévoit explicitement le cas des systèmes qui continuent d'apprendre après leur mise sur le marché. Sa formulation est la clé de tout :

Les modifications apportées au système d'IA à haut risque et à sa performance qui ont été déterminées au préalable par le fournisseur au moment de l'évaluation initiale de la conformité et font partie des informations contenues dans la documentation technique visée à l'annexe IV, point 2), f), ne constituent pas une modification substantielle.

Autrement dit : si vous avez décrit à l'avance comment votre modèle évoluera, et que vous l'avez inscrit dans votre documentation technique, ces évolutions ne déclenchent pas une nouvelle évaluation de la conformité.

À l'inverse, une modification substantielle est définie comme un changement non prévu ni planifié lors de l'évaluation initiale, qui nuit à la conformité aux exigences du chapitre III section 2, ou qui modifie la destination pour laquelle le système a été évalué.

La conséquence stratégique est directe : l'enveloppe d'évolution que vous décrivez au départ détermine votre liberté de manœuvre pour les années suivantes. Une enveloppe trop étroite vous oblige à repasser une évaluation à chaque amélioration. Une enveloppe trop large ne passera pas l'évaluation initiale. C'est un exercice d'anticipation produit, et il se fait avec l'équipe technique, pas seulement avec le consultant réglementaire.

Ce qu'on met dans cette enveloppe

En pratique, la description des changements prédéterminés couvre :

Le périmètre du réentraînement. Sur quelles données, de quelle nature, provenant de quels types de sources. Réentraîner sur des données de même nature que celles de la validation initiale est une chose ; élargir à une autre population en est une autre.

Les bornes de performance. Les seuils en dessous desquels une nouvelle version n'est pas déployable, métrique par métrique. Ces bornes sont ce qui rend l'enveloppe acceptable pour un évaluateur : elles garantissent que l'évolution ne dégrade pas le produit.

La procédure de validation d'une nouvelle version. Quels tests, sur quel jeu, avec quelle décision et par qui. Cette procédure doit être exécutable par votre équipe sans arbitrage au cas par cas.

Les critères de retour arrière. Dans quelles conditions on revient à la version précédente, et en combien de temps. Un modèle sans retour arrière testé n'est pas un modèle déployable.

Ce qui sort explicitement de l'enveloppe. Un changement d'architecture, une nouvelle indication, une extension à une population non validée, un changement de type de données d'entrée. Le dire clairement protège autant que le reste.

Côté MDR, les deux régimes se superposent

L'AI Act ne remplace pas le MDR sur ce sujet, il s'y ajoute.

L'annexe IX, section 2.4, du MDR impose au fabricant d'informer l'organisme notifié de tout projet de modification substantielle du système de gestion de la qualité ou de la gamme de dispositifs couverts, et d'obtenir son approbation préalable avant de mettre en œuvre des modifications susceptibles de compromettre la sécurité, les performances, ou les conditions prescrites d'utilisation du dispositif.

Une modification est substantielle au sens du MDR quand elle affecte, ou est susceptible d'affecter, la sécurité, l'efficacité ou les performances du dispositif certifié, ou sa conformité aux exigences. Les guidances du MDCG précisent que les changements logiciels entrent pleinement dans cette évaluation.

Ce que ça donne concrètement : votre plan de changements prédéterminés doit être construit pour satisfaire les deux lectures. L'exercice est le même, et c'est cohérent avec le fait que, pour un dispositif médical à base d'IA, les exigences de l'AI Act font partie de l'évaluation de la conformité menée au titre du MDR. Détail de cette articulation dans notre guide sur l'AI Act en santé.

IEC 62304 quand le comportement est appris

La norme de cycle de vie du logiciel médical a été écrite pour du code déterministe. Nous en détaillons les classes de sécurité et les exigences dans notre guide sur la certification dispositif médical logiciel. Trois adaptations s'imposent quand une partie du comportement vient d'un apprentissage.

La traçabilité exigence vers implémentation vers test. Sur du code, elle est directe : cette exigence est satisfaite par cette fonction, vérifiée par ce test. Sur un modèle, l'implémentation n'est pas lisible. La chaîne de traçabilité devient : cette exigence est satisfaite par ce modèle dans cette version, entraîné sur ce dataset dans cette version, vérifiée par ce protocole d'évaluation avec ce résultat. Le dataset et le protocole entrent dans la traçabilité au même titre que le code.

La vérification devient statistique. Un test unitaire passe ou échoue. Une évaluation de modèle produit une métrique à comparer à un seuil, avec un intervalle de confiance. Vos critères d'acceptation doivent être écrits en conséquence, et la taille du jeu de test devient un sujet de conception, pas un détail.

Les modèles tiers relèvent de la logique du logiciel d'origine inconnue. Un modèle à poids ouverts que vous n'avez pas entraîné pose les mêmes questions qu'une bibliothèque externe intégrée à un dispositif : que savez-vous de sa provenance, de ses données d'entraînement, de son comportement en limite, et comment gérez-vous ses versions et ses vulnérabilités ? La documentation de cette dépendance fait partie du dossier, et le fait que le fournisseur ne la publie pas est votre problème, pas le sien.

La dérive, et ce qu'on en fait

Un modèle qui n'a pas changé peut quand même se dégrader, parce que le monde autour a changé. C'est la dérive, et c'est le sujet de surveillance après mise sur le marché propre à l'IA.

Deux formes à distinguer, parce qu'elles ne se détectent pas pareil.

La dérive des entrées. La population, le protocole ou l'appareil ont changé. Un nouveau scanner, un service qui adresse d'autres patients, une saison. Elle se détecte sans connaître la vérité terrain, en comparant la distribution des entrées en production à celle de l'entraînement.

La dérive des performances. La relation entre les entrées et la sortie attendue a changé. Elle ne se détecte qu'avec un retour de vérité terrain, ce qui en santé signifie un délai, parfois long. C'est pour ça qu'on surveille les deux : la première est un signal précoce de la seconde.

Ce qu'il faut instrumenter :

• une mesure continue de la distribution des entrées, avec des seuils d'alerte définis à l'avance ;
• un recueil de vérité terrain, même partiel, même différé, organisé plutôt que subi ;
• le taux de désaccord entre la sortie du modèle et la décision finale du professionnel, qui est souvent le meilleur indicateur disponible en temps réel ;
• des performances suivies par sous-population, parce qu'une dégradation localisée se noie dans une moyenne globale.

Et une procédure écrite pour quand l'alerte se déclenche : qui est prévenu, sous quel délai, quelles sont les options (réentraînement dans l'enveloppe, restriction temporaire de la destination, retour arrière, information des utilisateurs), et à partir de quand cela devient un signalement de matériovigilance.

L'instrumentation minimale en production

Résumé de ce que nous mettons systématiquement en place sur ce type de produit.

Versionnement conjoint du modèle, du dataset et du prompt. Chaque sortie produite en production est rattachable au triplet exact qui l'a produite. Sans ça, aucune investigation n'est possible.

Journalisation des événements sans données de santé en clair. L'exigence de traçabilité de l'article 12 de l'AI Act rencontre l'exigence de protection des données. Les deux se concilient, mais cela se conçoit, comme détaillé dans notre article sur l'architecture technique d'une application e-santé.

Traçabilité de la décision humaine. Ce que le modèle a proposé, ce que le professionnel a retenu, et l'écart. C'est à la fois l'exigence de contrôle humain, la mesure de la valeur réelle du produit, et la matière première de vos améliorations.

Déploiement progressif et retour arrière testé. Une nouvelle version de modèle se déploie sur un périmètre restreint avant d'être généralisée, et le retour arrière est vérifié régulièrement, pas supposé.

Tableau de bord des performances réelles. Celles que vous revendiquez dans la notice, mesurées en production, par sous-population. Si vous ne pouvez pas les afficher, vous ne pouvez pas les défendre.

Un calendrier réaliste

Pour un dispositif médical à base d'IA de classe IIa ou IIb, en partant d'un POC qui fonctionne :

• Qualification et cadrage réglementaire : quelques semaines, et c'est la dépense la plus rentable du projet.
• Mise sous contrôle du dataset et protocole d'évaluation : plusieurs mois, souvent le poste le plus long, et celui qu'on ne peut pas rattraper plus tard.
• Industrialisation et intégration au système d'information cible : plusieurs mois, en parallèle.
• Validation selon le niveau visé, de la validation interne à l'étude en conditions réelles : de quelques mois à beaucoup plus.
• Évaluation par l'organisme notifié : le délai qui échappe à votre contrôle, et celui que les équipes sous-estiment le plus.

Un point de calendrier à ne pas manquer : les organismes notifiés au titre du MDR qui entendent évaluer des systèmes d'IA à haut risque doivent introduire leur demande de désignation au plus tard le 28 janvier 2028, et les exigences de l'AI Act s'appliquent aux dispositifs médicaux à partir du 2 août 2028. Interrogez le vôtre maintenant : changer d'organisme notifié en cours d'évaluation coûte plus cher que n'importe quelle décision technique de ce guide.

FAQ

Peut-on mettre à jour un modèle d'IA déjà marqué CE ?

Oui, si la mise à jour entre dans les modifications que vous avez décrites à l'avance dans votre documentation technique. L'article 43, paragraphe 4, de l'AI Act prévoit que les changements prédéterminés au moment de l'évaluation initiale ne constituent pas une modification substantielle. Hors de cette enveloppe, une nouvelle évaluation est nécessaire, et côté MDR l'annexe IX impose d'informer l'organisme notifié et d'obtenir son approbation préalable.

Qu'est-ce qu'une modification substantielle ?

Au sens de l'AI Act, une modification apportée après la mise sur le marché qui n'était pas prévue ni planifiée lors de l'évaluation initiale, et qui nuit à la conformité aux exigences applicables ou change la destination du système. Au sens du MDR, une modification qui affecte ou est susceptible d'affecter la sécurité, l'efficacité ou les performances du dispositif certifié.

Un modèle en apprentissage continu est-il interdit en dispositif médical ?

Non. L'AI Act l'envisage explicitement. Ce qui est exclu, c'est un modèle qui évolue sans cadre décrit : l'apprentissage continu est possible à condition que son périmètre, ses bornes de performance et sa procédure de validation aient été définis et documentés dès l'évaluation initiale.

Comment détecter qu'un modèle se dégrade en production ?

En surveillant deux choses distinctes : la distribution des données d'entrée comparée à celle de l'entraînement, qui se mesure sans vérité terrain et sert de signal précoce, et les performances réelles, qui demandent un retour de vérité terrain souvent différé. Le taux de désaccord entre la proposition du modèle et la décision du professionnel est le meilleur indicateur disponible en temps réel.

Un modèle à poids ouverts que je n'ai pas entraîné pose-t-il problème ?

Pas en soi, mais il se traite comme une dépendance externe intégrée à un dispositif médical : provenance, données d'entraînement connues ou non, comportement en limite, gestion des versions et des vulnérabilités. Cette documentation fait partie de votre dossier technique, et c'est à vous de la produire même si le fournisseur du modèle ne la publie pas.

Faut-il un organisme notifié pour chaque nouvelle version ?

Non, si les versions restent dans l'enveloppe de changements prédéterminés que vous avez fait évaluer. C'est précisément l'intérêt de bien dimensionner cette enveloppe au départ : elle détermine combien de fois vous devrez repasser devant votre organisme notifié dans les années qui suivent.

Ce que nous faisons chez Bob le développeur

Nous développons des logiciels de santé sous contraintes HDS et RGPD depuis 2017, pour des éditeurs et des établissements dont l'AP-HP. Sur un produit d'IA destiné à devenir un dispositif médical, nous intervenons sur ce qui se code : le pipeline de données versionné, la traçabilité qui relie exigence, dataset, modèle et protocole d'évaluation, l'instrumentation de la dérive, le déploiement progressif et le retour arrière.

Nous ne remplaçons pas votre consultant en affaires réglementaires, et nous vous recommanderons d'en avoir un tôt. Notre travail est de faire en sorte que l'architecture rende ses exigences démontrables, plutôt que de les rattraper à coups de documentation en fin de projet.

Notre page développement d'IA en santé détaille notre approche, et vous pouvez nous décrire votre projet pour un premier ordre de grandeur.