Payload CMS 4.0 n'est pas une simple release note. C'est le premier grand jalon public depuis que Payload a rejoint Figma, et le moment où l'équipe montre enfin la couche visible d'une stratégie plus large. Voici un early look sourcé : ce qui arrive dans la 4.0, et ce qui se prépare « ensuite », encore largement non annoncé.
Chez Beease, on livre déjà des sites sur Payload + Next.js en production. On est très satisfaits du CMS tel qu'il est : on n'attend pas la 4.0 pour « sauver » une stack. On la regarde parce que l'écosystème accélère, et parce qu'un admin plus soigné aidera surtout les équipes contenu.
Payload CMS 4.0 n'est pas sorti (encore)
Premier point à garder en tête : la 4.0 n'est pas stable. Le post officiel parle d'un early look. Plusieurs briques sont déjà visibles sur la branche main du GitHub officiel, mais l'équipe le dit clairement : c'est du travail en cours. La ligne prod reste la 3.x.
Les chiffres du camp Payload, depuis septembre : environ 1 300 PR mergées, ~600 issues fermées, ~181 features, et des downloads hebdo passés d'environ 100k à 400k. Le momentum est réel, même si ce n'est pas encore un go-live.
La cible affichée : une beta dans le prochain trimestre, avec un chemin beta vers stable plus court qu'en 3.0 (où la beta d'avril avait traîné jusqu'en novembre). Paul Popus, côté équipe, le résume sans filtre sur Discord : d'abord une beta publique, puis beaucoup de releases entre beta.0 et le stable, avec des breaking changes possibles selon les retours.
Ce qui arrive dans la 4.0
Un admin redessiné (inspiré du design system Figma)
Le morceau le plus visible, c'est un redesign complet de l'admin : listes et édition, tables, actions bulk, drawers, modales (crop / focal point), focus states, contrast mode, et des contrôles Lexical plus propres. Sass laisse place à des tokens sémantiques, un vrai design system, et une meilleure coexistence avec Tailwind quand vous customisez l'admin.
James Mikrut l'assume dans le community call : beaucoup ont râlé sur l'UI pendant des années, et c'est en partie de sa faute (« maybe a little bit too minimalist »).
Tylen Davis, designer Payload, précise le cap : une expérience cohérente entre Payload et Figma, avec un design system basé sur celui de Figma (
UI3). Des composants Payload propres, et une lib Figma promise plus tard.
Hiérarchies natives
Les dossiers et tags deviennent un primitif core, et plus seulement le plugin nested docs. La sidebar gagne des onglets (folders / tags), ainsi que des slots React pour les plugins (queues, favoris, multi-tenant…). À terme, nested docs sera remplacé, même si la migration n'est pas encore figée.
Pour les sites marketing avec une vraie arborescence de pages, c'est le genre de feature qui change le quotidien des éditeurs.
Agents, skills, MCP
Payload pousse des skills installables pour agents (des guides spécifiques Payload), une collecte des échecs LLM, et une suite d'evals. Côté MCP, l'objectif 4.0 est volontairement simple : ajouter le plugin, configurer le MCP.json, et y aller. Les tools sont en opt-out par défaut, et les schémas complexes deviennent plus fiables.
Si vous suivez déjà le sujet agents + CMS, lisez aussi notre article sur l'agent IA et Payload CMS.
TanStack Start (early)
Next.js reste first-class. Mais la 4.0 introduit un pattern d'adapters framework (admin, RSC, loaders, montage API). Le premier proof point : TanStack Start. La démo est early, les bugs CSS sont admis, et le signal est clair : Payload ne veut plus être « Next-only forever », même si Paul avait déjà calmé la rumeur d'un découplage total dès la 4.0.
Figma, Sites, et ce qui se prépare « ensuite »
En juin 2025, Payload rejoint Figma. James pose le problème sans détour :
« The gap between design and code still exists. Designers create in Figma, then devs recreate in code, then content teams struggle to maintain it all… And historically, the CMS tends to make it worse. »
Et la promesse : intégrer les design systems « in ways no other CMS can ».
Kris Rasmussen, CTO Figma, est encore plus direct sur le blog Figma : quand Sites a été annoncé à Config, un CMS était déjà promis. Payload apporte le backend que les devs aiment et un admin pour les éditeurs. Autrement dit, Sites CMS + Payload n'est pas une lecture communautaire : c'est le framing officiel.
Paul Popus (équipe Payload, désormais dans l'écosystème Figma) le dit cash sur Discord : le ROI sera dans ce que Payload fait comme CMS dans la plateforme Figma, pendant que l'open source reste une boucle de feedback positive. Sur le risque « rugpull » : techniquement impossible de tout retirer, le code existant est MIT.
Ry, designer Figma NYC, publie le 30 septembre 2025 le RFC Admin UX #13979 : il travaille déjà avec James et l'équipe depuis des mois. Le redesign n'est donc pas une idée post-acquisition sortie du chapeau : c'était déjà en cours, en silence.
James, en community call sur la v4 :
« As we build these integrations back to Figma, we have a very wide array of ideas that we're actively building behind the scenes with Figma. »
Le redesign admin sert à ce que l'aller-retour Figma ↔ Payload soit une expérience cohérente. Ce n'est pas le produit final : c'est le prérequis visible.
Anecdote Discord (17 juin 2025) : un utilisateur propose « mockup Figma → convert → app CMS Payload end-to-end ». James répond juste : 😏. Ce n'est pas une roadmap, mais c'est sans doute le meilleur teaser non officiel du lot.
Ce qu'on voit vs ce qui reste dans l'ombre
Lecture courte, sans science-fiction. Court terme : une UI alignée Figma. Moyen terme : Payload comme cerveau contenu sérieux dans, ou à côté de, l'écosystème Sites. Long terme (l'utopie de James) : des design systems et des modèles Payload synchronisés, avec moins de handoff design / code / contenu. Make, Dev Mode MCP et agents peuvent accélérer tout ça, mais ce n'est pas encore le communiqué de presse.
Pour le positionnement CMS au sens large, on a déjà documenté pourquoi Payload face à WordPress. La 4.0 ne change pas ce socle : elle le rend plus crédible côté éditeurs, et plus branché côté plateforme Figma.
Ce qu'on en retient chez Beease
- On surveille. Pas de prod sur
main. La 3.x reste la ligne livrable. - Le CMS nous convient déjà. L'UI 4.0 est un plus pour vos équipes marketing / contenu, pas un sauvetage technique.
- Les vraies features « wow » pour nos projets clients : DAM, hiérarchies, admin plus lisible...
- Agents / MCP : direction claire, à suivre de près. Le setup plus simple en 4.0 peut devenir un vrai différenciateur.
- Figma : un contexte stratégique à connaître. Quand le pont produit sera public, on en reparlera avec des faits, pas des "😏".
Paul, encore, pour calmer les peurs OSS : Figma n'a pas intérêt à casser l'open source. L'enjeu, c'est l'interopérabilité et les besoins CMS de la plateforme. L'OSS n'était « jamais » le paymaster : c'étaient les clients enterprise. Cash, utile, et cohérent avec ce qu'on voit depuis un an : le rythme open source n'a pas freiné. Il a accéléré.
Sources et suite
Sources primaires à garder sous le coude :
- Early look Payload 4.0 (blog Payload)
- Payload is joining Figma (James Mikrut)
- Payload joins Figma (Kris Rasmussen / Figma)
- RFC Admin UX #13979 (Ry, Figma)
- Community call YouTube
- Lecture presse : CMSWire sur le deal Figma × Payload
- Discord Payload #general (annonce 17–18 juin 2025 + teasing redesign mai–juin 2026)
Payload CMS 4.0, c'est la façade publique. « Et ensuite », c'est fermer la boucle design → code structuré → contenu, avec Payload comme couche de vérité dans l'écosystème Figma. On n'a pas encore le communiqué produit, mais on a déjà assez de signaux pour ne pas regarder ailleurs.
Si vous construisez (ou envisagez) un site sur cette stack, on peut en parler concrètement : architecture, admin éditeurs, et ce que la 4.0 changera (ou pas) pour vous. Découvrez notre offre agence Payload CMS, ou contactez nous
Martin Lotz
CEO
Ingénieur commercial
Martin Lotz est CEO et ingénieur commercial chez Beease Digital. Membre clé de l’équipe, il assure le lien entre les besoins business des clients et les solutions techniques de l’agence.
Planifier une démo avec Martin
