Payload CMS : c'est quoi et pourquoi c'est une alternative sérieuse à WordPress ?

Ce qu'est Payload CMS, concrètement

Payload est un headless CMS open source écrit entièrement en TypeScript. Il est sorti en version stable en 2021 et a connu une adoption rapide depuis sa version 2.0, notamment grâce à son intégration native avec Next.js.

Le principe central est simple : vous définissez vos collections de données (articles, produits, auteurs, médias, pages) dans des fichiers TypeScript, et Payload génère automatiquement deux choses : une API REST et GraphQL pour consommer ces données depuis votre frontend, et une interface d'administration complète pour que les équipes contenu puissent travailler.

Pas d'interface à coder en plus. Pas de plugin à installer. L'admin suit la config. Si vous ajoutez un champ à une collection, il apparaît dans l'admin au prochain démarrage.

L'architecture : ce qui le distingue vraiment

Code-first, pas config-first

La majorité des CMS headless du marché (Contentful, Prismic, Sanity) proposent une interface graphique pour configurer les schémas de données. C'est pratique pour démarrer vite, mais ça crée une dépendance à l'interface du fournisseur. Versionner la configuration dans Git devient compliqué, et migrer d'un environnement à un autre demande des exports/imports manuels.

Avec Payload, toute la configuration est dans le code. Un fichier TypeScript qui décrit vos collections, vos champs, vos hooks, vos règles d'accès. Ça se commite, ça se review, ça se diff. C'est une différence fondamentale pour les équipes qui travaillent avec des processus de développement sérieux.

Même serveur que votre frontend Next.js

C'est l'une des décisions d'architecture les plus originales de Payload 2.0 : le CMS peut tourner dans la même application Next.js que votre frontend. Même processus Node.js, même déploiement. Vous n'avez pas besoin d'un serveur CMS séparé à maintenir, à monitorer et à faire évoluer indépendamment.

Concrètement, ça ressemble à ça : votre dossier app/ Next.js contient votre frontend, et Payload s'initialise en parallèle avec ses routes d'admin sur /admin. Un seul repo, un seul déploiement, deux interfaces.

Hooks et logique métier intégrés

Payload expose des hooks qui s'exécutent avant ou après les opérations CRUD sur vos collections : beforeChange, afterChange, beforeRead, afterDelete. Vous pouvez y brancher n'importe quelle logique : envoyer un email de notification quand un article est publié, recalculer un slug, appeler une API externe, invalider un cache CDN.

Pas besoin d'un système d'events séparé ni d'un webhook configuré dans une interface tierce. La logique est dans le code, versionnée, testable.

Les fonctionnalités qui comptent vraiment

Gestion des médias

Payload intègre une gestion des fichiers uploadés avec redimensionnement automatique, génération de variantes (thumbnails, formats WebP) et stockage configurable : local, S3, Cloudinary, ou n'importe quel driver que vous branchez. L'upload est une collection comme les autres, ce qui signifie que vous pouvez y ajouter des champs personnalisés (légende, droits d'auteur, tags) et les interroger via API.

Contrôle d'accès granulaire

Les règles d'accès se définissent au niveau de la collection et au niveau du champ. Un rédacteur peut modifier ses propres articles mais pas ceux des autres. Un éditeur peut publier mais pas supprimer. L'accès à un champ spécifique (par exemple un champ "note interne") peut être restreint aux administrateurs uniquement. C'est tout ça dans du TypeScript, pas dans une interface de permissions avec des cases à cocher.

Gestion des relations

Les relations entre collections sont typées et bidirectionnelles. Un article a un auteur (relation vers la collection Users), plusieurs tags (relation vers la collection Tags), et des articles liés (relation vers la collection Articles elle-même). GraphQL reflète ces relations avec du typage fort et des queries imbriquées. Pas besoin d'assembler des données à la main côté frontend.

Champ Rich Text basé sur Lexical

Payload 2.0 a remplacé Slate.js par Lexical (l'éditeur de Facebook) pour les champs de contenu riche. Lexical est plus stable, plus performant, et les plugins sont extensibles depuis la configuration Payload. Vous pouvez ajouter vos propres blocs de contenu personnalisés directement dans l'éditeur.

Ce que Payload ne fait pas (et c'est important de le savoir)

Payload n'est pas un outil pour les équipes non-techniques autonomes. L'installation initiale demande un développeur : configurer le projet, choisir la base de données (MongoDB ou PostgreSQL), définir les premières collections. Une fois en place, les équipes contenu peuvent travailler dans l'admin sans toucher au code, mais le démarrage est technique.

Il n'y a pas de marketplace de plugins ou de thèmes comme sur WordPress. L'extensibilité est totale mais elle passe par du code. Si vous avez besoin d'une fonctionnalité spécifique qui n'est pas intégrée, vous l'implémentez vous-même ou vous la composez à partir des hooks et des API disponibles.

Enfin, la maturité de l'écosystème est moindre que celle de Strapi ou de Contentful. La documentation est bonne, la communauté grandit vite (notamment sur Discord), mais certains cas d'usage avancés sont moins bien documentés qu'ils ne le seraient sur des outils plus anciens. Choisir entre Payload, Strapi et Contentful implique de peser cette dimension selon la séniorité de votre équipe.

Pourquoi ça intéresse autant les développeurs en ce moment

Il y a une raison simple : Payload remplit un vide. Les CMS SaaS comme Contentful ou Sanity sont puissants mais coûteux à l'échelle, et la configuration ne vous appartient pas vraiment. Strapi est open source mais son architecture Express commence à montrer son âge face aux projets Next.js modernes. WordPress en mode headless fonctionne, mais c'est du bricolage.

Payload arrive avec une stack TypeScript moderne, une intégration Next.js native, une vraie approche code-first, et une interface d'admin générée automatiquement. Pour les projets où voir comment Payload s'intègre dans des architectures concrètes aide à se projeter, les cas d'usage réels sont souvent plus parlants que la liste de features.

C'est un outil jeune. Mais il comble exactement le besoin que beaucoup de développeurs formulaient depuis quelques années sans trouver de réponse satisfaisante.