Ce que votre assistant IA envoie à l'extérieur : audit du trafic avec mitmproxy

```html

Le 11 août 2026, une analyse a circulé sur Hacker News, qu'il vaut la peine de lire pour quiconque utilise un assistant AI dans son IDE : un chercheur a configuré VS Code avec GitHub Copilot derrière un proxy interceptant et a observé ce qui était envoyé aux serveurs. Il s'est avéré que la requête contenait bien plus que la ligne que vous complétez, y compris le contenu du fichier .env en clair.

Bonne nouvelle : n'importe qui peut vérifier cela, et pas seulement avec Copilot. Ci-dessous se trouve un guide pratique sur la façon de mettre en place un audit du trafic de votre assistant en 20 à 30 minutes, ce qu'il faut rechercher dans les requêtes interceptées et quelles sont les limitations des mécanismes d'exclusion de fichiers par défaut.

Pourquoi le faire soi-même

La documentation du fournisseur décrit la politique, et non le comportement réel du client. Entre « nous n'utilisons pas votre code pour l'apprentissage » et « le client n'envoie pas votre code au serveur » — il y a un fossé : pour générer une suggestion, le modèle doit obtenir le contexte, et la question est de savoir à quel point le client collecte ce contexte.

Un audit est nécessaire si vous :

• travaillez sous NDA ou avec des données personnelles de clients et devez savoir ce qui sort du périmètre ;
• conservez des secrets, des configurations d'environnement, des adresses internes et des tokens dans votre dépôt ;
• êtes responsable de la conformité au sein de votre équipe et avez besoin d'un journal des requêtes réelles, pas d'une capture d'écran des paramètres ;
• voulez simplement comprendre pourquoi l'assistant « sait » soudainement quelque chose sur un fichier que vous n'avez pas ouvert.

Ce que nous avons trouvé dans le trafic de Copilot

L'analyse en question s'appuyait sur le classique mitmproxy : VS Code a été dirigé vers un proxy local sur le port 8080 et la vérification stricte des certificats a été désactivée. Voici les principales découvertes :

• Le contexte est plus large qu'un seul fichier. Lors des compléments en ligne, le client collecte jusqu'à 20 fichiers, 8 résumés des dernières modifications et 3 lignes de contexte autour de chaque changement, plus le texte complet du fichier actuel et les fichiers récemment modifiés sous forme de diff.
• Les secrets ne sont pas masqués. Dans le corps de la requête, le champ prompt contenait une chaîne de type TEST_ENV_VAR_SECRET="mysecretenvvar" — c'est-à-dire que les variables d'environnement du fichier ouvert étaient envoyées en texte clair.
• La base de données locale est également ouverte. Le fichier session-store.db stocke user_message et assistant_response sans cryptage ni modification : il contenait des tokens, des clés de fournisseurs de cloud et des mots de passe des chaînes de connexion que vous avez un jour insérées dans le chat.
• Appels de service. En plus des compléments eux-mêmes, le client interroge /models, /agents/swe/models, /models/session/intent et les points de terminaison OAuth de GitHub — cela montre bien comment l'assistant classe votre requête avant même de générer une réponse.

Il convient de se rappeler que le client envoie au serveur l'URL du dépôt actuel pour obtenir la politique d'exclusion applicable. Ce fait en soi n'est pas problématique, mais cela signifie que la composition de votre arbre de travail est également un signal.

Étape par étape : mettre en place l'interception

1. Installez mitmproxy et lancez-le. L'interface web suffit : mitmweb. Par défaut, le proxy écoute sur le port 8080, et la console s'ouvre dans le navigateur. Pour CI et les longues sessions, mitmdump est plus pratique.
2. Installez le certificat racine. Lors de la première exécution, mitmproxy crée une CA dans le répertoire ~/.mitmproxy (fichier mitmproxy-ca-cert.cer). Il doit être ajouté aux certificats de confiance — sinon, le client interrompra la connexion TLS. Pendant l'audit, il suffit d'une confiance au niveau utilisateur ; après, supprimez le certificat, ne laissez pas de CA étrangère dans le système « au cas où ».
3. Choisissez le mode d'interception. Il y en a trois, et un bon choix vous fera gagner une heure :
   • regular — proxy classique, le client doit être configuré explicitement. C'est l'option la plus prévisible.
   • local — interception transparente des applications sur la même machine, sans modification des paramètres du programme : mitmproxy --mode local:Code ne capturera que le processus VS Code, --mode local:42 — le processus avec le PID spécifié, --mode local:!curl — tout sauf curl. C'est le meilleur moyen d'écouter un assistant qui n'a pas de configuration proxy.
   • upstream — chaîne où mitmproxy est derrière votre propre proxy : mitmdump --mode upstream:http://host:8081, et le login et le mot de passe sont définis par l'option --set upstream_auth=user:pass.
4. Dirigez l'IDE vers le proxy (pour le mode regular). Dans VS Code dans settings.json :
   • "http.proxy": "http://127.0.0.1:8080"
   • "http.proxySupport": "override"
   • "http.proxyStrictSSL": false — seulement pendant l'audit. Ce drapeau désactive complètement la vérification des certificats, et il ne faut pas le laisser dans la configuration de travail.
5. Résolvez le problème de certificat de manière appropriée. L'extension Copilot fonctionne sur Node, donc le bon chemin est de ne pas désactiver la vérification, mais de rassembler le PEM avec les CA racines plus le certificat mitmproxy et de le spécifier via la variable d'environnement NODE_EXTRA_CA_CERTS. L'IDE doit être redémarré : la variable est lue au démarrage du processus.
6. Écrivez le flux dans un fichier. Regarder en temps réel est inutile — il y a des dizaines de requêtes par minute. Activez --set save_stream_file=flows.dump, et pour ne pas tout collecter, limitez l'échantillonnage via --set save_stream_filter=.... Ensuite, le fichier peut être analysé hors ligne.
7. Recherchez dans le corps de la requête, pas dans l'URL. Une astuce pratique : placez dans un dépôt de test un fichier canari avec une chaîne unique (par exemple, CANARY_9f3c_DO_NOT_SEND), ouvrez-le dans l'éditeur, travaillez dans un fichier voisin — et cherchez le canari dans les corps interceptés. Ainsi, vous verrez non pas le rayon théorique de collecte de contexte, mais le rayon réel pour votre version du client.

Pièges

La licence peut bloquer l'interception. Sur les plans d'entreprise, Copilot renvoie une erreur du type « Votre licence Copilot actuelle ne prend pas en charge les connexions proxy avec des certificats auto-signés ». Ce n'est pas un bug du proxy — le client refuse intentionnellement de fonctionner via une CA auto-signée. Cela se résout par un certificat de confiance au niveau du système ou par la construction d'un PEM pour Node ; si la politique de l'organisation l'interdit, l'audit devra être approuvé par l'administrateur, et non contourné.

Pinning et QUIC. Certains clients utilisent HTTP/3 sur QUIC, que le proxy classique ne verra pas. Si après avoir activé l'interception l'application « fonctionne, mais le journal est vide » — la raison est presque toujours celle-ci : bloquez UDP/443 pour le processus de test, et le client reviendra à HTTP/2.

La télémétrie et la charge utile prennent des chemins différents. Ne tirez pas la conclusion « rien ne sort » sur la base d'un seul point de terminaison : regardez toute la liste des hôtes auxquels le processus accède, et pas seulement celui mentionné dans la documentation.

Cadre juridique. Il est possible d'intercepter le trafic sur votre propre machine et sur votre propre compte. Écouter le portable de travail d'un tiers sans le consentement du propriétaire est une autre histoire, et aucune « sécurité » ne justifie cela.

Que faire des résultats

Si l'audit a montré que des fichiers superflus sont inclus dans les requêtes, les outils par défaut apparaissent ainsi — et chacun a une limitation notable.

• Exclusion de contenu. Mécanisme officiel de GitHub qui interdit à Copilot d'utiliser les chemins spécifiés. Disponible uniquement sur les plans Business et Enterprise, configuré par l'administrateur dans les paramètres de Copilot, pris en charge dans VS Code, Visual Studio et JetBrains ; dans Xcode, Eclipse et Vim/Neovim — uniquement pour les suggestions en ligne.
• Le principal problème — le mode agent. La documentation indique clairement que les exclusions ne sont pas prises en charge dans les modes Edit et Agent dans Copilot Chat, ainsi que dans Copilot CLI. C'est-à-dire précisément là où l'assistant parcourt les fichiers, lit les configurations et exécute des commandes, le filtrage de la plateforme ne s'applique pas. Si vous comptez sur l'exclusion de contenu comme unique barrière — il n'y a pas de barrière en mode agent.
• .gitignore ne protège pas. Une idée reçue courante : l'exclusion de l'index Git ne signifie pas exclusion du contexte de l'assistant.
• Minimum organisationnel. Les secrets doivent être dans un gestionnaire de secrets, et non dans un .env à côté du code ; le chat de l'assistant n'est pas l'endroit pour insérer des chaînes de connexion ; la base de données locale d'historique doit être nettoyée tout comme vous nettoyez l'historique du shell.

Où est le proxy et pourquoi en avez-vous besoin

L'interception a une suite pratique. Tout d'abord, le mode upstream permet de faire passer tout le trafic de l'assistant par un nœud de sortie contrôlé : vous voyez simultanément les requêtes et contrôlez l'adresse à partir de laquelle elles partent. Cela est nécessaire lorsque l'API de l'assistant n'est pas accessible depuis votre région ou lorsque la politique d'entreprise exige une IP sortante fixe — pour ce scénario, des proxies de centre de données avec une adresse fixe conviennent.

Deuxièmement, le même environnement sera utile pour le débogage de l'automatisation : lorsque l'agent AI parcourt lui-même les sites, l'interception montre quels en-têtes il envoie réellement et sur quoi les protections l'attrapent. Nous avons examiné cette combinaison dans un article sur les proxies pour les agents AI sur Playwright et MCP — là, nous parlons du choix du type d'adresse pour les scénarios d'agent, où une IP résidentielle est nécessaire, et non une IP serveur.

Si vous n'avez jamais configuré mitmproxy auparavant, commencez par la configuration de base de l'interception HTTPS — elle est décrite en détail dans notre guide sur l'interception du trafic via mitmproxy, et ensuite superposez les modes local et upstream.

Conclusion

L'audit du trafic de l'assistant AI n'est pas de la paranoïa, mais une hygiène d'ingénierie normale qui prend une soirée et se fait une fois. L'analyse de Copilot a montré une image claire : le client collecte le contexte largement, les secrets sont inclus dans ce contexte au même titre que le code, l'historique local est stocké en texte clair, et les exclusions par défaut ne fonctionnent pas précisément dans le mode le plus dangereux — le mode agent.

Vérifiez non pas la documentation, mais le trafic. Mettez en place mitmproxy en mode local, placez un canari dans le dépôt, collectez le flux dans un fichier et voyez par vous-même ce qui sort de votre machine. Ensuite, la solution est simple : soit vous acceptez délibérément ce volume de transmission, soit vous déplacez les secrets en dehors de l'arbre de travail avant qu'ils ne soient vus par un serveur tiers.