Embarqué médical : ce que le règlement MDR change pour vous

Beaucoup d'ingénieurs systèmes embarqués abordent une mission médicale comme un projet industriel classique. Erreur de cadrage. Dès lors que le logiciel ou l'électronique que vous développez contribue à une finalité médicale — surveiller un paramètre physiologique, piloter une délivrance, aider au diagnostic —, vous entrez dans le périmètre du règlement européen MDR (Medical Device Regulation, 2017/745).

La notion clé : le logiciel peut être un dispositif médical à part entière (on parle de « software as a medical device »). Le firmware d'un capteur de glycémie connecté, l'algorithme qui déclenche une alerte sur un moniteur, le code qui régule une pompe : ce ne sont pas de simples briques techniques, ce sont des composants soumis à un régime de conformité strict, avec une classe de risque (de I à III) qui détermine le niveau d'exigence.

Concrètement, cela signifie que votre travail s'inscrit dans une chaîne documentaire et réglementaire où la moindre approximation se paie. Un comportement non spécifié, un cas limite non testé, une absence de documentation des choix de conception : ces manquements ne sont plus de simples bugs, ce sont des non-conformités réglementaires.

La structure de responsabilité dans le médical déroute. Le fabricant du dispositif (votre client) porte la responsabilité finale devant les autorités et le marché : c'est lui qui appose le marquage CE, qui assure la vigilance, qui répond des incidents. Vous pourriez en déduire que votre exposition est limitée. Ce serait une erreur.

En tant que prestataire technique, vous êtes lié au fabricant par un contrat qui vous engage sur la qualité et la conformité de votre livrable. Si un défaut de votre firmware provoque un incident, le fabricant qui aura indemnisé le marché se retournera contre vous au titre de votre faute. Le mécanisme est en cascade :

• Le patient ou l'établissement subit un dommage.
• Le fabricant, responsable devant le marché, indemnise et fait l'objet de procédures de vigilance.
• Le fabricant exerce un recours contre vous à hauteur de la part de responsabilité imputable à votre prestation.

Autrement dit, votre position de sous-traitant ne vous protège pas : elle vous place au bout de la chaîne du recours. D'où l'importance d'une RC Professionnelle dont les plafonds sont calibrés pour un secteur où les indemnisations sont parmi les plus élevées.

Dans le médical, le respect des normes n'est pas une question de bonnes pratiques optionnelles. Le non-respect d'une norme applicable constitue, en cas de litige, une présomption de faute. Trois piliers structurent votre travail :

1. IEC 62304 — cycle de vie du logiciel de dispositif médical. Elle impose un processus documenté : planification, analyse de risques logiciels, architecture, vérification, gestion des anomalies. Travailler sans s'y conformer, c'est s'exposer.
2. ISO 14971 — gestion des risques. Chaque risque doit être identifié, évalué, maîtrisé et documenté. Un cas limite « oublié » qui cause un incident révèle une analyse de risques défaillante.
3. IEC 62366 — aptitude à l'utilisation. Les erreurs d'usage induites par une mauvaise conception de l'interface ou du comportement système relèvent aussi de votre responsabilité.

Dans le médical, ce qui n'est pas documenté est réputé ne pas avoir été fait. Votre dossier de conception est votre première ligne de défense en cas de réclamation.

Votre assurance ne remplace jamais la conformité : elle intervient quand, malgré une démarche sérieuse, un sinistre survient. Mais un assureur examinera votre niveau de conformité, et un dossier solide facilite la prise en charge.

Un dispositif médical connecté — moniteur communicant, pompe pilotable à distance, capteur transmettant des données de santé — ajoute une dimension que le MDR prend désormais explicitement en compte : la cybersécurité. Une vulnérabilité dans votre firmware n'est plus seulement un défaut technique, c'est une porte d'entrée vers des données de santé (parmi les plus sensibles au sens du RGPD) et un risque pour la sécurité du patient.

Deux conséquences pour votre couverture :

• RGPD et données de santé. Si votre conception facilite une fuite de données de patients, la responsabilité peut être partagée. Une assurance cyber couvre les conséquences d'une atteinte aux données et la gestion de crise associée.
• Sécurité fonctionnelle. Une intrusion exploitant une faille que vous auriez dû prévenir peut compromettre le fonctionnement du dispositif — donc la sécurité du patient. C'est l'intersection la plus délicate entre RC Pro et cyber.

Le MDR exige désormais une prise en compte de la cybersécurité dès la conception (« security by design »). Documenter cette démarche n'est pas qu'une obligation réglementaire : c'est aussi ce qui distingue, en cas de litige, l'erreur excusable de la négligence.

Avant d'accepter une mission qui touche un dispositif médical, posez le cadre. Voici les réflexes qui font la différence entre une exposition maîtrisée et un risque subi :

• Vérifiez la classe du dispositif. Un dispositif de classe III (implantable, à risque vital) n'expose pas comme un dispositif de classe I. Adaptez vos plafonds en conséquence.
• Délimitez votre périmètre par écrit. Quelle partie du système relève de vous ? Quelles obligations de conformité portez-vous ? Un contrat flou élargit votre responsabilité.
• Calibrez votre RC Pro pour le médical. Plafonds relevés, couverture des préjudices immatériels, prise en charge du recours du fabricant : tous les contrats ne se valent pas pour ce secteur.
• Activez le volet cyber dès que le dispositif est connecté ou traite des données de santé.

Pour comprendre l'ensemble des garanties pensées pour votre métier et obtenir un tarif adapté à votre secteur d'intervention, consultez la page dédiée assurance ingénieur systèmes embarqués.