Claude Code et Sanity CMS : guide production pour content ops

Définition simple de Sanity CMS

Sanity CMS est un headless CMS pour gérer du contenu structuré : articles, pages produit, auteurs, FAQ, offres, cas clients, messages marketing et CTA réutilisables. Un headless CMS sépare l’interface d’édition du site qui affiche le contenu. L’équipe édite dans Sanity Studio, les données vivent dans le Content Lake, puis le frontend récupère uniquement les champs nécessaires avec une API.

Pour une équipe content ops, l’intérêt n’est pas seulement d’avoir un meilleur éditeur. L’intérêt est de rendre le contenu exploitable : intention de recherche, mot-clé, lien interne, CTA, responsable de relecture, note de vérification, date de mise à jour. Quand ces éléments deviennent des champs, Claude Code peut générer les schemas, les requêtes GROQ, les helpers TypeScript, les composants et les scripts de contrôle qualité.

Les types de champs sont documentés dans Sanity Schema Types. La syntaxe de requête est documentée dans GROQ syntax. Claude Code peut produire un excellent premier jet à partir de ces références, mais la qualité production dépend toujours des règles humaines : unicité du slug, exclusion des drafts, texte alt obligatoire, CTA adapté et mesure des conversions.

En 2026, Sanity doit être pensé comme une pièce de l’architecture de revenus. Si un site vend des templates, des formations ou du conseil, le CMS doit aider à relier les articles aux offres. Un article débutant peut pousser un PDF gratuit, une comparaison de CMS peut proposer une revue de migration, et un guide de gouvernance peut envoyer vers une formation d’équipe.

Architecture production 2026

Une architecture saine sépare l’édition, la source API, le rendu, la mesure et la monétisation. Cette séparation évite de coller les CTA, les FAQ et les règles de publication directement dans le corps des articles.

Couche	Rôle en production	Indicateur à suivre	Travail confié à Claude Code
Sanity Studio	Éditer posts, offres, FAQ, CTA et notes de revue	champs manquants, attente de revue, drafts anciens	schemaTypes, previews, validation
Content Lake	Source API du contenu structuré	taille des requêtes, cache, séparation dataset	GROQ, filtres draft, filtres locale
Frontend	Pages SEO, listes, pages détail et landing pages	indexation, performance, clics CTA	helpers fetch, types, composants
Analytics/CRM	Relier lecture, achat et demande de contact	événements, formulaires, achats, leads	noms d’événements, checklist QA
Monétisation	PDF gratuit, Gumroad, Stripe, training ou conseil	revenu, qualité du lead, remboursements	variantes CTA, tableaux, FAQ, routing

La règle pratique est simple : tout ce qui influence la conversion doit être structuré. Un CTA dans un paragraphe est difficile à tester. Une FAQ dupliquée dans dix pages est difficile à maintenir. Un statut de relecture dans une feuille séparée sera oublié. Sanity donne la structure, Claude Code transforme cette structure en code répétable.

Pour compléter le sujet, consultez Claude Code blog CMS, la comparaison avec Claude Code Contentful CMS et l’intégration avec Claude Code API development. Pour transformer ce système en workflow d’équipe, utilisez training / consultation.

Use cases réels

Premier use case : une bibliothèque SEO multilingue. Une équipe publie d’abord dans une langue, puis localise vers le français, l’anglais, le japonais, le chinois ou l’espagnol. Si chaque version est un fichier Markdown copié, les écarts apparaissent vite : CTA manquant, description trop longue, lien interne absent, mot-clé mal localisé. Dans Sanity, vous pouvez stocker locale, canonicalSlug, targetKeyword, searchIntent et localizedCta. Claude Code peut auditer ces champs avant publication.

Deuxième use case : un funnel contenu-produit. Tous les lecteurs n’ont pas la même intention. Un débutant veut peut-être une checklist gratuite. Un responsable technique comparant Contentful et Sanity veut peut-être un audit de migration. Un manager lisant sur la gouvernance veut peut-être une formation. Un document CTA structuré avec intent, label et href permet d’afficher la bonne offre au bon endroit.

Troisième use case : une migration CMS avec audit éditorial. Migrer depuis WordPress, Contentful, Notion ou Markdown ne devrait pas signifier déplacer du contenu obsolète. La migration est le bon moment pour classer les pages par trafic, fraîcheur, preuve, intention et valeur commerciale. Des champs comme contentScore, lastReviewedAt, reviewOwner et monetizationStatus donnent une vraie feuille de route.

Quatrième use case : une source unique pour marketing et ventes. En B2B, le site, les emails commerciaux, les FAQ et le support divergent souvent. Sanity peut stocker les explications, objections, preuves et réponses réutilisables. Le site les affiche au public, et un outil interne les affiche à l’équipe. Claude Code peut construire le fetch, les composants et l’API autour de cette même source.

Schema copiable

Ce schema Sanity v3 peut être enregistré dans schemaTypes/post.ts. Il inclut les champs nécessaires au SEO, à l’opération éditoriale et à la monétisation : locale, description, image avec alt, CTA, note de vérification et date de publication.

// schemaTypes/post.ts
import {defineField, defineType} from 'sanity'

export const post = defineType({
  name: 'post',
  title: 'Post',
  type: 'document',
  fields: [
    defineField({
      name: 'title',
      title: 'Title',
      type: 'string',
      validation: (rule) => rule.required().max(90),
    }),
    defineField({
      name: 'slug',
      title: 'Slug',
      type: 'slug',
      options: {source: 'title', maxLength: 96},
      validation: (rule) => rule.required(),
    }),
    defineField({
      name: 'locale',
      title: 'Locale',
      type: 'string',
      options: {
        list: [
          {title: 'English', value: 'en'},
          {title: 'French', value: 'fr'},
          {title: 'Japanese', value: 'ja'},
        ],
      },
      validation: (rule) => rule.required(),
    }),
    defineField({
      name: 'description',
      title: 'SEO description',
      type: 'text',
      rows: 3,
      validation: (rule) => rule.required().max(120),
    }),
    defineField({
      name: 'heroImage',
      title: 'Hero image',
      type: 'image',
      options: {hotspot: true},
      fields: [
        defineField({
          name: 'alt',
          title: 'Alt text',
          type: 'string',
          validation: (rule) => rule.required(),
        }),
      ],
      validation: (rule) => rule.required(),
    }),
    defineField({
      name: 'body',
      title: 'Body',
      type: 'array',
      of: [{type: 'block'}, {type: 'image'}],
      validation: (rule) => rule.required(),
    }),
    defineField({
      name: 'cta',
      title: 'Monetization CTA',
      type: 'object',
      fields: [
        defineField({name: 'label', title: 'Label', type: 'string'}),
        defineField({name: 'href', title: 'URL', type: 'url'}),
        defineField({name: 'intent', title: 'Intent', type: 'string'}),
      ],
    }),
    defineField({
      name: 'verificationNote',
      title: 'Verification note',
      type: 'text',
      rows: 4,
    }),
    defineField({
      name: 'publishedAt',
      title: 'Published at',
      type: 'datetime',
      validation: (rule) => rule.required(),
    }),
  ],
  preview: {
    select: {title: 'title', subtitle: 'locale', media: 'heroImage'},
  },
})

// schemaTypes/index.ts
import {post} from './post'

export const schemaTypes = [post]

GROQ et récupération client

Séparez les requêtes. La liste n’a pas besoin du corps complet. La page détail récupère le body, la note de vérification et le CTA complet.

// src/lib/sanity/queries.ts
export const postsByLocaleQuery = `
  *[
    _type == "post" &&
    locale == $locale &&
    defined(slug.current) &&
    defined(publishedAt)
  ] | order(publishedAt desc) [0...$limit] {
    _id,
    title,
    description,
    "slug": slug.current,
    publishedAt,
    "heroImageUrl": heroImage.asset->url,
    "heroImageAlt": heroImage.alt,
    cta
  }
`

export const postBySlugQuery = `
  *[
    _type == "post" &&
    locale == $locale &&
    slug.current == $slug
  ][0] {
    _id,
    title,
    description,
    "slug": slug.current,
    publishedAt,
    body,
    verificationNote,
    cta,
    "heroImageUrl": heroImage.asset->url,
    "heroImageAlt": heroImage.alt
  }
`

// src/lib/sanity/client.ts
import {createClient} from '@sanity/client'
import {postBySlugQuery, postsByLocaleQuery} from './queries'

export const sanityClient = createClient({
  projectId: process.env.NEXT_PUBLIC_SANITY_PROJECT_ID || '',
  dataset: process.env.NEXT_PUBLIC_SANITY_DATASET || 'production',
  apiVersion: '2026-06-02',
  useCdn: process.env.NODE_ENV === 'production',
})

export async function getPosts(locale: string, limit = 12) {
  return sanityClient.fetch(postsByLocaleQuery, {locale, limit})
}

export async function getPostBySlug(locale: string, slug: string) {
  return sanityClient.fetch(postBySlugQuery, {locale, slug})
}

npm install sanity @sanity/client @sanity/image-url
set NEXT_PUBLIC_SANITY_PROJECT_ID=your_project_id
set NEXT_PUBLIC_SANITY_DATASET=production

Pitfalls et échecs fréquents

Premier pitfall : concevoir le schema uniquement pour la page actuelle. Cela semble rapide, mais chaque ajout futur devient une migration : langues, auteurs, CTA, dates de revue, score de contenu.

Deuxième pitfall : surcharger les requêtes. Une page liste qui récupère tout le body gaspille bande passante et cache. Séparez cartes, détail, sitemap et contenus liés.

Troisième pitfall : exposer des drafts. publishedAt ne suffit pas toujours. Ajoutez reviewStatus ou séparez preview et production.

Quatrième pitfall : utiliser un CTA universel. La monétisation doit suivre l’intention de recherche, pas une bannière identique partout.

Checklist de rollout

• Rendre obligatoires title, description, slug, heroImage.alt et publishedAt.
• Séparer posts, FAQ, auteurs, offres et CTA quand ils sont réutilisables.
• Créer des requêtes GROQ distinctes pour liste, détail, sitemap et articles liés.
• Stocker locale et canonical pour le multilingue.
• Vérifier liens officiels, liens internes, CTA et note de vérification.
• Aligner les événements entre analytics, vente et formulaire.
• Relire trafic, clics, achats et demandes après 30 jours.

CTA de monétisation

Sanity CMS vaut surtout quand il relie contenu, preuve et offre. ClaudeCodeLab peut transformer un blog Markdown, Contentful ou WordPress en modèle Sanity avec GROQ, checklist de publication et CTA de revenus. Pour relier vos articles SEO à des templates, du training ou du conseil, démarrez par training / consultation avec votre contenu réel.