Une plateforme de réservation de terrains de sport, construite pour ma certification de product builder no-code et IA. Un joueur choisit un créneau, indique combien ils seront, et le prix du terrain se divise entre eux : celui qui réserve décide combien de parts il règle tout de suite. Une fois le paiement passé, le créneau disparaît du catalogue pour les autres visiteurs.
Le travail s'est mené en deux temps : d'abord le pilotage des compétitions côté organisateur, ensuite l'application de réservation côté joueur.
Projet de certification, pas une réalisation client : les terrains, les clubs et les coordonnées visibles sur ces écrans sont des données de démonstration.
Réserver un terrain à plusieurs pose toujours le même problème d'argent : la plateforme encaisse la totalité auprès d'une seule personne, qui passe la semaine à réclamer sa part à chacun. Le paiement n'est pas le sujet du sport, mais c'est lui qui laisse un souvenir.
La question posée au projet était donc simple à énoncer et moins simple à construire : faire porter le partage par la plateforme elle-même, au moment de la réservation, pour que personne n'ait à payer à la place des autres.
Le prix du terrain se divise entre les joueurs prévus, et celui qui réserve choisit combien de parts il règle tout de suite. La sienne seulement, ou celles des joueurs qui ne sont pas encore inscrits.
Une fois la réservation payée, le créneau disparaît du catalogue : le visiteur suivant voit un terrain de moins, et réserve donc autre chose. Le gérant garde un planning à jour sans y toucher, et le terrain reste à une seule équipe à la fois.
C'est exactement la mécanique qui, chez un commerçant, tient un stock juste sans que personne y touche : une vente retire l'article des disponibles, et la page suivante affiche l'état réel plutôt qu'un état recopié la veille.
La certification s'est déroulée en deux projets successifs sur le même produit. Le premier a monté le pilotage, côté organisateur. Le second a construit l'application, côté joueur.
Le même produit, monté deux fois et de deux façons : c'est exactement l'arbitrage qui se pose au cadrage d'un projet client. Sortir les données de l'application donne des vues de pilotage en quelques minutes, au prix d'un compte de plus à tenir, d'une facture de plus et d'un endroit de plus où quelque chose peut se casser. Les garder dedans donne une application d'un seul tenant, au prix d'un tableau de bord à construire à la main. Le bon choix dépend de qui doit lire quoi, et à quelle fréquence : c'est la question que je pose au départ, et la réponse se justifie devant vous.
Une disponibilité à tenir, un paiement à répartir, un document à produire. Dites-moi lequel vous coûte le plus de temps.
