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

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

En anglais : Error establishing a database connection

Votre site affiche un titre solitaire, « Erreur lors de la connexion à la base de données », sur fond blanc, parfois suivi d’un court texte et d’une liste de questions. L’erreur touche en général le site public et l’administration en même temps, puisque WordPress ne peut rien afficher sans sa base : articles, réglages, utilisateurs, tout y est stocké. Elle peut aussi être intermittente lors d’un pic de charge.

Le message dit seulement que la connexion a échoué. À vous de trouver pourquoi : mauvais identifiants, mauvais hôte, serveur de base indisponible ou saturé, base supprimée ou droits retirés. Les contenus sont presque toujours intacts, ce qui laisse une bonne marge pour réparer.

Ce que signifie cette erreur

À chaque requête, WordPress charge la classe wpdb (wp-includes/class-wpdb.php) et ouvre une connexion MySQLi avec les constantes DB_HOST, DB_USER, DB_PASSWORD et DB_NAME de wp-config.php. Si la méthode db_connect() n’obtient pas de connexion, elle appelle bail() avec le titre « Erreur lors de la connexion à la base de données » suivi du texte d’aide.

L’affichage dépend du contexte, dans dead_db() (wp-includes/functions.php) :

• sur le site public, seul le titre est montré, sous le titre de page « Erreur de la base de données » ;
• dans l’administration et à l’installation, le message détaillé est affiché : « Cela signifie soit que l’identifiant ou le mot de passe dans votre fichier wp-config.php n’est pas correct, soit que le serveur de base de données à l’adresse … ne peut pas être contacté. Cela peut signifier que votre serveur de base de données ne fonctionne plus. » La page demande ensuite si les identifiants, le nom d’hôte et le serveur sont corrects ;
• si le fichier wp-content/db-error.php existe, WordPress l’affiche à la place, ce qui permet de personnaliser la page.

La réponse HTTP est un code 500 par défaut. Trois messages voisins existent dans le même code : « Erreur de reconnexion à la base de données » (la connexion a été perdue en cours de requête), « Impossible de sélectionner la base données » (le serveur répond mais la base nommée dans DB_NAME n’est pas accessible) et « Une ou plusieurs tables de votre base de données sont indisponibles » (tables du cœur absentes ou illisibles, avec un lien vers l’outil de réparation).

Diagnostic rapide

Symptôme / constat	Cause probable	À vérifier
Erreur apparue juste après une migration ou un changement d’hébergeur	Identifiants ou hôte de la base différents	DB_NAME, DB_USER, DB_PASSWORD, DB_HOST dans wp-config.php
Plusieurs sites du même serveur sont en panne	Serveur MySQL/MariaDB arrêté ou saturé	Statut du service, espace disque, mémoire, page d’état de l’hébergeur
Le site tombe par intermittence, surtout aux heures de pointe	Trop de connexions simultanées	max_connections, robots, requêtes lentes
Message « Impossible de sélectionner la base données »	Base inexistante ou droits retirés	Nom de la base, privilèges de l’utilisateur
Le front est en erreur mais /wp-admin/ affiche « tables indisponibles »	Tables manquantes ou corrompues	wp db check, outil de réparation, sauvegarde
Message « Erreur de reconnexion à la base de données »	Connexion perdue en cours de requête (redémarrage, charge)	Journal du serveur de base ; fiche « MySQL server has gone away »

Les causes les plus fréquentes

1. Identifiants erronés dans wp-config.php : après une migration, un changement de mot de passe de la base ou une copie du site de préproduction.
2. Hôte incorrect : localhost ne convient pas partout. Certains hébergeurs fournissent un nom de serveur dédié, un port ou un socket.
3. Serveur de base arrêté ou en échec : maintenance, disque plein, mémoire insuffisante (le système tue le processus MySQL), crash.
4. Trop de connexions ouvertes en même temps lors d’un pic de trafic, d’un robot agressif ou d’une requête bloquante.
5. Base supprimée ou droits retirés à l’utilisateur de la base.
6. Tables du cœur corrompues ou manquantes, souvent après un arrêt brutal du serveur.

Solutions pas à pas

Avant d’intervenir sur la base ou les fichiers, faites une sauvegarde (export de la base et copie de wp-config.php). Du moins invasif au plus technique :

1. Vérifier que le problème est général

Rechargez la page dans quelques minutes : une surcharge passagère disparaît d’elle-même. Consultez la page d’état de votre hébergeur et testez un autre site hébergé au même endroit. Si tout est en panne, le serveur de base est en cause : contactez le support ou passez à l’étape 4.

2. Contrôler les identifiants dans wp-config.php

Ouvrez wp-config.php par SFTP ou depuis le gestionnaire de fichiers, et comparez avec les informations de votre panneau d’hébergement (section Bases de données) :

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

Surveillez les espaces en trop, les guillemets typographiques collés depuis un traitement de texte et les apostrophes dans le mot de passe. Pour valider les valeurs sans toucher au site, testez-les depuis un terminal :

mysql -h localhost -u utilisateur_de_la_base -p nom_de_la_base -e "SELECT 1;"

Si la commande réussit, les identifiants sont bons. Un message « Access denied for user » désigne un utilisateur ou un mot de passe faux ; « Unknown database » désigne un nom de base inexact.

3. Corriger DB_HOST

Essayez, selon votre hébergeur, l’une de ces valeurs. WordPress accepte un port ou un socket après les deux-points :

define( 'DB_HOST', 'localhost' );
define( 'DB_HOST', '127.0.0.1' );
define( 'DB_HOST', 'localhost:3306' );
define( 'DB_HOST', 'mysql.exemple-hebergeur.fr' );
define( 'DB_HOST', 'localhost:/var/run/mysqld/mysqld.sock' );

Rechargez le site après chaque essai. Si la valeur correcte ne figure pas dans votre panneau, demandez-la au support.

4. Vérifier que le serveur de base fonctionne

Sur un serveur dédié ou un VPS, connectez-vous en SSH :

sudo systemctl status mysql        # ou : mariadb
sudo systemctl restart mysql       # ou : mariadb
df -h                              # disque plein ?
free -m                            # mémoire disponible
sudo tail -n 50 /var/log/mysql/error.log

Le nom du service et le chemin du journal varient selon la distribution. Si le journal du système mentionne une mémoire insuffisante, le processus MySQL a été arrêté par le noyau : il faut réduire la consommation ou ajouter de la mémoire. Pour une saturation de connexions, connectez-vous à la base et comparez :

SHOW VARIABLES LIKE 'max_connections';
SHOW STATUS LIKE 'Threads_connected';

Une valeur proche du maximum explique un message « Too many connections ». Cherchez alors ce qui sature (robots, extension qui multiplie les requêtes) avant d’augmenter la limite. Notre article Erreur de connexion à la base de données : quand un thème s’effondre sous la charge détaille un cas réel.

5. Contrôler les droits et l’existence de la base

Si le message est « Impossible de sélectionner la base données », vérifiez dans phpMyAdmin ou en ligne de commande que la base existe et que l’utilisateur a le droit de l’utiliser :

SHOW DATABASES;
SHOW GRANTS FOR 'utilisateur_de_la_base'@'localhost';
GRANT ALL PRIVILEGES ON `nom_de_la_base`.* TO 'utilisateur_de_la_base'@'localhost';
FLUSH PRIVILEGES;

La commande GRANT demande un compte d’administration de la base. Chez un hébergeur mutualisé, rattachez plutôt l’utilisateur à la base depuis le panneau de gestion.

6. Réparer les tables

Si l’administration affiche « Une ou plusieurs tables de votre base de données sont indisponibles », exportez d’abord la base, puis lancez le contrôle :

wp db export sauvegarde.sql
wp db check
wp db repair

La réparation fonctionne pour les tables MyISAM ; pour InnoDB, restaurez plutôt une sauvegarde. Sans WP-CLI, ajoutez cette ligne à wp-config.php, ouvrez /wp-admin/maint/repair.php et cliquez sur « Réparer la base de données » :

define( 'WP_ALLOW_REPAIR', true );

Cette page est accessible sans connexion tant que la constante est présente : supprimez la ligne dès que la réparation est terminée.

7. Afficher une page de maintenance propre en attendant

Pour éviter qu’un visiteur ou Google ne tombe sur une page nue, créez wp-content/db-error.php. WordPress l’utilise en cas d’échec de connexion :

<?php
http_response_code( 503 );
header( 'Retry-After: 600' );
?>
<!DOCTYPE html>
<html lang="fr">
<head><meta charset="utf-8"><title>Site momentanément indisponible</title></head>
<body>
<h1>Site momentanément indisponible</h1>
<p>Nous revenons dans quelques minutes.</p>
</body>
</html>

Le code 503 indique aux moteurs de recherche que la panne est temporaire. Attention aussi aux caches de pages : ils peuvent conserver la page d’erreur avec un code 200, comme le montre notre article sur le cache qui masque une erreur de base de données.

8. Restaurer une sauvegarde

Si la base est détruite ou irréparable, restaurez la dernière sauvegarde saine : wp db import sauvegarde.sql ou l’import de phpMyAdmin. Testez le résultat dans un environnement séparé avant de remplacer la production, comme dans notre article sur la restauration en bac à sable.

Prévenir l’erreur

• Surveillez le serveur de base : disque, mémoire, nombre de connexions, avec une alerte avant la saturation.
• Sauvegardez la base chaque jour, hors du serveur, et vérifiez régulièrement que la restauration fonctionne.
• Limitez le trafic inutile : cache de pages, blocage des robots abusifs, requêtes allégées (voir Query Monitor).
• Notez les identifiants lors d’une migration et testez-les avant la bascule du DNS.
• Gardez une page db-error.php qui renvoie un code 503 plutôt qu’une page nue.

Questions fréquentes