ShakeUp

Une soirée, c’est un système d’information.

Le projet a démarré sous le nom de code The Forest, dans le cadre du projet de deuxième année d’IMT Nord Europe : un vrai commanditaire, un cahier des charges, un budget et des revues régulières avec deux tuteurs.

Le besoin : un organisateur de soirées doit gérer en même temps les réservations de tables, les entrées, les commandes et l’encaissement. L’objectif était de tout réunir dans un seul outil, utilisable par le client chez lui comme par le staff en pleine soirée.

Six rôles, une seule app.

La difficulté du produit, c’est que chacun voit une application différente. L’app lit le rôle de l’utilisateur à la connexion et l’envoie vers la bonne interface.

D’une publication à la dernière bouteille.

1. Publication. L’admin crée la soirée et son plan de table dans le backoffice. Les utilisateurs reçoivent une notification push.
2. Réservation. Le client choisit sa table sur le plan, indique le nombre d’invités et règle l’acompte via la billetterie partenaire.
3. Billet. La réservation confirmée génère un QR code dans l’app, qu’on peut aussi ajouter à Apple Wallet.
4. Entrée. Le staff scanne le QR à la porte : la table passe « arrivée » et le serveur concerné est prévenu.
5. Commande. À table, le staff scanne le QR de la table et saisit la commande. Elle apparaît chez la compta et chez le préparateur.
6. Paiement. La compta valide le paiement ; l’acompte déjà versé est déduit automatiquement.
7. Service et bilan. Le préparateur passe la commande en « prête » puis « envoyée ». Après la soirée, l’admin consulte les résultats agrégés.

Trois briques, un backend.

L’app mobile et le backoffice partagent le même projet Firebase. Toutes les écritures sensibles (réservations, commandes, paiements, rôles) passent par des Cloud Functions côté serveur, jamais directement depuis un client.

Autour de ce cœur : notifications push iOS via APNs, images des soirées sur Cloudinary, builds et mises à jour avec EAS, passes Apple Wallet signés, et un webhook pour la billetterie partenaire.

Ce qui m’a le plus appris.

• Import des plans de salle par IA. Placer des dizaines de tables à la main sur un plan, c’est long. Le backoffice fournit un prompt qu’on donne à un LLM multimodal (ChatGPT, Gemini ou Claude) avec la photo du plan ; le modèle renvoie un JSON structuré (catégories, tables, positions). Le backoffice le valide, corrige les coordonnées selon le cadrage de l’image, puis le fusionne sans jamais écraser une table déjà réservée.
• Plan de table interactif. Dans le backoffice, on pose les tables sur le plan de la salle, on les déplace et on les redimensionne. Les positions sont stockées en pourcentage, donc l’app affiche le même plan sur n’importe quel écran, avec zoom.
• API billetterie. J’ai rédigé la spécification des échanges avec la plateforme de billetterie (6 endpoints). Chaque appel est signé en HMAC-SHA256 pour qu’on ne puisse pas valider un acompte de l’extérieur.
• Apple Wallet sans module natif. Le pass est généré et signé par une Cloud Function, puis ouvert dans Safari. Résultat : la fonctionnalité a pu partir en mise à jour OTA, sans nouvelle version sur l’App Store.
• Rôles et sécurité. Le rôle est porté par le jeton d’authentification et revérifié côté serveur dans chaque fonction. Un compte staff peut être jetable, limité à une soirée.

Vérifier un webhook.

Quand la billetterie confirme un acompte, elle appelle ce point d’entrée. On recalcule la signature du message avec la clé partagée et on la compare en temps constant avant de toucher à la base.

exports.ticketingWebhook = onRequest(async (req, res) => {
  // … méthode, configuration et taille du corps vérifiées avant
  const header   = String(req.get("X-ShakeUp-Signature") || "");
  const expected = "sha256=" + crypto
    .createHmac("sha256", secret).update(rawBody).digest("hex");

  const a = Buffer.from(header), b = Buffer.from(expected);
  if (a.length !== b.length || !crypto.timingSafeEqual(a, b)) {
    return res.status(401).json({ error: "invalid-signature" });
  }

  // La réservation doit exister et correspondre à la soirée et à la table annoncées
  const resa = (await db.doc(`tablesReservation/${reservationId}`).get()).data();
  if (body.eventId !== resa.eventId) return res.status(422).json({ error: "reservation-mismatch" });

  await applyDepositValidation({ reservationId, source: "api" });
  res.status(200).json({ ok: true });
});

Chef de projet qui code.

• Cadrage et maquettes : recueil des besoins avec le client, parcours et écrans sous Figma, validés avant développement.
• Architecture : choix de la stack, modèle de données, découpage en Cloud Functions, règles de sécurité.
• Développement : une grande partie de l’app, du backoffice et du backend.
• Pilotage : sprints et répartition des tâches dans l’équipe de cinq, suivi d’un budget de 300 €, comptes rendus aux tuteurs.
• Mise en production : publication sur l’App Store et le Play Store, déploiement du backoffice.

Ce qui a été livré.

De l’app au SaaS.

ShakeUp a été conçu pour un organisateur. L’étape suivante, c’est d’en faire un SaaS que n’importe quel organisateur de soirées en France peut utiliser, avec ses propres événements, son équipe et son menu.

Les leçons.

• Un produit à plusieurs rôles se conçoit à partir des parcours, pas des écrans : qui fait quoi, à quel moment de la soirée.
• Mettre la logique métier côté serveur dès le début évite de devoir faire confiance au téléphone du client.
• Une maquette validée coûte beaucoup moins cher qu’une fonctionnalité recodée.
• Diriger une équipe, c’est surtout rendre visible qui fait quoi et pour quand.