Aller au contenu
UCP
Menu

Ressources · Essai

Catalogue comme API

Traiter le catalogue produit comme une surface d'API délibérée — versionnée, typée, documentée. Le shift mental, les implications opérationnelles.

Publié : ·10 min de lecture ·Requête : catalogue produit api

La plupart des marchands traitent leur catalogue produit comme de la donnée — un corpus d'enregistrements stockés dans un PIM, synchronisés vers un storefront, exportés comme flux. Ce cadrage n'est plus suffisant. Un agent ne consomme pas votre donnée comme de la donnée ; il consomme votre catalogue comme s'il s'agissait d'une API. Une fois le shift perçu, la pratique opérationnelle change en conséquence.

Le cadrage

Les APIs ont quatre propriétés que les catalogues n'ont habituellement pas : contrat, versioning, documentation, et garanties de fiabilité. Les agents exploitent les quatre. Si votre catalogue en manque, l'agent compense par devinette, scraping et confiance réduite — tout cela pénalise votre visibilité.

Contrat

Un contrat d'API définit quels champs existent, quels types ils portent, quelles plages ils acceptent. Un contrat de catalogue signifie :

  • Chaque produit a des champs identifiants (GTIN, MPN+Marque).
  • Les champs prix sont typés (nombre + devise), pas des chaînes.
  • La disponibilité est énumérée (in_stock / out_of_stock / pre_order / back_order).
  • Les politiques sont des objets structurés, pas de la prose.
  • Les attributs custom ont des types et unités déclarés.

Le contrat peut vivre à plusieurs endroits : le JSON-LD de vos PDPs, le schéma de votre flux et — idéalement — un schéma lisible par machine publié à une URL stable. Traitez-le comme source de vérité.

Versioning

Les APIs versionnent. Les catalogues rarement. Résultat : quand un marchand change le sens d'un attribut (« Délai de livraison » signifiait auparavant traitement + transit, désormais juste transit), tout consommateur aval casse silencieusement. Les agents ayant caché des interprétations anciennes sont dans le faux.

Un contrat de catalogue devrait porter un numéro de version. Les breaking changes devraient le bumper. Les ajouts non-breaking devraient être clairs. Les dépréciations devraient être annoncées. La discipline coûte peu et prévient le mode d'échec silencieux le plus fréquent des opérations de flux.

Documentation

La documentation d'un catalogue signifie :

  • Une description publique de chaque attribut que vous exposez.
  • Les conventions d'unités (cm vs pouces, grammes vs oz).
  • Les valeurs énumérées et leurs significations (états de disponibilité).
  • Les SLAs de fraîcheur (« stock mis à jour toutes les 10 minutes »).
  • Les schémas de politiques (quels champs porte votre structure de retours).

La plupart des marchands n'écrivent rien de tout cela. Les meilleurs le publient. Le faire aligne marketplaces, partenaires affiliés, agents — et vos propres équipes internes.

Fiabilité

Les APIs s'engagent sur la fiabilité. Les catalogues devraient aussi. Les deux engagements mesurables :

  • Parité entre surfaces (flux, PDP, checkout). L'incohérence est traitée par les agents comme un défaut de fiabilité.
  • Fraîcheur : une cadence de rafraîchissement annoncée que vous tenez.

« Notre flux est mis à jour toutes les 15 minutes » est un engagement. « On met le flux à jour quand on y pense » est un mode d'échec que les agents mesurent.

Implications opérationnelles

  1. Tenez un changelog de catalogue. Publiez-le là où partenaires et agents peuvent le trouver. Même un simple fichier Markdown daté à /catalogue/changelog vaut mieux que le silence.
  2. Alignez les sources. Le PIM est source de vérité. Flux et PDP s'en rendent. Toute divergence est un bug.
  3. Typez vos attributs custom. Si vous avez « Warranty_Length » comme chaîne libre, convertissez en entier avec unité.
  4. Exposez un endpoint de lecture. Si les orchestrateurs d'agents veulent vous appeler directement (via MCP par exemple), publiez un endpoint catalogue simple.
  5. Mesurez la parité. Job nightly : échantillonnez 100 SKUs, diffez flux vs PDP vs checkout, alertez sur deltas >1 %.

Le shift mental

« Catalogue » sonne comme un artefact statique. « API » sonne comme un système vivant avec des utilisateurs. Une fois que vous voyez votre catalogue comme un système vivant avec des utilisateurs externes — des utilisateurs qui vous citeront, vous compareront et transactent avec vous — le niveau de discipline ambient monte. Les champs sont mieux nommés. Les unités sont indiquées explicitement. Les dépréciations sont annoncées. La parité est mesurée. C'est là tout l'intérêt du cadrage.

Où aller ensuite