Le problème : « Tu viens samedi ? »
Je joue du trombone dans 2LDC, une fanfare d’une quinzaine de fanfarons. Avant chaque répète ou chaque concert, c’est la même chanson : qui vient ? Et surtout, est-ce qu’on a tous les pupitres ? Parce qu’un concert sans sousaphone, c’est pas le même problème qu’un concert avec trois trompettes en moins.
Avant, il fallait jongler entre trois outils :
- un site de présences : identifiant, mot de passe, puis un grand tableau de oui et de non, sans aucune lecture par instrument ;
- les partitions dans un dossier Drive partagé, avec des dizaines de PDF à faire défiler pour trouver sa partie ;
- les notes de frais dans un Google Form, encore ailleurs.
Tout le monde était déjà inscrit. Le but n’était donc pas de convaincre la fanfare de changer d’outil, mais de rendre la réponse tellement simple que tout le monde réponde. Et que les admins arrêtent de relancer chacun un par un.
Avant de coder : on pose tout à plat
Première étape, aucune ligne de code : un PRD (Product Requirements Document) pour poser le besoin. Qui utilise l’appli, sur quel écran, quelles données, quelles décisions trancher. Au passage, j’en ai tiré une méthode en 13 étapes que je ressors depuis à chaque projet.
Les décisions qui ont tout guidé :
- Répondre en un tap. On ouvre l’appli entre deux trucs, on répond, on ferme. Chaque clic en plus, c’est un fanfaron qui ne répond pas.
- Quatre réponses, pas deux. Oui, non, indécis… et « pas de réponse ». Pour un orga, « je sais pas encore » et « j’ai pas vu le message », ça n’a rien à voir.
- Lire par pupitre. Pour chaque date, on voit tout de suite combien de batteries, de saxos, de trompettes, de trombones et de graves sont là. Un zéro en rouge, et on sait qui appeler.
- Le téléphone pour les fanfarons, l’ordi pour les orgas. Les écrans membres se tiennent d’une main ; l’admin (dates, comptes, partitions) suppose un vrai clavier.
- On se connecte avec son prénom. Pas d’e-mail à retenir, pas d’inscription : un admin crée le compte et donne le mot de passe.
Deux looks, un gagnant
La première version jouait la carte « affiche de concert » : fond noir, encre crème, cartes en forme de ticket. Sympa, mais ça chargeait l’écran sans aider à lire l’info.
Alors j’ai tout repris avec une idée fixe, « Le Spécimen vivant » : une planche de spécimen typographique, papier et encre, une seule police (Archivo variable). Et une astuce dont je suis assez fier : la graisse du chiffre de chaque date dépend du nombre de fanfarons qui viennent. Personne ? Trait tout fin. Tout le monde ? Chiffre bien gras. Un coup d’œil sur le calendrier, et on repère les dates qui tiennent la route avant même de lire un mot. Le chiffre est toujours accompagné d’un compte en clair (« 8 / 15 viennent »), parce qu’un effet typo tout seul, ce n’est pas accessible.
Le reste suit la même logique :
- Le rouge veut dire « bouge-toi ». Il ne sort que pour ce qui demande une action : une date sans réponse, un pupitre vide, un refus, une suppression. Si rien ne demande d’action, pas de rouge à l’écran.
- Une couleur pastel par famille d’instruments, avec une petite icône par instrument.
- Des contrastes mesurés, pas estimés à l’œil, et des boutons d’au moins 44 px pour les gros doigts.
- Un peu d’humour dans les textes : une fois sa réponse donnée, c’est « Trop tard ! seul Dieu peut le modifier. » (ou un admin, en vrai).
Sous le capot
La stack : SvelteKit et Svelte 5, Drizzle ORM sur Turso (SQLite), better-auth, Tailwind CSS et shadcn-svelte, Playwright, le tout sur Vercel. Budget : 0 € par mois, tout tient dans les offres gratuites.
Chaque choix est argumenté dans un document d’architecture, y compris ce que j’ai volontairement laissé de côté (pas d’OAuth, pas de réplicas de base : inutile pour quinze personnes).
Ce qui comptait vraiment :
- C’est le serveur qui vérifie les rôles, pas juste un bouton qu’on cache. L’espace admin est protégé dès le routage.
- Pas moyen de s’enfermer dehors : un admin ne peut ni supprimer son propre compte, ni retirer le dernier rôle d’admin.
- La réponse s’affiche tout de suite, avant même que le serveur confirme, et revient en arrière si ça coince.
- Un seul tableau d’ensemble pour tout le monde : en lecture seule pour les fanfarons, modifiable pour les admins qui peuvent corriger une réponse à la main.
- Une bibliothèque de partitions : on choisit son instrument, et chaque morceau affiche directement sa partie (partie 1, partie 2…).
- Un e-mail à chaque nouvelle date, pour que personne ne la rate.
- On ne repart pas de zéro : un script importe les dates publiées sur l’ancien site, sans doublon, et peut être relancé autant de fois que nécessaire.
- Des données de démo pour tester sans toucher aux vraies, et des tests de bout en bout sur les parcours qui comptent (connexion, réponse, actions admin).
Côté méthode : une fonctionnalité à la fois. Je lis les données, je les affiche, j’ajoute l’écriture, je teste dans un vrai navigateur avec des données jetables, et je commite. Les nouveautés passent d’abord par une proposition écrite (OpenSpec) avant d’être codées.
Et je ne code pas seul : je travaille en binôme avec Claude Code, un assistant de développement par IA. Moi, je fixe le cap : le besoin, les décisions produit, la direction visuelle, et je relis et teste tout ce qui part en ligne. Lui, il accélère l’écriture du code. C’est d’ailleurs pour ça que tout est écrit noir sur blanc (PRD, architecture, design) : un bon binôme, humain ou pas, ça se briefe.
Et alors ?
Toute la fanfare est passée sur 2LDC Calendar. Présences, partitions et frais au même endroit, une seule connexion, et tout se lit d’un coup d’œil sur un téléphone.
La suite au programme :
- un formulaire de frais intégré, pour dire adieu au Google Form (qui oblige à avoir un compte Google pour joindre ses justificatifs) ;
- des rappels pour les dates restées sans réponse. Parce qu’il y a toujours un trombone qui oublie.