Création du blog et technos utilisées
Créer un blog technique est souvent l’occasion d’expérimenter de nouvelles technologies.
Ce blog a donc été surtout l’occasion de me mettre à niveau sur des nouvelles technos et sortir de mon domaine de prédilection Symfony qui gère le backend et le frontend (avec twig).
Dans cet article, je vous partage comment j’ai mis en place ce blog statique, sécurisé, auto-hébergé et extensible grâce à plusieurs outils : Hugo, Symfony, OIDC, GitLab et Docker.
Hugo, pour la partie frontend
J’ai choisi Hugo comme générateur de site statique pour plusieurs raisons :
- Rapidité : Hugo est extrêmement rapide à générer les pages, même sur de gros volumes de contenu
- Optimisé : éviter le calcul côté serveur pour le rendu des pages.
- Sécurité : un site statique ne contient pas de logique côté serveur, réduisant considérablement la surface d’attaque.
- Simplicité : l’écriture se fait en Markdown, versionnable, et facilement maintenable.
- Flexibilité : grâce aux thèmes et à la puissance de son moteur de templating, Hugo permet des personnalisations poussées.
Thème utilisé : Mainroad
Pour construire l’apparence du blog, j’ai choisi le thème Mainroad comme point de départ.
Ce thème offre une base propre, lisible, responsive et optimisée pour le contenu technique. Il gère bien les métadonnées, le SEO et les réseaux sociaux — parfait pour un blog statique.
Cependant, j’ai souhaité aller plus loin en matière de personnalisation visuelle. J’ai donc modifié le thème pour y intégrer Tailwind CSS ainsi que la bibliothèque DaisyUI. Cela m’a permis d’enrichir l’interface avec des composants modernes et facilement personnalisables, tout en conservant la structure solide de Mainroad.
Ce choix m’a offert un excellent compromis entre stabilité, performance et esthétique.
Personnalisation avec Tailwind CSS + DaisyUI
Afin de ne pas être limité par les styles du thème, j’ai intégré Tailwind CSS dans le projet Hugo. Cela m’a permis de :
- Ajouter des composants modernes et réactifs.
- Adapter finement la typographie, les espacements, et les couleurs.
J’ai complété cette stack avec DaisyUI, une bibliothèque de composants basée sur Tailwind, pour gagner en rapidité de développement :
- Boutons, alertes, menus déroulants déjà stylés.
- Compatibilité totale avec mes classes Tailwind.
- Un style cohérent, facilement personnalisable via les thèmes DaisyUI.
Cette approche m’a donné un excellent équilibre entre la simplicité de Hugo, la structure robuste du thème Mainroad, et la souplesse visuelle d’un framework CSS moderne.
WebComponents avec Lit
Pour la partie dynamique de l’interface, j’ai opté pour Lit-Element afin de créer des Web Components réutilisables et performants.
Ces composants interagissent directement avec le backend via des API REST, tout en respectant le mécanisme d’authentification mis en place avec OpenID Connect. Chaque requête API est automatiquement authentifiée grâce au token d’accès géré côté frontend, ce qui permet une intégration fluide et sécurisée entre les Web Components et le backend Symfony.
- J’ai dû me remettre à niveau avec Tailwind CSS v4, qui introduit de nouveaux concepts comme les compositions de variantes
- La compilation des assets (Tailwind, DaisyUI) m’a amené à configurer PostCSS correctement dans Hugo, afin d’obtenir un pipeline CSS propre, optimisé et automatisé.
- Pour faciliter les déploiements, j’ai construit une image Docker personnalisée embarquant Node.js 22 (pour Tailwind/DaisyUI) et Hugo — me permettant ainsi d’avoir un environnement de build isolé, reproductible et portable.
- Mise en oeuvre OIDC (OpenID Connect) pour l’authentification des API dans les WebComponents.
- Enfin, j’ai pris le temps d’apprendre la structure des templates Hugo, les partials, la hiérarchie des layouts, ainsi que la configuration fine via le
config.toml.
Ces étapes m’ont permis de mieux comprendre l’écosystème Hugo et de créer un blog à la fois maintenable, performant et personnalisable.
Symfony pour le backend : Accès aux API
Bien que le blog soit statique, j’avais besoin d’une couche dynamique pour certaines fonctionnalités privées : accès à des documents, API protégées, etc.
Pour cela, j’ai mis en place un backend Symfony :
- Fournit des endpoints API sécurisés.
- Permet l’authentification des utilisateurs.
- Traite certaines requêtes dynamiques non possibles avec un site purement statique.
Symfony ne m’a posé aucune difficulté particulière, car c’est un framework que j’utilise et maîtrise depuis plusieurs années.
La partie la plus complexe du projet a été l’intégration de l’authentification via OpenID Connect (OIDC), notamment avec l’Identity Provider fourni par le NAS Synology. Ce dernier ne respecte pas entièrement les spécifications OIDC, ce qui a nécessité plusieurs ajustements. En particulier, le token d’accès délivré expire au bout de seulement trois minutes, ce qui rendait les sessions API très instables.
J’ai donc dû mettre en place une gestion manuelle du refresh token côté Symfony, afin de renouveler automatiquement les accès et éviter des expirations de session trop fréquentes.
Authentification via OIDC et Synology comme IDP
La sécurité de l’API repose sur OIDC (OpenID Connect).
- L’Identity Provider (IDP) est celui de mon NAS Synology, qui offre un service d’authentification compatible OIDC.
- Cela permet de centraliser la gestion des identités, et d’offrir une authentification unifiée entre les services auto-hébergés.
Le flux d’authentification est donc :
- L’accès au site statique n’est pas soumis à authentification
- Un bouton, permet à l’utilisateur de se connecter via l’interface OIDC (login Synology).
- Un jeton d’accès (access token) est émis.
- Ce token est utilisé pour interroger les API Symfony protégées.
- La gestion du mode refresh token à été mise en oeuvre
GitLab auto-hébergé et CI/CD pour le déploiement
Tout le code est versionné sur un GitLab auto-hébergé, également installé sur mon NAS.
- Chaque commit déclenche un pipeline de CI/CD personnalisé.
- Le site statique Hugo est généré automatiquement et déployé derrière un frontal nginx
- Le backend est buildé puis déployé via Docker sur le NAS.
Cela me permet :
- Une intégration continue fiable.
- Un déploiement automatisé dès qu’un changement est poussé.
- Un contrôle complet sans dépendre de services externes.
Le NAS joue ainsi le rôle de serveur d’hébergement complet : stockage, authentification, CI/CD, déploiement.
Ce projet de blog m’a permis de combiner plusieurs technologies :
- Un générateur statique moderne (Hugo,Tailwind, Lit).
- Un backend sécurisé et extensible (Symfony + OIDC).
- Un pipeline CI/CD complet et auto-hébergé (GitLab + Docker).
- Le tout, déployé de manière robuste sur un NAS Synology.
Ce choix d’architecture me donne un blog à la fois rapide, sécurisé, privé quand nécessaire, et 100% sous contrôle.
Vous avez une question sur cette stack ou vous souhaitez faire pareil chez vous ? N’hésitez pas me contacter !