Développement et validation d’applications low-/no code dans GXP

Le low-/no code fait partie d'une nouvelle tendance du secteur du développement qui connaîtra une croissance à deux chiffres dans les années à venir. Contrairement au développement logiciel traditionnel, il vise à accélérer les cycles de produits, à offrir une plus grande flexibilité et à réduire les ressources nécessaires au développement et par conséquent les coûts relatifs.

Bien que le concept ne soit pas nouveau, ces dernières années le low-/no code a été considéré comme une technologie déstabilisante. Cela est dû à sa capacité d'utiliser la modélisation graphique pour créer des applications Mobiles et Web par exemple, qui n'utilisent que peu ou pas de code (donc « low-/no code »). En principe, un utilisateur professionnel disposant de compétences informatiques de base pourrait désormais être capable de concevoir un flux de travail numérique pour remplacer un flux de travail papier et l'exécuter sur une tablette intelligente. Évidemment, cela va bien au-delà. Comme le terme low-code l'indique, une certaine proportion de code reste nécessaire, d'autant plus que certaines plateformes low-/no code permettent soit d'importer du nouveau code source, soit de le modifier de manière à contourner la partie de modélisation et de configuration prédéfinie. Ce processus nécessite non seulement des compétences de base en programmation, mais aussi de faire appel à un développeur spécialisé en low-code. Autre contrainte : un collaborateur affairé par les opérations quotidiennes (gestion des urgences), aura du mal à trouver les ressources pour programmer une application par ses propres moyens.

Cependant, la majorité des cas d'utilisation de lancement d'une application low-/no code proviennent d'opérations commerciales. Voici quelques exemples de cas où des projets de développement low-/no code peuvent être déployés :

• Remplacement d'un processus papier par un flux de travail électronique
• Remplacement d'une application obsolète (ex. base de données d'accès)
• Agréger les données provenant de sources multiples dans un tableau de bord, des graphiques ou des rapports d'état accessibles sur les appareils mobiles
• Utilisation de modèles de données sémantiques pour standardiser, partager et analyser les données au sein de l'organisation
• Construire une plateforme B2B pour interagir avec des partenaires sur le même ensemble de données
• Créer des interfaces utilisateur et des plateformes rapides pour intégrer le cloud et les services externes
• Étendre les fonctionnalités d'un système ERP ou CRM

1. Sélectionner le bon fournisseur de plateforme

En plus des grands fournisseurs, il en existe des dizaines d'autres, qui ont tous leur lot d'avantages et d'inconvénients. Par exemple, certaines plateformes sont plus adaptées à la visualisation des données, certaines permettent de créer de meilleurs flux de travail et d'autres ne fonctionnent que sur les appareils mobiles. Il y aura toujours des compromis à faire, surtout si une combinaison de différentes fonctionnalités (par exemple, flux de travail et rapport visuel des données) est nécessaire.

2. Avez-vous déjà une plateforme low-/no code ?

Il se peut que votre entreprise ait déjà mis en place une plateforme low-/no code qui convient ou non à votre utilisation. Seules les organisations les plus importantes seront disposées à investir dans un deuxième fournisseur de plateforme low-/no code.

3. La plateforme doit être adaptée à votre application GxP

Étant donné que, selon toute probabilité, la plupart des applications construites ne sont pas GxP, il peut être difficile de l'adapter aux exigences GxP.

4. Modules tiers

Certains modules tiers pourraient être utilisés pour votre application. Cependant, le processus d’approbation et de validation d’un logiciel d'une provenance inconnue (SOUP) pour une application GxP peut prendre du temps. Une autre option consiste à développer la fonctionnalité par vous-même, ce qui implique d'investir dans une longue phase de test.

5. Trouver les bons spécialistes low-/no code et UI pour concevoir l'application

Bien que cela puisse sembler contre-intuitif dans un concept low-/no code, cela reste néanmoins l'un des facteurs clés de succès pour développer une application productive qui sera acceptée par les utilisateurs professionnels.

6. Négocier un bon contrat d’assistance avec le fournisseur

Les fournisseurs de low-/no code ont un avantage : les processus de support essentiels s'exécutent au niveau de la plateforme, y compris la gestion des incidents, la sauvegarde et la reprise après sinistre. Cependant, cela signifie que vous devez négocier un bon contrat d’assistance avec le fournisseur de la plateforme, garantissant qu'en cas d'incident de l'application qui ne pourrait être résolu en interne, ils répondront dans un délai défini.

7. Y a-t-il une restriction d'intégration de la part du fournisseur ?

Gardez toujours à l'esprit que vous développez votre application avec une technologie propriétaire du fournisseur. Par conséquence, le fournisseur peut vous empêcher d'intégrer d'autres dispositifs commerciaux qui pourraient augmenter le niveau de service technique de l'application à l'avenir.

8. Établir une bonne communication avec le fournisseur de la plateforme

En effet, la plateforme fait l'objet de mises à jour et de nouvelles versions. C’est pourquoi, avoir une idée claire de la portée d'un nouveau correctif ou d'une nouvelle version en cours de déploiement est essentielle pour effectuer une évaluation des risques et de l'impact de votre application GxP à l'avance.

1. Planifier avec l’approche de validation habituelle de la plateforme ou de l'application.

2. Il convient de s’assurer que la plateforme ait déjà atteint le statut « validé » ou « qualifié » et que les processus de gestion de la qualité et de support aient bien été définis.

3. Le concept de validation doit s'appuyer sur les processus de la plateforme validée/qualifiée, dans la mesure où il est possible de s'y conformer.

4. La stratégie de validation doit être alignée sur la méthode de développement (cascade, agile, DevOps ou hybride) et doit être alignée sur le cadre CSV.

5. Les caractéristiques de la plateforme doivent être évaluées avec un examen approfondi afin de déterminer si elles répondent aux exigences pertinentes de GxP. Si la plateforme ne répond que partiellement aux exigences GxP, les fonctionnalités doivent être développées et testées au niveau de l'application. Cela peut, bien sûr, prolonger considérablement le temps de conception et de validation.

6. Il est essentiel que la personne responsable de l'AQ ou du CSV soit impliquée dès le début. Étant donné que le low-/no code constitue une approche de développement très différente, elle pourrait rencontrer de la résistance sur le plan de la sécurité et de la conformité. Ces préoccupations doivent être prises en compte et il est évidemment préférable de les considérer à l'avance plutôt qu'à un stade ultérieur du projet.

En résumé, le développement d'applications sur la base de low/no-code offre un certain nombre d'avantages par rapport au travail de programmation traditionnel. Il est toutefois essentiel de veiller à ce que les exigences réglementaires pertinentes soient respectées. En revanche, des cycles de développement plus courts conduisent à une plus grande implication des PME, qui assisteront et contribueront à la mise en œuvre des exigences commerciales d'un produit minimum viable à une application pleinement fonctionnelle.

*Dans les secteurs de la biotechnologie, pharmaceutique, des dispositifs médicaux et des industries connexes, la validation des systèmes informatiques (CSV), ou sous sa forme abrégée, la « validation », englobe toutes les activités permettant de vérifier qu'un logiciel est adapté à l'usage auquel il est destiné et qu'il est conforme aux réglementations externes. Cela permet de fournir une garantie élevée que les risques relatifs aux patients, à la qualité des produits et à l'intégrité des données soient réduits au minimum.