OpenClaw

Automatiser son Backlog avec OpenClaw : Cas Réel DevOps

Avant : backlog vivant mais tri manuel. Autensa transforme recherche, swipe et PR en boucle OpenClaw supervisée. Setup complet + limites de production.

La Pince

26 juil. 2026 — 5 min de lecture

Bon dimanche ! ☕

Aujourd'hui, on plonge dans un cas qui pousse OpenClaw dans une direction ambitieuse : ne plus seulement confier une tâche à un agent, mais brancher une boucle produit complète sur un dépôt réel. Le projet s'appelle Autensa, il est public, et il documente une idée simple à formuler mais difficile à rendre fiable : un produit qui recherche ses propres opportunités, propose des idées, les fait valider, puis déclenche des agents jusqu'à la pull request.

🎯 Le Cas : un moteur produit autonome

Auteur : crshdn (source GitHub)
Contexte : développeur qui construit une interface self-hosted autour d'OpenClaw Gateway pour piloter des agents produit, code, test et review.
Objectif : automatiser la boucle recherche marché -> idéation -> validation humaine -> build -> test -> review -> pull request.

📖 L'Histoire

La situation initiale est très familière pour une équipe produit ou un maker : le backlog ne manque jamais d'idées, mais il manque de tri, de contexte et de continuité. On repère un concurrent, une faiblesse SEO, un bug UX ou une opportunité technique, puis l'information se perd dans un ticket, une note ou une conversation. Quelques jours plus tard, il faut reconstituer le pourquoi avant même de commencer le comment.

Autensa part de ce problème et le transforme en système. Le README présente le projet comme un "Autonomous Product Engine" : une application Next.js reliée à OpenClaw Gateway, avec SQLite pour l'état local, des workspaces isolés pour les tâches et une interface pour superviser les agents. Ce n'est pas un simple dashboard de tâches. Le coeur du cas, c'est la boucle Autopilot : les agents analysent le produit, génèrent des idées scorées, l'utilisateur les valide par swipe, puis les idées acceptées deviennent des tâches qui passent par build, test, review et PR.

Le parcours documenté montre aussi une évolution intéressante. Le projet n'est pas resté au stade "agent qui code une feature". Les versions récentes ont ajouté la préparation des dépôts privés, la récupération des checks GitHub, les sessions OpenClaw séparées par tâche, la correction du routage modèle via openclaw/default, et la préservation des rôles lors de la synchronisation Gateway. Autrement dit, les problèmes rencontrés sont exactement ceux d'une automatisation réelle : contexte qui fuit entre tâches, permissions GitHub insuffisantes, branches par défaut qui ne s'appellent pas toujours main, agents qui se bloquent, checks CI qui échouent.

La solution finale est donc moins spectaculaire qu'elle n'en a l'air, et c'est une bonne nouvelle. Elle ne prétend pas supprimer l'humain partout. Elle garde un point de décision explicite : le swipe. Ce choix rend le système plus crédible. OpenClaw orchestre les étapes longues et répétitives, mais l'utilisateur reste responsable du goût produit, du niveau d'automatisation et de la validation des changements.

🔧 Le Setup Technique

Architecture Agent

Produit réel + repo GitHub
        |
        v
Autensa (Next.js, port 4000)
        |
        +--> SQLite : produits, recherches, idées, coûts, checkpoints
        +--> Workspaces : git worktrees, branches, sandboxes, ports 4200-4299
        |
        v
OpenClaw Gateway (ws://127.0.0.1:18789)
        |
        +--> Research agent : marché, concurrents, SEO, gaps techniques
        +--> Ideation agent : idées scorées impact/faisabilité
        +--> Builder agent : implémentation
        +--> Tester agent : suite de tests et corrections
        +--> Reviewer agent : diff, qualité, sécurité
        +--> Learner agent : leçons réutilisables
        |
        v
GitHub PR + checks + récupération si échec

Le projet documente aussi un "Convoy Mode" pour les grosses features : une tâche parente est découpée en sous-tâches, exécutées par 3 à 5 agents en parallèle avec un graphe de dépendances. Les agents ont des checkpoints, une détection de santé et un mécanisme de relance quand une session devient silencieuse.

Fichiers Clés

README.md

Research -> Ideation -> Swipe -> Build -> Test -> Review -> Pull Request

Le README sert de guide principal : quick start, Docker, configuration, architecture, variables d'environnement, base SQLite, isolation workspace et dépannage.

.env.local

OPENCLAW_GATEWAY_URL=ws://127.0.0.1:18789
OPENCLAW_GATEWAY_TOKEN=your-token-here
MC_API_TOKEN=your-64-char-hex-token
WEBHOOK_SECRET=your-64-char-hex-token
DATABASE_PATH=./mission-control.db
WORKSPACE_BASE_PATH=~/Documents/Shared
PROJECTS_PATH=~/Documents/Shared/projects

Commandes essentielles

git clone https://github.com/crshdn/mission-control.git
cd mission-control
npm install
cp .env.example .env.local
openclaw gateway start
npm run dev

Pour Docker :

cp .env.example .env
docker compose up -d --build
docker compose logs -f mission-control

Étapes de Mise en Place

Installer Node.js 18+ et OpenClaw : npm install -g openclaw.
Lancer le gateway OpenClaw dans un terminal séparé : openclaw gateway start.
Récupérer le token dans ~/.openclaw/openclaw.json, champ gateway.token.
Cloner Autensa, installer les dépendances et copier .env.example vers .env.local.
Renseigner OPENCLAW_GATEWAY_URL et OPENCLAW_GATEWAY_TOKEN.
Démarrer l'interface : npm run dev, puis ouvrir http://localhost:4000.
Ajouter un produit : dépôt GitHub, URL live, branche par défaut, niveau d'automatisation.
Lancer une recherche ou configurer une cadence quotidienne/hebdomadaire.
Valider les idées via swipe : Pass, Maybe, Yes ou Now.
Laisser le pipeline créer la tâche, isoler le workspace, coder, tester, reviewer et ouvrir une PR.

📊 Les Résultats

Gains mesurés :

2 113 stars GitHub au moment de la veille, signe d'un intérêt fort pour le pattern.
80+ endpoints API annoncés pour couvrir tâches, produits, agents, coûts, webhooks et Gateway.
21 migrations SQLite documentées, ce qui montre un modèle de données déjà conséquent.
Pipeline complet documenté : recherche, idéation, swipe, planification, build, test, review, PR.
Mode parallèle prévu pour 3 à 5 agents sur les grosses features.

Limites rencontrées :

Les gains de temps exacts ne sont pas chiffrés par l'auteur ; il faut donc éviter de vendre un "X heures économisées" non sourcé.
Le setup dépend de GitHub, d'OpenClaw Gateway, d'un provider IA et d'une gestion correcte des secrets.
Les dépôts privés demandent une vraie préparation : accès git authentifié, branche par défaut, permissions Actions, secrets et variables de workflow.
L'automatisation complète reste risquée sur un produit en production si les tests et la review humaine ne sont pas solides.

🧐 Analyse Critique

✅ Ce qui est bien fait

Le système garde une validation humaine au bon endroit. Le swipe n'est pas décoratif : il sert à entraîner les préférences et à empêcher le backlog d'être rempli automatiquement par des idées faibles.
L'isolation workspace est prise au sérieux. Les git worktrees, ports dédiés et files de merge réduisent les conflits entre agents concurrents, un problème classique dès qu'on lance plusieurs sessions de code en parallèle.
Le projet documente ses cicatrices. Les notes de versions parlent de sessions par tâche, de récupération de PR checks, de permissions GitHub et de routage modèle. Ce sont des détails de production, pas des promesses marketing.
La boucle Learner est pertinente : capturer les leçons des tâches finies puis les réinjecter dans les futures instructions évite de répéter les mêmes erreurs d'architecture ou de style.

⚠️ Points d'attention

Le mot "autonomous" peut donner une impression trompeuse. Pour un produit critique, le mode conseillé reste supervisé : PR créée automatiquement, merge manuel.
Les secrets doivent être traités avec beaucoup de rigueur. Autensa annonce ne pas stocker les valeurs de secrets GitHub ajoutées depuis l'UI, mais le déploiement local doit aussi protéger .env.local, SQLite et les logs.
Le coût peut monter vite. Recherche marché, idéation, planification, build, test et review appellent tous des modèles. Les caps journaliers et mensuels ne sont pas optionnels.
La qualité dépend du Product Program. Si le document de cadrage est vague, les idées générées seront probablement séduisantes mais mal alignées.

💡 Améliorations possibles

Ajouter un exemple complet de Product Program pour un SaaS réel, avec critères d'acceptation et signaux à ignorer.
Publier un benchmark de coût par cycle : recherche seule, idéation, build simple, build convoy.
Documenter un mode "dry run" qui simule les PR sans pousser de branche, utile pour tester le système sur un dépôt sensible.

🎓 Ce qu'on en retient

Leçons clés :

Une automatisation produit crédible commence par la sélection, pas par le code. Le swipe d'Autensa est une interface simple pour préserver le jugement humain.
Les agents multi-tâches ont besoin d'isolation forte : session séparée, workspace séparé, port séparé, checkpoint séparé.
OpenClaw devient beaucoup plus puissant quand le contexte métier est persistant : Product Program, historique de swipe, knowledge base, coûts et résultats de PR.

Pour aller plus loin :

À dimanche prochain pour un nouveau cas ! 🦞