Payload CMS : notre avis après l'avoir mis en production

Depuis juin 2026, le site que vous lisez tourne sur Payload CMS et Next.js, un framework (une base de développement) très répandu pour construire des sites. Nous y avons migré près de 200 articles depuis Webflow, nos cas clients et nos pages d'offre, en français et en anglais. Voici ce que Payload change au quotidien, ce qu'il coûte vraiment, quand nous ne le recommanderions pas et les pièges d'une migration. Faits techniques et tarifaires vérifiés fin septembre 2026, sur Payload 3.

Payload en bref, et ce qui a changé depuis 2024

Payload est un CMS headless open source (licence MIT), pensé pour Next.js. Un CMS est l'outil qui sert à gérer les contenus d'un site : c'est l'espace d'administration où l'on écrit les textes et où l'on ajoute les images. « Headless » veut dire que cette administration ne décide pas de la mise en page : elle stocke les contenus, et le site, développé sur mesure, les affiche comme il veut. « Open source » : le code de Payload est public et utilisable gratuitement, y compris pour un site commercial.

Avec Payload, les types de contenus, leurs champs et les droits de chacun sont décrits dans le code du projet. Depuis la version 3, sortie le 19 novembre 2024, Payload s'installe directement dans une application Next.js : le site et son administration forment un seul projet. Il fonctionne avec les bases de données les plus courantes (PostgreSQL, MongoDB, SQLite).

Trois évolutions comptent pour une décision en 2026 :

• L'arrivée chez Figma et la fin de l'hébergement géré pour tous. Figma a annoncé le 17 juin 2025 que l'équipe Payload le rejoignait et s'est engagé à garder le logiciel libre. En revanche, la création de projets sur Payload Cloud, l'hébergement géré par l'éditeur, est aujourd'hui réservée à l'offre Enterprise, l'offre payante de Payload pour les grandes organisations. En pratique, le site s'héberge ailleurs : sur un serveur loué, ou chez des hébergeurs spécialisés comme Vercel ou Cloudflare, pour lesquels Payload fournit des modèles prêts à l'emploi.
• Un rythme de versions soutenu. Payload publie une nouvelle version presque chaque semaine : la version 3 est passée de 3.0 à 3.90 en moins de deux ans, et la version 4 est en préparation. Suivre ces mises à jour est un travail régulier, à prévoir dans la maintenance.
• Un lien étroit avec Next.js. Toutes les versions de Next.js ne sont pas compatibles avec Payload : mettre à jour l'un oblige à vérifier l'autre.

Si vous cherchez plutôt ce que nous construisons avec Payload, c'est sur notre page agence Payload CMS.

Ce que nous avons réellement en production

Notre propre site. Next.js 16 et Payload 3 dans la même application, une base de données PostgreSQL, un serveur chez OVH et un site de préproduction séparé (une copie du site pour tester avant de mettre en ligne). Le blog, les cas clients, les pages d'offre et de secteur, le menu et le pied de page sont gérés dans l'administration. Nous nous sommes fixé une règle : tout texte visible sur le site doit être modifiable sans toucher au code.

Zéro Doute, un annuaire d'entreprises de services contrôlées en Charente. Nous avons développé le site et son administration : fiches entreprises, témoignages rattachés à chaque entreprise, articles, demandes de contact enregistrées dans le CRM. Aujourd'hui, l'équipe de Zéro Doute fait vivre le site seule : elle ajoute les entreprises nouvellement labellisées, met en ligne les témoignages audio de leurs clients et met à jour les notes. Le modèle de contenu (la liste des types de contenus, de leurs champs et des liens entre eux) porte aussi des règles métier : un témoignage ne peut pas être publié tant que l'entreprise à laquelle il est rattaché est encore en brouillon.

Parallaxe Studio, un studio de photographie d'architecture : parti d'un prototype statique, le site est entièrement géré dans Payload (pages, projets, services, images).

Ces projets sont présentés sur la page nos réalisations avec Payload CMS.

Pour quels projets c'est un bon choix

D'après ce que nous avons construit, Payload se justifie dans quatre situations :

1. Des contenus nombreux et reliés entre eux. Articles, cas clients, offres, entreprises, témoignages : chaque type a ses propres champs, et les liens entre contenus sont de vraies relations, avec des règles. La règle de publication des témoignages de Zéro Doute en est un bon exemple.
2. Un site multilingue à piloter finement. Chaque champ (titre, texte, bouton…) a sa version dans chaque langue, avec des adresses différentes par langue si besoin. Notre site fonctionne ainsi en français et en anglais.
3. Un site qui doit se brancher à d'autres outils ou grandir. Formulaire relié au CRM, annuaire, espace client, recherche interne : tout se développe dans le même projet que le site.
4. La volonté de posséder son site. Code et contenus vous appartiennent, la base de données s'exporte, l'hébergement se choisit, y compris en France.

Quand ne pas le choisir

• Personne pour la technique après la mise en ligne. Un site Payload est une application : il faut quelqu'un, en interne ou chez un prestataire, pour les mises à jour, l'hébergement et les évolutions.
• Une équipe qui veut modifier le design elle-même. Dans l'administration, vous modifiez les contenus et assemblez les sections conçues pour votre site ; changer le design ou créer un nouveau type de section passe par le code.
• Un circuit de validation à plusieurs niveaux prêt à l'emploi (un rédacteur propose, un responsable valide), ou une connexion avec le compte de l'entreprise (SSO). Brouillon, aperçu et rôles (qui a le droit de faire quoi) sont inclus ; le reste relève de l'offre Enterprise, sur devis, ou se développe.
• Un petit site stable, à lancer en quelques jours. Un outil tout-en-un comme Webflow ou Wix fait très bien ce travail, hébergement, sécurité et sauvegardes compris.

Face aux alternatives, notre lecture est courte. Webflow reste le bon choix quand l'équipe veut garder la main sur le design et que les besoins évoluent peu ; nous le proposons aussi (voir les forces et limites du CMS Webflow). WordPress se justifie surtout avec un existant lourd ou une extension métier indispensable. Strapi et Directus séparent le site et l'administration en deux applications ; Directus est d'abord pensé pour administrer des données (notre avis sur Directus). L'argument décisif de Payload, pour nous : un seul projet à développer, héberger et maintenir.

Ce que ça change pour l'équipe marketing

Brouillon et aperçu. Sur nos articles et nos cas clients, chaque modification peut être enregistrée en brouillon, avec une sauvegarde automatique pendant la saisie, puis vérifiée avec le bouton Aperçu avant publication. Le public ne voit que le contenu publié.

Historique des versions. Quand il est activé sur un type de contenu, Payload garde des copies successives de chaque document, montre ce qui a changé entre deux versions et permet de revenir en arrière. Nous en conservons 30 par document (le réglage par défaut est 100). Seule limite : une modification faite directement dans la base, hors de Payload, ne laisse pas de trace.

Un choix à faire dès la conception : quels contenus ont un brouillon. Le brouillon et l'historique se règlent type de contenu par type de contenu. Pour des pages qui changent rarement, publier directement peut suffire ; pour des pages que l'on refond ou que plusieurs personnes modifient, le brouillon devient indispensable. Cet arbitrage se décide quand on conçoit le modèle de contenu : il coûte plus cher à changer ensuite.

Le multilingue. Chaque champ traduisible a sa version française et sa version anglaise ; si le champ anglais est vide, le site affiche le français.

Créer une page sans développeur. L'administration permet d'assembler une nouvelle page à partir des sections conçues pour le site. Avec le Builder IA Scroll, que nous proposons sur nos sites Payload, une nouvelle page se crée en une dizaine de minutes à partir d'une consigne, puis se relit avant publication.

Ce qui reste technique. Certaines opérations demandent encore un développeur. Les redirections, par exemple : quand on renomme l'adresse d'une page publiée, l'ancienne adresse doit rediriger vers la nouvelle. Un module officiel permet de les gérer depuis l'administration ; il faut prévoir, dès le développement, que le site les applique. Plus largement, l'administration n'est jamais meilleure que le modèle de contenu qu'on a conçu : c'est là que se joue l'autonomie de l'équipe.

Les coûts à prévoir

Logiciel : zéro. Payload est gratuit, sans abonnement obligatoire (WordPress aussi, mais ses thèmes et extensions avancés sont souvent payants). Seule l'offre Enterprise (connexion unique SSO, circuits de validation, édition visuelle annoncée, etc.) est payante, sur devis. Les outils tout-en-un, eux, fonctionnent par abonnement : Webflow, par exemple, facture un abonnement par site, plus un abonnement d'espace de travail et des utilisateurs supplémentaires.

Hébergement : faible. Pour un site vitrine d'une dizaine de pages et moins de 10 000 visiteurs par mois, notre configuration type revient à moins de 10 € HT par mois : un petit serveur OVH et le nom de domaine, les services annexes (e-mails, statistiques, protection réseau) restant dans leurs offres gratuites. La facture monte avec le volume : base de données plus lourde, gros trafic, beaucoup d'e-mails.

Développement : le vrai poste. Il dépend du nombre de pages et de gabarits, du niveau de design, du volume de contenus à reprendre, du multilingue et des connexions à vos outils. Une partie du budget part dans la conception du modèle de contenu : c'est ce travail qui rend ensuite l'administration simple. Chaque projet est chiffré sur mesure, après un premier échange sur vos besoins.

Maintenance : le poste qu'on oublie. Sur un outil tout-en-un comme Webflow ou Wix, la plateforme s'occupe des serveurs, de la sécurité et des sauvegardes. Sur un Payload que vous hébergez, comme sur un WordPress, quelqu'un doit le faire. Sur notre site : mise à jour du moteur chaque mois, sauvegarde chiffrée de la base de données chaque nuit, vérification régulière que cette sauvegarde se remet bien en place, surveillance extérieure qui prévient si le site ne répond plus, et alerte si une sauvegarde échoue. C'est ce suivi que nous proposons, si vous le souhaitez, sur les sites que nous développons.

Changer de CMS : cinq points de contrôle tirés de notre propre migration

Notre nouveau site est en ligne depuis le 12 juin 2026. Il venait de Webflow, mais ces points valent pour toute migration, depuis WordPress comme depuis un outil tout-en-un. Une migration de près de 200 articles fait apparaître des pièges que la documentation ne signale pas. Voici ceux que nous avons rencontrés, et la liste de contrôle que nous en avons tirée.

1. Le corps de l'article n'est pas tout l'article. Dans l'ancien outil, une partie du contenu peut vivre ailleurs que dans le texte. Chez nous (Webflow), les FAQ des articles étaient rangées dans une collection séparée (une liste de contenus à part, un peu comme un autre onglet de tableur), reliée à chaque article, et un import qui ne suit pas ce lien les laisse de côté. Sur WordPress, ce sont souvent les champs ajoutés par des extensions. Ce que nous vérifions : l'inventaire de tous les champs de chaque type de contenu, y compris les liens entre eux, avant d'écrire le programme qui recopie les contenus.

2. Comparer automatiquement l'ancien et le nouveau contenu. Une relecture à l'œil ne suffit pas sur des centaines de contenus. Ce que nous vérifions : un programme compare automatiquement l'ancien et le nouveau contenu, champ par champ, avant la mise en ligne.

3. Se méfier des traces de l'ancien outil. Chaque outil laisse les siennes. Les paragraphes « vides » de Webflow contiennent souvent un caractère invisible, qui crée de grands trous entre les paragraphes si on l'importe tel quel. Sur WordPress, ce sont par exemple les codes courts (shortcodes) des extensions, qui ne veulent plus rien dire une fois sortis de WordPress. Ce que nous vérifions : le rendu des articles importés, pas seulement leur texte.

4. Vérifier la page réellement servie, pas seulement l'administration. Le titre affiché dans Google et l'adresse de référence de la page (l'« adresse canonique ») peuvent être bien renseignés dans l'administration, mais arriver trop tard dans le code de la page, parce que Next.js envoie la page par morceaux. Next.js indique que Google sait les lire ; nous préférons ne pas parier et les plaçons au début de la page. Ce que nous vérifions : la page telle que Google la reçoit, pour chaque modèle de page.

5. Traiter les adresses comme un chantier à part. Les redirections des anciennes adresses se préparent avant le lancement, mais le travail ne s'arrête pas là : une adresse renommée plus tard casse les liens écrits directement dans le texte des autres articles. Ce que nous vérifions : chaque renommage passe par une redirection et par la réparation des liens internes.

La méthode complète (audit, correspondance des contenus, plan de redirections) est décrite sur notre page migration Webflow vers Payload.

Notre avis

Payload est aujourd'hui notre choix par défaut pour les sites qui ont beaucoup de contenus reliés, plusieurs langues, des fonctionnalités spécifiques ou vocation à grandir. Ce n'est pas un choix sans entretien : il remplace un abonnement tout compris par un site qui vous appartient, qu'il faut héberger, sauvegarder et mettre à jour. Si personne ne peut porter ce travail, ou si votre équipe veut surtout modifier le design elle-même, un outil tout-en-un restera plus adapté. Pour trancher selon votre situation, notre page création et refonte de sites web sur mesure explique comment nous choisissons l'outil avec nos clients.