Une billetterie complète en six jours : retour sur un projet sur mesure

Un hôtel entier privatisé pendant deux nuits. Plus d'une centaine de chambres à vendre, chacune incluant les entrées de ses occupants. Une soirée chaque soir, avec du public, des tables réservées et des invitations. Des billets à scanner à l'entrée, et une liste de réservations à transmettre chaque matin à la réception de l'hôtel.

Ouverture des ventes six jours plus tard, à heure fixe.

Le projet venait de l'intérieur : c'est un groupe dont je suis associé qui organisait l'événement. Comme souvent, l'outil est né d'un besoin qu'on avait nous-mêmes, avant d'être une offre.

Les plateformes généralistes savent vendre un billet. Elles ne savent pas vendre une chambre d'hôtel avec des entrées incluses, ventiler la TVA entre une prestation de spectacle et un hébergement soumis au régime de la marge, gérer un contingent de tables à côté du public, ni produire chaque matin la liste des arrivées pour la réception.

Et elles prélèvent entre 5 et 8 % du prix de chaque billet pour ce qu'elles savent faire.

Sur un volume important, la question n'était donc pas de choisir une plateforme, mais de savoir combien coûte un outil qui fait exactement ce qu'il faut.

La vente. Quatre paliers de prix par soir, avec quotas. Le palier suivant s'ouvre automatiquement quand le précédent est épuisé, et la règle est appliquée côté serveur : impossible d'acheter un tarif fermé en contournant l'affichage. Les packs chambre incluent les entrées des occupants, dont les noms sont saisis à la commande, et chaque pack porte deux montants figés dès l'achat, la part soirée et la part hébergement, pour la comptabilité.

Le stock. C'est le cœur du système. Chaque soir dispose d'une jauge découpée en contingents étanches : public, chambres, tables, invitations. Une réservation vérifie tous les stocks concernés dans une seule opération et réserve la place dix minutes, le temps du paiement. Un test simule une ruée de plusieurs milliers d'acheteurs simultanés sur une jauge complète, et vérifie que chaque place n'est vendue qu'une fois. Ce test est rejoué à chaque modification du moteur de stock.

Le paiement. Une commande n'est validée que lorsque le prestataire de paiement le confirme, jamais sur le simple retour du navigateur. Les remboursements effectués sont répercutés automatiquement : billets annulés, places libérées, client prévenu.

Les billets. Un QR code par personne et par soir, signé cryptographiquement, envoyé par email avec le reçu détaillé et, pour les chambres, une confirmation d'hébergement. Les envois passent par une file d'attente régulée, pour qu'un pic de commandes ne fasse pas tomber les emails.

Le scanner. Une application web installable sur n'importe quel téléphone, protégée par un code. Elle télécharge la liste des billets valides à la connexion et décide localement : billet valide, déjà scanné avec l'heure du premier passage, mauvais soir, invalide. Elle fonctionne sans réseau et se resynchronise dès que la connexion revient. Testée sur téléphone réel, en mode avion, avant l'ouverture.

L'exploitation. Une liste d'arrivées envoyée chaque matin à la réception, une page en lecture seule pour attribuer les numéros de chambre, un tableau de bord temps réel des ventes et des entrées, la gestion des paliers et des jauges sans redéploiement, et les exports comptables avec les deux régimes de TVA.

Le développement a été mené avec un agent de programmation, sous direction humaine, avec le client dans la boucle à chaque décision de prix, de stock et d'exploitation.

Concrètement : un cahier des charges rédigé le premier jour, un fichier de règles non négociables relu par l'agent à chaque session (jamais de survente, un billet par personne et par soir, le prestataire de paiement comme seule source de vérité, les prix et quotas en base et jamais dans le code), puis des lots livrés et testés les uns après les autres.

À l'ouverture, le projet comptait plusieurs centaines de tests automatisés, dont une série dédiée au stock et aux contingents, et plus de cent cinquante tests de bout en bout sur mobile et sur grand écran, incluant un parcours de paiement réel. Chaque mise en production est précédée de la suite complète.

Ce qui a compté le plus n'est pas la vitesse d'écriture du code, mais ce que les tests ont attrapé avant l'ouverture. Plusieurs défauts invisibles sur une démonstration, dont un problème de concurrence qui ne se déclenchait qu'avec des centaines d'acheteurs simultanés sur la vraie base de données.

L'agent écrit le code. Les règles, les tests et les arbitrages métier restent humains.

Six jours de travail dirigé, pas six semaines de développement. Une infrastructure à quelques dizaines d'euros par mois, hébergée en Europe. Des frais de paiement limités à ceux du prestataire, là où une plateforme aurait prélevé plusieurs points sur chaque billet.

Mais le vrai gain est ailleurs. L'organisateur est propriétaire de ses données clients, de son tunnel de vente et de sa marque. Il peut créer un palier de prix, fermer les ventes ou déplacer des places d'un contingent à l'autre en un clic, sans dépendre de personne. Et le site est déjà multi-événements : le prochain n'aura pas à être reconstruit.

C'est le modèle que nous défendons : des outils sur mesure, construits vite avec des agents de programmation, mais tenus par des règles écrites, des tests exécutés et quelqu'un qui connaît le métier et tranche.

La vitesse vient de l'agent. La fiabilité vient de la méthode.