Erreur de connexion à la base WordPress : diagnostic sans fuite de secret

Le message « Error establishing a database connection » n’annonce pas forcément une base perdue. WordPress n’arrive pas à utiliser la connexion dont il a besoin, mais la cause peut se trouver dans la configuration, le service de base de données ou le chemin qui les relie. La première étape consiste à relever l’erreur précise sans exposer les accès du site.

Identifier la panne derrière le message affiché

Notez quand l’erreur apparaît, les pages concernées et le dernier changement connu : migration, rotation d’un mot de passe, intervention de l’hébergeur ou hausse de trafic. Comparez une page publique et l’administration. Une page encore visible peut venir d’un cache alors que les demandes qui sollicitent réellement WordPress échouent.

La documentation des erreurs WordPress présente plusieurs causes possibles. Ce message ne suffit donc pas à conclure à une corruption ou à une intrusion. Si la réponse indique seulement une erreur interne sans mention de connexion, le diagnostic de l’erreur 500 couvre un périmètre différent.

Rapprochez l’heure du test des journaux PHP et de la base accessibles à l’administrateur. Les outils de débogage WordPress peuvent compléter l’analyse si le chargement atteint cette étape, mais ne remplacent pas les journaux du service. Gardez les traces protégées ; afficher toutes les erreurs aux visiteurs peut révéler des chemins ou des informations internes.

Vérifier la configuration sans diffuser les identifiants

Ouvrez la configuration uniquement par un accès autorisé. La référence de wp-config.php décrit notamment le nom de la base, l’utilisateur, le mot de passe et DB_HOST. Comparez ces valeurs à celles fournies pour cet hébergement, sans les copier dans une capture, un ticket public, un journal ou une conversation.

Après une migration, vérifiez que la configuration désigne la bonne instance et que l’utilisateur y existe encore. Une ancienne sauvegarde peut contenir des accès qui ont changé depuis. Remplacer tout le fichier pour récupérer une valeur risque aussi de réintroduire d’autres réglages périmés ; corrigez seulement l’écart confirmé en conservant une préimage protégée.

Si WordPress propose une nouvelle installation alors que le site existait, arrêtez cette procédure. Une connexion peut fonctionner tout en pointant vers une autre base ou un préfixe de tables incorrect. Vérifiez la présence des tables attendues et leur identité avant toute initialisation ; ne recréez pas le site par-dessus les données que vous cherchez à retrouver.

Distinguer le transport du refus d’authentification

Une connexion refusée, un délai dépassé et une erreur Access denied ne s’interprètent pas de la même façon. La documentation des connexions MySQL distingue notamment le service inaccessible du mauvais port ou du mauvais socket. Le contrôle doit partir du serveur qui exécute WordPress, pas seulement de votre ordinateur.

Sur Unix, selon la configuration du client, localhost peut utiliser un socket local alors qu’une adresse IP utilise TCP. Ces chemins ne sont pas interchangeables par principe. Conservez l’hôte et le mode de connexion prévus par l’hébergement ; n’ouvrez pas la base à Internet et ne désactivez pas le pare-feu pour contourner un doute.

Un refus d’authentification oriente vers le compte, son mot de passe, l’hôte depuis lequel il est autorisé ou ses privilèges. Le guide MySQL des problèmes de connexion aide à séparer ces cas. Un accès réussi dans phpMyAdmin ou en ligne de commande ne prouve pas encore que PHP utilise le même compte, le même canal et les mêmes paramètres.

Contrôler le service avant de le redémarrer

Si la base est administrée par l’hébergeur, transmettez l’horaire, le message utile expurgé et le périmètre touché. Si vous gérez le service, relevez d’abord son état, les erreurs récentes, l’espace disponible et la consommation de ressources. Un redémarrage immédiat peut masquer l’état qui expliquait l’arrêt et ne résout pas sa cause.

Le message Too many connections indique que la capacité de connexion est atteinte. Il faut comprendre les connexions présentes et leur durée, les requêtes bloquées ou la hausse de demandes. Augmenter une limite sans tenir compte de la mémoire et de la charge peut déplacer le problème plutôt que rétablir un service durable.

En cas de disque plein, identifiez ce qui occupe l’espace avec l’administrateur. Ne supprimez pas au hasard les fichiers du moteur de base, ses journaux ou la dernière sauvegarde utile. Si plusieurs applications sont touchées, ce périmètre commun renforce la piste d’infrastructure ; il ne désigne pas à lui seul le composant fautif.

Réserver les réparations aux dommages confirmés

Une erreur de connexion n’est pas une preuve de table endommagée. Une fois l’accès rétabli, un contrôle d’intégrité peut aider si les journaux donnent des indices précis. La commande wp db check s’appuie sur l’outil de vérification de la base ; elle ne répare pas automatiquement les données et peut charger le serveur ou prendre des verrous selon les tables et le moteur.

Avant une réparation ou une restauration, vérifiez une sauvegarde récente et restaurable, avec les fichiers et la base nécessaires. La documentation des sauvegardes WordPress rappelle ces deux composantes. Un export créé ne suffit pas : contrôlez son intégrité et sa restauration dans un environnement isolé. Si l’export courant échoue, conservez cet échec et faites qualifier la protection disponible.

Le plan de réparation dépend du moteur, de la version et des dommages observés. Faites-le valider par la personne qui administre la base avant toute écriture. Une procédure trouvée pour un autre type de table peut être inadaptée ; ne remplacez pas la production par une copie locale pour simplement faire disparaître le message.

Vérifier la reprise avec les vrais parcours du site

Après la correction ciblée, contrôlez le contenu et le statut HTTP d’une page qui sollicite réellement WordPress, puis l’administration par l’accès habituel. Vérifiez les journaux à la même heure. Un simple rechargement de l’accueil en cache ne prouve pas que la connexion applicative fonctionne à nouveau.

Testez ensuite les fonctions concernées avec les accès autorisés : recherche, connexion et, si nécessaire, une écriture de test encadrée avec nettoyage prévu. Vérifiez mobile, tablette et ordinateur pour les parcours touchés. Ne créez pas de fausse commande ou de compte persistant uniquement pour valider une lecture de page.

Conservez un relevé court : cause étayée, valeur ou service corrigé, vérifications, protection disponible et retour possible. Retirez tout dispositif temporaire de diagnostic et restaurez le niveau de journalisation prévu. Le retour d’un affichage normal ne dispense pas de rechercher les raisons d’une saturation ou d’un arrêt répété.

La maintenance WordPress peut suivre cette stabilité dans le temps. Si le site reste indisponible ou si l’intégrité des données est incertaine, une intervention sur un site en panne permet de cadrer la reprise à partir des preuves et des sauvegardes existantes, sans promettre une restauration que personne n’a encore vérifiée.