286 lines
30 KiB
Markdown
286 lines
30 KiB
Markdown
# Requirements Document
|
|
|
|
**Spec : Socle Plateforme SchotzimmO**
|
|
|
|
## Introduction
|
|
|
|
**SchotzimmO** (« l'ami de l'immobilier » ; *Schotzi* signifie « ami » en alsacien, *immO* pour l'immobilier) est une **plateforme SaaS multi-utilisateur, multi-réseaux et multi-module** destinée aux **mandataires immobiliers**, en complément de la plateforme mère de leur réseau (ex. IAD). Elle les aide à gérer en propre leur activité quotidienne : relation prospects, suivi des opportunités et des actions, agenda, carnet d'adresses, suivi kilométrique, facturation vers le siège, notes de frais, tableau de bord et reporting.
|
|
|
|
La plateforme est **multi-réseaux** : chaque mandataire appartient à un **Réseau** choisi à l'inscription (IAD et un réseau de démonstration au lancement, d'autres réseaux ultérieurement). Les données de chaque Réseau sont **physiquement isolées** dans une base de données propre à ce Réseau ; les arbres de parrainage sont donc **cloisonnés par Réseau**. Un Réseau est préalablement initialisé par l'Administrateur (Onboarding_Reseau) avant toute inscription.
|
|
|
|
L'accès aux fonctionnalités est organisé en **Modules** regroupés dans des **Packs d'abonnement** (Starter gratuit, Pro, Premium). Chaque Mandataire souscrit un abonnement **individuel** qui détermine les Modules auxquels il accède.
|
|
|
|
Ce document, dit **Socle Plateforme**, décrit les exigences **transversales** communes à tous les Modules : comptes et inscription, authentification, Réseaux, parrainage et hiérarchie, visibilité hiérarchique, annuaire, abonnements et Packs, activation des Modules, administration, tableau de bord, cadre applicatif et isolation des données par Réseau. Les exigences propres à chaque Module (Carnet d'adresses, KMS, CRM, Agenda, Facturation…) sont décrites dans leurs specs dédiées.
|
|
|
|
> **Note** : Ce document exprime le besoin **fonctionnel métier** (attendu fonctionnel, mode opératoire, règles de gestion) fourni par le Product Owner business. Les exigences **techniques** dérivées (isolation par deux niveaux de base MariaDB conteneurisée ou externe, résolution de connexion par Réseau, JWT, codes HTTP, sécurité, e-mails, rendu) sont rassemblées dans le document `design-requirements.md`, à préciser conjointement par le PO business et le PO IT. Chaque exigence renvoie, lorsque pertinent, à son pendant technique dans `design-requirements.md`.
|
|
|
|
---
|
|
|
|
## Glossary
|
|
|
|
- **Plateforme** : L'ensemble du système SchotzimmO (socle + Modules).
|
|
- **Frontend** : L'interface utilisateur de la Plateforme.
|
|
- **Backend** : Le serveur d'API de la Plateforme.
|
|
- **API** : L'interface de programmation exposée par le Backend pour communiquer avec le Frontend.
|
|
- **Mandataire** : Un utilisateur de la Plateforme, mandataire immobilier d'un Réseau, disposant d'un Compte.
|
|
- **Compte** : Le compte individuel d'un Mandataire, identifié par une Adresse_Email (login) et protégé par un Mot_De_Passe. Un Compte appartient à exactement un Réseau. L'authentification est centralisée ; les données métier du Mandataire résident dans la base de son Réseau.
|
|
- **Adresse_Email** : L'adresse e-mail du Mandataire, utilisée comme identifiant de connexion et destinataire des e-mails (invitation, réinitialisation de mot de passe).
|
|
- **Mot_De_Passe** : Le secret d'au moins 8 caractères associé au Compte, jamais conservé en clair.
|
|
- **Session** : L'état authentifié d'un Mandataire, établi à la connexion et vérifié à chaque accès protégé.
|
|
- **Jeton_Reinitialisation** : Un jeton à usage unique et à durée de vie limitée, envoyé par e-mail, permettant de définir un nouveau Mot_De_Passe sans connaître l'ancien.
|
|
- **Identifiant_Mémorisé** : L'Adresse_Email de connexion conservée par le navigateur lorsque le Mandataire a demandé « Se souvenir de moi », afin de pré-remplir le champ Adresse_Email lors des visites ultérieures sur ce même navigateur. Le Mot_De_Passe n'en fait jamais partie.
|
|
- **Profil** : Les paramètres personnels du Mandataire : identité (nom, prénom), Identifiant_Reseau, Statut_Juridique, numéro SIREN/RSAC optionnel, coordonnées, et données utiles aux Modules (ex. Adresse_Domicile pour KMS).
|
|
- **Reseau** : L'organisation mère à laquelle appartient un Mandataire (ex. IAD). Choisi à l'inscription. Chaque Reseau dispose d'une **base de données propre** qui héberge toutes ses données métier : les relations de parrainage et la visibilité hiérarchique sont ainsi strictement cloisonnées par Reseau, aucun lien ni aucune donnée ne traversant deux Reseaux.
|
|
- **Onboarding_Reseau** : Le parcours d'initialisation d'un Reseau mené par l'Administrateur avant toute inscription de Mandataire : création et initialisation de la base du Reseau, puis paramétrage (Personnalisation_Reseau). Un Reseau n'est ouvert à l'inscription qu'une fois initialisé.
|
|
- **Personnalisation_Reseau** : Le paramétrage propre à un Reseau (thème, libellés et réglages d'interface), appliqué par-dessus le socle commun.
|
|
- **Identifiant_Reseau** : L'identifiant du Mandataire propre à son Reseau (fourni par le Reseau). Obligatoire à l'inscription.
|
|
- **Statut_Juridique** : La forme d'exercice du Mandataire (ex. auto-entrepreneur, EIRL). Détermine notamment la présence d'un numéro SIREN/RSAC.
|
|
- **Numero_Siren** : Le numéro SIREN/RSAC du Mandataire, **optionnel** (présent lorsque le Statut_Juridique l'implique, ex. EIRL ; absent en auto-entrepreneur).
|
|
- **Parrain** : Le Mandataire qui a recruté/affilié un autre Mandataire (son Filleul) au sein d'un même Reseau. Un Filleul a au plus un Parrain.
|
|
- **Filleul** : Le Mandataire affilié à un Parrain au sein d'un même Reseau. Un Parrain peut avoir plusieurs Filleuls.
|
|
- **Filleul_Direct** : Un Filleul rattaché directement à un Parrain (niveau immédiatement inférieur, N+1).
|
|
- **Descendance** : L'ensemble des Mandataires situés sous un Parrain dans l'arbre de parrainage, tous niveaux confondus (Filleuls_Directs, puis leurs propres Filleuls, etc.).
|
|
- **Arbre_Parrainage** : La structure hiérarchique des relations Parrain/Filleul au sein d'un Reseau donné.
|
|
- **Membre_Declare** : Un Mandataire déclaré dans l'Arbre_Parrainage (comme Parrain ou Filleul d'un Mandataire inscrit) mais **pas encore inscrit** : il figure dans l'annuaire comme lien « supposé », sans Compte actif et sans aucune donnée métier.
|
|
- **Invitation** : Une proposition d'inscription envoyée par e-mail par un Mandataire à son Parrain supposé ou à l'un de ses Filleuls supposés, porteuse d'un Lien_Parrainage pré-renseignant le Reseau et le lien hiérarchique.
|
|
- **Lien_Parrainage** : Un lien (ou code) d'inscription transmis par Invitation ou partagé par un Parrain, pré-renseignant à l'inscription le Reseau et l'identité du Parrain, afin d'établir l'affiliation.
|
|
- **Affiliation** : Le lien Parrain/Filleul. Elle est **validée** lorsque le Filleul s'inscrit via un Lien_Parrainage ou confirme son rattachement ; elle est **supposée** tant qu'elle n'est pas validée par le Filleul.
|
|
- **Confirmation_Affiliation** : L'acte par lequel deux Mandataires déjà inscrits établissent ou valident entre eux un lien Parrain/Filleul resté supposé (cas de « perte de lien » lorsque le rapprochement automatique par e-mail n'a pas opéré). Le lien devient validé lorsque la partie concernée (Parrain ou Filleul) l'approuve.
|
|
- **Rapprochement_Email** : Le mécanisme par lequel un Membre_Declare (identifié par une Adresse_Email lors de sa déclaration) est automatiquement relié au Compte s'inscrivant avec cette même Adresse_Email, afin d'éviter les doublons et d'établir l'Affiliation.
|
|
- **Annuaire** : Le répertoire des Mandataires d'un Reseau (inscrits et Membres_Declares), permettant de visualiser l'organisation et de retrouver un contact.
|
|
- **Visibilite_Descendante** : Le principe selon lequel un Parrain peut consulter des informations de sa Descendance, jamais l'inverse (aucune visibilité ascendante ni latérale par défaut).
|
|
- **Vue_Agregee** : Une consultation d'indicateurs **agrégés** (totaux, KPI consolidés) portant sur toute la Descendance d'un Parrain, sans détail nominatif.
|
|
- **Vue_Detail_Direct** : Une consultation de données **détaillées** limitée aux Filleuls_Directs (niveau N+1) d'un Parrain, dans les limites définies par chaque Module.
|
|
- **Module** : Une unité fonctionnelle de la Plateforme (ex. Carnet_Adresses, KMS, CRM, Agenda, Facturation). Chaque Module est rattaché à un Pack.
|
|
- **Catalogue_Modules** : La liste des Modules disponibles sur la Plateforme, chacun associé au Pack qui le débloque.
|
|
- **Pack** : Une formule d'abonnement regroupant un ensemble de Modules. Trois Packs existent : **Starter** (gratuit), **Pro**, **Premium**. Un Pack inclut tous les Modules des Packs de niveau inférieur.
|
|
- **Abonnement** : La souscription individuelle d'un Mandataire à un Pack, déterminant les Modules auxquels il a accès. Un Mandataire a exactement un Abonnement actif à un instant donné.
|
|
- **Retrogradation** : Le passage d'un Abonnement vers un Pack de niveau inférieur (ou l'expiration d'un Pack payant vers Starter). Les données des Modules devenus inaccessibles sont **conservées** et restent accessibles **en consultation a minima**.
|
|
- **Module_Accessible** : Un Module auquel le Mandataire a accès en pleine fonctionnalité au titre de son Abonnement courant.
|
|
- **Module_Consultation_Seule** : Un Module non inclus dans l'Abonnement courant mais pour lequel le Mandataire possède des données antérieures, accessible en lecture seule à la suite d'une Retrogradation.
|
|
- **Administrateur** : Le gestionnaire de la Plateforme (exploitant SchotzimmO), disposant de droits d'administration transverses (comptes, abonnements, Catalogue_Modules, Onboarding_Reseau, indicateurs d'usage par Réseau). Rôle distinct de celui de Mandataire.
|
|
- **Tableau_De_Bord** : L'écran d'accueil présenté après connexion, regroupant les actions du jour et des indicateurs clés (KPI), alimenté par le socle et enrichi par les Modules_Accessibles.
|
|
- **KPI** : Un indicateur clé de performance affiché sur le Tableau_De_Bord ou dans un reporting.
|
|
|
|
---
|
|
|
|
## Requirements
|
|
|
|
### Requirement 1: Inscription d'un Mandataire
|
|
|
|
**User Story:** En tant que mandataire immobilier, je veux créer un compte sur SchotzimmO en indiquant mon réseau et mon identité, afin d'accéder aux outils de gestion de mon activité.
|
|
|
|
> Exigences techniques associées (validation serveur, unicité, hachage du mot de passe, codes HTTP) : `design-requirements.md`, Requirement 1.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. THE Frontend SHALL proposer un parcours d'inscription demandant au minimum : Adresse_Email, Mot_De_Passe, nom, prénom, Reseau et Identifiant_Reseau.
|
|
2. THE Frontend SHALL permettre de renseigner, à l'inscription, un Statut_Juridique et un Numero_Siren optionnel.
|
|
3. WHEN le Mandataire soumet le formulaire d'inscription avec tous les champs obligatoires valides, THE Backend SHALL créer un Compte rattaché au Reseau choisi et retourner une confirmation.
|
|
4. IF l'Adresse_Email soumise correspond déjà à un Compte existant, THEN THE Backend SHALL refuser la création et signaler que l'adresse est déjà utilisée, sans révéler d'autre information sur le Compte existant.
|
|
5. IF le Mot_De_Passe soumis comporte moins de 8 caractères, THEN THE Backend SHALL refuser la création et signaler que le mot de passe est trop court.
|
|
6. IF un champ obligatoire (Adresse_Email, Mot_De_Passe, nom, prénom, Reseau, Identifiant_Reseau) est absent ou vide, THEN THE Frontend SHALL afficher un message d'erreur identifiant chaque champ manquant sans soumettre la requête au Backend.
|
|
7. WHEN l'inscription est effectuée via un Lien_Parrainage valide, THE Frontend SHALL pré-renseigner le Reseau et l'identité du Parrain et empêcher la modification du Reseau pré-renseigné.
|
|
8. WHEN un Compte est créé via un Lien_Parrainage valide, THE Backend SHALL établir l'Affiliation entre le nouveau Mandataire et le Parrain désigné à l'état validé.
|
|
9. WHEN un Compte est créé, THE Backend SHALL lui attribuer par défaut un Abonnement au Pack Starter.
|
|
10. IF le Numero_Siren est fourni mais ne respecte pas un format de numéro valide, THEN THE Backend SHALL refuser la création et signaler que le numéro est invalide.
|
|
|
|
---
|
|
|
|
### Requirement 2: Authentification et session
|
|
|
|
**User Story:** En tant que mandataire, je veux me connecter de façon sécurisée et rester authentifié, afin d'accéder à mes données en toute confidentialité.
|
|
|
|
> Exigences techniques associées (JWT, durée de session, en-têtes, codes HTTP) : `design-requirements.md`, Requirement 2.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. THE Frontend SHALL proposer un écran de connexion demandant l'Adresse_Email et le Mot_De_Passe.
|
|
2. WHEN le Mandataire soumet des identifiants valides, THE Backend SHALL établir une Session et retourner au Frontend de quoi accéder aux ressources protégées.
|
|
3. IF les identifiants soumis sont invalides, THEN THE Backend SHALL refuser la connexion et retourner un message générique n'indiquant pas lequel de l'Adresse_Email ou du Mot_De_Passe est erroné.
|
|
4. WHILE une Session est active, THE Backend SHALL n'autoriser l'accès aux ressources d'un Mandataire qu'à ce Mandataire authentifié.
|
|
5. WHEN le Mandataire demande à se déconnecter, THE Frontend SHALL mettre fin à la Session côté client et rediriger vers l'écran de connexion.
|
|
6. WHEN le Mandataire coche « Se souvenir de moi » lors d'une connexion réussie, THE Frontend SHALL conserver l'Identifiant_Mémorisé pour pré-remplir l'Adresse_Email lors des visites ultérieures sur ce navigateur, sans jamais conserver le Mot_De_Passe.
|
|
7. WHEN le Mandataire demande une réinitialisation de mot de passe pour une Adresse_Email, THE Backend SHALL générer un Jeton_Reinitialisation à usage unique et à durée de vie limitée et l'envoyer par e-mail, en répondant de façon identique que l'adresse existe ou non.
|
|
8. WHEN le Mandataire soumet un nouveau Mot_De_Passe avec un Jeton_Reinitialisation valide et non expiré, THE Backend SHALL mettre à jour le Mot_De_Passe et invalider le jeton.
|
|
9. IF un Jeton_Reinitialisation est expiré, déjà utilisé ou inconnu, THEN THE Backend SHALL refuser la réinitialisation et signaler que le lien n'est plus valide.
|
|
10. WHILE aucune Session valide n'est présente, THE Frontend SHALL rediriger toute tentative d'accès à une ressource protégée vers l'écran de connexion.
|
|
|
|
---
|
|
|
|
### Requirement 3: Réseaux
|
|
|
|
**User Story:** En tant qu'exploitant, je veux que chaque mandataire soit rattaché à un réseau, afin de cloisonner les hiérarchies et de préparer l'ouverture à d'autres réseaux que IAD.
|
|
|
|
> Exigences techniques associées (référentiel des réseaux, cloisonnement en base) : `design-requirements.md`, Requirement 3.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. THE Backend SHALL maintenir un référentiel de Reseaux ; seuls les Reseaux actifs et initialisés (Onboarding_Reseau effectué) SHALL être proposés à l'inscription.
|
|
2. WHEN un Compte est créé, THE Backend SHALL le rattacher à exactement un Reseau et interdire la modification ultérieure de ce rattachement par le Mandataire.
|
|
3. THE Backend SHALL garantir qu'aucune relation d'Affiliation ne relie deux Mandataires appartenant à des Reseaux différents.
|
|
4. WHEN la Plateforme présente l'Annuaire, l'Arbre_Parrainage ou une Vue_Agregee à un Mandataire, THE Backend SHALL restreindre les données au seul Reseau du Mandataire.
|
|
5. IF aucun Reseau n'est sélectionné à l'inscription (hors Lien_Parrainage), THEN THE Frontend SHALL empêcher la soumission et signaler que le Reseau est obligatoire.
|
|
6. WHEN l'Administrateur réalise l'Onboarding_Reseau d'un nouveau Reseau, THE Backend SHALL initialiser l'espace de données propre à ce Reseau et enregistrer sa Personnalisation_Reseau avant toute inscription.
|
|
7. IF un Mandataire tente de s'inscrire sur un Reseau non actif ou non initialisé, THEN THE Backend SHALL refuser l'inscription et signaler que le Reseau n'est pas disponible.
|
|
8. WHERE un Reseau définit une Personnalisation_Reseau (thème, libellés), THE Frontend SHALL appliquer ce paramétrage par-dessus la présentation commune du socle.
|
|
|
|
---
|
|
|
|
### Requirement 4: Parrainage et hiérarchie
|
|
|
|
**User Story:** En tant que mandataire, je veux déclarer mon parrain et mes filleuls et les inviter à rejoindre la plateforme, afin de reconstituer mon équipe au sein de mon réseau.
|
|
|
|
> Exigences techniques associées (e-mails d'invitation, génération et validité des Liens_Parrainage, états en base) : `design-requirements.md`, Requirement 4.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. THE Frontend SHALL permettre à un Mandataire de déclarer son Parrain (au plus un) et ses Filleuls (plusieurs) au sein de son Reseau, en fournissant pour chaque personne déclarée au minimum son Adresse_Email, servant de clé de Rapprochement_Email.
|
|
2. WHEN un Mandataire déclare un Parrain ou un Filleul non encore inscrit, THE Backend SHALL enregistrer un Membre_Declare correspondant dans l'Arbre_Parrainage du Reseau, sans Compte ni donnée métier associée.
|
|
3. WHEN un Mandataire déclenche une Invitation vers un Parrain ou un Filleul déclaré, THE Backend SHALL envoyer un e-mail contenant un Lien_Parrainage pré-renseignant le Reseau et le lien hiérarchique.
|
|
4. WHEN un destinataire s'inscrit via un Lien_Parrainage, THE Backend SHALL convertir le Membre_Declare correspondant en Compte et établir l'Affiliation à l'état validé.
|
|
5. THE Backend SHALL garantir qu'un Filleul a au plus un Parrain à un instant donné.
|
|
6. IF une déclaration de hiérarchie créerait un cycle dans l'Arbre_Parrainage (un Mandataire devenant ancêtre et descendant d'un autre), THEN THE Backend SHALL refuser la déclaration et signaler l'incohérence.
|
|
7. WHILE une Affiliation reste supposée (Filleul non inscrit ou non confirmée), THE Backend SHALL n'exposer aucune donnée métier du Membre_Declare concerné.
|
|
8. WHEN un Membre_Declare existe pour une Adresse_Email ensuite utilisée pour une inscription (via Rapprochement_Email), THE Backend SHALL rattacher l'inscription au Membre_Declare existant plutôt que d'en créer un doublon.
|
|
9. WHEN un Mandataire déjà inscrit déclare comme Parrain ou Filleul un autre Mandataire déjà inscrit (cas de perte de lien, sans Rapprochement_Email préalable), THE Backend SHALL créer une Affiliation à l'état supposé en attente de Confirmation_Affiliation par la partie concernée.
|
|
10. WHEN la partie concernée approuve une Confirmation_Affiliation, THE Backend SHALL faire passer l'Affiliation à l'état validé et recomposer l'Arbre_Parrainage en conséquence.
|
|
11. IF la partie concernée refuse une Confirmation_Affiliation, THEN THE Backend SHALL ne pas établir le lien et conserver l'état antérieur de l'Arbre_Parrainage.
|
|
|
|
---
|
|
|
|
### Requirement 5: Visibilité hiérarchique descendante
|
|
|
|
**User Story:** En tant que parrain, je veux consulter des informations sur ma descendance (agrégées sur tous les niveaux, détaillées pour mes filleuls directs), afin de suivre et d'accompagner mon équipe, sans que mes filleuls ne voient mes données.
|
|
|
|
> Exigences techniques associées (filtrage des requêtes par périmètre hiérarchique, portée par Module) : `design-requirements.md`, Requirement 5.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. THE Backend SHALL appliquer le principe de Visibilite_Descendante : un Parrain peut consulter des informations de sa Descendance, et aucun Mandataire ne peut consulter les informations d'un de ses ancêtres ou d'un Mandataire d'une autre branche.
|
|
2. WHEN un Parrain consulte une Vue_Agregee, THE Backend SHALL calculer les indicateurs agrégés sur l'ensemble de sa Descendance (tous niveaux) au sein de son Reseau, sans exposer de détail nominatif.
|
|
3. WHEN un Parrain consulte une Vue_Detail_Direct, THE Backend SHALL limiter le détail aux seuls Filleuls_Directs (niveau N+1), dans les limites de portée définies par chaque Module concerné.
|
|
4. IF un Mandataire tente d'accéder à des données hors de son périmètre de Visibilite_Descendante, THEN THE Backend SHALL refuser l'accès.
|
|
5. WHERE un Module ne définit pas de données partageables en consultation hiérarchique, THE Backend SHALL n'exposer aucune donnée de ce Module dans les Vues_Agregees ou Vues_Detail_Direct.
|
|
|
|
> **Note d'évolution** : un paramètre « nombre de niveaux » permettant à un Parrain de limiter la portée de certaines Vues_Agregees est envisagé ultérieurement et n'entre pas dans le périmètre initial.
|
|
|
|
---
|
|
|
|
### Requirement 6: Annuaire des abonnés
|
|
|
|
**User Story:** En tant que mandataire, je veux consulter un annuaire des membres de mon réseau, afin de visualiser l'organisation et de retrouver des contacts.
|
|
|
|
> Exigences techniques associées (champs exposés, recherche, pagination) : `design-requirements.md`, Requirement 6.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. WHEN un Mandataire consulte l'Annuaire, THE Backend SHALL retourner les Mandataires inscrits et les Membres_Declares de son Reseau uniquement.
|
|
2. THE Frontend SHALL distinguer visuellement, dans l'Annuaire, les Mandataires inscrits des Membres_Declares non encore inscrits.
|
|
3. THE Frontend SHALL permettre de rechercher un membre de l'Annuaire par nom, prénom ou Identifiant_Reseau.
|
|
4. THE Backend SHALL n'exposer dans l'Annuaire que des informations d'identification et de contact de niveau annuaire, à l'exclusion de toute donnée métier des Modules.
|
|
5. WHEN un Mandataire visualise son équipe, THE Frontend SHALL présenter l'Arbre_Parrainage de sa Descendance au sein de son Reseau.
|
|
|
|
---
|
|
|
|
### Requirement 7: Abonnements et Packs
|
|
|
|
**User Story:** En tant que mandataire, je veux souscrire une formule d'abonnement, afin de débloquer les modules dont j'ai besoin ; en tant qu'exploitant, je veux financer l'hébergement et la maintenance via des formules payantes.
|
|
|
|
> Exigences techniques associées (modèle de données abonnement, paiement éventuel, codes HTTP) : `design-requirements.md`, Requirement 7.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. THE Backend SHALL proposer exactement trois Packs : Starter (gratuit), Pro et Premium.
|
|
2. THE Backend SHALL garantir qu'un Pack inclut l'ensemble des Modules des Packs de niveau inférieur (Pro inclut Starter ; Premium inclut Pro et Starter).
|
|
3. THE Backend SHALL attribuer par défaut le Pack Starter à tout Compte sans Abonnement payant actif.
|
|
4. WHEN un Mandataire souscrit ou change de Pack, THE Backend SHALL mettre à jour son Abonnement et recalculer la liste de ses Modules_Accessibles.
|
|
5. WHEN une Retrogradation survient (changement vers un Pack inférieur ou expiration d'un Pack payant), THE Backend SHALL conserver l'intégralité des données des Modules devenus inaccessibles.
|
|
6. WHILE un Module n'est plus inclus dans l'Abonnement courant mais contient des données du Mandataire, THE Backend SHALL exposer ce Module en Module_Consultation_Seule (lecture seule), sans permettre de nouvelle saisie ni modification.
|
|
7. THE Backend SHALL garantir qu'un Mandataire a au plus un Abonnement actif à un instant donné.
|
|
8. IF un Mandataire tente une action d'écriture sur un Module_Consultation_Seule, THEN THE Backend SHALL refuser l'action et signaler que le Module nécessite un abonnement de niveau supérieur.
|
|
|
|
---
|
|
|
|
### Requirement 8: Catalogue et activation des Modules
|
|
|
|
**User Story:** En tant que mandataire, je veux n'accéder qu'aux modules compris dans mon abonnement, et voir clairement ceux que je pourrais débloquer, afin de comprendre l'offre.
|
|
|
|
> Exigences techniques associées (contrôle d'accès par Module, référentiel Module→Pack) : `design-requirements.md`, Requirement 8.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. THE Backend SHALL maintenir un Catalogue_Modules associant chaque Module au Pack qui le débloque.
|
|
2. THE Backend SHALL rattacher, au lancement, les Modules suivants aux Packs : Carnet_Adresses, KMS et Facturation au Pack Starter ; CRM et Agenda au Pack Pro.
|
|
3. WHEN le Frontend présente la navigation, THE Frontend SHALL afficher les Modules_Accessibles comme actifs, les Modules_Consultation_Seule comme consultables, et les Modules non souscrits comme proposables à l'abonnement.
|
|
4. WHEN un Mandataire tente d'accéder à un Module non inclus dans son Abonnement et sans données existantes, THE Backend SHALL refuser l'accès fonctionnel et le Frontend SHALL proposer la montée en abonnement correspondante.
|
|
5. THE Backend SHALL vérifier, à chaque appel d'API d'un Module, que le Mandataire dispose du droit d'accès correspondant à son Abonnement (plein accès ou consultation seule).
|
|
|
|
---
|
|
|
|
### Requirement 9: Administration de la Plateforme
|
|
|
|
**User Story:** En tant qu'exploitant SchotzimmO, je veux administrer les comptes, les abonnements et le catalogue des modules, afin de gérer la plateforme et d'en suivre l'activité globale.
|
|
|
|
> Exigences techniques associées (rôle Administrateur, périmètre des droits, statistiques) : `design-requirements.md`, Requirement 9.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. THE Backend SHALL distinguer le rôle Administrateur du rôle Mandataire et réserver les fonctions d'administration au seul Administrateur.
|
|
2. WHEN l'Administrateur consulte la liste des Comptes, THE Backend SHALL retourner les Comptes de tous les Reseaux avec leur Reseau, leur Abonnement et leur statut.
|
|
3. THE Backend SHALL permettre à l'Administrateur de modifier l'Abonnement d'un Compte et de gérer le rattachement des Modules aux Packs dans le Catalogue_Modules.
|
|
4. WHEN l'Administrateur consulte les statistiques globales, THE Backend SHALL retourner des KPI consolidés (ex. nombre de Comptes par Reseau, répartition par Pack) sans exposer de donnée métier individuelle au-delà du nécessaire.
|
|
5. IF un Mandataire non Administrateur tente d'accéder à une fonction d'administration, THEN THE Backend SHALL refuser l'accès.
|
|
6. WHEN un différend ou une incohérence de hiérarchie lui est signalé, THE Backend SHALL permettre à l'Administrateur de corriger l'Arbre_Parrainage d'un Reseau (rattacher, détacher ou réaffecter un Mandataire à un Parrain), dans le respect du cloisonnement par Reseau et de l'interdiction des cycles.
|
|
|
|
---
|
|
|
|
### Requirement 10: Tableau de bord
|
|
|
|
**User Story:** En tant que mandataire, je veux retrouver à l'ouverture mes actions du jour et des indicateurs clés, afin de démarrer ma journée efficacement.
|
|
|
|
> Exigences techniques associées (agrégation inter-modules, rafraîchissement) : `design-requirements.md`, Requirement 10.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. WHEN un Mandataire se connecte, THE Frontend SHALL présenter le Tableau_De_Bord comme écran d'accueil.
|
|
2. THE Tableau_De_Bord SHALL regrouper les actions du jour et des KPI issus des seuls Modules_Accessibles du Mandataire.
|
|
3. WHERE un Module_Accessible fournit des éléments pour le Tableau_De_Bord, THE Frontend SHALL afficher la section correspondante ; WHERE aucun Module ne fournit d'élément, THE Frontend SHALL afficher un état vide explicite.
|
|
4. WHEN le Mandataire sélectionne une action ou un indicateur du Tableau_De_Bord, THE Frontend SHALL le rediriger vers le Module concerné.
|
|
5. THE Backend SHALL ne fournir au Tableau_De_Bord que des données appartenant au Mandataire ou relevant de sa Visibilite_Descendante.
|
|
|
|
---
|
|
|
|
### Requirement 11: Cadre applicatif et navigation
|
|
|
|
**User Story:** En tant que mandataire, je veux une interface cohérente avec une navigation claire entre les modules et l'accès à mon profil, afin d'utiliser la plateforme facilement.
|
|
|
|
> Exigences techniques associées (structure de navigation, avatar, pages de paramétrage) : `design-requirements.md`, Requirement 11.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. THE Frontend SHALL présenter une navigation donnant accès au Tableau_De_Bord, à l'Annuaire et aux Modules selon l'Abonnement du Mandataire.
|
|
2. THE Frontend SHALL afficher un contrôle d'identité (avatar) donnant accès au Profil, au paramétrage, à l'Abonnement et à la déconnexion.
|
|
3. WHEN le Mandataire accède à son Profil, THE Frontend SHALL permettre de consulter et modifier son identité, ses coordonnées et les données transverses, à l'exception du Reseau de rattachement.
|
|
4. THE Frontend SHALL présenter de façon cohérente, sur tous les Modules, l'en-tête, la navigation et les messages d'erreur ou de confirmation.
|
|
5. WHEN un Module n'est pas accessible, THE Frontend SHALL le signaler dans la navigation et proposer, le cas échéant, l'accès en consultation seule ou la montée en abonnement.
|
|
|
|
---
|
|
|
|
### Requirement 12: Persistance et isolation des données par Réseau
|
|
|
|
**User Story:** En tant que mandataire, je veux que mes données soient strictement isolées de celles des autres mandataires, afin de garantir la confidentialité de mon activité.
|
|
|
|
> Exigences techniques associées (cloisonnement par tenant en base MariaDB, index, intégrité) : `design-requirements.md`, Requirement 12.
|
|
|
|
#### Acceptance Criteria
|
|
|
|
1. THE Backend SHALL persister les données métier de chaque Mandataire de manière durable, dans la base de données propre à son Reseau, rattachées à son Compte.
|
|
2. THE Backend SHALL garantir qu'une requête de données d'un Mandataire ne retourne que des données de son propre Reseau lui appartenant ou relevant de sa Visibilite_Descendante, aucune donnée d'un autre Reseau ne pouvant être atteinte.
|
|
3. IF une requête vise des données n'appartenant pas au Mandataire et hors de sa Visibilite_Descendante, THEN THE Backend SHALL refuser l'accès sans divulguer l'existence de ces données.
|
|
4. WHEN une opération d'écriture échoue partiellement, THE Backend SHALL annuler l'intégralité de l'opération et conserver l'état précédent sans modification partielle.
|
|
5. THE Backend SHALL garantir l'isolation des Arbres_Parrainage et des données entre Reseaux distincts.
|
|
6. WHEN un Compte quitte le Reseau (désinscription ou départ), THE Backend SHALL rattacher par défaut sa branche (ses Filleuls_Directs) au Parrain du Compte partant (grand-parrain), en préservant la cohérence de l'Arbre_Parrainage et l'absence de cycle.
|
|
7. WHERE le rattachement par défaut d'une branche ne correspond pas à la réalité du Reseau, THE Backend SHALL permettre aux Mandataires concernés de réorganiser la branche via le mécanisme de déclaration et de Confirmation_Affiliation (auto-gestion), et à l'Administrateur de corriger l'Arbre_Parrainage.
|
|
8. IF le Compte partant n'a pas de Parrain (racine de branche), THEN THE Backend SHALL conserver ses Filleuls_Directs comme nouvelles racines de branche de leur Reseau, sans rattachement ascendant.
|