Permissions
Comprenez la matrice complète des permissions par rôle au niveau organisation, workspace et projet.
Siovos Archi utilise un système de permissions à trois niveaux : organisation, workspace et projet. Chaque niveau a ses propres rôles avec des droits spécifiques.
Vue d'ensemble#
Les permissions se résolvent au niveau le plus élevé : quand un utilisateur a plusieurs sources de droits (organisation, workspace, équipe), c'est la plus permissive qui s'applique.
Niveau Organisation#
Rôles disponibles#
| Rôle | Description |
|---|---|
| Owner | Propriétaire de l'organisation, tous les droits |
| Admin | Administrateur, gère les membres et workspaces |
| Member | Membre standard, accès aux workspaces assignés |
Matrice des permissions#
| Action | Owner | Admin | Member |
|---|---|---|---|
| Accéder à l'organisation | ✅ | ✅ | ✅ |
| Modifier les paramètres org | ✅ | ✅ | ❌ |
| Supprimer l'organisation | ✅ | ❌ | ❌ |
| Gérer la facturation | ✅ | ❌ | ❌ |
| Inviter des membres | ✅ | ✅ | ❌ |
| Modifier les rôles membres | ✅ | ✅ | ❌ |
| Retirer des membres | ✅ | ✅ | ❌ |
| Créer un workspace | ✅ | ✅ | ❌ |
| Supprimer un workspace | ✅ | ✅ | ❌ |
| Créer une équipe | ✅ | ✅ | ❌ |
| Gérer les équipes | ✅ | ✅ | ❌ |
| Voir les logs d'audit | ✅ | ✅ | ❌ |
Notes importantes#
- Plusieurs Owners possibles. Seul un Owner peut promouvoir un autre membre Owner ; le dernier Owner ne peut pas être rétrogradé, ce qui garantit la continuité d'accès.
- Admins multiples possibles. Recommandé d'avoir au moins 2 pour la continuité.
- Member est le rôle par défaut pour les nouvelles invitations.
Niveau Workspace#
Rôles disponibles#
| Rôle | Description |
|---|---|
| Admin | Gestion complète du workspace |
| Editor | Création et modification des projets |
| Viewer | Consultation uniquement |
Matrice des permissions#
| Action | Admin | Editor | Viewer |
|---|---|---|---|
| Voir le workspace | ✅ | ✅ | ✅ |
| Modifier les paramètres | ✅ | ❌ | ❌ |
| Supprimer le workspace | ❌* | ❌ | ❌ |
| Gérer les membres | ✅ | ❌ | ❌ |
| Créer un projet | ✅ | ✅ | ❌ |
| Créer un dossier | ✅ | ✅ | ❌ |
| Voir les projets | ✅ | ✅ | ✅ |
*La suppression d'un workspace nécessite d'être Admin de l'organisation.
Être Admin d'organisation ne donne pas automatiquement accès aux workspaces. Vous devez être explicitement ajouté comme membre du workspace.
Niveau Projet#
Les permissions de projet sont héritées du workspace, mais peuvent être restreintes.
Héritage par défaut#
Un membre avec le rôle Editor sur le workspace a automatiquement les droits Editor sur tous les projets du workspace.
Accès équipe#
Les équipes peuvent être assignées à des projets avec des rôles spécifiques :
| Équipe sur projet | Permissions |
|---|---|
| Admin | Gestion complète du projet |
| Editor | Modification du canvas et des propriétés |
| 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 | ✅ | ✅ | ✅ |
| Résoudre des commentaires | ✅ | ✅ | Siens |
| Gérer les versions | ✅ | ✅ | ❌ |
| Exporter | ✅ | ✅ | ✅ |
| Gérer les paramètres | ✅ | ❌ | ❌ |
| Supprimer le projet | ✅ | ❌ | ❌ |
| Gérer les présentations | ✅ | ✅ | ❌ |
| Lancer une présentation | ✅ | ✅ | ✅ |
Mode lecture seule#
Les utilisateurs avec le rôle Viewer sont en mode lecture seule :
Ce qu'ils peuvent faire#
- Naviguer sur le canvas (pan, zoom)
- Consulter les propriétés des nodes
- Voir les commentaires
- Ajouter des commentaires et réactions
- Lancer des présentations
- Exporter (selon le plan)
Ce qu'ils ne peuvent pas faire#
- Ajouter, déplacer ou supprimer des nodes
- Modifier les connexions
- Changer les propriétés
- Créer des présentations
- Modifier les paramètres
Un badge Lecture seule est visible dans le header du projet.
Précédence des permissions#
Quand un utilisateur a plusieurs sources de permissions, la plus élevée s'applique :
Exemple#
Alice est :
- Member de l'organisation
- Editor du workspace "Backend"
- Membre de l'équipe "Architects" qui est Admin sur le projet "API Gateway"
Sur le projet "API Gateway", Alice a les droits Admin (le plus élevé).
Résolution#
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 hérite des permissions du workspace.
Linked Projects#
Pour voir le contenu d'un Linked Project, vous devez avoir accès au projet source. Sinon, vous voyez "Accès restreint".
Invitations en attente#
Une invitation non acceptée n'a aucune permission. L'utilisateur doit d'abord accepter.
Bonnes pratiques#
Principe du moindre privilege#
Attribuez le rôle minimum nécessaire :
- Stakeholders → Viewer
- Contributeurs actifs → Editor
- Responsables → Admin
Équipes pour la gestion à échelle#
Plutôt que des permissions individuelles, utilisez les équipes :
- Créez des équipes par rôle fonctionnel
- Assignez les équipes aux projets
- Ajoutez/retirez les membres des équipes
Revue periodique#
Tous les trimestres, vérifiez :
- Les permissions sont-elles toujours pertinentes ?
- Des membres ont-ils quitte l'entreprise ?
- Les rôles correspondent-ils aux responsabilités actuelles ?
Documentation#
Documentez votre modèle de permissions :
- Qui peut accéder à quoi
- Pourquoi ces choix
- Processus pour demander un accès
Prochaines étapes#
- Équipes pour la gestion groupée
- Sécurité pour 2FA et audit
- Administration pour la vue d'ensemble