Chapitre 04Démarrer
Anatomie d'un projet
Chaque fichier, son rôle, et surtout : lesquels vous modifierez tous les jours, lesquels jamais. Plus la liste complète des commandes.
Le projet d'un site
C'est ce que produit npm create inline@latest, et c'est ce que vous versionnez
dans le dépôt du client.
mon-site/
├── astro.config.mjs ★ intégration, langues, sortie statique
├── package.json ★ scripts du site
├── wrangler.toml configuration des fonctions chez l'hébergeur
├── tsconfig.json
├── .env.example modèle de variables — le seul versionné
├── .dev.vars variables locales — ignoré par Git
├── .gitignore
│
├── functions/
│ └── api/
│ ├── auth.ts ┐
│ ├── content.ts │ quatre adaptateurs de 5 lignes,
│ ├── save.ts │ jamais une règle
│ └── upload.ts ┘
│
├── scripts/
│ ├── check-html.mjs contenu présent dans le HTML brut
│ ├── check-locales.mjs parité des clés entre langues
│ ├── check-logs.mjs aucun secret dans un console.*
│ ├── check-secrets.mjs aucun secret dans dist/
│ ├── make-key.mjs une clé et son empreinte — la rotation
│ └── mock-git-api.mjs faux dépôt local
│
├── src/
│ ├── content/
│ │ ├── config.ts déclaration de la collection (schéma du paquet)
│ │ ├── site.json ★ navigation, coordonnées, pied de page
│ │ ├── site.ts validation de site.json au build
│ │ └── pages/
│ │ ├── fr/home.json ★ LE contenu — une page, une langue, un fichier
│ │ └── en/home.json ★
│ │
│ ├── components/ ★ vos composants — statiques par défaut
│ │ └── Testimonial.astro
│ ├── layouts/
│ │ └── Base.astro ★ métadonnées, navigation, pied de page
│ ├── lib/
│ │ └── locales.ts ★ les langues de CE site
│ ├── media/ ★ les images — dans src/, pas dans public/
│ │ └── library.ts créé par l'intégration, à laisser tel quel
│ ├── pages/
│ │ └── [lang]/[...slug].astro ★ le gabarit de page
│ └── styles/
│ └── theme.css ★ LA charte : palette, échelle, rythme
│
└── .github/workflows/ci.yml contrôles automatiques★ = fichiers que vous modifiez pour un site donné.
Tous les jours
Le contenu et la charte
src/content/pages/**, src/styles/theme.css, src/components/, src/pages/[lang]/[...slug].astro.
Une fois par site
La configuration
astro.config.mjs, src/lib/locales.ts, src/content/site.json, les variables d'environnement.
Jamais
Les adaptateurs et les contrôles
functions/api/*.ts et scripts/check-*.mjs : ils sont livrés corrects. Y ajouter une règle est un symptôme, pas une solution.
Le paquet partagé
inline-core n'est pas dans le dépôt du site : c'est une dépendance, installée
dans node_modules. Sa structure sert à savoir où lire quand on cherche un
comportement.
inline-core/
├── astro/index.ts l'intégration : /admin, /aide, overlay, amorce
├── components/
│ ├── Editable.astro un champ texte ou richtext
│ ├── Media.astro une image ou une vidéo
│ └── Collection.astro une liste + son template d'item
├── pages/
│ ├── admin.astro la page de saisie de la clé
│ └── aide.astro l'aide du client, clé en main
├── styles/tokens.css une classe par valeur du schéma
└── src/
├── schema.ts LE modèle de contenu (Zod) — build ET serveur
├── style-tokens.ts les variantes autorisées, source unique
├── safe-href.ts ce qu'est un lien sûr, des deux côtés
├── video.ts lecture d'une adresse YouTube / Vimeo
├── translate.ts repli de traduction (pas la liste des langues)
├── editor/ l'overlay — TypeScript sans framework
│ ├── index.ts la boucle : un chemin, un pointeur, une mutation
│ ├── bar.ts barre flottante et bandeaux
│ ├── toolbar.ts barre de variantes et de richtext
│ ├── media.ts panneau image / vidéo
│ ├── collection.ts ajout, duplication, déplacement, suppression
│ ├── draft.ts brouillon local
│ ├── sanitize.ts assainissement côté navigateur
│ ├── heic.ts décodage des photos d'iPhone, à la demande
│ └── api.ts les appels aux quatre routes
└── server/
├── auth.ts verifyAuth / createSession — seul juge de l'identité
├── guard.ts débit, plafonds, chemins autorisés
├── rate-limit.ts comptage des appels, stockage interchangeable
├── git-provider.ts l'interface du fournisseur Git
├── github.ts implémentation GitHub (version = SHA du blob)
├── gitlab.ts signature + notes — non implémenté
├── image.ts reconnaissance des formats aux octets
├── sanitize.ts assainissement côté serveur (sans DOM)
└── routes/ les quatre routes, en fabriques configurablesCe qu'on importe, et sous quel nom
| Import | Ce que c'est | Où on s'en sert |
|---|---|---|
inline-core/astro | L'intégration | astro.config.mjs |
inline-core/schema | Schémas Zod et types | src/content/config.ts, composants |
inline-core/style-tokens | Enums de style et styleClasses() | Composants, outillage |
inline-core/components/Editable.astro | Champ texte / richtext | Les pages |
inline-core/components/Media.astro | Image ou vidéo | Les pages |
inline-core/components/Collection.astro | Liste + modèle d'item | Les pages |
inline-core/styles/tokens.css | Classes des tokens | Le layout |
inline-core/server | Les quatre fabriques de routes | functions/api/*.ts |
inline-core/translate | mergeWithDefault, localePath | src/lib/locales.ts |
inline-core/video | parseVideoUrl, embedUrl | Composants, outillage |
Les commandes
Dans un site
npm run dev # serveur Astro seul — la mise en page, sans l'édition
npm run build # build de production (échoue si le contenu est invalide)
npm run serve:functions # site + fonctions : c'est ici qu'on édite
npm run mock:git # faux dépôt Git local
npm run make:key # une clé et son empreinte — la rotation
npm run check # HTML brut + parité des langues + journaux + secretsDans le dépôt de référence
npm run dev # serveur Astro seul
npm run build # build de production
npm run serve:functions # site + fonctions sur http://127.0.0.1:8788
npm run check # les quatre contrôles
npm test # toute la suite de tests
npm run create:site # prépare les accès d'un site (clé, empreinte, variables)
npm run make:key # une clé et son empreinte — la rotation
npm run bootstrap # extrait le contenu d'une page HTML annotée
npm run mock:git # faux dépôt Git local
npm run test:scaffold # crée un site de zéro, l'installe, le construit, le contrôle
npm run test:pack # idem, depuis les archives qu'une publication produirait
npm run pack:core # fabrique l'archive d'inline-core
npm run release:core # publie inline-core sur le registre
npm test et npm run check — ce sont exactement celles que lance
l'intégration continue, et elles bloquent la branche. Un contrôle qui ne bloque pas se
contourne, puis se désactive, puis disparaît.
Où va une modification ?
La question se pose à chaque évolution, et une seule mauvaise réponse suffit à faire diverger dix sites. Le critère est simple : est-ce que ce serait vrai chez tous les clients ?
| Vous voulez… | Où |
|---|---|
| changer une couleur, une taille de titre, une police | src/styles/theme.css du site |
| ajouter une page, un bloc, une section | src/content/pages/… + le gabarit de page |
| ajouter une langue | astro.config.mjs, src/lib/locales.ts, scripts/check-locales.mjs |
| ajouter un type de champ (ex. un tableau) | inline-core/src/schema.ts — version majeure |
| changer un plafond de taille, un budget de débit | inline-core/src/server/guard.ts |
| corriger un message affiché au client | inline-core/src/editor/* |
| supporter un nouveau fournisseur Git | inline-core/src/server/ + GIT_PROVIDER |
| ajouter une vérification d'identité | inline-core/src/server/auth.ts, et nulle part ailleurs |
Si vous vous apprêtez à écrire une règle dans functions/api/*.ts, arrêtez-vous.
Ces fichiers ne contiennent que trois lignes d'assemblage. Une règle qui y apparaît est une
règle qu'il faudra retrouver dans chaque dépôt de client le jour où elle changera.
Ce que le site doit fournir au paquet
Trois choses, et trois seulement :
- sa configuration — les langues, passées à l'intégration et aux routes ;
- son contenu —
src/content/pages/{langue}/{page}.json; - son apparence — les variables CSS attendues par
tokens.css, ses composants, sa mise en page.
Si cette liste s'allonge, c'est le signe qu'une décision du paquet a fuité vers les sites.