Mon IA médicale est-elle un système à haut risque ? L'arbre de décision en 5 questions

« Est-ce que mon IA est concernée par l'AI Act ? » est la première question que nous entendons, et c'est la bonne : tout le reste en découle, du budget au calendrier en passant par le choix de l'organisme notifié.

Elle se tranche en cinq questions, dans cet ordre. Chacune a une base juridique précise et une conséquence concrète. Prenez dix minutes, répondez honnêtement, et vous saurez où vous en êtes.

Un avertissement avant de commencer : cet arbre qualifie, il ne remplace pas l'avis d'un spécialiste des affaires réglementaires sur votre dossier. Il sert à savoir de quoi vous parlez quand vous irez le voir.

Question 1 : votre logiciel a-t-il une destination médicale ?

C'est la question qui décide de tout, et elle porte sur votre destination revendiquée, pas sur votre technologie.

Un logiciel est un dispositif médical s'il est destiné par son fabricant à une finalité médicale : diagnostic, prévention, contrôle, prédiction, pronostic, traitement ou atténuation d'une maladie. Ce que vous écrivez sur votre site, dans votre notice et dans vos supports commerciaux construit cette destination.

Si non : vous n'êtes pas dans le champ de l'annexe I de l'AI Act. Vous restez soumis au RGPD, à l'hébergement des données de santé et, si vous générez des contenus de synthèse, aux obligations de transparence de l'article 50 de l'AI Act. Passez directement à la question 5.

Si oui : continuez.

Le piège : beaucoup d'équipes croient échapper à la qualification en écrivant « à titre informatif, ne constitue pas un avis médical » quelque part. Si le produit est construit, vendu et utilisé pour éclairer une décision clinique, la mention ne protège pas. À l'inverse, restreindre réellement la destination est une décision produit légitime, mais elle a un coût fonctionnel qu'il faut assumer.

Question 2 : quelle est votre classe MDR ?

La règle 11 de l'annexe VIII du règlement (UE) 2017/745 est spécifique aux logiciels. En résumé : un logiciel destiné à fournir des informations utilisées pour des décisions diagnostiques ou thérapeutiques est au minimum de classe IIa, et monte en IIb ou III selon la gravité des conséquences possibles. Le simple stockage, archivage ou affichage reste en classe I.

Nous détaillons la règle, les guidances du MDCG et le processus de marquage CE dans notre guide sur la certification dispositif médical logiciel (MDR/SaMD). Cet arbre suppose que vous avez fait cet exercice.

Retenez juste ceci pour la suite : en pratique, la grande majorité des logiciels à finalité médicale tombent en classe IIa ou IIb.

Question 3 : votre classe impose-t-elle un organisme notifié ?

C'est le test décisif de l'AI Act, et il surprend souvent.

L'article 6, paragraphe 1, de l'AI Act pose deux conditions cumulatives pour qu'un système d'IA soit à haut risque au titre de l'annexe I :

1. le système est un composant de sécurité d'un produit couvert par l'annexe I, ou constitue lui-même un tel produit ;
2. ce produit est soumis à une évaluation de la conformité par un tiers.

Le MDR figure au point 11 de la section A de l'annexe I de l'AI Act, et le règlement (UE) 2017/746 sur le diagnostic in vitro au point 12.

Votre situation	Organisme notifié	Haut risque au titre de l'annexe I
Dispositif médical classe I	Non, auto-certification	Non
Dispositif médical classe IIa, IIb, III	Oui	Oui
Diagnostic in vitro classe A	Non en général	Non
Diagnostic in vitro classe B, C, D	Oui	Oui

Si vous êtes en classe I : votre IA n'est pas à haut risque à ce titre. Et l'article 43, paragraphe 3, tel que modifié par le règlement omnibus du 8 juillet 2026, ajoute une garantie explicite : un fabricant n'est pas tenu de choisir une procédure impliquant un tiers uniquement parce que son produit intègre un système d'IA à haut risque comme composant de sécurité, si le MDR ne l'exige pas. Ajouter de l'IA ne vous fait pas changer de procédure.

Si vous êtes en classe IIa ou plus : vous êtes à haut risque, sous réserve de la question 4. Vos obligations de fond s'appliquent à partir du 2 août 2028, calendrier détaillé dans notre article sur l'AI Act en santé.

Question 4 : votre module d'IA est-il vraiment un composant de sécurité ?

Un dispositif de classe IIa n'est pas intégralement de l'IA. Si votre modèle ne touche pas la fonction clinique, la première condition de l'article 6, paragraphe 1, peut ne pas être remplie. Le règlement omnibus a inséré trois paragraphes pour le préciser.

Article 6, paragraphe 1 bis : ne sont pas des composants de sécurité les systèmes d'IA utilisés uniquement pour des aspects non liés à la sécurité. Le texte cite l'assistance aux utilisateurs, l'optimisation des performances, l'efficacité des services, l'automatisation, la commodité et le contrôle de la qualité.

Article 6, paragraphe 1 ter : par exception, les systèmes dont la défaillance ou le dysfonctionnement mettrait en danger la santé et la sécurité sont des composants de sécurité, quoi qu'en dise le paragraphe précédent.

Article 6, paragraphe 1 quater : un produit soumis à évaluation par un tiers uniquement pour des risques autres que sanitaires et sécuritaires (le texte cite la distribution du spectre radioélectrique et les interférences électromagnétiques) ne remplit pas la seconde condition.

En pratique, la ligne se trace comme ceci :

Probablement hors composant de sécurité

• pré-remplissage d'un compte rendu à partir de la dictée, relu et validé par le praticien
• résumé d'un dossier long, avec accès à la source
• recherche sémantique dans une documentation ou un référentiel
• aide à la planification, optimisation de tournées, gestion de files d'attente
• détection de doublons administratifs, contrôle de complétude d'un formulaire

Probablement composant de sécurité

• signalement d'une anomalie sur une image ou un signal
• proposition ou vérification de posologie
• score de risque affiché au praticien pour orienter une décision
• déclenchement d'une alerte clinique, y compris différée
• tri ou priorisation de patients sur un critère clinique

La zone grise existe, et elle se traite par écrit. La qualification s'appuie sur votre analyse de risques : que se passe-t-il si le modèle se trompe, qui voit la sortie, et est-ce que quelqu'un peut la corriger avant qu'elle produise un effet ? Un résumé faux qu'un médecin relit n'a pas les mêmes conséquences qu'un score faux qui déclenche une alerte.

Conséquence produit, souvent plus intéressante que la conclusion juridique : isoler le module d'IA du reste du logiciel change la surface d'évaluation. C'est une décision d'architecture à prendre tôt, et c'est le même raisonnement que celui qui consiste à séparer le dispositif médical du reste de la plateforme.

Question 5 : relevez-vous aussi de l'annexe III ?

Dernière vérification, souvent oubliée. L'annexe III de l'AI Act liste des cas d'usage à haut risque indépendamment de tout produit réglementé, par exemple en matière d'emploi, d'accès aux services essentiels ou de biométrie. Un logiciel de santé peut y toucher par une fonction périphérique.

Le règlement omnibus a tranché le cumul. L'article 43, paragraphe 3, dernier alinéa, pose que lorsqu'un système à haut risque relève à la fois de l'annexe I section A et d'une catégorie de l'annexe III, le fournisseur suit la procédure d'évaluation de la conformité requise par la législation de l'annexe I section A. Pour vous : la procédure MDR, une seule fois.

Attention en revanche aux dates, qui restent distinctes : 2 décembre 2027 pour les systèmes à haut risque au titre de l'annexe III, 2 août 2028 au titre de l'annexe I. Si vous n'êtes pas un dispositif médical mais que vous relevez de l'annexe III, votre échéance est la première.

Et si vous générez des contenus de synthèse, l'article 50 sur la transparence s'applique depuis le 2 août 2026, avec un butoir au 2 décembre 2026 pour les systèmes déjà sur le marché au titre du nouvel article 111, paragraphe 4.

Le récapitulatif

Réponse	Ce que ça veut dire	Votre échéance
Pas de destination médicale, pas de cas d'usage annexe III	Hors haut risque. RGPD, HDS et transparence restent dus	Article 50 déjà applicable
Dispositif médical classe I	Hors haut risque au titre de l'annexe I. L'IA ne change pas votre procédure	Article 50 déjà applicable
Classe IIa et plus, IA hors fonction clinique	Qualification à documenter, article 6 paragraphes 1 bis et 1 ter	À trancher avant tout développement
Classe IIa et plus, IA en composant de sécurité	Haut risque, exigences des articles 8 à 15, dans la procédure MDR	2 août 2028
Cas d'usage annexe III sans produit réglementé	Haut risque au titre de l'annexe III	2 décembre 2027
Client autorité publique	Délai spécifique de l'article 111, paragraphe 2	2 août 2030

FAQ

Une IA qui rédige des comptes rendus médicaux est-elle un dispositif médical ?

Cela dépend de sa destination. Un outil qui transcrit et met en forme ce que le praticien a dit, pour qu'il le relise et le valide, n'a pas de finalité diagnostique ou thérapeutique propre. S'il commence à proposer un diagnostic, à coder un acte à portée clinique ou à suggérer une conduite à tenir, la qualification change. La frontière se documente dans la notice et dans l'analyse de risques.

Un chatbot de pré-triage est-il un système à haut risque ?

S'il oriente un patient sur un critère clinique, il fournit une information utilisée pour une décision et tombe probablement dans le champ du dispositif médical, avec une classe qui dépend de la gravité des conséquences d'une erreur. La réponse dépend du niveau de décision réellement délégué au modèle.

Mon modèle est un LLM du marché que je n'ai pas entraîné. Suis-je quand même fournisseur ?

Si vous mettez sur le marché un système d'IA sous votre nom ou votre marque, vous en êtes le fournisseur, même si le modèle sous-jacent vient d'un tiers. Les obligations de gouvernance des données, de documentation et de supervision humaine vous incombent pour la partie que vous maîtrisez, et votre contrat avec le fournisseur du modèle devient une pièce de votre dossier.

Peut-on éviter le haut risque en restreignant la destination ?

Oui, c'est une décision produit légitime, et elle est fréquente. Mais elle doit être réelle : la destination restreinte se reflète dans les fonctionnalités, dans l'interface, dans la notice et dans le discours commercial. Une restriction affichée mais contredite par l'usage réel ne tient pas.

L'AI Act change-t-il ma classe MDR ?

Non. La classification MDR suit la règle 11 de l'annexe VIII du règlement (UE) 2017/745, indépendamment de l'AI Act. L'article 43, paragraphe 3, précise d'ailleurs que la classification comme système d'IA à haut risque n'affecte pas le choix de la procédure d'évaluation de la conformité offerte par le MDR.

Vous voulez faire l'exercice sur votre produit ?

Nous développons des logiciels de santé sous contraintes HDS et RGPD depuis 2017, pour des éditeurs et des établissements dont l'AP-HP. La qualification est la première étape de nos cadrages, parce qu'elle détermine l'architecture, le calendrier et le budget.

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.