Choisir un CMS headless en 2026 ressemble à prendre parti dans un débat philosophique. D'un côté, vous avez Payload CMS — open-source, auto-hébergé, orienté code, et de plus en plus chéri des développeurs qui veulent un contrôle total. De l'autre, Hygraph (anciennement GraphCMS) — une plateforme SaaS GraphQL native gérée qui s'occupe de l'infrastructure pour vous. J'ai déployé des projets de production avec les deux au cours des deux dernières années, et la réponse honnête est : aucun n'est universellement meilleur. Mais l'un sera presque certainement meilleur pour votre situation spécifique. Décortiquons exactement pourquoi.

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 : orienté code, auto-hébergé

Payload est un CMS headless open-source orienté TypeScript qui s'exécute sur votre propre infrastructure. Depuis la version Payload 3.0 (sortie fin 2024 et affinée tout au long de 2025), il est construit directement au-dessus de Next.js. Ce n'est pas une coquille — Payload est littéralement une application Next.js. Votre panneau d'administration 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 des fichiers TypeScript. Il n'y a pas d'interface utilisateur pour la création de schéma — vous l'écrivez, vous le commitez, vous le versionnez. C'est soit merveilleux, soit terrible selon votre équipe.

Payload supporte à la fois MongoDB et PostgreSQL (via Drizzle ORM) comme adaptateurs de base de données. Depuis début 2026, l'adaptateur Postgres a mûri considérablement et c'est celui que je recommande pour la plupart des nouveaux projets.

Hygraph : GraphQL native SaaS

Hygraph prend l'approche opposée. C'est une plateforme entièrement géré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, 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 un choix de conception intentionnel. Ils se sont fortement appuyés sur l'écosystème GraphQL — y compris le support de la fédération de contenu, des sources distantes et des types d'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 les modifications de votre configuration, l'interface d'administration s'exécute sur localhost, et vous pouvez déboguer tout dans un seul processus. Puisque c'est Next.js, votre stack entière — frontend, CMS, API — s'exécute dans une seule commande next dev. C'est vraiment agréable. Pas de latence réseau vers une API distante pendant le développement, pas de couches de simulation, pas d'instances CMS distinctes à gérer.

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

Support TypeScript

Payload génère les types automatiquement à partir de votre configuration. Puisque votre schéma est TypeScript, les types sont toujours en synchronisation. C'est une de ces choses qui semble mineure jusqu'à ce que vous ayez affaire à un CMS où les types divergent 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 à l'exécution.

Interface d'administration

Le panneau d'administration Payload est basé sur React et entièrement personnalisable. Vous pouvez échanger les composants de champ, ajouter des vues personnalisées, injecter vos propres routes. Il a l'air propre et moderne depuis Payload 3.x, bien qu'il ne gagnera pas de prix de conception. C'est fonctionnel.

L'interface d'administration Hygraph est soignée et construite dans le but de servir les rédacteurs de contenu. L'expérience d'édition de contenu est sans doute 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 pur.

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

Modélisation du contenu

Approche de Payload

La modélisation du contenu dans Payload se fait dans le 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 versionné, examiné dans les PR, et déployé avec votre code d'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 de Hygraph

Hygraph vous donne un éditeur de schéma visuel. Vous glissez et déposez les types de champ, configurez les validations, créez des 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 modifier soit une conversation différente).

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

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

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

Design API et requêtes

Payload : REST + GraphQL

Payload vous donne une API REST et une API GraphQL directement. L'API REST est générée automatiquement à partir de vos collections et suit des conventions prévisibles. L'API GraphQL est également générée automatiquement.

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 depuis le 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 saute la couche réseau entièrement. Quand vous construisez avec Next.js et Payload dans le même projet, c'est la façon principale dont vous récupérez 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 un filtrage solide, une pagination et un classement. Ils supportent les étapes de contenu (DRAFT, PUBLISHED), la localisation au niveau du champ, et un point de terminaison de lecture haute performance qui sert le contenu mis en cache à partir de l'edge.

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

Performance et scalabilité

Les performances de Payload dépendent entièrement de votre infrastructure. S'exécutant sur un VPS décent avec PostgreSQL et un indexage approprié, j'ai observé des temps de réponse P95 inférieurs à 30 ms pour l'API locale et environ 50-80 ms pour les points de terminaison REST/GraphQL. Mais vous êtes responsable de la mise à l'échelle. 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 mise à l'échelle pour vous. Leur API de lecture mise en cache à l'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 20-50 ms dans le monde entier. Pour les sites de contenu à lecture intensive, c'est difficile à battre sans travail infrastructurel significatif du côté auto-hébergé.

Pour nos projets de développement de CMS headless, nous avons constaté 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 de Hygraph pour la plupart des modèles de trafic du monde réel.

Ventilation des tarifs pour 2026

C'est là que les choses deviennent intéressantes. Voici les vrais chiffres.

Plan Payload CMS Hygraph
Gratuit/Open Source 0 $ (auto-hébergé, toutes les fonctionnalités) Plan gratuit : 2 sièges, 1M appels API/mois, 500 entrées de contenu
Petite équipe ~20-50 $/mois de coûts d'hébergement Starter : 0 $ (limité), Growth : tarification personnalisée
Échelle moyenne ~100-300 $/mois (VPS + DB + stockage) Professionnel : à partir de ~399 $/mois
Entreprise 500-2000 $/mois d'infra (varie énormément) Entreprise : 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 entièrement gratuit. Vous payez pour votre propre infrastructure d'hébergement. Un VPS Hetzner (20 $/mois), une instance Postgres gérée (15-30 $/mois) et un stockage compatible S3 (5-10 $/mois) vous rend un setup prêt pour la production pour moins de 60 $ par mois. Payload offre également Payload Cloud — leur service d'hébergement géré — à partir de 30 $/mois par projet, ce qui simplifie considérablement le déploiement.

Le plan gratuit de 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, de rôles personnalisés, de plusieurs environnements ou de limites API plus élevées, vous passez à leurs plans payants. Le plan Professionnel coûte environ 399 $ par mois en 2026, ce qui est un coût récurrent significatif. La tarification d'entreprise est négociée mais commence généralement autour de 1 500 $ par mois.

Voici la nuance : si vous factoriez le temps du développeur pour gérer l'infrastructure, la tarification de Hygraph pourrait être moins chère pour les petites équipes sans expertise DevOps. Inversement, 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 changer ses conditions, abandonner une fonctionnalité ou retenir votre contenu en otage.
  • Pas de limites de taux API. Vous êtes limité par votre infrastructure, pas par un niveau de plan 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 d'administration — il n'y a rien que vous ne puissiez changer.
  • Colocation avec votre application. 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 à corriger, pas de bases de données à sauvegarder, pas de mise à l'échelle à gérer.
  • Performance edge mondiale directement. L'API soutenue par CDN de Hygraph est rapide partout sans que vous configuviez quelque chose.
  • Fédération de contenu. La fonctionnalité Remote Sources de Hygraph vous permet de tirer les données d'API externes dans votre graphe de contenu. C'est vraiment puissant pour les architectures composables.
  • Convivial pour les non-développeurs. L'onboarding des rédacteurs de contenu est plus simple quand le générateur de schéma est visuel.
  • Garanties de disponibilité. Hygraph offre des SLA sur leurs plans d'entreprise. La disponibilité auto-hébergée est votre problème.

Pour les équipes pour lesquelles la gestion de l'infrastructure est une force (ou pour lesquelles elles travaillent avec une agence de développement Next.js qui la gère), Payload est le meilleur choix. Pour les équipes qui veulent se concentrer purement sur le contenu et le développement frontend, Hygraph supprime des frictions réelles.

Authentification et contrôle d'accès

Payload

Payload a l'authentification intégrée. Utilisateurs, sessions, vérification par courriel, réinitialisation de mot de passe — c'est tout là. Vous pouvez définir un contrôle d'accès au niveau du champ et au niveau de la collection 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 vrai contrôle d'accès au niveau du code. Vous pouvez écrire n'importe quelle logique. Besoin de vérifier contre un service externe ? Allez-y. Besoin de restreindre l'accès selon les champs du document actuel ? C'est fait.

Hygraph

Hygraph utilise un système de jetons d'authentification permanents avec permissions configurables. Vous créez des jetons avec un accès spécifique aux étapes de contenu (par exemple, lecture PUBLISHED uniquement, lecture DRAFT, écriture). 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 plutôt que de les exprimer dans le code. Les scénarios complexes — comme « les rédacteurs peuvent uniquement mettre à jour les articles de leur catégorie assignée » — nécessitent des contournements créatifs dans Hygraph mais sont triviaux dans Payload.

Écosystème de plugins et extensibilité

L'écosystème de plugins de Payload a considérablement augmenté depuis la version 3.0. Les plugins notables incluent :

  • @payloadcms/plugin-seo — Champs de métadonnées SEO et aperçus
  • @payloadcms/plugin-form-builder — Création de formulaires dynamiques
  • @payloadcms/plugin-search — Intégration de recherche plein texte
  • @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'ils ne sont que des fonctions qui modifient la configuration Payload.

L'extensibilité de Hygraph s'effectue via :

  • Applications et extensions de barre latérale — Éléments d'interface utilisateur personnalisés dans l'éditeur
  • Webhooks — Déclencher les flux de travail externes sur les modifications de contenu
  • Remote Sources — Fédérer les API GraphQL et REST externes
  • API de gestion — Gérer programmatiquement le schéma et le contenu

La place de marché d'applications de Hygraph a augmenté mais reste plus petite que l'écosystème de plugins de Payload. La fonctionnalité Remote Sources, cependant, est quelque chose que Payload n'a pas d'équivalent. Pouvoir assembler un catalogue de produits Shopify directement dans votre graphe de contenu sans middleware est vraiment utile.

Quand choisir l'un ou l'autre

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

Choisissez Payload CMS si :

  • Vous êtes une équipe de développement (ou travaillez avec une) à l'aise avec TypeScript et l'infrastructure
  • Vous avez besoin d'une personnalisation approfondie du comportement du CMS
  • La propriété des données et l'indépendance vis-à-vis des fournisseurs vous importent
  • Vous construisez une application 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é vers le 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 rédacteurs de contenu ont besoin d'une expérience d'édition visuelle soignée directement
  • Vous avez besoin d'une performance edge mondiale garantie sans configurer les CDN
  • Votre chronologie de projet est serrée et vous ne pouvez pas vous permettre le temps de configuration

Pour de nombreux 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 avec la façon dont nous travaillons. Mais nous avons également expédié des projets alimentés par Hygraph pour les clients dont les équipes avaient besoin de la simplicité d'une plateforme gérée.

Il n'y a pas de honte à faire l'un ou l'autre choix. La honte est de choisir l'un sans comprendre les compromis. Si vous ne savez pas quelle direction est la bonne pour votre projet, nous sommes heureux de discuter.

FAQ

Payload CMS est-il vraiment gratuit ?

Oui. Payload CMS est sous licence MIT et le noyau est entièrement gratuit, y compris toutes les fonctionnalités — il n'y a pas de « niveau premium » qui bloque les fonctionnalités derrière un mur de paiement. 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 géré, qui commence à 30 $ par mois par projet si vous ne voulez pas gérer votre propre infrastructure.

Hygraph peut-il fonctionner sans connaissances de GraphQL ?

Le côté édition de contenu ne nécessite aucune connaissance de GraphQL — les rédacteurs utilisent simplement l'interface visuelle. Cependant, les développeurs interrogeant le contenu d'Hygraph doivent utiliser GraphQL. Il n'y a pas d'alternative d'API REST. 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 a 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'image réactives en fonction de votre configuration. Pour la plupart des projets, la connecter à un bucket 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 les 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 ensuite les rédacteurs 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 vers Payload (ou vice versa) ?

La migration est possible mais pas triviale dans l'une ou l'autre direction. 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 de contenu — en particulier le texte riche, qui est stocké différemment dans chaque système. Planifiez un script de migration et un test approfondi. Pour les grandes bibliothèques de contenu, budgétisez au moins 2-4 semaines pour une migration propre.

Quel CMS est mieux pour le commerce électronique ?

Aucun n'est une plateforme de commerce électronique, mais les deux s'intègrent bien avec les solutions de commerce headless. Hygraph a un avantage ici avec sa fonctionnalité Remote Sources, qui peut fédérer les données de produits de Shopify ou commercetools directement dans votre graphe de contenu. Payload fonctionne très bien aussi avec les backends de commerce électronique, 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 de commerce électronique sérieux, considérez l'un ou l'autre CMS aux côtés d'un backend de commerce électronique dédié.

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

Payload 3.x était une réécriture majeure. Le plus grand changement est que Payload s'exécute maintenant en tant que plugin Next.js plutôt que en tant qu'application Express. Cela signifie que votre CMS et votre frontend partagent le même processus, permettant l'API locale pour les requêtes à latence zéro. Il a également ajouté le support de PostgreSQL (via Drizzle ORM), l'aperçu en direct et une interface d'administration redessinée. Si vous avez utilisé Payload 2.x et avez trouvé cela limitant, 3.x vaut un autre coup d'œil — 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 service VPS ou conteneur (Railway, Render, Fly.io ou un VPS Hetzner avec Docker), PostgreSQL gérée (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 $ par 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.