Article
Agentic commerce en retail : adapter l’infrastructure paiement aux transactions initiées par des IA
Un client ne compare plus toujours les prix lui-même. De plus en plus souvent, c’est un assistant qui achète à sa place, à l’heure qu’il veut, sans jamais ouvrir votre application.
Les agents IA commencent à initier des achats de façon autonome, pour le compte des utilisateurs. Or, le parcours de paiement classique a été pensé pour des utilisateurs humains. Ces derniers saisissent leurs coordonnées, valident une authentification 3DS sur leur téléphone, choisissent leur moyen de paiement.
Quand l’initiateur de la transaction bascule du côté de l’IA, ce parcours montre ses limites. Les refus peuvent augmenter la friction se déplace au mauvais endroit, et le risque de fraude devient plus difficile à évaluer (et donc à prévoir) avec précision. Pour les retailers, la question n’est plus seulement de savoir si le commerce agentique va se développer, mais comment adapter dès maintenant leur infrastructure de paiement pour l’accueillir sans perdre de conversion.
Pourquoi le commerce agentique casse le checkout traditionnel
Le tunnel de paiement classique repose sur trois gestes qu’un humain effectue lui-même : saisir ses coordonnées, valider une authentification 3DS en temps réel et choisir son moyen de paiement.
Un agent qui achète pour le compte d’un utilisateur ne peut reproduire aucun de ces trois gestes de la même façon. Il ne reçoit pas de notification bancaire sur un smartphone, n’a pas vocation à stocker un numéro de carte en clair, et son comportement d’achat ne ressemble en rien à celui d’un acheteur humain. Il est en effet répétitif, régulier, et s’effectue depuis une même source.
Si le checkout casse, ce n’est pas parce que l’agent est malveillant, mais parce qu’il a été construit pour un profil d’acheteur qui n’est plus le seul à se présenter.
L’identité au-delà du sujet seul de l’IA
La tentation est de traiter ce sujet comme un problème d’intelligence artificielle. Pourtant, le vrai sujet est ailleurs : c’est celui de l’identité de la transaction.
Un agent doit en effet pouvoir être reconnu comme une entité distincte, rattachée à un utilisateur identifié et avec un niveau de confiance qui lui est propre. À défaut, l’infrastructure paiement continue de juger chaque transaction agentique sur la base de critères humains, justifiant la hausse des refus.
Aujourd’hui, la question n’est donc pas de savoir si un agent est fiable, mais si votre infrastructure sait le reconnaître pour ce qu’il est.
Comment repenser l’authentification pour des transactions initiées par des agents ?
L’authentification ne doit plus reposer sur le principe du même niveau de contrôle pour tous. Avec Authenticate, le niveau de vérification appliqué dépend du risque réel de la transaction, et non de la nature humaine ou agentique de son initiateur.
Un achat récurrent de faible montant, effectué par un agent déjà reconnu, ne justifie pas la même friction qu’un premier achat à montant élevé depuis un nouvel appareil. Cette authentification adaptée au risque et à la réglementation en vigueur (SCA, 3DS) permet de conserver un contrôle réel là où il compte, sans l’imposer partout de façon uniforme et injustifiée.
La tokenisation réseau, pierre angulaire d’un parcours sans friction
La tokenisation apporte une réponse directe au problème de la donnée sensible. Concrètement, les données de carte sont remplacées par un token propre au commerçant, réutilisable sans réexposer la carte d’origine.
Pour un agent qui achète de façon répétée, ce token change la donne : aucune donnée sensible n’est stockée ni retransmise à chaque achat, et la continuité du paiement ne dépend plus d’une ressaisie humaine. Le token peut par ailleurs être limité dans le temps ou au périmètre d’un commerçant précis, ce qui réduit le risque sans complexifier le parcours.
Recalibrer le risque et les refus pour des comportements automatisés
Par défaut, un moteur de risque calibré uniquement sur des signaux humains étiquette de suspect un comportement d’agent (régularité, source identifiée, répétition). Protect applique le machine learning et des règles de gestion du risque pour distinguer ce signal d’agent légitime d’un signal de fraude réelle.
Ce recalibrage a un effet direct et mesurable : moins de refus sur des transactions agentiques légitimes, donc moins de conversions perdues pour un motif qui n’a rien à voir avec une fraude.
Les évolutions techniques et opérationnelles à prévoir côté retailer
Trois chantiers concrets se dégagent pour une équipe technique.
La politique de tokenisation doit évoluer pour supporter des jetons à portée limitée, adaptés à un usage répété par un agent.
Les règles du moteur de risque doivent intégrer des signaux propres au comportement agentique, plutôt que de les traiter comme des anomalies.
Le suivi des refus doit enfin permettre d’isoler ceux qui pénalisent une transaction agentique légitime, pour ajuster le paramétrage sans attendre qu’ils s’accumulent.
Ce que doivent mettre en place les grandes enseignes dès maintenant
Pour un retailer qui opère à l’échelle, l’enjeu n’est pas d’anticiper une bascule totale vers le commerce agentique, mais de s’assurer que l’infrastructure paiement peut déjà absorber les premières transactions de ce type sans dégrader ni la conversion, ni la sécurité. Trois étapes permettent d’engager ce chantier sans attendre que les volumes agentiques imposent leur rythme.
1. Identifier les points de friction actuels
La première étape consiste à identifier, dans le parcours de paiement existant, où un agent se heurterait à un mur d’authentification, à une exigence de ressaisie ou à un refus injustifié. Cette cartographie révèle en général les mêmes zones sensibles : authentification 3DS incontournable, absence de token réutilisable, règles de risque calibrées sur un comportement humain.
2. Prioriser les corrections selon leur impact sur la conversion
L’impact sur la conversion l’emporte sur la complexité technique des corrections. Une politique de tokenisation à faire évoluer touche souvent moins de flux qu’un recalibrage complet du moteur de risque, mais son effet sur la continuité du paiement est immédiat.
Commencer par les tokens à portée limitée, puis ajuster les règles de risque, permet d’obtenir des résultats mesurables avant d’engager une refonte plus large.
3. Instaurer un suivi exclusif des refus liés à des transactions agentiques
Ce suivi doit être distinct du suivi de fraude classique. Sans cette distinction, un refus causé par une mauvaise lecture du comportement d’un agent reste noyé dans les statistiques générales. Aussi, le vrai problème (celui de la conversion perdue sans fraude réelle) n’apparaît jamais clairement.
Cette méthode ne nécessite pas de reconstruire toute une infrastructure de paiement. Elle s’appuie sur l’existant, à savoir une tokenisation capable de générer des tokens scopés, une authentification modulée selon le risque réel, et un moteur de risque qui apprend à distinguer un agent légitime d’un signal de fraude.
C’est la combinaison de ces trois briques, plutôt que leur empilement, qui permet à un retailer d’absorber l’agentic commerce sans arbitrer entre sécurité et conversion.
Vous souhaitez évaluer comment votre parcours de paiement actuel se comporte face à des transactions initiées par des agents ? Nos équipes peuvent vous accompagner avec une lecture concrète des zones de friction propres à votre activité. Contactez-nous pour en discuter.