Rollback d'une MAJ WooCommerce qui casse le checkout

Rollback d'une MAJ WooCommerce qui casse le checkout

Une extension WooCommerce se met à jour pendant la maintenance de nuit. Le lendemain, la boutique s'affiche normalement, mais le tunnel de commande ne va plus jusqu'au bout : le bouton de paiement tourne dans le vide, ou la passerelle renvoie une erreur. Le rollback — le retour à la version précédente de l'extension — est la première manœuvre pour rouvrir la caisse. Encore faut-il savoir ce qu'il répare, ce qu'il laisse en l'état, et comment confirmer que le checkout repart vraiment. Ce guide décrit la procédure, du constat à la reprise, pour une boutique WooCommerce que vous maintenez pour un client.

Pourquoi une mise à jour casse le tunnel de commande

Le checkout WooCommerce dépend d'un enchaînement d'extensions : la passerelle de paiement, le calcul des taxes, les frais de livraison, parfois un module anti-fraude. Une mise à jour d'une seule d'entre elles suffit à rompre la chaîne, pour trois raisons courantes :

• une passerelle de paiement (Stripe, PayPal, Mollie) n'est plus compatible avec la version installée de WooCommerce ou de PHP ;
• deux extensions redéfinissent la même fonction ou chargent des scripts JavaScript qui entrent en conflit sur la page de commande ;
• la nouvelle version attend une migration de base de données qui n'a pas encore été exécutée.

Le symptôme est presque toujours le même : la vitrine répond, mais l'étape de paiement échoue. C'est précisément le scénario où un retour arrière rapide vaut mieux qu'un diagnostic long, à condition de garder une trace de l'état d'avant.

Avant la mise à jour : sauvegarde puis mesure de référence

Une mise à jour automatique bien conçue ne part jamais à l'aveugle. Sur la plateforme Sentinelo, la maintenance de nuit n'applique rien sans une sauvegarde réussie de moins de 24 heures ; s'il n'en existe pas, elle en déclenche une et reporte la mise à jour. Cette sauvegarde porte à la fois sur les fichiers et sur la base de données.

Juste avant d'appliquer, la plateforme relève ce que le site répond : son code HTTP et, si un mot-clé attendu est configuré, la présence de ce texte dans la page. Cette mesure sert de référence. Un site qui répondait déjà en erreur n'a pas été cassé par la mise à jour, et le remettre en arrière ne réparerait rien. L'agent conserve aussi la version précédente de l'extension concernée, pour pouvoir la réinstaller sans intervention humaine.

Après la mise à jour : la même mesure, et le retour arrière

La mise à jour appliquée, la plateforme refait la même mesure. Si le code de réponse a changé — une page qui passe de 200 à 500, par exemple — ou si le mot-clé attendu a disparu, la version précédente de l'extension est remise en place automatiquement. La nuit s'arrête alors pour ce site : on n'enchaîne pas d'autres mises à jour sur une boutique qui vient de revenir en arrière.

L'équipe qui gère le site reçoit un compte rendu. Pour que la même version défaillante ne revienne pas la nuit suivante, elle peut être ignorée : elle ne sera plus proposée tant qu'une version ultérieure n'est pas publiée. Le détail du mécanisme est décrit sur la page mises à jour de la plateforme.

Rollback automatique ou manuel : ce que chaque méthode couvre

Trois chemins ramènent une boutique à son état d'avant la mise à jour. Ils ne couvrent pas le même périmètre :

Méthode	Ce qu'elle remet	Base de données
Retour arrière automatique (fichiers de l'extension)	Le code de l'extension fautive	Inchangée
Extension WP Rollback	Le code d'une extension ou d'un thème, à la main	Inchangée
Restauration d'une sauvegarde complète	Fichiers et base dans leur état d'avant	Restaurée

L'extension WP Rollback, publiée sur le dépôt officiel WordPress.org, rétablit une version précédente d'un plugin ou d'un thème depuis l'interface d'administration, de la même façon que l'outil de mise à jour mais en sens inverse. C'est l'équivalent manuel du retour arrière automatique : pratique pour une boutique isolée, mais à répéter site par site sur un parc. Dans les deux cas, seuls les fichiers reviennent — la base reste sur son dernier état.

Ce que la vérification HTTP ne voit pas

Une mesure fondée sur le code HTTP et un mot-clé relit l'adresse du site, pas un parcours d'achat complet. Si la page d'accueil répond normalement mais que le paiement échoue à la dernière étape, la mesure ne bouge pas et rien n'est remis en place. Deux réglages réduisent cet angle mort :

• un mot-clé attendu bien choisi : un texte qui n'apparaît que lorsque la page se construit entièrement, plutôt qu'un mot présent même en cas d'erreur partielle ;
• la supervision, qui sonde le site toutes les 5 minutes par défaut — un intervalle configurable à 1, 15, 30 ou 60 minutes — et compte une page sans son mot-clé comme une panne. Une alerte n'est déclenchée qu'après deux sondes consécutives en échec, pour éviter les faux positifs.

Le reste relève du test en amont : une extension de paiement ou de livraison se rejoue en préproduction avant d'être laissée en mise à jour automatique. La page supervision de la plateforme détaille les sondes disponibles.

Ce que le rollback ne défait pas : la base de données

Revenir aux fichiers d'une extension ne suffit pas toujours. La documentation officielle de WooCommerce est explicite : certaines mises à jour nécessitent une mise à jour de la base de données après celle des fichiers du plugin. Cette migration modifie la structure des tables ou déplace des données. Si elle a déjà tourné et que vous remettez seulement les anciens fichiers, l'ancien code s'exécute sur une base au nouveau format — un écart qui peut casser d'autres fonctions à son tour.

La sauvegarde prise avant la mise à jour est alors le seul retour réellement complet. C'est pour cette raison qu'aucune mise à jour automatique ne part sans elle, et que la plateforme conserve plusieurs générations d'archives : 7 quotidiennes, 4 hebdomadaires, 12 mensuelles et 1 annuelle, sur 24 mois. La restauration d'une archive est lancée par l'équipe Sentinelo à la demande ; la logique de rétention est expliquée dans le guide sauvegarde et stratégie GFS.

Reprendre la main après un rollback

Une fois la boutique revenue à son état d'avant, quelques gestes referment l'incident proprement :

1. passer une commande de test avec un vrai moyen de paiement, en mode réel ou bac à sable, jusqu'à la page de confirmation ;
2. lire les journaux WooCommerce (WooCommerce > État > Journaux) pour repérer l'erreur liée à la passerelle ou au webhook ;
3. rejouer la mise à jour en préproduction pour comprendre ce qui a cassé, avant de la réautoriser ;
4. documenter la version fautive pour l'équipe, afin qu'elle reste ignorée jusqu'à un correctif.

Ce travail de vérification manuelle reste nécessaire : le retour arrière rouvre la caisse, il ne dit pas pourquoi elle s'était fermée.

Industrialiser le retour arrière sur un parc de boutiques

Sur un seul site, un rollback manuel la nuit de l'incident reste tenable. Sur dix ou cinquante boutiques clientes, la sauvegarde préalable, la mesure avant/après et le retour automatique doivent être outillés, sinon l'incident se découvre au premier client mécontent. C'est l'objet de la maintenance WooCommerce opérée par Sentinelo : chaque mise à jour est encadrée par une sauvegarde récente, une mesure de référence et un retour arrière automatique en cas de régression détectée. Pour tenir les pics de commandes, le guide maintenance WooCommerce pendant les fêtes prolonge cette approche.