Comment ça marche

Cette page décrit ce que fait réellement Flexweg CMS quand vous cliquez sur Publier, et pourquoi le frontend public peut rester 100% statique.

Le pipeline en cinq étapes

À chaque publication, l'admin :

1. Lit les données depuis le backend actif (Firestore en mode Firebase, le fichier SQLite via /api/v1/sqlite/* en mode SQLite — le code admin est agnostique du backend, dispatché à travers src/services/*.ts)
2. Rend la page en exécutant le template du thème actif (React) via react-dom/server.renderToStaticMarkup dans le navigateur
3. Calcule un hash du HTML produit pour détecter si quoi que ce soit a changé depuis la dernière publication
4. Envoie le fichier sur Flexweg via l'API Files au chemin cible du post (<categorie>/<slug>.html, <page>.html, etc.)
5. Cascade : régénère aussi la home et chaque archive de catégorie pour que les listings restent à jour

Pourquoi tout se passe côté navigateur

Pas de serveur de build, pas d'edge function, pas de pipeline CI sur le frontend public. Le rendu théorique d'un thème pourrait avoir lieu n'importe où, mais le faire dans le navigateur a deux avantages :

• Aucune infra à maintenir côté hébergement public — le seul service externe est Firebase (ou rien, en mode SQLite) et l'API Files de Flexweg
• Le cycle de feedback est instantané — vous voyez le rendu réel au moment où vous éditez, le bouton Publier n'a plus qu'à uploader

Le frontend public vu de l'extérieur

Du point de vue d'un visiteur, votre site est juste un ensemble de fichiers HTML/CSS/JS déposés sur Flexweg. Aucun script ne tourne côté serveur. Pour chaque URL visitée, Flexweg sert :

• Le HTML du post / de la page / de l'archive
• La CSS du thème (/theme-assets/<theme-id>.css)
• Les loaders JavaScript runtime du thème (menus dynamiques, recherche, hide-on-scroll, etc.)
• Les médias uploadés (media/<année>/<mois>/...)

C'est tout. Pas de cookies de session côté public, pas de back-office en production, pas de surface d'attaque applicative.

Qu'est-ce qui change entre les deux backends ?

Une seule chose, et elle est invisible pour le contenu publié : où l'admin lit ses posts/pages/médias/réglages avant le rendu. Le rendu HTML produit et le contenu uploadé sont strictement identiques.

• Firebase — subscribeToPosts(...) écoute Firestore en temps réel
• SQLite — subscribeToPosts(...) poll /api/v1/sqlite/version toutes les ~4 s ; quand la version change, refetch

Tout le code applicatif au-dessus du dispatcher (src/services/posts.ts, etc.) est strictement le même. Vous pouvez basculer d'un backend à l'autre via Réglages → Backend de données ; la migration de contenu se fait par export/import.