Le message est toujours le même, quel que soit le plugin concerné : « Le plugin n’a pas pu être activé car il a provoqué une erreur fatale. » Aucun détail, aucune ligne de code incriminée, juste ce constat sec affiché par WordPress au moment de l’activation. Pour un développeur qui doit diagnostiquer ce type d’incident chez un client, souvent dans l’urgence puisque le site reste bloqué tant que l’ancienne version fonctionnelle n’est pas restaurée, il vaut mieux disposer d’une méthode systématique plutôt que de chercher au hasard.
Étape 1 : activer le journal de débogage sans exposer l’erreur au public
La première chose à vérifier, avant toute autre hypothèse, c’est simplement si les journaux d’erreur sont accessibles. Si WP_DEBUG_LOG n’est pas déjà activé dans wp-config.php, l’activer temporairement, en gardant WP_DEBUG_DISPLAY à false pour ne jamais exposer d’information technique aux visiteurs du site pendant le diagnostic :
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
Une nouvelle tentative d’activation du plugin déclenche alors l’écriture, dans wp-content/debug.log, du message d’erreur PHP complet, avec le fichier et la ligne exacts où l’erreur fatale s’est produite. Dans l’immense majorité des cas rencontrés en pratique, cette seule étape suffit déjà à identifier la cause précise, sans avoir besoin d’aller plus loin.
Étape 2 : classer l’erreur dans l’une des trois grandes familles
Une fois le message d’erreur en main, il se range presque toujours dans l’une de ces trois catégories, chacune avec sa méthode de résolution propre.
Incompatibilité de version PHP
PHP Fatal error: Uncaught Error: Cannot use 'Enum' as class name as it is reserved
Un message qui mentionne une syntaxe non reconnue, un mot réservé, ou un message du type Call to undefined function sur une fonction native récente, révèle presque toujours une incompatibilité entre la version de PHP exigée par le plugin et celle réellement installée sur le serveur. La vérification est immédiate :
wp eval 'echo PHP_VERSION;'
Comparée à la version minimale annoncée dans l’en-tête Requires PHP du fichier principal du plugin, cette information tranche rapidement l’hypothèse.
Dépendance manquante ou classe introuvable
PHP Fatal error: Uncaught Error: Class "GuzzleHttp\Client" not found
Ce type de message pointe presque toujours soit un dossier vendor manquant après un transfert de fichiers incomplet, notamment lors d’un déploiement par FTP qui aurait ignoré les fichiers cachés ou trop volumineux, soit un conflit d’autoloading Composer entre deux extensions qui embarquent la même bibliothèque sans préfixage, un problème traité en détail par ailleurs. Vérifier simplement la présence du dossier vendor et de son fichier autoload.php sur le serveur suffit souvent à confirmer ou infirmer la première hypothèse.
Table ou colonne absente en base
WordPress database error Table 'nom_base.wp_reservations' doesn't exist
Un message qui mentionne explicitement une table absente indique presque toujours un échec silencieux d’une précédente exécution de dbDelta(), ou un site restauré depuis une sauvegarde de fichiers sans la sauvegarde de base de données correspondante, un décalage fréquent lors de migrations mal coordonnées entre les deux composants d’un site.
Étape 3 : isoler par élimination si le journal reste muet
Dans les rares cas où le journal ne révèle rien d’exploitable, généralement parce que l’erreur survient dans un contexte qui échappe à la capture standard des erreurs PHP, la méthode par élimination reste efficace : désactiver temporairement toutes les autres extensions actives, puis réactiver l’extension problématique seule. Si l’activation réussit dans cet environnement isolé, le problème provient d’un conflit avec une autre extension spécifique, qu’on identifie ensuite en réactivant les autres extensions une par une.
wp plugin deactivate --all
wp plugin activate mon-extension-problematique
Checklist récapitulative du diagnostic
- Activer
WP_DEBUG_LOGsans jamais activerWP_DEBUG_DISPLAYsur un site en production. - Comparer la version PHP réelle du serveur à celle exigée par l’extension.
- Vérifier la présence effective du dossier
vendorsi l’erreur mentionne une classe introuvable. - Vérifier la cohérence entre les fichiers et la base de données après toute restauration de sauvegarde partielle.
- Isoler par élimination si aucune des pistes précédentes n’aboutit.
Un message d’erreur générique n’est jamais une impasse, c’est simplement une invitation à aller chercher l’information un cran plus bas, dans le journal que WordPress tient toujours, même quand il ne l’affiche pas.
En résumé
Face à une erreur fatale à l’activation, la première réaction à avoir n’est jamais de chercher au hasard dans le code du plugin, mais d’activer immédiatement le journal de débogage pour obtenir le message d’erreur réel que WordPress masque volontairement à l’utilisateur final. Dans la grande majorité des cas rencontrés en pratique, cette seule étape, combinée à un classement rapide dans l’une des trois grandes familles de causes présentées ici, suffit à résoudre le diagnostic en quelques minutes plutôt qu’en plusieurs heures d’essais hasardeux.
