L'intgration de la chaine logistique

ERP, DW, EAI EDI, XML, Web Services

1. L'intgration dans une organisation : ERP, DW, EAI

1. L'ERP impose de repenser lexistant de production en profondeur, la fois les donnes et les
processus. Un ERP propose dintgrer les applications (les modules) en les faisant partager en temps rel une
information commune stocke au sein de sa base de donnes, grce la redfinition des processus et sa
base de donnes unique. Larchitecture devient modulaire, mais lexistant ne peut pas tre prennis.

2. Lentrept de donnes propose lextraction (ETL) de linformation partir des diffrentes bases de
donnes du SI, puis sa diffusion vers un entrept de donnes (DW) pour permettre traitement et analyse (BI). Il
impose ainsi la re-structuration des donnes, leur organisation, leur historisation et leur mise disposition.
Larchitecture est arborescente et lexistant de production est prennis.

3. Les architectures EAI proposent dhomogniser le SI et prenniser lexistant, en instituant une

plate-forme dintgration (passerelles de type middleware, architecture la fois modulaire et arborescente)
partir des bases de donnes du SI existantes et en utilisant les applications existantes. En ralit les pratiques
dinterfaage nintgrent que localement et partiellement les applications, une par une et au cas par cas. L'EAI
se fonde sur une centralisation des flux (mais pas des applications) et tente de gommer les connexions point
point entre les applications.

1.1 Larchitecture ERP, une intgration a priori

Au sein dun ERP-PGI lintgration est effective :
(1) un rfrentiel unique (UNE seule Base de Donnes)
(2) une uniformisation des interfaces et une unicit dadministration du systme
(3) la possibilit de paramtrer le progiciel en utilisant les processus prprogramms

Toutes les tailles, tous les secteurs et toutes les activits sont accessibles aux PGI.
Si le PGI tait lui seul le systme dinformation de gestion de lentreprise ce quil est rarement mais ce que
ses fonctionnalits lui permettent thoriquement il pourrait donc assurer la fois la cohrence et la capacit
de changement, mais des cohabitations sont inluctables avec diverses applications :
1. La migration. Implanter un PGI impose tout dabord de le rendre compatible avec la plate forme
informatique (systme dexploitation, bases de donnes). Les donnes de gestion indispensables sont
stockes par lorganisation au sein de bases de donnes historiques quil faudra intgrer (migration ou reprise).
Faire fonctionner un PGI ncessite donc, pendant une priode transitoire au minimum, de conserver les
applications antrieures et de les faire fonctionner simultanment avec celle de le PGI.
2. Le spcifique. Implanter un PGI nimplique pour lorganisation ni dutiliser la totalit des modules, ni
dabandonner les applications spcifiques antrieures. Implanter un PGI ne garantit pas de faon automatique
que toutes les fonctionnalits et en particulier les fonctionnalits de type mtiers soient prsentes et/ou
satisfaisantes. Les donnes de gestion de type historiques et/ou volumineuses sont stockes et traites au sein
de bases de donnes qui ne sont pas celles du PGI, et qui imposent donc de concevoir et dintgrer des
applications de type passerelles entre les 2 systmes.
3. La connexion avec l'extrieur. Le PGI est confront aux donnes (clients, fournisseurs) et
applications (CRM, SCM) en contact avec lenvironnement extrieur, ces changes doivent pouvoir tre
possibles et donc les applications qui les traitent doivent tre intgres.

L're des progiciels de gestion intgrs monolithiques semble donc rvolue. Paramtrer des PGI ne
suffit plus rpondre aux exigences d'interoprabilit auxquelles doivent rpondre les systmes d'information :
processus distribus B-to-B, ouverture la gestion de la relation client et de la chane logistique, scurit des
changes... Pour s'ouvrir, les diteurs profitent de l'opportunit offerte par l'architecture Web services. SAP
cherche par exemple sortir de son cadre en btissant l'architecture ESA (Enterprise Services Architecture) :
Nous avons transform les objets mtier de SAP en composants interoprables, pour substituer un standard
la notion propritaire de Bapi, Business API . Par une simple requte Soap, les dveloppeurs peuvent alors
appeler les objets mtier (procdures fonctionnelles), installs au coeur des PGI.

ERP : avantages et difficults

Sagissant des avantages relatifs des ERP, ils sont dordre technique, oprationnelle et stratgique.
Sans dvelopper sur les diffrents avantages techniques largement, rappelons que les entreprises adoptent
un ERP afin de profiter dune homognit interfonctionnelle et de disposer dun seul et mme systme avec
une seule et mme base de donnes, une mme interface hommes-machine pour tous les postes de travail et
un seul systme dadministration pour les diffrentes applications. Ladoption met fin aux problmes rsultant
de lacquisition autonome de logiciels par chaque unit tel que les incompatibilits de donnes (ressaisies de
donnes) ou lexistence de systmes parallles dupliquant les mmes fonctionnalits. Elle rduit les tches
de maintenance des interfaces. La portabilit large des ERP tant au niveau des systmes dexploitation que de
SGBD ou des rseaux et leur modularit permet aux entreprises de faire facilement voluer leur systme
dinformation.
Les avantages relatifs sont galement organisationnels, lERP vient remettre en cause la conception
dune organisation fonde sur la spcialisation fonctionnelle. Lorganisation devient transversale, elle nest plus
dcoupe par grandes fonctions mais par des macro-processus qui la traversent (El Amrani 2004). Lunit
danalyse nest plus la fonction en tant que regroupement dactivits similaires mais le processus qui traverse
les principales fonctions de lentreprise (Davenport, Short, 1990). Ladoption facilite lacquisition et la diffusion
dinformations lintrieur et lextrieur de lentreprise en tant certaines restrictions et en rendant les
requtes plus aises. Permettant de regrouper diverses applications fonctionnelles autour dune seule base de
donnes, les diffrents ERP dont les plus connus SAP, Oracle applications, JD Edwards, PeopleSoft sont
conus pour supprimer la fragmentation de linformation dans les entreprises.
Les avantages sont galement stratgiques. Les ERP permettent damliorer la ractivit vis--vis des
clients en rpercutant en temps rel les volutions des demandes des clients (nouvelles commandes par
exemple) sur l'ensemble du systme productif (plan de production et des approvisionnements), des activits et
des fonctions concernes (cf. Bidan M., El Amrani R., Marciniak R., Rowe F. (2003) pour limpact de lERP en
terme de flexibilit) . Les entreprises peuvent en attendre une rduction des cots dexploitation, des gains de
productivit (McAffe, (2002); Matolcsy Z. P.; Booth P.; Wieder B. (2005)), un meilleur enregistrement des
commandes (diminution des redondances et procdures simplifies de saisie de donnes). Ladoption dun
ERP permet notamment de dceler des dysfonctionnements et de rvler les slacks organisationnels
(Besson, 1999). La mise en place de PGI accrot la capacit de faire face aux fluctuations de la demande
court terme et aux problmes de production lis aux modifications du produit (Cf. Suarez, Cusumano et Fine,
1995) en permettant aux acteurs daccder aux informations pertinentes et de communiquer entre eux pour
sajuster face aux alas. Un ERP est souvent prsent comme parfaitement adapt la logique sectorielle de
supply-chain. Un tel systme doit tre capable de communiquer le long de la chane de valeur aussi bien avec
des systmes dentreprises quavec des clients utilisant diffrentes plateformes. Les composantes ncessaires
la gestion de la supply chain sont des applications de requte, des systmes de gestion des stocks, des
systmes de planification et de lancement des transports, des systmes de gestion des relations clients et de
gestion automatique de la force de vente.
Mais la revue de la littrature souligne la complexit de la mise en uvre dun projet ERP et les
risques associs (Bernard, Rivard, Aubert, 2004).) La porte de lapplication de ces systmes, leur complexit
et leur niveau lev dintgration reprsentent des dfis importants pour les organisations qui les mettent en
place (Cf. Rowe (1999) pour la description des facteurs de risque : taille du projet, difficult technique,
primtre du projet). Outre le risque de dpassements de budget et dchance (enqute CIO cite par
Cosgrove Ware, 2001), il y a celui de linsatisfaction des utilisateurs et dune mauvaise qualit du systme
rsultant de limplantation. Afin de procder au paramtrage du progiciel, lquipe de projet et les utilisateurs
doivent possder une expertise varie, le manque dexpertises internes est dailleurs prsent comme une
source dchec (Barki et al, 1993, Scott et Vessey, 2002). La rigidit des PGI (Bancroft et al, 1998, Kale 2000),
lexistence dun cart important entre le processus cibl et celui inscrit dans le logiciel sont lorigine de
rsultats indsirables en raison des adaptations ncessaires du logiciel. De mme, lampleur des changements
occasionns par le processus vis est un facteur de risque (Barki et al, 1993, Bancroft et Al 1998). Lmergence
des ERP est un des principaux facteurs de changement organisationnel dans les entreprises au cours de
ces dernires annes (Robey et al, 2002 ; Bingi et al ,1999).

ERP : les raisons du choix

Les travaux de recherche se sont principalement intresss aux conditions de russite de la mise en
uvre dun projet ERP, et ont un peu dlaiss la question pralable des conditions de leur adoption et de leur
diffusion, cest lobjet de cette tude. Lchantillon est compos de 58 entreprises dont 37 ont dclar avoir
adopt un ERP. Le taux de rponse a t environ de 20% puisque le questionnaire a t adress 300
entreprises de moyenne et grande taille, toutes tires au hasard.

1. Peu de rationalit calculatoire : ladoption des ERP n'est pas le choix dun agent isol qui ferait un
calcul doptimisation conformment la thorie financire.

Tableau 1. Usage du calcul conomique et choix

Pourcentage de sonds dclarant Total des firmes (=58) Firmes ayant Firmes nayant pas
adopt (=37) adopt (=21)
avoir valu un projet
par le calcul dune VAN 30% 17% 52%
avoir valu un projet
par le calcul dun TRI 55% 51% 61%
Selon la thorie conomique traditionnelle lagent conomique rationnel, se dtermine en fonction de son seul
intrt. Disposant dune information parfaite et voluant dans un avenir connu avec certitude, il maximise son
profit. Dans une situation dite davenir risqu , le dcideur a connaissance de toutes les dcisions
envisageables. Il est capable dvaluer leurs consquences, il les compare selon le critre de lutilit espre et
retient celle qui la maximise. Cette rationalit qualifie dutilitaire se fonde sur le principe de lvaluation
subjective des cots et bnfices pondrs par leur distribution de probabilit. Unit de dcision autonome, la
conduite de lagent nest pas conditionne par des habitudes sociales consciemment ou inconsciemment
assimiles. Les choix des autres sont sans effet sur son comportement (indpendance des fonctions de
prfrence). Dans ce cadre l, ladoption des ERP est un investissement raliser sil cre de la richesse.
Lopportunit de cet investissement se juge selon son niveau de cration de richesse estime partir des
diffrents outils et critres proposs par la thorie financire noclassique tels que celui de la valeur actuelle
nette et le taux de rentabilit interne.
En fait, il est difficile de quantifier la rentabilit des projets informatiques en raison notamment de leur
frontire trop large, de linteraction avec dautres changements et de lincertitude sur leur dure de vie.

2. Une rationalit plus sociale : ce sont les caractristiques perues de l'ERP dterminent le
comportement d'adoption des dcideurs
Tableau 2. Attributs perus des ERP
Toutes les firmes de Firmes ayant adopt Firmes nayant pas
lchantillon (effectif 58) (effectif 37) adopt (effectif 21)

Attributs perus Moyenne sur 6 Moyenne Moyenne

Compatibilit avec la stratgie
sectorielle 4,15 4,72 3,14
Avantages en terme de
gestion dinformations et prise
4,96
de dcision 5,35 4,27
Avantages stratgiques 4,10 4,42 3,53
Avantages organisationnels 4,44 4,89 3,64
Complexit et risques
techniques lis aux PGI 5,13 5,26 4,89
Complexit et risques orga-
nisationnels lis aux PGI 4,01 4,08 3,89
Dans la conception socio-rationnelle de la diffusion domine par le modle de diffusion de Rogers (1983, op.
cit.) ce sont les caractristiques de linnovation, de ceux qui ladoptent, de leur systme social, de
lenvironnement etc., qui favorisent sa diffusion. Une innovation ne sera adopte que lorsque les individus
concerns seront convaincus, compte tenu des informations dont ils disposent, de lintrt ou des gains quils
peuvent en tirer. Il s'agit d'un processus squentiel par tapes, au cours duquel un individu ou toute unit de
dcision passe de la premire connaissance de l'innovation (1), la formation d'une attitude vis--vis de cette
dernire (2), la dcision de l'adopter ou de la rejeter (3), la ralisation de la nouvelle ide (4), et enfin la
confirmation de la dcision d'adoption (5).

Selon, Rogers et Shoemaker (1971), lvaluation de linnovation par les potentiels adoptants se fait
selon cinq attributs : - l'avantage relatif ou "utilit perue" qui est le degr de supriorit de l'innovation par
rapport d'autres innovations existantes; - la compatibilit qui dtermine le degr de cohrence avec les
valeurs et l'exprience antrieure des individus; - la complexit ou "facilit d'utilisation" qui reprsente la
mesure de la difficult comprendre ou utiliser l'innovation; - l'essayabilit, ou la possibilit plus ou moins
grande de faire un essai limit de l'innovation;- l'observabilit qui dtermine le degr de visibilit de l'innovation
par les autres.

3. Beaucoup de mimtisme rationnel dans ladoption dun ERP

Tableau 3 Influence des positions prises par autrui

Total des Sonds ayant Sonds nayant pas
Entreprises dclarant avoir t ` sonds adopt adopt
influence fortement dans leur choix :
- par le choix dadopter pris par dautres socits 20,70% 29,70% 4,76%
- par le choix de socits proches gographiquement 8,60% 8,10% 9,50%
- par le choix fait par les socits innovantes 32,80% 40,54% 19,05%
- par le choix ralis par des socits reconnues comme 50% 43,24% 61,90%
leaders
- par le choix effectu par des socits reconnues comme 56,90% 54,05% 61,90%
performantes

La position prise par les entreprises dpend plus des positions prises par les autres entreprises que de
leur calcul priv. Une innovation se rpand en gnral au sein dun milieu social par mimtisme, certains
individus s'inspirant de l'attitude de premiers adoptants. Le dcideur, en situation dincertitude, observe le
comportement d'adoption des autres membres de sa communaut. Il btit ainsi sur cette observation, son propre
comportement, en s'alignant sur la pratique des autres.
Il y a imitation ds lors que l'adoption de l'innovation par une unit de dcision accrot pour d'autres la
probabilit d'en faire autant. Plusieurs modles de diffusion d'innovation, inspirs des travaux sur la propagation
pidmiologique de maladies, ont t dvelopps sur la base de cette hypothse de mimtisme. Le concept de
mimtisme, ce titre, est selon nous pertinent pour dcrire certains comportements dadoption dERP. Sil est
aujourd'hui la base de plusieurs thories majeures en sciences de gestion telles que la thorie de
l'apprentissage organisationnel (Lant et Mezias, 1990), la thorie institutionnelle (Di Maggio et Powell, 1983).
Ces rsultats rejoignent ceux de Webb et Pettigrew (1999) qui montrent, dans une perspective pour partie no-
institutionnelle, comment une stratgie initie par un leader se diffuse dans le champ inter-organisationnel.
Lorsque les leaders dopinion envisagent dadopter une stratgie initie, ce comportement est par la suite copi
par les autres (Greve 1995). Les entreprises imitent les actions des socits qui, ayant russi sur le march,
profitent dune bonne image et dun prestige lev (Burns et Wholey, 1993).

1.2 Lentrept de donnes, une intgration a posteriori

Avec les infocentres , il sagissait de faire une simple copie des bases de donnes de production, et
de donner ensuite aux utilisateurs les moyens daccs sur ces bases (outils dinterrogation et assistance).
Aujourd'hui un entrept de donnes (DataWarehouse) est une base de donnes vrifiant les trois proprits
suivantes:
- Une orientation par sujet : Par opposition aux donnes de production, qui sont orientes
applications, les donnes dun entrept sont centres sur les notions de base communes toute
lentreprise. Par exemple, une compagnie dassurances aura des applications pour lassurance auto,
lassurance vie, sant, etc. Chacune de ces applications manipule des donnes de production, dont certaines
sont communes (par exemple les contrats) mais ne peuvent tre reconnues pour telles. A loppos, ses sujets
dintrt sont les clients, les polices dassurance, les commerciaux quelle emploie... Ces diffrents sujets
constitueront les entits fondamentales du modle de donnes de lentrept.
- Une intgration totale des donnes : Les dveloppeurs des applications ont ncessairement, au fil
des annes, effectu des choix incohrents entre eux. Les diffrences se manifestent de certaines de faons:
dans le codage des donnes (par exemple, les dates...), la structure des cls, les conventions de noms...
Lintgration des donnes signifie que toutes les entits, sans aucune exception, ont un format unique dans
lentrept.
- Une historicit des donnes : Les donnes dun systme de production ne refltent que linstant
prsent. Celles dun entrept sont chronologiques: la dimension temps est explicitement reprsente dans
toutes les tables et la colonne correspondante est indexe. Les donnes sont donc conserves pour de
longues dures, lhorizon tant de 5 10 ans. Puisque la base est historique, il nexiste plus de notion de mise
jour. Une fois (correctement) enregistres, les donnes ne seront plus modifies. La normalisation des
tables cesse donc dtre un impratif pour la mise jour, la redondance nest pas dangereuse et toute libert
est laisse au concepteur pour optimiser laccs aux donnes.

Entre les bases de lentrept et les bases de donnes de production (encore souvent sur sites
centraux, et quelque fois mme sous forme non relationnelle), il faut organiser la slection, la transformation et
le transport des informations utiles au nouveau systme. Pour dcrire de telles conversions une nouvelle
gnration doutils de dveloppement a fait son apparition, celle des extracteurs de donnes ETL (Extract,
Transform and Load), avec des interfaces permettant de modliser graphiquement les changes, et de faire
correspondre des schmas de donnes non compatibles (en fonction des mtadonnes ou descriptions de
champs fournies par les applications). Les processus de dcision se raccourcissent dans le temps, et certains
outils ETL sont dsormais capables de grer des flux de donnes en temps rel , une srie de composants
veillent en attendant l'arrive des requtes pour les traiter.
Avec les ETL des entrepts, les donnes exploites des fins dcisionnelles analytiques restent en
gnral mises jour en diffr, du fait de leur volume important. Les plates-formes d'EAI peuvent alors tre
considres comme le prolongement des logiciels d'ETL : avec lEAI les donnes caractre oprationnel
(dont les applications ont besoin pour rendre compte de la situation prsente de l'activit) sont injectes en
temps rel dans l'application de destination. Mais au-del de lchange des donnes ncessaires la
transaction, lEAI entre aussi dans la couche transactionnelle : il permet une application de commander
l'excution d'une tche une autre selon le processus mtier dfini dans le rfrentiel de rgles, ce que ne fait
pas lETL dun entrept.

Outils dETL Outils dEAI

Excellente pompe donnes Trs bon routeur de messages
En gnral en mode batch En gnral au fil de leau
Sources BD et fichiers le plus souvent Applications sources et cibles
htrognes
Traite de forts volumes de donnes Traite de faibles volumes de donnes de
manire frquente
Transformations parfois complexes avant Transformations simples en gnral
lalimentation
Un SGBD relationnel sait fournir une liste de valeurs issues de plusieurs tables, mais la rgle de
normalisation consiste supprimer toute redondance et toute agrgation de donnes. Et rapatrier des
informations agrges (par exemple, le chiffre affaires total ralis sur une famille de produits) implique en
gnral de nombreuses jointures entre plusieurs tables, ainsi que des oprations daddition coteuses en
performance. Do lide dun modle de reprsentation des donnes particulier, et plus adapt lanalyse: le
modle multidimensionnel. Les principaux diteurs de bases de donnes relationnelles sintressent donc
lapproche multidimensionnelle des bases de donnes, qui peuvent aujourdhui adopter une structure des
tables en toile ou en flocon , o les indicateurs (ventes, marges, etc.) sont regroups dans une table.
Les donnes texte (clients, anne, mois, etc..) sont ranges dans des tables diffrentes, relies la premire
par des cls.

Les donnes sont donc organises selon des axes, en fonction des hirarchies, et elles peuvent tre
agrges et redondantes. Le modle multidimensionnel est finalement un hyper-cube qui comporte autant de
dimensions que daxes danalyse (souvent neuf). Avec trois dimensions, il pourrait sapparenter un Rubiks
cube , que lon peut faire pivoter selon ses axes pour visualiser diffrentes faces. Comme les donnes sont
prpares, les temps de rponse sont stables et quivalents quels que soient axes. Les requtes peuvent
exploiter toutes les combinaisons et permutations daxes. Il est possible de crer des niveaux hirarchiques et
de prvoir des axes pr-calculs (par exemple la somme de frais par rgions, par produits, par mois...). Cette
possibilit ouvre sur une des fonctions les plus intressantes de lanalyse multidimensionnelle: le drill-down
qui consiste plonger trs rapidement dans le dtail des informations fournies par un simple clic lcran.

LEXTRACTION DE DONNEES
BASES DE DONNEES EXTERNES

SYSTEMES TRANSACTIONNELS

BASES DE DONNEES UTILISATEURS

Communication
Extraction
Contrle

Conception
Rfrentiel
Dictionnaires

SGBD:
BASES DE DONNEES HISTORIQUES

LENTREPOT DE DONNEES

Data Mining

E.I.S. PROGICIELS SYST.EXPERTS INFOCENTRE ...

LE CLIENT

Les tenants de ces solutions OLAP (On Line Analytical Processing) affirment que les SGBD.R, conus
pour rpondre des besoins de gestion, se trouvent en fait incapables dassurer des rponses dans des temps
convenables des questions dordre dcisionnel. Do le besoin de crer une nouvelle base spcifique,
multidimensionnelle cette fois, que ce soit sur le serveur pour des applications lourdes (solution prne avec
Essbase...), ou sur le poste client (Speedware avec Media...). Mais la rvolution OLAP rside surtout dans
louverture du march de lanalyse multidimensionnelle des outils non spcialiss comme les tableurs.
La base dtaille, qui constitue lentrept de donnes proprement parler, reste lapanage des SGBDR. En
effet les bases multidimensionnelles, souvent limites en capacit, ne permettent pas dengranger les centaines
de Giga-octets, que lon souhaite stocker dans les datawarehouses. Dans un environnement dinformatique
dcisionnelle, une base OLAP se positionne alors plutt comme un serveur intermdiaire dcisionnel de
haut niveau aliment par le SGBDR, qui conserve lui son rle dentrept de donnes lmentaires, historises,
etc......
1.3 LEAI, une plate-forme reliant les applications htrognes
L'objectif de l'intgration d'applications est de mettre en place une infrastructure technique autorisant
une coopration automatise, de qualit, scurise et performante entre diffrentes applications. Ainsi, si
deux applications A et B ont besoin de travailler ensemble, il va falloir mettre en place une infrastructure de
communication entre elles, dvelopper des interfaces spcifiques leur permettant de s'changer des donnes
et d'utiliser conjointement leurs ressources et, enfin, dfinir des protocoles d'interaction. Si l'entreprise a besoin
de faire travailler ensemble N applications, elle devra, en appliquant cette logique, dvelopper autant
d'interfaces spcifiques qu'il y a de couples d'applications, soit Nx(N-1)/2. Ce traitement au cas par cas montre
vite ses limites car il ne permet pas une intgration pralable, globale et systmatique des briques du systme
d'information. Il est donc ncessaire que l'entreprise mette en place une dmarche et des solutions techniques
homognes permettant d'industrialiser cette coopration entre applications.

Pour cela, il est possible d'agir de deux faons, l'une ex-post, l'autre ex-ante :
- (1) Dvelopper ex-post un systme centralis autorisant et organisant la communication entre
toutes les applications internes : c'est l'objet de l'EAI : Enterprise Application Integration
- (2) Rebtir ex-ante certaines applications externes dans une logique de composants
interoprables bass sur des standards du march : c'est l'enjeu des architectures Web services bass sur
les technologies de l'internet.

Avant l'arrive des outils d'EAI, les entreprises devaient dvelopper elles-mmes deux connecteurs
chaque fois qu'elles souhaitaient relier deux applications entre elles. Aucune politique de standardisation des
connecteurs n'tait dfinie, pas plus qu'un protocole de transport standard. Si bien que les connexions
interapplicatives reprsentent un vritable plat de spaghettis qui cote de plus en plus cher maintenir. Les
plates-formes d'EAI sont des multiprises applicatives qui relient les applications entre elles en se fondant sur
des standards. Ce faisant, elles rationalisent et fluidifient le systme d'information, le rendant plus flexible et
plus ractif : un quartier ou une application peuvent tre facilement dbranchs sans bloquer le fonctionnement
du reste du systme.

Application 1 Application 2 Application 3

EAI

Application 4 Application 5 Application 6

Principe de fonctionnement de lEAI : une multiprise applicative.

Une plate-forme EAI fonctionne sur le modle d'une multiprise. Chaque application possde un
connecteur standard (la prise) qui est reli au " bus EAI " (la multiprise).
- Le connecteur est un excutable ou une classe Java, install sur la machine qui hberge
l'application. Il traduit les donnes provenant de l'application dans un format lisible par un courtier de message,
et vice versa. Il existe deux types de connecteurs : techniques et applicatifs. Les connecteurs techniques sont
relis aux applications depuis leur base de donnes, des fichiers plats, etc. Les connecteurs applicatifs
interfacent directement leurs API (Application Programing Interface). Encore propritaire au dbut des annes
deux mille, les connecteurs se standardisent peu peu autour de technologies telles que les services web
(WSDL, Soap, HTTP) ou JCA (J2EE Connector Architecture).
- Au coeur de la plate-forme, le bus EAI est constitu d'un courtier de messages (message broker) et
d'un MOM (middleware orient messages). Le courtier de messages applique des transformations sur les
messages entrants avant de les renvoyer vers les applications. Il est galement capable de router une
information sur une file d'attente particulire du MOM. Ainsi, si une application destinataire n'est pas accessible,
le MOM stocke les messages entrants et sortants jusqu' ce qu'ils soient rcuprs par leurs destinataires.
C'est ce mcanisme de communication asynchrone qui permet de dcoupler les applications les unes des
autres. Dans cette architecture de type " publication et abonnement ", chaque application s'abonne des files
de messages sur lesquelles elle peut publier et recevoir des messages, le plus souvent aujourd'hui au format
XML.

L'objet de l'EAI est de faire communiquer les applications d'un systme d'information non pas en mode
point point, mais via un systme global, cohrent et systmatique. Mais par quel miracle ce bus si simple
arrive-t-il remplacer le plat de spaghetti dautrefois ? Sil y parvient, cest parce quil nest pas simple du
tout, il ne sagit pas seulement dun bus , support passif de transmission, mais dun routeur complexe :
- routage des messages : le bus interprte ltiquette du message pour identifier ladresse vers
laquelle il doit lorienter ;
- transcodage des donnes : si deux applications recourent des codages diffrents, le bus assure
la traduction entre les codes ;
- gestion des flux : du temps rel transactionnel jusquau traitement batch , le bus gre les
dlais de mise jour selon les besoins des diverses applications ; il comporte des files dattente ( buffers ) ; il
traite la concurrence (lorsque deux utilisateurs veulent modifier en mme temps une mme donne) et la
persistance (lorsquil est ncessaire de conserver en mmoire la valeur dune donne qui vient dtre modifie).

Les fonctions ainsi offertes par le bus soulagent dautant les applications : il est plus simple pour une
application denvoyer les messages au bus qui en assurera le routage que dinclure elle-mme un sous-
programme de communication, il en rsulte une conomie dchelle par concentration du code nagure
dispers dans les applications. Le bus EAI est donc un middleware trs riche, sa mise en oeuvre
suppose que les fonctions ci-dessus soient dfinies et paramtres, et sa prsentation par les commerciaux est
dune simplicit trompeuse. La multiplicit des codages dans les applications impose un traitement rigoureux du
transcodage voire une vrification manuelle des cas litigieux ou douteux. La multiplicit des mises jour
(quotidienne, hebdomadaire ou transactionnelle) impose une harmonisation chronologique des mises jour
avant la synchronisation des applications. Les diffrences de volumes de donnes changer impose
galement une harmonisation des canaux pour viter lencombrement des mmoires ou la perte des donnes
en sous capacit de traitement. Les inluctables rejets de linterface entre deux applications doivent tre
pralablement traits. Laccs simultan aux dossiers traits par le SI doit tre conu de faon viter que les
donnes dun utilisateur ncrasent ou ne modifient celles dun second utilisateur.

Paramtrage dun logiciel EAI

Au mme titre quun PGI est paramtr pour sadapter au mieux un besoin mtier, un EAI doit tre
paramtr pour mettre en uvre les interfaces dont le SI a besoin. Chacune des couches prsentes
prcdemment fait lobjet dun paramtrage. Le paramtrage dans une solution dEAI se matrialise au travers
d'une ou plusieurs interfaces graphiques qui permettent de dfinir les connecteurs utiliser, les transformations,
les routages et les processus mtier.
Par exemple, pour un projet dintgration particulier, le paramtrage consiste raliser les actions
suivantes :
- choix des connecteurs adquats, par exemple un connecteur JDBC pour la source et un connecteur
SAP pour la cible,
- paramtrage des connecteurs pour leur indiquer sur quelles machines fonctionner, quels logins
utiliser, sur quelles tables (pour la source) et BAPI (pour la cible) travailler,
 - choix des formats de la source (dans lexemple les champs de la table), de la cible (dans lexemple
les paramtres fournir la BAPI) et du format pivot,
- paramtrage des transformations ncessaires entre la source et le format pivot dune part et entre le
format pivot et la cible dautre part en utilisant une ou plusieurs fonctions prdfinies fournies par la plateforme
dintgration,
- choix du mode de routage entre la source et la cible, par exemple un Publish and Subscribe,
- paramtrage de la publication de lapplication source et de la souscription de lapplication cible dans le
Message Broker (dans la couche Routage).

Certaines offres dEAI ne fournissent pas dIHM pour raliser tous les paramtrages voqus
prcdemment. Par exemple, Oracle Interconnect permet de paramtrer graphiquement les transformations et
le routage. Par contre, les connecteurs sont paramtrer en mode ligne de commande et via des fichiers de
paramtrage diter manuellement. L'outil de paramtrage manipule gnralement le contenu d'un repository
utilis par la solution d'EAI pour stocker lensemble des informations ncessaires au fonctionnement de
linfrastructure. Ce repository (qui en pratique est parfois divis en plusieurs repositories) prend des formes trs
diverses allant d'une simple collection de fichiers de configuration une base de donnes relationnelle.

Si loutil choisi ne peut rpondre un besoin prcis, il est alors envisageable de raliser un
dveloppement spcifique au sein de la plate-forme dEAI. Ces dveloppements se font alors via un kit de
dveloppement (SDK) que loutil dEAI fournit. Il convient cependant daborder cette possibilit en dsespoir de
cause : au mme titre quil est dangereux de faire du spcifique sur un PGI, notamment cause des cots de
maintenance, le dveloppement spcifique dans loutil dEAI loigne dun des principes de base de lapproche
EAI qui est dintgrer rapidement et simplement les applications.

EAI stratgique ou EAI tactique ?

Sur le papier, le schma est sduisant. Avec leurs capacits de Workflow et la possibilit de crer des
super processus d'entreprises au-dessus des systmes en place, les meilleurs EAI apparaissent comme une
solution idale : Diffuser la bonne donne, au bon moment et aux bons acteurs, en constitue la nouvelle finalit.
Mais les entreprises ont t dues par les solutions d'EAI stratgique, prsentes bien souvent comme des
produits proches de l'espranto informatique, mme de rsoudre tous les problmes lis aux flux dans
l'entreprise.
Elles tudient donc d'un il complaisant les solutions d'EAI tactique, surfant sur la vague Open
Source : le premier diteur de solution d'EAI en France s'appelle Axway, diteur franais de solution d'EAI
tactique. Il devance mme, dans l'ordre, IBM, WebMethods, Kabira et SeeBeyond Ces initiatives bases sur
lOpen Source se concentrent principalement sur trois briques techniques : les connecteurs, le middleware
orient messages (MOM) et le courtier de messages : OpenAdaptor propose une architecture technique pour
dvelopper des connecteurs, Joram pour sa part propose un MOM JMS 1.1 et, enfin, Proteus se concentre sur
son message broker (courtier de messages). Ces outils sont plutt des briques techniques que de plates-
formes prtes l'emploi, et il n'existe pas de connecteurs applicatifs (SAP, Siebel, etc.) et trs peu de
connecteurs techniques (fichier, SQL, etc.). Les outils open source constituent donc, avant tout, un socle
technique intressant pour rpondre des problmatiques d'intgration spcifiques. Le cot d'une solution
d'EAI est li celui des connecteurs et du courtier de messages, qui sont vendus sparment. Les diteurs
commercialisent en effet la plate-forme avec un nombre minime de connecteurs techniques et facturent trs
cher les connecteurs applicatifs, qui apportent le retour sur investissement le plus rapide l'entreprise.

Le cot moyen d'un connecteur technique se situe autour de 30.000 e, quand un connecteur applicatif
peut atteindre plus de 150.000 e. SIl n'est sans doute pas souhaitable de se lancer dans un projet pharaonique
englobant l'ensemble du plan d'urbanisation, un des risques de ce type de projet tactique consiste en revanche
le limiter un projet technique. Il convient d'appliquer une dmarche par tapes de rvolution permanente et
d'obtenir une adhsion du ou des mtiers concerns afin d'assurer le succs du projet.
 Principaux
Nom de la Principales Prix moyen
Editeur modules Rfrences
solution caractristiques d'un projet
fonctionnels
aXway File Broker, A partir de
Plus de 5 000
aXway Integration Connecteurs : SAP, 80.000 e
clients, dont Dexia-
Broker, aXway Oracle, Siebel, (licence +
Crediop, British
Sentinel, Buniness WebSphere, service). Projet
aXway Telecom,
Integrator, WebLogic, Kabira
Axway Integration
Enterprise Objectswitch
Jobpartners, SFD, intgration
Suite Banksys, Mutualit sans
Integrator, Rseaux valeur
fonction publique transformation
Information ajoute Bolero.net,
Services (MFP de donnes :
Integrator, aXway Swift, EDI
Services)
SwiftNet. 50.000 e
Sunopsis V3, Connecteurs: Damart, Europe 1, Prix moyen
Sunopsis MQ Principales bases de Cofidis, Roche, (licence +
Sunopsis Sunopsis V3 (MOM), Sunopsis donnes, PGI et Lafuma, Cegetel a service) : de
XML Driver (JDBC GRC. Connectivit : fait son 80.000
Edition). JDBC, ODBC, JCA apparition, 120.000 e

Des exemples dEAI

Casino connecte ses applications spcifiques par des progiciels EAI du march, mais le pilotage des
processus mtier interviendra dans un second temps. Casino s'est engag dans une refonte de son systme
d'information selon une approche best of breed : choisir les composants progiciels les plus adapts au lieu
d'une offre intgre ou d'un dveloppement spcifique. A l'issue de cette refonte, une grande partie des
applications sera utilise via des clients lgers et intgrs, en s'appuyant sur l'EAI de Sybase. Casino a
d'ores et dj utilis l'EAI pour intgrer la comptabilit client SAP, l'annuaire LDAP, ainsi que le progiciel de suivi
et d'analyse d'incidents ou d'anomalies ARS, de Remedy. Le recours l'EAI sera ensuite tendu l'intgration
des progiciels de coeur de mtier. Le volume des changes pour SAP est de l'ordre de cinq mille factures par
jour, et de soixante-dix mille enregistrements pour le LDAP. Nos comptables souhaitaient voir, pour certains
clients, les mises jour en temps quasi rel. Nous avons donc conu une inter face au fil de l'eau depuis notre
rfrentiel client DB2. Le message MQ de mise jour est rcupr par eBiz Integrator. L'adaptateur SAP livre
ensuite l'information au format Idoc.

Au Crdit Lyonnais, la Direction des marchs actions de la banque a dcid de conserver l'ancien
systme informatique et d'y adjoindre une plate-forme d'EAI pour le traitement des flux. Crossworlds, rachet
entre-temps par IBM, est choisi.. Cette dmarche donne naissance une logique mtier : il s'agit de replacer
les clients et le front-office au cur de l'activit. Auparavant le traitement d'une transaction par un trader incluait
plusieurs interventions manuelles. Outre l'impossibilit de traiter les volumes croissants, les erreurs taient
nombreuses. Maintenant, c'est le trader qui saisit lui-mme son ordre. Ensuite, la plate-forme EAI distribue cet
ordre dans le systme d'information : conomies et vision globale des processus mtier.

Le rseau Assurance de Groupama distribuant les services bancaires, le besoin d'intgration avec le
systme d'information de l'assureur tait vident. Les quipes de Groupama ont donn une orientation mtier
leur projet d'intgration : dfinir avec prcision les diffrents processus mtier lis la banque, et les modes
opratoires qui y sont rattachs, grce au rfrentiel de Mega. Afin d'viter toute rplication de donnes inutile,
Groupama banque souhaitait s'appuyer sur les informations gnres depuis le front-office (Siebel) de l'activit
Assurance. De mme, toutes les informations nouvellement saisies par le service bancaire ou assurance se
devaient d'tre rpercutes automatiquement dans le back-office, aprs vrification et transformation. L'EAI de
Vitria se voit donc confier cette tche et sert de vritable passerelle entre le back-office et le front-office. La
mise en place rapide de la solution d'EAI a permis au service bancaire d'tre oprationnel dans les dlais. Elle
a galement renforc la matrise des flux de donnes et fait diminuer de manire considrable les erreurs et les
tches d'administration.
 Les 260 "Espaces SFR" jouent un rle cl dans la politique de satisfaction des abonns. L'oprateur
souhaite en faire de vritables espaces de services proximit de ses clients. Afin de remplir ce rle, la Socit
financire de distribution (SFD), filiale de Cegetel qui gre l'ensemble des "Espaces SFR", a d remettre
niveau son systme d'information pour grer la logistique des boutiques. Cette chane tait trop fortement
sollicite et devait en plus absorber les rachats successifs de PhoneShop et d'Aloha : Le progiciel "SAP Retail",
le systme de mdiation et le systme d'encaissement avaient du mal supporter la monte en charge
provoque par la croissance externe. Le volume et la diversit des flux grer, le manque de fiabilit dans le
processus d'changes avec les boutiques, l'absence d'outils de supervision ainsi que la trop grande
htrognit des protocoles de communication ont pouss la SFD mettre en place une plate-forme
d'change EAI spcialise dans la logistique. La Socit financire de distribution a retenu la solution Axway
Integrator Suite de l'diteur franais Axway. Cette plate-forme EAI centralise les changes, contrle, transforme
et route les donnes. La fiabilit des donnes a permis la filiale de Cegetel de grer l'approvisionnement de
ses boutiques en temps rel, rduisant d'autant les ruptures de stock et augmentant le niveau de satisfaction de
ses clients.
2. L'intgration entre organisations : EDI, XML, Web Services

2.1 Les mtadonnes EDI

Ce qui diffrencie lEDI de la simple communication est le fait que les donnes soient prsentes selon
une norme reconnue au niveau sectoriel, national ou international. Cette norme va dfinir les termes
commerciaux utiliser, la faon dont le document est organis en segments, lordre de ces segments,
quels sont les contrles oprer pour vrifier, la rception, que le message est correctement reu, etc.
La norme dfinit un langage commun avec une syntaxe et une smantique trs prcises.

Les normes sectorielles.

De trs nombreuses normes ont t dfinies dans diffrents cadres; citons par exemple:
- au niveau national (France): Galia (constructeurs automobiles), Gencod (distribution), Cefic (chimie),
Innovert (transport);
- au niveau europen: GTF (transport terrestre), Odette (construction automobile), Edifice (construction
lectronique), Ediconstruct (travaux publics);
- au niveau International: Iata (transport arien).
Mais la multiplicit de ces normes se rvle trs vite gnante pour faire face aux besoins du commerce
et des changes intersectoriels (par exemple, une entreprise fabriquant des composants lectroniques
pour lautomobile devrait travailler avec les normes Odette et Edifice, uniquement en Europe).

Cest pour cette raison quest dvelopp, sous la tutelle des Nations unies, un langage commun:
EDIFACT (change de donnes informatises pour ladministration, le commerce et les transports). La
norme EDIFACT, mondiale et multisectorielle, devrait rapidement remplacer les diverses normes
actuellement en service.

Les normes internationales.

Les diffrentes instances de normalisation, EDIFRANCE lAfnor (Paris), EDIFACT-Board au Comit
Europen de Normalisation (Bruxelles) et la CEE/ONU avec lISO (Genve) ont vocation favoriser le
dveloppement de la normalisation des donnes et des messages pouvant supporter les changes
commerciaux entre des organisations nationales et internationales distinctes. Des groupes de travail
sectoriels ou intersectoriels, sous lgide dEDIFRANCE et de lEDIFACT-BOARD dveloppent des
messages normaliss dits UNS, United Nations Standard Message. Lensemble des administrations et des
entreprises prives et publiques peut participer aux travaux des instances de normalisation. Une vingtaine
de groupes professionnels de structures juridiques trs diffrentes oeuvrent aussi pour le dveloppement
de lEDI. On peut citer, comme exemple, lassociation EDISANTE, cre linitiative des acteurs du
systme de sant et les associations EDITRANSPORT et EDICONSTRUCT cres linitiative
dentreprises du transport, de la construction, des travaux publics, de leurs partenaires et de leur ministre
de tutelle.

On a reprsent ici une facture papier et son quivalent dmatrialis sous forme de message
EDIFACT INVOIC . Les segments de services servent dlimiter un interchange tel que celui
reprsent ici: UNZ dlimite un message, UNS dlimite une section (une partie cohrente du message, ici
lentte ou le dtail facture), etc....
 FACTURE

Expditeur: Rfrence: FD 10
FALLERY
60, rue des premires cabanes
75016 PARIS date: 14 JUIN 2012
Destinataire:
NORD SUD
42 rue de Bruxelles
34205 MONTPELLIER CEDEX
Adresse de livraison:
NORD SUD
42 rue de Bruxelles
34205 MONTPELLIER CEDEX

Conditions de transport Conditions de paiement

90 JOURS

Dsignation Quantit Prix Montant

Unit

CD ROM rf. 123 5 285 1425

Message EDIFACT INVOIC

UNB+UNOA 1+33333:33+444 44+960614

:120000+REF+PASSW+INVOIC+1
UNH+FACTURE+INVOIC:1
BGM+250+DF 10+960614
NAD+SU+3333:33++FALLERY
+60 rue des premires cabanes
+7 5 016 + + PA R I S
NAD+BY++NORD SUD:
42 rue de Bruxelles: 34205 MONTPELLIER CEDEX
NAD+CN++NORD SUD
+42 rue de Bruxelles
+34205++ MONTPELLIER CEDEX+++FR
PAT+01+++05:03:01:90+++
Paiement 90 jours:Chque bancaire
lordre de FALLERY
U N S + D
LIN+++123:VN++5:EA+285.00 PE
U N S + S
TMA+1425.00
UNT+15+FACTURE
UNZ+ 1 + RE FE G

Le commerce lectronique reste nanmoins confin aujourdhui au domaine des grandes socits.
Mais lintgration de technologies usuelles et peu coteuses commencent faire changer les choses.
Beaucoup de PME commencent donc mettre en avant leurs propres outils de cration et de gestion de
formulaires lectroniques. Forms chez Microsoft, Informs chez Novell, Formflow etc.... sont des solutions
proposes par les grands diteurs pour le commerce lectronique ceux qui nont pas toujours les moyens
de soffrir une vritable solution EDI. Avec lEFI, lEchange de Formulaires Electroniques, un bureau
distant ou un fournisseur peuvent recevoir et ouvrir un formulaire lectronique envoy par le sige social
 ou par un client, mettre automatiquement jour leur base de donnes partir des informations reues,
router le formulaire en interne pour traitement, remplir le formulaire-rponse appropri (tat de stock, devis,
facture...) et le renvoyer au sige par transfert de fichier binaire.

Les utilisateurs d'Edifact, organiss en 10 secteurs d'utilisation et aussi dans l'EWG (Edifact Working
Group) coordonnent le dveloppement d'Edifact depuis l'origine et ils veulent plutt traduire telle quelle
la smantique Edifact en XML (EDI-Light) limitant ainsi le cot de la migration, alors qu'ebXML voudrait
privilgier l'amlioration qualitative et radicale.

2.2 Les mtadonnes XML : vers le web smantique

Normes et Standards de mtadonnes

On peut dfinir les mtadonnes comme des donnes relatives des donnes . Ainsi, les contenus
de livres sont des donnes, mais des rpertoires de bibliothque constituent des mtadonnes parce quils
contiennent des informations sur les livres et leurs contenus. Les mtadonnes sont donc des informations
propos de ressources disponibles (sur le Web ou ailleurs) et exploitables par des logiciels (des agents
intelligents ou autres programmes). Ces mtadonnes peuvent tre incluses dans les ressources elles-mmes,
ou enregistres dans un fichier spar selon le type du contenu (par exemple il nest pas ais dinclure des
mtadonnes dans une image). Le web est aujourd'hui compos de liens simples et universels mais
smantiquement peu structurants, les mtadonnes sont peu ou mal utilises. Les moteurs de recherche
deviennent donc ultra sophistiqus mais restent imparfaits. La ncessit de liens riches, de mtadonnes
structures, sres et signifiantes se fait de plus en plus sentir. Le web smantique veut tre une rponse
ce besoin. Il permettrait de revenir une structure smantiquement riche, de type base de donnes,
oriente ressources, tout en conservant les mtadonnes dans les documents. Lintention du Web
smantique est de sappuyer, plutt que sur la structure textuelle du document, sur des descriptions
structures de linformation qu'il contient, pour construire des documents organiss et comprhensibles par des
logiciels (des moteurs de recherche ou des agents qui parcourent le Web de faon automatique). Aujourdhui :
le Web est exploit par des personnes qui recherchent des informations via un moteur de recherche et qui
exploitent elles-mmes le rsultat. Demain : le Web sera exploit en priorit par des machines qui traiteront
elles-mmes les questions poses par des personnes, et qui dlivreront les rsultats ces personnes.
http://www.semanticweb.org/

La capacit des mtadonnes faciliter

laccs aux ressources en ligne dpend bien
videmment de lexistence dun standard, dot
de deux proprits : prennit et aussi
possibilit dvolution. Une norme est un
ensemble de rgles de conformit, dictes par
un organisme de normalisation au niveau
national ou international (ISO, Cefact-ONU..).
Un standard est un ensemble de
recommandations manant d'un groupe
reprsentatif d'utilisateurs runis autour d'un
forum, comme l'IETF (Internet Engineering Task
Force), le W3C (World Wide Web Consortium),
le Dublin Core.

a) Dublin Core

Une premire ide est dinsrer des meta-tags normaliss dans une page html, et lexemple le plus
connu de mtadonnes est le Dublin Core Metadata Initiative , standard de facto dvelopp par un forum
international et interdisciplinaire, et constitu de quinze lments de description des ressources en ligne. Ces
15 lments sont demeurs inchangs depuis 1996. Leur utilisation n'est pas sujette un ordre tabli, et
chaque lment est optionnel, tout en pouvant tre rpt : Titre, Auteur, Sujet, Description, diteur,
Collaborateur, Date, Relation, Type de ressource, Format, Identificateur, Source, Langue, Porte, Droits. Afin
daccrotre la spcificit des mtadonnes, le Dublin Core peut tre qualifi avec deux types de qualificatifs :
Les qualificatifs d'lment prcisent la signification smantique de certains lments et les qualificatifs de
valeur qui prcisent la valeur attribue un lment au sein d'un registre de mtadonnes particulier.

Les 15 lments descriptifs du Dublin Core peuvent tre modliss (en RDF par exemple, voir plus
loin) pour sadapter chaque application. L'importance croissante du Dublin Core dans la description des
ressources lectroniques peut tre attribue sa simplicit, son extensibilit et sa flexibilit. En effet
lindexation dune ressource peut bien sr tre faite par son propritaire (les balises META ne sont pas limites,
et on peut donc utiliser ces balises tendues pour faire une ontologie dannotation , comme par exemple
avec SHOE, Simple html ontology extensions), mais dans la plupart de cas, lindexeur nest pas le propritaire
de ressources, il na pas le droit de mettre les mtadonnes dans le contenu de ressources, et les lments de
mtadonnes doivent donc tre conservs dans un registre spar des ressources (cest lintrt de RDF,
puisque les mtadonnes peuvent alors tre stockes ailleurs et rutilises dans plusieurs applications). Dans
un environnement vraiment collaboratif on doit mme pouvoir lire les proprits dune ressource sans rendre
compte de son contenu, on doit par exemple pouvoir indexer les ressources par proprits (WebDAV est alors
un protocole, extension du protocole dchange HTTP, qui permet dattacher des proprits sur les ressources
Web).
<TITLE>Dublin Core Metadata Element Set: Resource
Page</TITLE>
<META name = "DC.subject" content = "dublin core
metadata element set">
<META name = "DC.subject" content = "networked object
description">
<META name = "DC.publisher" content = "OCLC Online
Computer Library Center, Inc.">
<META name = "DC.author" type = "name" scheme =
"AACR2" content = "Weibel, Stuart L..">
<META name = "DC.author" type = "email" content =
"weibel@oclc.org">
<META name = "DC.title" content = "Dublin Core Element
Set Reference Page">
<META name = "DC.date" type = "creation" scheme =
"ISO" content = "1996-05-28">
<META name = "DC.form" scheme = "IMT" content="text/
html">
<META name = "DC.language" scheme = "ISO 639"
content="en">
<META name = "DC.identifier" scheme = "URL" content =
"http://purl.oclc.org/metadata/dublin_core">

b) XML, lavenir des changes de documents

La deuxime ide est de structurer logiquement le contenu des documents de manire pouvoir
sparer le fond et la forme. XML peut tre considr comme un mtalangage permettant de dcrire dautres
langages de balisage spcialiss pour des activits particulires : XHTML dans la conception des pages
Internet, WML pour le Wap des tlphones mobiles, MathML pour les mathmatiques, mais aussi des
langages pour lapprentissage, la chimie, la finance, etc..
<?xml version="1.0" standalone="yes"?>
<!DOCTYPE parent [ <?xml version="1.0 "standalone="no"?>
<!DOCTYPE parent SYSTEM "parent.dtd">
<!ELEMENT parent (garcon,fille)> <parent>
<garcon>Loic</garcon>
<!ELEMENT garcon (#PCDATA)> <fille>Marine</fille>
</parent>
<!ELEMENT fille (#PCDATA)>
en stockant dans le mme rpertoire une DTD
]> externe "parent.dtd":
<parent>
<garcon>Loic</garcon> <!ELEMENT parent (garcon,fille)>
<fille>Marine</fille> <!ELEMENT garcon (#PCDATA)>
</parent> <!ELEMENT fille (#PCDATA)>
Avec une DTD interne Avec une DTD externe

XML apparat comme le moyen pour dcrire la fois mtadonnes et structure des documents : Une DTD
(Dfinition de Type de Document) est la dfinition dun langage de balisage particulier, elle dcrit la
structure logique dune classe de documents, cest dire l'ensemble des rgles et des proprits que doivent
suivre les documents XML de cette classe. La DTD peut tre interne ou externe. Les exemples sont de
Vanlancker.Luc@ccim.be

Mais il est surtout possible de faire rfrence une DTD externe situ sur un autre site, et plusieurs
concepteurs peuvent donc se mettre d'accord pour utiliser une DTD commune pour changer leurs donnes,
comme pour par exemple le XHTML :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//FR"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

En XML, il est possible davoir certaines parties associes une DTD, et dautres une autre DTD . La
dfinition d'un espace de nom permet d'associer toutes les balises d'un langage un groupe afin d'tre
capable de mler diffrents langage balise (pouvoir mettre du HTML, MathML, et CML dans un mme
document). Il est galement possible danalyser des documents sans leur imposer une structure, des
documents XML peuvent alors tre bien forms (leur DTD nest pas connue), mais non valides (respectant
strictement une DTD donne). Certains analyseurs (parser ou parseur) peuvent lire un document XML, mais
sans pouvoir vrifier leur DTD, cest le cas dIE5.

c) La description des balises XML : le RDF

Au niveau des ressources, il faut pouvoir les nommer l'aide de descripteurs universels (URL, URN, URC),
et il est ncessaire de pouvoir normaliser la structure des ressources ( cest le rle des DTD: Document Type
Definition). XML structure ainsi les donnes, mais il ne dfinit pas de sens , de standard pour exprimer les
mtadonnes.

Cest l le rle de RDF (Resource Description Framework), qualifi de mtalangage de mtadonnes. La

couche mtadonnes contient les outils ncessaires la description de ces ressources : un modle
d'assertion (dfinition des rgles de base : cest le rle des RDF Ressource Description Framework qui
permettent les annotations smantiques dcrivant le contenu des documents), une normalisation de ces
modles de descriptions des mtadonnes (contraintes formelles sur les mtadonnes : cest le rle des
Schmas RDFs qui permettent la dfinition de classes, des types de proprits, la dclaration dhritage), et
enfin les ontologies (dfinition des concepts et des relations)
Langage de Agents Langage Langage de Agents Langage
requtes intelligents de preuve requtes de preuve
intelligent
s
Ontologies Modle Descriptions Ontologies : RDFs :
Crateur li
RDF : une seule date de
mta dassertions formelles mta Professeur Crateur X cration

Descriptions
Nommage Ressource URL, URN, Ressource XMLs, DTD
formelles URC

Une syntaxe : XML

La recherche de donnes est enfin assure par des agents intelligents. Le moteur analyse les requtes en
consultant les ontologies (la dernire brique du web smantique est constitue par le langage de preuve, qui
permet d'authentifier un document).

Dans RDF un ensemble de proprits dcrivant une ressource est appel une Description. Lassociation
d une ressource, dun nom de proprit et de la valeur de cette proprit pour la ressource est une assertion
pouvant tre reprsente par un triplet (proprit, ressource, valeur). Ainsi la phrase Fallery est l'auteur de
la ressource http://www.isim.fr/cours peut tre modlise par le triplet : {auteur, http://www.isim.fr/cours,
Fallery}. Une description RDF, cest--dire un ensemble dassertions, peut alors tre exprime en XML.

<?xml version="1.0" encoding ="iso-8859-1" ?>

<RDF
<Description
about=" http://www.isim.fr/cours ">
<auteur>Fallery<auteur>
</Description>

On voit donc que RDF remplace une suite de META tags, autre exemple :

<? xml version="1.0" ?>

<RDF xmlns = "http://w3.org/TR/1999/PR-rdf-syntax-19990105#" xmlns:DC = "http://purl.org/DC#" >
<Description about = "http://dstc.com.au/report.html" >
<DC:Title> The Future of Metadata </DC:Title>
<DC:Creator> Jacky Crystal </DC:Creator>
<DC:Date> 1998-01-01 </DC:Date>
<DC:Subject> Metadata, RDF, Dublin Core </DC:Subject>
</Description>
</RDF>

ici l'objet : http://w3.org/TR/1999/PR-rdf-syntax-19990105# est dcrit dans l'lment RDF :

<Description about= ...> ...
</Description>
par les proprits :
Title, Creator, Date, Subject, dfinies dans le domaine xmlns:DC = http://purl.org/DC#

Divers standards cohabitent pour exprimer les mtadonnes. La lutte est engag entre les gants
(Vignette, Interwoven, Sellent, Documentum, MS..) et les start-up (Profium, Sinequa..). Le RDF (Ressource
Description fait l'objet d'un groupe de travail au W3C, et Adobe a annonc que tous ses logiciels pourront
bientt exporter des documents sous ce format.
 Mais Topic Maps, est une norme ISO qui fait lobjet de nombreux dveloppements sur le march de la
gestion des contenus de l'entreprise (ECM, Enterprise Content Management)
http://www.universimmedia.com/index.htm. A linterieur dun theme , Topic Maps uilise les concepts
de topic (topic type, name) et doccurrence (occurrence role) pour organiser les informations sur sujet et
crer des index. Pour dcrire les relations entre topics, on utilise topic association (association type,
association role), et on peut associer des proprites aux topics en utilisant facet , ou donner des limites de
validit (scope)

d) Le paysage de la standardisation XML

XML est rput faciliter les changes d'informations en structurant les donnes de manire standardise.
Mais le problme vient en l'occurrence de la souplesse fournie par XML qui permet chacun de dfinir un
standard... sur mesure ! Cette possibilit a dj t largement utilise, notamment par les diffrentes branches
d'activits et types d'applications qui ont dfini leur propres standards, et l'on estime leur nombre plus de
500 ! On assiste maintenant la naissance d'initiatives destines recenser ces standards, et dfinir des
moyens de les fdrer. Le monde des standards pour l'interoprabilit ne se simplifie pas, mais volue trs
vite.

Pour le domaine E-business , on repre aujourdhui au moins quatre groupes

dacteurs (http://www.vendr-edi.net/) :

- d'un ct, Oasis (avec Sun) et le MoU (Memorandum of Understanding), avec le soutien des organismes
de normalisation (Cefact-ONU Edifact). OASIS se positionne en concurrent des rflexions du W3C sur le
Semantic Web, et continue la mise au point de ebXML, approche top down classique. Les pays comme les
USA o Edifact est peu implant privilgient ce "bond en avant" direct vers XML que reprsenterait ebXML.
Mais si cette standardisation "officielle" ne dbouche pas vite, la stabilit attendue par les entreprises pour
passer XML viendrait alors des standards " de facto "

- car de lautre ct, la WS-I (Web Services Interoperability Organisation) qui regroupe offreurs et grands
utilisateurs industriels de produits bass sur XML (avec Microsoft, IBM, SAP, Oracle, Dassault Systmes) se
veut un outil de la customer business process integration avec notamment les standards UDDI pour les
registres et SOAP pour les procdures distance. Tous proposent dj des spcifications construites autour de
XML : Ariba avec le cXML, CommerceOne avec le XCBL, IBM avec le SpML, Microsoft avec Biztalk

- absent des deux, le W3C, qui est occup coordonner entre eux les nombreux standards de la galaxie
XML (XML Schema, XSLT, Xquery, Xpointer, " namespaces "), et qui se situe mi-chemin entre les membres
du MoU et la WS-I. XML ncessite une bote outils cohrente et simple utiliser, o chaque outil complte les
autres, et il y a encore du travail faire au W3C!

Pour le domaine E-Formation , dans un march extrmement concurrentiel, sous limpulsion pressante
de laronautique (AICC Aviation Industry Committee) et du dpartement de la dfense aux USA (ADL
Advanced Distributed Learning Initiative), chacune des 500 plates-formes de formation en ligne (LMS) se vante
aujourdhui dune conformit des acronymes parfois obscurs (DC, LOM, AICC-SCORM..). Dans cette
effervescence, une spcification de lindustrie a vocation devenir un standard dans un consortium,
reconnu ensuite comme une norme internationale, et enfin dcline en diffrents profils dapplication et en
bonnes pratiques.
Le LOM (Learning Objects Model), bas sur le travail original dARIADNE en Europe (1995) et adopt
ensuite lISO en 2002 sur proposition de lIEEE (Institute of Electrical and Electronics Engineers), se prsente
comme un ensemble descriptif de meta-donnes composs de quatre-vingt balises XML

Le LOM reprend ainsi toutes les mtadonnes du Dublin Core en les dtaillant (la dlgation
franaise a russi faire rejeter le projet amricain didentifiant unique pour les personnes), et en ajoutant une
partie Education avec les caractristiques pdagogiques de l'Objet. Cette norme gnrale LOM donne
ensuite lieu des profils dapplication spcifiques : Celebrate en Europe, Normantic au Canada (Chouinard
2002). Avec ce concept dObjet dcrit par 9 catgories et leurs 71 champs (Typical Learning Time, Level of
interactivity..) on considre bien ici que la connaissance est prdfinie puis transfre, sans dpendre de
linteraction : un Objet LOM ne peut tre dcrit que par UN jeu de catgories. La catgorie Learning Resource
Type est souvent critique, car elle mlange des types et des fonctions (exercise, simulation, questionnaire,
diagram, figure, graph, index, slide, table, narrative text, exam, experiment, problem statement, self
assessment, lecture), la catgorie Semantic Density nest quune mesure subjective donne par un auteur, la
catgorie Title ne permet quune seule valeur car la langue est considre comme un lment interchangeable,
les critiques sont nombreuses.. Mais la reprise de la discussion au SC36 sur les concepts dObjet et/ou de
Ressource pourrait dboucher sur une norme dite LRM, acceptant des descriptions multiples, ce que Downes
(2003) appelle un vritable Profil , en utilisant les schmas RDFs, qui offrent la possibilit davoir diffrents
domaines de noms (namespace : xmlns) o peuvent se dfinir diffrents jeux de proprits (ici quatre
balises DC) qui dcrivent une mme ressource (ici http://polytech.fr/report.html) :

<? xml version="1.0" ?>

<RDF xmlns = "http://w3.org/TR/1999/PR-rdf-syntax-19990105#"
xmlns:DC = "http://purl.org/DC/elements/1.1">
<Description about = "http://polytech.fr/report.html" >
<DC:Title> Normalisation </DC:Title>
<DC:Creator> Bernard Fallery </DC:Creator>
<DC:Date> 1998-01-01 </DC:Date>
<DC:Subject> Metadata, RDF, Dublin Core </DC:Subject>
</Description>
</RDF>

2.3 Les Web Services

Les Web Services se fondent sur une communication point point, mais avec un langage standardis
et ouvert. Les Web Services sont, l'origine, destins permettre d'agrger les services applicatifs de plusieurs
entreprises entre elles.
Les services Web poursuivent un vieux rve de l'informatique: celui d'un monde o les ressources
informatiques pourraient interoprer travers un rseau, indpendamment de leurs plates-formes d'origine.
Tandis que l'EAI se fonde sur une centralisation des flux et tente de gommer le point point entre les
applications, les Web Services se fondent sur une communication point point, mais avec un langage
standardis et ouvert. L'EAI est d'abord une dmarche d'intgration applicative ex-post interne des
entreprises alors que les Web Services sont, l'origine, destins permettre ex-ante d'agrger les services
applicatifs de plusieurs entreprises entre elles. Les Web services, apparus avec la mouvance Internet et le
dveloppement rapide des applications client-serveur accessibles via un navigateur Web, se veulent un
aboutissement de la logique des applications distribues. Ce concept peut tre analys comme une rponse au
dsir des entreprises et des administrations de relier diffrents composants logiciels internes et externes.

Deux protocoles fondamentaux sont utiliss : SOAP (Simple Object Access Protocol) qui dfinit la
structure des messages XML utiliss par les diffrentes applications pour communiquer ensemble ; WSDL
(Web Services Description Language) qui est un langage de contrat dcrivant la faon pour une application
d'invoquer une autre application : standardisation des schmas XML utiliss pour tablir une connexion entre
metteurs et rcepteurs. Enfin, dans l'ide d'applications distribues sur le rseau Internet et utilisables comme
des services, il est ncessaire de disposer d'une cartographie interrogeable de ces services : c'est l'objet des
annuaires de services UDDI (Universal Description Discovery and Integration) : un annuaire mondial
d'entreprises bas sur le Web, intgrant toutes sortes d'entres (nom, carte d'identit des socits, description
des produits et des services, etc.), son objectif terme est d'automatiser les communications entre prestataires,
clients, etc..

Un service Web est dcrit dans un document WSDL, prcisant les mthodes pouvant tre invoques, leur
signature, et les points d'accs du service (URL, port, etc.). Ces mthodes sont accessibles via SOAP : la
requte et la rponse sont des messages XML transports par HTTP. Un service Web est accessible depuis
n'importe quelle plate-forme ou langage de programmation. On peut utiliser un service Web pour exporter des
fonctionnalits d'une application et les rendre accessibles via des protocoles standards. Le service Web sert
alors d'interface d'accs l'application, et dialogue avec elle au moyen de middleware (Corba, RMI, DCOM,
EJB, etc.).

SOAP est un protocole d'change de messages dans un milieu dcentralis o le seul pr-requis
devrait tre de pouvoir utiliser le protocole HTTP. SOAP a pour principe d'changer des messages HTTP (ou
SMTP) dont le corps est un fichier XML. SOAP dfinit aussi un RPC (Remote Procedure Call) qui rsout
certains problmes soulevs par les technologies telles que CORBA ou DCOM souvent difficiles mettre en
uvre. SOAP a pour vocation d'tre une spcification simple mettre en uvre, et de fonctionner sur toutes
les plates-formes et pour tous les langages de programmation. En dfinissant trop de services, on complique
l'utilisation de SOAP et on risque de perdre la portabilit (La scurit peut tre garantie au niveau du transport
ou par le biais d'extensions SOAP. Par exemple, au niveau du transport, il est possible de passer par
HTTPS).

WSDL est un langage qui permet de dcrire de faon prcise les services Web, en incluant des dtails
tels que les protocoles, les serveurs, les ports utiliss, les oprations pouvant tre effectues, les formats des
messages d'entre et de sortie, et les exceptions pouvant tre renvoyes. WSDL est le point d'entre du
service : on y trouve la localisation du service, et les oprations qu'il est possible d'invoquer en utilisant SOAP.

Mais ce socle initial de la technologie des Web Services ncessite souvent de se mettre aussi d'accord
sur d'autres dispositifs communs : L'intgrit des transactions ? La scurit ? Comment grer l'excution d'un
processus applicatif impliquant plusieurs Web Services ? Comment publier un Web Services au sein d'une
interface utilisateur ? Comment dfinir un processus mtier en environnement B to B ? Comment structurer les
documents commerciaux changs et dcrire les donnes mtier qu'ils contiennent ? Dans la constitution des
briques des Web Services, la stratgie de Microsoft et IBM au consortium WS-I, consiste rpondre aux
enjeux en partant des couches basses (SOAP). L'autre tendance, reprsente par le consortium Oasis et le
projet ebXML tente de donner une coloration mtier aux protocoles de base. Le but est de faire communiquer
et collaborer les applications :
1. Interfacer : extraire et injecter des donnes dans une application. Pour cela on utilise les services
Web (et en particulier WSDL), qui ont l'avantage de pouvoir tre accds partir de n'importe quel langage de
programmation et qui fonctionne sur n'importe quelle plate-forme. WSDL permet de donner une description
normalise des fonctionnalits offertes par les applications.
2. Transformer : convertir les donnes. C'est le rle de XSLT. Cela permet en particulier de convertir
des informations comprises par une application en informations comprises par une autre application. Par
exemple, si une application de gestion des commandes transmet une description de commande une
application de facturation dans le but de gnrer une facture, et que ces deux applications n'ont pas la mme
faon de modliser une commande, une opration de transformation est ncessaire :
3. Router : transporter les donnes vers le destinataire. Pour cela on utilise SOAP, qui peut tre utilis
pour une communication synchrone ou asynchrone.
4. Grer : suivre l'tat du processus. Formellement, un processus mtier peut tre dfini comme un
enchanement d'activits incluant une interaction entre participants, dans le but de raliser un objectif mtier.
Dans un processus mtier, on tient compte des diffrents participants d'une opration, de leur rle, de l'objectif
de cette opration et des moyens mis en uvre (messages, documents). Un processus mtier dcrit des
activits et leur squencement. Le problme de la reprsentation des processus mtiers n'est pas nouveau
mais BPML est un standard mergeant : Un processus e-business est compos de deux parties : Une interface
publique : dfinition du dialogue (RosettaNet, ebXML, Biztalk.org ou autre), prcisant l'interaction entre les
participants du processus e-business. Elle est commune tous les participants. Deux interfaces prives (une
par partenaire) : dfinition des processus mtiers implments par chaque partenaire.