Bob le développeur

Développement d’IA en santé

De la qualification réglementaire à la mise en production

Vous êtes fondateur d'une healthtech, souvent médecin vous-même, et votre produit embarque un modèle. Nous traduisons l'AI Act, le MDR et les attentes de la CNIL en décisions d'architecture : gouvernance du dataset, hébergement HDS, supervision humaine dans l'interface, seuils de performance mesurés en production. Background e-santé sous normes HDS depuis 2017, développements pour l'AP-HP.

Estimer mon projet
Développement d’IA en santé

L’AI Act est un cahier des charges d’ingénierie

La littérature disponible sur l’IA en santé s’arrête à « il faut un système qualité enrichi des exigences de l’AI Act ». Personne ne dit ce que ça veut dire dans un dépôt Git, un pipeline de données et un plan de tests. C’est exactement là que nous travaillons : les articles 8 à 15 du règlement se lisent comme un backlog, et les décisions qu’ils imposent se prennent au début du projet, pas au moment de l’évaluation.

Ce que nous prenons en charge

Les quatre chantiers qui décident de la conformité d’un produit d’IA en santé, et qu’aucun document juridique ne couvre.

Qualification et périmètre

Votre logiciel est-il un dispositif médical, dans quelle classe, et votre module d’IA est-il un composant de sécurité au sens des nouveaux paragraphes de l’article 6 ? Isoler le module change la surface d’évaluation : c’est une décision d’architecture, à prendre tôt.

Gouvernance du jeu de données

Versionner les datasets comme du code, tracer la provenance de chaque source, documenter les critères d’inclusion, rejouer un entraînement à l’identique. Un modèle dont on ne sait pas reconstituer le jeu d’entraînement n’est pas documentable.

Supervision humaine dans l’interface

Le contrôle humain de l’article 14 se conçoit dans l’écran, pas dans un avertissement en pied de page : niveau de confiance affiché, éléments qui ont conduit à la sortie, rejet aussi simple que l’acceptation, décision finale tracée.

Cycle de vie du modèle

Le MDR est conçu pour un produit figé, un modèle vit. Gestion des versions de modèle et de dataset, seuils de performance déclarés et mesurés en production, détection de dérive, plan de changements anticipé.

Le calendrier réel, après le règlement omnibus

Le règlement (UE) 2026/1744 du 8 juillet 2026, entré en vigueur le 27 juillet, a réécrit les dates avant même que le cœur de l’AI Act ne s’applique. Le report n’est pas un répit : les exigences sur les données et les traces portent sur ce que vous produisez aujourd’hui.

2 déc. 2026

Contenus de synthèse déjà en production

Article 111, paragraphe 4 : les systèmes générant des contenus audio, image, vidéo ou texte mis sur le marché avant le 2 août 2026 doivent se conformer à l’article 50, paragraphe 2. C’est l’échéance la plus proche, et elle concerne beaucoup de produits déjà lancés.

2 déc. 2027

Haut risque au titre de l’annexe III

Les cas d’usage listés à l’annexe III de l’AI Act. Concerne un logiciel de santé par une fonction périphérique plutôt que par sa fonction clinique.

28 janv. 2028

Désignation des organismes notifiés

Les organismes déjà notifiés au titre du MDR ou de l’IVDR doivent introduire leur demande de désignation à cette date au plus tard. À vérifier avec le vôtre maintenant : changer d’organisme en pleine évaluation n’est pas un détail de planning.

2 août 2028

Haut risque au titre de l’annexe I

L’échéance des dispositifs médicaux à base d’IA, repoussée du 2 août 2027 par le règlement (UE) 2026/1744. Les exigences des articles 8 à 15 entrent dans la procédure d’évaluation MDR.

2 août 2030

Systèmes destinés aux autorités publiques

Article 111, paragraphe 2 : délai spécifique pour les fournisseurs et déployeurs de systèmes à haut risque destinés à des autorités publiques. Si votre client est un CHU, cette date vous concerne.

Notre méthode, du cadrage à la production

Cinq étapes dans cet ordre. L’erreur la plus coûteuse que nous voyons est de construire douze mois puis de découvrir la qualification.

01

Qualifier avant de coder

Destination revendiquée, classe MDR, statut du module d’IA. Cette étape décide de tout le reste et se fait en quelques jours, pas en quelques mois.

02

Mettre le jeu de données sous contrôle

Provenance, base légale, versionnement, reproductibilité des entraînements. C’est le chantier le plus long et le seul qui ne se rattrape pas après coup.

03

Construire et évaluer le modèle

Protocole d’évaluation défini avant l’entraînement, population de validation documentée, seuils de performance qui deviendront ceux de la notice.

04

Instrumenter le produit

Journalisation des événements, supervision humaine dans l’interface, mesure des performances en production, détection de dérive et alertes.

05

Déployer et maintenir

Hébergement chez un certifié HDS, plan de changements du modèle, mise à jour de la documentation à chaque version, surveillance après mise sur le marché.

Pourquoi nous confier votre produit d’IA en santé

Une agence spécialisée e-santé qui code, et qui lit les règlements dans le texte.

Le réglementaire traduit en technique

Les avocats et les consultants qualité tiennent le sujet réglementaire, et le tiendront. Notre valeur est ailleurs : ce que l’article 10 change dans votre pipeline de données, ce que l’article 14 change dans votre écran.

Une vraie expertise santé

Fondateurs issus de la e-santé et de la télémédecine sous normes HDS, développements pour l’AP-HP, et une trentaine de contenus de référence sur le HDS, le RGPD santé, FHIR et le MDR.

Votre produit, pas une licence

Un actif que vous possédez, dont vous maîtrisez le modèle, les données et l’hébergement, plutôt qu’une dépendance à une API dont vous ne contrôlez ni la localisation ni la politique de conservation.

Des interlocuteurs qui parlent médecine

Nos clients fondateurs sont souvent praticiens. Nous savons cadrer avec quelqu’un qui connaît sa spécialité mieux que nous et qui a besoin d’un partenaire technique, pas d’un cours sur son métier.

Le cadre dans lequel nous travaillons

Un produit d’IA en santé cumule quatre cadres qui se recoupent. Traités dès la conception, ils coûtent du temps de cadrage. Traités après, ils coûtent une réécriture.

HDS

Modèles et données chez un hébergeur certifié, périmètre lu activité par activité.

RGPD santé

Base légale de l’entraînement, minimisation, droits des patients, registre.

AI Act et MDR

Qualification, exigences des articles 8 à 15 intégrées à l’évaluation MDR.

Gouvernance des données

Provenance, versionnement, reproductibilité, détection et correction des biais.

Sécurité

Chiffrement, traçabilité des accès, journalisation, robustesse du modèle.

Questions fréquentes : IA et santé

Mon produit de santé à base d’IA est-il un dispositif médical ?▼
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.
À partir de quand l’AI Act s’applique-t-il à mon logiciel ?▼
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é.
Ajouter de l’IA va-t-il m’obliger à passer par un organisme notifié ?▼
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.
Faut-il monter un second système qualité pour l’AI Act ?▼
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.
Peut-on entraîner un modèle sur des données de patients ?▼
Oui, sous conditions. La CNIL retient l’intérêt légitime comme base légale la plus adaptée en phase de développement dans la majorité des cas, avec un triple test documenté, et recommande la pseudonymisation dès la collecte. 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.
Peut-on utiliser une API d’IA générative avec des données de santé ?▼
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.
Où hébergez-vous les modèles et les données ?▼
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.
Comment fait-on évoluer un modèle déjà marqué CE ?▼
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.
Combien coûte le développement d’un produit de santé à base d’IA ?▼
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.

Vous construisez un produit de santé à base d’IA ? Parlons-en.

Un échange pour qualifier votre produit, situer votre échéance réglementaire et cadrer ce que ça implique techniquement.

Estimer mon projet

La newsletter qu'on n'ignore pas

Abonnez-vous à notre newsletter pour recevoir nos derniers articles, retours d'expérience et conseils tech directement dans votre boîte mail.

Désinscription en un clic. Vos données restent privées.