Votre déploiement se termine, le site est en ligne, et trois semaines plus tard votre équipe contenu vous ping : les uploads d'images expiren, les catégories imbriquées ne s'enregistrent pas, et la réponse API grimpe au-delà de 800ms. J'ai reproduit ce scénario avec Directus, Payload, et Supabase sur des projets en production au cours des deux dernières années — les mêmes symptômes, des causes racines différentes à chaque fois. La réponse dépend de choses que les landing pages ignorent : comment votre équipe éditoriale structure les workflows, à quoi ressemble réellement votre graphe relationnel, et si vous utilisiez toujours ce stack quand la Série A ferme. Voici le framework qui détermine quel backend survit à vos six prochains sprints.

Ce n'est pas une comparaison de checklist de fonctionnalités. C'est le framework de décision que j'utilise réellement quand je scopes des 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

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

L'identité centrale de chaque outil

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

Directus est un CMS headless axé sur la base de données. 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'introspect et vous donne 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 d'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, souscriptions en temps réel et fonctions edge. Mais les équipes l'utilisent constamment comme backend CMS, c'est pourquoi il continue d'apparaître dans ces comparaisons.

Cette distinction compte plus que tout le reste de cet article. Directus et Payload sont des systèmes de gestion de contenu spécialisés. Supabase est un backend à usage général que vous pouvez façonner en système de gestion de contenu avec suffisamment d'efforts.

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

Directus : Axé sur la base de données

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 quand vous travaillez avec des systèmes hérités ou quand votre modèle de données sert 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 traitées via l'interface utilisateur. Mais il y a un problème : parce que Directus introspect 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'admin Directus. Cela peut devenir désordonnée dans les environnements d'équipe si vous n'êtes pas rigoureux.

# 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 complets 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. Du Postgres brut. Vous définissez vos tables, configurez les politiques de Row-Level Security, 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 directement. Vous devrez soit construire un admin personnalisé, utiliser un outil tiers, soit connecter quelque chose comme Directus au-dessus de la même instance Postgres (oui, les gens font vraiment 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 tableau seulement
Éditeur de texte enrichi ✅ WYSIWYG + Markdown ✅ Basé sur Lexical (excellent) ❌ Aucun
Bibliothèque multimédia ✅ 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 des champs ❌ Implémentation manuelle
Versioning du contenu ✅ Révisions intégrées ✅ États de brouillon + versions ❌ Construisez le vôtre
Workflow / Publication ✅ Système Flows ✅ États brouillon/publié ❌ 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 gens 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 premier jour.

L'expérience d'édition de Payload s'est remarquablement améliorée depuis 3.0. L'éditeur de texte enrichi basé sur Lexical est flexible, la fonction d'aperçu en direct fonctionne magnifiquement avec les frontends Next.js, et le panneau d'administration se sent natif car 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 fil des années, et le système d'affichage/interface personnalisé signifie que vous pouvez construire des workflows éditoriaux complexes sans toucher au code frontend. Pour les organisations riches en contenu, cela compte beaucoup.

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

Expérience développeur et conception d'API

Styles d'API

Directus vous donne REST et GraphQL directement, 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 GraphQL peut sembler limité pour les requêtes imbriquées complexes.

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

// API locale 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 cliente JavaScript est véritablement excellente. Le constructeur de requête 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 également des souscriptions en temps réel, ce 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 bonne génération de types 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 Row-Level Security

C'est là que Supabase brille véritablement. Row-Level Security (RLS) de Postgres est le modèle de permissions le plus granulaire et le plus éprouvé au combat des trois. Vous définissez les 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 des champs. C'est intuitif dans le panneau d'administration et suffisant pour la plupart des cas d'utilisation CMS. Vous pouvez définir les permissions CRUD par rôle et ajouter même des règles de filtre personnalisées.

Payload offre le contrôle d'accès au niveau des champs et des collections 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, correcteurs et administrateurs, les trois fonctionnent bien. Pour les applications SaaS multi-locataires complexes avec des règles de permission 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 les tarifs cloud vous disent beaucoup sur leurs marchés cibles.

Plan Directus Cloud Payload Cloud Supabase Cloud
Tier gratuit ❌ Pas de cloud gratuit ✅ 1 projet, limité ✅ 2 projets, DB 500MB
Starter/Pro $99/mois (Professional) $35/mois (Standard) $25/mois (Pro)
Team/Business $399/mois (Enterprise) Tarification personnalisée $599/mois (Team)
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é ✅ Postgres géré
CDN/Stockage Inclus Inclus Inclus avec limites

Tarification au T1 2026. Vérifiez 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 tier gratuit de Supabase est le plus généreux pour le prototypage et les projets parallèles. Directus Cloud cible les plus grandes organisations prêtes à payer pour une expérience gérée poli.

L'auto-hébergement change dramatiquement 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 quand le client a besoin de SLA garantis.

Performance et benchmarks de scalabilité

J'ai exécuté quelques 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 articles) ~45ms ~12ms (API locale) / ~38ms (REST) ~18ms
Requête avec 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 frais généraux 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 riches en données. Directus ajoute une surcharge via sa couche d'abstraction, mais c'est parfaitement correct pour les workloads de diffusion de contenu.

Pour la recherche spécifiquement, 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 framework de décision : quand utiliser lequel

Voici le vrai framework. Répondez à ces questions, et votre choix devient évident.

Choisissez Directus quand :

  • Votre équipe 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 sert plusieurs frontends (web, mobile, kiosque)
  • 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 island ont plus de sens qu'un framework React complet.

Choisissez Payload quand :

  • Votre frontend est Next.js (c'est le cas d'utilisation phare)
  • Votre équipe est TypeScript-first 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 code dans le contrôle de version
  • Vous construisez un site où le modèle de contenu est bien défini à l'avance

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 n'a pas d'égal.

Choisissez Supabase quand :

  • Vous construisez une application, pas un site web 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 le roi)
  • Votre besoin principal est un backend, et le contenu est secondaire
  • Vous voulez utiliser les extensions Postgres (pgvector, PostGIS, pg_cron)
  • Votre équipe est à l'aise pour construire ses propres interfaces d'administration
  • Vous construisez un produit SaaS où les données générées par l'utilisateur comptent plus que le contenu éditorial

Scénarios réels de projets

Scénario 1 : Site Web de Marketing avec Blog

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

Un site marketing avec 50-200 pages, un blog, et une petite équipe contenu de 2-3 personnes. Vous avez besoin de flexibilité des pages de destination, d'optimisation d'images, de gestion des métadonnées SEO, et peut-être de 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 des 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 E-commerce

Meilleur choix : Directus ou Payload

Un catalogue de produits avec 5 000+ SKU, une catégorisation complexe, plusieurs listes de prix, et 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-locataire

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 Row-Level Security, de fonctions edge pour la logique métier, et de la capacité à scaler horizontalement.

Ce n'est pas un projet CMS -- c'est un projet 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 de technique à non-technique.

L'un ou l'autre CMS fonctionne bien ici. Directus a un léger avantage pour les équipes non-techniques car le panneau d'administration ne nécessite zéro code pour la personnalisation. Payload est mieux 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 des tables Postgres (ou MongoDB) standard, 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 n'est que Postgres. Zéro verrouillage. Vous pouvez prendre un 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 d'API mais vos données et schéma seraient parfaitement intacts.

Les trois obtiennent une bonne note sur le verrouillage comparé aux plates-formes CMS propriétaires comme Contentful ou Sanity, où vos données vivent dans le cloud de quelqu'un d'autre et l'exporter est toujours un processus partiel.

FAQ

Puis-je utiliser Supabase comme CMS headless ?

Techniquement oui, mais vous construirez les fonctionnalités CMS de zéro -- interface utilisateur d'édition de contenu, gestion multimédia, historique des révisions, workflows 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 pour toujours. Payload Cloud est leur service d'hébergement géré payant, commençant à $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 principal est pleinement fonctionnel sans payer quoi que ce soit.

Puis-je utiliser Directus et Supabase ensemble ?

Absolument, et c'est un pattern 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 souscriptions 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 à des couches différentes.

Quel est le meilleur pour un projet Next.js ?

Payload, et ce n'est pas proche. 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 se comparent-ils à Strapi en 2026 ?

Strapi v5 est une option solide mais a pris du retard dans quelques domaines. Son panneau d'administration semble dépassé comparé à celui de Payload, son support TypeScript n'est pas aussi fort, et son modèle de licence s'est avéré plus restrictif. Directus offre une approche similaire d'emballage de base de données avec une interface utilisateur plus moderne. Payload offre une meilleure expérience développeur pour les équipes TypeScript. L'avantage principal de Strapi est son plus grand écosystème de plugins et sa communauté plus grande, mais l'écart se comble.

Qu'en est-il de Sanity, Contentful, ou autres plateformes CMS SaaS ?

Sanity et Contentful sont d'excellents produits mais ce sont des plates-formes SaaS propriétaires. Vos données vivent sur leurs serveurs, les tarifs augmentent avec l'utilisation (et peuvent devenir très chers 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é du déploiement vous importent, les options open source gagnent. Nous couvrons cela plus en détail sur notre page de développement CMS headless.

Lequel a le meilleur écosystème de plugins/extensions ?

Directus a une 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és, et redirects. Supabase a les 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 budget limité ?

Payload auto-hébergé sur le tier gratuit de Vercel ou le plan hobby de Railway. Vous obtenez un CMS complet avec zéro coût mensuel pour les projets à faible trafic. Le tier gratuit de Supabase est également excellent pour le prototypage. Directus nécessite l'auto-hébergement pour une utilisation gratuite (pas de tier cloud gratuit), mais fonctionne bien sur un VPS à $5/mois. Si le budget est serré et vous avez besoin d'aide pour faire le bon choix, contactez-nous -- nous avons aidé beaucoup d'équipes à trouver l'architecture la plus rentable.