Soyons clairs dès le départ : je n’utilise pas ElevenLabs au quotidien. La qualité est au sommet du marché, le clonage de voix est bluffant, et le multilingue tient parfaitement le français. Difficile de faire mieux côté rendu. Mais pour mon usage, l’abonnement est tout simplement trop cher au regard de ce que j’en ferais réellement.

Le souci, c’est qu’il m’arrive ponctuellement d’en avoir besoin. Une voix off propre pour une vidéo, un test de clonage, une narration pour un article. Et là, deux choses bloquent. La première, c’est le modèle économique. ElevenLabs fonctionne par abonnement avec un plafond de crédits, et le clonage de voix professionnel, celui qui donne le meilleur résultat, démarre à 22 dollars par mois sur le plan Creator. Le plan gratuit, lui, interdit tout usage commercial et impose une mention ElevenLabs dans tes productions, ce qui le rend inutilisable pour de la monétisation YouTube. Payer un abonnement mensuel pour un besoin occasionnel, ça n’a aucun sens.

La deuxième, c’est la confidentialité. Pour cloner ma propre voix, je dois envoyer un échantillon de ma voix sur les serveurs d’une société américaine. Or ta voix, c’est une donnée biométrique. C’est ce qu’il y a de plus personnel, au même titre qu’une empreinte digitale.

Alors j’ai fait ce que je fais à chaque fois : j’ai décidé de rapatrier la capacité sur ma propre machine. L’objectif est simple. Avoir à disposition, à tout moment, une synthèse vocale française avec clonage de voix de qualité, sans abonnement, sans plafond, et sans que ma voix ne quitte mon réseau local. Je te préviens tout de suite : sur une carte Blackwell comme la RTX 5070 Ti, l’installation par défaut plante. Et le contournement n’est documenté nulle part en français. Voici donc le parcours complet, pièges compris.

I. La quête de la souveraineté vocale

Pourquoi se compliquer la vie quand un service à 22 dollars par mois fait le travail ? La réponse tient en deux mots : maîtrise et confidentialité. En produisant mes voix sur ma propre station, je ne dépends plus d’un quota de crédits, d’une connexion internet ou d’une politique de conservation que je ne contrôle pas. Et mon échantillon vocal reste chez moi, sur mon disque.

Le moteur de tout ça, c’est XTTS, le modèle de synthèse vocale de Coqui. Il fait du clonage de voix zero-shot multilingue, français inclus. Tu lui donnes 10 à 30 secondes d’un échantillon, il génère ensuite n’importe quel texte avec cette voix. Pour le piloter, j’utilise AllTalk, un serveur qui enrobe XTTS avec une API compatible OpenAI, une interface web, et la gestion de plusieurs moteurs. C’est le projet d’erew123 sur GitHub.

Ma configuration repose sur le matériel de ma Tazmen Station : un processeur AMD Ryzen 9 9900X épaulé par une carte NVIDIA GeForce RTX 5070 Ti avec 16 Go de VRAM. Bonne nouvelle, XTTS en inférence ne mobilise qu’environ 4 Go de VRAM. Tu as donc largement la place de le faire cohabiter avec un modèle de langage ou de la génération d’images sur la même carte.

Le hic, c’est que la 5070 Ti est une carte Blackwell. Et c’est exactement là que l’aventure commence.

II. Le piège Blackwell

C’est le point qui fait abandonner la moitié des gens, alors autant l’attaquer en premier.

L’installation d’AllTalk pose du PyTorch compilé pour CUDA 12.1. Ce build connaît les architectures GPU jusqu’à sm_90, c’est-à-dire la génération Hopper. Il ne connaît pas le sm_120 de Blackwell. Résultat concret : au premier chargement du modèle sur le GPU, c’est le crash immédiat.

Le contournement consiste à remplacer PyTorch par une version CUDA 12.8, qui elle gère Blackwell. En pratique, torch 2.7.0 avec torchvision et torchaudio alignés sur la même version et le même canal cu128.

Attention au piège dans le piège. Si tu installes torch et torchaudio sans verrouiller les versions, pip te choisit un torchaudio incompatible et tu te manges une erreur de symbole au démarrage du type undefined symbol: torch_library_impl. Il faut imposer les trois versions ensemble, dans l’environnement Python d’AllTalk, une fois l’installation de base terminée :

[CODE : fix_blackwell_cu128.sh]

pip install torch==2.7.0 torchvision==0.22.0 torchaudio==2.7.0 --index-url https://download.pytorch.org/whl/cu128

La vérification immédiate, et celle qui doit devenir un réflexe, c’est de confirmer que le GPU est bien vu :

[CODE : verif_gpu.sh]

python -c "import torch; print(torch.__version__, torch.cuda.is_available(), torch.cuda.get_device_name(0))"

Tu dois obtenir 2.7.0+cu128, True, et le nom de ta carte. Si tu as ça, le sm_120 est géré et le plus dur est derrière toi.

III. L’installation : attention à la branche

Première erreur que j’ai commise, et que tu vas éviter. Le git clone standard tire la branche master, qui correspond à AllTalk V1. La V1 n’a pas d’interface graphique complète, pas de RVC, et son API renvoie les URLs dans un format différent qui casse l’intégration avec certains outils. J’ai perdu un bon moment dessus avant de comprendre.

La version que tu veux, la V2, vit sur la branche alltalkbeta. La nuance n’est écrite nulle part de façon évidente, alors note la bien :

[CODE : install_alltalk_v2.sh]

git clone -b alltalkbeta https://github.com/erew123/alltalk_tts
cd alltalk_tts
chmod +x atsetup.sh
./atsetup.sh

Tu choisis l’option Standalone Application, puis l’installation de base. Le script crée un environnement Python isolé et tire toutes les dépendances. C’est long, laisse mouliner.

Deux avertissements qui m’ont coûté du temps. Au premier lancement, un compte à rebours de 60 secondes télécharge un modèle Piper par défaut. Si tu ne fais rien, tu te retrouves avec Piper, qui est un moteur correct mais sans clonage de voix. Choisis bien le moteur xtts dans le menu de démarrage. Et surtout, ne lance jamais AllTalk en root, sinon ton environnement Python se retrouve avec des fichiers root-owned et tu galères ensuite à chaque commande.

IV. Les correctifs de dépendances

Le remplacement de PyTorch chamboule l’arbre des dépendances. Trois ajustements à faire, et un bug propre à la branche beta à corriger.

Premier point, setuptools. La réinstallation de torch monte setuptools en version récente, qui a supprimé le module pkg_resources. Sauf que la version de librosa embarquée par XTTS en a encore besoin. Sans ça, crash au démarrage avec ModuleNotFoundError: No module named 'pkg_resources'. Le correctif tient en une ligne :

[CODE : fix_setuptools.sh]

pip install "setuptools<81"

Deuxième point, les dépendances système. Le log d’AllTalk te signale trois manques. Le plus important, c’est espeak-ng : XTTS s’en sert pour la phonémisation, ce n’est pas optionnel. Les deux autres relèvent du confort, ffmpeg pour le transcodage des sorties audio et libaio pour faire taire un avertissement :

[CODE : fix_deps_systeme.sh]

sudo apt install espeak-ng ffmpeg libaio-dev

Troisième point, un bug propre à la V2 beta. Quand tu changes de moteur depuis l’interface, le code tente un appel chaîné change_engine(...).save() qui plante avec une AttributeError, parce que la méthode ne renvoie pas l’objet attendu. On sépare proprement les deux appels :

[CODE : patch_change_engine.sh]

sed -i 's/tts_engines_config.change_engine(requested_engine).save()/tts_engines_config.change_engine(requested_engine)\n        tts_engines_config.save()/' ~/alltalk_tts/tts_server.py

Une note de dépannage utile. Sur la V1, j’avais aussi dû patcher le chargement des modèles à cause du passage de PyTorch 2.6 en weights_only=True par défaut, qui refuse les classes personnalisées de Coqui. Sur la V2, le fork de coqui-tts gère déjà ce cas et le modèle charge sans rien toucher. Si jamais tu vois une UnpicklingError au chargement, c’est ce point précis qu’il faut corriger.

V. Le modèle XTTS et le basculement de moteur

Si le moteur xtts est sélectionné mais que le modèle n’a jamais été téléchargé, AllTalk cherche le dossier models/xtts/ et ne trouve rien. Tu télécharges le modèle, soit depuis l’onglet TTS Engines Settings de l’interface, soit en ligne de commande depuis le dépôt officiel sur Hugging Face :

[CODE : telecharger_modele_xtts.sh]

mkdir -p ~/alltalk_tts/models/xtts/xttsv2_2.0.3
cd ~/alltalk_tts/models/xtts/xttsv2_2.0.3
wget https://huggingface.co/coqui/XTTS-v2/resolve/main/model.pth
wget https://huggingface.co/coqui/XTTS-v2/resolve/main/config.json
wget https://huggingface.co/coqui/XTTS-v2/resolve/main/vocab.json
wget https://huggingface.co/coqui/XTTS-v2/resolve/main/speakers_xtts.pth
wget https://huggingface.co/coqui/XTTS-v2/resolve/main/dvae.pth
wget https://huggingface.co/coqui/XTTS-v2/resolve/main/mel_stats.pth

Compte environ 2 Go au total, le fichier model.pth faisant à lui seul près de 1,8 Go. Ensuite, dans l’interface, onglet Generate TTS, tu passes Available Engines sur xtts puis tu cliques Change Model.

L’interface web d’AllTalk est accessible sur le port 7852, et l’API sur le port 7851. C’est cette API compatible OpenAI qui te permettra ensuite de brancher XTTS sur tes propres scripts ou sur n8n.

Côté performance, sur ma RTX 5070 Ti, le modèle charge en 5 à 6 secondes. Et la génération tape entre 0,2 et 0,5 seconde pour une phrase courte. C’est largement sous le temps réel, et franchement comparable à ce que je constatais sur ElevenLabs, sans la latence réseau.

VI. Cloner sa voix : tout se joue sur l’échantillon

C’est le coeur du sujet, et c’est aussi là que tout le monde se plante. Le clonage XTTS est aussi bon que ton échantillon. Ni plus, ni moins. Un clone moyen vient presque toujours d’un sample bâclé, pas du modèle.

Les règles à respecter pour un bon échantillon :

1. Format mono, 22050 Hz, 16 bits.
2. Durée de 10 à 30 secondes. Au-delà de 60 secondes, la qualité ne s’améliore plus et l’encodage ralentit.
3. Voix francophone si tu veux du français propre. Un locuteur anglophone clone un accent anglais sur ton texte français.
4. Aucun bruit de fond, aucune respiration bruyante, aucun raclement de gorge, aucun silence en début ou en fin.
5. Ton naturel et neutre. Si ton sample est joyeux ou agressif, le clone le sera aussi.

Une parenthèse cybersécurité qui devrait te faire réfléchir, parce que ce chiffre n’est pas anodin. 10 à 30 secondes de voix suffisent à produire un clone convaincant. C’est exactement pour cette raison qu’il ne faut jamais parler en premier quand tu reçois un appel suspect ou un numéro inconnu. Un simple « allô, oui, qui est à l’appareil ? » peut donner à un escroc assez de matière pour cloner ta voix, et s’en servir ensuite pour piéger un proche au téléphone, par exemple en simulant un appel de détresse. Le réflexe à prendre : laisse l’interlocuteur se présenter d’abord, et ne meuble pas le silence. La technologie qui te sert dans cet article peut tout aussi bien servir contre toi.

Pour nettoyer un enregistrement, Audacity fait parfaitement le travail. Tu importes ton fichier, tu sélectionnes un passage de silence, puis Effect, Noise Reduction, Get Noise Profile, et tu appliques la réduction sur l’ensemble. Tu coupes les respirations à la souris, tu normalises à -3 dB, et tu exportes en WAV mono 22050 Hz 16 bits.

Si tu veux juste convertir un fichier existant au bon format, ffmpeg suffit :

[CODE : convertir_sample.sh]

ffmpeg -i source.mp3 -ar 22050 -ac 1 -sample_fmt s16 ~/alltalk_tts/voices/mavoix.wav

Tu déposes le fichier dans le dossier ~/alltalk_tts/voices/, tu cliques Refresh Settings dans l’interface, et ta voix apparaît dans la liste. Sélectionne la, tape une phrase de test, et écoute le résultat.dans l’interface, et votre voix apparaît dans la liste. Sélectionnez la, tapez une phrase de test, et écoutez le résultat.

Voici le résultat 😀

VII. Affiner le rendu

Si le clone n’est pas à la hauteur malgré un bon échantillon, deux réglages dans l’onglet Generate TTS.

La température. Plus elle est basse, entre 0,5 et 0,65, plus le rendu colle à ton sample. Plus elle est haute, entre 0,75 et 0,85, plus c’est expressif, mais ça peut dériver.

La repetition penalty. La valeur par défaut à 10 est extrême. Descends à 2 ou 3 pour un rendu nettement plus naturel.

Si ça ne suffit toujours pas, deux options plus lourdes existent. Le mode multi-sample, où tu fournis plusieurs fichiers WAV d’une même personne pour stabiliser le clone. Et le fine-tuning, où tu entraînes réellement XTTS sur ta voix avec 2 à 20 minutes d’audio propre, pour obtenir un modèle dédié bien supérieur au zero-shot. Sur une 5070 Ti, cet entraînement prend une demi-heure environ. Je détaillerai cette partie dans un article séparé, parce qu’elle mérite son propre guide.

VIII. Les cas d’usage concrets

Une fois XTTS en place, ça ouvre plusieurs workflows qui remplacent directement ce que je faisais sur ElevenLabs :

1. Voix off pour mes vidéos YouTube. J’écris le script, je génère les pistes avec ma voix clonée, je monte dans mon éditeur. Zéro crédit consommé.
2. Lecture audio de mes articles de blog. Via l’API d’AllTalk branchée sur n8n, je génère automatiquement une version audio de chaque article.
3. Génération de faux podcasts. Un modèle de langage local écrit un dialogue à deux voix, XTTS le synthétise avec deux échantillons différents.
4. Doublage de mes propres vidéos en français. C’est le pipeline le plus puissant. On chaîne une transcription avec Whisper, une traduction avec un modèle local, puis une régénération en français avec ma propre voix.
   

Chacun de ces workflows mérite son propre tutoriel, et j’y reviendrai dans la suite de cette série.

Voici un exemple en anglais:

en espagnole:

En allemand:

est ça entre très bien dans un workfload n8n

IX. Démarrage automatique avec systemd

Pour ne pas relancer le serveur à la main à chaque démarrage, un service systemd. Tu crées le fichier /etc/systemd/system/alltalk.service :

[CODE : alltalk.service]

[Unit]
Description=AllTalk TTS Server
After=network.target

[Service]
Type=simple
User=ton_user
WorkingDirectory=/home/ton_user/alltalk_tts
ExecStart=/home/ton_user/alltalk_tts/start_alltalk.sh
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

Puis tu l’actives :

[CODE : activer_service.sh]

sudo systemctl daemon-reload
sudo systemctl enable alltalk
sudo systemctl start alltalk

AllTalk démarre désormais au boot, en arrière plan, avec relance automatique en cas de crash. Un détail qui m’a piégé deux fois : à l’arrêt manuel, le sous-process moteur a tendance à survivre et à garder le port 7851 occupé, ce qui bloque le redémarrage. Avant de relancer, vérifie avec lsof -i:7851 que le port est libre, et au besoin libère le avec kill $(lsof -t -i:7851).

X. Conclusion : le bilan de la liberté

Après ce parcours de correctifs et de réglages, est-ce que le jeu en vaut la chandelle ? Pour moi, c’est un oui franc.

Soyons lucides, ElevenLabs garde une longueur d’avance sur la qualité brute, surtout sur les nuances émotionnelles les plus fines. Mais XTTS en local atteint un niveau largement suffisant pour de la voix off, du doublage et de la lecture d’articles. Et il le fait sans abonnement, sans plafond de crédits, et sans que ma voix ne quitte ma machine. Pour quelqu’un qui prend ses données au sérieux, c’est le point de rupture.

Voici comment je résume la comparaison après plusieurs jours d’utilisation :

L’installation n’est pas plug and play sur une carte Blackwell, je ne vais pas te mentir. Mais une fois les correctifs passés, c’est stable, rapide, et entièrement à toi. Le plus gros levier de qualité reste l’échantillon : un bon enregistrement propre vaut tous les réglages du monde.

Dans le prochain article de cette série, je détaille les workflows en profondeur : la voix off, la lecture d’articles via n8n, le faux podcast, et surtout le doublage de mes propres vidéos YouTube en chaînant Whisper, traduction et XTTS. La route vers l’IA locale est encore longue, et on continue à en dessiner les contours.

A bientôt Louis 🐇 🤜 🤛 🐰

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 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 !

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.

L’arrivée de Gemma 4 marque un tournant que nous, ingénieurs d’infrastructure, attendions de pied ferme. On ne parle plus ici d’une simple itération incrémentale de « LLM » (Large Language Model), mais d’une véritable architecture multimodale native, pensée dès le départ pour la performance brute et la flexibilité de déploiement. Google DeepMind vient de libérer une famille de modèles (sous licence Apache 2) qui bouscule le rapport habituel entre puissance de calcul et qualité de réponse.

Le passage à la multimodalité totale (texte, image, audio, vidéo) dans des formats capables de tourner sur des stations de travail standard, voire sur du matériel « edge », change radicalement la donne pour nos pipelines de production.

1. Analyse Technique : L’Architecture sous le Capot

Gemma 4 ne se contente pas d’empiler des couches de Transformers. L’architecture introduit plusieurs mécanismes sophistiqués pour optimiser le flux de données et la gestion de la mémoire vive, ce qui est le nerf de la guerre en infrastructure.

L’Attention Hybride : Sliding Window vs Global Context

L’une des innovations majeures réside dans la gestion de l’attention. Au lieu d’utiliser une attention globale sur toute la fenêtre de contexte (ce qui est extrêmement coûteux en calcul, croissant de manière quadratique), Gemma 4 alterne :

• Sliding-window attention (SWA) : Des couches d’attention locale (512 tokens pour les petits modèles, 1024 pour les gros) qui limitent le voisinage de calcul et réduisent drastiquement la charge GPU.
• Global full-context attention : Des couches classiques intercalées pour maintenir la cohérence globale.

Pour gérer cette dualité, Google utilise un Dual RoPE (Rotary Positional Embeddings). Un RoPE standard pour les fenêtres glissantes et un RoPE « proportionnel » pour les couches globales. C’est ce qui permet aux modèles de tenir des fenêtres de contexte allant jusqu’à 256k tokens sans que la latence n’explose au premier prompt.

Per-Layer Embeddings (PLE) : La fin du goulot d’étranglement initial

Dans un modèle classique, l’embedding initial doit contenir toute l’information sémantique que les couches suivantes vont traiter. Gemma 4 introduit les PLE. C’est un second tableau d’embeddings, de dimension plus faible, qui injecte un signal résiduel spécifique à chaque couche du décodeur.

Concrètement, chaque couche reçoit une information « fraîche » sur l’identité des tokens, ce qui permet au modèle d’être beaucoup plus fin dans son raisonnement multimodal sans augmenter massivement le nombre total de paramètres.

Shared KV Cache : L’optimisation critique de la VRAM

Pour nous, les Ops, le « KV Cache » est souvent ce qui sature la mémoire vidéo lors des phases de génération longue. Gemma 4 implémente un Shared KV Cache. Les dernières couches du modèle ne recalculent pas leurs propres projections de clés (K) et de valeurs (V) ; elles réutilisent celles des couches précédentes.

Le gain est immédiat : moins de calculs de projection et une empreinte mémoire réduite pour le cache de contexte, sans perte de qualité mesurable sur les benchmarks.

2. Impacts sur l’Infrastructure : Dimensionnement et Performance

Le déploiement de Gemma 4 impose de repenser nos quotas de ressources. Voici un tableau récapitulatif des modèles pour nous aider à calibrer nos instances :

Tableau des caractéristiques et tailles de fichiers (Estimations Infra)

*Incluant les tables d’embeddings et PLE.

Le cas particulier du modèle Mixture-of-Experts (MoE)

Le modèle 26B est particulièrement intéressant d’un point de vue infrastructure. Bien qu’il pèse 26 milliards de paramètres (ce qui impacte le stockage et la VRAM nécessaire pour charger le modèle), il n’utilise que 4 milliards de paramètres actifs par token lors de l’inférence.

Impact concret : Vous avez besoin d’une carte avec au moins 24 Go de VRAM (ou une quantification agressive) pour le charger, mais le débit de tokens (tokens/sec) sera proche de celui d’un modèle 4B. C’est le meilleur compromis latence/intelligence du moment.

Gestion de la Multimodalité native

Gemma 4 intègre des encodeurs Vision et Audio directement dans le flux. L’encodeur vision supporte des ratios d’aspect variables et permet de configurer le nombre de tokens d’image (de 70 à 1120). En production, cela signifie que vous pouvez ajuster dynamiquement la charge de calcul en fonction de la précision d’image requise. Un OCR sur un document complexe demandera 1120 tokens, tandis qu’une simple reconnaissance d’objet se contentera de 70 tokens, économisant ainsi de précieux cycles GPU.

3. Recommandations : Mise en œuvre et Optimisation

Pour intégrer Gemma 4 dans vos environnements, voici les chemins critiques à privilégier.

Choix de la quantification

Ne restez pas en FP16 sauf si vous faites du fine-tuning. Pour l’inférence de production :

• Quantification 4-bit (GGUF/EXL2) : Indispensable pour faire tourner le modèle 31B ou 26B sur une seule carte type RTX 3090/4090 ou A10G.
• Quantification 8-bit (bitsandbytes) : Le « sweet spot » pour les modèles E2B et E4B si vous voulez conserver une précision quasi-parfaite en environnement critique.

Stack de déploiement

1. Local / On-device : Utilisez llama.cpp ou MLX (pour les puces Apple Silicon). La gestion du cache KV partagé y est déjà optimisée.
2. Cloud / Serveur : Privilégiez vLLM ou TGI (Text Generation Inference). Ces moteurs gèrent nativement le « Paged Attention », ce qui, couplé à la fenêtre de 256k de Gemma 4, permet de servir des contextes massifs sans crash mémoire.
3. Web / Browser : Grâce à transformers.js, le modèle E2B est désormais utilisable directement côté client en WebGPU. C’est une option majeure pour réduire vos coûts d’infrastructure serveur en déportant l’inférence sur le device de l’utilisateur.

Configuration Système (Exemple CLI)

Pour tester rapidement le modèle E4B sur une machine Linux avec Python :

Bash

pip install -U transformers accelerate bitsandbytes

Python

from transformers import Gemma4ForCausalLM, AutoProcessor
import torch

model_id = "google/gemma-4-e4b-it"
# Chargement optimisé en 4-bit pour économiser la VRAM
model = Gemma4ForCausalLM.from_pretrained(
    model_id, 
    device_map="auto", 
    quantization_config=BitsAndBytesConfig(load_in_4bit=True)
)

Conclusion

Gemma 4 n’est pas seulement une réussite algorithmique, c’est une leçon d’optimisation d’infrastructure. En combinant intelligemment l’attention hybride, les PLE et le partage de cache KV, Google livre des modèles qui « respirent » mieux sur notre hardware actuel.

Pour les équipes Infra, le message est clair : la barrière à l’entrée pour l’IA multimodale de haute qualité vient de s’effondrer. Le modèle 26B MoE, en particulier, va devenir le standard pour les agents autonomes nécessitant rapidité et compréhension contextuelle étendue. Il est temps de mettre à jour vos clusters et de commencer à benchmarker ces modèles sur vos données métiers.

Source : https://huggingface.co/blog/gemma4

Il y a encore quelques années, si je voulais créer des images numériques hyperréalistes, il me fallait des compétences pointues en modélisation 3D, en rendu physique ou des heures de travail acharné sur Photoshop. Aujourd’hui, il me suffit de taper une phrase, un simple « prompt » : « génère moi une image réaliste de l’homme du lapin (soit fidèle à la source) qui roulent dans un décapotable verte dans le désert du Nevada, le xénomorphe (du film alien) fait du stop sur le bord de la route sur le dos d’une licorne arc en ciel ». Quelques secondes plus tard, je vois l’image apparaître, non pas extraite d’une immense base de données secrète, mais générée de toutes pièces, pixel par pixel. Plus récemment encore, j’ai vu cette prouesse s’étendre à la vidéo, ajoutant une dimension temporelle vertigineuse à cette création ex nihilo.

Pendant longtemps, le monde de l’IA générative visuelle que j’observais était dominé par les GANs (Réseaux Antagonistes Génératifs). Bien que puissants, ils étaient notoirement instables et peinaient à générer des images très complexes à partir de textes précis. Puis, une révolution silencieuse a eu lieu au croisement de l’apprentissage profond (deep learning) et de la physique thermodynamique.

Face à ces résultats stupéfiants, je suis souvent tenté de crier à la magie. Pourtant, sous le capot de ces modèles génératifs de pointe, se cache une mécanique d’une élégance mathématique rare. J’ai voulu comprendre comment ces modèles fonctionnent réellement, et cela demande de dépasser les explications superficielles du type « l’IA a regardé beaucoup d’images ». C’est en fait un processus complexe de sculpture du bruit, guidé par une compréhension mathématique et sémantique du langage humain.

Dans cet article, je vais déconstruire pour vous cette mécanique en trois étapes fondamentales : la création d’un langage commun entre la machine et l’image, la structuration de la matière à partir du chaos absolu, et enfin, l’astuce mathématique cruciale qui permet à l’IA de suivre nos instructions à la lettre.

Partie 1 : La Pierre de Rosette Numérique (Comprendre le lien Texte-Image)

Avant qu’une IA puisse me « dessiner » un chat, elle doit comprendre fondamentalement ce qu’est un « chat », et comment ce concept purement linguistique se traduit visuellement. Si je montre une image de chat à un ordinateur, il ne voit qu’une grille de nombres. Comment faire le pont entre ces pixels froids et le mot « chat » ?

La réponse que j’ai découverte réside dans ce qu’on appelle les espaces latents et une technique d’apprentissage révolutionnaire nommée l’apprentissage contrastif, popularisée notamment par l’architecture CLIP (Contrastive Language-Image Pre-training).

1.1 La magie des espaces vectoriels à haute dimension

Pour comprendre CLIP, il m’a fallu d’abord saisir comment l’IA lit le texte. Les algorithmes modernes ne lisent pas les lettres, ils placent des mots dans un espace géométrique. J’imagine un espace gigantesque, non pas en 3 dimensions, mais possédant des centaines, voire des milliers de dimensions. Dans cet espace, chaque mot, chaque concept est un « point » défini par un vecteur (une longue liste de coordonnées).

L’idée est que des mots ayant un sens similaire seront placés proches l’un de l’autre dans cet espace. « Chien » sera géométriquement proche de « Chiot » et de « Loup », mais très loin de « Gratte-ciel ». Plus fascinant encore, cet espace permet des mathématiques sémantiques : si je prends les coordonnées du mot « Roi », que j’y soustrais les coordonnées de « Homme » et ajoute celles de « Femme », j’atterris exactement sur les coordonnées du mot « Reine ».

Le coup de génie de CLIP a été d’étendre ce concept au monde visuel. L’objectif ? Créer un espace vectoriel unique où les images et les textes qui les décrivent « habitent » exactement au même endroit.

Pour ce faire, le système utilise deux réseaux de neurones distincts fonctionnant en tandem :

1. Un encodeur d’images : Il prend une image de pixels et la compresse pour la transformer en un vecteur de 512 dimensions.
2. Un encodeur de texte : Il prend une phrase et fait exactement la même chose, produisant un autre vecteur de 512 dimensions.

1.2 Le jeu des paires contrastives

Au début de l’entraînement, ces encodeurs sont « stupides ». Le vecteur d’une image de chien peut se retrouver à l’autre bout de l’espace latent par rapport au vecteur de la phrase « une photo de chien ». C’est là qu’intervient l’apprentissage contrastif.

On nourrit le modèle avec des centaines de millions de paires (image, texte descriptif) aspirées sur Internet. J’imagine cela comme une matrice géante. Sur les lignes, j’ai les descriptions textuelles d’un lot d’images. Sur les colonnes, les images correspondantes.

L’objectif de l’entraînement est d’optimiser le modèle pour :

1. Maximiser la similarité entre les paires correspondantes (la diagonale de ma matrice). Géométriquement, l’IA force l’encodeur d’image et l’encodeur de texte à orienter leurs vecteurs respectifs dans la même direction exacte.
2. Minimiser la similarité entre toutes les autres paires. L’IA repousse activement le vecteur de l’image « chat » loin du vecteur du texte « voiture rouge ».

C’est cette fondation, cette véritable Pierre de Rosette numérique, qui permet à l’IA de « comprendre » mes prompts. Cependant, comprendre un texte n’est pas dessiner. CLIP est un critique d’art exceptionnel, mais c’est un piètre peintre. Pour générer l’image, il me faut un autre moteur.

Partie 2 : Sculpter le Chaos (Les Modèles de Diffusion)

La véritable révolution visuelle de la décennie est née de l’adoption des Modèles Probabilistes de Diffusion (DDPM). L’idée centrale m’a paru profondément contre-intuitive au début : pour apprendre à créer la beauté et la structure, l’intelligence artificielle doit d’abord apprendre à les détruire systématiquement.

2.1 Le processus aller : La thermodynamique de la destruction

Le principe s’inspire directement de la physique statistique (le mouvement brownien). Imaginons le processus d’entraînement. Je prends une image parfaitement nette de notre ensemble de données. Le processus de diffusion « aller » (forward process) consiste à détruire cette information en y ajoutant progressivement du bruit gaussien (une sorte de neige télévisuelle).

• Étape 0 : Image originale, parfaitement claire.
• Étape 500 : Les formes commencent à se dissoudre sévèrement dans la neige statique.
• Étape 1000 : L’image originale a totalement et irrémédiablement disparu. Il ne reste qu’un carré de bruit aléatoire absolu.

Ce processus est mathématiquement défini et fixe. J’ai transformé une donnée hautement structurée en un chaos parfait.

2.2 Le processus retour : La genèse à rebours

Le coup de génie des chercheurs a été d’entraîner un immense réseau de neurones (souvent une architecture U-Net) à inverser l’entropie de ce processus temporel.

L’entraînement se déroule ainsi : je donne au réseau de neurones l’image bruitée à une étape aléatoire (par exemple l’étape 450). Je lui donne aussi cette valeur temporelle pour qu’il sache « à quel point » l’image est censée être détruite. Sa mission est de deviner : « Parmi tout ce bruit que tu vois, quelle est la part exacte de bruit qui vient d’être ajoutée ? »

Plutôt que d’essayer de deviner l’image finale d’un coup sec, le réseau apprend à modéliser le vecteur de bruit pour le soustraire mathématiquement et retrouver l’image de l’étape 449, un peu plus nette.

2.3 Le paradoxe de la moyenne : Pourquoi l’IA réinjecte-t-elle du bruit ?

C’est l’une des caractéristiques que je trouve les plus fascinantes. Lors de la génération d’une nouvelle image, je pars de l’étape 1000 avec du pur bruit. Je demande au réseau de prédire le bruit, je le soustrais, et ainsi de suite. Logiquement, je devrais simplement « nettoyer » l’image pas à pas.

Pourtant, dans l’algorithme original, après avoir soustrait le bruit prédit, l’algorithme rajoute délibérément une petite dose de nouveau bruit aléatoire avant de passer à l’étape suivante. Pourquoi saboter son propre travail ?

Pour le comprendre, il faut s’imaginer l’espace de toutes les images possibles. Les images « réelles » et cohérentes occupent un espace extrêmement restreint, comme une fine ligne sinueuse, une spirale complexe.

Quand le modèle regarde un point très bruité (très loin de la spirale), son objectif est de pointer vers elle. Mais au début, le bruit pur est à égale distance de toutes les images possibles. Le réseau a tendance à pointer vers la moyenne de toutes les images possibles de son set d’entraînement (une bouillie grisâtre et floue).

Si je me contente de suivre la prédiction de manière purement déterministe, j’obtiendrai une image sans détails. En rajoutant du bruit à chaque étape, je force le point à « trembler » pendant qu’il se dirige vers la spirale. Cette agitation l’empêche de s’échouer sur la moyenne et lui permet de « tomber » sur une branche spécifique, nette et détaillée.

Partie 3 : Prendre le Contrôle (Conditionnement et Guidage CFG)

J’ai maintenant deux pièces maîtresses isolées : CLIP (qui comprend le texte) et le U-Net de Diffusion (qui sculpte l’image). Le but est de les fusionner. Comment dire au moteur de diffusion quelle partie de la spirale il doit viser ?

3.1 Le conditionnement : Murmurer à l’oreille du bruit

Lorsque je valide mon prompt, le texte passe d’abord dans l’encodeur de texte de CLIP, qui recrache un vecteur dense de coordonnées sémantiques. Ce vecteur est injecté directement dans les entrailles du réseau de diffusion (via l’Attention Croisée).

Au lieu de se demander « Comment rendre cette bouillie de pixels plus réaliste ? », le réseau se demande « Comment la rendre réaliste, sachant que cela doit finir par ressembler au concept d’un astronaute ? ».

3.2 Le secret de l’obéissance aveugle : Le « Classifier-Free Guidance » (CFG)

Cependant, dans la pratique, j’ai souvent remarqué qu’un simple conditionnement ne suffisait pas. Si je demandais « un astronaute tenant une pomme verte sur la lune », le modèle générait souvent juste un astronaute générique.

C’est là qu’est née l’astuce la plus importante : le Guidage sans classifieur (Classifier-Free Guidance ou CFG). C’est ce fameux paramètre « Guidance Scale » que l’on manipule dans les interfaces.

L’idée du CFG est de forcer mathématiquement le modèle à être radical dans son adhésion à mon texte. Voici comment cette magie opère :

1. La passe silencieuse : Le modèle regarde l’image bruitée, et on lui cache mon prompt. Il génère un vecteur prédisant la direction pour rendre l’image simplement « réaliste ».
2. La passe attentive : Le modèle regarde la même image, mais cette fois en lisant mon prompt. Il génère une nouvelle direction de débruitage conditionnée.
3. L’extraction de l’essence pure : On soustrait le vecteur générique du vecteur conditionné. Cette soustraction isole l’essence pure de mon prompt.
4. L’amplification : On multiplie ce vecteur d’essence pure par le facteur d’échelle CFG et on l’ajoute à la prédiction inconditionnelle.

En langage courant, voici ce que je dis au réseau via le CFG : « Je vois où tu irais naturellement. Je vois aussi où tu irais avec mon texte. Calcule la différence, multiplie cette urgence par 8, et fonce dans cette direction en ignorant tes instincts de base ! »

3.3 L’ingénierie inversée des défauts : Les Prompts Négatifs

Le corollaire magnifique du CFG, ce sont les « prompts négatifs ». Si je tape « flou, mauvaise anatomie, doigts supplémentaires », le système calcule le vecteur vers ces mots horribles et le soustrait activement de la trajectoire finale. Le processus est mathématiquement repoussé loin des zones contenant des mains à six doigts.

Conclusion : La grammaire de la nouvelle réalité

Pour moi, la génération d’images et de vidéos par IA n’est pas un banal tour de passe-passe. C’est le triomphe absolu de la modélisation mathématique des espaces à très haute dimension.

En combinant l’apprentissage de la sémantique humaine avec la puissante modélisation des probabilités thermiques inversées, et en y appliquant une algèbre vectorielle agressive pour forcer l’obéissance, nous avons créé un nouveau paradigme de création. J’utilise aujourd’hui mes mots comme des scalpels pour sculpter le bruit probabiliste.

La prochaine fois que je taperai un prompt et que je verrai une image époustouflante émerger du néant en quelques secondes, je prendrai un instant pour imaginer cette tempête de bruit mathématique, repoussée et modelée en arrière dans le temps, guidée par la force gravitationnelle de mes mots. Ce n’est pas de la magie, et c’est précisément pour cela que c’est si fascinant.

Sources et références scientifiques

Pour la rédaction de cet article et pour celles et ceux qui souhaitent creuser les fondations mathématiques de ces technologies, je me suis appuyé sur les travaux de recherche fondateurs suivants :

Sur l’alignement Texte-Image (CLIP) :

• Radford, A., Kim, J. W., Hallacy, C., Ramesh, A., Goh, G., Agarwal, S., … & Sutskever, I. (2021). Learning Transferable Visual Models From Natural Language Supervision. OpenAI. Lien : https://arxiv.org/abs/2103.00020

Sur la création des Modèles de Diffusion (DDPM) :

• Sohl-Dickstein, J., Weiss, E., Maheswaranathan, N., & Ganguli, S. (2015). Deep Unsupervised Learning using Nonequilibrium Thermodynamics. Stanford University / UC Berkeley. Lien : https://arxiv.org/abs/1503.03585
• Ho, J., Jain, A., & Abbeel, P. (2020). Denoising Diffusion Probabilistic Models. UC Berkeley. Lien : https://arxiv.org/abs/2006.11239

Sur l’accélération du processus (DDIM) :

• Song, J., Meng, C., & Ermon, S. (2021). Denoising Diffusion Implicit Models. Stanford University. Lien : https://arxiv.org/abs/2010.02502

Sur le contrôle de l’IA (Classifier-Free Guidance) :

• Ho, J., & Salimans, T. (2021). Classifier-Free Diffusion Guidance. Google Brain. Lien : https://arxiv.org/abs/2207.12598