At 10 a.m. Eastern on November 28, 2025, online spending in the United States climbed toward $12.5 million every minute and held near that pace for hours. Behind every one of those transactions sat a web server, a database connection and an autoscaling policy that either kept up or did not. For the team running that infrastructure, discount codes mattered less than whether the fleet could add capacity before checkout pages timed out. That decision gets made weeks earlier, in configuration files most shoppers never see.
Règles de dimensionnement automatique sous pression avant la ruée des fêtes
Amazon Web Services recommande le suivi de cible comme politique initiale pour la plupart des charges de travail. Une équipe choisit une métrique, souvent l'utilisation du processeur, et définit une valeur cible. Une politique de dimensionnement par suivi de cible peut viser une utilisation moyenne du processeur de 50 pour cent. À partir de là, le fournisseur cloud ajoute ou supprime des instances de lui-même pour maintenir cette ligne.
La politique a une particularité qui prend les nouvelles équipes au dépourvu. Une politique de dimensionnement par suivi de cible suppose qu'elle doit monter en charge lorsque la métrique spécifiée dépasse la valeur cible, mais elle ne peut pas monter en charge lorsque la métrique se situe en dessous de cette cible. Cela signifie qu'une montée lente et régulière du trafic est bien gérée. Une chute soudaine d'une métrique différente, que la politique n'a jamais été réglée pour surveiller, ne déclenchera aucune réponse.
C'est pourquoi la documentation AWS traite le suivi de cible comme une base plutôt que comme une réponse complète. Dans la plupart des cas, une politique de dimensionnement par suivi de cible suffit à augmenter et réduire automatiquement un groupe Auto Scaling. Mais l'expression clé est « dans la plupart des cas », pas dans tous.
Warm pools, dimensionnement par paliers et socle de capacité
Le dimensionnement réactif a un problème de décalage intégré lors d'un pic soudain. Un pic arrivant plus vite que le cycle d'évaluation des métriques dépassera la cible avant que le suivi de cible ne réagisse. Au moment où la politique le remarque, les dommages sur les temps de chargement des pages ont déjà commencé.
Deux outils permettent de combler cet écart. Le premier est le dimensionnement par paliers (step scaling), qui réagit par des bonds plus importants une fois qu'un seuil est franchi, utile pour un trafic viral ou lié à des ventes flash plutôt que pour le rythme quotidien lent que le suivi de cible gère bien. Le second est le « warm pool ». Les warm pools conservent des instances EC2 pré-initialisées dans des états arrêtés ou en cours d'exécution, prêtes à rejoindre un groupe Auto Scaling immédiatement lors d'événements de montée en charge. Les équipes devraient utiliser les warm pools lorsqu'une application a de longues séquences de démarrage, lorsque la latence de montée en charge affecte directement l'expérience utilisateur, ou lorsque des objectifs de disponibilité stricts s'appliquent durant les pics de trafic.
Un paramètre mérite un second regard avant le début de la saison. Les délais d'expiration des hooks de cycle de vie sont fixés par défaut à 3 600 secondes, et si l'automatisation liée à ce hook échoue silencieusement, les instances restent bloquées dans un état d'attente jusqu'à l'expiration du délai, ce qui peut bloquer la montée en charge durant la poussée même qu'une équipe essaie de survivre. Vérifier ce paramètre par défaut par rapport à vos propres scripts de déploiement prend quelques minutes. Le découvrir lors d'un pic de trafic n'en prend pas.
Le dimensionnement planifié et prédictif couvre l'écart que les politiques réactives ne peuvent pas gérer. Le dimensionnement planifié convient au lancement connu d'une campagne, tandis que le dimensionnement prédictif aide lorsque le trafic suit des modèles récurrents étayés par suffisamment de données historiques. Aucun des deux ne remplace le suivi de cible. Ils fonctionnent tous deux en complément comme un socle préventif, de sorte que le parc est déjà plus important avant que le premier acheteur n'atterrisse sur la page d'accueil.
Les décisions de coûts suivent la même logique. Un groupe d'instances mixtes peut combiner des capacités à la demande (On-Demand) et ponctuelles (Spot) et puiser dans plusieurs types d'instances, ce qui répartit les risques si un type d'instance vient à manquer. Les plans d'économies (Savings Plans) réduisent les tarifs de calcul éligibles mais ne fournissent pas de réservation de capacité EC2, donc une remise engagée n'est pas la même chose qu'une garantie que la capacité existera lorsque vous en aurez besoin.
Qui ressent la pression quand la capacité fait défaut
Les grands détaillants disposant d'équipes dédiées aux plateformes ont tendance à résoudre ce problème des mois à l'avance. La pression retombe plus durement sur les petites et moyennes boutiques en ligne fonctionnant sur un hébergement mutualisé, un serveur web unique ou un compte cloud faiblement géré. Ce sont les sites gérés par une ou deux personnes jonglant simultanément avec le marketing, les stocks et l'infrastructure.
Le choix de la plateforme détermine dans quelle mesure ce fardeau incombe directement au marchand. Shopify a rapporté que ses marchands ont généré $6.2 milliards de dollars de ventes en ligne mondiales lors du Black Friday 2025, un trafic que l'infrastructure de la plateforme elle-même a absorbé plutôt que chaque propriétaire de boutique individuel. Une boutique WooCommerce ou Magento auto-hébergée encaisse ce même pic de trafic sans ce tampon partagé, ce qui explique pourquoi les règles de dimensionnement automatique sous-jacentes à un site auto-géré importent davantage, et non moins, à mesure que le volume de commandes augmente.
Les agences et les développeurs indépendants gérant plusieurs sites clients sont confrontés à une version aggravée du même problème. Chaque site peut nécessiter son propre seuil, sa propre taille de warm pool et sa propre fenêtre de dimensionnement planifié calée sur le calendrier promotionnel spécifique de ce client.
Ce que révèlent les chiffres du Black Friday 2025
L'ampleur du problème est visible dans les chiffres de la saison dernière. Les consommateurs américains ont dépensé $11.8 milliards de dollars en ligne lors du Black Friday 2025, et les appareils mobiles ont représenté $6.5 milliards de ce total, soit 55.2 pour cent des ventes en ligne, selon Adobe. Une majorité de ce trafic est arrivée sur des téléphones, souvent via des réseaux mobiles instables, ce qui augmente le coût de tout retard dans la réponse des pages.
La composition du trafic évolue d'une manière qui complique les prévisions. Adobe a rapporté que le trafic IA vers les sites de vente au détail américains était en hausse de 805 pour cent par rapport au Black Friday précédent. Il s'agit d'une source de charge nouvelle et à croissance rapide que les modèles de trafic historiques des saisons passées ne capturent pas entièrement, ce qui affaiblit l'argument en faveur d'un recours au seul dimensionnement prédictif sans filet de sécurité réactif.
Les chiffres au niveau de la plateforme racontent une histoire similaire sur l'échelle. Les marchands Shopify ont vendu pour $14.6 milliards de dollars durant le Black Friday et le Cyber Monday 2025, une augmentation de 27 pour cent, desservant plus de 81 millions de clients. Ce taux de croissance dépasse la planification de capacité d'une année sur l'autre de la plupart des équipes, ce qui signifie que le nombre d'instances au pic de l'année dernière est rarement la base de référence sûre de cette année.
Quelles sont les prochaines étapes pour le dimensionnement automatique durant les fêtes
Les fournisseurs cloud s'orientent de plus en plus vers la prédiction plutôt que vers la réaction pure. La fonctionnalité de dimensionnement prédictif d'AWS prévoit la demande à partir de modèles historiques et ajoute de la capacité EC2 avant un pic attendu, plutôt que d'attendre qu'une métrique dépasse un seuil. La question ouverte est de savoir si ces prévisions peuvent suivre le rythme d'un mix de trafic qui change aussi vite que les achats orientés par l'IA actuellement.
Les tests restent l'élément que les équipes sautent le plus souvent. Les tests de charge qui augmentent progressivement de zéro au pic laissent à l'Auto Scaling le temps d'ajouter de la capacité avant la demande simulée, mais ils ne valident pas le comportement face aux pics. Un test conçu autour d'une montée en charge douce réussira sans problème tout en laissant un site exposé au genre de poussée soudaine et inégale que le trafic réel des fêtes produit.
Que la période des fêtes de 2026 reproduise le taux de croissance du trafic IA observé en 2025, ou qu'elle se stabilise dans un modèle plus régulier, c'est le chiffre que chaque équipe plateforme surveillera lors du prochain cycle de prévisions.
