Projet mis en avant

LeBooster

Ouverture de boosters Pokémon en ligne, tirage vérifiable

Plateforme co-fondée où l'on ouvre en ligne des boosters de vraies cartes Pokémon en état Near Mint, cote Cardmarket affichée. Chaque tirage est provably fair : le résultat est fixé avant l'animation, et n'importe qui peut le recalculer dans son navigateur. Le joueur garde ses cartes ou les revend en CardCoins, et ne fait livrer que celles qu'il veut vraiment. En ligne depuis septembre 2026, avec des ventes.

#Next.js#React#TypeScript#TailwindCSS#PixiJS#NestJS#PostgreSQL#Redis#Temporal#Stripe#Playwright#Docker
LeBooster, capture du jeu
Rôle & moteur
Co-fondateur & Développeur Full-Stack
Next.js 16 · PixiJS 8 · NestJS · PostgreSQL
Équipe
2 personnes
Deux co-fondateurs : je porte le front, la scène d'ouverture, le tirage vérifiable et le contenu ; mon associé porte l'essentiel du backend, des commandes et de la logistique
Période & studio
2026 - Présent
LeBooster
Plateforme
Web (desktop et mobile)

Le défi

Ouvrir un booster, c'est un frisson qui tient en quelques secondes : la déchirure, la carte retournée, la rare qui sort. Le recréer en ligne demande que l'ouverture soit aussi soignée qu'un moment de jeu vidéo, sur un téléphone comme sur un ordinateur.

Mais un tirage en ligne n'inspire confiance que s'il se prouve. Sur ce marché, la promesse « c'est aléatoire » ne suffit pas : il fallait que le joueur puisse vérifier lui-même que sa carte n'a pas été choisie après son clic.

Le modèle ajoute sa propre contrainte : aucun stock. Un booster est un pack défini par des règles (extensions, cartes éligibles, chances par valeur), et une carte n'est achetée sur Cardmarket que si le joueur demande sa livraison. Le produit, l'économie et la technique devaient donc être pensés ensemble, à deux.

Concept du projet

  • Ouverture en ligne de boosters de vraies cartes Pokémon Near Mint
  • Tirage provably fair, recalculable par le joueur dans son navigateur
  • Aucun stock : la carte n'est achetée que si le joueur la fait livrer
  • Co-fondé à deux en janvier 2026, en ligne depuis septembre 2026

Mon rôle & mes responsabilités

Co-fondation & produit
  • Modèle sans stock : le booster est un ensemble de règles, la carte n'est commandée qu'à la livraison
  • Économie des CardCoins : achat via Stripe, revente instantanée d'une carte à une part de sa cote, chances publiées par palier de valeur
  • Pricing, go-to-market et contenus pour les réseaux sociaux
  • Engagement des joueurs : skins saisonniers du site avec chasse aux œufs récompensée, classement des collections par saison, alertes Discord sur les grosses cartes
Scène d'ouverture
  • Conception et développement de toute la séquence : vol du pack, déchirure, retournement, halos et éclat de rareté
  • Migration de la scène vers PixiJS 8 : ciel, pack, carte en main et effets dessinés sur un seul canvas WebGL
  • Effets de révélation paramétrables, avec des shaders écrits et prévisualisés directement dans l'admin, puis assignés à un rang de carte
  • Geste de tri au glisser (à droite on garde, à gauche on revend), avec boutons et flèches du clavier en alternative, et une démo jouable sans compte
Tirage vérifiable
  • Bibliothèque provably fair isomorphe, partagée entre le serveur et le navigateur : la vérification calcule exactement ce que le tirage a calculé
  • Schéma commit-reveal : le serveur publie l'empreinte de sa graine avant l'ouverture, le tirage combine sa graine, celle du joueur et un compteur
  • Tests à vecteurs connus, pour qu'une évolution du code ne puisse pas changer silencieusement un résultat
  • Page publique de vérification, où le calcul se fait entièrement dans le navigateur
SEO & contenu
  • Une trentaine de guides Pokémon (cotes, raretés, extensions), d'abord en MDX puis servis depuis la base avec un éditeur visuel dans l'admin
  • Données structurées JSON-LD, sitemap daté à la dernière correction, maillage interne entre guides et boosters
  • Pages boosters publiques en ISR plutôt qu'en rendu à chaque requête, images de cartes servies depuis un miroir local
  • Score SEO de 100 sur Lighthouse mobile

Ce qui a changé en cours de route

Première version

Une scène d'ouverture assemblée en composants DOM animés

Version retenue

Une seule scène PixiJS 8 qui dessine le ciel, le pack, la carte et les effets

Pourquoi : Empiler des couches DOM animées multipliait le travail du navigateur à chaque image, et un effet de révélation ne pouvait pas être un vrai shader. En sortant d'abord les données de la scène des composants, chaque élément a pu passer sur le canvas un par un, sans casser l'ouverture en production.

Première version

Des guides écrits en fichiers MDX, publiés avec le code

Version retenue

Des guides en base, avec un éditeur visuel et une purge du cache à la publication

Pourquoi : Corriger une cote ou une faute demandait un déploiement. En base, le contenu vit à son propre rythme, et le sitemap peut enfin dater la dernière correction plutôt que la parution.

Galerie d'images

Révélation d'une carte ultra rare dans la scène d'ouverture PixiJS (mode démo)
Le pack présenté avant l'ouverture, sous le skin d'Halloween du site
Accueil : boosters à la une et booster offert chaque jour
Fiche d'un booster : prix en CardCoins et chances publiées par palier de valeur
Vérification d'un tirage, recalculé entièrement dans le navigateur
Rapport d'équité mensuel : chances annoncées et chances observées, palier par palier
Guides Pokémon : cotes, raretés et extensions
Fin d'ouverture : meilleures cartes et cartes gardées

Résultats

  • En ligne depuis septembre 2026, avec des ventes
  • Chaque ouverture est vérifiable par le joueur, et un rapport d'équité mensuel compare les chances annoncées aux tirages observés
  • Une démo d'ouverture jouable sans compte, pour découvrir la scène avant de payer
  • Une trentaine de guides indexés, éditables sans déploiement

Ce que j'en retiens

  • Dans un produit de tirage, la confiance est une fonctionnalité : la rendre vérifiable a autant pesé que de rendre l'ouverture belle
  • Une animation est un rendu en temps réel comme un autre : mon passé de développeur de jeux a plus servi sur la scène d'ouverture que n'importe quel composant d'interface
  • Co-fonder à deux oblige à découper clairement qui porte quoi, sans quoi chacun repasse derrière l'autre

Disponible pour un poste de Game Designer / Developer

Studio indé ou double A, profil polyvalent : design, code, réseau, audio, outillage.

bastienokonski@gmail.com