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ôlesHiérarchie des rôlesEmplacement réservé pour un visuel, un schéma ou une capture.

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.

Scénarios concrets

Centrale d'achat avec points de vente franchisés

Une centrale d'achat (organisation Type A) donne accès à son catalogue à des points de vente franchisés (organisations Type B).

Personne	Rôle global	Rôle organisation	Actions possibles
Directeur de la centrale	admin	admin (Type A)	tout: gérer les utilisateurs, les produits, les branches, les transactions
Employé centrale	user	agent (Type A)	saisir des inventaires, préparer les commandes, lire le stock
Franchisé	user	manager (Type B)	voir le catalogue, passer des commandes, suivre les livraisons
Vendeur du franchisé	user	agent (Type B)	utiliser l'app en magasin, saisir les ventes, synchroniser

Le franchisé voit uniquement les produits et tarifs que la centrale a partagés. Il ne peut pas accéder aux données des autres franchisés ni aux paramètres de la centrale.

ScénarioRôles dans une centrale + points de venteEmplacement réservé pour un visuel, un schéma ou une capture.

Réseau de magasins multi-sites

Un réseau exploite 5 magasins, chacun est une organisation Type A distincte. Un superviseur régional doit voir les stocks de tous les magasins de sa zone.

Personne	Rôle global	Rôle(s) organisation	Actions possibles
Superviseur région	manager	manager dans chaque magasin de sa zone	lire les stocks et tableaux de bord de tous ses magasins
Directeur de magasin	user	admin (son magasin)	gérer son établissement, créer des branches, des produits
Chef de rayon	user	manager (son magasin)	gérer les opérations quotidiennes de son rayon
Vendeur / caissier	user	agent (son magasin, branche boutique)	faire des ventes depuis la caisse uniquement

Le superviseur ne peut pas modifier les paramètres d'un magasin (rôle manager, pas admin), mais il voit l'activité de tous ses établissements sur un seul tableau de bord.

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
vente externe (outer_sale)	system, admin, manager	transaction métier standard
vente client (client_sale)	agent sur une branche	l'agent doit être rattaché à une branche
entrée fournisseur, vente interne, demande interne, ajustement de caisses	system, admin ou cas très encadrés	réservé aux organisations de type A / contexte admin
création de vides, prêt interne, vente locale	system, admin	pas une opération terrain simple

Audit et traçabilité

Chaque action sensible est enregistrée dans l'historique d'audit:

Information tracée	Détail
Qui	identifiant de l'utilisateur + rôle au moment de l'action
Quoi	type d'action (création, modification, validation, suppression)
Où	organisation et branche actives
Quand	horodatage précis
Contexte	session, appareil (si disponible)

L'audit permet de remonter à l'origine d'une modification sans supposer la bonne foi: on sait exactement qui a fait quoi, dans quel contexte et à quel moment.

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
• un utilisateur avec rôle none dans une organisation ne peut rien y faire, même s'il est admin global

À 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

À lire ensuite

• Concepts métier — comprendre Type A et Type B
• Création d'organisation — configurer les rôles au départ
• Guide: rôles et limites — ce que chaque profil peut faire dans l'application