Fichier ajouté par un agent collaborateur. Pour toute question ou ajustement, répondez dans la Pull Request associée.

🌘 Prompt : guide pour générer des articles de blogue (LLMS)

Voici une version condensée et opérationnelle du llms-blog-prompt.txt destinée aux agents (humains ou LLM) qui rédigent des articles pour ce dépôt. Respecte ces règles pour conserver la voix et la qualité éditoriale du blogue.

Voix et ton : personnel, direct, pédagogique et critique‑constructif. Emploie le tutoiement (tu) ; partage une expérience ou observation au début.
Structure : titre percutant, introduction courte, sous‑titres ## pour les sections, conclusion/actionable. Limite les listes ; privilégie la prose explicative.
Format : inclure métadonnées complètes (title, date, categories, tags, permalink, description). Utiliser des blocs de code pour les commandes et des liens internes quand pertinent.
Langue : français québécois adapté au milieu tech ; attention aux accords, aux traits d’union et à la concordance des temps.
Contenu : focus pratique et minimaliste, exemples concrets, références et sources, perspectives éthiques et open‑source.
Éléments récurrents : paradoxes, questions rhétoriques, rappels pratiques, mises en garde. Évite jargon excessif et promesses non fondées.

🌘 Processus recommandé

Choisir un sujet qui t’intéresse et qui a une valeur pratique.
Rédiger une introduction courte (question ou observation personnelle).
Développer 2–4 sections avec exemples concrets et liens internes.
Conclure par une action concrète ou une invitation au dialogue.

🌘 Utilisation de `answerBoxShortcode`

answerBoxShortcode sert à afficher un encadré synthétique (question/résumé) en tête d’article ou comme encadré pédagogique. Bonnes pratiques :

Placer un seul answerBoxShortcode par article, idéalement juste après le frontmatter ou en ouverture d’une section FAQ.
Format simple à utiliser :

Dans le texte du shortcode, éviter les longues listes ; privilégier une phrase ou deux bien formulées. Vérifier que le contenu du shortcode reste accessible (pas d’images seules, texte explicite).

🌘 Exigences techniques et vérifications

Tester localement : npm ci, npm run build, npm run serve:static puis npx pa11y http://localhost:8080/<chemin> sur la page modifiée.
Valider le frontmatter minimal et l’absence de liens cassés ou d’ancres vides.

Si tu veux, je peux appliquer automatiquement ce prompt à une proposition d’article (réécriture, vérifications, ajout du answerBoxShortcode), puis créer la branche et ouvrir la PR.

🌘 Agent : Correcteur de blogue

But : corriger et préparer des articles de blogue en français pour publication, en respectant le style et les exigences techniques du dépôt.

Quand l’utiliser : pour toute nouvelle contribution sous blogue/ ou lorsqu’une PR contient un article à relire (orthographe, frontmatter, balises, code, SEO).

Tâches recommandées (ordre suggéré)

Vérifier le frontmatter : s’assurer que title, date, categories, tags, permalink, description sont présents et correctement formatés (YAML valide, dates ISO ou format du dépôt).
Style & langue : corriger l’orthographe, accords et tournures en français québécois; appliquer le ton (tutoiement, phrases courtes, voix active).
Convertir HTML en Markdown : remplacer les fragments HTML inutiles par du Markdown, et s’assurer que les blocs de code sont en triple backticks avec la langue (ex. ```bash).
Answer box : ajouter ou corriger le answerBoxShortcode si pertinent. Placer au maximum un encadré juste après le frontmatter. Exemple :

SEO & métadonnées : vérifier description (court, actionnable), social_image_* si présent, et les tags pour cohérence.
Accessibilité : vérifier les alt des images, la hiérarchie des titres (##/###), et l’absence d’ancres cassées.
Liens et références : transformer les liens internes vers des chemins relatifs du dépôt et vérifier qu’ils pointent vers des pages existantes.
Vérifications locales : lancer npm ci puis npm run build et, si possible, npm run serve:static + npx pa11y http://localhost:8080/<chemin> pour vérifier la page.
Commit & message : committer les corrections avec un message clair fix(blog): correction article <slug> — orthographe, frontmatter, shortcode.

Règles pratiques

Ne pas modifier le dossier _site généré.
Limiter les reformulations importantes sans l’accord de l’auteur — privilégier corrections factuelles et stylistiques légères.
Lorsqu’un answerBoxShortcode est ajouté, garder le texte autonome (une ou deux phrases), éviter les listes à l’intérieur du shortcode.
Si des extraits de code sont fournis, s’assurer qu’ils sont fonctionnels et qu’ils utilisent des commandes copiables.

Exemple de checklist rapide à ajouter en description de PR

Frontmatter validé
Orthographe et style ajustés (FR‑QC)
answerBoxShortcode présent et correct
Images: alt vérifiés
Build local OK / Pa11y vérifié

Si tu veux, j’automatise ces étapes : je peux appliquer les corrections, exécuter une build locale et ouvrir une PR contenant uniquement les modifications proposées.

🌘 Instructions pour agents LLM — repository `site-grav`

Ce document décrit comment un agent automatisé (LLM) doit ajouter du contenu, reconstruire et mettre à jour le site.

🌘 Principes généraux

Travaillez dans le dépôt cloné — ne touchez pas au dossier _site généré.
Toutes les modifications de contenu doivent créer/éditer des fichiers sous blogue/ (posts), pages/ ou _includes/ selon le besoin.
Commits et PR : ouvrez une branche dédiée, validez les changements, puis ouvrez une Pull Request vers main.
Node / npm : le CI utilise Node.js 18 (voir .github/workflows/pa11y.yml). Installez les dépendances avant d’exécuter des scripts : npm ci.

🌘 Créer un nouvel article (script)

Fichier script : creer-blog.sh

Usage interactif (humain) :

./creer-blog.sh

Usage non-interactif (agent LLM) — exemple :

./creer-blog.sh --date 2026-04-06 --title "Mon titre" --category outils --tags "tag1,tag2" --description "Court descriptif" --yes

Règles pour l’agent :

Fournir --title en mode non-interactif (--yes), sinon le script échouera.
--category peut être un numéro (1…4) ou un texte (grimoire,alchimie,outils,collaborations).
Le script crée automatiquement le fichier Markdown dans blogue/YYYY/ et le dossier d’images correspondant sous static/images/blogue/YYYY/....
Après création, l’agent doit git add/commit/push la nouvelle page sur une branche, puis ouvrir une PR.

🌘 Commandes npm utiles (local / CI)

Installer dépendances :

npm ci

Build complet (Sass, images, Eleventy, pagefind) :

npm run build

Compiler seulement le Sass :

npm run build:sass

Servir le répertoire généré _site (local) :

npm run serve:static
# ou (plus simple) : npx http-server _site -p 8080

Lancer Pa11y localement (nécessite serve:static en fond) :

npx pa11y http://localhost:8080

Environnement de développement (watch) :

npm run dev
# ou lancer individuellement
npm run dev:11ty
npm run dev:sass

Déployer (script perso du dépôt) :

npm run deploy

🌘 CI

Un workflow GitHub Actions .github/workflows/pa11y.yml est présent pour lancer un scan Pa11y sur chaque push/PR vers main.
Les agents peuvent se reposer sur cette vérification, mais il est recommandé d’exécuter pa11y localement avant de proposer la PR si possible.

🌘 Recommandations opérationnelles pour agents

Toujours exécuter npm ci avant de lancer des builds locaux pour reproduire l’environnement CI.
Ne pas modifier _site dans les commits.
Valider que les fichiers créés disposent d’un frontmatter minimal : title, date, categories, tags, permalink, description.
Pour ajouter images : placer les fichiers sous static/images/blogue/YYYY/SLUG/ (le script crée déjà le dossier) puis référencer les chemins relatifs dans le frontmatter ou le contenu.
Tester localement : build + serve + pa11y. Commandes rapides :

npm ci
npm run build
npm run serve:static &
# vérifier
npx pa11y http://localhost:8080

🌘 Exemple de flux automatisé (agent)

Créer le contenu via ./creer-blog.sh --title "Titre" --date 2026-04-06 --category grimoire --tags "x,y" --description "desc" --yes.
git checkout -b add-post-<slug>
git add + git commit -m "Ajout article: <titre>"
git push --set-upstream origin add-post-<slug>
Ouvrir une Pull Request via API GitHub (titres, description, labels si nécessaire).
Laisser le CI exécuter pa11y et vérifier les résultats.

🌘 Notes de sécurité

Ne committez jamais de secrets (tokens, mots de passe). Utilisez les mécanismes secrets du CI pour actions automatisées.
Les agents doivent exécuter uniquement les commandes listées ici et éviter d’exécuter des scripts tiers inconnus.

🌘 Consignes de style (ton et forme)

Ces consignes reprennent le ton et la forme utilisés sur le blogue pour que les contenus générés restent cohérents avec ta voix.

Langue : rédige en français de France/Québec selon le vocabulaire du site (fr).
Ton : direct, convivial et pragmatique — tu utilises le tutoiement (tu) plutôt que le vouvoiement.
Voix : active, concise et orientée action ; privilégie des phrases courtes et des paragraphes brefs (2–4 lignes max).
Clarté : commencer par l’idée principale, puis détailler avec des exemples concrets ou commandes.
Exemples pratiques : illustre systématiquement les procédures par des commandes shell, extraits de code ou captures (si applicable).
Structure : utilisez des titres ## / ###, des listes à puces pour les étapes, et des blocs de code pour les commandes.
Terminologie : favorise le vocabulaire technique accessible (ex : “autohébergement”, “pandoc”, “Bash”) et évite le jargon marketing.
Style éditorial : ponctuation française (espaces insécables avant :, ;, !, ?), guillemets typographiques si nécessaire.
Accessibilité & liens : toujours fournir des liens explicites et descriptifs (texte du lien = destination), et privilégier des alt texts pour les images.
Ton humain : conserve un petit grain d’humour ou d’ironie quand c’est pertinent, mais pas au détriment de la clarté.
Sourcing : citer les sources et outils (liens), préférer des ressources libres quand possible.
Neutralité & inclusion : utiliser un langage inclusif et éviter les généralisations stéréotypées.

Exemple de phrase conforme au style :

"Pour automatiser cette tâche, écris un script Bash simple :

# Exemple : renommer tous les fichiers .txt
for f in *.txt; do mv "$f" "old_$f"; done

Cette commande te permet de tester rapidement l’idée avant d’industrialiser le script."