Faut-il vraiment payer un serveur puissant toute l’année pour un événement qui dure trois jours ? La question se pose concrètement pour un festival de musique dont le site WordPress reçoit l’essentiel de ses visites dans les deux semaines qui précèdent l’ouverture, avec un pic absolu le jour de l’annonce de la programmation et pendant le festival lui-même, quand les festivaliers consultent les horaires de passage en direct depuis leur téléphone.
Entre ces fenêtres de forte affluence, le site retombe à un trafic de consultation ordinaire, comparable à celui d’une association culturelle locale. Louer un serveur dimensionné pour le pic et le garder toute l’année revient à payer, la majeure partie du temps, pour une capacité qui ne sert à rien.
Dimensionner pour l’instant précis, pas pour l’année
La démarche retenue a consisté à découper le calendrier en trois phases distinctes, chacune avec son propre gabarit de serveur chez un fournisseur facturant à l’heure :
- toute l’année, un petit VPS suffisant pour un site vitrine avec cache de page complète ;
- les deux semaines précédant l’ouverture, un gabarit intermédiaire, activé à la date de sortie de la programmation ;
- les trois jours du festival, un gabarit maximal, avec plusieurs vCPU et une bande passante réseau élevée pour absorber les rafraîchissements répétés de la page horaires.
Préparer le serveur temporaire à l’avance, pas en urgence
Le point critique de cette approche n’est pas la puissance louée, mais la préparation en amont. Un serveur temporaire monté à la dernière minute, sans configuration éprouvée, introduit plus de risque qu’il n’en résout. La méthode retenue a été de créer une image système, un instantané complet du serveur intermédiaire déjà rodé, incluant Nginx, PHP-FPM et la configuration de cache, puis de redéployer cette image sur le gabarit maximal la veille du festival plutôt que de repartir d’une installation vierge.
# Script exécuté la veille du festival
IMAGE_ID=$(cloud-cli snapshot create --server intermediaire --name "festival-2024-base")
cloud-cli server create \
--image "$IMAGE_ID" \
--type "8vcpu-16go" \
--name "festival-2024-pic" \
--region "gra"
Le trafic est basculé vers ce nouveau serveur par un simple changement d’enregistrement DNS de type A, planifié avec un TTL abaissé à 300 secondes dans les jours précédents pour que la bascule soit rapide et non bloquante pour les visiteurs déjà en cache DNS.
Ce que la billetterie externe retire de la charge
Un choix décisif dans le dimensionnement a été de ne jamais héberger la billetterie elle-même sur ce serveur WordPress. La vente de billets est gérée par une plateforme spécialisée externe, intégrée au site par un simple lien ou un widget embarqué. Cette séparation retire du serveur WordPress la charge la plus imprévisible et la plus sensible, celle des transactions de paiement, pour ne lui laisser que la consultation de contenu, largement plus facile à mettre en cache.
La page horaires, seule vraie source de charge pendant l’événement
Pendant les trois jours du festival, la quasi-totalité des requêtes concerne une unique page : celle des horaires de passage, rafraîchie manuellement par des festivaliers qui vérifient si un concert est retardé. Un cache de fragment de trente secondes sur cette page précise, plutôt qu’un cache de page complète classique de plusieurs minutes, suffit à absorber la charge tout en gardant une information suffisamment fraîche pour rester utile en cas de changement de dernière minute.
function festival_get_horaires_html() {
$cle = 'festival_horaires_html';
$html = get_transient( $cle );
if ( false === $html ) {
ob_start();
// Récupération et mise en forme des horaires du jour.
include get_template_directory() . '/partials/horaires.php';
$html = ob_get_clean();
set_transient( $cle, $html, 30 );
}
return $html;
}
Redescendre dès le lundi matin
Le redimensionnement vers le bas est planifié avant même le début du festival, avec une tâche cron côté fournisseur programmée pour le lundi suivant, plutôt que laissée à la vigilance d’un organisateur épuisé par trois jours d’événement. Le serveur repasse alors sur le gabarit intermédiaire pendant une semaine de bilan, avant de revenir au petit VPS de croisière.
Un serveur de festival se prépare la veille, pas le matin même : la moitié des incidents évités sur cet événement l’ont été par une image système déjà testée, pas par la puissance brute louée en dernière minute.
Ce qu’on retient
Pour un événement dont le trafic se concentre sur quelques jours par an, l’abonnement annuel surdimensionné n’a pas de sens économique. La location à l’heure, associée à une image système préparée à l’avance et à une billetterie externalisée, permet d’absorber le pic sans faire peser sur le budget de l’association organisatrice le coût d’une capacité inutilisée onze mois sur douze.
