---
title: Signez les limites, pas l’achat
description: AP2 porte le nom des paiements, mais Alan, de Google, l’appelle par son vrai nom : de l’autorité déléguée par l’utilisateur. Notes sur ce passage du direct d’AGNTCon + MCPCon, le billet d’avion approuvé cinq fois et jamais acheté, et la façon dont les mandats ouverts et fermés d’AP2 permettent de signer les limites une fois, puis de s’en aller.
date: 2026-10-28
tags: agents IA, autorisation des agents, AP2, commerce agentique, A2A
---

Si votre agent vous demande votre empreinte chaque fois qu’il s’apprête à agir, vous ne déléguez pas, vous faites du baby-sitting. AP2, l’Agent Payments Protocol, règle ça avec un mandat : vous signez les limites une fois, sur un écran qu’aucun agent ne contrôle, et l’agent agit plus tard à l’intérieur, sans vous. Celui à qui il remet le mandat peut vérifier, par la cryptographie, qu’il est resté dans les clous. Il a été conçu pour les achats, mais comme l’a dit Alan, de Google, sur scène, c’est en réalité de l’autorité déléguée par l’utilisateur, et ça s’applique largement.

Cette phrase vient de la dernière conversation du direct du deuxième jour d’AGNTCon + MCPCon North America, le 23 octobre, un tour de la pile de protocoles d’agents de Google. Le passage dure environ deux minutes, et il met un nom sur un problème que j’ai avec chacun des agents que je fais tourner.

## Les paiements étaient le test le plus dur, pas le but

Alan est product manager chez Google. Il a aidé sur A2A et sur l’adoption de MCP en interne, et il siège au comité technique de l’Agentic AI Foundation. Il a aussi travaillé six ans dans les paiements chez Google, et c’est de là que vient AP2.

Son avis sur le nom : il est mal choisi. L’animateur a résumé l’idée ainsi : « moi, humain, je pose mon empreinte sur mon téléphone pour dire, oui l’agent, vas-y, fais-le pour moi ». La réponse d’Alan : « C’est en fait un mandat. On l’utilise pour les achats parce qu’on s’est dit : quel est le problème le plus dur qu’on peut attaquer maintenant ? » Puis : « Mais cette délégation d’autorité a de la valeur dans plein d’autres contextes. »

Les paiements font un bon premier test, parce que l’argent a un juge intégré. Un remboursement ou une rétrofacturation, c’est une dispute pour savoir si vous le vouliez vraiment, donc, selon ses mots, « il faut forcer la délégation pour qu’elle soit prouvable ». Il qualifie AP2 de pièce stratégique, et il admet que ça mettra longtemps à se répandre. Son cousin, UCP, l’Universal Commerce Protocol, est la pièce tactique : les conventions du commerce en ligne (panier, stock, options de livraison) en petits modules sur MCP et A2A, utilisables dès aujourd’hui.

<figure class="fd-fig ap ap-f1" aria-labelledby="ap1-cap" data-desc="Deux lectures d’AP2. Par son nom, l’Agent Payments Protocol : des achats, un mandat de paiement, l’empreinte de l’utilisateur sur un téléphone, choisis comme le problème le plus dur que Google pouvait attaquer en premier. Par ce qu’il est, selon Alan : de l’autorité déléguée par l’utilisateur, utile dans plein d’autres contextes, chaque fois qu’un agent agit pour quelqu’un et que l’autre partie a besoin de la preuve que la personne le voulait. En dessous, sa répartition des deux protocoles de commerce : AP2 stratégique, parce que les remboursements et les rétrofacturations obligent à rendre la délégation prouvable, et lent à se répandre ; UCP tactique, les conventions du commerce en ligne sur MCP et A2A, disponible maintenant.">
<div class="mp-two-row">
<div class="mp-two-card">
<p class="mp-two-who">Par son nom</p>
<p class="mp-two-name">Paiements</p>
<p class="mp-two-line">L’Agent Payments Protocol</p>
<p class="mp-two-line">Votre empreinte sur votre téléphone</p>
<p class="mp-two-line">Choisi comme le problème le plus dur pour commencer</p>
</div>
<p class="mp-two-vs">vs</p>
<div class="mp-two-card mp-two-peter">
<p class="mp-two-who">Par ce qu’il est</p>
<p class="mp-two-name">Autorité déléguée</p>
<p class="mp-two-line">« Utile dans plein d’autres contextes »</p>
<p class="mp-two-line">Chaque fois qu’un agent agit pour vous</p>
<p class="mp-two-line">Et que l’autre partie doit savoir que vous le vouliez</p>
</div>
</div>
<p class="mp-strip"><b>AP2</b><span>Stratégique : les litiges obligent à prouver la délégation. Lent à se répandre.</span></p>
<p class="mp-strip"><b>UCP</b><span>Tactique : panier, stock et livraison en modules sur MCP et A2A. Marche déjà.</span></p>
<figcaption id="ap1-cap">Les citations viennent du direct, traduites. La répartition entre les deux protocoles est celle d’Alan.</figcaption>
</figure>

## Tout approuver au moment même fait rater le vol

L’installation de l’animateur, je l’aurais construite aussi. Son agent a accès à l’API de 1Password. Quand il veut quelque chose, disons un numéro de passeport, il interroge le coffre et une notification arrive sur le téléphone. Un tap, c’est approuvé.

Le nom qu’Alan lui donne : human present, humain présent. Vous autorisez cette action-là, maintenant. Ça marche, jusqu’à ce que la tâche dure plus longtemps que votre attention.

Puis est venu le billet d’avion. Vous lancez l’agent sur la recherche, il fait tout le travail, vous vous éloignez de l’ordinateur. Il revient : « Je suis prêt à payer ce vol. Vous l’autorisez ? » Vous pensiez l’avoir autorisé il y a vingt minutes. Vous l’avez autorisé cinq fois, et il ne l’a jamais acheté. Alors vous autorisez encore, et maintenant le prix n’est plus disponible, et tout le parcours recommence.

Le verdict sans détour, sur scène : retirez l’agent de l’équation et un script ferait ça. L’agent n’est pas la partie lente. Le modèle d’approbation, si.

<figure class="fd-fig ap ap-f2" aria-labelledby="ap2-cap" data-desc="La boucle du billet d’avion racontée dans le direct, en cinq étapes qui s’allument tour à tour sous une grande étiquette. Un : l’agent trouve un vol. Deux : il demande, vous l’autorisez, et vous approuvez. Trois : vous vous éloignez de l’ordinateur. Quatre : il revient et redemande ; vous aviez approuvé cinq fois et il n’avait jamais acheté. Cinq, en rouge : le prix n’est plus disponible et tout le parcours recommence. En dessous, le verdict donné sur scène : retirez l’agent de l’équation et un script ferait ça.">
<p class="ea-now ea-say5" aria-hidden="true"><span>L’agent trouve un vol</span><span>Vous approuvez</span><span>Vous vous éloignez</span><span>Il redemande</span><span class="ea-no">Le prix a disparu</span></p>
<ol class="ea-rows ea-cyc5 ap-loop" aria-label="Le billet d’avion, étape par étape">
<li><b>1</b><span class="ea-who">Recherche</span><span>L’agent fait tout le travail pour trouver le vol.</span></li>
<li><b>2</b><span class="ea-who">Demande</span><span>« Je suis prêt à payer. Vous l’autorisez ? » Vous tapez oui.</span></li>
<li><b>3</b><span class="ea-who">Absent</span><span>Vous vous éloignez de l’ordinateur.</span></li>
<li><b>4</b><span class="ea-who">Redemande</span><span>Cinq approbations plus tard, il n’a toujours pas acheté.</span></li>
<li class="ea-row-no"><b>5</b><span class="ea-who">Disparu</span><span>Ce prix n’est plus disponible. On recommence.</span></li>
</ol>
<p class="mp-strip"><b>Le verdict</b><span>Retirez l’agent et un script ferait ça.</span></p>
<figcaption id="ap2-cap">L’histoire telle qu’elle a été racontée dans le direct. Cinq approbations, c’est le chiffre donné là-bas ; aucun journal derrière.</figcaption>
</figure>

## Humain présent, humain absent

La solution qu’Alan a décrite, c’est l’autre mode, human not present, humain absent. Son exemple : « Quand ces baskets passent en solde, si elles sont à ta taille, chez un de tes vendeurs de confiance, achète-les. »

Cette phrase contient trois limites (l’article, votre taille, une liste de boutiques) et un déclencheur. Vous l’approuvez une fois, avant que quoi que ce soit n’arrive. L’agent achète ensuite à 3 h du matin sans vous réveiller, et la boutique peut quand même savoir que vous avez accepté exactement ça.

Même empreinte, autre moment. En mode humain présent, vous signez l’achat. En mode humain absent, vous signez les limites, et l’achat, c’est le travail de l’agent.

<figure class="fd-fig ap ap-f3" aria-labelledby="ap3-cap" data-desc="Les deux modes d’AP2 côte à côte. Humain présent : l’agent demande au moment d’agir, vous approuvez cette seule chose sur votre téléphone, comme la notification 1Password de l’animateur pour un numéro de passeport ; ça casse quand la tâche dure plus longtemps que votre attention. Humain absent : vous approuvez des limites à l’avance, comme l’exemple des baskets d’Alan, achète-les quand elles passent en solde, à ta taille, chez un de tes vendeurs de confiance ; l’agent agit plus tard sans demander, et le marchand peut quand même vérifier que vous étiez d’accord. Sous les deux : la même empreinte, à un autre moment.">
<div class="mp-two-row">
<div class="mp-two-card">
<p class="mp-two-who">Humain présent</p>
<p class="mp-two-name">Signer l’acte</p>
<p class="mp-two-line">L’agent demande juste avant d’agir</p>
<p class="mp-two-line">« Je peux lire ton numéro de passeport ? »</p>
<p class="mp-two-line">Casse quand la tâche dure plus que vous</p>
</div>
<p class="mp-two-vs">vs</p>
<div class="mp-two-card mp-two-peter">
<p class="mp-two-who">Humain absent</p>
<p class="mp-two-name">Signer les limites</p>
<p class="mp-two-line">Vous approuvez une fois, à l’avance</p>
<p class="mp-two-line">« Ces baskets, en solde, ma taille, une boutique de confiance »</p>
<p class="mp-two-line">L’agent achète plus tard, sans demander</p>
</div>
</div>
<p class="mp-strip"><b>Même empreinte</b><span>Autre moment.</span></p>
<figcaption id="ap3-cap">Les deux exemples sont ceux du direct : le coffre de l’animateur, les baskets d’Alan.</figcaption>
</figure>

## Un mandat ouvert, puis un mandat fermé

Voici comment AP2 s’y prend vraiment. J’ai lu la spec v0.2, publiée en avril, après le direct. Elle est courte et concrète.

Un mandat est une attestation numérique signée, un SD-JWT, la variante à divulgation sélective du JSON Web Token. Il y en a deux sortes : un mandat de checkout (ce qui est acheté, à qui) et un mandat de paiement (combien, avec quelle carte ou quel compte). Chacun existe en deux étapes.

Le mandat ouvert, c’est ce que vous signez. L’agent rédige les limites, et une Trusted Surface, une surface de confiance, vous les montre, prend votre biométrie et signe avec votre clé. La spec dit que cette surface DOIT être non agentique : le modèle ne tient jamais votre stylo. Le mandat ouvert porte aussi la clé publique de l’agent dans un claim `cnf`, donc il est lié à cet agent-là. Une copie dans d’autres mains ne sert à rien.

Le mandat fermé, c’est ce que l’agent fabrique plus tard, seul. Il trouve un vrai panier, écrit la transaction exacte, et la signe avec sa propre clé, celle nommée dans votre mandat ouvert. Cette signature relie le mandat fermé au mandat ouvert.

Les limites sont une liste de contraintes typées. La version 0.2 définit celles-ci :

- Côté checkout : `checkout.allowed_merchants` et `checkout.line_items`, avec les produits et quantités acceptables.
- Côté paiement : `payment.amount_range`, `payment.allowed_payees`, `payment.allowed_payment_instruments`, `payment.execution_date`, et la paire pour les tâches répétées, `payment.agent_recurrence` (par exemple mensuel, 12 fois au plus) avec `payment.budget`, un plafond sur le total.
- Plus `iat` et `exp` sur le mandat ouvert, pour que l’ensemble expire.

Réduit à l’essentiel, le côté paiement des baskets d’Alan ressemblerait à ceci :

```json
{
  "vct": "mandate.payment.open.1",
  "cnf": { "jwk": "the agent's public key" },
  "constraints": [
    { "type": "payment.amount_range", "currency": "USD", "min": 0, "max": 20000 },
    { "type": "payment.allowed_payees", "allowed": ["one of your trusted shops"] }
  ]
}
```

Ma phrase préférée de la spec, c’est la raison d’être des mandats ouverts : « même des agents qui se comportent bien doivent voir leur comportement contraint bien plus étroitement que ce qu’un modèle d’autorisation normal exigerait d’utilisateurs humains ». Personne ne donne à un humain une carte qui ne marche que dans trois boutiques, sous deux cents dollars, jusqu’à vendredi. Un agent devrait recevoir exactement ça.

<figure class="fd-fig ap ap-f4" aria-labelledby="ap4-cap" data-desc="La chaîne de trois objets signés d’AP2, allumés tour à tour sous une grande étiquette. D’abord, le mandat ouvert : vous le signez avec votre clé sur une surface de confiance qui ne doit pas être un agent ; il contient les limites et la clé publique de l’agent dans un claim cnf. Ensuite, le mandat fermé : l’agent le signe plus tard avec la clé nommée dans le mandat ouvert ; il contient le panier et le montant exacts. Enfin, le reçu : le vérificateur le signe après avoir contrôlé la chaîne, que les claims ouverts sont inchangés, et chaque contrainte. En dessous, les types de contraintes que définit la version 0.2 : marchands autorisés, articles, fourchette de montant, bénéficiaires autorisés, moyens de paiement, date d’exécution, récurrence et budget, plus une expiration.">
<p class="ea-now ea-say3" aria-hidden="true"><span>Vous signez les limites</span><span>L’agent signe l’achat</span><span>Le vérificateur signe un reçu</span></p>
<div class="ap-chain" aria-hidden="true">
<div class="ea-box ap-c1"><p class="ea-box-k">Mandat ouvert</p><p class="ea-box-n">Vous</p><p class="ap-key">votre clé</p></div>
<span class="ap-arr">→</span>
<div class="ea-box ap-c2"><p class="ea-box-k">Mandat fermé</p><p class="ea-box-n">L’agent</p><p class="ap-key">sa clé, nommée dans l’ouvert</p></div>
<span class="ap-arr">→</span>
<div class="ea-box ap-c3"><p class="ea-box-k">Reçu</p><p class="ea-box-n">Le vérificateur</p><p class="ap-key">sa clé</p></div>
</div>
<ol class="ea-rows ap-parts" aria-label="Ce que contient chaque objet signé">
<li><b>1</b><span class="ea-who">Ouvert</span><span>Les limites, une expiration, la clé publique de l’agent. Signé sur une Trusted Surface non agentique.</span></li>
<li><b>2</b><span class="ea-who">Fermé</span><span>Le panier et le montant exacts, liés au mandat ouvert.</span></li>
<li><b>3</b><span class="ea-who">Reçu</span><span>Succès ou erreur, et une empreinte de ce qui a été vérifié.</span></li>
</ol>
<p class="mp-strip"><b>Limites en v0.2</b><span>Marchands, articles, montant, bénéficiaires, moyens, dates, récurrence, budget.</span></p>
<figcaption id="ap4-cap">Redessiné à partir des parcours de la spec. Les montants du code ci-dessus sont les valeurs d’exemple de la spec, pas un vrai mandat.</figcaption>
</figure>

## Trois vérificateurs, et aucun n’est vous

En mode humain absent, personne ne vous demande rien au moment de payer. Trois autres parties vérifient à votre place.

Le fournisseur d’identifiants de paiement (votre banque ou votre portefeuille) reçoit les deux mandats de paiement, ouvert et fermé, les vérifie, et seulement ensuite émet un jeton de paiement. Le marchand compare le mandat de checkout fermé à son panier actuel et vérifie que vos limites ouvertes sont respectées. Le prestataire de paiement du marchand vérifie que les mandats dans le jeton sont liés à ce checkout précis. Chacun signe un reçu.

Quelques règles là-dedans sont petites et très bonnes :

- Une contrainte inconnue compte comme un échec. Si un vérificateur ne comprend pas une de vos limites, il dit non plutôt que de la sauter.
- Après un reçu réussi, l’agent réduit la portée du mandat ouvert de ce qu’il vient de dépenser. C’est comme ça qu’un budget tient sur des achats répétés.
- L’agent ne doit pas présenter de mandats qui se chevauchent tant qu’un reçu ne revient pas en erreur. Pas de double dépense en faisant la course entre deux boutiques.
- Quand une limite ne peut pas être tranchée, le vérificateur renvoie `unresolved_constraint` et le parcours repasse en humain présent. On vous demande, une fois, la seule chose qui est vraiment nouvelle.

Cette dernière règle, c’est le billet d’avion réparé. L’agent ne revient pas cinq fois. Il revient quand le prix est sorti de ce que vous avez signé.

<figure class="fd-fig ap ap-f5" aria-labelledby="ap5-cap" data-desc="Qui vérifie quoi dans le parcours humain absent d’AP2. Un, le fournisseur d’identifiants, votre banque ou votre portefeuille : il vérifie les mandats de paiement ouvert et fermé, puis émet un jeton de paiement. Deux, le marchand : il compare le mandat de checkout fermé au panier actuel et vérifie que les limites ouvertes sont respectées. Trois, le prestataire de paiement du marchand : il vérifie que les mandats dans le jeton sont liés à ce checkout. En dessous, deux règles : une contrainte inconnue compte comme un échec, et quand une limite ne peut pas être tranchée, le vérificateur renvoie unresolved_constraint et on redemande à la personne, sur ce seul point.">
<ol class="mp-trio">
<li><p class="mp-trio-n"><b>1</b>Votre banque</p><p class="mp-trio-what">Vérifie les deux mandats de paiement, puis émet un jeton.</p></li>
<li><p class="mp-trio-n"><b>2</b>La boutique</p><p class="mp-trio-what">Compare le mandat fermé à son panier en cours, et vérifie vos limites ouvertes.</p></li>
<li><p class="mp-trio-n"><b>3</b>Le prestataire</p><p class="mp-trio-what">Vérifie que les mandats du jeton appartiennent à ce checkout précis.</p></li>
</ol>
<p class="mp-strip"><b>Limite inconnue</b><span>Compte comme un échec, jamais comme un succès.</span></p>
<p class="mp-strip ap-back"><b>Hors limites</b><span><code>unresolved_constraint</code> : on vous demande une fois, sur la nouveauté.</span></p>
<figcaption id="ap5-cap">Credential provider est le terme de la spec ; votre banque ou votre portefeuille, c’est mon raccourci.</figcaption>
</figure>

## Chaque approbation de ma flotte est en humain présent

Puis j’ai regardé ma propre installation, et c’est partout le modèle 1Password de l’animateur.

Mon agent de vente pilote un Chrome sur le Mac mini, connecté à mes comptes de revente sous mon nom. Il rédige chaque réponse aux acheteurs et attend mon OK dans le chat avant d’envoyer. Quand j’ai demandé à un agent de laisser un autre de mes agents envoyer des SMS depuis mon téléphone, le mode auto de Claude Code a refusé d’appliquer seul le changement de config, parce que c’était une attribution de permission. Il n’est passé qu’une fois approuvé par moi, à la main. Et cette note arrivera sur le site de la même façon. L’agent qui l’a rédigée peut ouvrir la pull request, mais le merge, c’est mon clic.

Tout ça va bien pour l’instant. Voilà ce qui me gêne après ce passage. Le navigateur connecté porte toute mon autorité : n’importe quelle annonce, n’importe quel prix, n’importe quel message. Mon OK est un message de chat que personne en aval ne peut vérifier. Les limites vivent dans ma tête et dans un prompt, pas dans quoi que ce soit de signé.

C’est l’autre moitié d’une note que j’ai écrite hier, sur [la conférence DotSpace de Chi Wang](/fr/notes/agents-carry-requests-not-authority.html). Sa règle : un agent porte votre demande, pas votre autorité. AP2, c’est la façon dont une part bornée d’autorité peut quand même voyager : comme un objet signé, avec les limites écrites dedans, vérifié par celui qui le reçoit. C’est aussi la même idée que la passerelle de ma [note sur les agents en entreprise](/fr/notes/hope-isnt-security-enterprise-agents.html), où les clés n’entrent jamais dans la sandbox. Ici, votre clé ne touche jamais l’agent ; elle reste sur la Trusted Surface.

Ce que je n’ai pas fait : je n’ai pas lancé les exemples d’AP2, et la v0.2 ne définit que des mandats de checkout et de paiement. Rien dans la spec ne couvre « réponds aux acheteurs de cette annonce-là, jamais sous ce prix, jusqu’à dimanche ». C’est le mandat que je voudrais vraiment, et personne n’en donne le format pour l’instant.

<figure class="fd-fig ap ap-f6" aria-labelledby="ap6-cap" data-desc="Mes propres approbations face à un mandat AP2. Ma flotte aujourd’hui : un agent de vente dans un Chrome connecté à mes comptes de revente sous mon nom, qui rédige chaque réponse aux acheteurs et attend mon OK dans le chat ; le mode auto de Claude Code qui refuse d’appliquer une attribution de permission tant que je ne l’ai pas approuvée à la main ; la pull request de cette note ouverte par un agent et fusionnée seulement par mon clic. Tout en humain présent, les limites seulement dans ma tête et dans un prompt. Un mandat : des limites écrites et signées une fois, liées à un agent, vérifiées par celui qui reçoit l’action, et qui expirent d’elles-mêmes. En dessous, le manque : la version 0.2 n’a de mandat que pour le checkout et le paiement.">
<div class="mp-two-row">
<div class="mp-two-card">
<p class="mp-two-who">Ma flotte, 28 octobre</p>
<p class="mp-two-name">Demander à chaque fois</p>
<p class="mp-two-line">Les réponses aux acheteurs attendent mon OK dans le chat</p>
<p class="mp-two-line">Attributions de permission : approuvées à la main</p>
<p class="mp-two-line">Merges : mon clic</p>
<p class="mp-two-line ap-gone">Limites : seulement dans ma tête et un prompt</p>
</div>
<p class="mp-two-vs">vs</p>
<div class="mp-two-card mp-two-peter">
<p class="mp-two-who">Un mandat AP2</p>
<p class="mp-two-name">Signer une fois</p>
<p class="mp-two-line">Des limites écrites et signées</p>
<p class="mp-two-line">Liées à la clé d’un seul agent</p>
<p class="mp-two-line">Vérifiées par celui qui les reçoit</p>
<p class="mp-two-line">Qui expirent d’elles-mêmes</p>
</div>
</div>
<p class="mp-strip"><b>Le manque</b><span>La v0.2 ne définit que des mandats de checkout et de paiement.</span></p>
<figcaption id="ap6-cap">Mon installation le jour où j’ai écrit ceci. La ligne barrée, c’est ce qu’un mandat remplacerait.</figcaption>
</figure>

## À essayer

Le passage sur AP2 dure deux minutes, à partir de 5:19:25. Regardez-le, puis lisez la page agent authorization de la spec. C’est l’explication la plus claire que j’aie vue de pourquoi les agents ont besoin de limites plus serrées que les gens.

Pour aller plus loin :

- [Le moment AP2 du direct](https://youtu.be/eB9I4Ixx2wc?t=19165), Live from AGNTCon + MCPCon North America, deuxième jour, le 23 octobre 2026, en anglais
- [Agent Payments Protocol](https://ap2-protocol.org/), le site, avec les pages [agent authorization](https://ap2-protocol.org/ap2/agent_authorization/) et [flows](https://ap2-protocol.org/ap2/flows/) (en anglais)
- [google-agentic-commerce/AP2](https://github.com/google-agentic-commerce/AP2), la spec et les exemples, Apache 2.0, v0.2.0 depuis avril 2026
- [Un agent peut porter votre demande, pas votre autorité](/fr/notes/agents-carry-requests-not-authority.html), les salles de Chi Wang où des agents de propriétaires différents travaillent ensemble
- [Espérer n’est pas sécuriser](/fr/notes/hope-isnt-security-enterprise-agents.html), où les clés n’entrent jamais dans la sandbox

Si vous avez signé un mandat ouvert pour autre chose qu’un achat, dites-moi à quoi ressemblaient les limites. J’aimerais beaucoup en voir un pour des messages.