erreur critique wordpress
Agir tout de suite : sécuriser l’accès et limiter l’impact
Quand le message Il y a eu une erreur critique sur ce site apparaît, l’objectif n’est pas de comprendre d’abord , mais de reprendre la main sans aggraver la situation. Commencez par éviter les manipulations hasardeuses (réinstallations en chaîne, suppression de fichiers au hasard). Si vous avez un accès à l’hébergement (FTP/SFTP + panel type cPanel/Plesk) et/ou à la base de données, vous pouvez intervenir proprement. Sinon, mettez temporairement le site en mode maintenance via votre hébergeur (si possible) ou bloquez l’accès public (règles serveur) pour éviter une avalanche de visites, de cache incohérent et de tentatives d’attaque pendant l’incident.
Si l’administration WordPress est inaccessible, vérifiez d’abord si un e-mail automatique de WordPress a été envoyé à l’adresse administrateur : depuis plusieurs versions, WordPress fournit parfois un mode de récupération avec un lien de connexion unique. S’il existe, utilisez-le immédiatement pour désactiver l’élément en cause (plugin ou thème). Si vous ne recevez rien, il faudra passer par FTP et/ou activer le débogage.
Comprendre le déclencheur : plugin, thème, mise à jour ou serveur
Dans la majorité des cas, l’erreur critique provient d’une erreur PHP fatale (fatal error), souvent liée à :
– un plugin récemment activé ou mis à jour ;
– un thème (ou un constructeur) mis à jour ;
– une incompatibilité de version PHP ;
– une mémoire PHP insuffisante ;
– un conflit entre extensions ;
– une mise à jour incomplète (core, plugins, thèmes) ;
– des droits fichiers incorrects ou une corruption de fichiers.
Il est utile de distinguer ce message des erreurs blanches et des erreurs serveur : parfois, l’incident s’apparente davantage à une erreur HTTP 500. Pour creuser les causes côté serveur, vous pouvez consulter ce guide externe sur les causes fréquentes d’une erreur 500 sur WordPress (configuration, .htaccess, limitations, etc.).
Activer le debug proprement (sans exposer les visiteurs)
Pour identifier précisément le fichier et la ligne qui plantent, activez le log plutôt que l’affichage public. Dans le fichier wp-config.php, ajoutez (ou ajustez) ces constantes :
define(‘WP_DEBUG’, true);
define(‘WP_DEBUG_LOG’, true);
define(‘WP_DEBUG_DISPLAY’, false);
Le but est d’écrire les erreurs dans wp-content/debug.log. Si ce fichier ne se remplit pas, vérifiez les droits d’écriture sur wp-content, ou consultez les logs PHP/Apache/Nginx dans votre interface d’hébergement. Une fois la cause trouvée, remettez WP_DEBUG à false.
Isoler la cause la plus probable : plugins
Un plugin est le suspect n°1, notamment après une mise à jour ou l’ajout d’une extension. Même si vous ne pouvez pas accéder à /wp-admin, vous pouvez désactiver les plugins via FTP :
1) Connectez-vous en FTP/SFTP.
2) Allez dans wp-content/.
3) Renommez le dossier plugins en plugins-old.
WordPress ne trouvant plus les plugins, il les désactive. Si le site revient, vous avez confirmé la piste plugin . Ensuite, remettez le dossier à son nom d’origine et renommez un à un les sous-dossiers de plugins (ou désactivez-les depuis l’admin) pour identifier le coupable.
Pour éviter ce type de saturation et de conflits, il est important de garder une logique de parc d’extensions : mieux vaut moins de plugins, mais bien maintenus et compatibles. À ce sujet, ce contenu interne est utile pour cadrer vos choix sans tomber dans l’excès : Combien de Plugins Peut-on Installer sur Sans Risque
Per saperne di più sui nostri servizi di manutenzione di siti WordPress
Tester le thème : basculer sur un thème WordPress par défaut
Si la désactivation des plugins ne change rien, le thème (ou un child theme) peut être en cause : functions.php, surcharge WooCommerce, code ajouté au mauvais endroit, incompatibilité avec une mise à jour PHP, etc.
Pour tester sans accès admin : via FTP, allez dans wp-content/themes/ et renommez le dossier du thème actif. WordPress tentera alors de basculer sur un thème par défaut (ex. Twenty Twenty-Four) s’il est présent. Si aucun thème par défaut n’est installé, uploadez-en un depuis votre poste (zip décompressé) dans wp-content/themes/ puis renommez l’ancien thème.
Si le site revient, vous avez isolé un problème de thème. À ce stade, évitez de patcher en prod au hasard : restaurez une version stable du thème (depuis sauvegarde), comparez les changements, et identifiez le fichier incriminé via le log.
Résoudre les mises à jour incomplètes (core, plugins, traductions)
Une mise à jour interrompue (timeout, coupure réseau, limite mémoire) laisse parfois WordPress dans un état instable. Indices typiques : un message d’échec de mise à jour, des fichiers manquants, ou un site qui bascule en erreur critique juste après l’opération.
Si vous soupçonnez ce scénario, vérifiez l’existence d’un fichier .maintenance à la racine WordPress : s’il est resté bloqué, supprimez-le. Ensuite, relancez proprement les mises à jour (ou restaurez depuis sauvegarde). Pour des cas concrets liés aux erreurs de mise à jour et de publication, vous pouvez consulter ce guide externe : mise à jour échouée et publication échouée : pistes de résolution.
Ajuster la mémoire et l’environnement PHP (sans masquer le vrai bug)
Augmenter la mémoire peut faire disparaître un crash, mais attention : si une extension a une fuite mémoire ou exécute des tâches trop lourdes, vous ne faites que repousser le problème. Cela dit, il existe un seuil minimal raisonnable, surtout avec WooCommerce, des builders et des plugins de sécurité.
Actions possibles :
– Augmenter WP_MEMORY_LIMIT dans wp-config.php (ex. 256M).
– Ajuster memory_limit côté PHP dans l’hébergement (si autorisé).
– Vérifier la version de PHP : certaines extensions exigent une version minimale. Une montée de version PHP doit être testée (staging) car elle peut aussi déclencher l’erreur si un vieux plugin n’est pas compatible.
– Vérifier max_execution_time et max_input_vars si vous observez des échecs lors d’actions lourdes (import, grosses pages builder).
Contrôler .htaccess et les règles serveur
Un .htaccess corrompu ou des règles ajoutées par un plugin de cache/sécurité peuvent provoquer une panne ou une erreur serveur. Même si le message affiché est erreur critique , la racine peut être côté réécriture ou directives interdites.
Test rapide : renommez .htaccess en .htaccess-old, puis rechargez. Si le site revient, régénérez les permaliens depuis l’admin (Réglages > Permaliens > Enregistrer) pour recréer un .htaccess propre. Ensuite, réintroduisez progressivement les règles nécessaires (cache, sécurité) en validant à chaque étape.
Réparer en s’appuyant sur une méthode structurée (et pas au feeling)
Plus vous changez d’éléments simultanément, plus vous perdez la trace de la cause. Une méthode robuste ressemble à ceci :
1) Capturer les symptômes : page concernée, action qui déclenche, heure d’apparition.
2) Lire les logs (debug.log + logs serveur).
3) Neutraliser les plugins, puis réactiver un par un.
4) Tester un thème par défaut.
5) Contrôler versions (WP/PHP), limites mémoire, .htaccess.
6) Revenir à une sauvegarde si la remise en état est plus coûteuse que le rollback.
7) Corriger la cause racine (plugin à remplacer, thème à patcher, montée de version, etc.).
Si vous souhaitez un pas-à-pas complémentaire orienté réparation avec différents scénarios, ce guide externe est une bonne référence : comment réparer le message Il y a eu une erreur critique.
Restaurer une sauvegarde : quand c’est la solution la plus rentable
Si votre site est en production (e-commerce, génération de leads, trafic SEO), l’objectif est de réduire le downtime. Dans beaucoup de cas, la restauration d’une sauvegarde saine (fichiers + base) est la solution la plus rapide, à condition de :
– connaître la fenêtre de perte acceptable (commandes, formulaires, contenu) ;
– réappliquer ensuite la mise à jour en staging pour reproduire le bug ;
– éviter de restaurer trop loin et de perdre des données importantes.
Pour mettre en place une stratégie fiable (et performante), voici un guide interne orienté bonnes pratiques : Comment Sauvegarder Automatiquement Sans Ralentir le Site
Après le rétablissement : éviter la rechute (maintenance, staging, monitoring)
Une fois le site revenu, le travail n’est pas terminé. Sans mesures préventives, l’incident risque de se reproduire à la prochaine mise à jour ou au prochain pic de charge. Les actions les plus efficaces :
Per saperne di più sui nostri servizi di manutenzione di siti WordPress
– Mettre en place un environnement de staging pour tester les mises à jour (core, plugins, thèmes).
– Activer un monitoring (uptime + alertes) et une surveillance des logs.
– Planifier les mises à jour et les valider (compatibilités, changelogs).
– Contrôler la performance de l’admin : une administration lente est souvent le symptôme d’un empilement de requêtes, de cron, ou d’extensions trop lourdes, ce qui peut aussi augmenter le risque de plantage lors d’opérations. Sur ce point, cet article interne aide à diagnostiquer : Lentezza in Admin Cause tecniche
Sécurité : un plantage peut aussi être un signal d’alerte
Dans certains cas, l’erreur critique survient après une compromission : injection de code, fichiers modifiés, création d’un admin fantôme, ou surcharge serveur provoquée par des bots. Si vous observez des fichiers inconnus, des redirections, ou des comptes suspects, considérez l’incident comme potentiellement lié à la sécurité.
Sans multiplier les outils, adoptez des fondamentaux : mises à jour régulières, plugins de confiance, mots de passe forts, limitation des tentatives de connexion, permissions fichiers cohérentes, et sauvegardes hors site. Pour approfondir côté sécurité WordPress, vous pouvez lire ce contenu externe : conseils et bonnes pratiques de sécurisation.
Et si vous voulez élargir votre boîte à outils de dépannage (pannes, dysfonctionnements, comportements étranges), cette ressource externe regroupe de nombreux cas pratiques : solutions rapides pour différents bugs WordPress.
Quand déléguer : gagner du temps, protéger le SEO et réduire le risque
Si votre site est un actif business, la vraie question n’est pas seulement comment réparer , mais comment éviter que ça coûte plus cher la prochaine fois . La maintenance WordPress couvre précisément ce périmètre : mises à jour contrôlées, tests, sauvegardes, sécurité, surveillance, et interventions rapides.
Il existe aussi un impact direct sur la visibilité : indisponibilités, lenteur, erreurs serveur et instabilités peuvent dégrader l’expérience et, à terme, les signaux de qualité. Pour relier maintenance et performance organique, ce contenu interne apporte un angle utile : SEO et Maintenance Le Lien Invisible.
Plan d’action récapitulatif (check-list)
– Utiliser le lien de récupération WordPress si disponible.
– Activer WP_DEBUG_LOG (sans afficher les erreurs aux visiteurs).
– Désactiver tous les plugins (FTP), puis réactiver un à un.
– Basculer sur un thème par défaut (FTP) pour confirmer/infirmer la piste thème.
– Vérifier .maintenance, relancer les mises à jour proprement.
– Contrôler mémoire/versions PHP et les logs serveur.
– Tester .htaccess (renommage) et régénérer les permaliens.
– Restaurer une sauvegarde si le temps de diagnostic dépasse le temps de rollback acceptable.
– Mettre en place staging + sauvegardes + monitoring pour prévenir.
Besoin d’une prise en charge : intervention et maintenance continue
Si vous préférez une résolution rapide avec un cadre (diagnostic, correction, sécurisation, prévention), vous pouvez consulter nos solutions d’accompagnement. Cela permet de traiter l’incident actuel, mais aussi de réduire fortement la probabilité qu’il se répète lors des prochaines mises à jour ou évolutions du site.
Externaliser ou non : le bon critère de décision
La meilleure règle est simple : si l’arrêt du site coûte plus cher (ventes perdues, leads, réputation, SEO) que la maintenance, il est rationnel de déléguer. À l’inverse, un petit site vitrine à faible enjeu peut s’en sortir avec une routine minimale, à condition d’être discipliné sur les sauvegardes et les tests.
Pour vous aider à trancher selon votre contexte (complexité, risques, ressources internes), ce contenu interne peut guider la décision : Perché affidare la manutenzione a un'agenzia?.
