Entraîner une IA sur des données de santé : base légale, formalités CNIL et gouvernance du dataset

Les fondateurs qui nous décrivent un projet d'IA en santé parlent presque toujours du modèle. L'architecture, le choix entre fine-tuning et entraînement, les métriques visées. Puis vient la question du jeu de données, et le projet change de nature.

Parce que le chantier réel n'est pas le modèle. C'est le dataset : d'où il vient, ce qui autorise à l'utiliser, comment il est documenté, et ce qu'il reste du patient à l'intérieur une fois le modèle entraîné.

La CNIL a publié le 5 mars 2026 des recommandations spécifiques sur le développement et l'évaluation des systèmes d'IA en santé, qui s'ajoutent à ses fiches pratiques IA et aux exigences de l'AI Act. Voici ce que ça donne quand on le traduit en travail d'ingénierie.

La première question n'est pas la base légale

C'est l'erreur de séquence la plus fréquente. Avant de se demander sur quel fondement juridique on traite les données, il faut qualifier le traitement, parce que c'est cette qualification qui détermine la formalité préalable à accomplir auprès de la CNIL.

Les recommandations du 5 mars 2026, qui s'adressent aux délégués à la protection des données et aux chefs de projet, posent la grille suivante :

Ce que vous faites	Qualification	Cadre applicable
Constituer une base de données réutilisable pour plusieurs projets	Entrepôt de données de santé	Référentiel entrepôts de données de santé
Constituer un jeu de données pour développer un système d'IA	Recherche, étude ou évaluation	MR-001, MR-003 ou MR-004
Évaluer l'impact du déploiement du système	Recherche, étude ou évaluation	MR-004

Deux conséquences immédiates.

Développer une IA en santé est qualifié de recherche, étude ou évaluation dans le domaine de la santé. Ce n'est pas une catégorie que les équipes produit ont en tête, et elle impose une formalité préalable.

La distinction entrepôt / projet est structurante. Si vous constituez une base durable que vous comptez réutiliser pour plusieurs travaux, vous êtes dans le régime des entrepôts de données de santé, avec son référentiel propre. Si vous constituez un jeu pour un projet identifié, vous êtes dans le régime des méthodologies de référence. Beaucoup d'équipes font le second en pensant au premier, ou l'inverse.

La MR-004, en pratique

C'est la méthodologie que rencontrent la plupart des projets d'IA en santé. Elle couvre les recherches n'impliquant pas la personne humaine, les études et les évaluations dans le domaine de la santé, typiquement les travaux sur des données déjà collectées.

Trois points à retenir :

• Le traitement doit présenter un caractère d'intérêt public. Ce n'est pas un obstacle à un projet privé, mais c'est un critère à argumenter, pas à supposer.
• Si votre traitement est strictement conforme à la méthodologie, la formalité se limite à une déclaration de conformité adressée à la CNIL par le responsable de traitement.
• S'il ne l'est pas, il faut une demande d'autorisation, et le calendrier n'a plus rien à voir.

La conséquence pour votre feuille de route est simple : la question « est-ce qu'on rentre dans la MR-004 » se pose avant de collecter, pas après avoir entraîné.

La base légale : l'intérêt légitime, et ce qu'il coûte

Sur le fondement du traitement, la CNIL retient que l'intérêt légitime est la base la plus adaptée dans la majorité des cas pour un organisme privé en phase de développement. Le consentement est rarement praticable quand les données viennent de sources multiples et massives.

Ce n'est pas un chèque en blanc. L'intérêt légitime suppose un triple test, documenté :

1. Un intérêt légitime au sens du droit, clairement défini. Pas « améliorer nos produits », mais un objectif précis et déterminé à l'avance, avec des critères de succès mesurables.
2. La nécessité : le traitement doit être indispensable, et une alternative moins intrusive ne doit pas permettre d'atteindre le même objectif.
3. La proportionnalité : la mise en balance avec les droits et libertés des personnes doit pencher du bon côté.

La CNIL attend en contrepartie des garanties concrètes, et elles se codent :

• anonymisation ou pseudonymisation le plus tôt possible, idéalement juste après la collecte ;
• des mesures limitant le risque de mémorisation par le modèle ;
• un droit d'opposition ouvert en amont de la collecte lorsque c'est possible ;
• une possibilité de suppression des données d'entraînement.

Ces quatre points ne sont pas des clauses de politique de confidentialité. Ce sont des fonctionnalités, avec un coût de développement.

Le piège que presque personne n'anticipe : le modèle lui-même

C'est la position la plus lourde de conséquences, et la moins commentée. Pour la CNIL, un modèle entraîné sur des données personnelles doit en principe être considéré comme soumis au RGPD, sauf à démontrer qu'il est anonyme.

Et la démonstration n'est pas déclarative. Elle passe par des tests :

• des tests d'inférence d'appartenance, qui cherchent à déterminer si un individu donné faisait partie du jeu d'entraînement ;
• des tentatives de réidentification par des moyens raisonnablement disponibles ;
• une analyse du risque de surapprentissage, de l'hétérogénéité des données et de l'architecture du modèle.

Traduit en conséquences produit : le fichier de poids de votre modèle n'est pas un artefact neutre que vous pouvez distribuer, sauvegarder n'importe où ou livrer à un client sans y réfléchir. S'il n'est pas démontré anonyme, il transporte des données personnelles, avec ce que ça implique sur l'hébergement, les durées de conservation, les transferts et les droits des personnes.

La CNIL admet que des protections au niveau du système (restrictions d'accès, filtrage des sorties, mesures de sécurité) peuvent permettre d'écarter certains usages du champ du RGPD. Mais ce sont des mesures à concevoir, pas à invoquer.

C'est aussi ce qui rend la question de l'hébergement du modèle indissociable de celle des données, sujet que nous traitons dans IA générative et données de santé : où faire tourner le modèle.

Réutiliser des données existantes

La plupart des projets ne collectent pas de zéro : ils partent de ce que le fondateur a sous la main, sa pratique, son service hospitalier, un partenariat. Trois situations, trois vérifications.

Des données déjà collectées pour autre chose. Il faut un test de compatibilité entre la finalité initiale et la nouvelle. Des données recueillies pour le soin ne basculent pas d'office vers l'entraînement d'un modèle.

Un jeu de données ouvert. La CNIL demande de vérifier l'absence d'illicéité manifeste. Un dataset public n'est pas un dataset licite par nature, et l'argument « il était sur internet » ne protège pas.

Des données acquises auprès d'un tiers. Devoir de diligence : vous devez vous assurer de la licéité de la collecte en amont, et être capable de le documenter.

Sur la couche RGPD générale qui s'applique par ailleurs à votre produit, voir notre guide RGPD et données de santé pour les éditeurs de logiciels.

Ce que l'AI Act ajoute par-dessus

Si votre système est à haut risque, l'article 10 de l'AI Act impose que vos jeux de données d'entraînement, de validation et de test satisfassent des critères de qualité. Pour les systèmes qui ne font pas appel à l'entraînement, ces exigences ne portent que sur les jeux de test.

Le règlement omnibus du 8 juillet 2026 a par ailleurs créé 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, sous six conditions cumulatives :

1. la détection et la correction des biais ne peuvent pas être satisfaites efficacement avec d'autres données, y compris synthétiques ou anonymisées ;
2. les données sont soumises à des limitations techniques de réutilisation et aux mesures les plus avancées de sécurité et de protection de la vie privée, y compris la pseudonymisation ;
3. des contrôles stricts et une documentation des accès empêchent toute mauvaise utilisation, avec des obligations de confidentialité ;
4. les données ne sont pas transmises ni consultées par d'autres parties ;
5. elles sont supprimées une fois le biais corrigé, ou à l'expiration de la durée de conservation, selon ce qui arrive en premier ;
6. le registre des traitements mentionne pourquoi ce traitement était strictement nécessaire et pourquoi d'autres données ne permettaient pas d'atteindre l'objectif.

Lisez la condition 1 attentivement : elle impose d'avoir essayé les données synthétiques ou anonymisées avant de recourir à des données sensibles, et de pouvoir le montrer. C'est une exigence de démarche, pas seulement de résultat.

Sur le calendrier d'application et la qualification de votre système, voir notre guide sur l'AI Act en santé.

La gouvernance du dataset, traduite en backlog

Voici ce que nous mettons en place concrètement sur ce type de projet. C'est la partie qui ne figure dans aucun document juridique, et c'est celle qui prend le plus de temps.

Versionner les datasets comme du code. Chaque entraînement référence une version identifiée du jeu de données. Sans ça, vous ne pouvez ni expliquer une performance, ni reproduire un résultat, ni répondre à un auditeur.

Tracer la provenance, source par source. Qui a collecté, pour quelle finalité initiale, sous quel cadre, avec quelle formalité. Cette traçabilité est ce qui rend le test de compatibilité démontrable deux ans plus tard.

Documenter les critères d'inclusion et d'exclusion. Quelle population, quelles périodes, quels appareils, quels protocoles. C'est ce qui permettra plus tard de dire sur quelle population le modèle est validé, et sur laquelle il ne l'est pas.

Rendre l'entraînement reproductible. Un modèle dont on ne sait pas reconstituer le jeu d'entraînement n'est pas documentable, donc pas certifiable.

Encadrer l'annotation. La CNIL consacre une fiche à ce sujet : les annotations doivent rester limitées à ce qui est nécessaire, exactes et objectives, et éviter les données sensibles hors exceptions. Les personnes doivent être informées de l'objectif des annotations et de qui en est responsable. En pratique, cela veut dire un référentiel d'annotation écrit, des annotateurs tracés, et une procédure de résolution des désaccords.

Définir les durées de conservation. Les données d'entraînement se suppriment quand elles ne sont plus nécessaires au développement. Une conservation prolongée pour l'auditabilité peut se justifier, mais avec des mesures de sécurité renforcées et un accès restreint.

Sécuriser le développement lui-même. Vérification de l'intégrité et de la qualité des données tout au long du cycle de vie, chiffrement des sauvegardes et des communications, contrôle des accès aux jeux non publics, outils et formats vérifiés, audits et tests d'intrusion.

Surveiller la dérive. Les données réelles s'éloignent de celles de l'entraînement : changement de population, de protocole, d'appareil. C'est un sujet de conformité autant que de performance.

Ce que vos clients établissements vont vous demander

Un dernier point, souvent découvert trop tard par les éditeurs, et qui transforme tout ce qui précède en argument commercial.

La HAS et la CNIL ont soumis à consultation publique, du 5 mars au 16 avril 2026, un projet de guide intitulé « Accompagner le bon usage des systèmes d'intelligence artificielle en contexte de soins ». Il s'adresse aux déployeurs, c'est-à-dire à vos clients : établissements publics et privés, structures médico-sociales, professionnels libéraux. Il est lié à la mise en application du 6e cycle de certification des établissements de santé.

Sa recommandation sur la contractualisation demande que le contrat contienne une information claire, accessible et documentée, élaborée par le fournisseur, portant notamment sur :

• la finalité ou destination d'usage, et le statut réglementaire (dispositif médical ou non, classe de risque) ;
• le développement du système : principes algorithmiques, origine et nature des données d'entraînement, modalités d'évaluation algorithmique, gestion des biais identifiés et stratégies d'atténuation, date de commercialisation ;
• les performances (sensibilité, spécificité, robustesse) et leur contexte de validation : validation interne, validation externe sur des données indépendantes n'ayant pas servi à l'entraînement, ou validation en conditions réelles ;
• les limites et biais connus ;
• la description précise des populations éligibles, de celles sur lesquelles les performances ont été validées, et de celles pour lesquelles le système n'est pas validé ;
• un principe de fonctionnement compréhensible, pour limiter l'effet boîte noire ;
• les dispositions minimales de contrôle humain à mettre en œuvre par le déployeur.

Ce document est un projet, la consultation est close et la version définitive est attendue. Mais la direction est claire, et elle est cohérente avec l'AI Act : ce que vous n'avez pas documenté pendant la constitution du dataset, vous ne pourrez pas le fournir à l'achat. L'établissement qui vous achète un système a ses propres obligations, registre des traitements, analyse d'impact sur la protection des données, et le cas échéant analyse d'impact sur les droits fondamentaux au titre de l'article 27 de l'AI Act. Il a besoin de vos éléments pour les remplir.

La bonne nouvelle est que la traçabilité exigée par la CNIL, celle exigée par l'article 10 de l'AI Act et celle attendue par l'acheteur sont largement la même documentation. Elle se produit une fois, tôt.

La checklist avant de collecter

1. Qualifier : entrepôt de données de santé, ou jeu de données pour un projet identifié ?
2. Déterminer la méthodologie applicable et vérifier si vous entrez strictement dans son cadre.
3. Préparer la déclaration de conformité, ou la demande d'autorisation si vous en sortez.
4. Documenter le triple test de l'intérêt légitime, avec un objectif précis et des critères de succès.
5. Vérifier la licéité de chaque source : test de compatibilité, diligence sur les tiers, contrôle des jeux ouverts.
6. Prévoir dès la conception la pseudonymisation précoce, le droit d'opposition et la suppression.
7. Mettre en place le versionnement, la traçabilité des sources et la reproductibilité des entraînements.
8. Écrire le référentiel d'annotation avant d'annoter.
9. Planifier les tests d'anonymat du modèle : inférence d'appartenance, réidentification, surapprentissage.
10. Si vous traitez des données sensibles pour corriger des biais, documenter les six conditions de l'article 4 bis, en commençant par avoir essayé les données synthétiques.

FAQ

Quelle base légale pour entraîner une IA sur des données de santé ?

Pour un organisme privé en phase de développement, la CNIL retient l'intérêt légitime comme la base la plus adaptée dans la majorité des cas, le consentement étant rarement praticable sur des sources multiples. Le triple test doit être documenté, et des garanties concrètes sont attendues : pseudonymisation précoce, limitation de la mémorisation, droit d'opposition en amont, suppression possible des données d'entraînement.

Faut-il une autorisation de la CNIL pour constituer un jeu de données d'entraînement ?

Développer un système d'IA en santé est qualifié de recherche, étude ou évaluation dans le domaine de la santé. Si votre traitement est strictement conforme à la méthodologie de référence applicable, notamment la MR-004, une déclaration de conformité suffit. S'il s'en écarte, il faut une demande d'autorisation.

Le modèle entraîné est-il une donnée personnelle ?

Pour la CNIL, un modèle entraîné sur des données personnelles doit en principe être considéré comme soumis au RGPD, sauf à démontrer son anonymat par des tests d'inférence d'appartenance, des tentatives de réidentification et une analyse du risque de surapprentissage. Ce n'est pas une présomption favorable : c'est à vous de faire la démonstration.

La pseudonymisation suffit-elle pour entraîner librement ?

Non. La pseudonymisation reste un traitement de données à caractère personnel. Elle est une garantie attendue, pas une sortie du cadre. Seule une anonymisation réelle, dont le risque de réidentification a été évalué, change le régime applicable.

Peut-on utiliser des données synthétiques ?

Oui, et l'AI Act y incite indirectement : la première des six conditions de l'article 4 bis impose de démontrer que la détection et la correction des biais ne pouvaient pas être satisfaites avec d'autres données, y compris synthétiques ou anonymisées. Autrement dit, il faut les avoir essayées. Reste que des données synthétiques mal construites reproduisent les biais de leur source.

Que faire des données après l'entraînement ?

Elles doivent être supprimées quand elles ne sont plus nécessaires au développement. Une conservation prolongée à des fins d'audit ou de maintenance peut se justifier, mais avec un accès restreint aux personnes autorisées et des mesures de sécurité renforcées. La durée se définit et se documente avant la collecte, pas après.

Un partenariat avec un CHU règle-t-il la question ?

Non, il la déplace. La formalité, la qualification du traitement et la répartition des responsabilités entre l'établissement et vous doivent être établies. Selon le montage, vous serez responsable de traitement, responsable conjoint ou sous-traitant, et ce n'est pas la même chose.

Ce que nous faisons chez Bob le développeur

Nous développons des logiciels de santé sous contraintes HDS et RGPD depuis 2017, pour des éditeurs et des établissements dont l'AP-HP. Sur les projets d'IA, la partie que nous prenons en charge est celle qui se code : le pipeline de données versionné et traçable, le référentiel d'annotation, la reproductibilité des entraînements, les tests d'anonymat du modèle, et la documentation qui se génère depuis le dépôt plutôt que de se rédiger à la fin.

Nous ne remplaçons pas votre délégué à la protection des données, et nous vous recommanderons d'en avoir un. Mais nous nous assurons que l'architecture rend ses réponses démontrables.

Notre page développement d'IA en santé détaille notre approche, notre page données de santé traite la conformité RGPD, et vous pouvez nous décrire votre projet pour un premier ordre de grandeur.