Payload CMS vs Sanity vs Strapi : quel headless CMS choisir en 2026 ?

#Pourquoi le headless CMS s'impose pour les projets Next.js B2B premium

Le modèle monolithique — WordPress ou Drupal couplant back-office et rendu HTML — atteint ses limites dès lors qu'un projet exige performances front-end maximales, multi-canal (web, mobile, API partenaires), et autonomie éditoriale sans friction. Le headless CMS décorrèle la couche de gestion de contenu du rendu : les éditeurs gèrent leurs données via une interface dédiée, les développeurs consomment une API (REST, GraphQL ou propriétaire) depuis leur front Next.js.

Pour les projets B2B premium — sites institutionnels multi-marchés, plateformes de lead generation à fort volume, portails clients — ce découplage présente des avantages concrets :

• Performances Core Web Vitals : Next.js génère des pages statiques ou ISR depuis l'API CMS, sans bloquer le rendu côté serveur sur une base de données lente.
• Sécurité renforcée : le back-office CMS n'est pas exposé sur le même domaine que le site public. Les surfaces d'attaque sont réduites.
• Autonomie éditoriale : les équipes marketing ou contenu modifient, prévisualisent et publient sans dépendre d'un développeur pour chaque modification.
• Multi-locale et multi-site : un même CMS peut alimenter plusieurs sites Next.js (France, Suisse, Belgique) depuis une source de vérité unique.
• Évolutivité : remplacer le front-end Next.js ou ajouter un canal mobile ne nécessite pas de migrer le CMS.

Le marché des headless CMS compte aujourd'hui une quinzaine d'acteurs significatifs. Parmi eux, trois ont émergé comme références pour les équipes Next.js en 2025-2026 : Payload CMS v3, Sanity et Strapi v5. Ce comparatif les analyse sur 15 critères pour vous permettre de faire un choix éclairé selon votre profil.

#Payload CMS v3 — TypeScript-first, Next.js natif, self-hosted

Payload CMS est un headless CMS open-source né en 2021, conçu dès le départ pour les développeurs TypeScript. La version 3 (sortie fin 2024) représente une réécriture majeure : Payload devient une dépendance NPM intégrable directement dans une application Next.js 16 App Router, partageant le même processus Node.js et le même système de routage.

#Architecture et DX

L'avantage architectural de Payload v3 est sans équivalent dans sa catégorie : le CMS vit dans un sous-répertoire (payload) de votre app Next.js. Concrètement :

• Un seul package.json, un seul déploiement, une seule infrastructure.
• Les collections et les types CMS sont définis en TypeScript — Payload génère automatiquement les types correspondants pour vos composants React et vos Server Components.
• Zéro duplication de types entre le CMS et le front : si vous ajoutez un champ publishedAt: Date à votre collection Post, votre composant PostCard.tsx reçoit le bon type TypeScript sans étape intermédiaire.
• Le panneau d'administration Payload est lui-même une app Next.js, personnalisable avec vos propres composants React.

#Modèle de données

Payload structure ses données autour de trois primitives : Collections (entités avec plusieurs documents : articles, produits, utilisateurs), Globals (documents singleton : paramètres du site, navigation principale) et Blocks (composants de contenu modulaires réutilisables, équivalent des «slices» Prismic). Cette architecture couvre 100 % des besoins d'un site B2B sans sur-ingénierie.

#Base de données et déploiement

Payload v3 supporte MongoDB, PostgreSQL et SQLite via un système d'adaptateurs. Pour les projets Nehos, nous utilisons PostgreSQL sur OVH Managed Databases — un stack 100 % français, hébergé en Union Européenne, compatible RGPD sans addendum contractuel.

#Tarification

Payload CMS est gratuit et open-source (licence MIT). Le coût réel est celui de l'infrastructure : environ 5 €/mois sur OVH pour un projet PME standard (instance compute + base PostgreSQL + stockage objet pour les médias). Il n'existe pas de frein à la montée en charge lié à un pricing par utilisateur ou par appel API.

#Points de vigilance

Payload est une solution relativement jeune : son écosystème de plugins tiers est moins étendu que celui de Strapi. Les fonctionnalités de collaboration en temps réel (plusieurs éditeurs sur le même document) sont absentes dans la version actuelle. Pour les équipes éditoriales larges avec des workflows d'approbation complexes, Sanity offre une expérience plus complète.

#Sanity — GROQ, Studio flexible, SaaS premium

Sanity est une plateforme SaaS norvégienne fondée en 2017, aujourd'hui utilisée par des marques comme Nike, Figma et Cloudflare. Son positionnement est résolument haut de gamme : la meilleure expérience éditoriale du marché, au prix d'un modèle SaaS avec facturation à l'usage.

#GROQ : le langage de requête propriétaire

Là où les autres CMS exposent du REST ou du GraphQL, Sanity a inventé GROQ (Graph-Relational Object Queries), un langage de requête déclaratif optimisé pour les données de contenu arborescentes. GROQ permet des requêtes très expressives — filtrer, joindre, projeter et transformer des données en une seule requête — avec une syntaxe plus concise que GraphQL pour les cas d'usage CMS courants. La courbe d'apprentissage est réelle (2-3 jours pour un développeur senior), mais la puissance expressive est un vrai gain sur les projets complexes.

#Studio et collaboration

Le Sanity Studio est une SPA React entièrement personnalisable et déployable sur votre propre domaine. Ses points forts pour les équipes éditoriales :

• Collaboration en temps réel : plusieurs éditeurs peuvent travailler simultanément sur le même document, avec présence visible et résolution de conflits automatique (basé sur un protocole CRDT).
• Portable Text : le format de texte riche structuré de Sanity — analogue au contenu Slack ou Notion — permet des contenus complexes (blocs imbriqués, annotations riches) sans HTML brut ni Markdown non structuré.
• Preview live : prévisualisation du contenu en brouillon directement dans l'interface Studio, sans déploiement.
• Schémas versionnés : les schémas de contenu sont définis en code JavaScript/TypeScript et versionnés avec votre dépôt Git — un gain de traçabilité majeur pour les projets long terme.

#CDN mondial et performances

Sanity héberge les données sur son infrastructure distribuée mondiale (CDN Sanity API), avec des temps de réponse inférieurs à 50 ms depuis l'Europe sur les requêtes GROQ courantes. Pour les sites à fort trafic utilisant ISR ou SSG avec Next.js, ce CDN réduit significativement la charge serveur lors des builds et des revalidations.

#Tarification SaaS

Le plan Free inclut 3 utilisateurs, 10 Go de stockage et 500 000 API requests/mois — suffisant pour un projet de taille modeste. Le plan Growth (99 $/mois) passe à 25 utilisateurs, 100 Go et 1 M API requests. Au-delà, Sanity facture à l'usage : stockage (0,05 $/Go), bandwidth (0,10 $/Go), API requests supplémentaires. Pour un site B2B à fort volume éditorial, la facture mensuelle peut atteindre à partir de 800 € selon l'usage — un poste à anticiper dans le TCO.

Point de conformité : Sanity propose un DPA (Data Processing Agreement) RGPD signable, avec hébergement des données en Europe possible (datacenter Frankfurt). Pour les données non-personnelles (contenu éditorial pur), l'impact RGPD est limité.

#Strapi v5 — REST+GraphQL, open-source, plugin ecosystem

Strapi est le headless CMS open-source le plus populaire au monde avec plus de 60 000 étoiles GitHub. Fondé en France en 2015, il s'est imposé comme la référence de facto pour les équipes souhaitant un CMS auto-hébergé avec une prise en main rapide. La version 5 (sortie en 2024) apporte des améliorations majeures en termes de performances et de developer experience.

#Architecture et APIs

Strapi expose automatiquement une API REST et une API GraphQL pour chaque collection de contenu créée via son interface d'administration. La configuration se fait principalement via l'interface graphique — un avantage pour les équipes moins orientées «code-first». Les politiques d'accès (RBAC granulaire) et les webhooks sont configurables sans écrire de code.

Strapi v5 introduit le Document Service API, une couche d'abstraction unifiée qui remplace les APIs séparées de v4 (Entity Service + Query Engine) et simplifie les requêtes complexes côté back-end.

#Plugin ecosystem

L'un des atouts historiques de Strapi est son marketplace de plugins : SEO, internationalisation, contenu multi-version (draft/publish), gestion des médias avec transformation d'images, authentification SSO (SAML, OAuth2), et intégrations CRM. Ces plugins réduisent le temps de développement sur des fonctionnalités transverses.

#Déploiement flexible

Strapi se déploie sur n'importe quelle infrastructure Node.js : Docker, Kubernetes, Heroku, Render, Vercel (attention : Strapi requiert un serveur persistant, pas de serverless pur), ou sur des VM OVH. Les données sont stockées dans la base de données de votre choix : SQLite (développement), PostgreSQL, MySQL ou MariaDB (production).

Strapi propose également Strapi Cloud, son offre SaaS managée, avec des plans de 99 $ à 499 $/mois selon les ressources. Pour la plupart des projets PME-ETI, un déploiement self-hosted sur OVH reste plus économique.

#Limites de Strapi v5

Malgré sa maturité, Strapi présente quelques points de friction sur les projets Next.js B2B premium :

• Type safety incomplète : Strapi génère des types TypeScript via un plugin tiers (strapi-plugin-generate-types), mais la couverture reste moins exhaustive que Payload CMS nativement.
• Couplage REST/GraphQL : la DX pour consommer les APIs Strapi depuis Next.js nécessite plus de code boilerplate que Payload (qui partage le même processus) ou Sanity (dont les types GROQ sont auto-générés).
• Performance admin : l'interface d'administration Strapi est plus lente que Studio Sanity sur les collections volumineuses.

#Autres challengers à connaître

Beyond le trio principal, plusieurs acteurs méritent attention selon les contextes :

Contentful reste la référence enterprise pour les grands comptes avec des équipes éditoriales de 50+ personnes et des besoins de gouvernance de contenu avancés. Son pricing (489 $/mois en plan Team) le réserve aux organisations ayant un budget CMS conséquent.

Directus est un meta-framework open-source qui transforme n'importe quelle base de données SQL existante en API headless. Pertinent si votre organisation a déjà une base de données métier à exposer en tant que CMS sans migration de données.

Hygraph (ex GraphCMS) mise sur une architecture de content federation — agréger du contenu provenant de multiples sources (APIs tierces, bases existantes) dans un seul schéma GraphQL. Son avantage différenciant pour les projets nécessitant une couche d'unification de données hétérogènes.

Keystatic est un CMS émergent du studio Thinkmill, basé sur des fichiers Markdown/YAML versionnés dans Git. Idéal pour les équipes techniques préférant gérer le contenu dans leur dépôt Git plutôt que via une base de données — positionnement proche de Tina CMS.

#Tableau comparatif 15 critères : Payload v3 vs Sanity vs Strapi v5

#Grille de décision par profil

#Startup SaaS B2B (équipe technique réduite)

Recommandation : Payload CMS v3

Une startup SaaS construit son site marketing et son portail client sur le même dépôt Next.js. Payload s'intègre sans infrastructure supplémentaire, les types TypeScript sont partagés entre le CMS et l'app, et le coût de licence est nul. La jeunesse de l'écosystème est un risque acceptable pour une équipe technique capable de contribuer si nécessaire.

#Agence web (production de sites pour clients)

Recommandation : Sanity ou Payload selon le profil client

Pour les clients avec équipes éditoriales actives (10+ éditeurs, workflows d'approbation, collaboration simultanée) : Sanity. Son Studio clé en main et sa collaboration temps réel réduisent les demandes de support éditorial. Pour les clients PME avec équipes techniques internes ou budget infrastructure maîtrisé : Payload sur OVH. Le Sanity Studio peut être déployé sur le domaine client et offre une UX éditoriale premium.

#ETI B2B (500-5000 salariés, multi-marchés)

Recommandation : Sanity (si budget SaaS) ou Payload v3 (si contraintes RGPD ou self-hosting)

Les ETI B2B ont généralement besoin de multi-locale, de workflows de validation éditoriaux et d'intégrations avec leur PIM ou leur DAM. Sanity couvre ces besoins nativement. Si l'ETI opère dans un secteur régulé (banque, santé, collectivité) ou a une contrainte de résidence des données en France, Payload sur OVH SecNumCloud est la seule option sans friction réglementaire.

#Grand compte / DSI (5000+ salariés)

Recommandation : Contentful ou Sanity Enterprise

Au-delà d'une certaine taille, les besoins de gouvernance de contenu (rôles ultra-granulaires, audit logs, SSO SAML, SLA contractuel 99,9 %) dépassent ce que Payload ou Strapi offrent sans développements spécifiques. Contentful et Sanity Enterprise proposent des contrats avec SLA, support dédié et fonctionnalités de conformité SOC2/ISO27001.

#Migration entre CMS headless : points d'attention clés

Migrer d'un headless CMS vers un autre est une opération significative que nos équipes ont réalisée plusieurs fois. Les points de friction récurrents :

Modèle de données non-portable : chaque CMS a sa propre structure de schémas. La migration nécessite un mapping manuel entre les types source et destination, souvent avec des pertes de métadonnées (révisions, historique d'édition, métadonnées de workflow).

Médias et assets : les images et fichiers binaires stockés sur le CDN du CMS source doivent être re-téléversés ou redirigés vers le nouveau stockage. Pour un site avec 10 000+ assets, prévoir 2-5 jours de travail de migration et de vérification.

Références et relations : les relations entre documents (article → auteur → catégorie) utilisent des identifiants internes propres à chaque CMS. La migration casse nécessairement ces références — un script de migration sur mesure est systématiquement nécessaire.

Downtime éditorial : pendant la migration, les équipes éditoriales ne peuvent pas créer de nouveau contenu. Prévoir une fenêtre de gel éditorial de 24-72h selon le volume de données.

URLs et SEO : si la migration s'accompagne d'un changement de structure d'URL (chemin /api/articles/{id} vers /api/collections/posts/{slug}), des redirections 301 côté Next.js sont impératives pour préserver le capital SEO.

Recommandation Nehos : avant toute migration, réaliser un audit complet du modèle de données source, produire un script de migration versionné et testé sur un environnement de staging, et prévoir un rollback plan. Nous estimons les migrations CMS headless entre 5 et 15 jours de développement selon la complexité.

#La position Nehos : Payload CMS par défaut pour les nouveaux projets

Depuis début 2025, Nehos a standardisé Payload CMS v3 comme CMS de référence pour tous les nouveaux projets Next.js 16. Ce choix repose sur cinq raisons opérationnelles :

1. Stack unifiée, déploiement simplifié. Un seul dépôt, un seul déploiement OVH, une seule pipeline CI/CD. Pas d'infrastructure CMS séparée à maintenir, surveiller ou scaler indépendamment du front.

2. Type safety bout-en-bout sans overhead. Sur les projets Next.js B2B avec des dizaines de types de contenu, les erreurs de typage entre CMS et composants front sont une source récurrente de bugs en production. Payload élimine cette classe d'erreurs structurellement — pas par convention ou documentation.

3. Conformité RGPD sans friction. Payload + PostgreSQL sur OVH Managed Databases = données hébergées en France, DPA OVH signable, éligibilité SecNumCloud pour les projets sensibles. Aucun compromis sur la souveraineté des données.

4. Coût total de possession maîtrisé. Pas de frais de licence, pas de pricing à l'API request, pas de surcoût à la montée en charge éditoriale. Le seul coût variable est l'infrastructure OVH — prévisible et proportionnel au trafic réel.

5. Momentum et roadmap solide. Payload v3 bénéficie d'une communauté active et d'une roadmap publique ambitieuse. Les contributeurs principaux sont soutenus par une équipe commerciale (Payload Cloud) dont les intérêts sont alignés avec la qualité du core open-source.

Nous recommandons Sanity pour les projets avec des équipes éditoriales de plus de 10 personnes nécessitant une collaboration en temps réel, et Strapi pour les migrations depuis une architecture Strapi v4 existante où le coût de réécriture ne serait pas justifié.

Sur notre projet nehos-groupe.com lui-même, la stack technique Next.js 16 + Payload CMS est en production depuis mars 2026 — nous mangeons notre propre cuisine.