Comment utiliser OpenClaw avec Ollama en local ?

OpenClaw transforme Ollama en assistant privé toujours joignable depuis WhatsApp, Telegram, Slack, Discord ou iMessage. L’intérêt est simple : ne plus lancer un modèle ponctuellement dans le terminal, mais garder un agent persistant, capable de répondre et d’exécuter des tâches en arrière-plan.

À quoi sert OpenClaw ?

OpenClaw sert à garder un assistant Ollama disponible en continu, accessible depuis des applications de messagerie, sans devoir relancer un agent à chaque fois depuis le terminal.

Quand j’utilise Ollama ponctuellement en ligne de commande, le modèle répond, puis la session disparaît ou reste limitée à cet usage local. C’est pratique pour tester un modèle, poser trois questions, valider une idée. Mais ça devient vite frustrant dès qu’on veut un assistant vraiment utilisable dans le quotidien.

OpenClaw change cette logique. Il ajoute une couche persistante entre vos messageries et vos modèles Ollama. Un message arrive depuis Telegram, WhatsApp, Slack, Discord ou iMessage, OpenClaw le reçoit, l’envoie au modèle local, puis renvoie la réponse dans le même canal. Votre modèle reste sur votre machine, mais l’expérience ressemble beaucoup plus à un vrai assistant personnel.

Le projet est associé à Peter Steinberger. Il a aussi connu plusieurs noms avant OpenClaw, notamment Clawdbot et Moltbot. Ce détail compte un peu, parce qu’on voit bien que l’idée n’est pas juste de lancer un énième script autour d’Ollama, mais de construire une interface durable entre les outils de discussion et l’IA locale.

L’intérêt opérationnel est assez simple :

• Vous pouvez parler à votre assistant depuis les outils que vous utilisez déjà.
• Vous gardez un assistant disponible pour des demandes longues ou répétées.
• Vous pouvez lancer des traitements qui ne se limitent pas à une seule interaction dans un terminal.
• Vous évitez de forcer toute l’équipe à apprendre une interface technique juste pour utiliser un modèle local.

J’ai souvent vu des équipes tester un LLM local, c’est-à-dire un grand modèle de langage exécuté sur leur propre machine ou serveur, puis l’abandonner assez vite parce qu’il restait coincé dans un terminal. La vraie adoption commence quand l’IA arrive dans les outils déjà utilisés. Là, les gens s’en servent naturellement.

L’installation est aussi pensée pour devenir plus simple avec la commande ollama launch à partir d’Ollama 0.17. Je ne rentre pas dans le tutoriel ici, mais l’idée est claire : réduire la friction entre le modèle local et un assistant disponible en permanence.

Comment fonctionne son architecture ?

OpenClaw fonctionne avec trois couches simples, la messagerie, le Gateway et le modèle Ollama. C’est une architecture assez saine, parce que chaque partie a un rôle clair, et ça évite le gros bloc magique qu’on ne sait plus maintenir.

La première couche, c’est la couche messaging. Elle sert de point d’entrée et de sortie pour les messages. En clair, c’est là que l’utilisateur parle à l’assistant, et c’est aussi par là que la réponse revient. OpenClaw peut se brancher sur WhatsApp via des protocoles comme Baileys, sur Telegram via la Bot API, mais aussi sur Slack, Discord ou iMessage. Je trouve ça important, parce que dans la vraie vie, personne n’a envie d’ouvrir une interface de plus. Votre assistant doit venir là où les équipes parlent déjà.

La deuxième couche, c’est le démon Gateway. Et le mot démon compte vraiment ici. Un démon, c’est un programme qui tourne en continu en arrière-plan. Il ne se lance pas juste pour répondre à une question avant de s’arrêter. Il reste disponible. C’est lui qui maintient les connexions, coordonne les échanges entre les messageries et le modèle, et garde l’assistant vivant. C’est aussi ce qui permet d’exécuter des tâches multi-étapes en arrière-plan, sans dépendre d’un petit script fragile lancé à la main. J’ai déjà vu ce problème chez un client, un script “temporaire” qui faisait tout, jusqu’au jour où personne ne savait pourquoi il ne répondait plus.

La troisième couche, c’est la couche modèle. Elle repose sur Ollama, avec des modèles locaux ou cloud selon votre configuration. Le modèle reçoit la demande, génère une réponse, puis cette réponse repart vers la messagerie par le même chemin.

Le flux complet est simple. Un utilisateur envoie une demande dans Telegram ou WhatsApp. La couche messaging récupère le message. Le Gateway coordonne l’échange. Ollama traite la demande. Puis la réponse revient dans l’application de départ, comme si l’assistant était directement intégré à la conversation.

Couche messaging	Elle reçoit les messages depuis WhatsApp, Telegram, Slack, Discord ou iMessage, puis renvoie les réponses vers ces mêmes canaux.
Gateway	Il tourne en continu, maintient les connexions, coordonne les échanges et permet les tâches multi-étapes en arrière-plan.
Modèle	Il s’appuie sur Ollama pour comprendre la demande, générer la réponse et la transmettre au Gateway.

Quels prérequis faut-il prévoir ?

Il faut prévoir un environnement compatible avec Ollama 0.17 ou plus, Node.js 18 ou plus pour l’installation via npm, assez de mémoire, et idéalement une configuration capable de gérer un long contexte.

Le vrai sujet, ce n’est pas seulement de lancer un modèle en local. Ça, une petite machine peut parfois le faire. Le point sensible, c’est de le faire tourner avec assez de contexte pour qu’OpenClaw reste utile dans une vraie conversation. Quand je parle de contexte, je parle de la quantité d’informations que le modèle peut garder en tête pendant l’échange. Un objectif autour de 64k est intéressant, parce qu’un assistant doit suivre plusieurs étapes, relire ce qui vient d’être dit, comprendre une consigne longue, et ne pas perdre le fil au bout de trois messages.

Côté logiciel, il faut rester simple. Il vous faut Ollama en version 0.17+. Il vous faut aussi Node.js 18+ si vous installez OpenClaw via npm, npm étant le gestionnaire de paquets fourni avec Node.js. Dans certains cas, un compte Ollama peut aussi être nécessaire, notamment si vous utilisez des modèles cloud ou des fonctions comme la recherche web. Rien de magique ici, juste les briques de base.

Côté matériel, je préfère parler en repères plutôt qu’en promesses. Plus le modèle est gros, plus il consomme de mémoire. Plus le contexte est long, plus il consomme aussi de mémoire. Si vous avez un GPU, la VRAM aide beaucoup, mais la RAM reste importante. Il faut aussi prévoir du stockage disque, parce que les modèles peuvent prendre de la place.

Usage	Configuration minimale	Configuration recommandée
Test local	Machine compatible avec Ollama, RAM suffisante, stockage disponible pour un petit modèle.	Machine récente, assez de RAM pour éviter les lenteurs, stockage confortable pour tester plusieurs modèles.
Usage régulier	Système stable, mémoire suffisante pour le modèle choisi, Node.js 18+ et Ollama 0.17+.	Configuration plus solide, idéalement avec GPU et VRAM si vous voulez de meilleures réponses et moins d’attente.
Contexte long	Possible selon le modèle, mais vite limité sur une petite machine.	Configuration sérieuse, avec beaucoup de mémoire, surtout si vous visez un contexte autour de 64k.

Une petite machine suffit pour découvrir OpenClaw avec Ollama. Pour un assistant vraiment confortable, qui garde le fil et travaille sur des échanges longs, il faut être plus ambitieux.

Quels modèles Ollama choisir ?

Le bon modèle dépend surtout du contexte voulu, de la machine disponible et du besoin éventuel de recherche web. Avec OpenClaw, je ne choisis pas un modèle “parce qu’il est à la mode”, je le choisis parce qu’il tient la route sur mon usage réel.

La première différence à garder en tête, c’est local contre cloud. Un modèle local garde l’intérêt principal d’Ollama : je fais tourner l’assistant sur ma machine, ou sur mon infrastructure, avec plus de contrôle sur les données, les versions, les accès et les coûts. C’est souvent ce que je veux quand je teste un assistant interne, un workflow sensible, ou un environnement que je veux maîtriser.

Un modèle cloud, lui, peut apporter autre chose. Selon les usages prévus par Ollama, certains modèles cloud peuvent offrir automatiquement un contexte plus long et parfois de la recherche web. Le contexte, c’est la quantité d’informations que le modèle peut garder en mémoire dans une même conversation. Plus il est long, plus l’assistant peut suivre des échanges persistants, relire des consignes, manipuler plusieurs étapes et éviter de perdre le fil.

Pour OpenClaw, je privilégie donc les modèles capables de tenir un contexte long. L’assistant peut recevoir des échanges persistants et gérer des tâches multi-étapes, donc un petit modèle local peut vite devenir frustrant si la conversation grossit. Il existe une recommandation incomplète autour de kimi-k2.5:cloud, que je cite avec prudence comme exemple de modèle cloud évoqué. Je n’en déduis pas une performance garantie, ni une disponibilité permanente, je le garde juste dans la liste des options à vérifier.

Dans la pratique, je raisonne simplement :

• Si je veux tester vite, je démarre avec un modèle local raisonnable, pas trop lourd.
• Si je veux du long contexte et de la recherche web sans gérer toute la charge matérielle, je regarde les modèles cloud Ollama.
• Si je veux garder le maximum de contrôle, je reste sur du local, mais j’accepte les contraintes de RAM, de VRAM et de stockage.

J’ai vu ce point bloquer chez un client : le modèle était bon sur une question simple, mais il décrochait dès que l’assistant devait suivre un dossier sur plusieurs échanges. Ce n’était pas un problème d’OpenClaw, c’était juste un mauvais choix de modèle pour un usage persistant.

Besoin	Option conseillée	Compromis
Confidentialité locale	Modèle local Ollama	Demande assez de RAM, VRAM et stockage.
Long contexte	Modèle cloud Ollama ou gros modèle local adapté	Le cloud simplifie, le local coûte plus cher en machine.
Recherche web	Modèle cloud compatible avec cet usage	Moins de contrôle qu’un modèle strictement local.
Machine limitée	Petit modèle local pour démarrer	Moins bon sur les longues tâches et le raisonnement complexe.
Usage d’assistant persistant	Modèle avec contexte long	À tester sur de vrais échanges, pas juste sur une question courte.

Pourquoi l’utiliser avec vos messageries ?

L’intérêt, c’est de mettre l’assistant IA là où les utilisateurs travaillent déjà, au lieu de leur demander d’ouvrir un terminal ou une interface séparée.

Je le vois souvent chez les clients. Le modèle peut être très bon, l’automatisation peut être propre, mais si l’accès est pénible, personne ne l’utilise. WhatsApp, Telegram, Slack, Discord ou iMessage sont déjà dans les habitudes. On ouvre ces apps sans réfléchir. On envoie un message, on attend une réponse, on relance si besoin. C’est exactement le bon format pour parler à un assistant.

Pour un usage personnel, ça change tout. Votre assistant devient presque un contact. Vous pouvez lui demander de résumer une note, préparer un message, retrouver une info, transformer une idée brute en plan d’action. Pas besoin de changer de contexte. Pas besoin de lancer un outil à part.

Pour une équipe, Slack ou Discord peuvent devenir des points d’entrée très naturels. On peut poser une question dans un canal, lancer une tâche, demander un résumé, suivre une action, ou déclencher une automatisation. Et surtout, tout le monde voit ce qui se passe quand c’est utile.

La différence entre les messageries se joue surtout sur l’usage :

WhatsApp / iMessage	Plutôt naturel pour un assistant personnel, rapide, proche des usages quotidiens.
Telegram	Très pratique pour créer des bots simples, avec une bonne souplesse technique.
Slack / Discord	Idéal pour les équipes, les canaux partagés, les demandes visibles et les suivis collectifs.

Le point important avec OpenClaw, c’est la persistance. Le Gateway, c’est la passerelle qui garde les connexions ouvertes entre vos messageries et vos modèles locaux. L’assistant ne disparaît pas à chaque commande. Il peut continuer une tâche, gérer plusieurs échanges, attendre une précision, puis reprendre.

C’est là que les agents multi-étapes deviennent vraiment utiles. Un agent peut résumer un document, chercher une information, préparer une réponse, vous demander validation, puis continuer. Ce n’est plus juste une commande isolée. C’est une conversation qui avance.

En automatisation et en IA, le vrai sujet n’est pas toujours le modèle. C’est souvent l’endroit où on le branche. Un très bon assistant coincé dans un outil à part sert moins qu’un assistant correct disponible dans l’application que tout le monde ouvre déjà.

OpenClaw n’est donc pas juste une façon de lancer Ollama. C’est une passerelle persistante entre vos conversations et vos modèles. Les cas d’usage réalistes sont clairs : assistant personnel, bot d’équipe, automatisation conversationnelle, tâches longues en arrière-plan.

Et si votre assistant local restait enfin disponible ?

OpenClaw règle un problème très concret : Ollama est puissant, mais souvent utilisé comme un outil ponctuel. Avec son Gateway persistant, il devient un assistant joignable depuis les messageries que vous utilisez déjà. L’architecture reste lisible : une couche messaging, un démon Gateway, un modèle Ollama local ou cloud. Le vrai choix se joue ensuite sur le contexte, les ressources machine et le besoin de recherche web. Si vous voulez un assistant privé, plus naturel à utiliser, et capable de gérer des tâches en arrière-plan, OpenClaw donne une base solide. Le bénéfice pour vous : moins de friction, plus d’usage réel.

FAQ

• OpenClaw sert à quoi avec Ollama ?
  OpenClaw sert à garder un assistant Ollama disponible en continu. Au lieu de lancer un modèle depuis le terminal pour une seule interaction, vous pouvez lui parler depuis des applications comme WhatsApp, Telegram, Slack, Discord ou iMessage.
• Quel est le rôle du Gateway dans OpenClaw ?
  Le Gateway est le démon qui maintient les connexions, coordonne les messages et permet à l’assistant de fonctionner en arrière-plan. C’est lui qui donne le côté persistant à l’ensemble, surtout pour les tâches multi-étapes.
• OpenClaw fonctionne-t-il seulement avec des modèles locaux ?
  Non. OpenClaw peut s’appuyer sur Ollama avec des modèles locaux ou cloud. Le local est intéressant pour le contrôle et la confidentialité. Le cloud peut être utile pour bénéficier plus simplement de longs contextes ou de fonctions comme la recherche web, selon les usages Ollama disponibles.
• Quels prérequis sont nécessaires pour installer OpenClaw ?
  Il faut prévoir Ollama 0.17 ou plus, Node.js 18 ou plus pour une installation via npm, et une machine adaptée au modèle choisi. La RAM, la VRAM et l’espace disque deviennent importants si vous utilisez de gros modèles ou un contexte long.
• Pourquoi le contexte long est-il important ?
  Un assistant persistant doit suivre des échanges, reprendre des informations et gérer des tâches sur plusieurs étapes. Un contexte long, autour de 64k quand c’est possible, permet de garder plus d’éléments utiles en mémoire pendant l’interaction.

 

 

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. J’accompagne des équipes qui veulent brancher l’IA dans leurs vrais outils, pas juste faire des démos. Avec webAnalyste et Formations Analytics, j’ai travaillé pour des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez mettre en place ce type d’assistant IA dans votre organisation, je peux vous aider à cadrer, automatiser et industrialiser proprement. Contactez-moi.