Réécrire ou réparer : comment j’ai décidé de repartir de zéro

Tout réécrire est presque toujours une mauvaise idée. Voici les critères qui m’ont pourtant conduit à le faire, et la méthode pour ne pas y laisser le produit.

La décision que tout le monde déconseille

Il existe peu de règles aussi partagées dans notre métier :

On ne réécrit jamais un logiciel de zéro.

Je la répète moi-même à mes clients.

Le code existant contient des années de corrections, de cas particuliers et de décisions oubliées. Le jeter, c’est accepter de redécouvrir chacune d’elles, une par une, en production.

Et pourtant, cette année, j’ai décidé de réécrire une plateforme que j’exploite.

Cet article explique pourquoi, et surtout comment.

Pourquoi réécrire est presque toujours une erreur

Il faut d’abord prendre la règle au sérieux.

Une réécriture échoue généralement pour trois raisons :

on sous-estime l’existant : l’ancien système fait bien plus de choses que ce dont on se souvient
on gèle le produit : pendant des mois, les utilisateurs n’obtiennent rien de nouveau
on vise une bascule unique : un grand soir où tout doit fonctionner d’un coup

La plupart du temps, le vrai motif est moins avouable : le code des autres est pénible à lire, et le sien, pas encore écrit, paraît toujours plus propre.

Ce n’est pas une raison.

Les questions que je me pose avant

Avant d’envisager une réécriture, je cherche à répondre honnêtement à quatre questions.

1. Le problème est-il dans le code ou dans le modèle ?

Un code mal écrit se répare morceau par morceau. Un modèle de données ou un découpage qui ne correspond plus au produit, beaucoup moins.

2. Les corrections se propagent-elles ?

Si chaque correctif en casse un autre, le coût de la réparation n’est plus linéaire.

3. Peut-on encore livrer ?

Quand la chaîne de build et de déploiement est devenue elle-même un risque, chaque évolution se paie deux fois.

4. Sait-on décrire précisément ce que le système doit faire ?

C’est la question décisive. Sans spécification claire, une réécriture ne produit qu’un deuxième système flou.

Mes réponses, pour Metalearn

Le problème était bien dans le modèle, pas dans le code.

L’architecture ne séparait pas suffisamment le backend de l’API dédiée à Workadventure.
Chaque modification devait donc rester compatible avec cette API, même quand elle ne concernait, par exemple, la facturation.
Il devenait presque impossible d’ajouter une fonctionnalité indépendante des autres.

Ce qui m’a fait basculer

La conséquence de tout cela tenait en une phrase : mettre en place une nouvelle fonctionnalité était devenu une question technique avant d’être une question pratique.

C’est l’inverse de ma vision de l’agilité. Ajouter une fonctionnalité doit être la réponse à un besoin, pas à sa faisabilité.

Quand on commence à écarter des idées utiles parce que le système ne les supporterait pas, ce n’est plus le produit qui décide. C’est son passif.

La décision n’a pas été prise sur une impression pour autant.

Elle a été prise le jour où j’ai pu écrire noir sur blanc ce que le nouveau système devait faire, et constater que l’ancien ne pouvait pas y arriver par étapes.

Décrire le système, pas ses bugs

Une erreur classique consiste à spécifier la nouvelle version par opposition à l’ancienne :

Comme avant, mais sans le problème X.

Cette formulation importe tous les défauts de conception de l’ancien système, en plus de ses habitudes.

J’ai préféré décrire ce que la plateforme doit faire, comme si l’ancienne n’existait pas : les acteurs, les règles, les limites, les cas d’erreur.

L’historique des bugs sert ensuite de liste de vérification. Pas de plan.

Basculer sans grand soir

C’est le point qui sépare une réécriture qui aboutit d’une réécriture qui s’enlise.

Je n’ai pas cherché à remplacer l’ancien système d’un coup.

La première étape a été, logiquement, de réécrire l’API. Avec trois exigences :

répondre aux appels de la version précédente, pour que l’existant continue de fonctionner sans modification
préparer la version suivante, sans attendre qu’elle soit terminée
devenir totalement indépendante des services associés, et centraliser les données

L’ancien et le nouveau peuvent ainsi cohabiter. La bascule se fait morceau par morceau, et chaque étape reste réversible.

Les principes que je m’impose :

développer et valider sur un environnement séparé, jamais directement en production
ne promouvoir en production que ce qui a été validé
garder l’ancien système en état de marche jusqu’à la dernière bascule

Ce que je referais, ce que j’éviterais

Ce que je referais : écrire le cahier des charges.

Quand les mises à jour deviennent chronophages, quand la question d’une fonctionnalité est essentiellement technique, et surtout quand le passif prend le dessus sur la nouveauté, écrire le cahier des charges d’une nouvelle version n’est pas une perte de temps.

Même si l’on décide finalement de ne pas réécrire, le résultat peut surprendre.

Ce que je ferais autrement : y passer plus de temps.

Je prendrais davantage de temps pour comparer cette nouvelle vision à l’existant, point par point, avant de choisir la meilleure piste.

Conclusion

La règle reste valable : dans la majorité des cas, il faut réparer.

Mais une règle n’est pas une décision. Il arrive que le système ait été conçu pour un produit qui n’existe plus, et que chaque réparation prolonge un malentendu.

Dans ce cas, la question utile n’est pas :

« Peut-on tout réécrire ? »

Mais plutôt :

« Sait-on décrire ce qu’on veut, et peut-on y arriver sans jamais éteindre l’existant ? »

Si la réponse est oui aux deux, la réécriture cesse d’être un pari. Elle devient un projet comme un autre.