Pourquoi WooCommerce casse après une mise à jour

🔎 Ce qui casse vraiment : rarement « WooCommerce » tout seul

WooCommerce core, mis à jour seul sur un site propre, casse peu. Ce qui casse, c'est le triangle thème / plugins / custom. Un thème marketplace qui surcharge le tunnel de vente, un plugin de frais de port qui s'accroche à un filtre renommé, un snippet dans functions.php copié il y a quatre ans : n'importe lequel peut transformer une mise à jour mineure en page blanche.

Les mises à jour groupées aggravent. On clique « tout mettre à jour » dans l'admin WordPress, dix extensions bougent, le cache n'est pas vidé, le CDN sert encore l'ancien JS du tunnel. Le lendemain, le bouton Payer ne répond plus. Imputer ça à WooCommerce est confortable. C'est faux. C'est l'absence de méthode.

🛠️ Les cinq coupables que je retrouve le plus souvent

Un : les plugins de tunnel de vente (un clic, champs custom, upsells). Deux : les plugins de cache et d'optimisation qui minifient le JS du tunnel. Trois : les constructeurs de pages qui ont « dessiné » le panier. Quatre : les snippets PHP oubliés. Cinq : un PHP trop vieux ou trop neuf par rapport à ce que le plugin de paiement supporte.

Derrière ces cinq, il y a souvent le même oubli : personne n'a vérifié un panier réel sur un staging après la mise à jour. Un site vitrine peut survivre à une mise à jour approximative. Une boutique WooCommerce, non. Une commande qui échoue est une vente perdue et un avis Trustpilot, pas une demande cosmétique.

• Tunnel de vente sur mesure ou plugins de paiement « en une page »
• Cache / minify qui casse le JS du tunnel
• Thème qui override les templates WooCommerce trop profondément
• Snippets et mu-plugins jamais documentés
• Mise à jour en production, sans restauration testée

✅ Pourquoi le vendredi soir revient si souvent

Parce que c'est le moment où quelqu'un « en profite » pour cliquer, ou où un plugin auto-update se déclenche. Le trafic du week-end arrive, le prestataire n'est plus là, la sauvegarde de la veille n'a jamais été restaurée. WooCommerce n'est pas plus fragile le vendredi. L'organisation l'est.

Une TMA sérieuse bloque les auto-updates du tunnel de vente, planifie les mises à jour en début de semaine, et garde quelqu'un disponible dans les deux heures qui suivent. Ce n'est pas du luxe. C'est le minimum pour une boutique qui fait du chiffre d'affaires.

⚠️ Tester WooCommerce en local et en préprod avant la prod

La copie locale sert à voir si le site démarre, si l'admin répond, si les plugins s'activent. La copie de test sert à rejouer un vrai panier : produit simple, déclinaison, code promo, transporteur, paiement sandbox, mail de confirmation. Sans ces deux étages, toute mise à jour WooCommerce est un pari.

La copie de test doit avoir les mêmes versions PHP, les mêmes constantes critiques, un cache comparable. Une copie de test « qui ressemble » mais tourne en PHP 8.2 alors que la prod est en 8.4 ment. Je détaille cette chaîne dans l'article sur les tests WordPress en local et sur une copie de test. Ici, retenir : pas de mise à jour Woo en production si le staging n'a pas encaissé un panier test.

📌 L'ordre des mises à jour qui limite la casse

On ne met pas tout à jour d'un coup. On sauvegarde (fichiers plus base), on teste la restauration une fois par trimestre pour de vrai. Puis : WordPress core sur le staging, puis WooCommerce, puis les extensions de paiement et de livraison, puis le thème, puis le reste. À chaque palier, un panier test.

Si quelque chose casse, on sait quel palier. C'est plus long qu'un clic unique. C'est incomparablement moins cher qu'un week-end sans tunnel de vente. Les boutiques qui « n'ont pas le temps » de faire ça passeront le temps à restaurer.

🧭 Quand le problème n'est pas la maj, mais la dette

Parfois WooCommerce casse à chaque mise à jour parce que le site est trop chargé : 50 plugins, un builder sur le panier, un thème enfant de 200 fichiers. Dans ce cas, la TMA des mises à jour ne suffit plus. Il faut alléger, parfois refondre le tunnel. Continuer à « juste mettre à jour » reproduit l'incident.

L'audit WooCommerce avant une campagne (soldes, Noël, lancement) sert précisément à voir si le prochain clic « mettre à jour » est sûr. Si la réponse est non, on nettoie avant. On ne lance pas une campagne sur une boutique qui n'a pas été mise à jour depuis 14 mois par peur.

💡 Ce que couvre une TMA WooCommerce digne de ce nom

Mises à jour ordonnées, staging, monitoring du tunnel de vente (pas seulement un ping HTTP), sauvegardes restaurables, corrections des vrais bugs. Pas « on clique une fois par mois ». Une TMA WooCommerce qui ne teste pas un panier n'est pas une TMA de boutique. C'est une TMA de site vitrine collée sur une caisse.

Si votre WooCommerce a déjà cassé après une mise à jour, le bon réflexe n'est pas de geler les versions pour toujours. C'est de reconstruire la chaîne de test, puis de rattraper les mises à jour par paliers. Geler, c'est accumuler la prochaine casse, plus grosse.

🧪 Liste de contrôle express après un incident

Mode maintenance ou retour arrière selon la gravité. Restaurer si le tunnel de vente est mort et que le fix n'est pas évident. Noter les versions avant / après. Regarder debug.log, les fatals PHP, la console JS du tunnel. Désactiver le dernier plugin bougé, pas les vingt d'un coup. Vérifier un panier. Puis écrire ce qui a manqué (staging, ordre, cache) pour que ça n'arrive plus.

Ensuite seulement, on reparle de « remettre à jour le reste ». Un incident WooCommerce est un signal sur la méthode, pas seulement sur un plugin. Traiter le plugin et oublier la méthode, c'est calendariser le prochain vendredi soir.

Woo ne casse pas « tout seul ». Il casse quand on met à jour sans copie de test.