Vous avez lancé une mise à jour — WordPress, plugin, thème, module PrestaShop ou déploiement de code — et le lendemain, des pages s'affichent mal, le formulaire ne fonctionne plus, le panier est vide, ou pire : écran blanc. Des pages qui ne chargent plus correctement après une mise à jour sont un incident, pas un hasard : quelque chose dans la chaîne (code, cache, base de données, compatibilité) a cassé un équilibre fragile.
Chez Apresta, nous recevons ces appels d'urgence plusieurs fois par mois de PME en Hauts-de-France. La bonne nouvelle : dans la majorité des cas, le problème est identifiable et réversible en quelques heures — à condition de ne pas empirer la situation en touchant à tout en même temps. Ce guide vous donne la marche à suivre.
Symptômes : reconnaître un site dégradé post-mise à jour
Les signaux d'alerte sont variés. Un écran blanc (WSOD — White Screen of Death) sur certaines pages ou tout le site, une mise en page cassée (colonnes décalées, menu absent, images géantes), un formulaire de contact qui ne soumet plus, un panier e-commerce qui ne se met plus à jour ou affiche 0 €, des erreurs 500 sur des pages spécifiques, un site ultra-lent après la mise à jour (passé de 2 s à 15 s de chargement), ou des fonctionnalités qui marchaient hier et plus aujourd'hui (slider, recherche, filtres, paiement). Des messages d'erreur PHP visibles en haut de page (si le mode debug est activé) orientent directement vers la cause.
Pour le diagnostic, notez si le problème est apparu immédiatement ou dans les 24 h suivant la mise à jour, si seules certaines pages sont affectées (souvent celles utilisant un plugin ou template spécifique), et si le back-office (admin) fonctionne encore — ou au contraire, est aussi cassé.
Première règle : notez l'heure exacte de la mise à jour, ce qui a été mis à jour (plugin, thème, core, module), et ne lancez pas d'autres modifications avant d'avoir diagnostiqué.
Causes fréquentes après une mise à jour
Incompatibilité plugin / thème / core
Le scénario n°1 : un plugin n'est pas compatible avec la nouvelle version de WordPress, ou le thème ne supporte pas la nouvelle version d'un plugin. Résultat : conflit PHP, écran blanc, erreur fatale.
Mise à jour du thème qui écrase des personnalisations
Fichiers functions.php, templates surchargés (child theme mal configuré), CSS custom perdu. Le site s'affiche avec le thème par défaut ou sans styles.
Cache non vidé
L'ancienne version mise en cache (page, objet, CDN, navigateur) s'affiche avec le nouveau code — ou l'inverse. Résultat : mise en page hybride incohérente. 50 % des « pages cassées » post-mise à jour sont des problèmes de cache.
Erreur PHP ou JavaScript non détectée avant déploiement
Code custom, snippet ajouté via un plugin, modification du functions.php : une mise à jour révèle une incompatibilité de syntaxe ou d'API.
Base de données non migrée
Mise à jour du core qui nécessite une migration de schéma non exécutée. Tables ou colonnes manquantes → erreurs SQL, fonctionnalités cassées.
Problème de permissions fichiers
Déploiement FTP ou CI/CD qui modifie les permissions. PHP ne peut plus lire/écrire certains fichiers → échec silencieux ou erreur 500.
Ressources externes cassées
API tierce modifiée, CDN down, police Google Fonts bloquée, script externe déprécié. La page charge partiellement.
Diagnostic : la procédure d'urgence
Dans les 30 premières minutes, ne paniquez pas et ne lancez pas d'autres mises à jour. Vérifiez si le problème est visible en navigation privée (éliminer le cache navigateur), videz le cache serveur (plugin cache, Varnish, CDN Cloudflare), consultez les logs d'erreur (wp-content/debug.log sur WordPress, logs serveur cPanel, Plesk, SSH), et identifiez quelle mise à jour a déclenché le problème (date, composant).
Dans la première heure, désactivez le dernier plugin mis à jour (via FTP : renommer le dossier du plugin si le back-office est inaccessible), testez si le problème disparaît avec le thème par défaut (Twenty Twenty-Five), vérifiez la version PHP du serveur (certaines mises à jour exigent PHP 8.1+), et contrôlez l'espace disque et la mémoire PHP (memory_limit).
Si le problème persiste, restaurez depuis la dernière sauvegarde fonctionnelle, analysez les conflits plugin par plugin, et mettez en place un environnement de staging pour les futures mises à jour. Guide : sauvegardes et mises à jour : la routine à adopter.
Corrections : rétablir le site étape par étape
Étape 1 — Vider tous les caches
Videz le cache plugin (WP Rocket, W3 Total Cache, LiteSpeed), le cache serveur (Varnish, Redis), le CDN (Cloudflare : Purge Everything), et testez en navigation privée pour éliminer le cache navigateur.
Étape 2 — Identifier le composant fautif
Par élimination : désactivez tous les plugins — le site fonctionne ? Réactivez un par un. Basculez sur le thème par défaut — le site fonctionne ? Le problème vient du thème. Consultez debug.log pour le nom du plugin ou la ligne d'erreur.
Étape 3 — Rollback ciblé
Pour un plugin, restaurez la version précédente (backup ou téléchargement de l'ancienne version sur wordpress.org). Pour un thème, réactivez le child theme ou restaurez les fichiers custom depuis la sauvegarde. Pour le core, en dernier recours, restaurez les fichiers WordPress depuis une sauvegarde complète. Ne mettez pas à jour à nouveau avant d'avoir compris la cause.
Étape 4 — Corriger le conflit
Mettez à jour le plugin conflictuel vers sa dernière version (le bug est peut-être déjà corrigé), contactez l'éditeur du plugin ou du thème, remplacez le plugin défaillant par une alternative, ou adaptez le code custom à la nouvelle API.
Étape 5 — Restaurer depuis la sauvegarde
Si rien ne fonctionne en moins de 2 heures, restaurez la base de données et les fichiers depuis la dernière sauvegarde antérieure à la mise à jour, vérifiez que le site fonctionne, et reportez la mise à jour après tests en staging. Voir : maintenance site web : pourquoi c'est indispensable.
Prévention : ne plus casser le site en production
Sauvegarde complète avant chaque mise à jour (fichiers + base de données), environnement de staging pour tester les mises à jour avant la production, mise à jour progressive (core d'abord, puis plugins un par un, thème en dernier), vérification post-mise à jour (pages clés, formulaire, panier, paiement, back-office), monitoring actif (alertes si le site ne répond plus ou si le temps de chargement explose), et contrat de maintenance avec un prestataire qui gère les mises à jour de façon contrôlée. Pour le monitoring : surveillance et monitoring de site web.
Cas concret : site vitrine à Tourcoing
Un installateur de cuisines (WordPress + Elementor + 22 plugins, 2 500 sessions/mois) a lancé une mise à jour groupée un vendredi soir : WordPress 6.7, Elementor Pro, et 8 plugins d'un coup. Lundi matin : page d'accueil en écran blanc, formulaire de devis inactif, page Réalisations avec mise en page cassée.
Le diagnostic en 45 minutes a révélé une erreur fatale dans un plugin de cache incompatible avec WordPress 6.7, combinée à un cache serveur qui servait l'ancienne version de la page d'accueil avec le nouveau CSS. Les corrections : désactivation du plugin de cache, mise à jour vers une version compatible, purge complète des caches, et remplacement d'un plugin formulaire en conflit JavaScript avec Elementor. Résultat : site fonctionnel en 2 heures. Le client a ensuite souscrit à un contrat de maintenance mensuelle (89 €/mois) pour éviter la récidive.
Priorisation : urgent, important, plus tard
En urgent, videz les caches, consultez les logs d'erreur, désactivez le dernier composant mis à jour. En important, effectuez un rollback ciblé du composant fautif, testez toutes les fonctionnalités critiques (formulaire, panier, paiement), et restaurez depuis la sauvegarde si nécessaire. Plus tard, mettez en place un staging, automatisez les sauvegardes pré-mise à jour, et souscrivez un contrat de maintenance préventive.
FAQ — pages cassées après mise à jour
Dois-je restaurer la sauvegarde immédiatement ?
Non — essayez d'abord de vider les caches et d'identifier le composant fautif (30 min à 1 h). La restauration est l'option de dernier recours, car vous perdrez les contenus modifiés entre la sauvegarde et l'incident.
Qui est responsable si une mise à jour casse le site ?
Si vous avez mis à jour vous-même : c'est un risque connu de l'auto-gestion. Si c'est votre prestataire : il doit corriger dans le cadre de la maintenance. Si c'est une mise à jour automatique non contrôlée : c'est un argument pour désactiver les auto-updates en production.
Faut-il désactiver les mises à jour automatiques ?
En production, oui — ou du minimum les mettre à jour automatiquement en staging d'abord. Les auto-updates de plugins sont la cause n°1 des sites cassés du week-end.
Combien coûte une intervention d'urgence ?
De 150 à 400 € pour un diagnostic + correction simple (cache, plugin conflictuel). De 400 à 1 500 € si restauration complète et reconfiguration. Un contrat de maintenance préventive coûte 60 à 200 €/mois selon la complexité.
Comment tester une mise à jour sans risque ?
Clonez le site en staging (sous-domaine ou environnement local). Lancez la mise à jour sur le clone. Testez les pages clés, le formulaire, le panier. Si tout fonctionne, répliquez en production — avec sauvegarde préalable.
Et maintenant ?
Des pages qui ne chargent plus après une mise à jour, c'est stressant — mais réversible dans la grande majorité des cas. Videz les caches, lisez les logs, isolez le composant fautif, et corrigez ou restaurez. Chaque minute compte pour limiter l'impact sur vos visiteurs et votre chiffre.
Si votre site en Hauts-de-France est en difficulté après une mise à jour, nous intervenons en urgence et mettons en place des processus de maintenance pour que ça ne se reproduise plus.