Comprenez le message avant de modifier WordPress
Le message « Erreur lors de la connexion à la base de données » apparaît lorsque WordPress n’arrive pas à établir la communication attendue avec sa base. Cette base contient notamment les articles, les comptes et une grande partie des réglages. La panne ne signifie pas automatiquement que ces données ont été effacées : un mot de passe devenu incorrect ou un service momentanément indisponible peut produire le même écran.
Commencez par ouvrir l’accueil, une page intérieure et l’administration. Relevez le texte exact de chaque réponse. Une page servie depuis un cache peut continuer à s’afficher alors que l’administration échoue ; cela ne prouve pas que la base fonctionne normalement. À l’inverse, une erreur sur un seul écran peut demander un diagnostic plus ciblé qu’une panne générale.
Notez le dernier changement connu : migration, restauration, modification du compte MySQL, changement d’hébergement ou pic d’activité. Une erreur apparue immédiatement après le déplacement du site oriente d’abord vers sa configuration. Une erreur intermittente sans changement récent mérite aussi un examen du service de base de données et de ses limites.
Les étapes qui suivent concernent une installation dont vous pouvez administrer l’hébergement. Sur une plateforme gérée comme WordPress.com, transmettez les observations au support lorsque les fichiers et le serveur ne sont pas accessibles. Aucun plugin n’est nécessaire pour ce diagnostic.
Choisissez entre trois approches
L’approche 1 consiste à remettre en cohérence la configuration WordPress et les accès fournis par l’hébergeur. Elle est adaptée après une migration ou un changement d’identifiants. Vous comparez des valeurs précises, puis corrigez uniquement celles dont l’écart est confirmé.
L’approche 2 vérifie la disponibilité du service MySQL ou MariaDB. Elle devient prioritaire lorsque la configuration est inchangée, que l’erreur apparaît par intermittence ou que plusieurs sites du même hébergement sont touchés. La correction se trouve alors souvent dans le service, sa capacité ou la communication entre serveurs.
L’approche 3 concerne la base elle-même : mauvaise base sélectionnée, import incomplet, préfixe incohérent ou table réellement endommagée. Elle ne doit pas commencer par une réparation générale. Il faut d’abord établir ce qui manque ou ce qui échoue et savoir quel moteur de stockage est utilisé.
Gardez un relevé simple de vos essais : heure, adresse testée, changement effectué et résultat. Faites une seule modification à la fois. Une série de changements simultanés peut faire disparaître le message sans vous permettre de savoir quelle correction était nécessaire, ni quelle autre fonction a été affectée.
Protégez les données et la configuration actuelle
Repérez la sauvegarde la plus récente qui contient à la fois les fichiers et la base. Vérifiez sa date, son emplacement et la possibilité de la restaurer sur une copie. Une archive des fichiers du site peut contenir les images et les extensions sans contenir les articles ni les commandes enregistrées dans la base.
Conservez également l’état actuel si l’hébergeur peut en prendre un instantané. Sur un site actif, des données utiles peuvent avoir été créées depuis la dernière copie saine. Restaurer toute la base de la veille pour corriger un identifiant erroné ferait courir un risque de perte qui n’a aucun rapport avec la cause réelle.
Téléchargez une copie de wp-config.php dans un emplacement local privé avant de le modifier. Ce fichier contient des secrets : ne le publiez pas dans un ticket ouvert, un forum ou un dépôt de code. Ne laissez pas non plus une copie nommée .bak dans le répertoire public, car elle pourrait être téléchargée selon la configuration du serveur.
Si la base est inaccessible, ne concluez pas que la sauvegarde est impossible : le prestataire peut disposer de copies et d’outils qui ne dépendent pas du fonctionnement de WordPress. Demandez ce qu’il peut préserver avant une réparation ou une restauration. N’effacez pas la base existante pour faire de la place à une nouvelle installation.
Approche 1 : comparer les quatre paramètres de connexion
Dans le gestionnaire de fichiers ou par SFTP, ouvrez le fichier de configuration de la bonne installation. Vérifiez le domaine associé au répertoire : le même compte peut contenir plusieurs versions du site. Recherchez les quatre constantes de connexion et comparez-les avec les informations de l’hébergement.
DB_NAME désigne le nom exact de la base. Il peut inclure un préfixe ajouté par le prestataire. DB_USER désigne l’utilisateur MySQL ou MariaDB autorisé à y accéder ; ce n’est pas votre identifiant d’administrateur WordPress. DB_PASSWORD est le mot de passe de cet utilisateur de base. Enfin, DB_HOST indique le serveur à joindre, avec éventuellement un port ou un chemin de socket selon l’environnement.
Recopiez les valeurs depuis une information fiable du panneau client. Ne les déduisez pas du domaine public. Après une migration, le nom de la base peut sembler identique tout en ayant un autre préfixe, et le serveur SQL peut être séparé du serveur web. Le mot de passe d’un compte d’hébergement n’est pas nécessairement celui de l’utilisateur SQL.
Si les valeurs sont chargées depuis des variables d’environnement ou un fichier géré par le prestataire, ne remplacez pas cette logique par des valeurs écrites à plusieurs endroits. Faites corriger la source réellement utilisée. Une seconde définition dans wp-config.php ne garantit pas que vous remplacez la première et peut produire un avertissement.
Corrigez la valeur confirmée et vérifiez les permissions du compte
Modifiez uniquement le paramètre dont vous avez confirmé l’erreur. Conservez la syntaxe PHP existante : guillemets, virgule et point-virgule. Utilisez un éditeur de texte simple, sans guillemets typographiques. Si le secret contient des caractères nécessitant un échappement dans la chaîne PHP, faites appliquer la valeur correctement plutôt que de retirer ces caractères du mot de passe.
Enregistrez, puis ouvrez l’administration et une page publique. Si une nouvelle erreur de syntaxe apparaît, remettez immédiatement la copie du fichier et revérifiez la modification. Une erreur PHP introduite pendant le dépannage est distincte de la panne initiale de connexion.
Dans le panneau de gestion des bases, vérifiez aussi que l’utilisateur est bien associé à la base sélectionnée et dispose des droits nécessaires à WordPress. Un compte peut exister sans être autorisé sur cette base. Demandez une correction limitée à l’installation concernée ; il n’est pas nécessaire de lui donner des droits d’administration sur toutes les bases du serveur.
Ne réinitialisez pas le mot de passe SQL sans vérifier quels sites ou services l’utilisent. S’il est partagé, ils devront être mis à jour de façon coordonnée. Une rotation peut être justifiée, mais elle doit avoir un périmètre connu. Sinon, vous risquez de réparer un site en coupant la connexion d’un autre.
Ne remplacez pas DB_HOST au hasard
Les valeurs localhost et 127.0.0.1 ne sont pas interchangeables dans tous les environnements. Selon le système et le client, la première peut utiliser un socket local tandis que la seconde impose une connexion TCP. Le port, le chemin du socket et les autorisations du compte peuvent donc changer le résultat.
Utilisez l’adresse fournie par l’hébergeur pour cette installation. Si la base est sur un serveur distant, demandez également depuis quel serveur web les connexions sont autorisées. Une migration peut avoir changé l’origine de la connexion sans que les autorisations correspondantes aient suivi.
N’ouvrez pas le service SQL à toutes les adresses pour tester. Faites vérifier le chemin réseau et l’autorisation de l’origine attendue. Si le prestataire vous donne une nouvelle valeur, notez l’ancienne, appliquez la correction et répétez le même test. Un exemple réussi sur un forum n’est pas une valeur universelle à recopier dans votre configuration.
Approche 2 : vérifier le service et la disponibilité de la base
Consultez les incidents annoncés par l’hébergeur et l’état des services dans le compte client. Si plusieurs installations du même compte échouent au même moment, indiquez-le au support. Ce constat oriente vers une ressource commune, mais il ne dispense pas de vérifier si elles utilisent réellement le même serveur de base de données.
Essayez d’ouvrir la base depuis l’outil fourni par l’hébergeur. Si phpMyAdmin ne peut pas joindre le serveur, conservez son message et l’heure. Si phpMyAdmin fonctionne, restez prudent : il peut utiliser un autre compte ou une autre route réseau que WordPress. Cette réussite ne prouve donc pas que les quatre paramètres de l’application sont corrects.
Demandez au prestataire de tester la connexion depuis le serveur web avec l’utilisateur SQL du site, sans lui transmettre le secret dans un message public. Un compte client authentifié lui permet normalement d’identifier l’installation. Le résultat technique distingue un accès refusé, un hôte inaccessible, une base inconnue ou une limite atteinte.
Sur un serveur que vous administrez, commencez par les journaux du service et les ressources disponibles. Un redémarrage peut rendre le site disponible temporairement sans expliquer pourquoi la panne revient. Évitez les redémarrages répétés pendant une restauration ou un traitement important. Conservez les traces de l’incident avant toute opération qui les rendrait plus difficiles à interpréter.
Si l’erreur apparaît seulement à certaines heures
Comparez les horaires de panne avec les tâches prévues : sauvegardes, imports, synchronisations, génération de rapports ou traitement de commandes. Une erreur pendant chaque import peut signaler une charge concentrée. Elle ne démontre pas automatiquement que l’extension d’import est défectueuse ; le volume et les ressources disponibles comptent aussi.
Un message technique indiquant trop de connexions signifie que les connexions autorisées sont déjà occupées. Faites identifier les traitements qui les consomment et leur durée. Augmenter une limite sans examiner la mémoire et la charge peut déplacer le problème. Le prestataire doit pouvoir expliquer si la capacité est insuffisante ou si un traitement conserve des connexions anormalement longtemps.
Si vous avez lancé une tâche non essentielle qui coïncide avec la panne, interrompez-la par son mécanisme normal lorsque c’est prévu, puis observez le résultat. Ne tuez pas au hasard des processus de base de données sur une boutique en production. Une action en cours peut écrire des données dont il faut préserver la cohérence.
Après correction, observez le site pendant le créneau où l’erreur se produisait. Une page qui fonctionne à un moment calme ne valide pas une panne liée à la charge. Conservez l’heure et le résultat de ce contrôle dans votre relevé, sans transformer un seul essai réussi en garantie de disponibilité permanente.
Approche 3 : vérifier la bonne base, les tables et le préfixe
Après une migration, ouvrez la base sélectionnée dans l’outil de l’hébergeur et regardez la liste des tables. Vérifiez que l’import a réellement été effectué et qu’il s’est terminé sans erreur. Une base créée mais vide ne contient pas votre site, même si son nom correspond à celui du fichier de configuration.
Comparez ensuite le préfixe déclaré dans $table_prefix avec celui des tables du site. Un préfixe incohérent peut conduire WordPress à ne pas retrouver l’installation attendue. Si un assistant d’installation apparaît alors que le site possédait déjà du contenu, ne le lancez pas immédiatement. Cela peut signaler une mauvaise base, un mauvais préfixe ou un import incomplet.
Lorsque plusieurs groupes de tables existent, ne choisissez pas simplement celui qui possède le plus de lignes. Repérez la copie attendue à partir du contexte de migration, des adresses du site et des données connues. Un ancien groupe peut contenir beaucoup d’articles tout en ignorant les commandes les plus récentes. Faites confirmer ce choix avant de changer le préfixe ou d’importer de nouveau.
Si la base est correcte mais qu’une table manque, relisez le compte rendu d’import. La création peut avoir échoué à cause d’une limite de taille, d’une permission ou d’une incompatibilité. Réimporter toute la sauvegarde par-dessus une base utilisée entre-temps peut écraser des données valides. Préférez reproduire l’import dans une base de test pour comprendre ce qui échoue.
Contrôler les tables avec WP-CLI, lorsque c’est approprié
Si vous disposez de WP-CLI et d’un accès SSH autorisé, la commande ci-dessous utilise les paramètres de la configuration pour vérifier les tables. Elle dépend aussi de l’outil de contrôle MySQL disponible sur le serveur. Placez-vous dans le répertoire de la bonne installation avant de l’utiliser.
Ce contrôle n’est pas une réparation et peut solliciter ou verrouiller des tables selon leur moteur et leur état. Sur une base volumineuse, une boutique active ou une corruption suspectée, faites choisir le moment et la méthode par l’hébergeur, idéalement sur une copie. Ne le lancez pas en boucle pour surveiller la disponibilité.
Lisez le message complet. Un échec de connexion signifie que le contrôle n’a pas pu examiner les tables ; il ne prouve pas qu’elles sont endommagées. Une table signalée en erreur demande ensuite une analyse propre à son moteur. Un résultat satisfaisant ne garantit pas que les données métier, les relations entre extensions et tous les contenus attendus sont présents.
wp db checkRéparer uniquement quand le diagnostic le justifie
Consultez le type de moteur des tables dans l’outil d’administration ou demandez-le au support. Les procédures fondées sur REPAIR TABLE ne s’appliquent pas à tous les moteurs. En particulier, une table InnoDB ne se répare pas avec cette commande classique. Répéter une action non prise en charge ne transforme pas son résultat en réparation.
WordPress possède une page de réparation native, activable temporairement avec WP_ALLOW_REPAIR. Elle ne résout pas un mauvais mot de passe SQL ni un serveur inaccessible. Réservez-la à un cas où la connexion fonctionne et où le diagnostic a confirmé qu’une opération prise en charge par le moteur est pertinente. Conservez une sauvegarde ou un instantané avant toute écriture de réparation.
Cette page peut être utilisée sans connexion à l’administration lorsqu’elle est activée. Faites donc protéger son accès par l’hébergement pendant l’intervention, ou travaillez sur une copie isolée. Dans ce contexte, ajoutez temporairement define( 'WP_ALLOW_REPAIR', true ); à la configuration avant le chargement de WordPress, ouvrez le chemin /wp-admin/maint/repair.php du site concerné et choisissez la réparation prévue. L’optimisation n’est pas nécessaire simplement pour tenter de rétablir une connexion.
Conservez le résultat, retirez immédiatement la constante temporaire, puis vérifiez que la fonction n’est plus accessible dans cet état. Si une table InnoDB est réellement endommagée, demandez une procédure de récupération adaptée au serveur et à sa version. N’appliquez pas au hasard un mode de récupération forcée ou des commandes trouvées pour un autre moteur.
Si une restauration devient nécessaire
Une restauration doit répondre à un manque ou à une corruption identifiée. Vérifiez la date de la copie et les données qui seraient perdues en revenant à cet instant. Pour une boutique, prenez en compte les commandes, paiements, stocks et comptes créés depuis. Une copie ancienne peut remettre l’accueil en ligne tout en rendant les informations commerciales incohérentes.
Demandez d’abord une restauration dans un environnement distinct. Contrôlez le contenu attendu et la cohérence avec les fichiers : médias, thèmes et versions des extensions doivent correspondre à un état utilisable. Une base restaurée avec des versions de composants très différentes peut demander des traitements supplémentaires.
Préparez ensuite le passage en production avec une méthode de conservation des données récentes. Cette méthode dépend du site ; recopier quelques lignes à la main n’est pas une procédure universelle pour des commandes liées à plusieurs tables. Gardez l’état antérieur à l’intervention jusqu’à la fin des vérifications.
Si le problème se limitait à un paramètre erroné, la restauration n’apporte rien de plus qu’une correction ciblée. L’accès retrouvé doit s’accompagner d’une explication de la cause, afin de ne pas reproduire la même panne lors de la prochaine migration.
Vérifiez le retour à un fonctionnement normal
Ouvrez l’administration et quelques pages publiques en visiteur déconnecté. Contrôlez un contenu ancien et un contenu récent pour vous assurer que vous consultez la bonne base. Si vous avez une copie de test, vérifiez que la production ne pointe pas accidentellement vers elle et que les deux environnements ne partagent pas des écritures par erreur.
Effectuez ensuite une petite action d’écriture adaptée au site, par exemple enregistrer un brouillon de test identifié comme tel. Une base accessible en lecture mais mal autorisée en écriture peut afficher les pages sans permettre les modifications. Sur une boutique, utilisez les parcours de test prévus, sans déclencher un paiement réel uniquement pour ce contrôle.
Vérifiez les journaux à l’heure de ces essais et retirez les réglages temporaires de diagnostic ou de réparation. Si des secrets ont été publiés pendant le dépannage, faites organiser leur remplacement de façon coordonnée. Le fait de masquer une capture après coup ne garantit pas que les valeurs exposées n’ont pas été copiées.
Un plugin de nettoyage ou d’optimisation ne remplace aucune de ces étapes. Quand WordPress ne peut pas accéder à sa base, cet outil peut être incapable de fonctionner lui aussi. Les outils de l’hébergeur, la configuration et les diagnostics du serveur constituent le parcours principal. Le bon résultat est un site qui lit et enregistre les données attendues, avec une cause identifiée et une correction documentée.
