Un site WordPress peut afficher “il y a eu une erreur critique sur ce site” juste après une mise à jour de plugins. Parfois, même l’administration devient inaccessible. La priorité est simple : remettre le site en ligne sans aggraver la panne, puis identifier précisément ce qui a cassé.

Hypothèses

Le contexte ne précise pas l’hébergeur, les accès disponibles, ni la version PHP. La procédure ci-dessous part d’un cas courant : accès aux fichiers via FTP ou gestionnaire de fichiers, et un site WordPress qui a cessé de répondre immédiatement après une mise à jour de plugins.

Symptôme observé

Après une mise à jour de plugins, le site affiche une erreur critique. Rien n’est accessible, y compris la page de connexion à l’admin. Dans ce scénario, l’erreur est souvent un “fatal error” déclenché au chargement d’un plugin ou du thème.

Objectif et logique de dépannage

Le dépannage suit une logique de risque minimal.

Première étape : désactiver l’ensemble des plugins sans passer par l’admin.

Deuxième étape : confirmer que le site repart.

Troisième étape : réactiver un à un pour isoler le plugin fautif.

Quatrième étape : récupérer un message d’erreur exploitable dans un log.

Cinquième étape : corriger la cause racine, puis sécuriser les futures mises à jour.

Remise en ligne immédiate sans accès à l’admin

Vérifier l’accès aux fichiers

Vous devez pouvoir accéder aux fichiers du site.

Les options habituelles sont le gestionnaire de fichiers de l’hébergeur ou un accès FTP. Si vous ne savez pas lequel vous avez, cherchez dans l’espace client de l’hébergeur une entrée type “fichiers”, “file manager”, “FTP”, ou “accès FTP”.

Une fois connecté, repérez le dossier de WordPress. Les indices typiques sont la présence de wp-config.php, des dossiers wp-content, wp-includes, wp-admin.

Désactiver tous les plugins en renommant un dossier

C’est la méthode la plus rapide quand le site et l’admin sont bloqués.

1. Ouvrez wp-content.
2. Repérez le dossier plugins.
3. Renommez plugins en plugins.off.

Résultat attendu : WordPress ne trouve plus les plugins, donc il ne tente plus de les charger. Le site doit repartir au moins en front.

Si le site redevient accessible, cela confirme fortement qu’un plugin mis à jour provoque l’erreur.

Si le site ne revient pas : tester le thème

Si le site reste en erreur après la désactivation des plugins, la panne peut venir du thème.

1. Ouvrez wp-content/themes.
2. Repérez le dossier du thème actif.
3. Renommez le thème actif en ajoutant .off.

Résultat attendu : WordPress bascule sur un thème par défaut si l’un est installé. Si le site repart, le problème vient du thème ou d’une interaction thème-plugin.

Point d’attention : si aucun thème par défaut n’est installé, le basculement peut échouer. Dans ce cas, il faut remettre le thème à son nom initial immédiatement pour éviter de rester bloqué.

Identifier le plugin fautif sans casser à nouveau le site

Une fois le site de nouveau accessible après avoir désactivé tous les plugins, l’objectif est d’isoler le responsable.

Réactiver les plugins progressivement

1. Renommez plugins.off en plugins.
2. Entrez dans wp-content/plugins.
3. Renommez un premier plugin en ajoutant .off à son dossier. Exemple : nom-du-plugin devient nom-du-plugin.off.
4. Rafraîchissez le site.

Interprétation.

Si le site reste accessible, ce plugin n’est pas celui qui casse le site.

Si le site retombe sur l’erreur critique, le dernier plugin “remis en service” est très probablement le responsable.

Pratique recommandée.

Travaillez par lots si vous avez beaucoup de plugins. L’objectif est de réduire le nombre d’allers-retours. Vous pouvez réactiver par groupes, puis réduire le groupe fautif.

Stabiliser le site

Quand le plugin fautif est identifié, laissez son dossier avec .off. Le site reste alors fonctionnel avec tous les autres plugins.

À ce stade, vous avez déjà évité le pire : un site complètement hors ligne.

Pour remettre votre site d’aplomb sans perdre de données, demandez un dépannage prioritaire: dépannage WordPress en urgence

Obtenir la vraie erreur pour décider de la correction

Le message “erreur critique” est trop vague. Il faut le détail du “fatal error”. L’approche la plus directe est d’activer un log WordPress.

Activer les logs WordPress via wp-config

Si vous avez accès à wp-config.php, vous pouvez activer un log.

Ajoutez ou forcez les constantes de debug avant la ligne de fin (souvent un commentaire indiquant d’arrêter d’éditer).

Ce paramétrage vise deux choses : écrire un fichier de log, et éviter d’afficher le détail de l’erreur à l’écran.

Après activation, rechargez une page qui déclenche l’erreur, puis cherchez le fichier wp-content/debug.log.

Résultat attendu : le log mentionne un fichier précis et souvent le nom d’un plugin.

Exploiter le debug.log

Recherchez les lignes contenant “Fatal error” ou “Uncaught”.

Ce que cela apporte.

Vous ne dépannez plus à l’aveugle. Vous savez quel fichier plante, et parfois pourquoi : version PHP incompatible, fonction manquante, conflit avec un autre plugin, ou erreur de type.

Causes fréquentes après une mise à jour de plugins

Le contexte de la panne est un déclencheur important : “juste après une mise à jour”. Cela oriente vers des causes typiques.

Incompatibilité de version PHP

Une mise à jour peut introduire une exigence plus récente côté PHP, ou au contraire déclencher un bug sur une version trop récente.

Dans un scénario courant, un plugin mis à jour requiert une version PHP supérieure à celle du serveur. Le plugin charge, puis plante immédiatement.

À l’inverse, un plugin ancien peut casser quand le serveur est passé sur une version PHP plus récente.

Décision.

Le log est la source la plus utile pour trancher. À défaut, la seule action prudente est de maintenir le plugin fautif désactivé le temps d’analyser.

Conflit entre plugins

Deux plugins peuvent fonctionner séparément, mais casser ensemble après mise à jour.

Le signal.

Le site repart quand tous les plugins sont coupés, retombe quand un plugin est réactivé, mais l’erreur varie selon l’ordre de réactivation.

Dans ce cas, l’isolement par groupes et le debug.log sont indispensables.

Thème dépendant d’un plugin

Certains sites reposent sur un plugin “constructeur” ou un ensemble d’extensions. Une mise à jour de ce plugin peut casser le rendu, voire l’accès.

Le signal.

Le site retombe en erreur dès que le plugin central est réactivé.

La conduite.

Laissez le plugin désactivé, restaurez une version stable si vous avez une sauvegarde, ou mettez à jour l’environnement si le log pointe une incompatibilité serveur.

Plan de secours si vous avez une sauvegarde

Quand la panne survient après une mise à jour, la restauration est souvent l’option la plus sûre si elle est disponible.

La logique.

Vous restaurez un état fonctionnel, puis vous refaites la mise à jour en conditions contrôlées.

Point d’attention.

La discussion ne confirme pas la présence d’un système de sauvegarde chez l’hébergeur. Si vous en avez un, restaurez fichiers et base de données au même point dans le temps.

Sécuriser la prochaine mise à jour

Une fois le site remis en ligne, le vrai gain est d’éviter la répétition.

Ne plus mettre à jour “tout d’un coup”

La mise à jour en bloc rend l’identification difficile.

Approche plus sûre.

Mettre à jour un plugin à la fois, vérifier le site, puis passer au suivant. En cas d’incident, vous savez immédiatement quel plugin est en cause.

Avoir un environnement de test

Le contexte ne mentionne pas d’environnement de staging. Pourtant, c’est l’outil le plus simple pour tester une mise à jour sans risquer l’indisponibilité.

Si vous gérez plusieurs sites ou un site vital, une maintenance régulière avec tests et plan de retour arrière réduit fortement le risque d’arrêt.

Si vous rencontrez le même symptôme et voulez un diagnostic rapide avec plan d’action, contactez-nous: assistance et dépannage informatique

Mettre en place une maintenance WordPress

Une maintenance ne se limite pas aux mises à jour. Elle inclut la vérification de compatibilité, les sauvegardes, et un plan de remise en ligne.

Dans ce type de panne, c’est ce qui fait la différence entre une interruption longue et une remise en service rapide.

Pour une approche structurée et des mises à jour maîtrisées, consultez : maintenance WordPress et site en panne

Résumé opérationnel

Le chemin le plus court quand le site est totalement inaccessible après une mise à jour de plugins est le suivant.

Désactiver tous les plugins en renommant wp-content/plugins. Si le site repart, réactiver progressivement pour isoler le fautif. Si le site ne repart pas, tester le thème. Ensuite, activer un log WordPress pour obtenir l’erreur exacte et décider de la correction.

FAQ

Faut-il désactiver les plugins depuis l’admin ?

Quand l’admin est inaccessible, ce n’est pas possible. Le renommage du dossier plugins est une alternative simple et réversible.

Comment savoir quel plugin a cassé le site ?

En remettant les plugins, puis en les réactivant un par un ou par groupes. Le plugin qui fait revenir l’erreur est le principal suspect.

Que faire si le site reste en erreur même sans plugins ?

Tester le thème en le renommant. Si cela ne suffit pas, il faut récupérer le détail de l’erreur via un log pour éviter les suppositions.

Une restauration est-elle préférable ?

Oui si vous avez une sauvegarde récente et fiable. C’est souvent la manière la plus sûre de revenir à un état stable avant de retenter la mise à jour.