Grok Build ajoute une mémoire entre sessions, mais la confidentialité reste en question

xAI a annoncé le 16 septembre 2026 une mémoire entre sessions pour Grok Build, son agent de codage en terminal. La fonction enregistre des conventions, des décisions et des faits de projet sous forme de notes Markdown, puis les relit lors d’une session suivante. Sur le papier, cela doit éviter de répéter les mêmes consignes à chaque relance. Dans le même temps, une analyse indépendante publiée en juillet 2026 soutient que le CLI envoie aussi des contenus de fichiers, puis des snapshots de dépôt entiers vers l’infrastructure de xAI, ce qui relance la question de ce qui persiste vraiment, et où.

Une mémoire qui retient le contexte technique

Selon xAI, la mémoire fonctionne après qu’un tour est terminé. L’agent relit l’échange, extrait ce qui semble durable et l’écrit en notes Markdown, une par sujet. Le stockage est séparé par projet, avec aussi un espace global pour les préférences communes. L’entreprise cite notamment des règles de code, des décisions d’architecture et des faits concrets comme la commande qui lance les tests.

Dans l’exemple fourni, Grok Build confond d’abord cargo test et just test sur un projet nommé orbit. Le premier échec un test d’intégration car la base Postgres n’est pas démarrée. Après correction, la suite passe avec 148 tests, puis une note testing.md enregistre la convention. Lors d’une session ultérieure, l’agent retrouve cette note, modifie src/webhooks.rs et vérifie le changement avec 151 tests réussis. Ce type de mémoire est pratique. C’est aussi le genre de détail que personne n’a envie de réexpliquer à l’infini, sauf peut-être un lundi matin.

Comment Grok Build stocke et relit ses souvenirs

xAI expose plusieurs commandes. /memory ouvre un navigateur en lecture seule des fichiers de mémoire, /dream consolide les observations, /flush pousse la mémoire de conversation vers le disque et /remember enregistre une note directement. La documentation décrit aussi une hiérarchie claire : les notes sont rangées par portée, avec des fichiers de type MEMORY.md, preferences.md, testing.md ou gateway.md.

Le point important est le rappel automatique. Avant de travailler sur un sujet connexe, Grok lit les notes adaptées et les applique, même si le thème n’est pas explicitement réabordé dans la nouvelle session. En cas de conflit, les instructions de la conversation passent avant les notes enregistrées. Autrement dit, la mémoire aide, mais ne prend pas le volant.

La partie qui fâche : ce que l’analyse indépendante dit du CLI

La publication de @cereblab décrit un comportement plus large que la seule mémoire de contexte. Selon cette analyse, Grok Build transmettrait le contenu des fichiers lus, y compris un fichier .env avec des secrets factices, puis uploaderait aussi des fragments de dépôt ou des bundles Git vers grok-code-session-traces, un bucket Google Cloud Storage nommé dans le binaire. Les captures citées mentionnent également des requêtes vers /v1/responses et /v1/storage, ainsi que des appels vers Mixpanel et grok.com.

L’auteur dit avoir testé plusieurs tailles de dépôt, jusqu’à un environnement de 12 GB, avec des transferts de plusieurs gigaoctets et des réponses HTTP 200 pour les envois de stockage. Il affirme aussi qu’un dépôt entier a pu être reconstruit depuis un bundle Git uploadé, avec un fichier jamais ouvert contenant son marqueur d’origine. Les sources précisent toutefois que cela ne prouve pas un entraînement du modèle sur ces données, seulement leur transmission et leur stockage. Le point, ici, est surtout celui de la visibilité : un utilisateur qui pense n’envoyer que du contexte de travail peut découvrir qu’un mécanisme de fond embarque bien plus que prévu.

Le réglage d’opt-out ne suffit pas à fermer la porte

L’analyse de @cereblab soutient que le réglage Improve the model ne coupe pas les envois de dépôt. Même désactivé, le CLI continuerait à uploader le contenu du workspace, tandis que la réponse de /v1/settings afficherait encore des indicateurs comme trace_upload_enabled: true et upload_enabled: true. xAI, de son côté, présente la mémoire comme un moyen d’améliorer la pertinence de l’agent au fil de l’usage. Mais si le dépôt sort de la machine, le sujet n’est plus seulement la mémoire. Il devient aussi celui du contrôle des flux.

Dans ses documents publics, xAI insiste sur la personnalisation et l’opt-out côté amélioration du modèle. L’analyse indépendante répond que cela ne couvre pas, à elle seule, la mécanique d’upload observée sur le CLI. Les deux lectures peuvent coexister sans se contredire frontalement : l’une parle d’usage, l’autre de transport de données. Pour les équipes techniques, la différence compte énormément, car elle change le périmètre à auditer avant d’adopter l’outil.

Un lancement utile, mais pas anodin pour les équipes techniques

Grok Build est présenté comme un agent de codage pour des tâches complexes, désormais propulsé par Grok 4.6 et disponible en essai gratuit. La mémoire persistante peut réduire les répétitions, lisser le travail en équipe et garder trace des conventions locales. En contrepartie, l’outil remet au premier plan une question très concrète : quelles données restent en mémoire, lesquelles quittent le poste, et à quel moment. La réponse n’est pas la même selon qu’on parle d’une note Markdown ou d’un dépôt entier. Et ce n’est pas un détail de comptable, même si les logs adorent les colonnes bien rangées.

À ce stade, les sources concordent sur un point : la mémoire entre sessions existe, et elle s’appuie sur des fichiers de contexte persistants. Elles divergent sur l’étendue réelle des transferts vers xAI. L’analyse indépendante affirme avoir documenté des envois de fichiers et de dépôts complets ; xAI, elle, met en avant la continuité de travail et la consolidation de notes. Pour les entreprises, la question pratique reste simple : avant de brancher un agent de terminal sur un dépôt sensible, il faut savoir s’il retient seulement le contexte ou s’il emporte aussi le code.