13 — Rôles & permissions¶

Dans un produit où des closers indépendants se partagent des leads et où de l'argent circule, « qui voit quoi » est une fonctionnalité, pas un réglage technique. Un closer ne doit pas voir le portefeuille de son collègue, ni ses leads.

Les rôles¶

Quatre rôles sont assignables dans un workspace, plus un rôle interne à la plateforme :

Rôle	Qui	Portée
Owner (propriétaire)	Le créateur du workspace	Tout, dans son workspace
Admin	Un bras droit	Large — gestion de l'équipe et du contenu
Manager	Un responsable d'équipe	Son équipe : ses closers et leurs opportunités
Closer	Un commercial	Ses propres opportunités
Staff	L'équipe ikloze	Interne à la plateforme, non assignable dans un workspace

Le rôle Staff est réservé à l'exploitation de la plateforme : il ne peut pas être attribué à un membre depuis un workspace client.

L'adhésion : le lien membre ↔ workspace¶

Un utilisateur n'est pas « dans » ikloze : il est membre d'un ou plusieurs workspaces. Son adhésion porte tout ce qui est spécifique à ce workspace :

Élément	Rôle
Rôle	Owner, Admin, Manager ou Closer
Manager	Le responsable hiérarchique du membre — le lien qui structure les équipes
Taux de commission	Son taux dans ce workspace
Permissions accordées	Droits ajoutés à titre individuel
Permissions refusées	Droits retirés à titre individuel

Conséquence produit : une même personne peut être closer à 12 % chez un client et manager à 6 % chez un autre. Les deux contextes ne se mélangent jamais.

Le workspace actif¶

Un utilisateur multi-workspace travaille dans un workspace à la fois — le workspace actif, indiqué à chaque requête. Ses droits, ses leads et ses statistiques sont ceux de ce workspace-là.

Ce contexte n'est jamais mémorisé côté serveur : il est déterminé à chaque requête. Deux onglets ouverts sur deux workspaces différents fonctionnent donc sans interférence.

Le modèle de permissions¶

Des droits nommés¶

Chaque action sensible est adossée à une permission nommée, au format module.action_ressource — par exemple payments.create_payment_link ou withdrawals.review_withdrawal_admin. Le produit en compte une soixantaine, couvrant :

projets · formulaires · leads · opportunités · règles d'affectation · paiements · portefeuilles · retraits · KYC · analytics · membres · groupes · invitations · annonces · missions · réglages de plateforme

Deux permissions couvrent le recrutement sur la marketplace :

Permission	Ce qu'elle autorise
`announcements.manage_announcement`	Écrire, publier et clôturer une annonce ; trier les candidatures reçues
`missions.propose_mission`	Proposer, révoquer et terminer une mission ; déposer un avis sur un closer

Comment un droit est résolu¶

L'utilisateur est-il superutilisateur de la plateforme ?  ──▶ OUI : autorisé
                        │ NON
                        ▼
Est-il propriétaire du workspace actif ?                  ──▶ OUI : autorisé
                        │ NON
                        ▼
Union des permissions de son rôle
   + permissions accordées individuellement
   − permissions refusées individuellement                ──▶ décision

Deux règles structurent ce modèle :

Le refus l'emporte. Une permission explicitement retirée à un membre ne peut pas être ré-accordée par son rôle. C'est le mécanisme qui permet de restreindre un individu sans créer un rôle sur mesure.
Il n'existe pas de droit joker. Les raccourcis superutilisateur et propriétaire sont des règles du code, pas une permission « tout » stockée quelque part. On ne peut donc pas s'attribuer l'omnipotence par erreur de configuration.

Ajuster un membre sans créer un rôle

Ouvrir les analytics de l'équipe à un closer expérimenté ? On lui accorde cette permission sur son adhésion. Interdire à un admin d'annuler des liens de paiement ? On la lui refuse. Pas besoin de multiplier les rôles.

Ce qui n'est pas une permission de workspace

L'argent d'une personne, son identité, ses moyens de paiement et sa vie sur la marketplace ne passent pas par ce modèle : retirer sa commission, soumettre son KYC, enregistrer un compte Mobile Money, publier son profil closer, postuler à une annonce ou répondre à une proposition de mission ne dépend d'aucun rôle et d'aucun workspace. Un workspace n'a pas de titre à bloquer ce qu'un closer a gagné, ni à contrôler s'il cherche ailleurs. Les permissions d'arbitrage correspondantes restent côté plateforme, suffixées _admin (withdrawals.review_withdrawal_admin, kyc.review_kyc_admin).

C'est une nécessité technique autant qu'un principe : un closer entre deux missions n'est membre d'aucun workspace. Un modèle où tout droit découlerait d'une adhésion lui interdirait purement et simplement de chercher une mission.

Le cloisonnement des données¶

Au-delà des permissions, le produit applique un cloisonnement par rôle sur ce que chacun voit. Deux personnes ayant le même droit « voir les liens de paiement » ne voient pas le même périmètre.

Rôle	Périmètre visible
Owner / Admin	Tout le workspace
Manager	Ses propres éléments + ceux des closers qu'il supervise
Closer	Ses propres éléments uniquement

Ce cloisonnement s'applique aux opportunités, aux liens de paiement, aux statistiques, ainsi qu'aux annonces et aux propositions de mission : un manager cloisonné ne voit que les annonces qu'il a écrites, les candidatures qui s'y rattachent et les missions qu'il a proposées.

Deux exceptions assumées côté marketplace :

Terminer une mission active échappe au cloisonnement. Une mission en cours est une relation de tout le workspace ; la réserver à son proposeur laisserait les missions d'un manager parti sans personne pour y mettre fin.
Déposer un avis aussi, et pour la même raison : qui peut engager et rompre un contrat peut dire comment il s'est passé.

Le filtrage est appliqué côté serveur

Le périmètre n'est pas masqué dans l'interface : il est appliqué à la requête en base. Un closer qui tenterait d'accéder directement à l'identifiant d'une opportunité qui n'est pas la sienne obtient une réponse « introuvable » — et non « interdit », ce qui l'empêcherait de déduire l'existence de la ressource.

Les statistiques suivent la même logique, via trois permissions distinctes : voir tout le workspace, voir son équipe, voir soi-même.

Le cycle de vie d'un membre¶

L'invitation¶

Le propriétaire ou un admin invite par email. L'invité peut avoir un compte ikloze ou non : dans les deux cas il reçoit un lien d'invitation, qu'il accepte pour rejoindre le workspace. L'invitation expire et peut être annulée ou renvoyée.

La vie du membre¶

Son rôle, son manager, son taux de commission et ses permissions individuelles sont modifiables à tout moment par qui en a le droit. Un membre peut aussi quitter un workspace de lui-même.

Le départ¶

Quand un membre est retiré, ses opportunités ne sont pas perdues : elles sont réaffectées, et le motif transfer_on_member_removal est inscrit dans l'historique. On sait donc toujours d'où vient un lead réattribué.

Les commissions déjà acquises restent sur son portefeuille : quitter un workspace ne fait pas perdre l'argent gagné.

Si le membre était arrivé par la marketplace, son départ termine automatiquement ses missions en cours — qu'il ait été retiré ou qu'il soit parti de lui-même. Les statuts d'une mission ne peuvent jamais contredire l'appartenance réelle au workspace. Voir 11 — La mission.

La propriété du workspace¶

La propriété est transférable à un autre membre. C'est une opération sensible : elle déplace le raccourci « propriétaire » — donc l'accès total au workspace. Les deux parties sont notifiées.

En résumé¶

Les droits vivent sur l'adhésion, pas sur l'utilisateur — le multi-workspace est natif.
Le refus l'emporte sur l'attribution par rôle.
Le cloisonnement est appliqué en base, pas seulement dans l'interface.
Aucun droit joker : les bypass sont des règles explicites du code.

Détail technique : Architecture › Permissions (RBAC) et Multi-tenant.