marathons caritatifs, en direct
Étude de cas Septembre 2026 · projet personnel · écrit pendant l'événement
Une régie multi-stream,
construite en direct.
Suivre le ZEvent, c'est jongler entre une cagnotte qui bouge toutes les dix secondes, une centaine de chaînes en direct et des paliers de dons qui tombent sans prévenir. J'ai construit l'outil qui manquait — pendant l'événement, en corrigeant au fil des usages réels.
Voir le tableau de bord en direct → Le détail des fonctionnalités
Le problème
Pendant un marathon caritatif, l'information est éclatée : le site officiel donne la cagnotte, Twitch donne les flux, les paliers de dons vivent dans des articles de presse, et le placement des streamers dans la salle est un plan griffonné publié sur X. Aucun outil ne réunit tout ça, et surtout aucun ne permet de regarder six chaînes en même temps sans faire fondre la machine.
Ce que ça fait
Un panneau qui classe les streamers par cagnotte avec l'avancement de leurs paliers, un espace où l'on ouvre autant de chaînes qu'on veut, des cartes de statistiques qui se rangent comme des fenêtres, un plan de la salle où chaque bureau porte la photo du streamer, et une télécommande pour piloter plusieurs PC depuis un iPad.
Cinq problèmes qui ont façonné le code
1. Une iframe qu'on déplace se recharge
Toute la mosaïque repose sur une règle : l'élément d'une fenêtre n'est jamais re-parenté. Changer de disposition, passer en grille, envoyer une fenêtre sur le second écran — tout passe par la position, la taille et l'ordre d'affichage, jamais par un déplacement dans le DOM, sous peine de couper le flux et de repartir sur cinq secondes de tampon.
2. Les lecteurs ne démarraient pas sous Windows
Symptôme : tout marchait sur macOS, rien ne démarrait sur un Chromium Windows. La cause n'est pas un bug mais une règle : l'activation utilisateur ne traverse pas les frontières de domaine. Un clic sur mon interface ne donne aucun droit au lecteur Twitch, qui vit dans une iframe d'un autre domaine. La réponse : détecter le blocage, basculer automatiquement sur les contrôles natifs de Twitch — le seul ▶ que le navigateur accepte — et proposer une relance groupée.
3. La télécommande saturait le salon
Chaque écran publiait son état, le serveur rediffusait, la rediffusion déclenchait une nouvelle publication : une trentaine de requêtes par seconde pour rien, et une télécommande poussive. Une boucle de rétroaction en trois lignes. Après suppression et garde de signature : une requête toutes les dix secondes, et l'interface répond au doigt grâce à un affichage optimiste qui n'attend pas l'aller-retour.
4. Cinq secondes d'écart entre deux PC
Image sur un PC, son sur l'autre : deux lecteurs Twitch ne sont jamais synchrones, chacun remplit son tampon, et rien dans l'API ne permet de les recaler. La seule vraie réponse était de ne lire le flux qu'une fois : la machine qui affiche capture le son de son onglet et l'envoie à l'autre en WebRTC, la signalisation passant par le salon de contrôle déjà en place — aucun serveur supplémentaire.
5. Un plan griffonné en image
Le placement des streamers n'existait que sous forme d'image manuscrite. J'ai relevé les 81 bureaux en coordonnées, rattaché chaque nom à un compte Twitch (avec les pièges : « JDG », « Seb du grenier », les duos), et converti le tout en pourcentages pour que le plan reste juste à n'importe quelle taille. Résultat : une carte zoomable où un clic ouvre le flux du bureau, agrandi depuis sa position.
L'architecture, en une phrase
Un serveur Node sans aucune dépendance qui interroge l'API amont toutes les douze secondes et pousse le résultat en SSE, un front en modules ES natifs sans build ni framework, un état répliqué entre onglets par BroadcastChannel et entre machines par des salons éphémères, et le lecteur Twitch piloté par son API JavaScript pour imposer 480p à l'ouverture.
Piloter plusieurs machines depuis un iPad
Un code de six caractères, dictable à voix haute, suffit à relier des PC qui ne se connaissent pas. La télécommande affiche une touche par flux, six commandes par touche — toutes en un seul appui — et tient sur un écran sans jamais défiler : la grille calcule le nombre de colonnes qui donne les plus grandes touches, et la dernière s'étale sur la place restante.
Ce que j'en retire
- Les contraintes des navigateurs — autoplay, cookies tiers, activation utilisateur — décident de l'architecture bien plus que les goûts techniques.
- Un projet utilisé pendant qu'on l'écrit ne laisse aucune place aux fonctions décoratives : chaque ajout venait d'un manque constaté en direct.
- Zéro dépendance, ce n'est pas un défi de style : c'est ce qui permet de déployer en trente secondes, à trois heures du matin, sans rien casser.
- Dire honnêtement ce qui ne marche pas — les drops, le rendu audio inexistant chez Twitch — vaut mieux que promettre l'impossible.