IEC 62304 pour les équipes logicielles : classes de sécurité, livrables exigés et intégration dans Git et la CI

Réponse directe

L'IEC 62304 est la norme de cycle de vie du logiciel de dispositif médical, y compris le logiciel qui est un dispositif médical à part entière (logiciel dispositif médical, ou SaMD). Chaque système logiciel reçoit une classe de sécurité A, B ou C selon le dommage auquel il peut contribuer une fois prises en compte les mesures de maîtrise du risque externes, et cette classe détermine les activités et les documents obligatoires. Gestion de configuration, résolution de problèmes, maintenance et tests système s'appliquent à toutes les classes ; l'architecture, les tests d'intégration et l'essentiel de l'analyse de risque logicielle commencent en classe B ; la conception détaillée des unités ne concerne que la classe C. Aucun cycle en cascade n'est imposé : pull requests revues, rapports de tests de CI et versions taguées peuvent constituer les enregistrements, à condition d'être planifiés, maîtrisés et traçables.

Quelle version s'applique en 2026

Le texte en vigueur est l'IEC 62304:2006+AMD1:2015, édition consolidée 1.1. Une deuxième édition est en préparation depuis plusieurs années. QuickBird Medical indiquait en septembre 2026 que l'IEC prévoit désormais une publication le 26 octobre 2028, après un volume important de commentaires sur le projet de comité de 2025. Les projets diffusés jusqu'ici proposent de remplacer les classes A/B/C par deux niveaux de rigueur de processus et d'élargir le périmètre à l'ensemble des logiciels de santé. Prenez-le comme une orientation : travaillez sur l'édition 1.1 aujourd'hui et gardez des documents de processus assez modulaires pour être réaffectés plus tard.

La place de l'IEC 62304 parmi les autres normes et réglementations

L'IEC 62304 couvre le cycle de vie du logiciel, et rien d'autre. Elle suppose que l'environnement existe déjà :

Deux points réglementaires comptent pour la planification. Dans l'UE, l'EN 62304 était harmonisée sous l'ancienne directive 93/42/CEE, mais elle ne figure pas dans les listes de normes harmonisées au titre du MDR publiées jusqu'à mi-2026 : elle ne confère donc pas de présomption de conformité formelle au titre du MDR. Les organismes notifiés la considèrent toujours comme l'état de l'art, si bien qu'en pratique personne ne s'en passe. Vérifiez la dernière liste récapitulative avant d'écrire « harmonisée » dans un dossier technique. Si vous devez encore déterminer si votre logiciel est un dispositif médical, commencez par le guide MDR pour les équipes logicielles et le MDCG 2019-11 rév.1.

Aux États-Unis, le guide FDA de juin 2023 Content of Premarket Submissions for Device Software Functions a remplacé l'ancien « level of concern » par un niveau de documentation Basic ou Enhanced. Pour l'élément « pratiques de développement, de gestion de configuration et de maintenance », il accepte une déclaration de conformité à la version de l'IEC 62304 reconnue par la FDA. Depuis le 2 février 2026, la Quality Management System Regulation intègre l'ISO 13485:2016 par référence : un seul SMQ ISO 13485 contenant les processus IEC 62304 peut donc servir les deux marchés.

Classification de sécurité logicielle et mesures de maîtrise du risque

L'amendement 1 a modifié la logique de classification. Le texte de 2015 attribue une classe à chaque système logiciel selon les situations dangereuses auxquelles il peut contribuer, après prise en compte des mesures de maîtrise du risque externes au logiciel :

• Classe A : le logiciel ne peut pas contribuer à une situation dangereuse, ou la situation dangereuse n'entraîne pas de risque inacceptable une fois les mesures externes prises en compte.
• Classe B : un risque inacceptable subsiste après les mesures externes, et le dommage possible est une blessure non grave.
• Classe C : un risque inacceptable subsiste après les mesures externes, et le dommage possible est le décès ou une blessure grave.

« Externe » signifie hors du système logiciel classé : un verrouillage matériel, un système logiciel indépendant, une procédure clinique. Un contrôle dans la même base de code ne fait pas baisser la classe de cette base de code. Trois règles piègent souvent les équipes :

1. Tant qu'aucune classe n'est attribuée, les exigences de la classe C s'appliquent (clause 4.3 g).
2. Les éléments logiciels héritent de la classe du système dont ils proviennent. Une classe inférieure pour un élément exige une justification documentée de sa ségrégation (4.3 d). En classe C, la clause 5.3.5 impose d'identifier cette ségrégation et d'en démontrer l'efficacité.
3. La classe est consignée dans le dossier de gestion des risques (4.3 c). C'est une décision de gestion des risques, prise conjointement avec les responsables du processus ISO 14971.

Exemple : un logiciel dispositif médical qui propose un bolus d'insuline. Si une valeur erronée peut atteindre le patient sans contrôle, il est en classe C. Si le circuit clinique impose à un clinicien de vérifier les données d'entrée et le résultat face à un calcul affiché avant administration, et que le dossier de gestion des risques montre que cette mesure ramène le risque à un niveau acceptable, l'équipe risques peut justifier la classe B. Cet argument doit résister à l'évaluation de l'aptitude à l'utilisation selon l'IEC 62366-1 ; une boîte de confirmation que les utilisateurs valident machinalement n'est pas une mesure efficace.

Un piège pour les dossiers déposés des deux côtés de l'Atlantique : le niveau de documentation FDA s'évalue avant l'application des mesures de maîtrise du risque. Un système justifié en classe B selon l'IEC 62304 peut tout de même exiger une documentation Enhanced pour la FDA.

Livrables exigés par classe

Ce tableau suit les mentions de classe du texte normatif de l'IEC 62304:2006+A1:2015 (le tableau A.1 de l'annexe A donne la même image).

La classe A est allégée, pas vide. Depuis l'amendement 1, un logiciel de classe A doit avoir des exigences, des tests système qui les couvrent, des enregistrements de libération, une gestion de configuration et une résolution de problèmes.

SOUP : ce que la norme demande

Un SOUP (software of unknown provenance, logiciel de provenance inconnue) désigne tout logiciel déjà développé qui n'a pas été conçu pour votre dispositif : bibliothèques open source, runtime du langage, système d'exploitation, SDK commercial, ou ancien code interne sans enregistrements de développement. Les obligations s'additionnent selon la classe :

• Toutes classes (8.1.2) : pour chaque élément de configuration SOUP, documenter le titre, le fabricant et un identifiant unique, par exemple une version ou un numéro de correctif. Les bibliothèques standard comptent.
• Classes B et C (5.3.3, 5.3.4) : spécifier les exigences fonctionnelles et de performance que le SOUP doit satisfaire pour votre usage prévu, ainsi que le matériel et les logiciels nécessaires à son fonctionnement.
• Classes B et C (7.1.3) : si une défaillance du SOUP peut contribuer à une situation dangereuse, évaluer au minimum la liste d'anomalies publiée par le fournisseur pour la version exacte livrée.

Un lockfile identifie les versions, mais ne dit pas pourquoi une bibliothèque est acceptable ni quels bugs connus ont été examinés. Générez un SBOM (CycloneDX ou SPDX) à chaque build de version, et tenez à côté un court registre des SOUP avec les exigences, la pertinence pour le risque et la date de la dernière revue d'anomalies. Pour les « cyber devices » aux États-Unis, la section 524B du FD&C Act exige déjà un SBOM dans la soumission (voir le guide FDA sur la cybersécurité) : le même artefact sert aux deux usages.

Transposer l'IEC 62304 dans Git et la CI

La norme demande la preuve que les activités planifiées ont eu lieu, sous la responsabilité de quelqu'un, sur une configuration connue. Une chaîne d'outils moderne produit déjà l'essentiel de ces preuves. Décrivez cette correspondance dans le plan de développement logiciel (5.1.1) ; sans cela, l'auditeur voit des outils sans processus.

Une convention de commit et de PR qui rend la matrice de traçabilité générable :

feat(dosing): clamp bolus suggestion to configured max

Implements: SRS-042
Risk-control: RCM-007 (HAZ-012 overdose suggestion)
Verified-by: test_bolus_clamped_to_max, SYS-TC-118
Ticket: CR-311

Une étape de pipeline minimale qui garde les preuves avec le build :

release-evidence:
  runs-on: ubuntu-24.04
  steps:
    - uses: actions/checkout@v4
    - run: npm ci
    - run: npm test -- --ci --reporters=default --reporters=jest-junit
    - run: npx @cyclonedx/cyclonedx-npm --output-file sbom.cdx.json
    - run: node scripts/trace-matrix.mjs --requirements docs/srs.yaml --junit junit.xml --out trace-matrix.csv
    - uses: actions/upload-artifact@v4
      with:
        name: release-evidence-${{ github.ref_name }}
        path: |
          junit.xml
          sbom.cdx.json
          trace-matrix.csv

Le script trace-matrix.mjs est le vôtre : il lit les identifiants d'exigences dans la spécification des exigences logicielles, parcourt les noms de tests et les trailers de PR, et fait échouer le build quand une exigence ou une mesure de maîtrise du risque n'a aucun test réussi. Ce contrôle bloquant pèse plus lourd en audit qu'un tableur maintenu à la main. La rétention des artefacts de CI est souvent courte : copiez les preuves de chaque version dans un stockage maîtrisé dont la durée correspond à la période d'archivage de la clause 5.8.7.

Deux règles de plus rendent l'ensemble défendable. Les outils qui produisent des enregistrements (CI, script de traçabilité, outil de tickets) doivent être validés pour leur usage prévu selon la clause 4.1.6 de l'ISO 13485, proportionnellement au risque. Et les paramètres de protection de branche font partie de votre processus : leurs modifications passent par la maîtrise des modifications.

Constats d'audit fréquents

Ces constats reviennent régulièrement, quelle que soit la taille de l'entreprise :

• Classification sans lien avec le risque : classe B ou A revendiquée sans référence aux dangers, aux mesures externes ni aux entrées du dossier de gestion des risques qui la justifient.
• Liste de SOUP sans versions ni revue d'anomalies : « React, PostgreSQL, Python », sans identifiant, et sans preuve que quelqu'un a lu la liste des problèmes connus pour la version livrée.
• Trous de traçabilité : mesures de maîtrise du risque non traduites en exigences logicielles (5.2.3), ou traduites mais jamais testées.
• Modifications auto-approuvées : l'auteur a fusionné sa propre PR, ou un administrateur a contourné la protection de branche sans motif enregistré.
• Version construite sur un poste de développeur : aucun environnement de build documenté, donc le binaire livré n'est pas reproductible (5.8.5).
• Anomalies résiduelles listées mais non évaluées : l'export des bugs ouverts existe, l'évaluation du risque de chacun manque (5.8.3).
• Plan obsolète : le plan de développement logiciel décrit un processus abandonné depuis deux ans (5.1.2).
• Aucune analyse de tendances sur les rapports de problème (9.6), ce qui affaiblit aussi la surveillance après commercialisation.

Pour aller plus loin

L'IEC 62304 recoupe d'autres obligations sur la même base de code : les composants d'IA ajoutent les exigences de l'AI Act, les déploiements en établissement de santé entraînent les obligations de sécurité NIS2, et le panorama de la conformité santé en Europe montre comment ces textes s'articulent. Si vous cherchez une équipe qui développe du logiciel dispositif médical avec cette chaîne de preuves dès le premier sprint, voir développement HealthTech.

Cet article est un guide d'ingénierie, pas un avis réglementaire ou juridique. Validez la classification et la stratégie de conformité avec votre responsable affaires réglementaires et votre organisme notifié.