Accueil
 chercher             Plan du site             Info (English version) 
L'histoire de XML s'écrit en ce moment même. XMLfr vous aide à la suivre et à en dégager les tendances.Les listes de discussions XMLfr sont à votre disposition pour réagir sur nos articles ou simplement poser une question.Si vous ètes passionnée(e) par XML, pourquoi ne pas en faire votre métier ?XMLfr n'est heureusement pas le seul site où l'on parle de XML. Découvrez les autres grâce à XMLfr et à l'ODP.Les partenaires grâce auxquels XMLfr peut se développer.Pour tout savoir sur XMLfr.XMLfr sans fil, c'est possible !Pour ceux qui veulent vraiment en savoir plus sur XML.L'index du site.
 Si vous vous posez une question, vous n'êtes peut-être pas le premier...Les traductions en français des bibles XML.Ces articles sont des références dans leur domaine.Tout ce qu'il faut savoir pour démarrer sur un sujet XML...


Place de marché électronique, XML, EDI et BSR

XML et BSR pour l'intégration de l' EDI dans l'ensemble des échanges électroniques ou "de la place de marché à la supply chain enEDI".

Extrait de VendrEDI, la lettre mensuelle gratuite de Claude Chiaramonti, qui contribue au passage de l'EDI traditionnel (Edifact et RVA) à XML sur Internet. Pour s'abonner : courrier.vendredi@worldnet.fr
jeudi 21 décembre 2000

Sommaire

Introduction : Internet et EDI
1. Fonctions des places de marché et EDI
1.1. Many to many : l'outil du e-commerce
1.2. Many to one : le profil imposé par les grands comptes
1.3. One to one : l'EDI classique maintenu
1.4. One to many : le Web EDI en XML
2. Le contenu de l'EDI intégré en XML dans les places de marché
2.1. EDI et interopérabilité des places de marché
2.2. D'abord les pages jaunes du e-commerce
2.3. L'offre UDDI d'Ariba, Microsoft et IBM
2.4. Standardiser l'EDI en XML
Conclusion : XML et BSR pour intégrer l'EDI

Introduction : Internet et EDI

Après avoir représenté le must des échanges électroniques à la fin des années 80 et au début des années 90, l'EDI classique (Edifact et RVA) n'en finit plus d'être bousculé par l'innovation technologique. Autoroutes de l'information, Internet, XML et maintenant place de marché électronique (Electronic Market Place) permettent de resituer l'EDI à sa juste place : une fonction permanente qui va pouvoir jouer tout son rôle grâce à ces nouvelles technologies.

En effet, qu'est-ce que l'EDI (échange de données informatisé) : la mise à niveau automatique des systèmes d'information d'entreprises ayant des transactions régulières, par exemple commande de produits frais tous les matins. A partir du moment ou l'application de gestion des achats du supermarché commande automatiquement ses produits frais à l'application de gestion des ventes de chacun de ses fournisseurs, c'est de l'EDI !

Peu importe que cette commande soit contenue dans un message utilisant la syntaxe Edifact ou XML, peu importe que le message transite par un RVA en X400 ou par un Extranet en IP, peu importe que le supermarché ait choisi ses fournisseurs après enchères sur une place de marché électronique ou autrement, ce sera toujours de l'EDI !

La révolution d'Internet pour l'EDI, c'est que le commerce électronique et ses places de marché vont constituer le terreau privilégié sur lequel l'EDI continuera à fleurir grâce à l'engrais que constitue XML.

1.   Fonctions des places de marché et EDI

Le développement des places de marché électronique est foudroyant : bien sûr emmenées par les très grandes entreprises, les places de marché devraient néanmoins progressivement ne pas rebuter les PME qui se familiarisent avec les techniques d'Internet.

Plusieurs stratégies sont possibles. L'entreprise veut-elle devenir fournisseur d'un groupe ? Faire des achats stratégiques ? Alors, il faut chercher une place de marché "verticale", c'est-à-dire propre à un secteur de l'économie. Veut-elle gérer ses achats de fonctionnement ? L'entreprise se tournera vers les places de marché "horizontales" : leurs échanges portent sur des biens hors production comme les fournitures de bureau. Il y a aussi des places de marché fonctionnelles, par exemple sur la gestion des ressources humaines.

Une entreprise peut commencer par faire connaître une partie de son catalogue sans payer de frais d'adhésion en s'inscrivant un site communautaire B-to-B où le fournisseur n'est jamais en contact avec le client et où la place de marché se comporte comme une centrale d'achat. Ensuite l'e-entreprise peut payer une adhésion qui donne une ouverture directe au marché en louant une licence de gestion de catalogue et un ensemble de services marketing complémentaires. A partir de là, l'entreprise connecte son système à la place de marché. La bonne méthode consiste à connecter son PGI-ERP au système e-business en XML qui fera le relai avec l'e-marketplace.

En effet, ces différentes connexions se font de plus en plus en XML qui devient un outil d'intégration, non seulement des entreprises avec les places de marché, mais aussi des places de marché entre elles, quand elles le souhaitent.

1.1.   Many to many : l'outil du e-commerce

Une place de marché est une plate-forme "many to many" qui fédère et gère les transactions des entreprises. Les offreurs doivent réorganiser leurs catalogues et intégrer des contraintes propres à la place de marché, en particulier la rapidité de mise à jour du catalogue.

La place de marché est donc une foire où les clients ne sont plus isolés et peuvent avoir plus de pouvoir que les exposants. Dans le cadre d'appel d'offres, l'organisation d'enchères descendantes peut consacrer le pouvoir du marché, à savoir celui des acheteurs, groupés ou non. Mais une place de marché organisée par de petits fournisseurs peut tout autant les protéger contre leurs grands donneurs d'ordres et organiser des enchères classiques !

La place de marché prend en charge le routage des transactions et finit par exercer les fonctions qui étaient celles du RVA en EDI classique, horodatage, certification etc. Le succès d'une place de marché ne dépend pas seulement de cette organisation des transactions mais aussi de services complémentaires, comme la logistique, le groupage des acheteurs, la gestion des stocks et des invendus, le suivi des performances des fournisseurs etc.

Mais dès lors qu'il s'agit de transactions qui ont vocation à se répéter, par exemple si le produit acheté doit s'intégrer régulièrement dans la production du client, la 1ère transaction ne restera pas isolée et peut se transformer en relation stable. On ne peut en effet rechercher un partenaire tous les matins sous peine de désorganiser sa production ! Et autant automatiser en EDI des transactions répétitives dont on maîtrise les paramètres. En XML plutôt qu'en Edifact puisque XML est déjà le format d'échange avec la place de marché.

1.2.   Many to one : le profil imposé par les grands comptes

Dans l'EDI classique, dominé par les grands donneurs d'ordres qui y trouvent le plus d'intérêt pour des raisons d'échelle, ce sont les formats d'échange de ces donneurs d'ordres qui s'imposent à leurs partenaires dispersés. Même si des subsets de messages Edifact s'imposent à tous au sein de communautés EDI sectorielles, l'accord d'interchange mettant en œuvre ces subsets est bien celui dicté par chacun des grands comptes. Cette dictature de chacun des "one" du "many to one" est lourde pour les PME !

Il n'est pas sûr qu'il en soit de même systématiquement dans les places de marché : certes, les premières ont été bâties par des grands donneurs d'ordres ! Mais rien n'interdit à des fournisseurs d'en bâtir autour de produits complémentaires et de pratiquer des enchères montantes ! Et rien n'interdit alors à ce regroupement de petits de proposer leur DTD-schéma en XML à tous leurs clients, y compris les gros.

Sinon, la dictature subsistera : simplement les guides d'utilisation de subsets de messages Edifact seront remplacés par autant de DTD-schémas propres à chaque grand compte. En espérant qu'avec XML, le mapping avec leurs applications sera un peu moins pénible pour les PME !

En tout cas, les places de marché électroniques propres à une seule grande entreprise ne pourront rester isolées longtemps et leur interopérabilité sera un facteur puissant d'harmonisation des échanges les concernant : l'EDI pour les mise à jour des catalogues et les transactions commerciales répétitives finira par être "gagnant-gagnant" comme le voulait la théorie de l'EDI classique.

 1.3.  One to one : l'EDI classique maintenu

L'EDI, c'est la transmission automatisée, d'application à application, de messages structurés suivant un vocabulaire métier et des formats convenus à l'avance. Mais cela ne vaut la peine de se mettre d'accord sur cette structuration que si l'on prévoit que les messages à échanger seront suffisamment répétitifs.

L'EDI est d'autant plus efficace qu'il a été préparé par une modélisation, une analyse du processus métier et de ses étapes permettant d'identifier les données à transmettre à l'occasion de chaque flux de données. L'EDI est d'autant plus rentable qu'il est d'abord considéré dans ses aspects organisationnels : recevoir automatiquement des commandes, c'est bien, surtout si elles sont immédiatement répercutées sur tous les services ayant à en connaître !

Autrement dit, l'EDI c'est d'abord de l'organisation avec l'analyse de flux qui s'en déduit, pas de la technique : peut importe la syntaxe de l'échange, Edifact ou XML, l'important ce sont les données et leur traitement.

En Edifact, l'EDI est un peu marginalisé dans le système d'information de l'entreprise par le recours à un traducteur spécialisé : avec XML, le parseur fourni gratuitement avec le browser peut être utilisé pour l'EDI comme pour toute autre forme d'échange électronique. Les données du message EDI en XML sont immédiatement transmissibles à toutes les applications qui utilisent XML comme format d'échange.

Avec XML, l'EDI reste alors la forme la plus ambitieuse de l'échange électronique, puisque automatisé dans l'échange et le "process" qui s'ensuit, et il s'intègre mieux parmi les fonctions du système d'information.

1.4.   One to many : le Web EDI en XML

L'EDI light, utilisant l'EFI (échange de formulaire informatisé) a été une première manière d'utiliser les possibilités du Web pour alléger la charge de l'EDI pour les PME. Ce Web EDI est aussi un outil important pour les donneurs d'ordre qui souhaitent élargir facilement leur communauté EDI vers de petits fournisseurs. occasionnels

Pour cela, un logiciel du type formulaire électronique peut être fourni à ces nouveaux venus, et une adresse leur est réservée sur le site Web EDI. C'est cette base Web EDI qui assure dans les deux sens l'interface Edifact - formulaires électroniques. La solution est transparente pour le donneur d'ordres : ses commandes sont toujours émises en Edifact, mais elles sont reçues chez ses fournisseurs, soit par intégration du message Edifact tel quel dans leur application, soit par simple affichage à l'écran d'un formulaire reproduisant les données du message Edifact dans le cas du Web EDI.

Naturellement en HTML à l'origine, les Web EDI vont maintenant être écrits en XML (avec sans doute XSL) pour afficher tout simplement un message XML, ce qui surprendra d'autant moins les PME qu'elles se seront habituées à ce métalangage universel pour d'autres types d'échanges électroniques. Au total, si le Web EDI était une manière de rendre la dépendance aux clients plus légère, les places de marché orientées fournisseurs permettront aux PME de ne plus être dépendantes du tout !

2.   Le contenu de l'EDI intégré en XML dans les places de marché

Les places de marché qui subsisteront sont celles qui se spécialiseront autour de compétences métier, même pour les achats hors production. L'expertise des commerçants classiques sera toujours indispensable pour l'organisation des catalogues et des têtes de gondole virtuelles. Une compétence métier sera de même nécessaire pour aider les entreprises ayant décidé de pérenniser leurs relations en passant en EDI.

Au total, ce sont bien les fonctionnels et leurs compétences métier qui retrouveront leur rôle : la technique restera d'autant plus facilement à sa place qu'elle deviendra transparente. Avec un seul format, XML, pour structurer tous les échanges électroniques, la place de marché pourra coller plus facilement aux besoins de ses clients.

Avec Internet, il était devenu possible pour les Communautés EDI de faire comme les e-commerçants et de se passer de RVA à la condition de sécuriser leur Extranet. Avec ses nouvelles fonctionnalités, la place de marché électronique permet de justifier à nouveau le coût de la gestion des échanges.

A travers leur PGI (ERP) et leur logiciel de e-business qui les connecte à leur place de marché, les entreprises auront grâce à XML un langage commun permettant à la fonction EDI de ne plus être une excroissance isolée. L'EDI sera alors la prolongation naturelle, en couple "one to one", des relations nouées dans le cadre de la place de marché. Et le plus souvent ce sont les spécifications de la place de marché qui les a marié qui continueront à être le langage commun de ces "couples EDI".

2.1.   EDI et interopérabilité des places de marché

Il n'y a guère, fin 2000, que trois grands fournisseurs de logiciels de places de marché : Ariba, CommerceOne et Oracle, plus des offreurs de solutions toutes faites comme IBM ou Microsoft avec Biztalk : l'interopérabilité entre places de marché ne devrait donc pas être un objectif hors d'atteinte !

Le standard émergeant XML est bien sûr le noyau technologique commun aux éditeurs. Mais tous proposent des spécifications construites autour de XML : Ariba avec le cXML, CommerceOne avec le XCBL, le trio IBM, JPMorgan et PriceWaterHouse-Coopers avec le SpML, Microsoft avec Biztalk. A cela s'ajoutent les "produits standards" mis au point par les fournisseurs comme RosettaNet, la place de marché de l'industrie des composants électroniques.

Certaines de ces e-marketplaces ont tendance à se fermer aux concurrents en utilisant des technologies propriétaires. Mais il sera facile, sous la pression du marché, d'ouvrir les places de marchés et de les connecter les unes aux autres car toutes les solutions sont bâties autour de Java et de XML qui sont des technologies ouvertes.

Cela devrait permettre de se concentrer sur l'interopérabilité au niveau du contenu : comment, d'une part, permettre à une entreprise de se référencer avec ses produits d'une manière homogène d'une place de marché à l'autre, et d'autre part, faciliter la tâche de l'acheteur en lui proposant la même nomenclature de produits d'une place de marché à l'autre.

A étudier : des solutions EDI souples comme celle accompagnant en Edifact un identifiant d'entreprise ou un code produit par deux données (1131-3055). Ces deux données décrivant leur thème et leur organisme responsable permettent de reconnaître le répertoire d'où est tiré l'identifiant d'entreprise ou la nomenclature du code produit.

2.2.   D'abord les pages jaunes du e-commerce

Pour ne pas avoir de surprises désagréables avec des e-partenaires que l'on n'a jamais vu, des pages jaunes garanties par des organismes professionnels de chaque secteur seraient bienvenues.

Après tout, le téléphone a mis un certain temps avant de disposer d'annuaires universels qui ne soient pas des outils de concurrence mais, au contraire, des outils de transparence. Pour le commerce électronique, des codes officiels existent et devraient pouvoir être utilisés avec les standards du marché pour répondre aux questions suivantes :

Qui : les codes EBIC et IAEC répondront à cette question. EBIC, pour EDIRA Business Identifier Code qui est dérivé du code EDIRA (EDI Registration Authorities, basé sur la norme ISO 6523), qui est un identifiant à deux étages commençant par un code précisant que l'on est dans l'univers INSEE, Swift, EAN ou Dun & Bradstreet, suivi du numéro utilisé par ces organismes.

Quoi : le code UN/SPSC, fusion de codes des Nations Unies et de Dun & Bradstreet, permettant de décrire de manière universelle l'activité ou les produits des entreprises pour des appels d'offres en ligne etc.

Où : d'abord l'EUTC, pour ECCMA URL Tag Code, “metatag” identifiant les pages Web et ses attributs d'utilisation, et ensuite le Locode géré par le Cefact identifiant les lieux de livraison pour les transporteurs physiques

NB : l'ECCMA, Electronic Commerce Code Management Association, est une association américaine dont le représentant en Europe est Alain Thiénot.

Comment : avant d'enregistrer les profils, encore faut-il les définir, par exemple à partir du framework d'ebXML s'il parvient à s'imposer.

2.3.   L'offre UDDI d'Ariba, Microsoft et IBM

Dans le domaine des répertoires aussi, le marché peut prendre la normalisation de vitesse en plébiscitant une offre qui devient alors un standard de facto.

Microsoft, IBM et Ariba, soutenus par CommerceOne, SAP, Sun etc. présentent ainsi fin 2000 la première version d'un annuaire intersectoriel et international basé sur XML, UDDI pour "Universal Description Discovery and Integration". Mais dans ce cas, pour que leur initiative puisse devenir un standard de facto, ces grands acteurs du commerce électronique s'engagent à laisser la gestion d'UDDI à un organisme de normalisation ! A noter néanmoins que, comme par hasard, UDDI se base, certes sur XML, mais aussi sur SOAP (Simple Access Object Protocol) proposé au W3C par Microsoft, le tout étant, avec HTML et TCP/IP au cœur de .Net, le cheval de bataille de Microsoft pour la nouvelle économie !

Pour décrire les e-commerçants, UDDI comprend des pages blanches qui les enregistrent notamment par l'identifiant Dun & Bradstreet (questions "qui" et "où"), des pages jaunes (question "quoi") décrivant leurs produits par le code NAICS américain (mieux adapté à la nouvelle économie que les nomenclatures activité-produit classiques) et des pages vertes (question "comment") donnant leur profil API et EDI ainsi que les services Web offerts.

Par rapport aux répertoires existants, c'est d'une part la juxtaposition de ces trois répertoires et d'autre part la qualité des services prévus autour d'eux qui peut faire d'UDDI la base d'un annuaire universel du commerce électronique et du e-business en général.

Quid d'une version française accessible aux PME francophones ?

2.4.   Standardiser l'EDI en XML

Chaque domaine d'utilisation de XML (e-business mais aussi données techniques, multimédia, mathématiques etc.) doit établir sa sémantique : pour assurer l'interopérabilité à ce niveau, cette sémantique doit être commune au maximum d'acteurs d'un secteur donné et enregistrée sinon normalisée.

Première question : compte tenu du caractère eXtensible de XML, peut-on reproduire la démarche top down d'Edifact (des messages universels, aussi bien internationaux qu'intersectoriels et s'imposant à tous) ou faut-il se contenter d'enregistrer des briques élémentaires réutilisables ?

Deuxième question : quel est le bon niveau de ces briques élémentaires ? Faut-il enregistrer tout ensemble des modèles UML, des schémas XML sectoriels et des core components sémantiques du type formats d'adresse etc. ? Edifact s'étant développé sans modèles, c'est à ces deux niveaux de base, flux et données, que l'investissement de l'EDI classique doit être sauvegardé : d'où l'importance dans ce but de l'initiative ebXML du Cefact-Onu et d'Oasis (offreurs sauf Microsoft?).

Mais il est à craindre qu'ebXML débouche surtout sur le plan technique (architecture, enveloppes, messaging etc.) en laissant non résolu le niveau sémantique (discuté dans son groupe Business processes et Core components ).

Il resterait de toute manière à définir qui prendrait en charge la maintenance de cette sémantique XML réutilisable : l'Edifact Working Group s'est porté volontaire à l'échelon mondial avec la collaboration d'Ansi X12. Ainsi la sémantique de l'EDI classique serait maintenue en cohérence avec celle de XML, ce qui ne pourrait que faciliter une transition tranquille des transactions effectuées sur les places de marché en XML vers des relations en EDI.

 Conclusion : XML et BSR pour intégrer l'EDI

L'interopérabilité dont ont besoin les échanges électroniques professionnels doit être totale, de bout en bout, depuis les PGI (ERP) jusqu'aux différentes fonctions des places de marché, y compris l'EDI.

Outil sous-jacent de cette interopérabilité dans l'intégration des processus de business, XML comme contenant. Avec comme contenu celui de l'EDI classique à la condition de le décloisonner tout en le maintenant comme norme des processus et des données de business.

Pour sauvegarder ainsi l'investissement de l'EDI classique, plusieurs méthodes peuvent être utilisées, au besoin successivement :

1.        Transposer tels quels en XML les subsets Edifact utilisés ;

2.        Partir de la sémantique des subsets Edifact utilisés pour reconstruire des DTD-schémas XML tenant compte des nouvelles possibilités des outils liés à XML ;

3.        Modéliser le processus d'affaires et construire des DTD-schémas XML à partir de core components reprenant la sémantique Edifact-Ansi X12 de base.

Dans toutes ces étapes, l'interopérabilité sémantique n'est assurée que si l'on est certain des concepts sous-jacents à chaque donnée. Même pour un modèle, il faut des concepts sans ambiguïté pour définir un acteur, expliciter son rôle etc. Le Basic Semantics Register (BSR) de l'ISO rassemble ces concepts de base, en multilingue pour éviter les ambiguïtés et non-dits de chaque langue. Le BSR facilitant aussi l'interopérabilité sémantique français-anglais pour les PME.

Au total, XML et BSR sont les outils d'une réintégration de l'EDI comme outil le plus ambitieux des échanges électroniques professionnels, en particulier dans le cadre des places de marché électroniques.

Copyright 2000, Claude Chiaramonti, EDItorialiste de VendrEDI.


 

Mots clés.



L'histoire de XML s'écrit en ce moment même. XMLfr vous aide à la suivre et à en dégager les tendances.


Les documents publiés sur ce site le sont sous licence "Open Content"
Conception graphique
  l.henriot  

Conception, réalisation et hébergement
Questions ou commentaires
  redacteurs@xmlfr.org