Guide de migration CDN : changer de fournisseur sans interruption

La migration CDN la plus sûre conserve les URL publiques inchangées et traite le nouveau fournisseur comme un chemin de production parallèle. Créez et testez la nouvelle configuration, réduisez le TTL DNS en amont, basculez le trafic par étapes contrôlées, surveillez les deux fournisseurs et l'origine, et conservez un retour arrière testé. Google décrit cela comme un changement d'hébergement sans changement d'URL : préparez la nouvelle infrastructure, mettez à jour le DNS, surveillez le trafic et n'arrêtez l'ancien fournisseur qu'après avoir vérifié que les utilisateurs et Googlebot reçoivent correctement le contenu.

Avant la migration : définir le périmètre d'impact

Créez un inventaire de chaque nom d'hôte et classe de trafic. Incluez le HTML, les API, les images, les téléchargements, la vidéo, les WebSockets, le streaming, l'authentification, les webhooks, robots.txt, les sitemaps XML, les redirections et les endpoints de santé. Consignez les enregistrements DNS et TTL actuels, les certificats TLS, les adresses d'origine, les listes d'autorisation du pare-feu, les en-têtes d'hôte, la compression, les versions HTTP, les règles de cache, les cookies, la gestion des paramètres de requête, les requêtes de plage, les règles WAF, les politiques de bots, les processus de purge et les exports de journaux.

Établissez une référence depuis l'edge public et l'origine :

• Statut et chaîne de redirection pour des URL représentatives.
• En-têtes de réponse, type de contenu, sommes de contrôle du corps et statut de cache.
• Temps DNS, TLS, de connexion, jusqu'au premier octet et de réponse totale.
• RUM par type de page, région, appareil et version.
• Contrôles synthétiques pour les parcours et modes de défaillance importants.
• Charge d'origine, taux d'erreur, bande passante et distribution des requêtes.

L'objectif n'est pas de faire paraître le nouveau fournisseur performant de façon isolée. Il consiste à prouver que les anciens et nouveaux chemins se comportent de la même manière là où ils le doivent, et à distinguer les améliorations intentionnelles du risque de migration. La présentation du CDN managé couvre les enjeux de diffusion à rendre explicites.

Préparer le nouveau fournisseur

1. Reproduire les règles de contenu et de routage

Importez le modèle des noms d'hôte et chemins, puis examinez chaque règle au lieu de supposer qu'un export est complet. Vérifiez la sélection de l'origine, l'en-tête d'hôte, SNI, la gestion des méthodes HTTP, la normalisation des chaînes de requête, le passage des cookies, l'authentification, CORS, la compression et la négociation de contenu. Confirmez que les réponses dynamiques ne sont pas mises en cache et que les ressources statiques appliquent la politique de cache prévue.

Maintenez l'origine accessible aux deux fournisseurs pendant la migration. Mettez à jour les listes d'autorisation du pare-feu et les contrôles de santé avant de déplacer le trafic. Si l'origine reçoit un en-tête propre à un fournisseur ou un format d'IP client particulier, testez les règles applicatives et de sécurité avec les deux formes.

2. Configurer TLS et DNS sans risque

Émettez et validez les certificats pour chaque nom d'hôte de production, y compris les noms d'hôte alternatifs et tout domaine d'API ou de ressources. Testez la chaîne de certificats, la prise en charge des protocoles, les redirections HTTP vers HTTPS et la vérification du certificat d'origine. Un certificat qui fonctionne sur un nom d'hôte temporaire ne prouve pas que le SNI de production et le mappage d'hôte sont corrects.

Réduisez le TTL DNS concerné à une valeur prudente, idéalement bien avant le changement. Google recommande de le ramener à quelques heures au moins une semaine avant un déplacement d'hébergement afin que les caches des résolveurs se rafraîchissent plus vite. Le TTL influe sur la rapidité de propagation des nouvelles réponses, mais ne force pas immédiatement chaque résolveur ou connexion existante à changer. Maintenez l'ancien fournisseur en service pendant cette fenêtre.

3. Tester via un nom d'hôte contrôlé

Utilisez un nom d'hôte temporaire ou un mécanisme de routage interne pour envoyer les requêtes de test via le nouvel edge. Si le nom d'hôte est publiquement accessible, évitez une indexation accidentelle avec un contrôle noindex approprié et ne l'incluez ni dans les liens publics ni dans les sitemaps. Testez de vraies URL et des chaînes de requête représentatives, pas seulement un espace réservé statique.

Comparez les anciennes et nouvelles réponses depuis plusieurs emplacements, avec des états de cache froid et chaud. Vérifiez la langue HTML et les balises canoniques, les en-têtes de sécurité, les cookies, les redirections, les réponses de plage, les pages d'erreur, l'âge du cache et le comportement de purge. Testez une défaillance contrôlée : rendez l'origine lente ou indisponible dans un environnement hors production et confirmez que le nouveau chemin expire, bascule ou sert une réponse périmée délibérément configurée sans exposer de contenu sensible.

Basculer par étapes

1. Gelez les changements sans rapport. Évitez d'associer une migration CDN à une refonte, un changement de domaine, une version applicative ou une réécriture importante de la politique de cache.
2. Ouvrez la fenêtre de changement. Confirmez les responsables, contacts fournisseurs, tableaux de bord, URL de test, commandes de retour arrière et conditions d'arrêt.
3. Lancez un canari. Utilisez une capacité permettant une répartition contrôlée, un nom d'hôte à faible risque ou une région limitée. La pondération DNS seule peut être imprécise car les résolveurs récursifs mettent les réponses en cache ; mesurez donc le trafic réel plutôt que de supposer le pourcentage exact.
4. Comparez les signaux en direct. Surveillez le statut par chemin, le TTFB, la charge d'origine, le taux de succès du cache, la bande passante, les erreurs TLS, les actions WAF, le RUM et les parcours synthétiques. Comparez le nouveau chemin à la référence, segmenté par géographie et appareil.
5. Augmentez progressivement. Ne déplacez le trafic par étapes que lorsque l'étape précédente est stable pendant une fenêtre d'observation significative. Incluez une charge de pointe ou représentative avant de déclarer le succès.
6. Gardez l'ancien fournisseur actif. N'annulez pas le compte, ne retirez pas l'accès au pare-feu et ne supprimez pas la configuration tant que des caches DNS et connexions client longue durée existent encore.

Pour une résilience au-delà d'une bascule vers un seul fournisseur, consultez Multi CDN. Une conception multi-fournisseurs requiert toujours des règles cohérentes de cache, de purge, de sécurité et d'observabilité ; ajouter un second fournisseur ne supprime pas la complexité opérationnelle.

Retour arrière et validation après migration

Si le nouveau chemin échoue, restaurez l'ancienne réponse DNS ou pondération de routage, puis confirmez depuis plusieurs résolveurs et régions que le trafic revient. N'oubliez pas qu'un retour arrière DNS n'est pas instantané. Surveillez les deux fournisseurs jusqu'à ce que l'ancien trafic augmente et que le nouveau diminue. Ne purgez que lorsque vous savez quel fournisseur détient l'objet incorrect ; une purge indiscriminée peut provoquer une surcharge de l'origine pendant un incident.

Après la bascule, conservez un tableau de bord de migration pendant au moins un cycle de trafic normal et une période de pointe. Vérifiez les signaux d'exploration et d'indexation de Search Console, les journaux serveur pour Googlebot, les distributions de statut, les taux de redirection, les erreurs de cache et la capacité d'origine. Google indique qu'une baisse temporaire du taux d'exploration de Googlebot peut survenir après un changement d'hébergement, suivie d'une récupération progressive si la nouvelle infrastructure reste disponible et réactive.

Lorsque les preuves sont stables, retirez les contrôles de test temporaires, mettez à jour la documentation et les runbooks, vérifiez la responsabilité du renouvellement DNS et des certificats, puis seulement retirez l'ancien fournisseur. Si la migration modifie aussi les URL, arrêtez-vous et suivez un plan distinct de déplacement de site : un changement de fournisseur seul ne doit pas introduire de redirections ou de modifications canoniques.

Erreurs courantes

• Traiter la propagation DNS comme un basculement de trafic précis et instantané.
• Ne migrer que la page d'accueil alors que les API, ressources, téléchargements ou WebSockets utilisent encore les anciennes règles.
• Oublier les listes d'autorisation du pare-feu de l'origine ou modifier l'hôte transmis et la sémantique de l'IP client.
• Copier des règles de cache sans examiner les cookies, chaînes de requête, autorisations et la négociation de contenu.
• Tester le nouveau fournisseur uniquement avec un cache froid ou depuis une seule région.
• Permettre qu'un nom d'hôte de test temporaire soit indexé ou lié publiquement.
• Associer la migration à un changement d'URL puis déboguer simultanément les symptômes SEO et d'infrastructure.
• Arrêter l'ancien chemin avant que les caches DNS, journaux et connexions longue durée ne se soient stabilisés.

Utilisez le guide RUM ou surveillance synthétique pour concevoir le tableau de bord de comparaison, et le guide des budgets de performance web pour définir les conditions d'arrêt de performance. Pour une revue de migration couvrant l'edge, le SEO et le retour arrière, contactez Optimi.

Il n'y a que deux choses difficiles en informatique : l'invalidation du cache et le choix des noms.