Une fois l’architecture technique établie, la question de la modélisation du contenu s’est imposée comme un enjeu central du projet Beyond Pages. L’utilisation de Sanity Studio a déplacé la réflexion au-delà de l’interface visible pour se concentrer sur la structure même de l’information.

Le contenu n’est plus pensé comme un simple ensemble de pages statiques, mais comme un système organisé, capable d’évoluer indépendamment du rendu. Cette approche a profondément influencé la manière dont le site a été conçu et développé.

Penser le contenu avant l’interface

La première étape a consisté à définir le contenu sans anticiper son affichage dans Next.js. Sanity impose une séparation claire entre la donnée et sa représentation, ce qui oblige à formuler précisément la nature de chaque information. Cette contrainte s’est révélée bénéfique. Elle m’a conduit à clarifier le rôle de chaque élément éditorial et à structurer les données de manière cohérente, en tenant compte des usages futurs plutôt que de l’interface immédiate.

Structuration de l’article comme entité centrale

L’article constitue l’élément principal du projet. Sa structure a été pensée pour répondre à des besoins éditoriaux concrets tout en restant suffisamment flexible pour accueillir des évolutions ultérieures.

import {DocumentTextIcon} from '@sanity/icons'
import {defineArrayMember, defineField, defineType} from 'sanity'

export const postType = defineType({
  name: 'post',
  title: 'Post',
  type: 'document',
  icon: DocumentTextIcon,
  fields: [
    defineField({
      name: 'title',
      type: 'string',
    }),
    defineField({
      name: 'slug',
      type: 'slug',
      options: {
        source: 'title',
      },
    }),
    defineField({
      name: 'articleNumber',
      type: 'string',
    }),
    defineField({
      name: 'author',
      type: 'reference',
      to: {type: 'author'},
    }),
    defineField({
      name: 'mainImage',
      type: 'image',
      options: {
        hotspot: true,
      },
      fields: [
        defineField({
          name: 'alt',
          type: 'string',
          title: 'Alternative text',
          validation: rule => rule.custom((value, context) => {
          const parent = context?.parent as {asset?: {_ref?: string}}

          return !value && parent?.asset?._ref ? 'Alt text is required when an image is present' : true
          }),
        })
      ]
    }),
    defineField({
      name: 'publishedAt',
      type: 'datetime',
    }),
    defineField({
      name: 'body',
      type: 'blockContent',
    }),
    defineField({
      name: 'similarPosts',
      title: 'Articles similaires',
      description: 'Sélectionnez manuellement les articles similaires à afficher (max 3 recommandés)',
      type: 'array',
      of: [
        defineArrayMember({
          type: 'reference',
          to: [{type: 'post'}],
        }),
      ],
      validation: (rule) => rule.max(6),
    }),
  ],
  preview: {
    select: {
      title: 'title',
      author: 'author.name',
      media: 'mainImage',
    },
    prepare(selection) {
      const {author} = selection
      return {...selection, subtitle: author && `by ${author}`}
    },
  },
})

Le schéma repose sur un titre, un numéro d’article, un slug destiné au routage, un corps de texte basé sur le Portable Text, une image principale, une date de publication ainsi qu’un lien vers un auteur. Cette organisation permet d’assurer une continuité entre la rédaction du contenu et son exploitation côté front-end.

Relations entre les contenus

La gestion des relations a joué un rôle déterminant dans la modélisation. Plutôt que de dupliquer les informations, les articles s’appuient sur des références vers d’autres types de contenu, notamment les auteurs. Cette logique relationnelle favorise la cohérence éditoriale et facilite les mises à jour. Elle introduit également une réflexion sur la responsabilité du front-end, chargé d’interpréter ces relations et de proposer des alternatives lorsque certaines références ne sont pas renseignées.

Évolution progressive du Sanity Studio

Le Sanity Studio n’a pas été conçu comme un environnement figé.

Sa structure a évolué progressivement, au rythme des tests et des premières intégrations dans Next.js. Certains choix initiaux se sont révélés trop rigides et ont nécessité des ajustements, tandis que d’autres ont été simplifiés afin d’améliorer la lisibilité du Studio. Cette approche itérative a permis de maintenir un équilibre entre rigueur structurelle et souplesse d’usage, tout en renforçant le lien entre la modélisation du contenu et les contraintes techniques du projet.

Apports méthodologiques de la modélisation

Cette phase de travail a modifié ma perception du développement d’un site éditorial. La qualité du projet ne repose pas uniquement sur le code ou les performances, mais sur la capacité à structurer l’information de manière claire et durable.

Les ajustements successifs opérés sur les schémas ont mis en évidence l’importance d’une réflexion en amont, tout en confirmant la nécessité d’expérimenter concrètement avant de figer une architecture.

Vers un contenu modulaire et évolutif

La modélisation mise en place constitue une base solide pour l’introduction de contenus modulaires et de sections dynamiques. Elle prépare le terrain à une approche où le contenu devient véritablement moteur du rendu, indépendamment de la structure des pages.

L’article suivant s’attachera à approfondir cette logique en explorant la mise en place de blocs réutilisables et leur intégration dans le front-end.

Cette étape a marqué un tournant dans le projet Beyond Pages. Elle a permis de passer d’une logique de pages à une logique de systèmes, où le contenu devient une matière première structurée et exploitable.