Un site peut sembler terminé et échouer dès qu’un visiteur essaie de faire quelque chose de simple : comprendre l’offre, trouver une information, envoyer une demande ou consulter une page sur mobile. La recette sert précisément à éviter cette livraison en trompe-l’œil.

Il s’agit de valider le site à partir de scénarios réels, avec des résultats observables. Chaque contrôle doit répondre à trois questions : que teste-t-on, quel résultat attend-on et que se passe-t-il si le test échoue ?

La recette se prépare idéalement sur une version de préproduction, avant la mise en ligne, puis se rejoue après les changements finaux. Une correction de dernière minute peut modifier un formulaire, un menu ou une redirection. Ce qui a été validé hier ne l’est donc pas forcément encore aujourd’hui.

Commencer par les parcours, pas par la page d’accueil

Avant d’ouvrir une liste de contrôles, identifiez les actions qui comptent réellement pour ce site. Elles varient selon le projet : demander un devis, prendre rendez-vous, acheter, consulter un catalogue, trouver une adresse ou appeler l’entreprise.

Jouez ces parcours comme un visiteur qui ne connaît pas le site. Depuis une page d’entrée, pouvez-vous comprendre ce que propose l’entreprise ? Trouver l’information attendue ? Identifier la prochaine action ? Revenir en arrière sans vous perdre ?

Résultat attendu : chaque parcours critique aboutit à l’action prévue, sans lien cassé, impasse ni information contradictoire.

Priorité : bloquant avant livraison. Si le parcours principal ne mène pas à la bonne action, les autres qualités du site ne compensent pas ce défaut.

Notez chaque anomalie dans un document partagé, avec la page concernée, les étapes pour la reproduire, le résultat observé et la correction attendue. Une capture peut aider, mais elle ne remplace pas la description du scénario.

Vérifier les contenus comme un visiteur pressé

Un site livré doit contenir les bonnes pages, pas seulement des maquettes bien remplies. Parcourez l’arborescence et vérifiez que les contenus prévus sont présents : pages de services, informations pratiques, coordonnées, tarifs ou modalités lorsqu’ils font partie du projet.

Relisez les textes dans leur contexte final. Un titre peut être correct dans un document et devenir trompeur lorsqu’il est affiché dans un menu ou une carte. Contrôlez aussi les dates, noms, adresses e-mail, numéros de téléphone et horaires. Les coordonnées du pied de page, de la page Contact et d’un formulaire doivent correspondre.

Testez les liens internes et externes en cliquant réellement dessus. Vérifiez également les liens présents dans les boutons, les images, les menus et les mentions prévues par le projet. Un lien qui s’ouvre dans un nouvel onglet sans indication claire, ou qui renvoie vers une ancienne adresse, peut perturber le parcours.

Les éléments légaux nécessaires dépendent du site, de son activité et de ses fonctionnalités. Ils doivent être identifiés avec les personnes responsables du projet, puis vérifiés avant livraison. Il ne s’agit pas de recopier un modèle générique sans contrôler sa pertinence.

Résultat attendu : les pages prévues sont publiables, les informations sont cohérentes, les liens aboutissent au bon endroit et les contenus temporaires ont disparu.

Priorité : bloquant avant livraison pour une information fausse, une page manquante sur un parcours essentiel ou un lien qui empêche une action. Les corrections typographiques secondaires peuvent relever d’une priorité importante plutôt que d’un blocage immédiat.

Tester l’affichage sur les écrans prévus

Un aperçu sur l’ordinateur du concepteur ne suffit pas. Testez les pages représentatives sur mobile, tablette et ordinateur, avec les navigateurs prévus dans le périmètre du projet. Inutile de multiplier les combinaisons sans objectif : choisissez des situations qui couvrent les usages réels.

Commencez par les points qui cassent le plus facilement :

• le menu s’ouvre, se ferme et reste utilisable ;
• les boutons sont visibles et activables ;
• les titres et les paragraphes ne débordent pas ;
• les images et vidéos ne déforment pas la page ;
• les tableaux restent lisibles ou proposent une présentation adaptée ;
• les fenêtres contextuelles peuvent être fermées ;
• les contenus longs ne masquent pas une action importante.

Faites défiler les pages et essayez les interactions, plutôt que de vous contenter d’une capture d’écran. Un élément peut sembler bien placé au chargement puis recouvrir un bouton, pousser un formulaire hors écran ou rendre la navigation difficile après une action.

Résultat attendu : les pages restent lisibles et utilisables dans les formats prévus, sans débordement ni action inaccessible.

Priorité : bloquant avant livraison lorsqu’un contenu ou une action essentielle est inaccessible. Un léger défaut d’espacement, s’il ne gêne pas l’usage, peut être classé comme amélioration.

Faire passer les formulaires de bout en bout

Voir un formulaire à l’écran ne prouve pas qu’il fonctionne. Remplissez-le avec des données valides, puis avec des données manquantes ou incorrectes. Vérifiez les intitulés, les champs obligatoires, les messages d’erreur et la conservation des informations déjà saisies lorsqu’une correction est demandée.

Allez jusqu’au bout du scénario : cliquez sur Envoyer, observez le message affiché, contrôlez la réception dans la bonne boîte et vérifiez l’adresse utilisée pour l’expédition. Si un accusé de réception est prévu, testez son contenu et son destinataire. Pour un formulaire de devis, vérifiez aussi que les informations transmises permettent bien de traiter la demande.

Effectuez ce test avec les protections contre les soumissions indésirables prévues par le projet, sans les désactiver définitivement pour aller plus vite. Contrôlez enfin ce qui est conservé, pendant combien de temps selon les règles définies pour le site, et qui peut y accéder. Les modalités liées aux données doivent être validées avec le responsable du projet.

Un scénario détaillé permet d’aller plus loin que le simple « formulaire visible » : l’article Votre formulaire peut perdre des prospects complète ce contrôle sur les erreurs qui interrompent une demande.

Résultat attendu : une saisie correcte arrive au bon destinataire, une saisie incorrecte est expliquée clairement et l’utilisateur sait ce qui se passe après l’envoi.

Priorité : bloquant avant livraison si l’envoi échoue, n’est pas reçu ou affiche une confirmation trompeuse. Une amélioration de formulation peut attendre si le parcours reste compréhensible et fiable.

Contrôler l’accessibilité dans les usages courants

La recette n’a pas besoin de devenir un audit complet pour repérer des obstacles évidents. Parcourez les pages au clavier : pouvez-vous atteindre le menu, les liens, les boutons et les champs ? Le focus reste-t-il visible ? L’ordre de navigation suit-il une logique compréhensible ?

Vérifiez ensuite les intitulés des champs, la structure des titres, les alternatives des images informatives et la compréhension des messages d’erreur. Un message comme « champ invalide » n’aide pas beaucoup si l’utilisateur ne sait pas quoi corriger. Contrôlez aussi que le contraste permet de lire les textes et d’identifier les éléments interactifs dans les situations prévues.

Ce contrôle ciblé ne remplace pas un examen plus approfondi lorsque le site a un niveau de risque ou un public particulier. Pour le test au clavier, voir aussi Votre page passe-t-elle le test sans souris ?

Résultat attendu : les fonctions essentielles restent accessibles au clavier, les champs sont compréhensibles et les messages permettent de corriger une erreur.

Priorité : bloquant avant livraison lorsqu’un parcours essentiel est impossible à utiliser ou qu’un élément interactif est inaccessible. Les améliorations de confort peuvent être classées comme importantes ou facultatives selon le public concerné.

Observer la performance sans confondre score et diagnostic

La performance se juge aussi dans les parcours réels. Ouvrez les pages principales sur mobile, observez le temps avant que le contenu utile apparaisse et essayez les interactions importantes. Repérez les images inutilement lourdes, les médias qui se lancent sans raison, les scripts qui retardent l’affichage ou les éléments qui se déplacent pendant le chargement.

Comparez les pages entre elles : une page d’accueil très chargée, une page de service, un article et une page contenant un formulaire peuvent rencontrer des problèmes différents. Un score technique peut signaler un symptôme, mais il ne dit pas forcément quelle étape gêne le visiteur. Le score ne dira pas pourquoi votre site est lent rappelle cette distinction.

Résultat attendu : les pages prioritaires chargent leur contenu utile dans des conditions cohérentes avec les usages prévus, sans ralentissement évident qui empêche l’action.

Priorité : important dans la plupart des projets, et bloquant avant livraison si la lenteur empêche de consulter une page, d’utiliser un formulaire ou de poursuivre un parcours essentiel. Aucun score isolé ne doit décider seul de la livraison.

Vérifier les fondamentaux techniques du référencement

Le site doit être vérifié dans l’état prévu pour sa mise en ligne. Contrôlez que les pages destinées à être trouvées peuvent être explorées et que les pages qui ne doivent pas l’être sont traitées conformément au projet. Une page importante ne doit pas être bloquée par une consigne oubliée ou une configuration de préproduction.

Relisez les titres de pages et les descriptions prévus, vérifiez les URL finales et repérez les anciennes adresses qui doivent rediriger. Contrôlez les balises canoniques lorsqu’elles sont nécessaires au projet, ainsi que le sitemap et les réglages liés à l’indexation. Vérifiez enfin l’aperçu d’un lien partagé : titre, image et description doivent correspondre à la page concernée.

Ces contrôles portent sur les fondamentaux, pas sur une promesse de positionnement. Le contenu, la concurrence et de nombreux autres facteurs dépassent la recette de livraison.

Résultat attendu : les URL finales sont cohérentes, les pages importantes sont accessibles à l’exploration prévue et les aperçus de partage ne présentent pas de contenu provisoire.

Priorité : bloquant avant livraison pour une indexation accidentellement empêchée, une URL principale inaccessible ou une redirection indispensable absente. Les ajustements éditoriaux peuvent être importants sans empêcher toute mise en ligne.

Sécuriser la mise en ligne et la reprise

Avant livraison, vérifiez les accès nécessaires : compte d’administration, hébergement, domaine, messagerie liée au site et services utilisés par les formulaires ou les statistiques. Le client ou l’équipe qui reprend le site doit savoir quels comptes existent et comment les gérer.

Contrôlez également que les sauvegardes prévues fonctionnent et qu’une restauration a été envisagée dans un environnement adapté. Une sauvegarde simplement activée n’est pas une preuve qu’elle pourra être utilisée au bon moment. L’article Une sauvegarde WordPress ne suffit pas complète ce point.

Enfin, vérifiez les mises à jour réalisées avant la livraison, les extensions réellement nécessaires et les réglages propres à la production. La méthode dépend du site et de son niveau de risque : il n’existe pas une configuration universelle à appliquer sans examen.

Résultat attendu : les accès utiles sont identifiés, le site peut être administré par les bonnes personnes et la stratégie de sauvegarde prévue a été contrôlée de façon réaliste.

Priorité : bloquant avant livraison si personne ne peut reprendre le site, si un accès critique manque ou si aucune solution de restauration crédible n’est prévue. Les optimisations de gestion peuvent être traitées ensuite.

Décider avec une fiche de recette simple

Pour chaque test, consignez au minimum :

• le parcours ou la page concernée ;
• l’action réalisée ;
• le résultat attendu ;
• le résultat observé ;
• la priorité : bloquant avant livraison, important ou amélioration ;
• la personne chargée de la correction et la date du nouveau test.

Ne validez pas une rubrique parce qu’elle a été regardée. Validez-la lorsque le résultat attendu est obtenu et que le test peut être rejoué. Une anomalie bloquante doit empêcher la livraison ; une anomalie importante doit être planifiée clairement ; une amélioration peut être conservée dans une liste séparée pour ne pas masquer les urgences.

Cette méthode ne remplace pas un audit spécialisé lorsque le site présente des enjeux élevés, des fonctionnalités complexes ou des exigences particulières. Elle évite toutefois une erreur fréquente : confondre une apparence aboutie avec un site réellement utilisable, transmissible et prêt à être mis entre les mains de ses visiteurs.