Intermédiaire ⏱ 13 min Mis à jour le 29 juillet 2026

Migrer un site web vers un nouvel hébergement sans coupure

Changer d'hébergement fait peur : et si le site tombait ? Avec la bonne méthode — préparer, transférer, tester, puis basculer le DNS — la migration se fait sans coupure visible.

La règle d’or pour migrer un site web sans coupure

Migrer un site web sans interruption visible demande de préparer entièrement le nouvel hébergement avant de modifier le DNS. L’ancien serveur doit rester opérationnel jusqu’à ce que le nouveau ait été transféré, configuré et testé.

L’ordre à respecter est simple :

Inventaire
   ↓
Sauvegarde complète
   ↓
Transfert des fichiers et de la base
   ↓
Configuration du nouvel hébergement
   ↓
Tests
   ↓
Synchronisation finale
   ↓
Bascule DNS
   ↓
Surveillance

Le DNS doit être modifié en dernier. Ne résiliez jamais l’ancien hébergement avant la fin de la propagation et des vérifications.

Pour un site statique, cette méthode permet généralement une transition très fluide. Pour un site dynamique — boutique, forum, espace membre ou WordPress actif — une courte période de lecture seule ou de maintenance peut être nécessaire afin d’éviter que de nouvelles données soient enregistrées uniquement sur l’ancien serveur.

Une migration « sans coupure » ne signifie pas qu’aucune précaution n’est nécessaire. L’objectif est de maintenir le site accessible tout en évitant les pertes de données pendant la transition.

Préparer la migration

Commencez par établir un inventaire précis de ce qui doit être transféré.

Éléments du site

Notez notamment :

le dossier racine du site ;
les fichiers envoyés par les utilisateurs ;
la base de données ;
les fichiers de configuration ;
les tâches cron ;
les services systemd ;
les redirections ;
les sous-domaines ;
les certificats ;
les comptes e-mail ;
les règles de pare-feu.

Relevez également les versions utilisées :

CMS et extensions
PHP, Node.js ou Python
MySQL, MariaDB ou PostgreSQL
Nginx ou Apache
Modules et bibliothèques

Une différence de version peut provoquer une erreur même si les fichiers ont été copiés correctement.

Réaliser une sauvegarde complète

Avant toute modification, sauvegardez :

Fichiers du site
Base de données
Configurations
Secrets
Tâches planifiées
Liste des dépendances

Des sauvegardes automatiques sont incluses pour vous aider à restaurer. Conservez aussi vos propres exports réguliers : vous restez responsable de vos données.

Stockez au moins une copie en dehors des deux hébergements concernés. Le guide sur la stratégie de sauvegarde serveur détaille la règle 3-2-1 et les tests de restauration.

Transférer les fichiers vers le nouvel hébergement

Vous pouvez utiliser SFTP, SCP ou rsync selon vos accès.

Avec rsync depuis l’ancien serveur :

rsync -avz \
  --progress \
  /var/www/exemple.fr/ \
  utilisateur@NOUVEAU_SERVEUR:/var/www/exemple.fr/

Avec un port SSH personnalisé :

rsync -avz \
  --progress \
  -e "ssh -p 2222" \
  /var/www/exemple.fr/ \
  utilisateur@NOUVEAU_SERVEUR:/var/www/exemple.fr/

Le / final après le dossier source est important : il demande à rsync de copier son contenu.

Pour un site contenant des caches ou dépendances régénérables, vous pouvez exclure certains dossiers :

rsync -avz \
  --exclude=".git/" \
  --exclude="node_modules/" \
  --exclude="cache/" \
  /var/www/exemple.fr/ \
  utilisateur@NOUVEAU_SERVEUR:/var/www/exemple.fr/

Après le transfert, vérifiez le propriétaire et les permissions :

sudo chown -R utilisateur:www-data /var/www/exemple.fr

find /var/www/exemple.fr \
  -type d \
  -exec chmod 755 {} \;

find /var/www/exemple.fr \
  -type f \
  -exec chmod 644 {} \;

Ces valeurs sont des bases courantes, à adapter à l’application et à l’utilisateur qui exécute le service.

Le guide pour transférer des fichiers vers un VPS présente également SCP, SFTP et rsync.

Migrer la base de données

Exporter une base MySQL ou MariaDB

Depuis l’ancien hébergement :

mysqldump \
  --single-transaction \
  --routines \
  --triggers \
  -u ancien_user \
  -p \
  ancienne_base \
  | gzip > site.sql.gz

Le mot de passe est demandé de manière interactive. Ne l’ajoutez pas directement dans la commande.

Transférez ensuite l’archive :

scp site.sql.gz \
  utilisateur@NOUVEAU_SERVEUR:/tmp/

Créer la base sur le nouveau serveur

Connectez-vous au moteur :

sudo mysql

Créez la base et un utilisateur dédié :

CREATE DATABASE nouvelle_base
  CHARACTER SET utf8mb4
  COLLATE utf8mb4_unicode_ci;

CREATE USER 'nouveau_user'@'localhost'
  IDENTIFIED BY 'REMPLACEZ_PAR_UN_SECRET_FORT';

GRANT ALL PRIVILEGES
  ON nouvelle_base.*
  TO 'nouveau_user'@'localhost';

FLUSH PRIVILEGES;
EXIT;

Importez les données :

gunzip -c /tmp/site.sql.gz \
  | mysql \
      -u nouveau_user \
      -p \
      nouvelle_base

Vérifiez que les tables existent :

mysql \
  -u nouveau_user \
  -p \
  -e "SHOW TABLES;" \
  nouvelle_base

Ne placez jamais les identifiants de base de données dans un script public, l’historique Git, une capture d’écran ou un ticket de support non sécurisé.

Reconfigurer le site

Le nouvel environnement possède généralement de nouveaux identifiants, chemins ou ports.

Pour WordPress, adaptez wp-config.php :

define( 'DB_NAME', 'nouvelle_base' );
define( 'DB_USER', 'nouveau_user' );
define( 'DB_PASSWORD', 'REMPLACEZ_PAR_LE_SECRET' );
define( 'DB_HOST', 'localhost' );

Protégez ensuite le fichier :

chmod 640 /var/www/exemple.fr/wp-config.php

Vérifiez aussi :

le chemin du dossier public ;
les variables du fichier .env ;
les clés API ;
le serveur SMTP ;
les tâches cron ;
les permissions d’écriture ;
les fichiers envoyés par les utilisateurs ;
les connexions à des services externes.

Attention aux URL WordPress

Si le nom de domaine ne change pas, évitez de remplacer inutilement les URL dans la base.

S’il change, utilisez un outil compatible avec les données sérialisées de WordPress, comme WP-CLI :

wp search-replace \
  'https://ancien-domaine.fr' \
  'https://nouveau-domaine.fr' \
  --all-tables-with-prefix \
  --skip-columns=guid \
  --dry-run

Exécutez d’abord --dry-run. Si le résultat est correct, relancez sans cette option.

Une recherche-remplacement SQL classique peut endommager certaines données sérialisées.

Pour préparer un nouveau WordPress, consultez le guide pour héberger un site WordPress.

Tester avant de basculer le DNS

Le nouvel hébergement doit être testé avec le véritable nom de domaine avant la modification publique du DNS.

Utiliser le fichier `hosts`

Ajoutez temporairement sur votre ordinateur :

203.0.113.10 exemple.fr www.exemple.fr

Remplacez l’adresse fictive par l’IP du nouveau serveur.

Emplacements courants :

Windows : C:\Windows\System32\drivers\etc\hosts
Linux   : /etc/hosts
macOS   : /etc/hosts

Cette modification ne concerne que votre ordinateur. Le reste des visiteurs continue d’utiliser l’ancien hébergement.

Testez ensuite :

la page d’accueil ;
les pages internes ;
les images ;
les formulaires ;
la connexion ;
l’administration ;
la recherche ;
les envois d’e-mails ;
les tâches programmées ;
les écritures en base ;
les téléchargements.

Retirez l’entrée du fichier hosts après la migration.

Basculer le DNS proprement

Lorsque cela est possible, réduisez le TTL avant la migration. Cette modification doit être faite suffisamment en amont pour que l’ancien TTL ait le temps d’expirer.

Le guide pour relier un domaine à un VPS explique les enregistrements A, AAAA, CNAME et les serveurs de noms.

Juste avant la bascule d’un site dynamique :

activez une courte maintenance ou un mode lecture seule ;
effectuez un dernier export de la base ;
synchronisez les fichiers récemment modifiés ;
importez les dernières données ;
réalisez un test final ;
modifiez le DNS ;
rouvrez les écritures sur le nouveau serveur.

Modifiez ensuite l’enregistrement concerné :

Type : A
Nom  : @
Valeur : NOUVELLE_ADRESSE_IP

Vérifiez aussi www et les éventuels enregistrements AAAA.

La propagation n’est pas instantanée et aucun délai exact ne peut être garanti. Pendant cette période, certains visiteurs peuvent encore atteindre l’ancien serveur.

Conservez l’ancien serveur actif et fonctionnel pendant toute la période de cohabitation DNS.

Vérifier la migration après la bascule

Contrôlez la résolution :

dig +short exemple.fr
dig +short www.exemple.fr

Surveillez les logs Nginx :

sudo tail -f /var/log/nginx/access.log
sudo tail -f /var/log/nginx/error.log

Vérifiez également :

Erreurs HTTP
Formulaires
E-mails transactionnels
Tâches cron
Charge du serveur
Connexions à la base
Certificat HTTPS

Le certificat présent sur l’ancien hébergement ne suit pas automatiquement les fichiers. Installez ou renouvelez un certificat sur le nouveau serveur après que le domaine est correctement accessible.

Consultez le guide pour activer HTTPS avec Let’s Encrypt.

Ne résiliez pas immédiatement l’ancien hébergement. Conservez-le quelques jours, ou davantage selon les contraintes du projet, puis vérifiez qu’il ne reçoit plus de trafic utile avant sa suppression.

En résumé

Pour migrer un site web, préparez le nouvel hébergement avant de toucher au DNS.
Ne coupez jamais l’ancien serveur tant que le nouveau n’est pas validé.
Inventoriez les fichiers, bases, versions, e-mails, tâches cron et configurations.
Réalisez une sauvegarde complète indépendante avant la migration.
Transférez les fichiers avec SFTP, SCP ou rsync.
Vérifiez les propriétaires et permissions après la copie.
Exportez et importez la base avec les outils du moteur.
Ne placez jamais un mot de passe de base de données directement dans une commande ou un dépôt.
Reconfigurez les chemins, variables, accès SMTP et identifiants.
Pour WordPress, utilisez une méthode compatible avec les données sérialisées.
Testez le nouveau serveur via un domaine temporaire ou le fichier hosts.
Synchronisez une dernière fois les données dynamiques avant la bascule.
Modifiez le DNS uniquement lorsque le nouveau site fonctionne.
Gardez les deux serveurs actifs pendant la propagation.
Vérifiez HTTPS, les logs, les formulaires et les tâches planifiées.
Pour migrer un site web vers un hébergement en France conforme au RGPD, avec stockage NVMe, Anti-DDoS L3/L4/L7 inclus, panel de gestion et support francophone, découvrez l’offre hébergement web TalCloud.