La plupart des incidents WordPress que je récupère ont la même cause : on a touché la production parce qu'il n'existait rien d'autre. Pas de copie locale, pas de préprod (une copie de test du site, hébergée comme le vrai), une sauvegarde jamais restaurée. Tester un site WordPress en local et en préprod n'est pas une pratique de grand groupe. C'est la condition pour mettre à jour WooCommerce, changer un thème, désactiver XML-RPC ou activer la double authentification sans découvrir le dégât avec les visiteurs. Cet article explique le rôle de chaque environnement, comment cloner proprement, quoi vérifier, et les pièges (e-mails, paiements, cron, URLs).
🔎 Trois environnements, trois questions
Le local répond à : est-ce que ça démarre sur ma machine, est-ce que je peux développer sans casser le live ? La préprod répond à : est-ce que ça ressemble assez à la production pour oser la mise à jour ? La production répond à : est-ce que les vrais utilisateurs et le vrai argent passent ? Mélanger les trois, c'est ainsi que l'on envoie un mail de test à 4 000 clients.
Une PME n'a pas besoin de cinq environnements et d'une infrastructure de grande entreprise. Elle a besoin d'un local pour le développeur, d'une préprod hébergée proche de la prod (même PHP, même type de cache), et d'une prod touchée en dernier. Si le budget ne permet qu'une préprod, on commence par elle. Le local seul ment trop (autre OS, autre charge).
🛠️ Ce que le local sait faire, ce qu'il ne sait pas
En local on installe WordPress, on reproduit les bugs, on développe un plugin, on voit le thème. On ne valide pas les perfs réelles, ni le HTTPS de prod, ni le comportement CDN, ni la charge. Un site « rapide en local » peut être lent en production. Un plugin qui marche en local peut casser avec l'object cache de prod.
Outils : Docker, Valet, Local WP, un stack maison. Peu importe, tant que PHP et la version MySQL sont proches, et que l'on peut importer une copie anonymisée. Les mots de passe clients, les clés Stripe live, les SMTP de prod n'ont rien à faire sur un laptop.
✅ Cloner WordPress sans polluer le monde réel
On copie fichiers et base. On remplace l'URL (search-replace sérieux, sérialisation PHP). On désactive ou on redirige les e-mails (mailtrap, log, plugin de redirection). On passe les paiements en sandbox. On coupe les crons dangereux (sync ERP, campagnes). On noindex la préprod. On protège par mot de passe HTTP. Oublier une de ces lignes, c'est un incident.
Les données personnelles : on anonymise ce qu'on peut. Une préprod n'est pas un second CRM. RGPD et simple prudence. Les commandes Woo se masquent ou se réduisent à un échantillon.
- Search-replace d'URL qui respecte les données sérialisées
- E-mails piégés, jamais le SMTP de production
- Paiements sandbox, clés live absentes
- noindex + auth HTTP sur la préprod
- Cron et webhooks tiers coupés ou pointés vers le sandbox
⚠️ La préprod utile : proche, pas identique au pixel
Même version PHP, mêmes extensions PHP, même type de serveur (Apache/Nginx), un cache du même genre. Pas forcément le même CDN. Pas forcément la même RAM. L'objectif est que les mises à jour WordPress et les plugins se comportent pareil, pas de gagner un benchmark.
Une préprod fournie par l'hébergeur en un clic est un bon départ, si elle n'envoie pas d'e-mails et si on peut la rafraîchir. Une préprod vieille de six mois ne sert plus : on y teste une autre époque du site.
📌 Quoi vérifier selon le changement
Mise à jour de plugin mineure : admin, une page clé, le formulaire. Mise à jour WooCommerce : un panier complet sandbox. Changement de thème : accueil, pages intérieures, mobile, menu, footer. Changement d'URL d'admin ou 2FA : le chemin de connexion des vrais humains, pas seulement le vôtre. Désactivation XML-RPC : les apps qui s'en servaient encore (Jetpack, éditeurs mobiles).
On écrit la liste de contrôle. On la joue. On ne se contente pas de « jeter un œil ». Les régressions WordPress sont locales (un hook, un CSS). L'œil sur la home ne les voit pas.
🧭 Déployer vers la production sans folklore
Sauvegarde d'abord (et on sait restaurer, voir l'article Sauvegardes WordPress qui restaurent vraiment). Déployer les mêmes versions qu'en préprod. Vider le cache. Vérifier le sous-ensemble critique en live (paiement encore sandbox si on peut, ou une commande de 1 €). Rester disponible une heure après la mise en ligne.
Si ça casse : retour arrière sur les fichiers et la base, pas « on corrige en live pendant que les clients paient ». Le local et la préprod existent pour que ce retour arrière soit rare. Quand il arrive, il doit être ennuyeux, pas héroïque.
💡 Qui a le droit de toucher à quoi
La production n'est pas un terrain d'essai pour un plugin trouvé sur un blog. La préprod l'est. Le local aussi. Cette phrase doit être dite au client : chaque « petite extension » passe par le staging. C'est plus lent d'une demi-journée. C'est plus rapide que trois jours d'incident.
Les accès : moins de comptes admin en prod, 2FA, URL d'admin modifiée. En préprod, on peut être plus large, mais pas public. Un staging ouvert, Google l'indexe, les bots le remplissent, et un jour quelqu'un paie dessus.
🧪 Démarrer petit si vous n'avez rien
Semaine 1 : sauvegarde restaurée une fois sur un clone. Semaine 2 : préprod noindex, mails piégés. Semaine 3 : les mises à jour ne se font plus qu'après le staging. C'est une TMA. Ce n'est pas un projet de six mois.
Si votre prestataire refuse la préprod « parce que ça double le travail », il vous vend du risque. Tester WordPress en local et en préprod, c'est le travail. La production n'est que la dernière répétition.
🔎 Données de prod : ce qu'on copie, ce qu'on masque
Les contenus publics, on les copie. Les commandes et les comptes, on les échantillonne et on les anonymise (e-mails en +test, cartes absentes, tokens régénérés). Une préprod qui est un miroir parfait des clients est un second site à protéger comme la prod, sans en avoir les moyens. La TMA n'a pas besoin de 40 000 commandes pour tester un panier.
Les uploads : on copie un sous-ensemble, ou on sert les médias de prod en lecture seule derrière un domaine de preview, avec prudence (hotlink, auth). Un clone de 80 Go « pour être vrai » n'est pas un clone de travail. C'est une copie de musée.
🛠️ Quand le local ment, et comment s'en servir quand même
Windows vs Linux, Docker vs l'hébergeur, absence d'object cache, absence de CDN : le local dira « c'est bon » trop tôt. On s'en sert pour le code et les fatals, pas pour signer une mise en production. La préprod signe. Le local accélère.
Les équipes qui n'ont que le local finissent par tester en prod « parce que ça marchait chez moi ». C'est la phrase à interdire. Tester un site WordPress en local et en préprod, c'est la phrase à imposer. Les deux mots comptent.
Tester en prod, ce n'est pas du courage. C'est de la loterie.
