inline-core 2.1.0 · périmètre v1 gelé

Le client modifie son site
sur sa page.

Le contenu vit dans des fichiers JSON versionnés. Astro les injecte au moment du build. Une interface superposée les rend modifiables directement dans la page — et la publication écrit un commit. Pas de CMS, pas de base de données, pas de serveur applicatif à surveiller.

Lire la documentation Essayer le simulateur

$ npm create inline@latest mon-site

npm create inline@latest mon-site

$ pnpm create inline mon-site

pnpm create inline mon-site

$ bun create inline mon-site

bun create inline mon-site

Un site neuf, éditable en local, en quatre commandes.

0base de données

37 Kod'overlay, chargé pour l'éditeur seul

22chapitres de documentation

2langues, deux URL

exemple.fr/admin

Changer l’image

fournil-au-petit-matin.webp 1600 × 900 · 8,4 Mo → 210 Ko

Description de l’image

Changer la vidéo

Adresse de la vidéo

youtube · aqz-KE-bpKQ

Menuiserie sur mesure

Agencement, restauration, pose. Depuis 1974.

content/accueil.fr.json 3 modifications

4 "hero": { 5− "titre": "Menuiserie sur mesure" 5+ "titre": "Menuiserie sur mesure, depuis 1974" 6− "image": { "src": "atelier.webp", … } 6+ "image": { "src": "fournil-au-petit-matin.webp", … } 7+ "film": { "provider": "youtube", "id": "aqz-KE-bpKQ" } 8 }

+images/fournil-au-petit-matin.webp210 Ko

Aucun fichier pour la vidéo : le schéma n’en retient que le fournisseur et l’identifiant.

a3f1c92 contenu : hero — compte machine, jeton restreint

Le site

Le visiteur reçoit du HTML pré-construit. Rien à interroger, rien à réveiller.

Aucune vidéo, aucun montage : la séquence ci-dessus est la reproduction fidèle des six états que traverse une modification. Refaire la séquence en vrai →

Le geste

Six états, sans montage

C'est exactement ce que traverse une modification, de la visite au déploiement.

01 Le site Le visiteur reçoit du HTML pré-construit. Rien à interroger, rien à réveiller.

02 La clé Une clé, une fois, sur /admin. Pas de compte à créer, pas de mot de passe à réinitialiser.

03 L'édition L'overlay repère les champs éditables et les rend modifiables là où ils sont.

04 Les médias La photo est recadrée et convertie en WebP dans le navigateur avant de partir. La vidéo, elle, n'entre jamais dans le dépôt : le schéma n'en retient que le fournisseur et l'identifiant.

05 La publication Les modifications partent vers le dépôt, signées par un compte machine à droits restreints.

06 La mise en ligne Le site public est régénéré. L'historique du contenu est l'historique Git.

Le problème

Un site vitrine n'a pas besoin d'un CMS. Il a besoin d'un client autonome.

Entre « le client ne peut rien changer » et « on lui installe un CMS complet », il manquait une marche. inline occupe exactement cette marche.

Sans rien

Le client vous écrit

Une virgule à corriger devient un ticket.
Vous facturez dix minutes ou vous les offrez.
Le site se périme parce que personne ne le touche.

Avec un CMS

Vous entretenez une infrastructure

Une base de données, des mises à jour, des sauvegardes.
Un back-office que le client traverse pour changer un mot.
Une surface d’attaque, pour trois pages de contenu.

Avec inline

Le contenu reste du code

Des fichiers JSON dans le dépôt, validés par un schéma.
Le client modifie sur la page, sans apprendre d’interface.
Rien à héberger de plus : le site reste statique.

Comment ça marche

Deux flux, et rien entre les deux

Le flux de lecture ne connaît pas l'édition. Le flux d'édition n'écrit jamais dans le site en ligne : il écrit dans le dépôt, et laisse la chaîne de build faire son travail.

Lecture Du fichier à la page 4

01 content/*.json Le contenu, versionné, lisible, diffable.
02 Schéma Zod Le build échoue si un champ manque ou change de type.
03 Astro Le contenu est injecté dans le HTML au moment du build.
04 HTML statique Servi tel quel. Aucun appel au moment de la visite.

Édition De la page au dépôt 4

01 Clé de site Vérifiée par une fonction serveur, jamais par le navigateur seul.
02 Overlay Chargé pour l’éditeur uniquement. Le visiteur ne le télécharge pas.
03 Commit La publication écrit dans le dépôt via un jeton restreint.
04 CI + déploiement Le site est reconstruit et remis en ligne.

La conséquenceLe contenu et le code partagent le même historique. Un retour en arrière est un git revert, pas une restauration de sauvegarde.

À quoi ça ressemble

Trois fichiers, et la page devient éditable

Aucun langage intermédiaire à apprendre : du JSON, un schéma, un composant Astro.

content/accueil.json

{
  "titre": "Atelier Berthaud",
  "accroche": "Menuiserie sur mesure, depuis 1974.",
  "services": [
    { "id": "svc-1", "nom": "Agencement", "texte": "Cuisines et bibliothèques." },
    { "id": "svc-2", "nom": "Restauration", "texte": "Meubles anciens et parquets." }
  ]
}

{
  "titre": "Atelier Berthaud",
  "accroche": "Menuiserie sur mesure, depuis 1974.",
  "services": [
    { "id": "svc-1", "nom": "Agencement", "texte": "Cuisines et bibliothèques." },
    { "id": "svc-2", "nom": "Restauration", "texte": "Meubles anciens et parquets." }
  ]
}

src/content/schema.ts

import { z } from 'zod';

export const accueil = z.object({
  titre: z.string().min(1),
  accroche: z.string().min(1),
  services: z.array(
    z.object({
      id: z.string(),
      nom: z.string(),
      texte: z.string(),
    }),
  ),
});

import { z } from 'zod';

export const accueil = z.object({
  titre: z.string().min(1),
  accroche: z.string().min(1),
  services: z.array(
    z.object({
      id: z.string(),
      nom: z.string(),
      texte: z.string(),
    }),
  ),
});

src/pages/index.astro

---
import { field, list } from 'inline-core';
import accueil from '../../content/accueil.json';
---

<h1 {...field('accueil.titre')}>{accueil.titre}</h1>
<p {...field('accueil.accroche')}>{accueil.accroche}</p>

<ul>
  {accueil.services.map((service) => (
    <li {...list('accueil.services', service.id)}>
      <h2 {...field('nom')}>{service.nom}</h2>
      <p {...field('texte')}>{service.texte}</p>
    </li>
  ))}
</ul>

---
import { field, list } from 'inline-core';
import accueil from '../../content/accueil.json';
---

<h1 {...field('accueil.titre')}>{accueil.titre}</h1>
<p {...field('accueil.accroche')}>{accueil.accroche}</p>

<ul>
  {accueil.services.map((service) => (
    <li {...list('accueil.services', service.id)}>
      <h2 {...field('nom')}>{service.nom}</h2>
      <p {...field('texte')}>{service.texte}</p>
    </li>
  ))}
</ul>

terminal

npm create inline@latest mon-site -- --nom "Mon site" --courriel contact@exemple.fr
cd mon-site && npm install

npm run mock:git          # faux dépôt local, dans un premier terminal
npm run build             # construit le site
npm run serve:functions   # sert le site ET les fonctions

npm create inline@latest mon-site -- --nom "Mon site" --courriel contact@exemple.fr
cd mon-site && npm install

npm run mock:git          # faux dépôt local, dans un premier terminal
npm run build             # construit le site
npm run serve:functions   # sert le site ET les fonctions

Ce que ça fait

Assez pour un site vitrine. Rien de plus.

Chaque ligne ci-dessous est implémentée et documentée. Le périmètre de la v1 est gelé : ce qui manque manque volontairement.

Édition sur la page Texte, texte riche, image, listes à identifiants stables. Le client voit le résultat pendant qu’il tape.

Clé de site, pas de comptes Une clé par site, vérifiée côté serveur, révocable en une commande. Aucun utilisateur à gérer.

Schéma Zod obligatoire Le contenu est typé. Une faute de structure arrête le build au lieu de casser la page.

Publication par commit GitHub de bout en bout, GitLab documenté. Compte machine, jeton restreint, un commit par publication.

Conflits détectés Deux modifications concurrentes ne s’écrasent pas en silence : le conflit est montré au client.

Multilingue par URL Une URL par langue, pas de bascule JavaScript. La documentation applique la règle qu’elle décrit.

Images et médias Dépôt depuis la page, formats contrôlés, chemins stables dans le dépôt.

Charte tenue Un seul fichier de styles à reprendre. Le client choisit dans la charte, jamais une couleur libre.

La documentation

Vingt-deux chapitres, et deux ateliers pas à pas

Écrite pour être lue une fois dans l'ordre, puis consultée par morceaux. Deux ateliers complets la doublent d'un parcours guidé, du premier « npm create » à la mise en ligne. Bilingue, avec une palette de recherche et un simulateur d'édition.

Tutoriels

Un site neuf, éditable, en quatre commandes

Suivre le démarrage Lire « Pourquoi cet outil existe » Ouvrir la documentation

Édition de contenu en front pour sites statiques. inline-core 2.1.0 · create-inline 1.2.0

Le client modifie son site
sur sa page.

Six états, sans montage

Un site vitrine n'a pas besoin d'un CMS. Il a besoin d'un client autonome.

Le client vous écrit

Vous entretenez une infrastructure

Le contenu reste du code

Deux flux, et rien entre les deux

Trois fichiers, et la page devient éditable

Assez pour un site vitrine. Rien de plus.

Vingt-deux chapitres, et deux ateliers pas à pas

Un site complet, de A à Z

Reprendre un site HTML

Pourquoi cet outil existe

Démarrage local

Le modèle de contenu

Simulateur d'édition

GitHub, de bout en bout

Dépannage

Tout, sur une page

Un site neuf, éditable, en quatre commandes

Le client modifie son sitesur sa page.

Six états, sans montage

Un site vitrine n'a pas besoin d'un CMS. Il a besoin d'un client autonome.

Le client vous écrit

Vous entretenez une infrastructure

Le contenu reste du code

Deux flux, et rien entre les deux

Trois fichiers, et la page devient éditable

Assez pour un site vitrine. Rien de plus.

Vingt-deux chapitres, et deux ateliers pas à pas

Un site complet, de A à Z

Reprendre un site HTML

Pourquoi cet outil existe

Démarrage local

Le modèle de contenu

Simulateur d'édition

GitHub, de bout en bout

Dépannage

Tout, sur une page

Un site neuf, éditable, en quatre commandes

Le client modifie son site
sur sa page.