La validation et

les méthodes Agiles

La réglementation sur les dispositifs médicaux et les produits pharmaceutiques sont applicables indépendamment du cycle de développement logiciel

Les méthodes agiles sont itératives, c’est à dire qu’elles comprennent des cycles de développement successifs. Chaque itération se base sur des éléments essentiels comme les exigences utilisateurs et les critères d’acceptation qui vont permettre de démarrer le cycle de développement. A la fin de chaque itération, on obtient une version ou incrément en vocabulaire agile, qui est censé être un produit utilisable par les utilisateurs…. Le principe est de livrer des versions fiables du système même si toutes les fonctions ne sont pas finalisées.

À la différence de ce qui est demandé dans le modèle en V, cette approche permet de démarrer les développements sans la rédaction de spécifications fonctionnelles détaillées préalables, car les utilisateurs et l’assurance qualité sont impliqués dès le début et valident en continu la réponse fonctionnelle.

L’approche agile est bien adaptée quand toutes les exigences du système ne peuvent pas être décrites avec précision au début du projet. Historiquement, les projets web ont été parmi les premiers à l’utiliser, pour l’ajout d’un chatbot GxP par exemple. Le point essentiel est que les utilisateurs disposent des fonctions au fur et à mesure des mises à jour en production et peuvent modifier les exigences tout au long du cycle de vie du système.

La désignation de méthode agile recouvre différentes approches alignées avec le Manifeste Agile de 2001. On peut en citer quelques-unes : Scrum, eXtreme Programming (XP), Feature Driven Development (FDD), Rapid Application Development (RAD), Behavior Driven Development (BDD) …

On peut noter que l’approche Agile a été mise en place principalement pour les étapes de développement logiciel et que selon les méthodes, certaines démarrent dès les phases de pré projet et faisabilité, d’autres sont plus orientées sur l’exécution du projet. Ce sont ces dernières qui sont essentiellement utilisées en environnement réglementées. (exemple la méthode  Scrum).

Le modèle en V est une variante du modèle Waterfall de développement logiciel. Il désigne une procédure séquentielle dans laquelle chaque étape doit être finie pour que la suivante puisse commencer. La branche descendante correspond aux phases de conception. La branche montante correspond aux phases de test. Chaque étape de conception correspond à une phase de vérification.

Cette méthode nécessite une définition précise des exigences dès le départ. Elle est bien adaptée aux systèmes pour lesquels les changements en cours de développement sont limités. Le planning initial et le périmètre fonctionnel ne sont pas censés changer au cours du projet. La traçabilité entre les exigences et les tests assure un contrôle documenté de la qualité à chaque étape.

Pour le secteur pharmaceutique, il n’y pas d’incompatibilité entre les principes de la validation et ceux de l’approche agile. On peut s’appuyer sur le Guide GAMP® 5* seconde version de 2022 qui reprend les exigences et qui ne préconise pas un cycle de développement précis mais décrit une succession de cinq phases ; planification, spécification, configuration (ou codage), vérification et rapport. Il est essentiel que la gestion des risques soit intégrée dans toutes les étapes, ce qui implique une analyse de risque dynamique. De même la réglementation sur les dispositifs médicaux (Règlement (UE) 2017/745 et Règlement (UE) 2017/746) n’impose aucune séquence précise pour les projets de conception et développement logiciel.

A noter que la méthode utilisée n’a aucun impact sur le contenu des preuves documentées exigées, qui doivent être conformes aux attendus des normes.

L’approche agile peut donc être mise en œuvre dans un environnement GxP* pour autant qu’elle intègre les exigences réglementaires sur la documentation du logiciel et le système de management de la qualité. En particulier, il est essentiel de conserver la maîtrise de la traçabilité des exigences tout au long du développement.

L’agilité n’est pas, comme il est dit parfois, une approche sans aucune formalisation ni maitrise des changements ; il est possible de l’utiliser dans un contexte réglementé.

Un des facteurs clés de succès est l’implication de l’Assurance Qualité dans le projet, et ce, dès le début, à savoir l’expression des besoins utilisateurs.

Au cœur de l’approche agile, se trouve une équipe autonome, pluridisciplinaire et stable. Par stable, on entend une même équipe qui suit le projet de bout en bout. Et du personnel formé à la méthodologie agile, formation tant sur le vocabulaire qui est parfois spécifique en fonction de la méthode appliquée ; qu’une formation à la méthodologie de travail qui est associe collaboration et flexibilité.

Pour une validation efficace, des outils spécifiques au monde agile sont indispensables. Ils vont assurer le suivi des exigences et des risques tout au long du développement.

Sa mise en pratique, demande une transformation de l’organisation et des pratiques de la plupart des industriels de la santé. Aussi, le mode hybride peut être une approche de transition vers le mode full Agile.

Les retours positifs sont l’obtention d’un système qui répond aux attentes des utilisateurs, grâce à la flexibilité offerte par la méthode.

La prise en main progressive par les utilisateurs clés génère une adhésion et une acceptance du nouveau système, particulièrement intéressante.

Un point de vigilance : le travail en mode agile ne fait pas gagner de temps contrairement aux idées reçues. La répartition temporelle est différente. Ne perdons pas de vue, qu’en mode agile, les mises à jour de documentation de spécifications, les mises à jour d’analyse risques, les répétitions de tests, sont aussi nombreuses que la quantité d’itérations nécessaires pour obtenir un produit fini. Aujourd’hui, pour gagner du temps, ces mises à jour ne sont pas correctement réalisées sur les projets et posent des problèmes de compliance.

Autre point de vigilance : La qualité des tests réalisés. Les tests sont trop souvent linéaires, ils vérifient seulement le fonctionnement système et ne s’appuient pas réellement sur les risques identifiés. Les tests aux limites ou en défaillance ne sont pas suffisamment présents.

Enfin, l’agilité a ses limites. La flexibilité et les capacités d’ajustement ne doivent pas aboutir à un système radicalement différent de l’expression de besoin initiale. Ne serait ce que pour des raisons de faisabilité en termes de couts, ressources, délais et qualité.