Chez Innovel, nous concevons des cartes électroniques pour des dispositifs médicaux depuis plusieurs années. Et c’est précisément cette expérience qui nous pousse à vous expliquer pourquoi comprendre les normes IEC 62304 et ISO 13485 n’est pas une simple formalité administrative : c’est une question de responsabilité envers les patients qui utiliseront vos équipements.

La norme IEC 62304

Publiée en 2006 et amendée en 2015 (IEC 62304:2006/Amd 1:2015), elle est éditée par la Commission électrotechnique internationale (CEI, ou IEC en anglais) et reprise en Europe sous la référence EN 62304[1]. Concrètement, à quoi sert-elle ? Elle établit une méthodologie rigoureuse pour le développement et la maintenance des logiciels embarqués dans les dispositifs médicaux, avec un objectif simple mais fondamental : maîtriser les risques liés à ces logiciels. Un bug dans un jeu vidéo peut être ennuyeux. Un bug dans le firmware d’une pompe à insuline peut être fatal.

Les trois classes de sécurité logicielle : hiérarchiser les risques

La norme IEC 62304 ne demande pas la même rigueur pour tous les logiciels médicaux. Elle les classe en trois catégories, selon les conséquences possibles d’une défaillance (clause 4.3) :

Classe A — le logiciel ne peut pas contribuer à une situation dangereuse, ou la situation dangereuse qu’il pourrait créer n’entraîne pas de risque inacceptable compte tenu des mesures de maîtrise extérieures au logiciel. Exemple : l’archivage ou l’affichage de données sans effet sur la conduite du soin.
Classe B — une situation dangereuse est possible, avec un risque inacceptable, mais le dommage envisageable est une blessure non grave. Exemple : le pilotage d’un dispositif de photothérapie dont un défaut peut provoquer une irritation cutanée.
Classe C — la défaillance peut entraîner une blessure grave ou le décès. Exemples : le firmware d’un ventilateur pulmonaire ou d’une pompe à perfusion.

Deux règles que l’on oublie souvent. D’abord, un logiciel est présumé de classe C tant que rien ne justifie une classe inférieure : la classification s’argumente par écrit, en lien avec le dossier de gestion des risques du fabricant (ISO 14971). Ensuite, plus la classe est élevée, plus les exigences de conception documentée, de tests et de traçabilité s’alourdissent — et cela se décide en début de projet, pas à la fin.

À ne pas confondre avec la classe réglementaire du dispositif (I, IIa, IIb, III au sens du règlement (UE) 2017/745)[3] : ce sont deux classifications distinctes. Un dispositif de classe IIa peut parfaitement embarquer un logiciel de classe de sécurité B.

Notre périmètre couvre aujourd’hui les classes A et B. Si l’analyse de risque conduit à un logiciel de classe C, nous le disons dès le cadrage et nous vous orientons vers un partenaire dimensionné pour ces exigences : c’est plus honnête que de le découvrir au moment de l’audit.

ISO 13485 : le système qualité qui englobe tout

La norme IEC 62304 ne fonctionne jamais seule. Elle s’intègre dans un ensemble plus large dont le pilier est la norme ISO 13485, reprise en Europe sous la référence EN ISO 13485:2016, qui définit les exigences du système de management de la qualité des dispositifs médicaux[2]. Là où l’IEC 62304 encadre le cycle de vie du logiciel, ISO 13485 regarde le système global : conception, fabrication, distribution, maintenance, relation client. Concrètement, elle impose une structure organisationnelle dédiée à la qualité, des procédures documentées, une traçabilité complète et une gestion systématique des non-conformités.

Qui est concerné ?

Tous les fabricants de dispositifs médicaux embarquant du logiciel — et, en amont, leurs sous-traitants de conception électronique. La responsabilité réglementaire du dispositif appartient au fabricant au sens du règlement (UE) 2017/745 : c’est lui qui détient le dossier technique, le système qualité et le dossier de gestion des risques. Mais l’article 7.4 d’ISO 13485 lui impose d’évaluer et de maîtriser ses fournisseurs. En pratique, le sous-traitant est évalué, contractualisé, parfois audité, et doit fournir des livrables documentaires directement intégrables au dossier du fabricant. Ignorer ces normes quand on est sous-traitant, c’est se rendre inutilisable sur ce marché.

Les exigences à satisfaire

Nous voyons régulièrement des clients arriver après coup, une fois le prototype terminé. Erreur stratégique. La conformité IEC 62304 / ISO 13485 doit être architecturée dès la conception, pas ajoutée ensuite.

Pourquoi ? Parce que si vous découvrez les défaillances en fin de projet, vous devez reprendre la conception, les tests et la documentation. Vous repoussez votre mise sur le marché de plusieurs mois.

À l’inverse, intégrer la conformité dès le départ coûte moins cher. C’est un investissement initial qui se rentabilise lors de l’évaluation de conformité et des mises à jour futures.

Conclusion : la conformité, c’est de la confiance

Lorsqu’un praticien branche un dispositif médical à un patient, il fait un acte de confiance. Il suppose que ce dispositif a été conçu, testé et validé selon des standards stricts. Cette confiance n’est pas accidentelle : elle repose sur des décennies d’apprentissage, d’erreurs et de régulations.

Les normes IEC 62304 et ISO 13485 ne sont pas des paperasses bureaucratiques. Ce sont des garde-fous méthodologiques qui obligent à penser l’impensable : « et si cette électronique tombe en panne ? »

Pour un fabricant, les respecter, c’est dire au marché qu’il a mesuré l’importance de ce qu’il fait et qu’il a investi dans la qualité. C’est aussi un avantage commercial concret : une certification ISO 13485, un audit réussi, une documentation impeccable sont des atouts pour vendre et pour fidéliser.

Innovel n’est pas certifiée ISO 13485. Nous intervenons comme sous-traitant de conception et de production électronique auprès de fabricants de dispositifs médicaux, qui portent la responsabilité de la conformité du dispositif final. L’article 7.4 d’ISO 13485 impose au fabricant d’évaluer et de maîtriser ses fournisseurs — il ne lui impose pas de les choisir certifiés. Nous produisons les livrables documentaires du cycle de vie logiciel exigés par l’IEC 62304 en classes A et B, destinés à être intégrés au dossier technique et au système qualité du fabricant.

Un projet de dispositif médical à cadrer ? Décrivez-nous la fonction du logiciel et la classe visée : nous vous dirons ce que nous pouvons livrer et ce qui doit rester chez vous. Demandez un devis.

Références

[1] IEC 62304:2006/Amd 1:2015, Medical device software — Software life cycle processes. https://www.iso.org/standard/64686.html

[2] ISO 13485:2016, Medical devices — Quality management systems — Requirements for regulatory purposes. https://www.iso.org/standard/59752.html

[3] Règlement (UE) 2017/745 du Parlement européen et du Conseil du 5 avril 2017 relatif aux dispositifs médicaux. https://eur-lex.europa.eu/eli/reg/2017/745/oj