Moderniser ou réécrire une application existante ?

Une application ancienne devient difficile à faire évoluer, et la tentation est nette : tout reprendre. Le code « ne se comprend plus », les déploiements font peur, une personne concentre la connaissance. Une réécriture promet un système propre. Elle promet aussi plusieurs mois sans valeur visible, puis une bascule où l’ancien et le nouveau doivent dire la même chose sur les données. Ce second point est en général le vrai sujet.

Avant de choisir, il faut nommer ce qui coince. Pas le ressenti. Le coût de la prochaine évolution, le risque d’un changement, et ce que le métier perd s’il ne change rien.

Pourquoi les anciennes applications deviennent difficiles à faire évoluer

L’âge du code n’explique pas tout. Une base ancienne, bien comprise, avec des tests sur les règles qui comptent, se modifie encore. Ce qui grippe, c’est l’accumulation de décisions jamais écrites.

Le déploiement est manuel et personne n’ose y toucher un vendredi. La logique métier est répartie entre l’écran, un batch et un trigger. Il n’y a pas de moyen fiable de savoir si un changement a cassé un cas rare. L’environnement de développement ne ressemble plus à la production. Les dépendances ne se mettent plus à jour sans effet de bord.

À cela s’ajoute la connaissance. Si une seule personne sait pourquoi un calcul est ainsi, chaque évolution attend son calendrier. Le logiciel n’est pas seulement dur à modifier. Il est dur à confier.

Les signes qu’une modernisation devient nécessaire

Quelques signaux reviennent, et ils se combinent :

• un changement petit demande un délai disproportionné, de façon répétée ;
• les corrections créent des régressions sur des parcours que personne n’avait en tête ;
• on refuse des demandes métier parce que « le système ne sait pas faire », alors que la demande est légitime ;
• les contournements — exports, doubles saisies, scripts locaux — portent désormais une partie du processus ;
• la mise en production est un événement, pas une routine ;
• la version du socle (runtime, base, système) n’est plus tenue, et le correctif de sécurité attend pour cette raison.

Un seul de ces signes ne justifie pas un projet. Plusieurs, sur un outil qui porte une activité critique, justifient au moins de comparer les options. Le cas est développé du point de vue du problème dans moderniser un logiciel métier.

Option 1 : maintenir encore

Maintenir est une décision, pas un échec. Elle est rationnelle quand le logiciel fait encore le travail, que les évolutions demandées sont rares, et que le risque d’y toucher est plus élevé que le coût de continuer ainsi.

Elle cesse de l’être quand « on ne touche plus » devient la politique par défaut, y compris pour une faille ou pour une obligation métier. Maintenir suppose encore un minimum : savoir déployer, savoir qui est responsable, avoir une copie exploitable des données, et ne pas dépendre d’une machine que personne ne saurait reconstruire.

Si ces conditions tiennent, le bon geste peut être de documenter les quelques parcours critiques et de remettre un pipeline de déploiement, sans ouvrir un chantier de réécriture.

Option 2 : moderniser progressivement

Moderniser, ici, veut dire changer le système par zones tout en le laissant servir le métier. Le motif utile est l’étranglement : le nouveau parcours prend la place de l’ancien pour un cas précis, l’ancien continue pour le reste, et la frontière est explicite.

Concrètement, cela passe par quelques leviers, pas par un relooking :

• isoler un domaine — un type de dossier, un calcul, une intégration — derrière une interface stable ;
• arrêter d’ajouter des règles dans la zone qu’on a décidé de quitter ;
• couvrir cette zone par des tests sur les cas qui font mal, avant de la déplacer ;
• rendre le déploiement reproductible, souvent avec l’aide du cloud et de l’exploitation, pour que chaque pas soit réversible ;
• remplacer quand la nouvelle zone tient en conditions réelles, pas quand elle est « finie » sur un environnement de démo.

Le rythme est moins spectaculaire qu’une refonte. Il a l’avantage de livrer un parcours utile avant la fin du chantier, et de garder l’ancien comme filet tant que les chiffres ne concordent pas.

Option 3 : réécrire

La réécriture se justifie quand les contraintes de fond rendent le reste trop cher. Le modèle de données ne peut pas porter les cas réels sans contorsion permanente. Le socle n’a plus de chemin de mise à jour. L’application mélange tellement les responsabilités qu’isoler une zone coûte autant que la reconstruire. Ou le métier a changé de nature, et l’outil encode une organisation qui n’existe plus.

Encore faut-il réécrire le bon système. Reprendre écran par écran fige les contournements dans le neuf. Le travail préalable est le même que pour un logiciel nouveau : rôles, décisions, exceptions, données qui font foi. Cadrer et architecturer avant de rouvrir un dépôt évite de reconstruire l’ancien problème avec une syntaxe plus récente.

Une réécriture a aussi un coût d’attention. Pendant qu’elle avance, l’ancien doit continuer à vivre. Si l’équipe ne peut pas faire les deux, le planning est faux, quelle que soit la qualité de la cible.

Option 4 : remplacer par une solution existante

Parfois le spécifique ne paie plus. Le processus est devenu standard, les écarts locaux sont des habitudes plus que des avantages, et un outil du marché couvre le besoin à un coût inférieur — licence, intégration et conduite comprises.

Le critère n’est pas « est-ce qu’un logiciel existe ». C’est « est-ce que nos écarts valent encore le coût de les porter ». S’ils ne le valent pas, le projet change de nature : paramétrage, reprise de données, interfaces avec ce qu’on garde, et abandon assumé de quelques particularités.

S’ils le valent, un outil générique finit souvent par être contourné, et l’on se retrouve avec un spécifique informel autour d’un standard. Autant le savoir avant de signer.

Le vrai sujet : les données

Les utilisateurs jugent le nouveau système à une question simple : est-ce que mes dossiers y sont, et sont-ils justes ?

La migration n’est pas un script de fin de projet. C’est une contrainte de conception. Quelles entités bougent ? Quel historique doit rester consultable, et lequel peut rester en archive ? Quelles clés permettent de réconcilier ancien et nouveau ? Quelle qualité a la donnée aujourd’hui — doublons, statuts incohérents, champs utilisés pour autre chose que leur nom ?

Un plan honnête prévoit un écart. On compare des comptes, des stocks, des dossiers ouverts, pas seulement le nombre de lignes. On décide à l’avance quel écart est acceptable le jour de la bascule, et qui a le droit de corriger ensuite.

Sans cette comparaison, la réécriture la plus propre échoue au moment où elle rencontre le métier. Le code neuf n’a pas de mémoire. Les données, si.

Éviter le « big bang »

Tout couper un vendredi soir suppose que le nouveau système est complet, que les données sont justes, que les interfaces tierces ont suivi, et que les équipes savent travailler dedans le lundi. Ces conditions sont rarement vraies en même temps.

La coexistence est plus lente à expliquer et plus sûre à vivre. L’ancien reste la référence pour les parcours non migrés. Le nouveau prend un flux, avec un moyen clair de savoir où en est un dossier. On prévoit le retour arrière d’une zone sans revenir sur tout le projet. On ne demande pas aux gens de saisir deux fois, sauf pendant une fenêtre courte et mesurée.

Le big bang reste parfois inévitable, par exemple quand une interface partenaire ne tolère qu’un seul système. Dans ce cas, il se prépare comme un exercice : répétition sur une copie, critères d’arrêt, rôle de chacun le jour même. Ce n’est plus une espérance, c’est une opération.

Comment choisir ?

La grille ci-dessous ne donne pas un score. Elle force les critères qui changent réellement la décision.

Critère	Question utile
Criticité	Un arrêt de quelques heures est-il absorbable, ou le flux s’arrête-t-il avec l’outil ?
Dette	Le coût de la prochaine évolution est-il encore lisible, ou chaque demande est-elle une découverte ?
Connaissance	Quelqu’un sait-il encore pourquoi les règles sont ainsi, et peut-il l’écrire ?
Dépendances	Quels systèmes et quels partenaires cassent si le contrat de données change ?
Valeur du spécifique	Ce qui nous distingue tient-il dans cet outil, ou dans la façon de travailler autour ?
Horizon	Dans trois ans, ce processus existera-t-il encore sous cette forme ?

Si la criticité est haute et la connaissance faible, on commence par rendre le système déployable et observable, avant d’en remplacer le cœur. Si la valeur du spécifique est basse, on regarde le remplacement par un outil existant avant d’écrire du code. Si les données sont sales, aucun scénario ne saute cette étape.

Développer le remplacement ou la zone neuve vient après ce tri. La meilleure décision n’est pas celle qui produit le plus de code nouveau. C’est celle qui rend la prochaine évolution ordinaire, sans perdre l’historique sur lequel le métier s’appuie.