Ilustración editorial para IA local y privacidad: cómo comprobar qué datos salen de tu equipo
Imagen generada con gpt-image-2.5-sunburst para InferamaSource ↗
01

Ce que signifie réellement « local »

Le terme « local » peut décrire plusieurs réalités différentes : l’emplacement des poids du modèle, le lieu où une réponse est calculée ou les parties du flux de travail qui se déroulent sur l’ordinateur. Ces conditions ne sont pas équivalentes. Un modèle peut avoir été téléchargé et s’exécuter sur l’ordinateur tandis que l’application consulte un service externe pour une fonction facultative, vérifie la disponibilité de mises à jour ou recherche des modèles. Il est également possible qu’une application envoie une requête à un serveur d’inférence exécuté sur le même appareil, tout en conservant les conversations ou les journaux dans des fichiers accessibles à d’autres utilisateurs du système.

La question utile n’est donc pas seulement « le modèle est-il local ? », mais « quels composants interviennent dans cette tâche, quelles données chacun reçoit-il et de quels éléments dispose-t-on pour vérifier leur comportement ? ». Le périmètre à examiner comprend l’interface de chat, le processus qui charge le modèle, les outils activés, les extensions, les connexions réseau, le stockage et les sauvegardes. L’évaluation porte sur une configuration précise : version de l’application, paramètres, système d’exploitation, modèle installé et actions effectuées.

Exécuter l’inférence sur l’appareil peut réduire la nécessité d’envoyer le prompt à un fournisseur distant pour cette opération. Cela ne prouve toutefois pas que l’application dans son ensemble fonctionne sans connexion. Cela ne protège pas non plus automatiquement les informations des autres comptes ayant accès à l’appareil, des logiciels malveillants, de permissions trop larges ou de fichiers conservés après la fermeture de l’application. Il faut distinguer l’emplacement du calcul, le parcours des données et la sécurité de l’appareil.

Trois questions à ne pas confondre

QuestionCe qu’elle cherche à établirCe qu’elle ne démontre pas à elle seule
Où se trouvent les poids du modèle ?Si le fichier du modèle se trouve sur l’appareil ou dans un stockage distant.Que toutes les requêtes, fonctions ou tous les journaux soient locaux.
Où la réponse est-elle calculée ?Si l’inférence de cette requête a lieu sur l’appareil ou sur un service distant.Qu’il n’existe aucune autre connexion ou aucun traitement supplémentaire.
Où vont les données de l’ensemble du flux ?Quels composants reçoivent les prompts, les documents, les résultats et les métadonnées.Que l’appareil soit protégé contre les autres utilisateurs ou processus.
02

Cartographiez le parcours avant de tester

Dressez l’inventaire des éléments qui interviennent, et pas seulement du modèle. Commencez par l’application qui affiche le chat, le serveur d’inférence, le modèle et son gestionnaire de téléchargement. Ajoutez ensuite la recherche sur le Web, les outils, les extensions, les modules complémentaires, les vérifications de mises à jour et les options susceptibles d’utiliser des services cloud. Si une application permet de basculer entre des modes locaux et distants, notez le mode actif pour chaque essai. L’étiquette affichée à l’écran ne remplace pas la vérification de la configuration réellement utilisée.

Pour chaque élément, notez les informations qu’il pourrait recevoir. Un prompt peut contenir du texte sensible ; un document joint peut être lu par un outil ; une recherche peut transmettre une requête ; un journal peut conserver les entrées et les sorties. Ne supposez pas que toutes ces données sont traitées de la même manière. Un service qui calcule une réponse, une fonction qui consulte Internet et un fichier d’historique sont des destinations et des surfaces d’exposition différentes.

L’inventaire doit distinguer les activités. Télécharger un modèle, installer une extension, saisir un prompt, joindre un fichier, lancer une recherche et vérifier les mises à jour sont des actions distinctes. Si vous les effectuez toutes en même temps, il sera difficile d’attribuer clairement une variation du trafic. La méthodologie de caractérisation du réseau du NIST fournit une base pour organiser les observations autour d’activités définies à l’avance. Son rapport porte sur les appareils de l’Internet des objets : il est donc ici adapté comme méthode de test, et non comme certification des applications d’IA.

Inventaire initial

  1. 01Notez le système d’exploitation, la version de l’application, les paramètres, le modèle et les fonctions activées.
  2. 02Énumérez les processus, les services, les extensions et les outils qui font partie du flux.
  3. 03Associez à chaque action ses entrées possibles : prompt, fichier, requête de recherche, résultat ou métadonnées.
  4. 04Séparez les actions de préparation — téléchargements et installations — de l’utilisation ordinaire.
  5. 05Notez ce que vous vous attendez à observer et l’observation concrète qui pourrait confirmer ou réfuter cette attente.
03

Effectuez un test contrôlé hors ligne

Un test sans Internet permet de déterminer quelles fonctions restent disponibles après la préparation de l’environnement. Il ne prouve pas qu’aucune transmission n’a jamais eu lieu. Avant de vous déconnecter, installez l’application, téléchargez le modèle à évaluer et préparez les documents de test. Notez les ressources obtenues pendant cette phase. Si le produit propose une recherche, des téléchargements à la demande ou des outils distants, identifiez-les comme des fonctions distinctes du chat de base.

Déconnectez l’appareil d’Internet selon une méthode vérifiable et consignez l’état de la connexion. Testez séparément une conversation simple avec le modèle déjà chargé, une requête portant sur un document local et chaque fonction facultative qui vous intéresse. Notez si la tâche aboutit, échoue avec un message, reste en attente ou produit un résultat partiel. Répétez chaque essai dans des conditions similaires et évitez de modifier plusieurs options entre deux essais.

Formulez le résultat en précisant ses limites. Si une conversation fonctionne hors ligne, vous pouvez conclure que cette tâche précise a fonctionné dans cette configuration pendant le test. Vous ne pouvez pas en déduire que l’application ne transmet jamais de données, qu’elle ne se connectera pas après le rétablissement du réseau ou qu’un autre mode d’utilisation se comportera de la même façon. Si une fonction échoue, cela indique que l’opération testée n’était pas disponible hors ligne dans ces conditions ; cela ne permet pas, à lui seul, d’identifier les données qui auraient été envoyées ni leur destination.

La documentation de LM Studio, par exemple, distingue les tâches qu’elle déclare disponibles hors ligne, comme le chat et le travail sur des documents, des actions qui déclenchent des requêtes réseau, comme la recherche ou le téléchargement de modèles et la vérification des mises à jour. Cette documentation illustre la façon dont une application peut décrire ses modes. Elle ne remplace pas la vérification de l’appareil, de la version et des paramètres précis que vous évaluez.

04

Observez le trafic activité par activité

Le test le plus instructif consiste à séparer les événements et à prendre des notes avant, pendant et après chacun d’eux. Consignez les connexions au repos, puis lancez le programme, chargez le modèle, envoyez un prompt de test, joignez un document sans données sensibles, activez une recherche, installez une extension et vérifiez les mises à jour. Ne regroupez pas toutes ces étapes dans une seule session si vous devez attribuer les connexions observées. Répétez les actions importantes pour vérifier si le même schéma réapparaît.

Notez le moment, l’action, le processus associé si vous pouvez l’identifier, la destination visible et la durée approximative. Conservez également la configuration exacte et tout message d’erreur. La constatation d’une connexion ne suffit pas à établir le contenu qui a circulé ; le nom d’une destination ne prouve pas, à lui seul, le traitement appliqué aux données. Si vous ne pouvez pas examiner le contenu, consignez cette limite et évitez de combler le manque par une supposition.

Comparez trois situations : l’application inactive, l’utilisation de base et chaque fonction facultative. Si une connexion apparaît pendant une mise à jour ou un téléchargement, séparez-la du test du prompt. Si vous n’observez aucun trafic pendant un essai, limitez votre conclusion à cet essai et aux outils d’observation utilisés : une capture ponctuelle peut ne pas détecter des connexions intermittentes, différées ou lancées par un autre composant. Pour une évaluation plus importante, demandez à une personne compétente de documenter la méthode et de répéter le protocole.

Journal d’observation minimal

ChampÉléments à noterPourquoi c’est important
ActivitéAction exacte, comme charger le modèle ou envoyer le prompt de test.Permet de relier une observation à un événement.
MomentHeure de début et de fin, ainsi que le fait que l’application soit inactive ou non.Permet de distinguer les connexions en arrière-plan de l’activité déclenchée.
ObservationProcessus, destination visible, durée et outil de capture.Rend l’examen reproductible sans attribuer un contenu qui n’a pas été observé.
LimiteÉléments qui n’ont pas pu être déterminés, comme le contenu transmis ou le processus à l’origine de la connexion.Évite de présenter une déduction comme un fait vérifié.
05

Vérifiez les historiques, les journaux et les permissions

La confidentialité ne s’arrête pas au moment où la réponse est générée. Cherchez où sont enregistrés les conversations, les documents temporaires, les caches et les journaux. Examinez les paramètres de l’application ainsi que les fichiers qu’elle crée, puis vérifiez quels comptes du système peuvent les lire. Tenez également compte de la synchronisation des dossiers, des sauvegardes et des outils de diagnostic s’ils sont utilisés sur cet appareil. Ne supposez pas que fermer une fenêtre équivaut à effacer les données, ni qu’une option de nettoyage couvre tous les composants.

À titre d’exemple précis, la documentation de LM Studio indique que les conversations sont enregistrées dans des fichiers JSON et décrit des emplacements de stockage pour différents systèmes d’exploitation. Sa documentation sur la commande de flux des journaux précise que ceux-ci peuvent afficher le texte d’entrée et de sortie du modèle et du serveur. Ces informations sont utiles pour examiner cette application et sa configuration ; elles ne doivent pas être extrapolées automatiquement à d’autres environnements d’exécution.

Avant d’introduire des informations sensibles, testez la suppression avec des données fictives : repérez les fichiers avant et après, utilisez la méthode documentée, puis vérifiez ce qui subsiste. Si le produit n’explique pas où les données sont stockées ni comment les supprimer, consignez cette incertitude et demandez des précisions au fournisseur ou à la personne chargée de l’administration du système. Limiter les permissions du compte qui exécute l’application peut réduire le nombre de personnes ayant accès aux fichiers. Cela ne remplace toutefois pas les contrôles du système, le chiffrement lorsqu’il est pertinent ni une politique de conservation.

06

Un serveur sur l’appareil peut être accessible depuis le réseau

Une API locale permet à une application cliente d’envoyer des requêtes au serveur d’inférence. Le terme « local » peut désigner le fait que le processus s’exécute sur votre ordinateur, mais c’est l’interface réseau sur laquelle il écoute qui détermine depuis où il est joignable. Un service limité à une interface de bouclage est destiné aux requêtes provenant du même appareil ; un service accessible par une interface réseau peut accepter des connexions d’autres appareils, selon sa configuration et les règles du réseau. Vérifiez le comportement réel au lieu de le déduire du mot « local ».

Examinez l’adresse d’écoute, le port, les options d’accès au réseau et les mécanismes d’authentification. Vérifiez si un autre appareil du réseau peut joindre le service et lui envoyer des requêtes sans identifiants. Effectuez ces contrôles uniquement dans un environnement autorisé, avec un modèle et du contenu de test. Une réponse du serveur ne prouve pas que tous ses outils sont isolés : vérifiez séparément les fichiers, fonctions ou extensions auxquels le client qui envoie les requêtes peut accéder.

La documentation de LM Studio décrit un serveur API local utilisable sur localhost ou sur le réseau. Cette possibilité justifie d’inspecter l’interface et les paramètres actifs ; elle ne prouve pas que toute installation écoute sur le réseau ou y soit exposée par défaut. Si vous n’avez pas besoin d’un accès depuis d’autres appareils, limitez le service à l’appareil lui-même au moyen des options disponibles et des règles du système. Si cet accès est nécessaire, appliquez des contrôles d’accès et limitez les permissions du processus au strict nécessaire.

Vérifier l’exposition du serveur

  1. 01Identifiez le processus qui fournit l’API ainsi que l’interface et le port sur lesquels il écoute.
  2. 02Déterminez si le service accepte uniquement les connexions de l’appareil ou également celles du réseau.
  3. 03Avec l’autorisation nécessaire, essayez d’y accéder depuis un autre appareil à l’aide d’une requête sans risque.
  4. 04Vérifiez si une authentification est exigée et quelles actions l’API permet.
  5. 05Désactivez les accès inutiles, puis répétez la vérification après toute modification de la configuration.
07

Distinguez les faits observés, les déclarations et les questions ouvertes

Un compte rendu utile distingue trois niveaux. Le premier correspond aux observations : par exemple, une fonction précise a échoué hors ligne ou une connexion a été enregistrée pendant une action donnée. Le deuxième correspond aux déclarations du fournisseur dans sa documentation ou ses politiques, comme les fonctions qu’il affirme disponibles hors ligne ou les cas où il dit transmettre des données. Le troisième comprend ce qui n’a pas encore été établi : le contenu d’une connexion chiffrée qui n’a pas été inspecté, le comportement d’une autre version ou l’accès aux fichiers par des processus tiers.

Une politique de confidentialité est une source primaire concernant les déclarations du fournisseur sur son produit, mais elle ne vérifie pas de façon indépendante ce qu’a fait une installation particulière. À l’inverse, une capture du trafic décrit ce qu’un outil a observé durant une période et dans une configuration données, mais elle ne remplace pas une explication contractuelle sur la conservation ou le traitement des données. Combinez les deux types d’éléments et consignez, pour chacun, la date, la version et les conditions.

La matrice ci-dessous aide à éviter les conclusions plus générales que les tests ne le permettent. Si le résultat dépend d’un paramètre, consignez à la fois l’état observé et la valeur exacte de ce paramètre. Si vous ne pouvez pas reproduire une observation ou en identifier l’origine, classez-la comme non résolue. Pour les décisions à haut risque, une évaluation informelle ne remplace pas l’examen des exigences de sécurité, de confidentialité et des obligations légales applicables.

Matrice de communication des résultats

Élément de preuveConclusion prudenteConclusion qui n’est pas étayée
La tâche a abouti alors que le réseau était déconnecté.Cette tâche a fonctionné hors ligne dans la configuration testée.L’application ne transmet jamais de données.
Une connexion a été observée pendant une recherche.Une connexion a eu lieu à peu près au moment de cette activité.Le prompt entier a été envoyé à une destination précise, si le contenu n’a pas été observé.
La documentation indique qu’une fonction fonctionne hors ligne.Le fournisseur décrit cette fonction comme disponible hors ligne.L’installation évaluée s’est comportée exactement ainsi, sans test.
Aucun trafic n’a été détecté pendant une session.L’outil utilisé n’a observé aucun trafic pendant cet essai.Aucune communication réseau n’a eu lieu à aucun moment.
08

Liste de contrôle avant d’utiliser des données sensibles

La décision finale ne devrait pas dépendre d’une étiquette commerciale ni d’un test unique. Tenez compte du type de données, de l’impact d’une divulgation, des fonctions réellement nécessaires, de l’accès physique et logique à l’appareil, du niveau de preuve recueilli et de votre capacité à effacer ou à contrôler les journaux. Si vous ne pouvez pas éclaircir une question importante, ne la transformez pas en hypothèse favorable : réduisez le périmètre d’utilisation, désactivez la fonction incertaine ou suspendez l’évaluation jusqu’à l’obtention d’une réponse vérifiable.

Pour garder le contrôle, conservez un bref relevé de la configuration et du protocole. Répétez les tests après les mises à jour importantes, les changements d’extensions ou les modifications du réseau, car le résultat décrit la configuration testée, et non toutes les configurations futures. Conservez les captures ou notes après en avoir retiré les données sensibles et limitez les personnes qui peuvent les consulter. Si un envoi inattendu est détecté, interrompez l’utilisation de données réelles, préservez les éléments non sensibles et demandez un examen technique avant de reprendre.

Utilisez cette liste comme seuil pratique de vérification, et non comme certification de confidentialité. Pour explorer les modèles locaux, consulter des comparatifs ou découvrir d’autres outils, vous pouvez commencer par les guides sur les modèles locaux, les comparatifs et le catalogue de découverte d’Inferama ; l’évaluation de la confidentialité doit toutefois porter sur l’application et la configuration que vous comptez utiliser.

Contrôles minimaux pour clore l’évaluation

  1. 01Définissez les informations sensibles et commencez les tests avec des données fictives.
  2. 02Identifiez les fonctions locales, distantes et facultatives, puis désactivez celles dont vous n’avez pas besoin.
  3. 03Répétez les tests hors ligne et les observations du trafic pour chaque activité.
  4. 04Repérez les historiques, les journaux et les fichiers temporaires ; vérifiez les permissions et la suppression.
  5. 05Vérifiez l’interface d’écoute et l’accès au serveur depuis d’autres appareils.
  6. 06Consignez séparément les résultats, les déclarations du fournisseur et les questions encore sans réponse.
  7. 07Interrompez l’utilisation de données sensibles en cas de trafic inattendu ou si vous ne pouvez pas limiter une exposition importante.

Questions ouvertes

  • Le comportement du réseau, du stockage et des permissions dépend de l’application, de sa version, du système d’exploitation et de la configuration précise.
  • Les sources disponibles ne déterminent pas le comportement de toutes les applications d’IA locale ni de toutes les extensions.
  • Un test ponctuel peut ne pas détecter des communications intermittentes, différées ou lancées par un autre processus.
  • L’observation des destinations réseau ne révèle pas nécessairement le contenu transmis ni son traitement ultérieur.
  • Les déclarations du fournisseur sur la confidentialité ne constituent pas une vérification indépendante d’une installation donnée.
  • L’accessibilité d’un serveur API doit être vérifiée dans l’environnement évalué ; elle ne peut pas être déduite de la seule documentation générale.
09

Poursuivre l’exploration

09

Sources consultées

03

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.

Proposer une correction