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 !
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.
L’intégration de puissance de calcul graphique au sein d’environnements virtualisés est devenue un incontournable. Que ce soit pour faire tourner des modèles d’Intelligence Artificielle, du Machine Learning ou simplement pour du traitement vidéo intensif, nos machines virtuelles ont de plus en plus besoin de muscles.
Lorsque je discute avec des clients, je reçois souvent des questions à ce sujet : comment assigner une carte graphique physique à une VM de manière simple et performante ?
Aujourd’hui, je vous propose de voir ensemble comment déployer un GPU NVIDIA Tesla P4 sur une VM Ubuntu Server 24.04 hébergée sous Nutanix AHV, en utilisant le mode « Passthrough ».
1. Les prérequis
Avant de mettre les mains dans le cambouis, prenons un instant pour vérifier notre équipement. Une bonne préparation, c’est la moitié du travail de fait ! J’ai moi-même perdu des heures par le passé à cause d’un simple prérequis oublié.
Pour suivre ce tutoriel, vous aurez besoin de :
Un nœud Nutanix (cluster physique) équipé d’au moins une carte NVIDIA Tesla P4.
Une machine virtuelle sous Ubuntu Server 24.04.
Un accès SSH fonctionnel vers cette VM avec des privilèges sudo.
Bien que Nutanix AHV gère cela de manière transparente pour vous, gardez en tête que le mode Passthrough repose sur des instructions matérielles spécifiques. Il nécessite que les extensions de virtualisation des I/O (VT-d chez Intel ou AMD-Vi chez AMD) soient bien activées au niveau du BIOS de votre nœud physique. Si un jour vous montez un cluster « home-lab », c’est la première chose à vérifier !
2. Configuration côté Nutanix : Le mode Passthrough
Maintenant que notre base est solide, passons à l’interface d’administration. C’est ici que la magie opère. Que vous utilisiez Prism Element ou Prism Central, la logique reste la même. Assurez-vous d’abord que votre machine virtuelle est bien éteinte.
Allez dans les paramètres de votre VM, sélectionnez « Update », puis descendez jusqu’à la section « GPUs ». Cliquez sur « Add GPU ».
Dans la fenêtre qui s’ouvre, le choix est crucial : dans le menu déroulant « GPU Type », sélectionnez le mode Passthrough, puis choisissez votre Tesla P4 dans la liste.
Le mode Passthrough est une fonctionnalité particulière : il permet de « donner les clés » matérielles de la carte graphique directement à la machine virtuelle. L’OS invité a l’illusion (et les avantages) de posséder la carte physiquement.
Vous vous demandez peut-être pourquoi nous privilégions le Passthrough plutôt que le vGPU ? C’est une question de cas d’usage, mais aussi d’architecture.
Le vGPU permet de découper virtuellement une carte pour la partager entre plusieurs VMs, ce qui est génial pour du VDI, mais il nécessite l’installation et la maintenance d’un serveur de licences NVIDIA (vGPU Software).
Le Passthrough, en revanche, dédie 100% de la puissance de la Tesla P4 à notre VM Ubuntu, sans aucun serveur de licence additionnel. Pour un besoin de performance brute mono-VM, c’est clairement la meilleure option.
3. Préparation et mise à jour d’Ubuntu 24.04
Une fois le GPU attaché, sauvegardez la configuration, allumez votre VM et connectez-vous en SSH.
Avant de nous précipiter sur l’installation des drivers NVIDIA, il y a une étape que je ne saute absolument jamais : la mise à jour du système.
Tapez simplement cette commande :
sudo apt update && sudo apt upgrade -y
Les pilotes propriétaires NVIDIA s’appuient sur le système DKMS (Dynamic Kernel Module Support) pour compiler les modules du noyau à la volée lors de l’installation.
Si vos en-têtes de noyau (kernel headers) ne sont pas parfaitement synchronisés avec votre version actuelle du noyau linux, l’installation échouera silencieusement. Un système fraîchement mis à jour est votre meilleure garantie pour une compilation propre et sans accroc !
4. Installation des drivers NVIDIA (Branche Server)
Maintenant que notre système est propre et à jour, passons au plat de résistance. Sous Ubuntu, on a souvent le réflexe d’utiliser la commande ubuntu-drivers autoinstall ou d’installer la dernière version « desktop » à la mode. Je vous arrête tout de suite !
Pour un serveur, surtout en production, la stabilité est le maître mot. C’est pourquoi nous allons installer la branche « Server » du pilote. Tapez la commande suivante :
sudo apt install nvidia-driver-535-server -y
💡 L’astuce de l’Expert : Pourquoi précisément le paquet « server » ? NVIDIA maintient des branches de pilotes spécifiques pour les data centers. La branche « Server » (ou Tesla driver) est conçue pour des cycles de vie longs (LTS) et minimise le risque de régression. Installer un pilote « Desktop » sur un hyperviseur ou un serveur IA, c’est s’exposer à ce qu’une mise à jour mineure casse votre environnement de production un vendredi à 17h !
Laissez l’installation se terminer (cela peut prendre quelques minutes le temps que DKMS compile le module pour votre noyau). Une fois terminé, un redémarrage est obligatoire pour charger correctement le pilote :
sudo reboot
5. Vérification
Après le redémarrage, reconnectez-vous en SSH à votre machine virtuelle. Pour vérifier que l’OS, le pilote et le matériel communiquent parfaitement, NVIDIA nous fournit un outil en ligne de commande :
nvidia-smi
Si tout s’est bien passé, vous devriez voir apparaître un magnifique tableau de bord en ASCII.
💡 Décryptage : En haut à droite, notez la CUDA Version (ici 12.2) : c’est la version maximale de l’API CUDA supportée par ce pilote, une info cruciale pour les développeurs IA. Regardez aussi la colonne Perf : elle indique « P0 », ce qui correspond à l’état de performance maximum (les « P-states » vont de P0 à P12 pour l’économie d’énergie). Si votre carte reste bloquée sur un P-state bas alors qu’elle est en charge, c’est qu’il y a un souci matériel ou thermique ! Enfin, cet output confirme que l’OS est prêt à accueillir le NVIDIA Container Toolkit (pour du Docker avec GPU).
Conclusion
Et voilà ! En quelques étapes simples, nous avons réussi à présenter physiquement notre GPU NVIDIA Tesla P4 à notre VM Ubuntu 24.04 sous Nutanix AHV. Le mode Passthrough nous a permis d’obtenir une configuration performante, sans latence et sans l’usine à gaz d’un serveur de licences externe.
Notre Tesla P4 est désormais correctement installée ! La prochaine étape logique ? Le déploiement de modèles LLM (Large Language Models) ou d’applications gourmandes en calcul dans des conteneurs isolés. Mais ça, ce sera pour un prochain article sur le blog !
Le codage assisté par IA, pour moi qui suis une buse en développement, c’est une révolution qui me permet de concrétiser des idées en quelques heures là où cela relevait de l’impossible auparavant. Mais cette vitesse a un prix que l’on néglige trop souvent : la dette technique.
Le contexte de développement
Récemment, j’en parlais ici, j’ai développé une petite application web nommée HYCU Upgrade Path. Le concept est simple : une interface épurée pour générer et visualiser l’upgrade path d’une version A à une version B du logiciel de backup.
Pour ce faire, j’ai utilisé Lovable, une solution « no-code/low-code » qui m’a permis en quelques jours de mettre l’application en ligne.
Quelques semaines plus tard, j’ai décidé de redévelopper l’application à l’aide de Gemini, l’IA multimodale de Google, pour voir ce qu’elle avait dans le ventre.
J’ai donné des instructions similaires à chacune des 2 IA. J’attendais un résultat fonctionnel et similaire des deux côtés. Ce que je n’avais pas prévu, c’est l’écart abyssal dans la structure du code… Et le temps passé.
On parle d’une différence de 628ko contre 115ko. On parle de passer de 79 fichiers à 21 fichiers. On parle d’une semaine contre une demi journée. Un gouffre.
L’expérience Lovable
Sur le papier Lovable vend du rêve : vous décrivez, ça s’affiche. Et c’est vrai, l’expérience utilisateur est bluffante de fluidité. J’ai décrit mon besoin pour HYCU Upgrade Path, et en quelques itérations, l’application tournait sous mes yeux. Visuellement, c’était propre avec quelques ajustements à faire. Fonctionnellement, c’était un peu plus bancal.
Je ne suis pas développeur, mais mon premier réflexe a été d’aller voir le repository généré. Et là… ça a été la douche froide.
Pour une application aussi simple qu’un générateur d’upgrade path, Lovable m’a pondu une véritable usine à gaz :
79 fichiers créés.
8 dossiers imbriqués.
Un poids total de 628ko.
Lovable a fragmenté l’application en une myriade de petits composants atomiques, a généré des fichiers de configuration en doublon et a importé des librairies « au cas où ». En regardant le dossier components/ui, j’ai trouvé 38 fichiers ! Des accordéons, des badges, des carrousels, des « toasters »… alors que mon app n’utilise qu’une fraction de tout ça.
C’est l’approche « Black Box » : tant que ça marche en façade, on ne se soucie pas de l’élégance du moteur. Le résultat est une application lourde et difficilement maintenable dans le temps. Et ça pour moi, c’est un premier red flag.
Coté modification du code par itération, je ne l’ai pas trouvé très précise. J’ai été contraint d’avancer par toutes petites itérations ce qui a rallongé le temps de développement… Une itération un peu trop musclée ? Ca cassait une fois sur deux mon interface ou donnait un résultat qui n’était pas celui attendu. Bref, pas hyper satisfait de l’expérience bien que j’ai réussi à atteindre mon but en une petite semaine de discussions.
L’expérience Gemini : L’architecte logiciel
Après cette semaine de lutte et quelques semaines en production, j’ai tenté la même expérience avec Gemini. Même prompt, même besoin, juste “pour voir” de quoi l’IA de Google était capable.
Le résultat ? Au départ, j’ai cru qu’il manquait des morceaux.
21 fichiers au total.
5 dossiers.
115ko sur la balance.
Temps de développement : une demi-journée.
Gemini a adopté une approche radicalement différente, bien plus mature. Au lieu d’importer une librairie graphique massive, il a structuré le code et n’a gardé que ce qui était réellement nécessaire.
En ouvrant le dossier src/components, la différence est flagrante : 7 fichiers, tous essentiels. Pas de bruit, pas de composants inutiles.
Plus impressionnant encore, Gemini m’a fourni une architecture « Prête à mettre en prod ». Là où Lovable m’a donné un frontend en vrac, Gemini a séparé proprement le frontend du backend, et m’a même généré un docker-compose.yml et un script de déploiement (deploy.sh) pour mon VPS. Il n’a pas juste codé l’interface, il a pensé à comment je la ferais tourner, avec un joli README.md en prime.
Pour le plaisir, j’ai ajouté quelques détails supplémentaires sur mon application au passage.
Le Match Technique : L’obésité vs L’efficacité
Comparons ce qui est comparable. Voici le bilan des courses pour la même fonctionnalité :
Métrique
Lovable
Gemini
Gain
Poids du projet
628 ko
115 ko
-82%
Nombre de fichiers
79
21
-73%
Philosophie
UI Kit complet (« au cas où »)
Code propre, lisible
Maintenance facilitée
Architecture
Frontend monolithique
Dockerisé (Front + Back)
Prêt à déployer
Temps de dev
1 semaine
1/2 journée
Productivité x10
Pourquoi la « propreté » compte (même pour les non-devs comme moi) ?
Vous pourriez me dire : « On s’en fiche du code ou du nombre de fichiers tant que l’app fonctionne ! ». C’est une erreur.
La maintenance : Modifier à la main le projet créé sous Lovable, c’est chercher une aiguille dans une botte de 79 fichiers. Avec Gemini, chaque fichier a un nom qui décrit réellement ce qu’il fait.
La consommation : 628ko de code à charger pour un utilisateur mobile, c’est lourd. 115ko, c’est presque instantané.
Le coût cognitif : Quand l’IA génère du code « brouillon », elle a elle-même plus de mal à se relire pour les itérations suivantes. C’est pour ça que Lovable « cassait » l’interface : elle se perdait dans sa propre complexité.
Conclusion : Le choix de l’outils fait la différence
Mon verdict est sans appel. Si vous voulez prototyper une idée en 10 minutes pour montrer que « ça bouge » à votre boss, Lovable fait illusion. C’est spectaculaire, c’est visuel, c’est une belle démo technologique.
Mais si vous voulez construire une application pérenne, que vous pourrez faire évoluer sans tout casser, une IA comme Gemini est bien plus performante à mes yeux.
L’écosystème évolue vite. Je ne l’ai pas testé pour le moment, mais un outils comme Claude Code doit même surement être capable de faire encore mieux.
Octobre 2023. Le contexte est tendu : le prix du kWh s’envole et mon fil d’actualité est inondé de publicités pour des panneaux solaires promettant « l’autonomie totale » ou « la gratuité ».
Étant d’un naturel méfiant (et un peu geek sur les bords), j’ai sorti mes fichiers Excel avant de sortir le carnet de chèques. J’ai investi 13 900 € pour 6kWc de puissance. Deux ans plus tard, avec 17,4 MWh produits, est-ce que ça valait le coup ?
Spoiler : les chiffres de la « vraie vie » ont battu mes simulations, mais le diable se cache dans les détails.
1. La Genèse : Pourquoi j’ai transformé mon toit en centrale ?
On ne se lève pas un matin en décidant de lâcher près de 14 000 euros (avant primes) juste pour faire plaisir à la planète. C’est un calcul. Mon objectif était double : sécuriser une partie de mon coût de l’énergie pour les 20 prochaines années et, avouons-le, le plaisir technique de piloter ma propre production.
Le contexte : Acheter son électricité en avance
Pour le néophyte, voir ça comme une dépense est une erreur. C’est un investissement. En installant des panneaux, j’ai décidé d’acheter l’équivalent d’un stock d’électricité à prix fixe (le coût de l’installation divisé par la production future) plutôt que de louer cette énergie à un fournisseur dont les tarifs sont indexés sur des crises géopolitiques que je ne maîtrise pas.
Mais attention, pour que ce calcul fonctionne, il ne faut pas dimensionner l’installation au doigt mouillé.
L’analyse de consommation : Le pré-requis indispensable
Avant même de contacter un installateur, j’ai réalisé un audit de ma propre maison. Beaucoup font l’erreur de regarder leur facture annuelle globale. C’est insuffisant.
Il faut comprendre quand on consomme.
Le solaire ne produit que le jour (sans blague). Si votre consommation se fait à 80% la nuit (chauffage électrique sans inertie, vie nocturne), le solaire sans batteries sera un échec financier.
J’ai extrait mes données horaires via le site d’Enedis (merci le compteur Linky) pour isoler mon « bruit de fond » énergétique, ce qu’on appelle le talon.
C’est la consommation incompressible de la maison quand « rien » n’est allumé : frigo, box internet, VMC, veille des appareils. Chez moi, ce talon justifiait une base de production, mais pour atteindre la rentabilité sur 6kWc, il fallait que je sois capable de déplacer mes gros consommateurs (Lave-linge, Sèche-linge, Lave-vaisselle, Cumulus) en journée. C’est ce potentiel de « déplacement de charge » qui a validé le projet.
2. L’Étude technique : Choisir sans se faire avoir
Une fois le besoin validé, il fallait choisir le matériel. Le marché du solaire est une jungle où côtoient artisans passionnés et éco-délinquants. Voici mes choix techniques et, surtout, pourquoi je les ai faits.
Autoconsommation avec vente du surplus : Le choix logique
J’ai opté pour le modèle standard : je consomme ce que je produis en priorité, et ce que je ne consomme pas est injecté automatiquement dans le réseau et vendu à EDF OA (Obligation d’Achat).
En octobre 2023, ce contrat garantissait un tarif de rachat fixe (autour de 13 cts/kWh) pendant 20 ans. C’est une sécurité financière majeure qui permet d’amortir l’installation même si je ne suis pas à la maison pour consommer.
Le Matériel : DualSun et Enphase, le couple franco-américain
Une passerelle de communication Enphase Envoy S-Metered
Pourquoi ce choix ?
Les Panneaux DualSun (375 Wc) : C’est une marque française (fabriqué en Asie, soyons honnêtes, mais ingénierie française). La technologie « Half-Cut » (demi-cellules) permet une meilleure gestion de l’ombrage partiel et réduit les pertes résistives. Ils sont robustes et esthétiquement sobres (cadre noir).
Micro-onduleurs vs Onduleur Central : C’était le grand débat. J’ai choisi les micro-onduleurs Enphase IQ8M.
Pourquoi l’IQ8M ?
Contrairement à un onduleur central (type SMA ou Fronius) qui gère toute la chaîne en série (si un panneau lâche ou est à l’ombre, toute la chaîne chute), le micro-onduleur gère chaque panneau indépendamment.
Mais pourquoi le modèle IQ8M ? C’est la dernière génération d’Enphase capable de créer un micro-réseau (bien que je n’utilise pas encore le mode « Sunlight Backup » sans batterie). Le suffixe « M » indique une puissance de sortie adaptée à mes panneaux de 375Wc. Avec un peak output power de 330VA, le ratio DC/AC est de 1.13, ce qui est excellent pour éviter l’écrêtage tout en maximisant la production en faible luminosité.
La parenthèse « Kits prêts à poser » et le piège du rendement
Avant de signer mon devis, j’ai évidemment regardé les kits « Plug & Play » qu’on trouve en magasin de bricolage. Sur le papier, c’est séduisant : pas d’artisan, on branche sur une prise, et c’est parti. Mais pour 6kWc, cette solution n’était pas viable, et il faut mettre en garde contre un mirage marketing fréquent.
Un panneau de 400W ne produira jamais 400W s’il est mal orienté. Les kits de balcon, souvent posés à la verticale (90°) ou avec une inclinaison approximative, perdent énormément de rendement par rapport à une installation toiture optimisée (généralement 30-35°).
Le piège, c’est de confondre la Puissance Crête (ce que le panneau peut sortir en laboratoire) et la Production Réelle (l’énergie utile).
Sur beaucoup de kits, l’onduleur est sous-dimensionné volontairement (pour respecter la limite d’injection sur prise simple). Vous achetez un panneau 420Wc, mais le micro-onduleur bride à 350VA. C’est ce qu’on appelle l’écrêtage. Ce n’est pas grave en soi, mais c’est une perte sèche en plein été. Pour mon projet de 6kWc, je voulais une cohérence totale entre la capacité des panneaux DualSun et celle des IQ8M pour récupérer chaque photon disponible.
3. L’Installation et la mise en service (Octobre 2023)
Une fois le matériel validé, place à l’action. L’installation s’est faite fin octobre 2023.
Poser 16 panneaux n’est pas anodin. Il faut gérer la répartition sur le toit, le passage des câbles DC sous les tuiles et la descente vers le tableau électrique. L’avantage des micro-onduleurs Enphase ici, c’est la sécurité : on ne descend pas du courant continu haute tension (dangereux en cas d’arc électrique) dans la maison, mais directement du courant alternatif 230V.
Côté administratif, il ne faut pas sous-estimer les délais. Entre la déclaration préalable en mairie (DP), la demande de raccordement Enedis et le passage du Consuel (obligatoire pour valider la sécurité électrique avant d’injecter), c’est un parcours qui demande de la patience. Dans mon cas, tout a été bouclé pour une mise en service effective fin 2023.
4. Production et Pilotage : La réalité des chiffres (2024-2025)
C’est ici que le geek prend le dessus. Après plus de deux ans de recul, je peux sortir le nez des estimations théoriques pour vous donner la réalité du terrain.
Les Outils de monitoring : Enphase Enlighten
Pour piloter le tout, j’utilise la passerelle Envoy S-Metered. Notez bien le « Metered ». Contrairement à la version standard qui ne mesure que la production, celle-ci utilise des tores de mesure (pinces ampèremétriques) placées sur l’arrivée générale de la maison.
Résultat : Je vois ce que je produis, mais surtout ce que je consomme et ce que j’importe/exporte en temps réel.
Sans cette visibilité, l’autoconsommation se fait à l’aveugle.
Production brute : 17,4 MWh en deux ans !
Voici les données extraites de mon suivi pour une puissance installée de 6 kWc :
Année
Production Totale
Ratio de performance (kWh/kWc)
2024
8.9 MWh
~1 483 kWh/kWc
2025
8.5 MWh
~1 416 kWh/kWc
Analyse des données :
La variabilité météo : On note une baisse de production d’environ 4,5% entre 2024 et 2025. C’est normal. Le soleil n’est pas une constante absolue d’une année à l’autre.
L’efficacité redoutable : Avec un ratio approchant les 1 500 kWh produits par kWc installé en 2024, mon installation performe extrêmement bien (la moyenne nationale se situe souvent entre 1100 et 1300 selon la région). L’association DualSun + Enphase fait des merveilles, aidée par une orientation/inclinaison quasi parfaite (33% d’inclinaison pour une orientation quasi plein sud) et une ventilation correcte des panneaux (qui perdent du rendement quand ils chauffent trop).
Concrètement, cela signifie que je consomme directement environ 45% de ma production. Le reste (55%) provient du réseau.
Malgré mes efforts (départ différé des machines, chauffe-eau en journée), je stagne sous la barre des 50%. Pourquoi ? Parce qu’en été, les journées sont longues et la production explose (parfois 40 kWh/jour), bien au-delà des besoins de la maison. Sans batterie physique ou véhicule électrique à charger le week-end, il est difficile de monter plus haut sur une installation de 6kWc. C’est là que la vente du surplus devient vitale pour la rentabilité.
5. L’Heure du bilan : Rentabilité et ROI réel
Parlons cash. On entend tout et n’importe quoi sur la rentabilité du solaire. Voici mes chiffres réels, facture à l’appui, sans filtre.
Le coût final de l’opération
Pour une installation de 6 kWc clés en main (matériel + pose + démarches), la facture s’est élevée à :
Investissement initial : 13 900 € TTC
Prime à l’autoconsommation (État) : – 2 000 €
COÛT RÉEL FINAL : 11 900 €
Scénario 1 : Ma réalité (Contrat 2023)
Avec un taux d’autoconsommation d’environ 45% (les 55% restants provenant du réseau) et un tarif de rachat du surplus figé à 0,13 €/kWh (le tarif en vigueur lors de ma demande), voici mon rendement annuel moyen (basé sur une moyenne de 8,7 MWh/an) :
Économies sur facture (Autoconsommation) :~3 915 kWh que je n’ai pas achetés à EDF (base 0,25€/kWh) = 978 € d’économies.
Vente du surplus (Injection) :~4 785 kWh vendus à EDF OA (0,13€/kWh) = 622 € de revenus.
Gain annuel total : ~1 600 €
Retour sur Investissement (ROI) : 11 900 € / 1 600 € = 7,4 ans.
Verdict : Un amortissement en moins de 7 ans et demi pour un matériel garanti 20 ou 25 ans, c’est un placement financier imbattable, bien supérieur à n’importe quel Livret A.
Scénario 2 : Si c’était à refaire aujourd’hui (Le piège des 4 centimes)
C’est ici que mon article doit vous servir d’alerte. Les règles du jeu ont changé. Récemment, le tarif de rachat du surplus a chuté drastiquement pour avoisiner les 0,04 €/kWh (selon les trimestres). Refaisons le calcul avec ce nouveau paramètre, en gardant la même installation :
Économies sur facture : 978 € (Inchangé).
Vente du surplus (Nouveau tarif) :~4 785 kWh * 0,04 € = 191 € (au lieu de 622 € !).
Gain annuel total : ~1 169 €
Nouveau ROI : 11 900 € / 1 169 € = 10,2 ans.
Cette chute du tarif de rachat bouleverse la stratégie.
En 2023 (mon cas) : La vente du surplus était un pilier de la rentabilité. Je pouvais me permettre d’injecter quasiment 60% de ma production sans trop de douleur.
Aujourd’hui : Vendre à 4 centimes ne couvre presque plus rien. La priorité absolue n’est plus de produire beaucoup, mais de tout consommer. Cela remet en lumière l’intérêt des batteries virtuelles ou physiques, qui étaient économiquement non-viables il y a deux ans mais qui, avec un rachat si faible, redeviennent une option à étudier sérieusement pour ne pas « gâcher » 60% de sa production.
6. Conclusion
Après plus de deux ans, est-ce que je regrette mes 11 900 € ? Absolument pas.
Produire 17,4 MWh d’énergie verte depuis mon toit est une satisfaction quotidienne. Voir mon compteur Linky afficher « 0 VA » de consommation alors que le four et la machine à laver tournent est un plaisir dont on ne se lasse pas.
Techniquement, le couple DualSun / Enphase est d’une stabilité exemplaire : aucune panne, monitoring précis, production au rendez-vous.
Cependant, si vous vous lancez aujourd’hui, ne copiez pas aveuglément mon modèle économique. Faites vos calculs avec le tarif de rachat actuel. Si vous ne pouvez pas déplacer vos consommations en journée, le ROI risque de s’éloigner. Le solaire reste rentable, mais il demande désormais d’être encore plus intelligent sur son pilotage.
Dans le monde de l’infrastructure, on sait que chaque cluster se doit d’être monitoré. On ne lance jamais une mise à jour majeure sans avoir vérifié l’état des nœuds et s’être assuré de la redondance. Pour nos vies pro et perso, ça devrait être la même chose.
2025 s’achève, et si je devais résumer cette année, ce ne serait pas une simple migration à chaud, mais une véritable évolution d’architecture, avec quelques incidents de prod. C’est le moment de faire le Health Check complet. Pas de filtre, juste de la data, de l’infra et du ressenti.
Voici mon audit post-mortem de 2025 et ma roadmap pour 2026.
2025 : Rétrospective sans filtre (Le Health Check)
Cette année a marqué un tournant critique dans ma carrière : ma première année complète en tant que Team Lead, tout en restant Consultant Senior expert en infrastructures hyperconvergées chez un Nutanix Pure Player : Mikadolabs.
De l’Expert Technique au Team Lead
Pour les néophytes, passer de « Consultant Senior » à « Team Lead », c’est un peu comme passer de la gestion d’un seul cluster à l’orchestration de tout un datacenter. On change d’échelle. On ne gère plus seulement des IOPS et de la latence, mais des humains et de la planif.
Sur le papier, le blueprint était clair. Dans la réalité, l’exécution demande une vigilance de tous les instants.
Globalement, la stack a tenu. L’équipe a délivré, et les projets d’infrastructures ont été menés à bien. J’ai appris à déléguer l’opérationnel (parfois douloureux pour un puriste) pour me concentrer sur l’organisation et l’amélioration des processus. Voir un membre de l’équipe monter en compétence sur des sujets complexes, mais pas forcément techniques, grâce à mon accompagnement m’a apporté une satisfaction différente, mais tout aussi puissante que la résolution d’une panne critique.
Soyons transparents : tout n’a pas été fluide. Le plus dur pour un profil ultra technique comme le mien, c’est de s’éloigner de la console.
J’aime mettre les mains dans le cambouis, tuner les performances, auditer les clusters. En devenant Team Lead, j’ai dû accepter de passer moins de temps sur Prism Element ou en ligne de commande, et plus de temps en réunion ou en planification. J’ai parfois eu l’impression de perdre ma « connexion » directe avec la tech, ce syndrome de l’imposteur qui guette ceux qui s’éloignent de la prod.
C’est un équilibre précaire que je continue d’ajuster pour 2026 : rester un des experts référents de l’équipe sans en devenir le goulot d’étranglement.
2025 en Data : L’Analyse des Logs
Un bon architecte ne se fie pas au doigt mouillé, il regarde les métriques. Et cette année, si je n’avais pas ouvert mes dashboards, j’aurais eu une vision totalement biaisée de ma propre performance.
C’est là que la data devient pertinente : elle ne ment pas, contrairement à notre cerveau qui a tendance à effacer les succès pour se focaliser sur les manques.
Le Blog : Une croissance « Scale-Out »
Les chiffres de fréquentation sont plutôt bons pour un blog tech personnel.
Les KPIs de l’année :
Production : 60 articles publiés (soit une moyenne de 5 articles/mois). Une régularité d’horloge suisse.
Trafic : 39,3k Vues (+868%) et 23,8k Visiteurs uniques (+924%). Note : Les chiffres d’évolution par rapport à 2024 sont un peu biaisés car l’outil qui me servait jusqu’alors à suivre la fréquentation du blog a changé sur le dernier trimestre 2024.
Engagement : Une communauté qui grandit sur LinkedIn et qui commence à commenter et interagir, signe que mon contenu trouve sa cible.
On observe une corrélation directe entre la densité de publication (notamment les pics de Mai et la régularité du dernier trimestre) et l’explosion du trafic organique. C’est la preuve par l’exemple que le SEO technique, couplé à du contenu de fond (pas de simples articles ChatGPT), paie sur la durée. Le blog est passé d’un statut « confidentiel » à une véritable ressource consultée. De nombreux clients (pour ne pas dire « tous ») m’ont déjà dit qu’ils lisaient le blog régulièrement. Merci, c’est ce qui me pousse à continuer !
Sport : Le bug de perception
C’est ici que la rétrospective devient surprenante. Si vous m’aviez demandé hier : « Julien, as-tu été sportif cette année ? », je vous aurais répondu avec frustration : « Oui, mais pas assez régulier à mon goût, j’ai l’impression d’avoir stagné ».
J’ai donc extrait les logs de mes activités (Course à pied et Vélo, merci Strava) pour constater l’étendue des dégâts. Et là, surprise : les logs contredisent mon monitoring mental.
Activité
2024 (Baseline)
2025 (Prod)
Différentiel
Course à pied
106 km
487 km
x 4,5
Vélo
444 km
1987 km
x 4,5
C’est un cas d’école de « Faux Positif ». Mon cerveau s’est focalisé sur les semaines « sans » (seulement 3 semaines sur 52 à 0 activité), en oubliant la volumétrie globale.
En réalité, j’ai multiplié mon volume d’activité par 4,5 par rapport à 2024. J’ai parcouru près de 2500 km tous sports confondus. C’est pas si mal, mais je compte bien faire mieux en 2026 !
La leçon pour 2026 ? Trust the data. Comme en prod, quand on pense qu’il y a un problème de latence, on regarde d’abord les courbes avant de rebooter. Je n’ai pas été « irrégulier », j’ai simplement changé d’échelle sans m’en rendre compte.
Objectifs 2026 : Ma Tech Radar & Roadmap
Un bilan ne sert à rien s’il ne permet pas de mettre à jour la roadmap. Pour 2026, je ne prévois pas de révolution, mais une évolution ciblée de ma stack technique et personnelle. L’objectif ? Réduire la dette technique et préparer l’avenir.
1. La Veille Techno : K8s et l’IA (Pragmatique)
Il y a deux sujets majeurs sur lesquels je compte monter en compétence, non pas par « Hype », mais par nécessité opérationnelle :
Kubernetes (K8s) : C’est devenu incontournable. Même dans un monde hyperconvergé, l’orchestration de conteneurs est la couche supérieure standard. C’est un sujet que j’ai longtemps repoussé, par manque de temps. Je veux donc apprendre les bases, et aller au-delà pour maîtriser l’architecture et le troubleshooting avancé.
L’IA (Utilisateur & Intégrateur) : Je ne parle pas de jouer avec des prompts pour générer des images de chats ou des chansons parodiques. Mon objectif est double : optimiser mon workflow quotidien (IA comme assistant) et surtout comprendre comment l’intégrer techniquement dans des solutions (API, automatisation). L’IA ne remplacera pas l’architecte, mais l’architecte qui utilise l’IA remplacera celui qui ne le fait pas.
2. Le Side Project : L’Audit Automatisé
C’est le gros morceau « Dev » de l’année. En tant que consultant, je passe beaucoup de temps à auditer des infrastructures. Je travaille sur le développement d’une application d’audit automatisé.
L’idée est simple : scripter l’intelligence et les checks récurrents pour gagner du temps sur la collecte de data et se concentrer sur l’analyse à haute valeur ajoutée. C’est un projet qui mixe mes compétences infra et mes envies de code. Stay tuned, j’en reparlerai sûrement ici.
3. L’infrastructure Humaine : Maintenance Préventive et MCO
Enfin, parlons de mon Hardware : mon corps.
Les logs 2025 m’ont montré que la machine est capable d’encaisser la charge, mais il va falloir optimiser la configuration. Mon objectif 2026 est d’investir un peu plus sur ma santé comme on investit dans une infrastructure critique :
Plus de sport : Continuer sur la lancée de 2025 pour viser la régularité absolue et augmenter le volume avec des entraînements plus structurés.
Moins de stress : Mieux cloisonner le pro et le perso, et apprendre à choisir mes batailles.
Nourriture Healthy : Faire un peu plus attention à mon alimentation pour booster les bienfaits de l’activité physique.
Mes vœux pour vous : Soyez curieux, soyez résilients
Pour conclure cette première publication de 2026, je ne vais pas me contenter des formules habituelles. En 2026, je vous souhaite deux qualités essentielles : la Curiosité et la Résilience.
Ne soyez pas intimidés par la montagne. L’informatique, comme n’importe quel domaine d’expertise, s’apprivoise étape par étape. Soyez curieux, osez tester, osez vous tromper. C’est l’unique chemin pour apprendre.
Je vous souhaite également de la Résilience. Dans nos projets comme dans nos vies, tout ne se passe jamais exactement comme prévu sur le papier. Il y aura des imprévus, des erreurs, des moments de fatigue. Ce n’est pas grave.
La vraie force n’est pas de ne jamais tomber, mais de savoir rebondir. Soyez indulgents avec vous-mêmes quand ça ne marche pas du premier coup. Acceptez les moments de moins bien, apprenez, et repartez. C’est ça, la vraie performance durable.
A tous, je vous souhaite une excellente année 2026.
On pourrait croire qu’avec le temps, on s’habitue. Qu’après deux ans, l’ouverture de l’email annonçant les résultats devient une simple formalité administrative. Eh bien, je vous le confesse : pas du tout.
C’est avec une immense fierté – et un soulagement non dissimulé – que je vous annonce ma nomination en tant que Nutanix Technology Champion (NTC) pour l’année 2026. C’est la troisième année consécutive que j’ai l’honneur de rejoindre ce groupe d’experts passionnés.
Pour être tout à fait transparent, je ne prends jamais cette distinction pour acquise. Dans le monde de l’IT, les technologies évoluent vite, et nous aussi. Rester pertinent demande du travail, de la curiosité et surtout, l’envie de partager. Voir son nom figurer à nouveau sur la liste officielle des NTC 2026 est donc une belle validation des efforts fournis sur le blog tout au long de l’année.
C’est quoi un « NTC » ? (Spoiler : Ce n’est pas juste un badge LinkedIn)
Souvent, on me demande si c’est un examen que j’ai passé, comme une certification NCP-MCI. La réponse est non, et c’est justement ce qui fait la beauté de ce programme.
Le programme Nutanix Technology Champion ne récompense pas uniquement la réussite à un QCM technique. C’est une distinction qui reconnaît l’engagement communautaire. En gros, Nutanix repère ceux qui passent leur temps libre à tester, casser, réparer et surtout expliquer leurs technologies aux autres. Que ce soit via des articles de blog (comme ici), des interventions sur les forums, ou des talks lors d’événements.
Pour les puristes, c’est l’équivalent du vExpert chez VMware ou du MVP chez Microsoft. C’est la validation de ce qu’on appelle les « Soft Skills » techniques : la capacité à évangéliser une solution non pas parce qu’on est payé pour le faire, mais parce qu’on en maîtrise les arcanes et qu’on aime ça. C’est une reconnaissance par les pairs et par l’éditeur, et c’est ce qui rend la chose si gratifiante.
Sous le capot : Pourquoi cette nomination est importante pour le blog
Au-delà du logo brillant à mettre en signature, être NTC a un impact direct sur la qualité de ce que je peux vous proposer sur juliendumur.fr. Ce n’est pas un titre honorifique vide de sens, c’est une clé qui ouvre des portes intéressantes.
Concrètement, ce statut me donne un accès privilégié aux coulisses. J’ai l’opportunité d’échanger directement avec les Product Managers et les équipes d’ingénierie de Nutanix. Cela signifie que lorsque je rédige un article technique, je peux valider mes hypothèses à la source, évitant ainsi les approximations.
De plus, nous avons accès à des briefings sur la roadmap et aux versions Bêtas. Même si ces informations sont souvent sous NDA (je ne peux pas tout vous révéler à l’avance !), cela me permet de comprendre la direction que prend la technologie. Je peux ainsi mieux anticiper les sujets à traiter et vous proposer des analyses plus pertinentes dès que les fonctionnalités passent en General Availability (GA). C’est l’assurance pour vous de lire du contenu qui est non seulement techniquement juste, mais aussi en phase avec la réalité du marché.
Rétrospective et Objectifs 2026 : On ne lâche rien
Cette troisième nomination est le fruit de la régularité. Mais elle marque surtout le début d’une nouvelle année de « lab ». Le but n’est pas de collectionner les étoiles, mais de continuer à explorer la Nutanix Cloud Platform sous toutes ses coutures.
Pour 2026, je compte bien continuer à vous proposer des tutoriels pratiques et des retours d’expérience. Si l’hyperviseur AHV reste le socle incontournable, j’ai très envie de monter un peu plus dans les couches logicielles cette année. Attendez-vous à voir passer des sujets autour de l’orchestration de conteneurs avec NKP (Nutanix Kubernetes Platform), de l’automatisation, et probablement un focus plus appuyé sur la sécurité avec Flow. L’objectif reste le même : décortiquer la techno pour la rendre accessible.
Un immense merci à la communauté pour les échanges quotidiens, et bien sûr à l’équipe du programme NTC (clin d’œil à Angelo Luciani) pour leur confiance renouvelée. C’est un plaisir de faire partie de cette famille virtuelle.
Maintenant, la balle est aussi dans votre camp : y a-t-il des sujets spécifiques ou des fonctionnalités de l’écosystème Nutanix que vous aimeriez me voir traiter cette année ? Les commentaires sont ouverts !
Je ne vais pas vous mentir : quand on a goûté à l’or, le bronze a une saveur particulière. L’année dernière, j’avais l’immense fierté de finir premier au classement des « Top Bloggers » du programme Nutanix Technology Champion (NTC).
Est-ce que j’ai ralenti ? Non. Est-ce que j’ai moins partagé ? Au contraire. Mais dans la tech comme dans le sport, rester au sommet est souvent plus dur que d’y arriver. Cette 3ème place, c’est avant tout le signal que la compétition s’est intensifiée. Et très honnêtement ? C’est exactement ce qu’il fallait pour me motiver à repartir au combat pour 2026.
Le programme NTC n’est pas qu’un simple badge
Pour ceux qui découvrent l’écosystème, être Nutanix Technology Champion (NTC), ce n’est pas juste coller un logo sur son profil LinkedIn. C’est un engagement. C’est faire partie d’une avant-garde technique qui teste, casse, répare et surtout documente les solutions Nutanix.
Le classement « Top Blogger », c’est le baromètre de cette activité.
1er en 2024, 3ème en 2025 : L’analyse des logs
Alors, que s’est-il passé ? J’ai sorti mes logs pour comparer.
Si j’avais baissé de régime, j’aurais accepté cette 3ème place avec un haussement d’épaules. Mais les datas montrent autre chose : mon volume de publication est équivalent à celui de l’année dernière. Mieux encore, ma stratégie était plus propre : au lieu de faire des « bursts » (des rafales d’articles), j’ai maintenu une régularité métronomique, étalée uniformément sur les 12 mois.
Le constat est donc simple et sans appel : le niveau global a monté.
Mes confrères ont été monstrueux cette année. Ils ont produit plus. C’est une excellente nouvelle pour la communauté Nutanix : l’écosystème est vivant, dense et de plus en plus pointu. Mais pour le compétiteur en moi, c’est un signal d’alarme. La régularité ne suffit plus, comme sur le vélo, il va falloir remettre de l’intensité.
Pourquoi publier ?
Au-delà du classement et de la compétition, pourquoi continuer à écrire avec autant de discipline ?
La réponse est pragmatique. Mon blog, c’est d’abord ma mémoire externe. Dans notre métier, on ne retient pas tout. On teste, on configure, on rencontre une erreur critique, on la résout… et six mois plus tard, on a oublié comment on a fait.
Blogger, c’est documenter mes propres « galères » pour ne plus jamais avoir à chercher la solution deux fois. C’est transformer un troubleshooting obscur en un tutoriel clair.
Mais ne vous y trompez pas : chaque article est né d’un vrai besoin technique, d’une vraie infra que j’ai montée ou réparée. Pas de théorie fumeuse, juste du terrain.
La cerise sur le gâteau : les retours de tous nos clients qui sont déjà tombés sur mon blog et qui me disent « on a trouvé une solution sur ton blog ». C’est ça la vraie récompense.
Conclusion : Rendez-vous sur la ligne d’arrivée
Bravo aux deux confrères qui m’ont devancé cette année. Vous avez placé la barre très haut, et c’est tout ce que j’aime. Le niveau du programme NTC est ce qui le rend crédible.
Mais le message est passé. La régularité de 2025 était une bonne base, mais pour 2026, je change de braquet. Je vais aller chercher des sujets plus pointus, creuser plus profond dans les entrailles de Nutanix AOS et AHV, et peut-être explorer des cas d’usage que personne n’a encore documentés.
La médaille de bronze, c’est bien. Mais elle va surtout servir de rappel sur mon bureau : l’année prochaine, je vise le maillot jaune.
Derrière ce titre à la référence musicale se cache l’événement annuel organisé par Nutanix France : le Nutanix .NEXT on Tour !
Nutanix .NEXT on Tour Paris
Comme l’année dernière, Nutanix organise une fois de plus une édition du NEXT on Tour à Paris le 2 octobre 2025 au CNIT La Défense.
Au programme de cette journée, des sessions plénières, des keynotes, des retours d’expériences… Certains partenaires auront également un stand, l’occasion parfaite pour les clients français de l’éditeur de pouvoir échanger durant toute une journée avec des professionnels des infrastructures hyperconvergées.
Parmi les sujets qui seront abordés lors de cette journée, vous pourrez retrouver :
La migration vers Nutanix
La gestion et l’automatisation du votre cloud hybride avec Nutanix Cloud Manager
En tant Nutanix Pure Player, Mikadolabs aura un stand cette année encore lors du salon. Je serais présent là bas une bonne partie de la journée pour vous recevoir et répondre à vos questions concernant Nutanix et l’hyperconvergence avec une partie de la Team.
N’hésitez pas à passer dire bonjour et si vous n’êtes pas encore inscrit à l’événement, vous pouvez encore le faire via ce lien : Inscriptions à l’événement
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.
