Propres apps d'IA et le piège du dispositif médical (article 5(5) du MDR)

Quand une app développée en interne devient-elle un dispositif médical ?

Lorsqu’elle a une finalité médicale. Selon l’article 2, point 1, du MDR, un logiciel est aussi un dispositif médical s’il sert notamment au diagnostic, à la prévention, au contrôle, à la prédiction, au pronostic ou au traitement d’une maladie. Le guide MDCG 2019-11 précise : le logiciel doit traiter des données au-delà du stockage, de l’archivage, de la communication et de la recherche simple, et ce au bénéfice de patients individuels. Qu’une erreur soit dangereuse ou non ne joue aucun rôle dans la qualification ; c’est la finalité qui compte.

Sur une plateforme d’IA, une app se compose d’une instruction, de documents et de connexions à des systèmes. La finalité réside donc surtout dans l’instruction et dans l’usage pour lequel l’établissement partage l’app :

App	Finalité	Qualification (en règle générale)
Rédiger une lettre de sortie à partir de notes	formuler un texte, le médecin vérifie	pas un dispositif médical
Rechercher dans une recommandation de bonne pratique et citer la source	information générale, sans lien avec un patient	pas un dispositif médical
Résumer les résultats d’examens d’une patiente	documentation, sans évaluation	en règle générale pas un dispositif médical
Proposer des diagnostics différentiels à partir des résultats	aide à la décision pour une patiente	dispositif médical, au moins classe IIa selon la règle 11
Adapter une dose à la fonction rénale	décision thérapeutique pour un patient	dispositif médical

La frontière ne passe pas entre la plateforme et l’app, mais entre les apps. Un établissement peut avoir les deux sur la même plateforme.

Qui est alors le fabricant ?

L’établissement qui développe et utilise l’app à finalité médicale. Le fournisseur de la plateforme ne devient pas fabricant pour autant, de même qu’un serveur ne devient pas un dispositif médical parce qu’un logiciel de diagnostic y tourne. Pour l’établissement, cela signifie : soit il suit le parcours complet d’un fabricant, avec évaluation de la conformité et marquage CE (Marquage CE de l’IA d’aide au diagnostic), soit il recourt à l’exemption des établissements de santé.

Qu’exige l’article 5(5) du MDR ?

Pour les dispositifs fabriqués et utilisés exclusivement au sein d’un établissement de santé dans l’UE, seules les exigences générales en matière de sécurité et de performances de l’annexe I s’appliquent, pas le reste du MDR. En contrepartie, toutes les conditions doivent être remplies :

• Aucun transfert : pas à une autre entité juridiquement distincte (point a).
• Gestion de la qualité : fabrication et utilisation dans le cadre d’un système approprié (b).
• Justification : documenter pourquoi aucun produit équivalent sur le marché ne répond aux besoins du groupe de patients avec le niveau de performance requis (c).
• Information : informations pour l’autorité sur demande (d).
• Déclaration publique : nom et adresse de l’établissement, indications sur le dispositif et déclaration relative à l’annexe I ; exigences non remplies avec justification (e). Le MDCG 2023-1 contient un modèle à cet effet.
• Documentation : conception, fabrication et données de performance, y compris la finalité (f), fabrication conforme à cette documentation (g).
• Exploiter l’expérience : examiner l’expérience clinique et prendre des mesures correctives (h).

L’exemption ne s’applique pas à une fabrication à l’échelle industrielle. Les États membres peuvent restreindre et surveiller la fabrication en interne.

Où s’arrête l’exemption ?

Le guide MDCG 2023-1 cite des limites que les apps d’IA atteignent vite :

• Groupe hospitalier : si les établissements appartiennent à des sociétés différentes, chacun est une entité juridique distincte. Une app pour tous les établissements ne relève alors pas de l’exemption.
• Apps pour patients : les applications que les patients utilisent en dehors de l’établissement sont exclues.
• Produit équivalent sur le marché : s’il existe un produit marqué CE offrant le même niveau de performance, la justification tombe. L’établissement doit donc surveiller le marché en continu.
• Raisons uniquement économiques : une fabrication en interne qui vise seulement à économiser de l’argent, sans raison clinique, n’est pas couverte par l’exemption.
• Finalité modifiée : si un établissement donne une nouvelle finalité à un produit marqué CE, l’article 5(5) s’applique également à cette finalité.

Qu’ajoutent l’AI Act et la responsabilité du fait des produits ?

• AI Act : un dispositif médical qui nécessite l’intervention d’un organisme notifié est, en tant que système d’IA, un système à haut risque (article 6(1) avec l’annexe I). Après la modification par le règlement (UE) 2026/1744, les obligations correspondantes s’appliquent à partir du 2 août 2028. L’article 6(1) repose sur le fait que le produit doit faire l’objet d’une évaluation de la conformité par un tiers ; en cas de fabrication en interne selon l’article 5(5) du MDR, celle-ci n’a pas lieu. La question de savoir si les fabrications en interne échappent ainsi à la qualification à haut risque n’est pas tranchée. Prévoyez par précaution les exigences relatives aux données, à la journalisation et au contrôle humain.
• Responsabilité du fait des produits : la nouvelle directive (UE) 2024/2853 couvre les logiciels et s’applique aux produits mis sur le marché ou mis en service après le 9 décembre 2026. Est aussi considéré comme fabricant celui qui développe un produit pour son propre usage.

Comment un établissement garde-t-il le contrôle de ses apps ?

• Fixer la finalité : pour chaque app partagée, noter brièvement à quoi elle sert et à quoi elle ne sert pas.
• Piloter le partage : ne partager les apps liées aux patients avec des groupes qu’après vérification par le correspondant matériovigilance ou la gestion de la qualité.
• Vérifier les instructions : des formulations comme « propose le traitement » ou « évalue le risque » signalent une finalité médicale.
• Résultat sous forme de projet : le professionnel vérifie à la source et décide.

Comment cela fonctionne-t-il avec basebox ?

basebox n’est pas un dispositif médical, mais une plateforme pour des tâches générales comme la rédaction de courriers ou la recherche dans des recommandations de bonne pratique. Vous construisez des apps à partir d’une instruction, de documents et de connexions ; la personne qui construit une app la partage avec des groupes ou des personnes, pour l’utiliser ou la modifier. Vos collaborateurs ne peuvent utiliser que ce que votre administrateur a activé. Chaque réponse indique ses sources avec le passage cité, le modèle et sa version sont documentés, et le journal d’audit enregistre qui a utilisé quelle app.

Si votre établissement développe lui-même avec basebox une application à finalité médicale, votre établissement en est le fabricant. Pour votre documentation technique, basebox fournit les informations d’un fournisseur : registre des modèles avec version et licence, nomenclature logicielle (SBOM) et certificat ISO 27001. Les bases sur la plateforme : L’IA est-elle un dispositif médical ?

Pas un conseil juridique : c’est la finalité de l’app, au cas par cas, qui décide si elle est un dispositif médical. Les guides MDCG ne sont pas contraignants. Les échéances de l’AI Act ont été modifiées en 2026 et peuvent changer à nouveau ; la transposition allemande de la directive sur la responsabilité du fait des produits n’était pas encore promulguée au 11 octobre 2026. État de la recherche : 11 octobre 2026.