Erreur de connexion à la base de données WordPress : causes et solutions

Une page blanche, une seule phrase dessus : "Error establishing a database connection". Pas de menu, pas de contenu, aucun accès à l'administration. Le site entier est par terre… et c'est précisément ce qui fait peur.

Pas de panique : c'est rarement grave. Formateur WordPress depuis 2012 et fondateur de WPServeur, j'ai croisé cette erreur des dizaines de fois, sur des sites de stagiaires comme sur des installations clients. Neuf fois sur dix, la base est intacte : c'est la connexion entre WordPress et MySQL qui a lâché, pas vos articles. On va donc faire l'inverse de la panique. Reprendre les causes une par une, de la plus fréquente à la plus rare, jusqu'à ce que le site revienne.

Qu'est-ce que l'erreur de connexion à la base de données WordPress ?

WordPress range tout son contenu (articles, pages, réglages, comptes, commentaires) dans une base de données MySQL ou MariaDB. À chaque visite, il s'y connecte pour reconstruire la page demandée. Quand cette connexion échoue, il ne peut plus rien afficher et renvoie le message "Error establishing a database connection", en français "Erreur lors de l'établissement d'une connexion à la base de données".

Le détail qui change tout : l'erreur frappe le site en entier, front et back en même temps. C'est ce qui la distingue des autres pannes. Une erreur 404 ne touche qu'une URL. Un écran blanc épargne souvent l'administration. Là, si vous tapez l'adresse de votre /wp-admin et qu'il s'affiche normalement, ce n'est pas ce problème, et le diagnostic part ailleurs. Pour le reste du catalogue, j'ai regroupé les correctifs dans mon guide des erreurs WordPress les plus courantes.

Pourquoi WordPress n'arrive plus à joindre sa base ?

Cinq causes couvrent l'immense majorité des cas : un identifiant erroné dans wp-config.php, un mot de passe de base changé côté hébergeur, le serveur MySQL lui-même à l'arrêt, une base qui sature sous trop de connexions simultanées, ou une table corrompue. Le reste tient à des configurations exotiques que vous croiserez rarement.

L'ordre dans lequel vous testez compte autant que les tests eux-mêmes. On commence par le plus simple et le plus probable (les identifiants), avant de soupçonner le serveur ou la base. Inutile de lancer une réparation de table si le vrai souci est un mot de passe que votre hébergeur a régénéré pendant une migration. "Par où commencer ?" Par le fichier de configuration, toujours. C'est gratuit, c'est réversible, et ça résout une bonne partie des cas en deux minutes.

Comment réparer l'erreur de connexion à la base de données ?

Voici le protocole que je déroule, dans cet ordre. Avant toute manipulation de la base, faites une sauvegarde récente de votre site, fichiers et base. On ne sait jamais, une fausse manip est si vite arrivée… et un site déjà en rade, c'est bien assez d'émotions pour la journée.

Vérifier les quatre identifiants dans wp-config.php

Ouvrez le fichier wp-config.php à la racine de votre installation, par FTP ou via le gestionnaire de fichiers de votre hébergeur. Quatre constantes définissent la connexion :

define( 'DB_NAME', 'nom_de_la_base' );
define( 'DB_USER', 'utilisateur_de_la_base' );
define( 'DB_PASSWORD', 'mot_de_passe' );
define( 'DB_HOST', 'localhost' );

Comparez chaque valeur avec celles affichées dans le panneau de votre hébergeur (section bases de données MySQL). Un caractère de trop dans le mot de passe, un nom de base mal recopié après un déménagement, et la connexion tombe. Le DB_HOST vaut localhost sur la plupart des mutualisés, mais certains hébergeurs imposent une adresse dédiée. Si vous l'ignorez, demandez à votre hébergeur : c'est la valeur que les gens se trompent le plus souvent.

Le mot de passe de la base a changé côté hébergeur

C'est la cause numéro un que je vois en support. Une migration, une régénération de mot de passe dans le panneau, une intervention de l'hébergeur sur le serveur MySQL… et le mot de passe stocké dans wp-config.php ne correspond plus à celui de la base. WordPress présente les bons identifiants, mais l'ancien sésame, et MySQL referme la porte.

Pour trancher, ouvrez phpMyAdmin depuis le panneau de votre hébergeur et tentez de vous connecter avec l'utilisateur et le mot de passe de wp-config.php. "Comment savoir si c'est la base ou le serveur ?" Si phpMyAdmin vous laisse entrer mais que WordPress échoue, le souci vient des identifiants : régénérez un mot de passe dans le panneau, puis reportez-le à l'identique dans wp-config.php. Si phpMyAdmin refuse lui aussi la connexion, passez à l'étape suivante : le problème est plus bas, côté serveur.

Le serveur MySQL est à l'arrêt

Parfois, ce n'est ni votre faute ni votre fichier. Le service MySQL du serveur est tombé, ou il a été redémarré et n'est pas remonté. Un signe ne trompe pas : phpMyAdmin ne se connecte pas non plus, et vos autres sites hébergés au même endroit renvoient la même erreur. Sur un mutualisé, vous ne pouvez rien faire d'autre que contacter le support : c'est leur serveur, leur intervention. Sur un VPS ou un serveur dédié, vous redémarrez le service vous-même (par exemple avec une commande du type systemctl restart mysql en SSH) et vous vérifiez l'espace disque, parce qu'une partition pleine met MySQL à genoux sans prévenir.

"Too many connections" : la base sature

Si l'erreur s'accompagne du message "Too many connections", MySQL a atteint son plafond de connexions simultanées (souvent 151 par défaut, mais bridé bien plus bas sur les offres mutualisées). Parfois, c'est un pic de trafic légitime qui dépasse les ressources de votre offre. Parfois, c'est un plugin mal codé ou une boucle de requêtes qui monopolise les connexions et ne les rend pas. Dans les deux cas, le site revient souvent tout seul quelques minutes plus tard… puis retombe à la charge suivante.

Mon conseil : si ça se répète, regardez ce qui tourne. Un plugin d'import, un crawler agressif, une extension de statistiques qui écrit en base à chaque clic. "Comment repérer le coupable ?" Désactivez les extensions une par une, par FTP si l'admin ne répond plus : celle qui fait disparaître l'erreur est la bonne. Et si c'est le trafic réel qui sature, c'est bon signe pour votre activité, mais le message est clair : votre hébergement est trop juste pour ce que vous lui demandez.

Réparer une base ou une table corrompue

Dernier suspect : une table de la base s'est corrompue, après un crash serveur ou une coupure pendant une écriture. WordPress embarque un outil de réparation intégré, à activer dans wp-config.php :

define( 'WP_ALLOW_REPAIR', true );

Ajoutez cette ligne, puis rendez-vous sur votresite.com/wp-admin/maint/repair.php. La page s'affiche sans demander de connexion et propose de réparer (et d'optimiser) les tables. Lancez la réparation, attendez la fin, puis retirez immédiatement la ligne de wp-config.php : tant qu'elle est présente, n'importe qui peut atteindre cette page. On l'oublie trop souvent, et c'est une porte ouverte. Si la réparation échoue, phpMyAdmin propose la même opération (sélectionnez les tables, menu "Réparer la table").

Pourquoi le site revient, puis retombe quelques minutes plus tard ?

Quand l'erreur va et vient, ce n'est presque jamais un identifiant. Un mot de passe faux est faux en permanence. Une erreur qui clignote raconte autre chose : une question de ressources. La base tient tant que la charge reste basse, sature dès qu'un pic arrive, puis se libère quand le calme revient. Sur un mutualisé, vous partagez le serveur MySQL avec des centaines de voisins, et il suffit qu'un autre site s'emballe pour que le vôtre trinque. C'est l'effet de bord du mutualisé : pas cher, mais soumis aux voisins.

J'ai vu des sites passer des semaines avec ces micro-coupures avant qu'on remonte à la cause : un plugin de cache mal réglé qui régénérait la base à chaque visite au lieu de servir une page stockée. Le jour où on l'a corrigé, les coupures ont disparu. Avant de changer d'hébergeur sur un coup de tête, vérifiez d'abord ce qui consomme vos connexions. Et surtout, ce qui alourdit votre base au quotidien… parce que c'est souvent là que tout se joue.

Mon réflexe en maintenance : garder la base propre

Quand je prends un site en maintenance, mon premier geste n'est pas de regarder le thème ou la liste des extensions. J'ouvre la base. Je veux trois informations tout de suite : le préfixe des tables, le poids global, et ce qui traîne (révisions à rallonge, transients périmés, tables orphelines laissées par des plugins désinstallés). Une base négligée, c'est une base qui grossit, qui ralentit les requêtes, et qui finit par tousser au pire moment, typiquement le jour du pic de trafic.

Moi, je travaille directement dans la base : en SQL via phpMyAdmin, ou en ligne de commande avec WP-CLI quand l'accès le permet. À force, je sais où regarder et quoi toucher sans rien casser. Soyons clairs : ce n'est pas une manip pour tout le monde. Une requête de travers, et le petit ménage vire à la grosse panne. Si une base de données vous intimide, c'est normal, et deux extensions gratuites de la famille WPServeur, l'hébergeur que j'ai fondé, font le travail à votre place, sans une ligne de SQL.

Un exemple que j'ai en tête. Sur un site e-commerce dont j'assure la maintenance, un matin, en parcourant les tables dans phpMyAdmin, une ligne saute du lot : une table laissée par un ancien plugin de statistiques désinstallé depuis des mois. À elle seule, elle pesait plusieurs dizaines de Mo et continuait d'être interrogée à chaque chargement de page. La base entière en était alourdie, les sauvegardes traînaient, et aux heures de pointe MySQL commençait à tirer la langue. Je l'ai vidée, j'ai purgé le reste, et tant qu'à faire, j'ai changé le préfixe wp_ resté par défaut. La base a fondu, les requêtes ont repris du nerf, et une cause potentielle de saturation a disparu avant d'avoir fait tomber le site.

Alléger la base, sans rien casser

Sur mes sites, je fais ce ménage à la main, requête par requête. Mais pour quelqu'un qui ne veut pas ouvrir phpMyAdmin, WPS Cleaner s'en charge sans danger : il vide les révisions, purge les transients, nettoie les options orphelines, les médias et les tables laissées par d'anciennes extensions. C'est gratuit, c'est de la famille WPServeur, et j'ai participé à sa création. Soit vous nettoyez tout en un clic, soit vous y allez au cas par cas.

Une base allégée sature moins vite, sauvegarde plus vite, et répond plus vite. Tout ça pour une corvée de cinq minutes par mois.

Changer le préfixe wp_ par défaut

Le préfixe, c'est le petit wp_ devant le nom de chaque table : wp_posts, wp_options, wp_users… Par défaut, il est identique sur des millions de sites, ce qui facilite la vie des scripts d'attaque automatisés qui visent ces noms connus. Le changer ne révolutionne pas votre sécurité, mais ça ferme une porte aux scans bêtes et méchants. Moi, je le modifie directement dans la base quand je reprends un site resté en wp_. Là encore, si le SQL n'est pas votre tasse de thé, un plugin gratuit s'en occupe : WPS Bidouille repère un préfixe d'origine et le sécurise en un clic, en mettant à jour wp-config.php et les références internes proprement.

Et les réflexes qui ne coûtent rien, je les répète à chaque formation. Notez vos identifiants de base dans un gestionnaire de mots de passe (Bitwarden, 1Password) : le jour où le site tombe à 23h un samedi, vous ne chercherez pas DB_PASSWORD en panique. Programmez une sauvegarde automatique testée, base comprise, qui transforme une corruption en restauration de dix minutes. Et dimensionnez l'hébergement sur votre trafic réel : si vous frôlez le plafond de connexions chaque semaine, l'offre est trop juste, point.

Quand faut-il appeler votre hébergeur ?

Dès que le problème sort de votre fichier de configuration. Si phpMyAdmin refuse la connexion alors que vos identifiants sont bons, si vos autres sites tombent en même temps, si le message "Too many connections" persiste malgré un trafic normal : c'est le serveur, pas vous. Sur un mutualisé, vous n'avez de toute façon pas la main sur le service MySQL, et insister par vous-même ne fera que perdre du temps. Un bon support identifie une panne serveur en quelques minutes. À l'époque où je gérais WPServeur, ce genre de ticket arrivait et l'équipe distinguait tout de suite le souci client du souci machine. Donnez-leur le message d'erreur exact, l'heure et le nom de domaine : ils iront droit au but.

Questions fréquentes

Mes données sont-elles perdues quand WordPress affiche cette erreur ?

Presque jamais. Dans la grande majorité des cas, la base et son contenu sont intacts : c'est la connexion entre WordPress et MySQL qui échoue, pas les données elles-mêmes. Le seul cas de perte réelle est une table corrompue, et l'outil de réparation intégré (WP_ALLOW_REPAIR) la récupère le plus souvent.

Où trouver les identifiants de ma base de données ?

Ils sont écrits dans le fichier wp-config.php, à la racine de votre site (constantes DB_NAME, DB_USER, DB_PASSWORD, DB_HOST). Côté hébergeur, vous les retrouvez et les régénérez dans la section bases de données MySQL de votre panneau d'administration.

Pourquoi l'erreur apparaît seulement par moments ?

Une erreur intermittente trahit un problème de ressources, pas d'identifiants. La base sature aux pics de charge (trafic ou plugin gourmand), puis se libère au calme. Sur un hébergement mutualisé, un site voisin qui s'emballe peut aussi faire tomber le vôtre quelques minutes. Une base allégée et bien entretenue encaisse beaucoup mieux ces pics.

Changer le préfixe wp_ protège-t-il vraiment mon site ?

Partiellement. Remplacer le préfixe par défaut complique la tâche des scripts d'attaque automatisés qui ciblent les noms de tables connus, mais ça ne remplace pas une vraie sécurité (mots de passe forts, mises à jour, pare-feu). Voyez-le comme une porte fermée de plus, pas comme un coffre-fort. Faites-le toujours avec une sauvegarde, à la main si vous maîtrisez le SQL, ou avec un plugin dédié sinon.

Un plugin peut-il provoquer cette erreur ?

Oui, indirectement. Un plugin mal codé qui ouvre trop de connexions ou lance des requêtes en boucle peut faire saturer la base et déclencher un "Too many connections". Désactiver les extensions une par une, par FTP si l'admin est inaccessible, permet d'isoler le responsable.

Une dernière chose. Cette erreur a l'air brutale parce qu'elle prend tout le site d'un coup, mais elle fait partie des plus simples à corriger une fois qu'on sait où regarder. Gardez vos identifiants au chaud, vos sauvegardes à jour, votre base au régime, et le mode debug à portée de main : si une autre panne pointe le bout du nez, activer WP_DEBUG vous donnera le vrai message derrière l'écran. Le reste, c'est de la méthode. Et si la panne vous dépasse, ou s'installe sans qu'on en trouve la cause, confier le dépannage à un expert WordPress reste le chemin le plus court pour dormir tranquille.

Article original sur WPFormation