Changez d'hébergeur : on migre votre site gratuitement

La migration, dans l'ordre où elle se fait

Une migration rate rarement sur la technique : elle rate sur l'ordre. Le TTL qu'on abaisse après la bascule, le MX qu'on modifie avant d'avoir créé les boîtes, l'ancien contrat résilié avant d'avoir relu les journaux — chacune de ces inversions coûte une demi-journée. Voici la séquence complète, du premier inventaire à la résiliation.

Les repères en jours valent pour un site ou un serveur ordinaire. Une boutique en pleine saison, ou un parc de plusieurs dizaines de boîtes mail, demande d'étirer ces étapes, pas d'en sauter.

1. J-7 — Faire l'inventaire de ce qui tourne vraiment. Les sites et leurs domaines, la version de PHP en service, les bases et leur moteur, les boîtes e-mail et leur volume, les tâches planifiées, les certificats et leur date d'expiration, et les services tiers qui connaissent votre adresse IP actuelle (passerelle de paiement, relais SMTP, webhooks). C'est cette liste, et pas votre mémoire, qui servira de contrôle final.
2. J-7 — Dimensionner la cible sur l'usage réel, pas sur l'offre que vous payez aujourd'hui. Relevez l'espace disque occupé, la taille des bases, la mémoire réellement consommée. Un site qui tient dans 6 Go n'a pas besoin d'une offre à 200 Go parce que l'ancienne l'annonçait.
3. J-5 — Ouvrir le nouvel hébergement et monter la copie. Fichiers et bases sont transférés une première fois, complètement, sans que rien ne change côté public. Cette copie n'a pas besoin d'être à jour à la seconde : elle sert à vérifier que l'application démarre.
4. J-3 — Geler les évolutions sur l'ancien serveur. Plus de mise en ligne d'article, plus de mise à jour d'extension, plus de retouche de thème jusqu'à la bascule. Tout ce qui est écrit après ce point devra être resynchronisé à la main.
5. J-2 — Abaisser le TTL des enregistrements qui vont changer, à 300 secondes. Cette étape se fait au moins 48 heures avant la bascule, pour la raison expliquée dans la section DNS ci-dessous. C'est l'étape la plus souvent faite trop tard, et la seule qui ne se rattrape pas.
6. J-1 — Tester la copie sous son vrai nom de domaine, sans toucher au DNS public : modifiez le fichier hosts de votre poste pour faire pointer le domaine vers la nouvelle adresse IP. Vous voyez alors exactement ce que verront vos visiteurs, liens absolus et redirections compris.
7. J-1 — Préparer la zone DNS cible sans la publier. Notez les valeurs exactes des enregistrements A, AAAA, MX, SPF, DKIM, DMARC et CAA que vous allez poser. Les écrire à l'avance évite de les improviser le jour J, quand le site est déjà à moitié basculé.
8. Jour J — Resynchroniser le delta. Une seconde passe de copie ne transfère que ce qui a bougé depuis J-5, puis un export de base frais remplace le précédent. C'est cette seconde passe, courte, qui définit la vraie fenêtre d'indisponibilité.
9. Jour J — Publier les nouveaux enregistrements DNS. Avec un TTL à 300 secondes posé deux jours plus tôt, la bascule devient effective en quelques minutes pour la plupart des visiteurs, pas en vingt-quatre heures.
10. Jour J — Dérouler les vérifications dans l'ordre donné plus bas. Ne cochez rien de mémoire : ouvrez la liste et testez réellement.
11. J+1 — Remonter le TTL à sa valeur habituelle ; 3 600 secondes conviennent dans la plupart des cas. Un TTL court en permanence multiplie inutilement les interrogations de vos serveurs de noms.
12. J+7 — Résilier l'ancien contrat, pas avant. Attendez d'avoir reçu du courrier sur les nouvelles boîtes, restauré une sauvegarde chez le nouvel hébergeur et relu les journaux d'erreur. Une résiliation efface souvent les données le jour même.

Ce qu'on transfère, et par quel moyen

Un hébergement n'est pas un bloc unique : c'est une pile d'éléments qui se déplacent chacun avec son propre outil. Les traiter séparément évite l'erreur la plus courante, qui consiste à copier les fichiers et à espérer que le reste suivra.

• Les fichiers. rsync en SSH quand les deux côtés le permettent, SFTP sinon. Deux passes valent mieux qu'une : une première complète pendant que le site tourne, une seconde juste avant la bascule qui ne reprend que les différences. Vérifiez ensuite que les droits, les propriétaires et les liens symboliques ont survécu — un FTP mal réglé les aplatit sans prévenir.
• Les bases de données. mysqldump --single-transaction --quick pour MySQL et MariaDB, pg_dump -Fc pour PostgreSQL. Relevez le jeu de caractères et la collation de la base d'origine, et recréez la base cible avec les mêmes : c'est ce détail-là qui transforme les accents en caractères illisibles après import.
• La sauvegarde du panel. Si votre hébergement actuel est administré par un panel, son export intégré — fichiers, bases, boîtes et réglages dans une seule archive — est souvent la voie la plus sûre. Nos offres d'hébergement web sont livrées avec le panel Plesk, qui dispose de ses propres outils de sauvegarde et de reprise.
• L'image disque, pour un serveur entier. Sur un VPS ou un serveur dédié, deux routes : recopier le disque tel quel (image raw ou qcow2, ou copie bloc à bloc depuis un système de secours), ou repartir d'un système propre et redéployer l'application dessus. Si votre hébergeur actuel ne donne pas accès à l'image disque, la seconde route est la seule possible — et c'est de toute façon celle que nous conseillons pour un système de plusieurs années.
• Les certificats. Ne les déplacez pas : un certificat Let's Encrypt se réémet en quelques secondes sur le nouveau serveur, une fois le domaine pointé. Si vous payez un certificat à validation étendue, exportez la clé privée avant de résilier, faute de quoi il faudra le racheter.
• Les boîtes e-mail. Une synchronisation IMAP recopie les messages, l'arborescence des dossiers et les états lu ou non lu d'un serveur à l'autre. Passez-la deux fois, comme pour les fichiers : une avant la bascule, une après, pour rattraper les messages arrivés entre les deux.
• Les tâches planifiées et les services. Les cron, les minuteries systemd, les files d'attente et les processus permanents ne figurent dans aucune sauvegarde de site. Recopiez-les à la main, puis vérifiez qu'ils tournent après la bascule, pas seulement qu'ils sont déclarés.
• Les secrets. Clés SSH autorisées, jetons d'API, clés de chiffrement applicatives, identifiants de services : ils vivent souvent hors du dossier du site et se perdent silencieusement. Une application qui démarre mais ne déchiffre plus ses données, c'est presque toujours une clé restée sur l'ancien serveur.

Le DNS : ce qui se prépare avant, ce qui bascule le jour J

Le DNS est la partie de la migration que vous ne maîtrisez pas seul. Entre votre zone et vos visiteurs, il y a des résolveurs qui gardent l'ancienne réponse en mémoire pendant exactement la durée que vous leur avez annoncée. Cette durée s'appelle le TTL, et c'est le seul levier dont vous disposez pour raccourcir la bascule.

D'où la règle : on abaisse le TTL avant, jamais pendant. Si votre TTL vaut aujourd'hui 86 400 secondes et que vous le passez à 300 le matin de la bascule, les résolveurs qui détiennent déjà l'ancienne valeur continueront de la respecter pendant vingt-quatre heures. En l'abaissant 48 heures plus tôt, vous laissez l'ancienne valeur expirer d'elle-même, et la bascule devient une affaire de minutes.

1. 48 heures avant : abaisser le TTL à 300 secondes sur tous les enregistrements que vous allez modifier — au minimum A et AAAA, plus le MX et les CNAME associés si le courrier déménage aussi. Le TTL se règle dans la zone DNS, chez celui qui héberge cette zone : votre bureau d'enregistrement, dans la plupart des cas.
2. Relever la zone actuelle avant d'y toucher. Une interrogation dig votredomaine.fr ANY, ou un export de zone depuis l'interface, vous donne l'état de départ. Conservez-le : c'est votre point de retour si quelque chose se passe mal.
3. A et AAAA. L'enregistrement A porte l'adresse IPv4 du nouvel hébergement, AAAA son adresse IPv6 s'il en a une. N'oubliez ni www ni les sous-domaines réellement utilisés : un webmail, une api, une préproduction. Ceux qu'on oublie sont ceux qu'on ne visite jamais soi-même.
4. MX : l'enregistrement qu'on oublie. Il désigne le serveur qui reçoit votre courrier, et il est indépendant de celui qui héberge le site. Si votre messagerie reste où elle est, n'y touchez pas : c'est l'erreur classique de la bascule « on remplace toutes les IP de la zone », qui détourne le courrier vers un serveur qui ne le connaît pas. Si la messagerie déménage, ne changez le MX qu'une fois les boîtes créées et synchronisées.
5. SPF. C'est un enregistrement TXT unique qui énumère les serveurs autorisés à envoyer du courrier en votre nom. S'il continue de désigner l'ancien hébergement, les messages partis du nouveau seront classés en indésirable ou rejetés. Ajoutez le nouveau serveur avant la bascule, retirez l'ancien une fois la migration confirmée — et gardez un seul enregistrement SPF : deux se neutralisent.
6. DKIM. La signature est produite par le serveur d'envoi et vérifiée grâce à une clé publique publiée dans votre zone, sous un sélecteur. Publiez le sélecteur du nouveau serveur avant de basculer et laissez l'ancien en place quelques jours : deux sélecteurs coexistent sans se gêner, ce qui n'est pas le cas du SPF.
7. DMARC. Il indique aux destinataires quoi faire des messages qui échouent aux contrôles précédents. Pendant une migration, restez en p=none avec une adresse de rapport : vous observez sans rien casser, et vous durcissez la politique une fois que SPF et DKIM sont propres des deux côtés.
8. CAA, s'il existe. Cet enregistrement liste les autorités autorisées à émettre un certificat pour votre domaine. S'il ne mentionne pas celle qu'utilise votre nouvel hébergeur, l'émission échoue silencieusement et le site reste en HTTPS invalide, sans message d'erreur explicite nulle part.
9. Reverse DNS (PTR). Il ne se règle pas dans votre zone mais sur l'adresse IP, donc chez l'hébergeur qui la détient. Il compte dès que votre serveur envoie lui-même du courrier : sans PTR cohérent avec le nom annoncé, une partie des destinataires refuse le message. Chez nous, le reverse DNS peut être personnalisé sur demande.

L'indisponibilité réelle, et comment la ramener à presque rien

La coupure que redoutent la plupart des gens — « mon site sera injoignable pendant la propagation DNS » — n'existe pas si les deux hébergements répondent en même temps. Pendant la propagation, une partie des visiteurs arrive sur l'ancien serveur, l'autre sur le nouveau, et les deux affichent le site. Personne ne voit d'erreur.

La vraie fenêtre est ailleurs : c'est le moment où le site accepte encore des écritures d'un côté alors que la base a déjà été exportée. Une commande passée pendant cette fenêtre est enregistrée sur l'ancien serveur et n'existera jamais sur le nouveau. Réduire l'indisponibilité, c'est donc réduire cette fenêtre d'écriture — pas se battre contre le DNS.

• Site vitrine ou site statique : aucune coupure. Rien ne s'écrit côté serveur, la copie peut être faite la veille, et la bascule ne demande aucune précaution particulière.
• Site avec base de données : quelques minutes. On passe le site en lecture seule ou en maintenance, on exporte la base, on l'importe, on bascule. Sur un site ordinaire, la manœuvre tient en cinq à quinze minutes, à programmer en heure creuse.
• Boutique en ligne : la même fenêtre, mais annoncée. Prévenez l'équipe, choisissez un creux réel — souvent tôt le matin — et comparez après coup les dernières commandes des deux côtés avant de considérer l'ancien serveur comme jetable.
• Courrier : pas de coupure, mais une période de recouvrement. Tant que le MX n'est pas propagé partout, des messages continuent d'arriver sur l'ancien serveur. Gardez-y l'accès quelques jours et refaites une synchronisation IMAP après la bascule : c'est ce qui évite le message perdu.
• Application avec file d'attente ou traitements différés : videz la file avant. Un travail en cours au moment de l'export sera perdu, ou rejoué deux fois. Arrêtez les consommateurs, laissez la file se vider, puis exportez.

Après la bascule : les vérifications, dans l'ordre

Cette liste se déroule de haut en bas le jour de la bascule. L'ordre n'est pas décoratif : chaque point suppose le précédent vérifié, et un échec au point 2 rend tous les suivants ininterprétables.

1. La résolution DNS. Interrogez un résolveur public et celui de votre fournisseur d'accès : les deux doivent renvoyer la nouvelle adresse. Tant que ce n'est pas le cas, ce que vous voyez dans votre navigateur ne prouve rien.
2. Le site répond, depuis la bonne machine. curl -I https://votredomaine.fr doit renvoyer un code 200 ; en cas de doute, curl --resolve permet de forcer l'adresse et de comparer les deux serveurs côte à côte.
3. Le certificat. Valide, au bon nom, et couvrant aussi www. Comptez quelques minutes après la propagation pour une émission automatique ; au-delà d'une heure, allez regarder l'enregistrement CAA.
4. Les redirections. HTTP vers HTTPS, et www vers le domaine nu ou l'inverse — mais dans un seul sens, en 301 et non en 302, et sans chaîne de deux redirections successives.
5. Les pages profondes. L'accueil fonctionne presque toujours. Ouvrez cinq ou six URL internes prises au hasard : c'est là que se voient les règles de réécriture perdues et les liens absolus restés sur l'ancien domaine.
6. Les formulaires. Envoyez un message de test depuis le formulaire de contact et vérifiez qu'il arrive. Un formulaire qui affiche « merci » sans rien expédier est le défaut post-migration le plus fréquent.
7. Le paiement, s'il y en a un. Une commande de test en mode bac à sable, jusqu'à la confirmation et l'e-mail associé. Vérifiez au passage que la passerelle n'a pas une liste d'adresses IP autorisées à mettre à jour.
8. Le courrier sortant. Envoyez un message depuis le site vers une adresse extérieure, ouvrez l'en-tête du message reçu et lisez les résultats SPF et DKIM. Il faut « pass » des deux côtés ; sinon, reprenez la section DNS.
9. Le courrier entrant. Écrivez de l'extérieur à l'une des adresses migrées, et continuez de surveiller l'ancienne boîte pendant quelques jours.
10. Les tâches planifiées. Attendez qu'une exécution soit passée et vérifiez sa trace, plutôt que la seule présence de la ligne dans la table des tâches.
11. Les journaux d'erreur. Relisez-les pendant les 48 premières heures. Une extension manquante ou un chemin absolu resté en dur s'y voit immédiatement, souvent avant que quiconque ne s'en plaigne.
12. Une première sauvegarde chez le nouvel hébergeur. Prenez-la, puis restaurez-la une fois pour vérifier qu'elle est exploitable. C'est la condition à remplir avant de résilier l'ancien contrat.

Les pièges qui font perdre une journée

• Le TTL abaissé le jour même. Il ne sert à rien : l'ancienne valeur, longue, est déjà en cache. Une partie de vos visiteurs reste sur l'ancien serveur toute la journée, et vous cherchez une panne qui n'existe pas.
• Le MX remplacé par réflexe. Remplacer « toutes les IP de la zone » emporte le courrier avec le site. Si la messagerie ne déménage pas, le MX ne bouge pas.
• Le SPF laissé sur l'ancien serveur. Le site fonctionne, les e-mails partent, et personne ne les reçoit — ou ils tombent en indésirable. C'est le défaut le plus difficile à diagnostiquer après coup, parce que rien n'échoue visiblement.
• L'ancien contrat résilié trop tôt. La résiliation efface les données, souvent le jour même, et emporte avec elles les messages arrivés après la bascule et la seule copie encore fraîche des fichiers.
• Le certificat demandé avant que le DNS ne pointe. La validation échoue, le site s'affiche avec un avertissement de sécurité, et le navigateur garde l'erreur en mémoire. Attendez la propagation, puis demandez l'émission.
• Le robots.txt de préproduction recopié tel quel. Un Disallow: / hérité de l'environnement de test désindexe le site en quelques jours. Relisez ce fichier juste après la bascule.
• La version de PHP qui change sans qu'on l'ait décidé. Le nouvel hébergement propose souvent une version plus récente par défaut. Reproduisez d'abord la version d'origine, mettez à jour ensuite, une fois la migration derrière vous.
• Le cache et le CDN oubliés. Si un CDN se trouve devant votre site, ce n'est pas l'enregistrement A public qu'il faut changer, mais l'origine déclarée dans le CDN. Et purgez le cache après la bascule, sinon vous continuez de servir l'ancien site.
• Les listes d'adresses IP autorisées chez les tiers. Passerelle de paiement, relais SMTP, API partenaire, base de données distante : tout ce qui filtre par adresse IP doit connaître la nouvelle avant la bascule, pas après.

Migrer un serveur, ce n'est pas migrer un site

Les deux opérations portent le même nom et n'ont pas le même contenu. Migrer un site, c'est déplacer des fichiers, une base et des boîtes vers un hébergement déjà administré : le système, les mises à jour de sécurité et le panel sont fournis. C'est ce que couvre la migration prise en charge vers nos offres d'hébergement web.

Migrer un serveur, c'est reconstruire une machine : système, paquets, services, pare-feu, utilisateurs, certificats, sauvegardes. Sur un VPS KVM, vous récupérez une adresse IPv4 dédiée, un accès root en SSH et un panel qui donne le redémarrage, la réinstallation, les instantanés et la console. Cette console compte le jour de la bascule : c'est elle qui vous permet de reprendre la main si une règle de pare-feu vous ferme la porte SSH.

Notre conseil, quand la machine d'origine a plusieurs années : ne recopiez pas le disque, reconstruisez. Vous héritez sinon de réglages dont plus personne ne connaît la raison. Prenez un instantané juste avant chaque étape sensible — cela ne coûte rien en temps et transforme une erreur en simple retour arrière. Pour une infrastructure entière à déplacer, décrivez-nous l'existant dans un devis : nous cadrons la séquence avec vous plutôt que d'annoncer un délai avant d'avoir vu la machine.

Le référencement pendant la migration

Changer d'hébergeur en gardant le même domaine et les mêmes URL n'a, en soi, aucun effet sur le référencement : pour un moteur, seule l'adresse IP change, et ce n'est pas un critère de classement. Les pertes constatées après une migration viennent presque toujours d'autre chose.

• Des URL qui changent sans redirection. Si la structure évolue en même temps que l'hébergement, préparez la table de correspondance avant la bascule et servez des 301, pas des 302. Gardez-les douze mois au minimum.
• Un blocage d'indexation involontaire. robots.txt, en-tête X-Robots-Tag, balise noindex héritée d'un environnement de test : vérifiez les trois le jour même.
• Un site plus lent qu'avant. Le cache applicatif et la compression sont souvent à réactiver sur le nouvel hébergement. Comparez le temps de réponse avant et après, plutôt que de le supposer.
• Un plan de site cassé. Vérifiez qu'il reste accessible et à jour, puis laissez le moteur revenir de lui-même. Le rythme d'exploration se rétablit en quelques jours ; il n'y a rien à forcer si les URL n'ont pas bougé.