Votre client approuve les wireframes. Votre repo Next.js est scaffoldé. Puis vous vous heurtez à la décision du CMS et tout s'arrête. Payload CMS offre un contrôle code-first auto-hébergé — vous êtes propriétaire de la base de données, écrivez des hooks personnalisés, déployez où vous le souhaitez. Hygraph vous offre une API GraphQL managée, gère la scalabilité, et facture mensuellement que vous utilisiez 100 requêtes ou 100 000. J'ai livré des projets en production avec les deux au cours des deux dernières années. Aucun ne gagne universellement, mais l'un s'adaptera presque certainement mieux à votre stack, à la tolérance DevOps de votre équipe et au budget de votre client que l'autre. La question n'est pas quel CMS est objectivement supérieur — c'est quels compromis vous êtes prêt à accepter quand quelque chose se casse à 23h ou que votre équipe de contenu demande une fonctionnalité que Hygraph n'expose pas. Voici comment décider sans reconstruire deux fois votre modèle de contenu.

Table des matières

Payload CMS vs Hygraph 2026: Auto-hébergé vs GraphQL SaaS comparé

Architecture et philosophie

Ces deux CMS proviennent de visions fondamentalement différentes, et comprendre cela est plus important que n'importe quel tableau de comparaison de fonctionnalités.

Payload CMS : Code-first, auto-hébergé

Payload est un CMS headless open-source d'abord TypeScript qui s'exécute sur votre propre infrastructure. Depuis la sortie de Payload 3.0 (qui s'est produite fin 2024 et a été affinée tout au long des versions récentes), il est construit directement sur Next.js. Ce n'est pas une faute de frappe — Payload est littéralement une app Next.js. Votre panneau admin CMS, vos routes API et votre frontend peuvent tous vivre dans le même projet.

La configuration est du code. Vous définissez les collections, les champs, les hooks et le contrôle d'accès dans les fichiers TypeScript. Il n'y a pas d'interface utilisateur pour construire le schéma — vous l'écrivez, le commitez, le versionnez. C'est soit merveilleux soit terrible selon votre équipe.

Payload supporte MongoDB et PostgreSQL (via Drizzle ORM) comme adaptateurs de base de données. Début 2026, l'adaptateur Postgres a mûri de manière significative et c'est ce que je recommanderais pour la plupart des nouveaux projets.

Hygraph : SaaS natif GraphQL

Hygraph adopte l'approche opposée. C'est une plateforme entièrement managée avec un générateur de schéma visuel, une API GraphQL hébergée, et zéro infrastructure à gérer. Vous modelez votre contenu dans leur interface utilisateur, configurez les webhooks, configurez les environnements, et c'est parti.

Sous le capot, Hygraph s'exécute sur une infrastructure edge distribuée mondialement. Leur API de contenu est exclusivement GraphQL (pas de point de terminaison REST), ce qui est une décision de conception intentionnelle. Ils ont beaucoup misé sur l'écosystème GraphQL — y compris le support de la fédération de contenu, des sources distantes et des types union.

Hygraph n'est pas open-source. Vous louez la plateforme.

Expérience développeur

Développement local

Avec Payload, le développement local est juste pnpm dev. Vous obtenez le rechargement à chaud sur vos changements de configuration, l'interface admin s'exécute sur localhost, et vous pouvez déboguer tout dans un seul processus. Puisque c'est Next.js, votre pile entière — frontend, CMS, API — s'exécute dans une seule commande next dev. C'est vraiment sympa. Pas de latence réseau vers une API distante pendant le développement, pas de couches de mock, pas d'instances CMS séparées à gérer.

Hygraph vous oblige à travailler contre leur API cloud pendant le développement. Ils offrent des environnements de développement et du branching (sur les forfaits de niveau supérieur), mais vous effectuez toujours des requêtes réseau. Pour les équipes dans des régions éloignées de leurs nœuds edge, cela peut ajouter une latence perceptible pendant le développement. Sur le plus côté positif, il y a zéro configuration — inscrivez-vous, créez un projet, commencez à interroger.

Support TypeScript

Payload génère automatiquement les types à partir de votre configuration. Puisque votre schéma est TypeScript, les types sont toujours synchronisés. C'est l'une de ces choses qui semble mineure jusqu'à ce que vous ayez affaire à un CMS où les types dérivent de la réalité.

Hygraph vous oblige à générer les types à partir de leur schéma GraphQL, généralement via GraphQL Code Generator. Cela fonctionne, mais c'est une étape supplémentaire dans votre pipeline. Et si quelqu'un change le schéma dans l'interface Hygraph sans mettre à jour les types générés, vous le découvrirez au runtime.

Interface admin

Le panneau admin de Payload est basé sur React et complètement personnalisable. Vous pouvez échanger les composants de champ, ajouter des vues personnalisées, injecter vos propres routes. Il a l'air propre et moderne à partir de Payload 3.x, bien qu'il ne remporte aucun prix de design. C'est fonctionnel.

L'interface admin d'Hygraph est soignée et spécialement conçue pour les éditeurs de contenu. L'expérience d'édition de contenu est en quelque sorte plus fluide pour les utilisateurs non techniques. La navigation de la barre latérale, la gestion des actifs et les flux de travail d'étapes de contenu se sentent plus matures du point de vue de l'UX pure.

Fonctionnalité Payload CMS Hygraph
Développement local Stack local complet API cloud uniquement
TypeScript Natif, auto-généré Via graphql-codegen
Personnalisation de l'admin Remplacement complet du composant React Limité (applications de barre latérale personnalisées)
UX de l'éditeur de contenu Bon, orienté développeur Soigné, orienté éditeur
Temps de configuration 5-15 min (nécessite Node + DB) 2 min (s'inscrire et partir)

Modélisation de contenu

Approche de Payload

La modélisation de contenu dans Payload se fait en code. Voici un exemple simplifié :

import { CollectionConfig } from 'payload'

export const Articles: CollectionConfig = {
  slug: 'articles',
  admin: {
    useAsTitle: 'title',
  },
  fields: [
    {
      name: 'title',
      type: 'text',
      required: true,
    },
    {
      name: 'content',
      type: 'richText',
    },
    {
      name: 'author',
      type: 'relationship',
      relationTo: 'users',
    },
    {
      name: 'publishedAt',
      type: 'date',
    },
  ],
}

Ceci est contrôlé par version, examiné dans les PRs et déployé aux côtés du code de votre application. Besoin d'ajouter un champ ? Modifiez la configuration, exécutez une migration si vous utilisez Postgres, déployez. Le modèle mental est très proche de la façon dont vous définiriez un schéma de base de données avec un ORM.

Payload supporte les blocs, les tableaux, les groupes, les onglets, la logique conditionnelle et les types de champs personnalisés. Le type de champ blocks est particulièrement puissant pour construire des générateurs de pages flexibles.

Approche d'Hygraph

Hygraph vous offre un éditeur de schéma visuel. Vous glissez-déposez les types de champ, configurez les validations, configurez les références entre les modèles. C'est intuitif et rapide pour la configuration initiale. Les non-développeurs peuvent comprendre le schéma (bien que la question de savoir s'ils devraient le changer est une conversation différente).

Hygraph supporte les composants (groupes de champs réutilisables), les types union pour les références polymorphes, et un concept appelé « Sources distantes » qui vous permet de fédérer les API externes directement dans votre graphique de contenu. Cette dernière fonctionnalité est véritablement unique et utile pour certaines architectures.

L'inconvénient ? Les changements de schéma dans Hygraph se produisent dans leur interface utilisateur. Bien qu'ils offrent un branching d'environnement et des migrations de schéma sur les forfaits entreprise, vous n'obtenez pas le même flux d'examen du code que Payload fournit nativement.

Payload CMS vs Hygraph 2026: Auto-hébergé vs GraphQL SaaS comparé - architecture

Conception et interrogation des API

Payload : REST + GraphQL

Payload vous offre à la fois une API REST et une API GraphQL d'emblée. L'API REST est auto-générée à partir de vos collections et suit des conventions prévisibles. L'API GraphQL est également auto-générée.

Mais voici la chose que la plupart des gens manquent : Payload expose également une API locale qui vous permet d'interroger votre base de données directement à partir du code côté serveur sans aucune surcharge HTTP :

// Composant serveur ou route API
const articles = await payload.find({
  collection: 'articles',
  where: {
    publishedAt: { less_than: new Date().toISOString() },
  },
  depth: 2,
  limit: 10,
})

Cette API locale est absurdement rapide car elle ignore complètement la couche réseau. Quand vous construisez avec Next.js et Payload dans le même projet, c'est la façon principale dont vous allez récupérer le contenu. C'est un énorme avantage.

Hygraph : GraphQL uniquement

Hygraph est GraphQL tout du long. Pas d'API REST. Vos requêtes ressemblent à ceci :

query GetArticles {
  articles(where: { publishedAt_lt: "2026-01-01" }, first: 10) {
    title
    content {
      html
    }
    author {
      name
    }
  }
}

L'API GraphQL est bien conçue avec une bonne filtration, pagination et classement. Ils supportent les étapes de contenu (DRAFT, PUBLISHED), la localisation au niveau du champ et un point de terminaison de lecture hautes performances qui sert le contenu mis en cache depuis l'edge.

Si votre équipe travaille beaucoup avec GraphQL — disons que vous utilisez Apollo Client ou urql — Hygraph se sent naturel. Si votre équipe ne connaît pas GraphQL, la courbe d'apprentissage est réelle.

Performance et scalabilité

La performance de Payload dépend entièrement de votre infrastructure. S'exécutant sur un VPS décent avec PostgreSQL et un indexation appropriée, j'ai vu des temps de réponse P95 sous 30ms pour l'API locale et autour de 50-80ms pour les points de terminaison REST/GraphQL. Mais vous êtes responsable de la scalabilité. Besoin de gérer un pic de trafic ? C'est à vous — ajoutez plus de conteneurs, mettez à l'échelle votre base de données, configurez la mise en cache.

Hygraph gère la scalabilité pour vous. Leur API de lecture sauvegardée par le cache edge (ce qu'ils appellent l'« API de contenu ») sert les réponses à partir de nœuds CDN distribués mondialement. Les temps de réponse typiques sont de 20-50ms dans le monde entier. Pour les sites de contenu lourds en lecture, c'est difficile à battre sans un travail d'infrastructure significatif du côté auto-hébergé.

Pour nos projets de développement CMS headless, nous avons découvert que Payload avec une mise en cache appropriée (ISR ou revalidation à la demande dans Next.js) fonctionne de manière comparable à l'API edge d'Hygraph pour la plupart des modèles de trafic du monde réel.

Détail des prix 2026

C'est là que les choses deviennent intéressantes. Laissez-moi vous présenter les vrais chiffres.

Forfait Payload CMS Hygraph
Gratuit/Open Source $0 (auto-hébergé, toutes les fonctionnalités) Niveau gratuit : 2 sièges, 1M appels API/mois, 500 entrées de contenu
Petite équipe ~$20-50/mois frais d'hébergement Starter : $0 (limité), Growth : tarification personnalisée
Moyenne échelle ~$100-300/mois (VPS + DB + stockage) Professional : à partir de ~$399/mois
Enterprise $500-2000/mois infra (varie énormément) Enterprise : tarification personnalisée (~$1500+/mois)
Payload Cloud À partir de $30/mois par projet N/A

Payload CMS lui-même est sous licence MIT et complètement gratuit. Vous payez pour votre propre infrastructure d'hébergement. Un VPS Hetzner ($20/mois), une instance Postgres managée ($15-30/mois) et un stockage compatible S3 ($5-10/mois) vous obtient une configuration prête pour la production pour moins de $60/mois. Payload offre également Payload Cloud — leur service d'hébergement managé — à partir de $30/mois par projet, ce qui simplifie le déploiement de manière significative.

Le niveau gratuit d'Hygraph est utilisable pour les petits projets et les prototypes. Mais une fois que vous avez besoin de plus de 2 sièges d'équipe, des rôles personnalisés, de plusieurs environnements ou des limites d'API plus élevées, vous passez à leurs forfaits payants. Le niveau Professional coûte environ $399/mois en 2026, ce qui est un coût récurrent significatif. La tarification Enterprise est négociée mais commence généralement autour de $1500/mois.

Voici la nuance : si vous tenez compte du temps de développeur pour gérer l'infrastructure, la tarification d'Hygraph pourrait en fait être moins chère pour les petites équipes sans expertise DevOps. À l'inverse, pour les agences gérant de nombreux projets, le noyau gratuit de Payload signifie que votre coût marginal par projet est juste l'hébergement.

Auto-hébergement vs SaaS : les vrais compromis

C'est la tension centrale, et je veux être honnête sur les deux côtés.

Pourquoi l'auto-hébergement (Payload) gagne

  • Propriété des données. Vos données vivent dans votre base de données. Point final. Aucun fournisseur ne peut modifier ses conditions, abandonner une fonctionnalité ou tenir votre contenu en otage.
  • Pas de limites de taux API. Vous êtes limité par votre infrastructure, pas par un niveau de forfait arbitraire.
  • Coût à l'échelle. Une fois que vous dépassez un certain seuil de trafic, l'auto-hébergement est dramatiquement moins cher.
  • Profondeur de personnalisation. Hooks, points de terminaison personnalisés, types de champs personnalisés, remplacements d'interface admin — il n'y a rien que vous ne puissiez changer.
  • Colocation avec votre app. Exécuter Payload et Next.js dans le même processus élimine la latence réseau pour les requêtes de contenu.

Pourquoi SaaS (Hygraph) gagne

  • Zéro charge opérationnelle. Pas de serveurs à patcher, pas de bases de données à sauvegarder, pas de scalabilité à gérer.
  • Performance edge globale d'emblée. L'API soutenue par CDN d'Hygraph est rapide partout sans que vous configuriez quoi que ce soit.
  • Fédération de contenu. La fonctionnalité Sources distantes d'Hygraph vous permet de tirer les données d'API externes dans votre graphique de contenu. C'est véritablement puissant pour les architectures composables.
  • Conviviale pour les non-développeurs. Intégrer les éditeurs de contenu est plus simple quand le générateur de schéma est visuel.
  • Garanties de disponibilité. Hygraph offre des SLA sur ses forfaits entreprise. La disponibilité auto-hébergée est votre problème.

Pour les équipes où la gestion d'infrastructure est une force (ou où elles s'associent avec une agence de développement Next.js qui s'en charge), Payload est le choix plus fort. Pour les équipes qui veulent se concentrer purement sur le contenu et le développement frontend, Hygraph supprime la friction réelle.

Authentification et contrôle d'accès

Payload

Payload dispose d'une authentification intégrée. Utilisateurs, sessions, vérification e-mail, réinitialisation de mot de passe — c'est tout là. Vous pouvez définir le contrôle d'accès au niveau des champs et au niveau des collections avec des fonctions :

access: {
  read: ({ req: { user } }) => {
    if (user?.role === 'admin') return true
    return {
      publishedAt: { less_than: new Date().toISOString() },
    }
  },
  update: ({ req: { user } }) => user?.role === 'admin',
}

C'est un contrôle d'accès réel au niveau du code. Vous pouvez écrire n'importe quelle logique que vous voulez. Besoin de vérifier contre un service externe ? Allez-y. Besoin de limiter l'accès en fonction des champs du document actuel ? Fait.

Hygraph

Hygraph utilise un système de jetons d'authentification permanents avec des permissions configurables. Vous créez des jetons avec un accès spécifique à l'étape de contenu (par exemple, lire PUBLISHED uniquement, lire DRAFT, écrire). Pour un contrôle plus granulaire, ils supportent les permissions personnalisées liées aux rôles.

Cela fonctionne, mais c'est moins flexible que l'approche de Payload. Vous configurez les permissions via leur interface utilisateur plutôt que de les exprimer en code. Les scénarios complexes — comme « les éditeurs ne peuvent mettre à jour que les articles de leur catégorie assignée » — nécessitent des solutions créatives dans Hygraph mais sont triviales dans Payload.

Écosystème de plugins et extensibilité

L'écosystème de plugins de Payload s'est considérablement développé depuis 3.0. Les plugins notables incluent :

  • @payloadcms/plugin-seo — Champs de métadonnées SEO et aperçus
  • @payloadcms/plugin-form-builder — Création dynamique de formulaires
  • @payloadcms/plugin-search — Intégration de recherche en texte intégral
  • @payloadcms/plugin-redirects — Gestion des redirections
  • Plugins communautaires pour l'intégration de Stripe, la génération de contenu IA et plus

Écrire des plugins personnalisés est simple puisqu'il s'agit juste de fonctions qui modifient la configuration de Payload.

L'extensibilité d'Hygraph vient par :

  • Applications et extensions de barre latérale — Éléments d'interface utilisateur personnalisés dans l'éditeur
  • Webhooks — Déclencher des workflows externes sur les changements de contenu
  • Sources distantes — Fédérer les API externes GraphQL et REST
  • API de gestion — Gérer par programmation le schéma et le contenu

Le marché d'applications d'Hygraph a grandi mais est toujours plus petit que l'écosystème de plugins de Payload. La fonctionnalité Sources distantes, cependant, est quelque chose pour laquelle Payload n'a pas d'équivalent. Pouvoir coudre un catalogue de produits Shopify directement dans votre graphique de contenu sans middleware est véritablement utile.

Quand choisir lequel

Après avoir travaillé avec les deux sur plusieurs projets en production, voici mon cadre d'recommandation honnête :

Choisissez Payload CMS si :

  • Vous êtes une équipe de développement (ou travaillant avec une) à l'aise avec TypeScript et l'infrastructure
  • Vous avez besoin d'une personnalisation profonde du comportement du CMS
  • La propriété des données et l'indépendance de fournisseur vous importent
  • Vous construisez une app Next.js et voulez l'avantage de performance de l'API locale
  • Vous êtes une agence gérant de nombreux projets et voulez minimiser les coûts de licence par projet
  • Vous avez besoin d'un contrôle d'accès complexe et orienté code

Choisissez Hygraph si :

  • Vous voulez zéro gestion d'infrastructure
  • Votre équipe est déjà investie dans GraphQL
  • Vous avez besoin de fédération de contenu à partir de plusieurs sources
  • Vos éditeurs de contenu ont besoin d'une expérience d'édition visuelle soignée d'emblée
  • Vous avez besoin d'une performance edge globale garantie sans configurer les CDN
  • La chronologie de votre projet est serrée et vous ne pouvez pas vous permettre du temps de configuration

Pour beaucoup des projets que nous construisons chez Social Animal — en particulier les projets Astro et Next.js — Payload est devenu notre recommandation par défaut. L'histoire de colocation, l'approche native TypeScript et les coûts de licence zéro s'alignent bien sur la façon dont nous travaillons. Mais nous avons également livré des projets alimentés par Hygraph pour les clients dont les équipes avaient besoin de la simplicité d'une plateforme managée.

Il n'y a pas de honte à choisir l'un ou l'autre. La honte est de choisir sans comprendre les compromis. Si vous n'êtes pas sûr de la direction qui convient à votre projet, nous serions heureux de en discuter.

FAQ

Payload CMS est-il vraiment gratuit ?

Oui. Payload CMS est sous licence MIT et le noyau est complètement gratuit, y compris toutes les fonctionnalités — il n'y a pas de « niveau premium » qui verrouille les fonctionnalités derrière un mur payant. Vous payez pour votre propre infrastructure d'hébergement (serveurs, base de données, stockage). Payload offre également Payload Cloud, leur service d'hébergement managé, qui commence à $30/mois par projet si vous ne voulez pas gérer votre propre infrastructure.

Hygraph peut-il fonctionner sans connaissance de GraphQL ?

Le côté édition de contenu ne nécessite aucune connaissance de GraphQL — les éditeurs utilisent juste l'interface visuelle. Cependant, les développeurs interrogeant le contenu d'Hygraph doivent utiliser GraphQL. Il n'y a pas d'alternative REST API. Si votre équipe frontend n'est pas à l'aise avec GraphQL, il y a une courbe d'apprentissage que vous devez factoriser dans votre chronologie.

Comment Payload CMS gère-t-il les téléchargements de médias et de fichiers ?

Payload dispose d'un système de téléchargement intégré qui supporte le stockage de fichiers local, le stockage compatible S3 (AWS S3, Cloudflare R2, MinIO) et d'autres adaptateurs. Il inclut le redimensionnement automatique des images, la sélection du point focal et génère des tailles d'images réactives en fonction de votre configuration. Pour la plupart des projets, le connecter à un compartiment S3 ou Cloudflare R2 est l'approche recommandée.

Hygraph supporte-t-il la localisation ?

Oui. Hygraph a la localisation au niveau du champ intégrée, ce qui signifie que vous pouvez marquer les champs individuels comme localisables plutôt que de dupliquer des entrées de contenu entières. C'est une fonctionnalité forte — vous configurez vos paramètres régionaux dans les paramètres du projet et les éditeurs de contenu peuvent basculer entre les langues dans l'éditeur. Payload supporte également la localisation avec une approche similaire au niveau du champ.

Puis-je migrer d'Hygraph à Payload (ou vice versa) ?

La migration est possible mais pas triviale dans les deux sens. Les deux systèmes ont des API qui vous permettent d'exporter et d'importer du contenu. Le principal défi est les différences de modélisation du contenu — en particulier le texte enrichi, qui est stocké différemment dans chaque système. Préparez un script de migration et des tests approfondis. Pour les grandes bibliothèques de contenu, budgétisez au moins 2-4 semaines pour une migration propre.

Quel CMS est meilleur pour l'e-commerce ?

Aucun n'est une plateforme d'e-commerce, mais les deux s'intègrent bien avec les solutions de commerce sans tête. Hygraph a un avantage ici avec sa fonctionnalité Sources distantes, qui peut fédérer les données de produits de Shopify ou commercetools directement dans votre graphique de contenu. Payload fonctionne bien avec les backends d'e-commerce aussi, mais vous construirez généralement l'intégration vous-même en utilisant des hooks et des points de terminaison personnalisés. Pour les projets d'e-commerce sérieux, envisagez l'un ou l'autre CMS aux côtés d'un backend de commerce dédié.

Comment Payload 3.x se compare-t-il à Payload 2.x ?

Payload 3.x était une refonte majeure. Le plus grand changement est que Payload s'exécute maintenant comme un plugin Next.js plutôt qu'une app Express. Cela signifie que votre CMS et votre frontend partagent le même processus, activant l'API locale pour les requêtes de latence zéro. Il a également ajouté le support de PostgreSQL (via Drizzle ORM), l'aperçu en direct et une interface admin repensée. Si vous avez utilisé Payload 2.x et l'avez trouvé limitant, 3.x vaut la peine de réessayer — c'est une expérience fondamentalement différente.

Quelle est la meilleure configuration d'hébergement pour Payload CMS en 2026 ?

Pour la plupart des projets, nous recommandons : un VPS ou un service de conteneur (Railway, Render, Fly.io ou un VPS Hetzner avec Docker), PostgreSQL managé (Neon, Supabase ou l'offre de votre fournisseur VPS) et Cloudflare R2 pour le stockage de médias. Le coût total s'exécute généralement $40-80/mois pour les petits à moyens projets. Pour les déploiements plus importants, Vercel avec Payload Cloud ou une configuration Kubernetes fonctionne bien. Consultez notre page de tarification pour savoir comment nous gérons la configuration d'infrastructure pour les projets clients.