Fais le tour des réseaux sociaux et tu tomberas vite sur le même argument, répété en boucle : « l’IA en local, c’est gratuit, tu ne paies pas les tokens ». C’est l’argument massue, celui qui fait briller les yeux et sortir la carte bleue.

Sauf que c’est faux. L’IA en local, tu la paies deux fois : une fois à l’achat du matériel, et une deuxième fois en consommation électrique, mois après mois, tant que la machine tourne. Le cloud te facture au token ; le local te facture en watts. Dans les deux cas, il y a un compteur qui tourne. Il est juste moins visible côté local, parce qu’il se planque dans ta facture EDF au lieu d’arriver par mail à la fin du mois.

Et tu risques d’être surpris par le montant. Plus loin dans l’article, je te montre ma propre facture sur douze mois, relevé fournisseur à l’appui. Spoiler : ce n’est pas anodin.

Ça ne veut pas dire que le local est une mauvaise idée. Au contraire, sur certains usages c’est imbattable, et tu gardes la main sur tes données et tes modèles sans dépendre d’une API qui peut changer ses CGU ou ses prix du jour au lendemain. Ça veut juste dire qu’il faut acheter en connaissance de cause, avec les deux factures en tête, pas une seule.

Donc avant de claquer un budget, posons les bases. Et la première règle, celle qui détermine tout le reste, tient en une phrase : en IA locale, tu n’achètes pas de la puissance de calcul, tu achètes de la mémoire.

La règle de base : la mémoire d’abord

Toute la littérature sérieuse 2026 dit la même chose. Tu choisis d’abord la quantité de mémoire (VRAM sur un GPU, ou mémoire unifiée sur un mini-PC / un Mac), et ensuite seulement le reste.

Les repères à garder en tête :

• 8–16 Go : modèles 7B en quantifié. Du RAG léger, des petits agents, de l’expérimentation.
• 24 Go : 32B utilisables en Q4/Q5 (Qwen 2.5-Coder 32B, Mistral Small). Le vrai point de bascule pour bosser sérieusement.
• 40 Go+ ou mémoire unifiée 64–192 Go : 70B quantifiés (Llama 3.3 70B, DeepSeek R1 distill 70B, Qwen 2.5 72B), voire du 120B en 4-bit.

Un détail qu’on oublie souvent : la bande passante mémoire détermine ta vitesse en tokens/seconde. Une RTX 3090 tape dans les ~936 Go/s, un boîtier AMD à mémoire unifiée plafonne souvent autour de ~120 Go/s, un Mac M4 Pro est à 273 Go/s. À mémoire égale, ça change tout sur le ressenti en inférence. Avoir 64 Go ne sert à rien si le modèle crache 4 tok/s.

Les familles de matériel

Avant les tranches de budget, il faut distinguer les formes de produit, parce qu’on compare souvent des trucs qui n’ont rien à voir.

GPU grand public (GeForce). Le meilleur rapport perf/prix pour du LLM + image classique. RTX 3060, 4060 Ti, 3090, 4090, 5090. Le marché de l’occasion est ton ami.

Mini-PC IA à mémoire unifiée. Ryzen AI Max (Strix Halo), Minisforum, GMKtec, Mac mini/Studio. Beaucoup de mémoire, faible conso, format compact. En contrepartie, une bande passante plus faible que les gros GPU (sauf Apple).

Cartes data center détournées. Tesla P100, T4, P4, V100 récupérées d’occasion et collées dans une tour ATX. Beaucoup de VRAM pour pas cher, mais c’est un truc de bricoleur Linux (cooling à ajouter, drivers data center, pas de sortie vidéo).

Edge / embarqué (Jetson). Orin Nano, AGX Orin, Thor. Conso ultra-basse, format NUC, parfait pour de l’always-on silencieux ou du RAG embarqué. Pas pour du gros LLM à la maison.

Stations IA compactes premium. DGX Spark, Mac Studio haut de gamme. 128 Go+ de mémoire unifiée, cher, mais redoutable en perf/watt.

Par tranche de budget

Petite précaution avant de lire : les prix ci-dessous sont des prix observés mi-2026 sur le marché français/européen (occasion comprise). Ça bouge vite, parfois dans le mauvais sens : les Jetson Orin Nano ont pris une grosse hausse ces derniers mois, et le marché de l’occasion réserve des absurdités (un Mac mini M1 d’occasion peut coûter plus cher qu’un M4 neuf… cherchez la logique).

Moins de 400 €

L’entrée de gamme. Tu vises du 7B quantifié et du RAG léger.

• RTX 3060 12 Go d’occasion : le classique. CUDA partout, ça marche, point.
• Tesla P4 8 Go ou P100 16 Go d’occasion (~150–250 €) : énormément de VRAM par euro, mais cooling DIY et drivers data center.
• Tesla V100 32 Go sur AliExpress (~350 €) : le vrai bon plan VRAM/prix du moment, mais c’est réservé aux bricoleurs. Voir l’encadré dédié plus bas, parce qu’il y a un piège électrique sérieux.
• Jetson Orin Nano (~350 €) : si tu veux un truc qui consomme 7 W et tourne en permanence. Attention, le prix a fortement grimpé ces derniers mois, ce n’est plus le kit à 99 $ avant.

À ce niveau, ne rêve pas de génération d’image lourde ni de 32B. C’est un terrain de jeu, pas une station de prod.

400 – 900 €

Le sweet spot pour débuter sérieusement. 16 Go de VRAM ou un mini-PC milieu de gamme.

• RTX 4060 Ti 16 Go ou RX 7600 XT 16 Go : 7–13B confortables et de l’image raisonnable (SDXL, Flux en presets corrects).
• Tesla T4 16 Go : 70 W, excellente en perf/watt, parfaite pour un serveur d’inférence allumé H24.
• Mini-PC Ryzen AI 32 Go : polyvalent, basse conso, mais attention au support GPU sous Linux (j’y reviens plus bas).

900 – 1 800 €

Là, tu passes en 24 Go et tu peux faire du ComfyUI sérieux + du 32B. C’est la tranche des GPU 24 Go d’occasion, et clairement la plus rentable.

• RTX 3090 24 Go d’occasion (700–1 000 €) : LE meilleur achat, toutes catégories confondues. 24 Go, ~936 Go/s, compatibilité parfaite. Le neuf ne sert à rien ici, prends de l’occasion. Si tu ne devais retenir qu’une carte, c’est elle.
• RTX 4090 24 Go d’occasion (1 000–1 100 €) : même VRAM que la 3090 mais plus de patate, notamment en image. Là aussi le neuf est inutile.
• Tesla P100 32 Go : encore plus de VRAM pour pas cher, mais idle médiocre (voir section conso).
• Mini-PC à mémoire unifiée 64 Go type Minisforum AI X1 Pro (~1 100 $) : tu charges des modèles jusqu’à ~50B en Q4 sans GPU dédié. Le piège : ~120 Go/s de bande passante, donc compte 15–25 tok/s sur un Qwen 14B Q4. C’est lent mais ça tient en RAM ce qu’un GPU 24 Go ne tiendra jamais.

1 800 – 3 000 €

La tranche de la mémoire unifiée compacte et de l’edge costaud. Beaucoup de mémoire, faible conso, format de bureau, mais on troque la vitesse des gros GPU contre la capacité.

• Beelink SER9 (HX-370, ~2 300 €) : mini-PC Ryzen AI, basse conso (~7–9 W idle).
• Minisforum Strix Halo 64 Go (~2 300 €) : le modèle 128 Go n’est toujours pas dispo, on est cantonné au 64 Go pour l’instant. TDP modulable 45–120 W.
• Mac mini M4 64 Go (~2 800 €) : 70B quantifiés accessibles, idle dérisoire (~4–8 W), perf/watt imbattable. L’option la plus propre pour un nœud LLM always-on costaud.
• Jetson AGX Orin 64 Go (~2 400 € avec boîtier) : si tu fais de l’edge sérieux ou du RAG embarqué.

Plus de 3 000 €

Le haut du panier. C’est là que le 70B confortable, le 120B en 4-bit et l’image lourde deviennent vraiment fluides, mais le ticket d’entrée fait mal.

• RTX 5090 32 Go (3 500–5 000 €) : la puissance brute. 32 Go GDDR7, ~575 W rien que pour la carte. Réserve-la si tu fais de l’image lourde ou du training.
• Mac Studio M4 (à partir de ~4 400 € selon config) : jusqu’à 192 Go unifiée, 70B quantifiés + vidéo + IA, idle ridicule. Le compromis perf/watt le plus propre pour une station.
• DGX Spark (~5 000 €) : 128 Go unifiée (GB10), écosystème CUDA natif dans un format de bureau.
• Multi-GPU 4× 3090 en rack : 96 Go de VRAM totale pour qui veut du 70B+ sans compromis. C’est plus un labo qu’une machine perso, et la facture électrique suit (voir plus bas).

Le prix de la mémoire : la variable qui va tout chambouler

Tous les prix ci-dessus sont une photo à l’instant T, et cette photo va se dégrader. On a passé l’article à répéter que tu achètes de la mémoire avant tout : il faut donc parler du fait que la mémoire est en pleine crise de prix.

Depuis fin 2025, la DRAM et la NAND flambent. Les tarifs ont été multipliés par 3 à 4 en moins d’un an. La cause tient en trois lettres : la HBM, cette mémoire ultra-rapide qui équipe les accélérateurs IA des data centers (NVIDIA H100/H200/B200, AMD MI300…). Les trois seuls fabricants mondiaux (Samsung, SK Hynix, Micron) ont réorienté leurs capacités vers cette HBM à forte marge, au détriment de la DDR4, DDR5, LPDDR5 et de la NAND grand public. Résultat : moins d’offre, des stocks tendus, des prix qui s’envolent. Et ça ne s’arrête pas à la RAM système : la GDDR des cartes graphiques est touchée par le même effet, donc les GPU sont aussi concernés.

Et ce n’est pas fini. Micron annonce +50 à 60 % sur la DRAM dès le premier trimestre 2026, TrendForce table sur +58 à 63 % de plus au deuxième trimestre. Pour résorber la pénurie, il faudrait augmenter la production de 12 % par an d’ici 2027 ; les plans industriels actuels ne prévoient que 7,5 %. L’écart ne se comble pas par magie : une nouvelle usine de semi-conducteurs met des années à monter en cadence. Les prévisions convergent vers une tension qui dure au moins jusqu’en 2027, avec un plateau des prix cette année-là et une éventuelle détente seulement à partir de 2028. Les plus pessimistes (Counterpoint) évoquent 2030.

Donc oui, il y a eu de légères respirations sur certains tarifs, mais la tendance de fond est haussière, et elle va le rester un moment. Ça a deux conséquences très concrètes pour toi.

D’abord, les configs gourmandes en mémoire vont coûter de plus en plus cher. Un mini-PC 128 Go de mémoire unifiée ou une carte à grosse VRAM, c’est exactement ce que le marché s’arrache. Si ton projet en dépend, le surcoût ne fera que grimper.

Ensuite, et c’est là que je vais à contre-courant du discours ambiant : dans pas mal de cas, le calcul honnête, c’est de ne pas acheter maintenant. À ces prix-là, monter une vraie config locale revient cher, et on sait que la mémoire restera tendue jusqu’en 2027-2028. Une stratégie tout à fait défendable, c’est donc : j’attends deux ans que le marché se détende, et en attendant j’utilise les API. Tu paies au token sur la période, mais tu n’immobilises pas 3 000 ou 5 000 € dans une machine achetée au pic, qui aura perdu de la valeur quand les prix mémoire seront retombés. Pour un usage modéré, l’addition API sur deux ans peut largement rester sous le coût d’achat + électricité d’une grosse config.

Si malgré tout tu veux du local tout de suite, l’occasion est ta meilleure protection. Une RTX 3090 ou 4090 d’occasion, avec sa VRAM déjà soudée et payée au prix d’hier, te met à l’abri de la flambée. C’est l’arbitrage à faire : soit tu passes par l’occasion maintenant, soit tu encaisses le coût API quelque temps et tu investis quand le marché aura soufflé. Ce qui n’a pas de sens, c’est d’acheter du neuf gourmand en mémoire en plein pic.

Dernier point à connaître : à partir de 2026, la disponibilité risque de devenir un problème avant même le prix. Si tu choisis la voie « j’achète maintenant », garde en tête que trouver le composant pourra être plus compliqué que le payer.

Inférence vs diffusion : ce que ça change

On mélange trop souvent les deux usages, alors qu’ils ne sollicitent pas le matériel pareil.

Inférence LLM. C’est dominé par la bande passante mémoire. Le modèle doit être lu en entier à chaque token généré. D’où l’importance de la VRAM (pour faire rentrer le modèle) ET de la bande passante (pour le lire vite). Une P100 à 16 Go fera tourner un 32B Q4, mais ses ~550 Go/s la rendent plus lente qu’une 3090.

Diffusion / génération d’image. Là, l’architecture du GPU compte davantage. Les Tensor Cores modernes (FP8, etc.) accélèrent énormément. C’est pour ça qu’une Pascal (P100) fait tourner ComfyUI mais reste sensiblement plus lente qu’une 3090/4090/5090 sur le même workflow. En image, l’ancienneté de l’archi se paie cash.

Conclusion pratique : si ton truc c’est le LLM, optimise la mémoire et la bande passante. Si c’est l’image, oriente-toi vers une archi récente (Ampere minimum, idéalement Ada/Blackwell).

La consommation : le truc que personne ne regarde

C’est l’angle mort des tableaux VRAM/prix. Si ta machine tourne H24 pour Ollama, n8n ou ComfyUI, deux chiffres comptent : la conso idle (machine allumée, modèle pas chargé) et la conso en calcul.

Attention, point crucial : les chiffres ci-dessous sont pour la carte seule. C’est toute la config qui consomme. CPU, carte mère, RAM, ventilation, alim avec son rendement : ajoute facilement 100 à 250 W sous charge par-dessus le GPU. Une config autour d’une RTX 5090 dépasse le plus souvent 1 000 W à pleine charge. Donc quand tu lis « 575 W » pour la 5090, lis plutôt « 1 000 W au mur » pour la machine complète.

Côté boîtiers compacts, l’intérêt c’est que les chiffres sont système complet (pas de tour à ajouter autour) :

C’est aussi là que les boîtiers compacts à mémoire unifiée prennent leur revanche sur les gros GPU : un Mac mini ou un Strix Halo te fait tourner un 70B en consommant ce qu’une tour avec 5090 brûle au repos. Si ton usage c’est l’always-on, le perf/watt écrase la perf brute.

Le truc à retenir, qui n’apparaît jamais dans un tableau prix/VRAM : une P100 ou une V100 est souvent bloquée en état de perf élevé au repos, donc son idle est mauvais. Géniale pour bricoler et calculer, beaucoup moins pour un serveur domestique qui passe sa vie à attendre. Ça se rattrape sous Linux en réglant les p-states (voir l’astuce dans l’encadré V100 plus bas), mais c’est un réglage à faire, ce n’est pas automatique. À l’inverse, une T4, un Jetson ou un Mac mini sont imbattables pour de l’always-on sans rien toucher.

Règle simple de lecture :

• Tu calcules souvent : 3090/4090/5090, peu importe l’idle.
• Tu veux un nœud IA allumé toute la journée : Mac mini, Jetson, T4. La sobriété prime.

Rien n’est gratuit : la facture, en vrai

Petite parenthèse vécue, parce que c’est facile de raisonner en watts sans jamais regarder la note. Voici ma conso réelle sur 12 mois (relevé fournisseur, en € par mois) :

J’ai commencé à utiliser ma 5070 mi-octobre, et la courbe grimpe à partir de là. En mai, je suis passé sur des API pour une partie du travail, et la facture retombe à 86 €, exactement le niveau d’avant la 5070.

Et là, pas d’échappatoire : je me chauffe au bois :D. Le pic hivernal n’est donc pas un artefact du chauffage électrique. Le seul gros changement sur la période, c’est la machine qui s’est mise à tourner pour faire de l’IA. La corrélation est limpide : GPU allumé mi-octobre, la facture décolle ; bascule sur API en mai, elle redescend à son niveau de départ. Il reste bien quelques variations saisonnières mineures (éclairage, jours plus courts), mais elles ne pèsent pas 100 € par mois. Le coupable, c’est le calcul local.

Mais le message de fond tient : rien n’est gratuit. La machine locale a un coût électrique réel et récurrent, et l’API a un coût au token. L’IA locale n’est pas « gratuite » par opposition au cloud : tu déplaces juste la dépense de la facture API vers la facture EDF. À toi de voir laquelle correspond à ton usage et à ton volume.

Encadré bricoleur : la Tesla V100 32 Go (~350 €)

C’est le meilleur ratio VRAM/prix du moment, mais ça se mérite. Avant de cliquer sur AliExpress, tu dois savoir trois choses :

• L’alimentation est piégeuse. Le connecteur n’est pas un PCIe standard, il y a une modif/adaptateur à faire. Mal branchée, tu risques de cramer la carte mère. Les adaptateurs se trouvent en ligne, mais c’est une manip à ne pas rater.
• Ventilation passive. Comme toutes les cartes data center, pas de ventilo intégré. Il faut ajouter un shroud + ventilateur sinon ça monte en température.
• Idle à programmer sous Linux. Par défaut elle reste bloquée en état de perf élevé (P0), donc elle tire 40 W et plus au repos pour ne rien faire. Sans réglage des p-states, ton idle est catastrophique pour du 24/7.

Astuce : dompter les p-states. Le problème touche toutes les cartes data center (P100, V100, T4…) : par défaut elles ne redescendent pas en basse conso au repos. Deux approches.

D’abord, active le persistence mode pour fiabiliser le comportement des clocks :

bash

sudo nvidia-smi -pm 1

Ensuite, le plus simple et le plus propre : le démon nvidia-pstated (open-source, dispo sur GitHub). Il surveille l’utilisation du GPU et force la carte en p-state bas (P8) dès qu’elle est inactive, puis la repasse en P0 sous charge, automatiquement, sans bricoler tes clocks à la main. Sur une P100/V100, ça fait tomber l’idle de ~40 W à une dizaine de watts. Tu le lances en service systemd et tu n’y penses plus.

Alternative manuelle si tu veux verrouiller les fréquences toi-même (nvidia-smi -lgc), mais tu plafonnes alors les perfs et c’est moins souple que le démon. Pour un serveur allumé en permanence, nvidia-pstated est de loin la meilleure option : c’est lui qui transforme une carte « mauvais idle » en carte 24/7 acceptable.

En clair : 350 € pour 32 Go, c’est imbattable, mais c’est un projet Linux à part entière, pas un achat plug-and-play. Si tu n’es pas à l’aise avec le tuning matériel, reste sur une 3090 d’occasion.

Compatibilité : le piège PyTorch / CUDA

C’est là que beaucoup se font avoir. Avoir 64 Go de mémoire unifiée ne sert à rien si ta stack logicielle ne sait pas l’exploiter au GPU. Petit tour par écosystème.

NVIDIA / CUDA. Le standard de fait. PyTorch, vLLM, Ollama, ComfyUI : sur de l’Ampere ou de l’Ada (3090, 4090…), tout marche nativement, builds officiels, zéro galère. C’est la raison numéro un pour rester sur du NVIDIA si tu fais du dev ou du training, pas juste de l’inférence.

Sauf qu’il y a une grosse exception, et elle est contre-intuitive : la série RTX 5000 (Blackwell) est aujourd’hui le moins bon choix CUDA. Ces cartes utilisent une nouvelle compute capability, sm_120, et les versions stables de PyTorch ne sont compilées que jusqu’à sm_90 (Hopper). Concrètement, sur une 5070 / 5080 / 5090 fraîchement montée, tu te prends souvent un CUDA error: no kernel image is available for execution on the device, ou pire, un fallback silencieux sur le CPU. Le seul moyen d’en tirer quelque chose, c’est de passer par les builds nightly (cu128/cu129, Python 3.13 conseillé) ou de compiler PyTorch depuis les sources. Ça fonctionne, mais ce n’est pas une version stable définitive.

Et ça dure. La série 50 est sortie début 2025 ; on est mi-2026 et le support officiel de sm_120 dans le PyTorch stable n’est toujours pas là. Les demandes côté PyTorch (dont une qui cite nommément la 5070 Ti) sont encore ouvertes. Plus d’un an à bricoler du nightly pour faire tourner une carte vendue, entre autres, pour l’IA : c’est le monde à l’envers. Et le plus cocasse, c’est qu’on parle déjà de la suite : les fuites (Kopite7kimi, relayé par Wccftech) annoncent une génération RTX 60 sous architecture Rubin pour le second semestre 2027. Autrement dit, NVIDIA prépare déjà la relève alors que la génération actuelle n’est toujours pas correctement prise en charge par la stack logicielle. Bref, si tu veux du NVIDIA sans prise de tête logicielle, une 3090 ou 4090 d’occasion t’évitera ces galères ; la 5090 ne se justifie que si tu as vraiment besoin de sa puissance brute et que le tuning logiciel ne te fait pas peur.

AMD / ROCm. Sur les gros GPU AMD dédiés, ROCm progresse et PyTorch a ses builds. Mais sur les iGPU Ryzen AI récents (Strix Halo compris), le support ROCm reste partiel en 2026. Ollama tourne très bien en CPU+RAM, mais sans accélération GPU complète. Donc le mini-PC AMD 64 Go que tu lorgnes : il chargera de gros modèles, mais souvent en s’appuyant sur le CPU. À garder en tête avant d’acheter.

Apple / Metal / MLX. PyTorch a un backend MPS qui fonctionne, mais tous les ops ne sont pas couverts. Pour Apple Silicon, le vrai chemin c’est MLX (le framework d’Apple) ou Ollama/llama.cpp. La bonne nouvelle : la grosse bande passante mémoire (273 Go/s sur M4 Pro) compense, et le perf/watt est excellent.

Pascal (P100/V100). CUDA-capable, donc Ollama/vLLM/ComfyUI tournent. Mais c’est de l’archi ancienne : pas de FP8, pas de Tensor Cores modernes, et il faut surveiller que les versions récentes de PyTorch ne lâchent pas le support des vieilles compute capabilities (sm_60/sm_70). Plus les drivers data center (pas GeForce) et le cooling DIY. C’est jouable, mais ce n’est clairement pas plug-and-play.

Jetson. Écosystème Linux embarqué (JetPack), pas Windows. CUDA présent mais parfois plus limité que sur GPU desktop côté bibliothèques. Parfait pour de l’edge, pas pour reproduire ta station de dev.

En résumé : quel matériel pour quel besoin

• Découvrir, RAG léger, 7B, petit budget. RTX 3060 12 Go d’occasion, ou une Tesla P4/T4 si tu acceptes le bricolage. T4 si c’est pour du H24 sobre. Et si tu es à l’aise avec le tuning matériel, la V100 32 Go à ~350 € est imbattable en VRAM/prix.
• Bosser sérieusement, 32B, ComfyUI, le meilleur rapport qualité/prix. La RTX 3090 24 Go d’occasion (700–1 000 €). Sans hésiter. CUDA natif, 24 Go, bande passante correcte. Le neuf ne sert à rien.
• Charger de gros modèles 70B sans exploser le budget GPU. Un mini-PC à mémoire unifiée 64–128 Go (Minisforum, Strix Halo, ~2 300 €). En acceptant la lenteur et le support GPU partiel sous Linux.
• Nœud IA allumé en permanence, basse conso. Mac mini M4 (~2 800 € en 64 Go) ou Jetson. Conso de N100, moteur IA en plus.
• 70B confortable, perf/watt propre, format bureau. Mac Studio M4 (~4 400 €) ou DGX Spark (~5 000 €), si le budget suit.
• Image lourde, puissance brute, training. RTX 4090 d’occasion (~1 000–1 100 €) ou 5090 (3 500–5 000 €), archi récente obligatoire, sans oublier que la config 5090 complète tape dans les 1 000 W.

Le bon réflexe : pars de ton usage réel (inférence ? image ? always-on ?), déduis la mémoire dont tu as besoin, vérifie que ta stack supporte le matériel au GPU, et seulement après regarde le prix. Dans cet ordre. La machine la plus tape-à-l’œil sur le papier n’est pas forcément celle qui tournera le mieux chez toi.

Et garde en tête les deux factures et le calendrier. À l’achat, la mémoire est en pleine flambée et la tendance reste haussière jusqu’en 2027-2028 : à ces prix-là, le calcul le plus malin n’est pas forcément d’acheter aujourd’hui. Pour beaucoup, attendre deux ans que le marché se détende et tenir avec les API entre-temps coûte moins cher que d’immobiliser plusieurs milliers d’euros dans une machine achetée au pic. Si tu veux quand même du local maintenant, passe par l’occasion, pas par du neuf gourmand en mémoire. En consommation, un GPU qui tourne, c’est une centaine d’euros par mois sur ta facture, chiffre réel à l’appui. L’IA en local n’est pas gratuite. Elle peut valoir largement le coup, mais en connaissance de cause, les deux factures posées sur la table, et parfois la meilleure décision c’est juste d’attendre.

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 🐇 🤜 🤛 🐰

Dans le monde en constante évolution des licences Microsoft, de l’optimisation cloud et des stratégies FinOps, il est essentiel de rester informé des dernières pratiques en matière d’achats IT, de gestion budgétaire et de négociations fournisseurs. C’est précisément ce que propose le blog de Ludovik Dopierala, un expert reconnu dans le domaine des licences Microsoft 365 basé en région parisienne. Avec plus de 4 428 abonnés sur LinkedIn et une expertise pointue chez alt-up by Artemys, Ludovik Dopierala aide les DSI et acheteurs IT à optimiser leurs coûts sur les licences Microsoft Cloud, particulièrement Microsoft 365, dans un contexte de hausses tarifaires récurrentes.

Qui est Ludovik Dopierala ?

Ludovik Dopierala est un professionnel aguerri du secteur IT, avec une expertise marquée en licences Microsoft 365, infrastructure cloud Microsoft Azure et collaboration Modern Workplace. Actuellement Service Line Manager chez alt-up by Artemys à Roeux (Hauts-de-France), il occupe un poste d’expert en infrastructure et cloud Microsoft Azure et collaboration. Avec un profil technique et le titre de MVP Allumnin, il conseille les DSI et acheteurs sur le bon niveau de licences Microsoft en fonction de leurs usages réels.

Ses publications sur son blog Dopierala.fr et sur LinkedIn, telles que des analyses sur les hausses de prix Microsoft 365 2026 (jusqu’à +33%), les contrats CSP ou les stratégies de migration vers Google Workspace, démontrent sa veille technologique active et son engagement à décrypter les enjeux actuels pour un public averti. Son approche analytique et stratégique (« deep dive ») transparaît dans ses écrits, faisant de lui une référence pour les DSI, acheteurs IT, experts en cybersécurité et passionnés du cloud.

Présentation du Blog Dopierala.fr

Le blog Dopierala.fr est une plateforme dédiée à des analyses techniques détaillées sur des thèmes variés comme les licences Microsoft 365, la sécurité informatique, l’IA, les infrastructures cloud et les stratégies FinOps émergentes. Son blog vise à fournir des décryptages pointus, des alertes infrastructurelles et des stratégies d’optimisation budgétaire, le tout dans un style technique et accessible aux professionnels.

Les articles sont souvent structurés autour de « deep dives » ou d’analyses en profondeur, avec des titres évocateurs qui mettent l’accent sur des innovations ou des menaces actuelles. Le blog s’adresse principalement à un public expert : administrateurs systèmes, spécialistes en sécurité et professionnels du cloud, qui cherchent des insights pratiques et des réflexions stratégiques.

Exemples d’Articles Récents

Voici un aperçu des publications qui illustrent la richesse du contenu :

• Microsoft 365 : La courbe de Laffer arrive enfin dans les licences SaaS ? : Une exploration prospective reliant économie (courbe de Laffer) et tarification cloud, expliquant pourquoi les hausses Microsoft 365 de juillet 2026 pourraient atteindre un point de rupture.
• Le Contrat CSP de Microsoft : Une Solution Avantageuse pour les DSI et Acheteurs de PME : Analyse des modèles contractuels Microsoft (Cloud Solution Provider) et stratégies d’optimisation budgétaire.
• Microsoft 365 F3 : Attention à votre Stockage SharePoint : Décryptage des limitations et pièges des licences Frontline.
• Azure Virtual Desktop : Analyse des Regional Host Pools (Public Preview) et de la Souveraineté des Métadonnées : Focus sur les nouveautés Azure AVD et la gestion des données sensibles.
• Windows Admin Center : Vers une Architecture Modulaire avec le « Virtualization Mode » : Une exploration des évolutions modulaires dans l’administration Windows.
• Alerte Infra : La mutation des scans Citrix vers les réseaux résidentiels (Analyse Deep Dive) : Analyse des nouvelles menaces liées aux scans de réseau.
• L’exposition des instances Ollama : Vecteur d’un réseau d’inférence IA fantôme (« Silent Brothers ») : Décryptage d’une vulnérabilité IA potentielle.
• Microsoft Maia 200 : L’ASIC qui redéfinit les standards de l’inférence IA en 3nm : Présentation d’une puce IA innovante.

Ces articles mettent en lumière des sujets d’actualité, comme les intrusions via routage SMTP, la sécurité face à l’IA générative ou le tuning de VRAM pour GPU, avec une emphase sur des stratégies pratiques et des alertes timely.

Pourquoi Suivre Dopierala.fr ?

Si vous êtes passionné par les stratégies d’optimisation cloud, les licences Microsoft 365 et que vous souhaitez approfondir vos connaissances en FinOps, cybersécurité et alternatives SaaS, le blog de Ludovik Dopierala est une ressource incontournable. Ses analyses approfondies et ses alertes infrastructurelles vous aideront à anticiper les défis futurs dans un paysage numérique en mutation rapide, notamment face aux hausses tarifaires Microsoft de juillet 2026.

N’hésitez pas à suivre Ludovik sur LinkedIn pour plus d’updates, et à visiter son blog sur dopierala.fr pour découvrir ses dernières publications !