L’innovation en santé est en plein essor. De nombreuses idées sont creusées chaque année pour améliorer le quotidien des patients et des professionnels de santé grâce à la tech. Certaines de ces idées vont nécessiter de construire des dispositifs médicaux numériques dont il est important de mesurer l’impact sur le fonctionnement de l’entreprise (Vous pouvez d’ailleurs lire Comment savoir mon innovation est un dispositif médical ?).
Dans le cadre du développement d’un logiciel certifié dispositif médical (SaMD), toute entreprise doit respecter les exigences de la norme 62304, relatives aux développements logiciels. Parmi les 80 pages de la norme, il est noté que :
Le FABRICANT doit établir un(des) plan(s) de développement du logiciel pour [...] c) la TRAÇABILITÉ entre les exigences du SYSTEME, les exigences du logiciel, les essais du SYSTEME LOGICIEL et les mesures de MAITRISE DU RISQUE mis en œuvre dans le logiciel.
L’intention de la norme est de pouvoir vérifier que le logiciel conçu dit ce qu’il fait et fait ce qu’il dit (pas plus, pas moins).
Ma tête quand j’ai lu la norme IEC 62304 pour la première fois
Néanmoins, cette assertion, anodine au premier abord a un impact non négligeable sur notre manière de travailler : tout fabricant doit être capable pour partie du logiciel, de justifier à quel URS/SRS est associée une ligne de code.
Ainsi, concrètement, comment répondre de manière efficace à cette exigence ?
Des logiciels de traçabilité dédiés vieillissants
Pour répondre aux besoins des entreprises de prouver cette exigence (qui s’applique d’ailleurs à d’autres domaines que la santé), de nombreux logiciels de traçabilité ont émergé sur le marché. Leur but est de pouvoir générer facilement des documents montrant la conformité des entreprises sur la traçabilité.
Néanmoins, ces logiciels, bien que complets, imposent plusieurs inconvénients:
- On doit mettre à jour sur le logiciel dédié l’ensemble des documents de notre dispositif médical. Si un collaborateur effectue une modification sur le document, il doit remettre à jour dans le logiciel. Cela augmente le risque d’avoir des documents non à jour si jamais l’entreprise décide de faire des copies des documents.
- Le logiciel a des balises bien spécifiques pour faire le lien entre les documents. L’entreprise doit s’approprier cette logique et faire les modifications idoines dans les documents, cela rajoute du travail et de la maintenance.
- De même, sur certains logiciels où on peut brancher le code source du projet afin de faire le lien avec le code développé, la documentation doit être spécifique dans le code pour pouvoir faire le lien
Exemple de logiciel de traçabilité
Grammaire supplémentaire dans le document word pour être intégré au logiciel de traçabilité
Ainsi, ces logiciels, bien que répondant à l’intention de la norme, ont l’inconvénient de devoir ajouter du temps supplémentaire pour la documentation. Or, dans la conception d’une innovation, le but est de pouvoir mettre le dispositif le plus rapidement sur le marché afin de pouvoir faire profiter de l’innovation. Tout ajout dans le flux de conception et de développement apparait donc comme un obstacle à l’innovation.
Utiliser son board projet pour tracer les modifications directement
Face aux inconvénients des logiciels de traçabilité traditionnels, une approche plus intégrée peut être adoptée en utilisant directement le board de gestion de projet pour la traçabilité. Cette méthode tire parti des outils déjà en place dans l'organisation, tels que Jira, Trello, ou Azure DevOps, pour suivre les modifications, les exigences, et les tests en temps réel.
Cette stratégie peut transformer la traçabilité d'une contrainte en un avantage compétitif :
- Une traçabilité naturelle dans les flux de Travail : En s'appuyant sur les outils de gestion de projet existants, il est possible de créer une liaison directe entre les tâches, les user stories, les exigences (URS/SRS), et le code. Chaque élément de travail peut être tagué avec des identifiants uniques, permettant une traçabilité complète depuis l'exigence initiale jusqu'à l'implémentation et la vérification. Cette intégration naturelle garantit que la traçabilité devient une partie du processus quotidien sans ajouter de charge de travail supplémentaire.
- Automatisation de la documentation : L'automatisation joue un rôle crucial dans cette approche. Les outils modernes de CI/CD (Intégration Continue/Livraison Continue) peuvent être configurés pour générer automatiquement des documents de traçabilité à chaque étape du développement. Par exemple, lorsqu'un ticket est complété, le système peut automatiquement lier le code source, les tests effectués, et les résultats des tests à l'élément de travail correspondant. Cela crée un enregistrement immuable et facilement accessible de la conformité à la norme 62304.
- Réduction des risques de non conformité règlementaire : En traçant chaque modification directement dans le board de projet, on minimise le risque de divergences entre la documentation et l'état actuel du développement. Cette transparence assure que toutes les parties prenantes, y compris les équipes de QA (Assurance Qualité) et de réglementation, ont une vue à jour et complète de la conformité du projet. De plus, cela facilite grandement les audits, puisque toute la documentation nécessaire est organisée et accessible en quelques clics.
Ainsi, cette méthode offre un double avantage compétitif : elle réduit le temps nécessaire à la gestion de la traçabilité tout en augmentant la réactivité face aux changements. En éliminant les tâches redondantes et en intégrant la conformité dans le flux de travail, les entreprises peuvent se concentrer davantage sur l'innovation et la mise sur le marché rapide de leurs produits.
Bye bye les logiciels dédiés, la traçabilité s’adapte à nos outils (exemple avec Azure DevOps)
Appliquons ces concepts à un board Azure DevOps, dont le code serait aussi hébergé sur Azure (exemple de situation où notre entreprise ne possède que des outils Microsoft).
Définition des exigences utilisateurs
Pour suivre notre board projet, nous effectuons une relation 1-1 entre :
- les URS et les Features au sens Agile,
- les SRS et les EPICS
- les SDS et les User stories
Exemple de lien suggéré entre vocabulaire règlementaire et vocabulaire agile
Lors de la rédaction du Software development plan, nous précisons que les SRS seront raffinées par l’écriture au quotidien des SDS associés. Ceci revient à calquer qu’une EPIC est une liste de user stories.
Ainsi, sur ADO, nous définissons un board pour chaque niveau de lecture de nos besoins
- Le besoin fonctionnel (l’URS)
- Le découpage haut niveau technique (le SRS)
- Le raffinage fonctionnel développable à la journée (la SDS)
Notons que ADO possède une haut niveau de configuration possible. Vous pouvez tout à fait intégrer vos étapes de développements propres à votre entreprise dans les boards projets.
Kanban des SRS
Board d'URS
Traçabilité du code
L’étape suivante est de pouvoir tracer le code fourni.
Une bonne pratique de développement est de suivre une convention d’écriture de commits, les commits conventionnels.
Une règle importante est d’inclure dans le titre du commit la référence de la user story
feat(core): add new header component for home page #123
Exemple de commit relié à une user story
L’avantage de ADO est que si le développeur livre une pull request avec les commits référents les user stories, ADO va directement lier les commits la user story.
Liste des commits avec référence du ticket
La liste des commits liées au ticket à droite du ticket dans l'encadré Development
Traçabilité des tests
Dans ADO, il est possible de noter directement dans le ticket (par un système de tab par exemple) les résultats des tests de revue effectués (vérification / Intégration). Les relecteurs peuvent alors mettre leurs commentaires si le code livré est conforme et fonctionne.
Enfin, il est possible d’associer à ADO des tests d’un SRS directement dans l’outil.
Ainsi, tous les objets règlementaires sont branchés dans le board projet, donnant la visualisation suivante.
Il ne reste plus qu’à utiliser le board comme d’habitude, en suivant le développement des user stories, en les testant etc, puis exporter l’ensemble des changements pour obtenir une traçabilité indolore pour l’équipe.
Conclusion
L'adoption d'une stratégie de traçabilité intégrée, exploitant les outils de gestion de projet agiles comme Azure DevOps, représente une évolution majeure dans le développement de logiciels certifiés dispositifs médicaux. Cette approche, loin de constituer une contrainte supplémentaire, s'avère être un véritable levier d'efficacité et d'innovation.
Parmi les pistes que nous envisageons afin d’aller encore plus loin dans son utilisation :
- Automatisation des résultats de tests : aujourd’hui, les tests sont manuels, on pourrait faire des tests end to end dont le résultat serait directement mis à jour dans ADO,
- Si toutefois un test casse, on pourrait alors ouvrir automatiquement une non conformité afin de tracer les actions de corrections,
- On pourrait aussi générer automatiquement la matrice de traçabilité.
En rendant la traçabilité indolore et en la fondant dans nos outils et méthodologies de travail quotidiens, nous ne faisons pas que répondre aux exigences de la norme ISO 62304 ; nous élevons le standard de qualité et de conformité de nos produits. La traçabilité devient alors non seulement une preuve de notre engagement envers la sécurité et l'efficacité, mais aussi un catalyseur pour le déploiement rapide et sécurisé des innovations en santé.
Et vous, quel est votre approche pour faire de la traçabilité un atout et non pas une contrainte ?
