Réparer un site WordPress cassé : le guide complet pour le faire soi-même

Un site WordPress « cassé » recouvre des situations très différentes : page blanche, message « Il y a eu une erreur critique sur ce site », affichage sans style, éditeur qui refuse d'enregistrer, administration inaccessible. Le point commun, c'est qu'une mise à jour, une extension, un thème, un fichier modifié ou une base abîmée empêchent WordPress de s'exécuter.

Ce guide décrit les réparations que vous pouvez mener vous-même, avec un accès FTP ou SFTP, le panneau de votre hébergeur et, quand vous l'avez, WP-CLI. Les commandes et les valeurs citées viennent de la documentation officielle de WordPress.org et de WP-CLI, liens en fin d'article. Pour identifier votre panne parmi les plus courantes, voyez notre catalogue des pannes WordPress fréquentes.

Avant toute chose : sauvegarder le site cassé

Le réflexe habituel est de bricoler tout de suite. C'est la meilleure façon de transformer une panne réparable en perte de données. Avant de toucher au moindre fichier, copiez l'état actuel du site, aussi cassé soit-il. Depuis un accès SSH :

tar -czf ~/sauvegarde-fichiers.tar.gz ~/public_html
mysqldump -u UTILISATEUR -p NOM_DE_LA_BASE > ~/sauvegarde-base.sql

Avec WP-CLI, l'export de la base se réduit à une commande, qui lit les identifiants dans wp-config.php :

wp db export ~/sauvegarde-base.sql

Sans SSH, faites la même chose à la main : téléchargez tout le dossier du site en FTP, et exportez la base depuis phpMyAdmin en cochant toutes les tables et le format SQL. La documentation WordPress recommande les options « Add DROP TABLE » et « IF NOT EXISTS », pour que le fichier soit réimportable par-dessus une base existante. Notre guide des sauvegardes WordPress explique quoi automatiser après la réparation.

Identifier la panne avant de réparer

Réparer au hasard fait perdre des heures. Trois outils gratuits vous donnent presque toujours la cause en quelques minutes.

Lire l'erreur exacte avec WP_DEBUG

Une page blanche ne dit rien, mais le journal des erreurs PHP dit tout. Ajoutez ces trois lignes dans wp-config.php, juste avant la ligne /* That's all, stop editing! */ :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

La documentation précise que WP_DEBUG_LOG n'a aucun effet si WP_DEBUG n'est pas à true, et que le journal est écrit dans debug.log, dans le dossier de contenu, en général wp-content/debug.log. Rechargez la page cassée puis ouvrez ce fichier : la dernière erreur fatale nomme le fichier et la ligne responsables, donc l'extension ou le thème en cause. Repassez ensuite WP_DEBUG à false, un journal actif en production expose des chemins internes.

Utiliser le mode de récupération de WordPress

Depuis WordPress 5.2, une erreur fatale déclenche automatiquement le mode de récupération. L'écran public affiche « Il y a eu une erreur critique sur ce site » et un courriel part vers l'adresse de l'administrateur avec un lien de connexion spécial. Ce lien met en pause l'extension ou le thème fautif pour votre seule session : vous vous connectez, l'avertissement désigne le composant en cause, vous le désactivez, puis vous quittez le mode de récupération.

La documentation signale un piège fréquent : si le site utilise une extension pour l'envoi des courriels et que l'erreur survient avant son chargement, le message part directement du serveur web et finit souvent en indésirable. Ne concluez donc pas trop vite que le mode de récupération n'a pas fonctionné. Notre article sur l'écran blanc WordPress détaille les cas où aucun message n'apparaît.

Isoler l'extension ou le thème fautif

Si vous n'accédez plus à l'administration, la désactivation se fait par le système de fichiers. Renommer le dossier d'une extension suffit à la désactiver : la documentation officielle donne l'exemple de wp-content/plugins/hello-dolly renommé en wp-content/plugins/hello-dolly-1. Pour tout couper d'un coup, renommez le dossier plugins lui-même :

mv wp-content/plugins wp-content/plugins-hors-service

Si le site revient, remettez le nom d'origine puis réactivez les extensions une par une. Avec WP-CLI :

wp plugin deactivate --all
wp theme activate <theme-par-defaut>
wp plugin activate <nom-de-lextension>

Le passage à un thème par défaut règle la question du thème. Notre guide sur la désactivation des extensions par FTP détaille la manipulation quand vous n'avez ni SSH ni administration.

Restaurer une sauvegarde : la réparation la plus rapide

Si le site fonctionnait hier et plus aujourd'hui, la restauration est presque toujours plus rapide que le diagnostic. Trois sources possibles, par ordre de simplicité.

La sauvegarde de votre hébergeur

La plupart des hébergeurs mutualisés conservent des sauvegardes quotidiennes sur plusieurs jours, restaurables depuis leur panneau. Vérifiez deux points avant de cliquer : la date exacte du point de restauration, et ce qu'il contient. Certains hébergeurs restaurent les fichiers et la base ensemble, d'autres séparément. Restaurer les fichiers d'hier avec la base d'aujourd'hui donne un site incohérent.

La sauvegarde d'une extension

Si une extension de sauvegarde tourne sur le site, son archive contient en général les fichiers et un export SQL. Le point délicat est que la restauration passe par l'administration : si celle-ci est inaccessible, extrayez l'archive à la main et importez le SQL par phpMyAdmin.

La restauration manuelle, fichiers puis base

L'ordre compte, et la documentation WordPress l'indique clairement : restaurez les fichiers d'abord, puis importez la base.

mysql -u UTILISATEUR -p NOM_DE_LA_BASE < sauvegarde-base.sql

Ou, avec WP-CLI, wp db import sauvegarde-base.sql. Par phpMyAdmin, sélectionnez la base, ouvrez l'onglet d'import et envoyez le fichier SQL. Si les identifiants de la base ont changé entre-temps, par exemple après un déménagement, mettez wp-config.php en accord avec eux : c'est la seule modification que la documentation demande explicitement après une restauration.

Réparer après une mise à jour ratée

Une mise à jour interrompue, un transfert FTP coupé, une incompatibilité entre une extension et une nouvelle version de PHP : le résultat est un site à moitié à jour, donc cassé. La réparation consiste à remettre des fichiers d'origine à la place des fichiers abîmés. Notre page sur les problèmes de mise à jour WordPress reprend les cas les plus courants.

Réinstaller le cœur de WordPress

La procédure manuelle décrite par la documentation tient en quelques gestes : sauvegarder la base et les fichiers, désactiver toutes les extensions, télécharger l'archive depuis wordpress.org, supprimer les anciens fichiers du cœur, puis envoyer les nouveaux. Elle insiste sur ce qu'il ne faut surtout pas supprimer : wp-config.php, le dossier wp-content, le fichier .htaccess s'il contient vos propres règles, et robots.txt si le site est à la racine du domaine. Vous remplacez donc wp-admin, wp-includes et les fichiers PHP de la racine, rien d'autre. WordPress propose ensuite de mettre la base à jour à votre prochaine connexion.

Avec WP-CLI, la même opération se réduit à une commande, dont l'option --force « écrase les fichiers existants » et --skip-content télécharge WordPress « sans les thèmes et extensions par défaut » :

wp core download --force --skip-content

Réinstaller un thème ou une extension

Même principe : supprimer le dossier abîmé et remettre la version d'origine. En FTP, supprimez wp-content/plugins/nom-de-lextension puis renvoyez le dossier extrait de l'archive officielle. Les réglages ne sont pas perdus, ils vivent dans la base. Avec WP-CLI, l'option --force « écrase la version installée de l'extension, sans demander de confirmation » :

wp plugin install nom-de-lextension --force
wp theme install nom-du-theme --force

Revenir temporairement à une version antérieure

Quand une nouvelle version d'extension casse le site, les versions précédentes restent téléchargeables depuis la fiche de l'extension sur wordpress.org, dans la vue avancée. En ligne de commande :

wp plugin install nom-de-lextension --version=2.4.1 --force

Traitez ce retour en arrière comme une mesure d'attente : la documentation rappelle que garder du vieux code n'est pas une solution, la version à jour étant celle qui reçoit les correctifs de sécurité. Signalez le bogue à l'éditeur et remettez la version courante dès qu'un correctif sort.

Réparer la base de données

Une table abîmée se manifeste par des pages qui disparaissent, des réglages qui ne s'enregistrent plus ou une erreur mentionnant une table. Ne confondez pas : « Erreur lors de la connexion à la base de données » n'est pas une corruption mais un problème d'identifiants, de serveur ou de droits, traité sur notre page erreur de connexion à la base de données.

WordPress embarque un outil de réparation, désactivé par défaut. Ajoutez dans wp-config.php :

define( 'WP_ALLOW_REPAIR', true );

Puis ouvrez /wp-admin/maint/repair.php sur votre domaine : la page propose de réparer la base, ou de la réparer et de l'optimiser. Avec WP-CLI, la commande wp db repair « lance l'utilitaire mysqlcheck avec --repair=true », avec les identifiants déclarés dans wp-config.php.

Réparer les permaliens et le fichier .htaccess

Des pages en erreur 404 alors que l'accueil s'affiche : le symptôme désigne presque toujours les règles de réécriture. Sur Apache, WordPress modifie .htaccess pour gérer les permaliens, et le bloc par défaut est celui-ci :

# BEGIN WordPress
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

La réparation la plus simple consiste à ouvrir Réglages puis Permaliens et à enregistrer sans rien changer : WordPress réécrit le bloc si le fichier est modifiable. Sans administration, remplacez le contenu de .htaccess par le bloc ci-dessus, en gardant vos règles personnelles hors des marqueurs BEGIN et END. Sur nginx, il n'y a pas de .htaccess : les règles vivent dans la configuration du serveur, et seul l'hébergeur peut les corriger.

Réparer les permissions de fichiers

Des permissions trop restrictives cassent les envois de médias et les mises à jour ; des permissions trop larges ouvrent le site. La documentation WordPress ne donne pas une valeur unique, parce que « les permissions diffèrent d'un hébergeur à l'autre », et conseille de « commencer avec des réglages peu permissifs comme 744, puis de remonter jusqu'à ce que cela fonctionne ». Pour les hébergements en suexec, elle indique des valeurs précises : 755 ou 750 pour les dossiers, 644 ou 640 pour les fichiers, 440 ou 400 pour wp-config.php. Pour les appliquer depuis la racine du site :

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 440 wp-config.php

La documentation est catégorique sur le 777 : « n'utilisez 777 que si c'est nécessaire, et si possible pour une durée limitée ». Un dossier en 777 laisse n'importe quel processus du serveur écrire chez vous : c'est la porte d'entrée classique d'un fichier malveillant.

Réparer un thème enfant ou un extrait de code cassé

Beaucoup de sites cassent après l'ajout d'un extrait de code dans le functions.php du thème enfant. Une accolade oubliée, une fonction déclarée deux fois : le site tombe en erreur fatale dès le chargement. La réparation est immédiate en FTP, ouvrez wp-content/themes/votre-theme-enfant/functions.php et retirez le dernier bloc ajouté. En SSH, la vérification de syntaxe évite les allers-retours :

php -l wp-content/themes/votre-theme-enfant/functions.php

Autre panne classique : la disparition du fichier style.css ou de son en-tête, qui déclare le thème parent. Sans cet en-tête, WordPress ne reconnaît plus le thème et l'affichage part en morceaux.

Quand la réparation dépasse le bricolage

Faire soi-même a du sens tant que la panne est identifiée et que le site reste secondaire. Trois situations changent le calcul.

• Le temps passé coûte plus que l'intervention. Une soirée et une matinée à chercher, pour un site qui rapporte, dépassent vite le prix d'un forfait.
• Le risque de perte est réel. Sans sauvegarde exploitable, chaque manipulation peut détruire des commandes ou des articles. C'est le moment d'arrêter.
• La panne cache autre chose. Des fichiers modifiés que vous n'avez pas touchés, un administrateur inconnu, un site qui recasse après chaque réparation : c'est une compromission, pas un bogue.

Notre équipe répare et sécurise des sites WordPress depuis 2016. Le diagnostic est gratuit et rendu sous 12 heures, le prix de l'intervention est fixe et annoncé avant de commencer, à 350 €, et il vous est remboursé si nous échouons. Selon votre situation, voyez notre service de réparation de site WordPress ou, si le site est hors ligne, notre dépannage WordPress en urgence.

Sources

Pages consultées le 7 septembre 2026.

• WordPress Developer Resources, « Debugging in WordPress », Advanced Administration Handbook, mis à jour le 7 juillet 2025, developer.wordpress.org.
• WordPress.org, « Recovery Mode », documentation publiée le 14 août 2025, wordpress.org.
• WordPress Developer Resources, « Updating WordPress », mis à jour le 1er juillet 2026, developer.wordpress.org.
• WordPress Developer Resources, « Backing Up Your WordPress Site », mis à jour le 4 juin 2026, developer.wordpress.org.
• WordPress Developer Resources, « Editing wp-config.php », section WP_ALLOW_REPAIR, mis à jour le 16 août 2026, developer.wordpress.org.
• WordPress Developer Resources, « Changing File Permissions », mis à jour le 7 juillet 2025, developer.wordpress.org.
• WordPress Developer Resources, « Apache HTTP Server », section .htaccess et permaliens, mis à jour le 7 juillet 2025, developer.wordpress.org.
• WP-CLI, références des commandes wp db repair, wp core download et wp plugin install, developer.wordpress.org.