BingoLive.online : comment un projet ludique est devenu un laboratoire technique

L’origine du projet

J’ai créé BingoLive à une période où les jeux de casino en ligne avaient le vent en poupe en France, notamment avec l’explosion des lives Twitch et l’augmentation du nombre de joueurs.

Mon idée était de créer une solution qui, bien qu’imparfaite, puisse offrir une alternative gratuite aux personnes qui souhaitaient retrouver certaines mécaniques de jeu sans miser d’argent réel.

Le service ne devait jamais demander de dépôt, vendre des crédits ou proposer des gains convertibles. L’objectif était uniquement de conserver le côté ludique du tirage, des cartons et du direct.

Je savais néanmoins qu’une telle solution ne pouvait pas être présentée comme une méthode de sevrage. Un jeu gratuit ne remplace pas un accompagnement spécialisé lorsqu’une personne rencontre une véritable addiction.

Mes objectifs techniques

Lorsque j’ai démarré ce projet, je voulais principalement apprendre le JavaScript à un niveau plus avancé et comprendre le fonctionnement des plateformes de streaming.

Les streamers de l’époque diffusaient principalement leur contenu sur Twitch. Pour être cohérent avec les usages du public ciblé, je voulais donc diffuser le tirage sur la même plateforme.

Le projet dépassait rapidement la création d’un simple site front. Il fallait construire plusieurs briques capables de fonctionner ensemble.

L’architecture initiale

La première version de BingoLive reposait sur une architecture composée de plusieurs briques distinctes.

Le front affichait les cartons, le dernier numéro tiré, l’historique de la partie et le tchat. Les API fournissaient au client l’état courant du tirage, tandis qu’un orchestrateur exécuté côté serveur s’occupait de lancer les parties, de gérer les timers et de tirer les numéros.

Le serveur restait la source de vérité. Le client ne décidait jamais lui-même du résultat d’un tirage. Il récupérait les informations depuis les API et mettait à jour son affichage.

Cette séparation était importante pour éviter que chaque navigateur génère sa propre version de la partie et pour garantir que tous les utilisateurs disposent du même état.

La diffusion Twitch

Pour le live Twitch, un Raspberry Pi affichait le moteur de tirage en plein écran. Le flux était ensuite encodé en H.264 et envoyé vers Twitch au travers de la chaîne de streaming.

Roger Chaudet, de Spatiograph , a réalisé l’UI/UX ainsi que les assets graphiques des boules utilisées pendant le tirage. Son travail a donné au projet une véritable identité visuelle.

Twitch apportait la partie visuelle et communautaire, mais la plateforme introduisait naturellement de la latence. Il n’était donc pas possible de considérer la vidéo comme la référence technique de la partie.

La synchronisation temps réel

L’un des aspects les plus intéressants du projet concernait la synchronisation entre le moteur de tirage, le live Twitch et les navigateurs des utilisateurs.

À chaque nouveau numéro, l’orchestrateur mettait à jour l’état de la partie. Les clients récupéraient cette information au travers des API et affichaient immédiatement le dernier numéro tiré.

Cette aide visuelle était indispensable, car le live Twitch pouvait arriver avec plusieurs secondes de décalage. Le joueur pouvait donc continuer à suivre correctement ses cartons, même si la vidéo n’était pas parfaitement synchronisée.

Ce projet m’a permis de travailler sur plusieurs problématiques typiques des systèmes distribués :

• gestion de l’état courant ;
• ordre des événements ;
• reconnexion d’un client en cours de partie ;
• récupération de l’historique du tirage ;
• gestion de la latence ;
• cohérence entre plusieurs clients connectés.

La génération des cartons

La génération des cartons demandait également un véritable algorithme. Je ne voulais pas simplement placer des nombres aléatoires dans une grille.

Les cartons devaient respecter la disposition réelle du loto : répartition des nombres par colonnes, nombre défini de cases remplies par ligne et absence de doublons incohérents.

Les utilisateurs pouvaient recevoir plusieurs cartons pendant une partie. Le système devait donc :

• générer des cartons valides ;
• les rattacher au bon utilisateur ;
• conserver leur état pendant toute la partie ;
• vérifier automatiquement les numéros présents ;
• détecter les combinaisons gagnantes.

L’ensemble reposait sur un jeu d’API entre le front, le back et l’orchestrateur.

Connexion, tchat et localisation

Le public ciblé comprenait notamment des personnes peu à l’aise avec l’informatique. J’avais donc intégré une connexion simplifiée via Facebook afin d’éviter la création d’un nouveau compte avec un mot de passe supplémentaire à mémoriser.

Le tchat était également une brique importante. Le bingo est un jeu social : sans interaction entre les joueurs, l’expérience aurait rapidement ressemblé à un simple générateur de nombres.

J’ai aussi mis en place un système de détection du pays et de traduction de l’interface. Pour que le système soit cohérent, il fallait également localiser le tchat, soit en séparant les salons par langue, soit en appliquant une logique de traduction adaptée.

Cette partie m’a permis de travailler sur l’internationalisation, la détection de locale, les contenus traduits et les limites de la géolocalisation automatique.

Montée en charge et load balancing

Au plus haut de son activité, BingoLive a attiré environ 1 300 utilisateurs. Ce chiffre ne correspond pas nécessairement à 1 300 connexions simultanées, mais il a suffi à faire apparaître les limites de l’architecture initiale.

J’ai dû travailler sur la répartition de charge côté serveur, la supervision des services et la suppression de plusieurs points uniques de défaillance.

Ce projet a été l’une de mes premières expériences concrètes autour du load balancing appliqué à une application utilisée en temps réel.

Les données récupérées via Google Analytics montraient également une part importante d’utilisateurs mobiles. J’ai donc revu l’IHM pour la rendre réellement responsive et permettre l’utilisation des cartons depuis un smartphone.

VPS, réseau local et OpenVPN

L’architecture de BingoLive était hybride.

Le front, les API et l’orchestrateur étaient hébergés sur mon VPS Ionos. La partie streaming, avec le Raspberry Pi et l’encodage H.264, fonctionnait sur mon réseau local.

Il fallait donc maintenir une connexion permanente entre ces deux infrastructures. Je ne souhaitais pas ouvrir plusieurs ports sur mon réseau local ni exposer directement les services internes sur Internet.

J’ai mis en place un serveur OpenVPN afin de créer un tunnel permanent entre mon infrastructure locale et le VPS. Les différents composants pouvaient ainsi communiquer au travers d’un réseau privé commun.

Ce choix m’a permis de travailler concrètement sur :

• les routes réseau ;
• les tunnels VPN persistants ;
• la communication entre un VPS et un LAN ;
• la reconnexion après une coupure ;
• la limitation de la surface d’exposition publique.

Une architecture devenue trop complexe

D’un simple projet ludique destiné à apprendre JavaScript, j’étais arrivé à une architecture composée d’un front, d’un back, d’API, d’un orchestrateur, d’un VPN, d’un Raspberry Pi, d’une chaîne d’encodage H.264 et d’une diffusion Twitch.

Le système fonctionnait, mais il demandait un certain niveau de maintenance à chaque démarrage et en cas d’incident.

J’ai laissé cette architecture fonctionner pendant environ six mois avant de devoir réaffecter les Raspberry Pi à d’autres projets.

Remettre ensuite toute l’infrastructure en route uniquement pour BingoLive me demandait trop de temps. Le projet est donc resté en sommeil pendant un moment.

La relance grâce au vibe coding

Grâce au vibe coding, j’ai finalement trouvé le temps de reprendre le projet et de moderniser son architecture.

Le premier changement important a été l’arrêt de la diffusion via Twitch. L’écran qui était auparavant affiché sur le Raspberry Pi et envoyé vers la plateforme est désormais rendu directement dans le navigateur des clients.

J’en ai également profité pour ajouter plusieurs mini-jeux, notamment une version gratuite du blackjack, un pachinko et une roue inspirée des jeux de casino.

Ces jeux fonctionnent uniquement avec des points virtuels gratuits. Ils ne permettent aucun dépôt, aucun retrait et aucun gain ayant une valeur marchande.

Les limites du projet

BingoLive peut constituer une alternative gratuite pour les personnes qui souhaitent retrouver certaines mécaniques de jeu sans risquer de perdre de l’argent.

Il ne faut cependant pas présenter ce type de service comme une solution médicale ou une méthode de sevrage. Les tirages aléatoires, les animations et les points peuvent continuer à reproduire certaines sensations associées aux jeux d’argent.