« Erreur lors de la connexion à la base de données » : que faire ?WordPress ne joint plus ses contenus. Voici comment rétablir le lien.

1. Regardez l'administration et l'état de l'hébergeur : une panne annoncée se règle en attendant.
2. Faites une copie de wp-config.php avant d'y toucher.
3. Lisez le code exact dans le journal : 1045, 1049, 2002 ou 1040 désignent chacun une cause.
4. Comparez les identifiants de wp-config.php avec ceux de l'espace de l'hébergeur.
5. Réparez les tables avec WP_ALLOW_REPAIR, puis retirez la ligne.
6. En dernier recours, restaurez la base seule et appelez l'hébergeur avec le code.

Dans ce guide

• Ce que veut dire le message
• Les causes, de la plus fréquente à la plus rare
• La marche à suivre, dans l'ordre
• Ce que nous ferions à votre place
• Questions fréquentes

Un site WordPress tient en deux morceaux : des fichiers (WordPress, le thème, les extensions, les images) et une base de données, qui range les pages, les articles, les réglages, les comptes et les commandes. À chaque visite, WordPress se connecte à cette base avec les identifiants écrits dans son fichier wp-config.php. Quand la connexion échoue, il ne peut rien afficher et montre « Erreur lors de la connexion à la base de données ».

Dans l'administration (votresite.fr/wp-admin), le message est parfois différent : WordPress indique que des tables sont indisponibles et propose de réparer la base. C'est une autre piste, plus précise, traitée à l'étape 6.

Le journal des erreurs donne le code exact, et ce code dit presque tout :

1. Le serveur de base de données est en panne ou saturé chez l'hébergeur. C'est souvent temporaire : le site revient seul au bout de quelques minutes, puis l'erreur peut revenir aux heures chargées.
2. Les identifiants ne correspondent plus : le mot de passe de l'utilisateur de la base a été changé dans l'espace de l'hébergeur, le site a déménagé, une restauration a remis un ancien wp-config.php.
3. Le mauvais serveur de base (DB_HOST) : « localhost » chez beaucoup d'hébergeurs, mais une adresse dédiée chez d'autres, indiquée dans la fiche de la base. Une erreur fréquente après un déménagement.
4. Trop de connexions, ou un quota dépassé : des robots qui bombardent le site, une extension qui multiplie les requêtes, une base devenue plus grosse que ce que l'offre autorise, un espace disque plein.
5. Des tables abîmées, souvent celle des réglages (wp_options), après un plantage du serveur ou un disque plein.
6. Un hébergement suspendu, ou une base supprimée : facture impayée, offre arrivée à échéance, nettoyage d'un ancien compte.
7. Plus rarement, une intrusion : un wp-config.php modifié, des tables vidées ou remplacées. C'est une intrusion repérée : suivez notre guide du site WordPress piraté.

1. Regardez l'administration et l'état de l'hébergeur

Ouvrez votresite.fr/wp-admin : si WordPress parle de tables indisponibles et de réparation, passez à l'étape 6. Puis regardez la page d'état de votre hébergeur et vos e-mails : une panne ou une maintenance annoncée explique tout, et il suffit d'attendre. Si d'autres sites hébergés au même endroit sont tombés en même temps, c'est aussi le serveur.

2. Faites une copie de wp-config.php

Par FTP ou avec le gestionnaire de fichiers de l'hébergeur, téléchargez wp-config.php, à la racine du site, avant de le modifier. Une faute de frappe dans ce fichier peut arrêter tout le site : la copie permet de revenir en arrière en une seconde.

3. Lisez le code exact

Dans le journal des erreurs de l'hébergeur (sous cPanel, Métriques, puis Erreurs ; sous Plesk, Journaux), ou dans celui de WordPress : ajoutez dans wp-config.php define('WP_DEBUG', true);, define('WP_DEBUG_LOG', true); et define('WP_DEBUG_DISPLAY', false); (en remplaçant la ligne WP_DEBUG existante), rechargez le site, puis ouvrez wp-content/debug.log. Une ligne du type mysqli_real_connect(): (HY000/1045): Access denied for user donne le code : le tableau plus haut dit où chercher.

4. Comparez wp-config.php avec l'espace de l'hébergeur

Les quatre lignes qui comptent ressemblent à ceci :

define('DB_NAME', 'compte_wp123');
define('DB_USER', 'compte_wpuser');
define('DB_PASSWORD', 'le-mot-de-passe');
define('DB_HOST', 'localhost');

Sous cPanel, ouvrez « Bases de données MySQL » : la liste montre chaque base, et, dans la colonne des utilisateurs privilégiés, l'utilisateur qui y a accès. Le nom et l'utilisateur doivent être identiques à ceux du fichier, préfixe compris (sous cPanel, les noms commencent par celui du compte). L'utilisateur doit avoir tous les privilèges sur la base. Pour le mot de passe, le plus sûr est d'en définir un nouveau pour cet utilisateur, puis de le recopier dans DB_PASSWORD. Évitez l'apostrophe dans ce mot de passe : elle couperait la ligne de PHP. Pour DB_HOST, reprenez l'adresse indiquée par l'hébergeur dans la fiche de la base.

5. Si le site a déménagé

Vérifiez aussi que la base a été importée en entier, et que la ligne $table_prefix de wp-config.php correspond au début du nom des tables importées (wp_ par défaut). Avec un mauvais préfixe, WordPress ne trouve pas ses tables et propose de s'installer à nouveau : n'acceptez pas, corrigez le préfixe.

6. Réparez les tables

Ajoutez dans wp-config.php la ligne define('WP_ALLOW_REPAIR', true);, puis ouvrez votresite.fr/wp-admin/maint/repair.php et lancez la réparation. Retirez la ligne aussitôt après : tant qu'elle est là, cette page est ouverte à n'importe qui, sans connexion. Vous pouvez aussi passer par phpMyAdmin : cochez les tables, puis choisissez « Réparer la table ». La réparation agit surtout sur les tables au format MyISAM ; avec InnoDB, le format des bases récentes, une table vraiment abîmée se récupère plutôt depuis une sauvegarde.

7. Si le serveur est saturé ou plein

Regardez l'utilisation des ressources et de l'espace disque dans l'espace de l'hébergeur. Un disque plein, souvent à cause de sauvegardes ou de journaux accumulés sur le serveur, empêche la base d'écrire : libérez de la place. Des pics de connexions viennent souvent de robots : le journal des visites (sous cPanel, « Visiteurs » ou « Accès bruts ») montre les adresses qui bombardent wp-login.php ou xmlrpc.php, à bloquer.

8. En dernier recours, restaurez la base

Si la base est perdue ou trop abîmée, restaurez-la seule, sans les fichiers, depuis la sauvegarde la plus récente de l'hébergeur. Avant, notez ce qui sera perdu entre la date de la sauvegarde et aujourd'hui : commandes, messages, inscriptions. Puis contactez l'hébergeur avec le code exact et l'heure de l'erreur : c'est lui qui voit le serveur de base de données.

9. Une fois le site revenu

Remettez WP_DEBUG à false, supprimez wp-content/debug.log, vérifiez que la ligne WP_ALLOW_REPAIR a bien disparu, et gardez la copie de wp-config.php qui marche en lieu sûr, hors du serveur.

• Erreur critique WordPress : « Il y a eu une erreur critique sur ce site » : trouver l'extension ou le thème fautif, et le désactiver.
• Erreur 500 WordPress : « Internal Server Error » : le fichier .htaccess, une extension, la version de PHP ou la mémoire.
• Erreur 503 WordPress : Site bloqué en maintenance après une mise à jour, ou serveur saturé.
• Page blanche WordPress : Rien ne s'affiche, sur tout le site, dans l'administration ou sur une seule page.

Toutes les erreurs, classées par message : Erreurs de site, trouver la cause et réparer. Des signes d'intrusion (redirections, pages inconnues, fichiers que vous n'avez pas mis) : suivez plutôt notre guide site WordPress piraté, que faire dans la première heure.

Rédigé par l'équipe Boost de WS Agency, qui maintient et protège des sites WordPress, PrestaShop et Joomla. Publié le 20 octobre 2026. Manipulations vérifiées le 20 octobre 2026 sur WordPress 7.1 ; elles valent aussi pour WordPress 6, et pour PHP 8.1 à 8.5.

• WordPress, les réglages de wp-config.php (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST, WP_ALLOW_REPAIR).
• WordPress, les erreurs courantes de WordPress.
• WordPress, déboguer WordPress (WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY).
• MySQL, la liste des codes d'erreur (1040, 1044, 1045, 1049, 2002, 2005, 2006).
• WordPress, historique des versions (7.1.3 et 7.0.7 publiées le 6 octobre 2026) et configuration recommandée (PHP 8.3 ou plus).

Une erreur, une information à compléter, un droit de réponse ? Écrivez à contact@wsagency.fr : nous corrigeons, et nous indiquons ici ce qui a changé et quand.