Erreur de connexion à la base de données WordPress

Le problème : ton site n’affiche qu’une phrase

Ce matin, sur un site WordPress hébergé chez un mutualisé classique, l’écran affichait juste : “Erreur d’établissement d’une connexion à la base de données”. Pas de menu, pas d’article, rien. Juste cette phrase, blanche sur fond blanc, qui fait froid dans le dos quand c’est le site de ta boîte.

Bonne nouvelle tout de suite : dans l’immense majorité des cas, le contenu n’est pas perdu. WordPress fonctionne avec deux briques séparées : les fichiers (thème, plugins, médias) d’un côté, la base de données MySQL (ou MariaDB) de l’autre, qui stocke tes articles, pages et réglages. Ce message veut juste dire que WordPress n’arrive plus à parler à cette base — pas qu’elle a disparu.

Ça peut venir d’identifiants mal renseignés, d’une base corrompue, d’un serveur MySQL simplement à l’arrêt, ou d’un souci de préfixe de tables. On va vérifier chaque piste dans l’ordre, du plus rapide au plus technique.

Pourquoi ça arrive

Voici les causes les plus fréquentes, par ordre de probabilité :

• Identifiants incorrects dans wp-config.php : nom de base, utilisateur, mot de passe ou hôte qui ne correspondent plus à la réalité (souvent après une migration ou un changement d’hébergeur).
• Serveur MySQL/MariaDB à l’arrêt : le service de base de données a planté ou a été redémarré côté serveur, souvent après une mise à jour système ou une surcharge de ressources.
• Base de données corrompue : une ou plusieurs tables endommagées suite à une coupure brutale, un disque plein, ou une opération d’écriture interrompue.
• Préfixe de tables incohérent : le préfixe déclaré dans wp-config.php (ex. wp_) ne correspond pas à celui réellement utilisé dans la base (ex. wp3x7z_), souvent après une migration mal faite.
• Trop de connexions simultanées : l’hébergeur limite le nombre de connexions MySQL, et un pic de trafic ou un plugin gourmand sature ce quota.
• Quota d’hébergement dépassé : certains mutualisés bloquent l’accès à la base une fois l’espace disque ou le quota de requêtes atteint.

Chacune de ces causes se vérifie en quelques minutes. Pas besoin d’être développeur pour les trois premières étapes ci-dessous.

1. Vérifier wp-config.php (le premier réflexe)

C’est le fichier qui contient les clés d’accès à ta base. Il se trouve à la racine de ton installation WordPress, accessible via FTP ou le gestionnaire de fichiers de ton hébergeur.

Ouvre-le et repère ces quatre lignes :

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

Compare-les avec les informations réelles fournies par ton hébergeur (dans phpMyAdmin ou le panel d’administration). Une erreur de frappe, un mot de passe changé récemment, ou un DB_HOST qui n’est plus localhost (certains hébergeurs utilisent une adresse IP ou un nom spécifique) suffisent à casser la connexion.

Si tu viens de changer d’hébergeur, ce point mérite une attention particulière — c’est justement le genre de détail qui casse tout lors d’une migration mal préparée, comme on l’explique dans ce guide sur le changement d’hébergeur sans perdre son référencement.

Astuce : si tu ne connais plus le mot de passe de la base, tu peux le réinitialiser directement depuis le panel d’administration (cPanel, Plesk, hPanel) sans perdre aucune donnée. Il suffit ensuite de reporter le nouveau mot de passe dans wp-config.php.

2. Confirmer que le serveur MySQL tourne vraiment

Si les identifiants sont corrects, le problème vient peut-être du serveur de base de données lui-même. Deux façons de vérifier :

• Via le panel d’hébergement : la plupart des interfaces (cPanel, Plesk) affichent l’état des services. Cherche “MySQL” ou “MariaDB” dans la liste des services système.
• Via phpMyAdmin : essaie de t’y connecter avec les mêmes identifiants que ceux de wp-config.php. Si phpMyAdmin refuse aussi la connexion, le souci vient bien du serveur, pas de WordPress.

Si tu as un accès SSH, une commande simple permet de vérifier l’état du service :

systemctl status mysql

ou selon la distribution :

service mysql status

Si tu n’es pas à l’aise avec le terminal, notre guide sur SSH et les bonnes pratiques t’aidera à comprendre les risques avant de t’y aventurer.

Sur un mutualisé, tu ne peux généralement pas redémarrer le service toi-même : c’est là qu’il faut contacter le support de l’hébergeur (voir étape 5).

3. Réparer la base de données via WordPress

WordPress intègre un outil de réparation natif, désactivé par défaut pour des raisons de sécurité. Pour l’activer :

1. Ouvre wp-config.php.
2. Ajoute cette ligne juste avant /* C'est tout, ne touchez pas à ce qui suit ! Bonne publication. */ :

define( 'WP_ALLOW_REPAIR', true );

3. Enregistre, puis rends-toi sur https://tonsite.fr/wp-admin/maintenance.php.
4. Clique sur “Réparer la base de données” (ou “Réparer et optimiser” pour aller plus loin).

Cet outil analyse et corrige les tables corrompues, notamment après une coupure serveur ou un disque plein. Une fois la réparation terminée, retire la ligne de wp-config.php : la laisser active expose cette page à n’importe qui connaissant l’URL.

4. Vérifier le préfixe des tables et l’intégrité via phpMyAdmin

Si la réparation automatique ne suffit pas, direction phpMyAdmin (accessible depuis le panel de ton hébergeur).

• Connecte-toi à ta base et vérifie le préfixe réel des tables (wp_options, wp_posts, etc.). Compare-le avec la valeur $table_prefix dans wp-config.php. Un décalage ici (fréquent après une migration ou une restauration de sauvegarde partielle) provoque exactement ce type d’erreur.
• Sélectionne toutes les tables, puis utilise l’action “Réparer table” dans le menu déroulant en bas de la liste. Une table listée “en cours d’utilisation” ou marquée d’un statut d’erreur est généralement la coupable.
• Si une table wp_options ou wp_posts est manquante ou vide, il faudra restaurer depuis une sauvegarde récente — c’est le moment de vérifier que ton hébergeur ou ton prestataire précédent en conservait bien une.

Si tu reprends un projet après un prestataire disparu et que tu n’as aucune sauvegarde, ce diagnostic phpMyAdmin est souvent la seule porte de sortie avant de devoir reconstruire le contenu.

5. Contacter l’hébergeur (quand c’est côté serveur)

Si les identifiants sont bons, la base semble saine, et pourtant rien ne se connecte : le problème est très probablement côté infrastructure. Les hébergeurs mutualisés appliquent des limites strictes de connexions MySQL simultanées, faciles à atteindre lors d’un pic de trafic ou avec un plugin mal optimisé.

Dans ce cas :

• Ouvre un ticket support en précisant le message d’erreur exact et l’heure d’apparition.
• Demande explicitement si le service MySQL a été redémarré récemment ou si un quota de connexions a été atteint.
• Si le problème est récurrent, c’est un signal que ton hébergement est sous-dimensionné pour ton trafic — direction un hébergement plus robuste ou une optimisation globale de WordPress.

Tableau récapitulatif

FAQ

Quand passer la main à un pro

Si tu as vérifié wp-config.php, confirmé que MySQL tourne, tenté la réparation native et que l’erreur persiste, il est temps d’arrêter de tâtonner. Une base corrompue en profondeur, un décalage de préfixe sur une installation multisite, ou une restauration de sauvegarde mal maîtrisée peuvent transformer une manipulation simple en dégâts irréversibles. Un développeur habitué à ce genre de diagnostic résout généralement ça en moins d’une heure, avec un accès SSH et phpMyAdmin en main — le genre d’intervention qu’une maintenance par abonnement couvre justement, plutôt que de découvrir la facture le jour où tout casse.