Audit de readiness UCP
en quatre phases.

Ce que la phase de cartographie va effectivement chercher

La grille n'est pas arbitraire : elle suit ce que la spécification UCP demande à un marchand de publier. Un audit de readiness consiste à confronter l'existant à ces attendus, point par point.

Le profil et la négociation de capacités

UCP fonctionne par négociation : une entreprise publie un profil décrivant ses capacités et ses services, et la plateforme découvre dynamiquement ce qu'elle peut faire avec elle. L'audit vérifie donc moins « avez-vous une API » que « qu'annoncez-vous être capable de faire, et est-ce exact ». Les capacités sont nommées en domaine inversé, ce qui permet à un acteur d'ajouter une extension sous son propre namespace sans comité d'approbation central. Une gouvernance décentralisée, donc, mais qui suppose de savoir ce qu'on déclare. Établi

Les transports

La spécification définit les services en REST et en JSON-RPC, et supporte plusieurs couches de transport pour l'interopérabilité. La question d'audit n'est pas « faut-il choisir » mais « lequel votre stack peut-elle exposer sans réécriture ». C'est souvent là que se joue l'écart entre un chantier de trois semaines et un chantier de six mois.

Le checkout et ses points de rupture

La session de checkout expose un statut qui pilote l'agent, avec les états incomplete, requires_escalation, ready_for_complete, complete_in_progress, completed et canceled. Les erreurs sont classées par gravité : récupérable, nécessitant une saisie de l'acheteur, nécessitant une revue, ou irrécupérable.

L'audit cartographie ici vos vraies conditions de rupture, celles que vos équipes connaissent et qui ne sont écrites nulle part : vérification d'âge, seuil de signature, zone de livraison, produit soumis à ordonnance, dérogation tarifaire. Chacune doit trouver sa place dans requires_escalation plutôt que de casser le parcours. C'est le livrable le plus utile de la phase I, et celui que les marchands sous-estiment le plus.

Le paiement, instruments et handlers

UCP sépare les instruments de paiement des handlers qui les mettent en œuvre. Cette séparation est ce qui permet à un marchand de changer de prestataire sans renégocier son intégration agentique. L'audit vérifie que votre chaîne actuelle supporte cette distinction, ou ce qu'il faudrait pour qu'elle la supporte. Établi

Deux points de cadrage évitent des mois de discussion inutile en comité. Le vendeur de record ne change pas : vous restez le vendeur. Et la capacité Checkout n'introduit pas d'obligation de conformité PCI DSS pour les paiements par carte. La question « perd-on la main sur la transaction » a donc une réponse écrite, et elle est non.

L'éligibilité et le degré d'autonomie

UCP prévoit une vérification d'éligibilité : des claims doivent être résolus avant qu'une transaction aboutisse. C'est le mécanisme des prix contractuels, des restrictions géographiques et des conditions client. L'audit recense ce que vous conditionnez aujourd'hui, et si c'est exprimable.

Enfin, le curseur d'autonomie se règle en un seul endroit : la commande doit être finalisée manuellement par l'utilisateur dans une interface de confiance, sauf si l'extension AP2 Mandates est supportée. Un marchand qui vise le réassort automatique a besoin des mandats AP2. Un marchand qui vise la découverte assistée n'en a pas besoin. Cet arbitrage, posé en phase III, change le coût du projet du simple au triple. Établi

Sources : spécification UCP, vue d'ensemble et capacité Checkout, version 2026-04-08. Pour la mise en œuvre, voir le guide d'implémentation et les cas d'usage par typologie.