OpenClaw

Piloter n8n avec OpenClaw : Cas Réel Research

Avant : un agent qui raisonne, mais peu d’exécution fiable. Après : OpenClaw pilote n8n par webhooks. Le setup de Gaurav, complet, dockerisé, avec analyse critique.

La Pince

La Pince

— 5 min de lecture
Piloter n8n avec OpenClaw : Cas Réel Research

Bon dimanche ! ☕

Aujourd'hui, on regarde un cas réel qui parle à tous ceux qui aiment OpenClaw mais qui se heurtent à une limite très concrète : l'agent raisonne bien, mais il ne devrait pas porter seul toute la mécanique d'un workflow.

Le dépôt publié par Gaurav Caprihan propose une réponse simple : mettre OpenClaw dans le rôle d'interface agentique, et déléguer l'exécution répétable à n8n. Ce n'est pas le cas le plus spectaculaire de la série, mais c'est précisément ce qui le rend intéressant : il montre comment transformer un agent en système opérable, dockerisé, sauvegardable et extensible.

🎯 Le Cas : OpenClaw comme Interface d'Automatisation

Auteur : Gaurav Caprihan / caprihan (source GitHub)
Contexte : un stack public MIT, créé le 5 février 2026, qui combine OpenClaw et n8n dans Docker Compose. Le dépôt compte 134 étoiles au moment de l'analyse.
Objectif : fournir un "personal AI operating system in a box" où OpenClaw pilote des workflows n8n par webhooks, avec des validations multi-modèles en exemple.

📖 L'Histoire

Le problème de départ est classique dans les workflows agentiques : un agent IA sait comprendre une demande, arbitrer, reformuler, synthétiser. En revanche, dès qu'on lui demande de déclencher des actions répétables dans Gmail, Slack, une API métier ou un pipeline de validation, on se retrouve vite à bricoler des scripts, des tokens, des webhooks et des conventions fragiles.

Le choix de Gaurav Caprihan consiste à ne pas forcer OpenClaw à devenir lui-même un orchestrateur visuel de workflows. OpenClaw reste l'interface naturelle : on parle à l'agent, on lui donne du contexte, il décide quelle action appeler. n8n devient la couche d'automatisation : webhooks, credentials, noeuds HTTP, intégrations externes, logs d'exécution.

Le dépôt met cette idée dans un format très reproductible : un docker-compose.yml, un .env.template, un fichier d'exemple de configuration OpenClaw, et deux workflows n8n prêts à importer. Le README promet aussi des cas comme triage email et social monitoring ; dans l'état public du dépôt, les fichiers réellement présents sont surtout centrés sur RIPR, une validation factuelle multi-LLM avec ChatGPT et Gemini. C'est une limite, mais aussi un bon signal : on peut lire le système réel au lieu de se contenter d'une liste marketing.

Le cas d'usage le plus solide est donc celui-ci : un agent OpenClaw prépare ou reçoit une liste de claims à vérifier, puis appelle n8n. n8n envoie ces claims vers un validateur ChatGPT ou Gemini, force une réponse JSON, parse le résultat, puis renvoie à OpenClaw un verdict structuré : statuts de validation, scores d'exactitude, fraîcheur, complétude, pertinence, clarté, et recommandations.

🔧 Le Setup Technique

Architecture Agent

Utilisateur
  ↓ langage naturel
OpenClaw gateway : raisonnement, contexte, décision d'appel
  ↓ POST http://n8n:5678/webhook/ripr-gpt ou /ripr-gemini
n8n : webhook, credentials, appel modèle, parsing JSON
  ↓ réponse structurée
OpenClaw : synthèse, arbitrage, prochaine action

La décision d'architecture importante est le réseau Docker partagé ai-stack. OpenClaw et n8n n'ont pas besoin de se parler via une URL publique : dans le compose, OpenClaw reçoit N8N_WEBHOOK_BASE=http://n8n:5678/webhook, donc les appels restent internes au réseau Docker.

Fichiers Clés

config/openclaw.example.json

{
  "gateway": {
    "port": 3456,
    "host": "0.0.0.0"
  },
  "models": {
    "default": "anthropic/claude-sonnet-4-20250514",
    "thinking": "low"
  },
  "skills": {
    "enabled": true,
    "paths": ["./skills"]
  },
  "n8n": {
    "webhookBase": "http://n8n:5678/webhook",
    "enabled": true
  }
}

docker-compose.yml

openclaw:
  image: node:22-slim
  volumes:
    - openclaw-data:/app/.openclaw
    - ./workspace:/app/workspace
    - ./config/openclaw.json:/app/openclaw.json:ro
  environment:
    - ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}
    - OPENAI_API_KEY=${OPENAI_API_KEY:-}
    - GEMINI_API_KEY=${GEMINI_API_KEY:-}
    - N8N_WEBHOOK_BASE=http://n8n:5678/webhook
  command: >
    sh -c "npm install -g openclaw &&
           openclaw gateway start --port 3456"

n8n:
  image: n8nio/n8n:latest
  volumes:
    - n8n-data:/home/node/.n8n
    - ./workflows:/home/node/workflows

Workflow RIPR

Les deux workflows n8n suivent la même structure :

Webhook
  → ChatGPT Validator ou Gemini Validator
  → Parse Response
  → Respond to Webhook

Le validateur ChatGPT utilise https://api.openai.com/v1/chat/completions, gpt-4o, une température de 0.3, et response_format: { "type": "json_object" }. Le validateur Gemini appelle gemini-2.0-flash:generateContent avec responseMimeType: application/json.

Étapes de Mise en Place

  1. Cloner le dépôt :
git clone https://github.com/caprihan/openclaw-n8n-stack.git
cd openclaw-n8n-stack
  1. Préparer l'environnement :
cp .env.template .env
nano .env

  1. Renseigner au minimum ANTHROPIC_API_KEY, puis OPENAI_API_KEY ou GEMINI_API_KEY si l'on veut utiliser les validateurs RIPR.

  2. Démarrer le stack :

docker-compose up -d

  1. Ouvrir n8n sur http://localhost:5678, importer workflows/ripr-gpt-workflow.json ou workflows/ripr-gemini-workflow.json, puis configurer les credentials.

  2. Depuis OpenClaw, appeler un workflow :

curl -X POST "http://n8n:5678/webhook/ripr-gpt" \
  -H "Content-Type: application/json" \
  -d '{"claims":[{"claim_id":"C1","text":"...","source":"..."}]}'

📊 Les Résultats

Gains mesurés :

  • 1 commande Docker Compose pour lancer OpenClaw + n8n, au lieu d'une installation manuelle en deux environnements séparés.
  • 2 validateurs multi-LLM fournis dans le dépôt public : ChatGPT et Gemini.
  • 400+ intégrations n8n potentiellement accessibles derrière une interface OpenClaw, selon les credentials configurés.

Limites rencontrées :

  • Le README mentionne email-triage.json et social-monitor.json, mais le dépôt public expose surtout les deux workflows RIPR.
  • Le conteneur OpenClaw installe le paquet global au démarrage, ce qui simplifie l'essai mais rend le boot dépendant du réseau et de l'état du registre npm.
  • Le mot de passe n8n par défaut est changeme, volontairement visible dans le template : pratique pour un quickstart, dangereux si quelqu'un expose le port trop vite.

🧐 Analyse Critique

✅ Ce qui est bien fait

  • La séparation des rôles est saine. OpenClaw gère le raisonnement et l'interaction, n8n gère l'exécution répétable. C'est beaucoup plus maintenable qu'un agent qui accumule des scripts ad hoc.
  • Le webhook interne Docker est le bon niveau d'abstraction. L'agent appelle http://n8n:5678/webhook/..., pas une URL publique fragile. Pour un usage local ou homelab, c'est propre.
  • Les workflows RIPR imposent une sortie structurée. Le JSON avec claim_validations, scores, weighted_score, feedback et verdict transforme une validation LLM en artefact exploitable par un autre agent ou par un humain.

⚠️ Points d'attention

  • La sécurité doit être traitée avant toute exposition Internet. Le README le dit clairement : mot de passe fort, reverse proxy HTTPS, pas de ports ouverts directement, .env jamais commit.
  • n8n devient une surface critique. Celui qui contrôle les credentials n8n peut appeler Gmail, Slack, CRM ou APIs internes. OpenClaw ne doit pas envoyer des payloads libres vers des workflows destructifs sans garde-fous.
  • La validation multi-LLM n'est pas une preuve absolue. Deux modèles qui confirment une erreur restent deux modèles qui confirment une erreur. Le workflow est utile pour prioriser la review, pas pour remplacer les sources.

💡 Améliorations possibles

  • Épingler les versions Docker et le paquet OpenClaw au lieu de dépendre de latest et d'une installation globale à chaque démarrage.
  • Ajouter un exemple de skill OpenClaw qui encapsule les appels RIPR, avec schéma d'entrée, seuil de score, et comportement en cas de CONTRADICTED ou UNVERIFIED.
  • Fournir les workflows annoncés de triage email et social monitoring, ou corriger le README pour éviter l'écart entre promesse et fichiers disponibles.

🎓 Ce qu'on en retient

Leçons clés :

  1. Un bon agent n'a pas besoin de tout faire lui-même : il doit savoir déléguer à des systèmes observables.
  2. Docker Compose est souvent le meilleur premier niveau de produit pour un workflow agentique local : volumes, réseau, secrets, backups.
  3. Les sorties structurées sont le vrai multiplicateur : un verdict JSON peut déclencher une review, bloquer une publication ou enrichir une mémoire projet.

Pour aller plus loin :

À dimanche prochain pour un nouveau cas ! 🦞

Lire la suite