Les plateformes d’automatisation IA manipulent des données sensibles et des workflows critiques. Des fiches clients circulent dans les étapes de Recipes. Des rapports financiers sont générés et distribués. Des communications internes sont rédigées et envoyées. Le modèle de contrôle d’accès doit être à la hauteur des enjeux.
« Admin ou Utilisateur » ne suffit pas. Vous avez besoin d’un responsable conformité qui peut lire les journaux d’audit mais ne peut rien exécuter. Vous avez besoin de responsables de département qui gèrent les automatisations de leur équipe mais ne peuvent pas toucher à celles des autres départements. Vous avez besoin de limites claires qui correspondent à votre organigramme, pas d’un simple interrupteur binaire.
Cet article couvre le système RBAC de JieGou : la hiérarchie à 6 rôles, les 26 permissions granulaires, les surcharges par département et le mécanisme d’application qui s’exécute à chaque appel API.
La hiérarchie à 6 rôles
Chaque utilisateur dans JieGou a un rôle global — un niveau numérique unique qui détermine ses permissions de base sur l’ensemble du compte.
| Rôle | Niveau | Objectif |
|---|---|---|
| Owner | 50 | Créateur du compte. Accès complet incluant la suppression du compte. |
| Admin | 40 | Gestion complète : facturation, utilisateurs, clés API, analytics inter-départements. |
| Dept Lead | 30 | Responsable de département. Modifier/supprimer tout contenu dans ses départements. Installer des packs. Promouvoir des workflows. |
| Member | 20 | Utilisateur standard. Créer du contenu, modifier le sien, exécuter des Recipes/workflows, gérer les plannings. |
| Auditor | 15 | Accès en lecture seule aux journaux d’audit, analytics, gouvernance. Ne peut pas créer ni exécuter. |
| Viewer | 10 | Accès en lecture seule au contenu. Ne peut rien exécuter. |
Les niveaux numériques ne sont pas arbitraires. Ils permettent des vérifications de permissions en O(1) — au lieu de parcourir des listes de rôles, le système compare deux entiers. Une permission nécessite un niveau minimum, et l’utilisateur l’atteint ou non.
Le rôle Auditor
Auditor est l’ajout le plus récent, conçu spécifiquement pour la conformité. Il se situe entre Viewer (10) et Member (20) au niveau 15.
La différence clé avec Viewer : les Auditors obtiennent la permission audit:read. Ils peuvent accéder aux journaux d’audit, aux tableaux de bord analytics et aux rapports de gouvernance. Les Viewers ne le peuvent pas.
La différence clé avec Member : les Auditors ne peuvent pas créer de contenu, exécuter des Recipes, lancer des workflows ou gérer des plannings. Ils observent et rapportent. Rien d’autre.
C’est important pour les industries réglementées. Votre responsable conformité doit vérifier que les workflows respectent les politiques, que le traitement des données répond aux exigences, et que l’activité des utilisateurs s’aligne sur votre cadre de gouvernance. Il ne devrait pas avoir besoin — et ne devrait pas avoir — la capacité de modifier ou d’exécuter quoi que ce soit.
Les Auditors sont disponibles dans le mapping SSO groupe-vers-rôle, ce qui vous permet de provisionner automatiquement les responsables conformité depuis votre IdP. Mappez votre groupe compliance-team ou internal-audit au rôle Auditor, et les nouvelles recrues de ces groupes obtiennent le bon accès dès leur première connexion. Aucune assignation manuelle de rôle requise.
26 permissions réparties en 8 catégories
Les rôles sont un raccourci. Les permissions sont ce qui est réellement vérifié. JieGou définit 26 permissions granulaires organisées en 8 catégories :
Compte (4 permissions)
| Permission | Rôle min. | Description |
|---|---|---|
account:delete | Owner | Supprimer l’ensemble du compte |
account:admin | Admin | Actions administratives (config SSO, paramètres du compte) |
account:settings | Admin | Gérer les paramètres au niveau du compte |
account:billing | Admin | Gérer la facturation et l’abonnement |
Utilisateurs (2 permissions)
| Permission | Rôle min. | Description |
|---|---|---|
users:manage | Admin | Gérer tous les utilisateurs du compte |
users:manage-department | Dept Lead | Gérer les utilisateurs de son département |
Contenu (6 permissions)
| Permission | Rôle min. | Description |
|---|---|---|
content:create | Member | Créer de nouvelles Recipes, workflows, documents |
content:edit-own | Member | Modifier le contenu que vous avez créé |
content:edit | Dept Lead | Modifier le contenu de votre département |
content:edit-any | Admin | Modifier tout contenu de tous les départements |
content:delete-any | Admin | Supprimer tout contenu de tous les départements |
content:read | Viewer | Lire le contenu (Recipes, workflows, documents) |
Exécution (3 permissions)
| Permission | Rôle min. | Description |
|---|---|---|
execution:run | Member | Exécuter des Recipes et workflows |
execution:schedules | Member | Créer et gérer des exécutions planifiées |
execution:triggers | Member | Configurer des déclencheurs événementiels |
Analytics (2 permissions)
| Permission | Rôle min. | Description |
|---|---|---|
analytics:read-department | Auditor | Lire les analytics de son département |
analytics:read-all | Admin | Lire les analytics de tous les départements |
Fonctionnalités (4 permissions)
| Permission | Rôle min. | Description |
|---|---|---|
features:chat | Member | Utiliser l’interface de chat IA |
features:documents | Member | Gérer les documents de la base de connaissances |
features:packs | Dept Lead | Installer et gérer les packs de département |
features:connectors | Admin | Configurer les connecteurs MCP et intégrations |
Gouvernance (3 permissions)
| Permission | Rôle min. | Description |
|---|---|---|
governance:audit | Auditor | Lire les journaux d’audit et rapports de gouvernance |
governance:environments | Dept Lead | Gérer les environnements de déploiement |
governance:promote | Dept Lead | Promouvoir les workflows entre environnements |
Sécurité (2 permissions)
| Permission | Rôle min. | Description |
|---|---|---|
security:byok | Admin | Gérer les clés API Bring Your Own Key |
security:embedded-api | Admin | Configurer l’API embarquée |
Le mapping des rôles vers les permissions est statique. Un Dept Lead (niveau 30) a automatiquement chaque permission dont le rôle minimum est 30 ou inférieur. Pas de surcharges de permissions par utilisateur, pas de définitions de rôles personnalisés. Cela maintient le modèle auditable — vous pouvez regarder le rôle d’un utilisateur et savoir exactement ce qu’il peut et ne peut pas faire.
Surcharges de rôle par département
Un rôle global s’applique partout. Mais les organisations ne sont pas plates. Un product manager pourrait avoir besoin d’un accès Member globalement mais d’un accès Dept Lead dans le département Product pour gérer les automatisations de son équipe.
Les surcharges par département résolvent ce problème. Un utilisateur a un rôle global, plus zéro ou plusieurs surcharges de rôle spécifiques à un département.
Exemple : Sarah est Member globalement. Elle a une surcharge Dept Lead dans le département Sales. Dans Sales, elle peut modifier tout le contenu, installer des packs et promouvoir des workflows. Dans Engineering, elle est une Member standard — elle ne peut modifier que son propre contenu.
Le principe de conception critique : les surcharges ne peuvent qu’élever, jamais réduire. Si vous êtes un Admin global avec une surcharge Viewer dans Engineering, votre rôle effectif dans Engineering reste Admin. La surcharge est ignorée car elle réduirait l’accès. Cela empêche une surcharge mal configurée de verrouiller accidentellement quelqu’un hors d’un département auquel il devrait avoir accès.
Résolution du rôle effectif
Lorsque le système a besoin de déterminer ce qu’un utilisateur peut faire dans un département spécifique, il exécute cette résolution :
- Vérifier si une surcharge de département existe pour cet utilisateur dans ce département
- Si une surcharge existe, renvoyer le plus élevé du rôle global et de la surcharge
- Si aucune surcharge n’existe, renvoyer le rôle global
En pseudocode :
effectiveRole(user, department):
override = getDepartmentOverride(user, department)
if override exists:
return max(user.globalRole, override.role)
return user.globalRoleLes vérifications de permissions par département utilisent ce rôle effectif. Lorsque Sarah tente d’installer un pack dans Sales, le système résout son rôle effectif dans Sales (Dept Lead, niveau 30), vérifie le niveau minimum pour features:packs (30), et accorde l’accès. Lorsqu’elle tente la même chose dans Engineering, son rôle effectif est Member (20), ce qui est inférieur au niveau requis.
Règles anti-escalade
Les changements de rôle sont l’opération la plus sensible en matière de sécurité dans le système. Quatre règles empêchent l’escalade de privilèges :
-
Vous ne pouvez pas changer votre propre rôle. Pas d’auto-promotion. Un admin qui veut devenir Owner a besoin qu’un autre Owner effectue le changement.
-
Vous ne pouvez pas attribuer le rôle Owner. Le transfert de propriété est une opération séparée et délibérée avec ses propres protections. Elle ne passe pas par l’API standard de changement de rôle.
-
Vous ne pouvez pas attribuer un rôle supérieur ou égal au vôtre (sauf si vous êtes le Owner). Un Admin (40) peut attribuer Dept Lead (30), Member (20), Auditor (15) ou Viewer (10). Il ne peut pas attribuer Admin (40) ou Owner (50). Seul le Owner peut créer d’autres Admins.
-
Vous ne pouvez pas changer le rôle de quelqu’un dont le rôle est supérieur ou égal au vôtre (sauf si vous êtes le Owner). Un Admin ne peut pas modifier le rôle d’un autre Admin. Un Dept Lead ne peut pas modifier le rôle d’un Admin. La hiérarchie est strictement appliquée vers le haut.
Ces règles se composent proprement. Combinées, elles garantissent qu’aucun utilisateur ne peut escalader ses propres privilèges ou ceux de ses pairs — seul le Owner échappe à cette contrainte.
Comment les permissions sont appliquées
Chaque route API dans JieGou passe par un auth guard en trois étapes avant d’exécuter toute logique métier :
Étape 1 : Vérifier le cookie de session. Le token de session du cookie HTTP est validé auprès de Firebase Auth. Le résultat est mis en cache dans Redis avec un TTL de 5 minutes, de sorte que les requêtes répétées de la même session n’interrogent pas Firebase Auth à chaque appel.
Étape 2 : Rechercher l’enregistrement AccountUser. L’appartenance au compte de l’utilisateur — incluant son rôle global et ses surcharges de département — est récupérée depuis Firestore. C’est également mis en cache dans Redis avec un TTL de 5 minutes.
Étape 3 : Vérifier la permission contre la hiérarchie de rôles. La permission requise est mappée à son niveau de rôle minimum. Le rôle effectif de l’utilisateur (tenant compte des surcharges de département si la vérification est scopée par département) est comparé à celui-ci. C’est en O(1) — une seule recherche de hash pour trouver le niveau minimum, plus une comparaison numérique.
Aucune requête base de données au moment de la vérification des permissions. Aucune itération à travers des listes de permissions. Deux recherches en cache et une comparaison d’entiers.
Vérifications au niveau des ressources
Au-delà des permissions basées sur les rôles, les ressources individuelles (Recipes, workflows, documents) ont des règles d’accès basées sur la propriété :
- Owner, Admin, Dept Lead — peuvent modifier toute ressource dans leur périmètre
- Member — ne peut modifier que les ressources qu’il a créées
- Auditor, Viewer — ne peuvent modifier aucune ressource
Cela se combine avec les permissions au niveau des rôles. Un Member avec content:edit-own ne peut modifier que les ressources où resource.createdBy === user.id. Un Dept Lead avec content:edit peut modifier toute ressource de son département quel qu’en soit le créateur.
Intégration avec les fonctionnalités de la plateforme
Le RBAC n’est pas isolé — il se connecte à chaque sous-système majeur de la plateforme :
Portes d’approbation. L’éligibilité à l’approbation respecte la hiérarchie de rôles. Vous pouvez configurer une étape d’approbation pour exiger un rôle minimum — par exemple, seuls les Dept Lead ou supérieurs peuvent approuver les sorties de workflow avant leur mise en production.
Visibilité des exécutions. Les exécutions de workflow ont 4 périmètres de visibilité : private (uniquement l’exécuteur), department (toute personne du même département), group (groupes spécifiés) et account (tout le monde). Le RBAC détermine qui peut voir les résultats d’exécution et qui ne le peut pas.
Promotion d’environnement. Différents environnements (développement, staging, production) peuvent exiger différents rôles minimum. Le développement pourrait autoriser la promotion au niveau Member. La production pourrait exiger Admin. Le RBAC contrôle chaque transition.
Reporting de gouvernance. Le tableau de bord de gouvernance affiche la distribution des rôles à travers le compte, le nombre de ressources accessibles par utilisateur et l’utilisation des permissions. Les Auditors peuvent consulter ces données pour s’assurer que les patterns d’accès correspondent à la politique.
Disponibilité
Le RBAC est disponible sur tous les plans. Chaque compte JieGou bénéficie de la hiérarchie complète à 6 rôles et des 26 permissions. Les surcharges par département et le rôle Auditor sont disponibles sur les plans Team et Enterprise. Explorer toutes les fonctionnalités ou démarrer un essai gratuit.