# Absorber le pic annuel d’inscriptions d’un club sportif : cache préchauffé

> Chaque année, un formulaire d'inscription annuel subit un pic de charge à heure fixe. Stratégie de préchauffage programmé mise en place pour absorber ce rendez-vous.

- Auteur : WordPress Développement
- Publié le : 2023-12-16
- Mis à jour le : 2023-12-16
- Catégorie : Performance
- URL : https://www.wpmoderne.fr/performance/club-sportif-prechauffer-cache-avant-inscriptions/

## L’essentiel

- L'heure du pic est connue à l'avance, donc anticipable
- Un préchauffage manuel avant l'ouverture évite le premier visiteur qui génère le cache à froid
- Une tâche cron programmée automatise ce préchauffage chaque année

Le 1er septembre à 9h00 précises, chaque année, plusieurs centaines de familles se connectent en même temps pour inscrire leurs enfants aux différentes sections d'un club sportif associatif. Cette régularité, plutôt qu'un problème, constitue une chance rare en matière de performance web : le pic de charge est daté avec une précision à la minute près, un luxe que peu de sites connaissent pour leurs propres pics de trafic.

Le club utilisait un formulaire d'inscription construit sur mesure, avec vérification en temps réel des places disponibles par section, hébergé sur une offre mutualisée modeste mais suffisante en temps normal. Le problème ne se posait qu'une fois par an, mais de façon suffisamment aiguë pour avoir provoqué, l'année précédente, plusieurs minutes d'indisponibilité totale du site au moment critique.

## Pourquoi le premier visiteur payait le prix fort

Le site utilisait un cache de page classique basé sur des fichiers statiques générés à la première visite, puis servis directement sans repasser par PHP pour les visiteurs suivants. Ce mécanisme fonctionne très bien en temps normal, mais présente un défaut connu : quand le cache expire ou vient d'être vidé, le tout premier visiteur qui arrive doit attendre la génération complète de la page, opération nettement plus lourde que la lecture d'un fichier déjà en cache.

À 9h00 précises, ce n'était pas un visiteur qui arrivait en premier sur un cache froid, mais plusieurs centaines simultanément, chacun déclenchant potentiellement sa propre génération de page si le cache n'avait pas eu le temps de se stabiliser après le premier passage.

## La stratégie de préchauffage programmé

La solution retenue consiste à générer le cache artificiellement quelques minutes avant l'heure d'ouverture, via une commande WP-CLI appelant les URL critiques du parcours d'inscription, avant qu'aucun visiteur réel n'y accède.

```
#!/bin/bash
URLS=(
  "https://club-exemple.fr/inscriptions/"
  "https://club-exemple.fr/inscriptions/football/"
  "https://club-exemple.fr/inscriptions/natation/"
  "https://club-exemple.fr/inscriptions/tennis/"
)
for url in "${URLS[@]}"; do
  curl -s -o /dev/null -w "%{http_code} %{time_total}s %{url}\n" "$url"
done
```

Ce script, exécuté depuis une tâche cron système programmée à 8h50, garantit que le cache de chaque page critique est déjà chaud lorsque les premières connexions réelles arrivent dix minutes plus tard, sans qu'aucun visiteur n'ait à subir le coût de la génération initiale.

> L'essentiel à retenir : L'heure du pic est connue à l'avance, donc anticipable ; Un préchauffage manuel avant l'ouverture évite le premier visiteur qui génère le cache à froid ; Une tâche cron programmée automatise ce préchauffage chaque année

## Le cas particulier des données dynamiques

Le compteur de places disponibles par section posait un défi supplémentaire : cette donnée change en permanence pendant la période d'inscription, donc un cache de page classique risquait d'afficher un nombre de places obsolète aux visiteurs suivants. Le compteur a été extrait du cache de page via un appel asynchrone déclenché côté navigateur, interrogeant une route dédiée non mise en cache, pendant que le reste de la page profitait pleinement du cache statique.

- Contenu stable de la page (formulaire, description des sections, tarifs) : servi depuis le cache statique préchauffé
- Compteur de places disponibles : requête séparée non cachée, actualisée à chaque affichage
- Soumission du formulaire : traitement classique côté serveur, hors cache par nature

## Résultat sur l'ouverture suivante

L'année suivante, avec ce préchauffage en place, le site a encaissé le pic de connexions sans aucun ralentissement perceptible ni erreur serveur, contre plusieurs minutes d'indisponibilité l'année précédente. Le club a depuis intégré cette étape de préchauffage à sa liste de vérifications avant chaque campagne d'inscription.

> Un pic de trafic daté à la minute près n'est pas un problème de performance ordinaire, c'est un problème de logistique. La bonne réponse n'est pas de rendre le serveur plus puissant en permanence, mais de préparer précisément le moment où il en a besoin.

## Pour aller plus loin

Cette approche se généralise à tout événement daté à l'avance : ouverture de billetterie, publication d'un communiqué, lancement d'une vente. La clé reste la même : identifier les URL réellement sollicitées au moment du pic, et s'assurer que leur cache est déjà chaud avant que le premier visiteur réel ne se présente.