« Erreur lors de la connexion à la base de données » sur WordPress : causes et solutions

« Erreur lors de la connexion à la base de données » signifie que WordPress n’arrive pas à se connecter au serveur MySQL ou MariaDB qui stocke vos contenus. Les causes les plus fréquentes sont des identifiants incorrects dans le fichier wp-config.php, un serveur de base de données arrêté ou saturé, une base endommagée ou une limite imposée par l’hébergeur. Pour la corriger : vérifiez les quatre paramètres de connexion dans wp-config.php, testez-les indépendamment de WordPress, puis vérifiez l’état du serveur de base de données avec votre hébergeur.

C’est une erreur impressionnante, parce qu’elle remplace tout le site par une seule ligne de texte. Bonne nouvelle : dans la plupart des cas, vos contenus ne sont pas perdus, WordPress ne parvient simplement plus à les atteindre. Voici comment trouver la cause, dans l’ordre le plus efficace.

• Pourquoi WordPress a-t-il besoin de la base de données ?
• Quelles sont les causes possibles ?
• Étape 1 : vérifier wp-config.php
• Étape 2 : tester les identifiants hors de WordPress
• Étape 3 : vérifier que le serveur MySQL ou MariaDB fonctionne
• Étape 4 : réparer une base endommagée
• Étape 5 : trop de connexions ou limite de l’hébergeur
• Les erreurs à éviter
• Questions fréquentes
• Sources

Pourquoi WordPress a-t-il besoin de la base de données ?

WordPress sépare deux choses : les fichiers (le code de WordPress, le thème, les extensions, les images) et la base de données, qui contient les pages, les articles, les réglages, les utilisateurs, les commandes. À chaque affichage de page, WordPress se connecte à la base avec quatre informations écrites dans wp-config.php. Si cette connexion échoue, il ne peut rien afficher et s’arrête sur ce message.

La documentation officielle de WordPress résume la démarche en trois pistes : vérifier les informations de wp-config.php, contacter l’hébergeur pour savoir si le serveur de base de données est en panne ou si la base a dépassé son quota, et s’assurer que le site n’a pas été compromis.

Quelles sont les causes possibles ?

Cause	Contexte typique	Qui peut agir
Identifiants erronés dans wp-config.php	Migration, changement d’hébergeur, mot de passe de base modifié	Vous (FTP)
Mauvais hôte de base de données (DB_HOST)	Hébergeur qui n’utilise pas localhost, migration	Vous, avec l’information de l’hébergeur
Serveur MySQL ou MariaDB arrêté	Panne, manque de mémoire, redémarrage du serveur	Hébergeur ou administrateur du serveur
Base de données endommagée	Arrêt brutal du serveur, disque plein	Vous ou l’administrateur
Trop de connexions simultanées	Pic de trafic, robots, requêtes lentes	Administrateur, optimisation du site
Quota ou suspension de l’hébergeur	Base trop volumineuse, abus de ressources	Hébergeur
Site compromis	wp-config.php modifié par un tiers	Procédure de sécurité

Premier réflexe : l’erreur est-elle apparue juste après une action (migration, changement de mot de passe, changement d’offre) ou sans raison apparente ? Dans le premier cas, regardez d’abord wp-config.php. Dans le second, le serveur de base de données est le premier suspect.

Étape 1 : vérifier wp-config.php

Connectez-vous en FTP ou SFTP, ou via le gestionnaire de fichiers de l’hébergeur, et téléchargez wp-config.php (à la racine du site) pour en garder une copie. Ouvrez-le avec un éditeur de texte brut et repérez ces lignes :

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

Comparez chaque valeur avec ce qu’affiche l’espace client de votre hébergeur, rubrique bases de données :

• DB_NAME : le nom exact de la base. Beaucoup d’hébergeurs ajoutent un préfixe (identifiant du compte suivi d’un tiret bas).
• DB_USER : l’utilisateur MySQL, qui n’a rien à voir avec votre identifiant WordPress.
• DB_PASSWORD : attention aux caractères spéciaux. Une apostrophe dans le mot de passe casse la ligne si elle n’est pas échappée.
• DB_HOST : souvent localhost, mais pas toujours. Certains hébergeurs fournissent une adresse dédiée. La documentation WordPress précise que si un port ou un socket est nécessaire, on l’ajoute après deux-points, par exemple localhost:3307.

Vérifiez aussi que le fichier n’a pas été modifié récemment sans raison. Un wp-config.php altéré par un tiers est un indice de piratage : dans ce cas, traitez la situation comme un piratage : isolez le site, changez tous les accès et vérifiez les comptes administrateurs avant toute autre action.

Si vous avez un doute sur le mot de passe, le plus simple est d’en définir un nouveau pour l’utilisateur MySQL dans l’espace client de l’hébergeur, puis de le reporter dans wp-config.php.

Étape 2 : tester les identifiants hors de WordPress

Pour savoir si le problème vient des identifiants ou du serveur, testez la connexion sans passer par WordPress. Deux possibilités :

1. phpMyAdmin (ou Adminer), fourni par la plupart des hébergeurs : connectez-vous avec l’utilisateur et le mot de passe de wp-config.php. Si la connexion échoue, les identifiants sont faux ou l’utilisateur n’a pas de droits sur la base.
2. En ligne de commande, si vous avez un accès SSH :

mysql -h localhost -u utilisateur_de_la_base -p nom_de_la_base

Le message obtenu oriente la suite :

Résultat	Signification	Suite
Connexion réussie	Identifiants bons, serveur actif	Revérifier la syntaxe de wp-config.php, puis l’état des tables (étape 4)
Access denied for user	Utilisateur ou mot de passe incorrect, ou droits manquants	Réinitialiser le mot de passe, vérifier l’association utilisateur et base
Unknown database	Le nom de la base est faux ou la base n’existe plus	Corriger DB_NAME ou restaurer la base
Can't connect to ... server	Serveur injoignable ou arrêté	Étape 3
Too many connections	Serveur saturé	Étape 5

Étape 3 : vérifier que le serveur MySQL ou MariaDB fonctionne

Si les identifiants sont bons mais que la connexion échoue, le serveur de base de données est peut-être arrêté. Sur un hébergement mutualisé, vous ne pouvez rien faire vous-même : consultez la page d’état de l’hébergeur et ouvrez un ticket. Si d’autres sites du même hébergement affichent la même erreur, c’est une panne générale.

Sur un serveur dédié ou un VPS que vous administrez (Debian ou Ubuntu par exemple), vérifiez le service et son journal :

# État du service (le nom peut être mariadb ou mysql)
sudo systemctl status mariadb

# Dernières lignes du journal du service
sudo journalctl -u mariadb -n 100

# Espace disque disponible
df -h

Un serveur de base de données s’arrête souvent pour deux raisons : le manque de mémoire (le système arrête le processus le plus gourmand, souvent MySQL) et le disque plein. Redémarrer le service remet le site en ligne, mais sans traiter la cause, la panne reviendra. Si le disque est plein, libérez de l’espace (journaux, anciennes sauvegardes stockées sur le serveur) avant de redémarrer.

WordPress recommande aujourd’hui MySQL 8.0 ou plus récent, ou MariaDB 10.11 ou plus récent. Si votre serveur utilise une version beaucoup plus ancienne, c’est le moment de planifier une mise à jour.

Étape 4 : réparer une base endommagée

Après un arrêt brutal du serveur, certaines tables peuvent être endommagées. Le site s’affiche alors partiellement, ou l’administration signale des tables indisponibles. WordPress intègre un outil de réparation, désactivé par défaut. Ajoutez cette ligne dans wp-config.php :

define( 'WP_ALLOW_REPAIR', true );

Rendez-vous ensuite sur https://votre-site.fr/wp-admin/maint/repair.php et lancez la réparation. Retirez la ligne dès que c’est terminé : la documentation WordPress rappelle que cette page est accessible sans être connecté, donc par n’importe qui tant que la constante est active.

Avec WP-CLI, deux commandes font le même travail en s’appuyant sur l’outil mysqlcheck de MySQL et sur les identifiants de wp-config.php :

# Vérifier les tables
wp db check

# Réparer les tables
wp db repair

Avant toute réparation, exportez la base (phpMyAdmin ou wp db export) si c’est encore possible. Si la réparation échoue, la restauration d’une sauvegarde récente de la base est la solution la plus sûre.

Étape 5 : trop de connexions ou limite de l’hébergeur

Si l’erreur apparaît par intermittence, surtout aux heures de forte affluence, le serveur refuse probablement de nouvelles connexions. MySQL renvoie alors l’erreur « Too many connections » : toutes les connexions autorisées par la variable max_connections sont occupées. La documentation MySQL précise qu’une connexion supplémentaire est réservée aux comptes d’administration, pour pouvoir diagnostiquer avec SHOW PROCESSLIST.

Augmenter max_connections est possible sur un serveur que vous administrez, mais la vraie question est : pourquoi les connexions restent-elles ouvertes aussi longtemps ? Les causes habituelles sont des requêtes lentes (extension mal optimisée, table d’options surchargée), l’absence de cache de pages qui oblige chaque visite à interroger la base, ou un afflux de robots.

Sur un hébergement mutualisé, le nombre de connexions et la taille de la base sont plafonnés par l’offre. Si vous atteignez régulièrement ces plafonds, votre site a dépassé son hébergement. Nous comparons les offres dans notre article sur les meilleurs hébergeurs web, et détaillons les coûts dans le prix réel d’un hébergement professionnel.

Les erreurs à éviter

• Réinstaller WordPress. Les contenus sont dans la base, pas dans les fichiers. Une réinstallation ne règle rien et peut compliquer la suite.
• Modifier wp-config.php sans copie. Une apostrophe ou un point-virgule manquant crée une nouvelle erreur.
• Oublier WP_ALLOW_REPAIR. Laisser l’outil de réparation ouvert au public est une faille inutile.
• Redémarrer sans chercher. Un serveur de base qui s’arrête a une raison : mémoire, disque, requêtes. Elle reviendra.
• Compter uniquement sur les sauvegardes de l’hébergeur. Gardez aussi une copie de la base hors du serveur, et vérifiez qu’elle se restaure.

Une base de données qui tombe est rarement un accident isolé : c’est souvent le signe d’un hébergement trop juste ou d’un site qui a grossi sans optimisation. Notre offre d’hébergement et maintenance WordPress inclut la surveillance, les sauvegardes et l’intervention en cas de panne, avec un budget qui dépend de votre site (voir nos tarifs indicatifs). Pour un site lent ou une base à optimiser, notre agence WordPress peut auditer les extensions et les requêtes. Et pour les bases de l’entretien courant, voyez notre article sur la maintenance des sites WordPress.

Questions fréquentes

Ai-je perdu mes articles et mes pages ?

Très probablement pas. Dans la grande majorité des cas, la base est intacte et seule la connexion échoue. La perte de données ne concerne que les bases réellement endommagées ou supprimées, d’où l’importance des sauvegardes.

Le site fonctionne mais pas l’administration, est-ce la même erreur ?

Si le site public s’affiche grâce à un cache et que l’administration montre l’erreur, oui : le cache masque la panne pour les visiteurs. La démarche est la même.

L’erreur est apparue après une migration, que vérifier en premier ?

DB_HOST et le nom de la base : ce sont les valeurs qui changent le plus souvent d’un hébergeur à l’autre. Vérifiez aussi que la base a bien été importée sur le nouveau serveur.

L’erreur apparaît puis disparaît, pourquoi ?

C’est le profil typique d’un serveur saturé (trop de connexions) ou d’un serveur de base qui redémarre après avoir manqué de mémoire. Les journaux du serveur et l’heure des incidents permettent de trancher.

Cette erreur affecte-t-elle mon référencement ?

Tant qu’elle dure, les robots reçoivent une erreur serveur. Google ralentit alors l’exploration et, si l’erreur persiste, finit par retirer les pages de l’index. Une panne de quelques heures a peu d’effet durable.

Sources

• WordPress Advanced Administration Handbook : Common WordPress errors
• WordPress : How to install WordPress (paramètres DB_NAME, DB_USER, DB_PASSWORD, DB_HOST)
• Editing wp-config.php (WP_ALLOW_REPAIR)
• WP-CLI : wp db repair
• WP-CLI : wp db check
• MySQL 8.4 Reference Manual : Too many connections
• WordPress.org : configuration requise
• Google : effet des codes HTTP et des erreurs serveur sur l’exploration