Checklist confidentialité

#Ce que « local » garantit, et ce qu'il ne garantit pas

Pour vérifier qu'un LLM local reste confidentiel, il faut contrôler cinq points : l'outil que vous utilisez, ses télémétries et ses appels vers des services distants, le trafic réel de la machine, la provenance des modèles et extensions, et enfin les dossiers où vivent vos conversations. Un modèle exécuté chez vous n'envoie rien par lui-même : les fuites viennent presque toujours de ce qui l'entoure, une option cloud activée, un ping de bibliothèque, un plugin, une synchronisation. La méthode la plus fiable reste le test réseau : couper Internet, refaire une session normale, puis observer ce qui tente encore de sortir. Le reste de cette page détaille chaque contrôle, avec les variables d'environnement, les commandes et les réglages à vérifier.

#Quel niveau de contrôle selon vos données

Tout le monde n'a pas besoin de la même rigueur. Un usage personnel sans donnée sensible se contente des premiers points ; un dossier client ou médical réclame l'étanchéité complète, et un secret industriel ou un cadre NDA impose de prouver ce qui sort. Le tableau suivant relie le niveau d'exigence aux contrôles à cocher.

Les deux dernières lignes sont détaillées dans les guides sur l'isolation d'une machine d'inférence et sur le chiffrement du disque.

#1. Vérifier l'outil lui-même

Chaque application d'inférence a sa propre politique. Ce qui suit reprend ce que les éditeurs indiquent dans leur documentation ou leur politique de confidentialité, consultées le 30 septembre 2026 ; une mise à jour peut changer ces réglages, revérifiez après chaque montée de version majeure.

Deux corrections par rapport aux idées reçues. D'abord, la mention « télémétrie opt-in » qu'on lit souvent pour LM Studio est dépassée : sa politique actuelle précise que l'application n'inclut pas de télémétrie. Ensuite, dire d'Ollama qu'il n'a « aucune fonction distante » est inexact depuis l'arrivée des modèles cloud et de la recherche web. Ces fonctions sont facultatives, mais présentes.

#Ollama : désactiver les fonctions cloud

Si Ollama est votre moteur, coupez explicitement ce qui peut sortir. La FAQ indique qu'en désactivant le cloud, vous perdez la possibilité d'utiliser les modèles cloud et la recherche web d'Ollama. C'est exactement l'effet recherché pour un poste confidentiel.

sudo systemctl edit ollama
# Ajouter dans l'éditeur :
# [Service]
# Environment="OLLAMA_NO_CLOUD=1"
sudo systemctl restart ollama

Sur macOS avec l'application, les variables se posent avec launchctl setenv avant de relancer l'application, comme le décrit la FAQ ; l'alternative est d'ajouter la clé disable_ollama_cloud à true dans le fichier ~/.ollama/server.json. Après redémarrage, les journaux affichent « Ollama cloud disabled: true », ce qui donne une preuve simple à conserver.

• Ollama Cloud : prix, avis et limites

#2. Télémétrie et analytics des bibliothèques

L'outil peut être propre alors que les bibliothèques qu'il embarque parlent. Dans l'écosystème Python de Hugging Face, la documentation indique que certaines données sont collectées par défaut pour surveiller l'usage et prioriser les fonctionnalités, la mise en oeuvre centrale se trouvant dans huggingface_hub. Une seule variable les coupe toutes.

export HF_HUB_DISABLE_TELEMETRY=1
# Équivalent reconnu par tout l'écosystème (transformers, diffusers, gradio) :
export DO_NOT_TRACK=1

# À placer dans ~/.zshrc ou ~/.bashrc pour la rendre persistante

La variable HF_HUB_DISABLE_IMPLICIT_TOKEN, souvent citée avec les précédentes, n'est pas une variable de télémétrie : elle empêche l'envoi automatique de votre jeton Hugging Face lors de requêtes qui n'en ont pas besoin, ce qui limite ce que vous exposez quand vous êtes connecté. Elle est utile, mais pour un autre motif, et la documentation prévient qu'elle peut avoir des effets de bord (les modèles privés n'apparaissent plus dans certaines listes).

export HF_HUB_OFFLINE=1
# Aucun appel HTTP vers le Hub ; seuls les fichiers du cache sont lus

Ce dernier réglage est le plus puissant pour un poste sensible : il transforme une fuite silencieuse en erreur visible. Si un script échoue en signalant l'absence de cache, c'est qu'il tentait de joindre le Hub, ce que vous vouliez savoir. L'ancienne variable TRANSFORMERS_OFFLINE a longtemps servi au même usage, mais HF_HUB_OFFLINE est celle que la documentation actuelle de Transformers met en avant.

#Open WebUI et ses dépendances

Open WebUI embarque des composants tiers, dont une base vectorielle et un module de statistiques d'installation. Son fichier d'exemple de configuration regroupe trois lignes dans une section « DO NOT TRACK » qui coupent ces envois. Elles se passent en variables d'environnement, dans le fichier de configuration ou dans le docker run.

SCARF_NO_ANALYTICS=true
DO_NOT_TRACK=true
ANONYMIZED_TELEMETRY=false

Vérifiez aussi que vous n'y avez pas ajouté de clé de fournisseur distant : un « repli » vers un service hébergé, quand le modèle local est indisponible, envoie silencieusement vos prompts dehors. Le guide Open WebUI avec Ollama montre où ces connexions se déclarent.

• Open WebUI avec Ollama : guide complet

#3. Surveillance réseau : voir ce qui sort vraiment

Les déclarations des éditeurs se lisent ; le trafic se mesure. Un pare-feu applicatif liste chaque programme qui tente une connexion sortante et vous laisse trancher au cas par cas, ce qui révèle en quelques jours ce qu'aucune documentation ne dit.

Little Snitch (macOS)

Pare-feu par application : vous voyez qui appelle quel domaine et décidez pour chaque cas.

GlassWire (Windows)

Historique visuel du trafic par processus, avec alertes sur les nouvelles connexions.

OpenSnitch (Linux)

Application firewall interactif pour GNU/Linux, inspiré de Little Snitch, open source (licence GPL-3.0).

ufw ou iptables

Bloquent par défaut et n'autorisent que le nécessaire ; le guide sur l'air-gap détaille la démarche.

#Lister les connexions et les ports en écoute

Deux commandes distinctes répondent à deux questions. La première montre sur quelle adresse le service accepte des connexions, la seconde les connexions ouvertes vers l'extérieur.

# Qui écoute, et sur quelle adresse ?
lsof -nP -iTCP -sTCP:LISTEN | grep -i ollama

# Quelles connexions sortantes sont ouvertes ?
lsof -nP -i | grep -i ollama | grep ESTABLISHED

Lisez le résultat ainsi : une écoute sur 127.0.0.1:11434 est le comportement par défaut, documenté par la FAQ d'Ollama, et n'est joignable que depuis la machine. Une écoute sur * ou 0.0.0.0 signifie que le service est joignable depuis le réseau local, ce qui arrive quand la variable OLLAMA_HOST a été modifiée. Ce n'est pas une fuite vers Internet, mais c'est une exposition à traiter : voir le guide sur la sécurisation d'un serveur Ollama. Le point souvent confondu : 0.0.0.0 ne veut pas dire « localhost uniquement ».

Une ligne ESTABLISHED vers une adresse publique pendant une inférence est le signal à creuser. Notez que le téléchargement d'un modèle produit légitimement des connexions ; c'est l'inférence, une fois le modèle en place, qui doit rester silencieuse. Les mises à jour de l'application peuvent aussi contacter l'éditeur, comme le reconnaît LM Studio dans sa politique : décidez si vous les tolérez.

• Sécuriser son serveur Ollama
• Air-gapper sa machine d'inférence

#4. Modèles : d'où ils viennent et ce qu'ils contiennent

Le premier téléchargement d'un modèle exige une connexion : c'est normal, et ce qui transite alors est le modèle qui arrive, pas vos données. Une fois le fichier en place, un modèle est un ensemble de poids : lui-même n'ouvre pas de connexion. Le point d'attention porte sur le format et sur ce qui l'exécute.

Format des poids

Les formats GGUF et safetensors ne contiennent que des tenseurs. Le format pickle, utilisé par défaut pour les poids PyTorch, est différent : la documentation de Hugging Face avertit que charger un fichier pickle peut exécuter du code arbitraire.

Origine

Privilégiez les dépôts des éditeurs (Mistral AI, Meta, Qwen, Google) ou les bibliothèques d'un outil qui vérifie ses modèles. Un dépôt anonyme au format pickle est le cas à éviter.

Ce qui exécute

Le risque vient de l'application et de ses outils : si le modèle peut appeler une recherche web, un serveur MCP ou un script, ce sont ces outils qui accèdent au réseau, pas les poids.

#5. Extensions, plugins et outils connectés

C'est là que se cachent la plupart des fuites réelles. Une extension d'éditeur de code, un plugin de prise de notes, un outil déclaré dans Open WebUI ou un serveur MCP s'exécute avec vos droits et peut appeler n'importe quel domaine. Un plugin qui promet « l'IA locale » n'engage que son auteur.

Lire avant d'activer

Cherchez dans le code les appels réseau (requêtes HTTP, bibliothèques de suivi) et l'endpoint réellement configuré : c'est une ligne à changer, souvent, pour pointer vers Ollama plutôt que vers un service hébergé.

Préférer l'open source

Un code que vous pouvez lire est vérifiable ; un assistant à backend propriétaire ne l'est pas.

Limiter les permissions

Un outil qui n'a pas besoin de lire tout le disque ne doit pas y avoir accès ; donnez-lui un dossier de travail dédié.

Observer avec le pare-feu

Après installation, laissez le pare-feu applicatif apprendre les domaines contactés par l'extension pendant une semaine.

• MCP et LLM local : connecter des serveurs MCP à Ollama
• OWASP Top 10 LLM : sécuriser son IA locale

#6. Stockage, sauvegardes et synchronisation

Vos conversations et vos documents indexés sont des fichiers. Leur sort dépend de l'endroit où l'application les range, et de ce qui surveille ce dossier : synchronisation cloud, sauvegarde en ligne, indexeur de recherche.

Où sont les modèles Ollama

Selon la FAQ : ~/.ollama/models sous macOS, /usr/share/ollama/.ollama/models sous Linux, C:\Users\%username%\.ollama\models sous Windows, déplaçable avec OLLAMA_MODELS. Ce sont des fichiers de plusieurs gigaoctets : les exclure de la synchronisation économise aussi de la bande passante.

Où sont les conversations

Dans le dossier de données de l'interface que vous utilisez (LM Studio, Jan, GPT4All, Open WebUI), pas dans celui d'Ollama. Repérez ce dossier dans les réglages de l'application, puis vérifiez qu'aucun service cloud ne le surveille.

Synchronisation

Beaucoup de logiciels rangent leurs données dans Documents, que iCloud, OneDrive ou Dropbox répliquent automatiquement. Une conversation confidentielle y devient une copie sur un serveur tiers.

Sauvegardes

Une sauvegarde hors site ou sur un disque externe non chiffré recopie l'historique. Chiffrez la destination, ou excluez le dossier.

Disque

Un disque non chiffré rend toutes les conversations lisibles en cas de vol : FileVault, BitLocker ou LUKS, avec une phrase de passe solide.

• Chiffrer le disque des modèles

#Audit en 15 minutes : la procédure

Cette procédure enchaîne les contrôles dans l'ordre où ils révèlent le plus pour le moins d'effort. Gardez une capture ou une ligne de journal par étape : elle sert de preuve face à un client.

1. 01
   Inventorier la chaîne

   Listez chaque programme qui touche vos prompts : moteur (Ollama, LM Studio), interface (Open WebUI, Jan), extensions d'éditeur, scripts Python. Ce qui n'est pas listé n'est pas contrôlé.
2. 02
   Couper les fonctions distantes

   Désactivez les modèles cloud et la recherche web (OLLAMA_NO_CLOUD=1), retirez les clés d'API distantes, vérifiez Datalake sur Off dans GPT4All.
3. 03
   Poser les variables

   Placez HF_HUB_DISABLE_TELEMETRY=1, DO_NOT_TRACK=1 et, une fois les modèles en cache, HF_HUB_OFFLINE=1 dans le profil du shell ; ajoutez les trois lignes anti-analytics à Open WebUI.
4. 04
   Regarder le réseau

   Installez un pare-feu applicatif, lancez une session normale de dix minutes, puis relisez les domaines contactés. Lancez aussi les deux commandes lsof.
5. 05
   Déplacer les dossiers

   Sortez conversations et modèles des dossiers synchronisés, chiffrez le disque et la destination des sauvegardes.
6. 06
   Rejouer en mode avion

   Coupez la connexion et refaites la même session. Tout ce qui échoue est soit une fuite, soit une fonction cloud à retirer ; corrigez, puis recommencez jusqu'à ce que le test passe.

#La checklist récapitulative

☐ Fonctions cloud coupées

OLLAMA_NO_CLOUD=1, aucun modèle hébergé, aucune clé d'API distante, Datalake sur Off.

☐ Télémétrie désactivée

HF_HUB_DISABLE_TELEMETRY=1 et DO_NOT_TRACK=1 ; trois variables anti-analytics dans Open WebUI.

☐ Pare-feu applicatif actif

Little Snitch, GlassWire, OpenSnitch, ou ufw avec règle stricte, journal relu.

☐ Écoute vérifiée

127.0.0.1 pour Ollama, sauf exposition voulue et sécurisée.

☐ Modèles hors ligne

Après téléchargement, HF_HUB_OFFLINE=1 ; poids en GGUF ou safetensors, pas de pickle inconnu.

☐ Extensions revues

Code lu, endpoints vérifiés, permissions limitées.

☐ Dossiers hors synchronisation

Conversations et modèles exclus d'iCloud, OneDrive, Dropbox et des sauvegardes non chiffrées.

☐ Disque chiffré

FileVault, BitLocker ou LUKS.

☐ Test mode avion réussi

Une session complète sans Internet.

#Questions fréquentes sur la confidentialité d'un LLM local

• Source : FAQ Ollama (confidentialité, cloud, exposition réseau)
• Source : variables d'environnement de huggingface_hub
• Source : politique de confidentialité de LM Studio
• Source : fichier .env.example d'Open WebUI
• Source : Hugging Face, analyse des fichiers pickle

• LLM local et RGPD : la conformité en entreprise