# Préparer une migration d’hébergeur sans coupure pour une boutique active > Comment migrer une boutique WooCommerce en cours d'activité sans interrompre les ventes ni perdre une seule commande passée pendant la fenêtre de bascule. - Auteur : WordPress Développement - Publié le : 2022-11-14 - Mis à jour le : 2022-11-14 - Catégorie : Hébergement & serveurs - URL : https://www.wpmoderne.fr/hebergement/preparer-migration-hebergeur-sans-coupure-boutique-active/ ## L’essentiel - Synchroniser les commandes passées pendant la copie initiale - Verrouiller brièvement les écritures plutôt que le site entier - Vérifier les webhooks de paiement après bascule Comment déplacer une base de données qui continue de recevoir des commandes pendant qu'on la copie ? C'est la question centrale de toute migration d'hébergeur pour une boutique en ligne active, et la réponse ne tient pas dans un simple export-import : entre le moment où l'export de la base démarre et celui où le nouveau serveur devient l'origine réelle, des commandes peuvent être passées et perdues si la procédure n'anticipe pas ce décalage. La question de la passerelle de paiement elle-même — sa propre migration éventuelle, ses propres clés d'API — n'est pas traitée ici : le sujet se limite à la migration de l'hébergement du site WooCommerce, en supposant que la passerelle de paiement reste inchangée de bout en bout. ## Le problème : une base de données qui bouge pendant la copie Un export de base MySQL classique, avec `mysqldump`, prend un instantané à un moment précis. Toute commande enregistrée après cet instantané, mais avant que le nouveau serveur ne devienne officiellement l'origine, existe uniquement sur l'ancien serveur. Si la bascule DNS intervient sans précaution supplémentaire, ces commandes disparaissent purement et simplement du nouvel environnement. ## La checklist de migration à zéro perte > L'essentiel à retenir : Synchroniser les commandes passées pendant la copie initiale ; Verrouiller brièvement les écritures plutôt que le site entier ; Vérifier les webhooks de paiement après bascule 1. **Copier l'intégralité du site vers le nouvel hébergeur en amont**, fichiers et base, plusieurs jours avant la date de bascule prévue, pour disposer d'un temps de test confortable sans pression de délai. 2. **Mettre en place une synchronisation différentielle** des commandes passées sur l'ancien serveur pendant la phase de test, via un export ciblé des tables `wp_wc_orders` et associées plutôt qu'un export complet répété. 3. **Fixer une fenêtre de gel des commandes**, la plus courte possible, pendant laquelle le site ancien passe en mode maintenance pour les seules actions d'écriture — passage de commande, création de compte — sans bloquer la simple consultation du catalogue. 4. **Effectuer un dernier export de base pendant la fenêtre de gel**, garanti sans écriture concurrente puisque les commandes sont temporairement bloquées. 5. **Importer ce dernier export sur le nouveau serveur** et vérifier immédiatement le nombre de commandes total, comparé à celui de l'ancien serveur au même instant. 6. **Basculer le DNS et surveiller les tout premiers paiements** reçus sur le nouvel environnement, en particulier les webhooks entrants de la passerelle de paiement. 7. **Lever le gel des commandes sur l'ancien serveur** uniquement après confirmation que le nouveau reçoit correctement les webhooks, en le laissant en lecture seule quelques jours par sécurité. ## La fenêtre de gel en pratique Sur ce projet, la fenêtre de gel a été fixée à trois minutes, affichée aux visiteurs par un message clair invitant à réessayer l'ajout au panier dans un instant, plutôt que par une page de maintenance générique qui aurait masqué tout le catalogue. Techniquement, ce gel a été obtenu en désactivant temporairement l'endpoint de paiement WooCommerce via un filtre, sans toucher au reste du site. ``` add_filter( 'woocommerce_available_payment_gateways', function ( $gateways ) { if ( get_option( 'migration_gel_actif' ) ) { return array(); } return $gateways; } ); ``` Ce filtre vide simplement la liste des moyens de paiement disponibles lorsqu'une option dédiée est activée, empêchant toute nouvelle commande d'aboutir sans pour autant rendre le site inaccessible. L'option est activée manuellement juste avant le dernier export, et désactivée après confirmation de la bascule côté nouveau serveur — jamais laissée active plus longtemps que nécessaire. ## Les webhooks, point de vigilance après bascule Un piège fréquent sur ce type de migration concerne les webhooks de confirmation de paiement asynchrone. Certaines passerelles envoient leur confirmation quelques secondes, voire quelques minutes, après le paiement réel du client. Si la bascule DNS intervient précisément entre le paiement et la réception du webhook, celui-ci peut arriver sur l'ancien serveur alors que le client a déjà été redirigé vers le nouveau. Maintenir l'ancien serveur en lecture seule, capable de recevoir encore les webhooks pendant quelques jours et de journaliser leur contenu, permet de rattraper manuellement ce type de commande orpheline si elle se produit. - Vérification de l'URL de webhook configurée chez le prestataire de paiement, pointant vers le nom de domaine et non une adresse IP spécifique à l'ancien serveur. - Journalisation temporaire de tout webhook reçu sur l'ancien serveur après la bascule, pour détecter d'éventuelles commandes orphelines. - Test d'une commande réelle à faible montant sur le nouvel environnement avant d'annoncer la migration terminée. > Le repère qu'on garde en tête sur ce genre d'opération : une migration de boutique réussie ne se mesure pas à l'absence de plainte client, mais au nombre exact de commandes retrouvées, à l'unité près, des deux côtés de la bascule. ## En résumé Migrer une boutique active sans coupure ni perte de commande repose moins sur la rapidité de la bascule que sur la maîtrise précise de la fenêtre de gel des écritures et la vérification systématique des webhooks de paiement après coup. Une fenêtre de quelques minutes, bien annoncée et bien testée, vaut mieux qu'une bascule instantanée mais aveugle aux commandes en transit.