Erreur critique sur votre site WordPress : que faire, et dans quel ordre

Points clés :

• L’erreur critique protège votre site : WordPress a coupé l’affichage, il n’a rien effacé.
• La bonne question n’est pas « que faut-il ajouter » mais « qu’est-ce qui a bougé juste avant ».
• WordPress vous a déjà envoyé un mail de récupération : c’est votre première porte d’entrée.
• Restaurer la sauvegarde de la veille règle la plupart des blocages en quelques minutes.
• Des signaux clairs indiquent le moment où il faut cesser de manipuler.
• Trois habitudes simples évitent la récidive : sauvegarder avant, faire les mises à jour une par une, vérifier après.

Ce que WordPress vous dit vraiment

Erreur 500 ou critique, ce message n’annonce pas la fin de votre site. Il signale qu’une erreur fatale s’est produite dans le code, presque toujours à l’intérieur d’un composant actif (une extension, un thème, un bout de code personnalisé), et que WordPress a préféré interrompre l’affichage public plutôt que de continuer à exécuter un programme défaillant. La logique est celle d’un disjoncteur domestique : quand quelque chose surchauffe, le courant saute. Ce n’est pas la panne, c’est la protection contre la panne. Vos pages, vos articles, vos commandes, votre base de données : tout est encore là, derrière le rideau.

Une nuance utile avant d’aller plus loin. Si votre site s’ouvre mais que la mise en page est cassée, qu’un menu a glissé ou qu’un bloc s’affiche de travers, sans message d’erreur, vous n’êtes pas dans le même scénario : cela relève généralement du thème ou des styles, et l’urgence est bien moindre. La méthode reste identique, identifier puis défaire le dernier changement. En revanche, si votre site WordPress est inaccessible avec cette phrase à l’écran, suivez la suite point par point. Et si vous vous interrogez plus largement sur la protection de votre installation, notre article sur la sécurisation d’un site WordPress traite ce volet séparément.

Qu’est-ce qui a bougé juste avant ?

Une erreur critique ne surgit jamais de nulle part. Elle suit un changement. Avant de toucher au moindre réglage, remontez le fil : qu’avez-vous fait hier soir, ce matin, la semaine dernière ? Une mise à jour lancée en partant ? Un plugin (extension) installé pour tester une fonctionnalité ? Un message de votre hébergeur ? Cette question vous fait gagner un temps considérable, parce qu’elle transforme une recherche à l’aveugle en vérification ciblée.

Une mise à jour d’extension incompatible

C’est la cause la plus fréquente, et de loin. Une extension se met à jour, automatiquement ou de votre main, et son nouveau code ne s’entend plus avec la version de WordPress installée, avec la version de PHP du serveur, ou avec une autre extension déjà en place. Le site tourne parfaitement la veille, le lendemain, plus rien. Rien d’exotique là-dedans : c’est le quotidien d’un site un peu chargé.

Un conflit entre deux extensions

Deux outils peuvent fonctionner impeccablement chacun de leur côté et se marcher dessus une fois activés ensemble. Chacun appelle des fonctions ou des ressources que l’autre modifie, et l’un des deux finit par tomber. Ce type de conflit se déclenche typiquement dans les minutes qui suivent l’activation d’un nouveau plugin.

Un thème récemment activé ou mis à jour

Le thème n’est pas qu’une question d’apparence : il contient du code, notamment dans ses fichiers de fonctions et ses modèles de page. Une erreur glissée là-dedans suffit à bloquer l’affichage dès le chargement. Si vous avez changé de thème ou accepté sa mise à jour récemment, vous tenez peut-être votre coupable.

Une version de PHP trop ancienne ou trop récente

PHP est le langage qui fait tourner WordPress sur le serveur. Deux scénarios opposés produisent le même écran. Soit votre hébergement est resté sur une version ancienne et une extension incompatible exige des fonctions qui n’y existent pas. Soit votre hébergeur a fait basculer le serveur vers une version plus récente, et un composant vieillissant ne suit plus. Prenons une consultante indépendante dont l’hébergeur modernise l’infrastructure un dimanche soir : elle n’a rien touché, et pourtant son site se bloque le lundi. La documentation officielle de WordPress publie des tableaux de compatibilité entre ses versions et celles de PHP ; pour un site actif, viser une version récente reste la position raisonnable, à condition de coordonner le changement avec une sauvegarde.

Une limite de mémoire atteinte

Chaque page générée consomme de la mémoire serveur. Quand un site accumule les extensions gourmandes et que le plafond alloué est trop bas, un script finit par dépasser la limite de mémoire disponible et s’interrompt brutalement. Le symptôme est le même : écran coupé, message d’erreur. La cause, elle, n’est pas dans un composant fautif mais dans un dimensionnement devenu insuffisant.

Le mail que vous n’avez pas lu et le mode de récupération de WordPress

Voilà le point que presque personne ne connaît. WordPress ne se contente pas d’afficher un message : il envoie automatiquement un e-mail à l’adresse de l’administrateur du site, et cet e-mail contient un lien de connexion spécial. Ce lien ouvre ce qu’on appelle le mode de récupération de WordPress. Concrètement, vous accédez à votre tableau de bord dans une session sécurisée où WordPress a mis en pause le composant qu’il soupçonne, et il vous indique lequel. Vous le désactivez proprement, depuis l’interface, sans toucher au reste. Le site revient. Allez fouiller votre boîte de réception, y compris les indésirables : la solution vous attend peut-être depuis ce matin.

Pas de mail de récupération ? Cela arrive souvent, et pour une raison simple : l’adresse administrateur enregistrée dans WordPress est une vieille adresse, celle de l’ancien webmaster ou d’une messagerie abandonnée. Reste alors la méthode par les fichiers, via l’accès à votre hébergement. Le principe tient en trois gestes : vous ouvrez le dossier qui contient les extensions, vous renommez celui de l’extension suspecte (ajouter un tiret et un mot suffit), puis vous rechargez votre site. S’il revient, vous avez trouvé. Sinon, remettez le nom d’origine et passez à la suivante. Une par une, patiemment. Si aucune extension n’est en cause, appliquez la même logique au dossier du thème actif : WordPress bascule alors sur un thème par défaut, moche mais fonctionnel, ce qui suffit à confirmer la piste. Dès que l’affichage est rétabli, réactivez les éléments un à un pour vérifier lequel déclenche l’incident.

Dernier point de contrôle avant de passer à la suite : la version de PHP. Elle se consulte depuis l’interface de votre hébergeur, ou depuis la page d’état de santé du site dans votre tableau de bord si vous y avez accès. Si elle a changé récemment, vous tenez votre explication.

Restaurer la sauvegarde de la veille : le geste qui règle tout, si elle existe

Tout ce qui précède demande du temps, de la méthode et un peu de sang-froid. Il existe un raccourci, et il ne dépend que d’une chose : disposez-vous d’une sauvegarde complète d’hier, et savez-vous où elle se trouve ? Répondez honnêtement. Votre réponse oriente vers deux journées radicalement différentes.

Comparons deux dirigeants dans exactement la même situation. Le premier gère une petite agence immobilière : son site est sauvegardé chaque nuit, avec un historique de sept jours. Il ouvre son espace, sélectionne la version de la veille, restaure, et son site est de retour avant son deuxième café. Le second dirige un atelier de menuiserie ; sa dernière sauvegarde date d’un moment indéterminé, sur un disque quelque part. Il doit identifier l’extension coupable, désactiver, tester, recommencer, puis reconstruire à la main les réglages perdus. Plusieurs heures. Parfois la journée entière. Quelques minutes d’un côté, une journée de l’autre, sans qu’aucun délai puisse jamais être garanti.

Précision qui rassure : une erreur critique ne supprime pas vos contenus. Ce sont les manipulations empilées sans point de retour qui rendent la récupération pénible. Chaque tentative hasardeuse ajoute une couche à défaire ensuite.

Sur un site hébergé et maintenu par novfr, l’affaire est plus simple : sauvegardes quotidiennes avec sept jours d’historique, surveillance continue avec alerte, mises à jour vérifiées avant d’être appliquées. Dans ce cadre, la restauration de sauvegarde de la veille règle la plupart des erreurs critiques en quelques minutes. C’est tout l’intérêt d’un entretien régulier, expliqué en détail sur notre page de service Maintenance WordPress.

Les signaux qui disent qu’il faut arrêter de manipuler

Il y a un moment où insister aggrave les choses. Vous y êtes si vous ne savez plus quelle extension a été modifiée en dernier, si l’idée de renommer un dossier sur le serveur vous met mal à l’aise, si votre back-office reste inaccessible, si les messages d’erreur ne vous évoquent rien, si vous ignorez où sont vos sauvegardes, ou tout simplement si la procédure ci-dessus a échoué. Arrêtez-vous là. Ne rien faire vaut mieux qu’un geste de trop.

Dans ce cas, novfr propose une ligne de dépannage urgent : 01 85 09 71 76. Elle sert à reprendre la main quand les gestes ne suffisent plus, pas à remplacer un entretien régulier. Une réserve importante : si votre site s’avère infecté, le nettoyage ne relève pas d’un contrat de maintenance standard et fait l’objet d’un devis distinct. Les questions de panne et de piratage sont d’ailleurs traitées dans la FAQ de cette même page de service : Maintenance WordPress. Et si votre vraie interrogation porte sur l’organisation à adopter, l’article sur le choix entre maintenir soi-même ou confier la maintenance pose le débat sans détour.

Trois habitudes pour ne pas revivre la scène

Aucune culpabilisation ici : lancer ses mises à jour en bloc un vendredi soir est un réflexe partagé par des milliers de dirigeants, et ça se comprend quand on a une entreprise à faire tourner. Mais trois gestes suffisent à changer la donne.

• Sauvegarder avant chaque mise à jour importante. Une sauvegarde complète, datée, dont vous connaissez l’emplacement. C’est votre porte de sortie.
• Faire les mises à jour une par une, jamais en bloc. Si quelque chose casse, vous savez immédiatement quoi. En bloc, vous cherchez une aiguille dans une botte de foin.
• Vérifier l’affichage après chaque changement. Page d’accueil, formulaire de contact, deux ou trois pages qui comptent. Ça prend trente secondes.

Ce qui prend du temps n’a jamais été le clic de mise à jour. C’est le contrôle qui vient après, et la sauvegarde qui permet de revenir en arrière. Un site laissé sans entretien coûte plus cher à rattraper qu’à maintenir : les extensions vieillissent, les incompatibilités s’accumulent, et l’incident finit par arriver au pire moment. Pour d’autres repères pratiques, parcourez la liste de tous nos articles.