Sanity est puissant. C’est aussi une plateforme que tu construis, pas que tu utilises.

Il n’existe pas d’éditeur visuel

C’est le point le plus important à comprendre à propos de Sanity : Sanity Studio est un framework de configuration, pas un environnement d’édition prêt à l’emploi.

Tu définis tes schémas en JavaScript/TypeScript. Sanity Studio génère un formulaire à partir de ces schémas. Le résultat, c’est une interface d’administration fonctionnelle — mais basée sur des formulaires, pas visuelle. Il n’y a pas d’aperçu en direct de ton contenu dans ton frontend réel intégré à la plateforme.

L’aperçu dans Sanity, c’est quelque chose que tu construis toi-même — en utilisant les hooks d’API de prévisualisation de Sanity, tu branches un panneau d’aperçu ou une URL d’aperçu séparée. C’est une tâche de développeur, pas une fonctionnalité de la plateforme.

b10cks fournit un éditeur visuel bidirectionnel où les éditeurs cliquent sur les éléments dans l’aperçu en direct et le panneau d’édition saute vers ces champs — en temps réel, sans rechargement de page. C’est au niveau de la plateforme, pas de l’implémentation. Zéro configuration développeur pour l’expérience éditoriale.

GROQ vs REST

Sanity utilise GROQ (Graph-Relational Object Queries) — un langage de requête puissant et expressif, conçu spécifiquement pour le modèle documentaire de Sanity. Si tu l’apprends, il est vraiment très bon.

Le compromis : GROQ est propriétaire à Sanity. Tes choix de SDK, tes intégrations frontend et l’onboarding de tes développeurs dépendent tous d’une familiarité avec un langage qui n’existe nulle part ailleurs. C’est une vraie forme d’enfermement propriétaire, facile à sous-estimer quand GROQ ressemble à un simple langage de requête de plus.

b10cks propose du REST — standard, portable, agnostique du framework. N’importe quel développeur que tu recrutes sait déjà consommer ces API.

L’auto-hébergement : un point plus important que tu ne le crois

Sanity Studio — l’environnement d’édition frontend — est open source et peut être déployé n’importe où. Mais Content Lake de Sanity — le backend, la base de données, le stockage réel du contenu — est le cloud managé propriétaire de Sanity. Il ne peut pas être auto-hébergé.

Cela signifie que, quelle que soit la façon dont tu personnalises Sanity Studio, ton contenu vit toujours sur l’infrastructure de Sanity. Tu ne peux pas faire tourner Sanity sur site, dans ton propre compte AWS, ou sous ta propre gouvernance des données.

b10cks est entièrement auto-hébergeable. Le backend, la base de données, le stockage — tout fonctionne là où tu décides. L’auto-hébergement ne demande qu’une seule commande Docker Compose et ta propre infrastructure.

La localisation n’est pas une fonctionnalité de plateforme

Sanity n’a pas de système de localisation. Tu implémentes la localisation toi-même — généralement via un plugin communautaire (sanity-plugin-internationalized-array ou similaire) qui stocke les variantes linguistiques sous forme de champs d’objet dans les documents. L’approche fonctionne, mais elle n’est ni standardisée, ni maintenue par Sanity, ni intégrée au flux de travail d’édition.

Pour des produits multilingues en production, cela signifie que les développeurs passent du temps sur une infrastructure que b10cks fournit par défaut : contrôle de traduction au niveau des champs, héritage des paramètres régionaux, contrôle de publication par langue, changement de langue dans l’éditeur.

Le problème de la tarification par siège

Le plan gratuit de Sanity est généreux : 20 sièges sans frais. Mais le plan Growth coûte 15 $/siège/mois sans limite supérieure de nombre de sièges. Pour une équipe de 20 éditeurs, Growth coûte 300 $/mois rien qu’en frais de siège. Pour 30 éditeurs, 450 $/mois.

Et Growth reste limité : 25 000 documents, 5 rôles d’autorisation.

b10cks n’a pas de frais par siège. Invite toute ton entreprise — développeurs, responsables contenu, parties prenantes, clients — sans que le compteur tourne. Tu paies pour le stockage et le trafic. C’est tout.