Sauvegarder et migrer une boutique en ligne sans coupure

Une boutique en ligne ne peut pas se permettre une migration improvisée. Chaque minute d’indisponibilité peut faire perdre des ventes, mais le risque le plus grave est plus discret : une commande enregistrée sur l’ancien serveur pendant la bascule peut ne jamais parvenir sur le nouveau.

Une migration fiable suit donc quatre principes : préparer, copier, tester et basculer. L’essentiel du transfert peut être réalisé pendant que la boutique reste accessible. Seule la synchronisation finale nécessite une courte fenêtre de maintenance ou un mode lecture seule afin de garantir qu’aucune commande ne soit perdue.

Ce qu’il faut réellement migrer

Une boutique WooCommerce ou PrestaShop repose sur deux ensembles indissociables :

• La base de données contient les produits, clients, commandes, stocks, réglages, comptes et contenus.
• Les fichiers contiennent les images, thèmes, modules, extensions, documents téléchargeables et personnalisations.

Copier uniquement les fichiers produit une boutique vide ou incohérente. Copier uniquement la base laisse des images manquantes et des modules inutilisables.

Il faut aussi inventorier les éléments périphériques : version de PHP, extensions PHP, tâches cron, configuration du serveur web, règles de réécriture, certificats TLS, comptes email, relais SMTP, variables d’environnement et éventuels services externes. Les DNS, boîtes mail et certificats ne sont pas toujours inclus dans une migration d’hébergement classique.

Avant de commencer, relevez les versions de PHP, MariaDB ou MySQL, WooCommerce ou PrestaShop, ainsi que celles des extensions critiques. Le nouvel environnement doit être compatible avant d’accueillir la copie.

Effectuer une sauvegarde complète avant toute migration

La première copie doit être considérée comme une sauvegarde de sécurité. Elle comprend au minimum un export de la base et une archive ou une réplication des fichiers.

Cette sauvegarde doit être :

• Complète, avec la base et les fichiers issus du même état logique.
• Chiffrée, surtout si elle contient des données clients.
• Stockée hors du serveur d’origine.
• Datée et accompagnée des informations nécessaires à sa restauration.
• Testée sur un environnement isolé.

Une sauvegarde non restaurée n’est qu’une hypothèse. Importez la base, déployez les fichiers et vérifiez que la boutique démarre. Ne lancez aucune mise à jour de CMS ou de module pendant la migration : cela ajouterait une variable inutile au diagnostic. Notre guide sur les sauvegardes chiffrées avec restic aide à automatiser ces copies.

Préparer le nouvel hébergement

Installez le serveur web, PHP, la base de données et les extensions requises. Créez la base cible et un utilisateur disposant uniquement des droits nécessaires. Reproduisez les tâches cron, les limites PHP, les règles de cache et les paramètres d’envoi d’emails.

Préparez également HTTPS avant la bascule. Le certificat doit couvrir le domaine final et sa chaîne doit être valide. Sans cela, les premiers visiteurs risquent de rencontrer une alerte de sécurité, même si la boutique fonctionne correctement.

Chez un hébergeur français comme TalCloud, des serveurs situés en France simplifient la maîtrise de la localisation des données dans une démarche RGPD. Le stockage NVMe favorise les accès fréquents au catalogue et à la base, tandis que la protection Anti-DDoS Netrix et le support humain contribuent à la continuité de service. Les offres VPS démarrent à 4,99 € par mois.

Réaliser une première copie sans interrompre la boutique

La première copie se déroule pendant que l’ancien site continue à recevoir du trafic. Exportez la base avec mariadb-dump ou mysqldump :

mariadb-dump --single-transaction --quick --triggers --routines --events \
  -u boutique_user -p boutique_db > boutique-initiale.sql

L’option --single-transaction permet un export cohérent des tables transactionnelles InnoDB sans blocage prolongé. Évitez de placer le mot de passe directement dans la commande, car il pourrait rester dans l’historique du terminal.

Transférez puis importez la base sur le nouveau serveur :

mariadb -u boutique_user -p boutique_db < boutique-initiale.sql

Pour les fichiers, rsync ne recopie ensuite que les différences, ce qui réduit fortement la durée de la synchronisation finale :

rsync -aH --info=progress2 /var/www/html/ user@nouveau:/var/www/html/

Sur WooCommerce, wp-content concentre généralement les médias, thèmes et extensions :

rsync -aH --info=progress2 /var/www/html/wp-content/ \
  user@nouveau:/var/www/html/wp-content/

Pour PrestaShop, il est souvent préférable de synchroniser toute la racine /var/www/html, puis d’exclure uniquement les caches temporaires identifiés. Vérifiez ensuite les propriétaires et permissions attendus par PHP et le serveur web.

Tester le nouveau serveur avant le changement DNS

Le nouveau site doit être testé avec son vrai contenu, mais sans modifier encore le DNS public. Vous pouvez utiliser un domaine temporaire ou forcer localement la résolution du domaine dans /etc/hosts :

203.0.113.20 boutique.example.com www.boutique.example.com

Cette entrée dirige uniquement votre poste vers la nouvelle adresse IP. Pensez à la supprimer après les tests.

Contrôlez l’accueil, les catégories, les fiches produits, la recherche, les images, le panier, les comptes clients et l’administration. Effectuez un paiement avec le mode test du prestataire concerné. Vérifiez aussi les emails transactionnels et les retours des passerelles de paiement, dont les URL de webhook peuvent dépendre du domaine ou d’un filtrage réseau.

Consultez les journaux PHP, MariaDB et serveur web. Une page visuellement correcte peut masquer des erreurs cron, des permissions incorrectes ou un module incompatible.

Organiser la fenêtre de bascule

Lorsque les tests sont concluants, planifiez une courte fenêtre à faible trafic. Le déroulement recommandé est précis :

1. Activer la maintenance ou la lecture seule sur l’ancienne boutique.
2. Vérifier qu’aucun nouveau panier ne peut devenir une commande.
3. Laisser les paiements déjà engagés se terminer ou les rapprocher manuellement.
4. Resynchroniser les fichiers modifiés depuis la première copie.
5. Exporter et importer les données récentes.
6. Basculer le DNS.
7. Vérifier le nouveau serveur.
8. Retirer la maintenance sur le nouveau site.

Une seconde synchronisation des fichiers sera généralement rapide :

rsync -aH --delete /var/www/html/ user@nouveau:/var/www/html/

Utilisez --delete uniquement si la destination est bien une copie dédiée et après vérification des deux chemins. Cette option supprime sur la destination les fichiers absents de la source.

Pour la base, la méthode la plus sûre reste un second export complet réalisé après l’activation de la maintenance. Sur un très gros catalogue, une synchronisation limitée aux commandes, clients et stocks peut réduire la durée, mais elle exige une cartographie exacte des tables et relations.

WooCommerce peut stocker les commandes dans les tables historiques WordPress ou dans les tables HPOS. PrestaShop répartit commandes, paiements, adresses, paniers, stocks et historiques entre plusieurs tables. Copier seulement une table de commandes créerait des données orphelines. Cette synchronisation sélective doit donc être préparée et répétée sur une copie de test.

Adapter les URL et la configuration

Si le domaine reste identique, évitez les modifications inutiles. Contrôlez néanmoins les chemins absolus, les identifiants de base, les caches, les cookies et les variables d’environnement.

Si le domaine change, utilisez un outil qui comprend le format des données du CMS. Pour WooCommerce, WP-CLI sait préserver les données PHP sérialisées :

wp search-replace 'https://ancien.example' 'https://nouveau.example' \
  --all-tables-with-prefix --precise --skip-columns=guid --dry-run

Après contrôle du résultat, relancez sans --dry-run. N’effectuez pas un simple UPDATE ... REPLACE(...) global : la modification de la longueur d’une URL peut casser les valeurs sérialisées.

Dans PrestaShop, mettez à jour les paramètres de domaine, domaine SSL et URI physique depuis l’administration ou selon la procédure adaptée à la version. Videz ensuite le cache et régénérez les règles de réécriture si nécessaire.

Réduire les effets de la propagation DNS

Abaissez le TTL des enregistrements concernés, idéalement 24 à 48 heures avant la migration. Un TTL de quelques minutes accélère la prise en compte de la nouvelle adresse, mais les résolveurs ne respectent pas tous immédiatement ce changement.

Pendant la propagation, certains visiteurs peuvent encore atteindre l’ancien serveur. C’est pourquoi celui-ci doit rester en maintenance ou en lecture seule jusqu’à ce que le trafic ait effectivement basculé. Sinon, une commande pourrait être enregistrée dans l’ancienne base après la synchronisation finale.

Modifiez uniquement les enregistrements nécessaires. Vérifiez les entrées A, AAAA, CNAME et, si les emails sont concernés, MX, SPF, DKIM et DMARC. Une ancienne entrée IPv6 oubliée peut continuer à envoyer une partie des visiteurs vers le mauvais serveur.

Vérifier la boutique après la bascule

Réalisez immédiatement un parcours complet depuis une connexion qui n’utilise pas votre entrée /etc/hosts :

• Accueil, catégories, produits et recherche.
• Connexion et création de compte client.
• Ajout au panier, taxes, livraison et codes promotionnels.
• Paiement en mode test et retour vers la boutique.
• Création de commande, réduction de stock et facture.
• Emails adressés au client et à l’équipe.
• Administration, tâches cron et webhooks.
• HTTPS, redirections et absence de contenu mixte.
• Redirections des anciennes URL et réponses HTTP utiles aux moteurs de recherche.

Surveillez les journaux, les erreurs de paiement, les commandes incomplètes et les temps de réponse pendant les premières heures. Comparez aussi le nombre de commandes et les derniers identifiants entre les deux bases. Notre guide sur la migration d’un site web complète cette approche pour les sites plus simples.

Conserver l’ancien serveur comme filet de sécurité

Ne supprimez pas immédiatement l’ancien hébergement. Gardez-le quelques jours, isolé du trafic et toujours en lecture seule. Il constitue un point de comparaison et un moyen de récupérer un fichier ou une donnée oubliée.

Évitez toutefois un retour improvisé vers l’ancienne boutique après que le nouveau serveur a accepté des commandes. Un tel retour ferait perdre les transactions créées sur la nouvelle base. Toute procédure de repli doit inclure une resynchronisation des données récentes.

Automatiser les sauvegardes après la migration

La migration terminée, mettez en place des sauvegardes automatiques de la base et des fichiers. Adaptez leur fréquence au volume de commandes : une boutique active peut nécessiter plusieurs sauvegardes de base par jour.

Appliquez une politique de rétention avec plusieurs générations, chiffrez les archives et conservez au moins une copie hors du serveur de production. Surveillez les échecs de sauvegarde, testez régulièrement une restauration et documentez la procédure. Une migration réussie ne protège qu’un instant précis ; une stratégie de sauvegarde testée protège durablement le chiffre d’affaires et les données clients.