Qui peut faire quoi : membres, rôles et portées
Le rôle de base que porte chaque membre, les rôles personnalisés qu'une équipe peut écrire, et l'affectation qui accorde l'un d'eux sur un seul environnement.
Vérifié le 13 août 2026
L'accès à la plateforme se construit avec trois pièces, et tout devient plus simple dès qu'on voit qu'elles sont distinctes : un rôle de base porté par chaque membre, des rôles qui ne sont que des ensembles nommés de permissions, et des affectations qui accordent un rôle à un endroit précis.
C'est la troisième que personne ne devine, et c'est elle qui permet de faire entrer un collaborateur externe dans un seul environnement, et nulle part ailleurs.
Chaque membre porte un rôle de base
La page Équipe liste vos membres, chacun avec un rôle de base qui s'applique à toute l'équipe. Il est choisi au moment de l'invitation et peut être changé ensuite depuis la même ligne.
Le rôle du propriétaire ne se change pas ici, et le propriétaire ne peut pas être retiré : une équipe doit toujours conserver quelqu'un capable d'agir sur elle.
Les cinq rôles intégrés
Ils sont fixes, et ils s'emboîtent : chacun contient tout ce que contient le précédent, plus le reste.
| Rôle | Permissions | Ce que cela signifie |
|---|---|---|
| Propriétaire | 51 | Tout le catalogue, y compris la suppression de l'équipe. |
| Administrateur | 50 | Tout l'opérationnel — tout sauf supprimer l'équipe. |
| Développeur | 35 | Le quotidien : déployer, modules, sauvegardes, restauration, bases, IA. Voit la facturation mais ne peut pas dépenser ; ne gère pas les membres. |
| Lecteur | 11 | Lecture seule, plus les journaux et les métriques — de quoi observer, rien pour modifier. |
| Invité | 0 | Rien du tout, à l'échelle de l'équipe. |
Que l'invité ne détienne aucune permission n'est pas un oubli : c'est toute la raison d'être de ce rôle. Un invité ne voit rien tant que vous ne lui accordez pas quelque chose à un endroit précis, ce qui est exactement la forme voulue pour un client, un auditeur ou un sous-traitant.
Notez où passe la limite du développeur : il peut restaurer un environnement et gérer les instances clientes, mais il ne peut pas supprimer un environnement, supprimer une instance cliente, recharger le solde ni changer le pays de facturation. Détruire des données et dépenser de l'argent restent réservés à l'administrateur et au propriétaire.
Les rôles que vous écrivez vous-même
Rôles et permissions est l'endroit où une équipe définit les siens. Un rôle personnalisé est un nom, une description et un ensemble de permissions choisies dans le catalogue — rien de plus. Il ne porte aucune portée par lui-même.
Cliquez sur n'importe quel rôle — les intégrés compris — pour voir exactement les permissions qu'il accorde. Dupliquer un rôle intégré est la façon la plus honnête et la plus rapide d'en construire un : partez de Développeur, retirez ce que vous ne voulez pas, enregistrez sous votre propre nom.
La portée : où un rôle s'applique
Une affectation est l'assemblage de un membre, un rôle et une portée. Il en existe trois :
- Toute l'équipe — le rôle s'applique partout, exactement comme un rôle de base.
- Instance — le rôle s'applique à cette instance et à tout ce qu'elle contient, ses environnements compris.
- Environnement — le rôle s'applique à ce seul environnement.
Comme la portée vit sur l'affectation et non sur le rôle, un même rôle peut être accordé plusieurs fois à des endroits différents. « Support client » sur l'environnement de production d'un client, puis sur celui d'un autre client, c'est le même rôle employé deux fois.
Comment les permissions s'additionnent
La règle est courte : vos permissions effectives sont l'union des permissions de votre rôle de base, pour toute l'équipe, plus chaque affectation que vous détenez, à la portée de cette affectation.
Deux conséquences en découlent, et les deux comptent :
- Une affectation ne fait qu'ajouter. Rien ne soustrait. Donner à un administrateur un rôle restreint sur un environnement ne restreint rien : il avait déjà le droit. Pour réduire quelqu'un, abaissez son rôle de base (Invité est le plancher) puis rendez-lui ce dont il a besoin.
- Une attribution sur une instance couvre ses environnements. La permission est vérifiée contre la chaîne de l'objet visé : un rôle limité à une instance atteint donc tout ce qui se trouve en dessous. L'inverse n'est pas vrai : une attribution sur un environnement y reste.
La recette pour un collaborateur externe est donc : rôle de base Invité, plus une affectation d'un rôle personnalisé étroit, limitée au seul environnement sur lequel il travaille.
Ce à quoi il faut faire attention
Gérer les rôles et les membres vaut toujours pour toute l'équipe. team.roles.manage et
team.members.manage sont vérifiées uniquement contre vos permissions valables à l'échelle de l'équipe :
accorder l'une d'elles sur un environnement ne permet pas d'administrer l'équipe depuis cet endroit.
Le pouvoir de distribuer les accès ne peut pas lui-même être distribué dans un coin.
Cacher un bouton n'est pas la protection. L'interface masque ce que vous ne pouvez pas faire, mais chaque service revérifie la permission à l'arrivée de la requête. Un bouton caché et une requête refusée sont deux mécanismes différents, et seul le second relève de la sécurité.
Les clés de permission sont un contrat. Elles ne sont jamais renommées ni supprimées, seulement ajoutées — c'est pourquoi un rôle écrit il y a un an accorde toujours exactement ce qu'il accordait alors, et pourquoi les nouvelles capacités arrivent automatiquement chez le propriétaire et l'administrateur sans que personne ait à modifier un rôle.