PunchOut : proposer son catalogue directement dans l'ERP d'un grand compte

La demande du client paraît simple

Un grand compte souhaite retrouver le catalogue de son fournisseur depuis son outil achats ou son ERP. L'acheteur navigue dans une sélection de produits, constitue un panier, puis revient dans son système d'origine pour suivre les validations et passer commande. Ce fonctionnement est connu sous le nom de PunchOut.

Pour le fournisseur, ce n'est pas un site e-commerce ordinaire : les informations doivent respecter un contrat d'échange, un contexte d'achat, des règles de catalogue et parfois des conditions commerciales propres à chaque organisation.

Le point de départ : le métier, puis le protocole

Dans un contexte professionnel de conception d'échanges B2B grands comptes, les vrais sujets ne se limitent pas à afficher des produits. Il faut déterminer qui identifie l'acheteur, quel catalogue il est autorisé à voir, comment sont obtenus les prix et les stocks, et ce qui est retourné à son outil achats.

Selon les écosystèmes, OCI et cXML peuvent intervenir dans ces échanges. Ils ne résolvent pas à eux seuls les mappings de références, unités de mesure, conditionnements, classifications ou contraintes d'approvisionnement.

Le parcours qu'il faut rendre robuste

Le système achats du client ouvre une session PunchOut contextualisée. Le fournisseur contrôle l'accès et expose les produits autorisés, alimentés par ses systèmes de catalogue et de gestion. Au retour, le panier est retransmis dans le format convenu, avec les champs attendus pour la validation interne du client.

Le panier retourné ne signifie pas nécessairement que le fournisseur a reçu une commande. Selon le processus, la commande n'existera qu'après approbation dans l'ERP ou l'outil achats du client. Confondre ces deux étapes crée de graves erreurs d'exploitation.

Il faut également prévoir les cas moins visibles : session expirée, article devenu indisponible, changement de conditionnement, prix non concordant, donnée manquante ou retour de panier incomplet.

Concevoir un socle réutilisable pour plusieurs grands comptes

Créer une intégration entièrement différente pour chaque client fait augmenter la dette technique. Une architecture plus durable sépare le noyau catalogue/panier des adaptateurs OCI ou cXML, des règles de visibilité, des mappings et des particularités contractuelles de chaque grand compte.

Ce modèle doit être validé sur les flux réels. Les noms d'outils, les champs obligatoires et les mécanismes d'authentification varient ; aucun protocole ne garantit l'interopérabilité sans tests de bout en bout.

Ce que la direction doit décider

Qui prend la responsabilité d'une information erronée ? Quelles sont les limites de synchronisation des prix et stocks ? Qui déclenche réellement la commande ? Quelles preuves et journaux permettent de comprendre un incident ? Quel contrat d'interface permet d'intégrer un nouveau client sans réécrire la plateforme ?

Intervention possible de Mahthildis

Paulo Castro peut cadrer le besoin achats et catalogue, définir les API et mappings, challenger un intégrateur, piloter la réalisation et prendre en charge des composants techniques convenus. L'objectif n'est pas seulement d'ouvrir un catalogue : c'est de fiabiliser le processus d'achat B2B entre deux organisations.

À retenir : le PunchOut n'est ni une vitrine ni un simple bouton « commander ». C'est un processus interentreprises à sécuriser, du contexte d'achat jusqu'au retour de panier.