Pourquoi c'est mal couvert
Peu de spécialistes des affaires réglementaires savent lire une architecture logicielle. Peu de développeurs savent lire le MDR. Le sujet tombe entre les deux, et ça se voit dans les dossiers.
Le symptôme classique : une documentation logicielle rédigée par quelqu'un qui n'a jamais vu le code, remplie de généralités conformes au plan de la norme mais qui ne décrit pas le produit. Ou l'inverse — une documentation technique riche, écrite par l'équipe de développement, qui ne répond à aucune exigence normative.
Un dossier logiciel se juge à une chose : est-ce qu'il décrit le logiciel qui existe réellement ?
Nous travaillons ce sujet des deux côtés : plus de vingt ans de développement logiciel en environnement industriel, et des dossiers de conformité IEC 62304 et MDR menés jusqu'à l'audit.
Trois questions, dans cet ordre
Est-ce un dispositif médical ?
La qualification se joue sur la destination revendiquée, pas sur la technologie. Un logiciel destiné à un usage diagnostique, thérapeutique, de prévention, de pronostic ou de surveillance relève du MDR. Un logiciel qui se contente de stocker, archiver, communiquer ou effectuer une recherche simple n'en est pas un.
Attention : la destination se lit dans toute votre communication — notice, site web, plaquette, démonstration en salon, publications. Une seule page qui parle de « diagnostic » suffit à qualifier le produit, quelle que soit la prudence du reste.
Quelle classe ?
C'est la règle 11 de l'annexe VIII du MDR qui s'applique, et elle est sévère. Un logiciel fournissant des informations utilisées pour prendre des décisions à visée diagnostique ou thérapeutique est au minimum en classe IIa — donc soumis à organisme notifié. La classe monte à IIb ou III selon la gravité des conséquences possibles.
Cette règle est la principale cause de reclassification depuis l'entrée en application du MDR. Nous lui consacrons un article complet.
Quelle classe de sécurité logicielle ?
Distincte de la classe du dispositif, la classe IEC 62304 — A, B ou C — dépend du dommage possible en cas de défaillance, après prise en compte des mesures de maîtrise externes. Elle détermine l'étendue du cycle de vie à documenter : en classe A, plusieurs sections tombent ; en classe C, l'architecture détaillée et les tests unitaires deviennent obligatoires.
La classe de sécurité doit être justifiée dans le rapport de gestion des risques, pas affirmée dans le plan de développement. Déclarer une classe A sans démonstration est un des constats les plus fréquents — et sa correction oblige à rouvrir toute la documentation du cycle de vie.
Ce que nous produisons
Note de qualification et classification
Application argumentée des règles, avec les scénarios alternatifs. Le document qui permet de tenir sa position devant un organisme notifié ou l'ANSM — ou de constater qu'elle ne tient pas, avant que quelqu'un d'autre le fasse.
Documentation IEC 62304
Plan de développement, spécifications, description de l'architecture logicielle, plan et rapports de vérification, gestion de configuration, gestion des anomalies. Rédigés à partir du produit réel.
Liste et maîtrise des SOUP
Inventaire des composants tiers avec version, fonction, exigences et anomalies connues. Le point le plus systématiquement incomplet des dossiers logiciels.
Cybersécurité
Analyse de risque sécurité, exigences du MDR annexe I §17.2 et §17.4, plan de gestion des vulnérabilités, articulation avec le guide MDCG 2019-16.
Aptitude à l'utilisation
IEC 62366-1 : dossier d'ingénierie de l'aptitude à l'utilisation, identification des erreurs d'usage, validation. Souvent traité trop tard, alors qu'il conditionne la conception.
Validation des systèmes informatisés
ISO 13485 §4.1.6 : validation des outils du système qualité — GED, ERP, suivi des CAPA. Approche fondée sur le risque pour éviter de tout valider au même niveau.
Deux sujets émergents
Intelligence artificielle et EU AI Act
Un dispositif médical intégrant de l'IA cumule le MDR et le règlement (UE) 2024/1689. La plupart des dispositifs médicaux à base d'IA relèvent du haut risque au sens de ce règlement, avec des obligations propres : gouvernance des données, documentation technique, journalisation, surveillance humaine, robustesse. L'enjeu pratique est de ne pas construire deux systèmes documentaires parallèles mais d'articuler les deux référentiels sur une base commune.
Où s'arrête le dispositif ?
Sur une plateforme configurable, la frontière du dispositif médical n'est pas toujours architecturale. Un même socle logiciel peut porter des usages qui relèvent du MDR et d'autres qui n'en relèvent pas, selon la configuration livrée à chaque client. La frontière est alors fonctionnelle, et il faut la définir explicitement — sinon c'est l'organisme notifié qui la définira, en général plus largement que vous ne l'auriez souhaité.
Questions fréquentes
Mon logiciel est-il un dispositif médical ?
Cela dépend de sa destination revendiquée, pas de sa technologie. S'il est destiné à un usage diagnostique, thérapeutique, de prévention, de pronostic ou de surveillance d'une maladie, il relève du MDR. S'il se contente de stocker, archiver, communiquer ou effectuer une recherche simple, non. Entre les deux se situe la zone grise, et c'est là que se prennent les mauvaises décisions.
Comment choisir la classe IEC 62304 ?
Par le dommage possible si le logiciel défaille, après prise en compte des mesures de maîtrise externes au logiciel. Classe A : aucune blessure possible. Classe B : blessure non grave. Classe C : décès ou blessure grave. Le raisonnement doit figurer dans le rapport de gestion des risques.
Qu'est-ce qu'un SOUP et pourquoi ça compte ?
Un software of unknown provenance : bibliothèque tierce, composant open source, framework — tout ce que vous intégrez sans maîtriser son cycle de développement. L'IEC 62304 impose d'en tenir la liste avec version, fonction et exigences, et de surveiller les anomalies publiées. Dans une application web moderne, la liste peut être longue : mieux vaut la générer automatiquement que la tenir à la main.
Faut-il valider les logiciels du système qualité ?
Oui, c'est le §4.1.6 de l'ISO 13485. Il concerne la GED, l'ERP, le suivi des CAPA, la gestion des réclamations — tout outil informatique utilisé dans le système qualité. Ce sujet est distinct du logiciel produit et il est régulièrement découvert pendant l'audit. Sur un parc de vingt applications, c'est un chantier de plusieurs dizaines de jours.
Une méthode agile est-elle compatible avec l'IEC 62304 ?
Oui. La norme décrit des processus et des livrables, pas un cycle en V. Le rapport technique AAMI TIR45 documente précisément l'articulation entre agilité et IEC 62304. Ce qu'exige la norme, c'est la traçabilité entre exigence, conception, code et test — pas un enchaînement séquentiel de phases.
Et pour un logiciel déjà sur le marché ?
La reprise documentaire d'un logiciel existant est un exercice courant et différent : on ne réécrit pas l'histoire, on documente l'état actuel et on met en place le processus pour la suite. Le piège serait de produire une documentation de cycle de vie rétrospective qui ne correspond à rien de ce qui s'est réellement passé.
Un doute sur la qualification de votre logiciel ?
C'est la question à trancher en premier — tout le reste en dépend, y compris votre budget et votre calendrier.
En parler Lire l'article sur la règle 11