top of page

Comment concilier Agilité et 62304 ?

Dernière mise à jour : 21 avr. 2022

Introduction


Concilier agilité et réglementaire dans un contexte logiciel dispositif médical est aujourd'hui un enjeu pour beaucoup d'entreprises.


Que leur proposition de valeur s'appuie sur les nouvelles technologies ou qu'elles voient dans le logiciel une source d'innovation pour dynamiser des produits ayant déjà trouvé leur marché, le nouveau règlement, encore une fois, place la barre plus haut.


Pour les premières, l'IEC 62304 et ses racines Cycle en V, semblent incompatibles avec le monde de l'Agilité, qui est la référence méthodologique du logiciel moderne.


Pour les secondes, elles pensaient que dans le monde du logiciel les cycles de développement étaient plus rapides, elles constatent que la "paperasse" y est également bien présente.


Cet article, qui fait suite aux interviews de quelques chefs de projet logiciel confirmés confrontés au problème, a pour but de faire la synthèse à la fois des aimables retours et de nos travaux internes ou expériences clients.


L'article est structuré en deux parties : les difficultés rencontrées ; une vision basée sur la suite Atlassian, décomposée par thématique.


Difficulté N°1 : Itération documentaire


La principale difficulté remontée est sans conteste la génération documentaire à chaque itération ou sprint qui entrave l'avancée du développement commercial.


D'un côté nous avons des équipes logicielles qui utilisent la plupart du temps des tickets Jira ou équivalent, de l'autre les affaires qualité et réglementaire qui ont besoin de documents.


Les dossiers réglementaires attendus par les organismes notifiés étant au format documentaire, par pragmatisme les entreprises traduisent les livrables de développement en document, avec inévitablement une perte de temps et des allers-retours aussi démotivants que chronophages pour les équipes.


La génération d'une matrice de traçabilité, déjà très difficile à réaliser manuellement, devient un cauchemar à produire à chaque itération, d'autant plus qu'elles sont aujourd'hui réalisées le plus souvent sur Excel.


Dernier élément clé, le volume des documents des dossiers techniques de l'entreprise est beaucoup plus important que celui des documents du système qualité. Or les documents projets sont très souvent les parents pauvres de la gestion documentaire de l'entreprise où le contrôle documentaire est fréquemment assuré manuellement par l'équipe qualité et réglementaire. Cette situation engendre de fait : gaspillages et délais, sans valeur ajoutée.


Difficulté N°2 : Intégration qualité


La gestion des risques est une activité réglementaire qui est aujourd'hui faite sous Excel, déconnectée des outils de gestion de projet Agile, alors qu'elle est censée jouer un rôle majeur dans le développement du produit, notamment d'un point de vue vérification et validation.


Dans de nombreuses entreprises, la gestion des bugs logiciels est retranscrite dans une gestion des anomalies certes plus large, mais sous fiche Word ou Excel, ou un outil de gestion de ticket dissocié de l'activité Agile, lui-même dissocié de la gestion des risques.


Les spécifications sont également très souvent au format Word, peu d'entreprises ont un véritable outil de gestion des exigences qui, lorsqu'il existe, est de toute façon rarement connecté à des outils Agiles. Certains nous ont dit recopier les exigences au format Word dans un outil de tests pour générer la traçabilité…


Le cloisonnement des formats ( tickets versus documents ), ne favorise pas le travail en équipes multidisciplinaires, et contribue à sortir la qualité de l'équipe, enfreignant ainsi les principes de l'Agilité. La gestion documentaire qualité, réalisée manuellement, reste possible au sein d'une équipe qualité de 4 à 5 personnes, mais lorsque la gestion documentaire touche le dossier technique, alors on touche les limites de l'approche manuelle d'un point de vue collaboratif.


La signature électronique qui permettrait de dématérialiser de nombreuses activités n'est pas pleinement utilisée, soit par manque de connaissance, soit par appréhension de sa validation. Résultat : on imprime, on signe, on antidate, on envoie des courriels, on se trompe, on corrige, etc. !


Les entreprises n’ont pas formé les équipes Qualité à l’Agilité et à l’intégration Jira - Confluence, cela se traduit naturellement par une surcharge de travail et des délais allongés pour essayer de faire rentrer l’agilité dans le monde du papier. Inutile de dire qu’avec le logiciel et la 62304, la partie est difficile.


Difficulté N°3 : Validation


Il n'y a pas, ou plus, de débat sur la validation d'un outil de gestion de conception, comme l'est Jira. Avec la version 2016 de l'ISO 13485, l'outil doit être validé.


Le revers de la médaille est que beaucoup d'équipes hésitent à faire évoluer le paramétrage de Jira, faute de temps, de moyen, et parfois de méthode, car le sujet est d'actualité, et de nombreux logiciels attendent d'être validés dans les entreprises…


Dans le cas le plus extrême, la validation fait peur, et on "cache" l'utilisation de Jira pour éviter sa validation, on ne montre alors à l'auditeur que les exports word ou excel. Une des raisons évoquée est le délai de validation pour l'éviter. La plupart du temps cela s'explique par une appréciation biasée des risques véhiculés par Jira, et donc une validation sans esprit critique qui conduit à des excès.


La validation devient alors un frein aux évolutions de Jira et donc à l'intégration des processus qualité au sein des équipes de développement.


Il est donc fortement recommandé de faire appel à des experts techniques et métiers capables de mettre au centre du processus de validation la gestion des risques afin de positionner le cursseur au bon niveau.


Enfin, un des freins les plus fréquents à la validation des outils cloud, et notamment Altassian, et la gestion des versions qui sont poussées par l'éditeur. En fonction du niveau d'abonnnement, Premium pour Jira et Confluence, il est possible de disposer d'environnement de tests pour valider les mises à jour, et contrôler celles destinnées à la production.


Difficulté N°4 : Tension sur les compétences d'intégration Atlassian Cloud


Jira est de loin l'outil de référence Agile, notamment pour les équipes logicielles. La politique de migration Cloud volontariste de l'éditeur, vers des versions Jira SAAS, change de fait les méthodes de paramétrage avancées.


Si maintenant il est plus facile converger vers la conformité RGPD il n'en reste pas moins qu'il reste de nombreux besoins fonctionnels qui nécessitent du développement et plus un simple paramétrage.


Tirer le plein bénéfice de la plateforme demande une véritable expertise technique et fonctionnelle non présente dans les entreprises.


Difficulté N°5 : Un système de management de la qualité papier


Pour des raisons à la fois culturelles et historiques, la qualité des entreprises du dispositif médical reste ancrée sur les documents, avec comme seul argument l'homologation réglementaire. Tout le monde reconnait de nombreuses tâches sans valeur ajoutée, mais rares sont ceux qui ont une vision d'une qualité agile et numérisée, capable de concilier Agilité et Réglementaire.


A leur décharge, la pression mise par le nouveau règlement sur les équipes Qualité et Réglementaire, ne leur laisse pas forcément le temps de prendre de la hauteur sur la numérisation des processus, et lorsque cela est le cas, les budgets sont parfois très contraints.


Les réclamations, non conformités, CAPA et audits sont très souvent sous Word et Excel, l'intégration avec le monde logiciel se faisant via des références ressaisies … alors qu’il est possible de numériser son SMQ en s’appuyant sur JIRA.


Vision N°1 : Connecter l'Agilité aux documents


Qu'on le veuille ou non, le document reste un élément pivot dans la constitution du dossier technique. Par conséquent, les équipes logicielles, en particulier dans un contexte IEC 62304, doivent intégrer cette contrainte.


Pour cela, rien de plus facile avec l'intégration Jira/Confluence, non seulement le lien entre le ticket Jira et la page Confluence est natif, mais surtout il est très facile de consolider automatiquement un ensemble de tickets Jira dans une page Confluence via un filtre.


Autrement dit, les tickets de type "activités" (User Story, Tâche) peuvent être liés aux pages Confluence pour le suivi de projet ; une autre page peut tout aussi bien afficher un ensemble de tickets, représentant des exigences, des risques ou d'autres "artefacts" de conception. sans recopie. L'activité documentaire peut ainsi être intégrée aux sprints, via des tableaux de type Kanban ou Scrum, et des flux d'approbation aussi bien au niveau des tâches que des pages Confluence avec de la signature électronique grâce à des plugins Confluence.


L'agilité est ainsi littéralement connectée aux pages Confluence. Pour répondre aux exigences réglementaires en matière de gestion documentaire, il suffit d'ajouter plusieurs plugins disponibles via la marketplace Atlassian.


Vision N°2 : Générer les documents automatiquement


Générer les documents réglementaires sans effort est bien évidement le rêve de tout développeur logiciel. Attention cependant à ne pas penser que l'Agilité signifie absence de formalisation ou documentation …


Il existe a priori trois grandes approches pour générer automatiquement la documentation.

  1. Utiliser un générateur de documents qui, par programmation, va aller chercher l'information et générer un ou plusieurs documents. L'outil peut être déclenché via une chaine DevOps.

  2. Utiliser les filtres Jira dans une page Confluence pour rapatrier des données amont qui sont contrôlées par un workflow. La page Confluence contient une partie statique issue d'un template ou d'une structure définie de page, et une partie dynamique qui vient de Jira.

  3. Utiliser les générateurs de documents soit natifs à Jira, soit intégrés à des plugins pour consolider les informations et générer automatiquement les documents, souvent avec des hyperliens vers les tickets Jira.

Couplé à la signature électronique sur les documents générés, on obtient une génération documentaire beaucoup plus fiable et rapide.


Vision N°3 : Intégrer la gestion des tests à l'Agilité


Aussi surprenant que cela puisse paraître, un grand nombre d'équipes logicielles des entreprises du DM, présentent des tests au format Word. Inutile de s'appesantir sur les raisons ou l'inefficacité de cette approche, c'est une voie sans issue, obstacle à l'intégration, le déploiement et la validation continue.


Il existe des plugins de tests qui permettent de sortir de cette impasse avec un chemin de progrès tracé : tests manuels puis tests automatisés.


Ce type de plugin donne plus de lisibilité à l'écriture des tests, facilite leur capitalisation, réduit le nombre de pas de tests en utilisant des données, rend la capture des preuves de tests moins fastidieuse, retrace facilement les exécutions par environnement, crée un lien immédiat avec les bugs, etc. En un mot, ils améliorent la maturité des tests manuels.


L'automatisation des tests va de pair avec l'intégration et le déploiement continu, et par voie de conséquence la validation continue, qui est clairement la direction à prendre pour concilier IEC 62304 et Agilité.


Insérer des tests automatisés dans une chaine DevOps, en remontant les preuves de tests dans Jira est aujourd'hui tout à fait possible, permettant ainsi de réduire les exécutions manuelles, et d'ouvrir une perspective de traitement des exécutions via le pipeline. Enfin, tester une application via son API est souvent très efficace.


La rentabilité des tests automatisés est assurée à partir de 4 exécutions en moyenne; avec 3 releases par an, des produits modulaires, et des changements mineurs, ce nombre d'exécution est généralement atteint dès la première année.


Vision N°4 : Une traçabilité Agile


Le sujet de la traçabilité dans un contexte Agile peut tout d'abord être vu sous l'angle de la matrice de traçabilité, qui est encore trop souvent générée manuellement.


Via des plugins Jira, il est possible de constituer la traçabilité au fur et à mesure, c'est à dire depuis les User Stories, les exigences utilisateur et les exigences fonctionnelles, pour bénéficier d'un fil rouge méthodologique et ne pas repousser à la fin de la release la fastidieuse tâche de recoller les morceaux de références plus ou moins fiables. On part du principe que les Stories, exigences fonctionnelles, et risques sont dans l'outil Agile, ce qui semble ne pas être toujours le cas d'après nos retours clients. Or, si on parle d'Agilité, la notion de valeur attendue ne peut être écartée, elle doit être suivie et mesurée, à priori dans l'outil de gestion de l'activité Agile, Jira dans notre cas. Une Story mal rédigée peut être source d'amertume, une Story n'est pas une simple tâche de développement !


L'autre intérêt majeur de gérer les Stories et exigences fonctionnelles dans Jira, et la capacité native de l'outil à faire le lien avec le code ( au moment du commit le développeur indique la référence du ticket Jira ), offrant ainsi une traçabilité jusqu'au code.


Enfin, ce qui freine les équipes Agile dans un contexte IEC 62304, c'est bien évidemment la gestion des changements et la traçabilité associée. Remplir un formulaire Word, et le circulariser manuellement, n'est pas franchement Agile, surtout lorsqu'il est possible de transformer le formulaire en ticket Jira ou d'utiliser le socle Jira Service Management pour bénéficier de processus prédéfinis qu'il faut ajuster à la marge.


Pour terminer ce point, intégrer la gestion des risques au niveau Jira favorise la collaboration entre les équipes de développement et les affaires réglementaires. Trop souvent, c'est en fin de release que l'on s'aperçoit que les mesures d'atténuation ne sont pas implémentées, il faut alors tant bien que mal justifier, et la livraison est plus ou moins retardée. En incluant la gestion des bugs dans l'outil, la surveillance est facilitée, et l'occurrence des risques plus facilement quantifiable.


S'appuyer sur une traçabilité collaborative intégrée facilite l'analyse d'impact au sein de l'entreprise et peut éviter des désagréments réglementaires très couteux.


Vision N°5 : Utiliser les modèles pour standardiser


L'amélioration de la qualité au sens large, passe par la standardisation, c'est indéniable.


  1. L'utilisation de modèles documentaires Confluence guide les métiers et les nouveaux arrivants.

  2. L'utilisation d'un modèle d'espace Confluence guide l'équipe dans la rédaction d'un dossier technique sécurisé.

  3. L'utilisation d'un modèle de projet Jira structure l'activité collaborative d'un Design Control, ses révisions reflètent le savoir-faire de l'entreprise, et donc une partie de sa propre valeur.

Il existe des plugins de gestion du temps et de traçabilité des coûts qui permettent de mesurer les progrès réalisés grâce à la mise en place de ces évolutions à la fois méthodologiques et outillées.


Vision N°6 : Valider pour dématérialiser et se recentrer sur la valeur


Valider une application, en définissant au préalable les besoins, en ayant en tête les gains visés par la dématérialisation de la paperasse et des signatures manuscrites, coûte généralement bien moins cher que sa mauvaise utilisation. Cela est particulièrement le cas avec le triptyque Jira/Confluence/Bitbucket, où sans vision d'un processus IEC 62304 Agile dématérialisé, répondant au 21 CFR Part 11, on construit une chaine hétérogène d'outils dont la valeur ajoutée est amputée par la gestion papier réglementaire.


La validation va naturellement permettre la dématérialisation des processus de Design Control et Document Control selon la terminologie employée par la FDA.


Le calcul de ROI est très favorable, pour trois raisons :


  1. L'investissement initial en matière d'intégration et validation est très raisonnable : quelques semaines de travail.

  2. Le modèle d'abonnement Atlassian Premium est accessible à toutes les entreprises, y compris les petites. L'écosystème de plugins réduit les coûts d'intégration. L'investissement Jira/Confluence est déjà présent dans les entreprises logicielles.

  3. Le gain est fonction du nombre de releases annuelles et de produits. C'est sans aucun doute l'effet levier le plus puissant.


Avec une vision claire ( reprise dans une "Roadmap ), déclinée sous forme de Stories formalisées, alors il est possible d'enclencher une validation certes réglementaire, mais qui est surtout là pour valider la valeur attendue d'un Design Control plus agile, plus véloce, capable de répondre aux enjeux de l'intégration et du déploiement continu, pour que l'entreprise reste compétitive.



Conclusion


Les entreprises du dispositif médical, qui ont toutes très largement investi dans la suite Atlassian, avec pour certaines de très nombreuses composantes logicielles à leur actif, peuvent, dans le cadre d'une démarche d'amélioration continue, tirer assez facilement profit de l'écosystème de plugins Atlassian via une intégration éclairée.


Concilier Agilité et Réglementaire est accessible, dans un délai raisonnable, sans faire table rase de l'existant, avec une conduite du changement réduite et donc une probabilité de transformation digitale réussie bien plus élevée qu'avec encore une nouvelle suite logicielle "magique" à intégrer.


Posts récents

Voir tout

Comments


bottom of page