OpenClaw

Produire une Revue IA avec OpenClaw : Cas Réel Média

4 826 actualités indexées, 10 sujets traduits chaque matin. unclejoeyao666 l'a fait avec OpenClaw. Setup multiformat complet et limites observées sur Discord.

La Pince

La Pince

— 5 min de lecture
Produire une Revue IA avec OpenClaw : Cas Réel Média

Bon dimanche ! ☕

Aujourd'hui, on démonte un cas qui va bien au-delà du résumé RSS envoyé par cron. Un développeur a construit avec OpenClaw une petite rédaction automatisée : collecte mondiale, sélection, traduction chinoise, site web, version audio et livraison Discord.

🎯 Le Cas : Une Revue IA Multiformat Chaque Matin

Auteur : unclejoeyao666
Contexte : un développeur maintient une revue quotidienne chinoise de l'actualité IA et tech, avec ses données, scripts et sorties publiés dans un dépôt GitHub créé le 5 avril 2026.
Objectif : transformer des flux RSS en dix sujets récents, les traduire, les publier sur un site consultable, produire un MP3 puis livrer texte et audio sur Discord sans intervention quotidienne.

📖 L'Histoire

Le problème de départ est familier : les sources techniques sont nombreuses, les nouvelles vieillissent vite et une simple agrégation déplace le travail au lieu de le supprimer. Il faut encore trier, traduire, mettre en forme et distribuer. Ici, l'auteur vise une édition chinoise matinale, pas un entrepôt de liens.

La première version conservée dans archive/v1 reposait déjà sur une base SQLite, un collecteur et des fichiers Markdown quotidiens. Le dépôt montre ensuite une évolution vers un pipeline découpé en étapes explicites. C'est un détail important : OpenClaw ne reçoit pas un immense prompt chargé de tout faire. Il orchestre des scripts déterministes et réserve le raisonnement aux opérations qui en ont besoin, notamment la sélection et la traduction.

La version actuelle répartit la production entre huit jobs cron. La collecte et la sélection démarrent, puis trois tentatives de traduction peuvent reprendre uniquement les éléments en attente. Un dernier fallback élimine les entrées non traduites plutôt que de publier un mélange incohérent. La publication du site et de l'audio arrive ensuite, avant une livraison Discord séparée. Un watchdog horaire inspecte l'état et reprend le pipeline.

Le résultat est observable. Au 7 juin, l'état versionné indique 4 826 entrées en base, 520 encore disponibles, dix sujets sélectionnés puis dix traductions terminées. L'article, le brief, l'audio de 2,4 Mo et le push sont marqués ok. Le dépôt contient 38 fichiers briefing.md dans la version actuelle, en plus des archives d'avril. Ce n'est donc ni une maquette ni une simple capture d'écran.

🔧 Le Setup Technique

Architecture Agent

Le système sépare orchestration et exécution :

RSS -> SQLite -> sélection de 10 sujets -> traduction
    -> article Astro + brief -> TTS -> GitHub Pages
    -> livraison texte + MP3 sur Discord

OpenClaw : 8 crons + reprises cognitives + message Discord
Python   : collecte, états, rendu, publication et watchdog
SQLite   : source de vérité des articles et traductions
GitHub   : historique, déploiement du site et audit des sorties

Les jobs sont isolés dans le temps : récolte à 04:00 UTC, traduction à 04:30, retries à 05:15 et 06:00, fallback à 06:25, publication à 06:30, livraison à 07:00, plus un watchdog horaire. La livraison publique n'utilise qu'un chemin : stage_d_delivery.py prépare le contenu, OpenClaw envoie les messages, puis le script enregistre les vrais identifiants Discord.

Fichiers Clés

Instruction d'orchestration

Le SKILL.md de production reste local chez l'auteur, donc son prompt exact n'est pas public. Le README documente toutefois son contrat opératoire :

Production uses 8 OpenClaw cron jobs.
Stage D is the only public delivery path.
The hourly watchdog performs deterministic resume.

État et commandes de contrôle

python3 scripts/daily_pipeline.py --date today --status
python3 scripts/daily_pipeline.py --date today --from harvest --to select
python3 scripts/translate_helper.py pending --date today
python3 scripts/translate_helper.py finalize --date today
python3 scripts/daily_pipeline.py --date today --from publish_article --to push
python3 scripts/stage_d_delivery.py prepare --date today
python3 -m scripts.lib.news_db data/news.db --stats

Chaque journée possède un .state.json. Les étapes harvest, select, translate, publish_article, publish_brief, audio et push y passent de pending à ok ou failed. Les livraisons Discord enregistrent séparément canal, identifiant du message, taille du MP3 et heure de fin.

Étapes de Mise en Place

  1. Déclarer les flux dans data/sources.json et la taxonomie dans data/tags.json.
  2. Initialiser SQLite et vérifier les statistiques avec le module news_db.
  3. Tester localement la chaîne harvest vers select, sans publication.
  4. Configurer les jobs OpenClaw par étape, avec des horaires espacés et des retries limités aux traductions en attente.
  5. Générer le site Astro et activer le déploiement GitHub Pages via .github/workflows/deploy.yml.
  6. Configurer Microsoft Edge TTS comme moteur principal et MiniMax comme secours.
  7. Préparer la livraison avec stage_d_delivery.py, envoyer par l'outil de messagerie OpenClaw, puis enregistrer les IDs retournés.
  8. Ajouter un watchdog qui lit l'état et reprend la première étape incomplète, sans relancer toute la journée.

📊 Les Résultats

Gains mesurés :

  • 4 826 entrées indexées au 7 juin 2026 ;
  • dix sujets sélectionnés et dix traductions terminées lors de l'exécution du jour ;
  • 38 briefings versionnés dans le pipeline actuel ;
  • une sortie simultanée en article, brief, site, MP3 et messages Discord ;
  • des IDs Discord réels conservés comme preuve de livraison le 6 juin.

Ces chiffres mesurent la production, pas le temps économisé. L'auteur ne publie aucun chronométrage manuel avant/après : affirmer « trois heures gagnées par jour » serait inventé.

Limites rencontrées :

  • Le 5 juin, la traduction est restée en échec après plusieurs jours et les étapes suivantes sont demeurées en attente.
  • Le runbook canonique et les payloads cron sont sur la machine de l'auteur, pas dans le dépôt public.
  • Aucun indicateur public ne mesure la qualité éditoriale, les erreurs de traduction ou l'audience.
  • Les fichiers audio ne sont pas versionnés dans Git, même si leur taille et leur état sont tracés.

🧐 Analyse Critique

✅ Ce qui est bien fait

  • Une source de vérité explicite. SQLite contient les données, tandis que .state.json décrit l'exécution. L'agent n'a pas à deviner ce qui a déjà été fait.
  • Des reprises ciblées. Les retries traitent les traductions en attente au lieu de recommencer collecte et sélection. Cela réduit coûts, doublons et effets de bord.
  • Une frontière nette avant publication. Un seul stage livre au public et les IDs Discord sont enregistrés après l'envoi réel. C'est beaucoup plus auditable qu'une annonce cron supposée réussie.
  • Le déterminisme là où il compte. Scripts Python, fallback et watchdog encadrent les opérations génératives. OpenClaw orchestre ; il ne remplace pas toute la logique métier.

⚠️ Points d'attention

  • Le watchdog ne garantit pas la guérison. L'échec du 5 juin montre qu'une reprise répétée ne corrige pas une donnée invalide. Il faut une alerte humaine et une politique d'abandon claire.
  • Les secrets traversent plusieurs services. RSS privés éventuels, GitHub, moteur TTS et Discord exigent des permissions minimales et des journaux qui ne divulguent aucun token.
  • La fraîcheur peut masquer la qualité. Sélectionner dix sujets est mesurable ; vérifier leur importance et la fidélité de la traduction demande encore un échantillonnage éditorial.
  • La reproductibilité est partielle. Le code est public, mais pas le skill canonique ni la configuration exacte des crons. Le lecteur doit reconstruire cette couche.

💡 Améliorations possibles

  • Ajouter un budget d'erreur : après trois échecs, isoler l'article fautif, publier neuf sujets et ouvrir une alerte structurée plutôt que bloquer toute l'édition.
  • Versionner un exemple nettoyé du SKILL.md et un export des huit jobs cron, sans secrets, pour rendre le déploiement réellement reproductible.
  • Mesurer chaque semaine un échantillon de traductions, le taux de liens invalides, la durée par étape et le coût par édition.

🎓 Ce qu'on en retient

Leçons clés :

  1. Un agent fiable orchestre des étapes observables ; il ne cache pas toute la chaîne dans un prompt.
  2. La reprise doit partir d'un état persistant et cibler uniquement le travail incomplet.
  3. Une preuve de livraison, comme un ID Discord, vaut mieux qu'un statut « envoyé » déclaré avant l'appel externe.

Pour aller plus loin :

À dimanche prochain pour un nouveau cas ! 🦞

Lire la suite