WooCommerce Guide
Mettre à jour WooCommerce sans casser la boutique : la méthode de la préproduction
Une mise à jour appliquée directement en production reste l’une des causes de panne les plus fréquentes sur WooCommerce. Préproduction, sauvegarde vérifiée, ordre des mises à jour, parcours de test et retour arrière : la méthode qui transforme une loterie en procédure.

Le scénario est connu de tous les marchands WooCommerce. Un bouton « Mettre à jour » en rouge dans l’administration, un clic un soir de semaine, et le lendemain matin un panier qui ne se valide plus. Rien n’a été « cassé » à proprement parler : une extension de paiement n’était pas encore compatible avec la nouvelle version, ou un thème surchargeait un gabarit qui a changé.
WooCommerce publie une nouvelle version à peu près chaque mois, WordPress plusieurs fois par an, et chaque extension suit son propre rythme. Sur une boutique ordinaire d’une trentaine d’extensions, il y a des mises à jour à appliquer presque chaque semaine. L’enjeu n’est pas de les éviter, c’est d’en faire une procédure.
Le circuit de mise à jour
Une sauvegarde n’existe que si elle a été restaurée
Les extensions de sauvegarde affichent volontiers une coche verte. Elle signifie qu’un fichier a été produit, pas qu’il permet de remonter la boutique. La seule preuve est la restauration : une fois par trimestre au moins, la dernière sauvegarde est remontée sur un environnement vierge. C’est aussi le moyen le plus simple d’alimenter la préproduction avec des données fraîches.
La sauvegarde doit couvrir la base et les fichiers, être stockée hors du serveur de production, et être horodatée juste avant l’intervention. Une sauvegarde de la nuit précédente fait perdre toutes les commandes de la journée en cas de retour arrière.
L’ordre des mises à jour
- Lire les notes de version de WooCommerce et des extensions de paiement et de livraison. Une version majeure de WooCommerce (x.0) justifie une attente de quelques jours, le temps que les correctifs x.0.1 sortent.
- Extensions critiques d’abord : paiement, livraison, facturation. Leurs éditeurs publient généralement la compatibilité avant la sortie de WooCommerce.
- WooCommerce, puis vérification de l’écran Statut : gabarits de thème obsolètes et mise à jour de base de données en attente.
- WordPress et le thème, en dernier.
- Parcours de contrôle sur la préproduction, puis reproduction à l’identique en production.
Le parcours de contrôle
Un parcours de contrôle tient en une page et se déroule en dix minutes : recherche d’un produit, fiche produit avec variation, ajout au panier, application d’un code promo, calcul des frais de port vers un point relais et vers une adresse, paiement en mode test, réception de l’e-mail de confirmation, apparition de la commande dans l’administration et dans l’outil de facturation. Il se complète d’un coup d’œil au journal d’erreurs PHP, souvent plus bavard que l’écran.
La mise en production se fait à l’heure la plus creuse de la boutique, que les statistiques de commandes indiquent précisément, et jamais avant un week-end ou une opération commerciale. Pendant les 48 heures suivantes, le taux de commandes est comparé à la même période de la semaine précédente : une chute brutale signale un problème que personne n’a encore remonté.
Ce qu’il faut retenir
- Une sauvegarde non restaurée n’est pas une sauvegarde.
- Paiement et livraison d’abord, WooCommerce ensuite, WordPress et thème en dernier.
- Un parcours de contrôle écrit, rejoué à l’identique en préproduction puis en production.
Ma règle tient en une phrase : jamais de mise à jour en production un vendredi soir. Je l’ai apprise en agence, sur des sites bien moins sensibles qu’une boutique. Sur un site vitrine, une panne coûte de l’image. Sur une boutique, chaque heure se compte en commandes perdues, et le client s’en aperçoit avant le marchand. — Simon Janvier
Les mises à jour de votre boutique vous font peur ? La maintenance mensuelle les prend en charge avec préproduction et retour arrière. Commencer par l’audit offert