Recette avant mise en ligne d’un site WordPress : la méthode, les tests, la décision

Votre site WordPress est "presque prêt", et quelqu’un vient de prononcer le mot recette ? Tapez "recette site web" dans Google : fin septembre 2026, Marmiton figurait parmi les vingt premiers résultats, au milieu des agences web… Le mot fait sourire. L’étape, elle, décide si votre site peut ouvrir.

Je dis bien décide. Une recette reprend le cahier des charges point par point, puis tranche : on ouvre, ou on n’ouvre pas.

Voici comment je la mène, et ce que WordPress vous fera oublier si vous n’y prenez pas garde. Vous trouverez aussi les commandes que j’ai fait exécuter pour le vérifier, et mon modèle de cahier de recette, à télécharger en Word et en PDF.

Qu’est-ce que la recette d’un site web ?

La recette d’un site web est la phase où le client et le prestataire vérifient ensemble que le site livré correspond à ce qui a été commandé, avant sa mise en ligne. On contrôle chaque promesse du cahier des charges, on note chaque écart. La recette se termine par une décision : accepté, accepté avec réserves, ou refusé.

Recette site web, recettage, UAT : trois mots, une seule étape

Recette, recettage : les deux mots désignent la même étape. En anglais, vous lirez UAT, pour user acceptance testing, le test d’acceptation par l’utilisateur. L’idée est dans le nom : celui qui accepte est celui qui va se servir du site.

Le cahier de recette est le document qui porte tout cela. Mon modèle, en Word et en PDF, se télécharge dans ce guide.

Pourquoi une check-list ne suffit pas

Une check-list dit quoi regarder. Elle ne dit pas qui décide, par rapport à quel document, ni ce qu’on fait d’un point qui ne passe pas.

La recette, si. Sa référence est le cahier des charges : le site est conforme, ou non, à ce qui était écrit. Dans mon modèle de cahier des charges de site web, la rubrique 12 s’appelle "Recette et critères de validation". Elle tient en quelques lignes à remplir.

• "Liste des points à vérifier avant mise en ligne" ;
• "Qui valide, côté client" ;
• "Délai de recette accordé après livraison" ;
• "Modalités de correction des éventuels défauts".

La recette est le jour où ces quatre lignes servent. Restées vides à la signature, elles se rempliront dans l’urgence, chacun à son avantage… Je ne réexplique pas ici le cahier des charges : ce guide commence là où il s’arrête, et transforme ses promesses en tests.

Qui fait la recette, quand, et combien de temps ?

La recette commence chez le prestataire, qui contrôle son propre travail. Puis le client valide, avec lui, que le site respecte le cahier des charges. Côté calendrier, gardez au moins deux jours ouvrés avant la date d’ouverture. C’est le minimum que donne la documentation de WordPress VIP, un hébergeur WordPress pour grands comptes.

Ce que je fais avant d’ouvrir un site au public

Avant d’ouvrir un site au public, je fais un passage manuel, puis je le soumets à une ou deux personnes pour vérification.

Je fais aussi plusieurs contrôles par l’IA, en lui précisant de nombreux points. Par exemple : tester tous les formulaires et toutes les fonctionnalités du site. L’IA prend également, à ma demande, différentes captures d’écran, dont je lui fais faire une analyse détaillée.

Je fais moi aussi beaucoup de captures d’écran, que je soumets une fois à Codex, une fois à Claude Code.

Au total, on n’est pas loin de quatre à cinq vérifications avant l’ouverture au public. Les mêmes captures sont donc lues deux fois, par deux IA différentes.

La recette avec le client

Celui qui valide, en général, c’est le donneur d’ordre, avec moi. Nous reprenons tous les éléments point par point. Nous vérifions ensemble que le site respecte bien le cahier des charges et, une fois que tout est bon, on valide.

Pour la durée, voici ce que prévoit ma feuille de route pour un site vitrine en préparation (qui n’est pas un WordPress, j’y reviens). Deux à trois jours pour la recette et ses contrôles, puis un à deux jours pour la mise en production.

Le client a sa part. Le cahier des charges du même projet prévoit qu’il teste le site de travail, transmette ses retours et s’efforce de répondre aux demandes de validation dans la semaine.

Où faire la recette d’un site WordPress ?

La recette d’un site WordPress se fait sur un environnement de recette, qu’on appelle aussi préproduction ou staging. C’est une copie complète du site, fermée au public, où l’on teste sans risque. Elle se distingue du site en ligne par un accès protégé par mot de passe, une demande de non-indexation et un type d’environnement déclaré à WordPress.

Un mot de passe, puis la case de non-indexation

Pour un contenu qui doit rester privé, Google demande un mot de passe. Sa documentation l’écrit ainsi : "vous devez le protéger par un mot de passe afin que seuls les utilisateurs autorisés puissent y accéder". Une page en noindex, elle, "reste accessible via un lien".

WordPress a bien une case pour cela, dans Réglages, puis Lecture : "Demander aux moteurs de recherche de ne pas indexer ce site". Depuis la version 5.3, elle ajoute une balise noindex,nofollow dans l’en-tête des pages. C’est une demande, et la documentation de l’écran Lecture le dit elle-même : libre aux moteurs de la respecter.

Sur une installation neuve, cette case n’est pas cochée. À vous de la cocher sur la recette… et de la décocher le jour de l’ouverture ! Depuis WordPress 6.9, l’écran Santé du site signale l’oubli par un message sans ambiguïté : "Les moteurs de recherche sont découragés d’indexer ce site."

Sur le site vitrine en préparation, le site de travail est protégé par un identifiant. Une sonde surveille cette protection à l’envers : elle attend un refus, le code 401. Si elle reçoit un 200, c’est que la protection est tombée.

Dire à WordPress où il se trouve

WordPress distingue plusieurs types d’environnement : local, development, staging et production. Sans réglage, il se croit en production. La constante WP_ENVIRONMENT_TYPE, dans le fichier wp-config.php, le détrompe.

Attention à la valeur development : elle active le mode de débogage si vous ne l’avez pas réglé vous-même. Or la documentation réserve ces outils aux tests en local et à la préproduction. Pour les couper, voyez comment déboguer WordPress.

Sur la recette, déclarez staging. Le jour de l’ouverture, le site doit répondre production. Le WordPress local qui m’a servi de banc d’essai pour cet article (version 7.1.2, le 30 septembre 2026) répond ceci.

$ wp config get WP_ENVIRONMENT_TYPE
local

$ wp config get WP_DEBUG
1

Un site local, débogage actif : rien d’anormal. La même réponse sur le site qui ouvre demain serait une anomalie bloquante.

Un mot sur ces commandes. Elles passent par WP-CLI, l’outil qui sert à gérer WordPress en ligne de commande, et toutes sont en lecture seule. Je ne publie que celles que j’ai fait exécuter, avec leur vraie sortie. Les lignes qui commencent par # sont mes annotations.

Que vérifier pendant la recette d’un site WordPress ?

Une recette complète couvre huit familles de contrôles. Aucune n’est propre à WordPress, mais chacune y a ses tests. Le tableau donne la carte ; les sections qui suivent ne détaillent que ce que WordPress change.

Famille	Ce que la recette vérifie	Le test sur WordPress
Fonctionnel	Chaque fonctionnalité promise marche	Un article créé avec un compte Éditeur, puis Auteur ; chaque formulaire envoyé, et son message reçu
Éditorial	Textes définitifs, liens valides	Recherche du faux texte "Lorem ipsum", brouillons oubliés, page 404
Graphisme et mobile	Conformité aux maquettes	Trois largeurs d’écran, contraste mesuré texte par texte
Référencement	Le site peut être indexé	Case de non-indexation, plan du site, redirections 301
Performance	Les seuils promis sont tenus	Mesure sur la recette, puis sur le vrai domaine
Accessibilité	Le niveau promis, ou imposé	Selon le type d’organisme
Sécurité et technique	Rien d’oublié, rien de trop	Comptes de test, fichiers à la racine, débogage, certificat HTTPS et contenu mixte, sauvegarde restaurée
Juridique	Mentions légales, confidentialité, cookies	Un test par texte

Ce tableau ne dit pas comment régler WordPress. Les permaliens, le thème, les extensions de départ : tout cela relève de mes dix premiers gestes après l’installation et de ma check-list de réglages en quinze points. La recette contrôle l’état final, la veille de l’ouverture.

Fonctionnel et éditorial : les parcours, puis les textes

Pour les tests de fonctionnement, la liste minimale de WordPress VIP fait une bonne base. Elle demande, entre autres, de créer un article avec un compte Éditeur, puis avec un compte Auteur, et de vérifier la recherche, les redirections 301 et l’absence d’erreur JavaScript dans la console du navigateur.

J’insiste sur les rôles. La tentation est de tout tester avec son compte administrateur, qui a tous les droits. Vos rédacteurs n’en auront qu’une partie. Sur le site vitrine en préparation, le test est écrit ainsi : un rédacteur non technique crée et publie une actualité complète, seul, avec un vrai compte de rôle auteur.

Côté textes, quelques commandes débusquent les restes de chantier.

# Du faux texte resté dans un contenu ?
$ wp post list --post_type=any --post_status=any --s="Lorem ipsum" --format=count
1

# Des articles restés en brouillon ?
$ wp post list --post_status=draft --format=count
0

# Des commentaires en attente de modération ?
$ wp comment list --status=hold --format=count
0

Sur mon banc d’essai, la première a trouvé un contenu, et un seul "Lorem ipsum" en ligne suffit à faire amateur !

Graphisme et mobile

La référence, ce sont les maquettes validées. On compare page par page, à plusieurs largeurs d’écran, et on mesure les contrastes.

Vous lirez parfois qu’il faut passer le site au "test d’optimisation mobile" de Google. Google a annoncé son retrait à compter du 1er décembre 2023. Testez sur de vrais téléphones.

Référencement : seulement ce qui se joue à l’ouverture

La recette n’est pas un audit SEO. Pour le fond, j’ai un guide du référencement sur WordPress. Ici, je ne garde que ce qui peut empêcher le site d’exister dans Google le jour où il ouvre.

La case de non-indexation, évidemment. Elle a un effet secondaire. Tant qu’elle est cochée, WordPress désactive son plan du site (il en fournit un, sans extension, depuis la version 5.5), et l’adresse /wp-sitemap.xml répond 404.

Une case décochée ne garantit pas pour autant une page indexable. Une extension, le serveur ou le thème peut encore poser un noindex dans le code de la page, ou dans l’en-tête HTTP X-Robots-Tag, que Google lit aussi. Et la balise canonical, qui indique à Google l’adresse de référence d’une page, peut désigner la préproduction. Sur l’accueil, un article et une page clé, contrôlez donc la réponse publique elle-même.

Viennent les redirections. Si le site en remplace un autre, chaque ancienne adresse doit mener quelque part. De lui-même, WordPress sait rediriger un contenu dont le slug a changé. Pour les adresses d’un ancien site, c’est à vous de fournir le plan de redirections, et de le contrôler. Une ancienne adresse renvoyée vers l’accueil ne produit pas de 404 côté serveur, mais Google peut la traiter comme une fausse erreur 404 ("soft 404") : chaque redirection permanente (301) doit mener au contenu équivalent.

Performance : les seuils du cahier des charges

Pour la vitesse, la recette vérifie les seuils écrits au cahier des charges. Si votre document cite encore le FID, corrigez-le. Depuis le 12 mars 2024, l’INP l’a remplacé parmi les Core Web Vitals de Google. Il mesure le temps que met la page à réagir à une action du visiteur.

Accessibilité : le niveau promis, ou le niveau imposé

Tout dépend de qui vous êtes. L’article 47 de la loi du 11 février 2005 ne vise pas tous les sites. Le tableau résume le texte et la page officielle du RGAA, consultés le 30 septembre 2026.

Qui	Ce que le texte impose	Ce que la recette vérifie
Organismes publics, délégataires d’une mission de service public et organismes privés assimilés	Des services en ligne accessibles, une déclaration d’accessibilité, un schéma pluriannuel, une mention, visible dès la page d’accueil, qui dit si le site est conforme ou non	Audit selon le RGAA (version 4.1.2 à ce jour), déclaration publiée, mention en page d’accueil
Entreprises à partir de 250 millions d’euros de chiffre d’affaires en France, en moyenne sur les trois derniers exercices	Les mêmes obligations	Les mêmes points
Tous les autres sites	Rien au titre de l’article 47	Ce que le cahier des charges a promis

L’article 47-1 de la même loi confie le contrôle à l’Arcom, qui met d’abord en demeure. Chez les organismes publics et assimilés (1° à 3° de l’article 47), elle constate les manquements aux "dispositions des I, III et IV" : l’accessibilité elle-même, puis la déclaration, le schéma et la mention.

Chez les entreprises au-dessus du seuil (4°), le texte ne vise que les "dispositions des III et IV" : la déclaration, le schéma pluriannuel et la mention. Les plafonds suivent la même ligne, 50 000 € pour l’accessibilité et 25 000 € pour ces obligations. L’article 47 demande pourtant, à ces entreprises aussi, des services accessibles.

Hors de l’article 47 : d’abord le commerce en ligne, ensuite le contrat

L’article 47 n’est pas le seul texte. Depuis le 28 juin 2025, l’article L412-13 du Code de la consommation impose aussi l’accessibilité à certains services, dont le commerce électronique. Les entreprises de services de moins de dix personnes en sont dispensées si leur chiffre d’affaires annuel ou le total de leur bilan ne dépasse pas deux millions d’euros. Les autres exceptions se vérifient au cas par cas, mais une boutique WooCommerce au-dessus de ce seuil doit être accessible, même si son cahier des charges n’en dit rien : sa recette le vérifie, à commencer par le parcours d’achat et le paiement.

Pour les autres sites, l’accessibilité devient une obligation quand le cahier des charges la promet (j’ai détaillé les critères WCAG appliqués à WordPress). Celui du site vitrine liste ce qui sera tenu : contrastes, hiérarchie des titres, navigation au clavier, textes alternatifs, liens explicites. Il précise qu’un audit de conformité complet n’est pas compris.

Sécurité et technique : les fichiers oubliés

Un site en fin de chantier traîne des restes. Des comptes de test, des mots de passe provisoires, des fichiers posés à la racine "juste pour cette fois". La recette fait le ménage, et WP-CLI aide à voir ce qu’on ne voit plus.

$ wp core verify-checksums
Warning: File should not exist: wp-config.bak
Warning: File should not exist: wp-config.lock
Success: WordPress installation verifies against checksums.

$ wp plugin verify-checksums --all
Success: Verified 10 of 10 plugins.

$ wp user list --role=administrator --format=count
1

Lisez bien la première sortie. Elle finit par "Success", et pourtant deux avertissements la précèdent. Deux fichiers rangés à côté de wp-config.php ne font pas partie de WordPress (leurs noms sont simplifiés ici).

L’un est une copie complète de wp-config.php, mot de passe de la base compris. Si le serveur la sert comme un simple fichier texte, elle livre ce mot de passe à qui tombe dessus.

Toutefois, la commande a une limite, inscrite dans son code. L’essai le montre : à la racine, elle signale un fichier inconnu dont le nom commence par wp-. Elle ne signale pas une copie nommée wp-config.php suivie d’un suffixe (wp-config.php.bak, par exemple), ni un fichier qui ne commence pas par wp-.

Sa documentation décrit une option qui étend le contrôle à tout le dossier ; je ne l’ai pas fait exécuter.

Comptes, mots de passe, sauvegarde

Les mots de passe d’application, que WordPress gère depuis la version 5.6, se relisent compte par compte : WP-CLI sait les lister et les trier par date de dernier usage. Ceux du chantier partent avec le chantier, comme les comptes de test, qu’il sait supprimer en réattribuant leurs publications.

Une sauvegarde qu’on n’a jamais restaurée, on ne sait pas ce qu’elle vaut, quel que soit l’outil (voir comment choisir une extension de sauvegarde). Sur le site vitrine, l’environnement de recette sera alimenté en restaurant la sauvegarde du site de travail : la recette teste la restauration au passage.

Juridique : mentions légales, confidentialité, cookies

Ce qui suit cite les textes et en tire un test de recette. Ce n’est pas un avis juridique.

Les mentions légales. L’article 1-1 de la loi pour la confiance dans l’économie numérique liste ce que l’éditeur d’un site met "à la disposition du public". Pour une société, il demande : sa dénomination, son siège social, son numéro de téléphone et, si elle est immatriculée, son numéro d’inscription et son capital.

S’y ajoutent le nom du directeur de la publication, puis le nom, l’adresse et le numéro de téléphone de l’hébergeur. La recette pointe chaque élément sur la page (pour la créer : comment intégrer les mentions légales dans WordPress).

La politique de confidentialité. WordPress sait désigner cette page depuis la version 4.9.6 : la recette contrôle qu’elle est désignée, que son texte est le vôtre, et que le pied de page y mène.

Les cookies. La CNIL demande un consentement préalable au dépôt des traceurs : dans une fenêtre de navigation privée, aucun traceur soumis à consentement ne doit donc apparaître avant un clic, ni après un refus. La suite relève du RGPD appliqué à WordPress.

Quels contrôles WordPress fait-il oublier ?

Les contrôles que WordPress fait oublier sont ceux qu’il semble réussir tout seul : un formulaire qui remercie sans que rien n’arrive, une tâche planifiée qui attend un visiteur, un mode maintenance resté actif. Aucun ne se voit en parcourant les pages…

Les e-mails, jusqu’à la boîte de réception

Un formulaire peut afficher "Merci, votre message a bien été envoyé" sans que personne ne reçoive rien. La fonction d’envoi de WordPress, wp_mail(), répond "vrai" dès qu’elle a traité la demande sans erreur. Sa documentation le précise : cela ne signifie pas que le destinataire a reçu le message.

Le piège n’est pas propre à WordPress. La documentation technique du site vitrine en préparation le décrit pour un autre outil. Sans service d’envoi configuré, la demande de "mot de passe oublié" répond par un code 200, celui du succès, et n’envoie jamais rien. Un code 200 ne prouve pas qu’un e-mail part.

Le test de recette s’écrit donc ainsi : le message du formulaire de contact et l’e-mail de mot de passe oublié arrivent dans la vraie boîte, et quelqu’un les ouvre.

Parmi les causes possibles, l’expéditeur par défaut de WordPress : wordpress@ suivi de votre domaine. Certains hébergeurs bloquent cette adresse quand elle n’existe pas (c’est écrit dans le code de WordPress).

Autre cas, relevé en préparant un projet pour une ETI de distribution. Quand la messagerie du domaine rejette tout expéditeur non déclaré, un formulaire oublié perd ses messages sans bruit (la parade : un envoi par SMTP).

Tâches planifiées et mode maintenance

WP-Cron, le planificateur de WordPress, ne tourne pas à heure fixe : il consulte sa liste à chaque chargement de page. Sur un site de recette que personne ne visite, une tâche prévue à 14 h peut attendre 17 h. L’exemple est celui de la documentation. Une publication programmée qui ne part pas en recette n’est donc pas toujours un bogue.

Certains hébergements remplacent ce mécanisme par une vraie tâche du serveur, en posant la constante DISABLE_WP_CRON. Si la constante est là et que la tâche du serveur manque, plus rien ne se déclenche. Ces commandes lèvent le doute.

$ wp cron test
Success: WP-Cron spawning is working as expected.

$ wp config has DISABLE_WP_CRON
# aucune sortie, code de retour 1 : la constante n'est pas définie

$ wp maintenance-mode status
Maintenance mode is not active.

La dernière répond à une autre question de veille d’ouverture : le site est-il resté en maintenance ? Le mode natif de WordPress repose sur un fichier .maintenance posé à la racine. WordPress cesse d’en tenir compte dix minutes après sa création.

Une page "bientôt disponible" posée par une extension ne s’efface pas toute seule : c’est l’autre visage du mode maintenance de WordPress.

Ce qu’une recette mesurée a trouvé dans une maquette déjà validée

Je vis de WordPress, et l’exemple de recette le plus parlant que j’aie sous la main n’en est pas un. Autant le redire : le site vitrine dont je parle depuis le début est celui d’un établissement scolaire, construit avec un autre outil. Les contrôles se transposent tels quels.

Il fallait montrer au client trois variantes de couleurs de sa future page d’accueil, sur une adresse de démonstration fermée aux moteurs de recherche. La maquette de départ, produite avec un outil de design, était déjà validée par le client. Une simple démonstration, donc.

Elle est quand même passée par une recette, que j’ai fait faire par Claude Code. Un script a comparé chaque variante à la maquette validée : les textes, les images, puis les styles.

Un autre a mesuré le contraste de chaque texte visible, à 1 440 pixels puis à 390 pixels de large. Il le mesure contre ce qui se trouve réellement derrière le texte. Sur une photo, il retient les 5 % de pixels les plus défavorables.

Les seuils sont ceux des WCAG, les règles internationales d’accessibilité, au niveau AA. Le rapport de contraste doit atteindre 4,5 pour 1 pour le texte courant. Il tombe à 3 pour 1 pour les grands textes, à partir de 18 points, ou de 14 points en gras (environ 24 et 19 pixels).

Ce que la mesure a sorti

La mesure a compté 13 textes sous le seuil dans la maquette déjà validée, sur ordinateur comme sur mobile. Treize. Dans un document que le client avait approuvé.

Le contrôle a sorti autre chose. Au survol, le liseré de couleur de quatre cartes disparaissait. Un point-virgule en trop dans les styles, et seule l’ombre s’appliquait. Le défaut a été constaté dans le navigateur, sur les quatre cartes.

La notice de l’outil de design se trompait de seuil : elle rangeait un surtitre de 12,5 pixels en gras parmi les grands textes. À cette taille, le seuil est de 4,5 pour 1. Et les pages chargeaient leurs photos et leur logo depuis le serveur de l’ancien site, celui qui disparaîtra avec son abonnement…

Corriger, remesurer, publier

Les retouches ont été testées dans la page, avec la même mesure. Après la seconde livraison, plus aucun texte sous le seuil : 144 textes mesurés sur ordinateur, 134 sur mobile, pour les trois variantes. Le liseré tenait au survol.

Restait à publier. Les fichiers en ligne ont été comparés aux fichiers contrôlés, empreinte par empreinte : identiques. Code 200, certificat valide. Puis le tour du propriétaire, en ligne : en-tête, animations, compteurs, survol, menu mobile, 10 images sur 10, aucune erreur.

Les contrastes ont été remesurés sur les pages publiées. Et les pages déjà présentes à la même adresse répondaient toujours.

Du premier contrôle enregistré à la publication, l’horodatage donne une heure vingt-quatre. Mon e-mail au client est parti dans le quart d’heure suivant.

Ce qui se transpose à WordPress

Rien de tout cela ne dépend de l’outil. Sur WordPress, maquettes et contrastes se contrôlent sur les pages du thème. La comparaison d’empreintes existe déjà : les commandes verify-checksums la font pour le cœur et pour les extensions. Quant à la dépendance cachée, son équivalent est une image ou un lien qui pointe encore vers l’adresse de recette.

Comment consigner une anomalie dans le cahier de recette ?

Une anomalie se consigne sur une ligne du cahier de recette, et une seule. Cette ligne dit la page concernée, ce qu’on a fait, ce qu’on attendait et ce qu’on a obtenu, avec une capture, une gravité et un statut. Une ligne par anomalie, jamais plusieurs défauts dans la même. C’est ce qui rend chaque correction vérifiable.

Un signalement mal rempli coûte un aller-retour. Pour l’éviter, chaque ligne porte les mêmes champs.

• la page, avec son adresse exacte ;
• les étapes pour reproduire le défaut ;
• le résultat attendu, et la rubrique du cahier des charges qui le promet ;
• ce qu’on a obtenu à la place, capture à l’appui ;
• le navigateur et l’appareil ;
• la gravité ;
• le statut, avec la date de chaque changement.

Le guide de recette de Marker.io, un éditeur d’outils de signalement de bogues, demande le même socle : ce qui a été testé, les étapes pour reproduire, le résultat attendu, le résultat obtenu et l’environnement.

La gravité se définit par la décision

Bloquant, majeur, mineur : ces mots ne veulent rien dire tant qu’on ne les relie pas à la mise en ligne. Dans mon modèle, chaque niveau répond à une seule question. Peut-on ouvrir avec ce défaut ?

Gravité	Effet sur la décision	Exemple (cas d’école)
Bloquant	Pas de mise en ligne tant que le défaut existe	Le message du formulaire de contact n’arrive pas
Majeur	Mise en ligne possible, avec une réserve datée	La page Équipe attend encore deux photos définitives
Mineur	Corrigé après l’ouverture, sans réserve	Une espace manque avant un point d’interrogation

Prenons un cas d’école : un site de dix pages, avec un formulaire de contact. La recette remonte vingt anomalies. Si dix-neuf sont mineures et qu’une seule est bloquante, le site n’ouvre pas. Si les vingt sont mineures, il ouvre le jour dit. Le nombre ne décide de rien.

Bogue, ou demande nouvelle

Était-ce écrit au cahier des charges ? Si oui, le défaut se corrige dans le prix convenu. Sinon, la demande est hors périmètre, et l’annexe de mon modèle de cahier des charges prévoit son circuit : "avenant écrit + devis + accord avant réalisation".

Corriger, puis revérifier

Dans mon modèle, une anomalie est ouverte, puis corrigée, puis revalidée. Le dernier statut compte double. "Un ticket fermé n’est pas une correction vérifiée", écrit Marker.io. Son guide demande de retester les défauts bloquants après correction, et pas seulement de les marquer résolus.

Revérifiez aussi autour. Une correction peut, en effet, casser la page voisine : les gens du métier appellent cela un test de non-régression. Dans la démonstration du site vitrine, un contrôle portait justement sur les pages auxquelles personne n’avait touché.

Procès-verbal, réserves et levée des réserves

La recette se termine par une décision. Je vous dis comment je la prends, ce que je propose pour l’écrire, puis ce que disent les textes.

Dans ma pratique

Et s’il reste des réserves ? À ce moment-là, elles sont notées, et j’amende le cahier des charges pour la correction. En général, je traite les derniers points. Cela ne m’arrive que très rarement.

La réserve finit dans le cahier des charges, le document de référence du projet.

Ce que je propose : un procès-verbal

Ce qui suit est une proposition, et non le récit de ma pratique.

Le procès-verbal de recette tient sur une page. Il porte la décision : acceptée, acceptée avec réserves, ou refusée. Il liste les réserves, avec la date à laquelle chacune doit être levée, et reçoit la signature des deux parties. Pour lever une réserve, on rejoue le test qui avait échoué, on constate qu’il passe, et on date la ligne.

Le guide de Marker.io demande lui aussi une validation écrite : "une approbation informelle ne suffit pas quand l’enjeu est élevé".

Ce que disent les textes

Le vocabulaire est celui du droit de la construction. L’article 1792-6 du Code civil y définit la réception comme "l’acte par lequel le maître de l’ouvrage déclare accepter l’ouvrage avec ou sans réserves". Il ne s’applique pas tel quel à un site web.

Un arrêt porte bien, en revanche, sur un site internet : Cour de cassation, chambre commerciale, 26 novembre 2013, n° 12-25.191. Un client avait signé un procès-verbal sans émettre de réserve. Le site ne fonctionnait pas. Le client avait protesté avant et après la signature, et le prestataire n’avait pas réagi à ses réclamations.

Devant la Cour, le prestataire soutenait qu’une réception sans réserve couvre les défauts apparents. Elle a écarté l’argument, en ces termes.

"Mais attendu que l’obligation de délivrance de produits complexes n’est pleinement exécutée qu’une fois réalisée la mise au point effective de la chose vendue"

Les juges d’appel avaient écrit, de leur côté, qu’il en va autrement pour "un site internet dont la mise en oeuvre et la conformité ne peuvent s’apprécier au moment de la seule démonstration mais exigent une utilisation d’une certaine durée".

Dans cette affaire, le procès-verbal signé sans réserve n’a pas fermé la discussion. Les écrits figuraient au dossier : les réclamations du client, avant et après la signature, et le silence du prestataire.

Si une réserve n’est jamais levée

Reste alors le droit commun des contrats. L’article 1217 du Code civil énumère ce que peut faire celui envers qui un engagement "n’a pas été exécuté, ou l’a été imparfaitement".

• "refuser d’exécuter ou suspendre l’exécution de sa propre obligation" ;
• "poursuivre l’exécution forcée en nature de l’obligation" ;
• "obtenir une réduction du prix" ;
• "provoquer la résolution du contrat" ;
• "demander réparation des conséquences de l’inexécution".

Votre contrat peut prévoir autre chose.

Si personne chez vous ne sait lire une sortie de terminal, un regard extérieur peut faire la recette à vos côtés. Mes interventions d’expert se facturent 190 € HT de l’heure, et le premier appel est offert.

La bascule : le jour de la mise en ligne

La décision est prise, le site ouvre. La bascule se prépare comme le reste : par écrit. Voici ce que prévoit la feuille de route du site vitrine pour ce jour-là.

• Le feu vert du client, et lui seul, déclenche l’opération.
• Une sauvegarde de référence est prise avant la bascule, et le retour arrière est prêt.
• Le DNS du site est modifié, la messagerie ne bouge pas.
• La protection par identifiant du site de travail est retirée.
• Le site prend son adresse définitive, et les redirections des anciennes adresses sont activées.
• Les contenus sont gelés ; la Search Console et les statistiques sont branchées.
• La surveillance s’inverse : la sonde qui attendait un 401 sur le site de travail attend désormais un 200 sur le domaine définitif.

Combien de temps dure l’opération ? La durée annoncée au client : une dizaine de minutes. Le site de travail et le site définitif sont la même installation : il n’y a aucun contenu à transférer le jour J. L’ancien site reste visible jusqu’au dernier moment.

Sur WordPress : l’adresse de recette ne doit pas survivre

Un WordPress construit sur une adresse de recette garde cette adresse dans sa base : réglages, contenus, liens. Avant de remplacer quoi que ce soit, comptez. La commande suivante simule le remplacement sans rien écrire (le nom du site local est remplacé par un nom d’exemple).

$ wp search-replace "http://monsite.local" "https://exemple.fr" --dry-run --skip-columns=guid --report-changed-only
Table        Column         Replacements   Type
wp_options   option_value   4              PHP
wp_postmeta  meta_value     1              PHP
wp_posts     post_content   9              SQL
wp_users     user_url       1              SQL
Success: 15 replacements to be made.

Quinze occurrences, dans quatre tables. L’option --dry-run déroule toute l’opération et affiche le rapport, sans toucher à la base. La commande sait traiter les données sérialisées de PHP, d’après sa documentation. La mécanique complète est dans mon tutoriel de refonte d’un site WordPress.

Après la bascule, relancez la même simulation : elle ne doit plus rien trouver. Puis videz les caches, décochez la case de non-indexation, et retestez chaque formulaire sur le vrai domaine.

Une précaution vient de WordPress VIP : avant de toucher au DNS, sa documentation conseille d’afficher le site à sa future adresse depuis un seul poste, en modifiant son fichier hosts.

Le lendemain, puis une semaine après

Le lendemain de l’ouverture, on rejoue sur le vrai domaine les tests qui dépendent de l’adresse : formulaires, indexation, redirections, tâches planifiées. Une semaine après, on lit ce que seul l’usage révèle. Les erreurs remontées par la Search Console, la vitesse mesurée chez de vrais visiteurs, et les réserves encore ouvertes.

Quand	Contrôle	Résultat attendu
Le lendemain	Un message envoyé par chaque formulaire, depuis le vrai domaine	Reçu dans la vraie boîte
Le lendemain	wp option get blog_public et l’adresse du plan du site	La commande répond 1, le plan du site s’affiche
Le lendemain	L’accueil, un article et une page clé, sur le vrai domaine	Réponse 200, aucun noindex dans la page ni dans l’en-tête X-Robots-Tag, canonical sur le vrai domaine
Le lendemain	Un échantillon d’anciennes adresses	Une redirection 301 vers la page qui les remplace, puis une réponse 200, aucune erreur 404
Le lendemain	wp cron test, et la sauvegarde de la nuit	"Success", et une sauvegarde datée du jour
Une semaine après	La Search Console	Des pages indexées, pas de vague d’erreurs 404
Une semaine après	La vitesse, sur le vrai domaine	Les seuils du cahier des charges
Une semaine après	Les réserves du procès-verbal	Levées, ou redatées par écrit
Une semaine après	Les comptes et les mots de passe du chantier	Supprimés, ou changés s’ils ont circulé par e-mail

L’indexation vérifiée, puis 329 redirections

Sur le site vitrine, l’hypothèse de départ était simple : les anciennes actualités n’étaient presque pas dans Google. Une recherche avec l’opérateur site: a montré le contraire. Elles y étaient.

La conséquence : un plan de 329 redirections, que le document de migration dit "non négociable". Et le contrôle est écrit d’avance. Après la mise en ligne, aucune de ces 329 adresses ne doit renvoyer une erreur 404. Sur un échantillon d’abord, dans la Search Console après.

Que contient un cahier de recette pour WordPress ?

Voici ce que contient mon modèle de cahier de recette, à télécharger en Word et en PDF en bas de cette page. Il se remplit avec mon modèle de cahier des charges, et les deux documents se lisent côte à côte : chaque partie renvoie à la rubrique dont elle vérifie la promesse.

Partie du cahier de recette	Ce qu’elle contient	Rubrique du cahier des charges
Mode d’emploi	Qui remplit quoi, dans quel ordre, quand signer	Sans objet
0. Informations générales	Projet, adresse de recette, version de WordPress, dates, valideur, prestataire	0. Informations générales
1. Règle d’acceptation	Gravité définie par la décision ; anomalie ou demande hors périmètre	12. Recette et critères de validation, annexe
2. Contrôles fonctionnels	Formulaires et messages reçus, recherche, comptes et rôles, paiement	3. Périmètre fonctionnel
3. Contenus et parcours	Pages prévues, textes définitifs, liens, page 404, redirections	4. Arborescence et parcours, 7. Contenus, 8 (redirections)
4. Graphisme et mobile	Maquettes, largeurs d’écran, contrastes	6. Charte graphique et design
5. Référencement, performance, accessibilité	Indexation, plan du site, balises de titre, vitesse, accessibilité	8. Référencement, performance, accessibilité
6. Technique et sécurité WordPress	Environnement, débogage, tâches planifiées, sauvegarde restaurée, comptes, fichiers oubliés	5. Contraintes techniques, 10. Maintenance et reprise des accès
7. Juridique	Mentions légales, confidentialité, cookies	5. Contraintes techniques (conformité RGPD), et le contrat
8. Registre des anomalies	Date, page, description, capture, gravité, statut	12
9. Procès-verbal de recette	Décision, réserves et dates de levée, signatures	12
10. Bascule et suivi	Jour de la mise en ligne, lendemain, semaine suivante, prise en main	9. Budget et planning, 10, 11
Annexe	Les commandes WP-CLI de ce guide	Sans objet

La recette qui ne s’arrête pas

Sur wpformation.com, la recette continue tous les jours. Chaque matin, un contrôle automatique interroge 18 adresses du site et compare la réponse à celle qui est attendue. L’une de ces adresses n’existe pas, exprès : elle doit répondre 404. Si elle répond autre chose, ou si une seule des dix-sept autres flanche, je reçois un e-mail.

Ce contrôle est né d’un raté. En avril 2026, six adresses du site ont répondu 404 pendant quatre jours, sans aucune alerte.

Pour un site ouvert depuis longtemps, l’exercice change de nom et devient un audit : j’en déroule un dans mon audit WordPress en 13 points de contrôle.

Un dernier conseil, qui ne demande aucun outil. N’attendez pas la veille de l’ouverture pour écrire votre recette : écrivez-la le jour où vous rédigez le cahier des charges. Chaque promesse, avec son test en face.

Le jour venu, vous n’aurez plus qu’à dérouler… et la recette de votre prochain site sera déjà à moitié prête.

Questions fréquentes

Qui valide la recette d’un site web ?

Le donneur d’ordre, avec le prestataire. Ils reprennent le cahier des charges point par point et vérifient ensemble que le site le respecte. Le nom de la personne qui valide côté client s’écrit dans le cahier des charges, avant le début du projet.

Comment vérifier que WordPress ne bloque pas l’indexation ?

Regardez la case "Demander aux moteurs de recherche de ne pas indexer ce site", dans Réglages, puis Lecture : elle doit être décochée. En ligne de commande, wp option get blog_public doit répondre 1. Depuis WordPress 6.9, l’écran Santé du site signale aussi la case cochée. Tant qu’elle l’est, le plan du site natif répond 404. Contrôlez ensuite la réponse publique de quelques pages : aucun noindex dans le code ni dans l’en-tête X-Robots-Tag, et une balise canonical qui désigne le vrai domaine.

Un procès-verbal signé sans réserve empêche-t-il toute réclamation ?

Pas nécessairement. Dans un arrêt du 26 novembre 2013 (n° 12-25.191), un procès-verbal avait été signé sans réserve pour un site qui ne fonctionnait pas, et la Cour de cassation a approuvé les juges d’avoir retenu un manquement du prestataire. L’arrêt n’est pas publié au Bulletin : pour votre contrat, consultez un avocat.

Sources

Toutes lues le 30 septembre 2026 ; citations anglaises traduites en français.

• WordPress : écran Lecture, install.php, Santé du site, plan du site (annonce), environnement, débogage, maintenance, anciens slugs, wp_mail(), WP-Cron, version 4.9.6
• WP-CLI : core verify-checksums (code), search-replace, cron test, config has, user delete, application-password list ; commandes exécutées sur un WordPress local 7.1.2
• Google : contrôler ce que vous partagez, retrait du test mobile, INP
• Méthode : WordPress VIP (tester, liste de tests, lancement), Marker.io
• Accessibilité : loi n° 2005-102, article 47 et article 47-1, champ d’application du RGAA, WCAG 2.2 ; Code de la consommation, article L412-13 et articles D412-49 et suivants (lus le 2 octobre 2026)
• Mentions légales et cookies : loi n° 2004-575, article 1-1, CNIL
• Procès-verbal et réserves : Code civil, article 1792-6 et article 1217 ; Cass. com., 26 novembre 2013, n° 12-25.191
• Mes projets : compte rendu de contrôle, feuille de route et plan de migration d’un site vitrine, anonymisés ; résultats de Google relevés le 29 septembre 2026