ZCode a téléversé des historiques Git entiers ; Zhipu s'excuse
Un instantané atteignait 313 Mo et 42 411 fichiers, dont 86,6 % venaient du répertoire .git, envoyés vers un stockage que l'utilisateur ne peut pas déchiffrer.
3 min de lecture

En chiffres
- size of one project snapshot sent to cloud storage
- 313MB
- files in that single snapshot
- 42,411
- of the snapshot that came from the .git directory
- 86.6%
ZCode, l'outil de développement de bureau de l'entreprise chinoise d'IA Zhipu, empaquetait l'intégralité des espaces de travail des développeurs et les téléversait vers un stockage en ligne, selon une analyse publiée le 18 septembre 2026. Zhipu s'est excusé le même jour et a expliqué que ces envois venaient d'une fonction activée par défaut. Les envois contenaient des historiques Git complets, là où se trouvent les identifiants supprimés et les branches abandonnées.
ZCode est un outil de développement agentique bâti autour des modèles GLM de Zhipu. Tech AI Wire a couvert la publication des poids de GLM-5.3 en août 2026.
Ce que l'analyse a trouvé
L'analyse technique de ferstar indique que l'outil archive le répertoire de travail pendant qu'un utilisateur est connecté. L'archive couvrait tout le répertoire .git, le cache des gros fichiers, les reflogs et la configuration globale de l'application.
Les chiffres expliquent l'enjeu. L'instantané d'un projet commercial atteignait 313 Mo répartis sur 42 411 fichiers, et 86,6 % de ce total venait du seul .git. Un historique Git n'est pas seulement le code actuel. Il contient chaque version de chaque fichier, y compris la clé d'API que quelqu'un a validée puis retirée il y a trois ans.
Deux réglages de l'interface, nommés "Optimize Experience" et "Repo Snapshot Indexing", n'arrêtaient pas ce comportement une fois désactivés, selon l'analyse. Supprimer un instantané ne servait à rien non plus, car l'outil en créait un nouveau. La parade de l'auteur a été de rendre le répertoire des points de contrôle non modifiable au niveau du système de fichiers.
Le détail du chiffrement
L'archive sur le disque est chiffrée, ce qui rassure jusqu'à ce qu'on regarde qui détient la clé. L'analyse indique que la clé publique RSA arrive du serveur au moment de la capture, tandis que la clé privée correspondante reste dans le nuage. Une développeuse ne peut donc pas ouvrir le fichier posé sur son propre ordinateur.
"Une clé que seul le serveur peut utiliser ne sert qu'à une chose : garantir que le serveur peut lire votre code quand il le veut", a écrit ferstar. L'analyse relève aussi que la politique de confidentialité publiée décrit la collecte de code et de texte pour l'inférence, sans rien dire de l'empaquetage d'espaces de travail entiers.
La réponse de Zhipu
Zhipu a déclaré avoir terminé un examen interne et s'est excusé auprès des utilisateurs concernés, selon PANews. L'entreprise attribue ce comportement à une fonction d'indexation du dépôt. Cette fonction sert à la reprise de session, au retour à une version antérieure et à une fonction Repo Wiki. Zhipu a précisé que l'étape de génération du Wiki pouvait déclencher un envoi.
| Engagement de Zhipu | Détail |
|---|---|
| Conservation | Les données envoyées sont détruites après la génération d'une page Wiki, pas stockées |
| Réglage par défaut | La fonction était activée par défaut lors du lancement initial |
| Code | Le code de ZCode sera publié en source ouverte |
| Audit | Des évaluateurs externes seront invités à examiner le fonctionnement du système |
| Compensation | Chaque utilisateur reçoit une remise à zéro supplémentaire de son quota hebdomadaire |
Les récits ne concordent pas entièrement, et cet écart est l'information. L'analyse décrit une capture et un envoi liés à la connexion, avec des réglages qui ne les arrêtaient pas. Zhipu décrit un chemin plus étroit, lié à la génération d'une page Wiki, suivi d'une suppression. Seul l'audit externe promis pourra dire quelle description correspond au logiciel livré.
Ce que cela signifie pour les développeurs
Traitez votre dépôt comme l'actif sensible, pas seulement vos fichiers actuels. Lancez git log -p sur votre propre historique et voyez ce qu'une copie complète exposerait. D'anciens fichiers .env, des noms d'hôtes internes, un export de base ajouté puis retiré, des noms de branche qui nomment un produit non annoncé : tout y est.
Vérifiez ce que vos outils envoient avant de vérifier ce qu'ils promettent. L'inspection du trafic et un coup d'œil au répertoire de cache de l'outil répondent plus vite qu'une politique de confidentialité. Si un réglage prétend désactiver la télémétrie, confirmez-le par le trafic, car cette promesse a échoué ici.
Pour du code réglementé ou du code client, préférez des outils dont vous pouvez inspecter ou désactiver le chemin de capture au niveau du système de fichiers. Rendre un répertoire en lecture seule est grossier, mais vérifiable. Une publication en source ouverte, que Zhipu vient de promettre, est la version de cet engagement que tout le monde peut contrôler.
Sources
Articles liés

Apple Reference Image signe les photos dans le capteur
Les négatifs sécurisés passent dans les photos supprimées après 30 jours, et la capture est désactivée dans l'UE au lancement. Le billet d'Apple du 15 septembre détaille la chaîne de signature.

Git 3.0 passera à SHA-256 par défaut et exigera Rust
Git 2.56-rc0 est sorti le 11 septembre 2026, et la version 3.0 qui suit fera passer les nouveaux dépôts à SHA-256, à reftable et à la branche main.

Les correctifs kbuild de Linux 7.4 accélèrent la compilation
Une série kbuild visant Linux 7.4 réduit d'environ 80 % les compilations à vide et retire 37,6 secondes à une compilation allmodconfig complète.