Agile avec APEX dans un environnement très réglementé

Par Hansjörg Grässlin, Christophe Girardey et Dr. Christian Wattinger

 

De nombreux secteurs ont des réglementations strictes (industrie automobile, pharmaceutique, contrôle du trafic aérien, banques, etc.) en ce qui concerne la mise en œuvre des projets informatiques, et la tendance est à la multiplication et au renforcement des réglementations en de nombreux endroits. L'APEX, avec son orientation vers des approches de développement agiles et rapides (p. ex. Low Code, Rapid Application Development), ne semble pas, à première vue, être adapté en soi à des solutions dans un environnement rigide et réglementé. En prenant l'exemple d'une mise en œuvre d'APEX dans un environnement strictement validé dans l'industrie pharmaceutique dans le domaine du développement clinique (Clinical Development), nous montrons comment ces problèmes inhérents peuvent être surmontés avec succès.

 

Dans cet article, nous souhaitons illustrer, à l'aide de l'exemple d'un projet réussi que nous avons mené dans un grand groupe du secteur pharmaceutique, comment les concepts "agile" et "strictement réglementé", à première vue contradictoires, peuvent être conciliés avec l'APEX. Pour ce faire, nous commencerons par décrire les deux concepts opposés avant de présenter la solution proposée.

 

La validation est...

...conformément à la Food and Drug Administration (FDA) américaine :

"L'établissement de preuves documentées qui offrent un haut niveau d'assurance qu'un processus donné fabrique un produit conforme à ses spécifications et caractéristiques de qualité prédéfinies".

Dans l'industrie pharmaceutique, les exigences réglementaires sont appelées validation et sont imposées dans les différents pays par les offices correspondants.

 

 

En Tableau 1 présente quelques exemples pertinents : Dans ce contexte, on fait la distinction entre système et logiciel. C'est important, car une validation se réfère toujours à l'ensemble du système, dont le logiciel n'est qu'une partie - certes importante. Mais le système comprend aussi, entre autres, les procédures et les personnes impliquées (voir figure 1).

 

 

Le guide central de la validation est la GAMP 5 [2] (Good Automated Manufacturing Practice), qui décrit une approche basée sur les risques pour valider les systèmes. GAMP divise les logiciels en plusieurs catégories, décrites dans tableau 2 catégories énumérées, l'effort de validation augmentant avec la catégorie. Dans le secteur pharmaceutique, il est indiqué et obligatoire de valider un système informatique dans les cas suivants, si le système concerne l'un des thèmes suivants :

• Sécurité des personnes, en particulier des patients
• Qualité du produit
• l'intégrité des données et donc, en fin de compte, la confiance dans les données (important par exemple dans le cadre d'études cliniques pour l'autorisation d'un médicament)

 

 

Dans tous ces cas, la validation doit garantir que les sources d'erreur sont minimisées et que la fiabilité des processus est maximisée. De plus, les écarts de processus qui surviennent doivent être clairement identifiables et compréhensibles. Dans l'environnement validé de l'industrie pharmaceutique, les développements de logiciels sont généralement réalisés selon le modèle V. Celui-ci est représenté dans Figure 2 est représenté.

 

 

En commençant en haut à gauche, le processus séquentiel suivant est suivi :

• Création et acceptation d'un plan de validation (VP) qui décrit comment le système doit être validé.
• Rédaction et acceptation de la User Requirements Specification (URS), qui décrit les exigences des utilisateurs pour le système.
• Rédaction et acceptation de la Functional Specification (FS), qui explique comment l'URS sera mise en œuvre sur le plan fonctionnel.
• Rédaction et acceptation de la Design Specification (DS). Il s'agit d'une représentation précise de la manière dont les fonctionnalités issues de la FS seront implémentées techniquement.
• Ensuite - tout en bas du modèle V - le logiciel est programmé. À la fin de l'implémentation, une revue de code est effectuée afin de soumettre la programmation à un contrôle de qualité grâce au principe du double contrôle. À partir de là, un guide d'installation (IQ) à tester est rédigé et accepté.
• Sur la droite, un pas plus haut, on exécute les tests unitaires afin de vérifier la mise en œuvre exacte selon le DS. Les écarts de test doivent être traités de manière formelle et, à la fin, tous les résultats des tests doivent être acceptés.
• Ce n'est qu'ensuite que l'on remonte d'un cran, où les tests fonctionnels (OQ) vérifient la mise en œuvre correcte de la fonctionnalité selon la FS. Là encore, la règle est la même que précédemment : Les écarts de test doivent être traités de manière formelle et tous les résultats des tests doivent être acceptés à la fin.
• Ce n'est qu'ensuite que le test de réception (PQ) est effectué par les utilisateurs !
• Tout à la fin, un rapport de validation (VR) est établi, qui montre comment toutes les étapes de contrôle et d'acceptation prévues ont été franchies avec succès ; il prouve ainsi la qualité compréhensible du résultat, c'est-à-dire du logiciel fini. L'approbation formelle du rapport de validation conduit à l'autorisation du système pour une utilisation productive.

 

L'outil central de l'ensemble du processus est l'analyse fonctionnelle des risques (FRA). Les différents risques possibles y sont analysés et évalués. Sur la base de ces évaluations, des mesures sont définies pour minimiser le risque. Cela peut conduire à des activités de test supplémentaires, à des solutions procédurales, à une formation supplémentaire ou même à des modifications de la conception.

Il est immédiatement évident qu'il s'agit d'un processus très lourd en termes de documentation et peu flexible. Le travail de validation est souvent beaucoup plus important que la programmation effective et les adaptations peuvent entraîner des dépenses disproportionnées, surtout si elles sont détectées tardivement (par exemple, seulement lors du test d'acceptation par les représentants des utilisateurs finaux - un cas tout à fait typique). Il faut également tenir compte des nombreuses signatures requises pour les tests de réception ; la collecte de toutes les signatures nécessaires peut souvent prendre beaucoup de temps si les responsables ne sont pas disponibles. Ceci est d'autant plus critique que, dans le modèle en V, on ne peut pas passer à l'étape suivante tant que toutes les étapes précédentes n'ont pas été approuvées par des signatures.

Cela contredit à bien des égards l'approche agile moderne - par exemple celle de Scrum - qui jouit d'une popularité croissante dans le développement de logiciels, et constitue donc presque l'exact opposé de l'approche flexible et itérative à laquelle nous sommes plutôt habitués dans le développement moderne de logiciels.

 

Scrum

Scrum est devenu la méthodologie de choix pour le développement agile de logiciels dans de nombreuses organisations. Nous nous contenterons donc ici d'esquisser brièvement les contours de cette méthodologie afin de souligner son opposition au concept de validation. Les éléments du cadre Scrum sont présentés dans la figure 2. Figure 3 est représentée :

 

 

Scrum est un processus itératif dans lequel l'équipe traite un "backlog" par blocs de travail de même durée - les "sprints". L'accent est mis sur le fonctionnement du logiciel plutôt que sur la documentation.

Des rétrospectives régulières et de courtes "Daily Scrum Meetings" quotidiennes, au cours desquelles tous les problèmes sont abordés directement et en temps réel, servent à améliorer le travail d'équipe et donc à augmenter la vitesse de mise en œuvre ("Velocity") de l'équipe, c'est-à-dire la capacité à réaliser avec succès davantage de travail pendant un sprint.

Les trois piliers fondamentaux de Scrum sont donc

1. Aborder les obstacles de manière ouverte et directe - "Transparency
2. Auto-examen de l'équipe et des processus - "Inspection
3. Adaptation et amélioration de l'équipe - "Adaptation

 

Les défis de la validation avec Oracle APEX

Dans le domaine de la validation, l'évolution des exigences constitue un défi majeur. C'est là que la méthodologie agile entre en conflit avec le modèle en V. Dans l'environnement agile, les exigences ne sont pas fixées, elles peuvent évoluer en permanence au cours du projet. C'est l'un des points forts de l'approche agile. Inversement, la méthode en cascade (modèle V) est basée sur des exigences rigides.

Alors, comment mettre en œuvre le modèle de VM réglementé avec une méthodologie agile ?

Un deuxième défi lié à l'APEX est l'accent mis sur la traçabilité des adaptations dans un environnement validé. APEX n'offre pas de piste d'audit intégrée permettant de voir directement qui a modifié quoi, quand et pour quelle raison. Le contrôle de version - par exemple avec Git ou Subversion - n'est pas inclus dans la philosophie de base d'APEX.

Comment aborder cette question de manière efficace afin de garantir la traçabilité critique pour la validation ?

Nous illustrons ces points ci-dessous à l'aide d'un projet client.

 

Un projet client validé avec Oracle APEX

Le client est l'une des dix plus grandes entreprises pharmaceutiques du monde. Le projet se situait au niveau du développement clinique.

Les processus soutenus sont très réglementés, car le logiciel a été utilisé dans le cadre de la procédure d'autorisation. La confiance gagnée dans les données d'étude collectées a un impact direct sur l'autorisation du médicament. De plus, une erreur de logiciel pendant une étude pourrait mettre en danger les patients, avec toutes les conséquences qui en découlent.

Les services de validation à fournir, prescrits par le client, comprenaient la création des documents prescrits par le modèle V dans HP ALM (un système de gestion du cycle de vie des applications), la réalisation de revues de code (principe du double contrôle), la réalisation des cycles de test (tests unitaires - avec utPLSQL, OQ) et l'installation (selon IQ).

 

L'approche pragmatique

Dans cette constellation, nous avons opté pour une approche pragmatique et l'avons affinée en permanence au cours du projet. Pour travailler ensemble sur les documents, nous avons utilisé les outils de collaboration de Microsoft (MS Teams) ainsi qu'Atlassian Jira pour le suivi agile des blocs de travail et la planification des sprints.

Nous avons divisé le projet en intervalles de temps, analogues à des sprints, et avons travaillé de manière agile pendant chacun de ces intervalles. À la fin de chaque intervalle, nous avons défini une ligne de base sur laquelle nous avons appliqué la validation en cascade du modèle V (FS-DS-UT-IQ-OQ-PQ) dans un sprint de validation afin d'obtenir la validation formelle (voir figure 4).

 

 

Nous avons ensuite enregistré les écarts et les adaptations constatés lors des tests unitaires, des tests système (OQ) et des tests d'acceptation par les utilisateurs (PQ) dans un système de gestion des changements, puis évalué les risques associés par le biais de l'évaluation des risques fonctionnels (Functional Risk Assessment - FRA).

Lors de la mise en œuvre, nous avons accordé une grande importance à la simplicité de la partie APEX. Cela signifie, entre autres, que

1. réduire au maximum le code source en exploitant l'approche "low code" d'APEX,
2. Le code PL/SQL dans APEX a été systématiquement déplacé vers des packages de base de données (par ex. les fonctions pipelinées dans APEX Interactive Reports (IR), les appels de fonctions de base de données dans les processus APEX, le contrôle des autorisations dans les appels de fonctions de base de données),
3. tous les objets de la base de données (packages, fonctions, vues, etc.) ont été systématiquement soumis au contrôle de version dans Git. Git a été défini comme une source unique de vérité.

 

Les directives de codage sont très importantes, dès le début du projet. Nous n'avions pas fixé ces directives de manière rigide, mais les avions développées et affinées en permanence lors des Sprint Retrospectives. Ces directives ont ensuite servi de base au processus formel de révision du code.

Au cours du projet, nous avons également eu l'occasion d'apprendre de nos erreurs : la gestion des erreurs s'est avérée très importante. La persistance des erreurs, des avertissements et des informations s'est avérée indispensable pour le débogage. Le logiciel open source Logger d'OraOpenSource [3] est à notre avis très recommandé, car il standardise l'ensemble du traitement des erreurs. En outre, il s'est avéré très utile d'intégrer une page APEX pour le journal des informations et des erreurs, visible avec les droits d'administrateur, afin d'augmenter la transparence.

Nous avons utilisé les "Build Options" d'APEX afin de pouvoir intégrer des fonctionnalités de manière flexible (voir figure 5). Par un simple changement de configuration, ces fonctionnalités "cachées" pouvaient être facilement activées ou désactivées pour l'utilisateur final (pages, éléments de menu, etc.). Cela permettait de vérifier les nouvelles fonctionnalités sans les mettre à la disposition des utilisateurs finaux ; l'introduction de fonctionnalités pouvait ainsi être dissociée du cadre rigide du modèle en V.

 

 

Conclusion

Grâce à ces mesures pragmatiques, nous sommes parvenus à utiliser avec succès les principes agiles au profit du projet, tout en respectant les exigences réglementaires strictes.

Cela a contribué de manière décisive à la réussite de notre projet et à la satisfaction du client.

Les leçons tirées peuvent également être utiles pour des projets APEX similaires dans des environnements strictement réglementés.

 

Sources

[1] Composants d'un système informatisé validé, PIC/S Quelle : PIC/S (2007)
[2] GAMP5, A Risk based Approach to Compliant GxP Computerized Systems, ISPE (2008). Tampa, Fla. ISPE Headquarters [u.a].
[3] Logger, OraOpenSource, https://github.com/OraOpenSource/Logger