Réécrire ou moderniser ? Ma grille pour décider face à un vieux logiciel

« Le code est illisible, personne n’ose y toucher, il faudrait tout refaire. » C’est souvent la première phrase que j’entends quand on me présente une application métier qui a dix ans. Et c’est compréhensible.

Pourtant, la réécriture complète est l’un des projets les plus risqués en informatique. Pendant des mois, on dépense de l’argent pour reconstruire quelque chose qui existe déjà, sans rien livrer de nouveau aux utilisateurs.

Les quatre questions que je pose

Avant de trancher, je passe quelques jours dans le code et avec les utilisateurs pour répondre à ces questions.

1. Le logiciel fait-il encore ce qu’on attend de lui ?

Si l’application rend service au quotidien, elle contient des années de règles métier, souvent non documentées. Chaque cas particulier bizarre dans le code correspond probablement à un vrai problème rencontré un jour. Les réécrire, c’est prendre le risque de les oublier.

2. Qu’est-ce qui fait vraiment mal ?

« Tout » n’est pas une réponse. En général, la douleur se concentre sur quelques zones : un module de facturation fragile, un import de fichiers qui plante, des pages trop lentes. Les identifier permet de cibler l’effort.

3. La technologie est-elle encore maintenue ?

Un framework abandonné ou une version de langage qui ne reçoit plus de correctifs de sécurité change la donne. Dans ce cas, une migration devient nécessaire, mais elle peut souvent se faire progressivement.

4. Peut-on tester le comportement actuel ?

Sans tests, toute modification est un pari. Écrire des tests de caractérisation, qui figent le comportement existant, est presque toujours ma première action concrète.

La voie du milieu : moderniser par morceaux

Dans la grande majorité des cas, je recommande une modernisation progressive, sur le modèle de la figure de l’étrangleur : on construit les nouvelles parties à côté de l’ancien système, on redirige le trafic morceau par morceau, et l’ancien code disparaît petit à petit.

// Exemple : un routeur qui bascule progressivement vers le nouveau module
export function handleInvoice(request: InvoiceRequest) {
	if (featureFlags.newBilling && request.customer.migrated) {
		return newBilling.createInvoice(request);
	}
	return legacyBilling.createInvoice(request);
}

Chaque étape apporte une amélioration visible, le risque reste maîtrisé, et on peut s’arrêter à tout moment avec un système qui fonctionne.

Quand la réécriture a du sens

Il y a des exceptions : une application très petite, un besoin métier qui a complètement changé, ou une technologie devenue impossible à faire tourner. Dans ces cas, repartir de zéro peut être raisonnable, à condition de garder l’ancien système comme référence jusqu’au bout.

Vous hésitez sur l’avenir d’une de vos applications ? Un audit de quelques jours suffit souvent à y voir clair. Contactez-moi.