Gist-as-a-CMS : Vers un Blog Zéro Administration

Introduction

Si vous avez déjà ressenti la frustration de devoir configurer un CMS lourd, de gérer des bases de données ou de lutter avec des interfaces d’édition complexes pour un simple blog technique, vous apprécierez la philosophie derrière ce site. Ici, j’applique le concept de “Separation of Concerns” (SoC) à l’extrême : le code et le contenu vivent là où ils sont créés (sur GitHub), tandis que le site n’est qu’une projection statique de cette activité.

L’architecture “Gist-as-a-CMS” est une architecture que j’ai conçue pour avoir un blog statique en transformant GitHub en un moteur de contenu décentralisé et automatisé.

Contrairement à un blog Jekyll traditionnel où chaque article est un fichier .md stocké localement dans le dépôt, ce système traite vos Gists comme des entrées de base de données dynamiques et vos Dépôts comme des collections d’objets, le tout orchestré par une chaîne d’intégration continue.

Le Problème Historique : La Friction de Publication

Traditionnellement, maintenir un blog technique impose une friction constante :

  1. Duplication : On écrit un bout de code sur GitHub, puis on doit le copier-coller dans un article de blog.
  2. Désynchronisation : Si le code source change, l’article devient obsolète.
  3. Complexité d’Édition : Passer par une interface web ou devoir cloner son propre blog pour corriger une faute de frappe décourage la publication fréquente.

Ce système résout ces problèmes en introduisant un découplage total entre la création du contenu (le Gist) et sa présentation (le Site).

Les Trois Piliers de l’Architecture

Le système repose sur trois composants distincts, chacun ayant une responsabilité unique. C’est cette architecture modulaire qui permet l’automatisation totale.

  1. Le Stockage (GitHub Gists & API)

    Il représente la couche de données brutes.

    • Rôle : Héberger le code source, les notes techniques et les métadonnées des projets.
    • Avantage : Utilisation d’outils familiers (VS Code, Git) pour l’édition.

  2. L’Orchestrateur (GitHub Actions)

    C’est le médiateur qui synchronise le monde extérieur avec le site.

    • Rôle : Interroger l’API GitHub, nettoyer les données via jq et mettre à jour les fichiers de données locaux (_data/gist.json).
    • Fréquence : Exécution planifiée (Cron) ou manuelle (Workflow Dispatch).

  3. Le Générateur (Jekyll & Plugins)

    C’est la couche de présentation.

    • Rôle : Transformer les données JSON en pages HTML riches.
    • Spécificité : Utilise un plugin personnalisé (GistFetcher.rb) pour “crawler” le contenu réel des Gists lors de la compilation.
graph TD
    A[Développeur] -- Crée / Modifie --> B(GitHub Gists)
    A -- Push --> C(GitHub Repos)

    subgraph "Pipeline d'Automatisation"
        D[GitHub Actions] -- Polling API --> B
        D -- Polling API --> C
        D -- Commit Data --> E[JSON local]
    end

    subgraph "Moteur de Rendu"
        F[Jekyll + GistFetcher] -- Lit --> E
        F -- Download Raw --> B
        F -- Génère --> G[Site Statique]
    end

    G --> H[Hébergement GitHub Pages]
    H -- CDN Cloudflare --> LEC[Lecteur final]

La Dynamique du Découplage

Le secret de cette architecture réside dans la manière dont le contenu est “aspiré” plutôt que “poussé”.

1. Le “Fetch” au moment de la Build

Le plugin GistFetcher.rb s’enregistre sur le hook :post_read de Jekyll. Il ne se contente pas de lire le titre du Gist ; il va chercher le contenu brut (raw_url).

  • Cela permet d’avoir un site toujours à jour avec la dernière version du Gist sans avoir à modifier le code du site.
  • Le formatage est géré intelligemment : si c’est du Markdown, il est rendu ; si c’est du code, il est encapsulé dans un bloc de coloration syntaxique.

2. Le Layout Intelligent

Le site utilise highlight.js et mermaid.js de manière conditionnelle. Le layout détecte la présence de blocs de code ou de schémas dans le contenu récupéré pour ne charger les bibliothèques lourdes que si nécessaire.

graph LR
    A[Gist Content] --> B{Contient Mermaid ?}
    B -- Oui --> C[Charger Mermaid.js]
    B -- Non --> D[Ignorer JS inutile]
    
    A --> E{Contient Code ?}
    E -- Oui --> F[Appliquer Highlight.js]
    E -- Non --> G[Texte brut]

Analyse Comparative : Avantages et Inconvénients

Pourquoi c’est une révolution :

  • Maintenance Zéro : Le site est le reflet de votre activité réelle. Pas besoin de “préparer” un article.
  • Performance et Sécurité : Pas de PHP, pas de SQL. La surface d’attaque est nulle et le temps de chargement est optimal.

Les défis à considérer :

  • Dépendance à l’API : Vous êtes lié à la santé de l’infrastructure GitHub.
  • Latence de Build : La récupération HTTP de chaque Gist peut ralentir la compilation si vous en avez des centaines. Un système de cache devient alors indispensable.
  • SEO Limité : Les Gists ne supportent pas nativement les balises Meta complexes ou les descriptions personnalisées pour les moteurs de recherche sans manipulation supplémentaire.

Conclusion

L’adoption de cette architecture demande un changement de paradigme : on ne “gère” plus un site, on diffuse son activité. C’est l’outil parfait pour une personne qui veut partager sa veille technique sans perdre une minute en configuration.

Code source du site
Document rédigé pour expliquer l’innovation derrière bizouarn.com