Si vous avez lu mon précédent article détaillant l’architecture et la stack technique que j’ai retenu pour déployer OpenClaw, vous savez déjà pourquoi j’ai choisi de faire tourner cette solution sur mon cluster Nutanix AHV. Aujourd’hui, on passe à la pratique ! Je vais vous montrer, étape par étape, comment déployer votre propre instance sur une machine virtuelle Ubuntu fraîchement installée.

Avant de lancer les hostilités, petit rappel de ma configuration. J’ai provisionné une VM sous Nutanix AHV avec :

• 8 vCPU
• 32 Go de RAM
• 250 Go de stockage
• une carte NVIDIA Tesla P4 en PCI Passthrough

💡 Pourquoi avoir privilégié le Passthrough complet plutôt que du vGPU (virtual GPU) ? Tout simplement pour garantir des performances d’inférence quasi « bare-metal ». En donnant un accès direct et exclusif au matériel physique à notre VM, on élimine totalement l’overhead (la latence) lié à la couche de virtualisation.

C’est parti pour le déploiement.

Préparation de la VM Ubuntu : Système et Pilotes NVIDIA

La toute première étape consiste à préparer le terrain pour déployer notre IA.

Ubuntu 24.04 : Mise à jour du système d’exploitation

C’est une règle que j’applique à chaque fois que je déploie un nouveau système d’exploitation. Dès que je me connecte en SSH, je m’assure que tous les paquets sont à jour pour éviter de futures failles de sécurité ou des conflits de dépendances.

sudo apt update && sudo apt upgrade -y

GPU : Installation des drivers NVIDIA

Pour qu’OpenClaw puisse exploiter la puissance de calcul de ma Tesla P4, le système d’exploitation doit être en mesure lui parler correctement. Voici les commandes à passer pour installer le drivers (vous pouvez accéder à un guide plus détaillé sur le blog) :

sudo apt install nvidia-driver-535-server -y
sudo reboot

Une fois la machine redémarrée, on se reconnecte et on tape la commande pour vérifier que notre GPU est bien détecté et prêt à travailler :

nvidia-smi

Node.js et OpenClaw

Installation de Node.js 22

OpenClaw est bâti sur Node.js. Pour s’assurer de disposer d’un environnement d’exécution récent et performant (ici la version 22), on ajoute le dépôt officiel de NodeSource avant de lancer l’installation :

curl -fsSL [https://deb.nodesource.com/setup_22.x](https://deb.nodesource.com/setup_22.x) | sudo -E bash -
sudo apt install -y nodejs

Déploiement de base d’OpenClaw

Maintenant que NodeJS est en place, on passe à l’installation d’OpenClaw. Un simple script curl fourni par les développeurs s’occupe du gros du travail :

curl -fsSL [https://openclaw.ai/install.sh](https://openclaw.ai/install.sh) | bash

Une fois l’installation terminée, le système lance automatiquement l’assistant de configuration de votre instance. Je détaillerai cette étape ainsi que les créations de clés API (Discord, Telegram, etc…) dans un futur article.

Une petite manipulation est requise juste après l’installation d’OpenClaw si on veut pouvoir utiliser les commandes “openclaw” sans contrainte. Il faut ajouter le répertoire d’installation local à notre variable d’environnement PATH (pensez à adapter le nom d’utilisateur si vous n’utilisez pas administrateur) :

export PATH="/home/administrateur/.npm-global/bin:$PATH"

💡 Pourquoi cette manipulation ? C’est une excellente pratique de sécurité que je vous recommande. En exportant le PATH vers ~/.npm-global/bin, on évite d’installer des paquets globaux NPM avec les privilèges root (sudo). Cela réduit considérablement les surfaces d’attaque et vous épargne les éternels conflits de permissions sous Linux !

Exposer proprement OpenClaw avec Caddy

Par défaut, l’interface web d’OpenClaw écoute sur le port 18789. Au lieu d’attaquer ce port de manière brute, je préfère toujours placer un reverse proxy devant mes applications. Pour ce lab, mon choix s’est porté sur Caddy.

sudo apt install -y caddy

💡 Pourquoi Caddy plutôt qu’Apache ou Nginx ? Parce que Caddy est redoutablement efficace. Là où Nginx réclame parfois de longs blocs de configuration pour du proxying simple, Caddy accomplit le même travail en littéralement trois lignes de code, le tout de manière ultra légère.

On édite son fichier de configuration :

sudo vi /etc/caddy/Caddyfile

Et on remplace l’intégralité du contenu par les instructions suivantes (remplacez l’IP par celle de votre VM, dans mon cas 192.168.84.134) :

192.168.84.134 {
    reverse_proxy 127.0.0.1:18789
}

Il ne reste plus qu’à redémarrer le service pour que le proxy prenne le relais :

sudo systemctl restart caddy

Sécurité réseau : Verrouiller l’instance OpenClaw

Avoir une instance fonctionnelle c’est bien, la sécuriser c’est indispensable. Même si vous êtes sur votre réseau local (LAN), il ne faut jamais laisser l’accès libre à votre interface de contrôle. Nous allons appliquer une configuration stricte via les commandes CLI d’OpenClaw.

On commence par restreindre l’écoute de la Gateway à la boucle locale pour empêcher tout accès direct :

openclaw config set gateway.bind loopback

On force ensuite le mode de fonctionnement en local, et on active l’authentification par token (le minimum syndical) :

openclaw config set gateway.mode local
openclaw config set gateway.auth.mode token

Enfin, comme nous passons par Caddy, il faut autoriser les requêtes Cross-Origin (CORS) provenant de notre adresse IP, sans quoi le navigateur bloquera la page (n’oubliez pas d’adapter l’IP) :

openclaw config set gateway.controlUi.allowedOrigins '["[https://192.168.84.134](https://192.168.84.134)"]'

On redémarre le service pour appliquer notre blindage :

openclaw gateway restart

💡 Le pattern de sécurité appliqué ici s’apparente à du « Zero Trust » local. En forçant OpenClaw sur le loopback (127.0.0.1), on s’assure qu’absolument tout le trafic est obligé de passer par notre proxy Caddy. Couplé au filtrage CORS et à l’authentification, on protège un minimum notre instance contre d’éventuels scans ou scripts malveillants sur le réseau.

Premier contact et validation de la configuration

Récupération du Token d’accès

Maintenant que les portes sont fermées, il nous faut la clé. Le token d’authentification a été généré automatiquement lors de l’installation. On va aller le pêcher directement dans le fichier JSON de configuration :

grep -i token ~/.openclaw/openclaw.json

Copiez précieusement cette chaîne de caractères. Ouvrez ensuite votre navigateur et accédez à votre interface Web (ex: https://192.168.84.134).

Entrez le token dans l’encart « Gateway Token ».

Approbation du périphérique

Une fois connecté, vous remarquerez qu’il manque quelque chose : le système attend que l’on approuve le « périphérique » (le PC ou la tablette depuis laquelle on souhaite utiliser OpenClaw) pour lui accorder le droit de traiter des requêtes.

Retournez dans votre terminal pour lister les périphériques en attente :

openclaw devices list

Repérez l’ID de votre périphérique dans la liste (une chaîne de type UUID) et approuvez-le :

openclaw devices approve b7beb7fa-fa4e-46e9-aec1-282bcce881f6

💡 L’approbation d’un périphérique (devices approve) est bien plus qu’une simple formalité d’interface. C’est une sorte de handshake cryptographique. Ce mécanisme garantit qu’aucune machine non sollicitée ne puisse se greffer à votre instance cluster OpenClaw à votre insu !

Tests d’interaction

L’instance OpenClaw est à présent 100% opérationnelle ! Pour valider l’ensemble de notre stack, rien de tel qu’un test grandeur nature. Vous pouvez envoyer un premier prompt sur le chat intégré de l’interface web, ou configurer un pont pour envoyer un message côté Discord.

Conclusion

Nous sommes passés d’une simple VM Ubuntu à un véritable serveur d’inférence sécurisé, propulsé par Node.js et accéléré par un GPU NVIDIA Tesla P4 dédié via Nutanix AHV. L’architecture est propre, sécurisée derrière un proxy Caddy, et prête à encaisser nos requêtes.

Mais ce n’est que le début. Dans les prochains articles, nous irons encore plus loin : je vous montrerai comment configurer OpenClaw via l’assistant de départ, déployer des modèles locaux via Ollama, créer un bot Discord interactif, et même injecter des clés API Google pour doter notre IA de capacités de recherche. Restez connectés !

Si vous suivez un peu mes pérégrinations sur le blog, vous savez que j’adore triturer mes clusters et tester des trucs un peu out-of-the-box (cf. mes articles avec le Steamdeck par exemple). Récemment, je me suis fait une réflexion : Gemini ou Claude dans le cloud public, c’est super pour coder un script Python ou rédiger des mails. Mais quand il s’agit de lui demander d’interagir avec notre infrastructure locale, c’est là que ça coince.

Je me suis donc demandé comment je pourrais connecter l’intelligence artificielle au plus près de mes VMs. C’est dans cette optique que j’ai mis les mains sur OpenClaw. Honnêtement, ça a un peu été le parcours du combattant au démarrage. Fini le simple gadget conversationnel, on parle ici de déployer une véritable IA Privée sur un cluster Nutanix AHV capable d’agir sur notre infrastructure. Laissez-moi vous présenter la stack technique que j’ai retenue pour cette expérience.

OpenClaw : qu’est-ce que c’est ?

Pour ceux qui vivaient dans une grotte ces derniers mois, OpenClaw c’est un projet GitHub qui a dépassé les 300k étoiles en seulement quelques mois. Imaginez un traducteur de pensée ultra-intelligent couplé à un majordome. Au lieu de cliquer sur des dizaines de menus dans une interface complexe, vous demandez simplement à votre infrastructure de travailler pour vous en langage naturel (via une interface web universelle ou même des messageries comme WhatsApp et Telegram). Il est même capable de bosser tout seul pendant que vous dormez !

Mais là où ça devient passionnant pour nous, les ingénieurs, c’est sous le capot. OpenClaw n’est pas un énième modèle de langage (LLM) « stateless » qui oublie tout à chaque nouvelle requête. C’est une véritable Agentic Gateway. Concrètement, cela signifie qu’elle orchestre des agents autonomes équipés d’outils. Ces agents peuvent être configurés pour taper directement dans les API privées de notre cluster (comme les API REST de Prism Element ou Prism Central), coder, parcourir le web et en synthétiser certaines informations. Bref, on ne pose plus simplement des questions à l’IA, on lui délègue des tâches.

Pourquoi l’héberger en Self-hosted ?

Sur le terrain, la question de la gouvernance des données se pose à la seconde où l’on prononce le mot « IA ». Hors de question d’envoyer des informations sensibles sur des serveurs dont je n’ai pas la maîtrise !

Faire le choix du Self-hosted (auto-hébergement) avec OpenClaw, c’est reprendre le contrôle absolu. Les flux de données, les logs d’exécution et les identifiants d’API restent cloisonnés bien au chaud sur mon réseau, isolés d’internet si on le souhaite.

Architecture et Stack Technique

Pour ce projet, hors de question de faire un simple « Next, Next, Finish » sur un coin de table. Voici l’architecture technique robuste que j’ai fini par valider pour mon déploiement.

Le socle : Nutanix AHV & Ubuntu 24.04 LTS

Pour faire tourner la bête, il faut des fondations solides. J’ai provisionné une machine virtuelle sous Ubuntu 24.04 LTS hébergée directement sur mon cluster Nutanix AHV.

Côté dimensionnement, je suis parti sur 8 vCPU, 32 Go de RAM et 250 Go de stockage dédié. Vous allez peut-être me dire : « 32 Go pour une gateway, c’est pas un peu too much ? » La gateway va devoir ingérer des flux de données conséquents, maintenir le cache des différents agents actifs, et potentiellement gérer du requêtage d’API lourd en parallèle. Et puis, je peux affecter ces ressources sur mon lab, alors pourquoi s’en priver ?

Le moteur applicatif : NodeJS 22

Au cœur d’OpenClaw, la magie opère grâce à NodeJS 22. C’est le moteur d’exécution qui fait tourner la gateway et ses intégrations d’agents IA.

Pourquoi Node 22 est un excellent choix architectural ici ? Pour sa gestion de l’asynchrone (Event Loop). Quand vous demandez à OpenClaw de faire un rapport d’état sur 50 VMs, la gateway va initier de multiples appels d’API vers Prism Central tout en maintenant votre flux WebSocket ouvert pour vous répondre en temps réel dans l’interface de chat. NodeJS excelle dans cette gestion de la concurrence non-bloquante.

Le routage réseau : Caddy

Le mode de fonctionnement habituel d’OpenClaw, c’est de le déployer en local sur la machine depuis laquelle on va s’y connecter, ou bien de monter un tunnel pour pouvoir accéder à l’instance distante. On ne va pas se mentir, j’avais envie de taper l’IP dans mon navigateur et de pouvoir accéder à mon instance, que je sois sur mon PC ou sur ma tablette.

Pour rendre ceci possible, j’utilise un reverse proxy sous Caddy. Caddy gère le routage du trafic et le chiffrement HTTPS de manière totalement automatisée.

Je vous entends déjà me dire : “Oui mais si un mec se connecte sur ton réseau local, il aura accès à ton instance !”. Eh bien non ! Parce qu’OpenClaw intègre nativement un système de Device Whitelisting (liste blanche de périphériques). Si votre PC n’a jamais été connecté à l’instance, vous devrez fournir le “Gateway Token”. Ensuite, vous devrez accepter cette nouvelle connexion du côté de l’instance OpenClaw. Vous l’aurez compris, seuls les périphériques préalablement autorisés peuvent profiter de votre instance locale.

Le point d’entrée : Discord

Le choix du point d’entrée, ce qui vous permettra d’interagir avec OpenClaw, c’est souvent une question de goûts et de couleurs.

OpenClaw intègre directement un système de chat pour que vous puissiez discuter avec lui. C’est bien, c’est natif, mais inaccessible si je ne suis pas chez moi. Le système propose également de configurer des points d’entrée externes comme Telegram, WhatsApp, Discord ou encore Teams et Slack. Et ça, c’est clairement un gros plus car cela donne des possibilités quasi illimitées !

Et ensuite ?

L’objectif de cet article était de vous présenter l’architecture envisagée pour mon assistant OpenClaw, de comprendre ce que l’on déploie et pourquoi. Nous avons donc une stack technique cohérente, performante grâce à Nutanix AHV, et hébergée en local.

Dans un prochain article, je vous expliquerai comment installer OpenClaw étape par étape jusqu’à avoir une instance fonctionnelle.