Pousser un site de staging vers le site de production

TL;DR : L’assistant Push de WP STAGING copie tes modifications — fichiers, tables de base de données, ou les deux — vers le site en production. Sauvegarde d’abord le site en production (étape 1), choisis ce que tu veux pousser aux étapes 2–3, puis lance le push. En cas d’échec, consulte la section dépannage ci-dessous.

Cet article explique comment pousser un site de staging vers la production et migrer des modifications d’un site de staging vers un site de production avec WP STAGING | PRO. Si tu n’en as pas encore créé un, découvre comment créer un site de staging WordPress avant de suivre ce guide.

Si tu veux convertir ton site de staging en site de production avec la version de base de WP STAGING, lis cet article pour une méthode de migration alternative si l’assistant Push n’est pas disponible.

Que veux-tu pousser ?

Avant d’ouvrir l’assistant Push, décide ce que tu veux envoyer en production. Cela détermine les étapes dont tu as besoin.

Vidéo : migrer ton site de staging WordPress vers le site de production

La vidéo ci-dessous montre comment WP STAGING | PRO pousse les données du site de staging vers le site de production.

WP STAGING | PRO peut pousser tous les fichiers médias, Themes, Plugins et données de la base de données d’un site de staging WordPress vers un site de production.

Avant de pousser : liste de contrôle pré-lancement

Vérifie tous les points suivants avant de lancer l’assistant Push :

• Le site de production est en ligne et accessible à son URL (ex. : https://example.com).
• Le site de staging a été créé avec WP STAGING et contient les modifications que tu veux déployer.
• WP STAGING | PRO est installé et activé sur le site de production.
• Les versions de WordPress core sur le staging et la production sont identiques.

Effectue toujours une sauvegarde de ton site de production avant de lancer le push. Un Backup te permet de restaurer la production en quelques minutes si quelque chose se passe mal.

Pousser l’intégralité du site de staging vers la production

Utilise cette méthode quand tu veux pousser à la fois les fichiers et les tables de base de données en une seule opération.

Étape 1 : sauvegarder le site de production et le site de staging

Sauvegarde ton site de production avant de lancer le push grâce à l’outil de Backup intégré de WP STAGING | PRO.

Va dans WP STAGING > Backup & Migration > Create New Backup. Saisis un nom et clique sur Start Backup. Une fois le Backup terminé, enregistre une copie locale via Actions > Download.

Étape 2 : sélectionner les tables de base de données

Va sur ton site de production > WP STAGING > Start / STAGING.

Si tu as plusieurs sites de staging, sélectionne celui que tu veux transférer et clique sur le bouton Push Changes.

Clique sur Database Tables et sélectionne toutes les tables que tu veux pousser du staging vers la production. Chaque table sélectionnée remplacera intégralement son équivalent sur le site de production.

Pour comprendre quelles tables de base de données inclure avant de pousser, la référence sur la structure de la base de données WordPress liste chaque table principale et ce qu’elle contient.

Désélectionne une table spécifique pour l’exclure du push.

Remarque : Si tu pousses uniquement des mises à jour de fichiers de Plugins ou de Themes, tu n’as pas besoin de pousser de tables de base de données. En revanche, si tu as modifié des réglages, créé des articles, assigné des menus ou installé de nouveaux Plugins sur le staging, ces actions sont enregistrées dans la base de données et tu dois pousser les tables correspondantes.

Étape 3 : sélectionner les Plugins, Themes et fichiers médias

Clique sur Select Files et choisis tous les dossiers de Plugins, médias et Themes à copier en production.

Tu peux également spécifier des dossiers supplémentaires en saisissant leurs chemins absolus complets dans la zone de texte.

Étape 4 : exclure des tables ou des fichiers du push

Deux options contrôlent ce qui est supprimé du site de production lors du push :

• Désinstaller tous les Plugins sur le site de production — supprime les Plugins de la production qui n’existent plus sur le staging.
• Supprimer le dossier wp-content/uploads — vide les uploads de production avant de copier le dossier uploads du staging.

Si les deux options sont désactivées, rien n’est supprimé de la production. Un Plugin supprimé sur le staging sera désactivé en production mais restera installé et pourra être réactivé manuellement.

Étape 5 : lancer le processus de push

Clique sur Push Staging Site to Live site pour lancer le push.

Une fois le push terminé, recharge ton site. Toutes les modifications du staging seront en ligne sur ton site de production.

Remarque : WordPress te demande parfois de te reconnecter après un push complet. Cela se produit quand les données de session de la base de données du staging remplacent celles de la production — c’est un comportement normal.

Pousser uniquement les changements de base de données

Si tes modifications se limitent au contenu, aux réglages ou à la configuration de Plugins — et que tu n’as modifié aucun fichier de Theme ou de Plugin — pousse uniquement les tables de base de données.

Dans l’assistant Push, ouvre Database Tables et sélectionne uniquement les tables contenant tes modifications. Laisse tous les dossiers de fichiers désélectionnés dans Select Files. C’est plus rapide, moins risqué et laisse les fichiers de production intacts.

Pour comprendre quelles tables de base de données inclure avant de pousser, la référence sur la structure de la base de données liste chaque table principale de WordPress et ce qu’elle contient.

Utilisateurs de WooCommerce : Exclure les tables de commandes et de clients WooCommerce lors du push d’un site de staging de boutique. Pousser ces tables écraserait les données transactionnelles en production. L’encadré WooCommerce à l’étape 2 liste les tables spécifiques à ignorer.

Pousser uniquement les fichiers (Themes, Plugins, médias)

Si tu as mis à jour ou testé un Theme ou un Plugin sur le staging et confirmé qu’il fonctionne, pousse uniquement les fichiers modifiés — aucun push de base de données n’est nécessaire.

Dans l’assistant Push, laisse Database Tables entièrement désélectionné. Dans Select Files, choisis uniquement les dossiers qui ont changé : par exemple, wp-content/themes/your-theme pour une mise à jour de Theme, ou wp-content/plugins/plugin-name pour un seul Plugin.

Après le push, supprime manuellement les Plugins propres au staging après le push vers la production si tu as installé des outils de développement sur le staging qui ne doivent pas tourner en production.

Que faire si le push échoue ?

Dans notre file d’assistance, les causes les plus fréquentes d’un push bloqué ou en erreur se répartissent en quatre catégories.

Le push se bloque sur les grandes bases de données

Si le processus de push se fige ou expire lors de la copie des tables de base de données, la cause la plus fréquente est un paramètre max_allowed_packet trop faible dans MySQL. Cette limite contrôle la taille maximale d’une seule requête de base de données ; quand une ligne de table la dépasse — les valeurs d’options sérialisées et les articles avec des images en base64 sont les coupables habituels — le push s’arrête en cours d’opération.

Solution : augmente max_allowed_packet dans ta configuration MySQL ou demande à ton hébergeur de l’augmenter. Consulte également les limites de configuration PHP qui peuvent interrompre un push — des directives comme memory_limit et max_input_vars peuvent aussi provoquer des timeouts lors du push de grandes médiathèques.

Contenu mixte ou URLs cassées après le push

Si le site en production affiche des images cassées ou des avertissements de contenu mixte après le push, c’est que le domaine du staging est encore présent dans certaines lignes de la base de données. WP STAGING remplace les URLs lors du push, mais les valeurs sérialisées dans les tables de Plugins personnalisés peuvent être manquées.

Solution : lance un search-and-replace dans la base de données pour remplacer le domaine du staging par celui de la production. Les erreurs d’API REST qui apparaissent après le push sont souvent causées par le même problème de correspondance de domaine ; corriger le remplacement de domaine résout les deux problèmes.

L’administrateur ne peut pas se connecter après le push

Si tu as poussé la base de données complète et que tu ne peux pas te connecter à l’administration de la production, c’est que la table utilisateurs du staging a remplacé celle de la production et que tes identifiants d’administrateur d’origine ne correspondent plus.

Solution : réinitialise le mot de passe administrateur directement dans MySQL à l’aide de l’outil de gestion de base de données de ton hébergeur (phpMyAdmin, par exemple). Tu peux aussi résoudre d’abord les problèmes de connexion sur ton site de staging, puis pousser à nouveau.

Écran blanc ou erreur fatale après le push

Un écran blanc immédiatement après le push signifie généralement qu’un Plugin qui fonctionnait sur le staging est incompatible avec l’environnement du serveur de production — généralement une différence de version PHP ou une incompatibilité de configuration serveur.

Active le journal de débogage WordPress pour identifier le Plugin : ajoute define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); dans wp-config.php. Le journal d’erreurs apparaît dans wp-content/debug.log. Une fois le Plugin incompatible identifié et corrigé, supprime les constantes de débogage.

Après le push : liste de vérification

Effectue ces vérifications avant de considérer le push comme terminé :

• [ ] Visite la page d’accueil de la production — confirme que le nouveau contenu ou design est visible.
• [ ] Connecte-toi à l’administration de la production — confirme que les identifiants fonctionnent.
• [ ] Vérifie https://your-domain.com/wp-json/ — une réponse JSON confirme que l’API REST est opérationnelle.
• [ ] Ouvre les outils de développement du navigateur → Console — aucun avertissement de contenu mixte.
• [ ] Teste les formulaires, les tunnels de commande ou les fonctionnalités critiques.
• [ ] Supprime manuellement les Plugins propres au staging après le push qui ne doivent pas tourner en production.
• [ ] Demande une réindexation dans Google Search Console si du contenu important a changé.

Articles connexes

• Démarrage rapide : comment pousser un nouveau Theme du site de staging vers la production
• Pousser un site de staging vers la production
• Créer un env. Dev > Staging. Créer un site de staging et le copier vers un autre site de staging avant la mise en production
• Conseils pour sauvegarder un site WordPress de production et de staging
• Site déplacé vers un nouveau serveur – impossible de pousser le site de staging