wp-admin de WordPress ne s’ouvre pas : causes réelles et correctifs

Guide de diagnostic rapide

Si vous êtes de garde, ne philosophez pas. Triez. Votre objectif est de répondre rapidement à trois questions :

1. La requête atteint-elle le serveur ? (DNS, CDN/WAF, TLS, vhost, routage)
2. Le serveur web la transmet‑il correctement à PHP ? (configuration Nginx/Apache, santé PHP‑FPM, timeouts)
3. WordPress lui‑même est‑il à genoux ? (erreurs fatales plugins/thèmes, connexion/latence BD, cache objet, permissions système de fichiers)

Vérifier d’abord (30–90 secondes) : edge et code HTTP

• Depuis votre portable : curl -I https://example.com/wp-admin/ et curl -I https://example.com/wp-login.php.
• Regardez les codes de statut : 200/302/401/403/404/500/502/503/504. Ce ne sont pas des décorations ; ce sont votre carte.
• Si vous voyez des boucles 301/302, concentrez‑vous sur la normalisation du schéma/hôte et le domaine des cookies.
• Si vous voyez des 502/504, regardez PHP‑FPM ou les timeouts upstream (ou l’application qui met trop de temps).
• Si vous voyez 403, examinez les règles WAF, l’authentification basique, les permissions des fichiers ou les plugins de sécurité.

Vérifier ensuite (2–5 minutes) : logs ciblés

• Logs d’erreur Nginx/Apache pour l’horodatage exact de votre requête.
• Logs PHP‑FPM et slowlog (si activé) pour détecter les workers bloqués.
• Log de debug WordPress (seulement si vous pouvez l’activer en sécurité) pour les fautes plugins/thèmes.

Vérifier enfin (5–15 minutes) : goulots d’étranglement des ressources

• Saturation CPU, pression mémoire, OOM killer, I/O disque en attente, système de fichiers plein.
• Connectivité base de données et latence des requêtes.
• Disponibilité du cache objet (Redis/Memcached) et timeouts.

Règle empirique : wp-admin est plus « dynamique » que la page d’accueil. Une page d’accueil mise en cache peut sembler OK alors que wp-admin brûle.

Ce que fait réellement wp-admin (et pourquoi ça échoue)

/wp-admin n’est pas une seule page. C’est un ensemble de points d’entrée PHP (notamment wp-admin/admin.php) qui se dispersent rapidement en :

• Contrôles d’authentification (cookies, nonces, rôles utilisateur)
• Requêtes BD en lecture (user meta, options, états de plugins)
• Lectures système de fichiers (plugins, thèmes, traductions)
• Appels HTTP externes (certains plugins appellent des API externes sur les pages admin — oui, vraiment)
• Points d’accès AJAX (admin-ajax.php) qui peuvent se bloquer indépendamment

Donc quand « wp-admin ne s’ouvre pas », vous regardez généralement une de ces catégories :

• Blocage réseau/edge : DNS incorrect, CDN/WAF bloque, incompatibilité TLS, mauvaise origine.
• Bug de routage/config HTTP : règles de réécriture, mauvais vhost, handler PHP mal routé, fastcgi_param cassé.
• Erreur applicative fatale : erreur de syntaxe plugin/thème, fichier manquant, version PHP incompatible.
• Échec de dépendance : BD down/lente, Redis down, blocage NFS/EFS, disque plein, épuisement d’inodes.
• Épuisement de ressources : pool PHP‑FPM saturé, limite mémoire, max execution time, sessions verrouillées.
• Boucle de redirection/auth : discordance site URL, offload HTTPS mal configuré, problèmes de domaine de cookie.

Une citation à afficher au‑dessus de votre écran :

« L’espoir n’est pas une stratégie. » — Gene Kranz

Les pannes de wp-admin récompensent la méthode, pas l’optimisme.

Faits et histoire utiles pour le débogage

• Fait 1 : WordPress a commencé comme un fork de b2/cafelog en 2003, et son système de plugins est devenu un champ de mines de compatibilité — puissant, mais facile à casser avec une mauvaise mise à jour.
• Fait 2 : wp-login.php et /wp-admin/ sont des points d’entrée distincts ; une panne sur l’un n’implique pas toujours l’autre. Vérifiez les deux.
• Fait 3 : WordPress a historiquement supposé des déploiements de type LAMP ; les stacks modernes (Nginx + PHP‑FPM, reverse proxies, conteneurs) exigent des en‑têtes supplémentaires et une conscience du schéma pour éviter les boucles de redirection.
• Fait 4 : La « White Screen of Death » est devenue célèbre parce que les erreurs fatales PHP ne renvoyaient rien au navigateur en configuration production — les logs étaient la seule vérité.
• Fait 5 : Beaucoup de requêtes admin sont non mises en cache et spécifiques à l’utilisateur, donc elles exposent d’abord les problèmes de capacité BD et PHP — votre page d’accueil mise en cache peut rester souriante tandis que le tableau de bord est indisponible.
• Fait 6 : La table options (wp_options) est un point chaud : les options autoloadées sont lues constamment. Une charge autoload trop grosse ralentit chaque page admin.
• Fait 7 : Depuis WordPress 5.2, la « protection contre les erreurs fatales » peut envoyer des e‑mails aux admins et récupérer dans certains cas — mais elle ne vous sauvera pas des problèmes d’infrastructure, ni d’un cache d’opcodes corrompu.
• Fait 8 : L’API REST et les endpoints admin-ajax sont des dommages collatéraux fréquents causés par les règles de sécurité ; un WAF « aidant » peut silencieusement clouer l’UI wp-admin.

Partir des premiers principes : classer la défaillance

1) Atteignez‑vous l’origine du tout ?

Si votre navigateur ne peut pas joindre le site, wp-admin est hors sujet. Vérifiez DNS, CDN et TLS d’abord. Beaucoup de « problèmes WordPress » sont en réalité « le load balancer parle au mauvais pool ».

2) Quel code HTTP obtenez‑vous, de façon cohérente ?

• 301/302 boucle : discordance URL/schéma, en‑têtes proxy inversé, problèmes de cookies, guerres de canonicalisation.
• 403 : WAF, allowlist d’IP, auth basique mal appliquée, permissions fichiers, plugin de sécurité, règles ModSecurity.
• 404 : vhost mal configuré, règles de réécriture, docroot erroné, fichiers WordPress manquants, confusion multisite.
• 500 : fatal PHP, mauvaise config, limite mémoire, plugin/thème cassé, cache d’opcodes défectueux, erreurs de permissions.
• 502/504 : Nginx ne peut pas parler à PHP‑FPM, PHP‑FPM surchargé/figé, timeout upstream, ou l’app attend la BD/le disque.
• 503 : mode maintenance, origine surchargée, déploiement en cours, ou un upstream qui rejette volontairement la charge.

3) Est‑ce seulement wp-admin, ou toutes les pages dynamiques ?

Comparez :

• / (souvent en cache)
• /wp-login.php (moins de code plugin que l’admin complet)
• /wp-admin/ (plus de contrôles, plus de hooks plugin)
• /wp-admin/admin-ajax.php (chemin critique pour les tableaux de bord)

Blague n°1 : Une couche de cache est comme une belle nappe — elle peut cacher le désordre, mais elle ne lave pas la vaisselle.

4) Décidez : config, capacité ou code ?

Toutes vos actions doivent viser à classer l’incident dans un des seaux :

• Config : en‑têtes proxy, terminaison SSL, règles de réécriture, handler PHP, propriété des fichiers, SELinux/AppArmor.
• Capacité : pool PHP‑FPM, connexions BD, IOPS, mémoire, CPU, Redis.
• Code : mise à jour plugin/thème, changement de version PHP, coeur WordPress corrompu, mu‑plugin personnalisé.

Tâches pratiques : commandes, sorties et décisions

Ci‑dessous des tâches éprouvées à exécuter sur un hôte Linux typique. Elles sont écrites pour le réalisme : vous lancez une commande, vous lisez la sortie et vous prenez une décision. Si vous êtes en conteneurs, exécutez l’équivalent dans le pod/conteneur concerné.

Task 1: Reproduce the failure from the server and capture status/redirects

cr0x@server:~$ curl -sS -o /dev/null -D - https://example.com/wp-admin/ | head -n 20
HTTP/2 302
date: Sat, 27 Dec 2025 10:12:41 GMT
location: https://example.com/wp-login.php?redirect_to=https%3A%2F%2Fexample.com%2Fwp-admin%2F&reauth=1
set-cookie: wordpress_test_cookie=WP%20Cookie%20check; path=/; secure; HttpOnly
server: nginx

Ce que cela signifie : Vous obtenez une redirection normale vers la page de connexion. Si des utilisateurs disent « wp-admin ne s’ouvre pas », vérifiez si la connexion elle‑même fonctionne et si les cookies sont bien posés/retournés.

Décision : Si vous voyez une boucle de location: qui rebondit entre HTTP et HTTPS ou entre domaines, passez au diagnostic de boucle de redirection (Tâches 4–6).

Task 2: Check whether wp-login.php loads but wp-admin doesn’t

cr0x@server:~$ curl -sS -o /dev/null -D - https://example.com/wp-login.php | head -n 15
HTTP/2 200
date: Sat, 27 Dec 2025 10:12:55 GMT
content-type: text/html; charset=UTF-8
server: nginx

Ce que cela signifie : La page de connexion est atteignable. Si wp-admin se met en timeout ou renvoie 500 alors que wp-login est OK, suspectez des hooks de plugin pendant le bootstrap admin, une BD lente après l’authentification, ou la capacité PHP‑FPM.

Décision : Concentrez‑vous sur PHP‑FPM, la BD et les erreurs fatales WordPress plutôt que sur DNS/CDN.

Task 3: Identify the exact upstream error (Nginx example)

cr0x@server:~$ sudo tail -n 40 /var/log/nginx/error.log
2025/12/27 10:13:10 [error] 1842#1842: *991 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 203.0.113.10, server: example.com, request: "GET /wp-admin/ HTTP/2.0", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "example.com"

Ce que cela signifie : Nginx a parlé à PHP‑FPM mais n’a pas reçu d’en‑tête de réponse avant le timeout. Ce n’est presque jamais « un bug Nginx ». PHP est bloqué, surchargé, ou attend la BD/le disque/le réseau.

Décision : Vérifiez la santé du pool PHP‑FPM et les requêtes lentes (Tâches 7–9), puis la BD (Tâche 12).

Task 4: Detect redirect loops and where they start

cr0x@server:~$ curl -sS -o /dev/null -D - -L --max-redirs 10 https://example.com/wp-admin/ | egrep -i 'HTTP/|location:'
HTTP/2 301
location: http://example.com/wp-admin/
HTTP/1.1 301 Moved Permanently
location: https://example.com/wp-admin/
HTTP/2 301
location: http://example.com/wp-admin/
HTTP/1.1 301 Moved Permanently
location: https://example.com/wp-admin/

Ce que cela signifie : Vous rebondissez entre HTTP et HTTPS. C’est un problème de détection de schéma du proxy inverse / SSL termination, ou siteurl/home dans WordPress qui ne correspond pas à la réalité.

Décision : Corrigez la détection du schéma : assurez‑vous que X-Forwarded-Proto est défini par le proxy et pris en compte par WordPress (Tâche 6), et validez les réglages URL en BD (Tâche 11).

Task 5: Confirm what the server thinks the canonical host/scheme is

cr0x@server:~$ php -r 'echo "HTTPS=" . ($_SERVER["HTTPS"] ?? "");'
HTTPS=

Ce que cela signifie : En CLI c’est vide, mais cela vous rappelle le vrai problème : WordPress décide « suis‑je en HTTPS ? » d’après les variables serveur. Derrière un proxy, ces variables sont souvent fausses sauf configuration.

Décision : Assurez‑vous que le serveur web transmet les fastcgi params corrects et que votre proxy injecte les en‑têtes forward appropriés.

Task 6: Verify reverse proxy headers reach PHP (Nginx + PHP-FPM)

cr0x@server:~$ sudo grep -R "X-Forwarded-Proto" -n /etc/nginx/sites-enabled | head
/etc/nginx/sites-enabled/example.conf:42:proxy_set_header X-Forwarded-Proto $scheme;

Ce que cela signifie : L’en‑tête est défini pour les emplacements proxy, mais wp-admin peut être servi via fastcgi, pas proxy. Différents blocs, comportement différent.

Décision : Si vous terminez le TLS en amont, configurez WordPress avec la logique $_SERVER['HTTPS']='on' (généralement via wp-config.php) basée sur X-Forwarded-Proto, et assurez‑vous que votre load balancer l’envoie réellement.

Task 7: Check PHP-FPM status: are workers saturated?

cr0x@server:~$ sudo systemctl status php8.2-fpm --no-pager
● php8.2-fpm.service - The PHP 8.2 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php8.2-fpm.service; enabled)
     Active: active (running) since Sat 2025-12-27 09:41:03 UTC; 33min ago
   Main PID: 912 (php-fpm8.2)
     Status: "Processes active: 28, idle: 0, Requests: 18452, slow: 37, Traffic: 2.1req/sec"

Ce que cela signifie : Idle est à 0. C’est une piste directe : le pool est totalement occupé. Les requêtes font la queue, Nginx timeoute, wp-admin « ne s’ouvre pas ».

Décision : Soit augmentez la capacité (augmenter pm.max_children prudemment, scaler horizontalement), soit réduisez le coût par requête (corriger requêtes BD lentes, désactiver plugins fautifs, résoudre des blocages disque).

Task 8: Inspect PHP-FPM pool config for limits that match your symptoms

cr0x@server:~$ sudo egrep -n 'pm\.max_children|pm\.max_requests|request_terminate_timeout' /etc/php/8.2/fpm/pool.d/www.conf | sed -n '1,120p'
56:pm.max_children = 20
62:pm.max_requests = 500
115:request_terminate_timeout = 60s

Ce que cela signifie : Avec max_children à 20, les pics d’admin peuvent saturer rapidement. Un timeout de terminaison à 60s peut tuer des opérations lentes légitimes (comme des mises à jour de plugin), mais évite aussi un blocage total.

Décision : Si vous voyez des timeouts autour de ~60s, cela peut être auto‑infligé. Ajustez en fonction du CPU/mémoire et des profils réels de requêtes, pas des impressions.

Task 9: Identify whether PHP is dying from memory exhaustion

cr0x@server:~$ sudo tail -n 30 /var/log/php8.2-fpm.log
[27-Dec-2025 10:14:02] WARNING: [pool www] child 2143 said into stderr: "PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 4096 bytes) in /var/www/html/wp-includes/class-wpdb.php on line 2345"

Ce que cela signifie : Classique : limite mémoire atteinte. wp-admin a tendance à charger plus de chemins de code et de gros tableaux.

Décision : Augmentez la limite mémoire PHP (avec précaution) et trouvez la cause sous‑jacente (souvent un plugin effectuant des requêtes admin lourdes). Ne la montez pas jusqu’à ce que l’hôte commence à swapper jusqu’à l’effondrement.

Task 10: Confirm WordPress core files exist and are readable

cr0x@server:~$ ls -la /var/www/html/wp-admin | head
total 172
drwxr-xr-x  9 www-data www-data  4096 Dec 26 22:01 .
drwxr-xr-x  5 www-data www-data  4096 Dec 27 09:55 ..
-rw-r--r--  1 www-data www-data  7339 Dec 26 22:01 admin.php
-rw-r--r--  1 www-data www-data  1058 Dec 26 22:01 index.php

Ce que cela signifie : Les fichiers sont présents et appartenant à l’utilisateur d’exécution. Si vous voyez des propriétaires étranges (comme un utilisateur CI) ou des fichiers manquants, le cœur peut être partiellement déployé ou écrasé.

Décision : Corrigez la propriété des fichiers et restaurez un cœur WordPress sain si nécessaire. Les mises à jour partielles provoquent des pannes bizarres réservées à l’admin.

Task 11: Verify the WordPress site URLs stored in the database

cr0x@server:~$ mysql -N -e "SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl','home');"
siteurl https://example.com
home https://example.com

Ce que cela signifie : Si ces valeurs sont erronées (http vs https, mauvais domaine, URL de staging obsolète), les redirections wp-admin peuvent boucler indéfiniment ou renvoyer vers le mauvais hôte.

Décision : Corrigez‑les en BD (ou override temporaire dans wp-config.php lors de la réponse à l’incident). Ensuite corrigez le processus qui a permis la dérive.

Task 12: Check MySQL/MariaDB health and slow queries right now

cr0x@server:~$ mysql -e "SHOW PROCESSLIST;" | head -n 15
Id	User	Host	db	Command	Time	State	Info
214	app	10.0.2.15:51122	wp	Query	28	Sending data	SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes'
221	app	10.0.2.15:51148	wp	Query	31	Locked	UPDATE wp_options SET option_value = '...' WHERE option_name = 'rewrite_rules'

Ce que cela signifie : Les lectures d’options autoload prennent des dizaines de secondes et une UPDATE est verrouillée : c’est une cause réelle du blocage de wp-admin. Les pages admin lisent les options constamment ; la contention sur ces verrous est toxique.

Décision : Identifiez le détenteur du verrou, réduisez la contention, et examinez les payloads autoload gonflés. Si nécessaire, tuez les requêtes échappées pendant l’incident et corrigez le plugin/tâche en cause.

Task 13: Find the lock holder (InnoDB) and decide whether to kill it

cr0x@server:~$ mysql -e "SHOW ENGINE INNODB STATUS\G" | egrep -n "LATEST DETECTED DEADLOCK|TRANSACTION|WAITING" | head -n 30
103:TRANSACTION 4211892, ACTIVE 62 sec starting index read
110:LOCK WAIT 12 lock struct(s), heap size 1136, 6 row lock(s)
121:MySQL thread id 221, OS thread handle 140520112060160, query id 981231 10.0.2.15 app updating

Ce que cela signifie : Vous avez une attente de verrou d’environ ~60 secondes. Les requêtes admin peuvent s’accumuler derrière et saturer PHP‑FPM.

Décision : Lors de la réponse à l’incident, pensez à tuer la session bloquante si c’est sûr (KILL 221;) et si vous comprenez les effets secondaires (mises à jour partielles, installations de plugin). Ensuite procédez à l’analyse de la cause racine.

Task 14: Check disk space and inode exhaustion (silent killers)

cr0x@server:~$ df -h /var/www/html /var/lib/mysql
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        80G   79G  650M  99% /
/dev/vdb1       200G  120G   81G  60% /var/lib/mysql

cr0x@server:~$ df -i /var/www/html
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/vda1      5242880 5239011   3869  100% /

Ce que cela signifie : Vous êtes à court d’inodes. Cela peut casser les sessions, les uploads, les mises à jour de plugins, les écritures de cache et les logs. Ça se manifeste par des pannes « wp-admin » de façon créative et peu utile.

Décision : Libérez des inodes (nettoyez les répertoires temp/cache, anciennes releases, rotation des logs) et ajoutez du monitoring. Un disque plein est prévisible ; traitez‑le comme une panne de processus, pas comme un acte de la nature.

Task 15: Identify I/O wait that makes everything “slow”

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

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.10    0.00    4.22   62.35    0.00   21.33

Device            r/s     w/s   rkB/s   wkB/s  aqu-sz  await  %util
vda              4.20   85.30   92.1   941.4    8.12  91.3  98.7

Ce que cela signifie : 62% d’iowait et utilisation disque proche de 100%. Votre « problème WordPress » est en réalité une latence de stockage. wp-admin effectue beaucoup de petites lectures (fichiers PHP, sessions, options), donc il souffre tôt.

Décision : Réduisez l’I/O (désactivez logs bavards, corrigez jobs de sauvegarde, déplacez sessions/cache objet en mémoire, améliorez le niveau de stockage) ou augmentez les IOPS. Ne touchez pas aux timeouts PHP pour « réparer » un effondrement du stockage.

Task 16: Confirm Redis object cache health (if used)

cr0x@server:~$ redis-cli -h 127.0.0.1 ping
PONG

cr0x@server:~$ redis-cli -h 127.0.0.1 info stats | egrep 'instantaneous_ops_per_sec|rejected_connections'
instantaneous_ops_per_sec:1874
rejected_connections:0

Ce que cela signifie : Redis est vivant et n’accepte pas de connexions rejetées. Si Redis est down et que WordPress est configuré pour l’utiliser, wp-admin peut se bloquer sur des timeouts de connexion selon la configuration du client.

Décision : Si Redis échoue, restaurez‑le ou désactivez temporairement le drop‑in du cache objet (wp-content/object-cache.php) pour restaurer l’accès admin.

Task 17: Disable plugins without wp-admin access (the safe-ish way)

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

Ce que cela signifie : WordPress ne chargera aucun plugin si le répertoire est vide. C’est la façon la plus rapide de confirmer si « un plugin a tué l’admin ».

Décision : Si wp-admin revient, restaurez les plugins un par un (ou faites une recherche binaire) pour identifier le fautif. Ensuite mettez‑le à jour/remplacez‑le. Si ça ne revient pas, les plugins ne sont pas la cause principale — passez à autre chose.

Task 18: Switch to a default theme if the admin is theme-hooked into oblivion

cr0x@server:~$ mysql -N -e "UPDATE wp_options SET option_value='twentytwentyfour' WHERE option_name IN ('template','stylesheet'); SELECT option_name, option_value FROM wp_options WHERE option_name IN ('template','stylesheet');"
template	twentytwentyfour
stylesheet	twentytwentyfour

Ce que cela signifie : Cela force un thème par défaut. Certains thèmes (ou frameworks de thème) se greffent dans l’admin et peuvent le casser.

Décision : Si l’admin revient, votre thème est en cause ou a exposé un problème de version PHP. Corrigez en staging, puis redéployez en sécurité.

Task 19: Check for “maintenance mode” stuck on

cr0x@server:~$ test -f /var/www/html/.maintenance && echo "maintenance file present" || echo "no maintenance file"
maintenance file present

Ce que cela signifie : Une mise à jour échouée peut laisser WordPress en mode maintenance, renvoyant un comportement 503 ou une page « Briefly unavailable ».

Décision : Supprimez .maintenance seulement si vous êtes sûr qu’aucune mise à jour n’est en cours. Relancez ensuite correctement la mise à jour.

Task 20: Enable WordPress debug logging temporarily (controlled blast radius)

cr0x@server:~$ sudo -u www-data bash -lc "grep -n \"WP_DEBUG\" -n /var/www/html/wp-config.php | head"
90:define('WP_DEBUG', false);
91:define('WP_DEBUG_LOG', false);
92:define('WP_DEBUG_DISPLAY', false);

Ce que cela signifie : Le debug est désactivé (bien). Quand wp-admin est down à cause d’erreurs fatales, vous pourriez avoir besoin de logs. Mais ne renvoyez pas les erreurs dans le HTML en prod.

Décision : Activez WP_DEBUG_LOG à true en gardant WP_DEBUG_DISPLAY à false, reproduisez une fois, puis désactivez et taillez wp-content/debug.log.

Blague n°2 : Activer le debug en production, c’est comme allumer la lumière de la cabine pendant des turbulences — utile, mais personne ne se détend après.

Erreurs courantes : symptôme → cause → correctif

« Trop de redirections » sur /wp-admin

Symptôme : Erreur navigateur ou curl montrant des 301/302 alternés entre http/https ou entre domaines.

Cause racine : discordance siteurl/home, proxy qui ne fournit pas X-Forwarded-Proto, WordPress qui pense être en HTTP alors que le client est en HTTPS, ou un plugin de redirection canonical qui se bat avec le load balancer.

Correctif : Assurez‑vous des en‑têtes forward corrects ; corrigez siteurl/home ; ajoutez une détection HTTPS explicite dans wp-config.php derrière une terminaison TLS ; retirez les logiques de redirection dupliquées.

Écran blanc vide (aucun HTML, aucune erreur)

Symptôme : wp-admin renvoie une page vide, parfois avec un statut 200.

Cause racine : fatal PHP avec display_errors désactivé ; cache d’opcode confus après un déploiement ; plugin/thème cassé ; épuisement mémoire.

Correctif : Vérifiez les logs PHP‑FPM et du serveur web ; activez brièvement le log WP DEBUG ; revenez sur la mise à jour plugin/thème ; videz l’opcache en redémarrant le service si approprié.

502 Bad Gateway depuis Nginx (ou 504 Gateway Timeout)

Symptôme : Nginx renvoie 502/504 ; le log d’erreur mentionne upstream timed out ou connect() failed to php-fpm socket.

Cause racine : PHP‑FPM down, chemin de socket incorrect, pool saturé, ou PHP bloqué en attente de BD/disque/réseau.

Correctif : Redémarrez PHP‑FPM s’il est bloqué ; corrigez permissions/paths de socket ; augmentez la capacité ; trouvez et supprimez le chemin lent (plugin, verrou BD, latence stockage).

403 Forbidden uniquement sur wp-admin

Symptôme : La page d’accueil charge ; wp-admin renvoie 403.

Cause racine : règle WAF déclenchée par les cookies admin ou les query strings ; auth basique mal appliquée ; plugin de sécurité bloquant une IP ; permissions du dossier wp-admin.

Correctif : Consultez les logs WAF ; whitelistiez les chemins admin avec prudence ; confirmez les blocs location Nginx/Apache ; corrigez la propriété/permissions ; vérifiez l’absence de règles deny accidentelles.

« Error establishing a database connection » en accédant à l’admin

Symptôme : Page d’erreur BD, souvent intermittente sous charge.

Cause racine : BD down, connexions max atteintes, problème réseau, DNS du host BD cassé, ou requêtes lentes provoquant l’accumulation de connexions.

Correctif : Vérifiez la santé BD, le processlist et les limites de connexions ; scalez la BD ; optimisez les requêtes ; n’utilisez pas de connexions persistantes si vous ne maîtrisez pas leurs conséquences.

La connexion fonctionne, mais wp-admin charge indéfiniment

Symptôme : Les identifiants sont acceptés ; le tableau de bord n’achève jamais le chargement.

Cause racine : appels admin-ajax.php bloqués à cause d’un plugin, API REST bloquée, ou appel externe lent depuis l’admin.

Correctif : Inspectez l’onglet réseau des outils dev du navigateur pour requêtes coincées ; taillez les logs pour admin-ajax ; désactivez les plugins ; bloquez ou appliquez des timeouts aux appels externes ; autorisez les endpoints REST à travers les couches de sécurité.

Seuls certains utilisateurs peuvent accéder à wp-admin

Symptôme : Ça marche pour vous, échoue pour vos collègues ; ou ça marche sur mobile mais pas sur le laptop d’entreprise.

Cause racine : domaine/chemin de cookie incorrect, problèmes SameSite derrière un SSO, proxy d’entreprise qui met en cache ou supprime des en‑têtes, règles allowlist IP.

Correctif : Normalisez domaine et schéma ; vérifiez les attributs Set‑Cookie ; évitez les allowlists IP sauf si vous contrôlez le réseau ; vérifiez le comportement du proxy.

Trois mini‑histoires d’entreprise

Incident n°1 : La mauvaise hypothèse (l’édition « ça ne peut pas être le DNS »)

Une entreprise moyenne gérait WordPress pour des pages marketing et un portail partenaire protégé dans wp-admin. La page d’accueil était derrière un cache CDN agressif. Tout avait l’air sain de l’extérieur : les landing pages chargeaient instantanément, les checks de disponibilité étaient verts, les dirigeants arrêtaient de poser des questions. Naturellement, c’est à ce moment précis que le vrai problème a commencé.

Les équipes commerciales ont signalé que personne ne pouvait se connecter. Les ingénieurs ont tenté le classique : vider le cache, incognito, accuser les cookies. Quelqu’un a affirmé, avec confiance, que « le DNS est bon parce que le site charge ». Cette hypothèse a pris l’incident en otage pendant deux heures.

Le piège : le CDN avait deux origines configurées. Les pages statiques venaient de l’origine A (correcte). Les chemins admin étaient routés vers l’origine B (environnement ancien) à cause d’une règle path‑based périmée ajoutée lors d’une migration précédente. L’origine B répondait encore, mais avec un certificat TLS différent et un siteurl WordPress différent, donc elle renvoyait les utilisateurs dans une boucle de redirection jusqu’à ce que les navigateurs abandonnent.

Le correctif fut ennuyeux : corriger les règles de routage CDN et purger le comportement erroné. La leçon était plus nette : « le site charge » n’est pas un check de santé. Il vous faut des checks qui atteignent /wp-login.php et un endpoint admin dynamique, pas uniquement la page d’accueil mise en cache.

Incident n°2 : Une optimisation qui s’est retournée contre l’équipe (édition cache objet)

Une autre équipe cherchait à améliorer les performances. Ils ont ajouté un cache objet Redis en drop‑in pour réduire la charge BD. En staging tout semblait excellent : moins de requêtes BD, génération plus rapide, jolis graphes. Ils l’ont déployé en production pendant une fenêtre à faible trafic et sont rentrés chez eux fiers.

Trois jours plus tard, wp-admin a commencé à timeouter de façon intermittente. La page d’accueil restait ultra‑rapide car mise en cache à la périphérie. Le tableau de bord, lui, devenait un pile ou face. Les workers PHP‑FPM s’accumulaient en « busy ». Les logs Nginx se remplissaient de timeouts upstream. La base de données paraissait plus calme que d’habitude, ce qui était étrangement rassurant.

Le vrai problème était le chemin réseau et les timeouts. Redis était sur un nœud séparé. Sous certaines conditions de perte de paquets, le client Redis se bloquait plus longtemps que le timeout upstream du web tier. Chaque requête admin attendait les lectures du cache, retenant un worker PHP en otage. Assez d’otages et le pool saturait. Tout semblait être « WordPress en panne », alors que votre cache était juste très lent.

La résolution a inclus la définition de timeouts clients raisonnables, l’ajout de monitoring santé Redis et la stratégie « fail open » pour le cache objet quand approprié. L’optimisation n’a pas échoué parce que le caching est mauvais ; elle a échoué parce que l’équipe a traité une nouvelle dépendance comme si elle était aussi fiable que localhost.

Incident n°3 : La pratique ennuyeuse mais correcte qui a sauvé la situation (édition hygiène de release)

Une autre organisation exécutait plusieurs sites WordPress sur une infrastructure partagée. Pas glamour. Ce qu’ils avaient, c’était une pratique de release disciplinée : répertoires de déploiement immuables, switch par symlink et un rollback documenté que n’importe quel on‑call pouvait exécuter à 3h du matin sans inventer une nouvelle syntaxe.

Un soir, une mise à jour de plugin a introduit une erreur fatale PHP au bootstrap admin pour une partie des requêtes — spécifiquement en chargeant une page de paramètres appelant une fonction manquante sous PHP 8.2. Les pages frontales restaient correctes grâce au cache et parce que le chemin fatal était uniquement admin. L’incident a été signalé comme « les admins ne peuvent pas publier ». C’est une panne business, même si le tableau de bord uptime reste vert.

L’ingénieur on‑call n’a pas SSH‑é pour « fouiller ». Ils ont suivi le runbook : basculer le symlink vers la release précédente, redémarrer PHP‑FPM pour vider l’opcache, vérifier la santé de wp-admin, puis seulement lancer l’analyse de cause racine. Les opérations business ont repris en quelques minutes.

Plus tard, ils ont testé le plugin en staging reproduisant la version PHP de production et ont poussé une version corrigée. Personne n’a écrit un postmortem héroïque sur « avoir veillé toute la nuit ». Ils ont écrit un ticket tranquille : « Ajouter des checks synthétiques pour les chemins admin et imposer des gates pour les mises à jour de plugins ». L’ennuyeux a encore sauvé la journée.

Checklists / plan pas à pas

Étapes : restaurer l’accès wp-admin en sécurité

1. Confirmez l’étendue : Est‑ce que c’est seulement vous, seulement certains réseaux, ou tout le monde ? Testez depuis deux points de vue (votre portable + le serveur).
2. Capturez le comportement HTTP : code de statut, chaîne de redirection et en‑têtes de réponse pour /wp-admin/ et /wp-login.php.
3. Consultez les logs du serveur web : faites correspondre l’horodatage et l’ID de requête si vous en avez un.
4. Vérifiez la santé PHP‑FPM : en cours d’exécution, saturé, erreurs fatales, requêtes lentes.
5. Vérifiez la BD : connectivité, verrous, requêtes lentes, connexions max.
6. Vérifiez le disque : espace + inodes + I/O wait. C’est là que naît le comportement « aléatoire ».
7. Écartez les plugins rapidement : renommez wp-content/plugins. Si l’admin revient, isolez le fautif.
8. Écartez le thème : basculez vers un thème par défaut via une mise à jour BD si nécessaire.
9. Confirmez les réglages d’URL canoniques : siteurl et home. Corrigez les discordances qui causent des boucles.
10. Ne touchez aux timeouts/capacités qu’après : les timeouts ne résolvent pas des dépendances cassées ; ce sont des garde‑fous.
11. Rollback si changement récent : Si wp-admin est mort après une mise à jour, ne discutez pas — rollbackez et stabilisez, puis enquêtez.
12. Notez la cause racine pendant que c’est frais : votre futur vous est une autre personne avec moins de contexte et plus d’alertes.

Checklist : sanity pour proxy inverse et offload HTTPS

• Le load balancer envoie X-Forwarded-Proto et X-Forwarded-For.
• Le serveur web transmet les en‑têtes/params pertinents à PHP.
• WordPress voit correctement le HTTPS (surtout pour les cookies admin marqués secure).
• siteurl et home correspondent à l’URL publique, schéma inclus.
• Pas de logique de redirection dupliquée (load balancer + plugin + serveur web) qui se battent.

Checklist : capacité et santé des dépendances

• PHP‑FPM a des workers idle en charge normale.
• La BD montre peu d’attentes de verrous et des temps de requête raisonnables pour options/utilisateurs.
• Le disque a de la marge en espace et en inodes ; les sauvegardes ne coïncident pas avec les pics de trafic.
• Redis/Memcached est soit sain, soit configuré pour échouer rapidement / ouvrir la défaillance.
• Le monitoring inclut des checks synthétiques atteignant /wp-login.php et un endpoint dynamique non mis en cache.

FAQ

Pourquoi la page d’accueil fonctionne mais wp-admin est hors service ?

Parce que votre page d’accueil est probablement mise en cache (CDN, plugin de cache de page, proxy inverse). wp-admin est spécifique à l’utilisateur et dynamique, donc il atteint PHP et la base de données directement. Les pannes admin sont souvent des problèmes de capacité ou de dépendance que le cache masque.

Quelle est la façon la plus rapide de savoir si un plugin pose problème ?

Renommez wp-content/plugins pour que WordPress ne charge aucun plugin, puis testez wp-admin. Si cela récupère, vous avez prouvé une « défaillance induite par un plugin ». Ensuite restaurez les plugins progressivement pour trouver le coupable.

Augmenter la limite mémoire PHP est‑ce une vraie solution ?

Parfois. Si les logs montrent un épuisement mémoire, augmenter la limite peut restaurer l’accès. Mais considérez‑le comme un pansement. La cause sous‑jacente est souvent une page admin effectuant des requêtes lourdes ou chargeant un payload d’options énorme.

Qu’est‑ce qui provoque « trop de redirections » spécifiquement sur wp-admin ?

Généralement une confusion de schéma/hôte : terminaison TLS au niveau d’un proxy sans en‑têtes corrects, home/siteurl discordants, ou un plugin de redirection forçant HTTPS alors que l’origine pense être en HTTP.

Comment déboguer un écran blanc sans afficher les erreurs aux utilisateurs ?

Vérifiez d’abord les logs Nginx/Apache et PHP‑FPM. Si nécessaire, activez WP_DEBUG_LOG en laissant WP_DEBUG_DISPLAY désactivé, reproduisez une fois, puis rétablissez. Lisez wp-content/debug.log.

Un Cloudflare/CDN/WAF peut‑il bloquer wp-admin alors que le site charge ?

Oui. Les règles WAF ciblent souvent /wp-admin, wp-login.php, l’API REST ou des patterns admin-ajax. De plus, les CDN peuvent router différemment les chemins admin. Consultez les logs edge et les règles de routage par chemin.

Comment savoir s’il s’agit d’une saturation PHP‑FPM vs une seule dépendance lente ?

La saturation PHP‑FPM se manifeste par « idle: 0 » et des requêtes en file d’attente, souvent avec des timeouts upstream. Ensuite il faut trouver pourquoi les workers sont occupés : requêtes BD lentes/verrous, attente I/O disque, ou appels API externes. Ne vous arrêtez pas à « le pool est plein ».

Quel est le problème de base de données le plus fréquent derrière les blocages wp-admin ?

La contention de verrou et les requêtes lentes sur la table options. Les pages admin lisent constamment les options, et certains plugins mettent à jour les options d’une manière qui garde les verrous plus longtemps que prévu.

Dois‑je redémarrer des services lors d’un incident ?

Redémarrer PHP‑FPM peut être une mesure tactique valide si le service est bloqué ou si l’opcache est corrompu après un déploiement. Redémarrer aveuglément et à répétition, sans logs, transforme les incidents en mystères. Capturez les logs et symptômes d’abord, puis redémarrez avec intention.

Comment prévenir que les pannes wp-admin passent inaperçues ?

Ajoutez du monitoring synthétique qui atteint /wp-login.php et un endpoint dynamique (non mis en cache). Alertez sur l’augmentation des 5xx, les boucles de redirection et les timeouts upstream. « Homepage 200 OK » n’est pas une stratégie de fiabilité.

Conclusion : étapes suivantes pour éviter les récurrences

Quand wp-admin ne s’ouvre pas, arrêtez de traiter cela comme une énigme WordPress et commencez à le traiter comme un incident de production. Identifiez la classe de défaillance (redirections, 5xx, timeouts, boucles d’auth), confirmez où la requête meurt (edge, serveur web, PHP, BD, stockage), et appliquez le plus petit changement sûr qui restaure l’accès.

Faites ceci ensuite, dans l’ordre :

1. Ajoutez des checks santé pour les chemins admin (page de connexion plus un endpoint dynamique) afin que le cache ne puisse pas vous mentir.
2. Instrumentez la pile : timing des upstreams du serveur web, saturation PHP‑FPM, attentes de verrous BD, I/O wait disque, et remplissage système de fichiers (espace et inodes).
3. Facilitez les rollbacks : releases immuables, swaps de symlink et un runbook de rollback en une commande.
4. Contrôlez les mises à jour de plugins : staging aligné sur la production PHP, et une gate pour les plugins à risque qui touchent fortement l’admin.
5. Définissez la posture des dépendances : si vous ajoutez Redis, NFS, WAF ou une nouvelle couche de proxy, vous ajoutez aussi une nouvelle façon pour wp-admin de tomber en panne. Concevez les timeouts et modes d’échec volontairement.

Le tableau de bord n’est pas spécial. C’est juste votre endpoint le plus honnête — non mis en cache, étatique et impitoyable. Traitez‑le comme tel.