Une application qui fonctionne mais que personne n’ose modifier n’est pas un actif : c’est une dette dont les intérêts se paient en délais. Chaque évolution demandée reçoit la même réponse — « c’est compliqué » — et le coût annoncé finit par dépasser celui d’un développement neuf.
La question posée est presque toujours la même : faut-il tout refaire ?
Ce qu’il faut mesurer avant de décider
Décider sans inventaire, c’est parier. Nous commençons donc par trois relevés.
Le code. Volume, dépendances et leur état de maintenance, version du langage, présence de tests, couplage entre les parties. Une application de 40 000 lignes sans test n’est pas comparable à une application de 200 000 lignes couverte à 60 %.
Les données. Souvent le vrai sujet. Un schéma sans contraintes d’intégrité, avec des colonnes qui contiennent trois formats différents selon l’année, coûte plus cher à reprendre que le code lui-même.
Les usages réels. Les journaux du serveur disent quelles fonctionnalités sont utilisées, par combien de personnes et à quelle fréquence. Il est fréquent d’y découvrir qu’un tiers des écrans n’a pas servi depuis deux ans. Ce tiers-là n’a pas à être migré, et cette découverte change souvent la décision à elle seule. C’est le premier livrable de notre audit technique.
Les trois voies
Stabiliser sans changer de socle
Mise à jour du langage et des dépendances, ajout de tests sur les parcours critiques, correction des failles connues. On ne touche pas à l’architecture.
C’est la voie la moins spectaculaire et la plus rentable quand l’application répond encore au besoin métier. Elle rend l’évolution possible sans engager de refonte.
Remplacer par morceaux
L’ancienne et la nouvelle application cohabitent derrière la même adresse. Un module à la fois est réécrit, et le routage bascule les URL correspondantes une fois le remplacement vérifié.
C’est la voie que nous recommandons le plus souvent pour une reprise d’application : chaque étape livre quelque chose d’utilisable, et chaque étape est réversible. Elle demande en contrepartie de faire fonctionner deux systèmes en parallèle, avec une authentification et des données partagées — c’est là que se situe la difficulté réelle.
Réécrire entièrement
Parfois inévitable : socle qui n’a plus de correctifs de sécurité, langage sans compétences disponibles sur le marché, modèle de données incompatible avec le besoin actuel.
C’est la voie la plus risquée, et la raison est rarement technique. Une application ancienne encode des années de règles métier que personne n’a écrites ailleurs. La réécriture les redécouvre une par une, en production, par les réclamations des utilisateurs.
Ce qui décide vraiment
Trois questions tranchent la plupart des situations.
L’application répond-elle encore au besoin ? Si oui, stabiliser. Une architecture démodée qui fait le travail vaut mieux qu’une architecture moderne qui ne le fait pas encore.
Y a-t-il une contrainte de sécurité ? Un socle sans correctifs n’est pas une préférence esthétique, c’est une exposition. Elle impose un calendrier.
L’équipe peut-elle absorber deux systèmes ? Le remplacement progressif suppose d’exploiter l’ancien et le nouveau en même temps, parfois pendant un an. Sans cette capacité, il vaut mieux stabiliser et attendre.
Ce que nous refusons
Un forfait de migration annoncé avant l’inventaire. Un chiffrage donné sur la seule description de l’existant, sans avoir lu le code, est un chiffre inventé — et l’écart se règle plus tard, en avenants ou en compromis sur la qualité.
