ZCode a tenté d’envoyer des dépôts Git dans le cloud : ce que vos assistants IA savent vraiment de vos projets

Les assistants de programmation dopés à l’intelligence artificielle ont sérieusement changé de catégorie. Il n’y a encore pas si longtemps, leur grande spécialité consistait à compléter trois lignes de JavaScript, écrire une regex à notre place ou nous éviter de chercher pour la quinzième fois la syntaxe exacte d’un docker-compose.yml.

Aujourd’hui, on parle d’agents capables de parcourir un projet complet, comprendre son architecture, consulter Git, modifier plusieurs fichiers, lancer des commandes dans le terminal, exécuter les tests et parfois travailler plusieurs minutes presque sans intervention humaine. Bref, on leur donne les clés. Et forcément, plus on donne de clés à un logiciel, plus il devient intéressant de vérifier ce qu’il fait avec le trousseau.

ZCode vient justement de nous offrir un joli cas d’école.

Tout commence avec 700 Mo qui traînent sur un Mac

L’histoire démarre avec un développeur connu sous le pseudonyme ferstar, qui cherche simplement à récupérer un peu d’espace disque. En inspectant le répertoire ~/.zcode, il constate que celui-ci dépasse les 700 Mo. Jusque-là, rien d’extraordinaire : les applications modernes ont une certaine tendance à considérer votre SSD comme un buffet à volonté.

Sauf qu’en creusant dans ~/.zcode/v2/checkpoints, il découvre une archive chiffrée de 313 070 842 octets, associée à l’un de ses projets commerciaux. Le fichier d’état indique que le workspace original représente environ 345 Mo et, surtout, affiche un compteur plutôt sympathique : failureCount: 564.

Autrement dit, ZCode avait tenté 564 fois d’envoyer cette archive.

Mais il y a une nuance importante.

Non, les fameux 313 Mo n’ont finalement pas été envoyés

Une partie des premiers commentaires autour de l’affaire a laissé entendre que ces 313 Mo avaient effectivement été transférés vers le cloud. Ce n’est pas ce que montrent les investigations mises à jour de ferstar.

Cette grosse archive est restée dans le dossier pending et les centaines de tentatives d’envoi ont échoué, notamment parce qu’elle dépassait la taille maximale acceptée par le service. Le développeur indique également ne pas avoir constaté le départ de cette archive hors de son réseau.

En revanche, un second test est beaucoup plus intéressant. Un petit dépôt public contenant 538 fichiers, compressé et chiffré pour atteindre environ 15 Ko, a bien été accepté côté serveur.

Donc soyons précis : les 313 Mo n’ont pas été exfiltrés. Mais le mécanisme permettant d’empaqueter puis d’envoyer des dépôts existait bien, et un dépôt suffisamment petit a effectivement terminé son voyage dans le cloud.

Nuance importante. Ambiance toujours aussi rassurante.

Le plus gros morceau de l’archive ? Le dossier .git

Le détail probablement le plus intéressant de toute l’histoire se cache dans le contenu de l’archive. Sur les quelque 345 Mo préparés avant chiffrement, 86,6 % provenaient du dossier .git .

On y retrouvait notamment les objets Git, le cache Git LFS et les reflogs. Et là, le problème change complètement de dimension, parce qu’un dossier .git, ce n’est pas simplement trois informations permettant à votre IDE d’afficher la branche courante. C’est potentiellement une bonne partie de la mémoire du projet.

Anciennes versions de fichiers, commits, branches, objets Git, historique, références : tout cela peut contenir des informations que vous pensiez avoir supprimées depuis des mois. Vous avez retiré une clé API d’un fichier avant de pousser la dernière version ? Très bien. Elle peut toujours exister dans un ancien commit. Même chose pour un mot de passe, une URL interne, un certificat ou un fichier de configuration qui n’aurait jamais dû se retrouver dans Git.

Supprimer un secret de la version actuelle du projet ne le supprime donc pas automatiquement de tout son historique. Et quand un logiciel empaquette .git, il ne récupère pas uniquement votre code actuel : il embarque potentiellement la machine à remonter le temps avec.

Comment fonctionnait l’envoi ?

L’analyse de l’ancienne version de ZCode effectuée par ferstar décrit une chaîne assez sophistiquée. Le client créait une archive de l’espace de travail, la chiffrait localement en AES-256-CTR, puis utilisait une clé publique RSA fournie par le serveur afin de protéger la clé de chiffrement.

Le fichier pouvait ensuite être envoyé directement vers Alibaba Cloud OSS, tandis qu’un callback signalait la réception au backend de ZCode. Sur le papier, le chiffrement peut sembler rassurant. Sauf qu’il y avait un petit détail : la clé privée permettant le déchiffrement se trouvait côté cloud.

L’utilisateur se retrouvait donc sur son propre disque avec une grosse archive chiffrée de son projet qu’il ne pouvait pas lui-même déchiffrer. Concept intéressant.

« Pas utilisé pour entraîner l’IA » ne veut pas dire « reste sur votre machine »

C’est probablement la leçon la plus intéressante à retenir de cette histoire. Les politiques de confidentialité et réglages des services IA parlent énormément de l’entraînement des modèles : « vos données ne sont pas utilisées pour l’entraînement », « le programme d’amélioration est optionnel », « vos données ne servent pas à entraîner nos modèles par défaut ».

Très bien. Mais cette question est différente de celle-ci : est-ce que mon code quitte mon ordinateur ?

Un service peut parfaitement ne jamais entraîner son modèle avec votre code tout en envoyant celui-ci sur ses serveurs pour effectuer de l’indexation, générer de la documentation, construire un contexte ou exécuter une fonctionnalité distante. La politique de confidentialité actuelle de ZCode indique notamment pouvoir traiter des textes, fichiers et codes transmis lors de l’utilisation de ses services.

Cela ne signifie pas automatiquement qu’un service fait quelque chose de mal. En revanche, cela signifie que les utilisateurs devraient savoir clairement quelles données quittent leur machine, pourquoi elles sont envoyées et pendant combien de temps elles sont conservées.

Surtout lorsqu’il s’agit du dépôt privé d’une entreprise.

Z.ai a depuis modifié le fonctionnement

L’histoire ne s’arrête heureusement pas à la découverte initiale. ZCode a depuis été publié en open source sous licence Apache 2.0. Le dépôt officiel contient désormais les clients, les services backend, les interfaces partagées ainsi que l’agent CLI.

La documentation actuelle de Repo Wiki décrit également un comportement différent de celui observé dans l’ancienne version. ZCode indique aujourd’hui que la génération du wiki peut envoyer au modèle le contexte de code nécessaire, mais précise que plusieurs catégories de fichiers sont exclues, notamment le dossier .git, les dépendances, les fichiers de build, les caches et certains fichiers potentiellement sensibles.

Autrement dit, le comportement documenté aujourd’hui n’est plus celui observé dans la version analysée en septembre 2026. Et c’est une distinction importante : le but n’est pas de transformer un incident corrigé en vérité éternelle sur un logiciel.

Le vrai intérêt de cette affaire est ailleurs.

Parce que ZCode n’est finalement qu’un exemple

Cursor, Claude Code, GitHub Copilot, Gemini CLI, Windsurf, Codex et toute la nouvelle génération d’agents de développement sont confrontés au même problème fondamental. Pour être vraiment utiles, ils doivent comprendre votre projet.

Ils veulent connaître l’arborescence, lire vos fichiers, chercher les références d’une fonction, examiner les dépendances, consulter les logs, lancer des commandes et parfois parcourir Git. Dans certains cas, une partie de ces opérations implique également une communication avec des modèles hébergés à distance.

C’est précisément ce qui rend ces outils incroyablement pratiques. Mais c’est également ce qui fait que nous devrions probablement arrêter de les considérer comme de simples autocomplétions un peu plus intelligentes.

Un agent IA disposant d’un accès au terminal et à votre dépôt est pratiquement un nouvel utilisateur sur votre machine. Avec beaucoup de permissions. Et énormément de curiosité.

Quelques réflexes avant de donner votre dépôt à une IA

Pas besoin de revenir immédiatement à Vim sur un Pentium III déconnecté d’Internet. Quelques vérifications simples permettent déjà de réduire sérieusement les mauvaises surprises. Commencez par regarder comment fonctionne l’indexation du projet et recherchez dans la documentation des termes comme « codebase indexing », « repository context », « workspace », « cloud indexing », « semantic search » ou « Repo Wiki ».

Il est également important de vérifier ce que signifie réellement le réglage de confidentialité proposé par le service. Une option empêchant l’utilisation de vos données pour entraîner un modèle ne garantit pas nécessairement que celles-ci ne soient jamais envoyées vers le cloud pour être analysées.

Votre historique Git mérite lui aussi une attention particulière. Lorsqu’un secret, une clé API ou un mot de passe a été ajouté à un commit puis supprimé par la suite, il peut toujours être présent dans l’historique du dépôt. Dans ce cas, supprimer simplement le fichier ne suffit généralement pas : le secret concerné doit être considéré comme exposé, révoqué puis remplacé.

Pour les projets sensibles, surveiller le trafic réseau de l’application peut également être instructif. Un pare-feu applicatif, un proxy local ou certains outils de monitoring permettent de voir assez rapidement quels domaines sont contactés pendant l’analyse du dépôt.

Et lorsque la confidentialité prime réellement sur les performances, les modèles locaux constituent désormais une alternative de plus en plus crédible. Ils ne remplaceront pas systématiquement les meilleurs modèles cloud, mais accepter un peu moins de performance en échange d’un traitement entièrement local peut devenir un compromis très raisonnable.

L’IA peut lire votre code. Elle devrait simplement vous dire où elle l’emmène.

Les agents de programmation ne vont pas disparaître. C’est même exactement l’inverse qui est en train de se produire : ils vont obtenir davantage d’autonomie, accéder à plus de fichiers, exécuter davantage de commandes et réaliser des tâches de plus en plus longues sans intervention humaine.

Nous allons donc probablement devoir adopter avec eux le même réflexe qu’avec n’importe quel logiciel disposant de privilèges importants sur notre machine. Il ne suffit plus de regarder ce qu’un assistant promet de faire : il faut aussi s’intéresser à ce qu’il lit, à ce qu’il stocke, à ce qu’il transmet et surtout à la destination de ces données.

Parce qu’entre « mon assistant IA comprend mon projet » et « mon historique Git vient de partir faire un tour dans le cloud », il existe tout de même une nuance assez importante.