La crainte qui revient le plus souvent avant une refonte n'est pas le design, c'est la chute de trafic après la mise en ligne. Elle est fondée. La plupart des pertes constatées ne viennent pas du nouveau site, mais de ce qui n'a pas été cartographié avant de le construire. Voici comment nous traitons cette partie du projet, ce qui casse en pratique, et les cas où une refonte complète n'est pas la bonne réponse.
Cartographier l'existant avant de toucher au design
Un plan de redirections ne se construit pas à partir du menu du site. Il se construit à partir de tout ce qui existe réellement : sitemap, export des URL indexées dans la Search Console, crawl complet, journaux du serveur, pages listées par les outils de backlinks. Ces sources ne se recoupent jamais parfaitement, et c'est justement l'écart qui compte. Il contient les pages orphelines, qui ne sont plus liées nulle part en interne, mais toujours citées par un annuaire professionnel, un article de presse ou une fiche partenaire.
Avant de toucher au design, nous figeons une photo datée de l'existant : liste des URL, réponse HTTP de chacune, trafic reçu, positions sur les requêtes qui comptent, liens entrants connus. Ce document sert deux fois. Une première fois pour décider quoi garder, fusionner ou supprimer, avec des arguments plutôt qu'une impression visuelle. Une seconde fois après la mise en ligne, comme point de comparaison. Sans photo avant, il est impossible de démontrer quoi que ce soit après, et les discussions tournent en rond.
Une page qui ne reçoit presque aucune visite peut porter le seul lien entrant sérieux du site. La supprimer parce qu'elle paraît datée revient à jeter l'actif le plus difficile à reconstituer.
La table de correspondance, ligne par ligne
La table de correspondance associe chaque ancienne adresse à une destination unique, choisie sur l'intention et non sur la commodité. Rediriger tout ce qui disparaît vers la page d'accueil est la solution la plus rapide et la plus dommageable : le moteur traite ces redirections comme des pages introuvables déguisées, et la valeur accumulée ne se transmet pas.
Quelques règles que nous appliquons systématiquement. Une seule redirection permanente par adresse, sans enchaînement d'une ancienne URL vers une autre ancienne URL. Vérification que chaque destination répond bien en 200 et n'est pas elle-même redirigée. Traitement explicite des variantes techniques : http et https, avec et sans www, slash final, majuscules, paramètres de suivi, versions imprimables. Les fichiers ont aussi des adresses : images, PDF de catalogue ou de notice, souvent liés depuis l'extérieur et oubliés dans les inventaires.
La table est testée sur l'environnement de préproduction, ligne par ligne, avant la bascule. Après la mise en ligne, la liste complète des anciennes URL est repassée au crawler pour vérifier que chacune renvoie le code attendu vers la bonne cible. C'est fastidieux, et c'est la partie du projet qui protège le plus de trafic.
Les dégâts classiques, ceux qui se constatent après coup
Les incidents qui font vraiment chuter le trafic après une refonte sont peu nombreux et se répètent d'un projet à l'autre.
La balise noindex de la préproduction partie en production arrive en tête. Elle ne se voit pas à l'écran, le site paraît parfait, et l'indexation se vide en quelques semaines. Viennent ensuite les pages supprimées pendant le nettoyage éditorial parce qu'elles semblaient vieilles, alors qu'elles concentraient les liens entrants. Les balises title et meta description réécrites en bloc par un modèle de thème, qui remplace des intitulés travaillés par une formule générique répétée partout. Les images renommées ou déplacées sans conserver leurs anciennes adresses, ce qui efface au passage la visibilité dans la recherche d'images. Les données structurées oubliées dans la migration, avec les affichages enrichis qui disparaissent des résultats.
Deux autres se produisent en toute fin de projet. Le changement de structure d'URL décidé après la validation du plan, qui invalide silencieusement la table entière. Et la mise en ligne un vendredi soir, quand personne ne lira les journaux du serveur avant lundi.
Aucun de ces problèmes n'est visible le jour de la bascule. Ils se manifestent quelques semaines plus tard, au moment où la correction demande beaucoup plus de travail que la vérification qui l'aurait évitée.
Ce qui fait varier l'effort d'un projet à l'autre
Le périmètre d'une refonte dépend moins du nombre de pages visibles que de cinq facteurs concrets.
Le volume d'URL réellement indexées, qui dépasse souvent de beaucoup ce que l'on imagine depuis le menu. La présence d'un catalogue : une boutique multiplie les adresses par les variantes, les filtres, les pages de facettes et les fiches de produits arrêtés, dont certaines conservent des positions et des liens. Le multilingue : chaque langue a sa propre table de correspondance, et les balises hreflang doivent être reconstruites en cohérence avec les nouvelles adresses. La dette technique de l'existant : un site sur une version non maintenue, avec des extensions abandonnées et des personnalisations écrites directement dans le thème, demande un travail de désassemblage avant toute reconstruction. Enfin la qualité de l'accès aux anciens contenus : accès serveur, base de données exportable, hébergeur joignable, propriété du nom de domaine vérifiable. Quand cet accès est partiel, la récupération des contenus devient un chantier à part entière.
Ces cinq points sont évalués avant l'engagement, à partir des accès et des exports que vous nous transmettez par email. Ils déterminent le périmètre réel. Les découvrir en cours de route est la première cause de projets qui dérivent.
Les cas où une refonte complète n'est pas la bonne réponse
Le dire évite des projets ratés. Si le site est techniquement sain et que le problème est éditorial, pages trop courtes, absence de contenus répondant aux requêtes réelles, aucune reconstruction ne le résoudra : le nouveau design affichera les mêmes lacunes, en plus lisible. Si le site convertit correctement et que la gêne est surtout esthétique, une reprise ciblée du parcours et des pages clés produit généralement plus d'effet qu'une remise à zéro. Si le trafic provient presque entièrement d'une régie publicitaire ou d'une marketplace, le sujet est ailleurs.
La refonte se justifie quand la base technique bloque les évolutions, quand les temps de chargement restent mauvais malgré les réglages, quand l'administration repose sur une version qui ne reçoit plus de correctifs de sécurité, ou quand l'organisation des contenus empêche de traiter de nouveaux sujets.
Côté fonctionnement : nous travaillons depuis Dijon, entièrement par écrit et par email, avec une réponse sous 24 heures ouvrées. Pas de rendez-vous, pas d'appel, pas de visio, pas de déplacement. Cela suppose un interlocuteur capable de transmettre les accès et de trancher par écrit. Si votre organisation a besoin de réunions de cadrage, nous ne sommes pas le bon prestataire. Parmi les projets livrés : Chouchou Ribeyre, Au Petit Detail, LB Athletic, Mediavocats, Vectosolve. Chaque refonte est chiffrée sur devis, après examen de l'inventaire d'URL.
