Contexte de l’incident

En septembre 2026, des utilisateurs de ZCode, l’assistant de codage IA développé par la société chinoise Z.ai (également connue sous le nom de Zhipu), ont constaté une consommation anormale d’espace disque. L’enquête menée par le blogueur indépendant Ferstar a révélé que le processus en arrière‑plan de ZCode créait des archives compressées contenant l’ensemble du workspace, y compris l’historique complet .git, le cache Git LFS, les reflogs et les configurations globales de l’application.

Ces archives étaient ensuite chiffrées et transférées vers Aliyun OSS, le service de stockage d’objets d’Alibaba Cloud. La fonctionnalité responsable, nommée « Codebase Indexing », était activée par défaut et ne disposait d’aucun commutateur permettant de la désactiver. La politique de confidentialité de Z.ai ne mentionnait pas ce comportement, créant ainsi un écart entre les attentes des développeurs et les actions réelles du logiciel.

Mécanisme de l’indexation et du transfert

Le mécanisme d’indexation était destiné à fournir des points de contrôle de session, des retours de version et la génération de wikis. Lorsqu’un utilisateur était connecté, ZCode empaquetait automatiquement le répertoire de travail complet, incluant les .git reflogs et les secrets éventuels stockés dans des fichiers .env. Le bundle était compressé, chiffré avec des clés détenues exclusivement par les serveurs de Z.ai, puis envoyé vers un bucket OSS configuré par défaut. Aucun journal local n’indiquait la sortie de ces données, rendant la vérification par les équipes de sécurité pratiquement impossible.

Un cas concret signalé par Chengming Technology a indiqué que six workspaces différents avaient été uploadés, contenant du code source, des mots de passe de bases de données et des informations personnelles d’employés. Bien que l’entreprise ait ensuite retiré sa plainte, l’incident a mis en évidence le risque de fuite de secrets lorsqu’un outil possède un accès large au système de fichiers.

Réaction de Z.ai et mesures correctives

Après une semaine de réactions publiques, Z.ai a désactivé la fonctionnalité incriminée dans la version 3.14.0 de ZCode, a supprimé le bucket OSS concerné et a introduit des options de zero‑data‑retention. L’entreprise a également publié le code source de ZCode et a commandité des évaluations de sécurité externes auprès du China Academy of Information and Communications Technology et du cabinet NSFOCUS. NSFOCUS a confirmé la suppression du bucket et l’absence de données résiduelles. Z.ai a affirmé que les archives n’avaient jamais été utilisées pour l’entraînement du modèle GLM‑5.3 sous‑jacent et a annoncé la mise en place d’un processus continu de signalement et de réponse aux vulnérabilités.

Malgré ces actions, la transparence reste limitée : les clés de chiffrement étant contrôlées par Z.ai, aucune tierce partie n’a pu vérifier de façon indépendante la destruction effective des archives.

Enjeux de sécurité pour les assistants IA

L’incident illustre que les assistants de codage IA doivent être traités comme des applications privilégiées, soumises aux mêmes revues de sécurité que tout agent ayant accès aux dépôts et aux secrets. Trois points critiques émergent : la nécessité de contrôler les paramètres par défaut, la surveillance du trafic sortant (egress) pour détecter les transferts de gros paquets chiffrés, et la gestion des secrets hors du code (scanning, vaults). Les équipes DevSecOps doivent exiger des fournisseurs des descriptions précises des flux de données, des possibilités de désactivation centralisée des fonctions de synchronisation et des audits indépendants du code source.

En définitive, le problème ne réside pas dans le modèle d’IA lui‑même, mais dans l’architecture logicielle qui accorde à un outil de bureau un accès complet au système de fichiers et à Internet sans mécanismes de contrôle explicites. Cette leçon s’applique à tous les assistants IA, quel que soit le pays d’origine du fournisseur.