J'ai construit des projets en production avec ces trois CMS au cours des quatre dernières années. Certains étaient des développements à partir de zéro, d'autres des migrations depuis WordPress ou des systèmes hérités qui s'effondraient. Chaque fois qu'un client me demande « quel CMS headless devrions-nous utiliser ? », je résiste à donner une réponse unique — mais après avoir livré des douzaines de projets en 2025 et 2026, j'ai des opinions fortes basées sur des cicatrices réelles.

Cet article décompose Contentful, Sanity et Payload CMS selon les dimensions qui comptent vraiment lorsque vous construisez quelque chose de réel : la tarification à grande échelle, l'expérience développeur au combat, la flexibilité de la modélisation du contenu, la conception de l'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: Headless CMS Comparison 2026

L'aperçu 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 chouchou des développeurs avec son approche du contenu structuré en temps réel et son studio personnalisable. C'est puissant mais présente une courbe d'apprentissage et un modèle de tarification qui peut vous surprendre.

Payload est le nouveau venu qui est devenu discrètement un concurrent sérieux. C'est open-source, auto-hébergé par défaut (avec une option cloud maintenant), écrit en TypeScript, et ne facture zéro frais de licence. En 2025, Payload 3.0 a été lancé avec une réécriture complète basée sur Next.js, et cela a complètement changé la donne.

Fonctionnalité Contentful Sanity Payload
Type SaaS SaaS (auto-hébergement du studio) Open Source / Auto-hébergé
Langue N/A (API uniquement) JavaScript/React TypeScript/Next.js
Frais de licence Oui Oui (basée 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

Ventilation des tarifs : ce que vous allez vraiment payer

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

Tarification Contentful (2026)

Le niveau gratuit de Contentful vous donne 1 espace, 5 utilisateurs et 25K appels 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 — qui est 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 000 $/an.

Le problème : les dépassements d'appels API. Contentful facture les appels Content Delivery API, Content Management API et la bande passante des ressources séparément. Sur un site à fort trafic effectuant 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 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 requêtes API, 20GB de bande passante et 10GB 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 les gens dans la tarification Sanity : les requêtes GROQ et les requêtes CDN API sont mesurées, et les coûts augmentent 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 typique d'un projet de taille moyenne : 200-800 $/mois selon la taille de l'équipe et le trafic.

Tarification Payload (2026)

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

Vos coûts sont l'infrastructure : héberger une application Node.js et une base de données. Sur un service comme Railway, Render ou une configuration AWS/DigitalOcean basique, vous cherchez à 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 rarement dépasse 300-500 $/mois — et c'est pour un trafic sérieux.

Payload Cloud (leur offre hébergée) commence à 50 $/mois avec des plans variant selon le stockage et 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, trafic élevé 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 équivoque. Payload gagne à chaque niveau.

Expérience développeur

La tarification attire les gens. L'expérience développeur les y garde — ou les en chasse.

Expérience développeur 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 APIs REST et GraphQL sont bien documentées.

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

L'outillage de migration s'est amélioré avec leur paquet contentful-migration, mais par rapport à la définition de votre schéma en TypeScript et l'obtention de sécurité de type instantanée ? Cela semble d'une génération en retard.

Expérience développeur 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 application React que vous pouvez personnaliser largement — 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 » fait beaucoup de travail lourd 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 se débattre 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 cependant incroyables. Plusieurs éditeurs travaillant sur le même document avec des indicateurs de présence et aucun conflit d'enregistrement — cela fonctionne simplement. L'architecture du lac de contenu l'active de manière que les concurrents ne peuvent pas égaler.

Expérience développeur Payload

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

Voici à quoi ressemble une collection Payload typique :

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 sous forme de fonctions directement à côté de vos champs, pas dans une interface utilisateur de permissions séparée. Et parce que c'est juste une application Next.js, vous pouvez ajouter des pages personnalisées, des routes API ou des actions serveur à côté de votre code CMS.

Pour les équipes faisant du développement Next.js, Payload 3.0 est un jeu d'enfant du point de vue DX. Votre CMS et votre frontend vivent dans le même projet. Même déploiement. Même dépôt.

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

Modélisation du contenu

La modélisation du contenu est où vous vous configurez pour le succès ou 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'arbre JSON structuré, 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 lourd.

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 du contenu de Sanity est probablement la plus flexible des trois. Leur contenu de bloc (Portable Text) est une spécification ouverte pour le texte enrichi qui stocke le contenu sous forme de 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 certains modèles de contenu vraiment 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 du contenu de Payload se situe quelque part entre la simplicité structurée de Contentful et la flexibilité informelle 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 des types de bloc, chacun avec ses propres champs, et les éditeurs peuvent composer des pages à partir de ces blocs. Combiné avec le champ layout et la logique conditionnelle, vous pouvez modéliser presque n'importe quoi.

Le éditeur de texte enrichi Lexical de Payload 3.0 est un point fort. 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 les composants React directement dans le contenu de texte enrichi.

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

APIs : REST, GraphQL et tout ce qui se trouve entre

APIs Contentful

Contentful offre des APIs 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 jonglent avec plusieurs jetons 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.

APIs Sanity

Le langage de requête principal de Sanity est GROQ, fourni via HTTP. Ils offrent une API GraphQL, mais elle est déployée séparément et semble être un citoyen de second ordre. GROQ est plus puissant pour la plupart des cas d'utilisation Sanity de toute façon.

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

APIs Payload

Payload auto-génère les APIs REST et GraphQL à partir de vos configs de collection. Pas de configuration supplémentaire. Définissez une collection, obtenez des endpoints 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 application Next.js, vous pouvez ignorer l'API entièrement et utiliser l'API Local de Payload pour la récupération de données côté serveur. Requêtes directes de base de données avec le même contrôle d'accès, hooks et validation — mais sans frais HTTP.

// API Local - pas HTTP, pas frais 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 par le 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 à votre péril.

Contentful a l'interface utilisateur éditoriale la plus mature. C'est propre, prévisible, et votre équipe non technique le maîtrisera 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 application Contentful, ce qui est une application React entièrement séparée.

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

Le panneau d'administration Payload s'est amélioré de façon spectaculaire en 3.0. C'est propre, rapide (c'est une application Next.js), et supporte les composants personnalisés, le rendu conditionnel des champs 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 accessible prêt à l'emploi que Sanity.

Auto-hébergement vs SaaS : les vrais compromis

C'est le fossé philosophique. Contentful et Sanity sont des plates-formes 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 frais généraux d'ops, CDN intégré, disponibilité gérée. Ce sont des avantages réels, en particulier pour les petites équipes sans expérience DevOps.

L'argument auto-hébergé : propriété des données, pas de verrouillage des 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 CMS headless, l'auto-hébergement est devenu la recommandation pour la plupart des clients en 2026. Les outils d'infrastructure se sont suffisamment mûrs pour que le déploiement d'une application Payload sur Railway, Vercel ou AWS soit 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 d'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. Cela a été testé au combat à l'échelle pendant une décennie.

L'API CDN de Sanity offre des performances similaires 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 la chose — 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 API, mais les APIs 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. Tons d'intégrations, une marketplace d'applications et un support agence généralisé.

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

Payload a la communauté à la croissance la plus rapide des trois. Leur Discord est extrêmement actif, avec l'équipe principale répondant régulièrement aux questions. L'écosystème des plugins est plus petit mais croît rapidement — et parce que Payload est juste Node.js/TypeScript, vous pouvez npm installer n'importe quoi dont vous avez besoin.

Le GitHub de Payload a plus de 30K étoiles depuis le début de 2026 et la trajectoire est raide.

Le verdict

Je serai direct : Payload est le meilleur CMS headless 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 sou.
  2. Configuration TypeScript-native signifie que votre modèle de contenu est du code, contrôlé en version, type-safe et révisable dans les PR.
  3. Intégration API Local + Next.js vous donne des performances 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 une boutique propriétaire de quelqu'un d'autre.
  5. Pas de verrouillage des fournisseurs — si vous voulez vous éloigner, 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 poli et zéro-ops et qui 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 du marché intermédiaire, équipes menées par des développeurs, industries réglementées ayant besoin de contrôle des données, et quiconque ne veut pas se réveiller avec une facture surprise.

Si vous évaluez un CMS headless pour un nouveau projet et souhaitez discuter des spécificités, nous sommes heureux de vous aider. Nous avons livré des projets production Payload, Sanity et Contentful et pouvons vous donner des conseils honnêtes basés sur vos exigences réelles et 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 frais par utilisateur et pas de limites d'appels API de Payload. 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 en tant qu'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 application 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 CMS headless a le meilleur support GraphQL ?

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

Contentful vaut-il le prix en 2026 ?

Pour les grandes entreprises avec des opérations de contenu complexes, les flux de travail Contentful existants et les équipes qui valorisent une approche SaaS sans intervention — oui, cela peut en valoir la peine. Pour les petites et moyennes équipes, le coût est de plus en plus difficile à justifier quand Payload offre des fonctionnalités comparables (et à certains égards supérieures) à une fraction du prix. Nous avons vu plusieurs clients migrer loin de Contentful précisément en raison du coût.

Comment Payload CMS gère-t-il l'optimisation des images ?

Payload a un redimensionnement d'image et un recadrage de point focal intégrés. Quand vous téléchargez une image, Payload peut générer automatiquement plusieurs tailles basées sur votre config. Dans Payload 3.0 avec Next.js, vous pouvez combiner cela avec l'optimisation d'image Next.js pour la livraison WebP/AVIF réactive. Ce n'est pas aussi riche en fonctionnalités que l'API d'image de Contentful (qui offre les transformations basées sur URL), mais elle couvre 90% des cas d'utilisation sans un 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 simple. 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 prêt à l'emploi la plus intuitive pour les utilisateurs non techniques. Le panneau d'administration de Payload est un proche second 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 raide pour les éditeurs.

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

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