Le biais qui fausse presque toutes ces décisions
Tout développeur qui découvre le code de quelqu'un d'autre le trouve mauvais. C'est un fait de métier, pas un jugement : on ne voit pas les contraintes qui ont produit ces choix, on ne connaît pas les urgences ni les arbitrages, et la lecture d'un code inconnu est laborieuse alors que l'écriture d'un code neuf est agréable.
Ce biais produit une recommandation quasi automatique : « il faut tout refaire ». Elle est sincère, et elle est souvent coûteuse. La refonte se vend d'autant mieux qu'elle est plus chère et plus longue que la reprise.
La bonne méthode consiste donc à exiger des critères objectifs avant d'accepter cette conclusion.
Ce que coûte réellement une refonte
Une refonte ne coûte pas le prix du développement neuf. Elle coûte ce prix, plus trois postes qui n'apparaissent jamais dans le devis initial.
Le premier est la découverte des règles métier implicites. Une application en production depuis dix ans contient des centaines de comportements dont personne ne se souvient, chacun ajouté pour une raison valable. Ils ne sont documentés nulle part ailleurs que dans le code, et leur absence dans la nouvelle version se découvre en production, une par une, sous forme de réclamations.
Le deuxième est le double run. Pendant la refonte, l'ancien système doit continuer de fonctionner et souvent d'évoluer. Vous financez deux systèmes, ou vous gelez les évolutions pendant un an. Aucune des deux options n'est confortable.
Le troisième est la reprise de données. Migrer des données produites par un modèle ancien vers un modèle neuf est un projet en soi, et c'est régulièrement lui qui décale la mise en service.
Les cinq signaux qui justifient une refonte
Il en existe, et il faut les nommer, sinon la reprise devient un dogme aussi coûteux que la refonte systématique.
La technologie n'est plus maintenue. Un langage ou un framework sans correctif de sécurité expose à un risque qu'aucune couche de protection ne compense durablement. Ce signal se traite sans discussion.
Le modèle de données bloque le métier. Si l'évolution attendue implique de repenser les entités centrales, la refonte devient l'option raisonnable, parce que tout le reste en dépend.
Le coût des corrections dépasse celui du neuf. Quand une modification de trois jours en génère cinq de régressions, l'application coûte plus cher à maintenir qu'à remplacer. Cet indicateur se mesure, il ne se ressent pas.
Plus personne ne maîtrise le système. Un logiciel dont l'unique connaisseur est parti et qui n'a ni documentation ni tests est un actif à risque, même s'il tourne correctement aujourd'hui.
Le métier a changé. Si l'application répond à une organisation qui n'existe plus, la remettre en état revient à réparer soigneusement le mauvais objet.
La reprise, et ce qu'elle demande vraiment
Reprendre du code existant n'est pas s'en accommoder. C'est une démarche en trois temps qui se pilote.
D'abord, un état des lieux : cartographie des modules, mesure de la couverture de tests, inventaire des dépendances obsolètes, relevé des failles de sécurité connues. Quelques semaines suffisent, et cette étape produit la seule information capable de trancher entre les deux options.
Ensuite, la sécurisation : ajouter des tests automatisés sur les parcours critiques, mettre à jour les dépendances dangereuses, remettre en place un environnement de déploiement fiable. À ce stade, l'application n'a pas changé pour l'utilisateur, mais elle est redevenue modifiable.
Enfin, la modernisation par modules : chaque partie problématique est réécrite quand une évolution la concerne, pas avant. Le bénéfice est immédiat et le budget se pilote lot par lot.
La troisième voie : la refonte progressive
Entre les deux, il existe un chemin qui permet de refondre sans arrêter le service. On isole un domaine fonctionnel, on le réécrit dans la nouvelle architecture, on le branche à l'ancien système, puis on passe au suivant.
L'ancien système se vide progressivement de sa substance jusqu'à pouvoir être éteint. Cette approche demande plus de rigueur qu'une refonte en bloc, notamment sur la synchronisation des données entre les deux mondes, mais elle supprime l'effet tunnel et rend le chantier arrêtable à tout moment.
C'est l'approche que nous recommandons dans la grande majorité des dossiers de reprise, parce qu'elle protège la seule chose qui compte pendant les travaux : la continuité du service rendu aux utilisateurs.
La question à poser avant de décider
Une seule, et elle est redoutable : que se passe-t-il si le projet s'arrête au bout de six mois ?
Avec une reprise ou une refonte progressive, vous avez livré des améliorations utilisées en production. Avec une refonte en bloc, vous avez un système inachevé, un ancien système à bout de souffle, et rien à montrer. Cette asymétrie suffit le plus souvent à trancher.
