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.
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.
Très bien. Je m'en charge tout de suite.
Building
- 01Defining structure
- 02Build home page
- 03Generate article parser
- 04Writing first article
- 05Building CSS style
- 06Deploy and open preview
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 ?
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.
$ Building demo with PubliiPublii 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 ?
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.
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.
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.
Je préfère Payload qui a l'air plus simple, fais-moi une démo locale.
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.
$ pnpm create astro
✔ Astro project created
$ pnpm create payload-app
✔ Payload project created
✔ PostgreSQL adapter configured
✔ Drafts and versions enabledLa base est prête. Je passe maintenant au modèle de contenu et à la prévisualisation.
$ pnpm test:content-model
✔ article publication validated
✔ session publication validated
✔ draft preview token validated
✔ reading time calculatedJ’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.
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.
$ docker compose up -d --build
✔ payload ready
✔ astro ready
✔ postgresql connected
✔ umami healthy
✔ reverse proxy healthyLe déploiement est terminé. Le site public répond correctement, l’administration est protégée et Payload communique avec le PostgreSQL existant.