BetNawak : paris virtuels entre amis
BetNawak est une application web mobile à installer hors des boutiques d’applications, pour organiser des paris virtuels entre amis avec des points sans valeur réelle, dans des équipes fermées sur invitation.
État : en cours de développement. La spécification est rédigée ; aucun code applicatif n’est encore livré.
Contexte et besoin
Le projet part d’un cahier des charges : permettre à un groupe d’amis de se lancer des défis sous forme de paris, sans enjeu financier. Les points sont une unité interne sans valeur réelle et non convertible.
Chaque équipe est fermée : on y entre uniquement sur invitation par e-mail. Dans la première version, une équipe a un seul administrateur, qui la paramètre, invite, modère et tranche les litiges.
Modèle d’accès : accès au service par abonnement annuel, souscrit par l’administrateur ; les joueurs ne paient jamais. Deux paliers sont prévus (Starter : jusqu’à 3 équipes administrées ; Pro : équipes illimitées, statistiques avancées et export des données de l’équipe), avec des tarifs communiqués à l’ouverture. Les points virtuels n’ont aucune valeur, ne se convertissent pas et aucun gain monétaire n’existe ; aucun tarif ne dépend du nombre de points.
Fonctionnement prévu
- Application web progressive pensée d’abord pour le mobile, installable sans passer par les boutiques d’applications.
- Équipes, invitations à usage unique, rôles administrateur et membre.
- Un grand livre des points de l’équipe, visible de ses membres, dans lequel aucun point n’est créé ni détruit.
- Résolution d’un pari, signalement, contestation avec retour à l’état précédent et journal d’audit.
- Échanges en temps réel et conversation d’équipe.
Choix techniques prévus
- Stack : TypeScript, Next.js 16, Tailwind CSS 4, Drizzle, PostgreSQL, Redis et un service temps réel, orchestrés par Docker Compose derrière le proxy commun aux applications.
- Domaine pur d’abord : les règles de calcul des points, la répartition lorsqu’un membre quitte l’équipe et les états d’un pari sont écrits et testés par invariants avant l’interface.
- Authentification sans bibliothèque : mots de passe hachés avec Argon2id natif de Node 24 (environ 25 ms mesurés), jetons hachés, réponses uniformes, protection contre les essais répétés, tests inspirés de la norme ASVS ; un repli documenté existe, et une relecture externe de l’authentification est prévue.
- Isolation entre équipes vérifiée par des tests croisés, RGPD (hébergement dans l’Union européenne, export et suppression des données, gel de 30 jours puis purge en cas d’inactivité) et avis juridique prévu.
- Qualité : commits normalisés, détection de secrets, contrôles en local.
Difficultés et enseignements
- Trancher avant de coder : la première version de la spécification comptait 18 points ouverts, tous tranchés et consignés dans un journal de décisions ; neuf nouveaux points, nés de ces décisions, restent à régler.
- Les cas limites d’abord : départ d’un membre en cours de partie, contestation d’un résultat, litige sans décision, remise à l’état précédent. Ces cas sont spécifiés avant le premier écran.
- Un ordre de travail voulu : le domaine pur et le grand livre avant l’interface, parce que c’est là que les erreurs sont les plus coûteuses.
- Un choix assumé : écrire soi-même l’authentification est plus exigeant que d’utiliser une bibliothèque ; la spécification prévoit donc un repli et une relecture externe.
État d’avancement honnête
À ce jour : dépôt initialisé avec son outillage (hooks de commit, commits normalisés), cahier des charges, spécification v1.1 rédigée et plan en dix jalons. Le premier jalon (socle de l’application) est en cours ; le domaine pur, les comptes, le grand livre, le temps réel, la PWA et le reste restent à faire.
Il n’y a donc ni démonstration ni lien : cette page présente une conception, pas un produit livré.
Ce que ça montre de mon travail
- Cadrer un projet avant de coder : cahier des charges, spécification découpée, décisions tracées.
- Raisonner par invariants et par cas limites sur une logique de calcul.
- Choisir ce qui doit être écrit à la main (authentification) et ce qui doit rester simple, en documentant le repli.
- Travailler par jalons, avec un état d’avancement honnête.
Un projet à cadrer ?
Décrivez votre idée : je vous aide à la transformer en besoin précis, puis en application.