Cette nouvelle version impose de séparer les missions administratives, d’information, de suivi de la recherche et de contrôle, et interdit en pratique de les réunir dans une même application.
Une solution informatique mal conçue, qui ignore cette règle, sera écartée par les promoteurs, quelle que soit la qualité de son IA et du produit.
Mieux vaut donc connaître les règles applicables dès la conception de la solution d’IA à des fins de recherche !
I. L’AI Act : un cadre exigeant, mais rarement bloquant
1. Un texte qui régule selon le niveau de risque
L’AI Act suit une logique de sécurité des produits : exigences, évaluation de conformité, marquage CE, surveillance du marché. La démarche est donc toujours la même : vérifier que l’outil est bien un système d’IA au sens de l’article 3(1) (on ne le répètera jamais assez : le critère décisif est la capacité d’inférence), puis le classer selon son niveau de risque.
Le texte prévoit des exclusions pour la recherche : les systèmes développés et mis en service aux seules fins de la recherche scientifique (art. 2§6) et les activités de R&D menées avant la mise sur le marché (art. 2§8). L’éditeur d’une solution d’IA ne doit pas s’y tromper : un outil commercialisé et susceptible d’être utilisé en recherche reste soumis au règlement. De même, l’investigation clinique d’un dispositif médical intégrant de l’IA constitue un essai en conditions réelles est n’est à ce titre pas couvert par l’exclusion du règlement qui aura vocation à s’appliquer.
2. Des outils d’IA en recherche clinique le plus souvent hors du « haut risque »
Il ne faut pas s’y tromper, les fonctions que les équipes de recherche attendent d’un éditeur sont surtout organisationnelles : analyse documentaire, aide au pré-screening, rédaction d’articles, gestion des convocations, information à distance, gestion des consentements...
Rares sont celles qui pourraient relever des domaines de l’annexe III. Lorsqu’elles s’en approchent, le filtre de l’article 6§3 permet d’échapper à la qualification de haut risque pour une tâche procédurale étroite ou préparatoire, hors profilage.
Le haut risque ne s’impose vraiment que si l’outil est un composant ou constitue un dispositif médical soumis à un organisme notifié (annexe I). L’éditeur entre alors dans un régime qu’il connaît déjà : le règlement 2017/745 sur les dispositifs médicaux, avec une documentation technique unique.
Pour un outil d’assistance, il reste des obligations essentielles : maîtrise de l’IA des utilisateurs (art. 4), transparence lorsque l’utilisateur dialogue avec une machine (art. 50), notamment.
L’AI Act représente donc pour les éditeurs un coût de conformité connu ; il ne ferme aucun marché.
II. La MR-001 ou 003 version 2026 : la vraie contrainte de conception.
1. La MR conditionne la décision d’achat
Dès que l’outil traite des données personnelles dans le cadre d’une recherche, le client (promoteur industriel ou académique) est responsable de traitement, selon l’interprétation française de la CNIL. Si son traitement est conforme à une méthodologie de référence, une simple déclaration de conformité suffit. Dans le cas contraire, il doit obtenir une autorisation de la CNIL.
Aucun acheteur ne choisira donc un logiciel qui l’oblige à déposer une demande d’autorisation et à retarder ses études de plusieurs mois. La conformité à la MR-001 n’est donc pas un sujet juridique secondaire : c’est une condition d’achat de toute solution informatique pour la recherche clinique. Il est donc indispensable pour un éditeur de bien maitriser les exigences posées par la MR la nouvelle version 2026 des MR-001 ou la MR-003 et en premier lieu le principe de non-cumul des missions et ses exceptions.
2. Le principe de non-cumul des missions
La version 2026 des MR-001 ou la MR-003 distingue plusieurs missions au sein d’une recherche : le suivi des participants, la gestion administrative, l’information des personnes et le contrôle (notamment le contrôle qualité). Le cumul n’est admis que pour certains acteurs et à trois conditions :
- une séparation physique et organisationnelle des personnes chargées de chaque mission, avec des procédures d’habilitation distinctes ;
- un cloisonnement des données, avec des bases de données et des applications disjointes et des droits d’accès différents ;
- un accès de chaque intervenant limité aux seules données nécessaires à sa mission.
La conséquence pour l’éditeur est directe. Une solution d’IA unique qui convoque les participants, leur délivre l’information, renseigne les fiches de suivi et assiste le contrôle qualité ne peut pas être conforme à la version 2026 des MR-001 ou la MR-003, en ce qu’elle réunit dans une « même application » ce que la MR impose de séparer.
Pour un éditeur d’une solution d’IA à destination des acteurs de la recherche clinique, la leçon est simple : la MR-001 décide si le produit trouvera des acheteurs. C’est donc elle qui doit guider sa conception.
Laurence HUIN