1. Origine
Sanity a été fondée à Oslo en 2017 par Magnus Hillestad, Even Westvang et Simen Svale Skogsrud, autour d'une idée à contre-courant du CMS traditionnel : le contenu n'est pas une page, c'est une donnée structurée. Une fois structuré, il peut alimenter un site, une application, une newsletter ou une borne, sans être réécrit à chaque fois.
Le contenu est stocké dans le Content Lake, une base de documents JSON interrogeable en GROQ, le langage de requête maison. L'interface d'édition, le Studio, n'est pas un back-office figé : c'est une application React qu'on versionne avec le projet et qu'on adapte au contenu, pas l'inverse.
2. Utilité
Le schéma est le cœur du sujet. Sur un CMS classique, une page est un empilement de blocs libres : rien ne garantit qu'un projet du portfolio ait une année, un secteur ou une couverture. Dans Sanity, le schéma est écrit en TypeScript, versionné avec le code, et il vaut contrat : le champ existe, il est typé, il peut être obligatoire.
Chez Studio Relief, c'est le CMS du site : projets, articles, outils, termes du glossaire, questions fréquentes, offres et pages légales sont autant de types de documents distincts, reliés entre eux par des références. Le site les consomme via des requêtes GROQ typées, et le mode Presentation permet d'éditer le contenu directement dans un aperçu du site, en cliquant sur l'élément à modifier.
3. Fonctionnalités
Sanity fournit à la fois le magasin de contenu, le langage pour l'interroger et l'interface pour l'éditer, chacun étant remplaçable indépendamment.
- Schémas en TypeScript versionnés avec le code : chaque type de document, chaque champ et chaque règle de validation vit dans le dépôt
- GROQ : un langage de requête qui projette exactement les champs voulus, résout les références et calcule des valeurs dérivées en un seul appel
- Studio personnalisable : structure du menu, aperçus, actions et champs sur mesure, déployé comme une application à part entière
- Portable Text : le texte riche est stocké comme une structure et non comme du HTML, ce qui permet de le rendre différemment selon le support
- Presentation et Visual Editing : édition dans un aperçu du site, avec surlignage des éléments éditables
- Temps réel et collaboration : plusieurs personnes éditent le même document, avec historique des versions et restauration
- Brouillons et publication : chaque document a un état publié et un brouillon, avec des releases pour préparer une mise en ligne groupée
- Pipeline d'images : recadrage intelligent, formats modernes et redimensionnement à la volée depuis l'URL, sans retoucher les fichiers source
- TypeGen : génération des types TypeScript à partir du schéma et des requêtes, pour une chaîne typée du CMS jusqu'au composant
4. Cas concrets
→ Sur le site Studio Relief, une même fiche outil alimente plusieurs endroits : sa page dédiée, la grille filtrable du hub, les outils liés d'un article et la liste des projets qui l'utilisent. Le contenu n'est saisi qu'une fois, les relations sont résolues à la requête.
→ Sur un projet multi-supports, le même document peut alimenter le site public, une application mobile et un export. Le contenu étant structuré et non mis en forme, chaque support décide de son rendu sans dupliquer la saisie ni maintenir deux versions du texte.
5. Prix
Le plan gratuit couvre confortablement un site vitrine : plusieurs éditeurs, un volume de documents large, API et CDN de contenu inclus. Les plans payants s'adressent aux équipes plus nombreuses ou aux besoins avancés (rôles fins, environnements supplémentaires, volumétrie). La facturation dépend des utilisateurs et de la consommation d'API, jamais du nombre de pages du site.
→ Tarifs : sanity.io/pricing
6. Questions fréquentes
Sanity ou Webflow pour gérer le contenu ?
Webflow réunit design et contenu dans un même outil, ce qui est très confortable tant que le site reste un site. Sanity sépare le contenu de sa mise en forme : c'est plus exigeant au départ, puisqu'il faut modéliser, mais le contenu devient réutilisable, typé et indépendant du frontend.
Faut-il un développeur pour faire évoluer le CMS ?
Pour l'édition quotidienne, non : le Studio est fait pour les rédacteurs. Pour ajouter un type de document ou un champ, oui, puisque le schéma vit dans le code. C'est la contrepartie exacte de la garantie inverse : personne ne peut casser la structure du contenu depuis l'interface.
GROQ est-il compliqué à apprendre ?
La syntaxe est proche du filtrage JavaScript et se lit rapidement : on filtre, puis on projette les champs voulus. Les requêtes complexes (références inversées, agrégats) demandent un peu de pratique, mais l'outil Vision intégré au Studio permet de tester une requête en direct avant de la poser dans le code.
