Rôle d'EDIFRANCE dans la réconciliation du "top-down" EDIFACT-ONU et du "bottom-up" XML-EDI
3 pages	par Claude Chiaramonti chiara@worldnet.fr Président du Groupe " Modélisation et Scénarios EDI " Contribution personnelle rédigée à la demande de CREDIBLE	10-12-98

Merci à Claude Chiaramonti de nous autoriser à publier cette intéressante contribution au développement d'une normalisation  XML qui récupérerait les acquis de l'EDI. Claude Chiramonti était précédemment délégué général d'Edifrance. L'article, contrairement à ce que pourraient penser des lecteurs pressés, est rédigé en français. Sur XML voir aussi l'article de  Emmanuel Lazinier "XML Des documents qui prennent vie, ou comment XML va transformer la façon dont nous concevons et exploitons nos documents" http://www.admiroutes.asso.fr/action/theme/internet/xml.htm
Baquiast

Organisé autour de grandes entreprises au sein de Communautés, l'EDI traditionnel est pratiqué, d'un côté par 95% des plus grandes entreprises mondiales, mais de l'autre par seulement 2% de toutes les autres ! Cela, même si la plus importante des Communautés EDI, EAN, essaye d'étendre son audience avec Simpl-EDI en Grande-Bretagne et l'EFI en Web EDI en France.

L'EDI traditionnel restera de toutes manières un scénario "top-down " : les PME se joignant à une Communauté auront toujours à se plier au Guide d'utilisation de la Communauté avant de " mapper " vers leurs logiciels . Et si quelqu'un veut améliorer un aspect d'EDIFACT-ONU, ne serait-ce que par un nouveau code, il aura toujours à attendre des mois avant de voir sa demande prise en compte.

2/ L'extension d'XML/EDI, qui va être distribuée par Microsoft, SAP et les autres grands fournisseurs dans le monde entier à des millions d'entreprises.

XML/EDI est adapté aussi bien pour des formulaires à afficher à l'écran qu'à des messages EDI destinés à des applications. Un ensemble de formats de messages EDI ( les DTDs, ou Document Type Definition), sera disponible dans les prochaines versions des principaux logiciels comme Money de Microsoft. Cela permettra à une PME d'envoyer un tel DTD suivi des données dans le format de ce DTD à une autre PME qui pourra mapper ces données sans avoir à se conformer à un quelconque subset, Guide d'utilisation ou Accord d'interchange.

En effet, en EDIFACT on rédige l'accord d'interchange et il faut qu'un spécialiste le décode et configure le logiciel. Changer d'accord d'interchange est très coûteux puisqu'il faut faire revenir le dit spécialiste.

Avec XML/EDI, le concept équivalent à l'accord d'interchange est le DTD lui-même. Le DTD est écrit dans un langage formel et il est interprétable par l'ordinateur. Cela permet de se passer de spécialistes et de le remplacer par l'ordinateur. Alors qu'EDIFACT n'est que " door to door ", XML/EDI est bien d'application à application.

C'est là une tendance générale, le "plug and play", qui apprend à l'ordinateur à configurer ce que les experts devaient faire manuellement avant.

Naturellement, il y aura une période de mise au point pour XML/EDI et pendant quelque temps le "plug and play" sera d'abord du "plug and pray" !

Mais il s'agira bien d'un scénario " bottom-up " puisque les " communautés " XML/EDI qui se constitueront autour de leurs DTD grossiront et seront alors face au problème habituel de la Tour de Babel : si un DTD peut être amélioré en quelques minutes, les PME auront bientôt à stocker de nombreux DTD traitant tous des message commande, facture etc.

Et la question de l'alignement sur quelque chose ressemblant à une norme se posera, et dans ce cas pourquoi pas aider ces communautés XML/EDI à rapprocher leurs DTD des Guides d'utilisation des Communautés EDIFACT-ONU !

D'où le challenge: comment aider à la convergence entre ces deux scénarios, celui de l'EDIFACT-ONU traditionnel et celui du " upcoming " XML/EDI ? Car l'EDI traditionnel ne va pas disparaître ! Les grandes entreprises en sont satisfaites et ne veulent pas perdre leur investissement. Même chose pour les RVA et les Communautés EDI vendant leurs Guides d'utilisation etc.

Mais il est peut-être utile de faire le tri, parmi les produits EDIFACT-ONU, entre ceux qui vont survivre et ceux amenés à disparaître. Le plus probable est de voir les deux normes ISO relatives à l'EDIFACT-ONU devenir obsolètes :

- la version 3 de la syntaxe qui va rester en usage sera " retained " par l'ISO, mais la version 4 qui est cours de normalisation (ISO 9735) ne sera jamais mise en œuvre , les Communautés préférant "wait and see";

- le TDED (ISO 7372 ) n'est plus vraiment mis à jour (la véritable norme étant le TDID qui survivra sans doute comme base du futur EDI) ;

Au contraire, en effet, ce TDID, standard " de facto ", qui présente plus de 200 messages EDIFACT-ONU et leurs répertoires associés de définitions de données et codes rassemble toute l'expérience et le savoir-faire de l'EDIFACT-ONU concernant les analyses de business, les flux d'informations et l'organisation des données qui y sont associés.

Alors, le plus probable est de voir ce TDID, véritable contenu de l'EDI traditionnel en EDIFACT-ONU rester en usage avec la syntaxe XML/EDI à la place de la syntaxe EDIFACT-ONU.

Mais il y a malheureusement une autre possibilité : celle de voir les fournisseurs en XML/EDI réinventer la roue en proposant un registre (si ce n'est pas plusieurs registres propriétaires ! ) de schémas DTD, feuilles de style et Tags (définitions ou balises) de données et codes faisant double emploi avec le TDID. C'est là que la communauté EDIFACT-ONU se doit d'intervenir devant un choix très simple :

• ou la communauté EDIFACT-ONU essaye de participer au développement d'XML/EDI et sera capable d'y insérer le contenu du TDID ;
• ou la communauté EDIFACT-ONU ignore le succès d'XML/EDI et les futures implémentations EDI ignoreront EDIFACT !

Les experts Européens en EDI, tout particulièrement les Français, ont depuis le début fait l'apport le plus important à EDIFACT : c'est à eux de décider s'ils ne veulent rien voir et laisser EDIFACT mourir tranquillement  (et remplacer l'interchange agreement par le formalisme du DTD)''' ou insérer l'EDIFACT-ONU dans le cadre du nouveau concept XML/EDI :

1/ le niveau des messages : plusieurs Communautés EDI, en Europe comme en Amérique du Nord, ont déjà traduit leurs UNSM en DTD et, en France, DARVA semble faire de même. Cela doit être systématisé, même si aucune migration n'interviendra avant une très forte pression des fournisseurs des PME.

EDIFRANCE pourrait être le lieu d'enregistrement en français de ces DTD : ne serait ce que pour aider les PME (et peut-être même leurs fournisseurs de logiciels) à savoir ce qui se pratique et se préparer à un glissement progressif vers des DTD ressemblant aux UNSM et à leurs subsets français.

2/ le niveau des Tags des données : une proposition a été faite au CEFACT d'organiser le " Repository " des Tags des données XML/EDI de manière à assurer l'articulation avec le TDID : le problème est que les fournisseurs comme Microsoft ne souhaiteront sans doute pas livrer leurs propres registres pour des raisons évidentes, l'une étant une question d'image, le CEFACT n'étant pas encore capable d'automatiser la mise à jour de ses propres répertoires.

Par contre, EDIFRANCE a sans doute là aussi un rôle à jouer : de même qu'EDIFRANCE diffuse depuis longtemps une version française des répertoires du TDID, il faudrait faire savoir au monde francophone que les Tags d'XML/EDI mais aussi de XSL et autres XMI qui doivent enregistrer la sémantique XML/EDI  seront gérés en français de manière articulée avec les éléments correspondants du TDID.

3/ le niveau conceptuel (où les Tags des données doivent se référer pour qu'elles puissent être mappées entre elles, même si elles sont enregistrées dans des répertoires différents du niveau du TDID) : le TC154 de l'ISO vient d'accepter une proposition dans ce but de construction pratique avant la mi-99 du BSR (Basic Semantics Register) qui a déjà été testé avec le contenu de messages EDIFACT-ONU et ANSI X12.

Alors que la normalisation dans le domaine des échanges électroniques s'effectue pour l'essentiel dans le W3C et dans des groupements de grands fournisseurs, le BSR est sans doute pour l'ISO une chance de ne pas être complètement marginalisée. Mais encore faudrait-il que l'ISO s'en persuade, et toujours pour des questions d'image, y mette des moyens, pas seulement financiers, comme une mention du type " enregistré dans le BSR " lié à la certification 9000.

De même pour l'AFNOR ! Il faut savoir que cette proposition pour la gestion du BSR, acceptée par le TC154, est une proposition française conduite par EDIFRANCE et plusieurs de ses membres, l'INSEE et DARVA notamment : l'aspect multilingual de ce BSR en est naturellement une caractéristique fondamentale qui devrait permettre aux contenus d'XML/EDI qui sont attendus de ne pas être présentés seulement en anglais !

EDIFRANCE ne peut que voir son rôle renforcé en contribuant à éviter un fossé entre EDIFACT-ONU et XML/EDI grâce à un référentiel commun en français.

http://www.admiroutes.asso.fr/action/theme/internet/chiaxml.htm