AI Act et santé : le calendrier jusqu'en 2028 et les obligations d'un logiciel médical à base d'IA

Si vous développez un logiciel de santé qui embarque un modèle, vous avez probablement lu deux choses contradictoires cet été : que l'AI Act s'appliquait en août 2026, et qu'il était reporté. Les deux sont vraies, et la nuance décide de votre feuille de route.

Le règlement (UE) 2026/1744 du 8 juillet 2026, publié au Journal officiel de l'Union européenne le 24 juillet et entré en vigueur le 27 juillet 2026, a modifié l'AI Act avant même que son cœur ne s'applique. Pour les dispositifs médicaux, les obligations de fond sont désormais applicables à partir du 2 août 2028. Mais certaines obligations courent déjà, et l'une d'elles a une échéance au 2 décembre 2026.

Ce guide fait trois choses : il donne le calendrier exact, il vous dit si votre logiciel est concerné, et il traduit les exigences du règlement en éléments de backlog. Parce que c'est là que la littérature juridique s'arrête, et que le travail commence.

Le nouveau calendrier, article par article

Le règlement omnibus a réécrit le troisième alinéa de l'article 113 de l'AI Act, celui qui fixe les dates d'application. Le résultat pour les exigences applicables aux systèmes à haut risque (chapitre III, sections 1, 2 et 3) :

Catégorie	Base juridique	Application
IA à haut risque des cas d'usage listés	Article 6, paragraphe 2, et annexe III	2 décembre 2027
IA à haut risque intégrée à un produit réglementé	Article 6, paragraphe 1, et annexe I	2 août 2028

Les dispositifs médicaux relèvent de la seconde ligne. Le règlement (UE) 2017/745 (MDR) est le point 11 de la section A de l'annexe I de l'AI Act, et le règlement (UE) 2017/746 sur les dispositifs de diagnostic in vitro en est le point 12.

Deux autres dates à retenir :

• Les chapitres I et II (dispositions générales et pratiques interdites) s'appliquent depuis le 2 février 2025, avec quelques exceptions repoussées au 2 décembre 2026.
• Les articles 102 à 110 sont applicables depuis le 27 juillet 2026.

Enfin, une disposition que peu de gens ont vue passe par l'article 111, paragraphe 2, tel que modifié : les fournisseurs et déployeurs de systèmes d'IA à haut risque destinés à être utilisés par des autorités publiques doivent se conformer au règlement au plus tard le 2 août 2030. Si votre client est un CHU ou une agence publique, cette date vous concerne plus que la précédente.

Votre IA est-elle un système à haut risque ?

C'est la première question, et sa réponse ne dépend pas de la puissance de votre modèle. Elle dépend de votre classe MDR.

L'article 6, paragraphe 1, pose deux conditions cumulatives :

1. le système d'IA est destiné à être utilisé comme 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 en vue de sa mise sur le marché.

Traduit pour un logiciel médical : votre IA est à haut risque au titre de l'annexe I si votre logiciel est un dispositif médical et que sa classe impose un organisme notifié. En pratique, cela vise les dispositifs médicaux de classe IIa, IIb et III et les dispositifs de diagnostic in vitro de classe B, C et D.

Un dispositif médical de classe I n'est pas soumis à évaluation par un tiers. La seconde condition n'est donc pas remplie, et le logiciel n'est pas à haut risque à ce titre. Si vous ne savez pas encore dans quelle classe vous tombez, la question se règle avant tout le reste, et notre guide sur la certification dispositif médical logiciel (MDR/SaMD) traite la règle de classification et le marquage CE en détail.

Trois précisions nouvelles sur le « composant de sécurité »

L'omnibus a inséré trois paragraphes dans l'article 6, et ils sont utiles :

• Article 6, paragraphe 1 bis : les systèmes d'IA utilisés uniquement pour des aspects non liés à la sécurité ne sont pas des composants de sécurité. Le règlement 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é.
• Article 6, paragraphe 1 quater : un produit soumis à évaluation par un tiers uniquement en raison de risques autres que sanitaires et sécuritaires ne remplit pas la seconde condition.

Concrètement, un module qui pré-remplit un compte rendu, résume un dossier ou trie une file d'attente sans influer sur une décision clinique ne se lit pas comme un composant de sécurité. Un module qui propose une posologie, signale une anomalie sur une image ou déclenche une alerte, oui.

La frontière n'est pas cosmétique : elle se documente. Et elle se documente à partir de votre destination revendiquée, pas de votre argumentaire commercial.

Le point que personne n'écrit : l'IA ne change pas votre procédure d'évaluation

C'est la crainte la plus répandue chez les fondateurs, et elle est infondée. L'article 43, paragraphe 3, dans sa version issue de l'omnibus, le dit explicitement :

Les fabricants de ces produits ne sont pas tenus de choisir une procédure d'évaluation de la conformité impliquant une évaluation par un tiers uniquement parce que le produit intègre un système d'IA à haut risque en tant que composant de sécurité, si cela n'est pas requis par la législation d'harmonisation de l'Union dont la liste figure à l'annexe I, section A.

Autrement dit : ajouter de l'IA à un dispositif médical de classe I ne vous envoie pas chez un organisme notifié. Le même alinéa précise que la classification comme système d'IA à haut risque n'affecte pas le choix de la procédure d'évaluation offerte par le MDR, y compris la possibilité de s'appuyer sur des normes harmonisées. La condition étant que vous ayez appliqué ces normes pour l'ensemble des exigences de la section 2 du chapitre III, ou les spécifications communes de l'article 41.

Autre cas tranché par le même article : si votre système relève à la fois de l'annexe I section A et d'une catégorie de l'annexe III, vous suivez la procédure d'évaluation de la conformité du MDR. Pas les deux.

Un seul système qualité, un seul dossier

L'articulation avec le MDR a été pensée pour éviter le doublon, et c'est la bonne nouvelle du texte.

Pour un dispositif médical à base d'IA, l'article 43, paragraphe 3, pose que le fournisseur suit la procédure d'évaluation de la conformité du MDR, et que les exigences de la section 2 du chapitre III de l'AI Act font partie de cette évaluation. L'évaluation du système de gestion de la qualité prévue à l'article 17 est également effectuée, et certains points de l'annexe VII s'appliquent (points 3, 4.3, 4.4, 4.5, le cinquième paragraphe du point 4.6 et le point 5).

Côté qualité, l'article 17, paragraphe 3, permet d'intégrer les aspects relevant de l'AI Act dans le système de gestion de la qualité tenu au titre du MDR. Vous n'avez donc pas à monter un second SMQ à côté de votre ISO 13485, mais à l'étendre.

Côté organismes notifiés, l'omnibus organise la transition : les organismes déjà notifiés au titre du MDR ou de l'IVDR sont habilités à évaluer la conformité des systèmes d'IA à haut risque aux exigences de la section 2, à condition que leur respect de l'article 31, paragraphes 4, 5, 10 et 11, ait été évalué dans leur notification existante. Ils doivent introduire une demande de désignation au plus tard le 28 janvier 2028.

Ce qu'il faut en retenir côté produit : posez la question à votre organisme notifié maintenant. S'il ne demande pas sa désignation, vous changez d'organisme notifié en pleine évaluation, et ce n'est pas un détail de planning.

Ce qui est déjà applicable, et une échéance au 2 décembre 2026

Le report ne vide pas le règlement. L'article 50 sur la transparence s'applique depuis le 2 août 2026 : les contenus générés ou manipulés par une IA doivent être détectables et marqués comme tels.

L'omnibus a ajouté une disposition transitoire précise à l'article 111, nouveau paragraphe 4 : les fournisseurs de systèmes d'IA, y compris à usage général, qui génèrent des contenus de synthèse de type audio, image, vidéo ou texte et qui ont été mis sur le marché avant le 2 août 2026, doivent se conformer à l'article 50, paragraphe 2, d'ici au 2 décembre 2026.

Si votre produit génère du texte (un brouillon de compte rendu, une synthèse de dossier, un courrier au confrère) et qu'il est déjà en production, c'est votre première échéance réelle. Elle arrive dans moins de trois mois.

Les allègements pour les jeunes pousses, à ne pas laisser sur la table

Deux modifications de l'omnibus visent directement les PME et les startups, et elles sont exploitables.

Documentation technique simplifiée (article 11, paragraphe 1). Les PME, y compris les jeunes pousses, peuvent fournir les éléments de l'annexe IV sous une forme simplifiée. La Commission doit établir un formulaire dédié, et le texte précise que les organismes notifiés acceptent ce formulaire aux fins de l'évaluation de la conformité. Ce n'est pas une tolérance, c'est une obligation faite à l'organisme.

Système qualité proportionné (article 17, paragraphe 2). La mise en œuvre du SMQ est proportionnée à la taille de l'organisation, en particulier pour une PME ou une jeune pousse. Le texte ajoute tout de même que le degré de rigueur et le niveau de protection requis restent dus.

Les exigences traduites en backlog

C'est la partie que les analyses juridiques ne font pas. Les articles 8 à 15 de l'AI Act ne sont pas des clauses à recopier dans un dossier, ce sont des décisions d'architecture. Voici la traduction que nous utilisons en cadrage.

Article 9, système de gestion des risques. Un processus continu, pas un document. Concrètement : une analyse de risques qui vit dans votre outil de suivi, reliée aux tickets et aux versions, et qui se met à jour quand vous changez le modèle. Elle se branche sur la gestion des risques ISO 14971 que le MDR vous impose déjà.

Article 10, données et gouvernance des données. Le plus lourd. Vos jeux de données d'entraînement, de validation et de test doivent satisfaire des critères de qualité. En pratique : versionner les datasets comme du code, tracer la provenance de chaque source, documenter les critères d'inclusion et d'exclusion, et pouvoir rejouer un entraînement à l'identique. Un modèle dont on ne sait pas reconstituer le jeu d'entraînement n'est pas documentable.

L'omnibus a aussi supprimé l'ancien paragraphe 5 de l'article 10 pour créer un article 4 bis dédié au traitement de données sensibles aux fins de détection et de correction des biais. Il autorise ce traitement, mais sous six conditions cumulatives : impossibilité d'y parvenir avec d'autres données y compris synthétiques ou anonymisées, limitations techniques de réutilisation et pseudonymisation, contrôles et journalisation stricts des accès, interdiction de transmission à des tiers, suppression dès le biais corrigé ou à l'expiration de la conservation, et inscription de la justification au registre des traitements. Chacune est une exigence technique, pas une clause contractuelle. Sur la partie RGPD qui se superpose, voir notre guide RGPD et données de santé pour les éditeurs.

Article 11, documentation technique. Le formulaire simplifié si vous êtes une PME. Et un principe : la documentation se génère depuis le dépôt, elle ne se rédige pas à la fin.

Article 12, enregistrement. Journalisation des événements sur la durée de vie du système. Pour un logiciel de santé, cela se combine avec la traçabilité des accès déjà exigée côté HDS et RGPD. Notre article sur l'architecture technique d'une application e-santé détaille le pattern de journalisation avec scrubbing des données de santé.

Article 13, transparence et informations aux déployeurs. La notice d'utilisation devient un livrable produit : limites du modèle, performances mesurées, population sur laquelle il a été validé, conditions d'usage hors périmètre. C'est du contenu à maintenir à chaque version.

Article 14, contrôle humain. Le professionnel de santé doit pouvoir comprendre, contredire et écarter la sortie du modèle. Cela se conçoit dans l'interface, pas dans un avertissement en pied de page : afficher le niveau de confiance, exposer les éléments qui ont conduit à la sortie, rendre le rejet aussi simple que l'acceptation, et tracer la décision finale.

Article 15, exactitude, robustesse et cybersécurité. Des seuils de performance déclarés et tenus, un comportement défini en cas d'entrée aberrante, et une résistance aux attaques adverses. À noter : l'omnibus a ajouté un paragraphe 3 à l'article 42 qui pose une présomption de conformité aux exigences de cybersécurité de l'article 15 lorsque le système relève du règlement (UE) 2024/2847 sur la cyberrésilience et que les conditions de son article 12, paragraphe 1, sont remplies.

Ce qu'il faut faire dans les douze prochains mois

Le 2 août 2028 paraît loin. Il ne l'est pas, pour une raison simple : les exigences des articles 10 et 12 portent sur des données et des traces que vous produisez maintenant. Un modèle entraîné en 2027 sur un dataset non versionné ne devient pas conforme en 2028.

L'ordre que nous recommandons :

1. Qualifier. Votre logiciel est-il un dispositif médical, et dans quelle classe ? Le module IA est-il un composant de sécurité au sens des nouveaux paragraphes de l'article 6 ?
2. Traiter l'échéance courte. Si vous générez des contenus de synthèse et que vous êtes déjà sur le marché, l'article 50, paragraphe 2, est dû au 2 décembre 2026.
3. Mettre le dataset sous contrôle. Versionnement, provenance, reproductibilité des entraînements. C'est le chantier le plus long et celui qui ne se rattrape pas.
4. Interroger votre organisme notifié sur sa demande de désignation avant le 28 janvier 2028.
5. Étendre le SMQ existant plutôt que d'en créer un second, au titre de l'article 17, paragraphe 3.
6. Instrumenter le produit : journalisation, seuils de performance mesurés en production, supervision humaine dans l'interface.

Et une règle de méthode : ce calendrier a déjà bougé deux fois. Isolez les dates dans votre documentation au lieu de les diluer dans vos procédures, pour pouvoir les corriger sans tout relire.

FAQ : AI Act et logiciels de santé

L'AI Act s'applique-t-il aux dispositifs médicaux ?

Oui. Un système d'IA intégré à un dispositif médical soumis à évaluation de la conformité par un tiers est un système à haut risque au titre de l'article 6, paragraphe 1, et de l'annexe I de l'AI Act, dont le MDR constitue le point 11 de la section A.

Quand l'AI Act s'applique-t-il aux dispositifs médicaux ?

Les exigences du chapitre III, sections 1, 2 et 3, s'appliquent à partir du 2 août 2028 pour les systèmes classés à haut risque au titre de l'article 6, paragraphe 1, et de l'annexe I. C'est la date issue du règlement (UE) 2026/1744 du 8 juillet 2026, qui a repoussé l'échéance initiale du 2 août 2027.

Un dispositif médical de classe I avec de l'IA est-il à haut risque ?

Non, pas au titre de l'annexe I. La classification exige que le produit soit soumis à une évaluation de la conformité par un tiers, ce qui n'est pas le cas d'un dispositif médical de classe I. L'article 43, paragraphe 3, précise en outre que l'intégration d'une IA n'oblige pas à choisir une procédure impliquant un tiers si le MDR ne l'exige pas.

Faut-il deux marquages CE pour un dispositif médical à base d'IA ?

Non. Le fournisseur suit la procédure d'évaluation de la conformité du MDR, et les exigences de l'AI Act font partie de cette évaluation. Le système de gestion de la qualité de l'AI Act peut être intégré à celui tenu au titre du MDR, conformément à l'article 17, paragraphe 3.

Mon module d'IA de confort est-il concerné ?

Le nouvel article 6, paragraphe 1 bis, exclut de la notion de composant de sécurité les systèmes utilisés uniquement pour des aspects non liés à la sécurité, comme l'assistance aux utilisateurs, l'automatisation ou le contrôle de la qualité. Mais le paragraphe 1 ter y ramène tout système dont la défaillance mettrait en danger la santé et la sécurité. La qualification se fait sur la destination revendiquée et se documente.

Que doit-on faire avant le 2 décembre 2026 ?

Si vous fournissez un système d'IA générant des contenus de synthèse (audio, image, vidéo ou texte) mis sur le marché avant le 2 août 2026, l'article 111, paragraphe 4, vous impose de vous conformer à l'article 50, paragraphe 2, d'ici au 2 décembre 2026.

Les startups ont-elles des obligations allégées ?

Partiellement. Les PME et jeunes pousses peuvent fournir la documentation technique de l'annexe IV sous forme simplifiée via un formulaire que les organismes notifiés doivent accepter (article 11, paragraphe 1), et la mise en œuvre du système qualité est proportionnée à la taille de l'organisation (article 17, paragraphe 2). Le niveau de rigueur exigé reste le même.

Ce que nous faisons chez Bob le développeur

Nous développons des logiciels de santé depuis 2017, sous contraintes HDS et RGPD, pour des éditeurs et des établissements dont l'AP-HP. Sur les projets qui embarquent un modèle, notre travail commence par la qualification et la traduction des exigences en décisions d'architecture : gouvernance des datasets, journalisation, supervision humaine dans l'interface, seuils de performance mesurés en production.

Si vous construisez un produit de santé à base d'IA, notre page développement d'IA en santé détaille notre approche, et l'estimateur vous donne un premier ordre de grandeur.