Administrateurs de plateforme et emprunt d'identité

Deux rôles « admin » différents partagent la même chaîne dans Scrydon — les administrateurs de plateforme (user.role) et les administrateurs d'organisation (member.role). Cette page explique la distinction, comment devenir administrateur de plateforme et comment utiliser l'emprunt d'identité pour voir la plateforme comme un autre membre.

Scrydon possède deux rôles « admin » sans lien entre eux qui partagent le mot admin. Ils sont vérifiés sur des axes différents et accordent des pouvoirs différents. Les confondre est la cause la plus fréquente de tickets de support du type « je devrais voir ce bouton mais je ne le vois pas », aussi cette page fait office de référence canonique.

Être un administrateur d'organisation ne fait pas de vous un administrateur de plateforme. Ce sont des champs différents sur des lignes différentes. Les chaînes se recoupent ; les privilèges non.

Les deux axes admin

Axe	Champ	Valeurs	Ce qu'il contrôle
Rôle dans l'organisation	`member.role`	`admin` / `member`	Inviter des membres, modifier les rôles, configurer l'organisation, générer des jetons SCIM.
Rôle de plateforme	`user.role`	`admin` / `super_admin` (sinon `user`)	Actions d'opérateur à l'échelle de la plateforme, y compris l'emprunt d'identité d'autres membres. `super_admin` gère en outre qui est administrateur de plateforme et peut créer ou supprimer des organisations.

Le rôle de plateforme est configuré par l'opérateur qui gère votre déploiement Scrydon — ce n'est pas quelque chose qu'un administrateur d'organisation peut accorder. SSO et SCIM ne l'assignent pas non plus.

Comment savoir quel rôle vous avez

Dans n'importe quel onglet de navigateur connecté, ouvrez Outils de développement → Console et exécutez :

fetch("/api/auth/get-session", { credentials: "include" })
  .then(r => r.json())
  .then(s => console.log({
    platformRole: s.user?.role,                  // "admin" | "super_admin" | "user" | null
    orgRole:      s.session?.activeOrganizationRole, // "admin" | "member"
  }));

platformRole: "user" (ou null) → vous n'êtes pas un administrateur de plateforme. Le bouton d'emprunt d'identité et la page de paramètres Super Admin sont masqués.
platformRole: "admin" → vous pouvez emprunter des identités, mais vous ne pouvez pas promouvoir ou rétrograder d'autres administrateurs de plateforme.
platformRole: "super_admin" → vous pouvez emprunter des identités et gérer la liste des administrateurs de plateforme sous Paramètres → Super Admin.

Une vérification plus simple : si Paramètres → Super Admin n'apparaît pas dans votre barre latérale, vous n'êtes pas super_admin.

Comment quelqu'un devient administrateur de plateforme

Il existe quatre chemins, tous contrôlés par l'opérateur du cluster — pas par l'interface Scrydon seule :

Le tout premier utilisateur à s'enregistrer sur un nouveau déploiement est automatiquement promu super_admin. C'est l'opérateur qui gère le cluster. Si votre organisation fonctionne depuis un moment, cette personne existe déjà — contactez-la.

Tout e-mail listé dans la variable d'environnement SUPER_ADMIN_EMAILS (définie dans vos valeurs Helm) est automatiquement promu super_admin la première fois que cet utilisateur s'inscrit et la prochaine fois qu'un utilisateur existant avec un e-mail correspondant se connecte. S'ajouter ici est le chemin standard « je viens de déployer Scrydon, faites-moi super admin ».

Un super_admin peut promouvoir n'importe quel autre utilisateur depuis Paramètres → Super Admin en cliquant sur Promouvoir en Super Admin sur la ligne de cet utilisateur. C'est la façon normale d'ajouter des opérateurs après la mise en production du déploiement.

Un super_admin peut également rétrograder un autre super_admin vers user depuis la même page. Il n'y a pas d'étape séparée « rétrograder vers admin simple » — l'interface ne bascule qu'entre super_admin et user.

Le admin de plateforme simple (le rôle entre user et super_admin) n'est pas assignable depuis l'interface dans cette version. En pratique, chaque administrateur de plateforme est un super_admin. Le niveau inférieur admin existe pour la compatibilité future et accorde toujours le bouton d'emprunt d'identité.

Voir la plateforme comme un autre membre (emprunt d'identité)

Une fois que vous disposez d'un rôle d'administrateur de plateforme, vous pouvez vous connecter en tant que n'importe quel membre de l'organisation et voir exactement ce qu'il voit — mêmes routes, mêmes permissions, même filtrage des données, même espace de travail.

Où se trouve le bouton

Ouvrez Paramètres → Organisation → Membres.
Dans la colonne des actions à l'extrême droite pour chaque membre, vous verrez une petite icône de vérification utilisateur. Texte au survol : Emprunter l'identité de l'utilisateur.
Cliquez dessus. La page se recharge et votre session est maintenant celle de cet utilisateur.

Le bouton n'est affiché que lorsque les trois conditions suivantes sont vraies :

Votre user.role est admin ou super_admin.
La ligne n'est pas votre propre utilisateur.
Vous n'êtes pas déjà en train d'emprunter une identité (pas d'emprunt d'identité en chaîne).

Si l'une d'elles est fausse, le bouton n'apparaît pas du tout — c'est le comportement prévu, pas un bug.

La bannière ambrée

Pendant que vous empruntez une identité, une bannière ambrée fixe se trouve en haut de chaque page : Emprunt d'identité de <nom> avec un bouton Arrêter l'emprunt d'identité à droite. Cliquer sur le bouton met fin à la session empruntée et vous recharge dans votre propre session.

La bannière est votre seul rappel à l'écran. Prenez l'habitude de regarder en haut de l'écran avant de faire quoi que ce soit que vous ne souhaiteriez pas attribuer à l'utilisateur dont vous empruntez l'identité.

Durée de la session

Une session empruntée expire automatiquement après 1 heure. Après cela, toute action supplémentaire échouera jusqu'à ce que vous commenciez un nouvel emprunt d'identité ou vous reconnectiez à votre propre compte.

Ce qu'est réellement l'emprunt d'identité (et ce qu'il n'est pas)

C'est la partie qui surprend les gens, alors lisez-la avant d'utiliser la fonctionnalité.

Ce n'est pas un aperçu « voir en tant que » en lecture seule. Chaque clic, soumission de formulaire et appel API effectués pendant l'emprunt d'identité s'exécutent en tant que cet utilisateur, côté serveur, avec sa portée RLS.
Les actions sont enregistrées dans le journal d'audit sous l'identité de l'utilisateur emprunté. La ligne de session comporte un champ impersonated_by qui enregistre qui était le véritable opérateur, de sorte qu'un auditeur peut reconstituer qui a réellement fait l'action — mais seulement s'il sait chercher cette colonne.
Les politiques DLP, d'autorisation et les compteurs de quota s'appliquent tous comme si l'utilisateur emprunté avait effectué l'action.

Règles pratiques :

Utilisez l'emprunt d'identité pour diagnostiquer ce qu'un utilisateur voit (un élément de menu manquant, une erreur de permission, une vue de tableau cassée). Ensuite, arrêtez l'emprunt d'identité avant de faire un vrai travail.
N'utilisez pas l'emprunt d'identité pour « corriger rapidement quelque chose pour un utilisateur ». La piste d'audit attribuera cette correction à l'utilisateur, pas à vous. Soit accordez-vous la permission dont vous avez besoin, soit demandez à l'utilisateur d'effectuer l'action avec vous en observateur.
Soyez particulièrement prudent avec les actions destructrices (suppression d'un espace de travail, révocation d'intégrations, suppression de données). Elles ne sont pas réversibles en arrêtant l'emprunt d'identité.

Pourquoi les deux admins partagent le même mot

Le rôle admin de plateforme et le rôle admin d'organisation partagent vraiment la chaîne littérale "admin". En interne, nous les traitons comme deux axes différents et ne les vérifions jamais l'un par rapport à l'autre — mais sur le réseau, dans le cookie de session et dans les lignes de journal, ils se ressemblent. Si vous lisez du code ou déposez un ticket de support et avez besoin de les distinguer, la terminologie précise est :

Administrateur de plateforme : user.role === "admin" (ou "super_admin").
Administrateur d'organisation : member.role === "admin" sur une ligne member pour cet utilisateur dans cette organisation.

Les deux ne sont jamais vérifiés l'un par rapport à l'autre. Un super_admin de plateforme est traité comme un admin de chaque organisation (une dérogation opérateur), mais c'est une implication à sens unique : un admin d'organisation n'est pas implicitement un administrateur de plateforme en aucun sens.

En rapport

Identité et provisionnement (SCIM) — synchroniser les utilisateurs et les groupes depuis votre IdP. SCIM n'accorde pas le rôle d'administrateur de plateforme.
Cloisonnement strict — restreindre ce sur quoi les identifiants système peuvent agir.
Rapports de bugs — activer des fonctionnalités que les admins d'organisation contrôlent indépendamment du rôle d'administrateur de plateforme.

Administrateurs de plateforme et emprunt d'identité

Sur cette page