Développement d’IA en santé

Cela dépend de la destination que vous revendiquez, pas de la technologie employée. Si le logiciel est destiné à une finalité diagnostique, thérapeutique, de prévention, de pronostic ou de suivi d’une maladie, il entre dans le champ du règlement (UE) 2017/745. La classe se détermine ensuite avec la règle 11 de son annexe VIII. C’est la première chose que nous tranchons en cadrage, parce qu’elle détermine l’architecture, le calendrier et le budget.

Le règlement (UE) 2026/1744 du 8 juillet 2026 a repoussé au 2 août 2028 les obligations de fond pour les systèmes d’IA à haut risque intégrés à un produit réglementé, dont les dispositifs médicaux. Les cas d’usage de l’annexe III relèvent du 2 décembre 2027. En revanche, les obligations de transparence de l’article 50 sont applicables depuis le 2 août 2026, avec un butoir au 2 décembre 2026 pour les systèmes générant des contenus de synthèse déjà mis sur le marché.

Non, pas du seul fait de l’IA. L’article 43, paragraphe 3, de l’AI Act, dans sa version issue du règlement omnibus, précise qu’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. Un dispositif médical de classe I reste en auto-certification.

Non. L’article 17, paragraphe 3, permet d’intégrer les aspects relevant de l’AI Act au système de gestion de la qualité tenu au titre du MDR. Vous étendez votre ISO 13485 au lieu d’en créer un second. Les PME et jeunes pousses bénéficient en outre d’une documentation technique simplifiée que les organismes notifiés doivent accepter.

Oui, sous conditions. La CNIL juge l’intérêt légitime souvent adapté pour fonder le développement d’un système d’IA par un organisme privé, sous trois conditions à documenter, et recommande d’anonymiser ou, à défaut, de pseudonymiser les données à bref délai. Pour des données de santé, s’y ajoute une formalité auprès de la CNIL : déclaration de conformité à une méthodologie de référence (MR-001, MR-003 ou MR-004) ou demande d’autorisation. L’AI Act ajoute un article 4 bis qui encadre le traitement de données sensibles aux fins de détection et de correction des biais, sous six conditions cumulatives. En pratique, le chantier est la gouvernance du dataset autant que le modèle.

C’est une question d’architecture avant d’être une question juridique. Trois voies existent : déployer un modèle à poids ouverts sur une infrastructure certifiée HDS, dé-identifier les données en amont de l’appel, ou encadrer contractuellement un fournisseur en vérifiant la localisation et le périmètre de son certificat. Nous instruisons ce choix projet par projet, en fonction de la donnée réellement envoyée.

Chez des hébergeurs certifiés HDS. Nous ne sommes pas hébergeur, nous concevons et déployons chez des prestataires certifiés, en lisant le périmètre activité par activité sur leur certificat. Notre page HDS détaille cet accompagnement et notre comparatif des hébergeurs traite le choix du prestataire.

C’est le vrai sujet d’un produit d’IA en santé : le MDR est conçu pour un produit figé, un modèle vit. Cela se prépare dès la conception, avec une gestion des versions de modèle et de dataset, des seuils de performance déclarés et mesurés en production, une détection de dérive, et un plan de changements anticipé. Ce qui n’a pas été instrumenté au départ ne se rattrape pas au moment de l’évaluation.

Cela dépend du périmètre, de la classe réglementaire et de l’état de vos données. Le surcoût par rapport à un logiciel médical classique porte surtout sur trois postes : la constitution et l’annotation du jeu de données, la validation, et la documentation réglementaire. Nous travaillons sur devis après un cadrage, et notre estimateur donne un premier ordre de grandeur.