Refaire ou reprendre ? Les critères pour décider avant de payer une reconstruction

Pourquoi « tout refaire » séduit autant

L'existant est mal connu, chaque modification casse quelque chose, et la promesse d'une application neuve, propre et documentée est rassurante. Pour le prestataire, c'est aussi plus simple : on part de zéro, sans avoir à comprendre le travail d'un autre.

Mais une reconstruction a un coût caché : l'ancienne application contient des années de règles métier, souvent écrites nulle part ailleurs. Les cas particuliers, les exceptions, les corrections faites après une réclamation. Une reconstruction qui ne les retrouve pas toutes recrée les problèmes que l'ancienne avait résolus.

Les critères qui penchent vers « reprendre »

• L'application fait ce qu'il faut, et le problème est sa fragilité, pas son utilité ;
• les règles métier sont nombreuses et mal documentées : les retrouver toutes coûterait plus cher que de stabiliser l'existant ;
• les données sont précieuses et bien structurées : une migration est toujours le moment le plus risqué d'un projet ;
• les problèmes sont localisés : quelques zones fragiles, pas une architecture à revoir entièrement ;
• la technologie est encore maintenue, même si elle n'est plus à la mode.

Les critères qui penchent vers « refaire »

• La technologie n'est plus maintenue, ni réparable (un langage ou une plateforme abandonnés, sans correctifs de sécurité possibles) ;
• chaque modification coûte plus cher que la précédente, et cela s'accélère ;
• le besoin a changé au point que l'application ne correspond plus à l'activité ;
• l'application est enfermée chez un fournisseur dont vous ne pouvez pas sortir autrement ;
• personne ne peut plus lire le code, et une analyse confirme qu'il serait plus long à comprendre qu'à réécrire.

Ce dernier point se vérifie, il ne se décrète pas. Un code « illisible » à première vue l'est souvent beaucoup moins après une lecture méthodique.

La troisième voie : remplacer par morceaux

Entre tout garder et tout refaire, il existe une approche éprouvée : remplacer l'application morceau par morceau. On isole une fonction (la facturation, l'espace client, le calcul des plannings), on la reconstruit à côté, on bascule, puis on passe à la suivante. L'ancienne application rétrécit pendant que la nouvelle grandit, et à aucun moment l'activité ne dépend d'une bascule unique et risquée.

C'est plus lent sur le papier, et beaucoup plus sûr en pratique : chaque étape apporte de la valeur, et le projet peut s'arrêter à tout moment sans laisser un chantier à moitié fini.

Les questions à poser à qui vous propose de tout refaire

1. Avez-vous lu le code actuel ? Une proposition de reconstruction faite sans lecture est une estimation au hasard.
2. Comment allez-vous retrouver toutes les règles métier de l'application actuelle ? Par quelle méthode, en combien de temps ?
3. Comment migrez-vous les données, et comment vérifiez-vous qu'aucune n'est perdue ou altérée ?
4. Que se passe-t-il pendant la reconstruction ? Qui maintient l'ancienne application, et qui corrige ce qui casse ?
5. Qu'est-ce qui sera différent dans deux ans ? Tests, documentation, propriété du code : sans eux, la nouvelle application deviendra l'ancienne.
6. Pouvez-vous faire par étapes ? Un refus catégorique est un signal.

Décider sur pièces

La bonne décision dépend de ce qu'il y a réellement dans le code, pas de l'impression qu'il donne. C'est la raison d'être de notre diagnostic : lire l'existant, classer les risques, et dire, preuves à l'appui, ce qui se stabilise, ce qui se reprend, et ce qui mérite d'être refait. Comme nous l'écrivons ailleurs : refaire sans avoir lu, c'est payer deux fois.