OpenClaw : guide complet du routage multi-agents pour isoler travail, vie et expérimentation

Lundi 9 h, j’ouvre mon assistant IA pour aider un client sur une API de paiement. Il répond soudain : « D’après votre stratégie « roll-and-dodge » sur le boss d’Elden Ring hier soir, je suggère la même approche ici… »

Je suis resté figé.

Pire : c’était pendant une réunion partagée avec le client. Le silence à l’autre bout de la visio était palpable.

Ce jour-là, j’ai compris : l’assistant devient plus intelligent, mais il mélange travail, loisirs et expérimentation. Comme un tiroir sans séparateurs — tout empilé, difficile de retrouver quoi que ce soit, et on prend souvent le mauvais objet.

Si vous ressentez la même chose, cet article est pour vous. Un week-end à étudier le routage multi-agents d’OpenClaw m’a montré comment « cloner » l’assistant en plusieurs profils : le travail au travail, la vie à la vie, l’expérimentation en bac à sable.

Voici pourquoi c’est utile, comment configurer, et 5 scénarios que j’utilise vraiment.

Guide économique « élever un homard » : ArkClaw démocratise l’agent IA

OpenClaw (homard) est puissant mais la config rebute ? ArkClaw de ByteDance Volcano Engine abaisse la barrière : pas de serveur ni de token à bricoler, un assistant 24h/24 qui contrôle le navigateur, exécute des scripts et gère l’agenda.

Le prix compte : 9,9 ¥/mois, code d’invitation ZLKUK54M (inscription) → 8,9 ¥. Développeurs : Coding Plan Pro peut offrir l’accès.

Pourquoi l’assistant IA « mélange les contextes » ?

Trois moments gênants avec un seul assistant

J’utilisais un seul assistant pour tout, jusqu’à ces situations :

Scénario 1 : pollution de contexte
Vous demandez d’optimiser une requête SQL en entreprise ; l’IA cite soudain : « Comme pour le script Python de la semaine dernière… » — sauf que ce crawler était un projet perso que vous ne vouliez pas exposer.

Scénario 2 : fuite de confidentialité
En démo d’équipe, vous ouvrez l’historique pour montrer une fonctionnalité — et la liste affiche « comment négocier une augmentation », « déclarer un revenu secondaire »… On connaît la gêne.

Scénario 3 : l’expérimentation casse la prod
Un test de renommage en masse : l’IA se souvient d’un ancien répertoire projet client et renomme toute la base source. Heureusement, Git était là.

Pourquoi ça arrive ?

L’assistant n’est pas en tort : il retient tout et relie les contextes. Mais :

• le travail exige rigueur et confidentialité ;
• la vie personnelle, des conseils détendus ;
• l’expérimentation, de la liberté sans toucher à la prod.

Ces trois mondes ne devraient pas cohabiter.

L’approche du routage multi-agents

Le routage multi-agents OpenClaw, c’est une « pièce » par scénario :

• Espace de travail isolé : work-agent ne voit que /work, personal-agent que /personal — isolation au niveau fichiers
• Historique séparé : ce qui est dit à work-agent est inconnu de personal-agent
• Permissions distinctes : bac à sable hors ligne et FS lecture seule ; travail avec Git entreprise ; vie avec cloud perso

En jargon Docker : isolation au niveau conteneur. En clair : plusieurs « cerveaux » indépendants.

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

En 2026, les normes de sécurité IA exigent une isolation stricte des données par tenant. Le bac à sable Docker d’OpenClaw dépasse les outils qui se contentent de « groupes de conversation ».

Architecture d’isolation à trois niveaux

Gateway, Brain, Skills — au début, j’étais perdu. Après une config complète, c’est clair.

Trois couches, comme un système de livraison

• Gateway (hub) : reçoit Telegram, Discord, Slack… puis route vers le bon agent selon la config
• Brain (dispatch) : interprète l’intention — coder, chercher, exécuter — et orchestre le flux
• Skills (exécution) : travail concret dans un conteneur Docker dédié par agent

Trois niveaux d’isolation

Isolation session (tâches temporaires)
Nouveau conteneur par conversation, détruit à la fin. Idéal pour « analyser ce CSV ». Propre, mais environnement à recréer.

Isolation agent (scénarios long terme)
Un conteneur persistant par agent. Mes work-agent et personal-agent fonctionnent ainsi — mon mode préféré.

Isolation utilisateur OS (paranoïa saine)
Agents sous utilisateurs système différents. Je n’en ai pas eu besoin ; utile pour finance ou santé.

Test personnel : avec l’isolation agent, un fichier créé dans agent-A est inaccessible à agent-B, sauf volume partagé explicite. Rassurant.

5 scénarios que j’utilise

Configurations réelles, réutilisables telles quelles.

Scénario 1 : travail vs personnel

Problème : code entreprise et blog perso mélangés — j’ai failli pousser du code client sur mon GitHub perso.

Solution :

• work-agent : D:\work, clé SSH GitLab entreprise, clés API pro uniquement
• personal-agent : D:\personal, compte GitHub perso

Points clés :
Deux fichiers .env, WORKSPACE_PATH distincts. Deux bots Telegram : @my_work_bot et @my_personal_bot.

Scénario 2 : isolation multi-clients

Problème : freelance, trois clients — conseils pour le client A avec conventions de nommage du client B.

Solution :
Trois agents : client-nike-agent, client-adidas-agent, client-puma-agent (noms fictifs).

Points clés :

• Répertoire et dépôt Git par client
• PROJECT_NAME distinct dans chaque .env
• Clés API et BDD strictement séparées

Scénario 3 : bac à sable sécurisé

Problème : tester un script de fichiers sans risquer de tout effacer.

Solution :
sandbox-agent en mode strict.

Points clés :

ENABLE_NETWORK=false  # hors ligne
HOST_FILESYSTEM_MODE=readonly  # FS hôte en lecture seule
TEMP_STORAGE=true  # modifications temporaires, effacées au redémarrage

Toute opération risquée passe d’abord par ici.

Scénario 4 : équipe et espace privé

Problème : assistant partagé en équipe — notes et todos persos visibles par tous.

Solution :

• team-agent : dépôt et docs d’équipe
• private-agent : idées, brouillons, todos perso

Points clés :
team-agent sur NAS partagé ; private-agent sur partition chiffrée locale. team-agent dans le groupe Telegram ; private-agent en DM solo.

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

Scénario 5 : comparaison multi-modèles

Problème : comparer Claude, GPT-4 et Llama local — bascule de config fastidieuse.

Solution :
Trois agents : claude-agent, gpt-agent, llama-agent.

Points clés :
LLM_PROVIDER et API_KEY différents par .env. Même question aux trois, comparaison qualité/vitesse/coût.

Constat : Claude le plus fiable pour le code ; GPT-4 plus naturel en conversation ; Llama local lent mais discret pour données sensibles.

Astuces :

• Nommage : scénario-usage-date, ex. client-nike-backend-20260201
• Bascule : plusieurs comptes Telegram, un agent par compte
• Ressources : docker stop sur llama-agent quand inutilisé

Configurer votre première paire d’agents

Prérequis : Docker et OpenClaw installés (sinon, voir le guide de démarrage officiel).

Objectif : work et personal

Étape 1 : fichiers de config

cd openclaw
cp .env .env.work
cp .env .env.personal

Étape 2 : work-agent
Dans .env.work :

AGENT_NAME=work-agent
WORKSPACE_PATH=/path/to/your/work/directory
TELEGRAM_BOT_TOKEN=your_work_bot_token
ALLOWED_USERS=your_telegram_user_id

Étape 3 : personal-agent
Dans .env.personal :

AGENT_NAME=personal-agent
WORKSPACE_PATH=/path/to/your/personal/directory
TELEGRAM_BOT_TOKEN=your_personal_bot_token
CONTAINER_PORT=8001  # port différent

Étape 4 : démarrage

docker-compose --env-file .env.work up -d
docker-compose --env-file .env.personal up -d

Attendre Status: Running.

3 tests d’isolation

Test 1 : fichiers

• work-agent : « Crée test.txt avec ‘work data’ »
• personal-agent : « Liste les fichiers du répertoire »
• Résultat : pas de test.txt côté personal

Test 2 : conversation

• work-agent : « Retiens que mon code projet est ProjectX »
• personal-agent : « Quel est mon code projet ? »
• Résultat : « Je ne sais pas »

Test 3 : fonctionnalités

• .env.work : ENABLE_CODE_EXECUTION=true
• .env.personal : ENABLE_CODE_EXECUTION=false
• Résultat : exécution autorisée seulement sur work

Dépannage :

• Port occupé : CONTAINER_PORT unique par agent
• Bot muet : token et ALLOWED_USERS
• Permissions : droits sur WORKSPACE_PATH pour Docker

Astuces avancées et pièges

Performance : ne pas saturer la machine

Cinq agents au départ → ventilateur à fond, 8 Go de RAM. Optimisations :

Limites de ressources

deploy:
  resources:
    limits:
      cpus: '0.5'
      memory: 512M

Démarrage à la demande

# start-sandbox.sh
docker start sandbox-agent-container
# après usage
docker stop sandbox-agent-container

Image de base partagée
Une image OpenClaw, configs différentes — ~1–2 Go pour cinq agents, pas cinq copies complètes.

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

Sécurité : la commodité ne doit pas l’emporter

Moindre privilège
Ne monter que les chemins nécessaires. personal-agent n’a pas besoin de /work.

Données sensibles
Clés API en variables d’environnement, jamais en dur. Vérifier que .env n’est pas dans Git.

Audit régulier

docker logs work-agent-container --since 7d | grep ERROR

Dépannage courant

Agent ne démarre pas

• docker logs <container_name>
• Souvent port ou permissions Docker

Échec de routage

• Token Telegram, ALLOWED_USERS, test curl du bot

Permissions fichiers

• UID/GID hôte vs conteneur : user: "${UID}:${GID}" dans docker-compose.yml

La plupart des problèmes se lisent dans les logs.

Synthèse et prochaines étapes

Pourquoi : un seul assistant mélange contextes → fuites et perte d’efficacité. Le routage multi-agents isole physiquement.

Comment : plusieurs agents via .env distincts, répertoires, entrées messagerie et permissions. Cinq minutes pour work/personal.

Bonnes pratiques : moindre privilège, arrêt à la demande, audit régulier.

Usage quotidien : travail plus focalisé, expérimentation sans crainte, démos sans mauvaise surprise.

Actions :

1. Configurer work/personal aujourd’hui — ce n’est pas difficile
2. Questions : GitHub Issues ou Discord OpenClaw
3. Partager avec ceux qui subissent aussi le « mélange de contextes »

L’IA doit simplifier la vie, pas la brouiller. Le routage multi-agents, c’est le rangement : chaque assistant à sa place, workflow plus clair.

Essayez — vous vous remercierez.