Qu’est-ce que PunchOut ? Le guide complet pour les fournisseurs

Comment fonctionne PunchOut

PunchOut connecte deux systèmes qui n’ont pas été conçus pour communiquer : le système d’achat de votre client et votre boutique en ligne. Les grandes organisations achètent via des systèmes d’eProcurement comme SAP Ariba, Coupa ou SAP S/4HANA, où chaque achat suit des règles d’approbation et est imputé au bon budget. Au lieu de copier vos produits dans ce système, elles vous demandent un catalogue PunchOut : un lien qui ouvre votre boutique depuis leur système d’achat.

Une session PunchOut comporte quatre étapes :

1. Configuration. Un demandeur clique sur votre catalogue dans son système d’achat. Le système vous envoie une demande de configuration avec des identifiants et une adresse de retour.
2. Achat. Votre boutique s’ouvre dans leur navigateur, déjà connectée avec le rôle de ce client, avec son catalogue et ses prix contractuels.
3. Retour du panier. Le demandeur remplit le panier et clique sur « retour » (ou « valider la commande »). Au lieu de suivre votre processus de commande, le panier retourne à son système d’achat sous forme de message structuré.
4. Approbation et commande. Le panier passe par l’approbation interne du client. Une fois approuvé, le bon de commande vous est envoyé et vous le traitez comme toute autre commande.

Pour le client, votre boutique fait partie de son processus d’achat : il voit vos prix et stocks en temps réel et chaque commande suit ses règles. Pour vous, les commandes arrivent avec le numéro de bon de commande du client, sans saisie de données de part et d’autre.

PunchOut ou catalogue statique

Certains clients demandent aussi aux fournisseurs un fichier de catalogue statique (souvent un fichier CIF ou un index cXML) chargé dans leur système. Les deux modèles sont complémentaires :

Si votre assortiment est limité et stable, un fichier peut suffire. Si vous vendez des milliers de produits, des articles configurables ou à des prix propres à chaque client, les clients préfèrent généralement PunchOut.

Les deux protocoles : cXML et OCI

Chaque session PunchOut utilise l’un de deux protocoles, selon le système de votre client. cXML (Commerce eXtensible Markup Language) échange des documents XML via HTTPS et est utilisé par SAP Ariba, Coupa, Jaggaer, Ivalua, Oracle, Workday et la plupart des systèmes source-to-pay. Il transporte également le bon de commande, sous forme d’OrderRequest. OCI (Open Catalog Interface) est le protocole SAP utilisé par SAP S/4HANA, SRM et ECC : votre boutique s’ouvre avec un HOOK_URL et le panier retourne sous forme de champs de formulaire HTML nommés NEW_ITEM-*. Le bon de commande vous parvient ensuite par un canal distinct.

Notre guide cXML ou OCI compare les deux, message par message, avec des exemples.

Pourquoi les clients demandent PunchOut

Pour le client, PunchOut résout trois problèmes à la fois. D’abord, le contrôle : chaque achat commence dans son système d’achat et suit ses règles d’approbation, budgets et fournisseurs privilégiés. Ensuite, la précision : prix, codes produit et descriptions proviennent de votre boutique, sans ressaisie, et les factures correspondent aux commandes. Enfin, la simplicité pour les personnes qui achètent : elles utilisent une vraie boutique, avec recherche, filtres et configurations, plutôt qu’une liste statique.

Pour un fournisseur, la demande arrive généralement avec une échéance : nouveau contrat, accord-cadre ou appel d’offres mentionnant PunchOut parmi ses exigences. Les fournisseurs qui répondent rapidement conservent le client ; ceux qui ne le peuvent pas sont souvent remplacés par un concurrent qui le peut.

Qui intervient

Un projet PunchOut implique plusieurs personnes de chaque côté. Les identifier tôt fait gagner des semaines :

PunchOut de niveau 1 et de niveau 2

Vous pouvez rencontrer deux niveaux de PunchOut. Le niveau 1 ouvre la page d’accueil de votre boutique : le client y recherche et parcourt les produits. Le niveau 2 permet au client de rechercher dans son propre système d’achat, où un index succinct de vos produits est chargé, puis ouvre votre boutique directement sur le produit ou la catégorie choisi. Le niveau 2 nécessite un fichier d’index statique en plus de la boutique en temps réel : demandez au client lequel il attend ; la plupart commencent par le niveau 1.

Quels systèmes d’achat utilisent PunchOut

Pratiquement tous. SAP Ariba est la demande la plus fréquente que nous recevons des fournisseurs, suivi de SAP via OCI et de Coupa. Jaggaer, Ivalua, GEP SMART, Oracle, Workday et des dizaines d’outils procure-to-pay pour entreprises de taille intermédiaire prennent aussi en charge PunchOut. Consultez la liste complète des systèmes compatibles.

Ce que votre client vous demandera

Le service achats de votre client envoie généralement une documentation fournisseur ou un email d’intégration. Lisez-le d’abord : il énumère précisément ses attentes. On vous demandera ou fournira généralement :

• Des identifiants : pour cXML, des identités (pour SAP Ariba, l’Ariba Network ID ou ANID des deux entreprises) et un shared secret ; pour OCI, les paramètres de connexion de votre catalogue.
• Des URL : l’URL de configuration exposée de votre côté et l’URL de retour (cXML) ou le HOOK_URL (OCI) de son côté.
• Des règles de catalogue : les produits et prix visibles pour ce client, les unités de mesure et un standard de classification (UNSPSC ou ECLASS) à un niveau donné.
• Un plan de test : un environnement de test et les dates de recette utilisateur (UAT).
• Des documents, pour les appels d’offres et grands clients : informations de sécurité et d’hébergement, accord de traitement des données, références.

Les réponses varient selon le système ; nos pages SAP Ariba, SAP OCI et Coupa les détaillent.

Ce qui change dans votre boutique

PunchOut demande à une boutique des fonctions que les internautes habituels n’utilisent jamais. Voici les blocages courants :

• L’ouverture dans un autre site. De nombreux systèmes d’achat affichent votre boutique dans une frame ou une nouvelle fenêtre qu’ils contrôlent. Les en-têtes de sécurité comme X-Frame-Options et les cookies sans SameSite=None; Secure interrompent la session. Consultez le guide sur l’erreur d’iframe.
• La connexion du bon client, pour qu’il voie son assortiment et ses prix contractuels, sans mot de passe.
• Le retour du panier au lieu de votre processus de commande, dans le format attendu par le système du client.
• Les données produit : unités de mesure associées aux codes du client et code de classification sur chaque produit. Consultez les catégories PunchOut.
• La réception de la commande : importation du bon de commande approuvé dans votre boutique.

Un plugin et une passerelle PunchOut gèrent ces points de manière standard, pour que votre boutique, votre thème et votre processus de commande existants continuent à fonctionner pour vos autres clients.

Un plan réaliste de 30 jours

La configuration technique d’une connexion PunchOut sur une plateforme compatible prend quelques heures, pas des semaines. Ce qui prend du temps, c’est la coordination avec le client. Un plan type :

La file d’attente des tests du client détermine la date finale : certains services achats programment la recette UAT plusieurs semaines à l’avance. Demandez les dates tôt et, si l’échéance est proche, envisagez de confier la configuration à des spécialistes, par exemple avec notre service Go-Live Assist.

Combien coûte PunchOut

Il existe trois façons courantes de répondre à une demande PunchOut, avec des coûts très différents :

• Un projet d’intégration sur mesure réalisé par un développeur ou une agence pour votre boutique. Vous payez le développement et les tests pour chaque protocole et client, puis la maintenance lorsque votre plateforme ou le système du client évolue.
• Un service facturé par client, généralement une mensualité pour chaque client connecté, plus des frais de configuration. Économique pour un client, coûteux à mesure que vous en ajoutez.
• Un plugin avec une passerelle gérée comme PunchOut Rocket : un prix annuel fixe par site. PunchOut Rocket coûte 1 950 € par an pour WooCommerce et 2 950 € pour Magento, PrestaShop, nopCommerce ou la REST API, avec jusqu’à 10 clients inclus.

Consultez les tarifs pour la grille complète et un calculateur comparatif.

Liste de contrôle avant les tests du client

• Les identifiants et URL de l’environnement de test sont configurés et une session de test fonctionne de bout en bout.
• Le client ne voit que les produits et prix convenus au contrat.
• Chaque produit de l’assortiment du client possède le code de classification et l’unité de mesure qu’il exige.
• Un panier retourné contient vos codes produit, prix, quantités et devise comme attendu par le client.
• Vous savez comment le bon de commande vous parviendra (cXML OrderRequest ou un autre canal convenu avec le client) et qui le traite.
• Vous avez un contact dans l’équipe du client pour le jour des tests, et le client a le vôtre.

Pièges courants

• Commencer par la boutique avant de lire la documentation fournisseur du client : elle contient souvent des règles de champs qui modifient la configuration.
• Tester uniquement sur le système de production du client : demandez toujours d’abord l’environnement de test.
• Oublier les unités de mesure et la classification : les paniers sont rejetés lorsque les codes ne correspondent pas à ceux du client.
• Sous-estimer le calendrier du client : les créneaux UAT peuvent être à plusieurs semaines. Réservez-les dès que vous avez les identifiants.
• Promettre des confirmations de commande, avis d’expédition ou factures via cXML sans la bonne option : les confirmations et avis nécessitent l’option OC & ASN ; les factures font l’objet d’un devis sur demande.