Dans les coulisses de GrevireBlog : comment cet article a été écrit par un workflow Humain+IA

Dicté par Brocasm et corrigé et traduit par mistral-14b

TL;DR — Cet article documente le workflow humain+IA derrière GrevireBlog : d’une note dans l’inbox Obsidian (ou d’un mémo vocal) à un article bilingue publié. DeepSeek V4 Flash orchestre le pipeline (rédaction, Git, PR), tandis que Mistral 14B s’occupe de la correction linguistique et de la traduction. L’ancrage contextuel (Mem0, LLM Wiki, mémoire de session) empêche l’hallucination, et la validation humaine reste le filtre final. Stack technique : Hugo, Gitea, Docker, Obsidian, rclone.

Le défi autoréférentiel

Tu es en train de lire un article qui explique comment les articles de ce site sont fabriqués. Méta, je sais.

Mais c’est exactement le sujet. Après des semaines à construire un pipeline multi-modèle IA pour passer d’une idée brute dans Obsidian à un article publié sur blog.grevire.dev — avec brouillons, validation, traduction, et déploiement automatisé — je me suis dit que le processus méritait d’être documenté.

Alors voilà : l’histoire de comment une note jetée dans un fichier markdown devient un article bilingue peaufiné, que vous lisez en ce moment même. Et pourquoi mistral-14b s’occupe des mots pendant que DeepSeek V4 Flash dirige le spectacle.

Le problème : de l’idée à l’article publié

Quiconque écrit régulièrement connaît les points de friction :

Capture — Tu as une idée, mais où la poser pour ne pas la perdre ?
Développement — Transformer une liste à puces en article structuré demande du temps et de la volonté
Traduction — Un blog bilingue (EN + FR), c’est tout faire en double
Publication — Git, PR, CI/CD, déploiement — beaucoup de cérémonie pour un blog
Distribution — Reddit, LinkedIn, X — chaque plateforme a son ton

La solution typique ? Accepter la friction (et donc écrire moins), ou balancer un LLM unique et prier pour que ça marche. Je voulais quelque chose de plus réfléchi — une division du travail où chaque outil fait ce qu’il fait de mieux.

L’architecture : deux modèles, un pipeline

🧑 L’humain (moi)

Je fais ce que les humains font le mieux :

Capturer les idées brutes dans mon inbox Obsidian (05_Inbox/blog/)
Valider les brouillons — lire, corriger, approuver ou rejeter
Poster le thread Reddit (le contact humain compte dans l’engagement communautaire)
Décider du ton, de l’angle, et de la publication

🤖 La couche IA

DeepSeek V4 Flash — Le Chef d’Orchestre

DeepSeek V4 Flash tourne dans Hermes Agent, mon assistant IA personnel. Il joue le rôle d’orchestrateur :

Détecte une nouvelle note dans l’inbox
Crée le dossier article et les fichiers brouillons (blog-en.md, blog-fr.md, reddit-en.md…)
Rédige le brouillon complet en suivant les conventions du blog (frontmatter, attribution, i18n)
Gère tout le workflow Git : branche → commit → PR → push
Met à jour la note Obsidian archivée avec les liens Reddit après publication

Pourquoi DeepSeek V4 Flash ? Parce que le rôle d’orchestrateur demande :

Un long contexte — garder en tête le workflow complet, les définitions des skills, les conventions du blog et l’historique de la session
Une fiabilité d’outils — appeler Git, écrire des fichiers, lire Obsidian, créer des PRs
De la vitesse — c’est un workflow interactif, personne n’a envie d’attendre 30 secondes entre chaque étape
De la coordination — déléguer à d’autres modèles quand nécessaire (le rédacteur)

Mistral 14B — Le Styliste

Mistral 14B intervient pour ce qu’il fait de mieux : la langue.

Quand les brouillons sont prêts, un sous-agent propulsé par mistral-14b prend le rôle du rédacteur :

Relit les versions EN et FR
Corrige grammaire, orthographe, syntaxe
Traque les anglicismes dans la version française (le fléau de tout blog tech suisse en français — « outage » devient « panne », « messenger » devient « messagerie », « traffic » devient « trafic »)
Vérifie la cohérence des deux versions — même structure, mêmes sections
Contrôle le frontmatter (date, tags, attribution, description SEO < 160 caractères)

Pourquoi ne pas tout faire avec DeepSeek ? Parce que la spécialisation des modèles compte :

Tâche	Modèle	Pourquoi
Orchestration du workflow	DeepSeek V4 Flash	Long contexte, usage d’outils, coordination multi-étapes
Relecture / correction	Mistral 14B	Meilleure nuance linguistique, plus léger, plus rapide pour le texte
Conventions du blog	Définitions dans les skills	Documentées une fois, réutilisées à chaque fois (pas de dérive de prompt)

Le point clé : aucun modèle n’est le meilleur partout. Un pipeline de modèles spécialisés, chacun faisant ce dans quoi il excelle, surpasse l’approche monolithique « un modèle pour les gouverner tous ».

Le flux complet, de l’inbox à l’article publié

Obsidian 05_Inbox/blog/<sujet>/note.md    ← j'écris l'idée
  → Sous-dossier avec fichiers brouillons  ← DeepSeek V4 Flash
    → blog-en.md + blog-fr.md              ← DeepSeek V4 Flash rédige
      → Revue par le rédacteur (mistral-14b) ← Polish linguistique
        → Je valide dans Obsidian           ← Relecture humaine
          → PR sur Gitea → merge           ← DeepSeek V4 Flash
            → CI/CD build + déploie        ← Gitea Actions + cron poll
              → Blog en ligne 🎉
                → Je poste le thread Reddit avec lien blog
                  → Note Obsidian mise à jour avec lien Reddit et archivée

Ce qui se passe à chaque étape :

Inbox (05_Inbox/blog/) — Je dépose une note avec l’idée brute. Un titre, une liste, un flux de conscience. Parfois, je ne tape même pas — j’enregistre un mémo vocal vite fait, et Mistral 14B le retranscrit en texte. Cette capture audio + transcription IA rend l’étape de rédaction initiale presque sans friction. La qualité bénéficie déjà de l’ancrage contextuel (Mem0, LLM Wiki, mémoire de session) qui garde la transcription pertinente et ancrée dans la réalité du projet.
Génération des brouillons — DeepSeek V4 Flash détecte la note et crée un sous-dossier avec des fichiers séparés pour chaque brouillon. L’article (EN + FR), le thread Reddit, optionnellement LinkedIn et X. Tout reste dans Obsidian — rien n’est publié.
Passage du rédacteur — Mistral 14B relit les brouillons. Il vérifie la grammaire, la cohérence, la validité du frontmatter, et applique les conventions du blog (ligne d’attribution, tags, format de date). Il est impitoyable avec les anglicismes dans la version française.
Validation humaine — J’ouvre chaque fichier dans Obsidian, je lis, je corrige si besoin, je valide. Les brouillons sont en markdown — aussi naturel que d’éditer une note.
Git + PR — DeepSeek crée une branche feature, commit les articles validés, et ouvre une Pull Request sur Gitea.
CI/CD — Je merge la PR. Gitea Actions build une image Docker, la pousse vers notre registry Harbor, et une tâche cron interroge pour déployer les nouvelles images.
Publication — Le blog est en ligne sur blog.grevire.dev. Je poste le thread Reddit avec le lien de l’article.
Archivage — Le dossier Obsidian passe de 05_Inbox/blog/ à 04_Archives/ avec le lien Reddit ajouté à la note. Traçabilité complète.

Pourquoi ces choix techniques ?

Hugo, pas WordPress ou Astro

J’ai choisi Hugo pour sa simplicité :

Binaire unique, zéro dépendance runtime
Les fichiers Markdown comme source de vérité (pas de base de données)
Builds rapides (quelques millisecondes pour un blog de cette taille)
Le thème github-style donne un rendu propre et familier

Le blog tourne dans un conteneur Docker derrière NGINX. La CI/CD utilisait à l’origine Watchtower pour le déploiement automatique, mais la version actuelle du Docker Engine n’est plus compatible. On a temporairement remplacé ça par une tâche cron qui interroge notre registry Harbor et tire les nouvelles images. Un remplacement plus complet — GrevireWatch — est en développement actif (un agent Go basé sur webhook + un manager Python). Un article suivra sur ce sujet.

Gitea Actions → Docker build → Registry Harbor → Cron poll (temporaire) → GrevireWatch (WIP)

Le piège `<relative-time>`

Un bug que nous avons rencontré : le thème utilise le composant web <relative-time> de GitHub. Si le champ date du frontmatter ne contient que la date sans heure (ex: 2026-05-15 au lieu de 2026-05-15T18:55:00+02:00), Hugo parse à minuit. L’affichage relatif indique « 18h ago » au lieu du vrai « quelques minutes ago ». Un petit détail qui fait une grande différence dans l’expérience utilisateur.

Obsidian comme CMS

Utiliser Obsidian comme couche de gestion de contenu peut sembler inhabituel, mais c’est étonnamment efficace :

Local d’abord — pas de latence, pas de spinners de chargement
Markdown natif — exactement ce que Hugo consomme
Liage — les [[wikilinks]] permettent de faire des références croisées entre idées
Synchronisé — le vault est synchronisé via Nextcloud + rclone bisync

Le sous-dossier 05_Inbox/blog/ sert de zone de staging. Les brouillons y vivent, sont relus, puis soit publiés (→ blog), soit conservés comme notes (→ notes permanentes).

Ce que j’ai appris

1. La sélection du modèle compte

Cas d’usage	Modèle	Pourquoi pas l’autre
Orchestration / outils	DeepSeek V4 Flash	Mistral 14B galère avec les séquences d’outils multi-étapes
Édition linguistique	Mistral 14B	DeepSeek V4 Flash est surdimensionné pour du texte pur et moins précis sur les nuances françaises
Conventions du blog	Hardcodées dans les skills	Les deux modèles chargent les mêmes conventions — cohérence sans ingénierie de prompt

2. La structure bat les prompts

Les conventions du blog (format du frontmatter, ligne d’attribution, style des tags, format de date) sont documentées une fois dans un fichier skill que les deux modèles chargent. Pas besoin de répéter les mêmes instructions à chaque prompt — elles sont intégrées au système. C’est le cœur de l’approche Grevire pour les workflows IA : documenter le processus une fois, laisser l’IA le charger au besoin.

3. L’humain dans la boucle n’est pas optionnel

L’IA rédige. L’IA relit. L’IA pousse le code. Mais je valide. Chaque article est lu par un humain avant publication. L’IA enlève la friction, pas le jugement.

Cela dit, la qualité de l’article final commence par la qualité de la note initiale. Une note d’inbox vague produit un brouillon vague. Une idée bien structurée — même en quelques puces — donne à l’IA quelque chose de solide sur quoi travailler. Garbage in, garbage out s’applique toujours, même avec les meilleurs modèles.

On utilise aussi un ancrage contextuel pour garder l’IA sur les rails. Avant de rédiger, Hermes Agent charge :

Mem0 — les mémoires long terme de l’utilisateur (préférences, décisions passées, contexte technique)
LLM Wiki — une base de connaissance structurée avec les entités, concepts et sources brutes de l’écosystème projet
Mémoire de session — l’historique récent de la conversation pertinent pour le sujet

Ça empêche le modèle d’halluciner des faits sur l’infrastructure, d’inventer des outils qui n’existent pas, ou de contredire des décisions passées. Le résultat est un contenu à la fois créatif et ancré dans la réalité du projet.

Le résultat : plus d’écriture, moins de friction

Depuis la mise en place de ce pipeline, je suis passé de « faudrait que j’écrive un truc là-dessus » à des articles réellement publiés en beaucoup moins de temps. Le workflow gère les parties mécaniques — rédaction, traduction, mise en forme, déploiement — pendant que je me concentre sur l’essentiel : avoir quelque chose qui mérite d’être dit.

Les modèles changent. Les outils évoluent. Mais le principe reste : laisser chaque outil faire ce qu’il fait de mieux, et ne jamais laisser l’outil prendre la décision finale.

Cet article a été écrit en utilisant exactement le workflow qu’il décrit — d’une note dans l’inbox Obsidian, rédigé par DeepSeek V4 Flash, relu par Mistral 14B, validé par un humain, et déployé via Git → CI/CD.

Stack technique : Hermes Agent · DeepSeek V4 Flash · Mistral 14B · Hugo · Gitea · Docker · Harbor · Obsidian · rclone

GrevireDev / Dans les coulisses de GrevireBlog : comment cet article a été écrit par un workflow Humain+IA