On modernise un frontend quand la vitesse de livraison s'effondre de manière prévisible : évolutions lentes, effets de bord, recrutements bloqués. On ne réécrit que si le socle est irrécupérable ou si le domaine métier a changé — et jamais d'un coup.
La fausse question
« Faut-il tout réécrire ? » est presque toujours la mauvaise question. La vraie est : quel gain mesurable attend-on, et quel risque accepte-t-on ?
Les signaux d'une modernisation à mener
- Les évolutions demandées par le métier prennent des semaines au lieu de jours.
- Chaque ajout crée un effet de bord imprévu ailleurs.
- Les nouvelles recrues mettent des mois à être autonomes.
- Le bundle grossit plus vite que les fonctionnalités.
- La stack bloque les recrutements (framework mort, versions EOL).
Si trois de ces signaux sont présents, la dette ne coûte plus : elle détruit de la vitesse de manière prévisible.
Quand la réécriture se justifie quand même
Rarement, mais parfois :
- Le socle technologique est irrécupérable (plus de support de sécurité).
- Le domaine métier a tellement changé que le modèle de données ment sur l'activité réelle.
- Le coût de la migration progressive dépasse celui d'une reconstruction cadrée — calculé honnêtement, avec les opérations incluses.
La méthode qui évite les deux pièges
- Mesurer avant : temps de livraison des features, incidents, couverture de tests, taille du bundle.
- Isoler les zones : la dette est rarement homogène. Les zones stables ne se touchent pas ; les zones chaudes se modernisent en premier.
- Strangler fig : remplacer module par module, derrière une façade stable, en livrant en continu. Jamais de « big bang » derrière un rideau.
- Garder les tests : une réécriture sans filet de non-régression est un pari, pas une décision d'ingénierie.
Le critère final
Une modernisation réussie ne se voit pas au lancement : elle se voit trois mois plus tard, quand l'équipe livre de nouveau des évolutions en quelques jours.