Payload CMS : fonctionnement, installation dans Next.js et comparaison avec Strapi

Payload CMS est un CMS headless open source, écrit en TypeScript et publié sous licence MIT, qui s’installe directement dans une application Next.js. Les développeurs décrivent les types de contenu dans un fichier de configuration, puis Payload génère l’interface d’administration, la base de données et trois API (REST, GraphQL et une API locale appelée depuis le code serveur). Figma a racheté l’équipe en juin 2025. Le projet reste pourtant gratuit et open source. Payload est un bon choix pour une équipe TypeScript qui construit son site avec Next.js et veut garder ses contenus dans sa propre base. Strapi reste plus adapté quand le front n’utilise pas Next.js ou que l’équipe veut modéliser ses contenus depuis une interface. Ce guide explique comment Payload fonctionne, comment l’installer, ce qu’il fait mal et comment choisir entre Payload et Strapi.

Comment fonctionne Payload CMS

La plupart des CMS headless tournent à côté du site : un service séparé stocke les contenus, que le site récupère par une API. Payload s’installe au contraire dans l’application Next.js. Son interface d’administration est une route du site (/admin par défaut), ses API sont d’autres routes (/api/...), et les composants serveur lisent les contenus directement en base, sans requête HTTP.

Les développeurs déclarent dans un fichier payload.config.ts les collections (les types de contenu répétables : articles, pages, auteurs, produits), les globals (les contenus uniques : menu, pied de page, réglages du site), la base de données et l’éditeur de texte riche. Une collection minimale ressemble à ceci :

import type { CollectionConfig } from "payload";

export const Articles: CollectionConfig = {
  slug: "articles",
  admin: { useAsTitle: "title" },
  versions: { drafts: true },
  access: {
    read: () => true,
    update: ({ req }) => Boolean(req.user),
  },
  fields: [
    { name: "title", type: "text", required: true },
    { name: "slug", type: "text", unique: true },
    { name: "author", type: "relationship", relationTo: "users" },
    { name: "content", type: "richText" },
  ],
};

Payload lit ce fichier pour créer les tables ou les collections en base, générer les types TypeScript, construire les formulaires d’édition et exposer les API. Un composant serveur Next.js récupère les articles publiés en quelques lignes, avec des types générés automatiquement :

// app/(site)/blog/page.tsx
import { getPayload } from "payload";
import config from "@payload-config";

export default async function BlogPage() {
  const payload = await getPayload({ config });
  const { docs } = await payload.find({
    collection: "articles",
    where: { _status: { equals: "published" } },
    sort: "-createdAt",
  });
  return <ArticleList articles={docs} />;
}

Cette API locale est la principale différence avec un CMS hébergé comme Contentful ou Prismic. Le site lit sa base sans passer par le réseau, sans clé d’API et sans quota de requêtes. Les API REST et GraphQL restent disponibles pour une application mobile ou un autre service qui consomme les mêmes contenus.

graph TD
    A[Application Next.js] --> B["Pages du site<br/>app/(site)"]
    A --> C["Admin et API Payload<br/>app/(payload)"]
    B -->|API locale, sans HTTP| D[payload.config.ts]
    C --> D
    D --> E[(PostgreSQL, MongoDB ou SQLite)]
    C -->|REST et GraphQL| F[App mobile ou autre service]

Installer Payload dans un projet Next.js

Payload demande Node.js 20.18.1 ou plus récent, une version de Next.js prise en charge (16.2.6 ou plus récente, ou certaines versions correctives des branches 15.2 à 15.4) et une base de données MongoDB, PostgreSQL ou SQLite. La documentation recommande pnpm. Payload fonctionne aussi avec npm et avec Yarn à partir de la version 2.

Pour un nouveau projet, une commande crée l’application à partir d’un modèle (vierge, site web, e-commerce) :

npx create-payload-app

Pour un projet Next.js existant, l’installation se fait en cinq étapes :

1. Installer payload, @payloadcms/next, l’adaptateur de base de données (@payloadcms/db-postgres par exemple), l’éditeur de texte riche et sharp pour le traitement des images.
2. Copier le dossier (payload) du modèle vierge dans app/. Déplacer les pages existantes dans leur propre groupe de routes, (site) par exemple.
3. Envelopper la configuration Next.js avec withPayload. Le projet doit être en ESM ("type": "module" dans package.json ou un fichier .mjs).
4. Créer payload.config.ts et déclarer l’alias @payload-config dans tsconfig.json.
5. Lancer le serveur de développement et ouvrir /admin pour créer le premier compte.

Avec PostgreSQL, Payload synchronise tout seul le schéma de la base en développement, à chaque modification de la configuration. En production, il faut générer un fichier de migration (payload migrate:create), le versionner, puis l’appliquer pendant le déploiement (payload migrate). Une équipe qui oublie cette étape déploie un code qui attend une colonne absente de la base.

Payload s’héberge partout où tourne une application Next.js : Vercel, Netlify, un serveur Node.js ou un conteneur Docker chez un hébergeur français. Payload Cloud, l’offre hébergée de l’éditeur, n’accepte plus de nouveaux projets depuis le rachat. Les projets existants continuent de tourner en attendant une nouvelle plateforme annoncée par Figma.

Les fonctionnalités de Payload CMS

Payload a les fonctionnalités d’un CMS éditorial et plusieurs outils pour construire une application :

• Des brouillons et un historique des versions, avec restauration d’une version antérieure.
• Des contenus multilingues, traduits champ par champ, avec une langue de repli.
• Un constructeur de pages par blocs. L’équipe marketing assemble une page à partir de blocs définis par les développeurs (bandeau, témoignages, tableau de prix).
• L’éditeur de texte riche Lexical, extensible avec des blocs personnalisés au milieu du texte.
• Un aperçu en direct de la page pendant l’édition.
• Une médiathèque qui redimensionne les images et gère des points de recadrage.
• Une authentification intégrée pour les administrateurs et pour les utilisateurs du site (espace client, contenus réservés aux abonnés).
• Des droits d’accès par collection, par document et par champ, écrits en TypeScript.
• Des hooks qui s’exécutent avant et après chaque lecture ou écriture, pour notifier un outil tiers, recalculer un champ ou vider un cache.
• Une interface d’administration personnalisable avec des composants React.

On peut donc utiliser Payload comme back-office d’une application métier ou d’un SaaS, puisque l’authentification, les droits d’accès et les hooks sont déjà en place. Payload fournit alors les écrans d’administration (listes, filtres, formulaires) que l’équipe aurait sinon à coder.

Les limites de Payload CMS

Payload a cinq défauts, plus gênants sur un projet maintenu plusieurs années que sur un prototype.

L’interface d’administration dépend de Next.js

Un site en Astro, Nuxt ou SvelteKit peut lire les contenus de Payload par son API REST ou GraphQL, mais il faut alors faire tourner une application Next.js à côté, rien que pour l’administration. On perd l’intérêt principal de Payload, qui est d’avoir un seul code et un seul déploiement. Payload prend aussi en charge une liste précise de versions de Next.js. Une montée de version de Next.js se prépare donc avec celle de Payload.

Seuls les développeurs créent des types de contenu

Un nouveau champ ou une nouvelle collection passe par un développeur, une modification du code et un déploiement. Une équipe produit y gagne une structure cohérente et versionnée. Une équipe marketing qui veut ajouter un type de page doit en revanche attendre le prochain déploiement.

L’hébergement est à votre charge

Payload Cloud n’accepte plus de nouveaux projets, donc votre équipe ou votre prestataire doit gérer la base de données, les sauvegardes, les migrations et les mises à jour de sécurité. Sur un site d’entreprise, prévoyez ce travail dans la maintenance du site.

Payload 4 est en préversion

Payload 3 est la version stable en octobre 2026. L’équipe de Payload annonce pour la version 4 une interface d’administration redessinée, alignée sur celle de Figma, et une compatibilité avec TanStack. Un projet qui démarre aujourd’hui sur Payload 3 devra prévoir une migration dans les années à venir.

Payload a moins de plugins que Strapi

Payload maintient des plugins officiels (SEO, formulaires, redirections, recherche, e-commerce), mais une intégration plus rare demande souvent d’écrire quelques hooks.

Payload ou Strapi : lequel choisir ?

Payload et Strapi sont deux CMS headless open source écrits en TypeScript, que vous pouvez installer sur vos propres serveurs. Payload compte plus de 45 000 étoiles sur GitHub en octobre 2026. Figma a annoncé lors de sa conférence Config 2026 que les téléchargements de Payload avaient été multipliés par six en un an. Strapi, créé en France en 2015, a une base d’utilisateurs plus ancienne et une place de marché de plugins plus fournie. Les deux CMS répondent à des besoins différents.

La principale différence est l’architecture. Avec Strapi, le CMS est un service à part, avec son propre serveur et sa propre base. N’importe quel front (Next.js, Astro, une application React Native) le consomme par API. Avec Payload, le CMS fait partie du site. Un projet Next.js gagne une seule base de code, des types partagés entre le contenu et les pages, et un déploiement unique. Un projet qui n’utilise pas Next.js perd tous ces avantages.

La deuxième différence, c’est la modélisation des contenus. Strapi a un constructeur de types de contenu dans son interface, où un profil moins technique peut créer une collection et ses champs. Ce constructeur ne fonctionne qu’en mode développement et enregistre la structure dans des fichiers versionnés. Payload part du code dès le départ : les développeurs relisent la structure en revue de code, la testent et la déploient comme le reste de l’application.

Directus, Sanity et les autres CMS headless répondent à d’autres situations. Directus se branche sur une base SQL existante. Sanity est un service hébergé où plusieurs personnes éditent en temps réel. Vous pouvez comparer les prix de ces CMS headless avant de choisir.

Quand choisir Payload CMS

Payload est un bon choix dans quatre situations :

• Un site marketing ou éditorial en Next.js, que l’équipe marketing édite au quotidien avec des pages composées de blocs, et que les développeurs font évoluer sans gérer un second service.
• Un site multilingue où la traduction se fait champ par champ, avec des brouillons relus avant publication.
• Le back-office d’un SaaS ou d’un outil métier qui a besoin de listes, de formulaires, de droits fins et d’un historique, sans tout coder à la main.
• Un projet où les données doivent rester chez vous, dans votre base PostgreSQL, chez l’hébergeur de votre choix, sans facturation au nombre d’éditeurs ou de requêtes.

Il vaut mieux choisir autre chose quand :

• le site utilise un autre framework que Next.js et va le garder, auquel cas Strapi, Sanity ou un CMS hébergé conviennent mieux
• l’équipe marketing veut un éditeur visuel où elle compose ses pages en voyant le rendu final, comme Storyblok
• personne dans l’équipe ne peut gérer une base de données, ses sauvegardes et ses migrations, auquel cas un CMS hébergé coûte moins cher qu’une astreinte
• le site est un blog statique, pour lequel un CMS qui enregistre les contenus dans des fichiers du dépôt Git suffit

graph TD
    A{Le site est-il en Next.js ?} -->|Non| B[Strapi, Sanity ou un CMS hébergé]
    A -->|Oui| C{L’équipe peut-elle héberger une base de données ?}
    C -->|Non| D[CMS hébergé : Sanity, Contentful, Prismic]
    C -->|Oui| E{Le marketing veut-il un éditeur visuel complet ?}
    E -->|Oui| F[Storyblok ou un CMS hébergé visuel]
    E -->|Non| G[Payload CMS]

Avant de valider le choix, vérifiez six points avec l’équipe qui maintiendra le site :

1. Le site est développé en Next.js.
2. L’équipe maîtrise TypeScript.
3. Un hébergeur et une base PostgreSQL sont prévus.
4. Les migrations tournent à chaque déploiement.
5. Les éditeurs n’ont pas besoin de créer des types de contenu.
6. Une montée vers Payload 4 est budgétée.

Payload CMS chez Lonestone

Lonestone développe des sites et des applications avec Next.js depuis 2018, en TypeScript de bout en bout. Le choix du CMS se fait au cadrage, à partir de trois questions : qui édite les contenus, à quelle fréquence, et qui maintiendra le site dans trois ans. Quand le client a sa propre équipe de développeurs TypeScript, Payload est souvent la bonne réponse. Une équipe marketing qui travaille seule trouve en général un CMS hébergé plus simple.

Nos ingénieurs, qui ont pour la plupart entre 10 et 25 ans d’expérience, modélisent les contenus avec l’équipe éditoriale, écrivent les migrations, branchent l’aperçu en direct et forment les éditeurs. Quand nous créons un site web sur mesure ou que nous refondons un site existant, nous choisissons le CMS avec ces trois questions plutôt que par habitude.

Payload est le CMS le plus cohérent pour un site Next.js maintenu par une équipe TypeScript : un seul code, une seule base, des types partagés de la base de données jusqu’aux pages. Il demande en échange de gérer soi-même l’hébergement et les migrations. Si vous hésitez entre Payload, Strapi ou un CMS hébergé pour votre prochain site, l’équipe Next.js de Lonestone peut regarder votre projet avec vous et vous envoyer un devis gratuit.