Administrateur de plateforme

Audience

Cet article s'adresse aux opérateurs de la plateforme GCM. Les administrateurs d'église doivent plutôt consulter Utilisateurs et rôles — la console Administrateur de plateforme est le cockpit interne de l'équipe, pas un élément de l'espace de travail propre à chaque église.

L'Administrateur de plateforme est la surface réservée aux opérateurs qui se trouve derrière app.geniuschurchmanager.com/platform. C'est ainsi que l'équipe GCM gère chaque organisation sur la plateforme : qui est en retard de paiement, pourquoi une fonction edge a explosé hier soir, quel titre de page d'accueil est diffusé en espagnol, ce que le cron de renouvellement fera demain matin à 02:00. C'est une coque React distincte avec sa propre barre latérale (PlatformLayout), sa propre porte RBAC et sa propre posture d'audit.

Qui peut se connecter

Seul un utilisateur dont le JWT porte is_platform_admin: true ou is_superadmin: true peut charger une route /platform/*. À la fois PlatformLayout et PlatformAdmin.tsx vérifient usePermissions().roles au montage et redirigent les non-membres du personnel vers /. La revendication JWT est définie par la fonction edge auth-hook à partir du profil de l'utilisateur, donc les promotions prennent effet à la prochaine connexion.

Il existe deux niveaux :

Rôle	Ce qu'il débloque
platform_admin	Lecture/écriture complète sur chaque organisation, chaque journal de facturation, chaque ligne d'audit. Ne peut pas promouvoir d'autres utilisateurs en platform_admin ou superadmin.
superadmin	Tout ce qui précède, plus la possibilité d'accorder platform_admin et superadmin. Un trigger DB (trg_protect_platform_admin_role*) interdit de rétrograder le dernier superadmin.

Si votre compte perd les deux indicateurs, vous serez silencieusement renvoyé vers / dès que vous visiterez /platform — déconnectez-vous puis reconnectez-vous après tout changement de rôle, puisque c'est le JWT qui compte.

Mise en garde concernant le compte de démonstration

Le compte de démonstration partagé sur app.geniuschurchmanager.com n'est plus un administrateur de plateforme. Pour suivre les captures d'écran de cette section, vous avez besoin d'un compte de personnel qui porte la revendication platform_admin. Demandez à un superadmin d'en provisionner un si vous n'avez pas accès.

Les six groupes de navigation

La barre latérale est regroupée pour correspondre au rythme du travail des opérateurs, et non à l'alphabet :

1. Vue d'ensemble — KPI de vue d'ensemble, liste des organisations.
2. Plans et modules — Catalogue des plans, mappage plan -> module. Surtout en lecture seule après le lancement.
3. Facturation — Console d'opérations de facturation, configuration de la passerelle, métriques MRR / churn.
4. Contenu — Modèles d'e-mails, modèles de sites web, modèles de workflows, surcharges du contenu de la page d'accueil.
5. Paramètres — Marque, manifeste PWA, DNS, canaux, paramètres e-mail, slugs réservés.
6. Système — Utilisateurs, données maîtres Géographie, Journal d'audit, Journal d'erreurs.

Ce qui se trouve dans quelle table

La plupart des surfaces de cette section lisent dans l'une des trois tables à portée plateforme :

• platform_audit_log — chaque action du personnel : organisation créée, plan modifié, remboursement effectué, usurpation d'identité démarrée, impersonation_failed. Capturée par useAppMode et par chaque fonction edge d'opérations de facturation.
• platform_settings — magasin clé/valeur plat. Contient la marque (brand_title, brand_logo), les textes marketing (marketing_hero_title), les liens sociaux, le bouton de visite guidée. Pas de colonne organization_id — ces éléments sont à l'échelle de la plateforme.
• admin_impersonation — la ligne de session que crée le RPC start_impersonation pour que current_org_id() puisse, de façon transparente, restreindre un utilisateur du personnel à l'organisation ciblée. La ligne est ce qui fait que RLS "fonctionne tout seul" pendant l'usurpation d'identité.

Tout ce qui ressemble à des données par organisation (organisations, payment_history, frise d'audit, error_log) vit dans les mêmes tables multi-tenants qu'un admin de locataire toucherait — le personnel voit simplement toutes les lignes au lieu de celles d'une seule organisation.

Lecture seule par défaut, audit-écriture par conception

Les onglets de l'administrateur de plateforme s'appuient fortement sur trois patrons :

• useQuery mis en cache pour les lectures, donc le rafraîchissement est gratuit et cohérent entre les onglets.
• Champs de raison sur chaque écriture destructive — remboursements, suppressions en masse, surcharges d'abonnement nécessitent tous un texte libre de raison qui atterrit dans platform_audit_log à côté de l'e-mail de l'acteur.
• Essai à blanc avant la facturation — la boîte de dialogue de renouvellement est par défaut sur "Aperçu uniquement" pour que vous puissiez voir ce que ferait la passerelle avant que l'argent ne bouge.

Si une future fonctionnalité vous permet de changer l'état à l'échelle de la plateforme sans champ de raison, traitez cela comme un bogue.

Où aller ensuite

Vous devez...	Article
Trouver une organisation par nom, changer son plan ou supprimer un doublon	Organisations
Rembourser un paiement, débloquer un renouvellement coincé ou tracer une facturation échouée	Opérations de facturation
Vous connecter à l'espace de travail d'un client pour reproduire un bogue	Flux d'usurpation d'identité
Trier un pic d'erreurs façon Sentry	Journal d'erreurs
Enquêter sur "qui a changé quoi, quand"	Journal d'audit
Ajouter un pays, un état ou une ville manquants au sélecteur d'adresse	Données maîtres Géographie
Ajuster le texte du héros de la page d'accueil ou téléverser une nouvelle image OG	Surcharges de contenu de la page d'accueil