Le confidentiel reste chez vous, avec votre Qwen.

Du confidentiel impossible à confier à une IA externe ?

L'IA irait plus vite, vous le savez. Mais cette conversation ne peut pas sortir de l'entreprise.

Ça ne peut pas sortir, donc pas d'IA. Entre les deux, il existe une voie : la faire tourner sur vos propres serveurs.

* Les cas 1 et 2 s'inspirent d'exemples cités dans des vidéos explicatives (Ce que disent les vidéos).

Ce que vous vouliez vraiment : le confidentiel, avec un Qwen interne

Mêmes documents, mêmes réunions. L'IA s'en charge, et les données restent dans l'entreprise.

Tout cela se met en place avec les étapes et la checklist de cette page. Pour la répartition qui inclut la suite des réunions, voir Et SIMY ?

LLM local : pourquoi faire tourner Qwen en interne

Un LLM local, c'est faire tourner les poids publiés d'un modèle sur votre PC ou sur les serveurs de l'entreprise. Le texte saisi ne quitte pas la machine.

Ce qu'un LLM local permet

• Résumer et rédiger des documents confidentiels : comptes rendus, contrats, dossiers de conception, échanges clients.
• Interroger les documents internes (RAG) : lui faire lire règlements et procédures, puis lui poser des questions.
• Traduction et aide au code : traduction chinois, anglais, français ; explication et propositions de correction du code interne.

Un petit modèle n'est pas aussi performant qu'un grand modèle dans le cloud. Utilisez-le pour produire un premier jet plutôt qu'une version finale : l'écart avec vos attentes sera moindre.

Pourquoi Qwen

• Des modèles sous Apache 2.0
• Multilingue, dont le français
• Plusieurs tailles au choix

• Licence : de nombreux modèles, comme Qwen3 ou Qwen3.8-27B, sont publiés sous Apache 2.0. Mais pas tous (tableau ci-dessous).
• Langues : l'annonce de la génération Qwen3 revendique 119 langues et dialectes, dont le français.
• Taille : de 0,6B à 8B pour un PC, de 27B à 32B qui tiennent sur un seul GPU une fois quantifiés, jusqu'à 235B qui demande plusieurs GPU.

La licence dépend du modèle

Faites défiler le tableau horizontalement →

Vérifié le 1er octobre 2026 dans les fiches des modèles de l'organisation Qwen sur Hugging Face. « Qwen, donc Apache 2.0 » est faux. Avant tout usage commercial, vérifiez avec votre service juridique le fichier LICENSE du dépôt du modèle utilisé.

Choisir un moteur d'inférence : Ollama, llama.cpp, vLLM, SGLang, LM Studio

Le logiciel qui fait tourner le modèle s'appelle un « moteur d'inférence ». Côté sécurité, la grande différence, c'est l'adresse d'écoute par défaut.

Faites défiler le tableau horizontalement →

Vérifié dans la documentation officielle de chaque outil (et le code source pour vLLM), octobre 2026. Pour LM Studio, les points non confirmés sont marqués « Voir la doc officielle ».

• Pour valider d'abord : llama.cpp ou Ollama, pour voir si cela sert au travail.
• Pour toute l'entreprise : vLLM. La vitesse tient même avec beaucoup d'utilisateurs simultanés.
• Des agents qui envoient en masse les mêmes longues consignes : SGLang.

Attention avec vLLM : la page Security officielle explique que --api-key ne protège que /v1 et quelques autres chemins, pas /invocations ni /pooling, par exemple. C'est pourquoi la documentation elle-même présente comme mesure la plus efficace un reverse proxy qui ne laisse passer que les endpoints à exposer.

Matériel : mémoire GPU nécessaire selon le modèle Qwen

La mémoire GPU nécessaire se calcule comme une somme de trois termes.

• Poidsnombre de paramètres × octets par paramètre (BF16 : 2, FP8 : 1, 4 bits : env. 0,5)
• + Cache KVproportionnel à la longueur du contexte × nombre d'utilisateurs simultanés
• + Margeespace de travail à l'exécution

Faites défiler le tableau horizontalement →

Pour Qwen3, valeurs du benchmark de vitesse officiel de Qwen (mémoire GPU juste après le démarrage, entrée courte traitée avec transformers). Pour Qwen3.8-27B, faute de tableau officiel, estimation calculée à partir du nombre de paramètres et mesure individuelle, cache KV non compris. Le besoin varie fortement selon la quantification et la longueur du contexte (octobre 2026).

• Qwen3.8-27B et un GPU de 32 Go : en BF16, les poids seuls font environ 54 Go (estimation calculée) : impossible sur une seule RTX 5090 (32 Go). La version FP8 officielle pèse elle aussi environ 28,8 Go de poids, et une estimation publiée montre qu'avec le contexte maximal, 32 Go ne suffisent pas. On ajuste en passant en 4 bits ou en réduisant le contexte maximal.
• Deux GPU de 16 Go ne valent pas un GPU de 32 Go : répartir sur deux cartes coûte la communication entre elles et l'espace de travail propre à chacune.
• Un long contexte allonge l'attente : dans une mesure individuelle, avec environ 250 000 tokens en entrée, le premier caractère a mis plus de 4 minutes à sortir.
• Mac : Apple Silicon partage la mémoire avec le GPU. Il faut nettement plus de mémoire que la taille du fichier du modèle.

Pour dimensionner : fixez d'abord le nombre d'utilisateurs simultanés et la longueur des documents lus en une fois. Le cache KV croît avec ces deux valeurs : si vous ne comptez que les poids, la mémoire manquera en production.

Installer sur un réseau isolé : Qwen et vLLM sur un serveur interne

Exemple avec Qwen3.8-27B en FP8, vLLM (Docker) et un serveur Linux. Les commandes suivent la documentation officielle d'octobre 2026. Si la mémoire GPU manque, réduisez le contexte maximal (--max-model-len) ou choisissez une version 4 bits.

* Architecture fictive, à titre d'illustration

Lire les commandes : remplacez les parties entre chevrons, comme <SHA-du-commit-vérifié>, par vos propres valeurs. Les numéros de version sont des exemples d'octobre 2026.

1. Récupérer le modèle à une version figée

   Poste de transfert (côté Internet)

   Téléchargez depuis les dépôts de l'organisation officielle Qwen/, en précisant le commit. Enregistrez aussi le conteneur du moteur d'inférence à une version figée.

   bash

   pip install -U huggingface_hub
   hf download Qwen/Qwen3.8-27B-FP8 \
     --revision <SHA-du-commit-vérifié> \
     --local-dir ./Qwen3.8-27B-FP8
   
   docker pull vllm/vllm-openai:v0.30.0
   docker inspect --format '{{index .RepoDigests 0}}' vllm/vllm-openai:v0.30.0
   docker save vllm/vllm-openai:v0.30.0 -o vllm-openai-v0.30.0.tar

   Reportez dans le registre le digest affiché par docker inspect (la valeur qui commence par sha256:).

   Pourquoi figer la version : un même dépôt peut changer de contenu d'une révision à l'autre. Pour une version quantifiée, on rapporte qu'une nouvelle révision a supprimé la couche de décodage spéculatif (MTP), et que l'accélération ne se déclenchait plus.

2. Créer le registre SHA-256

   Poste de transfert

   Le lfs.oid renvoyé par l'API Hugging Face est le SHA-256 des gros fichiers (LFS). Comparez-le à vos fichiers locaux.

   bash

   # Extraire les valeurs côté Hugging Face (fichiers LFS uniquement)
   curl -s "https://huggingface.co/api/models/Qwen/Qwen3.8-27B-FP8/tree/<SHA-du-commit-vérifié>?recursive=true&expand=true" \
     | jq -r '.[] | select(.lfs) | "\(.lfs.oid)  ./\(.path)"' > HF.sha256
   
   # Comparer aux fichiers locaux et créer le registre de tous les fichiers
   cd Qwen3.8-27B-FP8
   sha256sum -c ../HF.sha256
   find . -type f ! -path './.cache/*' -print0 | sort -z | xargs -0 sha256sum > ../MODEL.sha256
   cd .. && sha256sum vllm-openai-v0.30.0.tar > IMAGE.sha256

   Une autre personne que celle qui a téléchargé signe le registre pour validation (selon la méthode de signature de votre entreprise).

3. Transférer sur support, vérifier avant de charger

   Serveur du réseau isolé

   Transférez le registre et les fichiers sur support, puis refaites la vérification côté isolé. Une seule ligne FAILED, et on n'utilise pas.

   bash

   cd /srv/llm/models/Qwen3.8-27B-FP8 && sha256sum -c /srv/llm/incoming/MODEL.sha256
   cd /srv/llm/incoming && sha256sum -c IMAGE.sha256
   docker load -i vllm-openai-v0.30.0.tar

4. Démarrer en écoute sur 127.0.0.1 uniquement

   Serveur du réseau isolé

   Sans --host, vLLM écoute sur toutes les interfaces. Écrivez toujours --host 127.0.0.1 et passez la clé par un fichier (en ligne de commande, elle est visible avec ps).

   bash · vLLM (Docker)

   # Créer le fichier de clé avec les droits 600
   sudo install -D -m 600 /dev/null /etc/llm/vllm.env
   echo "VLLM_API_KEY=$(openssl rand -hex 32)" | sudo tee /etc/llm/vllm.env > /dev/null
   
   sudo docker run -d --name qwen --gpus all --ipc=host --network host \
     -v /srv/llm/models:/models:ro \
     -e HF_HUB_OFFLINE=1 -e VLLM_NO_USAGE_STATS=1 -e DO_NOT_TRACK=1 \
     --env-file /etc/llm/vllm.env \
     vllm/vllm-openai:v0.30.0 \
     --model /models/Qwen3.8-27B-FP8 \
     --served-model-name qwen3.8-27b \
     --host 127.0.0.1 --port 8000 \
     --max-model-len 65536 --gpu-memory-utilization 0.90
   
   # Vérifier l'écoute sur 127.0.0.1:8000 uniquement
   ss -ltnp | grep 8000

   • Pas de --trust-remote-code. Pour ne pas exécuter le code livré avec le modèle.
   • Pas de VLLM_SERVER_DEV_MODE=1 en production. Il expose des endpoints de développement.
   • Mode réflexion et appels d'outils : la documentation officielle de Qwen cite, pour Qwen3, --reasoning-parser qwen3 et --enable-auto-tool-choice --tool-call-parser hermes. Pour la génération 3.8, vérifiez dans la fiche du modèle.
   bash · avec Ollama (systemd)

   sudo systemctl edit ollama
   # Écrire ces 3 lignes dans le fichier ouvert, puis enregistrer
   [Service]
   Environment="OLLAMA_HOST=127.0.0.1:11434"
   Environment="OLLAMA_NO_CLOUD=1"
   
   sudo systemctl restart ollama

   bash · avec SGLang ou llama.cpp

   python3 -m sglang.launch_server --model-path /models/Qwen3.8-27B-FP8 \
     --host 127.0.0.1 --port 30000 --api-key <clé> --admin-api-key <clé-admin>
   
   llama-server -m /models/qwen.gguf --host 127.0.0.1 --port 8080 \
     --api-key-file /etc/llm/keys --offline --no-webui --jinja

   Dans l'exemple SGLang aussi, n'écrivez pas la clé en clair : passez-la en pratique par un fichier ou une variable d'environnement. Les exemples des fiches de modèles utilisent --host 0.0.0.0 : ne les copiez pas tels quels.

5. TLS, liste d'autorisation et authentification avec nginx

   Serveur du réseau isolé (passerelle)

   Les utilisateurs n'ont accès qu'à nginx. Seules les routes nécessaires de /v1 passent ; tout le reste renvoie 404.

   nginx

   server {
     listen 443 ssl;
     server_name llm.internal.example;
     ssl_certificate     /etc/pki/llm.crt;
     ssl_certificate_key /etc/pki/llm.key;
     ssl_protocols TLSv1.2 TLSv1.3;
   
     allow 10.20.0.0/16;   # segment interne uniquement
     deny  all;
   
     location = /v1/chat/completions {
       auth_request /_auth;
       auth_request_set $user $upstream_http_x_auth_request_user;
       proxy_set_header Authorization "Bearer <clé-amont>";
       proxy_pass http://127.0.0.1:8000;
       proxy_buffering off;   # pour les réponses en streaming
     }
     location = /v1/models {
       auth_request /_auth;
       auth_request_set $user $upstream_http_x_auth_request_user;
       proxy_set_header Authorization "Bearer <clé-amont>";
       proxy_pass http://127.0.0.1:8000;
     }
     location = /_auth {
       internal;
       proxy_pass http://127.0.0.1:4180/oauth2/auth;   # lien avec l'IdP interne via oauth2-proxy, par ex.
     }
     location / { return 404; }   # ne pas exposer /metrics, /invocations, etc.
   }

   Les utilisateurs s'identifient par le SSO interne (OIDC ou SAML), et la clé d'API amont ne leur est jamais distribuée. auth_request est un module nginx : nginx -V indique s'il est inclus dans votre build.

6. Bloquer le trafic sortant

   Serveur du réseau isolé

   Par défaut, refusez toute connexion du serveur vers Internet. N'autorisez que le DNS interne, la synchronisation de l'heure et le collecteur de logs.

   bash · ufw

   sudo ufw default deny incoming
   sudo ufw default deny outgoing
   sudo ufw allow in on <interface-admin> to any port 22 proto tcp    # à autoriser d'abord, sinon SSH coupe
   sudo ufw allow in on <interface-interne> to any port 443 proto tcp
   sudo ufw allow out to <DNS-interne> port 53 proto udp
   sudo ufw allow out to <NTP-interne> port 123 proto udp
   sudo ufw allow out to <collecteur-logs> port 514 proto tcp
   sudo ufw enable
   
   # Vérifier qu'on ne peut pas sortir (l'échec est le bon résultat)
   curl -m 5 https://huggingface.co

   Si vous publiez un port avec -p dans Docker, Docker ajoute ses propres règles de filtrage : le port peut rester joignable de l'extérieur même si ufw semble le fermer. Ces étapes utilisent --network host et --host 127.0.0.1 pour limiter l'écoute à la machine locale.

   bash · avec -p

   # Publier côté hôte sur 127.0.0.1 uniquement (-p 8000:8000 publie sur toutes les interfaces)
   sudo docker run -d --name qwen --gpus all --ipc=host \
     -p 127.0.0.1:8000:8000 \
     -v /srv/llm/models:/models:ro \
     -e HF_HUB_OFFLINE=1 -e VLLM_NO_USAGE_STATS=1 -e DO_NOT_TRACK=1 \
     --env-file /etc/llm/vllm.env \
     vllm/vllm-openai:v0.30.0 \
     --model /models/Qwen3.8-27B-FP8 --served-model-name qwen3.8-27b \
     --host 0.0.0.0 --port 8000 --max-model-len 65536
   # ↑ écoute sur 0.0.0.0 dans le conteneur, mais exposé sur 127.0.0.1 seulement côté hôte

   Dans cette configuration, vLLM écoute sur 0.0.0.0 à l'intérieur du conteneur, mais reste injoignable depuis l'extérieur de l'hôte. Bloquez aussi le trafic sortant au niveau du pare-feu réseau.

7. Conserver logs et traces d'audit

   Passerelle, supervision

   Qui, quand, quel endpoint : consignez-le dans les logs nginx et envoyez-les vers la plateforme de logs interne (SIEM, etc.). Comptez les tokens via /metrics (format Prometheus), exposé uniquement sur le réseau de supervision.

   nginx · dans http { }

   log_format llm '$time_iso8601 user=$user ip=$remote_addr "$request" '
                  'status=$status bytes=$body_bytes_sent rt=$request_time';
   access_log /var/log/nginx/llm.log llm;

   Si vous activez --enable-log-requests dans vLLM au niveau DEBUG, le texte des prompts apparaît dans les logs. Conserver ou non ce texte, et combien de temps, se décide selon vos règles sur les données personnelles et la confidentialité.

8. Définir utilisateurs et droits

   Interface (Open WebUI, etc.)

   Pour un usage en chat, placez une interface comme Open WebUI dans le même réseau isolé, et répartissez les modèles accessibles par rôle et par groupe. Les départs sont bloqués via l'IdP interne.

   env · Open WebUI

   OFFLINE_MODE=true
   ENABLE_SIGNUP=false
   DEFAULT_USER_ROLE=pending
   ENABLE_COMMUNITY_SHARING=false

   Avec OFFLINE_MODE activé, la recherche documentaire (RAG) ne fonctionne pas si le modèle d'embedding n'a pas été installé au préalable. Apportez-le selon le même circuit que les étapes 1 à 3.

9. Fixer le circuit de mise à jour

   Poste de transfert → test → production

   vLLM sort une version environ toutes les deux semaines, presque toujours avec des correctifs de sécurité. Même en réseau isolé, mettez à jour régulièrement selon le circuit « récupérer → tester → registre → production ».

   bash

   # 1. Récupérer, vérifier et transférer la nouvelle version comme aux étapes 1 à 3
   # 2. En environnement de test, poser les mêmes questions à l'ancienne et à la nouvelle version
   # 3. Lister les variables d'environnement utilisées et vérifier dans les notes de version qu'elles existent toujours
   sudo docker inspect --format '{{range .Config.Env}}{{println .}}{{end}}' qwen \
     | grep -E '^(VLLM_|HF_)' | cut -d= -f1
   # 4. Après la mise en production, noter en une ligne qui a mis à jour, quand, et quand on est revenu en arrière
   echo "$(date -I) vllm <ancienne>→<nouvelle> resp:<nom> test:OK retour:<ancienne>.tar" >> /srv/llm/CHANGELOG

   Gardez le conteneur et le modèle de la version précédente, avec leur digest, pour pouvoir revenir en arrière. Comparez avant et après les valeurs qui changent d'une version à l'autre, comme la longueur maximale du contexte.

Checklist de sécurité d'un LLM local : 20 points avant la production

Avant et après l'installation, vérifiez dans l'ordre. Les cases ne servent que dans cette page : rien n'est envoyé.

0 / 20 vérifiés

Erreurs fréquentes : les failles du « ça devrait aller »

À gauche, l'erreur fréquente ; à droite, la parade avec les étapes de cette page.

• --host 0.0.0.0 sans authentificationLa commande d'exemple, copiée telle quelle, ouvre le serveur à tout le réseau local.
  127.0.0.1 + nginxÉcoute locale seulement. Les utilisateurs passent par la passerelle.
• Une version modifiée d'origine inconnueUn GGUF communautaire « Uncensored » utilisé sans vérifier sa provenance.
  Depuis Qwen/ officiel, SHA figéPour une version tierce, consigner l'auteur et la procédure.
• « Il y a une api-key, donc c'est sûr »Croire que la clé de vLLM protège tous les endpoints.
  Filtrer par liste d'autorisationNe laisser passer que le nécessaire, comme /v1/chat/completions.
• « C'est sur site, donc c'est sûr »Faire l'impasse sur les droits, les logs et le contrôle d'accès du RAG parce que c'est interne.
  En interne, la même rigueurSSO, rôles, logs, recherche qui respecte les droits de lecture.
• Un tunnel pour l'utiliser de l'extérieurUn outil interne exposé sur Internet via Cloudflare Tunnel ou équivalent.
  Depuis le réseau interne seulementPour un accès externe, passer par l'accès distant officiel de l'entreprise.
• Ignorer le trafic sortant par défautStatistiques d'usage de vLLM, mises à jour automatiques d'Ollama desktop.
  Variables d'environnement et blocage sortantCouper dans la config, et aussi au pare-feu.
• Trop en demander à un petit modèleEn agent ou en appel d'outils, il invente des fichiers ou des liens.
  Un premier jet, pas plusExécution en bac à sable, résultats vérifiés par un humain.
• La mise à jour qui casseUne variable d'environnement disparue ou une limite changée, et plus rien ne tourne.
  Comparer avant/après en testCroiser avec les notes de version, noter qui a mis à jour.

Ce que disent les vidéos : Qwen auto-hébergé en pratique

Nous avons vérifié, jusqu'à la transcription audio, 18 vidéos explicatives en anglais, chinois et japonais publiées entre février et octobre 2026.

Et SIMY ? Qwen dans le réseau isolé, SIMY à l'extérieur

Soyons francs : à ce jour, SIMY ne tourne pas sur Qwen, ni dans un réseau isolé, ni hors ligne.

* Répartition fictive, à titre d'illustration

• Capté en réunion et en chat
• À votre façon
• Seulement les décisions

Le texte confidentiel reste traité par le Qwen isolé. Ensuite, pour « qui fait quoi, et pour quand », SIMY fait avancer la partie que l'entreprise a décidé de laisser sortir, dans des outils qu'elle autorise.

• Comment SIMY fonctionne : l'exécution dans le cloud passe par votre compte ChatGPT (Codex). L'usage de Codex s'inscrit dans votre offre ChatGPT.
• Exécution sur PC : l'application de bureau SIMY peut confier l'exécution à Claude Code sur votre PC. Télécharger l'application.
• Lecture de l'historique des conversations : l'application de bureau lit l'historique de Claude Code et de Codex et transforme le travail répétitif en « suggestions de SIMY ». Le texte des conversations n'est pas stocké sur nos serveurs. Les PC et le périmètre concernés se décident selon vos règles internes.

Où tracer la ligne : ce qui reste dans le réseau isolé et ce qui peut passer par des outils externes, ce sont les règles de l'entreprise qui le décident. Le traitement des données par SIMY est décrit dans les pages Sécurité et Politique de confidentialité.

LLM local et Qwen : questions fréquentes

Sources

Étapes, réglages par défaut et licences ont été vérifiés dans les sources officielles suivantes (le 1er octobre 2026). Versions et valeurs par défaut changent souvent : consultez chaque page officielle avant l'installation.

• Security (documentation vLLM), Usage Stats Collection, vllm serve
• Notes de version de vLLM (GitHub)
• Server Arguments (documentation SGLang)
• FAQ (documentation Ollama)
• README de llama.cpp server (GitHub)
• Déploiement avec vLLM (documentation Qwen), Speed Benchmark (documentation Qwen)
• Qwen (Hugging Face), fiche du modèle Qwen3.8-27B
• Hugging Face CLI, Variables d'environnement (Hugging Face Hub)
• ngx_http_auth_request_module (documentation nginx), ngx_http_ssl_module
• Environment Variable Configuration (documentation Open WebUI)
• Packet filtering and firewalls (documentation Docker)
• qwen3.8 (bibliothèque Ollama)