--- type: tutorial title: Crée ta première équipe partagée summary: Mets en place une équipe partagée et invite trois coéquipiers, chacun avec exactement les permissions dont son rôle a besoin, en suivant BananaSeed qui se constitue une équipe. --- À la fin de ce tutoriel, tu auras créé une équipe partagée et y auras invité trois personnes, chacune avec un jeu de permissions délibérément différent : un responsable des opérations qui dirige l'équipe, un développeur qui configure un produit, et un manager qui ne lit que les chiffres. On suit **BananaSeed**, une entreprise dont la fondatrice constitue une équipe. Il te faut une offre payante incluant les équipes partagées (Troop ou Apex). Sur Solo ou Alpha, tu n'as que ton équipe **Personal**, qui n'est qu'à toi. Vois [facturation](/docs/account-management/billing) pour les offres, [ce qu'est une équipe](/docs/troops/overview) pour le concept, et [permissions et portée](/docs/troops/permissions) pour le modèle sur lequel s'appuient les rôles ci-dessous. ## Le contexte La fondatrice de BananaSeed, Ana, a dépassé son équipe Personnelle. Elle a deux produits, chacun avec sa propre clé de site, et trois personnes à intégrer : | Personne | Rôle | Doit pouvoir | |---|---|---| | **Dana** | DevOps | Diriger l'équipe : gérer les membres et les jetons d'accès. | | **Raj** | Développeur | Personnaliser la clé de site d'un produit, et rien d'autre. | | **Mia** | Manager | Voir les chiffres dans toute l'équipe. Ne rien changer. | Chacun correspond à l'une des quatre [permissions](/docs/troops/permissions) : Dana a besoin de **Gérer l'équipe**, Raj de **Modifier** sur une clé, Mia de **Lire**. ## 1. Crée l'équipe et ses clés Depuis la liste des équipes du tableau de bord, crée une équipe nommée `BananaSeed`. Elle démarre avec toi seul, le propriétaire, détenant chaque permission. Crée les deux clés de site qu'elle contient, `shop.bananaseed.com` et `blog.bananaseed.com`, pour qu'il y ait de quoi attribuer une portée aux gens. (Vois [clés de site](/docs/site-keys/overview).) ## 2. Invite Dana, la responsable DevOps (Gérer) Sur la page **Membres** de l'équipe, invite Dana par e-mail. L'invitation est l'adresse e-mail elle-même ; quand Dana se connecte avec cette adresse, son adhésion est active. Accorde-lui **Gérer l'équipe** seulement. Cette unique permission est l'administration de l'équipe : elle peut ajouter, retirer et modifier les membres et les [jetons d'accès](/docs/troops/tokens), et renommer ou supprimer l'équipe. Parce que Gérer est à l'échelle de l'équipe, sa portée n'a pas d'importance, donc laisse-la sur toutes les clés de site. Elle n'a besoin ni de Lire, ni de Créer, ni de Modifier pour faire son travail ; Gérer est la permission qui dirige l'équipe. Maintenant Dana peut prendre le reste de l'intégration des mains d'Ana : elle peut émettre un jeton CI, ajouter la prochaine recrue et ajuster les permissions, le tout sans pouvoir être verrouillée dehors par une portée. ## 3. Invite Raj, le développeur sur un produit (Modifier, avec portée) Invite Raj de la même façon. Il possède la boutique, pas le blog, donc : - Accorde **Modifier** (et **Lire** pour qu'il voie ce qu'il modifie). Modifier le laisse configurer la clé : ses réglages, la rotation du secret, la vérification hébergée, et la [personnalisation du jeu et de la marque blanche](/docs/game-customization/overview) de la clé. - Fixe sa **portée** à **clés de site spécifiques** et choisis seulement `shop.bananaseed.com`. Laisse **Gérer** désactivé. Raj devrait configurer son produit, pas diriger l'équipe. Avec Modifier limité à une clé, c'est exactement ce qu'il obtient : il peut régler l'épreuve et le skin de la boutique, et il ne peut toucher ni le blog, ni la liste des membres, ni les jetons. C'est l'octroi de moindre privilège du quotidien : une permission (Modifier) bornée par une portée (une clé). ## 4. Invite Mia, la manager qui ne fait que lire (Lire) Invite Mia et accorde **Lire** seulement, sur toutes les clés de site. Lire la laisse ouvrir chaque clé de l'équipe et regarder ses [statistiques](/docs/troops/statistics), sa configuration et ses journaux d'audit, sans rien changer. Elle obtient la vue d'ensemble de l'équipe dont elle a besoin pour le reporting, sans pouvoir modifier un réglage ni faire tourner un secret par accident. ## 5. Confirme chaque octroi Fais connecter chaque personne et vérifie que l'équipe se comporte comme prévu : - **Dana** voit les contrôles Membres et jetons et peut les changer, mais modifier la configuration propre d'une clé de site n'est pas son octroi. - **Raj** peut ouvrir et configurer `shop.bananaseed.com`, ne voit pas `blog.bananaseed.com`, et n'a aucun contrôle Membres. - **Mia** peut ouvrir n'importe quelle clé et lire ses statistiques, mais chaque contrôle de modification est absent. C'est tout l'intérêt du modèle : trois personnes, trois métiers, trois portées différentes, aucune n'en détenant plus que nécessaire. Sur Apex, tout ce que chacune fait est consigné sous sa propre identité dans le [journal d'audit de l'équipe](/docs/audit-logs/troop-log). ## Où aller ensuite - Ajoute un identifiant CI ou de service à la place d'une personne avec un [Troop Access Token](/docs/troops/tokens), qui porte les mêmes permissions et la même portée. - Fixe les [surcharges](/docs/troops/overrides) une fois sur l'équipe pour que les deux clés héritent de la marque. - Surveille l'usage sur les deux produits avec les [statistiques](/docs/troops/statistics) de l'équipe. ## Voir aussi - [Permissions et portée](/docs/troops/permissions) : les quatre permissions en entier. - [Sièges](/docs/troops/seats) : comment chaque membre et jeton consomme le pool de sièges de ton offre. - [Ce qu'est une équipe](/docs/troops/overview) : le concept et ce qu'une équipe possède.