Hugo : générateur de sites statiques, éditions et vitesse

Qu'est-ce que Hugo ?

Hugo est un générateur de sites statiques (static site generator) open source, écrit en Go. Il lit du contenu Markdown, des templates et un fichier de configuration, puis écrit un dossier de HTML, CSS et JavaScript simples que n'importe quel serveur web ou CDN peut servir. Il se distribue sous la forme d'un seul exécutable et, selon son propre site, il génère un gros site en quelques secondes, souvent moins.

Hugo fait partie de la famille de la génération de sites statiques : les pages sont construites une fois, à l'avance, plutôt qu'à chaque requête. Il côtoie ainsi Astro dans la boîte à outils Jamstack, avec un compromis différent : Hugo utilise des templates Go sans environnement d'exécution JavaScript, alors qu'Astro repose sur un modèle de composants JavaScript.

Comment fonctionne un site Hugo

Un projet est un dossier contenant quelques répertoires conventionnels (d'après la documentation Hugo) :

my-site/
  archetypes/   modèles pour le nouveau contenu
  assets/       CSS, Sass, JS et images pour le pipeline d'assets
  content/      pages Markdown
  data/         fichiers de données (JSON, TOML, YAML, XML)
  i18n/         tables de traduction
  layouts/      templates
  static/       copié tel quel dans public/
  themes/       thèmes facultatifs
  hugo.toml     configuration du site
  public/       site généré (créé par le build)

Vous écrivez une page en Markdown, avec le front matter en tête :

+++
title = 'Mon premier article'
date = 2026-10-23
draft = false
+++

Bonjour, **Hugo**. Ce Markdown devient une page HTML au moment du build.

Un template dans layouts/ enveloppe ce contenu dans le HTML de votre site. Deux commandes couvrent l'essentiel du travail quotidien :

hugo server -D    # serveur de développement local, brouillons inclus
hugo --minify     # construit le site dans public/

Le contenu créé avec hugo new content démarre en brouillon : il reste hors d'un build normal tant que vous n'avez pas mis draft = false. Hugo gère aussi les sites multilingues, les taxonomies comme les tags, les shortcodes, plusieurs formats de sortie (HTML, plus RSS ou JSON) et le traitement d'images, comme le redimensionnement et le recadrage.

Éditions standard, extended et deploy

Hugo est publié en plusieurs éditions. L'édition standard couvre le cœur. L'édition extended ajoute la prise en charge de LibSass pour Sass (la documentation indique que LibSass est obsolète et recommande Dart Sass, qui fonctionne avec toutes les éditions). L'édition deploy ajoute l'envoi direct vers un bucket AWS S3, Google Cloud Storage ou Azure Storage, et extended/deploy cumule les deux. La documentation recommande l'édition standard, sauf besoin des extras. Vous n'avez besoin de Go que pour compiler Hugo depuis les sources ou utiliser les Hugo Modules. Le guide d'installation liste toutes les plateformes.

Hugo est-il vraiment rapide ?

La vitesse de build est le principal argument de Hugo, mais mieux vaut lire avec prudence les chiffres qui circulent. La documentation décrit la vitesse en termes qualitatifs et ne publie aucun benchmark ; votre temps de build dépend du nombre de pages, de la complexité des templates, du traitement d'images et de la machine. Mesurez votre propre build avant de comparer des générateurs. Et un build rapide ne rend pas un site rapide : les visiteurs ne ressentent que ce que vous livrez, c'est-à-dire du HTML, du CSS, du JavaScript et des images.

Exemple : un site de documentation

Une équipe gère 300 pages Markdown dans Git. Chaque push déclenche un job de CI qui exécute hugo --minify et envoie public/ vers un hébergement statique placé derrière un CDN. Le guide d'hébergement de Hugo cite notamment AWS Amplify, Azure Static Web Apps, Cloudflare, Firebase, GitHub Pages, GitLab Pages, Netlify, Render, Vercel, ainsi que rsync ou FTP. Il n'y a aucun serveur d'application à patcher ni à dimensionner.

Erreurs courantes

• Versions de thème non figées. Une mise à jour du thème peut changer votre mise en page. Figez le commit du thème ou la version du module.
• Oublier les brouillons. Une page absente du site en ligne est souvent encore en draft = true.
• Utiliser des fonctions réservées à extended avec le binaire standard. Vérifiez l'édition installée par votre CI, pas seulement celle de votre poste.
• Attendre un comportement à l'exécution. Hugo n'a pas d'environnement serveur. Formulaires, recherche et commentaires passent par un service tiers ou une fonction serverless ; pour un rendu à chaque requête, le rendu côté serveur convient mieux.
• Ignorer le cache d'images en CI. Les images traitées sont mises en cache dans le répertoire resources. Conservez-le entre les builds, sinon la CI refait le travail à chaque fois.
• Contenu périmé. Les données sont figées au moment du build : un CMS headless a donc besoin d'un webhook qui déclenche un nouveau build.

Hugo, tests de performance et monitoring

La sortie statique retire le serveur d'application du chemin de la requête, mais la page peut rester lente à cause d'images lourdes, de scripts tiers ou d'un cache mal configuré. Après chaque déploiement, lancez un audit Lighthouse et suivez les Core Web Vitals. LoadFocus Page Speed Monitoring exécute des audits Lighthouse planifiés depuis 25 régions cloud et vous alerte quand une métrique se dégrade. Pour la mise en place, voir comment surveiller les Core Web Vitals avec alertes et rapports (en anglais) et, pour les correctifs, 10 façons d'améliorer la vitesse de votre site (en anglais).

Questions fréquentes : Hugo

Hugo est-il gratuit ?

Oui. Hugo est open source ; vous ne payez que l'endroit où vous hébergez les fichiers générés.

Faut-il connaître Go pour utiliser Hugo ?

Vous n'avez besoin ni d'installer ni d'écrire du Go pour construire un site. En revanche, il faut apprendre la syntaxe des templates Go de Hugo pour écrire des mises en page, ce qui est le passage le plus raide de la courbe d'apprentissage. Avec un thème, vous pouvez démarrer sans écrire de template.

Édition standard ou extended ?

Commencez par l'édition standard. Passez à extended seulement si un thème ou votre pipeline d'assets l'exige, par exemple pour LibSass, et préférez Dart Sass pour tout nouveau travail avec Sass.

Hugo peut-il faire du rendu côté serveur ?

Non. Hugo génère des fichiers au moment du build. Pour des pages dynamiques, ajoutez du JavaScript côté client ou des fonctions serverless, ou choisissez un framework qui rend côté serveur.

Où héberger un site Hugo ?

Partout où l'on sert des fichiers statiques : Cloudflare, Netlify, GitHub Pages, GitLab Pages, Vercel, AWS Amplify ou votre propre bucket S3 avec CDN, entre autres.

Hugo gère-t-il plusieurs langues ?

Oui. Hugo intègre la gestion du multilingue, avec du contenu traduit et des tables de traduction dans le répertoire i18n.