Dette technique : quand faut-il réécrire, et quand faut-il réparer
La réécriture complète est la décision la plus coûteuse d'un projet, et souvent la plus mal instruite. Trois questions permettent de trancher avant de s'engager.
Publié par L'équipe Noyau Digital
« On repart de zéro. » Cette phrase, prononcée en réunion, coûte en moyenne dix-huit mois et fait courir un risque considérable au produit. Elle est parfois la bonne décision. Le plus souvent, elle traduit une lassitude plutôt qu'un diagnostic.
Le problème est-il dans le code, ou dans la connaissance du code ?
Une base de code jugée « illisible » l'est fréquemment parce que les personnes qui l'ont écrite sont parties. Le code n'a pas changé ; la connaissance, si.
Avant d'envisager quoi que ce soit, nous passons deux à trois semaines à documenter l'existant et à écrire des tests de caractérisation — des tests qui décrivent ce que le système fait, sans juger ce qu'il devrait faire. Dans un cas sur trois, cette phase suffit à faire disparaître l'envie de réécrire.
La douleur est-elle diffuse ou localisée ?
C'est le critère le plus discriminant.
- Douleur localisée — un module précis concentre les incidents, les délais et les peurs. Il faut le remplacer, lui seul, derrière une interface stable. C'est un chantier de quelques mois, réversible.
- Douleur diffuse — chaque évolution, où qu'elle porte, casse quelque chose ailleurs. Le couplage est structurel. C'est le seul cas où une réécriture se défend vraiment.
Dans le doute, c'est que la douleur est localisée.
Peut-on se permettre deux ans sans nouvelle fonctionnalité ?
Une réécriture complète gèle l'évolution du produit pendant toute sa durée, puisque l'équipe doit rattraper l'existant avant d'ajouter quoi que ce soit. Pendant ce temps, vos concurrents avancent.
Un système imparfait qui évolue vaut mieux qu'un système parfait qui arrive trop tard.
Quand la réponse est non — et elle est presque toujours non — la stratégie du remplacement progressif s'impose : on encapsule l'ancien système, on détourne le trafic fonctionnalité par fonctionnalité, on éteint les morceaux devenus inutiles. C'est moins spectaculaire, et beaucoup plus sûr.
Notre position
Nous acceptons les missions de réécriture complète, mais nous commençons toujours par tenter de démontrer qu'elles sont évitables. Quand le client repart avec un plan de remplacement progressif et un budget divisé par trois, la mission a rempli son objet.