Le développement du standard d’échanges interentreprises sur internet ebXML n’a-t-il pas pris du retard ?La première mouture validée d’ebXML a été livrée en mai 2001. Mais, à cette date, la spécification était incomplète. Les réelles avancées acceptables ont vu le jour au cours de cette année. Etant entendu que tout cela est lourd et évolue en permanence. Pour comparaison, on fait encore varier Edifact (*) deux fois par an. Les processus d’affaires, le niveau de sécurité, la messagerie et la description de la faculté des entreprises à échanger au travers des Collaboration Protocol Profiles sont des points globalement stabilisés.Quel est l’enjeu de cette réorganisation de l’UN/Cefact (*) en forum ?Auparavant, on n’avait qu’une syntaxe : Edifact. Il n’existait pas de différenciation entre les gens du métier et ceux qui mettaient réellement en musique les mes- sages Edifact. Or, l’idée générale d’ebXML, c’est de définir des processus collaboratifs, leurs messages et leurs Core Components associés dans une syntaxe neutre, non liée à une représentation physique de ce que seront les échanges effectifs. Cette syntaxe neutre apparaît précisément parce que l’on a maintenant deux formats à gérer : Edifact et XML. Cela s’est traduit par la création et la coordination de nouveaux groupes de travail au sein de l’UN/Cefact.L’étude Gencod EAN France montre qu’aucune de ses entreprises adhérentes ne recourt à XML (voir encadré Etude). Cela ne vous inquiète- t-il pas pour ebXML ?Non, c’est normal. Les premières versions d’Edifact sont sorties en 1986. Or, l’usage de cette norme n’a vraiment démarré qu’en 1996 ou 1997. Edifact est une technologie c?”ur de métier qui marche bien et qui génére de gros volumes d’échanges. Les partenaires sont stables, et les utilisateurs gagnent beaucoup d’argent grâce à cette norme EDI, dont le marché continue de croître de 10 % par an.Vous êtes le promoteur d’ebXML en France. Et pourtant, vous êtes plutôt fataliste sur son délai d’adoption…Il faut bien comprendre qu’ebXML s’adresse à des entreprises qui ont déjà implémenté l’EDI traditionnel. Il est clair qu’elles ne vont pas se précipiter vers ebXML. Sauf si elles y voient un moyen d’identifier de nouveaux fournisseurs, par exemple. Elles ont aussi beaucoup investi dans des solutions alternatives de type web EDI. Donc, on ne va pas tout bousculer du jour au lendemain. Il y a là une forte problématique de maturation. On estime globalement qu’un système d’information évolue tous les cinq ans au minimum.Dans ce cas, comment inciter les entreprises à utiliser ebXML ?Edifrance a soutenu ebXML dès le début, car nous étions conscients des limitations d’Edifact. D’abord, vis-à-vis des applications impliquant des traitements multimédias [transmission d’images par exemple ?” NDLR] ou des notions d’interactions plus temps réel ou conversationnelles. Avec la version V4, nous avons essayé de lancer une version interactive d’Edifact. Mais elle n’a jamais été implémentée. Ensuite, on sait que, pour les PME, le coût de démarrage est élevé avec Edifact : il faut environ un mois pour amorcer un nouveau partenaire. Cela nécessite deux ou trois jours de prestations, et l’achat d’un traducteur EDI dont le prix de base s’élève à 600 euros. D’autant qu’Edifact présente un gros problème : c’est une norme de container, pas de messages. Elle définit bien l’environnement, l’enveloppe, la façon dont est structurée l’information. En revanche, la façon dont sont utilisés les messages à l’intérieur du container peut varier d’un partenaire à l’autre. Ce qui sous-entend un paramétrage à chaque fois qu’une PME veut dialoguer avec un nouveau donneur d’ordres.Il existe déjà un certain nombre de spécifications XML sectorielles. Pourquoi choisir plus spécifiquement ebXML ?En mai 2002, bon nombre de ces initiatives ?” EAN-UCC (grande distribution), Swift (réseau bancaire), Bolero (commerce international), OTA (transport civil), ou encore l’OAG ?” ont affirmé leur volonté de devenir compatibles avec ebXML. Cette démarche est rendue possible notamment par leur utilisation commune de la méthodologie UMM (UN/Cefact Modeling Methodology), vouée à la description des processus d’affaires. Leur intérêt de se conformer à ebXML ? L’intersectorialité. Dans la réalité, tout le monde dialogue avec tout le monde. Ce n’est pas parce que vous êtes dans la distribution que vous n’allez pas avoir besoin de messages bancaires. L’adhésion de ces différents groupes sectoriels est fondamentale. Car cela signifie qu’il n’est pas utile d’attendre la version définitive du volet Core Components d’ebXML. Ces composants de base pourront être remplacés par les dictionnaires de données métier ?” déjà prêts ?” de ces organismes. Par exemple, nous travaillons avec Gencod EAN sur ce sujet : nous reprenons ce qu’ils ont fait en XML pour l’intégrer dans ebXML.On a commencé par confronter UDDI à ebXML. Avec les dernières évolutions des services web ?” à l’instar de la proposition de Microsoft, IBM et BEA, BPEL4WS (Business Process Execution Language for Web Services) ?” estimez-vous ebXML menacé ?L’annuaire d’ebXML est désormais parfaitement complémentaire d’UDDI, puisque celui-ci et la spécification ebXML Registry ne font plus qu’un depuis le printemps 2001. S’agissant de l’opposition entre services web et ebXML, je pense que ce sont deux concepts qui ne se situent pas du tout au même plan. Le premier est une technologie, tandis que le champ du second est bien plus vaste, car intégrant une notion de langage et de sémantique. Je suis intimement persuadé que les services web seront tôt ou tard incorporés à ebXML. D’ailleurs, cette norme [ebXML Message Service ?” NDLR] a déjà retenu Soap comme protocole de communication et s’oriente déjà vers des approches interactives. Les gens de l’EDI pensent plutôt batch, avec l’envoi de flots de documents. Mais on s’aperçoit que les demandes de nouvelles applications comportent de plus en plus de mécanismes d’échange temps réel ?” par exemple, la cotation de fournisseurs avant passage de commande.Mais, avec BPEL4WS, on peut définir sa propre sémantique…Cela ne résout pas le problème. Pour discuter d’une sémantique, il faut disposer d’un dictionnaire commun. Chez Edifrance, nous avons travaillé sur les services web, et nous pensons qu’il reste un gros effort à fournir sur la normalisation de leur sémantique. Certains d’entre eux seront communs à toutes les entreprises. La disponibilité d’un article en stock, l’encours d’un client, entre autres, sont des informations banalisées par excellence. Là, on aurait besoin de définir un vocabulaire identique pour tout le monde.Les initiatives industrielles concurrentes, comme BPEL4WS et WS Choregraphy Interface de Sun, ne sont pas sans alimenter une certaine confusion. En tant que défenseur d’ebXML, penchez-vous plus pour l’une que pour l’autre ?D’abord, ebXML comprend déjà des techniques de collaboration et il décrit le séquencement des dialogues. Ensuite, cette norme s’inscrit dans une démarche de standardisation non propriétaire et, si possible, internationale via UN/Cefact. D’autres démarches sont le fruit de la réflexion de fournisseurs de solutions avec l’intérêt évident de s’approprier des parts de marché. Nous pensons globalement que ce n’est pas une bonne approche. Même si les entreprises ont la liberté de choisir cette voie. Nous estimons ?” et nous l’avons prouvé avec Edifact ?” qu’il vaut mieux s’appuyer sur des standards ouverts, sur lesquels tout le monde peut intervenir dans une structure organisée. A terme, toutes ces initiatives auront intérêt à converger. On l’a vu par le passé avec Corba ou UML.Mais cette convergence prendra énormément de temps…Oui. Mais soit on décide d’opter pour les services web pour pallier les insuffisances des systèmes existants ?” c’est dans cette optique qu’on les utilise actuellement ?”, soit une entreprise choisit de faire de son système d’information un système communiquant avec l’intégralité de ses partenaires, et cela prendra des années. Car elle devra repenser tout son noyau applicatif.Voilà environ un an, vous souteniez qu’un bon moyen d’impliquer les PME dans les nouveaux échanges B to B consistait à encourager leurs fournisseurs de progiciels à se conformer à ebXML. Où en est-on aujourd’hui ?C’est un travail de longue haleine. Nous avions déjà tenté cette approche il y a deux ou trois ans avec EDI Lite ou Simple EDI. Et ce avec l’idée de réunir autour d’une table des éditeurs de logiciels et de créer des sous-ensembles de messages correspondant au plus petit commun multiple des concepts qu’ils gèrent. Cela n’a rien donné en raison du frein que constituait le traducteur EDI. Nous sommes en train de refaire ce travail avec XML, dans le cadre d’un projet mené en relation avec EAN-UCC. Des acteurs comme Sage, Generix ou Interlogiciel sont intéressés, car nous leur proposons une solution unique de gestion des processus collaboratifs.Reste que, aujourd’hui, cette interface unique n’est pas prête. Ne peut-on pas se contenter des interfaces XML de base ?On peut toujours faire appel à des moteurs de transformation comme XSLT pour passer d’un format XML spécifique à un standard comme ebXML. Par exemple, il n’y a aucune raison pour que l’on ne puisse pas convertir un flux XML de SAP R/3 en ebXML. Il faut bien voir que XML est utilisé partout, aussi bien en interne qu’en externe. Il est d’ailleurs intéressant de remarquer les évolutions des fournisseurs de traducteurs EDI, comme Illicom ou EDT, qui changent de vocabulaire marketing et s’orientent désormais vers l’EAI. De la même façon, les éditeurs de ce dernier, tels Webmethods ou Tibco, annoncent le support de normes EDI verticales. Dès que le standard ebXML sera complètement mûr, à savoir dès que l’on disposera de bibliothèques de Core Components utilisables ?” au printemps prochain, selon moi ?”, les experts de l’intégration d’applications l’exploiteront.(*) Edifact est la norme internationale utilisée pour lEDI, maintenue et coordonnée par le Centre pour la facilitation des procédures et pratiques dans l’Administration, le commerce et les transports (Cefact).
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
