Commencez par identifier ce qui ne fonctionne plus
Vous ouvrez votre site et un message annonce une erreur critique. Le tableau de bord refuse parfois de s’afficher lui aussi. Dans cette situation, le premier objectif est de retrouver un accès utilisable sans perdre de données. Le second est de comprendre ce qui a provoqué la panne : une page revenue après une manipulation ne prouve pas encore que le problème est corrigé.
Ce guide concerne WordPress installé sur un hébergement auquel vous avez accès. Sur WordPress.com ou une offre entièrement administrée, certaines opérations sur les fichiers sont indisponibles : utilisez les outils proposés dans votre compte ou demandez au support d’effectuer la vérification correspondante. Vous n’avez pas besoin d’installer une nouvelle extension pour suivre le parcours principal. Une extension déjà présente peut toutefois être la cause à isoler.
Recopiez le message exact, l’adresse de la page et l’heure avec votre fuseau. Essayez ensuite trois adresses : l’accueil, un article déjà publié et l’administration. Notez celles qui répondent. Si seule une fiche produit échoue, cette précision réduit considérablement le champ de recherche. Si le navigateur annonce plutôt un certificat invalide, une panne DNS ou une connexion refusée, ne partez pas immédiatement modifier WordPress : le problème peut se situer avant son exécution.
Ouvrez aussi une fenêtre privée. Un contenu conservé en cache peut masquer une panne, ou donner l’impression qu’une correction n’a pas fonctionné. Cette comparaison reste un indice, pas un traitement. Évitez de purger tous les caches ou de relancer toutes les mises à jour avant d’avoir noté ce que vous observez : vous effaceriez des repères utiles.
Choisissez une approche selon les accès dont vous disposez
Le parcours le plus court dépend de ce que vous pouvez encore ouvrir. Les deux approches ci-dessous répondent au même objectif : rendre le site utilisable et isoler le composant en cause. Vous pouvez vous arrêter après la première si elle a identifié la panne et si les contrôles finaux réussissent. Il n’est pas nécessaire de recommencer les mêmes essais par une autre méthode.
Si vous recevez le courriel de récupération, suivez l’approche 1. Elle vous ramène dans l’administration et permet souvent de désactiver le composant signalé sans toucher aux dossiers. Si vous n’avez pas ce lien, mais disposez du gestionnaire de fichiers ou de SFTP, utilisez l’approche 2. Appuyez-vous sur les journaux pour choisir le dossier à isoler, au lieu de renommer tous les composants.
Si aucun de ces accès n’est disponible, votre prochaine étape est le compte d’hébergement : demandez une intervention ciblée ou l’ouverture d’une copie de test. Une restauration complète reste un recours distinct, à préparer avec la sauvegarde et les données récentes. Elle ne doit pas effacer les commandes apparues depuis la copie restaurée. Dans tous les cas, les sections de diagnostic et de vérification qui suivent servent à confirmer le résultat.
Préparez un retour arrière avant de toucher aux fichiers
Dans le compte de votre hébergeur, repérez les sauvegardes et le gestionnaire de fichiers. Vérifiez que vous travaillez sur le bon domaine, et non sur un autre site du même compte. Si une sauvegarde complète récente existe, relevez sa date et ce qu’elle contient. Une copie des fichiers ne contient pas nécessairement les articles, les réglages ou les commandes : une restauration complète demande aussi la base de données correspondante.
Conservez l’état actuel avant une réparation, même s’il est défaillant. Il peut contenir des commandes, des commentaires ou des fichiers ajoutés depuis la dernière sauvegarde saine. Demandez à l’hébergeur un instantané si le site ne permet plus une sauvegarde ordinaire. Une restauration aveugle d’hier peut remettre le site en ligne tout en supprimant les ventes de ce matin. Pour une boutique ou un espace membre actif, faites préciser comment préserver ces données.
Pour un fichier que vous allez modifier, téléchargez une copie dans un dossier local portant la date et le nom du site. Ne laissez pas un fichier de configuration nommé wp-config.php.bak dans un répertoire accessible au public : suivant le serveur, il pourrait être téléchargé. Gardez également une note des noms de dossiers avant et après renommage. Ce relevé évite de devoir deviner leur état d’origine au milieu du dépannage.
Si vous disposez d’une copie de test, commencez dessus. Vérifiez néanmoins qu’elle utilise une version de PHP et des composants comparables à la production. Une panne absente de la copie peut provenir de cette différence. Sans environnement de test, privilégiez une seule correction ciblée, à un moment calme, avec un moyen de revenir immédiatement en arrière.
Approche 1 : utiliser le lien de récupération WordPress
Consultez la boîte correspondant à l’adresse d’administration du site, ainsi que les indésirables. WordPress peut envoyer un message contenant un lien de récupération lorsqu’une erreur PHP fatale est détectée. Toutes les pannes ne déclenchent pas ce mécanisme, notamment lorsque l’exécution échoue trop tôt ou dans certains traitements en arrière-plan. L’absence du message ne signifie donc pas qu’aucune erreur PHP n’existe.
Avant d’ouvrir le lien, vérifiez que le domaine correspond réellement à votre site. Ce lien donne accès à un parcours sensible : ne le publiez pas dans un forum et ne l’insérez pas dans une capture destinée à plusieurs personnes. Connectez-vous avec votre compte d’administration habituel. Lisez l’avertissement affiché et relevez le nom de l’extension ou du thème signalé, ainsi que les informations techniques disponibles.
Le mode de récupération peut mettre un composant en pause pour votre session. Cela explique pourquoi l’administration redevient accessible alors que les visiteurs continuent à voir une erreur. Ne confondez pas cette session de secours avec une réparation globale. Si une extension est clairement identifiée, désactivez-la depuis la liste des extensions, puis testez le site public dans une autre fenêtre. Ne cliquez pas sur Supprimer : la désinstallation peut effacer des données propres au composant.
Si le message nomme le thème, passez à la section consacrée au thème avant de changer son état. Si le lien ne fonctionne plus, utilisez un nouveau message réellement émis par le site ou passez par les fichiers et les journaux de l’hébergeur. N’inventez pas une adresse de récupération à partir d’un exemple trouvé en ligne.
Cherchez l’erreur correspondant à votre test dans les journaux
Un journal d’erreurs est une liste de messages techniques datés. Dans le panneau d’hébergement, cherchez une rubrique nommée Journaux, Logs ou Erreurs PHP. L’emplacement varie selon le prestataire. Ouvrez la page qui échoue une seule fois, notez l’heure, puis examinez les nouvelles lignes. Si le journal utilise UTC et votre horloge une autre zone, faites la conversion : une erreur de la veille n’explique pas nécessairement votre test.
Repérez d’abord les messages fatals, les exceptions non interceptées ou les erreurs de syntaxe. Les avertissements et notices peuvent être utiles, mais leur présence ne prouve pas qu’ils bloquent la page. Un exemple fictif comme Uncaught Error suivi d’un chemin dans wp-content/plugins/exemple/ oriente vers une extension. Le nom du dossier fournit une piste ; il ne démontre pas à lui seul quel composant est responsable du conflit.
La dernière fonction citée peut avoir reçu une donnée incorrecte venant d’un autre endroit. Lisez donc le début du message et les quelques lignes associées, sans tenter de corriger chaque fichier mentionné. Sur une boutique, précisez l’action qui déclenche l’erreur : afficher un produit, modifier un panier ou ouvrir une commande. Cette observation est souvent plus utile qu’une longue copie du journal sans contexte.
Si vous partagez un extrait avec le support, retirez les mots de passe, jetons, adresses personnelles et paramètres privés des requêtes. Gardez le type d’erreur, les noms des composants et l’heure. Ne partagez jamais le contenu complet de wp-config.php. L’hébergeur peut généralement identifier votre installation à partir du domaine et de votre compte client, sans recevoir ses secrets dans un ticket public.
Activez un journal temporaire seulement si vous en avez besoin
Si les journaux de l’hébergeur ne suffisent pas, WordPress possède ses propres réglages de débogage. Leur utilisation est préférable sur une copie de test. Sur la production, demandez d’abord si l’hébergeur propose un journal PHP privé : un fichier debug.log placé dans le dossier public peut contenir des informations sensibles. Masquer les erreurs à l’écran ne rend pas automatiquement ce fichier inaccessible.
Ouvrez la copie de wp-config.php avec un éditeur de texte. Recherchez les constantes commençant par WP_DEBUG. Lorsqu’elles existent, modifiez leurs valeurs au lieu d’ajouter une seconde définition. Conservez leur état initial. Les réglages doivent se trouver avant la ligne finale de configuration et avant le chargement de WordPress. N’ajoutez pas une nouvelle balise d’ouverture PHP au milieu du fichier.
L’exemple suivant écrit dans le journal WordPress standard et masque l’affichage des messages. Utilisez-le sur une copie de test, ou uniquement si l’hébergeur a vérifié que le journal n’est pas accessible au public. Pour un journal privé situé hors du répertoire web, faites fournir le chemin exact par l’hébergeur plutôt que d’en inventer un. Les valeurs true et false sont des booléens, sans guillemets.
Après un seul test reproduisant la panne, récupérez l’extrait utile. Remettez ensuite les constantes dans leur état initial, puis archivez le journal dans un emplacement privé et retirez sa copie publique éventuelle. Ne laissez pas le mode de débogage actif pendant plusieurs jours : il peut accumuler des données inutiles et remplir le stockage. Si la modification déclenche une nouvelle erreur, remettez immédiatement la copie originale du fichier.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Approche 2 : isoler l’extension depuis les fichiers
Si l’administration reste accessible, commencez par l’extension correspondant aux indices du journal ou au changement juste avant la panne. Désactivez-la, puis répétez exactement le test initial. Par exemple, si l’erreur apparaissait sur une page contenant un formulaire, testez cette page et un article sans formulaire. Notez ce qui change. Une page qui s’affiche sans son formulaire ne signifie pas que le formulaire fonctionne de nouveau.
Si l’administration est inaccessible, utilisez le gestionnaire de fichiers de l’hébergeur ou une connexion SFTP autorisée. Repérez l’installation contenant wp-admin, wp-includes et wp-content. Ouvrez wp-content/plugins, puis renommez uniquement le dossier suspect, par exemple exemple-formulaire en exemple-formulaire.pause. Cette opération empêche WordPress de charger les fichiers à leur emplacement habituel. Elle ne désinstalle pas volontairement l’extension et ne remplace pas une sauvegarde.
Rechargez ensuite l’administration et contrôlez la liste des extensions. Après avoir rétabli le nom du dossier, vérifiez son état avant de la réactiver : ne présumez pas qu’un renommage conserve exactement l’état d’activation attendu dans toutes les circonstances. Si la réactivation reproduit la panne, vous disposez d’un indice fort. Laissez le composant désactivé le temps de trouver une version compatible ou une correction validée.
Sans suspect précis, le test de toutes les extensions désactivées est plus fiable sur une copie du site. Sur la production, il peut retirer le paiement, les formulaires, les règles de sécurité ou des contenus. Ne désactivez donc pas tout mécaniquement sur une boutique ouverte. Les extensions obligatoires, certains modules de cache et le code chargé par l’hébergeur ne sont pas nécessairement arrêtés avec les extensions ordinaires : si la panne continue, ne concluez pas trop vite que toute extension est innocente.
Vérifiez le thème et les modifications de code récentes
La panne est apparue après avoir collé un extrait dans le thème ? Commencez par annuler cette modification précise à partir de votre copie. Une parenthèse ou un point-virgule manquant peut suffire à bloquer PHP. Ne supprimez pas au hasard la ligne indiquée par l’erreur : le problème réel peut se trouver juste avant. Si vous ne reconnaissez pas le bloc modifié, transmettez un extrait limité à la personne qui maintient le site.
Pour tester le thème, utilisez de préférence un environnement de test et un thème officiel compatible déjà installé. Depuis Apparence, activez ce thème, puis reproduisez le problème. Si l’erreur disparaît, comparez le thème parent, le thème enfant et leurs versions. Un thème enfant ne fonctionne pas indépendamment de son parent. Ne remplacez pas son dossier sans vérifier les personnalisations qu’il contient.
Changer de thème peut modifier les menus, les modèles, les widgets et la présentation des pages. Prenez donc des captures de référence et notez le thème actif avant le test. Si l’administration est totalement inaccessible, demandez à l’hébergeur de vous aider à activer un thème de secours. Renommer le thème actif sans savoir quel thème de repli est disponible peut créer une autre panne et compliquer le retour arrière.
Ne modifiez pas les fichiers du cœur de WordPress pour faire disparaître un message. Une telle correction peut être écrasée à la prochaine mise à jour et masquer l’incompatibilité réelle. Le bon résultat est un thème corrigé ou une combinaison de versions compatible, pas une ligne supprimée dans WordPress pour contourner le symptôme.
Distinguez incompatibilité PHP, mémoire insuffisante et fichiers incomplets
Une erreur apparue juste après un changement de version PHP mérite une vérification spécifique. Relevez l’ancienne version, la nouvelle et les exigences des composants concernés. Une version plus récente peut révéler une incompatibilité ancienne ; rester indéfiniment sur une version obsolète n’est pas une réparation. Sur une copie, testez les mises à jour des composants et demandez au prestataire quelle version maintenue convient à l’ensemble.
Un message indiquant que la mémoire autorisée est épuisée n’appelle pas automatiquement une augmentation maximale des limites. Notez l’action concernée et la quantité annoncée. Une importation volumineuse, une génération d’images ou une boucle défectueuse n’exigent pas le même traitement. Commencez par réduire la taille du traitement lorsque c’est possible, puis vérifiez les limites réelles avec l’hébergeur. Une valeur ajoutée dans WordPress ne peut pas forcément dépasser la limite du serveur.
Si une mise à jour s’est interrompue, les fichiers d’une extension ou du cœur peuvent être incomplets. Vérifiez l’espace disponible, les messages de l’opération et les versions affichées. Ne superposez pas plusieurs tentatives de mise à jour. La remise en place de fichiers propres doit suivre la procédure officielle du composant, en conservant les données et les personnalisations. Pour le cœur, ne remplacez pas aveuglément wp-content et le fichier de configuration.
Enfin, une erreur de lecture ou d’écriture peut venir des permissions ou du propriétaire des fichiers. N’appliquez pas 777 à tout le site pour essayer : cela élargit dangereusement les possibilités d’écriture et ne résout pas un mauvais propriétaire. Faites corriger le chemin précis et l’identité du processus par l’hébergeur, puis vérifiez seulement l’opération qui échouait.
Quand une extension de diagnostic devient pertinente
Si le site répond de nouveau mais que le conflit est difficile à isoler, un outil de diagnostic peut compléter les journaux. Il ne doit pas être la première tentative sur un site déjà inaccessible. Vérifiez son origine officielle, sa compatibilité et son fonctionnement avant de l’ajouter. Un outil qui affiche des informations dans l’administration ne pourra pas toujours aider lorsque PHP s’arrête avant son chargement.
Choisissez l’outil pour une question précise : quel composant déclenche une erreur, quelle requête consomme trop de ressources, ou quelle combinaison provoque le conflit ? Ne multipliez pas les extensions de réparation générale. Sur une copie, un test comparant le même parcours avec une seule variable modifiée produit souvent une réponse plus nette qu’un tableau rempli d’alertes sans rapport avec la panne.
Une fois le diagnostic terminé, retirez les outils temporaires devenus inutiles et vérifiez que leurs éventuels journaux ne restent pas publics. Aucun plugin ne remplace une correction du composant incompatible, une restauration cohérente ou une intervention de l’hébergeur sur le serveur. Vous devez pouvoir expliquer ce qui a changé et pourquoi cette modification correspond à l’erreur observée.
Vérifiez la réparation et préparez un dossier d’assistance utile
Reprenez votre liste de départ : accueil, article, administration et action qui déclenchait l’erreur. Testez aussi en visiteur déconnecté. Sur une boutique, vérifiez le panier et le parcours de commande en mode de test, sans provoquer de paiement réel. Sur un site de services, contrôlez les formulaires et la réception des messages avec les moyens habituels du site. Une réponse visuelle correcte ne prouve pas que les fonctions retirées pendant le dépannage ont été rétablies.
Examinez les nouvelles lignes du journal après ces essais. L’objectif n’est pas d’obtenir un journal parfaitement vide, mais de vérifier que l’erreur fatale liée à la panne ne revient plus. Confirmez que le débogage temporaire est désactivé et que chaque dossier a retrouvé un nom documenté. Notez la correction, les versions conservées et la date. Cette courte fiche sera utile si la panne réapparaît après une future mise à jour.
Si vous devez demander de l’aide, fournissez un dossier bref : domaine, heure du dernier test, page concernée, message exact, changements récents, versions connues et manipulations déjà réalisées. Précisez si vous avez une sauvegarde restaurable et une copie de test. Demandez une réponse ciblée, par exemple une vérification du journal PHP à cette heure, plutôt qu’une réinstallation générale. Vous éviterez ainsi de répéter des essais qui n’ont rien changé.
Si aucune cause n’est identifiée, arrêtez les modifications successives et revenez à l’état documenté le plus stable. Une intervention assistée vaut mieux qu’une accumulation de changements contradictoires. La réparation est terminée lorsque le site fonctionne, que les fonctions nécessaires sont présentes et que vous savez quelle cause a été traitée ; pas simplement lorsque le message d’erreur a disparu une fois.
