Je teste 6 CMS pour Next.js App Router en production -- Voici ce que j'ai appris

J'expédie des sites Next.js depuis l'époque du Pages Router, et j'ai perdu le compte du nombre de fois où j'ai vu un article « meilleur CMS » écrit par quelqu'un qui a clairement installé le truc une fois, suivi le tutoriel quickstart, et appelé ça une critique. Ce n'est pas ça.

Chez Social Animal, nous exploitons des sites de production sur plusieurs architectures CMS -- de Payload CMS alimentant une application de santé à Supabase servant 253 000+ pages sur trois plates-formes différentes. Nous avons évalué Strapi 5, Sanity et Contentful pour des projets clients réels. Et ce site même que vous lisez ? Il est construit sur des fichiers MDX validés dans un dépôt Git.

Donc quand je dis « nous avons testé 6 en production », je veux dire que nous avons fait face aux maux de tête de migration, aux surprises de temps de construction, aux messages Slack à 3 du matin à propos du contenu qui ne se publie pas. Voici tout ce que nous avons appris sur le choix du bon CMS pour Next.js App Router en 2026.

Table des matières

Meilleur CMS pour Next.js App Router 2026 : Nous avons testé 6 en production

Pourquoi le App Router change l'équation CMS

Si vous pensez toujours à la sélection du CMS de la façon dont vous l'aviez fait avec le Pages Router, vous laissez des performances sur la table. Le App Router a fondamentalement changé la façon dont les données circulent dans une application Next.js, et cela a des implications directes sur le CMS qui convient le mieux.

Voici ce qui importe maintenant :

Les Server Components sont l'option par défaut. Votre récupération de données CMS se fait sur le serveur sans expédier de JavaScript au client. Cela signifie que les CMS avec des SDK Node.js natifs ou -- encore mieux -- des API locales qui contournent entièrement le réseau ont un énorme avantage.

React Server Components + mise en cache fetch. Le dédoublonnage et la mise en cache intégrés du App Router signifient que vos modèles d'intégration CMS semblent complètement différents. Vous ne cherchez plus getStaticProps ou getServerSideProps. Vous écrivez des composants asynchrones qui appellent votre CMS directement.

Routes parallèles et routes d'interception. Ces modèles déverrouillent les mises en page pilotées par CMS qui étaient pénibles à construire auparavant. Un CMS qui prend en charge la modélisation flexible du contenu (pas seulement les billets de blog et les pages) brille ici.

Partial Prerendering (PPR). À partir de Next.js 15, PPR vous permet de servir un shell statique avec des trous dynamiques. Cela change complètement le débat ISR vs SSR, et cela signifie que votre stratégie de revalidation CMS est plus importante que jamais.

Avec tout ce contexte, entrons dans les tests réels.

Les 6 CMS que nous avons testés (et comment nous les avons testés)

Notre évaluation n'était pas théorique. Pour chaque CMS, nous avons soit expédié des pages de production, soit effectué une évaluation technique approfondie pour un projet client réel. Nous avons mesuré :

  • Expérience développeur avec le App Router spécifiquement
  • Temps de construction à différents nombres de pages
  • UX d'éditeur de contenu pour les membres non développeurs de l'équipe
  • Tarification à l'échelle (pas seulement le niveau gratuit)
  • Qualité d'intégration TypeScript
  • Modèles de revalidation (ISR, à la demande, webhooks)

Passons en revue chacun.

1. Payload CMS 3 -- Meilleur dans l'ensemble pour Next.js

Notre verdict : Meilleure expérience développeur pour Next.js App Router, point barre.

Payload CMS 3 est celui qui m'a fait repenser ce qu'un CMS pourrait être. Ce n'est pas un service distinct que vous appelez via HTTP. Il vit à l'intérieur de votre application Next.js. Même dépôt, même déploiement, mêmes types TypeScript.

Nous exécutons Payload 3 en production sur SleepDr, une plateforme de santé avec 228 pages, un contrôle d'accès multi-niveaux, et du contenu qui doit être exact (c'est lié à la santé, donc un contenu incorrect n'est pas seulement mauvais -- c'est un problème de responsabilité).

Ce qui rend Payload spécial pour App Router

L'API locale est la fonctionnalité clé. Au lieu de faire des requêtes HTTP à votre CMS, vous importez une fonction et l'appelez directement :

// app/blog/[slug]/page.tsx
import { getPayload } from 'payload'
import config from '@payload-config'

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const payload = await getPayload({ config })
  
  const posts = await payload.find({
    collection: 'posts',
    where: {
      slug: { equals: params.slug },
      status: { equals: 'published' },
    },
  })
  
  const post = posts.docs[0]
  if (!post) notFound()
  
  return <Article post={post} />
}

Pas de saut réseau. Pas de surcharge REST ou GraphQL. Pas de SDK à installer. L'appel de fonction est entièrement typé car Payload génère les interfaces TypeScript à partir de vos configurations de collection. Quand vous refactorisez un nom de champ, votre IDE capture chaque référence cassée instantanément.

Aperçu en direct avec App Router

L'aperçu en direct de Payload 3 fonctionne avec les Server Components. Vos éditeurs de contenu voient les modifications en temps réel sur la mise en page du site réel -- pas une approximation dans le panneau administrateur. Nous avons configuré cela pour SleepDr et l'équipe éditoriale est passée de « j'ai besoin d'un développeur pour vérifier cela » à l'édition autonome en une semaine.

Contrôle d'accès qui fonctionne réellement

Le contrôle d'accès au niveau des champs et des collections de Payload est défini dans le code :

const Posts: CollectionConfig = {
  slug: 'posts',
  access: {
    read: () => true,
    create: ({ req: { user } }) => user?.role === 'editor' || user?.role === 'admin',
    update: ({ req: { user } }) => user?.role === 'admin',
    delete: ({ req: { user } }) => user?.role === 'admin',
  },
  fields: [
    // ...
  ],
}

Pour une application de santé, cette granularité n'est pas optionnelle. C'est une exigence.

Les compromis

Payload s'exécute sur votre infrastructure. Si vous voulez une expérience SaaS entièrement gérée, Payload Cloud existe (à partir d'environ 35 $/mois pour la production), mais vous êtes toujours responsable de la compréhension du déploiement. C'est aussi une dépendance du runtime Node.js, ce qui signifie que votre hébergement doit la prendre en charge (Vercel fonctionne, mais les coûts augmentent avec les connexions persistantes à votre base de données).

Pour notre travail de développement Next.js, Payload 3 est désormais notre recommandation par défaut pour les sites riches en contenu de moins de 5 000 pages.

Meilleur CMS pour Next.js App Router 2026 : Nous avons testé 6 en production - architecture

2. Supabase-as-CMS -- Meilleur pour la mise à l'échelle (10K+ pages)

Notre verdict : Pas techniquement un CMS, mais rien d'autre ne s'en rapproche pour les énormes ensembles de données structurés.

C'est le choix non conventionnel, et c'est celui qui m'enthousiasme le plus. Supabase n'est pas commercialisé comme un CMS. C'est une plateforme PostgreSQL avec authentification, stockage et Edge Functions. Mais quand votre « contenu » est vraiment des données structurées -- profils de célébrités, annuaires commerciaux, bases de données de produits -- les CMS traditionnels s'effondrent à l'échelle, et Supabase ne transpire même pas.

Nous exécutons trois sites de production sur Supabase-as-CMS :

  • DA -- 91 000+ pages de données de célébrités dans 30 langues
  • NAS -- 137 000+ annonces commerciales
  • HostList -- 25 000+ annonces de fournisseurs d'hébergement

C'est 253 000+ pages. Laissez-moi vous dire ce qui se passe quand vous essayez de mettre 91 000 entrées dans un CMS headless traditionnel : le panneau administrateur devient inutilisable, les temps de construction deviennent infinis, et votre facture monte en flèche.

L'architecture

Nous n'utilisons pas generateStaticParams pour 253K pages. Nous utilisons le rendu entièrement dynamique avec mise en cache agressive :

// app/[locale]/celebrity/[slug]/page.tsx
import { createClient } from '@/lib/supabase/server'

export default async function CelebrityPage({ params }: Props) {
  const supabase = await createClient()
  
  const { data: celebrity } = await supabase
    .from('celebrities')
    .select('*, social_profiles(*), net_worth_history(*)')
    .eq('slug', params.slug)
    .eq('locale', params.locale)
    .single()
  
  if (!celebrity) notFound()
  
  return <CelebrityProfile data={celebrity} />
}

export const revalidate = 86400 // Revalider quotidiennement

Temps de construction ? Environ 10 secondes. Les pages sont rendues à la demande et mises en cache à la périphérie. Quand quelqu'un cherche une célébrité que nous n'avons pas servie récemment, la première requête frappe Supabase (généralement 20-50ms depuis la périphérie), rend la page, la met en cache, et chaque visiteur ultérieur reçoit la version mise en cache.

Sécurité au niveau des lignes comme contrôle d'accès

Les politiques RLS de Supabase remplacent ce que vous construiriez normalement dans un CMS administrateur :

CREATE POLICY "Accès en lecture public" ON celebrities
  FOR SELECT USING (status = 'published' AND locale = current_setting('app.locale'));

CREATE POLICY "Accès mise à jour éditeur" ON celebrities
  FOR UPDATE USING (auth.role() = 'editor');

Le problème de l'édition de contenu

Voici l'inconvénient honnête : l'éditeur de tableau de Supabase est correct pour les développeurs, mais ce n'est pas une expérience d'édition de contenu. Nous avons construit des interfaces administrateur personnalisées pour nos équipes éditoriales en utilisant les bibliothèques clientes de Supabase. Si vous ne voulez pas construire votre propre interface administrateur, cette approche n'est pas pour vous.

Supabase Pro s'exécute à 25 $/mois, et même avec 253K pages, nous ne sommes nulle part près des limites de calcul ou de stockage. Comparez cela aux tarifs Contentful ou Sanity à échelle similaire.

Pour nos solutions de développement CMS headless, nous recommandons cette approche pour tout projet au-dessus de 10 000 pages de contenu structuré.

3. Strapi 5 -- Meilleur pour les équipes non techniques

Notre verdict : La meilleure expérience de modélisation du contenu visuel, idéale quand vos éditeurs ne sont pas des développeurs.

Nous avons évalué Strapi 5 en profondeur pour un projet client et avons écrit une comparaison approfondie Payload vs Strapi (qui se classe à la page 1, donc clairement d'autres posent les mêmes questions). Bien que nous ayons finalement opté pour Payload pour ce projet, Strapi a un cas d'usage clair.

Le Content-Type Builder de Strapi 5 permet aux membres non techniques de l'équipe de créer et modifier des structures de contenu via une interface GUI par glisser-déposer. Pas de code. Pas de fichiers de configuration. Pas de déploiements. Votre responsable marketing peut ajouter un type de contenu « témoignage » avec des champs pour la citation, l'auteur, l'entreprise et l'évaluation sans déposer un ticket Jira.

Intégration App Router

Strapi 5 expose les API REST et GraphQL. L'intégration avec App Router est simple mais nécessite des requêtes réseau :

// lib/strapi.ts
export async function getArticles() {
  const res = await fetch(
    `${process.env.STRAPI_URL}/api/articles?populate=*`,
    {
      headers: { Authorization: `Bearer ${process.env.STRAPI_TOKEN}` },
      next: { revalidate: 60 },
    }
  )
  return res.json()
}

Ça fonctionne. Mais comparé à l'API locale de Payload, vous ressentez le décalage d'impédance. Vous sérialisez et désérialisez des données qui auraient pu rester in-process. Les types TypeScript doivent être générés séparément (Strapi a une CLI pour cela, et cela s'est amélioré en v5).

Tarification Strapi 5 (2026)

Plan Prix Sièges Ressources
Community Gratuit (auto-hébergé) Illimité Illimité
Team 29 $/mois/siège 5-20 100GB
Business 99 $/mois/siège Personnalisé 500GB
Enterprise Personnalisé Personnalisé Personnalisé

L'auto-hébergement de Strapi est vraiment gratuit et fonctionne bien. Les plans Cloud ajoutent l'hébergement géré et le support premium.

4. Sanity -- Meilleur pour la collaboration en temps réel

Notre verdict : Meilleure expérience d'édition en temps réel, mais GROQ est un engagement à aimer ou détester.

Nous avons sérieusement évalué Sanity pour le projet DA (91K pages de célébrités) avant d'opter pour Supabase. Sanity Studio est véritablement impressionnant -- c'est une application React que vous pouvez personnaliser jusqu'au niveau du champ. La collaboration en temps réel fonctionne sans faille. Deux éditeurs peuvent travailler sur le même document simultanément, à la façon de Google Docs.

GROQ : Puissant mais polarisant

Sanity utilise GROQ, son propre langage de requête :

*[_type == "article" && slug.current == $slug][0] {
  title,
  body,
  "author": author->{ name, image },
  "categories": categories[]->{ title, slug },
  publishedAt
}

GROQ est en fait élégant une fois que vous l'apprenez. La syntaxe de projection (->) pour résoudre les références est plus agréable que GraphQL pour de nombreux cas d'usage. Mais c'est un autre langage de requête que votre équipe doit apprendre et maintenir. Et quand vous heurtiez des cas limites, la documentation peut sembler mince.

Pourquoi nous n'avons pas choisi Sanity pour DA

À 91 000 documents, les tarifs de Sanity deviennent significatifs. Le plan Growth (15 $/utilisateur/mois) comprend 1M requêtes API CDN. Cela semble beaucoup jusqu'à ce que vous réalisiez qu'un site avec 91K pages générant un trafic décent le dévore rapidement. Nous avons estimé que notre facture mensuelle de Sanity serait de 300-500 $/mois pour DA seul. Supabase Pro à 25 $/mois était une évidence.

Sanity est excellent pour les sites avec 50-5 000 éléments de contenu où plusieurs éditeurs doivent collaborer. Les équipes éditoriales des entreprises médias l'adorent.

5. Contentful -- Meilleur pour l'entreprise (avec budget)

Notre verdict : Le CMS headless le plus mature, mais vous paierez cette maturité.

Contentful existe depuis 2013. C'est le CMS headless auquel les équipes entreprises recourent par défaut, et il y a une raison : la modélisation du contenu est excellente, l'API est rock-solid (SLA 99,99 % sur Premium), et l'écosystème des intégrations est sans égal.

Nous avons évalué Contentful pour plusieurs projets de clients entreprise. Le constructeur de modèles de contenu est poli, l'explorateur d'API dans l'application Web est véritablement utile pour le débogage, et le système de webhooks s'intègre proprement avec la revalidation à la demande de Next.js.

L'étiquette de prix

Plan Prix (2026) Types de contenu Locales Appels API
Free 0 $ 48 2 1M/mois
Basic 300 $/mois 48 6 2M/mois
Premium Personnalisé (généralement 3 000+ $/mois) Illimité Illimité Personnalisé

Le saut de Free à Basic est raide. Le saut de Basic à Premium est une falaise. Si vous êtes une entreprise avec un budget SaaS de 50K+/an, Contentful est un choix sûr. Si vous êtes une startup essayant de maintenir le taux de combustion bas, cherchez ailleurs.

Intégration App Router

Le SDK JavaScript de Contentful fonctionne bien avec les Server Components :

import { createClient } from 'contentful'

const client = createClient({
  space: process.env.CONTENTFUL_SPACE_ID!,
  accessToken: process.env.CONTENTFUL_ACCESS_TOKEN!,
})

export async function getPage(slug: string) {
  const entries = await client.getEntries({
    content_type: 'page',
    'fields.slug': slug,
    include: 3,
  })
  return entries.items[0]
}

Le SDK est bien maintenu et entièrement typé avec contentful-typescript-codegen. Aucune plainte sur le front de l'expérience développeur.

6. Markdown/MDX -- Meilleur pour les blogs de développeurs

Notre verdict : Zéro surcharge, contrôle maximum, workflows Git-natifs.

Ce site -- socialanimal.dev -- s'exécute sur MDX. Chaque article est un fichier dans le dépôt avec des métadonnées frontmatter :

---
title: "Meilleur CMS pour Next.js App Router 2026"
slug: "best-cms-nextjs-app-router-2026"
category: "Resources"
tags: ["nextjs", "cms", "payload", "supabase"]
publishedAt: "2026-01-15"
---

J'expédie des sites Next.js depuis l'époque du Pages Router...

Avec @next/mdx ou contentlayer2 (le fork communautaire), MDX s'intègre nativement au App Router. Votre contenu EST votre base de code. Contrôle de version, branches, critiques de demandes de tirage -- tous les workflows que vous connaissez déjà.

Quand MDX s'effondre

Les non-développeurs ne peuvent pas l'utiliser. Point final. Si votre équipe marketing doit publier des billets de blog, MDX signifie qu'ils apprennent soit Git, soit vous construisez une interface d'édition (auquel cas, utilisez simplement Payload).

MDX ne s'échelle pas non plus bien à des milliers de pages. À environ 500+ fichiers MDX, les temps de construction commencent à traîner et votre IDE ralentit. Pour un blog d'entreprise ou un site de documentation, c'est parfait. Pour une plateforme de contenu, ce n'est pas.

Pour notre travail de développement Astro, nous utilisons MDX encore plus largement puisque les collections de contenu d'Astro offrent une excellente sécurité de type pour le contenu Markdown/MDX.

Comparaison des métriques de production

Voici les données de nos déploiements et évaluations réels en production :

CMS Pages en production Langues Temps de construction Coût mensuel Notre verdict
Payload 3 228 (SleepDr) 1 ~45s 35 $ (Payload Cloud) Meilleure UX pour Next.js
Supabase 253K (DA+NAS+HostList) 30 ~10s 25 $ (plan Pro) Meilleur pour la mise à l'échelle
Strapi 5 0 (évalué) N/A N/A Gratuit (auto-hébergé) Meilleur pour les éditeurs GUI
Sanity 0 (évalué) N/A N/A ~300-500 $ estimé Meilleur pour la collaboration
Contentful 0 (évalué) N/A N/A 300+ $ (Basic) Meilleur pour l'entreprise
MDX ~60 (ce site) 1 ~30s 0 $ Meilleur pour les blogs de dev

La colonne du temps de construction mérite une explication. Payload à 45 secondes comprend la génération de 228 pages statiques. Supabase à 10 secondes est parce que nous ne générons pas statiquement 253K pages -- nous utilisons le rendu dynamique avec ISR. MDX à 30 secondes est pour ~60 articles avec la coloration syntaxique et l'optimisation des images.

Cadre de décision : Comment choisir votre CMS

Oubliez les listes de contrôle des fonctionnalités. Répondez à ces quatre questions :

1. Qui édite le contenu ?

  • Seulement les développeurs → MDX ou Payload
  • Développeurs + éditeurs techniques → Payload ou Sanity
  • Équipe marketing non technique → Strapi ou Contentful

2. Combien de pages ?

  • Moins de 500 → N'importe quel CMS fonctionne. Choisissez en fonction de l'UX de l'éditeur.
  • 500-5 000 → Payload ou Sanity. Les deux gèrent bien cette gamme.
  • 5 000-50 000 → Supabase ou Contentful (avec budget).
  • 50 000+ → Supabase. Rien d'autre n'a de sens économiquement.

3. Quel est votre budget mensuel CMS ?

  • 0 $ → Payload auto-hébergé, Strapi auto-hébergé, ou MDX
  • 25-50 $ → Supabase Pro ou Payload Cloud
  • 100-500 $ → Sanity Growth ou Strapi Cloud
  • 500+ $ → Contentful ou Sanity Enterprise

4. Avez-vous besoin de collaboration en temps réel ?

  • Oui, critique → Sanity (meilleure de sa catégorie)
  • Sympa à avoir → Payload (l'aperçu en direct est proche)
  • N'importe quoi d'autre

Ce que nous ferions différemment

La rétrospection est précieuse. Voici ce que nous changerions :

Nous aurions commencé avec Payload plus tôt. Nous avons construit certains projets précoces avec des panneaux administrateur personnalisés en haut de Supabase avant que Payload 3 ne mûrisse. Pour les sites de moins de 5K pages, Payload aurait économisé un temps considérable de développement d'interface administrateur.

Nous aurions normalisé nos modèles Supabase-as-CMS plus tôt. Chacun de nos trois projets Supabase a des conventions légèrement différentes pour la modélisation du contenu, la mise en cache et la revalidation. Nous avons depuis créé un modèle interne que nous utilisons pour tous les nouveaux projets à grand volume.

Nous aurions ignoré l'évaluation Contentful pour les clients non entreprise. La falaise des tarifs est réelle, et à deux reprises, nous avons passé des évaluations de plusieurs semaines pour réaliser que le budget du client ne correspondait pas aux tarifs de Contentful. Nous aurions dû poser des questions sur le budget d'abord.

Si vous faites face à une décision CMS similaire pour un projet Next.js, nous serions heureux de partager plus de détails sur notre expérience. Consultez notre page tarification ou contactez-nous directement -- nous faisons ça tous les jours.

FAQ

Quel est le meilleur CMS headless pour Next.js en 2026 ?

Basé sur notre expérience en production sur 253K+ pages, Payload CMS 3 est le meilleur choix global pour Next.js App Router. Son API locale élimine la surcharge réseau, les types TypeScript sont générés automatiquement, et le panneau administrateur vit à l'intérieur de votre application Next.js. Pour les sites dépassant 10 000 pages, nous recommandons Supabase comme couche CMS avec une interface administrateur personnalisée.

Payload CMS est-il vraiment gratuit ?

Payload CMS est open-source et gratuit à auto-héberger sans restrictions de fonctionnalités. Vous devrez fournir votre propre hébergement et base de données (MongoDB ou PostgreSQL). Payload Cloud, leur service d'hébergement géré, commence à environ 35 $/mois pour les charges de travail de production en 2026. Il n'y a pas de frais par siège sur la version auto-hébergée.

Puis-je utiliser Supabase comme CMS pour Next.js ?

Oui, et nous le faisons à l'échelle. Nous exécutons trois sites de production totalisant 253 000+ pages sur Supabase. Cela fonctionne exceptionnellement bien quand votre contenu est des données structurées (profils, annonces, catalogues de produits) plutôt que du contenu éditorial long-forme. Le principal compromis est que vous devrez construire votre propre interface d'édition de contenu -- l'éditeur de tableau de Supabase n'est pas conçu pour les workflows éditoriaux.

Comment Strapi 5 se compare-t-il à Payload CMS 3 pour Next.js ?

Strapi 5 excelle à l'édition de contenu non technique avec son Content-Type Builder visuel. Payload 3 excelle à l'expérience développeur avec son API locale et l'approche native TypeScript. Si vos éditeurs sont des développeurs, choisissez Payload. Si vos éditeurs sont des responsables marketing, choisissez Strapi. Nous avons écrit une comparaison approfondie Payload vs Strapi couvrant ce sujet en profondeur.

Quel est le CMS headless le moins cher pour Next.js ?

Payload CMS auto-hébergé et Strapi auto-hébergé sont tous deux vraiment gratuits. Les fichiers MDX dans un dépôt Git ne coûtent rien au-delà de votre hébergement. Pour les services gérés, Supabase Pro à 25 $/mois offre la meilleure valeur à l'échelle -- nous servons 253K pages sur un seul plan Pro. Le niveau gratuit de Sanity est également généreux pour les petits projets (jusqu'à 3 utilisateurs, 500K requêtes API/mois).

Contentful en vaut-il la peine pour les projets Next.js ?

Contentful en vaut la peine si vous êtes une équipe entreprise qui a besoin d'un SLA 99,99 %, d'intégrations établies avec des outils comme Commercetools ou Salesforce, et que vous avez le budget (300+ $/mois pour Basic, 3 000+ $/mois pour Premium). Pour les startups et les entreprises de taille moyenne, Payload ou Sanity offrent des fonctionnalités comparables à une fraction du coût.

Dois-je utiliser ISR ou SSR avec un CMS headless dans Next.js App Router ?

Cela dépend de votre nombre de pages et de la fréquence de mise à jour du contenu. Pour les sites de moins de 5 000 pages, la génération statique avec revalidation à la demande via webhooks est idéale. Pour 5 000+ pages, le rendu dynamique avec ISR (revalidate = 3600 ou similaire) est plus pratique -- vous ne pouvez pas construire 50K pages à chaque déploiement. Avec l'API locale de Payload, la distinction importe moins car il n'y a pas de surcharge réseau de toute façon.

Puis-je migrer de WordPress vers un CMS headless pour Next.js ?

Absolument. Nous avons effectué plusieurs migrations WordPress. Le chemin typique est : exporter le contenu WordPress via l'API REST ou WP-CLI, transformer et importer dans votre CMS cible, puis reconstruire le frontend dans Next.js. Payload CMS rend cela particulièrement lisse car vous pouvez modéliser vos collections pour correspondre à vos types de publication WordPress existants. Pour plus de détails sur ce processus, consultez nos solutions de développement CMS headless.