Erreur de Connexion à la Base de Données

Commencez par deux questions

Avant toute modification, ouvrez votresite.fr/wp-admin et comparez avec la page d'accueil. La différence indique la branche du diagnostic :

1. Vérifier les identifiants

Ouvrez wp-config.php. Ces quatre valeurs doivent correspondre exactement à celles de votre hébergeur :

define( 'DB_NAME', 'votre_base' );
define( 'DB_USER', 'votre_utilisateur' );
define( 'DB_PASSWORD', 'votre_mot_de_passe' );
define( 'DB_HOST', 'localhost' );

Celle qui piège le plus est DB_HOST. localhost convient à la plupart des mutualisés, mais certains hébergeurs exigent 127.0.0.1, un port (127.0.0.1:3306) ou un nom d'hôte dédié. Si votre hébergeur vous a récemment migré de serveur, c'est très souvent la seule valeur qui a changé.

2. Tester la connexion hors WordPress

Ne devinez pas : prouvez-le. Déposez ce fichier à la racine sous le nom dbtest.php, chargez-le, puis supprimez-le immédiatement :

<?php
$c = @new mysqli('localhost', 'votre_utilisateur', 'votre_mot_de_passe', 'votre_base');
echo $c->connect_error ? 'ÉCHEC : ' . $c->connect_error : 'Connexion réussie.';

« Connexion réussie » signifie que les identifiants sont bons et que le problème est ailleurs : tables corrompues, extension qui monopolise les connexions, ou wp-config.php altéré. Access denied = identifiant ou mot de passe erroné. Can't connect to MySQL server = le service lui-même est injoignable.

3. Le serveur de base fonctionne-t-il ?

• Vos autres sites sur le même compte sont aussi hors ligne ? Problème au niveau serveur. Contactez l'hébergeur : il n'y a rien à corriger dans vos fichiers.
• Le site fonctionne par intermittence, et tombe sous la charge ? Vous atteignez la limite max_connections. Fréquent en mutualisé lors d'un pic — souvent causé par une requête lente qui retient les connexions.
• Quotas dépassés récemment ? Certains hébergeurs suspendent la base avant le compte. Vérifiez votre facturation et vos e-mails.

4. Réparer les tables corrompues

Si l'administration signale une base à réparer, ajoutez dans wp-config.php :

define( 'WP_ALLOW_REPAIR', true );

Rendez-vous ensuite sur votresite.fr/wp-admin/maint/repair.php et lancez la réparation. Une fois terminé, retirez immédiatement cette ligne : tant qu'elle est présente, la page de réparation est accessible à tout internaute, sans authentification.

5. Quand c'est en réalité une compromission

Cause moins évidente : un code malveillant a réécrit wp-config.php. Certaines infections corrompent le fichier au passage, d'autres injectent du code avant l'ouverture <?php et cassent l'analyse syntaxique. Vérifiez que le fichier commence proprement, ne contient ni eval() ni blocs base64 inattendus, et que les identifiants sont bien les vôtres.

Si le mot de passe de la base a changé sans votre intervention, traitez cela comme un incident de sécurité, pas comme un problème de configuration.

Questions fréquentes

Quelles sont les causes de cette erreur ?

WordPress n'a pas pu joindre MySQL. Quatre causes courantes : identifiants erronés, serveur de base arrêté ou saturé, tables corrompues, limite de connexions atteinte en mutualisé.

Pourquoi maintenant, alors que je n'ai rien changé ?

Généralement l'hébergeur a redémarré ou saturé le serveur, une limite a été atteinte pendant un pic, ou le compte a été suspendu. Cela peut aussi suivre une rotation automatique de mot de passe.

Vais-je perdre mon contenu ?

Presque jamais. Les données sont sur le disque, WordPress ne les atteint pas. Même une corruption réelle se répare le plus souvent.

Ça marche par moments, puis ça retombe.

Épuisement classique des connexions. Votre base autorise un nombre fixe de connexions simultanées et vous atteignez le plafond sous charge. Le vrai correctif est de trouver la requête lente responsable.