Écrire des Articles avec OpenClaw : Cas Réel Média

Bon dimanche ! ☕

Aujourd'hui, on plonge dans un cas un peu inconfortable, mais très utile : un journaliste qui a tenté de construire un agent OpenClaw capable de faire une partie de son propre travail. Pas une démo "hello world", pas une todo-list automatisée : un vrai workflow éditorial, avec recherche, angle, brouillon, et jugement humain à la fin.

La source est un article de Fast Company publié le 26 février 2026 par Thomas Smith. Une partie du contenu complet est derrière friction d'accès, donc l'analyse ci-dessous distingue volontairement deux choses : ce que la source documente explicitement, et le setup reproductible qu'un lecteur peut reconstruire proprement à partir du cas.

🎯 Le Cas : Agent de Rédaction pour Article Tech

Auteur : Thomas Smith (Fast Company)
Contexte : journaliste tech chez Fast Company, habitué à transformer des signaux faibles en articles lisibles pour un public business/innovation.
Objectif : tester si un agent OpenClaw peut produire un brouillon journalistique exploitable, pas seulement répondre à une question isolée.

Le titre original est direct : "I built an OpenClaw AI agent to do my job for me. The results were surprising—and a little scary". L'article précise que l'auteur a installé OpenClaw, construit son propre agent, puis l'a entraîné à faire son travail. Le résultat n'est pas présenté comme une substitution totale, mais comme une expérience suffisamment crédible pour poser la vraie question : que reste-t-il au journaliste quand l'agent sait chercher, structurer et rédiger vite ?

📖 L'Histoire

La situation de départ est familière : les grands acteurs de l'IA promettent depuis longtemps des agents capables d'agir, mais la plupart des produits grand public restent prudents. Ils répondent, ils résument, ils suggèrent. Ils prennent rarement des décisions opératoires dans un environnement réel, parce que le risque d'erreur augmente dès qu'un modèle peut cliquer, publier, envoyer, modifier ou interpréter des sources à la place d'un humain.

OpenClaw inverse en partie cette logique. L'outil assume le côté bricolé, configurable, très puissant, parfois rugueux, d'un agent personnel. Ce n'est pas une boîte noire qui promet "un assistant magique". C'est une plateforme où l'on décrit une identité, des permissions, des outils, des workflows et des limites. Pour un journaliste, cela change tout : au lieu de demander "écris-moi un article sur X", on peut construire un système qui surveille un sujet, lit plusieurs sources, propose un angle, produit un brouillon et laisse l'humain arbitrer.

Dans le cas de Thomas Smith, le test consiste à pousser cette logique dans un territoire sensible : son propre métier. L'article explique qu'il a installé OpenClaw, créé un agent, et lui a donné une mission éditoriale. La formulation "to do my job" est volontairement provocante, mais le point intéressant est ailleurs : le job n'est pas une seule tâche. C'est une chaîne. Il faut choisir un sujet, comprendre le contexte, éviter les contresens, écrire clairement, savoir ce qui mérite d'être cité, puis décider si le texte est publiable.

C'est là que le cas devient intéressant pour les lecteurs d'OpenClaw. Un agent de rédaction n'est pas dangereux parce qu'il génère du texte. Tous les LLM font déjà ça. Il devient sérieux quand il manipule un workflow complet : recherche web, extraction d'informations, synthèse, production Markdown, vérification, puis éventuellement envoi vers un CMS. Le bon design n'est donc pas "agent autonome ou rien". C'est une chaîne avec des points d'arrêt.

🔧 Le Setup Technique

Architecture Agent

Voici une architecture reproductible et prudente pour reproduire ce cas sans confondre expérimentation et publication automatique :

Session principale
  -> Agent éditorial OpenClaw
     -> Source watcher : recherche web ciblée
     -> Fetcher : lecture des sources retenues
     -> Curator : extraction faits / citations / incertitudes
     -> Writer : brouillon Markdown
     -> Reviewer : checklist qualité + risques
     -> CMS draft : création en brouillon uniquement

Le point central : la publication reste hors de portée de l'agent. Le workflow peut créer un brouillon, mais la validation finale appartient au journaliste. C'est exactement le type de frontière qu'il faut poser quand l'agent travaille sur un contenu public.

Fichiers Clés

SOUL.md

# Editorial Agent

Tu es un assistant éditorial spécialisé tech.
Ton rôle : proposer des angles, vérifier les sources, rédiger des brouillons.

Règles :
- Ne jamais inventer une citation, une date ou un chiffre.
- Toujours lier chaque affirmation importante à une source.
- Signaler les incertitudes explicitement.
- Produire des brouillons, jamais publier directement.
- Garder un ton clair, concret, sans emballement marketing.

USER.md

# Editor Context

Audience : lecteurs business/tech.
Priorités : exactitude, angle clair, lecture fluide.
Tolérance au risque : faible pour les faits, moyenne pour les hypothèses signalées.

TOOLS.md

# Tools

- web_fetch : lire les sources retenues
- browser : vérifier les pages difficiles
- ghost draft script : créer un brouillon CMS
- memory : tracker les sujets déjà traités

Commande de brouillon

node scripts/create-ghost-draft.js \
  --title "Titre de travail" \
  --content drafts/article.md \
  --tags "OpenClaw,Média,Article" \
  --excerpt "Accroche courte pour review éditoriale"

Étapes de Mise en Place

1. Créer un workspace dédié au contenu, séparé des projets personnels ou clients.
2. Définir SOUL.md, USER.md et TOOLS.md avec des limites explicites.
3. Ajouter un tracker local pour éviter de retraiter les mêmes sujets.
4. Donner à l'agent une requête de veille précise, par exemple : "trouve 3 signaux crédibles sur les agents IA en entreprise, avec sources primaires".
5. Exiger une note de sourcing avant tout brouillon : URL, auteur, date, affirmation principale.
6. Générer le brouillon Markdown seulement après validation du plan.
7. Lancer une passe critique séparée : hallucinations possibles, angles faibles, citations manquantes, titre trop sensationnaliste.
8. Créer un draft CMS, puis relire humainement avant publication.

Ce setup est volontairement moins spectaculaire qu'un agent qui publie seul. C'est aussi ce qui le rend exploitable. Dans un workflow média, la vitesse n'a de valeur que si la traçabilité suit.

📊 Les Résultats

Gains observables :

• L'auteur a pu passer d'une idée expérimentale à un agent opérationnel capable de produire un brouillon d'article.
• Le workflow teste une chaîne complète, pas une simple génération de paragraphe.
• Le résultat a été jugé assez frappant pour devenir lui-même le sujet d'un article publié.

Limites rencontrées :

• La source accessible ne fournit pas de métrique chiffrée fiable du type "X heures économisées".
• Le setup exact de l'auteur n'est pas publié fichier par fichier.
• Le cas soulève plus de questions qualitatives que de benchmarks : exactitude, voix éditoriale, responsabilité, contrôle.

C'est une limite importante. Un bon case study ne doit pas transformer une expérience narrative en fausse étude quantitative. Ici, le résultat mesurable n'est pas un gain de temps certifié : c'est la preuve qu'un journaliste a pu construire un agent assez compétent pour automatiser une partie substantielle du processus éditorial.

🧐 Analyse Critique

✅ Ce qui est bien fait

• Le test porte sur un vrai métier. L'auteur ne demande pas à OpenClaw de résumer une page isolée. Il teste une chaîne qui ressemble à son quotidien : comprendre, sélectionner, structurer, écrire.
• Le cas expose la tension centrale des agents. Plus l'agent est utile, plus il devient nécessaire de borner ses permissions. Le risque n'est pas théorique : un mauvais brouillon peut contenir une erreur factuelle, une citation mal attribuée ou un angle injuste.
• Le workflow révèle la valeur du jugement humain. Si l'agent accélère la recherche et la première version, l'humain reste responsable de la pertinence, du ton, des omissions et de la décision finale.

⚠️ Points d'attention

• Ne pas confondre style et vérité. Un agent peut écrire un texte convaincant avant d'avoir compris le sujet. En média, c'est le piège numéro un.
• Séparer rédaction et publication. Donner au même agent accès à la recherche, à la rédaction et à la publication augmente inutilement le rayon d'erreur.
• Tracer les sources dès le départ. Si le sourcing est ajouté à la fin, il devient décoratif. Il doit guider la rédaction, pas la maquiller.
• Conserver les brouillons intermédiaires. Pour comprendre une erreur, il faut savoir à quel moment elle est entrée dans le workflow : recherche, synthèse, plan ou rédaction.

💡 Améliorations possibles

• Ajouter une étape "fact table" obligatoire avant rédaction : chaque affirmation importante devient une ligne avec source, date et niveau de confiance.
• Créer deux agents séparés : un rédacteur et un contradicteur. Le second ne réécrit pas, il cherche les failles.
• Définir une liste de sujets interdits à l'automatisation complète : accusations, santé, finance, sécurité, personnes privées.
• Mesurer le workflow sur plusieurs articles : temps de recherche, temps de correction, nombre d'erreurs détectées, taux de paragraphes réécrits.

🎓 Ce qu'on en retient

Leçons clés :

1. Un agent éditorial utile n'est pas un générateur de texte, c'est un système de travail avec mémoire, sources et garde-fous.
2. Le bon niveau d'autonomie dépend du coût de l'erreur. Pour un article public, le draft automatique est raisonnable ; la publication automatique l'est beaucoup moins.
3. La qualité du setup compte plus que le modèle utilisé. Sans consignes de sourcing, de limites et de review, même un très bon modèle peut produire un texte fragile.

Pour aller plus loin :

• Construire sa Mémoire Obsidian avec OpenClaw
• Industrialiser ses Workflows avec OpenClaw
• Source originale Fast Company

À dimanche prochain pour un nouveau cas ! 🦞