Exolimits
Site d'agence — site marketing animé, entièrement piloté par un CMS headless pour publier textes et études de cas sans déploiement.
- Mon rôle
- Développeur Frontend
- Période
- févr. 2026 — juin 2026
- Statut
- Livré
Site vitrine de l'agence Exolimits, conçu pour que le mouvement porte la marque tandis que le contenu vit entièrement hors du code : chaque titre, chaque section et chaque étude de cas est un document Sanity. L'équipe de l'agence rédige et publie dans le CMS, et le site en ligne reflète les changements — sans build ni intervention d'un développeur.
Le front-end repose sur Next.js 16 et React 19 et interroge Sanity directement, sans backend intermédiaire. GSAP porte l'identité visuelle : des révélations pilotées par le scroll font apparaître les sections au fil de la lecture, et des marquees défilent en continu.
Le problème à résoudre
La page a deux propriétaires, et c'était là le vrai problème : les éditeurs contrôlent l'intégralité du contenu, tandis que la couche d'animation doit chorégraphier ce qu'ils publient. Un site vitrine classique fige ses textes dans le code — chaque retouche devient une tâche de développeur suivie d'un redéploiement ; ici, l'agence devait publier ses études de cas et ses textes en autonomie, alors même que l'identité du site repose sur un travail GSAP intensif : des révélations au scroll et des marquees qui doivent fonctionner sur un contenu dont la longueur et la forme ne sont pas connues à l'avance.
Comment cela a été construit
Le front-end lit Sanity directement : le contenu est modélisé en documents CMS, et des composants React 19 rendent chaque type de document comme une section de page — aucun backend sur mesure à construire ou à maintenir entre le CMS et l'écran. L'équipe publie dans Sanity et le site suit, sans déploiement.
La couche de mouvement est confiée à GSAP. Les révélations sont liées à la position de scroll, les sections s'animent donc à mesure que le visiteur les atteint, et les marquees tournent en continu. L'animation est rattachée aux composants de section plutôt qu'au contenu lui-même, ce qui sépare les deux propriétés : les éditeurs changent les mots et les études de cas, les composants décident du mouvement.
Ce que ça fait
Publication pilotée par CMS
Tous les textes et études de cas vivent dans Sanity. L'équipe édite et publie depuis le CMS, et les changements sont en ligne sans build ni intervention d'un développeur.
Révélations au scroll
Des timelines GSAP liées à la position de scroll font apparaître chaque section à mesure que le visiteur l'atteint — le cœur de l'identité en mouvement du site.
Marquees en continu
Des bandeaux marquee animés en continu par GSAP maintiennent certaines zones de la page en mouvement permanent, entre les séquences déclenchées au scroll.
Lecture directe de Sanity
Le front-end Next.js interroge Sanity directement — aucun serveur API intermédiaire à construire, déployer ou garder synchronisé avec le modèle de contenu.
Construit avec
Frontend
Next.js 16 rend les pages côté serveur à partir des données Sanity : un site dont la raison d'être est d'être trouvé et lu est servi en HTML prêt pour le référencement, et non comme une coquille rendue côté client.
Le modèle de composants de React 19 fait correspondre chaque type de document Sanity à un composant de section, gardant le modèle de contenu du CMS et la structure des pages alignés.
GSAP fournit les timelines liées au scroll dont dépendent les révélations et les marquees — un séquencement de mouvement que de simples transitions CSS ne peuvent pas exprimer.
TypeScript type les résultats des requêtes Sanity : un changement du modèle de contenu du CMS se manifeste comme une erreur de compilation dans le front-end plutôt que comme une page cassée en silence.