Comment migrer des sites web en toute sécurité

Publié le 21 juin 2026

Une migration de site web sûre commence avant tout déplacement de fichiers. Si vous voulez savoir comment migrer des sites web en toute sécurité, la première tâche n’est pas de copier des données - c’est de réduire les inconnues. Nous vérifions la stack actuelle, gelons les changements inutiles, confirmons que les sauvegardes peuvent réellement être restaurées et construisons un chemin de retour arrière avant de toucher au DNS. C’est la partie que beaucoup d’équipes sautent, et plus tard les logs racontent tous la même histoire.

Les migrations échouent pour des raisons banales. Une tâche cron oubliée continue d’écrire dans l’ancienne base de données. Le DNS est basculé avant que le SSL soit prêt. Les règles de redirection sont copiées à moitié. Le cache fait paraître le nouveau site correct pour une personne et cassé pour toutes les autres. Rien de tout cela n’est spectaculaire, mais c’est coûteux. Une migration sûre repose surtout sur un séquençage discipliné.

Comment migrer des sites web en toute sécurité sans mauvaises surprises d’indisponibilité

Les migrations les plus propres commencent par un inventaire. Vous devez savoir exactement ce qui est déplacé, ce qui peut changer pendant le déplacement et quelles dépendances se trouvent hors du serveur. Cela signifie les fichiers du site web, les bases de données, le stockage des médias, les certificats SSL, les zones DNS, les tâches planifiées, le routage des e-mails, les intégrations API, les callbacks de paiement et les règles de pare-feu. Si le site utilise un CDN, un stockage d’images externe, un cache d’objets ou une recherche tierce, incluez-les aussi.

C’est là que les équipes trouvent les petits pièges. Une boutique WooCommerce peut dépendre d’un webhook de paiement pointant vers l’ancienne IP. Une application SaaS peut avoir des workers en arrière-plan sur une deuxième machine. Un site marketing peut être simple, mais le formulaire de contact envoie via un service SMTP restreint par le nom d’hôte du serveur. Les migrations sûres concernent rarement la page d’accueil. Elles concernent les limites.

Avant de déplacer quoi que ce soit, décidez quel type de migration vous effectuez. Un déplacement à l’identique d’un VPS vers un autre correspond à un niveau de risque. Passer d’un hébergement mutualisé à un VPS managé, changer de panneau de contrôle, mettre PHP à niveau et remplacer le serveur web Apache par Nginx en même temps, c’est une tout autre affaire. Vous pouvez effectuer plusieurs changements à la fois, mais chaque variable supplémentaire ralentit le dépannage. Si possible, séparez les changements d’infrastructure des changements applicatifs.

Commencez par des sauvegardes que vous avez déjà testées

Tous les fournisseurs disent que des sauvegardes existent. C’est bien, mais une sauvegarde n’est utile que si elle se restaure proprement et assez vite pour votre objectif de reprise. Créez une nouvelle sauvegarde des fichiers et des bases de données immédiatement avant la migration. Conservez aussi une copie à l’extérieur de l’environnement source, afin de ne pas dépendre d’une seule plateforme au bon vouloir du jour.

Si le site est important pour le chiffre d’affaires, effectuez une restauration de test dans un environnement de staging. Ouvrez le site restauré, vérifiez la connectivité à la base de données, contrôlez les permissions des fichiers et assurez-vous que les médias se chargent. Si vous ne pouvez pas tester toute l’application, confirmez au moins que l’archive de sauvegarde est complète et que le dump de base de données est lisible. Ce n’est pas un travail glamour, mais expliquer à la comptabilité pourquoi les commandes de la nuit dernière ont disparu dans la forêt ne l’est pas non plus.

Gelez les changements pendant la fenêtre de migration

Les modifications de contenu, les installations de plugins et les déploiements de code pendant la migration créent des problèmes de divergence. Un système est mis à jour, l’autre non, et plus personne n’est sûr de savoir quelle version est réelle. Définissez un court gel des changements. Pour les sites riches en contenu ou transactionnels, utilisez le mode maintenance ou mettez les parties critiques en lecture seule pendant la synchronisation finale.

Pour l’e-commerce, les réservations ou le contenu généré par les utilisateurs, prévoyez une synchronisation delta. Copiez l’essentiel des fichiers et des données à l’avance, puis effectuez une synchronisation finale pendant la fenêtre de bascule afin de capturer les changements de dernière minute. Cela maintient l’indisponibilité à un niveau faible sans risquer de dérive des données.

Construisez l’environnement cible avant la bascule

Une erreur courante consiste à traiter le serveur de destination comme une boîte vide qui pourra être configurée plus tard. Une migration sûre fonctionne dans l’autre sens. L’environnement cible doit être prêt avant le changement : OS corrigé, stack web installée, version de PHP confirmée, base de données optimisée, SSL préparé, sauvegardes planifiées et surveillance activée.

Respectez d’abord les exigences de l’application, puis améliorez prudemment. Si l’ancien site fonctionne sous PHP 7.4 et que l’application n’est pas certifiée pour PHP 8.2, le jour de la migration n’est pas le moment de jouer les héros. Vous pourrez moderniser une fois la stabilité confirmée. Le calme d’abord, l’optimisation ensuite.

Les permissions et la propriété méritent une attention particulière. De nombreux incidents de type « le site a été migré mais les téléversements échouent » ne sont que des problèmes de propriété utilisateur/groupe incorrecte ou de chemins inscriptibles manquants. Passez aussi en revue les tâches cron, les workers de file d’attente et les tâches planifiées. Un site peut se charger correctement alors qu’un traitement important en arrière-plan s’est discrètement arrêté il y a une heure.

Testez avec un fichier hosts ou une URL temporaire

Ne pointez pas le DNS en production tant que le site n’a pas été vérifié sur le nouveau serveur. Utilisez une surcharge du fichier hosts ou un domaine de prévisualisation temporaire pour tester l’application en privé. Parcourez les pages clés, soumettez des formulaires, connectez-vous en tant qu’admin, passez une commande de test si pertinent et vérifiez l’envoi des e-mails. Vérifiez les images, la recherche, les API, les actions d’administration et tout ce qui est lié aux sessions ou à la mise en cache.

Allez au-delà des vérifications visuelles. Examinez les logs d’erreur, les logs du serveur web, l’état de PHP-FPM, les requêtes lentes de base de données et l’utilisation du disque. Confirmez que les redirections fonctionnent comme prévu. Assurez-vous que les URL canoniques, les règles robots et les variables d’environnement sont correctes. Il est étonnamment facile de migrer un site de production avec un en-tête noindex de staging encore attaché. Les moteurs de recherche sont obéissants aux pires moments possibles.

DNS, TTL et planification de la bascule

Si vous apprenez comment migrer des sites web en toute sécurité, le DNS est l’endroit où la préparation porte ses fruits. Abaissez le TTL des enregistrements DNS concernés bien avant la fenêtre de migration, idéalement 24 à 48 heures à l’avance. Cela aide les résolveurs à se rafraîchir plus vite lorsque vous basculez le site vers le nouveau serveur. Cela ne garantit pas une propagation mondiale instantanée, mais réduit la durée pendant laquelle les utilisateurs peuvent atteindre l’ancien emplacement.

Lors de la bascule, ne mettez à jour que ce qui est nécessaire. En général, cela signifie l’enregistrement A, peut-être AAAA, et parfois les enregistrements liés au courrier si l’e-mail migre aussi. Veillez à ne pas mélanger migration de site web et migration des e-mails, sauf s’il existe une raison claire. Les combiner augmente le périmètre d’impact. La plus belle migration est souvent celle qui a changé le moins de choses.

Gardez l’ancien serveur en vie pendant une période de chevauchement sûre. Même après le changement DNS, certains utilisateurs et bots atteindront encore l’ancien hôte pendant un moment. Pendant cette période, surveillez les logs d’accès sur les deux systèmes. Si l’ancien serveur reçoit encore un trafic significatif, gardez-le disponible et, si possible, orientez soigneusement l’activité d’écriture afin de ne pas perdre de données.

Surveillez les problèmes de cache et de SSL

Les caches CDN, les caches applicatifs et le cache local du navigateur peuvent masquer des problèmes après la migration. Purgez là où c’est nécessaire. Si un cache pleine page est utilisé, videz-le après la synchronisation finale et après la bascule DNS. Confirmez que l’origine CDN est mise à jour s’il en existe une.

Le SSL doit être prêt avant le changement, pas après. Installez les certificats sur le nouvel environnement, vérifiez la chaîne complète et testez le comportement de HTTP vers HTTPS. Des avertissements de contenu mixte peuvent apparaître si des URL d’assets codées en dur pointent encore vers l’ancien domaine ou protocole. Ce sont de petits détails, mais les utilisateurs remarquent l’icône de cadenas plus vite qu’ils ne remarquent votre planification soigneuse.

Redirections, SEO et intégrité de l’application

Si le domaine reste le même, le risque SEO est plus faible, mais les vérifications techniques restent importantes. Assurez-vous que les redirections de HTTP vers HTTPS, de www vers non-www ou l’inverse, ainsi que toutes les anciennes correspondances de chemins se comportent exactement comme prévu. Si le domaine change, utilisez des redirections 301 de manière exhaustive et mettez à jour les balises canoniques, les sitemaps et les références internes.

Ne lancez pas avec des chaînes de redirection si vous pouvez les éviter. Elles ralentissent les choses et créent un désordre d’indexation. Vérifiez aussi les pages d’erreur personnalisées, robots.txt, la génération du sitemap XML et les données structurées si le site en dépend. La migration ne se résume pas à « le site se charge ». C’est « le site se comporte correctement dans des conditions normales et limites ».

Pour les applications dynamiques, testez l’authentification, les sessions et les permissions avec de vrais rôles utilisateur. L’admin peut fonctionner alors que la connexion client échoue à cause de la portée des cookies, du stockage des sessions ou des en-têtes de proxy. C’est particulièrement courant derrière des load balancers ou des reverse proxies.

Le plan de retour arrière fait partie de la migration

Une migration n’est sûre que si le retour en arrière est possible. Définissez à l’avance les conditions de retour arrière. Par exemple : erreurs 5xx soutenues, échec du paiement, connexion cassée, régression sévère des performances ou incohérence des données. Définissez aussi qui prend la décision de retour arrière et combien de temps dure la fenêtre d’observation après la bascule.

Le retour arrière doit être assez simple pour être exécuté sous stress. Cela signifie généralement conserver l’ancien environnement intact, préserver l’ancien état de la base de données si possible et rétablir rapidement le DNS ou le routage du trafic. Si des écritures ont eu lieu sur le nouvel environnement, vous avez besoin d’une politique de réconciliation des données. C’est pourquoi les sites web transactionnels exigent une attention supplémentaire lors du changement final.

Surveillez de près pendant les premières 24 heures

Après la bascule, surveillez la disponibilité, le temps de réponse, le CPU, la mémoire, les E/S disque, la charge de la base de données, la validité du SSL, la profondeur de file d’attente et les tâches de sauvegarde. Surveillez aussi les signaux visibles par les utilisateurs : flux de commandes, formulaires de contact, succès de connexion et rapports d’erreurs. Une migration peut sembler correcte à la dixième minute et échouer à la troisième heure lorsque les tâches planifiées se déclenchent ou que le cache expire.

C’est là que le support managé justifie sa place. Une bonne surveillance détecte les pics de ressources, les services en échec et les problèmes de certificats avant que les clients ne deviennent votre système d’alerte. Pour les équipes sans grande profondeur ops en interne, cette couche opérationnelle sereine compte davantage qu’une case de plus dans un plan d’hébergement.

Une règle pratique pour des migrations plus sûres

Ne changez pas tout simplement parce que vous en avez enfin l’occasion. Déplacez d’abord, stabilisez ensuite, améliorez enfin. Cet ordre fait gagner du temps, même s’il paraît plus lent sur le papier. Si vous avez besoin d’aide pour savoir comment migrer des sites web en toute sécurité, le bon partenaire d’hébergement doit pouvoir vous assister non seulement avec le serveur lui-même, mais aussi avec les sauvegardes, la surveillance, la planification du retour arrière et les petits cas limites gênants qui n’apparaissent qu’après minuit.

Une bonne migration semble presque sans événement. C’est l’objectif. Des logs calmes, un trafic stable, des formulaires fonctionnels, aucune catastrophe cron mystérieuse et une équipe qui peut dormir après le changement DNS. Chez kodu.cloud, c’est généralement le standard que nous visons - pas tape-à-l’œil, simplement sous contrôle.

Andres Saar Ingénieur support client