Gestion d’une application legacy : un défi technique mais aussi humain.
Application legacy.
Ce terme nous fait peur dans l’IT,
il nous irrite et nous met dans tous nos états,
Pourtant il fait bien écho en vous car vous avez sans doute la mission comme moi d’en assurer la maintenabilité, la sécurité, l’évolutivité.
Voici un retour d’expérience sur mes premiers défis relevés lors de la gestion de plusieurs applications legacy.
Les défis d’une application legacy
Comme certains le disent, le code écrit il y a 1h est déjà legacy. Au rythme des changements technologiques, ils n’ont pas totalement tort. Il convient donc de clarifier de quoi il sera question dans cet article.
Par « application legacy », je fais référence à une application qui a été développée avec des technologies et des pratiques de développement peu récentes. Je distingue 2 types d’application legacy :
- la récente legacy 3–5 ans d’âge par rapport aux technologies et pratiques de développement
- la bonne vielle legacy de +5- 10ans d’âge (est-elle aussi savoureuse qu’un bon bourbon de 10 ans d’âge ? — nous le découvrirons dans la suite de l’article😉)
Ces applications legacy engendrent généralement 3 problématiques :
- Comment engager vos collaborateurs dans les modifications d’une application legacy tout en maintenant leur motivation et leur envie de rester dans votre équipe ? A mon sens, c’est la plus importante des problématiques pour un manager car sans la motivation on va droit dans un mur.
- Comment effectuer une évolution sur une application legacy sans engendrer de régression ?
- Quelle stratégie adopter pour la gestion des applications legacy dormants qui potentiellement se réveilleront pour vous hanter avec des potentielles failles de sécurité, des éventuelles évolutions réglementaires ou autres ?
1. L’engagement des collaborateurs
Il est facile d’engager des développeurs sur une nouvelle application, avec les technologies “up to date” et les pratiques du moment. Mais, quand on leur présente des travaux à réaliser sur des applications legacy, on n’est pas forcément bien reçu.
Je vais vous présenter ce qui m’a aidée à maintenir l’engagement de mes collaborateurs.
Une relation de transparence et de confiance est nécessaire pour obtenir l’entier engagement de l’équipe. Avoir une vision stratégique de ces différentes applications legacy et connaitre la cible ont été des sources très fortes de motivation pour mes collaborateurs.
Créer cette vision avec le management et la coconstruire avec l’équipe tout en partageant les contraintes ont participé à engager les collaborateurs et à obtenir leur adhésion dans la gestion de ces applications.
Ensuite en tant que manager, il faut également nourrir la soif du collaborateur des sujets technologiques du moment avec les technologies d’hier. C’est un travail d’équilibriste qui n’est pas simple mais qui fait partie de notre job de manager.
2. La gestion des évolutions sur une application legacy
Mes convictions se basent sur 2 expériences complètement différentes :
- Une mise en conformité de la sécurité d’une application lourde
- Une évolution fonctionnelle sur une application web.
De ces expériences, j’en sors une checklist :
Identifier la vision stratégique de votre application : décommissionnement, maintenabilité ou refonte ?
Dans le cas d’une vieille legacy, on oscille entre le décommissionnement et la maintenabilité. Une refonte nécessiterait un investissement conséquent. Généralement cette option est écartée. Néanmoins, il faut permettre à minima une reprise de l’application et maitriser les risques des éventuelles évolutions sécuritaires/légales à venir.
Dans le cas d’une récente legacy, vous héritez d’un projet avec des obsolescences techniques. Soyons lucide : vous n’obtiendrez pas le budget pour résorber ces obsolescences. Vous devez donc penser stratégique et être très pragmatique dans votre feuille de route. Tout d’abord définissez votre cible finale : quelle est l’architecture qui répondra aux normes de développement et apportera de la valeur business ?
Ensuite, dès que cette cible est figée, comment arriver par itération à cette cible en tenant compte des investissements en cours sur le projet/produit et des contraintes techniques ? Une équation très difficile à résoudre mais qui doit finalement aboutir à un plan d’actions en plusieurs étapes qui vous servira de contrat avec votre Product manager pour éviter de gérer un sujet dormant à la suite de l’évolution.
S’assurer que notre projet compile avant toute modification
C’est évident : qui sauvegarderait un projet qui ne compile pas ? Par acquis de conscience, il est sage de le vérifier encore plus pour un projet de plus de 10 ans d’âge.
Mettre en place une intégration continue (CI/CD)
Une intégration continue permet la reprise du projet par tout autre développeur en toute sérénité. Vous n’avez pas besoin de savoir quel fichier utiliser. La génération des livrables est automatisée.
En plus c’est un pas pour arriver à la surveillance automatique de sécurité et de qualité grâce aux outils de sécurité/qualité (SonarQube, Checkmarx, Lifecycle) qui sont branchés directement sur votre intégration continue.
Brancher vos outils de sécurité lorsqu’une intégration continue est déjà en place (généralement dans le cas de la récente legacy)
Vous êtes donc en mesure de connecter vos outils de sécurité & qualité. Ces outils vous fourniront des éléments factuels pour aller chercher des futurs investissements. Prenez l’exemple du contrôle technique de votre voiture. A la suite de ce contrôle, vous mettez en place les réparations demandées. C’est pareil avec votre application. Chez AXA, nous avons mis en place un ensemble de points de contrôle qui aboutit à des actions de remédiation avec en responsabilité le Product manager, l’Engineering Manager et l’architecte solution.
Gérer la non-régression
Généralement le fonctionnel est peu maitrisé. Il y a peu de test dans le code et peu de test rédigé par les testeurs.
Cela n’est pas une raison pour rester dans cette situation. Au contraire cela doit nous inciter à enrichir nos tests unitaires pour sécuriser le process de reverse engineering nécessaire dans le cas d’une vieille legacy.
On s’assure de faire des tests unitaires en commençant sur les parties modifiées. Sur la non régression, on s’appuie sur les équipes business- merci à eux. Dans la mesure du possible, on récupère leurs tests pour enrichir nos tests de bout en bout en Gherkin pour ainsi générer une documentation vivante.
Muscler vos scénarios de test de bout en bout
Cette action vous permettra également de vous préparer pour une éventuelle migration de votre application legacy vers la cible définie.
“Do your best and the best will come to you” / Advienne que pourra
Malgré toutes les étapes précédentes, vous ne serez pas à l’abri de surprises techniques. Il est important de partager ce risque pour que tous les acteurs (Développeur, Testeur, Product owner) soient engagés dans un modèle de management de risques.
3. La gestion des applications legacy dormants
Nous avons tous au moins une application où l’activité est fortement réduite. Mon conseil : avoir à minima un pipeline installé et vos outils de sécurité en place.
Cela vous permet d’assurer un service minimum : une surveillance automatique qui vous alertera le plus tôt possible des risques courus par votre application.
Ce dispositif ne garantit pas que des actions seront initiées pour remédier au risque, mais il a le mérite de tenir informés tous les acteurs de la situation de l’application.
Les Doers en parlent mieux
Ce qui est difficile : réussir à découper les tâches de remise à niveau d’une application. Quand il s’agit de migrer un framework par exemple, on arrive à un point où on ne peut plus le faire par petits bouts et la seule option est d’y dédier un ou plusieurs sprints avec grosse MEP à la fin. Situation très difficile à “vendre” au métier. Et tant qu’on ne le fait pas, le legacy peut nous bloquer dans d’autres développements. C’est un vrai numéro d’équilibriste.
Ce que j’apprécie : même si cela se fait dans la douleur, c’est bien souvent sur le legacy que l’on prend de l’expérience. Car à l’opposé tester un nouveau framework tout neuf c’est bien, mais c’est très facile : on ne rencontre en général pas de difficultés ni d’équations impossibles. Avec le legacy, tu dois faire preuve de patience, faire des choix difficiles, t’attendre à faire des régressions même quand on applique de bonnes pratiques etc. C’est beaucoup plus formateur.
— Louis Madeuf — Développeur fullstack
Lors de la reprise de mon sujet legacy, j’ai été confronté au fait que le sujet a été transmis de personne en personne en peu de temps … Tu dois te débrouiller avec le peu de documentation pas à jour, un repository laissé à l’abandon, sans les règles de développement. Et là tout d’un coup je découvre que les sources ont été archivées par dossier avec des jar décompilés et les classes modifiées à la main. L’horreur.
Après cette analyse qui fait mal, il faut trouver une solution et c’est là que le challenge devient intéressant. Il faut faire du reverse engineering et capitaliser dessus notamment avec la mise en place d’une CI/CD afin de mettre en place de façon clair la manière (étrange) de builder. Par contre rester à long terme sur ce type de projet me semble impossible. Soit le développeur ne dit rien et va partir du jour au lendemain ; soit il va l’exprimer et il va falloir trouver une solution pour le changer de périmètre car l’énergie et la motivation que demandent ces projets est comparable à un régime restrictif (pas bien) qui n’est pas du tout viable à long terme. — Arnaud Foraison— Développeur fullstack
En conclusion
Il faut être très pragmatique dans le management des applications legacy. Il est nécessaire d’avoir une gouvernance qui vous permettra de mettre sous contrôle l’obsolescence de vos applications. La conséquence : des évolutions à effectuer dans une relative sérénité. Mon dernier conseil et pas le moindre : prendre soin de vos développeurs afin de les préserver du long voyage qui vous attend.
Ça y est : on arrive au bout de cet article.
On peut toujours s’améliorer. J’ai donc hâte de lire vos feedbacks en commentaires sur vos stratégies de gestion de legacy en mode run et/ou évolution.
