Directus vs Payload vs Supabase : Quel backend CMS utiliser en 2026

J'ai livré des projets en production avec chacun de ces trois outils au cours des deux dernières années. Chaque fois que je démarre un nouveau projet, la même question revient dans nos discussions d'architecture : Directus, Payload, ou Supabase ? La réponse n'est jamais la même deux fois, car cela dépend de choses que les pages marketing ne vous disent pas -- comment votre équipe de contenu travaille réellement, à quoi ressemblent vos relations de données, et où vous serez dans 18 mois.

Ce n'est pas une comparaison de liste de fonctionnalités. C'est le cadre de décision que j'utilise réellement lors de la définition de projets chez Social Animal, affiné par des dizaines de builds headless. À la fin, vous saurez quel outil convient à votre situation spécifique sans vous remettre en question.

Table des matières

• L'identité centrale de chaque outil
• Architecture et modélisation de données comparées
• Expérience d'édition de contenu
• Expérience développeur et conception d'API
• Authentification, permissions et sécurité au niveau des lignes
• Auto-hébergement, cloud et tarification en 2026
• Benchmarks de performance et d'évolutivité
• Le cadre de décision : quand utiliser quoi
• Scénarios de projets réels
• Chemins de migration et considérations de verrouillage
• FAQ

L'identité centrale de chaque outil

Avant d'entrer dans les détails, vous devez comprendre ce que chaque outil est réellement à sa base, car le chevauchement des ensembles de fonctionnalités peut être trompeur.

Directus est un CMS headless database-first. Il enveloppe une base de données SQL existante (Postgres, MySQL, SQLite, MS SQL, MariaDB, CockroachDB) avec une API auto-générée et un panneau d'administration poli. Vous concevez votre base de données, Directus l'introspection et vous offre une interface utilisateur. Il est écrit en TypeScript et s'exécute sur Node.js.

Payload est un CMS headless code-first construit sur Next.js (à partir de Payload 3.0). Vous définissez les collections et les champs dans les fichiers de configuration TypeScript, et Payload génère le schéma de base de données, l'interface utilisateur d'administration, les points de terminaison API et les types TypeScript à partir de cette configuration. Il utilise MongoDB ou Postgres comme couche de base de données.

Supabase est une alternative open-source à Firebase -- un backend-as-a-service construit au-dessus de Postgres. Ce n'est vraiment pas un CMS du tout. C'est une plateforme de base de données avec authentification, stockage, abonnements en temps réel et fonctions edge. Mais les équipes l'utilisent constamment comme backend CMS, ce qui est pourquoi il continue à apparaître dans ces comparaisons.

Cette distinction importe plus que toute autre chose dans cet article. Directus et Payload sont des systèmes de gestion de contenu spécifiquement conçus. Supabase est un backend à usage général que vous pouvez transformer en système de gestion de contenu avec suffisamment d'efforts.

Architecture et modélisation de données comparées

Directus : Database-First

Directus ne possède pas votre schéma. Vous pouvez le pointer vers une base de données existante et il générera automatiquement un panneau d'administration. C'est vraiment puissant lorsque vous travaillez avec des systèmes hérités ou lorsque votre modèle de données dessert plusieurs applications au-delà de la gestion de contenu.

La modélisation des relations dans Directus est solide. M2M, M2O, O2M, et même les traductions sont gérées via l'interface utilisateur. Mais il y a un hic : parce que Directus introspection la base de données plutôt que de la générer à partir du code, vos changements de schéma se produisent à deux endroits -- migrations et l'administrateur Directus. Cela peut devenir compliqué dans les environnements d'équipe si vous n'êtes pas discipliné.

# Snapshot de schéma Directus (simplifié)
collections:
  - collection: articles
    fields:
      - field: title
        type: string
        interface: input
      - field: content
        type: text
        interface: input-rich-text-md
      - field: author
        type: uuid
        interface: select-dropdown-m2o
        related_collection: authors

Payload : Code-First

Payload 3.0 (la version actuelle en 2026) s'exécute à l'intérieur de Next.js en tant que plugin. Vos collections sont définies en TypeScript :

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: 'authors',
    },
  ],
}

Cette approche code-first signifie que votre schéma vit dans le contrôle de version. Vous obtenez des types TypeScript auto-générés à partir de votre configuration. C'est la meilleure expérience développeur des trois pour les équipes orientées TypeScript. L'inconvénient ? Les non-développeurs ne peuvent pas modifier le modèle de données sans un changement de code.

Supabase : SQL-First

Avec Supabase, vous écrivez du SQL. Postgres pur. Vous définissez vos tables, configurez les politiques de sécurité au niveau des lignes, puis interagissez via l'API REST auto-générée (PostgREST) ou le client JavaScript.

CREATE TABLE articles (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  title TEXT NOT NULL,
  content JSONB,
  author_id UUID REFERENCES authors(id),
  created_at TIMESTAMPTZ DEFAULT now(),
  published BOOLEAN DEFAULT false
);

-- Row Level Security
ALTER TABLE articles ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Public can read published articles"
  ON articles FOR SELECT
  USING (published = true);

Vous obtenez une flexibilité maximale mais zéro interface utilisateur de gestion de contenu prête à l'emploi. Vous allez soit construire un administrateur personnalisé, utiliser un outil tiers, soit connecter quelque chose comme Directus au-dessus de la même instance Postgres (oui, les gens font réellement cela).

Expérience d'édition de contenu

C'est là que la distinction CMS-vs-not-a-CMS frappe le plus fort.

Fonctionnalité	Directus	Payload	Supabase
Interface utilisateur d'administration intégrée	✅ Poli, personnalisable	✅ Natif à Next.js, très bon	❌ Éditeur de table uniquement
Éditeur de texte enrichi	✅ WYSIWYG + Markdown	✅ Basé sur Lexical (excellent)	❌ Aucun
Bibliothèque de médias	✅ Complète	✅ Complète	⚠️ Buckets de stockage (pas d'interface de bibliothèque)
Aperçu du contenu	✅ Via modules personnalisés	✅ Aperçu en direct natif	❌ Construisez le vôtre
Localisation	✅ Système de traduction intégré	✅ Localisation au niveau du champ	❌ Implémentation manuelle
Versioning du contenu	✅ Révisions intégrées	✅ États brouillons + versions	❌ Construisez le vôtre
Workflow / Publication	✅ Système de flux	✅ États brouillon/publication	❌ Logique personnalisée nécessaire
Convivial pour les non-développeurs	✅ Très	✅ Oui	❌ Pas du tout

Si votre projet implique des éditeurs de contenu -- des personnes qui écrivent des articles de blog, gèrent des catalogues de produits, mettent à jour des pages de destination -- Supabase est le mauvais outil. Point final. Vous passeriez des semaines à construire ce que Directus et Payload vous donnent le jour un.

L'expérience d'édition de Payload s'est considérablement améliorée depuis 3.0. L'éditeur de texte enrichi basé sur Lexical est flexible, la fonctionnalité d'aperçu en direct fonctionne magnifiquement avec les frontends Next.js, et le panneau d'administration se sent natif parce qu'il s'exécute littéralement à l'intérieur de votre application Next.js.

Directus a le panneau d'administration le plus mature des trois. Il a été affiné au cours des années, et le système d'affichage/interface personnalisé signifie que vous pouvez construire des flux éditoriaux complexes sans toucher le code frontend. Pour les organisations axées sur le contenu, cela compte beaucoup.

Expérience développeur et conception d'API

Styles d'API

Directus vous donne REST et GraphQL prêts à l'emploi, plus un SDK JavaScript. L'API REST suit un modèle cohérent, et l'implémentation GraphQL est auto-générée à partir de votre schéma. Cela fonctionne, mais le GraphQL peut sembler limité pour les requêtes imbriquées complexes.

Payload génère les API REST et GraphQL, plus vous avez accès complet à l'API locale (requêtes de base de données directes sans frais HTTP). Depuis Payload 3.0 qui s'exécute à l'intérieur de votre application Next.js, vous pouvez appeler payload.find() directement dans vos composants serveur. C'est un avantage énorme pour les projets Next.js.

// API locale de Payload dans un composant serveur Next.js
import { getPayload } from 'payload'
import config from '@payload-config'

export default async function ArticlePage({ params }) {
  const payload = await getPayload({ config })
  const article = await payload.findByID({
    collection: 'articles',
    id: params.id,
    depth: 2,
  })
  return <Article data={article} />
}

L'API de Supabase est auto-générée par PostgREST, et la bibliothèque client JavaScript est vraiment excellente. Le générateur de requêtes se sent naturel :

const { data, error } = await supabase
  .from('articles')
  .select('*, author:authors(*)')
  .eq('published', true)
  .order('created_at', { ascending: false })
  .range(0, 9)

Supabase a aussi des abonnements en temps réel, que ni Directus ni Payload n'offrent nativement. Si vous avez besoin de mises à jour de données en direct (chat, notifications, édition collaborative), Supabase gagne par défaut.

Sécurité des types

Payload a la meilleure histoire TypeScript. Les types sont générés à partir de vos configurations de collection, et tout est fortement typé de bout en bout. Supabase a une génération de type solide via leur CLI (supabase gen types typescript), qui crée des types à partir de votre schéma de base de données. Directus a un SDK TypeScript mais la génération de types nécessite une configuration supplémentaire et n'est pas aussi étroitement intégrée.

Authentification, permissions et sécurité au niveau des lignes

C'est là que Supabase brille vraiment. La sécurité au niveau des lignes Postgres (RLS) est le modèle de permissions le plus granulaire et le plus éprouvé des trois. Vous définissez des politiques au niveau de la base de données, et elles s'appliquent indépendamment de la façon dont les données sont accédées. C'est incroyablement puissant pour les applications SaaS multi-locataires.

Directus a un système de permissions basé sur les rôles qui fonctionne au niveau de la collection et du champ. C'est intuitif dans le panneau d'administration et suffisant pour la plupart des cas d'utilisation CMS. Vous pouvez définir des permissions CRUD par rôle et même ajouter des règles de filtre personnalisées.

Payload offre le contrôle d'accès au niveau du champ et de la collection via des fonctions dans votre configuration :

{
  slug: 'articles',
  access: {
    read: () => true,
    create: ({ req: { user } }) => user?.role === 'editor',
    update: ({ req: { user } }) => user?.role === 'editor',
    delete: ({ req: { user } }) => user?.role === 'admin',
  },
  fields: [
    {
      name: 'internalNotes',
      type: 'textarea',
      access: {
        read: ({ req: { user } }) => user?.role === 'admin',
      },
    },
  ],
}

Pour un CMS standard avec éditeurs, relecteurs et administrateurs, les trois fonctionnent bien. Pour les applications multi-locataires complexes avec des règles de permissions dynamiques, le RLS de Supabase est l'option la plus puissante.

Auto-hébergement, cloud et tarification en 2026

Les trois sont open source et auto-hébergeables. Mais la tarification du cloud vous en dit long sur leurs marchés cibles.

Plan	Directus Cloud	Payload Cloud	Supabase Cloud
Niveau gratuit	❌ Pas de cloud gratuit	✅ 1 projet, limité	✅ 2 projets, 500MB DB
Starter/Pro	$99/mo (Professionnel)	$35/mo (Standard)	$25/mo (Pro)
Équipe/Affaires	$399/mo (Entreprise)	Tarification personnalisée	$599/mo (Équipe)
Coût auto-hébergé	Gratuit (open source)	Gratuit (open source)	Gratuit (open source)
Base de données incluse	✅ Gérée	✅ Postgres gérée	✅ Postgres gérée
CDN/Stockage	Inclus	Inclus	Inclus avec limites

Tarification à partir du Q1 2026. Consultez la page de tarification de chaque plateforme pour les tarifs actuels.

Payload Cloud est l'option gérée la plus abordable pour les petits et moyens projets. Le niveau gratuit de Supabase est le plus généreux pour la création de prototypes et les projets parallèles. Directus Cloud cible les organisations plus grandes disposées à payer pour une expérience gérée poli.

L'auto-hébergement change complètement l'équation. Les trois fonctionnent bien sur un VPS à $5-20/mois. Directus et Supabase ont des configurations Docker Compose officielles qui fonctionnent de manière fiable. Payload se déploie partout où Next.js s'exécute -- Vercel, Railway, Fly.io, votre propre serveur.

Pour nos projets de développement CMS headless, nous recommandons généralement l'auto-hébergement sur Railway ou Fly.io pour l'efficacité des coûts, avec le cloud géré uniquement lorsque le client a besoin de SLA garantis.

Benchmarks de performance et d'évolutivité

J'ai exécuté des benchmarks informels sur du matériel équivalent (4 vCPU, 8GB RAM, Postgres 16) avec un ensemble de données d'environ 50 000 enregistrements de contenu.

Opération	Directus	Payload	Supabase
Requête de liste simple (20 éléments)	~45ms	~12ms (API locale) / ~38ms (REST)	~18ms
Requête de relation imbriquée (profondeur 3)	~120ms	~35ms (API locale) / ~95ms (REST)	~55ms
Recherche en texte intégral (1000 résultats)	~180ms	~85ms	~40ms (pg_trgm)
Insertion en masse (1000 enregistrements)	~2.1s	~1.8s	~0.9s
Temps de démarrage à froid	~3.5s	~2.8s	N/A (toujours en cours d'exécution)

L'API locale de Payload est l'option la plus rapide pour les applications Next.js car il n'y a pas de surcharge HTTP -- vous interrogez directement la base de données à partir de votre processus de rendu. La performance Postgres brute de Supabase est difficile à battre pour les opérations intensives en données. Directus ajoute une certaine surcharge via sa couche d'abstraction, mais elle est parfaitement fine pour les charges de travail de service de contenu.

Pour la recherche en particulier, Supabase a un avantage significatif car vous pouvez utiliser la recherche en texte intégral native de Postgres, les index trigram et même l'extension pgvector pour la recherche sémantique. Directus et Payload supportent tous deux la recherche mais s'appuient sur leurs propres implémentations plutôt que de tirer parti de Postgres directement.

Le cadre de décision : quand utiliser quoi

Voici le cadre réel. Répondez à ces questions, et votre choix devient évident.

Choisir Directus quand :

• Votre équipe de contenu est grande et non-technique
• Vous devez envelopper une base de données existante avec une couche CMS
• Vous utilisez une base de données autre que Postgres (MySQL, MS SQL, etc.)
• Vous avez besoin d'un CMS autonome qui dessert plusieurs frontends (web, mobile, kiosk)
• Votre frontend n'est pas Next.js (peut-être vous utilisez Astro, Nuxt, ou SvelteKit)
• Vous voulez une flexibilité maximale dans la personnalisation de l'interface utilisateur d'administration sans code

Directus s'associe magnifiquement avec Astro pour les sites riches en contenu où le rendu au moment de la construction et l'architecture des îles ont plus de sens qu'un cadre React complet.

Choisir Payload quand :

• Votre frontend est Next.js (c'est le cas d'utilisation killer)
• Votre équipe est first-TypeScript et veut la sécurité des types partout
• Vous voulez CMS et frontend dans une seule unité déployable
• Vous avez besoin de capacités d'aperçu en direct et d'édition visuelle
• Vous voulez des schémas définis par le code dans le contrôle de version
• Vous construisez un site où le modèle de contenu est bien défini dès le départ

Payload est notre recommandation par défaut pour les projets de développement Next.js où la gestion de contenu est une exigence centrale. L'intégration est inégalée.

Choisir Supabase quand :

• Vous construisez une application, pas un site de contenu
• Vous avez besoin de fonctionnalités en temps réel (chat, mises à jour en direct, édition collaborative)
• Vous avez besoin de permissions multi-locataires complexes (RLS est roi)
• Votre besoin primaire est un backend, et le contenu est secondaire
• Vous voulez utiliser les extensions Postgres (pgvector, PostGIS, pg_cron)
• Votre équipe est à l'aise de construire ses propres interfaces d'administration
• Vous construisez un produit SaaS où les données générées par l'utilisateur importent plus que le contenu éditorial

Scénarios de projets réels

Scénario 1 : Site Web de Marketing avec Blog

Meilleur choix : Payload (si Next.js) ou Directus (si Astro/autre)

Un site de marketing avec 50-200 pages, un blog, et une petite équipe de contenu de 2-3 personnes. Vous avez besoin de flexibilité de page de destination, d'optimisation d'image, de gestion de métadonnées SEO, et peut-être quelques tests A/B.

La fonctionnalité d'aperçu en direct de Payload est parfaite ici. Les éditeurs de contenu peuvent voir exactement à quoi ressemblera la page avant la publication. Le type de champ basé sur les blocs vous permet de construire des pages de destination flexibles sans donner aux éditeurs assez de corde pour se pendre.

Scénario 2 : Catalogue de produits d'e-commerce

Meilleur choix : Directus ou Payload

Un catalogue de produits avec 5 000+ SKU, une catégorisation complexe, plusieurs listes de prix, et l'intégration avec les systèmes d'inventaire. La clé ici est la flexibilité de la modélisation des données et la capacité à gérer efficacement les données structurées.

Directus a un léger avantage si vous devez vous connecter à une base de données de produits existante sans migrer les données. Payload gagne si vous construisez à partir de zéro et voulez des requêtes de produits type-safe dans votre vitrine Next.js.

Scénario 3 : Plateforme SaaS Multi-locataires

Meilleur choix : Supabase

Une plateforme où chaque client a son propre espace de données, avec accès basé sur les rôles, notifications en temps réel, et contenu généré par l'utilisateur. Vous avez besoin de sécurité au niveau des lignes, de fonctions edge pour la logique métier, et de la capacité à évoluer horizontalement.

Ce n'est pas un projet CMS -- c'est un projet de backend d'application. Supabase a été construit exactement pour cela.

Scénario 4 : Base de connaissances interne

Meilleur choix : Payload ou Directus

Une wiki/base de connaissances interne pour une entreprise de 200 personnes. Contenu en texte enrichi, catégorisation, recherche et accès basé sur les rôles. Les éditeurs de contenu vont des techniques aux non-techniques.

Chaque CMS fonctionne bien ici. Directus a un léger avantage pour les équipes non-techniques car le panneau d'administration ne nécessite aucun code à personnaliser. Payload est meilleur si vous voulez une expérience frontend poli et de marque.

Chemins de migration et considérations de verrouillage

Le verrouillage est réel. Pensez-y avant de vous engager.

Directus a le moins de verrouillage car votre schéma de base de données est indépendant du CMS. Supprimez Directus, et vous avez toujours une base de données SQL propre et standard. Vos données ne sont pas piégées dans un format propriétaire.

Payload stocke les données dans les tables Postgres standard (ou MongoDB), mais le schéma suit les conventions de Payload. La migration signifie restructurer certaines choses, mais vos données sont toujours dans une base de données standard.

Supabase est juste Postgres. Zéro verrouillage. Vous pouvez prendre votre dump de base de données et l'exécuter sur n'importe quelle instance Postgres. Si Supabase disparaissait demain, vous auriez besoin de remplacer certains appels API mais votre data et schéma seraient parfaitement intacts.

Les trois obtiennent de bons résultats sur le verrouillage par rapport aux plates-formes CMS propriétaires comme Contentful ou Sanity, où vos données vivent dans le cloud de quelqu'un d'autre et les exporter est toujours un processus partiel.

FAQ

Puis-je utiliser Supabase comme CMS headless ? Techniquement oui, mais vous allez construire des fonctionnalités CMS à partir de zéro -- interface utilisateur d'édition de contenu, gestion des médias, historique des révisions, flux de publication. Pour les petits projets avec gestion de contenu réservée aux développeurs, cela peut fonctionner. Pour tout ce qui implique des éditeurs non-techniques, utilisez un vrai CMS comme Payload ou Directus et connectez Supabase pour les données d'application si nécessaire.

Payload est-il vraiment gratuit ? Quel est le piège ? Payload CMS est vraiment open source sous la licence MIT. Vous pouvez l'auto-héberger gratuitement à jamais. Payload Cloud est leur service d'hébergement géré payant, à partir de $35/mois. Le piège, si vous voulez l'appeler ainsi, est que Payload Cloud a quelques fonctionnalités premium comme le générateur de formulaires et les plugins SEO qui sont gratuits mais bénéficient de l'environnement hébergé. Le CMS de base est pleinement fonctionnel sans payer quoi que ce soit.

Puis-je utiliser Directus et Supabase ensemble ? Absolument, et c'est un modèle que j'ai utilisé plusieurs fois. Pointez Directus vers une base de données Postgres Supabase. Vous obtenez le panneau d'administration de Directus pour la gestion de contenu et les abonnements en temps réel de Supabase, l'authentification et les fonctions edge pour les fonctionnalités d'application. Les deux outils se complètent bien car ils opèrent à différentes couches.

Quel est le meilleur pour un projet Next.js ? Payload, et ce n'est pas près. Depuis Payload 3.0, le CMS s'exécute à l'intérieur de votre application Next.js en tant que plugin. Vous obtenez l'API locale pour les requêtes de base de données sans frais généraux dans les composants serveur, l'aperçu en direct natif et un déploiement unique. Nous utilisons cette combinaison constamment dans notre travail de développement Next.js.

Comment ceux-ci se comparent-ils à Strapi en 2026 ? Strapi v5 est une option solide mais a pris du retard dans certains domaines. Son panneau d'administration semble dépassé par rapport à celui de Payload, son support TypeScript n'est pas aussi fort, et son modèle de licence est devenu plus restrictif. Directus offre une approche similaire de wrapping de base de données avec une interface utilisateur plus moderne. Payload offre une meilleure DX pour les équipes TypeScript. L'avantage principal de Strapi est son écosystème de plugins plus grand et sa communauté plus grande, mais l'écart se referme.

Qu'en est-il de Sanity, Contentful, ou autres plates-formes CMS SaaS ? Sanity et Contentful sont de grands produits mais ce sont des plates-formes SaaS propriétaires. Vos données vivent sur leurs serveurs, la tarification évolue avec l'utilisation (et peut devenir chère rapidement), et vous dépendez de leur infrastructure. Directus, Payload et Supabase sont tous open source et auto-hébergeables. Si la propriété des données, le contrôle des coûts et la flexibilité de déploiement vous importent, les options open source gagnent. Nous couvrons cela plus en détail sur notre page de développement CMS headless.

Quel a le meilleur écosystème de plugins/extensions ? Directus a un marketplace avec des extensions communautaires pour les interfaces personnalisées, les affichages et les modules. Payload a un écosystème de plugins croissant avec des plugins officiels pour SEO, formulaires, docs imbriquées et redirects. Supabase a des extensions Postgres (des centaines d'entre elles) qui servent un but différent mais sont incroyablement puissantes. Pour les plugins spécifiques à CMS, Directus a actuellement le plus d'options.

Quelle est la meilleure option pour une petite équipe avec un budget limité ? Payload auto-hébergé sur le niveau gratuit de Vercel ou sur le plan hobby de Railway. Vous obtenez un CMS complet avec zéro coût mensuel pour les projets à faible trafic. Le niveau gratuit de Supabase est également excellent pour la création de prototypes. Directus nécessite l'auto-hébergement pour un usage gratuit (pas de niveau cloud gratuit), mais s'exécute bien sur un VPS à $5/mois. Si le budget est serré et que vous avez besoin d'aide pour faire le bon choix, contactez-nous -- nous avons aidé de nombreuses équipes à trouver l'architecture la plus rentable.