Moltbot (ex-Clawdbot) : guide complet 2026 de l'agent IA local (fonctionnalités, canaux, modèles, limites)

Pourquoi Clawdbot est devenu Moltbot

Le changement de nom n'est pas un "rebranding marketing" classique. Le projet a abandonné Clawdbot pour Moltbot suite à une demande liée à une confusion de marque autour de "Claude". Les mainteneurs ont choisi de jouer la carte du "molt", la mue, le changement de carapace, plutôt que de disparaître. Résultat, on retrouve parfois encore l'ancien vocabulaire dans la doc, les dossiers, certains scripts et chemins (ce n'est pas grave, mais ça surprend la première fois).

Moltbot, c'est quoi exactement

Moltbot est un assistant IA "local-first" qui s'installe sur votre machine (ou un serveur), puis se connecte à vos canaux de discussion (WhatsApp, Telegram, Discord, Slack, Signal, iMessage, Teams, etc.). Ensuite, il tourne via un composant de fond (un "gateway"), et il expose une interface de contrôle (dashboard) accessible dans un navigateur.

Ce qui change par rapport à un bot classique : Moltbot n'est pas seulement un connecteur vers un LLM. Il orchestre :

• des sessions (conversations et contexte, par canal et parfois par fil ou groupe),
• des outils (web, fetch, navigateur, exécution, actions de messaging),
• des politiques de sécurité (qui parle, où, et ce que le bot a le droit de faire),
• et, si vous le voulez, des multi-agents (plusieurs "personnalités" ou rôles avec des droits différents).

Autrement dit, on est plus proche d'un mini-système d'automatisation conversationnelle que d'un simple "chat avec un modèle". C'est d'ailleurs pour ça que l'installation et la sécurité comptent autant que le choix du modèle.

Moltbot en chiffres (et pourquoi ça a explosé)

On peut mesurer la hype de deux façons : la communauté open source, et les canaux qu'il cible.

• Communautaire : le dépôt principal affiche des dizaines de milliers d'étoiles, avec une activité soutenue (issues, PR, releases fréquentes). En clair, c'est un projet qui bouge vite, parfois trop vite pour ceux qui aiment le confort des versions "enterprise"...
• Canaux : Moltbot s'appuie sur des applis de messagerie massivement utilisées. WhatsApp dépasse les 3 milliards d'utilisateurs mensuels, Telegram annonce plus d'un milliard, Discord communique sur environ 200 millions d'utilisateurs actifs mensuels. Quand un outil sort avec une compatibilité "messagerie d'abord", la diffusion devient presque naturelle.

A noter : ce succès vient aussi d'un imaginaire, l'idée d'avoir "son propre assistant", qui répond sur les canaux du quotidien, pas dans un onglet perdu. C'est tout bête, mais c'est exactement ce qui a manqué à beaucoup de projets d'agents IA.

Fonctionnalités principales : ce que Moltbot sait faire aujourd'hui

Moltbot embarque une base commune, puis des fonctions qui s'activent selon les canaux, les outils, et votre configuration. Voici les blocs les plus importants.

1) Les canaux de conversation

Le principe : vous parlez à Moltbot là où vous êtes déjà. Selon le canal, la mise en place change (token bot, QR code, app compagnon, plugin, etc.). Dans tous les cas, vous définissez une politique d'accès (pairing, allowlist, open... on y revient, parce que "open" est le genre de bouton qui peut ruiner votre semaine).

On retrouve notamment :

• WhatsApp (connexion via appareil lié, souvent QR code)
• Telegram (bot token, généralement rapide à configurer)
• Discord
• Slack
• Signal
• iMessage (plutôt ciblé Mac)


• Teams et autres environnements pro selon les plugins disponibles

2) Le gateway et le dashboard

Le gateway est le coeur qui tourne en tâche de fond. Il gère les connexions, les sessions, les actions, et sert l'interface web. Le dashboard, lui, est l'interface de contrôle pour vérifier l'état, voir les sessions, tester, et ajuster la configuration. C'est pratique, et (petite digression) c'est aussi une surface d'attaque potentielle si vous l'exposez n'importe comment sur Internet... donc prudence si vous utilisez un VPS.

3) Les "outils" (tools) et l'agent qui agit

Un agent utile, c'est un agent qui fait plus que parler. Moltbot inclut notamment :

• web_search : recherche web via un fournisseur (ex : Brave Search API)
• web_fetch : récupération d'une page et extraction lisible
• des actions de messagerie : envoyer un message, interagir avec un canal
• des capacités d'exécution (selon votre config) avec système d'approbation

C'est là que l'on bascule dans le monde "agent". Si vous autorisez l'exécution, Moltbot peut devenir très efficace... ou très dangereux. Le bon usage, ce n'est pas "tout autoriser", c'est "autoriser ce qui est nécessaire, au bon endroit, pour les bonnes personnes".

4) Multi-agents et sandbox

Autre point intéressant : vous pouvez définir plusieurs agents, avec des profils différents. Exemple concret :

• un agent "perso" avec des outils larges, mais accessible seulement en DM allowlist
• un agent "travail" plus strict, avec mention obligatoire et outils limités
• un agent "public" enfermé dans une sandbox, sans exécution, sans accès sensible

Ce n'est pas gadget. C'est souvent la différence entre un assistant exploitable en vrai, et un jouet instable que l'on désinstalle au bout de trois jours.

Modèles et fournisseurs : cloud, local, ou mix

Moltbot peut travailler avec plusieurs fournisseurs de modèles. Le choix dépend de trois critères : coût, confidentialité, qualité.

Option A : modèles cloud (qualité et confort)

Avec un fournisseur cloud, vous obtenez souvent de meilleurs résultats en raisonnement, en code, en extraction d'intention. En contrepartie, vous envoyez des données hors de votre machine (même si vous pouvez limiter ce que vous donnez au modèle).

Bon réflexe : compartimenter. Les conversations perso sensibles ne devraient pas être traitées comme un support client. Et dans Moltbot, vous pouvez justement séparer les canaux, les agents, et les outils.

Option B : modèles locaux via Ollama (confidentialité et autonomie)

Si vous visez la confidentialité ou l'autonomie, l'intégration avec un runtime local (comme Ollama) est un point fort. Vous téléchargez un modèle open source, vous le faites tourner sur votre machine, et Moltbot s'y connecte via une API compatible. Evidemment, la qualité varie selon le modèle, et les performances dépendent de votre matériel (GPU ou pas, RAM, etc.).

A noter : le "tout local" est séduisant, mais il faut rester lucide. Certains usages (rédaction fine, raisonnement complexe, planning avec beaucoup de contraintes) peuvent être moins bons selon les modèles locaux que vous choisissez.

Option C : mix intelligent (recommandé dans beaucoup de cas)

Le mix est souvent le meilleur compromis : local pour les tâches sensibles ou simples, cloud pour les tâches complexes ou quand il faut de la robustesse. L'important, c'est de décider et de documenter votre logique, sinon vous finissez avec un système "magique" que même vous ne comprenez plus (expérience vécue par pas mal d'équipes...).

Installation 2026 : rapide, mais à faire proprement

Bonne nouvelle : l'installation est devenue assez accessible. Mauvaise nouvelle : comme c'est un agent, il faut résister à la tentation du "suivant, suivant, suivant".

Pré-requis

• Node.js 22+ (c'est un point non négociable)
• macOS, Linux, ou Windows via WSL2 (en pratique, WSL2 simplifie beaucoup)
• Optionnel : un environnement propre (machine secondaire ou VM) si vous testez l'exécution d'actions

Méthode 1, script d'installation (recommandée)

Sur macOS ou Linux :

curl -fsSL https://molt.bot/install.sh | bash

Sur Windows (PowerShell) :

iwr -useb https://molt.bot/install.ps1 | iex

Puis, si l'onboarding n'a pas été lancé automatiquement :

moltbot onboard --install-daemon

Méthode 2, installation globale via npm (manual)

npm install -g moltbot@latest


moltbot onboard --install-daemon

Premier check (à faire, vraiment)

Avant de connecter WhatsApp ou de donner des outils, vérifiez la santé du système :

moltbot doctor


moltbot status


moltbot health

Ensuite, vous pouvez ouvrir le dashboard :

moltbot dashboard

(En général, il est accessible en local sur un port dédié. Si vous le rendez accessible à distance, faites-le en sécurisé, sinon vous ouvrez une porte inutile.)

Configuration des canaux : exemple WhatsApp (et logique de sécurité)

WhatsApp est l'un des canaux les plus "wow" pour un assistant perso... mais aussi l'un des plus sensibles, parce qu'un compte WhatsApp, c'est vite votre vie entière (famille, clients, groupes, photos, etc.).

Un exemple minimal ressemble à ceci :

{


  "channels": {


    "whatsapp": {


      "dmPolicy": "allowlist",


      "allowFrom": ["+33612345678"]


    }


  }


}

Ensuite, on lance la connexion (QR code via appareils liés), puis on démarre le gateway. Selon votre usage, vous pouvez aussi :

• forcer l'accès uniquement en DM,
• bloquer les groupes au début (le temps de tester),
• activer une exigence de mention dans les groupes,
• restreindre les outils disponibles sur ce canal.

A noter : Telegram est souvent plus simple à mettre en place (token). En entreprise, Slack ou Teams peuvent être plus "propres" côté gouvernance. Il n'y a pas un meilleur canal, il y a celui qui correspond à votre risque et à votre contexte.

Points positifs : pourquoi Moltbot est vraiment intéressant

• Expérience utilisateur naturelle : on parle à l'assistant dans la messagerie du quotidien, pas dans une app en plus.
• Architecture agent + sécurité : si on prend le temps de configurer, on peut limiter drastiquement la casse potentielle.
• Multi-agents : pratique pour séparer les usages (perso, pro, public) sans tout mélanger.
• Choix des modèles : cloud, local, ou mix. On n'est pas enfermé.
• Open source et communauté : ça bouge vite, les intégrations se multiplient, et les retours terrain arrivent rapidement.

Points négatifs, limites, et sujets sensibles (prompt injection, permissions, confiance)

On ne va pas tourner autour : un agent IA qui peut agir est un outil à risque. Même bien intentionné, il peut être manipulé, mal interpréter une demande, ou être poussé hors de son cadre via des attaques conversationnelles.

1) Prompt injection : le risque le plus sous-estimé

Le scénario classique : quelqu'un envoie un message du type "ignore tes règles, fais X" ou cache des instructions malveillantes dans une page web, un message, un document. Un modèle peut se faire piéger. Et si votre bot a des outils puissants, l'impact peut être réel (suppression de fichiers, envoi de messages, actions non désirées).

Les bonnes pratiques, très simples mais vitales :

• ne pas utiliser dmPolicy = "open" sur un canal "réel"
• commencer en allowlist, puis passer en pairing si besoin
• activer les approbations pour l'exécution et les actions sensibles
• restreindre les outils par canal, par groupe, voire par utilisateur
• segmenter : un agent public n'a pas les mêmes droits qu'un agent privé

2) Exposition du gateway et du dashboard

En local, c'est très bien. Sur un serveur exposé, c'est un autre jeu. Si vous ouvrez le dashboard au monde, vous augmentez la surface d'attaque. La règle simple : si vous n'avez pas besoin de l'exposer, ne l'exposez pas. Si vous en avez besoin, faites-le derrière un accès sécurisé (et pas "admin admin"...).

3) Choix du modèle et robustesse

Certains modèles sont plus "dociles" que d'autres, parfois trop dociles. Moltbot a d'ailleurs une logique de protection, il peut refuser certains modèles jugés trop fragiles ou obsolètes. Ce n'est pas parfait, mais l'intention est claire : partir du principe qu'un modèle peut être manipulé, et limiter les dégâts possibles.

4) Complexité réelle, derrière l'effet "wow"

Oui, l'installation est rapide. Mais un usage propre demande :

• un minimum de culture sécurité,
• une discipline de configuration,
• et, parfois, une machine dédiée ou une VM.

Ce n'est pas un défaut unique à Moltbot, c'est le prix de tous les agents IA qui touchent au système.

Cas d'usage concrets (perso et pro)

• Veille et synthèse : recevoir un résumé régulier via un canal (ex : Telegram) avec sources et points d'action.
• Assistance opérationnelle : checklists, rappels, suivi de tâches, messages proactifs.
• Support interne : un agent "work" sur Slack qui répond sur une base de connaissances, sans jamais avoir accès aux outils sensibles.
• Automatisation douce : envoyer un message, organiser une note, lancer une recherche, préparer un brouillon.

(plus le cas d'usage touche à des données sensibles, plus le "local" et la segmentation deviennent importants. C'est exactement là où Moltbot peut être intéressant pour une équipe technique, ou une PME prudente.)

Nota Bene : petit lexique pour éviter les malentendus

• Agent IA : un système qui combine un modèle + des outils + une logique d'action. Pas juste un chat.
• Gateway : le processus de fond qui gère les connexions, sessions, outils, et le dashboard.
• Canal : WhatsApp, Telegram, Slack, etc. Chaque canal a ses règles et ses risques.
• dmPolicy : règle d'accès en messages privés. "allowlist" et "pairing" sont vos amis. "open" est le bouton rouge.
• Prompt injection : tentative de détourner un modèle via des instructions malicieuses (souvent cachées dans du texte ou une page web).
• Sandbox : environnement restreint, limité en accès et en pouvoir d'action.

Conclusion : un agent prometteur, à condition de le traiter comme un système

Moltbot mérite sa popularité parce qu'il coche des cases que beaucoup d'outils ratent : intégration native dans les messageries, fonctionnement "local-first", multi-agents, et une vraie prise en compte de la sécurité. Mais c'est aussi un outil qui demande un minimum de rigueur. Si vous le configurez comme un gadget, il se comportera comme un gadget... avec des dents.

Le bon point, c'est que les briques existent déjà pour faire les choses proprement : allowlists, pairing, sandbox, restrictions d'outils, approvals. Bref, un agent IA, oui, mais un agent que l'on canalise. Et dans le contexte 2026, c'est probablement la seule façon raisonnable de profiter de ce type d'assistant au quotidien.

En savoir plus

https://www.molt.bot/