Refonte de site web : méthode et checklist pour décider sans perdre l’existant

1. Déterminer si la refonte est réellement nécessaire

Un site vieillissant n’a pas toujours besoin d’être reconstruit. Si l’offre reste claire, que le socle technique est maintenable et que quelques parcours concentrent les difficultés, une optimisation progressive peut être plus rapide et moins risquée. La refonte devient pertinente lorsque l’architecture ne représente plus l’activité, que la dette technique bloque chaque évolution ou que plusieurs problèmes se renforcent mutuellement.

Le diagnostic doit séparer les symptômes des causes. Une baisse de demandes peut venir d’un trafic moins qualifié, d’une proposition de valeur devenue floue, d’un formulaire pénible ou d’une mesure défaillante. Refaire l’interface sans vérifier ces hypothèses déplace souvent le problème au lieu de le résoudre. Pour un formulaire peu utilisé, comparez trois observations : nombre de visites de la page, démarrages du formulaire et demandes reçues. Un problème entre les deux premières étapes appelle une autre investigation qu’une confirmation affichée sans réception. Documentez aussi les limites de la mesure, notamment les refus de consentement et les erreurs de suivi.

• Inventorier les pages qui attirent, rassurent ou convertissent déjà.
• Observer les parcours mobiles, les abandons et les demandes reçues.
• Lister les contraintes de publication, de sécurité et de maintenance.
• Formuler les résultats attendus avec un indicateur et une période d’observation.

Décision utileSi le problème peut être décrit précisément et corrigé sans fragiliser le reste, commencez par une intervention ciblée. Une refonte se justifie quand la structure elle-même empêche les améliorations.

2. Cadrer l’offre, les publics et les preuves

L’arborescence doit découler de ce que les visiteurs cherchent à comprendre et à accomplir. Avant les maquettes, il faut donc nommer les publics prioritaires, leurs questions, les objections qui ralentissent la décision et les preuves disponibles. Cette matière évite de concevoir des blocs vides que l’équipe devra remplir trop tard.

Chaque page reçoit un rôle explicite : expliquer une offre, répondre à une situation, démontrer une expertise, orienter vers un contact ou soutenir une autre page. Les contenus sans rôle sont fusionnés, déplacés ou supprimés. Les contenus performants sont conservés, enrichis et reliés à la nouvelle structure. Construisez une fiche par page prioritaire : question du visiteur, réponse attendue, preuve disponible et responsable de mise à jour. Par exemple, une page de service peut expliquer les prérequis et les livrables sans annoncer un délai identique pour toutes les missions. Les points encore inconnus deviennent des questions à résoudre avant la rédaction.

• Une page principale par besoin clairement distinct.
• Un vocabulaire aligné sur les mots du public et sur la réalité de l’offre.
• Des preuves proches des affirmations qu’elles soutiennent.
• Un appel à l’action proportionné au niveau de maturité du visiteur.

3. Concevoir le parcours SEO et SXO ensemble

Le SEO facilite la découverte ; le SXO transforme cette découverte en expérience satisfaisante. Une page ne doit donc pas seulement reprendre une requête : elle doit confirmer rapidement que le visiteur est au bon endroit, donner une réponse exploitable et proposer une suite logique. Le titre, l’introduction, la hiérarchie et les liens internes participent au même mouvement.

Sur mobile, cette continuité devient décisive. Les informations essentielles doivent rester visibles sans zoom, les zones interactives suffisamment grandes et les formulaires limités aux données réellement nécessaires. Un contenu long reste confortable s’il est découpé, annoncé par un sommaire et ponctué de repères concrets. Pour vérifier le parcours, donnez une tâche concrète à une personne qui ne connaît pas le site : retrouver le périmètre d’une prestation puis préparer une demande. Observez les hésitations et les retours en arrière. Une page peut contenir la bonne information tout en l’exprimant sous un intitulé que le public ne reconnaît pas.

• Un H1 descriptif et une introduction qui répond avant de développer.
• Des H2 qui permettent de comprendre le plan en le parcourant rapidement.
• Des liens internes dont l’intitulé annonce clairement la destination.
• Des états de focus, contrastes et libellés utilisables au clavier et au toucher.

4. Préserver l’acquis lors de la migration

Toute URL utile de l’ancien site doit avoir une destination décidée. Lorsqu’une page change d’adresse, une redirection permanente vers l’équivalent le plus proche protège le parcours des visiteurs et aide les moteurs à transférer les signaux. Rediriger toutes les anciennes pages vers l’accueil masque les erreurs et crée une expérience incohérente.

Le tableau de correspondance est préparé avant la bascule puis contrôlé après publication. Il couvre les pages indexables, les ressources téléchargées, les liens internes, les canonicals, les métadonnées sociales et le sitemap. Les redirections restent en place durablement et les liens internes sont mis à jour pour éviter une chaîne de sauts inutiles. Le tableau de correspondance doit inclure les URL présentes dans les anciens liens, les documents téléchargés et les campagnes encore utilisées. Distinguez les destinations équivalentes des contenus sans successeur. Après la bascule, essayez les anciennes adresses elles-mêmes : un lien interne corrigé ne démontre pas que la redirection de l’ancienne adresse fonctionne.

• Exporter les URL connues depuis le site, le sitemap et les outils de mesure.
• Associer chaque ancienne URL à une page conservée, fusionnée ou supprimée.
• Tester les codes HTTP, les boucles et les chaînes de redirection.
• Soumettre le nouveau sitemap et surveiller l’exploration après lancement.

5. Fixer un budget de performance mesurable

La performance ne se traite pas à la fin. Le poids des images, le nombre de polices, les scripts tiers et la complexité des composants doivent recevoir des limites dès la conception. Les Core Web Vitals donnent trois repères de terrain : chargement principal, réactivité et stabilité visuelle.

Les seuils dits « bons » sont actuellement un LCP inférieur ou égal à 2,5 secondes, un INP inférieur ou égal à 200 millisecondes et un CLS inférieur ou égal à 0,1, évalués au 75e centile. Ils ne remplacent pas l’observation réelle, mais fournissent une base commune pour éviter qu’un effet visuel ou un outil marketing ne dégrade silencieusement l’expérience. Choisissez des pages et des actions représentatives : ouverture d’une fiche, affichage d’une image et interaction avec un formulaire. Conservez les conditions de mesure avant et après, dont appareil, connexion et cache. Une amélioration observée sur l’accueil ne suffit pas à conclure sur une fiche comportant davantage de médias.

• Servir des images WebP adaptées à la largeur d’affichage.
• Réserver la priorité réseau au visuel principal et différer le reste.
• Définir les dimensions des médias pour limiter les décalages de mise en page.
• Tester sur un appareil mobile et une connexion réalistes, puis suivre les données de terrain.

6. Organiser la recette et les trente premiers jours

La recette ne se limite pas à vérifier que les pages s’affichent. Elle suit des scénarios : trouver une prestation, comprendre les conditions, envoyer une demande, changer de langue, utiliser le clavier ou revenir depuis une ancienne URL. Chaque anomalie reçoit un niveau de priorité lié à son effet sur le visiteur et sur l’activité.

Après la mise en ligne, les trente premiers jours servent à comparer les hypothèses au réel. On surveille les erreurs serveur, les pages introuvables, l’indexation, les formulaires, les performances et les premiers parcours. Les écarts importants sont corrigés rapidement ; les améliorations moins urgentes rejoignent une feuille de route. À chaque anomalie, associez une page, les étapes pour la reproduire, le résultat attendu et celui observé. Classez séparément les défauts qui empêchent une demande et les améliorations de confort. Après correction, rejouez le scénario concerné et un parcours voisin plutôt que de vous fier à une capture de la nouvelle version.

• Tester les parcours critiques sur ordinateur et mobile.
• Vérifier les formulaires, messages d’erreur et confirmations.
• Comparer les URL indexées, exclues et redirigées.
• Documenter les corrections afin de conserver une base maintenable.

Refonte complète ou optimisation ciblée ?

Cas de contrôle

Une fiche pour vérifier votre propre situation

Choisissez une page qui reçoit déjà des demandes et suivez son parcours avant puis après refonte.

À consigner

Consignez ancienne URL, destination, contenu préservé et étapes de contact.

Critère de réussite

Le visiteur retrouve l’offre et peut terminer la même tâche sur mobile.

Erreur à éviterRepartir d’une maquette vide avant de connaître les fonctions qui créent déjà de la valeur.