Casa des Buzzer Un buzzer de quiz équitable à la milliseconde.
Un buzzer de quiz qui tourne sur de simples téléphones : un téléphone arbitre, sans compte et sans serveur de jeu. Projet personnel, conçu et piloté seul en 72 heures.
Fiche du projet
- Client
- Projet personnel
- Rôle
- Product Designer · Direction artistique · Pilotage technique
- Équipe
- Conçue et pilotée seul, de bout en bout, avec Claude Code pour le développement
- Périmètre
- Cadrage · règles d’équité · design · direction artistique · pilotage du développement · tests sur appareils
- Période
- Octobre 2026
- Durée
- 72 heures.
- Support
- Application web installable (PWA), temps réel multi-appareils : un téléphone anime, les autres jouent, un écran central affiche
- Statut
- Terminée : tests concluants, sans bug. Projet privé pour l’instant.
Impact
Contexte
Des soirées blindtest et quiz entre amis : un arbitre, mais parfois des contestations et de la mauvaise foi. Ces débats m’ont donné envie de créer une app de buzzer simple, que tout le monde pourrait utiliser, et surtout un écran central pour l’animation.
Les buzzers physiques coûtent cher et se transportent mal ; les applications existantes demandent souvent un compte, un serveur ou une installation. Je voulais quelque chose d’immédiat : on scanne un QR code, on joue.
Le projet est aussi une expérience de méthode : comment piloter un assistant IA (Claude Code) pour livrer un produit propre, et pas seulement du code qui marche.
Problème
Sur un réseau wifi, deux appuis à quelques millisecondes d’écart arrivent dans le désordre. Le vrai défi n’est donc pas l’interface : c’est l’équité. Il faut un arbitre fiable, une horloge commune, et des règles claires pour les égalités.
Objectifs
- Aucun compte, aucune donnée personnelle : un pseudo et un animal, rien d’autre.
- Aucun serveur central pour le jeu : pas de coût qui grimpe avec les parties, pas de données à protéger.
- iPhone et Android, sans installation obligatoire.
- Réactivité avant tout : les animations ne gênent jamais l’appui.
- Un design vivant, pas un énième écran générique d’application.
Démarche et enseignements
Poser les règles d’équité avant le design. Puis choisir chaque effet en l’essayant : une démonstration jouable et jetable compare deux ou trois variantes (un décompte ou un éclair au départ de manche, trois mises en scène de fin de partie…), et je tranche en jouant. Une fonctionnalité, une pull request, relue, testée, puis validée sur de vrais appareils.
Solution
Un téléphone sert de serveur et d’arbitre : le moteur de jeu tourne dans le navigateur de l’animateur. Les autres appareils lui envoient des intentions (« j’ai buzzé ») et reçoivent des événements (« Léa a la main »). Une seule source de vérité : l’ordre des buzz et les scores ne peuvent pas diverger.
Les appareils se parlent en direct (WebRTC). Un relais minuscule ne sert qu’à la mise en relation : il ne voit jamais de pseudos, de buzz ni de scores. Aucune adresse IP n’est exposée, et il n’y a ni compte ni service tiers.
Un arbitre, une horloge, des règles claires
Chaque joueur est pingué chaque seconde et l’heure de son buzz est corrigée d’une demi-latence, plafonnée à 50 ms. Un buzz reste admis 150 ms après le premier arrivé. Sous un écart réglable (15 ms par défaut), deux équipes différentes sont à égalité : l’animateur tranche, avec un écran de duel « VS ».
Un téléphone comme serveur
Le moteur de jeu vit dans le navigateur de l’animateur. Les joueurs et l’écran central se connectent en direct ; un relais minuscule fait seulement la mise en relation, sans jamais voir de données de jeu.
Une direction artistique « Pop »
Fond indigo, contours épais et sombres, gros boutons 3D en relief, avatars d’animaux. Le buzzer est un énorme bouton jaune qui s’enfonce quand on l’appuie. Le rouge est réservé à la connexion perdue ; les équipes sont des tuiles colorées.
Principes de conception
Le buzzer s’ouvre sur l’annonce de l’animateur, pas à la fin de l’animation locale : une animation lente ne peut désavantager personne. Sur les téléphones, aucune animation ne s’exécute pendant que le buzzer est actif.
On ne reste jamais bloqué : un joueur qui perd le wifi retrouve exactement sa place (même score, même équipe) grâce à un jeton de session, et chaque alerte offre une sortie vers l’accueil.
La vie privée est un principe de conception, pas une option : pas de compte, pas d’adresse IP exposée, pas de script ni de police tiers.
Fonctionnalités clés
Une manche
- L’animateur ouvre la manche ; tous les téléphones jouent un départ synchronisé de 0,9 s, pendant lequel les buzz sont ignorés.
- Le premier à buzzer prend la main. L’animateur valide ou refuse la réponse.
- Après une erreur, la manche se rouvre aux autres joueurs, ou se clôt sans point, ou retire des points.
Les réglages
- Un joueur qui s’est trompé peut rebuzzer ou non ; s’il ne reste qu’un joueur, il reçoit la main directement.
- Temps pour buzzer (aucun, 10, 20, 30 ou 60 s) et temps pour répondre (aucun, 5, 10 ou 20 s), avec pause et « +5 s » équitable.
- Égalité : jamais, 15, 30, 60 ou 100 ms.
La fin de partie
- Remise des trophées sur l’écran central : le plus souvent premier au buzz, le meilleur taux de bonnes réponses, la plus longue série.
- Chaque téléphone joue une animation différente selon le rang, avec un mot bienveillant pour le dernier.
- Tout reste lisible en version fixe si l’appareil demande de réduire les animations.
Les dés rebondissent sur le bitume en 2e édition, et se matérialisent en fil de fer phosphore dans Invader.
Résultats
Un buzzer équitable jusqu’à la milliseconde, qui s’ouvre avec un QR code. Il gère 2 à 8 joueurs, des équipes, un temps pour buzzer et pour répondre, la reprise après coupure de wifi, et une vraie fin de partie avec remise de trophées.
Le projet compte 885 tests automatisés et 56 pull requests relues. Une coupure de wifi est détectée en 3,4 secondes, contre 8 à 10 secondes au départ.
Réflexions
- La contrainte d’équité structure tout le reste. Une fois la règle « le buzzer s’ouvre sur l’annonce de l’animateur » posée, les animations peuvent être aussi riches qu’on veut : elles n’influencent plus le résultat.
- Les démos battent les descriptions. Choisir un effet en l’essayant a évité des allers-retours, et m’a laissé la main sur chaque décision produit.
- Un essai réel vaut cent tests. Couper le wifi d’un téléphone a révélé trois manques que la suite de tests ne voyait pas : pas de retour possible, détection trop lente, alerte invisible. Les trois sont devenues des fonctionnalités.
Et ensuite
Le projet reste privé : mon relais Cloudflare ne peut pas accueillir beaucoup de connexions. Si la demande est présente, je pourrais en faire une version publique. Le jeu hors du même wifi a été construit, puis abandonné : il demandait un service payant, contraire à ma contrainte de départ.