10 meilleures pratiques de staging WordPress pour éviter les catastrophes sur le site en direct

Vous mettez à jour un plugin sur votre site en production car cela ne prend que 30 secondes. Puis votre page d'accueil devient blanche.

C'est arrivé à presque tous les propriétaires de sites WordPress à un moment donné.

Une mise à jour rapide, un petit changement, un moment « ça ira » qui n'allait pas. Et maintenant, vous regardez un écran blanc avec de vrais visiteurs essayant d'accéder à votre site.

C'est le problème qu'un site de staging résout. C'est une copie privée de votre site en production où vous testez les changements avant qu'ils n'approchent de la production. Si quelque chose casse sur le staging, personne ne le voit à part vous.

La plupart des utilisateurs occasionnels de WordPress savent que le staging existe. La plupart l'ignorent également car cela semble être du travail supplémentaire.

Je comprends. Mais après avoir vu une caisse WooCommerce planter en pleine vente à cause d'un conflit de plugin qui aurait pris deux minutes à détecter sur le staging, j'ai arrêté de le considérer comme facultatif.

Dans cet article, je vais vous montrer ce qu'est un site de staging, quand vous en avez besoin, comment en configurer un rapidement, et les pratiques qui rendent le staging utile en premier lieu.

Voici les points clés à retenir :

• Le staging n'est pas pour tous les changements. Les modifications mineures comme les fautes de frappe, les mises à jour de prix et les nouveaux articles ne nécessitent pas de flux de travail de staging.
• Tester contre une copie de votre site datant d'une semaine produit des résultats peu fiables. Rafraîchir le staging avant chaque série de changements résout entièrement ce problème.
• Pousser la base de données complète du staging vers la production détruit le contenu en production. Les commandes, les soumissions de formulaires et les inscriptions d'utilisateurs arrivés en production pendant que vous travailliez sur le staging sont écrasés. Poussez le code, pas la base de données.
• Un site de staging non bloqué nuit au référencement de votre site en production. La protection par mot de passe et les paramètres noindex sont non négociables.
• Le mode de débogage sur le staging révèle des erreurs qui sont cachées en production. Les notices et avertissements PHP qui existent silencieusement sur votre site en production apparaîtront ici en premier.
• Mettre à jour un plugin à la fois est la seule façon fiable de tracer un conflit. Les mises à jour groupées rendent impossible l'identification du changement qui a causé un problème.
• La sauvegarde avant le déploiement est ce qui rend un déploiement raté récupérable.
• Les anciens environnements de staging deviennent des vulnérabilités de sécurité. Supprimez-les lorsque vous avez terminé.

Table des matières

Le staging n’est pas une sauvegarde. Si votre site en direct plante, vous ne pouvez pas restaurer à partir du staging.

Ils servent des objectifs différents : les sauvegardes sont votre outil de récupération ; le staging est votre environnement de test.

Le staging n’est pas non plus la même chose qu’un environnement de développement local. Un environnement local s’exécute sur votre ordinateur, hors ligne, déconnecté des conditions réelles du serveur.

Le staging s’exécute sur un serveur réel à une URL réelle, il reflète donc la façon dont votre site se comporte réellement en production.

Si vous souhaitez effectuer une refonte complète ou créer un site à partir de zéro, des outils locaux comme XAMPP, WAMP ou MAMP sont pertinents. Pour tester les mises à jour et les modifications par rapport au comportement réel du serveur, le staging est l’option la plus fiable.

Et le staging n’est pas un second site permanent. C’est un environnement de travail temporaire. Vous apportez des modifications, vous les testez, vous publiez ce qui fonctionne, et vous réinitialisez ou rafraîchissez lorsque vous commencez le cycle suivant.

Quand utiliser un site de staging (et quand l'éviter)

Chaque article sur le staging vous dira de l’utiliser pour tout. Ce n’est pas réaliste, et suivre ce conseil mène à la fatigue du processus, où vous finissez par arrêter complètement d’utiliser le staging, y compris pour les modifications qui en ont réellement besoin.

Voici une approche plus honnête.

Modifications qui justifient le staging

Ce sont les situations où quelque chose qui tourne mal sur un site en direct a des conséquences réelles : ventes perdues, formulaires cassés, utilisateurs bloqués, ou une page d’accueil qui ne se charge pas.

Le coût en temps du staging n’est rien comparé au coût de récupération si l’une de ces situations tourne mal.

• Mises à jour du cœur de WordPress, en particulier les versions majeures
• Mises à jour de plugins ou de thèmes, en particulier WooCommerce, les constructeurs de pages et les plugins de sécurité
• Toute modification de votre version PHP ou de la configuration de votre serveur
• Ajout d’un nouveau plugin qui affecte le paiement, les formulaires ou la fonctionnalité globale du site
• Modifications de code personnalisé ou CSS qui touchent les modèles ou les fichiers de thème
• Refontes complètes ou modifications importantes de la mise en page

Modifications qui ne nécessitent pas de staging

Le staging a un coût. Créer un clone, apporter une modification et la renvoyer : c’est excessif pour des modifications qui ne comportent aucun risque réel.

• Correction d’une faute de frappe ou mise à jour d’un prix
• Publication d’un nouvel article de blog ou ajout d’un produit
• Modification d’un élément de menu ou ajustement d’un widget
• Mises à jour mineures d’images sans dépendance de code

Si quelque chose dans cette liste cassait votre site, la correction prendrait moins de temps que la configuration du staging. Gardez ce processus pour quand il en vaut la peine.

Comment configurer un site de staging WordPress

Si votre hébergeur propose un staging intégré, c’est un point de départ raisonnable. WP Engine, Kinsta et SiteGround l’incluent dans leurs tableaux de bord.

Si votre hébergeur ne le propose pas (ou si vous voulez quelque chose qui fonctionne de la même manière, quel que soit l’hébergement de votre site), Duplicator Pro est ce que j’utilise.

Il transforme n’importe quelle sauvegarde complète du site en un site de staging en quelques clics. Vous n’aurez pas besoin d’un compte d’hébergement séparé, du FTP ou d’un travail manuel sur la base de données.

Vous commencez par créer une sauvegarde complète de votre site.

Ensuite, allez à Staging » Créez votre premier site de staging.

Choisissez la sauvegarde que vous avez créée comme modèle pour le site de staging. Assurez-vous également de choisir un schéma de couleurs d'administrateur unique afin que votre tableau de bord de staging soit toujours différent.

Duplicator installera la sauvegarde comme un tout nouveau site de staging. Toutes les modifications apportées ici n'auront aucun impact sur votre site réel.

La méthode manuelle est également une option : configurez un sous-domaine ou un sous-répertoire, transférez les fichiers via FTP, dupliquez la base de données dans phpMyAdmin, mettez à jour vos identifiants wp-config.php, et synchronisez les URL dans la table wp_options. Cela fonctionne, mais il y a beaucoup d'étapes où l'on peut se tromper.

Pour plus de méthodes de staging, lisez notre article sur comment créer un site de staging WordPress.

10 meilleures pratiques de staging WordPress que chaque propriétaire de site devrait suivre

La mise en place du staging est la partie facile. Voici quelques bonnes pratiques de staging WordPress pour éviter les erreurs courantes :

• Commencez toujours par une sauvegarde récente. Votre point de récupération si la configuration du staging échoue ou si un changement poussé casse le site en direct.
• Base de données privée, bloquée aux index, séparée. Trois paramètres distincts qui empêchent chacun une catégorie différente de dommages.
• Miroir de votre environnement de production. La version PHP, le type de serveur, les couches de mise en cache et les règles de pare-feu doivent tous correspondre à la production, sinon vos résultats de test ne seront pas fiables.
• Activez le mode debug. Affiche les erreurs PHP sur le staging qui sont masquées par défaut sur votre site en direct.
• Une mise à jour à la fois. Le seul moyen de retracer un conflit jusqu'au changement spécifique qui l'a causé.
• Le staging comme dernière étape d'assurance qualité. Un passage de test complet couvrant la navigation, les formulaires, le processus de commande, le mobile et la vitesse des pages avant que quoi que ce soit ne soit mis en ligne.
• Code vers la production, pas vers la base de données. Pousser la base de données complète écrase le contenu en direct arrivé pendant que vous travailliez en staging.
• Rafraîchissez avant chaque cycle. Un staging obsolète donne des résultats peu fiables. Récupérez depuis la production avant chaque nouveau lot de changements.
• Sauvegardez la production avant de pousser. Prise immédiatement avant le déploiement, pas la veille.
• Nettoyage régulier. Supprimez les anciens environnements de staging lorsque vous avez terminé pour éviter la confusion et les failles de sécurité.

1. Commencez toujours par une sauvegarde fraîche

Avant de créer un environnement de staging, effectuez une sauvegarde complète de votre site de production. Si la configuration du staging tourne mal, vous avez un point de récupération propre.

Plus important encore, cette sauvegarde devient votre option de restauration si vous poussez des changements qui cassent quelque chose sur le site en direct.

Si vous avez créé un site de staging avec Duplicator, vous aurez déjà une sauvegarde récente de votre site. C'est la première étape du staging !

Pendant que vous créez la sauvegarde, je recommande d'en envoyer au moins une copie dans le cloud. Duplicator Cloud vous offre un tableau de bord de récupération hors site au cas où il arriverait quelque chose à votre vrai site.

2. Gardez le staging privé, bloquez l'indexation et utilisez une base de données séparée

Commencez par la protection par mot de passe. Votre URL de staging ne doit jamais être accessible publiquement, point final.

Toute personne qui y accède voit une version inachevée et potentiellement défectueuse de votre site. La plupart des hébergeurs et des plugins de staging gèrent cela automatiquement, mais vérifiez par vous-même plutôt que de supposer.

Bloquer les moteurs de recherche est une étape distincte et tout aussi importante. Allez dans Paramètres » Lecture dans le tableau de bord WordPress de votre staging et cochez Décourager les moteurs de recherche d’indexer ce site.

Duplicator devrait le faire automatiquement, mais cela ne coûte rien de vérifier.

Un site de staging non bloqué peut être indexé. Google ne fait pas toujours la distinction entre staging et production si l’URL est accessible, et les dommages SEO dus au contenu dupliqué peuvent affecter les classements de votre site en direct pendant des mois.

La règle de la base de données est différente mais tout aussi importante. Ne partagez jamais une base de données entre votre site en direct et votre staging.

Une base de données partagée signifie qu’une action de staging comme une sauvegarde accidentelle ou un changement de configuration peut écraser des données de production réelles. Vous pourriez perdre des commandes, des soumissions de formulaires, des comptes d’utilisateurs ou du contenu publié.

Gardez les bases de données complètement séparées. La plupart des configurations de staging le font par défaut, mais si vous effectuez une configuration manuelle, c’est la seule chose qui mérite une double vérification avant de commencer.

3. Reproduisez votre environnement de production aussi fidèlement que possible

Le but du staging est de tester ce qui se passera sur votre site en direct. Si le staging ne correspond pas à la production, les résultats des tests n’ont pas beaucoup de sens.

La version PHP est l’inadéquation la plus courante. Si votre environnement de staging utilise PHP 8.1 et la production PHP 8.3, un plugin qui fonctionne bien sur le staging peut générer des erreurs sur le site en direct.

Vérifiez que les deux environnements utilisent la même version avant de tester quoi que ce soit. Vous devrez peut-être mettre à niveau la version PHP d’un site.

Si vous utilisez Duplicator pour créer des sites de staging, créez-en un nouveau avant une nouvelle série de tests. Un ancien environnement ne sera pas une copie fidèle de votre site web.

Supprimez l’ancien site de staging, générez une copie fraîche de votre site web, et utilisez-la pour créer un nouveau site de staging.

La même logique s’applique à votre serveur web. Apache et Nginx gèrent certaines configurations différemment. Si les environnements sont différents, vous pouvez obtenir des bugs qui sont vraiment difficiles à tracer.

Les couches de cache sont également importantes, en particulier pour les tests de performance. Si la production utilise Redis ou Memcached et que le staging ne le fait pas, tous les benchmarks de vitesse de page que vous exécutez sur le staging ne refléteront pas les conditions réelles.

Miroir la configuration du cache, ainsi que vos règles de pare-feu et de sécurité. Un plugin de sécurité ou une règle WAF active sur la production mais pas sur le staging peut causer des conflits que vous ne découvrirez qu’après le déploiement.

Plus la correspondance est étroite, plus vous pouvez faire confiance à ce que le staging vous dit.

4. Activez le mode de débogage sur le staging

WordPress masque les erreurs PHP sur la production par défaut. C’est la bonne décision pour un site en direct car vous ne voulez pas que les visiteurs voient des messages d’erreur bruts. Mais cela signifie aussi que des problèmes peuvent exister sur votre site sans aucun signe visible.

Le staging est l’endroit où vous les faites apparaître, et vous pouvez le faire avec le débogage WordPress.

Ajoutez define('WP_DEBUG', true); à votre fichier wp-config.php sur l'environnement de staging. Cela active le rapport d'erreurs et affiche les notices et avertissements PHP qui resteraient autrement cachés.

Si une mise à jour de plugin introduit un avertissement de dépréciation ou si une fonction de thème génère une erreur, vous la verrez sur le staging avant qu'elle n'atteigne votre site en production.

Il est également utile d'activer WP_DEBUG_LOG en parallèle. Cela écrit les erreurs dans un fichier debug.log dans votre dossier wp-content afin que vous ayez un enregistrement à consulter plutôt que de vous fier à la détection des erreurs en temps réel.

Laissez le mode debug désactivé en production. Les paramètres sont réservés au staging.

5. Mettez à jour une chose à la fois

Lorsque vous avez six mises à jour de plugins en attente, vous pourriez vouloir tout sélectionner et tout mettre à jour en une seule fois. C'est plus rapide, mais si quelque chose casse après une mise à jour groupée, vous n'avez aucune idée du plugin qui en est la cause.

Mettez à jour individuellement. Après chacune, effectuez une vérification rapide.

Chargez la page d'accueil, naviguez sur quelques pages et assurez-vous que rien d'évident n'a cassé. Ensuite, mettez à jour la suivante.

Cela ajoute quelques minutes au processus, mais vous donne une carte claire de ce qui a changé en cas de problème.

Ceci s'applique également aux mises à jour du cœur de WordPress. Si vous mettez à jour le cœur et plusieurs plugins dans la même session, mettez à jour le cœur d'abord, testez-le, puis parcourez les plugins un par un.

Un conflit entre une mise à jour majeure du cœur et un plugin spécifique est beaucoup plus facile à diagnostiquer lorsque vous n'avez pas modifié plusieurs choses en même temps.

6. Utilisez le staging comme votre dernière étape d'assurance qualité avant chaque déploiement

Le staging n'est pas seulement un endroit pour expérimenter des changements. C'est la dernière vérification obligatoire avant que quoi que ce soit n'atteigne votre site en production.

Avant de pousser un changement, effectuez un cycle de tests complet. Cela signifie plus que de vérifier la page que vous venez de mettre à jour.

Voici quelques actions clés à entreprendre :

• Naviguez dans votre menu principal sur ordinateur et mobile.
• Soumettez tous les formulaires utilisés par le site, y compris les formulaires de contact, les inscriptions à la newsletter et tout ce qui est transmis à un service tiers.
• Si vous utilisez WooCommerce, parcourez le flux de paiement complet : ajouter au panier, passer à la caisse, paiement.
• Vérifiez la vitesse de chargement de votre page avec Google PageSpeed Insights et comparez-la à votre référence.
• Examinez les pages que votre changement était censé affecter et quelques pages qu'il n'était pas censé toucher du tout.

Les conflits ne se manifestent pas toujours là où vous vous attendez. Une mise à jour de plugin qui affecte votre processus de paiement peut ne pas casser visuellement la page de paiement mais peut silencieusement casser les e-mails de confirmation de commande.

Dix minutes de clics approfondis rattrapent ce qu'un contrôle rapide de cinq secondes manque.

7. Poussez le code, pas toute la base de données

Lorsque vous poussez des changements du staging vers la production, déplacez le code — thèmes, plugins, scripts personnalisés et changements de configuration. Ne poussez pas la base de données entière à moins d'avoir une raison spécifique et de comprendre pleinement ce que vous écrasez.

Pendant que vous travailliez sur le staging, votre site en production a continué de fonctionner. De nouvelles commandes sont arrivées. Des formulaires de contact ont été soumis. Des utilisateurs se sont inscrits. Des commentaires de blog ont été postés.

Si vous poussez une base de données complète du staging vers la production, vous écrasez tout cela.

La règle est la suivante : le code circule de la pré-production vers la production ; le contenu reste sur la production.

Si vous avez apporté des modifications de contenu sur la pré-production qui doivent être mises en ligne, migrez ces éléments manuellement plutôt que de pousser toute la base de données.

Si votre hébergeur ou votre plugin de pré-production prend en charge la poussée sélective, utilisez-le. Il vous permet de pousser des fichiers ou des tables spécifiques sans toucher au reste. Ce niveau de contrôle est très précieux lorsque votre site en direct a des utilisateurs actifs ou des transactions en cours.

Pour Duplicator, vous pouvez créer une sauvegarde personnalisée du site de pré-production qui n'inclut pas la base de données.

Téléchargez-le, puis téléchargez-le sur votre site de production.

Cependant, assurez-vous d'avoir un plan de reprise après sinistre en place et d'éviter de pousser des modifications pendant les périodes de forte affluence. Vous pourriez avoir besoin de déboguer des erreurs ou de restaurer une sauvegarde si quelque chose se passe mal sur la production.

8. Rafraîchissez le staging avant chaque série de changements

Un environnement de pré-production vieux de plusieurs semaines ou mois n'est pas un environnement de test fiable. C'est un instantané de l'apparence de votre site au moment où vous l'avez créé, ce qui peut avoir très peu en commun avec votre site actuel.

Les versions des plugins sur la pré-production peuvent être en retard par rapport à la production. Les structures de contenu peuvent avoir changé. Les paramètres que vous avez mis à jour sur le site en direct peuvent ne pas exister sur la pré-production.

Lorsque vous testez sur une copie obsolète, les résultats reflètent des conditions qui n'existent plus.

Récupérez une copie fraîche de la production avant chaque nouveau lot de modifications. C'est la seule habitude qui élimine le plus d'erreurs de pré-production. Cela signifie que chaque test que vous effectuez est effectué sur une version actuelle et précise de votre site.

Si vous utilisez Duplicator Pro, le rafraîchissement de la pré-production est aussi rapide que la configuration initiale : exécutez une nouvelle sauvegarde, transformez-la en environnement de pré-production, et vous avez terminé.

9. Effectuez une sauvegarde de production avant de déployer

Même après un travail de pré-production minutieux et approfondi, une poussée peut toujours mal tourner. Le comportement de mise en cache du serveur, un plugin qui réagit différemment sur l'environnement en direct, une configuration qui fonctionne sur la pré-production mais qui entre en conflit en production : ces choses arrivent, et elles ne sont pas toujours prévisibles.

La réponse est d'avoir toujours un point de récupération prêt avant de pousser.

Prenez une nouvelle sauvegarde complète du site de votre environnement de production immédiatement avant de déployer quoi que ce soit depuis la pré-production. Ainsi, si quelque chose casse sur le site en direct, vous restaurez cette sauvegarde, et vous revenez à la normale en quelques minutes.

Sans cela, vous déboguez un site en direct cassé en temps réel ou vous essayez de reconstituer les choses manuellement.

Je considère cela comme une étape non négociable. La pré-production peut se dérouler parfaitement, et la poussée peut toujours vous surprendre. La sauvegarde est ce qui rend cela récupérable plutôt que catastrophique.

Duplicator est le seul plugin de sauvegarde avec des URL de reprise après sinistre qui fonctionnent même si WordPress est hors service. Après avoir créé une sauvegarde complète du site, définissez-la comme point de récupération après sinistre.

Ensuite, copiez l'URL de récupération et enregistrez-la dans un endroit sûr.

Si la poussée échoue, collez ce lien dans une fenêtre de navigateur et restaurez instantanément votre site à son état normal.

10. Nettoyez les anciens environnements de staging

Les environnements de staging peuvent s'accumuler rapidement. Vous en créez un pour une refonte, terminez le projet et passez à autre chose. Six mois plus tard, trois clones de staging obsolètes traînent sur votre serveur ou votre compte, aucun n'est clairement étiqueté, tous sont périmés.

Cela pose deux problèmes. Premièrement, la confusion : lorsque vous revenez pour effectuer d'autres travaux, il n'est pas toujours évident de savoir quel environnement est le plus récent ou dans quel état ils se trouvent.

Deuxièmement, la sécurité : un ancien site de staging qui n'est plus activement géré peut ne pas être mis à jour, et s'il n'est pas correctement protégé par mot de passe, c'est une porte ouverte.

Prenez l'habitude de supprimer les environnements de staging lorsque vous avez terminé. Vous pouvez gérer tous vos sites de staging depuis un seul endroit dans le tableau de bord de Duplicator.

Lorsque vous commencez un nouveau cycle de travail, créez un nouveau clone à partir de la production plutôt que de déterrer un ancien. Cela permet de garder les choses propres et vous assure de toujours savoir exactement sur quoi vous travaillez.

Staging bien fait : une checklist avant de déployer en production

Avant de déployer quoi que ce soit du staging vers la production, parcourez cette liste. Cela prend cinq minutes, et je peux dire par expérience que cela a évité plus de quelques mauvaises journées.

• Le staging a été actualisé à partir de la production avant cette série de tests
• Toutes les modifications ont été effectuées sur le staging, pas directement sur la production
• WP_DEBUG était activé sur le staging et aucune erreur n'a été trouvée
• Chaque mise à jour a été appliquée individuellement, pas toutes en même temps
• Test complet du site terminé : navigation, formulaires, paiement, mise en page mobile, vitesse de chargement des pages
• Le staging est protégé par mot de passe et bloqué de l'indexation par les moteurs de recherche
• Seuls les changements de code sont poussés, pas la base de données complète
• Une nouvelle sauvegarde complète du site de production a été effectuée immédiatement avant le push
• Vous connaissez les étapes exactes pour restaurer cette sauvegarde si le push casse quelque chose

Ce dernier point est celui que les gens négligent. Prendre une sauvegarde et savoir comment la restaurer sont deux choses différentes.

Si vous n'avez jamais effectué de restauration avec Duplicator Pro auparavant, testez-la sur un environnement de staging d'abord afin de ne pas avoir à la découvrir sous pression sur un site en direct défaillant.

Questions fréquemment posées (FAQ)

Le staging ne vous ralentira pas. La récupération d’un site en direct défaillant le fera.

Le staging a la réputation d’être la chose que vous êtes censé faire mais que vous ne parvenez jamais vraiment à faire. Cela donne l’impression d’une surcharge. Une couche supplémentaire entre vous et la modification que vous souhaitez apporter.

La plupart des utilisateurs occasionnels de WordPress le traitent ainsi, et la plupart d’entre eux ont également vu leur site en direct se casser au pire moment possible.

Le coût en temps de la mise en scène est faible : quelques minutes pour rafraîchir, quelques minutes pour tester, une sauvegarde avant de pousser. Le coût en temps de récupération d'un site en direct défaillant est beaucoup plus important, et il s'accompagne du stress supplémentaire de se produire en public.

Avoir un flux de travail de mise en scène n'élimine pas entièrement le risque, mais il détecte la grande majorité des problèmes avant qu'ils n'atteignent la production.

Plus de 1,5 million de professionnels WordPress utilisent Duplicator Pro pour sauvegarder, migrer et mettre en scène leurs sites. La configuration de la mise en scène prend quelques clics, fonctionne sur n'importe quel hôte, et ne nécessite pas de compte d'hébergement séparé ni de connaissances techniques pour être opérationnelle.

Si cet article vous a fait réfléchir à la protection de votre site avant d'apporter des modifications, ces guides méritent d'être lus ensuite.

• Comment créer un site de staging WordPress (pour des tests en toute sécurité)
• Avez-vous besoin d'un site de staging ?
• Comment sauvegarder le site staging de votre site Web avant chaque transfert
• 9 meilleurs plugins WordPress de staging (+ nos avis d'experts)
• Comment créer un site de staging WooCommerce (+ Quoi tester avant la mise en ligne)
• Maintenance de la base de données WordPress : Ce qu'il faut faire chaque semaine, chaque mois et chaque trimestre