Labs

Sanity : construire un rich text qui s’adapte au contenu

CatégorieDéveloppement
Publication31 août 2026
Mis à jour11 sept. 2026
Clément MurzeauFondateur & Développeur

En refondant notre site, on savait surtout ce qu’on ne voulait plus : des contenus CMS réduits à une alternance de textes et d’images.

On voulait pouvoir pousser chaque idée jusqu’à la forme qui la sert le mieux. Diffuser une vidéo depuis notre propre infrastructure. Afficher un extrait de code prêt à copier. Intégrer une scène 3D, une carte ou un graphique…

Les idées ne manquent pas. Les besoins de nos clients non plus.

Pourtant, il suffit parfois de vouloir glisser un simple bouton entre deux paragraphes pour devoir sortir du rich text, contourner le CMS ou demander une intervention côté développement.

Sanity change la logique. Ce CMS headless dissocie le contenu de son affichage. Pour chaque bloc, on définit les données à saisir ; Sanity Studio construit l’interface correspondante, tandis que le front-end garde la main sur le HTML, le style et les interactions.

L’outil ne fixe plus le cadre : le projet le fait.

Utiliser le récap IA
La musique du moment

Lock it, fill it, call it, find it 🎶

Un rich text taillé pour nos contenus

Dans Sanity, Portable Text réunit textes, listes et blocs sur mesure dans un même contenu.

Pour notre nouveau site, on a conçu un premier jeu de blocs à partir de besoins éditoriaux concrets. Chacun encadre les données à renseigner et leur rendu : la personne qui rédige se concentre sur l’essentiel, le site s’occupe du reste.

Tableau

Des données organisées en colonnes et en lignes, avec une structure contrôlée avant publication pour rester lisible et cohérente.

BlocCe qu’on renseigneExemples d’usage
TableauDes en-têtes, des lignes et une légendeComparer des offres, présenter des tarifs ou structurer une fiche technique
AssetUn média (image ou vidéo), son format, son texte alternatif et sa légendeMontrer un projet, une interface, une vidéo ou un résultat
DuoDeux médias, un format commun, leurs textes alternatifs et leurs légendesComparer un avant/après, deux pistes créatives ou deux réglages
TrioTrois médias, un format commun, leurs textes alternatifs et leurs légendesPrésenter une gamme, une progression ou trois variantes
CodeUn extrait, son langage et son nom de fichierPartager une commande, une configuration ou du code prêt à copier
ChecklistUn titre, des étapes et leurs précisionsProposer un audit, un protocole ou une liste de vérification interactive
DépliantUn intitulé, un contenu et une couleurAjouter une FAQ, une précision technique ou une mention légale sans alourdir la page
BoutonUn libellé, une destination et sa mise en pageDiriger vers un outil, un téléchargement, un dossier de presse ou une source
Démo interactiveUn module, ses réglages et son aperçuIntégrer un bloc sur mesure et charger son JavaScript uniquement lorsqu’il devient utile

Asset

Une image ou une vidéo, accompagnée de son format, de son texte alternatif et de sa légende.

Les deux personnages, index joints, à l'instant où la fusion s'opère
Bloc Asset en mode image
Bloc Asset en mode vidéo

Duo

Deux médias alignés pour confronter des pistes, montrer une évolution ou créer un avant/après.

(Forcément le rendu mobile de notre exemple est moins sympa)

Un personnage de dessin animé exécute la danse de la fusion, bras tendu vers la droite
Le second personnage exécute le geste symétrique, bras tendu vers la gauche

Trio

Trois médias réunis dans une composition cohérente, sans avoir à bricoler leur mise en page dans l’éditeur.

Carapuce, petite tortue bleue à la queue enroulée, sur fond crème
Carabaffe, la tortue au stade suivant : plus grande, oreilles et queue duveteuses
Tortank, le stade final : carapace massive et deux canons d'eau aux épaules

Code

Un extrait accompagné de son langage et de son nom de fichier, présenté dans une interface lisible et facilement copiable.

checklist.tsTypeScript
// Schéma du bloc Checklist : ses champs et sa règle de validation

export const checklist = defineType({
  name: "checklist",
  title: "Checklist",
  type: "object",
  fields: [
    defineField({
      name: "title",
      title: "Titre",
      type: "string",
    }),
    defineField({
      name: "items",
      title: "Points",
      type: "array",
      of: [{ type: "checklistItem" }],
      validation: (rule) =>
        rule.min(1).error("Ajoutez au moins un point."),
    }),
  ],
});
nouveau-bloc-rich-textPrompt
# Prompt : aide à la création d'un nouveau bloc de rich text

Ajoute un bloc au rich text de ce projet Sanity.

Besoin : <le bloc en une phrase, avec le vocabulaire du client>
Champs : <champ par champ, en précisant obligatoire ou non>
Refus  : <ce que le bloc ne doit pas laisser passer>

Contraintes du projet :
- defineType / defineField, TypeScript strict
- intitulés et descriptions en français, noms de champs en anglais
- une validation explicite par règle de refus, avec son message d'erreur
- un preview avec title et subtitle lisibles dans la liste du Studio
- ajoute le type au tableau `of` du rich text, onglet d'insertion Sanity

Livre : le fichier de schéma, la modification du rich text, et le composant
de rendu Astro correspondant. Aucune dépendance nouvelle.

Checklist

Une liste interactive dont la progression peut être mémorisée par le navigateur.

Faut-il créer un bloc sur mesure ?

0 / 5

Dépliant

Un complément accessible à la demande, pour approfondir un point sans interrompre la lecture principale.

Replié à l’écran, présent dans le HTML

Dans notre bloc, le contenu du dépliant est présent dans le HTML initial, même lorsqu’il est replié. Il reste donc accessible aux robots qui n’exécutent pas JavaScript. À l’inverse, un dépliant qui injecte son contenu uniquement après le clic peut sembler identique, tout en restant invisible pour certains robots.

Bouton

Un appel à l’action inséré directement dans le contenu, avec son libellé, sa destination et sa mise en page.

Nous écrire

Démo interactive

Une expérience interactive configurée depuis le CMS. Son code JavaScript peut être chargé uniquement lorsque le bloc approche de l’écran, afin de préserver les performances du reste de la page.

Cube chargé à l'approche de l'écran.

Chaque bloc embarque ses propres règles. Le Tableau exige autant de cellules que d’en-têtes, la Checklist refuse une liste vide et le Bouton attend une destination. Sanity bloque ainsi les incohérences dès la rédaction, avant qu’elles n’atteignent la page publiée.

Ce jeu de blocs n’est pas figé : il évoluera avec nos usages, nos expérimentations et les nouveaux besoins du studio.

Que se passe-t-il dans Sanity Studio ?

La personne qui rédige choisit un bloc, renseigne les quelques champs utiles et vérifie le résultat directement dans la page. La complexité du composant reste cachée derrière une interface adaptée à son usage.

Choisir parmi les blocs du projet

Le menu d’insertion affiche uniquement les blocs conçus pour les Labs. Il ne cherche pas à couvrir tous les scénarios imaginables : il reflète les possibilités réelles de cette partie du site.

Le menu d'insertion du rich text ouvert dans Sanity Studio, listant les blocs disponibles pour ce projet
Les Labs gardent leur propre jeu de blocs.

Ne montrer que les champs nécessaires

Une fois le bloc choisi, Sanity affiche uniquement les données dont il a besoin.

L’Asset commence, par exemple, par demander un type de média. En mode image, il attend un fichier, un texte alternatif et une légende. En mode vidéo, il fait apparaître un poster et deux sources.

Le formulaire du bloc Asset en mode vidéo, avec le choix du type puis celui du format du cadre
Ici le type choisi commande la suite du formulaire.

Vérifier le résultat dans la vraie page

Sanity Presentation affiche le site à côté des champs de rédaction. Un clic dans la page ouvre le bloc correspondant dans le Studio. Les modifications apparaissent dans la prévisualisation avant toute publication.

La personne qui rédige ne doit plus imaginer le résultat à partir d’un formulaire abstrait : elle le voit directement dans son contexte.

L'écran Presentation de Sanity Studio, avec le formulaire de rédaction à gauche et l'aperçu de la page à droite
Sanity Presentation : le formulaire à droite, la page telle qu'elle sortira à gauche.

Le back-office ne cherche pas à prévoir tous les besoins possibles ni à multiplier les boutons. Il utilise le vocabulaire du projet, masque les options inutiles et bloque les combinaisons incohérentes. De nouveaux champs ou blocs peuvent ensuite être ajoutés à mesure que le contenu évolue.

Un CMS, plusieurs terrains de jeu

Les blocs présentés plus haut appartiennent aux Labs. Notre collection Portfolio utilise, par exemple, un autre jeu conçu pour raconter des projets.

Dans les deux cas, cela reste du rich text : les paragraphes, les titres, les listes et les blocs sur mesure s’enchaînent dans un même contenu.

Sanity ne traite simplement pas le rich text comme un réglage global. Chaque champ définit les blocs qu’il accepte. La rédaction reste continue, mais son menu d’insertion s’adapte à ce que la page doit raconter.

Portfolio : des blocs conçus pour raconter un projet

Lors de la création de nos pages projet, on avait besoin de réunir plusieurs médias, de replacer les créations dans leur contexte et de comparer différents états. On a donc conçu plusieurs blocs autour de ces usages, à commencer par le Slider, le Média in situ et l’Avant/après.

  • Slider. Il réunit une série d’images ou de vidéos dans un même espace. La personne qui consulte le projet peut les parcourir sans que chaque média allonge davantage la page.
    Exemple : projet Coline
  • Média in situ. Il replace une création dans son contexte d’utilisation : un écran, un support imprimé ou un lieu. Le projet se découvre là où il doit vivre, plutôt que sur un fond neutre.
    Exemple : projet Gaia
  • Avant/après. Il superpose deux médias et permet de déplacer la ligne qui les sépare. Là où le Duo des Labs les place côte à côte, ce bloc rend la comparaison interactive.
    Exemple : projet Deguiret

Même CMS, même Studio, mais deux listes adaptées à deux récits différents.

Cette séparation ajoute une question à chaque nouveau besoin : le bloc appartient-il aux Labs, au portfolio ou aux deux ? Elle évite surtout de construire un menu global qui accumulerait les options inutiles au fil des projets.

Conclusion

Sanity ne remplace pas un catalogue fermé par un catalogue plus long. Il retire le catalogue de l’équation.

On construit le bloc dont le contenu a besoin, avec ses données, ses règles et son rendu. Il s’insère dans le rich text sans imposer de contournement à la personne qui rédige.

La question n’est donc plus : « Est-ce que le CMS le permet ? »
Elle devient : « Quelle structure sert le mieux ce contenu ? »

Toute la difficulté consiste alors à placer la bonne frontière. Quand un besoin mérite-t-il son propre bloc ? Quand justifie-t-il un jeu entier ? Et quand le rich text classique suffit-il largement ?

Cette fois, c’est au projet de répondre, pas à l’outil.

Sources

CatégorieDéveloppement
Publication31 août 2026
Mis à jour11 sept. 2026
Clément MurzeauFondateur & Développeur

Vous souhaitez de l’aide pour gravir de prochains sommets ?

Prenez rendez-vous avec nos sherpas !
Contacter

Explorez le relief