Meta, Walmart et Stripe veulent que les agents se connectent au lieu de cliquer. La spécification n'existe pas encore
By Surya Pratap
10 octobre 2026
9 min read
AI & Technology
10 octobre 2026
9 min read
Invité, puis lecture, puis écritureHover to exploreAujourd'hui, un agent IA personnel qui veut vérifier une commande, réserver une table ou changer une adresse de livraison fait comme un humain : il charge la page, trouve le formulaire et le remplit. C'est lent, cela casse dès que la page change, et l'entreprise ne sait généralement pas si elle a affaire à une personne ou à un programme.
Cette semaine, un groupe de grandes entreprises a proposé un autre fonctionnement : l'agent se connecte, le client décide de ce qu'il peut faire, et l'entreprise décide par où il entre.
Cet article s'appuie sur « Introducing Personal Agent Protocol », de Bret Taylor et Clay Bavor (Sierra), publié le 6 octobre 2026, ainsi que sur les articles de The Next Web, Constellation Research et The Daily Brief. Au moment de la rédaction, aucune spécification n'avait été publiée. L'analyse à partir de la section 4 est la mienne.
Le 6 octobre 2026, lors du sommet de Sierra à San Francisco, Sierra et Meta ont annoncé le Personal Agent Protocol, qu'ils présentent comme un standard ouvert sur « la manière dont les agents personnels interagissent avec les entreprises ». Les partenaires fondateurs cités sont Genesys, Instinct, Rocket, Shopify, Stripe et Walmart.
L'idée, selon les termes de Sierra : « les consommateurs décident de l'accès qu'ils accordent à leurs agents personnels, et les entreprises fixent le cadre de ce que ces agents peuvent faire ».
L'annonce articule le protocole autour des attentes de trois groupes :
L'intérêt de Meta est direct. Son agent personnel, Muse, est précisément le type d'agent visé. Selon Constellation Research, Muse applique deux tests avant d'agir : une personne honnête ferait-elle la même chose — l'exemple donné est la création de cinq comptes pour utiliser un seul coupon — et le système tiendrait-il si tous les agents le faisaient ?
L'annonce décrit une session à trois niveaux d'accès :
La session repose sur OAuth, le standard déjà utilisé par la plupart des connexions. Elle « se poursuit d'un canal à l'autre : une question posée avant la connexion et une modification de commande faite après font partie de la même visite ».
Côté entreprise, c'est elle qui choisit comment les agents l'atteignent :
Le client choisit ce que l'agent peut faire. L'entreprise choisit la porte par laquelle il entre. Pour l'instant, la proposition tient tout entière dans ce partage.
Il s'agit d'une annonce, pas d'un standard que vous pouvez implémenter cette semaine.
Bret Taylor, cité par The Daily Brief, résume la situation : « Tant qu'un tel standard n'existe pas, c'est un peu le chaos. »
Les fondateurs ont intérêt à lire cette annonce à côté de celles qu'elle recoupe. The Daily Brief en a comparé quatre :
| Protocole | Principaux soutiens | Objet |
|---|---|---|
| Agentic Commerce Protocol (ACP) | OpenAI, Stripe | Paiement au sein de l'agent, avec des jetons de paiement limités |
| Trusted Agent Protocol (TAP) | Visa, Cloudflare | Prouver l'identité d'un agent par des requêtes signées |
| Universal Commerce Protocol (UCP) | Google, Shopify et d'autres | L'achat de bout en bout, de la découverte à l'après-vente |
| Personal Agent Protocol (PAP) | Sierra, Meta, Walmart et d'autres | Comment l'agent d'une personne se connecte et ce qu'il peut faire |
Stripe et Shopify sont impliqués dans les quatre. Les entreprises qui ont le plus à perdre en misant sur le mauvais standard ont choisi de ne pas choisir. Une startup de cinq personnes ne devrait pas chercher à être plus sûre qu'elles.
Ces protocoles répondent en outre à des questions différentes. TAP porte sur quel agent appelle. ACP sur le paiement. PAP sur ce que ce client a autorisé cet agent à faire dans son compte. Un produit réel pourrait avoir besoin d'éléments de plusieurs d'entre eux.
Bonne nouvelle : le travail de fond qu'exigent tous ces protocoles est le même, et l'essentiel améliore aussi votre produit pour les humains.
Rendez les informations publiques lisibles sans connexion. Stock, prix, horaires, zones de livraison, politique de retour. Si un agent en mode invité ne peut pas les lire de façon fiable, il enverra son utilisateur ailleurs. Des données structurées sur vos pages comme une petite API en lecture seule font l'affaire.
Séparez l'accès en lecture de l'accès en écriture. Si votre API n'a qu'un jeton qui peut tout faire, un agent que le client voulait seulement autoriser à consulter ses commandes peut aussi les annuler. Des scopes OAuth distincts pour « consulter le compte » et « modifier le compte » sont le minimum que suppose le protocole.
Faites en sorte que les écritures puissent être rejouées sans risque. Les agents réessaient. Une modification de commande, une réservation ou une demande de remboursement doit accepter une clé d'idempotence, pour qu'une même requête envoyée deux fois ne s'exécute qu'une fois. Ajoutez une étape de confirmation pour tout ce qui est coûteux ou irréversible.
Identifiez les sessions d'agents. Enregistrez si une action vient d'une personne, d'un agent connu agissant pour le client ou d'un script inconnu. Impossible de fixer des limites de débit, de repérer les abus ou de mesurer le chiffre d'affaires apporté par les agents si vous ne distinguez pas ce trafic.
Si vous exposez déjà une API, un serveur MCP couvrant quelques-unes des tâches les plus courantes de vos clients est un moyen peu coûteux d'apprendre ce que les agents demandent vraiment. Commencez par des outils en lecture seule. N'ajoutez des outils d'écriture qu'une fois que vous voyez qui appelle et que l'idempotence et la confirmation sont en place.
Choisir son canal
Le protocole vous laisse choisir entre votre site, votre API et votre propre agent. Pour la plupart des produits en phase de lancement, la bonne première réponse est l'API : un site web est fragile pour un agent, et faire tourner votre propre agent face aux clients est un produit à part entière. Proposez votre propre agent quand la tâche exige vraiment une conversation — un retour compliqué, une question sur un prêt immobilier — et non comme porte d'entrée par défaut.
Que le PAP va s'imposer. Il a de grands noms et aucune spécification. UCP, ACP et TAP ont chacun leurs poids lourds, et le chevauchement de leurs membres montre que rien n'est joué.
Que les agents vont arriver bientôt dans votre produit. Les propres études de Visa montrent que la plupart des gens ne sont toujours pas prêts à laisser un agent payer à leur place. Le protocole rend les agents plus capables ; il ne rend pas les clients plus confiants.
Qu'il règle les questions juridiques. L'annonce ne dit pas qui est responsable lorsqu'un agent disposant d'un accès en écriture fait quelque chose que le client n'avait pas voulu. Elle ne dit pas non plus comment les paiements approuvés par un agent s'articulent avec des règles comme l'authentification forte du client en Europe, conçues pour une personne qui approuve un paiement. Pour voir comment un tribunal a considéré des agents agissant pour le compte d'utilisateurs, lisez notre analyse de la décision du Ninth Circuit dans l'affaire Perplexity.
Que les détails sont figés. Tout ce qui figure dans les sections 2 et 3 provient d'une annonce. La spécification v0.1 pourra changer des noms, des scopes ou le modèle de session.
Meta, Sierra, Walmart, Shopify, Stripe et d'autres ont proposé une manière standard pour l'agent IA d'une personne de se connecter à une entreprise. Les agents commencent en invité, le client choisit via OAuth un accès en lecture seule ou en écriture, et l'entreprise choisit si les agents passent par son site, ses API ou son propre agent. Il n'y a encore ni spécification, ni paiements, ni permissions fines, ni instance de gouvernance, et c'est l'un de quatre protocoles qui se recoupent.
Le protocole que vous adopterez finalement compte moins que les fondations qu'ils supposent tous : des informations publiques lisibles par un agent, un accès aux comptes limité par des scopes, des écritures qu'on peut rejouer sans risque et la capacité de distinguer le trafic des agents de celui des humains.
Choisissez les trois tâches les plus courantes de vos clients. Faites fonctionner celles en lecture seule sans connexion, et rendez celles en écriture limitées, rejouables et journalisées. Puis lisez la spécification v0.1 à sa sortie, au lieu d'attendre sa sortie pour commencer.
Sources : Bret Taylor et Clay Bavor, « Introducing Personal Agent Protocol », Sierra, 6 octobre 2026 — les partenaires, le principe énoncé, les attentes des trois groupes, les niveaux invité, lecture seule et écriture, OAuth et les sessions multicanales, les canaux site web, API et agent de l'entreprise, le calendrier de la v0.1 et les travaux futurs sur les paiements, les permissions et les notifications. The Next Web pour la date et le contexte de l'annonce. Larry Dignan, Constellation Research, 7 octobre 2026 — Muse de Meta et ses deux tests. Rajesh Beri, The Daily Brief, 7 octobre 2026 — l'absence de spécification, de licence et d'instance de gouvernance, la citation de Bret Taylor et la comparaison avec UCP, ACP et TAP. L'analyse des sections 4 à 6 est la mienne.
IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.
