DÉPANNAGE WORDPRESS
Erreur critique WordPress : reprendre la main sans perdre ses données
1. Évaluer l’incident avant de toucher aux réglages
L’expression « erreur critique » décrit un blocage, pas son origine exacte. Une manipulation précipitée peut compliquer la recherche ou effacer des informations utiles. Prenez quelques minutes pour établir ce qui fonctionne encore et ce qui a précédé l’incident.
Vérifier ce qui est inaccessible pour vos visiteurs
Ouvrez l’accueil, une page interne et l’adresse de connexion à WordPress dans une fenêtre privée. Notez les différences. Si seule une page pose problème, relevez l’action qui déclenche l’erreur : ouvrir une galerie, lancer une recherche ou envoyer un formulaire. Si le site fonctionne par intermittence, indiquez les heures et gardez une capture du message.
Cette description aide à choisir la suite. Un écran d’administration inaccessible et une erreur au paiement ne se traitent pas avec les mêmes priorités. Pour une boutique, vérifiez d’abord si des clients peuvent encore commencer une commande. Prévenez la personne qui suit les ventes afin qu’elle surveille les demandes ou paiements incomplets.
Ne concluez pas à un piratage sur la seule présence du message. Si vous observez en plus des comptes inconnus, des pages modifiées ou des redirections inhabituelles, conservez ces éléments pour une analyse de sécurité distincte.
Reconstituer les derniers changements sans supposer la cause
Notez ce qui s’est passé avant le blocage : mise à jour, installation d’une extension, modification du thème, ajout de code, changement de version PHP ou intervention de l’hébergeur. Demandez aussi aux autres personnes qui administrent le site. Une mise à jour automatique peut avoir eu lieu sans action manuelle récente.
L’ordre des événements donne une piste, mais ne prouve pas qu’un composant est seul responsable. Une extension peut révéler un conflit déjà présent. Évitez donc de changer plusieurs choses en parallèle. Si deux prestataires interviennent, désignez une personne qui centralise les actions et note les résultats.
Une maintenance WordPress avec historique des interventions rend cette reconstitution beaucoup plus simple. Lors d’un dépannage ponctuel, commencez par créer cet historique, même si les premières informations se limitent à une heure et à un nom d’extension.
Préparer les accès et une copie de l’état actuel
Rassemblez les accès utiles : administration WordPress, compte d’hébergement et adresse e-mail d’administration. Vérifiez qui les détient et comment les transmettre de manière sécurisée si un prestataire intervient. Ne publiez pas de capture contenant des identifiants, des chemins sensibles ou les données d’un client dans un forum ouvert.
Avant une opération importante, faites conserver l’état actuel. Un site en panne peut encore contenir des commandes, des messages ou des contenus absents de la dernière sauvegarde. Cette copie ne remplace pas une sauvegarde saine ; elle préserve les éléments apparus depuis.
Si vous n’avez aucun accès technique, envoyez au support une demande précise plutôt que d’essayer des procédures impossibles à terminer. L’URL, le message, l’heure du premier constat et les changements connus lui permettront de vous orienter vers le bon accès ou la bonne personne.
2. Retrouver un accès et isoler le composant en cause
Une fois l’incident décrit, cherchez une intervention ciblée. Le but est de rétablir le fonctionnement sans perdre la possibilité d’expliquer ce qui s’est passé. Si vous n’êtes pas à l’aise avec les fichiers du site, faites réaliser cette étape par votre prestataire.
Utiliser le mode de récupération si le courriel est arrivé
WordPress dispose d’un mode de récupération qui peut se déclencher lors de certaines erreurs fatales. Un courriel envoyé à l’adresse d’administration contient alors un lien spécial. Vérifiez la boîte concernée et les indésirables, puis assurez-vous que le message correspond bien à votre site.
Ce mode peut mettre un composant en pause pour votre session d’administration et vous permettre d’examiner l’erreur. Il ne signifie pas que le site est réparé pour les visiteurs. Relevez le composant indiqué, effectuez la correction adaptée et contrôlez ensuite le site hors de cette session.
Si le courriel n’arrive pas, ne consacrez pas tout le dépannage à le rechercher. Confirmez l’adresse utilisée et demandez au support de l’hébergement quelles informations d’erreur sont disponibles. L’absence du message ne veut pas dire que le site ou les sauvegardes sont perdus.
Désactiver de façon ciblée plutôt que supprimer au hasard
Quand un composant précis est suspecté, vérifiez sa fonction avant de le désactiver. Une extension peut gérer le paiement, les langues, les champs d’un formulaire ou une partie de la mise en page. Le site peut redevenir accessible tout en perdant une fonction essentielle : le retour de l’accueil ne suffit donc pas à valider la manipulation.
Sur une copie de test lorsque c’est possible, changez un seul élément puis reproduisez l’action qui échouait. Conservez le nom, la version et le réglage modifié. Si l’erreur disparaît, demandez-vous encore si un conflit entre composants explique le résultat. La correction durable peut être une mise à jour compatible, un correctif ou un remplacement raisonné.
La suppression complète est une autre opération que la désactivation. Avant de l’envisager, vérifiez les données associées et la procédure de l’éditeur. Évitez également de télécharger une prétendue version réparée depuis un site inconnu pour gagner quelques minutes.
Lire les journaux sans afficher les erreurs aux visiteurs
Le nom du fichier et le moment de l’erreur peuvent orienter le diagnostic. La documentation de débogage WordPress distingue l’enregistrement dans un journal avec WP_DEBUG_LOG de l’affichage à l’écran avec WP_DEBUG_DISPLAY. Un journal temporaire permet d’examiner des détails sans les publier dans les pages.
Faites traiter ces informations dans un environnement maîtrisé : accès limité au fichier, collecte pendant le temps nécessaire, puis retrait du dispositif de diagnostic. Un journal peut contenir plus d’informations que le seul message visible. Ne le joignez pas intégralement à une demande publique.
Une mention liée à la mémoire, à une fonction ou à une classe ne se résout pas systématiquement par une augmentation de limite. Recherchez l’action qui produit l’erreur et le composant qui l’exécute. Modifier une limite sans comprendre le comportement peut seulement déplacer le blocage vers une autre étape.
3. Restaurer si nécessaire, puis vérifier toute la reprise
Le site doit retrouver son fonctionnement utile : publication, contact, réservation ou vente. Une restauration peut être appropriée, mais elle demande de savoir exactement ce qui sera remplacé et quelles données doivent être conservées.
Choisir une sauvegarde complète et vérifier sa date
La documentation WordPress sur les sauvegardes distingue les fichiers du site et sa base de données. Pour préparer une restauration, vérifiez que les éléments nécessaires sont disponibles et que leur état correspond à un moment où le site fonctionnait.
Ne vous fiez pas uniquement à la présence d’un bouton « Restaurer ». Demandez la date de la copie, son périmètre et la possibilité de l’essayer ailleurs. Une sauvegarde non vérifiée peut être incomplète ou contenir déjà le problème. Notez aussi qui peut relancer le site si l’essai ne donne pas le résultat attendu.
Une copie ancienne peut néanmoins être utile pour comparer les versions ou récupérer un fichier. Le choix n’est pas toujours de remplacer tout le site. Le diagnostic doit déterminer si une réparation ciblée préserve mieux les données et réduit le travail de remise à jour.
Préserver les commandes et les contenus récents
Sur un site qui continue à recevoir des données, identifiez ce qui a changé depuis la sauvegarde : commandes, comptes clients, réservations, réponses enregistrées ou nouveaux contenus. Les données récentes risquent d’être remplacées lors du retour à un état antérieur. Faites prévoir leur conservation avant de confirmer l’opération.
Pour une boutique, confrontez les informations du site à celles du prestataire de paiement. Une transaction peut avoir eu lieu même si l’affichage de confirmation a échoué. Le suivi de votre boutique WooCommerce doit donc inclure la cohérence entre paiement, commande et notification au client.
Convenez d’une fenêtre d’intervention et de la manière de gérer les nouvelles demandes pendant ce temps. Si des données doivent être rapprochées après restauration, confiez cette tâche à une personne qui connaît leur structure. Une simple importation improvisée peut créer des doublons ou écraser les enregistrements à garder.
Tester les parcours et documenter la correction
Après reprise, ouvrez le site comme un visiteur anonyme. Testez le menu, plusieurs pages, la recherche et les formulaires. Vérifiez la réception réelle des messages avec une demande de test identifiée. Pour un commerce, utilisez le mode de test prévu par votre prestataire de paiement, puis contrôlez les réglages de production avant la réouverture.
Reconnectez-vous ensuite à l’administration et vérifiez les tâches habituelles : modifier une page, charger une image, consulter une commande. Si une extension reste désactivée, expliquez ce qui manque et quand cette fonction sera rétablie. Ne laissez pas une solution provisoire devenir un oubli silencieux.
Terminez par un compte rendu court : cause confirmée ou encore incertaine, intervention, données conservées, contrôles réalisés et prochaine action. Si les incidents se répètent, un audit des compatibilités et de l’entretien du site peut aider à décider quelles dépendances simplifier, au lieu d’enchaîner les réparations isolées.
