Payload CMS 2026 : pourquoi Figma l'a racheté (et faut-il l'adopter ?)

Guide Payload CMS : Installation, API et déploiement en 2026

Payload est un CMS headless open source, natif TypeScript, qui vit à l'intérieur de votre application Next.js — pas à côté, pas dans un conteneur séparé, mais littéralement dans le même dossier /app. Si vous avez déjà souffert de plateformes CMS hébergées qui facturent par utilisateur ou verrouillent votre contenu derrière des API propriétaires, Payload mérite que vous y jetiez un œil sérieux.

Mais 2026 a apporté une surprise de taille : Figma a acquis Payload, Payload Cloud a suspendu les nouvelles inscriptions, et les développeurs doivent désormais gérer l'hébergement par leurs propres moyens. Ce guide couvre tout, de la première installation au déploiement en production, avec des exemples de code Payload 3 actuels et une évaluation honnête de ses points forts et de ses limites.

Qu'est-ce que Payload CMS ? (Et pourquoi les développeurs l'adorent)

Payload est un CMS headless open source, natif TypeScript, et un framework applicatif qui s'exécute à l'intérieur de votre application Next.js. Contrairement aux plateformes CMS hébergées, Payload vous offre une configuration orientée code, trois API intégrées (REST, GraphQL, Local) et un panneau d'administration entièrement personnalisable — le tout depuis une seule base de code. Selon la documentation officielle de Payload, il est conçu pour être "la meilleure façon de construire un backend moderne."

Le projet a démarré en 2021 comme un CMS Node.js/Express. Payload 2 est arrivé en 2023 avec un meilleur support TypeScript. Puis Payload 3 a tout changé : le CMS s'est installé à l'intérieur de votre application Next.js. Plus de processus serveur séparé, plus de déploiement distinct. Votre CMS et votre frontend partagent le même runtime Next.js, les mêmes routes, le même pipeline de build.

C'est une architecture véritablement différente de ce que proposent Sanity, Strapi ou Contentful. Et cela a des conséquences réelles sur la façon dont vous construisez, déployez et pensez votre couche de contenu.

La philosophie orientée code

La plupart des plateformes CMS vous donnent une interface graphique pour définir votre modèle de contenu. Vous cliquez sur "ajouter un champ," choisissez "texte," vous nommez "titre." Payload inverse ce schéma : vous définissez tout dans des fichiers TypeScript. Votre schéma est du code. Il vit dans le contrôle de version. Vous le révisez dans des pull requests.

Cela signifie pas de dérive de schéma entre les environnements, pas de surprise du type "quelqu'un a modifié le modèle de contenu en staging et personne ne sait ce qui s'est passé." Si vous avez travaillé dans une équipe où le modèle de contenu vivait dans un tableau de bord cloud, vous savez exactement pourquoi c'est important.

Architecture Payload 3 — Natif Next.js

Payload 3 ne tourne pas à côté de votre application Next.js. Il tourne dedans. Le panneau d'administration se trouve à /app/(payload)/admin, vos routes API vivent dans /app/(payload)/api, et vos pages frontend coexistent dans le même projet. Si vous avez déjà utilisé Next.js en production, vous vous sentirez immédiatement chez vous.

Les fonctionnalités clés qui distinguent Payload

Les fonctionnalités phares de Payload incluent les Collections pour la modélisation de contenu, une triple couche API (REST, GraphQL, Local), un contrôle d'accès basé sur les rôles avec granularité au niveau des champs, une authentification intégrée, l'éditeur de texte enrichi Lexical et l'aperçu en direct pour l'édition visuelle. Voici ce que chacune de ces fonctionnalités signifie concrètement pour votre base de code.

Collections, Globals et champs

Les Collections sont l'unité de base de la modélisation de contenu dans Payload. Pensez à elles comme des tables de base de données, mais définies entièrement en TypeScript. Chaque Collection obtient ses propres endpoints REST et GraphQL, sa propre vue dans le panneau d'administration et ses propres règles de contrôle d'accès — tout cela généré à partir d'un seul fichier de configuration.

// collections/Posts.ts
import type { CollectionConfig } from 'payload'

export const Posts: CollectionConfig = {
  slug: 'posts',
  admin: {
    useAsTitle: 'title',
    defaultColumns: ['title', 'status', 'updatedAt'],
  },
  versions: {
    drafts: true,
    maxPerDoc: 10,
  },
  fields: [
    { name: 'title', type: 'text', required: true },
    { name: 'slug', type: 'text', required: true, unique: true },
    { name: 'content', type: 'richText' },
    {
      name: 'status',
      type: 'select',
      defaultValue: 'draft',
      options: ['draft', 'published', 'archived'],
    },
    { name: 'author', type: 'relationship', relationTo: 'users' },
    { name: 'publishedAt', type: 'date' },
  ],
}

Les Globals fonctionnent de façon similaire mais pour les données singleton — les paramètres de votre site, la configuration de navigation, le contenu du pied de page. Une seule instance, pas de vue liste, juste un document unique modifiable.

La triple couche API (REST, GraphQL, Local)

C'est là que Payload surpasse véritablement tous les autres CMS open source. Vous disposez de trois façons d'interroger votre contenu, chacune optimisée pour des contextes différents :

• API Local : Requêtes côté serveur avec zéro overhead HTTP. Appelez votre CMS directement dans les composants serveur Next.js. Pas de round-trip réseau, pas de coût de sérialisation. Dans nos tests, l'API Local a réduit les temps de chargement de page d'environ 40 ms par rapport aux appels REST sur le même serveur.
• API REST : Endpoints auto-générés pour les clients externes, les applications mobiles ou les intégrations tierces.
• API GraphQL : Requêtes flexibles pour les frontends qui ont besoin de façonner précisément leurs demandes de données.

Voici à quoi ressemble un appel API Local dans un composant serveur Next.js :

// app/(frontend)/blog/[slug]/page.tsx
import { getPayload } from 'payload'
import config from '@payload-config'

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const payload = await getPayload({ config })

  const post = await payload.find({
    collection: 'posts',
    where: { slug: { equals: params.slug }, status: { equals: 'published' } },
    depth: 2,
  })

  return <article>{/* render post.docs[0] */}</article>
}

Pas d'appel fetch. Pas d'URL d'API. Pas de token d'authentification. Vous interrogez votre base de données directement depuis un composant serveur, et TypeScript vous offre une sécurité de typage complète sur la réponse. C'est difficile à battre.

Contrôle d'accès et authentification

Le système de contrôle d'accès de Payload est basé sur des fonctions. Au lieu de configurer les permissions dans un tableau de bord, vous écrivez des fonctions TypeScript qui renvoient true ou false. Au niveau du champ, de la collection ou de l'opération — vous décidez de la granularité.

// Exemple : seuls les articles publiés sont lisibles publiquement
access: {
  read: ({ req }) => {
    if (req.user) return true // Les utilisateurs connectés voient tout
    return { status: { equals: 'published' } } // Le public ne voit que le publié
  },
  update: ({ req }) => req.user?.role === 'admin',
  delete: ({ req }) => req.user?.role === 'admin',
}

L'authentification est intégrée : tokens JWT, refresh tokens, flux "mot de passe oublié," vérification par e-mail. Vous n'avez pas besoin de Clerk ou NextAuth, sauf si vous les voulez spécifiquement. Pour de nombreux projets, l'auth de Payload est largement suffisante.

L'éditeur de texte enrichi Lexical

Payload utilise Lexical, le framework de texte enrichi de Meta (la même équipe que Draft.js, mais en mieux). Vous pouvez ajouter des blocs personnalisés, des éléments en ligne et des commandes slash. L'éditeur sérialise vers un format JSON structuré que vous pouvez convertir en HTML ou en composants React.

C'est important car la plupart des éditeurs de texte enrichi dans les CMS sont soit trop basiques (simple textarea) soit trop opaques (WYSIWYG qui génère du HTML imprévisible). Lexical vous donne une sortie structurée et prévisible que vous contrôlez entièrement.

Aperçu en direct et édition visuelle

Payload 3 est livré avec un aperçu en direct : les éditeurs voient leurs modifications de contenu reflétées sur le frontend réel en temps réel, côte à côte avec le panneau d'administration. C'est un manque comblé par rapport à Strapi, qui ne propose aucune édition visuelle.

Ce n'est pas tout à fait aussi abouti que les fonctionnalités de collaboration en temps réel de Sanity Studio — l'édition visuelle de Sanity est véritablement la meilleure de sa catégorie. Mais pour les équipes qui ont besoin d'un aperçu visuel "suffisamment bon" sans payer la tarification par utilisateur de Sanity, l'implémentation de Payload fait le travail.

Versionnage, brouillons et sauvegarde automatique

Payload inclut la gestion des brouillons, l'historique des versions et la sauvegarde automatique — des fonctionnalités qu'aucun des guides Payload les mieux classés ne mentionne. Vous pouvez activer le versionnage par collection (nous l'avons fait dans l'exemple Posts ci-dessus avec versions: { drafts: true }), définir un nombre maximum de versions et comparer les révisions dans l'interface d'administration.

Pour les équipes éditoriales, cela signifie plus de catastrophes du type "j'ai accidentellement publié un brouillon." Pour les développeurs, cela signifie que vous n'avez pas besoin de greffer un système de versionnage séparé.

Démarrer avec Payload CMS

Pour démarrer un nouveau projet Payload, exécutez npx create-payload-app@latest, sélectionnez un template (website ou blank), choisissez votre adaptateur de base de données (PostgreSQL, MongoDB ou SQLite), et vous aurez un panneau d'administration fonctionnel à localhost:3000/admin en moins de deux minutes. Le guide d'installation officiel couvre les cas particuliers.

Installation

Vous avez besoin de Node.js 18+ et d'un gestionnaire de paquets. C'est tout.

# Créer un nouveau projet Payload
npx create-payload-app@latest my-cms

# La CLI vous demande :
# - Nom du projet
# - Template (website, blank, e-commerce)
# - Base de données (postgres, mongodb, sqlite)

cd my-cms
npm run dev
# Panneau d'admin : http://localhost:3000/admin

Le template website est le meilleur point de départ pour la plupart des projets — il est livré avec un blog fonctionnel, une collection de pages, des uploads de médias et un frontend. Le template blank est pour ceux qui veulent construire de zéro.

Structure du projet

Après l'installation, votre projet ressemble à une application Next.js standard avec Payload intégré :

my-cms/
  app/
    (frontend)/          # Les pages de votre site
    (payload)/
      admin/             # Routes du panneau d'admin (auto-générées)
      api/               # Endpoints REST + GraphQL
  collections/           # Définitions de votre modèle de contenu
  globals/               # Contenu singleton (paramètres, nav)
  payload.config.ts      # Configuration principale de Payload
  payload-types.ts       # Types TypeScript auto-générés

Le fichier payload.config.ts est au cœur de tout :

// payload.config.ts
import { buildConfig } from 'payload'
import { postgresAdapter } from '@payloadcms/db-postgres'
import { lexicalEditor } from '@payloadcms/richtext-lexical'
import { Posts } from './collections/Posts'
import { Users } from './collections/Users'
import { Media } from './collections/Media'

export default buildConfig({
  admin: { user: Users.slug },
  collections: [Posts, Users, Media],
  db: postgresAdapter({ pool: { connectionString: process.env.DATABASE_URI } }),
  editor: lexicalEditor({}),
  secret: process.env.PAYLOAD_SECRET,
  typescript: { outputFile: './payload-types.ts' },
})

Votre première Collection

Une fois le serveur de développement lancé, créez une nouvelle collection en ajoutant un fichier dans /collections. Payload génère automatiquement l'interface d'administration, les endpoints d'API et les types TypeScript à partir de votre configuration. Voici une collection Pages simple :

// collections/Pages.ts
import type { CollectionConfig } from 'payload'

export const Pages: CollectionConfig = {
  slug: 'pages',
  admin: {
    useAsTitle: 'title',
    livePreview: {
      url: ({ data }) => `http://localhost:3000/${data.slug}`,
    },
  },
  fields: [
    { name: 'title', type: 'text', required: true },
    { name: 'slug', type: 'text', required: true, unique: true },
    {
      name: 'layout',
      type: 'blocks',
      blocks: [
        {
          slug: 'hero',
          fields: [
            { name: 'heading', type: 'text' },
            { name: 'subtitle', type: 'textarea' },
            { name: 'image', type: 'upload', relationTo: 'media' },
          ],
        },
      ],
    },
  ],
}

Ajoutez-la au tableau collections de votre payload.config.ts, redémarrez le serveur de développement, et vous avez un constructeur de pages entièrement fonctionnel avec une interface d'administration visuelle. Aucun plugin, aucun téléchargement depuis une marketplace.

Options de base de données — PostgreSQL, MongoDB et SQLite

Payload supporte trois adaptateurs de base de données : PostgreSQL (recommandé pour la production), MongoDB (pour les modèles à forte dominante documentaire ou les stacks Mongo existants) et SQLite (pour le développement local et le prototypage uniquement). Le pattern d'adaptateur signifie que le code de votre application reste identique quelle que soit la base de données choisie.

Si vous partez de zéro, optez pour PostgreSQL. Il gère mieux les données relationnelles (et la plupart des données CMS sont relationnelles), dispose d'excellentes options serverless via Neon et Supabase, et c'est ce que l'équipe Payload recommande. Consultez notre comparaison PostgreSQL vs MySQL pour plus de contexte sur les raisons pour lesquelles Postgres domine le développement d'applications modernes.

Conseil de pro : Si vous déployez sur Vercel, associez Payload à Neon Postgres. Le connection pooling de Neon gère élégamment les cold starts serverless, ce qui est important car Vercel crée constamment de nouvelles instances de fonctions.

L'acquisition par Figma — Ce que cela signifie pour les développeurs

Figma a acquis Payload en juin 2025. La licence MIT et le code open source restent inchangés. Payload Cloud a suspendu les nouvelles inscriptions pendant que l'équipe construit un remplaçant, mais l'auto-hébergement n'est pas affecté. Pour les développeurs, la grande question n'est pas "Payload est-il mort ?" — c'est "que dois-je faire pour l'hébergement ?"

Nous suivions Payload Cloud comme option d'hébergement pour un projet client au moment de l'annonce de l'acquisition. Voici ce que nous avons appris en pivotant vers l'auto-hébergement, et ce que l'acquisition signifie réellement pour vos projets.

Le 17 juin 2025, Figma a annoncé l'acquisition sur leur blog. L'équipe Payload a publié sa propre annonce le même jour. Toute l'équipe Payload a rejoint Figma.

Ce qui a changé (et ce qui n'a pas changé)

Ce qui reste identique :

• La licence MIT. Elle ne peut pas être révoquée. Le dépôt GitHub reste actif et ouvert aux contributions de la communauté.
• Le code. Payload 3 fonctionne exactement comme avant l'acquisition.
• L'auto-hébergement. Vous pouvez déployer Payload n'importe où, pour toujours.

Ce qui a changé :

• Payload Cloud a suspendu les nouvelles inscriptions. Les clients existants peuvent continuer, mais les nouveaux projets ne peuvent pas utiliser l'hébergement géré de Payload.
• Le focus de l'équipe a changé. L'équipe Payload construit désormais ce qui deviendra probablement un "Figma CMS" — comblant le fossé entre les designs Figma et le contenu en production. Les détails sont spéculatifs, mais la direction est claire.
• L'attention de la communauté. Certains développeurs s'inquiètent du schéma "acquis puis abandonné" qui affecte les projets open source. La licence MIT atténue le pire scénario, mais c'est une préoccupation légitime.

Devriez-vous quand même choisir Payload ?

Franchement ? Oui, avec des nuances.

Ce qui est positif : les ressources de Figma signifient plus de talent d'ingénierie derrière le projet. La licence MIT signifie que dans le pire des cas, vous pouvez le forker. Le code est mature, bien documenté et activement utilisé en production par des milliers de projets.

Ce qui est préoccupant : les intérêts de Figma pourraient diverger des besoins de la communauté open source avec le temps. L'absence de Payload Cloud vous oblige à gérer l'hébergement vous-même. Et si vous êtes averse au risque, l'incertitude autour de la direction à long terme est réelle.

Notre avis : si vous êtes à l'aise avec l'auto-hébergement (ce que vous devriez être — ce n'est pas difficile), Payload reste le meilleur CMS headless open source orienté code disponible. N'attendez pas le "Figma CMS." Construisez avec Payload 3 aujourd'hui, auto-hébergez, et avancez.

Comment déployer Payload CMS en 2026

Avec Payload Cloud suspendu pour les nouvelles inscriptions, vos principales options de déploiement en 2026 sont : Vercel (configuration la plus rapide, attention aux cold starts), Docker sur un VPS (idéal pour les éditeurs actifs, 7-45 €/mois), Railway/Render/Fly.io (conteneurs managés) ou Cloudflare Workers (le moins cher, environ 5-10 $/mois). Selon la documentation de déploiement de Payload, tout hébergement Node.js supportant Next.js fonctionnera.

Nous avons déployé Payload à la fois sur Vercel et sur un VPS basé sur Docker. Voici ce qui nous a surpris : les cold starts de Vercel rendaient le panneau d'administration lent pour les éditeurs qui ne se connectaient que quelques fois par semaine. Le VPS, malgré une configuration plus importante, offrait une expérience éditoriale nettement meilleure.

Vercel (Configuration la plus rapide)

Déploiement en un clic avec Neon Postgres et Vercel Blob pour les uploads de fichiers. Le chemin le plus rapide vers la production.

Avantages : Zéro gestion d'infrastructure, CDN excellent, idéal pour les sites avec une activité éditoriale légère. Inconvénients : Cold starts sur le panneau d'admin (3-5 secondes après inactivité), épuisement des connexions Postgres sous des requêtes intensives, plafond de timeout de 10 secondes pouvant interrompre les opérations en masse. Idéal pour : Sites marketing, portfolios, blogs avec édition peu fréquente.

Pour plus de contexte sur les forces et les limites de Vercel, consultez notre comparaison Vercel vs Netlify.

Docker sur un VPS (Idéal pour la production)

Une configuration Docker Compose sur Hetzner, DigitalOcean ou AWS EC2. Cela correspond mieux à l'architecture de Payload que le serverless, car Payload s'attend à un processus serveur persistant.

# docker-compose.yml
version: '3.8'
services:
  payload:
    build: .
    ports:
      - '3000:3000'
    environment:
      - DATABASE_URI=postgresql://payload:secret@db:5432/payload
      - PAYLOAD_SECRET=${PAYLOAD_SECRET}
      - NEXT_PUBLIC_SERVER_URL=https://your-domain.com
    depends_on:
      - db

  db:
    image: postgres:16-alpine
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      - POSTGRES_USER=payload
      - POSTGRES_PASSWORD=secret
      - POSTGRES_DB=payload

volumes:
  pgdata:

Avantages : Serveur persistant (pas de cold starts), coûts prévisibles (7-45 €/mois sur Hetzner), contrôle total de la stack. Inconvénients : Vous gérez le serveur, le SSL, les sauvegardes et les mises à jour. Idéal pour : Agences, équipes éditoriales actives, architectures multi-tenant, applications avec une utilisation intensive de l'administration.

Une comparaison d'hébergement détaillée par Build with Matija couvre d'autres fournisseurs VPS et configurations.

Conteneurs managés (Railway, Render, Fly.io)

Si Docker sur un VPS vous semble trop complexe en termes d'ops, les plateformes de conteneurs managés constituent un bon compromis. Railway est particulièrement populaire dans la communauté Payload — ils disposent d'un template Payload qui se déploie en un clic.

Consultez notre comparaison Railway vs Render vs Fly.io pour une analyse plus approfondie de ces plateformes.

Idéal pour : Les équipes qui veulent des serveurs persistants sans gérer directement l'infrastructure.

Cloudflare Workers (Le moins cher)

La solution la plus récente. Payload a ajouté un adaptateur Cloudflare Workers qui fonctionne sur des fonctions edge avec D1 (SQLite) ou Hyperdrive (proxy Postgres). Encore un peu expérimental, mais le coût est imbattable : environ 5-10 $/mois pour la plupart des projets.

Idéal pour : Projets personnels, sites particuliers, déploiements à petit budget où vous êtes à l'aise avec une infrastructure plus récente et moins éprouvée.

Notre verdict : Pour la plupart des projets Payload en production avec des éditeurs actifs, Docker sur un VPS est la meilleure option par défaut. C'est moins cher qu'on ne le croit, cela élimine les problèmes de cold starts, et vous donne un contrôle total. N'utilisez Vercel que si vos éditeurs sont peu fréquents et que vous voulez zéro overhead d'ops.

Tarification de Payload CMS — Ce que cela coûte vraiment

Payload lui-même est gratuit et sous licence MIT. Vos coûts réels concernent l'hébergement et, éventuellement, le développement professionnel. Voici à quoi ressemblent les chiffres en pratique, basés sur des configurations réelles et la analyse de tarification de Build with Matija.

Par comparaison : le plan Team de Contentful commence à 300 $/mois. Le plan Team de Sanity est à 99 $/mois par projet. Strapi Cloud commence à 29 $/mois. Le coût logiciel à 0 $ de Payload plus 7-25 $/mois d'hébergement est difficile à contester — particulièrement pour les agences qui construisent des projets clients où la tarification par utilisateur détruit les marges.

Payload vs Sanity vs Strapi vs Contentful — Comparaison rapide

Choisissez Payload si vous voulez un contrôle orienté code et l'auto-hébergement. Choisissez Sanity pour la meilleure édition visuelle et la collaboration en temps réel. Choisissez Strapi pour un panneau d'administration rapide avec un écosystème de plugins. Choisissez Contentful pour une infrastructure de niveau entreprise avec des garanties de SLA. Nous utilisons Sanity pour techsy.io, donc nous avons une expérience directe pour comparer ces plateformes.

Nous avons construit des projets basés sur Payload pour des clients qui ont besoin de propriété des données et d'auto-hébergement, et nous faisons tourner notre propre pipeline de contenu sur Sanity. Les deux sont excellents — le bon choix dépend du confort technique de votre équipe et de vos préférences d'hébergement. Si vous évaluez des options de CMS headless pour un projet, nous pouvons vous aider à choisir.

Pour des analyses approfondies de chaque plateforme, consultez nos guides : meilleur CMS headless en 2026, et les guides individuels pour Sanity, Strapi et Contentful à venir.

Quand ne PAS utiliser Payload CMS

Évitez Payload si votre équipe n'est pas technique et a besoin d'une interface graphique à la WordPress, si vous avez besoin d'un hébergement cloud managé immédiat sans travail d'auto-hébergement, si vos éditeurs veulent une édition visuelle au niveau de Sanity Studio, ou si vous avez besoin d'une marketplace de plugins pour une expansion rapide des fonctionnalités. Être honnête sur les limites inspire davantage confiance que de prétendre qu'elles n'existent pas.

Nous avons déconseillé Payload à des clients dont les équipes éditoriales n'avaient aucune expérience en TypeScript. Voici quand vous devriez chercher ailleurs :

• Équipes non techniques. Payload nécessite des connaissances en TypeScript pour la configuration. Si les éditeurs de votre client ne peuvent pas toucher au code et ont besoin de modifier le modèle de contenu eux-mêmes, WordPress ou Sanity sont de meilleures options.
• Vous avez besoin d'un hébergement managé immédiatement. Avec Payload Cloud suspendu pour les nouvelles inscriptions, vous devez obligatoirement vous auto-héberger. Si gérer un serveur (même une simple configuration Docker) est rédhibitoire, l'approche cloud hébergée de Contentful ou Sanity supprime ce fardeau.
• Collaboration éditoriale intensive. La collaboration en temps réel de Sanity Studio — plusieurs éditeurs travaillant simultanément sur le même document avec des indicateurs de présence — est plus aboutie que tout ce que Payload propose. Si vous avez une grande équipe éditoriale, Sanity l'emporte ici.
• Développement piloté par les plugins. Strapi dispose d'une plus grande marketplace de plugins. Vous avez besoin d'un plugin SEO, d'un générateur de sitemap, d'une intégration e-mail ? Strapi en a probablement un. L'écosystème de Payload grandit mais reste plus petit.
• Vous n'utilisez pas Next.js. Payload 3 est architecturalement lié à Next.js. Si votre frontend est Astro, Remix, Nuxt ou SvelteKit, le principal avantage de Payload (l'API Local dans les composants serveur) ne s'applique pas. Vous auriez quand même REST et GraphQL, mais à ce stade, Strapi ou Directus pourraient sembler plus naturels.

FAQ

Qu'est-ce que Payload CMS et comment fonctionne-t-il ?

Payload est un CMS headless open source, natif TypeScript, et un framework applicatif construit sur Next.js. Vous définissez votre modèle de contenu dans des fichiers de configuration TypeScript, et Payload génère automatiquement un panneau d'administration, une API REST, une API GraphQL et une API Local. Il s'exécute à l'intérieur de votre application Next.js comme une unité déployable unique.

Payload CMS est-il gratuit ?

Payload est entièrement gratuit sous la licence MIT. Le logiciel ne coûte rien à télécharger, utiliser ou modifier. Payload Cloud (hébergement managé) était à 35-199 $/mois mais est actuellement suspendu pour les nouvelles inscriptions suite à l'acquisition par Figma. L'auto-hébergement sur un VPS coûte 7-45 €/mois selon votre fournisseur.

Que s'est-il passé avec Payload et Figma ?

Figma a acquis Payload le 17 juin 2025. Toute l'équipe Payload a rejoint Figma. La licence MIT open source et le dépôt GitHub restent inchangés. Payload Cloud a suspendu les nouvelles inscriptions. L'auto-hébergement continue de fonctionner normalement. L'équipe construit probablement un produit CMS intégré à Figma, mais les détails n'ont pas été annoncés.

Quelle base de données utilise Payload CMS ?

Payload supporte trois bases de données via un pattern d'adaptateur : PostgreSQL (recommandé pour la production, fonctionne avec Neon et Supabase pour le serverless), MongoDB (adapté aux modèles documentaires ou aux migrations depuis Payload 2) et SQLite (développement local et CI uniquement). Le code de votre application reste identique quel que soit l'adaptateur choisi.

Comment déployer Payload CMS en 2026 ?

Avec Payload Cloud suspendu, déployez sur Vercel avec Neon Postgres (le plus simple), Docker sur un VPS comme Hetzner (idéal pour la production avec des éditeurs actifs), Railway ou Render (conteneurs managés) ou Cloudflare Workers (le moins cher). Pour la plupart des sites en production avec une activité éditoriale régulière, un VPS basé sur Docker offre la meilleure expérience.

Payload CMS est-il meilleur que Strapi ?

Payload l'emporte sur l'expérience développeur native TypeScript, l'intégration Next.js et l'API Local unique pour des requêtes côté serveur sans overhead. Strapi l'emporte sur sa marketplace de plugins, la définition de schéma via interface graphique et une compatibilité framework plus large. Si votre équipe écrit du TypeScript et utilise Next.js, Payload est le choix le plus solide. Sinon, évaluez Strapi.

Qu'est-ce que l'API Local de Payload ?

L'API Local est une couche de requête côté serveur qui appelle votre base de données directement avec zéro overhead HTTP. Au lieu de faire des appels REST ou GraphQL, vous importez Payload et interrogez les collections directement dans les composants serveur Next.js. Cela élimine les round-trips réseau et les coûts de sérialisation, ce qui se traduit par des chargements de page plus rapides. Aucun autre CMS headless n'offre cela.

Payload CMS peut-il gérer des applications à grande échelle ?

Payload supporte PostgreSQL avec connection pooling (via Neon ou PgBouncer), le contrôle d'accès basé sur les rôles avec granularité au niveau des champs, des flux de brouillons et de versionnage, et des architectures multi-tenant. Des entreprises et des agences utilisent Payload en production pour des applications à forte densité de contenu. Les requêtes sans overhead de l'API Local améliorent en fait les performances à grande échelle.

Comment Payload se compare-t-il à Sanity ?

Payload est auto-hébergé, orienté code et sous licence MIT avec une API Local pour les performances côté serveur. Sanity est hébergé dans le cloud avec une édition visuelle supérieure, une collaboration en temps réel et le langage de requête GROQ. Payload vous donne plus de contrôle sur l'infrastructure et des coûts inférieurs. Sanity vous donne de meilleures outils éditoriaux et zéro gestion d'hébergement.

Quels sont les inconvénients de Payload CMS ?

Payload nécessite des connaissances en TypeScript pour la configuration, n'a pas d'hébergement cloud managé pour les nouveaux utilisateurs depuis l'acquisition par Figma, offre un écosystème de plugins plus petit que Strapi, et est architecturalement lié à Next.js dans la version 3. Les équipes non techniques peuvent avoir du mal avec l'approche orientée code, et l'acquisition par Figma crée une certaine incertitude à long terme.