Site WordPress cassé la veille d'une livraison client : le plan d'urgence heure par heure

Le scénario : livraison demain 10 h, et ce soir le site affiche une erreur critique, une page blanche, ou un layout détruit. La pire chose à faire est aussi la plus tentante : corriger frénétiquement en production. Voici l'ordre des opérations qui maximise vos chances d'être livrable demain matin.

H+0 à H+1 : pourquoi geler avant de réparer ?

Parce qu'un site cassé peut encore s'aggraver, et que chaque action non documentée détruit de l'information de diagnostic.

1. Documentez le symptôme (10 min) : captures d'écran, URL exactes touchées, message d'erreur complet, heure d'apparition. Notez la dernière action connue : mise à jour de plugin ? Modification CSS ? Migration ? Dans la grande majorité des pannes de veille de livraison, la cause est la dernière chose que quelqu'un a faite.
2. Sauvegardez l'état cassé (20 min) : fichiers plus base de données, même cassés. Contre-intuitif mais indispensable : si une « réparation » aggrave les choses, vous devez pouvoir revenir à l'état cassé initial, qui contient peut-être des contenus saisis aujourd'hui que la sauvegarde d'hier n'a pas.
3. Verrouillez l'accès (5 min) : une seule personne intervient. Prévenez l'équipe : personne ne « tente un truc » en parallèle. Activez une page de maintenance si le site est public.
4. Localisez la dernière sauvegarde saine et vérifiez-la (15 min) : c'est votre plan B. Notez son horodatage et ce qui a été produit depuis (contenus, réglages). C'est le coût exact d'une restauration.

H+1 à H+2 : comment diagnostiquer par élimination ?

L'ordre qui suit va du plus probable au moins probable :

1. Les logs d'abord : log d'erreurs PHP de l'hébergeur, puis WP_DEBUG et WP_DEBUG_LOG à true dans wp-config.php (jamais WP_DEBUG_DISPLAY sur un site public). Une erreur fatale PHP nomme le fichier coupable, neuf fois sur dix un plugin ou le thème.
2. Le test plugins : renommez le dossier du plugin suspect via FTP/SSH (ou wp plugin deactivate en WP-CLI). Si le site revient, c'est réglé : vous déciderez à tête reposée s'il faut le remplacer. Pas de suspect ? Désactivez tout, réactivez un par un. C'est mécanique et ça tient en 20 minutes.
3. Le test thème : basculez sur un thème par défaut (Twenty Twenty-Five). Si le site revient, le problème est dans le thème, souvent une fonction ajoutée dans functions.php.
4. Les causes d'infrastructure : limite mémoire PHP, version PHP changée par l'hébergeur, certificat SSL, base de données corrompue (wp db check), disque plein. Cinq vérifications, dix minutes.
5. L'hypothèse piratage : si rien de tout ça ne colle (redirections étranges, fichiers inconnus, code obfusqué), changez d'urgence tous les mots de passe et passez en procédure de nettoyage d'un site piraté. Ce n'est pas un cas d'école : le rapport Patchstack a recensé 11 334 vulnérabilités WordPress en 2025, en hausse de 42 %, dont environ 9 sur 10 dans les plugins, et les failles les plus ciblées sont désormais exploitées dans un délai médian de quelques heures après leur divulgation. Un plugin pas à jour depuis trois semaines suffit.

H+2 : réparer ou restaurer, comment trancher ?

C'est LA décision de la soirée, et elle se prend sur un critère simple : le temps certain contre le temps espéré.

La restauration n'est pas un échec, c'est un choix d'ingénierie : un temps de retour connu (1 à 2 h) contre un débogage inconnu. La seule vraie question est ce que coûte la perte des modifications faites depuis la sauvegarde, d'où l'étape H+0.4.

H+3 à H+6 : la remise en état

Selon la branche choisie :

• Branche réparation : appliquez le correctif, puis testez le parcours critique de la livraison de demain. Pas tout le site, le parcours que le client va regarder : pages de la démo, formulaires, tunnel d'achat si WooCommerce. Refaites une sauvegarde complète de l'état réparé.
• Branche restauration : restaurez, vérifiez le parcours critique, rejouez les modifications perdues en les notant une par une, re-sauvegardez. Et surtout : n'appliquez aucune mise à jour ce soir. La veille d'une livraison, on gèle.

Dans les deux cas, terminez par un contrôle d'hygiène minimal : WP_DEBUG remis à false, page de maintenance retirée, cache vidé, test depuis un navigateur en navigation privée et un mobile. Si la livraison portait sur une fonctionnalité sur mesure (un checkout WooCommerce custom par exemple), testez ce parcours en priorité : c'est lui qui sera regardé en premier.

Faut-il prévenir le client ce soir ?

Si le site est de nouveau debout et la livraison tient : non. Vous communiquerez l'incident *a posteriori* si le contexte le justifie. Si à H+4 la livraison de 10 h est compromise : oui, ce soir, avec un message court qui contient trois choses. Le problème en une phrase, ce qui est déjà fait, et une nouvelle heure de livraison réaliste (prenez de la marge : annoncer 16 h et livrer à 14 h vaut mieux que l'inverse). Un report annoncé à 22 h la veille passe. Le même report annoncé à 9 h 45 détruit la confiance.

Le lendemain : les 3 mesures pour que ça ne se reproduise pas

1. Sauvegardes automatiques quotidiennes, externalisées, testées : la décision de H+2 n'est confortable que si la sauvegarde a moins de 24 h.
2. Un staging systématique : plus aucune mise à jour ni modification directe en production sur un site en cours de livraison. C'est la cause numéro un qu'on retrouve dans ces soirées-là.
3. Un gel des changements à J-2 avant toute livraison : plus de mises à jour de plugins, plus de changements d'hébergement. Les mises à jour de sécurité attendent 48 h ou passent par le staging.

Ces trois réflexes relèvent d'une bonne hygiène de production, la même qui sépare un développement custom propre d'un montage fragile.

En bref

Un site cassé la veille d'une livraison se gère par l'ordre, pas par la vitesse : geler, diagnostiquer, trancher entre réparer et restaurer. La restauration n'est pas un aveu d'échec, c'est le choix d'un temps de retour connu. Et le lendemain, trois réflexes d'hygiène suffisent pour que la soirée ne se rejoue pas.