Votre site affiche une phrase et rien d'autre : « Erreur lors de la connexion à la base de données ». Le contenu, les pages, les commandes, tout est encore là, mais WordPress n'arrive plus à y accéder.
Ce guide donne la procédure qu'on applique en intervention. Il commence par un test de trente secondes que presque aucun autre guide ne mentionne, et qui vous dira laquelle des trois familles de causes vous avez. Il vous dira aussi quand la fameuse ligne WP_ALLOW_REPAIR sert à quelque chose, et quand elle ne peut rien faire pour vous.
Le test qui prend trente secondes
Ouvrez deux onglets. Dans le premier, votre site. Dans le second, l'adresse de votre tableau de bord, https://votre-domaine.fr/wp-admin/.
Regardez les deux messages. Ils ne sont pas les mêmes, et c'est toute l'information dont vous avez besoin pour commencer.
Sur le site public, le message ne dit rien
Une phrase, et c'est tout.
Nous avons provoqué trois pannes différentes au laboratoire : un mot de passe périmé dans le fichier de configuration, un serveur de base de données arrêté, et une table disparue. Les trois donnent exactement la même page, à l'octet près. 2 507 octets dans les trois cas.
Autrement dit : regarder votre page d'accueil n'apprend rien sur la cause. C'est pourtant là que tous les guides demandent de commencer.
Sur le tableau de bord, le message trahit la cause
C'est là que se joue le diagnostic. Deux messages possibles.
Premier message :
Il parle de wp-config.php, d'identifiant, de mot de passe et du serveur de base de données. Vous êtes dans la famille « la connexion ne s'établit pas » : identifiants faux, serveur arrêté, adresse de serveur erronée, ou quota atteint.
Second message :
« Une ou plusieurs tables de votre base de données sont indisponibles. La base de données a peut-être besoin d'être réparée. »
Vous êtes dans une famille complètement différente : la connexion fonctionne, WordPress parle à votre base, mais une table manque ou est abîmée. Le remède n'a rien à voir.
Ce que ce test change
Les deux familles demandent deux dépannages sans rapport, et une bonne partie du temps perdu vient de là : les gens appliquent à la première les remèdes de la seconde.
Notez laquelle vous avez, et suivez la section correspondante.
Ce que WP_ALLOW_REPAIR peut et ne peut pas faire
Tous les guides que nous avons lus, en français, en anglais, en allemand, en espagnol et en italien, placent cette manipulation en deuxième étape. Elle consiste à ajouter une ligne dans wp-config.php puis à visiter une page de réparation.
Elle ne fonctionne que dans la seconde famille.
Nous l'avons vérifié. Avec la connexion cassée, la page de réparation renvoie exactement la même erreur que le reste du site.
La raison est simple une fois qu'on la voit : cette page a elle-même besoin d'une connexion à la base pour s'exécuter. Elle ne peut donc rien réparer quand le problème est justement qu'on ne s'y connecte pas. Vous pouvez la recharger dix fois, elle affichera dix fois la même erreur.
Quand la connexion fonctionne et qu'une table est en cause, la même page s'ouvre normalement.
Un avertissement que les guides mentionnent à peine. Tant que la ligne WP_ALLOW_REPAIR est présente dans votre fichier de configuration, cette page est accessible à n'importe qui, sans être connecté. Nous avons fait toutes nos requêtes sans le moindre cookie de session, et la page a répondu et proposé son bouton. Ce n'est pas une précaution de principe : la ligne doit être retirée dès que vous avez fini, et c'est la seule chose qui ferme cette porte.
En trente secondes
1. Comparez le site public et le tableau de bord. Le message de /wp-admin vous dit à quelle famille vous appartenez.
2. Demandez-vous ce qui a changé. Cette panne n'arrive presque jamais toute seule. Une migration, un changement d'hébergeur, une mise à jour, un mot de passe modifié dans le panneau de l'hébergeur, une facture impayée. La réponse est presque toujours dans les quarante-huit heures qui précèdent.
3. Ouvrez le panneau de votre hébergeur. S'il ne répond pas non plus, la cause est là et vous n'avez rien à réparer.
Les causes, par famille
Famille 1 : la connexion ne s'établit pas
| Cause | Ce qui la trahit |
|---|---|
| Mot de passe changé dans le panneau de l'hébergeur | quelqu'un a « sécurisé » le compte récemment |
| Identifiants faux après une migration | le site marchait avant le déménagement |
| Serveur de base arrêté ou saturé | les autres sites du même hébergement sont touchés |
| Adresse du serveur erronée | l'hébergeur n'utilise pas localhost, et personne ne l'a dit |
| Quota de la base atteint | rien ne s'affiche, aucun message n'en parle |
| Préfixe des tables modifié | une manipulation de sécurité mal terminée |
| Trop de connexions simultanées | la panne va et vient selon l'affluence |
Famille 2 : la connexion fonctionne, les tables sont abîmées
| Cause | Ce qui la trahit |
|---|---|
| Table corrompue par un arrêt brutal | coupure de courant, serveur redémarré de force |
| Table manquante après une restauration partielle | une sauvegarde restaurée à moitié |
| Table verrouillée par une opération interrompue | un import qui a échoué en cours de route |
La réparation, cause par cause
Les identifiants ne passent plus
Ouvrez wp-config.php par FTP, par SFTP, ou par le gestionnaire de fichiers de votre hébergeur. Il est à la racine du site. Quatre lignes vous intéressent :
define( 'DB_NAME', 'nom_de_la_base' );
define( 'DB_USER', 'utilisateur' );
define( 'DB_PASSWORD', 'le-mot-de-passe' );
define( 'DB_HOST', 'localhost' );
Comparez chacune avec ce qu'affiche le panneau de votre hébergeur, dans la section des bases de données. Recopiez à la main plutôt que par copier-coller, un espace invisible en fin de chaîne suffit à tout casser.
Attention aux caractères spéciaux dans le mot de passe. Une apostrophe casse la ligne PHP et produit exactement la même erreur qu'un mot de passe faux. C'est un cas relevé plusieurs fois dans les forums, et jamais dans les articles. Si votre mot de passe contient une apostrophe, changez-le dans le panneau de l'hébergeur pour un mot de passe sans apostrophe ni antislash.
L'adresse du serveur n'est pas localhost
C'est une cause que les articles français n'évoquent jamais, et qui revient régulièrement sur les forums anglophones et allemands.
Beaucoup d'hébergements font tourner la base sur une autre machine que le site. Dans ce cas localhost ne désigne rien d'utile, et il faut mettre l'adresse exacte que donne le panneau de l'hébergeur, du genre mysql-monsite.alwaysdata.net ou une adresse numérique. Certains hébergements demandent aussi 127.0.0.1 plutôt que localhost, ce qui n'est pas la même chose : le premier passe par le réseau, le second par un fichier de communication local.
Cherchez cette information dans votre panneau avant d'inventer, elle y est toujours écrite.
Le serveur de base est arrêté ou saturé
Vous ne pouvez rien y faire vous-même sur un hébergement mutualisé. Deux vérifications :
Vos autres sites répondent-ils ? S'ils sont tous en panne, c'est le serveur, pas votre site. Allez voir la page d'état de votre hébergeur.
La panne va-t-elle et vient-elle ? Si le site fonctionne par moments, c'est le signe d'une saturation, pas d'un identifiant faux. Un identifiant faux échoue toujours, une saturation échoue par intermittence, souvent aux heures de trafic. Notez les horaires avant d'appeler le support, ça leur fait gagner une heure.
Le quota de la base est atteint
Cause fréquente en mutualisé bon marché, et totalement invisible depuis le site. WordPress affiche la même phrase que pour un mot de passe faux, sans jamais mentionner de quota.
Le seul endroit où l'information existe est le panneau de votre hébergeur, dans la section des bases de données, où figure la taille occupée et la taille autorisée. Regardez-y avant de modifier quoi que ce soit dans vos fichiers.
Ce qui remplit une base sans qu'on s'en rende compte : les révisions d'articles, qui s'accumulent sans limite, les tables laissées derrière eux par des extensions désinstallées, et les journaux de certains plugins de sécurité ou de statistiques.
Une table est corrompue ou manquante
C'est le seul cas où la réparation automatique de WordPress sert.
Ouvrez wp-config.php et ajoutez, juste avant la ligne qui dit de ne rien modifier au-delà :
define( 'WP_ALLOW_REPAIR', true );
Puis visitez :
https://votre-domaine.fr/wp-admin/maint/repair.php
Deux boutons apparaissent. « Réparer la base de données » suffit dans la plupart des cas. « Réparer et optimiser » prend beaucoup plus de temps et n'apporte rien sur une petite base.
Retirez la ligne dès que c'est terminé. Tant qu'elle est là, cette page est ouverte à tout le monde, sans mot de passe. Ce n'est pas théorique, nous l'avons vérifié sans aucune session.
Deux limites à connaître. La réparation verrouille chaque table pendant qu'elle travaille : sur une grosse table, le site reste inaccessible pendant l'opération, ce qui inquiète beaucoup de gens qui l'interrompent au milieu. Et elle ne fait rien si la table est absente et non corrompue : dans ce cas il faut la restaurer depuis une sauvegarde.
Rien de tout cela
Testez la connexion en dehors de WordPress. Créez un fichier test-base.php à la racine du site avec ce contenu, en remplaçant les quatre valeurs par celles de votre wp-config.php :
<?php
$c = @mysqli_connect( 'localhost', 'utilisateur', 'mot-de-passe', 'nom_de_la_base' );
if ( $c ) {
echo 'Connexion réussie.';
} else {
echo 'Échec : ' . mysqli_connect_error();
}
Visitez https://votre-domaine.fr/test-base.php.
Ce test vaut de l'or parce qu'il vous donne le message d'erreur réel de la base, celui que WordPress vous cache. « Access denied for user » désigne un identifiant ou un mot de passe. « Unknown database » désigne un nom de base. « Can't connect to MySQL server » désigne un serveur injoignable, et vous n'y pouvez rien.
Supprimez ce fichier immédiatement après. Il contient vos identifiants de base en clair.
Le cas de la migration
Si la panne date d'un déménagement, quatre choses ont pu changer sans que vous le sachiez.
Le nom de la base a été renommé par l'hébergeur d'arrivée, qui préfixe souvent par le nom du compte. L'utilisateur a été renommé de la même façon. Le mot de passe a été régénéré et envoyé dans un e-mail que personne n'a lu. Et l'adresse du serveur n'est plus localhost.
Reprenez les quatre valeurs depuis le panneau du nouvel hébergeur, pas depuis vos notes.
Un cas relevé sur un forum mérite d'être connu : quelqu'un avait bien sauvegardé ses fichiers par FTP avant de résilier son ancien hébergement, mais pas sa base de données. Les fichiers ne contiennent aucun contenu, ils ne contiennent que le code. Tout le site était perdu. Une sauvegarde de fichiers n'est pas une sauvegarde de site.
Si rien n'a marché
Regardez le journal d'erreur de votre hébergeur, section « logs » ou « journaux ». Le message réel de la base y figure, avec des mots autrement plus utiles que la phrase générique de WordPress.
Appelez le support de l'hébergeur avec des faits. Dites depuis quand, si c'est permanent ou intermittent, si les autres sites du compte sont touchés, et ce que renvoie le test de connexion ci-dessus. Un ticket qui contient ces quatre éléments est traité beaucoup plus vite qu'un ticket qui dit que le site ne marche plus.
Si vous préférez ne pas toucher au fichier de configuration, ou si le test de connexion vous laisse sans réponse, c'est le genre de panne qu'on traite tous les jours. Le dépannage WordPress au forfait coûte 149 € HT, remis en ligne ou remboursé.
Ne restaurez une sauvegarde qu'en dernier. Elle ramène le site sans dire ce qui a cassé, et si la cause est côté serveur elle ne changera rien du tout. Vérifiez aussi jusqu'où remontent vos sauvegardes : chez plusieurs hébergeurs mutualisés, la base n'est conservée que quelques semaines.
Si votre site n'affiche pas ce message mais reste totalement blanc, ou affiche « il y a eu une erreur critique », vous n'êtes pas sur la bonne panne : le guide de l'écran blanc traite ce cas. Et si le message est une erreur 500, c'est encore autre chose, expliqué ici.
Comment éviter que ça recommence
Notez vos identifiants de base ailleurs que dans le fichier de configuration. Le jour où le site tombe, vous ne pourrez peut-être plus ouvrir le fichier.
Ne changez jamais un mot de passe de base depuis le panneau de l'hébergeur sans mettre à jour wp-config.php dans la foulée. C'est la cause la plus bête et la plus fréquente de cette panne.
Surveillez la taille de votre base. Une base qui grossit sans raison, ce sont des révisions d'articles ou les restes d'une extension désinstallée.
Vérifiez que vos sauvegardes contiennent la base, pas seulement les fichiers. Et testez-en une restauration au moins une fois, un jour où tout va bien.
Questions fréquentes
Comment réparer une erreur lors de la connexion à la base de données WordPress ?
Commencez par comparer le message du site public et celui de /wp-admin. S'ils parlent d'identifiant et de wp-config.php, la connexion ne s'établit pas : vérifiez les quatre valeurs du fichier de configuration contre celles du panneau de votre hébergeur. Si le message de /wp-admin parle de tables indisponibles, la connexion fonctionne et il s'agit d'une corruption : c'est le seul cas où la réparation automatique de WordPress sert à quelque chose. Ce test préalable évite de perdre du temps sur une manipulation qui ne peut pas fonctionner.
Pourquoi je n'arrive pas à me connecter au serveur de base de données ?
Quatre raisons possibles, indiscernables depuis la page d'accueil. Le mot de passe a été changé dans le panneau de l'hébergeur sans être reporté dans wp-config.php. Le serveur de base est arrêté ou saturé. L'adresse du serveur n'est pas localhost chez cet hébergeur et personne ne vous l'a dit. Ou le quota de votre base est atteint, ce que WordPress n'affiche jamais. Un petit fichier de test qui tente la connexion en dehors de WordPress vous donne le vrai message d'erreur et tranche entre les quatre.
Comment se connecter à la base de données WordPress ?
Les identifiants sont dans wp-config.php, à la racine du site, dans les lignes DB_NAME, DB_USER, DB_PASSWORD et DB_HOST. Avec ces quatre valeurs vous pouvez ouvrir la base depuis l'outil d'administration de votre hébergeur, en général phpMyAdmin ou Adminer, accessible depuis son panneau. Ces mêmes valeurs doivent correspondre exactement à ce que le panneau affiche dans sa section des bases de données.
Pourquoi « Error establishing a database connection » ?
C'est la version anglaise du même message. Il signifie que WordPress n'a pas réussi à ouvrir une connexion vers sa base. Il ne dit pas pourquoi, et volontairement : détailler l'erreur au visiteur exposerait le fonctionnement interne du site. La véritable explication est dans le journal d'erreur du serveur, ou dans le message que renvoie une tentative de connexion faite hors de WordPress.
La réparation automatique de WordPress est-elle dangereuse ?
Elle est sans risque pour vos données, mais elle laisse une porte ouverte. Tant que la ligne WP_ALLOW_REPAIR est présente dans le fichier de configuration, la page de réparation est accessible à n'importe qui sans connexion, ce que nous avons vérifié. Retirez la ligne dès l'opération terminée. À savoir aussi : la réparation verrouille les tables pendant qu'elle travaille, donc sur une grosse base le site reste inaccessible le temps de l'opération, ce qui est normal et ne doit pas vous faire l'interrompre.
Mon site fonctionnait, personne n'a rien touché, pourquoi cette erreur ?
Quelque chose a changé, mais pas forcément de votre côté. Un hébergeur qui migre ses serveurs, qui change l'adresse de la base ou qui applique une politique de mots de passe, un quota atteint par accumulation de révisions, une facture impayée qui suspend la base avant les fichiers. Regardez d'abord la page d'état et les e-mails de votre hébergeur, avant de modifier quoi que ce soit dans vos fichiers.