Un site peut sembler terminé et rester impropre à la publication. Un bouton peut mener au mauvais endroit, un formulaire peut envoyer les demandes à une adresse oubliée, une ancienne URL peut disparaître ou une information importante peut encore être erronée.

La recette finale ne consiste donc pas à demander à tout le monde de « jeter un œil ». Elle consiste à attribuer chaque vérification à la bonne personne, dans un ordre défini, avec une règle claire pour distinguer ce qui bloque la mise en ligne de ce qui pourra être amélioré ensuite.

Avant de tester, fixez les règles du jeu

Commencez par réunir une version précise du site, la liste des pages concernées et les accès nécessaires. Évitez de valider des contenus pendant qu’ils changent encore : une recette menée sur une version instable produit surtout de la confusion.

Une personne doit être clairement responsable du feu vert final. Ce n’est pas forcément le développeur. Il peut s’agir du dirigeant, du responsable marketing ou d’une personne désignée côté client. Les autres intervenants vérifient leur périmètre, signalent les anomalies et indiquent les corrections à effectuer, mais une seule personne tranche lorsque tout le monde n’a pas le même avis.

Définissez aussi trois niveaux simples :

• Bloquant : le site ne peut pas être publié tant que le problème n’est pas corrigé. Exemple : formulaire inutilisable, coordonnées fausses, accès administrateur non transmis ou page essentielle inaccessible.
• À corriger avant publication si possible : le site fonctionne, mais l’expérience ou la compréhension serait nettement dégradée sans correction.
• À traiter après publication : une amélioration utile, mais qui ne compromet ni le parcours principal ni l’exactitude des informations publiées.

Le client valide ce qui engage son activité

Le client ou le responsable métier est le mieux placé pour confirmer que le site dit juste. Il vérifie notamment les textes liés à l’offre, les tarifs lorsqu’ils sont affichés, les coordonnées, les horaires, les zones d’intervention et les appels à l’action.

Cette vérification doit se faire page par page, pas seulement depuis la page d’accueil. Contrôlez la cohérence entre les différentes présentations d’un même service : un intitulé, une adresse ou une promesse qui change d’une page à l’autre peut semer le doute chez le visiteur.

Le responsable métier vérifie également :

• les images utilisées et leur adéquation avec l’activité ;
• les crédits ou mentions nécessaires lorsque des visuels, textes ou documents ne sont pas produits en interne ;
• les coordonnées affichées dans le pied de page, les pages de contact et les boutons ;
• les mentions légales, la politique de confidentialité et les informations réglementaires prévues pour le projet.

Ces éléments doivent être examinés selon le pays, l’activité et les données collectées. Une recette éditoriale ne remplace pas une vérification juridique lorsque le contexte le nécessite.

Le rédacteur vérifie la cohérence du parcours

Le rédacteur ou la personne responsable des contenus ne se limite pas aux fautes d’orthographe. Son rôle est aussi de vérifier que le visiteur comprend où il se trouve, ce qu’on lui propose et quelle action il peut effectuer ensuite.

La relecture porte sur les titres, les sous-titres, les boutons, les légendes, les messages de confirmation et les documents téléchargeables. Les liens internes doivent conduire vers la page annoncée, les liens externes doivent fonctionner et les menus doivent reprendre les parcours réellement attendus.

Parcourez le site comme un visiteur qui ne connaît pas l’organisation. Depuis une page de service, peut-il demander un devis ? Depuis un article, peut-il retrouver l’offre concernée ? Depuis le pied de page, peut-il accéder aux informations utiles ? Un site peut être techniquement fonctionnel tout en laissant ses visiteurs chercher leur chemin.

Pour les contrôles d’usage, quelques essais ciblés suffisent souvent à repérer un problème important : lisibilité sur petit écran, navigation au clavier et libellés compréhensibles dans les formulaires. Pour aller plus loin, consultez aussi ce rappel pratique sur le test d’une page sans souris.

L’intervenant technique vérifie le fonctionnement réel

La validation technique intervient après la stabilisation des contenus, mais avant le feu vert final. Elle ne consiste pas à reprendre toutes les étapes de maintenance ou de sécurité de WordPress. Elle vise les éléments qui doivent fonctionner au moment de la publication.

Liens, menus et documents

Testez les menus, les boutons, les liens présents dans les textes et les liens vers les fichiers téléchargeables. Ouvrez réellement les documents : un bouton qui répond mais renvoie vers un fichier absent n’est pas validé.

Formulaires et demandes entrantes

Envoyez plusieurs demandes de test. Vérifiez la réception du message à la bonne adresse, le contenu transmis, le message affiché à l’utilisateur après l’envoi et le comportement prévu en cas d’erreur.

Le responsable du projet doit aussi savoir qui traite ces demandes et dans quel outil elles arrivent. Si le formulaire collecte des données ou s’appuie sur un service tiers, les informations affichées au visiteur et les règles applicables doivent être vérifiées pour le projet concerné. Ne considérez pas un formulaire comme validé simplement parce qu’un message de confirmation apparaît à l’écran.

Affichage et accès

Regardez les pages sur ordinateur et sur mobile, à plusieurs largeurs d’écran, avec les principaux navigateurs utilisés par votre public. Vérifiez en priorité les pages d’entrée, les formulaires, les menus, les tableaux, les images et les appels à l’action.

La liste des navigateurs et appareils n’a pas besoin d’être universelle : elle doit correspondre à l’audience réelle et, si possible, aux données disponibles sur l’ancien site.

Comptes, outils et redirections

Avant publication, identifiez les accès à transmettre : administration WordPress, hébergement, nom de domaine, outils de mesure, messagerie ou services connectés. Les identifiants ne doivent pas circuler dans un document partagé sans protection. Prévoyez une méthode de transmission adaptée et confirmez que le client sait qui possède quel accès.

Si des URL existantes sont remplacées, préparez les redirections correspondantes. Une page supprimée n’est pas seulement un problème technique : elle peut interrompre un lien envoyé à un client, un résultat de recherche ou un parcours depuis un document ancien.

Une checklist courte, avec un responsable par ligne

Un tableau de recette n’a pas besoin de devenir un inventaire interminable. Il doit permettre de répondre à quatre questions : que vérifie-t-on, qui le fait, quel est le statut et que faut-il corriger ?

Point contrôlé	Responsable	Statut attendu	Priorité
Coordonnées, offres et appels à l’action	Client	Validé	Bloquant si incorrect
Textes, titres et cohérence des parcours	Rédacteur	Relu	Bloquant si incompréhensible
Menus, boutons et liens	Intervenant technique	Testé	Bloquant si parcours essentiel interrompu
Formulaires et réception des demandes	Technique + client	Test réel effectué	Bloquant
Affichage mobile et ordinateur	Technique	Contrôlé	Bloquant si page inutilisable
Mentions et informations de confidentialité	Client	Validé pour le projet	À vérifier avant publication
Accès et redirections	Technique + client	Transmis et vérifié	Bloquant selon le périmètre

Ajoutez à chaque ligne un commentaire précis lorsqu’il reste une correction : « remplacer l’adresse du pied de page » est exploitable ; « à revoir » ne l’est pas. Une personne doit ensuite reprendre les corrections et remettre le statut à jour.

Le feu vert doit être explicite

Lorsque les corrections bloquantes sont terminées, le responsable désigné confirme par écrit la version validée, la date et le périmètre concerné. Cette trace peut être simple : un message indiquant que les contenus, les parcours principaux et les contrôles techniques prévus ont été vérifiés.

La publication ne clôt pas totalement la recette. Juste après la mise en ligne, refaites un contrôle ciblé des pages importantes : accueil, contact, formulaire principal, pages de services, menus et éventuelles redirections. Ce n’est pas le moment de recommencer tous les tests, mais de vérifier que la version réellement publiée correspond bien à celle qui a reçu le feu vert. Les tests de mise en ligne doivent d’ailleurs être distingués des essais effectués directement sur un site en production, comme l’explique cet article sur le fait qu’une mise à jour WordPress ne se teste pas en ligne.

Un site est prêt quand les bonnes personnes ont validé les bons éléments, que les blocages sont levés et qu’une décision claire a été prise. La qualité de la mise en ligne dépend moins d’une checklist parfaite que de cette répartition : le client engage le fond, le rédacteur sécurise la compréhension, l’intervenant technique vérifie le fonctionnement, et un responsable assume le dernier feu vert.