Erreur de connexion à la base de données : comment la résoudre

Le message « Erreur lors de la connexion à la base de données » signifie que WordPress n’arrive plus à joindre l’endroit où sont stockés vos contenus. Les trois causes possibles sont des identifiants devenus incorrects, un serveur de base de données arrêté ou saturé, et une base corrompue. Vos données ne sont perdues dans aucun de ces cas.

C’est une panne impressionnante parce qu’elle remplace tout le site par une page blanche avec une phrase. C’est aussi l’une des plus rapides à résoudre quand on procède dans l’ordre.

Comprendre ce qui se passe

WordPress stocke deux choses à deux endroits différents. Les fichiers, thème, extensions et images, sur le disque du serveur. Et tous vos contenus, articles, pages, réglages, comptes, dans une base de données MySQL.

À chaque visite, WordPress ouvre une connexion à cette base avec un nom d’utilisateur et un mot de passe stockés dans le fichier wp-config.php. Si cette connexion échoue, il ne peut rien afficher : il n’a que le contenant, pas le contenu.

Retenez surtout ceci : l’erreur porte sur la connexion, pas sur les données. Dans la très grande majorité des cas, vos contenus sont intacts de l’autre côté du mur.

Cause 1 : les identifiants ont changé

C’est la cause la plus fréquente, et elle survient presque toujours après une action précise : une migration vers un nouvel hébergeur, un changement de mot de passe dans le panneau d’hébergement, ou une restauration de sauvegarde partielle.

Ouvrez wp-config.php à la racine du site. Quatre lignes vous intéressent :

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

Comparez ces quatre valeurs avec celles affichées dans votre panneau d’hébergement, section bases de données. Une seule différence suffit à provoquer l’erreur.

Le piège classique concerne DB_HOST. Beaucoup d’hébergeurs mutualisés n’utilisent pas localhost mais une adresse propre, du type mysql.mondomaine.fr. Cette valeur change souvent lors d’une migration, et c’est celle qu’on oublie.

Si vous avez un doute sur le mot de passe, régénérez-le depuis le panneau d’hébergement et reportez la nouvelle valeur dans wp-config.php. C’est plus rapide que de chercher où est passé l’ancien.

Cause 2 : le serveur de base de données est saturé

Si les identifiants sont corrects, le problème vient du serveur lui-même. Deux situations très différentes se cachent derrière.

Le serveur peut être simplement arrêté, à la suite d’une panne ou d’une maintenance de votre hébergeur. Consultez sa page d’état ou son fil d’actualité : si d’autres clients sont touchés, vous n’avez rien à faire qu’attendre.

Il peut aussi être saturé. Sur un hébergement mutualisé, le nombre de connexions simultanées est plafonné. Un pic de trafic, un robot d’indexation agressif ou une extension qui interroge la base en boucle suffisent à atteindre la limite. L’erreur apparaît alors par intermittence : le site fonctionne, puis tombe, puis revient.

Ce caractère intermittent est un indice décisif. Une erreur permanente vient des identifiants ; une erreur qui va et vient vient de la charge.

À court terme, videz les caches et désactivez temporairement les extensions les plus gourmandes. À moyen terme, il faut soit optimiser le site, soit changer d’offre d’hébergement.

Cause 3 : la base est corrompue

Plus rare, mais bien réelle, en général après une coupure serveur brutale ou un disque saturé. WordPress vous le dit parfois explicitement, avec un message évoquant une table endommagée.

WordPress intègre un outil de réparation qu’il faut activer manuellement. Ajoutez dans wp-config.php :

define( 'WP_ALLOW_REPAIR', true );

Puis rendez-vous sur votresite.fr/wp-admin/maint/repair.php. Choisissez « Réparer la base de données », et laissez tourner.

Point important : retirez cette ligne dès que c’est terminé. Tant qu’elle est présente, la page de réparation est accessible à n’importe qui, sans authentification.

Le cas de l’administration seule

Si le site public fonctionne mais que l’administration affiche l’erreur, avec parfois le message « une ou plusieurs tables sont indisponibles », vous êtes typiquement dans un cas de corruption partielle. La procédure de réparation ci-dessus s’applique.

Vérifier depuis phpMyAdmin

Pour lever le doute entre un problème de connexion et un problème de données, connectez-vous à phpMyAdmin depuis votre panneau d’hébergement.

Si vous accédez à la base et que vous voyez vos tables, avec des préfixes du type wp_posts et wp_options, vos contenus sont là. Le problème est bien une histoire de connexion, et vous êtes revenu à la cause 1.

Si la base apparaît vide, ne paniquez pas immédiatement : vérifiez que vous consultez la bonne base. Un hébergement en héberge souvent plusieurs, et il est facile de se tromper. Une base réellement vide signale en revanche une suppression ou une restauration ratée, et il faut alors passer par une sauvegarde.

Le cas particulier de la migration

Si l’erreur apparaît juste après un changement d’hébergeur, la cause est presque toujours la même, et elle n’est pas là où on la cherche.

Lors d’une migration, on copie généralement le fichier wp-config.php avec le reste. Or ce fichier contient les identifiants de l’ancien hébergeur, qui ne fonctionnent évidemment pas chez le nouveau. Le nom de la base change presque toujours, l’utilisateur aussi, et DB_HOST passe fréquemment de localhost à une adresse spécifique.

Deuxième piège, plus sournois : la base a bien été importée, mais dans une base au nom différent de celui attendu. L’import s’est déroulé sans erreur, tout semble en ordre, et pourtant WordPress cherche au mauvais endroit.

Troisième cas, quand le site s’affiche par intermittence pendant 24 à 48 heures après une migration : ce n’est pas une erreur, c’est la propagation DNS. Certains visiteurs arrivent encore sur l’ancien serveur, d’autres sur le nouveau. Ne modifiez rien, attendez que la propagation se termine.

Vérifier les droits de l’utilisateur

Cas plus rare mais qui résiste à tous les diagnostics classiques : les identifiants sont exacts, le serveur répond, et l’erreur persiste.

Vérifiez alors que l’utilisateur de la base possède bien tous les droits sur celle-ci. Dans le panneau d’hébergement, un utilisateur peut exister sans être rattaché à la base, ou n’avoir que des droits de lecture. WordPress a besoin de lire et d’écrire.

Ce cas survient typiquement après une restauration partielle ou une manipulation manuelle dans phpMyAdmin. Réassocier l’utilisateur à la base avec tous les privilèges règle le problème en une minute.

Ce qu’il ne faut surtout pas faire

Ne réinstallez pas WordPress par-dessus en espérant que ça arrange les choses. Vous risquez d’écraser wp-config.php et de perdre les identifiants corrects que vous n’aviez peut-être pas notés.

Ne supprimez aucune table depuis phpMyAdmin. Et ne restaurez pas une sauvegarde de base de données par-dessus l’existante avant d’avoir compris la cause : si le problème vient des identifiants, vous venez d’écraser des contenus valides pour rien.

Un dernier réflexe utile : notez la date et l’heure exactes de la panne avant d’intervenir. Si l’erreur est intermittente, ce relevé permet de la corréler avec les pics de trafic ou les tâches planifiées de votre hébergeur, et c’est souvent ce qui fait la différence entre un diagnostic en dix minutes et une matinée perdue.

Éviter la prochaine fois

Trois habitudes suffisent. Notez vos identifiants de base ailleurs que dans wp-config.php, dans un gestionnaire de mots de passe. Sauvegardez la base quotidiennement, sur un support distinct du serveur. Et surveillez la disponibilité du site, pour être prévenu avant vos clients.

Ces trois points sont précisément ce que couvre un contrat de maintenance. Si l’erreur persiste après avoir vérifié les identifiants et l’état du serveur, le diagnostic est gratuit et prend rarement plus de trente minutes.