Aujourd'hui, avec la démocratisation accélérée du numérique, de nombreux avantages voient le jour, tel que la simplification de processus conséquents qui n'apporte pas de plus-value dans les grandes entreprises, bien au contraire. Ces processus peuvent être de simples tâches, classer une liste de fichiers par leurs dates de rédaction, à des processus plus sophistiqués qui seront découpés en plusieurs sous étapes.
Durant mon alternance à UPSA (Union de Pharmacologie de Scientifique Appliquée), j'ai eu la chance de travailler sur la simplification d'un de ces processus complexes, les contrôles Pocls.
Il faut savoir que dans le milieu pharmaceutique, les entreprises sont soumises régulièrement à des contrôles pour vérifier les équipements, les zones blanches – chaines de productions, laboratoires – etc. Ces contrôles permettent de valider les normes fonctionnelles.
Ces contrôles Pocls sont des inspections réalisées par un service interne – l'Assurance qualité et conformité – de l'entreprise, puis ce service est audité régulièrement pour vérifier la bonne conformité de ces contrôles.
Lors de ces inspections, ils vérifient si les écarts précédents ont bien été corrigés puis, constatent suivant une liste d'éléments les nouvelles anomalies qu'ils reportent sur une feuille. Ces écarts sont ensuite remontés sur un fichier Excel et un email est envoyé aux référents afin qu'une intervention de correction soit mise en œuvre.
Tout le long, ces contrôles sont suivis avec un statut mis à jour permettant d'informer si les écarts ont été corrigés ou non.
Ce faisant, les fichiers Excel peuvent varier selon le service inspecté, cela engendre des écarts entre les fichiers, il est alors difficile de suivre correctement les contrôles, voire de les tenir à jour (récurrences d'une même remarque par exemple, des écarts entre le papier et les fichiers Excel etc).
Ma mission était de simplifier ce processus en dématérialisant le papier et de proposer une solution mobile/web pour s'affranchir de l'outil Excel. Cet outil permettrait de ce fait, de centraliser la totalité des contrôles Pocls avec leurs suivis.
Le principal risque résidait dans la compréhension du projet. En effet, je n'avais aucune connaissance du processus de validation et du métier qu'exerçaient les différents acteurs. J'ai participé à plusieurs réunions afin de recueillir les attentes des futurs utilisateurs et leurs besoins. A cette occasion, j'ai pris connaissance du processus complet de ces contrôles sur le terrain.
Il fallait alors proposer une application sur tablette permettant de visualiser les Pocls, et d'y renseigner très simplement les nouveaux écarts constatés. Une interface web devait être prise en compte pour pouvoir administrer et tenir à jours les statuts des Pocls.
Enfin, je devais prendre en considération le fait que l'entreprise pouvait utiliser l'application sur plusieurs types d'OS, web mais aussi sur Android et IOS.
Il m'est apparu évident d'utiliser une technologie me permettant de faire du cross-plateform pour gagner du temps durant la phase de développement. Il existait beaucoup trop de contraintes pour développer en natif sur deux OS différents (peu de connaissance d'IOS, peu d'expérience sur Android, temps multiplié au minimum par deux pour le développement d'une même application dans deux technologies différentes sans prendre en compte le temps d'apprentissage).
J'ai notamment mis en place un repo sur Git me permettant de versionner l'application et de réaliser des sauvegardes dans le temps.
Enfin, le choix des technologies s'est porté sur :
Durant le développement de l'infrastructure, j'ai mis en place un système de log permettant de remonter toutes les exceptions levées. Cette stratégie permet dans le futur, une fois l'application mise en production, d'avoir un journal daté répertoriant tous les crashs ou bugs éventuels lors de l'utilisation de l'application. Ceci permet rapidement d'identifier la source d'un problème et de faciliter les corrections. De plus ce système permet d'afficher ses propres messages d'erreurs personnalisés afin de les rendre plus compréhensibles de tous. Mettre en place ce système m'a notamment aidé durant le développement.
Une autre problématique apparait quand on simplifie un processus complexe, comment simplifier un processus encré de longue date dans une entreprise et plus particulièrement dans l'esprit des collaborateurs qui ont chacun leurs propres reflexes et habitudes ? l'enjeux était de proposer un outil ergonomique, très facile d'utilisation, permettant un gain de temps dans la consultation et la déclaration d'un nouveau contrôle. De plus il me fallait mettre en place un serveur avec une sauvegarde automatique et régulière des données. Pour ce faire, j'ai travaillé avec l'IT (service s'occupant de l'infrastructure informatique de l'entreprise).
J'ai pris le développement à l'inverse en me focalisant en premier lieu sur l'IHM, mettant de côté l'aspect métier – API et base de données –, l'expérience utilisateur était au cœur du projet. J'aurais pu développer en parallèle les deux mais aborder le développement de la sorte, m'a permis de proposer rapidement un prototype et de réaliser une démonstration auprès des acteurs concernés.
Plusieurs contraintes m'obligeaient à être rigoureux durant l'avancée du projet. Je n'avais pas d'équipe pour le développement et devais par conséquent faire face seul aux éventuels problèmes qui pouvaient survenir. J'ai dû par exemple développer à plusieurs reprises une fonctionnalité car celle-ci n'était pas adaptée au besoin du client, la première version nommée très simplement « V.0 » a mis 4 mois à voir le jour (test sur le terrain avec un groupe d'utilisateurs restreint).
Une expérience solitaire très enrichissante, je ne pouvais compter que sur moi-même durant le développement. Mais au final, le retour des utilisateurs et celui du service de l'assurance qualité a été très positif.
Mon regard critique sur cette expérience est la suivante ; j'aurais dû développer la partie
back
et front en parallèles plutôt que de découper mon développement avec la partie
IHM puis la partie
métier, quitte à prendre un peu plus de temps sur la partie UI (user interface ou interface
utilisateur).
En effet, j'ai perdu beaucoup trop de temps sur la partie visuelle, car je souhaitais proposer une expérience
fluide, simple et ergonomique. J'ai passé une grande partie de ma planification à développer cet aspect en
oubliant le côté métier primordial pour le fonctionnement de l'application.
De plus, j'ai perdu du temps au moment de lier l'application à l'API, dû en partie à des modèles différents
entre le front et le back car je devais réadapter des « morceaux » du code.
Malgré ces choix, le fait d'avoir travaillé seul sur ce projet m'a forcé à faire du Fullstack me permettant d'améliorer mes compétences en architectures logicielles et en gestion du temps.
Grâce à cette application, le service « qualité » gagne du temps dans la déclaration et validation des Pocls avec une meilleure gestion de ces derniers (données centralisées en un seul et même endroit).
La prochaine étape est d'assurer le suivi de l'application en développant de nouvelles fonctionnalités pour répondre aux nouveaux besoins utilisateurs (envois d'emails dont le but est de notifier les référents d'un nouvel écart par exemple). L'application fera lieu de plusieurs versions dans le temps et devra vivre à travers ses utilisateurs.
Je tire une grande satisfaction personnelle d'avoir pu travailler sur ce projet, avec de réels enjeux pour une grande entreprise ou la conformité rime avec qualité.