CMS headless et Sanity 5 min
Site headless avec Astro et Sanity : qui édite quoi, et à quel prix
Un CMS headless est un outil d'édition de contenu séparé du site qui l'affiche. Les rédacteurs travaillent dans une interface comme Sanity, et le site, construit avec Astro, va chercher le contenu par API à chaque publication pour le transformer en pages statiques. On garde le confort d'édition d'un WordPress avec la vitesse et la sécurité d'un site sans serveur applicatif. Il ne se justifie que si plusieurs personnes publient régulièrement.
Headless, en une image
Dans un CMS classique, l’édition et l’affichage vivent dans le même logiciel : WordPress stocke vos textes et fabrique vos pages. Dans un montage headless, on coupe la tête. Le CMS ne fait que stocker et éditer (le corps), et un site séparé, ici construit avec Astro, se charge d’afficher (la tête). Les deux communiquent par une API.
Ce découpage a une conséquence que les visiteurs ne voient jamais mais que votre hébergeur, votre référencement et votre responsable sécurité remarquent tout de suite : le site publié est statique. Le CMS n’est jamais exposé aux visiteurs, il n’est même pas sur le même serveur. Ce que reçoit le navigateur, c’est du HTML fabriqué à la publication, comme nous l’expliquons dans pourquoi migrer vers un site statique avec Astro.
Faut-il un CMS ? La question qui précède toutes les autres
Un CMS headless coûte du temps de modélisation, un abonnement au-delà d’un certain nombre d’utilisateurs, et une couche de plus à exploiter. Il ne se justifie donc pas par principe. La grille que nous appliquons tient en quatre questions.
| Question | Des fichiers dans le dépôt suffisent | Un CMS headless se justifie |
|---|---|---|
| Qui publie ? | Une ou deux personnes, à l’aise avec un éditeur de texte ou aidées par un moteur de contenu | Une équipe, des contributeurs externes, des relecteurs distincts des auteurs |
| À quelle fréquence ? | Quelques contenus par mois | Des publications quotidiennes, des mises à jour de fiches, un calendrier |
| Quel type de contenu ? | Des articles et des pages : du texte structuré | Des fiches produits, des auteurs, des lieux, des relations entre contenus, des médias en nombre |
| Quel circuit ? | La relecture est la revue de la modification avant fusion | Brouillons, validation par rôle, publication planifiée, aperçu visuel pour des non-techniciens |
Notre propre cas illustre la première colonne. Ce site a été branché sur Sanity en 2025. En septembre 2026, nous avons ramené les articles dans le dépôt, en fichiers Markdown validés par un schéma, parce qu’une seule personne publiait et qu’un moteur de contenu écrit désormais les brouillons directement dans le dépôt : la relecture humaine est la revue de la modification, et la publication est une fusion. Un CMS aurait été une couche de plus à payer et à maintenir pour un confort dont personne ne se servait.
À l’inverse, une agence dont cinq personnes rédigent, un responsable valide et un graphiste gère les visuels a besoin d’un outil d’édition, d’un aperçu et de rôles. C’est là que Sanity prend sa place.
Comment Astro et Sanity s’emboîtent
Sanity n’est pas un WordPress sans thème : c’est une base de contenu hébergée, avec un studio d’édition dont le modèle se définit dans le code. Cinq mécanismes font tenir le montage.
- Le modèle de contenu dans le code. Vous décrivez vos types (article, auteur, offre, étude de cas) et leurs champs dans des fichiers versionnés avec le site. Le studio d’édition en découle. Ajouter un champ est une modification de code revue, pas un clic dans une interface que personne ne documente.
- Le texte riche structuré. Sanity stocke le texte riche sous une forme structurée (Portable Text) plutôt qu’en HTML : le site décide du rendu, et le même contenu peut alimenter une page, un flux, une application ou un assistant IA.
- L’intégration officielle Astro. Sanity publie une intégration officielle pour Astro : le site interroge le contenu à la construction et le transforme en pages statiques. Les requêtes s’écrivent en GROQ, le langage de requête de Sanity, qui permet de ne prendre que ce dont une page a besoin.
- La publication déclenche la reconstruction. Un webhook prévient l’hébergeur à chaque publication. Le site se reconstruit et se redéploie en quelques minutes. Entre deux publications, rien ne s’exécute.
- L’aperçu et l’édition visuelle. Les rédacteurs voient la page telle qu’elle sera publiée, avec leurs brouillons, avant de cliquer sur publier. C’est ce qui rend le montage acceptable pour une équipe non technique.
Ce que le montage ne change pas : le site publié reste un dossier de fichiers servi par un CDN, avec les mêmes contrôles automatiques (liens, sitemap, hreflang, données structurées) qu’un site statique sans CMS.
Ce que ça coûte réellement
Trois postes, et aucun n’est caché.
L’abonnement Sanity. Tarifs consultés le 3 septembre 2026 sur sanity.io/pricing : le plan Free est à 0 $ pour jusqu’à 20 utilisateurs et 2 jeux de données publics. Le plan Growth est à 15 $ par utilisateur et par mois, jusqu’à 50 utilisateurs, avec des jeux de données privés, les commentaires, la publication planifiée et l’assistance IA. Le plan Enterprise est sur devis. Pour une PME de cinq rédacteurs, le plan Free suffit souvent tant que le contenu peut être public. Le passage à Growth se décide sur les rôles et la confidentialité, pas sur le volume.
L’hébergement du site. Celui d’un site statique : quelques euros par mois, sans serveur à administrer.
Le montage. C’est le poste principal, et il se paie une fois : modélisation du contenu, studio, gabarits Astro, aperçu, webhooks, reprise du contenu existant, formation. Dans notre offre de migration vers un site statique, le palier headless avec Sanity démarre à 8 900 € hors TVA.
Les pièges que nous avons vus
- Tout mettre dans du texte riche. Une fiche produit dont le prix est dans un paragraphe ne se filtre pas, ne se trie pas, ne s’affiche pas ailleurs. Ce qui a un sens métier devient un champ.
- Modéliser trop tôt. Un modèle de contenu conçu avant d’avoir écrit dix contenus réels est presque toujours faux. On écrit d’abord, on modélise ensuite.
- Oublier l’aperçu. Sans aperçu visuel, les rédacteurs publient pour voir, et le site se reconstruit vingt fois par jour.
- Négliger les langues. Un contenu multilingue se modélise dès le départ (un document par langue ou des champs par langue), sinon la deuxième langue coûte le prix de la première.
- Confondre headless et sur mesure. Le CMS ne dispense pas de gabarits soignés ni de contrôles au build. Il déplace l’édition, pas la qualité.
Questions fréquentes
Sanity ou un autre CMS headless ? Sanity est notre choix par défaut pour son modèle dans le code, son texte riche structuré et son plan gratuit large. D’autres outils conviennent mieux dans certains cas (contenu très orienté fichiers, hébergement obligatoirement interne). Le cadrage le dit sur pièces.
Mes rédacteurs doivent-ils apprendre Git ? Non. Avec un CMS headless, ils travaillent dans le studio d’édition avec aperçu. Git reste l’affaire de la chaîne de publication, invisible pour eux.
Que se passe-t-il si Sanity tombe ? Le site publié ne dépend pas de Sanity pour s’afficher : il est statique. Seule la publication de nouveaux contenus attend le retour du service.
Puis-je commencer sans CMS et en ajouter un plus tard ? Oui, et c’est souvent la bonne séquence : Astro lit le contenu d’où il vient. On démarre en fichiers, on mesure qui publie, et on branche Sanity le jour où l’équipe en a besoin.