Problème
Éviter les fuites entre organisations.
Solution
Contexte tenant résolu côté serveur, membership vérifié, identifiant d’organisation porté par les services.
Étude de cas technique · projet en développement continu
Développement d’un SaaS de gestion pour salles de spectacle
Conception full-stack d’une plateforme métier multi-tenant réunissant programmation, réservations, billetterie, utilisateurs, paiements et outils d’exploitation.
Le problème métier
Une salle de spectacle n’est pas un simple catalogue de contenus
La plateforme relie spectacles, productions, représentations, jauges, tarifs, réservations, participants et équipes. Chaque action a un contexte d’organisation et un état métier à préserver.
Le projet est développé par lots : certaines briques sont opérationnelles, d’autres constituent encore un socle ou une expérimentation. Cette distinction guide la présentation.
Architecture générale
Un même backend pour l’administration, le public et le terrain
ClientsWeb admin · public · Flutter Operations
↓
FrontendReact · TypeScript · Vite · SCSS
↓
API RESTNode.js · Express · modules métier
↓
DonnéesMySQL · migrations SQL · transactions
Le socle mobile Flutter est réel et dialogue avec les mêmes endpoints Operations. Les plateformes Android, Web et Windows sont générées depuis le projet source.
Multi-tenant
Le contexte d’organisation traverse chaque module métier
Le middleware résout l’organisation à partir du hostname ou du contexte de session, vérifie le membership actif, puis expose un identifiant serveur utilisé par les services. Le header client n’est pas une source de vérité en production.
Extrait simplifié · tenantContext.ts
resolveOrganizationByHostname(hostname); verifyActiveMembership(); req.organizationId = organization.id; next();Ce garde-fou place l’isolation des données côté serveur, avant les routes métier.
Modélisation et billetterie
Conserver la cohérence quand un stock change d’état
Organisationmembres · rôles · domaines · modules
Productioncontenu · crédits · catégories
Représentationdate · capacité · offres tarifaires
Réservationacheteur · participants · billets
Jaugeholds · ledger · disponibilité
Paiementétat local · événements webhook
Une réservation ne se résume pas à une insertion : un maintien temporaire réduit la disponibilité, son expiration doit être prise en compte, et la conversion en réservation manuelle reste transactionnelle. Les prix et la TVA sont copiés au moment de la réservation pour ne pas réécrire l’historique.
Extrait conceptuel · capacité
BEGIN; lockOfferAndCapacity(eventDateId); createHold({ organizationId, eventDateId, expiresAt }); appendInventoryLedger({ eventDateId, quantity: -requested }); COMMIT;Le code publié est volontairement réduit : il montre la logique transactionnelle sans exposer de données d’exploitation.
Sécurité et autorisations
« Connecté » ne veut pas dire « autorisé »
Les rôles métier disposent de permissions distinctes : programmation, réservations, données personnelles, pointage, paiements manuels, communication ou administration des utilisateurs. Les grants Operations peuvent être limités à une organisation, un événement, un festival ou une représentation.
Les détails sensibles restent hors de cette page : aucun secret, token, identifiant de compte de paiement ou chemin d’administration n’est publié.
Programmerprogrammation · contrats
Billetterieréservations · pointage · encaissement
Communicationcontenus · médias · diffusion
Lecture seuleconsultation du tableau de bord
API et client Operations
Des endpoints conçus pour plusieurs interfaces
Le frontend web et le client Flutter consomment le backend SaaS. Le module Operations expose notamment la journée, les participants d’une représentation, le check-in manuel et son annulation. La date d’exploitation est explicite dans l’API pour éviter les ambiguïtés de fuseau.
Authentification→Permissions→Contexte organisation→Service métier→Réponse client
Endpoints vérifiés · Operations
GET /api/saas/reservations/operations/day?date=YYYY-MM-DD
GET /api/saas/reservations/performances/:performanceId/participants
POST /api/saas/reservations/performances/:performanceId/check-inLe client Flutter utilise ces contrats pour afficher les arrivées et effectuer le pointage terrain.
Difficultés techniques
Les décisions qui structurent le produit
Problème
Garder une jauge cohérente pendant une réservation.
Solution
Maintiens temporaires, ledger d’inventaire et conversion transactionnelle, avec conservation des annulations.
Problème
Faire évoluer le modèle sans casser l’historique.
Solution
Migrations additives, snapshots d’offres et de prix, compatibilité legacy explicitement bornée.
Compétences démontrées
Construire, sécuriser et faire évoluer une application métier
Architecture SaaSReact & TypeScriptNode & ExpressSQL & migrationsAPI RESTMulti-tenantRBAC & sécuritéBilletterieFlutterNginx & PM2Déploiement serveur
Projet en développement continu, utilisé comme terrain de conception d’une plateforme métier complète pour le spectacle vivant.
Un projet à construire ?
Vous développez un SaaS, un outil métier ou une automatisation ?
Je peux intervenir sur la conception, le développement full-stack, les APIs, les automatisations ou la reprise d’un projet existant.
Me contacter