Créer un environnement de staging WordPress

Créer un environnement de staging WordPress : tester les modifications en toute sécurité avant leur mise en ligne

Un site WordPress ne devrait pas être testé directement sur le site en production lorsque des modifications importantes sont prévues. Une mise à jour de plugin défectueuse, une version PHP incompatible, un nouveau thème ou un mauvais réglage peuvent, dans le pire des cas, faire en sorte que les visiteurs voient un site défectueux ou que des fonctions importantes ne soient plus utilisables.

C’est précisément à cela que sert un environnement de staging. Une copie de votre site WordPress existant est créée dans une zone séparée. Vous pouvez y tester des mises à jour, des modifications de design, de nouveaux plugins, des versions PHP ou des analyses d’erreurs sans perturber le fonctionnement de votre site en production.

Qu’est-ce qu’un environnement de staging ?

Un environnement de staging est une copie séparée de votre site. Il contient généralement les mêmes fichiers, les mêmes plugins, le même thème, la même base de données et les mêmes réglages que votre site en production au moment de sa création.

Les adresses de staging typiques sont par exemple :

• votre-domaine.ch/staging/
• staging.votre-domaine.ch
• test.votre-domaine.ch

Les visiteurs de votre site normal ne voient pas la version de staging. Elle sert exclusivement d’espace de test pour les administrateurs, les développeurs ou les rédacteurs.

Pourquoi le staging est si important

WordPress se compose de nombreux éléments mobiles : cœur WordPress, thème, plugins, version PHP, base de données, mise en cache, fonctions de sécurité, formulaires, fonctions de boutique et services externes. Une modification dans un domaine peut avoir des effets sur d’autres domaines.

Avec un environnement de staging, vous pouvez réduire les risques. Vous testez d’abord les modifications dans une copie sécurisée et décidez ensuite seulement si elles doivent être transférées sur le site en production.

Le staging est particulièrement précieux pour :

• Mises à jour de plugins : Vérifier si les extensions continuent de fonctionner correctement.
• Mises à jour WordPress : Tester les nouvelles versions avant de les utiliser en production.
• Changements de PHP : Vérifier la compatibilité avec le thème et les plugins.
• Changements de thème : Tester un nouveau design sans perturber les visiteurs.
• Ajustements CSS et de code : Contrôler les modifications sans risque.
• Boutiques WooCommerce : Vérifier le paiement, le panier et les modes de paiement.
• Recherche d’erreurs : Analyser les problèmes sans continuer à solliciter le site en production.
• Relancements : Préparer des transformations importantes.

Le staging ne remplace pas une sauvegarde

Un environnement de staging est une copie de test, mais il ne remplace pas une sauvegarde complète. Si quelque chose se passe mal lors de la création, de la modification ou de la restauration de la version de staging, vous avez toujours besoin d’une sauvegarde séparée.

Avant des modifications importantes, vous devriez donc toujours créer une sauvegarde contenant au minimum les éléments suivants :

• fichiers WordPress,
• médiathèque et téléversements,
• fichiers du thème,
• fichiers des plugins,
• base de données,
• wp-config.php,
• le cas échéant, .htaccess.

Partie 1 : créer un environnement de staging avec Softaculous

Chez CURIAWEB, vous pouvez copier votre installation WordPress dans un environnement de staging via Softaculous. Le déroulement exact peut légèrement varier selon l’affichage cPanel, mais suit en principe ce schéma.

1. Connectez-vous à votre cPanel.
2. Dans la rubrique Software, ouvrez le Softaculous Apps Installer.
3. Cliquez sur All Installations pour afficher vos sites WordPress installés.
4. Recherchez l’installation WordPress souhaitée.
5. Cliquez sur le symbole de staging, généralement représenté par deux carrés superposés.
6. Choisissez la destination de la copie de staging, par exemple un répertoire comme staging ou un sous-domaine comme staging.votre-domaine.ch.
7. Vérifiez les informations relatives à la base de données et au chemin d’installation.
8. Cliquez sur Create Staging.

Softaculous copie alors les fichiers et la base de données de votre site WordPress dans la zone de staging choisie. Selon la taille du site, cette opération peut prendre un certain temps.

Sous-domaine ou sous-répertoire ?

Lors de la création de l’environnement de staging, la question se pose souvent de savoir si un sous-domaine ou un sous-répertoire est préférable.

Pour des tests simples, un sous-répertoire suffit souvent. Pour les sites plus grands, les relancements ou les projets complexes, un sous-domaine est plus clair.

Protéger le staging des moteurs de recherche

Un site de staging ne devrait normalement pas être indexé par les moteurs de recherche. Sinon, des contenus de test, des contenus dupliqués ou des pages inachevées pourraient devenir accessibles publiquement.

Après la création, vérifiez donc :

• Le site de staging est-il protégé par mot de passe ?
• L’indexation par les moteurs de recherche est-elle désactivée sous Réglages > Lecture ?
• L’URL de staging n’est-elle pas liée publiquement ?
• Aucun sitemap XML du site de staging n’a-t-il été soumis à Google ?
• Le site de staging n’est-il pas utilisé par erreur dans des menus ou des e-mails ?

Partie 2 : tester les modifications dans l’environnement de staging

Après la création, vous pouvez vous connecter au site de staging et tester les modifications. Travaillez-y comme s’il s’agissait de votre vrai site, mais sans risque pour les visiteurs.

Tests typiques :

• mettre à jour le cœur WordPress,
• mettre à jour les plugins,
• mettre à jour le thème,
• changer de version PHP,
• installer de nouveaux plugins,
• tester un nouveau thème,
• vérifier les ajustements CSS,
• tester un thème enfant,
• tester les formulaires,
• tester le processus de commande WooCommerce,
• vérifier les réglages de performance.

Effectuez les modifications de manière structurée. Ne changez pas dix choses en même temps si vous souhaitez ensuite savoir ce qui a provoqué une erreur.

Liste de contrôle de test recommandée

Après des modifications importantes, vous ne devriez pas seulement consulter la page d’accueil. Vérifiez plusieurs zones centrales de votre site.

• page d’accueil,
• pages importantes,
• blog ou base de connaissances,
• formulaire de contact,
• menu et pied de page,
• affichage mobile,
• connexion et tableau de bord,
• médias et images,
• titres SEO et métadonnées,
• bannière de cookies,
• tracking ou analytics, si utilisés,
• panier et paiement WooCommerce, le cas échéant.

Testez également avec différents rôles si plusieurs groupes d’utilisateurs sont concernés, par exemple administrateur, rédacteur, client ou membre.

Utiliser le staging avec une prudence particulière pour WooCommerce

Pour les boutiques WooCommerce, le staging est particulièrement précieux, mais aussi particulièrement sensible. Pendant que vous travaillez dans l’environnement de staging, de nouvelles commandes, de nouveaux comptes clients, stocks, bons ou avis produits peuvent apparaître sur le site en production.

Si vous transférez ensuite toute la base de données de staging vers le site en production, ces nouvelles données live peuvent être écrasées.

Sont particulièrement critiques :

• nouvelles commandes,
• nouveaux comptes clients,
• nouveaux avis produits,
• stocks,
• bons,
• abonnements,
• statuts de paiement,
• entrées de formulaires,
• tickets de support ou réservations.

Partie 3 : transférer les modifications vers le site en production

Lorsque vous avez testé toutes les modifications et que la version de staging fonctionne correctement, vous pouvez la transférer vers le site en production. Dans Softaculous, cette fonction s’appelle souvent Push to Live.

Déroulement typique :

1. Ouvrez le Softaculous Apps Installer dans cPanel.
2. Allez dans All Installations.
3. Recherchez votre installation de staging.
4. Cliquez sur Push to Live.
5. Vérifiez soigneusement les options affichées.
6. Créez au préalable une sauvegarde manuelle du site en production.
7. Démarrez l’opération de push uniquement lorsque vous êtes sûr.

Selon la version de Softaculous, différentes options peuvent être disponibles, par exemple un écrasement complet ou un transfert sélectif de fichiers individuels ou de tables de base de données. Vérifiez soigneusement les options avant de démarrer l’opération.

Que signifie exactement « Push to Live » ?

« Push to Live » signifie que les modifications de l’environnement de staging sont transférées vers le vrai site. Selon l’option choisie, seuls les fichiers, seules certaines zones de la base de données ou toute l’installation peuvent être transférés.

Cela peut être utile pour :

• ajustements de thème,
• mises à jour de plugins,
• modifications de design,
• nouveaux modèles,
• modifications CSS,
• préparatifs de relancement.

Cela peut être risqué pour :

• boutiques WooCommerce actives,
• sites avec de nouvelles demandes de formulaire,
• sites membres avec comptes utilisateurs actifs,
• systèmes de réservation,
• forums ou sites communautaires,
• sites avec de nouveaux contenus quotidiens.

Dans de tels cas, il faut planifier précisément quelles données peuvent être transférées sur le site en production.

Après le push : vérifier le site en production

Après le transfert des modifications, vous devriez tester immédiatement le site en production. Ne vous fiez pas uniquement au fait que l’opération a été techniquement terminée.

Vérifiez :

• la page d’accueil se charge correctement,
• les pages importantes fonctionnent,
• le menu et le pied de page sont corrects,
• le formulaire de contact envoie correctement,
• SSL fonctionne,
• les images s’affichent,
• l’affichage mobile est correct,
• l’espace d’administration est accessible,
• le cache a été vidé,
• les réglages SEO sont conservés,
• le paiement WooCommerce fonctionne, le cas échéant.

Après le push, videz tous les caches pertinents : cache WordPress, cache serveur, cache CDN et cache du navigateur.

Quand faut-il utiliser le staging ?

Un environnement de staging n’est pas seulement utile aux développeurs. Les exploitants de sites ordinaires en profitent également lorsqu’ils souhaitent tester des modifications de manière contrôlée.

Utilisez le staging en particulier pour :

• grandes mises à jour WordPress : Surtout lors de sauts de version.
• mises à jour de plugins : Surtout pour WooCommerce, les formulaires, les plugins SEO ou les plugins de sécurité.
• changements de version PHP : Tester la compatibilité avec le thème et les plugins.
• changements de thème : Préparer un nouveau design.
• ajustements de thème enfant : Vérifier les modifications PHP et CSS.
• optimisation des performances : Tester la mise en cache, la minification et l’optimisation de la base de données.
• recherche d’erreurs : Reproduire et analyser les erreurs.
• relancement : Préparer une nouvelle structure ou une nouvelle mise en page.

Quand le staging est-il moins adapté ?

Le staging est très utile, mais il n’est pas parfait pour toutes les situations. Lorsque les données live changent constamment, il faut travailler avec une prudence particulière.

Le staging nécessite une planification spéciale pour :

• boutiques actives,
• portails membres,
• systèmes de réservation,
• plateformes de cours en ligne,
• forums,
• sites avec de nombreuses demandes de formulaire,
• portails d’actualités avec publication quotidienne.

Dans de tels cas, le moment du push devrait être planifié et, si nécessaire, une fenêtre de maintenance devrait être utilisée.

Staging et protection des données

Un environnement de staging peut contenir des données personnelles, car il s’agit d’une copie du site en production. Selon le site, cela inclut les demandes de contact, les comptes utilisateurs, les commandes, les commentaires ou les données clients.

Vérifiez donc :

• Le site de staging est-il accessible publiquement ?
• Est-il protégé par mot de passe ?
• Qui a accès à l’environnement de staging ?
• Des données clients réelles sont-elles nécessaires ou peuvent-elles être anonymisées ?
• Des e-mails provenant du staging sont-ils envoyés par erreur aux clients ?
• Les prestataires de paiement sont-ils en mode test ?
• Le tracking est-il désactivé sur le staging ?

Staging et envoi d’e-mails

Une erreur fréquente : le site de staging envoie de vrais e-mails. Cela peut arriver si WooCommerce, les formulaires de contact, les plugins de newsletter ou les notifications utilisateurs restent actifs.

Vérifiez donc dans le staging :

• Les formulaires de contact envoient-ils à de vrais destinataires ?
• WooCommerce envoie-t-il des e-mails de commande ?
• Les plugins de newsletter envoient-ils des messages ?
• Des notifications administrateur sont-elles déclenchées ?
• Les plugins SMTP sont-ils actifs ?
• Faut-il utiliser un plugin de journalisation des e-mails ou de blocage des e-mails ?

Pour les boutiques et les sites membres, il est souvent judicieux de désactiver ou de rediriger l’envoi d’e-mails dans le staging.

Staging et tests de performance

Un environnement de staging convient bien pour tester des optimisations de performance. Cela comprend la mise en cache, l’optimisation des images, le lazy loading, l’optimisation CSS et JavaScript ou le nettoyage des plugins.

Veuillez toutefois noter que les résultats de staging ne sont pas toujours exactement identiques à ceux du site en production. Des règles de cache différentes, des services désactivés ou le blocage des moteurs de recherche peuvent influencer les résultats de mesure.

Testez néanmoins :

• temps de chargement avant et après les modifications,
• PageSpeed Insights,
• Lighthouse,
• affichage mobile,
• formulaires et fonctions JavaScript,
• éléments pertinents pour les Core Web Vitals,
• comportement du cache.

SEO et staging

Le staging protège le SEO lorsque les modifications sont testées à l’avance. Les redirections défectueuses, modèles cassés, métadonnées manquantes ou menus défectueux peuvent être détectés avant d’être visibles publiquement.

Vérifiez avant le push :

• Les titres SEO et les méta-descriptions sont-ils conservés ?
• Les permaliens fonctionnent-ils ?
• N’y a-t-il pas de réglages noindex indésirables sur le site en production ?
• Le sitemap live est-il généré correctement ?
• Les liens internes fonctionnent-ils ?
• N’y a-t-il pas d’URL de staging dans les contenus live ?
• Les redirections ont-elles été testées correctement ?

Particulièrement important : assurez-vous qu’un réglage noindex provenant du staging n’est pas transféré par erreur sur le site en production.

GEO : utiliser le staging pour une meilleure qualité de contenu

Le GEO, c’est-à-dire Generative Engine Optimization, bénéficie indirectement du staging. Vous pouvez vérifier les contenus, la structure, les zones FAQ, les liens internes et la sortie technique avant que les modifications ne soient mises en ligne.

Le staging aide pour le GEO, car vous pouvez contrôler :

• si les contenus sont clairement structurés,
• si les titres sont organisés logiquement,
• si les zones FAQ sont affichées correctement,
• si les liens internes fonctionnent,
• si les contenus importants ne sont pas masqués par des erreurs,
• si les pages se chargent rapidement et de manière stable,
• si les données structurées restent correctes.

Erreurs fréquentes lors du staging

• Aucune sauvegarde avant le push : Les erreurs sont difficiles à annuler.
• Le staging est indexé : Les pages de test apparaissent dans les moteurs de recherche.
• Données WooCommerce écrasées : De nouvelles commandes live sont perdues.
• Vrais e-mails depuis le staging : Les clients reçoivent des messages de test.
• Les URL de staging restent dans les contenus live : Les liens pointent vers l’environnement de test.
• Cache non vidé : D’anciennes versions restent visibles.
• Seule la page d’accueil est testée : Les erreurs sur les sous-pages restent inaperçues.
• noindex repris par erreur : Le site live est exclu des moteurs de recherche.
• Prestataire de paiement pas en mode test : Des commandes de test peuvent déclencher de vrais paiements.

Procédure recommandée

1. Créer une sauvegarde : Avant chaque modification importante et avant chaque Push to Live.
2. Créer le staging via Softaculous : Dans cPanel via le Softaculous Apps Installer.
3. Protéger le staging : Désactiver l’indexation par les moteurs de recherche et limiter l’accès.
4. Tester les modifications de manière structurée : Vérifier séparément les mises à jour, le thème, les plugins, PHP ou le code.
5. Tester les formulaires et la boutique : En particulier les formulaires de contact, le paiement, les e-mails et les fonctions utilisateur.
6. Vérifier les réglages SEO : Contrôler noindex, permaliens, métadonnées, sitemap et liens internes.
7. Planifier soigneusement le push : Surtout pour les boutiques et les sites avec de nouvelles données live.
8. Tester le site live après le push : Vérifier le frontend, le backend, l’affichage mobile et les fonctions importantes.
9. Vider le cache : Tenir compte du cache WordPress, serveur, CDN et navigateur.
10. Maintenir le staging à jour : Pour les projets plus longs, synchroniser régulièrement le staging avec les données live.

Questions fréquentes sur l’environnement de staging WordPress

Qu’est-ce qu’un environnement de staging ?

Un environnement de staging est une copie de test de votre site. Vous pouvez y vérifier les modifications avant qu’elles ne soient visibles sur le site en production.

Puis-je utiliser le staging sans connaissances en programmation ?

Oui. Via Softaculous dans cPanel, vous pouvez créer une copie de staging WordPress en quelques clics. Pour les boutiques ou migrations complexes, la prudence reste toutefois recommandée.

Le staging est-il la même chose qu’une sauvegarde ?

Non. Le staging est un environnement de test. Une sauvegarde est une copie de sécurité destinée à la restauration. Vous devriez utiliser les deux.

Que signifie Push to Live ?

Push to Live transfère les modifications de l’environnement de staging vers le vrai site. Des fichiers et contenus de base de données peuvent être écrasés.

Puis-je utiliser le staging avec WooCommerce ?

Oui, mais avec une prudence particulière. Pendant que vous travaillez dans le staging, de nouvelles commandes peuvent apparaître sur le site live. Elles ne doivent pas être écrasées par erreur lors du push.

Le staging doit-il être indexé par Google ?

Non. Un site de staging ne devrait pas être indexé. Il contient des contenus de test ou des copies de vos contenus live et devrait être protégé des moteurs de recherche.

Pourquoi vois-je encore d’anciens contenus après le push ?

Une couche de cache affiche probablement encore d’anciennes données. Videz le cache WordPress, le cache serveur, le cache CDN et le cache du navigateur.

Le support CURIAWEB peut-il aider pour le staging ?

Oui. Le support CURIAWEB peut vous aider pour les questions relatives à la création du staging, au processus de push ou à l’évaluation technique. Les migrations complexes peuvent être payantes selon l’effort nécessaire.