Comment préparer votre site web aux pics de trafic

Publié le

14 juil. 2026

Temps de lecture

9 min de lecture

Préparez-vous aux pics de trafic en réduisant le travail inutile de l'origine, en prouvant que chaque couche peut monter en charge et en définissant un plan de réponse avant le début de l'événement. Un CDN aide à absorber la demande pouvant être mise en cache, mais ne rend pas illimités le paiement, la recherche, la connexion, les API, les bases de données, les appels tiers ou une origine non protégée. Être prêt signifie connaître le débit sûr de chaque dépendance et disposer d'un moyen testé de se dégrader avec élégance.

La bonne séquence est la suivante : modéliser l'événement, établir une référence du système actuel, maximiser le cache sans risque, tester une charge réaliste, protéger les ressources rares et surveiller l'événement en direct avec des critères de retour arrière clairs. Commencez des semaines à l'avance pour une vente ou un lancement majeur, pas lorsque le trafic augmente déjà.

Définir le pic que vous devez supporter

Consignez plus qu'une estimation de requêtes par seconde. Incluez l'heure de début attendue, la durée, la distribution géographique, le mix d'appareils, la proportion cachable ou dynamique, les objets les plus volumineux, les appels API par page, la part authentifiée et le comportement probable de nouvelle tentative. Modélisez un pic normal, un pic optimiste et un cas de défaillance où une dépendance est lente ou indisponible.

Traduisez ces scénarios en objectifs de service. Exemples : un taux de succès cible pour les pages produit, un temps de réponse p95 maximal pour la recherche, un budget d'erreur pour le paiement, un nombre maximal de connexions à l'origine et le temps autorisé pour activer un mode dégradé. Définissez les fonctions essentielles et celles qui peuvent être retardées, désactivées ou remplacées par une réponse statique.

Examinez la capacité à chaque étape :

• DNS, négociations TLS et limites de requêtes edge.
• Remplissage du cache CDN, bande passante, débit de requêtes et comportement de purge.
• Répartiteurs de charge, workers web, pools de connexions et files d'attente.
• Serveurs applicatifs, bases de données, caches, stockage et courtiers de messages.
• API externes de paiement, identité, recherche, analytique, livraison et autres.

Réduire le travail avant d'ajouter de la capacité

Rendez les ressources statiques fingerprintées et cachables longtemps. Utilisez des directives Cache-Control explicites et séparez si nécessaire la fraîcheur navigateur de celle du cache partagé. Gardez le cache HTML prudent à moins de pouvoir prouver que la personnalisation, les cookies, l'autorisation et l'invalidation sont sûrs. Ne mettez jamais en cache une réponse contenant des données utilisateur privées sous prétexte qu'elle est rapide.

Examinez les clés de cache. Supprimez les paramètres de suivi qui ne modifient pas la représentation, mais préservez ceux qui la modifient. Normalisez les différences d'URL inoffensives et évitez de varier sur des en-têtes à forte cardinalité sans raison métier. Utilisez le cache hiérarchisé ou la protection d'origine pour consolider les remplissages de cache, et le regroupement de requêtes lorsque votre fournisseur le propose.

Les équivalents Cloudflare incluent les Cache Rules, Tiered Cache, les contrôles de clé de cache et stale-while-revalidate ou stale-if-error lorsque leur sémantique convient au contenu. Les équivalents Fastly incluent Surrogate-Control explicite, la purge par clé ou clé surrogate et le shielding. Ces réglages ne sont pas interchangeables : vérifiez les en-têtes de réponse et le comportement du fournisseur dans un environnement de préproduction ou un chemin de production contrôlé.

Pour le trafic dynamique, réduisez le travail coûteux plutôt que d'essayer de le mettre aveuglément en cache. Mettez en cache brièvement les réponses API en lecture seule lorsque leur politique de données le permet. Regroupez les appels, réutilisez les connexions, pré-calculer les pages populaires, mettez les écritures non critiques en file et imposez des limites strictes aux opérations coûteuses de recherche ou de recommandation. Ajoutez une contre-pression pour qu'une surcharge devienne une réponse 429 contrôlée ou dégradée conviviale plutôt qu'une défaillance en cascade.

Configurer l'edge et l'origine

1. Confirmez que l'accès à l'origine est contrôlé. L'origine doit accepter le trafic de l'edge prévu et des systèmes internes, pas de tout client public. Faites tourner les adresses exposées si l'origine était précédemment publique et validez les comportements TLS et d'en-tête d'hôte.
2. Définissez des délais et nouvelles tentatives prudents. Une nouvelle tentative multiplie la charge lorsqu'une dépendance échoue déjà. Réessayez uniquement les opérations idempotentes, limitez les tentatives et appliquez un backoff avec gigue. Ne réessayez pas le paiement ou la création de commande sans conception d'idempotence.
3. Utilisez des contrôles de santé qui reflètent la santé du service. Un endpoint /health superficiel peut être utile pour savoir si le processus est vivant, mais ne doit pas déterminer si un pool de paiement reçoit du trafic. Ajoutez des contrôles de disponibilité pour les dépendances critiques, sans faire de la sonde de santé elle-même une ruée vers la base de données.
4. Définissez un mode dégradé. Décidez à l'avance si vous désactivez la personnalisation, les recommandations, les images non essentielles, les avis ou l'analytique. Gardez la découverte de produits et le paiement sur le chemin prioritaire. Documentez les feature flags et la personne autorisée à les activer.
5. Préchauffez délibérément. Ne chauffez que des objets connus, publics et cachables via un crawler approuvé ou un mécanisme fournisseur. Ne créez pas une tempête de requêtes, ne chauffez pas de contenu personnalisé et ne supposez pas que le cache est chaud sur chaque CDN et dans chaque région.
6. Gelez les changements risqués. Établissez une fenêtre de changement, un responsable du retour arrière et un instantané final de la configuration. Gardez les changements d'urgence petits et réversibles. Un événement de pointe est un mauvais moment pour modifier simultanément les clés de cache, la sensibilité WAF, le schéma applicatif et l'architecture DNS.

Tester avant l'événement

Utilisez des données et formes de trafic proches de la production, pas seulement un flot uniforme de GET. Testez la navigation anonyme, les manques de cache, les sessions connectées, la recherche, le panier, le paiement, l'authentification API, les ressources volumineuses et les chemins d'erreur. Exécutez le générateur de charge depuis des régions représentatives et respectez les règles de test des fournisseurs et tiers. Coordonnez-vous avec les fournisseurs avant un test à haut volume.

Testez la capacité par étapes : référence, pic attendu, pic prévu et défaillance contrôlée d'une dépendance. Surveillez la saturation et la récupération, pas seulement le débit maximal atteint. Vérifiez que les files se vident, les caches se remplissent, les bases récupèrent et l'autoscaling n'oscille pas. Testez la purge de cache et le déploiement sous charge, car les deux peuvent provoquer un remplissage simultané de l'origine.

Pendant l'événement, visualisez le trafic et les journaux par route, région, statut, statut de cache, fournisseur et parcours client. Alertez sur le taux de succès, la latence p95 et p99, le CPU de l'origine, les connexions base de données, la profondeur de file, les manques de cache, les nouvelles tentatives et le taux d'erreur des tiers. Les contrôles synthétiques doivent exécuter une page publique et un chemin de transaction sûr depuis l'extérieur de votre réseau. Gardez un canal d'incident ouvert et consignez les décisions.

Échecs de préparation courants

• Ne tester que le CDN et jamais une origine à cache froid.
• Considérer l'autoscaling comme instantané ou illimité.
• Ignorer les remplissages de cache dus aux purges et déploiements.
• Utiliser une limite de débit globale pour les pages, la connexion, la recherche et le paiement.
• Permettre aux clients ou proxies de réessayer des écritures non sûres.
• Oublier que le trafic de bots peut consommer la même capacité d'origine que les clients.
• Avoir des tableaux de bord mais aucun seuil, responsable, chemin d'escalade ou plan de retour arrière.

Le guide CDN managé explique la couche edge, tandis que Multi-CDN couvre le basculement entre fournisseurs. Pour la sémantique du cache, consultez les conseils Cloudflare sur Cache-Control et la documentation Fastly sur le shielding. Si vous avez besoin d'une revue d'architecture avant un événement de pointe, contactez Optimi.

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