Un environnement de staging n’a de valeur que s’il ressemble suffisamment à la production pour que les tests qu’on y fait soient représentatifs. On a vu trop de projets où le « staging » tournait sur une version de PHP différente, avec des plugins désactivés pour gagner en performance, et un contenu vieux de six mois — bref, un environnement qui valide tout, jusqu’au jour où la vraie mise en production révèle un problème que le staging n’avait aucune chance de détecter.
Voici comment on structure nos environnements de staging pour qu’ils remplissent réellement leur rôle : détecter les problèmes avant qu’ils n’atteignent les visiteurs.
Le principe : un miroir aussi fidèle que possible
Trois éléments doivent être identiques entre staging et production, sans exception :
- La version de PHP, et idéalement la version du serveur web et de MySQL
- La liste des plugins actifs, avec les mêmes versions
- La structure de la base de données — le contenu peut différer légèrement, la structure jamais
Sur nos serveurs, on utilise des sous-domaines dédiés du type staging.site.fr ou site.dev.wordpress-developpement.fr pointant vers la même infrastructure d’hébergement que la production, avec une configuration PHP-FPM identique. C’est la garantie qu’un problème de compatibilité de version ne se révèle jamais en surprise le jour du déploiement.
Bloquer l’indexation, sans exception
Un staging accessible publiquement et indexé par Google pose deux problèmes : du contenu dupliqué qui peut nuire au référencement du site principal, et une exposition inutile d’un environnement de test. On bloque systématiquement l’indexation à deux niveaux, jamais un seul :
# Dans le fichier robots.txt du staging
User-agent: *
Disallow: /// Dans le mu-plugin ou functions.php du staging, en complément du robots.txt
add_action( 'pre_option_blog_public', function () {
return '0';
} );
La combinaison des deux est volontaire : un robots.txt seul n’empêche pas l’indexation d’une page déjà liée ailleurs, alors que l’option blog_public à 0 ajoute une balise noindex sur toutes les pages du site. On ajoute parfois une authentification HTTP basique par-dessus, en particulier pour les projets avec des contenus sensibles avant leur publication officielle.
Synchroniser la base à sens unique
La règle la plus importante, et la plus souvent transgressée : les données circulent de la production vers le staging, jamais l’inverse. Un staging sert à tester du code contre des données réelles, pas à préparer du contenu qui remontera ensuite en production — cette dernière pratique mène systématiquement à des conflits et des pertes de contenu.
#!/bin/bash
# synchro-staging.sh : à lancer depuis le serveur, jamais l'inverse
wp db export - --path=/var/www/production | \
ssh deploy@serveur-staging "wp db import - --path=/var/www/staging"
ssh deploy@serveur-staging "wp search-replace 'https://site.fr' 'https://staging.site.fr' \
--path=/var/www/staging --skip-columns=guid"On planifie généralement cette synchronisation une fois par semaine, ou à la demande avant une phase de tests importante, jamais en temps réel : ça laisserait penser au staging qu’il reflète l’instant présent, alors qu’un décalage de quelques jours est en général sans conséquence pour tester une fonctionnalité.
Ce que le staging doit valider avant chaque déploiement
| Vérification | Pourquoi c’est important |
|---|---|
| Mise à jour de plugins | Détecter une incompatibilité avant qu’elle touche les visiteurs |
| Changement de thème ou de template | Vérifier l’affichage sur du contenu réel, pas des données de démonstration |
| Migration de champs personnalisés | S’assurer qu’aucune donnée n’est perdue pendant la transformation |
| Montée de version majeure de WordPress | Repérer les avertissements de dépréciation avant la production |
Un staging qu’on ne synchronise jamais avec la production finit par mentir. Mieux vaut un staging synchronisé une fois par mois de façon fiable qu’un staging « toujours à jour » en théorie mais oublié depuis six mois en pratique.
Automatiser plutôt que de compter sur la mémoire
On documente systématiquement la procédure de synchronisation dans un script exécutable, jamais dans une suite de commandes à retaper de mémoire. Sur les projets suivis par plusieurs personnes, ce script fait partie du dépôt Git au même titre que le code, avec un README qui explique quand et comment l’utiliser.
En résumé
Un environnement de staging n’a de valeur que s’il ressemble réellement à la production sur les points qui comptent : version de PHP, plugins actifs, structure de base. Bloquer son indexation, synchroniser les données à sens unique et documenter la procédure sont les trois habitudes qui transforment un staging décoratif en véritable filet de sécurité avant chaque mise en production.
