WordPress : erreur lors de l’établissement de la connexion à la base de données

Ce que signifie cette erreur et comment la reconnaître

• Le site affiche uniquement « Error establishing a database connection », souvent sur toutes les pages publiques.
• /wp-admin/ est également indisponible, car il utilise la même connexion à la base de données.
• L’erreur peut apparaître après une migration, un changement d’hébergement, une restauration de base de données, une modification manuelle de wp-config.php, une réinitialisation du mot de passe ou un redémarrage du serveur de base de données.
• Si seules certaines pages échouent tandis que d’autres pages utilisant la base de données fonctionnent, le problème peut être spécifique à une page, une extension, un thème ou une requête, plutôt qu’à une défaillance complète de la connexion à la base de données.

Causes principales, classées par probabilité

1. Identifiants incorrects dans wp-config.php — DB_NAME, DB_USER, DB_PASSWORD ou DB_HOST ne correspond plus à la configuration actuelle de la base de données. C’est particulièrement fréquent après une migration, une restauration, un changement de mot de passe ou une modification manuelle.
2. Serveur MySQL ou MariaDB indisponible — le service peut s’être arrêté, avoir rencontré une erreur ou être devenu indisponible en raison d’un problème de ressources chez l’hébergeur.
3. Hôte de base de données incorrect — localhost peut être incorrect lorsque la base de données s’exécute sur un autre serveur ou conteneur, tandis qu’une valeur d’hôte distant peut ne plus correspondre à l’environnement actuel.
4. Privilèges manquants pour l’utilisateur de la base de données — l’utilisateur peut exister sans être associé à la base de données WordPress ou sans disposer des privilèges nécessaires pour l’utiliser.
5. Tables de base de données corrompues — une écriture interrompue, un arrêt incorrect ou un problème de disque peut endommager les tables, mais cette cause est généralement moins probable qu’un problème de configuration ou de disponibilité.

Comment corriger le problème

1. Confirmez l’étendue de la défaillance

Ouvrez le site public et /wp-admin/. Si les deux affichent l’erreur de connexion, poursuivez avec les vérifications de la base de données ci-dessous. Si une seule page ou fonction échoue, examinez plutôt l’extension, le thème, la requête ou l’erreur applicative concernée, au lieu de supposer que toute la connexion à la base de données est indisponible.

2. Vérifiez que MySQL ou MariaDB fonctionne

Sur un VPS ou un serveur dédié dont vous assurez l’administration, vérifiez l’état du service concerné. Ces commandes sont en lecture seule et nécessitent un accès shell :

systemctl status mysql

Si le serveur utilise MariaDB, vérifiez :

systemctl status mariadb

Sur un hébergement mutualisé ou géré, consultez les informations d’état de la base de données dans le panneau d’hébergement ou demandez à l’hébergeur de vérifier le service et les limites de ressources. Ne redémarrez un service de base de données que si vous administrez ce serveur, disposez de l’autorisation appropriée et avez confirmé que l’impact opérationnel est acceptable ; un redémarrage peut interrompre les connexions actives à la base de données.

3. Vérifiez les quatre paramètres de base de données dans wp-config.php

Utilisez SFTP ou le gestionnaire de fichiers de l’hébergeur pour ouvrir wp-config.php. Comparez ces valeurs avec les informations actuelles de la base de données indiquées dans le panneau d’hébergement ou les documents de migration :

• DB_NAME — la base de données que WordPress doit utiliser
• DB_USER — le nom d’utilisateur de la base de données
• DB_PASSWORD — le mot de passe actuel de cet utilisateur
• DB_HOST — l’adresse ou le paramètre d’hôte du serveur de base de données

Recherchez un nom de base de données obsolète, un ancien mot de passe, un hôte incorrect ou des espaces et modifications accidentels des guillemets. Ne supposez pas que les anciennes valeurs restent valides après une migration, un changement d’hébergement, une restauration de base de données ou une réinitialisation du mot de passe.

4. Testez la même connexion en dehors de WordPress

Utilisez phpMyAdmin ou la ligne de commande MySQL avec le nom de base de données, le nom d’utilisateur, le mot de passe et l’hôte exacts indiqués dans wp-config.php. Ce test doit utiliser le même environnement et les mêmes identifiants que WordPress.

• Si la connexion directe échoue, examinez les identifiants, l’hôte de la base de données, la disponibilité du serveur ou l’accès réseau avant de modifier les fichiers WordPress.
• Si la connexion directe réussit, le chemin de connexion de base au serveur et les identifiants fonctionne ; poursuivez en vérifiant l’association de l’utilisateur à la base de données, les privilèges et l’état des tables.

Ne publiez jamais le mot de passe ni l’intégralité du fichier wp-config.php lorsque vous demandez de l’aide.

5. Confirmez l’accès et les privilèges de l’utilisateur de la base de données

Dans la section consacrée aux utilisateurs de bases de données du panneau d’hébergement, vérifiez que l’utilisateur indiqué dans wp-config.php est associé à la bonne base de données WordPress et peut lire et modifier ses tables. Cette vérification est particulièrement importante après la restauration d’une base de données sous un nouveau compte ou la création d’un utilisateur de remplacement.

Si vous administrez directement MySQL, un administrateur autorisé peut examiner les droits du compte avec SHOW GRANTS. Corrigez l’association entre l’utilisateur et la base de données ou les privilèges uniquement après avoir confirmé la base de données et le compte concernés. Répétez ensuite le test de connexion directe et rechargez le site.

6. Vérifiez les problèmes de tables uniquement une fois la connexion établie

Si le serveur de base de données est disponible, que les identifiants exacts fonctionnent lors d’un test direct et que l’utilisateur dispose d’un accès, examinez les tables WordPress dans phpMyAdmin ou via un outil de base de données autorisé. CHECK TABLE peut signaler des problèmes au niveau des tables.

Créez ou vérifiez une sauvegarde récente de la base de données avant toute tentative de réparation. REPAIR TABLE concerne principalement les tables MyISAM prises en charge et ne constitue pas une méthode de réparation universelle. N’exécutez pas les commandes de réparation de manière répétée lorsque les vérifications ne signalent aucune corruption ; revenez à l’hôte, à la configuration, aux privilèges et aux journaux du serveur pour poursuivre le diagnostic.

7. Vérifiez l’ensemble du site après la correction

Chargez plusieurs pages publiques ainsi que /wp-admin/. Si les deux fonctionnent, videz uniquement les couches de cache concernées si un ancien affichage persiste. Si l’une des deux zones échoue encore, relevez le message exact affiché et consultez les journaux du serveur ou de l’hébergement au lieu de supposer que le problème de connexion initial est inchangé.

Prévention et vérification du correctif

• Conservez le nom, l’utilisateur, l’hôte et le mot de passe actuels de la base de données dans un gestionnaire de mots de passe protégé ou un support sécurisé équivalent.
• Après chaque migration ou changement d’hébergement, testez le site public et /wp-admin/ avant de finaliser le transfert.
• Effectuez régulièrement des sauvegardes de la base de données et vérifiez périodiquement qu’une restauration est possible.
• Notez quel utilisateur de base de données est associé à chaque base WordPress afin qu’une restauration ou un remplacement d’utilisateur ne supprime pas silencieusement l’accès.
• Consultez les alertes de ressources de l’hébergement et les événements du service de base de données lorsqu’ils sont disponibles, notamment après des redémarrages inattendus ou des échecs de connexion récurrents.
• Limitez l’accès à wp-config.php et évitez de partager son contenu ou ses identifiants dans les demandes d’assistance.

Questions fréquentes