Auteurs

Contacts

• KADIRI Hai­tam : haitam.kadiri07@gmail.com

Citation

KADIRI Hai­tam "IDS275- Éla­bo­ra­tion du Dos­sier Tech­nique d'un Dis­po­si­tif Médi­cal Logi­ciel selon le Règle­ment (UE) 2017/745 en vue de l'obtention du mar­quage CE", 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 fin d'étude, juillet 2025, https://travaux.master.utc.fr/formations-master/ingenierie-de-la-sante/ids275

Résumé

Le Règle­ment (UE) 2017/745 sur les dis­po­si­tifs médi­caux a pro­fon­dé­ment redé­fi­ni le cadre de mise sur le mar­ché, exi­geant des fabri­cants non seule­ment de démon­trer la confor­mi­té de leurs pro­duits, mais éga­le­ment de prou­ver la robus­tesse d'un sys­tème de mana­ge­ment de la qua­li­té garan­tis­sant une repro­duc­tion conti­nue et sécu­ri­sée de leurs dis­po­si­tifs. Cette com­plexi­té accrue, notam­ment pour les dis­po­si­tifs médi­caux logi­ciels, se heurte sou­vent aux métho­do­lo­gies de déve­lop­pe­ment agiles.
Ce rap­port d'alternance vise à illus­trer cette dyna­mique au sein de l'entreprise RESIP. Il détaille la contri­bu­tion à l'élaboration du dos­sier tech­nique des dis­po­si­tifs médi­caux logi­ciels de l’entreprise et les acti­vi­tés annexes menées en paral­lèle, sou­li­gnant l'interdépendance entre le cycle de vie du déve­lop­pe­ment logi­ciel et la rigueur de la docu­men­ta­tion régle­men­taire. Il explore éga­le­ment les défis spé­ci­fiques aux­quels sont confron­tés les concep­teurs de logi­ciels face à ces exi­gences, offrant une pers­pec­tive sur les stra­té­gies à adop­ter pour navi­guer avec suc­cès dans cet envi­ron­ne­ment exigeant.

Abstract

Regu­la­tion (EU) 2017/745 on medi­cal devices has pro­found­ly resha­ped the fra­me­work for mar­ket access, requi­ring manu­fac­tu­rers not only to demons­trate the com­pliance of their pro­ducts but also to prove the robust­ness of a qua­li­ty mana­ge­ment sys­tem that ensures the consistent and safe repro­duc­tion of their devices. This increa­sed com­plexi­ty, par­ti­cu­lar­ly for soft­ware as medi­cal devices, often clashes with agile deve­lop­ment methodologies.

This inter­n­ship report aims to illus­trate this dyna­mic within the com­pa­ny RESIP. It details the contri­bu­tion to the pre­pa­ra­tion of the tech­ni­cal docu­men­ta­tion for the company’s medi­cal device soft­ware and the rela­ted acti­vi­ties conduc­ted in paral­lel, high­ligh­ting the inter­de­pen­dence bet­ween the soft­ware deve­lop­ment life­cycle and the strict­ness of regu­la­to­ry docu­men­ta­tion. It also explores the spe­ci­fic chal­lenges faced by soft­ware deve­lo­pers in mee­ting these requi­re­ments, offe­ring insights into stra­te­gies for suc­cess­ful­ly navi­ga­ting this deman­ding environment.

Remerciements

La rédac­tion d'un rap­port ne requiert pas néces­sai­re­ment des remer­cie­ments, mais si nous expri­mons notre gra­ti­tude envers cer­taines per­sonnes, c'est parce qu'elles le méritent.
Avant tout, je tiens à expri­mer ma gra­ti­tude à Dieu, qui m'a accor­dé le cou­rage et la force néces­saires pour mener à bien ce pro­jet de mas­ter.
Je tiens à expri­mer ma pro­fonde gra­ti­tude à toute l'équipe de RESIP pour l'accueil cha­leu­reux et le sou­tien constant durant mon alter­nance. Leur dyna­misme et leur exper­tise ont été une source d'inspiration tout au long de cette expé­rience.
Je remer­cie par­ti­cu­liè­re­ment ma tutrice Mme. AIT HAMMOU Btis­sam, pour sa dis­po­ni­bi­li­té, sa patience, et ses pré­cieux retours, conseils, qui m'ont per­mis d'acquérir des com­pé­tences essen­tielles et de mener à bien les mis­sions qui m'ont été confiées.
Je remer­cie éga­le­ment l’ensemble de l’équipe avec laquelle j’ai eu le plai­sir de col­la­bo­rer, en par­ti­cu­lier Mme. VIEYRA-GAKOSSO Pamé­la et Mme. THONG Cécile pour leur pré­sence, leur sou­tien et leur pro­fes­sion­na­lisme. Leur atti­tude bien­veillante et sti­mu­lante m’a beau­coup aidé à gar­der mon enthou­siasme, à nour­rir mon envie d’apprendre, et à me dépas­ser tout au long de cette expé­rience.
Je remer­cie tout par­ti­cu­liè­re­ment Mme. CLAUDE Isa­belle et M. Jean Mat­thieu PROT, mes enca­drants à l’UTC, pour leur sui­vi rigou­reux, leurs conseils avi­sés et leur dis­po­ni­bi­li­té constante tout au long de l’année. Leur super­vi­sion a été essen­tielle pour mener ce tra­vail à bien.
Enfin, à toutes les per­sonnes ayant contri­bué de près ou de loin à l'accomplissement de ce tra­vail, j'exprime ma sin­cère recon­nais­sance. Votre enga­ge­ment et votre col­la­bo­ra­tion ont été essen­tiels à la réa­li­sa­tion de ce pro­jet de fin d’études.

Liste des abréviations

AMM : Auto­ri­sa­tion de Mise sur le Mar­ché
API : Appli­ca­tion pro­gram­ming inter­face/ Inter­face de pro­gram­ma­tion des appli­ca­tions
ALM : Appli­ca­tion Life­cycle Mana­ge­ment
ASK : Axial Spon­dy­loar­thri­tis Know­ledge
axS­pA : spon­dy­lar­thrite axiale
BCB : Base de don­nées Claude Ber­nard
CAPA : Cor­rec­tive and Pre­ven­tive Action
CNDA : Centre Natio­nal de Dépôt et d'Agrément
DM : Dis­po­si­tif médi­cal
EGSP :  Exi­gences Géné­rales de Sécu­ri­té et de Per­for­mance
jFSE : Feuille de soin élec­tro­nique 
LAD : Logi­ciel d’aide à la dis­pen­sa­tion
LAP : Logi­ciel d’aide à la pres­crip­tion
MDR : Medi­cal Device Regu­la­tion
QARA : Qua­li­té et Affaires Régle­men­taires
SAMD : Soft­ware as a Medi­cal Device
SCM : Soft­ware Confi­gu­ra­tion Mana­ge­ment
SDLC : Soft­ware Deve­lop­ment Life Cycle
SRS : Soft­ware Requi­re­ment Spe­ci­fi­ca­tionURS : User Requi­re­ment Specification

Liste des Figures

Figure 1 : Logo Cege­dim
Figure 2 : Logo de RESIP
Figure 3 : Dif­fé­rentes solu­tions de RESIP
Figure 4 : Orga­ni­gramme de RESIP
Figure 5 : Pro­ces­sus de rédac­tion et de ges­tion du dos­sier tech­nique d’un DM logi­ciel
Figure 6 : Clas­si­fi­ca­tion des DM logi­ciels selon le Règle­ment (UE) 2017/745 (MDR), Annexe VIII, Chap­ter III, Régle 11
Figure 7 : Cycle de Vie du Déve­lop­pe­ment d'un dis­po­si­tif médi­cal logiciel

Élaboration du Dossier Technique d'un Dispositif Médical Logiciel selon le Règlement (UE) 2017/745 en vue de l'obtention du marquage CE

Introduction

L'intégration crois­sante du numé­rique dans le domaine de la san­té fait des dis­po­si­tifs médi­caux logi­ciels des outils d'une impor­tance capi­tale. Mon alter­nance chez RESIP m'a offert une immer­sion pri­vi­lé­giée au cœur de ce sec­teur en pleine évo­lu­tion, où l’innovation et la confor­mi­té régle­men­taire sont indissociables.

 Le pre­mier cha­pitre est dédié à la pré­sen­ta­tion de RESI, ses acti­vi­tés prin­ci­pales, ses pro­duits et sa posi­tion stra­té­gique sur le mar­ché des logi­ciels de san­té. La com­pré­hen­sion de cet envi­ron­ne­ment était pri­mor­diale pour sai­sir les enjeux de mes res­pon­sa­bi­li­tés quotidiennes.

  Le cœur de ma contri­bu­tion est ensuite détaillé dans le deuxième cha­pitre. Où je détaille les diverses mis­sions qui m'ont été confiées en tant qu'alternant, avec un accent par­ti­cu­lier sur mon rôle dans la rédac­tion des dos­siers tech­niques pour les dif­fé­rents logi­ciels déve­lop­pés par RESIP.

 Ces expé­riences ont natu­rel­le­ment mené à une ana­lyse plus appro­fon­die des défis fon­da­men­taux qui carac­té­risent le déve­lop­pe­ment des SaMDs face au Règle­ment (UE) 2017/745 (MDR), sujet du troi­sième cha­pitre, qui ana­ly­se­ra les obs­tacles iden­ti­fiés, notam­ment à tra­vers ma propre expé­rience et les ensei­gne­ments tirés de la lit­té­ra­ture spé­cia­li­sée, et pro­po­se­ra des stra­té­gies pour har­mo­ni­ser les pra­tiques de déve­lop­pe­ment logi­ciel avec les impé­ra­tifs de la confor­mi­té, démon­trant ain­si la com­plexi­té et l'importance de ce domaine pour l'avenir de la santé.

Chapitre 1 : Présentation de l’organisme d’accueil

INTRODUCTION

Dans ce pre­mier cha­pitre, je vous invite à décou­vrir RESIP filiale de Cege­dim san­té, l'entreprise où j'ai eu l'opportunité d'effectuer mon alter­nance. RESIP est une orga­ni­sa­tion dédiée à l'innovation et à l'amélioration des soins de san­té. Plus qu'une entre­prise, elle repré­sente une com­mu­nau­té de pro­fes­sion­nels pas­sion­nés qui tra­vaillent ensemble pour trans­for­mer la méde­cine et offrir des solu­tions de san­té de pointe.

1.1 Présentation générale du groupe Cegedim

Fon­dé en 1969, Cege­dim est un groupe inno­vant de tech­no­lo­gies et de ser­vices spé­cia­li­sé dans la ges­tion des flux numé­riques de l’écosystème san­té et BtoB, ain­si que dans la concep­tion de logi­ciels métiers des­ti­nés aux pro­fes­sion­nels de san­té et de l’assurance [1].

L’entreprise compte plus de 6 500 col­la­bo­ra­teurs. Elle a réa­li­sé, en 2023, un chiffre d’affaires de plus de 616 mil­lions d’euros.

Le Groupe Cege­dim pro­pose une large gamme de solu­tions et de ser­vices inno­vants à des­ti­na­tion des pro­fes­sion­nels de san­té, des cher­cheurs, des entre­prises et auto­ri­tés de san­té, des com­pa­gnies d’assurance et des entre­prises de tous sec­teurs inté­res­sés par les pro­blé­ma­tiques d’externalisation, d’hébergement sécu­ri­sé et d’échanges dématérialisés.

Cege­dim est un des lea­ders dans cha­cun de ses sec­teurs d’activité.

RESIP fait par­tie de Cege­dim San­té, orga­ni­sa­tion dédiée aux pro­fes­sion­nels de San­té et leurs patients.

Figure 1 : Logo de Cegedim.

En France : Cege­dim San­té couvre l’ensemble des marques dédiées à l’accompagnement des pro­fes­sion­nels de san­té et de leurs patients : Cege­dim san­té, Smar­tRx et RESIP [1].

A l'international : Cege­dim San­té Solu­tions est éga­le­ment pré­sent à tra­vers dif­fé­rentes enti­tés au Royaume-Uni, en Espagne et au Chi­li, en Rou­ma­nie, en Bel­gique et en Italie.

Au fil des années, le groupe s’est déve­lop­pé sur son métier de base en diver­si­fiant les pres­ta­tions four­nies et s’est inté­res­sé à des métiers connexes, où il pou­vait tirer par­ti de son savoir-faire. Ain­si, dès 1974, est née l’activité Mar­ke­ting direct, bien­tôt sui­vie par les acti­vi­tés infor­ma­tiques, ges­tion et Internet.

Depuis le début des années 1990, ayant la maî­trise de son mar­ché en France, le groupe a enta­mé une acti­vi­té d’internationalisation, qui l’emmène aujourd’hui à être pré­sent dans près de 20 pays en Europe et en Amé­rique. En 1995, CEGEDIM est entré au second mar­ché de la bourse de Paris.

En 2007, Cege­dim acquiert son concur­rent amé­ri­cain Den­drite, qui consti­tue de sa nou­velle uni­té Cegedim-Dendrite.

En 2010, Cege­dim Den­drite prend le nom de Cege­dim Rela­tion­ship Mana­ge­ment (CRM) ; dans le même temps le logo du groupe change pour l'ensemble des enti­tés majeures.

En Avril 2015 la socié­té IMS Health rachette 50 % des acti­vi­tés de Cege­dim, soit toute la divi­sion « CRM et don­nées stra­té­giques » et les ser­vices infor­ma­tiques. En novembre 2016, Cege­dim fait l'acquisition de Futu­ra­me­dia Group, lea­der fran­çais de l'affichage digi­tal en pharmacie,

En 2021/ 2022, Cege­dim fait de nou­velles acqui­si­tions : Medi­must, Mon­Doc­teur, Clinitix.

1.2 Définition et classification des dispositif médicaux logiciels

La socié­té RESIP a été créée en 1985 afin d'assurer la dif­fu­sion d'un pro­jet de base de don­nées sur les médi­ca­ments née deux ans plus tôt à la facul­té de méde­cine Claude Ber­nard de Lyon [2].

Depuis son ori­gine, l'activité prin­ci­pale de la socié­té RESIP est de mettre à dis­po­si­tion des pro­fes­sion­nels de san­té (phar­ma­ciens, méde­cins, den­tistes, para­mé­di­caux, gros­sistes répar­ti­teurs, éta­blis­se­ments de san­té : cli­niques, hôpi­taux, mai­sons de retraite) une base de don­nées scien­ti­fiques d'aide à la sécu­ri­sa­tion des pres­crip­tions et des dis­pen­sa­tions : la Base Claude Ber­nard. Cette acti­vi­té repré­sente un peu plus de 90% du chiffre d'affaires de RESIP.

Filiale du groupe CEGEDIM, depuis décembre 2000. RESIP compte plus de 60 col­la­bo­ra­teurs répar­tis sur 3 sites : Bou­logne sur mer pour la par­tie R&D et admi­nis­tra­tive, Rodez (FSE) et un autre site à Bou­logne Billan­court dédié à l'équipe scien­ti­fique, qua­li­té et commerciale.

RESIP a le rôle de fabri­cant de dis­po­si­tifs médi­caux de type logi­ciels, ces der­niers sont com­mer­cia­li­sés auprès des édi­teurs de logi­ciels médi­caux pour per­mettre l’utilisation de la Base Claude Ber­nard en l’intégrant au logi­ciel métier du pro­fes­sion­nel de santé.

Pour cela RESIP dis­pose prin­ci­pa­le­ment d'une acti­vi­té de déve­lop­pe­ment et de mise à jour des don­nées scientifiques.

Figure 2 : Logo de RESIP.

RESIP est aus­si édi­teur d'un moteur de fac­tu­ra­tion répon­dant au cahier des charges Sesam-Vitale appe­lé jFSE et com­mer­cia­li­sé aux édi­teurs de logi­ciels médi­caux pour assu­rer la par­tie règle­men­taire liée à la lec­ture d'une Carte Vitale d'un patient jusqu'à l'envoi des feuilles de soins élec­tro­niques. Ce moteur est sou­mis à l'obtention d'un agré­ment natio­nal déli­vré par le CNDA (Centre Natio­nal de Dépôt et d'Agrément).

De par son acti­vi­té, la socié­té RESIP dis­tingue quatre types de clients :

Les clients « Edi­teurs » : auprès des­quelles assure une pres­ta­tion de four­nis­seurs de don­nées sur les médi­ca­ments en leur pro­po­sant la Base Claude Ber­nard à inté­grer dans leur appli­ca­tion métier par le biais d'API (Appli­ca­tion Pro­gram­ming Inter­face) ou de four­nis­seur du module jFSE pour une inté­gra­tion au sein de leurs logi­ciels de ges­tion. RESIP signe un contrat d'intégration et de dif­fu­sion avec chaque édi­teur de logiciel.

Les clients « Abon­nés » : qui peuvent être phar­ma­ciens, méde­cins, den­tistes, para­mé­di­caux ou éta­blis­se­ments de san­té (cli­niques, hôpi­taux ou mai­sons de retraite) avec les­quels RESIP peut avoir un lien direct, ne serait-ce que pour l'envoi des mises à jour men­suelles de la BCB ou par l'intermédiaire de leur édi­teur de logi­ciel. La sous­crip­tion d'un abon­ne­ment à la BCB entraîne la signa­ture d'une licence d'utilisation entre RESIP et l'utilisateur final.

Les labo­ra­toires phar­ma­ceu­tiques : auprès des quels RESIP assure une pres­ta­tion de mise à jour des don­nées AMM des pro­duits de santé.

Autres : Gros­sistes répar­ti­teurs : ce sont des acti­vi­tés de sous-trai­tance de pro­duc­tion de bases de don­nées pro­duits qui ne sont pas cou­vertes par la norme ISO 13485 car elles sont indé­pen­dantes et sans inter­ac­tion avec les acti­vi­tés de la BCB.

Le sché­ma ci-des­sous détaille les dif­fé­rentes solu­tions de RESIP concer­nant la méde­cine de ville, les éta­blis­se­ments de soins, les offi­cines et le grand public [3]:

Figure 3 : Différentes solutions de RESIP.

1.2.1 Organigramme de RESIP

Cet orga­ni­gramme pré­sente la struc­ture orga­ni­sa­tion­nelle de RESIP. Il met en évi­dence les dif­fé­rentes direc­tions, les ser­vices asso­ciés et les res­pon­sables de chaque dépar­te­ment, ain­si que les équipes qui les com­posent. Cette orga­ni­sa­tion reflète une répar­ti­tion claire des res­pon­sa­bi­li­tés, faci­li­tant la coor­di­na­tion entre les domaines clés tels que la recherche et déve­lop­pe­ment, la qua­li­té, la régle­men­ta­tion, le mar­ke­ting, et les ser­vices clients.

Figure 4 : Organigramme de RESIP.

1.3 Présentation du service qualité et affaires réglementaires

RESIP pro­pose des solu­tions inno­vantes dans le domaine des logi­ciels de san­té, par­ti­cu­liè­re­ment adap­tées au sec­teur médi­cal. Le ser­vice Qua­li­té et Affaires Régle­men­taires s’assure que ces pro­duits répondent aux stan­dards de sécu­ri­té, d’efficacité et de qua­li­té, afin de garan­tir leur uti­li­sa­tion opti­male par les pro­fes­sion­nels de san­té et de ren­for­cer la confiance des utilisateurs.

Ain­si, le ser­vice Qua­li­té et Affaires Régle­men­taires de RESIP consti­tue une pièce maî­tresse dans la stra­té­gie glo­bale de l’entreprise, veillant à conju­guer inno­va­tion et confor­mi­té pour répondre aux attentes des patients et des pro­fes­sion­nels de santé.

1.3.1 Présentation de l’équipe qualité et affaires réglementaires 

Le ser­vice QARA se com­pose d’une équipe mul­ti­dis­ci­pli­naire dédiée à la ges­tion et au main­tien des exi­gences régle­men­taires et des stan­dards qualité :

Un Alter­nant Char­gé Qua­li­té et Affaires Régle­men­taires : rôle que j’occupe, par­ti­ci­pant acti­ve­ment aux mis­sions du ser­vice et contri­buant à la ges­tion des pro­jets qua­li­té et régle­men­taires. avec d'autres dis­po­si­tifs, et la sécu­ri­té des logi­ciels. Elles imposent éga­le­ment des normes pré­cises concer­nant l'étiquetage et les ins­truc­tions d'utilisation. Chaque élé­ment contri­bue à assu­rer que les dis­po­si­tifs médi­caux répondent aux attentes des uti­li­sa­teurs tout en pro­té­geant la san­té et la sécu­ri­té des patients (voir Figure 5).

Un Res­pon­sable Qua­li­té et Affaires Régle­men­taires : char­gé de super­vi­ser l’ensemble des acti­vi­tés du ser­vice et de veiller à la mise en œuvre des poli­tiques qualité.

Une Cheffe de pro­jet QARA : qui joue un rôle cen­tral dans l’application des pro­ces­sus qua­li­té, en assu­rant leur confor­mi­té avec les normes en vigueur.

Une Sta­giaire Phar­ma­cienne : qui sou­tient les pro­jets en cours en appor­tant une aide opé­ra­tion­nelle sur les sujets régle­men­taires et qualité.

1.3.2 Mission du service

Le ser­vice Qua­li­té et Affaires Régle­men­taires assure plu­sieurs mis­sions essentielles :

Sup­port régle­men­taire aux équipes de déve­lop­pe­ment : Accom­pa­gner les équipes tech­niques et com­mer­ciales dans la concep­tion de pro­duits conformes aux exi­gences du mar­ché et des clients.

Veille régle­men­taire et nor­ma­tive : Iden­ti­fier et ana­ly­ser les évo­lu­tions légis­la­tives et régle­men­taires appli­cables aux dis­po­si­tifs médi­caux, en par­ti­cu­lier ceux pro­po­sés par RESIP, afin d'assurer leur confor­mi­té en continu.

Ges­tion du sys­tème de mana­ge­ment de la qua­li­té (SMQ) : Mettre en place, sur­veiller et amé­lio­rer les pro­ces­sus internes pour garan­tir une qua­li­té opti­male des pro­duits et ser­vices, confor­mé­ment à des normes telles que la norme ISO 13485.

Éva­lua­tion et cer­ti­fi­ca­tion des pro­duits : Pré­pa­rer les dos­siers tech­niques néces­saires à l'obtention des cer­ti­fi­ca­tions, comme le mar­quage CE, et col­la­bo­rer avec des orga­nismes notifiés.

Ges­tion des non-confor­mi­tés et audits : Iden­ti­fier les écarts, pro­po­ser des actions cor­rec­tives et par­ti­ci­per aux audits internes et externes pour garan­tir la confor­mi­té aux exi­gences qualité.

1.3.3  Présentation des produits en lien avec mes missions        

1.3.3.1 BCB médecin CTREE           

Le dis­po­si­tif médi­cal « BCB méde­cin CTREE » est une API inté­grée par un édi­teur à un LAP/LAD et qui se pré­sente sous la forme d’une biblio­thèque de fonc­tions (DLL-Dyna­mic Link Libra­ry) qui per­met d’accéder à l’ensemble des don­nées dis­po­nibles au sein de la base de don­nées médi­ca­men­teuses Claude Bernard.

 Son rôle est d’assister les pro­fes­sion­nels de san­té habi­li­tés à pres­crire ou à dis­pen­ser des médi­ca­ments dans la sécu­ri­sa­tion des pres­crip­tions et des dis­pen­sa­tions. Elle per­met de véri­fier les inter­ac­tions médi­ca­men­teuses, les doses appro­priées, les contre-indi­ca­tions spé­ci­fiques, aller­gies, inter­ac­tions phy­si­co-chi­miques ain­si que les pré­cau­tions d'emploi, contri­buant ain­si à une meilleure pré­ven­tion des erreurs médi­ca­men­teuses et à la sécu­ri­té des patients.e unique doit ensuite être appo­sé, sous forme de code-barres, sur l’étiquette du dis­po­si­tif ou sur son embal­lage [2].

1.3.3.2 Aperçu des missions réalisées liées à la BCB médecin CTREE           

Dans le cadre de ce pro­jet, mon tra­vail s’est concen­tré sur plu­sieurs aspects essen­tiels en tant qu’alternant char­gé Qua­li­té et Affaires Réglementaires.

En effet, le dis­po­si­tif médi­cal étant un Lega­cy Device clas­sé en classe I sous l’ancienne direc­tive euro­péenne 93/42/CEE, il a dû être reclas­sé en classe IIb pour se confor­mer à la nou­velle régle­men­ta­tion MDR 2017/745. Cette tran­si­tion néces­site un mar­quage CE et une cer­ti­fi­ca­tion pour pou­voir conti­nuer à être commercialisé.

Mes prin­ci­pales contri­bu­tions ont été les suivantes :

• Par­ti­ci­pa­tion à la pré­pa­ra­tion du dos­sier tech­nique : Par­ti­ci­pa­tion à la rédac­tion et mise à jour des docu­ments liés aux spé­ci­fi­ca­tions logi­cielles (SRS : Soft­ware Requi­re­ment Spe­ci­fi­ca­tion, URS : User Requi­re­ment Specification).
• Ges­tion de la tra­ça­bi­li­té : Mise en place d’une matrice de tra­ça­bi­li­té entre les spé­ci­fi­ca­tions logi­cielles et les tests réa­li­sés pour démon­trer la confor­mi­té aux exi­gences de sécu­ri­té et de performance.
• Ges­tion des risques : Contri­bu­tion à l’identification, à l’évaluation, et à la rédac­tion des risques dans la matrice de risques, ain­si qu’à la défi­ni­tion et au sui­vi des actions de mitigation.
• Éva­lua­tion de la confor­mi­té : Véri­fi­ca­tion de la confor­mi­té de cer­tains points du dos­sier tech­nique pour s’assurer que les exi­gences régle­men­taires étaient bien respectées.

1.3.3.3 Axial Spondyloarthritis Knowledge

Le dis­po­si­tif médi­cal « ASK » (Axial Spon­dy­loar­thri­tis Know­ledge) est un logi­ciel récem­ment déve­lop­pé par RESIP. Il est uti­li­sé en inté­gra­tion par un édi­teur de logi­ciel de ges­tion de cabi­net médi­cal ayant pour objec­tif d’apporter aux méde­cins géné­ra­listes de ville une aide au dépis­tage de la spon­dy­lar­thrite axiale (axS­pA) chez l’adulte.

Lors d’une consul­ta­tion pour rachi­al­gie, ASK iden­ti­fie les patients adultes pré­sen­tant une rachi­al­gie chro­nique, ain­si qu’un tableau cli­nique évo­ca­teur d’une axS­pA, en se basant sur les don­nées conte­nues dans le dos­sier patient, et ce :

En signa­lant les patients adultes pré­sen­tant un mal de doschro­nique ayant débu­té avant l’âge de 45 ans.

En pro­po­sant une éva­lua­tion com­plé­men­taire de ces patients.

En faci­li­tant la pres­crip­tion d’analyses com­plé­men­taires et/ou l’orientation rapide de ces patients pour une consul­ta­tion spé­cia­li­sée avec un méde­cin rhumatologue.

1.3.3.4 Aperçu des missions liées à ASK 

Il s’agit d’un dis­po­si­tif médi­cal logi­ciel de classe IIb. Pour ce dis­po­si­tif, nous avons enta­mé la pré­pa­ra­tion de son dos­sier tech­nique afin de le sou­mettre à l’organisme noti­fié pour l’obtention du mar­quage CE.

Mes mis­sions liées à ce logi­ciel incluent :

• Par­ti­ci­pa­tion à rédac­tion des spé­ci­fi­ca­tions logi­cielles : URS et SRS
• La ges­tion des risques : notam­ment la contri­bu­tion à la créa­tion et à la mise à jour de la matrice ges­tion des risques pour iden­ti­fier, éva­luer et miti­ger les risques associés.
• La contri­bu­tion dans la ges­tion des tests : confi­gu­ra­tion de l’environnement JIRA, en col­la­bo­ra­tion avec les équipes pro­duit. Cet outil per­met de tra­cer et de gérer effi­ca­ce­ment les tests effec­tués sur le logi­ciel, tout en garan­tis­sant une tra­ça­bi­li­té com­plète et une éva­lua­tion pré­cise de l’adéquation des tests avec les fonc­tion­na­li­tés spé­ci­fiées du logiciel.

CONCLUSION

Grâce à son exper­tise et à son enga­ge­ment envers la qua­li­té et la confor­mi­té régle­men­taire, l’entreprise pro­pose des pro­duits per­for­mants, tels que la base de don­nées Médi­ca­ments Claude Ber­nard (BCB) et le logi­ciel ASK, qui contri­buent à la sécu­ri­té des patients et à l’amélioration des pra­tiques médi­cales. Par ses efforts constants en recherche et déve­lop­pe­ment, ain­si que son approche rigou­reuse en matière de cer­ti­fi­ca­tion et de sup­port, RESIP assure une uti­li­sa­tion opti­male de ses solu­tions, répon­dant aux exi­gences des mar­chés natio­naux et internationaux.

Chapitre 2 : Mission représentative et activités réalisées chez RESIP

2.1 Contexte de la mission

L’objectif prin­ci­pal était de garan­tir la confor­mi­té docu­men­taire régle­men­taire du pro­duit logi­ciel, en consti­tuant un dos­sier tech­nique struc­tu­ré, tra­çable, vali­dé et archi­vé, tout en assu­rant une par­faite cohé­rence entre les exi­gences régle­men­taires, les pra­tiques internes, et les contraintes tech­niques propres aux produits.

Ce tra­vail s’inscrit dans une démarche de mise en confor­mi­té régle­men­taire pour deux dis­po­si­tifs médi­caux logi­ciels dif­fé­rents, ce qui m’a per­mis de trai­ter une grande varié­té de docu­ments tech­niques, de pro­cé­dures internes, et d’exigences nor­ma­tives, dans un cadre concret et exi­geant, en col­la­bo­ra­tion avec de nom­breuses équipes : pro­duit, déve­lop­pe­ment, qua­li­té et affaires réglementaires.

2.2 Qu’est-ce qu’un dossier technique pour un DM logiciel

Le dos­sier tech­nique d’un dis­po­si­tif médi­cal logi­ciel est un ensemble struc­tu­ré de docu­ments exi­gés par les orga­nismes noti­fiés et les auto­ri­tés de san­té. Il a pour but de démon­trer que le logi­ciel répond aux exi­gences essen­tielles en matière de sécu­ri­té, de per­for­mance, de qua­li­té, de ges­tion des risques, de véri­fi­ca­tion et de vali­da­tion. Il consti­tue en quelque sorte la preuve docu­men­taire que le logi­ciel est sûr et effi­cace, et qu’il peut être com­mer­cia­li­sé dans l’Union européenne.

Le conte­nu de ce dos­sier est défi­ni dans l’annexe II du règle­ment MDR, com­plé­tée par les recom­man­da­tions des guides MDCG et les normes ISO / IEC appli­cables (ex : ISO 13485, IEC 62304, ISO 14971). Pour les logi­ciels, la norme IEC 62304 joue un rôle fon­da­men­tal car elle encadre le cycle de vie du logi­ciel médical.

2.2.1 Composition typique du dossier technique

Le dos­sier tech­nique d’un dis­po­si­tif médi­cal logi­ciel est consti­tué d’un ensemble struc­tu­ré de docu­ments cou­vrant l’ensemble des aspects régle­men­taires, qua­li­té, déve­lop­pe­ment, vali­da­tion, ges­tion des risques et post-market.

Voi­ci la liste des docu­ments géné­ra­le­ment exi­gés pour consti­tuer un tel dossier.

• Docu­ment d’algorithme : décrit de manière pré­cise les règles logiques ou médi­cales implé­men­tées dans le logi­ciel, avec des sché­mas expli­ca­tifs si nécessaire.

• Matrice de risque : tableau réca­pi­tu­la­tif de l’analyse des risques iden­ti­fiés, éva­lués selon leur gra­vi­té et leur pro­ba­bi­li­té, avec les mesures de maî­trise associées.

• Liste des SOUP (Soft­ware of Unk­nown Pro­ve­nance) : Docu­ment lis­tant l’ensemble des com­po­sants logi­ciels tiers (biblio­thèques, fra­me­works, outils) uti­li­sés dans le logi­ciel et qui ne sont pas déve­lop­pés en interne, et dont le cycle de vie n’est pas maîtrisé.

• Liste des SRS (Soft­ware Requi­re­ments Spe­ci­fi­ca­tions) : ensemble des exi­gences logi­cielles fonc­tion­nelles et non fonctionnelles.

• Liste des URS (User Requi­re­ments Spe­ci­fi­ca­tions) : ensemble des exi­gences expri­mées du point de vue de l’utilisateur ou du client.

• Plan de test de véri­fi­ca­tion : stra­té­gie mise en œuvre pour véri­fier que le logi­ciel res­pecte les spé­ci­fi­ca­tions SRS.

• Des­crip­tion des tests de véri­fi­ca­tion : scé­na­rios et cas de tests détaillés.

• Rap­port de test de véri­fi­ca­tion : résul­tats de l’exécution des tests et ana­lyse des écarts.

• Plan de test de vali­da­tion : stra­té­gie visant à confir­mer que le logi­ciel répond bien aux besoins utilisateur.
• Des­crip­tion des tests de vali­da­tion : cas de vali­da­tion en condi­tion d’usage simu­lée ou réelle.

• Rap­port de test de vali­da­tion : syn­thèse des résul­tats de vali­da­tion et confor­mi­té aux URS.

• Ins­truc­tions d’accès au manuel d’utilisation : pro­cé­dure pour garan­tir l’accessibilité de la docu­men­ta­tion utilisateur.

• Che­ck­list EIFU : véri­fi­ca­tion de la confor­mi­té de l'information élec­tro­nique pour l'utilisateur (Elec­tro­nic Ins­truc­tions For Use).

• Plan de déve­lop­pe­ment logi­ciel : décrit l’organisation géné­rale du déve­lop­pe­ment du logi­ciel selon IEC 62304.

• Ration­nel de clas­si­fi­ca­tion : jus­ti­fi­ca­tion du niveau de classe du dis­po­si­tif selon les règles du MDR.

• Plan de ges­tion des risques : pla­ni­fi­ca­tion des méthodes et res­pon­sa­bi­li­tés liées à l’analyse des risques.

• Rap­port de ges­tion des risques : syn­thèse finale des risques rési­duels acceptables.

• Manuel d’utilisation : guide com­plet à des­ti­na­tion de l’utilisateur final pour une uti­li­sa­tion sécu­ri­sée du logiciel.

• Quick User Guide : ver­sion conden­sée du manuel avec les infor­ma­tions essentielles.

• Plan d’évaluation cli­nique : stra­té­gie pour col­lec­ter et ana­ly­ser les don­nées cli­niques démon­trant la per­for­mance et la sécurité.

• Rap­port d’évaluation cli­nique : résul­tats détaillés de l’analyse clinique.

• Cahier de dos­sier tech­nique : registre prin­ci­pal lis­tant tous les docu­ments consti­tu­tifs du dos­sier tech­nique, avec leurs ver­sions et statuts.

• Docu­ments d’évaluation som­ma­tive et for­ma­tive : docu­men­ta­tion spé­ci­fique aux exi­gences d’ergonomie et d’utilisabilité.

• Guide d’intégration : docu­ment décri­vant com­ment le logi­ciel s’intègre dans son envi­ron­ne­ment cible (sys­tème d’information, maté­riel, etc.).

• Docu­ment d’architecture logi­cielle : struc­ture logique et modu­laire du logi­ciel (com­po­sants, inter­ac­tions, dépendances).

• Matrice de tra­ça­bi­li­té : lien entre les exi­gences (URS/SRS), les risques et les tests, pour démon­trer la cou­ver­ture com­plète du produit.

• Plan PMS (Post-Mar­ket Sur­veillance) : stra­té­gie de sur­veillance du pro­duit une fois mis sur le marché.
• Plan SCAC (Sui­vi Cli­nique Après Com­mer­cia­li­sa­tion : dis­po­si­tif pré­vu pour col­lec­ter des don­nées cli­niques après la mise en marché.

• PSUR (Per­io­dic Safe­ty Update Report) : rap­port pério­dique qui réca­pi­tule les infor­ma­tions de sécu­ri­té issues du sui­vi post-commercialisation.

• Che­ck­list des EGSPR (Exi­gences Géné­rales de Sécu­ri­té et de Per­for­mance) : tableau per­met­tant de démon­trer, point par point, que toutes les exi­gences lis­tées à l’annexe I du règle­ment (UE) 2017/745 ont bien été trai­tées, docu­men­tées, et jus­ti­fiées dans le dos­sier technique.

• Dos­sier d’aptitude à l’utilisation : regroupe les résul­tats et ana­lyses des acti­vi­tés d’évaluation de l’ergonomie, en par­ti­cu­lier les inter­ac­tions entre l’utilisateur et le logi­ciel. Il vise à démon­trer que l’interface et le fonc­tion­ne­ment du pro­duit per­mettent une uti­li­sa­tion sûre, effi­cace et conforme à l’intention d’usage du dis­po­si­tif médi­cal, confor­mé­ment à la norme IEC 62366-1.

Les pro­cé­dures qua­li­té et modes opé­ra­toires asso­ciés au dos­sier technique

En com­plé­ment des docu­ments tech­niques décrits pré­cé­dem­ment, le dos­sier tech­nique d’un dis­po­si­tif médi­cal logi­ciel s’inscrit dans un sys­tème qua­li­té struc­tu­ré, selon les exi­gences de la norme ISO 13485. Ce sys­tème repose notam­ment sur un ensemble de pro­cé­dures qua­li­té et de modes opé­ra­toires docu­men­tés qui encadrent, sécu­risent et assurent la tra­ça­bi­li­té de toutes les acti­vi­tés réa­li­sées dans le cadre du déve­lop­pe­ment, de la vali­da­tion, de la mise sur le mar­ché, et du sui­vi post-com­mer­cia­li­sa­tion du logiciel.

Ces docu­ments ne sont pas direc­te­ment tech­niques, mais défi­nissent “com­ment” les acti­vi­tés doivent être menées pour qu’elles soient conformes aux exi­gences régle­men­taires et aux bonnes pra­tiques. Leur éla­bo­ra­tion repose sur plu­sieurs normes har­mo­ni­sées et guides, notamment :

• ISO 13485 pour le sys­tème de mana­ge­ment de la qualité,
• ISO 14971 pour la ges­tion des risques,
• IEC 62304 pour les logi­ciels de dis­po­si­tifs médicaux,
• MDR (UE) 2017/745, règle­ment euro­péen sur les dis­po­si­tifs médicaux.

Liste des pro­cé­dures et modes opératoires :

Pro­cé­dure de ges­tion des modi­fi­ca­tions : décrit le pro­ces­sus à suivre lorsqu'une modi­fi­ca­tion est appor­tée à un com­po­sant logi­ciel, à un docu­ment, ou à un pro­ces­sus. Per­met de garan­tir que chaque chan­ge­ment est éva­lué, vali­dé, et cor­rec­te­ment documenté.

Pro­cé­dure de ges­tion des actions cor­rec­tives et pré­ven­tives (CAPA) : défi­nit les étapes pour iden­ti­fier une non-confor­mi­té, en recher­cher la cause racine, puis mettre en œuvre des actions pour la cor­ri­ger et évi­ter sa réapparition.

Pro­cé­dure de ges­tion des récla­ma­tions : encadre la manière dont les retours uti­li­sa­teurs, plaintes ou récla­ma­tions sont enre­gis­trés, éva­lués, et trai­tés, y com­pris en lien avec la maté­rio­vi­gi­lance si nécessaire.

Pro­cé­dure de ges­tion des non-confor­mi­tés (NC) : décrit la ges­tion des écarts par rap­port aux exi­gences appli­cables, détec­tés à tout moment du cycle de vie du pro­duit ou du processus.

Pro­cé­dure de ges­tion des inci­dents cri­tiques et de la maté­rio­vi­gi­lance : défi­nit les étapes de décla­ra­tion, d’analyse et de trai­te­ment des inci­dents graves, en lien avec les auto­ri­tés com­pé­tentes (ex. ANSM).

Pro­cé­dure de sur­veillance après com­mer­cia­li­sa­tion (PMS) : pla­ni­fie la col­lecte conti­nue des don­nées sur le pro­duit une fois com­mer­cia­li­sé, afin d’évaluer sa per­for­mance et sa sécu­ri­té dans le temps réel d’utilisation.

Pro­cé­dure de vali­da­tion des appli­ca­tions logi­cielles uti­li­sées dans le SMQ : s’assure que les logi­ciels de sup­port (type Excel, Jira, outil de ges­tion docu­men­taire, etc.) uti­li­sés dans les pro­ces­sus qua­li­té sont eux-mêmes vali­dés pour leur usage prévu.

Pro­cé­dure de tra­ça­bi­li­té : garan­tit que chaque exi­gence, acti­vi­té ou livrable est iden­ti­fiable et que son his­to­rique de modi­fi­ca­tion est connu (liens entre SRS, tests, rapports...).

Pro­cé­dure de ges­tion des achats : encadre l’évaluation, la sélec­tion et le sui­vi des four­nis­seurs et pres­ta­taires, en lien avec leur impact poten­tiel sur la qua­li­té du dispositif.

Pro­cé­dure de ges­tion des risques : orga­nise la démarche de ges­tion des risques selon ISO 14971, de l’identification ini­tiale jusqu’au sui­vi des risques rési­duels après mise sur le marché.

Pro­cé­dure de revue de direc­tion : docu­mente l’analyse pério­dique de l’efficacité du sys­tème qua­li­té par la direction.

Pro­cé­dure de ges­tion docu­men­taire : décrit la manière dont les docu­ments qua­li­té sont créés, iden­ti­fiés, mis à jour, approu­vés, et archivés.

Pro­cé­dure de for­ma­tion : encadre la for­ma­tion du per­son­nel aux exi­gences qua­li­té, aux pro­cé­dures et aux outils néces­saires à leurs missions.

2.3. Mon rôle dans la constitution du dossier

Au sein de l’équipe régle­men­taire de RESIP, j’ai eu l’opportunité de tra­vailler de manière concrète et proac­tive sur deux dis­po­si­tifs médi­caux logi­ciels dif­fé­rents. Pour cha­cun, une liste spé­ci­fique d’environ 35 docu­ments devait être pro­duite ou mise à jour, vali­dée et inté­grée dans le dos­sier technique.

2.3.1 Travail initial : analyse et organisation

Avant le démar­rage de la phase de rédac­tion, une étape préa­lable d’analyse de l’existant a été menée, consi­dé­rée comme essen­tielle pour poser les bases du pro­jet docu­men­taire : quels docu­ments étaient déjà dis­po­nibles, dans quel état et à quelle version ?

Cette ana­lyse a impliqué :

• Des échanges régu­liers avec les chefs de pro­duit et les équipes de déve­lop­pe­ment, afin de com­prendre l’historique des livrables et leur contexte d’utilisation.
• Une lec­ture appro­fon­die détaillée des ver­sions pré­cé­dentes de cer­tains livrables, per­met­tant d’identifier leur niveau de com­plé­tude, leur struc­ture et leur adé­qua­tion aux normes.
• La mise en évi­dence des écarts entre les livrables exis­tants et les exi­gences for­melles défi­nies par les normes telles que ISO 13485, ISO 14971, et IEC 62304.

À l’issue de cette phase de diag­nos­tic, un tableau de ges­tion docu­men­taire a été conçu sous Excel. Cet outil a consti­tué un sup­port cen­tral de pilo­tage tout au long du pro­jet, en per­met­tant de :

• Lis­ter l’ensemble des livrables à pro­duire pour chaque dis­po­si­tif médi­cal logiciel,
• Asso­cier à chaque docu­ment les contri­bu­teurs res­pon­sables (équipes pro­duit, déve­lop­pe­ment, test, qualité).
• Suivre l’état d’avancement de chaque livrable selon des sta­tuts pré­dé­fi­nis (brouillon, en cours de relec­ture, validé).
• Pla­ni­fier les échéances de pro­duc­tion, les prio­ri­tés et les dates cibles de finalisation.

Ce tra­vail de struc­tu­ra­tion a été réa­li­sé en coor­di­na­tion avec l’équipe qua­li­té, et a per­mis d’industrialiser la démarche docu­men­taire pour qu’elle soit repro­duc­tible pour d’autres pro­duits à venir.

2.3.2 Contribution à la rédaction des documents

Une part impor­tante de mon tra­vail a été dédiée à la rédac­tion ou à la co-rédac­tion des docu­ments régle­men­taires du dos­sier tech­nique. Cette rédac­tion se fai­sait en lien étroit avec les autres ser­vices : déve­lop­pe­ment, qua­li­té et affaires régle­men­taires, pro­duit. En fonc­tion de chaque docu­ment, le niveau de tech­ni­ci­té ou de régle­men­ta­tion variait fortement.

Le sché­ma ci-des­sous illustre les dif­fé­rentes étapes de ce pro­ces­sus, depuis l’identification des docu­ments néces­saires jusqu’à la consti­tu­tion du dos­sier tech­nique final. La rédac­tion des docu­ments repose à la fois sur des exi­gences nor­ma­tives (ISO 13485, ISO 14971, IEC 62304, etc.), sur des guides de bonnes pra­tiques, mais aus­si sur les exi­gences spé­ci­fiques de l’organisme noti­fié (ici, GMED).

Le sché­ma per­met éga­le­ment de sou­li­gner la néces­si­té d’un pilo­tage rigou­reux (plan­ning, coor­di­na­tion, relances, vali­da­tion interne) afin de garan­tir la qua­li­té, la tra­ça­bi­li­té et la confor­mi­té de chaque livrable.

Ce cadre métho­do­lo­gique a été celui dans lequel mes contri­bu­tions ont pris place au quotidien.

Figure 5 : Processus de rédaction et de gestion du dossier technique d’un DM logiciel

2.4 Conception des modèles documentaires (templates) et structuration des livrables

            Au sein du ser­vice qua­li­té et affaires régle­men­taires de RESIP, une par­tie essen­tielle de notre tra­vail ne se limite pas à la simple rédac­tion de docu­ments : nous sommes éga­le­ment res­pon­sables de la concep­tion des modèles docu­men­taires (tem­plates) qui ser­vi­ront de base à la pro­duc­tion des livrables régle­men­taires pour l’ensemble des dis­po­si­tifs médi­caux logi­ciels déve­lop­pés en interne.

Ces tem­plates sont construits selon une approche rigou­reuse, en tenant compte :

1. Des exi­gences des normes appli­cables (notam­ment ISO 13485, IEC 62304, ISO 14971, IEC 62366-1).
2. Des recom­man­da­tions des guides MDCG émis par la Com­mis­sion euro­péenne dans le cadre du Règle­ment (UE) 2017/745.
   • Le MDCG 2020-1 Éva­lua­tion cli­nique des logi­ciels, prin­cipes clés
   • Le MDCG 2019-16 concer­nant la cyber­sé­cu­ri­té des dis­po­si­tifs médicaux.
   • Le MDCG 2021-24 sur sur la clas­si­fi­ca­tion des dis­po­si­tifs médicaux.
   • Le Guide d’interprétation de la norme IEC 62304 (ISO/TR 80002-1).
3. Des attentes spé­ci­fiques de l’organisme noti­fié, avec lequel RESIP tra­vaille pour l’évaluation et la cer­ti­fi­ca­tion de ses dispositifs.

La concep­tion de ces modèles repose sur plu­sieurs prin­cipes structurants :

Stan­dar­di­sa­tion du for­mat (page de garde, his­to­rique des ver­sions, table des matières, réfé­rences nor­ma­tives, etc.).
Cohé­rence du conte­nu atten­du selon le type de docu­ment (exi­gences, plans, rap­ports, pro­cé­dures, etc.).
Tra­ça­bi­li­té des infor­ma­tions essen­tielles, notam­ment celles liées aux exi­gences régle­men­taires et aux tests.
Lisi­bi­li­té et clar­té : le GMED, comme tout orga­nisme noti­fié, appré­cie les docu­ments concis, bien struc­tu­rés, et faci­le­ment audités.

2.5 Collaboration interdisciplinaire dans l’élaboration des contenus

Une fois les modèles conçus, ils sont uti­li­sés comme base pour la rédac­tion col­la­bo­ra­tive des livrables. Il est essen­tiel de sou­li­gner que ces docu­ments ne sont pas rédi­gés en solo : bien au contraire, leur com­plé­tude et leur vali­di­té dépendent d’une col­la­bo­ra­tion étroite avec plu­sieurs équipes internes, notamment :

• Les déve­lop­peurs et archi­tectes logi­ciels (front-end, back-end), qui apportent les élé­ments tech­niques néces­saires : des­crip­tions d’algorithmes, archi­tec­ture logi­cielle, stra­té­gie de ver­sion­nage, pro­ces­sus de com­pi­la­tion, les choix tech­no­lo­giques et les élé­ments cri­tiques de conception.
• Les équipes de test / vali­da­tion (QA), qui four­nissent les don­nées de test, les preuves de vérification/validation, les rap­ports de non-confor­mi­té, les cri­tères d’acceptation, etc.
• Les chefs de pro­duit, qui for­mulent les besoins fonc­tion­nels, les cas d’usage, et les évo­lu­tions prévues.
• Les métiers régle­men­taires, qui assurent la confor­mi­té du conte­nu au regard des exi­gences nor­ma­tives et du cadre MDR.

Cette inter­dis­ci­pli­na­ri­té est un élé­ment cen­tral du pro­ces­sus, car elle garan­tit à la fois la qua­li­té tech­nique et la vali­di­té régle­men­taire des docu­ments. Chaque livrable passe par plu­sieurs cycles : rédac­tion ini­tiale, relec­ture par les équipes tech­niques ou régle­men­taires, mise à jour selon les retours, vali­da­tion finale (signa­ture numé­rique), puis archivage.

CONCLUSION

Cette mis­sion m’a per­mis de déve­lop­per une com­pré­hen­sion appro­fon­die de la com­po­si­tion et de la fina­li­té d’un dos­sier tech­nique, spé­ci­fi­que­ment dans le contexte des dis­po­si­tifs médi­caux logi­ciels. En tra­vaillant sur l’ensemble des livrables régle­men­taires, j’ai pu assi­mi­ler les attentes pré­cises des orga­nismes noti­fiés, notam­ment dans le cadre de l’évaluation pour l’obtention du mar­quage CE. Cette expé­rience a éga­le­ment été l’occasion de conso­li­der mes connais­sances en matière de régle­men­ta­tion euro­péenne, d’interpréter les exi­gences du Règle­ment (UE) 2017/745 (MDR), et d’intégrer les bonnes pra­tiques issues des normes ISO 13485, ISO 14971 ou encore IEC 62304.

En paral­lèle de cet appren­tis­sage régle­men­taire, j’ai pro­gres­si­ve­ment ren­for­cé ma com­pré­hen­sion des aspects tech­niques du logi­ciel, en me fami­lia­ri­sant avec l’architecture fonc­tion­nelle, les outils de déve­lop­pe­ment, les méca­nismes de tests, ain­si qu’avec les prin­cipes de véri­fi­ca­tion et validation.

Cette double com­pé­tence régle­men­taire et tech­nique s’est révé­lée essen­tielle pour assu­rer la cohé­rence et la qua­li­té du dos­sier produit.

Chapitre 3 : Intégration des exigences réglementaires dans le développement des dispositifs médicaux logiciels : obstacles, bonnes pratiques et retour d’expérience

INTRODUCTION

Le sec­teur des tech­no­lo­gies de la san­té est en pro­fonde muta­tion, lar­ge­ment impul­sé par l'innovation numé­rique et la pro­li­fé­ra­tion des Dis­po­si­tifs Médi­caux Logi­ciels (SaMD - Soft­ware as a Medi­cal Device). Qu'il s'agisse d'applications d'aide au diag­nos­tic, de logi­ciels de pla­ni­fi­ca­tion de trai­te­ment ou d'APIs médi­cales inté­grées dans des sys­tèmes com­plexes, les SaMDs redé­fi­nissent les par­cours de soins. Cepen­dant, leur nature imma­té­rielle, leur évo­lu­ti­vi­té rapide et leur inter­ac­tion poten­tielle avec la san­té humaine imposent un cadre régle­men­taire strict, tel que le Règle­ment (UE) 2017/745. Cette confron­ta­tion entre la dyna­mique de l'ingénierie logi­cielle et les exi­gences rigou­reuses de la confor­mi­té est au cœur des défis ren­con­trés par les acteurs de ce sec­teur, à l'image de RESIP.

Ce cha­pitre se pro­pose d'analyser en pro­fon­deur cette dia­lec­tique. Nous com­men­ce­rons par défi­nir les SaMDs et le cadre régle­men­taire euro­péen qui les régit, éta­blis­sant ain­si les fon­da­tions de la confor­mi­té. Ensuite, nous décri­rons en détail le pro­ces­sus de déve­lop­pe­ment d'un logi­ciel de dis­po­si­tif médi­cal, en sou­li­gnant sa com­plexi­té et la rigueur métho­dique requise à chaque étape, confor­mé­ment aux meilleures pra­tiques de l'ingénierie logi­cielle. Fort de cette com­pré­hen­sion des pro­ces­sus tech­niques, nous iden­ti­fie­rons les obs­tacles concrets que la régle­men­ta­tion impose à ces pra­tiques de déve­lop­pe­ment, éclai­rant les points de ten­sion. Enfin, nous conclu­rons par l'identification de stra­té­gies et de bonnes pra­tiques essen­tielles pour har­mo­ni­ser le déve­lop­pe­ment logi­ciel avec les exi­gences régle­men­taires, visant une fusion opti­male entre l'agilité de l'ingénierie logi­cielle et l'impératif de sécu­ri­té et de per­for­mance des dis­po­si­tifs médicaux.

3.1 Cadre Réglementaire des Dispositifs Médicaux Logiciels : Qualification et Classification Essentielles

L'innovation en matière de logi­ciels de san­té a ren­du indis­pen­sable l'établissement d'un cadre régle­men­taire clair et strict. L'objectif est double : sti­mu­ler l'innovation tout en garan­tis­sant un niveau éle­vé de sécu­ri­té et de per­for­mance pour les patients.

3.2 Cas d'utilisation d'un logiciel classe II et perspectives

3.1.1 Définition et qualification d'un logiciel en tant que Dispositif Médical (SaMD)

Selon l'Article 2, point 1 du Règle­ment (UE) 2017/745, un dis­po­si­tif médi­cal se carac­té­rise par sa des­ti­na­tion médi­cale spé­ci­fique, cou­vrant des fonc­tions telles que le diag­nos­tic, la pré­ven­tion, le contrôle, le trai­te­ment ou l'atténuation d'une mala­die. Un logi­ciel est qua­li­fié de SaMD s'il rem­plit cette des­ti­na­tion médi­cale de manière auto­nome, c'est-à-dire sans faire par­tie inté­grante d'un dis­po­si­tif médi­cal maté­riel [4].

Dans le contexte de RESIP, les APIs médi­cales déve­lop­pées illus­trent par­fai­te­ment cette qua­li­fi­ca­tion. Si une API four­nit, par exemple, des algo­rithmes d'analyse d'imagerie pour aider au diag­nos­tic, elle agit comme un SaMD. Inver­se­ment, un logi­ciel de ges­tion pure­ment admi­nis­tra­tive, même dans un envi­ron­ne­ment cli­nique, n'est pas consi­dé­ré comme un DM. Cette dis­tinc­tion est cru­ciale car elle est le point de départ de l'application de toutes les exi­gences du MDR. Elle implique une ana­lyse exhaus­tive de l'usage pré­vu du logi­ciel, de ses fonc­tion­na­li­tés prin­ci­pales et de l'impact des infor­ma­tions ou actions qu'il génère sur la prise en charge du patient.

3.1.2 La classification des SaMDs selon le Règlement (UE) 2017/745 (MDR)

Le MDR classe les dis­po­si­tifs médi­caux en fonc­tion de l'impact de leurs infor­ma­tions sur les déci­sions médi­cales, de la Classe I (risque faible) à la Classe III (risque éle­vé). Pour les logi­ciels, la règle 11 de l'Annexe VIII du MDR est la réfé­rence normative.

Cette clas­si­fi­ca­tion est d'une impor­tance capi­tale car elle déter­mine si l'intervention d'un orga­nisme noti­fié est requise (obli­ga­toire pour les classes IIa, IIb, III), l'étendue de la docu­men­ta­tion tech­nique à pro­duire et le niveau de rigueur des pro­ces­sus de sur­veillance post-com­mer­cia­li­sa­tion. Une clas­si­fi­ca­tion erro­née peut entraî­ner des retards signi­fi­ca­tifs dans le pro­ces­sus de mar­quage CE, voire une non-conformité.

Figure 6 : Classification des DM logiciels selon le Règlement (UE) 2017/745 (MDR), Annexe VIII, Chapter III, Régle 11

3.1.3 Les exigences générales de sécurité et de performance pour les SaMDs

Pour les SaMDs, cer­taines de ces exi­gences sont par­ti­cu­liè­re­ment per­ti­nentes et exigent une atten­tion spécifique :

• Per­for­mance et fia­bi­li­té : Le logi­ciel doit fonc­tion­ner sans défaillance, de manière repro­duc­tible et conforme à sa des­ti­na­tion, garan­tis­sant la pré­ci­sion des don­nées et des analyses.
• Sécu­ri­té de l'information et cyber-sécu­ri­té : Face à la cri­ti­ci­té des don­nées de san­té, le logi­ciel doit pro­té­ger la confi­den­tia­li­té, l'intégrité et la dis­po­ni­bi­li­té des infor­ma­tions patient, et être rési­lient face aux menaces cyber­né­tiques. Les récentes publi­ca­tions du MDCG, comme le MDCG 2019-16 sur la Cyber-sécu­ri­té, sou­lignent l'importance de la ges­tion proac­tive de ces risques.
• Com­pa­ti­bi­li­té : Le SaMD doit être conçu pour fonc­tion­ner har­mo­nieu­se­ment avec les sys­tèmes d'exploitation, les maté­riels et les autres logi­ciels avec les­quels il est cen­sé interagir.
• Concep­tion et fabri­ca­tion : Le pro­ces­sus de déve­lop­pe­ment lui-même doit être conduit selon des prin­cipes rigou­reux de ges­tion des risques et de qua­li­té documentée.

La confor­mi­té à ces EGSP est démon­trée par l'application de normes har­mo­ni­sées. L'IEC 62304:2015 "Logi­ciels de dis­po­si­tifs médi­caux - Pro­ces­sus du cycle de vie du logi­ciel" est la norme fon­da­men­tale qui struc­ture le déve­lop­pe­ment, la main­te­nance et la mise à jour des logi­ciels médi­caux. L'ISO 14971 :2019 "Dis­po­si­tifs médi­caux - Appli­ca­tion de la ges­tion des risques aux dis­po­si­tifs médi­caux" est éga­le­ment indis­pen­sable pour l'identification, l'évaluation et la maî­trise des risques liés au dis­po­si­tif, y com­pris ceux d'origine logi­cielle. La syner­gie entre ces normes et les exi­gences du MDR assure un cadre strict visant la sûre­té et l'efficacité des SaMDs tout au long de leur cycle de vie.

3.2. Le développement d'un Dispositif Médical Logiciel : étapes et rigueur du SDLC

Le déve­lop­pe­ment d'un dis­po­si­tif médi­cal logi­ciel est un pro­ces­sus hau­te­ment struc­tu­ré et exi­geant, bien au-delà de la simple pro­gram­ma­tion. Il doit s'inscrire dans un Cycle de Vie du Déve­lop­pe­ment Logi­ciel (SDLC) rigou­reux, tel que détaillé dans le docu­ment "Medi­cal Device Soft­ware Deve­lop­ment" de Fries et Bloesch. Ce pro­ces­sus intègre les exi­gences de qua­li­té, de sécu­ri­té et de per­for­mance dès les pre­mières phases, en adé­qua­tion avec les prin­cipes de l'IEC 62304 [5].

Figure 7 : Cycle de Vie du Développement d'un dispositif médical logiciel

3.2.1 Planification du projet logiciel et établissement du Système de Management de la Qualité (SMQ)

Cette phase inclut la défi­ni­tion claire des objec­tifs du pro­jet, l'allocation des res­sources humaines et maté­rielles, l'établissement des rôles et des res­pon­sa­bi­li­tés, et la déter­mi­na­tion des jalons clés du déve­lop­pe­ment. En paral­lèle, la mise en œuvre et le main­tien d'un Sys­tème de Mana­ge­ment de la Qua­li­té (SMQ), en confor­mi­té avec l'ISO 13485 :2016, sont fondamentaux.

Ce SMQ doit être spé­ci­fi­que­ment adap­té aux par­ti­cu­la­ri­tés du déve­lop­pe­ment logi­ciel, inté­grant des pro­cé­dures pour le contrôle docu­men­taire, la ges­tion des non-confor­mi­tés, les actions cor­rec­tives et pré­ven­tives (CAPA), et la réa­li­sa­tion d'audits internes. C'est ce cadre qui assure que toutes les acti­vi­tés de déve­lop­pe­ment sont menées de manière contrô­lée, tra­çable et conforme aux exi­gences régle­men­taires. La qua­li­té du pro­duit final est intrin­sè­que­ment liée à la robus­tesse du SMQ qui encadre son développement.

3.2.2 Définition des exigences utilisateur et des spécifications logicielles (URS/SRS)

Elle débute par la col­lecte et l'analyse des Exi­gences Uti­li­sa­teur (URS), qui expriment les besoins fonc­tion­nels et non fonc­tion­nels des uti­li­sa­teurs finaux et la fina­li­té médi­cale atten­due du logiciel.

Ces URS sont ensuite for­ma­li­sés en Spé­ci­fi­ca­tions des Exi­gences Logi­cielles (SRS) qui détaillent les fonc­tion­na­li­tés tech­niques, les per­for­mances atten­dues, les inter­faces (internes et externes) et les contraintes de concep­tion spé­ci­fiques du logi­ciel. L'utilisation de tech­niques comme les dia­grammes de cas d'utilisation ou les modèles de don­nées est recom­man­dé pour cla­ri­fier ces exi­gences. Un manque de clar­té ou d'exhaustivité à ce stade peut entraî­ner des défauts majeurs et des non-confor­mi­tés coû­teuses dans les phases ulté­rieures. Une tra­ça­bi­li­té rigou­reuse entre les URS et les SRS est indis­pen­sable, posant les bases pour les phases de concep­tion, de déve­lop­pe­ment et de tests.

3.2.4 Codage et implémentation

Le codage et l'implémentation repré­sentent la phase où la concep­tion logi­cielle est tra­duite en code exé­cu­table.
L'adhésion à des stan­dards de codage (conven­tions de nom­mage, com­men­taires clairs, struc­ture de code cohé­rente) est fon­da­men­tale pour la main­te­na­bi­li­té et la lisi­bi­li­té du code. L'utilisation d'outils de ges­tion de confi­gu­ra­tion logi­cielle (SCM) est indis­pen­sable pour le contrôle de ver­sion, la ges­tion des chan­ge­ments et la tra­ça­bi­li­té des modi­fi­ca­tions. La réa­li­sa­tion de revues de code (ins­pec­tions, code walk­through, code rea­ding…) est éga­le­ment citée comme un moyen effi­cace de détec­ter les défauts tôt dans le cycle. Bien que la réuti­li­sa­bi­li­té du code soit un avan­tage, elle doit être abor­dée avec pru­dence, chaque com­po­sant réuti­li­sé devant être vali­dé pour son appli­ca­tion spé­ci­fique dans le contexte du dis­po­si­tif médical.

3.2.3 Conception et architecture logicielle

Cette étape implique l'analyse des alter­na­tives de concep­tion et de leurs com­pro­mis, en visant une archi­tec­ture modu­laire et hié­rar­chique.
Les prin­cipes clés de concep­tion incluent la modu­la­ri­té (décou­per le sys­tème en modules indé­pen­dants), un cou­plage faible entre les modules et une forte cohé­sion interne, ain­si que l'encapsulation (cacher les détails d'implémentation). Cru­cia­le­ment, la concep­tion doit inté­grer des consi­dé­ra­tions pour la ges­tion des erreurs, la récu­pé­ra­tion en cas de panne, la sûre­té et la sécu­ri­té dès le départ. La docu­men­ta­tion détaillée de la concep­tion est essen­tielle pour la clar­té, la révi­sion et, pour la démons­tra­tion de la confor­mi­té réglementaire.

3.2.5 Vérification et Validation (V&V) logicielle

La Véri­fi­ca­tion et la Vali­da­tion (V&V) sont des phases cri­tiques pour s'assurer que le SaMD est conforme à ses exi­gences et qu'il est apte à l'emploi prévu.

La véri­fi­ca­tion est le pro­ces­sus de s'assurer que les pro­duits d'une phase de déve­lop­pe­ment satis­font les exi­gences de cette phase ("Are we buil­ding the pro­duct right?"), tan­dis que la vali­da­tion est le pro­ces­sus de s'assurer que le pro­duit final satis­fait les exi­gences et la des­ti­na­tion de l'utilisateur ("Are we buil­ding the right product?").

Tests Uni­taires (Unit Tes­ting) : Ces tests sont effec­tués sur la plus petite uni­té de code. L'objectif est de s'assurer que les modules logi­ciels de plus bas niveau fonc­tionnent cor­rec­te­ment. Il existe dif­fé­rentes approches, comme l'analyse de che­mins de branche (où le déve­lop­peur par­court chaque che­min au sein d'une uni­té, sou­vent pour les uni­tés cri­tiques pour la sécu­ri­té) ou les tests d'interface de module (approche "boîte noire" tes­tant l'unité uni­que­ment en variant ses entrées).

Tests d'Intégration (Inte­gra­tion Tes­ting) : Ces tests visent à s'assurer que des uni­tés logi­cielles (deux ou plus) fonc­tionnent cor­rec­te­ment ensemble une fois inté­grés. Les tests impliquent géné­ra­le­ment la rédac­tion de pro­to­coles pour exer­cer les inter­faces entre ces entités.

Tests de Vali­da­tion (Vali­da­tion Tes­ting) : Ce pro­ces­sus prouve que le pro­duit répond aux spé­ci­fi­ca­tions du pro­duit et qu'il ne fait pas ce qu'il n'est pas cen­sé faire. Plu­sieurs approches sont employées :

• Tests Basés sur les Exi­gences (Requi­re­ments-Based Tes­ting) : L'approche prin­ci­pale pour vali­der le logi­ciel. Les exi­gences des spé­ci­fi­ca­tions logi­cielles (SRS) sont ana­ly­sées et allouées à des tests spé­ci­fiques. Des approches comme les tests de seuil ou de limite sont uti­li­sées pour déve­lop­per ces tests.
• Tests de Seuil (Thre­shold Tes­ting) : Prouve qu'un évé­ne­ment (par exemple, une alarme) se déclen­che­ra lorsqu’un para­mètre spé­ci­fié dépasse une cer­taine valeur, en incluant une bande de tolé­rance autour du seuil.
• Tests de Limite (Boun­da­ry Tes­ting) : Teste un para­mètre à ses limites défi­nies et tente de dépas­ser ces limites pour obser­ver la réac­tion du dispositif.
• Tests de Stress (Stress Tes­ting) : Sou­met l'unité à un bom­bar­de­ment d'entrées aléa­toires (par exemple, des pres­sions sur le cla­vier ou des rota­tions de molette) pour ten­ter de pro­vo­quer une défaillance logi­cielle. Cela peut être manuel ou automatisé.
• Tests de Volume (Volume Tes­ting) : Exerce l'unité pen­dant une période pro­lon­gée (par exemple, 72 heures) pour décou­vrir des pro­blèmes non détec­tés autre­ment. Ils sont presque tou­jours auto­ma­ti­sés et uti­lisent une approche logique pour tes­ter tous les che­mins du programme.
• Tests de Scé­na­rio (Sce­na­rio Tes­ting) : Implique la rédac­tion de tests qui simulent l'utilisation réelle du logi­ciel du point de vue de l'utilisateur, pour décou­vrir des pro­blèmes sys­tème ou des défauts dans l'utilisation glo­bale du produit.

Tests Sys­tème (Sys­tem Tes­ting) : Ces tests visent à vali­der l'ensemble du dis­po­si­tif médi­cal, et pas seule­ment le logi­ciel embar­qué. Il peut y avoir un che­vau­che­ment signi­fi­ca­tif avec les tests logi­ciels, sur­tout lorsque le logi­ciel néces­site d'autres sous-sys­tèmes méca­niques ou élec­triques pour fonc­tion­ner. L'objectif est de s'assurer que l'ensemble du sys­tème fonc­tionne comme prévu.

3.2.6 La traçabilité

La ges­tion de la docu­men­ta­tion tech­nique est une exi­gence cen­trale du MDR, et la tra­ça­bi­li­té est sa pierre angu­laire. Le docu­ment "Medi­cal device stan­dards' requi­re­ments for tra­cea­bi­li­ty during the soft­ware deve­lop­ment life­cycle and imple­men­ta­tion of a tra­cea­bi­li­ty assess­ment model" par Regan. Insiste sur le fait que la tra­ça­bi­li­té est la capa­ci­té de lier les arte­facts du déve­lop­pe­ment (exi­gences, concep­tion, code, tests) entre eux et est essen­tielle pour démon­trer la sûre­té du logi­ciel [6].

L'article dis­tingue plu­sieurs types de traçabilité :

• Tra­ça­bi­li­té en amont (back­ward tra­cea­bi­li­ty) : Per­met de remon­ter d'un arte­fact (ex : code) à sa source (ex : exi­gence) – "Pour­quoi ce module existe-t-il ?"
• Tra­ça­bi­li­té en aval (for­ward tra­cea­bi­li­ty) : Per­met de des­cendre d'un arte­fact à ses déri­vés – "Où cette exi­gence est-elle implé­men­tée et testée ?"
• Tra­ça­bi­li­té bidi­rec­tion­nelle : Une com­bi­nai­son des deux, consi­dé­rée comme essen­tielle pour une ana­lyse d'impact com­plète et pour véri­fier que toutes les exi­gences ont été implé­men­tées et testées.

Les normes comme l'IEC 62304 exigent expli­ci­te­ment de main­te­nir la tra­ça­bi­li­té entre les exi­gences sys­tème, les exi­gences logi­cielles, l'architecture logi­cielle, la concep­tion détaillée, les tests et la ges­tion des risques. La tra­ça­bi­li­té est cru­ciale pour la confor­mi­té régle­men­taire, l'analyse d'impact des chan­ge­ments, la détec­tion des lacunes et le sup­port d'audit. L'implémentation de la tra­ça­bi­li­té passe sou­vent par l'utilisation de matrices de tra­ça­bi­li­té et d'outils de ges­tion du cycle de vie des appli­ca­tions (ALM) pour auto­ma­ti­ser et main­te­nir ces liens com­plexes. Exemples : Jira + Confluence, GitLab… 

3.3 Obstacles majeurs à la mise en conformité des SaMDs avec le MDR au cours du SDLC

Mal­gré la rigueur des pro­ces­sus de déve­lop­pe­ment décrits pré­cé­dem­ment, leur inté­gra­tion dans le cadre strict du MDR pré­sente des défis signi­fi­ca­tifs. Les entre­prises inno­vantes sont confron­tées à de nom­breux obs­tacles qui peuvent ralen­tir ou com­pli­quer l'obtention et le main­tien du mar­quage CE. L'article JMIR 2024, "Explo­ring Impe­di­ments Impo­sed by the Medi­cal Device Regu­la­tion EU 2017/745 on Soft­ware as a Medi­cal Device" de Liga Svempe, met en lumière plu­sieurs de ces points de fric­tion majeurs [7]. Ces constats sont d'autant plus per­ti­nents qu'ils ont été confir­més et ana­ly­sés à tra­vers mon expé­rience au sein de RESIP en tant qu'alternant char­gé qua­li­té et affaires régle­men­taires, impli­qué notam­ment dans la rédac­tion et la mise à jour des dos­siers tech­niques tout au long du cycle de vie des logiciels.

3.3.1 Complexité et interprétation de la réglementation pour les SaMDs

L'un des pre­miers freins est la com­plexi­té et l'ambiguïté d'interprétation de cer­tains aspects du MDR, par­ti­cu­liè­re­ment lorsqu'ils sont appli­qués aux SaMDs. Le cadre régle­men­taire, his­to­ri­que­ment axé sur le maté­riel, peut par­fois man­quer de clar­té pour les spé­ci­fi­ci­tés logi­cielles (par exemple, la ges­tion des ver­sions mineures ver­sus majeures, ou la qua­li­fi­ca­tion de cer­taines fonc­tion­na­li­tés IA). Cette incer­ti­tude impacte direc­te­ment la pla­ni­fi­ca­tion du pro­jet et la défi­ni­tion des exi­gences, car une mau­vaise inter­pré­ta­tion peut mener à des erreurs de qua­li­fi­ca­tion ou de clas­si­fi­ca­tion, avec des réper­cus­sions signi­fi­ca­tives sur l'ensemble du SDLC.

3.3.2 Intégration des exigences réglementaires dans des méthodologies de développement agiles

Les entre­prises de déve­lop­pe­ment logi­ciel adoptent majo­ri­tai­re­ment des métho­do­lo­gies agiles (Scrum, Kan­ban) pour leur flexi­bi­li­té et leur rapi­di­té d'itération. Cepen­dant, la docu­men­ta­tion exces­sive et la rigi­di­té des pro­ces­sus régle­men­taires impo­sées par le MDR et néces­si­tant une docu­men­ta­tion exhaus­ti­ve­ment chaque modi­fi­ca­tion de code, de réa­li­ser des V&V com­plètes à chaque ité­ra­tion, et de main­te­nir une tra­ça­bi­li­té par­faite est un défi orga­ni­sa­tion­nel de taille. Les exi­gences de vali­da­tion et de docu­men­ta­tion pour chaque release peuvent ralen­tir consi­dé­ra­ble­ment le cycle de déploie­ment agile, créant une ten­sion entre la vélo­ci­té du déve­lop­pe­ment et l'impératif de conformité.

Défis concrets :

Sur­charge docu­men­taire : L'agile pri­vi­lé­gie les "logi­ciels opé­ra­tion­nels plu­tôt qu'une docu­men­ta­tion exhaus­tive". Or, le MDR exige un dos­sier tech­nique dense pour chaque ver­sion du SaMD.

Exemple : En agile, les spé­ci­fi­ca­tions évo­luent. Chaque sprint apporte son lot de nou­velles fonc­tion­na­li­tés ou d'ajustements. Docu­men­ter toutes les exi­gences, la concep­tion, les résul­tats de test et les ana­lyses de risque pour chaque petite ité­ra­tion peut deve­nir un tra­vail à temps plein pour l'équipe régle­men­taire, ralen­tis­sant le pro­ces­sus de déve­lop­pe­ment logiciel.

Rigi­di­té des pro­ces­sus de vali­da­tion : Les cycles de véri­fi­ca­tion et vali­da­tion sont sou­vent per­çus comme trop longs et lourds pour s'intégrer har­mo­nieu­se­ment dans des sprints agiles courts.

Exemple : Si un "fea­ture" est déve­lop­pé en deux semaines, la véri­fi­ca­tion et la vali­da­tion com­plète (tests uni­taires, inte­gra­tion, sys­tème, usa­bi­li­ty, etc.) peut prendre plu­sieurs semaines sup­plé­men­taires, for­çant l'équipe agile à "attendre" ou à tra­vailler sur d'autres sujets sans pou­voir déployer rapi­de­ment ce qui nuit à la réac­ti­vi­té et à l'efficacité des équipes agiles.

3.3.3 Gestion des risques spécifiques aux logiciels (ISO 14971)

Bien que l'ISO 14971 four­nisse un cadre pour la ges­tion des risques, son appli­ca­tion aux logi­ciels, et par­ti­cu­liè­re­ment ceux inté­grant des tech­no­lo­gies avan­cées comme l'Intelligence Arti­fi­cielle (IA), pré­sente des défis uniques et accrus.

Défis concrets :

Iden­ti­fi­ca­tion et carac­té­ri­sa­tion des modes de défaillance logi­ciels : Contrai­re­ment au maté­riel où les modes de défaillance peuvent être pré­dic­tibles (rup­ture méca­nique, panne élec­trique), les défauts logi­ciels peuvent être sub­tils et émer­ger dans des condi­tions d'utilisation inat­ten­dues (erreurs logiques, inter­ac­tions imprévues).

Exemple : Un algo­rithme d'IA conçu pour détec­ter des ano­ma­lies sur des images médi­cales peut se com­por­ter de manière inat­ten­due face à des don­nées "hors dis­tri­bu­tion" (nou­velles popu­la­tions, images de mau­vaise qua­li­té), géné­rant de faux posi­tifs ou néga­tifs. Éva­luer la pro­ba­bi­li­té et la gra­vi­té de ces défaillances pour chaque scé­na­rio cli­nique est extrê­me­ment com­plexe lors de la concep­tion logicielle.

Ges­tion des risques liés aux dépen­dances tierces et à la cyber-sécu­ri­té : Les SaMDs modernes reposent sou­vent sur de nom­breuses biblio­thèques tierces, fra­me­works open-source ou APIs externes. Ce contexte met en lumière le défi de la ges­tion des vul­né­ra­bi­li­tés asso­ciées à ces com­po­sants et à la cyber-sécu­ri­té globale.

Exemple : Une vul­né­ra­bi­li­té cri­tique est décou­verte dans une biblio­thèque open-source uti­li­sée par une API de RESIP. L'équipe doit non seule­ment mettre à jour rapi­de­ment la biblio­thèque (ce qui implique des tests de régres­sion), mais aus­si rééva­luer l'analyse de risque (3.3.3) et mettre à jour le dos­sier tech­nique, le tout sous la pres­sion d'une menace active.

3.3.4 Exigences de vérification et validation logicielles (IEC 62304)

Les exi­gences de veri­fi­ca­tion et vali­da­tion (V&V) de l'IEC 62304 sont rigou­reuses pour assu­rer la sécu­ri­té logi­cielle, mais leur mise en œuvre peut être un frein signi­fi­ca­tif pour les SaMDs complexes.

Défis concrets :

Cou­ver­ture de test exhaus­tive pour des sys­tèmes com­plexes : Pour des logi­ciels sophis­ti­qués, notam­ment ceux basés sur l’IA ou impli­quant des inter­ac­tions com­plexes avec d’autres sys­tèmes, la démons­tra­tion d’une cou­ver­ture de test exhaus­tive (par exemple, 100 % de cou­ver­ture de code ou de che­mins logiques) est extrê­me­ment dif­fi­cile. Il est sou­vent com­plexe d’atteindre le niveau de preuve atten­du par les auto­ri­tés réglementaires.

Exemple : Une API inter­agit avec une base de don­nées volu­mi­neuse conte­nant un très grand nombre de don­nées phar­ma­ceu­tiques. Tes­ter toutes les com­bi­nai­sons pos­sibles d'entrées, de réponses et d'états dans un envi­ron­ne­ment simu­lé devient expo­nen­tiel­le­ment com­plexe. Les tests de vali­da­tion doivent alors se concen­trer sur les scé­na­rios les plus cri­tiques, mais cela laisse des zones de risques potentielles.

Vali­da­tion cli­nique des per­for­mances : Pour les SaMDs de classe supé­rieure, la vali­da­tion cli­nique est essen­tielle. Prou­ver le béné­fice cli­nique et la sécu­ri­té du logi­ciel dans des condi­tions d'utilisation réelles peut s'apparenter à des essais cli­niques pour des médicaments.

Exemple : Une appli­ca­tion mobile qui aide au diag­nos­tic doit prou­ver qu'elle amé­liore réel­le­ment la pré­ci­sion diag­nos­tique ou réduit le temps de diag­nos­tic en condi­tions cli­niques réelles, par rap­port aux méthodes exis­tantes. Cela néces­site la col­lecte de don­nées cli­niques, la mise en place d'études, ce qui est très coû­teux et chro­no­phage, impac­tant direc­te­ment les délais de mise sur le marché.

3.3.5 Défis liés à la traçabilité et à la gestion documentaire du cycle de vie

La tra­ça­bi­li­té est une exi­gence clé du MDR et des normes comme l'IEC 62304. Cepen­dant, sa mise en œuvre est un obs­tacle majeur pour de nom­breuses entreprises.

Défis concrets :

Main­tien des liens de tra­ça­bi­li­té : Main­te­nir des liens clairs et à jour entre les exi­gences (URS/SRS), les élé­ments de concep­tion, le code, les tests et les risques tout au long du cycle de vie est une tâche ardue.

Exemple : Une petite modi­fi­ca­tion d'une exi­gence uti­li­sa­teur pour une API par exemple doit être réper­cu­tée et tra­cée dans les spé­ci­fi­ca­tions tech­niques, les élé­ments de code affec­tés, les cas de test asso­ciés et l'analyse de risque. Si cela n'est pas auto­ma­ti­sé, le risque d'oublier de mettre à jour un lien ou une docu­men­ta­tion est très éle­vé, menant à des non-confor­mi­tés lors des audits.

Cohé­rence et acces­si­bi­li­té de la docu­men­ta­tion : L'exigence de main­te­nir un dos­sier tech­nique com­plet, orga­ni­sé et faci­le­ment acces­sible pour les audits est une charge impor­tante, par­ti­cu­liè­re­ment dans un envi­ron­ne­ment agile où les docu­ments peuvent évo­luer rapidement.

Exemple : Il est facile de se retrou­ver avec des ver­sions obso­lètes de docu­ments de concep­tion si le pro­ces­sus de ges­tion des ver­sions n'est pas robuste. Un audi­teur peut deman­der la preuve de tra­ça­bi­li­té pour une ver­sion spé­ci­fique du logi­ciel datant d'il y a deux ans, ce qui néces­site un sys­tème de ges­tion docu­men­taire impec­cable et des outils ges­tion du cycle de vie des appli­ca­tions (ALM) effi­caces pour retrou­ver rapi­de­ment les infor­ma­tions pertinentes.

3.3.6 Enjeux de la cyber-sécurité et de la conformité continue

Les SaMDs, étant sou­vent connec­tés et inté­grant des don­nées de san­té sen­sibles, sont constam­ment expo­sés à des menaces de cyber-sécu­ri­té. Ce domaine repré­sente un défi en constante évo­lu­tion et une pré­oc­cu­pa­tion majeure pour le MDR.

Défis concrets :

Évo­lu­tion rapide des menaces et main­tien de la sécu­ri­té "by desi­gn" : Les cyber­me­naces (attaques par ran­çon­gi­ciel, ten­ta­tives d'intrusion…) évo­luent plus rapi­de­ment que les cycles de mise à jour régle­men­taires et néces­sitent une réac­ti­vi­té constante. L'intégration de mesures de sécu­ri­té dès la concep­tion est essen­tielle, mais le main­tien de cette sécu­ri­té sur le long terme est un défi.

Exemple : Après la mise sur le mar­ché d'une API de RESIP, une nou­velle vul­né­ra­bi­li­té est décou­verte dans un pro­to­cole de com­mu­ni­ca­tion stan­dard (par exemple, un pro­to­cole d'authentification ou de chif­fre­ment) ou un com­po­sant réseau cri­tique. Bien que l'API ait été conforme au moment de sa vali­da­tion, cette nou­velle vul­né­ra­bi­li­té exige que l'entreprise mette à jour rapi­de­ment le logi­ciel, rééva­lue les risques et mette à jour le dos­sier tech­nique. Cette ges­tion des vul­né­ra­bi­li­tés "post-com­mer­cia­li­sa­tion" est un pro­ces­sus conti­nu, com­plexe et coû­teux en ressources.

3.4 Fusionner le développement logiciel et les exigences réglementaires : bonnes pratiques

Les sec­tions pré­cé­dentes ont mis en évi­dence la dua­li­té entre la nature dyna­mique du déve­lop­pe­ment logi­ciel et la rigueur des exi­gences régle­men­taires. L'enjeu pour les entre­prises est de fusion­ner ces deux mondes pour opti­mi­ser le tra­vail, assu­rer la confor­mi­té et garan­tir la sécu­ri­té et la per­for­mance des logiciels.

3.4.1 Adopter une approche intégrée et collaborative

Au lieu de consi­dé­rer la confor­mi­té comme une tâche dis­tincte et post-déve­lop­pe­ment, elle doit être un moteur de la concep­tion. Cela implique une col­la­bo­ra­tion étroite et constante entre les équipes de déve­lop­pe­ment, de qua­li­té, des affaires régle­men­taires et les uti­li­sa­teurs. La sen­si­bi­li­sa­tion et la for­ma­tion de tous les acteurs aux exi­gences du MDR et aux normes per­ti­nentes sont cru­ciales pour déve­lop­per une culture de la qualité.

3.4.2 Stratégies pour une documentation et une traçabilité efficiente

Pour rele­ver le défi de la tra­ça­bi­li­té sans sur­char­ger les équipes, l'adoption d'outils de ges­tion du cycle de vie des appli­ca­tions est for­te­ment recom­man­dée. Ces outils cen­tra­lisent les exi­gences, la concep­tion, le code et les tests,le ges­tion des risque et les non confor­mi­tés en créant des liens de tra­ça­bi­li­té auto­ma­tiques. Cela per­met de géné­rer des rap­ports de tra­ça­bi­li­té à la demande et de s'assurer que toute modi­fi­ca­tion est cor­rec­te­ment docu­men­tée et ses impacts tracés..

3.4.3 Investir dans la formation continue et la veille réglementaire

Une veille régle­men­taire proac­tive est indis­pen­sable pour anti­ci­per les chan­ge­ments régle­men­taires (nou­velles direc­tives MDCG, révi­sions de normes) et adap­ter les pro­ces­sus internes en consé­quence.
La for­ma­tion conti­nue des équipes, non seule­ment sur les com­pé­tences tech­niques mais aus­si sur les aspects régle­men­taires et les meilleures pra­tiques de l'industrie, assure que l'entreprise reste à la pointe de la confor­mi­té et de l'innovation.

3.5 Retour d’expérience

3.5.1 Compétences acquises et développées

Cette période en entre­prise a été un cata­ly­seur pour l'acquisition et le ren­for­ce­ment de nom­breuses com­pé­tences, tant tech­niques que trans­ver­sales, en lien direct avec ma for­ma­tion ini­tiale en ingé­nie­rie et ma spé­cia­li­sa­tion en affaires régle­men­taires. J'ai eu l'opportunité d'approfondir consi­dé­ra­ble­ment ma com­pré­hen­sion du Règle­ment (UE) 2017/745 (MDR) et des normes har­mo­ni­sées essen­tielles, telles que l'ISO 13485, l'ISO 14971 et l'IEC 62304.
Au-delà de leur simple connais­sance, j'ai appris à inter­pré­ter leurs exi­gences de manière prag­ma­tique et, sur­tout, à les appli­quer concrè­te­ment sur les pro­duits déve­lop­pés par RESIP, notam­ment dans le cadre de la rédac­tion et de la mise à jour des dos­siers tech­niques. Cela a consi­dé­ra­ble­ment ren­for­cé ma capa­ci­té à struc­tu­rer, rédi­ger et main­te­nir une docu­men­ta­tion de qua­li­té, prête à être audi­tée et reflé­tant un res­pect scru­pu­leux des exi­gences de confor­mi­té et de qualité.

Par ailleurs, mes com­pé­tences se sont éten­dues aux aspects tech­niques liés au déve­lop­pe­ment logi­ciel et à la ges­tion de l'information de manière plus géné­rale, depuis sa concep­tion jusqu'à son déploie­ment, offrant une vision com­plète du cycle de vie du produit.

Sur un plan plus trans­ver­sal, cette expé­rience a consi­dé­ra­ble­ment affi­né mes capa­ci­tés de com­mu­ni­ca­tion inter-équipes. La rédac­tion des dos­siers tech­niques pour un dis­po­si­tif médi­cal logi­ciel exige une inter­ac­tion constante et fluide avec les équipes de Recherche et Déve­lop­pe­ment et Pro­duit, me posi­tion­nant comme le repré­sen­tant de l’équipe affaires régle­men­taires. Cela a déve­lop­pé ma capa­ci­té à com­mu­ni­quer des infor­ma­tions com­plexes de manière claire. J'ai éga­le­ment culti­vé une forte auto­no­mie, indis­pen­sables pour pilo­ter la ges­tion d'un dos­sier tech­nique de SaMD, en iden­ti­fiant les besoins, en anti­ci­pant les obs­tacles et en pro­po­sant des solu­tions. Enfin, le sens de l'organisation et les com­pé­tences en ges­tion de pro­jet ont été cru­ciaux, me per­met­tant de gérer des tâches mul­tiples, d'organiser des réunions et d'assurer le va-et-vient effi­cace des infor­ma­tions entre les dif­fé­rentes per­sonnes et services.

3.5.2 Points restant à acquérir ou à approfondir

Bien que cette expé­rience ait été extrê­me­ment enri­chis­sante, elle a éga­le­ment mis en lumière des axes d'amélioration et des domaines dans les­quels je sou­haite ardem­ment pour­suivre mon déve­lop­pe­ment. Ma prio­ri­té est de conti­nuer à affi­ner mes com­pé­tences pour maî­tri­ser encore davan­tage le cycle de vie com­plet des dis­po­si­tifs médi­caux logi­ciels. Cela inclut, de manière cru­ciale, l'approfondissement de mes connais­sances tech­niques et régle­men­taires concer­nant les logi­ciels qui intègrent des tech­no­lo­gies avan­cées comme l'Intelligence Arti­fi­cielle et le Machine Lear­ning, pour les­quelles des régu­la­tions spé­ci­fiques et des défis par­ti­cu­liers émergent constam­ment. Sur un autre plan, j'aspire à m'impliquer davan­tage dans les déci­sions stra­té­giques qui dépassent la seule rédac­tion des dos­siers tech­niques, afin d'acquérir une vision plus glo­bale et d'influencer la confor­mi­té dès les phases amont du déve­lop­pe­ment pro­duit. Cet objec­tif s'accompagne du désir de ren­for­cer mon exper­tise en ges­tion de pro­jet, ain­si qu'en amé­lio­ra­tion des sys­tèmes de management.

3.5.3 Corrélation entre la Formation théorique et l'expérience en entreprise

Mon Mas­ter en Affaires Régle­men­taires des Dis­po­si­tifs Médi­caux a lar­ge­ment contri­bué à ma per­for­mance et à ma capa­ci­té d'intégration au sein de RESIP, consti­tuant une base théo­rique extrê­me­ment solide. Les dif­fé­rentes matières étu­diées, les pro­jets pra­tiques (liés à la qua­li­té, à l'aspect tech­nique ou à la ges­tion de pro­jet), ain­si que les échanges avec les inter­ve­nants pro­fes­sion­nels et les nom­breuses pré­sen­ta­tions réa­li­sées (pro­gram­mées ou non, courtes ou longues) nous ont dotés d'outils concep­tuels et métho­do­lo­giques pré­cieux. Tout ce que nous avons acquis en termes d'informations liées au Règle­ment (UE) et aux dif­fé­rentes normes har­mo­ni­sées et plus géné­ra­le­ment à la régle­men­ta­tion du sec­teur, m'a aidé à appré­hen­der rapi­de­ment les exi­gences spé­ci­fiques des dis­po­si­tifs médi­caux, à navi­guer effi­ca­ce­ment dans un cadre légal com­plexe et à appli­quer concrè­te­ment ces prin­cipes aux acti­vi­tés de l'entreprise. Cette syner­gie entre les acquis aca­dé­miques et les défis indus­triels a été fon­da­men­tale pour don­ner corps à mes connais­sances et pour contri­buer de manière per­ti­nente aux mis­sions de confor­mi­té et de qua­li­té chez RESIP.

CONCLUSION

Ce cha­pitre a mis en lumière défi de conci­lier l'agilité inhé­rente au déve­lop­pe­ment logi­ciel avec la rigueur impo­sée par la régle­men­ta­tion des dis­po­si­tifs médi­caux. Alors que l'agilité favo­rise l'itération rapide et la flexi­bi­li­té, le MDR exige une docu­men­ta­tion exhaus­tive, une tra­ça­bi­li­té minu­tieuse et des pro­ces­sus de vali­da­tion stricts.

La clé réside dans l'intégration proac­tive des exi­gences régle­men­taires dès le début du cycle de vie, trans­for­mant les contraintes en leviers pour assu­rer à la fois l'innovation et la sécu­ri­té des dis­po­si­tifs médi­caux logiciels.

CONCLUSION GÉNÉRALE

Ce rap­port a per­mis de mettre en lumière l'ensemble des acti­vi­tés réa­li­sées durant mon alter­nance chez RESIP. Grâce à une immer­sion com­plète dans un éco­sys­tème des dis­po­si­tifs médi­caux logi­ciels à diverses fina­li­tés médi­cales, j'ai pu appli­quer mes com­pé­tences tech­niques et mes connais­sances régle­men­taires tout en appro­fon­dis­sant ma com­pré­hen­sion des exi­gences régle­men­taires et nor­ma­tives rela­tives à la mise sur le mar­ché des solu­tions logicielles.

 Les dif­fé­rentes mis­sions effec­tuées, allant de la contri­bu­tion à la rédac­tion et la mise à jour des dos­siers tech­niques, en pas­sant par la veille régle­men­taire et nor­ma­tive et la ges­tion des risques, ont démon­tré l’importance d’adopter les bonnes pra­tiques et de les inté­grer dans le work­flow du tra­vail afin de répondre aux besoins spé­ci­fiques des clients et garan­tir la qua­li­té et la sécu­ri­té des solu­tions développées.

 Mon enga­ge­ment chez RESIP se pour­suit acti­ve­ment avec un pro­jet stra­té­gique visant à digi­ta­li­ser et opti­mi­ser la ges­tion des non-confor­mi­tés, des CAPA et de la maté­rio­vi­gi­lance sur notre outil de ges­tion de cycle de vie de pro­duit, Jira. Cette ini­tia­tive est cru­ciale pour flui­di­fier les pro­ces­sus, amé­lio­rer la tra­ça­bi­li­té et ren­for­cer le sys­tème de mana­ge­ment de qualité.

Bibliographie

[1]       « Société de technologie et de services depuis 50 ans | Cegedim ». Consulté le : 10 janvier 2025. [En ligne]. Disponible sur : https://www.cegedim.fr/groupe/presentation/Pages/Presentation.aspx

[2]       « Claude Bernard - La société RESIP ». Consulté le : 10 janvier 2025. [En ligne]. Disponible sur : https://www.bcb.fr/societe-resip.jsp

[3]       « Claude Bernard - La référence des produits de santé ». Consulté le : 10 janvier 2025. [En ligne]. Disponible sur : https://www.bcb.fr/base-de-donnees-medicaments.jsp#about

[4]       « Journal officiel L 117/2017 ». Consulté le : 26 juin 2025. [En ligne]. Disponible sur : https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=OJ:L:2017:117:FULL

[5]       R. C. Fries et A. E. Bloesch, « 85 - Medical Device Software Development », in Clinical Engineering Handbook, J. F. Dyro, Éd., in Biomedical Engineering. , Burlington : Academic Press, 2004, p. 359‑365. doi : 10.1016/B978-012226570-9/50093-4.

[6]       G. Regan, F. Mc Caffery, K. Mc Daid, et D. Flood, « Medical device standards’ requirements for traceability during the software development lifecycle and implementation of a traceability assessment model », Comput. Stand. Interfaces, vol. 36, n^o 1, p. 3‑9, nov. 2013, doi : 10.1016/j.csi.2013.07.012.

[7]       L. Svempe, « Exploring Impediments Imposed by the Medical Device Regulation EU 2017/745 on Software as a Medical Device », JMIR Med. Inform., vol. 12, n^o 1, p. e58080, sept. 2024, doi : 10.2196/58080.