Comment utiliser OpenClaw avec Ollama en assistant IA local?

OpenClaw sert à transformer Ollama en assistant IA persistant, accessible depuis Telegram, Slack, WhatsApp, Discord ou iMessage. Je vais clarifier l’architecture, les prérequis, le choix des modèles et les réglages utiles pour éviter le setup bancal qui marche cinq minutes puis disparaît.

À quoi sert OpenClaw ?

OpenClaw sert à rendre Ollama disponible en continu dans des applications de messagerie, au lieu de rester coincé dans un terminal ponctuel.

Ollama est très pratique quand on veut faire tourner un modèle d’IA en local, sur sa propre machine ou son propre serveur. On lance une commande, on discute avec le modèle, ça répond vite, les données restent chez vous. Très bien pour tester. Moins bien quand on veut un vrai assistant privé, disponible à tout moment.

Le problème arrive vite. Si vous voulez parler à votre modèle depuis Telegram, Slack, WhatsApp, Discord ou iMessage, il faut quelque chose entre la messagerie et Ollama. Une couche persistante, c’est-à-dire un service qui reste allumé en arrière-plan, écoute les messages, les envoie au modèle, puis renvoie la réponse au bon endroit. Sans ça, vous êtes obligé de revenir au terminal à chaque fois. Et soyons honnête, personne ne fait ça longtemps.

OpenClaw joue ce rôle. C’est un assistant IA personnel qui tourne en arrière-plan et qui connecte vos modèles Ollama, locaux ou cloud, à vos canaux de messagerie. Local veut dire que le modèle tourne chez vous. Cloud veut dire qu’il tourne sur un serveur distant. Dans les deux cas, l’idée est la même : vous gardez un assistant accessible dans les outils que vous utilisez déjà, sans relancer une commande à chaque demande.

Dans un usage business ou perso, l’intérêt est assez concret :

• Vous gardez un assistant privé, avec plus de contrôle sur vos données.
• Vous réduisez votre dépendance aux interfaces web classiques.
• Vous automatisez des échanges simples, comme des réponses, des résumés ou des recherches internes.
• Vous lancez des tâches plus longues sans rester devant une fenêtre de terminal.
• Vous centralisez des demandes venant de plusieurs canaux au même endroit.

J’ai souvent vu des équipes tester un modèle local avec enthousiasme, puis l’abandonner parce que personne n’a envie d’ouvrir un terminal pour lui parler. OpenClaw répond précisément à ce frottement. Il transforme un modèle intéressant en assistant vraiment utilisable au quotidien.

Pour comprendre pourquoi ça tient dans le temps, il faut regarder les trois couches qui composent OpenClaw.

Comment fonctionne l’architecture ?

OpenClaw fonctionne avec trois couches simples, la messagerie, le Gateway persistant et le modèle Ollama. C’est une architecture assez saine, parce qu’elle sépare bien ce que voit l’utilisateur, ce qui orchestre, et ce qui génère la réponse.

La première couche, c’est la messagerie. C’est le canal utilisé par l’utilisateur au quotidien, par exemple Telegram, WhatsApp, Slack, Discord ou iMessage. Le message part de là, comme dans une conversation normale. Vous écrivez une demande, vous envoyez, et OpenClaw récupère ce message depuis le canal configuré.

La deuxième couche, c’est le démon Gateway. Un démon, c’est juste un programme qui tourne en arrière-plan, sans qu’on ait besoin de le relancer à chaque action. Pour moi, c’est vraiment le cœur d’OpenClaw. Il maintient les connexions, coordonne les échanges, relaie les messages et peut orchestrer des tâches en plusieurs étapes. C’est là que ça devient intéressant. Si une tâche prend du temps, ou si elle demande plusieurs allers-retours, le Gateway reste actif et garde le fil. J’ai vu ce genre de logique sauver pas mal de workflows chez des clients, surtout quand on sort du simple “question réponse” et qu’on commence à automatiser des actions.

La troisième couche, c’est la couche modèle. Elle s’appuie sur Ollama, avec un modèle local sur votre machine, ou éventuellement un modèle cloud selon votre configuration. Le Gateway transmet la demande à l’API locale Ollama, récupère la réponse, puis la renvoie vers le canal de messagerie.

Le déroulé complet est très simple. Vous écrivez dans Telegram. OpenClaw reçoit le message. Le Gateway l’envoie à Ollama. Le modèle répond. Le Gateway renvoie la réponse dans Telegram. C’est tout, et c’est justement ce qui rend l’approche facile à comprendre.

Petit point d’historique utile. OpenClaw a été renommé plusieurs fois, avec les anciens noms Clawdbot puis Moltbot. Certains anciens alias de commande restent encore fonctionnels, par exemple :

ollama launch clawdbot

Couche	Rôle	Pourquoi c’est utile
Messagerie	Canal utilisateur comme Telegram, WhatsApp, Slack, Discord ou iMessage.	Vous utilisez un outil déjà connu, sans interface spéciale à apprendre.
Gateway	Service persistant qui reçoit, relaie, coordonne et orchestre les échanges.	Il garde le fil, même sur des tâches longues ou multi-étapes.
Modèle	Ollama exécute le modèle local ou cloud et produit la réponse.	Vous gardez la main sur le modèle, la confidentialité et les performances.

Cette architecture reste simple, mais elle impose quand même quelques prérequis, surtout sur la longueur de contexte et la mémoire disponible.

Quels prérequis faut-il prévoir ?

Il faut prévoir Ollama 0.17 ou plus, Node.js 18 ou plus, assez de RAM, assez de VRAM si les modèles tournent en local, et surtout une longueur de contexte adaptée.

La longueur de contexte, c’est le volume d’informations que le modèle peut garder “sous les yeux” pendant qu’il répond. Avec OpenClaw, c’est central, parce qu’un assistant agentique ne fait pas juste une réponse simple. Il peut lire, raisonner, appeler un outil, reprendre un résultat, corriger une action, puis continuer.

Une petite fenêtre de contexte peut suffire pour une question courte. Mais dès qu’on enchaîne plusieurs actions, ou qu’on garde des fichiers, des consignes et des résultats intermédiaires en mémoire, ça coince vite.

Par défaut, Ollama adapte le contexte à la VRAM disponible :

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

Dans la pratique, je vise souvent 64k pour des tâches multi-étapes confortables, quand le modèle et la machine le permettent. Ça laisse de l’air à OpenClaw sans tout casser au bout de trois actions.

Côté logiciel, je vérifie toujours ces points avant de perdre du temps ailleurs :

ollama --version
ollama signin

• Utiliser Ollama 0.17 ou plus.
• Installer Node.js 18 ou plus, parce qu’OpenClaw s’appuie sur npm.
• Se connecter avec ollama signin si vous voulez utiliser des modèles cloud ou la recherche web locale associée.

Côté matériel, il faut rester simple mais lucide :

• Un système compatible avec Ollama et Node.js.
• Assez de RAM pour que la machine ne s’écroule pas dès qu’on ouvre deux outils.
• De la VRAM adaptée si vous exécutez les modèles en local.
• De l’espace disque pour stocker les modèles, qui peuvent vite prendre de la place.

Le cloud simplifie beaucoup la partie contexte et mémoire. Le local donne plus de contrôle, plus de confidentialité, et moins de dépendance à un service externe. J’ai souvent vu le même problème chez des clients : l’installation marche, mais ils choisissent un modèle local trop ambitieux pour une machine trop juste. Résultat, c’est lent, frustrant, et l’équipe finit par penser que l’outil est mauvais. Alors que le souci, c’est juste le mauvais couple modèle / machine.

Cas	Approche recommandée
Petit poste local	Utiliser un modèle léger, accepter un contexte plus court, éviter les workflows trop longs.
Machine GPU solide	Faire tourner les modèles en local, viser un contexte large si le modèle le supporte.
Usage cloud	Déléguer la mémoire et le contexte au cloud, idéal pour aller vite sans régler toute l’infra.
Usage privé sensible	Privilégier le local, choisir un modèle adapté à la VRAM, limiter les dépendances externes.

Quel modèle Ollama choisir ?

Le bon modèle dépend surtout du besoin de confidentialité, de la puissance disponible et de la longueur de contexte attendue.

Si je veux une configuration simple avec OpenClaw, je pars souvent sur un modèle cloud Ollama. Les bons candidats sont kimi-k2.5:cloud, qwen3.5:cloud, minimax-m2.7:cloud et glm-5.1:cloud. Ils sont pratiques parce qu’ils gèrent automatiquement un contexte long, c’est-à-dire la quantité d’informations que le modèle peut garder en mémoire pendant l’échange. Et surtout, ils incluent la recherche web. Pour un assistant qui doit répondre à des questions récentes, vérifier une info, ou s’appuyer sur de la documentation à jour, ça change tout.

Si je veux rester en local, je regarde plutôt qwen3-coder pour un usage orienté code, avec environ 25 GB de VRAM. La VRAM, c’est la mémoire vidéo de la carte graphique. C’est elle qui encaisse une grosse partie du modèle. Pour une machine un peu moins musclée, gemma4 est intéressant avec environ 16 GB de VRAM. Là, l’idée est claire : je gagne en confidentialité et en contrôle, mais je paie ça avec des contraintes matérielles plus fortes.

Modèle	Type	Usage conseillé	Point d’attention
kimi-k2.5:cloud	Cloud	Assistant général avec contexte long et recherche web.	L’exécution n’est pas strictement locale.
qwen3.5:cloud	Cloud	Usage polyvalent, simple à configurer avec OpenClaw.	Il faut accepter le passage par le cloud.
minimax-m2.7:cloud	Cloud	Demandes documentées, réponses longues, recherche web incluse.	Moins adapté si la confidentialité maximale est prioritaire.
glm-5.1:cloud	Cloud	Assistant avec contexte complet géré automatiquement.	Dépendance à une exécution distante.
qwen3-coder	Local	Code, scripts, automatisations, raisonnement technique.	Environ 25 GB de VRAM recommandés.
gemma4	Local	Assistant local plus léger, bon équilibre contrôle/performance.	Environ 16 GB de VRAM recommandés.

Le compromis est assez simple. Le local donne plus de maîtrise et limite l’exposition des données, mais il demande une machine solide. Le cloud réduit les contraintes matérielles et apporte la recherche web plus facilement, mais il faut accepter que tout ne tourne plus chez vous.

Une fois le modèle choisi, le vrai enjeu est de garder OpenClaw stable en arrière-plan et connecté au bon canal de messagerie.

Comment le déployer proprement ?

Le déploiement propre consiste à lancer OpenClaw comme un service persistant, connecter le canal voulu, régler le contexte, puis vérifier que les messages circulent bien jusqu’à Ollama.

Je vois souvent l’erreur inverse chez les clients : tout marche dans un terminal pendant 10 minutes, puis plus rien dès que la machine redémarre ou que la session se ferme. Là, on n’a pas vraiment un assistant IA local. On a juste une démo fragile.

Le parcours reste assez simple. Je pars d’abord d’une installation Ollama propre, avec la logique simplifiée arrivée autour d’Ollama 0.17. L’idée, c’est d’éviter les bricolages inutiles : Ollama gère le modèle local, OpenClaw sert de Gateway, c’est-à-dire la passerelle entre vos applications de messagerie et le modèle.

Ensuite, je lance OpenClaw via Ollama, je choisis le modèle, puis je règle la longueur de contexte. Le contexte, c’est la quantité d’informations que le modèle peut garder en tête dans une conversation. Trop court, il oublie vite. Trop long, ça peut consommer plus de ressources. Je préfère commencer cohérent, puis ajuster après quelques vrais échanges.

Pour le premier canal, je prends souvent Telegram. C’est simple à valider avant d’étendre à Slack, Discord, WhatsApp ou iMessage. Une fois Telegram connecté, je teste depuis l’application de messagerie, pas seulement depuis l’interface locale. C’est le seul test qui compte vraiment : est-ce que mon message part, arrive au Gateway, passe dans Ollama, puis revient correctement ?

Si vous avez besoin d’un assistant disponible en continu, le mode headless avec Docker devient intéressant. Headless veut juste dire sans interface graphique. OpenClaw tourne sur une machine ou un serveur qui reste actif, même quand personne n’est connecté à l’écran. C’est beaucoup plus propre pour un usage quotidien.

Petit point de vigilance : si le Gateway tombe, l’assistant ne répond plus, même si Ollama fonctionne très bien. Il faut donc penser stabilité du service, logs, redémarrage et environnement d’exécution. Pas besoin de sur-ingénierie, mais il faut éviter le montage qui dépend d’un terminal ouvert par hasard.

• Version Ollama vérifiée.
• Node.js présent.
• Compte Ollama connecté si cloud ou recherche web.
• Modèle choisi.
• Contexte cohérent.
• Canal connecté, par exemple Telegram.
• Test de message réussi depuis l’application.
• Déploiement headless avec Docker si besoin.

Le bon setup n’est pas forcément le plus puissant, c’est celui qui reste disponible quand vous en avez besoin.

Et si votre assistant IA restait enfin disponible ?

OpenClaw comble un trou assez concret : Ollama est utile, mais il devient vraiment pratique quand il reste accessible depuis vos messageries. L’architecture est simple à comprendre : un canal de discussion, un Gateway persistant, puis un modèle Ollama local ou cloud. Le choix du modèle dépend de votre machine, de votre besoin de confidentialité et de la longueur de contexte attendue. Pour des tâches multi-étapes, ce contexte compte beaucoup. Pour un usage stable, le déploiement headless avec Docker a du sens. Le bénéfice pour vous est clair : un assistant IA privé, joignable, et réellement utilisable au quotidien.

FAQ

• OpenClaw sert à quoi avec Ollama ?
  OpenClaw sert à rendre Ollama accessible depuis des applications de messagerie comme Telegram, Slack, WhatsApp, Discord ou iMessage. Au lieu d’utiliser Ollama uniquement dans un terminal, vous obtenez un assistant IA persistant, capable de recevoir vos messages, de les envoyer au modèle et de vous répondre dans le canal choisi.
• OpenClaw fonctionne-t-il uniquement avec des modèles locaux ?
  Non. OpenClaw peut connecter Ollama à des modèles locaux ou cloud. Le local est intéressant pour garder plus de contrôle et de confidentialité. Le cloud simplifie la gestion du contexte, réduit les contraintes matérielles et peut inclure la recherche web selon les modèles utilisés.
• Pourquoi la longueur de contexte est importante ?
  La longueur de contexte détermine la quantité d’informations que le modèle peut garder en mémoire pendant l’échange. Pour des réponses simples, un petit contexte peut suffire. Pour des agents multi-étapes, 64k est plus confortable quand c’est possible. Ollama ajuste aussi des valeurs par défaut selon la VRAM disponible.
• Quels modèles Ollama utiliser avec OpenClaw ?
  Pour le cloud, les modèles cités sont kimi-k2.5:cloud, qwen3.5:cloud, minimax-m2.7:cloud et glm-5.1:cloud. Pour le local, qwen3-coder est adapté à un usage code avec environ 25 GB de VRAM, tandis que gemma4 demande environ 16 GB de VRAM. Le choix dépend surtout de votre matériel et de votre besoin de confidentialité.
• Peut-on faire tourner OpenClaw sans interface graphique ?
  Oui, l’article prévoit un déploiement headless avec Docker. C’est pertinent si vous voulez un assistant toujours disponible sur une machine ou un serveur. Le point clé reste la stabilité du Gateway, parce que c’est lui qui maintient les connexions entre vos messageries et Ollama.

 

 

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 rendre leurs outils IA vraiment exploitables, pas juste faire une démo sympa. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. J’ai travaillé avec des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez connecter l’IA à vos process business, contactez-moi.