Tous les articles
Pratique5 min de lecture

Refonte de site : ce qu’il faut vérifier avant la validation

Un nouveau site exige plus qu’un design convaincant. Cette liste de contrôle aide les PME suisses à vérifier contenus, moyens de contact, affichage mobile et accès aux moteurs de recherche avant la mise en ligne.

Composition de couleurs abstraite de Pribbly
Dans cet article

À quoi faut-il mesurer le nouveau site ?

Un nouveau design se juge vite au goût. Pour la validation, il faut en plus une tâche qu’un visiteur doit réellement accomplir : trouver un service adapté, demander une offre ou choisir un rendez-vous. Formulez cette tâche en une phrase avant la réception.

Pour un prestataire local, elle pourrait être : un prospect voit si sa demande correspond à l’offre, trouve le bon moyen de contact et peut envoyer une demande. C’est un exemple de travail, pas un résultat client mesuré. Une belle capture d’écran ne prouve pas encore que ce chemin fonctionne.

Une fiche de validation réellement utilisable

Nous recommandons une fiche commune avec les six contrôles suivants. Chaque ligne comporte un responsable et une preuve visible, comme un lien testé ou une demande test reçue. Ces critères sont notre propre outil de travail pour la réception.

Une fiche de validation réellement utilisable
Point de contrôleTest concretFait avant la mise en ligne
OffreUne personne compétente relit les pages de prestations et les conditions.Le périmètre des prestations et ses limites correspondent à l’offre réelle.
ContactEnvoyer une demande marquée comme test via le canal convenu.La demande arrive au bon endroit ; les messages d’erreur sont compréhensibles.
Rendez-vousParcourir le chemin de réservation jusqu’à l’étape de test convenue.Agenda, fuseau horaire et confirmation concordent ; les rendez-vous test sont ensuite supprimés.
Affichage mobileUtiliser le menu, une page de prestation et le moyen de contact sur smartphone.Les contenus et actions importants sont accessibles et ne sont pas masqués.
Liens existantsOuvrir les anciennes adresses importantes de prestations et de campagnes.Chaque adresse reste accessible ou mène au nouveau contenu correspondant.
ExploitationNoter qui est responsable des modifications, demandes et pannes.Accès et responsabilités sont clarifiés.

Sur smartphone, c’est l’utilisation qui compte, pas la maquette

Vérifiez aussi le site en dehors de l’aperçu de design. Ouvrez le menu, lisez une page de prestation et utilisez le moyen de contact sur un vrai smartphone. Soyez attentif aux messages qui n’apparaissent qu’après une saisie : un message d’erreur compréhensible peut compter davantage qu’une animation de plus.

Pour les contenus ordinaires lus verticalement, les WCAG 2.2 indiquent une largeur de 320 pixels CSS à laquelle informations et fonctions doivent rester disponibles sans défilement dans deux directions. Il existe des exceptions pour des contenus comme les tableaux de données. Testez donc aussi un affichage étroit et un texte agrandi ; une seule capture mobile ne suffit pas.

Pour un texte normal, le critère WCAG de contraste minimal exige au moins 4,5:1, et 3:1 pour un texte suffisamment grand. Un titre n’est pas automatiquement assez grand pour la valeur inférieure. Vérifiez en particulier les textes sur photos et les libellés de formulaires. Ces contrôles couvrent une partie de l’accessibilité, pas une preuve complète de conformité.

Sources : W3C : redistribution en affichage étroit et agrandissement · W3C : contraste minimal selon les WCAG 2.2

Vérifier séparément temps de chargement et réactivité

Une animation peut paraître calme et pourtant retarder les saisies. Vérifiez donc à la fois le premier chargement et la réaction du menu, des boutons et des formulaires. Pour les vidéos et les grandes images, un essai avec une connexion plus lente vaut aussi la peine.

Pour de bons Core Web Vitals, Google indique un LCP de 2,5 secondes au plus, un INP de 200 millisecondes au plus et un CLS de 0,1 au plus. L’évaluation porte sur le 75e centile des affichages réels, séparément pour mobile et ordinateur.

Avant la mise en ligne, les tests en laboratoire et vos propres essais d’utilisation aident à repérer des faiblesses concrètes. Après le lancement, vous les complétez par les données de terrain disponibles. Un score Lighthouse isolé ne prouve pas que les vrais visiteurs atteignent les trois valeurs cibles. Notez dans la fiche de validation la mesure disponible et ce qui reste à observer.

Sources : web.dev: Web Vitals

Préserver les chemins existants en cas de nouvelles adresses

Si les URL changent lors d’une refonte, Google recommande d’associer les anciennes adresses aux nouvelles correspondantes et d’utiliser des redirections permanentes côté serveur, par exemple 301 ou 308. Liens internes, balises canonical et sitemap doivent utiliser les nouvelles adresses. Rediriger en bloc de nombreuses anciennes pages vers l’accueil n’est pas une solution propre.

Rassemblez pour cela les principales pages de prestations existantes ainsi que les liens issus des annonces, e-mails et imprimés. Ouvrez-les de nouveau après le changement. Un simple changement de design avec des URL inchangées ne nécessite pas de redirections globales.

Sources : Google : migration de site avec modification des URL

Vérifier si le site public peut être trouvé

Un environnement de test peut être volontairement protégé. Sur les pages publiques, les paramètres doivent correspondre à l’accès souhaité pour les moteurs de recherche. Vérifiez en particulier qu’une protection par mot de passe, un blocage des robots ou une directive noindex n’ont pas été repris par erreur.

Google cite comme exigences techniques minimales un Googlebot non bloqué, une page fonctionnelle avec le statut HTTP 200 et des contenus indexables. L’outil d’inspection d’URL de la Search Console aide à contrôler des pages individuelles. Remplir ces conditions ne garantit ni l’indexation ni un positionnement précis.

Sources : Google : exigences techniques pour la recherche

Ce qui bloque la validation et ce qui peut attendre

Un périmètre de prestations erroné, un contact injoignable ou un bouton de réservation masqué doivent être corrigés avant la mise en ligne. Une variante d’image supplémentaire peut en revanche attendre une étape d’amélioration ultérieure. L’essentiel est de savoir si un problème empêche la tâche convenue ou fausse le contenu.

Prévoyez juste après la publication un nouveau contrôle des parcours les plus importants. Le contrôle dans l’aperçu et celui sur le vrai domaine sont deux étapes distinctes. Notez les améliorations en suspens avec un responsable pour qu’elles ne disparaissent pas après la mise en ligne.

  • Valider : la tâche visiteur convenue fonctionne sur le vrai domaine.
  • Corriger : un problème bien délimité empêche cette tâche ; après correction, retester le même chemin.
  • Redéfinir : l’offre, le public cible ou le processus de réservation sont encore flous. Clarifier d’abord la mission.

Comment le contrôle s’articule avec les offres web de Pribbly

Pribbly propose des sites web comme prestation à la carte et la création initiale du site dans ses forfaits mensuels. Dans les forfaits, le site d’entreprise est créé au démarrage ; ensuite sont prévues la maintenance technique et des modifications de contenu mensuelles limitées. Il ne s’agit donc pas d’un nouveau site chaque mois. L’offre séparée Website Premium 3D de la boutique ne fait pas automatiquement partie d’un forfait mensuel.

Pour une offre, notez donc quelles pages seront créées, quel parcours de contact ou de réservation les accompagne et quel suivi sera nécessaire ensuite. La fiche de validation aide à concrétiser ces points lors de l’entretien.

Cet article pratique a été rédigé avec l’aide de l’IA. Sources, affirmations et lien avec le catalogue Pribbly ont été vérifiés automatiquement avant publication. La liste de contrôle ne remplace pas l’examen d’un site client concret.

Sources et état

Votre entreprise dans le showroom.

Découvrez un nouveau projet pour votre présence, avec votre marque et votre offre.

Découvrir votre propre présence

Plus de Pribbly.