Moderniser les systèmes hérités : strangler fig et migration incrémentale

Ce qui fait d’un système un système hérité

Un système hérité (legacy) n’est pas simplement un vieux système. C’est un système qui fait encore quelque chose de précieux, souvent quelque chose sans quoi l’organisation ne pourrait pas fonctionner, mais qui est devenu difficile, risqué ou coûteux à modifier. Michael Feathers, dans Working Effectively with Legacy Code (2004), en a donné une définition volontairement provocatrice : le code hérité est du code sans tests, car sans tests chaque changement est un pari. Les autres causes courantes sont des compétences rares (un langage ou une plateforme que peu de gens connaissent encore), une technologie qui n’est plus supportée (un système d’exploitation ou une base de données arrivé en fin de support chez son fournisseur), une connaissance perdue (les personnes qui comprenaient la conception sont parties) et une dette technique accumulée dans la structure elle-même, le type coûteux décrit à la section 1.7.

Il faut le dire clairement : la plupart des systèmes hérités sont des systèmes qui ont réussi. Ils ont survécu parce qu’ils fonctionnaient et rapportaient de l’argent. Ce succès explique aussi pourquoi ils sont difficiles à remplacer : des années d’utilisation réelle y ont incorporé des milliers de petites décisions, de corrections et de règles métier qui ne sont écrites nulle part, sauf dans le code et dans les habitudes des personnes qui l’utilisent.

La modernisation a donc besoin d’une raison qui puisse s’énoncer en termes métier. Parmi les bonnes raisons : le coût ou le risque du changement bloque des objectifs métier importants ; la plateforme perd le support du fournisseur ou ses correctifs de sécurité ; les compétences pour la maintenir deviennent introuvables ; les coûts d’exploitation sont hors de proportion avec la valeur ; ou le système ne peut pas répondre à de nouvelles exigences d’échelle, de disponibilité ou de réglementation. Les mauvaises raisons sont la mode, l’ennui et la conviction qu’une nouvelle technologie est automatiquement meilleure. La section 11.8 montre comment transformer une bonne raison en analyse de rentabilité.

Pourquoi les réécritures échouent

La réponse évidente à un vieux système pénible est de tout recommencer. En avril 2000, Joel Spolsky a publié un essai, « Things You Should Never Do, Part I », soutenant que la décision de tout réécrire de zéro compte parmi les pires erreurs stratégiques qu’un éditeur de logiciels puisse commettre. Son exemple était Netscape, dont le navigateur est resté près de trois ans sans version majeure pendant la réécriture du code, période durant laquelle les concurrents ont pris le marché. Son argument central portait sur la connaissance : le vieux code paraît désordonné en partie parce qu’il contient des années de corrections de bugs pour des situations dont personne ne se souvient, et le jeter, c’est jeter aussi ces corrections.

Les raisons pour lesquelles une réécriture big bang échoue sont aujourd’hui bien comprises. La valeur n’arrive qu’à la fin, si bien que le métier attend des mois ou des années et perd patience. L’ancien système continue de changer pendant que le nouveau est construit : la cible bouge, et l’organisation soit gèle l’ancien système (et l’activité avec lui), soit paie pour faire chaque changement deux fois. Des comportements cachés sont oubliés, car personne ne peut énumérer toutes les règles que l’ancien système applique. Les estimations sont optimistes, car les fonctionnalités visibles ne sont qu’une fraction du travail réel. La migration des données et la bascule sont laissées pour la fin, au moment où elles sont les plus difficiles et les plus risquées. Et l’équipe se divise entre un groupe prestigieux chargé du nouveau système et un groupe démoralisé chargé de l’ancien. L’effet du second système de Fred Brooks, tiré de The Mythical Man-Month (1975), ajoute un risque supplémentaire : les concepteurs qui remplacent un système qu’ils connaissent ont tendance à charger le nouveau de toutes les idées que l’ancien ne pouvait pas accueillir.

Les grandes migrations qui basculent en une seule étape peuvent aussi échouer de façon très publique. En avril 2018, la banque britannique TSB a transféré les données et les services de ses clients vers une nouvelle plateforme informatique ; la plateforme a immédiatement connu de graves problèmes, toutes ses agences et une part importante de ses 5,2 millions de clients ont été touchées, et la banque n’a retrouvé un fonctionnement normal qu’en décembre 2018. En décembre 2022, la Financial Conduct Authority et la Prudential Regulation Authority ont infligé à TSB des amendes d’un total de 48,65 millions de livres sterling, estimant qu’elle n’avait pas correctement planifié, organisé et contrôlé la migration, ni géré les risques liés à son fournisseur externalisé.

Les praticiens ne s’accordent pas tous à dire que les réécritures sont toujours une erreur. Une réécriture peut être le bon choix quand le système est petit, que son comportement est bien spécifié et couvert par des tests, que la plateforme est vraiment dans une impasse, ou que le métier lui-même a tellement changé que l’ancien comportement n’est plus souhaité. Même alors, les réécritures les plus sûres sont livrées de façon incrémentale, l’ancien et le nouveau système fonctionnant côte à côte, ce qui est l’objet du reste de cette section.

Stratégies de migration : les R

Quand une organisation passe en revue tout un portefeuille d’applications, par exemple avant de quitter un centre de données, elle a besoin d’un vocabulaire pour décider quoi faire de chacune. Gartner a décrit cinq options de ce type au début des années 2010. En 2016, Stephen Orban, d’AWS, a publié six stratégies, et AWS en a ensuite ajouté une septième, ce qui donne les sept R utilisés aujourd’hui dans ses recommandations de migration. D’autres fournisseurs cloud et cabinets de conseil utilisent des listes semblables, avec des noms légèrement différents. La liste est surtout utile pour rappeler que reconstruire n’est qu’une option parmi plusieurs, et généralement la plus coûteuse.

Le strangler fig

Martin Fowler a nommé le patron incrémental le plus utilisé d’après les figuiers étrangleurs (strangler figs) qu’il a vus dans les forêts tropicales du Queensland en 2001 : des plantes grimpantes qui germent dans les branches d’un arbre hôte, poussent jusqu’au sol et entourent peu à peu l’hôte jusqu’à ce qu’il meure et que le figuier tienne debout seul. Il l’a décrit pour la première fois sous le nom de strangler application en 2004, l’a ensuite renommé strangler fig application et a profondément révisé l’article en 2024. La version logicielle, généralement appelée simplement strangler fig (figuier étrangleur), maintient l’ancien système en fonctionnement pendant que de nouveaux composants poussent autour de lui et reprennent son comportement un morceau à la fois, jusqu’à ce que l’ancien système ne fasse plus rien et puisse être éteint.

Le mécanisme comporte trois parties. D’abord, une couche d’interception est placée devant le système hérité : un reverse proxy, une API gateway ou une façade de routage par laquelle passent toutes les requêtes. Au départ, elle envoie tout à l’ancien système et ne change rien. Ensuite, une tranche de comportement est choisie le long d’un point d’articulation (seam : un endroit où le comportement peut être redirigé sans modifier une grande partie de l’ancien code, au sens de Feathers), reconstruite sous la forme d’un nouveau composant et activée en changeant une règle de routage, généralement d’abord pour une petite part du trafic. Enfin, le processus se répète jusqu’à ce que le système hérité ne traite plus rien ; il est alors retiré. Tout au long, la couche de routage rend chaque étape réversible : si le nouveau composant se comporte mal, la règle est rebasculée.

Le code qui permet à l’ancien et au nouveau de coexister (la façade de routage, les adaptateurs, les tâches de synchronisation des données) relève de l’architecture de transition : du logiciel construit pour être jeté. Les équipes rechignent souvent à l’écrire, car cela semble du gaspillage. L’argument de Fowler, et l’expérience qui le sous-tend, est que ce coût achète un risque réduit et une valeur bien plus précoce, ce qui est presque toujours un bon compromis. Le vrai danger est l’inverse : une migration qui cale à mi-chemin, laissant les deux systèmes et tout le code de transition en production indéfiniment. Chaque tranche doit donc retirer quelque chose de l’ancien système, et l’avancement doit se mesurer à ce qui a été éteint, pas seulement à ce qui a été construit.

Ian Cartwright, Rob Horn et James Lewis, de Thoughtworks, ont documenté une famille de techniques apparentées sous le titre Patterns of Legacy Displacement sur martinfowler.com (à partir de 2021). Ils présentent le travail comme quatre activités qui ne forment pas une séquence fixe : comprendre les résultats visés, décomposer le problème en parties, livrer ces parties de façon incrémentale, et faire évoluer l’organisation pour que le nouveau système ne se dégrade pas comme l’ancien. Ils remettent aussi en question le réflexe de reproduire chaque fonctionnalité : une grande partie du comportement d’un système hérité n’est peut-être plus souhaitée, et le vérifier coûte moins cher que de le reconstruire.

Branch by abstraction (branchement par abstraction)

Le strangler fig agit à la périphérie d’un système, là où les requêtes peuvent être routées. Certains remplacements doivent se faire au cœur d’une seule base de code : remplacer un framework de persistance, un moteur de tarification ou une couche de messagerie maison utilisée par des centaines de points d’appel. Branch by abstraction (branchement par abstraction), un nom introduit par Paul Hammant lorsqu’il défendait le développement basé sur le tronc et que Martin Fowler a décrit en 2014, y parvient sans branche de gestion de versions à longue durée de vie. Le système reste livrable à chaque étape, si bien que le changement peut s’étaler sur des semaines ou des mois pendant que d’autres travaux continuent sur la même ligne principale.

Prouver l’équivalence : exécution en parallèle et dark launching

La question la plus difficile de toute migration est de savoir si la nouvelle implémentation se comporte vraiment comme l’ancienne. Une exécution en parallèle (parallel run) y répond avec des preuves issues de la production : les deux implémentations reçoivent les mêmes entrées, l’ancienne continue de faire foi et c’est sa réponse qui est renvoyée à l’utilisateur, puis les deux résultats sont comparés et chaque écart est enregistré. GitHub a publié sa bibliothèque Scientist en 2016 exactement dans ce but : elle exécute côte à côte un contrôle et un candidat et signale les divergences ; des outils semblables existent pour de nombreux langages, et la technique est simple à écrire soi-même, comme le montre l’esquisse ci-dessous.

Le dark launching (lancement masqué), que Fowler décrit comme le fait d’appeler un nouveau comportement backend en production sans que les utilisateurs en voient les effets, en est proche. Il sert surtout à tester les performances et la stabilité du nouveau chemin sous une charge réelle avant qu’un utilisateur en dépende, tandis qu’une exécution en parallèle se concentre sur l’exactitude. Tous deux diffèrent d’une canary release (déploiement canari), dans laquelle une petite part des utilisateurs reçoit réellement le nouveau comportement.

Les deux techniques ont leurs pièges. Le candidat ne doit avoir aucun effet de bord visible de l’extérieur : il ne doit pas envoyer un second e-mail, débiter une carte deux fois ni écrire dans la base de données partagée ; les exécutions en parallèle sont donc plus faciles pour les lectures et les calculs, et les écritures exigent un bac à sable ou un stockage séparé. Les comparaisons doivent ignorer les différences légitimes, comme les horodatages, l’ordre et le formatage des nombres à virgule flottante, sinon le rapport des divergences se noie dans le bruit. Et exécuter les deux chemins consomme de la capacité : la part du trafic échantillonnée est donc souvent limitée.

def quote_delivery_fee(order):
    old = legacy_pricing.quote(order)          # still authoritative
    try:
        new = new_pricing.quote(order)         # must have no side effects
        if new.amount_pence != old.amount_pence:
            metrics.increment("pricing.mismatch")
            log.info("pricing mismatch", order_id=order.id,
                     old=old.amount_pence, new=new.amount_pence)
        else:
            metrics.increment("pricing.match")
    except Exception:
        metrics.increment("pricing.candidate_error")   # never hurts the user
    return old

Les données : la partie la plus difficile

Router les requêtes est relativement facile ; déplacer les données et les garder cohérentes pendant que deux systèmes en partagent la responsabilité, c’est là que la plupart des migrations peinent. La première règle est celle du chapitre 7 sur la propriété des données : pour chaque type de données, à chaque étape de la migration, l’équipe doit pouvoir dire quel système est le système de référence (system of record), quelles copies existent et à quel point chacune peut être périmée. Le diagramme ci-dessous montre l’inversion typique : le système hérité possède d’abord les données et le nouveau composant en lit une copie ; plus tard, le nouveau composant les possède et le système hérité en reçoit une copie pour les modules qui en ont encore besoin.

La capture des données modifiées est la manière habituelle de copier des données hors d’une base de données héritée sans modifier le code hérité : un outil comme Debezium lit le journal des transactions de la base et publie chaque changement sous forme d’événement, le même mécanisme que celui utilisé à la section 6.7 pour relayer une outbox. L’interception d’événements, l’un des patrons de remplacement des systèmes hérités (legacy displacement), agit à l’autre bout : elle capte les requêtes ou messages qui modifient l’état en route vers le système hérité et en transmet des copies (ou, plus tard, les originaux) au nouveau composant. Dans les deux cas, ne laissez jamais les deux systèmes accepter indépendamment des écritures sur les mêmes données avec une synchronisation bidirectionnelle, sauf si vous n’avez pas d’autre choix ; les conflits sont alors presque garantis.

Les données héritées correspondent rarement au nouveau modèle. Les codes de statut sont des entiers aux significations non documentées, une même table sert à trois usages, et les dates sont stockées en heure locale. Une couche anticorruption, le patron de la conception pilotée par le domaine qui protège un modèle de celui d’un voisin, traduit entre les deux pour que les bizarreries du système hérité ne s’infiltrent pas dans le nouveau code. Elle fait partie de l’architecture de transition et doit disparaître avec le système hérité.

La migration finale des données, qui déplace l’historique et effectue la bascule, mérite son propre plan. Profilez d’abord les données héritées pour trouver les doublons, les orphelins et les valeurs invalides. Écrivez explicitement la correspondance et testez-la sur une copie complète, à la taille de la production. Faites un rapprochement après chaque exécution avec des nombres de lignes, des sommes des colonnes monétaires et des sommes de contrôle, pas par des contrôles ponctuels. Répétez la bascule, chronométrez-la et mettez par écrit le retour arrière. Lorsque c’est possible, migrez par cohortes (une région, un segment de clientèle, une gamme de produits) plutôt que tout à la fois, afin qu’un problème ne touche qu’une fraction des clients et vous apprenne quelque chose avant la cohorte suivante.

Les leçons de Kill It with Fire

Kill It with Fire: Manage Aging Computer Systems (and Future Proof Modern Ones) (No Starch Press, 2021), de Marianne Bellotti, s’appuie sur son expérience de la modernisation de systèmes publics et commerciaux, y compris de parcs mainframe. Plusieurs de ses thèmes méritent d’être appliqués à toute modernisation.

La modernisation doit se justifier par la valeur qu’elle apporte et le risque qu’elle supprime, pas par l’âge de la technologie ; une vieille technologie bien comprise et qui fonctionne peut être la partie la moins risquée du parc. Les choix technologiques évoluent par cycles : une équipe qui remplace un système uniquement parce que sa conception est passée de mode risque de construire l’héritage de la génération suivante. L’amélioration incrémentale du système existant est généralement plus sûre que le remplacement, et une réécriture complète exige une justification exceptionnellement solide. Enfin, la modernisation est un problème d’organisation autant qu’un problème technique : elle a besoin de premières victoires visibles pour entretenir l’élan et le moral, de critères clairs pour savoir quand elle est terminée, et d’une attention aux incitations qui ont fait se dégrader l’ancien système, faute de quoi le nouveau suivra le même chemin.