[Accueil](https://servhidden.com/fr) / [Guides Hébergement Privé](https://servhidden.com/fr/guides) / Migrer un site vers un hébergeur offshore sans interruption Exploitation # Migrer vers un hébergeur offshore sans interruption Presque toutes les migrations douloureuses sont un problème d’ordre, pas un problème technique — un TTL abaissé le soir même plutôt que deux jours avant, un certificat émis après le changement DNS plutôt qu’avant, une tâche cron laissée active sur un serveur qui n’est plus autoritaire. Voici la séquence qui supprime entièrement la fenêtre d’interruption, plus la partie que les guides génériques passent sous silence : ce que le déménagement enregistre définitivement à votre sujet, et ce que vous pouvez encore faire pour y remédier. [Lire le guide](#guide-body) [FAQ](#guide-faq) ## Sur cette page - [Guide](#guide-body) - [FAQ](#guide-faq) - [Guides connexes](#guide-related) - [Pages recommandées](#guide-cta) Sans KYC Crypto uniquement Aucun journal DMCA ignoré Accès root complet SSD NVMe 20 min de lecture Mis à jour Aug 2026 Sur cette page [01Ce que « zéro interruption » veut vraiment dire](#ce-que-zéro-interruption-veut-vraiment-dire) [02Baissez le TTL DNS plusieurs jours avant de déménager](#baissez-le-ttl-dns-plusieurs-jours-avant-de-déménager) [03Inventoriez ce que vous déménagez, pas ce dont vous vous souvenez](#inventoriez-ce-que-vous-déménagez-pas-ce-dont-vous-vous-souv) [04Construisez d’abord le nouveau serveur, et durcissez-le avant qu’il ne contienne quoi que ce soit](#construisez-dabord-le-nouveau-serveur-et-durcissez-le-avant-) [05Copiez les données deux fois : une passe lente, puis une rapide](#copiez-les-données-deux-fois-une-passe-lente-puis-une-rapide) [06Testez le nouveau serveur avant que le DNS ne sache qu’il existe](#testez-le-nouveau-serveur-avant-que-le-dns-ne-sache-quil-exi) [07La bascule, dans l’ordre](#la-bascule-dans-lordre) [08Ce que la migration laisse derrière elle](#ce-que-la-migration-laisse-derrière-elle) [09La question du domaine : le conserver, ou repartir de zéro ?](#la-question-du-domaine-le-conserver-ou-repartir-de-zéro-) [10Démantelez correctement l’ancien hôte](#démantelez-correctement-lancien-hôte) [11Toute la séquence sur une seule page](#toute-la-séquence-sur-une-seule-page) [FAQQuestions fréquentes](#guide-faq) [→Pages recommandées](#guide-cta) 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. | Ce que vous déménagez | Ce qui mord vraiment | Ce que doit être le plan | | --- | --- | --- | | Site statique, site vitrine, sortie générée | Rien. Il n’y a aucun état à scinder | Copier, vérifier, basculer. Véritablement zéro interruption | | CMS avec base de données — WordPress, Ghost, un forum | Commentaires, connexions et publications atterrissant sur deux bases de données à la fois | Un gel en lecture seule mesuré en **minutes**, à votre heure la plus calme | | Une boutique, ou tout ce qui prend des commandes | Un split-brain perd silencieusement des commandes payées | Prenez la courte fenêtre de maintenance. C’est moins cher qu’une réconciliation | | Tout ce qui a des tâches cron ou des workers en arrière-plan | La même tâche se déclenche sur les deux serveurs — doubles e-mails, doubles débits | Désactivez la planification sur l’ancien hôte *avant* que le nouveau ne démarre | | Le courrier sur le même domaine | Les enregistrements MX expirent des caches selon leur propre horloge, indépendamment de votre enregistrement A | Déplacez le courrier une autre nuit, et laissez l’ancien MX accepter pendant une semaine | 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. Les deux serveurs tournent en même temps et le DNS bouge en dernier — c’est pourquoi une bascule correctement séquencée n’a aucune fenêtre du tout. ## 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](https://servhidden.com/fr/guides/first-hour-vps-hardening-checklist) 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](https://servhidden.com/fr/guides/full-disk-encryption-on-a-vps), 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. **Tirez (pull), ne poussez pas (push), et jamais via votre ordinateur portable.** Lancez la copie depuis le nouveau serveur, pour que le transfert se fasse d’hôte à hôte à la vitesse du datacentre. Faire transiter des gigaoctets par votre connexion domestique est lent, et cela place votre IP résidentielle dans les journaux d’accès des deux machines — exactement le lien qu’une migration motivée par la confidentialité cherche à éviter. Si même le fait que l’ancien hôte apprenne votre nouvelle IP est inacceptable, ne copiez pas directement du tout : restaurez plutôt le nouveau serveur depuis votre propre [sauvegarde chiffrée hors site](https://servhidden.com/fr/guides/vps-backup-strategy), et les deux machines ne se parlent jamais. ## 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. - Annoncez la fenêtre si d’autres personnes dépendent du site, puis passez l’ancien site en mode lecture seule ou maintenance. - **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. - Lancez la passe delta finale de rsync et le dump final de la base de données, puis importez-le. - Démarrez l’application sur le nouveau serveur et relancez vos tests de fumée via --resolve, sur les données finales. - Changez les enregistrements A et AAAA vers la nouvelle IP. Avec un TTL de 300 secondes, le monde suit en moins de cinq minutes. - Activez cron et les workers sur le nouvel hôte. - 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. - 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. | Ce qui enregistre le déménagement | Qui peut le lire | Ce que vous pouvez réellement faire | | --- | --- | --- | | DNS passif — historique des enregistrements A | N’importe qui, via des services commerciaux d’historique | **Rien.** L’ancienne IP reste associée au nom pour toujours. Considérez-la comme publique, parce qu’elle l’est | | Journaux Certificate Transparency | N’importe qui, en permanence, cherchable par domaine | Chaque certificat jamais émis y figure — y compris les sous-domaines à consonance interne que vous aviez oubliés. Préférez un wildcard à des noms descriptifs | | Les registres de compte de l’ancien hôte | L’ancien hôte, et quiconque peut l’y contraindre | Détails de carte, e-mail d’inscription, IP de connexion. Une destination no-KYC protège l’avenir, pas le passé | | Historique WHOIS | Archives commerciales d’historique WHOIS | Si le domaine a un jour été enregistré avec de vraies informations, cet instantané est capturé. Une confidentialité appliquée plus tard ne l’annule pas | | Identifiants analytics et publicitaires | Le fournisseur, et quiconque lit le code source de votre page | Conserver le même identifiant de suivi relie les deux sites de façon définitive. Émettez-en un nouveau, ou supprimez-le | | Dumps et sauvegardes laissés sur l’ancien disque | Quiconque se voit attribuer ce stockage ensuite | Supprimez et écrasez avant de résilier. Sur du stockage partagé, considérez que la suppression est une suggestion, pas une garantie | | En-têtes Received: dans le courrier envoyé | Chaque destinataire, pour toujours | Rien de rétroactif. Seul le courrier envoyé après le déménagement porte le nouveau chemin | | Vos propres connexions pendant la copie | Votre FAI, et les journaux d’accès des deux hôtes | Celui-ci est entièrement sous votre contrôle. Ne touchez jamais l’une ou l’autre machine depuis une IP qui vous identifie | 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](https://servhidden.com/fr/guides/server-opsec-staying-anonymous) 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](https://servhidden.com/fr/guides/anonymous-domain-registration-with-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. - 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. - 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. - Retirez vos clés publiques SSH et tout accès support de l’ancien serveur. - Supprimez l’application, les dumps et les sauvegardes, puis écrasez l’espace libre pour qu’une lecture superficielle du volume recyclé ne donne rien. - Résiliez le service seulement à ce moment-là, et retirez tout moyen de paiement enregistré sur l’ancien compte. **Tout ce qui a vécu sur du matériel que vous ne contrôlez plus est compromis par définition.** Non pas parce que votre ancien hôte est malveillant, mais parce que ce disque va retourner dans un pool et que vous ne saurez jamais ce qui a survécu à l’effacement. Renouveler un mot de passe de base de données prend deux minutes. Découvrir des mois plus tard qu’une clé provenant d’un serveur démantelé ouvre encore quelque chose prend considérablement plus longtemps. ## 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 : - **Deux jours avant :** baissez le TTL DNS à 300 secondes. - **Deux jours avant :** commandez et durcissez le serveur de destination, en reproduisant l’ancienne pile version par version. - **Plusieurs jours avant :** rédigez l’inventaire — cron, secrets, TLS, clés mail, médias, listes blanches IP, paquets. - **Plusieurs jours avant :** lancez la première copie complète des données, d’hôte à hôte. - **Avant la fenêtre :** émettez le certificat par DNS-01 et testez tout via --resolve. - **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. - **La fenêtre (secondes) :** changez l’enregistrement A, puis activez cron sur le nouvel hôte. - **La semaine suivante :** gardez l’ancien serveur en vie comme filet de retour arrière, surveillez les deux journaux, puis remontez le TTL. - **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](https://servhidden.com/fr/guides/choosing-an-offshore-jurisdiction) est le bon point de départ. FAQ ## Migration d’hébergeur — questions fréquentes ### 01 Combien d’interruption dois-je vraiment prévoir ? Pour un site statique, aucune — les deux serveurs peuvent servir le même contenu simultanément, donc le changement DNS est invisible. Pour tout ce qui a une base de données, votre interruption dure exactement le temps de votre gel des écritures, typiquement deux à dix minutes si vous avez déjà effectué une copie complète des données au préalable. Le chiffre qui compte n’est pas la vitesse à laquelle le DNS bouge ; c’est la quantité que vous copiez pendant la fenêtre. Copiez presque tout plusieurs jours à l’avance, et la fenêtre se réduit à la taille du delta. ### 02 Combien de temps prend la propagation DNS ? Il n’y a pas de propagation — ce mot décrit quelque chose qui n’existe pas. Les résolveurs mettent simplement votre enregistrement en cache pour la durée indiquée par son TTL, et le redemandent à l’expiration. Si le TTL en vigueur était de 86 400, certains résolveurs continueront à servir l’ancienne IP pendant encore 24 heures. Baissez le TTL à 300 secondes au moins une pleine période de l’ancien TTL avant la bascule, et Internet tout entier suit votre changement en moins de cinq minutes. ### 03 Dois-je aussi déplacer mon domaine ? Non. Le bureau d’enregistrement et l’hébergeur sont totalement indépendants, et déplacer le site en laissant le domaine exactement où il est fonctionne parfaitement. Savoir si vous devriez le déplacer dépend de votre raison de migrer : si c’était la juridiction, le prix ou la posture DMCA, ne touchez pas au domaine. Si c’était l’anonymat, notez que le domaine porte sa propre histoire séparée — les archives WHOIS conservent les informations avec lesquelles il a été enregistré la première fois, et les changements d’hébergement n’y changent rien. ### 04 Puis-je migrer sans que l’ancien hôte apprenne où je suis allé ? Pas si vous copiez directement entre les deux machines — une extrémité se connecte à l’autre, et les deux journaux d’accès l’enregistrent. Si ce lien compte vraiment pour votre modèle de menace, ne copiez pas du tout d’hôte à hôte : restaurez le nouveau serveur depuis votre propre sauvegarde chiffrée hors site, pour que les deux fournisseurs n’échangent jamais le moindre paquet. Dans tous les cas, n’initiez jamais le transfert depuis une connexion qui vous identifie, et ne mentionnez jamais la destination dans un ticket de support ouvert auprès de l’ancien fournisseur. ### 05 Faut-il mettre à jour l’OS ou la pile en même temps ? Non, et c’est l’échec de migration auto-infligé le plus courant. Changez une seule chose. Si le site se comporte mal après la bascule, vous voulez une seule explication candidate, pas un choix entre la nouvelle machine, la nouvelle version de PHP et la nouvelle version majeure de base de données. Reproduisez l’ancien environnement version par version, terminez le déménagement, confirmez une semaine de journaux propres, puis mettez à jour séparément, avec la possibilité de revenir en arrière. ### 06 La migration va-t-elle nuire à mon référencement ? Pas significativement, à condition que le domaine, les URL et le contenu restent les mêmes — Google indexe des URL, pas des adresses IP, et un changement d’hébergeur en soi n’est pas un signal de classement. Gardez une structure d’URL identique, renvoyez les mêmes codes de statut, et ne combinez pas le déménagement avec une refonte ou un changement de schéma d’URL. Si vous passez plutôt à un nouveau domaine, attendez-vous à une baisse temporaire même avec des redirections 301 correctes, et comprenez que ces redirections relient aussi publiquement les deux noms. ### 07 Dois-je réémettre les certificats TLS ? Oui — le nouveau serveur a besoin de son propre certificat et de sa propre clé privée, et recopier l’ancienne clé est une mauvaise habitude, même quand ça fonctionne techniquement. Émettez-le avant la bascule avec un challenge DNS-01, qui valide via un enregistrement TXT et réussit donc pendant que l’enregistrement A pointe encore vers l’ancien hôte. Attendre une validation HTTP-01 après le changement DNS garantit une période d’avertissements de certificat, pile dans la fenêtre que vous essayiez de protéger. ### 08 Quand est-il sûr de résilier l’ancien serveur ? Après une ou deux semaines de journaux silencieux sur l’ancienne machine et de journaux propres sur la nouvelle — ce délai est votre filet de retour arrière, et il coûte quelques dollars. Avant de résilier, vérifiez que rien d’externe ne pointe plus vers l’ancienne IP, renouvelez chaque secret qui a jamais vécu dessus, puis supprimez vos données et écrasez l’espace libre. Résiliez en dernier. Cliquer sur résilier en premier laisse votre base de données sur un disque que vous ne contrôlez plus. Guides connexes ## Continuer la lecture [### Comment choisir une juridiction d'hébergement offshore en 2026 Achat Un cadre de décision pratique pour choisir une juridiction offshore : loi sur la rétention de données, exposition aux MLAT, position face au DMCA, rapidité des tribunaux et application réelle — pays par pays. FAQ de 6 questions](https://servhidden.com/fr/guides/choosing-an-offshore-jurisdiction) [### VPS vs Serveur Dédié pour les Charges de Travail Sensibles à la Confidentialité Achat Quand un VPS suffit, quand la colocation est une responsabilité, et quand le bare metal est la seule réponse honnête. Isolation matérielle, risque hyperviseur, et coût vs modèle de menace. FAQ de 6 questions](https://servhidden.com/fr/guides/vps-vs-dedicated-for-privacy) [### VPN Auto-Hébergé sur un VPS Sans-KYC : WireGuard vs OpenVPN Exploitation Pourquoi un VPN auto-hébergé surpasse les fournisseurs commerciaux, et comment WireGuard et OpenVPN se comparent vraiment sur la confidentialité, les performances et le risque opérationnel en 2026. FAQ de 6 questions](https://servhidden.com/fr/guides/self-hosted-vpn-wireguard-vs-openvpn) [### RTX 4090 vs H100 SXM5 pour l'inférence IA (et où se situe le RTX 5090) Achat Guide d'achat : quel GPU NVIDIA pour des charges LLM auto-hébergées, image, vidéo, voix et finetuning en 2026. RTX 4090 vs RTX 5090 vs H100 SXM5 vs dual H100 — VRAM, débit, $/token, quand chacun gagne. FAQ de 6 questions](https://servhidden.com/fr/guides/rtx-4090-vs-h100-for-ai-inference) [### RDP Windows offshore pour le trading Forex MT4 / MT5 / cTrader Exploitation Guide complet : pourquoi un RDP Windows pour le trading Forex, comment choisir une juridiction offshore à faible latence, configuration MT4 / MT5 / cTrader / Expert Advisor, latence vers les serveurs de courtiers, et la voie de paiement sans KYC. FAQ de 6 questions](https://servhidden.com/fr/guides/offshore-windows-rdp-for-forex-trading) [### L’hébergement DMCA-ignoré expliqué : ce que cela signifie vraiment en 2026 Achat Ce que l’hébergement « DMCA ignoré » vous apporte réellement, quelles juridictions le soutiennent vraiment, les charges de travail qui en ont besoin, et les pièges en matière de droits d’auteur que le terme ne couvre pas. FAQ de 6 questions](https://servhidden.com/fr/guides/dmca-ignored-hosting-explained) [### Enregistrement de domaine anonyme avec crypto : confidentialité WHOIS en 2026 Confidentialité Un guide pratique 2026 pour enregistrer des domaines sans révéler votre identité : régimes WHOIS par extension, choix du bureau d’enregistrement, options de paiement en crypto, et les erreurs opérationnelles qui vous trahissent quand même. FAQ de 6 questions](https://servhidden.com/fr/guides/anonymous-domain-registration-with-crypto) [### Paiements Crypto pour l'Hébergement : Monero vs Bitcoin vs USDT Confidentialité Comment le choix de la monnaie affecte ce que votre hébergeur apprend sur vous. Confidentialité, frais, finalité et exposition à l'analyse de chaîne pour XMR, BTC et USDT — avec une recommandation claire. FAQ de 6 questions](https://servhidden.com/fr/guides/crypto-payments-monero-vs-bitcoin-vs-usdt) [### L’hébergement offshore est-il vraiment anonyme ? Une réponse honnête Confidentialité L’hébergement offshore sans KYC supprime l’identité qu’un hébergeur classique collecte — mais « anonyme » dépend du paiement, de la journalisation du fournisseur et de votre propre opsec. Voici ce qui est réellement traçable. FAQ de 6 questions](https://servhidden.com/fr/guides/is-offshore-hosting-truly-anonymous) [### La première heure de durcissement d’un VPS : une checklist Exploitation Une checklist concrète et ordonnée pour sécuriser un nouveau VPS en moins d’une heure : clés SSH, pare-feu, fail2ban, mises à jour automatiques, et la réduction de surface d’attaque qui stoppe la plupart des attaques opportunistes. FAQ de 6 questions](https://servhidden.com/fr/guides/first-hour-vps-hardening-checklist) [### Qu'est-ce que l'hébergement sans KYC ? Définition, légalité et fonctionnement Confidentialité L'hébergement sans KYC vous permet de louer un serveur sans aucune vérification d'identité — ni nom, ni e-mail, ni pièce d'identité. Voici exactement ce que cela signifie, comment ça fonctionne techniquement, si c'est légal, et comment choisir un vrai prestataire. FAQ de 6 questions](https://servhidden.com/fr/guides/what-is-no-kyc-hosting) [### L'hébergement offshore est-il légal ? La réponse honnête en 2026 Achat L'hébergement offshore est légal — pour vous comme pour le prestataire. Voici ce que le terme signifie vraiment, où se situe réellement la limite légale, les idées reçues à abandonner et comment l'utiliser de façon responsable. FAQ de 6 questions](https://servhidden.com/fr/guides/is-offshore-hosting-legal) [### Comment payer son hébergement avec Monero (XMR) — Guide étape par étape Confidentialité Un guide étape par étape pour payer un VPS ou un serveur dédié avec Monero (XMR) : pourquoi XMR est l'option la plus privée, comment l'obtenir, et comment fonctionne le paiement — de la facture à un serveur opérationnel en quelques minutes. FAQ de 6 questions](https://servhidden.com/fr/guides/how-to-pay-for-hosting-with-monero) [### Comment héberger un site web anonymement — Guide pratique 2026 Confidentialité Un guide pratique et structuré par couches pour héberger un site web sans identité attachée : le compte, le paiement, le domaine, la juridiction, votre connexion et le contenu — chaque couche expliquée. FAQ de 6 questions](https://servhidden.com/fr/guides/how-to-host-a-website-anonymously) [### Comment configurer un VPN WireGuard sur un VPS — Guide étape par étape Exploitation Créez votre propre VPN privé sur un VPS avec WireGuard : pourquoi un VPN auto-hébergé surpasse un service commercial, la configuration complète de l'installation à la connexion d'un client, et comment le renforcer. FAQ de 6 questions](https://servhidden.com/fr/guides/how-to-set-up-wireguard-vpn-on-a-vps) [### Comment héberger soi-même un LLM sur un serveur GPU — Guide 2026 Exploitation Faites tourner votre propre grand modèle de langage sur un serveur GPU loué : pourquoi l'auto-hébergement surpasse une API tierce, quel GPU et quel modèle choisir, la mise en place avec Ollama ou vLLM, et ce que ça coûte. FAQ de 6 questions](https://servhidden.com/fr/guides/self-host-an-llm-on-a-gpu-server) [### Hébergement bulletproof vs hébergement offshore — Quelle est la différence ? Achat Hébergement bulletproof et hébergement offshore sont constamment confondus — et pourtant ce n'est pas la même chose. Voici la vraie différence, pourquoi elle compte, et lequel des deux vous recherchez réellement. FAQ de 6 questions](https://servhidden.com/fr/guides/bulletproof-vs-offshore-hosting) [### Comment acheter un VPS avec Bitcoin — Guide étape par étape (2026) Achat Un guide accessible pour acheter un VPS avec Bitcoin : obtenir des BTC, choisir un plan, régler la facture et ce que vous obtenez — un serveur opérationnel sans carte bancaire et sans nom associé. FAQ de 6 questions](https://servhidden.com/fr/guides/how-to-buy-a-vps-with-bitcoin) [### Meilleurs pays pour un hébergement ignorant le DMCA en 2026 Achat Où héberger vos serveurs hors de portée des suppressions à l'américaine : les juridictions qui fonctionnent vraiment, ce que « ignorer le DMCA » signifie concrètement, et comment choisir. FAQ de 6 questions](https://servhidden.com/fr/guides/best-countries-for-dmca-ignored-hosting) [### Comment héberger un service caché Tor (site .onion) — Guide 2026 Exploitation Configurez un service onion Tor sur un VPS : ce qu'est un service caché, pourquoi c'est la forme d'hébergement anonyme la plus robuste, la mise en place complète et comment préserver réellement son anonymat. FAQ de 6 questions](https://servhidden.com/fr/guides/how-to-host-a-tor-hidden-service) [### Configuration d'un serveur mail offshore — Hébergez votre messagerie privée en 2026 Exploitation Gérez votre propre serveur de messagerie privé sur un VPS offshore : pourquoi auto-héberger vos emails, ce dont vous avez besoin, la mise en place concrète avec une solution tout-en-un, et comment assurer la délivrabilité. FAQ de 6 questions](https://servhidden.com/fr/guides/offshore-mail-server-setup) [### Guide d'hébergement de nœud crypto — Faire tourner un nœud blockchain sur un VPS Exploitation Comment héberger un nœud blockchain sur un serveur : pourquoi faire tourner son propre nœud, dimensionner le serveur pour Bitcoin, Ethereum, Monero et d'autres chaînes, la mise en place, et comment conserver sa confidentialité. FAQ de 6 questions](https://servhidden.com/fr/guides/crypto-node-hosting-guide) [### Hébergement GPU pour Stable Diffusion — Faites tourner votre propre serveur d'images Exploitation Faites tourner Stable Diffusion sur votre propre serveur GPU : pourquoi héberger soi-même la génération d'images, quel GPU choisir, la mise en place avec une interface web, et ce que cela coûte par rapport à un service hébergé. FAQ de 6 questions](https://servhidden.com/fr/guides/gpu-hosting-for-stable-diffusion) [### OpSec serveur — Rester anonyme quand on gère un serveur Confidentialité Sécurité opérationnelle pour toute personne gérant un serveur anonyme : les erreurs qui permettent de désanonymiser, les habitudes qui les préviennent, et comment maintenir une identité vraiment séparée. FAQ de 6 questions](https://servhidden.com/fr/guides/server-opsec-staying-anonymous) [### Guide de configuration d'une seedbox — Créez votre propre seedbox privée en 2026 Exploitation Comment créer sa propre seedbox sur un serveur : ce qu'est une seedbox, comment la dimensionner, installer un client torrent avec interface web, et la maintenir privée et sécurisée. FAQ de 6 questions](https://servhidden.com/fr/guides/seedbox-setup-guide) [### Comment contourner la censure DPI avec votre propre VPS (guide 2026) Confidentialité Votre VPN a cessé de fonctionner ? Comment contourner la censure DPI avec votre propre VPS : ce que l'inspection approfondie des paquets détecte réellement, lequel des cinq protocoles de 2026 bat quel type de blocage, et un guide complet de déploiement VLESS+REALITY. FAQ de 6 questions](https://servhidden.com/fr/guides/bypass-dpi-censorship-with-your-own-vps) [### Chiffrement intégral du disque sur un VPS : configuration LUKS Exploitation Comment chiffrer un VPS avec LUKS : volumes de données chiffrés, chiffrement intégral de la racine avec déverrouillage SSH, les réglages qui comptent sur un petit serveur, et ce que le chiffrement empêche vraiment. FAQ de 8 questions](https://servhidden.com/fr/guides/full-disk-encryption-on-a-vps) [### Masquer l'IP d'origine : CDN, reverse proxy et fuites Confidentialité Faut-il un CDN devant un serveur offshore : ce qu'il masque, le service abus hérité, les six fuites d'IP d'origine possibles, et comment auditer la vôtre. FAQ de 8 questions](https://servhidden.com/fr/guides/hiding-your-origin-server-ip) [### Sauvegarde VPS chiffrée et hors site : la stratégie qui restaure vraiment Exploitation Votre hébergeur ne conserve aucune sauvegarde. Ce qui détruit un serveur, restic contre Borg, les clés qu’on oublie, et comment tester une restauration. FAQ de 8 questions](https://servhidden.com/fr/guides/vps-backup-strategy) [### Auto-héberger Matrix : fédération, métadonnées et limites du chiffrement E2EE Exploitation Ce qu'un serveur Matrix auto-hébergé change : Synapse ou Conduit, le server_name qu'on ne change jamais, les médias qui saturent le disque, ce que révèle la fédération. FAQ de 8 questions](https://servhidden.com/fr/guides/self-host-a-matrix-server) [### How to Self-Host a Crypto Payment Gateway with BTCPay Server Exploitation Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out. FAQ de 8 questions](https://servhidden.com/fr/guides/self-host-a-crypto-payment-gateway) ## Donnez à la migration un endroit où atterrir Des serveurs KVM offshore dans sept juridictions à partir de $7.50/mo, avec accès root complet, stockage NVMe et bande passante illimitée, déployés en moins de cinq minutes dès qu’un paiement crypto est confirmé. Lancez la destination tôt, copiez à votre rythme, et basculez quand elle est prête. [Voir les offres VPS](https://servhidden.com/fr/vps) [Hébergement offshore](https://servhidden.com/fr/offshore-hosting) [Toutes les localisations](https://servhidden.com/fr/locations) ## Structured data (JSON-LD) ```json { "@context": "https://schema.org", "@type": "Organization", "@id": "https://servhidden.com/#organization", "name": "ServHidden", "url": "https://servhidden.com", "description": "VPS et serveurs dédiés offshore dans 7 juridictions privacy-friendly. Sans KYC, sans logs, crypto uniquement. La vie privée par architecture.", "logo": { "@type": "ImageObject", "url": "https://servhidden.com/ServHidden.webp", "width": 512, "height": 512 }, "foundingDate": "2025", "areaServed": [ { "@type": "Country", "name": "Iceland" }, { "@type": "Country", "name": "Panama" }, { "@type": "Country", "name": "Moldova" }, { "@type": "Country", "name": "Romania" }, { "@type": "Country", "name": "Switzerland" }, { "@type": "Country", "name": "Netherlands" }, { "@type": "Country", "name": "Russia" } ], "knowsAbout": [ "Offshore hosting", "Offshore VPS", "Bare-metal dedicated servers", "DMCA-ignored hosting", "No KYC hosting", "Cryptocurrency payments", "Privacy engineering", "Token-based authentication", "Anonymous domain name registration", "No-KYC domain registrar", "WHOIS privacy", "Cheap .com domains", "Crypto-paid domain names", "NVIDIA GPU compute", "Windows RDP hosting", "Agentic commerce" ], "contactPoint": { "@type": "ContactPoint", "contactType": "customer support", "url": "https://servhidden.com/contact", "availableLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] }, "sameAs": [ "https://servhidden.com/canary", "https://servhidden.com/press" ] } ``` ```json { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://servhidden.com/#website", "url": "https://servhidden.com", "name": "ServHidden", "publisher": { "@id": "https://servhidden.com/#organization" }, "inLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] } ``` ```json { "@context": "https://schema.org", "@type": "Article", "headline": "Migrer un site vers un hébergeur offshore sans interruption", "description": "L’ordre qui rend une migration d’hébergeur ennuyeuse : baisser le TTL DNS plusieurs jours à l’avance, faire tourner les deux serveurs en parallèle, geler les écritures pendant des minutes plutôt que des heures — et nettoyer la trace laissée par le DNS passif, les journaux Certificate Transparency et le WHOIS.", "image": "https://servhidden.com/assets/img/guides/migrate-website-to-offshore-hosting.webp?v=1787969426", "author": { "@type": "Organization", "@id": "https://servhidden.com/#editorial", "name": "ServHidden Editorial", "url": "https://servhidden.com/about", "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.", "knowsAbout": [ "Offshore hosting jurisdictions", "Data retention law", "MLAT and judicial cooperation", "WireGuard and OpenVPN deployment", "Tor relay operation", "Monero and Bitcoin payment privacy", "KVM virtualization and bare-metal hosting", "DMCA-ignored hosting" ], "parentOrganization": { "@id": "https://servhidden.com/#organization" } }, "publisher": { "@id": "https://servhidden.com/#organization" }, "datePublished": "2026-08-29T00:00:00+00:00", "dateModified": "2026-08-29T00:00:00+00:00", "mainEntityOfPage": "https://servhidden.com/guides/migrate-website-to-offshore-hosting", "inLanguage": "fr", "keywords": "migrer un site vers un hébergeur offshore, changer d’hébergeur sans interruption, migration de serveur sans temps d’arrêt, déménager un VPS vers un nouvel hébergeur, bascule DNS TTL, migrer vers un hébergeur no-KYC, checklist de migration de site web, migration de serveur avec rsync", "articleSection": "Exploitation", "wordCount": 3819 } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Combien d’interruption dois-je vraiment prévoir ?", "acceptedAnswer": { "@type": "Answer", "text": "Pour un site statique, aucune — les deux serveurs peuvent servir le même contenu simultanément, donc le changement DNS est invisible. Pour tout ce qui a une base de données, votre interruption dure exactement le temps de votre gel des écritures, typiquement deux à dix minutes si vous avez déjà effectué une copie complète des données au préalable. Le chiffre qui compte n’est pas la vitesse à laquelle le DNS bouge ; c’est la quantité que vous copiez pendant la fenêtre. Copiez presque tout plusieurs jours à l’avance, et la fenêtre se réduit à la taille du delta." } }, { "@type": "Question", "name": "Combien de temps prend la propagation DNS ?", "acceptedAnswer": { "@type": "Answer", "text": "Il n’y a pas de propagation — ce mot décrit quelque chose qui n’existe pas. Les résolveurs mettent simplement votre enregistrement en cache pour la durée indiquée par son TTL, et le redemandent à l’expiration. Si le TTL en vigueur était de 86 400, certains résolveurs continueront à servir l’ancienne IP pendant encore 24 heures. Baissez le TTL à 300 secondes au moins une pleine période de l’ancien TTL avant la bascule, et Internet tout entier suit votre changement en moins de cinq minutes." } }, { "@type": "Question", "name": "Dois-je aussi déplacer mon domaine ?", "acceptedAnswer": { "@type": "Answer", "text": "Non. Le bureau d’enregistrement et l’hébergeur sont totalement indépendants, et déplacer le site en laissant le domaine exactement où il est fonctionne parfaitement. Savoir si vous devriez le déplacer dépend de votre raison de migrer : si c’était la juridiction, le prix ou la posture DMCA, ne touchez pas au domaine. Si c’était l’anonymat, notez que le domaine porte sa propre histoire séparée — les archives WHOIS conservent les informations avec lesquelles il a été enregistré la première fois, et les changements d’hébergement n’y changent rien." } }, { "@type": "Question", "name": "Puis-je migrer sans que l’ancien hôte apprenne où je suis allé ?", "acceptedAnswer": { "@type": "Answer", "text": "Pas si vous copiez directement entre les deux machines — une extrémité se connecte à l’autre, et les deux journaux d’accès l’enregistrent. Si ce lien compte vraiment pour votre modèle de menace, ne copiez pas du tout d’hôte à hôte : restaurez le nouveau serveur depuis votre propre sauvegarde chiffrée hors site, pour que les deux fournisseurs n’échangent jamais le moindre paquet. Dans tous les cas, n’initiez jamais le transfert depuis une connexion qui vous identifie, et ne mentionnez jamais la destination dans un ticket de support ouvert auprès de l’ancien fournisseur." } }, { "@type": "Question", "name": "Faut-il mettre à jour l’OS ou la pile en même temps ?", "acceptedAnswer": { "@type": "Answer", "text": "Non, et c’est l’échec de migration auto-infligé le plus courant. Changez une seule chose. Si le site se comporte mal après la bascule, vous voulez une seule explication candidate, pas un choix entre la nouvelle machine, la nouvelle version de PHP et la nouvelle version majeure de base de données. Reproduisez l’ancien environnement version par version, terminez le déménagement, confirmez une semaine de journaux propres, puis mettez à jour séparément, avec la possibilité de revenir en arrière." } }, { "@type": "Question", "name": "La migration va-t-elle nuire à mon référencement ?", "acceptedAnswer": { "@type": "Answer", "text": "Pas significativement, à condition que le domaine, les URL et le contenu restent les mêmes — Google indexe des URL, pas des adresses IP, et un changement d’hébergeur en soi n’est pas un signal de classement. Gardez une structure d’URL identique, renvoyez les mêmes codes de statut, et ne combinez pas le déménagement avec une refonte ou un changement de schéma d’URL. Si vous passez plutôt à un nouveau domaine, attendez-vous à une baisse temporaire même avec des redirections 301 correctes, et comprenez que ces redirections relient aussi publiquement les deux noms." } }, { "@type": "Question", "name": "Dois-je réémettre les certificats TLS ?", "acceptedAnswer": { "@type": "Answer", "text": "Oui — le nouveau serveur a besoin de son propre certificat et de sa propre clé privée, et recopier l’ancienne clé est une mauvaise habitude, même quand ça fonctionne techniquement. Émettez-le avant la bascule avec un challenge DNS-01, qui valide via un enregistrement TXT et réussit donc pendant que l’enregistrement A pointe encore vers l’ancien hôte. Attendre une validation HTTP-01 après le changement DNS garantit une période d’avertissements de certificat, pile dans la fenêtre que vous essayiez de protéger." } }, { "@type": "Question", "name": "Quand est-il sûr de résilier l’ancien serveur ?", "acceptedAnswer": { "@type": "Answer", "text": "Après une ou deux semaines de journaux silencieux sur l’ancienne machine et de journaux propres sur la nouvelle — ce délai est votre filet de retour arrière, et il coûte quelques dollars. Avant de résilier, vérifiez que rien d’externe ne pointe plus vers l’ancienne IP, renouvelez chaque secret qui a jamais vécu dessus, puis supprimez vos données et écrasez l’espace libre. Résiliez en dernier. Cliquer sur résilier en premier laisse votre base de données sur un disque que vous ne contrôlez plus." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Accueil", "item": "https://servhidden.com/fr/" }, { "@type": "ListItem", "position": 2, "name": "Guides Hébergement Privé", "item": "https://servhidden.com/fr/guides" }, { "@type": "ListItem", "position": 3, "name": "Migrer un site vers un hébergeur offshore sans interruption", "item": "https://servhidden.com/fr/guides/migrate-website-to-offshore-hosting" } ] } ```