Confidentialité : ce qui circule vraiment sur le réseau quand l'IA est locale

La question qui compte

Vous avez choisi l'IA locale parce que vos données restent à vous. Mais que traverse vraiment votre ordinateur lorsque vous écrivez à un modèle qui tourne en local ? Quels prompts partent, où vont-ils, qui les voit ?

Cette question a une réponse précise, et la bonne réponse n'est pas « rien » en bloc : c'est presque rien, avec quelques exceptions à vérifier. La bonne nouvelle est que tout se vérifie en une demi-heure, avec les bons outils.

Le flux normal : vos données ne quittent pas la machine

Lorsque vous discutez avec un modèle local, le flux des données est simple. Le texte que vous écrivez est converti en tokens, les tokens passent des poids du modèle à la mémoire de la GPU ou de la RAM, et la réponse revient sur votre interface. Dans ce parcours, votre prompt ne traverse pas le réseau. Il n'y a pas de serveur d'inférence dans un data center : l'inférence s'exécute sur votre machine. C'est ce qui distingue l'IA locale de l'IA dans le cloud.

Le FAQ officiel de l'un des moteurs les plus utilisés le dit directement : quand le modèle tourne en local, le service ne voit ni vos prompts ni vos données. Cela vaut pour les principaux moteurs d'inférence : Ollama, llama.cpp, LM Studio. Ollama exécute le modèle dans un processus local et n'écoute des requêtes réseau que sur l'interface de localhost (127.0.0.1), afin que vos applications puissent s'y connecter. Le serveur local d'Ollama est conçu pour votre ordinateur : les instructions réseau concernent surtout comment l'exposer, si vous le souhaitez, au réseau local.

Ce qui part vraiment sur le réseau

Les seules fois où l'IA locale touche le réseau sont celles-ci :

Le premier téléchargement du modèle. Lorsque vous téléchargez un modèle depuis le registre (par exemple depuis Hugging Face via Ollama), des gigaoctets de données arrivent chez vous. Dans cette connexion, il n'y a pas votre prompt : il y a un fichier, avec une adresse et une somme de contrôle.

Les vérifications automatiques. Ollama et LM Studio vérifient s'il existe une nouvelle version du logiciel : sur Mac et Windows, l'application télécharge les mises à jour automatiquement. Ces appels ne portent aucun contenu : ce sont des requêtes automatiques.

Les fonctions réseau optionnelles. C'est le point délicat. Dans Ollama, la web search fait partie des « cloud features » : si vous l'activez, les requêtes de recherche du modèle partent vers un service externe. Un détail important : c'est un outil du modèle — votre prompt reste sur votre machine, mais la requête que le modèle choisit de chercher part sur le réseau. Ce n'est pas la même chose qu'un chatbot dans le cloud, où tout le texte va au fournisseur.

Et là vous avez le contrôle complet : Ollama se met en mode « local only », avec les cloud features désactivés totalement. Vous réglez disable_ollama_cloud: true dans ~/.ollama/server.json (ou la variable d'environnement OLLAMA_NO_CLOUD=1) et vous redémarrez Ollama. Dans les logs, vous pouvez vérifier que le cloud est désactivé : à partir de ce moment, aucune requête ne part sur le réseau.

Le concept clé : télémétrie vs données

C'est ici que se trouve le piège le plus courant. La télémétrie, ce sont les données que le logiciel envoie pour dire « ce que j'ai fait » — version, type d'erreur, métriques d'utilisation. Les données de contenu, en revanche, sont vos informations : les prompts, les documents, les fichiers. Un logiciel peut envoyer de la télémétrie sans jamais toucher vos données, et peut n'envoyer rien du tout. Les deux choses ne sont pas automatiquement liées : le fait qu'un programme n'envoie pas de télémétrie ne garantit pas que vos données ne partent pas par une fonction optionnelle, et vice-versa.

C'est pourquoi, lorsque vous lisez une politique de confidentialité, la question à poser est toujours la même : quelles données partent, et dans quelles conditions ? Pas « le programme est en ligne oui ou non ? ».

Votre point d'accès : le localhost

Tout ce qui tourne en local se connecte entre lui à travers le localhost, l'interface réseau de votre propre ordinateur (127.0.0.1). Ollama y écoute, LM Studio y écoute, les l'interface web et les applications s'y connectent. C'est la raison pour laquelle un pare-feu bien configuré est le premier outil de défense : si l'interface locale n'est pas joignable de l'extérieur, même un malware sur votre ordinateur ne peut pas « voler » vos prompts en les envoyant vers un serveur distant sans que vous le remarquiez. Le pare-feu dit qui peut parler avec qui — et c'est exactement la question que vous devez vous poser.

Comment vérifier vous-même : trois outils

La bonne nouvelle est que vous n'avez pas à vous fier à quiconque : vous pouvez mesurer vous-même ce qui part sur le réseau. Trois outils, tous gratuits et open source.

tcpdump est l'outil en ligne de commande : il capture les paquets qui traversent votre interface réseau et les affiche un par un. C'est la voie la plus directe pour répondre à la question « qui parle avec l'extérieur ? ». Vous l'installez avec le gestionnaire de paquets de votre système et vous l'activez avec un filtre pour ne voir que les connexions sortantes. Le manuel est bref et clair : quelques secondes pour comprendre ce qui se passe.

Wireshark est la version avec interface graphique : il capture le trafic et l'affiche dans un panneau navigable, avec filtres, couleurs et statistiques. C'est l'outil qui vous fait « voir » le réseau. Sur une machine avec votre configuration locale, un filtre comme tcp.port == 11434 vous montre en temps réel les connexions au serveur d'Ollama. Si le trafic local va et vient entre vos programmes et ne vient pas de l'extérieur, vous avez votre réponse.

mitmproxy est le plus puissant des trois : c'est un proxy qui intercepte et affiche les contenus des requêtes HTTPS en clair. C'est le bon outil quand vous voulez savoir non seulement qui parle avec qui, mais ce qu'ils se disent. Vous le placez entre votre système et l'extérieur, et chaque requête passe par lui : vous voyez les adresses, les en-têtes, les textes. Pour comprendre si une application envoie ou non vos contenus vers un endpoint distant, mitmproxy est l'outil définitif.

La procédure de vérification, étape par étape

1. Démarrer la capture. Avec tcpdump, Wireshark ou mitmproxy, enregistrez tout le trafic sortant de votre machine.
2. Fermer tout le reste. Arrêtez les navigateurs, les mises à jour automatiques, les applications qui font des requêtes en arrière-plan : vous voulez isoler votre configuration d'IA.
3. Démarrer le modèle en local et faire une conversation brève, comme vous le feriez normalement.
4. Regarder le trafic. Vous devriez voir des connexions de système (DNS, NTP) mais aucune connexion qui porte votre texte vers un domaine de tierces parties.
5. Répéter avec les fonctions optionnelles activées (par exemple la web search) et comparer : maintenant vous voyez les requêtes partir vers les moteurs de recherche. C'est exactement le comportement que vous attendiez — et vous l'avez vu, on ne vous l'a pas simplement raconté.

Fait cela, vous avez une connaissance vérifiable de ce qui part sur le réseau depuis votre configuration d'IA locale. C'est là que se trouve la différence entre la foi et le contrôle.

Erreur courante : l'application qui « utilise l'IA locale » mais envoie tout dans le cloud

Un cas qui revient souvent : une application qui présente comme « IA locale » un modèle qui tourne en réalité sur un serveur distant, ou une application qui envoie votre prompt à une API de l'éditeur et le renvoie « depuis l'IA locale ». Le moyen de le reconnaître est toujours le même : observer le trafic. Si votre texte part vers un domaine qui n'est pas le votre, le modèle n'est pas local — ou du moins, il ne l'est pas vraiment pour vos données.

Verdict

L'IA locale, bien configurée, n'envoie pas vos contenus sur le réseau. Vos prompts restent sur votre machine, les poids du modèle restent sur votre disque, et les seules communications réseau sont celles que vous avez activées et que vous pouvez désactiver en un instant.

Mais « bien configurée » n'est pas un fait : c'est une vérification que vous faites vous, avec les bons outils, en une demi-heure. Et une fois que vous l'avez faite, vous n'avez plus à vous fier à une promesse : vous savez ce qui part, et vous savez pourquoi.

Sources

• FAQ officielle d'Ollama — docs.ollama.com/faq
• Web search d'Ollama (outil réseau optionnel) — docs.ollama.com/capabilities/web-search
• tcpdump — manuel officiel — www.tcpdump.org/manpages/tcpdump.1.html
• Wireshark — wireshark.org
• mitmproxy — mitmproxy.org

Article généré par IA