Valider une implémentation UCP avant la production

Plan de validation UCP : manifeste, négociation, schémas, états, signatures, idempotence, sécurité et tests de bout en bout.

Publiée le 24 septembre 2026 . Rattachée à le guide d'implémentation UCP.

Une implémentation UCP n’est pas validée parce qu’un checkout nominal fonctionne. Elle doit prouver la découverte, la négociation, la conformité des schémas, les transitions d’état, les reprises et la sécurité de chaque transport annoncé.

En bref

Tester chaque capacité déclarée, pas seulement le parcours heureux.

Valider le profil et les messages à chaque version négociée.

Prouver qu’un timeout ou un webhook doublé ne crée aucun second effet.

1. Le manifeste est-il exploitable ?

Servir /.well-known/ucp en HTTPS avec un JSON conforme. Vérifier version, services, capabilities, payment_handlers et la clé canonique keys. Chaque URL de spec, schema et endpoint doit être accessible et correspondre à ce qui est réellement implémenté.

Le test doit couvrir un profil absent, mal formé, expiré ou signé avec une clé inconnue. Les statuts attendus sont décrits dans le manifeste UCP champ par champ.

2. La négociation retire-t-elle correctement l’incompatible ?

Construire des matrices avec versions communes, versions disjointes, extensions orphelines et extensions multi-parent. L’intersection doit choisir la version commune la plus élevée, puis répéter l’élagage jusqu’à ce qu’aucune dépendance ne manque.

Une intersection vide est un résultat métier, pas toujours une erreur HTTP. Le test doit donc vérifier le corps UCP même lorsque la réponse REST est 200.

3. Les payloads respectent-ils les schémas composés ?

Télécharger les schémas de base et les extensions actives, vérifier leurs contraintes de version, les composer avec allOf, puis valider requêtes et réponses. Tester les champs obligatoires, formats, enums, montants en unité mineure et champs inconnus.

Pour Catalog, vérifier la stabilité des IDs jusqu’au checkout. Pour Cart, vérifier le remplacement complet lors d’Update. Pour Checkout, tester les six états et chaque sévérité de message. Pour Order, vérifier que chaque réponse contient l’instantané complet.

4. Les opérations avec effet sont-elles idempotentes ?

Envoyer deux fois la même requête avec la même clé. La seconde réponse doit être celle du cache, sans nouveau paiement ni nouvelle commande. Envoyer ensuite un payload différent avec la même clé : le serveur doit refuser avec 409.

Simuler une perte de réponse après traitement, un 429, un 503 et un timeout de Complete Checkout. Le client doit réutiliser la clé et respecter le délai de reprise. Le plan détaillé se trouve dans Erreurs UCP, reprises et idempotence.

5. Les signatures sont-elles vérifiées sur les octets reçus ?

Tester une signature valide, un digest modifié, un chemin modifié, une clé inconnue et une clé retirée. Le calcul de Content-Digest doit porter sur les octets bruts. Les webhooks Order doivent être rejetés si la signature manque ou échoue.

Vérifier aussi la rotation avec deux kid simultanés. Les règles et algorithmes sont résumés dans Signatures de messages UCP.

6. Les handoffs protègent-ils l’utilisateur ?

Une erreur requires_buyer_input ou requires_buyer_review doit ouvrir un continue_url autorisé. Le transport embarqué doit vérifier l’origine, imposer le handshake et arrêter toute communication après une erreur de sécurité.

Les credentials ne doivent apparaître ni dans l’URL, ni dans les logs, ni dans les messages d’erreur. Les scopes OAuth demandés doivent être minimaux et chaque commande personnelle doit être protégée par une autorisation utilisateur.

7. Le repli humain reste-t-il possible ?

Tester les scénarios non représentables par API : produit indisponible, disclosure obligatoire, authentification, contrôle bancaire ou retour complexe. L’agent doit expliquer la raison du handoff, préserver la session et reprendre ensuite sans dupliquer l’action.

Matrice de recette minimale

Domaine	Cas nominal	Cas d’échec indispensable
découverte	profil valide	424 profil inaccessible
négociation	version commune	extension orpheline
Catalog	Search et Lookup	ID inconnu
Cart	conversion	checkout déjà existant
Checkout	completed	escalation et timeout
Order	lecture et webhook	webhook doublé ou non signé
OAuth	consentement accordé	scope insuffisant

Critère de sortie

La production peut être ouverte lorsque chaque capacité annoncée possède une preuve de conformité, chaque opération avec effet est idempotente, chaque webhook est authentifié et chaque erreur connue conduit à une action déterministe. Une capacité non testée doit être retirée du manifeste jusqu’à sa validation.

Sources

Revenir à le guide d'implémentation UCP · Toutes les notes · Read in English