Erreur lors de la connexion à la base de données

Cet article suit la page des erreurs courantes de WordPress et celle de wp-config.php, relues le 14 octobre 2026.

1. Le site est-il seul en cause ?

Ouvrez un autre site hébergé au même endroit, ou l'administration de votre hébergement. Si tout le reste fonctionne, le problème vient de la configuration de votre site, et la suite de cet article le règle. Si plusieurs sites sont touchés à la fois, le serveur de bases de données lui-même a sans doute un souci : consultez la page État du réseau et prévenez votre hébergeur.

Demandez-vous aussi ce qui a changé juste avant : un déménagement de site, un mot de passe modifié, une base renommée ou recréée. La cause est souvent là.

2. Comparer wp-config.php avec la base réelle

WordPress lit ses informations de connexion dans le fichier wp-config.php, à la racine du site. Elles s'y trouvent sur quatre lignes :

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

Sur un hébergement sous Plesk :

1. Dans Plesk, ouvrez « Sites Web & Domaines », puis « Bases de données ». Relevez le nom exact de la base et celui de son utilisateur ; le lien « Infos de connexion », sous le nom de la base, les rappelle.
2. Ouvrez wp-config.php avec le gestionnaire de fichiers de Plesk, depuis le dossier du site.
3. Comparez caractère par caractère DB_NAME et DB_USER avec ce que montre Plesk. Une majuscule, un préfixe oublié ou un espace suffisent à bloquer la connexion.
4. Vérifiez que DB_HOST vaut localhost. Chez Hubspace, le site et sa base sont sur le même serveur : c'est la bonne valeur.
5. Enregistrez le fichier et rechargez le site.

Si le site vient d'un autre hébergeur, l'ancien fichier porte souvent l'hôte de cet hébergeur, une adresse en mysql.quelquechose ou une IP. Remplacez-le par localhost.

3. Remettre un mot de passe connu

Le mot de passe est la seule valeur qu'on ne peut pas comparer d'un coup d'œil. Le plus rapide est d'en choisir un nouveau des deux côtés :

1. Dans Plesk, page « Bases de données », ouvrez la gestion des utilisateurs de la base et définissez un nouveau mot de passe pour celui du site, long, sans apostrophe pour ne pas casser la ligne de wp-config.php.
2. Recopiez exactement ce mot de passe dans DB_PASSWORD, entre les apostrophes.
3. Enregistrez et rechargez le site.

C'est aussi la piste que donne la documentation de WordPress quand les informations semblent justes.

4. Réparer la base

Si la connexion fonctionne mais que WordPress signale une base endommagée, ou si l'administration annonce qu'une ou plusieurs tables ne sont pas disponibles, WordPress sait réparer lui-même. Ajoutez dans wp-config.php :

define( 'WP_ALLOW_REPAIR', true );

Puis ouvrez l'adresse de votre site suivie de /wp-admin/maint/repair.php et lancez la réparation. Cette page s'ouvre sans connexion, ce qui la rend utilisable quand l'administration est bloquée, mais aussi pour n'importe qui : retirez la ligne, ou passez la valeur à false, dès la réparation finie.

La même opération est possible dans phpMyAdmin : sélectionnez les tables, puis l'action de réparation dans la liste du bas. Voir Utiliser phpMyAdmin.

5. Si rien ne change

Si les quatre valeurs sont justes, que le mot de passe vient d'être remis et que l'erreur persiste, la documentation de WordPress cite deux causes restantes : un incident du côté de l'hébergeur, et un site compromis dont la configuration a été modifiée. Dans le second cas, voir Nettoyer un site WordPress piraté.

Chez Hubspace, appelez-nous ou ouvrez un ticket depuis votre espace client : nous vérifions l'état du serveur de bases de données et, si besoin, restaurons la base de la veille depuis la sauvegarde quotidienne, gardée 30 jours.

Questions fréquentes