Un plugin WordPress a cassé votre site : désactivez-le via FTP/SSH et récupérez rapidement

décembre 25, 2025 • février 3, 2026 • Lecture : 28 min • Views: 10

Cet article vous a aidé ?

Votre site fonctionnait. Puis vous avez mis à jour « un petit plugin ». Maintenant vous êtes face à une erreur 500, un écran blanc, ou un wp-admin qui refuse poliment de se charger. La direction veut un ETA. Votre pager refait ce bruit. Bienvenue.

Ceci est un guide de récupération pour les personnes qui ont besoin que le site soit de nouveau opérationnel tout de suite, sans aggraver l’analyse post-incident. Nous allons désactiver le plugin défaillant depuis le système de fichiers (FTP/SSH), confirmer ce qui s’est réellement passé, et mettre en place des garde-fous pour que la prochaine mise à jour ne se transforme pas en incident.

Mode d’intervention rapide (10 premières minutes)

Vous essayez de répondre à une seule question : Le site est-il en panne à cause d’un crash PHP, d’une base de données inaccessible, ou parce que WordPress est bloqué dans un mauvais état (mode maintenance, options autoloadées, conflit de plugins) ?

Ne faites pas de « corrections au hasard ». C’est ainsi que vous obtenez un site qui fonctionne sans savoir pourquoi, ce qui est une façon polie de dire « incident répété ». Voici l’ordre qui identifie rapidement le goulot d’étranglement.

1) Confirmez le mode de défaillance depuis l’extérieur

Si vous voyez HTTP 500/502/503 : suspectez des erreurs fatales PHP, des timeouts en amont, ou le mode maintenance.
Si vous voyez un écran blanc (pas de HTML) : classique erreur fatale PHP ou mémoire épuisée.
Si wp-admin se charge mais les actions échouent : écriture en base de données, permissions, problèmes de nonce/session, ou un hook de plugin spécifique.
Si seule la page d’accueil échoue : thème, couche de cache, constructeur de pages, ou une route spécifique.

2) Vérifiez les logs du serveur avant de toucher WordPress

Les logs vous indiquent si vous avez affaire à une erreur fatale de plugin, un problème de permissions, ou quelque chose de plus bas niveau (PHP-FPM arrêté, disque plein). Si vous ne trouvez pas rapidement les logs, vous pouvez toujours procéder à la désactivation des plugins via le système de fichiers comme outil brutal — mais c’est mieux quand vous pouvez nommer le coupable.

3) Désactivez le plugin suspect (un seul plugin d’abord)

Si vous savez quel plugin a été mis à jour, désactivez celui-ci en renommant son dossier. Si vous ne savez pas, désactivez tous les plugins en renommant le répertoire plugins. Restaurez le site, puis affinez l’origine du problème.

4) Videz les caches et confirmez que PHP est sain

Le cache d’objets, le cache de page, le cache CDN et l’opcache PHP peuvent tous continuer à servir un comportement erroné après que vous ayez « corrigé » les fichiers. Vérifiez avec une requête directe, relisez les logs, et ne déclarez la victoire qu’ensuite.

5) Stabilisez avant de réactiver quoi que ce soit

Une fois que le site est revenu, votre rôle change : préservez les preuves (logs), empêchement des mises à jour automatiques de réintroduire le problème, et créez un chemin sécurisé pour réintroduire le plugin ou revenir à une version antérieure.

Une citation à garder : Idée paraphrasée — Gene Kranz : l’échec n’est pas acceptable ; les équipes réussissent grâce à une préparation disciplinée et une exécution sous pression.

Ce qui casse généralement quand un plugin « casse WordPress »

Les plugins WordPress ne sont pas des « extensions » au sens inoffensif. Ce sont des morceaux de PHP qui s’exécutent dans le cycle de requête avec les mêmes privilèges que le noyau. Un plugin peut :

Lancer une erreur fatale (erreur de syntaxe, classe/fonction manquante, incompatibilité de version PHP).
Consommer toute la mémoire ou provoquer des timeouts (boucles infinies, options autoloadées volumineuses, requêtes coûteuses).
Briser les sessions d’administration (cookies, nonces, redirections).
Corrompre les règles de réécriture ou émettre des en-têtes invalides.
Déclencher des modifications de schéma de base de données partiellement appliquées.

Deux « pièges » majeurs qui rendent les incidents de plugin aléatoires :

Options autoloadées : Certains plugins stockent de grandes données dans wp_options avec autoload = 'yes'. Cela signifie que WordPress les charge en mémoire sur de nombreuses requêtes. Tout ralentit, puis plante.
Ordre de chargement et hooks : Votre site peut ne se casser que pour les utilisateurs connectés, ou seulement lors du cron, car c’est là que le hook du plugin s’exécute.

Blague #1 : Une mise à jour de plugin, c’est comme « juste un petit changement » le vendredi — techniquement possible, spirituellement imprudent.

Voie de récupération A : désactiver le plugin via FTP / gestionnaire de fichiers

Si vous avez FTP ou un gestionnaire de fichiers chez l’hébergeur mais pas de shell, vous pouvez quand même récupérer rapidement. L’objectif est d’empêcher WordPress de charger le code du plugin. WordPress charge les plugins en scannant les répertoires sous wp-content/plugins. Si le nom du répertoire change, WordPress le considère comme manquant et le désactive.

Désactiver un plugin (préféré)

Connectez-vous via FTP / ouvrez le gestionnaire de fichiers de l’hébergeur.
Accédez à : public_html/wp-content/plugins/ (la racine peut varier).
Trouvez le dossier du plugin qui a été mis à jour ou qui semble suspect.
Renommez-le, par exemple :
- elementor → elementor.disabled
- woocommerce → woocommerce.off
Rechargez le site et wp-admin.

Ce que cela fait : WordPress voit le plugin comme manquant et le marque comme désactivé. C’est rudimentaire, mais ça marche même quand PHP est en feu.

Désactiver tous les plugins (nucléaire, mais rapide)

Allez dans wp-content/.
Renommez plugins → plugins.disabled.
Rechargez. Si le site revient, vous avez prouvé que l’incident est lié aux plugins.
Créez un nouveau répertoire vide plugins (WordPress s’y attend), puis replacez les plugins un par un.

Quand la récupération par FTP échoue

FTP fonctionne jusqu’à ce que les permissions, la propriété, ou le cache deviennent étranges. Si le renommage ne tient pas, ou si les changements sont annulés, vous êtes probablement face à :

un système de déploiement qui écrase les fichiers
système de fichiers en lecture seule / problèmes de permissions
plusieurs copies de WordPress et vous éditez la mauvaise

À ce stade vous avez besoin de SSH ou du support de l’hébergeur pour confirmer la racine documentaire réelle et la propriété des fichiers.

Voie de récupération B : désactiver le plugin via SSH (et pourquoi c’est mieux)

SSH transforme la récupération de « cliquer et prier » en « observer, modifier, vérifier ». Vous pouvez tailer les logs, confirmer les chemins, et annuler proprement.

Plan SSH minimal viable

Trouvez le répertoire racine de WordPress.
Confirmez le répertoire des plugins et le nom du dossier du plugin.
Renommez le dossier du plugin (ou le répertoire plugins) pour le désactiver.
Vérifiez les logs pour confirmer que l’erreur fatale a cessé.
Rechargez avec curl et vérifiez le statut HTTP et le contenu.

Pourquoi le renommage fonctionne de manière fiable

WordPress stocke les « plugins actifs » dans la base de données, mais il vérifie toujours si le fichier du plugin existe. Si le dossier a disparu, WordPress ne peut pas l’inclure et le désactive au prochain chargement. Renommer crée effectivement un « air gap » entre WordPress et le PHP cassé.

Voie de récupération C : WP-CLI deactivate (l’option la plus propre)

Si WP-CLI est installé et que vous pouvez l’exécuter en tant qu’utilisateur correct, c’est l’option la plus contrôlée. Elle met à jour l’état interne de WordPress au lieu de compter sur des astuces du système de fichiers. Mais si PHP est cassé au point d’empêcher WP-CLI de booter, le renommage gagne encore.

Vérifier la récupération comme un SRE (ne pas se fier à la page d’accueil)

Ramener la page d’accueil est agréable. Ce n’est pas une « récupération ». La vraie vérification inclut :

wp-admin se charge et la connexion fonctionne
une requête contournant le cache retourne 200
les logs d’erreur ne montrent plus de fatales
les formulaires de commande/contact se soumettent toujours
cron ne spame pas d’erreurs

Autre point : prenez un instantané (sauvegarde) après la stabilisation. Pas avant. Une sauvegarde d’un état cassé est un souvenir, pas une solution.

Tâches pratiques avec commandes : ce que la sortie signifie et quoi faire ensuite

Ci-dessous se trouvent des tâches pratiques que vous pouvez exécuter en SSH. Chacune inclut (1) la commande, (2) un exemple de sortie, (3) ce que la sortie signifie, et (4) la décision à prendre ensuite.

Task 1: Confirm you’re in the right WordPress root

cr0x@server:~$ cd /var/www/example.com/public_html && ls -la
total 248
drwxr-xr-x  7 www-data www-data   4096 Dec 27 09:10 .
drwxr-xr-x  3 root     root       4096 Dec 20 11:02 ..
-rw-r--r--  1 www-data www-data    420 Nov  3 10:21 index.php
-rw-r--r--  1 www-data www-data  19935 Nov  3 10:21 wp-blog-header.php
-rw-r--r--  1 www-data www-data   3516 Nov  3 10:21 wp-config.php
drwxr-xr-x  9 www-data www-data   4096 Dec 10 12:01 wp-content
drwxr-xr-x  8 www-data www-data   4096 Nov  3 10:21 wp-admin
drwxr-xr-x 25 www-data www-data   4096 Nov  3 10:21 wp-includes

Signification : La présence de wp-config.php, wp-admin et wp-includes suggère fortement que vous êtes au bon endroit.

Décision : Poursuivre. Si vous ne voyez pas ces fichiers, arrêtez-vous et trouvez la véritable racine documentaire. Désactiver des plugins dans le mauvais répertoire est la façon dont les gens « ne corrigent rien » pendant une heure.

Task 2: Identify the last modified plugin directories (often the culprit)

cr0x@server:~$ cd /var/www/example.com/public_html/wp-content/plugins && ls -lt | head
total 64
drwxr-xr-x 12 www-data www-data 4096 Dec 27 09:02 some-plugin
drwxr-xr-x 10 www-data www-data 4096 Dec 27 08:58 cache-tool
drwxr-xr-x  8 www-data www-data 4096 Dec 10 12:00 seo-pack
drwxr-xr-x 15 www-data www-data 4096 Dec  1 15:22 woocommerce

Signification : Les plugins mis à jour récemment remontent en haut. Ce timestamp correspond souvent à la fenêtre de l’incident.

Décision : Commencez par désactiver le plugin le plus récemment modifié qui correspond à la fenêtre de changement.

Task 3: Disable a single plugin by renaming its directory

cr0x@server:~$ mv /var/www/example.com/public_html/wp-content/plugins/some-plugin /var/www/example.com/public_html/wp-content/plugins/some-plugin.disabled

Signification : L’absence de sortie est normale pour mv. Si une erreur survient, vous verrez des problèmes de permission ou de chemin manquant.

Décision : Si le site revient, vous avez isolé le coupable. Sinon, passez à la désactivation de tous les plugins ou vérifiez les logs pour un autre mode de défaillance.

Task 4: Disable all plugins by renaming the plugins directory

cr0x@server:~$ cd /var/www/example.com/public_html/wp-content && mv plugins plugins.disabled && mkdir plugins

Signification : WordPress traitera tous les plugins comme manquants ; créer un répertoire plugins vide évite les avertissements et garde les futures installations cohérentes.

Décision : Si le site est de retour maintenant, vous savez que c’est lié aux plugins. S’il reste indisponible, concentrez-vous sur PHP, la base de données ou le serveur web.

Task 5: Curl the site and confirm status without a browser’s cache

cr0x@server:~$ curl -sS -D- -o /dev/null https://example.com/ | head -n 12
HTTP/2 200
date: Sat, 27 Dec 2025 09:12:10 GMT
content-type: text/html; charset=UTF-8
cache-control: no-cache, must-revalidate, max-age=0
server: nginx

Signification : HTTP 200 suggère que la couche web et PHP répondent. Les en-têtes indiquent si un cache est en jeu.

Décision : Si vous voyez encore 500/502/503, inspectez les logs immédiatement. Si c’est 200 mais le contenu est erroné, suspectez un cache ou des échecs partiels.

Task 6: Tail PHP-FPM or web error logs to catch the fatal error line

cr0x@server:~$ sudo tail -n 60 /var/log/nginx/error.log
2025/12/27 09:03:44 [error] 22110#22110: *881 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function some_plugin_init() in /var/www/example.com/public_html/wp-content/plugins/some-plugin/some-plugin.php:42
Stack trace:
#0 /var/www/example.com/public_html/wp-settings.php(453): include_once()
#1 /var/www/example.com/public_html/wp-config.php(92): require_once('...')
#2 /var/www/example.com/public_html/wp-load.php(50): require_once('...')
#3 /var/www/example.com/public_html/wp-blog-header.php(13): require_once('...')
#4 /var/www/example.com/public_html/index.php(17): require('...')
#5 {main}
  thrown" while reading response header from upstream, client: 203.0.113.10, server: example.com, request: "GET / HTTP/2.0"

Signification : C’est le coupable évident : fonction indéfinie dans un fichier de plugin. Souvent causé par une dépendance manquante, une mise à jour incomplète, ou une incompatibilité de version PHP.

Décision : Désactivez ce plugin (renommage du dossier) et laissez-le désactivé jusqu’à ce que vous puissiez soit revenir en arrière, soit corriger l’environnement.

Task 7: Confirm disk space (full disks cause “random” PHP failures)

cr0x@server:~$ df -h /var/www
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G   39G  420M  99% /

Signification : 99% d’utilisation, c’est territory d’incident. Les mises à jour peuvent échouer en cours d’extraction, les logs ne peuvent pas s’écrire, les sessions PHP ne peuvent pas se sauver. Tout devient instable.

Décision : Libérez de l’espace d’abord. Sinon vous « corrigerez » le plugin et le site replongera cinq minutes plus tard.

Task 8: Look for a stuck maintenance mode file

cr0x@server:~$ ls -la /var/www/example.com/public_html/.maintenance
-rw-r--r-- 1 www-data www-data 55 Dec 27 09:01 /var/www/example.com/public_html/.maintenance

Signification : WordPress supprime .maintenance pendant les mises à jour. Si la mise à jour plante, le fichier peut rester et maintenir le site en mode maintenance.

Décision : Supprimez-le si vous n’êtes pas en train de mettre à jour activement.

cr0x@server:~$ rm -f /var/www/example.com/public_html/.maintenance

Task 9: Validate PHP version vs plugin requirements

cr0x@server:~$ php -v
PHP 7.4.33 (cli) (built: Nov  8 2024 10:14:11) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies

Signification : Beaucoup de plugins modernes exigent de plus en plus PHP 8.x. Si une mise à jour de plugin suppose PHP 8 et que vous êtes en 7.4, des erreurs fatales peuvent survenir immédiatement.

Décision : Si le plugin requiert une version PHP plus récente, laissez-le désactivé et planifiez une mise à niveau PHP ordonnée (ou revenez à la version précédente du plugin). N’« améliorez » pas PHP en catastrophe pendant l’incident à moins d’aimer les longues soirées.

Task 10: Check file ownership/permissions (failed updates often leave root-owned files)

cr0x@server:~$ find /var/www/example.com/public_html/wp-content/plugins -maxdepth 2 -type f -name '*.php' -printf '%u %g %p\n' | head
root root /var/www/example.com/public_html/wp-content/plugins/some-plugin/some-plugin.php
www-data www-data /var/www/example.com/public_html/wp-content/plugins/seo-pack/seo-pack.php

Signification : Un fichier de plugin possédé par root dans un arbre normalement possédé par www-data suggère que quelqu’un a lancé une mise à jour en tant que root (ou qu’un outil d’extraction l’a fait). WordPress peut ensuite échouer à écraser ou nettoyer.

Décision : Corrigez la propriété pour le plugin affecté ou pour l’arbre entier (avec précaution), puis relancez les mises à jour via le mécanisme approprié.

cr0x@server:~$ sudo chown -R www-data:www-data /var/www/example.com/public_html/wp-content/plugins/some-plugin.disabled

Task 11: Confirm database connectivity from WordPress config (without dumping secrets)

cr0x@server:~$ grep -E "DB_NAME|DB_USER|DB_HOST" /var/www/example.com/public_html/wp-config.php
define( 'DB_NAME', 'wpdb' );
define( 'DB_USER', 'wpuser' );
define( 'DB_HOST', '127.0.0.1' );

Signification : Vous vérifiez l’hôte DB et que vous regardez la bonne config pour ce site.

Décision : Si le symptôme ressemble à une défaillance DB (« Error establishing a database connection »), testez le service DB ensuite.

Task 12: Check MySQL/MariaDB health on the host

cr0x@server:~$ sudo systemctl status mariadb --no-pager | sed -n '1,12p'
● mariadb.service - MariaDB 10.6.16 database server
     Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2025-12-27 08:10:03 UTC; 1h 2min ago
       Docs: man:mariadbd(8)
             https://mariadb.com/kb/en/library/systemd/
   Main PID: 982 (mariadbd)
     Status: "Taking your SQL requests now..."

Signification : La DB fonctionne. Cela ne prouve pas que les requêtes sont rapides, mais cela retire « la DB est down » de la liste.

Décision : Si le site est encore cassé, retournez l’attention sur les erreurs PHP, les plugins et les couches de cache.

Task 13: Find the plugin’s fatal error in PHP logs (if separate)

cr0x@server:~$ sudo tail -n 60 /var/log/php8.1-fpm.log
[27-Dec-2025 09:03:44] WARNING: [pool www] child 22134 said into stderr: "PHP Fatal error:  Uncaught Error: Call to undefined function some_plugin_init() in /var/www/example.com/public_html/wp-content/plugins/some-plugin/some-plugin.php:42"

Signification : Confirme que l’erreur fatale est au niveau PHP-FPM, pas une déduction de Nginx.

Décision : Laissez le plugin désactivé et corrigez la non-correspondance sous-jacente (version du plugin, dépendance, version PHP).

Task 14: Verify the WordPress site responds locally (bypass CDN/DNS issues)

cr0x@server:~$ curl -sS -H 'Host: example.com' http://127.0.0.1/ | head -n 5
<!doctype html>
<html lang="en-US">
<head>
<meta charset="UTF-8">

Signification : Le serveur d’origine rend du HTML localement. Si les utilisateurs externes voient encore des erreurs, le problème peut venir du cache CDN, des règles WAF, ou des vérifications de santé du load balancer.

Décision : Si local fonctionne et externe échoue, déplacez l’attention en amont : CDN, reverse proxy, terminaison TLS, pare-feu.

Task 15: Use WP-CLI to list plugins (if possible)

cr0x@server:~$ cd /var/www/example.com/public_html && sudo -u www-data wp plugin list
+-------------------+----------+-----------+---------+
| name              | status   | update    | version |
+-------------------+----------+-----------+---------+
| seo-pack          | inactive | none      | 3.2.1   |
| cache-tool        | inactive | available | 2.9.0   |
| some-plugin       | inactive | none      | 1.4.0   |
+-------------------+----------+-----------+---------+

Signification : Vous pouvez voir ce qui est actif/inactif et les mises à jour disponibles. Après un renommage de dossier, WP-CLI peut afficher le plugin comme manquant ou inactif selon l’état.

Décision : Utilisez WP-CLI pour réactiver avec précaution plus tard, un plugin à la fois, en surveillant les logs.

Task 16: Deactivate a plugin cleanly with WP-CLI

cr0x@server:~$ cd /var/www/example.com/public_html && sudo -u www-data wp plugin deactivate some-plugin
Plugin 'some-plugin' deactivated.
Success: Deactivated 1 of 1 plugins.

Signification : WordPress reconnaît maintenant que le plugin est inactif. C’est plus propre que de renommer le dossier quand vous pouvez l’exécuter.

Décision : Si la désactivation réussit et que le site se rétablit, vous pouvez restaurer le nom du dossier du plugin (si vous l’avez renommé) sans le réactiver.

Task 17: Check for runaway autoloaded options (common “everything got slow” cause)

cr0x@server:~$ cd /var/www/example.com/public_html && sudo -u www-data wp db query "SELECT option_name, LENGTH(option_value) AS bytes FROM wp_options WHERE autoload='yes' ORDER BY bytes DESC LIMIT 10;"
+---------------------------+--------+
| option_name               | bytes  |
+---------------------------+--------+
| some_plugin_cache_blob    | 524288 |
| rewrite_rules             | 182944 |
| wp_user_roles             |  32768 |
+---------------------------+--------+

Signification : Un blob autoloadé d’un demi-mega est suspect. Il gonfle la mémoire et ralentit chaque requête.

Décision : Laissez le plugin désactivé ; envisagez de supprimer ou de passer l’option en non-autoload après sauvegarde et examen minutieux.

Task 18: Check PHP memory limit quickly (symptom: white screen or “Allowed memory size exhausted”)

cr0x@server:~$ php -r 'echo ini_get("memory_limit").PHP_EOL;'
128M

Signification : 128M peut être juste pour des plugins lourds/constructeurs de pages. Mais augmenter la mémoire est un pansement, pas un diagnostic.

Décision : Si les logs montrent une épuisement mémoire, vous pouvez temporairement augmenter la mémoire pour restaurer le service, puis corriger le comportement du plugin ou le supprimer.

Erreurs courantes : symptômes → cause racine → correctif

Cette section évite à votre futur vous de répéter l’incident. Ce ne sont pas des théories ; cela arrive parce que WordPress est un agrégat de bonnes intentions et d’inclusions PHP.

1) Symptom: “I renamed the plugin folder but nothing changed”

Cause racine : Vous avez modifié la mauvaise instance WordPress (mauvaise docroot), ou un job de déploiement a restauré le dossier, ou le site est servi depuis un autre nœud.
Correctif : Confirmez la docroot (Task 1), confirmez avec curl local (Task 14), et vérifiez si vous êtes sur un setup load-balanced. Appliquez les changements sur l’origine réelle ou sur tous les nœuds.

2) Symptom: “Site shows maintenance mode forever”

Cause racine : Fichier .maintenance coincé après une mise à jour ratée.
Correctif : Supprimez .maintenance (Task 8). Puis enquêtez sur la raison de l’échec de la mise à jour (disque plein, permissions, timeout).

3) Symptom: HTTP 502 Bad Gateway after plugin update

Cause racine : PHP-FPM plante ou timeoute à cause d’erreurs fatales, d’épuisement mémoire, ou de requêtes longues déclenchées par le plugin.
Correctif : Vérifiez le log Nginx et le log PHP-FPM (Tasks 6, 13). Désactivez le plugin ; puis traitez les ressources PHP ou le bug de code.

4) Symptom: wp-admin loads, but saving settings throws 500

Cause racine : Hooks de plugin sur les requêtes POST admin qui provoquent des erreurs fatales seulement sur ce chemin ; ou WAF bloque certains payloads ; ou PHP max input vars/time.
Correctif : Taillez les logs pendant la reproduction. Désactivez le plugin suspect et retestez. Si cela échoue encore, vérifiez les logs WAF et les paramètres PHP.

5) Symptom: Everything is “up” but painfully slow after plugin update

Cause racine : Bloat d’options autoloadées, requêtes DB coûteuses, ou thrash du cache d’objets.
Correctif : Inspectez les tailles autoloadées (Task 17), vérifiez les slow logs DB si disponibles, et désactivez temporairement les plugins de cache pour comparer le comportement.

6) Symptom: Only logged-in users see a white screen

Cause racine : Le plugin s’exécute seulement pour l’admin/barre d’outils, ou des hooks spécifiques aux utilisateurs ; l’erreur fatale est masquée par les réglages d’affichage des erreurs.
Correctif : Tirez les logs pendant que vous accédez à wp-admin. Désactivez d’abord les plugins administratifs suspectés (sécurité, éditeurs, builders).

7) Symptom: Plugin won’t update, or updates “succeed” but revert

Cause racine : Mauvaise propriété/permissions, fichiers immuables, ou un système CI/deploy qui écrase l’arbre.
Correctif : Vérifiez la propriété (Task 10). Confirmez si les fichiers WordPress sont gérés par Git/déploiement. Décidez d’une autorité : soit le système de déploiement, soit l’updater WordPress, pas les deux.

8) Symptom: You fixed it, then it broke again minutes later

Cause racine : Les mises à jour automatiques ont réappliqué la version, une tâche cron a réactivé quelque chose, ou le cache s’est régénéré avec du code cassé depuis un autre nœud.
Correctif : Désactivez temporairement les mises à jour automatiques, vérifiez les événements cron, et assurez-vous que tous les nœuds partagent le même état des plugins.

Trois mini-récits d’entreprise issus des tranchées des incidents

Mini-récit 1 : L’incident causé par une fausse hypothèse

Une entreprise de taille moyenne gérait un site marketing WordPress derrière un CDN et un load balancer managé. Le site « est tombé » juste après une mise à jour de plugin. L’ingénieur en astreinte a fait le playbook standard : SSH sur le serveur, renommage du dossier du plugin en cause, rafraîchir le navigateur.

Toujours en panne. Même 500.

L’hypothèse erronée était subtile : ils ont supposé qu’il n’y avait qu’une seule origine. Il y en avait deux. L’un était un nœud plus ancien laissé après une migration, toujours enregistré dans le pool du load balancer. Le plugin avait été désactivé sur le nœud où ils étaient connectés (parce qu’ils se souvenaient de ce hostname), mais le trafic était encore dirigé vers l’autre nœud exécutant le code cassé.

Ils l’ont finalement prouvé en curlant chaque nœud directement avec un en-tête Host. Un nœud retournait 200, l’autre 500. Une fois le plugin désactivé sur le second nœud, l’incident s’est résolu immédiatement.

La correction post-incident a été ennuyeuse et efficace : retirer les origines obsolètes du pool, documenter l’inventaire autoritaire. Aussi : ne plus compter sur « l’hostname que vous vous souvenez ». La production n’a pas de compassion pour votre mémoire.

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

Une autre organisation avait un site WordPress à fort trafic et voulait accélérer les pages. Quelqu’un a installé un plugin de cache et poussé les réglages à fond : minification HTML agressive, combinaison de scripts, tout différer, et activation d’un cache d’objets soutenu par un démon local. Les benchmarks synthétiques s’amélioraient.

Puis une mise à jour de plugin est arrivée. Le site a commencé à renvoyer des 502 intermittents. Pas systématiquement — juste assez pour être rageant. Le plugin n’était pas toute l’histoire : la couche de cache mettait en cache des réponses d’erreur partielles et les servait sporadiquement. Par ailleurs, le démon de cache d’objets redémarrait sous pression mémoire, provoquant des tempêtes de requêtes lors du rewarm du cache.

L’équipe a d’abord tenté d’« optimiser encore » : augmenter les TTL, ajouter des exclusions, redémarrer les services plus fréquemment. Ça a empiré, parce que chaque redémarrage amplifiait le thundering herd de requêtes non mises en cache frappant PHP et la DB.

La solution fut embarrassante mais simple : désactiver temporairement le plugin de cache, stabiliser, puis réintroduire le cache avec des réglages conservateurs et une observabilité réelle. Le travail de performance sans mesure n’est que de la superstition en costume.

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

Une entreprise du secteur financier utilisait WordPress en conteneurs. Ce n’était pas sophistiqué, juste discipliné : déploiements immuables, mises à jour de plugins effectuées d’abord en staging, et production modifiée uniquement via une pipeline. Ils conservaient aussi des sauvegardes nocturnes et des snapshots filesystem de courte rétention.

Un matin, une mise à jour de plugin a passé staging mais a quand même cassé la production — parce que la production avait une version mineure PHP différente à cause d’un pin de base image oublié. Le plugin utilisait une fonctionnalité PHP absente en prod. Erreur fatale immédiate.

Au lieu de déboguer en production, ils ont exécuté le runbook pratiqué : rollback de l’image conteneur à la version précédente connue bonne, restauration du service, puis comparaison des versions PHP et des exigences du plugin dans un état calme. L’impact business a été minimisé parce que le rollback n’a pas été un acte héroïque ; c’était un mardi.

La correction long terme : aligner les images staging/prod, et ajouter une vérification pipeline qui assure la parité des versions PHP. La pratique ennuyeuse — environnements cohérents et rollback répété — a fait le vrai travail.

Faits et contexte historique (court, utile, un peu lucide)

Fait 1 : WordPress a commencé en 2003 comme fork de b2/cafelog, et son architecture de plugins a grandi avec l’écosystème — puissante, mais non sandboxée.
Fait 2 : Les plugins exécutent du PHP en processus ; il n’y a pas de frontière d’isolation comme le modèle des extensions navigateur. Un plugin peut casser le noyau avec une seule erreur fatale.
Fait 3 : Le « White Screen of Death » est devenu un mème WordPress parce que les fatales PHP produisaient souvent une sortie vide quand l’affichage des erreurs était désactivé.
Fait 4 : Les mises à jour automatiques en arrière-plan pour les releases de sécurité ont été introduites pour réduire le délai de patch, mais elles ont aussi augmenté la probabilité de changements non surveillés qui interagissent mal avec des plugins.
Fait 5 : Le fichier .maintenance existe spécifiquement pour prévenir des états incohérents durant les mises à jour, mais il peut vous bloquer si la mise à jour plante.
Fait 6 : Beaucoup d’incidents après « mises à jour de plugins » résultent en réalité d’extractions partielles dues à un espace disque faible ou à des problèmes de permissions, laissant des classes PHP manquantes.
Fait 7 : PHP 7.4 a atteint la fin de son cycle en 2022, et les plugins ont progressivement relevé leurs exigences minimales, transformant les anciennes piles d’hébergement en bombes à retardement.
Fait 8 : WordPress stocke les « plugins actifs » dans la base de données, mais vérifie toujours l’existence des fichiers sur le disque, d’où la fiabilité du renommage de dossier comme frein d’urgence.
Fait 9 : Un tueur de performance surprenant est une option autoloadée gonflée : elle se charge sur de nombreuses requêtes et pénalise tout également.

Listes de contrôle / plan étape par étape

Checklist 1: “Le site est en panne maintenant” (stabiliser d’abord)

Capturer le symptôme : statut HTTP (200/500/502/503), message de maintenance, écran blanc, wp-admin accessible ou non.
Vérifier les logs : log d’erreur du serveur web et log PHP-FPM pour une ligne fatale pointant vers un fichier de plugin.
Désactiver le plugin probable : renommer son dossier sous wp-content/plugins.
Si incertain, désactiver tous les plugins : renommer plugins en plugins.disabled et créer un répertoire plugins vide.
Supprimer le mode maintenance coincé : supprimer .maintenance si présent.
Vérifier avec curl : confirmer HTTP 200 et du HTML basique depuis l’origine.
Confirmer la connexion wp-admin : si l’admin fonctionne, votre tâche suivante est une restauration contrôlée.

Checklist 2: Restauration contrôlée (ne pas re-casser)

Réactiver les plugins un par un : déplacer un dossier de plugin ou activer via WP-CLI, puis tester et vérifier les logs.
Surveiller les échecs cachés : tester un endpoint dynamique (checkout, formulaire de contact, recherche) et pas seulement la page d’accueil.
Vider les caches délibérément : cache de page, cache d’objets, cache CDN (dans cet ordre). Confirmez d’abord que l’origine est correcte.
Verrouiller les mises à jour automatiques temporairement : empêcher le système de réintroduire la mauvaise version.
Conserver les preuves : conservez la trace de la stack d’erreur fatale et la version du plugin ; vous en aurez besoin pour un rollback ou le support éditeur.

Checklist 3: Prévention (transformer la douleur en processus)

Maintenir staging aligné avec production : même version PHP, mêmes extensions, même pile de cache.
Sauvegardes restaurables : base de données + uploads + code plugin/thème, restaurations testées, et pas seulement « on a des backups ».
Contrôle des changements pour les plugins : planifier les mises à jour, enregistrer les versions, et éviter de « tout auto-mettre à jour » sauf si vous avez une vraie capacité de rollback.
Observabilité : centraliser les logs, garder les logs d’erreur lisibles, et alerter sur les pics de 5xx et les fatales PHP.

Blague #2 : Le moyen le plus rapide d’apprendre les internals de WordPress, c’est un incident de plugin. Le deuxième plus rapide, c’est de lire ceci avant l’incident.

FAQ

1) Si je renomme un dossier de plugin, vais-je perdre ses paramètres ?

Généralement non. La plupart des paramètres de plugin résident dans la base de données. Renommer empêche seulement le code de se charger. Mais certains plugins exécutent des routines de désinstallation lors de la désactivation ; le renommage évite cela, ce qui est souvent plus sûr pendant la récupération.

2) Et si wp-admin est aussi en panne et que je ne peux pas me connecter ?

C’est normal avec des fatales de plugin car WordPress ne peut pas booter. Utilisez la désactivation au niveau du système de fichiers (renommer le dossier du plugin ou le répertoire plugins) ou WP-CLI si celui-ci peut booter.

3) Dois-je supprimer le dossier du plugin ?

Non, renommez-le. La suppression détruit des preuves et complique le rollback. Le renommage est réversible et rapide.

4) Puis-je désactiver un plugin directement depuis la base de données ?

Vous pouvez, en éditant l’option active_plugins, mais c’est un outil tranchant. Si vous êtes déjà en SSH, le renommage de dossier est plus sûr et plus rapide sous tension. N’utilisez les modifications DB que si vous comprenez les tableaux PHP sérialisés et si vous avez une sauvegarde.

5) Pourquoi désactiver tous les plugins ne résout parfois pas le site ?

Parce que le plugin n’était pas la seule défaillance. Coupables fréquents : .maintenance coincé, PHP-FPM arrêté, disque plein, problèmes de connexion DB, ou fatales au niveau du thème. La désactivation des plugins est un test, pas une religion.

6) J’ai désactivé le plugin mais le site affiche toujours la page d’erreur. Et maintenant ?

Vérifiez si vous voyez des réponses d’erreur mises en cache (CDN/cache de page). Vérifiez localement depuis l’origine avec curl. Puis videz les caches. Confirmez aussi que vous avez modifié le bon nœud dans un déploiement load-balanced.

7) Comment déterminer quel plugin a causé le problème si je ne sais pas ?

Trier les dossiers de plugins par date de modification (Task 2), puis tailer les logs pour la stack trace fatale (Task 6). Si vous ne pouvez toujours pas déterminer, désactivez tous les plugins et réactivez-les un par un jusqu’à ce que le problème réapparaisse.

8) WP-CLI est-il toujours sûr à utiliser pendant un incident ?

C’est sûr si vous l’exécutez en tant qu’utilisateur correct et s’il peut booter WordPress. Si la fatale survient avant le chargement de WP, WP-CLI peut aussi échouer. Gardez la méthode de renommage de dossier comme solution de secours sans dépendances.

9) Quelle est la différence entre un 500 et un 502 dans ce contexte ?

500 signifie souvent que le serveur web a renvoyé une erreur interne (ou que PHP a émis une fatale et que le serveur l’a mappée). 502 signifie souvent que le proxy inverse n’a pas obtenu de réponse valide de PHP-FPM en amont (plantage, timeout, bad gateway). En pratique : les deux vous renvoient aux logs.

10) Dois-je augmenter la limite mémoire PHP pour corriger le problème ?

Seulement si les logs montrent une épuisement mémoire, et seulement comme stabilisateur temporaire. Si une mise à jour de plugin nécessite soudainement 2× la mémoire, vous payez le bug de quelqu’un d’autre avec votre budget serveur.

Conclusion : étapes suivantes pour éviter la répétition

Pour récupérer rapidement : désactivez le plugin en renommant son dossier (ou tout le répertoire plugins), supprimez un fichier .maintenance coincé, vérifiez avec curl, et lisez les logs jusqu’à ce que la ligne fatale ait du sens. Puis réactivez les plugins un par un, avec les logs ouverts, pas à l’intuition.

Étapes suivantes qui ont vraiment un impact :

Arrêtez la roulette des plugins non surveillés : planifiez les mises à jour et exigez un plan de rollback.
Alignez staging et production : la parité de version PHP évite le mensonge « ça marchait en staging ».
Améliorez votre observabilité : logs centralisés et alertes 5xx transforment les pannes mystérieuses en incidents courts.
Exercez le rollback : le meilleur moment pour apprendre les procédures de restauration n’est pas pendant un incident qui impacte le chiffre d’affaires.