Copier la production vers la préproduction

Rafraîchir la préproduction à partir de la production est l'un des workflows les plus fréquents en agence : on veut tester une montée de version PHP, un nouveau plugin, une migration de thème ou un correctif lourd sans toucher au site en ligne. Cette doc décrit la méthode propre côté Plesk chez Datacampus, du clic assisté jusqu'à la version manuelle en SSH.

Pourquoi une préproduction ?

Un environnement de préprod permet de :

• Tester un passage de PHP 7.4 à 8.2 avant de basculer la prod.
• Valider un plugin WordPress ou un module PrestaShop sans casser les commandes en cours.
• Rejouer une migration de base en conditions réelles (volume, encodage, triggers).
• Former un nouvel intégrateur sans risque.
• Obtenir un devis client sur une V2 avec un lien démo.

Convention Datacampus : l'abonnement *_pp

Chez Datacampus, la convention est simple : à chaque abonnement Plesk de production correspond un second abonnement nommé nomclient_pp (pour préproduction) sur le même serveur mutualisé. Même infra, même version de Plesk, même gamme de versions PHP disponibles. Le domaine associé est généralement preprod.monsite.fr ou monsite-pp.datacampus.fr.

Méthode rapide : « Cloner le site » dans Plesk

Plesk intègre une fonction de clonage qui copie fichiers + base de données en une opération. C'est la méthode recommandée pour un rafraîchissement ponctuel de la préprod.

1. Connectez-vous à Plesk sur le compte qui possède la prod.
2. Sites Web & Domaines > ouvrez le menu contextuel du domaine de prod (les trois points ou la flèche).
3. Cliquez sur Cloner le site (Clone Website).
4. Choisissez l'abonnement cible : sélectionnez nomclient_pp dans la liste.
5. Renseignez le domaine de destination (preprod.monsite.fr).
6. Cochez Copier les fichiers et Copier les bases de données.
7. Lancez le clonage. Selon la taille du site, comptez de quelques secondes à plusieurs minutes.

À la fin, Plesk a recréé la racine web, importé la base avec un nouveau nom (généralement suffixé), et ajusté les identifiants de connexion dans le fichier de configuration du CMS si celui-ci est reconnu (WordPress, Joomla, Drupal).

Méthode manuelle : plus de contrôle

À préférer quand le site est volumineux, que l'encodage est sensible, ou que vous voulez scripter l'opération. Toutes les commandes se lancent en SSH sur le serveur mutualisé, avec l'utilisateur système du site de prod pour la lecture, puis celui du site de préprod pour l'écriture.

1. Dump de la base de production

mysqldump \
  --single-transaction \
  --default-character-set=utf8mb4 \
  --routines --triggers --events \
  -u USER_PROD -p BASE_PROD > /tmp/prod.sql

Les options à retenir :

• --single-transaction : dump cohérent sans bloquer les écritures (InnoDB).
• --default-character-set=utf8mb4 : évite les accents cassés lors de la restauration.
• --routines --triggers --events : embarque les procédures stockées, triggers et events si le site en utilise.

Les identifiants de connexion à la base sont disponibles dans Plesk : Bases de données > User Settings. Voir aussi MySQL en ligne de commande.

2. Copie des fichiers avec rsync

rsync -av --delete \
  /var/www/vhosts/monsite.fr/httpdocs/ \
  /var/www/vhosts/monsite_pp.fr/httpdocs/

Quelques points à vérifier avant de lancer :

• Le / final sur la source est essentiel (sinon rsync crée un sous-dossier).
• --delete supprime côté cible tout ce qui n'existe plus côté source. C'est voulu pour un rafraîchissement propre, dangereux si vous êtes dans le mauvais sens.
• Ajoutez --exclude='wp-content/cache/', --exclude='var/cache/' ou similaire pour éviter de trainer des caches obsolètes.

3. Restauration de la base côté préprod

mysql --default-character-set=utf8mb4 \
  -u USER_PREPROD -p BASE_PREPROD < /tmp/prod.sql

Si la base de préprod existe déjà et contient d'anciennes données, videz-la d'abord :

mysql -u USER_PREPROD -p -e "DROP DATABASE BASE_PREPROD; CREATE DATABASE BASE_PREPROD CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"

4. Ajuster le propriétaire des fichiers

Chez Datacampus, chaque site a son propre utilisateur Linux (pas de www-data partagé). Après un rsync lancé en root ou avec un autre user, il faut redonner la propriété au user système du domaine cible, sinon PHP-FPM ne peut plus écrire.

NC_USER=$(stat -c '%U' /var/www/vhosts/monsite_pp.fr/httpdocs)
chown -R "$NC_USER:$NC_USER" /var/www/vhosts/monsite_pp.fr/httpdocs

stat -c '%U' récupère le user propriétaire du répertoire cible : c'est celui qui doit rester aux commandes. Voir Permissions Linux pour les détails.

Adaptations post-copie : obligatoires

À ce stade, la préprod est une copie bit à bit de la prod — y compris l'URL, les clés SMTP, les tokens de paiement et les crons. Tant que vous n'avez pas neutralisé tout ça, la préprod est une bombe à retardement.

WordPress

Changer le domaine en base (sérialisation comprise) avec WP-CLI :

cd /var/www/vhosts/monsite_pp.fr/httpdocs
wp search-replace 'https://monsite.fr' 'https://preprod.monsite.fr' --all-tables --skip-columns=guid
wp cache flush
wp rewrite flush

Pensez aussi à désactiver les plugins qui pourraient polluer l'extérieur : mailers transactionnels, backups automatiques, synchro e-commerce. Voir WP-CLI.

PrestaShop

Mettre à jour les domaines en base :

UPDATE ps_shop_url SET domain='preprod.monsite.fr', domain_ssl='preprod.monsite.fr';
UPDATE ps_configuration SET value='preprod.monsite.fr' WHERE name='PS_SHOP_DOMAIN';
UPDATE ps_configuration SET value='preprod.monsite.fr' WHERE name='PS_SHOP_DOMAIN_SSL';

Puis vider les caches disque :

rm -rf var/cache/*
rm -rf img/tmp/*

Passez la boutique en mode maintenance depuis le back-office une fois connecté.

Neutraliser les emails transactionnels

Trois approches possibles :

• Configurer un SMTP factice (MailHog, Mailpit) qui capture les emails sans les envoyer.
• Rediriger tous les emails sortants vers une adresse interne via un plugin (WP Mail Logging, module PrestaShop équivalent).
• Couper purement et simplement la fonction mail() PHP dans les Paramètres PHP du domaine de préprod (disable_functions = mail).

Désactiver les crons métier

Allez dans Tâches planifiées de l'abonnement *_pp et désactivez (sans supprimer) tous les crons qui touchent à l'externe : export compta, relance panier, sync ERP, notifications SMS. Voir Tâches planifiées.

Noindex et accès restreint

On ne veut ni Google, ni un visiteur lambda sur la préprod.

Un robots.txt à la racine :

User-agent: *
Disallow: /

Plus un HTTP Basic Auth via .htaccess (voir .htaccess : les essentiels) :

AuthType Basic
AuthName "Preprod — acces restreint"
AuthUserFile /var/www/vhosts/monsite_pp.fr/.htpasswd
Require valid-user

Créez le fichier d'identifiants avec htpasswd -c /var/www/vhosts/monsite_pp.fr/.htpasswd agence.

Checklist finale

Avant de livrer la préprod au client ou à l'équipe :

• L'URL de préprod répond en HTTPS avec un certificat valide.
• La page d'admin (/wp-admin, /adminXXXX) se connecte sans boucle de redirection vers la prod.
• Un parcours critique fonctionne de bout en bout (commande test, formulaire de contact, création de compte).
• ~/logs/error_log ne hurle pas à chaque requête.
• Les emails transactionnels sont bien neutralisés (test avec une commande bidon).
• Les crons métier sont désactivés.
• La préprod est bien en noindex ou derrière Basic Auth.

Les erreurs classiques à éviter

• Oublier le chown après rsync : PHP-FPM renvoie du 500, impossible d'écrire dans wp-content/uploads.
• Oublier --default-character-set=utf8mb4 au dump ou à la restauration : tous les accents cassent.
• Laisser la préprod indexable : Google référence des pages en double, duplicate content garanti.
• Oublier de couper le mailer : envoi massif de « votre commande est confirmée » à tous les clients des 30 derniers jours.
• Copier la prod vers une préprod avec des crons actifs qui poussent vers un ERP de prod : double écriture côté métier.

En cas de doute ou si la copie touche à une base volumineuse (> plusieurs Go), passez par un ticket : on vous accompagne ou on scripte l'opération côté serveur.