Comment faire réparer un site WordPress en panne (erreur critique, écran blanc, 500)

Tu as mis à jour une extension et maintenant ton site WordPress affiche « Il y a eu une erreur critique sur ce site. » Tu vois peut-être une page blanche ou le message « 500 Internal Server Error » à la place.

Si tu as une boutique en ligne, tu perds peut-être des commandes. Tes articles et tes pages sont en général toujours là, même si le site ne se charge pas.

Quand je répare un site WordPress en panne, je commence par quelques vérifications simples. Je vais te montrer quoi essayer d’abord, puis comment faire appel à quelqu’un en toute sécurité si ça ne suffit pas.

Ce que cette erreur veut dire, en général

Ces trois messages veulent en général dire que WordPress n’a pas pu finir de charger la page parce qu’une erreur s’est produite dans le code. Les versions récentes de WordPress peuvent afficher un message d’erreur critique. Selon la configuration, tu peux aussi voir un écran blanc, et une panne du serveur peut renvoyer une erreur 500.

Les causes habituelles, à peu près dans l’ordre où je les rencontre :

• Une mise à jour d’extension ou de thème Elle entre en conflit avec une autre extension ou avec ta version de PHP. C’est de loin le cas le plus fréquent.
• Un changement de version de PHP chez ton hébergeur Une extension ou un thème plus ancien ne fonctionne pas avec la nouvelle version.
• Le site manque de mémoire Les constructeurs de pages lourds et les boutiques avec beaucoup d’extensions atteignent la limite de mémoire PHP.
• Un fichier endommagé Une mise à jour ratée, une mauvaise modification dans functions.php ou un fichier .htaccess abîmé, une cause classique de l’erreur 500.

Tes articles, pages, produits et commandes sont stockés dans la base de données, séparément du code à l’origine de l’erreur. Corriger ce code suffit en général à remettre le site en ligne sans supprimer ce contenu. WordPress propose un guide des erreurs courantes (en anglais) si tu veux plus de détails techniques.

Essaie d’abord ceci (10 minutes)

Voici les quatre vérifications que je ferais dans un cas de panne courant.

1. Regarde la boîte mail de l’administrateur. WordPress envoie un e-mail de récupération à l’adresse d’administration du site, avec pour objet « Votre site connaît un problème technique ». Il indique l’extension ou le thème en cause et contient un lien vers le mode de récupération, valable un jour. Utilise ce mode pour ouvrir le tableau de bord et désactiver ou mettre à jour l’extension. Regarde aussi dans les spams.
2. Annule la dernière modification. Tu as mis à jour WordPress, un thème ou une extension, ou reçu un avis de changement de version de PHP ? Annule ce changement. La plupart des panneaux d’hébergement permettent de repasser à l’ancienne version de PHP.
3. Restaure la sauvegarde d’hier. La plupart des hébergeurs gardent des sauvegardes automatiques que tu peux restaurer depuis le panneau d’hébergement. Pour un blog ou un site vitrine, c’est souvent la solution la plus rapide. Pour une boutique, passe cette étape : restaurer une sauvegarde supprime toutes les commandes et tous les comptes clients créés depuis cette sauvegarde.
4. Désactive toutes les extensions d’un coup. Dans le gestionnaire de fichiers de ton hébergeur, ouvre wp-content et renomme le dossier plugins en plugins_old. WordPress arrête alors de charger ces extensions. Si le site s’affiche, redonne au dossier son nom d’origine et réactive les extensions une par une pour trouver la cause probable.

Fais directement appel à quelqu’un si ta boutique a des commandes en cours, si tu vois des redirections inhabituelles ou un avertissement de piratage, ou si le message dit « Erreur lors de la connexion à la base de données ». Tâtonner peut coûter plus cher que la réparation.

Si ça n’a pas remis le site en ligne, ou si tu préfères ne pas toucher aux fichiers de ton hébergement, arrête-toi là. Chaque modification supplémentaire complique le travail du développeur. L’étape suivante, c’est de choisir qui va le réparer.

Où engager un développeur

Pour ce genre de réparation, je recommande Fiverr. J’y travaille moi-même, donc je connais bien le fonctionnement des commandes, des paiements et des avis.

Tu vois le prix avant de commander, les vendeurs de la catégorie correction de bugs WordPress livrent souvent en un jour, et Fiverr conserve ton paiement jusqu’à la fin de la commande.

Ce que ça coûte

Le prix dépend moins du message d’erreur que de ce qu’il reste à comprendre sur la panne. Au moment où j’écris ces lignes, les tarifs sur Fiverr pour ce type de travail se répartissent en trois niveaux :

Fiverr ajoute aussi de petits frais de service au moment du paiement.

Ce que le prix le plus bas laisse souvent de côté

Un service à 19 € peut suffire quand tu connais la cause et qu’il s’agit d’un seul problème. Si la cause est inconnue, l’option la moins chère peut laisser de côté ce qui permet de réparer durablement le site :

• une sauvegarde avant de toucher à quoi que ce soit
• la cause, pas seulement le symptôme (désactiver une extension remet le site en ligne ; la remplacer par une extension compatible avec ta version de PHP, c’est la vraie réparation)
• des tests sur autre chose que la page d’accueil : formulaires, passage de commande, affichage sur mobile
• une courte note sur ce qui s’est passé, pour que ça ne se reproduise pas

Quand la cause est inconnue, payer un vrai diagnostic coûte moins cher que payer deux fois.

Comment choisir le bon développeur

Beaucoup de vendeurs savent régler un conflit d’extensions. Regarde comment ils comptent intervenir sur ton site, gérer les accès et sauvegarder tes données.

Cherche des avis sur le même problème

Cherche des avis qui mentionnent « critical error », « white screen » ou « 500 error », pas seulement la note globale. Lis les avis à une, deux ou trois étoiles et les réponses du vendeur. Une réponse calme et précise est bon signe.

Envoie ton brief avant de commander

Envoie le brief ci-dessous à deux ou trois vendeurs. Un bon vendeur pose des questions sur ta version de PHP, ta sauvegarde ou tes derniers changements. « Oui, je peux le réparer. Passe commande » ne t’apprend pas grand-chose.

Lis la formule Basic

Vérifie ce que le vendeur entend par « un problème », le délai de livraison et le nombre de révisions. Un vendeur qui parle de sauvegarde a pensé aux risques pour ton site, pas seulement à la réparation.

Ne te fie pas trop au niveau du vendeur

Sur Fiverr, le niveau d’un vendeur reflète son historique de commandes, pas ses compétences sur WordPress. Un vendeur qui débute sur la plateforme peut régler un simple conflit d’extensions. Pour une boutique ou un possible piratage, je choisirais quelqu’un dont les avis portent précisément sur ce type d’intervention.

Les questions que je poserais avant de commander

• Tu fais une sauvegarde complète avant de modifier quoi que ce soit ?
• Tu travailles sur une copie de préproduction ou sur le site en ligne ?
• De quels accès as-tu besoin, exactement ?
• Tu me diras ce qui a causé le problème ?
• Tu vas installer des extensions ? Lesquelles, et ont-elles une licence ?
• Que se passe-t-il si l’erreur revient la semaine prochaine ?

Signaux d’alerte

• Il te demande le mot de passe de ton compte d’hébergement ou l’accès à ton nom de domaine alors qu’un compte WordPress et un accès aux fichiers suffiraient.
• Il veut poursuivre la discussion ou recevoir le paiement en dehors de Fiverr. Fiverr demande aux acheteurs de garder les échanges et les paiements sur la plateforme, et son assistance ne peut intervenir que pour les commandes qui y ont été passées.
• Il promet de corriger « n’importe quelle erreur en une heure » sans poser une seule question sur ton site.
• Il propose une extension premium gratuitement. C’est une copie piratée, et les extensions piratées peuvent contenir des logiciels malveillants.
• Il ne parle jamais de sauvegarde.
• Il offre une réduction en échange d’un avis cinq étoiles.

Comment donner des accès en toute sécurité

Donne au développeur uniquement les accès nécessaires, pour la durée la plus courte possible, avec des comptes que tu contrôles.

1. Fais d’abord ta propre sauvegarde. Télécharge une sauvegarde complète depuis ton panneau d’hébergement et garde une copie ailleurs que sur le serveur.
2. Crée un compte WordPress séparé pour le développeur au lieu de partager tes identifiants. Si le tableau de bord fonctionne, l’extension gratuite Temporary Login Without Password crée un lien de connexion qui expire automatiquement. Avec une erreur critique, le tableau de bord est souvent inaccessible, donc le développeur aura surtout besoin d’un accès aux fichiers.
3. Donne accès aux fichiers avec un compte SFTP séparé. Crée-le dans ton panneau d’hébergement. Ne partage jamais le mot de passe de ton compte d’hébergement lui-même.
4. Garde certains accès pour toi : le compte chez le fournisseur de ton nom de domaine, les comptes Stripe ou PayPal et la boîte mail liée à l’adresse d’administration du site.
5. Partage les mots de passe de manière sécurisée, uniquement après avoir commandé. Utilise le lien de partage d’un gestionnaire de mots de passe, pas du texte en clair dans la discussion.
6. Retire tous les accès une fois le travail terminé. Supprime le compte WordPress créé pour le développeur et son compte SFTP, change tes mots de passe et vérifie dans Comptes → Administrateur/administratrice qu’il n’y a pas de comptes que tu ne reconnais pas.

Une règle te protège plus que toutes les autres : garde ton hébergement et ton nom de domaine à ton nom. Celui qui les contrôle contrôle le site.

Ce qu’il faut envoyer avant le début du travail

Un brief clair fait gagner du temps et aide le développeur à comprendre ce qu’il doit faire. Envoie-le avant de commander, ou colle-le dans les consignes de la commande :

• l’URL de ton site et une copie de préproduction, si tu en as une
• ce qui est cassé et ce que « réparé » veut dire pour toi (par exemple : « la page d’accueil s’affiche et le formulaire de contact envoie bien les messages »)
• le texte exact de l’erreur et une capture d’écran
• quand ça a commencé et ce qui a changé juste avant
• ton hébergeur, ta version de WordPress et ta version de PHP (Outils → Santé du site → Informations, si le tableau de bord fonctionne)
• ton thème ou ton constructeur de pages et tes principales extensions (WooCommerce, cache, sécurité)
• si tu as une sauvegarde récente et où elle est stockée
• ce que tu as déjà essayé
• tes contraintes, par exemple « aucune modification de la page de commande du site en ligne pendant les heures d’ouverture », et ta date limite
• les accès que tu es prêt à donner

Sur Fiverr, les consignes de la commande servent de référence pour les demandes de révision. Un bon brief protège ton argent autant qu’il aide le vendeur.

Après la réparation : vérifier, valider, éviter une nouvelle panne

Sur Fiverr, tu as trois jours pour examiner une livraison. Ensuite, la commande se termine d’elle-même. Vérifie donc le travail le jour même :

• ouvre la page d’accueil et quelques autres pages du site, sur ton téléphone aussi
• envoie un message de test via le formulaire de contact
• si tu as une boutique, passe une commande de test
• demande ce qui a causé l’erreur, et note-le
• demande les modifications éventuelles via Fiverr avant d’accepter la livraison

Ensuite, retire les accès que tu as donnés (voir plus haut) et limite le risque d’une nouvelle panne. Garde les sauvegardes automatiques activées, mets à jour les extensions une par une, teste les mises à jour sur une copie de préproduction si tu as une boutique, et supprime les extensions que tu n’utilises plus. Si le site tombe régulièrement en panne après les mises à jour, une maintenance régulière peut coûter moins cher que de payer une réparation après l’autre.

En résumé

Faire réparer un site WordPress en panne est souvent une petite intervention, mais choisir la mauvaise personne peut créer un autre problème. Essaie d’abord les quatre vérifications. Si elles ne suffisent pas, choisis un vendeur qui a des avis sur la même erreur et qui prévoit une sauvegarde, et donne-lui un accès temporaire. Pour limiter le risque, commence par une commande pour un seul problème.