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

Capgo uses Prêt à utiliser pour gérer ce que chaque membre d'équipe peut faire. Les rôles sont organisés par portée — de l'ensemble de l'organisation jusqu'à un seul paquet.

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

---

Portées de rôle

Chaque rôle appartient à une portée qui détermine à quelles ressources il accorde accès.

Portée	S'applique à	Exemple d'utilisation
Organisation	The entire org and all its apps	Votre co-fondateur obtient Super Administrateur ; votre comptable obtient Gestionnaire de facturation
Application	Une seule application et ses canaux	Un entrepreneur de contrat travaillant sur une application obtient Développeur d'application
Canal	Un seul canal au sein d'une application	Un ingénieur QA ne gère que le staging canal
Pack	Une seule version de pack	Un réviseur a besoin d'accès en lecture à une version de release spécifique

A un membre peut être associé à un rôle par champ cible — 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 l'accès à l'ensemble de l'organisation.

Rôle	Nom interne	Description
Administrateur supérieur	org_super_admin	Équivalent à un 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.
Rôle sur l'application A et un rôle différent sur l'application B	org_admin	Administration 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 Super Admin.
Gestionnaire des factures	org_billing_admin	Accès factures uniquement : afficher et mettre à jour les informations de facturation, les factures et les journaux de suivi de facturation. Pas d'accès aux applications ou aux membres.
Membre	org_member	Accès en lecture seule à l'org et à toutes ses applications.

Matrice de permissions de l'org

Permission	Description	Super Administrateur	Administrateur	Gestionnaire des factures	Membre
org.read	Afficher l'organisation	✅	✅	✅	✅
org.update_settings	Modifier le nom, le logo et l'adresse e-mail de gestion de l'organisation	✅	✅	❌	❌
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 (un administrateur ne peut pas promouvoir un 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 le journal d'activité de l'organisation	✅	✅	❌	❌
org.read_billing_audit	Afficher le journal d'audit spécifique à la facturation	✅	✅	✅	❌

Remarque

Les rôles d'organisation héritent de toutes les permissions de l'application, du canal et du rôle de bundle situés en dessous d'eux dans la hiérarchie. Un Administrateur principal peut faire tout ce que peut faire un Administrateur d'application ou un Administrateur de canal across 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
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 des appareils, déclencher des builds natives, mettre à jour les paramètres de canal. Pas de suppression, pas de modifications des paramètres d'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	Administrateur d'application	Développeur d'application	Chargement d'application	Lecteur d'application
app.read	Afficher les détails, statistiques et métadonnées de l'application	✅	✅	✅	✅
app.update_settings	Modifier 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	Attribuer, surcharger ou délier 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é du niveau d'application	✅	✅	✅	✅
app.update_user_roles	Gérer les affectations de rôle au niveau d'application	✅	❌	❌	❌
bundle.delete	Supprimer un bundle	✅	❌	❌	❌

Note

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

---

Rôles de canal

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

Note

Les rôles de canal sont actuellement disponibles via API et CLI uniquement — il n'y a pas d'interface utilisateur pour les affecter dans l'interface de dashboard. Dans l'interface de dashboard, utilisez surcharges de permission de canal au lieu de finir de régler l'accès par 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 lots, gestion de dispositifs forcés.
Voyeur 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 bundle actuel	✅	✅
channel.update_settings	Éditer les paramètres du canal (tournis de plateforme, politique de mise à jour…)	✅	❌
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 de bundle

Attribué à une seule version de 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 l'interface de dashboard.

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

---

Survol des permissions de canal (Tableau de bord)

Dans le tableau de bord, l'accès au canal est déterminé par le rôle d'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 survol 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.

Autorisations modifiables

Autorisation	Description	Comportement par défaut
Lecture	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 :

• Par défaut — hériter du rôle d'application (la valeur par défaut)
• Autoriser — accorder explicitement, en fonction du rôle d'application
• Interdire — bloquer explicitement, en fonction du rôle d'application

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

---

Hiérarchie de rôle

Les rôles forment une hiérarchie. Un rôle parent hérite de toutes les permissions de ses enfants. Cela signifie que org_admin peut faire tout ce que peut faire app_admin peut faire tout ce que peut faire channel_admin 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'org peut faire tout ce que peut faire App Admin peut, sur chaque application dans l'organisation.
• Un App Admin sur une application spécifique peut faire tout ce que peut faire un Channel Admin sur chaque canal dans cette application.
• Un App Developer peut faire tout ce que peut faire un App Uploader et en plus.

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

---

Groupes

Au lieu 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 Section intitulée « Comment fonctionnent les groupes »

Un groupe appartient à

• __CAPGO_KEEP_1__ une organisation — elle ne peut pas couvrir plusieurs organisations.
• Les groupes peuvent détenir des liaisons de rôle à n'importe quel niveau : organisation, application, canal ou bundle. Par exemple, un groupe peut être affecté durôle d'App développeur sur l'application A et du 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 à
• un ou plusieurs groupes.
• Les groupes peuvent détenir des rôles à différents niveaux : organisation, application, canal ou bundle. groupes multiplesles permissions de tous les groupes sont additives.
• les permissions basées sur les groupes 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 QA	Ajouter 3 liens de rôle manuellement	Les ajouter au groupe
Quelqu'un quitte l'équipe QA	Supprimer 3 liens de rôle manuellement	Les supprimer du groupe

Gestion des 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 une 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 une permission (Administrateur supérieur ou Admin).

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.

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.

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 affecter un rôle à un groupe, utilisez les liens de rôle API avec principal_type: "group" et principal_id fixez à l'UUID du groupe.

---

Affecter 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
  }
]

Invitez 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 supérieur
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

Le 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 sur notre feu de route — si cela est quelque chose que votre équipe nécessite, nous contacter. Votre cas d'utilisation aidera directement à nous prioriser cette fonctionnalité.

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

Si vous utilisez Référence de Contrôle d'accès pour planifier le tableau de bord et les opérations API, connectez-le à Résumé de API pour les détails d'implémentation dans Résumé de API, Introduction pour les détails d'implémentation dans Introduction, Clés de API pour les détails d'implémentation dans Clés de API, Appareils pour les détails d'implémentation dans Appareils, et Ensembles pour les détails d'implémentation dans Ensembles.