Dupliquer un site WordPress en préproduction
Tester une mise à jour ou un développement sur une copie fidèle du site, avant de toucher à la production, suppose presque toujours de changer l’URL (site.fr vers preprod.site.fr ou un sous-dossier). Ce changement d’URL est le point technique le plus mal maîtrisé de ce type de copie.
Pourquoi changer l’URL casse des réglages si on s’y prend mal
WordPress stocke une partie de ses données (réglages de thème, configuration de widgets, certaines métadonnées, options de plugins) sous forme de données PHP sérialisées dans les colonnes texte de la base MySQL. Une chaîne sérialisée encode la longueur exacte de chaque sous-chaîne qu’elle contient, par exemple s:22:"https://ancien-site.fr". Si on remplace l’URL par un simple rechercher-remplacer SQL, avec une requête du type UPDATE wp_options SET option_value = REPLACE(...), le nombre déclaré avant les guillemets ne correspond plus à la nouvelle longueur de chaîne, et WordPress échoue à désérialiser la donnée.
Une copie de préproduction multiplie les occasions de tomber dans ce piège, car l’URL change souvent une deuxième fois par la suite : une adresse de test provisoire au moment de la copie, puis une adresse définitive de préprod une fois l’environnement stabilisé. Chaque changement doit repasser par le même outil, pas seulement le premier.
Le résultat n’est pas toujours visible immédiatement : réglages de thème réinitialisés, widgets qui disparaissent, options de plugin vidées, parfois sans message d’erreur clair. La bonne méthode passe par un outil qui recalcule ces longueurs à chaque remplacement, typiquement la commande wp search-replace ancienne-url nouvelle-url --all-tables de WP-CLI, ou un plugin de migration qui fait ce travail en interne, comme All-in-One WP Migration ou WP Migrate DB.
Ce qu’il faut prévoir en plus d’une copie classique
- Empêcher l’indexation par les moteurs de recherche : un doublon de contenu indexé nuit au référencement du site principal
- Couper l’envoi réel d’e-mails (confirmations de commande, notifications) pour ne pas alerter de vrais clients pendant les tests
- Neutraliser les passerelles de paiement en les laissant strictement en mode test, pour ne jamais déclencher un paiement réel
- Un écart qui se creuse avec le temps entre la préprod et la production si aucune synchronisation régulière n’est prévue
Comment je conduis une duplication en préproduction
-
Copie complète des fichiers et de la base
Je duplique l’intégralité des fichiers du site et un export de la base de données vers l’environnement de préproduction.
-
Remplacement d’URL avec wp search-replace
L’URL de production est remplacée par celle de la préprod avec WP-CLI, qui recalcule correctement les longueurs des données sérialisées.
-
Blocage de l’indexation
J’ajoute une balise noindex ou un fichier robots.txt dédié à la préprod, pour qu’aucun moteur de recherche n’indexe le doublon.
-
Neutralisation des e-mails sortants
J’utilise un service de capture d’e-mails ou je désactive le plugin d’envoi, pour qu’aucune notification ne parte vers un vrai client depuis la préprod.
-
Passage des passerelles de paiement en mode test
Les identifiants de paiement réels sont remplacés par leurs équivalents de test, pour ne jamais déclencher un mouvement d’argent réel.
-
Resynchronisation si nécessaire
Si l’écart entre préprod et production devient trop important avec le temps, je relance une copie complète depuis la production plutôt que de corriger la préprod au cas par cas.
Pour aller plus loin
-
Migration d’hébergeur sans interruption
Le même mécanisme de sérialisation appliqué à une vraie bascule d’hébergeur.
-
Comprendre la sérialisation PHP
La définition complète du mécanisme et de ses pièges.
-
Sauvegarder sa boutique avant intervention
Ce qu’il faut sauvegarder avant toute copie de site.
-
Activer le mode debug WordPress
Utile pour repérer une erreur silencieuse sur l’environnement de préproduction.
Décrivez votre besoin en 1 minute
Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.