Refondre un site legacy sans tout casser

Refondre un site legacy est rarement un sujet purement technique. Dans la vraie vie, il faut préserver le chiffre d’affaires, éviter les régressions SEO, maintenir la production et composer avec une base de code parfois vieille de 5, 10 ou 15 ans. Pour beaucoup d’équipes, le principal risque n’est pas de garder un existant imparfait : c’est de vouloir tout réécrire d’un coup. La stratégie la plus réaliste consiste souvent à moderniser progressivement, avec des étapes courtes, mesurables et réversibles.

Sur le terrain, les refontes “big bang” échouent plus souvent qu’on ne l’admet. Le Standish Group CHAOS Report, souvent cité dans l’industrie, rappelle depuis des années que les projets les plus ambitieux sont aussi les plus exposés aux retards, aux dépassements budgétaires et aux résultats partiels. Dans le web, cela se traduit par des migrations bloquées, des fonctionnalités perdues, des performances dégradées ou des tunnels de conversion cassés. À l’inverse, une refonte progressive permet de réduire le risque en gardant le site en production pendant la transformation.

Commencer par cartographier l’existant

Avant de toucher au code, il faut comprendre ce que fait réellement le site. La documentation est souvent incomplète ou obsolète. Le meilleur point de départ reste une cartographie simple :

les pages les plus visitées via Google Analytics 4, Matomo ou les logs serveur ;
les parcours critiques : inscription, paiement, génération de leads, espace client ;
les dépendances techniques : framework, CMS, version de PHP ou Node.js, base de données, APIs tierces ;
les irritants récurrents : temps de chargement, erreurs 500, dette CSS, tests absents, déploiement manuel ;
les contraintes business : saisonnalité, campagnes marketing, obligations légales, SLA.

Une règle utile : distinguer ce qui est visible de ce qui est critique. Une page peu élégante mais stable peut attendre. En revanche, un module de paiement sur une version obsolète de bibliothèque ou un back-office impossible à déployer doit remonter en priorité.

Dans un audit réel, il n’est pas rare de découvrir qu’environ 20 % des pages génèrent 80 % du trafic, selon une logique proche de la loi de Pareto. Cela change complètement l’ordre des priorités. On ne refond pas “le site”, on sécurise d’abord les zones à fort impact.

Mesurer avant de refaire

Une refonte sans métriques de départ est une prise de risque inutile. Il faut établir un état initial sur quatre axes :

performance : Core Web Vitals, poids des pages, temps serveur ;
qualité : taux d’erreurs, couverture de tests, bugs ouverts ;
SEO : trafic organique, pages indexées, positions, profondeur de crawl ;
business : conversion, panier moyen, leads, rétention.

Pour la performance, des outils comme PageSpeed Insights, Lighthouse, WebPageTest ou SpeedCurve donnent rapidement une base chiffrée. Google considère par exemple qu’un bon LCP doit rester sous 2,5 secondes, un bon INP sous 200 ms et un CLS sous 0,1. Si votre site legacy est à 4,8 secondes de LCP sur mobile, la marge de progression est concrète et mesurable.

Pour le SEO, Google Search Console, Screaming Frog et Ahrefs ou Semrush permettent d’identifier les pages qui performent, celles qui cannibalisent, les redirections douteuses et les erreurs d’indexation. Une refonte progressive bien menée peut améliorer la technique sans casser les URL stratégiques.

Éviter la réécriture complète par défaut

Réécrire entièrement un site semble séduisant : on repart proprement, on choisit une stack moderne, on efface la dette. En pratique, on perd aussi une quantité énorme de connaissance implicite : règles métier oubliées, cas limites, dépendances non documentées, comportements attendus par les utilisateurs. C’est pour cela que la stratégie la plus prudente consiste à extraire, encapsuler, remplacer plutôt qu’à tout jeter.

Un bon modèle mental est celui du strangler pattern, popularisé par Martin Fowler : on entoure progressivement l’ancien système par de nouveaux composants, jusqu’à ce que l’existant soit remplacé morceau par morceau. Cette approche est particulièrement adaptée aux sites e-commerce, aux portails éditoriaux et aux plateformes B2B qui ne peuvent pas se permettre une interruption longue.

Exemple concret : un site en PHP 5.6 avec un front mêlant jQuery, templates serveur et scripts inline. Plutôt que de migrer d’un coup vers une SPA complète, on peut :

mettre à jour l’infrastructure et la version de PHP vers une version supportée ;
introduire un système de build moderne avec Vite ;
isoler certains composants interactifs en Vue ou React uniquement là où c’est utile ;
conserver le rendu serveur pour les pages SEO ;
extraire progressivement la logique métier vers des services testables.

Cette stratégie produit des gains visibles sans imposer une bascule brutale du jour au lendemain.

Découper la refonte en chantiers à faible risque

Une modernisation progressive fonctionne mieux quand elle est découpée en lots autonomes. Un découpage fréquent ressemble à ceci :

chantier 1 : observabilité — logs centralisés, monitoring, alertes ;
chantier 2 : chaîne de déploiement — CI/CD, environnements de préproduction, rollback ;
chantier 3 : performance front — images, cache, JavaScript, CSS ;
chantier 4 : composants critiques — recherche, panier, formulaire, compte utilisateur ;
chantier 5 : rationalisation du design system — UI cohérente, dette CSS réduite ;
chantier 6 : migration progressive du socle — framework, templates, APIs.

Le point clé est de livrer de la valeur à chaque étape. Par exemple, la simple mise en place d’un CDN comme Cloudflare, d’un meilleur cache HTTP et d’une optimisation d’images via ImageMagick ou un service comme Imgix peut réduire fortement le poids des pages sans toucher au cœur métier.

Sur de nombreux sites médias ou e-commerce, les images représentent encore plus de 50 % du poids total d’une page. Convertir les visuels en WebP ou AVIF, activer le lazy loading natif et servir des tailles adaptées peut faire gagner plusieurs centaines de kilo-octets par page. Ce sont des optimisations sobres, peu risquées et immédiatement utiles.

Sécuriser avec des garde-fous techniques

Le principal frein à une refonte progressive est la peur de casser l’existant. Cette peur est saine : elle pousse à mettre en place des garde-fous. Les plus utiles sont souvent les plus pragmatiques :

tests de non-régression sur les parcours critiques avec Cypress ou Playwright ;
feature flags avec LaunchDarkly, Unleash ou une implémentation maison ;
déploiement progressif : canary release, pourcentage d’utilisateurs, activation par segment ;
surveillance applicative avec Sentry, Datadog ou New Relic ;
rollback simple en cas d’incident.

Il n’est pas nécessaire de viser 90 % de couverture de tests pour commencer. Sur un legacy, il est souvent plus rentable de couvrir les 10 parcours qui génèrent 80 % de la valeur que de tester tout le système de façon théorique. Un script Playwright qui vérifie l’ajout au panier, le passage de commande et la confirmation d’email vaut parfois plus qu’une batterie de tests unitaires mal ciblés.

Traiter le SEO comme une contrainte de production

Beaucoup de refontes échouent non pas sur le code, mais sur la visibilité. Changement d’URL, balises supprimées, maillage interne perdu, temps de réponse dégradé : le trafic organique peut décrocher en quelques jours. Une modernisation progressive limite ce risque, à condition de respecter quelques règles simples :

conserver les URL performantes quand c’est possible ;
préparer des redirections 301 exhaustives si une structure change ;
préserver les balises title, meta description, canonical, hreflang si elles existent ;
vérifier le rendu HTML réellement crawlable ;
surveiller Search Console après chaque lot.

Sur un site éditorial, supprimer ou renommer 1 000 URL sans plan de redirection peut coûter des mois de trafic. À l’inverse, une migration bien préparée, testée sur un crawl de préproduction avec Screaming Frog, réduit fortement les pertes. Le SEO n’est pas un sujet “après mise en ligne” : c’est une contrainte d’architecture.

Moderniser l’expérience sans surcharger la stack

Refondre ne veut pas dire complexifier. Beaucoup d’équipes remplacent un legacy imparfait par une stack surdimensionnée : SPA partout, microservices précoces, surcouche de build lourde, dépendances nombreuses. Résultat : le site est plus moderne sur le papier, mais plus difficile à maintenir.

Une approche sobre consiste à choisir la solution la plus simple qui répond au besoin réel. Si 90 % des pages sont éditoriales, un rendu serveur ou statique avec quelques îlots interactifs peut suffire. Des outils comme Next.js, Nuxt ou Astro permettent justement des approches hybrides. Astro, par exemple, est souvent pertinent pour réduire le JavaScript envoyé au navigateur, en n’hydratant que les composants nécessaires.

Le bon critère n’est pas “est-ce moderne ?”, mais “est-ce maintenable par l’équipe dans 2 ans ?”. Une petite équipe interne sera souvent plus efficace avec une architecture lisible, des conventions claires et peu de dépendances qu’avec une solution très ambitieuse mais fragile.

Faire de la refonte un processus continu

Une base legacy n’est pas un état honteux : c’est souvent le signe qu’un produit a vécu, généré du revenu et absorbé des demandes réelles. Le vrai enjeu n’est pas de repartir de zéro, mais de remettre le système dans une trajectoire saine. Cela passe par une discipline continue :

mettre à jour les dépendances régulièrement ;
supprimer le code mort à chaque sprint ;
documenter les décisions d’architecture ;
mesurer les régressions de performance ;
réserver du temps de maintenance dans la roadmap.

C’est souvent ce point qui fait la différence entre une refonte réussie et une simple parenthèse. Si l’équipe modernise pendant 6 mois puis recommence à empiler les urgences sans garde-fous, le legacy se reforme très vite.

La meilleure refonte n’est pas celle qui promet un nouveau départ total. C’est celle qui améliore l’existant par étapes, sans interrompre le service, sans perdre les acquis métier et sans créer plus de complexité qu’elle n’en retire.

Une stratégie réaliste pour avancer

Pour un site legacy, la stratégie la moins risquée est souvent la plus terre à terre : auditer, mesurer, prioriser, isoler, remplacer progressivement. On commence par ce qui rapporte le plus ou casse le plus, on sécurise avec des tests et de l’observabilité, et on évite les grands soirs techniques. Cette méthode demande moins d’héroïsme, mais elle donne généralement de meilleurs résultats.

Chez un média comme Code Brut, cette approche a du sens parce qu’elle épouse la réalité du développement web : des compromis, des contraintes et des choix pragmatiques. Refondre sans tout casser, ce n’est pas manquer d’ambition. C’est faire preuve de maturité technique.

Pour aller plus loin sur les patterns de migration progressive, la lecture de Martin Fowler sur le Strangler Pattern reste une référence utile. Côté performance, les recommandations de web.dev sur les Core Web Vitals offrent un cadre concret pour prioriser les optimisations qui comptent vraiment.