Écran blanc après une mise à jour d'extension : la panne WordPress la plus fréquente et la plus évitable
Sommaire
Introduction
Vous avez cliqué sur « Tout mettre à jour » dans votre tableau de bord WordPress, et votre site ne montre plus qu'un écran blanc. Pas de menu, pas de logo, pas même un message d'erreur à recopier dans un moteur de recherche.
C'est la panne la plus fréquente d'un site WordPress, et aussi la plus évitable. Elle ne vient presque jamais du cœur de WordPress : elle vient d'une extension mise à jour qui ne s'entend plus avec le reste de l'installation.
Derrière cet écran blanc, il y a un mécanisme simple à comprendre, une marche à suivre qui fonctionne, et une question de fond que la panne finit toujours par poser. Les trois sont traités ici, et la marche à suivre reste utilisable même si vous restez sur WordPress.
La question de fond est celle de la charge : qui essaie les mises à jour avant qu'elles n'arrivent sur le site public, qui surveille les extensions abandonnées, et qui répond le lundi matin quand la page est blanche. Si la réponse est « moi, quand j'ai le temps », la panne reviendra.
Un clic sur « Tout mettre à jour », et plus rien ne s'affiche
Le symptôme est toujours le même, et il est spectaculaire par son silence. Le navigateur affiche une page entièrement blanche, sans titre, sans erreur, sans rien à cliquer.
Parfois le site public tombe et l'administration répond encore, ce qui est une bonne nouvelle. Parfois les deux tombent ensemble, et vous perdez en même temps votre vitrine et le seul outil qui permettrait de la réparer.
Quand ce n'est pas votre clic qui a déclenché la panne
Un écran blanc peut aussi apparaître sans que personne n'ait touché au site : c'est alors souvent l'hébergeur qui a changé la version du langage exécutant WordPress. Ce scénario voisin est traité dans notre article sur le changement de version de PHP par l'hébergeur, et il se reconnaît à un détail : vous n'avez rien cliqué.
Le reste du temps, la séquence est celle-ci : une notification de mise à jour, un clic groupé, et le site qui disparaît dans la seconde. Entre les deux, aucune étape n'a vérifié que les extensions mises à jour restaient compatibles entre elles.
Pourquoi une seule extension fait tomber le site entier
WordPress appartient à la famille des systèmes de gestion de contenu, et il en partage le principe : le site est assemblé à chaque visite par du code exécuté sur le serveur. Les extensions que vous installez ne sont pas des modules isolés, elles sont du code ajouté dans ce même assemblage.
Un seul processus, aucune cloison
Quand une extension provoque une erreur fatale, ce n'est pas l'extension qui s'arrête : c'est l'ensemble du processus. Le serveur n'a plus rien à renvoyer au navigateur, et le navigateur affiche une page vide.
Aucune cloison ne sépare les extensions les unes des autres, ni des fichiers du thème. Quelques centaines de lignes écrites par un auteur que vous ne connaissez pas peuvent donc interrompre la page de contact de votre entreprise.
Pourquoi la page est blanche plutôt que bavarde
Un serveur correctement réglé pour la production n'affiche pas les messages d'erreur, afin de ne pas exposer de détails techniques aux visiteurs. Le message existe, mais il part dans un journal que vous devez aller chercher.
C'est ce réglage qui rend la panne si déroutante pour un dirigeant : il n'y a rien à lire, donc rien à chercher. Le silence n'est pas une absence de cause, c'est une absence d'affichage.
Les premières minutes : reprendre la main sans rien casser
L'objectif des dix premières minutes n'est pas de comprendre, c'est de remettre le site en ligne. La compréhension vient après, et elle vient beaucoup plus facilement sur un site qui répond.
Reprendre la main par le FTP quand l'administration ne répond plus
Si le tableau de bord est inaccessible, il reste l'accès aux fichiers : le gestionnaire de fichiers de votre hébergeur, ou un client FTP avec les identifiants reçus à l'ouverture du compte. C'est la porte de service, et elle fonctionne même quand le site ne s'affiche plus.
Dans cet accès, les extensions vivent toutes dans un même dossier, sous wp-content. Renommer ce dossier revient à les désactiver toutes d'un coup, sans en supprimer aucune.
Réactiver une par une, dans l'ordre
Après ce renommage, le site réapparaît presque toujours, nu mais vivant. Vous rendez alors au dossier son nom d'origine, puis vous réactivez les extensions une par une depuis le tableau de bord redevenu accessible.
La première qui fait réapparaître l'écran blanc est la coupable, et vous la laissez désactivée le temps de décider de son sort. Ce test est long, il est fastidieux, et c'est le seul qui donne une réponse certaine.
Si vous n'avez qu'un gestionnaire de fichiers dans l'espace client de l'hébergeur, le geste est identique : vous ouvrez wp-content, vous choisissez « renommer », et vous ajoutez un suffixe au nom du dossier. Aucun transfert n'est nécessaire, tout se fait depuis le navigateur.
Si le renommage du dossier ne suffit pas, le suspect est ailleurs : le thème, ou une mise à jour du cœur de WordPress interrompue en cours de route. La marche à suivre reste la même, appliquée cette fois au dossier du thème actif.
Les réflexes qui aggravent une panne de ce type, comme recliquer sur la mise à jour groupée, supprimer avant de comprendre ou restaurer une sauvegarde sans regarder sa date, sont détaillés dans notre article sur le message « Erreur critique sur ce site web ». Ils valent exactement de la même façon pour un écran blanc.
Ce qu'il faut faire de l'extension fautive
Une fois la coupable identifiée, la tentation est de la réactiver en espérant que le problème était passager. Il ne l'était pas : une incompatibilité de code ne se résorbe pas toute seule.
Les trois sorties possibles
La première est de revenir à la version précédente de l'extension, ce qui remet le site debout mais laisse en place un correctif de sécurité non appliqué. C'est une solution d'attente, acceptable quelques jours, pas quelques mois.
La deuxième est de remplacer l'extension par une autre qui rend le même service et qui est encore suivie par son auteur. C'est le choix le plus durable, et aussi celui qui demande de refaire des réglages, parfois une mise en page.
La troisième est de faire corriger le conflit, ce qui suppose un développeur et une relation durable avec lui. Elle se justifie quand l'extension porte une fonction dont le site ne peut pas se passer, comme une prise de rendez-vous ou un catalogue.
Les deux fausses pistes qui occupent une demi-journée
La première est le cache : après la réactivation, une page peut rester blanche parce qu'elle est servie depuis une version gardée en mémoire. Vider le cache avant de conclure évite d'accuser la mauvaise extension.
La seconde est le conflit qui n'apparaît que sur une seule page. Le site semble réparé parce que l'accueil s'affiche, et la panne attend tranquillement sur le formulaire de contact ou sur la fiche produit.
Ce que la coupure laisse comme traces dans Google
Pendant qu'un site renvoie une page vide, le robot d'exploration de Google continue de passer. Ce qu'il enregistre dépend du code de réponse renvoyé par le serveur, et ce code n'est pas visible dans le navigateur.
Ce que le robot a vu pendant la coupure
Une erreur serveur franche est le cas le plus favorable, parce qu'elle dit au robot de revenir plus tard. Une page blanche renvoyée avec un code de succès est le cas le plus défavorable, parce qu'elle fait passer un contenu vide pour le contenu réel de la page.
C'est le mécanisme des pages d'erreur mal signalées, celui qui transforme une coupure de quelques heures en problème durable. Une interruption brève ne laisse en général aucune trace dans les résultats, à condition que le serveur ait dit la vérité sur son état.
Un détail compte pour la suite : une page de maintenance qui renvoie le bon code de réponse protège mieux le référencement qu'un écran blanc laissé en place. C'est l'une des rares choses que l'on peut poser en cinq minutes au milieu d'une panne.
Le bon endroit pour mesurer l'effet réel est la Search Console, qui n'est utile que si elle a été reliée au site avant l'incident. Notre guide sur la configuration de la Search Console indique les rapports à ouvrir après une coupure.
Comment on évite cette panne en restant sur WordPress
Rien de ce qui suit ne suppose de changer de plateforme. Ce sont les cinq précautions qui, prises ensemble, font passer cette panne du statut d'accident à celui d'incident rattrapé en un quart d'heure.
La première est une sauvegarde complète déclenchée avant chaque série de mises à jour, fichiers et base de données ensemble. La deuxième est un site de préproduction, c'est-à-dire une copie où l'on essaie la mise à jour avant de la passer sur le site public.
La troisième est de mettre à jour une extension à la fois, en rechargeant le site entre chaque. La quatrième est de tenir la liste des extensions installées, avec la date de la dernière mise à jour publiée par leur auteur.
L'ordre compte aussi : le cœur de WordPress d'abord, puis les extensions, puis le thème. L'inverse expose le site à une extension qui attend déjà une version du cœur que vous n'avez pas encore installée.
La cinquième : reprendre la main sur les mises à jour automatiques
Les mises à jour automatiques des extensions sont pensées pour la sécurité, et elles ont une contrepartie : elles s'appliquent sans que personne ne regarde le site juste après. Les laisser actives sur un site vitrine qui change peu revient à accepter que la panne se produise un dimanche, sans aucun témoin.
Ces cinq précautions prennent du temps, et c'est précisément leur difficulté : elles ne produisent rien de visible. C'est ce travail invisible qui décide si la prochaine mise à jour sera un non-événement ou une matinée perdue.
Pourquoi personne ne garantit la compatibilité de vos extensions
Les extensions d'un site WordPress sont écrites par des auteurs indépendants, qui ne se connaissent pas et ne testent pas leur code ensemble. Chacun vérifie que son extension fonctionne avec WordPress, aucun ne vérifie qu'elle s'entend avec toutes les autres installées chez vous.
La compatibilité affichée sur la fiche d'une extension est déclarée par son auteur, pas mesurée par un tiers. Elle indique la version de WordPress visée, jamais l'entente avec les autres extensions de votre installation.
Ce que cela implique pour un site d'entreprise
La seule personne capable de constater un conflit est donc celle qui regarde votre site après la mise à jour. Si personne ne regarde, le constat est fait par un client qui n'arrive pas à vous joindre.
C'est la différence de nature entre un site assemblé à partir de briques indépendantes et un site posé sur une plateforme où un seul éditeur répond de l'ensemble. La première approche offre une liberté réelle, la seconde offre une garantie d'intégration.
Réparer, encadrer ou déplacer : les trois issues
Après une panne de ce type, trois chemins existent, et le pire est de n'en choisir aucun. Ne rien décider revient à reprendre le même risque le mois suivant, avec la même surprise.
Réparer et continuer seul est tenable si vous avez du temps et du goût pour cela. C'est la voie qui demande les cinq précautions de la section précédente, appliquées sans exception, y compris les semaines chargées.
Encadrer, c'est confier la pile technique à quelqu'un dont c'est le métier, en écrivant noir sur blanc qui fait quoi et dans quel délai. C'est le rôle d'un contrat de maintenance, et c'est à ses clauses qu'on voit si la charge est réellement portée.
Déplacer, c'est changer de socle pour que la question des extensions et de leur compatibilité ne vous revienne plus. Sur une plateforme hébergée comme Wix, il n'y a pas d'extensions tierces à mettre à jour, et les évolutions sont déployées par l'éditeur après avoir été essayées sur l'ensemble de ses sites.
La contrepartie existe et il faut la dire : vous dépendez de l'éditeur pour les évolutions du socle, et vous ne pouvez pas y greffer n'importe quel code. Pour un site vitrine, une boutique de taille courante ou un site de prise de rendez-vous, cette limite ne se rencontre pas ; pour une application sur mesure, elle se rencontre tout de suite.
Notre comparaison entre un site professionnel sous Wix et sous WordPress détaille ces critères un par un. Une remise à plat n'est pas une rupture : elle recense ce qui existe, conserve ce qui fonctionne, et transporte les adresses pour ne pas perdre ce que le référencement a mis des années à construire.
Qui teste la mise à jour avant qu'elle n'atteigne votre site
Le tableau remet chaque tâche en face de celui qui la porte, selon la façon dont votre site est tenu. Il ne compare pas des outils, il compare des charges de travail.
Tâche | WordPress que vous tenez | WordPress confié à un prestataire | Site Wix conçu par Lacky |
Essai de la mise à jour | À faire vous-même | Prévu au contrat | Fait en amont par l'éditeur |
Sauvegarde avant intervention | À déclencher à la main | Automatisée et contrôlée | Historique de versions intégré |
Site de préproduction | À créer et à maintenir | Fourni par le prestataire | Brouillon de page intégré |
Extensions abandonnées | À repérer seul | Surveillées périodiquement | Sans objet, pas d'extensions tierces |
Compatibilité entre modules | Non garantie | Vérifiée avant chaque passe | Garantie par l'éditeur |
Remise en ligne après panne | Selon vos disponibilités | Selon le délai du contrat | Panne de ce type sans objet |
Ce que cela vous prend | Plusieurs heures par mois | Le suivi du prestataire | Le temps du contenu seul |
Avis client
Une entreprise de services installée dans le sud de la France nous a écrit après exactement ce scénario. Son site WordPress avait disparu un vendredi soir, après une mise à jour groupée lancée depuis le tableau de bord.
« Nous avons perdu le week-end entier à chercher, et le lundi nous avons compris que personne, chez nous, n'avait jamais eu la charge de ces mises à jour. Depuis la refonte, nous ne touchons plus qu'au contenu et le reste ne nous réveille plus. »
Ce qui change après une bascule n'est pas le nombre de visiteurs du jour, c'est le nombre de décisions techniques qui remontent jusqu'au dirigeant. Ce sont elles qui quittent son agenda, et c'est le changement dont les clients nous parlent le plus.
Questions fréquentes
Un écran blanc WordPress signifie-t-il que mon site est piraté ?
Dans la grande majorité des cas, non : c'est une erreur fatale du code, le plus souvent déclenchée par une mise à jour. Un piratage se reconnaît à d'autres signes, comme des pages inconnues ou des redirections vers un autre site.
Puis-je perdre mes contenus à cause de cette panne ?
Non, les textes et les images sont dans la base de données et dans le dossier des médias, et une erreur d'exécution ne les efface pas. Le risque de perte vient de la réparation, pas de la panne, quand on restaure une sauvegarde trop ancienne.
Combien de temps faut-il pour remettre le site en ligne ?
Avec un accès aux fichiers et une sauvegarde récente, la remise en ligne prend en général moins d'une heure. Sans accès aux fichiers et sans sauvegarde datée, le même incident peut occuper plusieurs jours.
Les mises à jour automatiques sont-elles une bonne idée ?
Elles sont utiles pour les correctifs de sécurité du cœur de WordPress, et plus discutables pour les extensions. Sur un site vitrine, il est plus prudent de les déclencher à un moment où quelqu'un peut vérifier le résultat.
Est-ce que le référencement souffre d'une coupure de quelques heures ?
Une coupure courte ne provoque pas de chute durable, parce que le robot revient et retrouve la page. Ce qui fait vraiment mal, c'est une page vide renvoyée comme si elle était normale pendant plusieurs jours.
Faut-il changer de plateforme après une panne de ce genre ?
Pas sur le coup, et pas à cause de la panne elle-même : la bonne question est de savoir si quelqu'un porte cette veille aujourd'hui. Si la réponse est non, la panne reviendra, quelle que soit la plateforme.
Parler de votre site en trente minutes
Un écran blanc est un symptôme, et il dit quelque chose de l'organisation autour du site plus que du site lui-même. Avant d'arbitrer entre réparer et refaire, il est utile de poser la question à voix haute avec quelqu'un qui a déjà vu le cas des dizaines de fois.
Réservez un premier rendez-vous téléphonique de 30 minutes avec un expert Lacky pour discuter de votre projet web et SEO. Prenez rendez-vous dès maintenant.
Lacky est une agence web spécialisée sur Wix, partenaire au niveau Légende, et travaille à distance partout en France et en Belgique. Sa fiche publique sur le Wix Marketplace affiche 4,9 sur 136 avis Wix et plus de 500 projets réalisés depuis 2014.
Un échange de trente minutes ne vous engage à rien, et il suffit en général à savoir si votre site actuel peut être repris ou s'il vaut mieux repartir sur une base saine. C'est aussi l'occasion de regarder ensemble ce que la dernière coupure a laissé dans vos rapports de référencement.
