Moderniser un logiciel ancien : cinq chantiers

Moderniser un logiciel ancien désigne cinq chantiers qui n’ont ni le même prix, ni la même durée, ni le même risque. Remettre à niveau ce qui fait tourner l’outil sous des écrans qui ne bougent pas, le remplacer morceau par morceau pendant qu’il continue de servir, le réécrire entièrement et basculer à une date, acheter un produit du marché à la place, ou décider de ne pas y toucher pour l’instant, voire de l’éteindre. Un devis établi avant d’avoir tranché entre ces cinq-là chiffre autre chose que ce que vous avez demandé. Et le tri ne se fait pas sur l’âge de l’outil : il se fait sur trois points observables, ce qu’une modification coûte à vérifier, ce qui porte une date que vous n’avez pas fixée, et ce que vos règles de calcul ont de consigné ailleurs que dans le code. Un quatrième point ne dit rien de l’état de l’outil et tranche pourtant l’une des cinq routes, ce que vos données savent en sortir.

Trois points à relever avant de parler de chantier

L’âge sert à ouvrir la discussion et ne sert à rien pour la trancher. Un outil écrit il y a douze ans, que deux personnes modifient sans appréhension parce qu’elles voient tout de suite si elles ont cassé quelque chose, n’appelle aucune réécriture. Un outil de quatre ans que plus personne n’ose rouvrir en appelle une. Entre ces deux-là, ce qui diffère n’est pas la date d’écriture.

Les trois points qui suivent se relèvent sans compétence technique, en trois questions adressées à l’équipe qui maintient l’outil. Chacun d’eux ferme ou laisse ouverte une partie des cinq chantiers. Si la gêne elle-même n’est pas encore localisée, commencez un cran plus tôt, par le diagnostic qui sépare quatre situations derrière une même plainte.

Une modification se vérifie, ou elle se parie

Michael Feathers, dans l’ouvrage qu’il consacre au travail sur les logiciels anciens, propose une définition qui ne retient ni l’âge ni la technologie : pour lui, un code hérité est simplement un code sans tests. Il en donne la raison aussitôt. Avec des tests, écrit-il, on change le comportement du code vite et de façon vérifiable. Sans eux, on ne sait pas si le code s’améliore ou empire.

Ce qu’il appelle des tests, ce sont des tests de non-régression : un jeu de vérifications automatiques rejouées après chaque modification, qui signalent qu’une fonction qui marchait hier ne marche plus. Quand ce jeu n’existe pas, chaque modification se termine par une recette à la main, et la vérification finit par coûter plus cher que la modification elle-même. C’est le premier poste qui gonfle sur un logiciel hérité, bien avant qu’une réécriture soit sur la table.

Ce point décide de la route plus que tout autre. Un chantier mené morceau par morceau consiste à remplacer une partie en laissant le reste tourner, donc à affirmer après chaque lot que le reste tourne toujours. Sans vérification automatique, cette affirmation n’est pas tenable, et le projet glisse vers une réécriture complète par défaut, faute de pouvoir prouver quoi que ce soit entre deux lots.

Des dates que vous n’avez pas fixées

Votre logiciel repose sur un socle technique venu d’ailleurs, système d’exploitation, langage, base de données, dont les éditeurs annoncent longtemps à l’avance le jour où ils cessent de le corriger. Microsoft écrit ainsi, sur la page qui couvre les éditions Home et Pro de Windows 10, que le système a atteint sa fin de support le 14 octobre 2025, que la version 22H2 en est la dernière, et que toutes les éditions qu’elle couvre ont bénéficié de mises à jour de sécurité mensuelles jusqu’à cette date. La même page pose ensuite la réserve qui vous concerne : les versions déjà publiées de la déclinaison à support long, celle que Microsoft désigne par le sigle LTSC, continuent d’être mises à jour au-delà, chacune selon son propre cycle. Une date de fin de support vaut donc pour une édition et une version précises, et ce sont elles qu’il faut identifier avant d’en tirer la moindre conséquence. Une fois qu’elles le sont, la date s’impose seule, sans rien devoir à l’état réel de votre outil ni à vos priorités.

Une échéance proche sur une brique dont tout l’outil dépend impose son rythme au chantier, quelle que soit la route retenue, et c’est ce qui explique qu’une modernisation ne puisse pas toujours attendre le prochain exercice budgétaire. La manière dont cette échéance se relève, et la raison pour laquelle elle se finance sur une ligne séparée du reste, sont traitées ailleurs, dans ce qui tombe à une date publiée et ce qui attend seulement que vous rouvriez le code.

Des règles de calcul que personne n’a écrites

La remise de fin d’année, la priorité entre deux commandes arrivées le même jour, le traitement particulier d’un client entré au catalogue en 2009 : sur un outil ancien, ces règles de calcul vivent dans le code et nulle part ailleurs. Les personnes qui les avaient en tête sont parties, et ce qui en reste tient dans ce que la machine fait, pas dans ce qu’un document décrit.

Tant que c’est le cas, les routes qui réécrivent quelque chose ne démarrent pas sur une spécification. Elles démarrent sur une lecture du code destinée à reconstituer ce que l’outil fait réellement, y compris les comportements que personne n’avait voulus et dont vos équipes ont fini par dépendre. Ce travail se chiffre, il passe avant le reste, et il produit un document qui vous servira quelle que soit la route retenue ensuite. Ce qu’il coûte et ce qu’il rend est détaillé dans le cas d’un code reçu sans un document pour l’accompagner.

Les cinq chantiers que le mot recouvre

Amazon Web Services publie, dans son guide des grandes migrations vers son cloud, une grille de sept stratégies qu’il appelle les sept R. Elle a été écrite pour un déplacement d’hébergement, et elle en recommande certaines plutôt que d’autres pour ce cas-là. Ce qu’elle apporte ici est plus modeste : elle inscrit sur une même liste le fait de déplacer l’outil sans y toucher, de le réorganiser, de le remplacer par un produit acheté, de le laisser où il est, et de l’éteindre. Deux de ces stratégies laissent votre logiciel intact et se contentent de le déplacer, le document écrivant de l’une qu’elle se fait sans aucun changement dans l’application, et de l’autre qu’elle n’oblige ni à acheter du matériel neuf, ni à réécrire l’application, ni à modifier votre exploitation. Deux autres ne le déplacent même pas, puisqu’elles consistent à le garder où il est ou à l’arrêter.

Les cinq chantiers qui suivent ne se déduisent pas de cette grille, et deux d’entre eux n’y figurent pas. Ce sont ceux que le mot recouvre sur un outil métier utilisé tous les jours par vos équipes. Chacun porte la condition qui le rend défendable, parce qu’un chantier retenu sans sa condition produit un devis que vous ne saurez comparer à aucun autre.

Changer ce qui est dessous en laissant les écrans intacts

Vos écrans ne bougent pas, vos calculs ne bougent pas, et le remplacement ne concerne que les briques qui tournent dessous. Les prestataires appellent ce travail iso-fonctionnel, c’est-à-dire à fonctions constantes. Il se chiffre mieux que les autres parce que son périmètre est fixé d’avance : tout ce que l’utilisateur voyait doit se retrouver à l’identique, et cette exigence tient lieu de recette.

Sa condition est celle d’un outil dont vos équipes ne se plaignent pas. Si vos utilisateurs le contournent déjà avec un tableur, ce chantier vous rendra les mêmes contournements sur des briques neuves, au prix d’un projet entier. Ce qu’il couvre exactement, et ce qu’il laisse volontairement de côté, tient dans le fait de reprendre l’outil par le dessous en gardant ses écrans et ses calculs.

Remplacer morceau par morceau pendant que l’outil tourne

Le nouveau logiciel se construit à côté de l’ancien et lui prend ses fonctions une par une. Martin Fowler décrit le mécanisme par une image, celle du figuier qui pousse autour de son hôte : le chantier commence par de petites additions, souvent des fonctions nouvelles, construites par-dessus le code existant tout en restant séparées de lui. Il en tire l’argument qui compte pour vous, une fois en service, ces nouveaux morceaux rendent leur valeur au métier, ce qui fait revenir l’investissement plus tôt.

La condition tient en deux points. L’outil doit se découper, c’est-à-dire qu’un aiguillage puisse envoyer une partie des utilisateurs vers le nouveau morceau et le reste vers l’ancien. Et les tests de non-régression doivent exister, sinon chaque bascule se fait sans filet. C’est le seul des cinq chantiers qui mette quelque chose d’utilisable entre les mains de vos équipes avant sa fin.

Tout réécrire et basculer à une date

Le nouvel outil se construit entièrement de son côté, l’ancien continue de servir, et une date fait passer tout le monde d’un coup. Fowler écarte cette route sans détour : remplacer un système informatique sérieux prend longtemps, écrit-il, et les utilisateurs ne peuvent pas attendre les fonctions nouvelles pendant ce temps. Ce plan d’apparence simple, ajoute-t-il, ils l’ont vu partir en fumée la plupart du temps.

Cette route reste pourtant la seule ouverte quand l’outil ne se découpe pas, le cas d’une base de données unique que chaque écran lit et écrit directement, sans aucun endroit où poser un aiguillage. Sa condition devient alors budgétaire plus que technique : tant que dure la réécriture, vous payez deux outils, celui qu’on construit et celui qu’on continue de corriger. Cette ligne de double entretien court aussi longtemps que le chantier, et elle figure rarement dans la proposition de départ.

Acheter un produit du marché à la place

Cette route porte le nom de repurchase dans la grille citée plus haut, le rachat d’un produit tout fait. Le document la range parmi ses cas d’usage courants et en nomme un : remplacer une application développée sur mesure par un produit d’éditeur, ce qui évite d’avoir à la recoder et à en repenser l’architecture. Qu’un produit acheté puisse remplacer votre outil sans qu’on le recode, mieux vaut l’entendre d’un prestataire avant de lui commander une réécriture, pas après.

Un outil du marché tient tant que votre activité reste dans son périmètre. Le sujet se rouvre le jour où vos équipes commencent à le contourner, une relance notée à la main parce qu’il ne la programme pas, un second écran ouvert en parallèle pour ce qu’il ne sait pas croiser. Les critères qui tranchent dans un sens ou dans l’autre sont rassemblés dans les cas où un produit du marché couvre le besoin sans contournement. Un point conditionne toute cette route et se vérifie avant tout le reste, la reprise des données : douze ans d’historique qui ne sortent pas de l’ancien outil dans un format exploitable transforment un abonnement en projet à part entière.

Ne rien faire pour l’instant, ou éteindre

La grille des sept R ouvre sa liste par ces deux-là. Elle nomme d’abord le décommissionnement, c’est-à-dire l’arrêt de l’outil et l’extinction des serveurs qui le font tourner, et elle donne un signal mesurable pour le repérer, plus aucune connexion entrante sur les 90 derniers jours. Elle nomme ensuite le fait de ne pas migrer, et range parmi ses cas le logiciel dont le déplacement n’apporte aucune valeur métier, par exemple un outil dont se servent seulement quelques personnes en interne. Ces deux issues méritent leur place sur la table au même titre que les quatre chantiers précédents.

Éteindre est la seule issue de toute la série qui retire une ligne de votre budget au lieu d’en ajouter une. Sur un parc accumulé année après année, il arrive qu’un des logiciels que vous vous apprêtiez à moderniser soit devenu la copie moins bonne d’un autre, déjà en service dans un département voisin. Cette vérification ne demande aucun prestataire, et elle se mène avant d’en solliciter un. Ces deux issues partagent une même condition, la seule de la série qui ne porte pas sur le code : savoir qui se sert de l’outil, et pour quoi. Tant que cette liste n’existe pas, ne rien faire n’est pas une décision, c’est un report.

Quatre relevés, et ce que chaque réponse change

Les cinq routes ne se comparent pas de front. Elles se retirent une par une, à partir de quatre relevés qui tiennent sur une page et n’engagent rien. Les trois premiers reprennent les trois points du début, posés cette fois en question à qui détient la réponse. Le quatrième n’est apparu nulle part jusqu’ici, parce qu’il ne décrit pas l’état de l’outil mais ce qui peut en sortir.

Le premier relevé porte sur la vérification : quels tests automatiques existent, sur quelles parties de l’outil, et combien de temps sépare aujourd’hui une correction écrite de sa mise en service. Une réponse qui décrit deux jours de recette à la main retire le remplacement morceau par morceau de la table, non pas définitivement, mais tant qu’un premier lot n’a pas installé de quoi vérifier. Ce lot-là se chiffre seul, et vaut d’être demandé seul.

Le deuxième porte sur les briques et leurs dates : lesquelles font tourner l’outil, dans quelle version, dans quelle édition exactement, et jusqu’à quand leur éditeur les corrige encore. Une échéance dans les douze mois ne désigne aucune route en particulier. Elle impose une date de mise en service à celle que vous retiendrez, ce qui élimine tout ce qui demande plus de temps que ce délai.

Le troisième porte sur les règles : ce qui est écrit ailleurs que dans le code, et à quel endroit. Une réponse vide ajoute aux deux routes qui réécrivent une ligne de lecture du code, à demander chiffrée à part, et elle rend du même coup plus raisonnable celle qui ne réécrit rien.

Le quatrième porte sur la sortie des données : quels formats l’outil sait produire, sur quel périmètre, et si l’historique complet en fait partie. Il commande la route de l’achat, et il conditionne aussi la journée de bascule des deux routes qui réécrivent. C’est le seul des quatre qui porte sur ce qui sort de l’outil plutôt que sur ce qu’il contient.

Ces quatre relevés se demandent à l’équipe qui maintient l’outil. Lorsqu’ils ne reviennent pas, ou qu’ils se contredisent d’une réponse à l’autre, ce n’est pas le chantier qui commence, c’est une lecture du code et de l’hébergement commandée seule, dont le rapport vous reste acquis même si rien ne se décide derrière.

Par où commencer quand les cinq routes restent ouvertes

Comptez les routes que les quatre réponses laissent ouvertes, puis retirez celles que votre budget ne tient pas. Tant qu’il en reste plusieurs, mettre deux devis côte à côte n’apprend rien : deux prestataires qui n’ont pas retenu la même route ne chiffrent pas le même travail, et l’écart entre leurs prix ne mesure que cet écart-là. La comparaison des prix commence le jour où la route est arrêtée, et où vous la nommez dans votre demande.

Quand la route retenue consiste à reprendre l’outil plutôt qu’à le remplacer, le chantier avance par tranches successives, la première visant ce que plus personne n’ose toucher, et vos équipes travaillent dessus sans interruption du début à la fin. C’est ce que recouvre une remise à niveau menée par tranches, chiffrée et livrée tranche par tranche.

Vous pouvez préparer cette discussion sans nous, et c’est ce que nous vous conseillons de faire : les quatre relevés ci-dessus, réunis sur une page. Elle vous servira devant n’importe quel prestataire, nous compris. Si vous nous l’envoyez, c’est d’elle que part la discussion, et non d’une proposition écrite avant de savoir laquelle des cinq routes vous concerne.

Sources

Working Effectively with Legacy Code, Michael C. Feathers, Prentice Hall Professional Technical Reference, 2005, préface, https://archive.org/details/working-effectively-with-legacy-code

StranglerFigApplication, Martin Fowler, 22 août 2024, https://martinfowler.com/bliki/StranglerFigApplication.html

About the migration strategies, Guide for AWS large migrations, AWS Prescriptive Guidance, Amazon Web Services, consultée le 11 septembre 2026, https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html

Windows 10 Home and Pro, Microsoft Lifecycle, Microsoft, consultée le 11 septembre 2026, https://learn.microsoft.com/en-us/lifecycle/products/windows-10-home-and-pro