ISO 13485 pour un éditeur de logiciel : ce que ça implique vraiment

L’ISO 13485 souffre d’une mauvaise réputation dans les équipes logicielles : celle d’une norme bureaucratique qui ralentit tout. Cette réputation est en partie méritée — par la façon dont elle est souvent mise en œuvre, pas par son contenu.

Ce que le règlement exige réellement

Le règlement (UE) 2017/745 impose aux fabricants de mettre en place un système de management de la qualité couvrant notamment la stratégie de conformité, la gestion des risques, l’évaluation clinique, la réalisation du produit, la surveillance après commercialisation et la gestion des modifications.

Il ne nomme aucune norme. Mais l’ISO 13485 est le référentiel de fait : c’est la structure que les organismes notifiés connaissent, attendent et savent auditer. S’en écarter est théoriquement possible et pratiquement déraisonnable.

Ce que ça veut dire pour une équipe de développement

Six domaines concentrent l’essentiel de l’effort pour un éditeur.

La maîtrise de la conception. Planifier, tracer les exigences jusqu’à leur vérification, conserver les décisions de conception et leurs justifications. C’est le cœur du sujet, et le point où l’outillage fait toute la différence.

La maîtrise des modifications. Toute évolution doit être évaluée quant à son impact sur la sécurité, les performances et la destination. Pour une équipe qui livre en continu, cela impose de définir ce qui constitue une modification significative — et de le faire avant d’en avoir besoin.

La maîtrise des fournisseurs. Prestataires, mais aussi bibliothèques, dépendances et services externes. Il faut savoir ce qu’on utilise, pourquoi, et comment on suit les vulnérabilités.

Les enregistrements. La norme raisonne en preuves. Une activité non tracée est réputée ne pas avoir eu lieu — indépendamment de sa réalité.

Les actions correctives et préventives. Un processus d’analyse des causes qui alimente réellement l’amélioration, pas un registre rempli avant l’audit.

La formation et les compétences. Démontrer que les personnes qui conçoivent savent ce qu’elles font, au sens de la norme.

Agile et ISO 13485 : la vraie réponse

La norme n’impose aucun cycle de développement. Elle impose des activités et des preuves. Un développement itératif est parfaitement compatible, à une condition : que les preuves soient produites par le processus plutôt que reconstituées ensuite.

Concrètement, cela veut dire outiller la traçabilité — exigence, tâche, test, revue, livraison — dans les outils que l’équipe utilise déjà, plutôt que de maintenir une documentation parallèle. Les équipes qui échouent sont celles qui ont deux systèmes : un pour travailler, un pour l’audit. Le second finit toujours par diverger du premier, et cet écart est exactement ce qu’un auditeur détecte.

Se certifier, ou seulement se structurer ?

Ce sont deux décisions distinctes.

Structurer son système selon l’ISO 13485 est nécessaire dès lors que votre logiciel est un dispositif médical : c’est ce que le règlement exige et ce que l’organisme notifié auditera.

Obtenir une certification ISO 13485 séparée, délivrée par un organisme de certification, est un choix. Elle facilite les échanges commerciaux, rassure les clients et les partenaires, et peut fluidifier l’évaluation. Elle représente en revanche un dispositif d’audit supplémentaire à maintenir.

Pour une jeune structure, la séquence raisonnable consiste souvent à structurer d’abord, se certifier ensuite si le marché le demande.

L’erreur qui coûte le plus cher

Sous-traiter la rédaction du système à un cabinet extérieur sans impliquer l’équipe. On obtient un corpus documentaire cohérent, conforme sur le papier, et que personne n’applique.

L’audit ne compare pas vos procédures à la norme : il compare votre pratique à vos procédures. Un système modeste et réellement suivi passe ; un système ambitieux et fictif échoue.