Mon site sera-t-il indisponible pendant le transfert ?

Pour un site statique ou vitrine, la bascule peut passer inaperçue — l'ancien hébergeur sert les visiteurs jusqu'à ce que la copie testée prenne le relais. Pour un site qui accepte des commandes, des réservations ou des envois de fichiers, une courte fenêtre en lecture seule ou de maintenance pendant la synchronisation finale des données est souvent le prix honnête pour ne rien perdre ; ce que vous évitez, ce n'est pas une pause, c'est deux systèmes qui acceptent des données différentes en même temps.

Dois-je déplacer mes e-mails en même temps ?

Si les boîtes mail sont hébergées ailleurs, ne touchez pas aux enregistrements MX — le courrier entrant ne remarquera rien. Testez quand même les e-mails que votre site envoie : formulaires de contact, notifications de commande et de compte peuvent dépendre d'un service de messagerie local, d'identifiants SMTP, de règles de pare-feu ou d'une adresse IP d'envoi autorisée qui a changé avec l'hébergeur. Si les boîtes mail sont chez l'ancien hébergeur, traitez la messagerie comme une migration à part, avec une période de chevauchement.

Quand puis-je résilier mon ancien hébergement ?

Seulement après que le nouvel hébergeur a servi du trafic réel pendant quelques jours, avec des journaux propres et des formulaires, e-mails et fonctions vérifiés — et après une nouvelle sauvegarde du nouveau site plus une copie d'archive de l'ancien environnement. Ne vous fiez pas au seul journal d'accès de l'ancien hébergeur : un CDN peut masquer le trafic des visiteurs dans les journaux d'origine, et certains résolveurs servent des réponses DNS périmées au-delà du TTL. Résilier le jour même de la bascule est la façon classique de perdre des données et de servir des erreurs en même temps.

Comment changer d'hébergeur avec peu ou pas d'interruption ?

Changer d’hébergeur, c’est une copie, un test en parallèle et une bascule contrôlée — du trafic et des données. L’ancien hébergeur continue de servir les visiteurs pendant que vous montez et éprouvez le nouveau ; pour un site statique, la bascule peut même passer inaperçue. Un site qui accepte des commandes, des réservations, des envois de fichiers ou des commentaires demande un plan de plus que le site statique : comment les changements en direct restent cohérents tant que deux copies existent. Sautez ce plan et vous obtenez l’échec le plus laid de la migration — des visiteurs qui écrivent dans l’ancienne base de données pendant que d’autres écrivent dans la nouvelle, sans aucun moyen propre de fusionner ensuite.

Faites l’inventaire avant de copier

Listez ce qui doit réellement déménager — les surprises se cachent dans la seconde moitié :

Les fichiers du site et les bases de données (moteur, version, jeu de caractères), avec leurs tailles ; l’environnement d’exécution dont le site a besoin (version du langage, extensions, réglages).
Les règles et la disposition du serveur : .htaccess/réécritures et redirections, racine des documents, propriété et droits des fichiers.
Les pièces mobiles : tâches planifiées, files d’attente et processus de traitement, sessions, caches d’objets, stockage temporaire.
Les e-mails sortants : le site envoie-t-il via un service de messagerie local ou via SMTP — et l’adresse IP du nouvel hébergeur sera-t-elle encore autorisée par votre enregistrement SPF et votre DNS inversé ?
Les intégrations qui pointent vers le site : webhooks et URL de rappel de paiement/connexion, services externes avec listes d’adresses IP autorisées, configuration CDN/proxy/WAF.
Recherche et mesure : vérification dans la Search Console, robots.txt et tout blocage d’exploration ou d’indexation, configuration des statistiques et du signalement d’erreurs.
TLS : comment exactement les certificats seront émis chez le nouvel hébergeur (voir plus bas).
L’hébergement de la messagerie : boîtes mail chez le même hébergeur, ou ailleurs ? Cette réponse détermine une bonne partie de votre risque.
Où le DNS est-il géré ? — Un changement d’hébergeur n’oblige pas à déplacer le DNS ni le domaine (c’est une autre opération).

Faites une nouvelle sauvegarde vérifiée avant de commencer, et notez les valeurs DNS actuelles — c’est votre plan de retour.

Montez et testez la copie — avant tout changement DNS

Transférez les fichiers, importez la base de données depuis une exportation cohérente, puis testez sans toucher au DNS public :

L’astuce du fichier hosts : pointez seulement votre propre ordinateur vers le nouveau serveur en y ajoutant son adresse IP pour votre domaine — l’application voit alors son vrai nom d’hôte, ce qui garde cookies, redirections et URL absolues honnêtes. Connaissez ses limites : elle ne reproduit ni le DNS public, ni le routage CDN, ni l’émission de certificats, ni les rappels de services tiers.
Les noms d’hôte temporaires fonctionnent aussi, mais ils changent ce que le site voit — domaines de cookies, URL canoniques, rappels de paiement et de connexion, URL absolues générées par le CMS — ; certains échecs (et certains succès) sont donc des artefacts du nom de test. Les CMS qui stockent leur URL dans la base de données peuvent demander un traitement propre à l’application dans les deux cas.
Cliquez à travers les pages, formulaires, connexions, envois de fichiers ; surveillez la console du navigateur pour les erreurs ; vérifiez les pièges de déploiement — chemins, casse, permissions.

Réglez le HTTPS avant la bascule, délibérément. Comment ? Cela dépend de la méthode de validation de l’hébergeur : la validation par DNS peut généralement émettre le certificat à l’avance ; la validation par HTTP ne peut parfois aboutir qu’une fois que le domaine atteint réellement le nouvel hébergeur. Ne partez pas du principe que l’émission est instantanée — convenez de la procédure avec le nouvel hébergeur, couvrez tous les noms d’hôte (apex, www, sous-domaines), et vérifiez que le renouvellement automatique fonctionne après le déménagement.

Décidez comment gérer les données en direct

Pour un site statique ou vitrine sans aucune donnée créée par les visiteurs, une dernière synchronisation des fichiers peu avant la bascule suffit. Pour tout ce qui reçoit des écritures — commandes, réservations, formulaires, comptes, commentaires, stocks, envois de fichiers —, choisissez une stratégie avant la bascule :

Une courte fenêtre en lecture seule ou de maintenance : gelez les écritures sur l’ancien site, lancez la synchronisation finale de la base et des fichiers envoyés, puis basculez. Simple, honnête, et généralement court.
Une réplication ou un backend partagé : gardez les données de la nouvelle copie synchronisées en continu, ou laissez les deux interfaces écrire dans une seule base de données jusqu’à la fin de la migration.
Une migration assurée par l’hébergeur, où ses outils gèrent un passage de relais cohérent.

Ce qu’il ne faut surtout pas faire : laisser deux copies indépendantes accepter toutes les deux des changements en direct — il n’existe aucun moyen fiable de les réconcilier ensuite. La même règle vaut pour la période de chevauchement : gardez l’ancien hébergeur joignable pendant que les caches DNS se vident, mais pas comme second système de production — le mode lecture seule, une redirection ou un proxy vers le nouveau backend fonctionnent tous ; accepter en silence des commandes dans l’ancienne base de données, non.

La bascule

Abaissez le TTL des enregistrements qui vont changer — seulement ceux-là — au moins une période de l’ancien TTL à l’avance, en respectant les minimums de votre fournisseur (comment fonctionne le TTL).
Synchronisation finale selon la stratégie de données choisie (pour un site dynamique, c’est là que se place la fenêtre en lecture seule).
Changez ce qui route réellement le trafic web. Selon la configuration, ce sont les enregistrements A/AAAA, un CNAME, un alias d’apex, ou simplement le réglage origin de votre CDN ou proxy — ne convertissez pas les types d’enregistrements sans nécessité, et ne touchez ni aux MX ni aux enregistrements TXT sans rapport.
Gardez un vrai plan de retour : anciennes valeurs DNS notées, ancien environnement inchangé, et un déclencheur convenu à l’avance pour revenir en arrière. N’oubliez pas que le retour n’est pas instantané non plus — les réponses en cache circulent dans les deux sens, et une fois que le nouveau système a accepté de vraies commandes, revenir à l’ancienne base de données les perd. Revenez en arrière tôt, ou pas du tout.

Vérifiez, puis mettez hors service

Interrogez plusieurs résolveurs indépendants (IPv4 et IPv6 là où c’est configuré) ; parcourez le site en production et vérifiez les statuts, les redirections et les URL canoniques ; envoyez les formulaires et confirmez la réception ; testez la connexion, le paiement, les envois de fichiers et les tâches planifiées ; vérifiez que les e-mails sortants s’authentifient toujours (SPF/DKIM dans les en-têtes reçus) ; surveillez la Search Console et votre surveillance ; et lisez les journaux des deux hébergeurs — en gardant en tête qu’un CDN peut masquer le trafic des visiteurs dans le journal d’origine, son silence prouve donc moins qu’il n’y paraît. Faites ensuite une nouvelle sauvegarde du nouveau site en fonctionnement, gardez une copie d’archive de l’ancien environnement, et résiliez seulement après. Rétablissez les TTL normaux et mettez à jour votre inventaire des comptes.

Les anciens et nouveaux environnements doivent se chevaucher — mais ils ne doivent jamais devenir deux endroits indépendants qui acceptent des données différentes. Montez d’abord, testez à fond, synchronisez les derniers changements, basculez délibérément, et ne retirez l’ancien hébergeur qu’une fois que le nouveau système et le chemin du retour ont tous les deux fait leurs preuves.

Ce qu’il faut faire

Inventoriez l’environnement complet — fichiers, base de données, environnement d’exécution, règles serveur, tâches, e-mails sortants, rappels, plan TLS — et sauvegardez le tout.
Montez la copie et testez-la via votre fichier hosts ou un nom d’hôte temporaire, en sachant ce que chaque méthode ne montre pas.
Décidez la stratégie pour les données en direct : synchronisation finale seule pour les sites statiques ; fenêtre en lecture seule, réplication ou backend partagé pour tout ce qui reçoit des écritures.
Abaissez à l’avance uniquement les TTL concernés ; convenez de la procédure d’émission HTTPS avec le nouvel hébergeur.
Changez ce qui route le trafic web, laissez les MX tranquilles, et gardez l’ancien environnement joignable mais non modifiable.
Vérifiez le fonctionnement, l’authentification des e-mails et l’accès des moteurs de recherche ; sauvegardez le nouveau site ; archivez l’ancien ; puis résiliez.