Votre client valide Contentful en mars. En août, votre équipe dev Slack sur le fait de l'arracher. J'ai déployé des builds en production avec Contentful, Sanity et Payload sur 40+ projets depuis 2022—certains étaient des apps Next.js greenfield, d'autres des sauvetages d'installations WordPress tenues ensemble par du scotch et des prières. Chaque CMS a échoué différemment, coûteux. L'API de Contentful a étranglé un lancement produit à 6 du matin un mardi. La courbe d'apprentissage GROQ de Sanity a bloqué une équipe marketing pendant deux sprints. La facture d'auto-hébergement de Payload a surpris un fondateur en stage qui pensait que « open source » signifiait « gratuit ». Un choix a constamment causé moins de pings Slack à 2 du matin que les autres.

Cet article décompose Contentful, Sanity et Payload sur les dimensions qui importent vraiment quand vous construisez quelque chose de réel : tarification à l'échelle, expérience développeur dans les tranchées, flexibilité de la modélisation de contenu, conception d'API et le flux de travail éditorial quotidien que votre équipe de contenu aimera ou détestera.

Table des matières

Contentful vs Sanity vs Payload: Comparaison Headless CMS 2026

Vue d'ensemble en 30 secondes

Contentful est le sortant. Il existe depuis 2013 et alimente les sites d'entreprise à grande échelle. C'est poli, fiable et cher.

Sanity est le favori des développeurs avec son approche de contenu en temps réel, structurée et son studio personnalisable. C'est puissant mais il y a une courbe d'apprentissage et un modèle de tarification qui peut vous surprendre.

Payload est l'outsider qui s'est discrètement transformé en concurrent sérieux. C'est open-source, auto-hébergé par défaut (avec une option cloud maintenant), écrit en TypeScript, et facture zéro frais de licence. Payload 3.0 est arrivé avec une réécriture complète sur Next.js, et cela a entièrement changé l'équation.

Fonctionnalité Contentful Sanity Payload
Type SaaS SaaS (auto-hébergement du studio) Open Source / Auto-hébergé
Langage N/A (API uniquement) JavaScript/React TypeScript/Next.js
Frais de licence Oui Oui (basé sur l'utilisation) Aucun (MIT)
GraphQL Oui Oui (GROQ préféré) Oui (auto-généré)
API REST Oui Oui Oui (auto-généré)
Collaboration en temps réel Limitée Excellente Bonne (2.0+)
Auto-hébergement Non Studio uniquement Stack complet
Base de données Propriétaire Propriétaire MongoDB ou Postgres

Décomposition des tarifs : Ce que vous paierez réellement

C'est ici que les choses deviennent réelles. La tarification est la raison numéro un pour laquelle j'ai vu des équipes changer de CMS en milieu de projet, et c'est la première chose que les gens sous-estiment pendant l'évaluation.

Tarification de Contentful (2026)

Le niveau gratuit de Contentful vous donne 1 espace, 5 utilisateurs et 25K appels d'API. C'est bien pour un blog.

Le plan Basic commence à 300 $/mois et vous donne plus d'environnements et de rôles. Le plan Premium — ce dont la plupart des équipes sérieuses ont besoin — a un prix personnalisé mais commence généralement autour de 2 000-3 000 $/mois pour les organisations de taille moyenne. J'ai vu des contrats d'entreprise dépasser 80 K $/an.

L'astuce : les dépassements d'appels d'API. Contentful facture les appels Content Delivery API, Content Management API et la bande passante des actifs séparément. Sur un site à fort trafic avec 10M+ pages vues/mois, vous pouvez facilement dépasser les quotas inclus. Un client avec lequel j'ai travaillé a vu sa facture mensuelle passer de 2 500 $ à 4 800 $ après un lancement de produit viral en raison des dépassements de CDN et d'API qu'il n'avait pas anticipés.

Tarification de Sanity (2026)

Sanity utilise un modèle basé sur l'utilisation qu'ils appellent « pay as you grow ». Le plan Free inclut 3 utilisateurs non-administrateurs, 500K demandes d'API, 20 Go de bande passante et 10 Go de stockage. Généreux pour commencer.

Le plan Growth est 15 $/utilisateur/mois plus les dépassements d'utilisation. Le plan Enterprise a un prix personnalisé.

Voici ce qui mord avec la tarification de Sanity : les requêtes GROQ et les demandes d'API CDN sont mesurées, et les coûts évoluent avec la complexité de votre contenu. Une seule requête GROQ qui récupère du contenu profondément imbriqué et référencé peut consommer plus de votre quota que prévu. Sanity a amélioré la transparence ici, mais je recommande toujours aux équipes de configurer des alertes budgétaires tôt.

Coût type du projet de taille moyenne : 200-800 $/mois selon la taille de l'équipe et le trafic.

Tarification de Payload (2026)

Payload est sous licence MIT. Le CMS lui-même coûte 0 $. Toujours. Il n'y a pas de frais par siège, pas de mesure des appels d'API, pas de charges de bande passante de Payload.

Vos coûts sont infrastructure : héberger une app Node.js et une base de données. Sur un service comme Railway, Render ou une configuration AWS/DigitalOcean basique, vous regardez 20-100 $/mois pour la plupart des projets. Même un déploiement à grande échelle avec Postgres géré sur AWS RDS, une configuration EC2 ou ECS correctement dimensionnée et CloudFront devant dépasse rarement 300-500 $/mois — et c'est pour un trafic sérieux.

Payload Cloud (leur offre hébergée) commence à 50 $/mois avec des plans évoluant en fonction du stockage et de la bande passante, mais c'est entièrement optionnel.

Scénario Contentful Sanity Payload (auto-hébergé)
Développeur solo, petit site 0 $ (niveau gratuit) 0 $ (niveau gratuit) 20-40 $/mo (hébergement)
Équipe de 5 personnes, trafic moyen 300-500 $/mo 200-400 $/mo 50-100 $/mo (hébergement)
Équipe de 10 personnes, fort trafic 2 000-4 000 $/mo 500-1 500 $/mo 150-400 $/mo (hébergement)
Entreprise, 50+ éditeurs 5 000-10 000+ $/mo 2 000-5 000 $/mo 300-800 $/mo (hébergement)

L'histoire de la tarification est sans ambiguïté. Payload gagne à tous les niveaux.

Expérience développeur

La tarification fait entrer les gens par la porte. L'expérience développeur les y maintient — ou les éloigne.

DX de Contentful

L'expérience développeur de Contentful est... correcte. Leur support SDK est large (JavaScript, Python, Ruby, Java, Swift, etc.), la documentation est mature et les API REST et GraphQL sont bien documentées.

Mais voici ce qui me frustre : tout est configuré via l'interface Web. Types de contenu, champs, validations — c'est tout clic-clic-clic dans le navigateur. Oui, vous pouvez utiliser la CLI Contentful et les scripts de migration pour versionnez votre schéma, mais cela semble étroitement couplé. Ce n'est pas code-first ; c'est UI-first avec une échappatoire de code.

L'outillage de migration s'est amélioré avec leur paquet contentful-migration, mais comparé à définir votre schéma en TypeScript et obtenir la sécurité des types instantanée ? Cela semble d'une génération en retard.

DX de Sanity

L'expérience développeur de Sanity est véritablement excellente à bien des égards. Le schéma est défini dans les fichiers JavaScript/TypeScript. Le studio est une app React que vous pouvez étendre considérablement — composants d'entrée personnalisés, vues personnalisées, plugins de flux de travail.

GROQ, leur langage de requête, est puissant une fois que vous l'apprenez. Mais « une fois que vous l'apprenez » en dit beaucoup dans cette phrase. GROQ n'est pas SQL. Ce n'est pas GraphQL. C'est sa propre chose, et chaque nouveau développeur de votre équipe doit l'apprendre. J'ai vu des développeurs juniors lutter avec les projections GROQ pendant des semaines.

// Requête GROQ - puissante mais syntaxe unique
*[_type == "post" && publishedAt < now()] | order(publishedAt desc) [0...10] {
  title,
  slug,
  "author": author->{ name, image },
  "categories": categories[]->{ title, slug },
  body[] {
    ...,
    _type == "image" => {
      "url": asset->url
    }
  }
}

Les fonctionnalités en temps réel de Sanity sont incroyables cependant. Plusieurs éditeurs travaillant sur le même document avec des indicateurs de présence et sans conflits d'enregistrement — cela fonctionne tout simplement. L'architecture du contenu lake le permet de manière que les concurrents ne peuvent pas égaler.

DX de Payload

Payload 3.0 a tout changé. Construit sur Next.js, entièrement écrit en TypeScript, avec votre fichier de configuration comme source unique de vérité. Vous définissez les collections, les champs, les hooks, le contrôle d'accès et les points de terminaison personnalisés tout en code.

Voici ce qu'une collection Payload typique ressemble :

import { CollectionConfig } from 'payload'

export const Posts: CollectionConfig = {
  slug: 'posts',
  admin: {
    useAsTitle: 'title',
    defaultColumns: ['title', 'status', 'publishedAt'],
  },
  access: {
    read: () => true,
    create: ({ req: { user } }) => Boolean(user),
    update: ({ req: { user } }) => Boolean(user),
    delete: ({ req: { user } }) => user?.role === 'admin',
  },
  fields: [
    {
      name: 'title',
      type: 'text',
      required: true,
    },
    {
      name: 'content',
      type: 'richText',
    },
    {
      name: 'author',
      type: 'relationship',
      relationTo: 'users',
    },
    {
      name: 'status',
      type: 'select',
      options: ['draft', 'published'],
      defaultValue: 'draft',
    },
    {
      name: 'publishedAt',
      type: 'date',
      admin: {
        position: 'sidebar',
      },
    },
  ],
  hooks: {
    beforeChange: [
      ({ data, operation }) => {
        if (operation === 'create') {
          data.publishedAt = new Date()
        }
        return data
      },
    ],
  },
}

Tout est typé. Votre IDE complète automatiquement les noms de champs. Les hooks vous donnent un contrôle du cycle de vie. Le contrôle d'accès est défini comme des fonctions juste à côté de vos champs, pas dans une interface utilisateur de permissions séparée. Et comme c'est juste une app Next.js, vous pouvez ajouter des pages personnalisées, des routes d'API ou des actions serveur à côté de votre code CMS.

Pour les équipes faisant du développement Next.js, Payload 3.0 est une évidence du point de vue DX. Votre CMS et votre frontend vivent dans le même projet. Même déploiement. Même repo.

Contentful vs Sanity vs Payload: Comparaison Headless CMS 2026 - architecture

Modélisation de contenu

La modélisation de contenu est où vous vous préparez au succès ou où vous créez un cauchemar avec lequel vous vivrez pendant des années.

Approche de Contentful

Contentful utilise un modèle traditionnel type de contenu → entrée. Vous définissez les types de contenu avec des champs, et les éditeurs créent des entrées. Les références entre les types de contenu sont explicites. Cela fonctionne bien pour les structures de contenu simples.

Les limitations apparaissent avec le texte enrichi. Le champ de texte enrichi de Contentful stocke le contenu sous forme d'arborescence JSON structurée, ce qui est excellent pour la flexibilité de rendu, mais la modélisation de mises en page de page complexes avec des composants imbriqués nécessite une utilisation créative d'entrées intégrées et de références. Cela peut devenir maladroit.

Contentful supporte 50 types de contenu sur le plan Basic et 100+ sur Premium. Pour les grands sites avec de nombreux types de contenu, cela peut devenir une contrainte.

Approche de Sanity

La modélisation de contenu de Sanity est sans doute la plus flexible des trois. Leur contenu en bloc (Portable Text) est une spécification ouverte pour le texte enrichi qui stocke le contenu comme des données structurées. Vous pouvez définir des types de bloc personnalisés, des objets en ligne et des annotations.

Le système de schéma supporte les types d'objets profondément imbriqués, les champs conditionnels et la validation personnalisée. J'ai construit des modèles de contenu véritablement complexes dans Sanity qui seraient douloureux dans Contentful.

// Schéma Sanity avec personnalisation Portable Text
export default {
  name: 'post',
  type: 'document',
  fields: [
    {
      name: 'body',
      type: 'array',
      of: [
        { type: 'block',
          marks: {
            annotations: [
              { name: 'internalLink', type: 'object',
                fields: [{ name: 'reference', type: 'reference', to: [{ type: 'post' }] }]
              }
            ]
          }
        },
        { type: 'image', options: { hotspot: true } },
        { type: 'codeBlock' },
        { type: 'callout' },
      ]
    }
  ]
}

Approche de Payload

La modélisation de contenu de Payload se situe quelque part entre la simplicité structurée de Contentful et la flexibilité informe de Sanity — mais avec l'avantage d'être entièrement en TypeScript.

Le champ blocks de Payload est particulièrement puissant pour la construction de pages. Vous définissez les types de bloc, chacun avec ses propres champs, et les éditeurs peuvent composer des pages à partir de ces blocs. Combiné avec le type de champ layout et la logique conditionnelle, vous pouvez modéliser presque n'importe quoi.

L'éditeur de texte enrichi Lexical 3.0 de Payload mérite mention. Il a remplacé Slate (qui était correct mais vieillissant) par un éditeur moderne qui supporte les nœuds personnalisés, les blocs en ligne et le rendu côté serveur prêt à l'emploi. Vous pouvez intégrer directement les composants React dans le contenu de texte enrichi.

Le système de versioning mérite aussi mention. Payload vous donne les flux de travail brouillon/publication et l'historique complet des versions du document avec diffing. C'est intégré, pas un add-on payant.

API : REST, GraphQL et tout le reste

API de Contentful

Contentful offre des API séparées pour la livraison (CDN en cache, lecture seule), l'aperçu (non en cache, contenu brouillon), la gestion (CRUD) et les images. La séparation est sensée mais signifie que vous jongler avec plusieurs jetons d'API et URL de base.

Leur API GraphQL est solide mais a des limitations de profondeur et des limites de débit qui peuvent être frustrantes lors de la modélisation de contenu profondément référencé. Les requêtes complexes peuvent nécessiter plusieurs allers-retours.

API de Sanity

Le langage de requête principal de Sanity est GROQ, servi sur HTTP. Ils offrent une API GraphQL, mais elle est déployée séparément et semble comme une deuxième classe. GROQ est plus puissant pour la plupart des cas d'utilisation de Sanity de toute façon.

La magie réelle est l'API d'écoute en temps réel de Sanity. Vous pouvez vous abonner aux changements sur n'importe quelle requête et obtenir les mises à jour instantanément. Cela permet des expériences d'aperçu en direct qui sont véritablement impressionnantes.

API de Payload

Payload auto-génère les API REST et GraphQL à partir de vos configs de collection. Aucune configuration supplémentaire. Définissez une collection, obtenez des points de terminaison CRUD complets pour REST et GraphQL instantanément.

# Requête GraphQL auto-générée
query {
  Posts(where: { status: { equals: published } }, sort: "-publishedAt", limit: 10) {
    docs {
      id
      title
      content
      author {
        name
      }
      publishedAt
    }
    totalDocs
    hasNextPage
  }
}

Mais voici où Payload a un avantage unique : parce qu'il s'exécute dans le même processus que votre app Next.js, vous pouvez ignorer l'API entièrement et utiliser l'API locale de Payload pour la récupération de données côté serveur. Requêtes directes à la base de données avec le même contrôle d'accès, hooks et validation — mais avec zéro surcharge HTTP.

// API local - pas de HTTP, pas de surcharge de sérialisation
const posts = await payload.find({
  collection: 'posts',
  where: { status: { equals: 'published' } },
  sort: '-publishedAt',
  limit: 10,
})

C'est une énorme victoire de performance pour les pages rendues côté serveur. Pas d'aller-retour réseau vers une API CMS. Juste un appel de fonction.

Expérience éditoriale

Les développeurs choisissent le CMS, mais les éditeurs y vivent quotidiennement. Ignorez leur expérience à vos risques et périls.

Contentful a l'interface utilisateur éditoriale la plus mature. C'est propre, prévisible et votre équipe non-technique la comprendra rapidement. La planification, les flux de travail et les chaînes d'approbation du plan Premium sont solides. Cependant, cela peut sembler rigide — personnaliser l'interface éditoriale nécessite de construire une Contentful App, qui est une app React entièrement séparée.

Sanity Studio est le plus personnalisable. Vous pouvez construire des expériences d'édition entièrement bespoke. Mais cette personnalisation a un coût : prête à l'emploi, Sanity Studio peut sembler accablante pour les éditeurs non-techniques. Le générateur de structure nécessite du temps de développeur pour être bien configuré.

Le panneau d'administration de Payload s'est amélioré dramatiquement dans 3.0. C'est propre, rapide (c'est une app Next.js) et supporte les composants personnalisés, le rendu des champs conditionnels et l'aperçu en direct. Ce n'est pas aussi poli que l'interface utilisateur de Contentful, mais c'est plus personnalisable avec moins d'effort que Contentful et plus abordable prête à l'emploi que Sanity.

Auto-hébergement vs SaaS : Les vrais compromis

C'est la division philosophique. Contentful et Sanity sont des plateformes SaaS. Vous ne gérez pas l'infrastructure ; vous les payez pour le faire. Payload est auto-hébergé par défaut.

L'argument SaaS : moins de surcharge ops, CDN intégré, uptime géré. Ce sont des avantages réels, surtout pour les petites équipes sans expérience DevOps.

L'argument auto-hébergé : propriété des données, pas de dépendance aux fournisseurs, coûts prévisibles, conformité réglementaire (RGPD, HIPAA, résidence des données) et liberté de personnaliser n'importe quoi.

Pour les agences comme la nôtre faisant du développement headless CMS, l'auto-hébergement est devenu la recommandation pour la plupart des clients en 2026. L'outillage d'infrastructure a mûri au point où déployer une app Payload sur Railway, Vercel ou AWS est simple. Docker le rend reproductible. Et les économies de coûts sur un CMS SaaS se composent année après année.

Si vous êtes préoccupé par la charge ops, Payload Cloud gère l'hébergement pour vous tout en conservant les avantages open-source.

Performance et scalabilité

L'API de livraison soutenue par CDN de Contentful est rapide. Les temps de réponse typiques sont 50-100ms depuis les nœuds périphériques. C'est été testé en bataille à grande échelle pendant une décennie.

L'API CDN de Sanity livère une performance similaire pour le contenu en cache, avec sa couche en temps réel ajoutant peut-être 20-30ms pour les requêtes en direct.

La performance de Payload dépend de votre infrastructure, mais voici le truc — quand vous utilisez l'API local avec les composants serveur Next.js, vous faites un appel de fonction à une base de données locale. Les temps de réponse peuvent être sous 10ms. Ajoutez un CDN devant votre sortie Next.js (Vercel, CloudFront, etc.) et vous égalez ou battez les options SaaS.

Pour les projets basés sur Astro, les trois fonctionnent bien comme sources d'API, mais les API REST et GraphQL de Payload sont particulièrement simples à consommer dans la couche de récupération de données d'Astro.

Écosystème et communauté

Contentful a le plus grand écosystème d'entreprise. Tonnes d'intégrations, une place de marché d'apps et un large support d'agences.

Sanity a une communauté de développeurs passionnée, une excellente documentation et un écosystème de plugins en croissance. Leur Slack communautaire est véritablement utile.

Payload a la communauté qui grandit le plus vite des trois. Leur Discord est extrêmement actif, avec l'équipe principale répondant aux questions régulièrement. L'écosystème de plugins est plus petit mais grandit rapidement — et comme Payload est juste Node.js/TypeScript, vous pouvez npm install n'importe quoi dont vous avez besoin.

Le GitHub de Payload compte plus de 30K stars au début de 2026 et la trajectoire est abrupte.

Le verdict

Je serai direct : Payload est le meilleur headless CMS pour la plupart des projets en 2026.

Voici pourquoi :

  1. Zéro frais de licence à n'importe quelle échelle. Votre équipe d'entreprise de 50 éditeurs ne paie pas Payload un centime.
  2. Config TypeScript-native signifie que votre modèle de contenu est du code, versionné, type-safe et examinable dans les PRs.
  3. Intégration API locale + Next.js vous donne une performance que les CMS SaaS ne peuvent physiquement pas égaler.
  4. Propriété des données — votre contenu vit dans votre base de données, pas dans un magasin propriétaire de quelqu'un d'autre.
  5. Pas de dépendance aux fournisseurs — si vous voulez changer, vos données sont dans Postgres ou MongoDB. Interrogez-les simplement.

Il y a des scénarios où les autres gagnent :

  • Choisissez Contentful si vous êtes une grande entreprise avec une équipe de contenu établie qui a besoin d'une expérience éditoriale polie, zéro-ops et a le budget.
  • Choisissez Sanity si la collaboration en temps réel est critique pour votre flux de travail, vous avez besoin du texte enrichi structuré incomparable de Portable Text, ou vous construisez une expérience de studio hautement personnalisée.
  • Choisissez Payload pour tout le reste. Startups, agences, entreprises de taille moyenne, équipes menées par les développeurs, industries réglementées ayant besoin du contrôle des données et quiconque ne veut pas se réveiller à une facture surprise.

Si vous évaluez un headless CMS pour un nouveau projet et voulez discuter des détails, nous sommes heureux de vous aider. Nous avons déployé des projets Payload, Sanity et Contentful en production et pouvons vous donner des conseils honnêtes en fonction de vos besoins réels et de votre budget.

FAQ

Payload CMS est-il vraiment gratuit ?

Oui. Payload est un logiciel open-source sous licence MIT. Il n'y a pas de frais de licence, pas de charges par utilisateur et pas de limites d'appels d'API de Payload lui-même. Vos seuls coûts sont l'infrastructure d'hébergement (serveur et base de données), qui s'exécute généralement 20-500 $/mois selon l'échelle. Payload Cloud est disponible comme option hébergée payante si vous préférez ne pas gérer l'infrastructure.

Sanity peut-il être auto-hébergé ?

Partiellement. Sanity Studio (l'interface utilisateur d'administration) est une app React que vous pouvez déployer n'importe où. Cependant, le lac de contenu — où vos données réelles vivent — est un service hébergé géré par Sanity. Vous ne pouvez pas auto-héberger la couche de données. Cela signifie que votre contenu vit toujours sur l'infrastructure de Sanity, ce qui peut être une préoccupation pour la résidence des données ou les exigences de conformité.

Quel headless CMS a le meilleur support GraphQL ?

Contentful et Payload offrent tous deux des API GraphQL solides. Payload auto-génère son schéma GraphQL directement à partir de vos configs de collection, ce qui signifie zéro maintenance manuelle du schéma. L'API GraphQL de Contentful est mature et bien documentée. Sanity offre GraphQL mais préfère GROQ comme son langage de requête principal, et leur implémentation GraphQL ne supporte pas toutes les fonctionnalités GROQ.

Contentful vaut-il la peine en 2026 ?

Pour les grandes entreprises avec des opérations de contenu complexes, des flux de travail Contentful existants et des équipes qui valorisent une approche SaaS mains libres — oui, cela peut en valoir la peine. Pour les petites équipes de taille moyenne, le coût devient de plus en plus difficile à justifier quand Payload offre une fonctionnalité comparable (et à certains égards supérieure) à une fraction du prix. Nous avons vu plusieurs clients migrer loin de Contentful spécifiquement en raison du coût.

Comment Payload CMS gère-t-il l'optimisation d'image ?

Payload a une redimensionnement d'image intégré et un recadrage de point focal. Quand vous téléchargez une image, Payload peut générer automatiquement plusieurs tailles en fonction de votre config. Dans Payload 3.0 avec Next.js, vous pouvez combiner cela avec l'optimisation d'image Next.js pour la livraison réactive, WebP/AVIF. Ce n'est pas aussi complet que l'API d'image de Contentful (qui offre des transformations basées sur l'URL), mais cela couvre 90% des cas d'utilisation sans service tiers.

Puis-je migrer de Contentful vers Payload ?

Oui. Puisque Payload utilise des bases de données standard (Postgres ou MongoDB), la migration implique d'exporter votre contenu Contentful via leur Management API et de l'importer dans les collections Payload. La traduction de modélisation de contenu des types de contenu Contentful aux collections Payload est généralement directe. Nous avons géré plusieurs de ces migrations — la partie la plus délicate est généralement la conversion de texte enrichi, pas les données structurées.

Quel CMS est le meilleur pour les éditeurs non-techniques ?

Contentful a l'expérience éditoriale la plus intuitive prête à l'emploi pour les utilisateurs non-techniques. Le panneau d'administration de Payload est un deuxième rapproché et s'améliore rapidement. Sanity Studio peut être le meilleur des trois si un développeur investit du temps pour le personnaliser, mais l'expérience par défaut a une courbe d'apprentissage plus abrupte pour les éditeurs.

Payload CMS fonctionne-t-il avec des cadres autres que Next.js ?

Absolutement. Bien que Payload 3.0 utilise Next.js comme cadre d'interface utilisateur d'administration, les API REST et GraphQL fonctionnent avec n'importe quel frontend — Astro, Nuxt, SvelteKit, Remix ou même les apps mobiles. L'API local est spécifique à Next.js, mais les API externes n'ont pas de dépendances de cadre. Nous associons régulièrement Payload à Next.js et Astro selon les besoins du projet.