Moderniser ou tout réécrire ? Un cadre de décision pour vos applications legacy

Situation générale

L’évolution logicielle a été théorisée à travers les lois de Lehman dès 1974 comme étant un équilibre entre des forces favorables et des forces contraires. Dans l’optique de cet article, nous nous intéresserons essentiellement aux lois de changement continu et de complexité croissante. L’idée simplifiée est celle qu’un logiciel doit évoluer pour conserver le niveau de satisfaction à l’usage et qu’à mesure de ce processus sa complexité augmentera.

Sur le terrain, bien souvent, un projet web est pensé, sur son volet technique, comme un produit fini et non comme un système nécessitant un suivi tout au long de son cycle de vie. Cette absence de vision long terme, accentuée par des conditions de conception souvent dictées par des contraintes non techniques, conduit généralement à une obsolescence logicielle à terme. Cette échéance est atteinte plus ou moins rapidement en fonction de la dette technique accumulée et de la rapidité d’évolution de l’écosystème au sein duquel le logiciel évolue.

Il n’est donc pas rare en pratique de se retrouver à devoir travailler avec un logiciel obsolète et avec une dette technique importante.

Quelles options?

Les raisons amenant à envisager l’évolution d’un logiciel obsolète sont multiples et cumulables. Cela peut être nécessaire pour intégrer de nouvelles fonctionnalités, assurer une compatibilité technique avec un logiciel tiers, par nécessité de sécurisation, de performance ou de conformité règlementaire, etc.

Quelles que soient les raisons sous-jacentes, et si l’on considère que le logiciel est critique pour l’activité de l’entreprise, l’architecte en charge du projet d’évolution a globalement quatre grandes options face à lui et doit arbitrer en fonction des spécificités du projet.

1. Le statu quo : option privilégiée lorsque les conditions de son évolution ne sont pas réunies. Seule la maintenance minimale est assurée, les interventions considérées sont principalement celles liées à la sécurité et à la conformité règlementaire.

2. La refactorisation : le but ici n’est pas une modification de son fonctionnement, mais une réduction de sa dette technique et de son obsolescence. Les enjeux sous-jacents sont d’assurer une meilleure fiabilité, sécurité et performance en remplaçant le code par du code plus moderne et en évitant les régressions autant que possible.

3. L’encapsulation : le code source est devenu trop complexe ou risqué à modifier et la mémoire du projet (documentation, parties prenantes historiques) ne permet pas d’avoir une vue d’ensemble du système et de son fonctionnement. On va donc tenter de l’isoler et de construire une interface moderne entre le logiciel legacy et les systèmes récents.

4. La ré-écriture : option la plus coûteuse et la plus risquée à court terme, mais le contexte la rend parfois inévitable souvent en raison de technologies totalement obsolètes, de dette technique trop lourde, de risques existentiels pour l’entreprise ou de coûts de maintenance à long terme beaucoup trop importants.

Un framework décisionnel

On ne résume pas une expertise en architecture logicielle en quelques lignes, chaque projet portant intrinsèquement son contexte. L’exercice de la simplification est pourtant tenant et je vous propose donc ci-dessous un framework décisionnel de première intention.

Il repose sur trois questions, à poser dans cet ordre, car chacune n’a de sens que si la précédente a reçu une réponse positive.

1. Les conditions d’une évolution sont-elles réunies ? Afin de mener à bien un projet d’évolution, il est nécessaire d'y allouer un budget, que ce soit purement financier, mais aussi en termes de disponibilité. Sans ces éléments, lancer le chantier expose à un projet inachevé, souvent plus coûteux que l’attente. Le statu quo s’impose alors, à condition d’être assumé comme une décision temporaire présentant des risques. La réponse ici est essentiellement conditionnée par des questions organisationnelle et financière.

2. Le socle technique a-t-il encore un avenir ? Un écosystème technique évolue, de nouvelles versions de PHP sortent, les plus anciennes arrivent en fin de support les exposant à des failles sécurisées qui ne seront jamais corrigées. Il en est de même pour les frameworks, bibliothèques et extensions. Il est donc nécessaire de vérifier que les dépendances utilisées sont toujours maintenues ou que les versions ultérieures peuvent être adaptées au projet. Le niveau de dette technique et la courbe des coûts de maintenance sont également à prendre en compte. Si le socle technique n’a plus d’avenir, la réécriture devient la seule option raisonnable. C'est pour apporter une réponse à cette question qu'un audit technique est essentiel.

3. Le code est-il compris et modifiable sans risque majeur ? La présence de tests automatisés, d’une documentation à jour et de personnes capables d’expliquer le fonctionnement du système conditionne la possibilité de le moderniser le système. Si ces éléments font défaut, l’encapsulation permet de continuer à faire évoluer le système d’information sans toucher au cœur du legacy. Dans le cas contraire, la refactorisation est généralement l’option la plus efficiente. C'est cette question qui présente le plus de nuances dans son analyse et c'est ici que l'expertise d'un architecte logiciel s'appuyant sur l'audit technique prend tout son sens.

Et Tchernobyl dans tout ça?

De prime abord l'analogie semble bancale, ne parle-t-on pas de la destruction complète d'un système et de la gestion de crise subséquente ? Quel rapport avec la modernisation d'un système informatique ? Strictement aucun, sauf à reporter l'objet de notre attention sur le sarcophage de confinement du réacteur numéro 4 construit en 1986 par les Soviétiques.

Notre système informatique legacy est matérialisé par ce premier sarcophage. En continuant notre analogie, au fur et à mesure de sa durée d'exploitation, la dette technique (liée à une construction en urgence) a rendu celui-ci obsolète par rapport aux défis contemporains, et pourtant le besoin n'a jamais cessé d'exister.

Appliquons notre framework décisionnel à ce cas concret.

1. Les conditions d'évolution ? : oui, le sarcophage doit évoluer sous peine de ne plus pouvoir répondre aux objectifs de confinement et face à l'urgence environnementale posée par sa dégradation. Et au niveau du financement celui-ci a été assuré par une coalition internationale. Se retrouvent ainsi remplies les conditions de besoin, de disponibilité et de financement. Opter pour le statu quo n'a donc pas lieu d'être.

2. Le socle technique ? : sur cette question l'analogie soulève des questions intéressantes et on commence à entrevoir l'objet pédagogique de cette section. Maintenir l'ancien sarcophage n'était plus viable à plus ou moins long terme. Selon cette perspective, le socle technique n'avait plus d'avenir, rajouter du béton, combler les fuites n'avait pas de sens. Une réponse formelle d'après notre framework décisionnel serait de le remplacer par un nouveau, nous partirions donc logiquement sur une ré-écriture. La pertinence de l'analogie se retrouve ici dans la nécessité de maintenir l'ancien sarcophage pendant une période de transition malgré son obsolescence, donc on ne peut simplement le remplacer.

3. Modifiable sans risques ? : contrairement à la plupart des logiciels, le sarcophage ne peut pas être démantelé et remplacé dans un laps de temps suffisamment court pour que son absence n'induise pas de conséquences désastreuses. La continuité du système doit donc être assurée, mais l'objectif de remplacement à terme est indéniable. Les opérations techniques sur le premier sarcophage doivent être réalisées en plusieurs étapes afin de maintenir la continuité du système et de réduire les risques et de maximiser la sécurité des opérations et des intervenants.

En résumé, nous avons ici un système obsolète avec une dette technique importante, dont le maintien en l'état n'est plus possible, mais pour lequel le besoin n'a jamais cessé d'exister. Le socle technique est obsolète par rapport aux défis contemporains, mais un remplacement pur et simple n'est pas possible car le système doit remplir son rôle en permanence.

La solution est donc hybride et s'est traduite par la construction puis la mise en service, entre 2012 et 2019 d'un nouveau sarcophage nommé "Arche de Tchernobyl" à côté du site d'origine, puis relié à celui-ci par la suite. Il s'agit d'un nouveau système (ré-écriture) visant à servir dans un premier temps d'interface (encapsulage) entre l'ancien système et le monde extérieur. Que ce soit pour le protéger, contre les intempéries par exemple, ou pour contenir le danger environnemental qu'il représente. Son rôle à plus long terme est aussi de permettre le nettoyage du site (refactoring) et qui, au final, une fois les opérations de nettoyage terminées (le code legacy modernisé et supprimé) remplacera l'ancien système.

Les enseignements à tirer de cette analogie sont qu'une solution peut parfois être hybride, que le plan d'action dépend systématiquement du principe de réalité posé par le contexte, mais aussi qu'il est impératif d'avoir un engagement fort des parties prenantes et un investissement à la hauteur du ROI espéré sur le long terme.

Les pièges à éviter

Une approche trop simpliste peut conduire à des décisions eronnées. Voici quelques pièges à éviter.

• Considérer le statu quo comme une absence de risque : un logiciel figé continue de vieillir. Chaque version de PHP qui arrive en fin de support, chaque dépendance abandonnée réduit les options disponibles et augmente les risques opérationnels et le coût des prochaines décisions.
• La réécriture « Big Bang » : livrer un nouveau système en une seule fois, après de longs mois pendant lesquels l’ancien doit continuer d’être maintenu et les demandes métier s’accumulent, concentre tout le risque sur le jour de la bascule. Une réécriture et une mise en production étape par étape est presque toujours préférable.
• Oublier ce que le code sait : un logiciel en production depuis des années contient des règles métier, des exceptions et des corrections de cas limites qui ne sont documentées nulle part ailleurs. Un audit rigoureux pour les identifier avant de modifier ou de remplacer quoi que ce soit évite de les redécouvrir en production.