Préproduction WordPress client : monter et tester avant la prod

Pourquoi une préproduction plutôt qu'un test sur le site en ligne

Ce que la préproduction vous apporte

• Des mises à jour sans surprise — chaque changement de cœur, de thème ou d'extension est vu à l'écran avant d'atteindre les visiteurs.
• Un diagnostic lisible — les erreurs vont dans un journal, pas devant le client, et la cause se retrouve avant qu'il appelle.
• Une recette partagée — le client ou son chef de projet valide sur une adresse à part, sans toucher au site vitrine.
• Un journal des changements — vous notez la version avant et après de chaque extension, et vous rejouez exactement la même sur la production.
• Un essai des nouveautés — nouveau thème, nouveau constructeur de pages, nouveau module de paiement : tout se juge sur une copie.
• Un retour arrière préparé — la sauvegarde est faite et vérifiée avant le test, pas après l'incident.

Prérequis chiffrés avant de copier

Monter la préproduction, étape par étape

1. 01

   Sauvegarder la production avant toute écriture

   Depuis le dossier du site en ligne :
   mkdir -p ~/preprod-backups
wp db export ~/preprod-backups/before-staging.sql --single-transaction
tar -czf ~/preprod-backups/files-before-staging.tar.gz -C ~/public_html .
   Vérifiez que les deux fichiers existent et ne sont pas vides avec ls -lh ~/preprod-backups. Les sauvegardes de l'offre ne dispensent pas de ce geste : leur fréquence dépend de l'offre, donc elles peuvent dater de plusieurs jours.

2. 02

   Créer le sous-domaine et son dossier

   Créez staging.votre-domaine.com dans cPanel (le guide « Créer un sous-domaine dans cPanel » détaille l'écran) avec un dossier racine propre, de préférence hors de public_html, par exemple ~/staging.votre-domaine.com. Un dossier placé dans public_html serait aussi atteignable par une adresse du site en ligne. Attendez que le certificat TLS du sous-domaine soit émis avant de tester.

3. 03

   Copier les fichiers

   rsync -a --exclude='wp-content/cache/' ~/public_html/ ~/staging.votre-domaine.com/
   Adaptez le chemin source au dossier racine du site client. Sans terminal, le gestionnaire de fichiers de cPanel permet de compresser le dossier, de le déplacer puis de l'extraire dans le dossier du sous-domaine.

4. 04

   Créer une base et un utilisateur dédiés

   Dans la section des bases de données MySQL de cPanel, créez une base neuve, un utilisateur et donnez-lui tous les droits sur cette base seule. Puis ouvrez le wp-config.php de la copie et changez DB_NAME, DB_USER et DB_PASSWORD. C'est l'erreur la plus coûteuse de ce guide : copier wp-config.php sans modifier ces trois lignes, c'est faire écrire la préproduction dans la base de production.

5. 05

   Importer la base

   Depuis le dossier de la copie :
   cd ~/staging.votre-domaine.com
wp db import ~/preprod-backups/before-staging.sql
wp option get siteurl
   La dernière commande doit encore afficher l'adresse de production : c'est normal, les URL ne sont pas remplacées. Si elle échoue, wp-config.php pointe toujours vers la mauvaise base.

6. 06

   Remplacer les URL, à blanc d'abord

   wp search-replace 'https://votre-domaine.com' 'https://staging.votre-domaine.com' --all-tables --skip-columns=guid --dry-run
   Lisez le rapport : il liste les tables et le nombre de remplacements. Puis relancez la même commande sans --dry-run. WordPress stocke beaucoup de réglages en données sérialisées, où chaque chaîne porte sa longueur : un sed sur l'export change la longueur de l'URL sans corriger ce compte, et les réglages deviennent illisibles. wp search-replace comprend ces données et les réécrit correctement.

7. 07

   Poser les réglages de préproduction dans wp-config.php

   Ajoutez, au-dessus de la ligne « That's all, stop editing » :
   define('WP_ENVIRONMENT_TYPE', 'staging');
define('DISABLE_WP_CRON', true);
define('DISALLOW_FILE_EDIT', true);
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
   Les erreurs vont dans wp-content/debug.log sans s'afficher aux visiteurs. WP_ENVIRONMENT_TYPE existe depuis WordPress 5.5 et accepte local, development, staging et production : il permet aux thèmes et aux extensions de s'adapter, mais il ne masque pas le site aux moteurs, d'où l'étape suivante.

8. 08

   Fermer l'accès et demander le noindex

   Dans Réglages › Lecture, cochez « Demander aux moteurs de recherche de ne pas indexer ce site », ou en ligne de commande : wp option update blog_public 0. Ajoutez ensuite une authentification HTTP au dossier de la copie : un fichier .htpasswd créé avec htpasswd -c ~/.htpasswd-staging client, puis dans le .htaccess du dossier les directives AuthType Basic, AuthName "Preproduction", AuthUserFile vers ce fichier et Require valid-user. À défaut, limitez l'accès à une liste d'IP.

9. 09

   Contrôler la copie comme le ferait un robot

   curl -sI https://staging.votre-domaine.com/
   La réponse doit être un 401. Puis, avec les identifiants :
   curl -s -u client https://staging.votre-domaine.com/ | grep -i robots
   Vous devez voir une balise meta name='robots' contenant noindex. Si une extension de cache ou de référencement la remplace, c'est elle qu'il faut régler. Vérifiez enfin que le thème ne contient pas d'adresse de production en dur : grep -r "https://votre-domaine.com" wp-content/themes.

10. 10

    Rattacher la préproduction à votre routine d'agence

    Faites de ce montage un modèle : un sous-domaine par client, dans le compte cPanel du client, avec la même liste de contrôle. L'ordre des opérations pour déplacer un site vers un autre hébergeur fait l'objet du guide « Migrer un site WordPress client sans coupure » ; la préproduction décrite ici est un outil durable, pas une étape de bascule.

Isoler vraiment : le noindex ne suffit pas

Neutraliser e-mails, paiements et tâches planifiées

Liste de contrôle avant de toucher à la moindre extension

• E-mails — extension d'envoi en mode test ou redirigée vers une boîte de recette, notifications de la boutique coupées.
• Paiements — passerelle en mode test, clés de production retirées de la copie, adresses de rappel (webhooks) non déclarées pour la préproduction.
• Tâches planifiées — DISABLE_WP_CRON posé, événements en attente relevés avec wp cron event list.
• Modification de fichiers — DISALLOW_FILE_EDIT actif pour ne pas éditer le code depuis l'administration.
• Journal d'erreurs — WP_DEBUG_LOG actif et WP_DEBUG_DISPLAY à false.
• Intégrations tierces — CRM, annuaires, outils de statistiques et clés d'API de production remplacés ou retirés.
• Moteurs de recherche — noindex posé et authentification en place, contrôlés avec curl comme ci-dessus.

Tester les mises à jour, une à la fois

Quand la mise à jour casse : lire debug.log

Dépannage : les autres symptômes qu'on rencontre vraiment

• Le site redirige vers la production — wp option get siteurl et wp option get home affichent encore l'ancienne adresse, ou un constructeur de pages garde des URL en dur ; relancez le remplacement, avec --precise si besoin.
• « Erreur lors de la connexion à la base de données » — DB_NAME, DB_USER, DB_PASSWORD ou DB_HOST de la copie sont faux, ou l'utilisateur n'a pas de droits sur la nouvelle base.
• Images ou styles chargés depuis la production — des URL échappées, comme https:\/\/ dans les données JSON des constructeurs, ont échappé au remplacement ; relancez-le avec cette forme.
• Boucle de connexion ou déconnexion immédiate — les cookies appartiennent à l'ancien domaine ; videz-les et vérifiez siteurl et home.
• La préproduction apparaît dans un moteur de recherche — le noindex a été posé trop tard ou une extension le remplace ; passez à l'authentification HTTP et demandez la suppression de l'adresse.

Fichiers ou base : ce qui se reporte, et comment

Faites défiler le tableau

Reporter en production, et pouvoir revenir en arrière

Une routine qui tient à l'échelle d'un portefeuille