Conception d’un processus de paiement par agents : autorité déléguée, devis obsolètes, tentatives de réessai.

Concevoir un système de paiement était autrefois une question facile lors des entretiens, car une solution de référence circulait partout et un candidat compétent pouvait la reproduire en vingt minutes. La version actuelle introduit un agent logiciel entre l’acheteur et le vendeur, ce qui fait échouer presque toutes les hypothèses présentes dans la solution traditionnelle. Il n’existe pas d’article canonique à mémoriser pour ce système, et c’est précisément la raison pour laquelle cette question est constamment posée.

Pourquoi elle est apparue

Trois évolutions ont eu lieu en peu de temps.

First, un standard ouvert. Le Agentic Commerce Protocol, géré conjointement par OpenAI et Stripe, définit la manière dont les acheteurs, leurs agents, les vendeurs et les processeurs de paiement communiquent entre eux. Son élément central est un jeton de paiement partagé : l’agent peut finaliser une transaction sans jamais voir les informations de la carte, tandis que le vendeur conserve son rôle de commerçant officiel.

Deuxièmement, un design concurrent. Le Agent Payments Protocol de Google considère les autorisations comme des mandats signés, transmis sous forme de JWT à divulgation sélective. Un mandat prouve que l’utilisateur a approuvé l’achat et un autre prouve l’approbation du paiement ; chacun peut être ouvert, enregistrant à l’avance les contraintes, ou fermé, lié à un panier final.

Troisièmement, la recherche en matière de sécurité a évolué rapidement. Une étude systématique d’AP2 recense 48 menaces distinctes regroupées en cinq familles, huit d’entre elles étant classées comme ayant une gravité élevée ; toutes ont été testées sur un environnement réel et non simplement décrites. Pour un intervieweur, il s’agit d’un matériel idéal, car les modes de défaillance sont réels et spécifiques, sans besoin d’artifices pour donner de la profondeur à la question.

L’énoncé tel qu’il arrive

Les formulations varient, mais les exigences restent constamment proches de celles-ci :

1. Un acheteur demande à un assistant d’acheter un article, en précisant éventuellement des limites telles qu’un prix maximum ou une date limite de livraison.
2. L’agent examine plusieurs vendeurs, évalue les options et choisit enfin l’un d’eux.
3. Le paiement est effectué sans que l’agent n’aie accès aux données brutes de la carte.
4. L’acheteur peut consulter ce qui a été approuvé, et les litiges peuvent être résolus ultérieurement.
5. Aucune transaction n’est jamais dupliquée ni réalisée en dehors de ce à quoi l’acheteur a réellement consenti.

La cinquième exigence mérite d’être relue, car c’est là que se trouvent toutes les difficultés. Ces cinq lignes engendrent tous les sous-problèmes complexes qui suivent, et un candidat qui commence par présenter cette comparaison, plutôt que de se limiter à dessiner des cases, s’est déjà distingué de la plupart des autres. S’entraîner sur des questions liées à l’infrastructure des paiements réels est un moyen rapide de maîtriser le vocabulaire nécessaire, puisque les registres, l’idempotence et le règlement y apparaissent tous sous forme d’agents.

Problème un : autorité déléguée

Le acheteur est absent au moment de l’achat, il faut donc que quelque chose prenne le relais pour exprimer son consentement.

La réponse insuffisante consiste à conserver une méthode de paiement enregistrée pour que l’agent puisse la facturer après que l’utilisateur ait donné son accord. Cela pose problème, car un accord à 10h00 pour un broyeur de café pesant moins de 80 livres ne couvre pas ce que l’agent choisit à 10h04. Un modèle, une chaîne d’outils et éventuellement une description de produit modifiée peuvent tous entrer dans cette lacune.

Les normes gèrent cela de trois manières :

• L’autorisation devient un objet signé avec une portée définie, plutôt que simplement le détention d’une preuve d’identité.
• Cet objet sépare l’intention de l’exécution : une mandature ouverte fixe des limites telles qu’un plafond de prix et une catégorie, tandis qu’une mandature fermée est associée à un panier final spécifique.
• Les identifiants de paiement sont remplacés par un jeton valable pour un seul commerçant et une seule transaction, de sorte qu’un jeton volé ne permet d’acheter qu’un seul article une seule fois.

Points importants à mentionner : limitez chaque subvention en fonction du montant, du commerçant, de la catégorie et de la date d’expiration ; exigez la version finale avant tout transfert d’argent, afin que l’document signé et l’article acheté soient identiques ; considérez le mandat comme le registre d’autorisation en soi, et non comme un outil qui facilite l’utilisation de la carte.

Deuxième problème : les contraintes légales, ou pourquoi les agents méticuleux se basent sur des données obsolètes

Presque personne ne soulève ce point de lui-même, et cela peut être mesuré.

Un agent de shopping consciencieux examine de nombreuses offres avant de choisir. L’offre gagnante a été consultée au début de la comparaison, ce qui signifie que plus l’agent est méticuleux, plus ses données les plus fiables sont obsolètes.

Une simulation a joint une figure à ce texte. L’agent interroge chaque vendeur un par un, y consacrant de trois à huit secondes, puis réfléchit à l’ensemble pendant cinq à quinze secondes avant de prendre une décision. Les prix et les stocks évoluent selon un processus de Poisson, ce qui détermine la probabilité que l’offre choisie ait déjà changé au moment de la décision.

Ce qui frappe, c’est le schéma observé : passer d’un vendeur à vingt multiplie par environ cinq la probabilité de prendre une décision obsolète à chaque taux de rotation, de sorte que le comportement même souhaité par les acheteurs affaiblit les propres informations utilisées par l’agent. Avec une politique de tarification dynamique assez agressive, un tiers des comparaisons minutieuses se termine par une offre qui a déjà été modifiée.

Les conséquences en termes de conception sont concrètes :

• Les devis sont des objets émis par le serveur, chacun disposant d’un ID et d’une durée de vie limitée.
• L’autorisation finale est associée à un hash du panier finalisé, ce qui correspond exactement à ce qu’offre une commande clôturée.
• Lors du paiement, le vendeur vérifie à nouveau le prix et les stocks, et refuse toute incohérence au lieu de valider silencieusement la commande.
• En cas de refus, le système propose une nouvelle estimation de prix et envoie un message au client si ce changement dépasse les limites qu’il a fixées.

Les candidats ont tendance à oublier ce dernier point : refuser une commande obsolète est un comportement correct, et sans boucle de nouvelle estimation, un bug de tarification devient simplement un bug de fiabilité.

Problème trois : les tentatives répétées et la clé d’idempotence inutile de l’agent

Les clés d’idempotence sont mentionnées dans toutes les réponses, mais il existe un piège caché dans la configuration habituelle.

Généralement, le client génère une clé et l’envoie à nouveau lors d’une tentative de réessai. Les agents viennent contrecarrer ce mécanisme. Lorsqu’une réponse disparaît, un agent n’envoie souvent pas la même demande ; il la planifie à nouveau, ce qui génère une nouvelle demande avec une nouvelle clé, et le serveur la traite comme une intention nouvelle.

Ce comportement a été modélisé directement plutôt que supposé, avec 5 % de réponses perdues après que la facturation a déjà eu lieu et jusqu’à trois tentatives :

• Lorsque l’agent génère une nouvelle clé à chaque tentative, 4,98 % des commandes sont facturées deux fois, soit en moyenne 1,052 facturations par commande.
• Lorsque la clé est dérivée sur le serveur à partir des informations du panier, les doublons tombent à 0,00 % et chaque commande est facturée une seule fois.

Le taux simulé de 4,98 % correspond à la probabilité théorique de 5,00 %, ce qui est logique car un doublon apparaît précisément lorsque la première réponse disparaît.

En résumé : il faut générer la clé d’idempotence à partir de quelque chose approuvé par l’acheteur, et non à partir d’une information inventée par celui qui lance la demande. Le hash qui relie la commande finalisée au panier suffit déjà, il n’est donc pas nécessaire d’effectuer de travail supplémentaire.

Quatrième problème : qui est le commerçant officiel ?

Il s’agit d’une question commerciale déguisée en question technique, et c’est elle qui détermine le modèle de données.

• Avec un jeton partagé, le vendeur reste le commerçant officiel, ce qui permet à la plateforme d’agent d’éviter toute responsabilité en matière de règlement, de taxes et de remboursements.
• Si, en revanche, c’est la plateforme qui achète puis revend, la tâche de l’agent devient plus simple, mais cela entraîne également l’apparition d’un ensemble de règles réglementaires complexes.
• Il faut formuler cette hypothèse dès le début, en moins de deux minutes, car les remboursements, les taxes et les litiges en découlent tous.

Cinquième problème : l’auditableté en tant que exigence

L’une des cinq familles de menaces identifiées dans l’analyse AP2 concerne entièrement la responsabilisation, c’est-à-dire le stockage des preuves et leur traçabilité. Les gens l’ignorent, pourtant c’est elle qui détermine si un différend peut être résolu six mois plus tard.

Pour chaque transaction, stockez de manière immuable :

• Les deux versions du mandat signé, celui en version ouverte et celui en version fermée.
• Le hash précis du panier qui a été approuvé, ainsi que le contenu de ce panier.
• Le ID de la proposition commerciale, accompagné de la date à laquelle elle a été émise et de celle à laquelle elle expire.
• Le agent et la version du modèle qui ont agi, ainsi que le cadre de délégation dans lequel ils ont opéré.
• Chaque refus et sa raison, car les refus prouvent que les mécanismes de contrôle fonctionnaient correctement.

Un chemin de référence

Une réponse claire suit l’ensemble du processus d’achat de bout en bout :

1. Le client définit un objectif avec des limites, et la plateforme émet un mandat ouvert défini par un montant, une catégorie et une date d’expiration.
2. L’agent collecte les offres des vendeurs candidats, et chaque vendeur répond par une proposition accompagnée d’un ID et d’une date d’expiration.
3. L’agent en choisit une et demande un panier final que le vendeur signe.
4. La plateforme crée un mandat fermé lié au hash de ce panier, en le vérifiant par rapport aux limites du mandat ouvert.
5. Un jeton de paiement est émis uniquement pour ce vendeur et pour ce montant précis.
6. Le vendeur vérifie à nouveau le prix et les stocks, puis effectue le paiement en utilisant une clé d’idempotence dérivée du hash du panier.
7. Tous les éléments issus des étapes un à six sont enregistrés dans le stock d’audit avant que toute réponse ne soit envoyée.
8. En cas de désaccord à l’étape six, on revient à l’étape deux, ou bien au client si la modification dépasse ses limites.

Chacune des huit étapes existe parce qu’un échec spécifique resterait sinon sans protection, et c’est en reliant chaque étape à son échec que l’interrogateur évalue réellement la réponse.

Évaluation d’une réponse de pratique

Les réponses qui méritent des points sont celles qui :

• présentent le modèle de délégation en deux minutes puis s’y tiennent ;
• séparent l’autorisation ouverte de l’engagement fermé et expliquent pourquoi les deux sont nécessaires ;
• abordent le problème de péremption d’eux-mêmes, de préférence avec une estimation approximative ;
• construisent l’idempotence à partir de l’état approuvé, et non sur la base des informations fournies par l’appelant ;
• considèrent la trace d’audit comme une exigence et non simplement comme un enregistrement.

Les réponses qui perdent des points sont celles qui :

• imaginent l’agent comme un être humain rapide, alors que la plupart des difficultés proviennent justement de ses différences avec un humain ;
• donnent à l’agent n’importe quel type de crédentiel réutilisable ;
• présume qu’une tentative de réessai correspond à la même demande envoyée à nouveau ;
• définit un rejet sans étape suivante ;
• reporte les questions relatives à la responsabilité et au rôle du commerçant enregistré à la fin, bien qu’elles déterminent le modèle de données.

Pourquoi il vaut la peine de se préparer à cette question

Le polonais a cessé d’être un indicateur utile pour le recrutement dès lors qu’une réponse parfaite à chaque question classique est devenue disponible gratuitement. Le paiement par agent constitue un cas actuel où ce raccourci fait défaut. Les protocoles n’ont que quelques mois, la recherche sur les menaces est encore récente, et les compromis n’ont pas encore abouti à un accord.

Cela signifie que la consigne ne récompense plus les banques de questions basées sur des normes de compétences qui ne nécessitent plus d’appliquer un raisonnement fondé sur des contraintes véritablement comprises. Maîtriser cette compétence permet également de se préparer à toute question qui pourrait la remplacer, puisque l’approche de base reste inchangée. Il convient de se demander ce qui change lorsque l’entité située de l’autre côté de l’API n’est plus humaine.