étude de casBandPilotdéveloppement webReactExpressWebSocketfull-stack
Étude de cas : création de BandPilot, l'app de gestion pour groupes de musique (React, Express, PostgreSQL)
20 mars 202614 min de lecture
JL
Jérémy Lagouardille
Développeur web freelance, PilotOne
BandPilot est né d'un problème concret : je joue dans un groupe de musique (Watts Up, orchestre de bal du Béarn) et on perdait un temps fou à gérer nos partitions, nos setlists et nos dates de concerts. Chacun avait ses fichiers dans un coin, les versions se mélangeaient, et personne ne savait qui avait la dernière version de quoi. J'ai décidé de créer l'outil que j'aurais aimé avoir.
Cet article est un retour d'expérience complet : besoins métier, choix techniques, défis rencontrés, mesures de performance, leçons apprises après plusieurs mois de production avec de vrais utilisateurs. Si vous envisagez de faire développer votre propre application web full-stack (artisan, association, profession libérale, PME), vous trouverez ici de quoi nourrir votre cahier des charges.
Le besoin métier
Un groupe de musique, c'est une petite entreprise qui s'ignore. Il faut gérer :
Un classeur de partitions partagé, PDF, versions, transpositions par instrument
Des setlists par concert, ordre des morceaux, durées, transitions, notes scène
Un calendrier, répétitions, dates de concerts, disponibilités des membres
La gestion administrative, devis, factures, déclarations GUSO ou URSSAF
La communication interne, annonces, notifications, validation collective
Le mode live sur scène, affichage de la setlist + synchronisation avec le leader
Avant BandPilot, on utilisait un mélange de Google Drive, WhatsApp, un tableur Excel et des bouts de papier. Chaque concert exigeait 2 à 3 heures de préparation logistique collective rien que pour s'assurer que tout le monde avait les bonnes partitions dans la bonne tonalité. C'était ingérable.
Les choix techniques (et pourquoi)
J'ai choisi une architecture classique mais robuste, optimisée pour la rapidité d'itération et la maintenance long terme :
Frontend : React 19 + Vite 7. Pas de framework SSR (Next.js) parce que BandPilot est une app pure derrière login, pas besoin de SEO. Vite offre un DX (Developer Experience) excellent : hot reload < 100 ms, bundle de production léger.
Backend : Express.js + Prisma comme ORM. Express me donne un contrôle total sur l'API REST et les WebSockets. Prisma simplifie la gestion des migrations PostgreSQL et la génération de types TypeScript.
Base de données : PostgreSQL 16 hébergée sur Render. Backups quotidiens automatiques, point-in-time recovery sur 7 jours.
Stockage fichiers : Supabase Storage pour les PDF de partitions et les MP3. Avantages : gestion fine des permissions, CDN intégré, chiffrement at-rest.
Hébergement : Render Frankfurt pour conformité RGPD (données européennes). Tier Standard pour avoir < 100 ms de latence depuis la France.
: Passkey + email magic link via Supabase Auth. Plus de mot de passe à oublier, expérience mobile parfaite.
Un projet en tête ?
Discutons de vos besoins. Premier échange gratuit et sans engagement.
WebSockets : socket.io pour la synchronisation live des setlists multi-écrans.
UI : Tailwind CSS + shadcn/ui. Design system cohérent, accessibilité par défaut, dark mode natif.
Pourquoi pas Next.js ?Parce que BandPilot est une application pure (pas de SEO nécessaire, tout est derrière login). Vite + React Router offrent un DX supérieur pour ce type de projet, sans la complexité du serveur SSR. Le backend Express séparé me donne aussi la flexibilité d'exposer l'API à d'autres clients futurs (mobile native, intégrations partenaires).
Pourquoi pas une stack « tout-en-un » type Bubble ou Webflow ?Parce que BandPilot a des besoins très spécifiques (mode live synchronisé WebSocket, gestion PDF avancée, facturation française) que les no-code ne peuvent pas couvrir sans devenir des usines à gaz. Et à long terme, le coût total d'un no-code dépasse souvent celui d'un code sur mesure.
Le mode live : la fonctionnalité signature
La fonctionnalité dont je suis le plus fier, c'est le mode live. Sur scène, chaque musicien affiche sa setlist sur tablette ou téléphone. Quand le leader du groupe passe au morceau suivant, tous les écrans se synchronisent en temps réel, sans manipulation de la part des autres musiciens.
Concrètement : le batteur voit la setlist se scroller automatiquement quand le leader tape sur le morceau suivant. Le saxophoniste voit s'afficher la tonalité de transposition spécifique à son instrument. Le claviériste voit ses notes de partition défiler. Le tout fonctionne même avec une connexion mobile faible, essentiel quand on joue dans un bar en zone rurale du Béarn.
Techniquement, c'est du WebSocket via socket.io avec une logique de rooms par groupe. Chaque membre connecté reçoit les mises à jour instantanément. Côté frontend, j'ai implémenté une logique de reconnexion automatique avec rejeu des derniers événements pour gérer les coupures réseau ponctuelles. Latence mesurée en production : < 200 ms en moyenne entre l'action du leader et l'affichage chez les membres.
Les défis rencontrés et leurs solutions
Défi 1 : gestion des PDF de partitions
Les musiciens veulent pouvoir uploader leurs partitions, les annoter au stylet (sur tablette), les transposer dans une autre tonalité, et les retrouver rapidement par titre, style ou tonalité. J'ai implémenté :
Un viewer PDF intégré avec zoom, rotation et navigation par page
Un système de tags pour retrouver facilement un morceau (style, difficulté, tonalité)
Un système de versions (la dernière annotation collective est partagée à tout le groupe)
Une recherche plein texte sur le titre, le tag et le contenu OCR du PDF
La librairie PDF.js de Mozilla a fait l'essentiel du travail côté affichage. Pour l'OCR, j'utilise Tesseract.js côté navigateur (extraction texte à l'upload, pas en temps réel). Tout le traitement se fait localement, aucun PDF ne quitte les serveurs Render+Supabase.
Défi 2 : facturation française légalement conforme
Chaque concert génère une facture avec le détail de la prestation, le cachet, la répartition entre les membres et les charges sociales (GUSO ou URSSAF selon le statut). J'ai créé un système de génération PDF automatique qui respecte les obligations légales françaises :
Mentions obligatoires (SIRET, TVA si applicable, mode de paiement, pénalités de retard)
Calcul automatique TTC/HT/TVA selon le régime fiscal du groupe
Export comptable CSV pour transmission à l'expert-comptable
Conformité Factur-X (facture électronique normalisée) en préparation pour 2026/2027
La librairie pdfkit (Node.js) et un peu de templating permettent de générer une facture en moins de 100 ms. L'export CSV utilise le format SAGE/Cegid standard pour faciliter l'import dans n'importe quel logiciel comptable français.
Défi 3 : performances mobiles en zone rurale
Beaucoup de salles du Béarn ont une 4G aléatoire. Bandpilot devait fonctionner même avec une connexion à 1 Mbit/s. J'ai optimisé :
Lighthouse mobile : Performance 96, Accessibility 100, Best Practices 100, SEO 100
Leçons apprises (et applicables à votre projet)
1. Démarrer par un MVP et itérer.La première version de BandPilot n'avait que les setlists et les partitions. Le mode live, la facturation, le système de tags sont arrivés progressivement, validés par l'usage réel du groupe. Aucune fonctionnalité « parce que ça pourrait être utile ».
2. Utiliser son propre produit tous les jours.C'est la meilleure source de feedback possible. Quand un bug me frustre pendant un concert, je le corrige le lendemain matin. Cette boucle « ressentir-corriger » est impossible à reproduire avec un client externe.
3. Choisir des technologies matures.React, Express, PostgreSQL existent depuis 10+ ans. Tutoriels abondants, communauté massive, recrutement facile si je dois passer la main un jour. J'ai écarté volontairement les technologies trop jeunes (Bun, Solid.js, etc.) pour un projet qui doit durer.
4. Investir dans les tests dès le début. BandPilot a 200+ tests automatisés (Vitest côté frontend, Jest côté backend). Ça a sauvé des dizaines de régressions critiques au fil des refactorings. Ne JAMAIS déployer une feature sans test associé.
5. Documenter au fur et à mesure.J'ai un fichierTO-KNOW.md par grand domaine (auth, paiement, mode live, etc.) avec les décisions techniques importantes et leurs raisons. Indispensable quand on revient sur un code 6 mois plus tard.
Et pour votre projet ?
Cette approche « produit ET prestation » est ce qui différencie PilotOne d'une agence classique. Quand vous voyez BandPilot, BudgetPilot, PathPilot et ToolPilot tourner depuis plusieurs années avec de vrais utilisateurs, vous savez que vous travaillez avec quelqu'un qui sait concevoir, développer, déployer ET maintenir un produit dans la durée.
Si vous avez un projet d'application web sur mesure (outil interne, plateforme B2B, gestion métier spécialisée), je serais ravi d'en discuter. Premier échange gratuit, devis détaillé sous 48 h. Me contacter ou consulter mes tarifs publics.
BandPilot est accessible sur bandpilot.fr. Si vous êtes musicien dans un groupe, demandez un essai gratuit.
Article mis à jour le 25 avril 2026, métriques de production, ajout sections facturation française et performances mobiles, leçons apprises.
