Quand faut-il refaire son site internet ?

Les sept signaux qui méritent une investigation

Un signal déclenche une analyse, pas automatiquement une refonte. Associez chaque symptôme à une donnée et à une conséquence : demandes inexploitables, offre devenue illisible, parcours mobile interrompu, technologie non maintenue, mises à jour impossibles, accessibilité bloquante ou acquisition impossible à mesurer.

Une baisse globale de trafic n’est pas une preuve suffisante : elle peut venir de la demande, de la saison, d’un changement de mesure ou d’une perte sur quelques requêtes. Segmentez par page, appareil, requête et action avant de conclure.

• Offre réelle différente du contenu publié
• Pages importantes difficiles à trouver
• Formulaire ou réservation fréquemment interrompus
• Corrections impossibles sans casser d’autres zones
• Socle ou dépendances non maintenus
• Données et consentement mal cadrés
• Équipe incapable de publier ou corriger seule

Réparer lorsque la cause est locale

Un titre imprécis, une page lente, un formulaire défaillant ou une navigation secondaire ne justifient pas forcément un nouveau site. Isolez le problème, corrigez-le, puis vérifiez le résultat attendu. Cette option conserve les URL, réduit le risque et produit une information utile avant un chantier plus large.

Exemple : une entreprise reçoit des demandes hors zone depuis une page bien positionnée. Si l’offre, la technique et les autres parcours fonctionnent, clarifier la zone, les conditions et le formulaire est plus rationnel que reconstruire tout le domaine.

Refondre un parcours lorsque plusieurs pages partagent la friction

Une refonte partielle convient lorsque la navigation, les contenus et les preuves d’un même parcours ne s’accordent plus. Cartographiez alors l’entrée, les questions, les pages traversées, les abandons et l’action finale. Conservez ce qui remplit encore son rôle.

Exemple : un industriel possède des pages produits correctes, mais aucun chemin cohérent entre une problématique, une application, une fiche technique et la prise de contact. Repenser ce parcours, ses liens et son formulaire peut suffire sans migrer le blog ni l’espace documentaire.

• Pages concernées identifiées
• Point de rupture observable
• Contenus conservés explicitement
• Critère de réussite défini

Reconstruire lorsque le socle bloque les priorités

Une reconstruction devient défendable si la technologie n’est plus maintenable, si l’architecture interdit les parcours nécessaires, si les dépendances créent un risque important ou si chaque correction coûte plus qu’elle ne résout. Faites documenter cette impossibilité : version, dépendance, contrainte, impact et alternative évaluée.

Ne confondez pas impossibilité et préférence technique. Un changement de CMS, de framework ou d’hébergeur doit résoudre une contrainte identifiée, pas seulement moderniser la pile.

Établir une baseline avant toute modification

Exportez les performances Search Console par page et requête, les conversions réellement suivies, les URL indexables, les backlinks connus, les formulaires, les contenus et les événements importants. Ajoutez des tests au clavier, sur mobile et sur les parcours clés. Cette photographie permet de protéger l’existant et de mesurer la suite.

Les données doivent être interprétées avec leurs limites : consentement, attribution, saisonnalité et faible volume. Complétez-les avec des appels commerciaux, des demandes reçues et des tests utilisateurs courts plutôt que de chercher une métrique unique.

• URL et statuts
• Requêtes et pages d’entrée
• Liens entrants utiles
• Demandes et qualité commerciale
• Tests mobile, clavier et formulaires
• Temps interne de mise à jour

Préparer la migration URL par URL

Pour chaque adresse existante, décidez : conserver, améliorer, fusionner, rediriger ou retirer. Une redirection doit viser l’équivalent le plus proche ; renvoyer toutes les anciennes pages vers l’accueil dégrade l’expérience et peut être traité comme une erreur souple.

Conservez les titles, contenus, liens et données structurées qui restent justes. Testez les redirections, canonical, sitemap, robots, formulaires et mesure sur l’artefact final, puis après publication. Google précise qu’une migration peut provoquer des fluctuations temporaires : planifiez le suivi plutôt qu’une promesse de maintien absolu.

Décider avec un seuil écrit

Attribuez à chaque problème un impact, une étendue, une fréquence, un risque et un coût de correction. Une reconstruction est raisonnable lorsque plusieurs problèmes prioritaires partagent une cause structurelle et que la réparation incrémentale ne produit pas un socle durable.

Si les preuves restent contradictoires, testez d’abord une page ou un parcours. Une décision réversible et mesurable vaut mieux qu’une refonte globale justifiée par des impressions.

Arbre de décision exécutable

1. Une action importante est-elle cassée ou impossible ? Si non, maintenez et améliorez. Si oui, corrigez-la sur une page test. 2. La même cause touche-t-elle au moins un parcours complet ? Si non, gardez la correction locale. Si oui, refondez ce parcours. 3. Le socle empêche-t-il cette refonte ou expose-t-il une dépendance non maintenue ? Si non, restez sur une refonte partielle. Si oui, préparez la reconstruction et la migration.

Exemple rempli : un formulaire mobile ne transmet plus les demandes, mais les pages et le CMS restent exploitables. Décision initiale : réparer le formulaire, envoyer trois soumissions de test et vérifier leur arrivée dans le CRM. Si le défaut disparaît, aucune refonte. Si tous les formulaires reposent sur une extension abandonnée et impossible à remplacer sans rupture, l’étude s’élargit au parcours, puis au socle.

Plan 30, 60 et 90 jours

Jours 1 à 30 : inventorier URL, parcours, demandes, contenus, dépendances et accès ; corriger les urgences réversibles ; établir la baseline. Jours 31 à 60 : tester la portée minimale sur un parcours, valider architecture et contenus, préparer la table URL et la recette. Jours 61 à 90 : produire ou migrer, tester sur cinq formats, publier avec un plan de retour, puis surveiller erreurs, formulaires, indexation et performances.

Les phases ne constituent pas une durée promise : un petit site peut aller plus vite et un système connecté demander davantage. Le jalon utile est la validation des preuves et livrables, pas le passage automatique à la date suivante.