Je fais tourner un agent autonome (Hermes Agent de Nous Research) sur un mini PC dédié à la maison. Jusqu’à cette semaine, toutes ses requêtes LLM passaient par OpenRouter, avec DeepSeek V4 Flash comme modèle par défaut.

OpenRouter, c’est pratique : une seule clé, des dizaines de modèles, paiement à l’usage. Mais le paiement à l’usage a un défaut quand on laisse tourner un agent : on ne sait jamais à l’avance ce qu’on va payer.

J’ai regardé mes chiffres. Ils m’ont décidé.

Les chiffres qui font mal

Sur 2 jours d’utilisation, voici ce que mon dashboard OpenRouter affichait :

Deux choses sautent aux yeux.

D’abord, 3,71 $ en deux jours. Si je projette ça sur un mois, je tourne autour de 55 $. C’est beaucoup pour un agent perso.

Ensuite, le détail qui m’a le plus surpris : DeepSeek V4 Pro. 13 requêtes seulement, mais 1,40 $ soit près de 40 % de ma facture pour 1,5 % de mes appels. Ces quelques requêtes lourdes que l’agent décide de router vers un gros modèle, on ne les voit pas venir. Et c’est exactement là que le paiement à l’usage devient imprévisible.

OpenCode Go : le coût fixe

OpenCode Go, c’est un abonnement à 10 $/mois (5 $ le premier mois) qui donne accès à une douzaine de modèles open source curatés : DeepSeek V4 Flash et Pro, Qwen3, Kimi K2, GLM-5, MiniMax, MiMo.

Le point clé pour moi : l’endpoint est compatible OpenAI. Pas besoin d’utiliser l’outil OpenCode lui-même. On branche la clé sur n’importe quel agent qui parle à une API LLM/Hermes dans mon cas.

La migration, étape par étape

Bonne surprise : Hermes supporte OpenCode Go nativement. La section est déjà prévue dans le fichier de config. La bascule m’a pris cinq minutes.

1. Récupérer la clé OpenCode Go

Après abonnement sur opencode.ai/go, la clé API se récupère depuis le dashboard. Elle commence par sk-.

2. Ajouter la clé dans le .env

Le fichier d’environnement de Hermes se trouve dans ~/.hermes/.env. On y décommente la ligne dédiée à OpenCode Go et on colle la clé :

bash

OPENCODE_GO_API_KEY=sk-votre-cle-ici

À noter : on peut laisser l’ancienne clé OpenRouter en place. Hermes utilise le provider défini dans la config, pas celui dont la clé est présente. Pratique pour revenir en arrière sans rien réécrire.

3. Pointer Hermes sur OpenCode Go

Trois commandes suffisent. On change le provider, l’URL de base, et le modèle par défaut :

bash

hermes config set model.provider opencode-go
hermes config set model.base_url https://opencode.ai/zen/go/v1
hermes config set model.default opencode-go/deepseek-v4-flash

Je garde le même modèle (DeepSeek V4 Flash), je change juste le tuyau qui y mène.

4. Vérifier depuis Telegram

Mon Hermes est piloté en partie via Telegram. La commande /model affiche la configuration courante et permet de changer de provider à la volée. C’est le moyen le plus rapide de confirmer que la bascule a pris.

Et le résultat une fois le modèle sélectionné :

C’est fait. L’agent tourne désormais entièrement sur OpenCode Go.

Le calcul, sans enjoliver

Sur le papier, c’est 80 % d’économie. Mais je veux être honnête sur deux nuances, parce que c’est facile de vendre du rêve avec ce genre de tableau.

Nuance 1 : mes deux jours étaient atypiques. J’étais en plein build de mon serveur d’automation, avec des sessions très denses. Mon usage courant est plus léger. Donc les 55 $ projetés sont un plafond, pas une moyenne.

Nuance 2 : OpenCode Go n’est pas illimité. Les limites sont exprimées en valeur dollar, pas en nombre de requêtes, et elles se rechargent toutes les 5 heures. Les modèles plus légers durent plus longtemps que les gros. Si vous balancez du DeepSeek V4 Pro en continu, vous taperez le plafond. Pour un usage agent normal sur un modèle Flash, ça passe largement.

Autrement dit : l’économie est réelle, mais elle suppose un usage qui rentre dans les limites du forfait. Ce n’est pas une licence pour consommer sans compter.

Ce que je retiens

Le vrai gain, ce n’est pas seulement le prix. C’est la prévisibilité. Je sais que je paie 10 $ ce mois-ci, point. Plus de facture qui dérape à cause de quelques requêtes routées vers un modèle premium sans que je l’aie demandé.

Pour un agent qui tourne 24/7 sur du matériel perso, c’est exactement ce que je cherchais : un coût plat, une seule clé, et assez de modèles pour ne jamais être bloqué.

Je n’abandonne pas OpenRouter pour autant

Important : OpenCode Go remplace OpenRouter pour le cerveau texte de mon agent, pas pour tout le reste. Je garde OpenRouter en parallèle, et il garde tout son sens pour des usages plus spécialisés : le TTS, la génération d’image et la génération de vidéo. C’est devenu un vrai hub multimodal, là où le paiement à l’usage reste le bon modèle, on ne génère pas une vidéo toutes les cinq minutes.

En vidéo justement, je travaille beaucoup en local sur ma machine principale (ComfyUI, GPU dédié). LTX et Wan sont d’excellents modèles open source, largement suffisants pour la plupart de mes besoins, et gratuits une fois le matériel amorti.

Mais soyons honnêtes : quand je veux le résultat au-dessus du lot, un Seedance 2.0 reste exceptionnel. C’est là que le cloud garde l’avantage pour ces générations ponctuelles où la qualité prime sur le coût. D’où l’intérêt de garder une porte ouverte sur OpenRouter, qui donne accès à ce genre de modèle sous la même clé.

La bonne architecture, pour moi, n’est donc pas « tout cloud » ni « tout local ». C’est : OpenCode Go pour le LLM de l’agent (coût fixe, prévisible), le local pour le gros du multimodal (LTX, Wan), et OpenRouter en appoint pour le TTS et les générations haut de gamme comme Seedance 2.0.

En résumé

Si votre conso OpenRouter en LLM dépasse régulièrement 10 $/mois, basculer le cerveau de votre agent vers OpenCode Go est vite rentable. En dessous, restez sur le paiement à l’usage vous paierez moins. Et dans les deux cas, gardez OpenRouter sous la main pour ce qu’il fait désormais très bien : le multimodal à la demande.

Depuis quelques mois, je vois passer beaucoup de publications et de vidéos YouTube qui expliquent qu’il faut un Mac mini ou un VPS pour faire tourner un agent autonome comme OpenClow ou Hermes Agent. 700€ la machine, ou un abonnement mensuel qui part indéfiniment. Et en y réfléchissant bien, à ce qu’on leur demande concrètement : tourner 24h/24, attendre des messages Telegram, exécuter des workflows la nuit pendant qu’on dort. Pas de l’inférence lourde, pas de rendu 3D. Juste orchestrer et déléguer.

Je vais te montrer une autre voie : un mini PC à 130€, moins gourmand, moins cher, qui fait exactement le même boulot.

Cette machine tourne sans écran ni clavier depuis plusieurs semaines chez moi. Elle reçoit mes ordres par Telegram, exécute des tâches en arrière-plan, et s’appuie sur ma machine principale ou OpenRouter quand elle a besoin de compute. C’est le control plan permanent du setup, pas la brute de calcul.

Voilà comment j’ai fait, brique par brique, avec les détails d’installation que j’aurais aimé trouver en un seul endroit.

1. Le matos et pourquoi pas autre chose

Le mini PC : MLLSE G2 Pro

Intel N150, 12 Go de LPDDR5, 512 Go de SSD, WiFi 5, Bluetooth 5.0. Windows 11 Pro pré-installé, que j’ai remplacé par du Linux en dix minutes.

Le N150 est un quad-core basse consommation. Il ne va pas faire tourner un Llama 70B en local. Ce n’est pas son rôle. Son rôle, c’est d’être sobre et toujours allumé. Sous charge normale de serveur, il tire 9W. C’est ridicule. Une ampoule LED de bureau en consomme davantage. Ramené à l’année entière, ça représente environ 8€ d’électricité pour un serveur qui tourne 24h/24, à comparer aux 180€ d’un VPS entrée de gamme sur la même période, rien qu’en abonnement. Le chassis est conçu pour un usage permanent : pas de batterie qui gonfle, pas de ventilo qui s’encrasse.

Pourquoi pas un VPS cloud ?

5€/mois, ça paraît rien. Sur trois ans, tu as payé 180€ pour une machine qui n’est pas chez toi, qui ne voit pas ton réseau local, et qui te facture chaque byte de trafic sortant. Mon agent IA a besoin de parler à Ollama sur ma machine principale, à ComfyUI, à SearXNG. Avec un VPS, tout ça passerait soit par internet (latence plus coût), soit par un tunnel VPN. Avec un mini PC sur le LAN, c’est une simple requête HTTP sur le réseau interne. Pas de souci.

Le mini PC coûte plus cher le premier jour. Il est moins cher dès le quatorzième mois, et il reste sur ton réseau.

Pourquoi pas un vieux laptop ?

Un laptop qui tourne 24h/24, c’est une batterie qui gonfle dans les douze mois, un ventilo qui accumule de la poussière, et une consommation 3 à 5× supérieure au mini PC. La machine n’est pas faite pour ça. Le mini PC, si.

Pourquoi pas le Mac mini M4 à 700€ ?

Parce que le gros calcul, je l’ai déjà : Ryzen 9 + RTX 5070 Ti sur ma machine principale. Ce que je cherche ici, c’est un orchestrateur sobre et permanent qui sait déléguer. La même logique headless que partout ailleurs : mettre le bon outil au bon endroit, ne pas gâcher la ressource. Le Mac mini ferait la même chose six fois plus cher.

2. La stack : ce qu’on installe et pourquoi chaque brique

Avant le détail de l’installation, une vue d’ensemble de l’architecture cible.

[SCHÉMA : tazmenworld ↔ autoserver ↔ Telegram ↔ internet]

Le control plan (autoserver) décide et orchestre. Le compute (tazmenworld) calcule. La seule sortie cloud : les appels LLM vers OpenRouter. C’est du pay-per-use, pas un abonnement fixe. À l’usage courant, quelques dizaines de requêtes par jour sur DeepSeek V4, ça se chiffre en centimes. Tout le reste reste sur le réseau local.

3. Ubuntu Server 26.04 LTS : le socle headless

Pas d’interface graphique. C’est un serveur, il vit en console. On choisit Ubuntu Server 26.04 LTS « Resolute Raccoon », supporté jusqu’en 2031 (2036 avec Ubuntu Pro, gratuit jusqu’à 5 machines personnelles).

Créer la clé USB depuis tazmenworld

bash

cd ~/Downloads
wget https://releases.ubuntu.com/26.04/ubuntu-26.04-live-server-amd64.iso

# Identifier la clé USB
lsblk

# Écrire l'image (remplace /dev/sdX, ATTENTION : tout sera effacé)
sudo dd if=ubuntu-26.04-live-server-amd64.iso of=/dev/sdX bs=4M status=progress conv=fsync
sync

Options d’installation qui comptent

On démarre sur la clé (touche F7 ou Del au boot pour le menu), puis dans l’installeur Subiquity :

Une fois installé, on retire la clé USB, on redémarre. La machine boote en console texte. C’est normal, c’est voulu.

Mise à jour complète et outils de base

bash

sudo apt update && sudo apt upgrade -y
sudo apt autoremove -y

sudo apt install -y \
  curl wget git nano htop net-tools \
  ca-certificates gnupg lsb-release \
  ufw fail2ban unattended-upgrades \
  tree jq ncdu

sudo reboot

IP statique via Netplan

Un serveur ne peut pas changer d’IP à chaque redémarrage. On configure une IP fixe via Netplan, mais avant d’écrire quoi que ce soit, on vérifie la vraie adresse de la passerelle. Sur ton réseau, elle n’est pas forcément 192.168.1.1. La vérifier d’abord sur tazmenworld :

bash

ip route | grep default
# Exemple : default via 192.168.1.254 dev enp14s0
#                       ↑ c'est cette IP qu'on met dans netplan

Puis on identifie l’interface réseau sur autoserver :

bash

ip link show
# Exemple : enp2s0 (Ethernet), préférer l'Ethernet au WiFi pour un serveur

On édite la config :

bash

sudo nano /etc/netplan/00-installer-config.yaml

yaml

network:
  version: 2
  renderer: networkd
  ethernets:
    enp2s0:                        # adapter à ton interface
      addresses:
        - 192.168.1.20/24
      routes:
        - to: default
          via: 192.168.1.254       # ta vraie passerelle, pas une supposée
      nameservers:
        addresses: [1.1.1.1, 8.8.8.8]
      dhcp4: false

On applique et on vérifie :

bash

sudo netplan apply
ip addr show enp2s0        # l'IP 192.168.1.20 doit apparaître
ping -c 3 1.1.1.1          # si ça ne répond pas → passerelle incorrecte
ping -c 3 tazmenworld      # joignabilité réseau local

Synchronisation horaire

bash

sudo timedatectl set-timezone Europe/Paris
timedatectl status
# "System clock synchronized: yes" doit apparaître

Sécurisation SSH

On génère une paire de clés ed25519 sur tazmenworld :

bash

ssh-keygen -t ed25519 -C "tazmenworld→autoserver" -f ~/.ssh/autoserver_key

On copie la clé publique sur autoserver (avec le mot de passe temporaire) :

bash

ssh-copy-id -i ~/.ssh/autoserver_key.pub <votre_user>@192.168.1.20

On teste la connexion par clé :

bash

ssh -i ~/.ssh/autoserver_key <votre_user>@192.168.1.20

Puis on durcit la config SSH sur autoserver :

bash

sudo nano /etc/ssh/sshd_config

Port 2222
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 30
AllowUsers <votre_user>
X11Forwarding no

Spécificité Ubuntu 26.04, deux points à ne pas rater :

1. X11Forwarding en double. Le fichier par défaut contient souvent X11Forwarding yes plus haut. Commente cette ligne, sinon ta ligne no en bas sera ignorée.

2. Socket activation. Ubuntu 26.04 gère le port SSH via ssh.socket. Un simple restart ssh ne suffit pas :

bash

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket

⚠️ Teste depuis un deuxième terminal avant de fermer ta session actuelle :

bash

# Depuis tazmenworld, nouveau terminal
ssh -i ~/.ssh/autoserver_key -p 2222 <votre_user>@192.168.1.20

Si ça passe, on peut fermer l’ancienne session. On configure ensuite un profil SSH sur tazmenworld pour ne plus jamais taper l’IP :

bash

nano ~/.ssh/config

Host autoserver
    HostName 192.168.1.20
    Port 2222
    User <votre_user>
    IdentityFile ~/.ssh/autoserver_key
    ServerAliveInterval 60

Désormais : ssh autoserver. C’est tout.

Pare-feu UFW et Fail2ban

bash

# Règles UFW
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp comment "SSH"
sudo ufw allow 5678/tcp comment "n8n"
sudo ufw allow from 192.168.1.0/24 comment "Réseau local"
sudo ufw enable
sudo ufw status verbose

bash

# Fail2ban, bannissement auto des tentatives de brute-force
sudo nano /etc/fail2ban/jail.local

ini

[DEFAULT]
bantime  = 3600
findtime = 600
maxretry = 3

[sshd]
enabled  = true
port     = 2222
logpath  = /var/log/auth.log

bash

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Mises à jour automatiques de sécurité

bash

sudo dpkg-reconfigure --priority=low unattended-upgrades
# → Yes

Le serveur se patche tout seul sur les failles de sécurité. On n’a plus à y penser.

4. Docker : l’isolement propre

Pour n8n, on containerise. Docker isole le service, simplifie les mises à jour, et évite de polluer le système hôte.

Note Ubuntu 26.04 : Resolute Raccoon a supprimé le support de cgroup v1. Docker le gère nativement depuis la v20.10, mais il faut impérativement passer par le dépôt officiel Docker, pas le paquet docker.io des dépôts Ubuntu qui est souvent en retard.

Installation Docker CE (méthode officielle)

bash

# Supprimer d'éventuelles vieilles versions
sudo apt remove -y docker docker-engine docker.io containerd runc 2>/dev/null

# Clés GPG et dépôt officiel Docker
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL 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

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

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io \
                    docker-buildx-plugin docker-compose-plugin

Si apt update échoue avec une erreur sur le codename resolute : le dépôt Docker n’a peut-être pas encore indexé 26.04. Solution : forcer le codename noble (24.04), les paquets sont compatibles.

bash

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu noble stable" \
  | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update

Ajouter l’utilisateur au groupe docker

bash

sudo usermod -aG docker <votre_user>

Piège sur install minimized : newgrp n’est pas disponible. Le groupe ne s’active pas dans la session en cours. Tu dois te déconnecter et te reconnecter, sans message d’erreur explicite, juste un permission denied silencieux sur docker run si tu oublies ce détail.

bash

exit
# puis : ssh autoserver

# Tester depuis la nouvelle session
docker run --rm hello-world
docker compose version

Configurer le daemon Docker

bash

sudo nano /etc/docker/daemon.json

json

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "default-address-pools": [
    {"base": "172.20.0.0/16", "size": 24}
  ]
}

bash

sudo systemctl restart docker
docker info | grep -i "log driver"
# Attendu : Logging Driver: json-file

5. Structure des répertoires

bash

sudo mkdir -p /opt/autoserver/{n8n,hermes,shared,backups}
sudo chown -R <votre_user>:<votre_user> /opt/autoserver

/opt/autoserver/
├── n8n/
│   ├── docker-compose.yml
│   ├── .env
│   └── data/            ← volume persistant n8n
├── hermes/
│   └── data/
├── shared/              ← fichiers échangés entre services
└── backups/             ← sauvegardes automatiques

6. n8n : le moteur de workflows

n8n, c’est le chef d’orchestre des automatisations que tu as câblées. Il sait : « à 7h chaque matin, lance cette recherche ; si tel webhook arrive, déclenche ce traitement ». Interface visuelle, scriptable, il se connecte à des centaines de services.

Fichier d’environnement

bash

nano /opt/autoserver/n8n/.env

env

# Réseau
N8N_HOST=0.0.0.0
N8N_PORT=5678
N8N_PROTOCOL=http
WEBHOOK_URL=http://192.168.1.20:5678/

# Sécurité
N8N_ENCRYPTION_KEY=<générer_avec_openssl_rand_-hex_16>
GENERIC_TIMEZONE=Europe/Paris
NODE_ENV=production

# Indispensable en HTTP local, voir section "pièges"
N8N_SECURE_COOKIE=false

# Désactiver la télémétrie (évite des erreurs réseau parasites dans les logs)
N8N_DIAGNOSTICS_ENABLED=false
N8N_VERSION_NOTIFICATIONS_ENABLED=false

# Connexion Ollama sur tazmenworld
OLLAMA_BASE_URL=http://192.168.1.100:11434

Pour générer une clé d’encryption solide :

bash

openssl rand -hex 16

Docker Compose n8n

bash

nano /opt/autoserver/n8n/docker-compose.yml

yaml

services:
  n8n:
    image: n8nio/n8n:latest
    container_name: n8n
    restart: unless-stopped
    ports:
      - "5678:5678"
    env_file:
      - .env
    volumes:
      - ./data:/home/node/.n8n
      - /opt/autoserver/shared:/shared
    networks:
      - autoserver_net
    extra_hosts:
      - "tazmenworld:192.168.1.100"

networks:
  autoserver_net:
    name: autoserver_net
    driver: bridge

Le extra_hosts permet d’appeler http://tazmenworld:11434 depuis les workflows n8n au lieu d’une IP brute : plus lisible, et ça survit à un changement d’IP sans tout recâbler.

Fix permissions du volume (indispensable)

n8n tourne dans son container sous l’utilisateur node (UID 1000). Si le dossier data appartient à root, il ne peut pas écrire et crashe en boucle dès le démarrage sans message clair.

bash

sudo chown -R 1000:1000 /opt/autoserver/n8n/data

Autoriser Docker à sortir sur internet (UFW)

Par défaut, UFW bloque le forwarding des containers. n8n démarre correctement, mais tout appel HTTP externe échoue en silence : les workflows ne peuvent pas joindre d’API extérieure.

bash

sudo nano /etc/default/ufw
# Changer cette ligne :
# DEFAULT_FORWARD_POLICY="DROP"  →  DEFAULT_FORWARD_POLICY="ACCEPT"

sudo ufw reload

Lancer n8n

bash

cd /opt/autoserver/n8n
docker compose up -d
docker compose logs -f     # Ctrl+C pour quitter

Quand tu vois n8n ready on ::, port 5678, l’interface est accessible depuis tazmenworld via http://192.168.1.20:5678.

7. Hermes Agent : l’IA qui décide seule

C’est la brique qui fait passer le setup d’un serveur d’automatisation classique à un agent IA autonome. Hermes Agent est un projet open-source de Nous Research (licence MIT) : mémoire persistante entre les sessions, génération de ses propres skills, terminal sandboxé sous Docker, et gateway Telegram intégré. Là où n8n exécute des rails que tu as tracés, Hermes reçoit un objectif et se débrouille.

Installation

bash

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

Le script gère tout : Python 3.11, Node.js 22, ripgrep, ffmpeg. Il lance ensuite automatiquement le wizard de configuration.

Prérequis : internet doit être accessible depuis autoserver. Si curl -I https://github.com répond No route to host, tu as un problème de passerelle dans Netplan. Voir la section sur l’IP statique.

Configuration via le wizard

Les choix qui importent :

Configurer le bot Telegram

1. Ouvre Telegram, cherche @BotFather → /newbot
2. Donne un nom et un identifiant à ton bot
3. Récupère le token : 123456789:AAH-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
4. Cherche @userinfobot → note ton User ID numérique
5. Renseigne le token et l’User ID dans le wizard
6. Réponds Y pour le Home Channel (DM direct avec le bot)
7. Réponds Y pour installer comme service en arrière-plan

Activer le linger : le détail qui rend le setup vraiment autonome

Le gateway Telegram tourne en user service systemd. Sans cette configuration, il ne démarre pas au boot si aucune session utilisateur n’est ouverte. Résultat : après une coupure de courant à 3h du matin, ton agent reste silencieux jusqu’à ce que quelqu’un se connecte en SSH.

bash

sudo loginctl enable-linger <votre_user>

# Vérifier
loginctl show-user <votre_user> | grep Linger
# Attendu : Linger=yes

Une fois activé, le serveur peut redémarrer seul : le gateway Telegram revient en ligne sans intervention de ta part.

Vérification et commandes utiles

bash

# Statut du gateway
systemctl --user status hermes-gateway

# Test CLI interactif
source ~/.bashrc
hermes
> Bonjour, que peux-tu faire sur ce serveur ?

# Changer de modèle à chaud, sans redémarrage
hermes setup model

# Mettre à jour
hermes update

# Diagnostic complet
hermes doctor

8. Intégration avec la stack de tazmenworld

Depuis n8n ou Hermes sur autoserver, tous les services de tazmenworld sont accessibles directement par IP locale :

Ollama        → http://192.168.1.100:11434
Open WebUI    → http://192.168.1.100:3000
ComfyUI       → http://192.168.1.100:8188
SearXNG       → http://192.168.1.100:8080
n8n principal → http://192.168.1.100:5678

Pour centraliser ça proprement :

bash

nano /opt/autoserver/.env.global

env

TAZMENWORLD_IP=192.168.1.100
AUTOSERVER_IP=192.168.1.20

OLLAMA_URL=http://192.168.1.100:11434
OPENWEBUI_URL=http://192.168.1.100:3000
COMFYUI_URL=http://192.168.1.100:8188
SEARXNG_URL=http://192.168.1.100:8080
N8N_TAZMEN_URL=http://192.168.1.100:5678

OPENROUTER_BASE_URL=https://openrouter.ai/api/v1
OPENROUTER_API_KEY=sk-or-v1-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Et les deux instances n8n peuvent se parler : depuis autoserver, un nœud HTTP Request vers http://192.168.1.100:5678/webhook/<ton-webhook-id> déclenche un workflow sur tazmenworld. Les deux instances bossent ensemble.

9. Hermes en action : la démo Telegram

Là où n8n exécute des rails que tu as tracés, Hermes reçoit un objectif en langage naturel et se débrouille pour l’atteindre. Sa mémoire persistante lui permet de se souvenir des échanges précédents et d’ajuster son comportement au fil du temps.

Exemple concret, hier soir depuis le téléphone :

Moi :    Fais une veille sur les modèles open-weight sortis cette semaine.
         Résume les 5 plus intéressants en 3 lignes chacun et dépose
         le résumé dans /shared/veille.md

Hermes : Je lance les recherches. Je te préviens quand c'est déposé.

[quelques minutes plus tard]

Hermes : ✅ Résumé déposé dans /shared/veille.md, 5 modèles couverts.

Le fichier était là le matin. Je n’avais pas rouvert l’app entre les deux messages.

Ce qui rend ça possible, c’est le linger activé plus haut. L’agent tourne en fond, il n’a pas besoin que tu sois connecté en SSH, il n’attend pas que l’écran soit allumé. Il fait son boulot, prévient, et attend le prochain ordre.

10. Les trois pièges que j’ai rencontrés

Piège 1 : La passerelle réseau qu’on suppose à tort

En configurant l’IP statique, j’ai mis 192.168.1.1 comme passerelle sans vérifier. Résultat : ping local OK, accès internet mort. Impossible d’installer Hermes : curl -I https://github.com répondait No route to host.

La règle : ne jamais supposer l’IP de la passerelle. La vérifier en amont avec ip route | grep default sur une machine qui marche, reporter la vraie valeur dans Netplan. Vingt secondes de vérification qui évitent une heure de debug.

Piège 2 : Les permissions Docker sur trois fronts

Trois problèmes distincts, tous liés aux permissions, tous bloquants à leur façon.

Le groupe docker ne s’active pas immédiatement. Après usermod -aG docker, sur une install minimized newgrp n’est pas disponible. Le groupe ne prend effet qu’après déconnexion/reconnexion, sans message d’erreur explicite, juste un permission denied sur docker run.

n8n crashe en boucle au démarrage. Le container tourne sous l’UID 1000 (node). Si le dossier data appartient à root, n8n ne peut pas écrire et redémarre toutes les trente secondes. Fix : sudo chown -R 1000:1000 /opt/autoserver/n8n/data. C’est la première chose à faire avant de lancer le container.

n8n ne sort pas sur internet. UFW bloque par défaut le forwarding des containers. Les workflows se déclenchent, mais tout appel HTTP externe échoue en silence. Fix : passer DEFAULT_FORWARD_POLICY de "DROP" à "ACCEPT" dans /etc/default/ufw, puis sudo ufw reload.

Piège 3 : Le cookie n8n qui bloque la connexion

Tu ouvres l’interface, tu entres tes identifiants, ça ne passe pas. Aucun message d’erreur clair. n8n exige par défaut un cookie sécurisé qui ne fonctionne qu’en HTTPS. En HTTP sur le réseau local, c’est l’impasse.

Une ligne dans le .env règle l’affaire :

env

N8N_SECURE_COOKIE=false

Redémarre le container, l’interface s’ouvre. À ne configurer qu’en local sur un réseau de confiance. Dès qu’on expose vers l’extérieur, on passe par un reverse proxy HTTPS.

11. Ce qu’on peut faire avec

Le setup une fois en place, voilà ce qui tourne concrètement.

Veille techno automatique. Chaque matin à 7h, n8n déclenche une recherche via SearXNG sur tazmenworld, envoie les résultats à l’agent, et m’expédie un digest propre sur Telegram. J’ouvre le téléphone au réveil avec un résumé au lieu de vingt onglets à scroller.

Tâches longues en arrière-plan. Je donne un objectif à Hermes le soir (un comparatif de solutions, une analyse de logs, une rédaction), il découpe, cherche, rédige, et dépose le fichier dans /shared/. Au matin, c’est prêt. Le « pendant que tu dors » du titre, c’est littéralement ça.

Délégation au GPU. L’agent reçoit une demande de génération d’image, mais le N150 n’a pas de GPU sérieux. Pas de souci : il envoie le job à ComfyUI sur tazmenworld via http://192.168.1.100:8188, récupère le résultat, me le renvoie. Le control plan décide, le compute exécute.

Webhooks inter-machines. Un workflow sur autoserver peut déclencher un workflow sur le n8n de tazmenworld via un nœud HTTP Request vers http://192.168.1.100:5678/webhook/<id>. Les deux instances se parlent sans passer par internet.

Sauvegarde automatique à 3h du matin. Un cron sauvegarde les volumes Docker et garde les 7 dernières copies. Un alias as-status donne en deux secondes l’état des containers, la RAM, le disque, et la connectivité vers tazmenworld. Le serveur se surveille tout seul.

Conclusion

Il y a six mois, monter ce genre de setup demandait une connaissance pointue de Docker, des agents IA, et du self-hosting Linux. Aujourd’hui, l’installation tient en une soirée, et le résultat c’est un control plan IA permanent sur ton réseau local, piloté depuis ton téléphone, qui bosse sans te demander la permission.

Le Mac mini n’est pas mauvais. Il est juste disproportionné pour ce rôle. Et le vrai problème d’un VPS, ce n’est pas le prix : c’est qu’il ne voit pas ton réseau local. Un agent IA qui ne peut pas parler à tes services, c’est un outil à moitié aveugle.

Le mini PC à 130€ règle les deux problèmes : il est sur ton LAN, il est sobre, il ne s’arrête pas. Le calcul lourd, il a juste à savoir l’adresse de ta vraie machine pour le déléguer. C’est la même logique qu’on applique partout ici : ne pas gâcher la ressource, mettre le bon outil au bon endroit.

Matériel : MLLSE G2 Pro (Intel N150, 12 Go LPDDR5, 512 Go SSD). Stack : Ubuntu Server 26.04 LTS, Docker, n8n, Hermes Agent (Nous Research, licence MIT), DeepSeek V4 via OpenRouter. Les tokens, clés API et mots de passe dans les exemples sont des espaces réservés, génère les tiens avec les commandes indiquées.

Depuis quelque temps, je vois passer pas mal d’articles sur l’IA locale ou dans du cloud, et souvent la même idée revient : jouer sur le contexte. Charger une grosse fenêtre de contexte pour « fixer l’état » du modèle, cadrer son comportement et orienter le type de réponse qu’il va te sortir. L’intention est bonne donner au modèle un maximum de matière pour qu’il réponde juste.

Le problème, c’est que ça part souvent dans le mur. Plus le contexte augmente, plus on tombe dans ce qu’on appelle le Lost in the Middle : le modèle finit par perdre l’info au milieu de tout ce qu’on lui a donné. C’est ce que je veux t’expliquer ici, simplement et voir pourquoi, dans la plupart des cas, un RAG (Retrieval-Augmented Generation) fait le boulot bien mieux qu’un gros contexte.

1. Le réflexe « balance tout, il triera »

Coller 800 pages dans la fenêtre et poser sa question, c’est tentant parce que c’est rapide à mettre en place. Pas de base vectorielle, pas de chunking, pas d’embeddings à calculer.

Le souci, c’est qu’on mélange deux choses : la capacité (combien de tokens le modèle accepte en entrée) et l’attention utile (ce qu’il sait réellement exploiter là-dedans). Avoir 16 Go de VRAM ne veut pas dire qu’on les utilise bien souviens-toi de la « taxe d’affichage » Windows. Pour le contexte, c’est le même principe.

2. « Lost in the Middle » : l’info au milieu passe à la trappe

Le papier de référence sur le sujet, c’est Lost in the Middle: How Language Models Use Long Contexts (Liu et al., arXiv:2307.03172). Son constat : quand l’information pertinente est placée au milieu d’un long contexte, le modèle la retrouve mal.

La performance suit une courbe en U. Le modèle exploite bien ce qui est en début et en fin de contexte, et décroche au centre. Autrement dit, ta réponse peut être présente noir sur blanc dans les tokens que tu as fournis, et passer à côté juste parce qu’elle est tombée au mauvais endroit. Pour quelqu’un qui automatise des workflows, c’est un vrai problème : l’info est là, mais le résultat est faux.

3. Le « context rot » : plus c’est gros, plus ça hallucine

« Lost in the middle » est la partie la plus connue. Il existe un phénomène plus large, baptisé context rot : la qualité des réponses baisse à mesure que le contexte s’allonge, et ça commence avant que la fenêtre soit pleine.

Une étude de Chroma a testé 18 modèles récents. Tous se dégradent quand l’entrée s’allonge ; un modèle à 200K tokens peut déjà perdre en qualité dès 50K. Ce n’est donc pas la capacité qui compte, mais le rapport signal/bruit.

Deux mécanismes l’expliquent :

1. La dilution de l’attention. L’attention « soft » d’un Transformer a une capacité fixe. Plus tu ajoutes de tokens, plus elle s’étale sur du bruit, et moins chaque token utile en reçoit. C’est architectural aucun prompt ne le contourne.
2. Les hallucinations. Noyé dans la masse, le modèle comble les trous en inventant, avec le même aplomb que d’habitude.

L’analogie infra, c’est le spillover VRAM dont je parlais dans la série VRAM Tuning : tant que tout tient, ça file à ~1000 Go/s ; dès que ça déborde, on tombe à ~60 Go/s. Le gros contexte fait pareil avec l’attention du modèle, sauf que tu paies en plus ces tokens à chaque requête.

4. Ce que change le RAG

Le RAG inverse la logique. Au lieu de tout donner d’un coup, on récupère en amont les passages pertinents pour la question posée, et on ne sert que ça.

Le déroulé est simple :

1. La question arrive.
2. Un système de récupération (base vectorielle, recherche sémantique) sort les quelques morceaux utiles de ta base de connaissances.
3. On injecte seulement ces morceaux, propres et bien placés.
4. Le modèle répond sur une base nette.

Les trois problèmes tombent en même temps : pas de milieu géant où se perdre, une attention concentrée sur l’utile, et un signal/bruit qui limite les hallucinations.

C’est la même logique que le headless : on garde le moteur de calcul utile, on enlève le reste. On ne charge que ce qui sert.

5. Quand le gros contexte reste pertinent

Le RAG n’est pas la réponse à tout. Le gros contexte garde du sens dans des cas précis :

• Un document unique et court à analyser en entier (un contrat de 10 pages, un fichier de code) : monter un RAG là-dessus, c’est disproportionné.
• Un raisonnement transversal qui doit croiser des infos dispersées dans tout le document (« résume l’évolution du ton sur l’ensemble du rapport ») : un RAG qui ne récupère que des bouts isolés peut manquer la vue d’ensemble.
• Le prototypage : pour un test rapide, coller dans le contexte va plus vite. À condition de savoir que ça ne tiendra pas à l’échelle.

La vraie réponse dépend de la charge. Mais en production, sur du volume, le RAG l’emporte.

Tableau comparatif : RAG vs Gros Contexte

Conclusion

Le gros contexte, c’est la solution rapide, et elle a un coût : ton info se perd au milieu, l’attention se dilue, et tu paies plus pour des réponses moins fiables. « Lost in the middle » l’a montré dès 2023, le context rot l’a confirmé depuis.

Le RAG demande un peu de travail en amont base vectorielle, chunking, embeddings. Mais c’est la même logique que le reste du blog : ne pas gâcher la ressource, ne garder que l’utile. La capacité brute, c’est une chose ; savoir quoi mettre dedans, c’en est une autre.

On se retrouve pour la suite, où on montera un petit RAG local de bout en bout, avec une base vectorielle qui tourne sur ta machine et pas dans le cloud de quelqu’un d’autre. On va chunker, embedder et récupérer comme il faut.

Source principale : Liu et al., « Lost in the Middle: How Language Models Use Long Contexts », arXiv:2307.03172. Compléments sur le context rot et la dilution de l’attention : recherches Chroma (2025) et travaux associés sur la dégradation en long contexte.

Source: https://arxiv.org/abs/2307.03172v3

Je l’avoue : Perplexity est devenu, en l’espace de quelques mois, mon réflexe quotidien. C’est l’outil qui m’a fait oublier la liste interminable de liens bleus de Google pour me proposer des réponses synthétisées, sourcées et presque toujours pertinentes. Pourtant, plus je l’utilisais, plus une certaine gêne s’installait. À chaque requête, j’envoie un fragment de mes réflexions, de mes projets et de ma vie privée sur des serveurs dont je ne contrôle ni l’accès, ni la politique de conservation.

Aujourd’hui, je refuse de « louer » mon intelligence et ma vie privée à une boîte noire. J’ai décidé de reprendre les commandes en construisant ma propre alternative souveraine. L’objectif est simple : obtenir la même puissance de recherche et de synthèse, mais de manière totalement privée, sans abonnement, et en exploitant la puissance de calcul qui dort dans mon propre bureau.

La quête de la souveraineté numérique

Pourquoi s’embêter à configurer sa propre machine quand un service à 20 dollars par mois fait le travail ? La réponse tient en un mot : la maîtrise. En installant ma propre « Tazmen Station », je ne dépends plus d’une connexion internet pour réfléchir ou d’une mise à jour logicielle qui pourrait brider les capacités de mon modèle favori.

Ma configuration repose sur un matériel que j’ai choisi pour ses capacités de calcul : un processeur AMD Ryzen 9 9900X épaulé par une carte NVIDIA GeForce RTX 5070 Ti. C’est cette dernière qui est le véritable moteur de mon installation. Avec ses 13 Go de mémoire vidéo (VRAM) mobilisés, elle me permet de faire tourner des modèles sophistiqués comme Mistral-Nemo 12B avec une fluidité déconcertante.

Le projet que je vais vous détailler n’est pas une simple curiosité technique. C’est un système de production robuste. Pour y parvenir, j’ai assemblé une pile logicielle cohérente à l’aide de conteneurs Docker :

• SearXNG : Mon détective privé qui interroge le web à ma place, anonymement.
• Ollama : Le moteur qui héberge mes modèles de langage.
• Open WebUI : L’interface élégante qui lie le tout et me permet de dialoguer avec mes données.

[CODE : arborescence_projet.txt]

~/tazmen-ai-station/
├── docker-compose.yml     # L'orchestrateur de mes services
├── open-webui/            # Mes données d'interface et historiques
├── mcpo/                  # Le bridge pour les outils avancés
└── searxng/               # Ma configuration de recherche privée
    └── settings.yml       # Le réglage fin de mes moteurs de recherche

~/tazmen-ai-station/
├── docker-compose.yml     # L'orchestrateur de mes services
├── open-webui/            # Mes données d'interface et historiques
├── mcpo/                  # Le bridge pour les outils avancés
└── searxng/               # Ma configuration de recherche privée
    └── settings.yml       # Le réglage fin de mes moteurs de recherche

En tant qu’utilisateur passionné par la sécurité et l’IA, je ne cherche pas seulement à obtenir une réponse, mais à comprendre comment elle est générée. Dans ce guide, je vais vous montrer comment j’ai transformé une simple machine Ubuntu en un pôle d’intelligence capable de tenir tête aux solutions propriétaires les plus en vue. Nous n’allons pas seulement installer des logiciels ; nous allons bâtir un écosystème où chaque octet de donnée reste sous notre contrôle exclusif.

Préparez votre terminal. Nous allons voir comment transformer radicalement votre manière de chercher l’information, sans jamais compromettre votre confidentialité.

II. SearXNG : Le cerveau qui murmure à l’oreille du Web

Pour que mon installation puisse réellement rivaliser avec Perplexity, il me fallait un moyen d’interroger le web sans que les moteurs de recherche ne sachent qui je suis ni ce que je cherche. C’est ici qu’intervient SearXNG.

Je décris souvent SearXNG comme un moteur de recherche métacognitif. Contrairement à Google ou Bing, il ne possède pas son propre index de pages web. C’est un agrégateur : quand je lui pose une question, il va interroger simultanément des dizaines d’autres moteurs (Google, DuckDuckGo, Bing, Qwant) à ma place. Il récupère les résultats, les nettoie, supprime les doublons et me les présente de manière structurée.

L’anonymat par procuration

Le génie de SearXNG réside dans sa capacité à faire écran entre moi et les géants du web. Puisque c’est mon serveur local qui envoie les requêtes, les moteurs de recherche voient l’adresse IP de mon instance et non la mienne. En configurant correctement le fichier settings.yml, je m’assure qu’aucune donnée de profilage n’est transmise. C’est la base indispensable pour garantir que mes recherches sur la sécurité ou l’IA ne finissent pas dans une base de données publicitaire.

Pourquoi c’est la pièce maîtresse du puzzle ?

Un modèle comme Mistral, aussi brillant soit-il, possède une limite de connaissances fixée au moment de son entraînement. Pour lui donner une « mémoire vive » du web actuel, j’utilise le RAG (Retrieval-Augmented Generation).

SearXNG est le fournisseur officiel de ce contexte. Dans ma configuration, Open WebUI envoie la requête utilisateur à SearXNG, récupère les 5 meilleurs extraits (snippets) et les injecte directement dans le prompt de Mistral. C’est ce mécanisme qui permet d’obtenir des réponses sur le programme TV de demain ou sur une faille de sécurité découverte il y a trois heures.

[CODE : Extrait de configuration des moteurs dans settings.yml]

engines:
  - name: google
    engine: google
    shortcut: go
  - name: bing
    engine: bing
    shortcut: bi
  - name: brave
    engine: brave
    shortcut: br
    categories: [general, web]

engines:
  - name: google
    engine: google
    shortcut: go
  - name: bing
    engine: bing
    shortcut: bi
  - name: brave
    engine: brave
    shortcut: br
    categories: [general, web]

Dans mon fichier settings.yml, j’ai pris soin d’activer des moteurs comme Bing et Brave pour ne pas dépendre uniquement de Google, qui a parfois tendance à bloquer les requêtes automatisées. Cette diversité est ce qui rend le système robuste : si un moteur fait défaut, les autres prennent le relais pour fournir l’information à Mistral.

Sans cette brique, mon IA locale serait une encyclopédie figée dans le passé. Avec SearXNG, elle devient un analyste capable de lire le web en temps réel tout en respectant ma vie privée.

II. L’Infrastructure : Poser les fondations avec Docker

Pour bâtir ma propre station d’IA, j’ai choisi la voie de la propreté et de la modularité : Docker Compose. L’idée n’est pas de transformer mon installation Ubuntu en un tas de dépendances Python incohérentes, mais de compartimenter chaque outil dans son propre conteneur. Cela me permet de tout démarrer ou d’éteindre l’ensemble de ma machine de recherche en une seule commande.

Architecture du flux de données

Avant de regarder le code, il est crucial de comprendre comment mes outils discutent entre eux. Voici le chemin parcouru par une simple question comme « Quel est le dernier driver NVIDIA pour Linux ? » :

Le fichier de configuration : Analyse du docker-compose.yml

Voici le cœur de ma Tazmen Station. J’y ai regroupé tous les services nécessaires, de l’interface au moteur de recherche, en passant par le pont MCP pour les outils étendus.

[CODE : docker-compose.yml]

name: tazmen-ai-station

services:
  # Moteur d'IA : Ollama gère le chargement et l'exécution de Mistral
  ollama:
    image: ollama/ollama
    container_name: ollama
    volumes:
      - /media/DATA/LLM/models:/root/.ollama # Stockage externe pour mes modèles
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              device_ids: ['0'] # Cible ma RTX 5070 Ti
              capabilities: [gpu]
    restart: unless-stopped

  # Recherche Web : L'agrégateur privé
  searxng:
    container_name: searxng
    image: searxng/searxng:latest
    ports:
      - "8080:8080"
    volumes:
      - ./searxng:/etc/searxng
    restart: unless-stopped

  # Interface : Le portail qui orchestre le RAG
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    depends_on:
      - ollama
      - searxng
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
      - ENABLE_RAG_WEB_SEARCH=True
      - RAG_WEB_SEARCH_ENGINE=searxng
      - SEARXNG_QUERY_URL=http://searxng:8080/search?q=<query>
      - RAG_WEB_SEARCH_RESULT_COUNT=5 # Nombre de sources lues par l'IA
    restart: unless-stopped

name: tazmen-ai-station

services:
  # Moteur d'IA : Ollama gère le chargement et l'exécution de Mistral
  ollama:
    image: ollama/ollama
    container_name: ollama
    volumes:
      - /media/DATA/LLM/models:/root/.ollama # Stockage externe pour mes modèles
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              device_ids: ['0'] # Cible ma RTX 5070 Ti
              capabilities: [gpu]
    restart: unless-stopped

  # Recherche Web : L'agrégateur privé
  searxng:
    container_name: searxng
    image: searxng/searxng:latest
    ports:
      - "8080:8080"
    volumes:
      - ./searxng:/etc/searxng
    restart: unless-stopped

  # Interface : Le portail qui orchestre le RAG
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    depends_on:
      - ollama
      - searxng
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
      - ENABLE_RAG_WEB_SEARCH=True
      - RAG_WEB_SEARCH_ENGINE=searxng
      - SEARXNG_QUERY_URL=http://searxng:8080/search?q=<query>
      - RAG_WEB_SEARCH_RESULT_COUNT=5 # Nombre de sources lues par l'IA
    restart: unless-stopped

Le point critique : L’accès au GPU

Pour que ce système soit réactif, il n’y a pas de secret : il faut que Docker puisse voir la carte graphique. Dans mon cas, c’est une RTX 5070 Ti. Dans le service ollama, la section deploy.resources.reservations est indispensable. Sans elle, c’est mon Ryzen 9 9900X qui prendrait tout le travail sur ses épaules, et la génération de texte deviendrait péniblement lente.

J’ai également déporté le stockage des modèles sur un disque dur dédié via le volume /media/DATA/LLM/models. C’est une astuce de vieux routier de l’IA : les modèles comme Mistral pèsent plusieurs gigaoctets et je préfère ne pas encombrer ma partition système Ubuntu.

Une fois ce fichier prêt, un simple sudo docker compose up -d met en route toute la mécanique. L’interface devient accessible sur le port 3000 de ma machine, prête à recevoir mes premières questions.

IV. Configurer SearXNG : Le réglage de précision

Avoir un conteneur qui tourne, c’est bien. Avoir un moteur qui répond exactement à ce que Mistral attend, c’est mieux. Pour transformer SearXNG en une source de données fiable, je dois descendre dans les soutes et éditer le fichier settings.yml. C’est ici que je définis quels moteurs interroger et comment formater les réponses pour qu’elles soient digestes pour mon IA.

La clé de voûte : La sécurité et l’accès

La première chose que j’ai configurée, c’est la secret_key. C’est elle qui sécurise les communications de mon instance. Pour cet article, je l’ai remplacée par une valeur générique, mais dans mon installation réelle, j’utilise une chaîne de caractères complexe générée aléatoirement.

Un point technique m’a demandé un peu de recherche : la méthode de communication. Par défaut, SearXNG utilise souvent POST, mais pour assurer une compatibilité totale avec le module de recherche d’Open WebUI, j’ai forcé le passage en GET. C’est un détail qui peut éviter bien des maux de tête lors des premiers tests de connexion.

[CODE : Configuration serveur dans settings.yml]

server:
  port: 8080
  bind_address: "0.0.0.0"
  secret_key: "VOTRE_CLE_ALÉATOIRE_ICI" # À anonymiser impérativement
  method: "GET" # Indispensable pour Open WebUI

server:
  port: 8080
  bind_address: "0.0.0.0"
  secret_key: "VOTRE_CLE_ALÉATOIRE_ICI" # À anonymiser impérativement
  method: "GET" # Indispensable pour Open WebUI

Sortie JSON : Le langage de l’IA

Pour que Mistral puisse « lire » les résultats de recherche, SearXNG ne doit pas seulement lui envoyer une page HTML pleine de bannières et de menus. J’ai donc activé le format json dans la section formats. Cela permet à Open WebUI de recevoir une structure de données propre, contenant uniquement le titre, l’URL et l’extrait du site.

Le choix des moteurs : Sortir de la bulle Google

C’est sans doute la partie la plus gratifiante du réglage. Google est puissant, mais il déteste qu’on l’interroge via un script et il finit souvent par bloquer les requêtes avec des Captchas. Pour rendre ma station robuste, j’ai diversifié mes sources.

J’ai activé Bing, Qwant et Brave. En multipliant les moteurs, je m’assure que si l’un d’eux boude ma requête, les autres fourniront quand même du grain à moudre à mon modèle. J’ai également gardé DuckDuckGo actif pour sa pertinence globale.

[CODE : Activation des moteurs dans settings.yml]

engines:
  - name: google
    engine: google
    shortcut: go
    disabled: false # On le garde, mais on ne compte pas que sur lui
  - name: bing
    engine: bing
    shortcut: bi
    disabled: false
  - name: brave
    engine: brave
    shortcut: br
    disabled: false
  - name: qwant
    engine: qwant
    shortcut: qw
    disabled: false

engines:
  - name: google
    engine: google
    shortcut: go
    disabled: false # On le garde, mais on ne compte pas que sur lui
  - name: bing
    engine: bing
    shortcut: bi
    disabled: false
  - name: brave
    engine: brave
    shortcut: br
    disabled: false
  - name: qwant
    engine: qwant
    shortcut: qw
    disabled: false

Le filtrage et l’autocomplétion

Pour affiner l’expérience, j’ai réglé le safe_search sur 0 (pour avoir les résultats bruts) et activé l’autocomplétion via Google pour m’aider à formuler mes recherches plus rapidement. J’ai aussi veillé à ce que le temps de bannissement en cas d’échec (ban_time_on_fail) soit assez court pour que le système se rétablisse vite si un moteur me bloque temporairement.

Avec ces réglages, mon instance SearXNG n’est plus un simple site web de recherche ; elle devient une API privée et ultra-rapide qui alimente mon cerveau numérique en temps réel. Nous avons maintenant un moteur de recherche qui parle le même langage que notre IA.

V. Le Mariage : Lier Open WebUI, Ollama et Mistral

C’est ici que la magie opère. Jusqu’à présent, nous avons des moteurs puissants qui tournent chacun dans leur coin. Pour créer mon propre « Perplexity », je dois faire d’Open WebUI le chef d’orchestre de ma station. C’est lui qui va recevoir mes questions, décider s’il doit aller sur le web, et demander à Mistral de rédiger la synthèse finale.

L’interface comme centre de commande

Dans mon installation, Open WebUI n’est pas qu’une simple peau esthétique posée sur un modèle. C’est le point de ralliement. Pour que la liaison soit parfaite, j’ai configuré les variables d’environnement directement dans le docker-compose.yml.

Le réglage le plus sensible concerne le RAG (Retrieval-Augmented Generation). J’ai activé la recherche web en pointant vers l’URL interne de mon conteneur SearXNG. Comme ils partagent le même réseau Docker, ils communiquent à une vitesse fulgurante.

[CODE : Configuration RAG dans docker-compose.yml]

# Variables cruciales pour le mariage technique
- ENABLE_RAG_WEB_SEARCH=True
- RAG_WEB_SEARCH_ENGINE=searxng
- SEARXNG_QUERY_URL=http://searxng:8080/search?q=<query>
- RAG_WEB_SEARCH_RESULT_COUNT=5 # Ma recommandation pour ne rien rater
- RAG_WEB_SEARCH_CONCURRENT_REQUESTS=10

# Variables cruciales pour le mariage technique
- ENABLE_RAG_WEB_SEARCH=True
- RAG_WEB_SEARCH_ENGINE=searxng
- SEARXNG_QUERY_URL=http://searxng:8080/search?q=<query>
- RAG_WEB_SEARCH_RESULT_COUNT=5 # Ma recommandation pour ne rien rater
- RAG_WEB_SEARCH_CONCURRENT_REQUESTS=10

Le choix du modèle : Mistral-Nemo 12B

Pourquoi avoir choisi Mistral-Nemo 12B plutôt qu’un modèle plus imposant ? Pour une question d’équilibre technique. Sur ma carte RTX 5070 Ti, ce modèle occupe environ 13 Go de VRAM lorsqu’il est chargé en précision 8-bit (q8_0).

C’est le « sweet spot » : le modèle est assez intelligent pour comprendre des contextes de recherche complexes, tout en laissant assez de place en mémoire vidéo pour que la génération soit quasi instantanée. Si je prenais un modèle plus gros, je risquerais de saturer ma carte et de voir mes performances s’effondrer, forçant le système à s’appuyer sur le processeur.

La liaison SearXNG : Le test de vérité

Une fois les services lancés, je me rends dans les paramètres d’Open WebUI pour tester la connexion. Il y a un petit indicateur visuel qui confirme que le « Web Search » est actif.

Ma petite astuce perso : j’ai augmenté le nombre de résultats à 5. Par défaut, beaucoup d’outils s’arrêtent à 3. Mais pour des sujets pointus comme la sécurité informatique, avoir deux sources supplémentaires permet souvent de dénicher le détail technique qui fait la différence entre une réponse vague et une solution précise.

Le System Prompt : Donner une personnalité à l’IA

Pour que Mistral se comporte comme un analyste et non comme un simple perroquet, j’ai affiné son System Prompt dans l’interface. Je lui demande explicitement de :

1. Analyser systématiquement les sources fournies par SearXNG.
2. Citer chaque source avec un lien cliquable.
3. Préciser si les informations trouvées semblent contradictoires ou incomplètes.

C’est cette couche finale qui transforme une suite de conteneurs Docker en un véritable assistant de recherche. Je ne lui demande pas simplement de « savoir », je lui demande de « chercher » avec la rigueur d’un documentaliste.

VI. Optimisations avancées : Devenir un Power User

Une fois que la liaison entre mon interface et mes moteurs est établie, je ne m’arrête pas là. Pour que l’expérience dépasse réellement celle d’un outil grand public, je dois affiner la qualité des données que Mistral ingère. C’est la différence entre une réponse « correcte » et une analyse de niveau expert.

Filtrage des sources : Nettoyer le bruit

Le web est rempli de sites de basse qualité, de fermes à contenus ou de pages saturées de publicités qui polluent le contexte envoyé à mon IA. Dans mon fichier settings.yml, j’ai la possibilité d’affiner ce que SearXNG considère comme pertinent.

Je privilégie une approche chirurgicale : j’augmente le poids (weight) des sources que je juge fiables, comme les dépôts de documentation technique ou les sites académiques, tout en réduisant la visibilité des sites trop généralistes. C’est ce qui permet à mon assistant de ne pas se perdre dans des tutoriels obsolètes quand je lui demande une information sur une bibliothèque Python précise.

Prompt Engineering : Créer l’Assistant Chercheur

Le secret d’une bonne synthèse réside dans le System Prompt. Dans Open WebUI, je ne laisse pas le champ vide. J’ai conçu un modèle de prompt qui force Mistral à adopter une démarche scientifique. Je lui demande de comparer les sources entre elles : « Si deux sites se contredisent sur une version logicielle, mentionne-le explicitement et cherche une troisième source pour arbitrer. »

Cette instruction change tout. L’IA ne se contente plus de résumer ; elle vérifie la cohérence des informations qu’elle extrait du web via SearXNG.

[CODE : chercheur_expert_prompt.txt]

Tu es un analyste technique de haut niveau. 
Ta mission est de synthétiser les résultats de recherche fournis. 
1. Ignore les publicités et les contenus promotionnels.
2. Priorise les documentations officielles et les forums spécialisés.
3. Cite systématiquement tes sources entre crochets [Source X].
4. Si les informations sont datées de plus de deux ans, précise-le comme un risque potentiel.

Tu es un analyste technique de haut niveau. 
Ta mission est de synthétiser les résultats de recherche fournis. 
1. Ignore les publicités et les contenus promotionnels.
2. Priorise les documentations officielles et les forums spécialisés.
3. Cite systématiquement tes sources entre crochets [Source X].
4. Si les informations sont datées de plus de deux ans, précise-le comme un risque potentiel.

Gestion de la performance et de la VRAM

Travailler en local signifie gérer ses ressources. Avec ma RTX 5070 Ti, je surveille constamment l’occupation de la mémoire vidéo via l’outil nvtop. Pour éviter que le système ne ralentisse lors de recherches complexes qui génèrent beaucoup de texte, j’ai ajusté la taille du contexte (Context Window) à environ 8 000 tokens.

C’est largement suffisant pour contenir les 5 extraits de recherche de SearXNG et ma propre conversation, tout en gardant une vitesse de génération fulgurante sur mes 13 Go de VRAM disponibles. Si je montais trop haut, la carte pourrait saturer, entrainant une chute drastique des performances au profit du processeur.

Le réglage fin des concurrent requests

Dans mon docker-compose.yml, j’ai fixé RAG_WEB_SEARCH_CONCURRENT_REQUESTS à 10. Pourquoi ? Parce que SearXNG est capable d’interroger plusieurs moteurs en même temps. En autorisant 10 requêtes simultanées, je m’assure que la phase de recherche ne prend que quelques millisecondes. Mon IA reçoit ses données presque instantanément, ce qui rend l’interaction aussi fluide, voire plus, qu’avec un service en ligne.

Toutes ces petites touches font que ma machine ne se contente pas d’imiter un service existant ; elle s’adapte précisément à mes besoins et à mon matériel.

VII. Démonstration de cas d’usage réels

Installer toute cette artillerie est une chose, mais la vraie question demeure : est-ce que ça tient la route face à Perplexity au quotidien ? Pour le savoir, j’ai soumis ma station à plusieurs tests intensifs. Voici comment se comporte ce duo Mistral-SearXNG sur des terrains où l’on attend normalement des services payants au tournant.

Cas d’usage n°1 : La veille en cybersécurité

En tant que passionné de sécurité, je cherche souvent des détails sur des failles fraîchement découvertes. J’ai posé la question suivante : « Quelles sont les dernières vulnérabilités signalées sur Ollama ou les frameworks d’IA locale cette semaine ? »

Grâce à SearXNG, mon système n’est pas allé interroger une base de données statique. Il a fouillé GitHub, des blogs spécialisés et des sites de CVE. Mistral-Nemo a ensuite synthétisé les résultats en isolant les vecteurs d’attaque potentiels.

Le verdict : La réponse est arrivée en moins de 10 secondes. Là où Perplexity m’aurait parfois noyé sous des sources généralistes, ma configuration locale a privilégié les dépôts techniques parce que j’ai configuré mes moteurs pour cela.

Cas d’usage n°2 : La vie pratique (Le test du programme TV)

C’est le test ultime pour vérifier la fraîcheur des données : « Il y a quoi demain soir sur TF1 ? » Pour une IA classique, c’est une question piège. Pour mon installation, c’est une routine de recherche web.

Open WebUI a lancé SearXNG, qui a récupéré les grilles horaires de plusieurs sites de programmes TV. Mistral a lu ces extraits et m’a présenté une réponse claire, avec les horaires précis.

Le verdict : La précision est identique à celle d’un moteur commercial. La seule différence ? Personne d’autre que moi ne sait que j’ai prévu de regarder un documentaire ou un film demain soir. Ma vie privée est préservée pour une information pourtant banale.

Cas d’usage n°3 : Développement et Hardware

J’ai testé une requête technique sur mon propre matériel : « Quelles sont les optimisations recommandées pour faire tourner Mistral-Nemo sur une RTX 5070 Ti sous Ubuntu ? »

Le système a croisé des benchmarks récents et des discussions sur des forums spécialisés. Il m’a suggéré d’utiliser des versions quantifiées (q8_0) pour occuper environ 13 Go de VRAM et conserver une réactivité maximale. C’est exactement ce que j’ai constaté en surveillant mon outil nvtop.

Bilan de performance

Après plusieurs jours d’utilisation intensive, voici mon constat :

• Rapidité : Sur ma machine (Ryzen 9 9900X et RTX 5070 Ti), la génération est quasi instantanée après la phase de recherche web qui prend environ 2 secondes.
• Pertinence : En passant à 5 sources de recherche au lieu de 3, j’ai éliminé la majorité des réponses incomplètes que j’avais au début de mes tests.
• Confidentialité : C’est le point de rupture total avec les solutions cloud. Je peux poser des questions sur des codes sources privés ou des documents sensibles sans aucune crainte.

[CODE : exemple_reponse_sourcee.json]

{
  "question": "Dernière version stable de SearXNG ?",
  "reponse": "La version actuelle est disponible sur GitHub...",
  "sources": [
    {"titre": "SearXNG Releases", "url": "https://github.com/searxng/searxng/releases"},
    {"titre": "Documentation officielle", "url": "https://docs.searxng.org/"}
  ]
}

{
  "question": "Dernière version stable de SearXNG ?",
  "reponse": "La version actuelle est disponible sur GitHub...",
  "sources": [
    {"titre": "SearXNG Releases", "url": "https://github.com/searxng/searxng/releases"},
    {"titre": "Documentation officielle", "url": "https://docs.searxng.org/"}
  ]
}

En résumé, remplacer Perplexity n’est pas seulement une déclaration d’indépendance ; c’est un gain réel en précision et en tranquillité d’esprit pour quiconque prend ses données au sérieux.

VIII. Conclusion : Le bilan de la liberté

Après avoir parcouru ce long chemin de configuration, de réglages de fichiers YAML et de tests de requêtes, je me pose souvent la question : est-ce que le jeu en vaut la chandelle ? La réponse, pour moi, est un grand « oui ».

Remplacer Perplexity par une solution locale n’est pas seulement un défi technique gratifiant. C’est un acte de reprise de contrôle. En voyant ma RTX 5070 Ti grimper à 79% de charge pour synthétiser en quelques secondes une réponse complexe, je ressens une satisfaction que seul le « fait maison » peut procurer.

Performance vs Praticité : L’heure du bilan

Si l’on regarde froidement les chiffres, voici ce que je retiens de ma Tazmen Station face aux solutions propriétaires :

• Vie privée : C’est la victoire par K.O. Aucune de mes données ne quitte mon réseau local. SearXNG agit comme un bouclier impénétrable entre mes intentions de recherche et les régies publicitaires.
• Vitesse : Grâce au couple Ryzen 9 9900X et GPU NVIDIA, la latence est extrêmement faible. Une fois la phase de recherche web terminée, Mistral-Nemo génère du texte à une vitesse qui n’a rien à envier aux versions payantes de GPT ou Claude.
• Coût : Certes, l’investissement matériel est là. Mais à 20 € par mois d’abonnement économisés, ma station est rentabilisée sur la durée, sans compter qu’elle me sert aussi pour d’autres tâches lourdes.
• Précision : En forçant le système à lire 5 sources via SearXNG au lieu des 3 habituelles, j’ai obtenu une profondeur d’analyse qui m’a bluffé, notamment sur les sujets de sécurité.

Et quoi après ?

Ce guide n’est que le début. Avec cette infrastructure Docker solide, je peux maintenant explorer de nouveaux horizons. L’étape suivante pour moi sera d’intégrer des agents autonomes capables d’exécuter des tâches encore plus complexes à partir de mes recherches web.

Bâtir sa propre IA, c’est accepter de passer un peu de temps dans son terminal pour gagner une liberté qui n’a pas de prix. J’espère que ce guide vous aura donné les clés pour, vous aussi, transformer votre machine Ubuntu en une forteresse d’intelligence privée.

[CODE : commande_finale_restart.sh]

# Pour relancer l'ensemble après une mise à jour des modèles
sudo docker compose down && sudo docker compose up -d --remove-orphans

# Pour relancer l'ensemble après une mise à jour des modèles
sudo docker compose down && sudo docker compose up -d --remove-orphans

Merci de m’avoir suivi dans cette exploration technique. Si vous avez des questions sur la configuration de votre GPU ou sur les subtilités de SearXNG, n’hésitez pas à partager vos retours. La route vers l’IA locale est vaste, et nous ne faisons que commencer à en dessiner les contours.

A bientôt Louis 🐇 🤜 🤛 🐰

Si tu suis mes articles sur l’optimisation hardware et le scripting headless, tu sais que je ne suis pas du genre à m’emballer pour les communiqués de presse lisses ou les promesses marketing. Mais aujourd’hui, on va lever le nez du terminal pour regarder un dossier qui va sérieusement bousculer nos habitudes.

Le baromètre mondial de l’IA (le fameux AI Index Report 2026 de Stanford) vient de sortir, et c’est une sacrée douche froide pour ceux qui pensaient que l’hégémonie de la Silicon Valley était gravée dans le marbre. On ne parle pas de spéculation ou de propagande, mais de faits documentés par l’élite universitaire américaine : la Chine n’est plus dans le rétroviseur, elle est en train de déboîter sur la file de gauche.

Dans cet article, on va plonger dans le dur. On va voir comment les ingénieurs chinois ont réussi à transformer les sanctions sur les puces en un moteur pour leur propre souveraineté technique. On va parler de modèles massifs entraînés sans une seule puce Nvidia, de la fin de la dépendance à TSMC et de ce que cela signifie concrètement pour nos futures infras. Pas de langue de bois, juste de la technique, des chiffres et de la géopolitique appliquée. Attache ta ceinture, on va parler puissance brute et silicium.

L’évaporation de l’écart technique : les chiffres qui fâchent

Pendant que les médias occidentaux se focalisaient sur les chatbots capables de générer des poèmes, les labos chinois ont bossé sur la performance brute. Le rapport de Stanford met en lumière une donnée qui devrait donner des sueurs froides à la tech américaine : l’écart de performance entre les meilleurs modèles américains et les fleurons chinois comme DeepSeek ou Qwen est désormais inférieur à 3 %.

En mars 2026, sur les benchmarks les plus exigeants ceux qui testent le codage informatique complexe, les mathématiques de niveau compétition et les raisonnements scientifiques de niveau doctorat la supériorité américaine est devenue un concept purement théorique. Pour nous, qui utilisons ces outils pour automatiser des workflows ou scripter des tâches complexes, la différence est devenue imperceptible en production.

Le cas DeepSeek V4 : 1000 milliards de paramètres sans Nvidia

C’est ici qu’on entre dans le vif du sujet hardware. Les USA ont misé gros sur l’embargo des puces H100 et H200 de Nvidia pour freiner la Chine. Ils ont pensé qu’en coupant l’accès au silicium de pointe produit par TSMC, ils bloqueraient net la capacité de calcul chinoise.

C’est exactement l’inverse qui s’est produit. Le rapport mentionne l’émergence de DeepSeek V4, un modèle massif de 1 000 milliards de paramètres. La véritable claque technique réside dans le fait que ce modèle a été entraîné à 100 % sur des clusters de puces Huawei Ascend.

Habituellement, l’entraînement de modèles de cette taille nécessite une interconnexion ultra-rapide entre les puces, un domaine où Nvidia régnait sans partage avec son protocole NVLink. Huawei a réussi à développer sa propre stack complète pour contourner ce goulot d’étranglement :

1. Les puces Ascend qui, bien que moins performantes par unité que les dernières Blackwell de Nvidia, sont optimisées pour travailler en clusters géants de manière très cohérente.
2. Un framework propriétaire, MindSpore, qui remplace PyTorch et qui est taillé sur mesure pour exploiter le silicium domestique.
3. Une indépendance totale vis-à-vis de TSMC pour la production, la Chine ayant réussi à optimiser ses procédés de lithographie pour sortir des volumes suffisants de puces de calcul performantes.

On est passé d’une dépendance critique à une autonomie forcée. La Chine a appris à faire de l’IA avec son propre hardware, là où le reste du monde est encore suspendu aux carnets de commandes de Nvidia.

L’architecture MoE et l’optimisation au couteau

Si tu as lu mes posts sur le VRAM tuning, tu sais que la mémoire est le nerf de la guerre. Les ingénieurs chinois n’ont pas cherché à copier bêtement l’approche de puissance brute adoptée par OpenAI. Ils ont poussé l’architecture Mixture of Experts (MoE) dans ses derniers retranchements.

L’idée est simple : au lieu d’activer les 1000 milliards de paramètres à chaque requête, le modèle ne sollicite que les experts concernés par le sujet. Cela permet de réduire la consommation électrique et, surtout, de faire tourner des modèles très puissants sur des configurations hardware qui auraient été jugées insuffisantes il y a deux ans. En clair, ils font plus avec moins de VRAM, ce qui est un avantage stratégique énorme quand on a un accès limité au hardware de pointe.

La fuite des cerveaux à l’envers : l’impact politique

Le rapport de Stanford souligne un point critique sur le capital humain, et c’est peut-être là que le bât blesse le plus pour Washington. Historiquement, les USA étaient un aspirateur à talents sans équivalent. Un étudiant chinois brillant finissait ses études à Stanford et restait bosser dans la Silicon Valley pour créer de la valeur aux États-Unis.

Ce cycle vertueux pour l’économie américaine est en train de se briser. Le rapport note une chute brutale de 89 % des arrivées de chercheurs étrangers en IA aux USA depuis 2017. Cette date n’est pas un hasard : elle marque le début du durcissement drastique de la politique migratoire sous l’administration Trump.

L’image projetée à l’international, marquée par une administration perçue comme hostile aux étrangers et les actions d’une agence comme l’ICE (Immigration and Customs Enforcement) aux méthodes de plus en plus paramilitaires, a créé un climat de méfiance profonde. Pour un chercheur de haut niveau, le rêve américain a été remplacé par l’incertitude des visas et un sentiment d’insécurité.

Aujourd’hui, la majorité des cerveaux formés en Chine, ou même ceux formés aux États-Unis, choisissent de retourner au pays pour monter des structures ou rejoindre des géants comme Baidu, Tencent ou Huawei. Ce n’est plus seulement une guerre de puces, c’est une guerre de neurones, et les USA sont en train de perdre leur force d’attraction principale. La Chine produit désormais plus de papiers de recherche de haut niveau que n’importe quelle autre nation, et la force de leur système est que ces recherches sont immédiatement injectées dans leur tissu industriel.

La frontière en dents de scie et le pragmatisme industriel

Un concept fondamental du rapport est la Sawtooth Frontier. Cela décrit le fait que l’IA ne progresse pas de manière uniforme. Un modèle peut être un génie en programmation mais être incapable de comprendre un concept social simple.

Alors que les Américains cherchent à créer une Intelligence Artificielle Générale capable de tout faire, les Chinois se concentrent sur une IA de production. Leurs investissements massifs sont fléchés vers des domaines concrets :

1. L’optimisation des réseaux électriques et des flux logistiques.
2. La conception assistée de nouveaux matériaux et semi-conducteurs.
3. L’automatisation de la cybersécurité.

C’est une approche purement utilitaire. Ils ne cherchent pas à ce que l’IA soit humaine, ils cherchent à ce qu’elle soit efficace. C’est du headless appliqué à l’échelle d’un pays : on enlève l’interface polie pour ne garder que le moteur de calcul.

Le coût caché : l’alerte environnementale

Même si la Chine gagne la course, le rapport de Stanford tire une sonnette d’alarme sur le coût énergétique et environnemental. On parle souvent de la consommation des datacenters, mais les chiffres ici sont vertigineux. L’entraînement d’un modèle comme DeepSeek V4 consomme plus d’eau pour le refroidissement que ce que consomme une ville moyenne en un an.

La Chine, avec ses besoins énergétiques monstrueux, semble prête à payer ce prix pour la domination technologique. C’est un facteur que les régulations européennes ou américaines pourraient limiter chez nous, créant un nouveau déséquilibre compétitif majeur.

Conclusion : On fait quoi maintenant ?

On ne va pas se mentir : le centre de gravité a basculé. Ce rapport de Stanford n’est pas une simple étude de plus, c’est l’aveu de la fin d’un monopole. Pour nous, les techniciens, cela signifie que notre boîte à outils va changer.

Il va falloir apprendre à bosser avec ces modèles venus d’ailleurs, comprendre leurs frameworks et arrêter de penser que si ce n’est pas développé en Californie, c’est forcément moins bon. La réalité du terrain, celle des benchmarks et des clusters de serveurs, raconte une tout autre histoire.

On est à l’aube d’une ère où la puissance de calcul ne dépendra plus d’une seule marque de cartes graphiques ou d’une seule fonderie à Taïwan. C’est le retour de la diversité technique, et pour ceux qui aiment l’optimisation et la performance, c’est un nouveau terrain de jeu passionnant.

On se retrouve pour le prochain article où on verra comment installer et quantifier localement ces nouveaux modèles pour voir ce qu’ils ont vraiment dans le ventre.

Analyse comparative (Données Stanford AI Index 2026)

Source: https://hai.stanford.edu/ai-index

Aujourd’hui, on va parler d’un sujet qui me tient à cœur : comment faire bosser une IA à sa place quand on a une tablette graphique, des idées, mais une flemme monumentale de tracer des flèches droites. On va transformer une simple interface de dessin en un outil agentique piloté par Ollama. Accrochez-vous, ça va être dense.

L’Intro : La Tablette, la Formation et la Grosse Flemme

Quand je donne des formations, j’adore utiliser Excalidraw. C’est souple, c’est propre, et avec ma tablette, j’ai l’impression d’être sur un vrai tableau blanc. C’est parfait pour gribouiller des concepts en direct. Mais on va être honnête deux minutes : parfois, je suis en manque total d’inspiration pour mes schémas.

Dessiner une architecture microservices avec 15 nœuds, trois bases de données et un bus de messages alors que j’ai déjà parlé pendant trois heures ? J’ai juste une grosse flemme. L’idée, c’était simple : je veux une IA, en local (parce que ma VRAM, je l’ai payée, alors je l’utilise), qui puisse « tenir le pinceau » pendant que j’explique le concept aux élèves. On ne parle pas juste de générer une image statique, mais d’avoir un vrai Agent qui manipule le canvas en temps réel sous mes yeux.

Étape 1 : Monter le Tableau Blanc (Installation d’Excalidraw)

Avant de parler IA, il nous faut le support. La façon la plus simple et la plus propre de faire tourner Excalidraw chez soi sans dépendre du cloud, c’est Docker.

Tu peux le lancer en une seule ligne de commande pour tester: docker run --rm -dit --name excalidraw -p 8000:80 excalidraw/excalidraw:latest.

Mais comme on est sur une AI Station sérieuse, on va l’intégrer proprement dans notre docker-compose.yml. Cela nous permet de gérer les ports et les redémarrages automatiques.

# --- TABLEAU BLANC EXCALIDRAW ---
  excalidraw:
    image: excalidraw/excalidraw:latest
    container_name: excalidraw
    ports:
      - "8000:80" # Accessible sur http://localhost:8000
    restart: unless-stopped

# --- TABLEAU BLANC EXCALIDRAW ---
  excalidraw:
    image: excalidraw/excalidraw:latest
    container_name: excalidraw
    ports:
      - "8000:80" # Accessible sur http://localhost:8000
    restart: unless-stopped

Une fois que c’est lancé, tu as ton Excalidraw perso sur le port 8000. C’est rapide, c’est léger, et ça ne demande aucune configuration complexe pour commencer à dessiner avec sa tablette ou sur son ordinateur et c’est gratuit :D.

Étape 2 : L’Intelligence de Dessin (Serveur MCP)

Maintenant, on veut que l’IA puisse interagir avec ce canvas. Pour ça, on utilise le protocole MCP (Model Context Protocol). J’ai choisi le projet mcp-excalidraw-local qui propose environ 32 outils pour manipuler le tableau blanc (créer des formes, du texte, des flèches, etc.).

Pour l’intégrer à l’infra, on ajoute un service dédié qui va compiler les sources GitHub.

Le Dockerfile du serveur MCP

On crée un fichier Dockerfile.mcp-excalidraw :

FROM node:20-slim
RUN apt-get update && apt-get install -y git python3 make g++ && rm -rf /var/lib/apt/lists/*
RUN npm install -g pnpm
WORKDIR /app
RUN git clone https://github.com/sanjibdevnathlabs/mcp-excalidraw-local.git .
RUN pnpm install && pnpm build
# Le serveur attend des commandes stdio par défaut
CMD ["node", "dist/index.js"]

FROM node:20-slim
RUN apt-get update && apt-get install -y git python3 make g++ && rm -rf /var/lib/apt/lists/*
RUN npm install -g pnpm
WORKDIR /app
RUN git clone https://github.com/sanjibdevnathlabs/mcp-excalidraw-local.git .
RUN pnpm install && pnpm build
# Le serveur attend des commandes stdio par défaut
CMD ["node", "dist/index.js"]

Le Bridge pour Open-WebUI

Le souci, c’est que mon interface préférée, Open-WebUI, ne parle pas nativement le « stdio » (le langage des terminaux) pour le MCP. Elle préfère le HTTP. On va donc utiliser un bridge appelé mcpo qui va faire la traduction.

On ajoute ces deux services à notre docker-compose.yml:

mcp-excalidraw:
    build:
      context: .
      dockerfile: Dockerfile.mcp-excalidraw
    container_name: mcp-excalidraw
    ports:
      - "3001:3000"
    environment:
      - CANVAS_PORT=3000
      - EXCALIDRAW_DB_PATH=/app/data/excalidraw.db
    volumes:
      - /chemin/vers/votre/data:/app/data
    restart: unless-stopped

  mcpo:
    image: ghcr.io/open-webui/mcpo:main
    container_name: mcpo
    ports:
      - "8081:8080"
    volumes:
      - ./mcpo/config.json:/app/config.json:ro
    depends_on:
      - mcp-excalidraw
    restart: unless-stopped

mcp-excalidraw:
    build:
      context: .
      dockerfile: Dockerfile.mcp-excalidraw
    container_name: mcp-excalidraw
    ports:
      - "3001:3000"
    environment:
      - CANVAS_PORT=3000
      - EXCALIDRAW_DB_PATH=/app/data/excalidraw.db
    volumes:
      - /chemin/vers/votre/data:/app/data
    restart: unless-stopped

  mcpo:
    image: ghcr.io/open-webui/mcpo:main
    container_name: mcpo
    ports:
      - "8081:8080"
    volumes:
      - ./mcpo/config.json:/app/config.json:ro
    depends_on:
      - mcp-excalidraw
    restart: unless-stopped

Il ne faut pas oublier de créer le fichier ./mcpo/config.json pour dire à mcpo d’aller chercher le serveur Excalidraw:

{
  "mcpServers": {
    "excalidraw": {
      "type": "sse",
      "url": "http://mcp-excalidraw:3000/sse"
    }
  }
}

{
  "mcpServers": {
    "excalidraw": {
      "type": "sse",
      "url": "http://mcp-excalidraw:3000/sse"
    }
  }
}

Étape 3 : Le Tool Python « Agentic » (La Touche Finale)

Après pas mal de tests, j’ai réalisé que pour avoir un contrôle total, rien ne vaut un Tool Python personnalisé dans Open-WebUI. Cela permet d’éviter les erreurs de protocole et de formater les requêtes exactement comme l’API du serveur MCP l’attend.

Pourquoi ce script ?

J’ai découvert deux bugs critiques en analysant les logs:

1. L’API attend un objet pour le texte : {"label": {"text": "votre texte"}} et non une simple string.
2. Pour le Mermaid, le champ doit s’appeler mermaidDiagram.

Voici le script excalidraw_tool.py corrigé que j’utilise:

"""
title: Excalidraw Canvas Tool
author: tazmen
description: Contrôle le canvas Excalidraw local
version: 1.2.0
"""
import json
import requests
import time

EXCALIDRAW_API = "http://mcp-excalidraw:3000"

class Tools:
    def add_element(self, type: str, label: str = "", x: int = 100, y: int = 100, width: int = 200, height: int = 100):
        """Ajoute un élément sur le canvas."""
        try:
            payload = {
                "type": type,
                "label": {"text": label}, # Formatage correct pour l'API
                "x": x, "y": y,
                "width": width, "height": height
            }
            r = requests.post(f"{EXCALIDRAW_API}/api/elements", json=payload, timeout=5)
            return "Élément ajouté."
        except Exception as e:
            return f"Erreur: {e}"

    def create_diagram_from_mermaid(self, mermaid_code: str) -> str:
        """Convertit un code Mermaid en schéma Excalidraw."""
        try:
            r = requests.post(
                f"{EXCALIDRAW_API}/api/elements/from-mermaid",
                json={"mermaidDiagram": mermaid_code}, # Champ corrigé
                timeout=10
            )
            time.sleep(2) # On laisse le temps au rendu
            return "Schéma généré."
        except Exception as e:
            return f"Erreur: {e}"

    def clear_canvas(self):
        """Vide le tableau blanc."""
        requests.delete(f"{EXCALIDRAW_API}/api/elements/clear", timeout=5)
        return "Canvas nettoyé."

"""
title: Excalidraw Canvas Tool
author: tazmen
description: Contrôle le canvas Excalidraw local
version: 1.2.0
"""
import json
import requests
import time

EXCALIDRAW_API = "http://mcp-excalidraw:3000"

class Tools:
    def add_element(self, type: str, label: str = "", x: int = 100, y: int = 100, width: int = 200, height: int = 100):
        """Ajoute un élément sur le canvas."""
        try:
            payload = {
                "type": type,
                "label": {"text": label}, # Formatage correct pour l'API
                "x": x, "y": y,
                "width": width, "height": height
            }
            r = requests.post(f"{EXCALIDRAW_API}/api/elements", json=payload, timeout=5)
            return "Élément ajouté."
        except Exception as e:
            return f"Erreur: {e}"

    def create_diagram_from_mermaid(self, mermaid_code: str) -> str:
        """Convertit un code Mermaid en schéma Excalidraw."""
        try:
            r = requests.post(
                f"{EXCALIDRAW_API}/api/elements/from-mermaid",
                json={"mermaidDiagram": mermaid_code}, # Champ corrigé
                timeout=10
            )
            time.sleep(2) # On laisse le temps au rendu
            return "Schéma généré."
        except Exception as e:
            return f"Erreur: {e}"

    def clear_canvas(self):
        """Vide le tableau blanc."""
        requests.delete(f"{EXCALIDRAW_API}/api/elements/clear", timeout=5)
        return "Canvas nettoyé."

Les Galères et le Troubleshooting (Le mode survie)

Si vous faites ça, vous allez forcément tomber sur des erreurs de permissions. C’est mathématique.

• Erreur SQLITE_CANTOPEN : Le conteneur mcp-excalidraw essaie d’écrire la base de données sur votre disque mais il n’a pas les droits. Comme le process Node.js tourne souvent avec l’UID 1001 , il faut lui donner la propriété du dossier: sudo chown -R 1001:1001 ~/tazmen-ai-station/mcp-excalidraw/data.
• L’IA qui refuse de dessiner : Si votre modèle (Mistral ou Qwen) vous dit qu’il « ne peut pas dessiner ici », c’est qu’il n’est pas assez directif. Il faut lui forcer la main dans le System Prompt.

Mon System Prompt de « Grosse Flemme »

Ajoutez ceci à votre modèle personnalisé dans Open-WebUI:

« Tu es un assistant spécialisé dans la création de schémas sur Excalidraw. RÈGLE ABSOLUE : Quand on te demande un schéma, utilise TOUJOURS create_diagram_from_mermaid. Ne montre jamais le code, dessine direct. ».

La Démo Finale : Ça en jette !

Une fois que tout est vert, le résultat est magique. Pendant ma formation, je dis simplement : « Fais-moi un schéma d’une architecture active directory avec les rôles FSMO ». L’IA réfléchit, génère le Mermaid, et paf, les boîtes apparaissent sur mon Excalidraw sur localhost:8000 ou 3001.

Conclusion

Voilà comment on passe d’une tablette graphique sympa à une station de travail agentique complète. C’est du boulot à installer, mais quel plaisir de voir ses idées prendre forme sans avoir à se battre avec l’alignement des rectangles !

Si vous avez des questions sur les variables d’environnement ou les quantisations de modèles (j’utilise Qwen 3.5 9B pour que ça rentre dans mes 16 Go de VRAM ), posez-les en commentaire.

À plus pour de nouvelles aventures en local !

Si vous avez suivi les deux premiers articles, vous avez maintenant une bête de course sous Linux qui fait tourner Mistral Nemo au doigt et à l’œil grâce à Ollama. On a optimisé la VRAM, on a une interface WebUI qui n’a rien à envier à ChatGPT, mais il manque encore un petit quelque chose…

L’accessibilité.

Ouvrir un navigateur, c’est bien. Mais pouvoir interpeller son propre modèle d’IA directement depuis son outil de travail quotidien, là où se passent les discussions, c’est un tout autre niveau. Aujourd’hui, on va voir comment transformer cette infrastructure locale en un assistant Slack ultra-réactif, totalement privé et surtout, sécurisé.

Le défi de la sécurité : Pourquoi le « Socket Mode » ?

Quand on parle de connecter un serveur local à un service cloud comme Slack, le premier réflexe est souvent de se dire : « Je vais devoir ouvrir un port sur ma box, gérer un DNS dynamique, un certificat SSL… ».

Oubliez tout ça. Ouvrir des ports, c’est créer des trous dans votre muraille de Chine personnelle. Pour cet article, on va utiliser le Socket Mode. C’est une technologie qui permet à notre petit bot Python, bien au chaud derrière votre pare-feu local, d’ouvrir lui-même une connexion vers Slack pour récupérer les messages. C’est le bot qui « écoute » Slack via une connexion sortante, et non Slack qui « appelle » votre serveur.

Résultat : Sécurité maximale. Votre IP reste cachée, aucun port n’est ouvert, et votre IA reste souveraine.

Étape 1 : Préparer le terrain sur Slack

Avant de toucher au code, il faut donner une existence légale à notre assistant sur l’interface développeur de Slack.

1. Rendez-vous sur le portail API de Slack et créez une application « From Scratch ».
2. Activer le Socket Mode : C’est l’option la plus importante dans le menu de gauche. En l’activant, Slack vous donnera un premier token (commençant par xapp-). C’est la clé de votre tunnel sécurisé.
3. Permissions (Scopes) : Votre bot a besoin de voir les mentions (app_mentions:read) et de pouvoir répondre (chat:write). Si vous voulez lui parler en privé, ajoutez aussi les permissions liées aux messages directs (im:history).

Étape 2 : L’architecture Docker (La modularité avant tout)

Dans l’article précédent, on a vu que Docker était notre meilleur allié pour isoler nos services. Pour ajouter le bot Slack, on ne va pas polluer notre conteneur Ollama. On va créer un nouveau service dédié.

Voici à quoi ressemble notre infrastructure mise à jour. J’ai anonymisé les chemins et les clés, mais la structure est celle que j’utilise au quotidien.

1. Le fichier docker-compose.yml

C’est le chef d’orchestre. Il définit comment Ollama et ton Bot communiquent dans un réseau privé.

# docker-compose.yml (Extrait)
services:
  # Votre moteur IA que nous avons configuré auparavant
  ollama:
    image: ollama/ollama
    container_name: ollama
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

  # Le nouveau venu : Notre pont Python personnalisé
  slack-bot:
    build: ./slack-bot
    container_name: slack-bot
    depends_on:
      - ollama
    environment:
      - SLACK_BOT_TOKEN=xoxb-votre-cle-secrete # Token de l'App
      - SLACK_APP_TOKEN=xapp-votre-cle-tunnel # Token Socket Mode
      - PYTHONUNBUFFERED=1 # Pour voir les logs en temps réel
    restart: unless-stopped

# docker-compose.yml (Extrait)
services:
  # Votre moteur IA que nous avons configuré auparavant
  ollama:
    image: ollama/ollama
    container_name: ollama
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

  # Le nouveau venu : Notre pont Python personnalisé
  slack-bot:
    build: ./slack-bot
    container_name: slack-bot
    depends_on:
      - ollama
    environment:
      - SLACK_BOT_TOKEN=xoxb-votre-cle-secrete # Token de l'App
      - SLACK_APP_TOKEN=xapp-votre-cle-tunnel # Token Socket Mode
      - PYTHONUNBUFFERED=1 # Pour voir les logs en temps réel
    restart: unless-stopped

2. Le fichier slack-bot/requirements.txt

slack_bolt
requests

slack_bolt
requests

3. Le fichier slack-bot/Dockerfile

Les instructions pour construire l’image de ton bot.

FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY bot.py .
CMD ["python", "bot.py"]

FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY bot.py .
CMD ["python", "bot.py"]

4. Le fichier slack-bot/bot.py (Version avec Mémoire)

C’est ici que la magie opère. Ce script gère les messages directs, les mentions, et conserve l’historique pour que l’IA ait du contexte.

Les dépendances Python nécessaires pour faire tourner le bot.

import os
import requests
from slack_bolt import App
from slack_bolt.adapter.socket_mode import SocketModeHandler

# Configuration
app = App(token=os.environ.get("SLACK_BOT_TOKEN"))
OLLAMA_URL = "http://ollama:11434/api/chat"
MODEL_NAME = "ministral-3:14b-instruct-2512-q4_K_M"

# Mémoire locale (Dictionnaire par utilisateur)
history_db = {}

def get_ai_response(user_id, user_text):
    # Initialiser l'historique si nouveau
    if user_id not in history_db:
        history_db[user_id] = []
    
    # Ajouter le message utilisateur
    history_db[user_id].append({"role": "user", "content": user_text})
    
    # Garder les 10 derniers messages pour le contexte
    history_db[user_id] = history_db[user_id][-10:]

    payload = {
        "model": MODEL_NAME,
        "messages": history_db[user_id],
        "stream": False
    }

    try:
        r = requests.post(OLLAMA_URL, json=payload)
        r.raise_for_status()
        bot_response = r.json()['message']['content']
        
        # Mémoriser la réponse de l'IA
        history_db[user_id].append({"role": "assistant", "content": bot_response})
        return bot_response
    except Exception as e:
        return f"Désolé, j'ai eu un souci technique : {e}"

# Écouteur pour les messages directs (DM)
@app.event("message")
def handle_message(event, say):
    if event.get("channel_type") == "im" and "bot_id" not in event:
        response = get_ai_response(event['user'], event['text'])
        say(response)

# Écouteur pour les mentions (@MonBot)
@app.event("app_mention")
def handle_mention(event, say):
    # On nettoie la mention pour ne garder que la question
    text = event['text'].split('> ')[-1] if '>' in event['text'] else event['text']
    response = get_ai_response(event['user'], text)
    say(response)

if __name__ == "__main__":
    handler = SocketModeHandler(app, os.environ.get("SLACK_APP_TOKEN"))
    handler.start()

import os
import requests
from slack_bolt import App
from slack_bolt.adapter.socket_mode import SocketModeHandler

# Configuration
app = App(token=os.environ.get("SLACK_BOT_TOKEN"))
OLLAMA_URL = "http://ollama:11434/api/chat"
MODEL_NAME = "ministral-3:14b-instruct-2512-q4_K_M"

# Mémoire locale (Dictionnaire par utilisateur)
history_db = {}

def get_ai_response(user_id, user_text):
    # Initialiser l'historique si nouveau
    if user_id not in history_db:
        history_db[user_id] = []
    
    # Ajouter le message utilisateur
    history_db[user_id].append({"role": "user", "content": user_text})
    
    # Garder les 10 derniers messages pour le contexte
    history_db[user_id] = history_db[user_id][-10:]

    payload = {
        "model": MODEL_NAME,
        "messages": history_db[user_id],
        "stream": False
    }

    try:
        r = requests.post(OLLAMA_URL, json=payload)
        r.raise_for_status()
        bot_response = r.json()['message']['content']
        
        # Mémoriser la réponse de l'IA
        history_db[user_id].append({"role": "assistant", "content": bot_response})
        return bot_response
    except Exception as e:
        return f"Désolé, j'ai eu un souci technique : {e}"

# Écouteur pour les messages directs (DM)
@app.event("message")
def handle_message(event, say):
    if event.get("channel_type") == "im" and "bot_id" not in event:
        response = get_ai_response(event['user'], event['text'])
        say(response)

# Écouteur pour les mentions (@MonBot)
@app.event("app_mention")
def handle_mention(event, say):
    # On nettoie la mention pour ne garder que la question
    text = event['text'].split('> ')[-1] if '>' in event['text'] else event['text']
    response = get_ai_response(event['user'], text)
    say(response)

if __name__ == "__main__":
    handler = SocketModeHandler(app, os.environ.get("SLACK_APP_TOKEN"))
    handler.start()

L’avantage de cette méthode ? Si vous voulez changer de modèle d’IA ou mettre à jour Ollama, votre bot Slack n’a pas besoin d’être modifié. Il attend simplement que le moteur soit prêt.

Étape 3 : Donner un cerveau (et une mémoire) au Bot

C’est là que le côté « humain » intervient. Un bot qui répond à une question, c’est bien. Un bot qui se souvient que vous lui avez parlé d’un projet de blog il y a trois messages, c’est mieux.

Par défaut, les API de LLM sont « amnésiques ». Chaque question repart de zéro. Pour corriger ça, on utilise un script Python qui va stocker les derniers échanges dans une petite structure de données (un dictionnaire) avant d’envoyer le tout à l’API /api/chat d’Ollama.

Le script va filtrer les mentions, nettoyer le texte et s’assurer que si vous l’appelez dans un canal public ou en message privé, il sache qui vous êtes.

Note sur l’anonymisation : Dans le code, on ne manipule jamais de noms réels, seulement des user_id fournis par Slack. C’est une couche de confidentialité supplémentaire.

Étape 4 : Le premier démarrage (Et les logs magiques)

Une fois le code prêt, on lance la machine : docker compose up -d --build

C’est le moment de vérité. On regarde les logs du conteneur. Si vous voyez s’afficher ⚡️ Bolt app is running!, félicitations : votre GPU est désormais branché sur Slack.

Étape 5 : L’IA en action (Tests et ressentis)

En testant avec Mistral Nemo (en version instruct, quantifié en Q8 pour garder de la précision), les réponses sont bluffantes.

Ce qui change tout par rapport à une interface web, c’est la fluidité. On pose une question technique sur un bout de code, on continue sa discussion avec ses collègues, et on voit la petite notification Slack arriver quand l’IA a fini de « réfléchir ». C’est moins intrusif et beaucoup plus intégré au flux de travail.

Conclusion : Souveraineté et Futur

En trois étapes, nous sommes passés d’une machine Linux brute à un assistant personnel capable de rivaliser avec les meilleurs services payants, le coût du cloud et l’espionnage en moins.

Ce projet montre qu’en 2026, l’IA locale n’est plus une curiosité pour les geeks du dimanche. C’est un outil de production sérieux, sécurisé, et totalement personnalisable. La prochaine étape ? Pourquoi ne pas donner à ce bot la capacité de lire vos documents locaux ou d’automatiser vos déploiements Docker ?

Mais ça, c’est peut-être le sujet d’un futur article…

D’ici là, reprenez le contrôle de vos données, et amusez-vous bien avec votre nouveau collègue de bureau virtuel !

Ce week-end, j’ai eu l’opportunité de participer au meetup Global Azure France 2026. L’événement était vraiment sympa et m’a permis de faire le plein de connaissances. Voici un petit récapitulatif des différents sujets abordés lors des sessions auxquelles j’ai pu assister.

🧠 Du POC à l’industrialisation : bâtir une infrastructure Azure prête pour la GenAI et les agents IA

Animé par Ibrahima Mbodji

C’était particulièrement intéressant d’avoir un retour d’expérience concret sur l’intégration d’infrastructures d’IA dans Azure, notamment avec AI Foundry. C’est un sujet très actuel mais sur lequel il est encore difficile d’obtenir du recul. Ibrahima a détaillé deux types d’intégration :

• Avec la Landing Zone « Enterprise-Scale ».
• Sans la Landing Zone, en mode « Start Small and Expand ».

Avoir une idée « grosse maille » des infrastructures de test et de production IA dans Azure apporte une vraie valeur ajoutée pour se projeter.

☁️ Azure Local – Le Cloud Souverain by Microsoft

Animé par Jonathan JEHANNO

Pour être honnête, j’avais gardé quelques mauvais souvenirs d’Azure Stack. Mais la démonstration de Jonathan sur Azure Local m’a vraiment fait changer d’avis (et le fait d’avoir une démo en direct, c’est toujours un gros plus !).

Au vu de l’augmentation récente des tarifs de certains hyperviseurs classiques et de Citrix, Azure Local tient vraiment la route en termes de licencing pour de l’AVD (Azure Virtual Desktop). C’est particulièrement pertinent pour les clients qui disposent de la Software Assurance. Même si Microsoft a annoncé en preview limitée l’AVD pour les environnements hybrides, le véritable atout d’Azure Local réside dans sa capacité à offrir un environnement totalement déconnecté, un point crucial pour les enjeux de sécurité et de souveraineté. Nous avons également eu un aperçu d’Office 365 en local. Les fonctionnalités sont encore limitées pour le moment, mais j’espère que la solution évoluera dans le futur.

💻 Design. Co-Pilot. Deploy. No Slides. Just Blazor.

Animé par Mabrouk Mahdhi

Une session très interactive et sans PowerPoint ! Mabrouk nous a fait une belle démonstration de vibe coding avec l’outil UX Pilot. C’est une solution vraiment sympa et facile d’accès. Le petit détail qui fait plaisir : à l’inscription, il est possible de créer un projet gratuitement pour tester la solution immédiatement.

🛠️ Improving Ops with Azure Copilot and GitHub Copilot

Animé par Achraf Ben Alaya

Achraf a partagé d’excellentes recommandations sur l’utilisation de l’IA pour améliorer les opérations. La session était riche en démonstrations pratiques. C’est toujours utile de prendre de bonnes pratiques sur ces outils d’assistance au quotidien.

📊 Le challenge du ROI de l’IA

Animé par Jean-Luc Boucho

C’est l’une des sessions que j’ai le plus appréciées. Il est assez rare d’avoir une vue « haut niveau » sur ce type de projet en entreprise. Jean-Luc a partagé un retour d’expérience transparent, en n’hésitant pas à soulever les différents « warnings » et points de vigilance lors de l’intégration de projets IA. La présentation s’est terminée par des exemples concrets et un petit quiz. Le format était un peu court à mon goût, j’en aurais volontiers pris davantage !

En conclusion

Nous avons eu droit à des sessions très sympas, parfois un peu courtes, mais toujours denses. C’était extrêmement pertinent d’avoir des retours terrain sur des technologies et des projets que l’on n’a pas forcément encore l’habitude de voir tourner en production, car ces technologies sont encore très jeunes.

Cet article fait suite à la Partie 2 : Passer sous Linux pour libérer votre GPU.

Maintenant que le système est propre, que l’interface graphique ne vient plus grignoter vos précieux gigaoctets de mémoire vidéo, on va s’attaquer au « cerveau » de la machine. L’idée ici n’est pas de suivre un tuto de plus sur l’IA, mais de comprendre comment orchestrer une stack qui tient la route pour de la production réelle.

Reprendre le contrôle : mon IA locale avec Mistral NeMo, Ollama et Open WebUI

Le passage à une IA 100 % locale n’est pas qu’une question de confidentialité. C’est avant tout une question de confort et de précision. Quand on travaille sur des projets sérieux, on ne peut pas se permettre d’avoir une IA qui « oublie » le début de la conversation ou qui répond avec le ton policé d’un département de relations publiques californien.

Voici comment j’ai structuré mon environnement pour exploiter au maximum mes 16 Go de VRAM.

1. Pourquoi le choix « Européen » : Mistral vs Llama vs Qwen

C’est un point crucial qu’on aborde rarement. Tous les modèles d’IA ne se valent pas, et ce n’est pas qu’une question de « benchmarks ». C’est une question de culture et de structure de langue.

• Llama (Meta) : Très puissant, mais formaté par une vision américaine de la « safety ». Le modèle a tendance à être trop verbeux, à s’excuser pour un rien et à utiliser des tournures de phrases très (trop) amicales qui sonnent faux en français comme Gemini ou Chatgpt.
• Qwen (Alibaba) : Techniquement impressionnant, surtout en code, mais on sent parfois une structure de pensée différente, presque « traduite », qui peut manquer de naturel sur des nuances rédactionnelles complexes en Europe.
• Mistral (Mistral AI) : C’est mon choix par défaut. Pourquoi ? Parce que Mistral est conçu en Europe. On retrouve dans ses réponses une structure logique et une concision qui collent beaucoup mieux à notre façon de nous exprimer. Le ton est plus direct, plus pragmatique, et surtout, il maîtrise les subtilités de la langue française (et européenne en général) sans avoir besoin d’en faire des tonnes. C’est un modèle qui « réfléchit » de manière plus proche de la nôtre.

2. La stratégie de stockage : Le NVMe de 4 To dédié

On en a parlé rapidement, mais le stockage est le moteur silencieux de votre IA. Charger un modèle de 14 Go doit être une opération transparente.

J’utilise un disque NVMe de 4 To entièrement dédié à l’IA. Voici pourquoi c’est un choix pragmatique :

• Éviter l’asphyxie du système : Les modèles sont lourds. Si vous téléchargez trois ou quatre versions de Mistral ou de Codestral pour comparer, vous perdez 50 Go en dix minutes. Sur un disque système, c’est le crash assuré.
• Vitesse de swap : Même avec 16 Go de VRAM, il arrive qu’on ait besoin de charger/décharger des modèles pour passer du texte à l’image. Le NVMe permet de le faire sans avoir l’impression que le PC a figé.
• Anonymisation des chemins : Pour Docker, j’ai monté ce disque sur un point propre (type /mnt/storage-ia/). Cela permet de garder un fichier de configuration lisible et de déplacer l’intégralité de sa bibliothèque de modèles d’une machine à l’autre simplement en déplaçant le disque et en mettant à jour une ligne dans le .env.

3. L’architecture Docker : Le pilotage de la VRAM

Docker est indispensable pour isoler les pilotes NVIDIA. Sans lui, une mise à jour d’Ubuntu peut casser votre installation CUDA. Voici la structure de mon docker-compose.yml. Notez bien la gestion de ComfyUI : il est là, mais il ne démarre que si je l’appelle.

services:
  # Moteur d'inférence (Le coeur)
  ollama:
    image: ollama/ollama
    container_name: ollama
    volumes:
      - /chemin/anonymise/ssd-ia/models:/root/.ollama
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    restart: unless-stopped

  # Interface utilisateur (Le visage)
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    volumes:
      - ./open-webui-data:/app/backend/data
    depends_on:
      - ollama
    ports:
      - "3000:8080"
    environment:
      - 'OLLAMA_BASE_URL=http://ollama:11434'
    restart: unless-stopped

  # Génération d'images (Démarrage manuel pour préserver les 16 Go de VRAM)
  comfyui:
    build: .
    container_name: comfyui
    runtime: nvidia
    restart: "no" # <--- Crucial : ne consomme rien au repos

services:
  # Moteur d'inférence (Le coeur)
  ollama:
    image: ollama/ollama
    container_name: ollama
    volumes:
      - /chemin/anonymise/ssd-ia/models:/root/.ollama
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    restart: unless-stopped

  # Interface utilisateur (Le visage)
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    volumes:
      - ./open-webui-data:/app/backend/data
    depends_on:
      - ollama
    ports:
      - "3000:8080"
    environment:
      - 'OLLAMA_BASE_URL=http://ollama:11434'
    restart: unless-stopped

  # Génération d'images (Démarrage manuel pour préserver les 16 Go de VRAM)
  comfyui:
    build: .
    container_name: comfyui
    runtime: nvidia
    restart: "no" # <--- Crucial : ne consomme rien au repos

4. Tableau comparatif des modèles utilisés

Voici comment je répartis la charge de travail sur ma carte de 16 Go. L’idée est d’avoir le bon outil pour la bonne tâche, sans jamais saturer la mémoire inutilement.

5. Pourquoi ces modèles et pas d’autres ?

Le choix de Mistral NeMo 12B est le résultat de nombreux tests. Sur une carte de 16 Go, c’est le « sweet spot ».

• En Q8_0 (8-bit) : Le modèle est quasi identique à la version non compressée. On a une précision chirurgicale.
• Le style : Contrairement à Llama qui a tendance à donner des conseils de vie non sollicités ou à faire de longs préambules (« En tant qu’intelligence artificielle, je… »), Mistral NeMo répond à la question. Point. C’est ce gain de temps et cette clarté qui font la différence en milieu pro.

Le Ministral-3 14B, lui, est mon joker pour les dossiers lourds. Sa capacité à gérer 256 000 tokens change la façon dont on travaille. On ne lui donne plus une question, on lui donne un contexte global. C’est le modèle que je sollicite pour auditer des fichiers de configuration Docker ou pour résumer des échanges techniques interminables.

6. Gestion du workflow : Priorité au texte

Dans ma configuration, la VRAM est une ressource précieuse qu’on ne gaspille pas. Le fait d’avoir mis ComfyUI (ou tout autre service d’image) en démarrage manuel est un choix pragmatique. Faire de l’image demande souvent de charger des modèles SDXL ou Flux qui prennent 10 à 12 Go de VRAM. Si Ollama a déjà réservé 13 Go pour Mistral, le crash est inévitable.

Mon workflow est donc linéaire :

Phase créative : Je coupe les modèles texte (Ollama libère la VRAM automatiquement après quelques minutes d’inactivité) et je lance ComfyUI.

Phase de réflexion/rédaction : 100 % de la VRAM pour Mistral via Open WebUI.

7. Vers une mémoire infinie : Le RAG (Prochainement)

Vous avez sans doute remarqué l’option « Documents » dans Open WebUI. C’est ce qu’on appelle le RAG (Retrieval-Augmented Generation). L’idée est simple : au lieu de tout demander au modèle, on lui permet de fouiller dans nos propres fichiers stockés sur le SSD de 4 To.

C’est un sujet tellement vaste et puissant (transformer son PC en base de connaissances souveraine) que j’ai décidé de lui consacrer un article entier. On y verra comment indexer des milliers de documents sans que cela ne ralentisse l’IA et comment poser des questions à sa propre archive technique.

Conclusion

Reprendre le contrôle de son IA, c’est d’abord arrêter de subir les choix des géants du cloud. Avec une carte de 16 Go, un bon disque NVMe et une stack Docker bien réglée, on a entre les mains un outil de travail plus performant et plus respectueux de notre culture que n’importe quel abonnement à 20$/mois.

Mistral NeMo et Ministral-3 ne sont pas juste des noms sur un benchmark, ce sont des outils calibrés pour notre façon de travailler en Europe. Optimisez votre VRAM, soignez votre stockage, et laissez l’IA bosser pour vous, pas l’inverse. 🚀🛠️

Note technique : Pour ceux qui veulent tester le Ministral-3 14B dès maintenant sur leur config Docker, la commande ollama run ministral-3:14b est votre point de départ.

On se retrouve pour la suite de notre dossier sur l’optimisation de la VRAM. Dans la partie 1, on a vu comment gratter chaque Mo possible sur Windows. Mais soyons honnêtes : au bout d’un moment, on se cogne contre les limites du système lui-même. 🛑

Le constat : Windows est trop gourmand

Même avec 32 Go de RAM et un nettoyage complet des applications au démarrage, Windows a cette fâcheuse tendance à s’étendre. Chez moi, il finit par occuper entre 9 et 10 Go de RAM juste pour « exister », malgré toutes les optimisations possibles.

Côté VRAM, c’est le même combat. Même en suivant les astuces de mon article précédent pour réduire la consommation de l’interface, Windows garde toujours une « taxe » de 400 à 500 Mo sur votre GPU. Ça paraît peu ? Sur une carte de 16 Go comme la RTX 5070 Ti ou la RTX 5080, c’est pourtant la différence entre charger un gros modèle Flux ou avoir une erreur « Out of Memory ». 📉

En comparaison, une installation Ubuntu bien configurée ne consomme que 20 Mo de VRAM. Le calcul est vite fait : on rend son potentiel brut à la carte graphique.

Pourquoi Ubuntu + Docker ?

Si vous avez une carte performante avec 16 Go de VRAM, utiliser Ubuntu est le meilleur choix pour l’IA. Pour garder un système propre, j’ai opté pour Docker. C’est la méthode la plus robuste : on évite les conflits de versions Python (le fameux « Python hell ») et on garde un environnement isolé. 🐳

Ce guide vous explique comment installer ComfyUI, configurer l’accès au GPU et lier vos modèles déjà existants (issus de Stability Matrix par exemple) pour ne pas gaspiller d’espace disque.

1. Vérification des prérequis matériels 🖥️

Avant de commencer, on doit s’assurer que ta carte graphique est bien reconnue par Ubuntu. C’est la base indispensable pour que tout le reste fonctionne.

Ouvre un terminal et tape :

nvidia-smi

nvidia-smi

Tu devrais voir un tableau s’afficher. Ce qui nous intéresse ici, c’est que le nom de ta carte apparaisse bien et que la Driver Version soit à jour (idéalement au-dessus de 550 pour les cartes récentes). Si ce tableau s’affiche, ton pilote est opérationnel.

2. Installation de Docker : Le moteur de ton projet ⚙️

Docker va nous permettre d’isoler ComfyUI. Au lieu d’installer des dizaines de bibliothèques directement sur ton Ubuntu, on va créer un « conteneur » qui contiendra tout le nécessaire.

Pourquoi Docker ?

• Propreté : Si tu veux supprimer ComfyUI un jour, tu supprimes juste le conteneur, et ton système reste comme neuf.
• Isolation : Pas de conflit entre tes différents projets IA.
• Simplicité : On utilise une « recette » précise qui fonctionne à tous les coups.

Les étapes d’installation

Tape ces commandes pour installer Docker de manière propre (version officielle) :

# Mise à jour des dépôts
sudo apt-get update
sudo apt-get install 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 | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Configuration du dépôt stable
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] 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 finale
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Mise à jour des dépôts
sudo apt-get update
sudo apt-get install 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 | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Configuration du dépôt stable
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] 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 finale
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

3. Le pont vers le GPU : NVIDIA Container Toolkit 🌉

Par défaut, Docker ne peut pas voir ta carte graphique. Il faut installer un « pont » qui permet au conteneur d’utiliser la puissance de calcul de ta RTX.

# Configuration du dépôt NVIDIA
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
    sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
    sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

# Installation et configuration
sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

# Configuration du dépôt NVIDIA
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
    sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
    sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

# Installation et configuration
sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

4. Préparation de l’environnement ComfyUI 🎨

On va créer un dossier dédié pour notre installation. On va y placer deux fichiers : un pour construire l’image et un pour gérer le lancement.

mkdir ~/comfyui-station && cd ~/comfyui-station

mkdir ~/comfyui-station && cd ~/comfyui-station

Le fichier Dockerfile

Ce fichier contient la « recette » de notre environnement. Il va télécharger une base NVIDIA/PyTorch stable et y installer ComfyUI.

Tape nano Dockerfile et colle ceci :

# On part d'une base CUDA solide
FROM pytorch/pytorch:2.2.1-cuda12.1-cudnn8-runtime

# Installation des dépendances système pour OpenCV et Git
RUN apt-get update && apt-get install -y \
    git \
    libgl1-mesa-glx \
    libglib2.0-0 \
    && rm -rf /var/lib/apt/lists/*

# Clonage de ComfyUI
WORKDIR /opt
RUN git clone https://github.com/comfyanonymous/ComfyUI.git

# Installation des dépendances Python de base
WORKDIR /opt/ComfyUI
RUN pip install --no-cache-dir -r requirements.txt

# --- AJOUT CRUCIAL POUR TON BLOG ---
# On installe les bibliothèques requises par les extensions populaires
# (Manager, Crystools, Lora Manager, etc.)
RUN pip install --no-cache-dir piexif deepdiff py-cpuinfo natsort pynvml toml GitPython

# Lancement du serveur
EXPOSE 8188
CMD ["python", "main.py", "--listen", "0.0.0.0"]

# On part d'une base CUDA solide
FROM pytorch/pytorch:2.2.1-cuda12.1-cudnn8-runtime

# Installation des dépendances système pour OpenCV et Git
RUN apt-get update && apt-get install -y \
    git \
    libgl1-mesa-glx \
    libglib2.0-0 \
    && rm -rf /var/lib/apt/lists/*

# Clonage de ComfyUI
WORKDIR /opt
RUN git clone https://github.com/comfyanonymous/ComfyUI.git

# Installation des dépendances Python de base
WORKDIR /opt/ComfyUI
RUN pip install --no-cache-dir -r requirements.txt

# --- AJOUT CRUCIAL POUR TON BLOG ---
# On installe les bibliothèques requises par les extensions populaires
# (Manager, Crystools, Lora Manager, etc.)
RUN pip install --no-cache-dir piexif deepdiff py-cpuinfo natsort pynvml toml GitPython

# Lancement du serveur
EXPOSE 8188
CMD ["python", "main.py", "--listen", "0.0.0.0"]

5. Mapping des modèles existants (Stability Matrix) 🧠

C’est l’étape cruciale pour ne pas perdre de place. Si tu as déjà tes modèles (Checkpoints, Lora, VAE) sur un disque dur séparé, on va les « monter » directement dans le conteneur.

Le fichier docker-compose.yml

Tape nano docker-compose.yml et adapte les chemins vers ton disque de données :

services:
  comfyui:
    build: .
    container_name: comfyui
    runtime: nvidia
    environment:
      - NVIDIA_VISIBLE_DEVICES=all
    ports:
      - "8188:8188"
    volumes:
      # --- STOCKAGE DES MODÈLES (À adapter selon votre disque) ---
      # Remplacez /media/NOM_UTILISATEUR/DISQUE/ par votre chemin réel
      - /media/user/DATA/Models/StableDiffusion:/opt/ComfyUI/models/checkpoints
      - /media/user/DATA/Models/Lora:/opt/ComfyUI/models/loras
      - /media/user/DATA/Models/VAE:/opt/ComfyUI/models/vae
      
      # --- DONNÉES LOCALES (Persistance dans le dossier du projet) ---
      - ./custom_nodes:/opt/ComfyUI/custom_nodes # Vos extensions
      - ./user:/opt/ComfyUI/user                 # Vos réglages (langue, thèmes)
      - ./output:/opt/ComfyUI/output             # Vos images générées

    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    
    # "no" pour garder le contrôle manuel, "unless-stopped" pour un démarrage auto
    restart: "no"

services:
  comfyui:
    build: .
    container_name: comfyui
    runtime: nvidia
    environment:
      - NVIDIA_VISIBLE_DEVICES=all
    ports:
      - "8188:8188"
    volumes:
      # --- STOCKAGE DES MODÈLES (À adapter selon votre disque) ---
      # Remplacez /media/NOM_UTILISATEUR/DISQUE/ par votre chemin réel
      - /media/user/DATA/Models/StableDiffusion:/opt/ComfyUI/models/checkpoints
      - /media/user/DATA/Models/Lora:/opt/ComfyUI/models/loras
      - /media/user/DATA/Models/VAE:/opt/ComfyUI/models/vae
      
      # --- DONNÉES LOCALES (Persistance dans le dossier du projet) ---
      - ./custom_nodes:/opt/ComfyUI/custom_nodes # Vos extensions
      - ./user:/opt/ComfyUI/user                 # Vos réglages (langue, thèmes)
      - ./output:/opt/ComfyUI/output             # Vos images générées

    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    
    # "no" pour garder le contrôle manuel, "unless-stopped" pour un démarrage auto
    restart: "no"

6. Lancement et Monitoring 📊

Tout est prêt. On lance la construction et le démarrage :

sudo docker compose up -d --build

sudo docker compose up -d --build

Docker va maintenant télécharger les composants (plusieurs Go) et préparer ton serveur. Tu peux suivre l’avancée avec :

sudo docker logs -f comfyui

sudo docker logs -f comfyui

Surveiller tes ressources

Une fois que ComfyUI est lancé sur http://localhost:8188, il est important de surveiller la charge de ta carte. Je te conseille d’installer nvtop sur ton Ubuntu :

sudo apt install nvtop
nvtop

sudo apt install nvtop
nvtop

Cela t’affichera des graphiques magnifiques sur l’utilisation de ta VRAM et de ton GPU en temps réel.

7. Installation du Manager et de Crystools 🛠️

Pour que ton expérience soit complète, tu as besoin du ComfyUI-Manager. Puisque nous avons mappé le dossier custom_nodes, tu peux l’installer directement depuis ton Ubuntu :

cd ~/comfyui-station/custom_nodes
git clone https://github.com/ltdrdata/ComfyUI-Manager.git

cd ~/comfyui-station/custom_nodes
git clone https://github.com/ltdrdata/ComfyUI-Manager.git

Redémarre le conteneur (sudo docker compose restart) et tu verras le bouton Manager apparaître. Utilise-le pour installer Crystools, qui te permettra d’avoir tes statistiques de ressources directement dans l’interface web.

8. Garder le contrôle : Le mode « Démarrage Manuel » 🕹️

Avoir ComfyUI qui tourne en arrière-plan, c’est pratique, mais sur une machine de guerre, on veut parfois récupérer 100 % de sa VRAM pour lancer un jeu gourmand ou un logiciel de montage sans que Docker ne vienne grignoter des ressources.

Voici comment configurer ton installation pour qu’elle ne s’allume que lorsque tu le décides.

1. Modifier la règle de redémarrage

Par défaut, nous avons configuré Docker pour qu’il relance ComfyUI automatiquement au démarrage du PC. Pour changer cela, ouvre ton fichier de configuration :

nano ~/comfyui-station/docker-compose.yml

nano ~/comfyui-station/docker-compose.yml

Modifie la ligne restart tout en bas :

• Ancienne version : restart: unless-stopped
• Nouvelle version : restart: "no"

Applique le changement avec un petit : sudo docker compose up -d. Désormais, au prochain démarrage d’Ubuntu, ComfyUI restera sagement éteint.

2. Le pilotage « Clic-Bouton » avec Portainer

C’est là que Portainer prend tout son sens. Au lieu de taper des lignes de commande, tu as maintenant une télécommande visuelle :

1. Ouvre ton interface Portainer.
2. Dans l’onglet Containers, tu verras ton conteneur comfyui avec un voyant gris (stopped).
3. Quand tu as une idée de création : coche la case et clique sur Start.
4. Une fois ta session finie : clique sur Stop. Ta carte graphique retombe instantanément à 0% d’utilisation.

Conclusion 🏁

Tu as maintenant une installation de ComfyUI professionnelle :

1. Performante : Accès direct au GPU via NVIDIA Container Toolkit.
2. Organisée : Tes modèles restent sur ton disque DATA.
3. Évolutive : Tu peux mettre à jour ComfyUI ou tester d’autres versions sans jamais polluer ton système Ubuntu principal.

Il ne te reste plus qu’à charger ton premier modèle et à laisser libre cours à ta créativité !

Dernier conseil de sécurité : Pense à faire une copie de ton dossier ~/comfyui-station (surtout les fichiers Dockerfile et docker-compose.yml) sur une clé USB ou un cloud. Si tu réinstalles ton Ubuntu un jour, tu récupéreras ton usine à images en exactement 2 minutes.