"On migre le site ce week-end." Cette phrase a provoqué plus de nuits blanches et de crises de panique que n'importe quelle autre dans l'IT. Pourtant, une migration de serveur bien préparée peut se faire sans que personne ne s'en aperçoive. Même pas vos clients.
J'ai supervisé des dizaines de migrations, des petits sites vitrine aux plateformes e-commerce à fort trafic. Les catastrophes arrivent toujours pour les mêmes raisons : précipitation, manque de préparation, et absence de plan B.
Pourquoi les migrations tournent mal
La migration elle-même est rarement le problème. Ce qui plante, c'est tout ce qu'on a oublié de prendre en compte.
Les DNS mal gérés. Vous pointez vers le nouveau serveur, mais la propagation prend 24-48h. Pendant ce temps, certains visiteurs voient l'ancien site, d'autres le nouveau. Si vous avez coupé l'ancien trop tôt, une partie de vos clients tombe sur une erreur.
Les chemins de fichiers qui changent. L'ancien serveur avait les fichiers dans /var/www/html, le nouveau dans /home/user/public_html. Tous vos liens internes en dur sont cassés.
Les versions de PHP/MySQL différentes. Votre site tournait sur PHP 7.4, le nouveau serveur est en PHP 8.2. Surprise : des fonctions dépréciées font planter l'application.
Les emails oubliés. Vous avez migré le site, mais les emails étaient sur le même serveur. Résultat : plus personne ne reçoit de mail pendant 3 jours.
Les certificats SSL expirés. Le nouveau serveur n'a pas de certificat, ou il pointe vers l'ancien domaine. Chrome affiche un avertissement de sécurité terrifiant.
La méthode zero-downtime
L'idée est simple : faire coexister l'ancien et le nouveau serveur jusqu'à ce que tout soit validé, puis basculer de façon transparente.
Phase 1 : Préparation (J-7 à J-3)
Inventaire complet de l'existant. Pas juste "le site", mais tout ce qui tourne sur le serveur :
- Sites web (combien ? quelles technos ?)
- Bases de données (MySQL, PostgreSQL, autres ?)
- Services email (SMTP, IMAP, webmail ?)
- Crons et tâches planifiées
- Certificats SSL (dates d'expiration, type)
- Configurations spécifiques (htaccess, nginx, php.ini)
Configuration du nouveau serveur à l'identique. Mêmes versions de PHP, mêmes extensions, mêmes configurations. Le but : que l'application ne voie aucune différence.
Phase 2 : Copie et tests (J-2 à J-1)
Copie complète des fichiers et bases de données sur le nouveau serveur. Pas via FTP (trop lent, risque d'erreur), mais via rsync ou un outil de migration dédié.
Test du site sur le nouveau serveur via le fichier hosts local. Modifiez votre fichier hosts pour pointer le domaine vers la nouvelle IP. Vous seul voyez le nouveau serveur, le reste du monde voit l'ancien. Testez tout : pages, formulaires, paiements, espace client.
Pour les migrations complexes impliquant des applications métier, un accompagnement en infogérance sécurise le processus et garantit la continuité de service.
Phase 3 : Synchronisation finale (Jour J)
Juste avant la bascule DNS, resynchronisation des données. Les fichiers uploadés et les entrées en base depuis la première copie doivent être récupérés. Pour un site e-commerce, c'est critique : vous ne voulez pas perdre les commandes passées entre-temps.
Deux approches :
- Maintenance planifiée : 30 minutes de "site en maintenance" pendant la synchro finale. Honnête et sans risque.
- Réplication temps réel : les deux serveurs restent synchronisés en permanence. Plus complexe, mais zéro interruption.
Phase 4 : Bascule DNS
Réduisez le TTL de vos DNS à 300 secondes (5 minutes) au moins 48h avant la migration. Ainsi, la propagation sera quasi instantanée le jour J.
Changez les enregistrements DNS pour pointer vers le nouveau serveur. Surveillez la propagation avec des outils comme whatsmydns.net.
Gardez l'ancien serveur actif pendant 48-72h. Si quelque chose tourne mal, vous pouvez revenir en arrière en quelques minutes.
Le cas particulier des sites e-commerce
Un site vitrine peut tolérer quelques minutes d'indisponibilité. Un e-commerce, non. Chaque minute de downtime, c'est du chiffre d'affaires perdu et des clients qui ne reviendront peut-être pas.
Pour les boutiques en ligne, la stratégie recommandée :
Migration en heures creuses. Analysez vos statistiques : quand avez-vous le moins de trafic ? Souvent entre 3h et 6h du matin. C'est le moment idéal.
Page de maintenance élégante. Si vous devez couper, affichez une page professionnelle avec une estimation de retour, pas une erreur 500 brute.
Communication préalable. Prévenez vos clients par email : "Maintenance prévue dimanche 4h-5h". La transparence rassure.
Après la migration : les vérifications
La migration n'est pas finie quand le site s'affiche. Elle est finie quand tout fonctionne parfaitement depuis au moins une semaine.
Points de contrôle post-migration :
- Toutes les pages s'affichent correctement
- Les formulaires envoient bien les emails
- Le HTTPS fonctionne sans avertissement
- Les redirections 301 sont en place
- Google Search Console ne signale pas d'erreurs
- Les performances sont au moins équivalentes
- Les sauvegardes automatiques fonctionnent
- Les crons s'exécutent aux bonnes heures
Quand faire appel à un pro ?
Migrer un petit site WordPress, vous pouvez le faire vous-même avec les bons tutoriels. Mais certaines situations justifient de déléguer :
- Site e-commerce avec plus de 100 commandes/jour
- Application métier critique (ERP, CRM connecté)
- Infrastructure complexe (plusieurs serveurs, load balancing)
- Aucune marge d'erreur acceptable
- Pas de compétences techniques en interne
Le coût d'une migration ratée (perte de données, downtime prolongé, clients perdus) dépasse toujours le coût d'un accompagnement professionnel. C'est un calcul simple.
Une migration réussie est une migration invisible. Vos clients ne doivent jamais savoir qu'elle a eu lieu.
