Pour un site éditorial principalement statique, Astro et Cloudflare forment une architecture cohérente lorsque le contenu peut être construit à l’avance, l’interactivité reste ciblée et aucun serveur applicatif n’est nécessaire pour produire chaque page.
Pour mon site, le besoin était précis : publier des pages bilingues, conserver les articles dans Git, maîtriser les métadonnées et réutiliser des composants. Il n’avait besoin ni de CMS, ni de base de données, ni d’authentification, ni de rendu côté serveur au lancement.
J’ai retenu Astro pour construire les documents et Cloudflare Workers Static Assets pour les distribuer. Leur périmètre correspondait au besoin. J’ai évalué chaque couche selon ce qu’elle ajoute au build, ce qu’elle livre au navigateur et ce qu’elle impose en exploitation.
Partir du contrat de sortie
Avant de choisir un framework, il faut déterminer ce qui doit réellement se passer lors d’une requête.
Ici, le navigateur doit recevoir une page HTML déjà constituée, sa feuille de style et ses ressources. Le contenu ne dépend ni de l’identité du visiteur, ni d’une donnée calculée à la volée. Une modification éditoriale peut déclencher une nouvelle construction du site.
Ces contraintes rendent la génération statique adaptée. Les routes sont connues pendant le build, les variantes françaises et anglaises sont produites séparément, le contenu est validé avant publication et l’interactivité ciblée peut rester progressive.
Le projet utilise Astro 7.1.3 avec une sortie static :
export default defineConfig({
site: "https://vincentcassiau.com",
output: "static",
trailingSlash: "always",
i18n: {
defaultLocale: "en",
locales: ["fr", "en"],
routing: {
prefixDefaultLocale: true,
redirectToDefaultLocale: false
}
}
});Les URL /fr/ et /en/ correspondent ainsi à des documents distincts. Elles ne
sont pas produites par un serveur à chaque visite. Cette séparation rend
explicites les URL canoniques, les relations hreflang et les liens internes.
Elle suit aussi la recommandation de Google d’utiliser
des URL différentes pour chaque version linguistique.
Astro organise le build, pas le runtime
Du HTML et du CSS écrits directement auraient fourni une sortie tout aussi immédiate. Pour quelques pages stables, sans contenu structuré ni logique partagée, cette solution peut rester la plus simple.
Astro me donne un cadre pour les composants, le routage et le contenu typé tout en conservant cette sortie statique. Ce parti pris correspond à ma manière d’aborder un site de contenu : commencer par le document, puis ajouter du JavaScript uniquement là où il apporte une interaction utile.
Par défaut, Astro rend ses composants en HTML sans runtime client. Un composant
de framework n’est hydraté dans le navigateur que si une directive client:*
l’indique. Des scripts explicites peuvent néanmoins être livrés sans
hydratation. Cette distinction est au cœur de
l’architecture en îlots d’Astro.
Ces mécanismes deviennent utiles lorsque plusieurs préoccupations doivent rester cohérentes : layouts partagés, variantes linguistiques, métadonnées, pages de listing, flux RSS, données structurées et règles de publication.
Les Content Collections permettent notamment de décrire les métadonnées par un schéma. Sur ce site, un article doit annoncer sa langue, sa clé de traduction, sa révision, son domaine et son statut de publication. Le build rejette une entrée invalide et TypeScript connaît ensuite la forme du contenu.
Les mêmes garanties pourraient être assemblées avec des scripts maison. Il faudrait maintenir séparément le chargement et la validation du contenu, le routage, la génération des pages et les types. Ici, Astro réunit ces mécanismes au build sans ajouter de runtime applicatif.
React, Next.js et Astro ne couvrent pas le même périmètre
React et Next.js ne désignent pas le même niveau d’abstraction. React fournit une bibliothèque pour construire des interfaces. Il ne détermine pas, à lui seul, la stratégie de rendu ou de déploiement. Sa documentation recommande d’ailleurs de démarrer une nouvelle application avec un framework.
Next.js réunit davantage de capacités : application React, rendu statique, rendu serveur, composants serveur, routes applicatives et fonctions dynamiques. Elles deviennent utiles pour un produit interactif ou personnalisé.
Il serait inexact de le réduire à une application monopage entièrement hydratée.
Avec output: "export",
Next.js génère un fichier HTML par route.
Les Server Components compatibles sont exécutés pendant le build et la sortie
peut être servie sans serveur Node.js.
Ces capacités ne sont pas toutes prises en charge par l’export statique. Les comportements dépendant de la requête et les Server Actions demandent un runtime serveur. Les en-têtes et redirections peuvent aussi être pris en charge par l’infrastructure d’hébergement.
Pour mon besoin, la différence tient surtout au périmètre. Astro rend les composants en HTML et demande une décision explicite pour chaque zone interactive. Next.js organise une application React capable d’évoluer vers davantage de comportements côté client ou côté serveur. Les deux peuvent produire du statique, mais ils ne structurent pas le projet autour des mêmes besoins.
Pour ce site, le contenu, le routage bilingue et les composants de présentation étaient centraux. Aucune fonctionnalité ne nécessitait le modèle applicatif plus large de Next.js.
Cloudflare prend le relais à la livraison
Astro produit les artefacts. Cloudflare les distribue et peut exécuter une logique ciblée au bord du réseau. Les deux couches répondent à des problèmes différents.
Avec Workers Static Assets, les fichiers statiques et le Worker sont déployés dans une même unité. Une URL qui correspond à un asset est servie en mode asset-first par défaut. Le code du Worker reste disponible pour les requêtes qui ne correspondent pas à un fichier ou pour les routes explicitement configurées en Worker-first.
La configuration retenue ne place que la racine / en Worker-first :
{
"assets": {
"directory": "./dist/",
"binding": "ASSETS",
"run_worker_first": ["/"],
"not_found_handling": "404-page",
"html_handling": "force-trailing-slash"
}
}Le tableau run_worker_first permet de
cibler les routes qui exécutent le Worker avant la résolution des assets.
La racine neutre lit l’en-tête Accept-Language, puis répond par une
redirection temporaire vers /fr/ ou /en/. Elle envoie
Vary: Accept-Language et Cache-Control: private, no-store, puisque la
destination dépend de la requête.
Les liens internes pointent directement vers une URL linguistique, et seules ces variantes sont destinées à l’indexation. Les pages localisées qui correspondent aux fichiers construits, le CSS et les autres ressources restent servis asset-first. Les en-têtes de sécurité et les politiques de cache sont déclarés avec les fichiers statiques, sans ajouter une application serveur pour chaque page.
Cloudflare permet aussi de régler la mise en cache, la compression, la version minimale de TLS, la redirection vers HTTPS et la politique HSTS sans modifier le rendu Astro. Ces préoccupations restent dans la couche de livraison, pas dans le code des pages.
Au 25 juillet 2026, Cloudflare indique que les requêtes servant des Static Assets sont gratuites et illimitées, et qu’aucun coût supplémentaire n’est facturé pour leur stockage. Les invocations du Worker restent soumises aux limites et à la tarification du plan. Ce modèle convient bien à une surface majoritairement statique, à condition de vérifier cette politique au moment d’évaluer les coûts.
CyberVanguard reprend la même séparation entre build Astro et livraison Cloudflare pour un site distinct.
Résultats sur la version en ligne
Une fois le site publié, j’ai mesuré les accueils, les index du Carnet et les articles en français et en anglais. Toutes ces pages ont obtenu 100 en performance, accessibilité, bonnes pratiques et SEO.
| Surface | Performance · Accessibilité · Bonnes pratiques · SEO | LCP maximal | CLS maximal | TBT maximal | Transfert maximal |
|---|---|---|---|---|---|
| Accueils FR/EN | 100 · 100 · 100 · 100 | < 1,3 s | 0 | 0 ms | < 16 Kio |
| Carnet FR/EN | 100 · 100 · 100 · 100 | < 1,3 s | 0 | 0 ms | < 16 Kio |
| Articles FR/EN | 100 · 100 · 100 · 100 | < 1,3 s | 0 | 0 ms | < 20 Kio |
Astro construit des documents HTML prêts à servir, accompagnés d’une feuille CSS. Cloudflare les distribue sans exécuter un serveur applicatif pour chaque visite. Aucun runtime de framework n’est chargé dans le navigateur.
Le Carnet ajoute uniquement le JavaScript nécessaire à sa recherche, à ses filtres et à son tri. Ce script reste limité au listing des articles. Cette interaction reste légère : la page la plus lourde mesurée reste sous 20 Kio transférés, avec un LCP inférieur à 1,3 seconde, aucun décalage de mise en page et aucun temps de blocage relevé.
Ce que cette architecture coûte
La génération statique déplace le travail au moment du build. Chaque modification de contenu exige une nouvelle construction et un nouveau déploiement.
Ce compromis fonctionne lorsque les publications sont contrôlées et que leur fréquence reste compatible avec ce cycle. Dans la configuration entièrement statique retenue ici, une donnée qui doit varier à chaque requête nécessiterait une couche cliente ou serveur supplémentaire.
Le contenu dans Git fournit un historique précis et des validations contrôlées par le projet. Il peut devenir contraignant pour une équipe éditoriale qui a besoin d’aperçus, de rôles, de planification et d’une interface de contribution. Un CMS répondrait alors à un besoin réel.
Le bilingue a aussi un coût. Deux URL bien structurées ne garantissent ni la qualité de l’adaptation ni la parité factuelle des deux versions. Les schémas de contenu et les contrôles de build propres au projet peuvent détecter une traduction absente ou une révision différente. La revue éditoriale reste indispensable.
Cloudflare n’est pas nécessaire pour servir un dossier statique. Un hébergeur capable d’appliquer les en-têtes et la politique de cache attendus peut suffire. Ici, Cloudflare réunit la distribution des assets et le traitement ciblé de la racine neutre.
Choisir le niveau d’abstraction suffisant
En pratique, je regarderais quatre situations :
- Quelques pages immuables sans contenu structuré peuvent rester en HTML et CSS directs.
- Un site éditorial statique, multilingue et composé de contenus validés trouve dans Astro un cadre proportionné.
- Un produit organisé autour de React, une préférence d’équipe pour cet écosystème ou un besoin de ses capacités applicatives peuvent rendre Next.js cohérent, y compris avec un export statique.
- Une réponse personnalisée, une authentification ou des données calculées à chaque requête demandent une couche dynamique.
Cloudflare est une décision distincte. Il devient utile lorsque des artefacts statiques doivent être distribués avec des politiques de cache, des en-têtes et quelques décisions ciblées au bord du réseau. Une simple distribution de fichiers peut s’en passer.
Pour mon site, Astro est à la fois un choix technique et une préférence. J’aime sa philosophie : partir du HTML, ajouter du JavaScript seulement lorsqu’il apporte quelque chose et conserver un build que je peux lire. Cloudflare complète cette approche à la livraison. Ce n’est pas la seule combinaison valable, mais c’est celle que j’ai envie de maintenir ici.