Une migration de React vers Vite tourne mal dès qu’elle devient un redesign. La variante la plus sûre remplace la fondation de build et de développement sous une application et garde son comportement visible exactement identique. Des builds locaux plus rapides valent beaucoup, mais seulement si la production reste banale tout du long.
Quand le problème apparaît
Le frontend annonce généralement son obsolescence lui-même. Le serveur de dev met du temps à démarrer et à recharger. L’outil de build est sur un chemin ancien et lent, comme un setup Webpack legacy ou Create React App qui ne reçoit plus guère d’attention. La mise à niveau d’une seule dépendance cascade en changements de configuration que personne ne veut assumer. Les nouvelles recrues perdent une journée à configurer leur environnement. L’application fonctionne encore, mais chaque interaction avec le build ralentit l’équipe, et cette taxe s’accumule.
Modes de défaillance courants
Mélanger migration et redesign. Changer le build et refactorer des composants en même temps rend les régressions impossibles à attribuer. Quand quelque chose casse, on ne peut pas dire si c’est le nouveau build ou le nouveau code.
Sous-estimer les hypothèses de build. Variables d’environnement, chemins d’assets, outillage de test, configuration TypeScript, comportement du proxy, cible de déploiement et commandes CI : c’est là que vivent réellement les surprises de migration. On les oublie facilement, précisément parce qu’elles sont implicites.
Sauter la passe de compatibilité. Routing, formulaires, authentification, écrans admin, analytics, feature flags et assets statiques se comportent souvent de façon subtilement différente après un changement de build. Sans vérification consciente, les différences partent vers les utilisateurs.
Faire confiance au succès local. Un build local rapide qui n’est pas passé par le vrai chemin de déploiement prouve peu de chose. Les erreurs intéressantes apparaissent en CI et dans les previews de production.
Une approche contrôlée
Listez d’abord les hypothèses de build
Avant de changer quoi que ce soit, notez les variables d’environnement, les chemins d’assets, l’outillage de test, les réglages TypeScript, les règles de proxy, la cible de déploiement et les commandes CI. Cette liste est la vraie surface de la migration, et la rendre explicite supprime la plupart des surprises.
Déplacez le build, gelez le comportement
Remplacez d’abord la fondation de build et gardez le comportement visible stable. Résistez au refactoring tant que le build est en mouvement. Une fois seulement que l’application tourne sur la nouvelle fondation, nettoyez les anciens patterns, comme une étape séparée et relisable.
Faites une passe de compatibilité consciente
Parcourez routing, formulaires, authentification, écrans admin, analytics, feature flags, assets statiques et previews de déploiement. Traitez chacun comme un point de checklist, pas comme une hypothèse. C’est ici qu’une migration mérite le mot sûr.
Vérifiez via le vrai pipeline
Confirmez que le build se comporte en CI et dans une preview proche de la production, pas seulement sur une machine de développeur. Le chemin de déploiement fait partie de la migration, pas d’une réflexion après coup.
Checklist opérationnelle
- Les hypothèses de build sont notées avant le début de la migration.
- Le build est migré séparément de tout refactor de composant.
- Routing, auth, formulaires et écrans admin sont vérifiés après le changement.
- Les variables d’environnement et les chemins d’assets se résolvent à l’identique en production.
- Les commandes CI et les previews de déploiement passent sur le nouveau build.
- Le comportement visible est inchangé quand la migration est déclarée terminée.
Un chemin sûr
Migrez le build via votre processus de release normal, gardez le diff concentré sur l’outillage plutôt que sur les fonctionnalités, et livrez quand la passe de compatibilité et la CI s’accordent à dire que rien n’a changé côté utilisateur. La récompense est un frontend plus facile à exploiter, tester et faire évoluer, obtenu sans forcer l’équipe dans un rewrite complet.
Ce travail fait partie de la modernisation et du rescue d’infrastructure et accompagne la checklist de modernisation Rails quand le backend porte sa propre dette. Il s’inscrit dans nos services plus larges, et la page proof cadre la même livraison soignée et incrémentale. Si un frontend lent ou fragile bloque votre équipe, écrivez-nous ce qui casse.