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

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

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

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

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

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

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

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

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

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

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

Deux mécanismes l’expliquent :

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

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

4. Ce que change le RAG

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

Le déroulé est simple :

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

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

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

5. Quand le gros contexte reste pertinent

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

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

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

Tableau comparatif : RAG vs Gros Contexte

Conclusion

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

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

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

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

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

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

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

La quête de la souveraineté numérique

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

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

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

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

[CODE : arborescence_projet.txt]

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

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

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

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

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

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

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

L’anonymat par procuration

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

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

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

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

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

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

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

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

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

II. L’Infrastructure : Poser les fondations avec Docker

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

Architecture du flux de données

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

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

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

[CODE : docker-compose.yml]

name: tazmen-ai-station

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

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

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

name: tazmen-ai-station

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

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

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

Le point critique : L’accès au GPU

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

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

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

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

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

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

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

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

[CODE : Configuration serveur dans settings.yml]

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

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

Sortie JSON : Le langage de l’IA

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

Le choix des moteurs : Sortir de la bulle Google

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

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

[CODE : Activation des moteurs dans settings.yml]

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

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

Le filtrage et l’autocomplétion

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

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

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

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

L’interface comme centre de commande

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

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

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

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

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

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

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

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

La liaison SearXNG : Le test de vérité

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

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

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

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

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

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

VI. Optimisations avancées : Devenir un Power User

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

Filtrage des sources : Nettoyer le bruit

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

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

Prompt Engineering : Créer l’Assistant Chercheur

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

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

[CODE : chercheur_expert_prompt.txt]

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

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

Gestion de la performance et de la VRAM

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

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

Le réglage fin des concurrent requests

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bilan de performance

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

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

[CODE : exemple_reponse_sourcee.json]

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

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

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

VIII. Conclusion : Le bilan de la liberté

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

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

Performance vs Praticité : L’heure du bilan

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

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

Et quoi après ?

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

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

[CODE : commande_finale_restart.sh]

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

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

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

A bientôt Louis 🐇 🤜 🤛 🐰

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

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

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

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

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

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

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

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

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

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

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

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

L’architecture MoE et l’optimisation au couteau

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

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

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

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

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

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

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

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

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

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

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

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

Le coût caché : l’alerte environnementale

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

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

Conclusion : On fait quoi maintenant ?

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

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

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

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

Analyse comparative (Données Stanford AI Index 2026)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Le Dockerfile du serveur MCP

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

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

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

Le Bridge pour Open-WebUI

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

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

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

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

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

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

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

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

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

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

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

Pourquoi ce script ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Mon System Prompt de « Grosse Flemme »

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

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

La Démo Finale : Ça en jette !

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

Conclusion

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

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

À plus pour de nouvelles aventures en local !

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

L’accessibilité.

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

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

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

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

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

Étape 1 : Préparer le terrain sur Slack

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

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

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

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

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

1. Le fichier docker-compose.yml

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

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

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

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

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

2. Le fichier slack-bot/requirements.txt

slack_bolt
requests

slack_bolt
requests

3. Le fichier slack-bot/Dockerfile

Les instructions pour construire l’image de ton bot.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Conclusion : Souveraineté et Futur

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

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

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

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

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

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

Animé par Ibrahima Mbodji

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

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

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

☁️ Azure Local – Le Cloud Souverain by Microsoft

Animé par Jonathan JEHANNO

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

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

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

Animé par Mabrouk Mahdhi

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

🛠️ Improving Ops with Azure Copilot and GitHub Copilot

Animé par Achraf Ben Alaya

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

📊 Le challenge du ROI de l’IA

Animé par Jean-Luc Boucho

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

En conclusion

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. Tableau comparatif des modèles utilisés

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

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

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

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

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

6. Gestion du workflow : Priorité au texte

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

Mon workflow est donc linéaire :

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

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

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

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

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

Conclusion

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

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

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

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

Le constat : Windows est trop gourmand

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

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

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

Pourquoi Ubuntu + Docker ?

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

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

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

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

Ouvre un terminal et tape :

nvidia-smi

nvidia-smi

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

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

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

Pourquoi Docker ?

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

Les étapes d’installation

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

# Mise à jour des dépôts
sudo apt-get update
sudo apt-get install ca-certificates curl gnupg

# Ajout de la clé GPG officielle de Docker
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

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

# Installation finale
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Mise à jour des dépôts
sudo apt-get update
sudo apt-get install ca-certificates curl gnupg

# Ajout de la clé GPG officielle de Docker
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

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

# Installation finale
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

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

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

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

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

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

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

4. Préparation de l’environnement ComfyUI 🎨

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

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

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

Le fichier Dockerfile

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

Tape nano Dockerfile et colle ceci :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Le fichier docker-compose.yml

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

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

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

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

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

6. Lancement et Monitoring 📊

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

sudo docker compose up -d --build

sudo docker compose up -d --build

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

sudo docker logs -f comfyui

sudo docker logs -f comfyui

Surveiller tes ressources

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

sudo apt install nvtop
nvtop

sudo apt install nvtop
nvtop

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

7. Installation du Manager et de Crystools 🛠️

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

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

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

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

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

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

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

1. Modifier la règle de redémarrage

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

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

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

Modifie la ligne restart tout en bas :

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

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

2. Le pilotage « Clic-Bouton » avec Portainer

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

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

Conclusion 🏁

Tu as maintenant une installation de ComfyUI professionnelle :

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

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

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

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

L’infrastructure Cloud moderne repose sur une agilité sans précédent, offrant aux entreprises la capacité de déployer des services et des interfaces à l’échelle mondiale en quelques clics. Cependant, cette facilité d’utilisation masque souvent une complexité architecturale redoutable. En tant qu’architectes et ingénieurs en infrastructure (Virtualisation, Cloud, Cyber-Infra), nous savons que chaque couche d’abstraction supplémentaire introduit son lot de vulnérabilités potentielles. Aujourd’hui, nous plongeons au cœur d’une faille de conception majeure qui ébranle la confiance dans l’un des composants les plus utilisés de l’écosystème Microsoft Azure : l’Azure API Management (APIM).

Une étude récente menée par la société de cybersécurité Praetorian, s’appuyant sur les travaux initiaux du chercheur Mihalis Haatainen, a révélé une statistique pour le moins alarmante : 97,9 % des portails développeurs Azure APIM exposés sur Internet sont vulnérables à un contournement de l’authentification lors de l’inscription (Signup Bypass). Plus troublant encore, le Security Response Center de Microsoft (MSRC) a classifié ce comportement comme étant « By design » (conçu ainsi). Ce constat impose aux équipes de sécurité et d’infrastructure de comprendre cette mécanique en profondeur pour pallier l’absence de correctif officiel.

Cet article se propose de décortiquer cette vulnérabilité, de détailler la chaîne d’attaque (kill chain) complète, d’évaluer les impacts concrets sur votre infrastructure, et de fournir des recommandations pragmatiques pour fermer cette béance de sécurité.

1. Analyse Technique : Les fondations de la vulnérabilité

Pour bien appréhender le problème, il faut d’abord comprendre le rôle d’Azure APIM. Cette solution agit comme une passerelle (Gateway) entre vos services backend (API internes, bases de données, microservices) et le monde extérieur (développeurs tiers, partenaires, applications front-end). Le Portail Développeur est l’interface web où ces consommateurs externes peuvent s’enregistrer, découvrir les API disponibles, et générer les clés de souscription nécessaires pour effectuer leurs appels API.

La vulnérabilité ne réside pas dans une injection SQL ou un dépassement de tampon, mais dans un décalage flagrant entre l’interface utilisateur (UI) d’administration et la logique métier du backend (REST API). Ce décalage se décompose en trois failles conceptuelles distinctes.

A. Le commutateur UI « Cosmétique »

La première erreur d’appréciation vient du portail d’administration d’Azure. Lorsqu’un administrateur décide de restreindre l’accès à ses API, il se rend dans les paramètres et désactive l’option d’inscription publique (portalsettings/signup.properties.enabled configuré sur false). Visuellement, le bouton « Sign Up » disparaît du portail développeur. L’administrateur pense alors, à juste titre, que l’endpoint d’inscription est désactivé.

Pourtant, il n’en est rien. Le moteur de rendu du portail masque l’interface, mais l’API REST sous-jacente au niveau du endpoint /signup reste parfaitement active. Elle continue d’écouter les requêtes et d’accepter les demandes de création de compte. Il s’agit d’une sécurité par l’obscurité, totalement inefficace face à un attaquant automatisé.

B. L’absence de validation Tenant-Side (Multi-tenant)

Les portails développeurs Azure APIM reposent sur une infrastructure mutualisée (multi-tenant). Lorsqu’une requête HTTP arrive sur les serveurs de Microsoft, elle est routée vers l’instance APIM du bon client en analysant l’en-tête Host de la requête (par exemple : Host: victime-portal.developer.azure-api.net).

La faille majeure ici est l’absence totale de validation d’origine. L’infrastructure Azure ne vérifie à aucun moment si la requête POST /signup a été légitimement générée depuis le domaine du client ou si l’utilisateur a une quelconque relation avec l’organisation cible.

C. La mutualisation du service CAPTCHA

Pour lutter contre les bots et les créations de comptes en masse, Microsoft a intégré un défi CAPTCHA lors du processus d’inscription. Cependant, le service de validation de ce CAPTCHA est global à l’ensemble de l’infrastructure Azure APIM, et non isolé par tenant.

Ainsi, un attaquant peut générer un défi CAPTCHA sur sa propre instance APIM (qu’il contrôle), le résoudre légitimement, puis envoyer le jeton de validation obtenu vers l’instance APIM de la victime. Le système backend de la cible interrogera le service global, qui confirmera la validité du CAPTCHA. L’attaquant vient de contourner la protection anti-bot par une attaque de type « Cross-tenant replay ».

2. La Kill Chain : De l’accès anonyme à l’exfiltration de données

L’équipe de recherche a simulé et documenté une chaîne d’attaque complète pour prouver la criticité de cette faille de conception. La création du compte n’est que la porte d’entrée ; la véritable gravité dépend de la configuration des « Produits » (Products) dans l’APIM.

Par défaut, chaque nouvelle instance APIM est livrée avec un produit nommé « Starter ». Ce produit possède une configuration par défaut fatale dans ce contexte : il requiert une souscription (subscriptionRequired: true) mais ne nécessite aucune approbation manuelle de la part de l’administrateur (approvalRequired: false).

Voici la décomposition pas-à-pas de l’attaque simulée :

Étape 1 : Identification de la cible via OSINT

L’attaquant commence par identifier des instances APIM exposées sur Internet. En utilisant des moteurs de recherche spécialisés comme Shodan, il est extrêmement simple de lister les serveurs répondant au nom d’hôte par défaut *.developer.azure-api.net. Les chercheurs ont ainsi identifié plus de 25 379 instances uniques.

Étape 2 : Vérification du verrouillage cosmétique

L’attaquant visite le portail de la cible. Il constate que l’administrateur a fait son travail : l’inscription semble impossible.

L’interface ne présente aucun bouton pour s’enregistrer, laissant penser que le système est clos.

Mais l’attaquant ne s’arrête pas à l’interface graphique. Il envoie une requête POST artisanale (via curl ou Postman) avec un corps JSON vide vers le endpoint /signup. La réponse du serveur est sans appel : une erreur HTTP 400 « ValidationError » demandant de fournir les informations du challenge CAPTCHA.

Cette erreur prouve de manière irréfutable que le endpoint écoute et que l’authentification « Basic Auth » est toujours activée sur le backend.

Étape 3 : Création d’un compte Cross-Tenant

Fort de cette confirmation, l’attaquant utilise sa propre instance APIM pour générer un CAPTCHA valide. Il forge ensuite une requête POST vers le portail de la victime, en y injectant ses propres identifiants (email, mot de passe) et le jeton CAPTCHA pré-résolu.

Le serveur cible reçoit la requête, interroge le service CAPTCHA global, valide la demande et retourne un statut HTTP 200 OK. Le compte est créé.

Le système de la victime, agissant de manière parfaitement automatisée selon sa conception, envoie même un e-mail de bienvenue à l’attaquant pour confirmer la création de son compte !

Étape 4 : Authentification et obtention de la clé d’API

Désormais doté d’un compte développeur valide, l’attaquant s’authentifie sur l’API de management d’Azure pour interagir avec le portail de la victime.

Il cible alors le produit par défaut « Starter ». Puisque ce produit est configuré pour auto-approuver les demandes d’abonnement, l’attaquant envoie simplement une requête PUT pour s’y inscrire. Le serveur répond par un code HTTP 201 Created.

Dans la foulée, il extrait les clés de souscription primaires et secondaires qui lui donnent désormais un accès complet aux API rattachées à ce produit.

L’automatisation du système ira jusqu’à lui envoyer un nouvel e-mail le félicitant (Youpi 🙁 ) pour son abonnement au produit Starter.

Étape 5 : Exploitation et exfiltration des données

Avec une clé d’API valide en main, la dernière étape consiste à consommer les services backend. Dans l’environnement de test (simulant une API IoT médicale), l’attaquant a pu requêter le nombre de patients.

Pire encore, il a pu exfiltrer des données sensibles complètes (données synthétiques pour la démonstration) incluant des noms, des dates de naissance, des diagnostics médicaux et des identifiants d’assurance.

3. Impacts sur l’Infrastructure et Matrice d’Exploitabilité

Il est essentiel de comprendre que la gravité de cette vulnérabilité varie considérablement en fonction de la manière dont votre infrastructure APIM a été configurée après son déploiement initial. L’équipe de recherche a défini une matrice d’exploitabilité très claire.

Les trois niveaux d’impacts potentiels :

1. Impact Faible (Bruit / Compte fantôme) : Si tous vos produits API exigent une approbation manuelle (approvalRequired: true), l’attaquant pourra créer un compte utilisateur, mais il sera bloqué à l’étape de la souscription. Il ne pourra pas générer de clé d’API. Le risque se limite à une pollution de votre annuaire d’utilisateurs locaux APIM.
2. Impact Modéré (Découverte et reconnaissance) : Si des API non sensibles ou des environnements de « Staging » sont attachés à un produit auto-approuvé. L’attaquant peut cartographier vos endpoints, comprendre la structure de vos requêtes, et préparer des attaques plus ciblées ultérieurement.
3. Impact Critique (Exfiltration et Mouvement latéral) : C’est le scénario du pire. Des API de production, manipulant des données sensibles ou des fonctions métiers critiques (gestion financière, RH, santé), sont rattachées au produit « Starter » ou à un produit auto-approuvé. L’exfiltration de données est immédiate et indétectable, car la clé d’API utilisée est techniquement valide et autorisée par le Gateway. De plus, si l’APIM est interconnecté avec un VNet interne via le mode « Internal » ou « External », l’attaquant pourrait utiliser ces API pour pivoter vers d’autres serveurs de votre infrastructure.

Sur les 25 379 instances analysées heuristiquement via une requête sans charge utile, il est estimé que plus de 23 000 répondent d’une manière confirmant l’activité du endpoint Basic Auth. Seules 51 instances avaient été correctement durcies par leurs administrateurs en supprimant le fournisseur d’identité vulnérable.

4. Recommandations : Les actions pragmatiques de durcissement

Microsoft ayant statué que ce comportement relève du design originel du produit, aucune mise à jour corrective (patch) ne sera poussée automatiquement sur vos tenants. Il est de la responsabilité exclusive des équipes d’architecture Cloud et de sécurité de combler cette faille. L’approche « Security by Default » n’est pas applicable ici ; il faut opérer une « Security by Configuration ».

Voici les quatre étapes cruciales pour sécuriser votre infrastructure APIM.

A. Suppression définitive du fournisseur d’identité « Basic Authentication » (Mesure Radicale)

C’est la seule méthode qui élimine totalement la surface d’attaque. En supprimant le fournisseur d’identité par défaut, le endpoint /signup n’a plus aucune logique d’authentification à laquelle se rattacher, désactivant de facto le mécanisme d’inscription local.

Action en CLI :

B. Transition vers Entra ID (anciennement Azure AD)

C’est la recommandation architecturale sur le long terme. Plutôt que de gérer une base d’utilisateurs locale (et vulnérable) dans APIM, déléguez l’authentification à votre fournisseur d’identité d’entreprise. En liant APIM à Entra ID, la création de compte est soumise aux règles de votre annuaire (MFA, accès conditionnel, validation du domaine). Le bypass cross-tenant devient structurellement impossible puisque l’authentification est cryptographiquement liée à votre propre tenant (Directory).

C. Imposer l’approbation manuelle sur tous les produits (Defense in Depth)

Si des impératifs métiers vous empêchent de supprimer le Basic Auth dans l’immédiat, vous devez impérativement casser la kill chain à l’étape de la génération des clés d’API. Modifiez la configuration de tous vos produits, et particulièrement du produit « Starter » intégré par défaut, pour forcer la validation humaine des souscriptions.

Action en CLI via l’API Management :

En configurant approvalRequired: true, l’attaquant verra sa demande d’abonnement mise en attente.

D. Audit et nettoyage des comptes compromis

Enfin, vous devez vérifier si votre infrastructure a déjà été silencieusement compromise. Utilisez les outils en ligne de commande pour lister l’ensemble des utilisateurs enregistrés sur votre portail APIM via l’authentification basique.

Analysez les dates de création (notamment celles postérieures à votre supposée « désactivation » via l’UI) et les domaines de messagerie utilisés. Supprimez immédiatement tout compte suspect et révoquez l’ensemble de leurs clés de souscription associées.

Conclusion : La vigilance continue face au Cloud

La vulnérabilité du Signup Bypass sur Azure APIM est un cas d’école fascinant et effrayant pour tous les professionnels de l’infrastructure informatique. Elle démontre avec acuité que la sécurité dans le Cloud ne se résume pas à cocher des cases dans une interface graphique conviviale. Les abstractions visuelles masquent des API REST complexes et des logiques de routage multi-tenant qui peuvent être détournées de leur usage premier.

Dans un modèle de responsabilité partagée, lorsque l’éditeur du logiciel (Microsoft) qualifie une faille de « comportement par défaut », c’est à l’équipe cliente (vous) de redoubler de vigilance. L’audit régulier des configurations, l’automatisation du durcissement (via Terraform ou Bicep) et l’adoption du principe du moindre privilège (en imposant Entra ID et l’approbation manuelle) sont les seuls remparts viables contre ce type de menaces silencieuses. Ne laissez pas un simple bouton ON/OFF dicter le niveau de sécurité de vos données les plus critiques.

Source : https://www.praetorian.com/blog/azure-apim-signup-bypass/