Exigences et Spécifications du Projet - Perlene SaaS
Ce document recense les règles d'architecture et les exigences techniques spécifiques à respecter tout au long du développement de la plateforme SaaS Perlene.

1. Architecture SaaS Multi-Tenant
Isolation des données : Toutes les données métier doivent obligatoirement être associées à une entreprise (tenant principal) et à un site (point de vente/succursale).
Accès par Rôle :
SUPER_ADMIN a accès à toutes les données de toutes les entreprises.
ADMIN_ENTREPRISE ne voit que les données de son entreprise.
GESTIONNAIRE_SITE (et rôles inférieurs) ne voit que les données rattachées spécifiquement à son site.
Filtre Tenant Global : La policy 
tenantFilter.js
 est responsable d'injecter automatiquement les contraintes entreprise et site dans req.query pour toutes les requêtes entrantes.
2. Rétention des Données (Soft Delete)
Suppression Logique Uniquement : Il est interdit de supprimer physiquement une donnée métier de la base de données (.destroy() est à proscrire pour les entités métier).
Implémentation :
Tous les modèles doivent posséder un champ estSupprime (booléen, défaut: false) ou dateSuppression (string/datetime, défaut: null).
Les requêtes de lecture (find, findOne) doivent exclure systématiquement les enregistrements supprimés (estSupprime: false).
Les routes de suppression (DELETE) doivent effectuer un .update() pour marquer le flag de suppression au lieu d'un .destroy().
3. Synchronisation et Origine des Données
La plateforme fonctionne en tandem avec un logiciel client lourd (desktop/caisse) local.

Traçabilité de l'Origine : Toute donnée créée doit indiquer sa plateforme d'origine via le champ sourceOrigine (LOGICIEL, WEB, MOBILE).
Statut de Synchronisation : Le booléen estSynchronise indique si la plateforme SaaS et le logiciel local ont déjà échangé cette donnée.
Création via Logiciel → remonte au Web → estSynchronise passe à true.
Création via Web → redescend vers Logiciel → estSynchronise passe à true après confirmation du logiciel.
4. Système de Modèles Métier (Extensibilité)
Le SaaS se veut modulaire (Gestion Commerciale, Restaurant, Hôtel, CRM, Pressing, etc.).
La disponibilité des routes spécifiques à un module doit être conditionnée par la validation de l'abonnement de l'entreprise au module concerné (via ModuleAbonnement).
5. Rétrocompatibilité
Les anciens systèmes de rôles (groupe: VENTE, SUPERVISEUR, etc.) et l'ancienne table UserInfo doivent être gérés par des couches de compatibilité (ex. dans 
Authorized.js
) jusqu'à la refonte complète de tous les contrôleurs front/back.