GUIDE

Comment fonctionne le punchout

Un guide en langage clair pour les fournisseurs Shopify dont le plus grand client vient de prononcer les mots « catalogue punchout ».

Quelque part dans votre boîte de réception se trouve un message de votre plus grand client qui ressemble à ceci : « Notre service achats demande si vous gérez les catalogues punchout. Avez-vous un endpoint cXML ? » Si vous exploitez une boutique B2B sur Shopify et que cette phrase sonne comme une langue étrangère, ce guide est la réponse longue. Il couvre ce qu'est réellement le punchout, l'aller-retour complet étape par étape, la différence entre cXML et OCI, ce que Shopify apporte déjà, ce que les réseaux d'achat vont exiger de vous, et où un connecteur trouve sa place.

Ce qu'est le punchout

Le punchout est la façon dont les grandes entreprises achètent chez leurs fournisseurs sans quitter leur propre logiciel d'achats. Votre client ne navigue pas sur le web ouvert. Il travaille dans un système e-procurement : SAP Ariba, Coupa, Ivalua, Jaggaer, Oracle, Workday, ou un ERP SAP. Quand il a besoin de vos produits, il clique sur votre nom dans ce système. Votre catalogue s'ouvre dans une fenêtre, il fait son panier, et le panier retourne dans son système sous forme de demande d'achat. Il n'appuie jamais sur un bouton de paiement chez vous, et aucun argent ne transite par votre site. Le bon de commande arrive plus tard, par un canal séparé.

Toute cette cérémonie existe pour une raison : le contrôle. Les équipes achats sont payées pour faire respecter circuits de validation, budgets et prix négociés sur chaque commande. Une boutique en ligne publique ne fait respecter rien de tout cela, alors leur logiciel enveloppe le vôtre : les emplettes se font chez vous, la commande se passe chez eux.

Pour un fournisseur, le punchout fait la différence entre être un fournisseur référencé sur le papier et l'être en pratique. Si commander chez vous oblige à quitter le système, à recopier des références dans un formulaire et à joindre un PDF, les acheteurs glissent vers le concurrent qui est connecté. Si votre catalogue est à un clic dans leur outil, à leurs prix contractuels, rester chez vous devient le chemin de moindre résistance.

L'aller-retour, étape par étape

Une relation punchout a deux moitiés : la sortie pour acheter, et le bon de commande au retour. Six étapes bouclent le cycle.

  1. Requête de setup. L'acheteur clique sur votre catalogue. Son système appelle votre endpoint punchout avec une requête authentifiée. En cXML, c'est un document PunchOutSetupRequest portant identités réseau et shared secret. En OCI, c'est un appel HTTP portant USERNAME, PASSWORD et une HOOK_URL de retour.
  2. Démarrage de session. Votre côté valide les identifiants, détermine quelle entreprise et quels prix contractuels s'appliquent, et répond avec une URL de démarrage. Le navigateur de l'acheteur ouvre votre catalogue, déjà dans le bon contexte client.
  3. Achats. L'acheteur parcourt votre vraie boutique : vos données produit, vos images, vos stocks. Les prix affichés sont ses prix négociés, pas la liste publique.
  4. Transfert du panier. À la place d'un checkout, il y a un transfert. Le panier part en message structuré, une PunchOutOrderMessage en cXML ou des champs NEW_ITEM en OCI, et atterrit dans le système du client comme brouillon de demande d'achat.
  5. Validation. La demande d'achat suit le circuit de validation du client. Une heure ou trois semaines. Votre boutique n'y participe pas et rien n'attend de votre côté.
  6. Bon de commande. La demande d'achat validée devient un bon de commande. Sur les réseaux cXML, il peut être transmis directement à votre endpoint sous forme de document OrderRequest et devenir une commande dans votre boutique, sans intervention humaine.

Les deux moitiés comptent, parce que beaucoup d'intégrations ne font que la première. Le panier arrive élégamment chez le client, puis le bon de commande revient en PDF que quelqu'un de votre équipe ressaisit un vendredi après-midi. Quand vous évaluez un dispositif punchout, posez toujours la question des deux sens.

cXML face à OCI

Deux protocoles portent la quasi-totalité du trafic punchout, et celui qu'il vous faut dépend entièrement des systèmes de vos clients.

cXML (Commerce XML) est le standard du monde Ariba, et le plus répandu des deux. Il est documentaire : quatre types de documents XML composent un cycle complet (PunchOutSetupRequest, PunchOutSetupResponse, PunchOutOrderMessage, OrderRequest). Coupa, Ivalua, Jaggaer, Oracle et Workday le parlent aussi. Sa force déterminante est le trajet retour : les bons de commande voyagent par le même protocole, et l'automatisation complète dans les deux sens est le cas normal. Si vos clients sont de grandes entreprises nord-américaines ou des groupes français sur Ivalua ou Coupa, le cXML est presque certainement ce qu'ils entendent par punchout. Voir les pages Ariba et Coupa pour le détail de chaque réseau.

OCI (Open Catalog Interface) est le standard plus ancien et volontairement simple de SAP, dominant dans l'Europe germanophone et présent partout où SAP SRM ou S/4HANA gère les achats. Pas de documents XML à l'aller : l'ERP appelle l'URL de votre catalogue avec un paramètre HOOK_URL, et le panier revient en champs NEW_ITEM indexés. OCI déplace des paniers, pas des bons de commande ; le bon de commande revient par le canal que l'ERP maîtrise, du propre OrderRequest cXML à l'impression papier. La complexité pratique vit dans les dialectes de champs : unités, groupes de marchandises et extensions NEW_ITEM varient selon l'installation. Détails sur la page OCI.

Beaucoup de fournisseurs européens finissent par avoir besoin des deux : un client sur SAP auto-hébergé, le suivant sur Ariba ou Coupa. C'est l'argument pour traiter les deux protocoles dans un seul connecteur plutôt que dans deux projets. Une comparaison pratique, dialectes de champs et trajet retour compris, se trouve (en anglais) dans cXML vs OCI, practically.

Ce que Shopify apporte, et ce qu'il n'apporte pas

La bonne nouvelle d'abord. Shopify B2B couvre déjà la moitié commerciale de la checklist punchout, celle qui est vraiment difficile à rattraper après coup : comptes entreprise avec plusieurs company locations, catalogues et listes de prix par location (ce sont vos prix contractuels), règles de quantité comme minimums et conditionnements, conditions de paiement. Si vous vendez déjà en gros sur Shopify, le modèle de prix et de droits que les clients punchout exigent est probablement déjà configuré.

Ce que Shopify n'a sur aucun plan, c'est un endpoint punchout. Rien ne reçoit une PunchOutSetupRequest, rien ne valide un shared secret, rien ne renvoie une PunchOutOrderMessage au transfert du panier, rien ne gère une HOOK_URL OCI, rien n'ingère un OrderRequest. Les fonctions B2B de Shopify s'arrêtent au bord de votre boutique ; le punchout est précisément la machinerie qui franchit ce bord vers le système du client.

C'est ce vide qu'un connecteur remplit : les endpoints des protocoles, la validation des identifiants, la session qui associe une identité réseau à la bonne company location, la transformation du panier à l'aller, l'ingestion du bon de commande au retour, et les logs qui rendent l'ensemble vérifiable.

Ce que les réseaux d'achat exigent des fournisseurs

Le protocole est la moitié rapide d'un projet punchout. La moitié lente est l'enablement : le processus que chaque réseau ou chaque client déroule avant la mise en production de votre connexion. Il varie fortement, et mieux vaut le connaître avant de promettre une date.

Ariba est le poids lourd. Trading relationship sur SAP Business Network, échange d'identités et de shared secret, fichier d'index catalogue par client à faire valider, tests dans le test realm de l'acheteur. Le punchout exige en pratique un compte Enterprise, et Ariba est le seul grand réseau qui facture les fournisseurs : commission de 0,155 % plafonnée à 20 000 USD par relation et par an une fois les seuils franchis, et paliers d'abonnement où l'automatisation cXML vous place en Silver, à 750 USD par an. La documentation de vrais acheteurs annonce 8 à 12 semaines, l'essentiel en coordination, pas en technique.

Coupa est le poids plume. Portail fournisseur gratuit, aucuns frais, et l'admin de votre client configure la connexion lui-même dans sa propre instance. Les premières connexions aboutissent couramment en une à deux semaines, ce qui fait d'un client Coupa le premier projet punchout idéal. Ivalua, Jaggaer, Oracle et Workday se situent entre les deux : base cXML, pas de frais fournisseur, enablement au rythme de l'équipe projet du client.

Sur tous, un même schéma se répète : les heures d'ingénierie sont petites, les semaines de coordination non. Le levier que vous contrôlez est la vitesse de fermeture de chaque boucle de test, et des logs de session bruts que l'équipe IT de votre client peut lire sans réunion sont le meilleur outil pour cela.

Où PunchRelay trouve sa place

PunchRelay est un connecteur punchout construit uniquement pour Shopify. Il donne à votre boutique des endpoints cXML et OCI, valide les identifiants de chaque client, ouvre les sessions punchout sur la company location Shopify B2B que vous désignez, applique vos règles de quantité avant le transfert du panier, renvoie le panier dans le dialecte attendu par le système du client, et transforme les OrderRequest cXML entrants en commandes Shopify, acquittés en moins de 150 millisecondes. Chaque message, dans les deux sens, est logué brut, parce que c'est le log qui raccourcit l'enablement.

Nous accompagnons en ce moment des marchands en accès anticipé et construisons leurs premières connexions acheteurs avec eux. Si un client vient de vous demander du punchout, commencez par la page qui correspond à son système : SAP Ariba, Coupa ou OCI pour SAP. Ou laissez votre e-mail ci-dessous et nous tracerons le chemin le plus court vers votre première connexion en production.

Demander un accès anticipé

Nous accompagnons un petit groupe de marchands Shopify B2B et construisons leurs premières connexions acheteurs avec eux. Dites-nous où vous joindre.

Pas de spam. Nous répondons personnellement.