Votre site fonctionnait hier soir. Ce matin, il affiche une page blanche, un message d'erreur ou une version à moitié cassée, et personne n'y a touché.

Vous cherchez à comprendre pourquoi un site qui n'a pas bougé peut tomber tout seul ? Dans la très grande majorité des cas, la réponse tient en une ligne : votre hébergeur a changé la version du langage qui fait tourner le site.

Ce changement n'est pas une erreur de sa part, et il n'était pas évitable : les anciennes versions de PHP ne reçoivent plus de correctifs de sécurité, donc les hébergeurs les retirent. Le problème est ailleurs, et il vous revient : le code de votre thème et de vos extensions doit suivre ce rythme, et quelqu'un doit s'en occuper.

Cet article explique ce qui se passe réellement, ce qui casse, ce que vous pouvez faire ce matin même, et pourquoi la panne reviendra tant que la pile technique se maintient à la main. Il se termine sur la seule question qui compte vraiment : qui porte cette veille, et est-ce votre métier.

Le site fonctionnait hier soir, il est cassé ce matin

Le symptôme est presque toujours le même, à quelques variantes près. Le site affiche une page entièrement blanche, ou un message en petits caractères sur fond clair, ou encore une mise en page désarticulée dont les menus ont disparu.

Parfois seule l'administration tombe, et les visiteurs continuent de voir le site normalement. Parfois c'est l'inverse : la partie publique ne répond plus et vous pouvez encore vous connecter, ce qui donne une fausse impression de normalité.

Sur un site WordPress, le message est souvent celui que nous avons détaillé hier à propos de l'erreur critique sur ce site web, qui masque volontairement la panne réelle. Le point commun de toutes ces variantes est la même cause profonde : du code écrit pour une version du langage, exécuté par une autre.

Le courriel que personne ne lit

Dans presque tous les cas, l'hébergeur a prévenu. Un courriel est parti plusieurs semaines avant la bascule, parfois plusieurs mois, avec un objet technique et un calendrier précis : la date de basculement y figurait noir sur blanc.

Ce courriel arrive sur l'adresse administrative du compte d'hébergement, qui n'est pas toujours celle que vous consultez tous les jours. Quand il atterrit sur une ancienne adresse ou dans les indésirables, la bascule devient une surprise, alors qu'elle était annoncée de longue date.

Pourquoi un hébergeur retire une version de PHP

PHP est le langage dans lequel WordPress, son thème et ses extensions sont écrits. Il ne tourne pas sur votre ordinateur mais sur le serveur de votre hébergeur, qui fabrique chaque page à la demande avant de l'envoyer au navigateur du visiteur.

Le passage à PHP 8 a marqué le plus gros saut de ces dernières années, et les bascules suivantes, d'une version 8 vers la suivante, obéissent au même mécanisme. Le nom de la version change, la mécanique qui casse votre site ne change pas.

Chaque branche du langage a une durée de vie publique, annoncée des années à l'avance. Elle reçoit deux ans de support complet, puis deux années supplémentaires limitées aux seules failles critiques : au-delà, plus rien ne sort.

Ce calendrier est public et se consulte branche par branche sur le site officiel du langage. C'est la source la plus fiable pour savoir si la version qui fait tourner votre site est encore suivie, ou si elle en est déjà sortie.

Passé cette échéance, une faille découverte dans le langage n'est plus corrigée pour cette version. Un hébergeur qui laisserait des milliers de sites sur une version abandonnée exposerait ses clients et son infrastructure à un risque qu'il ne peut pas assumer.

Le cycle de vie d'une version, quatre ans en tout

Cette mécanique explique le rythme que vous subissez. Un serveur web reste en service bien plus longtemps que la version du langage qu'il exécute, donc un changement de version revient en moyenne tous les trois ou quatre ans sur un site qui vit.

Quatre ans, c'est aussi le temps pendant lequel un site s'alourdit : extensions ajoutées une par une, bouts de code copiés d'un forum, thème personnalisé par un prestataire de passage. La bascule arrive donc au pire moment possible, sur un site devenu bien plus fragile que le jour de sa mise en ligne.

Ce qui casse concrètement dans un site WordPress

Une nouvelle version du langage ne casse pas tout, et c'est ce qui rend le diagnostic déroutant. Elle supprime des fonctions anciennes, durcit des règles qui étaient tolérées et transforme en erreur fatale ce qui n'était jusque-là qu'un avertissement discret dans les journaux.

Le thème et ses fonctions sur mesure

Le thème est le premier suspect, surtout s'il a été acheté une fois et jamais mis à jour depuis. Un thème abandonné par son auteur ne recevra jamais la correction qui le rend compatible, et il reste le point de blocage le plus fréquent de ce type de panne.

Les fonctions ajoutées au fil du temps dans les fichiers du thème sont le second suspect. Elles ont souvent été écrites vite, pour régler un détail d'affichage ou un besoin ponctuel, et personne ne les a documentées.

Les extensions, et surtout les plus anciennes

Une extension réellement maintenue passe la bascule sans rien dire. Une extension dont la dernière mise à jour remonte à plusieurs années est une bombe à retardement, parce qu'elle contient encore des appels que le langage ne comprend plus.

Le cumul est le vrai danger, bien plus que l'âge d'un composant isolé. Un site de TPE porte couramment plusieurs dizaines d'extensions, et il suffit d'une seule incompatible pour que la page entière refuse de s'afficher.

Les scripts maison ajoutés au fil des ans

Entre un suivi statistique collé dans un fichier, un formulaire bricolé et un connecteur vers un outil de gestion, un site accumule du code que plus personne ne revendique. Ces ajouts ne sont couverts par aucune mise à jour automatique et sortent du périmètre de n'importe quel éditeur.

La marche à suivre, dans l'ordre, le matin de la panne

La panique fait perdre du temps et détruit des indices utiles. La bonne séquence consiste à constater, revenir en arrière, puis seulement ensuite traiter la cause.

Premier geste : ouvrir l'espace client de l'hébergeur et regarder quelle version de PHP est active sur le site. Si elle a changé dans les jours précédents, vous avez votre explication en quelques secondes, sans avoir touché au site.

Deuxième geste : chercher le journal d'erreurs, qui se trouve dans ce même espace client. Il nomme le fichier et la ligne exacte qui bloquent, ce qui désigne l'extension ou le thème fautif sans aucune manipulation risquée.

Revenir à l'ancienne version, quand c'est encore possible

La plupart des hébergeurs laissent choisir la version de PHP depuis l'espace client, et certains conservent l'ancienne quelques semaines après la bascule. Repasser sur celle d'avant remet le site en ligne immédiatement et vous rend le temps de travailler proprement.

Cette marche arrière est un sursis, jamais une solution. L'échéance finit par tomber pour de bon, et un site laissé sur une version sans correctifs devient un risque de sécurité pour vous comme pour vos visiteurs.

Troisième geste, une fois le site revenu : faire une sauvegarde complète des fichiers et de la base de données. Tout ce qui suit consiste à mettre à jour, désactiver ou remplacer des composants, et une copie fiable est ce qui autorise à essayer.

Quatrième geste : mettre à jour le thème et les extensions, puis retenter la bascule sur une copie de test plutôt que sur le site public. Un hébergeur sérieux propose un site de préproduction en quelques clics, et c'est là que l'opération doit se jouer.

Les quatre réflexes qui aggravent la situation

Le premier est de tout mettre à jour d'un coup, en pleine panne, sans sauvegarde préalable. On ajoute alors une seconde cause à la première, et plus personne ne sait laquelle agit.

Le deuxième est de supprimer l'extension suspecte au lieu de la désactiver. La désactivation est réversible et conserve les réglages, la suppression efface souvent des données sans retour.

Le troisième est de modifier un fichier du cœur de WordPress pour faire taire l'erreur. La mise à jour suivante écrasera la modification, et le problème revient exactement au même endroit, quelques semaines plus tard.

Le quatrième est d'attendre, en espérant que cela se répare tout seul. Un site hors ligne plusieurs jours perd des demandes entrantes et des positions dans les résultats, et le rattrapage prend bien plus de temps que la panne elle-même.

Pourquoi cela recommencera, et à quel rythme

Un site WordPress n'est pas un produit fini, c'est un assemblage vivant. Le cœur, le thème, les extensions et le langage du serveur évoluent chacun à leur propre rythme, et personne ne synchronise ces rythmes à votre place.

Sur une année ordinaire, cela représente plusieurs mises à jour du cœur, des dizaines de mises à jour d'extensions et, tous les trois ou quatre ans, un changement de socle comme celui qui vous occupe aujourd'hui.

Qui porte la veille, et est-ce votre métier

La vraie question n'est pas de savoir si WordPress est un bon ou un mauvais outil : c'est un outil puissant, utilisé par une part considérable du web. Elle est de savoir qui lit les annonces de fin de support, qui teste avant la bascule et qui se lève le matin où le site est tombé.

Si la réponse est vous, le coût réel de votre site n'est pas celui de sa création : c'est le temps qu'il vous prend quand il tombe. Si la réponse est un prestataire, elle doit figurer noir sur blanc dans les clauses d'un contrat de maintenance, avec un délai d'intervention et un périmètre explicite.

Ce que change une plateforme dont le socle est tenu par l'éditeur

Sur Wix, la question de la version du langage ne vous est jamais posée. L'éditeur fait tourner l'ensemble de l'infrastructure, teste les évolutions du socle sur son parc entier, puis les déploie sans intervention de votre part.

L'hébergement, le certificat, les sauvegardes et les mises à jour techniques sont inclus et, du point de vue du client, invisibles. Il n'y a ni extension à surveiller ni thème abandonné, parce que les fonctions sont natives et maintenues par l'éditeur.

Cela a aussi un effet mesurable sur la performance, puisque le temps de réponse du serveur ne dépend plus de la mutualisation de votre offre d'hébergement, sujet que nous avons traité dans notre guide sur le temps de réponse serveur et le référencement. Le socle technique devient l'affaire de l'éditeur, et votre travail redevient le contenu et la visibilité.

La contrepartie existe et il serait malhonnête de la passer sous silence. Vous dépendez de l'éditeur pour les évolutions du socle, et un besoin très spécifique, par exemple une application sur mesure, sortira du périmètre de la plateforme.

Pour une entreprise de services, un artisan, un commerçant ou une TPE, cet échange est très largement favorable. Nous avons comparé les deux approches point par point dans notre article sur un site professionnel sous Wix et sous WordPress, et la conclusion vaut pour la très grande majorité des sites de cette taille.

Rester sur WordPress ou déplacer le problème

Les deux options sont défendables, et le choix ne se fait pas sur une préférence technique. Il se fait sur une estimation honnête du temps que vous pouvez consacrer à la maintenance de votre site.

Rester sur WordPress est raisonnable si le site remplit une fonction que la plateforme ne couvre pas, ou si vous avez déjà un prestataire qui porte cette charge avec un engagement écrit. Dans ce cas, le bon réflexe est de faire poser un calendrier de veille et une préproduction, pour que la prochaine bascule soit un non-événement.

Déplacer le problème est raisonnable si le site est un site vitrine, si personne en interne ne suit la technique et si chaque panne vous coûte une journée entière. La bascule se prépare alors comme une opération de référencement, avec un inventaire des adresses existantes et un plan de redirections, comme nous l'avons décrit dans notre plan de migration de WordPress vers Wix sans perdre son référencement.

Dans un cas comme dans l'autre, la décision se prend à froid, pas le matin de la panne. C'est précisément pourquoi il est utile de faire regarder votre site avant qu'il tombe une nouvelle fois.

Qui porte la mise à jour du socle technique

Le tableau ci-dessous résume la même question posée sous trois angles. Il ne compare pas des outils entre eux mais la charge que chacun porte, ce qui est la seule comparaison utile pour un dirigeant.

Critère	WordPress que vous maintenez	WordPress confié à un prestataire	Site Wix conçu par Lacky
Version du langage serveur	À choisir et tester vous-même	Choisie et testée par le prestataire	Gérée par la plateforme, sans action
Fin de support annoncée	Courriel d'hébergeur à interpréter	Traitée dans le contrat	Invisible pour vous
Compatibilité du thème	À vérifier à chaque bascule	Vérifiée avant la bascule	Sans objet, aucun thème à maintenir
Extensions et modules	Mises à jour par vous	Suivies par le prestataire	Fonctions natives testées en amont
Retour arrière	Selon l'offre d'hébergement	Préparé avant intervention	Sans objet
Sauvegardes	À mettre en place soi-même	Incluses et vérifiées	Automatiques chez l'éditeur
Site indisponible	Possible à chaque mise à jour	Fenêtre planifiée à l'avance	Très rare, hors de votre charge
Temps que cela vous prend	Variable, souvent au mauvais moment	Délégué, avec un interlocuteur	Quasi nul sur le socle

Avis client

Un cabinet de conseil installé en région parisienne nous a écrit après ce scénario exact. Son site WordPress était tombé un lundi matin, trois semaines après un courriel d'hébergeur que personne n'avait ouvert.

« Le site est resté inaccessible deux jours, et nous avons compris que le problème n'était pas la panne mais le fait que plus personne ne suivait ce site. Nous avons demandé une remise à plat, et depuis la bascule nous ne nous occupons plus que du contenu. »

Ce retour résume exactement le déplacement dont parle cet article. Le site n'est pas devenu magique, mais la veille a changé de mains, et c'est tout ce qui était demandé.

Questions fréquentes

Mon hébergeur peut-il repasser le site sur l'ancienne version de PHP ?

Souvent oui, depuis l'espace client, et parfois pour quelques semaines seulement. C'est une solution d'attente utile pour remettre le site en ligne, mais la version finira par être retirée définitivement.

Faut-il prévenir l'hébergeur que le site est tombé ?

Le signaler est utile, surtout pour obtenir le journal d'erreurs et la date exacte de la bascule. En revanche l'hébergeur n'est pas responsable du code de votre thème et de vos extensions, qui reste de votre côté de la frontière.

Mon site est en ligne mais mon administration ne répond plus, est-ce la même cause ?

C'est fréquent, et le mécanisme est identique. Une extension incompatible chargée uniquement dans l'administration suffit à la bloquer, pendant que le reste du site continue de s'afficher normalement.

Combien de temps faut-il pour remettre un site en ligne après ce type de panne ?

Quand la cause est une seule extension et que l'accès à l'hébergement existe, cela se compte en heures. Quand le thème est abandonné et le site sans sauvegarde, il faut arbitrer entre réparer et refaire, et le délai dépend de cet arbitrage.

Est-ce que passer sur Wix supprime vraiment ce risque ?

Ce risque précis disparaît, parce que la version du langage du serveur n'est plus de votre ressort. Il reste bien sûr le travail éditorial et le référencement, mais plus aucune panne de socle à surveiller.

Peut-on migrer sans perdre le référencement déjà acquis ?

Oui, à condition de recenser toutes les adresses existantes et de poser les redirections avant la bascule, jamais après. C'est le cœur du travail de migration, et c'est ce qui sépare une refonte réussie d'une chute de trafic.

Demander un devis pour votre nouveau site

Si votre site est tombé une fois à cause d'un changement de version, il tombera de nouveau. Avant d'arbitrer entre réparer et déplacer, il est utile de savoir ce que porterait réellement un site conçu pour ne plus vous demander cette veille.

Décrivez-nous votre activité et vos objectifs, nous vous établissons un devis détaillé sous 24h pour votre nouveau site vitrine Wix. Cliquez ici pour nous contacter.

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 la présente comme agence certifiée Wix depuis janvier 2014, avec plus de 500 projets référencés et les avis laissés par ses clients.

Un devis ne vous engage à rien et il vous donne une base pour décider. C'est aussi la façon la plus simple de savoir si votre site actuel peut être repris ou s'il vaut mieux repartir sur une structure saine.