OpenClaw : ce que c’est, comment lui brancher des outils, et la position d’Atako

Ce qu’est OpenClaw

OpenClaw est un projet open source sous licence MIT, porté par l’OpenClaw Foundation. Il a porté d’autres noms avant celui-ci, Clawdbot puis Moltbot : d’anciens articles ou fils de discussion peuvent donc désigner le même projet sous ces noms.

Son cœur est une passerelle (gateway) que vous hébergez vous-même. Elle relie des messageries (WhatsApp, Telegram, Slack, Discord, Signal, Teams, iMessage et d’autres) à des agents IA, et leur donne des outils, des sessions et de la mémoire. Le modèle derrière l’agent est interchangeable : la passerelle est le harnais, la couche qui entoure le modèle et décide comment le travail lui parvient et ce qu’il peut faire.

Si vous voulez un assistant personnel qui répond dans les messageries que vous utilisez déjà, avec le modèle de votre choix et une installation que vous maîtrisez de bout en bout, c’est le type de besoin auquel OpenClaw répond.

Comment on lui branche des outils

Un agent qui se contente de converser sert peu : l’essentiel du travail avec OpenClaw consiste à lui donner des outils. La documentation décrit deux voies principales.

Les skills. Un skill est un dossier avec un fichier SKILL.md qui apprend à l’agent à faire quelque chose et lui dit quoi appeler. On en installe un avec openclaw skills install @owner/slug, ou on le prend sur ClawHub, la place de marché où les skills sont publiés. Les skills y viennent de la communauté : un skill est donc du code tiers que votre agent exécutera avec vos identifiants. Relisez-le avant de l’installer, comme vous relirez une dépendance.

Les identifiants. Un skill qui parle à un service a besoin d’une clé. Vous la déclarez dans ~/.openclaw/openclaw.json, dans la section skills.entries, sous le nom du skill, avec des champs comme apiKey ou env. Vous pouvez aussi la passer en variable d’environnement du processus qui exécute la passerelle. Dans les deux cas, le secret finit sur la machine qui héberge l’agent.

MCP. OpenClaw sait aussi travailler avec des serveurs MCP, que l’on gère avec la commande openclaw mcp. C’est la voie à prendre quand un service fournit déjà son serveur MCP et que vous le préférez à un skill communautaire.

Ce que demande l’auto-hébergement

Faire tourner OpenClaw vous-même est un choix légitime, et le projet le documente. C’est aussi un travail d’exploitation, qu’il vaut mieux énumérer franchement.

Il vous faut une machine allumée en continu, car une passerelle en veille ne répond pas aux messages. Il vous faut une version récente de Node.js et les identifiants du fournisseur de modèle que vous choisissez. Pour chaque canal de messagerie que vous branchez, vous gérez la configuration propre à ce canal.

La documentation du projet insiste beaucoup sur la sécurité, et avec raison : une passerelle qui reçoit des messages et peut appeler des outils est une porte vers tout ce que ces outils atteignent. Les recommandations officielles comprennent de garder la passerelle sur l’interface de boucle locale (loopback) par défaut, d’appairer les appareils avant qu’ils puissent lui parler, d’utiliser des listes d’autorisations pour savoir qui peut écrire à l’agent, et de lancer openclaw security audit pour vérifier votre configuration. Le projet publie aussi des avis de sécurité sur GitHub. Suivez-les, et appliquez les mises à jour qu’ils indiquent.

Rien de tout cela n’est déraisonnable, et beaucoup de personnes le font très bien. C’est du temps passé sur la plomberie et sur son maintien en bon état, en échange d’un contrôle total.

Ce que fait Atako

Les nouveaux agents d’Atako ne se créent pas sur OpenClaw. À la création, vous choisissez Hermes, qui est le choix par défaut, ou opencode quand le travail de l’agent consiste à intervenir sur du code dans des dépôts GitHub. La page Hermes Agent décrit ce que ce harnais fait sur la plateforme.

Les agents qui tournent déjà sur OpenClaw sont maintenus. Ils continuent de fonctionner avec le même profil qu’un agent Hermes sur Atako : chat, e-mail, webhooks, messages entre agents et tâches planifiées, et tous les connecteurs du catalogue.

Ce qu’Atako ajoute autour du harnais, quel qu’il soit, c’est la partie difficile à bien faire seul :

• Un broker d’intégrations. Le secret d’un service tiers est conservé côté serveur et injecté au moment de l’appel. L’agent ne le détient jamais : une configuration qui fuite ou une consigne hostile glissée dans un message ne peuvent pas exposer une clé qu’il n’a pas.
• Des droits par endpoint. Pour chaque agent et chaque connexion, vous choisissez Lecture ou Écriture, puis vous cochez les endpoints précis que l’agent peut appeler. Ce qui reste décoché ne peut pas être appelé.
• Un journal d’audit. Chaque appel est enregistré avec son outil, son statut, son code HTTP et sa latence, visible sur l’agent et dans le dashboard.

Brancher un outil sur un OpenClaw auto-hébergé

Si vous faites tourner OpenClaw vous-même, les guides ci-dessous détaillent le branchement de deux outils courants avec un skill, et ce qu’il faut vérifier avant de lui faire confiance :

• HubSpot avec OpenClaw
• GitHub avec OpenClaw

Chacun se termine par la mise en place équivalente sur Atako, où le nouvel agent tourne sur Hermes et atteint le même outil par le broker.