Automatiser 80 % de sa doc IEC 62304 sans se faire recaler : la frontière homme–IA

Rédiger un document d’architecture logicielle (SSA) pour un dispositif médical de Classe B prend deux à trois jours à la main. Pas parce que les architectes ignorent leur architecture — ils la connaissent — mais parce que la documentation réglementaire est un métier distinct de la conception, qui se répète à chaque version, chaque audit, chaque release. L’IA promet d’en absorber l’essentiel. La vraie question n’est pas « peut-on l’automatiser ? » mais « le dossier tiendra-t-il devant un organisme notifié ? ». La réponse tient dans une frontière disciplinée : 80 % de mécanique automatisable, 20 % de jugement irréductiblement humain.

Pourquoi 80 % d’un dossier IEC 62304 est-il mécanique ?

Définition : un document d’architecture logicielle a deux couches — un socle identique à tous vos dispositifs, et un contenu spécifique à chaque produit. Une fois cette séparation posée, le document n’est plus qu’un gabarit avec des paramètres.

• Couche 1 — le socle : hébergement, pile de sécurité (WAF, pare-feu nouvelle génération, SIEM), pipeline CI/CD (audit de dépendances, SAST, SBOM), modèle d’isolation multi-tenant, voie de mise à jour. C’est la même infrastructure pour tous les dispositifs que vous expédiez.
• Couche 2 — le spécifique : identité et version du produit, classification IEC 62304, classe MDR, acteurs cliniques, entrées/sorties, cas d’usage, états du cycle de vie logiciel, composants tiers hors socle, scénarios de menace propres.

La couche 1 se fige dans le gabarit. La couche 2 tient dans un manifeste que vous remplissez par produit. Le générateur ne fait que combiner les deux — structure, texte standard, figures, références croisées. C’est ce périmètre-là, purement répétitif, qui pèse 80 % du temps et qui rend la documentation pourrissante : une section à reformuler pour l’audit, un inventaire de tiers à jour il y a six mois, un diagramme exact techniquement mais illisible pour le dossier.

Que peut-on automatiser sans risque ?

Tout ce qui est vérifiable de façon déterministe :

• La structure et le texte standard : les sections récurrentes, le socle d’infrastructure, les formulations réglementaires stables.
• Les figures : diagrammes d’architecture, C4, cas d’usage, états, déploiement — générés depuis le manifeste, jamais dessinés à la main deux fois.
• La traçabilité et les références croisées : chaque cas d’usage relié à son acteur et à son périmètre (dispositif médical ou non), chaque exigence à sa figure.
• La mise en forme : conversion en Word aux styles et à la charte maison, table des matières, en-têtes — un livrable qui ressemble à un document d’entreprise, pas à une sortie de script.

Ces éléments partagent une propriété : s’ils sont faux, le contrôle automatique le voit (un champ manquant, une figure qui ne compile pas, un périmètre non déclaré). C’est exactement ce que l’automatisation sait garantir.

Quels 20 % un humain doit-il garder ?

C’est le cœur du système : rendre les 20 % explicites plutôt que de les noyer. Voici ce qui exige un jugement, et pourquoi il ne se calcule pas.

Un outil qui prétend décider ces points-là ne fait pas gagner du temps : il fabrique un dossier qui sera contesté au premier audit.

Le garde-fou qui rend le dossier défendable

C’est la pièce que la plupart des articles « docs générées par IA » oublient — et la plus importante en contexte réglementaire.

Chaque génération produit, à côté du document, un rapport d’audit distinct destiné au lead dev et au référent réglementaire. Il attribue à chaque section un niveau de confiance — ÉLEVÉ / MOYEN / FAIBLE — selon des heuristiques : combien de champs proviennent directement du manifeste, la section contient-elle du texte libre non générable, faut-il un renvoi vers un autre document du système qualité. Deux sections sont plafonnées à MOYEN quelle que soit l’heuristique : l’inventaire des composants tiers (toujours à recroiser) et le bloc d’approbation (signatures humaines).

En parallèle, chaque affirmation à valider est surlignée dans le document (un marqueur « à confirmer » que le référent voit instantanément) : destination, cotations de risque, versions. Le flux de relecture devient trivial : traiter les FAIBLE d’abord, puis les MOYEN, vérifier les ÉLEVÉ en survol, puis lire chaque passage surligné.

Ce n’est pas « l’IA l’a fait, signez ». C’est un transfert structuré qui rend les 20 % explicites, nommés, et attribués à la personne la mieux placée pour juger.

C’est précisément ce qui rend un dossier généré défendable : non pas parce qu’une machine l’a produit, mais parce que le jugement humain y est tracé, pas supposé.

Quels résultats concrets ?

Sur un module de planification chirurgicale 3D en production, après trois mois d’usage :

• Génération complète du dossier : ~4 minutes (contre 2-3 jours de rédaction manuelle).
• Relecture réglementaire : ~2 heures — et c’est là que se concentre désormais la valeur.
• 10 figures générées automatiquement, ~25 points à valider signalés par run.

Le gain n’est pas « l’humain disparaît ». C’est l’inverse : le coût marginal d’un dossier auditable tend vers zéro, et le temps d’expert se reporte entièrement sur les 20 % qui comptent. Le pipeline complet — notre approche de la doc 62304 générée depuis la CI/CD — repose sur le même principe : la documentation naît des sources de vérité, l’humain garde le jugement.

Cette frontière — l’automatisation collecte, l’humain juge — n’est pas propre au dossier 62304 : elle structure aussi la conformité de sécurité de l’information, où la conformité-as-code collecte en continu les preuves SOC 2 et ISO 27001 sans jamais produire, elle non plus, le dossier réglementaire du dispositif.

FAQ

Un organisme notifié accepte-t-il une documentation générée automatiquement ?

Oui. Ce qui compte n’est pas comment le document est produit, mais qu’il soit exact, tracé et validé par les bonnes personnes. Un dossier généré puis relu et signé est aussi recevable qu’un dossier tapé à la main — souvent plus cohérent, car la structure et la traçabilité ne peuvent pas dériver.

L’IA peut-elle décider la classe IEC 62304 de mon logiciel ?

Non. La classe (A, B ou C) dépend de la contribution possible d’une défaillance à une situation dangereuse — c’est un jugement à valider contre votre Level of Concern, cohérent avec la classification MDR de votre dispositif. L’outil prend la classe telle qu’on la lui fournit ; il ne la décide jamais.

Combien de temps pour mettre ça en place ?

Comptez quelques semaines pour le premier gabarit + manifeste — le vrai travail est de séparer une fois le socle (couche 1) du spécifique (couche 2). Ensuite, le coût marginal de chaque nouveau dossier s’effondre. L’implémentation technique complète (pipeline, gabarits, code) est détaillée dans mon retour d’expérience sur Medium.