Résoudre l’erreur de connexion à la base WordPress

Si vous venez de tomber sur une page blanche avec “Error establishing a database connection”, votre site WordPress 6.9.4 n’est pas “cassé” au hasard : il n’arrive tout simplement plus à parler à sa base de données.

Le problème

Le message exact ressemble généralement à ceci :

Error establishing a database connection

Vous le voyez :

Sur le front-end (la partie publique) : la page d’accueil et toutes les pages affichent l’erreur.
Dans l’admin (/wp-admin/) : souvent la même erreur, parfois une variante du type “One or more database tables are unavailable”.
Sur WP-Cron (tâches planifiées) : vous ne le voyez pas forcément, mais les tâches ne s’exécutent plus.
Sur la REST API (/wp-json/) : les requêtes peuvent répondre en 500 si WordPress ne peut pas initialiser sa connexion DB.

Les circonstances typiques que j’ai le plus souvent rencontrées en dépannage :

Juste après une migration (changement d’hébergeur, de domaine, de serveur).
Après une mise à jour “automatique” côté hébergeur (PHP, MySQL/MariaDB, changement d’infrastructure).
Après avoir modifié wp-config.php (souvent pour activer le debug, changer le préfixe, ou ajouter des constantes de cache).
Après un pic de trafic (newsletter, pub, article viral) : DB saturée, trop de connexions simultanées.

À la fin, vous saurez faire trois choses concrètes : identifier la cause exacte, restaurer l’accès à la base sans aggraver la situation, et mettre en place des garde-fous pour éviter que ça revienne.

Résumé rapide

Dans 70% des cas : mauvais identifiants DB dans wp-config.php (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST).
Si les identifiants sont bons : serveur MySQL/MariaDB indisponible (panne, saturation, limite de connexions, incident hébergeur).
Si MySQL répond : tables manquantes/corrompues ou préfixe ($table_prefix) incohérent après migration.
Diagnostic rapide : testez la connexion DB en “hors WordPress” via un mini script PHP, puis vérifiez les logs.
Ne “réparez” pas au hasard : une mauvaise manipulation (préfixe, réparation, import) peut empirer la corruption.
Après correction : vérifiez front, admin, cron, et purgez les caches (plugin + serveur + CDN).

Les symptômes

Le symptôme principal est évident : l’erreur s’affiche partout. Mais selon le contexte, vous pouvez voir aussi :

Erreur 500 au lieu du message WordPress, si le serveur masque les erreurs ou si PHP plante avant l’affichage.
Écran blanc (WSOD) si un plugin de cache/optimisation intercepte la sortie.
Admin inaccessible : impossible de se connecter, redirections étranges, cookies invalides (WordPress ne peut plus lire/écrire les sessions et options).
API/AJAX cassés : l’éditeur de blocs, Elementor, Divi 5, Avada/Fusion peuvent afficher “Une erreur est survenue” car ils utilisent des appels AJAX/REST qui dépendent de la DB.
Emails qui ne partent plus (formulaires) : beaucoup de plugins stockent des files en DB.
Logs serveur : “Too many connections”, “Access denied for user”, “Unknown database”, “MySQL server has gone away”.

Table de diagnostic rapide (celle que j’utilise en premier sur site en production) :

Symptôme	Cause probable	Vérification	Solution
Erreur immédiate après migration	DB_HOST/DB_NAME faux, utilisateur non créé	Comparer `wp-config.php` et panneau hébergeur	Solution 1
Erreur aléatoire (revient/disparaît)	MySQL saturé / limite connexions	Logs “Too many connections”, monitoring hébergeur	Solution 2
Message “tables unavailable”	Tables corrompues ou préfixe incorrect	phpMyAdmin : tables absentes, préfixe différent	Solution 3
Front KO, admin parfois OK	Cache ou couche proxy/CDN	Purger caches, bypass CDN	Section “Si ça ne marche toujours pas”

Pourquoi ça arrive

Explication simple (débutants)

WordPress stocke presque tout dans une base de données : vos articles, pages, réglages, utilisateurs, menus, et une partie des données de plugins. Quand WordPress se charge, il lit wp-config.php pour savoir où est la base et avec quels identifiants s’y connecter. Si la connexion échoue, WordPress ne peut rien afficher.

Explication technique (intermédiaires/pros)

Au chargement, WordPress initialise l’objet $wpdb (la couche d’accès DB). La connexion est tentée via l’extension MySQLi (ou un driver compatible) en utilisant les constantes DB_HOST, DB_USER, DB_PASSWORD, DB_NAME. Si l’auth échoue, si le serveur ne répond pas, ou si la DB existe mais que les tables attendues n’existent pas (mauvais préfixe / tables corrompues), WordPress stoppe et affiche ce message.

Les causes, du plus fréquent au plus rare :

Identifiants DB erronés (ou DB_HOST incorrect après migration).
Serveur MySQL/MariaDB indisponible (panne, redémarrage, saturation, limite de connexions).
Base/tables incohérentes : préfixe $table_prefix différent, tables manquantes, corruption après crash disque, import incomplet.
Plus rare : DNS (DB_HOST en nom de domaine qui ne résout plus), pare-feu, droits SQL retirés, ou stockage plein (DB ne peut plus écrire).

Prérequis avant de commencer

Sauvegarde : au minimum, copiez wp-config.php et faites un export de la DB si elle est accessible (phpMyAdmin / WP-CLI). Ne testez pas “des réparations” sans filet.
Environnement de test : si possible, reproduisez sur une copie (staging). Sur un site à trafic, j’ai vu des tentatives de réparation aggraver la corruption.
Versions : WordPress 6.9.4 et PHP 8.1+ (recommandé). Une version PHP trop ancienne peut déclencher d’autres erreurs, mais ne cause pas directement ce message.
Accès : FTP/SFTP ou gestionnaire de fichiers, et idéalement l’accès au panneau d’hébergement (bases de données, logs, services).
Outils utiles (quand l’admin redevient accessible) :
- Query Monitor (diagnostic requêtes, erreurs PHP, HTTP).
- Health Check & Troubleshooting (mode dépannage sans impacter les visiteurs).

Pour le debug, la référence officielle : Debug WordPress (WP_DEBUG).

Solution 1 : Corriger les identifiants MySQL dans wp-config.php (cas le plus fréquent)

Quand l’erreur apparaît juste après une migration ou une modification de fichier, je commence toujours par là. Une seule lettre fausse dans DB_HOST suffit.

Où agir (très concret)

Fichier : wp-config.php à la racine de WordPress (au même niveau que wp-settings.php).
Accès : via SFTP/FTP ou gestionnaire de fichiers de l’hébergeur.
Sauvegardez le fichier avant de l’éditer (copie locale).

Ce qui casse souvent (AVANT)

Exemples réalistes que je vois régulièrement :

<?php
// Mauvais exemple : identifiants erronés (souvent après migration ou copier-coller)
define( 'DB_NAME', 'wordpress_prod' );
define( 'DB_USER', 'root' ); // Sur un hébergement mutualisé, "root" ne marche presque jamais
define( 'DB_PASSWORD', 'motdepasse' );
define( 'DB_HOST', 'localhost:3307' ); // Port inventé / incorrect

$table_prefix = 'wp_';

Autre cas très fréquent : DB_HOST doit être un nom fourni par l’hébergeur (pas localhost), par exemple mysql123.hosting.tld.

La version corrigée (APRÈS)

Vous devez recopier exactement les valeurs visibles dans votre panneau d’hébergement (section “Bases de données”).

<?php
// Bon exemple : valeurs à récupérer dans le panneau de l’hébergeur
define( 'DB_NAME', 'u123456_wp' );
define( 'DB_USER', 'u123456_wpuser' );
define( 'DB_PASSWORD', 'IciUnMotDePasseFortEtExact' );

// "localhost" est correct sur beaucoup d’hébergeurs, mais pas tous.
// Si votre hébergeur indique un hôte MySQL spécifique, utilisez-le.
define( 'DB_HOST', 'localhost' );

$table_prefix = 'wp_';

Pourquoi ça corrige le problème

WordPress ne “devine” rien. Il utilise ces constantes pour ouvrir une connexion au serveur MySQL/MariaDB. Si DB_NAME n’existe pas, MySQL renvoie “Unknown database”. Si l’utilisateur est mauvais, vous aurez “Access denied for user”. Dans les deux cas, WordPress n’a pas de plan B.

Diagnostic fiable : test de connexion hors WordPress

Quand je veux être certain que le problème vient des identifiants (et pas d’un plugin), je crée un fichier de test temporaire. Faites-le uniquement si vous comprenez le risque : ce fichier peut exposer des infos si vous le laissez en place.

Créez un fichier db-test.php à la racine du site (même dossier que wp-config.php).
Supprimez-le juste après.

<?php
// Fichier temporaire : db-test.php
// Objectif : vérifier que PHP peut se connecter à MySQL avec les identifiants de wp-config.php.
// IMPORTANT : supprimez ce fichier après le test.

require __DIR__ . '/wp-config.php';

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

try {
	$mysqli = new mysqli(DB_HOST, DB_USER, DB_PASSWORD, DB_NAME);
	$mysqli->set_charset('utf8mb4');

	echo 'Connexion DB OK. Serveur : ' . $mysqli->host_info;
} catch (Throwable $e) {
	http_response_code(500);
	echo 'Connexion DB KO : ' . $e->getMessage();
}

Si vous obtenez “Connexion DB OK”, vos identifiants sont bons et il faut passer à la solution 2 ou 3. Si vous obtenez “Access denied” ou “Unknown database”, vous avez votre cause.

Référence PHP (MySQLi) : PHP manual: mysqli.

Cas particulier : DB_HOST avec port ou socket

Certaines plateformes demandent :

Un port : define('DB_HOST', '127.0.0.1:3306');
Un socket (plus rare en mutualisé) : l’hébergeur vous donne un chemin de socket.

Ne l’inventez pas. Prenez la valeur exacte fournie par l’hébergeur.

Solution 2 : MySQL/MariaDB indisponible (ou saturé) côté hébergeur

Quand l’erreur apparaît “sans rien toucher” ou qu’elle va et vient, c’est souvent MySQL/MariaDB. J’ai souvent croisé ce bug sur des sites avec un cache de page désactivé, des requêtes lourdes (plugins de stats), ou un pic de trafic.

Ce que vous cherchez (signaux)

Le site tombe puis revient 2 minutes après.
Les emails “site down” de votre monitoring se multiplient.
Les logs indiquent “Too many connections” ou “MySQL server has gone away”.
Votre hébergeur affiche un incident sur sa page de statut.

Diagnostic : vérifier si MySQL répond vraiment

Si vous avez accès à WP-CLI, c’est propre et rapide. Sinon, utilisez le script db-test.php de la solution 1.

Avec WP-CLI (Solution avancée mais très efficace)

Connectez-vous en SSH, placez-vous dans le dossier du site, puis :

wp --info
wp db check

Si wp db check ne peut pas se connecter, WP-CLI vous le dira clairement. Documentation WP-CLI : WP-CLI db commands.

Résolution : actions concrètes côté hébergement

Redémarrer le service DB (VPS/dédié) : si vous administrez votre serveur. En mutualisé, c’est l’hébergeur.
Vérifier les limites : nombre de connexions simultanées, CPU, RAM, I/O disque.
Vérifier l’espace disque : si le disque est plein, MySQL peut refuser d’écrire et se comporter de façon erratique.
Activer/renforcer le cache : un cache de page réduit drastiquement la pression DB.

Si vous administrez un serveur Linux, voici les commandes typiques (à adapter à votre distribution). Ne les exécutez pas si vous n’êtes pas à l’aise :

# Vérifier l’état du service (Debian/Ubuntu)
sudo systemctl status mysql

# Redémarrer (attention : impact production)
sudo systemctl restart mysql

# Voir les erreurs récentes
sudo journalctl -u mysql --since "30 min ago"

Cas fréquent : “Too many connections” (trop de connexions)

Ça arrive quand trop de requêtes arrivent en même temps. Les page builders (Divi 5, Elementor, Avada) ne causent pas ce souci “par magie”, mais ils peuvent amplifier la charge si :

le cache est absent,
des plugins font des requêtes lourdes,
beaucoup de visiteurs chargent des pages non mises en cache (pages personnalisées, e-commerce, espace membre).

Ce que je fais en pratique :

Activer un cache de page côté serveur (LiteSpeed Cache / Nginx FastCGI cache / Varnish selon stack).
Mettre un CDN si le trafic est mondial.
Réduire les plugins “stats temps réel” qui tapent la DB à chaque hit.
Augmenter la RAM du serveur si c’est un VPS sous-dimensionné.

Référence WordPress (côté perf) : Performance (Advanced Administration).

Solution 3 : Base corrompue, préfixe incohérent ou tables manquantes

Quand les identifiants sont bons et que MySQL répond, mais que WordPress échoue quand même, je vérifie les tables. Après une migration, j’ai souvent vu un $table_prefix modifié par erreur, ou un import partiel (upload interrompu).

Cas A : préfixe de tables incorrect

WordPress utilise un préfixe (par défaut wp_) pour nommer ses tables : wp_options, wp_posts, etc. Le préfixe est défini dans wp-config.php via $table_prefix.

Si votre base contient des tables abc123_posts mais que $table_prefix vaut wp_, WordPress cherche wp_options… qui n’existe pas. Résultat : erreurs DB et parfois le message de connexion.

Vérification

Ouvrez phpMyAdmin (ou Adminer) via votre hébergeur.
Sélectionnez la base.
Regardez le nom des tables : quel est le préfixe réel ?

AVANT (cassé)

<?php
// Mauvais exemple : le préfixe ne correspond pas aux tables réellement présentes
$table_prefix = 'wp_';

APRÈS (corrigé)

<?php
// Bon exemple : le préfixe correspond aux tables de la base (ex : abc123_)
$table_prefix = 'abc123_';

Attention : ne “changez pas” le préfixe pour faire de la sécurité si vous ne savez pas exactement ce que vous faites. Il faut aussi mettre à jour des références dans la DB (options, usermeta). Ici on parle de réaligner WordPress sur l’existant.

Cas B : tables corrompues (réparation)

Si MySQL a subi un crash, ou si le disque a eu un souci, certaines tables peuvent être marquées “crashed”. WordPress propose un mode de réparation.

Activer la réparation (temporaire)

Dans wp-config.php, ajoutez :

<?php
// Active l’outil de réparation de la base WordPress.
// IMPORTANT : à retirer immédiatement après usage (risque d’accès non authentifié).
define( 'WP_ALLOW_REPAIR', true );

Ensuite, allez sur :

https://votre-domaine.tld/wp-admin/maint/repair.php

Choisissez “Réparer la base de données” (ou “Réparer et optimiser”). Puis supprimez la constante du fichier wp-config.php.

Référence officielle : Repairing Database.

Pourquoi il faut retirer WP_ALLOW_REPAIR

Cette page peut être accessible sans connexion admin selon les configurations. Laisser WP_ALLOW_REPAIR activé est un risque inutile.

Cas C : import incomplet / tables manquantes

Symptômes typiques :

Vous avez importé un fichier SQL mais l’upload a échoué.
Il manque des tables clés : _options, _posts, _users.

Dans ce cas, la “réparation” ne suffit pas. Il faut :

réimporter correctement la sauvegarde SQL,
ou restaurer depuis un snapshot,
ou demander à l’hébergeur une restauration DB à une date donnée.

Si vous avez WP-CLI et une sauvegarde SQL sur le serveur :

# Exemple : importer une sauvegarde (attention : écrase des données)
wp db import sauvegarde.sql

Je le répète parce que je l’ai vu trop souvent : ne faites pas d’import sur production sans être certain du fichier et sans sauvegarde.

Vérifications après correction

Une fois la cause corrigée, je valide toujours dans cet ordre :

Front-end : page d’accueil, une page, un article, une page builder (Divi/Elementor/Avada) si vous en avez.
Admin : connexion, chargement de “Réglages > Général”, puis “Extensions”.
Écriture DB : modifiez un brouillon et enregistrez. Si l’enregistrement échoue, la connexion est peut-être instable.
REST API : ouvrez /wp-json/. Vous devez obtenir une réponse JSON, pas une erreur.
Tâches cron : si vous utilisez un plugin de cron, vérifiez qu’il reprend. Sinon, surveillez les emails/automations.

Puis, purgez les caches :

cache plugin (si accessible),
cache serveur (si votre hébergeur en a un),
CDN (Cloudflare ou autre),
cache navigateur (test en navigation privée).

Si ça ne marche toujours pas

Quand la cause n’est pas évidente, je déroule une procédure fixe. Elle évite de partir dans tous les sens.

Étape 1 : activer les logs WordPress (sans afficher aux visiteurs)

Dans wp-config.php (avant la ligne “That’s all, stop editing!”), ajoutez :

<?php
// Debug recommandé en production : loguer sans afficher.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Le fichier de log est généralement : wp-content/debug.log. Référence : Debug WordPress.

Étape 2 : vérifier les logs serveur (PHP/MySQL)

Log d’erreurs PHP (souvent accessible dans le panneau hébergeur).
Log MySQL/MariaDB (sur VPS/dédié).
Recherchez : “Access denied”, “Unknown database”, “Too many connections”, “server has gone away”.

Étape 3 : isoler cache/proxy/CDN

J’ai déjà vu Cloudflare (ou un cache serveur) continuer à servir une page d’erreur alors que la DB était revenue.

Désactivez temporairement le “cache everything” si vous l’avez.
Purge “Everything” sur le CDN.
Testez en ajoutant un paramètre : ?nocache=1 (selon cache, ça peut bypass).

Étape 4 : conflit plugin/thème (rare pour ce message, mais possible)

Un plugin ne “casse” pas la connexion DB au sens strict, mais il peut :

épuiser la mémoire,
créer des boucles de requêtes,
saturer MySQL,
ou provoquer des timeouts.

Si vous récupérez l’accès admin, utilisez Health Check en mode dépannage. Sinon, renommez temporairement :

wp-content/plugins en plugins.off (désactive tous les plugins)
et/ou forcez un thème par défaut en renommant le thème actif (ou en modifiant l’option dans la DB si accessible).

Étape 5 : vérifier les permaliens (rewrite rules)

Ça ne cause pas ce message, mais après une panne DB, vous pouvez confondre plusieurs problèmes. Si l’admin revient, allez dans “Réglages > Permaliens” et cliquez “Enregistrer” (sans changer). Ça régénère les règles de réécriture.

Étape 6 : vérifier PHP 8.1+ et la mémoire

Une DB instable + une mémoire PHP trop faible peut donner un cocktail d’erreurs. Vérifiez votre version PHP et la mémoire dans “Outils > Santé du site”. Référence : WordPress & PHP.

Pièges et erreurs courantes

Symptôme / erreur	Cause probable	Solution recommandée
Vous modifiez `wp-config.php` et le site passe en erreur 500	Point-virgule oublié, guillemets cassés, copier-coller “smart quotes”	Revenir au fichier sauvegardé, éditer avec un éditeur simple, vérifier la syntaxe
“Access denied for user …”	DB_USER/DB_PASSWORD faux, ou privilèges SQL retirés	Solution 1 + vérifier les droits de l’utilisateur DB dans le panneau hébergeur
“Unknown database”	DB_NAME faux ou base supprimée	Solution 1, recréer la base si nécessaire puis restaurer un dump
Erreur qui disparaît après refresh puis revient	MySQL saturé / limite connexions	Solution 2, activer cache, réduire requêtes, upgrader hébergement
Vous avez “réparé” mais ça revient	Corruption liée au stockage (disque, I/O) ou crash récurrent	Solution 3 + diagnostic serveur (SMART disque, logs), restauration snapshot
Vous avez collé un snippet trouvé sur un vieux tutoriel	Constantes ajoutées au mauvais endroit ou fichier cassé	Supprimer le snippet, revenir à une version propre, puis réappliquer proprement
Vous testez directement sur production	Absence de staging/sauvegarde	Cloner en staging, valider, puis déployer

Erreurs “humaines” que je vois très souvent :

Copier le code après “That’s all, stop editing!” dans wp-config.php : WordPress peut ignorer certaines constantes ou vous créer des effets de bord.
Oublier de supprimer db-test.php ou WP_ALLOW_REPAIR après usage.
Confondre DB_HOST et l’URL du site : ce n’est pas votre domaine, c’est l’hôte MySQL.
Oublier de purger le cache et croire que “rien n’a changé”.

Variante / alternative

Méthode sans code (quand vous avez accès au panneau hébergeur)

Dans le panneau d’hébergement : ouvrez “Bases de données”.
Vérifiez : nom de base, utilisateur, mot de passe, hôte.
Utilisez la fonction “Réparer la base” si elle existe (certains hébergeurs la proposent côté MySQL).
Restaurez une sauvegarde “1 clic” si vous avez un backup automatique (souvent le plus rapide).

Méthode plus avancée (développeurs) : check DB + repair via WP-CLI

Si WP-CLI est disponible, c’est mon approche préférée :

# Vérifie l’intégrité des tables (selon support)
wp db check

# Répare (si supporté par le moteur de stockage)
wp db repair

Note : selon l’hébergeur, la commande “repair” peut être limitée. Document officiel : WP-CLI: db.

Éviter ce problème à l’avenir

Automatisez les sauvegardes (fichiers + DB) et testez une restauration une fois. Une sauvegarde non testée est une hypothèse.
Faites vos migrations proprement : export SQL complet, import sans timeout (WP-CLI ou outil hébergeur), puis vérification du préfixe.
Évitez d’éditer wp-config.php en direct sans copie. Utilisez un éditeur qui n’altère pas les guillemets.
Mettez du cache : sur des sites à trafic, c’est souvent la différence entre “MySQL tient” et “MySQL tombe”.
Surveillez : uptime monitoring + alertes (mail/Slack). Vous voulez savoir avant vos lecteurs.
Gardez PHP à jour (8.1+) et surveillez la RAM. Référence : PHP supported versions.

Petit garde-fou utile : si vous ajoutez des constantes de debug, faites-le proprement et réversible. Exemple (à mettre dans wp-config.php, puis à retirer après incident) :

<?php
// Bloc debug temporaire : à retirer après résolution
if ( ! defined( 'WP_DEBUG' ) ) {
	define( 'WP_DEBUG', true );
}
if ( ! defined( 'WP_DEBUG_LOG' ) ) {
	define( 'WP_DEBUG_LOG', true );
}
if ( ! defined( 'WP_DEBUG_DISPLAY' ) ) {
	define( 'WP_DEBUG_DISPLAY', false );
}

Ressources

Questions fréquentes

Est-ce qu’un plugin peut provoquer “Error establishing a database connection” ?

Indirectement, oui. Un plugin peut déclencher trop de requêtes, saturer MySQL, ou provoquer des timeouts. Mais si vos identifiants sont faux, aucun plugin n’y changera quoi que ce soit : commencez par wp-config.php.

Pourquoi ça arrive souvent après une migration ?

Parce que la migration change presque toujours au moins un paramètre : nom de base, utilisateur, mot de passe, ou hôte MySQL. Le préfixe $table_prefix peut aussi diverger si vous importez une DB d’un autre site.

Je suis sur Divi 5 / Elementor / Avada : est-ce différent ?

Non pour la cause principale : ces outils dépendent de WordPress, donc de la DB. Par contre, ils rendent le symptôme plus visible via AJAX/REST (éditeur qui ne charge plus, modules qui “tournent” dans le vide).

Est-ce que je peux réparer la DB sans accès admin ?

Oui, via WP_ALLOW_REPAIR (solution 3). Mais activez-le uniquement le temps nécessaire, puis retirez-le immédiatement.

Le script db-test.php est-il dangereux ?

Il peut l’être si vous le laissez en place. Il affiche des informations d’erreur et prouve qu’un fichier exécutable existe à la racine. Utilisez-le 2 minutes, puis supprimez-le.

Que faire si phpMyAdmin n’est pas accessible ?

Contactez l’hébergeur : sans outil d’accès DB (phpMyAdmin/Adminer/WP-CLI), vous êtes bloqué pour vérifier tables et imports. Sur un VPS, installez un accès sécurisé ou utilisez WP-CLI.

J’ai “Access denied”, mais je suis sûr du mot de passe

Vérifiez que l’utilisateur DB a bien des privilèges sur la base (SELECT/INSERT/UPDATE/DELETE). J’ai déjà vu des utilisateurs DB recréés sans droits après une restauration partielle côté hébergeur.

Est-ce que changer DB_HOST de localhost à 127.0.0.1 peut aider ?

Parfois, oui, selon la configuration réseau et DNS du serveur. Mais ne testez pas au hasard : votre hébergeur doit vous donner la valeur correcte. Sur certains systèmes, localhost utilise un socket, et 127.0.0.1 force TCP.

Je n’ai rien touché, pourquoi mon site tombe ?

Les causes les plus fréquentes dans ce scénario : incident hébergeur, saturation MySQL, disque plein, ou pic de trafic. La solution 2 est celle qui correspond le mieux.

Après réparation, mon site remarche mais il est lent

Ça arrive quand MySQL est encore sous pression. Activez un cache de page, vérifiez les requêtes lourdes (Query Monitor), et regardez si le serveur limite CPU/RAM.