Un catalogue « punchout » est une connexion en temps réel entre votre boutique en ligne et le système d’approvisionnement d’un acheteur, tel que Coupa ou SAP Ariba, qui permet à ce dernier de faire ses achats sur votre site depuis son propre logiciel et de valider une commande sans quitter son processus de validation. Cette connexion s’appuie sur un protocole, généralement le cXML, qui permet l’échange de documents spécifiques selon un ordre prédéfini. Il ne s’agit pas d’une fonctionnalité marketing, mais d’une exigence de conformité imposée par la politique d’approvisionnement de votre acheteur.
Les distributeurs et les fabricants qui vendent à de grands comptes sont confrontés à ce problème dès lors que l’équipe d’approvisionnement d’un client impose que tous les achats soient effectués via un système tel que Coupa, SAP Ariba ou Jaggaer. Nous observons ce phénomène en permanence dans le commerce électronique industriel, où le responsable des achats de maintenance d’une usine n’a pas l’autorisation de passer une commande en dehors de la plateforme d’approvisionnement agréée, quelle que soit la qualité de votre vitrine en ligne. Si cet acheteur ne peut pas effectuer de « punch-out » vers vous, il ne peut pas s’approvisionner chez vous, quels que soient le prix ou la relation commerciale.
La plupart des explications concernant les catalogues « punchout » se limitent à évoquer « une connexion sécurisée entre deux systèmes ». Cela ne donne aucune indication au directeur informatique sur la nature du document qui arrive sur son serveur, sur son contenu, ni sur ce qui doit être renvoyé en quelques secondes. Cet article répertorie tous les documents impliqués dans l’échange, compare les exigences réelles de Coupa, SAP Ariba, Jaggaer et Oracle Procurement Cloud avant qu’ils n’approuvent votre demande, et fournit des fourchettes de coûts et de délais réels afin que vous puissiez budgétiser correctement le projet dès le départ.
Un catalogue « punchout » est une session en temps réel nécessitant une authentification, et non un simple fichier. Contrairement au téléchargement d’un catalogue hébergé, où vous envoyez une liste de prix statique une fois par trimestre, le « punchout » ouvre la vitrine de votre boutique au sein d’un cadre contrôlé par le système d’approvisionnement de l’acheteur, affichant ainsi votre stock en temps réel et les tarifs contractuels négociés au moment même où l’acheteur effectue ses achats.
La demande émane rarement de votre équipe commerciale. Elle provient du service des achats ou du service informatique de l’acheteur, généralement comme condition pour rester un fournisseur agréé. Les grands industriels, les réseaux hospitaliers, les universités et les administrations publiques s’appuient sur un nombre restreint de plateformes d’approvisionnement et exigent de chaque fournisseur dépassant un certain seuil de dépenses qu’il prenne en charge le « punchout » vers cette plateforme. Si l’équipe chargée des comptes fournisseurs de votre client est passée à la vérification tripartite par rapport à un bon de commande, le « punchout » est très souvent le mécanisme qui permet à vos produits d’apparaître dans ce bon de commande.
Cela a une incidence sur la budgétisation : vous ne décidez pas de créer ou non un catalogue « punchout » en fonction de votre propre feuille de route. Vous le créez parce qu’un client spécifique l’exige, et ce sont les services achats de ce client, et non votre équipe produit, qui définissent les exigences techniques.
Une session de catalogue « punchout » suit une séquence fixe de documents nommés. Voici les 9 étapes de cette séquence, en prenant comme exemple Coupa comme plateforme acheteuse et cXML comme protocole, car il s'agit de la combinaison à laquelle la plupart des fournisseurs sont confrontés en premier lieu.
Il y a dix ans, la plupart de ces opérations reposaient sur des transferts de fichiers et des rapprochements manuels. Aujourd’hui, l’ensemble du processus, du clic à la commande, peut être effectué en moins d’une minute, à condition que votre terminal réponde suffisamment vite et que votre session ne soit pas interrompue par un délai d’attente trop long lors de la recherche des prix.
Deux protocoles couvrent la quasi-totalité des demandes de « punchout » que vous recevrez. Le protocole cXML punchout, géré par cxml.org et initialement développé pour Ariba, est à l’origine des documents PunchOutSetupRequest, PunchOutOrderMessage et PurchaseOrderRequest décrits ci-dessus. SAP Ariba, Coupa et Jaggaer utilisent tous le protocole cXML punchout comme protocole principal ou par défaut ; c’est donc celui que votre équipe de développement doit privilégier dans ses prévisions.
L'interface Open Catalog Interface (OCI) est l'autre protocole que vous rencontrerez, principalement chez les acheteurs utilisant le module d'approvisionnement natif de SAP ou d'anciennes installations SAP SRM. L'OCI est plus simple et plus ancienne que le protocole cXML Punchout. Elle fonctionne via une requête HTTP POST basée sur des formulaires plutôt que sur un échange de documents XML structurés, et renvoie généralement moins de champs par ligne de commande, ce qui limite la quantité de détails contractuels que le système de l'acheteur capture automatiquement.
Si votre plateforme de commerce en ligne est Adobe Commerce ou Magento Open Source, sachez qu’aucune des deux ne prend en charge nativement le punchout cXML ni l’OCI. Vous aurez besoin d’une extension dédiée ou d’une couche intermédiaire (middleware) telle que PunchOut2Go pour gérer l’établissement de la session et convertir les données du panier au format de document approprié. BigCommerce B2B Edition et Shopify Plus se trouvent dans la même situation : les deux nécessitent un middleware, généralement PunchOut2Go ou Alumio, car le punchout ne fait pas partie du moteur de commerce de base de ces deux plateformes.
Le système d’approvisionnement de chaque acheteur envoie les trois mêmes documents, bien que les champs spécifiques qu’ils contiennent varient selon la plateforme. La requête « PunchOutSetupRequest » arrive en premier et contient les identifiants d’authentification, l’identité de l’acheteur, l’agent utilisateur du navigateur et l’URL de retour. Votre point de terminaison doit valider le secret partagé et répondre dans le délai imposé par le système de l’acheteur, souvent compris entre cinq et dix secondes (selon votre fournisseur), faute de quoi la session échoue avant même que l’acheteur ne puisse accéder à votre boutique en ligne.
Une fois que l'acheteur a constitué son panier, votre système renvoie un « PunchOutOrderMessage ». Ce document doit contenir des références de pièces, des quantités, des unités de mesure et des prix exacts, conformes aux spécifications du contrat de l'acheteur, car le système d'approvisionnement de ce dernier rejettera ou signalera souvent toute divergence lors de la validation. Enfin, la « PurchaseOrderRequest » qui arrive après validation interne constitue une commande ferme que votre système de gestion des commandes doit intégrer automatiquement, car une ressaisie manuelle à ce stade irait à l’encontre de l’objectif même de l’intégration.
Coupa Punchout, SAP Ariba et Jaggaer gèrent chacun leur propre processus d’activation des fournisseurs, et aucun des trois ne vous permettra de passer en production sans l’avoir mené à bien. Coupa Punchout exige une inscription via le portail fournisseurs Coupa, un numéro DUNS et un environnement de test validé avant que les identifiants de production ne soient délivrés. SAP Ariba nécessite un compte Ariba Network doté de son propre identifiant AN, et la mise en service passe généralement par l’équipe de mise en service des fournisseurs d’Ariba plutôt que par l’acheteur directement. Jaggaer suit un schéma similaire via son propre portail fournisseurs, avec généralement un délai de mise en service plus court que celui de SAP Ariba.
| Plateforme d'approvisionnement | Protocole pris en charge | Ce que cela implique pour le fournisseur | Délai de mise en service habituel |
| Coupa | Punchout cXML | Inscription au portail fournisseurs Coupa, numéro DUNS, session de test validée | 4 à 8 semaines |
| SAP Ariba | Punchout cXML ou OCI | Compte Ariba Network (AN ID), identifiants de test et de production | 4 à 8 semaines |
| Jaggaer | Punchout cXML ou OCI | Inscription au portail fournisseurs Jaggaer, validation de la session de test | 3 à 6 semaines |
| Oracle Procurement Cloud | Punchout cXML ou OCI | Enregistrement des fournisseurs, tests des points de terminaison avec l'équipe d'intégration d'Oracle | 4 à 8 semaines |
Aucun de ces délais ne commence avant que votre équipe de développement ne dispose d'un point de terminaison opérationnel sur lequel effectuer des tests. Prévoyez la période de mise en place en plus de votre délai de développement, et non pas pendant celui-ci.
Un catalogue « punchout » B2B échoue au test le plus élémentaire dès lors que le prix affiché dans la session ne correspond pas à celui prévu dans le contrat de l’acheteur. Les acheteurs négocient des tarifs spécifiques à chaque client, souvent au niveau de chaque article, et ces tarifs doivent être récupérés en temps réel depuis votre ERP au moment de l’ouverture de la session, et non pas dupliqués ou estimés dans la base de données de votre boutique en ligne.
C'est la partie d'un catalogue « punchout » B2B qui engendre réellement des coûts, car il s'agit d'un travail d'intégration et non d'une simple configuration commerciale. Si votre ERP est Epicor Prophet 21, les tarifs contractuels figurent dans des grilles tarifaires spécifiques à chaque client que votre session « punchout » doit interroger en temps réel ; nous expliquons en détail le fonctionnement de cette connexion dans notre guide d’intégration Epicor Prophet 21 et WooCommerce. NetSuite OneWorld présente un défi similaire pour les distributeurs disposant de plusieurs filiales, car les tarifs peuvent varier selon l’entité juridique ainsi que selon le client. Dans tous les cas, la vitrine en ligne ne peut pas être la source de référence en matière de prix.
Si vous n’avez qu’un seul acheteur utilisant le système « Punchout » et que le volume annuel des dépenses transitant par ce compte est inférieur à environ 250 000 dollars, ne créez pas de catalogue « Punchout » complet. Les coûts de développement et de maintenance continue justifient rarement le retour sur investissement à ce niveau de volume. Envoyez plutôt un fichier de catalogue hébergé, au format BMEcat, cXML ou CSV structuré, que le système d’approvisionnement de l’acheteur importe selon un calendrier défini, ou traitez les commandes via EDI 850 si l’acheteur prend déjà en charge ce protocole.
Le « punchout » de niveau 2 mérite d’être connu en tant qu’option intermédiaire. Au lieu de rediriger l’acheteur vers la page d’accueil de votre boutique en ligne, le « punchout » de niveau 2 utilise des liens profonds pour l’envoyer directement vers la page d’un produit spécifique, ce qui raccourcit la session et réduit la quantité de logique de catalogue que votre point de terminaison doit gérer. Il nécessite toujours les mêmes échanges de messages « PunchOutSetupRequest » et « PunchOutOrderMessage » ; il n’est donc pas gratuit, mais sa mise en place est moins lourde que celle d’une prise en charge complète du « punchout ». Nous expliquons plus en détail dans quel cas une expérience acheteur allégée est pertinente dans notre article consacré au portail de commerce électronique B2B, qui passe en revue l’ensemble des options disponibles entre un catalogue statique et une session « punchout » complète.
Un catalogue « punchout » qui a passé les tests avec succès ne fonctionne pas de lui-même. Cinq types de défaillances sont à l'origine de la plupart des tickets d'assistance que nous recevons après la mise en service :
Les achats initiés par des machines commencent à s'immiscer dans ce même domaine. Des frameworks émergents, tels que l'Agentic Commerce Protocol, permettent à des agents IA de faire des achats et de finaliser la commande au nom d'un acheteur, en utilisant une structure de session qui reprend le modèle « configuration, navigation et retour » utilisé depuis des années par le « punchout ». Nous ne prétendons pas que cela remplace le « punchout », mais constatons simplement que ce modèle d'interaction s'avère suffisamment pérenne pour une nouvelle génération d'acheteurs, qu'ils soient humains ou non.
Si un client spécifique vient de vous indiquer que son système d’approvisionnement nécessite un catalogue « punchout », commencez par déterminer deux éléments avant d’écrire la moindre ligne de code : quelle plateforme il utilise (Coupa, SAP Ariba, Jaggaer ou Oracle Procurement Cloud), et où se trouvent actuellement les tarifs contractuels pour cet acheteur. Ces deux réponses déterminent pratiquement tout le reste, du protocole à développer à la répartition entre les tâches liées au commerce et celles liées à l’intégration ERP dans le cadre du projet.
Nous menons cette démarche sous la forme d'une brève phase de découverte avec les nouveaux clients : un appel avec le responsable de l'accompagnement des acheteurs afin de confirmer la procédure et les identifiants d'accès, ainsi qu'un entretien distinct avec la personne en charge de vos données ERP pour vérifier que les tarifs peuvent être consultés en temps réel plutôt que d'être exportés manuellement.
Un catalogue « punchout » est une session en temps réel qui permet à un acheteur de faire ses achats sur votre boutique en ligne depuis son système d'approvisionnement, tel que Coupa ou SAP Ariba, et de valider son panier comme commande sans quitter son processus de validation.
Le coût dépend de votre système ERP, de l'architecture d'intégration, du volume de commandes et de la complexité des données. À titre indicatif, une intégration simple de type « point à point » peut coûter entre 15 000 et 35 000 dollars, tandis qu'une intégration basée sur un middleware peut varier entre 40 000 et 90 000 dollars. Des couches de services personnalisées plus complexes peuvent coûter entre 80 000 et 200 000 dollars, voire davantage. Pour établir un devis précis, il est nécessaire d'évaluer vos systèmes spécifiques, vos flux de données et vos besoins métier.
Non. Il s'agit dans les deux cas de protocoles destinés aux sessions « punchout », mais le « punchout » cXML utilise des documents XML structurés tels que « PunchOutSetupRequest » et « PunchOutOrderMessage », tandis que l'OCI repose sur une requête HTTP POST plus simple, basée sur un formulaire, avec moins de champs par ligne de commande.
Pas nécessairement. Si le montant annuel des achats effectués par cet acheteur est inférieur à environ 250 000 dollars, l'utilisation d'un fichier de catalogue hébergé ou le traitement des commandes via EDI 850 offre généralement un meilleur rapport effort/résultat que la mise en place d'une prise en charge complète du « punchout ».
Aucune des principales plateformes ne le fait. Adobe Commerce, Magento Open Source, BigCommerce B2B Edition et Shopify Plus nécessitent toutes une extension ou une couche intermédiaire, telle que Punchout2Go ou Alumio, pour gérer la session « punchout ».
