« Erreur lors de la connexion à la base de données » signifie que WordPress n’a pas pu joindre le serveur qui stocke vos contenus. Le site entier disparaît, administration comprise. La cause est toujours l’une de ces trois-là, et on les distingue en quelques minutes.
Je regarde votre situation et je vous dis en vingt minutes ce qui mérite d’être corrigé en priorité.
Vérifier les identifiants en premier
Le fichier wp-config.php contient quatre constantes : DB_NAME, DB_USER, DB_PASSWORD et DB_HOST. Une seule valeur erronée suffit. C’est la cause principale après une migration, une restauration de sauvegarde, ou un changement d’hébergeur.
Le piège classique est DB_HOST. Sur beaucoup d’hébergeurs mutualisés, la valeur n’est pas localhost mais une adresse spécifique du type mysql.monhebergeur.fr. Un fichier copié depuis un autre serveur conserve l’ancienne valeur, et rien ne fonctionne.
Le serveur de base saturé
Si les identifiants sont bons, le serveur peut simplement refuser de nouvelles connexions. Sur un mutualisé, le nombre de connexions simultanées est limité : un pic de trafic, un robot agressif ou une extension qui interroge la base en boucle suffisent à atteindre le plafond.
Le symptôme caractéristique : l’erreur apparaît par intermittence. Le site fonctionne, puis échoue, puis refonctionne. Une panne d’identifiants, elle, est permanente.
- Erreur permanente depuis une migration : identifiants ou DB_HOST
- Erreur intermittente aux heures de pointe : serveur saturé
- Erreur sur une seule page : table spécifique corrompue
- Erreur apparue après une coupure serveur : table à réparer
- Administration accessible mais pas la partie publique : cache obsolète
| Comportement observé | Cause | Vérification |
|---|---|---|
| Erreur permanente après migration | Identifiants ou DB_HOST erronés | Comparer avec le panneau de l’hébergeur |
| Erreur par intermittence | Connexions simultanées saturées | Journal des accès, trafic robots |
| Erreur après une coupure serveur | Table corrompue | WP_ALLOW_REPAIR puis repair.php |
| phpMyAdmin refuse aussi la connexion | Problème côté serveur | Contacter le support de l’hébergeur |
Je peux appliquer directement ces corrections sur votre site plutôt que vous laisser une liste de recommandations.
La réparation intégrée que peu de gens connaissent
WordPress embarque un outil de réparation, désactivé par défaut. Ajoutez define('WP_ALLOW_REPAIR', true) dans wp-config.php, puis ouvrez votre-site.fr/wp-admin/maint/repair.php. La page est accessible sans connexion — c’est précisément pourquoi elle est désactivée par défaut.
Deux boutons apparaissent : réparer, ou réparer et optimiser. La première option suffit dans la plupart des cas. Retirez impérativement la constante une fois l’opération terminée, sans quoi n’importe qui peut lancer une réparation sur votre base.
Tester la connexion indépendamment
Pour savoir si le problème vient de WordPress ou du serveur de base, essayez de vous connecter à phpMyAdmin avec les mêmes identifiants. Si la connexion échoue là aussi, le problème est côté hébergeur ou identifiants. Si elle réussit, c’est la configuration de WordPress qui est en cause.
Une erreur de base de données permanente vient des identifiants. Une erreur intermittente vient de la charge. Le rythme du symptôme est déjà un diagnostic.
Ce qu’il faut retenir
Contrôlez wp-config.php ligne par ligne, en particulier DB_HOST que beaucoup oublient. Testez ensuite les mêmes identifiants dans phpMyAdmin : cela départage immédiatement une erreur de configuration d’une panne serveur. La réparation intégrée ne sert qu’au troisième cas, celui des tables corrompues.
Utiliser la réparation intégrée de WordPress
Avantages
- Aucun outil externe nécessaire
- Fonctionne même sans accès à l’administration
- Corrige la majorité des tables marquées comme corrompues
- Opération rapide, y compris sur une base volumineuse
Inconvénients
- La page est accessible sans authentification
- Ne corrige rien si la cause vient des identifiants
- Peut échouer sur une corruption profonde
- Impose de ne pas oublier de retirer la constante
Rétablir la connexion
0 sur 5 points validés
Cochez au fur et à mesure : votre avancement reste sur cet appareil, rien n’est envoyé et aucun compte n’est nécessaire.
Commencez par les quatre constantes de wp-config.php, DB_HOST en tête. Une erreur permanente vient des identifiants, une erreur intermittente de la charge serveur. La réparation intégrée ne traite que le cas des tables corrompues, et sa constante doit être retirée juste après.
Questions fréquentes
Où trouver les bons identifiants de base ?
Dans le panneau de votre hébergeur, rubrique bases de données. Le nom de la base, l’utilisateur et le serveur y figurent. Le mot de passe n’est généralement pas affiché : il faut le réinitialiser et reporter la nouvelle valeur dans wp-config.php.
Mes contenus sont-ils perdus ?
Presque jamais. Cette erreur signifie que WordPress ne parvient pas à joindre la base, pas que celle-ci a disparu. Vérifiez dans phpMyAdmin que les tables sont bien présentes avant de vous inquiéter.
L’erreur revient chaque jour à la même heure.
Cela évoque une tâche planifiée : sauvegarde, import, ou traitement par lots qui sature les connexions. Regardez les tâches cron de votre hébergeur et les extensions programmées à cet horaire.
Sources et vérifications
Causes ordonnées par fréquence sur les dépannages réalisés. Les noms de constantes correspondent à WordPress 6.x.
Décrivez votre situation en quelques lignes. Réponse sous 24 heures, sans engagement ni relance commerciale.
