Comment migrer le serveur d’un site web sans interruption

Publié le 15 juillet 2026

Commencez la migration avec une sauvegarde complète et restaurable, ainsi qu’un plan de bascule écrit. C’est la réponse la plus sûre à la question de savoir comment migrer l’infrastructure d’un serveur de site web sans transformer un déplacement de routine en panne. Votre nouveau serveur doit être déployé, sécurisé et testé avant que le DNS n’y dirige le moindre visiteur. L’ancien serveur reste en ligne jusqu’à ce que le nouvel environnement ait passé de vraies vérifications.

Une migration de serveur ne se résume pas à copier les fichiers du site web. Le site web, la base de données, les tâches planifiées, le routage des e-mails, les certificats SSL, l’environnement d’exécution de l’application, le comportement du cache, les enregistrements DNS et les règles de pare-feu peuvent tous faire partie du service. Il suffit d’oublier une petite dépendance pour qu’un site semble fonctionner correctement sur la page d’accueil alors que les e-mails de paiement, les formulaires ou les tâches en arrière-plan échouent discrètement. Ce n’est pas l’échec le plus spectaculaire, mais il peut quand même coûter cher.

Cartographiez le serveur actuel avant de le déplacer

Commencez par un inventaire de ce qui s’exécute réellement. Ne vous fiez pas uniquement à ce qu’affiche le panneau de contrôle de l’hébergement. Vérifiez la racine du document, la version de l’application, le moteur et la version de la base de données, les paramètres PHP ou Node.js, les tâches cron, les workers de file d’attente, les chemins de stockage, les redirections, les variables d’environnement et la configuration des e-mails sortants.

Pour un site web d’entreprise, identifiez aussi tout ce qui se trouve en dehors du domaine principal. Cela peut inclure des sous-domaines, des sites de préproduction, des points de terminaison d’API, des rappels de paiement, du stockage objet, des fournisseurs d’e-mails tiers, des scripts d’analyse et des enregistrements DNS utilisés pour la vérification. Si le serveur envoie les e-mails directement, notez son IP d’envoi, sa configuration de reverse DNS, ainsi que les enregistrements SPF, DKIM et DMARC. L’e-mail est souvent le dernier élément auquel on pense et le premier sujet de plainte des clients.

Documentez également l’utilisation des ressources du serveur actuel. Examinez la charge CPU, la consommation de mémoire, l’espace disque, la taille de la base de données, les modèles de trafic et les journaux d’erreurs. Cela vous indique si le nouveau VPS ou le serveur dédié est correctement dimensionné. Une migration est un bon moment pour laisser derrière soi un disque sous-dimensionné, une version de PHP obsolète ou un serveur qui survivait surtout grâce à l’optimisme.

Préparez d’abord le nouvel environnement

Provisionnez le serveur de destination avant de copier les données de production. Appliquez les mises à jour du système d’exploitation, créez un accès administratif restreint, configurez le pare-feu et n’installez que les services dont le site a besoin. Utilisez des clés SSH plutôt qu’un accès protégé uniquement par mot de passe lorsque c’est possible. Désactivez les services inutiles et assurez-vous que les mises à jour de sécurité automatiques correspondent à votre politique opérationnelle.

Respectez soigneusement les exigences de l’application. Un site passant de PHP 7.4 à PHP 8.3, ou de MySQL à une version plus récente de MariaDB, peut nécessiter des modifications de code avant de se comporter correctement. Il en va de même pour la configuration du serveur web. Les règles de réécriture Apache, les emplacements Nginx, les permissions de fichiers et les extensions PHP ne se transposent pas toujours à l’identique.

Mettez en place la supervision avant la bascule, pas après un incident. Surveillez la disponibilité, le temps de réponse, le CPU, la mémoire, l’utilisation du disque, l’expiration du SSL et les ports de service clés. Pour les applications avec traitement en arrière-plan, surveillez aussi la profondeur de file d’attente et les tâches échouées. Avec une infrastructure gérée et une supervision en place, les journaux racontent la même histoire dès maintenant, au lieu de vous laisser deviner après qu’un visiteur a signalé un problème.

Sauvegardez pour la reprise, pas seulement pour vous rassurer

Créez une nouvelle sauvegarde immédiatement avant la fenêtre de migration. Elle doit inclure les fichiers du site web, les bases de données, les fichiers de configuration, les téléversements générés par les utilisateurs et tous les secrets applicatifs stockés en dehors de la racine web. Vérifiez que la sauvegarde peut être restaurée dans un emplacement distinct. Une sauvegarde qui n’a jamais été testée n’est qu’une archive pleine d’espoir, pas un plan de reprise.

Pour les bases de données, utilisez une exportation cohérente. Les bases de données volumineuses ou actives peuvent nécessiter une gestion particulière afin d’éviter de copier des données pendant qu’elles changent. Selon la base de données et l’application, vous pouvez utiliser une fenêtre de maintenance, un mode lecture seule, la réplication ou une synchronisation incrémentielle finale. Les boutiques e-commerce, les systèmes de réservation, les produits SaaS et les sites d’adhésion nécessitent une attention particulière, car des commandes et des modifications de comptes peuvent arriver à chaque minute.

Conservez le serveur d’origine inchangé pendant le déplacement. Ne l’annulez pas et n’effacez pas les données dès que les fichiers apparaissent sur la destination. Conserver l’ancien environnement vous offre un chemin de retour propre si une dépendance cachée apparaît après le basculement.

Transférez les fichiers et les bases de données par étapes

Copiez le jeu de données initial pendant que le site existant reste en ligne. Des outils de transfert de fichiers sécurisés comme rsync sur SSH sont utiles, car ils peuvent synchroniser uniquement les fichiers modifiés lors d’un dernier passage final. Pour les bases de données, importez le dump initial sur le nouveau serveur, puis testez l’application avec celui-ci à l’aide d’un nom d’hôte temporaire ou d’une surcharge locale du fichier hosts.

Évitez de ne tester que la page d’accueil. Connectez-vous en tant qu’administrateur et en tant qu’utilisateur standard. Soumettez un formulaire de contact, réinitialisez un mot de passe, téléversez un fichier, effectuez un achat de test si nécessaire, examinez les e-mails de transaction et confirmez que les tâches planifiées fonctionnent. Vérifiez les journaux de l’application et les journaux d’erreurs du serveur web pendant les tests. Une réponse HTTP 200 réussie ne prouve pas que le service est sain.

Si vous changez aussi d’architecture serveur en même temps, isolez les changements lorsque c’est possible. Par exemple, passer à un nouveau VPS représente déjà assez de travail sans en plus refondre la base de données, remplacer la couche de cache et mettre à niveau le framework applicatif dans la même soirée. Des projets séparés rendent les échecs plus faciles à diagnostiquer et à annuler.

Réduisez le TTL DNS avant la bascule

Le DNS est l’endroit où une migration techniquement réussie peut devenir déroutante pour les visiteurs. Réduisez le TTL des enregistrements A, AAAA, CNAME et liés au courrier 24 à 48 heures avant le basculement prévu. Un TTL plus faible encourage les résolveurs à actualiser plus rapidement les enregistrements une fois que vous pointez le domaine vers le nouveau serveur.

Cela ne garantit pas que tous les résolveurs se mettront à jour instantanément. Certains réseaux mettent en cache plus longtemps que demandé, et les utilisateurs peuvent avoir un cache DNS local. Prévoyez une période de transition pendant laquelle une petite partie du trafic peut encore atteindre l’ancien serveur. Si le site accepte des données changeantes, vous avez besoin d’une stratégie pour gérer ce chevauchement. Un mode maintenance pendant la synchronisation finale est souvent plus sûr que d’accepter de nouvelles commandes sur deux serveurs distincts.

Ne modifiez pas les nameservers à moins d’avoir aussi une raison de déplacer l’hébergement DNS. Changer les nameservers faisant autorité ajoute une couche supplémentaire de propagation et davantage d’enregistrements à valider. Gardez la migration aussi ennuyeuse que possible. Une infrastructure ennuyeuse est généralement une infrastructure saine.

Exécutez la synchronisation finale et basculez le trafic

À l’heure de bascule convenue, mettez l’application en mode maintenance si elle écrit des données client. Arrêtez les workers de file d’attente et les tâches planifiées sur l’ancien serveur afin qu’ils ne puissent pas traiter la même tâche deux fois. Exécutez la synchronisation finale des fichiers ainsi que l’exportation/importation de la base de données, puis mettez à jour la configuration de destination avec les identifiants de la base de données de production, les clés de l’application et les URL correctes.

Activez l’application sur le nouveau serveur et mettez à jour le DNS avec son adresse IP. Confirmez que le certificat SSL est installé et que HTTP redirige correctement vers HTTPS. Si un équilibreur de charge, un CDN ou un proxy se trouve devant le site, mettez à jour sa configuration d’origine et vérifiez qu’il reconnaît les contrôles d’état du nouveau serveur.

Surveillez les deux serveurs pendant la propagation. Le nouveau serveur doit afficher des requêtes entrantes, tandis que l’ancien serveur doit recevoir progressivement moins de trafic. Examinez les erreurs 404, 500 et de permissions, ainsi que les alertes propres à l’application. Surveillez l’utilisation des ressources, car un nouveau serveur peut se comporter différemment sous trafic réel que pendant les tests.

Validez le service après la migration

Une fois que le trafic arrive dans le nouvel environnement, effectuez une vérification de production ciblée. Confirmez que les pages principales se chargent, que les utilisateurs peuvent s’authentifier, que les formulaires sont bien transmis, que les parcours de paiement ou de réservation fonctionnent, que les tableaux de bord affichent des données actuelles et que les fichiers téléversés sont accessibles. Testez depuis plus d’un réseau si possible, car votre propre ordinateur peut encore avoir du DNS en cache.

Vérifiez les activités planifiées au cours des heures suivantes. Les tâches cron, les sauvegardes, les renouvellements, les rapports, les workers de file d’attente et les récepteurs de webhooks révèlent souvent des problèmes de migration une fois la validation initiale passée. Examinez aussi les journaux de messagerie et les rapports de livraison. Si le site utilise un service SMTP distant, confirmez que l’IP ou le nom d’hôte du nouveau serveur est autorisé.

Laissez l’ancien serveur disponible pendant au moins 48 à 72 heures, voire plus pour les applications complexes ou les environnements DNS lents. Pendant cette période, conservez les sauvegardes des deux côtés et n’effectuez pas de changements de configuration sans rapport. Une fois que la supervision est propre, que le trafic est stable et que la fenêtre de retour arrière est passée, mettez l’ancien serveur hors service en toute sécurité.

Sachez quand faire appel à une aide gérée

Un simple site vitrine peut généralement être déplacé avec une préparation soignée et une courte fenêtre de maintenance. Une boutique à fort trafic, un portfolio d’agence avec de nombreux sites clients, une plateforme SaaS ou un serveur avec des services personnalisés mérite un plan plus contrôlé. La réplication de base de données, les déploiements par étapes, le drainage du trafic et la supervision active réduisent le risque, mais ils nécessitent aussi des mains expérimentées.

kodu.cloud peut aider sur le plan opérationnel d’une migration, de la préparation du serveur de destination et des sauvegardes jusqu’à la supervision et à la validation. L’objectif n’est pas de rendre le processus mystérieux. Il s’agit de s’assurer que quelqu’un surveille l’infrastructure pendant que vous faites avancer l’activité.

Une bonne migration se termine discrètement : les visiteurs utilisent le site, les tâches planifiées s’exécutent, les sauvegardes se terminent et personne n’a besoin d’envoyer un message nerveux à toute l’équipe. Conservez le plan, la sauvegarde et l’ancien serveur jusqu’à ce que les preuves montrent que le service est redevenu calme.

Andres Saar Ingénieur Customer Care