Pourquoi je construis sur Astro
Après mon premier build propre de ce site, j’ai lancé 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.
Ce chiffre, plus que n’importe quel benchmark, est la raison pour laquelle je suis resté.
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 grain. Astro est ce avec quoi j’ai fini par expédier, et après quelques semaines, je veux poser ce qui a marché et ce qui m’a piqué, dans l’esprit d’un carnet de terrain, pas d’une critique.
Statique, à nouveau
Astro, au fond, c’est un retour au site statique. Le HTML est l’artefact. Le Markdown est la source. Le navigateur reçoit la page déjà construite, et va se coucher.
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 : n’envoyer rien par défaut. Si vous voulez de l’interactivité, vous l’ajoutez, île par île. Je n’ai opté pour aucune. 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 célébrée du framework (l’hydratation partielle, les îles) est celle dont je n’ai pas eu besoin. La discipline du rien par défaut, si.
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 défauts 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.
Le plugin avait codé en dur sa propre palette sous prose-invert, et gagnait la cascade contre 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 défauts du plugin. Évident, rétrospectivement. Pas évident à 23 h.
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 d’en laisser un seul posséder la palette et de tout faire passer par lui.
Là où le framework gagne sa croûte
Trois choses dans Astro qui me manqueraient si je partais.
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.
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.
Ce ne sont pas des fonctionnalités qui font de belles démos. Ce sont du genre qu’on cesse de remarquer, et c’est le plus grand compliment qu’un framework puisse recevoir.
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, plus propre, et l’écart avec la mémoire musculaire de la v3 a été réel.
La réserve : la documentation est en pleine migration. La moitié des tutoriels en ligne supposent encore la v3. Quand quelque chose ne marche pas, vous déboguez parfois la version, pas le code. J’y ai perdu une heure une fois. J’y reperdrais une heure.
Si vous démarrez un projet aujourd’hui, la v4 est le bon choix. Prévoyez juste quelques détours du genre « est-ce moi ou est-ce une réponse de l’époque v3 ? ».
Pourquoi ça colle au Small Web
Une philosophie vaut ce que ses outils incarnent.
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 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 présument 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 partir.
Je produis. Je pars. Le dossier est téléversé, GitHub Pages le sert, et je referme le portable.
C’est tout le métier.
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.