fastsite est un moteur de publication, pas un CMS. Vous envoyez du contenu, il produit du HTML entièrement statique, le valide par site, et laisse votre CDN le servir. Voici le modèle complet, du début à la fin.

1. Vous envoyez des corps, pas des pages

Le contenu est du HTML limité au corps. Vous ne rédigez jamais une page complète — le shell gère le chrome, et le moteur enveloppe chaque corps dans celui-ci au moment de la génération. Il existe quatre façons d'envoyer du contenu, et elles aboutissent toutes au même endroit :

  • REST — POST /api/v1/sites/{site}/content avec une clé API.
  • MCP — les outils create_post et create_page, sous consentement OAuth.
  • Webhooks — une charge utile signée par HMAC provenant d'un système amont, associée à un article, une page, une importation de média ou un composant.
  • Le tableau de bord — pour les moments où vous préférez simplement le saisir vous-même.

Chacun de ces chemins utilise le même assainisseur : une liste blanche de balises fixe, les styles en ligne supprimés, les scripts et les iframes retirés. Les problèmes deviennent des avertissements attachés à l'enregistrement — ils sont normalisés et publiés, jamais transformés en requête échouée. Un mauvais collage ne devrait pas pouvoir bloquer votre pipeline.

2. Le shell gère tout le reste

Le shell est un petit ensemble de templates Twig, un système de design tokens.css, et des chaînes d'interface par locale. C'est l'ensemble du design du site, et c'est ce qu'un agent IA lit et réécrit via l'API ou MCP.

Modifiez un token et tout le site change de thème à la prochaine génération. Comme le design réside en un seul endroit et que le contenu n'est jamais qu'un corps, il n'y a pas de dérive de template entre les pages et rien à migrer quand le design change.

Les écritures dans le shell sont protégées — confinement de chemin, liste blanche d'extensions, limite de taille — et un template qui provoquerait une erreur ou échouerait à l'audit est rejeté lors de la sauvegarde, pas lors de la génération. Prenez un instantané avant une modification risquée ; la restauration crée son propre instantané en premier, de sorte que l'annulation est elle-même annulable.

3. Le moteur génère du HTML statique

À chaque génération, le moteur :

  • Développe <img data-media-id> en balisage <picture> responsive — AVIF et WebP en cinq largeurs, un fallback au format original, des dimensions explicites, et le chargement différé partout sauf pour l'image mise en avant, qui est préchargée à la place.
  • Rend les composants en balisage statique. Les composants React sont rendus côté serveur au moment de la génération et le résultat est du HTML — le framework n'atteint jamais le navigateur.
  • Intègre le CSS minifié avec les tokens en premier, et ne livre aucun JavaScript.
  • Écrit un head complet : title, description, canonical, Open Graph et JSON-LD.
  • Génère sitemap.xml, robots.txt, llms.txt, les en-têtes de cache et les redirections — y compris une redirection ajoutée automatiquement quand un slug change, afin que les anciens liens continuent de fonctionner.

Les générations sont incrémentielles. Un manifeste suit le hash de chaque fichier de sortie, de sorte que seul ce qui a réellement changé est écrit, et les fichiers dont la source a disparu sont supprimés plutôt que laissés orphelins.

4. L'audit décide de ce qui peut être livré

Un score parfait n'est pas quelque chose que vous cherchez à obtenir après coup — il est imposé avant que quoi que ce soit soit écrit. Chaque génération exécute un audit de page qui distingue deux types de problèmes :

  • Les échecs bloquent la génération. Une dimension d'image ou un attribut alt manquant, une ressource externe, un <script> livré, une feuille de style dépassant le budget — ce sont des invariants du pipeline, et une génération qui en violerait un ne se termine pas.
  • Les avertissements ne la bloquent jamais. Un niveau de titre sauté, une page lourde, un canonical non-apex, un lien non explorable — ce sont des signaux de qualité du contenu. Ils sont signalés et la page est quand même publiée.

Cette distinction est essentielle. Le moteur refuse de briser ses propres garanties, et refuse de retenir votre contenu en otage pour une question de style.

L'objectif absolu : 100/100/100/100 sur Google PageSpeed pour chaque page publiée. L'audit est ce qui maintient cette promesse honnête.

5. Il valide et déploie

La publication est une étape explicite, pas un effet secondaire. Écrire du contenu le stocke ; publier génère le site et le pousse. Cela signifie qu'un agent ou un script peut rédiger, réviser et mettre en scène autant qu'il le souhaite sans que rien n'atteigne vos visiteurs.

Quand une publication est lancée, le résultat est validé dans le dépôt git de votre site — un commit par publication — et poussé. Votre hébergeur statique génère sur push. Cloudflare Pages est ce qu'utilise ce site ; tout ce qui surveille un dépôt fonctionne de la même façon.

Les générations et les publications s'exécutent dans une file d'attente, de sorte que l'appel qui en déclenche une retourne immédiatement et vous interrogez pour obtenir le résultat. Les échecs font l'objet de nouvelles tentatives avec backoff plutôt que de disparaître, et une rafale de modifications est fusionnée en une seule génération plutôt qu'en une par modification.

Comme chaque publication est un commit, votre historique de déploiement est aussi un mécanisme de retour arrière. Rien de dynamique n'est déployé : pas de runtime à la périphérie, pas de base de données accessible depuis internet, et pas d'origine susceptible de tomber sous la charge.

Plus d'une langue

Ajoutez une locale et le moteur traduit le contenu publié ainsi que les chaînes d'interface du shell, puis regénère. La locale principale se trouve à la racine et chacune des locales supplémentaires obtient sa propre sous-arborescence, avec les alternates hreflang et x-default configurés sur l'ensemble du cluster et un sitemap par langue.

Les traductions sont suivies par ligne par rapport au hash de leur source, de sorte que la modification d'un paragraphe re-traduit cette page et rien d'autre. Tout ce que vous marquez comme traduit manuellement n'est jamais écrasé. Une page qui n'a pas encore de traduction est simplement absente de cette langue — les visiteurs ne se voient jamais servir une page qui se replie silencieusement sur la mauvaise.

Démarrage rapide

  1. Créez un site et concevez son shell, ou partez du scaffold par défaut.
  2. Créez une clé API, ou connectez un agent via MCP.
  3. Envoyez un article, puis publiez. Regardez une page statique apparaître, validée et en ligne.
  4. Prévisualisez à tout moment sans déployer — la génération de prévisualisation est autonome et ne nécessite aucun serveur.
  5. Ajoutez une locale et laissez le moteur traduire et réémettre l'arborescence.

Prêt pour les détails ? Lisez la référence de l'API REST, la référence MCP, ou le guide des webhooks. Si vous configurez votre propre moteur, commencez par l'installation.