CMS & Headless Architecture Decision Framework
Framework pour choisir le bon CMS (ou combinaison de CMS) selon un brief client. À lire avant de recommander ou partir sur une stack particulière.
Principe directeur
Il n'y a pas de "meilleur CMS" — il y a le bon CMS pour un contexte spécifique. Le rôle de Claude Code est de mapper le brief à la bonne plateforme, pas de pousser un favori.
Les 7 plateformes couvertes par atum-cms-ecom
| Plateforme | Type | Orientation | Hosting | Open source ? |
|---|
| WordPress | CMS monolithe | Publishing + tout-terrain | Self-hosted ou WP Engine / Kinsta | OSS (GPL) |
| Shopify | E-commerce SaaS | Commerce pur | SaaS Shopify | Propriétaire |
| Sanity | Headless CMS | Publishing + content ops | SaaS Sanity (Content Lake) | OSS (Studio) + SaaS (backend) |
| Strapi | Headless CMS | Custom apps backend | Self-hosted ou Strapi Cloud | OSS (MIT) |
| Payload | Headless CMS + Next.js | TypeScript full-stack | Self-hosted ou Payload Cloud | OSS (MIT) |
| Webflow | Visual CMS | Marketing sites + design-first | SaaS Webflow (native hosting) | Propriétaire |
| Ghost | Publishing platform | Newsletters + memberships | Self-hosted ou Ghost(Pro) | OSS (MIT) |
Matrice de décision (12 critères)
1. Content modeling flexibility
| Plateforme | Score | Note |
|---|
| Sanity | ★★★★★ | Le plus flexible (GROQ + references + PT) |
| Payload | ★★★★★ | TypeScript-first, très riche |
| Strapi | ★★★★ | Content-Type Builder + components |
| WordPress | ★★★ | ACF flexible mais hooks lourds |
| Ghost | ★★ | Limité à posts, pages, tags, authors |
| Shopify | ★★ | Metaobjects + metafields récents mais encore limités |
| Webflow | ★★ | 10k items/collection, pas de imbrication profonde |
2. Editor experience (UX merchant/éditeur)
| Plateforme | Score | Note |
|---|
| Webflow | ★★★★★ | Best visual editing UX |
| Shopify | ★★★★★ | Admin ultra-poli pour merchants |
| Sanity | ★★★★ | Studio customisable, Presentation tool excellent |
| WordPress | ★★★★ | Gutenberg + ACF Pro |
| Ghost | ★★★★ | Éditeur minimal mais parfait pour du publishing |
| Payload | ★★★ | Admin UI correct, demande customisation pour être user-friendly |
| Strapi | ★★★ | Admin UI fonctionnel mais peu ergonomique out-of-the-box |
3. Developer experience (DX)
| Plateforme | Score | Note |
|---|
| Payload | ★★★★★ | TypeScript end-to-end, config-as-code |
| Sanity | ★★★★★ | GROQ + TypeGen + Live Content API |
| Strapi | ★★★★ | Node.js, plugins clairs |
| Shopify | ★★★★ | Hydrogen + GraphQL + CLI excellent |
| WordPress | ★★★ | Écosystème riche mais PHP legacy |
| Ghost | ★★★ | Simple à comprendre, limité |
| Webflow | ★★ | DevLink aide, mais le cœur reste visuel |
4. Pricing model
| Plateforme | Model | Coût indicatif |
|---|
| WordPress | Self-hosted = hosting only | 10-100 €/mo |
| Ghost | Self-hosted ou Ghost(Pro) | Ghost(Pro) 9-249 $/mo |
| Strapi | Self-hosted ou Strapi Cloud | Cloud 15-750 $/mo |
| Payload | Self-hosted ou Payload Cloud | Cloud 35-135 $/mo |
| Sanity | Free tier généreux + usage-based | Free → 99 $/mo → Enterprise |
| Webflow | SaaS par plan | Site 23-235 $/mo, Workspace 19-60 $/seat/mo |
| Shopify | SaaS par plan + commission | 39-399 $/mo + fees, Plus 2000+ $/mo |
5. Hosting
| Plateforme | Options |
|---|
| WordPress | Self-host everywhere, WP Engine, Kinsta, Flywheel, Pressable |
| Shopify | Shopify managed (pas d'alternative sauf Hydrogen sur Oxygen) |
| Sanity | Sanity Cloud (Content Lake) — pas self-hostable |
| Strapi | Self-hosted (VPS, Railway, Fly, Render, AWS) ou Strapi Cloud |
| Payload | Self-hosted (Vercel, Railway, Fly, Render) ou Payload Cloud |
| Webflow | Webflow native hosting only |
| Ghost | Self-host (VPS, Docker) ou Ghost(Pro) |
6. i18n (multi-langue)
| Plateforme | Support |
|---|
| Sanity | Document-level ou field-level, plugin @sanity/document-internationalization |
| Strapi | Plugin natif @strapi/plugin-i18n, excellent |
| Payload | Natif via localized: true, config locales: [] |
| Shopify | Markets + Shopify Translate & Adapt (natif) |
| WordPress | WPML ou Polylang (payants / semi-payants) |
| Webflow | Localization natif (2024+), assez jeune |
| Ghost | Pas de natif, workaround via tags |
7. Multi-currency
| Plateforme | Support |
|---|
| Shopify | ★★★★★ Natif, Markets |
| Webflow | ★★ Limité (1 currency par site) |
| Autres | ★ Pas de feature native — à coder dans le frontend |
8. E-commerce
| Plateforme | Support e-com |
|---|
| Shopify | ★★★★★ Le meilleur (pensé pour ça) |
| WordPress + WooCommerce | ★★★★ Très flexible, plus bricolé |
| Webflow Ecommerce | ★★★ Simple, plafonnement rapide |
| Sanity/Payload/Strapi | ★★ Pas e-com natif, intégrer Stripe + Checkout custom |
| Ghost | ★ Uniquement memberships, pas produits |
9. API maturity
| Plateforme | API |
|---|
| Shopify | GraphQL Admin + Storefront + Customer Account + Functions + Webhooks — très riche |
| Sanity | GROQ + Live Content API + Presentation tool |
| Strapi | REST + GraphQL + Document Service API (v5) |
| Payload | REST + GraphQL auto-générés depuis la config |
| WordPress | REST API + GraphQL via plugin (WPGraphQL) |
| Ghost | Content API (read) + Admin API (write) |
| Webflow | Data API v2 + Designer API + Webhooks |
10. Migration effort
| Migration depuis → vers | Difficulté |
|---|
| WordPress → Ghost | Moyen (plugin officiel) |
| WordPress → Sanity | Difficile (HTML → Portable Text) |
| Medium / Substack → Ghost | Facile (import natif) |
| Shopify → autre | Très difficile (theming + app ecosystem) |
| Webflow → Sanity | Moyen (Data API + script custom) |
| Sanity → Strapi/Payload | Difficile (GROQ → REST, schema rewrite) |
11. Team size fit
| Plateforme | Sweet spot |
|---|
| Ghost | 1-3 éditeurs, focus publishing |
| WordPress | 1-20 éditeurs, plugins = gestion de drame |
| Shopify | E-commerce team 1-50 |
| Webflow | 1-5 designers + marketing |
| Sanity | 3-30 éditeurs + dev team |
| Strapi / Payload | Dev team 2+, projet custom avec admin |
12. Vendor lock-in
| Plateforme | Lock-in |
|---|
| Shopify | ★★★★★ Très fort (theming + apps propriétaires) |
| Webflow | ★★★★★ Très fort (Designer export limité) |
| WordPress | ★ Très faible (self-host + SQL export) |
| Strapi / Payload / Ghost | ★ Très faible (open source + code-first ou Handlebars) |
| Sanity | ★★ Content Lake propriétaire mais export JSON complet |
Arbres de décision par type de brief
Brief : Site vitrine marketing (SME, 5-20 pages)
Besoin d'éditeurs non-techniques ?
├── OUI → Webflow (DX client max, pas de code)
└── NON → Sanity + Next.js (DX dev max, i18n, SEO)
Brief : Blog + newsletter payante
Budget self-host ?
├── OUI → Ghost self-hosted (MySQL + Node + Nginx)
└── NON → Ghost(Pro) 9 $/mo starter
Brief : E-commerce B2C 100-1000 SKUs
Besoin multi-currency ?
├── OUI → Shopify + Hydrogen (si frontend custom)
└── NON →
├── WordPress + WooCommerce (budget serré, contrôle total)
└── Shopify Basic (simplicité)
Brief : E-commerce B2B ou marketplace
Shopify Plus → oui si budget > 2k$/mo et besoin scale
Sinon → Saleor (non couvert par ce plugin) ou Medusa ou custom Payload + Stripe
Brief : Site éditorial multi-langue avec 10+ auteurs
→ Sanity + Next.js
- i18n document-level
- Studio multi-éditeur avec workflow
- Visual editing via Presentation
- Portable Text pour la richesse éditoriale
Brief : App SaaS interne avec admin lourd
Besoin Admin UI custom ?
├── OUI → Payload (TypeScript, admin customisable, hooks riches)
└── NON → Strapi (Content-Type Builder, rapide à mettre en place)
Brief : Site marketing + e-commerce + blog
→ Shopify (commerce) + Sanity (content) en composable commerce
- Shopify pour products, cart, checkout
- Sanity pour pages marketing, blog, CMS éditorial
- Hydrogen ou Next.js qui agrège les deux APIs
Anti-patterns de choix CMS
- WordPress par défaut sans évaluer les alternatives — souvent un choix par familiarité plutôt que par fit
- Shopify pour un site sans commerce — overkill et coût mensuel injustifié
- Sanity/Payload pour un site simple de 5 pages — le coût dev dépasse la valeur
- Webflow pour un SaaS complexe — plafonnement rapide sur les workflows
- Ghost pour un CMS généraliste — trop limité hors publishing
- Strapi pour un merchant qui ne code pas — admin UI pas merchant-friendly out-of-the-box
- Multi-CMS (Shopify + Sanity) sur un petit budget — complexité d'intégration > valeur
Process de recommandation
Quand un utilisateur demande "quel CMS choisir ?", suivre ces étapes :
- Identifier le type de projet — vitrine, blog, e-commerce, SaaS, éditorial, marketplace, etc.
- Lister les contraintes hard — budget, hosting, team, langues, currencies
- Lister les besoins soft — DX, editor UX, customisation
- Matcher au tableau ci-dessus — choisir 2-3 plateformes candidates
- Arbitrer via les arbres de décision
- Expliciter les trade-offs — aucune plateforme n'est parfaite, expliquer ce qu'on sacrifie
- Proposer un plan B — si le choix se révèle mauvais à 6 mois, quelle est la migration possible ?
Quand utiliser ce skill
- Brief client ambigu sur la stack
- Demande de comparaison entre 2+ CMS
- Migration envisagée
- Choix multi-CMS (composable commerce)
- Review d'une stack existante
- Briefing d'un nouveau projet agence
Commande associée
Le slash command /cms-compare (dans ce plugin) applique ce framework à un brief spécifique et produit une recommandation argumentée en 1-2 paragraphes.