La mise en place de l’architecture éditoriale avec Sanity prend pleinement son sens au moment de son intégration côté front-end. L’enjeu n’était pas seulement d’afficher des données, mais de traduire des choix éditoriaux en une logique technique cohérente, capable d’évoluer avec le contenu. Next.js joue ici le rôle d’interprète entre les données structurées dans Sanity et leur restitution sous forme de pages dynamiques.

L’approche retenue repose sur une séparation claire entre la récupération des données, leur interprétation et leur affichage, afin de conserver une architecture lisible et adaptable.

De la modélisation à la requête GROQ

La première étape consiste à interroger le contenu défini dans Sanity à l’aide de requêtes GROQ. J’ai fait le choix de centraliser ces requêtes dans un fichier dédié, afin de maintenir une distinction nette entre la logique de données et les composants d’interface.

L’exemple ci-dessous illustre la requête utilisée pour récupérer un article individuel à partir de son slug :

export const POST_QUERY = defineQuery(`
  *[_type == "post" && slug.current == $slug][0]{
    title,
    body,
    mainImage,
    publishedAt,
    author->{
      name,
      image
    }
  }
`)

Cette requête reflète directement la structure du schéma défini dans Sanity. Seuls les champs nécessaires au rendu sont sélectionnés, ce qui limite les traitements côté front-end. La relation vers l’auteur est résolue directement dans la requête, illustrant la capacité de GROQ à naviguer dans les relations entre documents sans logique supplémentaire dans l’application.

Pages dynamiques et rôle du slug

Côté Next.js, chaque article est rendu à partir d’une route dynamique basée sur le slug défini dans le CMS. Le slug devient ainsi l’élément central de la navigation, renforçant l’idée que les pages ne sont pas définies manuellement, mais générées à partir des données.

La récupération de l’article s’effectue au chargement de la page, avec une gestion explicite des cas où le contenu n’existe pas :

const { data: post } = await sanityFetch({
  query: POST_QUERY,
  params: await params,
})

if (!post) {
  notFound()
}

Traduire le contenu en composants React

Le corps des articles repose sur un contenu riche structuré via Sanity. Pour son rendu, j’ai utilisé Portable Text, qui permet d’interpréter les blocs définis dans le Studio et de les transformer en composants React.

L’intégration reste volontairement simple :

{post?.body && (
  <PortableTextClient value={post.body} />
)}

Cette approche permet de conserver un contrôle éditorial côté CMS, tout en laissant au front-end la responsabilité de la mise en forme. L’ajout de nouveaux types de blocs ou l’évolution du contenu ne nécessite pas de modifier la structure de la page, mais simplement d’enrichir le système de rendu associé à Portable Text.

Une implémentation pensée pour évoluer

Au fil de l’intégration, j’ai rapidement constaté que la qualité de la modélisation initiale influençait directement la lisibilité et la simplicité du code front-end. Lorsque les schémas sont clairs, les requêtes deviennent plus expressives et les composants plus légers. À l’inverse, certaines imprécisions dans la structure du contenu ont entraîné des ajustements nécessaires lors de l’implémentation. Cette phase de va-et-vient entre Sanity et Next.js a renforcé l’idée que l’architecture headless ne relève pas uniquement d’un choix technique, mais d’une démarche globale où contenu et code évoluent ensemble.

Du contenu avant la page

L’implémentation front-end adoptée dans ce projet repose sur une logique orientée données plutôt que sur une conception page-centrée. Les composants React interprètent le contenu fourni par Sanity sans dépendre d’une structure figée. Cette approche ouvre la possibilité de faire évoluer le site, tant sur le plan éditorial que technique, sans remettre en cause les fondations existantes.

L’intégration de Sanity dans Next.js permet ainsi de matérialiser concrètement les principes abordés dans les articles précédents, en montrant comment des choix éditoriaux se traduisent en décisions techniques mesurables et évolutives.