Comment lancer OpenClaw avec Ollama en local ?

OpenClaw sert à garder un assistant Ollama disponible en continu, depuis Telegram, Slack, WhatsApp ou Discord. Je vous montre ce qu’il faut prévoir côté modèle, contexte, Gateway, recherche web et déploiement Docker, sans transformer ça en usine à gaz.

À quoi sert OpenClaw avec Ollama ?

OpenClaw sert à transformer Ollama en assistant IA persistant, accessible depuis des applications de messagerie, au lieu de rester limité à une utilisation en ligne de commande.

Quand je teste Ollama dans un terminal, c’est rapide, pratique, et franchement suffisant pour vérifier un modèle ou poser deux trois questions. Mais ça reste ponctuel. Je lance une commande, j’obtiens une réponse, puis c’est terminé.

Dès qu’on veut un assistant qui reste disponible, qui reçoit des messages, qui garde ses connexions ouvertes et qui lance des tâches en arrière-plan, il faut une couche de service. C’est exactement le rôle d’OpenClaw.

OpenClaw agit comme un assistant personnel qui tourne sur votre propre matériel, ou avec des modèles cloud exposés via Ollama. Il connecte vos modèles à des canaux que vous utilisez déjà, comme Telegram, WhatsApp, Slack, Discord ou iMessage. Dans les faits, vous ne parlez plus à Ollama depuis un terminal, vous lui parlez depuis votre messagerie.

L’architecture est assez simple à comprendre, je la vois en trois couches.

• La couche messagerie correspond aux applications utilisées par vous ou votre équipe, par exemple Telegram, Slack ou Discord.
• La couche coordination repose sur le démon Gateway, c’est-à-dire un service qui tourne en continu et fait le lien entre les messages et les modèles.
• La couche modèle correspond à Ollama, soit installé en local sur votre machine, soit connecté à des modèles disponibles dans le cloud.

Le flux est direct. Un message arrive dans l’application de messagerie. Il remonte au Gateway. Gateway appelle l’API Ollama, c’est-à-dire l’interface qui permet d’envoyer une requête au modèle. Puis la réponse repart dans le même canal.

Ce qui change vraiment, ce n’est pas seulement l’interface conversationnelle. C’est le fait que l’assistant peut rester actif, suivre une demande, piloter des tâches multi-étapes et continuer à travailler en arrière-plan. Chez un client, c’est souvent là que le déclic arrive. Le modèle n’est plus juste un outil qu’on interroge, il devient un petit agent disponible.

Petit point à connaître aussi, le projet a changé de nom avant OpenClaw. Il est passé par Moltbot puis Clawdbot. Certains anciens alias restent compatibles, par exemple ollama launch clawdbot.

Élément	Rôle	Ce que ça change
Applications de messagerie	Recevoir et envoyer les messages	Vous utilisez vos outils habituels
Gateway OpenClaw	Coordonner les échanges et garder le service actif	L’assistant reste disponible en continu
Ollama	Exécuter le modèle IA local ou cloud	Vous gardez la main sur le modèle utilisé

Quel matériel faut-il prévoir ?

Le point critique n’est pas seulement la puissance brute, c’est surtout la longueur de contexte dont l’assistant aura besoin pour gérer des tâches multi-étapes.

La longueur de contexte, dit simplement, c’est la quantité d’information que le modèle peut garder en mémoire pendant une interaction. Si OpenClaw doit suivre une conversation longue, faire plusieurs appels d’outils, lancer une recherche web, puis reprendre une tâche commencée dix minutes plus tôt, il lui faut de la place. Sinon il oublie des morceaux, il répète, ou il part dans une direction bizarre.

Avec Ollama, la longueur de contexte peut être définie automatiquement selon la VRAM, c’est-à-dire la mémoire de la carte graphique. Par défaut, on est sur ces ordres de grandeur :

• Moins de 24 Go de VRAM : 4k de contexte.
• Entre 24 et 48 Go de VRAM : 32k de contexte.
• 48 Go de VRAM et plus : 256k de contexte.

Je préfère définir explicitement la longueur de contexte pour des agents multi-étapes. Les valeurs automatiques peuvent surprendre, surtout quand on pense avoir assez large et que l’agent commence à perdre le fil.

Côté système, je vise macOS 14 ou plus, ou Ubuntu 22.04 ou plus, que je recommande souvent pour une machine dédiée. Il faut au minimum 16 Go de RAM, mais 32 Go est franchement plus confortable. Pour certains modèles locaux comme qwen3-coder ou glm-4.7-flash, prévoyez environ 25 Go de VRAM. Pour des usages plus larges, 48 Go et plus devient beaucoup plus sérieux. Le disque aussi compte : 5 Go minimum, mais plutôt 30 Go ou plus si vous téléchargez plusieurs modèles locaux.

Côté logiciel, il faut Ollama 0.17 ou plus, Node.js 18 ou plus, et OpenClaw installé via npm. Je vérifie toujours les bases avant de chercher un problème ailleurs :

ollama --version
node --version
ollama signin

Le compte Ollama sert pour les modèles cloud et la recherche web. Et si votre machine est limite, je ne forcerais pas. Un modèle lourd peut démarrer sans tourner correctement. Dans ce cas, les modèles cloud sont souvent le chemin le plus simple pour commencer proprement.

Besoin	Minimum	Recommandé	Pourquoi c’est important
Système	macOS 14 ou Ubuntu 22.04	Ubuntu 22.04 ou plus	Pour une base stable avec Ollama et OpenClaw.
RAM	16 Go	32 Go	Pour éviter que la machine sature dès que l’agent travaille longtemps.
VRAM	Environ 25 Go pour certains modèles	48 Go et plus	Pour gérer des modèles locaux et un contexte plus large.
Disque	5 Go	30 Go ou plus	Les modèles locaux prennent vite de la place.
Logiciels	Ollama 0.17, Node.js 18	Versions récentes	Pour éviter les bugs liés aux vieilles versions.

Quel modèle Ollama choisir ?

Pour démarrer sans me battre avec la VRAM et le contexte, je partirais sur un modèle cloud, puis je basculerais en local seulement si le matériel suit.

Avec OpenClaw, le choix du modèle change vite l’expérience. Si le modèle manque de contexte, il oublie une partie des échanges. Si la machine manque de VRAM, la mémoire de la carte graphique, ça rame ou ça ne démarre pas. C’est souvent là que les modèles cloud font gagner du temps.

Je regarderais d’abord ces modèles Ollama en cloud :

• kimi-k2.5:cloud : Bon point de départ pour débuter, assez polyvalent pour raisonner, écrire, analyser et piloter des tâches.
• qwen3.5:cloud : Intéressant pour le raisonnement et les usages techniques, surtout quand les prompts deviennent plus structurés.
• minimax-m2.7:cloud : Pratique pour la productivité, les assistants de travail, les synthèses et les tâches du quotidien.
• glm-5.1:cloud : Solide pour des workflows plus larges, avec un bon équilibre entre compréhension, rédaction et exécution.

Le vrai confort du cloud, c’est que la grande longueur de contexte est disponible sans passer du temps à régler le modèle local. La recherche web peut aussi être supportée sans configuration supplémentaire côté modèle. Je reste prudent, ça ne veut pas dire que tout sera magique ou meilleur dans tous les cas. Ça veut surtout dire que je peux tester OpenClaw vite, sans transformer le lancement en audit matériel.

En local, je regarderais plutôt qwen3-coder si le sujet principal est le code, et gemma4 pour un usage plus général. Le local a du sens quand je veux garder l’exécution près de mon infrastructure, intégrer proprement avec mes outils internes, ou maîtriser davantage l’environnement. Mais il faut surveiller la VRAM, le disque, la RAM et la longueur de contexte. Ce sont des contraintes très concrètes.

Chez les clients, je vois souvent la même erreur. Ils veulent commencer par le modèle local le plus ambitieux. Alors que le vrai sujet, au début, c’est de valider le workflow, les canaux connectés et les tâches vraiment utiles. Le modèle vient après.

Besoin	Choix conseillé
Débuter vite	kimi-k2.5:cloud
Code	qwen3.5:cloud ou qwen3-coder en local si la machine suit
Productivité	minimax-m2.7:cloud ou glm-5.1:cloud
Contexte long	Cloud, pour éviter les réglages locaux trop tôt
Machine avec peu de VRAM	Cloud
Environnement maîtrisé	Local, avec qwen3-coder ou gemma4 selon l’usage

Comment connecter Telegram et les autres canaux ?

On connecte les canaux en laissant le démon Gateway maintenir les sessions de messagerie et router les messages vers Ollama.

Dans OpenClaw, Le Gateway est la pièce qui reste active en permanence. Il garde les connexions ouvertes avec les canaux, reçoit les messages entrants, orchestre les agents, appelle l’API locale d’Ollama ou un modèle cloud, puis renvoie la réponse dans le canal d’origine. C’est lui qui fait le pont entre “quelqu’un m’écrit sur Telegram” et “un modèle répond avec le bon contexte”.

Telegram est souvent le plus simple pour valider un assistant. Vous créez un bot avec BotFather, Telegram vous donne un token d’accès, et ce token permet à votre application de parler à la Bot API de Telegram. La Bot API, c’est simplement l’interface officielle qui permet d’envoyer et recevoir des messages via un bot. Rien de magique, mais c’est pratique pour tester vite.

Le même principe vaut pour WhatsApp, Slack, Discord ou iMessage. Le canal change, les contraintes changent parfois, mais la logique reste identique. Un message entre, Gateway le récupère, il coordonne le bon agent, Ollama produit la réponse, puis Gateway renvoie le résultat là où la conversation a commencé.

Pour la recherche web, il faut aussi penser au compte Ollama. Elle peut être activée après connexion avec ollama signin. Selon les informations disponibles, les modèles cloud recommandés ont le support de la recherche web sans configuration supplémentaire côté modèle. En clair, vous évitez de bricoler chaque modèle un par un, tant que vous êtes bien connecté et que vous utilisez un modèle compatible.

Dans la vraie vie, je ne branche jamais tout d’un coup. Avant d’automatiser des tâches longues, je valide toujours une conversation simple, puis une tâche avec plusieurs étapes, puis seulement ensuite les intégrations plus sensibles. Ça évite de déboguer trois problèmes en même temps. Et franchement, c’est souvent là qu’on gagne le plus de temps.

• Vérifier Ollama.
• Vérifier le modèle utilisé.
• Vérifier le canal connecté, par exemple Telegram.
• Tester un message simple.
• Tester une tâche multi-étapes.
• Activer la recherche web si nécessaire.

Comment le faire tourner sans interface ?

Pour un usage sérieux, OpenClaw doit tourner en service headless, idéalement dans un conteneur Docker si on veut un déploiement propre et reproductible.

Headless, ça veut dire sans interface visible. Pas besoin de garder une fenêtre ouverte, ni un terminal lancé sur votre machine. Le service tourne en arrière-plan, il démarre avec le système ou avec le conteneur, et il reste disponible même si vous fermez votre session.

C’est important dès qu’OpenClaw sert d’assistant de messagerie. Si vous le branchez à Telegram, Slack ou Discord, il doit pouvoir répondre à n’importe quel moment. Un assistant qui dépend d’un terminal ouvert sur votre bureau, ce n’est pas vraiment un assistant. C’est une démo fragile.

Docker aide beaucoup ici. Pas parce que Docker est magique, mais parce qu’il isole l’environnement. Les dépendances restent stables, les chemins sont contrôlés, le redémarrage est plus simple, et vous pouvez déplacer le déploiement plus proprement d’une machine à une autre. Je ne mettrais pas un fichier docker-compose complet sans connaître les variables exactes, les ports, les volumes et les commandes attendues par votre version d’OpenClaw. Le principe reste simple : OpenClaw tourne comme un service, avec sa configuration persistée, et il sait joindre Ollama.

Les points que je surveille en priorité sont assez classiques :

• La persistance de la configuration : Les tokens, comptes connectés, préférences et sessions ne doivent pas disparaître au redémarrage.
• L’accès à Ollama : OpenClaw doit pouvoir appeler l’API locale d’Ollama, souvent exposée sur un port HTTP.
• Les comptes connectés : Si vous utilisez du cloud, de la recherche web ou un connecteur externe, l’authentification doit rester valide.
• Les ressources machine : RAM, CPU, GPU éventuel. Un modèle local peut ralentir tout le système si la machine est juste.
• Les logs du Gateway : C’est souvent là qu’on voit les erreurs de routage, de connecteur ou d’appel modèle.
• Le redémarrage automatique : Le conteneur ou le service doit repartir seul après un crash ou un reboot.

En production légère, le vrai sujet n’est pas seulement de lancer le conteneur. C’est de savoir quoi regarder quand l’assistant ne répond plus. Chez un client, on avait perdu une heure sur “le modèle ne marche pas”, alors que le bot Telegram avait juste perdu sa connexion. Les logs, la connexion au canal et l’accès à l’API Ollama sont les trois premiers endroits où je regarde.

Symptôme	Cause probable	Vérification simple
Aucune réponse dans Telegram	Bot déconnecté, token invalide ou Gateway arrêté	Regarder les logs du Gateway et tester le token du bot
Réponse lente	Modèle trop lourd, RAM saturée ou Ollama occupé	Surveiller CPU, RAM et temps de réponse de l’API Ollama
Tâche multi-étapes interrompue	Timeout, crash du service ou configuration non persistée	Vérifier les logs, les limites de temps et les volumes Docker
Recherche web inactive	Compte non connecté, clé API absente ou accès réseau bloqué	Tester l’authentification et une requête web simple depuis le service

Vous voulez un assistant IA qui reste vraiment disponible ?

OpenClaw devient intéressant dès qu’on sort du test Ollama en terminal. Le Gateway garde les connexions de messagerie, route les messages vers Ollama et permet à l’assistant de gérer des tâches plus longues en arrière-plan. Le point à ne pas sous-estimer, c’est le contexte et le matériel. Un modèle cloud comme kimi-k2.5:cloud permet de démarrer vite, le local devient pertinent quand l’infra suit. Je commencerais simple : un canal Telegram, un modèle fiable, une tâche utile, puis Docker pour le headless. Le bénéfice pour vous, c’est clair : un assistant IA privé, accessible et réellement exploitable au quotidien.

FAQ

• OpenClaw sert à quoi avec Ollama ?
  OpenClaw sert à faire tourner un assistant IA persistant basé sur Ollama. Au lieu d’utiliser le modèle uniquement en ligne de commande, vous pouvez lui parler depuis Telegram, WhatsApp, Slack, Discord ou iMessage. Le Gateway reçoit les messages, appelle Ollama, puis renvoie la réponse dans le même canal.
• Faut-il un gros serveur pour utiliser OpenClaw ?
  Pas forcément pour tester, mais le matériel devient important dès que vous utilisez des modèles locaux et des tâches multi-étapes. Le point clé, c’est la longueur de contexte. Ollama attribue par défaut 4k sous 24 Go de VRAM, 32k entre 24 et 48 Go, et 256k à partir de 48 Go. Pour démarrer simplement, un modèle cloud peut éviter pas mal de contraintes.
• Quel modèle choisir pour commencer ?
  Pour commencer vite, kimi-k2.5:cloud est un bon choix. Les modèles cloud comme qwen3.5:cloud, minimax-m2.7:cloud ou glm-5.1:cloud simplifient aussi la gestion du contexte et de la recherche web. Les modèles locaux comme qwen3-coder ou gemma4 sont intéressants si votre machine a assez de ressources.
• OpenClaw peut-il utiliser la recherche web ?
  Oui, la recherche web peut être activée avec un compte Ollama. Il faut se connecter avec ollama signin. Les modèles cloud recommandés disposent du support de la recherche web sans configuration supplémentaire côté modèle, ce qui est pratique pour un assistant qui doit répondre avec des informations plus fraîches.
• Pourquoi déployer OpenClaw en Docker ?
  Docker est utile pour faire tourner OpenClaw en mode headless, sans garder un terminal ouvert. Ça aide à isoler l’environnement, gérer les dépendances et redémarrer le service plus proprement. Pour un assistant connecté à Telegram ou Slack, c’est important, parce qu’il doit rester disponible en continu.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. Avec mon agence webAnalyste et mon organisme Formations Analytics, j’accompagne des équipes chez Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez brancher proprement l’IA à vos outils business, vos données et vos automatisations, je peux vous aider. Contactez-moi.