English
Italiano
Deutsch
Español
Português// 01 — Le problème
Ce qui ne va pas avec Ticketmaster
Ticketmaster est le leader mondial de la billetterie. Pourtant, pour les fans, chaque grosse mise en vente tourne à l'épreuve. Voici ce que je reproche à leur système.
Des sites qui lâchent
Pages blanches, erreurs et lenteurs pile au moment où tout le monde se connecte.
Une file opaque
Tu attends sans savoir si tu as une vraie chance, pour découvrir à la fin qu'il ne reste rien.
Le panier qui expire
Le compte à rebours tombe à zéro pendant la validation bancaire, et tes places repartent.
Le « complet » trop tard
Tu apprends qu'il n'y a plus de places après une longue attente, parfois au moment de payer.
Robots et revendeurs
Des places raflées par des programmes automatiques, puis revendues bien plus cher.
Une loterie déguisée
« Le premier qui clique gagne » se joue à quelques millisecondes : c'est ta connexion qui décide, pas toi.
Des quotas mal répartis
Complet chez un revendeur, alors qu'un autre a encore des places pour le même concert.
Aucune concurrence
Le même groupe produit les tournées et vend les billets. Le département de la Justice américain a lancé une procédure antitrust en 2024.
Ce qui cloche sous le capot
J'ai décortiqué une page d'achat qui tourne sur l'infrastructure de Ticketmaster France, en septembre 2026. Voici ce que l'architecture fait mal.
- D'abord une page blanche. Le serveur envoie une coquille presque vide, et toute la page se construit dans ton navigateur. Tant que le JavaScript n'a pas fini, tu fixes du blanc.
- Des appels API à la chaîne. Chaque requête attend la précédente avant de partir. Le serveur est rapide, mais les prix mettent quand même plusieurs secondes à s'afficher.
- Chaque visiteur sollicite le stock. Chaque chargement déclenche des dizaines d'appels API, dont beaucoup impossibles à mettre en cache. Multiplie par un million de fans, et le système de billetterie commun sature.
- La salle d'attente arrive en retard. La file virtuelle ne se charge qu'après le reste de la page. Elle est censée protéger le système, pas débarquer après la foule.
- Des choses que personne n'a demandées. Menus dans toutes les langues, listes de villes et de genres musicaux, suggestions d'achat : tout est chargé avant ou en même temps que les prix.
- Lourd sans raison. Des centaines de requêtes, un JavaScript découpé en beaucoup trop de fichiers, des images surdimensionnées et un CAPTCHA chargé deux fois.
// 02 — Ça existe déjà
D'autres secteurs gèrent déjà bien pire
Vendre 200 000 places en quelques minutes n'a rien de la science-fiction. Chaque année, le e-commerce, le paiement et le streaming encaissent des pics bien plus violents, et ils tiennent.
Vendre 200 000 places, c'est environ 1 000 réservations par seconde : moins de 0,2 % du pic d'Alibaba. Le vrai sujet n'est pas la puissance des serveurs, c'est la façon de concevoir la vente :
- Une file tirée au sort. Tout le monde arrive avant l'ouverture, l'ordre est tiré au hasard, et chacun voit sa vraie position.
- Une admission calée sur le stock. On ne fait entrer que le nombre de personnes que les places restantes peuvent servir.
- Des places bloquées avant le paiement. Une fois ta carte sortie, tes places sont à toi. Jamais de « complet » au paiement.
- Un stock partagé, sans quotas. Un registre ouvert permet à plusieurs revendeurs de vendre les mêmes places, sans jamais en vendre une deux fois.
- Un « complet » instantané. Dès que tout est vendu, toute la file le sait en quelques secondes.
// 03 — La preuve
Le test de charge en direct
Je conçois une billetterie pensée pour ces moments-là, et je vais la mettre à l'épreuve en public, avec une vraie vente simulée. Aucun vrai billet, aucun vrai paiement.
| Conditions du test | Valeur |
|---|---|
| Tournée mise en vente (fictive) | Ticketmaster's Retirement Plan Tour |
| Personnes connectées en même temps | 200 000 |
| Places en vente (fictives, 4 catégories) | 20 000 |
| Revendeurs simulés partageant le même stock, sans quotas | 3 |
| Part du trafic venant de robots simulés | 20 % |
| Paiements refusés (mode test bancaire) | 5 % |
| Acheteurs qui abandonnent en cours de route | 10 % |
| Participants | Inscrits + utilisateurs virtuels |
| Critères de réussite, publiés à l'avance | Objectif |
|---|---|
| Places vendues deux fois | 0 |
| Erreurs serveur vues par les participants | 0 |
| Vraie position affichée dans la file | < 2 s |
| Temps de réservation (99 % des requêtes) | < 200 ms |
| « Plus de places » annoncé au paiement | Jamais |
| Temps pour vendre toutes les places | < 10 min |
| « Complet » affiché à toute la file | < 5 s |
Les résultats bruts, les scripts de charge et le code du registre seront publiés en open source, que le test réussisse ou non.