Référence de contrôle d'accès

Capgo utilise le contrôle d'accès basé sur le rôle (RBAC) pour gérer ce que chaque membre de l'équipe peut faire. Les rôles sont organisés par portée — de l'organisation entière jusqu'à un seul paquet.

Pour une présentation visuelle de la gestion des membres dans le tableau de bord, voir Organisation.

---

Étendues de rôle

Chaque rôle appartient à une étendue qui détermine les ressources auxquelles il accorde accès.

Étendue	S'applique à	Exemple d'utilisation
Organisation	Toute l'org et tous ses applications	Votre co-fondateur obtient Super Administrateur ; votre comptable obtient Gestionnaire de factures
Application	Une seule application et ses canaux	Un prestataire travaillant sur une seule application obtient le rôle d'App Developer
Canaux	Un canal unique au sein d'une application	Un ingénieur QA ne gère que le staging canaux
Bundle	Une version de bundle unique	Un réviseur a besoin d'accès en lecture à une version de release spécifique

Un membre peut tenir un rôle par cible de portée — par exemple, un rôle d'organisation, un rôle sur l'application A et un rôle différent sur l'application B.

---

Rôles d'organisation

Ces rôles sont attribués lors de l'invitation d'un membre. Ils accordent accès à l'ensemble de l'organisation.

Rôle	Nom interne	Description
Administrateur principal	org_super_admin	Équivalent propriétaire. Contrôle total, y compris la suppression de l'org, la gestion des factures et le transfert d'applications. Attribué automatiquement au créateur de l'org.
Administrateur	org_admin	Gestion totale — gérer les membres, les applications, les canaux. Impossible de supprimer l'org, de mettre à jour les factures, de transférer les applications ou de promouvoir les utilisateurs à Administrateur principal.
Gestionnaire des factures	org_billing_admin	Accès aux factures uniquement : afficher et mettre à jour les informations de facturation, les factures et les journaux de comptes de facturation. Pas d'accès aux applications ou aux membres.
Membre	org_member	Accès en lecture seule à l'org et à tous ses apps.

Matrice de permissions de l'organisation

Permission	Description	Super Administrateur	Administrateur	Gestionnaire de facturation	Membre
org.read	Voir l'organisation	✅	✅	✅	✅
org.update_settings	Modifier le nom, le logo et l'adresse e-mail de gestion de l'org	✅	✅	❌	❌
org.delete	Supprimer définitivement l'organisation	✅	❌	❌	❌
org.read_members	Afficher la liste des membres	✅	✅	❌	✅
org.invite_user	Inviter de nouveaux membres	✅	✅	❌	❌
org.update_user_roles	Changer les rôles des membres (l'administrateur ne peut pas promouvoir à Super Administrateur — bloqué par la hiérarchie des rôles)	✅	✅	❌	❌
org.read_billing	Afficher les informations de facturation et le plan actuel	✅	✅	✅	❌
org.update_billing	Mettre à jour le moyen de paiement et le plan	✅	❌	✅	❌
org.read_invoices	Afficher les factures	✅	✅	✅	❌
org.read_audit	Afficher l'activité de l'organisation	✅	✅	❌	❌
org.read_billing_audit	Afficher le journal d'audit spécifique à la facturation	✅	✅	✅	❌

Note

Les rôles de l'organisation héritent de toutes les permissions de l'application, du canal et du bundle situés en dessous d'eux dans la hiérarchie. Administrateur principal peut faire tout ce que peut faire un Administrateur d'application ou Administrateur de canal peut faire, sur tous les applications et les canaux.

---

Rôles d'application

Limité à une seule application. Utilisez-les lorsque l'un de vos membres d'équipe devrait travailler uniquement sur une application, et non sur toute l'organisation.

Rôle	Nom interne	Description
Admin d'application	app_admin	Contrôle total d'une application — canaux, appareils, rôles d'utilisateur pour l'application. Impossible de supprimer ou de transférer l'application (ce sont des opérations au niveau de l'organisation).
Développeur d'application	app_developer	Charger des bundles, gérer des appareils, déclencher des builds natives, mettre à jour les paramètres de canal. Pas de suppression, pas de modifications des paramètres de l'application, pas de création de canal.
Téléchargeur d'application	app_uploader	Accès en lecture + télécharger de nouvelles versions de bundles.
Lecteur d'application	app_reader	Lecture seule — statistiques, bundles, canaux, journaux, appareils.

Matrice de permissions d'application

Permission	Description	App Admin	Administrateur d'app	App Developer	Développeur d'app
app.read	App Uploader	✅	✅	✅	✅
app.update_settings	Chargeur d'app	✅	❌	❌	❌
app.read_bundles	App Reader	✅	✅	✅	✅
app.upload_bundle	Lecteur d'app	✅	✅	✅	❌
app.create_channel	View app details, stats, et métadonnées	✅	❌	❌	❌
app.read_channels	Voir les détails, statistiques et métadonnées de l'app	✅	✅	✅	✅
app.read_logs	Edit app settings	✅	✅	✅	✅
app.manage_devices	Éditer les paramètres de l'app	✅	✅	❌	❌
app.read_devices	Voir la liste des appareils	✅	✅	✅	✅
app.build_native	Déclencher une construction cloud native	✅	✅	❌	❌
app.read_audit	Voir le journal d'activité de l'application	✅	✅	✅	✅
app.update_user_roles	Gérer les affectations de rôle à l'échelle de l'application	✅	❌	❌	❌
bundle.delete	Supprimer un bundle	✅	❌	❌	❌

Note

app.delete et app.transfer sont opérations à l'échelle d'organisation — uniquement org_super_admin peuvent les effectuer, quel que soit le rôle à l'échelle de l'application.

---

Rôles de canal

Limité à un seul canal. Utile pour accorder un accès ciblé à un canal de publication spécifique.

Note

Les rôles de canal sont actuellement disponibles via API et CLI seulement — il n'y a pas d'interface utilisateur pour les affecter dans l'interface de dashboard. Dans l'interface de dashboard, utilisez les réglages de permission de canal au lieu de les rôles de canal pour affiner l'accès par utilisateur.

Rôle	Nom interne	Description
Administrateur de canal	channel_admin	Contrôle total d'un canal : paramètres, promotion/retour en arrière de lots, gestion de dispositifs forcés.
Voyant de canal	channel_reader	Lecture seule — lot actuel, historique, dispositifs forcés, journal d'audit.

Matrice de permissions de canal

Permission	Description	Administrateur de canal	Voyant de canal
channel.read	Afficher le canal et son lot actuel	✅	✅
channel.update_settings	Éditez les paramètres du canal (télécommandes de plateforme, politique d'actualisation…)	✅	❌
channel.delete	Supprimer le canal	✅	❌
channel.read_history	Afficher l'historique d'affectation du bundle	✅	✅
channel.promote_bundle	Définir le bundle actif sur le canal	✅	❌
channel.rollback_bundle	Revenir à un bundle précédent	✅	❌
channel.manage_forced_devices	Forcer des appareils spécifiques à ce canal	✅	❌
channel.read_forced_devices	Afficher la liste des appareils forcés	✅	✅
channel.read_audit	Afficher le journal d'activité du canal	✅	✅

---

Rôles du bundle

Restreint à une seule version du bundle. Rarement nécessaire — la plupart des équipes utilisent des rôles d'application au lieu de cela.

Note

Les rôles de bundle sont actuellement disponibles via API et CLI seulement — il n'y a pas d'interface utilisateur pour les affecter dans le tableau de bord.

Rôle	Nom interne	Description
Administrateur de bundle	bundle_admin	Lecture, mise à jour des métadonnées et suppression d'un bundle spécifique.
Voyant de bundle	bundle_reader	Accès en lecture seule à un bundle spécifique.

---

Surcharge des permissions de canal (Tableau de bord)

Dans le tableau de bord, l'accès au canal est déterminé par le rôle de l'application de l'utilisateur par défaut. Pour un contrôle plus granulaire, vous pouvez surpasser les permissions de canal spécifiques par utilisateur ou groupe sans modifier leur rôle d'application.

Les survolages sont configurés à partir de l'onglet Accès du tableau de bord en cliquant sur le bouton de permissions de canal (icône bouclier) à côté d'un utilisateur. Voir Organisation — Survol des permissions de canal pour un guide visuel.

Permissions survolables

Permission	Description	Comportement par défaut
Lire	Afficher le canal et son bundle actuel	Hérité du rôle d'application
Historique	Afficher l'historique des affectations de bundle	Hérité du rôle d'application
Associer un bundle	Définir ou modifier le bundle actif sur le canal	Hérité du rôle d'application

Chaque permission peut être définie sur :

• Default — hérite des rôles de l'application (par défaut)
• Allow — accorde explicitement, quel que soit le rôle de l'application
• Deny — bloque explicitement, quel que soit le rôle de l'application

Cela vous permet, par exemple, de donner à un lecteur d'applications la possibilité d'associer des lots sur le staging canal sans les promouvoir en développeur d'applications.

---

Hiérarchie des rôles

Les rôles forment une hiérarchie. Un rôle parent hérite de tous les droits de ses enfants. Cela signifie que org_admin peut faire tout ce que app_admin peut, ce qui à son tour peut faire tout ce que channel_admin peut, et ainsi de suite.

Super Admin (org_super_admin)
  └── Admin (org_admin)
        └── App Admin (app_admin)
              ├── App Developer (app_developer)
              │     └── App Uploader (app_uploader)
              │           └── App Reader (app_reader)
              ├── Bundle Admin (bundle_admin)
              │     └── Bundle Viewer (bundle_reader)
              └── Channel Admin (channel_admin)
                    └── Channel Viewer (channel_reader)

Comment ça marche en pratique:

• Un Administrateur au niveau de l'organe peut faire tout ce que Administrateur d'application peut, sur chaque application dans l'organe.
• Un App Admin peut faire tout ce que peut faire un Channel Admin sur chaque canal dans cette application.
• Un Développeur d'application peut faire tout ce que peut faire un Chargé de téléchargement d'application et encore plus.

La hiérarchie ne s'applique que dans le sens descendant — un channel_admin ne jamais acquiert de permissions d'org niveau, même si elles détiennent également un rôle d'application.

---

Groupes

Plutôt que d'attribuer des rôles à chaque utilisateur individuellement, vous pouvez créer des groupes et attribuer des rôles au groupe. Chaque membre du groupe hérite automatiquement de ces rôles.

Comment fonctionnent les groupes

• Un groupe appartient à une organisation — il ne peut pas couvrir plusieurs organisations.
• Les groupes peuvent conserver des liens de rôle à n'importe quel champ : organisation, application, canal ou ensemble. Par exemple, un groupe peut être affecté au rôle de Développeur d'application sur l'application A et au rôle de Administrateur de canal sur le canal de l'application B. staging Lorsque les permissions d'un utilisateur sont évaluées, toutes ses adhésions de groupe sont résolues de manière transparente. Si l'un de ses groupes accorde la permission requise, l'accès est autorisé.
• Un utilisateur peut appartenir à
• plusieurs groupes , et les permissions de tous les groupes sont additives.Les permissions basées sur les groupes ne s'appliquent qu'à
• __CAPGO_KEEP_0__ principaux utilisateurs — les API clés ne héritent pas des rôles de groupe.

Quand utiliser les groupes

Scénario	Sans groupes	Avec groupes
5 ingénieurs QA ont besoin d'accès Développeur à 3 applications	15 liens de rôle individuels	1 groupe + 3 liens de rôle
Quelqu'un rejoint l'équipe QA	Ajouter 3 liens de rôle manuellement	Ajoutez-les au groupe
Quelqu'un quitte l'équipe QA	Supprimer 3 liens de rôle manuellement	Supprimez-les du groupe

Gérer les groupes via API

Tous les points de terminaison de groupe nécessitent une authentication et sont servis sous /private/groups.

Lister les groupes

curl -X GET "https://api.capgo.app/private/groups/<ORG_ID>" \
  -H "authorization: <API_KEY>"

Exige org.read_members permission.

Créer un groupe

curl -X POST "https://api.capgo.app/private/groups/<ORG_ID>" \
  -H "authorization: <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "QA Team",
    "description": "Quality assurance engineers"
  }'

Exige org.update_user_roles permission (Administrateur supérieur ou Administrateur).

Mettre à jour un groupe

curl -X PUT "https://api.capgo.app/private/groups/<GROUP_ID>" \
  -H "authorization: <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "QA Team",
    "description": "Updated description"
  }'

Supprimer un groupe

curl -X DELETE "https://api.capgo.app/private/groups/<GROUP_ID>" \
  -H "authorization: <API_KEY>"

La suppression d'un groupe supprime également tous ses liens de rôle. Les membres ne sont pas supprimés de l'organisation.

Lister les membres du groupe

curl -X GET "https://api.capgo.app/private/groups/<GROUP_ID>/members" \
  -H "authorization: <API_KEY>"

Ajouter un membre à un groupe

curl -X POST "https://api.capgo.app/private/groups/<GROUP_ID>/members" \
  -H "authorization: <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{ "user_id": "<USER_UUID>" }'

L'utilisateur doit déjà être membre de l'organisation. L'ajout d'un membre existant est une opération sans effet.

Retirer un membre d'un groupe

curl -X DELETE "https://api.capgo.app/private/groups/<GROUP_ID>/members/<USER_UUID>" \
  -H "authorization: <API_KEY>"

Note

Pour affecter un rôle à un groupe, utilisez les liens de rôle API avec principal_type: "group" et principal_id sélectionnez l'UUID du groupe.

---

Attribuer des rôles via API

Lister les membres

curl -X GET "https://api.capgo.app/organization/members" \
  -H "authorization: <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{ "orgId": "<ORG_ID>" }'

Réponse :

[
  {
    "uid": "user-uuid",
    "email": "alice@example.com",
    "image_url": "https://...",
    "role": "org_admin",
    "is_tmp": false
  }
]

Inviter un membre

curl -X POST "https://api.capgo.app/organization/members" \
  -H "authorization: <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "orgId": "<ORG_ID>",
    "email": "bob@example.com",
    "invite_type": "org_admin"
  }'

Valeurs acceptées pour invite_type:

Valeur	Rôle assigné
org_super_admin	Administrateur supérieur
org_admin	Administrateur
org_billing_admin	Gestionnaire de facturation
org_member	Membre

Supprimer un membre

curl -X DELETE "https://api.capgo.app/organization/members" \
  -H "authorization: <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "orgId": "<ORG_ID>",
    "email": "bob@example.com"
  }'

---

Attribuer des rôles via CLI

Lister les organisations

npx @capgo/cli organization list --apikey <API_KEY>

Lister les membres

npx @capgo/cli organization members <ORG_ID> --apikey <API_KEY>

Note

The CLI prend actuellement en charge la liste des membres. Pour inviter des membres ou modifier les rôles de manière programmée, utilisez les points de terminaison API ci-dessus.

---

Rôles personnalisés

Les rôles intégrés couvrent la plupart des structures d'équipe. La création de rôles personnalisés est prévue dans notre roadmap — si cela est quelque chose dont votre équipe a besoin, nous contacter. Votre cas d'utilisation aidera directement à nous prioriser cette fonctionnalité.

Continuez de l'Accès de Contrôle de la référence

Si vous utilisez Accès de Contrôle de la référence pour planifier les opérations de tableau de bord et API , connectez-le avec API Vue d'ensemble pour les détails d'implémentation dans API Aperçu, Introduction pour les détails d'implémentation dans Introduction, API Clés pour les détails d'implémentation dans API Clés, Appareils pour les détails d'implémentation dans Appareils, et Ensembles pour les détails d'implémentation dans Ensembles.