14. Décider une refonte de site avec un audit en sept points
Avant de refaire votre site, vérifiez sept points concrets : objectif, offre, contact, contenus, mobile, maintenance et migration. Une méthode pour décider quoi conserver, corriger ou reconstruire.
Découvrir mon accompagnement pour une refonteEn bref
Un site qui vieillit n’a pas forcément besoin d’être reconstruit. Avant de demander une refonte, vérifiez sept points : l’objectif commercial, la clarté de l’offre, les parcours de contact, les contenus, l’expérience mobile et l’accessibilité, la base technique, puis les données et accès à préserver. À la fin, classez chaque problème en conserver, corriger ou reconstruire. Vous aurez un périmètre utile pour demander un devis, au lieu d’acheter un nouveau design sans savoir ce qu’il doit améliorer.
Pourquoi auditer avant de refaire le site ?
Une refonte peut résoudre un problème réel : offre devenue illisible, formulaire défaillant, administration trop compliquée ou structure technique difficile à maintenir. Elle peut aussi déplacer le problème. Si les visiteurs ne comprennent pas ce que vous proposez, remplacer les couleurs et le framework ne changera pas grand-chose.
Pour une petite entreprise, je commencerais par un document simple : l’adresse du site, son objectif principal, les pages importantes, les accès disponibles et trois difficultés observables. Le Portail PME de la Confédération insiste sur l’organisation de l’information, la présentation des services et l’usage mobile. Ce sont de meilleurs points de départ qu’une impression générale de « site ancien ».
Voici mon audit en sept points. Il ne remplace pas une analyse approfondie, mais permet de décider où investir en premier.
1. Quel résultat le site doit-il produire ?
Choisissez une action principale : recevoir une demande de devis, obtenir une réservation, présenter des réalisations ou permettre à un client de trouver une information. Puis ouvrez le site comme si vous ne connaissiez pas l’entreprise.
- En quelques secondes, comprend-on à qui s’adresse l’offre ?
- Le service et la zone desservie sont-ils clairs ?
- L’action attendue est-elle visible sur mobile comme sur ordinateur ?
- Le formulaire arrive-t-il à la bonne personne et reçoit-elle les informations nécessaires pour répondre ?
Si la réponse est « non », commencez par clarifier le message et le parcours. Cette correction peut être moins coûteuse qu’une refonte complète. Si le modèle de l’entreprise a changé, il faudra peut-être revoir l’architecture du site, pas seulement sa page d’accueil.
2. Les pages décrivent-elles encore l’offre réelle ?
Faites la liste des pages qui parlent d’un service, d’un prix, d’une équipe ou d’une zone géographique. Pour chacune, notez : à jour, à corriger, à retirer après redirection éventuelle. Vérifiez aussi les horaires, coordonnées, photos, exemples et appels à l’action.
Une page techniquement parfaite qui décrit une ancienne offre nuit à la qualité des demandes. À l’inverse, une page qui répond déjà bien aux questions de vos clients mérite d’être conservée ou améliorée. Avant de la supprimer, regardez si elle reçoit des visites ou des liens. La Search Console de Google aide à observer les requêtes et pages qui apportent de la visibilité ; elle ne dit pas, seule, si ces visiteurs deviennent des clients.
3. Où le parcours de contact se casse-t-il ?
Testez un scénario réel de bout en bout. Par exemple : « Je suis responsable d’une PME en Valais, je cherche une refonte et je veux savoir si cette entreprise peut m’aider. » Depuis une recherche ou la page d’accueil, trouvez l’offre, lisez une preuve, puis envoyez une demande de test.
Regardez ce qui se passe après le clic : message de confirmation, livraison du formulaire, contenu reçu et délai de traitement prévu. Un bouton qui ouvre la bonne page n’est pas suffisant si le message se perd ou si personne ne sait qui doit répondre. Pour un site de service, je note séparément les questions qui freinent la prise de contact : périmètre, méthode, délais, maintenance et prochaine étape.
4. Le site fonctionne-t-il vraiment sur mobile et au clavier ?
Ne réduisez pas ce contrôle à une capture d’écran. Sur un téléphone, parcourez les pages importantes, ouvrez les menus, remplissez le formulaire et lisez les textes sans zoomer. Ensuite, utilisez seulement le clavier sur ordinateur : pouvez-vous atteindre les liens et voir clairement où se trouve le focus ? Les images informatives ont-elles une alternative textuelle utile ?
Les WCAG du W3C fournissent une référence pour l’accessibilité. Un test rapide ne certifie pas la conformité ; il révèle les obstacles les plus visibles et aide à prioriser une évaluation sérieuse. Si le problème se limite à quelques composants, une correction ciblée peut suffire. Si le système de pages entier reproduit les mêmes obstacles, la refonte devient plus plausible.
5. La lenteur vient-elle du contenu, du code ou de l’hébergement ?
Mesurez d’abord les pages importantes avec des données adaptées, puis cherchez la cause. Une grande image non optimisée, des scripts externes, une page trop lourde ou un serveur lent n’appellent pas la même solution. Les Core Web Vitals distinguent notamment chargement perçu, réactivité et stabilité visuelle. Ils éclairent le diagnostic, mais ne remplacent pas les essais du parcours réel.
Demandez au prestataire de montrer ce qui est lent, sur quelle page, dans quelle condition, et ce qu’il propose de modifier. Une promesse globale de « site plus rapide » sans mesure initiale est difficile à vérifier. Il peut être raisonnable d’optimiser les images et les scripts avant de changer toute la plateforme.
6. Peut-on encore administrer et maintenir le site ?
Essayez une tâche courante : modifier un horaire, une photo ou le texte d’une offre. Qui détient les accès au domaine, à l’hébergement, au CMS, aux statistiques et aux sauvegardes ? Qui met à jour les extensions ou dépendances ? Existe-t-il une procédure pour revenir en arrière après une erreur ?
Un site peut paraître correct au public et être devenu coûteux à entretenir. Si chaque petit changement nécessite un développeur, le vrai besoin est peut-être un meilleur système de contenu. Si la technologie est obsolète et bloque les mises à jour, une reconstruction progressive peut être plus saine qu’une série de réparations. La réponse dépend de l’état réel du code et des accès ; aucun audit à distance ne peut la déduire de l’âge du site seul.
7. Que risque-t-on de perdre pendant la migration ?
Avant toute décision, inventoriez les URL actuelles, les pages utiles, les images, les formulaires, les contenus du CMS et les intégrations. Si les URL changent, préparez une correspondance ancienne URL → nouvelle URL pertinente et testez les redirections. Google recommande une cartographie des URL et des redirections permanentes côté serveur lors d’un déplacement de site ; rediriger toutes les anciennes pages vers l’accueil peut créer de mauvais résultats pour les visiteurs et la recherche (Google Search Central).
Vérifiez également qui peut exporter les données et qui dispose des droits de publication. Sans ces accès, un devis de refonte est nécessairement conditionnel. Prévoir la migration tôt évite de découvrir au lancement qu’un contenu important ou une connexion métier a été oublié.
Comment décider entre correction et refonte ?
À la fin de l’audit, classez les constats dans un tableau court :
| Décision | Quand elle est raisonnable | Exemple |
|---|---|---|
| Conserver | La page ou la fonction sert encore son objectif. | Un guide utile et à jour qui attire les bonnes questions. |
| Corriger | Le problème est local et mesurable. | Un formulaire qui n’envoie pas les bonnes informations, une image trop lourde. |
| Reconstruire | Plusieurs limites structurelles empêchent les améliorations ou rendent la maintenance fragile. | Une architecture qui ne peut plus accueillir les offres actuelles et dont les mises à jour sont bloquées. |
Associez à chaque ligne une preuve, une priorité et une personne responsable. Vous pouvez alors demander des devis comparables : mêmes pages, mêmes contenus, mêmes intégrations, mêmes critères de recette. Mon guide du cahier des charges aide à transformer ce diagnostic en demande claire ; mon article sur le budget d’un site en Suisse aide à séparer réalisation et coûts récurrents.
FAQ
Un site qui date de plusieurs années doit-il être refait ?
Pas automatiquement. L’âge donne une raison de vérifier sécurité, maintenance, contenus et parcours. La décision dépend des problèmes constatés et du coût des corrections possibles.
Peut-on changer uniquement le design ?
Oui, si la structure, les contenus, les formulaires et la base technique répondent encore au besoin. Il faut tout de même tester le rendu mobile et l’accessibilité du nouveau design.
Une refonte améliore-t-elle forcément le référencement ?
Non. Une refonte peut améliorer la clarté et la technique, mais elle peut aussi perdre des pages ou casser des URL. Un inventaire, des redirections et une vérification après mise en ligne sont indispensables lorsque la structure change.
Que préparer avant de demander un devis ?
L’adresse du site, l’objectif principal, les difficultés observées, les pages et contenus à garder, les accès connus, les intégrations et la personne qui validera le projet. Si un élément manque, indiquez-le : un devis honnête peut prévoir une phase d’audit.
Vous voulez décider sur des faits ?
Je propose une refonte de site web en Valais qui commence par l’existant : objectifs, pages, parcours et accès. Si vous m’envoyez l’adresse de votre site et votre difficulté principale, nous pouvons d’abord distinguer ce qui mérite une correction de ce qui justifie réellement une reconstruction.