Buzzik

Trois écrans, un seul état

Buzzik fait cohabiter trois interfaces sur une même partie : le téléphone de chaque équipe, qui sert de buzzer ; un écran commun qui diffuse le classement et les réponses ; et la console de l’animateur qui orchestre le déroulé. Le problème n’est donc pas d’afficher une partie, mais de garantir que ces trois points de vue racontent exactement la même chose, à la même seconde.

Concevoir pour un réseau qui lâche

C’est la contrainte qui a dicté l’architecture. Plutôt que de faire vivre la partie dans la mémoire des navigateurs, je l’ai modélisée comme une machine à états persistée en base, propagée par Supabase Realtime. L’état de référence n’est jamais dans un onglet : il est en base, et les écrans s’y raccrochent.

Trois décisions découlent de ce choix :

• Un polling de secours double la diffusion temps réel. Quand la connexion persistante tombe, la partie continue au lieu de se figer ;
• Le chronomètre dérive d’un horodatage serveur, pas de l’horloge locale. Deux téléphones désynchronisés voient le même temps restant, et un buzz reste comparable à un autre ;
• Une reconnexion reprend la partie telle qu’elle est. Un joueur qui perd le réseau puis revient retrouve la question en cours, pas un écran vide.

Un score qu’on peut recalculer sans le fausser

Le moteur de score est idempotent par construction  : il n’incrémente pas un compteur, il recalcule intégralement le classement à partir des réponses enregistrées. La différence est invisible tant que tout va bien, et décisive dès qu’un message arrive en double ou hors séquence, ce qui est la règle plutôt que l’exception sur un réseau instable. Un même événement traité deux fois donne le même classement.

Le bon extrait, la bonne année

La bibliothèque musicale est alimentée par un pipeline d’enrichissement qui croise plusieurs sources — iTunes, MusicBrainz et AcoustID — et arbitre entre elles. Le cas qui pose problème dans un blind test est l’année de sortie : les rééditions et compilations font remonter des dates qui n’ont rien à voir avec la parution d’origine. Le pipeline les écarte, pour qu’une question sur une chanson des années 80 ne se retrouve pas datée de 2014.

Ce que ce projet démontre

Buzzik est un produit personnel, pas une commande client. Il figure ici parce qu’il répond à une famille de problèmes que les sites vitrines ne posent jamais : plusieurs utilisateurs simultanés, un état partagé qui doit rester cohérent, et un environnement d’exécution sur lequel on n’a aucune prise.

Aucun chiffre d’usage ni de fréquentation n’est revendiqué : le produit est présenté pour sa conception.

Stack

Next.js 16, React 19, TypeScript, Supabase et Vercel, distribué en PWA installable.