1. Deux classifications qu'on confond
Premier point, et il élimine la moitié des malentendus : la classe du dispositif et la classe de sécurité logicielle sont deux choses différentes, issues de deux textes différents.
| Classe du dispositif | Classe de sécurité logicielle | |
|---|---|---|
| Texte | MDR, annexe VIII | IEC 62304, §4.3 |
| Valeurs | I, IIa, IIb, III | A, B, C |
| Question posée | Quelle procédure d'évaluation de la conformité ? | Quelle rigueur dans le cycle de vie du logiciel ? |
Il n'y a pas de correspondance automatique entre les deux. Un dispositif de classe IIa peut parfaitement contenir un logiciel de classe A, et l'inverse existe aussi. Les raisonnements sont indépendants — même s'ils s'appuient tous deux sur l'analyse de risque.
2. A, B ou C : les définitions exactes
La norme définit les trois classes par le dommage possible résultant d'une défaillance du logiciel :
| Classe | Définition |
|---|---|
| A | Aucune blessure ni atteinte à la santé n'est possible |
| B | Une blessure non grave est possible |
| C | Le décès ou une blessure grave est possible |
Trois mots méritent l'attention.
« Possible », et non « probable ». La probabilité d'occurrence d'une défaillance logicielle n'entre pas dans le raisonnement — la norme part du principe qu'un défaut logiciel peut toujours survenir. On raisonne uniquement sur la conséquence.
« Blessure », au sens physique. Un préjudice financier, une perte de données ou un retard administratif ne sont pas des blessures au sens de la norme, même s'ils sont graves par ailleurs.
« Résultant d'une défaillance du logiciel ». On examine ce qui se passe si ce logiciel se comporte mal — pas ce qui peut arriver au patient par ailleurs.
3. Le raisonnement, étape par étape
Identifier les situations dangereuses
Quelles défaillances du logiciel peuvent contribuer à une situation dangereuse ? Sortie fausse, absence de sortie, sortie tardive, sortie attribuée au mauvais patient, arrêt inopiné. Ce travail relève de l'ISO 14971 et il doit précéder la classification.
Évaluer le dommage sans mesure de maîtrise
Première évaluation, la plus sévère : si rien ne rattrape la défaillance, quel est le pire dommage possible ? C'est le point de départ.
Appliquer les mesures de maîtrise externes au logiciel
C'est ici que la classe peut descendre. La norme permet de tenir compte des mesures de maîtrise du risque — à condition qu'elles soient externes au logiciel concerné. Une vérification faite par le logiciel lui-même ne compte pas : si le logiciel défaille, sa propre vérification défaille aussi.
Comptent en revanche : un dispositif matériel indépendant, une alarme externe, une procédure de vérification humaine documentée dans la notice, une seconde source d'information indépendante.
Réévaluer le dommage résiduel
Compte tenu de ces mesures, quel dommage reste possible ? La réponse donne la classe.
Classer chaque élément logiciel
La classification s'applique au système logiciel, mais aussi à ses éléments. Un élément peut avoir une classe inférieure à celle du système s'il est correctement isolé — voir la ségrégation ci-dessous.
L'argument « c'est le professionnel de santé qui vérifie » ne fonctionne que s'il est réellement opposable : la vérification doit être décrite dans la notice, réalisable en pratique, et le professionnel doit disposer d'une information indépendante pour l'effectuer. Un « le médecin garde le contrôle » non étayé ne réduit aucune classe.
4. Où la classe doit être justifiée
C'est le constat que nous voyons le plus souvent, et il est coûteux.
Beaucoup de dossiers annoncent la classe de sécurité dans le plan de développement logiciel — sous forme d'affirmation. « Le logiciel est de classe A. » Point.
Or la norme demande que la classification résulte de l'analyse de risque. Le raisonnement — situations dangereuses, dommages possibles, mesures de maîtrise externes retenues, dommage résiduel — doit figurer dans le rapport de gestion des risques. Le plan de développement s'y réfère, il ne le remplace pas.
Une classe affirmée sans démonstration n'est pas une classification. C'est une déclaration d'intention.
Pourquoi c'est cher : si l'organisme notifié rejette une classe A non justifiée et retient une classe B, ce ne sont pas quelques paragraphes à ajouter. Ce sont plusieurs sections du cycle de vie qui deviennent applicables rétroactivement, sur un logiciel déjà développé.
5. Ce que chaque classe implique
La norme module les exigences du cycle de vie selon la classe. Les grandes différences :
| Exigence | A | B | C |
|---|---|---|---|
| Plan de développement | Oui | Oui | Oui |
| Analyse des exigences | Oui | Oui | Oui |
| Conception architecturale | — | Oui | Oui |
| Conception détaillée | — | — | Oui |
| Vérification des unités logicielles | — | Oui | Oui, avec critères d'acceptation renforcés |
| Tests d'intégration | — | Oui | Oui |
| Tests système | Oui | Oui | Oui |
| Gestion des SOUP | Oui | Oui | Oui, avec exigences supplémentaires |
| Gestion des anomalies | Oui | Oui | Oui |
En classe A, plusieurs sections du §5.3 à §5.5 ne s'appliquent pas — d'où l'attrait de cette classe. Mais attention : la gestion des SOUP, la gestion de configuration, la gestion des anomalies et la maintenance s'appliquent à toutes les classes. Une classe A n'est pas une dispense de documentation.
Les SOUP, quelle que soit la classe
Un SOUP — software of unknown provenance — est tout composant que vous intégrez sans maîtriser son cycle de développement : bibliothèque tierce, framework, composant open source, module racheté. Pour chacun, la norme demande de documenter le nom, la version, le fabricant, la fonction assurée, les exigences qu'il doit satisfaire, et de surveiller les anomalies publiées le concernant.
Sur une application web moderne, la liste peut compter des centaines d'entrées. Deux conseils : générez-la automatiquement depuis votre gestionnaire de dépendances plutôt que de la tenir à la main, et distinguez les dépendances qui participent réellement à la fonction médicale de celles qui relèvent de l'outillage de développement.
6. Réduire la classe par ségrégation
La norme prévoit explicitement qu'un élément logiciel peut être classé plus bas que le système qui le contient, à condition d'être correctement isolé des éléments de classe supérieure.
C'est un levier puissant et sous-utilisé. Concrètement : si seule une fonction sur vingt peut contribuer à un dommage grave, il n'est pas nécessaire de traiter l'ensemble du produit en classe C.
Mais l'isolation doit être démontrée, pas affirmée. Il faut documenter :
- la frontière entre les éléments, dans l'architecture
- le mécanisme technique qui garantit qu'une défaillance d'un élément de classe basse ne peut pas affecter un élément de classe haute — processus séparés, isolation mémoire, contrôle d'intégrité des échanges
- la justification que ce mécanisme est lui-même fiable
Cette démonstration a un coût. Elle vaut le coup quand la partie critique est petite, beaucoup moins quand elle irrigue tout le produit.
7. Quatre erreurs fréquentes
Confondre classe du dispositif et classe logicielle
« Nous sommes en classe IIa donc le logiciel est en classe B. » Non — les deux raisonnements sont indépendants.
Compter des mesures internes au logiciel
« Le logiciel vérifie la cohérence de ses sorties. » Cette vérification tombe en même temps que le logiciel. Elle ne réduit pas la classe.
Croire que la classe A dispense de tout
Elle allège le §5, pas le reste. Plan, exigences, tests système, SOUP, configuration, anomalies, maintenance : tout reste dû.
Croire que l'agilité est incompatible
Elle ne l'est pas. L'IEC 62304 décrit des processus et des livrables, pas un cycle en V. Le rapport technique AAMI TIR45 documente précisément l'articulation entre développement agile et exigences de la norme. Ce qui est exigé, c'est la traçabilité entre exigence, conception, code et test — pas un enchaînement séquentiel de phases.
Cet article présente une méthode générale. La classification d'un logiciel donné dépend de son analyse de risque, de son architecture et de ses conditions d'utilisation réelles. Elle s'établit sur pièces, pas sur principe.