Le message « Erreur lors de la connexion à la base de données » signifie que WordPress n’arrive pas à joindre MySQL ou MariaDB. Quatre causes dominent : des identifiants erronés dans wp-config.php, un serveur de base arrêté ou saturé, des tables corrompues, ou un quota d’hébergement dépassé. Chacune se vérifie dans l’ordre, sans rien réinstaller.
Le site n’affiche plus que cette phrase, en français ou en anglais (« Error establishing a database connection »), parfois seulement dans l’administration. WordPress stocke tous ses contenus dans la base : sans connexion, aucune page ne peut être construite. Le déclencheur est souvent un changement récent : migration, changement de mot de passe de la base, redémarrage du serveur, pic de visites ou espace disque épuisé.
Si vous visitez le site, vous ne pouvez rien corriger : réessayez plus tard et prévenez l’éditeur. Si c’est votre site, les étapes ci-dessous vont du plus simple au plus technique. Elles demandent un accès aux fichiers du site et, pour certaines, à l’hébergement ou au serveur.
Vérifier si l’erreur touche le site public et l’administration
Si c’est votre site. Ouvrez la page d’accueil puis /wp-admin/. Si l’administration affiche un message différent, du type « One or more database tables are unavailable », ce sont des tables abîmées : passez directement à la réparation. Si les deux affichent la même erreur, la connexion elle-même est en cause. Testez aussi un autre site hébergé sur le même compte : s’il est tombé aussi, le serveur de base est arrêté ou saturé, et les identifiants ne sont pas en cause.
Contrôler les identifiants dans wp-config.php
Si c’est votre site. Téléchargez wp-config.php depuis la racine du site et relevez quatre constantes :
DB_NAME: le nom de la base ;DB_USER: l’utilisateur de la base ;DB_PASSWORD: son mot de passe ;DB_HOST: l’adresse du serveur de base, souventlocalhost, parfois un nom fourni par l’hébergeur.
Comparez-les avec ce qu’affiche l’espace client de l’hébergeur, section bases de données. Une faute de frappe, un mot de passe changé côté hébergeur ou une migration vers un autre serveur suffisent à tout bloquer. Dans phpMyAdmin, un utilisateur qui se connecte avec ces mêmes valeurs confirme qu’elles sont bonnes. Faites une copie de wp-config.php avant de le modifier.
Tester la connexion à la base indépendamment de WordPress
Si c’est votre site. Depuis un accès SSH, la commande mysql -u NOM_UTILISATEUR -p -h HÔTE NOM_BASE indique si le couple utilisateur et mot de passe est accepté. Un refus d’accès signale un mot de passe ou des droits incorrects. Un message « Can’t connect » ou « Connection refused » signale que le serveur de base ne répond pas. Sans SSH, essayez de vous connecter à phpMyAdmin avec les mêmes identifiants.
Vérifier que MySQL ou MariaDB tourne
Si vous administrez le serveur. Lancez systemctl status mariadb (ou systemctl status mysql selon l’installation). Si le service est arrêté, journalctl -u mariadb -n 50 indique pourquoi. Deux raisons reviennent : le processus a été tué faute de mémoire (cherchez « Out of memory » avec dmesg | grep -i oom) ou le disque est plein, ce que montre df -h. Libérez de la place ou de la mémoire avant de relancer avec systemctl restart mariadb. Si le service ne démarre pas du tout, le guide sur MySQL qui ne démarre pas détaille ce cas.
Si vous êtes sur un hébergement mutualisé. Vous n’avez pas accès au service : consultez la page d’état de l’hébergeur, puis ouvrez un ticket en précisant l’heure du début de l’erreur.
Réparer les tables corrompues
Si c’est votre site. Faites d’abord une sauvegarde de la base depuis phpMyAdmin. Ajoutez ensuite dans wp-config.php, avant la ligne « That’s all, stop editing », la ligne define( 'WP_ALLOW_REPAIR', true );. Ouvrez alors /wp-admin/maint/repair.php et choisissez « Réparer la base de données ». Cette page est accessible sans connexion tant que la constante est présente : retirez la ligne dès la fin de l’opération. Si la réparation échoue, la même fonction existe dans phpMyAdmin (sélectionner les tables, puis « Réparer la table »).
Vérifier le quota et la saturation de l’hébergement
Si c’est votre site. Certains hébergeurs coupent l’accès à la base quand l’espace disque, le nombre de connexions simultanées ou le quota de requêtes est dépassé. Cherchez dans l’espace client un avertissement de quota, et regardez si l’erreur apparaît surtout lors des pics de visites. Un trafic anormal ou un robot qui martèle le site peut saturer les connexions : ajoutez un cache de pages, puis consultez les journaux d’accès pour repérer l’origine du pic.
Rétablir une base saine si rien ne répond
Si c’est votre site. Si la base a disparu ou reste illisible, restaurez la dernière sauvegarde depuis phpMyAdmin (onglet Importer) ou depuis l’outil de l’hébergeur. Importez-la dans une base vide, puis vérifiez que DB_NAME pointe bien dessus. Les contenus publiés après la sauvegarde devront être recréés. Une fois le site revenu, notez la cause trouvée et vérifiez que des sauvegardes automatiques existent, par exemple avec le guide sur la sauvegarde en entreprise.
Questions fréquentes
Pourquoi mon site WordPress affiche « Error establishing a database connection » ?
WordPress ne parvient pas à ouvrir la base de données. Soit les identifiants de wp-config.php ne correspondent plus à ceux de la base, soit MySQL ou MariaDB est arrêté ou saturé, soit des tables sont corrompues. Commencez par comparer les quatre constantes DB_ avec l’espace client de l’hébergeur.
Comment retrouver les identifiants de la base de données ?
Ouvrez wp-config.php à la racine du site : DB_NAME, DB_USER, DB_PASSWORD et DB_HOST y figurent. Si le mot de passe a été changé côté hébergeur, définissez-en un nouveau dans la gestion des bases de l’hébergeur, puis reportez-le dans le fichier. Ne l’envoyez jamais par e-mail.
L’erreur apparaît seulement de temps en temps, d’où cela vient-il ?
Une erreur intermittente indique presque toujours une saturation : trop de connexions simultanées, mémoire insuffisante côté serveur ou quota de l’hébergeur atteint pendant un pic. Les journaux de MariaDB et ceux de l’hébergeur datent les coupures. Un cache de pages et la suppression des extensions gourmandes réduisent le nombre de requêtes.
Faut-il laisser WP_ALLOW_REPAIR dans wp-config.php ?
Non. Tant que cette ligne est présente, la page de réparation répond à n’importe quel visiteur, sans connexion. Retirez-la dès que la réparation est terminée. Elle ne sert qu’à une opération ponctuelle et ne doit jamais rester dans un fichier de production.
Peut-on réparer cette erreur à distance sans connaître les identifiants ?
Oui. Nous vous indiquons l’accès nécessaire, par exemple à wp-config.php ou à l’espace client de l’hébergeur, et nous vous guidons pour nous le donner, par téléphone si besoin. Nous examinons d’abord, sans rien modifier, puis vous recevez un devis gratuit. Si le serveur de base lui-même est géré par l’hébergeur et reste en panne, seul celui-ci peut le relancer.
Sources
- Common WordPress Errors — WordPress.org
- Editing wp-config.php — developer.wordpress.org
- Error Codes — MariaDB Documentation