Audit web · Guide TPE 2026 · environ 15 minutes
Un site ancien n’est pas forcément un mauvais site. À l’inverse, un site récemment mis en ligne peut déjà freiner les demandes de devis. La bonne décision ne dépend pas de son âge, mais de quatre questions : sert-il encore vos clients, votre visibilité, votre activité et votre équipe ?
Comment diagnostiquer son site sans être technicien ?
Commencez par cinq pages réelles : accueil, service principal, page locale ou produit, contact et article le plus visité. Testez-les sur votre téléphone en 4G, puis sur ordinateur. Demandez ensuite à une personne qui ne connaît pas votre entreprise : « Que vendons-nous, pour qui, où et comment nous contacter ? » Si elle hésite, le problème n’est pas seulement graphique.
Complétez ce test avec PageSpeed Insights, le rapport Core Web Vitals et l’inspection d’URL de Google Search Console, Lighthouse dans Chrome, un contrôle HTTPS, puis quelques actions réelles : appeler, demander un devis, acheter, réserver. Les outils automatisés signalent des symptômes ; ils ne remplacent ni un test humain ni l’analyse du chiffre d’affaires.
Les 12 signes les plus importants
1. Le contenu principal arrive trop lentement ou la page bouge
Problème. Une image héro trop lourde, des polices, scripts publicitaires ou extensions peuvent retarder l’information et déplacer les boutons pendant le chargement. Détection et mesure. Consultez les données mobiles du rapport Core Web Vitals dans Search Console, puis diagnostiquez les modèles de pages avec PageSpeed Insights : LCP, INP et CLS. Impact. L’utilisateur attend, clique au mauvais endroit ou abandonne ; Google recommande de bons signaux de page, mais un score parfait ne garantit pas un classement.
Décision. Optimisez si quelques images, scripts ou gabarits causent le problème. Envisagez une refonte technique si la lenteur est structurelle sur la majorité des pages et que le thème ou le constructeur empêche toute correction. Action : compresser et dimensionner les images, retirer les scripts inutiles, réserver l’espace média et mesurer avant/après sur 28 jours.
2. Le parcours mobile est incomplet ou pénible
Problème. Texte minuscule, boutons serrés, tableaux coupés, formulaire impossible à terminer ou contenu absent sur mobile. Or Google utilise la version mobile pour l’indexation et le classement. Détection et mesure. Testez les tâches essentielles sur plusieurs largeurs, sans Wi-Fi, avec zoom à 200 %. Comparez contenu, titres, liens, images et données structurées entre mobile et ordinateur. Lighthouse aide à repérer certaines anomalies, pas toutes.
Décision. Corrigez le CSS si la structure reste saine. Refonte partielle si les gabarits sont rigides ; complète si une version mobile séparée et divergente est devenue impossible à maintenir. Action : établir trois parcours mobiles prioritaires et faire réussir cinq tests consécutifs sans aide.
3. La proposition de valeur est illisible ou la marque incohérente
Problème. Un design peut sembler daté sans nuire au résultat. Il devient problématique lorsque contraste, hiérarchie, typographie ou incohérences empêchent de comprendre l’offre et d’identifier l’entreprise. Détection et mesure. En cinq secondes, un nouveau visiteur doit pouvoir reformuler le service, la cible, la zone et la prochaine étape. Contrôlez aussi le contraste WCAG : 4,5:1 pour le texte courant, 3:1 pour le grand texte.
Décision. Un ajustement du message et du système visuel suffit souvent. Refontez davantage si chaque page utilise une structure et des composants différents. Action : réécrire le premier écran, uniformiser titres, boutons, couleurs et preuves.
4. Les visiteurs se perdent dans la navigation
Problème. Menus internes, doublons, jargon et pages orphelines obligent le visiteur à deviner. Détection et mesure. Donnez à cinq personnes trois missions (« trouver le prix », « vérifier la zone », « demander un devis »). Notez réussite, temps, retours arrière et erreurs ; observez les recherches internes et les abandons de parcours. Impact. Une offre introuvable est une offre qui ne convertit pas, même si la page est bien référencée.
Décision. Optimisez les libellés et liens si les contenus sont bons. Refonte de l’architecture si les catégories ne correspondent plus aux besoins clients. Action : organiser les pages selon les questions du client, puis tester l’arborescence avant de la développer.
5. Le contenu ne correspond plus à l’entreprise ni aux questions des clients
Problème. Horaires, tarifs, équipe, prestations, zones, captures et promesses obsolètes détruisent la confiance. Un contenu vague ou générique répond mal aux recherches conversationnelles et fournit peu d’éléments vérifiables aux moteurs et assistants. Détection et mesure. Inventoriez chaque URL : propriétaire, date de vérification, trafic, requêtes, conversions, exactitude et action « garder, fusionner, actualiser, supprimer ».
Décision. C’est d’abord un chantier éditorial, pas une raison automatique de tout refaire. Refonte partielle si les gabarits ne permettent pas d’afficher clairement auteurs, dates, sources, services, FAQ ou informations locales. Action : actualiser en priorité les pages qui influencent une décision d’achat.
6. Les pages importantes sont mal explorées, indexées ou comprises
Problème. Mauvaise canonique, noindex, robots.txt mal réglé, liens uniquement générés en JavaScript, doublons ou pages sans lien interne peuvent rendre un contenu invisible. Google explore, rend puis indexe le JavaScript : rendre le texte essentiel directement dans le HTML initial réduit les dépendances et facilite aussi son accès par d’autres systèmes.
Détection et mesure. Utilisez l’inspection d’URL, le rapport d’indexation, les sitemaps et un crawl. Comparez URL déclarée, canonique choisie, code HTTP, titre, H1, texte et données structurées dans le HTML initial et rendu. Décision. Corrigez les règles si le défaut est local. Refonte technique si le CMS produit systématiquement des URL incohérentes ou masque le contenu derrière un rendu fragile. Action : corriger d’abord les pages commerciales et leurs liens internes.
7. Le trafic existe, mais les demandes utiles n’arrivent pas
Problème. Le trafic peut viser la mauvaise intention, la promesse peut être floue, la preuve insuffisante ou le formulaire trop exigeant. Détection et mesure. Définissez une conversion principale et des micro-conversions, puis segmentez par page d’entrée, appareil, source et type de demande. Vérifiez les formulaires avec de vraies soumissions et rapprochez les leads des ventes.
Décision. Optimisez d’abord proposition de valeur, preuve, CTA et formulaire ; testez. Refontez le parcours si les étapes et le contenu ne peuvent pas être modifiés sans casser le site. Action : instrumenter un entonnoir simple « arrivée → service vu → contact commencé → contact envoyé → lead qualifié » en respectant les règles CNIL.
8. Le site exclut des utilisateurs
Problème. Contraste faible, navigation clavier impossible, focus invisible, images informatives sans alternative, formulaires sans labels ou erreurs incompréhensibles bloquent des personnes et fragilisent la qualité globale. Détection et mesure. Parcourez tout au clavier, agrandissez le texte, lancez Lighthouse ou axe, puis réalisez des vérifications manuelles selon WCAG 2.2 niveau AA. Un score automatisé ne prouve jamais la conformité.
Décision. Corrigez les composants isolés ; refonte du design system si les mêmes défauts sont reproduits partout. Action : traiter en priorité navigation, contact, achat et réservation, puis faire tester par des utilisateurs concernés.
9. HTTPS, mises à jour et protections ne sont plus maîtrisés
Problème. Certificat expiré, contenu mixte, comptes partagés, extensions abandonnées, absence de sauvegarde testée et dépendances vulnérables augmentent le risque. L’OWASP Top 10:2025 inclut les défaillances de chaîne logicielle et les composants obsolètes. Détection et mesure. Vérifiez certificat, redirections HTTP→HTTPS, inventaire et versions des composants, comptes administrateurs, sauvegardes, journaux et alertes.
Décision. Une mise à niveau maîtrisée est préférable à une refonte esthétique. Refaire devient rationnel lorsque le socle n’est plus supporté ou ne peut être mis à jour sans rupture. Action : sauvegarde hors serveur, restauration testée, moindre privilège, MFA, correctifs et plan d’incident.
10. Le CMS rend chaque petite modification risquée ou coûteuse
Problème. Il faut appeler un développeur pour changer un tarif, les blocs se cassent, l’éditeur est incompréhensible ou la préproduction n’existe pas. Détection et mesure. Chronométrez cinq tâches courantes et comptabilisez incidents, délais, dépendances et coût annuel de maintenance. Impact. Le site cesse d’évoluer, donc les informations deviennent fausses.
Décision. Formation, rôles, gabarits et nettoyage peuvent suffire. Refonte partielle ou migration si le CMS ne répond plus aux compétences, au volume ou aux exigences métier. Action : rédiger la liste des dix opérations que l’équipe doit réaliser sans aide.
11. La technologie est obsolète, non supportée ou difficile à intégrer
Problème. Une dépendance n’est plus maintenue, le serveur utilise une version en fin de vie, ou le site ne peut se connecter au CRM, à la réservation, au paiement ou aux API nécessaires. Détection et mesure. Dressez l’inventaire du CMS, langage, runtime, thème, extensions et services ; vérifiez leurs politiques officielles de support, mises à jour et export.
Décision. Mettez à niveau si une trajectoire supportée existe. Refontez le socle si les correctifs sont impossibles, si la donnée est captive ou si chaque intégration exige un contournement fragile. Action : construire une preuve de concept sur l’intégration la plus critique avant de choisir une plateforme.
12. Le site ne peut plus accompagner les priorités de l’entreprise
Problème. Nouvelles zones, langues, franchises, catalogue, recrutement ou services nécessitent des duplications manuelles et créent des incohérences. Détection et mesure. Transformez la feuille de route des 24 prochains mois en exigences : volumes, rôles, workflows, données, langues, intégrations, performance et conformité. Estimez le coût de l’ajout sur l’existant et sur un socle adapté.
Décision. Ajoutez un module si le besoin est isolé. Refonte d’architecture lorsque plusieurs priorités stratégiques sont bloquées par les mêmes limites. Action : prioriser avec la méthode « indispensable, important, souhaitable, hors périmètre ».
Faut-il optimiser ou refaire son site ? Une matrice qualitative
Pour chaque problème, attribuez quatre appréciations documentées, sans fabriquer un total : gravité (gêne ou blocage), étendue (une page ou tout le site), enjeu métier (page secondaire ou revenu principal) et réparabilité (correction indépendante ou limite du socle). Conservez les preuves : URL, capture, métrique, témoignage et coût estimé.
| Situation observée | Décision probable | Exemple |
|---|---|---|
| Localisée, mesurable et réparable sans effet de bord | Optimisation | Images lourdes, formulaire trop long, titres imprécis |
| Plusieurs gabarits ou parcours touchés, socle encore sain | Refonte partielle | Navigation, design system, modèles de services |
| Défaut critique urgent | Sécuriser d’abord | Piratage, HTTPS cassé, pages de vente désindexées |
| Limites transversales et non réparables à coût raisonnable | Refonte complète à étudier | CMS abandonné, architecture incompatible, dette généralisée |
Prioriser les corrections avant de signer une refonte
| Action | Priorité habituelle | Impact potentiel | Difficulté |
|---|---|---|---|
| Stopper une faille, restaurer HTTPS, retirer un blocage d’indexation | Immédiate | Critique | Variable |
| Réparer contact, achat ou réservation | Très haute | Revenu | Faible à moyenne |
| Clarifier offre, zone, preuve et CTA | Haute | Conversion | Faible |
| Corriger un gabarit mobile / Core Web Vitals | Haute | UX et visibilité | Moyenne |
| Changer uniquement le style visuel | Selon preuve | Variable | Moyenne |
| Migrer de CMS | Seulement si justifié | Structurel | Élevée |
Une refonte peut-elle faire perdre le référencement ? Oui, si la migration est mal conduite
Une refonte n’améliore pas automatiquement le SEO. En changeant simultanément design, CMS, URLs, contenu, liens et rendu, vous modifiez ce que les moteurs connaissent. Google précise que des fluctuations sont normales pendant un déplacement de site et recommande de changer une chose à la fois lorsque c’est possible. Le risque le plus fréquent n’est pas « le nouveau design » : c’est la perte d’URLs, de contenu, de liens internes, de signaux canoniques ou de capacité d’exploration.
Avant la migration
- Crawler et exporter toutes les URLs, codes HTTP, titres, descriptions, H1, canoniques, liens et données structurées.
- Exporter Search Console, analytics, conversions, pages d’entrée, requêtes et backlinks importants.
- Conserver les URLs performantes quand aucun changement n’est nécessaire.
- Créer une correspondance ancienne URL → nouvelle page équivalente.
- Tester sur une préproduction protégée de l’indexation, jamais bloquée aux testeurs.
Au lancement et après
- Mettre des redirections serveur permanentes 301 ou 308, directes, sans chaîne.
- Mettre à jour liens internes, canonicals, hreflang, sitemap XML et données structurées.
- Vérifier robots.txt et retirer tout
noindexde préproduction. - Conserver Search Console et analytics ; annoter la date de mise en ligne.
- Crawler, tester les formulaires, surveiller 404, indexation, Core Web Vitals, trafic et conversions.
Le processus rationnel d’une refonte de site TPE
- Cadrer : objectifs métier, publics, priorités et indicateurs de réussite.
- Auditer : UX, contenu, SEO, performance, accessibilité, sécurité, données et maintenance.
- Décider : conserver, optimiser, refondre une partie ou migrer le socle ; chiffrer chaque option.
- Concevoir : architecture, contenus et prototypes testés avant la couche graphique.
- Construire : composants accessibles, HTML initial lisible, responsive, performance budgétée.
- Migrer : URLs, contenus, médias, métadonnées, schémas et redirections.
- Recetter : fonctions, appareils, navigateurs, accessibilité, SEO, analytics et sécurité.
- Suivre : comparer trafic, indexation, conversions, erreurs et Core Web Vitals sur plusieurs semaines.
Ce qu’un dirigeant doit retenir
Ne refaites pas un site parce qu’il a trois, cinq ou huit ans. Refaites-le lorsque des preuves montrent que son socle empêche durablement de servir les utilisateurs, d’être compris, de convertir, d’être maintenu ou d’accompagner l’entreprise — et que réparer coûterait presque aussi cher sans résoudre la cause. Dans les autres cas, une série d’optimisations mesurées est souvent plus rapide, moins risquée et moins coûteuse.
FAQ sur la refonte de site internet
Comment savoir si mon site est dépassé ?
Ne jugez pas son âge : testez les parcours mobiles, les conversions, l’indexation, les Core Web Vitals, l’accessibilité, la sécurité et le temps nécessaire pour l’administrer. Un site est dépassé lorsqu’il ne remplit plus ses fonctions ou ne peut plus être corrigé raisonnablement.
Quand faut-il refaire un site internet ?
Quand plusieurs limites structurelles touchent les pages et parcours essentiels, bloquent les objectifs métier et ne peuvent être corrigées indépendamment. Une faille ou une désindexation exige une action urgente, mais pas nécessairement une refonte complète.
Combien de temps garder un site ?
Il n’existe pas de durée universelle. Un site bien maintenu peut évoluer longtemps ; un site récent peut être inadéquat dès son lancement. Réalisez un contrôle léger chaque trimestre et un audit plus large lors d’un changement d’offre, de marché ou de technologie.
Faut-il refaire ou optimiser son site ?
Optimisez si le problème est local, mesurable et réparable. Choisissez une refonte partielle si plusieurs gabarits ou parcours doivent changer, mais que le socle reste fiable. Étudiez une refonte complète si la technologie, les données ou l’architecture bloquent durablement l’entreprise.
Une refonte fait-elle perdre le référencement ?
Elle peut provoquer une baisse si les URLs, contenus, liens, canoniques, données structurées ou règles d’indexation sont mal migrés. Conserver les URLs utiles, rediriger chaque ancienne page vers une équivalente et contrôler Search Console avant/après réduit le risque, sans garantir l’absence de fluctuations.
Maillage interne recommandé pour Hikaad
- Audit de site internet Hikaad — depuis la matrice de diagnostic.
- Création et refonte de site internet — depuis la partie décision.
- Site internet trop lent : combien de clients perdez-vous ? — depuis le signe n°1.
- Pourquoi votre site apparaît sur Google sans générer de devis ? — depuis le signe n°7.
- WordPress, Webflow, Shopify ou sur mesure ? — depuis les signes n°10 et 11.
- Demander un diagnostic à Hikaad — en conclusion, sans promesse de résultat.
Sources et bibliographie
Lecture des sources : les seuils Core Web Vitals et règles de migration sont des recommandations officielles ; WCAG 2.2 est une norme du W3C ; l’OWASP Top 10 est un référentiel de sensibilisation aux risques ; Nielsen Norman Group fournit des bonnes pratiques fondées sur la recherche UX. Aucun chiffre commercial n’est extrapolé dans cet article.
- Google Search Central, « Understanding Core Web Vitals and Google search results », documentation officielle, consultée le 13 août 2026.
- web.dev, « Web Vitals », seuils LCP, INP et CLS, documentation officielle, consultée le 13 août 2026.
- Google Search Central, « Mobile site and mobile-first indexing best practices », consultée le 13 août 2026.
- Google Search Central, « Understand JavaScript SEO Basics », consultée le 13 août 2026.
- Google Search Central, « How to move a site », guide officiel de migration, consulté le 13 août 2026.
- Google Search Central, « Introduction to robots.txt » et « Block Search indexing with noindex », consultés le 13 août 2026.
- Google Search Central, « Learn about sitemaps » et « Canonicalization », consultés le 13 août 2026.
- Google Search Central, « Introduction to structured data markup », consultée le 13 août 2026.
- Chrome for Developers, « Introduction to Lighthouse », mise à jour 2 juin 2025, consultée le 13 août 2026.
- W3C Web Accessibility Initiative, « WCAG 2 Overview » et « How to Meet WCAG 2.2 », norme et techniques, consultées le 13 août 2026.
- OWASP Foundation, « OWASP Top 10:2025 » et « A03 Software Supply Chain Failures », consultés le 13 août 2026.
- Mozilla Developer Network, « Mixed content », documentation sécurité, mise à jour 30 novembre 2025, consultée le 13 août 2026.
- CNIL, « Cookies : solutions pour les outils de mesure d’audience », 4 juillet 2025, consultée le 13 août 2026.
- Huei-Hsin Wang, Nielsen Norman Group, « Few Guesses, More Success: 4 Principles to Reduce Cognitive Load in Forms », 18 juillet 2025.
- Jakob Nielsen, Nielsen Norman Group, « Usability 101: Introduction to Usability », 3 janvier 2012, révisé le 15 juillet 2026.