- ▸ Lundi, Cereblab ouvre le capot du Grok Build CLI
- ▸ D'où vient l'envoi : la bascule des assistants de code vers le cloud
- ▸ Code propriétaire, identifiants, failles : le périmètre réel de la fuite
- ▸ « disable_codebase_upload: true » : le drapeau qui a coupé l'envoi
L’assistant de programmation Grok Build, édité par SpaceXAI, empaquetait et transférait l’intégralité des dépôts de ses utilisateurs vers Google Cloud — y compris des fichiers explicitement exclus et des secrets purgés de l’historique Git. Un chercheur en sécurité qualifie cette rétention d’« excessive ». Trois questions ordonnent ce dossier : ce qui partait vers les serveurs, ce qui a coupé l’envoi, et pourquoi le correctif ne referme pas le débat.
Ce qu’il faut retenir 1. Envoi intégral : le Grok Build CLI empaquetait et téléversait le dépôt complet des utilisateurs vers Google Cloud, d’après les tests relayés par The Verge. 2. Périmètre sensible : les envois incluaient « des fichiers qu’on lui avait dit de ne pas ouvrir et des secrets supprimés de l’historique ». 3. Verdict d’expert : Lukasz Olejnik (King’s College London) juge la rétention « excessive » ; le risque couvre code propriétaire, vulnérabilités, données personnelles, détails d’infrastructure et identifiants. 4. Correctif confirmé : les serveurs renvoient désormais un drapeau
disable_codebase_upload: trueet l’envoi « ne se déclenche plus ». 5. Point de friction : la commande/privacyest un réglage de rétention par session, pas l’interrupteur qui a corrigé le problème — Cereblab prévient qu’elle ne doit pas être présentée comme le contrôle.
Lundi, Cereblab ouvre le capot du Grok Build CLI
Un outil d’aide au code fonctionne comme une boîte partiellement fermée. Le développeur voit les suggestions qui remontent ; il ne voit pas toujours ce qui descend vers les serveurs de l’éditeur. C’est cette partie invisible que la société de recherche Cereblab a documentée lundi, en observant le trafic réseau du client en ligne de commande de Grok Build.
Le constat, relayé par The Verge, tient en une phrase brute : l’outil empaquetait et téléversait des dépôts de code entiers, « y compris des fichiers qu’on lui avait dit de ne pas ouvrir et des secrets supprimés de l’historique ». Autrement dit, la frontière que le développeur croyait avoir tracée — un .gitignore, une purge d’historique — n’était pas respectée par le client au moment de la synchronisation.
Le chiffre à retenir n’est pas un pourcentage exotique : c’est 100 %. Pas un échantillon, pas les fichiers ouverts dans l’éditeur, pas les seuls fragments nécessaires à une réponse — le dépôt complet. Cette totalité est ce qui distingue l’incident d’un simple débat sur la télémétrie.
D’où vient l’envoi : la bascule des assistants de code vers le cloud
Pour comprendre pourquoi ce comportement passe longtemps inaperçu, il faut regarder comment ces outils ont évolué. Les premiers assistants de programmation complétaient une ligne à la fois : ils envoyaient un contexte réduit, quelques dizaines de lignes autour du curseur. La logique restait locale, ou presque.
Les agents de code récents fonctionnent autrement. Pour raisonner sur un projet, ils ont besoin d’une vue d’ensemble : arborescence, dépendances, appels croisés entre fichiers. Beaucoup construisent donc un index — une représentation du dépôt — afin de retrouver rapidement le bon extrait quand l’utilisateur pose une question. La question technique décisive est de savoir où cet index est construit et combien de temps les données restent stockées.
Deux modèles cohabitent. L’indexation locale garde la représentation sur la machine du développeur ; seules des requêtes ciblées partent vers le modèle. L’indexation côté serveur, à l’inverse, suppose de transférer le contenu vers l’infrastructure de l’éditeur, où il est traité puis, selon les politiques, conservé. C’est sur ce second modèle que se joue la notion de « zéro rétention de données » (zero data retention, ou ZDR) : la promesse qu’un contenu envoyé pour être traité n’est pas conservé une fois la réponse produite. Sur ce point, la gestion des secrets dans les assistants de code est devenue un critère d’achat pour les directions techniques.
Le cas Grok Build se situe à l’intersection de ces deux enjeux : non seulement le contenu partait vers le cloud, mais il partait en totalité, exclusions comprises, et il était conservé. La combinaison est ce qui fait basculer l’affaire du registre de la télémétrie discutable vers celui du risque de sécurité caractérisé.
Code propriétaire, identifiants, failles : le périmètre réel de la fuite
Reste à mesurer ce que « dépôt entier » recouvre concrètement pour une organisation. La réponse dépend de ce que contient un dépôt moderne — et un dépôt moderne contient rarement que du code.
Lukasz Olejnik, chercheur indépendant en sécurité rattaché au King’s College London, a confirmé à The Verge que ce niveau de rétention est « excessif ». Il en détaille le périmètre : les données potentiellement exposées peuvent comprendre « du code source propriétaire, des informations sur des vulnérabilités de sécurité, des données personnelles, des détails d’infrastructure [et] des identifiants ».
Chacune de ces catégories porte un coût distinct. Le code propriétaire, c’est l’actif métier lui-même. Les informations sur des vulnérabilités renseignent un attaquant sur les points faibles avant même qu’ils ne soient corrigés. Les détails d’infrastructure cartographient le système cible. Et les identifiants — clés d’API, jetons, mots de passe committés par erreur — ouvrent directement la porte, sans effort d’exploitation supplémentaire.
Le point le plus corrosif tient au traitement des exclusions. Un développeur prudent range ses secrets hors du suivi, ou les efface de l’historique après une fuite locale. Le fait que Grok Build ait tout de même envoyé « des fichiers qu’on lui avait dit de ne pas ouvrir et des secrets supprimés de l’historique » signifie que ces garde-fous n’ont pas été honorés côté client. Un secret « supprimé » de l’historique Git peut donc avoir survécu ailleurs — sur des serveurs tiers.
Le tableau ci-dessous récapitule le périmètre décrit par les sources, sans extrapolation.
| Catégorie exposée (selon Olejnik / The Verge) | Nature du risque | Réversible après suppression ? |
|---|---|---|
| Code source propriétaire | Perte d’actif métier, copie hors périmètre | Partiellement — la copie a existé |
| Informations sur des vulnérabilités | Renseignement offensif avant correctif | Non — l’info reste connue |
| Données personnelles | Exposition RGPD potentielle | Selon usage aval |
| Détails d’infrastructure | Cartographie de la cible | Non — la topologie ne change pas |
| Identifiants (clés, jetons) | Accès direct aux systèmes | Seulement après rotation des secrets |
La dernière colonne porte l’enseignement pratique : supprimer un fichier côté serveur ne « répare » pas un identifiant qui a fuité. Un jeton exposé doit être révoqué et régénéré, pas seulement effacé.
« disable_codebase_upload: true » : le drapeau qui a coupé l’envoi
Une fois le comportement documenté publiquement, la question devient opérationnelle : l’envoi a-t-il cessé, et comment ? Les tests menés par les chercheurs apportent une réponse vérifiable côté réseau.
Depuis lundi, selon leurs observations, les serveurs de SpaceXAI renvoient un drapeau explicite : « disable_codebase_upload: true ». Concrètement, la synchronisation du dépôt « ne se déclenche plus ». Le contrôle a été poussé côté serveur, ce qui a l’avantage de s’appliquer sans que chaque utilisateur ait à mettre à jour son client ou à modifier une configuration.
Ce détail d’implémentation mérite d’être souligné, parce qu’il oriente l’évaluation du risque résiduel. Un correctif purement local — « installez la nouvelle version » — laisse en circulation toutes les installations non mises à jour. Un drapeau serveur qui neutralise le comportement pour l’ensemble des clients ferme le robinet plus largement. C’est, sur le papier, la bonne façon de stopper une hémorragie de données.
Restent deux limites que le drapeau ne traite pas. La première est temporelle : il coupe les envois à venir, pas ceux déjà effectués. La seconde est celle du stock : les données déjà synchronisées avant lundi existent quelque part, et leur sort dépend d’une action de suppression distincte. C’est précisément le terrain sur lequel le désaccord se cristallise.
/privacy n’est pas l’interrupteur : le malentendu sur le contrôle
Une note de sécurité mal calibrée peut être aussi trompeuse qu’une absence de note. C’est le reproche que Cereblab adresse à la manière dont le contrôle a été présenté.
La documentation associée indique que, si la rétention zéro est désactivée, « la commande /privacy est disponible dans le CLI pour désactiver la rétention de données, ce qui supprime aussi les données précédemment synchronisées ». Formulé ainsi, /privacy ressemble à l’interrupteur central — la manette unique qui règle la question.
Les chercheurs contestent cette lecture. Leur mise en garde est nette : « /privacy est un réglage de rétention par session, pas l’interrupteur qui a corrigé le problème, il ne devrait donc pas être présenté comme le contrôle ». La nuance n’est pas cosmétique. Un réglage « par session » n’a pas la même portée qu’un correctif structurel : il agit dans le cadre d’une session, quand l’utilisateur y pense et l’active, tandis que ce qui a réellement stoppé l’envoi est le drapeau serveur disable_codebase_upload.
Le risque, pour l’utilisateur, est de se croire protégé par une commande qui ne fait pas ce qu’il imagine. Pointer /privacy comme la solution revient à déplacer la charge de la sécurité vers le développeur, alors que le défaut se situait dans le comportement par défaut du client. Le tableau suivant sépare les mécanismes pour clarifier qui fait quoi.
| Mécanisme | Ce qu’il fait (selon les sources) | Ce qu’il ne fait pas |
|---|---|---|
disable_codebase_upload: true (serveur) | Neutralise l’envoi du dépôt pour les clients ; l’upload « ne se déclenche plus » | N’efface pas rétroactivement les données déjà transférées |
/privacy (CLI) | Bascule de rétention par session ; désactive la rétention et supprime les données synchronisées | N’est pas le correctif du défaut d’envoi ; portée limitée à la session |
| Rétention zéro (ZDR) | Si active, évite la conservation ; sa désactivation ouvre l’usage de /privacy | N’empêchait pas, en soi, l’empaquetage du dépôt complet |
Notre lecture : le correctif efficace et le contrôle communiqué ne sont pas le même objet, et cette confusion est le vrai angle mort de la réponse.
Une rétention supérieure aux outils comparables
Pour juger si l’incident relève de l’anomalie ou de la pratique courante, il faut un point de comparaison. Les sources en fournissent un, qualitatif mais explicite.
D’après The Verge, les conclusions de Cereblab décrivent un client qui empaquetait et téléversait des dépôts entiers — « nettement plus de rétention de données que des outils similaires comme Claude Code ». La formulation situe Grok Build à l’écart de la norme observée chez ses pairs, et non dans une zone grise partagée par tout le secteur.
L’écart compte parce qu’il déplace la question. Si tous les assistants de code téléversaient l’intégralité des dépôts, le débat porterait sur un standard sectoriel à réformer. Ici, un outil retient davantage que ses concurrents directs : le problème est spécifique à l’implémentation, pas structurel au marché. Un acheteur peut donc légitimement traiter la rétention comme un critère de différenciation, au même titre que la latence ou la qualité des complétions.
Le tableau comparatif ci-dessous s’en tient strictement à ce que les sources établissent ; il ne chiffre pas ce qui n’est pas chiffré.
| Dimension | Grok Build (SpaceXAI) | Outils comparables (ex. Claude Code) |
|---|---|---|
| Volume synchronisé observé | Dépôt entier, exclusions comprises | Rétention « nettement inférieure » (The Verge) |
| Respect des fichiers exclus | Non honoré avant correctif | Non détaillé par les sources ici |
| Correctif | Drapeau serveur disable_codebase_upload | Sans objet dans le périmètre rapporté |
Pour une équipe qui compare des fournisseurs, la leçon opérationnelle est de ne pas se fier à la promesse marketing de confidentialité, mais de vérifier le comportement réseau réel — exactement la méthode qui a permis de documenter ce cas.
Musk promet une suppression « totale » et défend la rétention
La réponse publique de SpaceXAI se lit sur deux registres qui coexistent mal. Elon Musk affirme d’abord que l’ensemble des données précédemment téléversées sera « complètement et totalement supprimé ». C’est l’engagement attendu face à un incident de ce type : effacer le stock déjà transféré.
Dans un autre message, il ajoute que « les réglages de confidentialité sont toujours respectés » — tout en demandant aux utilisateurs d’autoriser SpaceXAI à conserver leurs données, au motif que c’est « utile pour le débogage ». Les deux affirmations tirent dans des directions opposées. Promettre une suppression totale et solliciter, dans le même mouvement, l’autorisation de conserver, c’est demander à l’utilisateur d’arbitrer un compromis que le comportement par défaut ne lui avait pas soumis.
L’argument du débogage n’est pas illégitime en soi : conserver des données facilite le diagnostic d’incidents et l’amélioration de l’outil. Mais il se heurte à la nature de ce qui était collecté. On peut consentir à partager des journaux d’erreurs ; consentir à ce qu’un tiers conserve ses identifiants de production et la cartographie de son infrastructure relève d’un tout autre calcul de risque. Le consentement n’a de valeur que s’il porte sur un périmètre que l’utilisateur comprend.
Débogage contre confidentialité : l’arbitrage réel
L’objection sérieuse mérite d’être posée sans caricature. Un éditeur d’agent de code a besoin de signaux pour corriger les défauts ; priver l’outil de toute donnée le rend plus difficile à améliorer. La rétention n’est pas, en soi, une malveillance.
Le désaccord ne porte donc pas sur le principe, mais sur trois paramètres : le périmètre, le défaut et la transparence. Le périmètre — dépôt entier plutôt que journaux ciblés — est disproportionné au regard de l’objectif de débogage. Le défaut — conservation par défaut, exclusions ignorées — inverse la charge de la vigilance. La transparence — un contrôle (/privacy) présenté comme la solution alors qu’il n’est qu’un réglage de session — brouille la capacité de l’utilisateur à décider.
Un modèle défendable existe pourtant : collecte minimale, consentement explicite et granulaire, respect strict des exclusions déclarées, et distinction claire entre le correctif structurel et les réglages accessoires. C’est l’écart entre ce modèle et le comportement observé qui fonde la critique, pas le fait de vouloir déboguer.
Ce que doit faire une équipe qui a utilisé Grok Build
Passé l’analyse, l’incident appelle des gestes concrets pour toute organisation ayant fait tourner le client avant lundi. La promesse de suppression, même tenue, ne suffit pas à rétablir l’état antérieur.
La première mesure est la rotation des secrets. Tout identifiant présent dans un dépôt qui a pu être synchronisé — clé d’API, jeton, mot de passe, certificat — doit être considéré comme potentiellement exposé, donc révoqué et régénéré. Effacer un fichier côté serveur ne restaure pas la confidentialité d’une clé qui a quitté le périmètre.
La deuxième mesure relève de la gouvernance : vérifier quels projets ont été ouverts avec l’outil, et lesquels contenaient des données réglementées ou du code sous contrainte contractuelle. Une exposition de données personnelles ouvre des obligations distinctes d’une exposition de code interne. Sur ce point, les obligations de notification en cas de fuite de données conditionnent le calendrier de réponse.
La troisième mesure est méthodologique. Le cas rappelle qu’une politique de confidentialité affichée ne remplace pas l’observation du trafic réel d’un outil. Les équipes sensibles gagnent à inspecter le comportement réseau des agents de code avant déploiement — c’est cette démarche, appliquée par des chercheurs, qui a mis le défaut au jour.
Ce que l’incident annonce pour les agents de code
Grok Build n’est pas un cas isolé par nature : il est le symptôme d’une tension qui va s’accentuer. Plus les agents deviennent capables de raisonner sur un projet entier, plus ils sont incités à en ingérer une part large — et plus l’écart se creuse entre ce que l’utilisateur croit partager et ce que l’outil transfère réellement.
La ligne de défense qui se dessine n’est pas la promesse contractuelle, mais la vérifiabilité. Un contrôle de confidentialité crédible se mesure au comportement réseau observable, pas à une case cochée dans une documentation. Les acheteurs institutionnels commenceront à exiger des preuves — audits de trafic, engagements de rétention zéro vérifiés — plutôt que des déclarations.
Reste une question ouverte que ce dossier ne tranche pas : combien de dépôts ont transité avant lundi, et sous quelle forme les données seront effectivement supprimées. Tant qu’une suppression n’est pas vérifiée de l’extérieur avec la même rigueur qui a servi à documenter la fuite, la promesse reste une promesse.
FAQ
Les données envoyées par Grok Build sont-elles définitivement effacées ?
Elon Musk affirme que l’ensemble des données précédemment téléversées sera « complètement et totalement supprimé ». Mais aucune vérification externe de cette suppression n’est établie par les sources disponibles à ce jour, et la commande /privacy — présentée par ailleurs — n’est qu’un réglage de rétention par session, pas le correctif de fond.
Pourquoi l’envoi du code complet est-il si dangereux ?
Parce qu’un dépôt ne contient pas que du code. Selon Lukasz Olejnik (King’s College London), le périmètre à risque couvre code propriétaire, informations sur des vulnérabilités, données personnelles, détails d’infrastructure et identifiants. Un secret exposé donne un accès direct, sans exploitation supplémentaire — d’où la priorité de révoquer et régénérer les clés concernées.
Les autres assistants de code font-ils pareil ?
Non, selon les éléments rapportés. The Verge indique que Grok Build retenait « nettement plus » de données que des outils similaires comme Claude Code. L’écart situe le problème du côté de l’implémentation de SpaceXAI, pas d’un standard partagé par l’ensemble du secteur.
Sources
- The Verge, « SpaceXAI’s Grok programming tool was uploading its users’ entire codebase to cloud storage », 14 juillet 2026 — lien (reprend les conclusions de Cereblab, la confirmation de Lukasz Olejnik et les déclarations d’Elon Musk).
