Multi-CDN : quand un seul CDN ne suffit plus

Utilisez une architecture Multi-CDN lorsque la disponibilité, les performances géographiques, l'exposition réglementaire ou le volume de trafic de votre site rendent la dépendance à un seul fournisseur de diffusion inacceptable. N'ajoutez pas un second CDN uniquement pour disposer d'un tableau de bord supplémentaire. Le Multi-CDN est utile lorsque vous pouvez définir une décision de routage, maintenir un comportement cohérent entre les fournisseurs, protéger l'origine et prouver que le basculement fonctionne.

L'architecture comporte généralement quatre couches : un DNS faisant autorité ou un répartiteur de trafic edge, deux fournisseurs CDN ou plus, une origine et une politique de sécurité partagées, ainsi qu'une couche d'observabilité qui compare les fournisseurs. Le répartiteur choisit un fournisseur sain pour chaque région ou classe de requêtes. Les CDN mettent le contenu en cache et le protègent. L'origine reste la source de vérité, et non le mécanisme de basculement.

Quand le Multi-CDN a du sens

Commencez par la défaillance que vous cherchez à réduire.

• Panne d'un fournisseur : un site critique ne peut pas accepter qu'un seul fournisseur soit son unique chemin de diffusion.
• Variations de performances régionales : un réseau dispose d'un peering solide sur un marché tandis qu'un autre est plus performant ailleurs.
• Concentration du trafic ou des produits : un lancement, une promotion, un événement médiatique ou une charge d'API nécessite une capacité indépendante et une solution de repli testée.
• Contraintes contractuelles ou de souveraineté : différentes régions ou propriétés requièrent différents fournisseurs, points de présence ou contrôles opérationnels.
• Risque lié à la négociation ou à la migration : vous devez pouvoir changer de fournisseur sans une bascule globale risquée.

Conservez un seul CDN si le trafic est modeste, si le fournisseur répond déjà à vos objectifs de disponibilité et de latence, et si votre équipe ne peut pas exploiter le plan de contrôle supplémentaire. Le Multi-CDN ajoute de la complexité pour le DNS, la configuration, les purges, les certificats, les journaux, la facturation et la réponse aux incidents. Un CDN managé peut constituer une meilleure première étape.

Choisir le modèle de routage

Il n'existe pas de politique d'orientation universellement optimale. Sélectionnez celle qui correspond à l'objectif métier et à la qualité des signaux disponibles.

Le basculement prioritaire envoie le trafic vers un pool principal, puis le déplace vers un pool secondaire lorsque les vérifications d'état échouent. C'est le modèle le plus simple et le plus facile à expliquer pendant un incident. Il peut laisser inexploités des gains de performance tant que le pool principal est techniquement sain.

L'orientation géographique affecte des régions ou des pays à des fournisseurs. Elle fonctionne bien lorsque les fournisseurs ont des atouts locaux connus ou lorsque le traitement des données diffère selon les marchés. Prévoyez une solution de repli ordonnée pour chaque région, y compris le chemin par défaut.

L'orientation par la performance compare les mesures de latence ou les signaux d'erreur et sélectionne le meilleur fournisseur sain. Elle peut améliorer l'expérience utilisateur, mais elle exige suffisamment de sondes, une fenêtre de mesure stable et un mécanisme d'amortissement. Sinon, le trafic peut osciller entre les fournisseurs à cause du bruit normal du réseau.

L'orientation pondérée est utile pour un canari, une migration ou une répartition de capacité. Commencez avec un faible pourcentage, comparez le taux d'erreur et la charge sur l'origine, puis augmentez progressivement. Un poids n'est pas une politique d'état : un fournisseur fortement pondéré a toujours besoin d'une vérification d'état indépendante.

Les équivalents Cloudflare comprennent les pools Load Balancing, les moniteurs d'état et les politiques de basculement, d'orientation géographique ou dynamique. L'orientation dynamique de Cloudflare utilise les mesures des moniteurs pour comparer le temps aller-retour des pools. Les équivalents Fastly comprennent les backends sains, les vérifications d'état, les directeurs, les pondérations, les tentatives et le shielding. Les noms des produits diffèrent, mais le principe opérationnel est le même : n'orienter le trafic que parmi les destinations saines et définir ce qui se passe lorsque l'ensemble préféré est vide.

Construire l'architecture de manière fiable

1. Inventoriez les classes de requêtes. Séparez les ressources immuables, le HTML, les pages authentifiées, les API, les téléversements, le streaming, les webhooks et l'administration. Ils ne partagent pas la même politique de cache ou de basculement. Ne routez jamais une écriture avec état vers un fournisseur choisi uniquement pour la vitesse de ses ressources statiques.

2. Standardisez le contrat edge. Utilisez les mêmes noms d'hôte, la même couverture TLS, les mêmes protocoles pris en charge, règles de compression, redirections, clés de cache, en-têtes d'origine, politiques WAF, limites de débit et réponses d'erreur. Consignez les différences propres aux fournisseurs au lieu de supposer une parité de configuration.

3. Créez des vérifications d'état tenant compte de l'application. Sondez un endpoint léger qui vérifie le nom d'hôte attendu, TLS, le statut attendu et un corps de réponse sûr. Une connexion TCP vers un équilibreur de charge actif ne prouve pas que le paiement, la recherche ou l'API sont utilisables. Utilisez des vérifications distinctes pour les chemins critiques distincts lorsqu'un endpoint ne peut pas représenter l'ensemble de l'application.

4. Protégez l'origine. Autorisez le trafic provenant des fournisseurs de diffusion, utilisez des connexions authentifiées à l'origine lorsqu'elles sont disponibles, et ne publiez pas le nom d'hôte ni les adresses de l'origine lorsque c'est possible. Sinon, un attaquant peut contourner les deux CDN et transformer une conception de basculement en panne d'origine.

5. Rendez le cache et les purges portables. Utilisez des noms de fichier versionnés pour les objets à longue durée de vie. Définissez une procédure de purge indépendante du fournisseur pour le HTML et les objets mutables. Vérifiez qu'une publication ou un retour en arrière met à jour chaque fournisseur, et pas uniquement celui qui est actif. Si les fournisseurs utilisent des clés de cache différentes, réconciliez explicitement les paramètres de requête, les en-têtes, les cookies et la négociation de contenu.

6. Gardez des hypothèses DNS réalistes. L'orientation DNS est soumise à la mise en cache des résolveurs et des clients. Un TTL faible ne garantit pas que chaque utilisateur change immédiatement de fournisseur. Fixez un objectif de rétablissement opérationnel qui tient compte de ce délai, et utilisez une orientation au niveau de la connexion ou de l'application lorsque la charge exige un contrôle plus rapide.

Le tester et l'observer

Établissez une référence pour chaque fournisseur indépendamment avant d'envoyer du trafic de production. Mesurez la disponibilité, le temps jusqu'au premier octet, les Core Web Vitals, les erreurs TLS, l'état du cache, les requêtes à l'origine, les taux de 4xx et 5xx, ainsi que le coût par région et classe de requêtes. Comparez des éléments comparables : même état du cache, même version d'objet, mêmes en-têtes et même zone géographique de test.

Testez régulièrement les scénarios suivants :

• Un fournisseur renvoie des erreurs dans une région tout en restant sain ailleurs.
• Les vérifications d'état échouent, récupèrent, puis échouent à nouveau pendant un déploiement amorti.
• Les réponses DNS restent en cache au-delà du TTL prévu.
• Une purge est lancée pendant un déploiement et chaque fournisseur sert la version attendue.
• Le CDN principal est indisponible alors que l'origine est saine, puis l'origine se dégrade aussi.
• Une règle WAF, anti-bot ou de limitation de débit se comporte de manière cohérente après le basculement.

Déclenchez des alertes sur les symptômes visibles par les utilisateurs, et non uniquement sur les pages de statut des fournisseurs : taux de réussite régional, latence p95, taux de cache hit, saturation de l'origine, distribution des réponses DNS et part de trafic par fournisseur. Conservez des identifiants de requête et un indicateur de fournisseur dans les journaux afin de suivre la même transaction à travers l'edge et l'origine. Un service Multi-CDN managé n'a de valeur que si ce travail de comparaison et de réponse est pris en charge opérationnellement.

Erreurs à éviter

• Considérer deux CDN aux clés de cache différentes comme des copies redondantes d'un même système.
• Utiliser une vérification d'état qui renvoie toujours HTTP 200, même lorsque l'application est défaillante.
• Définir des pondérations agressives sans montée en charge, retour en arrière ni test de capacité.
• Oublier les certificats, redirections, CORS, en-têtes de sécurité ou le comportement de purge sur le fournisseur de secours.
• Supposer que le TTL DNS équivaut au délai de basculement.
• Autoriser l'origine à accepter l'Internet public après l'ajout d'une couche edge.
• Mesurer uniquement la latence moyenne et manquer des erreurs régionales ou une hausse du taux de requêtes à l'origine.

Pour les normes qui encadrent la mise en cache et la revalidation, consultez la norme IETF HTTP Caching. Pour les détails d'implémentation des fournisseurs, comparez l'orientation du trafic Cloudflare et l'équilibrage de charge Fastly. Pour évaluer si votre site a besoin de ce niveau d'orchestration, consultez la page contact d'Optimi.

Il n'existe que deux problèmes difficiles en informatique : l'invalidation du cache et le choix des noms.