Permissions
Comprenez la matrice complete des permissions par role au niveau organisation, workspace et projet.
Siovos Archi utilise un systeme de permissions a trois niveaux : organisation, workspace et projet. Chaque niveau a ses propres roles avec des droits specifiques.
Vue d'ensemble#
Organisation (Owner, Admin, Member)
└── Workspace (Admin, Editor, Viewer)
└── Projet (herite du workspace)Les permissions sont additives : un utilisateur cumule les droits de tous ses roles.
Niveau Organisation#
Roles disponibles#
| Role | Description |
|---|---|
| Owner | Proprietaire de l'organisation, tous les droits |
| Admin | Administrateur, gere les membres et workspaces |
| Member | Membre standard, acces aux workspaces assignes |
Matrice des permissions#
| Action | Owner | Admin | Member |
|---|---|---|---|
| Voir l'organisation | ✅ | ✅ | ✅ |
| Modifier les parametres org | ✅ | ✅ | ❌ |
| Supprimer l'organisation | ✅ | ❌ | ❌ |
| Gerer la facturation | ✅ | ❌ | ❌ |
| Inviter des membres | ✅ | ✅ | ❌ |
| Modifier les roles membres | ✅ | ✅ | ❌ |
| Retirer des membres | ✅ | ✅ | ❌ |
| Creer un workspace | ✅ | ✅ | ❌ |
| Supprimer un workspace | ✅ | ✅ | ❌ |
| Creer une equipe | ✅ | ✅ | ❌ |
| Gerer les equipes | ✅ | ✅ | ❌ |
| Voir les logs d'audit | ✅ | ✅ | ❌ |
Notes importantes#
- Un seul Owner par organisation. Le transfert de propriete est possible dans les parametres.
- Admins multiples possibles. Recommande d'avoir au moins 2 pour la continuite.
- Member est le role par defaut pour les nouvelles invitations.
Niveau Workspace#
Roles disponibles#
| Role | Description |
|---|---|
| Admin | Gestion complete du workspace |
| Editor | Creation et modification des projets |
| Viewer | Consultation uniquement |
Matrice des permissions#
| Action | Admin | Editor | Viewer |
|---|---|---|---|
| Voir le workspace | ✅ | ✅ | ✅ |
| Modifier les parametres | ✅ | ❌ | ❌ |
| Supprimer le workspace | ❌* | ❌ | ❌ |
| Gerer les membres | ✅ | ❌ | ❌ |
| Creer un projet | ✅ | ✅ | ❌ |
| Creer un dossier | ✅ | ✅ | ❌ |
| Voir les projets | ✅ | ✅ | ✅ |
*La suppression d'un workspace necessite d'etre Admin de l'organisation.
Etre Admin d'organisation ne donne pas automatiquement acces aux workspaces. Vous devez etre explicitement ajoute comme membre du workspace.
Niveau Projet#
Les permissions de projet sont heritees du workspace, mais peuvent etre restreintes.
Heritage par defaut#
Un membre avec le role Editor sur le workspace a automatiquement les droits Editor sur tous les projets du workspace.
Acces equipe#
Les equipes peuvent etre assignees a des projets avec des roles specifiques :
| Equipe sur projet | Permissions |
|---|---|
| Admin | Gestion complete du projet |
| Editor | Modification du canvas et des proprietes |
| Viewer | Consultation, commentaires |
Matrice des permissions projet#
| Action | Admin | Editor | Viewer |
|---|---|---|---|
| Voir le projet | ✅ | ✅ | ✅ |
| Modifier le canvas | ✅ | ✅ | ❌ |
| Ajouter/supprimer nodes | ✅ | ✅ | ❌ |
| Modifier les connexions | ✅ | ✅ | ❌ |
| Ajouter des commentaires | ✅ | ✅ | ✅ |
| Resoudre des commentaires | ✅ | ✅ | Siens |
| Gerer les versions | ✅ | ✅ | ❌ |
| Exporter | ✅ | ✅ | ✅ |
| Gerer les parametres | ✅ | ❌ | ❌ |
| Supprimer le projet | ✅ | ❌ | ❌ |
| Gerer les presentations | ✅ | ✅ | ❌ |
| Lancer une presentation | ✅ | ✅ | ✅ |
Mode lecture seule#
Les utilisateurs avec le role Viewer sont en mode lecture seule :
Ce qu'ils peuvent faire#
- Naviguer sur le canvas (pan, zoom)
- Consulter les proprietes des nodes
- Voir les commentaires
- Ajouter des commentaires et reactions
- Lancer des presentations
- Exporter (selon le plan)
Ce qu'ils ne peuvent pas faire#
- Ajouter, deplacer ou supprimer des nodes
- Modifier les connexions
- Changer les proprietes
- Creer des presentations
- Modifier les parametres
Un badge Lecture seule est visible dans le header du projet.
Precedence des permissions#
Quand un utilisateur a plusieurs sources de permissions, la plus elevee s'applique :
Exemple#
Alice est :
- Member de l'organisation
- Editor du workspace "Backend"
- Membre de l'equipe "Architects" qui est Admin sur le projet "API Gateway"
Sur le projet "API Gateway", Alice a les droits Admin (le plus eleve).
Resolution#
Permissions effectives = MAX(
Role workspace,
Role equipe sur projet,
Role individuel sur projet
)Cas particuliers#
Projets dans les dossiers#
Les dossiers n'ont pas de permissions propres. Un projet dans un dossier herite des permissions du workspace.
Linked Projects#
Pour voir le contenu d'un Linked Project, vous devez avoir acces au projet source. Sinon, vous voyez "Acces restreint".
Invitations en attente#
Une invitation non acceptee n'a aucune permission. L'utilisateur doit d'abord accepter.
Bonnes pratiques#
Principe du moindre privilege#
Attribuez le role minimum necessaire :
- Stakeholders → Viewer
- Contributeurs actifs → Editor
- Responsables → Admin
Equipes pour la gestion a echelle#
Plutot que des permissions individuelles, utilisez les equipes :
- Creez des equipes par role fonctionnel
- Assignez les equipes aux projets
- Ajoutez/retirez les membres des equipes
Revue periodique#
Tous les trimestres, verifiez :
- Les permissions sont-elles toujours pertinentes ?
- Des membres ont-ils quitte l'entreprise ?
- Les roles correspondent-ils aux responsabilites actuelles ?
Documentation#
Documentez votre modele de permissions :
- Qui peut acceder a quoi
- Pourquoi ces choix
- Processus pour demander un acces
Prochaines etapes#
- Equipes pour la gestion groupee
- Securite pour 2FA et audit
- Administration pour la vue d'ensemble