Migrer vers un hébergeur offshore sans interruption

Personne ne déplace un site en production pour le plaisir. Cela arrive parce que l’hébergeur actuel réclame soudain une photo de votre passeport, ou transmet une plainte assortie d’un délai de vingt-quatre heures, ou parce que le pays où se trouve son datacentre a cessé de sembler raisonnable pour y garder vos données. Quelle que soit la raison, le déménagement lui-même est la partie dangereuse — c’est le seul moment où le site peut tomber, et le seul moment où un faux pas peut coller le nouveau serveur à l’identité que vous cherchiez justement à quitter.

Les deux risques ont le même remède, et ce n’est pas un outil. C’est l’ordre des opérations. Une migration menée dans le bon ordre ne comporte aucune fenêtre pendant laquelle le site est injoignable, parce que les deux serveurs sont actifs en même temps et que le DNS est la toute dernière chose à bouger. Une migration menée dans le mauvais ordre produit à la fois une coupure et une trace. Voici cette séquence, écrite pour quelqu’un qui migre vers un hébergeur offshore et no-KYC plutôt que de jongler entre deux fournisseurs grand public — la mécanique est la même, mais le nettoyage qui suit ne l’est pas.

Ce que « zéro interruption » veut vraiment dire

L’expression est utilisée avec légèreté, et c’est cette légèreté qui fait mal. Servir du HTTP depuis deux machines à la fois est facile. Garder l’état cohérent pendant que deux machines servent en même temps est la partie difficile, et c’est la seule partie qui puisse jamais faire perdre des données. Donc, avant de planifier quoi que ce soit, déterminez lequel de ces cas est réellement le vôtre, parce que la réponse détermine la forme de toute la nuit.

Remarquez que seule la première ligne est vraiment gratuite. Partout ailleurs, « zéro interruption » veut dire « un gel des écritures si court que personne n’ouvre de ticket à ce sujet ». Deux minutes en lecture seule à 4 h du matin sont une erreur d’arrondi ; deux heures d’écritures scindées entre deux bases de données sont un week-end de réconciliation. Choisissez le gel.

Baissez le TTL DNS plusieurs jours avant de déménager

C’est la seule étape qui demande un délai d’anticipation, c’est pourquoi elle vient en premier et c’est pourquoi c’est celle que l’on saute. Votre TTL — durée de vie — indique à tous les résolveurs d’Internet combien de temps ils peuvent mettre votre enregistrement en cache avant de le redemander. Si votre enregistrement A a un TTL de 86 400, un résolveur qui l’a consulté il y a une heure continuera à distribuer l’ancienne IP pendant encore vingt-trois heures, quoi que vous changiez chez le bureau d’enregistrement.

Le détail critique est que l’abaissement du TTL est lui-même soumis à l’ancien TTL. Les résolveurs n’apprennent la nouvelle valeur, plus courte, que lorsque l’ancienne copie en cache expire. Baissez donc le TTL à 300 secondes au moins une pleine période de l’ancien TTL avant la bascule — avec un TTL d’une journée, cela signifie le faire 24 à 48 heures à l’avance. Le monde entier converge alors vers votre nouvel enregistrement dans les cinq minutes suivant le changement, et la bascule cesse d’être un moment à suspense.

Remontez le TTL à une valeur raisonnable quelques jours après le déménagement. Un TTL de 300 secondes est un bon outil ponctuel mais un mauvais réglage permanent : il multiplie votre volume de requêtes et transforme votre fournisseur DNS en un point de défaillance unique bien plus tranchant.

Inventoriez ce que vous déménagez, pas ce dont vous vous souvenez

Chaque migration ratée a le même post-mortem : quelque chose que personne n’avait listé n’a pas été copié. La racine web et la base de données sont les deux choses dont tout le monde se souvient ; la liste ci-dessous couvre le reste, et il vaut la peine de la parcourir à la lettre plutôt que de mémoire.

• Travaux planifiés. crontab -l pour chaque utilisateur, plus les timers systemd. Les hooks de renouvellement et les tâches nocturnes se cachent là.
• Définitions de services. Unités systemd personnalisées, vhosts du serveur web, pools PHP-FPM, toute configuration supervisor.
• Secrets et environnement. Fichiers .env, clés API, mots de passe de base de données, sels applicatifs — et notez que ceux-ci doivent être renouvelés, pas simplement copiés.
• Matériel TLS. Les certificats et, plus important encore, le compte ACME et la configuration de renouvellement.
• Identité mail. Clés privées DKIM, enregistrements SPF et DMARC. Une incohérence ici ne casse rien bruyamment ; elle envoie simplement votre courrier vers les spams, en silence.
• Médias téléversés. Souvent en dehors de la racine web, souvent la plus grosse chose que vous possédiez.
• Tout ce qui, à l’extérieur, fait confiance à votre IP. Listes blanches de passerelles de paiement, destinations de webhooks, pare-feux de base de données, API tierces avec restrictions IP. C’est la cause numéro un du « le site marche mais le paiement est cassé » à 3 h du matin.
• La liste des paquets. dpkg --get-selections ou l’équivalent, pour que la nouvelle machine ait exactement les mêmes extensions et bibliothèques, pas presque les mêmes.

Écrivez la liste avant de commencer à copier. Cet inventaire sera aussi votre plan de test plus tard — chaque ligne est quelque chose à vérifier sur le nouveau serveur avant que le DNS ne sache qu’il existe.

Construisez d’abord le nouveau serveur, et durcissez-le avant qu’il ne contienne quoi que ce soit

Commandez la destination tôt et laissez-la tourner à vide pendant un jour ou deux. Le chevauchement ne coûte rien — un petit VPS offshore coûte quelques dollars par mois — et il y a beaucoup à gagner à ne pas construire sous pression, avec une base de données gelée qui attend.

Reproduisez délibérément l’ancien environnement : la même distribution et la même version majeure, la même version majeure de PHP, Node ou Python, la même version majeure de base de données. La tentation de moderniser pendant que vous y êtes est énorme et doit être totalement résistée. Si le site casse après la bascule, vous voulez qu’exactement une seule variable ait changé. Mettez la pile à jour quinze jours plus tard, un après-midi tranquille, avec la possibilité de revenir en arrière.

Durcissez-le pendant qu’il est encore vide. SSH par clés uniquement, pare-feu en deny par défaut, mises à jour de sécurité automatiques — la checklist de durcissement de la première heure est exactement cette liste, et elle est bien plus facile à appliquer à une machine qui ne contient rien. Si les données sont assez sensibles pour justifier un changement de juridiction, c’est aussi le bon moment pour trancher la question du chiffrement au repos, parce que le rajouter plus tard signifie une migration de plus.

Copiez les données deux fois : une passe lente, puis une rapide

L’instinct est de tout copier pendant la fenêtre de maintenance. Faites l’inverse. Lancez une copie complète plusieurs jours à l’avance, pendant que l’ancien site sert tranquillement son trafic, puis lancez une seconde passe au moment de la bascule qui ne déplace que ce qui a changé. La première passe peut prendre six heures sans que personne ne le remarque. La seconde prend quatre-vingt-dix secondes, et c’est tout votre budget d’interruption.

Pour les fichiers, rsync -aHAX --numeric-ids préserve les permissions, la propriété, les liens durs et les attributs étendus ; le drapeau --numeric-ids compte parce que les UID coïncident rarement entre deux machines fraîchement installées. Lancez-le une première fois tôt, puis à nouveau juste avant la bascule avec les mêmes arguments — la seconde exécution ne transfère que le delta.

Les bases de données demandent le même traitement en deux phases, mais avec des outils différents. Un mysqldump --single-transaction ou pg_dump vous donne un instantané cohérent, tôt, sur lequel construire et tester. À la bascule, soit vous prenez un second dump pendant votre bref gel des écritures, soit — pour une grosse base de données où même un court gel fait mal — vous configurez le nouveau serveur en réplique de l’ancien plusieurs jours à l’avance, vous le laissez rattraper son retard, puis vous le promouvez. La réplication réduit le gel à quelques secondes. Elle transforme aussi une migration de deux heures en un projet de deux jours, donc ne l’utilisez que lorsque la taille l’exige vraiment.

Testez le nouveau serveur avant que le DNS ne sache qu’il existe

Vous pouvez servir le vrai nom d’hôte depuis la nouvelle IP sans changer le moindre enregistrement public, et vous devriez le faire — c’est ce qui rend la bascule sans histoire. Ajoutez une ligne à votre /etc/hosts local qui pointe le domaine vers la nouvelle IP, ou faites l’impasse et laissez curl le faire pour une seule requête :

curl -I --resolve example.com:443:203.0.113.10 https://example.com/

Parcourez maintenant l’inventaire. Chargez la page d’accueil et trois pages profondes. Connectez-vous. Soumettez un formulaire. Téléversez un fichier. Vérifiez que la connexion à la base de données est bien la nouvelle, locale, et qu’elle ne pointe pas encore vers l’ancien hôte via Internet — une erreur qui fonctionne parfaitement jusqu’au jour où vous résiliez l’ancien serveur. Lancez les tâches cron à la main et lisez leur sortie. Vérifiez les redirections, et qu’une URL manquante renvoie toujours 404 et non 200.

Émettez le certificat TLS maintenant, avant la bascule, pas après. Utilisez un challenge DNS-01, qui prouve le contrôle du domaine via un enregistrement TXT et fonctionne donc pendant que l’enregistrement A pointe encore vers l’ancien serveur. Si vous attendez une validation HTTP-01 après le changement DNS, chaque visiteur précoce reçoit un avertissement de certificat pendant l’intervalle — une panne auto-infligée, pile dans la fenêtre que vous essayiez de protéger.

La bascule, dans l’ordre

À ce stade, le nouveau serveur est construit, durci, peuplé, testé sous le vrai nom d’hôte, et détient un certificat valide. La bascule elle-même se réduit maintenant à une liste courte et ennuyeuse — c’est exactement le but.

1. Annoncez la fenêtre si d’autres personnes dépendent du site, puis passez l’ancien site en mode lecture seule ou maintenance.
2. Désactivez cron et les workers en arrière-plan sur l’ancien hôte. Faites-le avant de les démarrer sur le nouveau, jamais après.
3. Lancez la passe delta finale de rsync et le dump final de la base de données, puis importez-le.
4. Démarrez l’application sur le nouveau serveur et relancez vos tests de fumée via --resolve, sur les données finales.
5. Changez les enregistrements A et AAAA vers la nouvelle IP. Avec un TTL de 300 secondes, le monde suit en moins de cinq minutes.
6. Activez cron et les workers sur le nouvel hôte.
7. Surveillez les deux journaux d’accès côte à côte. Le trafic se retire de l’ancien serveur et apparaît sur le nouveau ; quand l’ancien devient silencieux, la bascule est terminée.
8. Laissez l’ancien serveur tourner, servir, et intact pendant une semaine. C’est votre filet de retour arrière.

L’étape huit est celle que l’on coupe, et c’est l’assurance la moins chère de toute la liste. Pour le prix de quelques dollars, vous gardez la possibilité de repointer le DNS en arrière — une récupération de cinq minutes — aussi longtemps qu’il le faut pour être sûr.

Ce que la migration laisse derrière elle

Voici la partie que les guides de migration génériques omettent, et celle qui compte le plus si vous avez déménagé pour la confidentialité plutôt que pour le prix. Déplacer un site n’efface pas son histoire. Plusieurs registres publics et semi-publics de l’ancien arrangement survivent définitivement au déménagement, et savoir lesquels fait toute la différence entre une vraie rupture nette et une simple illusion d’en avoir fait une.

Le résumé honnête est qu’une migration ne peut pas réécrire le passé — elle peut seulement arrêter d’y ajouter. Cela vaut quand même beaucoup, mais cela change la décision : si votre modèle de menace exige qu’aucun observateur ne puisse relier le nouveau site à l’ancien, déplacer le même domaine vers un nouvel hôte n’y parvient pas, et aucun soin apporté pendant la bascule n’y changera rien. Ce cas-là nécessite un nouveau nom et un vrai nouveau départ, abordé plus loin. Si votre objectif est plutôt d’arrêter de générer des traces identifiantes à partir d’aujourd’hui, et de déplacer le centre de gravité légal vers une juridiction que vous avez choisie, le déménagement fait exactement cela. Notre guide OpSec serveur couvre les habitudes qui gardent ça propre par la suite.

La question du domaine : le conserver, ou repartir de zéro ?

Le site et le domaine sont des décisions indépendantes, et les confondre est fréquent. Vous pouvez déplacer l’hébergement aujourd’hui et ne plus jamais toucher au bureau d’enregistrement ; rien dans le changement de serveur n’exige de toucher au domaine. Savoir si vous devriez le faire dépend entièrement de ce que le domaine sait déjà sur vous.

• Gardez le domaine, changez de bureau d’enregistrement. Sensé quand le domaine a de la valeur — liens, classements, un nom que les gens tapent. Cela corrige l’avenir de l’enregistrement WHOIS, pas son histoire, et cela garde intact chaque signal de classement. C’est la bonne réponse pour la plupart des sites commerciaux.
• Gardez le domaine, ne changez rien d’autre que l’hôte. Parfaitement raisonnable quand vous avez déménagé pour la juridiction, la disponibilité ou la posture DMCA plutôt que pour l’anonymat. Le déménagement le plus simple possible, zéro risque SEO.
• Nouveau domaine, redirection de l’ancien. Préserve les classements, et relie publiquement et définitivement les deux noms. Choisissez cette option pour la continuité, jamais pour la confidentialité — la redirection est le lien.
• Nouveau domaine, rupture nette. La seule option qui rompt vraiment l’association, et elle vous coûte chaque classement et chaque lien entrant que vous aviez. Enregistrez-le en privé dès le départ, parce qu’un domaine n’est jamais plus anonyme que son tout premier enregistrement. Notre guide sur l’enregistrement de domaine anonyme en crypto explique comment bien le faire.

Choisissez délibérément, et choisissez avant la bascule plutôt que pendant. Changer d’avis sur le domaine après que le DNS a bougé signifie refaire la partie délicate deux fois.

Démantelez correctement l’ancien hôte

Une ou deux semaines après la bascule, quand les journaux du nouveau serveur sont ennuyeux et que ceux de l’ancien sont vides, il est temps de fermer l’ancien compte. Faites-le dans cet ordre, parce que le raccourci tentant — cliquer sur résilier — est justement celui qui laisse vos données sur le disque de quelqu’un d’autre.

1. Confirmez que plus rien ne pointe vers l’ancienne IP : cherchez les adresses codées en dur dans les webhooks tiers, les listes blanches, le monitoring, et tout enregistrement DNS oublié, comme un sous-domaine égaré mail ou cpanel.
2. Renouvelez chaque secret qui a jamais vécu sur cette machine — mots de passe de base de données, clés API, sels applicatifs, clés DKIM, clés SSH. Ne les recopiez pas vers le nouveau serveur.
3. Retirez vos clés publiques SSH et tout accès support de l’ancien serveur.
4. Supprimez l’application, les dumps et les sauvegardes, puis écrasez l’espace libre pour qu’une lecture superficielle du volume recyclé ne donne rien.
5. Résiliez le service seulement à ce moment-là, et retirez tout moyen de paiement enregistré sur l’ancien compte.

Toute la séquence sur une seule page

Débarrassée de tout raisonnement, une migration d’hébergeur tient en neuf étapes, dont seulement deux sont vraiment urgentes :

1. Deux jours avant : baissez le TTL DNS à 300 secondes.
2. Deux jours avant : commandez et durcissez le serveur de destination, en reproduisant l’ancienne pile version par version.
3. Plusieurs jours avant : rédigez l’inventaire — cron, secrets, TLS, clés mail, médias, listes blanches IP, paquets.
4. Plusieurs jours avant : lancez la première copie complète des données, d’hôte à hôte.
5. Avant la fenêtre : émettez le certificat par DNS-01 et testez tout via --resolve.
6. La fenêtre (minutes) : gelez les écritures, désactivez l’ancien cron, lancez la copie delta et le dump final, démarrez la nouvelle application.
7. La fenêtre (secondes) : changez l’enregistrement A, puis activez cron sur le nouvel hôte.
8. La semaine suivante : gardez l’ancien serveur en vie comme filet de retour arrière, surveillez les deux journaux, puis remontez le TTL.
9. Ensuite : renouvelez les secrets, effacez, résiliez — et souvenez-vous de ce que le déménagement n’a pas pu effacer.

Rien dans cette liste n’est difficile. Chaque étape qui fait mal est une étape faite dans le désordre — un TTL baissé le soir même, un certificat émis après le changement DNS, une tâche cron laissée active sur une machine qui n’est plus autoritaire. Respectez la séquence, et la partie intéressante d’une migration devient le choix de l’emplacement du serveur, pas le déménagement lui-même. Si vous n’avez pas encore tranché cette question, le guide des juridictions est le bon point de départ.