Accès wp-admin bloqué : méthodes simples pour le rétablir

Si vous voyez soudain “There has been a critical error on this website” ou une page blanche dès que vous ouvrez /wp-admin, vous n’êtes pas bloqué “pour toujours”. Dans la majorité des cas, l’accès se récupère en 10 à 30 minutes avec une méthode propre, sans toucher au cœur de WordPress.

Le problème

Vous n’arrivez plus à accéder à l’administration WordPress (https://votre-site.tld/wp-admin/ ou /wp-login.php). Le front (la partie publique) peut fonctionner… ou être cassé aussi.

Voici des messages typiques que j’ai vus (et que vous pouvez retrouver dans les logs serveur) :

There has been a critical error on this website.

HTTP ERROR 500

ERR_TOO_MANY_REDIRECTS

Error establishing a database connection

Sorry, you are not allowed to access this page.

403 Forbidden - You don't have permission to access /wp-admin/ on this server.

Où et quand ça apparaît :

Admin uniquement : /wp-admin renvoie une erreur 500, une page blanche, ou une boucle de redirection, alors que la page d’accueil marche.
Admin + front : tout le site est KO (souvent une erreur PHP fatale, un problème de base de données, ou une configuration PHP/mémoire).
Après un événement : mise à jour WordPress 6.9.4, mise à jour d’un plugin, activation d’un snippet, migration d’hébergeur, passage à PHP 8.1/8.2/8.3, changement de DNS/HTTPS.

À qui s’adresse ce guide : blogueurs débutants (et ceux qui gèrent leur site sans équipe technique). À la fin, vous saurez :

désactiver un plugin ou un thème sans accéder à l’admin ;
activer un mode debug propre (sans exposer d’infos sensibles) ;
isoler le vrai coupable (plugin, thème, cache, .htaccess, base de données, PHP) ;
récupérer l’accès à wp-admin sur WordPress 6.9.4+ (PHP 8.1+).

Résumé rapide

Erreur critique / 500 : renommez wp-content/plugins pour désactiver tous les plugins, puis réactivez un par un.
Page blanche : activez WP_DEBUG_LOG et lisez wp-content/debug.log (souvent une erreur PHP fatale).
Boucle de redirection : vérifiez WP_HOME/WP_SITEURL, HTTP/HTTPS, et les règles de cache/CDN.
403/401 : permissions fichiers, règles WAF (ModSecurity/Cloudflare), ou restriction IP sur /wp-admin.
“Error establishing a database connection” : identifiants DB, serveur MySQL, ou base saturée/corrompue.
Ne modifiez jamais le core : utilisez un mu-plugin ou votre wp-config.php pour les actions de récupération.

Les symptômes

Vous n’avez pas besoin d’identifier “la cause” tout de suite. Commencez par reconnaître votre symptôme, puis suivez la solution correspondante.

Symptômes fréquents côté navigateur

Erreur 500 / “Critical error” en allant sur /wp-admin (ou /wp-login.php).
Écran blanc (white screen of death) : page vide, parfois sans message.
ERR_TOO_MANY_REDIRECTS : boucle HTTP ↔ HTTPS, ou URL du site incohérente.
403 Forbidden / 401 Unauthorized : blocage serveur/WAF, ou permissions.
504 Gateway Timeout : PHP trop lent, requête bloquée, ou serveur surchargé.
La page de login s’affiche, mais après connexion vous revenez au login (cookies/sessions, cache, HTTPS, ou table wp_options).

Symptômes techniques (souvent visibles dans les logs)

Erreur PHP fatale : “Uncaught Error”, “Allowed memory size exhausted”, “Call to undefined function…”.
REST API / AJAX cassés : l’admin charge mal, menus qui tournent, éditeur de blocs instable (Gutenberg), Media Library qui ne s’ouvre pas.
Conflit plugin/thème : très courant avec des plugins de sécurité, cache, optimisation JS/CSS, ou snippets collés au mauvais endroit.
Cache : vous corrigez, mais le navigateur/CDN renvoie encore l’ancienne erreur.

Tableau de diagnostic (rapide mais fiable)

Symptôme	Cause probable	Vérification	Solution
Erreur 500 / Critical error	Plugin ou snippet cassé (PHP)	Consulter `debug.log` / logs PHP	Désactiver plugins, isoler le coupable (Solution 1)
Page blanche	Fatal error masquée / mémoire	Activer `WP_DEBUG_LOG`	Augmenter mémoire + corriger l’erreur (Solution 3)
ERR_TOO_MANY_REDIRECTS	HTTP/HTTPS, URL site, proxy	Comparer URL navigateur vs `siteurl`/`home`	Corriger WP_HOME/WP_SITEURL, purge cache
403 sur /wp-admin	WAF, règle serveur, permissions	Tester en 4G, désactiver temporairement WAF	Règles serveur / whitelist / permissions (Solution 3)
Login en boucle	Cookies, cache, HTTPS, domaine	Test navigation privée, vider cache CDN	Fix URL, vider cache, vérifier cookies
Error establishing a database connection	DB down / identifiants	Vérifier `wp-config.php` + statut MySQL	Corriger DB_*, contacter hébergeur

Pourquoi ça arrive

Version simple (débutant) : wp-admin charge beaucoup plus de code que le front. Un plugin peut “marcher” sur la page d’accueil, mais casser l’admin (AJAX, REST API, droits, scripts). Quand une erreur PHP survient, WordPress 6.9.4 affiche souvent un message générique, et vous n’avez pas accès à l’écran pour corriger.

Version technique (intermédiaire/pro) : l’admin passe par wp-admin/admin.php, charge des hooks (actions/filtres) et des dépendances JS/CSS. Une erreur fatale dans un plugin, un autoloader Composer mal déclaré, une classe PHP incompatible avec PHP 8.1+, ou une optimisation agressive (minification/delay JS) peut casser l’exécution avant même l’affichage du tableau de bord.

Causes classées du plus fréquent au plus rare (mon expérience terrain) :

Plugin cassé après mise à jour (cache, sécurité, optimisation, formulaire, e-commerce).
Snippet ajouté au mauvais endroit (dans le mauvais fichier, ou via un plugin de snippets qui ne gère pas les erreurs).
Thème (ou thème enfant) cassé : fonctions admin, functions.php avec une erreur de syntaxe.
Problème d’URL : HTTP/HTTPS, domaine, proxy, Cloudflare, changement de site URL en base.
Permissions / règles serveur : 403 sur /wp-admin, Basic Auth, WAF trop strict.
Mémoire PHP insuffisante ou limite d’exécution trop basse (surtout sur des sites avec Divi 5, Elementor, Avada + gros plugins).
Base de données indisponible, identifiants erronés, serveur DB down.
Fichiers corrompus (upload incomplet, disque plein, malware, synchronisation ratée).

Prérequis avant de commencer

Sauvegardez avant de modifier. Si vous n’avez plus accès à l’admin, faites au minimum :

une copie de wp-config.php ;
une archive de wp-content/ ;
si possible un export de la base (via l’outil de l’hébergeur, phpMyAdmin, ou WP-CLI).

Ce que vous devez avoir sous la main :

Accès FTP/SFTP (FileZilla, Cyberduck) ou gestionnaire de fichiers de l’hébergeur ;
Accès au panneau d’hébergement (logs, version PHP, redémarrage PHP-FPM) ;
Optionnel mais très utile : accès WP-CLI (ligne de commande).

Outils recommandés (une fois l’admin récupérée) :

Query Monitor (diagnostic requêtes, hooks, erreurs PHP) ;
Health Check & Troubleshooting (mode dépannage sans impacter les visiteurs).

Références officielles utiles pendant le dépannage :

Solution 1 : Désactiver les plugins sans accéder à l’admin

Quand /wp-admin casse après une mise à jour, le coupable est très souvent un plugin. L’objectif : désactiver tout, récupérer l’accès, puis réactiver un par un.

Étape 1 — Désactiver tous les plugins (sans base de données)

Où agir : via FTP/SFTP ou le gestionnaire de fichiers de l’hébergeur.

Allez dans wp-content/
Renommez le dossier plugins en plugins.off
Rechargez /wp-admin

Pourquoi ça marche : WordPress ne trouve plus les plugins, donc il ne peut pas les charger. C’est une désactivation “brute”, mais efficace.

Si l’admin revient, vous avez confirmé un conflit plugin.

Étape 2 — Réactiver les plugins un par un (méthode propre)

Renommez plugins.off en plugins
Dans wp-content/plugins, renommez un plugin à la fois, par exemple mon-plugin → mon-plugin.off
Testez /wp-admin après chaque changement

Astuce que j’utilise souvent : commencez par désactiver les plugins “à risque” :

cache/optimisation (minify, delay JS, combine CSS)
sécurité / firewall
plugins de snippets
plugins “tout-en-un” de performance

Cas fréquent : un plugin de snippets a cassé l’admin

J’ai souvent croisé ce scénario : un utilisateur colle un code trouvé sur un vieux tuto (pré-PHP 8), une virgule manque, et tout wp-admin tombe.

Exemple de code AVANT (cassé) : point-virgule manquant, fatal error.

Où ce code se trouve en général : functions.php du thème enfant, ou un plugin de snippets.

<?php
// Exemple volontairement cassé : oublie du point-virgule
add_action('init', function () {
    update_option('blogdescription', 'Mon site')
});

Code APRÈS (corrigé) :

<?php
// Correction : point-virgule ajouté, et on évite de faire ça à chaque chargement
add_action('admin_init', function () {
    // On limite l'exécution à l'admin, et on évite une écriture DB permanente
    if (get_option('bpcab_desc_updated') !== '1') {
        update_option('blogdescription', 'Mon site');
        update_option('bpcab_desc_updated', '1');
    }
});

Pourquoi ça corrige :

Le point-virgule manquant provoquait une erreur de syntaxe → PHP stoppe tout.
Le hook action admin_init (une “action” = un point d’exécution où vous accrochez votre code) limite l’exécution à l’admin.
On évite d’écrire en base à chaque page (sinon vous créez d’autres problèmes).

Bonus : mu-plugin de “mode secours” (si vous retombez en panne)

Si vous êtes bloqué régulièrement, créez un mu-plugin (Must-Use plugin). Un mu-plugin se charge automatiquement, même si l’admin est inaccessible. C’est mon filet de sécurité sur des sites clients.

Où coller le code : créez le fichier wp-content/mu-plugins/bpcab-recovery.php. Créez le dossier mu-plugins s’il n’existe pas.

Risque sécurité : ne laissez pas un mode “désactivation globale” permanent. Utilisez-le temporairement, avec une condition stricte.

Exemple AVANT (cassé) : un site en erreur critique à cause d’un plugin, mais vous ne pouvez pas le désactiver via l’admin.

Exemple APRÈS (mu-plugin de secours) : désactive tous les plugins uniquement si vous ajoutez ?recovery=1 à l’URL et que vous êtes sur votre IP.

<?php
/**
 * Plugin Name: BPCAB Recovery (mu-plugin)
 * Description: Filet de secours temporaire pour récupérer l'accès à wp-admin.
 */

// Sécurité : ne pas exécuter en accès direct.
if (!defined('ABSPATH')) {
    exit;
}

add_filter('option_active_plugins', function ($plugins) {
    // N'activez ce mode que temporairement.
    if (!isset($_GET['recovery']) || $_GET['recovery'] !== '1') {
        return $plugins;
    }

    // Restreignez à votre IP (à adapter). Si vous êtes derrière un proxy, attention.
    $ip_autorisee = '203.0.113.10'; // Exemple (RFC 5737)
    $ip_client = $_SERVER['REMOTE_ADDR'] ?? '';

    if ($ip_client !== $ip_autorisee) {
        return $plugins;
    }

    // Désactive tous les plugins (WordPress chargera "aucun plugin").
    return [];
}, 1);

Pourquoi ça marche : active_plugins est une option WordPress. En filtrant sa valeur (un filtre = un hook qui modifie une valeur), vous empêchez le chargement des plugins, le temps de vous connecter et réparer.

Solution 2 : Revenir à un thème sain (et sauver un site Divi/Elementor/Avada)

Quand le problème vient du thème (ou du thème enfant), l’admin peut casser dès le chargement, surtout si functions.php contient une erreur PHP, ou si le thème surcharge des parties de l’admin.

Étape 1 — Forcer un thème par défaut

Où agir : base de données (phpMyAdmin) ou WP-CLI. Si vous n’avez pas accès DB, passez à la méthode “renommage” plus bas.

Méthode WP-CLI (la plus simple si disponible)

# Affiche le thème actif
wp theme list

# Active un thème par défaut installé (exemple)
wp theme activate twentytwentyfive

Docs officielles WP-CLI : wp theme activate

Méthode base de données (phpMyAdmin)

Dans la table wp_options (le préfixe peut être différent), modifiez :

template = twentytwentyfive (ou un autre thème présent)
stylesheet = twentytwentyfive

Si vous ne voyez pas le thème dans wp-content/themes, installez-le via FTP (copie du dossier du thème), ou via WP-CLI :

wp theme install twentytwentyfive --activate

Étape 2 — Cas Divi 5, Elementor, Avada : ce que ça change

Sur un site avec un page builder, changer de thème peut faire peur, mais pour un dépannage c’est souvent la meilleure preuve.

Divi 5 : si vous utilisez le thème Divi, repasser temporairement sur un thème par défaut peut casser le rendu front, mais l’objectif est de récupérer l’admin. Si vous utilisez Divi Builder plugin avec un autre thème, testez d’abord en désactivant uniquement le thème enfant (souvent le coupable).
Elementor : Elementor fonctionne avec la plupart des thèmes. Si l’admin est cassée, le souci vient plus souvent d’un plugin d’optimisation ou d’un thème surchargé que d’Elementor lui-même. Un test avec un thème par défaut est très parlant.
Avada : Avada (Fusion Builder) charge beaucoup de code. Une limite mémoire trop basse peut tuer l’admin. Si un switch de thème rétablit l’admin, regardez ensuite les erreurs dans les logs et la mémoire PHP.

Variante sans DB : renommer le thème actif

Où agir : FTP/SFTP → wp-content/themes.

Identifiez le dossier du thème actif (ex. divi, avada, mon-theme-enfant).
Renommez-le : divi → divi.off.
WordPress tentera de basculer sur un autre thème disponible.

Si aucun autre thème n’est présent, WordPress ne pourra pas basculer proprement. Dans ce cas, installez un thème par défaut via FTP ou WP-CLI.

Exemple de casse typique dans functions.php (AVANT/APRÈS)

Erreur courante : appeler une fonction de plugin (Elementor/Divi/Avada) alors que le plugin n’est pas chargé, ou au mauvais hook.

AVANT (cassé) : appel direct dès le chargement du thème (fatal si le plugin n’est pas actif).

<?php
// Mauvaise pratique : appeler une fonction de plugin sans vérifier qu'elle existe
elementor_do_something_admin_only();

APRÈS (corrigé) : on vérifie l’existence, et on attend le bon moment.

<?php
add_action('plugins_loaded', function () {
    // On vérifie que la fonction existe (plugin actif) avant d'appeler
    if (function_exists('elementor_do_something_admin_only')) {
        elementor_do_something_admin_only();
    }
});

Pourquoi ça corrige :

plugins_loaded s’exécute après le chargement des plugins. Si Elementor (ou autre) est actif, ses fonctions existent.
function_exists() évite une fatal error.

Solution 3 : Diagnostiquer par les logs (WP_DEBUG), WP-CLI et la base de données

Quand les méthodes “désactiver plugin/thème” ne suffisent pas, vous devez savoir quelle erreur se produit. Sur WordPress 6.9.4, le message “critical error” est volontairement vague. Les logs, eux, sont précis.

Activer WP_DEBUG proprement (sans afficher les erreurs aux visiteurs)

Où coller le code : dans wp-config.php, idéalement juste avant la ligne /* That's all, stop editing! */ (ou équivalent).

AVANT (souvent absent ou incomplet) :

<?php
// ... votre wp-config.php

APRÈS (configuration recommandée en prod pendant dépannage) :

<?php
// Active le mode debug WordPress
define('WP_DEBUG', true);

// Écrit les erreurs dans wp-content/debug.log
define('WP_DEBUG_LOG', true);

// N'affiche pas les erreurs à l'écran (évite de divulguer des chemins/infos sensibles)
define('WP_DEBUG_DISPLAY', false);

// Optionnel : évite que PHP affiche ses erreurs en dehors de WordPress
@ini_set('display_errors', '0');

Pourquoi c’est la bonne combinaison : vous collectez les erreurs sans les exposer publiquement (risque sécurité réel si un chemin serveur, une version, ou une requête s’affiche).

Doc officielle : Debug WordPress

Lire debug.log et identifier l’erreur utile

Où lire : wp-content/debug.log (via FTP/gestionnaire de fichiers).

Exemples d’erreurs qui bloquent l’admin :

PHP Fatal error:  Uncaught Error: Call to undefined function wp_get_environment_type()
in /wp-content/plugins/ancien-plugin/ancien-plugin.php:42

PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes)
in /wp-includes/class-wpdb.php on line 2345

PHP Fatal error:  Uncaught TypeError: strpos(): Argument #1 ($haystack) must be of type string, null given
in /wp-content/themes/mon-theme/functions.php:120

Ce que vous cherchez :

le fichier (plugin/thème) et la ligne ;
le type : Fatal error / TypeError / Parse error ;
si c’est une limite : mémoire, temps, permissions.

Fix “mémoire PHP insuffisante” (fréquent sur Divi/Avada + gros plugins)

Si votre log montre Allowed memory size exhausted, augmentez d’abord la mémoire côté hébergeur (panneau PHP). Ensuite, vous pouvez aussi définir une limite WordPress.

Où coller : wp-config.php.

<?php
// Augmente la mémoire côté WordPress (ne dépasse pas ce que l'hébergeur autorise)
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');

Pourquoi : WP_MEMORY_LIMIT s’applique surtout au front, WP_MAX_MEMORY_LIMIT à l’admin (qui consomme plus). Si l’hébergeur limite PHP à 128M, WordPress ne peut pas “forcer” au-delà.

Fix “boucle de redirection” (ERR_TOO_MANY_REDIRECTS)

Ce problème arrive souvent après activation HTTPS, changement de domaine, ou configuration Cloudflare/proxy. L’admin redirige vers une URL différente, et le navigateur boucle.

Vérification rapide : ouvrez https://votre-site.tld/wp-login.php en navigation privée. Si ça boucle, regardez :

si votre site est accessible en HTTP et HTTPS ;
si un plugin force HTTPS ;
si Cloudflare est en mode “Flexible” (souvent la source du problème).

Correctif robuste : forcer WP_HOME et WP_SITEURL temporairement dans wp-config.php.

Où coller : wp-config.php, avant “stop editing”.

<?php
// Fix temporaire : force l'URL du site (à adapter exactement à votre domaine)
define('WP_HOME', 'https://votre-site.tld');
define('WP_SITEURL', 'https://votre-site.tld');

Pourquoi : WordPress lit normalement ces valeurs depuis la base (options home et siteurl). En les définissant ici, vous neutralisez une valeur DB incorrecte le temps de corriger.

Une fois l’admin récupérée, corrigez proprement dans Réglages → Général, puis retirez ces define() si vous n’en avez plus besoin (sinon vous vous “bloquez” vous-même lors d’une migration future).

Fix 403/401 sur /wp-admin (permissions, WAF, Basic Auth)

Quand /wp-admin renvoie 403, le PHP ne s’exécute parfois même pas. Le problème est alors côté serveur.

Permissions : dossiers en 755, fichiers en 644 (valeurs classiques). Un 777 peut déclencher un blocage sécurité chez certains hébergeurs.
WAF / ModSecurity / Cloudflare : un faux positif bloque wp-login.php (surtout si vous avez beaucoup de tentatives de login ou un plugin de sécurité).
Restriction IP : règle dans un fichier serveur (Apache/Nginx) ou dans un plugin de sécurité.

Test simple : essayez depuis un autre réseau (partage 4G). Si ça marche, vous avez probablement un blocage IP/WAF.

Si vous avez un fichier .htaccess (serveur Apache/LiteSpeed), une règle peut bloquer l’admin. Pour tester sans tout casser :

renommez .htaccess en .htaccess.off
testez /wp-admin
si ça revient, régénérez les permaliens dès que vous récupérez l’admin (Réglages → Permaliens → Enregistrer)

Note : sur Nginx, il n’y a pas de .htaccess. Le blocage se trouve dans la conf serveur.

Utiliser WP-CLI pour désactiver sans FTP (solution “propre”)

WP-CLI est souvent disponible sur des hébergements WordPress managés. Quand vous l’avez, c’est un gain de temps énorme.

# Désactive tous les plugins
wp plugin deactivate --all

# Active un plugin précis
wp plugin activate nom-du-plugin

# Passe sur un thème par défaut
wp theme activate twentytwentyfive

Docs officielles : wp plugin deactivate

Cas “base de données” : Error establishing a database connection

Si vous voyez ce message, l’admin et le front sont souvent KO.

Vérifications :

Dans wp-config.php : DB_NAME, DB_USER, DB_PASSWORD, DB_HOST (typo fréquente après migration).
Statut MySQL/MariaDB dans le panneau hébergeur.
Disque plein / quotas : j’ai déjà vu une DB “down” parce que le stockage était saturé.

Référence officielle : Error establishing a database connection

Vérifications après correction

Une fois /wp-admin de retour, validez que vous n’avez pas seulement “caché” le problème.

Connectez-vous et vérifiez que le Tableau de bord charge sans erreur.
Ouvrez une page de réglages (ex. Réglages → Général) : si ça casse ici, c’est parfois un plugin qui ajoute des champs.
Testez l’éditeur : Articles → Ajouter. Si l’éditeur de blocs charge mal, suspectez un plugin d’optimisation JS/CSS ou un blocage REST API.
Videz les caches : plugin de cache, cache serveur (LiteSpeed/Varnish), CDN (Cloudflare), puis cache navigateur.
Si vous avez activé WP_DEBUG : relisez debug.log et corrigez les warnings persistants, puis désactivez le debug.

Quand tout est stable, remettez :

<?php
// À remettre une fois le dépannage terminé
define('WP_DEBUG', false);

Si ça ne marche toujours pas

Voici une procédure que j’applique quand le site résiste et que les causes se cumulent (cache + plugin + serveur).

Étape 1 — Confirmer si le PHP s’exécute

Si vous avez une 403/401, le PHP ne s’exécute probablement pas → problème serveur/WAF.
Si vous avez une 500, le PHP s’exécute mais plante → lire les logs.

Étape 2 — Isoler “core vs wp-content”

Test très parlant : désactivez plugins + bascule thème (Solutions 1 et 2). Si l’admin est toujours KO :

suspectez un fichier core corrompu, un problème PHP, une extension PHP manquante, ou une config serveur.

Sur un hébergement, j’ai déjà vu un OPcache bloqué qui servait un ancien fichier PHP après mise à jour. Un redémarrage PHP-FPM résout parfois instantanément.

Étape 3 — Vérifier les versions (WordPress 6.9.4, PHP 8.1+)

Si votre hébergeur est en PHP 7.4/8.0, vous êtes en zone à problèmes. Visez PHP 8.1+ (8.2/8.3 sont courants en 2026).
Un plugin ancien peut casser en PHP 8.1 (TypeError). Le log vous le dira.

Référence PHP : PHP : versions supportées

Étape 4 — Vérifier REST API (admin qui “tourne”)

Quand l’admin s’affiche mais que tout est cassé (médias, éditeur, menus), ouvrez la console du navigateur (F12) et cherchez des erreurs réseau vers :

/wp-json/
admin-ajax.php

Un 403/401 sur /wp-json/ vient souvent d’un plugin de sécurité, d’un WAF, ou d’un réglage “désactiver REST API” (mauvaise idée sur WordPress moderne).

Doc REST API : REST API Handbook

Étape 5 — Vérifier la réécriture (permalinks) et .htaccess

Si le login marche mais /wp-admin renvoie 404/403 selon les pages, suspectez des règles de réécriture incohérentes.

Test : renommez .htaccess (Apache) puis testez.
Si l’admin revient : régénérez les permaliens dès que possible.

Étape 6 — Vérifier la sécurité (malware)

Si le problème apparaît “sans raison”, avec des redirections bizarres, ou si des fichiers inconnus sont apparus :

scannez wp-content (hébergeur, Wordfence, ou outil dédié) ;
vérifiez les comptes admin (utilisateurs inconnus) ;
changez les mots de passe (WP + FTP + DB).

Risque : un malware peut bloquer l’admin pour éviter que vous le supprimiez. Dans ce cas, travaillez sur une copie, puis nettoyez méthodiquement.

Pièges et erreurs courantes

Symptôme	Cause probable	Solution recommandée
Vous modifiez un fichier et tout empire	Pas de sauvegarde / modification sur production	Restaurer backup, travailler sur une copie
Erreur PHP “Parse error”	Parenthèse/point-virgule manquant dans `functions.php`	Corriger la syntaxe, utiliser un éditeur avec coloration
Admin KO après ajout d’un snippet	Code collé dans le mauvais fichier (core, plugin, mauvais thème)	Mettre le code dans un plugin custom ou mu-plugin
Vous avez “désactivé un plugin”, mais l’erreur reste	Cache serveur/CDN/b navigateur	Purger cache plugin + serveur + CDN + navigateur
Erreur “Call to undefined function”	Fonction appelée avant chargement (hook inadapté)	Utiliser `plugins_loaded` / `init` + `function_exists`
Login en boucle	URL HTTP/HTTPS incohérentes, cookies	Fix `WP_HOME`/`WP_SITEURL`, vider cookies/cache
403 uniquement sur wp-admin	WAF/ModSecurity, restriction IP	Tester autre réseau, whitelist, logs WAF
“Allowed memory size exhausted”	Limite mémoire trop basse	Augmenter mémoire PHP + `WP_MAX_MEMORY_LIMIT`
Code d’un vieux tutoriel ne marche plus	Incompatibilité PHP 8.1+ / WordPress 6.9.4	Mettre à jour le code, lire logs, remplacer fonctions obsolètes

Variante / alternative

Méthode sans code : Health Check (après récupération minimale)

Quand vous avez récupéré l’accès au moins une fois, installez Health Check & Troubleshooting. Son mode dépannage vous permet de désactiver plugins et thème uniquement pour vous, sans impacter les visiteurs.

Je l’utilise souvent sur des sites à fort trafic : vous dépannez sans “casser” le front en plein milieu de journée.

Méthode avancée : réinstaller les fichiers core WordPress (sans toucher à wp-content)

Si vous suspectez des fichiers WordPress corrompus (mise à jour interrompue, fichiers manquants), vous pouvez réuploader les dossiers wp-admin et wp-includes depuis l’archive officielle correspondant à votre version.

Téléchargez WordPress depuis wordpress.org/download
Remplacez uniquement wp-admin et wp-includes sur le serveur
Ne remplacez pas wp-content ni wp-config.php

Si vous voulez vérifier la version exacte, regardez wp-includes/version.php (lecture seule) ou le fichier readme.html si présent.

Éviter ce problème à l’avenir

Les pannes d’admin reviennent quand les mises à jour se font “en aveugle” et que le site n’a pas de filet de sécurité.

Bonnes pratiques simples (et qui changent tout)

Environnement de staging : testez mises à jour et snippets avant production.
Backups automatiques (quotidiens minimum) + test de restauration.
Limiter les plugins d’optimisation empilés : un seul plugin de cache, pas trois.
Éviter de coller du code dans le thème : préférez un plugin custom ou un mu-plugin.
Surveiller les logs : un warning aujourd’hui devient une fatal error après une montée de PHP.

Créer un plugin “snippets” maison (plus fiable que functions.php)

Quand vous mettez vos personnalisations dans un plugin, vous pouvez le désactiver facilement sans casser le thème. C’est une séparation propre.

Où coller : créez wp-content/plugins/mes-personnalisations/mes-personnalisations.php, puis activez-le dès que l’admin fonctionne.

<?php
/**
 * Plugin Name: Mes personnalisations
 * Description: Personnalisations stables, indépendantes du thème.
 * Version: 1.0.0
 */

if (!defined('ABSPATH')) {
    exit;
}

// Exemple : petit ajustement sans risque, chargé au bon hook.
add_action('admin_init', function () {
    // Placez ici des personnalisations admin, testées en staging.
});

Surveiller la santé du site (Site Health)

Le rapport “Santé du site” (Outils → Santé du site) détecte des problèmes de configuration (version PHP, extensions, etc.). Quand je reprends un site instable, c’est un des premiers écrans que je consulte.

Référence : Site Health API

Ressources

Questions fréquentes

Je peux accéder au front, mais pas à wp-admin. C’est normal ?

Oui. L’admin charge plus de scripts, plus d’AJAX/REST API, et déclenche des hooks spécifiques. Un plugin peut casser uniquement l’admin. Commencez par désactiver les plugins (Solution 1).

J’ai renommé le dossier plugins et ça ne change rien. Je fais quoi ensuite ?

Basculez le thème (Solution 2), puis activez WP_DEBUG_LOG et lisez wp-content/debug.log (Solution 3). Si l’erreur persiste avec plugins désactivés + thème par défaut, suspectez serveur/core.

Est-ce risqué d’activer WP_DEBUG en production ?

Oui si vous affichez les erreurs à l’écran. Utilisez la configuration recommandée : log activé, affichage désactivé. Et désactivez-le dès que le diagnostic est terminé.

Pourquoi je retombe sur la page de login après connexion ?

Souvent un problème d’URL (HTTP/HTTPS), de cookies, ou de cache. Testez en navigation privée, purgez le cache, puis forcez temporairement WP_HOME/WP_SITEURL si nécessaire.

Je suis sur Divi 5 / Avada et l’admin rame puis plante. C’est lié ?

Souvent, oui, via la mémoire PHP et le temps d’exécution. Regardez debug.log pour un Allowed memory size exhausted. Augmentez la mémoire côté hébergeur et via WP_MAX_MEMORY_LIMIT.

Un 403 sur wp-admin, c’est forcément un hack ?

Non. Le plus fréquent est un WAF trop strict, une restriction IP, ou des permissions. Testez depuis un autre réseau et consultez les logs de sécurité/hébergement.

Puis-je “réinstaller WordPress” pour réparer wp-admin ?

Oui, mais proprement : remplacez wp-admin et wp-includes par les fichiers officiels, sans toucher à wp-content ni wp-config.php. Faites une sauvegarde avant.

Quelle est la méthode la plus rapide si j’ai WP-CLI ?

wp plugin deactivate --all, puis test. Ensuite wp theme activate twentytwentyfive si besoin. WP-CLI vous fait gagner un temps énorme sur l’isolement.

Je peux corriger un plugin cassé moi-même ?

Parfois, oui (erreur de syntaxe, compat PHP). Mais si c’est un plugin premium, le plus sûr est de le mettre à jour, revenir à une version stable, ou contacter le support. Ne modifiez pas un plugin sans méthode (vous perdrez les changements à la prochaine mise à jour).