Pourquoi j'ai migré tous mes sites WordPress vers Hugo

8 février 2026 par Benoit

Il y a un moment, dans la vie d’un développeur, où on regarde l’ensemble de ses sites WordPress et on se dit : « Pourquoi est-ce que je fais ça ? » Ce n’est pas un moment dramatique. Personne ne pleure. C’est plutôt le genre de réalisation tranquille qui arrive un mardi après-midi, pendant qu’on attend qu’un plugin finisse de se mettre à jour sans tout casser (spoiler : il va tout casser).

Après plus de vingt ans de développement web, j’ai décidé de transférer l’ensemble de mes sites WordPress vers Hugo, un générateur de sites statiques écrit en Go. Et dans les prochains mois, je vais proposer la même démarche à mes clients. Ce qui suit, c’est le pourquoi, le comment, et — parce que je suis honnête — les quelques moments où WordPress fait encore mieux.

La performance, ou : pourquoi votre site met trois secondes à afficher du texte

Voici comment fonctionne WordPress quand quelqu’un visite votre site. Un navigateur envoie une requête. Le serveur reçoit la requête. PHP se réveille. PHP demande à MySQL de lui donner le contenu. MySQL cherche. MySQL trouve. MySQL renvoie. PHP assemble le tout. PHP génère du HTML. Le serveur envoie le HTML. Le navigateur affiche la page. Tout ça pour montrer un article de blog que vous avez écrit il y a six mois et qui n’a pas changé depuis.

Voici comment fonctionne Hugo : un navigateur demande une page, le serveur envoie un fichier HTML qui existe déjà. C’est tout.

Le résultat est un site jusqu’à cent fois plus rapide (pour un WordPress non optimisé — et pour obtenir des performances comparables avec WordPress, il faut empiler OpenLiteSpeed, LS Cache et un CDN, ce qui représente une configuration complexe et des coûts supplémentaires). Mais le chiffre brut n’est pas le plus intéressant. Ce qui est intéressant, c’est la prévisibilité. Un site Hugo est rapide quand personne ne le visite. Il est rapide quand mille personnes le visitent. Il est rapide le jour où votre article devient viral sur Reddit (ça arrive à tout le monde, non ?). Avec WordPress, la performance est un problème qu’on résout en empilant des solutions — plugins de cache, CDN, serveurs plus puissants — et qui revient dès qu’on change quelque chose. Avec Hugo, la performance n’est pas un problème. C’est juste une propriété du site.

J’en ai profité pour intégrer des versions AMP sur l’ensemble de mes sites lors de la migration. Le résultat sur mobile est quasi instantané, ce qui est le genre de phrase qu’on ne peut pas écrire quand on utilise WordPress sans ajouter « après avoir installé et configuré sept plugins ».

La sécurité, ou : la joie de ne rien avoir à pirater

WordPress est, par conception, une application web dynamique avec une base de données, un langage côté serveur, et un écosystème de dizaines de milliers de plugins écrits par des gens dont les compétences en sécurité varient — disons — considérablement. Chaque plugin est une porte. Chaque thème est une fenêtre. Chaque mise à jour de PHP est une occasion de découvrir que quelqu’un avait laissé une porte ouverte.

J’ai passé des heures à surveiller des alertes de sécurité, à appliquer des correctifs urgents, à vérifier que tel plugin n’avait pas introduit une vulnérabilité qui permettrait à un adolescent en Moldavie de transformer mon blog en site de cryptomining. (Je n’ai rien contre la Moldavie. Ni contre les adolescents. Ni même, en principe, contre le cryptomining. Mais je préfère que ça ne se passe pas sur mes serveurs.)

Hugo élimine tout ça. Le site généré ne contient que des fichiers HTML, CSS et JavaScript statiques. Pas de base de données. Pas de code serveur. Il n’y a rien à pirater parce qu’il n’y a rien à exécuter. C’est la sécurité par l’absence, et c’est étrangement reposant.

L’hébergement, ou : comment mettre plus de sites sur le même serveur

Je ne vais pas faire semblant que l’hébergement me coûte zéro euro. J’ai mes propres serveurs et je compte les garder. Mais le gain est réel : là où un site WordPress monopolise des ressources avec PHP et MySQL (qui tournent en permanence, même quand personne ne visite le site, comme un employé qui reste au bureau à ne rien faire mais qui coûte quand même un salaire), un site Hugo ne consomme quasiment rien. En pratique, ça veut dire que je peux héberger beaucoup plus de sites sur un même serveur.

Pour ceux qui n’ont pas leur propre infrastructure — ce qui est le cas de la plupart des gens — l’avantage est encore plus spectaculaire. GitHub Pages, Netlify, Cloudflare Pages : tous ces services hébergent des sites statiques gratuitement, avec des performances excellentes et un CDN mondial inclus. Cloudflare Pages offre une bande passante illimitée, GitHub Pages propose 100 Go par mois, et Netlify fonctionne désormais sur un système de crédits (depuis septembre 2025, les nouveaux comptes disposent d’environ 30 Go de bande passante gratuite — les comptes antérieurs conservent les 100 Go de l’ancien plan). On passe de 5-30 euros par mois (le coût d’un hébergement PHP/MySQL même modeste) à littéralement zéro. Ce n’est pas une réduction de coûts. C’est la disparition d’un poste budgétaire.

Le workflow développeur, ou : pourquoi Git est la meilleure chose qui soit arrivée au web

En tant que développeur, c’est l’avantage qui m’a fait basculer. Avec Hugo, tout le site vit dans un dépôt Git. Chaque modification est versionnée, traçable, réversible en un commit. L’historique Git n’est pas juste un outil de développement — c’est la sauvegarde. Plus de plugins de backup. Plus de restaurations de bases de données à 3 heures du matin. Plus de ce moment horrible où on se demande si la dernière sauvegarde date d’hier ou de la semaine dernière.

Le Markdown, pour un développeur, n’est pas une limitation. C’est un avantage. On écrit plus vite, on se concentre sur le contenu, et la syntaxe est la même que celle qu’on utilise déjà dans les README, les issues GitHub, la documentation. C’est une compétence qu’on a déjà.

Pour le déploiement, il y a deux approches, et les deux sont valides.

La première, c’est le CI/CD cloud : un push sur GitHub ou GitLab déclenche automatiquement la compilation et le déploiement via des pipelines, Netlify, ou GitHub Actions. C’est propre, c’est standard, et c’est ce que je recommande pour la plupart des projets. D’ailleurs, j’ai quelques sites que je prévois d’héberger directement sur Netlify — pour certains projets, ça ne sert à rien de réinventer la roue quand la roue fonctionne parfaitement.

La seconde, c’est mon approche personnelle pour mes serveurs : un script rsync qui synchronise mon site local vers le serveur, et un cron job qui tourne toutes les dix minutes pour comparer le répertoire de déploiement avec la production. S’il y a des différences, rsync met à jour, et Caddy sert le résultat. C’est simple, c’est fiable, et ça me donne un contrôle total. (Il y a quelque chose de profondément satisfaisant dans un cron job qui fait exactement ce qu’on lui demande, toutes les dix minutes, sans jamais se plaindre. WordPress ne m’a jamais donné cette satisfaction.)

Les shortcodes : le Gutenberg qu’on contrôle vraiment

Hugo permet de créer des shortcodes personnalisés — des fragments de code réutilisables qu’on glisse dans le Markdown. Vidéos YouTube, galeries d’images, blocs de code avancés, tooltips : tout est faisable. On écrit ses shortcodes en quelques lignes de template Go, et on a un contrôle total sur le HTML généré.

C’est comparable aux blocs Gutenberg de WordPress, à une différence près : on sait exactement ce que le code fait, parce que c’est nous qui l’avons écrit, dans un fichier qu’on peut lire, versionner et déboguer. Ce qui n’est pas toujours le cas avec Gutenberg (ni avec la majorité des plugins WordPress, mais j’y reviens).

Le multilingue sans plugin

Hugo gère le multilingue nativement. Taxonomies, menus, contenus traduits : tout se configure dans les fichiers YAML ou TOML. WordPress, pour le même résultat, nécessite WPML (payant) ou Polylang, ce qui ajoute une couche de complexité, un risque de conflit avec d’autres plugins, et des coûts supplémentaires. C’est un schéma qui revient souvent avec WordPress : des fonctionnalités qui devraient être simples mais qui nécessitent un plugin, qui nécessite une configuration, qui nécessite une mise à jour, qui casse quelque chose.

Le problème dont personne ne parle : la qualité du code des plugins

On entend souvent que WordPress a un « écosystème massif de plus de 60 000 plugins ». C’est vrai. Ce qu’on entend moins, c’est la question qui devrait suivre immédiatement : oui, mais ils sont écrits comment, ces plugins ?

Après des années à travailler avec des plugins WordPress, je peux répondre : souvent, c’est déplorable.

J’ai vu des plugins écrits dans un seul fichier. Des plugins sans la moindre structure, sans documentation, sans souci de maintenabilité. (Ce n’est pas une hyperbole. Un seul fichier. Tout dedans. Des centaines de lignes. Bonne chance pour trouver ce que vous cherchez.) Quand on doit adapter un de ces plugins pour un projet client — ajouter une fonctionnalité, corriger un comportement —, on entre dans un monde de souffrance silencieuse.

Parce que voici le dilemme : vous voulez travailler proprement, mais le code sur lequel vous travaillez n’a pas été écrit proprement. Alors vous hackez. Vous contournez. Vous trouvez des solutions élégantes à des problèmes qui n’auraient pas dû exister. Et à la fin, vous avez passé plus de temps à faire tenir un plugin debout qu’il n’en aurait fallu pour développer la fonctionnalité de zéro.

Ce temps-là, avec Hugo, je le passe à créer de la valeur.

Hugo vs WordPress : le tableau

Les limitations de Hugo (et pourquoi elles sont de moins en moins gênantes)

Les formulaires de contact

C’est la limitation la plus concrète. Un site statique ne peut pas traiter un formulaire tout seul. Mais des services comme Formspree, Basin, ou Netlify Forms (intégré nativement si le site est sur Netlify) résolvent le problème en quelques minutes. C’est le point où je prévois de développer ma propre solution — parce que j’aime avoir le contrôle, et parce que c’est faisable.

Les commentaires

Si votre site a besoin de commentaires (et posez-vous honnêtement la question : en a-t-il vraiment besoin ?), des solutions matures existent. Comentario offre une interface d’administration complète. Isso est léger et auto-hébergé. Giscus utilise les discussions GitHub comme backend, ce qui est élégant si votre audience est technique. Ce ne sont pas des palliatifs : ce sont des outils solides.

L’édition pour les non-développeurs

C’est la limitation qu’on cite le plus souvent. « Oui mais mon client, il ne va pas écrire du Markdown. » C’est vrai. Mais voici le truc : à l’heure actuelle, avec l’IA, cette objection est en train de devenir obsolète.

On peut mettre en place un workflow où le client dépose son document Word et ses photos dans un dossier — ou dans un zip — et un script alimenté par l’IA fait le reste : extraction du contenu, génération de l’article en Markdown, correction orthographique, mise en forme, optimisation des images. Le client n’a jamais besoin de savoir que le Markdown existe. Il n’a jamais besoin de toucher au code. Il écrit son texte, il met ses images, et la magie opère.

(Et soyons honnêtes : même avec WordPress et son éditeur Gutenberg, est-ce que les clients produisaient vraiment du contenu web de qualité tout seuls ? Dans mon expérience, la réponse est non. Ils produisaient du contenu qu’il fallait reprendre de toute façon.)

Pour les approches plus traditionnelles, des CMS headless comme Decap CMS, Tina CMS ou Sveltia CMS offrent une interface visuelle dans le navigateur qui commit directement dans Git.

La recherche

Pagefind indexe le site à la compilation et offre une recherche instantanée côté client. Lunr.js et Fuse.js font le même travail. Algolia propose une solution en SaaS avec un tier gratuit généreux. La recherche dans un site statique est un problème résolu.

Le e-commerce

Ici, je vais être direct : le e-commerce n’est le terrain ni de Hugo, ni de WordPress. Oui, WooCommerce existe. Oui, ça fonctionne. Mais « ça fonctionne » n’est pas la même chose que « c’est bien ».

Pour une entreprise sérieuse, la vraie réponse, c’est soit une solution dédiée comme Shopify, soit un développement sur mesure avec un framework adapté — Django, Go, .NET, Laravel. Pour le prix d’un WooCommerce personnalisé (et les heures, les innombrables heures, passées à le faire tenir debout), on peut aujourd’hui développer une solution robuste et performante. Ce n’était peut-être pas vrai il y a dix ans. C’est vrai aujourd’hui.

Comment j’ai migré (ce n’est pas ce que vous croyez)

La méthode classique de migration, c’est l’export XML de WordPress, la conversion en Markdown, le nettoyage, la configuration des permaliens. C’est documenté, ça fonctionne.

Ce n’est pas ce que j’ai fait.

J’avais déjà, avant toute migration, un site Hugo de référence que j’avais construit entièrement à la main, sans IA. Ce site était mon modèle : structure des templates, traitement des images, shortcodes, intégration AMP. Il représentait exactement comment je voulais que mes sites fonctionnent.

Pour la migration proprement dite, j’ai utilisé Claude. Je lui ai demandé d’extraire le contenu de mes sites WordPress, de reproduire le design, et de générer les thèmes Hugo correspondants. Ensuite, j’ai fait les ajustements manuels : refonte de certaines parties du design, intégration AMP complète, amélioration des shortcodes. Chaque migration a été l’occasion d’affiner mes processus, en utilisant mon site de référence comme base. Le résultat final est plus propre, plus cohérent et plus performant que ce que j’avais avec WordPress.

Tout a été fait en code. Pas d’export XML. Pas de conversion automatique bancale. Juste un développeur, une IA, et un site de référence bien construit.

Et les frameworks JavaScript, alors ?

Si vous avez lu jusqu’ici, vous vous demandez peut-être pourquoi je ne parle pas de Next.js, Nuxt, Gatsby, ou de toute la galaxie React/Vue.js/Angular. Après tout, ce sont aussi des alternatives à WordPress, et certaines permettent de générer des sites statiques.

La réponse courte : c’est le sujet d’un prochain article.

La réponse un peu moins courte : j’utilise Vue.js à l’occasion, et ces frameworks ont leurs qualités. Mais ils introduisent des problèmes que Hugo n’a pas. Le SEO, d’abord : les applications monopages sont notoirement difficiles à indexer correctement, et même avec le rendu côté serveur (SSR), on ajoute une couche de complexité considérable pour résoudre un problème qu’un site statique n’a tout simplement pas. Et surtout, on retombe dans un environnement serveur — Node.js, en l’occurrence — avec tout ce que ça implique en termes de sécurité et de maintenabilité. Quiconque a géré un projet Node.js en production sait de quoi je parle : les dépendances qui se comptent par centaines, les mises à jour qui cassent des choses, les failles de sécurité dans des paquets dont on ignorait l’existence. On quitte WordPress pour se retrouver avec un autre type d’usine à gaz.

Mais c’est un sujet qui mérite son propre article. Ça viendra.

Pour qui Hugo est-il le bon choix ?

Pour les développeurs qui ont un blog, un portfolio, un site vitrine ou de la documentation : Hugo est une évidence. Mais je vais aller plus loin.

Hugo devrait être la solution par défaut pour la majorité des entreprises dont le site ne bouge quasiment pas. Et c’est le cas de beaucoup d’entre elles. Beaucoup plus qu’on ne le pense. Quelques pages de présentation, un blog occasionnel, un formulaire de contact via un service tiers — Hugo gère tout ça avec des performances et une sécurité que WordPress ne peut pas égaler, pour un coût d’hébergement qui tend vers zéro.

WordPress reste pertinent dans certains cas. Je ne dis pas le contraire. Mais son champ d’application réel est bien plus étroit que ce que l’industrie veut bien admettre. Et pour les besoins qui dépassent le site statique — applications web, tableaux de bord, comptes utilisateurs, logique métier complexe — la réponse n’est pas WordPress non plus. C’est un vrai framework : Django, Go, Laravel, .NET. Des outils conçus pour ces cas d’usage, pas une usine à gaz reconvertie.

WordPress est une usine à gaz sur laquelle on peut faire beaucoup de choses. C’est suffisant pour beaucoup de cas. Mais « suffisant » n’est pas « optimal ». Et dans un monde où la performance, la sécurité et la maintenabilité comptent de plus en plus, « suffisant » ne suffit plus.

(Je sais que cette dernière phrase sonne comme une punchline de conférence TED. Mais elle est vraie.)

À lire aussi