Blog — Jekyll + GitHub Pages

Que fait Blog — Jekyll + GitHub Pages ?

Dépôt : ~/repos/github.com/<vous>/<vous>.github.io Moteur : Jekyll + GitHub Pages, thème : minima Branche : master → déploiement automatique sur push Index : conserver un fichier d'index du blog (ex. ~/notes/blog.md) — le mettre à jour après chaque article

Remarque — Aucune construction Jekyll locale nécessaire. GitHub construit côté serveur.

---

⚠️ Règle stricte : aucune information sur l'employeur

NE JAMAIS inclure dans un article :

• Les outils internes de votre employeur, systèmes, noms de code ou infrastructure
• Les noms de projets internes, noms d'équipe, structure organisationnelle ou détails de feuille de route
• Les noms de clients, partenaires ou détails contractuels
• Les tickets internes, pages wiki ou contenu de réunions
• Le salaire, les effectifs, le budget ou les indicateurs d'activité

Écrivez sur les techniques, les outils et les motifs — pas où vous travaillez ou ce que votre employeur publie. En cas de doute, demandez à l'utilisateur avant de publier.

---

Flux de travail

1. Rédiger l'article

_posts/YYYY-MM-DD-slug-ici.md

Frontmatter :

---
layout: post
title: "Votre Titre Ici"
date: YYYY-MM-DD
categories: ai agents productivité   # séparés par des espaces
series: "Productivité des agents IA"   # omettre si ce n'est pas une série
---

2. Style

• Commencez par le problème, pas la solution
• Une phrase d'ouverture concrète — pas de « Dans cet article, je vais... »
• Blocs de code pour tout ce qui est exécutable
• Tableaux pour les comparaisons
• Terminez par une section ## Source liant les dépôts/références
• Pas de bavardage LLM — écrivez comme un README
• Échappez @mot en \@mot pour éviter les erreurs de citation typst si un PDF est nécessaire un jour

Choisissez un article bien considéré et déjà publié sur le blog et utilisez-le comme référence pour le ton et la densité.

3. Vérifier chaque lien AVANT de publier (ne pas sauter)

Citer des URL de mémoire produit des erreurs 404. Vérifiez d'abord le statut HTTP de chaque lien :

for u in "https://example.com/a" "https://example.com/b"; do
  echo "$(curl -sS -L -o /dev/null -w '%{http_code}' "$u")  $u"
done

Chaque lien DOIT renvoyer 200 (ou 301/302 vers une cible valide) avant le commit. C'est moins coûteux que de publier un lien mort et de le corriger après que l'utilisateur le découvre.

4. Commiter et pousser

cd ~/repos/github.com/<vous>/<vous>.github.io
git add _posts/YYYY-MM-DD-slug.md
git commit -m "post : <titre>"
git push   # GitHub Pages déploie automatiquement en ~60s

5. Mettre à jour l'index

Ajoutez une ligne au tableau ## Posts dans le fichier d'index du blog (le plus récent en premier), et ajoutez l'article à la ligne ## Série active s'il appartient à une série :

| YYYY-MM-DD | Titre | `catégorie/chemin/YYYY/MM/DD/slug.html` |

L'URL suit le motif permalink de Jekyll dérivé de categories + date + slug.

6. Vérifier qu'il est bien en ligne (ne pas sauter)

Une construction Pages réussie ne signifie PAS que l'article est en ligne — Jekyll ignore silencieusement les articles datés dans le futur. Vérifiez l'URL réelle après la fin de la construction :

base="https://<vous>.github.io" ; slug="/CATÉGORIE/CHEMIN/YYYY/MM/DD/slug.html"
curl -sS -L -o /dev/null -w "%{http_code}\n" "$base$slug"   # doit être 200
curl -sS -L "$base/" | grep -o 'slug[^"]*html' | head -1     # doit apparaître sur la page d'accueil

Si ça renvoie 404 alors que la construction a réussi, c'est presque certainement le piège de la date future ci-dessous.

---

Safeguards de mise à jour d'un article publié

• Préservez le récit original et ajoutez une mise à jour clairement étiquetée, sauf si l'utilisateur demande explicitement une réécriture.
• Vérifiez HTTP uniquement sur les URL nouvellement ajoutées ou modifiées ; ne vérifiez pas de manière répétée les liens d'articles publiés inchangés, sauf si une audit de liens est demandée.
• Après avoir poussé, vérifiez que l'URL réelle publiée renvoie HTTP 200.

---

Conseils

• Gardez une section ## TODO dans le fichier d'index du blog pour les idées d'ébauches ; vérifiez-la avant de commencer de zéro
• Si l'article continue ou contredit un article précédent, liez-le avec {% post_url YYYY-MM-DD-slug %}
• Publication avant l'aube + piège de la date future : Jekyll interprète une date: YYYY-MM-DD sans heure comme minuit dans le fuseau horaire du site et supprime silencieusement les articles datés dans le futur. Avant que _config.yml n'ait une ligne timezone: explicite, un article écrit à 04:00 heure locale était interprété comme minuit UTC = ~1h dans le futur → supprimé jusqu'à ce que UTC rattrape. Définissez timezone: dans _config.yml et ne le SUPPRIMEZ PAS. Si un article rédigé avant l'aube renvoie encore 404 après une construction réussie, ajoutez une heure explicite dans le frontmatter (date: YYYY-MM-DD 04:00:00 +0530).