Rôles et permissions
La carte d'accès complète — quel rôle est requis pour utiliser chaque produit Scrydon, ce que chaque rôle peut faire sur chaque ressource, comment fonctionne l'accès programmatique (API), et comment l'habilitation des données forme un second axe par-dessus les rôles.
Cette page est la carte d'accès complète : qui peut utiliser quel produit, ce que chaque rôle peut faire sur chaque ressource, comment l'accès programmatique (API) est cadré, et comment l'habilitation des données vient s'ajouter. Pour la mécanique du comment une décision est résolue, voir Modèle de permissions ; cette page traite du quoi.
Les trois axes d'accès
Scrydon sépare l'accès en trois axes indépendants. Une requête n'est autorisée que lorsque les trois axes qui s'appliquent sont d'accord.
| Axe | Répond à | À qui il s'applique | Où il est défini |
|---|---|---|---|
| Identité & rôles | Cette personne peut-elle atteindre cette ressource ? | Chaque utilisateur humain | Appartenance à l'organisation et à l'espace de travail |
| Portées de capacité (scopes) | Que peut faire ce programme via l'API ? | Mini-applications & comptes de service | Portées OAuth à l'enregistrement |
| Habilitation des données | Quels éléments classifiés d'une ressource cet utilisateur peut-il voir ? | Chaque utilisateur humain | Niveau d'habilitation + classification |
Les rôles et l'habilitation sont orthogonaux. Un administrateur d'espace de travail disposant d'un large accès ne peut toujours pas lire un document classifié au-dessus de son habilitation. Inversement, un membre fortement habilité ne peut toujours pas toucher un espace de travail dont il n'est pas membre. L'accès est l'intersection, jamais l'union.
Les rôles en un coup d'œil
Scrydon possède trois niveaux de rôles. Ils ne se recoupent jamais — un admin d'espace de travail n'est pas un admin d'organisation.
Plateforme (opérateur du déploiement)
| Rôle | Responsabilité |
|---|---|
| Super admin | L'opérateur global d'un déploiement Scrydon — le premier utilisateur créé lors de la configuration, plus toute personne dans SUPER_ADMIN_EMAILS ou promue sous Paramètres → Super admin. Automatiquement traité comme administrateur de chaque organisation. Seul un super admin peut créer ou supprimer des organisations. |
Le super admin est un rôle privilégié à l'échelle du déploiement, et non un rôle d'organisation. Dans une installation auto-hébergée à tenant unique, le super admin est l'opérateur. Chaque attribution ou promotion automatique est écrite dans le journal d'audit, et elle est appliquée à la connexion — un super admin nouvellement promu doit se déconnecter et se reconnecter. Voir Administrateurs de la plateforme et usurpation d'identité.
Organisation
Il existe exactement deux rôles d'appartenance à l'organisation — il n'y a pas de niveau « propriétaire » distinct.
| Rôle | Responsabilité |
|---|---|
| Admin | Contrôle total de l'organisation : gérer les membres, les équipes et les espaces de travail ; configurer les intégrations et les droits ; installer et retirer des packs ; modifier les paramètres de l'organisation ; facturation ; gouvernance (DLP, habilitation, aperçus de coûts). Dispose d'un accès en lecture implicite à chaque espace de travail non personnel de l'organisation, à des fins de supervision. |
| Membre | Aucun pouvoir au niveau de l'organisation. N'accède au travail que via une appartenance directe à un espace de travail ou un droit d'équipe. L'accès étant explicite, un simple membre sans appartenance à un espace de travail peut se connecter mais ne voit rien. |
Espace de travail
| Rôle | Responsabilité |
|---|---|
| Propriétaire | Contrôle total de l'espace de travail : renommer, supprimer, transférer, configurer les intégrations et gérer les membres, ainsi que le niveau de paramètres le plus élevé. Attribué automatiquement au créateur de l'espace de travail. |
| Admin | Gérer les paramètres, les membres, les bases de connaissances et les intégrations de l'espace de travail. Tout ce qu'un propriétaire peut faire, sauf le transfert et le niveau de paramètres réservé au propriétaire. |
| Membre | Faire le travail : créer et exécuter des workflows, utiliser Chat, produire de la connaissance, lire les ressources (selon l'habilitation). Ne peut pas gérer les membres ni supprimer l'espace de travail. |
Les rôles d'espace de travail sont accordés directement ou via une équipe. Si un utilisateur hérite de rôles différents de plusieurs équipes sur le même espace de travail, c'est le plus élevé qui l'emporte (propriétaire > admin > membre). Les équipes sont le vecteur du provisionnement IdP / SCIM — voir Modèle de permissions → Droits basés sur les équipes. Un niveau lecteur en lecture seule existe dans le modèle mais n'est pas actuellement attribuable via les flux d'invitation ou d'ajout de membre.
Carte d'accès des produits
Chaque produit requiert un utilisateur authentifié membre de l'organisation. Au-delà de cela, l'accès est cadré comme suit.
| Produit | Ce que c'est | Qui peut l'utiliser | Qui l'administre |
|---|---|---|---|
| Chat (Cortex) | L'assistant IA de l'espace de travail — conversations, connaissance, création d'automatisations par chat | Tout membre d'espace de travail. Chaque membre accepte un consentement d'usage de l'IA une seule fois, à la première utilisation. | Les administrateurs d'organisation disposent de vues de supervision des sujets et conversations. |
| Workflows & Process flows (Automatisations) | Créer et exécuter des workflows agentiques et des process flows avec intervention humaine | Tout membre d'espace de travail crée et exécute les siens ; les administrateurs/propriétaires gèrent les paramètres partagés | Admin / propriétaire d'espace de travail pour les paramètres et intégrations au niveau de l'espace de travail |
| Copilot | L'assistant IA de création intégré à l'éditeur de workflows | Tout membre d'espace de travail | — |
| Analytics | Tables gouvernées, notebooks et graphe d'ontologie | Tout membre d'espace de travail ; les lignes/colonnes visibles sont régies par la classification et le masquage des tables (les tables plus classifiées sont réservées aux administrateurs/propriétaires) | Admin / propriétaire d'espace de travail ; nécessite un stockage objet provisionné pour l'organisation |
| Ontologie | La couche sémantique — types et instances d'objets/liens/actions | Lecture : tout membre d'organisation. Les lectures d'instances sont filtrées par habilitation. | Types créés par les administrateurs d'organisation, les administrateurs/propriétaires d'espace de travail ou le rôle ontology-author (propositions uniquement) |
| Bases de connaissances | Bases de connaissances RAG / Memex et leurs documents | Lecture : membres d'espace de travail, selon l'habilitation du document | Propriétaire de la base de connaissances ou admin / propriétaire d'espace de travail |
| Marketplace & Packs | Installer des packs de contenu (ontologies, workflows, intégrations, connaissance) | Parcourir : tout membre d'organisation | Installer / retirer des packs et gérer les sources de packs : admin d'organisation |
| Intégrations & Connexions | Connecter des comptes fournisseurs et activer des capacités (LLM, STT, stockage, outils…) | Utiliser les intégrations activées : membres d'espace de travail (sous réserve du droit) | Activer les intégrations & gérer les droits : admin d'organisation |
| Horizon (Common Operating Picture) | Vue de connaissance de la situation en direct sur les opérations gouvernées | Tout membre d'espace de travail — mais uniquement lorsque l'indicateur de déploiement est activé. Les données sont filtrées par habilitation pour chaque observateur. | Activé par déploiement via l'indicateur HORIZON_ENABLED (désactivé par défaut) |
| Paramètres (Plateforme) | Plan de contrôle du compte, de l'organisation et de la gouvernance | Paramètres du compte : tout membre | Paramètres de l'organisation, membres, équipes, espaces de travail, facturation et gouvernance (DLP, habilitation, coûts) : admin d'organisation. Exploitation du déploiement : super admin. |
Horizon est désactivé par défaut. Il n'apparaît que lorsqu'un opérateur définit HORIZON_ENABLED=true pour le déploiement. Les fonctionnalités moteur qu'il compose (lectures cartographiques gouvernées, événements opérationnels) restent toujours disponibles pour les packs ; seule la console Horizon est soumise à l'indicateur.
Matrice des permissions par ressource
Voici ce que chaque rôle peut faire sur chaque type de ressource. Sauf mention contraire, un administrateur d'organisation peut faire tout ce qu'un rôle d'espace de travail peut faire, sur tous les espaces de travail non personnels (supervision). L'accès est un refus par défaut : tout ce qui n'est pas accordé ici est refusé.
Contenu des espaces de travail
Workflows, conversations, dossiers, planifications, mémoires, webhooks, process flows, journaux d'exécution, fichiers et tables gérées.
| Action | Qui peut |
|---|---|
| Voir / exécuter | Tout membre d'espace de travail (propriétaire, admin, membre) |
| Créer & modifier | Le créateur/propriétaire de l'élément, ainsi que l'admin / propriétaire d'espace de travail |
| Supprimer | Le créateur/propriétaire de l'élément, ainsi que l'admin / propriétaire d'espace de travail |
Les fichiers autorisent également la lecture par tout membre d'organisation lorsqu'ils sont partagés au niveau de l'organisation ; les écritures au niveau de l'organisation requièrent un administrateur d'organisation.
Bases de connaissances & documents
| Action | Qui peut |
|---|---|
| Lire une base de connaissances | Tout membre d'espace de travail (y compris en lecture seule) ; tout membre d'organisation pour les bases à portée organisation |
| Créer / modifier / supprimer une base de connaissances | Le propriétaire de la base, ou l'admin / propriétaire d'espace de travail ; l'admin d'organisation pour les bases à portée organisation |
| Lire un document | Nécessite un accès en lecture à la base de connaissances et une habilitation ≥ à la classification du document et, si le document est restreint, un droit explicite par document |
| Modifier un document | Nécessite un accès en écriture à la base de connaissances et une habilitation ≥ à la classification du document (pas d'écriture vers le bas) |
Les documents appliquent trois couches à la fois : le rôle (êtes-vous membre de la base de connaissances ?), le besoin d'en connaître (détenez-vous un droit pour un document restreint ?) et l'habilitation (votre niveau est-il suffisant ?). Voir la section « Habilitation des données » ci-dessous.
Ontologie (couche sémantique)
| Ressource | Lecture | Créer / modifier | Notes |
|---|---|---|---|
| Types (objet / lien / action) | Tout membre d'organisation | Admin d'organisation ; admin/propriétaire d'espace de travail (son propre espace) ; le rôle ontology-author sur les branches de proposition | Les types installés par pack sont en lecture seule pour tous, sauf le système |
| Instances (objets / liens) | Membres d'organisation, filtrées par habilitation ; les champs sensibles peuvent être expurgés | Admin d'organisation ; admin/propriétaire d'espace de travail | L'accès inter-organisations est toujours refusé |
| Branches | Tout membre d'organisation | Proposer : tout membre d'organisation. Publier : admin d'organisation/d'espace de travail, ou le rôle ontology-approver | Un approbateur ne peut pas publier sa propre proposition (séparation des tâches) ; la branche main est immuable pour les acteurs non-système |
Modèles & packs
| Ressource | Lecture | Gestion |
|---|---|---|
| Modèles (workflow / process) | Tout membre d'organisation | Admin d'organisation uniquement |
| Catalogue de packs | Tout membre d'organisation | Installer / modifier / retirer : admin d'organisation uniquement |
| Sources de packs (flux gérés par le client) | — | Admin d'organisation uniquement |
Paramètres & administration
| Surface | Lecture | Écriture | Niveau le plus élevé |
|---|---|---|---|
| Paramètres d'espace de travail | Tout membre d'espace de travail | Admin / propriétaire d'espace de travail | Actions réservées au propriétaire (ex. transfert) |
| Paramètres d'organisation | Tout membre d'organisation | Admin d'organisation | Réservé à l'admin d'organisation |
| Opérations d'administration de l'organisation | — | — | Exécuter : admin d'organisation uniquement |
| Droits d'intégration | — | Admin d'organisation uniquement | — |
| Utiliser une intégration | Régi par le droit de l'espace de travail (org-wide / accordé / refusé), et non par le rôle — un admin d'organisation décide quels espaces de travail peuvent utiliser chaque intégration |
Un exemple concret de la règle des paramètres d'espace de travail : enregistrer son propre consentement d'usage de l'IA de Chat est une action personnelle, donc chaque membre peut le faire. Gérer les paramètres de l'espace de travail est une écriture, qui requiert donc un admin ou un propriétaire d'espace de travail.
Accès programmatique (portées API)
Les rôles humains régissent l'interface produit. Les programmes — mini-applications et comptes de service — s'authentifient via OAuth et portent des portées de capacité à la place. C'est un axe totalement distinct de l'administration de l'organisation : un compte de service avec workflows:write peut déclencher des workflows mais ne peut pas inviter un membre d'organisation.
Qui détient les portées
| Principal | Type de délivrance | Comment les portées sont accordées |
|---|---|---|
| Mini-applications | OAuth authorization_code | Un admin d'organisation sélectionne les portées autorisées à l'enregistrement. Le jeton d'un utilisateur ne porte que l'intersection de ce qu'il a consenti et de ce que l'application est autorisée à faire. |
| Comptes de service | OAuth client_credentials | Un admin d'organisation crée le compte (admin d'organisation uniquement) et choisit ses portées. Il échange un identifiant client + secret contre un jeton de courte durée (15 minutes). |
Portées de capacité
Les portées sont de la forme ressource:action, où l'action est read ou write. Une portée write satisfait la portée read correspondante sur la même ressource ; les portées ne franchissent jamais les ressources.
| Ressource | Régit | Surface API à ce jour |
|---|---|---|
workflows | Définitions de workflows, état du canevas, déploiement, déclenchement, résultats d'exécution, catalogues de blocs & modèles | Actif — les routes /api/v1/workflows/*, /blocks, /models |
knowledge | Bases de connaissances, documents, ingestion, recherche sémantique, la couche géo de l'ontologie | Actif — les routes /api/v1/knowledge/* et /ontology/geo |
storage | Téléversement de fichiers et téléchargement pré-signé propres à la mini-application | Actif — les routes /api/v1/storage/* |
tools | Le pont d'outils d'intégration gouverné — découvrir et exécuter les outils d'intégration activés de l'organisation | Actif — les routes /api/v1/tools/* |
logs | Lire les journaux d'exécution des workflows et les instantanés de canevas | Actif (lecture) — les routes /api/v1/logs/* |
capabilities | Exécution directe de capacités IA — LLM, embeddings, reconnaissance vocale, OCR, synthèse vocale, image, vidéo — via un unique point gouverné | Actif — la route /api/v1/capabilities/execute (protégée par capabilities:write) |
chat, templates, tables | Réservé à de futures surfaces API | Vocabulaire réservé — pas encore exercé par une route publique |
Quelles capacités IA une organisation peut réellement exécuter (quel LLM, si l'OCR est activé, la facturation, la DLP) est décidé par le registre d'intégrations et appliqué côté serveur, à chaque appel — jamais par la portée OAuth. capabilities:write est un unique verrou stable ; ajouter une nouvelle capacité IA n'ajoute jamais de nouvelle portée. C'est ce qui maintient la surface programmatique réduite et auditable.
Habilitation des données (le second axe)
Les rôles répondent à pouvez-vous atteindre la ressource. L'habilitation répond à quels éléments classifiés à l'intérieur vous pouvez voir. C'est un contrôle obligatoire — il ne peut être levé par un rôle.
L'échelle d'habilitation
Les documents et enregistrements sont classés sur une échelle à cinq niveaux :
| Niveau | Rang | Signification |
|---|---|---|
| Non classifié | 0 | Accès non restreint |
| Restreint | 1 | Personnel de l'organisation uniquement |
| Confidentiel | 2 | Besoin d'en connaître |
| Secret | 3 | Étroitement contrôlé |
| Très secret | 4 | Strictement cloisonné |
Les libellés affichés dans l'interface dépendent du schéma de classification actif de votre organisation — le schéma commercial par défaut (Public / Interne / Confidentiel / Restreint), OTAN ou UE. Les rangs se comparent de la même manière en dessous. Voir Habilitation de la base de connaissances pour la sélection du schéma.
Comment l'habilitation est décidée
| Source | Résultat |
|---|---|
| Membre d'organisation (par défaut) | Jusqu'à Restreint |
| Admin d'organisation (par défaut) | Jusqu'à Confidentiel |
Droit par utilisateur (user_clearance) | Secret / Très secret — défini depuis une revendication IdP, ou via une intervention admin à quatre yeux (approbation par deux administrateurs, limitée dans le temps) |
L'habilitation n'est pas un indicateur libre par utilisateur qu'un admin peut activer. Par défaut, elle suit le rôle d'organisation ; l'élévation au-dessus de Confidentiel passe par le processus audité user_clearance. Pour donner à quelqu'un un large accès à une habilitation supérieure, promouvez-le — ne distribuez pas un indicateur.
Les règles d'application
Un utilisateur ne peut pas lire un élément dont le rang de classification est supérieur à son rang d'habilitation — quel que soit son rôle d'espace de travail. La recherche et la récupération appliquent ceci comme un filtre invisible, de sorte que les éléments trop classifiés n'apparaissent même jamais dans les résultats ou les décomptes.
Les écritures requièrent toujours une habilitation ≥ à la classification de l'élément, afin qu'un utilisateur habilité ne puisse pas copier un contenu sensible vers un emplacement moins classifié.
Un document peut en outre être restreint, exigeant un droit explicite par document en plus de l'habilitation et de l'appartenance à la base de connaissances.
Les enregistrements d'ontologie porteurs d'étiquettes de protection des données (ex. PII / PHI) sont renvoyés avec ces champs expurgés, sauf si l'appelant détient la capacité correspondante. Les administrateurs d'organisation les détiennent implicitement.
Modes d'application
Une organisation choisit la rigueur d'application de l'habilitation. La détection de fuite est toujours active, quel que soit le mode.
| Mode | Comportement |
|---|---|
| Désactivé | Aucune application ; requiert une exception référencée et limitée dans le temps qui se réactive automatiquement |
| Test avec notifications | Journalisation uniquement ; notifier les administrateurs ; rien n'est bloqué |
| Audit | Journaliser les violations et autoriser l'accès ; émettre des événements d'audit de haute gravité (le mode par défaut d'une nouvelle activation) |
| Application | Bloquer en ligne ; la récupération filtre silencieusement sans divulguer de décompte |
Comment une décision est prise
Authentifier la session (ou le jeton OAuth pour un programme). Pas de session → refusé.
Admin d'organisation ? → accès de supervision. Sinon, rôle d'espace de travail direct ou via équipe. Pas de rôle → refusé. (Voir Modèle de permissions.)
Un moteur de politique central (OPA) décide de l'action précise sur la ressource précise selon les règles ci-dessus. Il est en refus par défaut : si le moteur est injoignable, la décision est par défaut un refus.
Pour les données classifiées, appliquer les règles d'habilitation. Pour les appels API, vérifier la portée de capacité. Chaque attribution et refus est écrit dans le journal d'audit.
Voir aussi
- Modèle de permissions — la hiérarchie de résolution à trois niveaux derrière cette carte.
- Autorisation — le point de décision de politique qui l'applique.
- Administrateurs de la plateforme et usurpation d'identité — super admin vs administrateur d'organisation.
- Habilitation de la base de connaissances — schémas de classification et manière de définir l'habilitation.
- DLP — prévention de la perte de données et expurgation.
- Journal d'audit — chaque attribution et révocation de permission est enregistrée.