Une méthode progressive pour remettre un site en ligne sans désactiver tout au hasard, écraser des données récentes ou masquer la cause réelle de la panne.
Vous mettez à jour une extension, un thème ou WordPress. Quelques secondes plus tard, l’administration ne répond plus. Selon les cas, le site affiche une page blanche, une erreur 500, le message « Une erreur critique est survenue » ou reste bloqué en maintenance.
Le premier réflexe est souvent de restaurer immédiatement une sauvegarde ou de renommer tout le dossier des extensions. Ces actions peuvent fonctionner, mais elles détruisent aussi des indices utiles. Sur une boutique ou un site qui reçoit des formulaires, une restauration précipitée peut en plus effacer des commandes ou des messages arrivés depuis la dernière sauvegarde.
Une panne post-mise à jour se traite mieux comme un incident : figer l’état, collecter les preuves, isoler la couche fautive, appliquer le plus petit correctif possible, puis vérifier le retour à la normale.
Voici un protocole utilisable même lorsque vous n’avez plus accès à wp-admin. Il suppose que vous disposez au minimum d’un accès SFTP ou au gestionnaire de fichiers de l’hébergeur. Les étapes en ligne de commande sont facultatives, mais plus rapides si WP-CLI et SSH sont disponibles.
1. Ne touchez plus à rien pendant cinq minutes
Avant de « tester des choses », notez quatre informations :
• l’heure exacte de la panne ;
• la dernière action effectuée ;
• le message visible et le code HTTP éventuel ;
• les zones touchées : site public, administration, API REST, tâches planifiées.
Testez ensuite le site dans une fenêtre privée, sans être connecté. Un administrateur et un visiteur anonyme ne reçoivent pas toujours la même réponse : les caches de page excluent souvent les utilisateurs connectés.
Cette comparaison donne déjà un indice :
| Symptôme observé | Première piste à vérifier |
|---|---|
| « Briefly unavailable for scheduled maintenance » | fichier .maintenance resté à la racine |
| page blanche ou erreur critique | erreur fatale PHP dans une extension ou un thème |
| erreur 500 partout | PHP, serveur web, règle .htaccess ou code chargé très tôt |
| administration cassée, site public accessible | extension d’administration, permissions ou cache navigateur |
| version correcte connecté, ancienne version en navigation privée | cache de page, cache hébergeur ou CDN |
| fichier PHP remplacé, ancien comportement toujours actif | OPcache PHP ou mauvais fichier déployé |
Évitez pour l’instant les mises à jour supplémentaires. Chaque modification ajoute une variable au diagnostic.
2. Sauvegardez aussi l’état cassé
Une sauvegarde saine permet de revenir en arrière. Une copie de l’état cassé permet de comprendre ce qui s’est passé. Les deux n’ont pas le même rôle.
Avant toute désactivation ou restauration, copiez au minimum :
• wp-content/ ;
• wp-config.php ;
• la base de données ;
• les journaux PHP et wp-content/debug.log s’ils existent.
Stockez ces fichiers hors du répertoire public quand l’hébergement le permet. Depuis la racine WordPress, avec WP-CLI :
wp db export ../incident-$(date +%Y%m%d-%H%M).sql --skip-plugins --skip-themes
tar -czf ../incident-fichiers-$(date +%Y%m%d-%H%M).tar.gz wp-content wp-config.php
Sur un site transactionnel, cette étape est essentielle. Restaurer une base de données ancienne peut supprimer des commandes WooCommerce, des comptes, des commentaires ou des soumissions de formulaires reçus entre-temps.
3. Sortez d’abord d’un mode maintenance bloqué
Pendant une mise à jour, WordPress crée un fichier .maintenance à sa racine. WordPress ne le considère normalement actif que pendant une courte période, mais un processus interrompu ou une couche de cache peut prolonger le message côté visiteur.
Avec WP-CLI, contrôlez son état puis désactivez-le :
wp maintenance-mode status --skip-plugins --skip-themes
wp maintenance-mode deactivate --skip-plugins --skip-themesSans WP-CLI, affichez les fichiers cachés dans votre client SFTP et renommez temporairement .maintenance en .maintenance.bak.
Rechargez ensuite une URL en navigation privée. Si la page de maintenance disparaît mais laisse place à une erreur fatale, vous avez seulement révélé la panne sous-jacente : poursuivez le diagnostic.
4. Activez un journal de debug qui ne s’affiche pas aux visiteurs
Le message public de WordPress est volontairement vague. Le nom du fichier ou de la fonction fautive se trouve généralement dans les journaux.
Dans wp-config.php, avant la ligne de fin qui indique d’arrêter l’édition, ajoutez temporairement :
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
Rechargez une seule fois la page en erreur, puis consultez les dernières lignes de wp-content/debug.log :
tail -n 100 wp-content/debug.log
Cherchez la première erreur fatale, pas les dizaines d’avertissements qui peuvent la suivre. Un chemin comme celui-ci est particulièrement instructif :
wp-content/plugins/nom-extension/...
wp-content/themes/nom-theme/...Si debug.log reste vide, consultez le journal PHP proposé par l’hébergeur. Une erreur de syntaxe dans wp-config.php, un problème PHP-FPM ou une panne qui survient avant le chargement complet de WordPress peut ne jamais atteindre le journal WordPress.
Le debug ne doit pas rester activé en production. Les journaux peuvent contenir des chemins serveur, des requêtes ou d’autres informations sensibles. Conservez une copie pour le post-mortem, puis désactivez les constantes et supprimez le fichier public une fois l’incident clos.
5. Isolez l’extension fautive, d’abord de façon ciblée
Si le journal désigne clairement une extension, désactivez uniquement celle-ci :
wp plugin deactivate nom-extension --skip-plugins --skip-themesRechargez le site. S’il revient, ne réactivez pas immédiatement l’extension. Vérifiez d’abord sa version, la version de PHP requise, son journal de changements et l’existence d’un correctif.
Si aucune extension n’est identifiable, désactivez-les toutes :
wp plugin deactivate --all --skip-plugins --skip-themes
Puis réactivez-les par petits groupes. Une recherche par moitié est plus rapide qu’une réactivation une par une lorsque le site possède beaucoup d’extensions : activez la moitié, testez, puis continuez dans le groupe qui reproduit la panne.
Sans WP-CLI
Renommez d’abord le dossier de l’extension suspecte dans wp-content/plugins/. Si vous ne connaissez pas la coupable, renommez plugins en plugins-off, ouvrez l’administration pour que WordPress constate leur absence, puis rendez au dossier son nom d’origine. Les extensions pourront ensuite être réactivées progressivement.
Cette méthode ne neutralise pas tout ce qui peut charger du code. Si la panne persiste, contrôlez aussi :
• wp-content/mu-plugins/ ;
• les drop-ins comme object-cache.php et advanced-cache.php ;
• le code personnalisé ajouté dans le thème ou via une extension de snippets.
Ne supprimez aucun dossier tant que la cause n’est pas confirmée. Un renommage est réversible ; une suppression ne l’est pas toujours.
6. Testez le thème avec un thème par défaut déjà installé
Si les extensions sont hors de cause, vérifiez les thèmes disponibles :
wp theme list --status=installed --skip-plugins --skip-themes
Activez ensuite un thème par défaut présent sur le serveur :
wp theme activate twentytwentysix --skip-plugins --skip-themesAdaptez le slug au thème réellement installé. Ne renommez pas le thème actif avant d’avoir vérifié qu’un thème de secours fonctionnel est disponible.
Si le changement corrige la panne, comparez la version cassée à la sauvegarde précédente. Une édition manuelle incomplète, un fichier transféré partiellement ou une incompatibilité PHP peut produire les mêmes symptômes qu’une mauvaise mise à jour.
7. Vérifiez l’intégrité du cœur sans le réinstaller à l’aveugle
Si la panne subsiste avec les extensions désactivées et un thème par défaut, vérifiez les fichiers du cœur :
wp core verify-checksums --include-rootWP-CLI compare les fichiers installés aux sommes de contrôle officielles de la version de WordPress utilisée. L’option –include-root signale également des fichiers inattendus à la racine.
Une différence ne prouve pas automatiquement une attaque : un transfert interrompu ou une modification manuelle peut aussi l’expliquer. En revanche, elle indique précisément quoi examiner avant de réinstaller le cœur.
Contrôlez également :
php -v
wp core version
wp plugin list
wp theme list
Une mise à jour peut révéler une incompatibilité avec la version de PHP, une extension PHP manquante ou une limite de mémoire. Ne doublez pas arbitrairement toutes les limites : le journal doit d’abord montrer que la mémoire ou le temps d’exécution est réellement en cause.
8. Distinguez les caches avant de tout purger
« Vider le cache » ne désigne pas une opération unique. Un site WordPress peut cumuler :
1. le cache du navigateur pour les fichiers CSS et JavaScript ; 2. un CDN ou proxy inverse ; 3. un cache de page fourni par une extension ou l’hébergeur ; 4. un cache objet persistant, par exemple Redis ; 5. OPcache, qui conserve le bytecode PHP compilé.
Commencez par comparer les en-têtes HTTP :
curl -sI https://exemple.fr/ | grep -Ei 'age|cache|etag|last-modified|cf-|litespeed'Quelques indices fréquents : Age, CF-Cache-Status, X-LiteSpeed-Cache, X-Cache ou X-Proxy-Cache. Les noms varient selon l’infrastructure.
Si seul le HTML public est ancien, purgez la page concernée dans le cache de page et le CDN. Si le HTML est à jour mais pas le CSS ou le JavaScript, changez la version de l’asset plutôt que de purger tout le site.
WordPress prévoit justement un paramètre de version dans wp_enqueue_style() et wp_enqueue_script(). Pour un thème sur mesure, filemtime() permet de changer automatiquement l’URL lorsque le fichier change :
$css_file = get_stylesheet_directory() . '/assets/css/site.css';
wp_enqueue_style(
'site-css',
get_stylesheet_directory_uri() . '/assets/css/site.css',
array(),
filemtime( $css_file )
);N’utilisez pas time() à la place : l’URL changerait à chaque requête et supprimerait tout bénéfice du cache.
La commande suivante ne vide que le cache objet WordPress :
wp cache flushElle ne purge ni le navigateur, ni le CDN, ni forcément le cache de page de l’hébergeur. Sur un multisite utilisant un cache objet persistant partagé, elle peut affecter tous les sites et provoquer une pointe de charge pendant la reconstruction du cache.
Enfin, si un fichier PHP présent sur le serveur contient bien votre correctif mais que l’ancien comportement persiste même après purge de page, suspectez OPcache. Le piège classique consiste à lancer opcache_reset() depuis PHP CLI ou WP-CLI : le processus CLI utilise souvent un cache distinct de celui de PHP-FPM. Préférez le bouton prévu par l’hébergeur ou un redémarrage contrôlé du service PHP. N’exposez pas durablement un script public de réinitialisation.
9. Restaurez uniquement lorsque le diagnostic le justifie
Une restauration complète est pertinente si :
• plusieurs fichiers sont corrompus ;
• une compromission est confirmée ;
• la mise à jour a modifié la base de façon incompatible ;
• le retour arrière ciblé a échoué ;
• le temps de rétablissement devient plus important que l’analyse immédiate.
Préservez d’abord la copie de l’état cassé. Sur une boutique, restaurez de préférence les fichiers sans écraser la base récente, sauf si vous disposez d’un plan pour réconcilier les commandes et autres écritures arrivées après la sauvegarde.
Après la restauration, ne vous contentez pas d’une page d’accueil qui répond en 200. Vérifiez :
• une page publique en navigation privée ;
• la connexion et l’administration ;
• l’enregistrement d’un brouillon ;
• les formulaires ou le parcours de commande ;
• l’API REST ;
• les tâches planifiées ;
• les journaux PHP ;
• l’affichage mobile et les fichiers statiques.
10. Réouvrez le site puis rédigez un post-mortem court
Une fois la cause corrigée :
wp maintenance-mode deactivate --skip-plugins --skip-themesDésactivez le debug public, purgez uniquement les couches concernées et testez comme un visiteur anonyme.
Consignez ensuite sur une page :
• le composant et la version concernés ;
• l’heure de début et de fin ;
• le premier message d’erreur utile ;
• la cause racine ;
• le correctif appliqué ;
• la mesure préventive décidée.
La prévention peut être simple : conserver un thème par défaut, tester les mises à jour sur une préproduction, vérifier les sauvegardes par une restauration réelle, versionner les assets, documenter les purges de cache et surveiller les erreurs fatales après chaque déploiement.
La règle à retenir : réduire l’incertitude à chaque étape
Un bon diagnostic ne consiste pas à multiplier les manipulations jusqu’à ce que le site « remarche ». Chaque étape doit répondre à une question : la maintenance est-elle bloquée ? Une extension est-elle responsable ? Le thème est-il en cause ? Les fichiers du cœur sont-ils intègres ? La nouvelle réponse est-elle masquée par un cache ?
En sauvegardant d’abord, en lisant les journaux et en appliquant un changement réversible à la fois, vous réduisez le risque de transformer une panne simple en perte de données — et vous conservez assez d’indices pour éviter qu’elle se reproduise.
Sources et documentation
Débogage dans WordPress — documentation développeur WordPress
https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/
Mode maintenance — référence WordPress
https://developer.wordpress.org/reference/functions/wp_is_maintenance_mode/
Commandes WP-CLI de maintenance
https://developer.wordpress.org/cli/commands/maintenance-mode/
Désactiver une extension avec WP-CLI
https://developer.wordpress.org/cli/commands/plugin/deactivate/
Activer un thème avec WP-CLI
https://developer.wordpress.org/cli/commands/theme/activate/
Vérifier les sommes de contrôle du cœur
https://developer.wordpress.org/cli/commands/core/verify-checksums/
Les différentes couches de cache WordPress
https://developer.wordpress.org/advanced-administration/performance/cache/
Référence de wp_enqueue_style()
https://developer.wordpress.org/reference/functions/wp_enqueue_style/
Commande wp cache flush et précaution multisite
https://developer.wordpress.org/cli/commands/cache/flush/
Référence PHP de opcache_reset()
https://www.php.net/manual/fr/function.opcache-reset.php
