Un million de requêtes en une heure : c’est le trafic mesuré lors du lancement d’une édition limitée d’un produit de collection, sur une boutique dont le trafic habituel plafonnait autour de vingt mille requêtes horaires. Le facteur quarante-cinq n’avait été anticipé qu’à moitié par l’équipe technique, malgré une préparation de plusieurs semaines.
Le produit, disponible en quantité volontairement limitée à des fins commerciales, avait été annoncé plusieurs jours à l’avance sur les réseaux sociaux de la marque, avec une heure de mise en vente précise communiquée publiquement — configuration classique pour générer un pic de trafic concentré sur une fenêtre très courte.
La décision prise en amont : un mode file d’attente pré-construit
La décision la plus structurante a été prise trois semaines avant le lancement : ne pas compter sur l’infrastructure habituelle pour absorber le pic, mais construire une page de file d’attente statique, hébergée séparément de WordPress, capable d’encaisser un volume de requêtes bien supérieur à ce que le serveur d’application pouvait traiter.
Cette page, servie directement par le CDN sans passer par PHP ni par la base de données, affichait une position de file estimée et rafraîchissait automatiquement toutes les quinze secondes, avec un jeton de session généré côté edge pour garantir l’ordre d’arrivée sans sollicitation du serveur d’origine.
Le seuil de bascule : la charge serveur, pas le nombre de visiteurs
Fixer le seuil de bascule vers le mode file d’attente sur un nombre de visiteurs simultanés se serait révélé trop imprécis : deux visiteurs qui naviguent tranquillement sur des fiches produit ne pèsent pas la même charge que deux visiteurs qui rafraîchissent frénétiquement la page de paiement. Le seuil retenu a porté sur la charge réelle du serveur applicatif (temps de réponse moyen des requêtes PHP), surveillée en continu, avec un déclenchement automatique de la file d’attente dès que le temps de réponse moyen dépassait 800 millisecondes sur une fenêtre glissante de trente secondes.
Pendant l’incident : les décisions prises en temps réel
Malgré cette préparation, le pic réel a nécessité des ajustements en direct. Le nombre de visiteurs simultanément autorisés à accéder au tunnel de commande, initialement fixé à 200, a été réduit à 80 après les dix premières minutes, le temps de réponse du paiement se dégradant plus vite que prévu avec le prestataire de paiement tiers, lui-même mis sous tension par l’afflux simultané d’autres boutiques utilisant la même passerelle ce jour-là.
- Minute 0 à 5 : bascule automatique en file d’attente dès le dépassement du seuil de charge.
- Minute 10 : réduction manuelle du nombre de sessions simultanées admises en tunnel de commande.
- Minute 25 : désactivation temporaire des recommandations de produits associés sur la fiche produit, pour réduire la charge de requêtes secondaires.
- Minute 40 : stabilisation, le stock du produit en édition limitée étant épuisé, réduisant mécaniquement l’affluence sur le tunnel de paiement.
Ce qui a été sous-estimé
Le point sous-estimé n’était pas la volumétrie de trafic front, correctement anticipée par la page de file d’attente, mais la dépendance à un prestataire de paiement externe dont la propre capacité n’était pas sous le contrôle de l’équipe. Un pic de commandes concentré sur une fenêtre de quelques minutes sollicite non seulement le serveur de la boutique, mais l’ensemble de la chaîne de paiement, invisible depuis les outils de supervision internes tant qu’aucun incident ne se déclare côté prestataire.
Conseil maison : lors de la préparation d’un lancement à fort trafic attendu, contactez le prestataire de paiement en amont pour connaître ses propres limites de charge. La résilience de votre boutique ne vaut que ce que vaut le maillon le plus faible de la chaîne complète de la commande.
En résumé
Encaisser un million de requêtes en une heure sans effondrement a reposé sur une page de file d’attente statique préparée à l’avance, un seuil de bascule fondé sur la charge réelle plutôt que sur un comptage de visiteurs, et une capacité d’ajustement manuel en temps réel pendant l’incident. La promotion marketing de l’opération elle-même, avec son calendrier de communication, n’entre pas dans le périmètre technique de ce retour d’expérience.
