Comment créer un site de staging PrestaShop

Pourquoi nous utilisons des boutiques de staging pour chaque projet que nous touchons

Chez mypresta.rocks, nous faisons tourner plusieurs environnements de staging côte à côte, dont ps9-dev, ps8-dev, ps178-dev et ps176-dev, ainsi que des boutiques propres à chaque client lorsqu'un projet a besoin de son propre clone. Ce n'est pas un luxe. C'est ainsi que nous testons chaque mise à jour de module, chaque montée de version PrestaShop et chaque changement de thème avant qu'un seul client ne les voie. Après une décennie passée à livrer des modules, nous n'avons jamais rencontré de marchand qui ait regretté d'en avoir mis une en place, et beaucoup ont regretté de s'en être passés.

Le schéma est toujours le même : une mise à jour de module passe en production sans avoir été testée, la page d'accueil casse à 9h, le ticket de support arrive à 9h05, et l'heure qui suit se passe à déboguer devant de vrais clients. Une boutique de staging coûte une heure à construire et transforme ce scénario en un correctif de 20 minutes sur une URL que personne ne peut voir.

Le coût d'une heure d'indisponibilité pendant une promotion dépasse de deux ordres de grandeur le coût de maintien d'un environnement de test. Si vous vendez sur internet pour gagner votre vie, vous avez besoin d'une boutique de staging.

Ce qu'est réellement une boutique de staging

C'est un clone complet de votre boutique de production (mêmes fichiers, même base de données, même ensemble de modules) servi depuis une URL que vous seul et votre équipe pouvez atteindre. Mêmes chemins de code que ceux que vos clients empruntent, même logique métier, mêmes cas limites. Les seules différences sont le nom d'hôte, les identifiants et (si vous l'avez configurée correctement) le fait qu'aucun e-mail réel ne soit envoyé et qu'aucune carte réelle ne soit débitée.

Ce n'est pas un environnement de développement pour des travaux partant de zéro, et ce n'est pas une sauvegarde. Nous avons vu ces deux idées fausses coûter de l'argent bien réel aux marchands : le staging est écrasé dès que vous le rafraîchissez, donc tout ce que vous y avez construit sans le pousser en production est perdu.

Ce qu'est le staging

• Une copie fonctionnelle de vos fichiers et de votre base de données de production
• Sur un domaine ou un sous-domaine distinct (nous utilisons staging.yourshop.com ou dev.yourshop.com)
• Verrouillé derrière une liste blanche d'IP ou une authentification basique pour que seule votre équipe y entre
• Là où les mises à jour de modules, les changements de thème et les montées de version PHP sont répétés à blanc

Ce qu'il n'est pas

• Un bac à sable de développement pour construire du code neuf à partir de zéro, c'est une boutique de développement distincte
• Une sauvegarde. Les sauvegardes sont immuables. Le staging est écrasé à chaque rafraîchissement.
• À configurer puis oublier. Une boutique de staging désynchronisée de la production depuis six mois ne détecte rien.

Option 1 : staging basé sur Docker (ce que nous utilisons)

Toutes nos boutiques de staging tournent sous Docker sur une seule machine TrueNAS. Chaque boutique est une pile docker-compose unique sur un réseau Docker partagé, conteneur PrestaShop, conteneur MySQL, Redis partagé, un point de montage pour le répertoire html, un pour les données MySQL. Nous pouvons lancer une nouvelle version de PS en moins de cinq minutes, et la démonter pour libérer de la RAM lorsque nous avons terminé. Une fois que vous aurez fait cela une fois, vous ne reviendrez jamais à « je vais simplement l'installer dans un sous-dossier de cPanel ».

Prérequis

• Un hôte Linux avec au moins 2 Go de RAM par boutique de staging (4 Go si vous voulez que l'administration soit réactive)
• Docker et Docker Compose installés et fonctionnels
• Un accès SSH à la fois à la production et au staging
• Vous êtes à l'aise avec le copier-coller de commandes shell

Étape 1 : le fichier compose

Créez un répertoire et un docker-compose.yml :

mkdir ~/your-shop-staging && cd ~/your-shop-staging

cat > docker-compose.yml <<'EOF'
version: '3.8'
services:
  prestashop:
    image: prestashop/prestashop:8.2
    container_name: <your-shop>
    ports:
      - "8080:80"
    environment:
      - DB_SERVER=db
      - DB_NAME=prestashop
      - DB_USER=root
      - DB_PASSWD=your_secure_password
    volumes:
      - ./html:/var/www/html
    depends_on:
      - db
    restart: unless-stopped

  db:
    image: mysql:5.7
    container_name: <your-shop>-db
    environment:
      - MYSQL_ROOT_PASSWORD=your_secure_password
      - MYSQL_DATABASE=prestashop
    volumes:
      - ./mysql:/var/lib/mysql
    restart: unless-stopped
EOF

Faites correspondre exactement le tag de l'image PrestaShop à votre version de production. Si la prod est en 1.7.8.11, utilisez prestashop/prestashop:1.7.8.11, pas 1.7. Nous avons vu des marchands courir après des bugs fantômes pendant des heures parce que le staging était en 1.7.8.10 et la prod en 1.7.8.11, un écart assez petit pour paraître identique, assez grand pour se comporter différemment.

Étape 2 : exporter la production

Connectez-vous en SSH à la prod et lancez mysqldump. Utilisez --single-transaction sur une boutique en direct pour ne pas verrouiller la table des commandes pendant que des clients passent à la caisse :

# Sur votre serveur de production
mysqldump --single-transaction -u root -p prestashop > ~/prestashop_backup.sql

# Télécharger vers votre machine locale / serveur de staging
scp user@production-server:~/prestashop_backup.sql ./

Étape 3 : importer dans le staging

# Démarrer les conteneurs
docker compose up -d

# Attendre ~30 secondes que MySQL s'initialise, puis importer
docker exec -i <your-shop>-db mysql -u root -pyour_secure_password prestashop < prestashop_backup.sql

Si MySQL se plaint du jeu de caractères à l'import, placez SET NAMES utf8mb4; en haut du fichier SQL. Nous avons passé plus de temps que nous ne voudrions l'admettre à déboguer de l'UTF-8 doublement encodé sur le staging qui n'existait pas en production.

Étape 4 : copier les fichiers de production

# Synchroniser vos fichiers de production vers le répertoire html du staging
rsync -avz --delete \\
  user@production-server:/var/www/html/ \\
  ./html/ \\
  --exclude='var/cache/*' \\
  --exclude='var/logs/*' \\
  --exclude='app/config/parameters.php'

Excluez toujours parameters.php de rsync. Les identifiants de base de données qui s'y trouvent appartiennent à la production, si vous laissez rsync les recopier, votre boutique de staging tente de se connecter à votre base de données de production, ce qui est le pire résultat possible d'une « mise en place du staging ». Nous l'avons appris à nos dépens sur un projet client en 2017 et écrivons ce drapeau d'exclusion automatiquement depuis.

Excluez également tout répertoire d'exécution dans lequel la boutique écrit en production, plans de site, images générées dont vous n'avez pas besoin, dossiers de sauvegarde, clés de licence. rsync --delete efface le côté destination, et des rsync trop zélés ont effacé des plans de site générés et cassé Google Search Console plus d'une fois sous notre surveillance.

Étape 5 : réécrire les URL et vider le cache

La plus grande cause de « pourquoi ma boutique de staging ne fonctionne pas » : ps_shop_url pointe encore vers la production. Corrigez-le :

docker exec -i <your-shop>-db mysql -u root -pyour_secure_password prestashop -e "
  UPDATE ps_shop_url SET domain='staging.yourshop.com', domain_ssl='staging.yourshop.com' WHERE id_shop=1;
  UPDATE ps_configuration SET value='staging.yourshop.com' WHERE name IN ('PS_SHOP_DOMAIN','PS_SHOP_DOMAIN_SSL');
"

Mettez à jour html/app/config/parameters.php avec les identifiants de base de données du staging issus de votre fichier compose. Puis détruisez le cache :

docker exec <your-shop> rm -rf /var/www/html/var/cache/*

Si vous sautez le vidage du cache, les templates compilés de Smarty embarquent toujours l'URL de production et vous obtiendrez des boucles de redirection vers la boutique en direct. Sur toute boutique utilisant OPcache (c'est-à-dire toute boutique en production), redémarrez aussi PHP-FPM ou appelez l'endpoint de réinitialisation d'OPcache.

Option 2 : sous-domaine sur un hébergement mutualisé

Docker n'est pas disponible sur cPanel, Plesk ou DirectAdmin. Vous obtiendrez le même résultat avec un sous-domaine, une seconde base de données et une copie de fichiers.

Créer le sous-domaine

1. Dans le panneau d'hébergement, allez dans Sous-domaines ou Domaines
2. Ajoutez staging.yourshop.com
3. Faites-le pointer vers un nouveau répertoire comme /home/user/staging.yourshop.com

Créer une base de données distincte

1. Ouvrez Bases de données MySQL
2. Créez quelque chose comme user_staging
3. Créez ou attachez un utilisateur disposant de tous les privilèges dessus

Copier les fichiers et importer le dump

En SSH :

cp -r /home/user/public_html/* /home/user/staging.yourshop.com/

# Exporter la production
mysqldump -u user -p production_db > ~/staging_import.sql

# Importer dans le staging
mysql -u user -p staging_db < ~/staging_import.sql

Modifiez app/config/parameters.php (ou config/settings.inc.php sur la 1.6) pour pointer vers la nouvelle base de données, puis exécutez la même requête SQL de réécriture d'URL de l'Option 1, étape 5. N'oubliez pas de supprimer var/cache/ ensuite.

Option 3 : développement local avec XAMPP/MAMP

Très bien pour « laissez-moi vérifier l'écran d'administration de ce module pendant dix minutes », inutile pour quoi que ce soit d'autre. La version de PHP, la version de MySQL, le modèle de permissions de fichiers et les extensions au niveau de l'OS différeront tous de votre serveur de production. Nous utilisons nous-mêmes des piles locales, mais jamais comme test final avant le déploiement. Tout ce qui est sur le point de toucher la production est re-testé sur un staging hébergé sur serveur qui reflète l'environnement de prod.

Après la configuration : les choses qui vous mordent si vous les oubliez

Coupez les e-mails sortants immédiatement

Votre base de données de staging contient chaque adresse e-mail de client réel. Déclenchez une réinitialisation de mot de passe, une confirmation de commande ou un cron de notification de stock, et ces e-mails partent vers de vrais clients. Nous avons vu des marchands s'excuser publiquement parce que leur cron de staging avait envoyé « votre commande a été expédiée » à un millier de clients réels dont les commandes n'avaient, en réalité, pas été expédiées.

Allez dans Paramètres avancés → E-mail et soit :

• Réglez la méthode sur « Ne jamais envoyer d'e-mails » : la seule option entièrement sûre
• Acheminez tout via Mailtrap pour pouvoir tout de même inspecter les e-mails rendus sans les livrer

Désactivez les modules de paiement

Stripe, PayPal, Klarna, Adyen. Tout ce qui est relié à un compte marchand en direct. Soit désactivez entièrement les modules sur le staging, soit basculez chacun en mode bac à sable/test. Cela vaut également pour les API de transport (étiquettes UPS, DHL, GLS) et tout module qui appelle un service externe avec des effets de bord facturables.

Bloquez les moteurs de recherche

Une boutique de staging indexée par Google est un désastre de contenu dupliqué. Trois choses à faire, par mesure de double sécurité :

• Désactivez le plan de site XML dans Paramètres de la boutique → Trafic & SEO
• Déposez un robots.txt avec User-agent: * et Disallow: / à la racine
• Mieux encore, bloquez entièrement l'accès public (section suivante) pour que Google ne l'atteigne jamais en premier lieu

Verrouillez-la derrière une liste blanche d'IP

L'approche la plus fiable est une restriction d'IP au niveau d'Apache ou de Nginx. Le mode maintenance peut être contourné si le réglage de la liste blanche d'IP comporte un bug, et l'authentification HTTP Basic casse parfois les modules à forte composante AJAX (nous l'avons vu tuer nos propres panneaux d'administration lorsque le navigateur ne parvenait pas à transporter l'en-tête d'authentification à travers les requêtes XHR). Une liste blanche d'IP au niveau du serveur web intercepte tout avant même que PrestaShop ne s'exécute.

Garder le staging synchronisé avec la production

Une boutique de staging vieille de trois mois est pire qu'aucune boutique de staging. Elle vous donne une fausse confiance. Nous rafraîchissons les nôtres selon un calendrier et avant tout déploiement important.

Quand rafraîchir

• Avant tout changement significatif : mise à jour de module, montée de version du cœur, changement de version PHP, refonte de thème
• Une fois par mois au minimum si vous développez activement
• Après tout gros changement de catalogue en production, nouvelles arborescences de catégories, changements structurels de produits, réorganisation de caractéristiques/attributs

Script de rafraîchissement (Docker)

#!/bin/bash
# refresh-staging.sh : Récupère les dernières données de production dans le staging

# 1. Exporter la base de données de production
ssh production "mysqldump -u root -p'PASS' prestashop" > /tmp/staging_refresh.sql

# 2. Importer dans le staging
docker exec -i <your-shop>-db mysql -u root -p'your_secure_password' prestashop < /tmp/staging_refresh.sql

# 3. Corriger les URL
docker exec -i <your-shop>-db mysql -u root -p'your_secure_password' prestashop -e "
  UPDATE ps_shop_url SET domain='staging.yourshop.com', domain_ssl='staging.yourshop.com' WHERE id_shop=1;
  UPDATE ps_configuration SET value='staging.yourshop.com' WHERE name IN ('PS_SHOP_DOMAIN','PS_SHOP_DOMAIN_SSL');
"

# 4. Synchroniser les fichiers
rsync -avz --delete production:/var/www/html/ ./html/ --exclude='var/cache/*' --exclude='app/config/parameters.php'

# 5. Vider le cache
docker exec <your-shop> rm -rf /var/www/html/var/cache/*

echo "Staging refreshed."

Les erreurs que nous voyons encore les marchands commettre

Clés d'API de production laissées en place

Le nombre de boutiques de staging que nous avons auditées qui envoyaient discrètement de vrais débits Stripe, sollicitaient de vraies API de transport pour des étiquettes de suivi en direct, ou consommaient les limites de débit d'API en direct parce que les clés étaient arrivées avec la base de données, trop pour les compter. Faites tourner chaque identifiant externe vers une clé de bac à sable sur le staging dès que la base de données atterrit, avant même d'ouvrir l'interface d'administration.

Crons qui se déclenchent encore

Si vous avez mis en place des tâches cron en production (rappels de panier abandonné, synchronisation de stock, génération de flux, renouvellements de licence), vérifiez que votre panneau d'hébergement ou vos minuteries systemd n'exécutent pas les mêmes tâches sur le nom d'hôte du staging. Nous avons eu un client dont la boutique de staging envoyait joyeusement de vraies mises à jour de stock Allegro pendant deux semaines avant que quiconque ne s'en aperçoive.

Les deux interfaces d'administration ouvertes dans le même navigateur

Les cookies d'administration de PrestaShop sont rattachés au domaine, mais des conflits de session surviennent tout de même lorsque vous avez les deux boutiques authentifiées dans le même navigateur. Utilisez un navigateur distinct, un profil distinct ou une fenêtre de navigation privée pour le staging. Chaque membre de notre équipe dispose d'un profil Firefox dédié aux boutiques de staging des clients.

Quand tester sur le staging et quand la production suffit

Une heure bien investie

La première configuration de staging prend environ une heure. Un rafraîchissement, une fois le script en place, prend cinq minutes. La première fois que le staging détecte une mise à jour de module qui aurait cassé votre tunnel de commande, vous avez récupéré dix fois votre investissement, et nous l'avons vu se produire sur de vraies boutiques que nous exploitons. Docker est ce vers quoi nous nous tournerions si vous disposez d'un VPS ou d'une machine dédiée ; le clonage par sous-domaine est le bon choix sur un hébergement mutualisé. Dans les deux cas, l'objectif est le même : rien qui n'ait pas été testé ne touche vos clients.

Si vous mettez en place un staging spécifiquement pour tester nos modules, notre programme Essayez avant d’acheter vous offre une démo complète de 30 jours lorsqu’une option de démo est disponible, installez-le sur le staging, mettez-le à l'épreuve, décidez avant de payer.

Lectures complémentaires

• Comment tester correctement les modules PrestaShop : quoi faire concrètement une fois le staging en place
• Développement local PrestaShop : configuration XAMPP, WAMP, Docker et Linux : l'étape de développement local avant le staging
• Docker pour PrestaShop : configuration de l'environnement de développement : comment nous faisons tourner nos conteneurs en détail
• Configuration Docker pour PrestaShop : environnements de développement et de production
• Supprimer les commandes de test : nettoyer PrestaShop avant la mise en ligne

Modules associés

• Password Protection : verrouillez la boutique de staging derrière un mot de passe / une liste blanche d'IP
• MPR Cron Manager : contrôlez quels crons se déclenchent sur le staging
• Performance Revolution : testez les changements de performance avant qu'ils n'atteignent la production

Questions liées

• Comment vider correctement le cache PrestaShop ?
• MPR Digital Revolution peut-il proposer des téléchargements démo, essai ou gratuits pour des produits PrestaShop ?