Plugin WordPress qui ne fonctionne plus : isoler la cause en quatre étapes, sans casser le site

Un plugin qui cesse de fonctionner n’est presque jamais « cassé » en lui-même. Dans la grande majorité des cas, il s’agit d’un conflit entre deux extensions, ou d’une incompatibilité avec la version de PHP du serveur. La méthode ci-dessous isole la cause en quelques essais, sans désactiver tout le site au hasard.

Avant de toucher à quoi que ce soit : la sauvegarde

Ce n’est pas une formalité. Un diagnostic consiste à désactiver, réactiver et parfois modifier des fichiers : il faut pouvoir revenir en arrière.

La sauvegarde doit couvrir les fichiers et la base de données. Une sauvegarde de fichiers seule ne restaure ni les contenus, ni les réglages, ni les utilisateurs. Notre page sur la sauvegarde d’un site et la règle 3-2-1 détaille ce que recouvre une sauvegarde qui sert réellement à quelque chose.

Si votre hébergeur propose des instantanés automatiques, vérifiez maintenant leur date et leur profondeur. Un instantané de la nuit dernière suffit ; un instantané hebdomadaire vous ferait perdre une semaine de contenu.

Étape 1 : lire le journal des erreurs

Cette étape évite souvent toute la suite, et elle est pourtant la plus souvent sautée.

WordPress sait écrire les erreurs PHP dans un fichier, à condition de le lui demander. Dans le fichier wp-config.php, avant la ligne qui indique d’arrêter les modifications, on active le mode de débogage en écriture seule — c’est-à-dire en journalisant les erreurs sans les afficher aux visiteurs.

Le journal se remplit alors dans wp-content/debug.log. Reproduisez le problème, puis ouvrez ce fichier : la dernière erreur porte le chemin du fichier fautif, et ce chemin contient le nom du dossier de l’extension. Vous avez votre coupable en une ligne.

Point de vigilance : n’activez jamais l’affichage des erreurs à l’écran sur un site en production. Les messages d’erreur PHP révèlent des chemins serveur et parfois des fragments de requête, ce qui constitue une fuite d’information exploitable.

Étape 2 : la désactivation par moitiés

Si le journal ne dit rien d’exploitable, on passe à l’isolement. La tentation est de désactiver les extensions une par une : sur trente extensions, cela fait trente essais.

La méthode par moitiés en demande cinq.

1. Désactivez la moitié des extensions actives.
2. Testez. Si le problème a disparu, le coupable est dans la moitié désactivée. Sinon, il est dans l’autre.
3. Réduisez de moitié la zone suspecte et recommencez.
4. En quatre à cinq essais, il ne reste qu’une extension.

Notez l’ordre exact de vos désactivations sur un papier. C’est banal et c’est ce qui évite de réactiver une extension de travers à la fin de la procédure.

Une fois le coupable isolé, vérifiez qu’il s’agit bien d’un conflit : réactivez-le seul, avec toutes les autres désactivées. S’il fonctionne dans ces conditions, le problème n’est pas lui, c’est sa cohabitation avec une autre extension.

Étape 3 : les trois causes les plus fréquentes

Cause	Comment la reconnaître	Ce qui la corrige
Version de PHP trop récente	Erreur fatale mentionnant une fonction « deprecated » ou « undefined »	Repasser à la version PHP précédente chez l’hébergeur, le temps de mettre le plugin à jour
Extension non maintenue	Dernière mise à jour remontant à plus d’un an sur sa fiche	Chercher un équivalent maintenu, pas de correctif à espérer
Conflit entre deux extensions	Le plugin fonctionne seul mais pas avec un autre actif	Choisir entre les deux, ou chercher la fonction en double

La version de PHP est la cause la plus souvent négligée, parce qu’elle change sans qu’on le demande : de nombreux hébergeurs font évoluer la version par défaut, et un plugin ancien ne suit pas. C’est un réglage qui se modifie en deux clics dans le panneau de l’hébergeur, et le repli temporaire vers la version précédente est une manœuvre légitime — à condition de ne pas s’y installer, une version de PHP obsolète ne recevant plus de correctifs de sécurité.

Les doublons de fonction méritent une mention à part. Deux extensions qui gèrent le même domaine — deux caches, deux outils de référencement, deux gestionnaires de formulaires — finissent presque toujours par se gêner. Sur un site vitrine, la règle qui évite le plus de problèmes est d’avoir une seule extension par fonction.

Étape 4 : quand l’administration est inaccessible

Si l’erreur bloque l’accès au tableau de bord, la désactivation par l’interface devient impossible. Il reste une porte.

Connectez-vous en FTP ou par le gestionnaire de fichiers de votre hébergeur, puis ouvrez le dossier wp-content/plugins. Renommez le dossier de l’extension suspecte en lui ajoutant un suffixe. WordPress ne la trouve plus, la considère comme absente et la désactive automatiquement.

Si vous ne savez pas laquelle incriminer, renommez le dossier plugins lui-même : toutes les extensions sont désactivées d’un coup et l’administration redevient accessible. Vous remettez ensuite le nom d’origine et réactivez une à une depuis l’interface.

Cette manœuvre ne détruit aucune donnée : les réglages des extensions vivent en base de données, pas dans leurs fichiers.

Éviter que cela se reproduise

Trois habitudes réduisent nettement la fréquence de ces incidents.

Mettre à jour en environnement de test, pas directement en production, dès que le site a un enjeu commercial. Le sujet est traité dans les mises à jour de WordPress.

Tenir la liste des extensions courte. Chaque extension ajoutée multiplie les combinaisons possibles de conflits. Une extension installée « pour essayer » et jamais retirée est une dette.

Vérifier la date de dernière mise à jour avant d’installer. Une extension abandonnée fonctionne jusqu’au jour où WordPress change quelque chose, et ce jour arrive. C’est aussi une question de sécurité : une extension non maintenue est un point d’entrée connu, comme le rappelle notre page sur un site WordPress piraté.