Guide8 min de lecture
Par KRUZMis à jour le
Refonte de site web : quand la prévoir et comment la cadrer
Identifiez les raisons valables de refondre un site, auditez l’existant et préparez contenu, redirections, tests et mesure avant la mise en ligne.

01
Refondre pour résoudre un problème défini
Une apparence datée ne justifie pas, à elle seule, une reconstruction. Une refonte devient pertinente lorsque le site ne représente plus l’offre, complique une tâche importante, fonctionne mal sur certains appareils, reste difficile à maintenir ou dépend d’outils qui ne répondent plus aux besoins.
Transformez chaque constat en objectif vérifiable : rendre une information plus facile à trouver, simplifier une demande, publier dans plusieurs langues ou permettre à l’équipe de mettre le contenu à jour. Cette liste évite de confondre préférence graphique et besoin métier.
02
Commencer par l’audit de l’existant
Inventoriez les pages, modèles, formulaires, intégrations, médias et comptes externes. Ajoutez les données disponibles sur les pages consultées, les requêtes internes, les erreurs et les actions importantes, en tenant compte du consentement et de la confidentialité.
Classez ensuite chaque élément : conserver, améliorer, fusionner, rediriger ou supprimer. Une refonte menée sans cet inventaire risque d’effacer un contenu utile ou de reproduire les mêmes difficultés dans une nouvelle interface.
Inventoriez les pages, modèles, formulaires, intégrations, médias et comptes externes.
03
Protéger les URL et la compréhension du contenu
Si une URL change, préparez une correspondance précise entre l’ancienne et la nouvelle page. Les redirections doivent mener vers la ressource la plus proche, pas systématiquement vers l’accueil. Mettez aussi à jour les liens internes, les canoniques et les plans de site.
- Conservez les informations qui répondent encore aux besoins des visiteurs.
- Une nouvelle mise en page ne compense pas des textes vagues, des titres génériques ou des pages locales quasi identiques.
- Aucun processus de migration ne peut garantir le maintien d’une position dans les résultats.
04
Concevoir et développer par priorités
Validez d’abord l’architecture, les parcours et quelques modèles représentatifs. Testez-les avec le vrai contenu avant de décliner toutes les pages : les longueurs de titres, images, tableaux et formulaires révèlent des contraintes invisibles dans des maquettes factices.
Prévoyez dès le départ les états de clavier, le contraste, les erreurs de formulaire, les petits écrans et les performances. L’expérience de page fait partie de la qualité globale, mais Google précise qu’elle ne remplace pas la pertinence du contenu.
05
Tester la migration avant le lancement
Sur une version de préproduction non indexée, vérifiez les principaux parcours, formulaires, langues, métadonnées, données structurées, redirections et outils de mesure. Contrôlez aussi les pages absentes, les liens cassés et les réponses du serveur.
Conservez une sauvegarde et un plan de retour réaliste. Attribuez à chaque personne une responsabilité claire pour la validation du contenu, de la technique et des aspects juridiques.
06
Les signaux qui justifient vraiment une refonte
Le premier signal est fonctionnel : une tâche importante échoue ou demande un effort disproportionné. Le formulaire de contact n’arrive plus, la page de réservation ne s’affiche pas sur téléphone, le menu du restaurant est une image illisible, ou l’équipe ne peut plus modifier un prix sans appeler quelqu’un. Ces situations ont un coût quotidien, mesurable en demandes perdues et en heures passées à contourner l’outil.
Le deuxième signal est technique : la version du CMS n’est plus maintenue, une extension critique a été abandonnée par son auteur, l’hébergement affiche des alertes de sécurité, ou le site ne passe plus en HTTPS correctement. Un site dans cet état est un risque avant d’être un problème d’image, et la refonte devient une mesure de protection.
Le troisième signal est stratégique : l’offre a changé et le site raconte encore l’ancienne. Nouvelle activité, nouvelle zone desservie, passage au multilingue, abandon d’un service ; quand le décalage entre ce que fait l’entreprise et ce que dit son site devient visible aux clients, chaque visite travaille contre vous. Une simple apparence datée, sans l’un de ces trois signaux, se corrige souvent par une retouche graphique et non par une reconstruction.
07
L’inventaire des URL : méthode concrète
Exportez la liste complète des pages indexées depuis Search Console, complétez-la avec le plan de site actuel et avec un crawl du site réalisé par un outil dédié. Les trois sources ne coïncident jamais exactement : le crawl trouve des pages orphelines, Search Console révèle des URL que Google connaît encore mais que plus rien ne relie, et le plan de site liste parfois des pages disparues.
Pour chaque URL, notez le trafic des douze derniers mois, le nombre de liens externes qui pointent vers elle si vous disposez de cette information, et la décision : conserver telle quelle, réécrire, fusionner avec une autre, rediriger ou supprimer. Une page sans trafic, sans lien et sans rôle peut disparaître ; une page peu visitée mais citée par un annuaire ou un partenaire mérite une redirection précise.
- Le résultat est un tableau à deux colonnes — ancienne adresse, nouvelle adresse — qui devient le plan de redirections.
- Il se prépare avant le développement, se teste sur la préproduction et se vérifie le jour du lancement, URL par URL.
- C’est le livrable le plus ingrat de la refonte et celui qui évite le plus de dégâts.
08
Refonte progressive ou reconstruction complète
Une refonte progressive conserve la base technique et remplace les gabarits un à un, en commençant par les pages les plus visitées. Elle limite le risque, étale la charge et permet de mesurer chaque étape. Elle convient quand la structure des URL est saine, le CMS encore maintenu et le contenu globalement bon.
Une reconstruction complète repart d’une base neuve : nouvelle architecture, nouveau code, souvent nouvelle technologie. Elle s’impose quand la base actuelle est trop fragile pour être améliorée, quand le site dépend d’outils abandonnés, ou quand l’architecture de l’information doit changer en profondeur. Elle coûte plus cher d’un coup mais élimine une dette technique qui, sinon, se paie à chaque intervention.
Le choix se fait après l’audit, jamais avant. Un prestataire qui recommande la reconstruction sans avoir regardé l’existant vend sa méthode ; un prestataire qui promet une refonte progressive sur une base pourrie vend du temps. Demandez dans les deux cas ce qui a été examiné et ce qui motive la recommandation.
09
Le contenu : réécrire, pas seulement transférer
Une refonte est l’occasion de relire chaque texte avec la question la plus simple : cette page répond-elle à ce qu’un client vient y chercher ? Les pages de service écrites il y a cinq ans parlent souvent de l’entreprise plutôt qu’au client, empilent des adjectifs et oublient de dire ce qui est inclus, pour qui, et comment demander un devis.
Profitez-en pour regrouper ce qui est dispersé et supprimer ce qui est redondant. Trois pages qui disent presque la même chose sur trois communes se remplacent avantageusement par une page solide et une zone desservie claire. Une actualité de 2019 sur une promotion terminée peut disparaître sans regret.
Fixez enfin des règles de rédaction qui survivront au lancement : un seul titre principal par page, des intertitres qui annoncent le contenu, des paragraphes courts, une action claire en fin de page. Ces règles, écrites sur une page et partagées avec ceux qui publient, valent plus que la plus belle maquette.
10
Le jour du lancement et les semaines qui suivent
Lancez un jour où quelqu’un peut surveiller le site pendant plusieurs heures, jamais un vendredi soir. Vérifiez immédiatement les redirections sur un échantillon d’anciennes URL, le formulaire de contact avec un envoi réel, les paiements avec une commande de test si c’est une boutique, le plan de site et le fichier robots, et l’absence de balise d’interdiction d’indexation héritée de la préproduction.
Dans les jours suivants, surveillez dans Search Console les erreurs d’exploration et les pages introuvables ; chaque nouvelle erreur signale une redirection oubliée. Regardez aussi les données de performance réelles dès qu’elles sont disponibles, pour confirmer que le nouveau site fait mieux que l’ancien sur les mêmes gabarits.
Attendez plusieurs semaines avant de tirer une conclusion sur la visibilité. Google doit réexplorer l’ensemble des pages, réévaluer les redirections et recalculer ce qu’il sait du site ; une baisse temporaire n’est pas anormale et une hausse immédiate n’est pas garantie. Comparez ensuite des périodes équivalentes et notez chaque changement fait entre-temps, pour ne pas attribuer à la refonte ce qui vient d’ailleurs.
11
Mesurer ce que la refonte devait améliorer
Avant de changer le site, documentez une situation de départ : tâches réussies, demandes reçues, erreurs, performance réelle et questions fréquentes. Après le lancement, observez les mêmes indicateurs et segmentez les données lorsque le volume le permet.
- Une variation n’est pas automatiquement causée par le design.
- Saisonnalité, campagnes, changement d’offre et problèmes de suivi peuvent intervenir.
- Utilisez les résultats pour prioriser les corrections plutôt que pour annoncer un succès garanti.
Sujets abordés
- refonte site web Bruxelles
- audit de site
- migration SEO
- plan de redirections
Questions fréquentes
- Existe-t-il une durée de vie standard pour un site ?
- Non. Le besoin de refonte dépend de l’offre, de la maintenance, des technologies, du contenu et des attentes des utilisateurs. Un audit régulier est plus utile qu’une date d’expiration arbitraire.
- Une refonte conserve-t-elle automatiquement le référencement ?
- Non. Un inventaire des URL, des redirections précises et des contrôles techniques réduisent les erreurs évitables, mais aucune agence ne peut garantir des positions inchangées.
- Faut-il tout reconstruire ?
- Pas toujours. Si l’architecture et la technique restent adaptées, des améliorations ciblées peuvent suffire. Le choix doit suivre l’audit et les objectifs, pas une préférence de solution.
- Quand préparer le contenu ?
- Le plus tôt possible. Tester les modèles avec des textes et médias réels permet de repérer les lacunes, les doublons et les besoins de traduction avant l’intégration finale.