~/sessions/construire-un-blog-sur-mesure-avec-astro-et-payload

SESSION / working transcript

Construire un blog sur mesure avec Astro et Payload

Les décisions clés derrière un blog auto-hébergé, éditable dans Payload et entièrement dessiné avec Astro.

transcript / start18 messages
01Paulpaul

Je veux un blog auto-hébergé, un seul auteur, pas de newsletter. Par contre je veux de l’analytique, et surtout quelque chose de beaucoup plus configurable qu’un style template. J'aimerais bien un style terminal.

02Agentagent

Très bien. Je m'en charge tout de suite.

Building

  1. 01
    Defining structure
  2. 02
    Build home page
  3. 03
    Generate article parser
  4. 04
    Writing first article
  5. 05
    Building CSS style
  6. 06
    Deploy and open preview
03Paulpaul

J'aime beaucoup. Nouvelle idée, on va publier les articles en mode session chat, avec les messages, les commandes et les résultats d’outils ? Et garder aussi un blog classique dans la même liste ? Aussi tu m'as fait un simple site, mais comment je peux éditer mes blogs facilement ?

04Agentagent

Oui. Les deux formats peuvent cohabiter dans la même liste. Chaque contenu indiquera simplement son format : un article classique avec un corps éditorial, ou une session composée de messages, de commandes et de résultats d’outils. Le site utilisera ensuite le rendu adapté.

Pour l’édition, modifier directement des fichiers Markdown finirait vite par être contraignant. Il nous faut une interface capable de gérer les brouillons, les médias, les métadonnées et la prévisualisation avant publication.

Parmi les solutions disponibles, Publii semble être la plus simple pour tes besoins. Tu pourrais rédiger depuis une application desktop, personnaliser entièrement le thème, puis générer le site localement et le publier sur ton serveur via SFTP.

05Agentagent · tool call
tool call
$ Building demo with Publii
06Paulpaul

Publii a l'air pratique, mais est-ce qu’il nous sert vraiment à quelque chose si on refait tout le thème et le mode de publication ?

07Agentagent

Plus vraiment. Publii est très efficace pour générer rapidement un site statique à partir d’un thème. Mais si l’on personnalise le modèle éditorial, les sessions, les composants et la prévisualisation, on risque de passer notre temps à contourner son fonctionnement.

Astro serait plus adapté : le site resterait léger, rapide et largement statique, tout en nous laissant contrôler chaque détail du rendu.

08Paulpaul

Ok, go Astro. Mais je perds l'interface admin ? Je veux une interface avec des brouillons, des médias et une vraie preview avant publication.

09Agentagent

On peut séparer l’édition de l’affichage.

Un CMS headless (Payload/Directus) conserverait les contenus, les versions, les brouillons et les médias. Astro récupérerait ces données et resterait entièrement responsable du site public.

La prévisualisation ne serait pas une approximation dans le CMS : elle ouvrirait le véritable site Astro avec le contenu encore en brouillon.

10Paulpaul

Je préfère Payload qui a l'air plus simple, fais-moi une démo locale.

11Agentagent

Je vais créer une collection unique, appelée « Publications », avec un champ qui détermine le format : article ou session.

Les deux partageront les métadonnées communes — titre, résumé, image, date, statut et URL — puis disposeront de leur propre structure. Les articles auront un corps éditorial riche. Les sessions seront composées de messages, de notes et d’appels d’outils.

12Agentagent · tool call
tool call
$ pnpm create astro
✔ Astro project created

$ pnpm create payload-app
✔ Payload project created
✔ PostgreSQL adapter configured
✔ Drafts and versions enabled
13Agentagent

La base est prête. Je passe maintenant au modèle de contenu et à la prévisualisation.

14Agentagent · tool call
tool call
$ pnpm test:content-model
✔ article publication validated
✔ session publication validated
✔ draft preview token validated
✔ reading time calculated
15Paulpaul

J’adore la démo. On déploie ça sur mon serveur, mais réutilise le PostgreSQL qui tourne déjà. Et garde Umami en surcouche pour l'analytic, protégé comme le reste de l’admin.

16Agentagent

Je conserve l’instance PostgreSQL existante. Astro sera la seule application exposée publiquement. Payload et Umami resteront sur des sous-domaines protégés par le reverse proxy.

Avant le déploiement, je vérifie les connexions, les variables nécessaires et l’état des sauvegardes, sans toucher aux autres services du serveur.

17Agentagent · tool call
tool call
$ docker compose up -d --build
✔ payload      ready
✔ astro        ready
✔ postgresql   connected
✔ umami        healthy
✔ reverse proxy healthy
18Agentagent

Le déploiement est terminé. Le site public répond correctement, l’administration est protégée et Payload communique avec le PostgreSQL existant.