OpenClaw s’installe en une ligne de commande. Ça ne veut pas dire qu’il se configure en une ligne. La plupart des guides existants font l’impasse sur ce qui se passe après le curl | bash : le port 18789 exposé sur toutes les interfaces réseau, les clés API stockées en clair dans ~/.openclaw/openclaw.json, les volumes Docker montés sans restriction. Un scan Shodan récent a révélé plus de 42 000 instances OpenClaw exposées sur Internet, dont 93 % sans authentification fonctionnelle. Le problème n’est pas l’outil. C’est le delta entre l’installation express et un déploiement réellement sûr. Cet article détaille chaque mode d’installation (local, Docker, VPS), leurs implications concrètes en termes de sécurité et de fiabilité, et les erreurs que la documentation officielle ne signale pas assez fort.

Faut-il vraiment un VPS pour installer OpenClaw 24/7 ?

La question du VPS revient systématiquement dans les discussions. Elle est souvent mal posée, parce qu’elle oppose « gratuit en local » à « payant sur serveur » sans examiner ce que chaque option implique techniquement.

Ce que le VPS apporte réellement (uptime, IP publique, reverse proxy)

Un VPS fournit trois choses qu’une machine locale ne peut pas garantir : une IP publique stable, un uptime indépendant de vos habitudes d’alimentation électrique, et la possibilité de placer un reverse proxy (Traefik, Caddy, nginx) entre Internet et le gateway OpenClaw. Ce reverse proxy est critique. Sans lui, le port 18789 est directement exposé, et la couche d’authentification par token du gateway devient le seul rempart. Avec Traefik, vous obtenez du TLS automatique via Let’s Encrypt, une terminaison HTTPS propre et la possibilité de filtrer les connexions par IP avant même qu’elles n’atteignent le processus Node.js. Sur un VPS à 4-5 €/mois (Contabo, Hetzner, DigitalOcean), vous obtenez un environnement isolé de votre machine personnelle, ce qui élimine le risque qu’un skill mal codé ou une injection de prompt accède à vos fichiers personnels, votre navigateur connecté ou votre réseau local.

Ce que vous perdez en local (intégration système, contrôle direct, latence)

En contrepartie, un VPS introduit une couche d’indirection. Chaque interaction avec l’agent passe par le réseau, ce qui ajoute de la latence sur les échanges WebSocket. L’intégration avec des outils locaux (contrôle du navigateur via CDP, accès aux fichiers du disque, automatisation macOS/iOS via les Companion Apps) devient soit impossible, soit nécessite un tunnel comme Tailscale. Le débogage en temps réel est aussi plus contraignant : consulter les logs, redémarrer le gateway ou modifier la configuration exige une connexion SSH. Pour un usage expérimental ou de développement de skills, la boucle de feedback en local reste nettement plus rapide. Un Raspberry Pi 5 avec 8 Go de RAM peut d’ailleurs faire tourner OpenClaw de façon permanente tout en restant physiquement déconnectable, ce qui offre un compromis intéressant entre isolation et accès direct.

Le faux débat « local = gratuit » : coûts API vs coûts serveur

Installer OpenClaw en local ne coûte rien en hébergement. Mais l’agent consomme des appels API à chaque interaction, à chaque battement du heartbeat daemon, et à chaque exécution de skill planifiée. Avec Claude Opus comme modèle principal (recommandé par le projet), un usage actif peut générer plusieurs dizaines d’euros par mois en frais d’API, bien au-delà du coût d’un VPS d’entrée de gamme. Un heartbeat mal configuré qui interroge le modèle toutes les minutes peut brûler des centaines de dollars en une nuit, comme plusieurs utilisateurs l’ont rapporté. Le coût du serveur est fixe et prévisible. Le coût API est variable et potentiellement explosif. C’est cette asymétrie qu’il faut évaluer, pas la gratuité apparente de l’installation locale.

Installation locale : pourquoi 80 % des tutos passent à côté du vrai risque

Le risque principal d’une installation locale n’est pas la complexité technique. C’est l’accès implicite que l’agent obtient à l’ensemble de votre environnement utilisateur dès qu’il tourne sur votre machine.

Node ≥22 : les erreurs silencieuses qui bloquent l’onboarding

OpenClaw exige Node.js version 22 ou supérieure. Ce prérequis est mentionné dans la documentation, mais les conséquences d’une version antérieure ne sont pas toujours explicites. Avec Node 18 ou 20, l’installation via npm s’effectue sans erreur apparente. C’est l’onboarding (openclaw onboard) qui échoue silencieusement : le wizard se lance, les étapes s’enchaînent, mais certaines fonctionnalités du gateway (WebSocket challenge, device auth, gestion des nonces) dépendent d’APIs introduites dans Node 22. Le symptôme typique est un device nonce mismatch ou un device signature invalid lors de la première connexion au dashboard, sans message indiquant que la version de Node est en cause. La commande node --version devrait être le premier réflexe avant toute installation, et l’utilisation de n ou nvm pour installer la bonne version évite des heures de débogage inutile.

WSL2 + Docker : isolation réelle vs accès implicite au disque C:

Sous Windows, WSL2 est le chemin recommandé. Mais WSL2 monte automatiquement le système de fichiers Windows sous /mnt/c/, /mnt/d/, etc. Un agent OpenClaw qui tourne dans WSL2 a donc, par défaut, accès en lecture et écriture à l’intégralité de votre disque Windows. Si vous ajoutez Docker dans WSL2, le conteneur peut lui aussi accéder à ces montages si les volumes sont mal configurés. L’isolation que Docker est censé fournir est court-circuitée par le comportement par défaut de WSL2. La seule protection réelle consiste à désactiver l’automount dans /etc/wsl.conf avec [automount] enabled = false, puis à ne monter manuellement que les répertoires strictement nécessaires. Sans cette étape, l’agent dispose d’un accès shell à vos documents, votre bureau, vos téléchargements, et potentiellement à vos fichiers de configuration de navigateur contenant des tokens de session.

Limiter l’écoute réseau : 0.0.0.0 vs 127.0.0.1 et implications concrètes

L’installation CLI par défaut lie le gateway à 127.0.0.1:18789 (loopback uniquement). C’est le comportement sûr : seules les connexions depuis la même machine sont acceptées. Mais le script Docker (docker-setup.sh) bascule par défaut sur 0.0.0.0:18789, ce qui expose le gateway sur toutes les interfaces réseau, y compris l’IP publique si vous êtes sur un VPS sans firewall. C’est cette divergence entre les deux modes d’installation qui explique l’ampleur des instances exposées détectées par les scans Shodan. Si votre gateway écoute sur 0.0.0.0 et que vous n’avez ni firewall, ni reverse proxy, ni token d’authentification fort, n’importe qui peut se connecter au WebSocket, interagir avec votre agent et potentiellement exécuter des commandes shell sur votre machine. Vérifier le binding actif se fait avec ss -tlnp | grep 18789 : si la sortie affiche 0.0.0.0:18789 au lieu de 127.0.0.1:18789, la correction est urgente.

Installer OpenClaw via script officiel : rapide, mais à quelles conditions ?

La méthode recommandée tient en une ligne. Cette simplicité masque des décisions de sécurité que le script prend à votre place, sans toujours les documenter.

curl | bash : ce que vous exécutez réellement sur votre machine

La commande curl -fsSL https://openclaw.ai/install.sh | bash télécharge et exécute un script shell en une seule opération. Ce script installe Node.js (s’il n’est pas présent ou en version insuffisante), installe le package npm openclaw globalement, et prépare l’environnement pour l’onboarding. L’exécution via pipe dans bash signifie que vous n’inspectez pas le script avant de le lancer. Pour un projet open source avec plus de 180 000 stars GitHub, la confiance est raisonnable, mais pas aveugle. La pratique recommandée reste de télécharger le script d’abord (curl -fsSL https://openclaw.ai/install.sh -o install.sh), de le lire, puis de l’exécuter. Cette précaution n’est pas paranoïaque : elle est élémentaire, surtout quand le script effectue des installations globales de packages npm qui seront ensuite exécutés avec les permissions de votre utilisateur.

openclaw onboard –install-daemon : service système et persistance au reboot

L’option --install-daemon du wizard d’onboarding installe le gateway comme service système : launchd sur macOS, systemd (service utilisateur) sur Linux. Ce daemon assure que le gateway redémarre automatiquement au boot, ce qui est nécessaire pour un fonctionnement 24/7. Ce que cette étape implique concrètement : un processus Node.js tourne en permanence en arrière-plan, consomme de la RAM (comptez environ 200-400 Mo selon les skills chargés), et maintient des connexions WebSocket actives vers vos canaux de messagerie. Le heartbeat daemon s’exécute aussi à intervalle régulier et peut déclencher des appels API même en l’absence d’interaction humaine. Vérifier l’état du service avec systemctl --user status openclaw-gateway (Linux) ou launchctl list | grep openclaw (macOS) devrait devenir un réflexe, notamment pour détecter les redémarrages en boucle qui ne génèrent pas toujours de notification visible.

Où sont stockées les clés API et comment les protéger correctement

Les clés API (Anthropic, OpenAI, ou tout autre fournisseur) sont stockées dans ~/.openclaw/openclaw.json en texte clair. Ce fichier contient également le token du gateway, la configuration des canaux, et les paramètres des agents. Ses permissions par défaut dépendent de votre umask système, qui sur la plupart des distributions Linux laisse le fichier lisible par le groupe. Un chmod 600 ~/.openclaw/openclaw.json est le minimum. Sur un VPS partagé ou un environnement multi-utilisateurs, ce fichier est la cible prioritaire en cas de compromission d’un autre compte. L’approche recommandée pour un déploiement sérieux consiste à utiliser des variables d’environnement (ANTHROPIC_API_KEY, OPENAI_API_KEY) plutôt que de stocker les clés dans le fichier de configuration. Docker Sandboxes va plus loin en injectant les clés via un proxy réseau, de sorte que le conteneur n’a jamais accès aux clés en clair, même en cas d’exfiltration.

Dockerisation d’OpenClaw : protection ou illusion de sécurité ?

Docker isole le processus OpenClaw du système hôte. Mais cette isolation n’est effective que si la configuration est stricte. Dans la majorité des déploiements observés, elle ne l’est pas.

Volumes partagés : comment une mauvaise config expose vos fichiers

Le docker-compose.yml standard d’OpenClaw monte deux volumes : ~/.openclaw (configuration, mémoire, clés) et ~/openclaw/workspace (répertoire de travail de l’agent). Le premier contient vos secrets. Le second est le répertoire où l’agent peut lire et écrire librement. Si vous ajoutez des montages supplémentaires via OPENCLAW_EXTRA_MOUNTS sans en mesurer les conséquences, vous élargissez la surface d’attaque du conteneur. Un montage de /home/user/Documents donne à l’agent accès à tous vos documents. L’image officielle tourne comme utilisateur node (uid 1000), ce qui limite les dégâts, mais un uid 1000 sur l’hôte correspond souvent au premier utilisateur humain du système. Si vos fichiers hôte appartiennent à uid 1000, le conteneur peut les modifier. La règle est simple : ne montez que les répertoires strictement nécessaires, et vérifiez la propriété des fichiers avec ls -ln avant de configurer les volumes.

Groupe docker sans sudo : gain pratique, surface d’attaque accrue

Ajouter votre utilisateur au groupe docker permet de lancer des conteneurs sans sudo. C’est confortable. C’est aussi l’équivalent de donner à cet utilisateur un accès root permanent au système. Tout membre du groupe docker peut monter le système de fichiers racine dans un conteneur, lire /etc/shadow, installer des backdoors. Dans le contexte d’OpenClaw, si l’agent a accès au socket Docker (ce qui est le cas si vous montez /var/run/docker.sock pour le sandboxing), une injection de prompt suffisamment sophistiquée pourrait théoriquement déclencher la création d’un conteneur privilégié. L’alternative est Podman en mode rootless : pas de daemon root, pas de groupe privilégié, isolation par user namespace. La documentation OpenClaw ne le recommande pas officiellement, mais le projet est compatible et plusieurs guides de hardening le préconisent comme standard pour les déploiements exposés.

Port 18789 exposé : pourquoi c’est la faille la plus fréquente

Le port 18789 est celui du gateway WebSocket. Le scan Shodan de février 2026 a trouvé plus de 42 000 instances avec ce port ouvert sur Internet. La cause est structurelle : le script Docker expose le port sur 0.0.0.0 par défaut, et beaucoup de tutoriels de déploiement VPS ne mentionnent pas la nécessité d’un firewall ou d’un reverse proxy. Sans reverse proxy, le WebSocket est accessible directement. Même avec le token d’authentification activé, le protocole WebSocket ne bénéficie pas de la protection TLS si vous n’avez pas configuré HTTPS en amont. Le token transite alors en clair sur le réseau. La correction minimale : lier le port au loopback dans le docker-compose.yml (127.0.0.1:18789:18789 au lieu de 18789:18789), puis exposer le gateway uniquement via un reverse proxy HTTPS.

Déployer OpenClaw sur un VPS : architecture minimale vraiment robuste

Déployer sur un VPS sans réfléchir à l’architecture revient à déplacer le problème. Une stack minimale mais solide repose sur trois composants : Docker, un reverse proxy avec TLS, et des règles d’accès explicites.

Docker + Traefik + HTTPS automatique : la stack qui tient en production

Traefik s’intègre nativement avec Docker Compose et gère le renouvellement automatique des certificats Let’s Encrypt. La configuration type expose un seul point d’entrée HTTPS sur le port 443, route les requêtes vers le conteneur OpenClaw, et termine le TLS avant le gateway. Le conteneur OpenClaw n’écoute que sur le réseau Docker interne, jamais sur l’interface publique. Le docker-compose.yml de production inclut Traefik comme service séparé avec les labels de routage sur le conteneur OpenClaw. Cette architecture élimine l’exposition directe du port 18789, chiffre toutes les communications (y compris les WebSocket), et permet d’ajouter des middlewares de sécurité (rate limiting, headers de sécurité, restriction géographique) sans toucher à la configuration d’OpenClaw. Le coût en ressources de Traefik est négligeable : environ 30 Mo de RAM.

Restreindre l’accès au Gateway : token seul vs IP whitelist

Le gateway supporte l’authentification par token (gateway.auth.mode: "token"). Ce token est une chaîne de 48 caractères stockée dans la configuration. C’est le minimum requis, mais pas suffisant seul sur un VPS exposé. Un token protège contre l’accès non autorisé au WebSocket, mais pas contre les tentatives de connexion répétées (bruteforce) ni contre l’exploitation d’éventuelles vulnérabilités du serveur WebSocket Node.js lui-même. L’IP whitelist, configurée au niveau du reverse proxy ou du firewall (ufw allow from <IP> to any port 443), réduit drastiquement la surface d’attaque en n’autorisant que vos adresses connues. Pour un usage personnel, combiner le token avec une restriction IP sur votre adresse Tailscale ou votre IP fixe est l’approche la plus sûre. Certains hébergeurs comme DigitalOcean ajoutent automatiquement un rate limiting sur le port du gateway dans leur déploiement 1-Click, ce qui constitue une couche de protection supplémentaire.

Logs et restart policy : éviter les boucles silencieuses de redémarrage

Le restart: unless-stopped dans Docker Compose est le paramètre par défaut pour un service persistant. Mais si le gateway crashe à cause d’une erreur de configuration (clé API invalide, port déjà occupé, conflit de pairing), Docker le relance immédiatement, en boucle. Les logs s’accumulent, le CPU tourne, et rien de visible ne signale le problème. La commande docker compose logs --tail 50 openclaw-gateway révèle généralement un pattern d’erreur répété toutes les quelques secondes. La solution est double : configurer un restart: on-failure avec un restart_policy.max_attempts limité (par exemple 5), et mettre en place une surveillance externe (un simple script cron qui vérifie docker inspect --format='{{.State.RestartCount}}' et alerte au-delà d’un seuil). Sans cette surveillance, un gateway en boucle de redémarrage consomme des ressources sans rendre aucun service, et masque le vrai problème dans un flot de logs identiques.

Pourquoi OpenClaw « ne répond plus » après installation ?

C’est la question la plus fréquente sur le Discord et les issues GitHub. Dans 90 % des cas, le gateway tourne, mais l’agent ne traite pas les messages. Trois causes couvrent la quasi-totalité des situations.

Clé API invalide ou facturation inactive : symptôme typique

OpenClaw ne vérifie pas proactivement la validité de votre clé API au démarrage. Le gateway démarre, le WebSocket s’ouvre, les canaux se connectent. Mais quand un message arrive et que l’agent essaie de contacter le modèle (Anthropic, OpenAI, etc.), la requête échoue silencieusement ou renvoie une erreur 401/403 qui n’apparaît que dans les logs. Un compte Anthropic sans abonnement actif, une clé API révoquée, ou un dépassement de quota produisent le même symptôme : l’agent reçoit les messages mais ne répond jamais. La commande openclaw logs --follow pendant l’envoi d’un message de test est le diagnostic le plus direct. Cherchez les lignes contenant 401, 403, insufficient_quota, ou billing_not_active. Configurer des alertes de dépenses au niveau du fournisseur (pas dans OpenClaw) est indispensable pour éviter à la fois les dépassements et les interruptions silencieuses.

Problème de pairing (pending.json) : diagnostic et correction propre

Le système de pairing d’OpenClaw repose sur deux fichiers JSON dans ~/.openclaw/devices/ : paired.json (appareils approuvés) et pending.json (demandes en attente). Le bug le plus documenté est le suivant : la gateway écrit la demande de pairing dans pending.json, mais l’API qui expose les demandes en attente lit un autre store (nodes/pending.json). Résultat : openclaw devices list affiche une liste vide alors qu’une demande existe réellement sur le disque. Ce problème touche particulièrement les installations Docker, où le NAT empêche l’auto-approbation des connexions loopback. Le diagnostic consiste à inspecter directement cat ~/.openclaw/devices/pending.json. Si une demande y figure avec un deviceId et un publicKey, la correction manuelle consiste à déplacer cette entrée dans paired.json avec le bon format, puis à redémarrer le gateway. C’est inélégant mais fiable, en attendant l’unification des deux stores de pairing qui fait l’objet de plusieurs issues ouvertes.

Conteneur actif mais agent inactif : lire les logs avant de réinstaller

docker ps affiche le conteneur comme Up. Mais Up ne signifie pas fonctionnel. Le processus Node.js à l’intérieur peut être en état d’erreur, en boucle de reconnexion, ou bloqué sur un verrou de fichier. La commande docker compose exec openclaw-gateway openclaw status donne l’état réel de l’agent. Si le statut indique gateway: reachable mais agent: inactive ou channels: disconnected, le problème est dans la configuration de l’agent (workspace, modèle, permissions) et non dans le conteneur. Réinstaller depuis zéro à ce stade détruit votre configuration, vos sessions, et potentiellement vos clés. La séquence correcte est : lire les logs (docker compose logs --tail 100), identifier l’erreur, corriger la configuration, puis docker compose restart. La réinstallation est un dernier recours, pas un premier réflexe.

Connecter WhatsApp ou Telegram sans créer une bombe à retardement

OpenClaw s’intègre à WhatsApp, Telegram, Slack, Discord, Signal et d’autres. Chaque intégration ouvre un canal de communication bidirectionnel entre votre agent et un service tiers. Les implications de sécurité varient considérablement d’un canal à l’autre.

QR code et device linking : ce que vous autorisez réellement

Connecter WhatsApp à OpenClaw passe par le scan d’un QR code qui lie votre compte WhatsApp personnel à une session web. OpenClaw agit comme un appareil lié (WhatsApp Web). Concrètement, l’agent peut lire tous vos messages entrants, envoyer des messages en votre nom, et accéder à vos contacts. Ce n’est pas un bot sur un numéro séparé : c’est votre compte, avec tous les messages de tous vos contacts, exposé à un agent autonome. Si quelqu’un envoie un message contenant une instruction malveillante (injection de prompt via un message WhatsApp), l’agent la traite comme n’importe quelle autre entrée. La recommandation minimale est de dédier un numéro séparé à OpenClaw plutôt que d’utiliser votre numéro principal, et de limiter les contacts qui interagissent avec ce numéro.

Désactiver la confidentialité des groupes Telegram : impact sécurité

Pour que l’agent OpenClaw puisse lire les messages dans un groupe Telegram, il faut généralement modifier les paramètres de confidentialité du bot ou du compte utilisé. Certains guides recommandent de désactiver les restrictions de confidentialité des groupes pour simplifier l’intégration. Le résultat : votre agent reçoit tous les messages de tous les groupes auxquels il est ajouté, y compris ceux envoyés par des inconnus dans des groupes publics. Chaque message est une entrée potentielle pour l’agent, qui peut déclencher une action (exécution de commande, envoi de réponse, appel API). Le paramètre requireMention dans la configuration OpenClaw des canaux Telegram est une protection essentielle : l’agent n’intervient que lorsqu’il est explicitement mentionné. Sans cette restriction, un groupe actif génère un flux continu d’appels API et de potentielles exécutions non souhaitées.

Pairing manuel via CLI : contrôle fin des appareils autorisés

La commande openclaw devices list affiche tous les appareils appairés avec leur deviceId, clientMode et scopes. Chaque scope définit ce que l’appareil peut faire : operator.admin donne un accès complet, operator.read un accès en lecture seule. Le pairing manuel via openclaw devices approve <requestId> permet de contrôler précisément quels appareils accèdent au gateway et avec quelles permissions. C’est préférable à l’auto-approbation loopback quand vous gérez plusieurs points d’accès (CLI, dashboard web, application mobile, nœuds distants). Vérifier régulièrement la liste des appareils appairés et révoquer les accès obsolètes (openclaw devices revoke <deviceId>) fait partie de l’hygiène de base. Un appareil appairé avec des scopes admin qui n’est plus utilisé reste un vecteur d’accès potentiel.

Exécuter OpenClaw en 24/7 sans transformer votre machine en passoire

Faire tourner un agent autonome en permanence demande des précautions que la documentation couvre partiellement. Les trois points suivants sont les plus négligés.

Désactiver l’automount WSL pour cloisonner les fichiers sensibles

Si vous utilisez WSL2 sous Windows, l’automount expose par défaut l’intégralité de vos disques Windows à l’environnement Linux. Pour un agent qui tourne 24h/24 avec accès shell, c’est un risque disproportionné. Le fichier /etc/wsl.conf doit contenir :

[automount] enabled = false

Après modification, un wsl --shutdown puis relance applique le changement. Vous pouvez ensuite monter manuellement uniquement le répertoire workspace OpenClaw si nécessaire. Cette étape est absente de la documentation officielle d’OpenClaw et de la plupart des guides d’installation sous Windows, alors qu’elle constitue probablement la mesure de sécurité la plus importante pour les utilisateurs WSL2.

Sauvegarder ~/.openclaw et tokens avant toute mise à jour

Le répertoire ~/.openclaw contient l’ensemble de l’état de votre agent : configuration, mémoire (fichiers Markdown), sessions, appareils appairés, et clés. Une mise à jour (npm update -g openclaw@latest) peut modifier la structure de ce répertoire ou invalider des fichiers de pairing, comme l’a montré le bug de la version 2026.2.19-2 où toutes les commandes CLI ont cessé de fonctionner avec pairing required après update. Avant chaque mise à jour, un cp -r ~/.openclaw ~/.openclaw.backup.$(date +%Y%m%d) prend quelques secondes et peut éviter une réinstallation complète. Pour Docker, le volume correspondant doit aussi être sauvegardé. Les tokens d’authentification des canaux (WhatsApp, Telegram) sont stockés dans cet arbre de fichiers. Perdre ces tokens signifie reconnecter chaque canal manuellement.

Rotation des clés API et gestion des permissions minimales

Les clés API utilisées par OpenClaw ont un pouvoir d’achat illimité si vous n’avez pas configuré de plafond chez le fournisseur. Faire tourner la même clé pendant des mois augmente le risque en cas de fuite. La rotation trimestrielle est un minimum raisonnable : générer une nouvelle clé chez Anthropic ou OpenAI, la mettre à jour dans la configuration OpenClaw, puis révoquer l’ancienne. Côté permissions de l’agent, le principe du moindre privilège s’applique directement : ne donnez pas accès aux outils shell, browser et filesystem si votre usage se limite à la messagerie et au calendrier. Chaque skill installé depuis ClawHub doit être audité (26 % des skills communautaires analysés par Cisco contenaient au moins une vulnérabilité). L’installation de skills doit se faire depuis un fork personnel, après lecture du code source, jamais en aveugle depuis le registre public.

Mettre à jour ou réinstaller OpenClaw : quand repartir de zéro est la meilleure option

Les mises à jour d’OpenClaw sont fréquentes. Le projet évolue vite (anciennement Moltbot, puis Clawdbot, puis OpenClaw). Certaines mises à jour cassent la compatibilité du pairing, des sessions, ou de la structure de configuration.

docker compose down -v : nettoyage complet sans résidus

La commande docker compose down arrête et supprime les conteneurs, mais conserve les volumes. docker compose down -v supprime aussi les volumes nommés, ce qui élimine toute trace de configuration, de mémoire et de sessions. C’est la commande appropriée quand vous voulez un état propre, par exemple après un bug de pairing impossible à résoudre ou une corruption du store de sessions. Attention : si vos volumes contiennent des données que vous voulez conserver (mémoire de l’agent, fichiers workspace), sauvegardez-les avant. La commande docker volume inspect permet de localiser le chemin physique des volumes sur l’hôte. Après un down -v, le prochain docker compose up repart de l’image propre et relance l’onboarding.

Différence entre update binaire et reconstruction d’image Docker

npm update -g openclaw@latest met à jour le binaire CLI et le gateway sur une installation native. Le processus est rapide, mais conserve toute la configuration existante, y compris les éventuelles incompatibilités. En Docker, la mise à jour passe par le pull d’une nouvelle image (docker compose pull) suivi d’un docker compose up -d. L’image est reconstruite depuis le Dockerfile du projet, avec potentiellement de nouvelles dépendances système, une version de Node différente, ou des changements dans la structure du filesystem du conteneur. La reconstruction complète de l’image (docker build --no-cache) est parfois nécessaire quand des couches en cache contiennent des dépendances obsolètes. La différence pratique est que l’update binaire conserve l’état, tandis que la reconstruction d’image repart d’un OS propre à l’intérieur du conteneur. Les deux approches nécessitent de vérifier ensuite que les devices sont correctement appairés et que le gateway démarre sans boucle.

Réinstallation Ubuntu / VM : solution radicale mais propre

Quand la configuration est devenue un enchevêtrement de fichiers modifiés manuellement, de pending.json corrompus, et de versions incompatibles de Node, la réinstallation complète de l’OS dans une VM ou sur le VPS reste la méthode la plus fiable. Un VPS peut être réinitialisé en quelques minutes depuis le panneau de contrôle de l’hébergeur. Une VM locale se recrée depuis un snapshot propre. Cette approche est particulièrement justifiée si vous avez fait des modifications de sécurité dans paired.json à la main (ce que recommandent plusieurs workarounds officiels) sans être certain de leur cohérence. Repartir d’un Ubuntu nu, installer Node 22, lancer l’onboarding, et restaurer uniquement le fichier de configuration (pas les fichiers de pairing) depuis la sauvegarde produit un environnement prévisible en moins de 30 minutes.

Installer OpenClaw en 5 minutes : dans quels cas c’est une erreur stratégique

La promesse d’une installation en 5 minutes est tenue sur le plan technique. Elle est trompeuse sur le plan opérationnel dans plusieurs scénarios.

Usage expérimental vs usage productif : exigences différentes

Pour tester OpenClaw, explorer ses capacités, ou développer un skill, l’installation locale express est parfaitement adaptée. Le gateway tourne, le dashboard s’ouvre, vous pouvez interagir via le Control UI sans connecter aucun canal de messagerie. Mais dès que l’agent est connecté à des comptes réels (WhatsApp personnel, Slack d’entreprise, Gmail), les exigences changent radicalement. Un agent productif nécessite un environnement isolé, des sauvegardes automatiques, une surveillance des logs, des plafonds de dépenses API, et une politique de permissions explicite. Passer de l’expérimentation à la production sans ces étapes intermédiaires est la source de la majorité des incidents de sécurité rapportés dans l’écosystème OpenClaw. L’installation en 5 minutes crée un prototype. Transformer ce prototype en infrastructure fiable prend des heures, pas des minutes.

Agent autonome avec accès fichiers : arbitrage entre confort et contrôle

OpenClaw peut lire et écrire des fichiers, exécuter des commandes shell, contrôler un navigateur et envoyer des emails en votre nom. Chaque capacité ajoutée augmente le confort d’utilisation et la surface d’attaque dans les mêmes proportions. Un agent avec accès au filesystem peut résoudre des tâches complexes de manière autonome (organiser des fichiers, modifier du code, créer des rapports). Le même agent, face à une entrée malveillante ou un hallucination du modèle, peut supprimer des fichiers, exfiltrer des données, ou envoyer des communications non autorisées. L’architecture d’OpenClaw confie à un modèle probabiliste des actions déterministes et irréversibles. Cette tension est inhérente au projet et assumée par ses créateurs. Votre responsabilité est de définir le périmètre d’action acceptable avant de donner les clés.

La règle des 20 % : limiter les permissions avant d’ajouter des skills

Un principe opérationnel qui émerge de la pratique : ne donnez à l’agent accès qu’à 20 % des outils disponibles, ceux dont vous avez un besoin immédiat et vérifié. Commencez avec la messagerie seule, sans accès shell, sans accès filesystem, sans browser. Ajoutez les outils un par un, en vérifiant à chaque étape le comportement de l’agent face à des instructions ambiguës ou potentiellement dangereuses. Chaque skill installé depuis ClawHub étend les capacités de l’agent mais aussi son périmètre d’action autonome. Gater toutes les actions irréversibles (paiements, suppressions, envois d’emails, modifications de fichiers) derrière une approbation humaine explicite est la seule configuration défendable pour un agent connecté à des systèmes réels. L’autonomie totale est un objectif séduisant. En l’état actuel des modèles et du projet, c’est aussi un risque que seuls les utilisateurs qui comprennent parfaitement l’architecture peuvent assumer en connaissance de cause.

Questions fréquentes

OpenClaw fonctionne-t-il avec des modèles locaux via Ollama ou llama.cpp ?

OpenClaw est agnostique au niveau du modèle. Vous pouvez connecter Ollama, llama.cpp, LocalAI, ou tout endpoint compatible OpenAI en configurant le provider dans openclaw.json ou via openclaw models set. Les modèles locaux éliminent les coûts API et gardent toutes les données sur votre machine. La contrepartie est une qualité de raisonnement inférieure aux grands modèles cloud (Claude Opus, GPT-4), ce qui affecte directement la fiabilité de l’agent pour les tâches complexes. Un compromis courant consiste à utiliser un modèle local pour les tâches simples et routinières, avec un fallback vers un modèle cloud pour les requêtes exigeantes.

Quelle est la consommation mémoire et CPU d’OpenClaw en fonctionnement continu ?

Le gateway OpenClaw consomme entre 150 et 400 Mo de RAM selon le nombre de canaux connectés et de skills chargés. Le CPU est sollicité de manière intermittente : quasi nul entre les interactions, avec des pics lors du traitement des messages et de l’exécution des skills. Un Raspberry Pi 5 avec 8 Go de RAM gère confortablement une instance. Sur un VPS, 2 Go de RAM suffisent pour le gateway seul, mais la construction de l’image Docker (pnpm install) nécessite au moins 2 Go sous peine de kill OOM (exit code 137). Prévoyez une instance avec 2 Go minimum pour l’installation, même si le fonctionnement courant demande moins.

Peut-on faire tourner plusieurs agents OpenClaw sur la même machine ?

OpenClaw supporte le multi-agent routing nativement. Vous pouvez configurer plusieurs agents isolés avec des workspaces, modèles et canaux distincts, le tout géré par un seul gateway. Chaque agent dispose de ses propres sessions et de sa propre mémoire. Cette architecture évite de multiplier les instances et les ports. La configuration se fait dans la section agents du fichier de configuration, en attribuant des canaux et des comptes spécifiques à chaque agent. Pour des besoins d’isolation totale (par exemple un agent de test et un agent de production), des instances gateway séparées sur des ports différents restent préférables.

Comment limiter les dépenses API quand le heartbeat est actif ?

Le heartbeat daemon réveille l’agent à intervalle configurable pour exécuter des tâches planifiées. Chaque réveil peut générer un appel API, même sans interaction humaine. Pour contrôler les coûts, configurez d’abord un plafond de dépenses chez votre fournisseur d’API (Anthropic et OpenAI proposent tous deux des limites mensuelles). Ensuite, ajustez l’intervalle du heartbeat dans la configuration OpenClaw pour le limiter au strict nécessaire. Désactivez-le complètement si vous n’utilisez pas de tâches planifiées. Enfin, surveillez vos dépenses via le tableau de bord de votre fournisseur plutôt que via OpenClaw, car les mécanismes de suivi internes ne couvrent pas tous les cas de consommation inattendue.

OpenClaw est-il adapté à un usage professionnel en entreprise ?

En l’état actuel du projet (février 2026), les principales firmes de sécurité et plusieurs entreprises technologiques (dont Meta) ont restreint ou interdit son utilisation sur les systèmes d’entreprise. Les raisons sont documentées : exécution de code arbitraire via prompt injection, absence d’audit trail natif pour les actions sensibles, et risque de Shadow IT lié à l’installation en une ligne. Pour un usage professionnel individuel (freelance, side project), OpenClaw est utilisable avec les mesures de hardening appropriées. Pour un déploiement connecté à des systèmes d’information d’entreprise (Slack corporate, bases de données, email professionnel), le cadre de sécurité actuel n’offre pas les garanties exigées par la plupart des politiques de sécurité informatique.