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

Vous tapez l’adresse de votre site et il ne reste qu’un écran presque vide avec une phrase en anglais : « Error establishing a database connection ». Plus de site, plus d’administration, rien. Cette erreur de connexion à la base de données WordPress fait peur, parce qu’on imagine tout de suite que les contenus ont disparu.

Dans l’immense majorité des cas, ils sont là. WordPress a simplement perdu le chemin vers sa base. J’ai remis plusieurs sites en ligne après ce message, et la méthode ne change pas : on regarde, on sauvegarde, puis on teste les causes de la plus probable à la moins probable.

Que signifie « Error establishing a database connection » sur un site WordPress ?

La réponse courte : WordPress n’a pas réussi à ouvrir une connexion vers sa base de données. Cette base, MySQL ou MariaDB selon l’hébergeur, contient vos articles, vos pages, vos réglages et, si vous avez WooCommerce, vos commandes. Les fichiers du site (thème, plugins, images) sont rangés ailleurs, sur le disque du serveur. Sans la base, WordPress ne sait plus rien afficher. Il s’arrête et écrit ce message.

En français, le texte devient « Erreur lors de l’établissement d’une connexion à la base de données ». C’est la même panne. Le serveur renvoie en général un code HTTP 500, ce qui explique que les outils de supervision la rangent parmi les erreurs serveur.

Le point rassurant : ce message ne dit rien de l’état de vos contenus. Il dit seulement que la porte est fermée.

C’est d’ailleurs pour ça que la page est si pauvre. WordPress ne peut même pas charger votre thème ou vos réglages, puisque les réglages, eux aussi, vivent dans la base. Il affiche donc un texte brut, sans le design de votre site, et c’est normal.

Je précise tout de suite un détail qui sert au diagnostic. L’erreur peut s’afficher sur le site public seulement, ou aussi dans l’administration. Parfois l’administration affiche un autre message, qui parle de tables indisponibles. Ces deux cas n’ont pas la même cause, et je reviens dessus plus bas.

Pourquoi cette erreur de connexion à la base de données WordPress apparaît-elle ?

Pour que WordPress parle à sa base, quatre choses doivent être vraies en même temps : le serveur de base tourne, WordPress connaît son adresse, il possède le bon couple utilisateur et mot de passe, et les tables existent. Dès qu’un seul de ces points casse, vous obtenez l’erreur. Je les classe ici selon ce que j’observe le plus souvent sur des sites de TPE.

• Des identifiants ou un hôte faux dans wp-config.php (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST) : la cause la plus fréquente, surtout après une migration, un changement d’hébergeur ou un nouveau mot de passe de base.
• Un serveur de base arrêté, saturé, ou un quota dépassé chez l’hébergeur.
• Des tables abîmées ou introuvables, après un arrêt brutal du serveur ou avec un préfixe de tables qui ne correspond plus.
• Un fichier wp-config.php écrasé par une restauration partielle ou abîmé par une modification à la main.

Concrètement, la question à se poser avant tout est simple : qu’est-ce qui a changé juste avant la panne ? Une migration de la veille, un mot de passe modifié dans l’espace client, une restauration de sauvegarde, un hébergeur qui a annoncé une maintenance. Dans mon expérience, il y a presque toujours un événement déclencheur, et le propriétaire du site l’a oublié ou ne le relie pas à la panne.

Avant de chercher la cause technique, cherchez le dernier changement : migration, restauration, mot de passe, quota.

Si rien n’a bougé de votre côté, regardez du côté de l’hébergeur. Une base qui tombe seule, sans action de votre part, est plus souvent un problème de serveur qu’un problème de WordPress.

Comment diagnostiquer l’erreur avant de toucher à quoi que ce soit ?

Étape 1 : je fais une copie de wp-config.php et, si la base répond encore dans phpMyAdmin, un export complet. Ça prend quelques minutes et ça évite d’aggraver la situation avec une fausse manipulation. Ensuite seulement, je teste dans cet ordre.

1. J’ouvre l’adresse /wp-admin de mon site. Si l’administration affiche un message qui dit qu’une ou plusieurs tables de la base de données sont indisponibles (« One or more database tables are unavailable » en anglais), la connexion fonctionne et ce sont les tables qui sont abîmées : direction la réparation.
2. Si l’administration affiche la même erreur que le site, je regarde l’espace client de l’hébergeur : état des bases de données, incident en cours, quota atteint.
3. Je tente de me connecter à phpMyAdmin avec l’utilisateur et le mot de passe inscrits dans wp-config.php. Si la connexion échoue, le problème vient des identifiants ou du serveur, pas de WordPress.
4. Je consulte le journal d’erreurs PHP de l’hébergeur, quand il existe : c’est là qu’apparaît souvent le numéro d’erreur MySQL, qui donne la cause exacte.

Ces quatre vérifications ne modifient rien sur le site. Elles suffisent à classer la panne dans l’une des familles vues plus haut. Le plus important, c’est de ne pas lancer cinq actions à la fois : si le site revient, vous ne saurez pas laquelle a fonctionné, et si ça empire, vous ne saurez pas laquelle a cassé quelque chose.

Que disent les codes MySQL 1045, 1049 et 2002 ?

Ces numéros apparaissent surtout dans le journal d’erreurs de l’hébergeur ou dans phpMyAdmin, plus rarement à l’écran. Ils valent de l’or, parce qu’un numéro désigne une cause précise là où le message WordPress reste le même pour toutes les pannes. Voici ceux que je croise le plus.

Si votre journal affiche le 1045, l’erreur est presque gagnée : le serveur répond, il refuse simplement votre couple utilisateur et mot de passe. Pour le 1049, c’est le nom de la base qui ne colle pas, par exemple parce que l’hébergeur en a créé une nouvelle lors d’une migration.

Que faire si le serveur MySQL de l’hébergeur est arrêté ou saturé ?

Premier indice : l’erreur n’est pas permanente. Elle apparaît quelques minutes, disparaît en rechargeant la page, revient aux heures de forte fréquentation. Ce comportement prouve que vos identifiants sont bons, sinon la connexion ne marcherait jamais. Le serveur de base est surchargé ou redémarre, ou bien votre offre a un quota de connexions ou de taille qui est atteint.

Je ne touche à rien dans ce cas. Je note l’heure des coupures, je vérifie le statut des services dans l’espace client, puis j’écris au support de l’hébergeur avec ces horaires. Si les coupures sont régulières, c’est le signe qu’il faut alléger le site (extensions lourdes, requêtes mal faites) ou changer d’offre d’hébergement.

Comment corriger les identifiants et l’hôte dans wp-config.php ?

Le fichier wp-config.php se trouve à la racine du site, parfois un dossier au-dessus. Je l’ouvre en SFTP ou avec le gestionnaire de fichiers de l’hébergeur, après en avoir gardé une copie. Quatre lignes décident de tout :

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

Ces valeurs doivent être identiques à celles de l’espace client de l’hébergeur, rubrique bases de données. Le nom de la base et l’utilisateur sont parfois très différents de ce qu’on imagine, avec un préfixe imposé par l’hébergeur. L’erreur la plus courante est de recopier un ancien mot de passe ou de coller une valeur avec un espace en trop.

DB_HOST mérite une attention particulière. Beaucoup d’hébergeurs acceptent « localhost », mais chez d’autres, dont OVH en mutualisé, la base est sur un serveur distinct et l’adresse à utiliser est indiquée dans l’espace client. Avec Docker, c’est le nom du service de la base dans le fichier de configuration des conteneurs, pas « localhost ».

Deux pièges techniques. Une apostrophe dans le mot de passe doit être précédée d’un antislash, sinon la ligne PHP est cassée. Et si vous avez copié les lignes depuis un traitement de texte ou un e-mail, les guillemets courbes à la place des guillemets droits rendent le fichier illisible pour PHP.

Si l’erreur est apparue juste après un déménagement de site, relisez ma méthode pour migrer un site WordPress chez un nouvel hébergeur sans coupure : oublier de mettre à jour les identifiants de la nouvelle base est le piège classique.

Comment réparer la base de données avec WP_ALLOW_REPAIR ?

Quand la connexion marche mais que des tables sont abîmées, WordPress embarque un outil de réparation, désactivé par défaut. Il s’active avec une ligne de configuration, et la documentation officielle sur le fichier wp-config.php précise qu’il ne doit rester allumé que le temps du besoin. Voici ma procédure.

1. Sauvegarder la base depuis l’hébergeur ou phpMyAdmin.
2. Ajouter dans wp-config.php, au-dessus de la ligne qui dit d’arrêter les modifications, la ligne de réparation ci-dessous.
3. Ouvrir l’adresse /wp-admin/maint/repair.php de votre site et lancer la réparation.
4. Supprimer la ligne ajoutée dès que c’est terminé, puis recharger le site.

define( 'WP_ALLOW_REPAIR', true );

phpMyAdmin ou repair.php : quelle méthode choisir ?

La page repair.php est la voie la plus simple : pas de SQL, un bouton, et le résultat s’affiche table par table. Je commence presque toujours par elle. phpMyAdmin sert quand j’ai besoin de voir quelles tables posent problème, de les exporter une à une, ou quand l’administration de WordPress est trop abîmée pour s’ouvrir.

Un plugin de réparation ne sert à rien ici : sans connexion à la base, WordPress ne charge même pas ses extensions. Et la réparation ne fonctionne pas sur toutes les tables, notamment celles en InnoDB. Si elle échoue, la bonne réponse est de restaurer la dernière sauvegarde saine. Ce jour-là, vous serez content d’avoir mis en place une sauvegarde WordPress automatisée et testée.

Quand faut-il demander de l’aide pour une erreur de base de données ?

Il y a des cas où j’arrête d’essayer seul, et je conseille la même chose à mes clients. Vous n’avez pas accès à l’espace client de l’hébergeur, donc impossible de lire les identifiants. La base a été supprimée ou vidée. La réparation échoue et vous n’avez aucune sauvegarde récente. Le site réapparaît mais il manque des commandes ou des articles. Ou bien l’erreur est arrivée sans changement de votre part et vous craignez un piratage.

Sur une boutique WooCommerce, je ne remets jamais le site en vente sans avoir comparé la dernière commande visible avec celle de vos e-mails de notification : une restauration peut faire perdre des commandes passées entre la sauvegarde et la panne.

Si vous êtes dans l’un de ces cas, je peux regarder le contexte de votre site, identifier la cause probable et remettre les choses d’aplomb avec une sauvegarde de sécurité avant toute intervention. Plus on me contacte tôt, moins il y a de risque de perte.

Un conseil de terrain : ne lancez pas de réinstallation de WordPress pour « repartir propre ». C’est la manœuvre qui transforme une panne réparable en perte de données, et je la vois tenter par des gens pressés qui pensent bien faire.

Prenez le temps d’un coup de fil à l’hébergeur d’abord. Il voit côté serveur ce que vous ne voyez pas.

Comment éviter que l’erreur de connexion à la base de données revienne ?

En pratique, trois habitudes suffisent. D’abord, une sauvegarde automatique de la base et des fichiers, dont vous avez déjà testé la restauration une fois. Ensuite, noter les identifiants de la base dans un gestionnaire de mots de passe : le jour de la panne, personne ne retrouve ce mot de passe créé il y a trois ans.

Troisième habitude : ne jamais changer le mot de passe de la base chez l’hébergeur sans mettre à jour wp-config.php dans la foulée, au même moment. Je l’ai vu plus d’une fois, avec une panne qui arrive deux jours plus tard à cause d’un cache. Une vérification mensuelle de la maintenance WordPress aide aussi à repérer un disque presque plein ou un quota qui approche.

Avant un changement de version de PHP ou une migration chez un nouvel hébergeur, je teste d’abord sur une copie. Et le réflexe qui vaut toutes les règles : un message d’erreur, une capture d’écran, la date et l’heure, avant de toucher quoi que ce soit.

Questions fréquentes