Sécurité et rôles

Syrcow sépare les droits globaux du SaaS et les droits au niveau de chaque organisation. Le point clé à retenir est simple: un utilisateur peut être puissant au niveau plateforme, mais limité dans une organisation précise, et l'inverse. Cette séparation sert à éviter qu'un compte voit ou modifie des données hors de son périmètre réel.

Rôles globaux

Rôle	Portée	Ce qu'il peut faire	Limites
system	plateforme entière	accès total, administration complète	doit rester réservé au système ou aux comptes de maintenance
admin	plateforme entière	gérer les organisations, les utilisateurs et les paramètres globaux	ne remplace pas automatiquement le rôle métier dans une organisation
manager	supervision opérationnelle	piloter plusieurs organisations et des actions avancées	n'est pas un super-admin de la plateforme
user	usage standard	accès limité aux fonctions autorisées par son organisation	ne doit pas être utilisé pour administrer la plateforme

À quoi servent les rôles globaux

• system sert aux traitements internes, aux migrations et aux maintenances très sensibles.
• admin sert à piloter le SaaS dans son ensemble.
• manager sert à superviser l'activité avec plus de portée qu'un simple utilisateur métier.
• user sert au quotidien quand la personne n'a pas de responsabilité d'administration.

Rôles d'organisation

Rôle	Ce qu'il couvre	Ce qu'il ne couvre pas
admin	administration complète de l'organisation, paramètres, membres, branches et opérations sensibles	ne donne pas automatiquement accès au niveau plateforme
manager	gestion opérationnelle quotidienne, création d'objets métier, suivi des opérations	ne remplace pas un admin de plateforme
agent	exécution des opérations terrain, ventes et saisies minimales	ne peut pas administrer la structure ni valider les actions sensibles
none	aucun rôle effectif dans cette organisation	aucune action métier n'est attendue

À quoi servent les rôles d'organisation

• admin donne la main sur les membres, les paramètres et les opérations critiques de la structure.
• manager permet de suivre et corriger l'activité sans gérer la plateforme entière.
• agent permet d'exécuter le travail de terrain sans risque de toucher à la gouvernance.
• none signifie que l'utilisateur existe mais ne doit pas agir dans cette organisation.

Ce que le code impose vraiment

Les règles sont ensuite appliquées par action, pas seulement par étiquette de rôle.

Action	Rôles autorisés	Limite importante
créer une organisation	system, admin	réservé au niveau plateforme
créer un fournisseur	system, admin	pas ouvert aux rôles de terrain
créer une branche	system, admin	lié à la gouvernance d'organisation
créer un produit	system, admin, manager	le manager doit rester dans le cadre de son organisation
ajouter une dépense	system, admin, manager	dépend du contexte d'organisation actif
approuver une dépense	system, admin, manager global	réservé aux profils les plus élevés
voir la caisse	system, admin, manager	l'accès est plus large que la validation
valider une écriture de caisse	system, admin	la validation est plus stricte que la lecture
outer_sale	system, admin, manager	transaction métier standard
client_sale	agent sur une branche	l'agent doit être rattaché à une branche
approvisioning, inner_sale, inner_request, crates_adjustment	system, admin ou cas très encadrés	réservé aux organisations de type A / contexte admin
create_empty, create_empty_full, create_empty_lost, inner_loan, local_sale	system, admin	pas une opération terrain simple

Comment vérifier qu'un rôle est correct

Quand un utilisateur ne voit pas un bouton ou reçoit un refus:

1. vérifier l'organisation active;
2. vérifier le rôle de l'utilisateur dans cette organisation;
3. vérifier le rôle global si l'action touche la plateforme;
4. vérifier si l'action est réservée à l'administration;
5. relire le message renvoyé par l'API ou l'écran.

Conséquence pratique

Un même utilisateur peut voir plusieurs organisations, mais n'exécute pas les mêmes actions partout. Le rôle doit être vérifié au niveau de l'organisation active, sinon on ouvre des actions au mauvais niveau.

Exemples concrets:

• un manager de plateforme ne peut pas se comporter comme un admin de plateforme pour créer des entités globales
• un agent ne peut faire une vente client que si son organisation active possède une branche
• un admin d'organisation n'est pas automatiquement un super-admin de la plateforme
• les transactions de caisse vide et d'ajustement ne doivent pas être utilisées comme raccourci pour contourner le workflow normal

À surveiller

• les écrans publics login et register
• les routes API protégées
• les actions qui manipulent les transactions ou les quotas
• les permissions sur une organisation active, pas uniquement sur l'utilisateur
• les différences entre lecture, création, validation et suppression
• les écrans d'administration qui ne doivent pas être visibles aux agents