Console d'administration

Parcours pas à pas pour débuter

Prérequis : Lisez les deux guides pour débutants ci-dessous, terminez la configuration locale du Web et ouvrez ce monorepo à sa racine dans votre éditeur. Les paramètres Web appartiennent à apps/web/.env.local ; Next.js ne lit pas la racine .env. /dashboard dans le mode faux par défaut est une démo sans base de données ; /auth nécessite une base de données migrée.

Termes rapides : un espace de travail est constitué des utilisateurs, des données et des paramètres distincts d'une équipe. Le serveur est le backend de confiance ; gardez les clés du fournisseur hors du code du navigateur et du téléphone. Une migration est une modification de base de données versionnée qui crée ou met à jour des tables. Un modèle d'IA est le moteur qui répond ; le catalogue de modèles est la liste du serveur des identifiants de modèles et des prix disponibles. Un fournisseur est un service externe tel qu'un service d'IA, de messagerie ou de facturation. Un droit est une subvention qui permet à un espace de travail d'utiliser une fonctionnalité. Un webhook est un message qu'un service envoie au URL d'un autre service.

1. Avant de créer un compte de test local, ajoutez votre propre adresse à la liste ADMIN_EMAILS réservée au serveur et redémarrez l'application.

2. Inscrivez-vous sur la base de données de test migrée et ouvrez /admin ; inspectez les pages d’utilisateur et d’organisation disponibles.

3. Cela accorde à l'administrateur de la plateforme, et non à la propriété de l'espace de travail. Si l'accès est refusé, vérifiez la configuration exacte de la messagerie et du serveur ; n'élevez pas d'utilisateurs arbitraires et ne testez pas par rapport à la production.

Pour le code personnalisé, commencez par le prompts/README.md fourni et copiez l'invite la plus proche : prompts/new-app-screen.md pour un écran d'application ou prompts/new-landing-page.md pour une page publique. Pour le travail sur un serveur, une base de données ou un fournisseur, confiez à votre agent de codage la tâche de ce guide et demandez-lui de lire les miroirs AGENTS.md, .ai/PROJECT_CONTEXT.md et .ai/ correspondants ; inspectez les fichiers sources exacts nommés ici ; lister les fichiers et les vérifications avant de les modifier ; préserver la propriété de l'espace de travail et les secrets du serveur ; et je vous montre la différence. Indiquez-lui le comportement souhaité, les champs d'entrée et de sortie, les rôles autorisés, les succès et erreurs attendus, ainsi que le compte, le fournisseur ou l'appareil de test. Utilisez des exemples de valeurs ; ne collez jamais un vrai secret.

• Avant de commencer
• Bases du terminal
• Configuration locale Web
• Invites de l'agent et mémoire du projet

Créer la frontière d’administration

ADMIN_EMAILS est une liste de démarrage séparée par des virgules, réservée au serveur. Les utilisateurs listés obtiennent le rôle d’administrateur de plateforme à l’inscription. Sans cette liste, accordez l’accès via un parcours de base de données ou d’administration autorisé ; ne faites pas du premier visiteur venu un administrateur.

Le rôle d’administrateur de plateforme est distinct du rôle de propriétaire ou d’administrateur d’un espace. /admin et ses pages d’utilisateurs, d’organisations, d’indicateurs, d’annonces et de liste d’attente vérifient le rôle de plateforme.

Utiliser les commandes disponibles

Le moteur Better Auth par défaut fournit la gestion des utilisateurs, les bannissements et l’usurpation d’identité. L’application compose les vues de plateforme avec des pistes d’audit. Limitez l’usurpation à un administrateur vérifié, rendez son état visible et restaurez la session administrateur initiale à la sortie.

Auth.js n’hérite pas automatiquement des extensions d’administration Better Auth. Examinez admin.ts, admin-actions.ts et le comportement du fournisseur d’authentification avant de changer de moteur.

Vérifier les actions privilégiées

Testez le refus pour un non-administrateur, l’accès administrateur, les sessions d’un utilisateur banni, le début et la fin d’une usurpation ainsi que les actions que vous activez. Excluez toutes les routes d’administration de l’indexation publique.

• Drapeaux de fonctionnalité
• Annonces
• Administration de la liste d'attente

Configuration et paramètres

La surface /admin est la vue d'inspection de l'opérateur sur les workspaces, membres et l'état produit. ADMIN_EMAILS (ou la configuration du plugin admin dans le produit consommateur) décide qui y accède ; chaque route admin revérifie l'autorisation côté serveur.

Les feature flags (feature-flag-runtime.ts) désactivent par défaut tout ce qui n'est pas configuré — un flag manquant ne peut jamais activer silencieusement une surface — et les overrides par flag vivent dans la table featureFlagOverride.

/admin                    operator dashboard
announcement-actions.ts   broadcast in-app notices
resolveFeatureFlags(...)  bulk flag resolution for a caller context

Processus d’implémentation

Utilisez les actions admin pour l'inspection et les opérations de support (recherche de workspace, gestion des membres, diffusion d'annonces). Gardez les mutations auditées et l'autorisation vérifiée à la frontière d'action, pas à la nav.

Déployez les fonctionnalités derrière des flags : shippez le code en sombre, activez par workspace ou globalement, puis retirez le flag quand la surface est permanente. L'impersonation de plateforme reste gelée sauf si le PRODUCT.md du produit l'autorise explicitement.

Vérification et dépannage

Vérifiez qu'un non-admin est refusé, qu'un flag désactivé masque sa surface de bout en bout (nav, route, action), qu'un override ne se résout que pour sa cible et que les annonces atteignent l'audience visée. Les tests admin doivent couvrir le chemin refusé d'abord.