Erreur de connexion à la base de données WordPress : que faire ?

L’erreur de connexion à la base de données WordPress signifie que le site ne parvient pas à accéder aux données nécessaires à son fonctionnement. Vérifiez d’abord les identifiants dans wp-config.php, puis la disponibilité du serveur de base de données et les droits de l’utilisateur. Une panne de l’hébergeur, une saturation ou des tables endommagées peuvent aussi être en cause.

Identifier l’étendue de la panne WordPress

WordPress utilise PHP pour communiquer avec une base MySQL ou MariaDB. Celle-ci contient notamment les articles, les pages, les réglages et les utilisateurs. Si la connexion échoue, WordPress ne peut pas lire ces informations et affiche un message générique, parfois en anglais : « Error establishing a database connection ».

Commencez par ouvrir la page d’accueil, puis l’administration à l’adresse /wp-admin/. Notez ce que vous observez :

• Si les deux sont inaccessibles avec le même message, cherchez en priorité un problème de connexion global.
• Si l’administration fonctionne mais pas certaines pages, examinez aussi le cache, les tables concernées et les éventuelles surcharges.
• Si les pages chargent longtemps avant d’échouer, le serveur peut être indisponible ou saturé.

Relevez l’heure du problème et les changements récents : migration, restauration, mise à jour, modification d’une extension ou du thème, changement d’hébergement ou de DNS. Ces indices facilitent la recherche de la cause, sans prouver à eux seuls son origine.

Avant toute modification, faites une sauvegarde des fichiers et de la base si vous y avez accès. Si vous disposez d’une sauvegarde antérieure, vérifiez qu’elle est exploitable avant d’envisager une restauration.

Vérifier les paramètres de connexion à la base de données

Le fichier wp-config.php, situé à la racine de l’installation WordPress, contient les paramètres de connexion. Vous pouvez y accéder par FTP, SSH ou depuis le gestionnaire de fichiers de votre hébergeur.

Ouvrez une copie du fichier et comparez les valeurs suivantes avec celles de votre panneau d’hébergement :

• DB_NAME : le nom de la base de données.
• DB_USER : l’utilisateur de la base.
• DB_PASSWORD : son mot de passe.
• DB_HOST : l’adresse du serveur de base de données.

Une faute de frappe ou un mot de passe de base modifié sans mise à jour du fichier suffit à empêcher la connexion. Après correction, enregistrez le fichier, puis rechargez le site et l’administration.

Contrôler l’hôte et les droits de l’utilisateur

La valeur de DB_HOST est souvent localhost, mais elle peut aussi être un nom de serveur, une adresse IP ou une autre valeur fournie par l’hébergeur. Ne la remplacez pas par localhost au hasard : vérifiez celle qui correspond à votre installation, particulièrement après une migration ou un changement d’offre.

Dans le panneau d’hébergement ou phpMyAdmin, vérifiez également que :

1. La base indiquée dans DB_NAME existe.
2. L’utilisateur indiqué dans DB_USER est associé à cette base.
3. Cet utilisateur dispose des droits nécessaires aux opérations WordPress, notamment SELECT, INSERT, UPDATE, DELETE, CREATE et ALTER.

Si le mot de passe a été réinitialisé, reportez la nouvelle valeur dans wp-config.php. Ne transmettez pas le contenu de ce fichier ni vos identifiants dans un message public.

Tester la base et vérifier le serveur

Tester la connexion indépendamment de WordPress permet de distinguer un problème d’accès à la base d’une autre cause. Selon les outils disponibles chez votre hébergeur :

1. Ouvrez phpMyAdmin, sélectionnez la base et essayez de parcourir ses tables.
2. Consultez l’interface de l’hébergeur pour vérifier l’état du service MySQL ou utiliser son éventuel test de connexion.
3. Si vous disposez d’un accès SSH et du client MySQL, testez les identifiants avec la commande suivante :

mysql -h HOST -u USER -p

Remplacez HOST et USER par les valeurs adaptées. Le mot de passe est demandé après l’exécution de la commande. Un accès réussi depuis un autre outil est un indice utile, mais ne garantit pas que WordPress utilise les mêmes paramètres ou le même chemin réseau.

Une erreur d’authentification peut signaler un mot de passe incorrect ou un utilisateur sans accès. Une base absente doit être recherchée dans le panneau d’hébergement. Si phpMyAdmin ne charge pas ou répond très lentement, le service peut être indisponible ou saturé, sans que ce soit la seule explication possible.

Repérer une panne ou une limite de ressources

Consultez la page d’état de l’hébergeur et, si elles sont accessibles, les métriques de CPU, de mémoire, d’entrées-sorties, d’espace disque et de connexions à la base. Un redémarrage MySQL, un disque plein ou une limite de connexions peut provoquer une interruption.

Une panne apparue sans changement récent, qui touche plusieurs sites du même hébergement ou disparaît puis revient, justifie aussi une vérification auprès de l’hébergeur. Communiquez-lui l’heure, le message exact et les tests effectués. Il pourra contrôler les incidents, les limites appliquées et l’adresse du serveur de base.

Consulter les journaux et réparer les tables endommagées

Lorsque les accès semblent corrects, les journaux peuvent préciser la cause. Cherchez notamment les erreurs PHP, error_log, les journaux PHP-FPM et ceux de MySQL si votre hébergeur les met à disposition.

Le message Access denied oriente vers les identifiants ou les droits. Too many connections indique que la limite de connexions a été atteinte. Conservez le contexte et l’heure des erreurs afin de les rapprocher de la panne du site.

Activer temporairement le journal de débogage

Dans wp-config.php, vous pouvez activer le débogage et l’enregistrement des erreurs sans les afficher aux visiteurs. Vérifiez d’abord si ces constantes existent déjà : modifiez leurs valeurs plutôt que de les déclarer une seconde fois. Placez-les avant la ligne indiquant de ne plus modifier le fichier.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Consultez ensuite le fichier wp-content/debug.log, s’il a été créé. Il peut contenir des informations sensibles : ne le partagez pas publiquement. Une fois le diagnostic terminé, rétablissez les réglages précédents et sécurisez ou supprimez le journal selon vos besoins.

Réparer une base potentiellement corrompue

Une coupure, un disque saturé ou un problème matériel peut endommager des tables. Une corruption produit des symptômes proches d’une panne de connexion, mais une réparation de tables ne corrigera pas des identifiants erronés ni un serveur inaccessible.

Avant toute réparation, sauvegardez la base si possible. WordPress propose un outil intégré :

1. Ajoutez temporairement cette ligne dans wp-config.php, avant la ligne indiquant de ne plus modifier le fichier :

define( 'WP_ALLOW_REPAIR', true );

1. Ouvrez /wp-admin/maint/repair.php sur votre site.
2. Lancez la réparation proposée et consultez le résultat.
3. Retirez immédiatement la ligne ajoutée : la page de réparation est accessible sans connexion lorsqu’elle est activée.

Dans phpMyAdmin, vous pouvez aussi sélectionner les tables concernées et choisir Réparer la table, si le type de table et l’interface le permettent. Pour approfondir le diagnostic, consultez les étapes pour réparer une base WordPress corrompue.

Examiner les extensions, le thème et le préfixe des tables

Si la connexion au serveur fonctionne mais que le site tombe en panne sous charge, une extension ou un thème peut être à l’origine de requêtes trop nombreuses ou trop coûteuses. Une erreur fatale ou un délai d’attente peut également produire un symptôme voisin.

Testez de préférence sur un environnement de staging. Désactivez les extensions une par une, puis vérifiez le comportement du site après chaque changement. Testez aussi le thème si nécessaire. En production, intervenez seulement avec une sauvegarde et un moyen de revenir en arrière, par exemple un accès FTP ou SSH.

Une extension obsolète peut présenter des incompatibilités ou générer des requêtes inefficaces. Avant de la remplacer ou de la supprimer, vérifiez ses dépendances, sauvegardez le site, désactivez-la et observez le résultat. Le test d’une extension avant mise en production permet de préparer ces changements plus sereinement.

Vérifier le préfixe après une migration

Un préfixe incorrect ne provoque pas nécessairement le message de connexion à la base, mais peut empêcher WordPress de trouver ses tables après une migration ou une restauration.

Dans wp-config.php, comparez la variable $table_prefix aux noms visibles dans phpMyAdmin. Si les tables commencent par wpabc_ mais que le fichier indique wp_, vérifiez quelle base est la bonne, puis corrigez généralement le préfixe dans le fichier. Évitez de renommer les tables sans comprendre les conséquences et sans sauvegarde.

Traiter les causes récurrentes et prévenir les pannes

Une panne isolée peut correspondre à une maintenance ou à un redémarrage du serveur. Si elle revient, notamment lors de pics de trafic, recherchez plutôt une cause durable : ressources insuffisantes, requêtes lourdes, cache inadapté ou tâche planifiée trop coûteuse.

Selon le diagnostic, vous pouvez :

• Mettre en place un cache de pages ou un cache objet adapté à votre configuration.
• Examiner les extensions de statistiques, les recherches et les filtres qui sollicitent fortement la base.
• Vérifier les tâches WP-Cron et les automatisations externes.
• Nettoyer avec prudence les révisions, les transients et les tables laissées par des extensions, après sauvegarde.
• Adapter les ressources d’hébergement si les limites sont régulièrement atteintes.

Les erreurs de performance WordPress fréquentes donnent d’autres pistes pour identifier une surcharge. Si les vérifications ne permettent pas de rétablir le site, un dépannage WordPress peut prendre le relais, tandis que l’hébergeur contrôle les incidents et limites de son infrastructure.

Vérifier une éventuelle intrusion

Une base inaccessible peut aussi accompagner un incident de sécurité : mot de passe modifié, fichiers altérés ou requêtes malveillantes. Ce scénario mérite une attention particulière si vous constatez également des redirections inconnues, de nouveaux comptes administrateurs, des fichiers modifiés ou une alerte de l’hébergeur.

Dans ce cas, examinez les journaux et les comptes, contrôlez l’intégrité des fichiers et effectuez une analyse de sécurité. Changez les mots de passe FTP ou SSH, WordPress et de la base en mettant à jour la configuration correspondante.

Pour limiter les récidives, conservez des sauvegardes automatiques et testez leur restauration. Maintenez WordPress, les extensions et le thème à jour, surveillez la disponibilité du site et les ressources, et gardez une trace des changements effectués.

Questions fréquentes

Article rédigé avec l’aide d’une IA à partir des sources citées et de notre pratique de la maintenance WordPress. Notre méthode éditoriale.