[🛠] Ajouter un calendrier et des statistiques d’activité à la sidebar du blog GitHub Pages

✨ Résumé de GPT-5.5 　

Un récit sur l’ajout d’un calendrier des posts et de statistiques d’activité par catégorie dans la sidebar juste après la reprise du blog, avec le mois de l’article courant et la navigation d’archive mensuelle.

Après avoir mis de l’ordre dans l’article de reprise du blog, le problème suivant est apparu immédiatement.

J’avais recommencé à écrire des articles. Mais le blog ne donnait pas encore vraiment l’impression d’être vivant. Avec seulement une liste de catégories, on ne voyait pas bien quand le blog avait bougé, quels jours avaient accumulé des traces, ni quel flux récent existait.

Pour réécrire Daily Review, il faut une sensation des dates.

Ce blog est finalement centré sur “ce que j’ai laissé tel jour”. Mais un blog GitHub Pages n’a pas naturellement une navigation par dates visible comme Naver Blog. Comme c’est un blog statique, il fallait d’autant plus la construire moi-même.

La fonctionnalité ajoutée ce soir n’était donc pas une simple décoration.

C’était un travail pour transformer la sidebar, d’ornement secondaire d’une liste d’articles, en outil de navigation qui montre les dates et le flux d’activité.

La première chose ajoutée était un petit calendrier direct

Le premier commit était f6971fc.

f6971fc  feat: add sidebar activity widgets

À ce moment-là, j’ai créé deux nouveaux fichiers.

_includes/sidebar-calendar.html
_includes/sidebar-nav-stats.html

J’ai ajouté l’include du calendrier à sidebar.html.

{% include sidebar-calendar.html %}

Le premier calendrier était construit uniquement avec Liquid, sans JavaScript.

Il filtrait les articles cachés hors de site.posts, puis calculait le premier jour de la semaine et le dernier jour du mois courant. Même le calcul des années bissextiles pour février était traité dans Liquid.

{% assign calendar_posts = site.posts | where_exp: "post", "post.hidden != true" %}
{% assign calendar_year = site.time | date: "%Y" %}
{% assign calendar_month = site.time | date: "%m" %}

Dans le mois, les dates avec des articles deviennent des liens, et les dates sans article restent de simples nombres. La base initiale était site.time. Autrement dit, à ce stade, le calendrier était un widget de sidebar qui montrait “l’état des posts du mois courant”.

Même cela a eu un effet immédiat.

Le blog a commencé à donner de nouveau l’impression de bouger. Contrairement à une simple liste de titres, un calendrier montre la densité des traces. On voit d’un coup d’oeil quels jours sont chargés en articles, quels jours sont vides, et où se trouve aujourd’hui.

J’ai aussi ajouté des informations d’activité aux catégories

Si je n’ajoutais que le calendrier, le flux des dates devenait visible, mais le flux par catégorie restait terne.

J’ai donc aussi créé sidebar-nav-stats.html.

Cet include considère l’URL de chaque élément de sidebar comme un chemin de catégorie, puis filtre à nouveau les articles appartenant à cette catégorie.

{% assign stat_posts = site.posts | where_exp: "post", "post.hidden != true" %}
{% assign stat_categories = include.url | remove_first: "/" | split: "/" %}

Par exemple, /daily-review affiche le nombre d’articles de la catégorie daily-review, et /diary/ai ne garde que les articles qui contiennent à la fois diary et ai.

La sortie est simple.

Nombre d'articles · Date du dernier article

J’ai aimé cela parce que la sidebar sortait du simple rôle de table des matières.

On voit combien d’articles Daily Review existent, quand le dernier article AI a été publié, et si GitHub Pages Blog est réellement actif. Pour savoir si un blog est vivant ou mort, la date la plus récente parle souvent plus clairement que le nombre d’articles.

J’ai immédiatement ajusté la densité mobile

Dès que j’ai ajouté le calendrier, la densité mobile est devenue un problème.

La sidebar a de la place sur desktop, mais sur mobile elle descend sous le corps de page ou se mêle au menu. Si les cellules du calendrier sont grandes ou si les libellés de nombre d’articles sont longs, un seul widget prend trop d’écran.

Donc dans 17d074d et b401d8b, j’ai immédiatement resserré les libellés d’activité de sidebar et la densité du calendrier.

17d074d  fix: tighten sidebar activity labels
b401d8b  [Fix] | Sidebar calendar: Improve mobile density

Dans le SCSS, j’ai fixé les cellules de dates avec aspect-ratio: 1, utilisé des tailles de police plus petites et un radius de 4px. Les informations d’activité des catégories ont été rendues assez petites pour tenir sur une ligne.

L’important ici était de ne pas faire du calendrier le personnage principal.

Le calendrier est un dispositif qui aide la navigation du blog. Il ne doit pas devenir plus grand que le contenu. Surtout dans un blog de traces, la sidebar doit donner de l’information sans gêner la lecture.

Je l’ai changé pour utiliser le mois de l’article courant

Un problème plus important est apparu tout de suite.

Si le calendrier repose sur site.time, alors même pendant la lecture d’un article de 2025, le calendrier montre mai 2026. Dans ce cas, le calendrier n’explique pas le contexte de l’article courant.

Donc dans ccb58d5, j’ai changé la date de base.

ccb58d5  [Fix] | Sidebar: Refine calendar behavior

Le point clé est ici.

{% assign calendar_source_date = site.time %}
{% if page.date %}
  {% assign calendar_source_date = page.date %}
{% endif %}

Si la page a une date, il affiche le mois de cette date. Sur les pages sans date, il utilise toujours site.time.

Cette modification a changé le caractère du calendrier.

Le premier calendrier montrait “l’état du blog ce mois-ci”. Maintenant, il montre “le temps dans lequel l’article courant est placé”. Si je lis un ancien Daily Review, je peux voir le flux des traces de ce mois-là et retrouver quels autres articles existaient dans le même mois.

C’est beaucoup plus juste pour un blog de traces centré sur les dates.

Plusieurs articles le même jour sont devenus une liste

Dans le même commit, j’ai aussi ajouté des listes d’articles par date.

S’il n’y a qu’un article dans une journée, envoyer le lien de la date directement vers cet article convient. Mais s’il y a plusieurs articles le même jour, un problème apparaît. Rien que le premier jour de reprise, Daily Review et l’archive de conversation IA existaient à la même date.

Donc quand une date a plusieurs articles, le lien de la date ne va pas directement vers un article. Il se déplace vers la liste des articles de cette date.

<section id="sidebar-calendar-2026-05-25-posts" class="sidebar-calendar__post-list">
  <h4 class="sidebar-calendar__post-list-title">Articles du 25 mai</h4>
  <ul>
    ...
  </ul>
</section>

La règle à ce stade était simple.

1 article : aller vers cet article
2 articles ou plus : aller vers la liste d'articles de cette date

Ce n’est pas tant une règle parfaite qu’une manière de résoudre immédiatement le problème des multiples articles à la même date. Mais le plus important, c’est que le système ne cache pas le problème.

Le système doit reconnaître qu’une seule date peut contenir plusieurs articles. Si un blog peut publier Daily Review, conversations IA et journaux de développement le même jour, ce traitement est nécessaire.

J’ai aussi ajouté une enhancement JavaScript

Avec seulement le calendrier Liquid, la navigation centrée sur le mois courant est possible, mais passer d’un mois à l’autre reste peu pratique.

Donc dans b06b6d6, j’ai ajouté JavaScript.

b06b6d6  [Feat] | Sidebar calendar: Add archive navigation

Le nouveau fichier est celui-ci.

assets/js/custom/sidebar-calendar.js

Et je l’ai enregistré dans after_footer_scripts de _config.yml.

after_footer_scripts:
  - /assets/js/custom/dark-theme.js
  - /assets/js/custom/sidebar-calendar.js

Côté Liquid, les données des posts descendent en JSON.

<script type="application/json" data-calendar-posts>
[
  {
    "title": "...",
    "url": "...",
    "date": "2026-05-25"
  }
]
</script>

JavaScript lit ces données et construit postsByDate, postCountByMonth, postCountByYear et latestPostMonthByYear. Ensuite, il rend les boutons mois précédent/suivant, un month input, des boutons de nombre d’articles par année/mois, et des listes dynamiques d’articles par date.

J’aimais cette structure parce qu’elle n’abandonnait pas le fallback.

Si JavaScript est disponible, le déplacement entre les mois et la navigation d’archive deviennent pratiques. Même sans JavaScript, Liquid rend déjà le mois de l’article courant et la liste fallback pour les dates avec plusieurs articles.

Cet équilibre compte dans un blog statique.

Ce qui a changé aujourd’hui

Le flux de cette nuit jusqu’à l’aube ressemblait à ceci.

f6971fc  Ajout du calendrier de sidebar et des statistiques d'activité par catégorie
17d074d  Resserrement de la densité des libellés d'activité de sidebar
b401d8b  Ajustement de la densité du calendrier mobile
ccb58d5  Gestion du mois de l'article courant et des dates à articles multiples
b06b6d6  Ajout de l'enhancement JavaScript pour la navigation d'archive mensuelle

Les fichiers centraux sont ceux-ci.

_includes/sidebar.html
_includes/sidebar-calendar.html
_includes/sidebar-nav-stats.html
assets/js/custom/sidebar-calendar.js
_sass/custom/customOverride.scss
_config.yml

En une phrase :

J’ai ajouté à la sidebar du blog une couche de navigation qui montre le flux des dates et de l’activité par catégorie.

Résultat

La sidebar du blog n’est plus une simple liste de catégories.

Elle montre le mois auquel appartient l’article courant, marque les dates avec des articles, et déplie en liste les journées qui ont plusieurs articles. Les entrées de catégorie affichent le nombre d’articles et la date du dernier article. Si JavaScript est activé, on peut parcourir l’archive du blog en passant d’une année et d’un mois à l’autre.

Du point de vue portfolio, l’intérêt de ce travail est d’avoir amélioré la navigation sans serveur.

Il n’y a ni DB séparée, ni API. Avec site.posts de Jekyll, Liquid, SCSS et un petit morceau de JavaScript, j’ai comblé un point faible du blog statique. Les traces ont des dates. Quand ces dates apparaissent dans l’UI, le blog ressemble moins à un tas d’articles qu’à un système qui avance dans le temps.

Le calendrier ajouté aujourd’hui en est le début.