Elon Musk annonce l’ouverture du code de Grok Build : les développeurs peuvent le compiler localement, pour éteindre l’incendie après la tempête de fuites ?

xAI a entièrement ouvert le code source de l’agent de programmation pour terminal Grok Build sur GitHub le 15 juillet, permettant aux développeurs de compiler eux-mêmes en local et de vérifier le code ligne par ligne, sans plus dépendre du calcul dans le cloud.
(Contexte : Grok Build a été victime d’un piratage qui a exfiltré « l’ensemble du répertoire personnel » des utilisateurs vers le cloud, effrayant les développeurs : tout a été divulgué)
(Informations complémentaires : Musk’s xAI lance « Grok Build » pour défier Claude : jusqu’à 8 agents IA en parallèle, une fenêtre de contexte allant jusqu’à 2 millions de tokens)

Table des matières

Toggle

• Grok Build ouvre le code
• Un code déployé qu’on ne peut plus cacher
• Au-delà de l’open source, qu’est-ce qui manque encore

Dans l’aube d’aujourd’hui (16), Musk a partagé un post indiquant : SpacexAI a publié l’intégralité du code de Grok Build sur GitHub, permettant aux développeurs de compiler et de vérifier en local, ligne par ligne. Toutefois, le moment de ce « grand cadeau » est délicat : ce n’est que ces derniers jours que les données exfiltrées via Grok Build ont été mises au jour, notamment des mots de passe et des clés d’utilisateurs, discrètement emballés puis envoyés dans le cloud.

Cette ouverture est-elle une démarche de bonne volonté, ou un moyen d’éteindre un incendie ?

Grok Build is now open source https://t.co/LbGepmRB3l

— Elon Musk (@elonmusk) July 15, 2026

Grok Build ouvre le code

Grok Build est un agent de programmation natif pour terminal basé sur l’IA, lancé par xAI (alias SpaceXAI) en mai 2026. L’officiel met en avant jusqu’à 8 agents IA en parallèle, une fenêtre de contexte pouvant atteindre 2 millions de tokens, avec pour objectif de défier Claude Code d’Anthropic et Cursor.

Désormais, xAI a ouvert l’intégralité du code source de Grok Build sur GitHub via le projet xai-org/grok-build : les développeurs peuvent compiler et modifier en local, par exemple en changeant le fichier de configuration config.toml, puis exécuter avec une inférence locale, sans devoir transmettre les données au cloud xAI.

L’entreprise présente cette étape comme une réponse officielle aux critiques externes concernant la confidentialité et la transparence. En théorie, après la publication du code source, chacun peut vérifier par lui-même ce que l’outil fait réellement en coulisses, sans devoir se contenter du discours officiel.

Le code déployé qu’on ne peut plus cacher

La tempête qui a éclaté ces derniers jours vient d’un problème dans la version 0.2.93 de Grok Build. Un chercheur en sécurité IA a découvert que, à chaque fois que Grok Build lit et traite un fichier, il l’intègre comme une partie d’une requête d’appel de modèle ; l’outil dissimule en interne un canal d’envoi distinct côté « back-end » : il ne s’agit pas seulement d’envoyer les fichiers partiels requis par la tâche, mais d’emballer l’ensemble du dépôt Git du code de l’utilisateur, avec le code source complet du projet et l’historique complet des modifications, puis de le compiler en un Git bundle et de l’envoyer vers l’espace de stockage de SpaceXAI sur le cloud Google. Les données ne sont absolument pas anonymisées.

À quel point est-ce énorme ? Lors d’un test réel, la tâche ne nécessitait en pratique que 192 KB de données, mais Grok Build a envoyé 5,1 GB, soit 26 000 fois la quantité nécessaire. En plus, ont été emballés et envoyés : des journaux d’opérations, un mot de passe back-end et des clés API. Les « interrupteurs de confidentialité » que l’outil prétend pouvoir désactiver n’ont eu aucun effet lors des tests.

Le premier geste de xAI n’a pas été de présenter des excuses publiques, mais de pousser discrètement une correction côté serveur pour bloquer les envois anormaux, sans publier d’avis de sécurité, et les notes de la mise à jour n’ont pas non plus mentionné l’affaire. Ce n’est que lorsque Musk est intervenu en personne que l’entreprise a promis publiquement de supprimer entièrement et définitivement toutes les données utilisateur déjà envoyées, sans laisser de sauvegarde ; pour les utilisateurs non-entreprise n’ayant pas activé la conservation « zéro données », l’entreprise fournit une simple commande permettant aux utilisateurs de supprimer eux-mêmes les données collectées auparavant.

Au-delà de l’open source, qu’est-ce qui manque encore

Il reste encore de nombreuses zones d’ombre. La correction côté serveur n’a pour l’instant été confirmée que comme efficace sur un seul appareil et pour un seul compte : est-ce que cela s’est déjà appliqué globalement à grande échelle, l’officiel ne l’explique pas. De plus, on ne sait pas vraiment si les données ont été supprimées, et il n’existe aucune vérification indépendante par un tiers permettant de le confirmer.

Des experts estiment que la vraie solution devrait consister à interdire directement côté serveur l’envoi de l’intégralité du dépôt de code, plutôt que de compter sur des instructions manuelles de la part des utilisateurs pour rattraper le coup. La réaction de la communauté a aussi été directe : il est difficile de faire confiance à un assistant IA disposant du plus haut niveau de privilèges sur un ordinateur. Pour les entreprises qui confient tout l’environnement de développement à des agents IA, ainsi que pour les développeurs indépendants, cet épisode constitue un avertissement : plus l’outil dispose d’autorisations élevées, plus il a besoin de mécanismes de vérification et d’audit stricts.