Comment créer un site de staging PrestaShop

Pourquoi vous avez besoin d'un site de staging

Tout propriétaire de boutique PrestaShop finit par faire face au même dilemme : vous devez mettre à jour un module, modifier votre thème ou tester une nouvelle fonctionnalité — mais le faire sur votre boutique en ligne risque de casser quelque chose dont vos clients dépendent. Un site de staging résout ce problème en vous offrant une copie identique de votre boutique où vous pouvez tester librement sans conséquences.

Si vous avez déjà mis à jour un module et vu votre page d'accueil se casser, ou installé un nouveau thème pour découvrir que votre processus de commande ne fonctionnait plus — un environnement de staging aurait détecté cela avant qu'un seul client ne le voie.

Un site de staging n'est pas un luxe — c'est le strict minimum pour gérer une boutique e-commerce professionnelle. Le coût d'une heure d'indisponibilité pendant un pic de trafic dépasse largement l'effort de maintenance d'un environnement de test.

Qu'est-ce qu'un site de staging exactement ?

Un site de staging est un clone complet de votre boutique de production — même base de données, mêmes fichiers, même configuration — fonctionnant sur une URL séparée à laquelle seul vous (et votre équipe) pouvez accéder. Il ressemble et se comporte exactement comme votre vraie boutique, mais les clients ne le voient jamais.

Considérez-le comme une répétition générale. Vous testez tout sur le staging d'abord, confirmez que tout fonctionne, puis appliquez les mêmes modifications à votre boutique en ligne.

Ce qu'un site de staging EST

• Une copie exacte des fichiers et de la base de données de votre boutique de production
• Fonctionnant sur un domaine ou sous-domaine séparé (par ex., staging.yourshop.com)
• Protégé par mot de passe ou restreint par IP pour que seule votre équipe puisse y accéder
• Un endroit sûr pour tester les mises à jour, les nouveaux modules, les modifications de thème et les mises à niveau PHP

Ce qu'un site de staging N'EST PAS

• Un environnement de développement pour créer du code personnalisé à partir de zéro (c'est un environnement de dev)
• Une solution de sauvegarde (les sauvegardes sont séparées — ne comptez jamais sur le staging comme unique sauvegarde)
• Quelque chose que vous configurez une fois et que vous oubliez — il doit être rafraîchi régulièrement à partir de la production

Option 1 : Staging basé sur Docker (recommandé)

Docker est de loin la méthode la plus propre pour faire fonctionner un environnement de staging PrestaShop. Il vous offre des environnements isolés et reproductibles que vous pouvez démarrer et arrêter en quelques minutes. C'est ce que nous utilisons en interne pour tout notre développement et nos tests de modules.

Prérequis

• Un serveur Linux ou VPS avec au moins 2 Go de RAM (4 Go recommandés)
• Docker et Docker Compose installés
• Un accès SSH à la fois à votre serveur de production et à votre serveur de staging
• Une aisance de base avec la ligne de commande

Étape 1 : Configurer l'environnement Docker

Créez un répertoire pour votre projet de staging et un fichier docker-compose.yml :

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

cat > docker-compose.yml <<'EOF'
version: '3.8'
services:
  prestashop:
    image: prestashop/prestashop:8.2
    container_name: staging-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: staging-shop-db
    environment:
      - MYSQL_ROOT_PASSWORD=your_secure_password
      - MYSQL_DATABASE=prestashop
    volumes:
      - ./mysql:/var/lib/mysql
    restart: unless-stopped
EOF

Important : Faites correspondre la version de l'image PrestaShop avec votre version de production. Si vous utilisez PS 1.7.8, utilisez prestashop/prestashop:1.7.8. Si c'est PS 8.1, utilisez prestashop/prestashop:8.1.

Étape 2 : Exporter votre base de données de production

Connectez-vous en SSH à votre serveur de production et exportez la base de données :

# On your production server
mysqldump -u root -p prestashop > ~/prestashop_backup.sql

# Download to your local machine / staging server
scp user@production-server:~/prestashop_backup.sql ./

Étape 3 : Importer dans le staging

# Start the containers
docker compose up -d

# Wait ~30 seconds for MySQL to initialize, then import
docker exec -i staging-shop-db mysql -u root -pyour_secure_password prestashop < prestashop_backup.sql

Étape 4 : Copier les fichiers de production

# Sync your production files to the staging html directory
rsync -avz --delete \
  user@production-server:/var/www/html/ \
  ./html/ \
  --exclude='var/cache/*' \
  --exclude='var/logs/*' \
  --exclude='app/config/parameters.php'

Étape 5 : Mettre à jour la configuration

Après l'importation, mettez à jour l'URL de la boutique dans la base de données pour pointer vers votre domaine de staging :

docker exec -i staging-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');
"

Ensuite, mettez à jour html/app/config/parameters.php avec les identifiants de la base de données de staging (correspondant à votre docker-compose.yml).

Enfin, videz le cache :

docker exec staging-shop rm -rf /var/www/html/var/cache/*

Option 2 : Sous-domaine sur hébergement mutualisé

Si vous êtes sur un hébergement mutualisé (cPanel, Plesk, DirectAdmin), Docker n'est pas disponible. À la place, vous allez créer un sous-domaine avec sa propre racine de documents et sa propre base de données.

Étape 1 : Créer le sous-domaine

Dans votre panneau d'hébergement :

1. Allez dans Sous-domaines ou Domaines
2. Créez staging.yourshop.com
3. Pointez-le vers un nouveau répertoire, par ex., /home/user/staging.yourshop.com

Étape 2 : Créer une nouvelle base de données

Dans votre panneau d'hébergement :

1. Allez dans Bases de données MySQL
2. Créez une nouvelle base de données (par ex., user_staging)
3. Créez ou assignez un utilisateur avec tous les privilèges sur cette base de données

Étape 3 : Copier les fichiers

Utilisez SSH ou le gestionnaire de fichiers pour copier l'intégralité de votre installation PrestaShop dans le répertoire de staging. Si vous disposez de SSH :

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

Étape 4 : Exporter et importer la base de données

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

# Import to staging
mysql -u user -p staging_db < ~/staging_import.sql

Étape 5 : Mettre à jour la configuration

Éditez app/config/parameters.php (ou config/settings.inc.php sur PS 1.6) pour pointer vers la base de données de staging. Mettez à jour les URL de la boutique dans la base de données comme indiqué dans l'Option 1, Étape 5.

Option 3 : Développement local avec XAMPP/MAMP

Pour des tests locaux rapides, XAMPP (Windows/Linux) ou MAMP (macOS) fonctionnent très bien. Le processus est similaire à l'hébergement mutualisé — créez une base de données, copiez les fichiers, importez le dump, mettez à jour la configuration. C'est la méthode la plus rapide pour les développeurs travaillant seuls qui ont juste besoin de tester un module rapidement.

L'inconvénient est que votre environnement local peut différer de la production (version PHP différente, version MySQL différente, extensions manquantes), donc effectuez toujours un test final sur un staging basé sur un serveur avant de déployer en production.

Étapes essentielles après l'installation

Désactiver les e-mails sortants

C'est essentiel. Votre site de staging contient une copie de votre base de données de production, ce qui signifie qu'il contient de vraies adresses e-mail de clients. Si vous déclenchez une confirmation de commande ou une réinitialisation de mot de passe sur le staging, ces e-mails seront envoyés à de vrais clients.

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

• Définissez la méthode d'envoi sur « Ne jamais envoyer d'e-mails » (le plus sûr), ou
• Redirigez tous les e-mails sortants vers une adresse de test en utilisant un outil comme Mailtrap

Désactiver les passerelles de paiement

Si votre site de staging est connecté à des processeurs de paiement en production (Stripe, PayPal), désactivez-les immédiatement. Vous ne voulez pas de débits accidentels sur de vraies cartes. Soit :

• Désactivez tous les modules de paiement sur le staging, ou
• Passez-les en mode sandbox/test

Bloquer les moteurs de recherche

Empêchez votre site de staging d'être indexé par les moteurs de recherche — le contenu dupliqué est un cauchemar pour le SEO :

• Allez dans Paramètres de la boutique → Trafic et SEO et désactivez le sitemap
• Ajoutez un robots.txt qui bloque tous les robots : User-agent: * / Disallow: /
• Mieux encore, restreignez complètement l'accès (voir ci-dessous)

Restreindre l'accès

Votre site de staging ne devrait pas être accessible publiquement. Options :

• Liste blanche d'IP via .htaccess : N'autorisez que l'IP de votre bureau/domicile
• Authentification HTTP basique : Ajoutez une invite de mot de passe via .htaccess
• Mode maintenance PrestaShop : Activez-le et ajoutez votre IP en liste blanche dans Back Office → Paramètres de la boutique → Général → Maintenance

Nous recommandons la liste blanche d'IP dans .htaccess comme méthode la plus fiable — le mode maintenance peut être contourné, et l'authentification basique entre parfois en conflit avec les modules utilisant intensivement Ajax.

Maintenir le staging synchronisé

Un site de staging n'est utile que s'il reflète votre environnement de production actuel. Rafraîchissez-le régulièrement :

Quand rafraîchir

• Avant toute mise à jour majeure (mise à niveau du cœur PrestaShop, mise à jour importante d'un module)
• Au moins une fois par mois si vous développez activement
• Après des modifications significatives du catalogue (nouvelles catégories, modification de la structure des produits)

Script de rafraîchissement rapide (Docker)

#!/bin/bash
# refresh-staging.sh — Pull latest production data into staging

# 1. Dump production DB
ssh production "mysqldump -u root -p'PASS' prestashop" > /tmp/staging_refresh.sql

# 2. Import to staging
docker exec -i staging-shop-db mysql -u root -p'your_secure_password' prestashop < /tmp/staging_refresh.sql

# 3. Fix URLs
docker exec -i staging-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. Sync files
rsync -avz --delete production:/var/www/html/ ./html/ --exclude='var/cache/*' --exclude='app/config/parameters.php'

# 5. Clear cache
docker exec staging-shop rm -rf /var/www/html/var/cache/*

echo "Staging refreshed."

Erreurs courantes à éviter

Utiliser les clés API de production sur le staging

Si votre boutique de production se connecte à Stripe, PayPal, des API de transport ou tout autre service externe — ces clés API sont maintenant aussi sur votre site de staging. Passez toujours aux clés sandbox/test sur le staging pour éviter :

• De débiter de vrais clients à partir de commandes de test
• D'envoyer de vraies demandes d'expédition aux transporteurs
• D'atteindre les limites de requêtes API qui affectent votre boutique en ligne

Oublier de désactiver les tâches cron

Si votre boutique de production a des tâches cron (rappels de panier, synchronisation de stock, génération de flux), ces tâches cron peuvent aussi s'exécuter sur le staging si les URL sont similaires. Désactivez ou commentez toutes les entrées cron liées au staging.

Tester avec la boutique en ligne ouverte dans un autre onglet

Si vous êtes connecté à la fois au back office de votre staging et de votre production dans le même navigateur, les cookies peuvent entrer en conflit. Utilisez un navigateur séparé ou une fenêtre de navigation privée pour le staging.

Quand tester sur le staging vs. la production

Résumé

La mise en place d'un site de staging prend environ une heure la première fois. Le rafraîchir prend 5 minutes une fois que vous avez un script. L'investissement en temps est rentabilisé dès la première fois que vous détectez un changement qui casse quelque chose avant qu'il n'atteigne vos clients.

Docker est la meilleure approche si vous disposez d'un VPS ou d'un serveur dédié. Le clonage par sous-domaine fonctionne sur l'hébergement mutualisé. Dans tous les cas — l'important est que vous ayez quelque chose entre vos modifications de code et vos clients.

Si vous avez besoin d'aide pour mettre en place un environnement de staging afin de tester nos modules spécifiquement, consultez notre programme Essayez avant d'acheter — chaque module comprend une démonstration entièrement fonctionnelle de 30 jours que vous pouvez installer sur votre site de staging pour tester avant d'acheter.