Platform admin vs. org admin: pourquoi la distinction compte

“Admin” est un mot surchargé dans une plateforme multi-tenant. La plateforme a des admins. Chaque org tenant a des admins. Ils partagent le mot, pas les pouvoirs. La structure d’URL de la plateforme rend la distinction visible.

Platform-only pages

/admin/platform/trust-scoring (configurer les platform-wide trust scoring weights), /admin/escrow/disputes (adjudicate disputes entre tenants), /admin/auction/strikes/[companyId] (pardon strikes — platform-staff only), /admin/exchange-rates (gérer le rate feed). Ces pages sont gated par getAdminScope() qui retourne un rôle platform-tier ; un org-admin ne peut pas les atteindre, quelle que soit sa configuration de permissions.

Org-only pages

/admin/organizations/[slug] (gérer vos propres org settings, users, billing), /admin/users (gérer les utilisateurs de votre org), /admin/storage (votre propre storage tier), /admin/email-provider (votre propre outbound email config). Ces pages permettent à un org-admin de tout faire dans sa propre tenancy sans voir les autres tenants.

Visibilité cross-tenant

Le platform staff peut lire entre tenants pour support — un client ouvre un ticket sur un deal bloqué, le staff plateforme doit voir le deal pour investiguer. La visibilité est journalisée : chaque cross-tenant read écrit une entrée dans l’activity log avec le staff user, le target tenant et l’action. Donc “quelqu’un de la plateforme a-t-il regardé nos données ?” a une réponse qui n’est pas une supposition.

Pourquoi deux préfixes d’URL

Parce que mélanger les pages platform-only et org-only dans le même arbre d’URL mène aux erreurs d’access-control. /admin/platform/* est sans ambiguïté. /admin/organizations/* est sans ambiguïté. Une page à /admin/[ambiguous-name] vous oblige à lire le code pour savoir quel rôle l’enforce. Le naming rend l’audit plus simple.