Ton site plante et tu suspectes un plugin
Ce matin-là, sur un site WooCommerce hypothétique, le back-office affiche une erreur critique dès la connexion. La veille, tout allait bien. Entre-temps : trois mises à jour de plugins installées automatiquement dans la nuit. Le coupable est probablement dans ce lot — mais lequel ?
C’est le scénario le plus fréquent en maintenance WordPress. Deux plugins (ou un plugin et le thème) se battent pour la même ressource, appellent une fonction qui n’existe plus, ou surchargent la mémoire disponible. Résultat : écran blanc, erreur critique, page qui ne charge plus, ou erreur 500.
La bonne nouvelle : il existe une méthode fiable, éprouvée, qui marche dans 95 % des cas. Elle est un peu fastidieuse mais imparable. Pas besoin de deviner, ni de tout réinstaller de zéro. On isole, on teste, on trouve. Voici comment procéder, du plus simple au plus technique.
Pourquoi ça arrive : les causes réelles
- Deux plugins accrochent le même hook WordPress (une fonction interne appelée à un moment précis) et se marchent dessus.
- Un plugin mis à jour n’est plus compatible avec la version de PHP ou de WordPress installée sur le serveur.
- Un conflit JavaScript en façade : deux scripts chargent la même librairie (jQuery, Swiper) dans des versions différentes, la page front plante silencieusement.
- Le thème appelle une fonction qu’un plugin vient de supprimer ou de renommer après une mise à jour majeure.
- Une mise à jour groupée (thème + plugins + noyau WordPress en même temps) rend impossible d’isoler la source sans méthode.
- Épuisement de la mémoire PHP : un plugin gourmand (constructeur de page, cache, sécurité) dépasse la limite allouée et fait planter tout le reste.
Ce dernier point mérite d’être creusé, parce qu’il ressemble à un conflit de plugins sans en être un — et inversement.
1. Vérifier la santé du site avant de toucher à quoi que ce soit
Avant toute manipulation, va dans Réglages > Santé du site dans le tableau de bord WordPress. Cet outil natif liste les incompatibilités connues, la version de PHP, les erreurs critiques récentes et l’onglet “Informations” te donne un export complet à copier si tu dois demander de l’aide.
C’est aussi le bon moment pour vérifier combien de plugins sont actifs. Si tu es au-delà de 25-30, la probabilité de conflit grimpe mécaniquement — combien de plugins WordPress, est-ce trop ? détaille le seuil raisonnable.
2. Activer le mode debug pour voir l’erreur réelle
WordPress cache par défaut les erreurs PHP aux visiteurs (heureusement), mais toi tu as besoin de les voir. Ouvre wp-config.php (racine du site, via FTP ou le gestionnaire de fichiers de ton hébergeur) et ajoute, juste avant la ligne /* That's all, stop editing! */ :
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);WP_DEBUG_LOG écrit chaque erreur dans un fichier wp-content/debug.log sans l’afficher aux visiteurs (WP_DEBUG_DISPLAY à false). Ouvre ce fichier, cherche la dernière ligne avec un timestamp récent : elle mentionne presque toujours le chemin du plugin fautif, du type wp-content/plugins/nom-du-plugin/fichier.php on line 42. C’est souvent l’indice le plus rapide de toute la méthode.
3. Désactiver tous les plugins en une fois
Si le back-office est accessible : va dans Extensions, coche la case du haut pour tout sélectionner, choisis “Désactiver” dans le menu déroulant en masse. Le site redevient fonctionnel ? Le coupable est bien un plugin. S’il plante encore, le problème vient du thème ou du cœur — passe à l’étape 5.
Si le back-office est inaccessible (écran blanc total, comme décrit dans l’écran blanc de la mort) : connecte-toi en FTP ou en SSH et renomme simplement le dossier wp-content/plugins en plugins-off. WordPress désactive automatiquement tout ce qu’il ne trouve plus. Recrée un dossier plugins vide, puis renomme progressivement.
4. Réactiver les plugins un par un — la vraie méthode
C’est l’étape qui prend du temps, mais qui donne une certitude absolue. Réactive un seul plugin, recharge le site (front et back), vérifie qu’aucune erreur n’apparaît. Si tout va bien, passe au suivant. Note chaque test dans un fichier texte au fur et à mesure — nom du plugin, résultat.
Dès que le site casse à nouveau après une réactivation, tu as ton coupable. Pas besoin d’aller plus loin : désactive-le, et cherche une alternative ou une version antérieure compatible.
Astuce pour gagner du temps sur un site avec 30+ plugins : réactive-les par lots de 5, teste, puis affine dans le lot fautif un par un. Tu divises le nombre de tests par cinq.
5. Basculer sur un thème par défaut
Si désactiver tous les plugins n’a rien changé, le suspect est le thème (ou une combinaison thème + plugin de constructeur de page comme Elementor ou WPBakery). Va dans Apparence > Thèmes et active un thème par défaut de WordPress (Twenty Twenty-Four, Twenty Twenty-Five). Ces thèmes sont volontairement minimalistes, sans dépendance lourde — s’ils font disparaître le problème, ton thème habituel (ou son builder) est en cause.
Si l’admin est inaccessible, même logique par FTP : renomme le dossier du thème actif dans wp-content/themes, WordPress bascule automatiquement sur un thème par défaut restant.
Pour les sites construits avec Elementor ou WPBakery, c’est souvent là que le problème se niche vraiment — un module tiers du builder, pas le builder lui-même.
6. Isoler sans casser l’expérience visiteur
Sur un site en production avec du trafic, désactiver tous les plugins publiquement n’est pas idéal. Installe le plugin Health Check & Troubleshooting (gratuit, dans le répertoire officiel WordPress) : il propose un “mode dépannage” qui désactive les plugins et bascule le thème uniquement pour ton propre compte connecté. Les visiteurs continuent de voir le site normal pendant que tu testes en coulisses. C’est la méthode que je recommande sur tout site avec du trafic actif.
7. Vérifier la mémoire PHP si le conflit ressemble à un blocage total
Certains “conflits de plugins” sont en réalité un dépassement de memory_limit : deux plugins gourmands cumulés dépassent la limite allouée par l’hébergeur, et le symptôme ressemble à un conflit alors que c’est une ressource insuffisante. Le détail complet des directives PHP est dans ce guide dédié, mais voici l’essentiel :
| Directive | Rôle | Symptôme si trop bas | Où la régler | Valeur de départ |
|---|---|---|---|---|
memory_limit | Mémoire max allouée à PHP par requête | Écran blanc, “Allowed memory size exhausted” | wp-config.php ou php.ini | 256M |
max_execution_time | Temps max d’exécution d’un script | Erreur 500/504 sur pages lourdes | .htaccess ou panel hébergeur | 60-90s |
max_input_vars | Nombre de champs de formulaire traités | Réglages de plugin qui ne s’enregistrent pas | php.ini | 3000 |
Cause → Solution en un coup d’œil
| Cause probable | Comment le confirmer | Solution |
|---|---|---|
| Plugin incompatible avec la version PHP | debug.log mentionne son dossier | Désactiver/mettre à jour ce plugin uniquement |
| Deux plugins sur le même hook | Réactivation une par une | Choisir un des deux, chercher une alternative |
| Thème ou builder en cause | Thème par défaut résout le problème | Mettre à jour le thème ou changer de builder |
| Mémoire PHP insuffisante | ”memory exhausted” dans debug.log | Augmenter memory_limit à 256M |
| Cache qui masque le vrai état | Le problème persiste après vidage cache | Vider le cache avant chaque test |
FAQ
Puis-je désactiver tous les plugins sans perdre mes réglages ?
Oui. Désactiver un plugin ne supprime jamais ses données ni ses réglages enregistrés en base de données. Tu peux tout désactiver, tester, puis tout réactiver sans rien perdre — sauf si tu supprimes le plugin (bouton “Supprimer”), là les réglages disparaissent pour de bon.
Le site fonctionne à nouveau après désactivation totale, mais je ne sais pas lequel réactiver en premier ?
Commence par les plugins installés ou mis à jour le plus récemment — regarde la date dans Extensions > Extensions installées. C’est presque toujours le dernier changement qui a déclenché le problème.
Le mode debug affiche des "notices" partout, est-ce grave ?
Non, les notices (avertissements de bas niveau, souvent liés à du code obsolète dans un plugin) ne cassent pas le site. Seules les erreurs “Fatal error” ou “Critical error” bloquent l’affichage. Ne panique pas devant un fichier debug.log rempli de notices bénignes.
Comment éviter que ça se reproduise ?
Teste toujours les mises à jour de plugins sur un environnement de préproduction avant de les appliquer en production, et limite le nombre total de plugins actifs. Une maintenance régulière qui surveille les mises à jour une par une, plutôt qu’en masse et automatiquement, réduit drastiquement ce type d’incident.
Quand passer la main à un pro
Si après désactivation totale et thème par défaut le site plante toujours, le problème vient probablement du noyau WordPress, de la base de données ou de la configuration serveur — plus du côté erreur de connexion à la base de données que du côté plugin. De même, si le site héberge un e-commerce actif et que chaque minute de panne coûte des ventes, ne teste pas en production : fais intervenir quelqu’un qui a l’environnement de test prêt et qui isole en une heure ce qui te prendrait une après-midi entière à tâtonner.
Ce problème, Peechy s'en occupe
Plutôt que de tout gérer seul, confiez votre site à une agence qui s'occupe de tout — hébergement, sécurité, maintenance et corrections. Encore plus simple en abonnement : on règle les soucis avant même que vous les remarquiez.
Confier mon site à Peechy