> ## 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 # Gestion de contenu Entrées CMS typées avec un cycle de vie libre et une frontière de lecture publique. ## 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. Connectez-vous en tant que propriétaire ou administrateur d'un espace de travail, ouvrez `/content` et utilisez le formulaire pour créer une publication, une page, un document ou un rapport avec un slug unique. Enregistrez-le en tant que brouillon, puis publiez-le. 2. Confirmez les changements de statut à publié ; un slug ou un membre en double sans accès à la gestion devrait échouer. 3. Pour un test contrôlé, utilisez `required_entitlement=ai.reference-task` ; sans subvention vérifiée, la page doit afficher uniquement son teaser. 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 des entrées dans l’espace de travail Le gestionnaire `/content` traite les entrées `post`, `page`, `doc` et `report`. Les lignes `content_entry` ont un état draft/published/archived, des slugs limités à l’espace de travail et un auteur. Les actions de gestion exigent le rôle owner ou admin approprié. Ce CMS est distinct du catalogue typé des blogs et de la documentation publique du kit dans `src/resources`. Un produit peut afficher les entrées CMS avec sa propre composition de pages. ## Protéger le corps côté serveur `required_entitlement` est nullable : une entrée sans valeur n’est pas protégée. Pour une entrée protégée, `content-queries.ts` réservé au serveur fournit le contenu lisible ou un aperçu verrouillé dont le corps est vide. `content-access.ts` gère cette projection ; ne faites jamais confiance à un droit d’accès déclaré par le client. La publication émet `content.published` ; les digests planifiés peuvent résumer les entrées récentes de l’équipe de publication. Le contenu rédigé est également inclus dans l’export du compte. ## Vérifier la publication et l’accès Testez la visibilité d’un brouillon, les transitions publication/archivage, les slugs en double, un mauvais espace de travail, les entrées gratuites et les droits payants inactifs. Utilisez le bloc paywall pour la présentation, tout en laissant le serveur responsable de l’accès. [Tutoriel sur le contenu payant](https://supastack.dev/fr/docs/web/setup-ai.md) [Résumés de contenu](https://supastack.dev/fr/docs/web/project-structure.md) [Présentation du Paywall](https://supastack.dev/fr/docs/web/project-structure.md) ## Configuration et paramètres La surface d'espace de travail /content gère les entrées CMS — post, page et doc sont les types suggérés, mais la colonne accepte tout type produit sûr pour l'URL (minuscules, chiffres, tirets, underscores, jusqu'à 64 caractères). La table content_entry borne chaque ligne par workspaceId, horodate createdBy et garde les slugs uniques par workspace et type. Les entrées parcourent un cycle de vie libre draft ↔ published ↔ archived — evaluateContentStatusChange dans src/content.ts rejette les transitions invalides ou inchangées, et publishedAt est apposé à la première publication et survit aux dépublications ultérieures pour que les lecteurs gardent la date d'origine. ``` /content workspace CMS surface src/content.ts input + lifecycle rules src/content-actions.ts member+ mutations content_entry workspaceId, type, slug, status ``` ## Processus d’implémentation Les membres et au-delà rédigent les entrées — chaque mutation résout la session, le workspace actif et au moins le rôle membre via requireWorkspaceWriter (workspace-access.ts), donc les invités restent en lecture seule. normalizeContentEntryInput valide le type, un titre de 1 à 255 caractères et un slug sûr pour l'URL avant toute écriture. listPublishedContentEntries est la frontière de lecture publique assumée : elle prend un workspaceId explicite, n'exige pas de session et ne renvoie que les lignes publiées — le chemin qu'empruntent les pages vitrine, blogs et docs pour rendre le contenu du workspace. La publication émet un webhook sortant content.published, et les entrées rédigées rejoignent l'export de données GDPR. ## Vérification et dépannage Exercez un aller-retour draft → publish → archive, un slug dupliqué dans le même type et une lecture inter-workspaces. Confirmez que la frontière publique ne renvoie jamais de brouillons ni de lignes d'un autre workspace, et que content.published se déclenche une fois par action de publication. ## Suivant [E-commerce](https://supastack.dev/fr/docs/web/commerce.md)