OpenClaw : guide complet de l’assistant IA
Comprendre OpenClaw : Gateway self-hosted, canaux, agents, workspace, mémoire, skills, automatisations et sécurité.
Introduction
OpenClaw est un assistant IA self-hosted conçu pour rester disponible depuis un terminal, une interface web ou des canaux de messagerie. Il est utile aux développeurs et utilisateurs avancés qui veulent contrôler leur Gateway, leurs données, leurs skills et leurs automatisations. Ce n’est pas un framework Python de workflows multi-agents : son produit central est un service Node/TypeScript qui route des conversations vers des agents dotés de workspaces. Si votre besoin tient dans un script déterministe ou un simple appel LLM, une approche plus simple sera préférable. Ce guide donne le bon modèle mental, les commandes actuelles et les limites à connaître.
Résumé rapide
- OpenClaw est un Gateway self-hosted pour assistants IA, pas une bibliothèque Python.
- Un agent réunit workspace, instructions, mémoire, sessions, modèle et skills.
- Les canaux et bindings acheminent les messages vers le bon agent.
- Les automations, plugins et nodes étendent le service au-delà du chat.
- La sécurité repose sur le contrôle des expéditeurs, des tools et de l’hôte.
Comprendre OpenClaw aujourd’hui
OpenClaw est un assistant agentique self-hosted distribué comme application Node/TypeScript. Son centre de gravité est le Gateway : un processus durable qui relie le runtime d'agent aux interfaces de contrôle, aux canaux de messagerie et, si besoin, à des nodes mobiles ou headless. La CLI et la Control UI pilotent ce même système. Cette architecture diffère d'un framework Python intégré dans une application : on configure et exploite un service, on ne construit pas un pipeline en important une classe Agent.
Chaque agent possède un workspace. On y trouve ses instructions, son identité, ses fichiers de mémoire et ses skills. Les skills sont des dossiers documentaires contenant un SKILL.md ; ils apprennent à l'agent quand et comment employer des tools déjà disponibles. Une capacité runtime nouvelle relève plutôt d'un plugin, qui peut ajouter tools, providers, canaux ou hooks. Cette distinction évite de transformer un simple mode opératoire Markdown en faux SDK.
Le mode mono-agent suffit par défaut. Le multi-agent ajoute des workspaces, états et sessions séparés, puis des bindings déterministes pour router les messages. Il ne s'agit pas d'une équipe CrewAI qui se distribue spontanément des rôles : ce sont des assistants isolés servis par un Gateway commun. Les automations planifient des tours ou des événements à l'intérieur de ce Gateway.
Le choix d’OpenClaw est pertinent lorsque la continuité de session, l’accès depuis plusieurs surfaces et l’exploitation locale comptent davantage qu’un graphe de workflow codé. Pour comparer cette topologie aux frameworks applicatifs, le comparatif des frameworks d’agents IA donne un cadre plus large, tandis que le guide LangGraph présente l’approche par graphe d’état.
Architecture, usages et limites
Le Gateway comme centre opérationnel
Le Gateway conserve les connexions aux canaux, les sessions et le routage. Il écoute localement par défaut et expose la Control UI sur le port 18789. La CLI permet de vérifier le service avec openclaw gateway status, d’ouvrir le tableau de bord avec openclaw dashboard et de diagnostiquer une installation avec openclaw triage ou openclaw doctor. Cette centralisation rend l’assistant cohérent entre terminal, WebChat, Telegram ou Slack.
Workspace, mémoire et contexte
Le workspace par défaut est ~/.openclaw/workspace. AGENTS.md et SOUL.md cadrent le comportement ; USER.md, MEMORY.md et le dossier memory/ organisent les préférences et souvenirs explicites. OpenClaw n’annonce pas une mémoire cachée : ce qui doit durer est écrit sur disque, puis peut être indexé et recherché. Cette transparence simplifie la revue, la sauvegarde et la correction des informations obsolètes.
Skills, tools et plugins
Un skill est un mode opératoire Markdown. Il explique comment employer un tool, un binaire ou un service et peut embarquer scripts, références ou modèles. Les tools exécutent réellement les actions. Les plugins ajoutent des capacités runtime et peuvent fournir leurs propres skills. Avant d’installer un élément communautaire, inspectez sa provenance et ses prérequis. Le guide des skills OpenClaw détaille cette frontière.
Canaux, nodes et multi-agent
Les canaux donnent accès à l’assistant depuis les applications de messagerie. Les nodes étendent certaines actions à un appareil appairé. Un Gateway peut également servir plusieurs agents isolés ; openclaw agents add work crée un agent et openclaw agents list --bindings affiche le routage. Chaque agent doit garder son propre répertoire d’état. Les bindings ne sont pas une orchestration de tâches : ils choisissent le destinataire d’un message entrant.
Automatisations
Le scheduler intégré persiste les jobs et leurs historiques. Les commandes openclaw automations list et openclaw automations runs <job-id> servent à contrôler l’exécution. Un job n’est utile que si le Gateway reste actif. Pour un workflow strictement déterministe, conservez les transformations critiques dans un script ou un service dédié et utilisez l’agent seulement pour les étapes qui exigent jugement ou langage naturel.
Quand choisir OpenClaw
Choisissez-le pour un assistant personnel ou d’équipe accessible depuis plusieurs surfaces, avec mémoire explicite, outils et tâches récurrentes. Évitez-le pour embarquer un graphe d’état dans une API métier, pour isoler des clients hostiles sur un même Gateway ou pour remplacer une fonction simple. Le duel OpenClaw vs LangGraph aide à trancher entre assistant persistant et orchestration applicative.
Repère opérationnel supplémentaire
Le Gateway doit rester le point de référence opérationnel. Il porte les sessions, les connexions aux canaux et le routage ; un redémarrage ou une panne affecte donc toutes les surfaces qui en dépendent. En production, supervisez le processus, conservez une procédure de redémarrage, puis vérifiez son état avec openclaw gateway status. Les automations exigent elles aussi un Gateway actif au moment prévu. Cette topologie est plus simple à exploiter qu'une collection de scripts dispersés, mais elle impose de traiter le Gateway comme un service durable et non comme une commande ponctuelle.
Repère opérationnel supplémentaire
Le workspace facilite l'organisation, mais ce n'est pas une frontière de sécurité. Il fournit le répertoire de travail, les instructions, les skills et les fichiers de mémoire ; sans sandbox, un outil autorisé peut encore atteindre d'autres chemins de l'hôte. Pour un assistant exposé à plusieurs personnes, limitez les outils, activez l'isolation adaptée et séparez les Gateway lorsque les utilisateurs ne partagent pas le même niveau de confiance. Une allowlist de skills réduit ce que le modèle voit, mais ne remplace jamais une politique d'exécution shell.
Repère opérationnel supplémentaire
La validation doit porter sur un effet observable. Après une modification, lancez une demande courte, vérifiez le fichier ou le message produit, puis consultez les logs et l'historique de session en cas d'écart. Évitez de conclure qu'une opération a réussi uniquement parce que la CLI n'a pas retourné d'erreur. Pour les actions avec effets de bord, ajoutez une étape de lecture après écriture, un identifiant d'exécution et une règle d'idempotence. Cela réduit les doublons lors d'un retry ou d'une reprise après interruption.
Repère opérationnel supplémentaire
Les coûts et la latence dépendent davantage du modèle, du volume de contexte et du nombre d'appels d'outils que du nombre de fichiers de configuration. Commencez avec une mission étroite, un petit jeu de skills et une session clairement délimitée. Mesurez ensuite le temps de réponse, les appels échoués et la qualité de la sortie avant d'ajouter des agents ou des automatisations. Un workflow déterministe reste préférable lorsque la tâche se résume à transformer une entrée connue selon des règles stables.
Repère opérationnel supplémentaire
Les changements de configuration méritent une discipline de maintenance. Modifiez une seule dimension à la fois, gardez une copie exploitable, lancez openclaw doctor, puis redémarrez le Gateway seulement lorsque le changement l'exige. Le fichier est validé strictement : une clé inconnue ou une structure invalide peut empêcher le démarrage. La Control UI et openclaw config get sont utiles pour lire l'état effectif au lieu de raisonner sur un extrait ancien ou une valeur supposée.
Repère opérationnel supplémentaire
La sécurité commence avant le prompt. Restreignez les expéditeurs autorisés, conservez l'écoute réseau sur loopback tant qu'un accès distant n'est pas nécessaire, protégez l'authentification du Gateway et auditez régulièrement l'installation avec openclaw security audit --deep. Les contenus reçus, les pages consultées et les résultats d'outils doivent être considérés comme non fiables. Donnez à chaque agent uniquement les capacités nécessaires et préférez des identifiants dédiés pour les services externes.
Repère opérationnel supplémentaire
La mémoire OpenClaw est explicite : les faits durables vivent dans MEMORY.md, les préférences stables dans USER.md et les notes courantes dans memory/. Cette lisibilité facilite l'audit et la correction, mais oblige à surveiller ce qui est conservé. Ne placez ni secret ni jeton dans ces fichiers. Une information sensible copiée dans une conversation peut aussi se retrouver dans un transcript ; appliquez donc une politique de rétention et nettoyez les données avant de partager des diagnostics.
Repère opérationnel supplémentaire
Dans un déploiement multi-agent, chaque agent doit conserver son propre workspace, son répertoire d'état et son historique. Les bindings choisissent l'agent à partir du canal, du compte ou du correspondant. Cette séparation évite les collisions de sessions et permet des identités distinctes, mais elle ne crée pas une isolation hostile à l'intérieur d'un même Gateway. Pour des équipes ou clients qui ne se font pas confiance, utilisez des Gateway et, si nécessaire, des utilisateurs système ou des hôtes séparés.
Exemple concret
Une petite équipe souhaite recevoir chaque lundi une synthèse de veille dans son canal de travail. Elle installe OpenClaw, termine l’onboarding, puis vérifie le Gateway. Dans le workspace, elle ajoute un skill veille-hebdo qui décrit les sources autorisées, le format du résumé, les critères de sélection et la règle de citation. Le skill n’implémente pas une classe Python : il guide l’agent dans l’usage des tools disponibles.
L’opérateur teste d’abord un tour manuel avec openclaw agent --agent main --message "Prépare la veille selon le skill veille-hebdo". Il relit les sources et contrôle le fichier produit. Une fois le résultat stable, il crée une automation hebdomadaire et vérifie sa présence avec openclaw automations list. Après le premier passage, il inspecte l’historique avec openclaw automations runs <job-id> et confirme la livraison dans le canal. Si le résultat dérive, il corrige les instructions du skill avant d’ajouter des outils. Cet exemple prouve l’intérêt d’OpenClaw : continuité, routage et planification autour d’un assistant, sans inventer un pipeline Python.
Bonnes pratiques
Commencez par un seul agent, un canal et une mission étroite. Vérifiez chaque effet de bord avant d’automatiser, gardez les secrets hors du workspace et limitez les tools d’écriture ou d’exécution. Exécutez openclaw security audit --deep après une modification d’exposition, de canal ou de plugin. En production, supervisez le Gateway et surveillez les logs ainsi que l’historique des automations.
Ne confondez pas allowlist de skills et autorisation système : cacher un skill au modèle ne bloque pas un shell déjà disponible. Ne partagez pas un Gateway entre utilisateurs adverses. Enfin, documentez une procédure de rollback pour la configuration et testez un cas négatif dans votre checklist, par exemple le refus d’un expéditeur inconnu ou d’une action hors workspace.
Questions fréquentes
OpenClaw est-il un framework Python ?
Non. OpenClaw actuel est un assistant IA self-hosted construit autour d’un runtime Node/TypeScript et d’un Gateway. Il ne s’installe pas avec pip et ne fournit pas une API Python Agent destinée à composer des pipelines. Pour une orchestration applicative en graphe, regardez plutôt un framework comme LangGraph.
À quoi sert le Gateway OpenClaw ?
Le Gateway maintient les connexions aux canaux, les sessions, le routage et les surfaces de contrôle. La CLI, la Control UI, les automations et les nodes s’y connectent. Il doit rester actif pour recevoir les messages et déclencher les tâches planifiées.
OpenClaw peut-il gérer plusieurs agents ?
Oui. Chaque agent peut avoir son workspace, son état, son modèle et son historique de sessions. Des bindings routent les comptes ou conversations vers l’agent cible. Cette fonction organise plusieurs assistants isolés ; elle ne reproduit pas automatiquement une équipe d’agents collaboratifs de type CrewAI.
OpenClaw convient-il à la production ?
Oui si le Gateway est supervisé, l’accès est restreint, les tools sont limités et les actions sont vérifiées. La production exige aussi des sauvegardes, des logs, une stratégie de mise à jour et un audit de sécurité. Pour des utilisateurs non fiables entre eux, séparez les Gateway et les hôtes.
Articles liés
OpenClaw est surtout pertinent comme assistant persistant et multi-surface que vous exploitez vous-même. La prochaine étape consiste à installer le Gateway, puis à cadrer un premier agent et ses skills avant toute automation.
Restez informé sur les agents IA
Nouveaux tutoriels, comparatifs et guides pratiques directement dans votre boîte mail.