Remplacer un système legacy en une seule fois semble offrir une solution simple et maîtrisée. Sur le terrain, c’est souvent une illusion qui masque une complexité bien plus profonde.

Retour d’expérience

Dans une mission récente, j’ai vu revenir une idée que beaucoup connaissent :

“On arrête de bricoler l’ancien système, et on en construit un nouveau, propre, à côté. Puis on bascule.”

L’intention est bonne. L’ancien système est devenu difficile à maintenir, mal compris, parfois incohérent. Repartir de zéro semble logique.

Au début, tout se passe comme prévu. Le périmètre est défini. Les équipes avancent. Le nouveau système prend forme. Pendant ce temps, l’ancien continue de tourner, tant bien que mal.

Puis les premiers décalages apparaissent.

Certaines règles métier ne sont pas si claires, des comportements inattendus émergent, et des usages “informels” refont surface — fichiers Excel, scripts, contournements. On découvre alors que le système ne fait pas seulement ce qu’il est censé faire, mais aussi ce que les utilisateurs ont appris à lui faire faire. Et ça, ce n’était écrit nulle part.

En parallèle, le métier continue d’évoluer. De nouvelles demandes arrivent. Certaines doivent être implémentées en urgence dans l’ancien système. Mais comme on prépare le nouveau, il faut aussi les intégrer de l’autre côté. On commence à faire le même travail deux fois.

Le nouveau système, lui, avance… mais sans retour réel des utilisateurs. Les écarts s’accumulent silencieusement.

Et si, en plus, cette reconstruction s’accompagne d’un changement d’architecture vers des microservices mal délimités — cas malheureusement fréquent — la complexité inhérente au distribué vient alors s’ajouter à un problème déjà mal compris.

Et un jour, arrive le moment prévu : basculer. Le fameux “on appuie sur le bouton”.

Sauf que le système n’est pas complètement prêt. Il manque des cas. Des comportements. Des subtilités. Certaines fonctionnalités sont incomplètes, d’autres se comportent différemment. Les utilisateurs, eux, perdent leurs repères du jour au lendemain. Ce qui était maîtrisé devient imprévisible, et le système, censé simplifier, devient un obstacle.

Ce qui devait être une amélioration devient une rupture.

Pattern

Ce que j’ai observé n’a rien d’exceptionnel.

Ce type d’approche a un nom : le Big Bang replacement, notamment décrit dans le livre Domain-Driven Transformation, dont je reprends ici rapidement les grandes lignes.

L’idée est simple : construire un nouveau système en parallèle, puis remplacer l’ancien en une seule fois.

Ce qui l’est moins, ce sont les problèmes que cette approche sous-estime systématiquement.

D’abord, ce que les auteurs du livre appellent les “unknown unknowns” : tout ce que le système fait sans que personne ne le sache vraiment. Dans un système ancien, la logique métier est souvent dispersée, implicite, parfois même contournée. Il est pratiquement impossible de tout reconstituer à l’avance.

Ensuite, le décalage entre un système figé et un métier vivant.Pendant qu’on reconstruit, le monde continue de bouger. Le nouveau système est donc en retard avant même d’être livré.

Il y a aussi le travail en double. Même si on tente de geler l’ancien, certaines évolutions restent nécessaires : réglementaire, bugs critiques, ajustements métier. Ces changements doivent être répliqués dans le nouveau système, ce qui ralentit tout.

Et surtout, il y a le problème du feedback tardif. En livrant tout d’un coup, on découvre les erreurs trop tard.

Ce qui aurait pu être corrigé rapidement devient un problème structurel.

Enfin, il y a les utilisateurs. Ils connaissent les défauts du système actuel, mais ils savent travailler avec.

Avec un remplacement brutal, ils perdent cette maîtrise en une seule fois.

Conclusion

Sur le papier, remplacer un système d’un coup donne l’impression de reprendre le contrôle.

Dans la réalité, cela revient souvent à ignorer une chose essentielle :

un système legacy ne contient pas seulement du code. Il contient des usages, des habitudes, des détournements, et une part importante de connaissance implicite.

Et cette connaissance ne se remplace pas en appuyant sur un bouton.

Il existe heureusement d’autres approches. Elles ne sont ni simples, ni rapides, ni indolores. Elles n’éliminent pas les difficultés, mais elles évitent qu’elles se manifestent toutes en même temps. En avançant par étapes, sur des périmètres plus restreints, elles permettent d’obtenir des retours plus fréquents, de corriger plus tôt, et de transformer une rupture brutale en une succession d’ajustements maîtrisables.