Une mise à jour de plugin déployée directement en production et votre site affiche une page blanche. Votre boutique est inaccessible, les commandes ne passent plus et le retour arrière prend du temps si aucune sauvegarde récente n’a été faite. Ce scénario arrive et est évitable. Tester les modifications sur une copie isolée du site avant de les appliquer en production, c’est ce que permet un environnement de staging. De nos jours, un certain nombre d’hébergeurs web comme Gladhost proposent ce type d’environnement dans leurs offres d’infogérance pour éviter que la phase de test se fasse aux dépens des visiteurs.
Qu’est-ce qu’un environnement de staging ?
Un environnement de staging est une copie conforme de votre site de production, hébergée séparément et inaccessible au public. Il reprend la même configuration serveur, le même CMS, la même base de données et les mêmes fichiers. Ce que vous y faites n’a donc aucun impact sur le site en ligne.
Il se distingue du développement local, qui tourne sur la machine du développeur et ne reflète pas toujours fidèlement les conditions réelles du serveur. Il se distingue aussi de la préproduction, terme utilisé dans les projets pour désigner un environnement intermédiaire entre le développement et la mise en ligne, souvent soumis à validation client.
Le staging est directement calqué sur la production. L’URL est ainsi protégée par un mot de passe ou restreinte à certaines adresses IP. La base de données peut être une copie complète ou une version anonymisée si elle contient des données personnelles. C’est le cas sur toute boutique en ligne.
Qu’est-ce que l’on teste en staging ?
La majorité des incidents en production surviennent après une modification :
- mise à jour du CMS
- installation d’un nouveau plugin
- changement de configuration PHP
- refonte d’une partie du thème…
Le staging intercepte les problèmes avant qu’ils atteignent les visiteurs. Les mises à jour de WordPress, PrestaShop ou Magento sont le cas le plus fréquent. Une version majeure peut malencontreusement introduire des incompatibilités avec des modules tiers ou modifier le comportement de fonctions utilisées par le thème. Tester la mise à jour en staging prend moins d’une heure. Alors que corriger une régression en production demande beaucoup plus de temps.
Les modifications de thème ou de CSS se font également en staging. Un changement d’affichage qui paraît anodin sur un écran desktop peut casser la mise en page mobile ou perturber le tunnel de commande sur certains navigateurs. Les changements de configuration serveur, version de PHP, paramètres de cache ou règles de réécriture d’URL, sont les plus risqués à tester directement en production. Le staging est donc parfaitement utile.
Ce que votre hébergeur doit proposer pour votre environnement de staging
Le premier point à vérifier est la synchronisation. Tester sur une copie de votre site vieille de trois mois n’a pas grand intérêt car les plugins, le thème et la base de données ont évolué depuis. L’hébergeur doit permettre de rafraîchir le staging depuis la production sans perdre les modifications en cours de test.
L’accès SSH et l’accès à la base de données est indispensable pour intervenir au-delà de l’interface du CMS. Certains hébergeurs mutualisés le restreignent ou le facturent en option.
La bascule en production doit aussi être simple. Valider des modifications en staging pour ensuite les reporter manuellement fichier par fichier annule une partie du bénéfice.
Comment mettre en place un staging sur WordPress, PrestaShop et Magento ?
Sur WordPress, les plugins WP Staging ou Duplicator permettent de créer une copie du site en quelques clics depuis l’interface d’administration. WP Staging génère un sous-domaine isolé avec sa propre base de données. C’est la méthode la plus rapide pour un site sans contrainte technique particulière.
Sur PrestaShop ou Magento, la mise en place est plus manuelle. Elle passe par un dump de la base de données, une copie des fichiers via FTP ou SSH, et l’adaptation des fichiers de configuration pour pointer vers la nouvelle base. Il faut aussi modifier le fichier robots.txt et ajouter une protection par mot de passe sur le domaine de staging pour éviter toute indexation par Google.
FAQ à propos de l’environnement de staging
Un environnement de staging est-il indexé par Google ?
S’il est correctement protégé, non il ne l’est pas. Un staging accessible publiquement sans restriction peut être crawlé et indexé, ce qui crée du contenu dupliqué. La bonne pratique est plutôt de le protéger par un mot de passe ou de le restreindre à certaines adresses IP, et d’ajouter une directive noindex dans le fichier robots.txt.
Faut-il un nom de domaine séparé pour son environnement de staging ?
Un sous-domaine du domaine principal suffit, comme par exemple staging.monsite.com. Certains hébergeurs génèrent automatiquement un sous-domaine temporaire dédié à cet usage.
Devez-vous copier en staging les données clients présentes en production ?
C’est une question de conformité RGPD. Copier une base de données contenant des données personnelles dans un environnement moins sécurisé que la production expose en effet à des risques. La bonne pratique est d’anonymiser les données sensibles avant de les importer en staging.
Un environnement de staging ralentit-il le serveur de production ?
Si le staging est hébergé sur le même serveur que la production, il consomme une partie des ressources disponibles. Sur un hébergement infogéré ou dédié, il est possible d’isoler les deux environnements pour éviter toute contention.
Une mise à jour de plugin déployée directement en production et votre site affiche une page blanche. Votre boutique est inaccessible, les commandes ne passent […]