octobre 16, 2026
ia achat

Comparer des dizaines d’offres, réserver un hôtel, renouveler une commande de fournitures ou payer un service sans ouvrir soi-même chaque site : cette forme de délégation n’est plus seulement théorique. Les agents d’intelligence artificielle commencent à intervenir directement dans les parcours d’achat.

En 2026, plusieurs infrastructures permettent déjà à des agents de sélectionner des produits, de préparer une commande et, dans certains cas, de déclencher son paiement. Visa a annoncé avoir traité des centaines de transactions initiées par des agents, tandis que Mastercard et Santander ont présenté en mars 2026 ce qu’ils décrivent comme la première transaction européenne complète exécutée par un agent IA. Des protocoles comme l’Agentic Commerce Protocol, développé notamment par OpenAI et Stripe, ou les protocoles UCP et AP2 de Google cherchent parallèlement à standardiser ces échanges. Ces annonces montrent que la technologie fonctionne, mais pas encore qu’elle est devenue universelle, parfaitement fiable ou juridiquement stabilisée.

La réponse à la question est donc oui, à condition de ne pas confondre automatisation et abandon de contrôle.

Ce qu’un agent d’achat peut réellement faire

Un agent IA ne se limite pas à afficher une liste de produits comme un comparateur traditionnel. Il peut recevoir un objectif formulé en langage naturel, par exemple :

« Trouve-moi un train pour Lyon vendredi soir, sans correspondance, à moins de 90 euros, avec une option d’annulation. »

Il peut ensuite rechercher les offres disponibles, interpréter les conditions tarifaires, comparer les horaires et présenter la solution qui respecte le mieux les critères. Avec les autorisations appropriées, il peut également remplir les informations personnelles, créer la réservation et transmettre un moyen de paiement au marchand.

Dans les systèmes actuellement déployés, l’agent ne devient toutefois pas lui-même commerçant ou établissement de paiement. Le marchand conserve généralement la maîtrise de la commande, accepte ou refuse la transaction, débite le moyen de paiement par l’intermédiaire de son prestataire habituel et reste responsable de la livraison, du remboursement et du service après-vente.

Cette distinction est essentielle. L’agent orchestre l’achat, mais il ne remplace pas les acteurs juridiques et financiers qui exécutent la transaction.

Peut-il payer sans demander une confirmation ?

Techniquement, oui. Un utilisateur pourrait préautoriser un agent à effectuer certaines dépenses dans un cadre défini : acheter des consommables lorsque le stock devient insuffisant, renouveler un abonnement ou réserver automatiquement un billet lorsqu’un tarif descend sous un seuil précis.

Mais les solutions les plus prudentes maintiennent aujourd’hui une validation humaine avant le paiement. OpenAI indique par exemple que, dans son système de paiement intégré, l’utilisateur confirme explicitement chaque étape et que les jetons de paiement sont limités à un montant et à un marchand déterminés. Il s’agit d’un choix de sécurité, pas seulement d’un obstacle technique.

En Europe, l’authentification forte prévue par la réglementation sur les services de paiement demeure également applicable dans de nombreuses situations. Elle est notamment requise lorsqu’un payeur accède à son compte en ligne, initie une transaction électronique ou réalise à distance une opération présentant un risque de fraude. Un agent ne peut donc pas simplement contourner les contrôles de la banque au nom de la fluidité de l’expérience.

L’autonomie réaliste n’est donc pas nécessairement une autonomie absolue. Elle peut prendre la forme d’une autorisation permanente, mais limitée : plafond de dépenses, liste de marchands autorisés, catégories de produits précises, durée de validité ou confirmation obligatoire au-delà d’un certain montant.

Le premier risque : l’agent peut acheter le mauvais produit

Un agent peut respecter littéralement une consigne tout en produisant un résultat inadapté.

Le billet le moins cher peut être non remboursable. L’hôtel présenté comme proche d’une destination peut se trouver à proximité géographique, mais être mal desservi. Un ordinateur répondant aux caractéristiques demandées peut utiliser un clavier étranger ou être vendu sans le système d’exploitation attendu.

Le problème n’est pas toujours une « hallucination ». Il peut s’agir d’une mauvaise hiérarchisation des critères, d’une information obsolète, d’une ambiguïté dans la demande ou d’une incapacité à comprendre les conséquences pratiques d’une condition contractuelle.

Ces erreurs sont particulièrement coûteuses pour les prestations qui ne bénéficient pas du droit de rétractation habituel. En France, le délai de quatorze jours s’applique à de nombreux achats à distance, mais plusieurs exceptions existent, notamment pour le transport de passagers, l’hébergement et certaines activités de loisirs prévues à une date déterminée. Une réservation erronée peut donc être immédiatement difficile, voire impossible, à annuler sans frais.

Un agent chargé d’acheter ne devrait donc pas seulement comparer les prix. Il doit examiner le prix total, les conditions d’annulation, les frais annexes, les délais, les garanties et la compatibilité exacte du produit avec le besoin.

Le deuxième risque : la fraude et le détournement de l’agent

Un agent de paiement dispose potentiellement d’informations très sensibles : identité, adresse, historique d’achat, préférences, accès à des comptes et autorisations financières.

Il devient donc une cible particulièrement intéressante.

Une attaque dite d’« injection de prompt indirecte » peut, par exemple, cacher des instructions malveillantes dans une page web, une fiche produit ou un document que l’agent doit analyser. Le système peut alors être incité à ignorer ses règles, à divulguer des données ou à exécuter une action non prévue. Le National Cyber Security Centre britannique souligne que les agents autonomes héritent des vulnérabilités des grands modèles de langage, notamment les injections de prompt et les détournements de comportement.

Une seconde menace consiste à usurper l’identité d’un marchand ou à rediriger l’agent vers une fausse interface de paiement. Dans un parcours classique, l’utilisateur peut remarquer une adresse suspecte ou une présentation incohérente. Un agent automatisé peut au contraire traiter ces éléments comme de simples données techniques.

La protection ne doit donc jamais reposer uniquement sur la capacité de raisonnement du modèle. Elle exige des contrôles externes : authentification des marchands, jetons de paiement à usage unique, montants plafonnés, durée d’autorisation limitée, journalisation des actions et possibilité de révoquer instantanément les accès.

Qui est responsable en cas d’erreur ?

C’est la question la moins résolue par les discours marketing.

Un agent IA n’absorbe pas automatiquement la responsabilité de l’utilisateur, de son éditeur, du marchand ou du prestataire de paiement. L’AI Act européen impose certaines obligations aux fournisseurs et aux organisations qui déploient des systèmes d’IA, mais il ne constitue pas un régime général autorisant les agents à effectuer des paiements ni une règle unique déterminant qui indemnise chaque achat erroné. Les règles du paiement, de la consommation, du contrat, de la protection des données et de la responsabilité des produits continuent de s’appliquer.

Le droit français définit traditionnellement le mandat comme l’acte par lequel une personne donne à une autre le pouvoir d’agir en son nom. Un agent logiciel peut exécuter techniquement une autorisation, mais cela ne signifie pas nécessairement qu’il devient lui-même un mandataire juridique classique. La répartition réelle des responsabilités dépendra notamment des contrats conclus avec le fournisseur de l’agent, le marchand et le prestataire de paiement.

La distinction entre transaction autorisée et transaction non autorisée sera déterminante. Si l’agent utilise frauduleusement un moyen de paiement après un piratage, les règles protectrices relatives aux paiements non autorisés peuvent intervenir. Si l’utilisateur avait volontairement donné à l’agent une autorisation trop large, mais que celui-ci a choisi un produit médiocre ou mal interprété les critères, le litige risque d’être plus complexe. La question ne sera plus seulement « Qui a payé ? », mais « Quelle action avait réellement été autorisée ? ».

Une délégation acceptable doit être limitée et vérifiable

La bonne architecture consiste à accorder à l’agent le minimum de pouvoir nécessaire.

Pour des achats occasionnels ou coûteux, l’agent peut rechercher, comparer et préparer la commande, mais laisser la validation finale à l’utilisateur. Pour des dépenses répétitives et peu risquées, une autonomie plus importante peut être acceptable, à condition de prévoir :

  • un plafond par opération et par période ;
  • une liste de marchands ou de catégories autorisés ;
  • une interdiction des achats non remboursables sans confirmation ;
  • un journal détaillé des offres examinées et des décisions prises ;
  • une notification immédiate après chaque transaction ;
  • un bouton de suspension ou de révocation ;
  • des moyens de paiement tokenisés plutôt que l’accès direct aux coordonnées bancaires.

L’agent ne devrait par ailleurs recevoir que les données nécessaires à l’achat. Le principe de minimisation du RGPD impose de limiter la quantité de données traitées, leur accessibilité et leur durée de conservation à ce qui est réellement requis.

Faut-il finalement lui faire confiance ?

Il est raisonnable de déléguer à un agent la recherche, le tri et l’exécution d’achats simples, réversibles et strictement encadrés. Il est beaucoup moins prudent de lui accorder un accès financier général et permanent.

La frontière pertinente ne sépare pas l’achat humain de l’achat automatisé. Elle sépare les décisions facilement réparables des décisions irréversibles, coûteuses ou juridiquement engageantes.

Un bon agent d’achat ne devrait donc pas être jugé uniquement sur sa capacité à finaliser rapidement une transaction. Il devrait être évalué sur sa capacité à expliquer son choix, respecter des limites vérifiables, protéger les données, identifier les conditions défavorables et interrompre l’opération lorsqu’une incertitude subsiste.

L’objectif n’est pas de supprimer l’intervention humaine à tout prix. Il est de la réserver aux moments où elle apporte réellement du contrôle.