Créer un site de préproduction (staging) pour WordPress et Laravel

Chaque développeur a son histoire de « petite modification rapide en production ». Une mise à jour d'extension qui a affiché une page blanche sur une boutique un vendredi après-midi. Une migration Laravel qui a verrouillé une table en plein pic de trafic. Une retouche de thème parfaite sur votre portable qui a cassé le tunnel de commande sur mobile. Un environnement de staging existe pour que ces histoires se passent là où personne ne regarde. Mais un staging mal fait provoque ses propres catastrophes : des clients qui reçoivent des e-mails de test, Google qui indexe un doublon de votre site, ou une « promotion » qui écrase une journée de vraies commandes. Voici comment bien faire du staging pour WordPress et Laravel.

Ce qu'est vraiment un environnement de staging

Le staging est une seconde copie d'un site de production, qui tourne sur la même pile logicielle, avec ses propres fichiers, sa propre base de données et sa propre adresse, généralement un sous-domaine comme staging.example.com. Les règles qui le rendent utile :

• La même pile que la production. Même version de PHP, mêmes extensions, même configuration du serveur web. Un staging en PHP 8.3 ne vous dit rien du comportement d'un changement sur le PHP 8.1 de la production. (Si vous hébergez plusieurs sites, voir faire tourner plusieurs versions de PHP par site.)
• Sa propre base de données. Ne pointez jamais le staging vers la base de production. Un test qui supprime des lignes supprime de vraies lignes.
• Des données récentes. Un staging copié il y a un an ne reproduit pas les bugs d'aujourd'hui. Rafraîchissez-le régulièrement depuis la production.
• Isolé du monde extérieur. Pas d'indexation par les moteurs de recherche, pas de vrais e-mails, pas de clés de paiement réelles.

Copier la production vers le staging

Le geste de base est le même pour toute application PHP : copier les fichiers, copier la base, puis corriger ce qui diffère.

# Fichiers (en excluant les caches et les gros envois inutiles)
rsync -a --delete --exclude 'wp-content/cache' \
  /var/www/site/public_html/ /var/www/site/staging/

# Base : export de la production, import dans la base de staging
mysqldump --single-transaction site_prod | mysql site_stg

--single-transaction vous donne un instantané cohérent des tables InnoDB sans verrouiller le site en ligne pendant l'export.

WordPress : remplacer les URL

WordPress stocke sa propre URL dans la base, souvent à l'intérieur de tableaux PHP sérialisés (réglages de widgets, données de constructeurs de pages). Un simple REPLACE() SQL corrompt les chaînes sérialisées car la longueur stockée ne correspond plus. Utilisez wp-cli, qui comprend la sérialisation :

wp --path=/var/www/site/staging search-replace \
  'https://example.com' 'https://staging.example.com' \
  --all-tables --precise --dry-run
# Le résultat vous convient ? Relancez sans --dry-run

Vérifiez ensuite que le wp-config.php du staging pointe vers la base de staging avec ses propres identifiants, et définissez define('WP_ENVIRONMENT_TYPE', 'staging'); pour que les extensions qui testent l'environnement se comportent en conséquence.

Laravel : un .env séparé

Laravel garde les différences d'environnement hors de la base, ce qui simplifie le staging. Le staging reçoit son propre .env :

APP_ENV=staging
APP_DEBUG=false
APP_URL=https://staging.example.com
DB_DATABASE=site_stg
MAIL_MAILER=log
QUEUE_CONNECTION=sync

Lancez d'abord php artisan migrate sur le staging. Si une migration échoue ou prend dix minutes sur une copie des vraies données, vous venez d'apprendre ce que la production vous aurait appris à la dure. Videz et reconstruisez le cache de configuration (php artisan config:cache) après avoir modifié .env, sinon Laravel continue d'utiliser les anciennes valeurs.

Gardez le staging invisible et inoffensif

C'est là que la plupart des stagings échouent.

• Bloquez les moteurs de recherche. Une copie publique de votre site est du contenu dupliqué. Protégez le staging par une authentification HTTP basique, qui écarte à la fois les robots et les curieux. Au minimum, envoyez un en-tête noindex :

add_header X-Robots-Tag "noindex, nofollow" always;

Sous WordPress, cochez aussi « Demander aux moteurs de recherche de ne pas indexer ce site » (wp option update blog_public 0). Un simple Disallow dans robots.txt ne suffit pas : il empêche l'exploration, pas l'indexation de liens trouvés ailleurs.

• Coupez les e-mails sortants. Une base de boutique copiée contient de vraies adresses clients. Une seule exécution de cron sur le staging peut envoyer « votre commande a été expédiée » à des centaines de personnes. Sous Laravel, utilisez MAIL_MAILER=log ; sous WordPress, une extension qui intercepte les e-mails ou un bac à sable comme Mailpit.
• Passez les clés de paiement en mode test. Stripe, PayPal et consorts ont tous des clés sandbox. Le staging ne doit jamais contenir de clés réelles.
• Désactivez ou isolez les tâches planifiées. Les crons, workers de file d'attente et webhooks qui parlent à des tiers (synchro CRM, export ERP) doivent être coupés ou pointés vers des points de test.
• Anonymisez si possible. Pour les agences qui traitent des données clients, épurer les données personnelles sur le staging est souvent une attente du RGPD, pas seulement une politesse.

La promotion : l'étape qui demande le plus de soin

« Pousser le staging en production » sonne comme une seule action. Ce sont en réalité deux actions très différentes :

• Le code et les fichiers passent du staging à la production. C'est généralement sûr et c'est ce que vous voulez.
• La base de données, c'est là que ça devient dangereux. Entre votre dernière synchronisation et maintenant, la production a continué d'enregistrer des commandes, des commentaires, des formulaires et de nouveaux utilisateurs. Écraser la base de production avec la copie de staging jette tout cela.

Règles pratiques :

1. Sauvegardez la production juste avant de promouvoir. Fichiers et base, stockés hors du serveur. (Voir sauvegardes de sites chiffrées vers S3.)
2. Promouvez les fichiers librement, la base rarement. Pour des sites de contenu qui évoluent lentement, une promotion complète juste après une synchronisation fraîche convient. Pour les boutiques et les sites à espace membre, rejouez les changements de base sous forme de migrations (Laravel) ou refaites les réglages à la main plutôt que de copier toute la base.
3. Rafraîchissez le staging juste avant le travail, pas des semaines avant. Plus l'écart entre synchronisation et promotion est court, moins les données de production sont exposées.
4. Promouvez dans une fenêtre calme et vérifiez le site en ligne juste après : page d'accueil, commande ou connexion, journal d'erreurs PHP.
5. Inversez le remplacement d'URL. Si vous recopiez une base WordPress, lancez le search-replace dans l'autre sens, sinon le site en ligne se mettra à pointer vers le sous-domaine de staging.

Les pièges courants

• Un staging pointé « temporairement » vers la base de production.
• Des moteurs de recherche qui indexent le sous-domaine de staging parce que personne n'a ajouté d'authentification ni de noindex.
• Des e-mails de test qui atteignent de vrais clients depuis une table de commandes copiée.
• Une version de PHP différente sur le staging, si bien que les bugs n'apparaissent qu'après la promotion.
• La promotion d'une base de staging périmée qui efface silencieusement une semaine de commandes.
• Oublier de mettre à jour le staging après des changements en production, si bien que les tests portent sur le passé.
• Des chemins ou noms d'hôte de production codés en dur dans des fichiers de configuration (extensions de cache, réglages de cache objet, configuration Laravel personnalisée), si bien que le staging écrit discrètement dans le cache ou le stockage de la production.
• Une même base Redis ou un même dossier d'envois partagés entre les deux environnements, si bien qu'un vidage de cache ou un fichier supprimé sur le staging touche aussi le site en ligne.

Comment ShadowPanel gère le staging

ShadowPanel est un panel d'hébergement auto-hébergé, et sur les offres Pro et Agency chaque site peut disposer d'un environnement de staging :

• Création en un clic. Le panel provisionne un sous-domaine staging. du site avec sa propre racine de documents et sa propre base de données dédiée, sur la même version de PHP que la production.
• Rafraîchir depuis la production. Une action écrase le staging avec une copie fraîche du site de production, pour tester sur des données actuelles.
• Promouvoir quand c'est prêt. Une autre action pousse la copie de staging en ligne, derrière une étape de confirmation, avec le journal de la dernière synchronisation affiché dans le panel.
• Supprimer proprement. Retirez l'environnement de staging et sa base quand le projet est terminé.
• Complémentaire du reste du panel. Faites une sauvegarde à la demande de la production avant une promotion et, sur les sites WordPress, utilisez le WordPress Toolkit pour essayer d'abord les mises à jour sur le staging. (Plus de détails sur cette routine dans gérer de nombreux sites WordPress.)

Les réglages propres à l'environnement restent entre vos mains : identifiants de staging dans wp-config.php ou .env, remplacement des URL, réglages d'e-mail et de paiement, protection contre l'indexation. Ils dépendent de votre application, et la liste ci-dessus les couvre.

En résumé

Le staging est une assurance peu coûteuse, tant qu'il s'agit d'une copie fidèle qui ne peut nuire à personne : même pile, sa propre base, des données récentes, pas d'indexation, pas de vrais e-mails, pas de clés réelles. Traitez la promotion comme l'étape risquée qu'elle est : sauvegardez d'abord, déplacez les fichiers librement, et ne déplacez la base que lorsque vous êtes sûr que rien de nouveau ne s'est passé en production. ShadowPanel offre à chaque site Pro et Agency une copie de staging que vous pouvez créer, rafraîchir et promouvoir depuis le panel.

curl -fsSL https://shadowpanel.de/install.sh | bash

Voir les tarifs et télécharger →