L’éditeur WordPress plante : conflits de plugins et comment identifier le responsable

janvier 31, 2026 • février 3, 2026 • Lecture : 28 min • Views: 12

Cet article vous a aidé ?

Si votre éditeur WordPress plante, se recharge, devient blanc ou reste bloqué sur un spinner, ce n’est pas « un mauvais jour pour le navigateur ». Vous avez devant vous une chaîne de défaillances : erreur JavaScript → requête REST échoue → autosave meurt → l’éditeur abandonne. Ou des fatales PHP en coulisse. Ou un plugin qui se dispute avec un autre plugin avec la subtilité de deux tout-petits dans une salle serveur.

La bonne nouvelle : la plupart des « plantages » de l’éditeur sont diagnostiquables en moins d’une heure si vous agissez comme un opérateur. Reproduisez. Isolez. Lisez les logs. Changez une seule variable à la fois. Puis pointez le coupable avec une preuve, pas des impressions.

Playbook de diagnostic rapide

Version « j’ai cinq minutes et un stakeholder qui me regarde partager mon écran ». L’objectif n’est pas de tout réparer. L’objectif est de localiser la couche en échec : JS côté navigateur, REST/AJAX WordPress, PHP, base de données ou infrastructure.

Première étape : déterminer si c’est du JavaScript côté client ou du PHP côté serveur

Ouvrez les DevTools du navigateur → Console. Si vous voyez des erreurs en rouge (TypeError, « Cannot read properties », scripts bloqués, CORS), vous êtes en territoire JS.
Ouvrez DevTools → Network et rechargez l’éditeur. Filtrez sur wp-json et admin-ajax.php. Si ces appels retournent 401/403/500 ou expirent, vous êtes en territoire API/PHP.

Deuxième étape : reproduire dans une session propre

Fenêtre incognito/private (sans extensions, cookies propres). Si ça fonctionne là, vous avez un souci d’auth/session mise en cache, une extension de navigateur qui casse le JS d’admin, ou un cache edge trop agressif.
Basculez temporairement vers un thème par défaut. Les thèmes peuvent et font parfois empirer les écrans d’administration via des scripts globaux.

Troisième étape : isoler les conflits de plugins de manière agressive

Désactivez tous les plugins, confirmez la stabilité de l’éditeur, puis réactivez par lots (recherche binaire). N’activez pas 37 plugins un par un sauf si vous aimez souffrir.
Si la désactivation règle le problème, vous avez un conflit, pas « WordPress qui fait WordPress ». Réduisez l’investigation.

Quatrième étape : consulter les logs avec intention

Log d’erreurs PHP pour les fatales, épuisement de mémoire, fonctions non définies.
Log de debug WordPress pour les warnings/notices corrélés au chargement de l’éditeur.
Logs du serveur web pour les 500, 403, timeouts sur les endpoints REST.

Cinquième étape : confirmer la correction via une reproduction propre

Éditez un article, déclenchez un autosave, insérez un bloc, ouvrez les blocs réutilisables/patterns, publiez.
Surveillez Network et Console pour de nouvelles erreurs. Des correctifs qui « ont l’air de marcher » mais laissent des erreurs dans la console sont de futurs incidents déguisés.

Une idée paraphrasée souvent rattachée à la culture SRE (paraphrase) : L’espoir n’est pas une stratégie ; la fiabilité vient d’un design et d’une vérification délibérés. — souvent associée à la culture opérations et fiabilité.

Ce que « planter l’éditeur » signifie réellement dans WordPress

« Planter » est un mot d’utilisateur. WordPress n’exécute pas un processus unique qui segfault ; c’est une application web. Quand les utilisateurs disent « l’éditeur plante », cela signifie généralement l’un des cas suivants :

Écran blanc (white screen of death) sur la route de l’éditeur parce qu’un fatal PHP s’est produit, ou la sortie est corrompue avant l’envoi des réponses JSON.
L’éditeur de blocs se charge mais devient non réactif à cause d’une exception JavaScript, souvent suite à un plugin injectant des scripts, bloquant des scripts core, ou introduisant des dépendances React conflictuelles.
Spinner de chargement bloqué parce que les appels REST échouent (401/403/500), ou que les requêtes sont bloquées par des règles WAF/CDN.
Échecs d’autosave qui se répercutent en « Mise à jour échouée » et finissent par rendre l’éditeur inutilisable.
L’éditeur charge mais ne peut pas publier à cause d’un problème de permissions, nonce, authentification REST ou filtres de contenu qui renvoient des réponses invalides.

Les conflits de plugins sont courants parce que les plugins peuvent modifier le comportement de l’admin via des hooks, enqueuer des scripts, enregistrer des blocks, filtrer les réponses REST et modifier le traitement du contenu. Ce pouvoir est le produit. C’est aussi le risque.

Petite blague #1 : Les plugins sont comme des collègues en open space — individuellement corrects, collectivement bruyants, et l’un d’eux touche toujours à vos réglages.

Faits et contexte historique (pourquoi ça revient)

Un peu de contexte utile vous aide à déboguer plus vite, parce qu’il vous indique où sont les coutures.

Gutenberg (l’éditeur de blocs) est devenu le défaut dans WordPress 5.0 (2018). C’était un changement tectonique : une application React dans l’admin, fortement dépendante des endpoints REST et du bundling JS moderne.
L’éditeur de blocs s’appuie sur l’API REST pour les workflows core. Un plugin qui casse les réponses REST (sortie additionnelle, mauvais headers, changements d’auth) peut « planter » l’édition sans toucher au code de l’éditeur.
Les pages d’administration WordPress ne sont pas « immunisées » contre les scripts front-end. Thèmes et plugins peuvent enqueuer des scripts globalement ; une logique d’enqueue bâclée peut polluer wp-admin.
Beaucoup de constructeurs de pages et bibliothèques de blocs livrent leurs propres bundles JS. S’ils packagent des versions incompatibles de paquets liés à React ou supposent des globals, l’éditeur devient un champ d’horreur.
Autosave et révisions ne sont pas de simples options. L’autosave est un flux REST/AJAX ; quand il échoue, la confiance de l’utilisateur s’effondre rapidement car il craint de perdre son contenu.
Les plugins de sécurité et WAF inspectent de plus en plus les appels REST d’admin. Les faux positifs sont fréquents, surtout pour des payloads JSON contenant du HTML, des shortcodes ou des chaînes « suspectes ».
Les limites de mémoire PHP restent une contrainte pratique. L’éditeur peut déclencher du parsing de blocs complexe, du traitement d’images, de l’analyse SEO et le rendu de champs personnalisés — le tout simultanément.
Le cache d’objets peut modifier le comportement des plugins. Certains plugins gèrent mal les vérifications de capacités mises en cache, la validation des nonces REST ou des flags d’éditeur basés sur des transients.
WP-CLI est devenu la méthode sérieuse pour gérer les plugins à grande échelle. C’est plus rapide, scriptable, et fonctionne quand wp-admin est cassé.

Modes de défaillance courants : où apparaissent les conflits

1) Collisions JavaScript dans wp-admin

L’éditeur de blocs est une application JS. Une seule erreur non interceptée peut stopper le rendu ou casser des flux cruciaux comme l’insertion de blocs. Causes courantes :

Un plugin enqueue des scripts sur toutes les pages d’admin (au lieu de seulement ses écrans) et introduit un conflit de dépendances.
Un plugin ajoute un script qui suppose des globals jQuery dans des contextes où ils ne sont pas chargés (ou charge une vieille version de jQuery).
Les plugins « d’optimisation » concatènent/minifient les scripts d’admin et réordonnent accidentellement les dépendances.

2) API REST et casse des nonce/auth

Les actions de l’éditeur appellent des endpoints comme /wp-json/wp/v2/posts/<id>. Si ces appels échouent, vous verrez « The response is not a valid JSON response », « Updating failed » ou un spinner qui ne s’arrête jamais.

Causes courantes :

Plugin de sécurité bloque ou réécrit des routes REST.
WAF/CDN bloque les POST avec corps JSON ou supprime des headers.
Un plugin émet des espaces blancs/warnings/HTML avant le JSON, rendant la réponse invalide.

3) Fatales PHP et épuisement mémoire

Les utilisateurs perçoivent cela comme un écran blanc, « The site is experiencing technical difficulties » ou des parties de l’UI de l’éditeur qui ne se chargent pas. Dans les logs, on voit souvent :

Allowed memory size exhausted
Fatal error: Uncaught Error provenant d’un plugin qui attend une classe/fonction manquante
Erreurs de type après une mise à jour PHP

4) Base de données et stockage (oui, le stockage)

Les « plantages » de l’éditeur peuvent être des timeouts. Si l’enregistrement d’un article déclenche des requêtes lentes, des verrous de tables ou un stockage saturé, l’éditeur devient peu fiable. L’autosave est particulièrement sensible car il s’exécute fréquemment et les utilisateurs remarquent chaque accroc.

5) CDN, mise en cache et l’illusion de « l’aide »

L’admin ne devrait généralement pas être mis en cache en edge. Mais des erreurs de configuration arrivent : réponses REST en cache, pages connectées mises en cache, ou bundles JS obsolètes. L’éditeur charge des assets incompatibles et plante.

Petite blague #2 : Rien ne dit « optimisation des performances » comme mettre en cache le tableau de bord admin puis passer l’après-midi à expliquer pourquoi la réalité est incohérente.

Tâches pratiques avec commandes : isoler, confirmer, décider

Ces tâches partent du principe que vous avez un accès SSH et une pile d’hébergement Linux standard. Si vous êtes sur un hébergement managé sans shell, adaptez la logique : les points de décision restent les mêmes.

Règles d’engagement : changez une variable à la fois, capturez des preuves (extraits de logs, codes HTTP, horodatages), et arrêtez de deviner. Deviner, c’est créer deux incidents au lieu d’un.

Tâche 1 : Confirmer l’inventaire WordPress et des plugins

cr0x@server:~$ cd /var/www/example.com/htdocs && wp core version && wp plugin list --status=active
6.6.2
+-------------------------+----------+-----------+---------+
| name                    | status   | update    | version |
+-------------------------+----------+-----------+---------+
| wordfence               | active   | none      | 7.11.6  |
| wp-rocket               | active   | available | 3.16.1  |
| advanced-custom-fields  | active   | none      | 6.3.6   |
| custom-block-library    | active   | none      | 2.4.0   |
+-------------------------+----------+-----------+---------+

Ce que cela signifie : vous connaissez maintenant les pièces en mouvement et si « nous n’avons rien changé » est une fiction.

Décision : s’il y a une mise à jour disponible pour un plugin de cache/optimisation/sécurité, considérez-le comme suspect (pas nécessairement la cause, mais suspect).

Tâche 2 : Reproduire avec les plugins désactivés (levier d’isolation le plus rapide)

cr0x@server:~$ cd /var/www/example.com/htdocs && wp plugin deactivate --all
Deactivated 'wordfence' plugin.
Deactivated 'wp-rocket' plugin.
Deactivated 'advanced-custom-fields' plugin.
Deactivated 'custom-block-library' plugin.
Success: Deactivated 4 of 4 plugins.

Ce que cela signifie : vous avez supprimé la majeure partie du comportement tiers. Si l’éditeur plante encore, le problème est probablement le thème, le core, PHP ou l’infrastructure.

Décision : testez l’éditeur maintenant. Si stable, le plantage est lié aux plugins ; procédez à une réactivation contrôlée.

Tâche 3 : Réactiver les plugins en utilisant une recherche binaire

cr0x@server:~$ cd /var/www/example.com/htdocs && wp plugin activate advanced-custom-fields custom-block-library
Plugin 'advanced-custom-fields' activated.
Plugin 'custom-block-library' activated.
Success: Activated 2 of 2 plugins.

Ce que cela signifie : vous réduisez l’ensemble suspect. Testez l’éditeur. Si ça casse, le coupable est dans cet ensemble.

Décision : si cassé, désactivez l’un des deux puis retestez pour identifier le plugin précis.

Tâche 4 : Basculer vers un thème par défaut (les thèmes peuvent aussi empoisonner l’admin)

cr0x@server:~$ cd /var/www/example.com/htdocs && wp theme list --status=active && wp theme activate twentytwentyfour
+-----------+--------+-----------+---------+
| name      | status | update    | version |
+-----------+--------+-----------+---------+
| corp-theme| active | none      | 1.9.3   |
+-----------+--------+-----------+---------+
Success: Switched to 'Twenty Twenty-Four' theme.

Ce que cela signifie : vous avez supprimé la logique d’enqueue au niveau du thème, les styles d’éditeur personnalisés et les effets secondaires de functions.php.

Décision : si l’éditeur devient stable uniquement avec un thème par défaut, votre « conflit de plugins » pourrait en réalité être du code thème ou une interaction thème-plugin.

Tâche 5 : Activer le debug WordPress sans inonder l’écran

cr0x@server:~$ cd /var/www/example.com/htdocs && wp config set WP_DEBUG true --raw && wp config set WP_DEBUG_LOG true --raw && wp config set WP_DEBUG_DISPLAY false --raw
Success: Updated the constant 'WP_DEBUG' in the 'wp-config.php' file with the raw value 'true'.
Success: Updated the constant 'WP_DEBUG_LOG' in the 'wp-config.php' file with the raw value 'true'.
Success: Updated the constant 'WP_DEBUG_DISPLAY' in the 'wp-config.php' file with the raw value 'false'.

Ce que cela signifie : les erreurs iront dans wp-content/debug.log au lieu d’altérer les réponses JSON en imprimant des warnings dedans.

Décision : reproduisez le plantage une fois, puis inspectez le log immédiatement.

Tâche 6 : Inspecter le log de debug WordPress pour l’horodatage exact

cr0x@server:~$ cd /var/www/example.com/htdocs && tail -n 60 wp-content/debug.log
[27-Dec-2025 14:18:02 UTC] PHP Warning:  Cannot modify header information - headers already sent by (output started at /var/www/example.com/htdocs/wp-content/plugins/custom-block-library/includes/debug.php:12) in /var/www/example.com/htdocs/wp-includes/rest-api/class-wp-rest-server.php on line 1898
[27-Dec-2025 14:18:02 UTC] PHP Notice:  Trying to access array offset on value of type null in /var/www/example.com/htdocs/wp-content/plugins/custom-block-library/includes/rest.php on line 77

Ce que cela signifie : ce « headers already sent » est un tueur classique de l’éditeur parce que les réponses REST doivent être du JSON propre avec des en-têtes corrects. Un plugin a affiché de la sortie trop tôt.

Décision : désactivez ce plugin immédiatement ou corrigez la sortie. N’augmentez pas la mémoire en espérant que ça disparaisse.

Tâche 7 : Vérifier les logs PHP-FPM et serveur web pour les fatales et timeouts

cr0x@server:~$ sudo tail -n 80 /var/log/php8.2-fpm.log
[27-Dec-2025 14:18:02] WARNING: [pool www] child 18422 said into stderr: "PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /var/www/example.com/htdocs/wp-content/plugins/advanced-custom-fields/pro/fields/class-acf-field-flexible-content.php on line 312"

Ce que cela signifie : l’éditeur a atteint une limite de mémoire lors d’un chemin de rendu/enregistrement. Cela peut se présenter comme un spinner bloqué ou une erreur générique.

Décision : augmentez la mémoire de manière responsable (et mesurez), ou réduisez le comportement gourmand en mémoire (config ACF, patterns de blocs, meta boxes lourdes). Vérifiez aussi qu’il n’y a pas de fuite/régression après des mises à jour.

Tâche 8 : Valider la santé de l’API REST côté serveur (contourner le bruit du navigateur)

cr0x@server:~$ curl -s -D - https://example.com/wp-json/ -o /dev/null | head
HTTP/2 200
content-type: application/json; charset=UTF-8
x-robots-tag: noindex

Ce que cela signifie : l’endpoint index REST répond en JSON avec un 200. Le routage de base est vivant.

Décision : si vous voyez 403/503 ou content-type HTML, suspectez des règles WAF, des pages de maintenance, ou une corruption de sortie PHP.

Tâche 9 : Vérifier si admin-ajax retourne des erreurs (commun pour Classic Editor)

cr0x@server:~$ curl -s -D - -X POST https://example.com/wp-admin/admin-ajax.php -d 'action=heartbeat' -o /dev/null | head
HTTP/2 200
content-type: text/html; charset=UTF-8

Ce que cela signifie : heartbeat répond. Pour plus de détail, il faudrait des cookies d’auth, mais un 500 ici serait un gros signal d’alerte.

Décision : si c’est 500, allez directement aux logs PHP ; si c’est 403, suspectez sécurité/WAF/modifications de capacités.

Tâche 10 : Trouver les requêtes lentes et endpoints défaillants dans les access logs

cr0x@server:~$ sudo awk '$9 ~ /500|502|503|504/ {print $4, $5, $7, $9}' /var/log/nginx/access.log | tail -n 20
[27/Dec/2025:14:18:02 +0000] "/wp-json/wp/v2/posts/219?context=edit" 500
[27/Dec/2025:14:18:03 +0000] "/wp-admin/post.php?post=219&action=edit" 200

Ce que cela signifie : la page de l’éditeur se charge (200), mais l’appel REST pour récupérer les données du post échoue (500). Voilà pourquoi l’UI « plante ».

Décision : déboguez l’échec de la route REST en PHP (plugins, filtres thème, sortie), pas la page HTML.

Tâche 11 : Vérifier la pression cron/heartbeat WordPress (parfois ce n’est pas un plantage, c’est la charge)

cr0x@server:~$ cd /var/www/example.com/htdocs && wp cron event list --due-now | head
+---------------------+-------------------+------------+---------------------+
| hook                | next_run_gmt      | recurrence | args                |
+---------------------+-------------------+------------+---------------------+
| wp_version_check    | 2025-12-27 14:20  | twice_daily| []                  |
| wordfence_daily_cron| 2025-12-27 14:20  | daily      | []                  |
+---------------------+-------------------+------------+---------------------+

Ce que cela signifie : des tâches cron sont dues et peuvent se chevaucher avec des sessions d’édition, augmentant la charge et la latence.

Décision : si les éditions échouent à des heures spécifiques, mettez-les en corrélation avec des fenêtres de cron chargées ; envisagez de planifier différemment et de limiter les scans lourds.

Tâche 12 : Inspecter la configuration PHP pour limites mémoire et exécution

cr0x@server:~$ php -i | egrep 'memory_limit|max_execution_time|max_input_vars' | head -n 20
memory_limit => 256M => 256M
max_execution_time => 30 => 30
max_input_vars => 1000 => 1000

Ce que cela signifie : 256M peut ou non suffire selon la pile de plugins ; max_input_vars=1000 peut casser les formulaires de meta box volumineux.

Décision : si vous voyez des fatales mémoire, augmentez memory_limit (et les réglages PHP-FPM) de manière contrôlée ; si l’enregistrement de grands formulaires échoue, augmentez max_input_vars et retestez.

Tâche 13 : Repérer si un plugin d’optimisation altère les assets d’admin

cr0x@server:~$ cd /var/www/example.com/htdocs && wp option get wp_rocket_settings | head
a:5:{s:9:"minify_js";i:1;s:15:"combine_js";i:1;s:12:"exclude_js";a:0:{}s:17:"cache_logged_user";i:1;s:17:"cache_ssl";i:1;}

Ce que cela signifie : les réglages indiquent minification/combinaison JS et mise en cache des utilisateurs connectés activées. C’est une combinaison à haut risque pour la stabilité de wp-admin/éditeur.

Décision : désactivez la minification/combinaison pour les routes admin/éditeur, et ne mettez pas en cache les sessions connectées au niveau page.

Tâche 14 : Confirmer que vous ne servez pas des assets mixtes ou obsolètes après un déploiement

cr0x@server:~$ cd /var/www/example.com/htdocs && wp core verify-checksums
Success: WordPress installation verifies against checksums.

Ce que cela signifie : les fichiers core sont intacts. Si l’éditeur casse toujours, concentrez-vous sur les plugins/thèmes/mu-plugins et les couches de cache.

Décision : si les checksums échouent, arrêtez tout. Corrigez d’abord l’intégrité du système de fichiers ; déboguer des conflits de plugins sur un core corrompu, c’est comme régler un moteur avec du sable dedans.

Tâche 15 : Vérifier les must-use plugins et drop-ins (les influenceurs cachés)

cr0x@server:~$ cd /var/www/example.com/htdocs && wp plugin list --status=must-use && ls -1 wp-content | egrep 'mu-plugins|object-cache.php|advanced-cache.php'
+-------------------+----------+--------+---------+
| name              | status   | update | version |
+-------------------+----------+--------+---------+
| platform-mu-stack | must-use | none   | 1.4.2   |
+-------------------+----------+--------+---------+
advanced-cache.php
mu-plugins
object-cache.php

Ce que cela signifie : les MU plugins et drop-ins peuvent altérer REST, cache, auth et logging. Ils sont souvent la vraie source d’un « on a tout désactivé et ça casse encore ».

Décision : inspectez le code des MU plugins et des drop-ins de cache si le basculement normal des plugins ne change pas le comportement.

Tâche 16 : Vérifier la santé du stockage et du système de fichiers quand les sauvegardes expirent

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (web01) 	12/27/2025 	_x86_64_	(4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.31    0.00    4.15    9.72    0.00   73.82

Device            r/s     rkB/s   rrqm/s  %rrqm   r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm   w_await wareq-sz  aqu-sz  %util
nvme0n1          8.00    512.00     0.00   0.00    3.20    64.00   110.00   4096.00    18.00  14.06   45.10    37.24    5.12  92.00

Ce que cela signifie : un %util élevé et un w_await élevé suggèrent une contention d’écriture sur le stockage. Les sauvegardes et autosaves sont des écritures.

Décision : si les sauvegardes d’éditeur corrèlent avec une latence d’écriture élevée, investiguez l’I/O base de données, les requêtes lentes, les jobs de sauvegarde ou les voisins bruyants. Ne blâmez pas le JavaScript pour ce qui est essentiellement un problème de file disque.

Trois micro-récits d’entreprise issus du terrain

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

L’entreprise déployait un workflow éditorial rafraîchi. Nouveaux blocks, quelques types de contenu personnalisés, et un « petit » plugin ajoutant un panneau latéral pour des métadonnées de conformité. L’éditeur a commencé à planter sur un seul site du réseau multisite. Bien sûr, tout le monde a supposé que c’était « lié au contenu » parce que ça arrivait sur des posts avec beaucoup d’embeds.

Ils ont passé une demi-journée à extraire les « mauvais posts », retirer le HTML, enlever les embeds et tester différents navigateurs. Rien n’était cohérent. Le plantage apparaissait de façon aléatoire : parfois au chargement, parfois en insérant un bloc, parfois seulement après quelques minutes. Le classique incident où l’équipe commence à blâmer l’utilisateur, parce que blâmer l’utilisateur est émotionnellement rassurant.

La mauvaise hypothèse : « Si c’était un plugin, ça casserait partout. » En réalité, le plugin avait un réglage par site activant la sortie debug en production. Il imprimait une seule ligne de texte avant les réponses REST. Pas assez pour apparaître sur la page, suffisamment pour corrompre le JSON.

Une fois qu’ils ont suivi le log de debug et les access logs du web serveur côte à côte, c’était évident : chaque plantage de l’éditeur correspondait à un REST 500 et à un warning « headers already sent » pointant vers le plugin de conformité. Désactivez le plugin pour ce site, l’éditeur redevient instantanément stable. Ensuite corriger le plugin pour qu’il n’echo/print jamais en production, et livrer une migration de config qui retire le flag debug.

Enseignement : ne jamais supposer la portée en se basant sur « c’est un plugin ». Un plugin peut se comporter différemment selon le site, le rôle, le type de contenu et l’environnement. Les preuves battent les hypothèses. À chaque fois.

Micro-récit 2 : L’optimisation qui a mal tourné

Une équipe marketing a demandé « un admin plus rapide » parce que les rédacteurs se plaignaient de lenteur. Quelqu’un a activé une concaténation et minification agressive des scripts — sur tout, y compris les utilisateurs connectés — parce que les chiffres du tableau de bord de perf semblaient meilleurs quand on mesurait la page d’accueil et qu’on faisait comme si l’éditeur n’existait pas.

Une semaine, tout semblait aller. Puis l’éditeur a commencé à lancer des erreurs JavaScript intermittentes. Pas toujours la même. Parfois les blocs ne s’inséraient pas. Parfois la bibliothèque média ne s’ouvrait pas. Publier devenait aléatoire. Les tickets de support arrivaient à un rythme prévisible : assez pour être pénible, pas assez pour forcer un rollback complet.

Le coupable n’était pas la « minification » en soi. C’était l’ordre des dépendances et la staleness du cache. Le plugin d’optimisation produisait un bundle admin combiné qui servait parfois une version obsolète après une mise à jour d’un plugin, tandis qu’un autre plugin attendait la build plus récente. L’éditeur chargeait des paquets désynchronisés et plantait en cours de rendu.

La correction fut ennuyeuse et immédiate : arrêter d’optimiser wp-admin comme s’il s’agissait d’une page marketing publique. Exclure les routes admin/éditeur de la combinaison/minification, et ne plus mettre en cache les réponses des utilisateurs connectés au niveau page. Après cela, ils ont pu optimiser le front-end en sécurité — là où l’invalidation de cache est prévisible et l’impact d’un échec plus faible.

Enseignement : le travail de performance qui ignore les modes de défaillance n’est que de l’ingénierie d’incidents sous un plus joli nom. Optimisez le front-end ; gardez l’admin déterministe.

Micro-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la journée

Un grand portail d’actualité interne avait une politique stricte de changements pour les mises à jour WordPress : les mises à jour de plugins étaient groupées, déployées en staging et testées avec un script court mais constant : ouvrir l’éditeur, insérer des blocs, uploader un média, autosave, publier et vérifier les révisions. Pas d’héroïsme, juste de la répétition.

Un matin, un rédacteur signale que l’éditeur de blocs reste bloqué au chargement. L’ingénieur on-call n’a pas paniqué ni commencé à toggler des réglages au hasard. Il a vérifié les notes du dernier déploiement, vu une mise à jour d’un plugin de sécurité, et suivi le playbook établi : reproduire, vérifier les appels REST, lire les logs et comparer avec la staging.

La staging était OK. La production non. Cette différence comptait. Ils ont inspecté les logs WAF et trouvé une règle nouvellement activée qui bloquait les POST REST contenant certains motifs HTML. La mise à jour du plugin de sécurité était une coïncidence — tentante, mais fausse. La pratique ennuyeuse de « noter ce qui a changé » a empêché un rollback inutile.

Ils ont ajusté la règle WAF pour le trafic authentifié wp-admin et confirmé la récupération de l’éditeur. Le postmortem fut court, peu glamour et utile. La politique de changement n’a pas empêché l’incident, mais elle a empêché l’équipe de blâmer le mauvais composant et de perdre une journée.

Enseignement : le suivi discipliné des changements et un script de test répétable ne sont pas de la bureaucratie. C’est ce qui limite la taille des incidents.

Erreurs courantes : symptôme → cause racine → correction

Ce sont des schémas que je vois souvent. Ils font perdre du temps parce que les symptômes induisent en erreur.

1) « The response is not a valid JSON response » lors de la mise à jour

Symptôme : l’éditeur affiche une erreur JSON ; Network montre que l’appel REST retourne du HTML ou des caractères supplémentaires.
Cause racine : plugin/thème émet warnings/notices/echo avant le JSON ; ou une couche de sécurité injecte une page de challenge.
Correction : définir WP_DEBUG_DISPLAY false ; désactiver le plugin fautif ; vérifier les logs pour « headers already sent » ; mettre les routes REST en liste blanche dans le WAF pour les utilisateurs authentifiés.

2) Écran blanc ou « critical error » uniquement sur les pages d’éditeur

Symptôme : wp-admin se charge mais la route éditeur est blanche.
Cause racine : fatal PHP dans une meta box, un renderer de champ personnalisé ou l’enregistrement d’un block ; souvent déclenché seulement en éditant un type de post spécifique.
Correction : tail des logs PHP-FPM, identifier le fichier/ligne fatale, désactiver le plugin, et vérifier la compatibilité avec la version de PHP.

3) L’éditeur charge mais devient non réactif après avoir cliqué sur « Add block »

Symptôme : l’UI se fige ; la Console montre un TypeError dans un script de plugin.
Cause racine : un plugin injecte du JS d’administration globalement, en conflit avec les packages Gutenberg ou supposant des globals.
Correction : désactiver le plugin suspect ; si vous le maintenez, corriger les conditions d’enqueue et les dépendances ; éviter de packager des versions conflictuelles des paquets Gutenberg.

4) Autosave failed, puis tout semble cassé

Symptôme : indicateur d’autosave échoue ; parfois « Publishing failed ».
Cause racine : appels REST bloqués (403), mismatch de nonce dû au cache, ou timeouts provoqués par une DB/stockage lent.
Correction : assurer que les réponses admin/rest ne sont pas mises en cache ; vérifier les codes d’état REST ; investiguer la latence I/O et les requêtes lentes.

5) Marche pour les admins, échoue pour editors/authors

Symptôme : plantages spécifiques aux rôles ou panneaux manquants.
Cause racine : vérifications de capacités mises en cache incorrectement ; plugin restreint des routes REST selon les rôles ; modifications de rôles personnalisées en conflit avec les attentes des plugins.
Correction : tester avec le même rôle ; auditer les plugins de rôle/capacité ; vider le cache d’objets ; vérifier les MU plugins affectant l’auth.

6) N’échoue que derrière un CDN / seulement en production

Symptôme : staging OK ; production éditeur plante de façon intermittente.
Cause racine : mise en cache edge des pages connectées, règles WAF, mauvais réglage Brotli/gzip, ou cache d’assets servant des versions désynchronisées.
Correction : bypasser le cache pour /wp-admin/, /wp-json/ quand connecté ; purger les caches après deploy ; vérifier les headers.

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

A. Plan d’isolation discipliné (recommandé)

Capturer précisément les symptômes : quel éditeur (bloc/classique/builder), quel type de post, quel rôle, quel navigateur, quel message d’erreur exact.
Reproduire avec DevTools ouverts : noter les erreurs Console et les appels Network échoués (endpoint + code de statut).
Désactiver tous les plugins : confirmer si la stabilité revient.
Basculez vers un thème par défaut : confirmer l’implication éventuelle du thème.
Réactiver les plugins par lots : recherche binaire jusqu’à identifier l’ensemble coupable, puis le plugin précis.
Confirmer les preuves côté serveur : faire correspondre l’horodatage d’échec aux logs PHP-FPM et serveur web.
Confirmer l’intégrité REST : les réponses REST doivent être du JSON, sans warnings ni injection HTML.
Corriger ou atténuer : mettre à jour le plugin, ajuster la config, exclure l’admin de l’optimisation, augmenter la mémoire, ou patcher le code.
Vérifier la correction via un script de test : charger l’éditeur, insérer des blocs, uploader un média, autosave, publier, rééditer.
Rédiger une courte note d’incident : ce qui a sauté, comment vous l’avez prouvé, ce que vous avez changé et comment le détecter la prochaine fois.

B. Plan de récupération « je ne peux pas me connecter à wp-admin »

SSH sur le serveur et désactivez les plugins avec WP-CLI.
Si WP-CLI n’est pas disponible, renommez le dossier plugins (dernier recours) ou désactivez des dossiers de plugins spécifiques.
Rendez l’éditeur stable d’abord, puis réintroduisez les composants prudemment.

C. Test de fumée répétable pour l’éditeur (à utiliser après chaque changement)

Ouvrir un article existant contenant beaucoup de blocs.
Ajouter un nouveau bloc, le déplacer, annuler/refaire.
Uploader une image, l’insérer, mettre à jour le texte alternatif.
Attendre le déclenchement de l’autosave ; confirmer l’absence d’erreurs.
Publier/mettre à jour ; vérifier que l’article se charge côté front-end.
Rouvrir l’article ; confirmer que les révisions existent et que l’éditeur se charge proprement.

FAQ

1) L’éditeur de blocs est-il plus sujet aux conflits de plugins que l’éditeur Classique ?

Oui, parce que c’est une application JS lourde dépendant du REST. L’éditeur classique est plus basé sur forms/AJAX. Différents modes de défaillance, même cause racine : des plugins qui hookent trop largement.

2) Si désactiver tous les plugins règle le problème, le dernier plugin que j’ai mis à jour est-il forcément le coupable ?

Non. Les mises à jour corrèlent souvent avec des incidents parce qu’elles changent le système, mais le déclencheur réel peut être une couche de cache, une mise à jour PHP ou un autre plugin réagissant à la mise à jour.

3) Pourquoi l’éditeur plante-t-il seulement sur un article ?

Cet article peut déclencher un block spécifique, un shortcode ou un renderer de meta box. Certains plugins chargent du code additionnel seulement quand certains blocks/champs existent, donc un seul article peut être le seul reproducteur.

4) Que signifie en pratique « invalid JSON response » ?

Soit le serveur a renvoyé du HTML (page challenge WAF, page d’erreur PHP) soit il a renvoyé du JSON avec des caractères en trop avant/après (notices PHP, echo isolé). Les consommateurs REST sont stricts ; c’est normal.

5) Les extensions de navigateur peuvent-elles provoquer des plantages de l’éditeur WordPress ?

Oui. Gestionnaires de mots de passe, bloqueurs de pub et extensions « privacy » peuvent bloquer des scripts ou modifier des requêtes. C’est pour ça que tester en incognito/private est un check rapide et utile.

6) Dois-je augmenter memory_limit PHP pour corriger les plantages de l’éditeur ?

Parfois. Si les logs montrent un épuisement de mémoire, augmenter la mémoire peut être une mitigation valable. Mais considérez cela comme du temps acheté : corrigez aussi le comportement plugin/thème consommateur de mémoire.

7) Pourquoi ça marche en staging mais pas en production ?

La production a souvent du cache edge, des règles WAF, un trafic réel, des jobs en arrière-plan et un comportement de cache d’objets différent. La staging est plus calme. Les bugs aiment les environnements calmes car ils peuvent s’y cacher.

8) Comment identifier un conflit quand le plantage est intermittent ?

Instrumentez : loggez des horodatages, capturez les codes d’état Network, et mettez cela en corrélation avec les logs serveur. Les problèmes intermittents s’alignent souvent sur l’expiration de cache, des jobs cron ou des pics de charge.

9) Est-il sûr de désactiver des plugins sur un site en production pour déboguer ?

Ça dépend du plugin. Désactiver brièvement un plugin de sécurité est souvent plus sûr que laisser l’éditeur cassé pendant des heures. Mais faites-le intentionnellement : annoncez-le, limitez la durée et revenez en arrière avec précaution.

10) Et si le coupable est un MU plugin ou un drop-in de cache ?

Alors le basculement normal des plugins ne vous aidera pas. Il faudra inspecter wp-content/mu-plugins, object-cache.php et advanced-cache.php et coordonner avec qui gère la couche plateforme.

Conclusion : prochaines étapes réalisables aujourd’hui

Si votre éditeur WordPress plante, ne le traitez pas comme un problème UI mystique. Traitez-le comme un incident de production avec une zone d’impact visible par les utilisateurs.

Exécutez le diagnostic rapide : Console DevTools + Network, puis isolation des plugins.
Activez la journalisation en sécurité : loggez dans un fichier, pas à l’écran. Protégez les réponses JSON.
Prouvez le coupable : désactivez tous les plugins, réactivez par lots, corrélez avec des lignes de log et des codes HTTP.
Corrigez la classe de problème : excluez wp-admin de l’optimisation, mettez en liste blanche REST pour les utilisateurs authentifiés dans le WAF, et gardez des limites mémoire réalistes.
Institutionnalisez : gardez un court test de fumée de l’éditeur et exécutez-le après chaque mise à jour. L’ennui, c’est bien. L’ennui, c’est la stabilité.