Échange de Données Informatisé (EDI) : Claude Chiaramonti

change de donnes informatis (EDI)
par
Claude CHIARAMONTI
EDItorialiste
Membre du conseil dadministration ddifrance
1.
1.1
1.2
1.3
EDI, prcurseur du B2B ..........................................................................

Permanence de la fonction de lEDI ...........................................................
EDI classique : RVA et Edifact pour les grands comptes
donneurs dordres .......................................................................................
LEDI demain avec Internet, Web et XML ..................................................
2.
2.1
2.2
2.3
H 3 598 2
5
5
Acquis et limites dEdifact....................................................................

LEDI classique standardis den haut (top down) ....................................
Derniers progrs ..........................................................................................
Que reprendre dEdifact ? ...........................................................................
6
6
9
10
3.
3.1
3.2
3.3
Approche XML partant de lutilisateur (bottom up) ......................

DTD-schmas et namespaces pour eXtensibility avec reusability
Outils XML : XSLT, XLink, DOM, etc...........................................................
Langages XML mtiers, frameworks et rfrentiels.................................
11
11
13
14
4.
4.1
4.2
4.3
La synergie : intgrer lEDI en XML dans la bote outils

de lentreprise ...........................................................................................
LEDI couche des PGI, progiciels de gestion intgre (ou ERP) ...............
LEDI parmi les outils de communication de lentreprise.........................
EDI et XML dans une normalisation au service des entreprises .............
16
16
17
18
5.
Conclusion .................................................................................................
19
Rfrences bibliographiques .........................................................................
19
u dbut des annes 90, l'EDI tait le sigle la mode, porteur de la modernit
d'une informatique qui devenait un outil de communication standardis
entre entreprises. Le sigle EDI, Electronic Data Interchange, se conserve en franais avec comme traduction change de Donnes Informatis : noter que cest
lchange qui est informatis, pas seulement les donnes. Ne serait-ce cette proccupation de conserver le sigle anglais, on pouvait plus simplement parler
dchange lectronique de donnes.
On ne parlera pas ici des changes de donnes techniques qui ont leur sigle,
EDT, leur norme, STEP, et leur problmatique propre, pour sen tenir aux changes lectroniques de donnes structures relatives ladministration, au commerce et au transport, selon le sigle Edifact, Electronic Data Interchange For
Administration, Commerce and Transport.
LEDI lheure dInternet

et de XML
Avec Internet, le Web et XML, l'EDI, jusqu' prsent centr sur les grands
comptes donneurs d'ordres, va pouvoir pntrer le tissu des PME et, aprs avoir
t le prcurseur du B2B, en rester l'pine dorsale pour tre le back office du
commerce lectronique.
Car la fonction de lEDI, rationaliser, codifier et automatiser des transactions
rptitives entre applications dentreprises diffrentes, ne peut que prendre de
limportance avec le commerce lectronique et la socit de linformation.
Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Informatique
H 3 598 1
CHANGE DE DONNES INFORMATIS (EDI) ________________________________________________________________________________________________
LEDI classique install va continuer se renforcer en continuant utiliser la

norme Edifact. Mais si XML devient le liant entre tous les types dapplications, il
sera de plus en plus difficile de ne pas passer de la syntaxe Edifact au mtalangage XML.
Cette migration sera dautant moins coteuse pour les quelque 30 000 entreprises franaises dj difies quelle prservera lacquis dEdifact : lanalyse
des processus daffaires et la smantique des codifications utilises.
Passer XML et ses outils apportera deux grands bnfices : dune part intgrer lEDI, jusquici marginalis, parmi les outils de communication de lentreprise, y compris places de march et catalogues lectroniques, dautre part
ouvrir lEDI sur de nouveaux partenaires sur le Web.
Reste XML stabiliser les spcifications de ses outils et aux utilisateurs
enregistrer leurs profils de mise en uvre pour concilier la libert eXtensible
(0)
de XML avec la possibilit de rutiliser ce qui existe dj.
Lemploi dexpressions en anglais est invitable : le sens dans lequel elles sont employes est
explicit dans larticle.
(0)
Remerciements
Plusieurs dveloppements de cet article sont emprunts ltude de Canope et Tenor Conseil
Opportunit d'utilisation de XML dans le cadre des EDI pour la MTIC, la CNAV et le GIPMDS, en particulier les exemples de donnes et segments Edifact ainsi que le couple schma
et message XML de commande dans lautomobile [1].
La thse densemble et de nombreux dveloppements sont des prolongements de louvrage
Applications EDI sur lInternet (Eyrolles) [2].
1. EDI, prcurseur du B2B

Le lecteur trouvera dans le tableau 1 la liste des principaux sigles
et expressions utiliss au cours de cet article.
message EDI. Naturellement, cet automatisme ne se justifie que si

les commandes sont suffisamment nombreuses et renouveles
souvent : c'est bien le cas d'un supermarch o des centaines de
produits, pour ne pas dire des milliers, sont en rappro chaque
jour, en particulier les produits frais.
En prolongement des changes qui se passent l'intrieur des

systmes d'information centraliss et rguls par l'entreprise, l'EDI
ne concerne que les changes lectroniques entre entreprises diffrentes, changes rptitifs en principe automatiss, donc ncessitant un accord pralable sur le scnario et le format d'change ainsi
que sur le sens, la smantique, des donnes transmettre.
L'EDI est adapt aux changes de tous les domaines, pas seulement ceux du commerce lectronique, ds l'instant o ces changes sont suffisamment rptitifs pour justifier d'tre dmatrialiss
et automatiss. Mais s'il ne s'agit que de commander une dizaine de
produits une fois par semaine, le fax ou la messagerie lectronique
sont largement suffisants !
noter que lEDI classique na pas t que le prcurseur du B2B,

mais aussi du B2A : de par son origine doutil de simplification des
procdures du commerce international, les dclarations douanires
ont trs vite t difies . Ensuite, la France a t lorigine de
plusieurs messages utiliss pour les tlprocdures sociales ou
fiscales.
Voir la lettre mensuelle VendrEDI, abonnement :
courrier.vendredi@worldnet.fr
1.1 Permanence de la fonction de lEDI

On a gard gnralement de l'EDI une vision lie son origine :
RVA, X435 et Edifact. En fait, la fonction de l'EDI, mettre niveau
automatiquement des applications informatiques d'entreprises
diffrentes, est une fonction permanente, qui va pouvoir toucher le
tissu des PME grce Internet, au Web et XML et devenir le back
office du commerce lectronique B2B. tant permanente, cette fonction de l'EDI est donc indpendante des rseaux, protocoles de
transfert, matriels, logiciels et mme des syntaxes.
1.1.1 Dfinition et conditions de succs de lEDI

la sortie d'un supermarch, la caisse enregistreuse n'tablit pas
seulement le ticket de caisse, elle informe l'application de gestion
des stocks de la vente effectue : le soir, l'application totalise les
ventes et passe commande automatiquement au fournisseur via un
H 3 598 2
Dfinition : l'EDI (change de Donnes Informatis) est un

outil au service de l'change lectronique consistant transporter automatiquement de l'application informatique d'une entreprise l'application informatique d'une autre entreprise, par des
moyens de tlcommunication, des donnes structures selon
des messages types convenus l'avance.
Mais l'EDI est d'abord un effort d'organisation consistant
analyser les procdures d'changes et leurs flux de donnes
pour les rationaliser, les codifier et en dduire une automatisation ( machine to machine ) des relations rptitives entre des
acteurs qui communiquaient jusqu'ici par papier, fax ou message lectronique ( human to human ).
Le fonctionnement de l'EDI est le suivant :
l'application de gestion des stocks du supermarch extrait les
rfrences des produits commander avec les quantits, etc., et
compose un fichier de donnes plat ;
un logiciel de traduction compose partir de ces donnes un
message normalis (par exemple le message commande Edifact
ORDERS) avec des sparateurs ou des balises dans le cas de XML,
message qu'il envoie au fournisseur ;
le logiciel de traduction de ce dernier vrifie le message puis le
traduit en un fichier plat dont les donnes sont intgres dans
l'application d'administration des ventes qui les traite et fait prendre
les mesures ncessaires.
(0)
________________________________________________________________________________________________ CHANGE DE DONNES INFORMATIS (EDI)
Tableau 1 Principaux sigles ou expressions utiliss (1)

Terme
Dfinition
Terme
B2A
Framework
Back office
Business to Administration, par exemple tlprocdures

Business to Business, par exemple transactions
interentreprises
arrire-boutique, ce que lutilisateur ne voit pas
Boilerplate
matrice ou modle
Bottom up
ascendant
B2B
Core component lment smantique de base rutilisable

Demand chain remonte dinformations sur les gots des consommateurs pour lECR
DTD XML
Document Type Dfinition, quivalent XML du message-type
ebXML
electronic business XML, initiative commune
OASIS et au Cefact-ONU pour encadrer un dveloppement de XML garantissant linteroprabilit
Edifact
norme EDI pour ladministration, le commerce et le

transport
EFI
change de Formulaire Informatis
ECR
Efficient Consumer Response, remonte dinformation sur les ventes et adaptation rapide de la production et des livraisons aux gots des
consommateurs
Enterprise Ressource Planning (en franais, PGI,
Progiciel de Gestion Intgre)
caractre extensible de XML
ERP
eXtensibility
Extranet
Dfinition
cadre
Glue
colle forte, liant
ISO
International Standard Organization
Mapping
transcodage ou mise en correspondance, code

code, entre deux codifications
Namespace
espace nominal permettant dviter les confusions

smantiques
Reusability
RVA
caractre rutilisable
Rseau Valeur Ajoute
Schma XML
Subset
Supply chain
TDID
Top down
dfinition plus prcise que le DTD des spcifications dun message XML
sous-ensemble dun message-cadre Edifact comprenant au moins tous les segments obligatoires
chane dapprovisionnement en B2B des fournisseurs vers leurs clients
Trade Data Interchange Directory, jeu de rpertoires
pour lchange de donnes, le mot trade , depuis
longtemps trop limitatif, rappelant lorigine dEdifact comme outil de simplification des procdures
du commerce international
descendant
Trade
commerce international
X435
adaptation de la norme X400 lEDI (ou Pedi)
utilisation des protocoles Internet pour un ensemble ferm dentreprise
(1) Les expressions ou sigles mentionns seulement dans le paragraphe o ils sont dfinis ne sont pas rappels ici.
La solution fichier plat la plus utilise est bien adapte un EDI

limit un seul message : mais lors dun scnario comportant
l'enchanement de plusieurs messages un transfert des donnes du
message vers une base de donnes semblerait plus appropri, facilitant par la mme occasion le passage XML. Cependant, peu de
traducteurs Edifact en sont encore capables.
Quoi qu'il en soit, les deux applications se sont mises niveau
automatiquement, chacune restant nanmoins matre chez elle
puisqu'il n'y a pas eu besoin d'aligner les systmes d'information,
grce la double traduction Edifact (figure 1). Mais le but est quand
mme atteint : l'application de gestion des ventes du fournisseur
dispose dsormais des mmes donnes que l'application de gestion
des stocks du client sur les rappros attendues.
Nota : des fichiers plats peuvent tre changs entre entreprises sans que l'on parle
alors d'EDI, mais il s'agit d'une solution rigide se prtant mal l'automatisation des traitements.
En plus du caractre rptitif des changes difier , deux

conditions sont remplir pour que le recours l'EDI soit justifi :
il faut que les donnes transmettre soient connues l'avance
et structurables pour tre codifies : identifiants des articles commands, quantits, prsentation, prix, conditions de livraison sont
des donnes qui peuvent tre facilement codifies d'un commun
accord l'avance ; et si une donne imprvue devait tre ajoute
exceptionnellement, des zones de texte libre sont prvues cet effet
dans le message ;
les codes correspondant aux donnes transmettre doivent
pouvoir tre extraits et intgrs automatiquement dans les appli-
Partenaire A
Partenaire B
EDI
Applications
utilisateur
Applications
utilisateur
Suivi de
contrle
Affichage
EDIFACT
Message
en langage
commun
Figure 1 LEDI, une mise niveau des applications qui respecte

lautonomie de chacun
cations qu'il s'agit de mettre niveau, en particulier pour qu'elles

puissent tre traites automatiquement l'arrive chez le fournisseur : demande des produits commands au magasin, rservation
du moyen de transport, information de l'application comptable, du
logiciel de facturation, etc.
H 3 598 3
Seuls les cas exceptionnels et non prvus tant rservs la

gestion humaine, il faut donc un mapping entre toutes les donnes
du message EDI et les donnes de l'application : il s'agit l de
l'opration la plus lourde pralable l'EDI qui ne peut tre ni automatise ni entirement sous-traite. Mais il peut s'agir aussi de
l'aspect le plus rentable de l'EDI, ce mapping obligeant passer en
revue toutes les procdures de l'entreprise et, pourquoi pas, les
rationaliser.
Client
Fournisseur
Commande
Rponse-Facture
Ordre de
livraison
1.1.2 Domaines et fonctions de lEDI

L'EDI est apparu dans tous les domaines o les changes de
donnes taient la fois suffisamment rptitifs et codifiables pour
justifier leur automatisation : rservation des billets d'avion, transport maritime, approvisionnement en pices dtaches de l'industrie automobile, grande distribution, transferts bancaires, etc.
Autant dorganisations o des flux rptitifs sont courants.
Chaque secteur a dvelopp ses propres formats de messages
jusqu' ce que le besoin d'un format intersectoriel et international
soit suffisamment fort pour donner naissance la norme Edifact
vers laquelle tous les messages propritaires ont migr (sauf les
messages EDI nord-amricains Ansi X12). Ds lors, pour faire le tour
des domaines, secteurs, fonctions o l'EDI s'est implant, il suffit
d'analyser la collection de plus de 200 messages Edifact.
Pour chacune des fonctions suivantes, des messages Edifact standardiss permettent de btir de vritables scnarios d'changes
lectroniques automatiss :
fonctions commerciales ou commerce lectronique ;
logistique ;
paiement bancaire ;
gestion des conteneurs ;
suivi des marchandises dangereuses ;
ddouanement ;
gestion dun chantier de construction ;
qualit de leau ;
instance et gestion judiciaire ;
recouvrement de dettes ;
gestion comptable y compris les formalits administratives ;
enregistrement et informations sur les entreprises, statistiques
avec des messages concernant la balance des paiements ;
assurances ;
dclaration et paiement de cotisations sociales y compris gestion dun salari cotisant ;
gestion hospitalire, depuis les achats jusquau remboursement des soins, en passant par les analyses de laboratoire et le dossier mdical ;
rservations touristiques ;
gestion du march de l'emploi.
Le plus important de ces scnarios, celui du commerce lectronique B2B, correspond la fonction EDI qui s'est implante le plus
largement dans la plupart des secteurs du commerce et de l'industrie. Il est dtaill ci-dessous.
1.1.3 Scnario de commerce lectronique B2B

en EDI
Sur plus de 200 messages Edifact standardiss, 31 concernent le
commerce lectronique dentreprise entreprise B2B. On peut y
ajouter les messages relatifs aux relations avec les douanes, les
transporteurs ou les banques (figure 2). Une communaut souhaitant installer une relation EDI sur un scnario de commerce lectronique a la possibilit de dmarrer avec un scnario simple ne
comportant que deux ou trois messages et dlargir progressivement son scnario en utilisant au fur et mesure davantage de
messages.
titre dexemple, est propose dans le tableau 2 une bauche de
scnario denchanement de lensemble de ces 31 messages classs
dans leur ordre logique d'apparition.
H 3 598 4
Avis de livraison
Ordre
de paiement
Transporteur
Avis
de crdit
Banque
Figure 2 Scnario commercial avec bouclage logistique
et financier
Tableau 2 Scnario denchanement de messages

dans leur ordre dapparition
PARTIN
informations sur les intervenants
PROINQ
demande dinformation produit
PRICAT
catalogue et liste de prix
PRODAT
information produit
PRDRSC
information sur lorigine dun produit
QALITY
donnes sur la qualit dun produit
QLSPEC
caractristiques techniques
REQDOC
nouvelle information
REQOTE
appel doffres
QUOTES
rponse lappel doffres
SLSFCT
prvision des ventes
DELFOR
prvision de livraison
ORDERS
commande
OSTENQ
statut dune commande (demande)
OSTRPT
rponse concernant le statut dune commande
ORDCHG
modification de la commande
ORDRSP
rponse la commande
SLSRPT
tat des ventes
MSCONS
consommations enregistres sur compteurs
INVPRT
tat des stocks
RETANN
avis de retours
RETINS
instructions sur les retours
PRODEX
prt mutuel de produits
STATAC
position de compte
COASCU
rsum de compte commercial
CNTCND
conditions contractuelles
PRIHIS
historique de la fixation des prix
INVOIC
facture
COMDIS
litige ou demande davoir
JUPREQ
demande de paiement justifi
REMADV
dcompte (ou avis) de paiement
En fait, la plupart des communauts EDI utilisent seulement une

partie de ces messages, voire un seul au dpart (le message
commande ORDERS par exemple). En tout cas, ils permettent le
pilotage automatique du commerce lectronique B2B, par exemple
entre une application dadministration des ventes (chez lentreprise
fournisseur) et une application de gestion des achats (chez lentreprise cliente).
1.2 EDI classique : RVA et Edifact

pour les grands comptes
donneurs dordres
Partir des conditions initiales de dveloppement de lEDI na pas
quun but historique : il sagit didentifier notamment :
les acquis de lEDI traditionnel sauvegarder lanalyse des flux
de donnes lies aux processus mtiers ;
ses limites quInternet, le Web et XML vont permettre de
dpasser.
1.2.1 Prminence des grands comptes

L'EDI classique s'est implant partir de la ncessit des grands
comptes de rechercher des gains de productivit dans leurs activits
tertiaires. Automatiser des changes rptitifs est apparu comme le
moyen d'aller vers les 3 zros : zro papier, zro dlai, zro stock ,
auxquels on peut ajouter zro dfaut et zro litige, puisque viter la
ressaisie limine la plupart des erreurs.
La prminence des grands comptes donneurs d'ordre s'est
manifeste par le fait que leurs petits fournisseurs ont souvent t
contraints de suivre (sous peine d'tre drfrencs), alors que les
conditions d'un recours russi n'taient pas remplies pour eux : des
PME faisaient ainsi de l'EDIFax consistant afficher l'cran le
message Edifact reu occasionnellement et tenter de dchiffrer
tant bien que mal une suite de caractres incomprhensibles de
prime abord. Dans ce cas, l'EDI n'tait pas peru comme gagnantgagnant !
Rciproquement, l'EDI n'est pas non plus la panace pour le
donneur d'ordres qui, s'il est matre des spcifications, doit consacrer des moyens non ngligeables aider ses partenaires les intgrer. C'est rentable pour ses principaux fournisseurs qui il passe
de nombreuses commandes, cela l'est beaucoup moins pour les
nombreuses PME qui il ne passe commande qu'occasionnellement.
1.2.2 Intrt des RVA

Implant dans certains secteurs bien avant l'irruption d'Internet,
l'EDI s'est dvelopp en utilisant les RVA et son propre protocole de
communication X435 (ou Pedi). D'une part, l'EDI tait bien, en effet,
un rseau autour du donneur d'ordres, d'autre part ce dernier
n'avait pas forcment un service informatique ayant vocation
offrir tous les services ncessaires, notamment de scurit : bon
acheminement, archivage chez un tiers de confiance, etc.
Si les RVA ont un cot adapt aux services qu'ils rendent au
donneur d'ordres, les PME peroivent mal la justification d'un abonnement pour recevoir un message de temps en temps ! En plus de
la complexit du mapping, le cot du RVA a donc fait apparatre
l'EDI comme une technique peu adapte aux PME.
De plus, un mme fournisseur ayant plusieurs donneurs d'ordres
avec des systmes EDI diffrents pouvait parfaitement tre contraint
de se conformer tous, RVA compris ! Heureusement, dans plusieurs
secteurs, le regroupement des donneurs d'ordres en communaut
EDI a permis de favoriser un RVA (Allegro pour la grande distribution
par exemple), ce qui a permis de limiter les dgts pour les fournisseurs du secteur.
1.2.3 Bilan : 2 % seulement des PME en EDI

en 1998
Au total, selon une tude amricaine de 1998, si aux USA 98 %
des grandes entreprises pratiquaient l'EDI, ce n'tait le cas que de
2 % des PME. En France, la situation apparaissait un peu moins
contraste, mais le bilan est le mme : l'EDI classique (donc sans
compter les virements bancaires et rservations ariennes) ne
touche que quelque 30 000 entreprises et ne s'est pas dvelopp
dans le tissu des PME.
Cela, avec des exceptions d'autant plus remarquables : d'abord
celle de l'assurance accident automobile o le RVA d'ArvA a su
dvelopper un rseau EDI associant mutuelles, garagistes et
experts. De mme, des communauts EDI comme Editransport,
Gencod-EAN France (grande distribution) ou Galia (automobile) se
sont efforces de runir offreurs et utilisateurs de toute taille pour
unifier les spcifications des donneurs d'ordres de leur secteur et
ainsi aider les PME les prendre en compte.
En tout cas, avant l'explosion d'Internet, le recours l'EDI la fois
s'approfondissait et s'essoufflait :
l'EDI s'approfondissait lorsque l'arborescence descendait audessous du premier rang des fournisseurs des donneurs d'ordres
pour atteindre, dans le cur du mtier d'une filire comme l'automobile, le 2e voire le 3e rang de fournisseurs ; des relations EDI
s'tablissaient mme parfois dans le hors-production (pour des produits qui ne sont pas des pices dtaches, donc ne s'intgrant pas
dans le produit final) avec des fournisseurs de fournitures diverses ;
l'EDI devenait ractif lorsque la supply chain du fournisseur
vers le client tait prpare par une demand chain o les donnes sur les ventes taient remontes au plus vite pour l'ECR (Efficient Consumer Response) permettant d'orienter la production chez
les fournisseurs et ainsi viter les invendus dans l'intrt de toute la
filire ;
mais l'EDI officiel et normalis s'essoufflait en parvenant mal
s'articuler avec les PGI, Progiciels de Gestion Intgrs (ou ERP) se
rpandant y compris parmi les PME ;
mais en attendant Internet et le Web, l'EDI classique ne pouvait
disposer de catalogues on line et de places de march lectroniques
pour amorcer simplement la pompe du B2B, non pas seulement
pour des communauts dj constitues, mais pour un EDI ouvert
tous.
1.3 LEDI demain avec Internet,

Web et XML
La convivialit d'Internet et du Web contrastant avec les contraintes de l'EDI automatis ont fait dire qu'Internet allait remplacer l'EDI.
Srement pas : si par EDI on entend la mise niveau d'applications
d'entreprises diffrentes, on ne voit pas pourquoi cette fonction
perdrait de son importance avec le dveloppement du commerce
lectronique et de la socit de l'information, au contraire.
1.3.1 largissement de lEDI grce lEFI

et au Web EDI
Grce aux outils d'Internet, il y a une manire simple de rtablir
l'quilibre entre donneur d'ordres et PME : c'est le recours l'EFI
(change de Formulaire Informatis) o le donneur d'ordres envoie
bien un message de commande en EDI mais o le petit fournisseur
qui le reoit se contente de l'afficher l'cran pour le traiter manuellement. C'est bien de l'EDI au dpart mais pas l'arrive ( machine
to human ) si le fournisseur ne doit recevoir qu'une commande par
semaine. La condition de rptitivit n'tant pas remplie, les deux
autres conditions (mapping avec l'application interne et traitement
automatique) n'ont pas non plus l'tre chez le petit fournisseur.
H 3 598 5
Par contre l'EFI prsente l'avantage pour le donneur d'ordres de ne

pas ncessiter de systme diffrent de son systme EDI.
L'utilisation d'un site Web rend l'EFI encore plus convivial : dans
l'architecture Web EDI, l'utilisateur PME n'a besoin que d'un navigateur. Il va rcuprer sur le site Web du donneur d'ordres les formulaires, accompagns ventuellement de scripts ou d'appliquettes
Java. En fonction de son profil et de la relation qu'il souhaite tablir,
le formulaire adapt lui est propos, le cas chant, prrempli en
fonction de ses transactions prcdentes.
L'important est que ces deux scnarios se rejoignent et qu'une

rconciliation fructueuse pour tous intervienne entre les acquis de
l'EDI classique et les nouvelles fonctionnalits d'Internet et de XML.
C'est ce qui va tre examin maintenant.
2. Acquis et limites dEdifact
Lintrt du Web EDI rside dans le fait que la PME na pas besoin
dun environnement spcifique pour recevoir les messages EDI du
donneur dordres. Cest le Web EDI qui le fait pour lui de manire
personnalise. Un autre avantage est que le donneur dordres externalise son application EDI auprs du seul oprateur du Web EDI. Il
na plus besoin de prendre en compte les contraintes techniques,
logistiques et organisationnelles de tous ses petits partenaires
commerciaux et de la monte en charge du dploiement de son EDI
auprs des multiples PME auxquelles il n'a affaire qu'pisodiquement.
Edifact n'est pas n dans un environnement informatique (alors

que c'est le cas de XML, ce qui lui permettra sans doute d'absorber
plus facilement les volutions technologiques), mais comme outil
de simplification des procdures du commerce international. Cela
explique sans doute que les forces d'Edifact se situent plutt du ct
procdure, savoir analyse des processus mtiers et smantique
codifie des donnes affrentes, que du ct informatique, savoir
sa structure syntaxique qui n'a pas suivi l'volution technologique.
1.3.2 De nouvelles fonctionnalits trs attendues
Les procdures du commerce international devant tre les

mmes quel que soit le pays, les concepteurs d'Edifact ont voulu un
format unique pour chaque type de flux de donnes. Cette approche
quasi rglementaire a t la force initiale d'Edifact, mais s'en est
rvle ensuite tre le talon d'Achille.
Au lieu de remplacer l'EDI, bien au contraire, les outils d'Internet

vont pouvoir tre utiliss pour permettre enfin l'EDI classique de
sortir de son carcan d'origine pour irriguer tout le tissu des PME et
les raccorder au commerce lectronique mondial.
Tout d'abord, ces outils existent : des recommandations du W3C,
EDIINT et S/MIME pour des messages avec des images ou dessins
attachs, permettent l'acheminement de l'EDI en utilisant le protocole SMTP. Cela permet d'tablir des Extranets qui peuvent se
passer de RVA pour les communauts ayant les moyens de ne pas
externaliser les services dont elles ont besoin pour scuriser leurs
changes. De tels Extranets se branchent facilement sur les Intranets de chacun des partenaires et mme sur Internet pour la recherche de nouveaux partenaires.
Le Web et ses catalogues et rpertoires lectroniques avec les
outils XLink et XPointer de XML permettent, en temps rel, au
moment de la confection d'un message EDI de commande, par
exemple, de vrifier automatiquement qu'un article est toujours
rfrenc. D'une manire gnrale, Internet facilite l'extension d'un
EDI en temps rel alors que l'EDI classique tait surtout utilis en
batch, malgr dsormais une syntaxe et des rpertoires Edifact pour
l'EDI interactif.
De mme que les protocoles IP permettent d'articuler facilement
Extranet pour l'EDI avec Intranets et Internet, le mtalangage XML
apparat comme la glue , le liant, qui va assurer la liaison entre
tous les types d'applications et de donnes, y compris l'EDI : ainsi au
lieu d'tre marginalise avec son traducteur Edifact, la couche EDI
sera relie plus facilement aux autres couches du systme d'information de l'entreprise, le mapping restant toutefois ncessaire pour
l'automatisation des changes.
1.3.3 Deux scnarios qui doivent se rejoindre

Les applications EDI classiques ne vont pas pour autant disparatre, et devraient au contraire continuer se renforcer. Elles existent
et donnent satisfaction : pourquoi y toucher, surtout s'il a fallu beaucoup travailler pour les mettre en place et finir par recueillir un
retour sur investissement ? Ds lors que des guides d'utilisation de
messages bien adapts chaque processus mtier ont t mis au
point, les nouveaux arrivants sont plus facilement intgrs dans la
communaut. C'est le scnario de la continuit.
L'autre scnario, c'est celui de la constitution de nouveaux tissus
d'changes EDI, plus ouverts partir des liens s'tablissant sur
Internet, plus souples car directement en XML. C'est le scnario de
l'avenir que l'on commence voir en 1999 aux USA et qui va donc
arriver dans les premires annes 2000 en Europe.
H 3 598 6
2.1 LEDI classique standardis den haut

(top down)
2.1.1 Le langage Edifact

Voir le site Web dEdifact : http.//unece.org/cefact/
Le langage Edifact se compose de deux niveaux : le niveau
syntaxique et le niveau smantique. L'importance du niveau
smantique diffrencie Edifact des autres langages techniques ;
Edifact n'est pas seulement un mtalangage sans smantique
comme XML, il comporte toute la smantique ncessaire :
le niveau syntaxique permet d'organiser le discours grce
des sparateurs, par des regroupements des donnes en segments
et en messages, par des enchanements de messages en scnarios ;
ce niveau syntaxique, on gre aussi les lments de service
(metteur, destinataire, date et numro des messages, rfrence
aux applications qui les traitent), au moyen des segments de service
de la syntaxe ;
le niveau smantique permet de vhiculer dans les changes
un sens communment accept caractrisant les donnes changes. Ce sens est celui de la vie des affaires. Il s'exprime travers
des commandes, des adresses, une date, etc. Tous les besoins des
utilisateurs en nouvelles donnes font lobjet dune procdure
dintgration dans les rpertoires Edifact.
Les rpertoires d'information sont le point fort dEdifact. Ces
rpertoires, appels TDID, (Trade Data Interchange Directories), se
sont construits au fil des annes et sont le fruit d'un travail minemment important men par une multitude de groupes dans tous les
secteurs d'activit, groupes constitus dans le cadre de l'organisation mondiale mise en place par les Nations Unies, le Cefact et son
EWG (Edifact Working Group). Ces rpertoires sont mis jour deux
fois par an et se composent de cinq dictionnaires complmentaires.
Ils reprsentent la valeur ajoute smantique d'Edifact et constituent un rfrentiel partag par l'ensemble de la communaut des
utilisateurs mondiaux.
Cinq dictionnaires constituent donc un des acquis essentiels
d'Edifact.
2.1.1.1 Dictionnaire des donnes lmentaires
Le tableau, ci-dessous, extrait du rpertoire D99A (1re mise jour
de 1999 du rpertoire TDID), prsente les quatre types de donnes
dfinies par Edifact ; les qualifiants, les littraux, les donnes d'identification et les donnes codes :
Code
Prsentation de la donne
3035
QUALIFIANT DE LINTERVENANT
Desc : Code donnant une signification prcise au rle
dun intervenant
Repr : an..3
3036
NOM DE LINTERVENANT
Desc : Nom dun intervenant dans une transaction
Repr : an..35
3039
IDENTIFICATION DE LINTERVENANT
Desc : Code identifiant un intervenant dans une transaction
Note : Code dfini par un utilisateur ou un organisme.
Peut tre utilis en combinaison avec les donnes 1131
et 3055
Repr : an..35
3045
FORMAT DU NOM DE LINTERVENANT, EN CODE

Desc : Spcification de la reprsentation du nom de
lintervenant
Repr : an..3
Edifact ne pouvant grer l'ensemble des registres et nomenclatures du monde entier, chaque valeur de code de la donne 3055 identifie un gestionnaire de ces registres ou nomenclatures.
2.1.1.4 Dictionnaire des segments
Ci-dessous le segment DIM qui permet de renseigner une dimension ; il est constitu de la donne lmentaire 6145 et de la donne
composite C211. Cette dernire est elle-mme constitue des
donnes lmentaires 6411, 6168, 6140, 6008. Un segment est
toujours identifi par un code mnmotechnique pour anglophones
comme NAD (Name and ADdress) ou DIM (DIMension) dans l'exemple ci-dessous.
Pos
Code
DIM
Prsentation du segment
DIMENSIONS
Fonction : spcifier des dimensions
010
6145 QUALIFIANT DE DIMENSION
020
C211 DIMENSIONS
6411 Qualifiant de lunit de mesure
M an..3
Dans l'exemple ci-dessus, le qualifiant indique si l'intervenant est

acheteur, vendeur ou autre ; son nom l'identifie ensuite en toutes
lettres, puis de manire code (n Siret par exemple) ; enfin un code
prcise le format du nom (en fait deux squences possibles de nom,
initiales, nom de jeune fille, etc.).
M an..3
6168 Longueur
C n..15
6140 Largeur
C n..15
6008 Hauteur
C n..15
2.1.1.2 Dictionnaire des donnes composites

2.1.1.5 Dictionnaire des messages
L'exemple de composite ci-dessous associe la donne 3039 le
couple de donnes 1131-3055 qui permet de savoir que l'identifiant
mentionn par la donne 3039 est, par exemple, Siret gr par
l'Insee. Ce couple 1131-3055 est utilis quasi systmatiquement
dans les composites.
Pos
Code Prsentation de la donne composite

C082 DTAILS DE LIDENTIFICATION DUN INTERVENANT
Desc : Identification dun intervenant dans la transcription par un code.
010
3039 Identification de lintervenant
C an..35
020
1131 Qualifiant dune liste de codes
C an..3
030 30355 Organisme responsable dune liste de

codes, en code
C an..3
2.1.1.3 Dictionnaire des listes de codes

Ils sagit des codes de la donne 3055 :
Code
3055
Prsentation de la donne code et valeur des codes

ORGANISME RESPONSABLE DE LA LISTE DE CODES
(EN CODE)
Desc : Code dsignant lorganisme responsable dune liste
de codes
Repr : an..3
3 IATA, International Air Transport Association
5 ISO, International Organization for Standardization
9 EAN, European Article Number association
64 Edifrance
107 INSEE
Quelques-uns des messages Edifact ont t cits plus haut pour le

scnario du commerce lectronique. Pour tous les messages, un
boilerplate (matrice) permet d'en saisir la structure, les enchanements et les rptitions (par exemple, toutes les donnes mentionner pour chaque article command). Le boilerplate est complt par
un diagramme de branchement prcisant les enchanements et
rptitions possibles des segments et groupes de segments.
Exemple de boilerplate du message ORDERS
Dbut du boilerplate du message ORDERS (commande)
10
UNH EN-TETE DE MESSAGE

Segment de service dbutant et identifiant de faon unique un
message.
Le code du type de message pour le message Commande est
ORDERS.
Les messages Commande conformes ce document doivent
contenir les donnes suivantes dans la composite S009 du segment
UNH :
0065 ORDERS
0052 D
0054 96A
0051 UN
20 BGM DEBUT DE MESSAGE
Segment par lequel l'metteur doit identifier de faon unique la
commande par son type et son numro et, lorsque ncessaire, sa
fonction.
30
DTM DATE OU HEURE OU PERIODE

Segment indiquant les dates gnrales et, le cas chant, les
heures relatives l'ensemble du message. Ce segment doit apparatre au moins une fois pour identifier la date de la commande. Ce
segment DTM peut tre utilis, titre d'exemple, pour indiquer les
dlais qui s'appliquent l'ensemble de la Commande, et, si aucune
prvision n'est prcise, la date de livraison.
Le segment Date ou heure ou priode l'intrieur d'autres groupes de segments doit tre utilis chaque fois qu'il est logique de
H 3 598 7
rattacher la date ou l'heure ou la priode une autre donne prcise. Par exemple, la date d'chance du paiement est indique
l'intrieur du Groupe de segments dclench par le segment PAT.
40
PAI
INSTRUCTIONS DE PAIEMENT
Segment demandant ou confirmant les conditions de paiement,
de garantie et la mthode de paiement destines l'ensemble de la
commande. Ce segment peut servir titre d'exemple prciser
qu'un crdit documentaire sera utilis.
50
ALI
INFORMATIONS COMPLEMENTAIRES
Segment indiquant les conditions particulires applicables
l'ensemble de la commande en raison de l'origine des marchandises, d'une prfrence douanire ou d'autres facteurs commerciaux.
60
IMD
DESCRIPTION DE L'ARTICLE
Segment donnant une description commune toutes les lignes
articles de la commande.
70
FTX
TEXTE EN FORMAT LIBRE
Segment comportant des informations textuelles, en code ou en
clair (en ASCII 8 bits, la donne de syntaxe 0001 dans le segment
UNB de dbut dinterchange prcisant par exemple avec le code
UNOC quil sagit de franais accentu, avec le code UNOA quil
sagit de latin1 etc.), utilis lorsqu'un complment d'informations
est ncessaire mais ne peut tre servi dans d'autres segments.
Dans les changes d'ordinateur ordinateur, ce texte obligera
normalement le rcepteur traiter ce segment par des procds
manuels.
80
Gr.1
GROUPE DE SEGMENTS 1
Groupe de segments destin indiquer les rfrences se rapportant l'ensemble du message, par exemple, numro de contrat,
numro de licence d'importation ou d'exportation, numro d'avis
d'expdition, et lorsque ncessaire, numro de rservation.
90
RFF
REFERENCE
Segment identifiant la rfrence par son numro et, s'il y a lieu,

par un numro d'une ligne d'un document.
100
DTM
DATE OU HEURE OU PERIODE
Segment indiquant la date/heure relative la rfrence.

110
Gr.2
NAD
NOM ET ADRESSE
Segment identifiant le nom et l'adresse des intervenants, en code

ou en clair, et les fonctions correspondantes, applicables la
commande.
L'identification des intervenants auprs du vendeur et de l'acheteur est obligatoire pour le message de commande. Il est recommand, chaque fois que possible, de n'indiquer que la forme en
code de l'identification de l'intervenant.
Par exemple le vendeur et l'acheteur se connaissant, seule l'identification en code est requise, mais l'adresse du destinataire ou du
vendeur pouvant varier, il conviendrait alors de la prciser clairement, de prfrence sous forme structure.
130
LOC
IDENTIFICATION D'UN LIEU OU EMPLACEMENT
Segment apportant un complment d'informations sur la localisation particulire de l'intervenant dsign dans le segment NAD, par
exemple, numro d'un site ou btiment intrieur.
140
FII
IDENTIFICATION FINANCIERE
Segment identifiant l'tablissement financier, (par exemple, la

banque) et les numros de compte correspondants l'intention du
vendeur, de l'acheteur, et, lorsque ncessaire, d'autres intervenants.
L'acheteur peut, par exemple, offrir le choix entre plusieurs tablissements financiers des fins de dbit direct.
930
Partie du message ORDERS consacr chaque article

Gr.25
940
LIN
LIGNE ARTICLE
Segment identifiant la ligne article par le numro de ligne et le
niveau de configuration et, en outre, le produit ou le service
commands. Les autres numros d'identification du produit, par
exemple, le numro de produit de l'acheteur, etc. peuvent tre indiqus dans le segment PIA qui suit.
950
PIA
IDENTIFICATION COMPLEMENTAIRE DU PRODUIT
Segment indiquant ou une identification complmentaire au
produit prcis dans le segment LIN (par exemple, le numro du
Systme Harmonis Douanier) ou permettant d'identifier tout
produit de remplacement.
960
IMD
DESCRIPTION DE L'ARTICLE
Segment destin dcrire le produit ou le service faisant l'objet
de la commande aussi bien que les caractristiques du produit. Ce
segment doit tre utilis pour des produits qui ne peuvent tre totalement identifis par un code de produit ou un numro d'article.
970
MEA MESURES
Segment permettant d'indiquer les mesures physiques de l'article
command lorsque ces informations sont indispensables l'identification complte du produit. Toute mesure doit faire rfrence au
produit dans sa forme non emballe, par exemple, paisseur de la
pellicule en matire plastique, longueur, poids, etc.
980
QTY QUANTITE
Segment identifiant les quantits du produit, par exemple, la
quantit commande.
Exemple de diagramme de branchement du message INVOIC
Le tableau 3 dcrit les enchanements et rptitions des segments
et groupes de segments du message INVOIC.
2.1.2 Une normalisation illusoire

pour les utilisateurs de lEDI top down
Groupe de segments identifiant les intervenants et comportant

les informations associes.
120
Groupe de segments donnant les informations dtailles sur les

diffrents articles commands. Ce groupe de segments doit tre
rpt au moins une fois pour donner les informations dtailles sur
une ligne article secondaire.
H 3 598 8
Ne de la ncessit de fusionner des formats sectoriels et nationaux, la norme Edifact s'est voulue l'enveloppe de tous les besoins
qui y taient rassembls. D'o le ct complexe de certains messages UNSM (United Nations Standardised Message) comme
ORDERS ou INVOIC, messages les plus utiliss dans des conditions
rglementaires ou de processus mtiers trs diffrents en provenance du monde entier.
De ce fait, le message type n'est jamais utilis dans sa totalit : les
donnes relatives chaque rglementation ou pratique professionnelle particulire ne sont que conditionnelles, et chacun n'utilise
qu'un sous-ensemble, (le subset), du message le concernant, en
plus des parties obligatoires du message. Consquence : d'un pays
l'autre ou dans un pays, d'un secteur l'autre, les subsets ne sont
pas les mmes et ne sont donc pas interoprables.
De plus, pour un mme subset, des groupes d'entreprises n'ayant
pas tout fait les mmes pratiques professionnelles n'utiliseront,
pour une mme donne, que les codes correspondant ces pratiques : elles auront donc des guides d'utilisation de messages (qui
rassemblent les conventions quant l'emploi de chaque code dans
chaque cas de business) qui, tant en partie incompatibles, ne
seront pas, eux non plus, interoprables.
Au total, la norme Edifact ne garantit en aucune faon dans la
pratique l'interoprabilit entre groupes d'utilisateurs, ce qui n'a
rien d'tonnant ds lors que les pratiques professionnelles ne sont
pas les mmes. Pourquoi avoir alors impos les messages types
UNSM s'ils aboutissent concrtement des implmentations
incompatibles ? La rponse est que cela a garanti un march
mondial aux offreurs de traducteurs Edifact qui vrifient la conformation aux messages types : le traducteur peut vrifier tout subset !
Mais pour les utilisateurs, tout rapprochement de communauts

EDI oblige fusionner les subsets et les guides d'utilisation :
l'approche normalisatrice top down est donc illusoire et on est bien
oblig de revenir un processus bottom up de proximit.
(0)
Tableau 3 Dbut du diagramme de branchement

du message INVOIC
ISO
Organisation
internationale
de
normalisation
ISO 9735
ISO 7372
Niveau Edifact
UNH
M 1
BGM
M 1
PAI
C 1
DTM
M 35
IMD
C 1
ALI
C 5
FTX
C 10
Gr. 1
C 10
Gr. 2
C 20
RFF
M 1
NAD
M 1
International
EN 29735
EBES
European Board
for EDIFACT
Standardization
CEN/ISSS
Comit europen
de normalisation
0
Nations-Unies
CEE/ONU
(CEFACT)
R
Rgional
gional
NF EN 29735
AFNOR
COS ICT
EDIFRANCE
National
Figure 3 Un processus lourd de mise jour

Gr. 3
C 9999
2
Lecture de haut en bas

et de gauche droite
DTM
C 5
3 Dbut du message facture INVOIC
LOC
C 25
FII
C 5
RFF
M 1
DTM
C 5
Conventions de notation
M = prsence obligatoire (mandatory), C = prsence facultative
(conditionnal) ; M 1 signifie que le segment doit tre prsent, mais
une seule fois, M 35 quil doit tre prsent au moins une fois mais
peut mme tre rpt jusqu 35 fois, C 5 que sa prsence nest
pas obligatoire mais quil peut tre prsent et mme rpt jusqu
5 fois.
Le niveau 0 est rserv aux segments isols napparaissant quune
fois, le niveau 1 aux autres (groupes de segments ou segments isols apparaissant plusieurs fois).
Quand un segment suit un autre indpendamment de lui (le second
peut tre prsent mme si le premier ne lest pas) il est plac au
mme niveau sa droite. Quand un segment dpend dun autre (le
second ne peut tre prsent si le premier ne lest pas) il est plac
sous lui au niveau n +1.
Exemple de lecture sur le diagramme ci-dessus
Gr.1 C 10 RFF M 1 DTM C 5
signifie que le groupe de segment
n1, compos de deux segments, est facultatif mais peut tre rpt
10 fois ; chaque occurrence du groupe, le segment RFF est obligatoire et ne peut tre rpt, par contre le segment DTM est facultatif
mais peut tre rpt jusqu' 5 fois.
Process du message
Le logiciel EDI compose ou interprte les segments d'un message
dans l'ordre suivant :
de haut en bas quand c'est possible : dans l'exemple du Gr.1
ci-dessus, du segment RFF (rfrence) de niveau 1 il passe au segment DTM (date de cette rfrence) en baissant d'un niveau dans le
Groupe 1 puisque ce segment DTM de niveau 2 ne peut tre interprt qu'en fonction du segment RFF prcdent dans la mme
occurrence du Gr.1 ;
de gauche droite : toujours dans l'exemple ci-dessus, aprs
le DTM, on remonte au RFF pour aller lire droite dans le Groupe 2
le segment NAD (nom et adresse), etc.
Lecture du dbut du message INVOIC ci-dessus
Au total, le message sera interprt dans l'ordre suivant en supposant que les segments et groupes sont tous prsents une seule fois
y compris les conditionnels : UNH, BGM, DTM, PAI, ALI, IMD, FTX,
RFF, DTM, NAD, LOC, FII, RFF, DTM.
2.1.3 Un processus de mise jour lourd

L'aspect top down de l'EDI normalis en Edifact se manifeste
surtout dans sa procdure de mise jour dcrite dans la figure 3.
Le processus de mise jour des rpertoires Edifact part bien des
besoins ressentis par les utilisateurs : nouveau message ou seulement nouvelle donne ou mme nouveau code pour une donne
existante. Mais ce besoin ne peut tre satisfait immdiatement : il
faut qu'il soit examin et valid par toutes les instances nationales,
rgionales et internationales avant d'tre intgr dans une nouvelle
version du rpertoire Edifact concern.
Cette validation n'est pas toujours simple : les organismes
sociaux franais ont mis deux ans convaincre les traders
australiens et amricains que le segment NAD (nom et adresse pour
la livraison d'une commande) n'tait pas suffisant pour dcrire les
ayants droit d'un allocataire. L'approche top down imposait un seul
segment pour la fonction d'adressage. A l'inverse, on peut trouver
encore dans les listes de codes des valeurs diffrentes ayant pourtant le mme libell, tout simplement parce que des secteurs diffrents en avaient fait la demande et voulaient avoir leur code bien
eux, (ce qui, dailleurs, tait la ngation mme de l'approche top
down).
Cela tant dit, rien n'empche un groupe d'utilisateurs de convenir d'utiliser les codes existants en les dtournant de leur propos
initial : le traducteur ne voyant passer que les codes et non les libells n'y verra que du feu et le mapping avec les applications se fera
en fonction des significations convenues et non des libells officiels !
2.2 Derniers progrs

L'instance du Cefact-ONU responsable de la mise jour bisannuelle des rpertoires Edifact est l'EWG (Edifact Working Group) qui
est prsid dbut 2001 par Pierre Georget, directeur technique de
Gencod-EAN France et Prsident d'Edifrance. L'assistance aux
runions de l'EWG a tendance dcrotre au fur et mesure que les
demandes de modification (DMR) des rpertoires Edifact se rarfient.
Cela peut tre interprt positivement comme l'indice que les
communauts EDI ont maintenant les messages Edifact qui leur
conviennent et qu'elles se consacrent dsormais leur implmentation. D'autant que les experts EDI ont fait aboutir des amliorations,
non ngligeables :
Simpledi (ou EDI light en France), pour les relations avec les
PME ;
H 3 598 9
EDI interactif, pour les besoins de secteurs comme le tourisme

(rservations) ou la sant ;
EDI multimdia en raison de la prolifration des donnes de ce
type ;
EDI scuris avec messages spcialiss, y compris en Extranet ;
EDI ouvert, qui fait l'objet d'une norme ISO et l'EDI orient
objet (OO EDI).
2.2.1 La version 4 de la syntaxe : trop tard ?

Certaines des amliorations de ces outils Edifact sont incluses
dans la dernire version de la syntaxe Edifact, qui est devenue la
norme en 2000 (tableau 4) : EDI interactif, EDI multimdia et EDI
scuris.
(0)
Tableau 4 Structure de la version 4 de la norme ISO 9735

(syntaxe Edifact)
Partie 1
Rgles communes
Partie 2
Rgles spcifiques aux changes EDI batch
Partie 3
Rgles spcifiques aux changes EDI interactifs
Partie 4
Message de compte rendu syntaxique et de service

(CONTRL)
Partie 5
Rgles de scurit batch (authenticit, intgrit, nonrpudiation dorigine)
Partie 6
Message dauthentification et daccus de rception

scuris (AUTACK)
Partie 7
Rgles de scurit batch (confidentialit)
Partie 8
Donnes multimdia associes ( un message)
Partie 9
Message de gestion des cls et certificats de scurit

(KEYMAN)
Au total, bien qu'un peu tardive, cette opration de vrification de

la qualit de la smantique Edifact est fondamentale car elle facilitera la reprise de la smantique Edifact dans les langages venir de
l'electronic business en XML.
2.2.3 La modlisation obligatoire

Depuis le 1er avril 2000, l'EWG n'examinera une demande de
nouveau message que si ce message se rfre un modle utilisant
la notation UML. Auparavant, seuls le secteur social dans le cadre
du projet TESS, la finance autour de Swift, l'industrie automobile
sous le couvert d'Odette (communaut EDI europenne) et le
secteur de la Sant (TC 251 europen et HL7 amricain) avaient
modlis leurs changes de donnes. Ces secteurs ayant retenu
cette approche modlisation et ayant dploy un EDI en Edifact
sont dj prts pour un passage XML ; l'investissement dans
l'expression de leur modle d'change d'information va en effet tre
directement rutilisable dans un contexte XML.
Il est, en effet, convenu de dire que la modlisation est la seule
rponse possible la complexit et la variabilit croissante des
relations. Elle seule permettrait de dfinir des rgles pour une interoprabilit relle et prenne entre, non seulement des systmes
d'informations, mais des process de production et en gnral d'activits diverses.
La modlisation exige de dfinir le primtre du systme
d'change, la smantique des changes, en allant jusqu' des objets
mtier, les scnarios des changes, les rgles de gestion, et elle
contraint les partenaires la clarification. Le modle dfinit le rfrentiel smantique commun aux partenaires pour leurs changes,
indpendant du langage utilis.
2.3 Que reprendre dEdifact ?
Partie 10 Rgles de scurit pour lEDI interactif
Il est dommage de constater que cette version 4 de la syntaxe

Edifact contient tout ce qu'il faut pour des changes multimdia
interactifs et scuriss sur Internet, mais qu'elle ne sera sans doute
pas mise en uvre en raison de l'irruption de XML. Mais mme si
cette version de la syntaxe Edifact, qui sera sans doute la dernire,
ne devait tre que peu implmente, on peut penser que les utilisateurs s'en serviront pour vrifier que les nouvelles fonctions qu'elle
assure sont bien reprises dans l'environnements XML.
2.2.2 Contrle de qualit de la smantique

Le monde Edifact s'est rendu compte que, plus que sa syntaxe,
c'est sa smantique, donnes et codes arrangs en messages, qui
cristallise l'acquis de son analyse des procdures interentreprises,
des pratiques professionnelles et des langages mtiers. Une 2e
opration de quality control a donc t entreprise concernant
cette smantique, la prcdente remontant 1989-1990.
Pour les noms de donnes, il s'agit de vrifier leur pertinence en
vitant les imprcisions et les jargons sectoriels. Toute donne,
comme chacune de ses valeurs codes, tant caractrise par un
nom et une courte description, il est toujours possible d'associer un
nom exprim en termes gnraux et une description plus circonstancie. Cela permettra de reprer des codes n'ayant pas t attribus la bonne donne.
Concernant les codes et leurs libells, il s'agit d'liminer les codes
diffrents ayant exactement le mme libell, de remplacer les
descriptions self explanatory ou description to be provided
par une relle description, et de vrifier que les libells existants
sont toujours revendiqus par au moins un groupe sectoriel d'utilisateurs.
H 3 598 10
Edifact provenant dune analyse des procdures interentreprises

ou interorganisations et des flux de donnes qu'elles entranent, il
n'y a donc rien de surprenant ce que l'on trouve sa richesse dans
les rsultats de cette analyse, c'est--dire d'abord dans la smantique, donnes et codes. Chacun des messages Edifact est aussi le
rsultat de cette analyse : mais tant constitu de l'enveloppe des
besoins des utilisateurs, chaque utilisateur le trouve redondant,
moins de n'en retenir que les segments obligatoires comme dans
les subsets EDI light.
2.3.1 Analyse empirique des procdures dchange

et de leurs flux de donnes
Les groupes Edifact ont conu non seulement une norme, syntaxe
et dictionnaire de donnes, mais aussi des mthodes, des accords
d'interchange et des modles d'affaire. partir de l, c'est tout un
monde Edifact qui s'est construit, avec ses offreurs, ses services
valeur ajoute, son organisation de normalisation associant les
grands prescripteurs internationaux de procdures comme les
douanes. Si cette mthode a eu le mrite de garantir l'existence de
solutions compltes, acceptes au niveau international, elle explique aussi l'isolement progressif dans lequel se sont retrouvs les
spcialistes Edifact face aux autres acteurs des systmes d'information et l'explosion d'Internet.
LEDI est d'abord un effort d'organisation consistant analyser les
procdures d'changes et leurs flux de donnes pour les rationaliser, les codifier et en dduire une automatisation. C'est l que rside
sa valeur ajoute, et les outils informatiques de cette automatisation
ne sont bien que des outils : on peut changer d'outils, passer
d'Edifact-X435-RVA XML-IP-Web tout en prservant la fonction de
l'EDI.
Autrement dit, c'est tout le savoir-faire accumul des groupes

sectoriels nationaux, europens et internationaux qui est garder
prcieusement. Leur mmoire est grave dans leurs comptes
rendus de runion, dans les justificatifs de demandes de modification de messages Edifact, etc. chacun de prserver cette riche
mmoire pour ne pas avoir tout rinventer (en particulier les
guides d'utilisation de messages et la smantique).
2.3.2 Guides dutilisation de messages, donnes

et listes de codes
Le guide d'utilisation d'un message matrialise, dans un pays,
dans un secteur, dans un scnario donn, toute l'exprience acquise
ncessaire une bonne utilisation de ce message : dans chacune de
ses occurrences, il dcline en filigrane d'une part les aspects rglementaires et d'autre part les conventions des partenaires partant du
savoir-faire accumul. C'est vritablement le relais que doit transmettre l'EDI classique pour repartir plus loin grce aux nouvelles
technologies.
Il est noter qu'un guide d'utilisation de message, partant des
besoins concrets d'une communaut d'utilisateurs tait corset
par le ct top down d'Edifact interdisant la moindre modification
immdiate des rpertoires. Il s'accommodera parfaitement du ct
bottom up eXtensible de XML.
Les rpertoires de donnes et de leurs codes reprsentent les
briques lmentaires de l'EDI et de ses guides d'utilisation de
messages : en principe, chaque cas de figure de business pouvant
se rencontrer dans un pays ou un secteur y est prvu. Ils rassemblent le travail de trs nombreux groupes d'utilisateurs travaillant
dans chaque pays et coordonns l'chelle internationale. Ces
rpertoires sont le seul corpus smantique la fois transnational et
intersectoriel existant, et reprsentent un capital impressionnant.
Les informations smantiques gnrales et la reprsentation de flux
d'change qu'ils contiennent, bien qu'tant formalises en fonction
de la syntaxe Edifact, sont parfaitement transposables dans une
autre notation.
Le contrle en cours de la qualit de ces rpertoires permet de les
mettre au cur de l'exercice de ebXML, initiative commune au
Cefact-ONU et Oasis (offreurs XML) visant dfinir au plus tard en
2001 un framework rendant interoprables les langages XML de
l'electronic business. Les rpertoires Edifact y sont tudis dans le
groupe d'ebXML intitul Core components.
Les rgles fondamentales sont simples :

tout lment est encadr par une balise de dbut et une balise
de fin ;
les lments peuvent s'imbriquer mais jamais se chevaucher ;
la structure fondamentale de tout document XML est donc un
arbre, et tout document est contenu dans un lment racine unique,
qui contient tous les autres.
noter que le grand progrs de XML par rapport HTML a t de
librer les balises des attributs de formatage, donc de sparer
contenu et prsentation, ce qui rend XML tout fait adapt l'EDI.
Voir la recommandation du W3C : http://www.w3.org/TR/1998/
REC-xml-19980210
Il faut bien voir que XML n'est pas limit au Web, mme s'il en est
originaire : sa souplesse lui permet d'irriguer tout le systme
d'information des entreprises dont il deviendra le format standard
structurant chaque type d'application, y compris le WAP des mobiles et du m-commerce. L'EDI tant le format d'change automatis
entre applications a donc tout gagner tre lui-mme en XML.
Voir les sites dinformations sur le XML :
http://www.xml.com
http://www.xmlfr.org
3.1 DTD-schmas et namespaces pour

eXtensibility avec reusability
L'expression DTD-schma est employe comme raccourci visant
rappeler que dbut 2001, les schmas, mme recommands par le
W3C, nauront pas encore remplac les DTD en vigueur. Dautant
que des discussions difficiles risquent de durer : faut-il pouvoir
dcrire toutes les contraintes et caractristiques d'un lment au
risque de faire trop compliqu ou faut-il une version simplifie ? Les
propositions en prsence la mi-2000 sont :
DCD (Data Content Description) de Microsoft et IBM (succdant XML-Data) ;
DDML (Document Description Markup Language ou Xschema)
du groupe de travail du W3C ;
SOX (Schema for Object-oriented XML).
Voir le registre de DTD-schmas : http://www.xml.org/registry
3.1.1 Des schmas comme messages cadres
3. Approche XML partant

de lutilisateur (bottom up)
Un document XML qui fait rfrence une dfinition externe de

ses balises et structures pourra le faire bientt grce des schmas.
Proposs d'abord par Microsoft, ils reprsentent une volution
importante pour l'utilisation d'XML.
Dvelopp par le W3C (World Wide Web Consortium dirig

notamment par l'INRIA), XML, eXtensible Markup Language, est un
mtalangage de description et d'change sur le Web de donnes
structures : on voit immdiatement que l'EDI relve de XML ! Issu
comme HTML de SGML, qui est une norme trs ancienne de lISO,
XML structure le document ou fichier transmettre par des balises
qui encadrent chacun des lments du document.
Les schmas sont particulirement importants pour les EDI. Les

schmas permettent, en particulier, de prciser, pour une donne,
non seulement son type, mais galement ses bornes ou d'autres
informations sur ses valeurs. Ils permettent donc des validations
automatiques lors de l'analyse des messages et documents par les
parseurs, vitant de passer des donnes aberrantes aux applications. En fait, les schmas vont permettre d'intgrer des contraintes sur les donnes qui taient celles figurant dans les dictionnaires
de donnes, dont en particulier ceux d'Edifact.
Voir le site du W3C : http://www.w3.org/xml

La dfinition des balises et l'organisation de la structure, si ncessaire, sont externes au document et prcises pralablement dans
une dfinition type ; Document Type Definition (DTD), ou schma.
Les balises indiquent le nom de l'lment et fournissent des informations complmentaires dans des attributs, comme des valeurs,
des renvois des rfrences, etc.
XML n'tant par lui-mme qu'un mtalangage, le choix des noms
et dfinitions des balises est libre : tout ensemble de balises et de
contraintes constitue en fait un langage XML sous rserve qu'il
respecte des rgles sur les caractres, etc.
Les schmas sont de plus les briques qui vont permettre de crer
rapidement des messages et des documents, d'autant qu'ils sont
crits en XML et supportent l'hritage. Il est donc possible, en utilisant les outils XML qui se diffusent, d'assembler rapidement des
schmas pour en crer de nouveaux, et de se rfrer des ensembles de schmas pour crer des messages.
Les schmas permettent enfin la constitution de rpertoires qui
comprennent les dictionnaires de donnes en mentionnant toute la
structure propre telle ou telle donne. Par rapport Edifact, ils
reprsentent un concept qui regroupe les donnes, les segments et
les messages.
H 3 598 11
Le schma XML, qui est prsent dans lexemple 1, permet de

dfinir une structure de rfrence du secteur automobile pour
l'change d'une commande. Le document XML correspondant
une commande respectant la structure et les caractristiques de ce
schma pour tre valid est prsent dans lexemple 2.
Exemple 1 : schma XML
noter que certains termes communs, Adresse, Commentaire,
Items, sont prcds d'un prfixe cm:. Ce prfixe permet de prciser
que les termes associs appartiennent un dictionnaire ou un rpertoire se trouvant sur un serveur dont l'adresse est mentionne dans les
premires lignes du schma (xmlns=:cm=http://www.automobile.fr/
cmmd). Cette caractristique recouvre la notion de namespace
(espace nominal) aborde ci-dessous.
On remarque dans le schma l'embotement des dfinitions : Commande est du type Commandetype, qui est dfini ensuite et contient
diffrents lments. L'un d'eux, Adresse, renvoie une dfinition place aprs, etc. Dans d'autres cas, le type ne renvoie pas une dfinition mais un type de donne standard : string (chane de caractres),
dcimal, etc.
Premire ligne : targetNamespace prcise l'adresse de l'URI du
namespace en relation avec le schma en cours.
Deuxime ligne : dclaration du domaine de nom sans prfixe, il
constitue le domaine par dfaut associ tout les lments du
document dont le nom n'est pas prfix.
Troisime ligne : dfinition du prfixe cm permettant d'associer
aux lments du schma prfixs par cm l'adresse du namespace
mentionn.
<schema targetNamespace="http://www.automobile.fr/namespace/cmmd"
wmins="http://www.automobile.org/xmischema-commande-2000-001"
wmins:com="http://www.automobile.fr/namespace/cmmd">
Exemple 2 : document XML

<?xml version 1.0 ?>
<Commande DateCommande="2000-05-20"xmins="http://www.canope.com/cmmd">
<Client type:"FR">
<Nom>Emile Dupond</Nom>
<Rue>12,quai Andr Citroen</Rue>
<Codepostal>75015</Codepostal>
<Ville>Paris</Ville>
<Pays>FR</Pays>
</Client>
<DateLivraison>1999-05-25</DateLivraison>
<Commentaire>Me livrer rapidement, ma voiture est en
panne</Commentaire>
<Items>
<Item>
<NumroProduit="PSA-676-123-002">
<NomProduit>Carter a huile</NomProduit>
<Quantite>1</Quantite>
<Prix>2 345,50</Prix>
<Commentaire>Confirmez-moi la disponibilite</
Commentaire>
</Item>
<NumeroProduit="PSA-523-178-108">
<NomProduit>Filtre a huile</NomProduit>
<Quantite>1</Quantite>
<Prix>310,00</Prix>
</Item>
</Items>
</Commande>
<element name="commande"type="cm:Commandetype"/>
<element name="Commentaire"type="string"/>
<type name="Commandetype">
<element name="Client"type="cm:Adresse"/>
<element name="Datelivraison"type="date"/>
<element ref="cm:Commentaire"minoOccurs="O"/>
<element name="Items"type="cm:Items"/>
<attribute name="DateCommande"type="date"/>
</type>
<type name="Adresse">
<element name="Nom"type="string"/>
<element name="Rue"type="string"/>
<element name="Codepostal"type="integer"/>
<element name="Ville"type="string"/>
<element name="Pays"type="string"/>
<attribute name="type"type="string"/>
</type>
<type name="Items">
<element name=Item"minOccurs="O"maxOccurs="*"/>
<type>
<element name="NomProduit"type="string"/>
<element name="Quantite">
<datatype source="integer"/>
<minExclusive value="O"/>
</datatype>
</element>
<element name="Prix"type="decimal"/>
<element ref="po:Commentaire"minOccurs="O"/>
<attribute name="DateCommande"type="date"/>
</type>
</element>
</type>
</schema>
H 3 598 12
3.1.2 Les namespaces (espace nominal)

comme rpertoires de donnes rutilisables
C'est avec les schmas qu'est introduit un apport important, celui
du namespace XML. Les namespaces sont un langage de dfinition
et d'enregistrement de la smantique crit en syntaxe XML. Un
namespace est un rpertoire de noms utilisables comme noms
d'lment ou d'attribut dans un document XML. Le namespace
identifie des noms d'lments utiliss de faon unique sur le Web
pour viter les conflits de terminologie entre des lments de nom
identique.
Les namespaces sont fondamentaux pour l'EDI puisqu'ils permettent de pallier le danger de Tour de Babel que reprsente le
caractre eXtensible de XML : chacun peut se btir son DTD-schma
avec ses propres balises en rutilisant les lments dj dfinis
dans des rpertoires virtuels. Il reconstitue ainsi potentiellement le
rpertoire top down d'Edifact avec une alimentation bottom up,
partant des utilisateurs.
L'approche de la norme Edifact est, en effet, de normaliser les
dictionnaires de faon trs stricte. Edifact n'est pas qu'une syntaxe,
c'est un ensemble complet qui comprend des jeux de messages et
des dictionnaires de donnes et de leurs listes de codes. Cette
approche correspondait au monde rglementaire de l'ONU : elle
n'est absolument pas envisageable dans le bourgeonnement actuel
du commerce lectronique et des rseaux. Pourtant, la rigueur reste
ncessaire : l'automatisation EDI des changes entre systmes
informatiques suppose bien de se rfrer de faon univoque un
mme dictionnaire ou aux mmes codes.
Avec les namespaces, la rponse du W3C est de faire systmatiquement appel aux rfrences sur le rseau, en fonction du
contexte : il est toujours possible, pour toute structure rfre en
XML, de prciser qu'elle appartient un namespace particulier. En
outre, plusieurs namespaces peuvent tre utiliss dans un mme
document, rfrant ainsi plusieurs domaines smantiques. La
dmarche reste bottom up, des communauts d'utilisateurs
pouvant utiliser des langages gnraux et adapter un certain

nombre d'lments pour leurs besoins propres.
3.2.1 Outils de prsentation et de transformation
L'utilisation des namespaces va tre essentielle pour rcuprer

les dictionnaires multiples qui peuvent exister dans un domaine, et
ceci sera particulirement important dans la prochaine priode de
transition o plusieurs dictionnaires d'organismes, de groupements
et de communauts seront utiliss simultanment. L'utilisation des
namespaces indiquant quel dictionnaire est utilis permettra aux
outils XML d'aller y chercher une information si ncessaire comme
le montre lexemple 3.
L'EDI classique, conu uniquement machine to machine ne se

prte pas un affichage l'cran, pourtant souvent utile. XML le
permet grce une sparation stricte entre :
la structure : la dfinition de la structure d'un document (le
DTD-schma) ;
le contenu : la description du contenu d'une occurrence du
document (le message XML) ;
la prsentation : la mise en page du document, grce une
feuille de style.
Exemple 3 :
xmins:cm="http://www.automobile.fr/namespace/cmmd"
<element name="Commande"type="cm:Commandetype"/>
<element name="Client"type="cm:adresse"/>
xmins:cm : dfinition dun prfixe contenant le nom du prfixe
de lespace nominal (cm) utilis pour associer les lments de
cmmd (commande) cet espace ;
http://www.automobile.fr/namespace/cmmd :
nom
de
lespace nominal rfrenant le dictionnaire qui dfinit llment
commande.
Une feuille de style dfinit un mcanisme de prsentation d'une

page d'information sur le Web. Il est possible l'aide d'une feuille
de style de spcifier l'aspect visuel d'un document. Aprs le langage
CSS, (Cascading Style Sheets), le W3C dveloppe actuellement le
langage XSL, (eXtensible Style sheets Language) qui est plus ambitieux.
XML s'entourant d'outils rseaux, un namespace est, en effet,

identifi par une ressource :
soit un URI, Universal Resource Identifier ;
soit un URL, Uniform Resource Locator ;
soit un URN, Uniform Resource Number (sans que soit encore
bien dfini ce que l'on trouve derrire cette ressource).
Voir le projet du W3C : http://www.w3.org/TR/1999/REC-xmlnames-19990114/, la recommandation devrait tre adopte en 2001 au
plus tard.
3.1.3 Choisir, modifier ou dfinir soi-mme

son message-cadre
En Edifact, on choisit son message-cadre, on en dtermine le
subset utile et on se met d'accord dans le guide d'utilisation de
message et l'accord d'interchange sur les codes utiliser dans
chaque cas de figure prvisible. En principe, il nest pas question
d'ajouter de soi-mme, ne serait-ce qu'un code manquant. Il faut
l'accord pralable des utilisateurs du monde entier, mme si, le plus
souvent, aucun de ces utilisateurs n'changera jamais un message
EDI avec la communaut qui a besoin de ce code !
Ce qui s'annonce avec XML est une pratique moins rglementaire
et plus en conformit avec l'esprit de la Toile : on peut utiliser tel
quel (ou un subset seulement) un DTD-schma choisi dans une
bibliothque, on peut le modifier ou le reconstruire entirement
partir de donnes du systme d'information transmettre, ce qui ne
pourra que faciliter le mapping. Si un rapprochement de communauts s'impose alors qu'elles utilisent des DTD-schmas diffrents,
on les unifiera ; cet alignement de proximit se fera parce qu'il
correspond un besoin rel.
La dmarche top down d'Edifact, ne dans un environnement
rglementaire, part d'un message-cadre qui enveloppe tous les
besoins sans sauvegarder l'interoprabilit de ses implmentations
d'un contexte l'autre. La dmarche bottom up de XML, mtalangage n dans un contexte informatique, vite la cacophonie grce
des rpertoires de briques lmentaires rutilisables et privilgie
l'intgration la base dans le systme d'information.
3.2 Outils XML : XSLT, XLink, DOM, etc.

XML est entour de companion standards qui en dcuplent la
puissance et qui assurent son insertion au cur du systme d'information.
Voir la documentation la plus rcente du W3C, en particulier :

http://www.w3.org/TR/2000/WD-xsl-20000112/
L'approche par les feuilles de style et par un langage de transformation est tout fait fondamentale pour l'EDI dans un environnement ouvert multipartenaire : partir des mmes informations de
base, il est en effet possible de dfinir de multiples messages,
formulaires, transferts de donnes, ou affichages. Les serveurs qui
vont se dvelopper auront de plus en plus accs, non seulement
des bases de donnes et documents, mais des rpertoires de
feuilles de style. Elles leur permettront de gnrer aussi bien un
message qu'une prsentation sur un site Web, en tenant compte de
la gnration des navigateurs. la demande, le mme message
XML pourra tre trait automatiquement par une application, mais
aussi tre affich dans une forme visuellement utilisable.
Plus encore, l'utilisation de ces mcanismes de mise en forme va
permettre de grer des environnements acceptant des messages
dans des langages XML diffrents avec XSLT, (Extensible Stylesheet
Language Transformation), qui est un langage de transformation de
documents XML en d'autres documents XML.
Voir la recommandation du W3C de novembre 1999 :
http://www.w3.org/TR/xsl/
Cette transformation va permettre de modifier une structure XML
en une autre un arbre devenant un autre arbre. Elle est d'autant
plus ncessaire que de nombreux langages professionnels ou scientifiques vont se dvelopper qui traiteront de problmes similaires
mais avec des structures diffrentes d'organisation des informations.
C'est l, entre autres, une rponse la prolifration aujourd'hui
des DTD, demain des schmas.
Pour des lments d'information, des documents ou des messages correspondant la mme fonction, d'ventuelles diffrences
entre des groupes ou communauts d'utilisateurs reflteront seulement des choix de mise au point. Si les modles sous-jacents et les
donnes sont en fait les mmes, une transformation symtrique
entre des formes diffrentes est possible et automatisable. Cette
dmarche va notamment permettre la cohabitation d'approches
concurrentes pour l'organisation des schmas lorsqu'elle ne peut
tre vite.
Loin de reprsenter (par rapport Edifact) un retour en arrire
vers la cacophonie, XSLT peut au contraire contribuer rsoudre ce
qu'Edifact n'a pas su faire, savoir l'incompatibilit des subsets et
guide d'utilisation de messages entre eux.
3.2.2 Outils de rfrencement et de transfert

dune donne sur le Web
XLink : http:/www.w3.org/TR/1999/WD-xlink-19991220/
Le langage XLink permet de crer et de dcrire des liens entre des
ressources du Web. Les liens qu'il est possible de crer sont de diff-
H 3 598 13
rents types, allant de liens simples internes un document XML et

similaires, aux liens hypertextes utiliss actuellement dans des
documents HTML, des systmes de relations plus complexes, tels
que des liens tendus vers des ressources multiples ou des bases de
donnes de liens.
Dans la prparation automatique d'un message EDI, il sera ainsi
possible de faire rfrence en ligne un catalogue de produits ou
la dernire mise jour de la notice explicative d'une formalit administrative.
XPointer : http://www.w3.org/TR/xptr
XPointer est une extension du langage XPath. Langage simple,
XPointer fournit un mcanisme permettant de spcifier un point
prcis dans un document XML en fonction d'une localisation source
pour y slectionner des lments. Il opre sur la structure arborescente et les nuds des documents. Il peut tre utilis par XLink pour
tablir des liens au sein mme d'un document XML. Les fonctionnalits de XPointer permettent aux liens XLink de pointer vers un point
prcis d'un document qui peut tre un lment, un texte ou une
partie d'un document.
Les utilisations de XPointer dans le cadre d'un EDI ouvert sont
inventer. Par exemple : permettre une PME francophone, recevant
une commande dun anglophone et ayant un doute sur la smantique dun lment, davoir dans la feuille de style du message la
possibilit de pointer avec un simple click vers lURI comportant une
dfinition de cet lment en anglais ou en franais.
3.2.3 Outils dinterface de XML

la diffrence d'Edifact, rest isol dans le systme d'information, XML s'est entour d'outils qui en facilitent l'insertion et font de
XML la general glue du systme d'information. On n'en mentionnera que deux :
XMI : l'objet principal de XMI, (XML Metadata Interchange), est
de permettre l'change de mtadonnes entre outils de modlisation bass sur UML (Unified Modeling Language), et la communication des rpertoires de mta donnes bass sur le MOF (Meta
Object Facility), deux standards de l'OMG (Object Management
Group). XMI est donc la rencontre entre deux mondes importants,
celui des objets et celui des structures de donnes et documents.
Lorsque des modlisations ont t ralises, dans des entreprises
ou communauts diffrentes, comment s'assurer que ces modles
vont pouvoir s'articuler et qu'un projet EDI pourra s'en dduire ?
Jusqu'ici il tait peu prs impossible une communaut d'entreprises de travailler sur des modles communs en utilisant des outils
de conception provenant de fournisseurs diffrents. Cela devient
possible grce XMI. Des rgles sont ensuite mises au point pour
passer des modles en notation UML aux documents et messages
XML. Ds lors, la phase de modlisation de toute activit devrait
permettre de produire automatiquement les instances concrtes
des messages, y compris en EDI.
DOM : c'est une interface de programmation (API) pour des
documents XML (ou HTML). Cette interface est indpendante des
plates-formes et des langages de programmation. Elle doit permettre aux scripts et aux programmes d'accder et mettre jour dynamiquement le contenu, la structure et la prsentation d'un
document XML. Le DOM devrait faire l'objet d'une recommandation
du W3C en 2001.
Le nom, Document Object Model ou DOM, a t choisi en rfrence aux mthodes de conception oriente objet. Les documents
sont modliss en mettant en vidence la structure du document,
son comportement et les objets qui les composent. Les nuds d'un
document ne reprsentent pas une structure de donnes, mais des
objets ayant une fonction et une identit.
Le DOM identifie :
les interfaces et objets utiliss pour reprsenter et manipuler
un document ;
H 3 598 14
la smantique de ces interfaces et objets (comportement et

attribut) ;
les relations et les collaborations entre les interfaces et les
objets.
Le DOM doit permettre aux offreurs de logiciels de proposer des
applications Web avec une interface standard utilisable dans tous
les environnements et avec toutes les autres applications Web indpendamment de la plate-forme et du langage de programmation de
l'application. C'est une garantie d'intgration de XML dans tout
environnement. C'est le type d'outil qui permettra de mettre en
uvre un jour l'OO-EDI (EDI orient objet).
3.3 Langages XML mtiers, frameworks

et rfrentiels
La dclinaison du mtalangage XML en langages mtiers, grce
son eXtensibilit, doit se concilier avec une interoprabilit qui sera
facilite par la rutilisation possible de schmas rfrencs. D'o
l'enjeu des frameworks pour l'interoprabilit et des rfrentiels de
schmas, vocation plus ou moins universelle.
On peut constater une approche oprationnelle, (celle de RosettaNet, par exemple), et une autre plus normalisatrice :
soit tendance quasi rglementaire (poursuite de celle d'Edifact qui est celle d'ebXML, d'ailleurs coparrain par le Cefact-ONU) ;
soit plus ouverte privilgiant le rfrencement avec passerelles, plus dans le style Internet et XML (celle de BizTalk de Microsoft).
3.3.1 Floraison de langages mtiers en XML

En 2000, le mtalangage XML a commenc se dcliner de plus
en plus par mtiers. Il s'agit parfois d'un simple schma, souvent
d'un schma accompagn d'un dictionnaire de donnes et de rgles
d'utilisation constituant donc un vritable langage. Cette floraison
se produit dans les domaines les plus divers, comme dans le transfert de donnes gographiques pour lequel GML (Geography
Markup Language), a t publi dbut 2000. Mais XML se dveloppe
aussi dans des domaines de l'EDI couverts par Edifact :
le tourisme avec le langage dvelopp par Open Travel
Alliance ;
la comptabilit et le business reporting avec XBRL, eXtensible
Business Reporting Language (largissement de XFRL, eXtensible
Financial Reporting Language) ;
la construction avec bcXML (building construction) dvelopp
par le groupement europen eConstruct venu s'ajouter aecXML
(architecture, engineering and construction), projet de schma
dpos par Bentley ;
le commerce lectronique en gnral avec WebGiro (World
Electronic Business Global Information Real-time On-line) et son
DCML (Defined Commerce Message Language) avec Microsoft
comme partenaire, qui a mme cherch s'intgrer dans la normalisation officielle europenne (CEN) ;
les formalits administratives (B2A) avec XForms (spcification du W3C) qui s'affiche en HTML (ou XHTML), mais qui est en
fait une structure XML standardise qui permettra de vrifier la validit des formulaires remplis en retour.
Rien n'assure a priori l'interoprabilit de ces langages, ce qui ne
facilitera pas la tche des entreprises ayant transfrer des donnes
de l'un l'autre. D'o l'importance des frameworks, mais aussi des
serveurs rfrenant ces langages et procurant des passerelles
entre eux. terme, soit un ensemble de concepts et de schmas
s'imposera, soit des sous-ensembles se constitueront, pour des
fonctions et secteurs diffrents, et des passerelles seront tablies
grce aux modles sous-jacents de l'change.
3.3.2 Rpertoires et serveurs de DTD-schmas

fonctionnels ou sectoriels
Les premiers rpertoires et serveurs de rfrence ont surtout eu
comme proccupation de proposer des services oprationnels. En
effet, la fourniture d'outils et la cration de communauts reprsentent des perspectives commerciales importantes pour les acteurs
qui seront capables de contrler ces serveurs et leurs services et
logiciels. D'o une offre importante :
RosettaNet et son PIP (Partner Interface Process) :
http://www.rosettanet.org
Ce groupement des acteurs de l'informatique vise au dpart la
standardisation de la chane des approvisionnements du secteur,
cependant les ambitions des promoteurs les ont amens concevoir des mcanismes qui peuvent largement tre repris pour
d'autres secteurs.
L'apport le plus intressant est le Partner Interface Process. Un
PIP est une spcification XML qui permet d'harmoniser et d'intgrer
les systmes des partenaires de commerce. Il ne s'agit donc pas des
messages de commerce eux-mmes mais de modles de donnes,
de process et de documents qui vont permettre aux dveloppeurs
d'implmenter des interfaces elles-mmes dfinies par RosettaNet.
OBI (Open Buying on the Internet) maintenant rcrit en XML :
http://www.openbuy.org
OBI est un vaste consortium, avec notamment American Express,
dont le but est l'tablissement de standards pour les petits achats
des entreprises hors de leur activit principale (hors production),
par exemple les fournitures de bureau. Il s'agit d'un ensemble de
fonctions et de messages permettant d'identifier un acheteur dans
une entreprise, un fournisseur, de proposer des choix, de permettre
le paiement par un employ pour de petits montants.
cXML (Commerce XML) : http://www.cxml.org
cXML est un ensemble de propositions de messages pour les
relations acheteurs-fournisseurs, et de protocoles associs permettant l'interrogation de sites Web des fournisseurs depuis les logiciels de gestion des achats des entreprises. Un protocole de
demandes-rponses peut alors se drouler. Le process vis est celui
des achats, jusqu'au paiement. L'acheteur reoit des paramtres,
pour les produits et les prix, correspondant son profil. Microsoft a
sign un accord avec cXML, regroupement d'acteurs du commerce
lectronique autour d'Ariba et Sterling Commerce, qui sera
support par Biztalk.
On peut citer aussi CBL (CommerceOne) qui est un concurrent
rassemblant une collection de schmas XML pour des process courants comme la commande, la facture, etc. Pour faire face la diversit des langages de schmas, CBL est crit selon trois langages,
celui du W3C (pas encore un standard), celui de Biztalk (qui devrait
finalement se conformer au prcdent, selon Microsoft) et le langage dvelopp par Commerce One, SOX (une des premires propositions, Schema for Object Oriented XML). L aussi, Microsoft a
sign des accords avec CommerceOne et Biztalk accueillera CBL.
Pour clore une liste non exhaustive, on peut citer les protocoles
OTP (Open Trading Protocol) ou OFX (Open Financial eXchange)
avec une mention spciale pour Bolero, lanc par des transporteurs
et banquiers internationaux, familiers de l'EDI, qui a pour lui un
plus : tre un tiers de confiance pour la livraison et le paiement !
3.3.3 Trois global unique frameworks :

CommerceNet, ebXML et/ou BizTalk
CommerceNet : http://www.commercenet.com
Cr en avril 1994 aux tats-Unis, avant lexplosion de XML,
l'objet de CommerceNet, qui regroupe plus de 500 socits et orga-
nisations dans le monde, est de transformer Internet en une vaste

place de march lectronique. CommerceNet va donc dvelopper
des propositions de standards pour l'interoprabilit. L'ambition est
de dvelopper un cadre gnral et gnrique pour le commerce, qui
pourrait englober les diverses propositions de protocoles, langages,
messages.
Ce cadre, eCo Framework, cherche permettre l'interoprabilit
des diffrents systmes en proposant des dfinitions gnriques
des lments et des documents du commerce lectronique, en se
plaant un niveau de dfinitions smantiques, et en compltant
par la dfinition des transactions.
Le principe est donc, devant l'existence de plusieurs langages et
procdures pour un mme objet, de remonter au niveau des modles et des dictionnaires, ce qui est un principe gnral pour rtablir
l'interoprabilit. Des outils peuvent alors tre construits pour
passer d'une forme une autre de messages particuliers. L'enjeu
est important, mais l'objectif est difficile atteindre. Cependant,
terme, ce type de proposition est envisageable parce que tous ces
changes concurrents sont crits dans des langages XML, dans une
grammaire commune.
ebXML : http://www.ebxml.org
la diffrence de tous les rfrentiels cits jusqu'ici, ebXML associe pleinement les reprsentants de l'EDI classique puisqu'il rsulte
d'une initiative commune entre le Cefact-ONU, responsable
d'Edifact, et Oasis, association des offreurs pour un dveloppement
standardis de XML pour le commerce lectronique.
L'ambition est grande puiqu'ebXML a dpos une marque :
Single Global Electronic Market . L'ambition se reflte galement
dans le champ des groupes de travail d'ebXML qui couvrent tous les
niveaux de l'change lectronique :
Technical Architecture Specification (dfinition d'ensemble,
dictionnaires des agents, objets, entits ebXML) ;
Repository and Registry Specification ;
Transport, Routing and Packaging Specification ;
Business Process Modelling Specification ;
Core Components Specification.
Si on peut tre sceptique sur la capacit d'ebXML de dfinir et de
faire adopter un framework aussi complet, les discussions entre,
d'une part offreurs de produits XML pour un commerce lectronique ouvert, et d'autre part utilisateurs de l'EDI classique, marquent
la premire reconnaissance mutuelle de deux mondes qui au mieux
s'ignoraient. Cela ne peut manquer d'avoir un effet trs positif sur la
synergie entre EDI et XML.
BizTalk : http://www.biztalk.org
Plutt que de prtendre imposer un framework, Microsoft a
dcid doffrir tous les schmas existants librement accessibles
tous, avec de plus des services ajouts qui retiennent les utilisateurs.
Microsoft propose donc depuis fin 2000 un ensemble dcrit dans
la figure 4, Biztalk, qui comprend la fois une proposition de
contenu de schma, en attendant la recommandation du W3C, et un
forum associatif o sont enregistrs, pour divers messages et
secteurs, des schmas utilisables par tous. Biztalk est fortement
orient rseau et comporte un serveur qui enregistre et tient jour
en XML les profils de transactions, y compris en EDI, entre ses utilisateurs et leurs correspondants. BizTalk assure, par exemple, la
traduction d'un format Edifact en XML et rciproquement.
Microsoft a plac Biztalk entre les mains d'un consortium comprenant notamment de nombreuses socits utilisatrices importantes
comme SAP, Ariba et Boeing. Microsoft poursuit ainsi sa stratgie
XML, qu'il a t le premier soutenir, en particulier en proposant les
schmas pour remplacer les DTD, et verrait bien BizTalk s'imposer
comme un de ses standards de facto.
Mais au mme moment apparat sous l'gide d'Oasis (offreurs ne
voulant pas se plier la loi de Microsoft) un autre rpertoire de DTDschmas : http://www.xml.org/registry/
H 3 598 15
BizTalk : change de Donnes

BizDesk
Gestion des partenaires Commerciaux
Outils
Donnes
Editeur
de Squence
BizEdit
ED XSOC
IDOC
SpMappec
Spec
Agreement
WebDAV
Admin
BizMap
EDI
EDIEDI
Temporaire
EDI
SAP
IDOC
Tracking
MSMQ
DCOM
HTTP
SAP
IDOC
SAP
R/3
FTP
ADO
Client
ou
Fournisseur
SAP
IDOC
BizTalk
Servers
File
System
SMTP
EDI
SNA
Server
Figure 4 Larchitecture BizTalk
4. La synergie : intgrer lEDI

en XML dans la bote
outils de lentreprise
Dans l'immdiat, d'une part les systmes existants bass sur
Edifact vont continuer fonctionner, d'autre part les spcifications
de standards lis XML tardent se stabiliser, ce qui freine l'apparition sur le march d'outils les mettant en uvre. En 2000, on peut
donc dire que l'on est entr dans une priode en constante volution avant que XML puisse faire preuve de toute sa puissance. Mais
il faut grer cette instabilit, car il n'y a dj plus de choix : l'EDI,
comme tous les autres outils informatiques de demain, utilisera
XML.
4.1 LEDI couche des PGI, progiciels

de gestion intgre (ou ERP)
Le monde Edifact est rest assez largement isol. L'outil technique Edifact, la diffrence d'XML des produits associs, est trs
strictement limit l'EDI Edifact. Paradoxalement, la recherche de
dictionnaires de codes communs avec les partenaires EDI de l'entreprise, pour les fonctions achats, trsorerie, ou logistique, a souvent
pris le pas sur les dmarches de modlisation des donnes internes
dans les entreprises. Or, le recours de plus en plus frquent aux PGI
(ou ERP), y compris par les PME, condamne l'EDI rompre cet isolement et s'intgrer comme une couche des PGI.
H 3 598 16
4.1.1 Synergie entre lEDI et les PGI

Les grands diteurs de PGI, SAP en tte, passant en XML, dsormais lingua franca des systmes d'information, le courant dsign
aux tats-Unis sous le nom d'EAI (Enterprise Application Integration) dans lequel l'EDI, tant en XML, aura sa place naturelle, s'tendra plus facilement au bnfice mutuel de l'EDI et des PGI.
D'un ct, en effet, les PGI ne peuvent plus se permettre de rester
isols : une gestion est-elle vraiment intgre si une partie importante des informations gres par l'entreprise doit faire l'objet de
saisie alors qu'elle est disponible sur les ordinateurs de ses partenaires ? Une entreprise qui dispose d'un systme de traitement de
l'information parfaitement intgr ne rend pas les meilleurs services
ses clients si elle est incapable de leur envoyer, ni de recevoir
deux, automatiquement, donc en EDI, des informations rptitives,
commandes, avis de livraison, factures etc. L'EDI est donc un facteur
d'intgration externe des PGI.
De l'autre ct, si le mapping entre message EDI et l'application
est l'tape la plus importante et la plus dlicate de l'EDI, les PGI,
avec leurs bases de donnes internes se rfrant un modle explicite, facilitent grandement le mapping. Les PGI sont donc un facteur
d'intgration interne de l'EDI.
4.1.2 Mini-PGI et EDI light pour les PME

Constatant que les PME, 98 % ne font pas d'EDI, mais utilisent
de plus en plus un mini-PGI leur porte, l'EDI light dvelopp par
Edifrance est adapt ces PGI de PME. L'EDI light est un scnario de
commerce lectronique mettant en relation EDI ces mini-PGI, en se
basant sur 6 messages Edifact ne comprenant que ce qui est indispensable ces progiciels pour les transactions commerciales des
PME.
Ce scnario EDI pour les PME couvre ainsi les subsets les plus
petits possibles de 6 messages Edifact :
PARTIN 1 identification dun fournisseur ;
PARTIN 2 identification de client et ouverture de compte ;
PRICAT ouverture de compte et catalogue de prix ;
ORDERS commande ;
ORDRSP rponse la commande ;
DESADV confirmation de commande et avis dexpdition ;
INVOIC facture conforme aux exigences de la DGI sur la dmatrialisation.
Une note prvoit mme que le passage XML puisse se faire
selon 3 modalits :
transposer les codes de donnes ou segments Edifact en balises XML : pas trs lisible par l'utilisateur puisque le nom des donnes ne figure pas en clair, mais la structure Edifact est respecte ;
reconstituer en XML les segments Edifact avec les libells des
donnes en clair : lisible, mais la structure (qualifiants etc.) n'est
plus respecte ;
moyen terme, appliquer des rgles de fabrication d'une balise
XML qui soient bases sur la syntaxe EDIFACT : dans le cas d'un
segment Edifact commenant par un qualifiant, sa balise reprend le
nom de segment plus le code Edifact (et non le libell) du qualifiant.
Le rsultat reste proche d'Edifact et est intgrable sans traducteur
par l'application, tout en tant moyennement lisible.
4.1.3 Vrifier le contenu du message

avant son envoi
La pratique de l'EDI classique consiste vrifier l'arrive d'un
message, d'une part s'il est bien conforme la syntaxe, c'est le rle
du message CONTRL, et d'autre part si l'application destinatrice a
pu le traiter sans problme, c'est le rle du message APERAK (APplication ERror and AcKnowledgement). C'est bien le minimum de
contrler l'arrive si un message comporte des erreurs, mais ce
serait bien mieux de le faire avant l'envoi du message ! Cela viterait les pertes de temps, la gestion des messages d'erreur, etc.
Par exemple, commander un article dfrenc entrane un
message d'erreur APERAK : vrifier sur le site du fournisseur, avant
l'envoi de la commande, que tous les articles commands figurent
toujours son catalogue serait une manire efficace d'utiliser la
souplesse de XML et du Web. Un tel vrificateur de messages avant
envoi (du type du produit Test&Go de la socit Qualicontrol, (http:/
/www.testandgo.com) se paramtre pour remplir les fonctions assures par les messages Edifact CONTRL et APERAK : il joue en effet
d'abord le rle d'un parseur en vrifiant la syntaxe prvue dans la
DTD et peut ensuite prendre en charge, non seulement les contraintes supplmentaires du schma (quand il sera standardis par le
W3C), mais des contraintes diverses de niveau applicatif comme
celles qui vrifient les zones d'un questionnaire.
Chaque zone d'un message peut se voir attribuer des contraintes
classiques, format, prsence obligatoire ou conditionnelle croise
avec une autre zone, calculs, respect d'une liste de codes internes
ou consulter en temps rel sur un site Internet etc. En consquence, la convivialit bottom up de XML s'exercerait en deux
temps :
1) les partenaires d'changes rptitifs conviendraient d'une DTDschma ;
2) ils se mettraient d'accord sur le paramtrage d'un outil comme
Test&Go pour prvenir les erreurs.
4.2 LEDI parmi les outils

de communication de lentreprise
La fonction de lEDI restera de mettre niveau les applicatifs
dentreprises diffrentes. Mais ces applicatifs sont dsormais relis
au Web et lEDI ne peut lignorer. Quil sagisse de places de march

ou dun rseau des catalogues lectroniques, des annuaires du B2B
ou daccord dinterchange lectronique, lEDI classique ne peut
rester isol et doit sintgrer parmi les outils de communication de
lentreprise. Avec XML, cela lui sera plus facile.
4.2.1 LEDI, suite de la place de march

et des catalogues lectroniques
De mme qu'on a pu lire qu'Internet ou XML allaient remplacer
l'EDI, il a t dit que les places de march lectroniques signaient la
mort de l'EDI. En fait, l'EDI ne sera pas remplac par les places de
march lectroniques en ligne many to many , il les prolongera
pour les relations entre partenaires one to one : sous peine de
dsorganiser la production, on ne peut rengocier tous les jours sur
le Web un nouvel accord avec un nouveau partenaire !
Aprs les fiches-produits et les messages Edifact correspondants,
amont du processus EDI classique de commerce lectronique,
lapparition de catalogues lectroniques, pour le B2C comme pour
le B2B, a chang la donne : les informations sur les produits sont
mises jour en permanence sur le Web, et on vient de voir quune
commande, en EDI ou non, ne doit tre passe quaprs vrification
que les rfrences nont pas t modifies.
Cela dautant plus que lon voit poindre des catalogues lectroniques collectifs de filires ou de places de march qui en feront un
outil stratgique du commerce lectronique sur lequel lEDI doit se
brancher.
4.2.2 Annuaires du B2B

Qu'AOL, IBM, Microsoft, Novell, Oracle et Sun cooprent sur un
standard, DSML (Directory Service Markup Language), l'vnement
mrite d'tre not. C'est que DSML est un standard XML pour exprimer les services et les informations des annuaires qui sont un
service public dont tout le monde a besoin. DSML permet
d'interfacer les applications de commerce lectronique B2B aux
annuaires des diffrents partenaires des changes, qu'ils soient en
EDI ou non.
La disponibilit d'annuaires communs est une condition du
commerce lectronique et d'un EDI ouvert. Or, la norme X500 a des
contraintes assez fortes et le format d'change simplifi (Light
Directory Access Protocol) oblige crire des interfaces LDAP spcifiques pour chaque application. Avec le nouveau standard DSML,
les applications accdent aux annuaires par LDAP mais toutes les
requtes et toutes les informations sont vhicules dans un langage
XML standardis, et permettant donc un commerce plus ouvert
dans des communauts. La spcification 1.0 doit tre adopte en
2000. noter que l'implmentation sera conforme BizTalk.
DSML est trs important pour l'EDI, d'abord pour que le mme
annuaire aide prolonger en EDI des contacts nous sur une place
de march lectronique, ensuite pour qu'une communaut EDI existante se gre et puisse s'largir facilement.
4.2.3 tpaML et EDI ouvert

Il s'agit de la proposition par IBM dun projet de standard tpaML
(Trade Partner Agreement Markup Language), bas sur XML, et
visant gnrer un accord dinterchange entre deux ou plusieurs
partenaires pour leur commerce lectronique en EDI ou non.
Comme les accords dinterchange que ngociaient les partenaires
de lEDI classique, le tpaML comporte des aspects juridiques et techniques, prcisant les protocoles de transmission, les protocoles
mtier, du type OBI, RosettaNet, cXML ou Biztalk et les formats de
message du type DTD ou schmas.
H 3 598 17
Quand deux partenaires schangeront un tpaML en y indiquant

les informations de leur profil , cela vaudra passation de contrat.
Alors, partir de ces spcifications figurant dans un document XML,
un gnrateur de codes produira en consquence une couche logiciel dans le serveur Web de chacun pour quensuite les messages
puissent tre automatiquement mis, reus et intgrs dans les
applications.
prparer un mapping correct avec ses donnes internes. Dans un

message XML, la balise comporte le nom en clair de la donne
transmise, d'o la longueur des messages XML ! D'o aussi la difficult de voir se promener des balises crites en langues diffrentes
dans un EDI ouvert o la smantique n'est plus discute, mais
simplement propose dans le DTD-schma envoy en claireur .
Cela ressemble ce que souhaitait faire la business view de

lEDI ouvert condition que tpaML, ne sen tenant pas aux messages isols, prenne en compte leur enchanement au sein de
scnarios. Au cas o ce standard tpaML serait entrin, IBM devrait
proposer sa mise en uvre par une architecture ad hoc : BPF, signifiant B2B Protocol Framework, et une suggestion dannuaire LDAP
annonant lextrieur quelles sont les fonctions et spcifications
quune entreprise accepte dans son tpaML. L aussi, cest une des
visions de lEDI ouvert qui prendrait corps grce XML.
On voit tout de suite le danger : celui d'une omniprsence dfinitive de l'anglo-amricain et de la disparition progressive des autres
langues, dans le monde du B2B d'abord, dans la socit de l'information ensuite. D'o le BSR (Basic Semantics Register) gr pour
l'ISO par un consortium franais. Le BSR rassemble les dfinitions
de chaque donne exprimes en plusieurs langues, au dpart
anglais, franais, allemand, puis espagnol, etc., pour permettre
une communaut francophone d'utiliser des balises en franais tout
en fournissant ses correspondants anglophones la rfrence de
cette balise exprime en anglais.
4.3 EDI et XML dans une normalisation

au service des entreprises
Lencadr suivant montre la stratgie d'Edifrance, membre du

consortium grant le BSR et fournisseur de la version francophone
des rpertoires Edifact : assurer aux communauts EDI et entreprises francophones une source smantique de rfrence qui facilite le
portage de l'acquis Edifact en XML.
Voir le site dEdifrance : http://www.edifrance.org
Le global business suppose une interoprabilit maximum pour

viter que les changes lectroniques ne deviennent un vrai cassette. Certes, BizTalk de Microsoft prtend s'occuper de tout avec ses
serveurs en esprant devenir ainsi un standard de facto. En fait, du
point de vue des entreprises utilisatrices, peu importe que le
framework garantissant l'interoprabilit soit fourni par un standard de facto, ou par la normalisation officielle de l'ISO (ou du W3C),
l'important est d'avoir un tel cadre de cohrence !
4.3.1 Architecture ebXML et importance

des core components
On a vu que l'architecture d'ebXML tenait compte, au niveau
smantique, de l'exprience des edifacteurs . ct de modles
de business, de profils d'change, d'en-ttes de messages, cette
architecture s'appuie en effet sur des core components rutilisables. La smantique tant en fait lie au contexte de business, le rle
de ces core components est, en particulier, de permettre de relier
entre eux des concepts identiques exprims suivant des langages
mtiers diffrents.
Exemple : une compagnie arienne appellera passager la mme
personne que celle qui sera appele acheteur par le Duty free aprs
avoir atterri, expditeur si cette personne envoie le cadeau achet,
avant d'tre appele cliente en arrivant l'htel de l'aroport, etc. Et
pourtant, chaque fois, cette personne se sera identifie de manire
identique et aura pay avec la mme carte de crdit. chaque fois, son
rle dans un scnario de business diffrent se traduit par une smantique particulire.
Avec les core components , il ne s'agit pas de forcer tout le
monde employer les mmes termes, mais de ne pas compliquer la
vie de ceux qui veulent tre srs qu'ils parlent bien de la mme
personne, en leur offrant une passerelle identique vers les donnes
d'identification de cette personne. Reste le problme tudi par
ebXML d'un repository rassemblant cette smantique de base,
avec la question du multilinguisme.
4.3.2 BSR et frXML pour la place du franais

Dans un message Edifact, part quelques donnes en clair, seul le
code des donnes est transmis : les libells pouvant tre en langues
diffrentes ne sont utiliss qu'au pralable, quand on s'entend sur la
signification donner chacun de ces codes. chacun donc de se
H 3 598 18
Se concentrer sur les besoins essentiels

Devenir la source smantique de rfrence pour XML
dans le commerce lectronique
Crer un cadre gnral de description des concepts EDIFACT
dans le contexte XML
Crer des tags XML lies au dictionnaire EDIFACT
Crer un/des rpertoire(s) de tags XML-EDI
Faire de la XML-isation du dictionnaire de base un modle
et une rfrence pour la communauts EDI
Crer et promouvoir un portail pour permettre aux
communauts XML/EDI de stocker et rendre accessibles des
tags, DTD et scnarios XML
4.3.3 XML/EDI, EBES et Edifrance

La normalisation de XML et de ses diffrents outils est dans une
situation complexe et volutive : d'abord il s'agit de recommandations du W3C. La mise en uvre standardise de ces recommandations est laisse aux utilisateurs par le W3C, par exemple
ebXML pour ce qui est de l'interoprabilit du e-business . Reste
le monde de la normalisation officielle, en particulier l'chelon
europen, celui du CEN et de son ISSS (Information Society Standardization System) avec un atelier XML/EDI traitant de XML pour
l'EDI.
L'EBES (European Board for Edifact Standardization) est lui aussi
rattach l'ISSS. Pour faciliter la migration du monde Edifact vers le
monde XML, il serait souhaitable que l'EBES largisse son champ
celui de l'EDI exprim en XML et devienne, l'instar de ebXML, le
Electronic Business European Standardization. Il en est de mme
pour Edifrance l'chelon franais ou francophone : on a vu que
c'tait l'une de ses orientations stratgiques.
Car la question pose est dj celle de l'aprs-ebXML qui est
cens se dissoudre aprs ses 18 mois d'existence prvus, soit avant
la fin 2001. Quelle instance lui succdera pour grer repository ,
core components , etc. ? La meilleure manire de sauvegarder
l'acquis Edifact dans l'environnement XML est encore un mariage
de raison entre les deux patrimoines qui assure leur synergie et
vite tout conflit.
5. Conclusion
Aprs avoir prpar le terrain au B2B, l'EDI classique en est
modestement devenu un simple outil, le plus ambitieux, certes,
puisqu'il vise toujours automatiser les transactions rptitives
entre entreprises. Mais cette fonction permanente ne peut que
s'amliorer avec l'apparition de nouveaux outils qui en facilitent la
mise en uvre.
Ainsi, la dferlante XML ne menace pas le monde Edifact, mais
peut, au contraire, en permettre la fois llargissement et le prolongement. Mais comme toujours, si migration il doit y avoir, elle ne se
fera qu'au rythme souhait par les communauts EDI installes.
D'autant que certaines n'ont pas encore achev leur migration de
leur format propritaire vers Edifact ! L'EDI classique en Edifact a
donc encore de beaux jours devant lui. Mais la pression va s'accrotre pour que l'EDI s'exprime en XML, un Extranet en EDI tant alors
homogne avec les Intranet des entreprises. Devant cette pression,
plusieurs ractions sont possibles pour les communauts Edifact
installes :
ignorer XML et passer la version 4 de la syntaxe Edifact avec
RVA, subsets, guides et EFI (saisie cran chez les PME, EDI
larrive) ;
ou tenir compte de XML, au moins moyen terme :
en continuant avec la version 3 de la syntaxe en attendant les

produits respectant un nouveau cadre (ebXML) qui reprenne
lacquis Edifact, la smantique notamment,
avec de nouveaux partenaires XML en traduisant simplement
la vole chaque message XML en Edifact et rciproquement
avec de nombreux produits offerts,
en utilisant des stations de gestion des changes acceptant
aussi bien Edifact que XML (BizTalk, EDI-Pass, Viewlocity, etc.),
en rcrivant tels quels les messages Edifact en XML (projet
allemand de norme) et en migrant sur une station Internet de ecommerce.
Dans tous les cas en esprant ne pas avoir refaire entirement le
mapping avec les applications. Car cest bien l lessentiel : si lon
veut automatiser les changes lectroniques en one to one , il
restera toujours assurer, en XML comme en Edifact, un mapping
entre les donnes dun message et celles de lapplicatif ! En se
basant sur les core components smantiques de chaque corps
de mtier.
Car c'est bien l la difficult, mais aussi l'apport de l'EDI classique :
faire enregistrer les pratiques professionnelles pour pouvoir pratiquer un B2B automatis. Sans compter qu' terme, l'EDI ne se limitera plus seulement au B2B : lorsqu'une canette de bire sera sortie
d'un frigo intelligent , celui-ci enverra un message EDI au supermarch du coin pour rappro ! Ce jour-l, on en sera peut-tre dj
au successeur de XML, mais la proccupation de lEDI sera toujours
aussi vivace !
Rfrences bibliographiques
[1]
MARCHAND (R.), AGNOUX (H.) et CHIARAMONTI (C.). Applications EDI sur lInternet. ditions Eyrolles, Paris (1999).
[2]
CANOPE et TENOR CONSEIL. Opportunit dutilisation de XML dans le cadre des EDI. tude tlchargeable http://www.mtic.pm.gouv.fr/programmes/teleprocedures/index.shtml
H 3 598 19

Échange de Données Informatisé (EDI) : Claude Chiaramonti

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Échange de Données Informatisé (EDI) : Claude Chiaramonti

Uploaded by

Copyright:

Available Formats

change de donnes informatis (EDI)

EDI, prcurseur du B2B ..........................................................................

Acquis et limites dEdifact....................................................................

Approche XML partant de lutilisateur (bottom up) ......................

La synergie : intgrer lEDI en XML dans la bote outils

Rfrences bibliographiques .........................................................................

LEDI lheure dInternet

CHANGE DE DONNES INFORMATIS (EDI) ________________________________________________________________________________________________

LEDI classique install va continuer se renforcer en continuant utiliser la

1. EDI, prcurseur du B2B

message EDI. Naturellement, cet automatisme ne se justifie que si

En prolongement des changes qui se passent l'intrieur des

noter que lEDI classique na pas t que le prcurseur du B2B,

1.1 Permanence de la fonction de lEDI

1.1.1 Dfinition et conditions de succs de lEDI

Dfinition : l'EDI (change de Donnes Informatis) est un

________________________________________________________________________________________________ CHANGE DE DONNES INFORMATIS (EDI)

Tableau 1 Principaux sigles ou expressions utiliss (1)

Business to Administration, par exemple tlprocdures

Core component lment smantique de base rutilisable

norme EDI pour ladministration, le commerce et le

change de Formulaire Informatis

colle forte, liant

International Standard Organization

transcodage ou mise en correspondance, code

espace nominal permettant dviter les confusions

adaptation de la norme X400 lEDI (ou Pedi)

utilisation des protocoles Internet pour un ensemble ferm dentreprise

La solution fichier plat la plus utilise est bien adapte un EDI

En plus du caractre rptitif des changes difier , deux

Figure 1 LEDI, une mise niveau des applications qui respecte

cations qu'il s'agit de mettre niveau, en particulier pour qu'elles

CHANGE DE DONNES INFORMATIS (EDI) ________________________________________________________________________________________________

Seuls les cas exceptionnels et non prvus tant rservs la

1.1.2 Domaines et fonctions de lEDI

1.1.3 Scnario de commerce lectronique B2B

Tableau 2 Scnario denchanement de messages

informations sur les intervenants

demande dinformation produit

catalogue et liste de prix

information sur lorigine dun produit

donnes sur la qualit dun produit

rponse lappel doffres

prvision des ventes

statut dune commande (demande)

rponse concernant le statut dune commande

tat des ventes

consommations enregistres sur compteurs

tat des stocks

instructions sur les retours

prt mutuel de produits

rsum de compte commercial

historique de la fixation des prix

litige ou demande davoir

demande de paiement justifi

dcompte (ou avis) de paiement

________________________________________________________________________________________________ CHANGE DE DONNES INFORMATIS (EDI)

En fait, la plupart des communauts EDI utilisent seulement une

1.2 EDI classique : RVA et Edifact

1.2.1 Prminence des grands comptes

1.2.2 Intrt des RVA

1.2.3 Bilan : 2 % seulement des PME en EDI

1.3 LEDI demain avec Internet,