« On lance dans trois jours, il faudrait quand même tester la charge. » Cette phrase, prononcée en réunion de préparation du lancement d’une billetterie pour un événement à forte affluence attendue, résume un schéma classique : le test de charge, prévu depuis le début du projet, avait été repoussé à chaque revue de planning au profit de fonctionnalités jugées plus urgentes, jusqu’à se retrouver coincé dans les tout derniers jours avant l’ouverture des ventes.
Le test, lancé avec k6 en simulant l’ouverture simultanée des ventes par plusieurs milliers de visiteurs, a immédiatement révélé un goulot d’étranglement sur la vérification de disponibilité des places, une requête exécutée sans verrou ni mise en cache adaptée, qui saturait la base de données bien avant que le nombre de visiteurs simulés n’atteigne les projections réelles attendues pour l’ouverture des ventes.
Ce que trois jours permettent de faire, et ce qu’ils ne permettent pas
Un délai aussi court élimine d’emblée toute option de refonte structurelle, comme l’introduction d’une file d’attente virtuelle ou une réorganisation complète du schéma de base de données, deux solutions qui auraient réellement traité la cause du problème mais qui nécessitaient plusieurs semaines de développement et de test à leur tour. Le choix s’est donc porté sur des correctifs ciblés, appliqués et retestés en boucle courte pendant ces trois jours.
// Correctif d'urgence : mise en cache courte de la disponibilité des places
function verifier_disponibilite_places( $evenement_id ) {
$cle_transient = 'dispo_places_' . $evenement_id;
$dispo = get_transient( $cle_transient );
if ( false === $dispo ) {
$dispo = calculer_disponibilite_reelle( $evenement_id );
set_transient( $cle_transient, $dispo, 5 ); // 5 secondes seulement
}
return $dispo;
}
Une mise en cache de cinq secondes seulement, jugée acceptable pour ce cas précis car une billetterie tolère une légère imprécision transitoire sur la disponibilité affichée sans risque réel de survente grâce à une vérification stricte au moment du paiement effectif.
Distinguer un correctif acceptable d’une dette dangereuse
Tous les correctifs envisagés dans l’urgence n’ont pas été retenus. L’idée de désactiver temporairement la vérification de disponibilité en base au profit d’un compteur en mémoire partagée entre les workers a été écartée, car elle aurait introduit un risque de survente en cas de redémarrage d’un worker en cours de vente, un risque jugé inacceptable comparé au gain de performance espéré.
- Correctif retenu : mise en cache très courte, avec vérification stricte conservée au moment du paiement.
- Correctif écarté : compteur en mémoire non persistante, risque de survente en cas de redémarrage.
- Correctif reporté après lancement : réorganisation du schéma de requête, jugée trop risquée à tester en trois jours.
Ce que le test a permis d’éviter malgré tout
Malgré la précipitation, ce test de charge tardif a évité un scénario bien pire : découvrir le goulot d’étranglement au moment même de l’ouverture réelle des ventes, face à des milliers de visiteurs réels et sans aucune marge de manœuvre pour réagir. Trois jours restent un délai inconfortable, mais infiniment préférable à zéro jour.
| Scénario | Marge de correction disponible | Risque pour le lancement |
|---|---|---|
| Test de charge trois jours avant | Correctifs ciblés uniquement | Réduit, sous contrôle |
| Aucun test de charge avant lancement | Aucune | Panne en direct devant les clients |
Le vrai correctif est arrivé après le lancement
Une fois l’événement passé et les ventes terminées sans incident majeur, la réorganisation du schéma de requête, écartée par prudence dans l’urgence, a été menée sereinement dans les semaines suivantes, accompagnée cette fois d’un test de charge mené deux mois avant l’événement suivant plutôt que trois jours avant.
Un correctif d’urgence n’est jamais une solution, seulement un délai acheté à un prix qu’il faut ensuite honorer. Le vrai travail commence une fois la panique retombée, pas pendant.
En résumé
Lancer un test de charge trois jours avant un événement à forte affluence limite sévèrement les options de correction, mais reste infiniment préférable à ne pas en lancer du tout. La leçon retenue par l’équipe ne porte pas sur les correctifs eux-mêmes, plutôt bien choisis dans les circonstances, mais sur la nécessité de planifier ce test bien plus tôt la fois suivante, pour disposer du temps nécessaire à un correctif structurel plutôt qu’à un simple pansement.
