« Erreur critique sur ce site web » : ce que WordPress ne vous dit pas, et comment reprendre la main
Sommaire
Introduction
Vous ouvrez votre site un matin et il a disparu. À sa place, une phrase grise sur fond blanc : « Il y a eu une erreur critique sur ce site web ».
Personne n'a touché à quoi que ce soit la veille. Aucune alerte, aucun message : juste un site devenu inaccessible, et un formulaire de contact qui ne reçoit plus rien.
Ce message n'est pas une panne de serveur ni un problème de connexion. C'est WordPress qui s'arrête volontairement pour éviter d'afficher pire, et qui refuse de vous dire pourquoi sur la page publique.
Les pages qui suivent indiquent où se trouve le vrai message, quelles sont les trois causes qui reviennent presque toujours, et dans quel ordre rétablir le site.
Elles se terminent sur la question qui compte une fois le site revenu en ligne. Qui porte cette maintenance, et est-ce votre métier.
Ce que le message « Erreur critique » dit, et ce qu'il cache
Depuis la version 5.2, WordPress intercepte les erreurs fatales au lieu de laisser le serveur renvoyer une page blanche. Le visiteur voit une phrase neutre, et l'administrateur reçoit un courriel.
Ce comportement est une protection délibérée. Afficher le détail technique d'une erreur sur une page publique revient à exposer des chemins de fichiers et des noms de composants à n'importe quel visiteur.
Un garde-fou, pas un diagnostic
Le message public ne contient donc aucune information exploitable. Il ne dit ni quel composant a échoué, ni depuis quand, ni si vos données sont intactes.
C'est précisément ce vide qui transforme une panne technique en situation de crise. Le dirigeant constate l'arrêt, ne peut rien qualifier, et doit appeler quelqu'un sans savoir ce qu'il va falloir expliquer.
Pendant ce temps, le site reste indexé par Google avec un code de réponse d'erreur. Quelques heures n'ont pas d'effet durable, plusieurs jours en ont un.
Où se trouve le vrai message d'erreur
Le détail existe toujours, il est simplement écrit ailleurs. Trois endroits le contiennent, par ordre de facilité d'accès.
Le courriel de récupération
WordPress envoie un message à l'adresse d'administration du site au moment de l'erreur. Ce courriel nomme le fichier fautif, la ligne concernée, et contient un lien d'accès en mode de récupération valable vingt-quatre heures.
Encore faut-il que cette adresse soit lue. C'est le premier intérêt très concret d'une messagerie professionnelle reliée au domaine, sujet traité hier à propos du nom de domaine et de l'adresse e-mail professionnelle.
Le journal de débogage et les journaux de l'hébergeur
En ajoutant deux constantes dans le fichier wp-config.php, WordPress écrit les erreurs dans un journal au lieu de les afficher. Le fichier obtenu, wp-content/debug.log, donne la trace complète de l'arrêt.
L'hébergeur tient de son côté ses propres journaux, accessibles depuis son interface d'administration. Ils remontent plus haut que WordPress et révèlent parfois une cause que le site lui-même ne voit pas.
Ces deux sources suffisent à qualifier la panne en quelques minutes. C'est le travail d'un prestataire, pas celui d'un dirigeant qui découvre un journal technique un lundi matin.
Les trois causes qui reviennent presque toujours
Sur un site WordPress de TPE, la quasi-totalité des erreurs critiques tient à trois causes. Elles ont un point commun, et ce point commun explique pourquoi la panne se répète.
Une extension ou un thème incompatible
Tout s'exécute dans le même processus. Une extension de formulaire, un thème et le cœur de WordPress partagent la même mémoire et la même pile d'exécution, sans aucune isolation entre eux.
Une seule extension mise à jour la nuit précédente peut donc arrêter le site entier. Ce n'est pas une anomalie du système, c'est la conséquence directe de son architecture ouverte.
La mémoire du serveur saturée
Chaque requête dispose d'une quantité de mémoire plafonnée par l'hébergement. Un site qui accumule les extensions finit par franchir ce plafond, souvent sur la page la plus lourde plutôt que sur l'accueil.
La panne paraît alors aléatoire, et c'est ce qui la rend difficile à faire reconnaître. Le site fonctionne pour vous, et il tombe pour le visiteur qui ouvre la page de contact.
Un changement de version du langage
Le langage PHP fait tourner WordPress, et chaque branche de ce langage a une durée de vie limitée. Deux ans de support actif, un an de correctifs de sécurité, puis l'hébergeur retire la version pour ne plus exposer ses serveurs.
Le jour de la bascule, le code du thème et des extensions doit déjà être compatible. S'il ne l'est pas, le site s'arrête sans que personne n'ait rien modifié de son côté.
C'est la panne la plus mal vécue, parce qu'elle survient sans action de votre part. Elle est aussi la plus prévisible : le calendrier des versions est public des années à l'avance.
Site tombé ce matin : la marche à suivre dans l'ordre
Voici la séquence qui résout la grande majorité des cas, y compris si vous restez sur WordPress. Elle se suit dans cet ordre, et chaque étape sert à ne pas perdre d'information pour la suivante.
Première étape, ouvrir la boîte de réception de l'adresse d'administration et chercher le courriel de WordPress. Le lien qu'il contient ouvre le site en mode de récupération, avec le composant fautif déjà désactivé.
Deuxième étape, noter le nom du fichier et la ligne indiqués avant de toucher à quoi que ce soit. Cette information disparaît dès que l'on commence à désactiver des composants au hasard.
Troisième étape, remettre le site en ligne en laissant le composant fautif désactivé. Un site amputé d'un module de galerie reste un site qui reçoit des demandes, ce qu'un site arrêté ne fait pas.
Quatrième étape seulement, traiter la cause. Mise à jour du composant, remplacement par un équivalent maintenu, ou relèvement de la limite de mémoire chez l'hébergeur selon ce que disait le journal.
Si vous n'avez plus accès à l'administration
Il reste la voie par les fichiers, via un accès FTP ou le gestionnaire de fichiers de l'hébergeur. Renommer le dossier wp-content/plugins désactive toutes les extensions d'un coup et rend l'administration accessible.
On rétablit ensuite le nom d'origine, puis on réactive les extensions une par une jusqu'à voir laquelle arrête le site. La méthode est lente mais elle ne se trompe jamais.
Les quatre réflexes qui aggravent la panne
Certaines réactions de bonne foi rendent la situation plus difficile à réparer. Les quatre suivantes reviennent dans presque tous les dossiers que nous reprenons.
Tout mettre à jour une seconde fois en espérant que le problème se corrige de lui-même. Cela ajoute des variables au lieu d'en retirer, et rend la cause initiale impossible à isoler.
Restaurer une sauvegarde sans avoir daté la panne. On revient parfois à un point qui contient déjà le composant fautif, et l'on conclut à tort que la sauvegarde est inutilisable.
Supprimer des fichiers pour faire de la place avant d'avoir lu le journal. Un journal effacé est une panne qu'il faudra reproduire pour la comprendre.
Laisser le site arrêté plusieurs jours en attendant une disponibilité. C'est le seul de ces quatre réflexes qui a un effet mesurable sur le référencement, et il est entièrement évitable.
Pourquoi la panne reviendra tant que la pile se maintient à la main
Une erreur critique réparée n'est pas un incident clos. C'est le symptôme d'un empilement de composants dont chacun suit son propre calendrier de mises à jour.
Un site WordPress de TPE réunit couramment un thème, une vingtaine d'extensions, le cœur du système et une version du langage serveur. Cela fait autant d'éditeurs indépendants qui publient quand ils le décident, sans se coordonner entre eux.
Qui porte la veille, et est-ce votre métier
La question n'est pas de savoir si WordPress est un mauvais outil. Il fait tourner une part considérable du web, et des équipes entières travaillent très bien avec lui.
La vraie question est celle de la charge. Quelqu'un doit lire les notes de version, tester avant de déployer, surveiller les composants abandonnés et suivre le calendrier des versions du langage.
Si ce quelqu'un est vous, c'est du temps pris sur votre activité. Si c'est un prestataire, cela doit figurer noir sur blanc dans un engagement écrit, et nous avons détaillé les clauses d'un contrat de maintenance à examiner avant de signer.
Dans les deux cas, le travail existe et il se règle en attention ou en délégation. Le piège est de croire qu'il n'existe pas, jusqu'au matin où le site s'arrête.
C'est souvent à ce moment qu'un dirigeant découvre que personne ne portait ce suivi. Nous avons décrit ailleurs les signaux qui doivent conduire à changer d'agence web plutôt qu'à patienter.
Ce que change une plateforme dont les mises à jour sont testées en amont
Sur une plateforme hébergée comme Wix, la pile technique n'est pas la vôtre. Le moteur, le serveur, la version du langage et les modules fonctionnels sont maintenus par l'éditeur et déployés après ses propres tests.
Le risque ne disparaît pas du monde, il change de table. Ce n'est plus votre entreprise qui absorbe une incompatibilité découverte un mardi matin.
La conséquence pratique est simple. Il n'y a pas de message d'erreur critique à diagnostiquer, pas de journal à lire, et pas de limite de mémoire à relever auprès d'un hébergeur.
Ce n'est pas une promesse d'infaillibilité, et nous ne la formulons pas ainsi. C'est un déplacement de responsabilité, documenté dans notre comparaison entre un site professionnel sous Wix et sous WordPress.
Reste la contrepartie, qu'il faut dire honnêtement. Vous dépendez d'un éditeur pour les évolutions du socle, ce qui convient à la grande majorité des sites vitrines et beaucoup moins à une application sur mesure.
Rester sur WordPress ou déplacer le problème : comment trancher
La décision ne se prend pas pendant la panne. Elle se prend une fois le site rétabli, à froid, avec trois éléments sous les yeux.
Premier élément, le nombre de pannes des douze derniers mois et le temps qu'elles ont pris. Un incident par an se gère, un par trimestre est un signal.
Deuxième élément, l'état des composants installés. Une extension dont la dernière mise à jour remonte à deux ans est une dette qui ne se résorbera pas toute seule.
Troisième élément, qui signe l'engagement de maintenance. Si la réponse est « personne pour l'instant », le socle n'est pas le vrai sujet.
Si la bascule est retenue, elle se prépare et ne s'improvise pas. Nous avons détaillé la méthode et les points de vigilance dans notre guide sur la migration de WordPress vers Wix sans perdre son référencement.
Et si WordPress reste le bon choix pour vous, la conclusion est la même. Il faut un responsable nommé, un engagement écrit et un calendrier de mises à jour tenu.
Trois façons de porter la maintenance d'un site
Le tableau ci-dessous compare les trois situations que nous rencontrons le plus souvent. Il ne porte pas sur les fonctionnalités mais sur la charge réelle et sur qui l'absorbe.
Critère | WordPress maintenu par vous | WordPress confié à un prestataire | Site Wix suivi par Lacky |
Mises à jour du socle | À votre charge, sans test | Selon le contrat signé | Faites par l'éditeur, testées en amont |
Version du langage serveur | À suivre vous-même | À la charge du prestataire | Hors de votre périmètre |
Risque d'erreur critique | Élevé et récurrent | Réduit si la veille est tenue | Pratiquement nul sur le socle |
Qui est appelé en panne | Vous, puis un dépanneur | Le prestataire du contrat | Lacky, directement |
Délai de rétablissement | Imprévisible | Celui du contrat | Quelques heures ouvrées |
Extensions abandonnées | Découvertes à la panne | Suivies si l'audit est prévu | Modules intégrés au socle |
Temps pris sur votre activité | Important et imprévisible | Faible, contre engagement | Nul sur la partie technique |
Sauvegardes et restauration | À configurer et vérifier | Selon les clauses retenues | Intégrées à la plateforme |
Aucune de ces trois colonnes n'est mauvaise en soi. La seule erreur consiste à croire que l'on est dans la deuxième alors que l'on est dans la première.
Avis client
Un cas récent illustre bien la mécanique. Une entreprise de services aux particuliers nous a contactés un lundi, site arrêté depuis le vendredi, sans savoir qui appeler.
Le courriel de récupération de WordPress était bien parti, sur une adresse que plus personne ne relevait. La cause était une extension de réservation mise à jour automatiquement, et incompatible avec la version du langage que l'hébergeur venait d'imposer.
Son dirigeant a résumé la situation en une phrase que nous entendons souvent : « Je croyais que mon site était entretenu parce qu'il fonctionnait. »
Le site a été rétabli le jour même, puis repris en main dans les semaines suivantes. Le point de bascule n'a pas été la panne elle-même, mais le constat qu'elle se reproduirait.
Questions fréquentes
Mes données sont-elles perdues quand ce message apparaît ?
Non, dans la quasi-totalité des cas. Le contenu est dans la base de données, qui n'est pas touchée par une erreur d'exécution du code.
Combien de temps faut-il pour remettre un site en ligne ?
Quelques dizaines de minutes quand le courriel de récupération est disponible et que la cause est une extension. Plusieurs heures s'il faut passer par les fichiers et tester les composants un par un.
Faut-il désactiver les mises à jour automatiques pour éviter le problème ?
Ce serait échanger un risque de panne contre un risque de sécurité, et le second est plus grave. La bonne réponse est de tester avant de déployer, pas de cesser de mettre à jour.
Mon hébergeur est-il responsable s'il change la version du langage ?
Il annonce ces changements à l'avance et son obligation s'arrête là. L'adaptation du thème et des extensions relève de celui qui maintient le site.
Un site arrêté quelques heures perd-il son référencement ?
Une interruption courte ne laisse pas de trace durable dans les résultats. Une indisponibilité qui se prolonge sur plusieurs jours, en revanche, se voit dans la couverture d'indexation.
Peut-on passer sur Wix sans perdre les pages déjà référencées ?
Oui, à condition de recenser les adresses existantes et de poser les redirections avant la bascule. C'est le cœur du travail de migration, et c'est là que se joue le maintien du référencement.
Faire auditer votre site actuel
Si le message d'erreur critique est apparu une fois, il apparaîtra de nouveau. Avant d'arbitrer entre réparer et déplacer, il est utile de savoir ce que porte réellement votre site aujourd'hui.
Envoyez-nous l'URL de votre site actuel et nous vous renvoyons sous 48h un audit SEO complet et personnalisé, gratuit et sans engagement. Cliquez ici pour nous contacter et décrivez-nous votre situation en deux lignes.
Lacky est une agence web spécialisée sur Wix, partenaire Wix Studio au niveau Légende, et travaille à distance partout en France et en Belgique. Sa fiche publique recense plus de 500 projets réalisés sur Wix depuis 2014, ainsi que les avis laissés par ses clients.
Un audit ne vous engage à rien et il vous donne une base pour décider. C'est aussi la façon la plus rapide de savoir si votre site actuel peut être consolidé ou s'il vaut mieux repartir sur un socle maintenu.
