Rabbehni

Rabbehni est un SaaS de fidélité qui permet à n'importe quel commerce — un café, un barbier, une chaîne de magasins — de lancer un vrai programme de fidélité sans le développer : le client scanne un QR code au comptoir, la visite est enregistrée, et une récompense ou un jeu se débloque instantanément.

Contexte et problème. La fidélité est un problème résolu pour les grandes chaînes qui ont leur logiciel sur mesure, et non résolu pour tous les autres. En faire un SaaS soulève trois difficultés distinctes en même temps. La tenancy : des dizaines de marchands partagent une seule base et ne doivent jamais voir les clients des autres. La confiance : un check-in accorde une valeur économique réelle, il ne peut donc pas être une simple affirmation de l'application cliente. La multiplication des surfaces : le marchand a besoin d'un tableau de bord, le personnel au comptoir d'un scanner rapide, et le client d'un portefeuille — sachant que le client qui vient de scanner un QR n'installera rien, alors que l'habitué qui revient chaque semaine, lui, veut une app.

Solution. Un monorepo avec une unique API NestJS 11 et cinq surfaces client, dont aucune n'accède directement à la base. L'API est découpée par domaine — checkin, games, rewards, redemptions, campaigns, billing, tenant, analytics, audit, localization — chacun étant un module Nest avec une séparation stricte contrôleur/service/Prisma : les contrôleurs déclarent les routes et valident les DTO, les services portent toute la logique métier, Prisma accède aux données et ne décide de rien. Les préoccupations transverses vivent dans common sous forme de gardes : authentification, cloisonnement du tenant et limites du plan d'abonnement sont appliqués avant même qu'une requête n'atteigne un service. Prisma modélise 26 entités sur 9 migrations versionnées contre PostgreSQL 16. L'app web est un Next.js 16 avec des groupes de routes par public, et l'application client existe volontairement deux fois — en web pour le visiteur qui vient de scanner, en Expo pour l'habitué — les deux consommant exactement les mêmes endpoints /api/me. Une passerelle Socket.IO pousse les check-ins en direct vers les tableaux de bord marchands.

Ingénierie et exigence qualité. La règle des trois couches est l'invariant autour duquel la base de code est construite : pas de logique métier dans les contrôleurs, pas de req/res dans les services, aucune décision dans la couche données — ce qui rend les services testables unitairement sans passer par HTTP. L'isolation des tenants et le respect des plans sont des gardes plutôt que des vérifications endpoint par endpoint : un nouveau module en hérite au lieu de les réimplémenter en oubliant un cas limite. La validation du check-in est entièrement côté serveur ; le scanner du personnel soumet un code, l'API décide. Le dépôt fournit douze chapitres de documentation technique couvrant l'architecture, le modèle de données, la sécurité et les parcours fonctionnels — ainsi que des scripts de seed qui montent un jeu de démonstration complet depuis une base vide.