Le Personal Agent Protocol est un projet de standard qui définit comment l'assistant IA d'une personne accède au site web, aux API et à l'agent de support d'une entreprise, et ce que l'entreprise l'autorise à y faire. Sierra et Meta l'ont annoncé avec des partenaires comme Stripe, Shopify et Walmart (annonce de Sierra), et une première version du draft, surnommée Poppy, a été rendue publique quelques jours plus tard (Sierra à propos du draft). Ce n'est pas un produit que vous pouvez activer aujourd'hui.
Si vous dirigez une entreprise, voici ce qu'il faut retenir : rien ne casse et rien n'est obligatoire. Mais des assistants IA visitent déjà des sites pour le compte de clients, et ce draft est la première tentative sérieuse de vous donner votre mot à dire sur la manière dont ils le font. En comprendre les grandes lignes dès maintenant demande une heure. L'ignorer pourrait vous coûter quelques années brouillonnes de règles anti-bots improvisées.
Cet article présente ce que définit le draft, en quoi il diffère de MCP, d'A2A et des protocoles de commerce, qui y a adhéré et qui n'y est pas, ainsi qu'une courte liste de choses à faire dès maintenant.
Ce qui est réellement public, et ce qui ne l'est pas
Trois éléments existent. Il y a l'annonce de Sierra, qui nomme les partenaires et les objectifs de conception. Il y a un projet de spécification, estampillé Draft 0.1, sous licence Apache 2.0 (spec). Et il y a la promesse d'ateliers de conception et d'une implémentation de référence, dont aucun n'était apparu dans les sources consultées pour cet article (Sierra).
Ce qui n'est pas encore public : aucune entreprise nommée qui l'utilise en production, aucune instance de gouvernance, aucune réponse arrêtée sur les paiements. Lors de l'annonce, un article relevait qu'aucune instance de gouvernance ni licence n'avait été identifiée (FourWeekMBA). La question de la licence a depuis été réglée par le draft lui-même. Celle de la gouvernance, dans les pages consultées, ne l'a pas été.
Considérez donc cela comme une proposition avec de sérieux soutiens. Meta a décrit l'ambition par une comparaison avec l'e-mail : « Email took off because everyone agreed on addressing, message transport and delivery. No one owns it, anyone can build on it » (VKTR). L'e-mail a aussi mis des années à s'imposer, et beaucoup d'entreprises ont appliqué leurs propres règles de messagerie étranges entre-temps. Attendez-vous à la même mosaïque ici : les premiers adoptants fixeront les conventions que les autres copieront.
Le problème : tout bloquer ou donner son mot de passe
Le site du projet décrit sans détour le choix actuel. Soit les entreprises bloquent totalement les agents, soit un agent se connecte avec les identifiants complets de l'utilisateur et peut faire tout ce que celui-ci peut faire (personalagentprotocol.org). Aucune des deux options n'est bonne. Bloquer agace le client qui a envoyé l'agent. Donner un accès complet, c'est un audit de sécurité qui attend de se produire.
Le blocage est une réalité. Un tour d'horizon de l'annonce cite Amazon, Delta, United, Zillow et eBay parmi les sites qui bloquent les agents, et mentionne une politique anti-bot de Cloudflare qui en a piégé certains par accident (AI Weekly). Kevin Miller, de Stripe, a résumé clairement le point de vue du client : les gens qui envoient un agent « s'attendent au même service que celui qu'ils obtiendraient eux-mêmes » (Unite.AI).
La réponse du draft est une échelle. Le site prend l'exemple d'un hôtel : bloquer l'agent, laisser n'importe quel agent chercher des chambres, lui laisser voir les réservations après connexion, ne lui laisser réserver une chambre qu'avec l'approbation de la personne à chaque fois, ou lui donner un accès complet. Vous choisissez l'échelon pour chaque action.
Les échelons intermédiaires sont l'essentiel. La plupart des entreprises voudront que les agents puissent parcourir et lire librement, et ne modifier quelque chose que si un humain dit oui.
Comment fonctionne une session
Une entreprise publie un fichier à l'adresse /.well-known/poppy.json qui indique comment les agents peuvent interagir avec elle. L'agent le lit, ouvre une session (en invité si personne n'est connecté) et, quand il a besoin de plus, envoie la personne vers une connexion basée sur OAuth (Sierra). Le draft nomme trois types de connexion : directe, où la personne se connecte sur la page de l'entreprise elle-même ; par appareil, où elle utilise un code sur un autre appareil ; et médiée, où l'agent soumet lui-même les identifiants (spec).
Deux détails comptent pour les équipes sécurité. Les tokens de session ont une durée de vie courte et sont liés à une clé via DPoP, et le draft précise que les agents ne doivent pas envoyer de tokens dans une URL et que les entreprises ne doivent pas les y accepter. Il admet aussi le point faible : « Accepting credentials from a Personal Agent puts more responsibility on the Company » (spec).
L'autre idée à retenir : un seul token couvre tout. Sierra affirme que le même token fonctionne pour les API de l'entreprise, son site web et les conversations avec son agent (Sierra). Une question posée avant la connexion et une commande modifiée après comptent comme une seule visite (The Next Web).
Trois voies d'accès, et c'est vous qui choisissez
Vous n'avez pas à tout construire. L'entreprise choisit comment les agents l'atteignent : via le site web, via des API décrites avec OpenAPI ou un serveur MCP, ou via son propre agent pour les conversations. Un commerçant doté d'une bonne API peut se passer de la voie navigation. Une petite boutique qui n'a qu'un site web peut commencer par là.
La voie conversationnelle comporte une règle que les clients apprécieront : chaque message indique si c'est un humain ou une IA qui l'a écrit, et le draft prévoit le transfert vers une personne. Si vous gérez déjà un agent de support, par exemple issu du classement des agents de support client, c'est la voie qui vous concerne en premier.
Articulation avec MCP, A2A, ACP et AP2
Il ne remplace aucun d'entre eux et il ne faut pas le lire comme leur concurrent. Ils couvrent des rôles différents, et le draft s'appuie lui-même sur MCP.
| Protocole | Créé par | Rôle |
|---|---|---|
| MCP | Standard open source | Connecte les applications d'IA à des outils et à des données (MCP docs) |
| A2A | Google, aujourd'hui Linux Foundation | Permet à des agents de fournisseurs différents de dialoguer entre eux (A2A) |
| ACP | Stripe et OpenAI | Paiement par agent et partage des identifiants de paiement (ACP) |
| AP2 | Mandats signés prouvant qu'un utilisateur a autorisé un achat (AP2) | |
| Personal Agent Protocol | Sierra et Meta (draft) | Découverte, sessions, connexion et permissions entre un agent personnel et une entreprise |
La pile ci-dessus est notre lecture, pas un schéma officiel. Pour le dire simplement : MCP, c'est la façon dont un agent appelle un outil ; A2A, celle dont les agents se parlent ; ACP et AP2 concernent le paiement ; et ce draft concerne le fait d'entrer par la porte et d'être reconnu. Les paiements sont annoncés comme une extension future, donc un paiement passerait encore aujourd'hui par quelque chose comme ACP ou AP2. Le chevauchement qui fera débat, c'est MCP, puisque le draft comme un simple serveur MCP peuvent exposer les actions d'une entreprise.
Il existe aussi un rival côté accès. Visa gère un Trusted Agent Protocol lancé plus tôt cette année, et The Next Web a rapporté que Stripe et Shopify l'avaient déjà rejoint (The Next Web). Visa figure aussi maintenant sur la liste des partenaires de conception du Personal Agent Protocol, donc les deux initiatives pourraient se recouper plutôt que s'affronter frontalement. Reste à savoir si l'industrie finira avec un standard ou deux.
Qui en fait partie, et qui manque
L'annonce citait Genesys, Instinct, Rocket, Shopify, Stripe et Walmart aux côtés de Sierra et Meta (Sierra). L'article sur le draft place aussi NiCE dans ce premier groupe et ajoute 35 autres partenaires de conception, dont Adyen, Bank of America, BBVA, Cloudflare, Mastercard, OpenAI, PayPal, Target, United Airlines, Visa et Wells Fargo. Sierra indique qu'ils participeront au processus de conception, ce qui n'équivaut pas à un support livré (Sierra). Cela modifie un récit antérieur : le jour de l'annonce, des articles signalaient l'absence d'OpenAI, et Bret Taylor, cofondateur de Sierra, préside le conseil d'administration d'OpenAI (AI Weekly).
Amazon, Anthropic et Google ne figurent pas parmi les partenaires cités au lancement ni dans l'article sur le draft. L'absence d'une liste ne prouve pas qu'ils sont en dehors, alors revérifiez les pages de Sierra avant de citer ce point. Claude, ChatGPT et Perplexity seraient tous des agents personnels naturels, et un standard sans grand assistant derrière lui reste une checklist côté entreprises. Le jour de l'annonce, The Next Web notait qu'aucun distributeur, banque ou société de paiement européen n'avait été nommé (The Next Web). La liste élargie inclut désormais BBVA et Adyen.
Ce que cela signifie pour les développeurs et les marketeurs
Les développeurs s'en sortent mieux. Si votre produit dispose déjà d'OAuth et d'une description OpenAPI, vous avez fait l'essentiel du chemin vers la voie API, et les règles du draft sur les tokens (durée courte, liés à une clé, jamais dans une URL) ressemblent à de simples bonnes pratiques. Le nouveau travail, c'est le fichier de découverte et la définition des scopes.
Les marketeurs héritent d'une question de mesure. Aujourd'hui, un agent qui étudie votre page de tarifs pour un client ressemble à un bot, ou à rien du tout. Une session qui identifie l'agent, et le client derrière lui, transforme ce trafic en quelque chose que vous pouvez compter et traiter différemment des scrapers. Que ce soit une bonne nouvelle dépend de ce que vous voulez que les agents disent de vous, ce qui relève autant du contenu que de la technique.
Ce qu'une entreprise peut faire dès maintenant
Rien de tout cela n'exige le protocole. Tout cela est utile, que le draft s'impose ou s'éteigne.
- Examinez vos logs et vos outils anti-bots pour savoir quel trafic d'agents vous atteint déjà. Si vous utilisez Cloudflare, vérifiez ce que ses règles anti-bots font aux agents qui agissent pour un client.
- Notez, action par action, ce qu'un agent peut lire et ce qu'il peut modifier. Servez-vous de l'échelle ci-dessus : parcourir, voir le compte, agir avec approbation.
- Vérifiez que les clients peuvent se connecter via un flux OAuth standard. Les agents s'appuieront dessus.
- Placez vos actions principales (suivi de commande, retours, réservations) derrière une API documentée ou un serveur MCP. Un fichier OpenAPI bien décrit vaut le coup de toute façon.
- Si vous vendez sur Shopify, surveillez ce que la plateforme livre plutôt que de le construire vous-même.
- Confiez à une personne la mission de suivre le draft. Lisez la page Open topics de la spec quand elle évolue.
Le scorer ci-dessous transforme cette liste en un auto-diagnostic rapide. C'est notre propre checklist, elle ne fait pas partie du protocole.
Qui n'a pas besoin de s'en soucier pour l'instant : une entreprise sans comptes clients, sans API et sans agent de support. Vous n'avez rien à exposer. Si vous êtes une boutique de service client, la comparaison la plus proche est l'agent IA que vous exploitez déjà (Sierra AI Agents en est un ; le classement des chatbots de support IA en liste d'autres). À lire aussi : notre guide d'achat des plateformes d'agents IA et le classement des meilleurs agents IA.
Les questions ouvertes
Identité. Le draft permet aux entreprises d'exiger l'enregistrement des agents, de tenir des listes d'autorisation et de blocage par client ID, et de révoquer un client ID qui détourne le protocole (spec). Qui se porte garant d'un agent, et comment une petite boutique en vérifie un, est laissé à chaque entreprise. Lors de l'annonce, les articles indiquaient qu'aucun détail n'était donné sur la façon dont les agents prouvent leur identité (FourWeekMBA). La spec ne décrit pas de registre partagé d'agents de confiance.
Consentement. La connexion directe affiche les scopes demandés et permet à la personne d'en approuver certains, tous ou aucun. C'est bien. Ce qui n'est pas réglé, c'est la fréquence à laquelle les agents demanderont, et si les gens cliqueront sans lire.
Responsabilité. Si un agent réserve le mauvais vol, quelqu'un en supporte le coût, et la spec ne dit pas qui. Elle ne mentionne pas du tout la responsabilité. Elle ne mentionne pas non plus les paiements, renvoyés à plus tard.
Spam et abus. Les entreprises peuvent limiter le débit de création de sessions par client ID. Reste à voir si cela tient face à des agents qui changent d'identité en boucle : ce n'est pas testé.
Foire aux questions
Le Personal Agent Protocol est-il en production ?
Pas en tant que standard livré. Une spec Draft 0.1 est publique et Sierra a promis des ateliers et une implémentation de référence. Aucun déploiement en production n'était nommé dans les sources consultées.
Remplace-t-il MCP ?
Non. Il désigne MCP comme l'un des moyens pour une entreprise d'exposer ses actions. MCP connecte une application d'IA à un outil. Le draft définit qui est l'agent et ce qu'il peut faire chez une entreprise donnée.
Dois-je publier un fichier poppy.json ?
Pas encore. Le draft prévoit que les entreprises le publient pour la découverte, mais personne n'y est tenu tant que la spec n'est pas stabilisée et que les agents ne se mettent pas à le lire. Préparer les décisions sous-jacentes est la partie utile.
Puis-je toujours bloquer les agents IA ?
Oui. Le blocage est le premier échelon de l'échelle. L'argument du draft, c'est que vous disposez d'options entre le blocage et l'accès complet.
Gère-t-il les paiements ?
Pas dans le draft. Sierra cite le paiement sans partage des données de carte comme une extension future. Pour le paiement aujourd'hui, regardez du côté d'ACP ou d'AP2.
Qui le contrôle ?
Le draft est sous licence Apache 2.0 et a été publié par Sierra avec Meta. Aucune instance de gouvernance n'apparaît dans les pages publiées, donc la question de qui le pilotera à long terme reste ouverte.