Bonjour,
 
Ci-dessous VendrEDI n° 65. Comme d'habitude, me signaler par retour de courrier des adresses de nouveaux lecteurs ou votre souhait de ne plus recevoir VendrEDI.
 
Prochain numéro le 29 août, sauf événement imprévu. Bonnes vacances.
 
Cordialement
 
Claude Chiaramonti
 
PS : comme d'habitude, après avoir rédigé l'article "EDI, Internet, SW" du dernier numéro de VendrEDI, j'ai bien demandé l'avis de l'association Edifer, puisque ses travaux devaient être mentionnés dans l'article, mais, semble-t-il, je n'ai pas consulté la personne compétente d'Eurofer-Edifer qui m'a adressé la demande de rectificatif ci-dessous :
 
Dear Claude,
 
Sorry for addressing the issue in English, but it is for me easier than to do it in French.
 
Thank you for providing information on Eurofer about EDI in vendrEDI.  But I have to correct that the  Edifer Committee dealing with e-business is for the moment only maintaining the Eurofer implementation guides for the EDI messages based on the EDIFACT standard and is very active by defining a set of XML messages in the European Steel Industry Data Exchange Language (ESIDEL) standard.  To do that the Edifer Committee are defining the Business processes using UML and defining the class diagrams of the Business documents using UML.  From the syntax neutral class diagram and by using the UN/CEFACT CCTS 1.90 and a set of Design and Naming rules the corresponding XML messages are defined.  Please notice that the XML messages are not  a translation, as you mentioned, of the EDIFACT version of the business documents.  A lot of new messages not define as Eurofer EDIFACT implementation guides have been developed and will be soon available on the Eurofer website. 
 
Eurofer would appreciate that this shall be corrected, and would prefer for the future to be addressed, before information about the Eurofer activities in e-business standardisation is published;  if you need further information about our activities, please don't hesitate to contact us directly.
 
Kind regards,
 
Freddy De Vos
Secretary of the Edifer Committee
Eurofer     
 
 
   VendrEDI   lettre de Claude Chiaramonti
 sur les données de
l'échange électronique
        Numéro 65       27 juin 2003
 llicom : EAI-EDI-B2B
 
Web's Identity crisis :
    pour grands comptes et PME 
le monde réel ou les pages Web ?
Illicom couvre tout le spectre de l'intégration du B2B : EAI, EDI et Web EDI. Leader des grosses applications EDI  et des serveurs pour grands com-ptes, Illicom propose aussi des solutions de déploie-ment packagées pour PME.
Les produits d' Illicom : d'abord Station Visual Com-merce, station EDI pour PME. Pour faciliter sa mise en oeuvre, la station comporte des versions packagées des principaux messages EDI utilisés par les grands donneurs d'ordres. Ensuite, le produit WebXpress pour le Web EDI, couvrant la prise ou l'envoi de commande classique, mais aussi les fiches produits et les télédéclarations B2A. Mais le produit phare d'Illicom est TradeXpress.
TradeXpress est d'une part le serveur EDI de très nombreuses grandes entreprises, et assure d'autre part pour le B2B l'intégration des flux avec les places de marché, l'e-procurement et les plate-formes de catalogues électroniques ; il se positionne enfin comme outil EAI pour moyennes entreprises.
La plate-forme TradeXpress assure l'ensemble des fonctions d'intégration, depuis la transformation des données (EDI, XML, any to any), l'inté gration aux applications (connecteurs SGBD et ERP) et la gestion des Business Process (modélisation et orchestration) jusqu'au routage et à la supervision des échanges . TradeXpress traduit tous les formats EDI utilisés ainsi que 20 protocoles de commu-nication. A noter, de ce point de vue, qu'Illicom est la première société européenne a avoir été certifiée EDIINT AS2. AS2 est un protocole IETF pour l'EDI et le B2B sur Intenet qui permet de se passer de RVA tout en assurant sécurité et traçabilité.
L'outil "TradeXpress Business Process Manage-ment" va assurer la création et l'exécution des processus métier de l'entreprise. L'outil répond aux sollicitations externes, du workflow humain aux services applicatifs, y compris SGBD, ainsi qu'aux Services Web à venir.
Les activités de services d'Illicom, consulting, for-mation et accompagnement d'intégration, peuvent s'appuyer sur le service d'hébergement HubXpress pour l’EDI, le B2B, l’EAI et le Web EDI. Très présente dans les Communautés EDI, Illicom comporte 5 implantations en France et étend son réseau partenarial à l'étranger, y compris en Asie.
 
Les promesses de Services Web où chacun pourrait programmer la réception des seules informations dont il a besoin ne se réalisent pas vite : difficultés mentionnées, la sécurité et l'interopérabilité entre logiciels tardant à s'appuyer sur des standards bien stabilisés. La sémantique n'est que très rarement mentionnée, alors que les praticiens de l'EDI savent bien que, pour que le message passe, il faut d'abord être d'accord sur le sens des données à transmettre ! Les "anciens" de l'EDI rejoignent sur ce point les "futuristes" du Semantic Web qui, pour l'automatisation, placent au premier plan de leurs préoccupations ce préalable de la sémantique.
A commencer par la question de base sur d'identi-fication qui conditionne le transfert d'information : le Web étant défini comme un univers de resources, et ces resources étant (cf RFC 2396bis) "tout ce qui a une identité" de type URI, Uniform Resource Identifier, il faut être d'accord sur ce qui peut avoir une telle URI ! S'agit-il d'identifier des objets du monde réel eux-mêmes ou, simplement, de donner l'adresse de pages Web décrivant ces objets ?
L'URI d'une page Web ou d'un fichier à télécharger peut être équivalent à l'URL,Uniform Resource Locator, qui est l'adresse de cette page Web ou du fichier, mais l'URI d'un individu ne peut être un URL : la personne physique n'est pas sur le Web, seulement sa home page ! L'URI n'identifie pas l'entreprise du monde réel, mais seulement une information sur cette entreprise ou, autrement dit, un identifier n'est pas forcément une address.
Solution : distinguer quand l'URI identifie "directe-ment" un objet du Web, ou seulement indirecte-ment, quand cet objet n'est pas localisable sur le Web. Cette distinction entre deux types d'URI existe dans XTM (XML Topic Maps) et devrait être reprise dans RDF (Resource Description Framework) et par le groupe du W3C sur l'archi-tecture des Services Web. La distinction pourrait être aussi utile pour le groupe Oasis sur le XRI ( eXtensible Resource Identifier) dont le but est de faciliter des distributed directory services per-mettant l'identification de ressources including people and organizations, ainsi que le partage de données entre applications. Un pas vers un Semantic Web automatisé.
Pour que "le message passe" il faut bien être d'accord sur le sens des données à transmettre

    Relancer le B2B :
 
Code à barres > RFID
      filières  + Services Web de PGI
 
Microsoft s'y met avec UCC-EAN 
Marc Sahraoui (Devise), expert en économie numé-rique et notamment en charge de l'OC2E (Observatoire du Commerce et des Echanges Electroniques),  constate que l'écart des usages du B2B se creuse entre entreprises françaises et leurs homologues européennes. Au vu des analyses de Devise et d'une étude de la Commission Euro-péenne, 4 fois moins de vendeurs et 2 fois moins d'acheteurs B2B ! D'ailleurs les résultats des projets B2B sont décevants quant aux coûts des processus d'achat, de la logistique et des stocks intermédiaires.
Pour renverser la tendance et maintenir la compétitivité des filières françaises et de leurs PME, on peut envisager deux formes d'incitations :
1/ Pour , le soutien des pouvoirs pu-blics doit maintenant aller à des contrats avec les fi-
lières sectorielles pouvant s'engager sur une feuille de route "Compétitivité numérique".
Préalable : établir un cadre de référence à 5 ans sur l'adaptation à l'impact des TI. Cadre à partir du-quel  préparer une triple négociation sectorielle : avec l'Etat sur les plans réglementaires, avec l'international pour les contenus, les formats et les scénarios des échanges électroniques, comme cela a été fait pour la norme Edifact, avec les offreurs pour l'adaptation de leurs outils et services.
Est surtout importante la mutualisation des actions de réorganisation inter-entreprises : modéliser dans son coin son processus d'affaires ne sert à rien. Cette mutualisation, de type "Communauté EDI", étant définie à l'échelon national, utilisée comme "levier" à l'échelon européen, déclinée en région. Le programme e-PME en cours de développement par l'AFNeT va dans ce sens.
2/ Une 2ème forme d'incitation viendra sans doute des fournisseurs de PGI (ERP) qui ne peuvent plus se contenter de l'intégration interne. SAP annonce ainsi sa plate-forme NetWeaver, une Enterprise Services Architecture, compatible .Net et Java, basée sur des Services Web ouverts vers les appli-cations des partenaires de l'entreprise. NetWeaver comprendra les mappings XML avec les standards EDI, dont Edifact, les PIP de RosettaNet etc.
La relance d'un "B2Bfr" sera d'autant plus efficace que les filières sauront faire adapter pour leurs PME ces PGI communicants. Le B2Bfr doit, en effet, associer la rigueur et l'automatisation de l'EDI  avec la souplesse et l'ouverture des Services Web. Sans oublier le français pour les PME : la relance pour le multilinguisme de l' outil BSR pouvant contribuer à ce que, dans le B2Bfr, le fr soit bien relié au B2B anglophone.
 
Le code à barres ne sert pas seulement à identifier les produits que le consommateur doit payer à la caisse, mais est d'abord utile pour l'inventaire et le suivi des colis et palettes contenant ces produits. En effet, il ne suffit pas qu'un flux d'informations EDI irrigue les supply chains : pour assurer le Tracking & Tracing, encore faut-il que l'on puisse vérifier à volonté que les marchandises physiques suivent bien ! Il faut donc une saisie d'informations qui les identifie à chaque étape, si possible sans que cela stoppe ou freine les opérations de transport et de manutention. Et de ce point de vue, la technique de la RFID, Radio Frequency IDentification est moins contraignante que celle du code à barres, puisqu'elle peut être automatique par passage sous un portique etc. Elle peut offrir d'autres fonction-nalités que les seuls identifiants EAN (du numéro de colis à l'unité consommateur), la puce RFID de moins de 1 mm pouvant comporter des infor-mations complémentaires, avec en tout premier lieu des données du flux EDI. En contrepartie, la RFID est chère, rentable seulement en grand nombre, et pas encore bien acceptée par les autorités radio.
En tout cas, UCC et EAN (grande distribution mon-diale) ont créé AutoID pour développer, au-delà du code à barres, une RFID comportant 5 techniques :
- identification, du colis au produit consommé ;
- "lecture" à distance des données de la puce ;
- système du type Internet Domain Name Service  pour passer de l'identifiant numérique de la balise RFID à la description du produit ;
- langage XML pour la description des produits ;
- une base de données distribuée contenant des in-formations sur les produits identifiés.
Du point de vue de l'information, une certaine homogénéité d'ensemble est donc recherchée, alors que les codes à barres n'ont d'homogène que l'identification pays-entreprise, les produits identifiés et les informations les concernant restant ensuite de la seule responsabilité des entreprises.
La RFID sera sûrement  très vite précieuse, depuis les fabricants jusqu'aux détaillants, pour les sys-tèmes de pilotage et reporting du supply chain management, comme pour la gestion automatisée des entrepôts ou plate-formes d'éclatement jusqu'au cross-docking et au séquencement des colis.
C'est sans doute pourquoi Microsoft a été le premier à rejoindre AutoID, d'abord pour participer à la mise au point de certaines des technologies prévues pour la RFID, et ensuite être ainsi bien placé pour l'inclure, dès  l'année prochaine, à son offre de logiciels d'inventaire etc.
Ce numéro 65 de VendrEDI a été adressé à 1108 abonnés      Pour écrire    
Tous les numéros de VendrEDI peuvent être téléchargés zippés à    http://www.actimum.com/acvendredi.htm