Guide Sanity CMS : comment nous publions en 10 langues

Guide Sanity CMS : comment nous publions en 10 langues

Nous avons publié plus de 400 contenus sur 4 sites et 10 langues via Sanity CMS. Voici ce que nous avons appris — de la conception des schémas à la publication multilingue automatisée.

Sanity CMS est une plateforme de contenu headless bâtie sur du contenu structuré, un Content Lake en temps réel et un éditeur React personnalisable appelé Sanity Studio. Il utilise GROQ pour les requêtes, le Portable Text pour le contenu riche, et les schémas en code pour la modélisation du contenu. Ce guide couvre l'installation, la conception des schémas, GROQ, le Portable Text, l'architecture multilingue et les tarifs.

Qu'est-ce que Sanity CMS ?

Sanity est une plateforme de contenu structuré — ce que l'équipe de Sanity.io appelle un « système d'exploitation pour le contenu ». Contrairement aux CMS traditionnels qui stockent des blobs HTML dans une base de données, Sanity enregistre chaque élément de contenu sous forme de JSON structuré dans un backend géré appelé le Content Lake. Vous l'interrogez avec GROQ ou GraphQL, et vous rendez le contenu dans n'importe quel frontend : Next.js, React Native, Svelte, une application mobile, un outil CLI — tout ce que vous voulez.

Les entreprises qui l'utilisent couvrent tout le spectre. Nike, Figma, Puma et Cloudflare font tourner Sanity à l'échelle enterprise. Les startups l'adoptent parce que l'offre gratuite est vraiment utilisable en production (on en parle dans la section tarifs). Nous l'utilisons parce qu'aucun autre outil ne nous a donné la flexibilité nécessaire pour construire un pipeline de publication automatisé en 10 langues.

Architecture du Content Lake

Le Content Lake est le backend géré de Sanity. Imaginez un document store hébergé qui se synchronise en temps réel sur tous les clients connectés. Quand un éditeur modifie un paragraphe dans Sanity Studio, un autre éditeur le voit instantanément — pas de bouton de sauvegarde, pas de conflits de fusion, pas de migrations de base de données.

Sous le capot, les documents sont stockés sous forme de JSON structuré avec des champs typés. Chaque mutation est tracée via un journal de transactions, ce qui vous donne un historique complet des versions par défaut. La synchronisation temps réel repose sur une architecture par listeners (décrite dans les docs architecture de Sanity sur GitHub) qui pousse les changements vers tous les abonnés via des observables RxJS.

En quoi cela diffère-t-il d'une base PostgreSQL avec une API REST ? Le Content Lake gère la modélisation du contenu, le contrôle d'accès, le cache CDN, les transformations d'images et la collaboration en temps réel comme un seul service géré. Vous ne lancez pas de migrations. Vous ne gérez pas de réplicas. Vous définissez des schémas et interrogez votre contenu.

Sanity Studio : votre éditeur sur mesure

Sanity Studio est une application React open source qui sert d'interface d'édition. Ce n'est pas un panneau d'administration hébergé — c'est une application React qui vit dans votre codebase. Vous pouvez en personnaliser chaque aspect : composants d'entrée personnalisés, champs conditionnels, actions sur les documents, patterns Structure Builder et plugins.

La collaboration en temps réel est intégrée. Plusieurs éditeurs peuvent travailler simultanément sur le même document avec des indicateurs de présence et des mises à jour en direct. Si vous avez utilisé Google Docs, l'expérience est similaire — vous voyez les curseurs et les modifications des autres en temps réel.

Nous déployons notre Studio avec npx sanity deploy, ce qui l'héberge sur le CDN de Sanity sous un sous-domaine personnalisé. Vous pouvez aussi l'auto-héberger puisque c'est simplement une application React. Nous avons classé Sanity en tête dans notre comparaison des CMS headless notamment pour la flexibilité de Studio.

Comment configurer un projet Sanity

Pour configurer Sanity CMS, installez la CLI avec npm create sanity@latest, choisissez un template de projet, configurez vos fichiers de schéma et lancez npx sanity dev pour démarrer Studio en local. Tout le processus prend moins de 5 minutes.

Prérequis et installation

Il vous faut Node.js 18+ et npm (ou pnpm). C'est tout. Lancez la commande d'initialisation :

npm create sanity@latest

# Vous serez invité à renseigner :
# - Méthode de connexion (Google, GitHub, email)
# - Nom du projet
# - Nom du dataset (par défaut : "production")
# - Template de projet (blog, ecommerce, clean)
# - TypeScript ? (recommandé : oui)

La CLI génère un projet avec tout ce dont vous avez besoin. Voici à quoi ressemble la structure du projet :

Structure du projet expliquée

my-sanity-project/
├── schemas/              # Vos schémas de contenu (c'est là que vous passerez du temps)
│   ├── index.ts          # Registre des schémas -- importe et exporte tous les types
│   ├── post.ts           # Définitions des types de documents
│   └── blockContent.ts   # Config du texte riche / Portable Text
├── sanity.config.ts      # Config principale -- plugins, structure Studio, dataset
├── sanity.cli.ts         # Config CLI -- identifiant de projet, dataset
├── package.json
└── tsconfig.json

Le fichier sanity.config.ts est votre point d'entrée. Voici un exemple minimal :

// sanity.config.ts
import { defineConfig } from 'sanity'
import { structureTool } from 'sanity/structure'
import { visionTool } from '@sanity/vision'
import { schemaTypes } from './schemas'

export default defineConfig({
  name: 'default',
  title: 'My Blog',
  projectId: 'your-project-id',
  dataset: 'production',
  plugins: [structureTool(), visionTool()],
  schema: { types: schemaTypes },
})

Le plugin visionTool() vous offre un terrain de jeu GROQ directement dans Studio — vous l'utiliserez constamment en développement.

Déployer votre Studio

Lancez en local avec npx sanity dev (tourne sur localhost:3333). Quand vous êtes prêt à partager avec des éditeurs, déployez sur le CDN de Sanity :

npx sanity deploy
# Demande un hostname, ex. "my-blog"
# Déploie vers https://my-blog.sanity.studio

Conseil pratique : lancez npx sanity@latest schema deploy après chaque modification de schéma. Cela télécharge votre schéma vers l'API de Sanity, ce qui active des fonctionnalités comme l'API GraphQL et les outils schema-aware (dont le serveur MCP que nous abordons plus loin).

Conception de schémas dans Sanity CMS

Les schémas Sanity sont définis comme des objets JavaScript ou TypeScript dans votre codebase. Chaque schéma spécifie un type de document avec des champs, des règles de validation et des composants d'entrée personnalisés. Les modifications de schéma sont instantanées — aucune migration de base de données requise. C'est l'approche « schéma en code », et c'est ce qui nous a convaincus de choisir Sanity plutôt que Contentful.

Types de champs et validation

Sanity embarque un ensemble riche de types de champs. Voici ceux que nous utilisons le plus :

Chaque champ prend en charge la validation via un callback validation. Vous pouvez imposer des champs obligatoires, des valeurs min/max, des patterns regex et des règles personnalisées :

defineField({
  name: 'seoDescription',
  title: 'Meta Description',
  type: 'string',
  validation: (Rule) =>
    Rule.required()
      .min(145)
      .max(160)
      .warning('Meta description should be 145-160 characters'),
})

Types de blocs personnalisés (nos exemples en production)

C'est là que Sanity devient intéressant — et là où aucun des 6 guides concurrents ne montre de code. Dans notre schéma de production, nous définissons cinq types de blocs personnalisés dans le tableau body : block (texte standard), table, codeBlock, chartBlock et inlineImage.

Voici notre définition de codeBlock :

// schemas/objects/codeBlock.ts
import { defineType } from 'sanity'

export const codeBlock = defineType({
  name: 'codeBlock',
  title: 'Code Block',
  type: 'object',
  fields: [
    {
      name: 'language',
      title: 'Language',
      type: 'string',
      options: {
        list: [
          { title: 'JavaScript', value: 'javascript' },
          { title: 'TypeScript', value: 'typescript' },
          { title: 'Python', value: 'python' },
          { title: 'Bash', value: 'bash' },
          { title: 'JSON', value: 'json' },
          { title: 'GROQ', value: 'groq' },
        ],
      },
    },
    {
      name: 'code',
      title: 'Code',
      type: 'text',
    },
  ],
})

Et voici comment le champ body référence tous nos types personnalisés ensemble :

// schemas/fields/body.ts
defineField({
  name: 'body',
  title: 'Body',
  type: 'array',
  of: [
    { type: 'block' },         // Portable Text standard (paragraphes, titres, listes)
    { type: 'table' },         // Plugin @sanity/table
    { type: 'codeBlock' },     // Notre bloc de code personnalisé
    { type: 'chartBlock' },    // Visualisation de données (barres, courbes, camembert)
    { type: 'inlineImage' },   // Images avec alt et légendes
  ],
})

Cela donne à nos éditeurs un outillage de contenu riche tout en gardant chaque élément typé et interrogeable. Un chartBlock n'est pas un embed HTML opaque — c'est de la donnée structurée avec des champs chartType, title, dataPoints et dataLabels. C'est important quand vous essayez de rendre le même contenu sur le web, par email et sur mobile.

Bonnes pratiques d'organisation des schémas

Gardez vos schémas modulaires. Nous les répartissons dans des fichiers par type : schemas/documents/post.ts, schemas/objects/codeBlock.ts, schemas/objects/chartBlock.ts. Importez-les tous dans schemas/index.ts :

// schemas/index.ts
import { post } from './documents/post'
import { codeBlock } from './objects/codeBlock'
import { chartBlock } from './objects/chartBlock'
import { inlineImage } from './objects/inlineImage'

export const schemaTypes = [post, codeBlock, chartBlock, inlineImage]

L'enseignement clé tiré de notre travail avec le contenu structuré : votre schéma EST votre modèle de contenu. Si vous le pensez comme de l'ingénierie de contexte pour votre équipe éditoriale, vous prendrez de meilleures décisions de conception. Chaque champ ajouté doit servir à quelque chose — soit pour les éditeurs, soit pour le rendu, soit pour les requêtes.

GROQ : le langage de requête de Sanity

GROQ (Graph-Relational Object Queries) est le langage de requête open source de Sanity pour filtrer, joindre et projeter des documents JSON. La syntaxe de base est *[filtre]{projection} — sélectionnez tous les documents correspondant à un filtre, puis façonnez la sortie. C'est plus concis que GraphQL pour les requêtes spécifiques à Sanity et, dans notre expérience, plus rapide à apprendre.

Requêtes de base : filtrer et projeter

La requête la plus simple récupère tous les documents d'un type :

// Récupère tous les articles -- juste le titre et le slug
*[_type == "post"]{
  title,
  "slug": slug.current
}

// Filtre par langue, développe la référence auteur
*[_type == "post" && language == "en"]{
  title,
  "slug": slug.current,
  "authorName": author->name,
  "authorImage": author->image,
  "categoryTitle": category->title,
  publishedAt
}

L'opérateur -> suit les références. author->name signifie « suit la référence auteur et retourne le champ name ». Pas de requêtes séparées, pas de problèmes N+1, pas de JOINs — tout tient en une seule expression.

Jointures, tri et pagination

Pour nos pages d'index de blog, nous avons besoin d'articles ordonnés et paginés avec les références développées :

// Articles paginés avec métadonnées complètes
*[_type == "post" && language == "en"] | order(publishedAt desc) [0...10] {
  title,
  "slug": slug.current,
  excerpt,
  publishedAt,
  readTime,
  "author": author->{name, image},
  "category": category->{title, "slug": slug.current},
  "coverImage": coverImage{
    "src": asset->url,
    alt
  }
}

[0...10] retourne les 10 premiers résultats (indexé à 0, fin exclusive). | order(publishedAt desc) trie du plus récent au plus ancien. La projection façonne la sortie pour inclure exactement ce dont votre frontend a besoin — rien de plus.

Vous pouvez tester toutes ces requêtes de manière interactive avec le plugin Vision dans Sanity Studio. Il est précieux en développement. Pour plus de patterns, consultez le cheat sheet GROQ.

GROQ vs GraphQL

Sanity prend en charge GROQ et GraphQL. Lequel utiliser et quand ?

GROQ est le langage natif de Sanity. Il gère les jointures, les projections et les champs calculés dans une seule chaîne de requête. C'est ce pour quoi le Content Lake est optimisé.

GraphQL est disponible après le déploiement de votre schéma (npx sanity@latest schema deploy). Utilisez-le quand vous avez besoin d'outillage standardisé — par exemple, si votre frontend utilise déjà Apollo Client ou si votre équipe connaît GraphQL mais pas GROQ.

Nous utilisons GROQ exclusivement. Il est plus expressif pour les données Sanity, et le plugin Vision rend le débogage des requêtes trivial.

Portable Text : le contenu riche bien fait

Le Portable Text est la spécification de Sanity pour le texte riche structuré. Au lieu de stocker le contenu sous forme de chaînes HTML, il stocke un tableau de blocs typés — paragraphes, titres, images, extraits de code, tableaux — chacun sous forme d'objet JSON. Cela rend le contenu utilisable dans n'importe quel framework, n'importe quelle plateforme, n'importe quel format.

La structure de données

Voici à quoi ressemblent un paragraphe et un bloc de code en JSON Portable Text :

[
  {
    "_type": "block",
    "_key": "a1b2c3",
    "style": "normal",
    "markDefs": [],
    "children": [
      {
        "_type": "span",
        "_key": "d4e5f6",
        "text": "Here's an example of our pipeline config:",
        "marks": []
      }
    ]
  },
  {
    "_type": "codeBlock",
    "_key": "g7h8i9",
    "language": "typescript",
    "code": "export default defineConfig({ ... })"
  }
]

Chaque bloc a un _type et une _key. Les blocs de texte standard utilisent "block" avec des spans enfants (qui prennent en charge des marks comme gras, italique et liens). Les blocs personnalisés — comme notre codeBlock, chartBlock, table et inlineImage — utilisent leur propre _type et portent des champs structurés.

Pourquoi cela compte-t-il ? Parce que HTML est un format de rendu, pas un format de stockage. Si vous stockez <h2>Titre</h2><p>Du <strong>texte</strong></p> dans votre base de données, vous vous enfermez dans le rendu web. Vous ne pouvez pas extraire proprement ce contenu pour une application mobile, une newsletter email, un PDF ou la fenêtre de contexte d'un agent IA. Le Portable Text sépare le contenu de la présentation. La spécification Portable Text est open source — ce n'est pas un enfermement propriétaire Sanity.

Blocs personnalisés en production

Notre pipeline convertit le Markdown en Portable Text via un script Python (scripts/md_to_portable_text.py). Le convertisseur gère les blocs standard, plus nos quatre types personnalisés :

• table — utilise le schéma du plugin @sanity/table. Lignes et cellules stockées comme données structurées.
• codeBlock — langage et code comme champs séparés, ce qui permet la coloration syntaxique au rendu.
• chartBlock — type de graphique, titre, labels d'axes, noms de séries et points de données sous forme de JSON structuré. Le frontend les rend avec Chart.js.
• inlineImage — alt, source et légende optionnelle comme champs séparés.

Cette structure nous permet d'interroger tous les exemples de code de notre blog (*[body[]._type == "codeBlock"]), de trouver les articles avec des graphiques, ou d'extraire toutes les images sans alt text — tout via GROQ.

Rendu du Portable Text

Côté frontend, utilisez @portabletext/react (ou les équivalents Svelte/Vue). Vous enregistrez des composants personnalisés pour chaque type de bloc :

import { PortableText } from '@portabletext/react'

const components = {
  types: {
    codeBlock: ({ value }) => (
      <pre className={`language-${value.language}`}>
        <code>{value.code}</code>
      </pre>
    ),
    chartBlock: ({ value }) => <Chart data={value} />,
    inlineImage: ({ value }) => (
      <figure>
        <img src={value.src} alt={value.alt} />
        {value.caption && <figcaption>{value.caption}</figcaption>}
      </figure>
    ),
  },
}

// Dans votre composant :
<PortableText value={post.body} components={components} />

C'est le pipeline de rendu complet. Le composant PortableText gère automatiquement les blocs standard (paragraphes, titres, listes, marks). Vous ne définissez des composants personnalisés que pour vos types personnalisés.

Contenu multilingue avec Sanity CMS

Sanity prend en charge le contenu multilingue via la localisation au niveau document (documents séparés par langue liés par une référence canonique) ou la localisation au niveau champ (champs traduits dans un même document). La localisation au niveau document est meilleure pour le SEO et la publication à grande échelle — c'est celle que nous utilisons dans notre pipeline en 10 langues.

Localisation au niveau document vs au niveau champ

Nous avons choisi la localisation au niveau document parce que chaque traduction obtient son propre slug, sa propre URL et ses propres métadonnées. La version turque d'un article sur Supabase vs Firebase reçoit le slug supabase-firebase-karsilastirma — du turc correct, pas un hack de paramètre d'URL.

Architecture de notre pipeline en 10 langues

Voici comment notre pipeline automatisé fonctionne : nous rédigeons un article en anglais, puis nous le traduisons en 9 langues supplémentaires (allemand, français, néerlandais, espagnol, turc, italien, suédois, norvégien, arabe). Chaque traduction passe par la conversion Markdown, la génération Portable Text et la publication via l'API Sanity.

L'architecture ressemble à ça :

1. Rédaction — Markdown anglais avec frontmatter YAML
2. Traduction — Traduction IA vers 9 langues (vérification de la complétude et des diacritiques)
3. Conversion — Script Python qui convertit chaque fichier .md en JSON Portable Text
4. Publication — Appels API Sanity : créer le document, uploader les images, patcher les références

Chaque document a un champ language et une référence canonicalPost pointant vers l'original anglais. Voici la requête GROQ pour récupérer un article et toutes ses traductions :

// Récupère un article et toutes ses traductions
*[_type == "post" && slug.current == "sanity-cms-guide" && language == "en"][0]{
  title,
  language,
  "translations": *[
    _type == "post" &&
    canonicalPost._ref == ^._id
  ]{
    title,
    language,
    "slug": slug.current
  }
}

La partie schéma est simple — un champ language avec une liste de langues supportées :

defineField({
  name: 'language',
  title: 'Language',
  type: 'string',
  options: {
    list: [
      { title: 'English', value: 'en' },
      { title: 'German', value: 'de' },
      { title: 'French', value: 'fr' },
      { title: 'Dutch', value: 'nl' },
      { title: 'Spanish', value: 'es' },
      { title: 'Turkish', value: 'tr' },
      { title: 'Italian', value: 'it' },
      { title: 'Swedish', value: 'sv' },
      { title: 'Norwegian', value: 'no' },
      { title: 'Arabic', value: 'ar' },
    ],
  },
  validation: (Rule) => Rule.required(),
})

Un piège appris à nos dépens : publiez d'abord le document anglais, puis patchez les références canonicalPost sur les traductions en utilisant l'ID du document publié — pas le préfixe drafts.. Sanity traite les documents brouillon et publiés comme des entités distinctes en interne.

Pour plus de détails sur la façon dont ce pipeline se connecte au Model Context Protocol, voir la section suivante.

Fonctionnalités IA de Sanity : MCP, Canvas et Agent Context

Sanity se positionne comme le système d'exploitation de contenu pour l'ère de l'IA. Les fonctionnalités IA clés incluent un serveur MCP pour que les agents IA puissent lire et écrire du contenu, Canvas pour l'édition assistée par IA dans Studio, et Agent Context pour que les agents IA en production puissent interroger du contenu structuré avec une conscience du schéma.

Intégration du serveur MCP

Le serveur MCP de Sanity permet aux agents IA — Claude Code, Cursor, Windsurf et autres — d'interagir avec votre workspace Sanity par programmation. Les agents peuvent lire les schémas, exécuter des requêtes GROQ, créer des documents et gérer du contenu sans wrappers API personnalisés.

Nous utilisons le serveur MCP de Sanity quotidiennement dans notre pipeline de contenu. Nos agents IA interrogent le schéma pour comprendre la structure des documents, récupèrent les articles existants pour trouver des opportunités de liens internes, et publient de nouveaux documents. Le protocole MCP donne aux agents une conscience du schéma — ils savent quels champs existent, quels types ils attendent et quelles règles de validation s'appliquent. Si vous construisez des agents IA pour les entreprises, c'est un pattern puissant.

Agent Context pour l'IA en production

Agent Context est une fonctionnalité distincte pour les intégrations IA de niveau production. Contrairement au serveur MCP (conçu pour les outils développeur), Agent Context fournit un accès en lecture seule et délimité pour les agents IA qui ont besoin d'interroger votre contenu au moment de l'exécution — pensez chatbots, moteurs de recommandation ou systèmes de personnalisation de contenu.

La différence compte : le MCP est pour les flux de travail de développement et éditoriaux (outils de développement schema-aware), tandis qu'Agent Context est pour l'accès au contenu à l'exécution avec une authentification et une limitation de débit appropriées.

Le contenu structuré de Sanity lui donne un vrai avantage ici. Un site WordPress stocke le contenu sous forme de blobs HTML — un agent IA doit parser le HTML pour comprendre le contenu. Sanity stocke des documents JSON typés avec des schémas définis. Un agent peut interroger *[_type == "product" && category == "electronics"]{name, price, features} et obtenir des données propres et structurées. Pas de scraping, pas de parsing, pas de devinettes.

Comment nous utilisons Sanity chez Techsy

Ce n'est pas une section hypothétique. Nous faisons tourner Sanity CMS sur 4 sites en production, en publiant dans 10 langues via un pipeline automatisé que nous avons construit au cours de la dernière année. Voici l'architecture.

Architecture de notre pipeline de contenu

Le pipeline va de la recherche à l'article publié dans les 10 langues :

1. Recherche — analyse des mots-clés, identification des lacunes chez les concurrents, patterns SERP
2. Brief — spec de rédaction structurée avec guidance par section, comptages de mots, liens internes
3. Rédaction — production du Markdown anglais avec frontmatter YAML
4. Conversion — script Python qui transforme le Markdown en JSON Portable Text avec nos 5 types de blocs personnalisés
5. Publication — appels API Sanity : document createOrReplace, upload des images vers le CDN Sanity, patch des références auteur/catégorie
6. Traduction — traduction IA vers 9 langues, vérifiée pour la complétude
7. Publication des traductions — même flux convert/publish par langue, avec la référence canonicalPost patchée vers l'original anglais

Le schéma personnalisé prend en charge les types block, table, codeBlock, chartBlock et inlineImage — tous définis comme des objets de schéma Sanity de production avec des règles de validation. Parmi les meilleurs outils IA pour les startups que nous avons testés, ce pipeline basé sur Sanity s'est révélé le plus fiable pour du contenu structuré à grande échelle.

Leçons tirées de 400+ pièces publiées

Quelques points que nous aurions aimé que quelqu'un nous dise :

L'ordre de patch des références est crucial. Les références Sanity ne peuvent pas pointer vers des documents qui n'existent pas encore. Publiez d'abord l'article anglais, puis créez les traductions avec canonicalPost pointant vers l'ID publié du document anglais. Nous avons cassé ça plusieurs fois au début.

Le déploiement du schéma est par workspace. Si vous gérez plusieurs projets Sanity (nous en gérons 4), vous devez déployer les schémas dans chacun séparément : npx sanity@latest schema deploy par config de projet.

L'offre gratuite est réelle. Nous avons fait tourner deux de nos quatre sites sur le plan gratuit pendant des mois. 20 utilisateurs, 500K requêtes API/mois, 100K requêtes CDN — c'est suffisant pour un vrai site en production, pas juste un projet jouet.

La conversion Portable Text est le goulot d'étranglement. Le passage de Markdown à Portable Text n'est pas trivial. Listes imbriquées, tableaux dans des blockquotes, blocs de code avec des caractères spéciaux — les cas limites sont partout. Nous avons itéré sur notre script de conversion pendant des mois.

Besoin d'aide pour configurer Sanity pour votre projet ? Nous avons construit des pipelines de contenu multilingues pour 4 sites en production. Obtenez une consultation gratuite

Tarifs Sanity CMS détaillés

Sanity propose trois plans : Gratuit (20 utilisateurs, 500K requêtes API/mois), Growth (15 $/utilisateur/mois avec des rôles avancés et des brouillons programmés) et Enterprise (tarification personnalisée avec SLA et fonctionnalités de conformité). L'offre gratuite est la plus généreuse du marché des CMS headless.

Sur l'offre gratuite, nous faisons tourner deux de nos sites sans atteindre les limites. Le plan Growth à 15 $/utilisateur/mois a ajouté le contrôle d'accès basé sur les rôles (important une fois que nous avons eu des éditeurs non techniques) et la publication programmée. Les lecteurs sont gratuits sur Growth, ce qui est appréciable — vous n'êtes pas pénalisé pour donner aux parties prenantes un accès en lecture.

Comment cela se compare aux concurrents ?

L'offre gratuite à 20 utilisateurs de Sanity est exceptionnelle. Contentful vous limite à 1 utilisateur en gratuit et passe à 300 $/mois pour son plan Team. Si vous êtes une startup ou une petite équipe, le plan gratuit de Sanity vous permet de faire tourner de vrais workloads en production sans rien dépenser.

Sanity propose aussi un programme startup qui offre aux startups éligibles un an d'accès Growth gratuit. Ça vaut la peine de postuler si vous remplissez les critères.

Questions fréquentes

Qu'est-ce que Sanity CMS et comment ça fonctionne ?

Sanity CMS est une plateforme de contenu headless qui stocke des documents JSON structurés dans un backend géré appelé le Content Lake. Vous éditez le contenu via Sanity Studio (une application React personnalisable), vous l'interrogez avec GROQ ou GraphQL, et vous le rendez dans n'importe quel framework frontend. Le contenu se synchronise en temps réel sur tous les clients connectés.

Sanity CMS est-il gratuit ?

Oui. L'offre gratuite de Sanity inclut 20 utilisateurs, 500K requêtes API par mois et 100K requêtes CDN — le plan gratuit le plus généreux parmi les plateformes CMS headless. Le plan Growth coûte 15 $ par utilisateur et par mois et ajoute le contrôle d'accès basé sur les rôles, la publication programmée et des limites plus élevées. Les tarifs Enterprise sont sur devis.

Quelle est la différence entre Sanity et Contentful ?

Sanity utilise les schémas en code (les schémas vivent dans votre codebase), GROQ pour les requêtes et un Studio open source entièrement personnalisable. Contentful utilise la modélisation de contenu par interface graphique, GraphQL et un éditeur hébergé moins personnalisable. L'offre gratuite de Sanity inclut 20 utilisateurs contre 1 pour Contentful. Contentful dispose d'un plus grand écosystème de plugins.

Sanity CMS est-il adapté aux débutants ?

Sanity Studio est intuitif pour les éditeurs de contenu — l'expérience d'édition ne nécessite aucune compétence technique. En revanche, la configuration des schémas demande une maîtrise de JavaScript ou TypeScript. Sanity propose une excellente documentation, des templates de projet et un Slack communautaire avec un support actif. Commencez par npm create sanity@latest et un template blog.

Peut-on auto-héberger Sanity ?

Sanity Studio est entièrement auto-hébergeable car c'est une application React open source. Vous pouvez le déployer sur Vercel, Netlify ou tout hébergeur de sites statiques. Le backend Content Lake est un service géré — il n'y a pas d'option d'auto-hébergement pour la couche de données. C'est un compromis : vous obtenez zéro gestion d'infrastructure mais pas de contrôle des données sur site.

Quel type de base de données Sanity utilise-t-il ?

Le Content Lake de Sanity n'est pas une base de données SQL ou NoSQL traditionnelle. C'est un document store géré qui stocke le contenu sous forme de JSON structuré avec une couche de requête GROQ par-dessus. Vous n'interagissez pas directement avec la base de données sous-jacente — vous passez par les API de Sanity. Les documents ont un historique de versions complet et la synchronisation temps réel intégrés.

Sanity CMS est-il open source ?

Sanity Studio est open source sous licence MIT — vous pouvez le forker, le personnaliser et l'auto-héberger. Le backend Content Lake est du SaaS propriétaire. La spécification du langage de requête GROQ est également open source, publiée sur GitHub. La spécification Portable Text est open source elle aussi, maintenue sur portabletext.org.

Qu'est-ce que le Portable Text dans Sanity ?

Le Portable Text est la spécification de Sanity pour le texte riche structuré. Au lieu de stocker le contenu sous forme de chaînes HTML, il représente paragraphes, titres, images et blocs personnalisés comme des objets JSON typés dans un tableau. Cela rend le contenu portable entre frameworks et plateformes. Vous pouvez définir des types de blocs personnalisés comme des extraits de code, des graphiques et des tableaux avec leurs propres champs structurés.

Qu'est-ce que GROQ et en quoi diffère-t-il de GraphQL ?

GROQ (Graph-Relational Object Queries) est le langage de requête natif de Sanity. Sa syntaxe — *[filtre]{projection} — est plus concise que GraphQL pour les données Sanity, avec un support intégré pour les jointures via l'opérateur -> et les champs calculés. GraphQL est aussi disponible pour les équipes qui préfèrent des outils standardisés ou utilisent déjà Apollo Client.

Comment Sanity gère-t-il le contenu multilingue ?

Sanity prend en charge la localisation au niveau document (documents séparés par langue liés par des références canoniques) et la localisation au niveau champ (champs traduits dans un même document). Le niveau document est meilleur pour le SEO parce que chaque traduction obtient sa propre URL et ses propres métadonnées. Nous utilisons la localisation au niveau document pour publier dans 10 langues avec des pipelines de traduction et de publication automatisés.