Désormais avec création de pages par IA via le serveur MCP

Comment fonctionne cmssy

Ce qui vit dans cmssy, ce qui vit dans votre dépôt, et ce qui se passe entre une requête et une page rendue.

cmssy stocke vos contenus et ne les affiche jamais. Votre application affiche vos contenus et ne les stocke jamais. Tout ce qui suit découle de cette seule séparation.

Ce qui vit où

  • Dans votre dépôt - les schémas de blocs et les composants. Un bloc est un composant React plus un schéma de champs, déclaré avec defineBlock. C'est du code : relu, versionné, déployé.
  • Dans cmssy - les pages, les instances de blocs et leurs valeurs, les médias, les modèles et enregistrements, les formulaires. Ce sont des données : éditées visuellement ou par un client IA, publiées sans déploiement.

La frontière entre les deux ne bouge pas. Ajouter un champ demande de livrer du code. Changer un titre, non.

Ce qu'est une page

Une page est un nœud dans un arbre. Elle a un slug dérivé de ses parents, une liste ordonnée d'instances de blocs qui composent son corps, et un layout - des blocs d'en-tête et de pied de page qu'elle possède ou hérite de son parent.

Chaque instance de bloc stocke ses valeurs indexées par langue : content.fr.title et content.en.title sont donc le même champ de la même instance dans deux locales. Il n'y a pas de page traduite séparée.

De la requête à la page rendue

Un frontend cmssy a besoin d'une seule route. La voici en entier :

// app/[[...path]]/page.tsx
import { createCmssyPage } from "@cmssy/next/server";
import { cmssy } from "@/cmssy/config";
import { blocks } from "@/cmssy/blocks";

export const revalidate = 3600;

export default createCmssyPage(cmssy, blocks);

Ce qui se passe à l'arrivée d'une requête :

  1. La route catch-all reçoit le chemin et le transforme en slug.
  2. Le SDK demande à l'API de diffusion la page publiée à ce slug, avec ses blocs de layout. Sans jeton - le contenu publié est public.
  3. Chaque instance de bloc renvoyée porte un type. Le SDK cherche ce type dans le registre passé en deuxième argument.
  4. Votre composant s'affiche avec le contenu de cette instance pour la locale active. Les champs de relation arrivent déjà résolus en enregistrements complets.
  5. Un type de bloc absent du registre n'affiche rien sur votre site - et une carte de diagnostic nommant le type dès que vous ouvrez l'éditeur. Un bloc qui lève une erreur, dans son loader ou son rendu, est contenu de la même façon. Le contenu ne peut pas faire planter votre application.

Le registre est un simple tableau que vous maintenez :

// cmssy/blocks.ts
import { heroBlock } from "@/blocks/hero/block";
import { pricingBlock } from "@/blocks/pricing/block";

export const blocks = [heroBlock, pricingBlock];

Les paquets

Le framework est un adaptateur, jamais la fondation :

  • @cmssy/core - transport, requêtes, configuration, protocole de l'éditeur. Aucun framework. Tourne dans Node, à l'edge, dans un navigateur, dans un cron.
  • @cmssy/react - le rendu : registre de blocs, composants, pont d'édition, hooks.
  • @cmssy/next - uniquement les liaisons Next.js : middleware, route handlers, Metadata, sitemap et robots, fabriques de pages.

Les adaptateurs pour d'autres frameworks se placent à côté de next, pas au-dessus : une application Astro ou Remix n'installe donc jamais React juste pour récupérer une page.

@cmssy/next se découpe par runtime et les entrées ne se mélangent pas : @cmssy/next/middleware tourne à l'edge, /server dans les RSC et route handlers, /client dans le navigateur.

Édition

Deux points d'entrée, un seul contenu.

L'éditeur visuel charge votre vrai site dans un cadre et lui parle via postMessage. Vous éditez les composants réels, pas une approximation d'aperçu - c'est pourquoi le pont d'édition vit dans core et non dans le paquet React.

Le serveur MCP donne à un client IA le même accès en écriture : créer des pages, modifier le contenu des blocs, téléverser des médias, publier. Il modifie le contenu, jamais votre code.

Brouillons et publication

Les modifications atterrissent dans un brouillon. L'API de diffusion publique ne renvoie que du contenu publié : une page inachevée est donc invisible pour votre site par construction, pas grâce à un filtre qu'il faut penser à appliquer.

Pour voir les brouillons pendant le développement, ajoutez ?cmssyDev=1 à n'importe quelle URL. Cela requiert CMSSY_API_TOKEN et affiche votre propre calque de brouillon ; sans le paramètre, vous obtenez le contenu publié.

Publier n'est pas déployer. Votre application met les pages en cache selon sa propre valeur revalidate, et cmssy peut appeler un webhook de revalidation à la publication pour les invalider plus tôt.

Étapes suivantes