Si vous avez réduit votre choix de CMS headless à Sanity par rapport à la foule Payload-ou-Storyblok, vous avez déjà éliminé 80 % du bruit que le reste de cette catégorie génère. La décision restante est celle qui compte vraiment : optimisez-vous l'expérience de l'équipe éditoriale, ou la propriété de l'équipe d'ingénierie ? Posez bien cette question et le reste du choix s'impose de lui-même.
Sanity est la réponse quand l'équipe éditoriale est la protagoniste. Après avoir exécuté plus de 12 000 builds clients chez Seahawk Media et livré une poignée directement sur Sanity au cours des 18 derniers mois, voici l'analyse honnête sur où il gagne, où Payload le surpasse, et où Storyblok domine. Tarification, capacités, chemin de migration, et les compromis que personne sur les pages de vente des éditeurs ne vous dira.
Ce que Sanity est vraiment en 2026
Sanity est un CMS headless hébergé où vous écrivez le schéma en TypeScript ou JavaScript, exécutez une application admin personnalisable basée sur React appelée Sanity Studio (généralement déployée sur votre propre domaine), et interrogez le contenu via GROQ — un langage de requête de style graphe qui ressemble à GraphQL mais est plus expressif sur les relations entre documents. Le contenu est en temps réel entre les éditeurs dès le départ : deux éditeurs dans le même document voient les positions des curseurs de l'autre en direct, comme dans Figma.
La plateforme est mature : Sanity v3 est la version majeure stable depuis deux ans, Studio est vraiment personnalisable jusqu'aux composants d'entrée unique, et la Live Content API diffuse les changements de document à votre front-end sans interrogation. Sanity est l'un des rares choix de CMS headless en 2026 qui ne donne pas l'impression d'être un produit en phase précoce un mardi après-midi.
Tarification Sanity en 2026 — la vraie courbe des coûts
Trois plans. L'offre gratuite semble généreuse jusqu'à ce que vous heurtiez les limites strictes ; le plan Growth démarre à 15 $ par utilisateur par mois ; Enterprise est sur mesure et commence là où le plan Growth cesse de s'adapter.
Plan gratuit
- 0 $/mois, 20 utilisateurs inclus sans dépassement autorisé.
- Limité aux rôles Administrator et Viewer — pas de rôles Editor, Developer ou Contributor.
- Limites strictes sur les documents, les actifs, les requêtes API, la bande passante CDN. Si vous atteignez un quota, la fonctionnalité affectée est bloquée jusqu'à la réinitialisation du quota ou la mise à niveau.
- Réaliste pour : les prototypes, les outils internes ou les sites de contenu avec moins de 5 000 documents et une petite équipe éditoriale.
Plan Growth
- 15 $ par utilisateur par mois, jusqu'à 50 utilisateurs.
- Les cinq rôles déverrouillés : Admin, Viewer, Editor, Developer, Contributor.
- 250 000 requêtes API par mois incluses, 1 million de requêtes CDN API, avec un modèle à l'usage au-delà de cela.
- Limite stricte de 25 000 documents — pas de facturation à l'usage au-delà de cette limite sur Growth, vous devez passer à Enterprise.
- Brouillons planifiés, fonctionnalités de collaboration, authentification unique si vous ajoutez le module SSO (plus de détails ci-dessous).
- Réaliste pour : la plupart des sites de contenu en production avec 1 à 10 éditeurs et moins de 25 000 documents.
Plan Enterprise
- Tarification personnalisée, gérée par l'équipe commerciale.
- Limites de documents plus élevées, rétention personnalisée, sécurité avancée, support dédié, performance garantie par SLA.
- Réaliste pour : sites avec 50 000 documents et plus, secteurs réglementés, entreprises avec exigences d'approvisionnement.
Le module SSO qui rend Growth plus cher qu'il n'y paraît
SAML SSO sur le plan Growth est un module complémentaire à 1 399 $ par mois. Pour une équipe de 5 utilisateurs qui paie par ailleurs 75 $ par mois, ajouter SSO multiplie le coût par 19. Si votre politique de sécurité exige SSO dès le départ, le plan Growth n'est pas rentable et vous êtes effectivement à des tarifs Enterprise sans l'ensemble des fonctionnalités Enterprise. À savoir avant de vous engager.
Où Sanity gagne (et le type de brief qui le choisit)
Édition en temps réel sur des équipes distribuées
Le modèle de collaboration de Sanity est ce qui se rapproche le plus dans un CMS headless du travail dans un Google Doc. Deux éditeurs dans le même document voient les curseurs l'un de l'autre. Les commentaires s'enchaînent sur les champs individuels. La présence des documents est visible dans la navigation. Pour les équipes de marque, les équipes de content marketing, et toute personne où deux ou plusieurs personnes touchent régulièrement le même document dans la même heure, c'est une fonctionnalité véritablement catégorique.
Personnalisation du schéma qui ne ressemble pas à un modèle CMS
Studio est une application React que vous déployez. Des composants d'entrée personnalisés, des aperçus personnalisés, des boutons de flux de travail personnalisés, une validation personnalisée, des pipelines d'assets personnalisés — tout se trouve dans votre repo. Si votre équipe éditoriale a des besoins spécifiques (un sélecteur de date et fuseau horaire personnalisé qui rejette les jours fériés, un champ slug qui valide par rapport à une liste de concurrents, une interface de recadrage d'image personnalisée), Sanity Studio est le seul CMS headless où vous pouvez le construire sans combattre la plateforme.
GROQ en tant que langage de requête
GROQ est plus expressif que GraphQL pour les requêtes sur graphe de documents. Vous pouvez joindre à travers des références, projeter des champs imbriqués, filtrer sur des valeurs calculées, et découper des listes en une seule requête. Le compromis est que GROQ est spécifique à Sanity — vous ne pouvez pas prendre vos requêtes ailleurs. Pour les équipes qui livrent des surfaces de contenu complexes (annuaires à facettes, widgets de contenu connexe, chaînes de secours multi-locale), GROQ est plus rapide à écrire et plus rapide à itérer que la requête GraphQL équivalente plus la logique front-end.
Édition visuelle sur les front-ends Next.js
La fonctionnalité Visual Editing de Sanity, généralement disponible depuis 2025, permet aux éditeurs de cliquer directement sur une page Next.js ou Nuxt en mode aperçu et d'éditer le champ sous-jacent dans Studio. C'est l'histoire d'édition visuelle la plus épurée dans l'espace CMS headless en dehors de Storyblok. Si votre flux de travail éditorial est dominé par un aperçu préalable, c'est un vrai gain de productivité.
Où Payload dépasse Sanity
Payload est le bon choix quand l'équipe d'ingénierie est au cœur du projet et que l'équipe éditoriale peut être intégrée à une interface d'administration un peu plus orientée développeur.
Des schémas TypeScript-first comme source canonique
Les schémas Payload vivent dans vos fichiers TypeScript aux côtés de votre code applicatif. La sécurité des types est de bout en bout : le schéma, le client API et votre app Next.js partagent tous les mêmes types sans étapes de génération de code. Le schéma de Sanity est aussi défini en code, mais le flux de génération de types est plus complexe et l'histoire TypeScript est moins native.
Auto-hébergé, votre base de données Postgres, votre bucket S3
Payload est la meilleure solution quand la propriété des données est non-négociable. Le CMS s'exécute sur votre infrastructure, la base de données est votre instance Postgres ou MongoDB, les assets se trouvent dans votre bucket S3 (ou compatible). Sanity stocke les documents sur l'infrastructure hébergée de Sanity — acceptable pour la plupart des équipes, rédhibitoire pour les secteurs réglementés ou toute équipe ayant une politique « pas de stockage de données tiers ».
API locale sans surcharge HTTP
L'API locale de Payload vous permet d'appeler les fonctions du CMS directement depuis votre code Next.js sans requête HTTP. Pour les apps étroitement intégrées où le CMS n'est qu'une des plusieurs sources de données, cela performe mesurément mieux que le modèle d'accès réseau uniquement de Sanity.
J'ai couvert la décision Payload-versus-Strapi en profondeur ici : Payload vs Strapi in 2026. La version courte a la même forme : Payload pour les équipes lourdement orientées TypeScript qui veulent la propriété, Strapi pour les équipes qui veulent un écosystème de plugins plus riche.Payload vs Strapi in 2026. The short version is the same shape: Payload for TypeScript-heavy teams that want ownership, Strapi for teams that want a richer plugin ecosystem.
Où Storyblok surpasse Sanity (un cas spécifique)
Storyblok surpasse Sanity sur une seule dimension et une seule : l'éditeur visuel pour les équipes marketing qui veulent mettre en page des pages composant par composant sans toucher au code. Le Visual Editor de Storyblok permet à un responsable marketing non-technique de construire un hero, un hero-with-cta, une disposition trois-colonnes-feature-grid à partir de blocs de composants prédéfinis et de voir l'aperçu en direct au fur et à mesure. Sanity Visual Editing est bon mais n'est pas conçu autour de la même persona.
Si votre équipe éditoriale est dominée par des utilisateurs non-techniques orientés marketing qui veulent assembler des pages, Storyblok est le bon choix. Si votre équipe éditoriale est centrée sur le contenu (rédacteurs, éditeurs, journalistes, gestionnaires de connaissances), l'éditeur orienté documents de Sanity offre une meilleure expérience.
Migration vers Sanity : le chemin réaliste
Depuis WordPress
Modèle standard : exporter le contenu WordPress via WP All Export, transformer au format de document NDJSON de Sanity, importer via la Sanity CLI. Le mappage de schéma est le travail — pages, articles, types de publication personnalisés, champs ACF ont tous besoin d'un équivalent Sanity. Le guide de migration WordPress vers Next.js couvre la partie transport SEO qui s'applique quel que soit la cible CMS. Temps sur un site de 5 000 pages : 4 à 8 semaines de travail concentré pour la migration seule, plus longtemps si le schéma inclut du contenu relationnel complexe.The WordPress to Next.js migration playbook covers the SEO transport side that applies regardless of CMS target. Time on a 5,000-page site: 4 to 8 weeks of focused work for the migration alone, longer if the schema includes complex relational content.
Depuis Contentful
Plus facile que WordPress car le modèle de contenu de Contentful se mappe proprement à la structure document-et-référence de Sanity. Les outils de migration Sanity ont des importeurs dédiés pour les exports Contentful. Calendrier réaliste sur un site de taille similaire : 2 à 4 semaines.
Depuis Drupal
Le plus difficile des trois car le modèle entité-et-bundle de Drupal est structurellement différent. La plupart des équipes finissent par reconstruire le schéma de zéro dans Sanity plutôt que de faire une auto-migration. 6 à 12 semaines pour un site Drupal multi-langue complexe.
FAQ
Sanity est-il conforme à HIPAA ?
Sanity ne publie pas de Business Associate Agreement HIPAA sur son plan Growth, donc d'emblée Sanity n'est pas éligible à HIPAA pour stocker PHI. Les clients Enterprise ayant des workflows healthcare peuvent négocier un accord de traitement de données personnalisé, mais ce n'est pas la valeur par défaut. Si votre application healthcare a besoin d'un CMS qui stocke PHI directement, Supabase avec l'add-on HIPAA ou un déploiement Payload auto-hébergé sur un host éligible à HIPAA est un chemin plus défendable.
Sanity est-il meilleur que Contentful ?
Pour la plupart des équipes en 2026, oui — Sanity offre plus de flexibilité de schéma, une meilleure collaboration en temps réel, un langage de requête plus capable (GROQ), et un prix significativement plus bas pour des ensembles de fonctionnalités équivalents. La force de Contentful est l'approvisionnement enterprise et les intégrations avec les stacks marketing legacy. Si votre équipe est technique et le workflow éditorial est la priorité, Sanity est le meilleur choix. Si vos stakeholders exigent un contrat enterprise compatible avec l'approvisionnement, Contentful est le choix plus sûr.
Combien coûte Sanity pour une équipe de 5 personnes ?
Sur le plan Growth, 75 $ par mois pour 5 sièges à 15 $ par siège. Si vous avez besoin de SAML SSO, ajoutez 1 399 $ par mois — ce qui porte la même équipe à 1 474 $ mensuels. Le plan gratuit couvre 20 sièges avec des limites strictes, donc si votre équipe est petite et votre utilisation est basse, la tier gratuit peut vous couvrir la première année.
Puis-je utiliser Sanity avec Next.js ?
Oui — Next.js est le front end le plus courant pour Sanity en 2026. Le package officiel @sanity/client gère les appels API, les requêtes GROQ s'exécutent côté serveur dans Server Components ou via des routes API, et Visual Editing est supporté en mode preview. Sanity a un template starter Next.js maintenu ; le cloner est le moyen le plus rapide d'accéder à un projet fonctionnel.
Qu'est-ce que GROQ et pourquoi c'est important ?
GROQ est le langage de requête de contenu de Sanity — un langage de requête en forme de graphe, basé sur la projection et conçu pour les types de jointures et filtres dont le contenu CMS headless a besoin. Il est plus expressif que GraphQL pour les requêtes de graphe de documents. Le côté négatif est que GROQ est spécifique à Sanity, donc une migration future hors de Sanity signifie réécrire chaque requête. Pour la plupart des équipes, le gain de productivité à court terme l'emporte sur le risque de verrouillage.
Lectures associées
Les alternatives à WordPress en 2026 : quand le no-code n'est pas la réponse — le post parent sur les alternatives de stack, incluant la section sur les choix de CMS headless. — the parent post on stack alternatives, including the section on headless CMS choices.
Migration de WordPress vers Next.js sans perdre votre classement — s'applique que votre CMS cible soit Sanity, Payload ou n'importe quoi d'autre. Le transport SEO est le même quel que soit le CMS. — applies whether your CMS target is Sanity, Payload, or anything else. The SEO transport is the same regardless of CMS.
Avantages et inconvénients de l'architecture headless — les vrais compromis du modèle headless lui-même, utile comme prélude au cadre décisionnel. — honest tradeoffs of the headless model itself, useful as the decision framework prequel.
WordPress Stack Advisor — collez votre URL, recevez une recommandation sur mesure qui inclut si Sanity est le bon CMS pour votre brief spécifique. — paste your URL, get a tailored recommendation that includes whether Sanity is the right CMS for your specific brief.
Le choix du CMS n'est rarement le goulot d'étranglement. Le goulot d'étranglement, c'est le premier mois de l'équipe éditoriale sur le nouvel outil. Choisissez Sanity si votre équipe éditoriale est enthousiaste ; choisissez Payload si votre équipe d'ingénierie l'est.
Réservez un appel de 30 minutes pour le choix du CMS — décrivez le brief, l'équipe, la chronologie, les intégrations, et repartez avec une décision Sanity-vs-Payload-vs-Storyblok honnête sur les compromis. — describe the brief, the team, the timeline, the integrations, and walk away with a Sanity-vs-Payload-vs-Storyblok decision that is honest about the trade-offs.