Pourquoi je construis sur Astro
Sommaire
Après mon premier build propre de ce site, j’ai lancé un petit du -sh dist/. Moins de 150 Ko. L’ensemble (chaque page, chaque feuille de style, chaque asset) tiendrait sur une disquette de 1996 avec de la place en rabe. Ça ne nous rajeunit pas ;-)
C’est ce chiffre, plus que n’importe quel benchmark, qui m’a fait rester.
Je tournais autour des frameworks web depuis des mois. Eleventy, Hugo, du HTML brut, même un flirt rapide avec un build Python fait main. Chaque option avait son caractère. C’est avec Astro que j’ai fini par mettre en ligne, et après quelques semaines, je veux poser ce qui a marché et ce qui m’a un peu gonflé, dans l’esprit d’un journal de bord, pas d’une critique.
Statique, à nouveau
Astro, au fond, c’est un retour au site statique. Le Markdown est la source et le HTML le produit fini : le navigateur reçoit la page déjà construite, et n’a plus rien à faire.
Ce n’est pas un détail. Pendant quinze ans, l’industrie nous a dit que le statique était insuffisant : qu’il nous fallait des runtimes, de l’hydratation, une couche de calcul entre l’auteur et le lecteur. Résultat : un blog personnel embarque aujourd’hui un mégaoctet de JavaScript pour rendre six paragraphes de prose.
La promesse d’Astro est l’inverse : ne rien envoyer par défaut. Si vous voulez de l’interactivité, vous l’ajoutez, île par île. Je n’ai opté pour aucune à ce jour, juste pour voir. Il n’y a sur ce site aucun JavaScript que le navigateur soit forcé d’exécuter. Le thème clair/sombre bascule via prefers-color-scheme en pur CSS. Le flux RSS est un fichier XML statique produit au build. Les dates sont rendues au build, pas à l’exécution.
La fonctionnalité la plus mise en avant du framework (l’hydratation partielle, les îles) est celle dont je n’ai pas eu besoin, pour le moment du moins.
Le piège du prose-invert
La première vraie friction a été cosmétique, et m’a coûté une soirée.
J’utilise @tailwindcss/typography pour styler la prose. Le plugin arrive avec des réglages par défaut raisonnables : couleurs, espacements, un mode prose-invert pour les fonds sombres. J’avais branché mes propres variables CSS pour le thème (un jeu pour le sombre, un pour le clair, échangés via @media (prefers-color-scheme: light)), et j’ai regardé la prose en mode sombre s’afficher en sombre-sur-sombre. Illisible. C’est en forgeant qu’on devient forgeron, n’est-ce pas ?
Le plugin avait codé en dur sa propre palette sous prose-invert, et l’emportait dans la cascade sur mes variables. Le correctif a été de lier directement les propriétés CSS du plugin à mes variables de thème :
.prose {
--tw-prose-body: var(--text-color);
--tw-prose-headings: var(--text-color);
/* ...etc */
}Une poignée de lignes, déclarées en dehors de @layer base pour qu’elles l’emportent sur les valeurs par défaut du plugin. C’est évident avec le recul, beaucoup moins à 23 h quand on débute sur un outil.
Leçon : quand un framework propose un « mode sombre » et que vous avez déjà votre propre système de thème, attendez-vous à ce qu’ils se battent. Le contrat le plus propre, c’est de confier la palette à un seul des deux et de lui faire confiance.
Là où le framework gagne sa croûte
Trois choses dans Astro qui me manqueraient s’il n’existait pas.
Les content collections. Des fichiers Markdown dans un dossier, un schéma Zod pour le frontmatter, et le build refuse de publier un article avec une date mal formée ou un titre manquant. Des garde-fous éditoriaux, gratuits.
L’API getCollection. Lister les articles, les trier, filtrer ce qu’on veut : trois lignes de TypeScript. Pas de CMS, pas de base de données, pas de panneau d’admin. Le système de fichiers est la base de données. Simple et efficace.
Le plugin RSS. @astrojs/rss lit la collection et émet un flux valide. Pas de XML manuel, pas de gabarit, pas de service tiers. Le canal de distribution principal du Small Web, produit comme effet de bord du build.
Ces fonctionnalités ne font pas de belles démos. On finit par ne plus les remarquer, mais pour un framework c’est un beau compliment.
Tailwind v4, avec quelques réserves
Tailwind v4 était l’autre pari. Le plugin Vite remplace l’ancienne chaîne PostCSS ; la configuration migre dans le CSS lui-même via @theme et @plugin. C’est plus rapide et plus propre, et j’ai bien senti l’écart avec mes réflexes de la v3.
La réserve : la documentation est en pleine migration. Beaucoup de tutoriels en ligne supposent encore la v3. Quand quelque chose ne marche pas, vous déboguez parfois la version, pas le code.
Si vous démarrez un projet aujourd’hui, la v4 est le bon choix. Prévoyez juste quelques pertes de temps du genre « est-ce moi ou suis-je sur une doc v3 ? ».
Pourquoi ça colle au Small Web
Une philosophie se juge aussi à ses outils.
Les défauts d’Astro coïncident avec les défauts du Small Web : pas de JavaScript embarqué sauf demande ; pas de primitives de tracking ; pas de verrouillage cloud ; l’artefact de build est un dossier de fichiers qu’on pourrait héberger sur une petite clé USB. Le framework ne vous demande pas de troquer votre souveraineté contre de l’ergonomie.
C’est plus rare qu’il n’y paraît. La plupart des frameworks modernes supposent que vous voulez déployer sur un cloud précis, router via un réseau edge précis et confier votre contenu à un runtime précis. Astro vous laisse produire un dossier dist/ et passer à autre chose.
J’écris, je pousse sur main et je pars : la CI construit le site, GitHub Pages le sert et je tourne la page.
C’est tout ce qu’on lui demande.
La perfection est atteinte, non pas lorsqu’il n’y a plus rien à ajouter, mais lorsqu’il n’y a plus rien à retirer.
Antoine de Saint-Exupéry, Terre des hommes, 1939
Mise à jour, 20 mai 2026. Depuis l’écriture : une version FR du site, un second flux RSS, et dist/ pèse aujourd’hui environ 400 Ko. La disquette de 1996 a encore de la place.