Que se passe-t-il quand un site habitué à quelques dizaines de visites quotidiennes reçoit, en l’espace d’une matinée, l’équivalent de deux mois de trafic ? C’est la question que pose chaque année la période des primeurs pour les domaines viticoles vendant en ligne : une fenêtre commerciale très courte, annoncée à l’avance par voie de presse spécialisée, qui concentre l’essentiel des ventes annuelles sur une poignée de jours.
Le cas suivi ici concerne un domaine du Bordelais dont le site, hébergé sur une offre mutualisée milieu de gamme, tournait toute l’année sans le moindre incident. La campagne de primeurs, annoncée neuf jours durant lesquels le site allait concentrer près de 40 % de son trafic annuel, imposait de revoir cette tranquillité apparente.
Ce que ce cas ne couvre pas
Il ne s’agit pas ici d’optimiser la boutique en ligne elle-même — tunnel de commande, moyens de paiement, gestion des stocks. Le sujet est strictement l’hébergement : la capacité du serveur à absorber un afflux de visiteurs et de commandes simultanées sans ralentir ni tomber, quelle que soit la solution e-commerce installée par-dessus.
Identifier la fenêtre de risque réelle
Première étape : ne pas confondre la date d’ouverture officielle des ventes avec la fenêtre de risque réelle. Dans ce cas précis, l’essentiel du trafic n’arrivait pas à l’heure exacte de l’ouverture, mais dans les deux heures suivant l’envoi d’une newsletter aux acheteurs habituels, puis un second pic le lendemain matin porté par la presse spécialisée. Deux créneaux bien identifiés, donc, plutôt qu’une seule journée à surveiller de façon diffuse.
Cette précision change la façon de dimensionner : plutôt que de sur-provisionner neuf jours pleins, il devenait possible de réserver des ressources supplémentaires sur des créneaux ciblés, moins coûteux qu’un palier permanent.
Le test en conditions réelles
Deux semaines avant l’ouverture, une simulation de charge a été menée avec l’outil k6, en reproduisant un scénario réaliste : consultation d’une fiche de cuvée, ajout au panier, passage en caisse. L’objectif n’était pas de mesurer un nombre abstrait de requêtes par seconde, mais de vérifier à quel niveau de trafic simultané le temps de réponse du serveur commençait à se dégrader.
import http from 'k6/http';
import { sleep } from 'k6';
export const options = {
stages: [
{ duration: '2m', target: 50 },
{ duration: '5m', target: 200 },
{ duration: '2m', target: 0 },
],
};
export default function () {
http.get('https://exemple-domaine.fr/cuvee-2019/');
sleep(1);
}Le test a révélé un point de rupture net autour de 140 visiteurs simultanés, bien en dessous du pic attendu. La cause : un nombre de processus PHP-FPM limité par l’offre mutualisée, sans possibilité de l’augmenter sans changer de formule.
La solution retenue : un palier temporaire
Plutôt que de migrer précipitamment vers un serveur dédié pour neuf jours d’activité, l’hébergeur proposait un palier de puissance réservable à l’avance, activable et désactivable à la demande depuis l’espace client. Cette option, souvent ignorée des clients d’offres mutualisées, permettait de multiplier temporairement le nombre de processus PHP-FPM disponibles sans changer d’infrastructure ni de configuration DNS.
- Réservation du palier renforcé cinq jours avant l’ouverture, avec activation automatique la veille au soir.
- Mise en place d’un cache de page complet pour les fiches de cuvées, avec exclusion du panier et du tunnel de commande.
- Surveillance en direct du nombre de processus PHP occupés via le tableau de bord de l’hébergeur, avec un seuil d’alerte fixé à 80 % d’occupation.
- Désactivation programmée du palier renforcé au dixième jour, pour ne pas prolonger inutilement le coût.
Ce que le pic a réellement donné
Le jour de l’ouverture, le nombre de visiteurs simultanés a atteint 210 au plus fort de la matinée, dépassant largement le point de rupture initial mesuré deux semaines plus tôt. Grâce au palier renforcé et au cache de page, le temps de réponse moyen est resté sous la seconde, y compris pendant les quinze minutes qui ont suivi l’envoi de la newsletter.
Le repère qu’on retient de ce type de campagne : mieux vaut un palier ciblé de quelques jours, testé à l’avance, qu’un serveur surdimensionné à l’année pour un trafic qui ne se manifeste que deux fois par an.
Notre verdict
Ce cas illustre un principe valable bien au-delà du secteur viticole : un site à trafic saisonnier n’a pas nécessairement besoin d’un hébergement surdimensionné en permanence, mais d’une capacité de montée en charge testée et activable ponctuellement. Le test de charge préalable reste l’étape la plus souvent négligée ; c’est pourtant lui qui a permis, ici, d’identifier un point de rupture invisible en fonctionnement normal, avant qu’il ne se manifeste devant les clients au pire moment possible.
