Sauvegardes WooCommerce : éviter la perte de commandes clients

Une boutique WooCommerce ne peut pas se contenter d’une sauvegarde hebdomadaire. Entre deux copies, des commandes payées, des remboursements, des comptes clients ou des stocks peuvent avoir changé. Pour une activité e-commerce, la maintenance site WordPress doit donc prévoir des sauvegardes fréquentes, restaurables et adaptées aux données réellement utilisées par WooCommerce. L’objectif n’est pas seulement de remettre le site en ligne après une panne : il faut aussi pouvoir retrouver une commande précise sans écraser les ventes enregistrées depuis la dernière sauvegarde.

Comprendre où WooCommerce enregistre les commandes

Une commande WooCommerce est principalement stockée dans la base de données WordPress. Selon la configuration de la boutique, elle peut utiliser le stockage historique dans les tables de contenus WordPress ou le stockage haute performance des commandes, appelé HPOS. Avec le stockage historique, les commandes sont notamment liées aux tables des contenus et des métadonnées. Avec HPOS activé, WooCommerce utilise notamment des tables telles que wp_wc_orders, wp_wc_order_addresses et wp_wc_orders_meta. Le préfixe wp_ peut toutefois être différent sur votre installation.

Cette distinction est importante lors d’une exportation ou d’une restauration manuelle : il ne faut pas supposer qu’une commande se trouve dans une seule table ni importer une table isolée sans connaître le mode de stockage actif. Dans WooCommerce, vérifiez ce point dans WooCommerce > Réglages > Avancé > Fonctionnalités, au niveau du stockage des commandes.

Les fichiers restent eux aussi indispensables. Le dossier des téléversements peut contenir des images produits, des factures PDF générées par une extension, des pièces jointes envoyées par les clients ou des éléments nécessaires à l’affichage du catalogue. Les extensions, le thème et les fichiers de configuration participent enfin au bon fonctionnement du paiement, des e-mails et des règles de livraison. Une sauvegarde exploitable couvre donc la base de données et les fichiers.

Définir une fréquence adaptée au volume de ventes

La fréquence doit être liée au volume de données qu’il serait acceptable de perdre, et non à une habitude technique. Une boutique qui reçoit des commandes chaque jour ne devrait pas dépendre d’une copie complète effectuée une seule fois par semaine. Une perte de quelques heures peut déjà représenter des commandes encaissées mais absentes du back-office.

• Pour une boutique avec des ventes quotidiennes, planifiez au minimum une sauvegarde quotidienne de la base de données et une copie régulière des fichiers.
• Pour une boutique avec des commandes fréquentes dans la journée, prévoyez des sauvegardes de base de données plus rapprochées, par exemple toutes les heures si l’hébergement ou l’outil le permet.
• Avant une mise à jour de WooCommerce, du thème, d’une extension de paiement ou de WordPress, créez un point de restauration manuel complet.
• Conservez plusieurs versions : une seule sauvegarde peut contenir une erreur déjà présente, une suppression accidentelle ou une base corrompue.

Les sauvegardes incrémentales peuvent réduire l’espace nécessaire, mais vérifiez qu’elles permettent bien une restauration complète et que la chaîne de sauvegardes est conservée. Un système qui conserve uniquement la dernière copie ne protège pas contre une détection tardive d’un problème.

Mettre en place une sauvegarde complète et indépendante

Inclure la base, les fichiers et la configuration

Une sauvegarde WooCommerce doit inclure au minimum la base de données entière, le répertoire wp-content/uploads, les extensions, les thèmes et les fichiers de configuration nécessaires à l’installation. Sauvegarder seulement les fichiers du site ne permet pas de récupérer les commandes, car leurs données sont en base. À l’inverse, restaurer uniquement la base sans les fichiers peut casser l’affichage, des extensions ou les documents liés aux commandes.

Les extensions de sauvegarde WordPress peuvent convenir si elles savent exporter la base et les fichiers, planifier les tâches et envoyer les archives vers un stockage externe. Les sauvegardes proposées par l’hébergeur sont également utiles, mais ne doivent pas être votre seule copie si vous ne pouvez pas télécharger l’archive ou restaurer sélectivement. Vérifiez toujours ce qui est inclus, la durée de rétention et la procédure de récupération.

Éviter de dépendre uniquement de WP-Cron

De nombreux plugins planifient leurs tâches via WP-Cron, le planificateur déclenché lors des visites sur WordPress. Sur un site peu fréquenté, une sauvegarde peut donc partir en retard. Sur une boutique active, elle peut aussi se déclencher pendant une charge importante. Lorsque votre hébergement le permet, configurez un véritable cron serveur pour appeler régulièrement le planificateur WordPress ou utilisez un service de sauvegarde disposant de sa propre planification. Surveillez ensuite les journaux du plugin : une tâche programmée n’est pas une preuve qu’une archive a été créée correctement.

Conserver une copie hors du serveur

Une archive stockée uniquement dans le même compte d’hébergement reste vulnérable à une suppression, un incident serveur ou une compromission du compte. Envoyez au moins une copie vers un stockage externe distinct : espace objet, serveur SFTP séparé ou service de stockage cloud professionnel. Restreignez l’accès, activez l’authentification multifacteur lorsque le service le propose et chiffrez les archives si elles contiennent des données clients.

Les commandes comportent souvent des noms, adresses, e-mails et parfois des informations de livraison. N’envoyez pas des archives de base de données par e-mail et ne les laissez pas accessibles depuis une URL publique. Limitez aussi l’accès aux personnes chargées de la maintenance.

Garantir la cohérence des commandes et des paiements

Une commande passe par plusieurs étapes : création, paiement, mise à jour du statut, réduction du stock, e-mails et parfois création d’un compte client. Une sauvegarde de base réalisée sans précaution pendant des écritures peut produire des données incomplètes selon l’outil utilisé. Utilisez de préférence une méthode compatible avec votre base et votre hébergement. Sur une base MySQL utilisant InnoDB, une exportation cohérente réalisée par un outil qui s’appuie sur une transaction est généralement préférable à une copie brute des fichiers de la base.

Ne désactivez pas arbitrairement la boutique pour chaque sauvegarde : cela peut perturber les clients et les paiements. En revanche, lors d’une opération à risque, comme une migration ou une restauration globale, passez en maintenance, terminez les traitements en cours et informez l’équipe qui prépare les commandes.

La base de données ne remplace pas le système de paiement. Conservez les accès et les historiques de votre prestataire de paiement (Stripe, PayPal ou banque) afin de pouvoir comparer les transactions aux commandes WooCommerce. Les clés secrètes d’API ne doivent jamais être copiées dans un document non protégé ; elles font partie des éléments à inventorier avant une restauration ou une migration.

Tester la restauration avant l’incident

Une sauvegarde non testée est seulement une hypothèse. À intervalles réguliers, restaurez une copie dans un environnement de préproduction ou dans un sous-domaine protégé, jamais directement sur la boutique en production. Utilisez idéalement une copie de base anonymisée si des personnes non autorisées peuvent accéder à cet environnement.

1. Restaurez les fichiers et la base de données dans l’environnement de test.
2. Vérifiez que l’administration WordPress et WooCommerce s’ouvrent sans erreur.
3. Recherchez une commande ancienne par son numéro, son e-mail client et son statut.
4. Contrôlez les produits, les images, les comptes clients et les méthodes de paiement.
5. Testez l’envoi d’un e-mail sur une adresse de test et vérifiez les journaux d’erreur.
6. Notez le temps nécessaire et les étapes exactes de restauration dans une procédure interne.

Ce test permet aussi de détecter une archive trop volumineuse, un délai d’exécution dépassé, un fichier manquant ou une extension qui ne se reconnecte pas après restauration.

Réagir si des commandes ont disparu

Évitez de restaurer immédiatement une ancienne sauvegarde sur la boutique active. Cette action peut supprimer les commandes plus récentes et créer un écart supplémentaire avec les paiements réellement encaissés. Commencez par mettre de côté une copie actuelle de la base et des fichiers, puis identifiez la période concernée.

• Comparez les transactions du prestataire de paiement avec les commandes WooCommerce par montant, e-mail, identifiant de transaction et heure.
• Consultez les journaux WooCommerce dans WooCommerce > État > Journaux, ainsi que les journaux PHP ou serveur disponibles.
• Restaurez la sauvegarde concernée dans un environnement isolé pour retrouver les données manquantes sans toucher à la production.
• Pour quelques commandes, recréez-les manuellement dans WooCommerce avec les informations vérifiées, en ajoutant une note interne sur l’origine de la correction.
• Pour un volume important, faites préparer une migration contrôlée par un professionnel : importer directement des tables ou métadonnées peut casser les relations entre commandes, clients, taxes et stock.

Après la récupération, vérifiez les statuts de paiement, les remboursements, les stocks et les e-mails déjà envoyés afin d’éviter une double expédition ou un nouveau débit. Une maintenance site WordPress efficace inclut enfin une alerte en cas d’échec de sauvegarde, un contrôle des restaurations et une procédure documentée pour traiter rapidement toute commande manquante.