L'agent est déjà à la porte de la caisse : ce qui se passe dans vos systèmes quand celui qui achète est une machine

Un client dit à son assistant d'IA : « Achetez-moi les baskets noires, pointure 27, et faites-les arriver vendredi ». L'assistant ouvre la boutique en ligne, choisit le produit, remplit l'adresse de livraison et arrive à l'écran de paiement. Là, il s'arrête et demande au client : « Je confirme ? ». Le client touche un bouton. La commande entre dans votre système.

Regardez cette scène du côté de votre entreprise. Jusqu'au bouton, celui qui a visité votre boutique n'était pas une personne. Et après le bouton, votre activité doit encaisser, facturer, expédier, rapprocher et, si quelque chose tourne mal, répondre d'un achat qu'aucun de vos systèmes n'a vu naître comme d'habitude.

Ce n'est plus une hypothèse de laboratoire. Cet article s'adresse aux responsables des ventes, des finances, des opérations ou de la technologie dans une banque, une fintech, un assureur, une chaîne de distribution ou une entreprise réglementée. Il vous propose de laisser de côté la question à la mode —les agents vont-ils acheter seuls ?— pour en poser une plus utile : que se passe-t-il dans mes systèmes quand ce qui arrive à la caisse est une machine ? Selon votre rôle, la question change : pour un commerçant, ce sont le catalogue, la commande, le CFDI et les retours ; pour un émetteur, les plafonds, le consentement et la révocation ; pour un acquéreur ou un processeur de paiements, l'acceptation, les signaux et le litige ; pour une entreprise réglementée, l'autorisation, la traçabilité et les données.

Ce qui s'est passé, et ce qui ne s'est pas passé

Fin septembre 2026, Shopify a documenté (le 28 septembre) que les agents d'IA qui opèrent dans un navigateur peuvent désormais utiliser quatre outils sur son écran de paiement : aller à la boutique, lire l'état de la commande, mettre à jour les données d'expédition et de livraison, et envoyer la commande. Ces outils fonctionnent à l'intérieur du même checkout web qu'utilise une personne et avec le même état que voit l'interface [1].

La nuance compte : l'outil qui envoie la commande le fait après la confirmation de l'acheteur [1]. Selon la documentation, en outre, le contrôle revient à la personne lorsque la vérification supplémentaire 3D Secure est requise, l'étape par laquelle la banque émettrice vérifie que le titulaire de la carte est bien celui qui paie [1].

Autrement dit : dans le flux que Shopify a documenté, l'agent prépare et la personne confirme ; d'autres schémas, comme AP2, envisagent déjà des achats autonomes sous autorisation préalable du client [7]. Parler d'« acheter seuls » dans ce cas serait une exagération. Ce qui est vrai est plus inconfortable et plus proche : dans le flux documenté par Shopify, l'agent arrive déjà jusqu'à la porte de l'encaissement, sans que la boutique lui ouvre une porte spéciale : selon Shopify, ces outils n'exposent pas de nouvelle interface et n'exigent aucune configuration de la part du commerçant [1].

Deux autres informations ont été rapportées, et il convient de les traiter pour ce qu'elles sont. Selon des déclarations d'un porte-parole rapportées par GeekWire, Amazon bloque Muse, l'agent d'achat de Meta, entre autres parce qu'il ne s'identifie pas lorsqu'il navigue dans la boutique [2]. Infobae a rapporté qu'Adidas aurait fait quelque chose de semblable, sans confirmation de l'entreprise [2]. Aucun des deux cas ne démontre une tendance du marché.

Une donnée de contexte, pour ne pas gonfler les attentes. Dans une enquête de Visa et Harris Poll de mai 2026 aux États-Unis (2 065 consommateurs ; la question sur les paiements a été posée à un sous-échantillon d'environ 1 030 personnes), 23 % ont dit faire confiance à l'IA générative pour effectuer des paiements en leur nom [3]. C'est une enquête d'un prestataire de paiement, dans un autre pays, et elle ne mesure pas un volume d'achats. Dans notre revue au 17 octobre 2026 des sites et communiqués des protocoles et des réseaux cités ici, nous n'avons trouvé aucun chiffre public sur le volume de transactions réelles effectuées par des agents. Ce qui existe, c'est l'infrastructure, et c'est ce que vous devez examiner.

Cinq choses que votre entreprise doit résoudre

Toutes découlent d'une seule idée : de nombreux flux de commerce électronique présupposent encore une session humaine, avec une carte à elle et une adresse e-mail. Un agent peut briser chacune de ces hypothèses séparément.

1. Identité : ouvre-t-on la porte ou la bloque-t-on ?

Beaucoup de filtres contre le trafic automatisé ne distinguent pas le scraping de prix d'un client assisté par un agent : ils traitent les deux comme un robot. Cela protège votre site du scraping de prix et des attaques, mais peut aussi rejeter, à votre insu, de vrais clients qui achètent par l'intermédiaire d'un assistant.

Visa et Mastercard documentent déjà des mécanismes pour identifier les agents. Le protocole d'agent de confiance de Visa permet à un commerçant de distinguer un agent légitime d'un robot au moyen de signatures cryptographiques liées au commerçant et à l'objet de la visite, de courte durée et non réutilisables [4]. Il s'appuie sur une norme ouverte de signature de messages HTTP, la RFC 9421 [5]. Mastercard, de son côté, a annoncé que son cadre d'acceptation d'Agent Pay exige d'enregistrer et de vérifier l'agent avant toute transaction [6].

Ce qu'aucune de ces pièces ne décide à votre place, c'est la politique : quels agents entrent, avec quelles limites de consultation et de montant, et qui tient la liste. Et les deux options ont un coût. Tout bloquer peut faire perdre des ventes déjà acquises. Ouvrir sans critère expose votre catalogue, vos prix et votre stock à des consultations massives. Identifiez qui, dans votre organisation, est responsable de cette décision.

2. Autorisation : qui a dit oui à ce paiement ?

Quand une personne achète, l'autorisation est à l'écran : elle saisit, confirme, la banque valide. Avec un agent, cela dépend du schéma. Il existe des flux dans lesquels l'acheteur confirme toujours au checkout, comme celui de Shopify et celui du protocole d'OpenAI et de Stripe [1][9]. Mais dans les schémas délégués ou préautorisés, la permission a été donnée avant, ailleurs, et votre entreprise a besoin d'une preuve qu'elle a été donnée.

Les protocoles abordent ce problème avec des idées voisines. AP2, de Google, utilise des « mandats » signés : une permission du client avec des règles —plafond de prix, durée de validité— et un panier approuvé, qui cherchent à laisser une trace vérifiable de ce qui a été autorisé [7]. Visa combine un jeton de paiement conçu pour les agents avec une vérification renforcée du titulaire par passkey (clé d'accès) [8]. Le protocole d'OpenAI et de Stripe utilise un jeton de paiement délimité qui n'expose pas la carte du client et laisse le commerçant responsable de la vente [9].

Pour une entreprise, apparaît un troisième type d'identifiant qui n'est ni la carte du client ni son portefeuille : un jeton au montant, au commerçant et à la durée limités, détenu par un programme. Dans les flux qui utilisent des identifiants délimités, confirmez avec votre processeur de paiements ou votre acquéreur comment ils sont reçus, validés et rapportés ; le mécanisme dépend du protocole et du circuit de paiement. Pour une banque émettrice, la question est autre : comment présenter au client ce que son agent peut dépenser, et comment le lui retirer.

3. Litiges : qui répond quand l'agent se trompe ?

Pensez à une rétrofacturation (chargeback) avec un motif nouveau : « je n'ai pas commandé cela ; mon agent s'est trompé ». Est-ce une erreur du client, du commerçant, de la plateforme de l'agent ou de l'émetteur ? Les protocoles cherchent à conserver la preuve de l'instruction d'origine : AP2 avec ses mandats [7] et Visa avec ce qu'il appelle des « signaux commerciaux » pour résoudre les litiges [8].

Mais preuve n'est pas critère. Dans notre revue au 17 octobre 2026 des publications de la CNBV, de Banxico et de la CONDUSEF (le régulateur bancaire, la banque centrale et l'organisme de protection des usagers financiers du Mexique), nous n'avons trouvé aucune règle mexicaine qui attribue expressément la responsabilité d'une erreur d'un agent ; ce n'est pas une revue juridique exhaustive. Examinez les contrats de réseau et d'acquisition et les obligations applicables avant de fixer une politique. D'ici là, la protection de votre entreprise dépend de ce que vous pouvez démontrer : quelle instruction a été reçue, de quel agent, avec quelle permission et ce que votre boutique a montré à ce moment-là. Il convient de décider dès aujourd'hui quelle preuve on conserve et pour combien de temps, selon la politique de conservation applicable, car la reconstituer après le premier litige peut être impossible.

4. Données fiscales : à qui facture-t-on ?

C'est ici le problème le plus local et le plus facile à négliger. Au Mexique, le CFDI 4.0 (la facture électronique mexicaine, dans sa version 4.0) exige des données du destinataire : son RFC (identifiant fiscal), son nom ou sa raison sociale, son régime fiscal et le code postal de son domicile fiscal [10]. Une personne les saisit dans un formulaire, ou son compte les a déjà. Un agent peut ne pas les porter.

Sans les données du destinataire, un CFDI nominatif ne pourra pas être émis (« timbré », selon le terme mexicain : la validation de la facture électronique par un prestataire agréé) pendant le checkout. Votre équipe a alors trois voies, et les trois coûtent : demander les données au client après coup, avec la friction et le décalage que cela entraîne ; appliquer une politique de facturation différée ; ou inclure l'opération dans la facture globale (factura global), qui s'applique aux opérations avec le grand public, dans les conditions de la règle 2.7.1.21 de la Resolución Miscelánea Fiscal (les règles fiscales annuelles du Mexique) [14], et qui ne remplace pas le CFDI nominatif lorsque le client le demande. Aucune des sources consultées ne tranche la question de savoir qui est le destinataire fiscal d'un achat réalisé par l'intermédiaire d'un agent. C'est une question ouverte et il convient d'y répondre avant que les cas ne se multiplient.

5. Fraude : comment distinguer un achat légitime d'un achat volé ?

Les modèles de risque qui protègent un commerçant se nourrissent, en grande partie, de signaux d'une personne : l'appareil, le schéma de navigation, l'heure, le rythme de frappe. Quand un agent intervient, ces signaux peuvent manquer : le trafic vient d'un programme, et les modèles calibrés pour le trafic humain peuvent devoir être revalidés.

Cela oblige à revoir les règles, à décider quand demander une confirmation humaine supplémentaire et à intégrer les signaux nouveaux qu'offrent les réseaux. Et cela oblige à quelque chose de plus élémentaire : savoir que la commande est venue d'un agent. Si cette information ne reste pas enregistrée dans la commande, avec celui qui a autorisé, le rapprochement et la défense face à une rétrofacturation deviennent du travail manuel. Il en va de même pour les retours : définissez avec votre acquéreur le circuit par lequel ils repartent.

Les protocoles, par couche

Les noms se multiplient —ACP, UCP, AP2, Visa, Mastercard— et il est facile de croire qu'il faut en choisir un. Ils ne sont pas en concurrence pour la même chose : chacun résout une couche différente. Et ils sont à des stades de maturité différents, qu'il vaut mieux ne pas confondre.

Une entreprise pourrait finir par parler plusieurs de ces protocoles à la fois. D'où l'idée que la question utile n'est pas « lequel adoptons-nous ? », mais « que doivent avoir résolu mes systèmes pour parler n'importe lequel d'entre eux ? ».

Ce qu'ils ont en commun est ce qui vous revient : un catalogue, des prix et un stock qu'une machine puisse consulter par interface et sans personne entre les deux ; une commande qui enregistre son origine ; et un dossier de qui a autorisé quoi.

Scénario : une boutique en ligne avec 10 000 commandes par mois

Scénario illustratif, avec des chiffres inventés pour montrer l'effet. Il ne décrit aucune entreprise.

Une boutique en ligne reçoit 10 000 commandes par mois. Supposez que 3 % commencent à arriver par des agents : 300 commandes. Jusqu'ici, un chiffre modeste. Supposez maintenant qu'un cinquième de ces clients demande une facture et que l'agent n'a pas porté le régime fiscal ni l'usage du justificatif : cela fait 60 factures qui ne peuvent pas être validées sur le moment.

Si un analyste consacre 15 minutes à chacune, cela fait 15 heures par mois de travail manuel qui n'existaient pas auparavant. Si la part des agents monte à 10 %, ces heures passent à 50. Et nous n'avons pas compté une seule rétrofacturation, un seul retour dû à une commande mal comprise par l'agent, ni un seul rapprochement qui ne trouve pas de quel agent venait l'encaissement.

La leçon de l'exemple n'est pas le chiffre : le scénario permet d'estimer des heures, des retards de clôture et des preuves manquantes.

Ce qu'il convient de faire cette semaine

Vous n'avez pas besoin d'un projet pour commencer. Vous avez besoin de répondre à cinq questions avec les bonnes personnes à la même table :

1. Trafic. Quelle part de ce que votre site rejette comme robot pourrait être l'agent d'un client ? Si vous ne le mesurez pas aujourd'hui, c'est la première réponse.
2. Politique des portes. Qui décide quels agents entrent, avec quelles limites, et quel est le coût de chaque décision ?
3. Preuve. Quand une commande viendra d'un agent, que reste-t-il d'enregistré : qui a autorisé, ce qui a été montré, ce qui a été encaissé ?
4. Facturation. Que fait votre service fiscal d'une commande sans données du destinataire, et qui prévient le client ?
5. Responsabilité. Si l'agent se trompe, qui absorbe le coût : le client, vous, l'émetteur ou la plateforme, et où est-ce écrit ?

Pour que les réponses cessent d'être de l'opinion, il convient de mesurer trois choses que votre équipe peut relever dès aujourd'hui, sans chiffres externes :

• Trafic rejeté comme robot. Quel pourcentage des visites que votre site bloque ou soumet à un défi correspond à des schémas qui pourraient être un agent de client ? Qui le vérifie, et à quelle fréquence ?
• Coût de reconstitution d'une facture. Combien de temps et combien de personnes faut-il aujourd'hui pour refaire une facture quand la commande est arrivée sans données fiscales complètes ? Multipliez-le par le nombre de commandes qui pourraient arriver ainsi.
• Coût d'une rétrofacturation. Combien vous coûte aujourd'hui le traitement d'une rétrofacturation de bout en bout —temps, commission, marchandise et preuve— et combien de plus il coûterait si le motif était « mon agent s'est trompé » ?

Si deux réponses ou plus sont « je ne sais pas » ou « cela dépend de qui répond », ce n'est pas une défaillance de votre équipe : ce sont des questions que personne n'avait à se poser il y a encore quelques mois. Ce qui a changé, c'est que le rythme n'est plus dicté seulement par votre agenda interne : c'est l'écosystème qui le dicte.

Il existe en outre une partie technique qui a déjà son guide. Qu'un agent puisse consulter votre catalogue, réessayer sans dupliquer une commande et recevoir des erreurs qu'il comprend n'est pas un sujet qui concerne seulement le checkout : c'est une propriété de vos interfaces. Nous la développons dans l'article Des API prêtes pour les agents d'IA.

Ce que fait Hábil

Les problèmes ci-dessus ont un point commun : ils surviennent à la jonction entre systèmes. La commande naît dans un canal, l'encaissement dans un autre, la facture dans un troisième et le rapprochement dans un quatrième, et aucun d'eux n'a pour rôle de savoir que celui qui a acheté était un agent. Hábil se consacre à cette jonction : intégrer des systèmes existants dans le but que les opérations laissent une trace de qui les a autorisées et qu'un nouveau canal n'oblige pas à réécrire les précédents.

Si votre entreprise réfléchit à la façon d'accueillir —ou de borner— les agents d'IA, la page Hábil AI explique ce que nous faisons avec eux, et l'article Des API prêtes pour les agents d'IA détaille ce dont votre système a besoin pour qu'un agent l'utilise avec contrôle.

L'étape suivante est simple : écrivez-nous sur WhatsApp. Lors d'une première conversation, sans frais, nous vous disons où l'on perd probablement de l'argent, du temps ou des preuves dans les interfaces de votre activité et s'il vaut la peine de faire un diagnostic approfondi, avec un périmètre convenu.