Une IA sur votre ordinateur ne veut pas dire que vos données restent chez vous

Vous avez installé un modèle sur votre machine. Plus de nuage, plus d'envoi, tout reste ici : c'est la phrase que vous vous êtes dite en lançant Ollama. Deux jours plus tard, vous testez une fonction « recherche web » par curiosité. Le texte de travail, lui, n'a peut-être plus tout à fait le même statut.

L'idée n'est pas de renoncer aux outils locaux. C'est de savoir ce qui sort encore de l'ordinateur, et dans quels cas. « Tourne sur mon PC » décrit le lieu de calcul. Ce n'est pas une politique de confidentialité complète.

Ce que « local » veut dire, et ce qu'il ne veut pas dire

Ollama le formule clairement dans sa FAQ officielle : l'outil tourne en local, et l'éditeur ne voit pas vos prompts ni vos données quand vous exécutez un modèle localement. La même FAQ précise le revers : dès que vous utilisez des modèles hébergés dans le cloud ou la recherche web, le contenu de la requête est traité pour fournir le service. Vous pouvez couper ces fonctions cloud (OLLAMA_NO_CLOUD=1 ou disable_ollama_cloud dans ~/.ollama/server.json). Tant que vous ne l'avez pas fait, « local » et « cloud » cohabitent dans le même binaire.

La politique de confidentialité d'Ollama (mise à jour mars 2026) ajoute un détail souvent sauté : des métadonnées d'usage limitées (version, compteurs) peuvent être collectées, sans le contenu des prompts. Ce n'est pas vos secrets. Ce n'est pas zéro trafic non plus.

Le modèle lui-même a déjà été entraîné ailleurs, sur d'autres données. Votre enjeu immédiat, ce n'est pas l'entraînement d'origine. C'est ce que votre usage envoie pendant que vous travaillez.

Ce qui peut quitter la machine malgré tout

Selon l'outil, une installation « locale » peut encore : vérifier une licence en ligne, télécharger une extension, envoyer un rapport d'erreur, exiger un compte, ou s'appuyer sur un service distant pour une brique du pipeline (voix, OCR, recherche). Votre texte de travail peut rester sur le disque. Une métadonnée, un extrait de log, ou une requête annexe peut partir ailleurs. Ce n'est pas toujours malveillant. C'est souvent écrit dans une page que personne ne lit.

Ollama, toujours dans la même FAQ, écoute par défaut uniquement sur votre machine (127.0.0.1, port 11434). Tant que vous ne changez pas OLLAMA_HOST, le serveur n'écoute pas le réseau local. Le jour où vous l'exposez « pour que le portable de la maison y accède », vous changez le périmètre. Local sur une machine n'est pas local sur un salon entier.

Sauf que le sentiment de contrôle arrive plus vite que la checklist. L'icône « offline » de l'interface n'est pas une preuve. Un test réseau, si.

Trois vérifications concrètes avant d'y coller des données sensibles

• Mode hors ligne forcé : coupez le réseau (avion, câble retiré) et testez la fonction dont vous avez besoin. Ce qui casse dépendait du réseau. Ce qui continue peut, à ce stade, être traité comme local pour cet usage-là.
• Permissions et compte : faut-il un compte ? Une télémétrie activée par défaut, à désactiver ? Une fonction cloud allumée dans un menu ? Notez-le avant d'y coller un contrat, un dossier médical, une liste de clients.
• Périmètre des fichiers : l'outil lit-il seulement le dossier choisi, ou indexe-t-il large par défaut ? Un assistant local qui « voit tout le disque » n'est plus un modèle. C'est un lecteur.

Ces trois gestes tiennent en une pause café. Ils évitent de découvrir, trop tard, qu'une brique « pratique » renvoyait des extraits. Pour un agent auto-hébergé qui touche aussi vos mails et votre navigateur, le tutoriel trois façons d'héberger un agent open source pose la même question d'accès, avant celle du modèle. Local plus puissant veut souvent dire local plus exposé, si les permissions suivent.

Dernier point, souvent oublié : le disque. Un modèle local laisse des traces (cache, historique, embeddings, fichiers temporaires). Chiffrer le disque, verrouiller la session, et savoir où l'outil écrit, ça fait partie de « rester chez vous ». Autant que le choix du modèle.

Questions fréquentes