C’est une affaire qui part d’un test de sécurité mené à la mi-juillet 2026 par un chercheur connu sous le pseudonyme Cereblab.

Son objectif initial ? Intercepter le trafic réseau généré par Grok Build pour observer précisément ce que l’outil transmettait aux serveurs de xAI. Le volume de données envoyé s’est révélé environ 27 800 fois supérieur à ce que la tâche de codage demandée nécessitait réellement. Pour être sûr de son résultat, le chercheur a même piégé son dépôt de test avec un fichier explicitement exclu de toute lecture par l’IA : il s’est retrouvé, intact, dans les données envoyées à xAI.

La trouvaille devient virale, au point d’obliger SpaceXAI à réagir publiquement sur son compte X, et Elon Musk à promettre lui-même la suppression de toutes les données utilisateur déjà envoyées.

Ce qui s’est réellement passé

Concrètement, quand un développeur utilise Grok Build pour se faire aider sur son code, l’outil a besoin d’envoyer certains fichiers à xAI pour que l’IA puisse répondre, ce qui est le fonctionnement normal de n’importe quel assistant de codage dans le cloud. Le problème découvert ici est différent : en parallèle de cet envoi normal, Grok Build envoyait aussi la totalité du dépôt de code, y compris tout son historique Git, c’est-à-dire l’ensemble des versions passées de chaque fichier, même celles supprimées depuis.

Un développeur qui aurait, par exemple, supprimé un mot de passe de son code un mois plus tôt pouvait donc quand même le voir transmis à xAI.

C’est notamment le cas d’autres utilisateurs de Grok Build, qui ont signalé des résultats similaires à ceux de Cereblab, notamment un utilisateur dont le répertoire complet, contenant clés SSH et bases de données de gestionnaires de mots de passe, avait été ouvert et téléchargé.

Pour compliquer les choses, l’outil proposait un réglage nommé « Improve the model », censé donner le contrôle aux utilisateurs sur ce point, mais ce réglage ne concernait en réalité que l’utilisation des données pour entraîner l’IA, pas leur envoi vers les serveurs de xAI.

Ce qui a été corrigé, et ce qu’il reste à vérifier

xAI a d’abord réagi via un communiqué publié sur son compte X, affirmant respecter la confidentialité et le choix de ses utilisateurs. L’entreprise y explique que les clients ayant activé la rétention zéro (ZDR) ne voient aucune donnée de code conservée, et que pour les autres, la commande « /privacy » permet de désactiver la rétention des données et de supprimer celles déjà synchronisées.

Sauf que, toujours selon Cereblab, ce n’est pas cette commande qui a réellement mis fin au problème. Le blocage effectif des envois de dépôts est venu d’un réglage technique distinct, activé côté serveur et sans aucune annonce publique.

À ce stade, xAI n’a publié aucun avis de sécurité détaillé sur la durée pendant laquelle les données ont été conservées, sur le nombre de comptes concernés ni sur la méthode utilisée pour la suppression promise par Musk.

Dans les commentaires suivant la communication officielle de SpaceXAI, le scepticisme domine largement et l’affaire ne profite pas qu’aux critiques de bonne foi. Sam Altman, patron d’OpenAI et rival direct de Musk sur le marché des IA de codage, a lui-même réagi sur X pour qualifier la situation d’inquiétante.

Un lecteur de Numerama, nous a d’ailleurs fait remarquer un détail qui donne un tout autre relief à ce « Concerning » : c’est justement une formule qu’Elon Musk emploie lui-même très régulièrement pour commenter des actualités venues de l’extrême droite sur X.