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 Structure.

---

Échelles de rôle

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

Échelle	S'applique à	Cas d'utilisation
Structure	L'ensemble de 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	A un contratiste travaillant sur une seule application obtient le rôle d'App Developer
Chaîne	Une seule chaîne au sein d'une application	Un ingénieur QA ne gère que la chaîne staging Chaîne
Une seule version de bundle	Un réviseur a besoin d'accès en lecture à une seule 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 App A et un rôle différent sur App B. Rôles d'organisation

---

__CAPGO_KEEP_0__

Ces rôles sont attribués lors de l'invitation d'un membre. Ils accordent l'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 complète — 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 en 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	Voir 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	Voir les informations de facturation et le plan actuel	✅	✅	✅	❌
org.update_billing	Mettre à jour le moyen de paiement et le plan	✅	❌	✅	❌
org.read_invoices	Voir les factures	✅	✅	✅	❌
org.read_audit	Voir l'historique d'activité de l'organisation	✅	✅	❌	❌
org.read_billing_audit	Voir 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. A Super Administrateur peut faire tout ce que peut faire un Administrateur d'application ou Administrateur de canal peut faire, dans tous les applications et canaux.

---

Rôles d'application

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

Rôle	Nom interne	Description
Administrateur 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	Télécharger des bundles, gérer les appareils, déclencher des builds natives, mettre à jour les paramètres de canal. Aucune suppression, aucune modification des paramètres de l'application, aucune création de canal.
Téléchargeur d'application	app_uploader	Accès en lecture + télécharger de nouvelles versions de bundles.
Lecture seule — statistiques, bundles, canaux, journaux, appareils.	app_reader	Aperçu de l'application
Cycle de vie de l'aperçu lié à l'organisation et à l'application : télécharger un bundle et créer un canal d'aperçu. La création de ce canal accorde automatiquement les droits de cycle de vie uniquement pour celui-ci.	app_preview	Matrice de permissions de l'application

Section intitulée « Matrice de permissions de l'application »

App permission matrix	Description	Admin de l'application	Développeur de l'application	Chargement d'une nouvelle version de l'application	Lecteur de l'application
app.read	Afficher les détails, les statistiques et les métadonnées de l'application	✅	✅	✅	✅
app.update_settings	Éditer les paramètres de l'application	✅	❌	❌	❌
app.read_bundles	Afficher la liste des ensembles chargés	✅	✅	✅	✅
app.upload_bundle	Charger une nouvelle version de l'ensemble	✅	✅	✅	❌
app.create_channel	Créer un nouveau canal	✅	❌	❌	❌
app.read_channels	Afficher les canaux	✅	✅	✅	✅
app.read_logs	Afficher les journaux de livraison de mise à jour	✅	✅	✅	✅
app.manage_devices	Attribuez, surchargez ou débranchez les appareils	✅	✅	❌	❌
app.read_devices	Afficher la liste des appareils	✅	✅	✅	✅
app.build_native	Déclencher une construction cloud native	✅	✅	❌	❌
app.read_audit	Afficher 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 ensemble	✅	❌	❌	❌

Note

app.delete et app.transfer sont opérations d'échelon d'organisation — uniquement org_super_admin peut les effectuer, quel que soit le rôle d'application.

ensemble de permissions App Preview

Utiliser App Preview (app_preview) pour une clé CI liée à une organisation et une application qui gère le cycle de vie d'une prévisualisation de PR sans accès large à l'application ou à l'organisation.

La app_preview la liaison ne concède que ces permissions d'applications :

Permission	Permet
app.read	Lire l'application sélectionnée
app.read_bundles	Lire les bundles téléchargés
app.upload_bundle	Charger un bundle
app.create_channel	Créer un canal

Lorsqu'une clé d'App Preview crée un canal, Capgo donne automatiquement à cette clé une clé enfant channel_preview Liaison pour le nouveau canal uniquement :

Permission	Permet
channel.read	Lire le canal créé par la clé
channel.promote_bundle	Définir la clé de chargement de son propre bundle sur ce canal
channel.delete	Supprimer ce canal

Parce que app_preview retient app.read, la clé peut lister les métadonnées du canal sélectionné dans l'application. L'liaison automatique de la clé enfant est un Gestion limites : elle ne concède pas les mutations de cycle de vie pour un canal dont la clé n'a pas été créée.

Capgo enregistre la clé de prévisualisation qui a créé chaque canal et téléchargé chaque bundle. Par conséquent, une clé de prévisualisation d'application peut créer chaque canal de prévisualisation non public dont elle a besoin, promouvoir son propre bundle et supprimer atomiquement ce canal et ce bundle avec channel delete --delete-bundle ; elle ne peut pas faire ces choses à un canal par défaut/main existant, à un canal d'une autre clé de prévisualisation ou à un bundle d'une autre clé.

Caution app.update_settingsAttention channel.update_settings, channel.rollback_bundleChaque liaison d'application de prévisualisation reste liée à l'organisation propriétaire de l'application sélectionnée. Le rôle omet un rôle organisationnel ; il ne supprime pas l'association organisationnelle. La révocation ou l'expiration de la liaison d'application supprime l'accès au cycle de vie effectif de la clé. bundle.delete.

Section intitulée « Rôles de canal »

Caution

---

Attention

Limité à un seul canal. Utile pour donner un accès ciblé à une version spécifique d'un canal.

Note

Les rôles de canal sont actuellement disponibles via API et CLI seulement — il n'y a pas d'interface utilisateur pour les assigner dans l'interface de dashboard. channel_preview est une exception : Capgo le crée automatiquement pour une clé de prévisualisation d'application lorsqu'elle crée un canal. Dans l'interface de dashboard, utilisez les surdéclarations de permission de canal au lieu pour affiner l'accès au canal 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 bundles, gestion de dispositifs forcés.
Voyant de canal	channel_reader	Lecture seule — bundle actuel, historique, dispositifs forcés, journal d'audit.
Aperçu de canal	channel_preview	Attribué automatiquement à la clé d'aperçu d'application qui a créé le canal : lecture, promotion de son propre bundle et suppression de ce canal.

Matrice de permissions de canal

Permission	Description	Administrateur de canal	Voyant de canal	Aperçu de la chaîne
channel.read	Afficher la chaîne et son bundle actuel	✅	✅	✅
channel.update_settings	Éditer les paramètres de la chaîne (touilles de plateforme, politique d'actualisation…)	✅	❌	❌
channel.delete	Supprimer la chaîne	✅	❌	✅
channel.read_history	Afficher l'historique d'affectation de bundle	✅	✅	❌
channel.promote_bundle	Définir le bundle actif sur la chaîne	✅	❌	✅
channel.rollback_bundle	Revenir à un bundle précédent	✅	❌	❌
channel.manage_forced_devices	Forcer des appareils spécifiques à cette chaîne	✅	❌	❌
channel.read_forced_devices	Afficher la liste des appareils forçés	✅	✅	❌
channel.read_audit	Afficher le journal d'activité de la chaîne	✅	✅	❌

---

Rôles de bundle

Limité à une version de paquet unique. Rarement nécessaire — la plupart des équipes utilisent des rôles d'application au lieu de cela.

Note

Les rôles de paquet 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 paquet	bundle_admin	Lecture, mise à jour des métadonnées et suppression d'un paquet spécifique.
Voyant de paquet	bundle_reader	Accès en lecture seule à un bundle spécifique.

---

Survol des permissions de canal (Tableau de bord)

Par défaut, l'accès au canal est déterminé par le rôle de l'application de l'utilisateur dans le tableau de bord. 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 depuis 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. Consultez Organisation — Survol des permissions de canal pour un guide visuel.

Permissions survolables

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

Chaque permission peut être définie sur :

• Par défaut — hériter du rôle d'application (la valeur par défaut)
• Autoriser — accorder explicitement, quel que soit le rôle d'application
• Dénier — bloquer explicitement, quel que soit le rôle d'application

Cela vous permet, par exemple, de donner à un Lecteur d'application la capacité de lier des ensembles sur le staging canal sans les promouvoir en Développeur d'application.

---

Héritage de rôle

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 faire, qui à son tour peut faire tout ce que channel_admin peut faire, 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 App Administrateur peut faire sur chaque application dans l'org.
• Un Administrateur d'application sur une application spécifique peut faire tout ce que peut faire un Administrateur de canal peut faire sur chaque canal dans cette application.
• Un Développeur d'application peut faire tout ce que peut faire un Administrateur d'application de téléchargement peut faire plus.

La hiérarchie ne s'écoule que vers le bas — un channel_admin jamais obtient des permissions au niveau d'organisation, même si elle détient également un rôle au niveau d'application.

---

Groupe

Plutôt que d'attribuer des rôles à chaque utilisateur individuellement, vous pouvez créer groupe 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 — elle ne peut pas couvrir plusieurs organisations.
• Les groupes peuvent détenir des liens de rôle à n'importe quel niveau : organisation, application, canal ou bundle. Par exemple, un groupe peut être attribué lerôle d'App développeur sur l'application A et le rôle d'administrateur de canal sur le canal de l'application B. 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é. staging Un utilisateur peut appartenir à
• plusieurs groupes
• protectedTokens targetLanguageet les permissions de tous les groupes sont additives.
• Les permissions basées sur le groupe ne s'appliquent qu'à principaux d'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 de test	Ajouter 3 liens de rôle manuellement	Les ajouter au groupe
Quelqu'un quitte l'équipe de test	Supprimer 3 liens de rôle manuellement	Les retirer du groupe

Gérer les groupes via API

Tous les points de terminaison de groupe nécessitent une authentification 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 la 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 la 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 toutes ses liaisons de rôle. Les membres ne sont pas supprimés de l'organisation.

Liste des 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.

Supprimer un membre d'un groupe

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

Remarque

Pour attribuer 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

Liste des 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 attribué
org_super_admin	Administrateur principal
org_admin	Administrateur
org_billing_admin	Gestionnaire des factures
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"
  }'

---

Attribution de 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 à 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 planer le tableau de bord et les opérations API, connectez-le à API Vue d'ensemble pour les détails d'implémentation dans API Vue d'ensemble, 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 Bundles pour les détails d'implémentation dans Bundles.