Faire tourner OpenClaw sur un Mac Mini n’est ni le hack magique vendu sur YouTube, ni un caprice de geek. C’est un choix d’infrastructure qui se justifie dans certains cas précis et qui se transforme en gouffre dans d’autres. Le problème, c’est que la quasi-totalité des guides publiés depuis janvier 2026 se contentent de dérouler un tutoriel d’installation sans jamais poser la question qui compte : est-ce que le hardware choisi supporte réellement la charge prévue sur la durée ? Un Mac Mini M4 à 599 € avec 16 Go de RAM ne remplit pas du tout le même rôle qu’un M4 Pro à 64 Go. Et entre les deux, il y a un écart que la plupart des acheteurs découvrent trop tard, quand Ollama commence à swapper et que l’agent répond en 45 secondes. Cet article détaille configuration par configuration, profil par profil, ce qui fonctionne et ce qui relève du gaspillage.

Un Mac Mini est-il réellement supérieur à un VPS pour OpenClaw ?

La réponse dépend de ce qu’on attend d’OpenClaw. Pour un agent connecté à des API cloud, un VPS à 8 €/mois fait le travail. Pour un assistant privé avec inférence locale, le Mac Mini n’a pas d’équivalent à ce prix.

Coût total sur 24 mois : hardware amorti vs abonnements API récurrents

Un VPS correct pour OpenClaw (2 vCPU, 8 Go de RAM, Hetzner ou équivalent) coûte entre 8 et 20 €/mois. Sur 24 mois, on atteint 192 à 480 € en hébergement seul. Ajoutez les tokens API : un usage modéré avec Claude ou GPT consomme entre 20 et 100 € par mois selon l’intensité des tâches. Le total réaliste sur deux ans se situe entre 670 et 2 800 €, sans jamais posséder le hardware.

Un Mac Mini M4 16 Go coûte 599 €. Un M4 24 Go, 699 €. Un M4 Pro 64 Go, environ 2 000 €. L’électricité d’un Mac Mini en fonctionnement continu tourne autour de 4 à 7 € par mois (20 W en charge moyenne). Si vous faites tourner un modèle local via Ollama et supprimez les API cloud, le coût mensuel post-achat tombe à zéro en tokens. Le point de bascule se situe autour du 12e mois pour la plupart des configurations : à partir de là, le Mac Mini coûte moins cher qu’un VPS avec API. Mais ce calcul ne tient que si vous utilisez effectivement l’inférence locale. Un Mac Mini à 599 € qui pointe vers Claude en OAuth, c’est un VPS de luxe avec un prix d’entrée six fois plus élevé.

Latence et fiabilité : pourquoi le « chez soi » bat souvent le cloud en usage quotidien

La latence d’un appel API cloud (Claude, GPT) oscille entre 300 ms et 2 secondes pour le premier token, selon la charge serveur et la taille du contexte. Sur un modèle local de 14 à 32B tournant en mémoire unifiée Apple Silicon, le premier token arrive en 50 à 200 ms. Pour un agent qui enchaîne des appels d’outils (recherche web, lecture de fichiers, exécution de commandes), cette différence se multiplie à chaque étape de la chaîne. Un workflow de 8 appels successifs peut prendre 12 secondes en cloud et 3 secondes en local.

L’autre point rarement mentionné : la fiabilité. Un VPS dépend de la disponibilité du provider, de sa connectivité réseau et de la stabilité de l’API du LLM choisi. Un Mac Mini branché sur un onduleur, connecté en Ethernet et configuré avec pmset pour redémarrer après coupure, ne dépend de personne. Les rate limits d’Anthropic ou d’OpenAI n’existent plus quand l’inférence est locale.

Vie privée : exécuter Ollama en local change-t-il réellement le modèle de risque ?

L’inférence locale via Ollama signifie qu’aucun prompt, aucune réponse et aucun fichier ne quitte votre réseau. C’est un fait technique, pas un argument marketing. Mais il faut nuancer : OpenClaw lui-même reste un agent avec accès shell, accès fichiers et connexion à vos canaux de messagerie. Le risque ne vient pas du LLM cloud qui « lirait » vos données. Il vient de l’agent qui a les clés de votre système.

En janvier 2026, des chercheurs en sécurité ont découvert 42 665 instances OpenClaw exposées publiquement via Shodan. 93 % d’entre elles n’avaient aucune authentification. La vulnérabilité CVE-2026-25253 permettait une exécution de code à distance en un clic. Le LLM local ne protège de rien si la gateway écoute sur 0.0.0.0 sans mot de passe. La vie privée se joue autant dans la configuration réseau que dans le choix du provider d’inférence.

M1, M2, M4 : faut-il vraiment viser la dernière génération ?

La génération de la puce compte moins que ce que la plupart des guides laissent croire. Ce qui détermine l’expérience avec OpenClaw et un modèle local, c’est la mémoire disponible et la bande passante mémoire, pas le nombre de cœurs CPU.

Node.js et charges OpenClaw : le CPU est-il un faux débat ?

OpenClaw tourne sur Node.js (version 22 minimum). La gateway elle-même consomme entre 2 et 3 Go de RAM et sollicite très peu le CPU en usage normal. Le processus passe l’essentiel de son temps à attendre : attendre la réponse du LLM, attendre le retour d’un outil, attendre un message entrant. Un M1 de 2020 fait tourner la gateway OpenClaw aussi fluidement qu’un M4 de 2024.

Le CPU entre en jeu uniquement si vous faites de l’inférence locale via Ollama. Mais même dans ce cas, la génération de tokens sur Apple Silicon est limitée par la bande passante mémoire, pas par la fréquence CPU. Passer d’un M2 à un M4 pour « aller plus vite » sur OpenClaw sans changer la RAM, c’est optimiser le mauvais paramètre. Le gain se mesure en single digits de pourcentage, pas en multiples.

Bande passante mémoire : le vrai facteur limitant pour les modèles locaux

La génération de tokens par un LLM local est un processus memory-bound. Chaque token généré nécessite de lire l’intégralité des poids du modèle depuis la mémoire. La vitesse de cette lecture dépend directement de la bande passante mémoire unifiée.

Les chiffres Apple sont explicites. Le M1 base offre 68 Go/s. Le M2 base, 100 Go/s. Le M4 base, 120 Go/s. Le M4 Pro monte à 273 Go/s. Un modèle de 14B paramètres quantifié en Q4 (environ 8 Go de poids) sur un M1 génère autour de 8 tokens/seconde. Le même modèle sur un M4 atteint 12 à 15 tokens/seconde. Sur un M4 Pro : 25 à 30 tokens/seconde. La bande passante mémoire est le facteur qui sépare un assistant utilisable d’un assistant frustrant.

Pourquoi un M2 24 Go peut être plus cohérent qu’un M4 16 Go

Un M4 16 Go fait tourner OpenClaw seul sans problème. Ajoutez Ollama avec un modèle de 8B quantifié, et il reste environ 5 à 6 Go de marge. C’est jouable, mais serré. Dès que le contexte s’allonge (OpenClaw charge un prompt système de 17 000 tokens avant même votre premier message), le KV cache gonfle et la mémoire disponible fond. Le swap s’active, les temps de réponse doublent ou triplent.

Un M2 24 Go dispose de 8 Go de marge supplémentaire. Sa bande passante mémoire est inférieure (100 Go/s contre 120 Go/s), mais il ne swappe pas. Un modèle qui tourne intégralement en mémoire sur un M2 sera plus rapide et plus stable qu’un modèle qui déborde sur le SSD d’un M4. Le marché de l’occasion rend ce choix encore plus pertinent : un Mac Mini M2 24 Go se trouve aujourd’hui autour de 500 à 600 €, contre 699 € pour le M4 24 Go neuf.

16 Go suffisent-ils ou est-ce une fausse économie ?

C’est la question la plus posée et la plus mal répondue. 16 Go suffisent pour un cas d’usage. Pas pour celui que la majorité des acheteurs ont en tête.

2 Go pour OpenClaw… et le reste disparaît vite avec Ollama

La gateway OpenClaw consomme entre 2 et 3 Go de RAM en fonctionnement. macOS en réserve environ 4 à 5 Go pour le système, Spotlight, les services réseau et la gestion mémoire. Sur 16 Go, il reste donc 8 à 10 Go de mémoire réellement disponible pour autre chose. C’est suffisant pour utiliser OpenClaw avec un LLM cloud (Claude, GPT via API). L’agent fonctionne, les outils répondent, tout roule.

Le problème surgit quand on installe Ollama. Un modèle de 7B en Q4 occupe environ 5 Go en mémoire. Un modèle de 14B, environ 8 à 10 Go. Ajoutez le KV cache pour un contexte de 64K tokens (le minimum recommandé par Ollama pour OpenClaw) et les 8 Go restants explosent. Le système passe en swap, le SSD prend le relais, et chaque token met des secondes à sortir. Ce n’est pas un bug : c’est la conséquence mécanique d’une RAM insuffisante pour la charge demandée.

24 Go : le véritable point d’équilibre pour éviter le swap mémoire

Avec 24 Go, la situation change de nature. Après les 5 Go système et les 3 Go d’OpenClaw, il reste environ 16 Go pour Ollama. Un modèle de 8B tourne confortablement avec de la marge pour le KV cache. Un modèle de 14B passe en Q4 sans swapper. C’est le seuil à partir duquel l’inférence locale devient réellement exploitable au quotidien, pas seulement en démo.

Le Mac Mini M4 24 Go à 699 € est probablement le meilleur rapport qualité/prix pour un usage OpenClaw avec modèle local léger. Le M2 24 Go d’occasion, entre 500 et 600 €, représente l’alternative la plus rationnelle pour qui accepte une bande passante mémoire 20 % inférieure.

32 à 64 Go : à partir de quand l’investissement devient rationnel ?

Le palier 32 Go (M4 Pro à environ 1 200 €) ouvre l’accès aux modèles de 24 à 32B paramètres, comme Qwen 2.5 Coder 32B ou Devstral 24B. Ce sont les premiers modèles locaux capables de gérer des tâches agentiques complexes (chaînes d’outils, raisonnement multi-étapes) sans halluciner systématiquement les appels de fonctions. À ce niveau de RAM, le cloud devient optionnel pour 80 % des usages courants.

Le palier 64 Go (M4 Pro à environ 2 000 €) permet de faire tourner deux modèles simultanément ou un seul modèle large avec un contexte étendu. C’est la configuration « zéro cloud » pour ceux qui refusent toute dépendance externe. L’investissement ne se justifie que si le coût évité en API cloud dépasse 80 à 100 €/mois, c’est-à-dire pour un usage intensif, multi-agents ou professionnel.

Mac Mini ou Raspberry Pi : l’option low-cost est-elle un piège ?

Le Raspberry Pi coûte dix fois moins cher qu’un Mac Mini. Mais la question n’est pas le prix d’achat. C’est ce que la machine peut réellement faire tourner.

Tokens/seconde : le seuil minimal pour une IA exploitable

Un agent IA interactif devient pénible en dessous de 5 tokens par seconde. En dessous de 3 tokens/seconde, l’expérience ressemble à une conversation par courrier postal. Sur un Raspberry Pi 5 avec Ollama et un modèle de 3B paramètres, les tests montrent des temps de réponse de 10 à 30 secondes par réponse complète. Un modèle de 7B ne tient pas en mémoire sur 8 Go avec l’OS et OpenClaw déjà chargés.

Sur un Mac Mini M4 base, le même modèle de 3B répond en moins de 2 secondes. Un modèle de 14B répond en 5 à 8 secondes. La différence n’est pas incrémentale : elle change fondamentalement ce que l’agent peut faire. Un agent qui met 25 secondes à répondre ne peut pas enchaîner des tâches en cascade. Un agent qui répond en 3 secondes, si.

API cloud obligatoire sur Pi : dépendance masquée

Le guide officiel Raspberry Pi et la plupart des tutoriels communautaires recommandent d’utiliser le Pi comme runtime pour OpenClaw et de pointer l’inférence vers un LLM cloud. C’est honnête, et ça fonctionne. Mais cela annule l’argument principal du self-hosting : l’indépendance. Votre agent tourne sur votre réseau, mais son cerveau est chez Anthropic ou OpenAI. Vous payez les tokens API chaque mois. Vous dépendez de la disponibilité du service. Vous envoyez vos prompts sur des serveurs tiers.

Le coût réel d’un Pi 5 8 Go avec boîtier, alimentation, SSD et carte SD tourne autour de 120 à 150 €. Ajoutez 20 à 100 € par mois d’API. Sur 12 mois, le Pi + API coûte entre 360 et 1 350 €. Un Mac Mini M4 24 Go à 699 € avec inférence locale gratuite devient rentable entre le 7e et le 18e mois selon votre consommation. Le Pi est moins cher à l’achat. Il n’est pas forcément moins cher à l’usage.

Quand le Pi reste pertinent malgré ses limites

Le Raspberry Pi garde un intérêt réel dans deux scénarios. Le premier : un usage léger d’OpenClaw avec API cloud, pour de la domotique, du monitoring réseau ou des tâches planifiées simples (cron). La consommation de 5 W rend le Pi idéal comme serveur permanent ultra-silencieux et quasi invisible sur la facture d’électricité.

Le deuxième : une architecture distribuée. Le Pi fait tourner OpenClaw comme runtime léger, et l’inférence est déportée vers une machine plus puissante du réseau local (un PC gaming, un Mac Studio, un serveur dédié). Un tunnel SSH inverse entre le Pi et la machine d’inférence suffit à relier les deux. C’est l’approche « split architecture » documentée par la communauté, qui combine le faible coût du Pi avec la puissance d’un GPU ou d’une puce Apple Silicon externe.

Installer OpenClaw directement ou via Docker : simplification ou surcouche inutile ?

OpenClaw propose deux méthodes d’installation sur macOS : native via npm avec un daemon launchd, ou conteneurisée via Docker Compose. Le choix a des conséquences concrètes sur les performances et la maintenance.

launchd natif vs conteneur Linux virtualisé : impact réel sur les performances

Sur macOS, Docker ne tourne pas nativement. Il exécute une machine virtuelle Linux légère dans laquelle les conteneurs s’exécutent. Cette couche de virtualisation ajoute un overhead mesurable. La documentation officielle d’OpenClaw le reconnaît explicitement : « Slow performance on macOS. This is expected due to Docker’s Linux VM layer. » Pour un agent qui enchaîne des opérations sur le système de fichiers (lecture de mémoire, écriture de logs, exécution de skills), ce surcoût se cumule.

L’installation native via npm install -g openclaw crée un daemon launchd qui tourne directement sur macOS, sans couche intermédiaire. Le processus Node.js accède au système de fichiers à vitesse native, consomme moins de RAM (pas de VM Linux à maintenir) et démarre plus vite après un reboot. Pour un Mac Mini dédié à OpenClaw, l’installation native est objectivement le meilleur choix en termes de performances brutes.

Isolation de sécurité : Docker apporte-t-il un vrai avantage ?

Docker offre une isolation que l’installation native ne fournit pas par défaut. Un conteneur peut être configuré sans bind mounts, avec un utilisateur non-root, un système de fichiers en lecture seule et un réseau restreint. Si l’agent est compromis (via une skill malveillante ou une injection de prompt), les dégâts restent confinés au conteneur.

En pratique, cette isolation a un prix. Certaines fonctionnalités d’OpenClaw, comme l’accès aux applications macOS natives (iMessage, Notes, Reminders), ne fonctionnent pas depuis un conteneur Linux. Les intégrations avec Spotlight, le Keychain ou AppleScript sont inaccessibles. Si vous utilisez OpenClaw principalement pour ses intégrations macOS, Docker supprime exactement ce qui justifie d’avoir un Mac. La bonne approche pour l’isolation sur macOS est un compte utilisateur dédié standard (non admin), combiné à un binding de la gateway sur 127.0.0.1.

Maintenance long terme : quel choix réduit la dette technique ?

Docker facilite les mises à jour et les rollbacks : un docker pull suivi d’un docker compose up -d suffit. Si une mise à jour casse quelque chose, revenir à l’image précédente prend 30 secondes. L’installation native via npm est plus fragile : les dépendances Node.js peuvent entrer en conflit, les mises à jour d’Homebrew peuvent casser des packages système, et la restauration d’un état antérieur demande plus de travail.

Sur un VPS Linux, Docker est presque toujours le meilleur choix. Sur un Mac Mini dédié, l’arbitrage dépend de vos priorités : performances maximales et intégrations macOS (natif) ou reproductibilité et isolation (Docker). Si le Mac Mini ne fait rien d’autre qu’OpenClaw, l’installation native avec launchd et un compte utilisateur dédié reste le chemin le plus propre. Docker devient pertinent si vous faites tourner d’autres services sur la même machine ou si la sécurité prime sur tout le reste.

Mode headless : pourquoi 10 € peuvent éviter des heures de debugging ?

Un Mac Mini utilisé comme serveur OpenClaw n’a pas besoin d’écran. Mais macOS n’a pas été conçu pour tourner sans moniteur, et certaines fonctions se désactivent silencieusement en mode headless.

Dongle HDMI : stabilité graphique et services macOS

Sans signal HDMI, macOS désactive une partie de son pipeline graphique. Les permissions de Screen Recording peuvent se casser, les applications GUI ne se rendent pas correctement, et la capture d’écran utilisée par certaines skills OpenClaw échoue. Un dongle HDMI « dummy plug » à 8 à 10 € simule la présence d’un écran et résout la totalité de ces problèmes.

Ce n’est pas un accessoire optionnel pour un usage serveur d’OpenClaw. C’est un prérequis. La majorité des problèmes de debugging remontés sur les forums communautaires en février 2026 étaient liés à l’absence de ce dongle. Un investissement de 10 € qui évite des heures de recherche sur des erreurs cryptiques liées aux permissions macOS.

pmset et autorestart : rendre la machine réellement autonome

macOS met un Mac Mini en veille par défaut après un certain temps d’inactivité. Pour un agent 24/7, c’est fatal. La commande sudo pmset -a sleep 0 disablesleep 1 désactive la mise en veille. L’option sudo pmset -a autorestart 1 redémarre automatiquement la machine après une coupure de courant. Dans les réglages système, activez « Wake for network access » sous Batterie/Options pour que la machine reste joignable via Tailscale même en mode basse consommation.

Ces trois réglages transforment un Mac Mini grand public en serveur domestique fiable. Sans eux, votre agent s’endort la nuit, ne redémarre pas après une micro-coupure, et perd sa connexion Tailscale dès que l’écran virtuel s’éteint.

SSH + Tailscale : ne jamais exposer le port 18789

La gateway OpenClaw écoute par défaut sur le port 18789. Exposer ce port sur Internet est la première cause de compromission documentée. L’incident Shodan de janvier 2026 l’a prouvé à grande échelle. La règle est simple : la gateway doit écouter uniquement sur 127.0.0.1. L’accès distant passe par un tunnel sécurisé.

Tailscale crée un réseau privé virtuel (VPN mesh) entre vos appareils sans ouvrir de port sur votre routeur. OpenClaw supporte Tailscale nativement dans son wizard de configuration. L’alternative est un tunnel SSH classique : ssh -N -L 18789:127.0.0.1:18789 user@mac-mini-ip redirige le port localement. Dans les deux cas, le port 18789 n’est jamais exposé à Internet. C’est la seule approche acceptable pour un agent qui a un accès shell à votre machine.

iMessage, Telegram, Discord : le Mac Mini est-il le seul choix viable ?

OpenClaw supporte plus de 12 canaux de messagerie. Mais tous ne fonctionnent pas sur tous les systèmes d’exploitation.

Dépendance à macOS pour iMessage : contrainte stratégique

iMessage ne fonctionne que sur macOS ou iOS. Si vous voulez contrôler OpenClaw via iMessage (ou que l’agent envoie des iMessages en votre nom), un Mac est obligatoire. C’est d’ailleurs la raison principale pour laquelle le Mac Mini est devenu le hardware de référence : pas pour sa puissance, mais pour son exclusivité logicielle.

OpenClaw accède à iMessage soit via l’intégration native macOS, soit via BlueBubbles (un bridge iMessage tiers). Dans les deux cas, macOS est requis. C’est une dépendance forte : si iMessage est votre canal principal de communication, aucun VPS Linux, aucun Raspberry Pi et aucun mini PC sous Ubuntu ne peut remplacer un Mac.

Multi-canaux simultanés : vraie limite technique ou mythe ?

OpenClaw gère nativement plusieurs canaux en parallèle : Telegram, Discord, Slack, WhatsApp, iMessage, Google Chat et d’autres. La gateway unique reçoit les messages de tous les canaux et les route vers l’agent. Il n’y a pas de limite technique au nombre de canaux actifs simultanément. La contrainte est plutôt dans la gestion du contexte : chaque conversation sur chaque canal maintient sa propre session, et le contexte cumulé consomme de la mémoire et des tokens.

En pratique, un Mac Mini 24 Go gère sans problème 3 à 5 canaux actifs avec un modèle cloud. Avec un modèle local, chaque session active augmente la pression sur la mémoire via le KV cache. Limitez-vous à 1 ou 2 canaux actifs simultanément si vous utilisez un modèle de 14B+ en local sur 24 Go.

Quand un mini PC Linux devient plus rationnel

Si vous n’avez pas besoin d’iMessage et que vous utilisez exclusivement Telegram, Discord ou Slack, un Mac Mini n’a aucun avantage fonctionnel sur un mini PC Linux. Un Beelink ou un MinisForum sous Ubuntu avec 32 Go de RAM et un processeur AMD Ryzen fait tourner OpenClaw et Ollama à un coût inférieur de 30 à 50 % par rapport à un Mac Mini équivalent.

Le point d’attention est la performance d’inférence. Sans GPU dédié, un processeur x86 fait de l’inférence CPU pure, qui est 5 à 10 fois plus lente qu’une puce Apple Silicon en mémoire unifiée. Si votre objectif est l’inférence locale performante sans GPU externe, Apple Silicon reste le meilleur rapport performance/prix. Si l’inférence est dans le cloud, un mini PC Linux à 300 € fait exactement le même travail qu’un Mac Mini à 699 €.

Sécurité : OpenClaw doit-il tourner sur votre compte principal ?

OpenClaw a un accès shell. Il peut lire vos fichiers, exécuter des commandes et interagir avec vos comptes connectés. Le faire tourner sur votre compte utilisateur principal est un risque que rien ne justifie.

Compte utilisateur dédié : cloisonnement minimal viable

La pratique recommandée est de créer un compte macOS standard (non admin) dédié à OpenClaw. Ce compte n’a pas accès à vos fichiers personnels, ne peut pas installer de logiciels système et ne peut pas modifier les réglages de sécurité. Si l’agent est compromis, le rayon d’impact est limité à ce compte.

Le compte admin sert uniquement à installer les dépendances (Homebrew, Node.js, npm). OpenClaw tourne ensuite depuis le compte standard. Cette séparation de privilèges est la base de toute configuration serveur sérieuse, mais la majorité des guides d’installation l’ignorent complètement. La commande openclaw doctor permet de vérifier que les permissions sont correctement configurées après l’installation.

Gateway en localhost uniquement : erreur fatale fréquente

La configuration bind address de la gateway est le choix de sécurité le plus critique de toute l’installation. Par défaut, certaines configurations exposent la gateway sur 0.0.0.0, c’est-à-dire sur toutes les interfaces réseau, y compris l’interface publique. Tout appareil sur le réseau local (ou sur Internet si le port est routé) peut alors accéder à la gateway sans authentification.

Le réglage correct est 127.0.0.1 : la gateway n’est accessible que depuis la machine elle-même. L’accès distant passe obligatoirement par Tailscale ou un tunnel SSH. La vulnérabilité CVE-2026-25253 (score CVSS 8.8) exploitait précisément cette mauvaise configuration pour voler des tokens d’authentification et exécuter du code arbitraire. Vérifiez cette valeur en premier après toute installation ou mise à jour.

Skills malveillantes : pourquoi l’isolation matérielle n’est pas optionnelle

Les skills sont des extensions qui augmentent les capacités d’OpenClaw : accès à Google Drive, publication sur GitHub, gestion de calendrier, etc. Chaque skill ajoutée élargit les permissions de l’agent. Une skill malveillante (ou compromise) peut exfiltrer vos clés API, lire vos fichiers ou exécuter du code arbitraire.

Le créateur d’OpenClaw recommande de démarrer avec zéro skill et d’ajouter chaque skill délibérément, une par une. Le sandboxing Docker par session (disponible depuis les versions récentes) isole l’exécution de chaque skill dans un conteneur éphémère. C’est la seule protection efficace contre les skills compromises. Sur une machine dédiée sans données sensibles et avec un compte utilisateur cloisonné, le risque résiduel est acceptable. Sur votre machine de travail quotidienne avec vos clés SSH, vos tokens API et vos documents professionnels, il ne l’est pas.

Quel setup offre le meilleur ROI selon votre ambition ?

Trois profils d’usage, trois configurations, trois budgets. Le ROI dépend entièrement de ce que vous attendez d’OpenClaw.

Usage API cloud simple : configuration minimale viable

Vous voulez un agent disponible 24/7 pour répondre via Telegram ou Discord, gérer des emails, lancer des tâches planifiées. L’inférence reste chez Anthropic ou OpenAI. Le hardware ne fait que faire tourner la gateway et les outils.

La configuration minimale : un Mac Mini M4 16 Go à 599 € (ou un Raspberry Pi 5 8 Go à 120 € si iMessage n’est pas nécessaire). Budget mensuel en tokens API : 20 à 50 €. Coût total sur 12 mois : 840 à 1 200 € avec le Mac Mini, 360 à 720 € avec le Pi. C’est le point d’entrée le plus accessible. Le Mac Mini est surdimensionné pour cet usage mais garantit une marge confortable et la possibilité d’évoluer.

Assistant IA privé sans abonnement : sweet spot matériel

Vous voulez un agent 100 % local pour les tâches courantes (triage email, résumés, réponses automatiques, gestion de fichiers) avec possibilité de fallback cloud pour les tâches complexes. L’inférence locale couvre 80 % des besoins.

La configuration optimale : un Mac Mini M4 Pro 32 Go à environ 1 200 € ou un M4 24 Go à 699 € (avec les limites sur la taille des modèles). Modèle recommandé : Devstral 24B ou Qwen 2.5 Coder 32B via Ollama ou LM Studio. Coût mensuel post-achat : quasi nul (électricité uniquement). Le retour sur investissement par rapport à un abonnement API de 50 €/mois intervient entre le 14e et le 24e mois. C’est le profil pour lequel le Mac Mini se justifie le plus clairement.

Infrastructure IA domestique ambitieuse : quand viser 64 Go devient logique

Vous voulez plusieurs agents, des workflows multi-étapes complexes, du traitement de documents en masse, zéro dépendance cloud, et la capacité de faire tourner les meilleurs modèles open source disponibles.

La configuration cible : un Mac Mini M4 Pro 64 Go à environ 2 000 €. Ce palier permet de faire tourner simultanément OpenClaw avec deux modèles (un spécialisé code, un généraliste), un contexte étendu à 128K tokens, et des skills lourdes comme l’automatisation de navigateur. L’investissement ne se rentabilise que si vous remplacez un usage cloud intensif (100 €+/mois en tokens) ou si la valeur créée par l’automatisation dépasse significativement le coût du hardware. Pour la plupart des utilisateurs individuels, 32 Go suffisent. 64 Go est le choix rationnel pour un usage professionnel ou semi-professionnel intensif.

Questions fréquentes

OpenClaw peut-il fonctionner derrière un proxy ou un pare-feu d’entreprise ?

OpenClaw établit des connexions sortantes vers les API des LLM (Anthropic, OpenAI) et les services de messagerie (Telegram, WhatsApp, Discord). Ces connexions passent par HTTPS sur le port 443. La plupart des pare-feu d’entreprise autorisent ce trafic par défaut. En revanche, si votre réseau bloque les WebSockets ou applique de l’inspection TLS profonde, certaines intégrations (WhatsApp via Baileys, Telegram en mode webhook) peuvent échouer silencieusement. Testez d’abord avec une connexion directe avant de diagnostiquer des problèmes liés au réseau d’entreprise.

Quelle est la consommation réelle en tokens API avec un usage quotidien modéré ?

Le prompt système d’OpenClaw pèse environ 17 000 tokens. Chaque échange ajoute le contexte de conversation, les définitions d’outils et l’historique de session. Un échange simple (question-réponse sans outil) consomme entre 20 000 et 30 000 tokens d’entrée. Un workflow agentique avec 5 appels d’outils peut atteindre 80 000 à 150 000 tokens. Sur une journée avec 20 à 30 interactions variées, comptez entre 500 000 et 2 millions de tokens. Avec Claude Sonnet à 3 $/million tokens en entrée, cela représente 1,50 à 6 € par jour. La facture mensuelle réaliste oscille entre 30 et 150 € selon l’intensité.

Faut-il utiliser Node.js ou Bun comme runtime pour OpenClaw ?

Le créateur d’OpenClaw recommande explicitement Node.js. Bun est compatible en théorie mais provoque des problèmes documentés avec certains canaux de messagerie (WhatsApp et Telegram notamment). La page npm officielle précise « Runtime: Node >= 22 » et les retours communautaires confirment que Bun introduit des régressions aléatoires difficiles à diagnostiquer. Utilisez Node.js pour la gateway de production. Bun peut servir pour du développement de skills si vous maîtrisez les différences de comportement.

Comment gérer les mises à jour d’OpenClaw sans casser la configuration existante ?

Avant toute mise à jour, sauvegardez le répertoire ~/.openclaw/ qui contient la configuration, les credentials, les fichiers mémoire et l’historique de sessions. La mise à jour elle-même se fait via npm update -g openclaw. Si la mise à jour casse quelque chose, restaurez le dossier sauvegardé et revenez à la version précédente avec npm install -g openclaw@version. La commande openclaw doctor après chaque mise à jour vérifie l’intégrité de la configuration et signale les migrations nécessaires. Planifiez les mises à jour en période creuse : certaines versions ont introduit des changements incompatibles dans le format de configuration.

OpenClaw supporte-t-il le multi-utilisateurs ou faut-il une instance par personne ?

Une instance OpenClaw est conçue pour un seul utilisateur. Le système de pairing lie un canal de messagerie à un utilisateur spécifique via un code de vérification. Il est techniquement possible de créer plusieurs agents dans une même instance avec des configurations et des canaux séparés (multi-agent routing), mais cette fonctionnalité reste expérimentale et consomme significativement plus de tokens et de mémoire. Pour un usage familial ou une petite équipe, la solution la plus fiable est de faire tourner plusieurs instances OpenClaw indépendantes, chacune sur son propre port, avec ses propres credentials et son propre compte utilisateur macOS.