Rôles & permissions dynamiques
Des permissions figées dans le code obligent à redéployer pour chaque nouveau rôle métier — un gérant qui veut créer un rôle « Caissier junior » doit attendre une mise à jour.
Rôles et permissions stockés en base de données, modifiables depuis les paramètres de l'organisation sans redéploiement. Mise en cache Redis : la vérification passe de 150ms à 2ms.
Un gérant crée et ajuste ses rôles lui-même. Chaque requête reste vérifiée en 2ms, même avec des dizaines de rôles personnalisés.
Modules découplés, automatisations fiables
Coupler directement Fidélisation et Coupons dans le code créerait une dépendance rigide : impossible de désactiver l'un sans casser l'autre, impossible d'ajouter un troisième module réactif sans tout retoucher.
Un déclencheur configurable écoute les événements métier (ex. « offre de fidélité acceptée ») et déclenche une action dans un autre module via une file d'attente dédiée, avec 3 tentatives et un échec toujours silencieux côté utilisateur.
Fidélisation ignore totalement l'existence de Coupons. Désactiver un module premium ne casse jamais les autres — le comportement se reconfigure sans toucher au code.
2FA TOTP — zéro dépendance
Les librairies TOTP tierces ajoutent des vecteurs d'attaque et des dépendances à maintenir. Les codes de secours sont souvent stockés en clair.
Implémentation native : HMAC-SHA1, base32 RFC 4648, dynamic truncation RFC 4226. Codes de secours générés et hashés en SHA-256, à usage unique.
Le compte d'un gérant reste protégé même si son mot de passe fuite. Compatible Google Authenticator, Authy, 1Password.
Isolation multi-tenant — 3 niveaux indépendants
Une seule couche d'isolation est insuffisante : un bug dans un seul contrôle expose toutes les données de toutes les entreprises clientes.
Le token d'accès identifie l'organisation dès la connexion, un contrôle serveur valide l'appartenance à chaque requête, et la base de données applique elle-même l'isolation via Row Level Security.
Trois couches indépendantes : une seule suffit à bloquer une intrusion. Vos données ne sont jamais visibles par une autre entreprise cliente, même en cas de bug.
Traçabilité complète — qui a fait quoi, quand
Sans journal d'audit, impossible de répondre à « qui a annulé cette vente ? » ou « pourquoi ce stock a-t-il changé ? » — un vrai problème en cas de litige client ou de contrôle interne.
Chaque action sensible (vente annulée, stock ajusté, rôle modifié, coupon validé) est journalisée avec l'utilisateur, l'organisation et l'horodatage — automatiquement, sans code additionnel dans chaque module.
Un historique complet et consultable, utile pour trancher un litige ou auditer l'activité d'une succursale.