Quelles sont les étapes de développement pour faire évoluer les applications biomédicales ?
Immersion chez l’éditeur Computer Engineering au sein des équipes chargées d’assurer l’amélioration continue des logiciels. Comme nous l’explique Nicolas Maschpy, Product Manager, le circuit du développement débute par le recueil des besoins utilisateurs.
« Les techniques de développement et leurs délais sont parfois difficiles à comprendre pour nos clients, reconnait Nicolas Maschpy. Lorsqu’ils nous font remonter une demande, ils aimeraient que l’adaptation informatique soit disponible très vite, mais ce n’est pas toujours possible ! ».
En effet, toute intervention sur l’un des logiciels de Computer Engineering obéit à une organisation bien rodée, structurée en 4 phases :
1. Analyse et priorisation des demandes des équipes hospitalières
Computer Engineering collecte des demandes d’évolution via le support utilisateurs, les consultants fonctionnels sur le terrain, les contacts avec les clients et les réunions des clubs utilisateurs. « Dans tous les cas, notre premier travail est d’analyser les demandes et de les prioriser car il y en a beaucoup. Pour effectuer ce tri, nous regardons s’il y a un caractère d’urgence ou si l’évolutif sera intéressant pour le plus grand nombre. S’il est trop spécifique, nous ne le retiendrons probablement pas. Mais en général, nous notons une convergence dans les requêtes », explique Nicolas.
Une fois le sujet sélectionné, l’équipe « spécification » formulera une description très détaillée des besoins, qui sera transmise à l’équipe de développement.
2. Circuit du développement : c’est parti pour le sprint
Chaque jour, l’équipe de développement fait un point sur l’avancée des demandes.
« Cette réunion, baptisée la mêlée, nous permet d’autoréguler notre activité et d’ajuster tous nos plannings en permanence : ce qui est OK, les difficultés, la prise en charge d’urgences, un décalage, etc. Grâce à cette mêlée quotidienne, nous pouvons réagir plus vite en cours de sprint. »
Qu’est-ce qu’un sprint ? Explications de Nicolas : « Nous fonctionnons en mode gestion de projet Scrum. Cette méthode agile segmente le travail en période de développement de 4 semaines, le sprint. Les dossiers pris en charge dans un sprint sont déterminés lors de la réunion de planification à partir de la liste de priorisation, et ordonnés dans le carnet du sprint. Toutes les 4 semaines, les développeurs traitent les sujets inscrits dans ce carnet ; ils doivent être terminés à la fin de la période, pour que nous puissions redémarrer sur un autre sprint. »
La méthodologie Scrum garantit la réactivité et les reports possibles, sous la supervision d’un Scrum Master. Ce facilitateur oriente les actions de l’équipe de développement. Il prend en compte notamment les urgences éventuelles. Si celles-ci concernent la sécurité du patient, elles sont forcément prioritaires.
3. Contrôle qualité = conformité assurée !
Cette 3e phase de qualification fait intervenir l’équipe du contrôle qualité. Son rôle est de vérifier la conformité fonctionnelle du produit, et que les applicatifs correspondent en tous points aux besoins exprimés.
L’équipe va aussi passer au crible toutes les évolutions afin d’intercepter les anomalies éventuelles. Elle effectue également les indispensables tests de non-régression pour s’assurer que le nouveau développement n’impacte pas le socle du logiciel existant.
4. Dernière étape, l’assurance qualité
Toute nouvelle version d’un logiciel développé par Computer Engineering doit être conforme à la réglementation en vigueur concernant la mise sur le marché des dispositifs médicaux. L’équipe « Assurance qualité » gère cette étape de libération réglementaire avant la livraison des mises à jour, accessibles par les établissements de santé depuis le portail client.
Pour prendre en compte les demandes utilisateurs, Computer Engineering planifie 4 fois par an des mises à jour officielles de versions, complétées par des versions intermédiaires si nécessaire du point de vue sécuritaire ou réglementaire. D’autres macro-planifications sont également prévues sur des chantiers plus prenants : le lancement d’un nouveau produit par exemple, ou de grandes évolutions sur les applications existantes. Dans ces cas-là, les sprints se transforment plutôt en marathon !