Auteurs

Contacts

• Maria GAMBIE : mariagambie972@outlook.fr
• Pau­line GRESSENT : gressent.pauline@gmail.com
• Moham­med NAJI : najimed200@gmail.com
• Lyam PATTE : lyampatte02300@gmail.com
• Fati­ma-Zah­ra ZIMAR : fatyzimar02@gmail.com

Citation

A rap­pe­ler pour tout usage : M.GAMBIE, P.GRESSENT, M.NAJI, L.PATTE, F-Z.ZIMAR, « Vers une meilleure apti­tude à l'utilisation des logi­ciels dis­po­si­tifs médi­caux inté­grant l'IA pour les start-ups : concep­tion d'une che­ck­list opé­ra­tion­nelle », Uni­ver­si­té de Tech­no­lo­gie de Com­piègne (France), Mas­ter Ingé­nie­rie de la San­té, Par­cours Dis­po­si­tif médi­cal et affaires régle­men­taires, Mémoire de Pro­jet, https://travaux.master.utc.fr/, réf n° IDS299, jan­vier 2026, https://travaux.master.utc.fr/formations-master/ingenierie-de-la-sante/ids299/, DOI : https://doi.org/10.34746/ids299

Résumé

Les solu­tions de logi­ciels dis­po­si­tifs médi­caux inté­grant l’intelligence arti­fi­cielle (IA) s’adressent aus­si bien aux pro­fes­sion­nels de san­té et qu’aux patients. La diver­si­té des uti­li­sa­teurs et des cas d’usage rend essen­tielle l’évaluation de l’aptitude à l’utilisation lors du déve­lop­pe­ment de ces dis­po­si­tifs. Or, le cadre régle­men­taire et nor­ma­tif demeure encore peu clair, en par­ti­cu­lier pour les petites struc­tures. Ce mémoire pro­pose d’analyser les réfé­ren­tiels exis­tants et d’enquêter sur les pra­tiques de ter­rain, afin d’élaborer un outil métho­do­lo­gique per­met­tant de gui­der les start-up dans l’évaluation de l’aptitude à l’utilisation des logi­ciels inté­grant l’IA.

Abstract

Medi­cal device soft­ware solu­tions inte­gra­ting arti­fi­cial intel­li­gence (AI) are inten­ded for heal­th­care pro­fes­sio­nals and patients equal­ly. The diver­si­ty of users and use appli­ca­tions makes it essen­tial to assess the usa­bi­li­ty of these devices during their deve­lop­ment. Howe­ver, the regu­la­to­ry and nor­ma­tive fra­me­work remains unclear, par­ti­cu­lar­ly for small orga­ni­sa­tions. This the­sis pro­poses to ana­lyse exis­ting stan­dards and inves­ti­gate prac­tices in the field in order to deve­lop a metho­do­lo­gi­cal tool to guide start-ups in asses­sing the sui­ta­bi­li­ty for use of soft­ware incor­po­ra­ting AI.

Téléchargements

Vers une meilleure évaluation de l'aptitude à l’utilisation
des logiciels dispositifs médicaux intégrant l'intelligence artificielle

Introduction

Grâce aux avan­cées tech­no­lo­giques, les dis­po­si­tifs médi­caux (DM) sont de plus en plus inté­grés au par­cours de soins, impli­quant à la fois les pro­fes­sion­nels de san­té et les patients [1]. Afin d’encourager leur déploie­ment, le sys­tème de san­té fran­çais a mis en place des dis­po­si­tifs favo­ri­sant leur adop­tion, notam­ment le rem­bour­se­ment par l’Assurance mala­die, depuis 2023, des dis­po­si­tifs médi­caux numé­riques (DMN) de télé­sur­veillance et à visée thé­ra­peu­tique. Contri­buant ain­si à  répondre aux enjeux actuels du sys­tème de san­té, tels que la coor­di­na­tion des prises en charge, l’égalité d’accès aux soins et l’accélération du virage numé­rique en san­té [2, 3]. La diver­si­té des pro­fils uti­li­sa­teurs cou­plée à la com­plexi­fi­ca­tion des dis­po­si­tifs médi­caux dis­po­nibles, accroît le risque d’erreurs d’utilisation sus­cep­tibles d’impacter à la fois la sécu­ri­té des patients et les per­for­mances du dis­po­si­tif. En consé­quence, la régle­men­ta­tion impose aux fabri­cants d’identifier, d’évaluer et de réduire les risques liés à l’utilisation nor­male ou anor­male du dis­po­si­tif, en inté­grant l’apti­tude à l’utilisation [4]. Au-delà de la sécu­ri­té, l’apti­tude à l’utilisation pré­sente éga­le­ment des béné­fices éco­no­miques. En effet, impli­quer les uti­li­sa­teurs dès la concep­tion per­met de cor­ri­ger en amont les pro­blèmes d’ergonomie ou de fonc­tion­na­li­té, évi­tant ain­si les modi­fi­ca­tions coû­teuses en phase de déploie­ment, ou les rap­pels de pro­duits après mise sur le mar­ché [5]. Une étude réa­li­sée sur le rap­pel des DM inté­grant l’intel­li­gence arti­fi­cielle (IA) aux Etats-Unis a mon­tré que 43,4% des rap­pels ont eu lieu au cours de la pre­mière année de mise sur le mar­ché et que ces rap­pels ont été plus impor­tant chez les DMN n’ayant pas fait l’objet d’une éva­lua­tion cli­nique [6]. De tels évé­ne­ments peuvent à la fois com­pro­mettre la confiance des uti­li­sa­teurs envers les tech­no­lo­gies de san­té et expo­ser les indus­triels à des pré­ju­dices juri­diques, aus­si bien au niveau de la per­sonne morale que des per­sonnes physiques.

En réponse aux besoins des pro­fes­sion­nels de san­té, en termes de diag­nos­tic pré­coce et de réduc­tion du temps de prise en charge,  nom­breuses start-ups déve­loppent des dis­po­si­tifs médi­caux repo­sant sur des sys­tèmes d’IA [7].  Tou­te­fois, ces entre­prises évo­luent dans un cadre régle­men­taire euro­péen exi­geant, visant avant tout à garan­tir la sécu­ri­té des patients et la fia­bi­li­té des dis­po­si­tifs mis sur le mar­ché [8]. Dans ce contexte, les res­sources finan­cières et humaines limi­tées dont dis­posent les start-ups rendent la com­pré­hen­sion et l’application de ces exi­gences par­ti­cu­liè­re­ment com­plexes. Il appa­raît alors néces­saire de pro­po­ser des outils per­met­tant de faci­li­ter la mise en confor­mi­té régle­men­taire des dis­po­si­tifs médi­caux et de struc­tu­rer l’évaluation de l’apti­tude à l’utilisation, dans une démarche visant avant tout la sécu­ri­té des patients, la fia­bi­li­té des dis­po­si­tifs et la pré­ven­tion des erreurs d’utilisation. Ce mémoire pré­sente les moyens maté­riels et imma­té­riels mobi­li­sés, ain­si que la métho­do­lo­gie employée, pour éla­bo­rer un outil per­met­tant d’évaluer l’apti­tude à l’utilisation d’un dis­po­si­tif médi­cal numé­rique embar­quant l’IA. Il est à des­ti­na­tion des start-ups sou­hai­tant accé­der au mar­ché de l’Union européenne.

Chapitre 1 : Cadre et impact liés à l’embarquement de l’intelligence artificielle dans les dispositifs médicaux numériques

1.1. Contexte

Le mar­ché des appli­ca­tions d’IA inté­grées aux DM connaît un déve­lop­pe­ment signi­fi­ca­tif en Europe, avec une crois­sance anti­ci­pée d’environ 30% au cours des dix pro­chaines années. En 2024, ce mar­ché repré­sen­tait 0,36 Mds $ et devrait atteindre 6,68 Mds $ d’ici 2035 [7].

 En France, envi­ron 450 entre­prises actives dans le sec­teur de la san­té numé­rique et de l’IA ont été recen­sées en 2024, dont 57% intègrent l’IA dans leurs pro­duits [9]. Le dyna­misme de ce sec­teur est éga­le­ment confir­mé par les levées de fonds. La Com­mis­sion euro­péenne a alloué 2,5 Mds $ à la recherche et à l’innovation en IA dans le cadre de son pro­gramme Hori­zon Europe. Paral­lè­le­ment, des start-up telles que Geo­dAI­sics ont réus­si à lever 5 M $ pour déve­lop­per une IA géné­ra­tive expli­cable en méde­cine [10]. À titre d’exemple, la start-up Nabla a levé 65 M $ pour conce­voir des outils d’IA des­ti­nés à assis­ter les pro­fes­sion­nels de san­té dans leurs acti­vi­tés cli­niques quo­ti­diennes, notam­ment en auto­ma­ti­sant cer­taines tâches de docu­men­ta­tion médi­cale et en faci­li­tant l’intégration de l’IA dans les pro­ces­sus cli­niques [11].

Cette dyna­mique répond à un besoin concret expri­mé par les pro­fes­sion­nels de san­té, notam­ment en ima­ge­rie médi­cale. Ceux-ci cherchent à iden­ti­fier plus pré­co­ce­ment cer­taines patho­lo­gies neu­ro­lo­giques, car­diaques ou onco­lo­giques afin de mieux orien­ter la prise en charge des patients, avec pour objec­tif d’améliorer l’efficacité des soins et d’optimiser l’utilisation des res­sources. Par ailleurs, l’IA est envi­sa­gée comme un outil pou­vant sou­te­nir le déve­lop­pe­ment de la télé­mé­de­cine et de la télé­sur­veillance, en faci­li­tant l’analyse de volumes impor­tants de don­nées cli­niques et en contri­buant, dans cer­tains contextes d’usage, à une orga­ni­sa­tion des soins plus réac­tive et mieux adap­tée aux besoins des patients [7].

L’essor des logi­ciels DM inté­grant l’IA s’accompagne d’un enca­dre­ment régle­men­taire et nor­ma­tif ren­for­cé. Depuis 2017, le règle­ment (UE) 2017/745 (MDR) régule les DM, y com­pris les logi­ciels déve­lop­pés à des fins médi­cales, afin d'assurer les per­for­mances et la sécu­ri­té. Ce règle­ment impose éga­le­ment un sys­tème de sur­veillance post-com­mer­cia­li­sa­tion pour trai­ter les inci­dents liés à l’utilisation des dis­po­si­tifs. Adop­té en 2024, le règle­ment (UE) 2024/1689 (AI Act) com­plète le MDR en intro­dui­sant des obli­ga­tions spé­ci­fiques pour les sys­tèmes d’IA à haut risque, dont les logi­ciels DM. 

Par­mi les exi­gences clés, la rédac­tion d’une docu­men­ta­tion tech­nique détaillée, l’enregistrement chro­no­lo­gique des évé­ne­ments et des déci­sions du sys­tème d’IA, la trans­pa­rence du fonc­tion­ne­ment du sys­tème, la super­vi­sion humaine de ses résul­tats, ain­si que la robus­tesse du dis­po­si­tif. À ces exi­gences s’ajoutent celles rela­tives à la cyber­sé­cu­ri­té et à la gou­ver­nance des don­nées [12, 13].

Ces obli­ga­tions font écho à cer­taines normes exis­tantes, telles que la norme NF EN 62366-1:2015+A1:2020 sur l’apti­tude à l’utilisation [14] et l’IEC 62304:2006 sur le cycle de vie du logi­ciel [15]. Bien que ces normes ne soient pas spé­ci­fi­que­ment dédiées à l’IA, elles sont recon­nues comme des normes har­mo­ni­sées. Éla­bo­rées par les orga­ni­sa­tions euro­péennes de nor­ma­li­sa­tion à la demande de la Com­mis­sion euro­péenne, char­gée de pro­po­ser et de veiller à l’application des textes légis­la­tifs euro­péens, elles consti­tuent des réfé­rences essen­tielles pour pré­su­mer la confor­mi­té aux exi­gences géné­rales de sécu­ri­té et de per­for­mance.
Par ailleurs, de nou­veaux tra­vaux de nor­ma­li­sa­tion visent à pré­ci­ser cer­tains aspects encore peu détaillés par la régle­men­ta­tion, notam­ment en ce qui concerne l’évaluation des per­for­mances des DM inté­grant des modèles d’appren­tis­sage auto­ma­tique. À titre d’exemple, le réfé­ren­tiel IEC 63521, actuel­le­ment en cours de déve­lop­pe­ment, pro­pose un cadre métho­do­lo­gique pour struc­tu­rer l’éva­lua­tion des per­for­mances des DM basés sur l’appren­tis­sage auto­ma­ti­que. Bien que ce réfé­ren­tiel ne fasse pas direc­te­ment par­tie du péri­mètre opé­ra­tion­nel de ce mémoire, il illustre la dyna­mique actuelle de cla­ri­fi­ca­tion nor­ma­tive autour de l’IA en san­té [16].

Ce contexte met en évi­dence une situa­tion contras­tée. D’une part, le mar­ché des DMN inté­grant l’IA est en forte dyna­mique, por­té par des besoins clai­re­ment iden­ti­fiés par les pro­fes­sion­nels de san­té. D’autre part, l’accès au mar­ché s’inscrit dans un envi­ron­ne­ment exi­geant, impli­quant des enjeux de for­ma­tion, de struc­tu­ra­tion orga­ni­sa­tion­nelle et de maî­trise des exi­gences nor­ma­tives et régle­men­taires. Ces élé­ments repré­sentent des défis impor­tants pour les fabri­cants, en par­ti­cu­lier pour les start-ups dis­po­sant de res­sources limi­tées, qui doivent conci­lier l’innovation tech­no­lo­gique, la confor­mi­té régle­men­taire et la sécu­ri­té des patients [17]. C’est pré­ci­sé­ment dans cette pers­pec­tive que s’inscrit la pro­blé­ma­tique suivante :

Com­ment conce­voir un outil opé­ra­tion­nel, conforme aux exi­gences nor­ma­tives et régle­men­taires per­met­tant d’évaluer l’aptitude à l’utilisation des dis­po­si­tifs médi­caux numé­riques inté­grant l’intelligence arti­fi­cielle, tout en res­tant com­pré­hen­sible et uti­li­sable par des acteurs aux pro­fils variés (déve­lop­peurs et RA/QA) ?

1.2. Enjeux

Les enjeux autour de cette ques­tion s’organisent autour de trois par­tis d’acteurs, ayant cha­cun leurs problématiques :

Tout d’abord, il y a les uti­li­sa­teurs poten­tiels des logi­ciels embar­quant l’IA. Ces der­niers peuvent être com­po­sés de cli­ni­ciens, de pro­fes­sion­nels médi­co-sociaux, ain­si que de patients. Les types d’application d’IA dans des logi­ciels DM sont larges. Par consé­quent, le panel d’uti­li­sa­teurs est très variable : avec des uti­li­sa­teurs en maî­trise, mais aus­si des uti­li­sa­teurs pro­fanes vis-à-vis de l’IA et de ses impli­ca­tions. Cette contrainte fait de l’évaluation de l’apti­tude à l’utilisation des logi­ciels un défi majeur, car le déve­lop­pe­ment de l’inter­face uti­li­sa­teur doit être adap­té aux spé­ci­fi­ci­tés de ce der­nier : son niveau de connais­sances, son envi­ron­ne­ment et le contexte dans lequel il est ame­né à inter­agir avec le logi­ciel. Selon une étude réa­li­sée en 2025 en France par l’agence de son­dage Flashs [18], 49% des inter­ro­gés, trouvent ras­su­rant que l’IA soit employée par les méde­cins pour affi­ner un diag­nos­tic, en revanche 80% estiment qu’il est impor­tant d’être aver­tis lorsque leur prise en charge implique l’IA. Ces chiffres illus­trent à la fois l’espoir que repré­sente l’IA appli­quée à la san­té pour la popu­la­tion, mais aus­si les méfiances qui peuvent l’accompagner.

La seconde par­tie pre­nante regroupe les auto­ri­tés de régu­la­tion, comme la Com­mis­sion euro­péenne, les orga­ni­sa­tions de nor­ma­li­sa­tion telles que la Com­mis­sion Elec­tro­tech­nique Inter­na­tio­nale (IEC) et l’Organisation Inter­na­tio­nale de Nor­ma­li­sa­tion (ISO). Ces organes ont conscience des pro­blé­ma­tiques qui accom­pagnent l’utilisation de cette tech­no­lo­gie, notam­ment en ce qui concerne la col­lecte et la ges­tion de don­nées sen­sibles, la cyber­sé­cu­ri­té et le poten­tiel détour­ne­ment des sys­tèmes employant l’IA. L’IA attire des inves­tis­se­ments mas­sifs dans la recherche à tra­vers le monde entier : selon les chiffres de l’OCDE [19], les Etats-Unis ont inves­ti 95 Mds $ dans l’IA, contre 17 Mds $ en Chine et 11 Mds $ en Europe sur l’année 2024. Les pays membres de l’Union euro­péenne doivent donc res­ter com­pé­ti­tifs sur le plan tech­no­lo­gique pour garan­tir sa sou­ve­rai­ne­té dans le milieu, tout en garan­tis­sant un usage rai­son­nable et sûr de l’IA en san­té. Ain­si, on voit appa­raître des textes de régu­la­tion à l’échelle euro­péenne tels de l’AI Act publié en 2024, mais aus­si des guides et pré­co­ni­sa­tions d’usage par la Haute auto­ri­té de san­té à l’échelle de la France [20]

La troi­sième par­tie pre­nante concerne les déve­lop­peurs de DMN embar­quant l’IA. La dif­fé­ren­cia­tion peut-être faite entre les grandes entre­prises et les start-ups, qui ne béné­fi­cient pas des mêmes res­sources face aux tech­no­lo­gies émer­gentes. Comme men­tion­né pré­cé­dem­ment, les start-ups pos­sèdent moins de res­sources pour l’apti­tude à l'utilisation et pour­tant, elles repré­sentent la grande majo­ri­té des entre­prises de la e-san­té. Elles sont agiles et pro­posent, bien sou­vent, des solu­tions dis­rup­tives dans leur milieu res­pec­tif. Les accom­pa­gner est donc une clé pour favo­ri­ser l’innovation et la sou­ve­rai­ne­té tech­no­lo­gique tout en garan­tis­sant la sécu­ri­té et la satis­fac­tion des exi­gences uti­li­sa­teur.

L’évaluation de l’apti­tude à l’utilisation d’un logi­ciel de DM embar­quant l’IA est une pro­blé­ma­tique qui s’impose à l’interface entre un contexte régle­men­taire en cours de construc­tion et un envi­ron­ne­ment de start-up et d’innovation qui a besoin de recom­man­da­tions et de métho­do­lo­gie. Ain­si, à par­tir de ces acteurs et de leurs attentes et défis, il est pos­sible d’identifier 3 grands enjeux.

Tout d’abord, il s’agit d’un enjeu éco­no­mique et de com­pé­ti­ti­vi­té : il convient d’accompagner les start-ups afin qu’elles trans­forment leurs inno­va­tions en leviers de com­pé­ti­ti­vi­té sur un mar­ché mon­dial par­ti­cu­liè­re­ment dynamique.

Le second enjeu est d’ordre tech­nique et de sécu­ri­té des patients et des uti­li­sa­teurs. La diver­si­té des uti­li­sa­teurs, des cli­ni­ciens aux patients, exige une concep­tion cen­trée sur l'humain pour garan­tir la sécu­ri­té et l'efficacité du dispositif.

Enfin, on peut ajou­ter à cela un enjeu éthique, où, face à une tech­no­lo­gie cri­tique, il est capi­tal d’anticiper ses vul­né­ra­bi­li­tés et de les atté­nuer de façon métho­do­lo­gique, notam­ment en ce qui concerne l’interface entre l’IA et les uti­li­sa­teurs. Per­mettre aux petites struc­tures déve­lop­pant des logi­ciels embar­quant l’IA d’avoir accès à des méthodes d'application de la norme NF EN 62366-1:2015+A1:2020. De ce fait, une éva­lua­tion de l’apti­tude à l’utilisation inadap­tée peut induire des erreurs d’utilisation, entraî­nant des consé­quences telles qu’un rejet de l’outil par l’uti­li­sa­teur, une perte de cré­di­bi­li­té du cli­ni­cien, de l’établissement ou du déve­lop­peur, voire des erreurs lors du diag­nos­tic et du trai­te­ment du patient.

Afin de trai­ter ce sujet, il est néces­saire d’étudier minu­tieu­se­ment le cadre régle­men­taire des logi­ciels de DM embar­quant l’IA, et de réa­li­ser une enquête de ter­rain auprès des start-ups du domaine. Cette enquête per­met­tra de mettre en lumière les dif­fé­rents besoins des start-ups et les méthodes d’évaluation de l’apti­tude à l’utilisation qu’elles mettent en place. Enfin, les infor­ma­tions recueillies par l’enquête ter­rain, cou­plée à l’étude du cadre régle­men­taire, per­met­tra d’établir un outil métho­do­lo­gique adap­té aux besoins des start-ups.

1.3. État du marché et de l’innovation dans le domaine des dispositifs médicaux numériques intégrant l’intelligence artificielle

Afin de mieux carac­té­ri­ser l’écosystème des start-ups déve­lop­pant des logi­ciels DM inté­grant l’IA, une car­to­gra­phie des acteurs éco­no­miques a été réa­li­sée. Elle se concentre exclu­si­ve­ment sur des start-ups fran­çaises déve­lop­pant des logi­ciels qua­li­fiés de DM. Les logi­ciels d’aide à la rédac­tion de comptes ren­dus, à l’organisation de ren­dez-vous, ain­si que les logi­ciels des­ti­nés à la recherche de molé­cules phar­ma­ceu­tiques ont été volon­tai­re­ment exclus de ce péri­mètre, car ils ne relèvent pas de la même caté­go­rie régle­men­taire. Au total, 29 entre­prises ont été iden­ti­fiées et étu­diées dans le cadre de cette cartographie.

Les résul­tats obte­nus mettent en évi­dence un tis­su indus­triel majo­ri­tai­re­ment com­po­sé de struc­tures récentes et de petite taille. En effet, 90 % des entre­prises ana­ly­sées ont été créées il y a moins de dix ans, et 54,2 % d’entre elles comptent moins de cin­quante col­la­bo­ra­teurs. Ces élé­ments tra­duisent un mar­ché fran­çais des logi­ciels de DM inté­grant l’IA prin­ci­pa­le­ment por­té par des PME inno­vantes en phase de structuration.

Par ailleurs, cer­taines de ces start-ups ont réa­li­sé des levées de fonds majeures : par exemple, Glea­mer a levé 27 mil­lions d’euros lors de son finan­ce­ment de série B pour accé­lé­rer l’expansion de ses solu­tions d’IA en ima­ge­rie médi­cale, ce qui porte son total de fonds levés à 36 mil­lions d’euros à ce jour [21]; de même, Incep­to Medi­cal a levé 27 mil­lions d’euros en 2022 pour sou­te­nir son déve­lop­pe­ment à l’échelle euro­péenne [22]. Ces finan­ce­ments impor­tants leur ont per­mis de struc­tu­rer leurs équipes, de déve­lop­per leurs tech­no­lo­gies et d’avancer sur les démarches régle­men­taires et cli­niques néces­saires à l’accès au mar­ché. L’analyse montre que la majo­ri­té des solu­tions pro­po­sées prennent la forme de logi­ciels inté­grés à des sys­tèmes exis­tants (Figure 1), tels que les sys­tèmes d’archivage et de com­mu­ni­ca­tion d’images médicales.

Figure 1 : Types de logiciel de dispositif médical embarquant l’intelligence artificielle développés par les start-up françaises identifiées. Source : Auteurs

Plus de 93% des logi­ciels recen­sés sont cen­trés sur 3 fina­li­tés prin­ci­pales (Figure 2) :

• L’aide au diag­nos­tic du patient : en par­ti­cu­lier avec des logi­ciels de trai­te­ment d’imagerie médi­cale, aidant à l’identification et le diag­nos­tic de frac­tures ou de cancers. 
• Le trai­te­ment et les soins du patient : notam­ment avec la pla­ni­fi­ca­tion de chi­rur­gies à l’aide des tech­no­lo­gies de jumeaux numé­riques, recons­ti­tuant cer­taines par­ties du corps du patient et ses par­ti­cu­la­ri­tés en 3D. 
• La télé­sur­veillance et la télé­mé­de­cine : avec des solu­tions qui per­mettent d’analyser les don­nées du patient à dis­tance et d'alerter le pro­fes­sion­nel médi­cal qui le suit.

Figure 2 : Types d’application des dispositifs médicaux embarquant l’intelligence artificielle développés par les start-up françaises identifiées. Source : Auteurs

À tra­vers ces trois axes prin­ci­paux, nous pou­vons car­to­gra­phier un grand nombre des start-up étu­diées dans notre car­to­gra­phie des acteurs éco­no­miques, ce qui per­met de mieux visua­li­ser l’écosystème d’entreprises concer­nées par notre sujet (Figure 3).

Figure 3 : Répartition des entreprises en fonction de la destination de leur logiciel. Source : Auteurs

L’analyse de la car­to­gra­phie réa­li­sée per­met d’identifier des asso­cia­tions récur­rentes entre les usages des logi­ciels et cer­taines spé­cia­li­tés médi­cales (Figure 4). Une forte repré­sen­ta­tion est obser­vée entre la radio­lo­gie et les fonc­tions de diag­nos­tic, repo­sant sur l’exploitation et l’analyse de don­nées d’imagerie médi­cale. De même, la chi­rur­gie est fré­quem­ment asso­ciée à des fonc­tions de trai­te­ment, notam­ment pour la pla­ni­fi­ca­tion d’interventions chi­rur­gi­cales à par­tir de modèles numé­riques du patient. En onco­lo­gie, plu­sieurs solu­tions sont orien­tées vers la télé­sur­veillance des patients atteints de cancer.

Figure 4 : Répartition par spécialité médicale des logiciels dispositifs médicaux embarquant l’intelligence artificielle développés par les start-up françaises identifiées. Source : Auteurs

Tou­te­fois, cette répar­ti­tion met éga­le­ment en évi­dence le fait que chaque entre­prise se posi­tionne sur un péri­mètre d’expertise spé­ci­fique. À titre d’exemple, la start-up Twin­sight concentre ses déve­lop­pe­ments sur la chi­rur­gie ortho­pé­dique, et plus par­ti­cu­liè­re­ment sur la prise en charge du genou. Ces élé­ments montrent que les logi­ciels pro­po­sés par les start-ups étu­diées consti­tuent des solu­tions ciblées, appor­tant une exper­tise pré­cise à l’interface d’une ou plu­sieurs spé­cia­li­tés médicales.

Par ailleurs, l’analyse des usages indique que la majo­ri­té de ces logi­ciels est des­ti­née à des uti­li­sa­teurs exer­çant une pro­fes­sion médi­cale, prin­ci­pa­le­ment en éta­blis­se­ments de san­té ou en cabi­nets libé­raux. Ces carac­té­ris­tiques d’usage consti­tuent des élé­ments essen­tiels à prendre en compte dans la ges­tion de l’apti­tude à l’utilisation. Elles doivent ain­si être inté­grées de manière appro­fon­die lors des enquêtes de ter­rain et dans la concep­tion d’une che­ck­list régle­men­taire des­ti­née à accom­pa­gner les start-ups dans leur démarche de conformité.

1.4. État de l'art réglementaire et normatif concernant l'utilisation de l'intelligence artificielle dans le domaine des dispositifs médicaux

Le déve­lop­pe­ment et la mise sur le mar­ché de DM inté­grant des sys­tèmes d’IA sont enca­drés par un ensemble de textes régle­men­taires et nor­ma­tifs visant à garan­tir la sécu­ri­té des patients et la per­for­mance des dis­po­si­tifs. Dans ce contexte, l’apti­tude à l’utilisation consti­tue une exi­gence cen­trale, com­plé­tée par des normes et règle­ments spé­ci­fiques por­tant sur la ges­tion des risques, le cycle de vie logi­ciel, la qua­li­té des don­nées et la super­vi­sion humaine.

1.4.1 Comprendre l’aptitude à l’utilisation appliquée aux logiciels embarquant l’intelligence artificielle

L’apti­tude à l’utilisation consti­tue une exi­gence régle­men­taire fon­da­men­tale pour les DM mis sur le mar­ché euro­péen. Le MDR impose aux fabri­cants de démon­trer que leurs dis­po­si­tifs sont sûrs et per­for­mants dans des condi­tions d’utilisation réelles, en tenant compte des erreurs d’utilisation rai­son­na­ble­ment pré­vi­sibles. À ce titre, le règle­ment exige une maî­trise des risques liés à l’utilisation, une démons­tra­tion de la per­for­mance cli­nique ain­si qu’une sur­veillance post-com­mer­cia­li­sa­tion per­met­tant d’identifier et de cor­ri­ger les pro­blèmes d’usage. L’apti­tude à l’utilisation s’inscrit ain­si comme un élé­ment cen­tral de la confor­mi­té au MDR, dans la mesure où elle influence direc­te­ment la sécu­ri­té des patients et les per­for­mances du dis­po­si­tif en situa­tion réelle.

Afin de démon­trer la confor­mi­té à ces exi­gences régle­men­taires, les fabri­cants peuvent s’appuyer sur des normes har­mo­ni­sées. L’apti­tude à l’utilisation est notam­ment défi­nie par la norme NF EN 62366-1:2015+A1:2020, norme har­mo­ni­sée au titre du MDR, qui vise à garan­tir qu’un DM peut être uti­li­sé cor­rec­te­ment, effi­ca­ce­ment et en toute sécu­ri­té par l’utilisateur visé, dans son envi­ron­ne­ment d’utilisation pré­vu. Dans le cas de DM logi­ciels à fonc­tion­ne­ment déter­mi­niste, les mêmes entrées pro­duisent sys­té­ma­ti­que­ment les mêmes résul­tats. Les risques d’utilisation sont alors prin­ci­pa­le­ment liés à la concep­tion de l’inter­face uti­li­sa­teur, à la com­pré­hen­sion des infor­ma­tions affi­chées ou à des erreurs de mani­pu­la­tion. L’évaluation de l’apti­tude à l’utilisation se concentre ain­si sur la pré­ven­tion des erreurs d’usage et sur la vali­da­tion de l’interface homme-machine.

À ces dif­fi­cul­tés tech­niques s’ajoutent des enjeux propres à l’apti­tude à l’utilisation. Un logi­ciel peut très bien fonc­tion­ner sur le plan algo­rith­mique et être pour­tant mal accep­té par les pro­fes­sion­nels. Cela peut venir d’une inter­face trop com­plexe, d’un manque d’explications, ou tout sim­ple­ment d’un déca­lage entre les besoins réels de l’utilisateur et ce que le DMN pro­pose.

L’intégration de l’IA dans les logi­ciels DM conduit tou­te­fois à une évo­lu­tion de cette approche. Cer­tains modèles d’IA suivent un com­por­te­ment non stric­te­ment déter­mi­niste, leurs per­for­mances pou­vant varier en fonc­tion des don­nées d’entrée, de la repré­sen­ta­ti­vi­té des popu­la­tions d’entraînement ou de l’évolution du modèle au cours du temps. Dans ce contexte, les risques liés à l’utilisation ne pro­viennent plus uni­que­ment de l’interface, mais éga­le­ment du com­por­te­ment intrin­sèque du modèle, de ses limites et de ses incer­ti­tudes. L’apti­tude à l’utilisation doit alors inté­grer des dimen­sions sup­plé­men­taires telles que la com­pré­hen­sion des résul­tats four­nis par l’IA, l’identification des situa­tions dans les­quelles le sys­tème peut être en échec, ain­si que la capa­ci­té de l’utilisateur à inter­pré­ter cor­rec­te­ment ces résul­tats dans sa prise de décision.

C’est pré­ci­sé­ment dans ce contexte que le règle­ment (UE) 2024/1689 (AI Act) apporte des exi­gences nou­velles pour les sys­tèmes d’IA à haut risque, dont les DM font par­tie. Il impose notamment :

• l'applicabilité et la trans­pa­rence : l’utilisateur doit com­prendre com­ment l’IA pro­duit ses résul­tats, dans quelles limites elle est fiable et dans quels cas elle peut se trom­per (art. 13) ;
• a super­vi­sion humaine obli­ga­toire : le cli­ni­cien doit pou­voir inter­ve­nir, cor­ri­ger ou igno­rer la pré­dic­tion lorsque cela est néces­saire (art. 14) ;
• la jour­na­li­sa­tion des actions et déci­sions de l’IA : chaque pré­dic­tion doit être tra­çable pour faci­li­ter l’analyse et la réso­lu­tion d’incidents (art. 12).

Cette évo­lu­tion des exi­gences est illus­trée par la figure 5, qui met en évi­dence l’élargissement du péri­mètre de l’apti­tude à l’utilisation lorsque le DM embarque un modèle d’IA

Figure 5 : Caractéristiques à prendre en compte pour l’évaluation de l’aptitude à l'utilisation d’un dispositif médical embarquant l’intelligence artificielle. Source : Auteurs

Alors que l’apti­tude à l’utilisation “clas­sique”, telle que défi­nie par la norme NF EN 62366-1:2015+A1:2020, se concentre prin­ci­pa­le­ment sur l’interface et la pré­ven­tion des erreurs d’usage, celle appli­cable aux DM inté­grant l’IA inclut des dimen­sions spé­ci­fiques telles que l’explicabilité des résul­tats, la ges­tion des biais, la tra­ça­bi­li­té des déci­sions, la varia­bi­li­té du modèle et la super­vi­sion humaine, comme requis par l’AI act. Ain­si, les exi­gences du MDR, cen­trées sur la démons­tra­tion de la sécu­ri­té et de la per­for­mance cli­nique, sont désor­mais com­plé­tées par celles de l’AI Act, qui visent à appor­ter des garan­ties sup­plé­men­taires en matière de fia­bi­li­té et d’explicabilité des sys­tèmes d’IA. Là où le MDR ne détaille pas expli­ci­te­ment la ges­tion des biais algo­rith­miques ni la trans­pa­rence des modèles, dont ce n’est pas l’objet, l’AI Act vient com­bler ces lacunes par un cadre régle­men­taire dédié.

Ces constats montrent à quel point l’évaluation de l’apti­tude à l’utilisation est essen­tielle. Elle per­met de véri­fier que le DMN peut réel­le­ment être uti­li­sé dans les condi­tions du ter­rain, sans ajou­ter de charge pour les uti­li­sa­teurs ni créer de confu­sion. Pour les start-up, c’est aus­si un moyen de sécu­ri­ser leur déve­lop­pe­ment, d’anticiper les points de blo­cage et de s’assurer que leur solu­tion pour­ra être adop­tée dès leur mise sur le mar­ché, en plus d’être conforme aux exi­gences régle­men­taires. Au final, c’est une étape indis­pen­sable pour conce­voir des outils utiles, fiables et réel­le­ment adap­tés aux pra­tiques des utilisateurs.

Chapitre 2 : Comprendre les pratiques des start-up pour mieux les accompagner : une enquête de terrain

2.1 Création d’un formulaire d’enquête terrain

2.1.1 Contraintes et attentes des entretiens avec les Start-up

Pour mieux déve­lop­per un outil à des­ti­na­tion des start-up, il est essen­tiel de com­prendre les méthodes actuel­le­ment employées pour l’évaluation de l’aptitude à l’utilisation, mais aus­si les dif­fi­cul­tés aux­quelles elles font face.

La dis­po­ni­bi­li­té des fon­da­teurs ou des res­pon­sables qualité/R&D consti­tue une contrainte majeure. Les start-ups évo­luent géné­ra­le­ment dans un contexte de forte pres­sion tem­po­relle liée au déve­lop­pe­ment de leur pro­duit et à la recherche de finan­ce­ments. Dans ce contexte, le choix d’initier une enquête de ter­rain sous forme de for­mu­laire en ligne s’est impo­sé comme une solu­tion per­met­tant d’allier effi­ca­ci­té et rapidité.

Pour per­mettre aux répon­dants de rem­plir l’enquête rapi­de­ment, il faut que cette der­nière soit construite avec un maxi­mum de ques­tions fer­mées, ou à sélec­tions mul­tiples. Ce modèle néces­site donc d’émettre des hypo­thèses sur la ges­tion de l’apti­tude à l’utilisation en entre­prise, tout en lais­sant la pos­si­bi­li­té au répon­dant d’affirmer ou de contre­dire cette supposition.

Une autre contrainte atten­due concerne la confi­den­tia­li­té. Les start-ups, en par­ti­cu­lier celles déve­lop­pant des logi­ciels inté­grant de l’IA, se montrent sou­vent réti­centes à par­ta­ger des infor­ma­tions détaillées par crainte de divul­guer des élé­ments stra­té­giques de leur inno­va­tion. C’est pour­quoi, l’enquête doit être construite de manière à per­mettre aux répon­dants de répondre ano­ny­me­ment et de ne pas divul­guer cer­taines infor­ma­tions s’ils ne le sou­haitent pas.

2.1.2 Thématiques abordées par l'enquête

Pour mieux exploi­ter les réponses à l’enquête de ter­rain, les ques­tions ont été orga­ni­sées par thématiques :

• La pre­mière par­tie consiste à col­lec­ter des infor­ma­tions sur le répon­dant, telles que son poste et sa maî­trise de la norme NF EN 62366-1:2015+A1:2020 pour mieux com­prendre le contexte de chaque réponse.
• La seconde par­tie porte sur le DMN pro­po­sé par l’entreprise, afin d’en iden­ti­fier le type de logi­ciel, qu’il s'emploie seul ou de façon inté­grée à d'autres sup­ports, ain­si que son uti­li­sa­tion (diag­nos­tic, trai­te­ment et soin, télé­sur­veillance, etc). Le sta­tut de déve­lop­pe­ment du dis­po­si­tif est aus­si une don­née capi­tale à prendre en compte, car une orga­ni­sa­tion ayant mis sur le mar­ché son logi­ciel aura un pro­ces­sus de ges­tion de l’apti­tude à l’utilisation plus mature qu’une orga­ni­sa­tion en cours de concep­tion de son dispositif.
• Pour adres­ser l’apti­tude à l’utilisation, la troi­sième par­tie à pour objec­tif de com­prendre le dis­po­si­tif et ses uti­li­sa­teurs. Le type d'utilisateurs, les tâches cri­tiques réa­li­sées avec le logi­ciel et la for­ma­tion néces­saire à l’utilisateur pour uti­li­ser le dis­po­si­tif, sont des infor­ma­tions col­lec­tées pour y rat­ta­cher les méthodes d’ingénierie d’apti­tude à l’utilisation uti­li­sées.
• Com­prendre les métho­do­lo­gies employées pour éva­luer l’aptitude à l’utilisation des DMN avec IA est la prin­ci­pale cible de l’enquête de ter­rain. Les méthodes sont sépa­rées en trois axes dans le for­mu­laire : les méthodes de recherches uti­li­sées pour iden­ti­fier les spé­ci­fi­ca­tions d’utilisation, les méthodes employées pour orien­ter la concep­tion de l’interface uti­li­sa­teur, et les méthodes employées pour les éva­lua­tions de l’apti­tude à l’utilisation.
• La der­nière par­tie de l’enquête porte sur l’impact de l’IA sur l’évaluation de l’aptitude à l’utilisation pour explo­rer la ques­tion des nou­veaux chal­lenges ren­con­trés par l’utilisation de l’IA dans les DMN. L’objectif ici est de com­prendre les défis spé­ci­fiques à l’IA et les solu­tions mises en place pour les surmonter.

Enfin, l’enquête s'achève en pro­po­sant aux répon­dants de rece­voir les tra­vaux aux­quels ils auront contri­bué, qu’il s’agisse du pré­sent mémoire d’intelligence métho­do­lo­gique, du pos­ter, ou de l’outil créé pour les start-up déve­lop­pant de DMN avec IA

2.1.3 Diffusion de l'enquête

Le for­mu­laire d’enquête de ter­rain à été dif­fu­sé dans plu­sieurs types de canaux : auprès de nos réseaux Lin­ke­din res­pec­tifs, ain­si qu’au sein du groupe des anciens élèves de l’UTC, Alum­ni Bio­mé­di­caux. Il a aus­si été choi­si de faire par­ve­nir ce for­mu­laire aux res­pon­sables assu­rance qua­li­té et affaires régle­men­taires des dif­fé­rentes entre­prises iden­ti­fiées lors de la car­to­gra­phie des acteurs éco­no­miques. Enfin, les contacts col­lec­tés suite aux échanges lors des Jour­nées Fran­çaises de la Radio­lo­gie 2025, au sein du vil­lage IA et Inno­va­tion ont été exploi­tés. Ces dif­fé­rents canaux per­mettent de dif­fu­ser notre enquête, à la fois de façon ciblée avec des contacts pré­cis, mais aus­si de manière plus géné­rale, per­met­tant ain­si aux per­sonnes sol­li­ci­tées se sen­tant concer­nés par le sujet, de répondre.

Cepen­dant, il est impor­tant de noter que, mal­gré cette stra­té­gie de dif­fu­sion de l’enquête, seuls quatre pro­fes­sion­nels ont répon­du. Ces réponses per­mettent d’établir un rap­port d’enquête de ter­rain, dont les réponses ne seront exploi­tées que de manière qua­li­ta­tive car ce faible échan­tillon de réponse ne per­met pas de consti­tuer des don­nées repré­sen­ta­tives sur les start-up déve­lop­pant des DMN embar­quant l’IA.

2.2 Interprétation des données et restitution de l'enquête de terrain en vue de la création d'un outil méthodologique

Les don­nées qua­li­ta­tives de l’enquête de ter­rain, se basant sur 4 réponses sont pré­sen­tées et inter­pré­tées en Annexe 1.

Cette enquête a mis en évi­dence plu­sieurs dif­fi­cul­tés spé­ci­fiques aux DMN inté­grant de l’IA. En par­ti­cu­lier, l’IA tend à com­plexi­fier l’interface uti­li­sa­teur, tant dans la mani­pu­la­tion du dis­po­si­tif que dans l’interprétation des résul­tats, ce qui peut avoir des réper­cus­sions directes sur la sécu­ri­té du patient. Cette com­plexi­té des inter­faces est recon­nue dans la lit­té­ra­ture, qui sou­ligne que les sys­tèmes d’IA en san­té pré­sentent sou­vent des modes d’interaction variés et des repré­sen­ta­tions d’information dif­fi­ciles à inter­pré­ter pour les uti­li­sa­teurs, néces­si­tant des com­pé­tences sup­plé­men­taires et des for­ma­tions spé­ci­fiques pour assu­rer une adop­tion sûre et effi­cace [23].

Indé­pen­dam­ment du fac­teur humain, l’IA peut éga­le­ment géné­rer des erreurs liées aux biais pré­sents dans les algo­rithmes. Cet aspect, sou­li­gné par les répon­dants au ques­tion­naire, consti­tue une cause majeure de la baisse de confiance des uti­li­sa­teurs envers le dis­po­si­tif, pou­vant com­pro­mettre son adop­tion, voire entraî­ner son rejet. À l’inverse, l’automatisation des ana­lyses peut aus­si favo­ri­ser une dépen­dance exces­sive des uti­li­sa­teurs aux recom­man­da­tions du sys­tème, au détri­ment de leur propre exper­tise, aug­men­tant ain­si le risque d’erreurs d’interprétation ou de diag­nos­tic. Ces constats sont cohé­rents avec la lit­té­ra­ture scien­ti­fique, qui met en évi­dence l’impact du manque d’explicabilité et des biais algo­rith­miques sur la confiance des uti­li­sa­teurs et l’adoption des DM inté­grant de l’IA [24].

Ces dif­fi­cul­tés, cou­plées aux obs­tacles aux­quels sont confron­tées les start-ups : manque de res­sources, dif­fi­cul­té à recru­ter des uti­li­sa­teurs finaux repré­sen­ta­tifs, com­plexi­té régle­men­taire, défi­cit d’expertise en ergo­no­mie appli­quée à l’IA et absence de méthodes stan­dar­di­sées pour éva­luer les per­for­mances de l’IA ; accen­tuent la néces­si­té de déve­lop­per un outil d’accompagnement dédié à l’évaluation de l’apti­tude à l’utilisation de leurs logi­ciels embar­quant l’IA.

2.2.1 Identification des besoins des start-up pour l’aptitude à l’utilisation des logiciels embarquant l’IA

L’identification des besoins de ces entre­prises en matière d’apti­tude à l’utilisation est une étape déter­mi­nante pour conce­voir un outil en adé­qua­tion avec les attentes des uti­li­sa­teurs et les pro­blèmes rele­vés.  Cette démarche per­met de sélec­tion­ner les exi­gences per­ti­nentes issues de la norme NF EN 62366-1:2015+A1:2020 ain­si que de l’AI Act. L’analyse repose exclu­si­ve­ment sur les résul­tats du ques­tion­naire auquel des char­gés qua­li­té et affaires régle­men­taires ain­si qu’un Chief Tech­no­lo­gy Offi­cer ont répondu.

Les besoins expri­més reflètent les dif­fi­cul­tés pré­cé­dem­ment iden­ti­fiées et se tra­duisent par :

• L’évaluation de la com­pré­hen­sion par l'utilisateur des don­nées de sor­tie du logi­ciel embar­quant l'IA ;
• La garan­tie que l’utilisateur conserve un esprit cri­tique et prenne le temps de véri­fier les résul­tats du logiciel ;
• La ges­tion de la confiance de l’utilisateur afin de pré­ve­nir à la fois une dépen­dance exces­sive au sys­tème et une réti­cence à l’utiliser ;
• L’évaluation des per­for­mances de l’algorithme d’IA en condi­tions réelles ;
• L’intégration de l’évaluation des biais de l’IA dans l’expérience utilisateur.

Les pra­tiques mises en œuvre par les entre­prises pour éva­luer ces aspects sont abor­dées dans la par­tie suivante.

2.2.2 Pratiques d’évaluation de l’aptitude à l’utilisation des logiciels de dispositifs médicaux à l’œuvre au sein des start-up

L’analyse des réponses au ques­tion­naire met en évi­dence des pra­tiques hété­ro­gènes en matière d’évaluation de l’apti­tude à l’utilisation des logi­ciels DM inté­grant de l’IA au sein des start-up inter­ro­gées. Pour répondre aux besoins iden­ti­fiés pré­cé­dem­ment, les entre­prises déclarent avoir mis en place dif­fé­rentes actions, dont cer­taines sont récurrentes.

Les solu­tions les plus fré­quem­ment citées concernent la for­ma­tion et la sen­si­bi­li­sa­tion des uti­li­sa­teurs aux prin­cipes de fonc­tion­ne­ment de l’IA, ain­si que la concep­tion d’interfaces inté­grant des infor­ma­tions sur le niveau de confiance ou les per­for­mances des pré­dic­tions. Cer­taines entre­prises déclarent éga­le­ment inté­grer des risques spé­ci­fiques liés à l’IA dans leur ana­lyse de risques et assu­rer un sui­vi post-com­mer­cia­li­sa­tion, por­tant à la fois sur les per­for­mances de l’algorithme et sur l’expérience utilisateur.

Tou­te­fois, bien que les besoins aient été expri­més de manière glo­ba­le­ment simi­laire par les entre­prises ayant répon­du, les solu­tions mises en œuvre appa­raissent limi­tées en nombre et en péri­mètre. En pra­tique, chaque entre­prise semble mobi­li­ser un nombre res­treint de leviers pour répondre à ces besoins, ce qui conduit à une cou­ver­ture par­tielle des dif­fé­rentes dimen­sions de l’aptitude à l’utilisation. Cette obser­va­tion sug­gère l’absence d’une approche métho­do­lo­gique struc­tu­rée et par­ta­gée pour l’évaluation de l’aptitude à l’utilisation des logi­ciels DM inté­grant l’IA.

Concer­nant plus spé­ci­fi­que­ment l’évaluation de l’explicabilité des sys­tèmes d’IA, la majo­ri­té des entre­prises déclarent ne pas impli­quer les uti­li­sa­teurs, voire ne pas réa­li­ser d’évaluation dédiée. Lorsque cette éva­lua­tion est mise en œuvre, elle repose prin­ci­pa­le­ment sur des tests uti­li­sa­teurs inté­grant des ques­tions rela­tives à la com­pré­hen­sion du fonc­tion­ne­ment ou des résul­tats four­nis par le sys­tème. De manière com­pa­rable, l’évaluation de la confiance accor­dée au sys­tème d’IA appa­raît peu déve­lop­pée. Lorsqu’elle est réa­li­sée, elle prend essen­tiel­le­ment la forme de ques­tion­naires admi­nis­trés à l’issue de l’utilisation de l’interface.

À l’inverse, l’apti­tude à l’utilisation au sens plus géné­ral est sys­té­ma­ti­que­ment prise en compte par les entre­prises ayant répon­du à l’enquête. Toutes déclarent réa­li­ser au mini­mum des tests uti­li­sa­teurs, en condi­tions simu­lées ou réelles, asso­ciés à des ques­tion­naires de satis­fac­tion post-uti­li­sa­tion. Cer­taines com­plètent ces éva­lua­tions par une mise à dis­po­si­tion du dis­po­si­tif dans un envi­ron­ne­ment contrô­lé ou par l’analyse de don­nées d’utilisation en condi­tions réelles après la com­mer­cia­li­sa­tion. Les dif­fé­rences obser­vées entre ces pra­tiques pour­raient s’expliquer, en par­tie, par le stade de déve­lop­pe­ment des dis­po­si­tifs concer­nés, les réponses recueillies cou­vrant des situa­tions allant du pro­to­type à des dis­po­si­tifs déjà com­mer­cia­li­sés. Néan­moins, ces obser­va­tions doivent être inter­pré­tées avec pru­dence au regard du nombre limi­té de retours ana­ly­sés, 4 réponses ont été recueillies à ce jour.

Dans l’ensemble, les pra­tiques obser­vées sug­gèrent que les start-up inter­ro­gées intègrent l’apti­tude à l’utilisation dans leur démarche de déve­lop­pe­ment, mais que cer­taines dimen­sions, telles que l’explicabilité et la confiance accor­dée aux sys­tèmes d’IA, demeurent insuf­fi­sam­ment éva­luées. Ces constats, bien que fon­dés sur un échan­tillon res­treint, mettent en évi­dence l’intérêt de dis­po­ser d’un outil struc­tu­rant per­met­tant d’évaluer de manière plus homo­gène et exhaus­tive l’ensemble des dimen­sions de l’apti­tude à l’utilisation d’un DMN inté­grant l’IA. Ils ont ain­si ser­vi de base à la défi­ni­tion du cahier des charges de l’outil pro­po­sé dans la suite de ce travail.

2.2.3 Cartographie récapitulative des éléments de sortie : comparaison entre les attentes des start-up et les exigences réglementaires

La car­to­gra­phie (Figure 6) illustre la confron­ta­tion entre attentes pra­tiques des start-up et exi­gences réglementaires.

Elle met en évi­dence les points de conver­gence néces­saires pour conce­voir une che­ck­list pertinente.

Figure 6 : Cartographie du processus de création d’un outil opérationnel pour accompagner les start-up dans leur démarche d’évaluation de l’aptitude à l’utilisation de leurs produits. Source : auteurs

Chapitre 3 : Conception et validation d'un outil méthodologique

3.1 Choix de l'outil et structure générale : caractéristiques et acteurs concernés

3.1.1 Format retenu : une checklist adaptée aux start-ups du logiciel embarquant l'intelligence artificielle

Les jeunes struc­tures étant confron­tées à de nom­breuses contraintes pré­dé­fi­nies, notam­ment régle­men­taires, orga­ni­sa­tion­nelles et de res­sources, le choix d’un for­mat de type « che­ck­list » appa­raît comme la solu­tion la plus adap­tée à leurs besoins. Ce for­mat per­met de struc­tu­rer et de prio­ri­ser les exi­gences essen­tielles liées à l’usabilité, tout en limi­tant la com­plexi­té docu­men­taire et le risque d’omission lors des phases de concep­tion. Cette forme de liste de contrôle répond à trois cri­tères de base que l’on peut retrou­ver dans les carac­té­ris­tiques de l’interface uti­li­sa­teur défi­nie dans la norme NF EN 62366-1:2015+A1:2020 [14] :

• L’efficacité :elle limite la sur­charge docu­men­taire en conden­sant les points cri­tiques à véri­fier durant les phases de concep­tion en rap­port avec l’aptitude à l’utilisation ;
• Ren­de­ment ou effi­cience :res­sources dépen­sées pour atteindre l’efficacité ;
• Satis­fac­tion :confort res­sen­ti par les uti­li­sa­teurs et d’autres personnes.

Ce choix répond au besoin iden­ti­fié sur le ter­rain et repré­sente une porte d’entrée simple vers la confor­mi­té,  grâce à son côté conden­sé, struc­tu­rant et évo­lu­tif, capable de gui­der pas à pas les équipes pro­jet vers une approche de la vali­da­tion des sys­tèmes IA.

3.1.2  Sélection des exigences pertinentes du Règlement (UE) 2024/1689 (AI Act)

Avant de défi­nir la struc­ture interne de la che­ck­list, une ana­lyse de l’AI Act a été faite afin d’identifier les articles pré­sen­tant un lien direct avec l’apti­tude à l’utilisation et la sécu­ri­té d’usage dès la phase de la concep­tion des DMN embar­quant une IA.

Cette lec­ture ana­ly­tique a per­mis de dis­tin­guer les articles ayant une por­tée opé­ra­tion­nelle pour la concep­tion et l'usage, de ceux rele­vant plu­tôt de la gou­ver­nance admi­nis­tra­tive, de la confor­mi­té post-com­mer­cia­li­sa­tion ou des pro­cé­dures de mar­quage CE médical.

Le tableau ci-des­sous pré­sente la matrice de per­ti­nence issue de la syn­thèse du AI Act au regard du péri­mètre du projet.

Tableau 1 : Pertinence des articles de l'AI act pour la conception de la checklist. Source : auteurs

Article	Thème prin­ci­pal	Jus­ti­fi­ca­tion
Art.4	Maî­trise humaine de l’IA et com­pé­tence du personnel	Garan­tit la for­ma­tion et la com­pré­hen­sion des uti­li­sa­teurs dans le contexte d’usage
Art.5	Pra­tiques interdites	Défi­nit les com­por­te­ments à évi­ter pour pré­ser­ver la confiance et évi­ter la mani­pu­la­tion de l’utilisateur
Art.9	Ges­tion des risques	Couvre les risques liés à l’usage et à la mau­vaise uti­li­sa­tion prévisible
Art.12	Enre­gis­tre­ment (logs)	Assure la tra­ça­bi­li­té des évé­ne­ments et la super­vi­sion humaine du système
Art.13	Trans­pa­rence et infor­ma­tion aux déployeurs	Cœur de l’aptitude à l’utilisation : expli­ca­bi­li­té, notice, com­pré­hen­sion des don­nées de sor­ties du logi­ciel DM embar­quant l’IA
Art.14	Super­vi­sion humaine	Déter­mine le rôle actif de l’humain dans la maî­trise du fonc­tion­ne­ment d’un algo­rithme d’IA
Art.15	Robus­tesse, exac­ti­tude et cybersécurité	Garan­tit la sta­bi­li­té et la fia­bi­li­té per­çue par l’utilisateur

3.1.3 Sélection des exigences de la norme NF EN 62366-1:2015+A1:2020

Une autre ana­lyse a été faite en paral­lèle de l’AI Act, sur la norme NF EN 62366-1:2015+A1:2020. Pour se faire, une métho­do­lo­gie sys­té­ma­tique a été mise en place per­met­tant d’identifier et de sélec­tion­ner les exi­gences per­ti­nentes. Une Ana­lyse Nor­ma­tive Opé­ra­tion­nelle (ANO) a été réa­li­sée. Cette approche, déve­lop­pée à l'UTC, a pour objec­tif de décor­ti­quer la norme afin d’en faci­li­ter la com­pré­hen­sion et l’exploitation. Elle consti­tue un pilier pour la concep­tion de l’outil opérationnel.

La pre­mière étape de l’ANO consiste à iden­ti­fier les para­graphes de la norme appli­cable à notre dis­po­si­tif. Pour ce pro­jet, les articles 4 "Exi­gences géné­rales" et 5 "Pro­ces­sus d’ingénierie de l’aptitude à l’utilisation" ont été rete­nus. Chaque para­graphe est ensuite décom­po­sé phrase par phrase afin de repé­rer les exi­gences for­mu­lées, soit via le verbe d’action, soit en fonc­tion de la situa­tion où l’exigence s’applique. Chaque exi­gence est clas­sée selon son carac­tère obli­ga­toire : infor­ma­tive, condi­tion­nelle ou conseillée.

Un des­crip­tif suc­cinct des para­graphes est éga­le­ment réa­li­sé, met­tant en évi­dence les verbes d’action essen­tiels pour la com­pré­hen­sion des exi­gences. Enfin, les objec­tifs de chaque para­graphe sont défi­nis : ils pré­cisent ce que la norme demande de faire, sur quel élé­ment ou com­po­sant l’action s’applique, les preuves ou docu­ments asso­ciés, et les condi­tions d’application pour le dis­po­si­tif. Cette struc­tu­ra­tion per­met de tra­duire la norme en actions concrètes et exploi­tables dans le cadre du déve­lop­pe­ment de l’outil (Docu­ment télé­char­geable : Ana­lyse nor­ma­tive opé­ra­tion­nelle).

3.2.La structure de la checklist, son utilisation et ses utilisateurs

3.2.1 Méthodologie pour la structuration de la checklist

Afin de conce­voir la che­ck­list, il était impor­tant de savoir com­ment la struc­tu­rer cor­rec­te­ment pour rendre son uti­li­sa­tion effi­cace pour les utilisateurs.

Pour cela, la méthode QQOQCP à été uti­li­sée. La méthode QQOQCP est une tech­nique de ques­tion­ne­ment sys­té­ma­tique pour ana­ly­ser en pro­fon­deur une situa­tion via 6 ques­tions : Qui, Quoi, Où, Quand, Com­ment, Pourquoi.

Elle prend sens dans l’élaboration de cet l’outil opé­ra­tion­nel, car elle per­met de n’omettre aucun élé­ment essen­tiel dans un pro­jet et d’assurer une pro­gres­sion com­plète lors de la concep­tion d’un DM embar­quant l’IA.

• Qui ?:Le res­pon­sable qui pilote l’exigence, son nom ou son rôle ;
• Quoi ? : La réfé­rence, l’indication du réfé­ren­tiel nor­ma­tif ou régle­men­taire à res­pec­ter afin d’être conforme ;
• Où ?:La preuve tra­çable, où est enre­gis­tré le jus­ti­fi­ca­tif de conformité ;
• Quand ?:Le sta­tut, qui repré­sente l’état d’avancement du res­pect de l’exigence ;
• Com­ment ?:L’exigence ou l’action à effec­tuer, la for­mu­la­tion de l’action concrète et mesurable ;
• Pour­quoi ?:L’objectif de l’exigence, ce qui est essen­tiel à rete­nir de l’exigence.

Après avoir uti­li­sé la méthode QQOQCP, la struc­tu­ra­tion de la che­ck­list (Docu­ment télé­char­geable : Check-list opé­ra­tion­nelle) a été réa­li­sée comme docu­men­té dans le tableau 2 :

Tableau 2 : Structuration de la checklist. Source : auteurs

Colonne	Des­crip­tion	Com­ment l’utiliser
N°	Numé­ro unique	Réfé­ren­cer faci­le­ment les exigences
Exi­gence/action	Ce qui doit être réalisé	For­mu­ler comme une action concrète et mesurable
Cri­tères de pon­dé­ra­tion	4 cri­tères pour éva­luer l'exigence	Défi­nir la cri­ti­ci­té de l'exigence dans le péri­mètre du projet
Score	Cri­tères de pon­dé­ra­tion par le coef­fi­cient global	Cal­cul auto­ma­tique qui va déter­mi­ner le niveau d'importance
Niveau d’importance	Clas­si­fi­ca­tion de l'effort requis en 3 niveaux	Cal­cul auto­ma­tique basé sur le score
Objec­tif	Ce qui est essen­tiel à rete­nir de l’exigence	For­mu­ler plus sim­ple­ment l’exigence pour l’utilisateur
Réfé­rence	Norme ou article	Don­ner une indi­ca­tion sur le réfé­ren­tiel utiliser
Preuve atten­du	Forme du jus­ti­fi­ca­tif de conformité	Don­ner une indi­ca­tion sur la forme des preuves
Sta­tut	Etat d’avancement	À rem­plir : À faire / En cours / Terminé
Res­pon­sable	Qui pilote la mise en confor­mi­té à cette exigence ?	À rem­plir : Nom ou rôle (ex : Res­pon­sable Qualité)
Preuve tra­çable	Réfé­rence qui jus­ti­fie la  confor­mi­té à l’exigence	À rem­plir : Lien vers rap­port, fichier, ou référence
Com­men­taires	Notes libres	À rem­plir : Dif­fi­cul­tés, ques­tions, précisions

L’outil pro­po­sé contient cinq rubriques d’exigences cor­res­pon­dant aux grandes étapes du pro­ces­sus d’ingénierie de l’apti­tude à l’utilisation défi­ni par la norme NF EN 62366-1:2015+A1:2020 (Docu­ment télé­char­geable : Check-list opé­ra­tion­nelle) :

• Contexte d’utilisation de l’IA : rubrique de véri­fi­ca­tion des exi­gences liées à l’utilisation pré­vue, à la défi­ni­tion des spé­ci­fi­ca­tions du logi­ciel, à la popu­la­tion cible, aux limites d’emploi du sys­tème et à la for­ma­tion des utilisateurs ;
• Pilo­tage du pro­ces­sus d’aptitude à l’utilisation : exi­gences rela­tives aux pro­ces­sus de concep­tion cen­trées sur l’utilisateur, incluant l’établissement, la docu­men­ta­tion et le sui­vi des acti­vi­tés de véri­fi­ca­tion et vali­da­tion de l’aptitude à l’utilisation ;
• Maî­trise du risque d’usage : inté­gra­tion des infor­ma­tions rela­tives à la sécu­ri­té et à la com­pré­hen­sion dans la concep­tion du sys­tème, afin que celles-ci soient per­cep­tibles et com­pré­hen­sibles par l’utilisateur ;
• Sur­veillance du sys­tème par les uti­li­sa­teurs et amé­lio­ra­tion conti­nue : exi­gences en matière d’intégration de méca­nismes de super­vi­sion, d’alerte et de jour­na­li­sa­tion per­met­tant à l’utilisateur d’interpréter lui-même les ano­ma­lies et de signa­ler les évé­ne­ments cri­tiques, et les exi­gences rela­tives aux plans de sur­veillance après com­mer­cia­li­sa­tion, favo­ri­sant la révi­sion régu­lière de l’outil.

Un sys­tème de pon­dé­ra­tion pour défi­nir la cri­ti­ci­té de chaque exi­gence iden­ti­fiée est d’abord pro­po­sé. Elle per­met de mettre en évi­dence, pour l’utilisateur de la che­ck­list, les exi­gences par­ti­cu­liè­re­ment cri­tiques dans le cadre de sa ges­tion de l’apti­tude à l’utilisation de son DMN.

Le cal­cul du score brut d’une exi­gence est basé sur quatre cri­tères fondamentaux :

• Impact sur la sécu­ri­té à l’usage ou du risque d’erreur humaine ;
• Impact sur la com­pré­hen­sion et l’interprétation de l’intel­li­gence arti­fi­cielle ;
• Impact sur la super­vi­sion humaine ;
• Impact sur la confor­mi­té régle­men­taire (AI Act/MDR).

Si ce score éva­lue l’importance intrin­sèque d’une exi­gence, il ne tient pas en compte du pro­fil de risque glo­bale du DM concer­né. Appli­quer le même niveau d’importance à une exi­gence pour un DM de classe IIa et pour un DM de classe III uni­que­ment sur le score brut serait inco­hé­rent (Annexe 2).

L’étape sui­vante consiste donc à ajus­ter ce score en fonc­tion du contexte régle­men­taire et tech­nique spé­ci­fique du pro­duit, assu­rant ain­si que l’effort de confor­mi­té soit pro­por­tion­nel au risque réel. Pour ce faire,  un coef­fi­cient glo­bal est appli­qué au score brut (Annexe 2).  Le coef­fi­cient glo­bal est cal­cu­lé selon 3 paramètres :

• La classe de risque du dis­po­si­tif selon le MDR (Classe MDR) ;

• Le fait que l'IA soit une Com­po­sante de Sécu­ri­té ou non ;

• Le niveau d'autonomie et le rôle de l'humain.

L’on obtient fina­le­ment le score sui­vant  : Score  = Score Brut × Coef­fi­cient Global

Le choix stra­té­gique d'une approche mul­ti­pli­ca­tive, plu­tôt qu'additive, est fon­da­men­tal. En effet, les fac­teurs de risque ne sont pas indé­pen­dants, mais s'amplifient mutuel­le­ment. L’addition de coef­fi­cients sug­gé­rait que les charges régle­men­taires s’accumulent de manière linéaire, ce qui ne reflète pas la réa­li­té. En pra­tique, la com­plexi­té et la charge de confor­mi­té aug­mentent de manière expo­nen­tielle lorsque des fac­teurs de risques éle­vés se combinent.

Cette approche garan­tit que l'effort alloué à une même exi­gence fon­da­men­tale s'étend sur toute l'échelle de risque, pas­sant d'un niveau FAIBLE (score de 4.0) à la cri­ti­ci­té maxi­male (score de 36.0), assu­rant une pro­por­tion­na­li­té directe avec le risque glo­bal du dis­po­si­tif. Cepen­dant, ce “Score”, bien que pré­cis, demeure une valeur numé­rique brute. Pour deve­nir un guide d'action clair et exploi­table, il doit être inter­pré­té et clas­si­fié, ce qui intro­duit la néces­si­té des niveaux d'importance.

Afin de clas­si­fier au mieux, il faut tra­duire la métrique quan­ti­ta­tive don­née par le “Score” dont sa plage s’étend de 1 à 36 en un niveau qua­li­ta­tif, per­met­tant aux uti­li­sa­teurs de mieux pla­ni­fier et allouer les res­sources régle­men­taires. Il faut donc trans­po­ser ce niveau dans un sys­tème hié­rar­chi­sé et intui­tif, per­met­tant une prise de déci­sion et une prio­ri­sa­tion effi­caces des actions de conformité.

Pour ce faire, le sys­tème intègre une matrice de déci­sion, ou "Bloc d'Acceptabilité du Risque" (Docu­ment télé­char­geable : Check-list opé­ra­tion­nelle) qui seg­mente l'échelle de score en trois niveaux d'importance clairs, cha­cun cor­res­pon­dant à un niveau d'effort régle­men­taire attendu :

• FAIBLE (Score < 7) : Exi­gence option­nelle ou allé­gée (effort minimal) ;
• MODÉRÉE (Score 7-14) : Exi­gence stan­dard (effort modéré) ;
• CRITIQUE (Score > 14) : Exi­gence prio­ri­taire (effort approfondi).

La défi­ni­tion des seuils à 7 et 14 n'est pas arbi­traire. On jus­ti­fie ce choix pour cor­res­pondre à des points de rup­ture régle­men­taires, en lais­sant une plage cri­tique large, volon­taire et inten­tion­nelle (60%), on signale que le DM devient com­plexe et que les exi­gences régle­men­taires deviennent plus conséquentes.

Enfin, des exemples de mode de preuve (docu­ments et pro­ces­sus) de la confor­mi­té de l’évaluation de l’aptitude à l’utilisation du pro­duit aux exi­gences iden­ti­fiées et ain­si prio­ri­sées sont pro­po­sés à l’utilisateur.

3.2.2 Mode d'emploi de la checklist

L’outil a été conçu sous la forme d’un tableur pour être simple d’utilisation. Plu­sieurs onglets sont pro­po­sés avec notam­ment :  un dédié à la check-list, un autre à un glos­saire (Docu­ment télé­char­geable : Check-list opé­ra­tion­nelle) expli­quant les termes employés. Ce glos­saire est essen­tiel, car l’absence de défi­ni­tion pour­rait entraî­ner une inter­pré­ta­tion erro­née des exi­gences. La check-list se rem­plit pro­gres­si­ve­ment, pour chaque exi­gence, il faut :

1. Lire l'action à réaliser
2. Consul­ter le glos­saire si un terme est inconnu
3. Assi­gner un responsable
4. Fixer une date prévue
5. Mettre à jour le sta­tut au fur et à mesure
6. Joindre la preuve (lien vers docu­ment, rapport…)

(Docu­ment télé­char­geable : Check-list opé­ra­tion­nelle)

La che­ck­list en tant que docu­ment seul ne suf­fit pas pour assu­rer sa bonne uti­li­sa­tion et sa satis­fac­tion auprès des uti­li­sa­teurs. Pour se faire, des onglets sup­ports (Docu­ment télé­char­geable : Check-list opé­ra­tion­nelle) ont été éla­bo­rés afin de rendre son fonc­tion­ne­ment plus com­pré­hen­sible pour les uti­li­sa­teurs. L’ensemble des docu­ments sup­ports se retrouve dans ce tableau réca­pi­tu­la­tif ci-des­sous :

Tableau 3 : Récapitulatif des onglets supports de la check-list, élaborée sous forme de tableur, pour construire et piloter le processus d’évaluation de l’aptitude à l’utilisation des dispositifs médicaux embarquant l’intelligence artificielle. Source : auteurs

Docu­ment sup­port	Des­crip­tion
Guide d'utilisation	Explique com­ment uti­li­ser effi­ca­ce­ment la check-list Régle­men­taire pour la concep­tion de logi­ciels dis­po­si­tifs médi­caux inté­grant l'intelligence arti­fi­cielle et per­met de consi­gner des infor­ma­tions sur le dis­po­si­tif pour adap­ter la che­ck­list en conséquence
Glos­saire	Ensemble des défi­ni­tions uti­li­sés dans la check-list
FAQ	Ques­tions géné­rales sur l’utilisation de la check-list, sur la clas­si­fi­ca­tion et le périmètre
Tableau de Bord	Repré­sen­ta­tion visuelle de l’avancement quan­ti­ta­tif des actions de mise en confor­mi­té du pro­ces­sus d’évaluation de l’aptitude à l’utilisation glo­bale à entreprendre

3.2.3. Acteurs concernés et rôles dans l’utilisation de la checklist

L’outil a été conçu pour être col­la­bo­ra­tif et trans­ver­sal, il mobi­lise des acteurs inter­ve­nant dans le cycle de vie du DMN :

• Le res­pon­sable qua­li­té et affaires régle­men­taires : pilote la mise en œuvre de la checklist.

• L’équipe de concep­tion logi­cielle : qui pilote les élé­ments tech­niques liés à la vali­da­tion des fonc­tions IA et à la super­vi­sion humaine dès la conception.

• Les uti­li­sa­teurs (pro­fes­sion­nels de san­té): qui par­ti­cipent aux tests d’usage  et aident  à l’évaluation de la com­pré­hen­sion et de la qua­li­té perçue.

3.3 Format de la checklist

Pour per­mettre à un grand nombre de pro­fes­sion­nels de béné­fi­cier de l’outil déve­lop­pé lors de ce pro­jet, la che­ck­list opé­ra­tion­nelle est dis­po­nible sous deux types de format :

Un for­mat Excel® : dis­po­nible en télé­char­ge­ment en haut de la pré­sente page. Elle per­met à l’utilisateur de la che­ck­list opé­ra­tion­nelle de télé­char­ger en local le fichier et de l’utiliser comme sup­port au sein de son entre­prise via l’application Excel®.

L’avantage de ce for­mat est que l’entreprise peut sau­ve­gar­der le docu­ment dans son réseau local par­ta­gé, et garan­tir un sui­vi et la bonne construc­tion de son dos­sier d’aptitude à l'utilisation, grâce aux docu­ments en lien. En revanche, l'un des incon­vé­nients de ce for­mat réside dans le fait que son uti­li­sa­tion opti­male a été pen­sée pour Micro­soft Excel. La com­pa­ti­bi­li­té avec des tableurs gra­tuits (tels que Ope­nOf­fice Calc) n’a pas été éva­luée dans le cadre de ce pro­jet, ce qui peut consti­tuer une limite pour cer­tains uti­li­sa­teurs. De plus, Excel® ne garan­tit pas nati­ve­ment une tra­ça­bi­li­té opti­male des méta­don­nées de modi­fi­ca­tion. Bien que des car­touches de sui­vi puissent être inté­grées manuel­le­ment, ces dis­po­si­tifs res­tent dépen­dants de l’utilisateur et ne consti­tuent pas une solu­tion de tra­ça­bi­li­té sys­té­ma­tique et sécurisée.

C’est pour­quoi cet outil à été déve­lop­pé sous for­mat de site inter­net, qui se com­pose d’abord d’une page d'accueil où l’utilisateur ren­seigne son iden­ti­té. Il peut ensuite avoir accès à une ver­sion en ligne de l’outil, et l’utiliser comme l’outil au for­mat Excel®. L’utilisateur peut aus­si expor­ter les infor­ma­tions de la che­ck­list, ain­si que les docu­ments de preuves préa­la­ble­ment télé­ver­sés pour l’exporter sous forme de PDF et l’intégrer plus faci­le­ment dans son dos­sier technique. 

L’avantage de ce for­mat est qu’il per­met une consul­ta­tion simple à des fins de démons­tra­tion ou d’enseignement, via un accès direct depuis un navi­ga­teur web, sans ins­tal­la­tion préa­lable, et qu’il per­met de com­pi­ler les docu­ments de preuve à par­tir de la che­ck­list en y ajou­tant auto­ma­ti­que­ment les méta­don­nées. En revanche, le for­mat site web per­met la sau­ve­garde et la reprise des ses­sions uti­li­sa­teurs grâce à une phase d’authentification, offrant ain­si une ver­sion inter­mé­diaire modi­fiable de la che­ck­list. En revanche, l’export des don­nées est limi­té au for­mat PDF, ce qui res­treint la réuti­li­sa­tion du docu­ment sous un for­mat édi­table. Le site web est héber­gé via la pla­te­forme GitHub, qui assure l’hébergement et la mise à dis­po­si­tion de l’application. Les ser­veurs sont gérés par le pres­ta­taire d’hébergement, confor­mé­ment à ses propres poli­tiques de sécurité. 

La ges­tion de la base de don­nées est assu­rée par Fire­base, une solu­tion de base de don­nées cloud dis­po­sant d’une ver­sion gra­tuite. Les don­nées sai­sies par les uti­li­sa­teurs peuvent ain­si être sto­ckées de manière sécu­ri­sée afin de per­mettre la sau­ve­garde des ses­sions. En tant qu’administrateurs de l’outil, les membres du groupe dis­posent tech­ni­que­ment d’un accès à la base de don­nées. Tou­te­fois, un enga­ge­ment sur l’honneur est pris par l’ensemble des membres du pro­jet sti­pu­lant que les don­nées des entre­prises ou uti­li­sa­teurs ne seront ni consul­tées ni exploi­tées, sauf en cas de demande expli­cite de leur part, notam­ment à des fins de sup­port ou d’amélioration de l’outil. Le site inter­net est dis­po­nible à l’adresse : https://checklist-dm-ia.vercel.app/

Ces deux for­mats sont pen­sés pour être com­plé­men­taires, et s’adaptent à des contextes d’utilisations dif­fé­rents. Ain­si il est conseillé une uti­li­sa­tion sur Excel quand la start-up débute son pro­ces­sus d’ingénierie d’aptitude à l’utilisation, et sou­haite un outil de sup­port et de sui­vi. Tan­dis que l’utilisation du for­mat site web est plus per­ti­nente pour une consul­ta­tion péda­go­gique en for­ma­tion interne ou externe, puisqu’il est acces­sible direc­te­ment depuis inter­net et sans télé­char­ge­ment. Il est aus­si per­ti­nent comme outil de contrôle et de com­pi­la­tion finale de l’ingénierie d’aptitude à l’utilisation.

Livrer cet outil sous deux for­mats per­met à chaque start-up et uti­li­sa­teur de la che­ck­list de choi­sir la solu­tion qui convient le mieux à ses méthodes de tra­vail, ren­dant ain­si l’outil acces­sible à tous.

Conclusion

L’intégration de l’IA dans les DMN marque aujourd’hui une évo­lu­tion majeure du numé­rique en san­té. Tou­te­fois, ce poten­tiel ne peut se concré­ti­ser que si l’encadrement régle­men­taire et nor­ma­tif est cor­rec­te­ment com­pris et inté­gré par les fabri­cants, afin d’assurer la sécu­ri­té des patients et la fia­bi­li­té des DMN inté­grant de l’IA.

Ce tra­vail a per­mis de cla­ri­fier les attentes du MDR, de l’AI Act et des réfé­ren­tiels nor­ma­tifs, et d’en ana­ly­ser l’impact direct sur l’apti­tude à l’utilisation. Les éva­lua­tions for­ma­tive et som­ma­tive, au cœur de la démarche de l’NF EN 62366-1:2015+A1:2020, appa­raissent comme des étapes indis­pen­sables pour com­prendre les besoins réels des uti­li­sa­teurs, amé­lio­rer l’interface, et véri­fier que le dis­po­si­tif peut être uti­li­sé en condi­tions repré­sen­ta­tives, sans géné­rer de risques sup­plé­men­taires liés au modèle d’IA.
L’enquête menée auprès de cinq acteurs du sec­teur, bien que limi­tée, ont toutes men­tion­né un manque de temps, de res­sources et des incer­ti­tudes dans l’interprétation des textes régle­men­taires. Ces retours ont mon­tré qu’un outil simple, clair et direc­te­ment uti­li­sable pou­vait vrai­ment les aider à struc­tu­rer leur démarche et à mieux inté­grer les exi­gences qui encadrent l’IA.

La che­ck­list conçue dans ce pro­jet s’inscrit dans cette logique. Elle ne rem­place pas une ana­lyse com­plète des risques ni les obli­ga­tions régle­men­taires, mais elle consti­tue un sup­port struc­tu­rant pour aider les équipes à inté­grer pro­gres­si­ve­ment les exi­gences liées à l’IA dans un DMN.

L’objectif est de ren­for­cer la qua­li­té du pro­ces­sus de concep­tion, ce qui contri­bue indi­rec­te­ment à la mise sur le mar­ché de dis­po­si­tifs plus fiables et plus trans­pa­rents. En faci­li­tant la bonne com­pré­hen­sion des exi­gences, la che­ck­list aide les fabri­cants à déve­lop­per des DMN plus sûrs, mieux adap­tés aux uti­li­sa­teurs et plus ali­gnés avec les attentes régle­men­taires émergentes.

En défi­ni­tive, ce pro­jet s’inscrit dans une démarche d’innovation appli­quée et prag­ma­tique. Il pro­pose une lec­ture claire d’un cadre régle­men­taire en pleine évo­lu­tion, tra­duit des exi­gences com­plexes en actions concrètes et met à dis­po­si­tion un outil des­ti­né à accom­pa­gner les start-up dans la concep­tion, l’amélioration et l’évaluation des DM inté­grant l’IA. Par cette approche, il contri­bue à ren­for­cer la sécu­ri­té d’usage, la qua­li­té des DMN et, à terme, la confiance des uti­li­sa­teurs dans l’IA en san­té.

Néan­moins, l’ensemble de ce tra­vail ne se concentre que sur les exi­gences règle­men­taires euro­péennes, ce qui repré­sente une par­tie du mar­ché mon­dial. Pour per­mettre aux start-ups euro­péennes d’évoluer sur la scène inter­na­tio­nale de la e-san­té, cet outil pour­rait évo­luer vers une ver­sion pre­nant en compte d’autres régu­la­tions concer­nant l’IA et les DM, telles que les exi­gences de la Food & Drug Admi­nis­tra­tion pour les Etats-Unis.

Glossaire

Appren­tis­sage auto­ma­tique : pro­ces­sus d'optimisation des para­mètres du sys­tème d’intelligence arti­fi­cielle par des tech­niques de cal­cul afin que le com­por­te­ment du modèle reflète les don­nées d’entraînement ou l'expérience [25].

Appren­tis­sage pro­fond : approche visant à créer des repré­sen­ta­tions hié­rar­chiques grâce à l'entraînement de réseaux de neu­rones com­por­tant de nom­breuses couches cachées [25].

Apti­tude à l’utilisation : capa­ci­té de l’interface uti­li­sa­teur de per­mettre une uti­li­sa­tion effi­cace, sûre et satis­fai­sante par les uti­li­sa­teurs cibles du dis­po­si­tif médi­cal dans l’environnement d’utilisation pré­vu [14]

Biais : dis­pa­ri­té sta­tis­tique intro­duite lors du trai­te­ment des don­nées sus­cep­tible de rendre une pré­dic­tion non repré­sen­ta­tive [26].

Cog­ni­tive walk­through : méthode d’évaluation de l’aptitude à l’utilisation consis­tant à simu­ler une tâche afin d’anticiper les actions de l’utilisateur et d’évaluer la per­ti­nence des infor­ma­tions four­nies par l’inter­face uti­li­sa­teur [27, 28].

Cyber­sé­cu­ri­té : pro­tec­tion d’un sys­tème infor­ma­tique contre les attaques, intru­sions ou mani­pu­la­tions mal­veillantes [12].

Dan­ger : source poten­tielle de dom­mage [29].

Dis­po­si­tif médi­cal numé­rique : logi­ciel, seul ou inté­gré dans un sup­port phy­sique, à visées médi­cales [30].

Dom­mage : bles­sure phy­sique ou atteinte à la san­té des per­sonnes, ou atteinte aux biens ou à l’environnement [29].

Effi­ca­ci­té : pré­ci­sion et degré d’achèvement selon les­quels les uti­li­sa­teurs atteignent des objec­tifs spé­ci­fiés [14].

E-san­té : ser­vices du numé­rique au ser­vice du bien-être de la per­sonne [31].
Éva­lua­tion des per­for­mances : éva­lua­tion et ana­lyse des don­nées visant à éta­blir ou à véri­fier la vali­di­té scien­ti­fique, les per­for­mances ana­ly­tiques et, le cas échéant, les per­for­mances cli­niques d'un dis­po­si­tif [32].

Éva­lua­tion for­ma­tive : méthode réa­li­sée tout au long du déve­lop­pe­ment d’un dis­po­si­tif, afin d’identifier et de cor­ri­ger pré­co­ce­ment les pro­blèmes liés à la concep­tion, avant sa mise sur le mar­ché. Inter­vient lors de la véri­fi­ca­tion du dis­po­si­tif [14].

Éva­lua­tion som­ma­tive : méthode réa­li­sée en fin de déve­lop­pe­ment afin de mesu­rer, de façon objec­tive et quan­ti­ta­tive, la faci­li­té d’utilisation d’un dis­po­si­tif auprès d’un panel repré­sen­ta­tif d’utilisateurs. Inter­vient lors de la vali­da­tion du dis­po­si­tif [14].

Gou­ver­nance des don­nées : ensemble des pra­tiques visant à garan­tir la sécu­ri­té, l’exploitabilité, la fia­bi­li­té et la tra­ça­bi­li­té des don­nées [33].

Groupe vul­né­rable : indi­vi­dus au sein d’une popu­la­tion pré­sen­tant, en rai­son de cer­taines carac­té­ris­tiques, une pro­ba­bi­li­té plus éle­vée de com­mettre une erreur d’utilisation [12].

Ins­pec­tion plu­ra­liste : méthode d’évaluation de l’aptitude à l’utilisation où dif­fé­rents pro­fes­sion­nels ana­lysent les scé­na­rios d’usage d’un dis­po­si­tif pour repé­rer les erreurs poten­tielles et pro­po­ser des solu­tions adap­tées [28]. 

Intel­li­gence arti­fi­cielle : recherche et déve­lop­pe­ment de méca­nismes et d'applications des sys­tèmes d'intel­li­gence arti­fi­cielle [25].

Intel­li­gence arti­fi­cielle à haut risque : sys­tème d’intel­li­gence arti­fi­cielle uti­li­sé dans le cadre d’activités cri­tiques, telles que le diag­nos­tic et les soins de patients, et dont les dys­fonc­tion­ne­ments peuvent mener à des consé­quences graves [12]. 

Intel­li­gence Arti­fi­cielle géné­ra­tive : sys­tème d'intel­li­gence arti­fi­cielle basé sur des tech­niques et des modèles visant à géné­rer du conte­nu nou­veau. Ce conte­nu peut inclure, par exemple, du texte, de l'audio, du code, de la vidéo et des images [34].

Intel­li­gence Arti­fi­cielle sym­bo­lique : branche de l'intel­li­gence arti­fi­cielle qui repose sur des tech­niques et des modèles qui mani­pulent des sym­boles et des struc­tures selon des règles expli­ci­te­ment défi­nies afin d'en tirer des conclu­sions [35]

Inter­face uti­li­sa­teur : sup­port, phy­sique ou numé­rique, d’un dis­po­si­tif médi­cal en inter­ac­tion avec l’utilisateur ou par­ti­ci­pant à cette inter­ac­tion [14].

Maî­trise du risque : ensemble des acti­vi­tés abou­tis­sant à la réduc­tion ou au main­tien du risque à des niveaux spé­ci­fiés [29].

Modèles pro­ba­bi­listes : branche de l'intel­li­gence arti­fi­cielle qui repose sur des tech­niques et des modèles qui uti­lisent un enco­dage impli­cite de l'information, qui peut être déri­vé de l'expérience ou de don­nées brutes, à par­tir d’approches sta­tis­tiques et pro­duit des résul­tats avec une pro­ba­bi­li­té d'erreur don­née [25].

Médi­co-social : com­bi­nai­son des ser­vices de san­té et ser­vices sociaux afin de pro­po­ser des pres­ta­tions de prise en charge et/ou d’accompagnement d’individus en situa­tion de pré­ca­ri­té, d’exclusion, de han­di­cap ou de dépen­dance [36].

Ren­de­ment : rap­port entre le résul­tat obte­nu et les res­sources uti­li­sées pour l’obtenir par rap­port à l’efficacité [14].

Risque : com­bi­nai­son de la pro­ba­bi­li­té de la sur­ve­nue d'un dom­mage et de sa gra­vi­té [29].

Risque rési­duel : risque sub­sis­tant après la mise en œuvre des mesures de maî­trise des risques [29].

Robus­tesse : niveau de fia­bi­li­té et de sta­bi­li­té d’un sys­tème d’IA [12].

Satis­fac­tion : capa­ci­té de répondre à une exi­gence ou à un besoin expri­mé [14].

Situa­tion dan­ge­reuse : situa­tion dans laquelle des per­sonnes, des biens ou l’environnement sont  expo­sés à un ou plu­sieurs dan­gers [29].

Social : struc­ture ou action ayant pour voca­tion d’améliorer la situa­tion sociale d’une per­sonne ou d’un groupe de per­sonnes, sans com­prendre d’acte médi­cal, tel que la réin­ser­tion [37]. 

Super­vi­sion humaine : pos­si­bi­li­té pour un humain de contrô­ler, orien­ter ou arrê­ter le fonc­tion­ne­ment d’un sys­tème d’IA [12].

Sys­tème de Mana­ge­ment : ensemble d'éléments cor­ré­lés ou en inter­ac­tion d'un orga­nisme, uti­li­sés pour éta­blir des poli­tiques, des objec­tifs et des pro­ces­sus de façon à atteindre les­dits objec­tifs [38].

Sys­tème expert : Sys­tème d'IA qui accu­mule, com­bine et encap­sule les connais­sances four­nies par un ou plu­sieurs experts humains dans un domaine spé­ci­fique afin de déduire des solu­tions aux pro­blèmes [25].

Sys­tème d’intelligence arti­fi­cielle : sys­tème géné­rant des résul­tats tels que du conte­nu, des pré­vi­sions, des recom­man­da­tions ou des déci­sions en fonc­tion d'objectifs défi­nis par l'uti­li­sa­teur. Ce sys­tème peut uti­li­ser diverses tech­niques et approches d'intel­li­gence arti­fi­cielle pour déve­lop­per un modèle repré­sen­tant les don­nées, les pro­ces­sus de connais­sance, etc., et per­met­tant ain­si la réa­li­sa­tion de tâches. Les sys­tèmes d'IA sont conçus pour fonc­tion­ner avec dif­fé­rents niveaux d'automatisation [25].

Télé­mé­de­cine :  forme de pra­tique médi­cale à dis­tance uti­li­sant les tech­no­lo­gies de l’information et de la com­mu­ni­ca­tion [39].

Télé­sur­veillance : sous acti­vi­té de la télé­mé­de­cine per­met­tant le recueil des infor­ma­tions médi­cales depuis le lieu de vie [39].

Trans­pa­rence : para­mètre des sys­tèmes d’IA qui per­met d'estimer, auprès des uti­li­sa­teurs, la com­pré­hen­sion de leur fonc­tion­ne­ment et de leurs résul­tats [12].

Uti­li­sa­teur : per­sonne en inter­ac­tion, c'est-à-dire exploi­tant ou mani­pu­lant, avec le dis­po­si­tif médi­cal [14].

Uti­li­sa­teurs pro­fanes : per­sonnes qui n'ont pas de connais­sances spé­cia­li­sées, tech­niques, ou pro­fes­sion­nelles dans le domaine concer­né, et qui uti­lisent un pro­duit, ser­vice ou dis­po­si­tif comme le ferait un consom­ma­teur ordi­naire [14].

Références bibliographiques

[1] Fortune Business insights, “Taille du marché des appareils médicaux en Europe, partage et rapport [2032],” Oct. 2025. Accessed : Sep. 23, 2025. [Online]. Available : https://www.fortunebusinessinsights.com/europe-medical-devices-market-107576

[2] Haute Autorité de Santé, “Dispositifs médicaux numériques : la HAS explicite ses principes d’évaluation,” Sep. 2025. Accessed : Jan. 05, 2026. [Online]. Available : https://www.has-sante.fr/jcms/p_3644653/fr/dispositifs-medicaux-numeriques-la-has-explicite-ses-principes-d-evaluation

[3] Ministère de la santé, des familles, de l’autonomie et des et des personnes handicapées, “Stratégie de transformation du système de santé,” Feb. 2021. Accessed : Jan. 05, 2026. [Online]. Available : https://sante.gouv.fr/systeme-de-sante/systeme-de-sante/strategie-de-transformation-du-systeme-de-sante/

[4] Commission européenne, “Règlement (UE) 2017/745 du Parlement européen et du Conseil du 5 avril 2017 relatif aux dispositifs médicaux, modifiant la directive 2001/83/CE, le règlement (CE) n° 178/2002 et le règlement (CE) n° 1223/2009 et abrogeant les directives du Conseil 90/385/CEE et 93/42/CEE (Texte présentant de l’intérêt pour l’EEE. ),” Journal officiel de l’Union européenne, https://eur-lex.europa.eu, May 2017. [Online]. Available : http://data.europa.eu/eli/reg/2017/745/oj/fra

[5] A. Broussier and I. Guiraud, “Aptitude à l’utilisation et retour sur investissement : un pari gagnant pour les dispositifs médicaux ?,” Sep. 2025. Accessed : Sep. 26, 2025. [Online]. Available : https://www.medtechfrance.fr/reglementation-et-economie/cadre-legislatif-et-normes/aptitude-utilisation-retour-investissement-pari-gagnant-dispositifs-medicaux/

[6] B. Lee, P. Kramer, and S. Sandri, “Early Recalls and Clinical Validation Gaps in Artificial Intelligence–Enabled Medical Devices,” JAMA Health Forum, Aug. 2025. Accessed : Jan. 05, 2026. [Online]. Available : https://jamanetwork.com/journals/jama-health-forum/fullarticle/2837802

[7] Metatech Insights, “Europe AI in Medical Diagnostics Taille du marché, 2025-2035,” Sep. 2024. Accessed : Sep. 23, 2025. [Online]. Available : https://www.metatechinsights.com/fr/reports/europe-artificial-intelligence-ai-in-medical-diagnostics-market

[8] Bpifrance, “L’écosystème français des startups de la MedTech,” Feb. 2019. Accessed : Sep. 26, 2025. [Online]. Available : https://lehub.bpifrance.fr/ecosysteme-francais-startups-medtech/

[9] “France Biotech dévoile le Panorama France HealtTech 2024 : Une filière dynamique mais conforntée à un contexte économique complexe.” Accessed : Sep. 23, 2025. [Online]. Available : https://france-biotech.fr/wp-content/uploads/2025/02/France-Biotech_CP_Panorama_VDEF_12022025.pdf

[10] Minalogic, “GeodAIsics lève 5 millions d’euros en série A pour accélérer la médecine personnalisée par l’IA, avec un actionnariat médical indépendant,” Minalogic. Accessed : Sep. 23, 2025. [Online]. Available : https://www.minalogic.com/actualites-adherents/geodaisics-leve-5-millions-deuros-en-serie-a-pour-accelerer-la-medecine-personnalisee-par-lia-avec-un-actionnariat-medical-independant/ 

[11] L. R. D. FRENCHWEB.FR, “Nabla lève 65 millions d’euros pour transformer l’IA médicale en infrastructure clinique,” Jun. 2025. Accessed : Sep. 23, 2025. [Online]. Available : https://www.frenchweb.fr/nabla-leve-65-millions-deuros-pour-transformer-lia-medicale-en-infrastructure-clinique/455513

[12] Comission européenne, “RÈGLEMENT (UE) 2024/1689 DU PARLEMENT EUROPÉEN ET DU CONSEIL,” Journal officiel de l’Union européenne, https://eur-lex.europa.eu, Jun. 2024. Accessed : Sep. 25, 2025. [Online]. Available : https://eur-lex.europa.eu/eli/reg/2024/1689/oj?locale=fr

[13] “NF EN ISO/IEC 23894 - Technologies de l’information - Intelligence artificielle - Recommandations relatives au management du risque,” Ed. Afnor, Paris, www.afnor.org, Feb. 2024.

[14] “NF EN 62366-1:2015+A1:2020 - Application de l’ingénierie de l’aptitude à l’utilisation aux dispositifs médicaux.” “NF EN 62366-1:2015+A1:2020 - Application de l’ingénierie de l’aptitude à l’utilisation aux dispositifs médicaux.” Ed. Afnor, Paris, www.afnor.org, Dec 2015

[15] “IEC 62304 - Quelles exigences pour les Logiciels de Dispositif Médical ? • Tuleap,” Tuleap. Accessed : Sep. 27, 2025. [Online]. Available : https://www.tuleap.org/fr/qualite-logicielle/iec-62304-exigences-norme-logiciels-de-dispositif-medical

[16] K. Chelly, “Projet de norme IEC 63521 : DM basé sur l’apprentissage automatique - Processus d’évaluation des performances,” DMEXPERTS - Veille, formation et conseil pour les dispositifs médicaux- Réseau de consultants. Accessed : Sep. 23, 2025. [Online]. Available : https://www.dm-experts.fr/2025/07/projet-de-norme-iec-63521-dm-base-sur-lapprentissage-automatique-processus-devaluation-des-performances/

[17] J. PIET, W. CHAABANI, R. EL KHOUMSSI, L. Dieudonnée TEGANG MEYIMO, and A. A. Ahmed ALISAWI, “IDS250 – Proposition d’outils à destination des fabricants pour faciliter l’intégration de l’AI Act avec le RDM,” Université de Technologie de Compiègne, 2025. Accessed : Sep. 25, 2025. [Online]. Available : https://travaux.master.utc.fr/formations-master/ingenierie-de-la-sante/ids250/

[18] Flashs, “Les Français, leur santé et l’IA,” Flashs, France, Sondage, Apr. 2025. Accessed : Sep. 28, 2025. [Online]. Available : https://www.flashs.fr/posts/les-francais-sante-intelligence-artificielle

[19] OECD.AI, “Live data from OECD.AI,” Sep. 2025. Accessed : Sep. 29, 2025. [Online]. Available : https://oecd.ai/en/data

[20] Ministère de la santé, “Stratégie intelligence artificielle et données de santé.” Ministère de la santé, Jul. 2025. Accessed : Sep. 28, 2025. [Online]. Available : https://sante.gouv.fr/IMG/pdf/strategie_donnees_et_intelligence_artificielle.pdf

[21] C. Carmagnol, “Gleamer Raises €27 Million in Series B Funding Round to Expand its AI Solutions Portfolio and Speed up International Expansion,” Jan. 2023. Accessed : Jan. 07, 2026. [Online]. Available : https://www.businesswire.com/news/home/20230628695819/en/Gleamer-Raises-%E2%82%AC27-Million-in-Series-B-Funding-Round-to-Expand-its-AI-Solutions-Portfolio-and-Speed-up-International-Expansion

[22] Incepto medical, “Incepto, spécialiste de la santé digitale, lève 27 millions d’euros pour accompagner son développement européen,” Sep. 2022. Accessed : Jan. 07, 2026. [Online]. Available : https://incepto-medical.com/learn/press-release/incepto-specialiste-de-la-sante-digitale-leve-27-millions-deuros-pour-accompagner-son-developpement-europeen

[23] J. Cálem, C. Moreira, and J. Jorge, “Intelligent systems in healthcare : A systematic survey of explainable user interfaces,” Comput. Biol. Med., vol. 180, p. 108908, Sep. 2024, doi : 10.1016/j.compbiomed.2024.108908.

[24] J. Amann, A. Blasimme, E. Vayena, D. Frey, V. I. Madai, and Precise4Q consortium, “Explainability for artificial intelligence in healthcare : a multidisciplinary perspective,” BMC Med. Inform. Decis. Mak., vol. 20, no. 1, p. 310, Nov. 2020, doi : 10.1186/s12911-020-01332-6.

[25] ISO and IEC, “ISO/IEC 22989:2022 Information technology — Artificial intelligence — Artificial intelligence concepts and terminology,” Jul. 2022. Accessed : Jan. 05, 2026. [Online]. Available : https://www.iso.org/fr/standard/74296.html

[26] ISO and IEC, “ISO/IEC DTR 29119-11 Guidelines on the testing of AI based systems,” Mar. 26, 2020. Accessed : Sep. 19, 2025. [Online]. Available : https://www.iso.org/fr/home.html

[27] Interaction Design Foundation, “Cognitive Walkthrough,” Interaction Design Foundation, Nov. 2024. Accessed : Nov. 13, 2025. [Online]. Available : https://www.interaction-design.org/literature/topics/cognitive-walkthrough#:~:text=A%20cognitive%20walkthrough%20is%20a,specific%20user%20journey%20is%20conducted

[28] J. Nielson and R. L. Mack, ouvrage "Usability Inspection Methods", New York : John Wiley&Sons. 1994.

[29] “NF EN ISO 14971 - Dispositifs médicaux - Application de la gestion des risques aux dispositifs médicaux,” Ed. Afnor, Paris, www.afnor.org, Dec. 18, 2019.

[30] Commission européenne, “MDCG 2019-11 Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR,” Oct. 2019. [Online]. Available : https://health.ec.europa.eu/system/files/2020-09/md_mdcg_2019_11_guidance_en_0.pdf

[31] Agence Régionale de Santé Bourgogne-Franche-Comté, “La e-santé, qu’est-ce que c’est ?,” Feb. 2024. Accessed : Jan. 05, 2026. [Online]. Available : https://www.bourgogne-franche-comte.ars.sante.fr/la-e-sante-quest-ce-que-cest

[32] Comission européenne, “MDCG 2020-1 Guidance on Clinical Evaluation (MDR) / Performance Evaluation (IVDR) of Medical Device Software,” Mar. 2020. Accessed : Nov. 18, 2025. [Online]. Available : https://ec.europa.eu/docsroom/documents/40323

[33] Commission européenne, “Règlement (UE) 2022/868 du Parlement européen et du Conseil du 30 mai 2022 portant sur la gouvernance européenne des données et modifiant le règlement (UE) 2018/1724 (règlement sur la gouvernance des données) (Texte présentant de l’intérêt pour l’EEE. ),” May 2022. [Online]. Available : https://eur-lex.europa.eu/eli/reg/2022/868/oj?locale=fr

[34] ISO and IEC, “ISO/IEC 22989:2022/DAmd 1(en) Information technology — Artificial intelligence — Artificial intelligence concepts and terminology — AMENDMENT 1 : Generative AI,” Nov. 2025. [Online]. Available : https://www.iso.org/obp/ui/en/#iso:std:iso-iec:22989:dis:ed-1:v1:amd:1:v1:en

[35] DataCamp Team, “Qu’est-ce que l’IA symbolique ?,” Datacamp, Nov. 2024. Accessed : Nov. 13, 2025. [Online]. Available : https://www.datacamp.com/fr/blog/what-is-symbolic-ai

[36] gnius, “Le secteur social et médico-social,” Jun. 2024. Accessed : Jan. 05, 2026. [Online]. Available : https://gnius.esante.gouv.fr/fr/secteur-social-medico-social#:~:text=Qu%27est%2Dce%20que%20le,de%20handicap%20ou%20de%20d%C3%A9pendance

[37] solidaire, “Social, médico-social.” Accessed : Sep. 29, 2025. [Online]. Available : https://www.solidaire-info.org/domaines/social-m%C3%A9dico-social

[38] "NF EN ISO 9000 - Systèmes de management de la qualité - Principes essentiels et vocabulaire", Ed. Afnor, Paris, www.afnor.org, Oct. 2015

[39] Service Public, “Télésanté : télémédecine (téléconsultation, télésurveillance...),” Jul. 2025. Accessed : Sep. 29, 2025. [Online]. Available : https://www.service-public.fr/particuliers/vosdroits/F34696

Annexes

Annexe 1 : Rapport d’enquête terrain

Annexe 2 : Justification du Système de Pondération

1.0 Intro­duc­tion : De la Sta­tique à la Dynamique

Les che­ck­lists régle­men­taires tra­di­tion­nelles pré­sentent une fai­blesse fon­da­men­tale : elles sont sta­tiques. Dans une telle approche, chaque exi­gence pos­sède un niveau d'importance fixe, qu'il soit faible, modé­ré ou cri­tique, indé­pen­dam­ment du dis­po­si­tif médi­cal (DM) éva­lué. Cette méthode est régle­men­tai­re­ment inco­hé­rente. Par exemple, une exi­gence de for­ma­tion des uti­li­sa­teurs serait jugée "MODÉRÉE" tant pour une appli­ca­tion de diag­nos­tic simple de Classe I que pour un pace­ma­ker de Classe III inté­grant une IA à haut risque. Or, l'effort requis pour un pace­ma­ker doit être consi­dé­ra­ble­ment plus élevé.

Pour résoudre cette inco­hé­rence, un sys­tème de pon­dé­ra­tion dyna­mique a été déve­lop­pé. Cette approche inno­vante adapte l'importance de chaque exi­gence au pro­fil de risque spé­ci­fique du dis­po­si­tif médi­cal. En sai­sis­sant quatre para­mètres clés, le sys­tème cal­cule un coef­fi­cient qui module le score de chaque point de la che­ck­list, la trans­for­mant d'un docu­ment géné­rique en un outil sur mesure.

2.0 Jus­ti­fi­ca­tion du Choix des Coef­fi­cients de Pondération

La défi­ni­tion de coef­fi­cients de pon­dé­ra­tion pré­cis est une étape stra­té­gique cru­ciale. Ces coef­fi­cients ont pour rôle de tra­duire le niveau de risque et la charge régle­men­taire asso­ciés à un dis­po­si­tif médi­cal en un mul­ti­pli­ca­teur quan­ti­fiable. C'est ce mul­ti­pli­ca­teur qui per­met d'ajuster dyna­mi­que­ment la rigueur atten­due pour chaque exi­gence de conformité.

Le pro­fil régle­men­taire d'un dis­po­si­tif médi­cal inté­grant une intel­li­gence arti­fi­cielle est défi­ni par quatre para­mètres clés, cha­cun agis­sant comme un fac­teur de complexité.

• Classe MDR du dis­po­si­tif : Le niveau de risque intrin­sèque pour le patient, selon le règle­ment 2017/745.
• Rôle de l'IA en tant que com­po­sante de sécu­ri­té : L'impact direct d'une défaillance de l'IA sur la sécu­ri­té du patient.
• Niveau d'autonomie du sys­tème : Le degré de super­vi­sion humaine requis pour le fonc­tion­ne­ment de l'IA.

Cha­cun de ces para­mètres se voit attri­buer un coef­fi­cient spé­ci­fique, dont la jus­ti­fi­ca­tion est détaillée ci-après.

2.1 Coef­fi­cient lié à la Classe MDR

Ce coef­fi­cient reflète le niveau de risque intrin­sèque du dis­po­si­tif pour le patient, tel que défi­ni par le Règle­ment sur les Dis­po­si­tifs Médi­caux (MDR 2017/745). La classe d'un DM déter­mine l'étendue de la docu­men­ta­tion tech­nique, la néces­si­té d'essais cli­niques et l'intensité de la sur­veillance post-commercialisation.

Option	Coef­fi­cient Attribué
Classe I	1.0
Classe IIa	1.5
Classe IIb	2.0
Classe III	3.0

Jus­ti­fi­ca­tion : La pro­gres­sion des coef­fi­cients (1.0 → 1.5 → 2.0 → 3.0) n'est pas linéaire, car elle modé­lise l'augmentation de la charge régle­men­taire. Le pas­sage de la Classe I à la Classe IIa repré­sente un saut d'effort signi­fi­ca­tif (+50%). Le pas­sage à la Classe IIb et enfin à la Classe III aug­mente encore cette charge, jus­ti­fiant des mul­ti­pli­ca­teurs plus éle­vés. Le coef­fi­cient 1.0 pour la Classe I sert de réfé­rence de base.

2.2 Coef­fi­cient lié au Rôle de l'IA comme Com­po­sante de Sécurité

Ce coef­fi­cient éva­lue si l'IA joue un rôle cri­tique dans la sécu­ri­té du dis­po­si­tif. Si une défaillance de l'IA peut direc­te­ment entraî­ner un pré­ju­dice pour le patient, la rigueur des tests et de la vali­da­tion doit être dras­ti­que­ment augmentée.

Option	Coef­fi­cient Attribué
Oui	2.0
Non	1.0

Jus­ti­fi­ca­tion : Le choix est binaire mais a un impact majeur. Si l'IA est une com­po­sante de sécu­ri­té (par exemple, elle contrôle l'administration d'un médi­ca­ment ou détecte des aryth­mies cri­tiques), sa fia­bi­li­té ne peut être com­pro­mise. Un dou­ble­ment de l'effort (coef­fi­cient 2.0) est donc jus­ti­fié pour reflé­ter cette exi­gence de rigueur maxi­male. Si l'IA n'est pas une com­po­sante de sécu­ri­té, aucune sur­charge n'est appli­quée (coef­fi­cient 1.0).

2.3 Coef­fi­cient lié au Niveau d'Autonomie du Système

Ce para­mètre, cen­tral dans les prin­cipes d'ingénierie de l'aptitude à l'utilisation (cf. NF EN 62366-1:2015+A1:2020), prend en compte le rôle de l'opérateur humain. Un sys­tème auto­nome, qui prend des déci­sions sans super­vi­sion humaine obli­ga­toire, pré­sente un pro­fil de risque plus éle­vé qu'un sys­tème d'assistance où un cli­ni­cien valide chaque recommandation.

Option	Coef­fi­cient Attribué
Auto­nome	1.5
Assis­tance / Déci­sion obligatoire	1.0

Jus­ti­fi­ca­tion : L'absence de super­vi­sion humaine obli­ga­toire sup­prime une ligne de défense essen­tielle. Le sys­tème doit donc être intrin­sè­que­ment plus robuste, trans­pa­rent et capable de gérer ses propres incer­ti­tudes. Cela requiert des méca­nismes d'alerte avan­cés et des limi­ta­tions des sor­ties aber­rantes, jus­ti­fiant une aug­men­ta­tion de 50 % de l'effort (coef­fi­cient 1.5). Un sys­tème d'assistance, où l'humain reste le déci­sion­naire final, ne néces­site pas cette sur­charge (coef­fi­cient 1.0).

2.4 Jus­ti­fi­ca­tion de l'Approche Multiplicative

Le choix stra­té­gique a été fait de mul­ti­plier ces quatre coef­fi­cients plu­tôt que de les addi­tion­ner. Cette approche reflète le fait que les fac­teurs de risque ne sont pas indé­pen­dants mais s'amplifient mutuel­le­ment. Une approche addi­tive sous-esti­me­rait gra­ve­ment la com­plexi­té régle­men­taire des dis­po­si­tifs les plus critiques.

Pre­nons l'exemple d'un dis­po­si­tif cumu­lant les plus hauts niveaux de risque : "Classe III + Com­po­sante Sécu + Autonome".

• Approche addi­tive : 3.0 + 2.0 + 1.5 = 6.5
• Approche mul­ti­pli­ca­tive : 3.0 × 2.0 × 1.5 = 9.0

Le résul­tat de 9.0 tra­duit fidè­le­ment le fait que la rigueur requise aug­mente de manière expo­nen­tielle. Un dis­po­si­tif de Classe III dont la sécu­ri­té dépend d'une IA auto­nome ne requiert pas sim­ple­ment une somme d'efforts, mais une inté­gra­tion com­plexe où chaque exi­gence est ampli­fiée par les autres. La docu­men­ta­tion MDR doit inté­grer la ges­tion des risques de l'IA, qui doit elle-même être vali­dée pour un fonc­tion­ne­ment auto­nome et sécu­ri­sé. La mul­ti­pli­ca­tion modé­lise cette inter­dé­pen­dance. De plus, cette approche a une fonc­tion péda­go­gique : elle contraint les fabri­cants à recon­naître que cer­taines com­bi­nai­sons de fac­teurs de risque sont expo­nen­tiel­le­ment plus exi­geantes, les inci­tant ain­si à réduire la com­plexi­té lorsque cela est pos­sible afin de maî­tri­ser la charge réglementaire.

En com­bi­nant ces quatre coef­fi­cients mul­ti­pli­ca­teurs, le sys­tème génère un Coef­fi­cient Glo­bal unique, allant de 1.0 à 9.0, qui repré­sente de manière holis­tique le pro­fil de risque et la charge régle­men­taire du dis­po­si­tif médical.

3.0 Méca­nisme de Cal­cul du Score Final

Le "Coef­fi­cient Glo­bal" est le moteur qui contex­tua­lise l'ensemble de la che­ck­list. Il est uti­li­sé pour modu­ler le score de chaque exi­gence indi­vi­duelle, trans­for­mant une éva­lua­tion de confor­mi­té sta­tique en une ana­lyse de risque dyna­mique. Ce méca­nisme consti­tue le cœur opé­ra­tion­nel du système.

3.1 Le Score Brut : Éva­lua­tion Intrin­sèque de l'Exigence

Avant toute contex­tua­li­sa­tion, chaque exi­gence régle­men­taire est d'abord éva­luée de manière intrin­sèque sur la base de quatre cri­tères fon­da­men­taux. Ces quatre cri­tères ont été stra­té­gi­que­ment choi­sis car ils consti­tuent les piliers de la confor­mi­té pour les DM inté­grant l'IA et repré­sentent un équi­libre opti­mal entre rigueur et faci­li­té d'utilisation :

1. Impact sur la sécu­ri­té à l’usage ou du risque d’erreur humaine ;
2. Impact sur la com­pré­hen­sion et l’interprétation de l’intelligence artificielle ;
3. Impact sur la super­vi­sion humaine ;
4. Impact sur la confor­mi­té régle­men­taire (AI Act/MDR) ; 

Le Score Brut est sim­ple­ment le nombre de cri­tères cochés pour une exi­gence don­née, résul­tant en une valeur de 0 à 4. Il repré­sente l'importance fon­da­men­tale de l'exigence, avant l'application du contexte spé­ci­fique au dispositif.

3.2 Le Score Final Pon­dé­ré : Appli­ca­tion du Contexte Réglementaire

Le Score Final est obte­nu en appli­quant le Coef­fi­cient Glo­bal au Score Brut. Cette opé­ra­tion simple mais puis­sante ajuste l'importance de chaque exi­gence en fonc­tion du pro­fil de risque glo­bal du DM.

La for­mule cen­trale du sys­tème est la suivante :

Score Final = Score Brut × Coef­fi­cient Global

Cette mul­ti­pli­ca­tion contex­tua­lise l'importance de l'exigence. Une exi­gence avec un Score Brut éle­vé (donc intrin­sè­que­ment impor­tante) aura une impor­tance finale très dif­fé­rente pour un dis­po­si­tif simple et pour un dis­po­si­tif critique.

Illus­tra­tion par l'exemple : Consi­dé­rons un pace­ma­ker auto­nome inté­grant une IA en com­po­sante de sécurité.

1. Cal­cul du Coef­fi­cient Glo­bal :
   • Classe MDR : III (→ 3.0)
   • Com­po­sante de Sécu­ri­té : Oui (→ 2.0)
   • Auto­no­mie : Auto­nome (→ 1.5)
   • Coef­fi­cient Glo­bal = 3.0 × 2.0 × 2.0 × 1.5 = 9.0
2. Déter­mi­na­tion du Score Brut :
   • Pour une exi­gence comme la "For­ma­tion des équipes", il est jus­ti­fiable de consi­dé­rer que les quatre cri­tères sont appli­cables : la for­ma­tion pré­vient les erreurs de sécu­ri­té, elle doit expli­quer le fonc­tion­ne­ment de l'IA (trans­pa­rence), elle couvre les modes de super­vi­sion, et elle doit être for­mel­le­ment docu­men­tée.
   • Score Brut = 4
3. Cal­cul du Score Final Pon­dé­ré :
   • Score Final = Score Brut × Coef­fi­cient Global
   • Score Final = 4 × 18.0 = 36.0

Ce Score Final, une valeur numé­rique pou­vant aller de 0 à 36, doit ensuite être inter­pré­té pour gui­der l'action. La sec­tion sui­vante détaille les seuils stra­té­giques uti­li­sés pour cette interprétation.

4.0 Jus­ti­fi­ca­tion du Choix des Seuils d'Importance

Un score numé­rique, bien que pré­cis, n'est pas direc­te­ment exploi­table. Il est néces­saire de le tra­duire en niveaux d'importance clairs et action­nables pour les équipes de confor­mi­té. Le choix des seuils qui opèrent cette tra­duc­tion est une déci­sion stra­té­gique qui condi­tionne la sen­si­bi­li­té, la per­ti­nence et l'utilité du système.

Trois niveaux d'importance ont été défi­nis pour clas­si­fier chaque exi­gence en fonc­tion de son Score Final.

Niveau d'Importance	Plage de Score	Inter­pré­ta­tion
FAIBLE (Exi­gence option­nelle ou allégée)	Score < 7	Effort mini­mal requis. L'exigence peut être vali­dée rapidement.
MODÉRÉE (Exi­gence standard)	Score 7-14	Effort stan­dard requis. L'exigence doit être trai­tée et docu­men­tée de manière com­plète, confor­mé­ment aux pro­cé­dures habituelles.
CRITIQUE (Exi­gence prioritaire)	Score > 14	Effort appro­fon­di requis. Cette exi­gence doit être trai­tée en prio­ri­té et faire l'objet d'une docu­men­ta­tion exhaustive.

4.1 Logique de Défi­ni­tion des Seuils 7 et 14

Le choix des valeurs 7 et 14 n'est pas arbi­traire. Il est le fruit d'une ana­lyse visant à défi­nir des points de rup­ture régle­men­taires significatifs.

• Jus­ti­fi­ca­tion du seuil de 7 : Le Score Final de 7 repré­sente le point de bas­cu­le­ment cri­tique où une exi­gence cesse d'être "gérable en arrière-plan" pour deve­nir "incon­tour­nable et for­ma­li­sée".  Un Score Brut modé­ré (2-3, exi­gence affec­tant 2-3 domaines clés) appli­qué à un dis­po­si­tif Classe IIa auto­nome (Coef­fi­cient ~ 2.5-3.0) → Score Final ≈ 6-9. Un Score Brut faible (1-2, exi­gence tech­nique ponc­tuelle) appli­qué à un dis­po­si­tif Classe III simple (Coef­fi­cient ~4-6) → Score Final ≈ 4-12. C’est le seuil ou la com­pliance passe de « faible » à impor­tante « stan­dard » (20% de la plage).
• Jus­ti­fi­ca­tion du seuil de 14 : Un Score Final de 14 repré­sente une conjonc­tion cri­tique entre risque intrin­sèque éle­vé et com­plexi­té dis­po­si­tif majeure. Le but était de cap­tu­rer le moment de pas­sage entre une exi­gence impor­tante à cri­tique pour le dis­po­si­tif (20% de la plage).

De plus, ces seuils ne sont pas de simples construc­tions mathé­ma­tiques ; ils s'ancrent dans des prin­cipes de ges­tion des risques éta­blis, tels que ceux que l'on retrouve dans la norme ISO 14971. Ils cor­res­pondent aux points de bas­cule où, his­to­ri­que­ment, le niveau de risque d'un dis­po­si­tif jus­ti­fie le pas­sage d'une docu­men­ta­tion allé­gée à des (seuil 12), puis à des docu­men­ta­tions consé­quentes (seuil 24).

Enfin, la plage "CRITIQUE" (> 14) couvre inten­tion­nel­le­ment une large por­tion de l'échelle (60 %). Ce choix est déli­bé­ré : il vise à signa­ler clai­re­ment qu'au-delà de ce point, toute exi­gence est hau­te­ment prio­ri­taire. Une sub­di­vi­sion sup­plé­men­taire (par exemple, "Très Cri­tique") n'apporterait pas de valeur déci­sion­nelle, car l'effort atten­du est déjà maximal.

Ces seuils, com­bi­nés au méca­nisme de cal­cul du score, per­mettent de trans­for­mer une simple che­ck­list en un véri­table outil d'aide à la déci­sion stra­té­gique, capable de gui­der et de hié­rar­chi­ser les efforts de mise en conformité.