Dans un précédent article, nous avons vu comment déployer OpenClaw sur Nutanix AHV. Cependant, avant de pouvoir profiter pleinement de cet agent IA autonome, il est crucial de préparer le terrain. OpenClaw n’est pas qu’un simple script : c’est un écosystème qui s’appuie sur plusieurs briques technologiques pour « penser » (LLM local), « exécuter » (Node.js) et « chercher » (SearXNG).

Dans cet article, nous allons détailler l’installation pas-à-pas de tous les prérequis nécessaires sur votre machine virtuelle (sous Ubuntu), en expliquant pour chacun pourquoi il est indispensable au bon fonctionnement d’OpenClaw.

1. Pilotes NVIDIA : Libérer la puissance du GPU

OpenClaw peut s’appuyer sur des modèles de langage (LLM) exécutés localement. Bien qu’il soit techniquement possible de faire tourner ces modèles sur un processeur (CPU), les performances seraient extrêmement lentes. L’installation des pilotes NVIDIA permet au système d’exploiter la carte graphique (GPU) allouée à votre VM via Nutanix AHV (vGPU ou Passthrough), garantissant ainsi une inférence rapide et fluide de l’IA.

Voici comment mettre à jour votre système et installer les pilotes adéquats :

# Mise à jour du système
sudo apt update && sudo apt upgrade -y

# Installation du pilote serveur NVIDIA
sudo apt install nvidia-driver-535-server -y

# Redémarrage nécessaire pour la prise en compte
sudo reboot

Après le redémarrage, vérifiez que votre GPU est bien reconnu avec la commande suivante :

nvidia-smi

2. Node.js (v24) : Le moteur d’exécution d’OpenClaw

Le cœur de la logique d’OpenClaw est développé en JavaScript/TypeScript. Node.js est l’environnement d’exécution qui permet de faire tourner le code de l’agent, de gérer ses dépendances et d’orchestrer les appels entre l’interface, le modèle d’IA et les différents outils. Nous ciblons ici la version 24.x pour assurer une compatibilité optimale.

# Ajout du dépôt NodeSource et installation
curl -fsSL [https://deb.nodesource.com/setup_24.x](https://deb.nodesource.com/setup_24.x) | sudo -E bash -
sudo apt install -y nodejs

# Vérification de la version installée
node --version  # doit afficher v24.x

3. Ollama & Qwen 2.5 : Le cerveau local de l’opération

Ollama est l’outil qui va nous permettre de télécharger et de faire tourner facilement notre modèle d’IA en local. Pour OpenClaw, nous allons utiliser le modèle Qwen2.5 (7B). Pourquoi ce choix ? C’est un modèle léger (adapté pour les GPU avec environ 8 Go de VRAM) et, surtout, il est excellent en « Tool Calling » (l’appel d’outils). C’est cette capacité qui permet à OpenClaw de comprendre qu’il doit exécuter une recherche web ou lancer un script plutôt que de simplement générer du texte.

# Installation d'Ollama
curl -fsSL [https://ollama.ai/install.sh](https://ollama.ai/install.sh) | sh

# Démarrer le service Ollama (en arrière-plan)
ollama serve &

# Dans un autre terminal, vérifiez qu'Ollama détecte bien le GPU :
nvidia-smi  # Vous devriez voir ollama dans la liste des processus GPU

# Puller (télécharger) le modèle recommandé
ollama pull qwen2.5:7b

# Tester le modèle et vérifier son exécution sur le GPU
ollama run qwen2.5:7b "dis bonjour"

# Pendant que le modèle génère une réponse, vérifiez l'utilisation de la VRAM
nvidia-smi

4. Docker : L’infrastructure de conteneurisation

Afin d’étendre les capacités d’OpenClaw (notamment pour la recherche web que nous verrons juste après), nous avons besoin de services tiers. Docker permet de déployer ces services de manière isolée, standardisée et rapide, sans polluer notre système hôte avec de multiples dépendances complexes.

# Installation des dépendances initiales
sudo apt update
sudo apt install -y ca-certificates curl gnupg

# Ajout de la clé GPG officielle de Docker
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL [https://download.docker.com/linux/ubuntu/gpg](https://download.docker.com/linux/ubuntu/gpg) | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Configuration du dépôt Docker
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  [https://download.docker.com/linux/ubuntu](https://download.docker.com/linux/ubuntu) \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Installation des paquets Docker
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Ajout de votre utilisateur au groupe docker pour éviter d'utiliser 'sudo' à chaque fois
sudo usermod -aG docker $USER
newgrp docker

# Vérification de l'installation
docker --version

5. SearXNG : Donner un accès au Web à l’IA

Pour qu’OpenClaw soit un véritable agent de recherche performant, il ne peut pas se contenter des données contenues dans le modèle Qwen (qui s’arrêtent à sa date d’entraînement). SearXNG est un métamoteur de recherche respectueux de la vie privée. En l’installant via Docker, nous offrons à OpenClaw une API (sur le port 8080) qu’il va pouvoir utiliser pour aller chercher en temps réel des informations sur le web et sourcer ses réponses.

# Créer un répertoire dédié pour la configuration
mkdir -p ~/searxng && cd ~/searxng

# Lancer le conteneur SearXNG
docker run -d \
  --name searxng \
  --restart unless-stopped \
  -p 8080:8080 \
  searxng/searxng

# Vérifier que le conteneur tourne correctement
docker ps

# Tester que l'API de SearXNG répond bien
curl http://localhost:8080

6. Homebrew & GCC : Les outils de compilation

L’écosystème Node.js d’OpenClaw fait parfois appel à des bibliothèques bas niveau ou à des packages natifs qui nécessitent d’être compilés directement sur votre machine lors de leur installation. Homebrew (le gestionnaire de paquets bien connu sur macOS, très pratique aussi sur Linux) et le compilateur GCC sont indispensables pour éviter les erreurs lors de la phase d’installation finale des dépendances (les fameux npm install).

# Installer le package de compilation de base Ubuntu
sudo apt-get install build-essential

# Installer Homebrew
/bin/bash -c "$(curl -fsSL [https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh](https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh))"

# Les instructions de fin d'installation d'Homebrew vous demanderont
# d'ajouter Homebrew à votre PATH. Généralement cela ressemble à ceci :
# (Assurez-vous d'adapter le chemin si nécessaire)
echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"' >> /home/$USER/.bashrc
eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"

# Installation de GCC via Homebrew
brew install gcc

Conclusion

Votre machine virtuelle sous Nutanix AHV est désormais un environnement riche et complet, équipé de pilotes GPU performants, d’un moteur d’exécution (Node.js), d’un LLM prêt à répondre (Ollama), d’un accès au Web (SearXNG) et des bons outils de compilation.

Le terrain est parfaitement préparé. Il ne vous reste plus qu’à finaliser l’installation de l’application elle-même en suivant la suite de notre guide sur OpenClaw.

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.