Faire ses valises pour la Silicon Valley ça fait toujours son petit effet, même pour un Nutanix Technology Champion. Demain matin, samedi 24 octobre à 6h30, je décolle de Lyon Saint-Exupéry. Après une courte escale à Amsterdam Schiphol où je retrouverai mes collègues et amis NTC européens (Jeroen Tielen, Patrick Damen, Bart Donders et Jonas Hogman) nous traverserons l’Atlantique tous ensemble sur le même vol direction San Francisco, avant de rejoindre notre hôtel à San José. L’objectif ? 2 jours au quartier général de Nutanix pour le NTC Tech Connect, un événement exclusif orchestré d’une main de maitre par Angelo Luciani. Avec un programme quasiment 100 % focalisé sur Nutanix Kubernetes Platform (NKP) et l’Intelligence Artificielle (NAI), je vous embarque dans les coulisses de ce voyage au cœur de l’écosystème Nutanix.
De Lyon à la Silicon Valley : L’esprit communautaire des Nutanix Technology Champions (NTC)
Au-delà des onze heures de vol qui nous attendent entre Amsterdam et la Californie, ce type de déplacement illustre parfaitement ce que j’aime dans le programme NTC : sa dimension humaine et communautaire. Partager ce voyage transatlantique avec des experts comme Jeroen, Patrick, Bart et Jonas transforme déjà le trajet en un mini-sommet technique à 10 000 mètres d’altitude.
Mais le NTC Tech Connect n’est pas un voyage de récompense ou une grand-messe marketing. C’est une immersion technique intense, sous accord de confidentialité (NDA), pensée par Angelo Luciani pour un groupe de NTC triés sur le volet, pour créer un pont direct entre le terrain et les équipes d’ingénierie de San José. Notre rôle en tant que NTC n’est pas seulement d’écouter la roadmap : c’est surtout de challenger les Product Managers et les Distinguished Engineers avec nos réalités d’architectes, nos contraintes de production et les cas d’usage concrets de nos clients européens.
Immersion au Nutanix HQ : Deux jours au cœur de la stratégie Cloud Native et IA
Nous attaquerons dès lundi matin deux journées denses au quartier général de Nutanix. Sans dévoiler les détails précis de l’agenda, le fil rouge de cette édition est limpide : l’accompagnement des applications modernes et l’industrialisation de l’IA sur nos infrastructures hybrides.
Nutanix Kubernetes Platform (NKP) : Architecture, sécurité et résilience à grande échelle
Le premier grand volet des échanges sera consacré à Nutanix Kubernetes Platform (NKP). Pour ceux qui suivent l’évolution de l’écosystème, NKP est la réponse de Nutanix pour simplifier et industrialiser la gestion de clusters Kubernetes, que ce soit on-premises ou dans le cloud. Nous allons plonger dans les meilleures pratiques de topologies de déploiement, la résilience des architectures et surtout la gestion de la sécurité à l’échelle d’une flotte complète. Quand il faut gérer des dizaines de clusters en production, le maintien en condition opérationnelle et l’observabilité deviennent les vrais sujets critiques.
L’accélération sur l’IA : De la vision produit à l’inférence avec Nutanix Enterprise AI (NAI)
L’autre pilier majeur de ce Tech Connect, c’est évidemment l’Intelligence Artificielle, et plus particulièrement son exécution sur NKP. Loin du simple buzzword, l’enjeu est de comprendre comment exécuter des workloads IA de manière pragmatique, sécurisée et performante. Les sessions prévues avec les équipes produits vont nous permettre de décortiquer Nutanix Enterprise AI (NAI) sous l’angle de l’inférence et de l’orchestration des flux (notamment autour des concepts d’Agent Gateway). C’est exactement là que se situe le défi actuel : offrir aux entreprises une plateforme clé en main pour consommer des modèles d’IA sans complexifier l’infrastructure sous-jacente.
Conclusion : L’aventure humaine et la suite sur le blog
Au-delà des sessions techniques intenses, ce NTC Tech Connect est aussi une véritable aventure humaine. Les soirées communautaires prévues à San José seront l’occasion idéale de prolonger les débats autour d’un verre et de confronter nos retours d’expérience sur nos projets respectifs. C’est souvent lors de ces échanges entre passionnés que naissent les meilleures idées !
Mon vol retour décollera de San Francisco mercredi 28 octobre pour un atterrissage à Lyon le jeudi 29 après-midi. Le temps de digérer le décalage horaire et de trier mes notes (en filtrant tout ce qui reste sous NDA), je vous donne rendez-vous très vite pour un débriefing complet de ce qui nous aura été présenté. D’ici là, n’hésitez pas à me suivre sur X (Twitter) et LinkedIn où je partagerai quelques coulisses de ce voyage californien en direct !
En septembre 2024, je publiais un article sur la création d’un homelab sous Nutanix CE dans lequel j’écrivais que la première question à se poser était celle de l’usage : des machines virtuelles éphémères pour monter en compétence, ou des services pour soi et pour sa famille ? J’avais répondu « des tests », et j’ai construit toute mon infrastructure autour de cette réponse.
Deux ans plus tard, la réponse a changé et l’infrastructure, elle, n’a pas bougé. Avant d’entamer le chantier, voici à quoi ressemblait mon homelab Nutanix au 1er juillet 2026.
L’état des lieux de mon homelab Nutanix au 1er juillet 2026
À cette date, tout ce qui tourne chez moi tient sur trois machines. Le réseau d’abord, monté il y a quatre ans à la construction de la maison et entièrement basé sur du Ubiquiti : une Dream Machine Pro, un switch USW Pro 24 PoE et quelques Flex répartis dans les pièces, le tout raccordé à une Freebox Delta en fibre 10 Gb/s.
Le cluster ensuite, un châssis Intel S2600WTTR installé dans le garage parce qu’il n’a pas droit de séjour dans la maison, sur des rails coulissants vissés dans les solives faute de baie, un nœud unique sous Nutanix CE 2.1, avec deux ou trois machines virtuelles de test dessus. J’en ai détaillé la configuration matérielle à l’époque, je vous invite à consulter mon article à ce sujet.
Ce serveur de 2016, je l’ai récupéré dans une précédente expérience professionnelle. Il était tombé en panne matérielle et l’administration ne souhaitait pas engager la réparation, compte tenu de son âge et du remplacement de l’infrastructure déjà lancé vers des clusters Nutanix neufs. Je l’ai donc sorti et remis en état à mes frais.
Tout le reste des décisions matérielles découle de ce point de départ. Une seule alimentation raccordée sur les deux, volontairement, parce que rien de critique ne tourne dessus et qu’une panne se traduit au pire par un cluster arrêté le temps d’un week-end, puis une redondance disque partielle que j’assumais déjà à l’époque comme un compromis. Sur le dimensionnement en revanche, je n’ai jamais rencontré la moindre limite : 384 Go de RAM, quatre SSD SAS de 800 Go et six disques 10k pour deux ou trois machines virtuelles de test, de la marge qui ne servait à rien.
Et c’est tout, ou presque. Deux services vivent en dehors du cluster : Home Assistant sur un Raspberry Pi, qui collecte déjà la consommation de la prise Meross branchée sur le serveur et la production photovoltaïque de mon installation, et AdGuard sur une machine virtuelle hébergée par la Freebox. La résolution DNS de toute la maison reposait donc sur la box de mon opérateur : un redémarrage un peu long, un changement d’offre, et plus rien ne résout.
Ce que l’audit du réseau a montré
Avant de toucher au cluster, j’ai passé la configuration UniFi au crible, sur une version antérieure à UniFi OS 5.1.33. Le résultat est moins flatteur que le matériel.
Le réseau natif est en 192.168.2.0/24 et porte l’identifiant de VLAN 1 dans le contrôleur, un écart entre le nommage et la réalité qui pique dès qu’on relit une configuration six mois plus tard. Quatre SSID ensuite, tous en 2,4 GHz et tous en WPA2, dont un masqué pour la vidéoprotection, ce qui n’a jamais protégé personne et complique surtout la vie des équipements qui doivent s’y raccrocher. Les caméras Tapo, justement, sont en Wi-Fi sur ce même réseau natif : les appareils sur lesquels j’ai le moins de garanties partagent le segment de tout le reste.
L’inventaire a sorti le reste. Quatre VLAN déclarés à côté du natif, ALARM en 192.168.90.0/29, VIDEO en 192.168.100.0/24, NTNX en 192.168.84.0/24 et IOT en 192.168.99.0/24, dont trois n’ont jamais distribué le moindre bail DHCP. Pendant ce temps, vingt-cinq équipements se partagent le LAN, les caméras comprises, alors que le VLAN VIDEO qui leur est destiné existe depuis le premier jour et reste vide.
C’est ce qui arrive quand on dessine une segmentation le jour de l’installation et qu’on ne la relit plus jamais ensuite.
Il n’y a donc pas de segmentation, juste des VLAN déclarés. Et la raison est la même que pour le cluster : le temps est passé ailleurs.
Ce que coûte un homelab Nutanix qu’on n’allume qu’au besoin
En 2024, j’avais branché une prise connectée Meross sur le cluster et je l’avais remontée dans Home Assistant pour savoir précisément ce que cette machine me coûtait. Environ 5 850 Wh par jour cluster allumé, ce qui projette 2 138,9 kWh sur une année pleine et près de 535 euros au tarif réglementé, en supposant le serveur allumé tous les jours de l’année.
Le chiffre que je n’attendais pas est l’autre : le serveur éteint consomme encore entre 300 et 400 Wh par jour, uniquement pour maintenir l’IPMI et les alimentations sous tension. Rapporté à l’année, cela fait de 110 à 146 kWh et une trentaine d’euros pour une machine qui ne fait rien. Le détail de la mesure est dans l’article que j’ai consacré au sujet.
La règle s’est donc imposée d’elle-même : le cluster ne s’allume que pour les tests et pour la rédaction des articles. Et c’est exactement ce qui bloque tout le reste, puisqu’une infrastructure qu’on démarre le soir où on en a besoin ne peut héberger aucun service qui doit répondre en permanence, ce qui exclut à peu près tout ce qu’une maison attend d’un serveur.
J’ai laissé la situation en l’état pendant deux ans car j’avais d’autres chantiers sur le feu.
Ce qui n’existait pas
Au 1er juillet 2026, je n’avais ni DNS interne, ni reverse proxy, ni supervision, ni gestion des secrets, et aucun système de sauvegarde.
Chacun de ces manques est indolore tant que les machines virtuelles sont jetables. On accède à une VM par son adresse IP parce qu’on en a trois, on ne surveille rien parce qu’un arrêt ne dérange personne, et on ne sauvegarde pas ce qu’on a prévu de détruire à la fin du test.
Avec le temps, les besoins ont évolué et je veux aujourd’hui faire tourner des applications en local qui seront utilisées par toute la famille. Les cinq manques apparaissent alors d’un seul coup, parce qu’aucun d’eux ne se voit tant que rien n’a besoin de survivre à un redémarrage.
Le seul ajout en deux ans : Mainsail
Entre mon article de 2024 et aujourd’hui, une seule chose a bougé. En décembre 2025, j’ai installé Klipper et Mainsail pour piloter mon imprimante 3D, sur un Raspberry Pi posé à côté.
Je n’ai même pas envisagé d’autre option. AHV ne sait pas faire de passthrough USB, la KB Nutanix est claire là-dessus, et de toute façon le cluster passe l’essentiel de son temps éteint. Il reste une piste que je garde pour la refonte, VirtualHere, qui expose un périphérique USB sur le réseau et le présente à une machine virtuelle sans passthrough matériel. Je ne l’ai pas encore testée.
La facture d’électricité a fini par dicter l’architecture, et pendant deux ans elle a produit la même décision à chaque nouveau besoin.
Voilà l’état des lieux. Un cluster de test presque tout le temps éteint, deux Raspberry Pi qui hébergent des applications et une box opérateur qui fait office de serveur DNS. Ça fonctionne, et ça ne peut rien porter de plus.
Le chantier commence là. Il me faut un socle allumé en permanence et sobre, un DNS et un reverse proxy qui m’appartiennent, des sauvegardes vérifiées, de la supervision, de quoi gérer les secrets… et un cluster Nutanix qui redevient ce pour quoi il est bon : casser des choses. C’est ce que je vais raconter dans les articles qui suivent.
Trois dates dans mon agenda d’octobre, deux villes, un seul éditeur : Nutanix. Les 7 et 8 octobre, le .NEXT on Tour Paris 2026 s’installe au Carrousel du Louvre, et j’y serai les deux jours, d’abord au Partner Technology Summit, puis sur le stand Inetum. Trois semaines plus tard, direction San José pour le NTC Tech Connect. Si vous êtes de la partie, voici où me trouver.
Le 7 octobre, le Partner Technology Summit
Le .NEXT on Tour parisien tient sur deux journées cette année, et la première ne s’adresse pas à tout le monde. Le 7 octobre est réservé aux partenaires, avec le Partner Technology Summit pour le volet technique et le Partner Sales Summit pour le volet commercial, chacun avec sa propre inscription. Si vous êtes client Nutanix, c’est le lendemain qui vous concerne.
J’y serai en tant que participant, avec ma casquette de Solution Architect, et j’y vais surtout pour NKP, la plateforme Kubernetes de Nutanix. C’est le genre de journée où l’on peut poser des questions précises aux gens qui construisent le produit, ce qui vaut mieux qu’une lecture de release notes un vendredi soir.
Autre changement par rapport à l’édition 2025 : on quitte le CNIT La Défense pour le Carrousel du Louvre.
Le 8 octobre, sur le stand Inetum
Le 8, les portes s’ouvrent à tout le monde, et c’est la journée où je serai le plus difficile à joindre : je tiens le stand Inetum avec Mathieu Croisy, directeur technique du CdSI Inetum, Jérôme Morlier, directeur des Alliances, et Arnaud Houllier, Product Line Expert, et nous y faisons tourner deux démonstrations toute la journée.
La première porte sur la sortie de VMware. Nutanix Move déplace les machines et il le fait bien, la difficulté d’un take out se trouve en amont : l’inventaire du parc source, l’analyse des workloads, le découpage en vagues, la validation de chaque bascule… C’est cette partie que notre outil de migration industrialise, et c’est celle que nous montrons, parce que c’est celle qui décide si un projet tient ses délais.
La seconde tourne autour de l’administration de clusters assistée par l’IA, avec un outil que nous développons chez Inetum. Je n’en dirai pas plus ici. Il faudra passer au stand pour le voir fonctionner, et c’est justement l’intérêt de se déplacer.
Passer une certification Nutanix gratuitement le 8 octobre
Voilà l’information qui justifie à elle seule de bloquer la journée, même sans rendez-vous commercial : un centre d’examen est ouvert sur place le 8, et les passages sont gratuits.
Le catalogue annoncé mélange deux générations, et ça mérite un coup d’œil avant de s’inscrire. En 7.5, vous avez la NCA, la NCP-MCI, la NCP-CN et la NCP-US. En 6.10, la NCP-MCA, la NCP-EUC, la NCP-CI pour AWS comme pour Azure, et la NCP-DB. La NCS-Core, elle, reste en 6.8. Si vous avez révisé sur une autre version que celle proposée le jour J, vous allez le sentir passer, donc vérifiez ce point avant de réserver votre créneau.
Deux prérequis à ne pas découvrir dans la file d’attente :
votre ordinateur portable et son alimentation, l’examen se passe sur votre machine
Il vous reste un mois pour réviser, ce qui est court sans être irréaliste. Si vous visez une des certifications du catalogue, les ressources de ntnx-mastery.com sont faites pour ça et elles sont gratuites.
Les 26 et 27 octobre, retour au NTC Tech Connect
Trois semaines plus tard, changement d’échelle et de fuseau horaire : deux jours au siège de Nutanix, à San José, avec les autres Nutanix Technology Champions. C’est ma deuxième participation, la première remontait à 2024, l’événement n’ayant pas eu lieu en 2025.
Le principe tient en une phrase : des sessions avec les équipes produit et les gens qui font l’application, dans leurs murs. Une partie du programme sera sous NDA, une autre sera publiable, et je ne saurai pas où passe exactement la ligne avant d’avoir l’agenda, qui n’est pas encore sorti. Ce qui pourra sortir sortira ici, le reste restera dans la salle.
J’attends aussi ces deux jours pour une raison moins technique : retrouver Jeroen, Kim, Brad, Patrick, Drew et les autres que je n’ai malheureusement pas pu voir au .NEXT à Chicago.
Trois dates, donc, et autant d’articles à venir, dans la limite de ce que je pourrai raconter : le programme du Partner Technology Summit, les questions qui reviendront au stand, ce que San José voudra bien laisser filtrer…
En attendant, si vous êtes au Carrousel du Louvre le 8, venez dire bonjour sur le stand Inetum. On y est toute la journée.
Ce week-end, j’ai voulu déplacer l’IPMI de mon node Nutanix de lab sur mon segment d’administration. J’ai changé l’adresse de la carte et le profil de VLAN du port du switch dans la même minute. Le node venait d’être réinitialisé, il n’avait plus de système, donc plus aucun moyen de corriger depuis l’intérieur, et la carte a disparu du réseau.
Ce qui m’a rendu la main tient en une adresse IPv6 link-local et deux commandes, un quart d’heure montre en main. Voici la méthode, sous Windows 11 et sous Rocky Linux.
Le soir où l’IPMI a disparu du réseau
Deux changements dans la même minute m’ont privé de tout moyen de savoir lequel des deux avait cassé quoi. J’ai branché un laptop en direct sur le port IPMI dédié de ce Supermicro SYS-5019D-4C-FN8TP pour reprendre la main.
Sur un node qui tourne, ipmitool en local règle ce genre de bêtise en une commande via l’interface KCS, sans passer par le réseau, mais un serveur fraîchement effacé ferme cette porte. Si vous êtes dans la situation inverse, la carte joignable mais le mot de passe perdu, je vous invite à consulter mon article à ce sujet : mot de passe IPMI perdu sur un noeud Nutanix ou Supermicro.
Pourquoi le link-local répond quand l’IPv4 est muette
Toute interface IPv6 active porte une adresse qui commence par fe80::, construite toute seule à partir de sa MAC et sans DHCP. Une machine dont l’IPv4 est fausse ou absente garde donc une identité joignable sur son segment. L’adresse ff02::1 est le groupe multicast dit all-nodes : un ping vers ce groupe fait répondre tout ce qui vit au bout du câble, et un IPMI alimenté en veille répond même serveur éteint. Le multicast ne traverse pas un routeur, il faut donc être sur le même segment que la carte.
Un détail achève de justifier la méthode, vu plus tard en relisant la configuration de ma carte en firmware 01.74.13 : la ligne « ARP Responses Enabled, Gratuitous ARP Disabled ». L’IPMI ne s’annonce jamais spontanément, donc écouter passivement le segment ne mène nulle part.
Retrouver la carte sur le câble
Le principe est le même sur les deux systèmes : identifier l’interface, envoyer le multicast, lire le cache voisinage.
Sous Windows 11
Repérage de la carte et de son index :
Get-NetAdapter
La colonne ifIndex donne le numéro à réutiliser ensuite, l’index 3 chez moi.
Sur un lien direct il n’y a aucun serveur DHCP, et une interface restée en automatique bascule en APIPA sur 169.254.x.x, auquel cas rien ne pinguera jamais, même face à un IPMI en parfait état. Posez une adresse statique :
Envoi du multicast, avec l’index de l’interface en suffixe de zone :
ping -6 ff02::1%3
Lecture des voisins découverts, avec leur adresse MAC :
Get-NetNeighbor -InterfaceIndex 3
Sous Rocky Linux
Identification de l’interface :
ip link show
Envoi du multicast :
ping6 -c4 ff02::1%ens0
Retour de la commande :
PING ff02::1%ens0(ff02::1%ens0) 56 data bytes
64 bytes from fe80:0:0:0:225:90ff:feb8:f313%ens0: icmp_seq=1 ttl=64 time=0.659 ms
64 bytes from fe80:0:0:0:225:90ff:feb8:f313%ens0: icmp_seq=2 ttl=64 time=0.288 ms
Association des adresses à leur MAC :
ip -6 neigh show dev ens0
Une nuance fait perdre du temps quand on passe d’un système à l’autre : le suffixe de zone prend un nom d’interface sous Linux et un index numérique sous Windows, et une adresse copiée d’une console à l’autre échoue sans message explicite.
Lire le constructeur directement dans l’adresse
Quand une adresse link-local contient ff:fe en son milieu, elle dérive de la MAC par la méthode EUI-64, et l’opération s’inverse de tête. Retirez les deux octets ff:fe du centre de fe80::225:90ff:feb8:f313, il reste 02:25:90:b8:f3:13, puis inversez le deuxième bit du premier octet : 02 devient 00, soit un OUI Super Micro Computer.
Ouvrir l’interface web en link-local
L’adresse récupérée s’utilise telle quelle dans un navigateur, entre crochets et suivie de son suffixe de zone :
https://[fe80::225:90ff:feb8:f313%3]
Le suffixe est obligatoire, une adresse link-local n’étant unique que sur un segment donné. Si votre navigateur refuse ce format, curl confirmera que le service répond, avec le % échappé en %25 et l’option -g sans laquelle les crochets partent en globbing :
Une fois l’interface ouverte, la réponse tenait en une ligne de sa page réseau : la carte portait 192.168.10.11, quand je pensais avoir configuré 192.168.10.1. Le profil de VLAN du port n’y était pour rien, et l’adresse que j’avais saisie est celle de la machine qui héberge mon DNS. Reconfiguration sur la bonne adresse, et c’était reparti.
Mes cartes de gestion vivent maintenant dans une plage réservée en bas du segment, avec une exclusion DHCP en face, le node de lab en .1 et celui de production en .2. Et je m’applique une règle simple depuis : un seul changement à la fois, vérifié avant le suivant.
Il m’est arrivé une petite mésaventure récemment. Après un changement de mot de passe IPMI sur mon 1-node, impossible de me reconnecter à l’interface de management de mon nœud. Oubli dans la seconde ? Faute de frappe ? Copier coller foireux ? Qu’importe la raison, le verrouillage de l’accès, lui, était bien réel.
Perdre son mot de passe IPMI (ou BMC) fait souvent transpirer. Mais rassurez-vous, l’expérience m’a appris une règle d’or : tant que vous avez encore un accès au système d’exploitation de l’hôte (que ce soit AHV, un Linux standard ou même ESXi), vous pouvez récupérer la main sans avoir besoin de faire un reset matériel.
Toutefois, la situation peut être plus critique qu’il n’y paraît. Pour les experts qui me lisent, vous savez qu’en environnement NutanixSingle-Node, l’IPMI n’est pas juste un confort d’administration : c’est votre seul et unique fail-safe. Sans lui, impossible de monter une ISO Phoenix en Remote Media lors d’un crash AOS majeur ou pour forcer un redémarrage. Perdre l’accès BMC sur un tel nœud devient donc très vite un point de blocage impactant pour votre production et l’accès à la console distante.
Dans ce guide, je vous partage les différentes méthodes pour reprendre le contrôle sur votre noeud en quelques minutes, de la plus douce à celle de la dernière chance.
Méthode 1 : Réinitialisation in-band via ipmitool
Si vous êtes sous Nutanix AHV ou une distribution Linux classique, vous avez de la chance : l’utilitaire ipmitool est généralement présent nativement. L’astuce de cette méthode repose sur le canal matériel KCS (Keyboard Controller Style). En clair, cela permet à l’OS de l’hôte de communiquer directement avec la puce BMC via le bus de la carte mère (LPC/PCIe), sans passer par le réseau de management.
Identifier et écraser le compte Admin
Connectez-vous en root sur votre hôte. Par précaution, on s’assure d’abord que les modules noyaux gérant l’IPMI sont bien chargés :
modprobe ipmi_si
modprobe ipmi_devintf
Ensuite, on va lister les utilisateurs configurés (généralement sur le channel 1) pour repérer l’ID de notre compte administrateur. Dans 99% des cas, le compte par défaut (ADMIN) correspond à l’ID 2.
ipmitool user list 1
Dans mon cas, l’ID correspond bien à 2 :
Une fois l’ID confirmé, la commande pour forcer un nouveau mot de passe est enfantine :
ipmitool user set password 2 'MonNouveauMdp123!'
Lors de la saisie de la commande précédente, il se peut que le terminal vous renvoie un vilain Invalid data field in request.
Pas de panique, c’est simplement le parseur de politique de sécurité de certains firmwares qui rejette votre demande. Il exige non seulement une complexité minimale (8 caractères, majuscule, minuscule, chiffre), mais peut aussi être capricieux sur le format de la requête.
Pour contourner (ou plutôt satisfaire) ce mécanisme, forcez la longueur d’encodage sur 20 octets en ajoutant simplement 20 à la fin de votre commande :
ipmitool user set password 2 'MonNouveauMdp123!' 20
Votre mot de passe est maintenant écrasé. Vous pouvez tester la connexion à l’interface web.
Méthode 2 : L’utilitaire IPMICFG (La solution pour VMware ESXi)
Si vous êtes sous VMware ESXi, la première méthode risque de vous laisser sur le carreau. Pourquoi ? Parce qu’ipmitool n’y est pas packagé nativement et résoudre les dépendances pour le compiler sur un hyperviseur est une perte de temps que je ne vous recommande pas.
La parade s’appelle IPMICFG. C’est l’outil officiel fourni par Supermicro (téléchargeable sur leur portail avec un compte gratuit). L’immense avantage est qu’il est fourni sous forme de binaires statiques, prêts à l’emploi pour Linux ou Windows.
Une fois l’archive transférée sur votre hôte et décompressée, son utilisation est très simple :
./IPMICFG-Linux.x86_64 -user list
./IPMICFG-Linux.x86_64 -user setpwd 2 MonNouveauMdp123!
Note : adaptez le nom du binaire si vous utilisez la version Windows ou Linux.
Que faire si l’OS ne démarre plus du tout ? C’est souvent là qu’on transpire, pensant que sans accès réseau à l’IPMI ni système d’exploitation fonctionnel, la seule méthode restante est le reset usine.
Rappelez-vous : l’interface KCS est exposée au niveau matériel dès la fin du POST BIOS. Elle est totalement indépendante de l’état de votre stockage.
Il suffit donc de booter le serveur sur une clé USB contenant un Live CD Linux (Ubuntu, Rocky Linux). Une fois sur le bureau éphémère, ouvrez un terminal, installez l’utilitaire s’il n’est pas déjà présent (apt install ipmitool par exemple), et reprenez exactement les commandes de la Méthode 1.
Méthode de dernier recours : Le Factory Reset du BMC
Si pour une raison obscure les méthodes précédentes échouent, il reste l’ultime recours : le reset aux paramètres d’usine.
Avec l’outil de Supermicro, la commande est directe :
./IPMICFG-Linux.x86_64 -fd
Et si vous préférez la méthode ipmitool pure, il faut passer une commande RAW :
ipmitool raw 0x3c 0x40
⚠️ Attention, les conséquences sont lourdes : Toute votre configuration BMC est remise à zéro. Vous perdez l’IP statique (le port repasse en DHCP), la configuration des VLANs, et vos comptes utilisateurs. Le BMC va ensuite redémarrer (comptez bien 2 à 3 minutes). Gros point de vigilance sur les générations récentes de serveurs : il se peut que le mot de passe ne redevienne pasADMIN/ADMIN. Il bascule sur le mot de passe unique imprimé sur l’étiquette OCP (souvent collée sur le châssis ou la carte mère). Pensez-y si votre serveur est physiquement à l’autre bout du monde !
Mes recommandations
Une fois l’accès récupéré via la méthode 1 ou 2, voici ce que je fais systématiquement pour sécuriser mes arrières :
Le gestionnaire de mots de passe : C’est basique, mais renseignez vos creds immédiatement au lieu de le garder dans le cache du copié-collé.
Le compte de secours : Créez un second compte administrateur.
L’astuce du Slot ID : Ne mettez pas votre compte de secours sur le Slot ID 3. Forcez sa création sur un Slot plus éloigné (comme le 5 ou le 6). Pourquoi ? Parce que certains scripts d’automatisation d’infrastructure ont parfois la fâcheuse tendance à écraser ou modifier en force les premiers Slots (2 et 3) lors du provisionning. En le mettant plus loin, vous le sanctuarisez.
Et vous, ça vous est déjà arrivé de vous enfermer dehors sur l’un de vos nœuds ? Partagez votre pire galère dans les commentaires ci-dessous !
Beaucoup le savent, j’ai un niveau de développement brut qui oscille entre le zéro absolu et le « c’est tombé en marche ».
Mais voilà, la donne a changé. L’intelligence artificielle, et plus précisément les agents de codage en CLI (Command Line Interface) comme Claude Code, m’ont donné des super-pouvoirs. Soudainement, coder n’est plus une montagne insurmontable, mais une discussion. Seulement, il y a un hic : pour discuter avec la machine, il faut que l’environnement soit d’équerre. Et le développement sous Windows, historiquement, c’était un peu comme essayer de faire rentrer des carrés dans des ronds (carré dans l’tube pour ceux qui ont la réf).
Heureusement, WSL (Windows Subsystem for Linux) est là. L’idée de ce guide ? Vous éviter les sueurs froides que j’ai eues. Je vous propose de configurer un environnement Ubuntu propre sous Windows, de le blinder avec les dépendances nécessaires (Cargo, npm), d’installer Claude Code, et de relier tout ça de façon fluide à Visual Studio Code.
Pourquoi s’embêter avec WSL2 me direz-vous ? Tout simplement parce que cela permet d’isoler totalement nos outils d’IA. Claude Code tournera dans son bac à sable Linux, avec des performances I/O natives, et tout ceci indépendamment de notre système Windows. On garde le contrôle.
Prêt à transformer votre machine Windows en station de développement boostée à l’IA ? Suivez le guide, j’ai déminé le terrain pour vous.
1. Activer et installer WSL (Windows Subsystem for Linux)
On ne va pas se mentir : à une époque, installer un environnement Linux sous Windows, c’était le parcours du combattant. Il fallait fouiller dans des menus obscurs, cocher des « Fonctionnalités Windows », et prier très fort. Aujourd’hui, Microsoft a rattrapé son retard, et ça tient en une ligne de commande.
Installation de WSL
Commencez par ouvrir PowerShell en tant qu’administrateur (clic droit sur le menu Démarrer > Windows PowerShell (admin) ou Terminal (Administrateur)).
Tapez simplement cette commande et appuyez sur Entrée :
wsl --install
Laissez la magie opérer. Une fois que c’est terminé, la règle d’or de l’informatique s’applique : redémarrez votre PC. Ce n’est pas optionnel, Windows a besoin de ce redémarrage pour activer les composants de virtualisation au niveau du système.
WSL : Choisir sa distribution
Au redémarrage, WSL est là, mais on va s’assurer d’installer la bonne distribution. Rouvrez PowerShell (pas besoin des droits admin cette fois).
Pour voir ce qui est disponible au « catalogue », tapez :
wsl --list --online
Dans notre cas, on va partir sur le standard absolu, Ubuntu. C’est là que la communauté est la plus grande, et où l’on trouve le plus de solutions quand on a un message d’erreur.
Lancez l’installation avec :
wsl --install Ubuntu
Une fenêtre de terminal va s’ouvrir, vous demandant de créer un nom d’utilisateur UNIX et un mot de passe.
Pourquoi WSL2 change tout ? Pour les plus curieux, sachez que cette commande active par défaut WSL2. Ce détail est crucial. Fini la première version (WSL1) où Windows essayait de traduire maladroitement les commandes Linux à la volée. Aujourd’hui, WSL2 utilise une véritable machine virtuelle ultra-légère (basée sur Hyper-V) avec un vrai noyau Linux optimisé par Microsoft. Le résultat ? Une compatibilité à 100% avec les outils de développement et des performances d’accès aux fichiers (I/O) fulgurantes, ce qui sera vital pour que Claude Code lise notre code rapidement.
2. Préparer l’environnement Ubuntu
Ça y est, la distribution Linux est installée mais un système Linux tout neuf, c’est comme un appartement vide : c’est très propre, mais on ne peut pas y faire grand-chose.
Avant de faire entrer notre super-agent IA, il faut installer les meubles, ou plutôt les dépendances. Beaucoup d’outils modernes en CLI s’appuient sur des écosystèmes bien précis.
Installer Cargo (et notre premier outil IA)
Pour mes propres expérimentations, j’utilise souvent l’écosystème Rust. On va donc installer son gestionnaire de paquets, cargo.
Tapez ceci dans votre terminal Ubuntu :
sudo apt install cargo
Pourquoi Cargo ? Parce qu’il va nous permettre d’installer des outils directement depuis leur code source. Par exemple, j’utilise rtk, un framework IA hyper pratique. Pour l’installer, c’est aussi simple que ça :
cargo install --git https://github.com/rtk-ai/rtk
Laissez compiler. C’est beau à voir (même si, je l’avoue, je regarde souvent défiler ces dizaines de lignes de compilation comme une poule devant un Rubik’s Cube, en priant juste pour qu’il n’y ait pas de texte rouge clignotant à la fin).
A quoi sert RTK me direz-vous ? Et bien à économiser des tokens Claude Code grâce à des automatisations et donc à pouvoir discuter plus longtemps avec l’IA d’Anthropic afin de préserver nos quotas.
Installer Node.js et npm
Ensuite, Claude Code et beaucoup d’autres agents utilisent des technologies web. Il nous faut donc npm (Node Package Manager).
On lance la commande :
sudo apt install npm
Si un développeur barbu et/ou chauve lit ce tutoriel, il va s’étrangler : « Ju, on n’installe jamais npm via apt, ça met une vieille version et ça crée des erreurs de permissions ! ». Et il aurait surement raison. La « vraie » bonne pratique consiste à utiliser NVM (Node Version Manager). Cependant, soyons pragmatiques : pour notre objectif précis de faire tourner Claude Code CLI aujourd’hui, la version stable fournie par les dépôts d’Ubuntu fait très bien le job. Si, plus tard, vous commencez à accumuler les erreurs de type EACCES en installant d’autres paquets globaux, vous saurez qu’il sera temps de nettoyer tout ça et de passer à NVM !
3. Installer et configurer Claude Code
Le script d’installation officiel
Pour installer Claude Code, Anthropic a fait les choses simplement. Enfin, « simplement » version Linux. On va utiliser un outil appelé curl qui va télécharger un script sur leurs serveurs et l’exécuter directement sur notre machine.
Tapez ceci dans votre terminal Ubuntu :
curl -fsSL https://claude.ai/install.sh | bash
En temps normal, balancer un script inconnu trouvé sur le net directement dans le bash de sa machine, c’est l’équivalent numérique de ramasser une clé USB sur le trottoir et de la brancher direct sur son PC. Mais bon, ici c’est Anthropic, on part du principe qu’ils ne veulent pas miner du bitcoin sur notre dos.
Le script va mouliner un peu. Et là, plein d’espoir, les yeux brillants, vous tapez claude dans votre terminal. Et paf… claude: command not found.
Frustration. Sueurs froides. Pas de panique, c’est un grand classique.
Le fameux piège du PATH
Pourquoi ça ne marche pas du premier coup ?
Parce qu’Anthropic fait les choses proprement en respectant le principe du moindre privilège. Au lieu d’installer Claude Code brutalement à la racine de votre système (ce qui requerrait des droits super-administrateur root et pourrait tout casser), le script place l’exécutable dans un petit dossier caché bien à vous : ~/.local/bin.
Le problème, c’est que votre système Ubuntu ne regarde pas de base dans ce dossier précis quand vous lui lancez une commande. Il faut lui indiquer explicitement le chemin. C’est ce qu’on appelle la variable d’environnement $PATH.
Pour réparer ça une bonne fois pour toutes, on va ajouter ce fameux dossier à notre PATH. Copiez-collez cette ligne (attention, copiez-la exactement avec ses guillemets) :
Cette double commande fait deux choses : elle inscrit le bon chemin à la fin de votre fichier de configuration personnel (.bashrc), et elle demande au terminal de relire ce fichier immédiatement pour prendre en compte la modification (source).
Maintenant, retapez claude ou claude --version. Si un menu ou un numéro de version s’affiche : c’est gagné !
4. L’intégration finale avec VS Code
C’est bien beau d’avoir la CLI de Claude qui tourne sagement dans un terminal sur WSL, mais l’idée, c’est quand même de lui faire lire et écrire du code de manière confortable. Et pour ça, il nous faut notre fidèle Visual Studio Code.
L’extension WSL pour VS Code
Ouvrez VS Code de manière classique, sous Windows. Allez dans l’onglet des extensions et cherchez WSL (anciennement Remote – WSL, éditée directement par Microsoft). Installez-la.
Une fois installée, regardez tout en bas à gauche de la fenêtre de VS Code. Vous y verrez une petite icône bleue (ou verte) avec des chevrons ><. Cliquez dessus, et choisissez l’option « Se connecter à WSL » (ou Connect to WSL).
Une nouvelle fenêtre VS Code s’ouvre. En bas à gauche, il y a maintenant écrit « WSL: Ubuntu ». Bingo.
C’est là que la puissance de l’architecture dont je vous parlais plus haut frappe fort. Quand vous ouvrez un projet de cette manière, VS Code installe un mini-serveur directement à l’intérieur de votre machine Linux. L’interface graphique (l’éditeur) tourne sous Windows, mais toute la logique de développement, le terminal intégré et l’accès aux fichiers s’exécutent de manière native sous Ubuntu.
Le plugin Claude pour VS Code
Avoir la CLI pour lancer des commandes globales c’est super, mais on ne va pas se mentir : avoir Claude directement intégré dans l’interface de l’éditeur, c’est le confort ultime.
Toujours dans cette nouvelle fenêtre VS Code (connectée à WSL), retournez dans l’onglet des extensions et cherchez l’extension officielle Claude (ou Claude Dev/Cline selon vos préférences).
⚠️ Attention : VS Code gère désormais deux « zones » d’extensions distinctes. Celles installées sur votre Windows local, et celles installées dans votre machine WSL. Assurez-vous de cliquer sur le petit bouton bleu « Installer dans WSL: Ubuntu » (Install in WSL: Ubuntu) si VS Code vous le propose.
Si vous l’installez par erreur du côté Windows, le plugin va tourner dans le vide et sera incapable de lire les fichiers de votre projet Linux ou de comprendre les commandes que vous lui envoyez.
Une fois le plugin activé côté Ubuntu, une nouvelle icône va apparaître dans votre barre latérale. Vous voilà avec la CLI puissante dans le terminal en bas, et l’assistant visuel réactif sur le côté. Une vraie tour de contrôle !
Conclusion
Et voilà, la boucle est bouclée. En quelques lignes de commande, nous sommes passés d’un environnement Windows cloisonné à un setup hybride ultra-performant. Vous avez maintenant un sous-système Ubuntu propre, prêt à compiler du Rust, faire tourner du Node, et surtout, héberger votre nouvel assistant IA.
De mon côté, avec mon niveau de « dev du dimanche », ce setup a changé ma vie. Je discute, j’oriente, je supervise et Claude gère le code. Et vous, quel va être votre premier projet avec cette nouvelle stack ?
Il y a des e-mails qui font plus plaisir que d’autres. Quand j’ai vu apparaître ce fameux « You’re in » dans ma boîte de réception, je me suis pris une petite décharge d’adrénaline. J’ai l’immense plaisir de partager avec vous mon invitation pour le très privé Nutanix Tech Connect 2026, qui se tiendra les 26 et 27 octobre prochains directement au siège, au HQ de Nutanix à San José dans la Silicon Valley !
Vous le savez, au quotidien, je passe une bonne partie de mes journées le nez dans l’écosystème Nutanix chez Inetum. C’est mon terrain de jeu. Mais ce voyage, c’est l’occasion de passer littéralement de l’autre côté du miroir. Et pour la 2e fois ! (voir mon article retraçant mes 2 jours au NTC Tech Connect 2024).
Si les grandes messes technologiques comme l’événement .NEXT sont parfaits pour découvrir les annonces publiques entouré de milliers de participants, le Tech Connect est son exact opposé. C’est l’envers du décor. Seule une poignée d’élus, triés sur le volet parmi les membres les plus actifs de la communauté NTC (Nutanix Technology Champions), sont invités. Et nous ne faisons pas le déplacement pour écouter le discours marketing habituel, mais pour plonger dans le vif du sujet, échanger sous NDA (Non-Disclosure Agreement) et décortiquer l’architecture avec ceux qui conçoivent la plateforme.
Qu’est-ce que le Nutanix Tech Connect ?
Un rassemblement d’experts passionnés
Faire partie du programme NTC, c’est déjà évoluer au quotidien au sein d’une communauté incroyable de partage et d’entraide. Mais cet événement en présentiel pousse le concept encore plus loin. Il a été pensé comme un rassemblement intimiste. L’objectif de Nutanix n’est pas ici de remplir un centre de conventions, mais de réunir autour d’une table une poignée de passionnés dont la voix et l’expérience terrain comptent.
L’impact direct sur la roadmap Nutanix
C’est là que l’on touche au but ultime pour tout ingénieur système ! Pendant ces deux jours d’immersion à San Jose, on laisse les présentations commerciales au vestiaire. Nos interlocuteurs directs ? Le Product Management (PM) et les équipes de Recherche & Développement (R&D).
C’est une occasion en or de discuter de manière transparente des évolutions du socle AOS (Acropolis Operating System) et des futures capacités de notre hyperviseur AHV. C’est précisément lors de ces tables rondes « sans filtre » que l’on décortique les cas d’usage complexes que nous rencontrons sur nos clusters de production. Savoir que nos « pain points » et nos retours terrains peuvent directement influencer la roadmap technique et façonner le code des prochaines releases est tout simplement grisant !
Au programme : Deux jours d’immersion San Jose
Le programme de ces deux jours s’annonce dense. L’email d’invitation est clair : l’objectif est d’interagir directement avec l’ingénierie, les équipes produit, et même les dirigeants de Nutanix. Concrètement, cela se traduit par des sessions techniques interactives où nous allons pouvoir « challenger » les choix d’architecture. C’est le moment idéal pour poser ces questions pointues qui restent souvent sans réponse sur les forums classiques, et surtout, pour avoir un aperçu exclusif (et strictement sous NDA !) de ce qui arrive dans les prochains mois.
L’autre immense atout du Tech Connect, c’est le networking. Se retrouver physiquement avec des NTC venus des quatre coins du monde, c’est l’assurance d’échanges d’une grande richesse dû à la provenance hétéroclite de l’ensemble des participants. On compare nos infrastructures, on partage nos retours d’expérience, et on trouve souvent des solutions à des problèmes complexes autour d’un simple café. C’est cette synergie entre experts passionnés qui fait la véritable force de la communauté Nutanix.
D’ici la fin octobre, la préparation va s’accélérer. Dans les prochaines semaines, nous aurons droit à un webinaire exclusif de « Kickoff » pour découvrir l’agenda détaillé, les sessions prévues et, on l’espère, quelques surprises. Ensuite, viendra le temps de sécuriser les vols et l’hébergement.
De mon côté, la préparation technique a déjà commencé ! Je compile mes notes, mes observations sur les dernières versions d’AOS, et surtout, les retours des collègues. Car oui, je compte bien être le porte-voix de notre communauté francophone lors de cet événement !
Merci et rendez-vous en Californie !
En attendant le mois d’octobre, je vais commencer à préparer tranquillement ma compilation de notes et observations et travailler sur quelques stickers à échanger avec les chers NTCs. Comptez sur moi pour vous faire un retour détaillé à mon retour (du moins, sur tout ce qui ne sera pas protégé par le NDA !).
Pour conclure, je tenais à adresser un immense et sincère merci à Angelo, ainsi qu’à toutes les équipes Nutanix, pour cette opportunité exceptionnelle et pour l’organisation de cet événement. La reconnaissance de cette communauté est un moteur puissant au quotidien.
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.
# 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.
On a tous connu ce moment de solitude dans notre parcours professionnel. Celui où tu as planifié l’upgrade matériel pour ton infrastructure, mais où un détail insignifiant vient perturber le déroulé des opérations. Récemment, nous devions remplacer les disques mécaniques 3.5 pouces d’un de nos clusters de 4 nœuds par des disques SSD 2.5 pouces. Une opération de maintenance classique pour passer d’un stockage hybride a une stockage full-flash et gagner en IOPS.
Seul problème, et de taille : les caddys d’origine des serveurs n’étaient pas compatibles avec ce format réduit.
Première approche : les adaptateurs “officiels”
La solution évidente quand on gère une infra pro ? Commander des adaptateurs officiels ou des caddys de remplacement. Il nous fallait 24 pièces au total (6 disques pour chacun des 4 nœuds). Et là, c’est la douche froide.
Plus de 500 euros (avec les taxes et la livraison).
Mais le pire n’était finalement pas le prix : c’était le délai d’approvisionnement. Attendre plusieurs semaines alors que le projet devait avancer ? Inenvisageable. Puisque je refuse de payer ce tarif et que les délais sont beaucoup trop longs, mon imprimante 3D va s’en charger.
La plan B : la solution DIY
L’avantage d’avoir du matériel standard comme du Supermicro, c’est que l’on n’est jamais le premier à rencontrer un problème. Pas besoin de passer des heures sur Fusion 360 à modéliser la pièce au millimètre près : la communauté open-source l’a probablement déjà fait.
En quelques clics sur les plateformes de partage de modèles 3D (comme Printables ou Thingiverse), j’ai déniché le fichier .stl parfait : https://www.thingiverse.com/thing:4353094
Pour m’assurer de la compatibilité, j’en ai imprimé un rapidement pour valider les dimensions et que cela faisait le job…
L’étape suivante : l’industrialisation. J’ai positionné mes modèles de sorte de pouvoir imprimer 6 adaptateurs d’un seul coup. Cela impliquait de laisser tourner l’imprimante pendant 7h30 environ pour chaque plateau.
Sur ma Creality CR-10S Pro v2 tournant sous Klipper, j’ai pu monitorer le job d’impression pour m’assurer que tout se passait comme prévu du coin de l’oeil tout en continuant à travailler sur mes projets.
Malgré un couac lors du premier batch qui m’a contraint à faire un peu de mécanique, les impressions se sont parfaitement bien déroulées.
Maker Spirit for the Win !
Le verdict final est sans appel :
Option Fournisseur : ~543 € et 3 semaines d’attente.
Option Maker : 20 € de filament, quelques kWh et deux grosses journées d’impression.
Au-delà de l’économie financière évidente (pour le prix des adaptateurs officiels, on aurait pu acheter l’imprimante + le filament), la vraie leçon de cette aventure, c’est que l’état d’esprit maker permet de transformer une problématique budgétaire et temporelle en une solution DIY 20 fois moins chère et qui fait le job dans des délais ultra-courts.
Alors, la prochaine fois qu’un problème pointe le bout de son nez, pensez “out-of-the-box” et éventuellement, dégainez votre plus belle bobine de filament.
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) :
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 :
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 :
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) :
💡 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 :
💡 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 !
We use cookies to improve your experience on our site. By using our site, you consent to cookies.
This website uses cookies
Websites store cookies to enhance functionality and personalise your experience. You can manage your preferences, but blocking some cookies may impact site performance and services.
Essential cookies enable basic functions and are necessary for the proper function of the website.
Name
Description
Duration
Cookie Preferences
This cookie is used to store the user's cookie consent preferences.
30 days
These cookies are needed for adding comments on this website.
Name
Description
Duration
comment_author
Used to track the user across multiple sessions.
Session
comment_author_email
Used to track the user across multiple sessions.
Session
comment_author_url
Used to track the user across multiple sessions.
Session
Statistics cookies collect information anonymously. This information helps us understand how visitors use our website.
Matomo is an open-source web analytics platform that provides detailed insights into website traffic and user behavior.
