Payload CMS 4 : quand migrer de Payload 3 vers Payload 4 ?

Si votre site tourne sur Payload 3 et que quelqu’un vous a demandé « on passe à la 4 quand ? », voici la réponse courte : pas maintenant, et personne ne peut vous dire quand. Payload 4 est en beta. Aucune date de sortie stable n’a été annoncée. Votre site n’est pas en retard.

La réponse longue est plus intéressante, parce que la 4 contient une chose qui change vraiment le quotidien d’une équipe qui publie : un MCP refait de zéro. On y vient.

Payload n’a donné ni jour, ni mois, ni trimestre pour la version stable. La beta est faite pour essayer. Un site qui publie reste en Payload 3.

Payload 4 a-t-il une date de sortie ?

Non. Et ce n’est pas une formule prudente : il n’existe aucune annonce.

Avant la beta, l’équipe Payload avait dit une seule chose sur le calendrier : elle voulait un passage de la beta à la stable plus court que pour la version 3. Pas de saison, pas de délai. Depuis l’ouverture de la beta, le message officiel est que la version complète est encore en cours et que les retours sont bienvenus.

Si vous lisez une date quelque part, elle vient d’un article tiers ou d’un fil de discussion, pas de Payload. Le jour où la stable sort, nous mettrons ce paragraphe à jour.

Faut-il passer à Payload CMS v4 maintenant ?

Non, et ce n’est pas une question de courage technique.

Une beta bouge. L’admin change encore, certains comportements aussi. Installer ça sur le site que votre équipe ouvre tous les matins pour publier, c’est s’offrir des ajustements dont vous n’avez pas besoin.

Payload 3 est la version stable. C’est sur elle que sortent les correctifs aujourd’hui. Rester dessus n’est pas un retard : c’est le choix normal pour un site en production.

Ce que Payload CMS 4.0 change pour votre équipe : le MCP

Les nouveautés visibles de Payload 4 (admin redessiné, médiathèque, dossiers) sont détaillées dans Payload CMS 4.0 : quoi attendre, et ensuite. Ici, un seul sujet mérite qu’on s’y arrête, parce qu’il concerne directement les personnes qui publient : le MCP.

Le MCP, c’est la porte par laquelle un assistant IA (Claude, Cursor, ChatGPT, ou un agent interne) lit et écrit dans votre CMS. Concrètement : « rédige trois variantes de cette page produit à partir de la fiche technique », « retrouve tous les articles qui citent ce client et mets à jour son nom », « crée les pages de la nouvelle gamme à partir de ce tableau ». L’assistant travaille dans Payload, avec vos modèles de contenu, vos champs, vos règles.

En Payload 3, ce MCP existait déjà, mais le mettre en place demandait un développeur et plusieurs étapes : activer chaque collection une par une, créer des clés, régler les permissions, configurer le client. Payload a dit lui-même que c’était trop lourd.

En 4, il a été reconstruit avec une logique inverse. Voici ce qui change, d’après la documentation Payload :

• Tout est disponible par défaut. Chaque collection et chaque contenu global est accessible à l’assistant sans réglage. On retire ce qu’on ne veut pas exposer, au lieu d’ajouter ce qu’on veut ouvrir.
• Plus de clé API en développement. Un développeur branche son assistant en quelques minutes pour tester.
• Des consignes pour l’IA, par type de contenu. Vous pouvez écrire, directement dans l’admin, les règles que l’assistant doit lire avant de créer ou modifier un contenu : ton, longueur, champs obligatoires, ce qu’il ne doit jamais toucher. L’assistant les reçoit avec la structure du contenu.
• Les droits restent ceux de Payload. Un assistant connecté avec un compte éditeur ne peut pas faire plus qu’un éditeur. Il ne supprime pas ce que le compte n’a pas le droit de supprimer.
• Les fichiers passent aussi. L’assistant peut déposer des images et des documents dans la médiathèque, avec les mêmes contrôles de format et de taille que vous.

Pour une équipe marketing, c’est le vrai argument de la 4. Pas un admin plus joli : un CMS dans lequel une IA peut travailler proprement, encadrée par vos règles. Si vous vous demandiez à quoi ressemble un agent IA branché sur Payload au quotidien, c’est exactement ce que la 4 rend simple à installer.

Quand passer à Payload v4 ?

Quand deux conditions sont vraies en même temps.

La première est hors de votre contrôle : Payload publie la 4.0 comme version stable.

La seconde est la vôtre : l’équipe y gagne quelque chose de concret. Trois situations suffisent.

• Vous voulez mettre une IA au travail sur vos contenus, avec des règles, sans ouvrir un chantier de configuration. Le MCP de la 4 est fait pour ça.
• Un correctif important ne sort plus que pour la 4. Ce jour-là, la mise à jour devient de l’entretien, comme une mise à jour de sécurité.
• Une refonte est déjà décidée. La montée de version s’y glisse. Elle ne justifie pas un projet à elle seule.

Aucune de ces situations ? Vous continuez à publier sur la 3, et vous avez raison.

Le jour où vous dites oui, ça ressemble à quoi ?

Côté contenu, à presque rien. Pages, articles, médias restent en place. Vos visiteurs ne voient pas un nouveau site.

Côté équipe, à un nouvel admin et une reconnexion. Prévoyez une demi-heure avec les personnes qui publient, sur les trois gestes qu’elles font vraiment : publier une page, déposer une image, retrouver un article.

Côté projet, à une fenêtre cadrée. Quelqu’un sauvegarde, fait la mise à jour sur une copie, vérifie que la publication, les formulaires et l’éventuel MCP répondent, puis bascule. Ce n’est pas un bouton dans l’admin. Ce n’est pas non plus une refonte. Le chiffrage dépend de ce que votre site a de particulier : admin personnalisé, plusieurs langues, automatisations.

Qui décide, qui fait ?

Vous décidez. La question utile tient en une ligne : est-ce que l’équipe publie mieux après ?

Le passage lui-même est un travail de développeur. Un développeur, ou une IA dans le code, fera la partie mécanique. Ce qui reste à faire ensuite, et que personne ne fait à votre place : choisir le moment, prévenir les éditeurs, vérifier que le site publié se comporte comme avant, et écrire les consignes que l’IA devra suivre dans votre CMS.

Beease prend cette partie quand vous avez tranché. Inventaire de ce qui est spécifique à votre site, mise à jour sur une copie, vérification avec vous, bascule une fois la stable disponible. Tant que Payload 4 n’est pas cette version, on ne vous proposera pas de l’installer en production.

On s’occupe de la mise à jour, le moment venu

Payload CMS

Mise à jour

Vous choisissez le moment. Nous faisons la migration Payload 4 quand la stable est là, et nous configurons le MCP avec vos règles.

Planifiez un call

Pour un avis sur votre site avant d’en parler en interne, demandez un audit.

Questions fréquentes

Payload 4 a-t-il une date de sortie ?

Non. Aucune date stable n’a été annoncée, ni mois ni trimestre. La beta est publique et la version complète est encore en préparation.

Un site Payload CMS encore en version 3 est-il dépassé ?

Non. La 3 est la version stable et reçoit les correctifs. Il peut y rester tant qu’elle est maintenue et que la 4 ne règle pas un problème que votre équipe rencontre déjà.

Qu’est-ce que le MCP de Payload 4 change pour une équipe marketing ?

Un assistant IA peut lire et écrire dans le CMS sans installation lourde, en respectant les droits de chaque compte et des consignes rédigées dans l’admin pour chaque type de contenu. Vous pouvez lui confier des tâches de rédaction, de mise à jour en masse ou de création de pages, dans votre cadre.

Faut-il en parler au prestataire maintenant ?

Pour qu’il sache que le sujet existe, oui. Pour lancer le travail, non. Une seule question vaut la peine aujourd’hui : qu’est-ce que notre site a de particulier, le jour où la stable sortira ?

Prendre un call avec Martin

Co-fondateur

Vingt minutes pour regarder votre site Payload et dire si une migration vers la 4 a un intérêt, et à quel moment.

Réserver un créneau avec Martin