Planification d'un MVP de billetterie : survente, remboursements, transferts

Le vrai problème : vendre des billets, c'est surtout des règles, pas des écrans

La plupart des applications de billetterie échouent pour une raison ennuyeuse : les écrans sont jolis, mais les règles manquent ou sont vagues. Les outils d'IA peuvent générer une page de paiement en quelques minutes. Ils ne peuvent pas deviner ce que vous entendez par « il ne reste qu'un billet » quand 200 personnes cliquent sur Acheter en même temps.

La survente, c'est exactement ça : vous encaissez de l'argent pour des billets que vous n'avez pas réellement. Dans la vraie vie, ça se traduit par deux clients avec un reçu pour le dernier siège VIP, ou un rapport du lieu disant que 300 personnes se sont enregistrées pour une salle de 250 places.

La cause racine est souvent simple. L'inventaire est compté à un endroit, les paiements sont confirmés ailleurs, et il n'y a pas de moment clair où un billet est vraiment réservé. Ajoutez des paiements par carte lents, une mauvaise réception, des rafraîchissements de page et des onglets multiples, et vous obtenez des ventes dupliquées.

Le dommage n'est pas que de l'embarras. La survente crée des clients en colère, une boîte support pleine de "où est mon billet", des demandes de remboursement, des contestations bancaires, et des avis qui pénalisent votre événement suivant.

Pour un MVP de billetterie, « MVP » doit signifier le flux le plus petit qui puisse vendre des billets en toute sécurité, pas le plus petit nombre d'écrans. Un MVP sécurisé peut être basique et fonctionner si vous répondez aux questions difficiles dès le départ.

Avant d'écrire une seule ligne de code, notez les règles qui décident de ce qui est réel :

• Quand un billet devient-il réservé, et combien de temps la réservation dure-t-elle ?
• Qu'est-ce qui compte comme « vendu » : le début du paiement, le paiement réussi, ou l'émission d'un reçu ?
• Que se passe-t-il si le paiement réussit après l'expiration de la réservation ?
• Quelle est la limite par acheteur, et comment l'appliquez-vous ?
• Quand l'inventaire est bas, bloquez-vous les ventes, proposez-vous une liste d'attente, ou utilisez-vous une file d'attente de réservations ?

Un scénario rapide montre pourquoi c'est important. Vous avez 50 billets early-bird. À 10:00, 80 personnes essaient d'acheter. Si votre règle est « l'inventaire diminue après le paiement », vous pouvez survendre en quelques secondes. Si votre règle est « l'inventaire est réservé 8 minutes pendant le checkout », vous réduisez le risque, mais vous devez toujours une réponse claire pour ce qui arrive à la minute 9.

Formulez l'objectif ainsi : écrivez d'abord les règles en anglais simple (ou dans la langue de travail), puis générez le MVP autour d'elles.

Définir la portée du MVP en termes simples

Un MVP de billetterie est plus facile à bâtir quand vous le décrivez comme un ensemble de règles, pas comme un ensemble d'écrans. Avant de toucher au code (ou de demander à un outil d'IA de le générer), soyez clair sur :

• Qui utilise le système
• Quelles « choses » y existent
• Ce qui ne doit jamais arriver

Commencez par les rôles minimaux :

• Acheteur : paie et reçoit les billets
• Participant (optionnel) : la personne qui se présente, si différente de l'acheteur
• Organisateur : crée l'événement et voit les ventes
• Équipe à l'entrée : scanne les billets et enregistre les présences

Si vous avez envie d'ajouter « admin marketing », « promoteur », « finance » ou « agent support » en v1, freinez-vous. Ceux-ci peuvent venir plus tard une fois que les bases fonctionnent.

Ensuite, nommez les objets minimaux que vous stockerez. Une appli de billetterie simple évitera rarement : Event, Ticket Type, Order, Ticket et Check-in.

Puis décidez de ce qui doit toujours être vrai (vos non-négociables). Exemples :

• Un billet ne peut pas être enregistré deux fois.
• Un billet remboursé ne peut pas être utilisé.
• Un billet transféré a exactement un propriétaire actuel.

Écrivez-les en phrases simples pour pouvoir les tester plus tard.

Un scénario aide : « Sam achète 2 billets Admission générale. Il transfère 1 à Alex. Alex s'enregistre à l'entrée. Sam demande un remboursement pour son billet restant avant la date limite de remboursement. » Si vos règles ne disent pas clairement ce qui arrive à chaque étape, le code va deviner, et deviner conduit aux litiges.

Enfin, décidez ce que vous ne construirez pas en v1. Plans de places assises, codes promo, taxes complexes, passes multi-jours, ventes au guichet en espèces, listes d'attente, et équipes organisatrices avec permissions sont des éléments courants à laisser pour plus tard.

Bases de l'inventaire : ce que vous comptez réellement

Avant de concevoir des écrans, décidez ce qu'un « billet » signifie dans votre système. La plupart des bugs commencent ici parce que l'appli ne peut empêcher la survente que si tout le monde est d'accord sur l'unité exacte comptée.

Votre unité d'inventaire doit correspondre à la façon dont les gens achètent et à la façon dont le personnel enregistre. Les unités courantes sont par type de billet (Général, VIP), par jour (ven vs sam), par créneau horaire (10:00, 10:30) ou par siège (Rang A, Siège 12). Choisissez-en une comme unité principale, même si vous l'affichez différemment plus tard.

Exemple : un atelier a trois sessions par jour avec 10 places chacune. Si vous comptez « par jour », vous pouvez vendre la session du matin et afficher encore « 10 restants » pour l'après-midi. Si vous comptez « par créneau », chaque session a son propre nombre et votre appli reste honnête.

Vous devez aussi décider comment afficher le faible inventaire. Certains événements aiment « Il n'en reste que 2 ». D'autres préfèrent « Disponible » vs « Complet » pour éviter les plaintes quand les comptes changent vite. Quelle que soit la méthode, traitez ce que vous affichez comme un indice, pas comme une promesse.

Définissez les états des billets en langage simple, et gardez-les stricts :

• Réservé : une place est bloquée pendant le checkout
• Vendu : le paiement a réussi et l'acheteur possède le billet
• Réservation expirée : la réservation a pris fin ou le paiement a échoué, la place retourne à l'inventaire

Puis écrivez une règle qui empêche la survente, et assurez-vous qu'elle est appliquée par le serveur et la base de données, pas seulement par l'UI :

"Un achat ne peut devenir Vendu que s'il existe au moins 1 unité disponible pour cet article d'inventaire exact, et le système réduit la disponibilité au même moment où il marque le billet comme Vendu."

Si un prototype ne vérifie la disponibilité que sur la page, il vendra le même dernier billet deux fois sous forte charge.

Arrêter la survente : réservations, expirations et conditions de course

La survente survient généralement dans l'écart entre « quelqu'un a cliqué Acheter » et « l'argent a réellement été encaissé ». Votre appli a besoin d'une règle claire pour cet intervalle.

Utilisez des réservations temporaires (et soyez précis)

Une réservation est une courte retenue qui bloque l'inventaire pendant que quelqu'un termine le paiement. Choisissez une fenêtre qui correspond au comportement réel. Pour beaucoup d'événements, 5 à 15 minutes suffisent : assez pour payer, assez courte pour ne pas geler l'inventaire toute la nuit.

Décidez ce qui réinitialise le minuteur. Vous pouvez autoriser une seule réinitialisation quand l'acheteur revient du pas de paiement, mais pas à chaque rafraîchissement. Si le rafraîchissement prolonge la réservation indéfiniment, une personne peut bloquer l'inventaire.

Décidez aussi ce qui arrive quand la réservation expire. La règle la plus simple et la plus sûre : quand le temps est écoulé, les billets retournent automatiquement à l'inventaire disponible.

Quand l'inventaire diminue-t-il ?

Vous avez trois options courantes :

• Diminuer l'inventaire au début du checkout : le plus sûr contre la survente, mais vous verrez plus d'abandons de réservations.
• Diminuer l'inventaire lors du succès du paiement : moins d'abandons, mais il faut quand même une réservation pour éviter les collisions.
• Diminuer l'inventaire après capture/règlement : généralement trop tard pour la billetterie sauf si la demande est faible.

Pour beaucoup de MVP, une approche pratique est : créer une réservation quand le checkout commence, puis convertir la réservation en Vendu seulement après le paiement réussi.

Préparez-vous aux échecs et paiements lents

Les paiements échouent pour des raisons normales : mauvais numéros, refus bancaire, fermeture d'app pendant le checkout, ou réponse tardive du prestataire.

Votre règle doit être automatique et prévisible :

• Si le paiement échoue, libérez la réservation (immédiatement si vous pouvez confirmer l'échec).
• Si le paiement est toujours en attente, ne libérez pas la réservation prématurément juste parce que vous n'avez pas eu de retour.

Considérez « pas encore de réponse » différemment de « échec ». Libérer trop tôt peut créer des doubles-ventes quand un paiement lent réussit finalement.

Le problème du dernier billet (conditions de course)

Imaginez deux personnes achetant le billet final à 19:59. Si votre système vérifie d'abord la disponibilité puis met à jour après, les deux peuvent passer la vérification.

La solution n'est pas un plus bel écran. La solution est une décision atomique côté serveur : une seule requête est autorisée à créer la réservation (ou l'achat) pour cette dernière unité. La seconde requête doit perdre proprement avec une réponse claire « Complet », et rien ne doit être facturé.

Si vous voulez une liste de décisions simple pour aligner tout le monde, écrivez-la avant de construire :

• Fenêtre de réservation : combien de minutes, et le rafraîchissement l'étend-il ?
• Réinitialisation de réservation : oui/non, et quand exactement
• Inventaire décrémenté : à la création de la réservation ou au succès du paiement
• Échec de paiement : libération immédiate vs expiration
• Collision du dernier billet : la première réservation gagne, la seconde obtient "complet"

Règles de remboursement à définir avant de construire quoi que ce soit

Le remboursement semble un bouton simple, mais c'est un ensemble de choix qui affecte l'argent, le temps du support et la confiance. Écrivez les règles en mots simples d'abord, puis transformez-les en logique.

Fixez des fenêtres de remboursement claires

Choisissez un petit nombre de fenêtres temporelles et tenez-vous-y. Un schéma courant : remboursement complet jusqu'à une date, remboursement partiel jusqu'à une date ultérieure, et aucun remboursement proche de l'événement.

Gardez les fenêtres basées sur le temps, pas "au cas par cas", afin que le support ne rende pas des décisions au jugé. Si vous voulez de la flexibilité, ajoutez une seule exception contrôlée comme « l'organisateur peut approuver des remboursements manuels », et enregistrez qui a approuvé.

Décidez des frais, annulations et des données à conserver

Les frais sont souvent à l'origine des disputes de remboursement. Choisissez une règle simple : le client paie les frais, l'organisateur paie les frais, ou partage. Si vous n'êtes pas sûr, « les frais ne sont pas remboursables » est souvent le choix le moins surprenant, tant que c'est clairement affiché au checkout.

Définissez aussi ce qui arrive quand l'organisateur change le plan :

• Si l'événement est annulé : émettez-vous des remboursements automatiques complets, et les frais sont-ils remboursés ?
• Si l'événement est reprogrammé : les clients peuvent-ils garder leurs billets, et jusqu'à quand peuvent-ils demander un remboursement ?
• Si le lieu/la plage de dates change : traitez-vous cela comme une reprogrammation et prolongez-vous la fenêtre de remboursement ?

Avant de coder, confirmez les données minimales nécessaires pour émettre des remboursements en toute sécurité : ID de commande, statut du paiement, statut du billet, statut du check-in, et historique des remboursements.

Exemple : quelqu'un achète deux billets, en transfère un à un ami, puis demande un remboursement. Vos règles doivent dire si les remboursements partiels sont autorisés et si les billets déjà enregistrés deviennent non remboursables. Construire d'abord puis décider ensuite mène à des états incohérents.

Transferts de billets : rester sûr sans être pénible

Les transferts semblent un bonus sympa, mais ils deviennent vite un problème de support si les règles ne sont pas claires. L'objectif est simple : permettre aux acheteurs de céder un billet quand leurs plans changent, sans faciliter la fraude ou la revente.

D'abord, décidez si les transferts sont autorisés du tout, et la date limite. « Autorisé jusqu'à l'ouverture des portes » (ou quelques heures avant) est courant parce que cela donne de la stabilité à l'équipe d'entrée.

Ensuite, choisissez ce que vous transférez :

• Billets individuels (plus convivial pour des groupes d'amis)
• Commandes entières (plus simple pour des achats d'entreprise ou en lots)

Le mauvais choix crée de la confusion à l'entrée : « J'ai acheté 4 billets, mais il n'y en a qu'un dans mon compte. »

Règles d'identité : ce qui change réellement

Décidez ce que signifie la "propriété". Le nom sur le billet est-il obligatoire et doit-il correspondre à une pièce d'identité ? Si vous exigez un nom, définissez ce qui se met à jour lors d'un transfert : le nom du participant, le compte qui peut accéder au QR et l'email qui reçoit les mises à jour. Gardez cela cohérent entre remboursements, transferts et check-in.

Limites anti-abus qui restent raisonnables

Vous n'avez pas besoin d'une sécurité lourde pour réduire les abus. Quelques limites simples suffisent : date limite, nombre maximal de transferts par billet, délai entre transferts, et règle empêchant le transfert de billets remboursés ou signalés pour contestation.

Exemple : quelqu'un achète 6 billets, les transfère vers 6 emails différents, puis tente de les récupérer. Une règle « 1 seul transfert par billet » plus un court délai d'attente empêche la plupart de ces abus.

Check-in et QR : où la survente se révèle

La survente n'est pas seulement un problème de checkout. Elle apparaît souvent à la porte, quand deux personnes se présentent avec ce qui semble être le même QR valide.

Commencez par une définition simple d'un billet valide à la porte : il est valide uniquement s'il est payé (ou marqué comp), non remboursé, non transféré ailleurs, et non déjà enregistré. Cela signifie que le check-in est un changement d'état, pas juste un scan.

Le hors-ligne ou une mauvaise réception est là où beaucoup de MVP cassent. Vous avez trois approches réalistes :

• Check-in uniquement en ligne : le plus précis, le pire pour des lieux sans réception
• Hors-ligne avec liste autorisée mise en cache : téléchargez les billets valides du jour, puis synchronisez les scans ensuite
• Hybride : autorisez le scan hors-ligne, mais limitez-le (par exemple, un seul appareil)

Les remboursements et transferts doivent changer le comportement du QR immédiatement. Si quelqu'un est remboursé, son QR doit cesser de fonctionner. Si un billet est transféré, l'ancien QR doit être invalidé et un nouveau QR remis au nouveau propriétaire. Sinon, l'acheteur original peut garder une capture d'écran et entrer quand même.

Décidez les cas limites avant que votre équipe doive improviser :

• Captures d'écran dupliquées : le premier scan gagne-t-il toujours ?
• Contournement manuel : qui peut forcer l'entrée et enregistrez-vous une raison ?
• Comps/liste invités : comment sont-ils émis et peuvent-ils être révoqués ?
• Montées de gamme ou remboursements partiels : le QR change-t-il et que doit afficher l'app d'entrée ?
• Incohérence de nom : exigez-vous une pièce d'identité, ou le QR suffit-il ?

Exemple : un acheteur transfère un billet à un ami une heure avant l'ouverture. Si vous n'invalidez pas l'ancien QR, les deux peuvent arriver et sembler "valides" pour un scanner simple.

Étape par étape : transformer les règles en MVP généré par IA en toute sécurité

Construire un MVP de billetterie avec l'IA va plus vite quand vous traitez l'application comme un moteur de règles d'abord et une UI ensuite. Des règles claires produisent une charpente utilisable. Des règles floues produisent une appli jolie qui échoue face à de vrais acheteurs.

Commencez par une spécification d'une page

Gardez-la courte, mais spécifique. Couvrez l'inventaire (ce que vous comptez), les réservations (comment vous réservez), les remboursements (qui récupère l'argent et quand), les transferts (ce qui est autorisé) et le check-in (ce que signifie "utilisé"). Ajoutez quelques lignes "ne doit jamais arriver" comme :

• Ne jamais vendre au-delà de la capacité.
• Un QR code ne doit être scanné qu'une seule fois.

Ensuite transformez cela en entrées constructibles :

• 6 à 10 user stories (acheter, recevoir un billet, voir un billet, transférer, demander un remboursement, check-in)
• Une liste de champs de données nécessaires (Event, TicketType, Order, Ticket, Hold, Refund, Transfer)
• Écrans et stubs d'API générés à partir des règles et des stories

Transformez les règles en tests avant d'ajouter "plus de fonctionnalités"

Avant d'ajouter promos, plans de sièges ou emails sophistiqués, écrivez des tests simples qui prouvent les règles.

Test exemple : un événement de 200 places, deux personnes essaient d'acheter les 2 derniers billets en même temps. Le résultat doit être prédictible : une seule achat réussit, l'autre obtient un message clair.

Faites correspondre les tests aux politiques. Si les réservations expirent après 10 minutes, testez qu'une réservation impayée libère l'inventaire. Si les remboursements sont autorisés jusqu'à 24 heures avant l'événement, testez le cutoff selon le fuseau horaire et l'heure de début de l'événement.

Exécutez un pilote conçu pour tout casser : une personne ouvre le checkout sur deux appareils, un transfert arrive après une demande de remboursement, un billet est scanné sans signal, et un acheteur tente de réutiliser une capture d'écran. Gardez-le petit, mais réaliste.

Pièges courants qui font rapidement échouer les apps de billetterie

La plupart des échecs ne sont pas des problèmes de design. Ce sont des problèmes de règles, surtout quand on saute les cas limites.

L'écart "paiement en attente"

L'erreur courante est de considérer un billet comme vendu au moment où quelqu'un clique sur Acheter, ou seulement après le règlement, sans phase intermédiaire. Si vous réservez trop tôt et ne libérez jamais, l'inventaire se bloque. Si vous réservez trop tard, deux personnes peuvent payer pour le dernier siège.

Un ensemble de règles simple aide : créez une courte réservation au début du checkout, prolongez-la uniquement pendant que le prestataire de paiement traite activement, libérez-la automatiquement au timeout, et convertissez la réservation en Vendu seulement après un événement de paiement confirmé.

Remboursements, transferts et doublons

Les remboursements deviennent compliqués si vous ne tracez pas nettement le lien avec le check-in. Si le personnel peut scanner un code puis plus tard l'acheteur se fait rembourser, vous invitez les litiges.

Les transferts cassent plus vite si votre logique « copie » un billet au nouveau propriétaire sans invalider l'ancien. Cela crée deux QR qui semblent valides.

Règles efficaces :

• Les remboursements s'arrêtent au premier enregistrement (ou vous définissez une exception claire)
• Un transfert invalide immédiatement le billet précédent
• Chaque billet a un propriétaire courant et un statut courant

Caché mais fatal : pas de piste d'audit

Quand quelque chose tourne mal, le support a besoin de faits. Si vous ne logguez pas les événements clés, vous ne saurez pas si l'utilisateur a expiré, payé deux fois, ou transféré correctement.

Loggez les moments qui changent la réalité : réservation créée, réservation expirée, paiement confirmé, billet émis, billet invalidé, transfert complété, et check-in accepté ou rejeté.

Ne faites pas confiance à l'UI pour appliquer les règles

Si vos règles vivent uniquement dans l'état des boutons et des écrans, les utilisateurs les contournent avec des rafraîchissements, onglets multiples ou appels API directs. Placez les règles côté serveur : vérifications d'inventaire, contrôles de propriété, et enforcement "un scan par billet".

Checklist rapide et étapes suivantes avant de commencer à coder

Si vous pouvez répondre aux points ci-dessous en termes simples, votre MVP a beaucoup moins de risques de craquer sous une vraie charge :

• Source de vérité d'inventaire : un endroit qui décide de ce qui est disponible
• Protection contre la survente : réservations, timeouts, et règle claire pour les collisions sur le dernier billet
• Règles de remboursement : fenêtres, frais, et que se passe-t-il quand l'événement change
• Règles de transfert : cutoff, limites, et invalidation immédiate des anciens billets
• Intégrité du check-in : un scan par billet, même en cas de mauvaise réception

Si quelque chose reste flou, écrivez 2 à 3 exemples concrets. Par exemple : « Si un acheteur commence le checkout à 18:00, il a jusqu'à 18:10 pour payer. S'il ne paye pas, le billet retourne immédiatement à l'inventaire. » Ce niveau de détail évite les bugs en production.

Si vous avez déjà un prototype généré par IA qui est désordonné ou peu fiable, un audit de code peut vous aider à trouver les points précis où la survente, la propriété du billet dupliquée, ou les conflits de check-in peuvent se produire. FixMyMess (fixmymess.ai) est spécialisé dans le diagnostic et la réparation des bases de code générées par IA pour qu'elles se comportent correctement sous trafic réel, notamment autour de l'inventaire, des paiements et de la sécurité.