Erreur lors de la connexion à la base de données WordPress : causes et réparation

Votre site affiche « Erreur lors de la connexion à la base de données » et plus rien ne s'ouvre ? Cette panne signifie une seule chose : WordPress ne parvient plus à lire ses données dans MySQL. C'est spectaculaire — page cassée, admin bloquée — mais rarement grave : dans l'immense majorité des cas, la cause se résume à quelques paramètres à corriger, et le site repart en moins d'une demi-heure.

Chez SiteBug.fr, cette erreur revient chaque semaine parmi nos interventions. Cet article vous livre ce que nous vérifions concrètement, dans l'ordre : la signification exacte du message, les 7 causes réelles classées par fréquence, la méthode de réparation pas à pas, une étude de cas chiffrée et les réflexes qui évitent la rechute.

Erreur lors de la connexion à la base de données : que signifie ce message ?

Un site WordPress repose sur deux briques : le code PHP (les fichiers) et une base de données MySQL (vos articles, pages, réglages, comptes). À chaque visite, PHP interroge la base pour reconstruire la page : titre, contenu, menus, options. Si ce dialogue échoue, WordPress s'arrête net et affiche « Erreur lors de la connexion à la base de données » (en anglais : error establishing a database connection).

Front-end et back-end : un test qui oriente le diagnostic

Premier réflexe : comparez la page publique et l'administration. Si l'erreur apparaît des deux côtés, le problème vient presque toujours des identifiants de connexion ou du serveur MySQL. Si /wp-admin affiche un message différent — « One or more database tables are unavailable » — c'est le signe d'une base ou d'une table corrompue à réparer.

Cette erreur est cousine de la page blanche WordPress : dans les deux cas, le serveur reçoit la requête mais ne renvoie rien d'exploitable. La différence ? Ici, le message pointe explicitement vers la base — un avantage pour le dépannage.

Les 7 causes fréquentes d'une erreur de connexion à la base de données WordPress

Toutes les « erreurs de connexion à la base de données WordPress » ne se valent pas. Voici les causes réelles, classées par fréquence d'après nos interventions, avec le signal qui permet de les distinguer.

Source : retours d'expérience terrain SiteBug.fr (350+ interventions) croisés avec la documentation officielle de Kinsta, Hostinger et SiteGround.

Un enseignement de terrain : plus de la moitié des cas se règlent sans rien réparer, simplement en corrigeant une valeur dans wp-config.php. Les 20 % de tables corrompues demandent, eux, une réparation MySQL — c'est le cœur de notre méthode de diagnostic (lecture des logs, REPAIR TABLE, restauration ou innodb_force_recovery en dernier recours).

Réparer l'erreur lors de la connexion à la base de données : la méthode pas à pas

Appliquez ces étapes dans l'ordre. Chacune écarte une cause probable ; inutile de passer à la suivante tant que la précédente n'est pas validée.

Étape 1 — Sauvegarder avant tout

Plusieurs manipulations touchent la base. Sauvegardez fichiers ET base de données (via l'espace hébergeur ou une extension) avant d'y toucher. Un dépannage sans sauvegarde préalable est un risque que nous ne prenons jamais.

Étape 2 — Vérifier les identifiants dans wp-config.php

C'est la cause n°1. Ouvrez wp-config.php à la racine du site (via FTP ou le gestionnaire de fichiers) et contrôlez ces quatre constantes :

define( 'DB_NAME', 'nom_de_votre_base' );
define( 'DB_USER', 'utilisateur_mysql' );
define( 'DB_PASSWORD', 'mot_de_passe' );
define( 'DB_HOST', 'localhost' );

Comparez chaque valeur avec celles affichées dans votre panneau d'hébergement (section « Bases de données »). La moindre faute de frappe, un mot de passe modifié ou un DB_HOST inadapté suffisent à casser la connexion. Documentation officielle : éditer wp-config.php sur WordPress.org.

Étape 3 — Tester la base via phpMyAdmin

Depuis phpMyAdmin, vérifiez que la base existe bien, qu'elle contient vos tables (préfixe wp_ le plus souvent) et que l'utilisateur peut s'y connecter. Si vous accédez à la base depuis phpMyAdmin mais pas depuis WordPress, le souci est bien dans les identifiants — pas dans le serveur.

Étape 4 — Réparer les tables (WP_ALLOW_REPAIR)

Si l'admin affiche « tables unavailable », activez l'outil natif de réparation. Ajoutez cette ligne dans wp-config.php :

define( 'WP_ALLOW_REPAIR', true );

Rendez-vous ensuite sur votresite.com/wp-admin/maint/repair.php, lancez la réparation, puis retirez impérativement la ligne ajoutée (cette page est accessible sans authentification). En profondeur, l'équivalent MySQL est la commande REPAIR TABLE nom_table;.

Étape 5 — Contrôler les privilèges et l'état du serveur MySQL

Identifiants corrects mais erreur persistante ? Vérifiez que l'utilisateur MySQL possède tous les privilèges sur la base, puis l'état du serveur côté hébergeur. Une erreur intermittente pendant les pics de trafic trahit souvent un serveur surchargé ou un quota de connexions atteint — fréquent sur mutualisé. Dans ce cas, la solution passe par l'hébergeur (ou par un plan mieux dimensionné).

Étape 6 — Remplacer les fichiers du cœur corrompus

En dernier ressort, réinstallez proprement le cœur de WordPress : téléchargez la dernière version sur WordPress.org, puis remplacez tous les fichiers sauf wp-content et wp-config.php. Votre contenu reste intact.

Comparatif des méthodes de réparation

Source : synthèse des procédures documentées par WordPress.org, Kinsta et SiteGround, complétée par les temps d'intervention moyens constatés chez SiteBug.fr.

Étude de cas : erreur de base de données après une migration

Un exemple concret, anonymisé, tiré de nos interventions. Un client — site vitrine sous WordPress — migre son site vers un nouvel hébergeur mutualisé. Tout se passe bien… jusqu'à ce que le site affiche « Erreur lors de la connexion à la base de données » quelques heures plus tard, à la bascule des DNS.

Résultat : résolution en 24 minutes, aucune perte de données (sauvegarde préalable), zéro récidive à 6 mois. La leçon : après une migration, le DB_HOST est le piège le plus courant — juste après le trio nom/utilisateur/mot de passe. Ce schéma revient dans notre panorama des 10 bugs WordPress les plus fréquents.

Prévenir l'erreur lors de la connexion à la base de données WordPress

Une erreur base de données est rarement une fatalité : cinq réflexes réduisent drastiquement le risque.

• Sauvegardes automatiques — fichiers ET base de données, stockées hors serveur et testées régulièrement.
• Après chaque migration, revérifiez les 4 constantes de wp-config.php, DB_HOST en priorité.
• Surveillez la charge MySQL et le nombre de connexions simultanées, surtout en mutualisé.
• Limitez les extensions gourmandes en requêtes SQL, qui saturent la base inutilement.
• Mettez en place un monitoring d'uptime pour être alerté avant vos visiteurs.

Une base saturée finit aussi par ralentir tout le site : si vous constatez des lenteurs, notre guide sur le site web lent complète utilement cette liste. Et si la panne cache un piratage (une base injectée peut déclencher ces erreurs), consultez notre procédure site WordPress piraté.

Reprendre la main, proprement

L'erreur lors de la connexion à la base de données impressionne mais suit presque toujours un schéma connu : un identifiant à corriger, une table à réparer, ou un serveur à relancer. En suivant la méthode dans l'ordre — sauvegarde, wp-config.php, phpMyAdmin, WP_ALLOW_REPAIR, privilèges/serveur — vous résolvez l'immense majorité des cas en moins de 30 minutes.

Mais chaque minute d'indisponibilité coûte des visiteurs, des ventes et des positions Google. Si le site est stratégique ou si le doute persiste, ne tâtonnez pas sur une base en production : un diagnostic expert va plus vite et protège vos données. Pour aller plus loin, explorez notre dépannage WordPress ou notre guide complet du dépannage de site web.