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

Ce message signifie que WordPress n’a pas pu parler à MySQL. Le code du site est intact, votre contenu aussi : c’est la liaison entre les deux qui a échoué. Avant de toucher à quoi que ce soit, une question tranche le diagnostic en deux : WordPress n’a-t-il jamais réussi à se connecter, ou a-t-il perdu une connexion établie ?

Deux messages qui se ressemblent, deux causes opposées

WordPress produit deux libellés distincts, et la plupart des articles les confondent. Ils ne mènent pourtant pas au même endroit.

• « Erreur lors de la connexion à la base de données » — la connexion n’a jamais été établie. Cherchez du côté des identifiants, du nom d’hôte, ou d’un serveur MySQL arrêté.
• « Erreur de reconnexion à la base de données » — la connexion existait et s’est interrompue en cours de requête. Les identifiants sont bons ; le serveur est saturé, a atteint sa limite de connexions simultanées, ou a coupé la liaison.

Le second cas mérite une précision utile : quand la liaison tombe, WordPress ne renonce pas tout de suite. Il retente cinq fois, avec une seconde d’attente entre chaque essai. C’est ce qui explique la sensation familière d’un site qui « rame pendant cinq secondes » avant d’afficher l’erreur — et c’est un indice : ce délai ne se produit pas quand les identifiants sont simplement faux, puisque l’échec est alors immédiat.

Obtenir l’erreur réelle

Sur la page publique, WordPress n’affiche qu’un titre. C’est délibéré : le détail contient le nom d’hôte de la base, qu’il ne faut pas exposer aux visiteurs. Mais dans l’administration, il imprime l’erreur entière.

Ouvrez donc https://votre-site.fr/wp-admin/. Vous y lirez la phrase complète : « 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 localhost ne peut pas être contacté. » Relevez ce nom d’hôte : c’est la valeur que WordPress utilise réellement, et la comparer à celle fournie par votre hébergeur résout à elle seule une bonne partie des cas.

Si vous voyez une page personnalisée

Si le message est habillé aux couleurs de votre hébergeur, il ne vient pas de WordPress mais d’un fichier wp-content/db-error.php. Ce drop-in court-circuite l’affichage par défaut, et vous ne verrez jamais l’erreur réelle tant qu’il est en place. Renommez-le le temps du diagnostic.

Vérifier les quatre valeurs de wp-config.php

Elles sont à la racine du site, en haut du fichier wp-config.php :

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

Plutôt que de les comparer à l’œil, testez-les. Déposez ce fichier à la racine du site sous le nom test-db.php, appelez-le dans le navigateur, puis supprimez-le immédiatement :

<?php
$c = @mysqli_connect( 'localhost', 'utilisateur', 'mot_de_passe', 'nom_de_la_base' );
echo $c ? 'Connexion OK' : 'Echec : ' . mysqli_connect_error();

Le message renvoyé est explicite là où WordPress reste muet : Access denied désigne l’utilisateur ou le mot de passe, Unknown database le nom de la base, et Connection refused ou Can’t connect le serveur lui-même.

Le nom d’hôte n’est pas toujours localhost

C’est la valeur la plus souvent fausse après une migration. Beaucoup d’hébergeurs mutualisés font tourner MySQL sur une autre machine et fournissent un nom propre au compte. Un port non standard s’écrit dans la même chaîne :

define( 'DB_HOST', 'mysql-51-2.serveur-hebergeur.net:3307' );

Les causes, par ordre de fréquence

1. Un mot de passe changé dans l’interface de l’hébergeur sans être reporté dans wp-config.php. Une réinitialisation suffit à couper le site.
2. Une migration : les identifiants du serveur d’origine ont suivi le site, mais ne valent rien sur le nouveau.
3. Le quota de connexions simultanées atteint sur un hébergement mutualisé. Signature : l’erreur va et vient, souvent aux heures de trafic, et parle de reconnexion.
4. L’espace disque saturé. MySQL refuse d’écrire, puis se bloque. À vérifier tôt : c’est invisible depuis WordPress et fréquent quand les sauvegardes s’empilent dans wp-content.
5. Une table corrompue après un arrêt brutal du serveur. C’est le seul cas qui justifie la réparation ci-dessous.

Réparer les tables, avec la précaution qui va avec

Si l’erreur ne survient que sur certaines pages, ou si l’administration signale une table endommagée, WordPress embarque un outil de réparation. Activez-le par une constante dans wp-config.php :

define( 'WP_ALLOW_REPAIR', true );

Rendez-vous ensuite sur https://votre-site.fr/wp-admin/maint/repair.php.

Cette page est volontairement accessible sans être connecté — il faut bien pouvoir réparer un site dont l’administration ne s’ouvre plus. Elle constitue donc une porte ouverte tant que la constante existe. Retirez la ligne dès la réparation terminée ; WordPress vous le rappelle lui-même à l’écran, et c’est un avertissement à prendre au sérieux.

Sauvegardez la base avant, par l’export de phpMyAdmin ou par mysqldump. Une réparation qui tourne mal sur une table déjà abîmée ne se rejoue pas.

Vérifier que le site est vraiment revenu

Comme pour toute panne, l’œil ne suffit pas : une page peut s’afficher tout en répondant en erreur, et continuer à envoyer aux moteurs le signal d’un serveur défaillant.

curl -I https://votre-site.fr/

Attendez-vous à HTTP/2 200. Si vous n’avez pas de terminal sous la main, le testeur d’en-têtes fait la même lecture depuis votre navigateur. Contrôlez aussi /robots.txt : une erreur qui persiste sur ce seul fichier interrompt l’exploration de tout le site.

Si l’erreur revient sans prévenir

Une erreur de base de données intermittente n’est pas un problème de configuration, c’est un problème de charge : requêtes trop lourdes, tâches planifiées qui se chevauchent, ou hébergement à bout de souffle. Rechercher la ligne fautive dans wp-config.php ne mènera nulle part.

Dans ce cas, l’intervention dure. Plutôt que de laisser les visiteurs et les moteurs tomber sur une erreur au hasard des rechargements, fermez proprement le site le temps des travaux : un statut 503 annoncé vaut infiniment mieux qu’une panne aléatoire. Et si vous cherchez plutôt du côté d’un plantage de PHP, voyez l’erreur critique WordPress.