Un développeur chinois qui publie sous le nom de ferstar faisait le ménage dans son disque dur le 18 septembre, pour récupérer de la place. Il tombe sur un fichier qu'il n'a pas créé : 313 mégaoctets, chiffré, dans un dossier en rapport avec ZCode, un agent de code qui vit sur son bureau comme Claude Code vit sur le mien. Il le supprime. Il revient une demi-heure plus tard, tout seul, reconstitué à l'identique.

Ce qu'il y a dedans, c'est son travail. Tout son travail. Et il a passé les jours suivants à démonter le logiciel pour comprendre qui l'embarquait, quand, et vers où.

ZCode, c'est l'outil de bureau de Zhipu, la boîte derrière GLM, dont je te parlais justement hier à propos de la nouvelle version FlashX deux fois et demie plus chère. Ils vendent donc un agent qui écrit du code dans tes projets. Et visiblement, il a un avis assez large sur ce qui t'appartient.

Ce qu'il y a dans les 313 mégaoctets

Le chercheur a analysé l'archive, et la répartition dit tout. Sur un projet de 345 mégaoctets, 46 mégaoctets seulement sont du code et des documents de travail. Le reste, plus de 86 pour cent, c'est le dossier caché .git : 196 mégaoctets de gros fichiers, et 102 mégaoctets d'objets et d'historique.

Un mot sur ce dossier, parce que c'est le cœur du problème. Quand tu suis ton code avec Git, ce répertoire contient non seulement tes fichiers actuels, mais aussi toutes les versions précédentes, les branches que tu as abandonnées sans jamais les envoyer, l'historique de chaque correction, et souvent les traces de choses que quelqu'un a commitées puis retirées. Un dépôt Git, c'est ta maison plus les cartons au grenier que tu n'as jamais ouverts. Et sous le plafond, il y a parfois les clés.

Sur une seconde machine, le même outil a fabriqué un manifeste de 7 946 fichiers pour 758 mégaoctets, avec le dossier .git à 98,91 pour cent du total. Les filtres du logiciel écartent bien les node_modules, les fichiers .env, les clés privées et les fichiers dont le nom contient « token » ou « secret ». Ils n'écartent jamais .git.

Le camion part à la nuit tombée. Personne ne lui a rien demandé, et il revient demain

Où ça part, et comment c'est emballé

Direction un espace de stockage chez Alibaba, le géant chinois du nuage. L'archive est chiffrée en deux temps, avec une clé symétrique pour le contenu et une clé publique envoyée par le serveur pour emballer cette clé-là. Traduction pratique : la clé qui ouvre le paquet n'existe que côté serveur. Toi, tu as un fichier illisible sur ton disque, et aucune façon de savoir ce qu'il y a dedans ni de le déchiffrer.

Le mécanisme d'envoi est encore plus gênant que le contenu. Un petit programme démarre à l'ouverture de session et reste là, en permanence. Il prend un instantané de ton espace de travail juste avant chaque requête que tu envoies à l'agent, et une fois de plus à la fin du travail. Sur une seule session d'écriture de code, le chercheur a compté 62 déclenchements. Son journal d'erreurs enregistre 564 tentatives d'envoi qui ont échoué et recommencé.

Et là, la question qui tue : les interrupteurs dans l'interface. Il y en a trois. Celui qui contrôle l'usage de tes données pour l'entraînement. Celui qui contrôle l'indexation de ton dépôt côté serveur. Celui de la mémoire de l'agent. Le chercheur les a coupés tous les trois, et l'archive a continué d'arriver. Parce que ces réglages décident de ce que le serveur fait de ce qu'il reçoit, pas de ce que ton ordinateur lui envoie.

Un joli panneau, et un paquet de câbles coupés qui ne mènent nulle part. Tu peux basculer ce que tu veux, ça ne coupe rien

La réponse de Zhipu

Il faut leur reconnaître une chose : ils ont répondu vite. L'éditeur a présenté des excuses, expliqué que les instantanés servent à deux choses, la restauration de ton espace de travail après une erreur et la fabrication automatique d'une documentation de ton projet, et affirmé que les données côté serveur sont détruites une fois la page générée. Ils se sont engagés à publier le code du client et à le faire auditer par un tiers.

Le problème, c'est ce que dit leur propre politique de confidentialité, qui n'a pas été réécrite depuis. Le traitement passe principalement par des serveurs à Singapour, les données concernées incluent le texte, la configuration et les commandes tapées dans le terminal, et elles sont conservées aussi longtemps que le compte existe. Nulle part il n'est écrit que l'historique Git complet du dépôt est extrait. On ne peut donc pas dire que c'est caché, mais on peut dire que ce n'était pas dit.

Un deuxième développeur a reproduit la chose sur la version 3.12.3, et un utilisateur sous Windows a vu 32 espaces de travail instantanés coup sur coup, jusqu'à 107 mégaoctets pour le plus gros paquet. Ce n'est pas un cas isolé ni une machine bizarre. Et ce n'est pas la première fois cette année : en juillet, un outil de code de xAI, Grok Build, avait déjà été épinglé pour des remontées du même genre.

Ce que tu fais si tu utilises un agent de code

D'abord, si tu as ZCode installé, tu peux rendre le dossier des instantanés impossible à écrire au niveau du système, ce qui est la seule parade vraiment efficace :

# Linux
sudo chattr +i ~/.zcode/v2/checkpoints

# macOS
chflags uchg ~/.zcode/v2/checkpoints

# Windows, en PowerShell, dossier en refus d'écriture
icacls "$env:USERPROFILE\.zcode\v2\checkpoints" /deny "%USERNAME%:(W)"

Et ne compte pas sur la suppression du fichier déjà là, il se refabrique tout seul en une demi-heure. Tourne aussi tes identifiants qui auraient pu traîner dans un vieux commit, et évite de faire tourner ce genre d'outil sur ton dépôt principal avec ton compte personnel.

Le cadenas est solide. Le problème, c'est que ce n'est pas toi qui tiens la clé

Ensuite, et c'est le vrai enseignement, il n'y a pas que ZCode. Un agent de code, c'est un programme qui lit tes fichiers, les modifie et exécute des commandes chez toi. Pour faire son travail, il doit forcément voir beaucoup. La question n'est pas de savoir s'il voit, mais ce qu'il en sort, et si c'est écrit quelque part en clair. Anthropic a eu la même leçon il y a trois jours sur Claude Code, avec un contrôle des permissions qui avait deux angles morts.

Ma règle à moi est simple depuis longtemps, et elle ne dépend d'aucun réglage dans aucune interface : ce qui ne doit pas sortir ne se trouve pas dans un dossier sur lequel un agent travaille. Les secrets dans un fichier de configuration à part, hors du dépôt. Les dépôts clients sur une machine, les miens sur une autre. Ce n'est pas de la paranoïa, c'est la seule défense qui reste quand le bouton « arrêter d'envoyer » ne fait rien.

Reste une question que personne n'a posée à Zhipu, et qui me gêne plus que le reste. Ils ont promis d'ouvrir le code du client et de le faire auditer. Très bien. Mais combien de temps ces 313 mégaoctets ont-ils dormi chez Alibaba, et combien d'autres archives du même genre dorment encore là-bas, pour des gens qui n'ont jamais rien remarqué ?