Site WordPress qui plante : le guide de dépannage

Site WordPress en panne : par où commencer

Le premier réflexe face à un site qui plante n’est pas de corriger, mais de sauvegarder et d’identifier ce qui a changé récemment. Une panne WordPress a presque toujours une cause déclenchante datée : une mise à jour, une nouvelle extension, une intervention. Retrouver ce déclencheur, c’est déjà être à moitié dépanné.

Avant toute manipulation, appliquez ces trois réflexes dans l’ordre :

1. Faites une sauvegarde complète (fichiers + base de données). Même sur un site cassé, sauvegardez avant d’intervenir. Une manipulation maladroite peut aggraver la situation, et sans copie de secours vous n’avez plus de point de retour. C’est la seule étape vraiment irréversible que vous pouvez éviter.
2. Notez le dernier changement effectué. Quelle extension a été installée ou mise à jour ? WordPress a-t-il été mis à jour ? Quelqu’un a-t-il modifié un fichier ? Neuf fois sur dix, la réponse est là.
3. Vérifiez si la panne touche tout le site ou une seule page. Un site entièrement inaccessible et une seule page en erreur ne relèvent pas du même diagnostic ni de la même urgence.

Avant d’accuser WordPress, vérifiez la couche en dessous. Une part non négligeable des « pannes WordPress » ne viennent pas de WordPress du tout. Contrôlez dans l’ordre :

• Le statut de l’hébergeur : une panne serveur, une maintenance ou un dépassement de ressources côté hébergeur peut mettre votre site à terre sans que WordPress soit en cause. Consultez la page de statut de votre hébergeur.
• Le nom de domaine : est-il expiré ? Un domaine non renouvelé coupe le site net.
• Les DNS : un enregistrement DNS mal configuré ou un changement récent peut rendre le site injoignable alors que les fichiers sont intacts.

Si ces trois points sont sains, alors seulement le problème est probablement dans WordPress. Vous venez d’économiser des heures de recherche au mauvais endroit.

Les erreurs WordPress les plus fréquentes

La plupart des pannes WordPress se reconnaissent à un message d’erreur précis qui pointe déjà vers la cause. Apprendre à lire ces messages, c’est raccourcir le diagnostic de moitié. Voici les symptômes les plus courants et leur piste de correction.

Depuis WordPress 5.2, le comportement moderne a changé : l’écran blanc historique est le plus souvent remplacé par le message « There has been a critical error on this website », accompagné d’un e-mail de récupération envoyé à l’adresse de l’administrateur. Cet e-mail contient un lien vers le mode de récupération, qui permet d’accéder au tableau de bord même quand le site public est cassé, et de désactiver l’extension fautive. C’est souvent la voie la plus rapide vers la correction : vérifiez d’abord votre boîte de réception.

Un message générique à l’écran ne suffit pas ; le vrai diagnostic est dans les journaux. Activez le mode débogage en ajoutant ces 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 );

WordPress consigne alors toutes les erreurs dans wp-content/debug.log. Ouvrez ce fichier : il nomme souvent l’extension ou la ligne de code exacte à l’origine de la panne. Consultez aussi les logs serveur (accessibles via cPanel, GridPane, Kinsta ou votre panneau d’hébergement) pour les erreurs de niveau PHP ou serveur. Pensez à repasser WP_DEBUG à false une fois le problème résolu, pour ne pas exposer d’informations sensibles.

Diagnostic en 6 étapes : isoler la cause

Le dépannage WordPress est une démarche d’élimination : on désactive, on teste, on réactive, jusqu’à trouver le coupable. Suivez ces six étapes dans l’ordre. Selon que votre tableau de bord /wp-admin est accessible ou non, la manipulation se fait depuis l’interface WordPress ou par FTP/SFTP.

1. Sauvegarder. Fichiers et base de données, avant tout le reste. Si vous n’avez rien d’autre à retenir de cet article, retenez ceci.
2. Activer le mode débogage. Passez WP_DEBUG et WP_DEBUG_LOG à true dans wp-config.php (voir plus haut) et lisez debug.log. Vous saurez peut-être immédiatement quoi corriger, sans passer par les étapes suivantes.
3. Désactiver toutes les extensions, puis les réactiver une à une. Si /wp-admin est accessible, désactivez-les toutes depuis l’écran Extensions. Sinon, par FTP, renommez le dossier wp-content/plugins en plugins-off. Si le site revient, une extension est en cause : réactivez-les une par une (recréez le dossier et renommez chaque sous-dossier) en testant entre chaque, jusqu’à ce que la panne réapparaisse.
4. Basculer sur un thème par défaut. Activez un thème officiel (Twenty Twenty-Four, Twenty Twenty-Five). Par FTP, renommez le dossier de votre thème actif dans wp-content/themes : WordPress bascule automatiquement sur un thème par défaut présent. Si le site se rétablit, le problème vient du thème.
5. Vérifier la mémoire PHP et le fichier .htaccess. Augmentez la limite mémoire en ajoutant define( 'WP_MEMORY_LIMIT', '256M' ); dans wp-config.php. Renommez le .htaccess à la racine pour tester s’il est en cause ; WordPress peut en régénérer un propre depuis Réglages → Permaliens.
6. Contrôler la base de données. En cas d’« erreur de connexion à la base de données », vérifiez les identifiants dans wp-config.php (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST). Réparez la base avec define( 'WP_ALLOW_REPAIR', true ); puis en visitant votresite.com/wp-admin/maint/repair.php.

Corriger les pannes sans accès au tableau de bord (par FTP)

Quand /wp-admin est inaccessible, toutes les corrections se font par FTP/SFTP ou par le gestionnaire de fichiers de l’hébergeur. C’est la situation la plus stressante, mais aussi celle où WordPress est le plus prévisible : les mêmes gestes règlent la grande majorité des cas.

Vous aurez besoin des identifiants FTP/SFTP fournis par votre hébergeur, et d’un client comme FileZilla. L’alternative, souvent plus simple, est le gestionnaire de fichiers intégré au panneau d’hébergement (cPanel, GridPane, Kinsta, et autres) : vous manipulez les fichiers directement depuis le navigateur, sans logiciel à installer.

Voici les manipulations clés :

• Désactiver toutes les extensions : renommez le dossier wp-content/plugins en plugins-old. WordPress ne trouve plus les extensions et les désactive toutes. Si l’accès revient, une extension était en cause.
• Forcer un thème par défaut : renommez le dossier de votre thème actif dans wp-content/themes. WordPress bascule sur un thème par défaut, contournant un thème défaillant.
• Régénérer le .htaccess : renommez le .htaccess à la racine en .htaccess-old. S’il était corrompu (erreur 500 ou 404 généralisée), le site revient ; régénérez-en un propre via Réglages → Permaliens une fois reconnecté.
• Augmenter WP_MEMORY_LIMIT : ouvrez wp-config.php et ajoutez define( 'WP_MEMORY_LIMIT', '256M' ); pour régler un dépassement de mémoire (écran blanc, erreur 500).
• Supprimer un fichier .maintenance coincé : si le message « briefly unavailable for scheduled maintenance » persiste, supprimez le fichier .maintenance à la racine, laissé par une mise à jour interrompue.

Prévenir plutôt que dépanner

La grande majorité des pannes WordPress sont évitables avec une routine de maintenance simple. Dans notre expérience d’agence qui héberge et maintient des sites clients au quotidien, la panne n’est presque jamais une fatalité technique : c’est un défaut de maintenance qui finit par se voir.

Voici les six mesures qui font le plus de différence :

• Sauvegardes automatisées hors-site. Des sauvegardes quotidiennes ou hebdomadaires, stockées ailleurs que sur le serveur du site (cloud, stockage distant). Une sauvegarde sur le même serveur disparaît avec lui.
• Environnement de préproduction (staging). Une copie du site où tester chaque mise à jour avant de la passer en production. C’est le filet de sécurité numéro un.
• Mises à jour espacées et surveillées. Ne pas tout mettre à jour d’un coup, sans surveillance, un vendredi soir. Espacer, tester, vérifier après chaque lot.
• Limitation du nombre d’extensions. Chaque extension est une porte d’entrée pour les conflits et les failles. Gardez le strict nécessaire, désinstallez le reste.
• Hébergement de qualité. Un hébergement adapté à WordPress, avec des ressources suffisantes et un support réactif, prévient une part importante des pannes serveur.
• Monitoring de disponibilité (uptime). Un outil qui vous alerte dès que le site tombe, pour intervenir avant que vos clients ne le remarquent, pas après.

Pour aller plus loin sur ces routines, consultez notre guide Maintenance WordPress : le guide complet et la checklist Sécuriser son site WordPress.

Mini étude de cas : un site récupéré en une heure

Ce n’est pas la panne qui coûte cher, mais l’absence de sauvegarde récente et de staging. Imaginons un scénario représentatif. Une PME manufacturière de la Rive-Sud constate un vendredi soir que son site affiche « There has been a critical error on this website ». Personne n’y a touché : une extension s’est mise à jour automatiquement et s’est révélée incompatible avec la version de PHP du serveur. Le site public est inaccessible, le tableau de bord aussi.

Voici comment la méthode de cet article déroule le dépannage :

1. Diagnostic par e-mail de récupération. WordPress 5.2+ a envoyé un e-mail à l’adresse de l’administrateur. Le lien de mode de récupération donne accès à un tableau de bord dégradé et nomme directement l’extension fautive.
2. Identification et neutralisation par FTP. Faute d’e-mail exploitable, on se connecte en FTP, on renomme le dossier de l’extension coupable dans wp-content/plugins. Le site revient immédiatement.
3. Rétablissement. L’extension est réinstallée dans une version compatible, ou remplacée. Le site est de nouveau pleinement fonctionnel en moins d’une heure.
4. Prévention pour la suite. On met en place un environnement de staging, on désactive les mises à jour automatiques non surveillées, et on installe des sauvegardes hors-site quotidiennes.

Avec ces deux garde-fous, l’incident du vendredi soir devient un non-événement réglé en quelques minutes le lundi matin, dans un environnement de test.

Par où commencer

Si votre site est en panne maintenant, suivez le diagnostic en 6 étapes en commençant par la sauvegarde ; si tout fonctionne, mettez en place la prévention dès aujourd’hui. Deux parcours, selon votre situation :

• « Mon site est en panne maintenant » → Rendez-vous à la section Diagnostic en 6 étapes. Commencez par la sauvegarde, activez le débogage, puis isolez le coupable par élimination. Si /wp-admin est inaccessible, passez directement par FTP.
• « Je veux éviter la prochaine panne » → Rendez-vous à la section Prévenir plutôt que dépanner et mettez en place sauvegardes hors-site, staging et monitoring.

Trois signaux doivent vous faire arrêter les manipulations et demander de l’aide : une erreur de base de données persistante malgré la réparation, un site piraté (code injecté, redirections, contenu inconnu), ou l’absence totale de sauvegarde disponible. Dans ces cas, chaque manipulation à l’aveugle risque d’aggraver la situation ou de détruire des données. Mieux vaut confier le rétablissement à quelqu’un qui répare des sites WordPress tous les jours.