La réécriture coûtera trois fois le budget que vous avez approuvé
L'affirmation L'estimation d'une réécriture complète découle des fonctionnalités que vous voyez. Le coût, lui, est porté par celles que vous ne voyez pas : onze années de cas limit...
L'affirmation
L'estimation d'une réécriture complète découle des fonctionnalités que vous voyez. Le coût, lui, est porté par celles que vous ne voyez pas : onze années de cas limites, d'exceptions et de contournements discrets enfouis dans un système que personne n'a lu d'un bout à l'autre. Cet écart explique que les réécritures atterrissent couramment à deux ou quatre fois le budget approuvé, et que la version livrée soit fréquemment moins bonne que celle qu'elle remplace.
Pourquoi l'estimation est structurellement fausse
Estimer une réécriture, c'est estimer un devis qui n'existe pas. Le comportement de votre système actuel n'est écrit nulle part : il est encodé dans du code ayant absorbé dix ans de décisions. L'exonération de taxe pour une catégorie de clients. La numérotation des factures exigée par un vérificateur en 2018. Le dépôt de fichier nocturne vers le vieux serveur FTP d'un fournisseur, dont personne ne parle parce qu'il fonctionne depuis des années et que son auteur est parti en 2021.
Rien de tout cela n'apparaît à l'atelier d'exigences, puisque personne dans la salle n'en connaît l'existence. Tout cela apparaît à la neuvième semaine, un élément à la fois, chacun sous la forme d'un petit changement qui s'avère porteur.
Il existe un second coût, plus dur : pendant la réécriture, l'ancien système continue d'exiger de l'entretien. Vous payez deux équipes — ou une équipe divisée — et le nouveau système ne produit aucune valeur avant la bascule. Une réécriture de douze mois, ce sont douze mois sans la moindre amélioration visible pour vos clients.
L'arithmétique à coucher sur papier
| Poste | Réécriture | Remplacement graduel |
|---|---|---|
| Estimation approuvée | 220 000 $ | 220 000 $ |
| Résultat réaliste | 440 000 $ à 660 000 $ | 240 000 $ à 300 000 $ |
| Délai avant bénéfice client | 10 à 18 mois | 4 à 8 semaines |
| Coût d'un arrêt à mi-chemin | Perte totale | On garde le livré |
| Entretien du legs pendant les travaux | Complet, en parallèle | Décroissant |
La ligne qui devrait trancher la réunion est la quatrième. Les priorités changent, une personne clé part, une urgence client dévore un trimestre. Sous une réécriture, des travaux arrêtés au huitième mois ne produisent rien du tout. Sous un remplacement graduel, tout ce qui a été livré est déjà en production et rapporte déjà.
À quoi ressemble un remplacement graduel
Placez une couche de routage devant l'application existante. Chaque requête va par défaut vers l'ancien système ; vous déplacez une route à la fois vers du nouveau code, derrière les mêmes adresses.
location /rapports/ { proxy_pass http://new_service; }
location / { proxy_pass http://legacy_app; }- Commencez par une zone en lecture seule et très visible. Les rapports, la recherche ou le catalogue public. Sans écriture, aucun problème de cohérence de données pendant que vous apprenez le domaine.
- Déplacez les écritures une entité à la fois, le nouveau service devenant propriétaire de la table et l'ancien la lisant via une interface ou une vue.
- Supprimez immédiatement l'ancien chemin de code une fois le trafic déplacé et une semaine écoulée. Sans suppression, vous entretenez deux implémentations pour toujours, ce qui est le mode d'échec de cette approche.
- Gardez une seule base de données tant que c'est supportable. Scinder le stockage est la partie coûteuse ; reportez-la jusqu'à ce qu'un problème précis l'impose.
Les tests de caractérisation d'abord
Avant de déplacer la moindre route, écrivez des tests qui capturent ce que le système actuel fait — et non ce que le devis prétend qu'il devrait faire. Passez une centaine d'entrées historiques réelles dans l'ancien chemin de code, enregistrez les sorties et vérifiez-les. Là où le comportement est erroné, le test documente l'erreur, et quelqu'un peut ensuite décider sciemment de la conserver ou de la corriger. C'est l'étape qui transforme un comportement non documenté en quelque chose de remplaçable sans danger, et c'est la semaine la plus rentable de tout le mandat.
Quand la réécriture est réellement le bon choix
Trois cas la justifient. La plateforme est en fin de vie et ne reçoit plus de correctifs, sans chemin de mise à niveau pris en charge. Le système est assez petit pour qu'une reconstruction complète tienne en six semaines, auquel cas la coordination du graduel n'en vaut pas la peine. Ou les règles d'affaires elles-mêmes changent : vous ne reconstruisez pas l'existant, vous bâtissez autre chose, et l'ancien comportement n'est explicitement pas la cible.
La question à poser en réunion
Demandez à l'équipe qui propose la réécriture de nommer les trois comportements les plus surprenants du système actuel. Si elle y arrive, elle a lu le code et son estimation mérite du poids. Si la réponse est que le système actuel est un fouillis et que personne ne sait vraiment ce qu'il fait, ce n'est pas un argument pour le réécrire. C'est une description du risque que vous vous apprêtez à financer.
