Comment lancer OpenClaw avec Ollama en privé ?

En reliant OpenClaw à Ollama, je fais tourner un assistant IA privé, persistant, accessible depuis WhatsApp, Telegram, Slack, Discord ou iMessage. Le vrai sujet, c’est l’architecture Gateway, le bon modèle, la longueur de contexte et un déploiement propre, surtout si vous voulez éviter le bricolage fragile.

À quoi sert OpenClaw avec Ollama ?

OpenClaw sert à une chose très simple : transformer Ollama en assistant IA personnel qui reste disponible, au lieu d’un modèle qu’on lance de temps en temps dans un terminal.

Je vois souvent le même scénario chez les clients. Quelqu’un installe Ollama en local, lance un modèle avec une commande, teste deux trois prompts, tout marche. Puis ça reste coincé dans une fenêtre noire, sur une machine précise, avec une usage de geek. Résultat : l’équipe n’adopte pas vraiment l’outil. Pas parce que l’IA est mauvaise. Parce qu’elle n’est pas là où les gens travaillent déjà.

OpenClaw ajoute une couche opérationnelle au-dessus d’Ollama. Le cœur du système, c’est un démon central appelé Gateway. Un démon, c’est juste un programme qui tourne en arrière-plan et reste actif sur la machine. Il attend les messages, les route, appelle le bon modèle, puis renvoie la réponse.

Concrètement, ça permet de parler à votre IA depuis des apps déjà utilisées au quotidien :

• WhatsApp, pour des échanges rapides sur mobile.
• Telegram, souvent pratique pour les équipes techniques.
• Slack, si votre boîte vit déjà dedans.
• Discord, utile pour des communautés ou des équipes produit.
• IMessage, surtout dans des environnements très Apple.

OpenClaw reçoit le message, le transmet à un modèle Ollama local ou cloud, puis renvoie la réponse dans la conversation. L’utilisateur n’a pas besoin de savoir quel modèle tourne, où il tourne, ni quelle commande lancer. C’est ça qui change tout.

L’intérêt business est assez clair. Je garde le contrôle sur l’infra, je réduis ma dépendance aux interfaces SaaS fermées, je centralise les échanges, et je rends l’IA disponible dans les canaux où les équipes sont déjà présentes. C’est moins spectaculaire qu’une démo en terminal, mais beaucoup plus utile au quotidien.

Le projet a été créé par Peter Steinberger. Il a d’abord existé sous les noms Clawdbot et Moltbot, avant d’être renommé OpenClaw en 2026. Et depuis Ollama 0.17, l’installation est devenue plus simple grâce à ollama launch, ce qui évite pas mal de bricolage.

Avant de parler installation, il faut quand même comprendre l’architecture. Sinon on branche des services au hasard, et c’est là que les ennuis commencent.

Comment fonctionne l’architecture OpenClaw ?

OpenClaw, je le vois comme une architecture en trois couches très simples. Une couche pour recevoir les messages, une couche Gateway pour faire tourner l’orchestration, puis une couche modèle avec Ollama pour répondre et raisonner. Ce découpage est important, parce que l’objectif n’est pas de discuter avec un terminal. L’objectif, c’est de parler à votre assistant depuis l’outil que vous utilisez déjà.

La première couche, c’est la messagerie. WhatsApp peut passer par Baileys, une librairie qui permet de se connecter à WhatsApp Web côté serveur. Telegram peut passer par la Bot API, l’interface officielle pour créer un bot Telegram. Slack, Discord ou iMessage peuvent aussi servir de portes d’entrée. Dans tous les cas, le principe reste le même : vous envoyez un message depuis votre canal habituel, et OpenClaw le récupère.

La deuxième couche, c’est le Gateway. C’est le démon persistant, donc un programme qui tourne en continu en arrière-plan. C’est lui qui garde les connexions ouvertes, reçoit les messages, gère le contexte de conversation, orchestre les tâches en plusieurs étapes et relaie les requêtes vers le modèle. C’est là que la vraie différence se joue avec un simple chatbot dans un terminal. Un terminal attend que vous soyez là. Le Gateway, lui, reste disponible, écoute plusieurs canaux, et peut coordonner des actions plus longues. J’ai déjà vu ce point débloquer des cas très concrets chez des clients, par exemple traiter une demande WhatsApp, vérifier une donnée dans un outil interne, puis renvoyer une réponse propre sans intervention humaine.

La troisième couche, c’est Ollama. Ollama sert à faire tourner le modèle de langage. Il peut tourner en local, sur votre machine ou votre serveur, ce qui maximise la confidentialité parce que les données ne sortent pas. Il peut aussi tourner dans le cloud si vous voulez plus de simplicité, plus de puissance, ou moins de contraintes matérielles. C’est exactement l’arbitrage qu’on retrouve ensuite : confidentialité, coût, vitesse, mémoire GPU, maintenance.

Couche messagerie	Rôle : Recevoir les messages depuis les outils du quotidien.	Exemples : WhatsApp avec Baileys, Telegram avec Bot API, Slack, Discord, iMessage.	Point d’attention : Chaque canal a ses limites, ses règles et parfois ses fragilités.
Couche Gateway	Rôle : Garder les connexions ouvertes, gérer le contexte et orchestrer les actions.	Exemples : Démon persistant, routage des messages, tâches multi-étapes.	Point d’attention : C’est la pièce critique à surveiller, logger et sécuriser.
Couche modèle	Rôle : Générer les réponses et raisonner sur les demandes.	Exemples : Ollama en local ou dans le cloud.	Point d’attention : Le choix dépend du niveau de confidentialité attendu et du matériel disponible.

Quelle machine faut-il prévoir ?

Je dimensionne surtout la machine selon trois choses : la longueur de contexte que j’attends, la taille du modèle que je veux utiliser, et le choix local ou cloud. Il ne faut pas forcément une grosse station GPU. Pour tester OpenClaw avec Ollama, une machine correcte peut suffire. Pour faire tourner un gros modèle local avec de longues conversations, là oui, la VRAM devient vite le sujet.

La longueur de contexte, c’est la quantité d’information que le modèle peut garder “en tête” pendant une discussion ou une tâche. Plus elle est grande, plus l’assistant peut suivre un historique long, manipuler plusieurs fichiers, ou enchaîner des étapes sans perdre le fil. Pour un assistant personnel sérieux, je trouve que 64k est une cible confortable. Pas obligatoire, mais agréable si vous voulez faire autre chose que trois questions rapides.

Avec Ollama, il y a une règle pratique à garder en tête. Ce n’est pas une promesse magique, parce que ça dépend du modèle, de sa quantification et de votre configuration, mais ça donne un bon repère :

• Sous 24 GB de VRAM, Ollama tourne souvent autour de 4k de contexte par défaut.
• Entre 24 et 48 GB de VRAM, on peut viser environ 32k.
• Au-delà de 48 GB de VRAM, certains setups peuvent monter jusqu’à 256k.

En logiciel, je pars sur Ollama 0.17 ou plus, Node.js 18 ou plus, et un compte Ollama si vous utilisez des modèles cloud ou la recherche web. La recherche web est pratique quand l’assistant doit compléter ses réponses avec des infos actuelles. Mais elle ajoute aussi une dépendance externe. Pour certains clients, c’est acceptable. Pour d’autres, surtout quand il y a des données sensibles, on garde tout en local.

Élément	Minimum	Recommandé
Système d’exploitation	Un OS compatible avec Ollama et Node.js	Linux, macOS ou Windows bien à jour
RAM	Assez pour faire tourner OpenClaw, Ollama et le système	Une marge confortable si vous manipulez plusieurs tâches ou fichiers
VRAM pour modèles locaux	Dépend fortement du modèle et du contexte visé	Plus de VRAM si vous voulez de gros modèles ou un contexte long
Disque	De l’espace pour OpenClaw et les modèles	Un SSD avec de la marge, surtout si vous testez plusieurs modèles
Version Ollama	Ollama 0.17 ou plus	Dernière version stable
Version Node.js	Node.js 18 ou plus	Dernière version LTS

Une fois le matériel cadré, le vrai choix devient plus simple : est-ce que je veux un modèle local, avec plus de contrôle, ou un modèle cloud, avec moins de contraintes machine.

Quel modèle Ollama choisir ?

Le bon modèle Ollama, ce n’est pas “le plus gros” ou “le plus connu”. C’est celui qui colle à votre niveau de confidentialité, à votre VRAM, au contexte dont OpenClaw a besoin, et à votre tolérance à la latence. Si l’assistant met 20 secondes à répondre, personne ne l’utilisera, même si le modèle est excellent sur le papier.

Je privilégie le local quand les conversations sont sensibles, quand l’entreprise veut garder la donnée sur sa machine, ou quand l’assistant doit rester maîtrisé techniquement. Là, il faut regarder quatre choses très concrètes : la VRAM, donc la mémoire de votre carte graphique, la RAM de la machine, l’espace disque, et le contexte utile. Le contexte, c’est la quantité de texte que le modèle peut garder en tête pendant une conversation. Plus OpenClaw doit analyser de longs documents ou de longues discussions, plus ce point compte.

Je retiens le cloud quand on veut aller vite, tester sans gros matériel, accéder plus facilement à de bons modèles, ou activer la recherche web via un compte Ollama. C’est pratique pour démarrer. Mais ça ajoute une dépendance externe, et ce n’est pas neutre si vos prompts contiennent des données sensibles.

• Confidentialité : Local si les données ne doivent pas sortir de votre environnement.
• Performance : Cloud si votre machine est trop limitée ou si vous voulez une réponse fluide tout de suite.
• Longueur de contexte : Choisissez un modèle capable de tenir vos vrais documents, pas juste une démo courte.
• Coût d’infrastructure : Local si vous avez déjà le matériel, cloud si vous ne voulez pas investir maintenant.
• Simplicité d’exploitation : Cloud pour tester vite, local pour garder la main sur toute la chaîne.
• Besoin de recherche web : Cloud si vous voulez l’activer simplement avec Ollama.

Petit retour terrain : en projet client, le plus mauvais choix n’est pas toujours un petit modèle. C’est souvent un modèle trop lourd, que personne n’arrive à faire tourner correctement, avec une latence pénible et des réglages que l’équipe ne maîtrise pas.

Usage	Recommandation	Raison
Usage personnel confidentiel	Local	Les données restent sur votre machine.
Assistant d’équipe	Local ou cloud	Local si données sensibles, cloud si priorité à la simplicité.
Prototype rapide	Cloud	Vous validez l’usage sans acheter de GPU.
Assistant avec recherche web	Cloud	L’intégration via un compte Ollama est plus directe.
Machine sans GPU puissant	Cloud ou petit modèle local	Un modèle léger sera plus exploitable qu’un gros modèle inutilisable.

Comment le déployer sans interface graphique ?

Quand je veux faire tourner OpenClaw sans écran, sans navigateur ouvert, et sans bricolage, je pars sur un déploiement headless en Docker. C’est le plus propre pour un serveur ou une machine dédiée. Docker permet de figer le lancement, les variables d’environnement, les redémarrages, les volumes, les logs, et surtout d’éviter le “ça marche sur ma machine”.

Le principe reste simple. Ollama fournit les modèles en local. OpenClaw Gateway tourne comme un service persistant. Les connecteurs de messagerie restent ouverts pour recevoir et envoyer les messages. La configuration décide du modèle utilisé, de la longueur de contexte, des canaux actifs, et éventuellement de la recherche web.

Dans la pratique, je vérifie d’abord les prérequis. Ollama doit être en version 0.17 ou plus. Si OpenClaw Gateway a besoin de Node.js côté serveur, je prépare Node.js 18 ou plus. Ensuite je connecte le canal de messagerie voulu, par exemple un connecteur chat, un webhook, ou une intégration compatible. Là, il faut choisir clairement où tourne l’intelligence : modèle local via Ollama, ou modèle cloud si vous acceptez que certaines requêtes sortent de votre infra.

Je règle ensuite le contexte. Le contexte, c’est la quantité d’informations que le modèle peut garder en mémoire dans une conversation. Plus il est long, plus ça consomme de RAM ou de VRAM. J’ai déjà vu un client mettre le maximum “au cas où”, puis se plaindre que tout rame. Mieux vaut tester avec de vraies conversations. Même chose pour la recherche web : je l’active seulement si le besoin est clair, parce qu’elle change le niveau d’exposition des données.

Quelques points à surveiller avant de laisser tourner ça en continu :

• Sécuriser les tokens de messagerie, parce qu’un token volé donne souvent accès au canal complet.
• Contrôler l’accès à la machine, avec SSH, pare-feu, utilisateurs limités, et pas de ports ouverts inutilement.
• Surveiller la consommation VRAM/RAM, surtout avec les gros modèles et les longs contextes.
• Tester le contexte réel, pas juste une démo de trois messages.
• Documenter les canaux connectés, pour savoir qui peut parler à l’assistant et par où.
• Prévoir les redémarrages, parce qu’un service utile doit repartir proprement après crash ou reboot.

Un assistant privé n’est privé que si l’infrastructure, les accès et les canaux le sont aussi. Le modèle local ne suffit pas à lui seul.

Point de contrôle	Statut attendu
Canal connecté	Testé avec un vrai message entrant et sortant
Modèle choisi	Validé selon qualité, vitesse et consommation
Contexte configuré	Réglé sur un volume réaliste
Recherche web validée	Activée seulement si nécessaire
Logs surveillés	Consultables sans interface graphique
Redémarrage testé	Gateway relancé automatiquement après reboot

Et si votre assistant IA vivait enfin dans vos outils ?

OpenClaw change surtout la manière d’utiliser Ollama. Au lieu d’avoir un modèle local qu’on lance à la main dans un terminal, on obtient un assistant persistant, connecté aux messageries, piloté par un Gateway et adaptable selon le niveau de confidentialité voulu. Le point clé, c’est de ne pas partir trop vite : contexte, VRAM, modèle local ou cloud, recherche web, déploiement Docker, tout ça doit être cohérent. Bien configuré, OpenClaw devient une vraie interface IA de travail. Le bénéfice pour vous est simple : une IA plus accessible, plus privée, et mieux intégrée à votre quotidien.

FAQ

• OpenClaw remplace-t-il Ollama ?
  Non, OpenClaw ne remplace pas Ollama. Il s’appuie dessus. Ollama fait tourner les modèles, en local ou dans le cloud, et OpenClaw ajoute la couche assistant persistant avec le Gateway et les connexions aux messageries.
• Pourquoi utiliser OpenClaw plutôt qu’un terminal Ollama ?
  Parce qu’un terminal reste ponctuel. OpenClaw garde un service actif, connecté à WhatsApp, Telegram, Slack, Discord ou iMessage. C’est beaucoup plus naturel si vous voulez un assistant disponible dans vos outils habituels.
• Faut-il une grosse carte graphique pour utiliser OpenClaw ?
  Pas forcément. Si vous utilisez des modèles cloud, la contrainte matérielle baisse. Pour les modèles locaux, la VRAM devient importante, surtout si vous voulez une grande longueur de contexte. Ollama adapte aussi le contexte par défaut selon la VRAM disponible.
• À quoi sert la longueur de contexte dans OpenClaw ?
  Elle détermine la quantité d’information que le modèle peut garder en mémoire pendant une conversation ou une tâche. Pour un assistant qui gère des échanges longs ou des actions multi-étapes, viser un contexte confortable, par exemple 64k, change vraiment l’expérience.
• OpenClaw est-il vraiment privé ?
  Il peut l’être si vous faites tourner les modèles localement et si votre machine, vos tokens et vos canaux de messagerie sont bien sécurisés. Si vous activez des modèles cloud ou la recherche web, vous gagnez en simplicité mais vous ajoutez une dépendance externe.

 

 

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 passer de l’expérimentation IA au vrai système exploitable, propre, maintenable et utile. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez cadrer ou déployer ce type d’assistant IA dans votre business, contactez-moi.