[🛠] Remettre mon blog GitHub Pages dans un système utilisable

✨ Résumé de GPT-5.5 　

Trace de la réouverture d’un blog GitHub Pages resté à l’arrêt, de la séparation entre Daily Review et archives de conversations avec l’IA, puis de sa relance comme système public de consignation.

Aujourd’hui, j’ai rouvert le blog.

Il ne s’agissait pas simplement d’écrire un article. Il s’agissait de remettre un blog GitHub Pages resté à l’arrêt dans un état où je pouvais vraiment retravailler dessus.

Le point de départ a été la Daily Review du 25 mai. Cet article était une déclaration disant que je recommencerais à consigner chaque jour, mais en même temps, il contenait trop de choses à la fois. La colère liée à la mort d’un réserviste, le dégoût envers la politique, l’auto-examen autour de la foi et du passage à l’action, l’idée d’utiliser l’IA comme outil d’autogestion, et la décision de relancer le blog étaient tous dans un seul texte.

Au début, je pensais que c’était bon.

Comme c’était le premier jour de la reprise, je pensais qu’il suffisait aussi de laisser toute la conversation qui m’avait poussé jusque-là. Mais quand j’ai vraiment regardé le fichier, ce n’était pas une Daily Review. C’était plus proche d’une archive de conversation que d’un journal de la journée. Si j’attache une conversation complète de plusieurs milliers de lignes à une Daily Review, cet article n’est plus un format que je peux continuer chaque jour.

La première décision du jour a donc été simple.

Séparer la Daily Review de l’archive de conversations avec l’IA.

J’ai commencé par fixer les conditions

Pour relancer le blog, il me fallait une structure exploitable avant une belle déclaration.

Les conditions étaient les suivantes.

• Garder la Daily Review assez légère pour pouvoir l’écrire tous les jours.
• Séparer les longues conversations avec l’IA dans des articles d’archive dédiés.
• Faire en sorte que les archives de conversation ne ressemblent pas à des exportations brutes.
• Masquer les injures et les expressions agressives pour une lecture publique.
• Distinguer visuellement les messages de l’utilisateur et les réponses de l’IA.
• Rendre la catégorie de chaque article immédiatement visible dans les listes d’archives.
• Empêcher les blocs de code ou les longues cartes de conversation de pousser l’écran sur mobile.

Écrit comme ça, cela ressemble à un travail de rangement.

Mais en réalité, c’était retirer le plus gros obstacle qui empêchait la relance du blog. Si le premier article de reprise devient trop gros, dès le lendemain je n’écris plus. Le cœur du jour n’était pas d’agrandir un article, mais de remettre le blog dans un état où je pouvais continuer à écrire.

J’ai sorti la conversation complète de la Daily Review

Au début, j’avais mis la conversation complète dans la Daily Review du 25 mai sous forme repliable.

Mais cette approche a vite montré ses limites.

La Daily Review doit être un article qui consigne les victoires et défaites du jour, les livrables, le suivi du corps et les moments d’évitement. Si presque 2 900 lignes de conversation y entrent, la nature de l’article devient floue. Le lecteur s’y perd, et moi non plus je n’ai plus envie de reprendre le même format le lendemain.

J’ai donc séparé la conversation dans un autre article.

_posts/daily-review/2026-05/2026-05-25-2026-05-25.md
_posts/diary/ai/2026-05-25-reservist-anger-to-blog-restart.md

Côté Daily Review, j’ai réduit l’énorme exportation brute de conversation et créé une archive de conversation séparée.

C’était le point central.

Un journal quotidien reste un journal quotidien. Une archive de conversation reste une archive de conversation. Ne pas mélanger les deux.

J’ai transformé une exportation brute en article

Une exportation de conversation avec l’IA est difficile à lire si on la colle telle quelle.

Des logs de recherche, des liens d’image qui peuvent expirer, des métadonnées répétées et des structures diverses au milieu de la conversation se mélangent. Si je publie ça tel quel, cela devient un « enregistrement », mais pas un « article ». Cela peut rester sur le blog, mais cela ne se lit pas.

J’ai donc transformé l’archive de conversation en structure de cartes.

<section class="conversation-entry conversation-entry--user">
  <div class="conversation-meta">Moi · 2026.05.25 09:12:38</div>
  <div class="conversation-body">
    ...
  </div>
</section>

Les messages de l’utilisateur sont mis en avant dans une teinte jaunâtre, et les réponses de l’IA reposent sur un arrière-plan plus calme. J’ai créé des classes comme conversation-meta, conversation-body, conversation-mask et conversation-code. Les injures restent visibles sous la forme ***, mais elles ne surgissent pas telles quelles dans l’article public.

Ce n’était pas une simple décoration CSS.

C’était le processus qui transforme une conversation en matériau public. Sans effacer complètement l’original, je voulais que le lecteur du blog puisse suivre où le sujet changeait, qui parlait, et pourquoi cette conversation menait à la déclaration de reprise.

J’ai aussi réorganisé les métadonnées

Une fois l’article séparé, un autre problème est apparu.

Si la liste d’archives ne montre que le titre et la date, on ne sait pas immédiatement si un article est une Daily Review, une archive IA, un journal de développement ou une astuce. Si le blog doit grandir à nouveau, le contexte doit apparaître dès la liste.

J’ai donc ajouté l’affichage des catégories dans _includes/archive-single.html.

J’ai mappé daily-review vers Daily Review, diary vers Journal, ai vers IA, et github-pages-blog vers GitHub Pages Blog. Au lieu d’afficher les catégories brutes, je les ai converties en noms lisibles par de vrais lecteurs.

Au début, j’avais placé les pastilles de catégorie sous les métadonnées du corps, mais elles ont vite paru trop dispersées. J’ai repris le placement pour mettre la date et les pastilles de catégorie sur la même ligne.

Date / pastilles de catégorie / résumé

Ce petit changement a amélioré la densité d’information des listes d’archives. Il a aussi du sens du point de vue du portfolio. Le blog ne ressemble plus seulement à un endroit où l’on écrit des articles, mais à un système qui distingue les types de contenu et améliore l’exploration.

J’ai aussi corrigé ce qui cassait sur mobile

Une fois les cartes de conversation et les blocs de code ajoutés, les problèmes mobiles sont arrivés.

Si de longues phrases, des citations, des blocs de code et des boutons de copie poussent l’écran sur le côté, le blog paraît tout de suite bricolé. En particulier, le bouton de copie de code de Minimal Mistakes est pratique, mais sur écran étroit, le bouton lui-même peut créer de l’overflow.

J’ai donc corrigé quelques points immédiatement.

.conversation-entry {
  overflow-wrap: break-word;
}

.conversation-body {
  min-width: 0;
}

.clipboard-copy-button {
  overflow: hidden;
}

J’ai aussi ajusté les marges des titres, des blockquotes et des premiers et derniers paragraphes dans les cartes de conversation. Sur mobile, j’ai réduit le padding des cartes et la taille des titres internes.

Ces corrections ne se remarquent pas beaucoup. Mais vues comme portfolio, elles sont importantes. Elles montrent que je ne me suis pas arrêté après avoir ajouté une fonctionnalité. J’ai suivi l’écran réel et poli les parties qui cassaient.

Ce qui a changé aujourd’hui

Les changements du jour se résument à peu près ainsi.

Organisation des règles d’exploitation du blog dans AGENTS.md et _project/blog-system/README.md
Retrait de la conversation complète de la Daily Review
Création d’un article séparé pour l’archive de conversation avec l’IA
Ajout de styles de cartes de conversation basés sur conversation-entry
Définition des règles de masquage des injures et d’omission des images jointes
Ajout de pastilles de catégorie aux listes d’archives
Organisation de la mise en page des métadonnées de date et des pastilles de catégorie
Unification des horodatages de conversation en notation coréenne
Application des cartes de conversation
Correction de l’overflow mobile dans les cartes de conversation et les boutons de copie de code

Vu comme un flux de commits, j’ai fait pas mal de choses en peu de temps.

d3fb3d5  clean blog project files
1d36a01  clean #87 transcript
1d9ab13  restore #87 toc
ccb9139  archive #87 transcript
310b3af  show archive categories
4579858  refine archive post metadata
fb3516b  localize conversation timestamps
0564866  apply conversation cards
244a4a5  prevent mobile copy-code overflow

En une phrase :

J’ai transformé la déclaration de reprise du blog en un système de consignation réellement exploitable.

Résultat

Aujourd’hui, le blog a rouvert.

Mais le plus important, ce n’est pas qu’un article soit monté. C’est que la structure a été remise en place.

La Daily Review est restée un journal qui peut continuer chaque jour, et les longues conversations avec l’IA ont été séparées en archives dédiées. L’archive de conversation n’est plus une exportation brute, mais un matériau public lisible. J’ai ajouté le contexte des catégories aux listes d’archives, et j’ai corrigé les parties qui cassaient sur mobile.

Ce n’est pas un ajout de fonctionnalité spectaculaire. Mais comme première étape pour ranimer le blog, c’était juste.

Si je veux écrire à nouveau, le blog ne peut pas être un simple entrepôt d’émotions. Il doit être un système exploitable. Ce que j’ai fait aujourd’hui, c’est restaurer l’ossature minimale de ce système.

J’aime aussi ce point du point de vue du portfolio.

Le problème était clair. Le premier article de reprise était devenu trop gros et risquait de casser le système de journal quotidien. La solution n’était pas une simple suppression. J’ai séparé les types de contenu, construit une UI, réorganisé les métadonnées et poli le rendu mobile.

Dire que je recommence le blog est facile.

Aujourd’hui, j’ai transformé cette phrase en structure de fichiers, modèles, styles, métadonnées et écrans mobiles.