Une bonne collection Payload traduit les règles du produit dans le schéma : champs nécessaires, relations, validations, permissions et cycle de publication. Commencez par les invariants éditoriaux, pas par l’apparence du formulaire d’administration.
Définir le document avant la collection
Listez d’abord ce qu’un document doit toujours posséder. Pour un article, cela peut inclure un titre, un slug stable, un résumé, un corps, un statut et des sources. Distinguez ensuite les valeurs obligatoires à la publication de celles qui peuvent manquer dans un brouillon.
Une collection représente un groupe de documents partageant le même schéma. Payload génère autour d’elle une API locale, une API REST, une API GraphQL et des écrans d’administration, selon la configuration du projet.
Exemple de collection minimale
import type { CollectionConfig } from 'payload'
export const Articles: CollectionConfig = {
slug: 'articles',
admin: { useAsTitle: 'title' },
fields: [
{ name: 'title', type: 'text', required: true },
{ name: 'slug', type: 'text', required: true, unique: true },
{ name: 'summary', type: 'textarea', required: true },
{ name: 'body', type: 'richText', required: true },
],
}Un slug unique évite deux URLs identiques, mais sa stabilité reste une règle métier à documenter. Pour des catégories, auteurs ou sources réutilisables, préférez un champ relationship à la duplication de texte.
Rendre les permissions explicites
Le contrôle d’accès s’applique par opération : création, lecture, modification et suppression. Une fonction peut autoriser, refuser ou retourner une contrainte de requête limitant les documents accessibles.
Écrivez les règles à partir des rôles et des états réels. Un exemple courant autorise la lecture publique des seuls documents publiés, permet aux éditeurs de préparer les brouillons et réserve la publication ou la suppression aux administrateurs.
Ne considérez pas l’interface d’administration comme une barrière de sécurité. Les mêmes règles doivent protéger les API. Testez les opérations autorisées et interdites avec chaque rôle.
Activer versions et brouillons
Les brouillons reposent sur le système de versions. Une configuration simple ressemble à ceci :
export const Articles: CollectionConfig = {
slug: 'articles',
versions: {
drafts: true,
maxPerDoc: 25,
},
fields: [
// champs du document
],
}Payload ajoute alors un champ interne _status dont la valeur est draft ou published. Le paramètre d’API draft=true et ce statut ont des fonctions distinctes : le premier contrôle notamment l’écriture d’une version et la validation, tandis que _status exprime l’état éditorial.
Prévoir la publication dès le schéma
Ajoutez les informations nécessaires à la confiance : date de vérification, prochaine révision, auteur de la revue et références. Définissez ce qui se passe lorsqu’une source est archivée ou qu’une catégorie disparaît. Une relation ne doit pas rendre silencieusement un contenu publié incohérent.
Pour une automatisation, utilisez une identité dédiée. Limitez-la à la création et à la mise à jour de brouillons, interdisez suppression et publication, puis conservez la clé dans un gestionnaire de secrets.
Checklist avant production
- les noms de champs expriment le métier et restent stables ;
- les champs obligatoires sont justifiés ;
- les slugs et autres clés métier sont indexés ou uniques ;
- les relations évitent la duplication ;
- chaque opération possède une règle d’accès testée ;
- les brouillons ne sont pas lisibles publiquement ;
- les versions ont une politique de conservation ;
- la publication reste explicite et traçable.
Questions fréquentes
Faut-il une collection pour chaque type de page ?
Non. Créez une collection lorsqu’un groupe de documents partage un schéma et un cycle de vie. Utilisez des champs, blocs ou relations si les différences restent structurées et limitées.
draft=true publie-t-il automatiquement un document ?
Non. Le paramètre de brouillon et le champ _status ne sont pas interchangeables. La publication exige un statut publié et des permissions adaptées.
Peut-on sécuriser Payload uniquement dans l’interface admin ?
Non. Le contrôle d’accès doit protéger les opérations elles-mêmes afin que les mêmes restrictions s’appliquent aux interfaces et aux API.