> ## Documentation Index > Fetch the complete documentation index at: https://supastack.dev/llms.txt > Use this file to discover all available pages before exploring further. > For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt # Console d'administration Inspection de plateforme, annonces et feature flags. ## 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](https://supastack.dev/fr/docs/web/before-you-start.md) [Bases du terminal](https://supastack.dev/fr/docs/web/terminal-basics.md) [Configuration locale Web](https://supastack.dev/fr/docs/web/ship-in-5-minutes.md) [Invites de l'agent et mémoire du projet](https://supastack.dev/fr/docs/web/agents.md) ## 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é](https://supastack.dev/fr/docs/web/feature-flags.md) [Annonces](https://supastack.dev/fr/docs/web/project-structure.md) [Administration de la liste d'attente](https://supastack.dev/fr/docs/web/setup-ai.md) ## 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. ## Suivant [Stratégie de test](https://supastack.dev/fr/docs/web/testing.md)