Content Pipeline

1. Quoi ? — Definition et contexte

Une idee vous vient sous la douche, vous la dictez en vocal sur Telegram. Un article interessant passe dans votre feed, vous envoyez l’URL au bot. Vous prenez une photo d’un tableau blanc apres une reunion. Chaque fois, le Content Pipeline structure le contenu avec Claude et le stocke comme note Obsidian dans un vault GitHub — pret a etre retrouve, enrichi, ou publie.

Obsidian

Obsidian est un editeur de notes en Markdown qui stocke tout en fichiers locaux. En utilisant un depot GitHub comme vault, les notes sont versionnees, accessibles partout, et synchronisables entre appareils.

Six types de contenu supportes

Commande	Type	Entree	Sortie
/note	Note	Texte libre	Note structuree avec wikilinks
/blog	Blog	Texte libre	Article avec intro, corps, conclusion
/research	Recherche	Sujet	Analyse approfondie avec sources
(URL)	URL	Lien web	Resume + points cles + citations
(vocal)	Voice	Audio	Transcription nettoyee et structuree
(photo)	Photo	Image	Texte OCR corrige et structure

Architecture

---

2. Pourquoi ? — Enjeux et motivations

Problemes resolus

Probleme	Sans pipeline	Avec pipeline
Idees perdues	Note dans un coin, jamais retrouvee	Vault Obsidian indexe et versionne
Mise en forme	Texte brut sans structure	Claude structure avec frontmatter
Contenu eparpille	Notes ici, bookmarks la	Un seul vault, un seul workflow
Publication laborieuse	Copier-coller entre apps	/blog → article pret a publier

Pourquoi un workflow de review ?

Le contenu genere par Claude n’est pas stocke directement. L’utilisateur recoit d’abord un apercu sur Telegram avec le titre, les tags, le chemin cible et les 500 premiers caracteres. Deux boutons permettent de valider ou annuler. C’est un filet de securite contre les erreurs de classification ou les notes mal formees.

Expiration automatique

Les contenus en attente de validation expirent apres 24 heures. Un workflow de nettoyage supprime les pendants non valides pour eviter l’accumulation.

---

3. Comment ? — Mise en oeuvre technique

Le parcours d’un contenu

1. Reception — L’Orchestrateur Telegram detecte une commande /note, /blog, /research, une URL, un vocal, ou une photo et route vers le Content Pipeline.

2. Consolidation — Un node Code normalise l’entree : le texte est extrait, les URLs sont fetchees (tronquees a 8000 caracteres), les vocaux arrivent deja transcrits, les photos deja OCRisees.

3. Generation Claude — Le LLM (Claude Sonnet via CLI Ollama, timeout 120s) recoit un prompt specifique au type de contenu. Chaque prompt definit la structure attendue, le frontmatter YAML, et les conventions de formatage (wikilinks pour les notes, sections pour les blogs, sources pour les recherches).

4. Stockage temporaire — Le Markdown genere est stocke dans la Data Table n8n_pending_actions avec un identifiant court (8 caracteres hex) et une expiration 24h.

5. Preview — L’utilisateur recoit un message Telegram avec l’apercu du contenu et deux boutons :

📝 Nouvelle note

Titre : Docker Networking Guide
Tags : docker, networking, guide
Chemin : notes/tech/2026-02-19-docker-networking-guide.md

Docker networking in practice involves understanding
bridge networks, overlay networks, and host mode...
[... tronque]

[Sauvegarder] [Annuler]

6. Sauvegarde — Au clic sur [Sauvegarder], l’Orchestrateur cree le fichier dans le depot GitHub guigpap/obsidian-vault via l’API et envoie une confirmation.

Classification automatique

Le chemin de stockage est determine par le type et les tags :

Condition	Chemin
Type = research	knowledge/
Type = blog	notes/projects/
Tag contient “project”	notes/projects/
Tag contient “reference”	notes/reference/
Defaut	notes/tech/

Le fichier est nomme {date}-{slug}.md (ex: 2026-02-19-docker-networking-guide.md).

Format de sortie

Chaque note est un fichier Markdown avec frontmatter YAML :

---
title: "Docker Networking Guide"
tags: [docker, networking, guide]
date: 2026-02-19
source: "telegram"
status: "draft"
type: "note"
slug: "docker-networking-guide"
---

Pour les articles de blog, deux champs supplementaires sont generes : description (meta description) et une structure avec Introduction, Corps, Conclusion.

Pour les recherches, le contenu inclut : Vue d’ensemble, Points cles, Details techniques, Sources, Sujets connexes.

Un second vault : vps-vault

Le pipeline ci-dessus alimente le vault personnel. Un second vault Obsidian, vps-vault, a ete cree depuis pour tout ce qui concerne l’infrastructure elle-meme. La difference tient a la provenance : le vault personnel recoit ce que l’utilisateur capture, vps-vault recoit ce que le systeme produit.

Dossier	Source	Rafraichissement
docs/stacks_vps/	Miroir des docs/*.md et des CLAUDE.md du depot	Cron quotidien 07:30
blog/published/	Miroir des articles publies du blog, convertis .mdx → .md	Meme cron
drafts/	Brouillons d’articles en cours	Manuel
research/, inbox/	Notes ecrites par l’agent Hermes	A la demande

Les deux premiers dossiers sont en lecture seule : la source de verite reste le depot d’origine, le vault n’en est qu’une projection. La conversion des articles de blog ne garde que les .mdx francais ranges dans un sous-dossier — les pages de navigation racine et la version anglaise sont ecartees pour ne pas polluer la recherche — et injecte deux champs de provenance dans le frontmatter, url et source, pour toujours pouvoir remonter a l’original.

L’interet de cette projection est double : le vault est consultable depuis un telephone via un client Git, et surtout il devient une base de connaissance interrogeable par l’agent, qui y accede en lecture avec vault_search / vault_list / vault_read et peut y deposer des notes avec vault_write, confine a research/ et inbox/.

Les cles SSH a passphrase cassent le cron silencieusement

Le cron de synchronisation et les pulls de l’agent utilisaient au depart la cle SSH du compte GitHub, protegee par une passphrase. En interactif tout fonctionnait ; en non-interactif, chaque push echouait sans bruit — la synchronisation a ete morte deux semaines avant d’etre remarquee. Le correctif : une deploy key sans passphrase par depot (une en lecture-ecriture pour le vault, une en lecture seule pour le blog), chacune avec son alias SSH utilise comme remote. Un echec de push renvoie desormais pushed: false avec le detail de l’erreur, au lieu de passer inapercu.

---

4. Et si ? — Perspectives et limites

Limites actuelles

Limite	Impact	Mitigation
Pas de deduplication	Envoyer 2x la meme URL = 2 notes	L’utilisateur peut annuler
OCR imparfait	Photos de mauvaise qualite = texte brouillon	Claude corrige les erreurs evidentes
Pas de recherche dans le vault personnel	Retrouver une note = parcourir les fichiers	Tags + Obsidian search + Qdrant (prevu). Cote vps-vault, vault_search couvre deja le besoin

Scenarios d’evolution

Si besoin de publication automatique :

• Publication blog automatique (workflow archive, publication manuelle desormais)
• Les notes de type blog avec status: ready sont candidates a la publication

Si besoin de recherche semantique :

• Generer des embeddings pour chaque note
• Stocker dans Qdrant pour une recherche vectorielle
• Commande /search dans Telegram pour interroger le vault

Si volume de notes augmente :

• Ajouter des sous-dossiers par mois ou par projet
• Creer un index automatique dans Obsidian
• Digest hebdomadaire des notes recentes

---

Pages liees

Workflows

• Telegram Orchestrator — Routage des commandes contenu
• Voice Transcription — Transcription des messages vocaux
• Vision OCR — Pipeline d’extraction sur images

Infrastructure

• AI Stack — CLI Ollama pour Claude
• Hermes Agent — Outils de lecture et d’ecriture sur vps-vault