Quoi considérer lors de la migration vers un autre hébergeur web

La migration d’un site web vers un nouvel hébergeur est l’une des opérations d’infrastructure les plus risquées qu’un propriétaire de site puisse entreprendre. Effectuée correctement, elle entraîne zéro perte de données, un temps d’arrêt négligeable et des performances mesurables améliorées. Effectuée négligemment, elle produit des bases de données corrompues, des pannes DNS, des baisses de classement SEO et des heures de travail de récupération d’urgence.

Ce guide couvre chaque phase critique d’une migration d’hébergement — de l’audit pré-migration et la validation de compatibilité, en passant par les mécanismes de basculement DNS, jusqu’à la surveillance post-migration — avec la profondeur technique nécessaire pour l’exécuter sans incident.

Phase 1 : Auditez votre environnement d’hébergement actuel avant de toucher quoi que ce soit

La cause la plus fréquente d’échec de migration provient du fait de sauter un audit approfondi de l’environnement existant. Avant d’évaluer un nouvel hébergeur, vous avez besoin d’un inventaire précis de ce que vous faites réellement tourner.

Profilage du trafic et des ressources

Récupérez au moins 90 jours de données sur les ressources serveur — pas seulement les comptages de pages vues. Les métriques qui comptent sont :

• Connexions simultanées au pic — pas le trafic moyen, mais le plafond de pointe que votre serveur doit gérer
• Consommation mémoire par worker PHP ou processus applicatif
• Modèles d’I/O disque — particulièrement pertinent si vous exploitez une application intensive en base de données comme WooCommerce ou un CRM personnalisé
• Utilisation de la bande passante — totaux de transfert mensuels par rapport au plafond de votre plan actuel

Si votre hébergeur actuel fournit cPanel ou Plesk, ces données sont accessibles dans les sections d’utilisation des ressources ou AWStats. Sur un Linux VPS, exécutez ce qui suit pour capturer un instantané de référence :

vmstat 1 10
iostat -x 1 5
free -m
df -h

Cette sortie vous indique si votre goulot d’étranglement est le CPU, la RAM ou le disque — ce qui détermine directement si vous avez besoin d’un plan partagé plus grand, d’un VPS, ou d’un Serveur Dédié.

Inventaire de la pile logicielle

Documentez chaque composant de votre pile avec les numéros de version exacts :

• Version PHP (ex. : 8.1, 8.2) et extensions actives (mbstring, curl, gd, imagick, redis)
• Version MySQL ou MariaDB et moteur de stockage (InnoDB vs. MyISAM est important pour les outils de migration)
• Logiciel de serveur web : Apache, Nginx, LiteSpeed, ou une combinaison de proxy inverse
• Tout module compilé, règles .htaccess personnalisées, ou blocs nginx.conf de localisation
• Tâches cron — exportez-les depuis crontab -l et documentez-les séparément
• Type de certificat SSL et émetteur (Let’s Encrypt, CA commercial, wildcard)

Manquer même une extension PHP sur le serveur de destination peut silencieusement casser des fonctionnalités qui ne se manifestent que sous des actions utilisateur spécifiques — un bug notoirement difficile à tracer après la migration.

Phase 2 : Évaluez et sélectionnez le bon niveau d’hébergement

Choisir le mauvais niveau d’hébergement est une erreur structurelle qui force une seconde migration dans les mois suivants. Mappez les résultats de votre audit à la classe d’infrastructure correcte.

Comparaison des niveaux d’hébergement

Règle de décision clé : Si votre application nécessite une configuration de pool PHP-FPM spécifique, des connexions socket Redis, des réécritures Nginx personnalisées, ou tout processus démon, l’hébergement partagé est architecturalement incompatible. Vous avez besoin au minimum d’un VPS avec accès root.

Pour les sites WordPress ou Joomla avec un trafic modéré, un VPS avec cPanel fournit l’interface de panneau de contrôle familière tout en conservant l’isolation et les performances d’une machine virtuelle.

Critères d’évaluation des fournisseurs

Au-delà des arguments marketing, évaluez les fournisseurs sur ces facteurs techniques vérifiables :

• SLA de disponibilité avec clauses de pénalité financière — un SLA à 99,9% sans compensation n’a aucune valeur
• Niveau de certification du centre de données (Tier III ou Tier IV pour les charges de travail en production)
• Redondance réseau — multi-homing BGP, plusieurs fournisseurs en amont
• Type de stockage — NVMe SSD versus SATA SSD versus disque rotatif (les différences de latence sont significatives)
• Politique de sauvegarde — fréquence, période de rétention, si les sauvegardes sont stockées hors site
• SLA de temps de réponse du support — distinguez entre le temps de première réponse et le temps de résolution

Phase 3 : Créez et vérifiez une sauvegarde complète

Aucune migration ne doit commencer sans une sauvegarde vérifiée et restaurable. « Vérifiée » signifie que vous avez réellement testé la restauration — pas seulement confirmé qu’un fichier de sauvegarde existe.

Ce qu’une sauvegarde complète doit inclure

• Fichiers de la racine web — l’intégralité du répertoire racine des documents, y compris les fichiers cachés comme .htaccess et .env
• Toutes les bases de données — exportées sous forme de dumps .sql, pas seulement une copie de fichier du répertoire de base de données
• Données email — si vous utilisez un Hébergement Email lié à votre domaine, exportez les boîtes mail avant tout changement DNS
• Tâches cron — crontab -l > crontab_backup.txt
• Certificats SSL et clés privées — si vous utilisez un certificat commercial, exportez la chaîne complète
• Fichiers de configuration serveur — /etc/nginx/, /etc/apache2/, /etc/php/, paramètres my.cnf personnalisés

Effectuer un export de base de données

Pour MySQL/MariaDB, utilisez mysqldump avec des options qui préservent la fidélité complète :

mysqldump 
  --single-transaction 
  --routines 
  --triggers 
  --events 
  --set-gtid-purged=OFF 
  -u root -p your_database_name > database_backup_$(date +%F).sql

L’option --single-transaction est critique pour les tables InnoDB — elle prend un instantané cohérent sans verrouiller les tables, ce qui signifie que votre site en production continue de servir les requêtes pendant le dump.

Vérification de l’intégrité de la sauvegarde

# Check the SQL dump is not truncated
tail -5 database_backup_2024-01-15.sql

# Verify file count in web root backup
tar -tzf webroot_backup.tar.gz | wc -l

# Test restoration to a local or staging environment
mysql -u root -p test_restore_db < database_backup_2024-01-15.sql

Une sauvegarde dont vous n’avez pas testé la restauration n’est pas une sauvegarde — c’est un faux sentiment de sécurité.

Phase 4 : Validez la compatibilité sur le serveur de destination

Avant de transférer les données de production, démarrez le nouvel environnement et validez la compatibilité en utilisant une approche de staging.

Vérification de la version PHP et des extensions

# On the destination server
php -v
php -m | grep -E 'mbstring|curl|gd|imagick|redis|zip|intl|opcache'

Comparez cette sortie avec votre inventaire de la Phase 1. Toute extension manquante doit être installée avant la migration, pas après.

Vérification de la compatibilité de la base de données

Si vous migrez de MySQL 5.7 vers MySQL 8.0 (un scénario courant), soyez conscient de ces changements incompatibles :

• Le jeu de caractères utf8mb3 est déprécié ; les colonnes peuvent nécessiter des déclarations de jeu de caractères explicites
• Le comportement de GROUP BY a changé — les requêtes qui fonctionnaient en 5.7 peuvent échouer en 8.0 sans ajustement du mode ONLY_FULL_GROUP_BY
• NO_ZERO_DATE est activé par défaut en mode strict, ce qui rejette les champs de date contenant 0000-00-00

Testez votre dump SQL contre la version MySQL de destination avant de basculer le trafic de production.

Traduction de la configuration du serveur web

Si vous migrez d’Apache vers Nginx (un scénario fréquent lors du passage à un VPS optimisé pour les performances), vos règles .htaccess ne se traduisent pas automatiquement. Conversions courantes :

Redirection Apache .htaccess :

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Équivalent Nginx dans le bloc server :

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Manquer cette traduction est l’une des causes les plus fréquentes d’erreurs 404 et de boucles de redirection après migration.

Phase 5 : Exécutez la migration en minimisant les temps d’arrêt

Choisissez la fenêtre de migration de manière stratégique

Analysez vos journaux Google Analytics ou serveur pour identifier votre fenêtre de trafic le plus faible — généralement entre 02h00 et 05h00 dans le fuseau horaire de votre audience principale, un mardi ou mercredi. Évitez les vendredis ; si quelque chose tourne mal, vos options de support se réduisent considérablement pendant le week-end.

Le flux de travail de migration staging-first

1. Pointez un sous-domaine vers le nouveau serveur (ex. : staging.example.com) en utilisant un enregistrement A, sans toucher au DNS de production
2. Transférez tous les fichiers et bases de données vers le nouveau serveur
3. Mettez à jour la chaîne de connexion à la base de données de l’application pour pointer vers la nouvelle base de données
4. Modifiez votre fichier /etc/hosts local pour résoudre le domaine de production vers l’IP du nouveau serveur — cela vous permet de tester la configuration de production complète sans affecter les utilisateurs en direct :

# Add to /etc/hosts on your local machine
203.0.113.50  example.com www.example.com

1. Effectuez un test fonctionnel complet — chaque formulaire, flux de paiement, système de connexion, endpoint API et téléchargement de média
2. Exécutez des benchmarks de performance en utilisant ab (Apache Benchmark) ou wrk :

ab -n 1000 -c 50 https://example.com/

1. Seulement après avoir réussi tous les tests, procédez au basculement DNS

Configuration du certificat SSL

Assurez-vous que votre certificat SSL est installé et validé sur le nouveau serveur avant le basculement DNS. Si vous utilisez Let’s Encrypt :

certbot --nginx -d example.com -d www.example.com

Si vous utilisez un certificat commercial d’un fournisseur comme ceux disponibles via Certificats SSL, installez la chaîne de certificats complète (certificat + CA intermédiaire + CA racine) pour éviter les erreurs de validation de chaîne sur les anciens clients.

Phase 6 : Basculement DNS — L’étape techniquement la plus sensible

La propagation DNS est largement mal comprise. Le chiffre de 48 heures est un plafond dans le pire des cas, pas une durée typique. En pratique, la plupart des résolveurs respectent la valeur TTL de l’enregistrement en cours de modification.

Réduction du TTL avant le basculement

Au moins 24 à 48 heures avant la fenêtre de migration, réduisez le TTL sur vos enregistrements A et CNAME à 300 secondes (5 minutes) :

example.com.    300  IN  A  203.0.113.50
www.example.com. 300 IN  A  203.0.113.50

Cela signifie qu’après avoir mis à jour l’enregistrement vers la nouvelle IP, l’ancienne valeur mise en cache expire dans les 5 minutes pour la plupart des résolveurs — pas 48 heures. C’est la technique la plus efficace pour minimiser la fenêtre de propagation DNS.

Mises à jour des serveurs de noms vs. enregistrements A

Il existe deux approches distinctes de basculement DNS :

• Modifier uniquement les enregistrements A (tout en conservant les mêmes serveurs de noms faisant autorité) : La propagation suit le TTL de l’enregistrement. Approche la plus rapide si votre registraire de domaine permet la gestion directe des enregistrements.
• Modifier les serveurs de noms (pointer vers le DNS du nouvel hébergeur) : Les TTL des serveurs de noms sont généralement de 24 à 48 heures et ne sont pas sous votre contrôle direct. Cette approche prend plus de temps.

Préférez les mises à jour des enregistrements A lorsque c’est possible. Gérez le DNS de votre domaine via votre panneau de contrôle d’Enregistrement de Domaine pour un contrôle direct au niveau des enregistrements.

Maintenir l’ancien serveur actif pendant la propagation

Ne résiliez pas et n’éteignez pas l’ancien plan d’hébergement immédiatement après le basculement DNS. Maintenez-le en fonctionnement pendant au minimum 72 heures. Pendant la propagation, une partie de vos utilisateurs résoudra toujours vers l’ancienne IP — ces requêtes doivent continuer à être servies. Éteindre prématurément l’ancien serveur crée une véritable panne pour ces utilisateurs.

Phase 7 : Surveillance et validation post-migration

Surveillance de la disponibilité et des performances

Configurez une surveillance externe de la disponibilité immédiatement après le basculement DNS — pas après que vous pensez que la propagation est terminée. Outils à déployer :

• UptimeRobot ou Better Uptime — vérifications HTTP(S) toutes les 1 à 5 minutes depuis plusieurs emplacements géographiques
• Google Search Console — surveillez les rapports de Couverture et Core Web Vitals pour détecter des anomalies dans les 7 jours suivant la migration
• New Relic ou Datadog — surveillance des performances au niveau applicatif si votre application le justifie

Identification et résolution des erreurs post-migration

Effectuez immédiatement un crawl du nouveau site en utilisant Screaming Frog ou un miroir wget :

wget --spider --recursive --no-verbose --output-file=crawl_log.txt https://example.com
grep -i "broken|404|error" crawl_log.txt

Problèmes courants post-migration et leurs causes :

Correction des URLs codées en dur dans les bases de données WordPress

Un problème fréquent et subtil : WordPress stocke l’URL du site dans la base de données, et de nombreux thèmes et plugins stockent des URLs absolues dans des données sérialisées. Après la migration vers un nouveau domaine ou protocole, exécutez :

wp search-replace 'http://old-domain.com' 'https://new-domain.com' 
  --all-tables 
  --precise 
  --report-changed-only

L’option --precise gère correctement les données sérialisées PHP, que le remplacement de chaîne naïf brise.

Phase 8 : Résiliez l’ancien plan d’hébergement

Résiliez l’ancien plan uniquement après que toutes les conditions suivantes sont confirmées :

• La propagation DNS est complète (vérifiez avec dig +trace example.com depuis plusieurs emplacements)
• La surveillance de disponibilité affiche 100% de disponibilité pendant au moins 72 heures consécutives
• Aucune erreur 404 ou lien cassé détecté dans les journaux de crawl
• La livraison des emails fonctionne correctement sur le nouveau serveur
• Les analyses montrent des modèles de trafic normaux sans baisses anormales
• Vous disposez d’une copie locale de tous les fichiers de sauvegarde indépendamment de l’un ou l’autre hébergeur

Liste de contrôle des points techniques clés

Utilisez ceci comme liste de contrôle d’exécution de migration :

Pré-migration

• [ ] Exporté la référence d’utilisation des ressources sur 90 jours (CPU, RAM, I/O, bande passante)
• [ ] Documenté la pile logicielle complète avec les numéros de version exacts
• [ ] Réduit le TTL DNS à 300 secondes au moins 24 heures avant le basculement
• [ ] Créé et testé la sauvegarde complète (fichiers + bases de données + tâches cron + email)
• [ ] Validé la version PHP et toutes les extensions requises sur le serveur de destination
• [ ] Traduit les règles .htaccess au format Nginx si changement de serveur web
• [ ] Installé et validé le certificat SSL sur le nouveau serveur avant le changement DNS

Pendant la migration

• [ ] Fichiers transférés en utilisant rsync avec vérification de somme de contrôle (rsync -avz --checksum)
• [ ] Base de données importée et nombre de lignes vérifié correspondant à la source
• [ ] Fonctionnalité complète du site testée via le remplacement /etc/hosts avant le changement DNS
• [ ] Fichiers de configuration de l’application mis à jour (hôte de base de données, identifiants, URL du site)

Post-migration

• [ ] Surveillance externe de la disponibilité active dans les 5 minutes suivant le basculement DNS
• [ ] Ancien serveur maintenu en fonctionnement pendant au minimum 72 heures après le basculement
• [ ] Crawl complet du site effectué ; toutes les erreurs 404 et liens cassés résolus
• [ ] URLs codées en dur corrigées dans la base de données (notamment pour WordPress)
• [ ] Google Search Console surveillée pendant 7 jours après la migration
• [ ] Ancien plan d’hébergement résilié uniquement après confirmation de tous les éléments ci-dessus

Foire aux questions

Combien de temps dure réellement la propagation DNS, et puis-je l’accélérer ?

La durée de propagation DNS est déterminée par la valeur TTL de l’enregistrement en cours de modification, pas par une fenêtre fixe de 48 heures. Si vous réduisez le TTL de votre enregistrement A à 300 secondes au moins 24 heures avant la migration, la plupart des résolveurs récupéreront la nouvelle IP dans les 5 à 10 minutes suivant le changement. Le chiffre de 48 heures s’applique aux changements de délégation de serveurs de noms, dont les TTL sont hors de votre contrôle.

La migration vers un nouvel hébergeur va-t-elle nuire à mon classement dans les recherches Google ?

Une migration correctement exécutée sans temps d’arrêt, avec une structure d’URL préservée et un SSL valide n’a aucun impact SEO négatif. Les classements peuvent baisser temporairement si le nouveau serveur est plus lent, si les URLs changent sans redirections 301 appropriées, ou si le site est inaccessible pendant l’exploration. Surveillez les rapports de Couverture et Core Web Vitals de Google Search Console pendant 14 jours après la migration.

Quelle est la méthode la plus sûre pour transférer de grandes bases de données sans corrompre les données ?

Utilisez mysqldump avec l’option --single-transaction pour les tables InnoDB afin d’assurer un instantané cohérent sans verrous de table. Transférez le fichier dump via SSH en utilisant scp ou rsync plutôt que phpMyAdmin, qui a des limites de taille de fichier et des contraintes de délai d’expiration qui causent une troncature silencieuse sur les grandes bases de données.

Dois-je réinstaller mon certificat SSL après la migration ?

Oui. Les certificats SSL sont liés à la clé privée du serveur, qui réside sur le serveur d’origine. Vous devez soit réémettre le certificat sur le nouveau serveur (gratuit pour Let’s Encrypt), soit exporter la clé privée et la chaîne de certificats depuis l’ancien serveur et les installer sur le nouveau. Assurez-vous que le certificat est entièrement validé avant de mettre à jour le DNS, afin que HTTPS fonctionne immédiatement après le basculement.

Comment puis-je vérifier que ma migration est complète avant de résilier l’ancien plan ?

Exécutez dig +trace example.com @8.8.8.8 et dig +trace example.com @1.1.1.1 pour confirmer que les résolveurs Google et Cloudflare retournent l’IP du nouveau serveur. Vérifiez la surveillance de disponibilité pendant 72 heures consécutives de réponses propres. Crawlez le site pour détecter les erreurs 404 et vérifiez la livraison des emails. Ce n’est qu’après que tous ces points sont validés qu’il est sûr de résilier l’ancien compte d’hébergement.