Commerce agentique
Comment les marchands implémentent-ils UCP et ACP en même temps ?
Mis à jour le
Ils ne sont pas un choix exclusif, et la majeure partie de l'implémentation est partagée. Les deux nécessitent la même base — un catalogue lisible par machine avec l'identité du produit, les variantes, ainsi que le prix et la disponibilité qui sont exacts au moment de la lecture. UCP spécifie ensuite la découverte et la construction du panier ; ACP spécifie la session de paiement et le paiement délégué au sein d'une interface d'IA. Construisez la couche de catalogue une fois, et le travail restant spécifique au protocole est le chemin de transaction, qui est aussi la partie encore en évolution.
La base commune représente la majeure partie du travail
Présentés comme des standards concurrents, ils ressemblent à un choix coûteux. Décomposés en obligations, le chevauchement est important et la divergence est tardive.
Les deux doivent savoir ce que vous vendez, sous une forme qu'une machine peut analyser sans interpréter une mise en page : identité du produit, variantes, attributs, un identifiant stable, et un prix et une disponibilité qui sont exacts au moment de leur lecture. Cette exigence n'est pas spécifique au protocole, elle n'est pas perdue si l'un ou l'autre standard échoue, et elle améliore la recherche classique en même temps.
| Couche | UCP | ACP | Partagé ? |
|---|---|---|---|
| Catalogue lisible par machine | Requis | Requis | Oui — construire une fois |
| Prix et stock en temps réel | Requis | Requis | Oui |
| Format du flux de produits | Format UCP | Spécification du flux ACP | Mêmes données source, sérialisation différente |
| Construction du panier | Spécifié | Spécifié | En grande partie |
| Session de paiement | Au niveau du panier | Spécification complète de la session | Non |
| Paiement délégué | Pas l'objectif principal | Spécifié | Non |
L'ordre qui ne laisse pas de travail en suspens
Ordonner par ce qui survit à la disparition d'un protocole.
- 1. Une source unique de vérité pour le catalogue avec des prix et une disponibilité exacts. Sert les deux, plus tout assistant qui n'implémente aucun des deux.
- 2. Sérialiser vers chaque format de flux à partir de cette source. Deux sérialiseurs sur un seul ensemble de données est un petit travail ; deux ensembles de données est un problème de réconciliation éternel.
- 3. Un devis et un panier programmatiques retournant un total contraignant incluant les frais de port et les taxes. Les deux protocoles en ont besoin et cela supprime la simulation de navigateur quoi qu'il arrive.
- 4. Des identifiants d'agent audités et à portée définie avant que quoi que ce soit puisse écrire. Aucun protocole ne le spécifie et les deux le supposent.
- 5. Le paiement et la délégation de paiement en dernier, car c'est la couche encore en évolution.
L'exigence de fraîcheur est le véritable défi technique
La plupart des marchands peuvent produire un catalogue structuré. Beaucoup moins peuvent en produire un dont les chiffres sont exacts au moment de la lecture, et c'est là que les implémentations de l'un ou l'autre protocole échouent.
Un flux rafraîchi chaque nuit annoncera avec confiance des stocks vendus le matin même, et un agent agissant sur celui-ci générera une annulation plutôt qu'une commande. Pour les entreprises d'abonnement, c'est encore plus critique : les renouvellements à venir sont des stocks engagés, donc un décompte de stock qui ne les réserve pas vendra des unités déjà promises.
C'est un véritable avantage architectural où l'inventaire, les commandes et les abonnements partagent un seul système plutôt que de se synchroniser à travers une limite d'intégration — la quantité réservée devient une propriété des données au lieu d'une tâche de réconciliation nocturne.
Questions fréquentes
- Dois-je choisir entre UCP et ACP ?
- Seulement si vous les considérez comme des produits à acheter plutôt que des obligations à remplir. Listés comme des obligations, le chevauchement représente la majeure partie du coût : l'identité, les variantes, le prix et le stock exacts sont exigés de manière identique par les deux, et seul le chemin de transaction diffère. Une équipe qui définit cela comme "choisir un standard" finit par séquencer la décision avant le travail, alors que le travail est le même dans les deux cas pour les quatre premières étapes.
- Lequel devrais-je implémenter en premier ?
- Aucun des deux, dans le sens qui compte : construisez d'abord la couche de catalogue, car les deux la nécessitent et elle est utile aux assistants qui n'implémentent aucun des deux. Le travail spécifique au protocole devrait commencer par la sérialisation du flux, ce qui est minime une fois que les données source sont correctes.
- La couche de paiement vaut-elle la peine d'être implémentée pour l'instant ?
- Pour la plupart des marchands, pas encore. OpenAI a fermé Instant Checkout en 2026 et a repositionné ACP vers la découverte, et les grands détaillants l'ont adopté du côté de la découverte. La partie la mieux placée pour savoir a retiré sa propre solution de paiement en chat ; le coût de la construction de cette intégration deux fois dépasse le coût d'être en retard une seule fois.
- Que supposent les deux protocoles que vous avez déjà ?
- Un accès agent audité et à portée définie — et aucun ne le spécifie. Les permissions par identifiant, l'idempotence sur les écritures, une piste d'audit durable et une validation humaine sur les actions irréversibles sont de la responsabilité de la plateforme, et elles font la différence entre une intégration d'agent et un incident.
Sources
- Standards de commerce agentique : UCP vs ACP vs AP2 — guide du marchand — Digital Applied