Erreur de connexion à la base de données WordPress

Votre site affiche "Error establishing a database connection" à la place de vos pages. Rien d'autre ne s'affiche, pas même un indice. C'est l'une des pannes WordPress les plus fréquentes, et dans la majorité des cas, la cause tient en une ligne de configuration ou un service arrêté côté hébergeur.

Ce que veut dire ce message

WordPress stocke son contenu dans une base de données MySQL : articles, pages, réglages, comptes utilisateurs. Le fichier wp-config.php, à la racine du site, contient les identifiants qui permettent à WordPress de s'y connecter. Ce message apparaît dès que cette connexion échoue, pour une des trois raisons suivantes : les identifiants sont faux, le serveur de base de données ne répond pas, ou la base elle-même est endommagée.

Contrairement à une erreur 500 ou à un écran blanc, ce message ne donne aucun détail technique au visiteur. Il faut aller chercher la cause ailleurs : danswp-config.php, dans les logs de l'hébergeur, ou dans phpMyAdmin.

Les causes les plus fréquentes

Dans l'ordre de fréquence constaté en intervention :

• Identifiants incorrects dans wp-config.php : mot de passe changé côté hébergeur sans mise à jour du fichier, migration de site mal terminée, ou restauration d'une sauvegarde avec un ancien nom de base.
• Serveur MySQL saturé ou arrêté : pic de trafic sur un hébergement mutualisé, limite de connexions simultanées atteinte, maintenance côté hébergeur, ou process MySQL qui a planté.
• Quota hébergeur dépassé : certains forfaits mutualisés coupent l'accès à la base dès que l'espace disque ou le nombre de requêtes par heure est dépassé.
• Tables corrompues : coupure brutale pendant une écriture, disque serveur défaillant, ou extinction mal gérée après un pic de charge.

Pour une vue d'ensemble des pannes WordPress les plus courantes, voir le panorama des 12 erreurs fréquentes. Une erreur 500 mal diagnostiquée masque parfois le même problème de base de données : voir le guide erreur 500 WordPress et PrestaShop. Le message "erreur critique" affiché par WordPress peut aussi venir d'une base inaccessible : détails dans le guide erreur critique WordPress.

Ce que vous pouvez tenter seul, sans risque

Avant toute manipulation, sauvegardez la base de données et les fichiers via l'interface de l'hébergeur ou en SFTP. Ensuite, procédez dans l'ordre :

1. Vérifier les identifiants. Ouvrez wp-config.php en SFTP et contrôlez les quatre constantes : DB_NAME, DB_USER,DB_PASSWORD et DB_HOST. Comparez-les avec ceux affichés dans le panel de votre hébergeur, section bases de données.
2. Tester la connexion directement. Connectez-vous à phpMyAdmin ou Adminer avec ces mêmes identifiants. Si la connexion échoue aussi là, le problème vient du serveur MySQL ou du mot de passe, pas de WordPress.
3. Vérifier l'état du serveur de base de données. Le panel de l'hébergeur indique généralement si le service MySQL est opérationnel. En cas de panne généralisée, la page de statut de l'hébergeur le confirme.
4. Vérifier le quota. Espace disque de la base, nombre de requêtes par heure : certains hébergeurs mutualisés affichent une jauge dans leur interface.
5. Lancer l'outil de réparation si les tables sont suspectées corrompues.Ajoutez cette ligne dans wp-config.php, juste avant la ligne/* C'est tout, ne touchez pas à ce qui suit ! */ :

define('WP_ALLOW_REPAIR', true);

Visitez ensuite https://votresite.fr/wp-admin/maint/repair.php et cliquez sur "Réparer la base de données". L'outil parcourt toutes les tables et corrige celles qui sont endommagées. Une fois l'opération terminée, retirez la ligne ajoutée : cette page reste accessible sans authentification tant qu'elle est présente.

Ce qu'il ne faut surtout pas faire

• Ne modifiez jamais directement les identifiants dans wp-config.php sans avoir vérifié les vrais paramètres côté hébergeur : une faute de frappe transforme une panne temporaire en panne certaine.
• Ne relancez pas plusieurs fois l'outil de réparation sans comprendre pourquoi les tables se corrompent : si le problème revient, c'est le disque ou l'hébergement qui doit être questionné, pas WordPress.
• Ne supprimez et ne recréez jamais la base de données en espérant "repartir propre" : c'est irréversible et vous perdez tout le contenu sans sauvegarde valide.
• N'exécutez pas de requêtes SQL manuelles dans phpMyAdmin si vous ne savez pas précisément ce qu'elles font : une suppression ou une mise à jour mal ciblée peut toucher toutes les lignes d'une table.

Quand appeler un professionnel

Si les identifiants sont corrects, que le serveur MySQL répond, et que l'erreur persiste malgré la réparation, le problème est plus profond : table manquante, structure de base incohérente après une migration, ou corruption au niveau du moteur de stockage. C'est le moment de passer la main plutôt que de multiplier les tentatives.

Pour un dépannage de site internet sur ce type de panne, l'offre Dépannage Express, à partir de 30 € HT, couvre un diagnostic gratuit, un créneau d'intervention dans l'heure en journée ouvrée, et une panne simple réglée en moins d'une heure, sauvegarde faite avant toute correction, avec une garantie 30 jours. Si le diagnostic révèle une panne plus lourde, vous recevez un devis ferme avant qu'on continue.

Questions fréquentes

Ai-je perdu mon contenu si la base ne répond plus ?

Pas forcément. Un serveur MySQL arrêté ou des identifiants faux n'effacent rien : les données sont toujours là, seule la connexion est coupée. Seule une corruption profonde des tables, sans sauvegarde, peut rendre une partie du contenu irrécupérable.

Faut-il contacter l'hébergeur ou un prestataire WordPress ?

Les deux ont un rôle différent. L'hébergeur gère la disponibilité du serveur MySQL. Le prestataire WordPress vérifie la configuration, la cohérence des tables et corrige le site lui-même. Commencez par l'hébergeur si vous suspectez une panne serveur, sinon passez directement au diagnostic WordPress.

Combien de temps pour résoudre cette erreur ?

Une erreur d'identifiants se corrige en quelques minutes une fois la bonne information en main. Une réparation de tables prend généralement moins d'une heure. Une base incohérente après une migration ratée peut demander plusieurs heures de diagnostic.

Cette erreur peut-elle revenir après correction ?

Oui, si la cause initiale n'est pas traitée : hébergement sous-dimensionné qui sature MySQL à chaque pic de trafic, ou disque serveur en fin de vie qui corrompt les tables régulièrement. Dans ce cas, c'est l'hébergement qu'il faut revoir, pas seulement la base.