Si 2026 finit par être l’année où les agents IA cessent d’être surtout des démos pour devenir de vrais outils d’opération, alors OpenClaw mérite d’être dans cette conversation.Je ne dis pas cela dans un sens buzzword.
Je le dis dans un sens pratique, d’ingénierie : OpenClaw essaie de faire converger messagerie, outils, automatisation, mémoire et workflows opérateur du quotidien dans un système unique réellement exploitable.NVIDIA commence déjà à aller dans une direction voisine avec NemoClaw, et Jensen Huang (PDG de NVIDIA) est même allé jusqu’à dire : “OpenClaw is the number one, most popular open-source project in the history of humanity.” Si vous voulez la source de cette phrase, voici la vidéo.Mais ce post n’est pas un encore post sur le hype.
C’est un post sur la pratique.Plus précisément, je raconte comment j’ai mis en place OpenClaw pour mon propre usage, ce qui s’est bien passé, ce qui s’est moins bien passé, et ce que j’ai appris après environ un mois d’utilisation dans une configuration remote-first plutôt que dans le modèle plus simple de machine unique.Par « remote-first », j’entends un assistant qui tourne entièrement sur un hôte distant et auquel on accède par le réseau, au lieu de partager la même machine que l’utilisateur.
Pourquoi je ne voulais pas du modèle local par défaut
Faire tourner OpenClaw en local est simple.Mais je ne voulais pas d’un assistant qui n’existe que sur la machine ouverte devant moi à un instant donné.
Je voulais quelque chose d’accessible de n’importe où, protégé par un contrôle d’accès fort, avec une frontière d’isolation suffisamment nette pour ne pas faire semblant que l’hôte et le runtime de l’assistant appartiennent à la même zone de confiance.Cette décision paraît simple.
En pratique, elle change la forme de tout le déploiement, parce qu’une grande partie de l’outillage IA moderne continue de supposer discrètement un fonctionnement local-first.
Pourquoi j’ai utilisé mon home lab plutôt qu’un VPS
D’abord, ce déploiement reflète un choix pragmatique : j’ai déjà un home lab.Pour moi, réutiliser du matériel existant était simplement plus économique que de louer un VPS et de payer chaque mois pour avoir une « machine isolée » dédiée à mon assistant.
Si la capacité de calcul, de stockage et de réseau existe déjà dans une infrastructure que je contrôle, la réutiliser est l’option rationnelle.Mais le coût n’était qu’une partie de la décision.Un déploiement en home lab m’offrait aussi plusieurs propriétés utiles pour ce type de système :
un contrôle plus direct sur l’hôte, le réseau et le modèle d’isolation
une expérimentation plus simple des frontières du runtime et des options de configuration réseau
pas besoin d’adapter le design à une image ou à des politiques génériques de fournisseur VPS
un point d’ancrage plus propre pour connecter ensuite le système à d’autres services auto-hébergés
Tout le monde ne veut pas, par défaut, faire tourner un système IA opérationnel sur une infrastructure louée à un tiers.Certains praticiens disposent déjà d’environnements self-hosted suffisamment solides, donc un VPS n’est pas forcément le choix économique évident.
Et dans certains contextes d’entreprise, la question n’est même pas le coût : c’est la gouvernance.Selon l’environnement, les équipes peuvent se soucier de choses comme :
où transitent les données conversationnelles et opérationnelles
si des outils internes doivent résider sur une infrastructure louée à l’extérieur
à quel point l’hôte peut être intégré à des contrôles réseau existants
quel niveau de contrôle elles conservent sur l’isolation, la journalisation et l’exposition
Cela ne veut pas dire qu’un VPS est un mauvais choix.
Pour beaucoup de gens, c’est le chemin le plus rapide et le plus simple.
Mais ce n’est pas le seul chemin à considerer, et dans certains environnements ce n’est peut-être même pas un chemin possible.C’est aussi pour cela que je pense que ce déploiement mérite d’être documenté.
Il montre à quoi ressemble OpenClaw quand on le traite moins comme une application jetable que comme une pièce d’infrastructure opérationnelle qu’on veut positionner de façon réfléchie.
Le déploiement : Docker Compose, état persistant et workspace partagé
Je fais tourner OpenClaw dans Docker, et la structure principale apparaît dans le fichier Compose ci-dessous.
version: "3.9"
services:
openclaw:
image: ${OPENCLAW_IMAGE:-ghcr.io/openclaw/openclaw:latest}
container_name: openclaw
environment:
HOME: /home/node
TERM: xterm-256color
# Required (recommended to set)
OPENCLAW_GATEWAY_TOKEN: ${OPENCLAW_GATEWAY_TOKEN}
# Optional
OPENCLAW_ALLOW_INSECURE_PRIVATE_WS: ${OPENCLAW_ALLOW_INSECURE_PRIVATE_WS:-}
CLAUDE_AI_SESSION_KEY: ${CLAUDE_AI_SESSION_KEY:-}
CLAUDE_WEB_SESSION_KEY: ${CLAUDE_WEB_SESSION_KEY:-}
CLAUDE_WEB_COOKIE: ${CLAUDE_WEB_COOKIE:-}
volumes:
- openclaw-data:/home/node
- openclaw-shared:/mnt/shared
# Sandbox isolation (optional) - only enable if you know you want allow OpenClaw to control the local Docker engine
# - /var/run/docker.sock:/var/run/docker.sock
init: true
restart: unless-stopped
command:
[
"node",
"dist/index.js",
"gateway",
"--bind",
"${OPENCLAW_GATEWAY_BIND:-lan}",
"--port",
"18789"
]
# No published ports: access via Cloudflare Tunnel only
networks:
- openclaw_net
healthcheck:
test:
[
"CMD",
"node",
"-e",
"const http=require('http');const req=http.get('http://127.0.0.1:18789/healthz',r=>process.exit(r.statusCode===200?0:1));req.on('error',()=>process.exit(1));"
]
interval: 30s
timeout: 5s
retries: 10
start_period: 60s
cloudflared:
image: cloudflare/cloudflared:latest
container_name: openclaw-cloudflare-tunnel
# Easiest: share the gateway network namespace and point ingress to 127.0.0.1:18789
network_mode: "service:openclaw"
depends_on:
- openclaw
command: tunnel --no-autoupdate run --token ${CLOUDFLARE_TUNNEL_TOKEN} --no-tls-verify
restart: unless-stopped
networks:
openclaw_net:
driver: bridge
internal: false
attachable: false
volumes:
openclaw-data:
external: true
openclaw-shared:
external: true
Il y a ici deux choix de design qui comptent vraiment.
openclaw-data : persister l’assistant
Le volume openclaw-data empêche OpenClaw de redevenir jetable à chaque recréation du conteneur.Monté sur /home/node, il préserve l’état de travail d’OpenClaw entre les redémarrages et les mises à jour d’image. En pratique, cela signifie que le workspace, les notes locales, les fichiers mémoire, l’état lié à la configuration et les autres données côté utilisateur survivent même si le conteneur lui-même ne survit pas.Cette persistance compte, parce qu’OpenClaw n’est pas simplement un service web stateless.
C’est beaucoup plus proche d’un environnement opérationnel.
Si l’on veut de la continuité, de la mémoire durable, des fichiers de travail éditables et un agent capable d’accumuler du contexte dans le temps, il faut un stockage durable sous son répertoire personnel.
openclaw-shared : un pont entre l’assistant et mes propres fichiers
Le second volume, openclaw-shared, est tout aussi important, mais pour une autre raison.Je l’utilise comme un espace partagé direct entre OpenClaw et moi.
C’est là que je peux monter ou exposer les fichiers sur lesquels je veux que nous travaillions ensemble, au lieu de traiter l’assistant comme un appareil clos.Dans mon cas, cela fonctionne proprement parce que j’utilise un NAS.
Le même stockage sous-jacent peut donc être monté à la fois dans l’environnement OpenClaw et sur ma machine locale. Le côté « partagé » est donc littéral, et pas seulement conceptuel.Pour moi, l’exemple le plus parlant est Obsidian.
Ce montage partagé permet à OpenClaw et à moi de collaborer très concrètement sur la gestion de connaissances :
rédiger et affiner des notes
organiser du matériel de recherche
maintenir des listes de papiers
connecter plus directement la mémoire de l’assistant et ma propre base de connaissances
C’est l’une des raisons pour lesquelles le modèle home lab fonctionne si bien pour ce cas d’usage.
L’assistant cesse de ressembler à un simple endpoint de chatbot distant pour devenir un véritable participant à un environnement de travail.
Exposer OpenClaw de manière sécurisée
La partie la plus simple de tout ce setup a été de placer OpenClaw derrière Cloudflare Tunnel et Cloudflare Access.
Cette combinaison m’a donné immédiatement l’essentiel de ce que je voulais :
un accès distant depuis n’importe où
aucun besoin d’exposer un port de service directement sur Internet
une authentification basée sur l’identité devant l’application
une posture de sécurité plus propre que publier un dashboard en espérant que tout se passe bien
Autrement dit, l’exposition sécurisée n’était pas le problème difficile.
Cloudflare a résolu cette partie de manière élégante.
Pourquoi j’aime ce déploiement
Il n’y a rien d’exotique dans ce déploiement, et c’est une bonne chose.Ce que j’aime, c’est qu’il rend explicites les éléments qui comptent vraiment :
OpenClaw tourne dans un runtime contenu
l’état est persistant par design
les données partagées sont montées délibérément
aucun port de service n’est publié directement
Cloudflare gère l’exposition externe au lieu d’une gestion côté hôte
l’état de santé est vérifié localement depuis l’intérieur de la frontière de service
Cela donne une base opérationnelle solide.
Onboarding avec openclaw onboard
OpenClaw utilise la commande onboard pour effectuer la configuration initiale du système.Au lieu de configurer chaque partie à la main, cette commande centralise les éléments principaux en un seul endroit. En général, cela inclut :
choisir et configurer un fournisseur de modèle (via clé API ou authentification)
initialiser le workspace et l’état local
configurer le Gateway (adresse de bind, port, authentification)
activer éventuellement des canaux comme Telegram ou d’autres
Dans un setup local simple, cela se fait généralement une seule fois via la CLI interactive :
openclaw onboard
La commande demande les informations nécessaires et écrit ensuite la configuration localement (généralement sous ~/.openclaw/), afin que le runtime puisse démarrer avec tout déjà en place.
Pourquoi j’ai utilisé le flux interactif
Même si OpenClaw supporte un mode non interactif, j’ai finalement utilisé le processus d’onboarding interactif.La raison principale était l’authentification.
Les mécanismes d’authentification basés sur OAuth ne peuvent pas être entièrement préconfigurés via des variables d’environnement de la même manière que des clés d’API, donc dans ce cas le wizard reste le seul chemin possible.Je voulais précisément utiliser le flux OAuth de ChatGPT, parce que cet usage est couvert par mon abonnement ChatGPT.
Utiliser une clé API directe aurait signifié traiter cette installation comme une infrastructure facturée séparément, ce qui n’était pas ce que je voulais.Ce flux est intrinsèquement interactif. Pendant l’onboarding, OpenClaw ouvre un parcours de connexion dans le navigateur et attend qu’une URL de callback soit recopiée dans la CLI pour terminer l’authentification.C’est aussi le chemin officiellement supporté pour l’accès via l’abonnement Codex :
openclaw onboard --auth-choice openai-codex
La mise en place a été assez directe :
copier l’URL fournie par OpenClaw
l’ouvrir dans mon navigateur local
terminer la connexion
recopier l’URL de callback dans OpenClaw
Une fois cela fait, la configuration OAuth OpenAI a fonctionné, et le runtime a pu utiliser openai-codex/gpt-5.4 via cet accès basé sur OAuth.
Configuration des canaux
Différents canaux peuvent être configurés directement pendant l’onboarding.
Dans mon cas, j’ai choisi Telegram et Discord.La configuration elle-même est simple et déjà documentée ici, donc je ne vais pas répéter le pas-à-pas. Le point important est que la messagerie devient une partie de la configuration initiale au lieu d’être ajoutée après coup.Une fois configuré :
les messages envoyés via Telegram sont traités comme des entrées pour l’assistant
les réponses repartent par le même canal
le système peut être utilisé sans passer par l’interface web
Dans une configuration remote-first, cela fournit un moyen léger d’interagir avec le système sans devoir ouvrir une session authentifiée complète à chaque fois.Petite note sur WhatsApp.On peut aussi voir passer des références à des intégrations WhatsApp. Contrairement à Telegram, qui fournit une API bot stable et bien supportée, WhatsApp impose des règles plus strictes en matière d’automatisation. Certaines intégrations s’appuient sur des méthodes non officielles. Dans ces cas-là, les comptes peuvent être signalés ou bannis pour non-respect des conditions d’utilisation de la plateforme.Utiliser l’API officielle WhatsApp Business évite ce problème, mais ajoute de la complexité de mise en place et des contraintes opérationnelles. Pour mon usage, Telegram était l’option la plus simple et la plus prévisible.
Problème caché après l’onboarding : le piège du profil d’outils
C’est l’un des points de friction de cette installation.Dans mon déploiement, le gateway ne fonctionnait pas comme un simple relais de messagerie devant un autre environnement d’exécution plus riche.
Il constituait en pratique le runtime opérationnel lui-même.
Il n’y avait pas de conteneur séparé côté CLI pour prendre en charge la partie exécution la plus lourde.Cela voulait dire que l’instance en cours devait faire du vrai travail :
exécuter des commandes
accéder à des fichiers
naviguer sur le web
gérer des tâches de configuration
se comporter comme un véritable agent opérationnel plutôt que comme une simple surface de chat
Par défaut, le profil d’outils actif se comportait davantage comme un profil orienté messagerie.
Cela a probablement du sens dans des déploiements plus classiques et découpés.
Dans ce setup, en revanche, cela donnait l’impression d’un système étrangement incomplet.La solution a été de basculer manuellement le profil d’outils sur full dans la vue de configuration brute.
Le panneau Agents ne fonctionnait tout simplement pas pour ce changement précis.
Les contrôles donnaient l’impression de devoir suffire, mais le seul chemin que j’ai trouvé vraiment fiable a été l’édition directe de la configuration brute.
Après rechargement de la configuration, tout a fonctionné comme prévu.
Exploiter OpenClaw : là où il devient réellement utile
Une fois la « plomberie » en place, la partie qui a commencé à compter le plus n’était plus le schéma de déploiement lui-même.
C’était l’expérience opérationnelle au quotidien.
C’est là qu’OpenClaw a cessé de ressembler à un simple exercice d’installation intéressant pour devenir quelque chose que je pouvais réellement utiliser.Le mot-clé ici, c’est skill.Un skill est une procédure opératoire réutilisable pour l’agent : un workflow empaqueté qui peut inclure des instructions, des conventions, des références et un contexte spécifique à la tâche, afin que l’assistant traite un travail récurrent de manière plus cohérente.Autrement dit, au lieu de réexpliquer le même processus à chaque fois, on apprend au système comment on veut qu’une certaine classe de tâches soit exécutée, puis on laisse ce schéma persister.
Cela peut être quelque chose de petit et très pratique, comme des règles de formatage ou de rédaction, ou quelque chose de plus opérationnel, comme la manière d’exécuter un workflow récurrent de recherche ou d’écriture.C’est important parce que cela transforme le système : on passe d’un assistant générique à quelque chose que l’on peut façonner autour de ses propres habitudes de travail.
Les skills que j’ai le plus utilisées
Ce qui a vraiment fait déclic pour moi, c’est la combinaison d’un workspace persistant et de quelques skills concrètes qui correspondent bien à la façon dont je travaille déjà.Les plus utiles jusqu’ici ont surtout été celles liées à la recherche, aux workflows d’écriture et au support opérationnel léger.
En pratique, cela veut dire par exemple :
travailler avec ma base de connaissances Obsidian via le montage partagé
rédiger et affiner des notes ou des idées d’articles directement sur place au lieu de copier-coller en permanence
utiliser des skills ciblées pour des workflows récurrents plutôt que de réexpliquer la même tâche à chaque fois
conserver une mémoire locale légère et du contexte opérationnel dans le workspace OpenClaw
C’est là que le système commence à accumuler de la valeur. Au lieu de refaire le travail, il commence à réutiliser une structure existante.
Je peux progressivement le façonner autour de workflows répétables et laisser ces workflows persister.
Les cron jobs ont donné au système une vraie dimension d’infrastructure
Un autre élément qui a fait une vraie différence, c’est le cron.C’est là qu’OpenClaw a commencé à moins ressembler à quelque chose que j’« utilisais quand on le demandait » et davantage à quelque chose capable de maintenir une partie de mon workflow en arrière-plan.
Dès que des tâches planifiées sont en place, le système cesse d’être purement réactif.
Il commence à se comporter comme une véritable infrastructure opérationnelle.C’est important parce qu’une grande partie du travail utile n’est pas interactive.
Certaines tâches doivent arriver au bon moment, d’autres doivent se répéter, et d’autres encore relèvent simplement de cette maintenance qu’on oublie très facilement si tout dépend d’un déclenchement manuel.Dans mon cas, cela incluait des briefs récurrents, des tâches de vérification et un workflow de recherche orienté.
Un bon exemple est le cron job lié au traitement des papiers à fort impact. Quand un papier est suffisamment important pour déclencher un traitement plus poussé, l’automatisation l’envoie dans un flux où spider.js étend le voisinage de citations et renvoie de la télémétrie vers mon workflow de curation de la VIP watchlist. Un seul papier intéressant devient ainsi un signal plus large sur les auteurs, laboratoires ou groupes de recherche qui méritent peut-être davantage d’attention avec le temps.
Ce que j’aime là-dedans, c’est qu’il ne s’agit pas simplement d’automatisation au sens où l’on exécute un script à heure fixe. Cela construit de la continuité opérationnelle dans le système. Une tâche planifiée peut détecter, vérifier, enrichir et réinjecter les résultats dans le workflow global sans exiger une intervention manuelle à chaque étape.La combinaison d’un état persistant, de fichiers partagés et de tâches planifiées change la nature du système. Il commence à se comporter moins comme une démo et davantage comme une petite control plane pour des workflows personnels.
Principaux enseignements de ce déploiement
La première chose que je dirais, c’est que l’installation a été plus simple que ce que la topologie laissait penser.L’architecture ressemble à un système en couches : hôte distant, frontière de conteneur, tunnel, couche d’identité, puis runtime agent derrière tout cela. Dit comme ça, cela peut paraître lourd.En pratique, ce n’est qu’une composition de composants bien connus. Chaque couche a une responsabilité claire, et aucune ne s’est comportée de manière atypique.Le système n’est pas vraiment compliqué ; il est surtout explicite.
Une fois que chaque pièce est comprise, l’ensemble devient prévisible plutôt que complexe.La deuxième chose que je dirais, c’est que le choix du modèle compte plus que je ne l’avais imaginé.Avant de me fixer sur OpenAI via Codex, j’ai passé environ une semaine à tester Google Gemini parce que j’en avais entendu du bien et que je pensais que ce serait peu coûteux. Je m’attendais à quelque chose autour de 5 USD par mois pour mon usage.
Au final, cela m’a coûté 37,94 €, et dans mon usage précis la qualité n’a pas justifié ce coût.Heureusement, OpenAI venait tout juste de sortir openai-codex/gpt-5.4, et cela a clairement changé la donne.
Pour ce setup, c’était nettement un meilleur choix, à la fois en qualité et en prévisibilité des coûts.
Dans la pratique, cela s’est montré plus solide, et l’expérience globale est devenue beaucoup plus convaincante pour la manière dont j’avais envie d’utiliser OpenClaw.Si quelqu’un me demandait aujourd’hui ce que je recommande, ma réponse est sans appel : utilisez GPT-5.4 via Codex.C’est probablement le résumé le plus honnête que je puisse faire.
Une fois le modèle de déploiement bien compris, OpenClaw lui-même n’était pas particulièrement difficile à faire tourner ni à adapter.
Et une fois les angles morts corrigés, l’expérience d’usage a été franchement positive.C’est précisément pour cela que je pense que ce projet mérite l’attention.
Non pas parce que tous les cas limites sont déjà abstraits, mais parce que même dans un setup un peu atypique, il s’est montré suffisamment pratique pour devenir très utile rapidement.
Réflexions finales
La partie intéressante de cette installation a été de comprendre comment faire tourner OpenClaw à distance tout en le gardant sûr, utilisable et malléable sur le plan opérationnel, alors qu’une grande partie de l’écosystème alentour continue de supposer tacitement que tout vit sur un seul laptop.C’est aussi une raison supplémentaire pour laquelle je pense que des outils comme OpenClaw comptent.
Ils remettent de vraies questions d’ingénierie au centre de la conversation.Maintenant, j’ai aussi envie de pousser cette installation plus loin dans plusieurs directions.Un domaine que j’ai particulièrement envie d’explorer est l’architecture multi-agents. Faire tourner un seul assistant est déjà utile, mais le modèle le plus intéressant reste celui d’un système d’agents spécialisés qui coopèrent à travers des frontières clairement définies.En pratique, cela veut dire déployer plusieurs serveurs MCP dans mon cluster, chacun chargé d’une classe de tâches spécifique plutôt que de dépendre d’un unique runtime généraliste.Une autre direction consiste à traiter le code et les skills générés par l’IA comme des artefacts à part entière. Au lieu de les laisser dans le workspace interne de l’assistant, je veux les versionner et les relire comme n’importe quel autre morceau de code.L’intégration avec mon environnement GitLab permettrait un modèle plus collaboratif : l’agent peut générer et modifier des artefacts, mais je peux ensuite intervenir, éditer, relire et façonner ces résultats directement. Le but n’est pas de rester passivement devant le système, mais de coopérer activement avec lui via un état partagé et versionné.Ces directions pointent vers un changement plus large : passer de l’interaction avec un assistant à l’exploitation d’un système.Je compte aussi passer davantage de temps à tester NemoClaw pour mieux comprendre ce qu’il cherche à être en pratique. Cette comparaison deviendra probablement plus intéressante à mesure que l’écosystème évoluera.En plus de cela, je prévois d’intégrer davantage de contrôle et de supervision à mon pod OpenClaw à l’aide d’une stack EDR open source. Cela méritera sans doute un post à part entière une fois que j’aurai quelque chose de plus concret à dire.Et ces questions ne feront que devenir plus importantes à mesure que les agents cesseront d’être des démos pour devenir des éléments d’infrastructure.Et cette transition est déjà en cours.
