Un site peut sembler ancien tout en reposant sur des bases solides, ou paraître moderne alors que contenus, performance et opérations fonctionnent mal. La bonne décision ne dépend pas uniquement de l’apparence. Une refonte améliore l’expérience sur une base viable ; une reconstruction remplace cette base lorsqu’elle bloque des résultats importants. Cette frontière doit être comprise avant de fixer le périmètre et le budget.
Diagnostiquer le problème avant de nommer le projet
Commencez par les preuves issues du site actuel : parcours critiques, visibilité organique, publication, accessibilité, vitesse, intégrations et effort de support. Séparez les symptômes des causes. Une conversion faible peut venir d’un positionnement flou, d’un parcours mobile défaillant, d’un trafic peu qualifié ou d’un checkout instable. Nommer immédiatement tout problème « refonte » crée un brief visuel avant de comprendre les contraintes métier et techniques.
Identifier ce qui mérite d’être conservé
Une refonte convient lorsque la plateforme est sûre, maintenable et capable de soutenir l’architecture d’information nécessaire. Les URL, contenus, intégrations et historiques de mesure peuvent avoir une valeur importante. Préservez ce qui fonctionne et modifiez les couches qui nuisent à la compréhension ou à l’action. Une reconstruction devient probable si les mises à jour sont bloquées, si les templates limitent les structures nécessaires ou si l’exploitation dépend de correctifs manuels fragiles.
Auditer contenus et SEO avant de déplacer les URL
Dressez l’inventaire des pages importantes avec leur objectif, leur demande, leurs liens, leurs conversions et leur statut. Décidez quoi conserver, améliorer, fusionner, rediriger ou supprimer. Associez chaque ancienne URL à sa destination finale avant le lancement et évitez les chaînes. Reconstruire sans modèle de contenu déplace simplement les incohérences dans de nouveaux templates. Une migration utile protège la demande existante tout en retirant les pages sans rôle clair.
Organiser la réalisation autour des risques
Regroupez les dépendances : modèle de contenu, design system, templates principaux, intégrations, migration et contrôles de mise en production. Prototypez tôt le parcours le plus risqué. Si la plateforme peut évoluer sans danger, livrez progressivement. Si une reconstruction s’impose, définissez gel des contenus, répétition de migration, retour arrière et responsabilités le jour du lancement. Le nombre de pages ne reflète pas la complexité des intégrations, droits ou opérations éditoriales.
Valider le modèle opérationnel après le lancement
Un lancement réussi ne se résume pas à une comparaison visuelle. Les éditeurs doivent publier sans risque, les redirections et formulaires doivent fonctionner, le monitoring doit exposer les erreurs et les responsabilités doivent être claires. Comparez performance, réussite des parcours et effort de support au point de départ. Maintenez un backlog d’amélioration maîtrisé au lieu de rouvrir toute la refonte à chaque nouvelle demande.