Une application lente, instable, que personne n'aime. Le budget arrive. La décision semble évidente : on repart de zéro, sous une nouvelle technologie, avec une base saine.
C'est un réflexe courant - et parfois le bon choix. Mais avant d'en arriver là, il y a une question que peu de gens posent vraiment : d'où vient le problème ?
Ce que la refonte ne résout pas
Reconstruire une application résout les problèmes qu'elle a elle-même créés. Pas ceux qui viennent d'ailleurs. Voilà trois situations où repartir de zéro ne change rien au fond.
Les sources externes sont défaillantes. Une application qui charge ses données depuis des partenaires, des APIs tierces ou des outils interconnectés peut être parfaitement saine - et afficher des comportements catastrophiques. Si les sources ne transmettent pas correctement, aucune refonte ne corrigera ça. La nouvelle application héritera des mêmes symptômes.
Les règles métier sont dans le code, pas dans la tête. Une ancienne application accumule des années de décisions : cas particuliers, exceptions, comportements qui semblent absurdes mais répondent à une vraie contrainte métier. Reconstruire, c'est recréer tout ça - avec le risque d'en oublier. Ce risque est rarement évalué au moment de prendre la décision.
La culture de maintenance ne change pas avec la technologie. Si une application a été laissée à l'abandon - sans suivi, sans documentation, sans pratiques solides - rien ne garantit que la suivante sera traitée différemment. Le problème n'était peut-être pas l'application.
Ce que ça donne en pratique
Sur une mission client, j'ai rejoint un projet dont l'ancienne application Drupal était en fin de vie - maintenue en attendant que la nouvelle prenne le relais. La décision de refonte était déjà prise.
L'application avait mauvaise réputation : les factures ne s'affichaient qu'une fois sur deux, changer de page prenait deux minutes.
En parcourant le code, j'ai constaté qu'il n'y avait aucune visibilité sur ce qui se passait réellement : quand un problème survenait, il fallait plusieurs jours pour en comprendre l'origine. J'ai ajouté des logs - l'équipe est passée de 3 jours à moins d'une heure pour diagnostiquer un incident.
Ce que les logs ont révélé : l'application chargeait ses factures depuis deux partenaires externes qui ne transmettaient pas les données correctement. L'application affichait ce qu'elle recevait. Le seul reproche valide : ne pas indiquer clairement pourquoi les données étaient absentes.
Quelques mois plus tard, la nouvelle application est entrée en production. Les factures ne s'affichaient toujours qu'une fois sur deux.
Le problème n'avait jamais été dans l'application.
Avant de décider, diagnostiquer
Ce n'est pas un argument contre les refontes - parfois, repartir de zéro est la bonne décision. Mais c'est une décision qui devrait être prise après diagnostic, pas à la place de lui.
Comprendre d'où vient un problème ne prend pas des mois. Ça prend les bons outils au bon endroit : des logs, du temps passé à lire ce qui se passe vraiment, et un regard qui n'a rien à défendre dans l'existant.
Une application qu'on ne comprend pas, on ne peut pas décider en connaissance de cause de la remplacer.
