Introduction
Développer un logiciel qui traite des images DICOM ou qui intègre de l’intelligence artificielle pour aider au diagnostic n’est pas comparable au développement d’une application e-commerce. Quand une erreur logicielle peut potentiellement affecter la santé d’un patient, les règles du jeu changent radicalement.
C’est là qu’intervient QARA - Quality Assurance and Regulatory Affairs - un domaine qui structure l’ensemble du cycle de vie des dispositifs médicaux logiciels.
Qu’est-ce que QARA ?
QARA combine deux disciplines complémentaires :
Quality Assurance (QA) — L’ensemble des processus systématiques qui garantissent que le logiciel répond aux exigences de qualité définies. Cela inclut la gestion des risques, la traçabilité des exigences, les tests de validation, et l’amélioration continue.
Regulatory Affairs (RA) — La veille et la conformité aux réglementations applicables selon les marchés visés. Un logiciel d’imagerie médicale commercialisé en Europe et aux États-Unis doit satisfaire simultanément le MDR européen et les exigences de la FDA.
Le Cadre Réglementaire
Classification des Logiciels Médicaux
Les logiciels médicaux sont classifiés selon leur niveau de risque :
| Classe | Risque | Exemple |
|---|---|---|
| Classe I | Faible | Visualiseur DICOM basique |
| Classe IIa | Modéré | Logiciel de mesure, reconstruction 3D |
| Classe IIb | Élevé | Aide au diagnostic assistée par IA |
| Classe III | Critique | Planification chirurgicale autonome |
Plus la classe est élevée, plus les exigences documentaires et de validation sont strictes.
Les Normes Fondamentales
IEC 62304 — La norme incontournable pour le cycle de vie du développement logiciel médical. Elle définit trois niveaux de sécurité (A, B, C) et impose des exigences croissantes en termes de documentation, tests et traçabilité.
ISO 13485 — Le système de management de la qualité spécifique aux dispositifs médicaux. Elle structure l’organisation, les processus et la documentation.
ISO 14971 — La gestion des risques appliquée aux dispositifs médicaux. Chaque fonctionnalité doit faire l’objet d’une analyse de risque documentée.
IEC 82304 — Spécifique aux logiciels de santé autonomes (standalone health software).
Projet Dispositif Médical vs Projet Classique : Les Différences Fondamentales
Avant de plonger dans les détails techniques, il est essentiel de comprendre ce qui distingue fondamentalement un projet de dispositif médical (DM) d’un projet logiciel classique.
Le Changement de Mindset
En Projet Classique
“Ship fast, fix fast” “Move fast and break things” “Good enough is good enough” “Documentation = waste”
L’objectif est la vélocité. Un bug en production ? On hotfix. Une feature bancale ? On itère. La dette technique se gère au fil de l’eau.
En Projet Dispositif Médical
“Ship right, ship safe” “Move deliberately and heal things” “Good enough must be proven good enough” “Documentation = evidence”
L’objectif reste la vélocité, mais encadrée par la sécurité. Un bug en production sur un logiciel d’aide au diagnostic ? C’est potentiellement un incident de matériovigilance à déclarer aux autorités.
Les Questions Qu’on Ne Se Pose Pas en Projet Classique
En projet DM, chaque décision technique soulève des questions supplémentaires :
Avant d’implémenter une fonctionnalité :
- Quel est l’impact sur la classification du dispositif ?
- Cette fonctionnalité introduit-elle de nouveaux risques ?
- Comment prouver qu’elle fonctionne comme attendu ?
Avant de corriger un bug :
- Ce bug a-t-il un impact sur la sécurité patient ?
- Faut-il déclarer un incident ?
- La correction nécessite-t-elle une re-validation ?
Avant de refactorer du code :
- Ce refactoring affecte-t-il des modules critiques ?
- La traçabilité est-elle préservée ?
- Les tests existants couvrent-ils les régressions potentielles ?
Avant de mettre à jour une dépendance :
- Cette mise à jour est-elle qualifiée pour un usage médical ?
- Introduit-elle des changements de comportement ?
- Le SBOM (Software Bill of Materials) est-il mis à jour ?
Le Cycle de Vie Étendu
Un projet classique vit souvent 3 à 5 ans avant refonte majeure. Un dispositif médical doit être maintenu et traçable pendant toute sa durée de commercialisation, plus les obligations post-market :
Développement (2 ans) → Certification (6 mois) → Commercialisation (10+ ans) → Surveillance Post-Market (Continue) → Fin de vie (Archivage 15 ans)
Cela signifie :
- Conserver tous les artefacts de développement
- Pouvoir reconstruire n’importe quelle version
- Maintenir la documentation à jour pendant des années
- Gérer les obsolescences (OS, frameworks, dépendances)
La Gestion des Incidents
Projet classique :
Bug détecté → Ticket créé → Priorisé → Corrigé → Déployé → Fermé
Projet DM :
Bug détecté → Évaluation impact sécurité → Classification de l’incident
- Impact sécurité ? OUI → Processus CAPA + Notification autorités si nécessaire
- Impact sécurité ? NON → Processus standard mais documenté
CAPA (Corrective and Preventive Action) est un processus formel qui exige d’analyser la cause racine, de documenter les actions correctives, et de prouver leur efficacité.
Ce Qui Reste Identique
Malgré ces différences, les fondamentaux du bon développement logiciel restent les mêmes :
- Écrire du code propre et maintenable
- Tester de manière exhaustive
- Faire des revues de code
- Automatiser ce qui peut l’être
- Livrer de la valeur aux utilisateurs
- S’améliorer continuellement
La différence réside dans le niveau de formalisme et de preuve exigé pour chaque activité.
Impact Concret sur le Développement en Imagerie Médicale
1. Traçabilité de Bout en Bout
Chaque ligne de code doit pouvoir être tracée jusqu’à une exigence, elle-même liée à un besoin utilisateur et à une analyse de risque :
Besoin Utilisateur → Exigence Système → Exigence Logicielle → Code → Test → Validation
En pratique, cela signifie :
- Des user stories liées à des requirements formels
- Des commits référençant des tickets traçables
- Des tests unitaires et d’intégration mappés aux exigences
- Une matrice de traçabilité maintenue à jour
2. Gestion des Risques Intégrée
Pour un logiciel d’imagerie médicale avec IA, l’analyse de risque couvre des scénarios comme :
- Que se passe-t-il si l’algorithme rate une anomalie sur une image ?
- Que se passe-t-il si les données DICOM sont corrompues pendant le transfert ?
- Que se passe-t-il si le modèle IA produit un faux positif ?
Chaque risque identifié doit avoir des mesures de mitigation implémentées et testées.
3. Validation des Algorithmes d’IA
Les logiciels d’imagerie médicale intégrant de l’IA (Software as Medical Device - SaMD) font face à des exigences spécifiques :
- Datasets de validation : Constitution de jeux de données représentatifs, annotés par des experts, avec une diversité démographique documentée
- Métriques de performance : Sensibilité, spécificité, AUC, intervalles de confiance
- Locked vs Adaptive algorithms : Un algorithme qui évolue après déploiement nécessite un cadre de surveillance continue
- Explicabilité : Documenter comment l’algorithme arrive à ses conclusions
4. Documentation Exhaustive
Un logiciel d’imagerie médicale classe IIb génère typiquement :
- Software Requirements Specification (SRS)
- Software Design Specification (SDS)
- Software Architecture Document
- Risk Management File
- Verification & Validation protocols
- User Manual
- Installation Qualification (IQ) / Operational Qualification (OQ)
- Release notes détaillées
5. Gestion du Changement
Toute modification - même mineure - déclenche un processus formel :
- Évaluation de l’impact sur les risques
- Mise à jour de la documentation affectée
- Tests de régression
- Revue et approbation
- Mise à jour de la matrice de traçabilité
Un simple refactoring qui améliore la lisibilité du code doit être évalué et documenté.