La question arrive souvent sous une forme qui pose problème dès la première ligne : "Astro 6 ou Hugo 13 ?". Il n'existe pas de Hugo 13. Il n'existe même pas de Hugo 1.0. Le générateur de sites statiques écrit en Go est toujours versionné en 0.x, et en octobre 2026, la dernière release publiée est la v0.167.0. Le bon comparateur face à Astro 6 est donc Hugo 0.167 - et les deux outils ne répondent pas exactement à la même question.
D'abord, remettre les versions d'accord
Hugo suit une convention de versionnage choisie depuis le début : tant que l'équipe juge qu'une release peut encore casser des choses ou changer de comportement, le numéro reste en 0.x. Le fait qu'un projet n'ait jamais franchi la 1.0 après plus de dix ans d'existence ne dit rien de sa maturité ; Hugo est un outil de production utilisé sur des sites à fort trafic. C'est une convention de numérotation, pas un signal d'alerte.
La contrepartie, c'est que la confusion est facile à créer : on parle d'Astro 6, donc l'on s'attend à retrouver "Hugo 13" quelque part dans une ligne parallèle. Il n'y en a pas. En termes de rythme, les deux projets jouent à des jeux différents :
- Astro passe d'une majeure à l'autre en un peu plus d'un an et demi, avec un cycle bêta public bien visible.
- Hugo sort des versions 0.x fréquentes et incrémentales, avec une forte attention portée à la rétrocompatibilité et à la sécurité.
Le choix dépend de ce que vous préférez : une montée de version majeure qui apporte de grosses fonctionnalités à absorber, ou une amélioration continue qui vous laisse presque toujours au même endroit.
Astro 6 : ce qui change vraiment
Astro 6 est sorti le 10 mars 2026, après une bêta publique annoncée le 13 janvier. L'annonce officielle résume la philosophie de cette version : refonte complète du serveur de développement et du pipeline de build sur une architecture "runtime-agnostic", alimentée par la nouvelle Environment API de Vite.
Cela se traduit par une chose très concrète pour un blogueur : le serveur de dev exécute désormais le même runtime que celui de la production. Le problème classique "ça marche en local, ça casse une fois déployé" disparaît en grande partie, particulièrement si vous ciblez Cloudflare Workers, Bun ou Deno plutôt que Node.js. L'adapter Cloudflare fait tourner workerd à chaque étape - développement, pré-rendu, production - avec accès aux bindings (KV, D1, R2) en local.
Les autres nouveautés utiles pour un site de contenu :
- Fonts API intégrée : téléchargement, auto-hébergement, fallbacks optimisés et préchargement gérés par le framework. Fini le bricolage manuel autour des polices Google.
- API Content Security Policy (CSP) stabilisée : configuration native pour pages statiques et dynamiques, avec hachage automatique des scripts et styles.
- Live Content Collections stables : le contenu peut être récupéré à la requête, sans rebuild. Si vous publiez depuis un CMS, un article en ligne apparaît sans relancer le pipeline de build.
- Compileur Rust expérimental, successeur du compilateur Go d'origine, activable via un drapeau de configuration.
- Rendu "queued rendering" expérimental, que l'équipe présente comme atteignant "jusqu'à 2 fois plus rapide" selon ses propres benchmarks internes. À noter : c'est une affirmation du projet, pas un banc d'essai tiers, et l'équipe prévoit d'en faire la stratégie de rendu par défaut en v7.
Astro 6 impose aussi Node 22 ou supérieur, les versions 18 et 20 ayant atteint ou étant proches de leur fin de vie. La migration d'un projet existant passe par l'outil @astrojs/upgrade.
Hugo 0.167 : la stabilité comme parti pris
Hugo, lui, ne vous demande rien de tout cela. C'est un binaire unique en Go : pas de Node.js, pas de node_modules, pas de version de runtime à surveiller. Vous le téléchargez, vous lancez le build, vous obtenez un dossier statique. La licence est Apache 2.0.
La release v0.167.0 illustre bien le style de l'équipe : des améliorations précises, pas de manifeste.
- Références de partials relatives : un partial peut désormais être appelé avec
./ou../, ce qui permet de construire des arborescences de templates déplaçables et autonomes. - Slug pour les pages de branche : sections, taxonomies et pages de termes prennent désormais en charge le champ
slugen front matter, avec propagation aux enfants - très pratique pour un site multilingue. - Build possible sans fichier de configuration, comparaisons numériques exactes dans les fonctions
eq,where,inetset, résumés automatiques qui ne s'arrêtent plus au milieu d'une liste ouverte. - Correctifs de sécurité, sans exploitation connue à date de publication.
Sur les versions précédentes, l'équipe a livré le support AVIF natif (encodeur et décodeur), une réécriture complète du moteur de glob, qui affecte les motifs de montage de modules, et une montée en version de Go avec ses correctifs. L'équipe mentionne au passage une hausse des rapports de vulnérabilités qu'elle attribue surtout à la vigilance accrue des outils d'IA, pas à une dégradation du produit.
Autrement dit : Hugo ne cherche pas à vous impressionner, il cherche à ne pas vous réveiller à trois heures du matin.
Où chacun place la complexité
Les deux projets produisent des sites statiques rapides. Leur différence tient à l'endroit où ils placent la complexité.
Astro absorbe la complexité applicative. Vous écrivez des composants (.astro, JSX, Vue, Svelte, React), vous gérez un pipeline d'assets, vous disposez d'un écosystème d'intégrations et d'un serveur de dev interactif. Le coût : plus de JavaScript dans la chaîne d'outils, une version de Node à suivre, et des majeures qui peuvent demander une migration.
Hugo absorbe la complexité d'exploitation. Un binaire, un dossier de contenu, des templates Go, un build rapide même sur un gros site. Le coût : le langage de template Go, moins familier pour un développeur front habitué à JSX, et une logique de templates structurée autour de layouts/ qui se lit différemment.
Le positionnement officiel de Hugo tient toujours en un slogan : "The world's fastest framework for building websites". C'est un argument que l'équipe revendique et qui a fait sa réputation. En face, Astro ne joue plus du tout la carte du petit outil de niche : son bulletin officiel de septembre 2026 signale que Mozilla, Akamai et le gouvernement américain l'utilisent, avec un catalogue de sites, des agences partenaires et une posture entreprise assumée.
Ce que les sources ne disent pas
Aucun des éléments rassemblés ici ne fournit de benchmark chiffré du temps de build Astro vs Hugo sur un même blog. Les seuls chiffres de performance disponibles sont ceux publiés par l'équipe Astro sur son propre rendu expérimental. Pas de tableau de temps de compilation inventé : si vous voulez trancher sur la vitesse brute, le test honnête reste de reprendre votre propre contenu et de chronométrer les deux.
En revanche, ces faits structurels ne demandent aucune mesure :
| Critère | Astro 6 | Hugo 0.167 |
|---|---|---|
| Langage de templates | Composants .astro, JSX, Vue, Svelte, React |
Go templates |
| Dépendance runtime | Node.js 22+ requis | Binaire unique, aucune dépendance Node |
| Serveur de dev | Refondu, aligné sur la production | Build en ligne de commande |
| Contenu dynamique | Live Content Collections (à la requête) | 100 % statique au build |
| Images | Pipeline d'images intégré, images responsives calculées à la construction | AVIF natif (encodeur et décodeur), transformation à la construction |
| Fontes | Fonts API intégrée | Gestion via les templates et ressources |
| Sécurité | API CSP native, stable | Modèle de sécurité restrictif, correctifs réguliers |
| Cycle de version | Majeures annoncées, migration outillée | 0.x incrémentales, rétrocompatibilité soignée |
| Licence | MIT (écosystème Astro) | Apache 2.0 |
Quel moteur pour quel blog
Le choix dépend moins de la mode que de votre profil.
Choisissez Hugo si :
- Vous écrivez principalement du Markdown et vous voulez que le build soit une formalité, pas une occupation.
- Votre hébergement se limite à un dossier de fichiers statiques, et vous ne voulez pas penser à Node, à
package.jsonni aux mises à jour de runtime. - Vous gérez un site multilingue : les slugs sur pages de branche de la 0.167 vont directement dans ce sens.
- Vous préférez une stabilité tranquille aux gros changements de cap.
Choisissez Astro si :
- Votre blog a vocation à devenir autre chose : un site avec des composants interactifs, des pages à rendu dynamique, un back-office connecté à un CMS.
- Vous voulez des fontes, une CSP et des images responsives gérés par le framework plutôt que par vous.
- Vous ciblez un runtime non-Node en production et vous voulez le tester en local exactement comme il tournera en ligne.
- Le JSX et l'écosystème JavaScript vous parlent davantage que les Go templates.
Le cas intermédiaire existe. Un blog purement éditorial, mis à jour une fois par jour, sans interactif, sans CMS temps réel : les deux produiront un excellent résultat, et la différence se jouera sur votre confort personnel avec le langage de templates. Dans ce cas, le critère décisif n'est pas la performance : c'est le langage que vous acceptez d'écrire chaque jour.
Une dernière précision
Si vous êtes tombé sur un comparatif "Astro 6 vs Hugo 13", sachez qu'il n'y a pas de Hugo 13 : en octobre 2026, le concurrent réel d'Astro 6 est Hugo 0.167.