OpenClaw

Coordonner 10 Agents avec OpenClaw : Cas Réel DevOps

Avant : un agent saturé et des handoffs flous. Après : 10 rôles coordonnés dans Telegram. Comment raulvidis a structuré une équipe multi-agents avec OpenClaw.

La Pince

La Pince

— 6 min de lecture
Coordonner 10 Agents avec OpenClaw : Cas Réel DevOps

Bon dimanche ! ☕

Aujourd'hui, on plonge dans un cas qui ressemble beaucoup moins à une démo qu'à une vraie tentative d'organisation opérationnelle : une équipe de 10 agents OpenClaw, coordonnée depuis Telegram, avec des rôles séparés, des topics par workflow, des handoffs standardisés et des fichiers partagés pour garder le contexte.

Le point intéressant n'est pas seulement "on peut avoir plusieurs agents". Ça, c'est la partie facile. Le vrai sujet, c'est la discipline nécessaire pour éviter qu'une équipe d'agents devienne un salon de discussion bruyant, coûteux, et impossible à déboguer.

🎯 Le Cas : Une équipe multi-agents pilotée depuis Telegram

Auteur : raulvidis (source GitHub)
Contexte : un setup OpenClaw public, documenté comme issu d'une configuration de production avec 10 agents autonomes dans un supergroupe Telegram.
Objectif : transformer OpenClaw en équipe spécialisée : orchestration, code, QA, DevOps, recherche, croissance, contenu, communauté, lead gen et ops.

📖 L'Histoire

Le dépôt openclaw-multi-agent-kit part d'un constat assez simple : un agent généraliste finit vite par accumuler trop de responsabilités. Il peut coder, tester, faire de la veille, répondre sur Telegram, préparer du contenu, trier des leads. Mais plus le périmètre grossit, plus le prompt devient flou, plus les erreurs de contexte apparaissent, et plus les interruptions humaines deviennent nécessaires.

L'auteur propose donc une séparation par rôles. Pas une séparation décorative où chaque agent reçoit juste un prénom et une personnalité. Une séparation opérationnelle : chaque agent a son workspace, son SOUL.md, son IDENTITY.md, son bot Telegram, ses topics, ses règles d'escalade et ses responsabilités. Le dépôt fournit les templates pour les construire, mais aussi les conventions de routage qui évitent que tout le monde réponde partout.

La partie la plus utile est la décision d'organiser Telegram par "lanes" de workflow plutôt que par personne. Le guide déconseille explicitement le modèle "un topic par agent". À la place : General, Build, Research, Growth, Leads, Ops, éventuellement Incidents. C'est une bonne intuition produit : quand on travaille, on ne veut pas chercher "où est Connor ?", on veut voir "où en est le build ?".

La solution finale ressemble donc à une petite organisation technique : un orchestrateur reçoit les demandes générales, le topic Build regroupe code, QA et DevOps, le topic Research sépare l'intelligence marché, le topic Ops garde les tâches administratives. Les agents ne discutent pas librement entre bots Telegram, car Telegram ne permet pas aux bots de lire proprement les messages des autres bots. OpenClaw sert alors de colonne vertébrale via sessions_send.

🔧 Le Setup Technique

Architecture Agent

Le schéma conceptuel est le suivant :

Humain
  |
  v
Orchestrateur OpenClaw
  |
  +-- Build lane: coder -> QA -> DevOps
  |
  +-- Research lane: researcher -> growth
  |
  +-- Social lane: content -> community
  |
  +-- Leads lane: leadgen
  |
  +-- Ops lane: ops

Chaque agent possède :

  • un workspace dédié, par exemple ~/.openclaw/workspace/agents/coder/
  • un SOUL.md spécialisé
  • un IDENTITY.md
  • une entrée dans agents.list
  • une liaison Telegram via bindings
  • des règles de topic dans channels.telegram.accounts
  • un accès aux fichiers partagés : THESIS.md, SIGNALS.md, FEEDBACK-LOG.md, SUPERGROUP-MAP.md

Le dépôt insiste sur trois modèles de routage :

  • multi-bot routing : chaque agent a sa propre identité Telegram visible
  • native topic routing : un seul bot visible, mais plusieurs agents internes selon le topic
  • DM forum topics : topics dans un chat direct, utile pour organiser des conversations privées

Pour une vraie équipe spécialisée, le multi-bot routing reste le choix le plus lisible.

Fichiers Clés

SOUL.md

Le template du coding agent donne une bonne idée du niveau de cadrage attendu :

## How I Work

I operate in two modes, explicitly. I never blur them.

Plan mode — I'm gathering context and proposing an approach.
Execute mode — I implement against the approved plan with minimal diffs,
run the project's checks, and post DONE with evidence.

Ce n'est pas seulement un ton. C'est une procédure de travail : lire avant d'écrire, limiter le diff, déclencher QA, escalader après un nombre borné d'échecs.

Config / Scripts

Le setup minimal montre trois agents : orchestrator, coder et QA.

{
  "agents": {
    "list": [
      { "id": "orchestrator", "workspace": "/home/YOUR_USER/.openclaw/workspace/" },
      { "id": "coder", "workspace": "/home/YOUR_USER/.openclaw/workspace/agents/coder/" },
      { "id": "qa", "workspace": "/home/YOUR_USER/.openclaw/workspace/agents/qa/" }
    ]
  },
  "bindings": [
    { "agentId": "coder", "match": { "channel": "telegram", "accountId": "coder" } },
    { "agentId": "qa", "match": { "channel": "telegram", "accountId": "qa" } }
  ]
}

Point critique : un seul agent doit répondre automatiquement dans un topic. Les secondaires restent en requireMention: true.

Étapes de Mise en Place

  1. Installer et lancer OpenClaw, puis vérifier la version :
openclaw --version

  1. Créer les bots Telegram via BotFather, un par agent si l'on choisit le multi-bot routing.

  2. Créer un supergroupe Telegram, activer les topics, puis créer les lanes : General, Build, Research, Growth, Leads, Ops.

  3. Créer les workspaces agents :

mkdir -p ~/.openclaw/workspace/agents/{coder,qa,devops,researcher,growth,content,community,leadgen,ops}
mkdir -p ~/.openclaw/workspace/shared-context

  1. Copier les templates SOUL.md, IDENTITY.md et les fichiers partagés depuis le dépôt.

  2. Sauvegarder la configuration avant édition :

cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak

  1. Ajouter les agents, bindings, comptes Telegram et topics dans openclaw.json.

  2. Redémarrer et tester les invariants :

openclaw restart
  1. Tester chaque topic : un seul agent répond, les mentions déclenchent les bons spécialistes, les handoffs produisent ACK, DONE ou BLOCKED.

📊 Les Résultats

Gains mesurés :

  • 10 rôles d'agents documentés dans le kit complet.
  • 3 agents dans la configuration minimale reproductible : orchestrator, coder, QA.
  • 6 lanes Telegram recommandées pour structurer le travail : General, Build, Research, Growth, Leads, Ops.
  • 392 étoiles GitHub au moment de l'analyse, ce qui signale un intérêt communautaire non trivial.
  • Un contrat de handoff explicite avec ACK, DONE et BLOCKED, utile pour auditer les tâches au lieu de relire un fil confus.

Limites rencontrées :

  • Le dépôt ne publie pas de métrique de temps économisé. On ne peut donc pas affirmer un gain horaire sans extrapoler.
  • Telegram impose une contrainte forte : les bots ne lisent pas fiablement les messages des autres bots. sessions_send devient obligatoire pour les handoffs.
  • Le setup demande beaucoup de configuration initiale : bots, topics, IDs, workspaces, prompts, fichiers partagés.
  • Le dépôt mentionne un risque de corruption d'état de channel avec sessions_send ; les messages de cycle de vie doivent donc être postés explicitement.

🧐 Analyse Critique

✅ Ce qui est bien fait

  • La séparation par workflow lane est excellente. Elle évite de transformer Telegram en organigramme. Le topic Build contient le flux de livraison, pas juste "le bot du développeur".

  • Le handoff est traité comme un protocole. Le format HANDOFF, ACK, DONE, BLOCKED donne une grammaire commune. C'est exactement ce qui manque dans beaucoup de setups multi-agents : une tâche doit avoir un propriétaire, un délai, des critères de fin et une preuve.

  • Le modèle reste provider-agnostic. Les exemples ne pin pas un modèle par défaut. C'est sain : on commence avec le runtime OpenClaw existant, puis on spécialise uniquement les agents qui en ont besoin.

⚠️ Points d'attention

  • La complexité arrive vite. Dix agents, c'est déjà une petite organisation. Sans SUPERGROUP-MAP.md à jour, les topic IDs et bindings deviennent une source d'erreurs silencieuses.

  • Le coût peut grimper. Même si les templates sont model-agnostic, multiplier les agents multiplie les sessions, les relances et les boucles QA. Il faut suivre la latence, le taux de blocage et le taux de rework.

  • La sécurité dépend du périmètre des rôles. Un agent content n'a pas besoin des mêmes droits qu'un agent DevOps. Le kit rappelle de restreindre les permissions, mais la responsabilité finale reste côté opérateur.

💡 Améliorations possibles

  • Ajouter un tableau de bord minimal : nombre de handoffs, temps moyen jusqu'à ACK, taux de BLOCKED, nombre de cycles QA par tâche.
  • Fournir un script de validation openclaw.json qui détecte deux agents en requireMention: false sur le même topic.
  • Documenter un exemple chiffré de production : volume de tâches par semaine, coût mensuel, erreurs évitées, temps de réponse moyen.

🎓 Ce qu'on en retient

Leçons clés :

  1. Un système multi-agents ne se gagne pas avec plus de personas. Il se gagne avec des frontières de responsabilité claires.
  2. Telegram peut être une bonne interface d'opération, mais seulement si les topics représentent des workflows, pas des individus.
  3. sessions_send est puissant, mais doit être encadré par un contrat strict de handoff et des messages de cycle de vie explicites.
  4. Le setup minimal devrait rester minimal : orchestrateur, coder, QA. Les autres agents viennent seulement quand un vrai goulot apparaît.

Pour aller plus loin :

À dimanche prochain pour un nouveau cas ! 🦞

Lire la suite