Ton site est tout cassé après une mise à jour ? Voilà comment réparer en 90 minutes

La page blanche, le 500, le fameux “This site is experiencing technical difficulties.”

J’ai vu ce truc 37 fois en 6 ans (oui, je note), toujours à 02:13 un dimanche. Et à chaque fois, c’est presque toujours évitable.

Tu veux réparer vite ? OK, on y va.

3 causes qui cassent ton site après une mise à jour

Les plugins sont souvent les coupables. 2 plugins incompatibles peuvent suffire à générer un fatal error (Parse error ou Uncaught TypeError) (testé sur WP 6.4 avec PHP 8.1, j’ai déjà vu ça).

Le PHP qui a changé. Passer de PHP 7.4 à PHP 8.1 peut claquer les fonctions obsolètes dans ton thème (warning, fatal). 1 appel à une fonction supprimée = page 500.

La config serveur (.htaccess, NGINX conf) mal ajustée après une migration. Un RewriteRule foireux et ton site redirige en boucle (ou renvoie 403). C’est basique, mais ça casse tout.

💡 Conseil : commence par vérifier la version PHP et les logs d’erreur (500 erreurs = log Apache/Nginx + PHP). Si t’es sur OVH, check le dashboard en 30 s.

Je te donne l’ordre : logs → PHP → plugins/themes → config serveur. Toujours dans cet ordre. Pourquoi ? Parce que 7 fois sur 10, le log te dit exactement ce qui merde.

1 check rapide à faire en 60 secondes

Ouvre ton FTP ou le dashboard de ton hébergeur. Trouve error_log ou active le mode debug.

Si tu utilises WordPress, crée un fichier phpinfo.php contenant <?php phpinfo(); ?> à la racine et ouvre-le. Tu verras la version PHP (ex : 8.1.12), les extensions chargées, la memory_limit. 30 s chrono.

Si t’as accès SSH, un tail -n 200 /var/log/nginx/error.log ou journalctl -u php8.1-fpm -n 200 te mettra direct sur la piste. (Oui, j’aime SSH. Ça sauve des soirées.)

Regarde le code HTTP : si tu reçois 500 c’est un bug PHP. Si c’est 503 c’est souvent une tâche Cron qui a planté ou un service arrêté.

⚠️ Attention : désactive immédiatement les plugins de cache après une grosse modif (WP Super Cache, LiteSpeed, etc.). Le cache peut masquer les erreurs et te faire perdre du temps.

5 outils gratuits que j’utilise pour débugger un site cassé

Chrome DevTools — gratuit, déjà dans ton navigateur. Réseau, console JS, performance. Tu peux repérer les 404 qui font tomber des APIs.
curl — en CLI, lance curl -I https://tonsite.fr pour voir les headers. Si tu as un 500 côté backend, curl ne ment pas.
WP-CLI — si ton site est WP, wp plugin deactivate --all sauve des vies (testé sur un site de 2 Go, restore en 8 min). Permet de dissocier un plugin fautif sans toucher à la BDD via phpMyAdmin.
Sentry (free tier) — 1 jour pour l’installer, et tu vois les exceptions PHP/JS avec stacktrace. J’ai attrapé un fatal qui ne remontait nulle part grâce à Sentry en 2025.
Cloudflare (plan gratuit) — mode développeur, purge cache, et surtout protection DDoS basique. Si ton site renvoie 521 ou 523, Cloudflare te dira si le problème vient du serveur.

Chaque outil couvre un angle. Utilise-les ensemble, pas en silo.

📌 À retenir : installe WP-CLI et active Sentry en staging avant de déployer en prod. Tu gagnes souvent 30–60 minutes sur un incident.

2 stratégies pour restaurer proprement sans tout bousiller

Stratégie A — rollback propre : restaurer un snapshot prend 10–30 minutes sur un VPS de 20 Go (dépend de ton host). Tu rétablis l’état connu bon, puis tu reproduis la mise à jour sur un staging. Pas envie de jouer au héros en prod ? Fais ça.

Stratégie B — isoler le coupable : si tu ne peux pas restaurer, désactive tous les plugins (WP-CLI ou renommage du dossier plugins), passe à un thème par défaut (Twenty Twenty-Three), puis réactive plugin par plugin. C’est chiant mais efficace pour isoler (compte 20–90 minutes selon nombre de plugins).

J’ai testé les deux. Sur un client à Lyon (site e-commerce avec 1200 produits), rollback OVH + vérif BDD = 22 minutes pour revenir online. Tentative de fix direct = 3 heures et un ticket support.

Du coup, si t’as moins de 2 heures pour réparer et que ton site rapporte du CASH, restaure d’abord.

Checklist actionnable : 7 étapes à suivre maintenant

Sauvegarde actuelle : exporte la BDD (mysqldump) et copie wp-content (ou dossier public). Oui, même si tout est cassé.
Logs : récupère les 200 dernières lignes du log PHP/NGINX.
PHP : vérifie la version (phpinfo()), memory_limit (>= 256M recommandé pour WP avec WooCommerce).
Plugins : désactive cache et sécurité en premier (ils interfèrent souvent).
Thème : passe à un thème standard si tu suspectes le front.
Requête HTTP : curl -I pour voir les headers.
Staging : reproduis la mise à jour sur un clone local ou staging avant de retenter en prod.

Si tu veux un guide pas prise de tête pour le staging, j’en parle dans mon article sur le code créateur (oui, je balance mes petites recettes là-bas).

Ce que j’ai appris après 100 incidents (chiffres et erreurs réelles)

Sur 100 incidents que j’ai traités en freelance depuis 2019 : 42 étaient dus à un plugin, 28 à une migration PHP, 15 à une erreur humaine (mauvais fichier .env), 15 autres étaient des attaques ou problèmes d’hébergement.

La majorité se règle sans développeur senior. Parfois 10 minutes sur FTP suffisent. Parfois tu dois appeler le support (et la, prépare-toi à attendre 30–90 minutes selon l’hebergeur). OVH, Scaleway, ou un petit VPS chez Hetzner ont des SLA différents — j’ai noté des RESTORES instantanés sur Hetzner en 2024 et des délais plus longs chez certains revendeurs.

Bref, garde toujours une sauvegarde de 7 jours minimum. Et si tu veux dormir tranquille, configure une rotation hebdo et monthly.

Quand appeler un pro : 3 signes qui montrent que tu dois lâcher l’affaire

Tu vois des erreurs dans la BDD (tables corrompues, erreurs SQL répétées). Là, c’est plus safe d’avoir un DBA ou un dev.
Ton site e-commerce a des transactions en cours (cartes, paiements). Ne touche pas au code. Restore d’abord.
Tu suspectes une compromission (fichiers modifiés à des heures bizarres, users admin inconnus). Sécurité = prioritaire.

⚠️ Attention : si des données persos ont été exposées, tu as 72 heures pour notifier selon certaines lois (check ton juriste). Je ne suis pas avocat, mais je suis franc et précis sur le timing.

Mes petites astuces perso (qui m’ont sauvé la vie à 02:13)

Garde un accès SSH et un user avec sudo limité. J’ai perdu 45 minutes une fois parce que j’avais oublié la clé SSH.
Documente tes étapes de déploiement dans un fichier README-deploy.md dans le repo. 3 entreprises m’ont payé pour écrire ça.
Si tu utilises Git, tag ton dernier build stable (v1.2.3-stable) avant une grosse maintenance.

(J’ai aussi un drive avec des scripts bash débiles qui automatisent les restores — pas glamour, mais utile.)

FAQ

Q : Combien de temps faut-il pour restaurer un site standard (WP, 2 Go) ?
R : Entre 10 et 30 minutes pour une restauration complète si tu as un snapshot et l’accès SSH ; compte 1–3 heures si tu dois refaire des vérifs BDD ou purger un CDN.

Q : Comment repérer si c’est un plugin qui foire sans tout désactiver ?
R : Active le mode debug (WP_DEBUG) et regarde les logs. Si l’erreur mentionne un chemin wp-content/plugins/nom-plugin, bingo. Sinon, désactive juste les plugins qui touchent au caching, sécurité et optimisation en premier (généralement les coupables).

Q : Est-ce qu’un hébergeur gratuit peut restaurer mes données ?
R : Les hébergeurs gratuits ont souvent des sauvegardes limitées. Si ton site est critique, passe à un VPS ou un hébergeur offrant snapshots (coûts typiques : 5–10 €/mois pour un petit VPS; 20–30 € pour un plan plus robuste).

Voilà. Si tu veux que je te guide pas à pas sur ton cas précis, décris ton hébergeur, version PHP et les messages d’erreur — je te dis quoi faire en 3 étapes.