La doc 62304 qui s'écrit toute seule : notre pipeline CI/CD

La documentation 62304 a mauvaise réputation chez les développeurs : des documents Word maintenus à la main, toujours en retard d’une release sur le code, remplis la veille de l’audit. C’est le symptôme d’une erreur d’architecture documentaire. Le principe correct : la documentation naît du code. Chaque exigence de la norme qui porte sur un fait vérifiable — quelles dépendances, quels tests, quelle version, qui a revu quoi — doit être produite par le pipeline, pas recopiée par un humain.

Pourquoi générer la doc plutôt que la rédiger ?

Définition : la documentation générée est un artefact de build — produite automatiquement à chaque release depuis des sources de vérité uniques (dépôt Git, lockfiles, gestionnaire de tickets, rapports de tests) — par opposition à la documentation rédigée, maintenue manuellement. L’IEC 62304 exige des enregistrements exacts du cycle de vie. Or un document maintenu à la main diverge du code dès la deuxième semaine. Un document généré est exact par construction : s’il est faux, c’est que le build est faux, et ça se voit.

Un document 62304 écrit à la main est périmé au moment où on le signe. Un document généré est exact par construction.

Quel mapping entre exigences 62304 et artefacts CI ?

La SOUP list depuis les lockfiles

Chaque dépendance tierce est un SOUP (Software Of Unknown Provenance) au sens 62304. Le pipeline génère un SBOM CycloneDX depuis les lockfiles (Syft, Trivy ou le plugin natif de votre écosystème), puis le rapproche d’un registre SOUP maintenu dans le dépôt : pour chaque composant, exigences fonctionnelles, version exacte, anomalies connues. Le build échoue si une dépendance apparaît dans le SBOM sans entrée au registre. Résultat : la SOUP list ne peut structurellement pas être incomplète.

La traçabilité depuis les IDs de tickets

Convention simple : chaque exigence logicielle a un ID (ticket Jira/Linear/GitHub), chaque test qui la vérifie porte cet ID (annotation, tag ou nom de test), chaque commit référence son ticket. Le pipeline parse les rapports de tests et produit la matrice exigence → tests → résultat → version. Une exigence sans test fait échouer le job de traçabilité. C’est la matrice que l’auditeur demande en premier — et elle est toujours à jour.

Les revues via PR

La 62304 exige des vérifications documentées. Une PR avec revue obligatoire, approbation nominative et checks verts est un enregistrement de vérification : approbateur, date, contenu revu, critères passés. Il suffit de configurer la protection de branche (pas de merge sans approbation ni CI verte) et d’exporter les métadonnées de PR dans le paquet de release. Aucun formulaire de revue à remplir à part.

À quoi ressemble le pipeline ?

Étapes nommées d’après ce qu’elles prouvent :

stages:
  - build              # artefact reproductible, version = tag Git
  - sbom               # SBOM CycloneDX + contrôle registre SOUP
  - unit-tests         # rapport 5.5 + couverture
  - integration-tests  # rapport 5.6
  - system-tests       # rapport 5.7, tagués par ID d'exigence
  - traceability       # matrice exigences <-> tests, échec si trou
  - security-scan      # SCA/SAST (au passage : 81001-5-1)
  - release-package    # manifeste de version, release notes,
                       # anomalies connues, export approbations PR

Le job release-package assemble le tout dans une archive versionnée et immuable : c’est votre enregistrement de release 62304, prêt à être déposé dans le SMQ. La release note elle-même est générée depuis les commits et les tickets liés — modifications, anomalies corrigées, anomalies résiduelles.

Qu’est-ce qui ne s’automatise pas ?

Tout ce qui relève du jugement reste humain, et c’est normal :

• L’intended use et la classification : décisions réglementaires, pas des artefacts de build.
• L’analyse de risque ISO 14971 : le pipeline peut lier un test à une mesure de maîtrise de risque, mais l’identification des dangers et l’évaluation de l’acceptabilité sont un travail d’équipe pluridisciplinaire.
• La justification de la classe de sécurité logicielle (A/B/C) et la stratégie de ségrégation.
• L’évaluation de chaque SOUP : l’outil détecte le composant, un humain juge si ses anomalies connues sont acceptables pour l’usage prévu.
• Les plans (développement, maintenance, configuration) : rédigés une fois, versionnés dans le dépôt, revus par PR comme du code.

L’automatisation ne remplace pas ces activités : elle les débarrasse de la paperasse pour qu’elles reçoivent le temps qu’elles méritent.

Quels gains constatés ?

Sur les projets où j’ai mis ce dispositif en place, trois effets se répètent :

1. Le coût marginal d’une release documentée tend vers zéro. Livrer une version auditable ne demande plus une semaine de rédaction : c’est un tag Git. Les équipes qui livraient deux fois par an peuvent livrer chaque mois sans dette documentaire.
2. Les audits se passent en démonstration, pas en archéologie. Montrer un pipeline qui échoue quand la traçabilité a un trou est plus convaincant qu’un classeur — les auditeurs comprennent vite que le système ne peut pas produire une release non documentée.
3. Les développeurs cessent de subir la qualité. Quand la conformité passe par les mêmes outils que le reste du travail (Git, CI, tickets), elle cesse d’être un pensum parallèle et devient une propriété du système.

Commencez par le SBOM et la matrice de traçabilité : ce sont les deux artefacts les plus demandés en audit et les plus simples à générer. Le reste s’ajoute release après release.