Comment pousser WordPress staging vers la production sans perdre de données

J'ai déplacé des modifications de staging vers la production plus de fois que je ne peux le compter, et les fois où cela a mal tourné avaient toutes la même cause profonde : j'ai précipité le transfert sans vérifier ce que j'étais sur le point d'écraser.

Si vous avez passé les dernières heures (ou jours) à apporter des modifications sur un site de staging, vous êtes probablement prêt à les mettre en ligne. Nouveau thème, plugins mis à jour, une page redessinée. Quoi que ce soit, vous l'avez testé, et ça fonctionne.

Le pousser sur votre site en production est là où les choses deviennent risquées.

J'utilise Duplicator pour cela car il me donne un contrôle total sur le processus. Je peux créer un package de migration à partir du staging, choisir exactement quelles tables de base de données sont incluses, et l'installer sur la production selon mes propres termes au lieu de faire confiance à un seul bouton pour prendre la bonne décision.

Ce contrôle est important. Un transfert négligent peut effacer de nouvelles commandes, déconnecter tous les utilisateurs, ou casser votre site en production devant les visiteurs pendant que vous vous précipitez pour le réparer.

Ce tutoriel vous explique ce que vous ferez pour transférer un site WordPress de staging vers la production, y compris les erreurs qui surprennent les gens.

Voici les points clés à retenir :

• Deux chemins principaux existent en fonction de votre hébergeur : utilisez le transfert intégré de votre fournisseur d'hébergement s'il est disponible, ou utilisez la méthode de sauvegarde et de migration de Duplicator lorsqu'il ne l'est pas, car elle fonctionne quel que soit votre hébergeur.
• Un transfert complet de la base de données peut effacer l'activité en direct. Toutes les commandes, commentaires ou inscriptions ajoutés à votre site après la création du staging seront écrasés à moins que vous n'excluez ces tables avant le transfert.
• Le timing est plus important que ce que les gens pensent. Plus l'écart est grand entre la création du staging et le transfert, plus les données en direct sont à risque, alors transférez plus tôt que tard.

Table des matières

Quand avez-vous besoin de transférer le staging vers la production ?

Toutes les modifications que vous apportez sur le staging n'ont pas besoin d'aller en production. Connaître la différence vous évite de prendre des risques inutiles.

Vous aurez besoin d'un vrai transfert lorsque :

• Vous avez testé une mise à jour majeure de thème ou de plugin et confirmé qu'elle fonctionne
• Vous avez créé de nouvelles pages ou du contenu que vous êtes prêt à publier
• Vous avez apporté des modifications structurelles ou de code
• Vous avez exécuté une mise à jour du cœur de WordPress et vérifié que rien n'a été cassé

Vous n'avez probablement pas besoin d'un transfert complet lorsque vous vérifiiez simplement l'apparence de quelque chose, exécutiez un test de compatibilité que vous allez refaire de toute façon, ou apportiez des modifications que vous ne prévoyez pas de conserver.

Je traite le staging comme l'endroit où casser les choses exprès.

La mise en production est différente. C'est le moment où vous vous engagez.

Chaque mise en production comporte un risque : des données écrasées, quelques minutes d'indisponibilité, ou des URL incorrectes qui prennent du temps à identifier. Rien de tout cela ne vaut la peine pour un changement que vous n'avez pas fini de tester.

Alors, avant de toucher quoi que ce soit, assurez-vous que ce qui est sur la plateforme de staging est bien terminé.

Ce dont vous avez besoin avant de commencer

Avant de mettre quoi que ce soit en production, mettez ces éléments en place. Sauter cette étape est la raison pour laquelle une tâche de 20 minutes se transforme en une course contre la montre de plusieurs heures.

• Une nouvelle sauvegarde de votre site en production, effectuée juste avant de commencer la mise en production
• Accès FTP ou SFTP, ou le gestionnaire de fichiers de votre compte d'hébergement, au cas où vous auriez besoin de téléverser des fichiers manuellement ou de corriger quelque chose à la main
• Accès à la base de données via phpMyAdmin ou l'outil de base de données de votre hébergeur, comme solution de repli si quelque chose nécessite une correction manuelle
• Une liste claire de ce qui a changé sur la plateforme de staging, afin que vous sachiez exactement ce que vous mettez en production et que vous puissiez vérifier qu'il a bien été appliqué
• Duplicator Pro installé sur votre site de staging, car c'est ce que vous utiliserez pour créer le package de migration dans la section suivante

Cette sauvegarde de votre site en production est le seul élément de cette liste que vous ne pouvez pas ignorer. J'ai vu des gens l'ignorer parce que « la mise en production fonctionne toujours ». Ça ne fonctionne pas toujours.

Quand ça ne fonctionne pas, cette sauvegarde est la seule chose qui vous sépare de la reconstruction de votre site à partir de zéro.

Différentes méthodes pour transférer le staging vers la production

Toutes les configurations WordPress n'ont pas les mêmes outils disponibles, et ce qui fonctionne pour un site peut ne pas exister sur un autre. Voici ce qui existe, en fonction de votre hébergeur et de vos plugins, avant d'entrer dans le détail étape par étape.

Mise en production depuis la plateforme de staging fournie par l'hébergeur

Les hébergeurs comme WP Engine, Kinsta, SiteGround et Flywheel intègrent des outils de mise en production depuis la plateforme de staging directement dans leurs tableaux de bord. Si votre hébergeur propose cela, c'est généralement l'option la plus rapide car elle est conçue autour de leur configuration serveur.

Le compromis est que vous êtes limité à ce que le niveau de plan de votre hébergeur inclut, et certains plans ne le proposent pas du tout.

Mise en production via un plugin de staging dédié

Les plugins spécialement conçus pour le staging (comme WP Staging) incluent leur propre bouton de mise en production avec sélection des fichiers et de la base de données. Cela fonctionne bien si le staging était déjà votre cas d'utilisation principal.

Le compromis est que vous ajoutez un autre plugin spécifiquement pour cette tâche unique.

Méthode de sauvegarde et de migration

C'est la méthode que j'utilise, et celle que ce tutoriel détaille.

Vous créez un package de migration à partir de votre site de staging, vous choisissez exactement ce qu'il faut inclure, et vous l'installez sur la production. Un outil comme Duplicator gère cela bien.

Cela prend quelques étapes de plus qu'un simple bouton de mise en production, mais cela fonctionne quel que soit votre hébergeur. Cela vous donne également le plus de contrôle sur ce qui est écrasé.

Méthode manuelle (FTP et phpMyAdmin)

Copier les fichiers et les tables de la base de données à la main, une par une. C'est une solution de dernier recours lorsque aucun autre outil n'est disponible. Cela fonctionne, mais c'est lent et sujet aux erreurs.

Je préfère la méthode de sauvegarde et de migration car elle ne dépend pas du support des mises en production de staging par mon hébergeur, et je peux décider table par table ce qui est sûr d'écraser.

Comment transférer un site WordPress de staging vers la production

Voici ce que vous allez faire, étape par étape :

• Sauvegardez d’abord votre site en production : Créez un filet de sécurité pour pouvoir restaurer la production en quelques minutes en cas de problème.
• Décidez ce que vous transférez : Déterminez si vous effectuez un transfert complet du site ou un transfert sélectif qui protège les données en production comme les commandes et les commentaires.
• Créez un package de migration à partir de la pré-production : Empaquetez les fichiers et la base de données de votre site de pré-production dans des fichiers que Duplicator peut installer sur la production.
• Transférez les fichiers du package sur le serveur de production : Obtenez l’installateur et l’archive sur votre serveur de production afin que l’installation puisse s’exécuter.
• Exécutez l’installateur sur le site de production : Installez vos modifications de pré-production sur la production et mettez à jour la base de données en conséquence.
• Vérifiez le site de production : Confirmez que tout fonctionne correctement avant de partir.

Étape 1 : Sauvegardez votre site en production d'abord

Les sauvegardes ne sont pas facultatives. Avant de toucher à la production, vous avez besoin d’un moyen de revenir en arrière si quelque chose casse.

Mon outil préféré pour cette tâche est Duplicator. Comme c’est aussi un plugin de migration, il vous aidera à protéger votre site, à configurer une zone de pré-production et à migrer les modifications en retour chaque fois que vous en aurez besoin.

Sur votre site de production, ouvrez Duplicator et allez à l’écran Sauvegardes. Cliquez sur le bouton Ajouter.

Nommez la sauvegarde quelque chose que vous reconnaîtrez plus tard, comme « sauvegarde-avant-transfert-preprod ». Choisissez le préréglage de sauvegarde Site complet pour sauvegarder tout.

Cliquez sur Suivant. Une fois que vous avez examiné les avis du scan, créez la sauvegarde.

Téléchargez les deux fichiers de sauvegarde. Stockez-les quelque part hors de votre serveur, comme un stockage cloud ou votre ordinateur local.

Je préfère utiliser Duplicator Cloud car il peut restaurer votre site même s’il est hors ligne suite à une erreur grave.

Étape 2 : Décidez quelles données vous transférez

Un transfert complet remplace tout : fichiers, thèmes, plugins et toute la base de données. Utilisez ceci lorsque vous avez apporté des modifications majeures comme un nouveau thème ou des mises à jour structurelles importantes.

Un transfert sélectif ne met à jour que des fichiers ou des tables de base de données spécifiques. Utilisez ceci lorsque vous n’avez modifié que quelques éléments, car cela protège les données en production que votre site de pré-production n’a pas, comme les nouvelles commandes, commentaires ou inscriptions d’utilisateurs effectuées sur la production depuis que vous avez commencé la pré-production.

Si vous effectuez un transfert complet de la base de données, tout ce qui s’est passé sur votre site de production après la création de la pré-production sera effacé et remplacé par les anciennes données de la pré-production.

Avant de créer votre package de migration à l’étape suivante, décidez quelles tables sont importantes.

Si vous n’êtes pas sûr de ce qui a changé en production depuis que vous avez commencé la pré-production, vérifiez maintenant. Il est beaucoup plus facile de demander « Ai-je besoin de cette table ? » avant le transfert que de la récupérer après.

Étape 3 : Créez un package de migration à partir du staging

Sur votre site de pré-production, créez une nouvelle sauvegarde avec Duplicator. C’est le même processus que celui que vous avez utilisé à l’étape 1, mais sur la pré-production cette fois.

Dans la section Sauvegardes, utilisez les préréglages de sauvegarde pour personnaliser les données incluses. Vous pouvez également utiliser des filtres de fichiers et de tables de base de données.

Duplicator vous permet d’exclure des tables spécifiques, comme wp_woocommerce_orders ou wp_comments, de la création de la base de données.

Terminez la création de la sauvegarde et téléchargez-la. Vous obtiendrez deux fichiers : un programme d'installation (installer.php) et une archive (un fichier zip contenant les fichiers et la base de données de votre site).

Étape 4 : Transférez les fichiers de staging vers le serveur de production

Connectez-vous à votre serveur de production à l'aide de FTP, SFTP ou du gestionnaire de fichiers de votre hébergeur.

Téléchargez le fichier installer.php et le fichier d'archive dans le répertoire racine de votre site de production. C'est le même dossier où se trouve le fichier principal wp-config.php de votre site.

Si votre site de staging se trouve dans un sous-dossier du même serveur, comme votresite.com/staging/, ce transfert est souvent une simple copie de fichiers plutôt qu'un téléversement complet, ce qui permet de gagner du temps.

Vérifiez que les deux fichiers apparaissent dans le répertoire racine du site de production avant de continuer.

Pour une méthode plus rapide, utilisez Duplicator Pro pour glisser-déposer l'archive de sauvegarde directement sur le nouveau site ! Vous n'aurez pas besoin d'un client FTP.

Étape 5 : Exécutez l'installateur sur le site en production

Dans votre navigateur, accédez à votresite.com/installer.php, en remplaçant « votresite.com » par votre domaine de production.

Vérifiez attentivement les détails de connexion à la base de données. Ils doivent pointer vers la base de données de votre site de production, pas celle de staging.

Poursuivez l'installation. Une fois terminée, reconnectez-vous avec le bouton Connexion administrateur.

Étape 6 : Vérifiez le site en production

Ouvrez votre site de production et vérifiez d'abord la page d'accueil.

Cliquez sur quelques pages clés : celles que vous avez modifiées sur staging, plus quelques-unes que vous n'avez pas touchées, juste pour confirmer que rien d'autre n'a été affecté.

Essayez de vous connecter à wp-admin avec vos identifiants habituels. Testez les formulaires ou les processus de paiement si votre site en possède.

Videz votre cache (à la fois le cache au niveau du serveur et tout plugin de cache que vous utilisez), car les pages mises en cache peuvent afficher du contenu ancien même après une migration réussie.

Dernière chose : si votre site de staging est toujours en ligne, vérifiez qu'il est toujours configuré sur noindex dans ses paramètres de visibilité. C'est facile à oublier, et vous ne voulez pas que les moteurs de recherche explorent un site en double.

Dépannage : Erreurs courantes lors du transfert du staging vers la production

Écran blanc juste après la migration

Vous chargez votre site de production et obtenez une page blanche sans message d'erreur.

Cela signifie généralement qu'un plugin qui fonctionnait bien sur staging est incompatible avec l'environnement de votre serveur de production, souvent en raison d'une différence de version PHP.

Comparez la version PHP de votre hébergeur avec celle utilisée par staging. Si elles ne correspondent pas, mettez à jour la production pour qu'elle corresponde à la version PHP de staging, ou annulez le plugin à l'origine du conflit en utilisant votre sauvegarde de l'étape 1.

Impossible de se connecter à wp-admin après la migration

Vous entrez vos identifiants de connexion habituels et obtenez « nom d'utilisateur ou mot de passe incorrect », même si vous savez qu'ils sont corrects.

Une migration complète de la base de données remplace la table des utilisateurs de votre site de production par celle de staging, de sorte que votre connexion de production ne correspond plus à ce qui se trouve dans la base de données.

Réinitialisez le mot de passe administrateur directement via phpMyAdmin ou l'outil de base de données de votre hébergeur, ou restaurez votre sauvegarde de l'étape 1 et refaites la migration en tant que migration sélective qui exclut la table des utilisateurs.

Erreurs REST API ou éditeur de blocs défectueux

L'éditeur de blocs ne se charge pas, ou vous voyez des erreurs REST API dans la console du navigateur.

Les données sérialisées dans votre base de données font toujours référence à votre URL de staging au lieu de votre domaine principal, et le remplacement d'URL de Duplicator n'a pas capturé toutes les occurrences.

Duplicator effectuera une recherche et un remplacement pour vous. Cependant, vous pouvez cibler les URL de staging restantes dans les champs sérialisés avec un plugin comme Search & Replace Everything.

Commandes, commentaires ou nouvelles inscriptions manquants

Les clients signalent que leurs commandes récentes ont disparu, ou que des commentaires des derniers jours ont disparu.

Cela se produit lorsqu'une synchronisation complète de la base de données écrase les tables principales qui avaient une nouvelle activité, car cette activité s'est produite après la création du staging.

Restaurez votre sauvegarde initiale immédiatement, puis refaites la synchronisation en tant que synchronisation sélective qui exclut wp_woocommerce_orders, wp_comments et toute autre table avec une activité en direct.

Le processus se bloque ou expire pendant le transfert

L'installation se bloque à mi-chemin, ou votre navigateur affiche une erreur de délai d'attente sans message d'échec clair.

Les fichiers d'archive volumineux peuvent dépasser les limites de téléchargement de votre serveur ou les limites de temps d'exécution, en particulier sur l'hébergement mutualisé.

Vérifiez la taille maximale de téléchargement et les paramètres de temps d'exécution PHP de votre hébergeur, divisez le package en plus petits morceaux si votre plugin le prend en charge, ou contactez votre hébergeur pour augmenter temporairement les limites pendant la synchronisation.

Le bouton de synchronisation de votre hébergeur est grisé ou manquant

Vous cherchez une option de synchronisation de staging dans votre tableau de bord d'hébergement, et elle est soit désactivée, soit absente.

Cela signifie généralement que votre niveau de plan d'hébergement n'inclut pas les fonctionnalités de synchronisation de staging, même si la création de staging elle-même est incluse.

Utilisez plutôt la méthode de sauvegarde et de migration de Duplicator, car elle ne dépend pas de ce que votre plan d'hébergement prend en charge.

Questions fréquemment posées (FAQ)

Traitez chaque transfert comme une migration, car c'en est une

Vous disposez maintenant d’un processus complet pour transférer les modifications du staging vers votre site en production sans deviner si quelque chose va casser.

Continuez à surveiller quelques éléments pour l’avenir.

L’activité en production continue pendant que vous travaillez sur le staging, donc plus vous attendez entre la création du staging et le push des modifications, plus vous risquez d’écraser des données avec un push complet. Vérifiez ce qui a changé en production avant chaque push, pas seulement le premier.

Une astuce que je ne vois nulle part ailleurs : planifiez votre push pendant vos heures de trafic les plus faibles, même pour un petit site. Moins de visiteurs actifs signifie moins de chances d’écraser une commande ou un commentaire arrivé pendant les quelques minutes que prend le push.

Protégez votre site avant le prochain transfert

Chaque push du staging vers la production comporte des risques, même lorsque vous suivez attentivement chaque étape. Une sauvegarde effectuée juste avant de commencer fait la différence entre une réparation rapide et la reconstruction de votre site à partir de zéro.

Duplicator Pro est conçu exactement pour cela : sauvegardes complètes du site, contrôle sélectif de la base de données et un processus de migration qui fonctionne, quel que soit ce que votre hébergeur prend en charge. Plus de 1,5 million de professionnels WordPress l’utilisent déjà pour protéger leurs sites lors de changements comme celui-ci.

N’attendez pas qu’un push échoue pour découvrir que votre dernière sauvegarde date d’une semaine.

Si ce tutoriel vous a aidé, ces guides méritent également d'être mis en favoris.

• Avez-vous besoin d'un site de staging ?
• Comment créer un site de staging WordPress
• Comment convertir un site WordPress en site de staging
• Comment créer un site de staging WooCommerce (+ Quoi tester avant la mise en ligne)
• Comment sauvegarder le site staging de votre site Web avant chaque transfert
• 9 meilleurs plugins WordPress de staging (+ nos avis d'experts)