Du pragmatisme dans nos refontes applicatives

Du pragmatisme dans nos refontes applicatives : pourquoi une refonte ?

Le monde de l’IT est en perpétuelle mutation, caractérisé par l’émergence constante d’innovations technologiques. Par exemple, l’usage intensif du smartphone dans nos quotidiens incite les développeurs de logiciels à envisager des alternatives mobiles pour leurs applications. Les paradigmes de développement qui prévalaient en 2010 sont désormais radicalement différents de ceux d’aujourd’hui, englobant divers aspects tels que l’UI/UX, les webservices, la DDD, la sécurité…

Au fil du temps, les projets accumulent inévitablement leur lot de difficultés : une dette technique qui persiste sans avoir été résorbée, des normes de développement dépassées, des interfaces utilisateur au design vieillissant, des mises à jour laborieuses, ainsi que des technologies devenues obsolètes. Ces exemples illustrent autant de motifs incitant à entreprendre une refonte applicative, qu’elle soit totale ou partielle.

 

Du pragmatisme dans nos refontes applicatives : le contexte

Notre étude se focalise sur une entreprise éditrice de logiciels spécialisée dans les solutions informatiques dédiées au domaine de la santé. Engagée dans un processus d’accompagnement des établissements de santé dans leur transition numérique, cette société propose des outils et des solutions technologiques visant à accroître l’efficacité opérationnelle et à améliorer de manière globale les services de santé.

L’élaboration de chaque outil ne se déroule pas simultanément et la chronologie des avancées technologiques se reflète dans la cartographie technique du système d’information. Les équipes de développement, composées de plusieurs dizaines de membres, sont divisées entre la maintenance des produits existants et le développement des produits en cours de refonte, certains étant déjà opérationnels.

À titre d’exemple, nous nous pencherons sur des projets réécrits autour de la technologie Angular, bien que les principes abordés demeurent applicables de manière générale.

 

 

Du pragmatisme dans nos refontes applicatives : les pièges

Une fois la réécriture actée, il devient impératif d’éviter certains pièges susceptibles de compromettre la productivité des équipes impliquées.

Le piège le plus évident consiste à se focaliser uniquement sur les aspects techniques et à viser une refactorisation à l’identique. Certaines fonctionnalités sont intimement liées aux contraintes techniques, ce qui est également le cas pour les technologies obsolètes. Par exemple, la transposition forcée de comportements propres aux clients lourds vers une interface Web se révèle souvent peu judicieuse. Cette approche augmente également le risque de répéter les erreurs du passé, notamment en termes de performances et de qualité.

Un autre écueil à éviter serait de tenter une révision totale d’un seul coup, en ignorant l’historique et en repartant à zéro. Bien que cette idée puisse sembler attrayante, elle demeure praticable uniquement pour des volumes restreints. Adopter cette approche dans le cadre de vastes morceaux du système d’information représente un risque significatif de dérive de temps et de motivation. La solution préconisée consiste à enchaîner les chantiers étape par étape. Par exemple, débuter par la refonte de la partie frontend et adapter ensuite progressivement la partie backend, en vue d’une refonte plus poussée ultérieurement.

Dans l’ensemble, un tel projet exige une certaine sagesse et une prise de recul sur tous les aspects, offrant ainsi une occasion propice pour réexaminer les fondements et garantir un niveau de qualité logicielle adéquat.

 

Du pragmatisme dans nos refontes applicatives : les solutions logicielles

Afin de nous orienter dans la bonne direction, plusieurs solutions logicielles sont disponibles, offrant des fonctionnalités telles que le formatage automatique, la vérification des normes de développement, la vérification des règles spécifiques au projet ainsi que l’exécution de tests automatisés.

Ces outils peuvent être intégrés directement dans l’IDE, ce qui permet de les utiliser pendant la phase d’écriture du code (Prettier, EsLint, etc.) ou d’être intégrés dans les pipelines d’intégration continue (Jest, Cypress, SonarQube, CodeCoverage, etc.).

Il est préférable d’adopter des normes reconnues par la communauté internationale afin de garantir une cohérence dans nos pratiques de développement entre différents services. Cependant, chaque projet conserve son autonomie et la responsabilité d’établir ses propres critères de qualité. Ces critères peuvent inclure des normes spécifiques, telles qu’une couverture de code attendue de 80%, ainsi que des règles personnalisées définies à l’aide d’outils tels que SonarQube. Cette approche permet de concilier les avantages de l’uniformité globale avec la flexibilité nécessaire pour répondre aux besoins spécifiques de chaque projet.

Une approche complémentaire consiste à mettre en place un socle technique afin de gagner en productivité lors des phases de développement. Ce socle technique peut contenir des composants réutilisables, des librairies génératives de code (schematics) ou encore un design system. Cela permet d’orienter le développeur dans son travail tout en maintenant une uniformité visuelle et des comportements applicatifs cohérents.

 

Du pragmatisme dans nos refontes applicatives : les solutions humaines et organisationnelles

En complément des solutions logicielles, il est essentiel de reconnaître l’importance des approches humaines. Ainsi, chaque développement fait l’objet d’une revue de code systématique par un membre de l’équipe. Une fois validée, la solution est soumise à des tests supplémentaires effectués par cette même personne ou par un membre tiers de l’équipe technique, ainsi que par un responsable fonctionnel.

Pour des sujets plus complexes ou critiques, l’adoption du pair programming (développement en binôme) est fortement encouragée. Cette pratique favorise une analyse approfondie de l’implémentation technique à adopter et une évaluation minutieuse des impacts. Comme l’adage le dit si bien : “deux cerveaux valent mieux qu’un”.

 

Pour optimiser l’ensemble de cette mécanique de projet, nous nous appuyons sur des solutions organisationnelles. L’adoption de la méthode agile nous permet de concentrer nos efforts sur le développement et la collaboration entre toutes les parties prenantes. Les projets suivent généralement une structure en sprints de 3 semaines, comprenant systématiquement la planification de sprint (sprint planning) et la revue de sprint (sprint review). Des réunions quotidiennes (daily) sont également organisées, ainsi que des rétrospectives planifiées tous les deux sprints.

Des points de synchronisation inter-services sont également instaurés pour garantir l’homogénéité et l’interopérabilité du système d’information.