Payload vs Strapi en 2026 : notre choix après avoir mis les deux en prod

Aucun de ces deux outils n'est universellement meilleur. On a mis les deux en prod sur des typologies de projets différents, et la conclusion est plus nuancée que ce que les comparatifs habituels laissent entendre.

Le point de départ

On utilise Strapi depuis la version 3. On a adopté Payload au lancement de la version 3 stable, début 2025. Les projets Strapi en prod sont des applications B2B avec des équipes éditoriales internes. Les projets Payload sont principalement des sites marketing, des espaces clients et des back-offices custom sur stack TypeScript.

Architecture et modèle de données

Strapi suit une approche REST-first. Vous définissez vos content types via une interface graphique ou en JSON, et Strapi génère les routes REST et GraphQL automatiquement. C'est accessible à des profils non-dev pour des ajustements mineurs.

Payload exige que tout soit décrit en TypeScript. Il n'y a pas d'interface graphique pour définir les collections, c'est du code, uniquement du code.

// Payload : collection définie en TypeScript
export const Articles: CollectionConfig = {
  slug: 'articles',
  admin: { useAsTitle: 'title' },
  fields: [
    { name: 'title', type: 'text', required: true },
    { name: 'slug', type: 'text', unique: true },
    { name: 'content', type: 'richText' },
    {
      name: 'author',
      type: 'relationship',
      relationTo: 'users',
    },
  ],
};

Strapi propose l'équivalent via un JSON généré par l'interface, ce qui est pratique pour démarrer mais crée un décalage entre ce que voient les devs et ce que fait réellement l'application.

Pour une équipe full TypeScript, Payload est structurellement plus cohérent. Pour une équipe mixte avec des profils non-dev qui ajustent le modèle, Strapi reste plus accessible.

DX et typage

C'est là que l'écart est le plus net.

Strapi génère des types TypeScript depuis la v4, mais leur précision est variable et dépend de la configuration. Les types générés sont parfois trop permissifs et ne couvrent pas les relations profondes.

Payload génère des types exacts depuis payload-types.ts. Le type d'une collection correspond exactement à son schéma, relations comprises. Sur un projet avec 30 collections interconnectées, c'est une différence concrète : les erreurs de typage bloquent à la compilation, pas en prod.

# Régénérer les types Payload après modification d'une collection
npx payload generate:types

Permissions et access control

Les deux outils ont un système de permissions. L'approche est différente.

Strapi utilise des rôles avec des permissions configurées dans l'admin, par collection et par action (create, read, update, delete, publish). Simple pour des cas standard, limité pour des règles fines.

Payload implémente l'access control sous forme de fonctions :

// Access control Payload : logique custom possible
access: {
  read: ({ req: { user } }) => {
    if (!user) return false;
    if (user.role === 'admin') return true;
    // Les utilisateurs ne voient que leurs propres documents
    return {
      author: { equals: user.id },
    };
  },
},

Cette approche permet des règles au niveau des champs individuels, des row-level conditions dynamiques, et des permissions qui dépendent de l'état du document. Strapi nécessite des plugins ou du code custom pour arriver au même niveau.

Pour des cas simples, Strapi est plus rapide à configurer. Pour des exigences de sécurité précises ou une architecture multi-tenant, Payload offre un contrôle qu'on ne peut pas atteindre avec l'interface Strapi.

Performance et infrastructure

Strapi est une API REST/GraphQL séparée du front. Il faut gérer deux déploiements, deux process, et les appels HTTP entre les deux.

Payload 3 colocalisé avec Next.js évite ces appels HTTP pour les Server Components. Sur un projet où le CMS alimente un site Next.js, le gain est direct et mesurable, entre 40 et 150 ms selon la complexité des requêtes et la latence réseau interne.

En revanche, Strapi peut être déployé indépendamment et scalé séparément du front. Pour des architectures où le CMS alimente plusieurs fronts (web, mobile, partenaires), cette séparation est un avantage.

Maturité et écosystème

Strapi a sept ans. Son écosystème de plugins est large, sa communauté est importante, sa documentation est stable. Les breaking changes entre les versions majeures ont été douloureux (v3 vers v4, v4 vers v5), mais chaque version stable est bien documentée.

Payload 3 est jeune. La documentation est incomplète sur certains aspects avancés, notamment les plugins et les hooks complexes. Les versions mineures contiennent parfois des breaking changes non signalés comme tels dans le changelog. On épingle toujours la version exacte.

Coût d'exploitation

Les deux sont open source et auto-hébergeables. La différence est dans la complexité opérationnelle.

Strapi seul nécessite : un serveur Node.js, une base de données, éventuellement un serveur de médias. Pour du cloud managé, Strapi Cloud existe mais est payant.

Payload dans Next.js peut tourner sur Vercel, Railway, ou n'importe quelle plateforme qui supporte Next.js. Une seule instance, un seul déploiement. Pour des projets de taille moyenne, c'est un avantage en coût et en complexité opérationnelle.

Notre règle de décision

Aujourd'hui, on choisit en fonction de trois critères :

Type de stack. Stack TypeScript Next.js ? Payload sans hésitation. Stack découpée avec plusieurs consommateurs ? Strapi reste pertinent.

Complexité des permissions. Règles simples par rôle ? Strapi suffit. Row-level security, permissions par champ, conditions dynamiques ? Payload.

Maturité de l'équipe éditoriale. Des développeurs TypeScript qui gèrent le contenu ? Payload. Une équipe éditoriale non-technique qui doit modifier le modèle de données sans dev ? Strapi.

Le cas qu'on n'a pas encore tranché : un projet Payload avec une équipe éditoriale importante qui trouve l'admin trop brut. Est-ce que l'admin de Payload se customise suffisamment pour atteindre le niveau de polissage de Strapi ? C'est la limite qu'on explore en ce moment.