Ton site tombe, tu vois ce message « Erreur lors de l’établissement d’une connexion avec la base de données » et ton back-office refuse de s’ouvrir. Ce n’est pas WordPress qui est mort : c’est le lien entre WordPress et MySQL qui a pété. Et bonne nouvelle, dans la majorité des cas, l’erreur de connexion à la base de données WordPress se répare en moins de 10 minutes, à la main, sans rien réinstaller.
Le piège, c’est de bricoler au hasard. Tu peux aggraver la panne et perdre l’accès admin pour de bon. Alors on va faire ça proprement, dans l’ordre.
Ce que WordPress essaie vraiment de te dire
WordPress ne stocke quasi rien en dur. Tes articles, tes utilisateurs, tes réglages WooCommerce, tout vit dans une base MySQL ou MariaDB. Le fichier wp-config.php contient les 4 coordonnées de la connexion : DB_NAME, DB_USER, DB_PASSWORD, DB_HOST.
Quand une seule de ces valeurs ne colle plus, ou quand MySQL est à l'arrêt, tu récoltes l’erreur de connexion à la base de données WordPress. WordPress n’est pas cassé. C’est le tuyau qui est bouché.
Les déclencheurs les plus fréquents : migration de serveur par l’hébergeur, changement de mot de passe MySQL depuis cPanel, un plugin qui a réécrit wp-config.php, ou un quota de connexions MySQL dépassé sur mutualisé.
Vérifie d’abord si MySQL est vivant
Avant de toucher au moindre fichier, connecte-toi à ton panneau d’hébergement (OVH, Hostinger, o2switch, Ionos, LWS). Cherche la section « Bases de données » et regarde le statut du service.
Si MySQL est indiqué arrêté ou en maintenance, tu n’as rien à faire côté WordPress : ouvre un ticket. Perdre une heure à éditer un fichier alors que la panne est chez eux, c’est le classique du dimanche soir.
Deuxième réflexe : lance phpMyAdmin avec les identifiants de ton wp-config.php. S’il refuse de s’ouvrir, la panne est côté serveur ou identifiants, pas côté WordPress. Cette seule distinction te fait gagner des heures.
wp-config.php : le fichier où 80 % des cas se règlent
Ouvre wp-config.php à la racine de ton install (FTP ou gestionnaire de fichiers) et compare ligne par ligne avec ce que l’hébergeur t’a filé.
- DB_NAME : le nom exact de la base, majuscules et tirets compris.
- DB_USER : beaucoup d’hébergeurs préfixent avec ton identifiant de compte (ex : monsite_user).
- DB_PASSWORD : un espace en trop et tout casse. Attention aux guillemets droits vs courbes.
- DB_HOST : souvent localhost, mais certains imposent une IP ou un hostname spécifique.
Détail que personne ne mentionne : si ton mot de passe contient ‘ ou $, PHP peut mal interpréter la chaîne. Dans le doute, régénère un mot de passe MySQL simple (sans caractères spéciaux) et mets-le à jour dans wp-config.php. C’est cinq minutes et ça élimine une cause sournoise d’erreur de connexion à la base de données WordPress.
La méthode qui répare sans rien casser
Si tu n’arrives pas à identifier la cause, voici la manœuvre que j’utilise systématiquement, même quand j’ai perdu la trace des identifiants.
- Renomme wp-config.php en wp-config-sauvegarde.php.
- Recharge ton site : WordPress détecte l’absence de config et lance son installateur.
- Renseigne les identifiants MySQL fournis par l’hébergeur.
- WordPress génère un wp-config.php propre avec les bonnes valeurs.
Piège classique : ne va pas jusqu’au bout en recréant des tables. WordPress reconnaîtra ta base existante tant que le préfixe de tables est identique. Si tu vois « la table existe déjà », tu es sur la bonne voie. Ne supprime rien.
Quand le problème vient du quota ou du préfixe
Cas que les tutos oublient : ton mutualisé peut avoir atteint sa limite de connexions simultanées MySQL. Résultat, l’erreur de connexion à la base de données WordPress apparaît par pics, pas en permanence. Si c’est intermittent, c’est très probablement ça.
Autre piste : un plugin de cache ou de sécurité qui ouvre trop de connexions. Désactive-les temporairement en renommant leur dossier dans /wp-content/plugins/.
Et il y a le cas du préfixe. Si tu as migré un site et que l’ancien préfixe était wp_ alors que le nouveau est wp8x_, WordPress cherche des tables qui n’existent pas et lève l’erreur. Vérifie la ligne $table_prefix dans wp-config.php.
Ce qu’il faut arrêter de faire en 2026
Supprimer la base et repartir de zéro est la pire décision possible. Tu perds articles, commentaires, commandes WooCommerce, comptes clients. Idem pour une réinstallation complète de WordPress depuis le panneau hébergeur : elle écrase souvent les fichiers sans prévenir.
Sauvegarde d’abord, toujours. Un export de la base via phpMyAdmin, un ZIP du dossier /wp-content/, et tu peux expérimenter sans stress.
Un dernier point que peu osent dire : si ton mutualisé à 2 € par mois plante régulièrement sur la base de données, ce n’est pas WordPress le fautif, c’est l’hébergement. Un serveur sérieux avec des ressources dédiées à MySQL règle le problème définitivement, là où dix correctifs temporaires ne font que repousser l’échéance.
Le vrai diagnostic en 3 minutes
Tu veux trancher vite ? Ouvre php
