T’as bossé des semaines sur ce site. Le code est propre, le staging est validé, le client est chaud. Il est temps de balancer ça en prod. Et là… tu fonces tête baissée et tu oublies des trucs basiques qui vont te coûter des heures de debug le soir à 22h.
Chez LRob, on accueille régulièrement des sites en migration — WordPress, PrestaShop, PHP en tout genre — et on voit toujours les mêmes erreurs revenir. Voici la checklist qu’on aurait aimé te donner avant.
Sommaire
1. Les TTL DNS : t’aurais dû y penser y’a 48h
Si tu migres vers un nouveau serveur, la propagation DNS ne se fait pas instantanément. Par défaut, un TTL est souvent à 3600 secondes (1 heure), parfois même à 86400 (24h). Pendant ce temps, une partie de tes visiteurs va encore atterrir sur l’ancien serveur.
Ce qu’il faut faire : 48 à 72h avant la migration, tu descends ton TTL entre 60 et 300 secondes (5 minutes). Comme ça, une fois que tu changes tes DNS, la propagation est quasi immédiate partout dans le monde.
Trop tard ? C’est trop tard. Prévois-le sur ta prochaine migration.
2. Le certificat SSL : génère-le dès que les DNS pointent
C’est logique mais ça se zappe constamment : dès que tes DNS pointent vers le nouveau serveur, génère ton certificat SSL immédiatement. Pas demain. Pas dans une heure. Maintenant.
Pourquoi ? Parce que le HTTPS est forcé — donc sans certificat valide sur le nouveau serveur, les visiteurs tombent sur une belle page d’erreur de certificat. Le genre de truc qui fait appeler le client en urgence pour un problème qui aurait pris 30 secondes à éviter.
Sur nos serveurs Plesk, c’est littéralement trois clics avec Let’s Encrypt. Aucune excuse.
3. Les emails : le carnage silencieux
Celui-là, c’est le boss final. Et il est vicieux parce que ça ne fait pas planter le site — ça plante juste les mails, et personne s’en rend compte avant que le client demande pourquoi sa boutique n’envoie plus de confirmations de commande depuis 3 jours.
Checklist à valider impérativement :
- L’adresse expéditeur appartient bien au domaine du site — pas à
contact@agence-du-dev.fr, pas à un Gmail, pas à l’adresse perso du dev. Si WooCommerce ou PrestaShop envoie depuisnoreply@monsite.com, c’estmonsite.comqui doit être configuré sur le serveur. - Le SPF est à jour — le nouveau serveur doit être autorisé à envoyer des mails au nom du domaine. Tu changes de serveur = tu mets à jour ton enregistrement SPF. Pas après. Maintenant. Renseigne-toi en amon, chez LRob ta règle SPF doit contenir :
include:_spf.lrob.net. - Le DKIM est configuré et actif — si tes DNS sont gérés chez LRob, c’est automatique. Si tes DNS sont ailleurs (OVH, Cloudflare, peu importe), tu dois récupérer la clé DKIM depuis Plesk, éventuellement générer un nouveau sélecteur pour éviter les conflits avec l’ancien serveur, puis aller coller manuellement l’enregistrement dans ta zone DNS. Ça ne se fait pas tout seul.
- Où sont gérés les emails ? C’est la question à se poser en premier. Deux cas :
- Les emails sont hébergés chez LRob : tout est configuré, rien à faire de particulier.
- Les emails sont ailleurs (Outlook 365, Google Workspace, etc.) : tu dois configurer le domaine dans Plesk en mode « Désactivé pour les mails entrants » (« Ce domaine peut uniquement envoyer des e-mails et uniquement avec Sendmail »). Sans ça, Plesk va chercher le destinataire en local quand le site envoie un mail vers une adresse du même domaine — et le mail disparaît dans le néant au lieu d’arriver dans ta boîte Outlook. Classique.
Pour tester : mail-tester.com ou mxtoolbox.com. Aucune raison de ne pas le faire avant de livrer.
4. La synchro des données : t’as pensé à ce qui a changé pendant la migration ?
Pour les sites statiques, bonne nouvelle : pas de problème. Pour tout le reste — WordPress avec des articles, PrestaShop avec des commandes, n’importe quel site avec une base qui bouge — il y a forcément eu des données créées sur l’ancien serveur pendant que tu préparais le nouveau.
Deux règles d’or :
- Prévois une dernière synchronisation juste avant le switch DNS — base de données, fichiers uploadés, tout.
- Passe l’ancien site en maintenance (ou suspend-le carrément) pendant la fenêtre de bascule — sinon tu risques d’avoir des commandes passées sur l’ancien serveur qui n’existent pas sur le nouveau. C’est ingérable.
La maintenance, c’est deux minutes à mettre en place. La désynchronisation de données, c’est des heures à réparer — si c’est encore rattrapable.
5. Le fichier hosts : ton meilleur ami pour tester avant tout le monde
Tu n’as pas encore changé les DNS publics mais tu veux tester le site sur le nouveau serveur en conditions réelles ? Modifie ton fichier hosts sur ton poste pour faire pointer le domaine vers la nouvelle IP.
- Windows :
C:\Windows\System32\drivers\etc\hosts - Mac/Linux :
/etc/hosts
Ajoute une ligne du type :
1.2.3.4 monsite.com www.monsite.comTu accèdes au nouveau serveur avec le vrai nom de domaine, tu testes les formulaires, le tunnel de commande, les redirections… bref, tu valides tout en conditions réelles. Le certificat SSL peut afficher une alerte si ce n’est pas encore généré — tu peux généralement l’outrepasser pour accéder quand même.
C’est pas du luxe, c’est la base.
6. Les logs : lis-les. Non, vraiment.
C’est le conseil le plus sous-estimé de cette liste. Lis les logs après la mise en prod. Pas dans trois jours. Dans les 30 minutes qui suivent.
Les logs te disent tout : erreurs PHP, ressources introuvables (404 sur des assets), requêtes qui timeout, plugins WordPress qui s’étouffent sur la nouvelle config… Des problèmes qui ne font pas planter le site visuellement mais qui dégradent l’expérience ou les performances. Qui peuvent aussi déclencher des sécurités chez LRob que tu ne trouves pas ailleurs. Donc teste avant.
Sur nos serveurs Plesk, les logs sont accessibles directement depuis l’interface. Pas besoin de SSH, pas besoin de droits particuliers. C’est là, sous tes yeux, et ça prend deux minutes à parcourir.
Si t’as mis en place un outil de monitoring d’erreurs (Sentry, etc.), vérifie aussi le tableau de bord dans la foulée.
En résumé
| # | Point critique | Quand |
|---|---|---|
| 1 | Baisser les TTL DNS | 48-72h avant |
| 2 | Générer le certificat SSL | Dès que les DNS pointent |
| 3 | Vérifier SPF, DKIM et l’expéditeur | Avant le switch |
| 4 | Synchroniser les données + mode maintenance | Pendant la bascule |
| 5 | Tester via le fichier hosts | Avant le switch DNS |
| 6 | Lire les logs | Dans les 30 min après |
En suivant ces 6 points, tu évites 90% des incidents post-déploiement qu’on voit passer.
Et si tu veux éviter de gérer tout ça toi-même : chez LRob, la migration est incluse dans les offres d’hébergement standard. Pour les revendeurs (offres Web Agency), elle est disponible en option. Et quand elle est payante, elle démarre à seulement 120€ — avec des options pour les migrations de nuit, les nombreuses boîtes mail ou les multi-sous-domaines.
Tous les points de cette checklist ? On les vérifie pour toi. 👉 Découvrir l’offre migration LRob
Laisser un commentaire