Forger un Livre avec OpenClaw : Cas Réel Média
Avant : un manuscrit qui dérive au fil des prompts. Après : un workflow à gates, sources et PDF. Comment shoripanda forge un livre avec OpenClaw.
Bon dimanche ! ☕
Aujourd'hui, on plonge dans un cas réel un peu différent des automatisations "je surveille un flux et j'envoie une notification". Ici, le sujet est plus ambitieux : transformer une conversation avec un agent en chaîne éditoriale capable de produire un livre, un essai ou un rapport jusqu'au PDF.
Le dépôt public openclaw-automations de shoripanda contient plusieurs workflows construits avec OpenClaw. Le plus intéressant, book-forge, ne vend pas une promesse magique de "livre écrit en un clic". Il documente plutôt une méthode à portes successives, avec état persistant, vérification des sources, validation humaine du plan, détection du style trop IA, et génération LaTeX/PDF.
🎯 Le Cas : Book Forge
Auteur : shoripanda (source GitHub)
Contexte : un dépôt public créé le 20 août 2026, qui rassemble des automatisations réalisées avec OpenClaw : veille Telegram, digest IA et workflow d'écriture longue.
Objectif : permettre à un agent OpenClaw de piloter la création d'un manuscrit long sans perdre l'état du projet, ni sauter les étapes critiques.
📖 L'Histoire
Le problème de départ est familier : les agents sont bons pour rédiger un paragraphe, un plan ou une synthèse. Ils deviennent beaucoup moins fiables quand le travail dure plusieurs sessions, demande des validations intermédiaires et doit finir dans un artefact propre. Un livre, même court, force à gérer des contraintes que le chat seul absorbe mal : sources, structure, interviews, objectifs de longueur, figures, mise en page, cohérence des termes, version finale.
book-forge répond en traitant le livre comme un projet, pas comme une conversation. Le coeur du système est un fichier project.json manipulé par scripts/pj.py. Ce fichier garde les métadonnées, les recherches, les réponses d'interview, le plan, les assets, l'état courant et le statut d'approbation. Autrement dit, OpenClaw peut reprendre le travail, changer d'environnement, ou passer d'un agent à un autre sans dépendre uniquement du contexte volatile.
Le choix le plus important est le découpage en phases. L'auteur impose un parcours 0 à 7 : intake, research, interview, outline, drafting, revision, layout, export. Chaque phase a son gate. On ne passe pas à la recherche tant que les métadonnées de base ne sont pas remplies. On ne passe pas à l'interview tant que les sources nécessaires ne sont pas enregistrées. Et surtout, on ne commence pas le manuscrit tant que l'auteur n'a pas validé le plan.
Ce n'est pas spectaculaire au sens "agent autonome qui fait tout". C'est plus sérieux : le workflow limite volontairement l'autonomie là où elle produit souvent des dégâts. L'agent peut chercher, structurer, questionner, rédiger et assembler. Mais il doit stocker ses preuves, exposer ses choix, et attendre une validation humaine au moment où le coût d'une erreur devient élevé.
🔧 Le Setup Technique
Architecture Agent
Dialogue OpenClaw
-> intake guidé : type de livre, lecteur, objectif, longueur, ton
-> project.json : état durable partagé entre sessions
-> recherche web : sources avec URL + date de consultation
-> interview : matière originale de l'auteur
-> gate outline : plan approuvé avant rédaction
-> manuscript.md : rédaction longue
-> lint.sh : détection de "style IA"
-> build.sh : Markdown -> LaTeX -> PDF
Dans OpenClaw, le rôle de l'agent principal est de tenir la conversation et d'orchestrer les étapes. Les recherches larges peuvent être confiées à des sous-agents ou à des outils web. Les scripts, eux, stabilisent les opérations répétables : écrire dans project.json, vérifier les gates, compiler le PDF, relancer le lint.
Fichiers Clés
SKILL.md
name: "book-forge"
description: "本や小論文を対話で作る。資料裏取り→インタビュー→目次承認→執筆→lint→組版→PDF/LaTeX出力まで一貫."
Le fichier décrit une compétence complète : création d'un livre ou d'un essai par dialogue, collecte de sources, interview, plan approuvé, rédaction, révision, mise en page et export.
project.json via pj.py
python3 scripts/pj.py init ./mybook --種類 技術書 --体裁 book --判型 四六 \
--読者 "lecteurs techniques" --狙い "comprendre un workflow agentique" \
--目標文字数 5000 --トーン "pédagogique"
python3 scripts/pj.py add-research ./mybook \
--出典 "Documentation officielle" \
--url "https://example.com/source" \
--要点 "Point vérifié à intégrer" \
--裏取り true \
--参照日 2026-08-23
python3 scripts/pj.py check ./mybook research
Compilation
PAPER=四六 FONTSIZE=9pt MARGIN=14 LINESPREAD=1.05 \
bash scripts/build.sh ./mybook/manuscript.md ./mybook/out
Le script produit book.tex et book.pdf avec Pandoc et Tectonic, en exposant les paramètres de densité : format, taille de police, marges, interligne.
Étapes de Mise en Place
- Cloner le dépôt :
git clone https://github.com/shoripanda/openclaw-automations.git
cd openclaw-automations/book-forge
- Initialiser un projet :
python3 scripts/pj.py init ./mybook --種類 技術書 --体裁 book --判型 A5 \
--読者 "makers et développeurs" --狙い "documenter une méthode" \
--目標文字数 12000 --トーン "clair"
- Vérifier le gate d'intake :
python3 scripts/pj.py check ./mybook intake
python3 scripts/pj.py state ./mybook research
- Ajouter des sources vérifiées :
python3 scripts/pj.py add-research ./mybook \
--出典 "Titre de la source" \
--url "https://..." \
--要点 "Ce que la source prouve" \
--裏取り true \
--参照日 2026-08-23
- Enregistrer l'interview :
python3 scripts/pj.py add-interview ./mybook \
--q "Quelle expérience personnelle doit absolument apparaître ?" \
--a "Réponse brute de l'auteur"
- Poser le plan, puis l'approuver :
python3 scripts/pj.py set-outline ./mybook '[{"章":"Chapitre 1","節":["Pourquoi ce sujet compte"],"目標字数":3000,"メッセージ":"Le problème est opérationnel avant d'être rédactionnel","状態":"draft"}]'
python3 scripts/pj.py approve ./mybook
- Rédiger
manuscript.md, relire, linter et compiler :
bash scripts/lint.sh ./mybook/manuscript.md tech --json
bash scripts/build.sh ./mybook/manuscript.md ./mybook/out
📊 Les Résultats
Gains mesurés :
- 8 phases explicites, de l'intake à l'export, au lieu d'une conversation longue sans état fiable.
- 1 fichier
project.jsoncomme source de vérité, réutilisable entre OpenClaw, Claude Code et ChatGPT. - 2 artefacts finaux prévus :
book.texpour l'édition etbook.pdfpour la relecture.
Limites rencontrées :
- Le dépôt ne fournit pas de métrique de temps économisé ni de livre complet publié comme preuve finale.
- Le workflow dépend d'outils externes pour la mise en page : Pandoc, Tectonic, polices japonaises, et éventuellement le skill
natural-japanese. - La partie "agent OpenClaw" est surtout décrite comme méthode d'orchestration ; les scripts rendent le workflow reproductible, mais pas entièrement plug-and-play.
🧐 Analyse Critique
✅ Ce qui est bien fait
- L'état est externalisé.
project.jsonévite le piège classique : un agent qui "se souvient" tant que le fil est ouvert, puis oublie les décisions dès qu'on change de session. - Les gates protègent la qualité. Le point le plus fort est l'interdiction d'écrire le manuscrit avant validation du plan. Cela réduit les dérives coûteuses : mauvais angle, mauvais lecteur, mauvaise structure.
- Les erreurs sont documentées.
FAILURE-LOG.mdliste des échecs concrets : police japonaise mal rendue, labels de graphiques qui chevauchent les lignes, légendes trop grandes, numérotation de figures doublée. C'est rare et précieux. - La sortie est éditoriale, pas seulement textuelle. Le workflow pense jusqu'au PDF et au LaTeX, avec densité de page ajustable. Pour un vrai manuscrit, c'est une différence énorme.
⚠️ Points d'attention
- Le lint peut devenir un faux sentiment de sécurité. Détecter le "style IA" aide, mais ne remplace pas une vraie révision éditoriale. Un texte peut sonner naturel et rester creux.
- La vérification des sources repose sur la discipline de l'agent. Le script impose des champs URL et date, mais il ne prouve pas automatiquement que la source soutient bien la phrase utilisée.
- La compilation peut être fragile selon l'environnement. Les polices japonaises et Tectonic ne seront pas identiques sur macOS, Linux ou un serveur minimal.
- Le workflow est très adapté au japonais. Les champs, consignes et exemples sont en japonais. C'est logique pour l'auteur, mais un lecteur francophone devra traduire ou adapter les clés.
💡 Améliorations possibles
- Ajouter un exemple complet de
project.json,manuscript.md,book.texetbook.pdfgénérés de bout en bout. - Créer une commande
doctorqui vérifie Pandoc, Tectonic, les polices disponibles et la présence du lint avant de lancer un projet. - Ajouter un gate de fact-check final : chaque affirmation sourcée importante devrait être reliée à une entrée
research[]. - Fournir un adaptateur OpenClaw prêt à l'emploi, avec prompts d'agents séparés pour recherche, interview, plan, rédaction et révision.
🎓 Ce qu'on en retient
Leçons clés :
- Un bon agent d'écriture longue n'est pas seulement un générateur de texte : c'est un gestionnaire d'état, de preuves et de validations.
- Les gates humains sont plus utiles quand ils arrivent avant la production massive, pas après 80 pages à corriger.
- Les scripts simples restent indispensables : ils transforment une méthode conversationnelle en workflow vérifiable.
Pour aller plus loin :
- Écrire des Articles avec OpenClaw : Cas Réel Média
- Produire une Revue IA avec OpenClaw : Cas Réel Média
- Source originale
À dimanche prochain pour un nouveau cas ! 🦞