Grok Build passe en open source : transparence forcée ou geste marketing ?

SpaceXAI ouvre le code de son agent de coding terminal. Une bonne nouvelle sur le papier. Mais le contexte de cette annonce mérite qu’on s’y attarde.

Ce que SpaceXAI a publié

Le 15 juillet 2026, l’entreprise a annoncé sur X l’ouverture du code source de Grok Build, son agent de coding en ligne de commande. Le dépôt xai-org/grok-build est désormais accessible sur GitHub.

Petite précision de vocabulaire, puisque la presse hésite encore : l’entreprise se présente désormais sous le nom SpaceXAI. C’est le nom qui figure dans le README du dépôt, celui du compte X qui a publié l’annonce (@SpaceXAI), et celui qu’emploient Next.ink comme PC Watch. Seule l’organisation GitHub conserve l’identifiant historique xai-org, et les modules gardent le préfixe xai-.

Concrètement, Grok Build est un agent IA qui tourne dans un terminal. Il comprend une base de code, édite des fichiers, exécute des commandes shell, effectue des recherches web et gère des tâches longues. Le tout s’affiche dans une interface TUI plein écran (Terminal User Interface, c’est-à-dire une interface graphique qui s’exécute dans un terminal texte), pilotable à la souris. Il fonctionne aussi en mode headless pour le scripting et la CI, ou embarqué dans un éditeur via le protocole ACP (Agent Client Protocol).

Selon le dépôt GitHub officiel, le code publié couvre deux composants principaux : le CLI/TUI et le runtime agent. Le tout est écrit en Rust (99,6 % du dépôt). Des binaires précompilés sont disponibles pour macOS, Linux et Windows — mais attention à la nuance : côté compilation depuis les sources, seuls macOS et Linux sont officiellement supportés, Windows étant qualifié de « best-effort » et non testé.

La licence retenue est l’Apache 2.0, une licence permissive qui autorise l’usage commercial et la modification. Elle ne couvre toutefois que le code first-party : les composants tiers et vendorisés restent sous leurs licences d’origine. SpaceXAI précise que le dépôt est synchronisé périodiquement depuis son monorepo interne.

Open source, oui, mais… Pas vraiment collaboratif.

Il faut lire les conditions en détail. SpaceXAI est explicite : aucune contribution externe n’est acceptée. Le dépôt est en lecture seule pour la communauté.

C’est un choix qui a un nom dans l’industrie : l’open source en vitrine. Le code est lisible, auditable, forkable. Mais le projet reste entièrement piloté par SpaceXAI. Pas de pull requests, pas de gouvernance partagée, pas de roadmap publique.

Le détail le plus parlant se lit dans l’interface GitHub elle-même : le dépôt compte un seul commit, et aucune release publiée. Pas d’historique, pas de traçabilité des changements, pas de moyen de voir ce qui a été modifié entre deux synchronisations du monorepo. On ne publie pas un projet, on dépose un instantané. À l’heure d’écrire ces lignes, ce snapshot avait tout de même rassemblé environ 6 000 étoiles et 919 forks.

La justification officielle, telle que rapportée par PC Watch : l’ouverture du code permettrait à chacun de contribuer à rendre le harnais plus fiable et plus robuste. La formulation est habile. Elle suggère une collaboration sans en offrir les mécanismes réels — puisque, précisément, personne ne peut contribuer.

La structure du dépôt est néanmoins documentée. On y trouve des crates (modules Rust) distincts pour le TUI, le runtime agent, les outils (terminal, édition de fichiers, recherche), et la gestion du workspace. Le fichier Cargo.toml racine est généré automatiquement et marqué en lecture seule, selon le README officiel.

Le contexte qu’on ne peut pas ignorer

Cette annonce n’arrive pas dans le vide. Cinq jours avant la publication du code, un chercheur connu sous le pseudonyme Cereblab documentait un comportement autrement plus préoccupant que ce que le terme « collecte de données » laisse entendre.

Selon Next.ink, qui a couvert l’affaire en détail, Grok Build envoyait des dépôts entiers vers des serveurs distants sans consentement explicite des développeurs. La méthode du chercheur était simple : un proxy en sortie de machine pour monitorer les échanges réseau. Sur un dossier de travail de 12 Go, 5,1 Go de données — pourtant non manipulées durant la session — ont transité vers un bucket hébergé sur Google Cloud, découpées en dizaines de morceaux d’environ 75 Mo retournant tous un code HTTP 200. Autrement dit : acceptées par l’infrastructure distante.

Le point technique décisif, que beaucoup de comptes rendus escamotent : il ne s’agissait pas d’envoyer des fichiers, mais d’empaqueter des bundles Git complets, historique des commits inclus. La différence est énorme. Un bundle Git ne contient pas seulement l’état actuel du répertoire de travail : il contient tout ce qui a été commité un jour. Anciennes clés API, mots de passe supprimés il y a six mois, URLs internes, fragments de configuration retirés trop tard. Tout ce que vous croyiez effacé.

Le chercheur a identifié deux canaux distincts : un canal « modèle » via /v1/responses (192 ko échangés) et un canal « stockage » via /v1/storage (5,1 Go envoyés). Le rapport entre les deux se passe de commentaire : environ 27 800 fois plus de données transmises par le canal de stockage que par celui strictement nécessaire à la réponse du modèle. Dans le lot figurait un fichier .env, envoyé sans caviardage automatique des secrets — soit précisément le fichier dédié aux clés d’accès aux API du projet.

Le test le plus parlant : Cereblab demande à Grok Build de répondre simplement « OK » et de n’ouvrir aucun fichier. L’outil génère quand même un bundle Git complet du dépôt local et l’envoie. Le chercheur a ensuite cloné le bundle intercepté sur le fil réseau et y a récupéré un fichier piégé volontairement, que l’agent n’était pas censé ouvrir. Il a reproduit l’expérience avec Claude Code, Codex d’OpenAI et Gemini : aucun transfert inapproprié constaté. Grok Build était l’exception.

Le bouton de confidentialité qui ne servait à rien

C’est ici que l’affaire cesse d’être un incident technique pour devenir un problème de conception.

Grok Build proposait bien un réglage de confidentialité : l’option « Improve the model ». Le désactiver ne changeait strictement rien à l’envoi. Après l’avoir coupée, l’endpoint /v1/settings continuait de renvoyer trace_upload_enabled: true, et le canal de stockage continuait d’accepter les bundles.

La raison est structurelle, et elle mérite d’être comprise : le consentement à l’entraînement et le contrôle de la transmission sont deux mécanismes différents. Le premier détermine si vos données servent à améliorer les futurs modèles. Le second détermine si elles quittent votre machine. Grok Build n’exposait que le premier. Les développeurs qui pensaient s’être désinscrits de la collecte n’avaient en réalité refusé qu’un usage en aval de données déjà parties.

Ajoutons que le marketing de l’outil affirmait que rien de votre base de code n’était transmis aux serveurs pendant une session. L’analyse réseau dit le contraire.

La réaction, et ce qu’elle ne règle pas

SpaceXAI a réagi en désactivant l’upload côté serveur, via un flag global silencieux (disable_codebase_upload: true, accompagné de trace_upload_enabled: false). Cereblab a confirmé, après plusieurs retests, que les envois avaient cessé. Elon Musk a promis la suppression des données précédemment collectées, tout en minimisant la portée de l’incident. L’entreprise s’est exprimée sur X le 13 juillet, assurant que rien n’était conservé pour les clients ayant opté pour un fonctionnement sans rétention de données (ZDR).

Trois problèmes subsistent.

D’abord, la fonction d’envoi reste intégrée au client. C’est une désactivation par configuration, pas par suppression du code. Un changement de politique suffirait à la réactiver, sans même pousser une mise à jour logicielle.

Ensuite, la commande /privacy mise en avant par l’entreprise est un réglage de rétention par session, pas le mécanisme qui a stoppé l’envoi. Cereblab est explicite sur ce point : ce n’est pas le bon contrôle à désigner, et aucun développeur ne devrait avoir à exécuter une désinscription après chaque session pour garder son code sur sa propre machine. Selon lui, le réglage par défaut correct, c’est « désactivé ».

Enfin, aucun audit indépendant ne permet de vérifier l’étendue de la suppression promise. Pas de rapport d’incident formel, pas de calendrier, pas de décompte des utilisateurs touchés, pas de mécanisme permettant à un développeur de vérifier que ses données ont bien disparu.

Le chercheur, lui, s’astreint à une rigueur qu’on aimerait voir plus souvent. Il refuse de spéculer sur la finalité de ces envois : rien ne prouve, écrit-il, que les données aient servi à entraîner quoi que ce soit. Ce qui est prouvé, c’est « la transmission, l’acceptation et le stockage ». La distinction entre ce qui est démontré et ce qui est plausible n’est pas un détail de forme. C’est ce qui sépare une analyse d’une accusation.

Pour ceux qui ont utilisé l’outil, une vérification simple circule chez les développeurs : cat ~/.grok/logs/unified.jsonl | grep repo_state.upload. Et la recommandation des chercheurs en sécurité est sans ambiguïté — faire tourner l’ensemble des identifiants auxquels l’outil a pu accéder, y compris ceux enfouis dans l’historique Git.

Ce que le code révèle (et ce qu’il cache encore)

La publication du code source offre une surface d’audit que les utilisateurs n’avaient pas avant. Les crates sont nommées explicitement dans le dépôt : xai-grok-tools contient les implémentations des outils (terminal, édition de fichiers, recherche). xai-grok-workspace gère le filesystem hôte, le VCS, l’exécution et les checkpoints.

Le README mentionne aussi un module sandbox et un mode headless pour les pipelines CI. Les fonctionnalités sont nombreuses : serveurs MCP (Model Context Protocol, un protocole pour connecter des agents IA à des outils externes), skills, plugins, hooks, thèmes. Le binaire produit s’appelle xai-grok-pager ; les installations officielles le livrent sous le nom grok.

Un point mérite attention : le fichier THIRD-PARTY-NOTICES liste des portages de code issus de openai/codex et sst/opencode. SpaceXAI a donc intégré du code d’autres projets open source dans son propre outil. Ces portages sont couverts par leurs licences d’origine, avec notice de modification requise par l’Apache §4(b), selon le README. Le répertoire third_party/ contient par ailleurs la stack Mermaid vendorisée.

Ce que le code ne peut pas révéler seul : le comportement des serveurs de SpaceXAI. Et c’est toute la limite de l’exercice. Le flag qui a stoppé les uploads est un flag serveur. Auditer le client permet de constater que la fonction d’envoi existe toujours ; cela ne dit rien de ce qui se passe à l’autre bout, ni de ce qui a été conservé. L’audit du client est utile. Il ne remplace pas la transparence sur l’infrastructure.

Le reset des limites d’utilisation et Grok 4.5 en Europe

L’annonce du 15 juillet 2026 s’accompagnait de deux autres nouvelles. Selon PC Watch, les limites d’utilisation de Grok ont été remises à zéro pour l’ensemble des utilisateurs. Jason Ginsberg, employé de SpaceXAI, a également confirmé sur X la disponibilité du modèle Grok 4.5 dans l’Union européenne, en remerciant les utilisateurs pour leurs retours.

Ces annonces groupées ont été relayées par Elon Musk sur X. La mécanique est rodée : plusieurs bonnes nouvelles simultanées, un effet d’accumulation favorable, une couverture médiatique concentrée sur le positif. PC Watch titre d’ailleurs sur la remise à zéro des limites, pas sur l’open source.

Le timing reste ce qu’il est. Cinq jours après une controverse sur la collecte non consentie de dépôts Git entiers, SpaceXAI publie le code source de l’outil incriminé, remet les compteurs à zéro et annonce une expansion géographique. Chaque élément pris séparément est une bonne nouvelle. L’ensemble ressemble à une opération de communication.

Ce qui n’enlève rien à la valeur du geste. Un code auditable vaut mieux qu’une boîte noire, quelles qu’en soient les motivations. Mais un dépôt à commit unique, fermé aux contributions, synchronisé depuis un monorepo opaque et dont le composant central du litige est piloté côté serveur : ça ne s’appelle pas de la transparence. Ça s’appelle une fenêtre.

Ce qu’il faut retenir

• Grok Build est désormais open source sous licence Apache 2.0 (first-party uniquement), code Rust disponible sur xai-org/grok-build
• L’entreprise se présente désormais sous le nom SpaceXAI ; seule l’organisation GitHub garde l’identifiant xai-org
• Aucune contribution externe n’est acceptée, le dépôt compte un seul commit et aucune release : c’est un instantané, pas un projet ouvert
• L’annonce intervient cinq jours après la publication de l’analyse de Cereblab sur l’envoi non consenti de dépôts vers Google Cloud
• Ce n’étaient pas des fichiers mais des bundles Git complets, historique inclus — donc des secrets supprimés des mois plus tôt ; environ 27 800× plus de données que la tâche n’en exigeait
• Le réglage de confidentialité « Improve the model » n’empêchait pas l’envoi : consentement à l’entraînement et contrôle de la transmission sont deux choses distinctes
• La fonction d’upload reste dans le client : seul un flag serveur la neutralise, et /privacy ne gère que la rétention
• Aucun audit indépendant, aucun rapport d’incident, aucun décompte des utilisateurs concernés
• Grok 4.5 devient disponible dans l’UE, et les limites d’utilisation ont été remises à zéro pour tous
• Binaires précompilés pour macOS, Linux et Windows ; compilation depuis les sources non testée sous Windows

Pour les artisans numériques qui utilisent des agents de coding en CLI : l’audit du code source est maintenant possible. C’est mieux qu’avant. Ce n’est pas suffisant pour accorder une confiance aveugle à l’infrastructure qui tourne derrière. Et si vous avez utilisé Grok Build avant le 13 juillet, faites tourner vos clés.

Sources

• GitHub — xai-org/grok-build (README, licence, structure du dépôt)
• PC Watch — Grok利用制限が全リセット！ターミナルAI「Grok Build」オープンソース化
• Next.ink — Grok Build envoyait des dépôts vers le cloud sans le consentement des développeurs
• The Register — Musk promises purge after Grok Build caught sending entire repos to the cloud
• L’Usine Digitale — L’entreprise d’Elon Musk a aspiré tous les dépôts Git des utilisateurs de Grok Build
• TechTimes — Grok Build Shipped Entire Codebases to xAI Cloud; Privacy Toggle Did Nothing
• The Next Web — Grok Build was uploading entire Git repositories, including committed secrets
• SpaceXAI — Page open source officielle