Un client m'a appelé en octobre dernier, légèrement paniqué. Il avait construit toute sa plateforme marketing sur un CMS hébergé et le fournisseur venait d'annoncer une restructuration tarifaire. Du jour au lendemain, sa facture passait de 180 £/mois à plus de 900 £. Le contenu n'était pas complexe. Un blog, un catalogue produits, peut-être quarante champs personnalisés répartis sur trois collections. Rien qui justifiait ce montant. Cet appel est la raison pour laquelle j'ai passé les trois mois suivants à migrer deux projets Seahawk vers Payload CMS et à construire un vrai modèle de coûts autour.
Alors laissez-moi vous dire ce que j'ai réellement trouvé.
Ce que Payload CMS est réellement (et n'est pas)
Payload est un CMS headless en TypeScript d'abord, piloté par le code. Vous définissez vos collections, globals et champs entièrement dans des fichiers de configuration. Pas d'interface graphique à cliquer pour concevoir le schéma. Le panneau d'administration est généré à partir de votre code, pas l'inverse. Cette inversion est tout l'intérêt, et c'est aussi ce qui vous piégera si vous venez de WordPress ou Contentful.
Ce n'est pas un SaaS. Il n'existe pas de tier hébergé par Payload pour lequel vous payez mensuellement. Vous contrôlez entièrement le déploiement. C'est une fonctionnalité et une contrainte selon votre situation.
Payload 2.0 est arrivé avec le support complet de PostgreSQL aux côtés de MongoDB, ce qui a déverrouillé la viabilité réelle pour les clients qui veulent des données relationnelles sans les acrobaties NoSQL. Au début 2026, l'écosystème autour a suffisamment mûri pour que je sois à l'aise de le recommander pour la production sans les réserves que j'avais l'habitude d'ajouter.
Sur quoi c'est réellement construit
Sous le capot : Next.js 15 pour l'interface d'administration, TypeScript partout, et votre choix entre Drizzle ORM (pour Postgres) ou Mongoose (pour MongoDB). Les API REST et GraphQL sont générées automatiquement à partir de votre schéma. Vous avez aussi une API locale pour les requêtes côté serveur qui est rapide d'une manière qui m'étonne à chaque fois.
Où il s'inscrit en 2026
Honnêtement, Payload s'inscrit dans une niche spécifique. Pas chaque projet ne devrait s'y trouver. Après l'avoir exécuté sur une douzaine de builds chez Seahawk, voici le pattern que j'ai remarqué.
C'est un bon choix quand :
- Le projet est mené par des développeurs dès le départ. C'est-à-dire qu'un vrai ingénieur le configure, pas un client à qui on a dit qu'il pouvait « tout gérer lui-même ».
- Vous avez besoin de logique de champ personnalisée, de champs conditionnels, ou de chaînes de relations complexes qui vous coûteraient cher en frais par fonctionnalité sur quelque chose comme Contentful.
- Le client est sensible aux coûts sur un horizon de 2-3 ans. Les calculs penchent presque toujours en faveur de Payload après le mois 14.
- Vous exécutez déjà une application Next.js ou Node et voulez que le CMS soit co-localisé ou du moins partage l'infrastructure.
C'est un mauvais choix quand :
- Le client a besoin qu'une personne non technique configure de nouveaux types de contenu sans support d'ingénierie.
- Vous construisez quelque chose qui doit être entièrement confié à quelqu'un qui n'a pas de développeur en interne.
- Le lancement est prévu dans moins de deux semaines et vous n'avez pas de scaffold Payload prêt à cloner.
J'ai appris ce deuxième point à mes dépens. En 2022, j'avais évalué un petit site caritatif avec Payload (v1 à l'époque). Le plan était de le remettre à leur coordinatrice bénévole interne pour qu'elle le gère. Trois mois plus tard, je recevais toujours des messages WhatsApp sur la raison pour laquelle le champ n'apparaissait pas. Le CMS n'était pas techniquement mauvais pour le projet. Il était mauvais pour le modèle de transmission.
Le Vrai Coût pour Exécuter Payload en 2026
C'est la partie que la plupart des articles de blog omettent ou présentent avec des plages vagues. Laissez-moi vous donner les chiffres réels de ce que j'ai exécuté.
Infrastructure
Vous avez besoin d'un endroit pour héberger le serveur Node et d'un endroit pour stocker votre base de données. Ce sont vos deux coûts fixes.
Option A : Railway J'utilise Railway pour la plupart des projets Payload avec un trafic moyen. Une application Payload typique (service Node + instance Postgres) coûte entre 12 et 35 $/mois selon l'utilisation. Pour un site marketing avec du contenu éditorial, vous êtes presque certainement dans la tranche 15-20 $. Les déploiements sont directs depuis un repo GitHub, et les sauvegardes Postgres sont automatiques.
Option B : Render Tarification similaire à Railway. Une version gratuite existe mais ne l'utilisez pas en production (les démarrages à froid vous humilieront devant vos clients). Les forfaits payants commencent à 7 $/mois pour le service web plus 7 $/mois pour le Postgres géré. Donc ~14 $/mois minimum, augmentant avec le CPU et la mémoire selon la croissance du trafic.
Option C : VPS autogéré Si vous exécutez plusieurs projets Payload, un VPS DigitalOcean ou Hetzner commence à devenir attractif. Un Hetzner CX32 (4 vCPU, 8 Go de RAM) coûte 8,29 €/mois et peut confortablement exécuter trois à quatre instances Payload derrière un proxy Nginx. J'exécute une instance Postgres partagée sur le même serveur pour les clients plus petits. Pas pour les timides, mais parfaitement stable.
Stockage Média
Payload ne gère pas vos images pour vous à moins de configurer un adaptateur de stockage. Les deux que j'ai utilisés en production :
- AWS S3 + CloudFront pour tout ce qui est à grande échelle. Budgétisez environ 5-15 $/mois pour un site marketing typique.
- Cloudflare R2 comme stockage compatible S3 sans frais de sortie. C'est mon défaut maintenant. Pour un site avec ~50 Go d'actifs médias, je paie essentiellement rien en sortie et environ 1,50 $/mois en stockage. Utilisez le plugin payload-cloud-storage et pointez-le vers R2.
Temps du Développeur (le coût qu'on oublie)
La configuration initiale d'un projet Payload, correctement structuré avec authentification, média, les collections dont votre client a besoin, et un modèle de contrôle d'accès sensé : budgétisez 12-20 heures pour un développeur expérimenté. Ce n'est pas une complexité optionnelle, c'est juste la nature d'un CMS code-first. À un tarif journalier de 400-600 £ (freelance mid-market londonien), c'est 4 800-12 000 £ d'avance avant d'avoir écrit une ligne de code frontend.
Comparez cela avec la création d'un espace Contentful et la configuration des types de contenu via leur interface en 3 heures. Le coût initial est réel. Le coût continu est là où Payload gagne.
Coût Total de Possession, Année 1 vs Année 3
Voici un modèle approximatif pour un site marketing de taille moyenne, comparant Payload on Railway et le plan Growth de Contentful :
- Payload on Railway, Année 1 : 18 £/mois infra + ~5 000 £ temps de configuration = ~5 216 £ total
- Payload on Railway, Année 3 : 18 £/mois infra + maintenance minimale = ~648 £ infra sur l'année 3
- Plan Contentful Growth, Année 1 : 320 £/mois = 3 840 £, pas de coût de configuration personnalisée
- Plan Contentful Growth, Année 3 : 320 £/mois = 3 840 £ encore une fois
Le basculement se produit environ au mois 20-22 selon votre tarif journalier. Après cela, Payload est sensiblement moins cher. Pour un client qui va faire fonctionner le même site en 2028, cela a de l'importance.
L'expérience développeur en termes honnêtes
J'aime vraiment travailler dans Payload. L'approche config-as-code signifie que votre schéma est versionné, examinable dans les pull requests, et déployable comme tout autre changement de code. Cela seul le place en avant des outils CMS où un modélisateur de contenu a cliqué dans une interface graphique et personne ne sait réellement ce qui a changé ou quand.
L'inférence TypeScript est excellente. Les types de votre collection s'écoulent dans vos requêtes API locales sans aucune étape de génération de type manuelle. Seahawk avait un projet de contenu fintech l'année dernière où nous interrogions des données de relations profondément imbriquées, et la sécurité des types a détecté deux bugs de forme de données avant qu'ils ne atteignent la mise en staging. Ce n'est pas rien.
L'interface admin est propre et rapide. Pas tape-à-l'œil, juste fonctionnelle. Les éditeurs non techniques se sentent généralement à l'aise avec en une ou deux sessions une fois que les champs sont bien étiquetés. Les hooks sont l'autre chose que je veux signaler : before-change, after-read, et des hooks de cycle de vie similaires vous permettent de faire des choses au niveau de la couche données que vous devriez sinon construire un middleware API personnalisé pour.
Les imperfections
Les migrations. Si vous êtes sur Postgres et que vous changez votre schéma, vous devez exécuter les migrations Drizzle. C'est correct si vous savez ce que vous faites et légèrement terrifiant si vous ne savez pas. J'ai vu un développeur junior sur un contrat sous-traitant de Seahawk supprimer une colonne en ne lisant pas soigneusement le diff de migration. Toujours examiner, toujours sauvegarder d'abord.
L'écosystème de plugins est plus petit que WordPress, évidemment. Mais le répertoire de plugins Payload a grandi considérablement. Constructeur de formulaires, documents imbriqués, champs SEO, redirections. Les bases importantes sont couvertes. Vous écrirez toujours plus de code personnalisé que sur une plateforme plus établie.
Comment cela se compare aux autres options Headless
Soyons direct sur les cas où je choisirais quelque chose d'autre.
Sanity.io si votre équipe de contenu est grande et que les éditeurs non techniques créent leurs propres structures de contenu. Studio de Sanity est plus convivial pour ce public, le backend hébergé est fiable, et le langage de requête GROQ est vraiment agréable à écrire. Vous paierez 99 $/mois ou plus sur un plan réel, mais pour certains clients, cela en vaut la peine.
Strapi a été l'alternative Payload pendant des années. C'est toujours viable et le modèle auto-hébergé est similaire, mais je trouve l'expérience TypeScript plus maladroite et le chemin de mise à niveau entre les versions majeures a historiquement été douloureux. La base de code de Payload me semble plus intentionnelle.
WordPress avec ACF ou une configuration basée sur les blocs pour tout ce qui doit être confié à un mainteneur non technique qui est déjà à l'aise avec WordPress. Toujours la bonne réponse pour de grandes portions de ce que les agences construisent. Ne laissez personne vous dire le contraire.
Directus en tant que outsider intéressant à considérer, surtout si vous travaillez avec un schéma de base de données existant que vous devez envelopper dans un CMS. Philosophie différente de Payload mais vraiment bon à ce travail spécifique.
FAQ
Payload CMS est-il gratuit à utiliser ?
Oui. Payload est open-source sous la licence MIT. Il n'y a pas de frais de licence. Vous payez votre propre infrastructure d'hébergement, ce qui est le compromis par rapport à un CMS SaaS hébergé.
Les clients non techniques peuvent-ils utiliser le panneau d'administration de Payload ?
Avec des champs bien étiquetés, des valeurs par défaut sensées, et une formation de base, oui. L'interface admin est suffisamment propre pour que les éditeurs la maîtrisent raisonnablement vite. Ce qu'ils ne peuvent pas faire, c'est créer de nouvelles collections ou changer le schéma sans développeur. C'est une contrainte stricte par conception.
Payload fonctionne-t-il avec Next.js ?
Oui, et particulièrement bien. Payload 2.x a été reconstruit sur Next.js, vous pouvez donc exécuter le CMS et votre frontend depuis la même application Next.js. Cette configuration « monorepo dans un seul dépôt » fonctionne bien pour les petits à moyens projets et réduit votre surcharge d'infrastructure.
Quelle base de données dois-je utiliser avec Payload ?
Pour les nouveaux projets en 2026, je défaut à PostgreSQL via Drizzle ORM. C'est bien testé, vous obtenez les bonnes contraintes relationnelles, et les outils de migration sont solides s'il sont utilisés avec soin. MongoDB reste une option et convient toujours bien si vos données sont façonnées comme des documents par nature, mais Postgres est ma première recommandation.
Comment Payload gère-t-il les envois de médias ?
Par défaut, Payload stocke les uploads localement sur le système de fichiers du serveur, ce qui convient au développement mais pas à la production. Pour la production, vous voudrez configurer un adaptateur de stockage pointant vers S3, Cloudflare R2, ou similaire. Le package officiel @payloadcms/plugin-cloud-storage gère cela et il faut environ une heure pour le configurer correctement la première fois.
Payload est-il prêt pour les sites de production à grande échelle ?
Il gère le trafic de production sérieux pour un certain nombre d'entreprises. Cela dit, ce n'est pas le CMS que je choisirais pour un site avec 10 millions de visiteurs mensuels et une équipe éditoriale de 20 personnes. À cette échelle, vous chercheriez des solutions de classe entreprise avec des contrats de support dédiés. Pour les projets mid-market construits par des agences qui constituent la majorité de notre travail chez Seahawk, Payload est stable et capable.
L'avis honnête
Payload CMS en 2026 est un outil mature et bien conçu pour les projets menés par des développeurs où le coût à long terme compte et où vous avez la capacité d'ingénierie pour maîtriser la stack. L'investissement initial en temps de configuration est réel. Le coût d'infrastructure continu est faible. L'expérience développeur est bonne.
Ce n'est pas un remplaçant WordPress. Ce n'est pas ce qu'il essaie d'être. Mais pour le bon projet, avec la bonne équipe, c'est l'option CMS headless la plus rentable avec laquelle j'ai travaillé sur plus de 12 000 builds. La question n'est pas si c'est bon. C'est si c'est bon pour votre situation.