Après avoir défini les intentions éditoriales et le cadre conceptuel du projet, la question de l’architecture technique s’est imposée rapidement.
Le défi consistait à mettre en place une stack capable de soutenir un projet éditorial évolutif, tout en restant cohérente avec les objectifs d’apprentissage fixés autour de Sanity et de Next.js. Les choix effectués ne visent pas l’exhaustivité ni l’optimisation extrême, mais la lisibilité, la modularité et la capacité à expérimenter.
Choix de la stack technique
Le projet s’appuie sur les technologies suivantes :
Next.js: framework front-end
Sanity Studio: interface d’édition du contenu
Sanity Content Lake: stockage et distribution des données
GROQ: langage de requêtes
Three.js: expérimentations visuelles ponctuelles
Vercel: déploiement et hébergement
Cette stack a été choisie pour sa complémentarité : chaque outil répond à un besoin précis sans empiéter sur le rôle des autres.
Séparation front-end / back-end éditorial
L’un des principes fondateurs de ce projet repose sur une séparation stricte entre le contenu et son rendu.
Le front-end, développé avec Next.js, est exclusivement chargé de l’interprétation et de l’affichage des données, tandis que le back-end éditorial repose sur Sanity, utilisé pour modéliser, stocker et organiser le contenu.
Sanity Studio n’est jamais exposé aux utilisateurs finaux : il fonctionne comme un outil interne me permettant de structurer, écrire et gérer les articles du mémoire. Cette architecture m’a amené à penser le contenu comme une ressource autonome, indépendante de toute notion de page ou de template figé. Chaque article, chaque bloc ou métadonnée existe ainsi avant toute considération visuelle.
La séparation présente plusieurs avantages : elle permet de faire évoluer le design sans impacter le contenu, de modifier les schémas Sanity sans avoir à réécrire les pages, et plus largement de concevoir le contenu comme une donnée plutôt que comme une page. Ce changement de perspective a fortement influencé la manière dont j’ai conçu les schémas au sein de Sanity Studio.
├── 📁 public
│ ├── 🖼️ bg-footer.jpg
│ ├── 🖼️ footer-flower-mid.png
│ └── 🖼️ sanity-logo.png
├── 📁 src
│ ├── 📁 app
│ │ ├── 📁 (frontend)
│ │ │ ├── 📁 posts
│ │ │ │ ├── 📁 [slug]
│ │ │ │ │ ├── 📄 page.tsx
│ │ │ │ │ └── 🎨 post.module.css
│ │ │ │ ├── 📄 page.tsx
│ │ │ │ └── 🎨 posts.module.css
│ │ │ ├── 📄 layout.tsx
│ │ │ └── 📄 page.tsx
│ │ ├── 📁 studio
│ │ │ └── 📁 [[...tool]]
│ │ │ └── 📄 page.tsx
│ │ ├── 🎨 globals.css
│ │ ├── 📄 layout.tsx
│ │ └── 🎨 page.module.css
│ ├── 📁 components
│ │ ├── 📁 ColorBends
│ │ │ ├── 🎨 ColorBends.module.css
│ │ │ └── 📄 ColorBends.tsx
│ │ ├── 📁 Footer
│ │ │ ├── 🎨 Footer.module.css
│ │ │ └── 📄 Footer.tsx
│ │ ├── 📁 Header
│ │ │ ├── 🎨 Header.module.css
│ │ │ └── 📄 Header.tsx
│ │ ├── 📁 Loader
│ │ │ ├── 🎨 Loader.module.css
│ │ │ └── 📄 Loader.tsx
│ │ ├── 📁 LoaderWrapper
│ │ │ └── 📄 LoaderWrapper.tsx
│ │ ├── 📁 PostsList
│ │ │ ├── 📄 PostsHeader.tsx
│ │ │ └── 📄 PostsList.tsx
│ │ └── 📄 PortableTextClient.tsx
│ ├── 📁 contexts
│ │ └── 📄 LoaderContext.tsx
│ └── 📁 sanity
│ ├── 📁 lib
│ │ ├── 📄 client.ts
│ │ ├── 📄 image.ts
│ │ ├── 📄 live.ts
│ │ └── 📄 queries.ts
│ ├── 📁 schemaTypes
│ │ ├── 📄 authorType.ts
│ │ ├── 📄 blockContentType.ts
│ │ ├── 📄 index.ts
│ │ └── 📄 postType.ts
│ ├── 📄 env.ts
│ ├── ⚙️ extract.json
│ ├── 🎨 portableTextComponents.module.css
│ ├── 📄 portableTextComponents.tsx
│ ├── 📄 structure.ts
│ └── 📄 types.ts
├── ⚙️ .gitignore
├── 📝 README.md
├── 📄 eslint.config.mjs
├── 📄 next.config.ts
├── ⚙️ package-lock.json
├── ⚙️ package.json
├── 📄 sanity.cli.ts
├── 📄 sanity.config.ts
└── ⚙️ tsconfig.jsonMise en place de Sanity Studio
Sanity Studio constitue le point d’entrée principal pour la gestion du contenu.
Son installation a été réalisée en parallèle du projet Next.js, afin de pouvoir tester immédiatement les interactions entre les deux environnements.
L’interface du Studio a été volontairement laissée proche de sa configuration par défaut dans un premier temps. Ce choix permettait de se concentrer sur la modélisation du contenu plutôt que sur la personnalisation de l’outil.
Organisation du projet Next.js
L’organisation du projet Next.js a été pensée afin de maintenir une séparation claire entre la gestion des données, la logique applicative et l’affichage.
Cette structuration vise avant tout la lisibilité du code et la capacité du projet à évoluer au fil de l’ajout de nouveaux contenus.
L’architecture repose sur un principe simple : le contenu est piloté par Sanity, tandis que Next.js se charge exclusivement de son interprétation et de son rendu.
Centralisation des requêtes et logique de données
Afin d’éviter la dispersion des requêtes GROQ dans les composants, l’ensemble des accès aux données Sanity a été centralisé dans un fichier dédié (queries.ts). Cette approche permet de maintenir un point d’entrée unique pour la récupération du contenu et facilite les ajustements liés à l’évolution des schémas.
export const POST_QUERY = defineQuery(`
*[_type == "post" && slug.current == $slug][0]{
title,
body,
publishedAt,
author->{ name }
}
`)
Ce choix renforce la lisibilité du projet et met en évidence le rôle central de la modélisation du contenu dans une architecture headless.
Routes dynamiques et génération des pages
Le routage repose sur des routes dynamiques basées sur le slug des articles.
Chaque page est générée à partir des données fournies par Sanity, sans dépendance à une structure de pages prédéfinie.
const { data: post } = await sanityFetch({
query: POST_QUERY,
params: await params,
})
La mécanique permet de créer des pages entièrement pilotées par le contenu, tout en conservant une logique de code simple et explicite.
Rendu du contenu éditorial
Le corps des articles est interprété à partir du format Portable Text, ce qui garantit une grande flexibilité dans la rédaction et la structuration du contenu côté CMS.
Le front-end se limite à traduire cette structure en composants React, sans logique métier superflue.
<PortableTextClient value={post.body} />Retour personnel sur l’organisation choisie
Cette organisation m’a rapidement montré à quel point les choix effectués lors de la modélisation influencent directement la simplicité du code front-end.
Une requête bien définie permet de réduire considérablement la complexité des composants, tandis qu’un schéma imprécis se traduit immédiatement par des ajustements côté Next.js.
Travailler avec des routes dynamiques et des requêtes paramétrées m’a également permis d’adopter une vision plus systémique du projet, où le contenu devient le véritable point de départ de l’architecture.
Premiers constats techniques
La mise en place de cette architecture a rapidement fait émerger plusieurs constats.
Le premier concerne l’impact direct de la modélisation du contenu sur la simplicité du front-end. Une structure claire côté Sanity se traduit immédiatement par des composants plus lisibles et une logique de rendu plus fluide.
L’usage de GROQ pousse également à une plus grande rigueur dans la structuration des données. La requête devient un miroir des choix effectués lors de la conception des schémas, révélant aussi bien leurs forces que leurs limites.
Enfin, Sanity Studio encourage une réflexion en amont sur l’organisation du contenu, plutôt qu’un ajustement tardif une fois le front-end déjà en place.
J’ai néanmoins constaté que certaines décisions prises trop rapidement au niveau des schémas ont nécessité des ajustements après les premiers tests d’intégration. Cette phase d’itération a mis en évidence l’importance d’un aller-retour constant entre modélisation et implémentation.
Une base volontairement perfectible
L’architecture mise en place à ce stade ne se veut pas définitive.
Elle constitue un socle de travail, suffisamment robuste pour accueillir les contenus du projet, tout en restant ouverte à des évolutions futures.
Ce caractère volontairement perfectible permet d’envisager plusieurs axes d’approfondissement, qui feront l’objet des articles suivants :
- la structuration avancée du contenu
- la mise en place de blocs modulaires
- l’optimisation des requêtes GROQ
- les choix de rendu et de performance côté Next.js
Cette progression reflète une démarche d’apprentissage continue, dans laquelle l’architecture évolue au même rythme que la compréhension de l’outil.