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.

• 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.

• 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.

• 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.

• 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.

• 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.

• 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 ?

Avant d’avancer

La check-list opérationnelle

1. ✓Objectifs, publics et indicateurs de réussite validés.
2. ✓Inventaire des contenus et des URL réalisé.
3. ✓Pages à conserver, fusionner, enrichir ou supprimer décidées.
4. ✓Arborescence et parcours mobiles testés avant développement.
5. ✓Plan de redirection préparé et relu.
6. ✓Métadonnées, canonicals et données structurées vérifiés.
7. ✓Images responsive, dimensions et chargement contrôlés.
8. ✓Formulaires et messages de confirmation testés.
9. ✓Sitemap, robots.txt et outils de mesure prêts pour la bascule.
10. ✓Suivi des trente premiers jours attribué à un responsable.