Erreur critique WooCommerce après mise à jour : restaurer et récupérer en toute sécurité

janvier 9, 2026 • février 3, 2026 • Lecture : 33 min • Views: 8

Cet article vous a aidé ?

Si vous lisez ceci, votre boutique vient probablement de vivre le scénario : une mise à jour de routine, une actualisation, et soudain WordPress affiche le redouté « Il y a eu une erreur critique sur ce site web. » Les commandes s’arrêtent. Le paiement plante. L’équipe marketing commence à « juste vérifier ».

Bonne nouvelle : la plupart des défaillances WooCommerce après une mise à jour sont récupérables sans perte de données, et le chemin le plus rapide n’est pas un débogage héroïque — c’est un rollback discipliné, une lecture rigoureuse des logs, et la protection de la base de données comme si elle payait votre salaire. Parce que c’est le cas.

Table des matières

Ce que signifie réellement « erreur critique » dans l’univers WooCommerce

Ce message est l’encapsulation polie de WordPress autour d’une erreur fatale PHP. Ce n’est pas un diagnostic ; c’est un airbag. WordPress intercepte le fatal, évite d’afficher une trace de pile sur votre vitrine, et montre la page « erreur critique ». Derrière, il s’agit généralement de l’un des cas suivants :

Une mise à jour de plugin a introduit une incompatibilité (version PHP, version WordPress, autre plugin, hooks de thème).
Une mise à jour de thème (ou du code de thème personnalisé) appelle des fonctions WooCommerce supprimées.
Une mise à jour partielle a laissé des fichiers désaccordés : moitié nouveau code, moitié ancien code.
Le cache d’opcode (OPcache) sert du code obsolète alors que le système de fichiers a été modifié.
Une migration de base de données a été lancée puis a échoué en cours, laissant le schéma ou des options incohérents.
Un changement côté serveur a coïncidé avec la mise à jour : modules PHP modifiés, permissions de fichiers, disque plein, ou autoloader corrompu.

Quand WooCommerce est impliqué, il y a un angle supplémentaire : les mises à jour WooCommerce incluent parfois des migrations de base de données. Celles-ci sont généralement sûres et idempotentes, mais « généralement » n’est pas le contrat que votre directeur financier veut entendre.

Une idée paraphrasée de Werner Vogels (CTO d’Amazon) : vous construisez des systèmes en supposant que des choses vont échouer, puis vous concevez pour que le rayon d’impact soit petit et la récupération routinière.

Mode opératoire de diagnostic rapide (que vérifier en premier/deuxième/troisième)

Voici l’ordre qui vous remettra le plus rapidement en production réelle. L’objectif n’est pas de tout comprendre. L’objectif est de restaurer le paiement, puis de faire la forensique.

Premier : confirmez qu’il s’agit d’un fatal PHP et capturez la signature

Vérifiez le journal d’erreurs du serveur web (Nginx/Apache) et le log PHP-FPM pour un fatal récent autour de l’incident.
Cherchez la trame de pile principale pointant vers wp-content/plugins/ ou wp-content/themes/.
Si vous ne voyez pas les logs, activez la journalisation de débogage WordPress en toute sécurité (log vers fichier, pas d’affichage).

Deuxième : réduisez les variables en désactivant le coupable le plus probable

Désactivez d’abord le(s) plugin(s) mis à jour en dernier.
Si vous ne savez pas ce qui a changé, désactivez tous les plugins via WP-CLI ou renommez les répertoires de plugins.
Basculez vers un thème par défaut (Storefront/Twenty Twenty-*) si le fatal pointe vers le thème.

Troisième : vérifiez la santé de la base de données et si des migrations ont été exécutées

Vérifiez si WooCommerce propose des mises à jour de base de données, si des actions programmées sont bloquées, et si des options/transients sont corrompus.
Confirmez la connectivité DB et l’état de réplication si applicable.
Prenez un instantané/sauvegarde avant d’appuyer sur tout bouton « mise à jour de la base de données ».

Quand arrêter et restaurer depuis une sauvegarde

Si le site est en panne et que vous ne pouvez pas isoler le fatal en 15–30 minutes, restaurez au dernier snapshot connu bon. Puis déboguez en staging. Le débogage héroïque en production est la façon de devenir une histoire d’avertissement.

Stabiliser d’abord : arrêter l’hémorragie sans empirer les choses

La récupération commence par la stabilisation du système, parce que les systèmes brisés attirent des « corrections rapides » qui créent des incidents secondaires. Votre premier travail est d’éviter les dommages aux données :

Geler les changements : suspendre les déploiements, désactiver les mises à jour automatiques, empêcher les collègues « serviables » de cliquer sur des boutons.
Conserver les preuves : garder les logs, copier les traces de pile, enregistrer les versions.
Protéger les commandes : si le paiement est cassé mais l’administration fonctionne, envisagez de mettre la boutique en mode maintenance avec une bannière claire, et non une erreur 500.
Sauvegarder maintenant : même si vous avez déjà des sauvegardes, prenez un instantané frais avant de rollbacker quoi que ce soit. Vous pourriez avoir besoin de récupérer des commandes créées pendant la fenêtre d’indisponibilité ou des migrations partielles.

Blague courte #1 : Les mises à jour automatiques sont comme des « refactorings surprises » que vous n’avez pas planifiés — excitantes pour absolument personne en astreinte.

Logs et signaux importants (et ceux qui trompent)

Les défaillances WordPress sont bruyantes. Vous avez besoin de signaux propres.

Artifacts à fort signal

Journal d’erreurs du serveur web : indique si PHP est mort, si des timeouts sont survenus, ou si des upstreams ont échoué.
Log PHP-FPM : capture les fatals, l’épuisement mémoire et les crashs de workers.
WordPress debug.log : peut capturer des avertissements de plugin et des traces de fatal si activé.
Logs d’état WooCommerce : incluent parfois des problèmes de migration et des échecs REST.
Journal d’erreurs de la base de données : deadlocks, disque plein, tables corrompues.

Distractions à faible signal

Erreurs de la console du navigateur : utiles pour un checkout JS cassé, pas pour une erreur critique PHP.
Taux de HIT du cache : pendant une panne, les caches peuvent masquer le rayon d’impact ou continuer à servir des pages cassées de manière fiable.
« Ça marchait sur ma machine » : les environnements locaux correspondent rarement à la production en termes d’extensions PHP, limites mémoire ou permissions de fichiers.

Une astuce récurrente : une « erreur critique » qui n’apparaît que pour certains utilisateurs peut être causée par un cache de pages servant une page d’erreur en cache, ou par des pools PHP/serveurs différents exécutant des codes différents. Traitez l’incohérence comme un problème d’hygiène de déploiement d’abord.

Stratégie de rollback : plugin/thème/core sans corrompre les données

Le rollback n’est pas une seule chose. Décidez ce que vous restaurez et quel état vous devez préserver.

1) Restaurer un plugin (WooCommerce ou autre)

Si une mise à jour de plugin a déclenché le fatal, restaurer uniquement ce plugin est généralement le plus sûr. Mais considérez ce détail : si le plugin a effectué une migration de base de données, revenir en arrière sur le code peut faire planter l’ancien code sur le nouveau schéma. WooCommerce est généralement prudent sur la rétrocompatibilité, mais les extensions varient énormément.

Règle générale : restaurez le code d’abord pour rétablir le rendu des pages, puis évaluez l’état des migrations de la base avant de remettre à jour.

2) Changer de thème pour isoler les fatals côté thème

Un thème appelant des fonctions de template WooCommerce supprimées est courant après des mises à jour WooCommerce. Passer à Storefront (ou un thème WP par défaut) est une manière chirurgicale de confirmer l’implication du thème. Vous pouvez garder les plugins activés et rétablir le paiement pendant que votre équipe dev corrige le thème.

3) Restaurer WordPress core (rarement nécessaire, mais possible)

Les mises à jour du core peuvent révéler des incompatibilités latentes. Revenir en arrière sur le core est plus risqué car la compatibilité des plugins attend une direction ascendante. Je ne le fais que si (a) l’incident a clairement commencé avec une mise à jour du core, (b) l’environnement est par ailleurs stable, et (c) j’ai un snapshot connu bon pour restaurer.

4) Restauration complète depuis un snapshot

Pour les boutiques avec un trafic significatif, la « restauration complète » est souvent le chemin le plus rapide et sûr — si vous avez des snapshots disciplinés. Restaurez le code + la base à un point connu bon, remettez le site en ligne, puis rejouez les commandes manquantes si nécessaire. La clé est de comprendre votre objectif RPO (Recovery Point Objective) : combien de données vous êtes prêt à perdre.

Récupération de la base de données : éviter de transformer une erreur PHP en incident de revenus

La plupart des « erreurs critiques » WooCommerce sont au niveau du code. La base de données est souvent intacte. Ne la rendez pas non-intacte.

Ce qui peut mal tourner avec la base lors d’une mise à jour

Dérive du schéma : nouvelles colonnes/tables créées, ancien code ne les attendant pas (généralement OK), ou nouveau code qui les attend mais qui n’ont pas été créées suite à une migration échouée.
Corruption d’options : une option sérialisée mise à jour avec une structure incompatible ; PHP plante ensuite sur unserialize ou un accès tableau.
Backlog Action Scheduler : WooCommerce utilise Action Scheduler pour les tâches en arrière-plan. S’il se coince (verrous DB, timeouts), le site peut sembler « cassé » de façons étranges.
Surprises d’ensembles de caractères/collation : rares, mais les upgrades peuvent rendre certains modes SQL stricts et révéler des requêtes défaillantes dans des extensions.

Règles de sécurité pour la base pendant la récupération

Snapshot avant de cliquer sur « Exécuter la mise à jour de la base ». Toujours. Sans exception.
Préférez d’abord des requêtes de diagnostic en lecture seule. Vérifiez la présence des tables, les comptages de lignes, les écritures d’ordres récentes.
Ne « réparez les tables » pas par réflexe. Parfois nécessaire, mais c’est aussi une excellente façon de détruire des preuves et créer de nouveaux problèmes.
Comprenez ce que contient votre sauvegarde. Certaines « sauvegardes » omettent des tables transientes ou de grosses tables. Les commandes WooCommerce vivent dans posts/postmeta (ou tables HPOS si activées). Assurez-vous que votre sauvegarde couvre ce qui vous paie.

Tâches pratiques : 12+ commandes réelles, sorties et décisions

Ces tâches supposent que vous avez un accès SSH au serveur et une pile Linux standard + Nginx/Apache + PHP-FPM + MySQL/MariaDB. Ajustez les chemins pour votre distro. Chaque tâche inclut : commande, sortie d’exemple, ce que ça signifie, et la décision.

Tâche 1 : Confirmer les symptômes actuels de l’incident (statut HTTP et réponse)

cr0x@server:~$ curl -I -s https://store.example.com/ | head
HTTP/2 500
date: Fri, 27 Dec 2025 10:11:22 GMT
content-type: text/html; charset=UTF-8
server: nginx

Ce que ça signifie : C’est une défaillance côté serveur, pas juste un asset cassé ou une erreur JS.

Décision : Allez directement aux logs serveur/PHP. Ne perdez pas de temps dans le navigateur.

Tâche 2 : Trouver l’erreur fatale dans le log d’erreurs Nginx

cr0x@server:~$ sudo tail -n 60 /var/log/nginx/error.log
2025/12/27 10:11:19 [error] 22190#22190: *8841 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_logger() in /var/www/html/wp-content/plugins/some-gateway/inc/init.php:41
Stack trace:
#0 /var/www/html/wp-settings.php(453): include_once()
#1 /var/www/html/wp-config.php(90): require_once('...')
#2 /var/www/html/wp-load.php(50): require_once('...')
#3 /var/www/html/wp-blog-header.php(13): require_once('...')
#4 /var/www/html/index.php(17): require('...')
#5 {main}
  thrown in /var/www/html/wp-content/plugins/some-gateway/inc/init.php on line 41" while reading response header from upstream, client: 198.51.100.19, server: store.example.com, request: "GET / HTTP/2.0", upstream: "fastcgi://unix:/run/php/php8.1-fpm.sock:", host: "store.example.com"

Ce que ça signifie : Un plugin de passerelle de paiement a appelé une fonction WooCommerce qui n’est pas chargée (ou WooCommerce lui-même est cassé/désactivé/mi-mis à jour).

Décision : Désactivez d’abord ce plugin de passerelle. Si WooCommerce s’est mis à jour, confirmez que WooCommerce se charge correctement.

Tâche 3 : Vérifier les changements récents de paquets/fichiers (quoi a été mis à jour ?)

cr0x@server:~$ ls -lt /var/www/html/wp-content/plugins | head
total 92
drwxr-xr-x 10 www-data www-data 4096 Dec 27 10:02 woocommerce
drwxr-xr-x  8 www-data www-data 4096 Dec 27 10:02 some-gateway
drwxr-xr-x  7 www-data www-data 4096 Nov 18 09:40 wp-mail-smtp

Ce que ça signifie : WooCommerce et la passerelle ont été modifiés en même temps — probablement la fenêtre de mise à jour.

Décision : Désactivez d’abord la passerelle (rapide), puis validez que WooCommerce se charge. Si c’est toujours cassé, restaurez WooCommerce.

Tâche 4 : Désactiver rapidement un plugin en renommant son répertoire

cr0x@server:~$ cd /var/www/html/wp-content/plugins
cr0x@server:~$ sudo mv some-gateway some-gateway.disabled
cr0x@server:~$ curl -I -s https://store.example.com/ | head
HTTP/2 200
date: Fri, 27 Dec 2025 10:13:01 GMT
content-type: text/html; charset=UTF-8
server: nginx

Ce que ça signifie : Le plugin de passerelle a causé le fatal. Le site sert de nouveau des pages.

Décision : Laissez-le désactivé, puis trouvez une version compatible du plugin ou un correctif du fournisseur avant de le réactiver. Vérifiez spécifiquement le checkout.

Tâche 5 : Valider que le point de terminaison de checkout renvoie 200 (pas juste la page d’accueil)

cr0x@server:~$ curl -I -s https://store.example.com/checkout/ | head
HTTP/2 200
date: Fri, 27 Dec 2025 10:13:19 GMT
content-type: text/html; charset=UTF-8
server: nginx

Ce que ça signifie : La route checkout se rend au niveau HTTP. Ce n’est pas une garantie du succès de paiement, mais vous êtes sorti du fossé.

Décision : Procédez à la validation fonctionnelle (ajout au panier, calcul des frais de port, disponibilité des moyens de paiement) et surveillez les logs.

Tâche 6 : Si WP-CLI est disponible, lister les plugins et confirmer ce qui est actif

cr0x@server:~$ cd /var/www/html
cr0x@server:~$ sudo -u www-data wp plugin list --status=active
+-------------------+--------+-----------+---------+
| name              | status | update    | version |
+-------------------+--------+-----------+---------+
| woocommerce       | active | available | 9.3.2   |
| akismet           | active | none      | 5.3     |
| wp-mail-smtp      | active | none      | 4.3.1   |
+-------------------+--------+-----------+---------+

Ce que ça signifie : La passerelle problématique n’est plus active (bien). WooCommerce est lui-même actif, mais affiche une mise à jour disponible, ce qui peut indiquer des workflows de mise à jour partiels.

Décision : N’actualisez rien d’autre pour l’instant. Capturez l’état, puis décidez si vous devez mettre WooCommerce à jour vers une version stable en staging.

Tâche 7 : Activer la journalisation de débogage WordPress en toute sécurité (pas d’erreurs à l’écran)

cr0x@server:~$ sudo -u www-data wp config set WP_DEBUG true --raw
cr0x@server:~$ sudo -u www-data wp config set WP_DEBUG_LOG true --raw
cr0x@server:~$ sudo -u www-data wp config set WP_DEBUG_DISPLAY false --raw
cr0x@server:~$ sudo -u www-data wp config set SCRIPT_DEBUG false --raw

Ce que ça signifie : Les erreurs seront consignées dans wp-content/debug.log sans exposer les traces aux clients.

Décision : Utilisez ceci temporairement pendant la réponse à l’incident ; retirez ou restaurez ensuite pour réduire le bruit et l’utilisation disque.

Tâche 8 : Lire le log de débogage WordPress et identifier les avertissements

cr0x@server:~$ sudo tail -n 80 /var/www/html/wp-content/debug.log
[27-Dec-2025 10:13:25 UTC] PHP Warning:  Undefined array key "country" in /var/www/html/wp-content/plugins/woocommerce/includes/class-wc-countries.php on line 133
[27-Dec-2025 10:13:26 UTC] PHP Notice:  Function wpdb::prepare was called incorrectly. The query does not contain the correct number of placeholders. in /var/www/html/wp-includes/class-wpdb.php on line 1777

Ce que ça signifie : Le fatal a disparu, mais vous avez des avertissements de compatibilité. Ils peuvent devenir des fatals sous des versions PHP plus strictes ou dans des versions futures.

Décision : Suivez-les comme de la dette technique ; priorisez ceux liés au checkout/taxes/livraison.

Tâche 9 : Vérifier la version PHP et les modules chargés (contrôle de compatibilité)

cr0x@server:~$ php -v
PHP 8.1.27 (cli) (built: Nov 20 2025 12:12:11) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.27, Copyright (c) Zend Technologies
    with Zend OPcache v8.1.27, Copyright (c), by Zend Technologies

Ce que ça signifie : Vous êtes sur PHP 8.1 avec OPcache. Certains plugins anciens cassent encore ici, surtout autour de fonctions dépréciées.

Décision : Si le plugin défaillant est ancien, le ramener en arrière peut ne pas aider ; vous aurez peut-être besoin d’une version supportée par le fournisseur compatible PHP 8.1+.

Tâche 10 : Recharger PHP-FPM proprement pour vider l’OPcache (si vous soupçonnez du code obsolète)

cr0x@server:~$ sudo systemctl reload php8.1-fpm
cr0x@server:~$ sudo systemctl status php8.1-fpm --no-pager | head -n 12
● php8.1-fpm.service - The PHP 8.1 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php8.1-fpm.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2025-12-27 08:03:10 UTC; 2h 10min ago
       Docs: man:php-fpm8.1(8)

Ce que ça signifie : Le rechargement a réussi ; les workers redémarreront proprement et rafraîchiront l’état d’OPcache.

Décision : Si les problèmes disparaissent après le reload, votre « mise à jour » était peut-être un problème de cohérence de cache. Corrigez le processus de déploiement pour recharger PHP-FPM après les changements de code.

Tâche 11 : Vérifier l’espace disque (les mises à jour échouent bizarrement quand l’espace manque)

cr0x@server:~$ df -h /var/www/html | tail -n 1
/dev/vda1        40G   39G  1.1G  98% /

Ce que ça signifie : Vous êtes presque plein. Les mises à jour WordPress peuvent s’appliquer partiellement quand les écritures échouent, laissant un répertoire de plugin Frankenstein.

Décision : Libérez de l’espace avant d’essayer une réactualisation ou un rollback. Si les horodatages des répertoires de plugins semblent incohérents, envisagez de restaurer depuis une sauvegarde plutôt que de faire confiance au système de fichiers.

Tâche 12 : Confirmer la propriété des fichiers et les permissions (pour éviter des mises à jour partielles)

cr0x@server:~$ stat -c "%U:%G %a %n" /var/www/html/wp-content/plugins/woocommerce | head -n 1
www-data:www-data 755 /var/www/html/wp-content/plugins/woocommerce

Ce que ça signifie : La propriété correspond à l’utilisateur web. Si vous voyez root:root ou des permissions non concordantes, le mécanisme de mise à jour peut échouer à écrire des fichiers.

Décision : Corrigez la propriété avant de relancer les mises à jour ; sinon vous vous exposez à des pannes répétées.

Tâche 13 : Vérifier la connectivité MySQL et la santé de base

cr0x@server:~$ mysqladmin -uroot -p ping
Enter password:
mysqld is alive

Ce que ça signifie : La DB est joignable et répond.

Décision : Poursuivez avec des requêtes ciblées ; ne supposez pas une corruption DB si le problème était un fatal PHP.

Tâche 14 : Vérifier que les commandes récentes s’écrivent toujours (confirmation lecture seule)

cr0x@server:~$ mysql -uroot -p -e "USE wordpress; SELECT ID, post_date, post_status FROM wp_posts WHERE post_type='shop_order' ORDER BY ID DESC LIMIT 5;"
Enter password:
+-------+---------------------+------------+
| ID    | post_date           | post_status|
+-------+---------------------+------------+
| 81231 | 2025-12-27 10:05:41 | wc-pending |
| 81230 | 2025-12-27 09:58:10 | wc-completed |
| 81229 | 2025-12-27 09:41:03 | wc-processing |
| 81228 | 2025-12-27 09:30:55 | wc-failed |
| 81227 | 2025-12-27 09:22:14 | wc-completed |
+-------+---------------------+------------+

Ce que ça signifie : Des commandes existent pendant la fenêtre d’incident (pending/failed peut être attendu si le checkout a planté en cours).

Décision : Coordonnez-vous avec le support : identifiez les clients affectés et réconciliez les paiements. Ne purgez pas les commandes « failed » tant que vous ne comprenez pas le comportement du gateway.

Tâche 15 : Changer de thème via WP-CLI (isolation rapide)

cr0x@server:~$ sudo -u www-data wp theme list --status=active
+-----------+--------+---------+
| name      | status | version |
+-----------+--------+---------+
| my-theme  | active | 3.1.0   |
+-----------+--------+---------+
cr0x@server:~$ sudo -u www-data wp theme activate storefront
Success: Switched to 'Storefront' theme.

Ce que ça signifie : Vous pouvez contourner les fatals de thème sans toucher aux plugins.

Décision : Si le site revient avec Storefront, votre thème est en cause. Gardez Storefront temporairement et corrigez votre thème dans un déploiement contrôlé.

Tâche 16 : Si WP-CLI est indisponible, désactiver tous les plugins en renommant le répertoire plugins

cr0x@server:~$ cd /var/www/html/wp-content
cr0x@server:~$ sudo mv plugins plugins.off
cr0x@server:~$ sudo mkdir plugins
cr0x@server:~$ sudo chown www-data:www-data plugins

Ce que ça signifie : WordPress considérera les plugins comme absents. C’est l’instrument brutal qui permet de récupérer l’UI d’administration.

Décision : Utilisez ceci quand vous ne pouvez pas identifier rapidement le coupable. Remettez le site en ligne, puis réintroduisez les plugins un par un (ou par lots) pour trouver le fautif.

Tâche 17 : Valider l’état de mise à jour de la base WooCommerce (indice sur le backlog Action Scheduler)

cr0x@server:~$ sudo -u www-data wp option get woocommerce_db_version
9.3.2
cr0x@server:~$ sudo -u www-data wp option get woocommerce_version
9.3.2

Ce que ça signifie : La version du code et la version DB correspondent. Cela réduit la probabilité d’être dans un état semi-migré.

Décision : Concentrez-vous sur la compatibilité des extensions plutôt que sur la récupération DB — sauf si vous constatez des tables manquantes ou des jobs de fond bloqués.

Trois mini-récits d’entreprise depuis le terrain

Mini-récit 1 : La panne causée par une mauvaise hypothèse

L’entreprise : un détaillant de taille moyenne avec une boutique WooCommerce qui a un volume quotidien régulier, plus quelques pics saisonniers. Ils avaient un hébergeur décent et une équipe compétente. Pas une boutique « move fast and break things ». Plutôt « avancer prudemment et quand même casser des trucs, mais en réunion ».

Un ingénieur a mis à jour WooCommerce et une poignée d’extensions pendant une période tranquille en semaine. L’hypothèse : « Si l’écran de mise à jour dit que c’est compatible avec notre version de WordPress, c’est compatible avec notre environnement. » Cette hypothèse est la graine de nombreuses pannes.

Dans leur environnement, PHP avait récemment été mis à jour par l’hébergeur de 7.4 vers 8.1. Personne n’a lié cela à la boutique, parce que le site avait été « ok » pendant des semaines. La mise à jour du plugin de passerelle a introduit un chemin de code utilisant un comportement déprécié que PHP 8.1 traitait plus strictement. Toutes les pages ne le rencontraient pas. Le checkout, lui, oui, sous certaines conditions de panier.

L’équipe a cherché dans les templates WooCommerce, puis le cache, puis « peut-être Stripe est en panne ». Pendant ce temps, les clients pouvaient naviguer mais pas payer, ce qui est le type de « presque opérationnel » le plus coûteux. La correction finale fut embarrassante de simplicité : restaurer le plugin de passerelle et le figer sur une version supportée par le fournisseur.

Ce qu’ils ont changé par la suite était plus important que la correction : ils ont ajouté un rapport d’environnement pré-mise à jour (version PHP, extensions, limite mémoire) et ont cessé de faire confiance aux bannières de compatibilité comme substitut à des tests. Les bannières de compatibilité sont du marketing, pas des contrats.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre entreprise, pile similaire. Leur consultant performance avait affiné le caching de façon agressive : cache full-page en edge, object cache dans Redis, OPcache à fond, et un processus de déploiement qui « ne change que ce qui est nécessaire ». Traduction : les mises à jour de code ne redémarraient pas PHP-FPM parce que « c’est plus rapide ».

Ils ont mis à jour WooCommerce. Les fichiers ont changé. Le cache edge a bien purgé. Mais OPcache continuait à servir du bytecode ancien pour certains fichiers tandis que de nouveaux fichiers existaient sur le disque pour d’autres. Un classique split-brain entre « ce que dit le système de fichiers » et « ce que PHP exécute réellement ». Résultat : un fatal impliquant des méthodes de classe manquantes qui existaient pourtant… dans le nouveau code, pas dans le bytecode caché.

Ils ont essayé de restaurer le plugin en recopiant d’anciens fichiers. Ça a empiré parce qu’OPcache avait maintenant un mélange chaotique d’anciennes et de nouvelles versions de bytecode. Chaque rafraîchissement était une nouvelle surprise. L’équipe l’a décrit comme « hanté ». Moi, je l’ai décrit comme « prévisible, juste pas pour vous ».

La correction a été de recharger PHP-FPM, vider OPcache de façon cohérente, puis déployer en utilisant un pattern de release atomique (nouveau répertoire, switch de symlink) accompagné d’un reload contrôlé. Les performances sont restées bonnes. Et maintenant les mises à jour ne nécessitent plus de rituels de séance.

Ils ont appris à la dure : les optimisations qui évitent les redémarrages sont correctes jusqu’au moment où elles ne le sont plus. Ensuite, elles multiplient les temps d’indisponibilité.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Celle-ci est moins spectaculaire, ce qui est le but. Un vendeur B2B utilisait WooCommerce avec un petit ensemble d’extensions soigneusement choisies. Ils avaient un environnement de staging qui reflétait la production : même version PHP, même cache d’objets, même thème, et une copie nettoyée de la base de production rafraîchie chaque semaine.

Avant les mises à jour, ils suivaient une checklist : snapshot production, mise à jour en staging, exécution d’un petit jeu de tests (login, ajout au panier, checkout avec gateway de test, édition de commande en admin), puis programmation des mises à jour en production pendant une fenêtre à faible trafic. Rien de fancy. Juste de la constance.

Une mise à jour a quand même mal tourné : une mise à jour d’extension de livraison a introduit un fatal pour certains formats d’adresse. Mais staging l’a détecté. Ils ont mis en pause cette extension, mis à jour le reste, et poussé la production en toute sécurité.

Le « gain » n’a pas été que d’éviter un temps d’arrêt. C’était d’éviter la taxe panique : réunions d’urgence, restaurations de nuit, et l’érosion lente de la confiance client. Leur pratique était ennuyeuse, et elle a marché. La plupart de la fiabilité est ennuyeuse. Voilà pourquoi elle est rare.

Faits intéressants et contexte historique

Un peu de contexte aide à prédire les modes de défaillance au lieu d’y réagir.

WooCommerce a commencé comme un plugin développé par WooThemes et a ensuite rejoint l’écosystème Automattic, ce qui a influencé son rythme de sorties et ses patterns d’intégration.
WordPress a introduit l’écran « erreur critique » pour réduire la fuite d’informations à partir des fatals et guider les admins via des liens de récupération par e-mail, déplaçant le dépannage du « white screen » vers une récupération journalisée.
L’ère classique du « White Screen of Death » n’était pas juste du drame — c’étaient souvent des fatals PHP avec display_errors désactivé, obligeant les admins à apprendre des workflows axés sur les logs en premier.
WooCommerce utilise Action Scheduler (également utilisé par d’autres plugins) pour le traitement en arrière-plan ; quand il se coince, les symptômes ressemblent à « WooCommerce est cassé » même si le frontend se rend.
PHP 8.x a renforcé le comportement autour des notices et des patterns dépréciés, donc des plugins qui « marchaient depuis des années » peuvent soudainement échouer après une mise à jour serveur même avant une mise à jour de code.
Les mises à jour WordPress sont généralement atomiques au niveau du paquet, pas du système de fichiers ; si le disque se remplit en milieu de mise à jour, vous pouvez vous retrouver avec des répertoires partiels et des fichiers manquants.
OPcache a été conçu pour accélérer PHP de façon significative, mais il a introduit une nouvelle classe de pannes : le bytecode obsolète après les déploiements si vous ne rechargez pas les workers.
WooCommerce a fait évoluer son modèle de stockage des données au fil du temps (y compris un stockage haute performance optionnel des commandes) ; les migrations peuvent être sûres mais nécessitent quand même une planification de rollback.

Erreurs courantes : symptôme → cause racine → correctif

Cette section est volontairement spécifique. Les conseils génériques, c’est comme prendre encore un incident.

1) Symptom : « Erreur critique » immédiatement après la mise à jour d’une extension de paiement/livraison

Cause racine : L’extension appelle des fonctions WooCommerce avant que WooCommerce ne soit chargé, ou dépend d’une API WooCommerce plus récente que la vôtre, ou casse sur votre version PHP.

Fix : Désactivez l’extension en renommant son répertoire. Restaurez le site. Ensuite installez une version d’extension compatible sur staging et réactivez.

2) Symptom : Le site fonctionne sur un serveur mais pas sur un autre (derrière un load balancer)

Cause racine : Déploiement partiel entre nœuds, fichiers de plugin désaccordés, ou état PHP-FPM/OPcache différent.

Fix : Vérifiez les versions de release sur tous les nœuds, puis rechargez PHP-FPM partout. Utilisez des déploiements atomiques et une invalidation de cache cohérente.

3) Symptom : L’administration fonctionne, le frontend renvoie 500

Cause racine : Fatal côté thème (override de template, hook supprimé), ou un plugin qui ne s’exécute que sur les requêtes frontend.

Fix : Passez au thème Storefront ; si c’est réparé, corrigez les overrides du thème. Sinon, désactivez d’abord les plugins lourds côté frontend (cache, optimisation, page builders).

4) Symptom : « Erreur critique » apparaît, puis disparaît après quelques minutes

Cause racine : Incohérence de cache transitoire, OPcache qui se vide lentement, job de fond qui se termine, ou redémarrages progressifs.

Fix : Ne pas déclarer victoire. Rechargez PHP-FPM, videz les caches de façon cohérente, et surveillez les logs pour des fatals récurrents. Intermittent reste cassé ; il se contente de mieux se cacher.

5) Symptom : L’écran de mise à jour bloque ; après le site est cassé avec des fichiers manquants

Cause racine : Disque plein, permissions incorrectes, ou interruption réseau en cours de mise à jour menant à des fichiers de plugin/core incomplets.

Fix : Libérez de l’espace disque et restaurez depuis un snapshot connu bon. N’essayez pas de « patcher » les fichiers manquants manuellement à moins d’aimer l’archéologie sous pression.

6) Symptom : Le checkout se charge mais les paiements échouent ou les commandes restent en attente

Cause racine : Plugin de gateway désactivé/roll-backé, endpoints webhooks modifiés, ou backlog Action Scheduler empêchant l’achèvement des tâches de commande.

Fix : Vérifiez l’état du plugin de gateway et les logs webhook ; contrôlez les files d’attente Action Scheduler ; réconciliez les commandes en attente avec le fournisseur de paiement.

7) Symptom : Après rollback, WooCommerce demande de relancer des mises à jour de base

Cause racine : Désaccord code/DB ; le rollback a ramené le code en arrière mais la version DB reste en avance, ou la mise à jour ne s’est pas terminée.

Fix : Restaurez un snapshot DB correspondant au code, ou remettez le code en avant pour correspondre à la DB. Ne basculez pas en permanence ; choisissez une paire cohérente.

Checklists / plan étape par étape (sûr en production)

Checklist de réponse à incident (premiers 30 minutes)

Confirmer l’impact : page d’accueil + checkout + admin. Capturez le statut HTTP.
Geler les changements : suspendre les auto-mises à jour et déploiements jusqu’à stabilisation.
Récupérer la signature du fatal : logs serveur + PHP-FPM autour de l’heure de l’incident.
Instantané maintenant : snapshot filesystem + base de données, même si vous prévoyez de rollbacker.
Désactiver le plugin modifié en dernier : renommer le répertoire ; retester.
Si incertain : désactiver tous les plugins ; retester ; puis restaurer les plugins sélectivement.
Si thème suspecté : passer à Storefront ; retester le checkout.
Vider de façon cohérente : recharger PHP-FPM (OPcache), purger le cache full-page avec prudence.
Valider les commandes : assurer que la création de commande fonctionne toujours ; identifier les statuts bloqués.
Communiquer : page statut/communications internes : ce qui est cassé, ce qui est atténué, prochaines étapes.

Checklist rollback sûr (axé plugin)

Enregistrer la version du plugin avant rollback (depuis le readme du répertoire ou WP-CLI).
Confirmer que l’espace disque et les permissions sont corrects.
Désactiver le plugin (renommer le répertoire) pour restaurer le service rapidement.
Restaurer une version antérieure du plugin depuis votre magasin d’artefacts/sauvegarde (pas depuis des copies aléatoires).
Recharger PHP-FPM pour éviter un OPcache obsolète.
Réactiver le plugin et tester les flux critiques de façon contrôlée.
Surveiller les logs pendant 15–30 minutes après la restauration.

Checklist restauration sûre (restore complet depuis snapshot)

Identifier le dernier point de restauration connu bon et l’heure de début de la panne.
Décider du RPO : acceptez-vous de perdre les commandes entre le point de restauration et maintenant ?
Exporter les commandes créées après le point de restauration si possible (ou planifier une réconciliation manuelle).
Restaurer le snapshot de base de données en premier (ou en paire cohérente avec le snapshot filesystem).
Restaurer le filesystem (wp-content, plus le core si vous l’avez snapshoté) correspondant à cette DB.
Recharger PHP-FPM et le serveur web.
Valider le checkout de bout en bout avec des transactions de test.
Réconcilier les commandes/paiements de la fenêtre manquante.

Blague courte #2 : La seule chose pire qu’aucune sauvegarde, c’est découvrir que votre « sauvegarde » est un poster motivant avec une icône ZIP.

Prévention : éviter que les mises à jour vous plantent à nouveau

Une fois que vous avez récupéré, la tentation est de souffler et de passer à autre chose. Résistez. Récupérer sans prévenir, c’est juste programmer votre prochaine panne.

1) Effectuer les mises à jour en staging qui correspond réellement à la production

Un site de staging qui tourne PHP 7.4 alors que la production tourne 8.1 n’est pas du staging. C’est du théâtre. Alignez :

Version PHP et extensions
Moteur/version de base de données et mode SQL
Comportement du cache d’objets (Redis/Memcached)
Paramètres OPcache
Thème et plugins must-use

2) Traitez les mises à jour WooCommerce comme des « releases applicatives »

WooCommerce n’est pas un plugin de formulaire de contact. C’est votre moteur de revenus. Cela implique :

Fenêtres de maintenance pour les mises à jour majeures
Relecture des changelogs comme des notes de release, pas comme une newsletter
Plans documentés de roll-forward et rollback
Scripts de vérification post-mise à jour (smoke tests) exécutés à chaque fois

3) Contrôler la dérive de versions et supprimer la roulette à plugins

Trop de magasins vivent un « marketplace de plugins » en production : 40+ plugins, chacun avec son propre calendrier de sorties et qualité de support. Le taux d’échec est prévisible. Réduisez-le :

Supprimez les plugins dont vous n’avez pas absolument besoin.
Préférez des fournisseurs bien maintenus avec des déclarations de compatibilité claires.
Figez les versions et mettez à jour par lots avec des combinaisons connues bonnes.

4) Rendre les déploiements atomiques et conscients du cache

Si vous mettez à jour du code, vous devez contrôler :

Atomicité système de fichiers : déployer dans un nouveau répertoire puis basculer un symlink, ou éviter autrement les états de fichiers partiels.
Cohérence OPcache : recharger PHP-FPM après le déploiement, ou utiliser un mécanisme d’invalidation de cache sûr.
Vidé du cache edge/full-page : purger après le déploiement, pas avant, et éviter de mettre en cache des réponses d’erreur.

5) Surveiller les bonnes choses

Si vous ne surveillez que « HTTP 200 sur la page d’accueil », vous manquerez les échecs coûteux. Surveillez :

Taux de succès du checkout
Taux de création de commandes et de complétion des paiements
Nombre de fatals PHP dans les logs (alerter sur les pics)
Deadlocks/timeouts en base de données
Backlogs de file d’attente (Action Scheduler)

FAQ

1) Dois‑je rollback WooCommerce ou l’extension qui a été mise à jour ?

Restaurez (ou désactivez) d’abord l’extension si la trace du fatal pointe vers elle. WooCommerce est la plateforme ; les extensions sont les coupables habituels. Si le fatal se situe dans les fichiers core de WooCommerce, envisagez de rollbacker WooCommerce ou de restaurer depuis un snapshot.

2) Puis‑je corriger l’« erreur critique » en désactivant tous les plugins ?

Oui, et c’est souvent la méthode d’isolation la plus rapide. C’est perturbant, mais cela vous rend l’UI admin opérationnelle. Ensuite réactivez les plugins par lots jusqu’à retrouver le coupable. Faites‑le méthodiquement, pas émotionnellement.

3) Pourquoi la mise à jour a réussi dans le tableau de bord mais le site a cassé ?

Le flux de mise à jour du tableau de bord peut se terminer même si certains fichiers n’ont pas été écrits correctement, surtout en cas d’espace disque faible ou de problèmes de permissions. De plus, un plugin peut s’installer mais rester incompatible avec votre version PHP ou un autre plugin. « Installé » n’est pas synonyme de « fonctionnel ».

4) Dois‑je lancer les mises à jour de la base WooCommerce après une mise à jour ?

Parfois, oui. Mais prenez un snapshot d’abord. Si vous avez déjà rollbacké le code, ne lancez pas des migrations avant qui avanceront la DB sur un code rétrogradé. Alignez le code et la DB.

5) Que faire si je n’ai pas accès à wp-admin pour désactiver des plugins ?

Renommez le répertoire du plugin en SSH (wp-content/plugins → plugins.off) ou renommez le dossier du plugin suspect. WordPress traitera les plugins comme inactifs sans wp-admin.

6) Le caching peut‑il provoquer une « erreur critique » ?

Le caching provoque rarement le fatal lui‑même, mais il peut l’amplifier (servir des pages d’erreur en cache) ou le rendre intermittent (serveurs différents, état OPcache différent). Purgez les caches de façon cohérente et rechargez PHP-FPM après les changements de code.

7) Après avoir désactivé le plugin cassé, le checkout marche mais les paiements non. Que faire maintenant ?

C’est attendu si le plugin de paiement est le fautif. Restaurez le service d’abord (même en « lecture seule »), puis choisissez une version de gateway compatible et validez les webhooks. Entre‑temps, réconciliez les commandes en attente avec les logs du fournisseur de paiement.

8) Est‑il sûr de restaurer seulement les fichiers et pas la base de données ?

Parfois oui. Si vous êtes sûr qu’aucune migration de base n’a été exécutée et que les commandes circulent, un rollback du code seul peut être sûr. Si WooCommerce ou une extension a pu changer le schéma/options, restaurez code et DB en paire cohérente ou acceptez que vous faites une expérience.

9) Quel est le moyen le plus rapide d’identifier le plugin en faute ?

La trace du fatal dans les logs le nomme généralement. Cherchez des chemins sous wp-content/plugins/ dans les logs. Si les logs sont indisponibles, désactivez tous les plugins, puis réactivez‑les jusqu’au retour de l’erreur. C’est rustique, mais fiable.

10) Dois‑je laisser WP_DEBUG activé après correction ?

Non. Désactivez‑le (ou au moins la journalisation) une fois stable, sauf si vous avez une rotation des logs et une raison. Les fichiers de debug grossissent vite. Le remplissage disque transforme des avertissements mineurs en pannes majeures.

Conclusion : prochaines étapes que vous pouvez faire aujourd’hui

Si votre boutique WooCommerce a lancé une erreur critique après une mise à jour, la bonne stratégie est ennuyeuse et reproductible :

Obtenez la signature du fatal depuis les logs serveur/PHP. Ne devinez pas.
Désactivez le coupable (généralement une extension) pour restaurer le service rapidement.
Rechargez PHP-FPM pour éviter les bizarreries OPcache après des changements de code.
Validez le checkout et l’écriture des commandes, pas seulement la page d’accueil.
Puis seulement faites le travail approfondi : reproduction en staging, figer les versions, et prévenir.

Et demain — quand personne ne crie — construisez les garde‑fous : staging proche de la production, snapshots avant les mises à jour, déploiements atomiques, et une surveillance qui comprend votre activité (les commandes) et pas seulement vos serveurs (les pings). Voilà comment rendre les mises à jour WooCommerce à nouveau ennuyeuses.