En bref
IEC 62304 exige des processus et des preuves de cycle de vie, pas un outil particulier. Les équipes SaMD qui travaillent déjà dans Jira et GitHub peuvent y mapper exigences, conception, vérification, configuration, maintenance et résolution de problèmes, à condition de combler les trous de traçabilité. Une couche de conformité / eQMS orchestre ces preuves sans imposer une migration ALM. L’Édition 1 reste la référence publiée ; l’Édition 2 approche (voir où en est la révision).
Ce qu’IEC 62304 attend (aujourd’hui)
La norme structure le cycle de vie du logiciel de dispositif médical : planification, analyse des exigences, architecture et conception détaillée, implémentation, vérification, gestion de configuration, résolution de problèmes, maintenance, et prise en compte du logiciel d’origine inconnue (SOUP). La classification de sécurité logicielle (classes A, B ou C dans l’Édition 1) module la profondeur des activités. Rien dans le texte n’impose Jira, GitHub ni une suite ALM : ce qui compte, c’est que les processus existent, soient proportionnés à la classe, et que les preuves soient récupérables pour un audit.
En pratique, la douleur n’est pas « manquer de tickets » : c’est la désynchro entre le flux de développement, le SMQ et le dossier technique. Le bon réflexe est de décider quels artefacts vivent où, puis de rendre les liens exigence → conception → vérification → release explicites.
Mapper le cycle de vie dans Jira
Jira porte bien le travail planifié et les décisions de priorité. Une cartographie utile (à adapter, pas à copier aveuglément) :
-
Epics / initiatives
Lots de fonctionnalités ou versions, reliés au plan de développement logiciel.
-
Stories / exigences
Exigences logicielles (sécu / perfs), statut, propriétaire, lien analyse de risques.
-
Tasks / sous-tâches
Conception, implémentation, revue, tests unitaires ou d’intégration.
-
Bugs / problem reports
Anomalies, sévérité, impact patient / utilisateur, CAPA si le SMQ l’exige.
-
Workflows
Revue et acceptation (pas seulement Done), transitions par rôle.
Ajoutez des champs ou labels pour la classe de sécurité (A/B/C), le système / sous-système logiciel, et le type d’artefact 62304. Sans ce minimum de métadonnées, l’export audit devient un chantier manuel à chaque jalon.
Mapper preuves et configuration dans GitHub
GitHub porte le code, les revues et souvent la CI. Pour IEC 62304, l’intérêt n’est pas le volume de commits : c’est la capacité à retrouver, pour une release donnée, ce qui a changé, qui a revu, et quels tests ont passé.
Pull requests
Une PR liée à un ticket Jira, avec revue, description des impacts et critères de test, constitue une preuve de conception / implémentation et de vérification partielle. Exigez le lien ticket dans le template PR.
Commits et tags
Messages conventionnels et tags de release (semver ou équivalent) ancrent la configuration logicielle. Le tag de release doit pointer vers le build testé et documenté, pas seulement vers « main ».
CI et releases
Pipelines de build / test / analyse statique archivés par release, plus notes de release, forment une base de vérification et de gestion de configuration. Conservez les logs et artefacts de façon récupérable.
Pour le SOUP : inventaire des dépendances (lockfiles, SBOM), justification d’usage, suivi des vulnérabilités et anomalies connues, et impact sur la classification. Les outils de dépendance aident ; ils ne remplacent pas l’évaluation documentée.
Les trous de traçabilité les plus fréquents
Les audits butent rarement sur « il n’y a pas de Jira ». Ils butent sur les chaînes cassées :
- exigence logicielle sans lien vers test de vérification ni vers risque ;
- changement de code mergé sans ticket, ou ticket clos sans preuve de test ;
- release déployée sans baseline de configuration (commit, SBOM, environnement) ;
- problème terrain traité en chat, jamais rouvrant le processus de résolution de problèmes ;
- maintenance et patches hors du change control SMQ.
Une matrice exigences ↔ conception ↔ vérification ↔ release, générée ou tenue à jour depuis Jira/GitHub, réduit ce risque. Si la matrice n’existe que dans un tableur déconnecté, elle dérive dès le premier sprint sous pression.
Où s’arrêtent les DevTools, où commence la couche conformité
Jira et GitHub excellent à produire des artefacts de développement. Ils ne remplacent pas le SMQ (CAPA, formation, doc control, revue de direction) ni l’orchestration des preuves pour un organisme notifié. C’est là qu’une couche comme Qapsule, branchée sur la stack existante, et un eQMS dans vos outils, prennent leur sens : centraliser preuves et traçabilité sans forcer une migration ALM. Pour situer ce choix face à d’autres références marché, voir Qapsule vs Ketryx et alternatives.
Édition 2 : anticiper sans basculer trop tôt
L’Édition 2 est encore en révision (publication prévue 2028 selon le tracker IEC) ; les drafts convergent vers deux niveaux de rigueur à la place des classes A/B/C, plus des clarifications cloud et IA. Gardez le mapping A/B/C opérationnel, et esquissez déjà une table de correspondance vers les futurs niveaux. Détail calendrier et impacts : IEC 62304 Édition 2 : où en est vraiment la révision ?
Plan d’action
- Listez les clauses IEC 62304 applicables à votre classe et le document / outil maître pour chacune.
- Définissez types d’issues Jira, champs (classe A/B/C, système logiciel) et workflows de revue.
- Imposez le lien ticket ↔ PR GitHub, et archivez CI + tags de release par version logicielle.
- Tenez un inventaire SOUP à jour, relié aux releases et aux anomalies.
- Construisez (ou générez) la matrice exigences ↔ vérification ↔ release et testez-la sur un audit blanc.
- Branchez résolution de problèmes et maintenance sur le change control / CAPA du SMQ.
- Décidez si une couche conformité / eQMS sur la stack actuelle suffit, avant d’envisager une suite ALM.
Conclusion
IEC 62304 se joue dans la discipline des preuves, pas dans le choix d’une marque d’outil. Jira et GitHub peuvent porter le cycle de vie SaMD si la traçabilité est conçue exprès ; la couche qualité orchestre ce que les DevTools ne ferment pas seuls.
FAQ
Jira et GitHub suffisent-ils pour être « conforme » IEC 62304 ?
Non. Les outils n’apportent pas de certification. Ils peuvent porter les artefacts du cycle de vie (exigences, tâches, PRs, releases, tickets de problèmes) si vos procédures, classifications et preuves sont définies et tenues à jour.
Faut-il migrer vers une suite ALM pour le SaMD ?
Pas forcément. Beaucoup d’équipes gardent Jira et GitHub et ajoutent une couche de conformité / eQMS pour industrialiser preuves et traçabilité. Une suite native n’est pertinente que si vous manquez vraiment de référentiel et acceptez la migration. Voir notre comparatif.
Où documenter la classification de sécurité logicielle ?
Dans le dossier logiciel / plan de développement, avec une justification liée à l’analyse de risques. Dans Jira, un champ ou un label de classe (A/B/C aujourd’hui) sur les items concernés aide la cohérence, sans remplacer le document maître.
Comment traiter le SOUP dans GitHub ?
Maintenez un inventaire SOUP (dépendances, versions, justification, anomalies connues) relié aux composants et releases. Les manifests (lockfiles), SBOM et tickets d’anomalie fournissent des preuves, pas une conformité automatique.
L’Édition 2 change-t-elle déjà le mapping Jira ?
Pas encore opérationnellement : l’Édition 1 reste la référence publiée. Surveillez la révision (classes vers niveaux de rigueur) et préparez une cartographie documentaire. Voir IEC 62304 Édition 2.
Guide QARA PULSE sur l’application opérationnelle d’IEC 62304 (Édition 1) avec Jira et GitHub. Ce n’est pas une certification, ni un avis juridique personnalisé. Adaptez le mapping à votre classification, à votre SMQ et aux attentes de votre organisme notifié.