Guide

Statut éditorial : En attente de relecture

Modéliser des contenus dans Payload CMS : collections, accès et brouillons

Concevoir un modèle éditorial Payload durable avec relations, versions, brouillons, rôles et contraintes métier.

Classification du contenu

Types

  • CMS headless
  • Développement back-end
Niveau
Intermédiaire
Publié le
10 août 2026
Dernière relecture
Relecture en attente
Prochaine vérification
10 novembre 2026

Une collection représente des documents partageant le même schéma et génère les API de gestion correspondantes. Un bon modèle reflète les responsabilités éditoriales et les requêtes réelles, pas simplement l’apparence d’une page. Séparez contenu réutilisable, taxonomies, médias et comptes utilisateurs.

Collections, groupes et relations

Créez une collection lorsqu’un objet possède son propre cycle de vie, ses permissions ou ses URLs : articles, technologies, auteurs. Utilisez groupes ou blocs pour structurer des champs appartenant au même document. Une relation convient à une entité partagée ; évitez de dupliquer son nom dans chaque contenu si elle doit pouvoir évoluer.

Versions et brouillons

Les versions conservent l’historique. Avec les drafts activés, Payload peut maintenir une version plus récente sans modifier le contenu publié. L’interface distingue Draft, Published et Changed. Pour une mise à jour via API, le paramètre draft et le champ _status ont des rôles différents : testez explicitement création, sauvegarde et publication.

Contrôle d’accès

Définissez create, read, update, delete et readVersions selon les rôles. Le front public doit recevoir uniquement les documents publiés, tandis que les éditeurs accèdent aux brouillons et previews. Les contraintes par document ou tenant doivent être appliquées côté serveur ; masquer un bouton d’administration ne suffit pas.

Hooks et validation

Utilisez les champs et validations pour les invariants locaux. Réservez les hooks aux effets ou règles transversales, en tenant compte des retries et des écritures récursives. Un hook de publication doit être idempotent. Ajoutez index et unicité selon les requêtes, notamment pour slugs et relations.

FAQ

Faut-il une collection par page ?

Non. Une collection par type de contenu récurrent et des globals pour quelques contenus uniques sont souvent plus cohérents.

Draft true publie-t-il le document ?

Non par lui-même. La publication dépend notamment de _status ; vérifiez la documentation de votre version.

Où mettre le SEO ?

Dans un groupe réutilisable avec titre, description et éventuellement image sociale, validé par type de contenu.

Collection avec accès public et brouillons

~~~typescript import type { CollectionConfig } from 'payload'

export const Articles: CollectionConfig = { slug: 'articles', access: { read: ({ req }) => req.user ? true : { _status: { equals: 'published' } }, update: ({ req }) => Boolean(req.user), }, versions: { drafts: { autosave: false, schedulePublish: false }, maxPerDoc: 25, }, fields: [ { name: 'slug', type: 'text', required: true, unique: true, index: true }, { name: 'title', type: 'text', required: true }, { name: 'body', type: 'richText', required: true }, { name: 'technologies', type: 'relationship', relationTo: 'technologies', hasMany: true }, ], } ~~~

Une mise à jour avec draft=true écrit seulement une nouvelle version et laisse le document principal publié inchangé. Gardez les règles métier dans des hooks testés et les permissions dans access. Évitez les hooks récursifs et indexez slug, statut et champs de filtrage réellement utilisés.

Sources utilisées