La phrase la plus dangereuse quand on possède un logiciel est peut-être « il faudrait simplement le réécrire ». On la prononce à propos de systèmes qui le méritent - quinze ans d’âge, sans documentation, tenus par les deux personnes qui se souviennent encore pourquoi le module de facturation se comporte ainsi. On la prononce aussi à propos de systèmes porteurs : les commandes, les stocks, la facturation et la paie y transitent chaque jour, et l’entreprise s’arrête quand ils s’arrêtent. La promesse de la réécriture séduit parce qu’elle est nette. Un nouveau système, construit correctement cette fois, et un beau jour on bascule. Le bilan réel est moins net : les réécritures d’un bloc de systèmes en fonctionnement échouent assez souvent, et assez cher, pour que la formule mérite d’être traitée comme une affirmation à démontrer plutôt que comme un plan.
Il existe une alternative dont le taux d’aboutissement est bien meilleur : le remplacement incrémental - le motif strangler-fig, nommé d’après le figuier étrangleur qui pousse autour de son arbre-hôte jusqu’à ce que celui-ci ne porte plus rien. Le nouveau système croît autour de l’ancien, reprend un module à la fois, et l’ancien est mis hors service quand plus rien n’est routé vers lui. C’est moins spectaculaire qu’une réécriture. C’est précisément l’idée.
Pourquoi les grandes réécritures échouent
Les modes de défaillance sont assez prévisibles pour avoir des noms. Le premier est l’effet du second système : l’équipe qui reconstruit emporte dans la reconstruction toutes les ambitions que l’ancien système avait étouffées. Un projet cadré comme « ce que fait l’ancien système, sur une pile moderne » devient discrètement « ce que fait l’ancien système, plus le reporting que les commerciaux ont toujours voulu, plus une architecture de plugins, plus le multi-tenant au cas où ». Le périmètre s’étend dans le seul projet où il était censé être figé, parce que l’ancien système est là, rappel quotidien de tout ce qu’il n’a jamais su faire.
Le deuxième est la fenêtre de gel fonctionnel. Une réécriture ne reste une réécriture que si la cible ne bouge pas ; on gèle donc l’ancien système pendant la construction du nouveau. Mais l’entreprise, elle, ne gèle pas. Dix-huit mois, c’est long pour annoncer aux commerciaux qu’il n’y aura rien de nouveau, et presque aucune entreprise ne tient cette ligne - les évolutions repartent donc dans l’ancien système, la réécriture court après une cible mouvante, et l’écart entre les deux se creuse au moment précis où il était censé se refermer.
Le troisième, ce sont les données que personne ne comprend. Un système qui fait tourner une entreprise depuis dix ans n’est pas décrit par sa documentation ; il est décrit par son comportement. L’arrondi étrange dans le calcul des remises, le code de statut qui n’existe que pour un client de 2016, le traitement nocturne qui répare ce que l’équipe de jour casse - rien de tout cela ne figure dans une spécification, parce que l’ancien système estla spécification. Une réécriture d’un bloc découvre ces exigences au pire moment possible : après la bascule, en production, sous forme de tickets de support. Cette découverte est en général ce qui tue le projet.
À quoi ressemble concrètement un remplacement incrémental
Le motif strangler comporte peu de pièces mobiles. D’abord, une façade est placée devant l’ancien système - une couche de routage qui reçoit chaque requête et, le premier jour, les transmet toutes telles quelles. Rien ne change, sinon que la porte d’entrée vous appartient désormais. C’est tout le premier jalon, et il vaut plus qu’il n’y paraît : à partir de là, l’endroit où réside chaque fonctionnalité devient une décision de routage que vous contrôlez, invisible pour les personnes qui utilisent le système. La façade peut être une passerelle d’API, un reverse proxy ou un service léger que vous écrivez - la technologie compte bien moins que le fait de l’avoir.
Ensuite, le remplacement avance module par module. Une partie bornée du système - l’établissement des devis, par exemple - est reconstruite en un nouveau service sur une pile délibérément ennuyeuse, car une modernisation est le dernier endroit où dépenser son budget nouveauté. Le nouveau module tourne en parallèle de l’ancien : les deux reçoivent les mêmes entrées, les deux produisent des sorties, et les sorties sont comparées. La réponse de l’ancien module est celle que voient les clients ; celle du nouveau est une ombre, journalisée et comparée.
La bascule se fait module par module, et uniquement quand les chiffres concordent - pas à la date de la feuille de route, pas quand la démo est belle, mais quand le rapport d’écarts est resté propre, ou explicablement non propre, assez longtemps pour qu’on lui fasse confiance. La façade route alors les devis vers le nouveau module, l’ancien reste en service comme solution de repli, et l’attention passe au module suivant. Chaque étape est petite, mesurée et réversible - soit exactement ce qu’une bascule d’un bloc n’est pas.
L’ancien système n’est pas l’ennemi. Il est la spécification, l’oracle de test et le filet de sécurité - jusqu’au jour où plus rien n’est routé vers lui.
Comment choisir le premier module
Le premier module porte une part disproportionnée du sort du projet, car sa vraie mission est de prouver la mécanique - la façade, l’exécution parallèle, le rapprochement, la bascule - sur quelque chose qui ne peut pas couler l’entreprise. Trois filtres font l’essentiel du travail. Couplage faible : choisissez ce qui partage le moins de tables et d’appels avec le reste du système - génération de documents, notifications, un flux de reporting - pour ne pas avoir à démêler tout le nœud dès le premier jour. Douleur forte : choisissez ce dont les gens se plaignent activement, pour que la première bascule produise un résultat que quelqu’un d’extérieur au projet remarque. Le meilleur candidat est souvent le processus que l’équipe rafistole déjà à coups d’exports et de ressaisies - la couche tableur autour d’un système historique est la carte de ses points douloureux. Mesurable : choisissez quelque chose dont la sortie peut être comparée mécaniquement - documents générés, totaux calculés, temps de réponse - car toute la discipline de bascule repose sur des chiffres à faire concorder.
Ce que le premier module ne doit pas être, c’est impressionnant. Petit, agaçant et dénombrable vaut mieux que vaste et stratégique. Un premier module qui prend six semaines et bascule proprement achète plus de crédibilité qu’un module qui prend six mois et basculera peut-être. Les modules stratégiques viennent ensuite, une fois que la mécanique a survécu au contact de la production.
Le problème des données
Le code est la moitié facile d’une modernisation. La moitié difficile, ce sont les données, et le principe directeur est brutal : l’ancien système reste la source de vérité tant que le nouveau n’a pas prouvé le contraire, module par module. En pratique, cela signifie que les données circulent dans un seul sens tant qu’un module est en mode ombre - synchronisées de l’ancien vers le nouveau par capture des changements si l’ancienne base le permet, par lot nocturne si c’est tout ce que la plateforme autorise. Le nouveau module lit sa copie synchronisée, calcule ses réponses et n’écrit rien en retour dont quiconque dépende.
Entre le mode ombre et la bascule se place la période de rapprochement, et c’est là que les vraies exigences apparaissent. Les deux systèmes traitent le travail de la même journée ; un traitement de comparaison confronte les résultats ; chaque écart est instruit. La plupart des écarts sont des erreurs du nouveau système, de celles qu’aucune spécification n’aurait attrapées - l’arrondi non documenté, le client traité en cas particulier. Instruits un à un, en mode ombre, ce sont des leçons peu coûteuses. Les mêmes découvertes après une bascule d’un bloc sont des pannes.
Certains écarts pointent dans l’autre sens : c’est l’ancien système qui avait tort, et l’entreprise absorbe silencieusement l’erreur depuis des années. Ce sont des décisions, pas des bugs - préserver l’ancien comportement par continuité, ou le corriger et prévenir les personnes concernées ? Les deux réponses peuvent être bonnes ; ce qui est mauvais, c’est de trancher par accident, ce qu’a fait chaque réécriture qui n’a jamais fait tourner les deux systèmes côte à côte. Ce n’est qu’à la bascule que la propriété des données du module est transférée - le nouveau système devient l’écrivain, et le traitement de rapprochement continue de tourner quelque temps ensuite, comme fil de détente.
Quand la réécriture est le bon choix
L’honnêteté impose de présenter le contre-argument, car le remplacement incrémental n’est pas gratuit - la façade, la synchronisation, l’exécution parallèle coûtent un effort qu’une réécriture propre éviterait. Ce surcoût est une assurance, et une assurance ne vaut pas la peine d’être souscrite pour chaque maison. Si le système est assez petit pour qu’un remplacement ciblé soit livré en 2-3 mois, la mécanique de coordination peut coûter plus cher que le risque qu’elle supprime. Si la plateforme est véritablement morte - un environnement d’exécution pour lequel on ne recrute plus, du matériel irremplaçable, un éditeur qui n’existe plus - il ne reste peut-être rien de stable à étrangler. Et si le système a peu d’utilisateurs, capables d’absorber une bascule sèche - un outil interne utilisé par une équipe à qui vous pouvez parler de vive voix - l’exécution parallèle est une prudence que la situation n’exige pas.
Même dans ce cas, gardez deux habitudes du remplacement incrémental : migrer les données avant l’échéance plutôt que pendant, et faire tourner l’ancien et le nouveau côte à côte pendant une période de validation si c’est possible d’une manière ou d’une autre. Le choix entre réécriture et strangler fixe la taille du dispositif de sécurité - il ne change rien au fait que les sorties doivent être vérifiées avant que quiconque en dépende.
Le versant politique
Une modernisation qui dure un an est un projet politique, quelle que soit l’architecture. Deux systèmes qui tournent côte à côte, cela veut dire payer les deux, et à un moment une personne raisonnable posera la question que redoute tout projet long : est-ce que cela finira un jour ? La qualité la plus sous-estimée du motif strangler, c’est qu’il produit lui-même la réponse. Comme le remplacement se fait module par module, l’avancement est dénombrable - modules basculés, part du trafic servie par le nouveau système, incidents par bascule. Le projet a un tableau de score, pas une estimation d’avancement en pourcentage restée à quatre-vingts pendant un an.
La cadence qui entretient la confiance, c’est la démo hebdomadaire de quelque chose de réel : pas des diapositives, mais le nouveau module de devis produisant les devis réels de la semaine à côté de ceux de l’ancien, avec les écarts à l’écran. Les parties prenantes voient les divergences se réduire de semaine en semaine, ce qui fait plus pour la confiance que n’importe quel plan. Et les engagements restent petits, volontairement : ne promettez jamais la date de la mort de l’ancien système - promettez le module suivant, livrez-le, recommencez. C’est cette cadence qui rythme nos missions de modernisation de l’existant, et c’est la différence entre une modernisation à laquelle l’entreprise croit et une qu’elle se contente de tolérer.
On parle généralement de l’ancien système comme du problème. Bien traité, il est l’inverse : une spécification complète et en fonctionnement de ce dont l’entreprise a besoin, un oracle de test qui note chaque réponse du remplaçant, et un filet de sécurité qui rend chaque étape réversible. La grande réécriture jette ces atouts, puis échoue faute de les avoir. Le remplacement incrémental les dépense, délibérément, module par module - jusqu’au jour où quelqu’un consulte la table de routage, n’y trouve plus rien qui pointe vers l’ancien système, et l’éteint. Sans drame. C’était bien l’idée.