On vous propose Sanity pour votre prochain site, et le mot « headless » revient dans chaque phrase du devis. Vous voyez bien qu'il s'agit d'un CMS, mais pas ce que cela change pour l'équipe qui écrira les pages, ni ce que vous perdez par rapport à un WordPress ou un Webflow. C'est une bonne question à poser avant de signer, parce que Sanity CMS ne se comporte pas comme les outils que la plupart des équipes marketing connaissent.
Je l'utilise tous les jours. Ce site est construit en Next.js et Sanity, avec le Studio intégré à l'adresse /studio, et j'ai refait en mai 2026 le site marketing de Moonworkers, mon entreprise, sur la même base. Voici comment l'outil fonctionne, ce que j'y ai construit, et les cas où je choisirais autre chose.
01Ce que « headless » veut dire, sans jargon
Un CMS classique fait deux choses à la fois : il garde vos textes et il fabrique les pages qui les affichent. Un CMS headless, littéralement « sans tête », ne fait que la première. Il garde le contenu et le met à disposition par une API ; c'est un autre programme, le site, qui vient le chercher et décide de son apparence.
Concrètement, cela veut dire trois choses pour vous. Le même contenu peut nourrir un site, une application ou un autre outil sans être recopié. Le design du site ne dépend plus du CMS, donc on peut le refaire sans toucher aux textes. Et un programme peut écrire dans le CMS aussi facilement qu'une personne, ce qui m'intéresse beaucoup pour automatiser la publication.
La contrepartie de cette liberté, c'est qu'il faut un développeur pour construire la partie visible. Personne ne glisse un bloc dans une page pour voir ce que ça donne, comme dans un éditeur visuel. On y revient plus bas.
02Comment Sanity range le contenu
Sanity se compose de deux morceaux qu'on confond souvent : le Studio, où l'on écrit, et le Content Lake, où le contenu est stocké.
Le Content Lake range le contenu comme des données structurées, sous forme de documents JSON, interrogeables et livrables vers n'importe quel canal. Un article n'y est pas une page HTML : c'est un document avec un titre, un slug, une langue, un corps, une liste de sources. C'est ce qui permet de le réutiliser, et de le vérifier.
Le Studio est l'interface d'édition. Il est open source, collaboratif en temps réel, et les développeurs y décrivent les modèles de contenu avec des objets JavaScript. Le code du Studio est publié sous licence MIT sur GitHub ; le stockage, lui, reste un service hébergé par Sanity.
Les schémas s'écrivent dans le code
Dans la plupart des CMS, on crée un champ en cliquant dans une interface d'administration. Dans Sanity, un schéma décrit dans le code les types de documents et de champs que les rédacteurs peuvent remplir. Le modèle de contenu se versionne donc comme le reste du site, et se relit dans un historique.
La vidéo officielle Sanity Studio 101 montre un détail que j'ai trouvé rassurant : le Content Lake n'impose pas de schéma. Si vous supprimez un champ du Studio, la donnée ne disparaît pas, elle apparaît comme un champ inconnu. On peut donc modifier le Studio en local sans casser la production, puis le publier avec une commande.
Les requêtes GROQ
Pour lire le contenu, Sanity a son propre langage, GROQ. Il sert à décrire exactement les informations dont la page a besoin, en joignant au besoin plusieurs documents. Pour lister les articles français du plus récent au plus ancien, avec leur titre, leur slug et leur extrait, la requête tient en une ligne. Elle commence par un astérisque, qui désigne tous les documents, puis un filtre entre crochets garde le type « article » et la langue « fr », et une projection entre accolades choisit les trois champs à renvoyer. Pour un directeur marketing, l'intérêt est indirect : le site ne charge que ce qu'il affiche.
Le texte riche n'est pas du HTML
Le corps d'un article revient de l'API en Portable Text, une suite de blocs structurés, et non en HTML ou en Markdown comme dans beaucoup d'autres CMS. Le site transforme ces blocs en paragraphes, intertitres et listes au moment de l'affichage. C'est un peu plus de travail au départ, mais un intertitre reste un intertitre, et non une balise collée à la main avec une taille de police au hasard.
03Relier Sanity à Next.js sans servir de pages périmées
Next.js garde en cache les pages et les données qu'il a déjà fabriquées, ce qui rend le site rapide. Le revers : quand un article change dans Sanity, le site peut continuer à servir l'ancienne version. J'ai appris à me méfier de ce cas en mission. Un site peut paraître normal à l'équipe connectée et être périmé, ou cassé, pour les visiteurs.
Sur ce site, j'ai donc écrit une route de revalidation protégée par un secret. À chaque publication, ma machine de contenu l'appelle, et elle fait deux choses. Elle invalide l'étiquette de cache des articles avec revalidateTag et une expiration immédiate (l'option « expire: 0 »). La documentation précise que, dans ce mode, le contenu périmé n'est jamais servi : la visite suivante attend la nouvelle version. Puis elle invalide les chemins du blog avec revalidatePath, au cas où le cache des pages survivrait à celui des données.
Le commentaire que j'ai laissé dans le code dit pourquoi : sans expiration immédiate, la première visite après une publication sert encore l'ancienne version. Rien de grave sur un blog, mais c'est exactement le genre de détail qu'on ne voit pas en testant connecté, juste après avoir cliqué sur « publier ». Après chaque publication, je vérifie donc la page comme un visiteur.
04Mon modèle de contenu pour ce blog
Voici, simplifié, le schéma d'un article sur ce site. Je le donne parce qu'il montre ce qu'un CMS headless permet quand on part du travail réel plutôt que d'un modèle générique.
- Les champs de lecture : titre, slug, extrait, image et son texte alternatif, corps en Portable Text, FAQ.
- La langue et le lien entre versions : chaque article porte sa langue et une référence vers l'original, pour relier le français et l'anglais.
- Les sources : une liste de titres et d'URL, affichée en fin d'article.
- Le référencement : un titre et une description pour les moteurs.
- Le suivi éditorial : un statut « à relire » ou « Relu », le verdict du contrôle automatique, la justification des points signalés et la date d'envoi, ces trois derniers en lecture seule.
Le cinquième bloc est celui que je n'aurais pas pu obtenir aussi simplement ailleurs. Ma machine de contenu vérifie chaque article, puis le publie directement dans Sanity par l'API avec le statut « à relire ». Je le lis sur le site, et je le passe à « Relu » dans le Studio, qui m'affiche la liste des articles qui attendent. J'ai raconté pourquoi j'ai automatisé la publication avant de produire plus : le goulot était la mise en ligne, pas l'écriture.
Ce modèle a un coût, et je préfère le nommer. Chaque champ ajouté demande de toucher au schéma, au code qui l'affiche et parfois aux documents déjà publiés. Le Content Lake garde les anciennes données, ce qui évite de perdre un article, mais ne fait pas le travail de mise à jour à votre place.
05Quand je ne prendrais pas Sanity
Sanity n'est pas le bon choix pour tout le monde, et je préfère le dire avant qu'on me le demande.
Si votre équipe veut composer ses pages elle-même, glisser un bloc, voir le résultat et publier sans développeur, un outil visuel ira plus vite. J'ai fait ce choix pour des sites B2B, et j'explique dans quels cas je pars sur Webflow pour un site B2B. Sanity propose un aperçu en direct du site dans le Studio, mais la mise en page reste écrite par un développeur.
Si personne ne pourra maintenir le code du site après la livraison, le headless devient une dépendance. Le contenu sera bien rangé, mais chaque nouveau type de page demandera quelqu'un pour écrire le schéma et le composant qui l'affiche.
Enfin, si vous changez de CMS uniquement pour la vitesse ou le référencement, regardez d'abord le site actuel. Une migration bien faite garde toutes les URL et les redirections ; je détaille la méthode dans migrer vers Next.js et Sanity sans perdre ses pages. Mal faite, elle coûte plus qu'elle ne rapporte.
06Par où commencer si vous hésitez
Avant de comparer des outils, je ferais un exercice d'une heure avec votre équipe :
- lister les types de contenu du site (article, page d'offre, étude de cas, fiche) et, pour chacun, ses champs ;
- noter qui écrit chaque type et qui le valide ;
- noter si un programme doit créer ou modifier du contenu (un import, une machine de contenu, un catalogue) ;
- noter si l'équipe a besoin de composer des pages librement, ou seulement de remplir des modèles.
Si la liste est longue, structurée, et qu'un programme y écrit, Sanity tient très bien la route. Si l'équipe veut surtout composer des pages, un outil visuel lui conviendra mieux. Entre les deux, c'est une discussion. Moonworkers, présenté parmi mes missions, est un exemple du premier cas : un site marketing avec des calculateurs et une publication automatique.
Si vous voulez qu'on regarde votre cas ensemble, mes services décrivent comment je travaille. On peut en parler.