OCI vs cXML : quel standard punchout convient à votre système ?

Vous disposez d'une boutique fournisseur qui doit se connecter par punchout à votre SAP, Ariba ou Coupa – et vous vous posez la question : OCI ou cXML ? La décision semble techniquement triviale, mais elle a des conséquences directes sur l'effort d'intégration, la charge de maintenance et la question de savoir quels fournisseurs vous pourrez raccorder plus tard sans friction. En bref : les deux standards produisent le même résultat final – un panier est constitué dans la boutique du fournisseur et renvoyé vers votre système de commande. Les chemins pour y parvenir et les implications pour votre informatique diffèrent toutefois nettement. Cet article situe techniquement les deux protocoles, montre les pièges issus de projets d'intégration réels et donne une recommandation claire par plateforme.

Qu'est-ce que le punchout ? Bref aperçu

Par punchout (aussi punch-out, appel OCI ou catalogue PunchOut), on entend un pont technique entre un système de commande (eProcurement, SRM, ERP) et la boutique en ligne d'un fournisseur. L'utilisateur démarre la commande dans son outil de commande habituel, est transféré vers la boutique du fournisseur avec authentification automatique (« punched out »), y sélectionne des articles et renvoie le panier vers le système de commande sous forme de paquet de données via un protocole défini. L'avantage par rapport aux catalogues statiques : les prix, les disponibilités et les options de configuration sont toujours à jour, car ils proviennent en direct du système du fournisseur.

Deux standards se sont imposés pour cet aller-retour : l'OCI (Open Catalog Interface), développé par SAP, et le cXML (commerce eXtensible Markup Language), issu de la maison Ariba. Tous deux existent depuis la fin des années 1990, tous deux sont encore activement utilisés aujourd'hui – et tous deux appartiennent désormais au groupe SAP, depuis le rachat d'Ariba par SAP en 2012 (Wikipedia: cXML). Ils ne convergent pourtant pas ; ils restent fondamentalement différents sur le plan technique.

OCI en détail (Open Catalog Interface)

OCI est une spécification que SAP a initialement publiée pour SAP Business-to-Business Procurement, puis pour SAP SRM. Elle est déclarée « Open », au sens de librement documentée et implémentable – la spécification est maintenue par SAP et disponible en téléchargement sur les portails d'aide SAP (Wikipedia: Open Catalog Interface). Outre les produits SAP, OCI est également pris en charge par Microsoft Dynamics AX et par une série de suites procurement européennes.

Fonctionnement de l'aller-retour OCI

L'appel OCI se déroule comme une soumission de formulaire HTTPS classique. Le système de commande ouvre dans le navigateur de l'utilisateur une session vers l'URL d'entrée OCI du fournisseur et transmet à cette occasion des paramètres tels que USERNAME, PASSWORD, HOOK_URL ainsi que, fréquemment, ~OkCode, ~Caller et des champs spécifiques au client (p. ex. centre de coûts, numéro de commande, langue). La boutique du fournisseur vérifie les identifiants, établit la session et mémorise la HOOK_URL – c'est l'adresse à laquelle le panier sera renvoyé plus tard.

Une fois que l'acheteur a fini de configurer son panier, la boutique déclenche un POST de formulaire HTML vers la HOOK_URL. Les données utiles ne sont pas une structure XML, mais une liste plate de champs de formulaire HTML, indexés par position : NEW_ITEM-DESCRIPTION[1], NEW_ITEM-QUANTITY[1], NEW_ITEM-UNIT[1], NEW_ITEM-PRICE[1], NEW_ITEM-CURRENCY[1], NEW_ITEM-VENDORMAT[1] et ainsi de suite. Chaque position reçoit son propre index. Cela a deux conséquences : premièrement, l'implémentation côté boutique est on ne peut plus simple – on construit un formulaire HTML, on l'envoie, c'est terminé. Deuxièmement, un aller-retour OCI ne peut avoir lieu que dans un contexte de navigateur actif, car il dépend de la soumission du formulaire.

Versions OCI : 3.0, 4.0, 5.0

Dans la pratique, vous rencontrez aujourd'hui trois versions en exploitation productive. OCI 4.0 reste la version la plus répandue et est prise en charge par pratiquement toutes les boutiques fournisseurs desservant le marché B2B allemand. Elle couvre les champs classiques autour de NEW_ITEM-*. OCI 5.0 étend la spécification avec des champs structurés pour les données de configuration, les pièces jointes, les échéanciers de livraison et les références contractuelles détaillées – pertinent surtout là où des produits configurables complexes (p. ex. pièces de machines, bundles informatiques) sont commandés. Les installations SAP SRM plus anciennes parlent souvent encore OCI 3.0 ; ses fonctionnalités sont réduites, mais il est rétrocompatible.

Authentification dans OCI

Dans sa forme standard, OCI ne définit aucune authentification cryptographique. USERNAME et PASSWORD sont transmis comme champs POST HTTPS et vérifiés par la boutique. Dans la pratique, les prestataires sérieux complètent cela par des protections supplémentaires : liste blanche d'adresses IP des serveurs du système de commande, jetons HOOK_URL signés, durées de session courtes et, dans certaines installations, certificats clients. Quiconque introduit OCI aujourd'hui devrait au minimum exiger TLS 1.2 ou supérieur et protéger la HOOK_URL contre les attaques par rejeu en la liant à un nonce signé.

cXML en détail (commerce eXtensible Markup Language)

cXML a été publié par Ariba en 1999 et est hébergé chez SAP depuis le rachat en 2012 ; la spécification continue d'être maintenue de manière ouverte sur cxml.org. La version DTD actuelle est la 1.2.069, mise à jour pour la dernière fois en février 2026 (cxml.org). Le standard couvre bien plus que le seul punchout : le transfert de catalogues, les commandes, les confirmations de commande, les avis d'expédition et les factures sont également définis comme types de documents.

Fonctionnement de l'aller-retour PunchOut cXML

Le punchout cXML se déroule en deux étapes et utilise du XML au lieu de champs de formulaire HTML. Le système de commande envoie d'abord par HTTPS POST un PunchOutSetupRequest directement – sans navigateur intermédiaire – à l'endpoint de la boutique du fournisseur. Ce message XML contient une section d'en-tête avec des éléments From, To et Sender (chacun avec des entrées Identity et Credential), ainsi qu'un corps de requête avec un BuyerCookie, qui marque le contexte de session, et une URL BrowserFormPost – l'équivalent cXML de la HOOK_URL d'OCI.

La boutique répond de manière synchrone avec un PunchOutSetupResponse qui fournit entre autres une URL StartPage. L'utilisateur reçoit cette URL sous forme de redirection ; il navigue alors réellement dans la boutique et configure son panier. À la finalisation, la boutique envoie un PunchOutOrderMessage sous forme de document XML par HTTPS POST vers l'URL BrowserFormPost. Contrairement à OCI, les positions sont des éléments XML structurés (ItemIn avec ItemID, ItemDetail, UnitOfMeasure, UnitPrice, etc.) – modélisées plus richement, mais aussi plus coûteuses à générer et à analyser.

Authentification dans cXML

cXML mise sur des shared secrets dans l'en-tête XML. Dans les éléments Credential, Identity et SharedSecret sont transmis en clair – protégés uniquement par le chiffrement de transport HTTPS. Cette méthode est robuste, car le secret n'atterrit jamais dans le contexte du navigateur (contrairement aux identifiants OCI, qui peuvent devenir visibles dans le formulaire HTML). Dans les constellations Ariba, cela est souvent complété par des requêtes Profile, avec lesquelles la boutique du fournisseur et le système de commande négocient leurs capacités lors du premier contact. En option, cXML prend également en charge les certificats clients X.509.

Comparaison directe : OCI vs cXML

Le tableau suivant résume les différences les plus importantes. Il ne remplace pas une spécification technique, mais il aide à une première évaluation en amont d'un projet d'intégration.

Quel standard convient à votre système ?

La réponse dépend en premier lieu de votre plateforme procurement, et non des mérites théoriques du protocole. Quiconque travaille dans un paysage hybride devrait en outre veiller à ce que le fournisseur choisi propose les deux standards – sinon, le prochain changement de plateforme coûtera cher.

SAP ERP / SAP S/4HANA avec SRM classique

Les installations SAP SRM classiques parlent nativement OCI 4.0. Si vous n'avez pas besoin de cXML ici pour d'autres raisons, OCI est le choix tranquille : simple à configurer, directement pris en charge par le standard SAP, pratiquement toujours proposé par le fournisseur. Sur les systèmes SRM 7.0, prêtez attention aux tables de customizing OCI WS_PUNCHOUT et assurez le test de connexion via la transaction SE38.

SAP Ariba

Ariba est la patrie naturelle de cXML. Les fournisseurs qui se raccordent à Ariba Network doivent obligatoirement implémenter cXML – OCI n'est pas ici le format d'intégration principal. Pour les acheteurs purement Ariba, il n'y a donc aucun sens à exiger OCI simplement parce qu'on le connaît. Pour les fournisseurs, en revanche, il est tout à fait recommandé de proposer les deux standards, car de nombreux clients Ariba utilisent en parallèle SAP SRM ou des systèmes tiers.

Coupa

Coupa mise principalement sur cXML et s'aligne étroitement, à cet égard, sur le modèle Ariba. OCI est pris en charge, mais secondaire. Une PME allemande qui introduit Coupa devrait exiger du fournisseur cXML dans la version DTD actuelle et tester au préalable les endpoints PunchOutSetupRequest.

JAGGAER, Onventis, Wallmedien (POOL4TOOL/SCConnect)

Les suites procurement répandues dans la région DACH prennent typiquement en charge les deux standards. JAGGAER et Onventis sont fortement représentés dans les PME allemandes et sont, dans la pratique, majoritairement raccordés par OCI – tout simplement parce que l'écosystème des fournisseurs y parle traditionnellement OCI. Si vous introduisez l'une de ces plateformes, demandez à l'éditeur une liste de références de boutiques raccordées pour les deux standards et décidez sur la base de cette liste.

Microsoft Dynamics 365 / Dynamics AX

Dynamics AX prenait nativement en charge OCI (Wikipedia: OCI) ; le produit successeur Dynamics 365 exige typiquement un middleware ou un add-on procurement. Dans cette constellation, le punchout est généralement réalisé via un connecteur qui parle OCI ou cXML vis-à-vis du fournisseur. Vérifiez d'abord quel format le connecteur produit nativement avant d'imposer des exigences au fournisseur.

Obstacles d'intégration typiques dans la pratique

Indépendamment du standard, les mêmes problèmes reviennent sans cesse dans les projets punchout. Les connaître fait gagner des semaines.

Certificats SSL/TLS et chaînes de confiance

OCI comme cXML fonctionnent exclusivement via HTTPS. Cela n'est trivial que jusqu'à ce que le système de commande se trouve derrière une vieille pile Java ou un truststore personnalisé. Symptômes : SSLHandshakeException, PKIX path building failed. Vérifiez tôt si le certificat racine de l'endpoint du fournisseur (souvent Let's Encrypt, DigiCert, GlobalSign) est présent dans le truststore de votre serveur procurement. Avec SAP SRM, cela concerne la configuration STRUST.

Liste blanche IP dans les deux sens

De nombreux fournisseurs exigent que les IP du système de commande soient mises en liste blanche. Inversement, la boutique du fournisseur se trouve parfois derrière un WAF qui bloque les rappels HOOK_URL. Clarifiez avant le go-live, dans un document réseau, quelles adresses doivent être accessibles dans quel sens – et si votre HOOK_URL est seulement accessible depuis Internet, au cas où la boutique doit renvoyer directement. Avec les systèmes de commande on-premises, ce n'est souvent pas le cas.

Timeouts de session et durée de vie de la HOOK_URL

Une HOOK_URL ou URL BrowserFormPost n'est typiquement valable que 30 à 60 minutes. Quiconque flâne plus longtemps dans la boutique du fournisseur – par exemple parce qu'il doit clarifier une situation particulière – reçoit une erreur à l'envoi. La boutique du fournisseur devrait donc afficher visiblement la fenêtre de session restante ou interrompre proprement la session au timeout d'inactivité, au lieu de renvoyer des erreurs 500 muettes.

Problèmes d'encodage lors de l'aller-retour

Le classique numéro un : les trémas et caractères spéciaux arrivent dans le système de commande sous forme de ? ou d'octets corrompus. La cause est presque toujours un décalage d'encodage lors de la soumission du formulaire (OCI) ou lors de la génération XML (cXML, déclaration encoding="UTF-8" manquante). Testez explicitement des articles avec trémas, eszett et une paire trait d'union/tiret cadratin. Qui n'y prête pas attention se retrouvera plus tard avec des désignations de produits erronées dans la commande – et, dans le pire des cas, dans la facture.

Taux de taxe, devise et UoM

OCI 4.0 n'a pas de champ dédié au taux de taxe. Certains systèmes de commande attendent le prix brut, d'autres le prix net. cXML est plus explicite ici, mais les implémentations divergent là aussi. Définissez lors de l'atelier d'intégration : quelle base de prix (net/brut) ? Quelle devise ? Quels codes UoM (UN/ECE Recommendation 20) ? Un seul code UoM erroné dans la boutique du fournisseur se traduit en aval par des comptabilisations erronées.

Mandants multiples et logique Ship-To

Quiconque possède plusieurs sites ou sociétés doit indiquer à la boutique du fournisseur à quelle adresse de livraison le panier s'applique. OCI le fait généralement via un champ personnalisé introduit par le client ; cXML connaît dans le PunchOutSetupRequest des éléments ShipTo dédiés. Qui néglige cela reçoit des commandes sans affectation de site.

Comment évaluer les fournisseurs qui proposent les deux standards

Si un fournisseur – comme un distributeur technique spécialisé en équipement d'entrepôt – prend en charge OCI et cXML, vous ne devriez pas cocher cela comme une simple case dans l'évaluation des fournisseurs. Vérifiez concrètement :

• Quelle version OCI est renvoyée ? 4.0 est le standard, 5.0 est pertinent si vous achetez des articles configurables avec une structure d'options.
• Quelle version de DTD cXML ? La spécification actuelle est la 1.2.069 (cxml.org) ; des versions nettement plus anciennes (p. ex. 1.2.014) peuvent fonctionner, mais il leur manque des champs plus récents.
• Les champs personnalisés sont-ils pris en charge ? Centre de coûts, numéro de commande interne, identifiant de projet – ces champs doivent revenir proprement à travers l'aller-retour.
• Comment la session est-elle sécurisée ? Demandez la signature des jetons, la durée de vie de la HOOK_URL et les options de liste blanche IP.
• À quoi ressemblent le mode test et le mode sandbox ? Un fournisseur sérieux met à disposition un endpoint de test qui permet de véritables allers-retours sans que de vraies commandes soient générées à la fin.
• Que se passe-t-il lors d'un changement de version ? Qui migre quand vers une nouvelle version OCI ou cXML ? Y a-t-il des délais de préavis ?

Un bon fournisseur a une réponse écrite à chacun de ces points. Qui esquive risque de vous voir plus tard lutter, dans le projet d'intégration, avec des implémentations bâclées.

Questions fréquentes

Ai-je besoin des deux standards si j'ai plusieurs systèmes procurement ?

Si vous travaillez avec un SAP SRM de groupe et des filiales de taille moyenne sous Onventis, vous devriez exiger les deux standards du fournisseur – le surcoût côté fournisseur est raisonnable, le bénéfice pour vous est grand. Si vous n'utilisez qu'un seul système, le format adapté suffit.

cXML est-il « meilleur » qu'OCI parce que plus récent et plus riche en données ?

Pas de manière générale. cXML est plus riche en données et proprement structuré en XML, ce qui apporte des avantages dans les cas complexes. OCI, en revanche, est plus simple à implémenter, plus résistant aux erreurs dans l'aller-retour navigateur et plus fréquent en Allemagne. Pour 80 % des commandes d'équipement d'entrepôt, OCI 4.0 suffit amplement.

Quel est le rapport avec BMEcat ?

BMEcat est un format de catalogue statique pour l'échange basé sur XML de catalogues de produits entiers entre fournisseurs et systèmes de commande. Il résout un autre problème que le punchout : avec BMEcat, un catalogue est importé une fois ; avec le punchout, on démarre en direct dans la boutique du fournisseur. De nombreuses entreprises combinent les deux – BMEcat pour l'assortiment de base, le punchout pour la longue traîne et les produits configurables.

Quelle est la sécurité du nom d'utilisateur/mot de passe en clair dans OCI ?

Tant que la connexion passe par TLS 1.2 ou supérieur, les identifiants sont chiffrés pendant le transport. Le risque se situe plutôt dans la journalisation du navigateur et dans la visibilité du code source du formulaire HTML. Qui veut éviter cela utilise en plus une liste blanche IP et remplace le mot de passe initial par un jeton de session court et signé.

Combien coûte typiquement un projet d'intégration punchout ?

Côté fournisseur, quelques jours-homme suffisent pour le raccordement OCI dans une boutique moderne ; cXML nécessite plutôt 5 à 15 jours, car il faut en plus construire l'endpoint de setup et le générateur XML. Côté acheteur s'ajoutent la configuration dans SRM/Coupa/Ariba (typiquement 1 à 3 jours), les tests avec validation de l'aller-retour et la formation des utilisateurs. Des chiffres fiables ne peuvent toutefois être donnés qu'après un scoping concret.

Et si mon fournisseur ne propose pas de punchout ?

Il reste alors trois alternatives : l'import de catalogue BMEcat, la commande manuelle via le portail du fournisseur avec ressaisie ultérieure, ou le raccordement via une plateforme de place de marché (Mercateo/Unite, Wucato, Conrad B2B) qui, de son côté, parle punchout avec le système de commande. Cette dernière option est souvent la voie la plus pragmatique lorsqu'un seul fournisseur manque.

Conclusion

OCI et cXML résolvent le même problème avec deux philosophies très différentes : OCI est léger, centré sur le navigateur et de fait omniprésent en Allemagne ; cXML est riche en données, orienté système à système et obligatoire dès qu'Ariba entre en jeu. Qui exploite SAP SRM ou des suites procurement classiques de la région DACH s'en sort sans discussion avec OCI 4.0. Qui évolue dans un monde Ariba ou Coupa ne peut pas contourner cXML. Les fournisseurs qui maîtrisent les deux standards vous facilitent la vie à long terme – vérifiez-le lors de l'évaluation plutôt que seulement à l'atelier d'intégration. Et, indépendamment du standard, prévoyez du temps pour les points invisibles : truststores TLS, encodage, durée de vie des sessions. C'est exactement là que naissent 80 % des retards dans un déploiement punchout.