Light Static Blog : une solution statique vibecodée

Light Static Blog est né d’un besoin très simple : avoir un blog personnel que
je comprends, que je maîtrise, et que je peux déployer sans usine à gaz.
Je voulais quelque chose de léger, statique, lisible, personnalisable, et assez propre pour durer. Pas un CMS complet. Pas une application serveur à maintenir. Pas une base de données pour trois articles et quelques images.
Juste du Markdown, un build, puis des fichiers HTML à déposer quelque part.
Pourquoi une solution perso ?
Il existe déjà beaucoup de solutions pour publier un blog. Certaines sont très bonnes. Mais j’avais envie d’un socle à ma main, avec des choix simples :
- des articles en Markdown dans le repo ;
- un site généré statiquement ;
- un thème facilement remplaçable ;
- un flux RSS complet ;
- un sitemap et un
robots.txtpropres ; - une base SEO correcte dès le départ ;
- un déploiement automatisé vers mon hébergement.
Le but n’était pas de réinventer le web. Le but était plutôt de construire un petit outil clair, adapté à mon usage, et suffisamment générique pour rester réutilisable.
Le choix du statique
Le statique a un charme très particulier : une fois généré, le site n’a presque plus besoin de rien.
Pas de serveur applicatif, pas de session, pas de base de données, pas de mise à jour de plugin qui casse tout un dimanche soir. Le résultat final, ce sont des fichiers HTML, CSS, JS et images que n’importe quel hébergement web classique peut servir.
Pour un blog personnel, c’est exactement ce que je voulais :
- rapide à charger ;
- simple à sauvegarder ;
- facile à versionner ;
- peu fragile ;
- déployable aussi bien sur GitHub Pages que sur un hébergement SFTP.
Il y a aussi une raison plus pragmatique : la sécurité. Un site statique expose beaucoup moins de surface d’attaque qu’une application dynamique. Pas d’administration en ligne, pas de base de données accessible, pas de code serveur à exécuter à chaque requête. Rien n’est magique, évidemment, mais moins il y a de pièces mobiles en production, moins il y a d’endroits où quelque chose peut mal tourner.
Le déploiement automatique
Une grosse partie du confort vient du déploiement.
L’idée est de pouvoir lancer une commande, générer le site, vérifier les sorties importantes, puis envoyer uniquement ce qui doit l’être sur le serveur. Le script SFTP gère donc le build, quelques contrôles, le transfert et une vérification des fichiers publiés.
Ce n’est pas spectaculaire, mais c’est exactement le genre de détail qui change l’usage au quotidien. Quand publier devient simple, on publie plus facilement.
Vibecodé avec Codex
Ce projet a aussi été une expérience de vibecoding.
Pendant quelques jours, j’ai construit le blog avec Codex comme compagnon de route : une idée, une itération, un test, une correction, puis une autre idée. Le système de thèmes, le RSS, le sitemap, les métadonnées SEO, le rendu Markdown, les améliorations mobiles, l’accessibilité, le script de déploiement… tout a été fait par petites passes successives.
Ce qui m’a plu dans cette manière de travailler, c’est le rythme. On peut avancer vite sans forcément bâcler, à condition de vérifier souvent :
npm run validate
À chaque étape, le projet devait continuer à construire proprement. C’est devenu une sorte de règle du jeu : expérimenter, oui, mais garder une base saine.
Un moteur et un carnet
Aujourd’hui, Light Static Blog est le moteur public générique. Et ce site,
Carnet de dev, en est une déclinaison personnelle avec mon thème, mes contenus
et mon déploiement.
Cette séparation me plaît bien :
| Projet | Rôle |
|---|---|
light-static-blog | moteur public, générique et réutilisable |
carnet-de-dev | blog personnel, thème privé et contenu réel |
Le moteur peut continuer à évoluer proprement, tandis que le carnet reste mon terrain d’expression.
Ce que je retiens
Ce projet est modeste, mais il coche beaucoup de cases importantes pour moi :
- il est simple à comprendre ;
- il produit un site statique rapide ;
- il respecte les bases SEO et RSS ;
- il laisse la main au thème ;
- il se déploie sans friction ;
- il garde le contenu dans Git.
Et surtout, il donne envie d’écrire la suite.