Renouvelez tous les secrets vus par Grok Build

Le fichier que personne n'avait ouvert

Le chercheur a posé un leurre. Un fichier unique, déposé dans un dépôt de test, que l'assistant n'a jamais été invité à ouvrir et qu'il n'a jamais cité: un canari. Puis il a placé le trafic derrière un proxy et il a regardé ce que Grok Build, le CLI de programmation de xAI, envoyait réellement vers ses propres serveurs. Le canari est réapparu dans le paquet intercepté. Il avait quitté la machine sans avoir jamais été lu.

L'analyse du trafic publiée sur la version 0.2.93 décrit deux canaux distincts. Le premier est celui que tout le monde attend d'un assistant de code en nuage: un canal de conversation avec le modèle, qui transporte les fichiers que l'agent lit vraiment, pour pouvoir répondre. Le second est un canal de stockage en arrière-plan, qui expédie un instantané de tout l'espace de travail vers un bucket, que l'agent ait consulté ces fichiers ou non.

L'écart entre les deux, c'est toute la découverte. Sur un dépôt de test de 12 gigaoctets, le canal du modèle a transporté environ 192 kilo-octets. Le canal d'arrière-plan a transporté 5,10 gibioctets, en 73 blocs d'environ 75 mégaoctets chacun. Un facteur d'à peu près 27 800. Un canal faisait le travail. L'autre recopiait l'immeuble.

Parmi les fichiers partis figurait un .env suivi par le gestionnaire de versions, la convention même que les développeurs emploient pour garder ce qui ne doit jamais voyager: clés d'API, mots de passe de bases de données. Il est parti tel quel, sans le moindre masquage.

Le bouton à l'écran n'était pas le bouton sur le fil

Tout outil de développement assisté par IA propose aujourd'hui une case qui dit, sous une forme ou une autre, "aidez-nous à améliorer le modèle". C'est le réglage sur lequel les achats posent des questions, celui que le délégué à la protection des données inscrit dans son analyse, et celui que le responsable technique montre du doigt quand on lui demande si le code est en sécurité.

Le chercheur l'a désactivée. Puis il est allé voir ce que le serveur, lui, en pensait. Le point de terminaison des réglages continuait de renvoyer trace_upload_enabled à true. Les téléversements se sont poursuivis.

C'est la partie qu'il faut séparer du titre. Le défaut n'est pas qu'un assistant de code envoie du code à un serveur: c'est la prémisse même d'un assistant en nuage, et la raison pour laquelle on lit les conditions avant d'en installer un. Le défaut, c'est que le réglage de consentement et le chemin des données n'ont jamais été reliés l'un à l'autre. La case gouvernait l'entraînement. Le téléversement passait par un autre tuyau, et rien à l'écran n'atteignait ce tuyau.

Un contrôle qui ne contrôle rien est pire que pas de contrôle du tout, parce qu'une équipe qui le voit cesse de chercher.

Le vrai enseignement: un correctif côté serveur

Le 13 juillet 2026, les téléversements se sont arrêtés. Ce qui instruit, c'est la manière. Aucune nouvelle version du client, aucun changement de numéro, aucune ligne de journal des modifications à relire et à valider. Le même binaire 0.2.93 a simplement cessé d'émettre des requêtes de stockage, parce que le serveur s'est mis à répondre avec un nouvel indicateur qui désactivait le téléversement du code. Elon Musk a déclaré que les données déjà envoyées seraient, selon ses mots, "complètement et totalement supprimées".

Relisez cette séquence du point de vue de la gouvernance. Le comportement du logiciel installé sur les portables de vos développeurs a été modifié à distance, par l'éditeur, sans toucher à l'artefact que vous aviez approuvé. Ce qui veut dire qu'il aurait pu être modifié dans l'autre sens, par le même moyen, et que de votre côté rien n'aurait eu l'air différent.

C'est la leçon structurelle, et elle dépasse largement xAI. Si le comportement d'un outil en matière de données dépend d'indicateurs côté serveur, alors auditer le client une fois vous dit ce qu'il faisait le jour où vous l'avez regardé. Cela ne vous dit rien de ce qu'il fait aujourd'hui. Figer une version, lire les notes de publication et signer, c'est un processus conçu pour des logiciels qui embarquent leur comportement dans le binaire. La plupart des outils d'IA ne le font plus.

xAI n'a publié ni la raison d'être de ces téléversements, ni la durée de conservation des données, ni la liste de ceux qui pouvaient y accéder, ni le nombre d'utilisateurs touchés. Ces quatre réponses sont exactement ce dont un client a besoin pour dimensionner l'incident, et leur absence est déjà une information.

Ce qu'une équipe européenne doit maintenant à ses clients

Partez de l'hypothèse dont l'erreur coûte le moins cher: considérez comme divulgué tout secret ayant vécu dans un dépôt ouvert avec Grok Build. Renouvelez les clés d'API, les identifiants de bases de données, les clés de signature et les jetons. Faites-le en fonction des dépôts qui ont été ouverts, et non des fichiers que vous croyez que l'assistant a lus, car c'est tout l'objet de la découverte: ces deux ensembles ne coïncident pas.

Regardez ensuite ce que contenaient ces dépôts. Du code source, c'est un problème commercial. Des données personnelles, ou des identifiants donnant accès à des systèmes qui hébergent des données personnelles, c'est un problème juridique. Au sens du RGPD, un fournisseur d'IA qui traite votre dépôt sur votre instruction est un sous-traitant, et la copie de ce dépôt atterrissant dans un bucket de stockage en dehors de la finalité convenue est une divulgation qu'il faut apprécier. En cas de violation de données à caractère personnel, c'est à la CNIL que le responsable de traitement français notifie, et le délai court depuis le moment où vous en avez eu connaissance, pas depuis celui où xAI corrige.

Les entités essentielles et importantes au sens de NIS2 doivent traiter l'affaire comme un incident de chaîne d'approvisionnement, la consigner comme telle et se référer à l'ANSSI, autorité nationale de cybersécurité et point de référence NIS2 en France. Car c'est bien de cela qu'il s'agit: un défaut dans le produit d'un fournisseur a déplacé vos données là où vous ne l'aviez pas choisi.

Rien de tout cela n'exige de savoir avec certitude ce que xAI a fait des données. Il suffit que vous ne puissiez pas prouver aujourd'hui que cela n'a rien changé.

Comment acheter un outil de code IA après cela

Le changement utile n'est pas l'interdiction. Les équipes qui bannissent purement et simplement les assistants de code découvrent le plus souvent que leurs développeurs en ont installé un quand même, et que plus personne ne le consigne. Le changement utile, c'est de cesser de considérer le client comme la frontière.

Posez trois questions à un éditeur avant que l'outil suivant n'arrive sur un portable. Vers quels points de terminaison parle-t-il, et pouvons-nous le constater sur notre propre réseau plutôt que dans votre documentation? Votre serveur peut-il changer ce que le client installé envoie sans livrer une nouvelle version, et si oui, qu'est-ce qui nous prévient quand cela arrive? Si un réglage est désactivé chez nous, quelle est sa représentation côté serveur, et nous laisserez-vous la vérifier?

Rendez ensuite les réponses vérifiables plutôt que contractuelles. Un proxy et un après-midi ont suffi à produire cette découverte. C'est un contrôle moins cher que n'importe quel questionnaire d'assurance, et le seul qui mesure un comportement au lieu d'une intention. Quant aux secrets, ils n'ont rien à faire dans un dépôt qu'un agent de code peut voir: l'injection de variables d'environnement à l'exécution et un coffre à secrets géré font passer cette classe d'incident d'une violation de données à un simple haussement d'épaules.

Ces outils valent la peine. Ce qui n'en vaut aucune, c'est un processus de revue qui lit l'étiquette et ne regarde jamais le fil.

À lire ensuite: Le prix des wafers grimpe sur chaque noeud avancé  |  Aucun labo d'IA n'a dépassé un C+ en sécurité