Site WordPress en erreur 500 : pourquoi j’ai reconstruit plutôt que réparé
Début septembre, en faisant l’inventaire hebdomadaire de mes hébergements, je remarque que 7days.dev renvoie une erreur HTTP 500 sur toutes les pages. Le message de WordPress est explicite, « Error establishing a database connection ». En vérifiant la configuration, je constate que la base de données du site n’existe plus. Pas de sauvegarde exploitable, rien à restaurer.
C’est une situation que je rencontre régulièrement chez les dirigeants de PME qui me contactent : un site WordPress qui tombe, et une seule question en tête, « combien pour le réparer ? ». Voici comment j’ai traité le cas sur mon propre site, ce que j’ai choisi, ce que j’ai écarté, et ce que les mesures montrent.
Le constat : une panne qui ne se répare pas
Le 2 septembre, ma mesure est sans appel : HTTP 500 sur 7days.dev, toujours en 500 deux jours plus tard. Le site partageait un hébergement mutualisé avec une douzaine d’autres sites, dont certains mettaient plus de 20 secondes à répondre ce jour-là.
Un WordPress, c’est deux choses : des fichiers et une base de données qui contient tout le contenu. Ici, les fichiers étaient là, la base non. « Réparer » voulait donc dire réinstaller un WordPress vide et tout ressaisir. À ce prix-là, la vraie question devient : WordPress est-il encore le bon outil pour ce site ?
La décision : ce que j’ai choisi, et ce que j’ai écarté
7days.dev est notre pôle dédié à l’automatisation des process pour entreprise, il est constitué de pages de présentation et d’articles. Aucun panier, aucun espace client, aucun formulaire complexe. Avant de trancher, j’ai comparé les options sur ce critère précis.
- Remonter un WordPress : écarté. Même base de données à héberger et sauvegarder, mêmes mises à jour d’extensions, même risque demain.
- Un CMS « headless » hébergé chez un tiers (type Sanity) : écarté. Le contenu vivrait chez un fournisseur extérieur ; je veux garder la maîtrise de mes données.
- Next.js : écarté. Excellent pour une application, surdimensionné pour un site sans besoin dynamique.
- Astro, en site statique : retenu. C’est l’outil de référence en 2026 pour les sites de contenu : il produit des pages HTML toutes prêtes, sans base de données ni code exécuté à chaque visite.
La contrepartie, je l’ai assumée dès le départ : plus d’interface d’administration WordPress. Le contenu s’édite en fichiers texte. Pour moi ce n’est pas un problème, puisque mes outils d’automatisation et d’IA écrivent directement dans ces fichiers. Pour un client qui veut modifier lui-même ses pages chaque semaine, c’est un vrai critère à peser.
Ce que j’ai mis en place
- Le contenu en Markdown dans un dépôt Git. Chaque page est un fichier texte versionné : l’historique complet est conservé, et le site se reconstruit à l’identique en quelques minutes.
- Un build automatique à chaque envoi. Quand j’envoie une modification, le site est recompilé dans un conteneur isolé, puis la nouvelle version remplace l’ancienne d’un coup, sans état intermédiaire visible.
- Un serveur qui ne sert que des fichiers. Aucun code n’est exécuté à la visite : il n’y a tout simplement rien à pirater côté serveur. Les certificats HTTPS se renouvellent seuls.
- Une chaîne de publication automatique. Un article déposé par un de mes workflows est en ligne sans intervention. Mesuré le 16 septembre : dépôt à 11:02:59, en ligne à 11:03:06, soit 7 secondes.
- Des visuels vectoriels animés. Plutôt que des photos de stock, 16 schémas SVG animés, dessinés en code, légers et nets sur tous les écrans.
Le contenu, lui, n’a rien d’automatique. Je relis chaque page à l’écran pendant la refonte, et chaque fait avancé (date, partenaire, choix technique) doit pouvoir être sourcé, par un registre officiel ou un article de presse. Si je n’ai pas la source, la phrase ne part pas en ligne.
Les résultats mesurés
| Mesure | Avant | Après |
|---|---|---|
| État du site | HTTP 500 (2 et 4 septembre) | HTTP 200 |
| Réponse de la page d’accueil | — | 0,13 s (12 et 29 septembre) |
| Premier octet reçu (TTFB) | — | 63 ms |
| Page entièrement chargée | — | 158 ms |
| Poids transféré, page d’accueil | — | 40 Ko |
| Impressions Google (8 premiers jours) | — | 521, de 11 à 153 par jour |
| Publication d’un article | manuelle | 7 s, automatique |
Avant la mise en ligne publique, j’ai fait parcourir les 105 pages du site par un robot : zéro erreur JavaScript, zéro débordement sur un écran de téléphone de 390 pixels, et une feuille de style de 10 Ko compressée.
Côté référencement, j’ai validé les données structurées dans l’outil officiel de Google avant d’attendre quoi que ce soit du trafic : fil d’Ariane, organisation et services sont reconnus sans erreur.
Premiers signaux dans Search Console
Les premières impressions apparaissent le 20 septembre. Huit jours plus tard, Search Console compte 521 impressions et 4 clics, pour une position moyenne de 14,5. Surtout, la courbe monte vite : 11 impressions le 20 septembre, 153 le 26.
Ce qui m’intéresse le plus, ce sont les requêtes. Hormis la marque « 7days » (position 6), ce sont des recherches très précises, celles de dirigeants qui ont déjà un problème en tête : « automatisation des relances clients », « automatisation des notes de frais », « saisie automatique des factures », « devis automatisé ». Les pages qui captent le plus d’impressions sont celles consacrées aux relances d’impayés (42), à la saisie des factures fournisseurs (34) et à la facturation récurrente (21). C’est exactement la cible du site.
Huit jours, c’est un démarrage, pas une tendance. Je referai le point à un mois puis à trois mois, avec les mêmes indicateurs.
WordPress et le back-office ont-ils encore un sens à l’ère de l’IA ?
C’est la vraie question que ce chantier m’a posée. Pendant des années, le back-office a été le seul moyen pour un non-développeur de modifier son site. Aujourd’hui, un assistant IA bien outillé rédige une page, corrige une coquille ou publie un article à partir d’une simple phrase, directement dans les fichiers ou par l’API du site. Pour un site de contenu dont les évolutions passent par moi et par mes outils, l’interface d’administration devient optionnelle.
Cela ne fait pas de WordPress une solution dépassée. L’article que vous lisez est publié sur oli-via-net.fr, qui tourne sous WordPress, et il y a été déposé par ces mêmes outils, via l’API. Les deux approches cohabitent très bien. WordPress et son back-office restent, à mon avis, le bon choix dès qu’il faut :
- vendre en ligne : catalogue, stocks, paiements et commandes avec WooCommerce ;
- des fonctionnalités spécifiques : réservation, espace membre, formulaires avancés, extensions métier ;
- de l’autonomie côté client : plusieurs personnes qui publient, avec des rôles et une validation ;
- un écosystème : des milliers d’extensions et de prestataires capables de reprendre le site.
Le site statique, lui, prend tout son sens pour un site vitrine ou éditorial, dont le contenu change quelques fois par mois, où la vitesse et la sécurité priment et où la publication peut être automatisée. Et dans tous les cas, une base de données sans sauvegarde testée est une panne programmée : c’est la première chose que je vérifie lors d’un audit.
Votre site est en panne, lent, ou vous hésitez entre le faire évoluer et le reconstruire ? Je regarde votre situation et vous dis franchement ce qui se justifie, WordPress compris.
Audit SEO & Marketing Digital Offert
Obtenez une analyse personnalisée de votre site en moins de 48h.
100 % gratuit, sans engagement : notre objectif est de vous montrer comment générer plus de trafic qualifié, de leads et de ventes.
