Payload CMS

En bref

Payload CMS est un système de gestion de contenu open source construit avec TypeScript. Il permet de définir des modèles de données dans le code, puis fournit une interface d’administration, des API et un système de contrôle d’accès.

Contrairement à un service de contenu entièrement hébergé, Payload s’intègre à l’application et à son infrastructure. L’équipe garde la maîtrise du code, de la base de données et du déploiement.

À quoi sert Payload CMS ?

Payload convient aux projets qui doivent gérer :

• des articles, pages et médias ;
• des catalogues ou données métier administrables ;
• plusieurs rôles avec des droits différents ;
• des brouillons et versions de contenu ;
• une API consommée par un site ou une application ;
• une administration personnalisée ;
• des traitements exécutés lors de la création ou modification des données.

Pour un site très simple et rarement modifié, un CMS complet peut être superflu. Pour un produit dont le contenu est étroitement lié au métier, la configuration en TypeScript apporte en revanche une base cohérente.

Collections et champs

Une collection décrit un type de document : articles, utilisateurs, produits ou technologies. Ses champs définissent les données, leur validation et leur présentation dans l’administration.

import type { CollectionConfig } from "payload";

export const Articles: CollectionConfig = {
  slug: "articles",
  fields: [
    { name: "title", type: "text", required: true },
    { name: "slug", type: "text", required: true, unique: true },
    { name: "body", type: "richText", required: true },
  ],
};

Le schéma sert à l’administration et aux API. Les types générés permettent aussi au reste de l’application TypeScript de connaître la forme des documents.

API locale et API HTTP

L’API locale s’utilise depuis le code serveur de l’application. Elle évite un appel HTTP inutile et reçoit le contexte de la requête lorsque celui-ci est fourni. Les API REST ou GraphQL permettent à d’autres clients d’accéder aux mêmes collections.

Les règles d’accès doivent rester cohérentes sur tous ces chemins. Une requête exécutée avec des privilèges élevés côté serveur doit être volontaire et limitée au besoin précis.

Contrôle d’accès

Les fonctions d’accès décident qui peut créer, lire, modifier ou supprimer un document. Elles peuvent renvoyer un booléen ou une contrainte qui limite les documents visibles.

Ne confondez pas l’affichage de l’administration avec l’autorisation réelle. Masquer un champ ou un bouton améliore l’interface, mais seule une règle exécutée côté serveur protège les données.

Testez au minimum les rôles anonymes, utilisateurs authentifiés, éditeurs et administrateurs selon le modèle du projet.

Hooks et logique métier

Les hooks exécutent du code avant ou après certaines opérations. Ils peuvent normaliser une valeur, maintenir une relation ou déclencher un traitement.

Un hook doit rester déterministe et éviter les effets en cascade difficiles à comprendre. Placez la logique métier réutilisable dans des fonctions indépendantes, puis appelez-les depuis le hook. Prévoyez aussi les imports, migrations et traitements automatisés qui peuvent utiliser les mêmes collections.

Versions, brouillons et migrations

Payload peut conserver des versions et gérer des brouillons. Cette fonction augmente le volume de données et nécessite une politique claire de publication et de rétention.

Une modification de schéma peut demander une migration de base. Testez les migrations sur une copie ou un environnement isolé, sauvegardez les données et séparez les changements compatibles des suppressions irréversibles.

Erreurs fréquentes

• accorder des privilèges serveur trop larges par commodité ;
• placer toute la logique métier dans des hooks ;
• modifier le schéma sans plan de migration ;
• supposer que l’interface d’administration constitue une protection ;
• charger des relations trop profondément par défaut ;
• oublier le coût de stockage des versions et médias.

Pour commencer

1. Définissez une collection simple et générez ses types.
2. Créez des rôles et écrivez leurs règles d’accès.
3. Utilisez l’API locale depuis une page serveur.
4. Ajoutez un hook court, idempotent et testé.
5. Simulez une migration et une restauration avant la production.

À retenir

Payload CMS rapproche le modèle de contenu, l’administration et le code applicatif. Cette intégration est puissante si les accès, hooks et migrations sont traités comme des composants critiques du produit.