Le ministère de la Santé américain adopte le low-code pour moderniser ses vieilles

De nombreux logiciels utilisés par le département américain de la Santé et des Services sociaux (DHHS), dont le budget tourne autour de mille milliards de dollars, sont des logiciels hérités, et le DHHS avait besoin de les moderniser. John O'Grady, directeur par intérim de la division des services numériques au sein du Bureau de l'Inspecteur général (OIG) du département, est responsable de la technologie qu’utilise le personnel du Bureau pour superviser les systèmes d’assurance-santé Medicare, les programme Medicaid et 100 autres programmes fédéraux.

« Ces quatre dernières années, nous avons lancé une initiative de grande envergure pour moderniser toutes les applications héritées de notre agence. C'est une tâche assez lourde, car nous avons plus d'une centaine d’applications », a-t-il déclaré. Cette actualisation doit aussi permettre d’économiser l'argent des contribuables et aider les auditeurs et enquêteurs à promouvoir plus efficacement la sécurité des patients, à prévenir la surconsommation de médicaments sur ordonnance et à renforcer les protections contre la fraude au programme Medicaid.

L'une des premières mesures prise pour mettre fin à 30 années de dette technologique a été de passer au développement agile et d’adopter une approche DevOps. Pour former l'équipe aux méthodologies agiles et low-code, M. O'Grady a fait appel à des ressources externes. « Nous formons les équipes aux pratiques agiles et low-code, nous les encadrons, nous leur expliquons ce qu'est un bon Product Owner (ndlr : le Product Owner est responsable de la définition et de la conception d’un produit) et ce que nous attendons de notre base client », a-t-il ajouté. Mais il y avait un problème. « Adopter des pratiques agiles et essayer de faire en sorte que le Product Owner consacre 80 % de son temps à un projet était un objectif très difficile à atteindre. Sur la vingtaine de personnes qui pilotent l'un des plus grands projets de modernisation en cours, trois consacrent exclusivement leur temps à gérer le changement organisationnel, à faire la promotion de la nouvelle méthodologie de développement et, plus largement, à modifier l'application.

Développement low-code externalisé

Ce changement de mentalité en matière de développement a été marqué par l’apparition de nouveaux outils. « Nous avons d’abord essayé le développement en Python, et nous avons construit quelques applications sur une pile assez moderne, que nous avons conservées », a déclaré M. O'Grady. Mais au final, le DHHS a opté pour une approche low-code, centrée sur ServiceNow. Plus connu pour sa plate-forme de gestion de services IT, ServiceNow s'est repositionné, sous la direction de l'ancien CEO de SAP, Bill McDermott, comme fournisseur d'outils de gestion des workflows dans le cloud.

Selon John O'Grady, ServiceNow s'intègre bien dans l'environnement cloud hybride du DHHS, constitué d’un mix d'AWS, de serveurs hébergés dans un datacenter Equinix et d'applications exécutées dans les clouds Office365 et DocuSign. « En 2019, 13 applications construites à l'aide de ServiceNow ont été soumises à des tests d'acceptation par les utilisateurs ou ont été déployées en tant que produits minimums viables », a expliqué M. O'Grady. Celui-ci est également directeur de la gestion du projet, mais la majeure partie de la programmation est sous-traitée à ITG, partenaire de ServiceNow, qui a récemment été acquis par ICF International, un autre contractant gouvernemental. Au total, dans le département, M. O'Grady gère environ 110 contractants chargés chacun de développer un logiciel. Deux choses ont facilité ce travail : « D’une part, nous avons nommé des Scrum masters pour chacun des projets. Ensuite, nous avons trouvé de très bons chefs de projet pour chacune des différentes équipes contractantes », a-t-il ajouté. Son principal conseil ? « Il est important d’établir des relations solides et de confiance dès le début du processus ».

Casser le monolithe

Après avoir testé ces modalités sur des projets plus modestes, l'équipe a entrepris l’an dernier de moderniser l'une des plus grandes applications de l'agence : son système de gestion des enquêtes, une connexion mainframe, datant de juillet 2003, soit bien avant l’avènement de la business intelligence, du data mining, de la mobilité et des médias sociaux. Sans surprise, le système avait besoin d’une bonne mise à jour pour devenir plus efficace et innovant. Les rôles et les autorisations, et le routage des tâches figuraient en bonne place de la liste des exigences. De plus, le système existant était centré sur les cas plutôt que sur les sujets. « Cela n’est pas d’un grand secours quand on a une centaine de John Smiths domiciliés à la même adresse, avec le même identifiant national de fournisseur NPI, et que l’on se rend compte que la même personne est vraiment liée à 120 cas », a-t-il expliqué.

Plutôt que de passer à un modèle de données centré sur le sujet, dans une réécriture tout ou rien, qui aurait demandé un énorme effort de migration des données de l'ancienne base Oracle, M. O'Grady a préféré une autre approche. « Notre méthode mettra fin au grand système monolithique de gestion des enquêtes, pour le remplacer par une suite d'outils d'investigation, tous reliés entre eux, qui se parleront entre eux et que les enquêteurs pourront utiliser », a déclaré John O'Grady. Au cours de la première phase, qui a débuté à la fin de l'année dernière, l'équipe a apporté des améliorations à l'application dans le cadre d'un exercice d'apprentissage - et pour maîtriser la tâche « absolument énorme » qui les attend, selon M. O'Grady. La seconde phase, actuellement en cours, va s'attaquer au modèle centré sur le sujet et mettra en place le processus d’absorption des données. Quelle que soit la rapidité du codage, le système existant ne sera pas opérationnel avant quelques temps : certains dossiers détenus par le système sont ouverts il y a cinq ou dix ans. Les nouveaux outils qu'ils développent continuent à échanger des données avec l'ancienne application d'une manière transparente pour l'utilisateur et devrait permettre d’accéder à toutes les fonctions de l'un ou l'autre système.

Le plus grand défi : le financement fédéral

« Le financement représente vraiment le plus grand défi », a encore déclaré M. O'Grady. En effet, un financement fédéral n’est pas le plus adapté pour établir un budget pour un projet aussi long. « C’est vraiment difficile de connaître les besoins d'une année sur l'autre, sans parler des cinq années à venir. Car un tel projet s’étend forcément sur plusieurs années », a-t-il ajouté. Même si la modernisation des applications est bénéfique pour le ministère et permet de réaliser des économies à long terme, il faut convaincre la direction que cela vaut la peine de dépenser un peu plus maintenant. « C'est un point délicat, surtout si l’administration venait à changer », a-t-il déclaré.

Il est donc important de profiter des périodes de stabilité relative pour apporter de grands changements au code. « Nous avons eu beaucoup de chance, car l’équipe de direction était excellente et elle n’a pas changé, ce qui n’a pas toujours été le cas. Il y avait eu un gros turnover au Bureau de l’inspecteur général les années précédentes », a encore déclaré M. O'Grady. « Les deux premières années, pas moins de six DSI se sont succédés au Bureau de l’inspecteur général. C'est très compliqué dans ce cas de faire avancer un projet de ce genre, surtout quand il s’étale sur 5 ans ».