Le contexte
Un opérateur français d’avantages salariés vend des places, des entrées et des offres à prix réduit, le plus souvent aux salariés d’une entreprise via leur comité. Vu du bénéficiaire, le métier paraît simple : une page, un prix réduit, un billet dans la boîte mail. Vu de l’intérieur, il l’est beaucoup moins, parce que rien n’est homogène en amont.
Chaque fournisseur livre ses billets à sa façon. Certains fournissent des PDF à l’avance, d’autres veulent confirmer chaque réservation à la main, d’autres exposent une API de billetterie avec son propre catalogue, ses disponibilités et ses règles d’annulation. Chaque comité d’entreprise, de son côté, veut son domaine, ses couleurs, son catalogue et ses propres règles de subvention. Et une place de spectacle vendue deux fois n’est pas un bug d’affichage : c’est un bénéficiaire refoulé à l’entrée.
Ce que nous avons fait
Nous avons conçu, développé et exploitons l’ensemble : le site public, les espaces réservés aux comités d’entreprise, le back-office et les services qui tournent derrière.
- Un modèle de stock qui absorbe l’hétérogénéité des fournisseurs. Billets pré-fournis, génération à la demande, validation par le partenaire, validation interne, ou billetterie tierce synchronisée : quatre modes de livraison et des catalogues externes, derrière un seul parcours d’achat. C’est l’inverse du réflexe habituel, qui consiste à faire porter la complexité fournisseur par l’acheteur.
- Une gestion des disponibilités transactionnelle. Les places sont réservées dès la mise au panier et libérées si le paiement n’aboutit pas, avec des écritures conditionnelles pour que deux achats simultanés sur la dernière place ne puissent pas réussir tous les deux. Les stocks cohabitent en date fixe et en période flexible, et les créneaux récurrents sont générés à partir de modèles hebdomadaires plutôt que saisis à la main.
- Le multi-tenant en marque blanche. Des dizaines de comités disposent de leur domaine, de leur thème, d’un sous-ensemble de catalogue et de leur propre contenu — actualités, médiathèque, sondages, bannières. Leurs administrateurs gèrent tout cela eux-mêmes, avec des permissions fines, sans accès aux fonctions internes et sans qu’une ligne de code soit dupliquée par client.
- La chaîne financière, qui est la partie la plus ingrate. Prix d’achat, prix public et prix négocié coexistent, avec frais, options, remises ciblées, ventes flash et subventions du comité. Le point dur est la TVA : la revente de billets mélange TVA sur marge et TVA classique, ce qui impose une ventilation ligne par ligne, cohérente entre le billet, la facture et la comptabilité.
- La livraison des billets et des documents. Génération des PDF avec QR codes et codes-barres, factures, e-mails de confirmation. Nous avons investi autant sur la délivrabilité que sur le reste — rejets, plaintes, liste de suppression — parce qu’un billet qui n’arrive pas coûte un appel au support et une confiance.
- La recherche des activités, en recherche sémantique appuyée sur des embeddings Amazon Bedrock et Amazon S3 Vectors, ce qui évite d’exploiter et de payer une base vectorielle dédiée à cette échelle.
- La conformité RGPD, traitée comme un sujet d’architecture : suppression du traçage analytique sur le front public, e-mails sans pistage d’ouverture, et droits des personnes outillés plutôt que traités à la main.
Le résultat
La plateforme est en production et nous l’exploitons. Un nouveau comité d’entreprise s’ouvre par configuration, pas par développement. Un nouveau fournisseur se raccorde en choisissant un mode de livraison existant, sans toucher au parcours d’achat.
L’enseignement le plus utile porte sur la TVA et les remises. Nous avons d’abord traité la ventilation comme un détail de facturation, et c’est devenu le sujet qui a demandé le plus de reprises : dans la revente de billets, le calcul du prix est le produit, pas un affichage. Le deuxième enseignement est plus banal et tout aussi coûteux à ignorer : la moitié du travail d’une billetterie se joue après le paiement.