L'essentiel à retenir : la plupart des erreurs WordPress — écran blanc, erreur 500, mémoire épuisée, 404 après une migration — remontent à l'une de quatre causes racines : un conflit de plugin/thème, une limite de mémoire ou d'exécution PHP, un fichier .htaccess corrompu, ou un problème de connexion à la base de données. Diagnostiquer laquelle se produit, plutôt que de tenter des corrections au hasard, remet un site en ligne le plus rapidement.
Pourquoi les mêmes erreurs reviennent sans cesse
WordPress fonctionne sur PHP, un serveur web et une base de données, et la plupart des erreurs rencontrées par les propriétaires de sites sont en réalité des défaillances de l'une de ces trois couches qui remontent à la surface via WordPress, plutôt que des bugs du cœur de WordPress lui-même. C'est utile à savoir car cela signifie que la correction n'est généralement pas "réinstaller WordPress" — mais d'identifier quelle couche a échoué et de traiter spécifiquement ce problème.
Les quatre causes racines ci-dessous représentent la grande majorité des erreurs WordPress signalées dans les forums d'assistance et les tickets d'hébergement, et chacune a une correction spécifique et reproductible plutôt qu'un vague "essayez de vider votre cache".
L'écran blanc de la mort (White Screen of Death, WSOD)
Une page entièrement blanche et vide, sans message d'erreur visible, signifie presque toujours qu'une erreur fatale PHP s'est produite, mais que la configuration par défaut de WordPress masque les erreurs aux visiteurs plutôt que de les afficher. Les deux déclencheurs les plus courants sont un plugin ou un thème incompatible avec la version PHP actuelle du site, et le site qui épuise sa limite de mémoire PHP allouée en cours de requête.
Pour diagnostiquer : activez le mode debug en ajoutant deux lignes à wp-config.php — define('WP_DEBUG', true); et define('WP_DEBUG_LOG', true); — ce qui écrit l'erreur PHP réelle dans un fichier debug.log à l'intérieur de wp-content au lieu de la masquer. Cela est documenté dans le guide officiel de débogage de WordPress lui-même. Une fois l'erreur spécifique et le fichier visibles, la correction consiste généralement à désactiver le seul plugin ou thème nommé dans le journal.
Si le FTP ou un gestionnaire de fichiers est le seul accès disponible (car le WSOD bloque aussi le tableau de bord d'administration), renommer le dossier plugins à l'intérieur de wp-content force tous les plugins à se désactiver simultanément — le site devrait se recharger, et les plugins peuvent être réactivés un par un pour trouver le coupable.
500 Internal Server Error
Contrairement à l'écran blanc, une erreur 500 est un message d'échec générique au niveau serveur, pas spécifique à WordPress — elle peut provenir d'un fichier .htaccess corrompu, d'un conflit de plugin, d'un délai d'exécution PHP dépassé, ou d'une mauvaise configuration serveur totalement indépendante du code de WordPress. C'est pourquoi vérifier le journal d'erreurs réel du serveur (disponible dans la plupart des panneaux de contrôle d'hébergement) est une première étape plus fiable que de deviner.
Corrections courantes, dans l'ordre de fréquence de résolution :
- Renommer temporairement .htaccess (WordPress en régénère un par défaut quand vous réenregistrez les réglages de permaliens) — corrige immédiatement les erreurs 500 liées à une corruption.
- Désactiver tous les plugins via phpMyAdmin en renommant la ligne active_plugins de la table wp_options, si l'accès admin est cassé.
- Augmenter la limite de temps d'exécution PHP si l'erreur ne survient que lors d'opérations lourdes comme de grandes importations.
Erreur "Allowed Memory Size Exhausted"
Cette erreur PHP spécifique et détaillée ("Allowed memory size of X bytes exhausted") signifie qu'un script a tenté d'utiliser plus de mémoire que PHP ne l'autorise, et c'est l'une des erreurs WordPress les plus explicites, puisqu'elle nomme le problème exact dans le message lui-même.
La correction comporte deux niveaux. D'abord, augmentez la propre limite de mémoire de WordPress en ajoutant define('WP_MEMORY_LIMIT', '256M'); à wp-config.php. Ensuite, si cela ne résout pas le problème, le memory_limit PHP sous-jacent défini par l'environnement d'hébergement lui-même devra peut-être aussi être augmenté — la constante de WordPress ne peut pas dépasser ce que le serveur autorise, donc un ticket d'assistance auprès de l'hébergeur ou une modification de php.ini est parfois inévitable.
Tableau de référence rapide
| Erreur | Cause la plus courante | Première correction à essayer |
|---|---|---|
| Écran blanc (WSOD) | Erreur fatale PHP d'un plugin/thème | Activer WP_DEBUG, vérifier debug.log |
| 500 Internal Server Error | .htaccess corrompu ou conflit de plugin | Régénérer .htaccess via les permaliens |
| Mémoire épuisée | Limite de mémoire PHP trop basse | Augmenter WP_MEMORY_LIMIT dans wp-config.php |
| 404 sur toutes les pages sauf l'accueil | Règles de réécriture désynchronisées | Réenregistrer les réglages de permaliens |
| Erreur de connexion à la base de données | Identifiants incorrects ou table corrompue | Vérifier les identifiants BDD dans wp-config.php |
Erreurs 404 après une migration ou une mise à jour
Si la page d'accueil se charge mais que toutes les autres pages renvoient une erreur 404, la structure de permaliens stockée dans la base de données WordPress s'est désynchronisée des règles de réécriture stockées dans .htaccess — un effet secondaire courant d'un changement d'hébergeur, d'une restauration de sauvegarde ou d'un changement de serveur. Réenregistrer la page des réglages de permaliens dans l'admin WordPress (Réglages → Permaliens → Enregistrer les modifications, sans besoin de changement réel) régénère .htaccess et corrige généralement cela immédiatement.
Erreurs de connexion à la base de données
"Error establishing a database connection" signifie que WordPress ne peut pas du tout atteindre la base de données MySQL/MariaDB, ce qui est distinct des erreurs ci-dessus puisque cela se produit avant que WordPress ne puisse même charger suffisamment pour afficher son propre style d'erreur. Les deux causes les plus courantes sont des identifiants de base de données incorrects dans wp-config.php (souvent après une migration) et une table de base de données corrompue, le plus souvent wp_options. Vérifier les constantes DB_NAME, DB_USER, DB_PASSWORD et DB_HOST dans wp-config.php par rapport au panneau d'hébergement réel résout le cas des identifiants ; un outil de réparation de base de données fourni par l'hébergeur résout généralement la corruption de table.
Une méthode systématique pour diagnostiquer n'importe quelle erreur WordPress
- Vérifiez l'erreur réelle, pas seulement le symptôme — activez WP_DEBUG ou consultez le journal d'erreurs du serveur plutôt que de deviner à partir d'un écran blanc ou d'un message générique.
- Testez sur une copie, pas sur le site en ligne, chaque fois que la correction implique de désactiver des plugins ou de modifier des fichiers du cœur — un site de staging existe exactement pour ça.
- Changez une seule chose à la fois — désactiver tous les plugins simultanément vous dit *qu'*un plugin est la cause, pas lequel.
- Écartez les causes au niveau de l'hébergement — les incompatibilités de version PHP et les limites de mémoire basses sont souvent un problème de configuration d'hébergement, pas de WordPress ; consultez notre guide plus large sur la vitesse et la configuration WordPress pour les facteurs au niveau de l'hébergement qui affectent aussi les taux d'erreur.
Prévenir ces erreurs dès le départ
Les plugins mal codés — en particulier les lourdes galeries d'images ou outils de traitement média qui chargent de grandes bibliothèques en mémoire à chaque requête — sont une source disproportionnellement courante de plantages par épuisement de mémoire. Une alternative plus légère qui utilise les bibliothèques d'images natives du serveur plutôt que de charger une pile de traitement externe, comme Erdo Image Optimizer, ajoute nettement moins de surcharge mémoire que des plugins médias tout-en-un plus lourds.
Au-delà du choix des plugins, les mêmes habitudes qui préviennent les erreurs les rendent aussi plus rapides à corriger quand elles surviennent quand même : conserver des sauvegardes régulières, tester les mises à jour sur une copie de staging avant de les pousser en production, et maintenir PHP et le cœur de WordPress raisonnablement à jour pour que les erreurs de compatibilité ne s'accumulent pas d'année en année par négligence.
Erreurs courantes lors de la correction des erreurs WordPress
- Réinstaller le cœur de WordPress comme première réaction, alors que la faute réelle est presque toujours un plugin, un thème ou un réglage au niveau de l'hébergement spécifique.
- Désactiver et réactiver les plugins un par un sur le site en ligne pendant les heures ouvrables, alors qu'une copie de staging permettrait de trouver le coupable sans interruption visible pour les visiteurs.
- Ignorer complètement le journal d'erreurs et essayer des corrections au hasard basées sur le symptôme visible (une page blanche) plutôt que sur l'erreur PHP réelle derrière.
- Modifier wp-config.php sans copie de sauvegarde préalable, transformant une erreur récupérable en un site qui ne se charge plus du tout si une faute de frappe est introduite.
- Supposer qu'une erreur 500 est toujours la faute de WordPress, alors qu'une mauvaise configuration au niveau serveur et des échecs PHP génériques produisent le même message.
En résumé
En bref, l'écran blanc, les erreurs 500, l'épuisement de mémoire et les permaliens cassés qui constituent la majorité des demandes de dépannage WordPress remontent tous à un petit ensemble de causes racines — conflits de plugin/thème, limites PHP, corruption de .htaccess ou problèmes de base de données — chacune avec une correction spécifique et reproductible. Activer le mode debug et lire l'erreur réelle, plutôt que de deviner à partir du symptôme visible, est l'habitude qui transforme une panne stressante en une correction de cinq minutes.