24 Juillet 2026 - 7 min de lecture

Zola #1 - Comment j'ai choisi mon CMS/SSG en 2026

Comme tout geek qui se respecte je me suis essayé à cette fantastique discipline qu'est le blogging sur les internets. Au commencement j'ai passé des années à réaliser mes sites par mes propres moyens souvent à l'aide de technologies simples telles que le PHP et du Javascript vanilla. Au début des années 2010, je me suis tourné vers les CMS dont principalement WordPress. A cette époque, c'était une des solutions les plus simples et les plus pratiques envisageables.

Modeste rédacteur que j'étais, mon blog ne contenait que quelques petits articles. Une chose marquante pour moi était de consacrer progressivement plus de temps sur la maintenance du site et à effectuer des mises à jour qu'à me concentrer sur le contenu et de potentiel nouveaux articles. L'expérience WordPress se termine probablement aux alentours des années 2016 à 2017, années durant lesquelles j'ai réinstallé un nouveau serveur ainsi qu'une nouvelle version du CMS et fait peau neuve intégrale sur le site en réintègrant d'anciens articles sans pour autant trouver plus de temps dans les mois qui ont suivi pour continuer la rédaction du contenu. Le constat était sombre: il y avait dans cet outillage quelque chose qui semblait être trop lourd pour mes besoins quotidiens et pour le type de contenus que je voulais rediger. Au fil des mois qui ont suivi j'ai donc délaissé cette discipline .. pour quelques années.

Pourtant dans mon quotidien et dans mon organisation j'ai produit de plus en plus de notes personnelles dans des fichiers texte ou markdown. Cela pouvait être une simple liste de TODOs mais aussi des dashboards, des bookmarks ou des documents plus thématiques comme des informations synthétiques sur le modélisme ou la vidéographie. Petite contrainte du quotidien: il fallait naturellement que ces fichiers soient accessibles et visibles depuis différents endroits pour que je puisse y accéder et les modifier aisément. C'est pour cela que je les ai synchronisés pendant un temps avec des outils dans le cloud. Or, c'est en faisant un grand rangement sur mes disques ces derniers mois (ndlr: "Le Grand Rangement 2026") et en commençant à constituer des archives et backups que je me suis rendu compte du nombre considérable de fichiers éparpillés sur divers supports. J'ai pris un certain temps pour les parcourir, les trier et les archiver. La question suivante qui me pendait au nez était la suivante: comment vais je continuer ma gestion de ces fichiers ? Je me suis rendu compte qu'une grande majorité de ces textes pourraient figurer dans un blog, car ils concernent des notes quelque peu plus élaborés qu'une simple ligne de texte d'un fichier TODO.

Aussi cette année j'ai reconsidéré ma position par rapport aux CMS: Je me suis dit que si j'arrivais à trouver un outil suffisamment simple, rapide et flexible, je pourrais centraliser grand nombre de ces notes sur un blog ou quelque chose d'équivalent tout au moins. J'ai donc challengé différents outils et différents mécanismes (workflow) pour avoir des éléments de comparaison en cette année 2026.

Les heureux élus ne font pas tous partie de la même catégorie mais ils répondent tous à mon besoin d'une facon ou d'une autre : WordPress, Grav, Bludit, MkDocs, Hugo et Zola. Il en existe bien d'autres bien évidemment !

La première étape importante pour moi a été de me désolidariser d'un outil qui impose des enregistrements dans une base de données qui était trop lourd à administrer pour mes besoins. Au fil de mes expérimentations, j'ai fini par remettre le concept même de CMS en question. Je me suis demandé si il était vraiment nécessaire d'avoir toute une interface d'administration pour gérer le contenu ou si quelque chose de très simple basé sur le système d'exploitation et système de fichier pouvait suffire.

On essaye donc d'établir une première checklist des idéaux très minimalistes:

  • outil simple
  • sans base de données
  • basé sur un format standardisé de markup (Markdown)
  • pas de gestion d'utilisateurs nécessaire
  • éviter la dépendance vers des langages tiers: PHP, Python, Node...
  • éviter les nombreuses dépendances sous-jaccentes au langage
  • pas de nécessité d'avoir des plugins
  • topologie basée sur le système de fichier
  • pas d'interface d'adminitration
  • un choix de thèmes cohérent et varié
  • simplicité du moteur de rendu des thèmes

A la vue de cette checklist infernale, on peut comprendre pourquoi j'ai rapidement abandonné les CMS pour me tourner vers les générateurs de sites statiques tels que MkDocs, Hugo ou Zola. J'ai ensuite évalué rapidement la complexité de ces systèmes et la facilité à rédiger du contenu, mais aussi, la facilité à modifier les thèmes graphiques pour adapter les différents types de pages à mes besoins. Voici un aperçu très synthétique de mes réflexions:

Wordpress 1

La solution la plus lourde parmi les candidats, nécessite une base de données et PHP, nécessite plus de temps en configuration et maintenance, failles de sécurité. Thèmes complexes.

Grav 2

Très bon candidat, moyennement lourd, thèmes encore complexes à mettre en oeuvre, nécessite PHP, nécessite du temps en maintenance et configuration. Sans DB. Utilise du Markdown. Grav vient tout juste de changer de version majeure et nombre de composants de l'ancienne version sont incompatibles.

MkDocs 3

Simple (dans le process), écrit en Python, assez fastidieux à mettre en place pour le rendu final obtenu. fonctionne sans DB et utilise du Markdown. Peu de thèmes.

Bludit 4

Petit CMS sans DB écrit en PHP, léger, rapide, simple avec Markdown mais communauté très petite et peu de thèmes disponibles.

Hugo 5

Ecrit en Go, très rapide, utilise également Markdown, très peu testé mais la solution va dans le bon sens. Grande communauté. Les thèmes sont évolués et assez complexes à prendre en main.

Zola 6

Ecrit en Rust, très léger et rapide, basé Markdown, simple et communauté grandissante. Personnalisation des thèmes assez aisée.

Tous ces outils (hormis Wordpress) sont basés sur des fichiers Markdown pour la rédaction du contenu ce qui me convient parfaitement ! De plus je rappelle que je n'ai aucunement besoin de la gestion multi-utilisateur ou de plugins complexes sur mon site.

Après avoir compris qu'un SSG (Static Site Generator) était le genre d'outil qui me convenait très bien il m'a fallu parcourir la communauté d'utilisateur pour voir quels sont les ressources disponibles. La première ressource qui m'intéressait était le thème graphique et la disponibilité de différents modèles. Pour cela Bludit était beaucoup trop jeune et ne disposait pas d'un grand choix. Hugo était déjà beaucoup plus intéressant: plus rapide et ne nécessitant plus de runtime PHP car écrit en Go, il avait nombre d'avantages pour lui ! Mais... en dernière minute j'ai découvert Zola. Zola est écrit en Rust propose les mêmes avantages que Hugo avec une communauté plus jeune. Par le plus grand des hasards j'ai immédiatement trouvé un thème graphique minimaliste qui me convenait parfaitement et qui allait me servir de base pour construire mon nouveau blog: Hermit. Ce thème est une adaptation de la version originale ... provenant de Hugo !

Le choix final s'annoncait compliqué ! Hugo vs. Zola ! Go vs. Rust ! Quel allait être le grand gagnant ? En faisant entrer un dernier petit paramètre cela va m'aider à prendre une décision: mes propres compétences vis à vis des deux languages dans lesquels ces outils sont écrits. J'ai actuellement une formation sommaire à Rust, tandis qu'en Go, je n'ai aucune connaissance sérieuse. Le choix était donc fait !

Parfois il suffit d'un petit déclic sur un détail pour valider et confirmer plusieurs attentes ! En définitive, la mécanique de templating de Zola étant très accessible j'ai pu adapter et customiser le thème à mes attentes sans grande difficulté et j'en suis satisfait à ce jour.

Quel périple ! Sans même avoir produit de contenu (encore une fois!!) j'avais déjà usé d'un certains nombre d'heures sur mon compteur de "temps geek" pour trouver l'outil qui convenait. Merci Zola !

Je suis tout à fait conscient que les éléments d'analyse et de comparaison cités dans ce document sont limités à mon propre usage et mes propres attentes vis à vis d'un tel outil. J'ai volontairement omis nombre de features que l'on pourrait attendre d'un CMS car toute cela était en dehors de mes prérequis et inintéressant.