# Pousser la base de staging en production : les erreurs qui coûtent cher > Commandes écrasées, utilisateurs de test réactivés, emails envoyés en double : pourquoi synchroniser la base de recette vers la production est une mauvaise idée, et par quoi la remplacer. - Auteur : Clément Hadrot - Publié le : 2025-02-13 - Mis à jour le : 2025-02-13 - Catégorie : Outils & workflow - URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/pousser-staging-production-erreurs/ ## L’essentiel - La direction staging vers production écrase des commandes réelles - Les webhooks et emails se redéclenchent en masse à l'import - Le bon sens du flux va toujours de la production vers la recette Un scénario que nous avons vu se répéter chez plusieurs clients avant de l'interdire explicitement dans nos procédures : un développeur travaille tranquillement sur l'environnement de recette, y ajoute du contenu de test, puis, par habitude ou par erreur d'inattention dans une interface de synchronisation, pousse cette base de recette vers la production au lieu de l'inverse. Ce qu'on voit ensuite dépasse largement le contenu de test affiché par erreur : des commandes clients réelles, passées en production pendant la fenêtre de travail, disparaissent purement et simplement, remplacées par l'état figé de la recette. Ce chapitre explique pourquoi ce sens de synchronisation est presque toujours une erreur, ce qu'il casse concrètement au-delà du contenu perdu, et ce qu'il faut faire à la place quand on a réellement besoin de rapprocher les deux environnements. ## Ce qu'on voit : la perte de données de production Une base de recette est, par nature, une photographie figée prise à un instant donné — souvent lors de la dernière synchronisation en sens inverse, de la production vers la recette. Tout ce qui s'est passé en production depuis cet instant (commandes, inscriptions, commentaires, modifications de contenu) n'existe pas dans cette photographie. Pousser cette photographie vers la production revient à effacer purement et simplement toute l'activité récente du site réel. ## Pourquoi c'est un problème plus large que le contenu perdu Le problème ne s'arrête pas à la perte de données visibles. Une base de recette contient généralement des comptes utilisateurs de test, parfois avec des rôles d'administrateur créés pour les besoins du développement, qui se retrouvent alors actifs en production. Elle contient aussi des réglages d'intégration tiers (clés d'API de paiement en mode test, adresses de webhook pointant vers un environnement de recette) qui, une fois importés en production, redirigent silencieusement des flux réels — un paiement client peut se retrouver traité par une clé d'API de test, sans jamais aboutir réellement, sans que personne ne s'en aperçoive avant le rapprochement comptable. > L'essentiel à retenir : La direction staging vers production écrase des commandes réelles ; Les webhooks et emails se redéclenchent en masse à l'import ; Le bon sens du flux va toujours de la production vers la recette ## Le cas des e-mails envoyés en double ou à mauvaise adresse C'est le symptôme le plus visible et le plus gênant socialement : une base de recette contient souvent d'anciens comptes clients, avec leurs vraies adresses e-mail. Si un plugin de notification, de newsletter ou de relance de panier abandonné se déclenche après cet import erroné (parce qu'un cron ou un événement se relance sur ces données restaurées comme si elles étaient nouvelles), de vrais clients reçoivent des e-mails en double, parfois avec des informations de test incohérentes visibles dedans (« Commande n° TEST-042 », un montant à zéro euro). C'est exactement ce genre d'incident qui abîme la confiance d'un client bien plus qu'une simple panne technique. ## Le bon sens du flux : toujours de la production vers la recette La règle qui élimine structurellement ce risque : la synchronisation de base de données ne circule que dans un seul sens, de la production vers la recette, jamais l'inverse en routine. Un environnement de recette existe pour tester sur des données réalistes, pas pour servir de source de vérité à réinjecter. ``` # sens correct : production -> recette, jamais l'inverse en usage courant wp db export --url=https://production.exemple.test /tmp/export-prod.sql scp serveur-prod:/tmp/export-prod.sql ./ wp db import export-prod.sql --url=https://recette.exemple.test wp search-replace "https://production.exemple.test" "https://recette.exemple.test" --url=https://recette.exemple.test ``` ## Ce qu'il faut faire pour remonter du contenu créé en recette Le vrai besoin derrière une envie de synchronisation inverse est souvent plus précis qu'une réplication totale : remonter un article rédigé en recette, une page de configuration validée par le client, ou un réglage d'extension testé et approuvé. Dans ces cas, on isole ce contenu précis plutôt que de tout réimporter : - Export ciblé d'un contenu unique via `wp post get --format=json` puis recréation manuelle en production ; - Utilisation d'une extension de migration de contenu qui exporte un article et ses médias associés sans toucher au reste de la base ; - Pour un réglage de configuration validé, reproduction manuelle du réglage en production plutôt qu'import de la table `options` entière, qui contient des centaines de valeurs sans rapport. > Dès qu'une demande commence par « il faudrait remonter la recette vers la production », on reformule d'abord la question en « qu'est-ce qu'on veut remonter précisément ? ». La réponse est presque toujours un contenu isolé, jamais toute la base. ## Se protéger d'une erreur humaine malgré tout Aucune règle de procédure n'élimine totalement le risque d'erreur humaine, en particulier avec des outils de synchronisation en un clic qui ne demandent pas toujours de confirmation explicite du sens choisi. Une sauvegarde automatique de la production avant toute opération de synchronisation, quelle qu'elle soit, reste la seule protection fiable contre ce scénario précis — elle permet de tout restaurer en quelques minutes si le mauvais sens a été sélectionné par erreur. ## En résumé Synchroniser une base de recette vers la production n'est jamais un raccourci sans conséquence : c'est une opération qui écrase des données réelles, réactive des comptes de test et peut redéclencher des envois d'e-mails vers de vrais clients. Le sens correct reste toujours de la production vers la recette, et tout besoin de remonter du contenu doit passer par un export ciblé, jamais par un import global de base.