Faire tournerun jeu en ligne,seul.

Le jeu en deux phrases

Chaque carte est un vrai morceau de musique, avec sa pochette, un extrait de 30 secondes et une rareté de Commune à Légendaire. On fouille des bacs comme chez un disquaire, on complète des albums, on échange, et on affronte ses amis en blind test. Un catalogue d'environ 18 000 titres, alimenté automatiquement chaque semaine, en français et en anglais.

Mon objectif personnel : faire découvrir la musique et d'autres cultures. Chaque semaine, le jeu met en avant trois albums, deux classiques et une découverte, chacun avec son histoire.

Premières lignes de code le 25 septembre 2026, version 1.0 en ligne sur setlist.gg le 11 octobre, 16 jours plus tard. Depuis, une mise en production par semaine, le mercredi à 2 h du matin.

Mon rôle : donner les pistes

J'ai tenu tous les rôles d'un petit studio : game designer, architecte, ops et support.

J'ai écrit le code avec un assistant IA (Claude Code), et je le dis ouvertement. Ce que l'IA ne fait pas à ma place, c'est décider : ce que le jeu doit être, ce qui est juste pour les joueurs, ce qui part en production et quand. Chaque fonctionnalité part d'une intention que je formule, et chaque mise en prod passe par mon accord.

J'ai aussi mis en place une revue systématique : un second agent relit chaque lot de changements avant la mise en production, côté sécurité, performance et régressions. Sur la dernière version, quatre passes de revue ont produit quatorze correctifs, tous intégrés avant la livraison. Quatre failles réelles ont été stoppées avant la production, dont une création de compte sans adresse confirmée via OAuth et une amplification de charge par le signal « en train d'écrire ». Aucune n'a atteint les joueurs.

Ce que j'ai appris en game design

Je n'avais jamais fait de jeu. Les vraies questions n'étaient pas techniques :

• L'économie. Les joueurs gagnent des « notes » et les dépensent en fouilles. Une récompense trop généreuse dévalue tout le reste. Avant chaque nouveau bonus, je regarde les prix réels et le portefeuille médian des joueurs.
• La rareté. Elle ne vient pas d'un tirage arbitraire : elle suit la popularité durable de chaque titre (Deezer, Last.fm, Wikipédia, longévité). Une Légendaire est un morceau que tout le monde connaît depuis des décennies.
• La frustration. Un compteur de pitié garantit une Ultra Rare au bout de 30 fouilles sans en trouver. Assez pour éviter la frustration, pas assez pour rendre la rareté banale.
• La dopamine, dosée. Une Légendaire a sa célébration plein écran. Une Ultra Rare a un effet plus discret. Et ceux qui ne veulent pas d'animations peuvent les couper dans les réglages.
• Pas d'argent réel. Le mode premium, Backstage, se paie uniquement en notes du jeu. C'est un choix : l'API musicale que j'utilise n'est pas commerciale, et je ne veux pas d'un jeu « pay to win ».
• L'anti-abus. Parrainage, échanges, récompenses : chaque mécanique qui donne quelque chose a été pensée pour ne pas être farmée (comptes par réseau limités, récompenses versées une seule fois, actions sensibles réservées aux adresses e-mail confirmées).

L'architecture

Volontairement simple, parce qu'une seule personne doit pouvoir tout comprendre et tout réparer.

• Flux joueurs
• Données externes
• Sauvegarde et livraison (tunnel chiffré)
• Supervision et alertes

Supervision et alertes : Prometheus, Alertmanager, Discord.

Une API de jeu sur mesure

Toute la logique de Setlist passe par une API que j'ai conçue au-dessus de PocketBase : 119 routes, dont 97 réservées aux joueurs connectés. C'est elle qui garantit les règles du jeu, côté serveur, sans jamais faire confiance au client : tirage des cartes et compteur de pitié, blind tests et classement, échanges et marché aux enchères, groupes, messages en temps réel, récompenses et anti-abus.

Elle s'appuie sur six sources externes (Deezer pour le catalogue et les extraits, MusicBrainz, Last.fm, Wikidata et Genius pour l'année, la popularité et les crédits des titres, Discord pour la communauté), avec des files d'attente et des quotas pour respecter leurs limites.

Elle sert aussi des pages publiques pour le référencement (fiches de cartes et d'artistes, plans de site), et expose ses propres métriques à Prometheus, sur un point d'accès réservé au réseau privé ou protégé par jeton. Une limitation de débit par adresse IP protège l'ensemble. Côté chiffres : 68 ms de latence médiane sur les actions de jeu, 271 ms au 95e percentile, mesurés par Traefik sur les 49 premières heures.

Les choix et leurs compromis

SQLite plutôt que PostgreSQL

Une seule machine, un seul fichier, des sauvegardes simples, des requêtes très rapides à cette échelle. Le compromis : pas de mise à l'échelle horizontale. Si le jeu grossissait vraiment, ce serait le premier chantier.

Docker Swarm plutôt que Kubernetes

Swarm fait ce dont j'ai besoin (déploiements progressifs, retour arrière automatique, secrets, réseaux) sans la charge d'exploitation de Kubernetes. Pour un service sur une seule machine, Kubernetes aurait été du coût sans bénéfice.

Un train de livraison hebdomadaire

Au début, je déployais plusieurs fois par jour. J'ai arrêté : tout ce qui est validé attend sur une branche, et un script livre le tout le mercredi à 2 h. S'il n'y a rien de nouveau, il n'y a pas de livraison. Le script construit une copie propre du code, déploie, vérifie la santé du jeu, et revient seul à la version précédente en cas d'échec. Les joueurs ont des nouveautés régulières sans subir d'instabilité permanente.

Peu d'alertes, mais vraies

Une alerte qui sonne pour rien finit ignorée. Après une série de faux positifs, j'ai revu toutes les règles : une panne n'est déclarée qu'après 5 minutes sans aucune réponse, la lenteur ne se mesure que sur les requêtes réussies, et les rappels sont espacés. J'ai aussi ajouté des alertes de capacité : elles me disent, chiffres à l'appui, quand il sera temps de prendre un serveur plus grand, plutôt que de le découvrir pendant un pic de joueurs.

Un incident réel

Le 13 octobre, mon homelab s'est éteint pendant la nuit. Le jeu, lui, n'a rien vu : il tourne sur le VPS. Mais la réplication de sa base vers le homelab s'est bloquée sur une connexion morte, et elle ne s'est pas relancée quand le serveur est revenu.

Mon alerte vérifiait que le service de réplication tournait, pas qu'il copiait vraiment : rien n'a sonné. Je l'ai découvert le jour même, en préparant une analyse de l'économie à partir d'une copie de la base : les données dataient de la veille.

Bilan chiffré : zéro donnée perdue, environ 25 minutes de la découverte à la restauration vérifiée. Après réparation, j'ai ajouté une alerte sur le retard réel de la réplication, et rendu bruyant le script de copie qui échouait en silence. Le même blocage serait aujourd'hui détecté en 30 minutes au plus, contre une quinzaine d'heures ce jour-là. La leçon que j'en garde : surveiller qu'un processus tourne ne dit pas qu'il fait son travail.

Ce que je referais autrement

• Une seconde destination de sauvegarde, indépendante de mon homelab, dès le départ.
• Un test de restauration automatique et quotidien, plutôt que de découvrir qu'une sauvegarde est inutilisable le jour où on en a besoin.
• Le train de livraison hebdomadaire dès la première semaine, au lieu de l'adopter après quelques déploiements de trop.

Ce que Setlist dit de ma façon de travailler

Je conçois des systèmes qu'une petite équipe peut réellement exploiter. Je préfère une architecture simple et bien surveillée à une architecture impressionnante que personne ne comprend à 3 h du matin. Et j'ai découvert que j'aimais autant concevoir l'expérience d'un joueur que l'infrastructure qui la fait tourner.

Jouer sur setlist.gg ↗