Bug WordPress après mise à jour : comment corriger rapidement ?

Un bug après une mise à jour WordPress ne signifie pas forcément que le site est perdu. Le plus souvent, le problème vient d’une incompatibilité entre une extension, un thème, une version de PHP ou un cache qui sert encore d’anciens fichiers. En maintenance site WordPress, la priorité est de limiter l’impact pour les visiteurs, d’identifier précisément la mise à jour en cause, puis de revenir à un état fonctionnel sans aggraver la situation.

Si le conflit ne peut pas être isolé sans interrompre l’activité, faites appel à un dépannage WordPress. Lorsqu’un message d’erreur fatale s’affiche après la mise à jour, suivez les vérifications spécifiques à une erreur critique WordPress.

1. Stabiliser le site avant toute manipulation

Évitez d’enchaîner les mises à jour « pour voir » ou de supprimer des fichiers au hasard. Notez l’heure du problème, le message affiché, les pages concernées et la dernière action réalisée : mise à jour d’un plugin, du thème, de WordPress, de PHP ou modification de réglages d’hébergement.

Si le site est accessible, activez temporairement le mode maintenance depuis votre extension de cache ou une extension dédiée. Ne bloquez pas l’accès à l’administration si vous pouvez travailler sans perturber les visiteurs : il est souvent préférable de laisser le site public fonctionner pendant le diagnostic.

  • Faites une sauvegarde complète immédiate : base de données et ensemble des fichiers du site, y compris wp-content, wp-config.php, les fichiers cachés tels que .htaccess s’il existe et les éventuels fichiers personnalisés. Conservez cette copie hors de l’espace public du site.
  • Vérifiez que la sauvegarde est téléchargeable et, idéalement, que vous savez où la restaurer.
  • Ne supprimez pas une extension avant d’avoir exporté ou sauvegardé ses données si elle gère des formulaires, commandes, réservations ou contenus.
  • Prévenez les personnes qui administrent le site afin d’éviter une modification simultanée.

2. Distinguer un bug visible, une erreur critique et une erreur serveur

Le bon correctif dépend du symptôme. Une page blanche, un message « Une erreur critique est survenue », une erreur 500, un écran d’administration cassé ou un panier WooCommerce inopérant n’ont pas forcément la même origine.

Site encore accessible, mais affichage incorrect

Commencez par vider les caches dans cet ordre : cache de l’extension WordPress, cache serveur fourni par l’hébergeur, CDN éventuel, puis cache du navigateur. Testez ensuite dans une fenêtre privée. Après une mise à jour, un fichier CSS ou JavaScript mis en cache peut donner l’impression que le site est défaillant alors que le code est déjà corrigé côté serveur.

Si seul l’éditeur de blocs, un formulaire ou une fonctionnalité JavaScript ne répond plus, ouvrez les outils de développement du navigateur, onglet Console. Une erreur telle que Uncaught TypeError ou une requête REST en erreur peut orienter vers une extension ou un script de thème.

Erreur critique ou page blanche

WordPress peut envoyer un e-mail à l’adresse administrateur avec un lien vers le mode de récupération. Utilisez-le pour désactiver l’extension signalée, puis testez le site. Ce lien est temporaire : ne le transférez pas publiquement et ne considérez pas son utilisation comme un correctif définitif. Il sert à reprendre la main sur l’administration.

Erreur 500 ou site totalement inaccessible

Consultez les journaux d’erreur de l’hébergement. Selon le prestataire, ils se trouvent dans le tableau de bord, dans un fichier error_log ou dans les logs PHP. Une erreur indiquant un fichier précis, par exemple wp-content/plugins/nom-extension/..., est beaucoup plus exploitable qu’un simple message 500.

3. Identifier la mise à jour responsable

Vérifiez les mises à jour récentes dans Tableau de bord > Mises à jour et dans la liste des extensions. Recherchez surtout l’élément modifié juste avant l’incident. Les journaux d’activité, lorsqu’ils étaient activés avant le bug, peuvent confirmer la version installée et l’utilisateur à l’origine de l’action.

Un conflit est fréquent lorsqu’un plugin demande une version de PHP plus récente, qu’un thème surcharge des fonctions WooCommerce devenues obsolètes, ou qu’une extension dépend d’une bibliothèque JavaScript modifiée. Vérifiez les exigences de PHP dans Outils > Santé du site > Informations et dans la documentation de l’extension concernée.

Ne confondez pas corrélation et certitude : une extension mise à jour en dernier est suspecte, mais elle peut simplement révéler un problème plus ancien dans le thème ou une autre extension.

4. Désactiver les extensions sans perdre leurs réglages

Lorsque l’administration est accessible, désactivez d’abord l’extension récemment mise à jour. Rechargez la page défaillante, puis testez les fonctions importantes : page d’accueil, formulaire de contact, connexion, tunnel de commande et espace client selon votre site.

Si vous ne pouvez plus accéder à /wp-admin, utilisez le gestionnaire de fichiers de l’hébergeur ou SFTP. Renommez le dossier de l’extension suspecte, par exemple :

wp-content/plugins/mon-extension devient wp-content/plugins/mon-extension-desactivee.

WordPress détectera son absence et la désactivera. Renommer tout le dossier plugins est utile pour un test d’urgence, mais il désactive toutes les extensions et peut interrompre les paiements, sauvegardes, caches ou formulaires. Réactivez ensuite les extensions une par une, en contrôlant le site à chaque étape.

Avec WP-CLI, si vous y avez accès, la commande wp plugin deactivate nom-du-plugin est plus propre qu’un renommage manuel. Exécutez-la depuis le répertoire contenant wp-config.php.

5. Tester le thème sans modifier le site de production durablement

Si le bug persiste sans l’extension suspecte, activez temporairement un thème WordPress par défaut installé, tel qu’un thème Twenty Twenty-*. Faites-le de préférence sur une copie de préproduction, car le changement de thème peut modifier les menus, zones de widgets ou options visuelles.

Si le problème disparaît, examinez les personnalisations du thème enfant : fichiers functions.php, surcharges WooCommerce dans woocommerce/, scripts personnalisés et constructeur de pages. Une surcharge de template déclarée obsolète dans WooCommerce > État mérite une mise à niveau plutôt qu’une simple réinstallation du plugin.

6. Activer un journal de débogage exploitable

Le débogage doit enregistrer les erreurs sans les afficher aux visiteurs. Dans wp-config.php, avant la ligne indiquant d’arrêter les modifications, utilisez temporairement :

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

Rechargez une seule fois la page qui échoue, puis consultez wp-content/debug.log. Recherchez la première erreur fatale récente et son chemin de fichier. Un message du type Call to undefined function peut signaler un ordre de chargement ou une dépendance manquante ; une erreur de compatibilité de syntaxe peut indiquer une version de PHP inadaptée.

Désactivez ensuite ce débogage ou remettez les constantes à leur état précédent. Le fichier de log peut contenir des chemins internes ou des informations techniques qu’il ne faut pas exposer.

7. Restaurer ou revenir à une version antérieure avec méthode

Quand l’extension responsable est confirmée, trois options existent : attendre un correctif officiel en laissant l’extension désactivée, installer sa version antérieure depuis une source fiable, ou restaurer une sauvegarde antérieure à la mise à jour. Une restauration complète est pertinente si la mise à jour a aussi modifié la base de données ou si plusieurs composants ont été mis à jour ensemble.

Pour un site WooCommerce, vérifiez les commandes passées entre l’heure de la sauvegarde et l’incident avant toute restauration de base de données. Restaurer seulement les fichiers peut ne pas suffire ; restaurer toute la base peut faire disparaître des commandes, comptes ou formulaires récents si aucune procédure de rapprochement n’est prévue.

Après le retour à une version fonctionnelle, désactivez les mises à jour automatiques uniquement pour le composant concerné et pendant le temps nécessaire au diagnostic. N’abandonnez pas durablement les mises à jour de sécurité : testez le correctif sur une préproduction, contrôlez les journaux, puis planifiez sa remise en place.

8. Vérifications avant de considérer l’incident comme résolu

  1. Testez le site connecté et déconnecté, sur ordinateur et mobile.
  2. Vérifiez les formulaires, les e-mails transactionnels, la recherche et les redirections principales.
  3. Pour une boutique, réalisez un parcours complet jusqu’au paiement en mode de test ou avec une commande contrôlée.
  4. Contrôlez Outils > Santé du site, les tâches planifiées et les journaux d’erreur après quelques heures.
  5. Documentez la cause, la version concernée, le correctif appliqué et la sauvegarde utilisée.

Une maintenance site WordPress fiable repose ensuite sur une préproduction, des sauvegardes restaurables, des mises à jour regroupées et testées, ainsi qu’un suivi des versions de PHP, WordPress, thèmes et extensions. Cette organisation réduit fortement le temps de diagnostic lors du prochain incident.

Faut-il désactiver toutes les extensions dès qu’un site WordPress plante ?

Non. Désactivez d’abord l’extension mise à jour juste avant le bug ou celle citée dans les journaux. Désactiver toutes les extensions est un test de diagnostic utile lorsque le site est inaccessible, mais cela peut interrompre des fonctions importantes. Réactivez-les ensuite une par une.

Comment accéder aux fichiers WordPress si l’administration ne répond plus ?

Utilisez le gestionnaire de fichiers de votre hébergeur ou une connexion SFTP. Le dossier des extensions se trouve généralement dans wp-content/plugins. Renommez uniquement le dossier du plugin suspect pour forcer sa désactivation sans supprimer ses fichiers.

Une restauration de sauvegarde efface-t-elle les nouvelles commandes WooCommerce ?

Une restauration de base de données peut supprimer les commandes, clients et contenus créés après la date de la sauvegarde. Avant de restaurer, identifiez les données récentes à conserver et demandez à votre hébergeur si une restauration sélective ou une copie de préproduction est possible.

Peut-on laisser WP_DEBUG activé sur un site en ligne ?

Évitez de le laisser activé durablement. Activez le journal temporairement avec WP_DEBUG_DISPLAY à false afin de ne pas afficher d’informations techniques aux visiteurs, consultez wp-content/debug.log, puis désactivez le débogage après analyse.

Pourquoi le bug apparaît-il parfois seulement pour certains visiteurs ?

Le cache navigateur, le CDN, le cache serveur, une session WooCommerce ou un script chargé sur une page précise peuvent expliquer ce comportement. Testez en navigation privée, connecté et déconnecté, puis purgez les caches concernés avant de conclure que le correctif ne fonctionne pas.

Besoin d’aide avec votre site ?

Que ce soit un bug, une refonte, une récupération de données ou de la maintenance, dites-nous ce qui vous bloque : nous revenons rapidement vers vous avec une solution.

Les détails techniques ou sensibles vous seront demandés uniquement après notre premier échange.

Vous êtes déjà client ?

Contact urgent