# Bascule d’hébergeur ratée : la connexion à la base de données coupée net

> Les fichiers sont bien arrivés sur le nouveau serveur, mais le site affiche une erreur de connexion à la base de données dès la première visite après la bascule.

- Auteur : WordPress Développement
- Publié le : 2021-06-03
- Mis à jour le : 2021-06-03
- Catégorie : Hébergement & serveurs
- URL : https://www.wpmoderne.fr/hebergement/bascule-hebergeur-ratee-connexion-base-donnees-coupee/

## L’essentiel

- Une erreur de connexion base de données pointe rarement vers la base elle-même
- Les identifiants et l'hôte MySQL changent presque toujours d'un hébergeur à l'autre
- wp-config.php doit être vérifié en dernier, jamais copié tel quel

« Error establishing a database connection ». C'est l'unique message affiché par le site quelques minutes après la fin du transfert de fichiers vers un nouvel hébergeur, alors que la migration des fichiers eux-mêmes s'était déroulée sans le moindre incident, chaque page et chaque média retrouvés à l'identique sur le nouveau serveur.

Ce message générique de WordPress recouvre en réalité plusieurs causes possibles, et une partie du travail de diagnostic consiste justement à éliminer méthodiquement celles qui ne s'appliquent pas, avant de trouver la bonne.

## Écarter d'abord l'hypothèse d'une base corrompue

Le premier réflexe, souvent erroné, consiste à craindre une corruption de la base de données pendant le transfert. Une connexion directe à MySQL depuis la ligne de commande du nouveau serveur a rapidement écarté cette piste : la base était bien présente, intégralement peuplée, et parfaitement interrogeable en dehors de WordPress.

```
mysql -u wp_user -p -h localhost wordpress_db -e "SHOW TABLES;"
```

Cette commande a renvoyé la liste complète des tables attendues, ce qui confirmait que le problème ne se situait ni dans l'intégrité des données, ni dans le service MySQL lui-même, mais quelque part entre WordPress et cette base pourtant bien vivante.

## La vraie cause : des identifiants copiés tels quels

Le fichier `wp-config.php` avait été transféré à l'identique depuis l'ancien hébergeur, sans modification. Or, chaque hébergeur attribue ses propres identifiants de connexion à la base de données, et surtout, son propre nom d'hôte MySQL : `localhost` ne fonctionne pas partout de la même façon, certains hébergeurs mutualisés imposant un nom d'hôte spécifique, parfois une adresse IP interne dédiée.

> L'essentiel à retenir : Une erreur de connexion base de données pointe rarement vers la base elle-même ; Les identifiants et l'hôte MySQL changent presque toujours d'un hébergeur à l'autre ; wp-config.php doit être vérifié en dernier, jamais copié tel quel

```
// Ancien hébergeur
define( 'DB_NAME', 'ancien_wp_db' );
define( 'DB_USER', 'ancien_wp_user' );
define( 'DB_PASSWORD', 'ancien-mot-de-passe' );
define( 'DB_HOST', 'localhost' );

// Nouvel hébergeur, valeurs correctes
define( 'DB_NAME', 'nouveau_wp_db' );
define( 'DB_USER', 'nouveau_wp_user' );
define( 'DB_PASSWORD', 'nouveau-mot-de-passe' );
define( 'DB_HOST', 'mysql57.nouvel-hebergeur.net' );
```

Une fois ces quatre constantes corrigées avec les informations réellement fournies par le nouvel hébergeur, la connexion s'est rétablie immédiatement, sans qu'aucune autre modification n'ait été nécessaire sur le reste du site.

## Pourquoi cette erreur reste si fréquente lors d'une migration

La tentation de copier l'ensemble du site, `wp-config.php` inclus, sans distinguer ce qui doit changer d'un hébergeur à l'autre, explique la fréquence de cet incident. Ce fichier contient à la fois des réglages qui doivent rester identiques (préfixe des tables, clés de sécurité, constantes de débogage) et des réglages qui doivent impérativement être adaptés à chaque nouvel environnement.

- Nom d'hôte de la base de données, presque toujours spécifique à chaque hébergeur
- Identifiants de connexion, nom de la base et utilisateur associé
- Éventuel port MySQL non standard sur certaines offres

> Ne jamais considérer `wp-config.php` comme un fichier à transférer tel quel lors d'une migration d'hébergeur. Il mérite une vérification ligne par ligne, en particulier les quatre constantes liées à la base de données, avant même de songer à ouvrir le site dans un navigateur.

## Une vérification à ajouter systématiquement à la procédure

Depuis cet incident, l'équipe a ajouté une étape explicite à sa checklist de migration : avant toute ouverture du site après transfert, une connexion manuelle à la base via la ligne de commande MySQL, avec les nouveaux identifiants, permet de confirmer que la connexion fonctionne indépendamment de WordPress. Si cette connexion échoue déjà à ce stade, le problème se situe clairement du côté des identifiants ou du réseau, avant même d'incriminer WordPress.

## Ce qu'il faut retenir de ce dossier

Une erreur de connexion à la base de données après une migration n'est presque jamais un problème de données corrompues : c'est, dans l'immense majorité des cas, un problème d'identifiants ou de nom d'hôte non mis à jour dans `wp-config.php`. Vérifier cette hypothèse en premier, avant d'explorer des pistes plus complexes, permet de résoudre l'incident en quelques minutes plutôt qu'en plusieurs heures.