Sécurité des agents IA : le cas Grok et Lego
Une capture d’écran de Grok a exposé une commande Lego et montré les risques des achats par IA. Découvrez les failles et les bons réflexes à adopter.
Une commande Lego, Grok et un rappel utile : un agent IA n'est pas un acheteur sans risque
Une capture d'écran publiée sur X a suffi à transformer une démonstration d'achat par intelligence artificielle en cas d'école. Elon Musk expliquait que Grok pouvait l'aider à commander des boîtes Lego Star Wars. Mais l'image montrait aussi plusieurs éléments liés à la commande : son numéro, le montant payé, des adresses de facturation et de livraison, une adresse e-mail, et même les quatre derniers chiffres d'une carte bancaire.
Par la suite, certains utilisateurs ont affirmé avoir exploité ces informations auprès du service client de Lego pour modifier ou annuler la commande. Lego n'a pas confirmé l'histoire, et la marque n'a pas souhaité répondre à WIRED. Musk, de son côté, a indiqué que sa commande n'avait finalement pas été annulée. Autrement dit : prudence. On doit distinguer ce que disent les captures, ce que racontent les publications sur X, et ce qui a réellement été fait dans les systèmes de Lego.
L'incident est quand même instructif. Il rappelle que les achats automatisés ne déplacent pas seulement la question « pratique ou pas pratique ». Ils déplacent aussi le risque : vers les données partagées, vers ce que l'agent a le droit de faire, et vers les mécanismes de vérification du marchand. Voici ce que l'on sait, ce que cela suggère, et les précautions à prendre avant de déléguer un achat à une IA.
Ce qui s'est passé entre Grok, X et Lego
L'histoire commence par une démonstration publique. Sur X, Elon Musk explique que Grok peut l'aider à acheter des produits en ligne. Pour étayer son propos, il publie une capture d'écran associée à une commande de Lego Star Wars. L'image ne montre pas seulement les articles : elle laisse également apparaître des détails qui permettent d'identifier et de suivre l'achat.
D'après WIRED, un utilisateur de X, sous le nom d'Enderman, a ensuite publié des captures de conversations avec l'assistant de Lego. Il affirmait avoir obtenu l'annulation de la commande en fournissant l'adresse e-mail et le numéro de commande visibles sur la capture. Musk a répondu quelques heures plus tard en disant que la commande n'avait pas été annulée.
Un autre utilisateur a aussi prétendu avoir réutilisé les mêmes informations pour modifier la livraison : augmenter la quantité et changer l'adresse. Les captures montraient l'assistant de Lego répondant favorablement. Mais là encore, ça ne suffit pas à prouver que la commande a été modifiée ni que les produits ont été expédiés. Lego n'a pas confirmé ces actions auprès de WIRED.
Cette nuance compte. Une capture d'écran peut montrer une conversation avec un chatbot sans prouver que l'opération a été validée dans le système de commande, qu'elle a passé les contrôles antifraude, ou qu'un employé l'a approuvée. Il serait donc exagéré de conclure à une fraude « avérée » ou à une compromission certaine des systèmes de Lego.
En revanche, la publication initiale soulève un vrai problème : des informations qui auraient dû rester privées ont été mises sous les yeux de tout le monde. Et une commande en ligne n'est pas protégée uniquement par le mot de passe du compte. En service après-vente, certains parcours utilisent plusieurs éléments de contexte - numéro de commande, adresse e-mail, code postal ou coordonnées de livraison - pour retrouver l'achat et répondre à une demande.
Ici, les détails visibles sur l'image auraient pu être suffisamment exploitables pour que des tiers tentent des actions via le service client. Le risque n'est donc pas forcément une intrusion technique sophistiquée. Il peut venir d'enchaînements plus « banals » : une donnée exposée, une vérification trop facile à contourner, puis une action sensible accessible depuis un assistant.
Pourquoi un numéro de commande peut devenir sensible
Un numéro de commande ressemble souvent à une simple référence, comme un ticket de caisse. Sauf que ce n'est pas toujours aussi inoffensif. Tout seul, il ne dit pas grand-chose. Avec une adresse e-mail, un nom, ou une adresse de livraison, il devient une pièce en plus dans un mécanisme d'identification.
C'est là que l'agrégation entre en jeu : chaque information prise séparément paraît limitée, mais leur combinaison peut faire le reste. Un attaquant n'a pas forcément besoin d'un mot de passe si, en face, il arrive à convaincre un service client qu'il est bien le titulaire de la commande. Le risque dépend alors de la manière dont le marchand vérifie l'identité et de la nature des actions qu'il autorise une fois l'identité « reconstruite ».
Les données exposées n'ont pas toutes la même valeur
La capture évoquée dans l'article contenait plusieurs types d'informations. Elles ne se valent pas toutes en sensibilité, mais leur combinaison mérite de l'attention :
- Le numéro de commande peut aider à retrouver l'achat ou à servir de référence lors d'un échange avec le service après-vente.
- L'adresse e-mail permet de relier la commande à un compte et peut aussi faciliter des messages ciblés de type hameçonnage.
- Les adresses de facturation et de livraison apportent des informations personnelles et peuvent aider à rendre une demande frauduleuse plus crédible.
- Le montant payé et le contenu du panier donnent des indices sur les habitudes d'achat et peuvent servir à construire un message trompeur.
- Les quatre derniers chiffres de la carte ne suffisent généralement pas pour payer, mais peuvent participer à une tentative d'usurpation ou à une « mise en confiance » auprès d'un interlocuteur.
Le point important : ne pas confondre exposition partielle et vol complet des données bancaires. L'article ne rapporte pas que le numéro complet de carte, sa date d'expiration ou son cryptogramme ont été divulgués. Il ne rapporte pas non plus qu'un paiement non autorisé aurait été effectué. La prudence consiste à évaluer le risque correctement, sans minimiser l'exposition, ni annoncer une compromission qui n'est pas établie.
Le service client devient une partie de la surface d'attaque
La sécurité d'un achat ne se limite pas au paiement. Elle dépend aussi des opérations possibles après la commande : annuler, modifier une quantité, remplacer une adresse, demander un remboursement, ou réinitialiser l'accès à un compte. Si une simple conversation suffit à lancer ces actions à partir de données visibles, alors le parcours de support devient un point sensible.
Un chatbot ne crée pas à lui seul une faille. Mais il peut rendre ces démarches plus rapides et plus fluides, et donc augmenter l'enjeu des contrôles placés derrière l'interface. La vraie question n'est pas seulement « le bot comprend-il la demande ? », mais « comment le système prouve-t-il que la personne qui parle est autorisée à agir ? ».
Pour un marchand, ces contrôles doivent être proportionnés à l'impact. Répondre à une question sur des horaires de livraison n'a pas le même risque que changer une adresse après paiement. Une action sensible peut exiger une authentification supplémentaire, une confirmation envoyée à l'adresse enregistrée, voire une validation humaine. La fluidité côté chatbot ne doit pas effacer ces différences.
Les risques propres aux achats réalisés par un agent IA
Un agent IA ne se contente pas forcément de rédiger une recommandation. Selon les outils et les autorisations qu'on lui donne, il peut rechercher un produit, comparer des prix, remplir un panier, et parfois finaliser une transaction. Utile, oui. Mais l'agent devient alors un intermédiaire opérationnel : entre l'utilisateur, le marchand et le moyen de paiement.
Le samedi précédant l'incident, Musk avait évoqué l'idée de demander à Grok de trouver des offres et d'acheter des produits, en s'aidant notamment d'une image de carte bancaire. En théorie, le principe paraît simple : l'utilisateur donne une instruction, l'agent exécute les étapes. En pratique, chaque étape doit être inspectée.
- Où sont traitées les données de paiement ?
- L'agent peut-il acheter sans confirmation explicite ?
- Quel site choisit-il ?
- Peut-il distinguer une boutique légitime d'une imitation ?
- Que se passe-t-il si le prix, la quantité ou l'adresse ne correspondent pas à l'intention de départ ?
L'agent peut se tromper de site ou d'offre
Quand un agent navigue sur le Web, il hérite des mêmes risques que n'importe quel utilisateur. La différence, c'est qu'il peut décider plus vite et sans « ressentir » certains signaux de confiance. Un site frauduleux peut copier l'apparence d'une boutique connue, afficher un prix anormalement bas, ou présenter des informations pensées pour contourner un processus automatisé.
Visa a notamment alerté sur des acteurs qui mettent en place des sites ressemblant à de vrais commerces afin d'attirer des robots acheteurs avec des prix très bas. Son analyse mentionne aussi une hausse des transactions lancées par des robots malveillants au second semestre 2025, particulièrement aux États-Unis. Ça ne veut pas dire que tous les achats par agent sont dangereux. Ça rappelle surtout que l'automatisation peut être ciblée, et que le prix seul n'est pas une preuve de fiabilité.
La délégation peut être trop large
« Achète-moi ce produit » semble clair, mais pour un logiciel, il reste beaucoup d'inconnues : le modèle exact, la taille, la quantité, le vendeur, les frais de livraison, le délai, la politique de retour. Si l'agent a accès au moyen de paiement et une autorisation permanente, une mauvaise interprétation peut vite devenir une dépense réelle.
On retrouve ici un principe de base de la sécurité : limiter les privilèges au strict besoin. Pour un achat ponctuel, il n'est généralement pas nécessaire qu'un agent conserve un accès large et durable à une carte bancaire, ni qu'il puisse agir sans validation. Une autorisation limitée à un montant, un marchand ou une transaction précise réduit le risque d'erreur, sans le supprimer entièrement.
L'IA ne remplace pas les contrôles du marchand
Même si l'agent exécute correctement la demande, le commerçant doit continuer à détecter ce qui sort de l'ordinaire : quantité inhabituelle, changement d'adresse après validation, modifications répétées sur une courte période, etc. Dans l'affaire Lego, WIRED indique que des garde-fous internes auraient pu détecter une activité anormale. Mais le média ne peut pas confirmer ce qui s'est réellement passé. On ne peut donc pas affirmer que ces contrôles ont été activés, ni qu'ils ont empêché une modification.
Pour les entreprises qui déploient des assistants, le sujet va au-delà du chatbot. Il faut cartographier les actions auxquelles l'agent donne accès, les données qu'il peut consulter, et les contrôles appliqués aux opérations sensibles. Un agent conversationnel peut être agréable à utiliser tout en s'appuyant sur des autorisations trop faibles. Ce n'est pas « la faute de l'IA » au sens large ; c'est un défaut d'architecture du système.
Les bons réflexes avant de déléguer un achat
Les achats par IA peuvent vraiment aider : comparer des produits, accélérer des tâches répétitives, gagner du temps. Le bon réflexe, ce n'est ni de leur faire confiance aveuglément, ni de les rejeter par principe. Il faut définir ce que l'agent peut faire, quelles données il reçoit, et à quel moment une validation humaine devient obligatoire.
Pour les particuliers : réduire l'exposition et garder le contrôle
Avant de confier un achat à un agent, appliquez une règle simple : l'autorisation doit être aussi limitée que possible et aussi visible que nécessaire.
- Ne publiez pas de capture d'écran de commande sans la vérifier. Masquez le numéro de commande, les coordonnées, les détails de paiement et les identifiants de compte. Une image « pour montrer » une fonctionnalité contient souvent plus d'éléments qu'on ne pense.
- Évitez d'envoyer une photo de carte bancaire dans une conversation. Préférez un paiement intégré au service, des cartes virtuelles, ou des options qui limitent plafond et durée d'utilisation.
- Demandez une confirmation avant le paiement. Vérifiez le vendeur, la référence exacte, la quantité, le prix total, les frais et l'adresse de livraison. Une validation humaine n'est pas une formalité inutile dès que votre argent est en jeu.
- Préférez les autorisations ponctuelles. Si le service le permet, autorisez une seule transaction plutôt qu'un accès réutilisable. Révoquez les permissions une fois l'opération terminée.
- Surveillez les notifications bancaires et les confirmations de commande. En cas d'opération inattendue, contactez rapidement votre banque et le marchand via leurs canaux officiels.
- Ne prenez pas un message du chatbot comme preuve d'exécution. Vérifiez le statut dans votre compte client ou dans une confirmation officielle.
En France et dans l'Union européenne, les moyens de paiement sont encadrés, et les données personnelles relèvent notamment du RGPD. Cela n'empêche pas les erreurs ni les abus. Le RGPD encadre le traitement des données par les organisations ; il ne remplace pas la vigilance sur ce qu'on publie, ni les mécanismes de sécurité propres à un compte marchand.
Pour les entreprises : séparer conversation et autorisation
Les équipes qui intègrent un agent dans un parcours d'achat devraient dissocier la capacité de comprendre une demande de la capacité à l'exécuter. Le modèle peut préparer une opération ; ensuite, un système distinct doit vérifier si elle est autorisée et si les conditions sont réunies.
Une façon pragmatique de procéder est de classer les actions selon le niveau de risque :
- Information sans conséquence : consulter une politique de retour ou un délai de livraison.
- Préparation réversible : rechercher un produit ou remplir un panier sans payer.
- Action financière : passer commande, modifier une quantité, ou déclencher un remboursement.
- Action sur les données personnelles : changer une adresse ou transmettre des informations à un tiers.
Plus une action est difficile à annuler ou peut causer un préjudice, plus le contrôle doit être strict. Cela peut impliquer une authentification renforcée, une validation explicite, une limite de montant, un délai de sécurité, ou une intervention humaine. Et ça doit inclure la journalisation, la réduction des données accessibles à l'agent, ainsi que des tests de scénarios d'abus - pas uniquement une démonstration du « parcours idéal ».
Cette logique vaut aussi pour les prestataires. Une entreprise ne devrait pas supposer qu'un outil est sûr parce qu'il est présenté comme un assistant « officiel » ou parce qu'il s'appuie sur un grand modèle de langage. Il faut savoir quelles données sont transmises, combien de temps elles sont conservées, quels outils l'agent peut appeler, et comment les erreurs sont corrigées. Ce sont des questions de conception et de gouvernance, pas des cases à cocher après coup.
Au fond, l'incident de la commande Lego ramène une règle simple : automatiser l'exécution ne supprime pas la responsabilité de cadrer les permissions. Un agent peut gagner du temps. Il ne devrait pas, lui, gagner du pouvoir.