Erreur lors de la connexion à la base de données WordPress : comment la corriger

Vous chargez votre site et chaque page — partie publique comme wp-admin — est remplacée par une seule phrase grise : Erreur lors de la connexion à la base de données. Rien ne s’affiche, parce que rien ne le peut. WordPress n’est même pas allé jusqu’à construire une page.

Voici le modèle mental qui rend la correction rapide. WordPress conserve tout votre contenu — articles, pages, réglages, utilisateurs — dans une base de données MySQL, pas dans des fichiers. À chaque requête, il lit quatre identifiants depuis wp-config.php, se connecte à cette base de données et en tire ce dont il a besoin. Cette erreur signifie que cette connexion a été tentée et refusée. La solution consiste à déterminer pourquoi elle a été refusée, et il n’y a que trois possibilités.

Les trois causes, par ordre de probabilité

1. Un identifiant erroné dans wp-config.php : le résultat habituel d’un changement d’hébergeur.
2. Le serveur de base de données est hors service ou surchargé : le résultat habituel de rien n’a changé de votre côté.
3. La base de données est corrompue : plus rare, et elle se manifeste autrement.

Parcourez-les dans cet ordre.

Étape 1 : vérifiez les quatre identifiants

Ouvrez wp-config.php à la racine de votre site via SFTP ou le gestionnaire de fichiers de votre hébergeur. Quatre lignes définissent la connexion :

define( 'DB_NAME', 'your_database_name' );
define( 'DB_USER', 'your_database_user' );
define( 'DB_PASSWORD', 'your_database_password' );
define( 'DB_HOST', 'localhost' );

Chacune d’elles doit correspondre exactement à ce que votre hébergeur a attribué. Ouvrez la section base de données du panneau de contrôle de votre hébergement (dans cPanel, c’est “MySQL Databases”) et comparez caractère par caractère :

• DB_NAME : les hébergeurs préfixent souvent le nom avec celui de votre compte, comme cpaneluser_wpdb. Le préfixe fait partie du nom.
• DB_USER : le même préfixage s’applique, et l’utilisateur doit être rattaché à cette base de données, pas seulement exister.
• DB_PASSWORD : le coupable le plus fréquent, et de loin. En cas de doute, réinitialisez-le dans le panneau de contrôle et collez la nouvelle valeur. Méfiez-vous d’un espace en fin de chaîne ou d’une guillemet typographique.
• DB_HOST : ne présumez pas localhost. De nombreux hébergeurs utilisent un serveur de base de données dédié avec une adresse comme mysql.yourhost.com, parfois avec un :port. Le panneau de contrôle affiche la bonne valeur.

Comme ce fichier est justement l’endroit où vivent ces quatre valeurs, le moyen le plus sûr de régénérer un wp-config.php propre et correctement échappé est le générateur de wp-config.php : remplissez les quatre champs de la base de données et collez le résultat par-dessus l’ancien bloc.

Cette étape à elle seule corrige l’erreur après presque chaque migration, car des identifiants qui étaient corrects sur l’ancien hébergement sont erronés sur le nouveau.

Étape 2 : confirmez que le serveur de base de données est bien actif

Si les identifiants sont corrects et que l’erreur persiste — surtout si elle est apparue toute seule, sans aucun changement de votre part — c’est le serveur de base de données lui-même qui est en cause.

Sur un hébergement mutualisé, c’est fréquent et généralement temporaire : le service MySQL est débordé lors d’un pic de trafic ou atteint sa limite de connexions par compte et se met à refuser les nouvelles connexions. Il récupère habituellement en quelques minutes. Rechargez après une courte attente avant de faire quoi que ce soit de radical.

Pour vérifier si les identifiants sont seulement valides, indépendamment de WordPress, déposez un petit script à côté de wp-config.php :

<?php
$link = mysqli_connect('localhost', 'your_database_user', 'your_database_password');
if (!$link) {
    die('Connection failed: ' . mysqli_connect_error());
}
echo 'Connected — the server and credentials are fine.';

Utilisez vos véritables DB_HOST, DB_USER et DB_PASSWORD. S’il affiche Connected, vos identifiants fonctionnent et le problème est ailleurs (une base de données corrompue, étape 3). S’il affiche une erreur de connexion, le message vous indique laquelle : “Access denied” signifie un utilisateur ou un mot de passe erroné ; “Can’t connect to MySQL server” signifie un hôte erroné ou un service réellement hors service — il est temps de contacter votre hébergeur. Supprimez le script dès que vous avez terminé.

Étape 3 : réparez une base de données corrompue

Un indice distingue la corruption d’un problème de connexion : la partie publique se charge mais wp-admin affiche l’erreur, ou l’inverse. Si la connexion était vraiment refusée, les deux seraient hors service. Un tel écart pointe vers des tables endommagées.

WordPress dispose d’un outil de réparation intégré. Ajoutez une ligne à wp-config.php, au-dessus du commentaire “stop editing” :

define( 'WP_ALLOW_REPAIR', true );

Rendez-vous ensuite directement sur cette URL dans votre navigateur :

https://yoursite.com/wp-admin/maint/repair.php

Elle se charge sans connexion — c’est justement le but, puisque vous pouvez être bloqué à l’extérieur — et propose “Repair Database” et “Repair and Optimize Database”. Lancez-la.

Supprimez ensuite immédiatement cette ligne de wp-config.php. Tant qu’elle est présente, n’importe qui sur Internet peut accéder à cette URL et lancer une réparation de votre base de données. Ce n’est pas un nettoyage facultatif ; c’est refermer une faille que vous venez d’ouvrir.

Étape 4 : quand la réparation ne parvient même pas à se connecter

Si la page de réparation elle-même affiche l’erreur de connexion, il n’y a rien à réparer — la base de données est totalement inaccessible, vous revoilà donc à l’étape 1 ou à l’étape 2. À ce stade, la manœuvre fiable est de restaurer la base de données depuis la sauvegarde la plus récente de votre hébergeur. La plupart des panneaux de contrôle conservent des instantanés quotidiens automatiques de la base de données ; une restauration d’hier soir est presque toujours plus rapide et plus sûre que de courir après une corruption à laquelle vous ne pouvez pas vous connecter.

Conseils que vous pouvez ignorer sans risque

« Réinstallez simplement WordPress. » Cette erreur concerne la connexion à la base de données, pas les fichiers du cœur. Réinstaller remplace précisément les fichiers qui fonctionnent bien et ne touche à rien de ce qui est cassé.

« Augmentez votre limite de mémoire PHP. » L’épuisement de la mémoire est une erreur différente, avec un message différent. Augmenter la limite ne fait rien pour une connexion à la base de données refusée et ne fait que masquer le fait que vous n’avez jamais vérifié les identifiants.

« Videz votre cache. » L’échec se produit dans PHP avant qu’un cache puisse servir une page. Vider le cache ne change rien tant que la connexion est refusée ; cela ne vaut la peine qu’après le retour du site.

« Modifiez directement la base de données pour la réparer. » Se précipiter sur phpMyAdmin pour éditer des tables à la main avant d’avoir confirmé que la connexion fonctionne, c’est ainsi qu’une panne temporaire devient une perte de données définitive. Confirmez d’abord la connexion ; touchez aux données en dernier, et uniquement depuis une sauvegarde.

Toujours bloqué ?

Si les identifiants se vérifient avec le script de test, que le serveur est actif, et que la réparation se connecte et ne signale aucune erreur, mais que le site affiche toujours le message, le suspect restant est une extension qui parle à la base de données via sa propre connexion — une extension de cache ou de base de données qui a enregistré un hôte obsolète. Renommez wp-content/plugins en plugins-off via SFTP pour l’écarter. Si l’erreur disparaît, réintroduisez les extensions une par une jusqu’à ce qu’elle revienne.