Refonte de site
comment préparer le projet en interne avant de se lancer
Avant de contacter un prestataire, une refonte de site se prépare en interne. Voici comment auditer l’existant, protéger ce qui fonctionne et organiser le projet.
Une refonte de site réussie se prépare avant même le brief au prestataire : auditer chaque page existante pour décider ce qui doit être gardé, retravaillé ou supprimé, cartographier le trafic et les mots-clés à préserver, transformer ces résultats en cahier des charges protecteur, organiser clairement la gouvernance du projet en interne, puis tester sur un environnement séparé avant de publier.
- Audit d’abord : évaluer chaque page avant de décider quoi refaire.
- Trafic à préserver : cartographier les pages et mots-clés qui portent des résultats.
- Cahier des charges protecteur : lister explicitement ce qui doit être conservé.
- Tester avant de publier : redirections, mobile, formulaires, sur un environnement séparé.
Pourquoi l’audit de l’existant doit précéder toute refonte
Un projet de refonte démarre souvent par une envie légitime : un site vieilli, une navigation confuse, un design daté. Le risque, dans cet élan, consiste à tout remettre à plat sans avoir d’abord mesuré ce qui fonctionne réellement sur le site actuel. Des pages qui génèrent un trafic stable depuis des années, un formulaire qui convertit bien, une structure de navigation que les visiteurs ont fini par apprendre : tout cela peut disparaître dans une refonte mal préparée, sans que personne ne s’en aperçoive avant la chute des résultats.
L’audit préalable ne ralentit pas le projet, il le sécurise. Il permet de distinguer ce qui doit changer parce que cela ne fonctionne plus, de ce qui doit être préservé parce que cela fonctionne déjà très bien. Sans cette étape, une refonte se transforme facilement en pari, alors qu’elle devrait être une décision informée.
Auditer ses pages une à une
ce qui doit être gardé, retravaillé ou supprimer
Passer en revue chaque page du site, une à une, permet de sortir d’une approche globale trop vague. Pour chaque page, trois questions simples suffisent à orienter la décision : cette page génère-t-elle du trafic ou des conversions mesurables, répond-elle encore à une vraie intention de recherche actuelle, et son contenu reste-t-il exact et à jour. Prenons l’exemple d’une page de service vieille de cinq ans, toujours bien positionnée mais dont le texte évoque une offre qui a évolué depuis : elle entre clairement dans la catégorie à retravailler, puisqu’elle continue d’apporter du trafic malgré un contenu à actualiser.
| Catégorie | Critère | Action |
|---|---|---|
| À garder | Trafic, conversions et contenu à jour | Améliorer la forme sans toucher au fond |
| À retravailler | Pertinente mais peu visible ou datée | Revoir la visibilité ou le contenu |
| À supprimer | Obsolète ou redondante | Supprimer avec redirection propre |
Cartographier le trafic et les mots-clés existants avant de tout changer
Avant de repenser la structure du site, il devient indispensable de savoir précisément quelles pages portent le trafic organique et sur quels mots-clés elles se positionnent. Cette cartographie sert de garde-fou pendant toute la refonte : elle permet de vérifier, à chaque étape, que les pages qui comptent le plus ne perdent pas leur URL sans redirection, leur structure de titres, ou les éléments qui expliquent leur bon positionnement actuel.
Cette étape révèle aussi souvent des surprises : une page peu mise en avant dans la navigation peut concentrer une part importante du trafic, simplement parce qu’elle répond bien à une recherche précise. Ignorer cette réalité au profit d’une nouvelle architecture pensée uniquement sur l’intuition interne de l’équipe conduit régulièrement à des pertes de trafic après la mise en ligne, alors qu’elles auraient pu être anticipées et évitées.
Rédiger un cahier des charges qui protège ce qui fonctionne déjà
Le cahier des charges ne doit pas se limiter à décrire l’apparence souhaitée du futur site : il doit aussi documenter explicitement ce qui doit être préservé, page par page si nécessaire. Lister les URLs à rediriger, les pages à conserver à l’identique sur le fond, les mots-clés à ne pas perdre, transforme le cahier des charges en outil de protection autant que de projet.
Un prestataire qui reçoit un cahier des charges centré uniquement sur le design n’a aucune raison de préserver spontanément ce qui fonctionnait avant, puisque cette information ne lui a jamais été transmise clairement.
Organiser la gouvernance du projet en interne
Une refonte qui traîne ou qui change de direction en cours de route souffre souvent d’un problème de gouvernance plus que d’un problème technique. Désigner un décideur unique, capable de trancher rapidement entre plusieurs avis internes divergents, évite les allers-retours qui rallongent le projet et fatiguent le prestataire autant que l’équipe. Il reste utile de distinguer clairement qui valide le contenu, qui valide le design et qui valide les aspects techniques, plutôt que de laisser chaque partie prenante intervenir sur tous les sujets à la fois. Cette clarté des rôles, définie avant le lancement du projet plutôt qu’improvisée en cours de route, fait souvent la différence entre une refonte qui tient ses délais et une refonte qui s’étire indéfiniment.
Le plan de bascule
tester avant de publier, pas après
La bascule vers le nouveau site ne doit jamais se faire sans une phase de test préalable sur un environnement séparé, invisible du public. Un plan de bascule sérieux prévoit aussi un point de contrôle dans les jours qui suivent la mise en ligne, pour surveiller les premiers signaux et pouvoir corriger vite, avant que le problème ne s’installe dans la durée.
-
1. Environnement séparé
Tester le nouveau site sur un environnement invisible du public avant toute bascule.
-
2. Redirections
Vérifier que chaque URL importante redirige réellement vers son équivalent.
-
3. Affichage et formulaires
Contrôler le rendu mobile des pages clés et l’envoi correct des formulaires.
-
4. Surveillance post-lancement
Suivre les premiers signaux dans les jours qui suivent pour corriger vite.
Faut-il auditer toutes les pages avant une refonte, même sur un gros site ?
Idéalement oui, au moins pour les pages qui génèrent du trafic ou des conversions mesurables. Trois questions suffisent pour chaque page : génère-t-elle du résultat, répond-elle encore à une intention de recherche actuelle, et son contenu reste-t-il exact et à jour.
Comment éviter de perdre son trafic lors d’une refonte de site ?
Cartographier précisément les pages qui portent le trafic organique et leurs mots-clés avant de changer la structure du site, puis vérifier à chaque étape que ces pages conservent une redirection propre et leurs éléments clés de positionnement.
Que doit contenir un cahier des charges de refonte pour protéger l’existant ?
Au-delà du design souhaité, il doit lister les URLs à rediriger, les pages à conserver sur le fond et les mots-clés à ne pas perdre. Sans cette information explicite, le prestataire n’a aucune raison de préserver spontanément ce qui fonctionnait déjà.
Comment tester un nouveau site avant sa mise en ligne ?
Sur un environnement séparé et invisible du public, en vérifiant que chaque redirection fonctionne, que l’affichage mobile reste cohérent sur les pages importantes, et que les formulaires envoient bien leurs données au bon endroit.
Une refonte réussie se joue rarement sur le nouveau design : elle se joue sur ce qu’on a pris le temps de comprendre avant de tout changer.