Hugo, la meilleure alternative WordPress pour sites vitrines et blogs

J’ai mis des années à arrêter de proposer WordPress par défaut. Pas pour des raisons idéologiques: les benchmarks et les factures d’hébergement finissent par parler d’eux-mêmes. Depuis, Hugo est ma référence pour tout projet sans besoin d’un monolithe PHP: sites vitrines, blogs, portfolios, landing pages. Une alternative WordPress fondée sur le site statique, sans base de données ni plugins à maintenir.

Voici un tour complet des dimensions qui comptent: sécurité, performance, coût, SEO et limites réelles.

Aux origines de Hugo #

Hugo naît en 2013 sous la main de Steve Francia, développeur Go chez Google. L’objectif : générer des pages HTML depuis des fichiers Markdown, sans serveur, sans base de données, avec un temps de build en millisecondes. Go compile nativement et parallélise les opérations sans effort. Hugo hérite de cette vitesse dès le premier commit.

En 2015, Bjørn Erik Pedersen (bep), développeur norvégien, rejoint le projet et en devient le mainteneur principal. Il porte Hugo de l’expérimentation à la production : shortcodes imbriqués, multilinguisme natif, Hugo Pipes pour les assets, render hooks pour le contrôle du rendu Markdown. Le projet n’a plus jamais ralenti.

Bjørn Erik Pedersen, alias bep, est basé en Norvège. Son activité GitHub est publique et continue depuis 2015 : releases régulières, réponses aux issues, pull requests. Pour un outil de fondation qui structure un site entier, savoir qui le maintient et comment il travaille compte autant que les benchmarks.

Ce que WordPress embarque sans qu’on le lui demande #

WordPress a construit son succès sur la facilité: une installation, un thème, des plugins, et le site est en ligne en quelques heures. C’est réel. Mais cette facilité initiale a un prix qui se paie dans la durée.

Un site WordPress classique, c’est PHP côté serveur, une base de données MySQL, un tableau de bord admin exposé sur internet, des dizaines de plugins à mettre à jour, et une surface d’attaque qui explique pourquoi WordPress représente une part disproportionnée des sites hackés chaque année. En 2025, Patchstack a recensé 11 334 nouvelles vulnérabilités dans l’écosystème WordPress, soit +42% par rapport à 2024. Sucuri estime à 13 000 le nombre de sites WordPress compromis chaque jour. À chaque mise à jour de plugin, on croise les doigts pour que rien ne casse.

La répartition des failles par composant illustre où le problème se concentre:

%%{init: {'themeVariables': {'pie1': '#ef4444', 'pie2': '#f97316', 'pie3': '#fbbf24'}}}%%
pie title Vulnérabilités WordPress 2025 (Patchstack)
    "Plugins" : 91
    "Core WordPress" : 6
    "Thèmes" : 3

91% des failles viennent des plugins, et 46% d’entre elles n’avaient aucun patch disponible au moment de leur divulgation.

Ce n’est pas un problème insoluble. Un développeur sérieux peut maintenir un WordPress performant et sécurisé. Mais ça demande du temps, des compétences, et parfois un hébergement payant adapté. Pour les équipes qui développent en local, remplacer XAMPP par Docker permet d’isoler l’environnement et de reproduire les mises à jour sans risque.

Hugo n’a aucun de ces problèmes, parce qu’il n’a pas de serveur PHP, pas de base de données, pas de plugins à mettre à jour.

Un site statique, pas un site figé #

La confusion la plus fréquente: “statique” ne veut pas dire “sans interactivité”. Un site Hugo génère des fichiers HTML, CSS et JavaScript à la compilation. Ces fichiers sont servis depuis un CDN, sans calcul serveur à chaque visite.

Côté navigateur, JavaScript peut brancher n’importe quel service tiers:

• Paiement: Stripe Checkout s’intègre avec quelques lignes. Le tunnel de commande est hébergé par Stripe, la vitrine reste statique et ultra-rapide.
• Recherche instantanée: Algolia est utilisé par la documentation de Vue.js, React, Tailwind et des centaines d’autres projets. Résultats en temps réel sans serveur dédié.
• Formulaires et newsletter: Netlify Forms, Formspree, ConvertKit. Un attribut HTML ou un embed suffit à brancher un formulaire de contact ou une inscription newsletter.
• Commentaires: Giscus (basé sur GitHub Discussions) ou Disqus. Le HTML est statique, les commentaires chargent en JavaScript.
• Authentification: Auth0 ou Clerk gèrent login, OAuth et sessions sans toucher au serveur.
• PWA: un fichier manifest.json et quelques lignes de configuration suffisent à rendre le site installable sur l’écran d’accueil d’un téléphone. Aucun plugin, aucune dépendance externe.

L’architecture JAMstack découple le frontend du backend. Chaque service fait une chose bien, peut être remplacé indépendamment, et ne ralentit pas le reste du site.

Performance: des chiffres, pas des promesses #

Un fichier HTML pré-généré servi depuis un CDN, c’est fondamentalement plus rapide qu’une page PHP qui interroge une base de données à chaque requête. Ce n’est pas une opinion, c’est de la physique réseau.

En pratique, les scores Lighthouse de ce site restent proches de 100 sur les quatre métriques: Performance, Accessibilité, Bonnes pratiques, SEO. Pas uniquement sur la page d’accueil, sur l’ensemble des pages.

Ce n’est pas un exploit de configuration. C’est le résultat naturel d’une architecture statique bien construite:

• pas de JavaScript inutile chargé depuis des plugins
• pas de requêtes base de données au moment du rendu
• assets versionnés et mis en cache agressivement
• déploiement sur CDN global (Netlify dans mon cas)

Quelques chiffres pour illustrer l’écart. Le TTFB (Time To First Byte) d’un site JAMstack se situe entre 5 et 50ms. Celui d’un WordPress non optimisé dépasse souvent 500ms. En temps de chargement complet, la différence est de l’ordre de 4x: 0.7s en median pour JAMstack, 3.2s pour WordPress classique. Une migration Drupal vers JAMstack documentée en 2024 a produit +41% de positions organiques en six mois, grâce à l’amélioration des Core Web Vitals.

*Installation vanilla avec Twenty Twenty-Three, sans cache ni CDN, mesure Lighthouse desktop.

Atteindre ces scores avec WordPress demande un travail de fond sérieux: cache de page, CDN, minification, suppression des scripts inutiles des plugins… Avec Hugo, c’est le point de départ.

Coût: de zéro à très peu #

Pour un blog ou un site vitrine sans e-commerce, le coût d’infrastructure peut être nul.

Netlify propose un tier gratuit généreux: déploiement automatique depuis GitHub, HTTPS inclus, CDN mondial, prévisualisations par branche. Pour la majorité des sites vitrines, ce tier suffit largement. Le nom de domaine reste le seul poste inévitable.

Contrôle total du SEO #

Avec WordPress, le SEO repose presque toujours sur un plugin (Yoast, Rank Math). Ces plugins font du bon travail, mais ils ajoutent du code, des dépendances, et une couche d’abstraction entre vous et ce qui est réellement généré.

Avec Hugo, le HTML généré est exactement celui que vous avez défini dans vos templates. Les balises <title>, les meta descriptions, les données structurées Schema.org, le sitemap XML, le fichier robots.txt, les redirections 301: tout est contrôlé directement dans le code.

Sur ce site, chaque article a:

• un seo.title personnalisable indépendamment du titre affiché
• une description unique rédigée pour les moteurs
• un schema.org BlogPosting généré automatiquement avec les bons champs
• un slug verrouillé pour éviter les changements d’URL accidentels

Aucun plugin entre le template et le HTML final. Ce que vous codez est ce qui est rendu.

Ce qu’il faut accepter #

Hugo n’est pas WordPress. Les contraintes sont réelles.

La courbe d’apprentissage #

Hugo a sa propre syntaxe de templates (Go templates), ses propres conventions pour l’organisation des fichiers, son propre système de données. Ce n’est pas difficile, mais ça se travaille. Un développeur qui découvre Hugo passe généralement quelques jours à comprendre les concepts avant d’être à l’aise. La documentation officielle est bien faite, dense, et la communauté active.

Pas de marketplace de plugins #

WordPress a des milliers de plugins pour tout. Hugo n’en a pas. À la place, on assemble des microservices (Upstash, Algolia, Cloudinary, Formspree) et des paquets npm selon les besoins. C’est plus de code à écrire, mais c’est aussi du code qu’on contrôle entièrement, sans dépendance opaque à maintenir.

Le CMS #

Sans tableau de bord intégré, les contenus s’écrivent en Markdown dans des fichiers texte versionnés avec git. Pour un développeur, c’est un avantage. Pour un client non technique qui veut modifier son site seul, c’est un frein. Des CMS headless comme Decap CMS ou Tina CMS règlent le problème, mais ça représente une configuration supplémentaire au démarrage.

Quand choisir WordPress plutôt qu’Hugo #

Hugo n’est pas la bonne réponse dans tous les cas. WordPress reste pertinent pour:

• un client qui doit modifier ses contenus seul, sans configuration CMS headless au préalable
• une équipe déjà habituée à WordPress et qui n’a pas de raison de changer de stack
• un délai très court où l’écosystème de plugins WooCommerce fait gagner du temps

Dans ces cas, tester WordPress en local avec Docker est la façon la plus propre d’évaluer thèmes et plugins avant de choisir un hébergeur.

E-commerce: une fausse limite #

Hugo avec Snipcart, Stripe Checkout ou le Buy Button Shopify couvre la majorité des cas d’usage: catalogue produit, panier, paiement sécurisé. La vraie différence est architecturale: la vitrine et le tunnel de paiement sont deux composants indépendants. On remplace Shopify sans retoucher le site, on refond la vitrine sans migrer le catalogue. Avec WooCommerce, tout est couplé dans le même monolithe PHP.

Pour tout le reste: site vitrine, blog, documentation, portfolio, landing page, Hugo est mon choix par défaut.

Conclusion #

Ce site tourne sur Hugo depuis sa refonte, avec un score Lighthouse stable, un hébergement gratuit sur Netlify, et des fonctionnalités comme la recherche, les upvotes et les commentaires qui prouvent que “statique” n’impose aucune limite sur l’expérience utilisateur.

Hugo n’est pas plus simple que WordPress au démarrage. Un thème WordPress s’installe en cinq minutes; un site Hugo sur mesure demande du travail. Mais la rapidité de livraison initiale se paie dans la durée: performances dégradées, plugins à surveiller, hébergement à financer. Hugo inverse ce ratio.

Pour un site qui n’a pas besoin de toute la machinerie PHP, c’est une architecture honnête: ce que vous déployez, c’est du HTML, du CSS et du JavaScript. Rien de plus.

Sources et références #

• Documentation Hugo
• Pagefind: recherche statique
• Upstash Redis: serverless data
• Netlify: hébergement JAMstack
• Patchstack: State of WordPress Security 2025
• Colorlib: WordPress Hacking Statistics 2026
• SiteGrade: WordPress vs JAMstack