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

Capgo utilise un contrôle d'accès basé sur les rôles (RBAC) pour gérer les permissions de chaque membre de l'équipe. Les rôles sont organisés par périmètre — de l'organisation entière jusqu'à un seul bundle.

Pour un aperçu visuel de la gestion des membres dans le dashboard, consultez Organisation.

---

Portée des rôles

Chaque rôl’appartient à une portée qui détermine les ressources auxquelles il donne accès.

Portée	S'applique à	Exemple d'utilisation
Organisation	L'organisation entière et toutes ses apps	Votre cofondateur est Super Admin ; votre comptable est Billing Manager
cible	Une seule application et ses canaux	Un prestataire travaillant sur une application reçoit le rôl’App Developer
Canal	Un seul canal au sein d'une application	Un ingénieur QA gère uniquement le staging canal
Bundle	Une seule version de bundle	Un relecteur a besoin d'un accès en lecture pour une release spécifique

Un membre peut détenir un rôle par périmètre cible — par exemple, un rôle d'organisation, un rôle sur l'App A, et un rôle différent sur l'App B.

---

Rôles de l'organisation

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

Rôle	Nom interne	Description
Super admin	org_super_admin	Équivalent propriétaire. Contrôle total incluant la suppression de l'organisation, la gestion de la facturation et le transfert d'apps. Attribué automatiquement au créateur de l'organisation.
Admin	org_admin	Administration complète — gérer les membres, les apps et les canaux. Ne peut pas supprimer l'organisation, modifier la facturation, transférer des apps ou promouvoir des utilisateurs en Super Admin.
Gestionnaire de facturation	org_billing_admin	Accès facturation uniquement : consulter et modifier les infos de facturation, les factures et les logs d'audit de facturation. Aucun accès aux apps ou aux membres.
Membre	org_member	Accès en lecture seule à l'organisation et à toutes ses apps.

Matrice des permissions de l'organisation

Autorisation	Description	Super admin	Admin	Gestionnaire de facturation	Membre
org.read	Voir l'organisation	✅	✅	✅	✅
org.update_settings	Edit org name, logo, management email	✅	✅	❌	❌
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	Modifier les rôles des membres (un Admin ne peut pas promouvoir un Super Admin — restreint par la hiérarchie)	✅	✅	❌	❌
org.read_billing	Voir les infos de facturation et le plan actuel	✅	✅	✅	❌
org.update_billing	Mettre à jour le mode de paiement et le plan	✅	❌	✅	❌
org.read_invoices	Voir les factures	✅	✅	✅	❌
org.read_audit	Voir le log d'activité de l'organisation	✅	✅	❌	❌
org.read_billing_audit	Voir le log d'audit de facturation	✅	✅	✅	❌

Remarque

Les rôles d'organisation héritent de toutes les permissions des rôles d'app, de canal et de bundle situés en dessous d'eux dans la hiérarchie. Un Super admin peut tout faire comme un Admin d'app ou Admin de canal peut effectuer, sur l'ensemble des apps et des canaux.

---

Rôles de l'app

Limité à une seule app. Utilisez ces rôles lorsqu'un membre de l'équipe ne doit travailler que sur une app, et non sur toute l'organisation.

Rôle	Nom interne	Description
Admin d'app	app_admin	Contrôle total d'une application — canaux, appareils, rôles utilisateur de l'app. Impossible de supprimer ou de transférer l'app (opérations au niveau de l'organisation).
Développeur d'app	app_developer	Envoyer des bundles, gérer les appareils, lancer des builds natifs, modifier les paramètres des canaux. Pas de suppression, pas de changement des paramètres de l'app, pas de création de canal.
Uploader d'app	app_uploader	Accès en lecture + envoi de nouvelles versions de bundles.
Lecteur d'app	app_reader	Lecture seule — stats, bundles, canaux, logs, appareils.
Aperçu de l'app	app_preview	Cycle de vie CI lié à l'organisation et à l'app : envoyez un bundle et créez un canal de preview. La création de ce canal accorde automatiquement les droits de cycle de vie uniquement pour celui-ci.

Matrice des permissions de l'app

Autorisation	Description	Admin d'app	Développeur d'app	Uploader d'app	Lecteur d'app
app.read	Voir les détails, les stats et les métadonnées de l'app	✅	✅	✅	✅
app.update_settings	Modifier les paramètres de l'app	✅	❌	❌	❌
app.read_bundles	Voir la liste des bundles uploadés	✅	✅	✅	✅
app.upload_bundle	Uploader une nouvelle version du bundle	✅	✅	✅	❌
app.create_channel	Créer un nouveau canal	✅	❌	❌	❌
app.read_channels	Voir les canaux	✅	✅	✅	✅
app.read_logs	Voir les logs de livraison des mises à jour	✅	✅	✅	✅
app.manage_devices	Assigner, écraser ou dissocier des appareils	✅	✅	❌	❌
app.read_devices	Voir la liste des appareils	✅	✅	✅	✅
app.build_native	Déclencher un build cloud natif	✅	✅	❌	❌
app.read_audit	Consulter les logs d'activité de l'app	✅	✅	✅	✅
app.update_user_roles	Gérer les assignations de rôles par app	✅	❌	❌	❌
bundle.delete	Supprimer un bundle	✅	❌	❌	❌

Remarque

app.delete et app.transfer que opérations au niveau de l'organisation — seuls org_super_admin peut les effectuer, quels que soient les rôles au niveau de l'app.

Ensemble de permissions App Preview

Utiliser Aperçu de l'app (app_preview) pour une clé CI liée à l'organisation et à l'app qui gère le cycle de vie des previews de PR sans accès étendu à l'app ni à l'organisation.

Le app_preview L'association n'accorde que ces permissions au niveau de l'application :

Autorisation	Permet de
app.read	Lire l'app sélectionnée
app.read_bundles	Lire les bundles uploadés
app.upload_bundle	Envoyer un bundle
app.create_channel	Créer un canal

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

Autorisation	Permet de
channel.read	Lire le canal créé par la clé
channel.promote_bundle	Définir le bundle uploadé de la clé sur ce canal
channel.delete	Supprimer ce canal

Parce que app_preview conserve app.read, la clé peut énumérer les métadonnées du canal dans l'application sélectionnée. La liaison enfant automatique est une limite de limite : elle ne permet pas de modifier le cycle de vie d'un canal que la clé n'a pas créé.

Capgo enregistre la clé de preview qui a créé chaque canal et envoyé chaque bundle. Par conséquent, une clé App Preview peut créer chaque canal de preview non public nécessaire, promouvoir son propre bundle, et supprimer de manière atomique ce canal et ce bundle avec channel delete --delete-bundle; il ne peut pas effectuer ces actions sur un canal par défaut/principal existant, sur le canal d'une autre clé de preview, ou sur le bundle d'une autre clé.

Elle n'inclut pas la app.update_settingsgestion des appareils ou des rôles, channel.update_settings, channel.rollback_bundlela gestion des appareils forcés, ou la bundle.delete.

Attention

Chaque liaison App Preview reste liée à l'organisation propriétaire de l'application sélectionnée. Le rôl’exclut un rôl’à l'échelle de l'organisation ; il ne supprime pas l'association à l'organisation. La révocation ou l'expiration de la liaison de l'application supprime l'accès effectif de la clé au cycle de vie.

---

Rôles de canal

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

Remarque

Les rôles de canal sont actuellement disponibles uniquement via API et CLI — il n'y a pas d'interface pour les assigner dans le dashboard. channel_preview est une exception : Capgo le crée automatiquement pour une clé App Preview lorsqu'elle crée un canal. Dans le dashboard, utilisez les overrides de permissions de canal à la place pour affiner l'accès au canal par utilisateur.

Rôle	Nom interne	Description
Admin du canal	channel_admin	Contrôle total d'un canal : paramètres, promotion/rollback de bundles, gestion des appareils forcés.
Lecteur du canal	channel_reader	Lecture seule — bundle actuel, historique, appareils forcés, logs d'audit.
Aperçu du canal	channel_preview	Assigné automatiquement à la clé App Preview ayant créé le canal : lecture, promotion de son propre bundle et suppression de ce canal.

Matrice des permissions par canal

Autorisation	Description	Admin du canal	Lecteur de canal	Aperçu du canal
channel.read	Voir le canal et son bundle actuel	✅	✅	✅
channel.update_settings	Edit channel settings (platform toggles, update policy…)	✅	❌	❌
channel.delete	Supprimer le canal	✅	❌	✅
channel.read_history	Voir l'historique d'assignation des bundles	✅	✅	❌
channel.promote_bundle	Définir le bundle actif sur le canal	✅	❌	✅
channel.rollback_bundle	Effectuer un rollback vers un bundle précédent	✅	❌	❌
channel.manage_forced_devices	Forcer des appareils spécifiques sur ce canal	✅	❌	❌
channel.read_forced_devices	Voir la liste des appareils forcés	✅	✅	❌
channel.read_audit	Voir les logs d'activité du canal	✅	✅	❌

---

Rôles de bundle

Limité à une seule version de bundle. Rarement nécessaire — la plupart des équipes utilisent des rôles au niveau de l'app.

Remarque

Les rôles de bundle sont actuellement disponibles uniquement via API et CLI — il n'y a pas d'interface pour les assigner dans le dashboard.

Rôle	Nom interne	Description
Admin des bundles	bundle_admin	Lire, mettre à jour les métadonnées et supprimer un bundle spécifique.
Visualiseur de bundle	bundle_reader	Accès en lecture seule à un bundle spécifique.

---

Surcharge des permissions de canal (Dashboard)

Dans le dashboard, l'accès aux canaux est déterminé par défaut par le rôle de l'utilisateur dans l'app. Pour un contrôle plus granulaire, vous pouvez écraser les permissions de canaux spécifiques par utilisateur ou par groupe sans modifier son rôle dans l'app.

Les surcharges se configurent depuis l'onglet Accès onglet en cliquant sur le bouton des permissions du canal (icône bouclier) à côté d'un utilisateur. Voir Organisation — Surcharge des permissions de canal pour un guide visuel.

Permissions surchargables

Autorisation	Description	Comportement par défaut
Lecture	Voir le canal et son bundle actuel	Hérité du rôle de l'application
Historique	Voir l’historique des assignations de bundles	Hérité du rôle de l'application
Associer un bundle	Définir ou changer le bundle actif du canal	Hérité du rôle de l'app

Chaque permission peut être définie sur :

• Par défaut — hériter du rôle de l'app (par défaut)
• Autoriser — accorder explicitement, quel que soit le rôle de l'app
• Refuser — bloquer explicitement, quel que soit le rôle de l'app

Cela vous permet, par exemple, de donner à un App Reader la possibilité d'associer des bundles sur le staging canal sans le promouvoir au rôle d'App Developer.

---

Hiérarchie des rôles

Les rôles forment une hiérarchie. Un rôle parent hérite de toutes les permissions de ses rôles enfants. Cela signifie qu'un org_admin peut tout faire ce qu'un app_admin peut, qui lui-même peut tout faire ce qu'un 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)

Fonctionnement pratique :

• Un Admin au niveau de l'organisation peut tout faire ce qu'un Admin d'app peut, sur chaque app de l'organisation.
• Un Admin d'app sur une app spécifique peut tout faire comme un Admin de canal peut, sur chaque canal de cette app.
• Un Développeur d'app peut tout faire comme un Uploader d'app peut, et plus encore.

La hiérarchie ne s'applique que vers le bas — un channel_admin ne gagne jamais de permissions au niveau de l'organisation, même s'il possède un rôl’au niveau de l'app.

---

Groupes

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

Fonctionnement des groupes

• Un groupe appartient à une seule organisation — elle ne peut pas s'étendre sur plusieurs organisations.
• Les groupes peuvent contenir des liaisons de rôles à any scope: organisation, app, canal ou bundle. Par exemple, un groupe peut se voir attribuer le Développeur d'app rôle sur l'App A et le rôle Administrateur de canal sur le staging canal de l'App B.
• Lors de l'évaluation des permissions d'un utilisateur, tous ses groupements sont résolus 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 s'additionnent.
• Group-based permissions only apply to principaux utilisateurs — les clés API n'héritent pas des rôles de groupe.

Quand utiliser les groupes

Scénario	Sans groupes	Avec des groupes
5 ingénieurs QA ont besoin d'un accès Developer sur 3 apps	15 liaisons de rôles individuelles	1 groupe + 3 liaisons de rôles
Un membre rejoint l'équipe QA	Ajouter 3 liaisons de rôles manuellement	Les ajouter au groupe
Un membre quitte l'équipe QA	Supprimer 3 liaisons de rôles manuellement	Les retirer du groupe

Gérer les groupes via API

Tous les endpoints 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>"

Nécessite une 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"
  }'

Nécessite une org.update_user_roles permission (Super admin ou Admin).

Modifier 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ôles. 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 n'aura aucun 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>"

Remarque

Pour attribuer un rôl’à un groupe, utilisez les role bindings API avec principal_type: "group" et principal_id l’UUID du groupe.

---

Assigner 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ôl’assigné
org_super_admin	Super admin
org_admin	Admin
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"
  }'

---

Assigner 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>

Remarque

CLI permet actuellement de lister les membres. Pour inviter des membres ou modifier des rôles par programmation, utilisez les endpoints 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 sur notre roadmap — si votre équipe en a besoin, contactez-nous. Votre cas d'usage nous aidera directement à prioriser cette fonctionnalité.

Continuer avec la référence Contrôle d’accès

Si vous utilisez Référence du contrôle d'accès pour planifier les opérations du dashboard et de API, connectez-l’avec Aperçu de API pour les détails d'implémentation dans « Vue d'ensemble de API », Introduction pour les détails d'implémentation dans l'introduction, Clés API pour les détails d'implémentation dans API Keys, Appareils pour les détails d'implémentation dans Devices, et Les bundles pour les détails d'implémentation dans Bundles.