L’agile pour les logiciels médicaux, c’est possible !

 

Bonjour à tous,

Aujourd’hui je vais vous parler d’un sujet que j’affectionne au quotidien : la gestion de projets dans le secteur médical.

J’aimerais orienter cet article autour de la problématique du développement de logiciels dans ce milieu et de l’utilisation de méthodes agiles. 

Dans les hôpitaux et les cliniques notamment, ces logiciels présentent un enjeu majeur : permettre d’établir un diagnostic et potentiellement aider à la prise de décision thérapeutique.

À première vue ces sujets peuvent paraître incompatibles tant la nécessité de garantir la sécurité du patient peut paraître opposée à l’idée de produire plus vite.

En réalité, il n’en est rien.

Concernant les méthodologies agiles, il en existe plusieurs. Scrum est la plus répandue mais on peut citer également Kanban, eXtreme Programming, RAD ou encore Crystal Clear.

Ces méthodes agiles sont centrées sur la recherche et la précision des besoins des clients. L’idée étant de faire plein de petits cycles combinant développement et tests afin de vérifier si les besoins des clients ont bien été compris par les développeurs.

Cela tombe bien car l’une des phases majeures du développement des dispositifs médicaux s’appelle le « Design Input ». Elle permet de rassembler toutes les exigences auxquelles le produit doit répondre en termes de fonctionnalités, de risques, de normes, de règlements …

Cependant, les logiciels médicaux se doivent de suivre une norme particulière, l’EN 62304. Cette norme propose un cycle global prédictif qui pourrait s’apparenter à du cycle en V, a priori incompatible avec les méthodes agiles. De plus de nombreux documents et de nombreux process sont requis dans le cadre du développement de DM (Dispositifs Médicaux) ce qui irait contre le manifeste agile dont l’un des principes est de moins se concentrer sur la documentation et les process pour favoriser les intéractions et la collaboration.

Alors comment faire ? L’enjeu est de ne pas brader les spécifications notamment celles réglementaires tout en limitant la surcharge documentaire.

La solution vient du fait de ne pas séparer les phases de design comme des silos sur lesquels on ne peut ni revenir en arrière ni anticiper mais de les comprendre un projet global. Cela permet en outre d’impliquer toutes les parties prenantes du projet dès le départ.

J’ai à titre personnel plusieurs fois vu les parties prenantes du côté production ou service client, être mises dans les boucles un peu trop tard, au moment du Design Transfer, là où rien ne peut être remis en cause et où le timing est très serré car les marges sont déjà consommées. Cela génère souvent de la frustration et la nécessité de rependre certaines procédures après le projet.

Dans le cadre du développement de dispositifs médicaux, applicable également à d’autres domaines, on peut distinguer 6 phases :

1- La collecte du besoin client, avec comme livrable clef le User Requirements Specifications (URS)
2- L’écriture des spécifications, avec comme livrable clef le Design Input
3- Le développement, avec comme livrable clef les Design Output
4- La vérification, avec comme livrable clef le Verification Report qui permet de s’assurer que les exigences du design ont été respectées
5- La validation, avec comme livrable clef le Validation report qui permet de s’assurer que le produit répond aux besoins des clients
6- Le transfert en production, avec comme livrable clef le Design Transfer Completeness qui permet de s’assurer que toutes les procédures permettent de produire et d’installer le dispositif médical.

A première vue on a envie de faire chaque phase distinctement et de ne pas commencer à développer/prototyper tant que les besoins clients ne sont pas clairs et les spécifications rigoureusement écrites.

Et c’est justement cet écueil qui retarde tant le développement des DM et notamment des logiciels. La phase de Design Input prend en général un temps infini avec des aller/retours dans la rédaction des exigences. Ceci retarde le lancement officiel du développement. Néanmoins l’excès inverse consistant à développer sans spécifications précises peut aussi générer de la frustration côté développeurs qui devront faire puis défaire les fonctionnalités, ce qui rend compliqué les phases de tests.

L’idéal, et ce que je prône régulièrement serait la façon suivante :
Sur chaque sprint :
1- Établir précisement 5 fonctions clefs voulues par les clients : chaque fonction doit avoir un rang par rapport aux autres.
2- Détailler les spécifications ces 5 fonctions par ordre de priorité.
3- Commencer le développement de chacune de ces 5 fonctions dès la spécification validée.
4- Réaliser le plan de test de vérification de ces 5 fonctions dès la spécification validée.
5- Établir le plan de validation de ces 5 fonctions dès la spécification validée.
6- Entamer le plan de transfert en production de ces 5 fonctions dès la spécification validée.
7- Réaliser les tests de validation et vérification dès la livraison des fonctions demandées.
8- Déployer la version chez un client test dès la livraison des fonctions demandées.

Comme vous le voyez il s’agit finalement d’un mini cycle de développement, jusque là rien de très révolutionnaire.

Le changement est que sur chacune des étapes du sprint il y a un acteur leader mais le reste des équipe reste totalement impliqué et anticipe ses actions. Si on reprend chacun des étapes :

1- Priorisation du besoin : Le product owner est clairement le leader de cette étape. Mais il a besoin que le marketing donne sa priorisation, que les développeurs donnent la difficulté et le timing associé à chaque fonction, que l’architecte fasse aussi part de son avis concernant l’intégration de la fonction, enfin que l’équipe de test (Vérification/Validation) donne également des pistes sur la manière d’évaluer les fonctions.

2- Spécifications : Là encore le product owner est leader et toute l’équipe l’aide à donner le maximum de détails possible sur chaque spécification afin quelle soit comprise de tous. Cela permet d’anticiper les étapes qui suivent.

3- Développement : les développeurs sont à la manœuvre, le scrum master permet d’avoir de la visibilité sur la production des fonctions, le product owner peut éventuellement ajuster certaines spécifications. Pendant ce temps l’équipe test prépare ses protocoles.

4, 5 : les plans de Vérification et de Validation peuvent se faire de manière continue dès les spécifications rédigées. Ils sont éventuellement révisés lorsque les spécifications s’ajustent en fonction des contraintes du développement. ll est très important de garder ces équipes dans la boucle du sprint car elles arrivent au bout du sprint, généralement là où toutes les marges sont consommées…

6,7 : Dès le développement terminé les tests peuvent être réalisés car les protocoles ont été préparés en amont. Les bugs peuvent ainsi être remontés rapidement afin d’ajuster la version si nécessaire.

8 : Les équipes d’intégration et du service client installent la version test chez un client cible (qui peut être en interne). Cela leur permet d’ajuster leurs procédures et d’être prêts lorsque la version finale est livrée.

Côté documentaire l’idée est de garder les documents « vivants » et de les compléter au fur et à mesure du cycle. L’avantage est de pouvoir revenir sur des fonctions durant le projet, d’ajuster le besoin et surtout de tester de manière continue le produit. L‘utilisation d’outils collaboratifs est clairement préconisée dans ce cas.

Avec cette méthode on se rapproche du manifeste agile car la documentation est limitée au minimum, les collaborations sont multipliées et en même temps on a la rigueur et la traçabilité du dispositif médical.

L’idée de mini cycle est évidement plus simple à réaliser sur un logiciel mais elle est adaptable sur des dispositifs « physiques ». En effet rien n’empêche d’aller jusqu’au prototypage de certaines fonctions/côtes clefs d’un DM surtout via l’impression 3D qui permet du prototypage rapide et rendent certains tests possibles (dimensionnement, packaging, usage).

En résumé, pour déployer les méthodes agiles dans un secteur normé comme le médical, pensez bien à :

  1. Considérer tous les acteurs du projet dès le début.
  2. Démarrer en même temps toutes les phases du projet de conception.
  3. Maximiser les interactions avec les parties prenantes, en premier lieux avec les clients.

Les outils utilisés dans le cadre de cette gestion de projets sont évidemment cruciaux, j’y consacrerai un article entier tellement le sujet est vaste.

Les rôles et responsabilités sont également primordiaux dans ce type de projet, ce sera le sujet d’un autre article également !

Qu’en pensez-vous ? Comment gérez-vous l’évolution des exigences de vos DM ?

Suivez-moi sur les réseaux sociaux !