BistrotWeb Bistrot Web — accueil
Demander un devis
← Retour à la prestation Migration & transfert 📋 Méthode & planning

Migrer un site, ce n'est pas changer d'opérateur téléphonique.

Quand vous changez de FAI, vous donnez un RIB, on vous envoie une box, vous la branchez. Pour un site web, il y a 6 phases, ~30 actions, et autant de pièges. Voici exactement comment on procède pour qu'aucun email, aucune URL et aucun référencement ne tombe en route.

Ce qu'on déménage exactement

Un "site web", dans le langage courant, c'est trois choses dont chacune vit chez un fournisseur différent et a sa propre logique de migration :

🌐

Le site lui-même

Fichiers HTML/CSS/JS, base de données pour les CMS, certificat SSL, fichiers uploadés (photos, PDF). Stocké chez l'hébergeur. Le plus simple à déménager — c'est juste de la copie.

📧

Les boîtes mail

Comptes IMAP, historique de plusieurs Go par boîte, règles de tri, signatures, alias. Souvent chez l'hébergeur du site — donc déménagent ensemble, mais ce sont deux migrations distinctes techniquement.

🗺️

Le DNS & le domaine

Records A, MX, TXT, SPF, DKIM. Vivent chez le registrar (OVH, Gandi, Cloudflare). C'est l'aiguillage : sans eux, votre nom de domaine ne sait pas où envoyer les visiteurs ni où acheminer les mails.

L'analogie qui ne marche pas : un FAI a un protocole standardisé pour transférer une ligne (portabilité numéro, validation 10 jours, automatique). Sur le web, il n'existe aucun standard de migration entre hébergeurs. Chaque cas est artisanal. C'est pour ça qu'il faut une méthode.

Notre planning type — 6 phases

Pour un site vitrine + 1 à 5 boîtes mail, comptez 5 à 7 jours ouvrés entre l'audit initial et la bascule effective. Voici la séquence exacte.

1

🔎 Audit initial

1-2 jours
  • ▸ Inventaire complet : URLs indexées, comptes mail, base de données, fichiers servis, plugins/modules CMS, certificats SSL
  • ▸ Lecture des configs DNS actuelles (registrar, MX, SPF, DKIM, DMARC, sous-domaines)
  • ▸ Test des accès à l'ancien hébergeur (FTP/SSH, panel, comptes IMAP)
  • ▸ Cartographie des dépendances cachées : webhooks, intégrations tierces, certificats expirés

Risque si on rate cette phase : Sans cet audit, vous découvrez les pépins le jour de la bascule (un compte mail oublié, un sous-domaine non documenté, un plugin qui parle à un service externe).

2

🛠️ Préparation staging

1-3 jours
  • ▸ Provisionnement du nouvel hébergeur (chez nous ou chez le prestataire de votre choix)
  • ▸ Copie des fichiers + base via SSH/SFTP, jamais en mode supprimer-puis-créer
  • ▸ Configuration des comptes mail en parallèle (sans toucher aux MX, donc l'ancien continue de recevoir)
  • ▸ Mise en place du staging sur un sous-domaine privé (ex. staging.votre-site.fr) avec auth basic
  • ▸ Test fonctionnel complet : navigation, formulaires, paiements, intégrations

Risque si on rate cette phase : L'erreur classique : tester directement sur le nouveau domaine avant la bascule, ce qui injecte des entrées dans le cache DNS public et complique le rollback.

3

📨 Synchro emails + TTL DNS bas

1-2 jours
  • ▸ Copie IMAP de tout l'historique de chaque boîte vers le nouveau serveur (IMAPSync ou équivalent)
  • ▸ Configuration des règles, signatures, alias, redirections internes
  • ▸ Réduction du TTL des records DNS à 300 s (5 min) sur l'ancien registrar — pour que la propagation post-bascule soit rapide
  • ▸ Vérification SPF/DKIM/DMARC sur le nouveau MX (sinon vos mails partent en spam)

Risque si on rate cette phase : Sans la baisse préalable du TTL DNS, certains visiteurs/clients verront l'ancien site pendant 24-48h après la bascule. C'est gérable, mais si vous attendez un trafic critique, c'est mieux d'avoir un TTL court.

4

🔄 Bascule DNS

Quelques minutes (mais propagation 1-4h)
  • ▸ Modification des records A/AAAA (pour le site) et MX (pour les mails) chez le registrar
  • ▸ Conservation de l'ancien hébergement actif en parallèle pendant 48-72h
  • ▸ Surveillance des logs : DNS lookups, mails entrants, erreurs 5xx
  • ▸ Activation du certificat SSL (Let's Encrypt) sur le nouveau serveur — automatique chez nous

Risque si on rate cette phase : Si on bascule avant d'avoir réduit le TTL, certains visiteurs voient l'ancien site pendant 1-2 jours. Si on coupe l'ancien hébergeur trop tôt, les mails reçus pendant la propagation DNS sont perdus.

5

🎯 Redirections SEO + validation

1-2 jours
  • ▸ Mise en place des redirections 301 page-à-page (souvent en .htaccess)
  • ▸ Soumission du nouveau sitemap à Google Search Console
  • ▸ Vérification crawl : on relance un crawl complet pour détecter les 404 résiduels
  • ▸ Test des formulaires en prod réel (avec votre adresse de réception)
  • ▸ Création d'un compte Search Console propre, vérification du domaine

Risque si on rate cette phase : Les redirections oubliées tuent le SEO. Une page qui pesait dans les résultats Google et qui répond 404 disparaît en 2-3 semaines de l'index.

6

✂️ Décommissionnement

1 jour, après J+30
  • ▸ Vérification que plus aucune requête ne tape l'ancien serveur (logs, DNS lookups)
  • ▸ Sauvegarde finale complète (fichiers + DB + emails) — archivée chez nous 30 jours minimum
  • ▸ Résiliation propre de l'ancien hébergement (vous, ou nous avec procuration)
  • ▸ Récupération du domaine si transfert de registrar (auth code, validation 5 jours)

Risque si on rate cette phase : Couper l'ancien serveur trop tôt = perdre des mails, des liens externes qui pointaient vers d'anciennes URLs sans redirection, ou un cron oublié qui tournait là-bas.

Les 5 pièges qu'on évite

Tirés de cas réels — ce sont les erreurs les plus courantes quand un client a déjà tenté de migrer seul et nous appelle pour réparer.

⚠️

Couper l'ancien hébergement avant que le DNS soit propagé

Les visiteurs dont le DNS pointe encore vers l'ancien serveur tombent sur du vide. On garde les deux actifs en parallèle 48-72h.

📭

Oublier la copie IMAP de l'historique mail

Le client se retrouve avec des nouvelles boîtes vides : 5 ans d'archives perdues. On copie tout l'historique avec IMAPSync avant la bascule MX.

🔗

Pas de redirections 301 page-à-page

Les liens externes (et les positions Google) pointent vers les anciennes URLs et se cassent. On crée une table de mapping et un fichier .htaccess complet.

🔐

SPF/DKIM/DMARC oubliés sur le nouveau serveur

Les mails sortants partent en spam chez Gmail/Outlook. On configure les 3 records avant la bascule, on teste avec mail-tester.com.

🕒

TTL DNS encore à 86400 secondes au moment de la bascule

La propagation prend 24h+ et certains visiteurs voient l'ancien site. On baisse le TTL à 300s 24h avant la bascule, on le remet à 3600s après.

🔌

Webhooks et intégrations tierces oubliés

Stripe, Mailchimp, Google Analytics, formulaires intégrés... pointent vers l'ancien domaine. On audite et on met à jour avant le décommissionnement.

Questions fréquentes

Combien de temps prend une migration de site ? +

Pour un site vitrine standard avec 1 à 5 boîtes mail, on planifie sur 5 à 7 jours ouvrés entre l'audit initial et la bascule DNS. Les sites e-commerce ou avec beaucoup de comptes mail montent à 10-15 jours. Le délai n'est pas tant le travail de migration que le respect des fenêtres TTL DNS et la phase de validation par le client.

Le site sera-t-il inaccessible pendant la migration ? +

Non. On copie d'abord, on ne supprime jamais. L'ancien site continue de tourner pendant qu'on prépare le nouveau sur un staging privé. La bascule DNS finale se fait par un changement de A/AAAA records — les visiteurs sont redirigés progressivement (selon leur résolveur DNS) sans interruption visible.

Et si je perds des emails pendant la bascule ? +

C'est exactement ce qu'on évite avec la procédure standard : on configure les nouvelles boîtes en parallèle, on copie l'historique IMAP avant la bascule, on garde les MX records de l'ancien hébergeur actifs 48h après le switch (pendant que le DNS se propage). Les mails reçus dans cette fenêtre sont récupérés et reposés dans les nouvelles boîtes.

Est-ce que mon SEO va chuter ? +

Pas si on fait les redirections correctement. Plan d'action systématique : audit des URLs indexées avant migration (via Search Console + crawl), mise en place des redirections 301 page-à-page, conservation des metadata, vérification du sitemap, soumission Search Console post-migration. Une perte temporaire de 5-10 % de positions pendant 2-3 semaines est normale, ça revient ensuite. Une perte durable ≥ 30 % est le signe d'une migration mal préparée.

Vous gérez aussi le changement de domaine (rebranding) ? +

Oui, mais c'est un cas plus complexe que le pur changement d'hébergeur — toutes les redirections doivent inclure le rewrite de domaine, les liens externes vont casser progressivement, le SEO prend un coup plus marqué (3-6 mois pour récupérer). Chiffré séparément.

Et si je veux juste être autonome après ? +

Parfait — c'est même le scénario nominal. On vous livre les sources (le code du site), les accès au nouvel hébergeur, la doc des comptes mail. Vous gérez la suite chez vous ou avec un autre prestataire. Aucune maintenance n'est imposée à la suite : c'est à vous de choisir si vous voulez nous garder dans la boucle.

Prêt à organiser votre migration ?

Donnez-nous l'URL actuelle, le nombre de boîtes mail à reprendre, et l'hébergeur cible (ou demandez-nous une recommandation). On revient sous 48h ouvrées avec un devis fixe et un planning daté.

Devis migration de site Voir la prestation détaillée
↗ Voir aussi

Vous pourriez aussi avoir besoin de…

Si cette prestation ne correspond pas à votre besoin, peut-être l'une de celles-ci.

🛡️

Site internet statique

Vitrine HTML/CSS, sans CMS ni base — donc impiratable.

Dès 690 € HT→
🔍

Audit de sécurité

Versions, plugins, configs : un rapport hiérarchisé en correctifs.

Dès 299 € HT→
🧪

Désinfection piratage

Site WordPress, PrestaShop ou Joomla compromis : on nettoie.

Dès 399 € HT→