Migrer une application ancienne sans tout casser

Une demande revient régulièrement : « notre application a douze ans, il faut la refaire ». La réponse attendue est un projet de réécriture. Je la déconseille presque toujours.

Non par prudence excessive, mais parce que j’ai vu le scénario se dérouler assez souvent pour en connaître la fin.

Pourquoi la réécriture complète échoue

Elle suppose de reconstruire, en une fois, des années de règles métier dont l’essentiel n’est écrit nulle part. Ces règles vivent dans le code, et souvent dans des conditions ajoutées un vendredi soir pour un cas particulier que plus personne ne sait expliquer.

Elle suppose aussi que l’ancienne application cesse d’évoluer pendant la reconstruction. Ce qui n’arrive jamais : le métier continue, la réglementation change, les clients demandent. On se retrouve à maintenir deux systèmes en parallèle, avec une équipe dimensionnée pour un seul.

Et elle produit un effet tunnel : dix-huit mois sans rien livrer, pendant lesquels le budget se consomme et la confiance s’érode. Le projet est arrêté au bout de douze, avec deux systèmes incomplets.

Le remplacement progressif

Le principe tient en une phrase : on entoure l’ancienne application, puis on la vide de l’intérieur.

Étape 1 — un point d’entrée unique. On place devant l’application un composant qui reçoit tout le trafic et le transmet à l’existant. À ce stade, rien ne change fonctionnellement, et c’est le but : on vérifie que ce détour ne casse rien, sans avoir touché à une seule ligne de métier.

Étape 2 — détourner un parcours. On choisit un parcours petit, autonome et à faible risque. On le réécrit, et le point d’entrée l’aiguille vers le nouveau code. Tout le reste continue de passer par l’ancien.

Étape 3 — observer, puis supprimer. On laisse tourner quelques semaines, on compare les résultats, et une fois la confiance acquise on supprime le code correspondant dans l’ancienne application. Cette suppression est essentielle : sans elle, on accumule deux implémentations et la complexité augmente au lieu de diminuer.

Étape 4 — recommencer. Parcours après parcours, jusqu’à ce que l’ancienne application ne contienne plus rien.

Ce que ça change concrètement

L’application est en production en permanence. Chaque étape apporte une valeur observable, et chaque étape est réversible : si une bascule se passe mal, on rebascule le trafic vers l’ancien code en quelques minutes.

Surtout, on peut s’arrêter. Si le budget se réduit après huit mois, ce qui a été migré reste migré, et le reste continue de fonctionner. Une réécriture arrêtée à mi-parcours ne laisse rien.

Enfin, on apprend en avançant. Les premiers parcours révèlent les règles non documentées, et les suivants coûtent moins cher — l’inverse exact d’une réécriture, où les surprises s’accumulent jusqu’à la fin.

Photo : Ian Livesey — licence CC0.

Les trois conditions sans lesquelles ça ne marche pas

Il faut pouvoir découper. Une application où tout appelle tout, sans frontières, ne se migre pas parcours par parcours. Le premier chantier consiste alors à créer ces frontières dans l’ancien code — ce qui est un travail en soi, à annoncer comme tel.

Il faut gérer les données partagées. Les deux systèmes lisent et écrivent la même base pendant la transition. Cela impose de décider, pour chaque table, qui a autorité — et d’accepter une période où le schéma sert deux usages. C’est la partie la plus délicate, et celle qui demande le plus de discipline.

Il faut supprimer au fur et à mesure. C’est la condition la plus souvent trahie. Une équipe sous pression migre sans jamais nettoyer, et se retrouve avec deux systèmes complets à maintenir. Ma règle : la suppression de l’ancien code fait partie de la tranche, pas d’un chantier ultérieur.

Combien de temps

Plus longtemps qu’une réécriture sur le papier, moins longtemps en pratique.

Sur une application métier de taille moyenne, comptez douze à vingt-quatre mois pour une migration complète, à raison d’un parcours toutes les deux à six semaines. C’est une durée qui effraie quand on l’annonce.

Mais le premier parcours migré arrive au bout de six à huit semaines, et le service rendu progresse en continu. Une réécriture annoncée à douze mois en prend dix-huit et ne livre rien avant la fin — quand elle livre.

Photo : Bob Richards — licence CC0.

Par quoi commencer, concrètement

L’ordre du découpage détermine la réussite bien plus que la technologie retenue.

Je commence toujours par un domaine peu couplé et à faible enjeu. Un module d’export, une gestion de référentiel, un espace de consultation. L’objectif du premier lot n’est pas de créer de la valeur métier : c’est de faire fonctionner l’aiguillage, la double authentification, la supervision et la procédure de retour arrière. Autrement dit, de construire le tuyau avant d’y faire passer quelque chose d’important.

Je garde pour la fin ce qui touche au cœur des données. La facturation, les droits, tout ce qui est écrit dans plusieurs tables à la fois. Ces domaines demandent que l’ancien et le nouveau système partagent une vérité commune, et c’est la partie la plus délicate de l’exercice.

Entre les deux, l’ordre suit une règle simple : le domaine qui coûte le plus cher à faire évoluer dans l’ancien système passe en premier. C’est lui qui rendra la migration visible aux yeux du métier, et c’est ce qui permet de tenir le financement dans la durée.

Vivre avec deux systèmes en parallèle

C’est la phase que personne n’aime, et elle dure longtemps.

Pendant cette période, deux applications coexistent, et les utilisateurs passent de l’une à l’autre. Trois précautions rendent cela supportable.

Une navigation sans couture. Même adresse, même authentification, même apparence générale. Si l’utilisateur doit se reconnecter en changeant d’écran, la migration devient impopulaire avant d’avoir produit ses effets.

Une seule source de vérité par donnée. Chaque table appartient à un système et un seul ; l’autre la consulte à travers une interface explicite. La double écriture est parfois inévitable sur de courtes périodes, et elle doit être traitée comme un dispositif temporaire avec une date de fin, pas comme une architecture.

Une date d’extinction annoncée. Sans elle, l’ancien système survit indéfiniment : chaque nouvelle demande urgente y est ajoutée « parce que c’est plus rapide », et la migration ne se termine jamais. C’est le mode d’échec le plus fréquent après la réécriture complète.

Quand la réécriture est justifiée

Il y a des cas, et je ne veux pas laisser penser le contraire.

Quand la technologie n’est plus maintenue et qu’aucun correctif de sécurité n’est disponible. Quand plus personne ne sait faire fonctionner l’existant, y compris pour un changement mineur. Quand le périmètre fonctionnel doit de toute façon changer entièrement — auquel cas ce n’est plus une migration, c’est un nouveau produit.

Dans les autres cas, la question à poser n’est pas « faut-il tout refaire ? » mais « quel est le premier parcours qu’on peut sortir de là ? ». Cette question a toujours une réponse, et elle se met en œuvre le mois suivant.