L`intégration de la chaine logistique ERP, DW, EAI

L'intégration de la chaine logistique
ERP, DW, EAI … EDI, XML, Web Services
1. L'intégration dans une organisation : ERP, DW, EAI
1. L'ERP impose de repenser l’existant « de production » en profondeur, à la fois les données et les
processus. Un ERP propose d’intégrer les applications (les modules) en les faisant partager en temps réel une
information commune stockée au sein de sa base de données, grâce à la redéfinition des processus et à sa
base de données unique. L’architecture devient modulaire, mais l’existant ne peut pas être pérennisé.
2. L’entrepôt de données propose l’extraction (ETL) de l’information à partir des différentes bases de
données du SI, puis sa diffusion vers un entrepôt de données (DW) pour permettre traitement et analyse (BI). Il
impose ainsi la re-structuration des données, leur organisation, leur historisation et leur mise à disposition.
L’architecture est arborescente et l’existant « de production » est pérennisé.
3. Les architectures EAI proposent d’homogénéiser le SI et pérenniser l’existant, en instituant une
plate-forme d’intégration (passerelles de type middleware, architecture à la fois modulaire et arborescente) à
partir des bases de données du SI existantes et en utilisant les applications existantes. En réalité les pratiques
d’interfaçage n’intègrent 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 L’architecture ERP, une intégration « a priori »
Au sein d’un ERP-PGI l’intégration est effective :
(1) un référentiel unique (UNE seule Base de Données)
(2) une uniformisation des interfaces et une unicité d’administration du système
(3) la possibilité de paramétrer le progiciel en utilisant les processus préprogrammés
Toutes les tailles, tous les secteurs et toutes les activités sont accessibles aux PGI.
Si le PGI était à lui seul le système d’information de gestion de l’entreprise – ce qu’il est rarement mais ce que
ses fonctionnalités lui permettent théoriquement – il pourrait donc assurer à la fois la cohérence et la capacité
de changement, mais des cohabitations sont inéluctables avec diverses applications :
1. La migration. Implanter un PGI impose tout d’abord de le rendre compatible avec la plate forme
informatique (système d’exploitation, bases de données…). Les données de gestion indispensables sont
stockées par l’organisation au sein de bases de données historiques qu’il faudra intégrer (migration ou reprise).
Faire fonctionner un PGI nécessite donc, pendant une période transitoire au minimum, de conserver les
applications antérieures et de les faire fonctionner simultanément avec celle de le PGI.
2. Le spécifique. Implanter un PGI n’implique pour l’organisation ni d’utiliser la totalité des modules, ni
d’abandonner les applications spécifiques antérieures. Implanter un PGI ne garantit pas de façon automatique
que toutes les fonctionnalités et en particulier les fonctionnalités de type métiers soient présentes et/ou
satisfaisantes. Les données de gestion de type historiques et/ou volumineuses sont stockées et traitées au sein
de bases de données qui ne sont pas celles du PGI, et qui imposent donc de concevoir et d’intégrer des
applications de type passerelles entre les 2 systèmes.
3. La connexion avec l'extérieur. Le PGI est confronté aux données (clients, fournisseurs…) et
applications (CRM, SCM…) en contact avec l’environnement extérieur, ces échanges doivent pouvoir être
possibles et donc les applications qui les traitent doivent être intégrées.
L'ère des progiciels de gestion intégrés monolithiques semble donc révolue. Paramétrer des PGI ne
suffit plus à répondre aux exigences d'interopérabilité auxquelles doivent répondre les systèmes d'information :
processus distribués B-to-B, ouverture à la gestion de la relation client et de la chaîne logistique, sécurité 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 bâtissant l'architecture ESA (Enterprise Services Architecture) : «
Nous avons transformé les objets métier de SAP en composants interopérables, pour substituer un standard
à la notion propriétaire de Bapi, Business API ». Par une simple requête Soap, les développeurs peuvent alors
appeler les objets métier (procédures fonctionnelles), installés au coeur des PGI.
ERP : avantages et difficultés
S’agissant des avantages relatifs des ERP, ils sont d’ordre technique, opérationnelle et stratégique.
Sans développer sur les différents avantages techniques largement, rappelons que les entreprises adoptent
un ERP afin de profiter d’une homogénéité interfonctionnelle et de disposer d’un seul et même système avec
une seule et même base de données, une même interface hommes-machine pour tous les postes de travail et
un seul système d’administration pour les différentes applications. L’adoption met fin aux problèmes résultant
de l’acquisition autonome de logiciels par chaque unité tel que les incompatibilités de données (ressaisies de
données…) ou l’existence de systèmes parallèles dupliquant les mêmes fonctionnalités. Elle réduit les tâches
de maintenance des interfaces. La portabilité large des ERP tant au niveau des systèmes d’exploitation que de
SGBD ou des réseaux et leur modularité permet aux entreprises de faire facilement évoluer leur système
d’information.
Les avantages relatifs sont également organisationnels, l’ERP vient remettre en cause la conception
d’une organisation fondée sur la spécialisation fonctionnelle. L’organisation devient transversale, elle n’est plus
découpée par grandes fonctions mais par des macro-processus qui la traversent (El Amrani 2004). L’unité
d’analyse n’est plus la fonction en tant que regroupement d’activités similaires mais le processus qui traverse
les principales fonctions de l’entreprise (Davenport, Short, 1990). L’adoption facilite l’acquisition et la diffusion
d’informations à l’intérieur et à l’extérieur de l’entreprise en ôtant certaines restrictions et en rendant les
requêtes plus aisées. Permettant de regrouper diverses applications fonctionnelles autour d’une seule base de
données, les différents ERP dont les plus connus SAP, Oracle applications, JD Edwards, PeopleSoft sont
conçus pour supprimer la fragmentation de l’information dans les entreprises.
Les avantages sont également stratégiques. Les ERP permettent d’améliorer la réactivité vis-à-vis des
clients en répercutant en temps réel les évolutions des demandes des clients (nouvelles commandes par
exemple) sur l'ensemble du système productif (plan de production et des approvisionnements), des activités et
des fonctions concernées (cf. Bidan M., El Amrani R., Marciniak R., Rowe F. (2003) pour l’impact de l’ERP en
terme de flexibilité) . Les entreprises peuvent en attendre une réduction des coûts d’exploitation, des gains de
productivité (McAffe, (2002); Matolcsy Z. P.; Booth P.; Wieder B. (2005)), un meilleur enregistrement des
commandes (diminution des redondances et procédures simplifiées de saisie de données). L’adoption d’un
ERP permet notamment de déceler des dysfonctionnements et de révéler les slacks organisationnels
(Besson, 1999). La mise en place de PGI accroît la capacité de faire face aux fluctuations de la demande à
court terme et aux problèmes de production liés aux modifications du produit (Cf. Suarez, Cusumano et Fine,
1995) en permettant aux acteurs d’accéder aux informations pertinentes et de communiquer entre eux pour
s’ajuster face aux aléas. Un ERP est souvent présenté comme parfaitement adapté à la logique sectorielle de
supply-chain. Un tel système doit être capable de communiquer le long de la chaîne de valeur aussi bien avec
des systèmes d’entreprises qu’avec des clients utilisant différentes plateformes. Les composantes nécessaires
à la gestion de la supply chain sont des applications de requête, des systèmes de gestion des stocks, des
systèmes de planification et de lancement des transports, des systèmes de gestion des relations clients et de
gestion automatique de la force de vente.
Mais la revue de la littérature souligne la complexité de la mise en œuvre d’un projet ERP et les
risques associés (Bernard, Rivard, Aubert, 2004).) La portée de l’application de ces systèmes, leur complexité
et leur niveau élevé d’intégration représentent des défis importants pour les organisations qui les mettent en
place (Cf. Rowe (1999) pour la description des facteurs de risque : taille du projet, difficulté technique,
périmètre du projet…). Outre le risque de dépassements de budget et d’échéance (enquête CIO citée par
Cosgrove Ware, 2001), il y a celui de l’insatisfaction des utilisateurs et d’une mauvaise qualité du système
résultant de l’implantation. Afin de procéder au paramétrage du progiciel, l’équipe de projet et les utilisateurs
doivent posséder une expertise variée, le manque d’expertises internes est d’ailleurs présenté comme une
source d’échec (Barki et al, 1993, Scott et Vessey, 2002). La rigidité des PGI (Bancroft et al, 1998, Kale 2000),
l’existence d’un écart important entre le processus ciblé et celui inscrit dans le logiciel sont à l’origine de
résultats indésirables en raison des adaptations nécessaires du logiciel. De même, l’ampleur des changements
occasionnés par le processus visé est un facteur de risque (Barki et al, 1993, Bancroft et Al 1998). L’émergence
des ERP est un des principaux facteurs de changement organisationnel dans les entreprises au cours de
ces dernières années (Robey et al, 2002 ; Bingi et al ,1999).
ERP : les raisons du choix
Les travaux de recherche se sont principalement intéressés aux conditions de réussite de la mise en
œuvre d’un projet ERP, et ont un peu délaissé la question préalable des conditions de leur adoption et de leur
diffusion, c’est l’objet de cette étude. L’échantillon est composé de 58 entreprises dont 37 ont déclaré avoir
adopté un ERP. Le taux de réponse a été environ de 20% puisque le questionnaire a été adressé à 300
entreprises de moyenne et grande taille, toutes tirées au hasard.
1. Peu de rationalité « calculatoire » : l’adoption des ERP n'est pas le choix d’un agent isolé qui ferait un
calcul d’optimisation conformément à la théorie financière.
Tableau 1. Usage du calcul économique et choix
Pourcentage de sondés déclarant
Total des firmes (=58) Firmes ayant Firmes n’ayant pas
adopté (=37) adopté (=21)
− avoir évalué un projet
par le calcul d’une VAN
30%
17%
52%
− avoir évalué un projet
par le calcul d’un TRI
55%
51%
61%
Selon la théorie économique traditionnelle l’agent économique rationnel, se détermine en fonction de son seul
intérêt. Disposant d’une information parfaite et évoluant dans un avenir connu avec certitude, il maximise son
profit. Dans une situation dite « d’avenir risqué », le décideur a connaissance de toutes les décisions
envisageables. Il est capable d’évaluer leurs conséquences, il les compare selon le critère de l’utilité espérée et
retient celle qui la maximise. Cette rationalité qualifiée d’utilitaire se fonde sur le principe de l’évaluation
subjective des coûts et bénéfices pondérés par leur distribution de probabilité. Unité de décision autonome, la
conduite de l’agent n’est pas conditionnée par des habitudes sociales consciemment ou inconsciemment
assimilées. Les choix des autres sont sans effet sur son comportement (indépendance des fonctions de
préférence). Dans ce cadre là, l’adoption des ERP est un investissement à réaliser s’il crée de la richesse.
L’opportunité de cet investissement se juge selon son niveau de création de richesse estimée à partir des
différents outils et critères proposés par la théorie financière néoclassique 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
frontière trop large, de l’interaction avec d’autres changements et de l’incertitude sur leur durée de vie.
2. Une rationalité plus « sociale » : ce sont les caractéristiques perçues de l'ERP déterminent le
comportement d'adoption des décideurs
Tableau 2. Attributs perçus des ERP
Toutes les firmes de Firmes ayant adopté Firmes n’ayant pas
l’échantillon (effectif 58) (effectif 37)
adopté (effectif 21)
Attributs perçus
Compatibilité avec la stratégie
sectorielle
Avantages en terme de
gestion d’informations et prise
de décision
Avantages stratégiques
Avantages organisationnels
Complexité et risques
techniques liés aux PGI
Complexité et risques organisationnels liés aux PGI
Moyenne sur 6
Moyenne
Moyenne
4,15
4,72
3,14
4,10
4,44
5,35
4,42
4,89
4,27
3,53
3,64
5,13
5,26
4,89
4,01
4,08
3,89
4,96
Dans la conception socio-rationnelle de la diffusion dominée par le modèle de diffusion de Rogers (1983, op.
cit.) ce sont les caractéristiques de l’innovation, de ceux qui l’adoptent, de leur système social, de
l’environnement etc., qui favorisent sa diffusion. Une innovation ne sera adoptée que lorsque les individus
concernés seront convaincus, compte tenu des informations dont ils disposent, de l’intérêt ou des gains qu’ils
peuvent en tirer. Il s'agit d'un processus séquentiel par étapes, au cours duquel un individu ou toute unité de
décision passe de la première connaissance de l'innovation (1), à la formation d'une attitude vis-à-vis de cette
dernière (2), à la décision de l'adopter ou de la rejeter (3), à la réalisation de la nouvelle idée (4), et enfin à la
confirmation de la décision d'adoption (5).
Selon, Rogers et Shoemaker (1971), l’évaluation de l’innovation par les potentiels adoptants se fait
selon cinq attributs : - l'avantage relatif ou "utilité perçue" qui est le degré de supériorité de l'innovation par
rapport à d'autres innovations existantes; - la compatibilité qui détermine le degré de cohérence avec les
valeurs et l'expérience antérieure des individus; - la complexité ou "facilité d'utilisation" qui représente 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 détermine le degré de visibilité de l'innovation
par les autres.
3. Beaucoup de mimétisme rationnel dans l’adoption d’un ERP
Tableau 3 Influence des positions prises par autrui
Total des
Sondés ayant
Entreprises déclarant avoir été `
sondés
adopté
influencée fortement dans leur choix :
- par le choix d’adopter pris par d’autres sociétés
20,70%
29,70%
- par le choix de sociétés proches géographiquement
8,60%
8,10%
- par le choix fait par les sociétés innovantes
32,80%
40,54%
- par le choix réalisé par des sociétés reconnues comme
50%
43,24%
leaders
- par le choix effectué par des sociétés reconnues comme
56,90%
54,05%
performantes
Sondés n’ayant pas
adopté
4,76%
9,50%
19,05%
61,90%
61,90%
La position prise par les entreprises dépend plus des positions prises par les autres entreprises que de
leur calcul privé. Une innovation se répand en général au sein d’un milieu social par mimétisme, certains
individus s'inspirant de l'attitude de premiers adoptants. Le décideur, en situation d’incertitude, observe le
comportement d'adoption des autres membres de sa communauté. Il bâtit ainsi sur cette observation, son propre
comportement, en s'alignant sur la pratique des autres.
Il y a imitation dès lors que l'adoption de l'innovation par une unité de décision accroît pour d'autres la
probabilité d'en faire autant. Plusieurs modèles de diffusion d'innovation, inspirés des travaux sur la propagation
épidémiologique de maladies, ont été développés sur la base de cette hypothèse de mimétisme. Le concept de
mimétisme, à ce titre, est selon nous pertinent pour décrire certains comportements d’adoption d’ERP. S’il est
aujourd'hui à la base de plusieurs théories majeures en sciences de gestion telles que la théorie de
l'apprentissage organisationnel (Lant et Mezias, 1990), la théorie institutionnelle (Di Maggio et Powell, 1983).
Ces résultats rejoignent ceux de Webb et Pettigrew (1999) qui montrent, dans une perspective pour partie néoinstitutionnelle, comment une stratégie initiée par un leader se diffuse dans le champ inter-organisationnel.
Lorsque les leaders d’opinion envisagent d’adopter une stratégie initiée, ce comportement est par la suite copié
par les autres (Greve 1995). Les entreprises imitent les actions des sociétés qui, ayant réussi sur le marché,
profitent d’une bonne image et d’un prestige élevé (Burns et Wholey, 1993).
1.2 L’entrepôt de données, une intégration « a posteriori »
Avec les « infocentres », il s’agissait de faire une simple copie des bases de données de production, et
de donner ensuite aux utilisateurs les moyens d’accès sur ces bases (outils d’interrogation et assistance).
Aujourd'hui un « entrepôt de données » (DataWarehouse) est une base de données vérifiant les trois propriétés
suivantes:
- Une orientation par « sujet » : Par opposition aux données de production, qui sont «orientées
applications», les données d’un entrepôt sont centrées sur les « notions de base » communes à toute
l’entreprise. Par exemple, une compagnie d’assurances aura des applications pour l’assurance auto,
l’assurance vie, santé, etc. Chacune de ces applications manipule des données de production, dont certaines
sont communes (par exemple les contrats) mais ne peuvent être reconnues pour telles. A l’opposé, ses «sujets
d’intérêt » sont les clients, les polices d’assurance, les commerciaux qu’elle emploie... Ces différents «sujets»
constitueront les entités fondamentales du modèle de données de l’entrepôt.
- Une intégration totale des données : Les développeurs des applications ont nécessairement, au fil
des années, effectué des choix incohérents entre eux. Les différences se manifestent de certaines de façons:
dans le codage des données (par exemple, les dates...), la structure des clés, les conventions de noms...
L’intégration des données signifie que toutes les entités, sans aucune exception, ont un format unique dans
l’entrepôt.
- Une historicité des données : Les données d’un système de production ne reflètent que l’instant
présent. Celles d’un entrepôt sont chronologiques: la dimension «temps» est explicitement représentée dans
toutes les tables et la colonne correspondante est indexée. Les données sont donc conservées pour de
longues durées, l’horizon étant de 5 à 10 ans. Puisque la base est historique, il n’existe plus de notion de mise
à jour. Une fois (correctement) enregistrées, les données ne seront plus modifiées. La normalisation des
tables cesse donc d’être un impératif pour la mise à jour, la redondance n’est pas dangereuse et toute liberté
est laissée au concepteur pour optimiser l’accès aux données.
Entre les bases de l’entrepôt et les bases de données de production (encore souvent sur sites
centraux, et quelque fois même sous forme non relationnelle), il faut organiser la sélection, la transformation et
le transport des informations utiles au nouveau système. Pour décrire de telles conversions une nouvelle
génération d’outils de développement a fait son apparition, celle des extracteurs de données ETL (Extract,
Transform and Load), avec des interfaces permettant de modéliser graphiquement les échanges, et de faire
correspondre des schémas de données non compatibles (en fonction des métadonnées ou descriptions de
champs fournies par les applications). Les processus de décision se raccourcissent dans le temps, et certains
outils ETL sont désormais capables de gérer des flux de données en temps réel , une série de composants
veillent en attendant l'arrivée des requêtes pour les traiter.
Avec les ETL des entrepôts, les données exploitées à des fins décisionnelles analytiques restent en
général mises à jour en différé, du fait de leur volume important. Les plates-formes d'EAI peuvent alors être
considérées comme le prolongement des logiciels d'ETL : avec l’EAI les données à caractère opérationnel
(dont les applications ont besoin pour rendre compte de la situation présente de l'activité) sont injectées en
temps réel dans l'application de destination. Mais au-delà de l’échange des données nécessaires à la
transaction, l’EAI entre aussi dans la couche transactionnelle : il permet à une application de commander
l'exécution d'une tâche à une autre selon le processus métier défini dans le référentiel de règles, ce que ne fait
pas l’ETL d’un entrepôt.
Outils d’ETL
Excellente « pompe » à données
En général en mode batch
Sources BD et fichiers le plus souvent
Traite de forts volumes de données
Outils d’EAI
Très bon routeur de messages
En général au fil de l’eau
Applications sources et cibles
hétérogènes
Traite de faibles volumes de données de
manière fréquente
Transformations simples en général
Transformations parfois complexes avant
l’alimentation
Un SGBD relationnel sait fournir une liste de valeurs issues de plusieurs tables, mais la règle de
normalisation consiste à supprimer toute redondance et toute agrégation de données. Et rapatrier des
informations agrégées (par exemple, le chiffre affaires total réalisé sur une famille de produits) implique en
général de nombreuses « jointures » entre plusieurs tables, ainsi que des opérations d’addition coûteuses en
performance. D’où l’idée d’un modèle de représentation des données particulier, et plus adapté à l’analyse: le
modèle multidimensionnel. Les principaux éditeurs de bases de données relationnelles s’intéressent donc à
l’approche multidimensionnelle des bases de données, qui peuvent aujourd’hui adopter une structure des
tables «en étoile » ou « en flocon », où les indicateurs (ventes, marges, etc.) sont regroupés dans une table.
Les données texte (clients, année, mois, etc..) sont rangées dans des tables différentes, reliées à la première
par des clés.
Les données sont donc organisées selon des axes, en fonction des hiérarchies, et elles peuvent être
agrégées et redondantes. Le modèle multidimensionnel est finalement un hyper-cube qui comporte autant de
dimensions que d’axes d’analyse (souvent neuf). Avec trois dimensions, il pourrait s’apparenter à un «Rubiks
cube », que l’on peut faire pivoter selon ses axes pour visualiser différentes faces. Comme les données sont
préparées, les temps de réponse sont stables et équivalents quels que soient axes. Les requêtes peuvent
exploiter toutes les combinaisons et permutations d’axes. Il est possible de créer des niveaux hiérarchiques et
de prévoir des axes pré-calculés (par exemple la somme de frais par régions, par produits, par mois...). Cette
possibilité ouvre sur une des fonctions les plus intéressantes de l’analyse multidimensionnelle: le « drill-down »
qui consiste à plonger très rapidement dans le détail des informations fournies par un simple clic à l’écran.
L’EXTRACTION DE DONNEES
BASES DE DONNEES EXTERNES
SYSTEMES TRANSACTIONNELS
BASES DE DONNEES UTILISATEURS
Communication
Extraction
Contrôle
Conception
Référentiel
Dictionnaires
SGBD:
BASES DE DONNEES HISTORIQUES
L’ENTREPOT 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, conçus
pour répondre à des besoins de gestion, se trouvent en fait incapables d’assurer des réponses dans des temps
convenables à des questions d’ordre décisionnel. D’où le besoin de créer une nouvelle base spécifique,
multidimensionnelle cette fois, que ce soit sur le serveur pour des applications lourdes (solution prônée avec
Essbase...), ou sur le poste client (Speedware avec Media...). Mais la révolution OLAP réside surtout dans
l’ouverture du marché de l’analyse multidimensionnelle à des outils non spécialisés comme les tableurs.
La base détaillée, qui constitue l’entrepôt de données à proprement parler, reste l’apanage des SGBDR. En
effet les bases multidimensionnelles, souvent limitées en capacité, ne permettent pas d’engranger les centaines
de Giga-octets, que l’on souhaite stocker dans les datawarehouses. Dans un environnement d’informatique
décisionnelle, une base OLAP se positionne alors plutôt comme un serveur intermédiaire décisionnel de
haut niveau alimenté par le SGBDR, qui conserve lui son rôle d’entrepôt de données élémentaires, historisées,
etc......
1.3 L’EAI, une plate-forme reliant les applications hétérogènes
L'objectif de l'intégration d'applications est de mettre en place une infrastructure technique autorisant
une coopération automatisée, de qualité, sécurisée et performante entre différentes 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, développer des interfaces spécifiques leur permettant de s'échanger des données
et d'utiliser conjointement leurs ressources et, enfin, définir des protocoles d'interaction. Si l'entreprise a besoin
de faire travailler ensemble N applications, elle devra, en appliquant cette logique, développer autant
d'interfaces spécifiques 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 intégration préalable, globale et systématique des briques du système
d'information. Il est donc nécessaire que l'entreprise mette en place une démarche et des solutions techniques
homogènes permettant « d'industrialiser » cette coopération entre applications.
Pour cela, il est possible d'agir de deux façons, l'une ex-post, l'autre ex-ante :
(1) Développer ex-post un système centralisé autorisant et organisant la communication entre
toutes les applications internes : c'est l'objet de l'EAI : Enterprise Application Integration
(2) Rebâtir ex-ante certaines applications externes dans une logique de composants
interopérables basés sur des standards du marché : c'est l'enjeu des architectures Web services basés sur
les technologies de l'internet.
Avant l'arrivée des outils d'EAI, les entreprises devaient développer elles-mêmes deux connecteurs à
chaque fois qu'elles souhaitaient relier deux applications entre elles. Aucune politique de standardisation des
connecteurs n'était définie, pas plus qu'un protocole de transport standard. Si bien que les connexions
interapplicatives représentent un véritable plat de spaghettis qui coûte 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 système d'information, le rendant plus flexible et
plus réactif : un quartier ou une application peuvent être facilement débranchés sans bloquer le fonctionnement
du reste du système.
Application 1 Application 2 Application 3
EAI
Application 4 Application 5 Application 6
Principe de fonctionnement de l’EAI : une multiprise applicative.
Une plate-forme EAI fonctionne sur le modèle d'une multiprise. Chaque application possède un
connecteur standard (la prise) qui est relié au " bus EAI " (la multiprise).
- Le connecteur est un exécutable ou une classe Java, installé sur la machine qui héberge
l'application. Il traduit les données 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
reliés aux applications depuis leur base de données, des fichiers plats, etc. Les connecteurs applicatifs
interfacent directement leurs API (Application Programing Interface). Encore propriétaire au début des années
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 particulière du MOM. Ainsi, si une application destinataire n'est pas accessible,
le MOM stocke les messages entrants et sortants jusqu'à ce qu'ils soient récupérés par leurs destinataires.
C'est ce mécanisme de communication asynchrone qui permet de découpler 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 système d'information non pas en mode
point à point, mais via un système global, cohérent et systématique. Mais par quel miracle ce « bus » si simple
arrive-t-il à remplacer le « plat de spaghetti » d’autrefois ? S’il y parvient, c’est parce qu’il n’est pas simple du
tout, il ne s’agit pas seulement d’un « bus », support passif de transmission, mais d’un routeur complexe :
- routage des messages : le « bus » interprète l’étiquette du message pour identifier l’adresse vers
laquelle il doit l’orienter ;
- transcodage des données : si deux applications recourent à des codages différents, le « bus » assure
la traduction entre les codes ;
- gestion des flux : du temps réel transactionnel jusqu’au traitement « batch », le « bus » gère les
délais de mise à jour selon les besoins des diverses applications ; il comporte des files d’attente (« buffers ») ; il
traite la concurrence (lorsque deux utilisateurs veulent modifier en même temps une même donnée) et la
persistance (lorsqu’il est nécessaire de conserver en mémoire la valeur d’une donnée qui vient d’être modifiée).
Les fonctions ainsi offertes par le bus soulagent d’autant les applications : il est plus simple pour une
application d’envoyer les messages au « bus » qui en assurera le routage que d’inclure elle-même un sousprogramme de communication, il en résulte une économie d’échelle par concentration du code naguère
dispersé dans les applications. Le « bus » EAI est donc un « middleware » très riche, sa mise en oeuvre
suppose que les fonctions ci-dessus soient définies et paramétrées, et sa présentation par les commerciaux est
d’une simplicité trompeuse. La multiplicité des codages dans les applications impose un traitement rigoureux du
transcodage voire une vérification 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 différences de volumes de données à échanger impose
également une harmonisation des canaux pour éviter l’encombrement des mémoires ou la perte des données
en sous capacité de traitement. Les inéluctables rejets de l’interface entre deux applications doivent être
préalablement traités. L’accès simultané aux dossiers traités par le SI doit être conçu de façon à éviter que les
données d’un utilisateur n’écrasent ou ne modifient celles d’un second utilisateur.
Paramétrage d’un logiciel EAI
Au même titre qu’un PGI est paramétré pour s’adapter au mieux à un besoin métier, un EAI doit être
paramétré pour mettre en œuvre les interfaces dont le SI a besoin. Chacune des couches présentées
précédemment fait l’objet d’un paramétrage. Le paramétrage dans une solution d’EAI se matérialise au travers
d'une ou plusieurs interfaces graphiques qui permettent de définir les connecteurs à utiliser, les transformations,
les routages et les processus métier.
Par exemple, pour un projet d’intégration particulier, le paramétrage consiste à réaliser les actions
suivantes :
- choix des connecteurs adéquats, par exemple un connecteur JDBC pour la source et un connecteur
SAP pour la cible,
- paramétrage 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 l’exemple les champs de la table), de la cible (dans l’exemple
les paramètres à fournir à la BAPI) et du format pivot,
- paramétrage des transformations nécessaires entre la source et le format pivot d’une part et entre le
format pivot et la cible d’autre part en utilisant une ou plusieurs fonctions prédéfinies fournies par la plateforme
d’intégration,
- choix du mode de routage entre la source et la cible, par exemple un Publish and Subscribe,
- paramétrage de la publication de l’application source et de la souscription de l’application cible dans le
Message Broker (dans la couche Routage).
Certaines offres d’EAI ne fournissent pas d’IHM pour réaliser tous les paramétrages évoqués
précédemment. Par exemple, Oracle Interconnect permet de paramétrer graphiquement les transformations et
le routage. Par contre, les connecteurs sont à paramétrer en mode ligne de commande et via des fichiers de
paramétrage à éditer manuellement. L'outil de paramétrage manipule généralement le contenu d'un repository
utilisé par la solution d'EAI pour stocker l’ensemble des informations nécessaires au fonctionnement de
l’infrastructure. Ce repository (qui en pratique est parfois divisé en plusieurs repositories) prend des formes très
diverses allant d'une simple collection de fichiers de configuration à une base de données relationnelle.
Si l’outil choisi ne peut répondre à un besoin précis, il est alors envisageable de réaliser un
développement spécifique au sein de la plate-forme d’EAI. Ces développements se font alors via un kit de
développement (SDK) que l’outil d’EAI fournit. Il convient cependant d’aborder cette possibilité en désespoir de
cause : au même titre qu’il est dangereux de faire du spécifique sur un PGI, notamment à cause des coûts de
maintenance, le développement spécifique dans l’outil d’EAI éloigne d’un des principes de base de l’approche
EAI qui est d’intégrer rapidement et simplement les applications.
EAI stratégique ou EAI tactique ?
Sur le papier, le schéma est séduisant. Avec leurs capacités de Workflow et la possibilité de créer des
super processus d'entreprises au-dessus des systèmes en place, les meilleurs EAI apparaissent comme une
solution idéale : Diffuser la bonne donnée, au bon moment et aux bons acteurs, en constitue la nouvelle finalité.
Mais les entreprises ont été déçues par les solutions d'EAI stratégique, présentées bien souvent comme des
produits proches de l'espéranto informatique, à même de résoudre tous les problèmes liés 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 français de solution d'EAI
tactique. Il devance même, dans l'ordre, IBM, WebMethods, Kabira et SeeBeyond… Ces initiatives basées sur
l’Open 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
développer 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 plutôt des briques techniques que de platesformes prêtes à l'emploi, et il n'existe pas de connecteurs applicatifs (SAP, Siebel, etc.) et très peu de
connecteurs techniques (fichier, SQL, etc.). Les outils open source constituent donc, avant tout, un socle
technique intéressant pour répondre à des problématiques d'intégration spécifiques. Le coût d'une solution
d'EAI est lié à celui des connecteurs et du courtier de messages, qui sont vendus séparément. Les éditeurs
commercialisent en effet la plate-forme avec un nombre minime de connecteurs techniques et facturent très
cher les connecteurs applicatifs, qui apportent le retour sur investissement le plus rapide à l'entreprise.
Le coût moyen d'un connecteur technique se situe autour de 30.000 e, quand un connecteur applicatif
peut atteindre plus de 150.000 e. S’Il 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 démarche par étapes de révolution permanente et
d'obtenir une adhésion du ou des métiers concernés afin d'assurer le succès du projet.
Editeur
Axway
Sunopsis
Nom de la
solution
Principaux
modules
fonctionnels
Principales
caractéristiques
Références
Prix moyen
d'un projet
aXway
Integration
Suite
aXway File Broker,
aXway Integration
Broker, aXway
Sentinel, Buniness
Integrator,
Enterprise
Integrator,
Information
Integrator, aXway
SwiftNet.
Connecteurs : SAP,
Oracle, Siebel,
WebSphere,
WebLogic, Kabira
Objectswitch…
Réseaux à valeur
ajoutée Bolero.net,
Swift, EDI…
Plus de 5 000
clients, dont DexiaCrediop, British
Telecom,
Jobpartners, SFD,
Banksys, Mutualité
fonction publique
Services (MFP
Services)…
A partir de
80.000 e
(licence +
service). Projet
intégration
sans
transformation
de données :
50.000 e
Sunopsis V3
Sunopsis V3,
Sunopsis MQ
(MOM), Sunopsis
XML Driver (JDBC
Edition).
Connecteurs:
Principales bases de
données, PGI et
GRC. Connectivité :
JDBC, ODBC, JCA
Damart, Europe 1, Prix moyen
Cofidis,
Roche, (licence +
Lafuma, Cegetel a service) : de
fait
son 80.000 à
apparition, …
120.000 e
Des exemples d’EAI
Casino connecte ses applications spécifiques par des progiciels EAI du marché, mais le pilotage des
processus métier interviendra dans un second temps. Casino s'est engagé dans une refonte de son système
d'information selon une approche « best of breed » : choisir les composants progiciels les plus adaptés au lieu
d'une offre intégrée ou d'un développement spécifique. A l'issue de cette refonte, une grande partie des
applications sera utilisée via des clients légers et intégrés, en s'appuyant sur l'EAI de Sybase.
Casino a
d'ores et déjà utilisé l'EAI pour intégrer 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'intégration
des progiciels de coeur de métier. 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 réel. Nous avons donc conçu une inter face au fil de l'eau depuis notre
référentiel client DB2. Le message MQ de mise à jour est récupéré par eBiz Integrator. L'adaptateur SAP livre
ensuite l'information au format Idoc. »
Au Crédit Lyonnais, la Direction des marchés actions de la banque a décidé de conserver l'ancien
système informatique et d'y adjoindre une plate-forme d'EAI pour le traitement des flux. Crossworlds, racheté
entre-temps par IBM, est choisi.. Cette démarche donne naissance à une logique métier : il s'agit de replacer
les clients et le front-office au cœur 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-même son ordre. Ensuite, la plate-forme EAI distribue cet
ordre dans le système d'information : économies et vision globale des processus métier.
Le réseau Assurance de Groupama distribuant les services bancaires, le besoin d'intégration avec le
système d'information de l'assureur était évident. Les équipes de Groupama ont donné une orientation métier à
leur projet d'intégration : définir avec précision les différents processus métier liés à la banque, et les modes
opératoires qui y sont rattachés, grâce au référentiel de Mega. Afin d'éviter toute réplication de données inutile,
Groupama banque souhaitait s'appuyer sur les informations générées depuis le front-office (Siebel) de l'activité
Assurance. De même, toutes les informations nouvellement saisies par le service bancaire ou assurance se
devaient d'être répercutées automatiquement dans le back-office, après vérification et transformation. L'EAI de
Vitria se voit donc confier cette tâche et sert de véritable 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 opérationnel dans les délais. Elle
a également renforcé la maîtrise des flux de données et fait diminuer de manière considérable les erreurs et les
tâches d'administration.
Les 260 "Espaces SFR" jouent un rôle clé dans la politique de satisfaction des abonnés. L'opérateur
souhaite en faire de véritables espaces de services à proximité de ses clients. Afin de remplir ce rôle, la Société
financière de distribution (SFD), filiale de Cegetel qui gère l'ensemble des "Espaces SFR", a dû remettre à
niveau son système d'information pour gérer la logistique des boutiques. Cette chaîne était trop fortement
sollicitée et devait en plus absorber les rachats successifs de PhoneShop et d'Aloha : Le progiciel "SAP Retail",
le système de médiation et le système d'encaissement avaient du mal à supporter la montée en charge
provoquée par la croissance externe. Le volume et la diversité des flux à gérer, le manque de fiabilité dans le
processus d'échanges avec les boutiques, l'absence d'outils de supervision ainsi que la trop grande
hétérogénéité des protocoles de communication ont poussé la SFD à mettre en place une plate-forme
d'échange EAI spécialisée dans la logistique. La Société financière de distribution a retenu la solution Axway
Integrator Suite de l'éditeur français Axway. Cette plate-forme EAI centralise les échanges, contrôle, transforme
et route les données. La fiabilité des données a permis à la filiale de Cegetel de gérer l'approvisionnement de
ses boutiques en temps réel, réduisant d'autant les ruptures de stock et augmentant le niveau de satisfaction de
ses clients.
2. L'intégration entre organisations : EDI, XML, Web Services
2.1 Les métadonnées EDI
Ce qui différencie l’EDI de la simple communication est le fait que les données soient présentées selon
une norme reconnue au niveau sectoriel, national ou international. Cette norme va définir les termes
commerciaux à utiliser, la façon dont le document est organisé en segments, l’ordre de ces segments,
quels sont les contrôles à opérer pour vérifier, à la réception, que le message est correctement reçu, etc.
La norme définit un langage commun avec une syntaxe et une sémantique trés précises.
Les normes sectorielles.
De très nombreuses normes ont été définies dans différents cadres; citons par exemple:
- au niveau national (France): Galia (constructeurs automobiles), Gencod (distribution), Cefic (chimie),
Innovert (transport);
- au niveau européen: GTF (transport terrestre), Odette (construction automobile), Edifice (construction
électronique), Ediconstruct (travaux publics);
- au niveau International: Iata (transport aérien).
Mais la multiplicité de ces normes se révèle très vite génante pour faire face aux besoins du commerce
et des échanges intersectoriels (par exemple, une entreprise fabriquant des composants électroniques
pour l’automobile devrait travailler avec les normes Odette et Edifice, uniquement en Europe).
C’est pour cette raison qu’est développé, sous la tutelle des Nations unies, un langage commun:
EDIFACT (échange de données informatisées pour l’administration, le commerce et les transports). La
norme EDIFACT, mondiale et multisectorielle, devrait rapidement remplacer les diverses normes
actuellement en service.
Les normes internationales.
Les différentes instances de normalisation, EDIFRANCE à l’Afnor (Paris), EDIFACT-Board au Comité
Européen de Normalisation (Bruxelles) et la CEE/ONU avec l’ISO (Genève) ont vocation à favoriser le
développement de la normalisation des données et des messages pouvant supporter les échanges
commerciaux entre des organisations nationales et internationales distinctes. Des groupes de travail
sectoriels ou intersectoriels, sous l’égide d’EDIFRANCE et de l’EDIFACT-BOARD développent des
messages normalisés dits UNS, United Nations Standard Message. L’ensemble des administrations et des
entreprises privées et publiques peut participer aux travaux des instances de normalisation. Une vingtaine
de groupes professionnels de structures juridiques très différentes oeuvrent aussi pour le développement
de l’EDI. On peut citer, comme exemple, l’association EDISANTE, créée à l’initiative des acteurs du
système de santé et les associations EDITRANSPORT et EDICONSTRUCT créées à l’initiative
d’entreprises du transport, de la construction, des travaux publics, de leurs partenaires et de leur ministère
de tutelle.
On a représenté ici une facture papier et son équivalent dématérialisé sous forme de message
EDIFACT « INVOIC ». Les segments de services servent à délimiter un « interchange » tel que celui
représenté ici: UNZ délimite un message, UNS délimite une section (une partie cohérente du message, ici
l’entête ou le détail facture), etc....
FACTURE
Expéditeur:
FALLERY
60, rue des premières cabanes
75016 PARIS
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
Désignation
CD ROM réf. 123
Référence: FD 10
date: 14 JUIN 2012
Conditions de paiement
90 JOURS
Quantité
Unit
5
Prix
Montant
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 premières 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:Chèque bancaire
à l’ordre 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 néanmoins confiné aujourd’hui au domaine des grandes sociétés.
Mais l’intégration de technologies usuelles et peu coûteuses commencent à faire changer les choses.
Beaucoup de PME commencent donc à mettre en avant leurs propres outils de création et de gestion de
formulaires électroniques. Forms chez Microsoft, Informs chez Novell, Formflow etc.... sont des solutions
proposées par les grands éditeurs pour le commerce électronique à ceux qui n’ont pas toujours les moyens
de s’offrir une véritable solution EDI. Avec l’EFI, l’Echange de Formulaires Electroniques, un bureau
distant ou un fournisseur peuvent recevoir et ouvrir un formulaire électronique envoyé par le siège social
ou par un client, mettre automatiquement à jour leur base de données à partir des informations reçues,
router le formulaire en interne pour traitement, remplir le formulaire-réponse approprié (état de stock, devis,
facture...) et le renvoyer au siège par transfert de fichier binaire.
Les utilisateurs d'Edifact, organisés en 10 secteurs d'utilisation et aussi dans l'EWG (Edifact Working
Group) coordonnent le développement d'Edifact depuis l'origine et ils veulent plutôt traduire « telle quelle »
la sémantique Edifact en XML (EDI-Light) limitant ainsi le coût de la migration, alors qu'ebXML voudrait
privilégier l'amélioration qualitative et radicale.
2.2 Les métadonnées XML : vers le web sémantique
Normes et Standards de métadonnées
On peut définir les métadonnées comme des « données relatives à des données ». Ainsi, les contenus
de livres sont des données, mais des répertoires de bibliothèque constituent des métadonnées parce qu’ils
contiennent des informations sur les livres et leurs contenus. Les métadonnées 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 métadonnées peuvent être incluses dans les ressources elles-mêmes,
ou enregistrées dans un fichier séparé selon le type du contenu (par exemple il n’est pas aisé d’inclure des
métadonnées dans une image). Le web est aujourd'hui composé de liens simples et universels mais
sémantiquement peu structurants, les métadonnées sont peu ou mal utilisées. Les moteurs de recherche
deviennent donc ultra sophistiqués mais restent imparfaits. La nécessité de liens riches, de métadonnées
structurées, sûres et signifiantes se fait de plus en plus sentir. Le « web sémantique » veut être une réponse à
ce besoin. Il permettrait de « revenir » à une structure sémantiquement riche, de type base de données,
orientée ressources, tout en conservant les métadonnées dans les documents. L’intention du « Web
sémantique » est de s’appuyer, plutôt que sur la structure textuelle du document, sur des descriptions
structurées de l’information qu'il contient, pour construire des documents organisés et compréhensibles par des
logiciels (des moteurs de recherche ou des agents qui parcourent le Web de façon automatique). Aujourd’hui :
le Web est exploité par des personnes qui recherchent des informations via un moteur de recherche et qui
exploitent elles-mêmes le résultat. Demain : le Web sera exploité en priorité par des machines qui traiteront
elles-mêmes les questions posées par des personnes, et qui délivreront les résultats à ces personnes.
http://www.semanticweb.org/
La capacité des métadonnées à faciliter
l’accès aux ressources en ligne dépend bien
évidemment de l’existence d’un standard, doté
de deux propriétés : pérennité et aussi
possibilité d’évolution. Une norme est un
ensemble de règles de conformité, édictées par
un organisme de normalisation au niveau
national ou international (ISO, Cefact-ONU..).
Un
standard
est
un
ensemble
de
recommandations émanant d'un groupe
représentatif d'utilisateurs réunis autour d'un
forum, comme l'IETF (Internet Engineering Task
Force), le W3C (World Wide Web Consortium),
le Dublin Core.
a) Dublin Core
Une première idée est d’insérer des meta-tags normalisés dans une page html, et l’exemple le plus
connu de métadonnées est le « Dublin Core Metadata Initiative »», standard de facto développé par un forum
international et interdisciplinaire, et constitué de quinze éléments de description des ressources en ligne. Ces
15 éléments sont demeurés inchangés depuis 1996. Leur utilisation n'est pas sujette à un ordre établi, et
chaque élément est optionnel, tout en pouvant être répété : Titre, Auteur, Sujet, Description, Éditeur,
Collaborateur, Date, Relation, Type de ressource, Format, Identificateur, Source, Langue, Portée, Droits. Afin
d’accroître la spécificité des métadonnées, le Dublin Core peut être qualifié avec deux types de qualificatifs :
Les qualificatifs d'élément précisent la signification sémantique de certains éléments et les qualificatifs de
valeur qui précisent la valeur attribuée à un élément au sein d'un registre de métadonnées particulier.
Les 15 éléments descriptifs du Dublin Core peuvent être modélisés (en RDF par exemple, voir plus
loin) pour s’adapter à chaque application. L'importance croissante du Dublin Core dans la description des
ressources électroniques peut être attribuée à sa simplicité, son extensibilité et sa flexibilité. En effet
l’indexation d’une ressource peut bien sûr être faite par son propriétaire (les balises META ne sont pas limitées,
et on peut donc utiliser ces balises étendues pour faire une « ontologie d’annotation », comme par exemple
avec SHOE, Simple html ontology extensions), mais dans la plupart de cas, l’indexeur n’est pas le propriétaire
de ressources, il n’a pas le droit de mettre les métadonnées dans le contenu de ressources, et les éléments de
métadonnées doivent donc être conservés dans un registre séparé des ressources (c’est l’intérêt de RDF,
puisque les métadonnées peuvent alors être stockées ailleurs et réutilisées dans plusieurs applications). Dans
un environnement vraiment collaboratif on doit même pouvoir lire les propriétés d’une ressource sans rendre
compte de son contenu, on doit par exemple pouvoir indexer les ressources par propriétés (WebDAV est alors
un protocole, extension du protocole d’échange HTTP, qui permet d’attacher des propriétés 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 =
"[email protected]">
<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, l’avenir des échanges de documents
La deuxième idée est de structurer logiquement le contenu des documents de manière à pouvoir
séparer le fond et la forme. XML peut être considéré comme un métalangage permettant de décrire d’autres
langages de balisage spécialisés pour des activités particulières : XHTML dans la conception des pages
Internet, WML pour le Wap des téléphones mobiles, MathML pour les mathématiques, mais aussi des
langages pour l’apprentissage, la chimie, la finance, etc..
<?xml version="1.0" standalone="yes"?>
<!DOCTYPE parent [
<!ELEMENT parent (garcon,fille)>
<!ELEMENT garcon (#PCDATA)>
<!ELEMENT fille (#PCDATA)>
]>
<parent>
<garcon>Loic</garcon>
<fille>Marine</fille>
</parent>
Avec une DTD interne
<?xml version="1.0 "standalone="no"?>
<!DOCTYPE parent SYSTEM "parent.dtd">
<parent>
<garcon>Loic</garcon>
<fille>Marine</fille>
</parent>
en stockant dans le même répertoire une DTD
externe "parent.dtd":
<!ELEMENT parent (garcon,fille)>
<!ELEMENT garcon (#PCDATA)>
<!ELEMENT fille (#PCDATA)>
Avec une DTD externe
XML apparaît comme le moyen pour décrire à la fois métadonnées et structure des documents : Une DTD
(Définition de Type de Document) est la définition d’un langage de balisage particulier, elle décrit la
structure logique d’une classe de documents, c’est à dire l'ensemble des règles et des propriétés que doivent
suivre les documents XML de cette classe. La DTD peut être interne ou externe. Les exemples sont de
[email protected]
Mais il est surtout possible de faire référence à 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 données,
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 d’avoir certaines parties associées à une DTD, et d’autres à une autre DTD . La
définition d'un « espace de nom » permet d'associer toutes les balises d'un langage à un groupe afin d'être
capable de mêler différents langage à balise (pouvoir mettre du HTML, MathML, et CML dans un même
document). Il est également possible d’analyser des documents sans leur imposer une structure, des
documents XML peuvent alors être bien formés (leur DTD n’est pas connue), mais non valides (respectant
strictement une DTD donnée). Certains analyseurs (parser ou parseur) peuvent lire un document XML, mais
sans pouvoir vérifier leur DTD, c’est le cas d’IE5.
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 nécessaire de pouvoir normaliser la structure des ressources ( c’est le rôle des DTD: Document Type
Definition). XML structure ainsi les données, mais il ne définit pas de « sens », de standard pour exprimer les
métadonnées.
C’est là le rôle de RDF (Resource Description Framework), qualifié de métalangage de métadonnées. La
couche métadonnées contient les outils nécessaires à la description de ces ressources : un modèle
d'assertion (définition des règles de base : c’est le rôle des RDF Ressource Description Framework qui
permettent les annotations sémantiques décrivant le contenu des documents), une normalisation de ces
modèles de descriptions des métadonnées (contraintes formelles sur les métadonnées : c’est le rôle des
Schémas RDFs qui permettent la définition de classes, des types de propriétés, la déclaration d’héritage…), et
enfin les ontologies (définition des concepts et des relations…)
Langage de
requêtes
Agents
intelligents
Langage
de preuve
Langage de
requêtes
Langage
de preuve
Agents
intelligent
s
Ontologies
méta
Modèle
d’assertions
Descriptions
formelles méta
Nommage
Ressource
Descriptions
formelles
Ontologies :
« Créateur » lié à
« Professeur »
Créateur « X »
RDFs :
« une seule date de
création »
URL, URN,
URC
Ressource
XMLs, DTD
RDF :
Une syntaxe : XML
La recherche de données est enfin assurée par des agents intelligents. Le moteur analyse les requêtes en
consultant les ontologies (la dernière brique du web sémantique est constituée par le langage de preuve, qui
permet d'authentifier un document).
Dans RDF un ensemble de propriétés décrivant une ressource est appelé une «Description». L’association
d ’une ressource, d’un nom de propriété et de la valeur de cette propriété pour la ressource est une « assertion
» pouvant être représentée par un triplet (propriété, ressource, valeur). Ainsi la phrase «Fallery est l'auteur de
la ressource http://www.isim.fr/cours» peut être modélisée par le triplet : {auteur, http://www.isim.fr/cours,
Fallery}. Une description RDF, c’est-à-dire un ensemble d’assertions, peut alors être exprimée 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 décrit dans l'élément RDF :
<Description about= ...> ...
</Description>
par les propriétés :
Title, Creator, Date, Subject, définies dans le domaine xmlns:DC = http://purl.org/DC#
Divers standards cohabitent pour exprimer les métadonnées. La lutte est engagé entre les « géants »
(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
bientôt exporter des documents sous ce format.
Mais Topic Maps, est une norme ISO qui fait l’objet de nombreux développements sur le marché de la
gestion
des
contenus
de
l'entreprise
(ECM,
Enterprise
Content
Management)
http://www.universimmedia.com/index.htm. A l’interieur d’un « theme », Topic Maps uilise les concepts
de “topic” (topic type, name) et d’“occurrence” (occurrence role) pour organiser les informations sur sujet et
créer des index. Pour décrire les relations entre topics, on utilise « topic association » (association type,
association role), et on peut associer des propriétes aux topics en utilisant « facet », ou donner des limites de
validité (scope)
d) Le paysage de la standardisation XML
XML est réputé faciliter les échanges d'informations en structurant les données de manière standardisée.
Mais le problème vient en l'occurrence de la souplesse fournie par XML qui permet à chacun de définir un
standard... sur mesure ! Cette possibilité a déjà été largement utilisée, notamment par les différentes branches
d'activités et types d'applications qui ont défini leur propres standards, et l'on estime leur nombre à plus de
500 ! On assiste maintenant à la naissance d'initiatives destinées à recenser ces standards, et à définir des
moyens de les fédérer. Le monde des standards pour l'interopérabilité ne se simplifie pas, mais évolue très
vite.
Pour le domaine
« E-business »,
d’acteurs (http://www.vendr-edi.net/) :
on
repère
aujourd’hui
au
moins
quatre
groupes
- d'un côté, 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 réflexions 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é privilégient ce "bond en avant" direct vers XML que représenterait ebXML.
Mais si cette standardisation "officielle" ne débouche pas vite, la stabilité attendue par les entreprises pour
passer à XML viendrait alors des standards " de facto "…
- car de l’autre côté, la WS-I (Web Services Interoperability Organisation) qui regroupe offreurs et grands
utilisateurs industriels de produits basés sur XML (avec Microsoft, IBM, SAP, Oracle, Dassault Systèmes…) se
veut un outil de la customer business process integration avec notamment les standards UDDI pour les
registres et SOAP pour les procédures à distance. Tous proposent déjà des spécifications 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 nécessite une boîte à outils cohérente et simple à utiliser, où chaque outil complète les
autres, et il y a encore du travail à faire au W3C!
Pour le domaine « E-Formation », dans un marché extrêmement concurrentiel, sous l’impulsion pressante
de l’aéronautique (AICC Aviation Industry Committee) et du département de la défense aux USA (ADL
Advanced Distributed Learning Initiative), chacune des 500 plates-formes de formation en ligne (LMS) se vante
aujourd’hui d’une conformité à des acronymes parfois obscurs (DC, LOM, AICC-SCORM..). Dans cette
effervescence, une “spécification“ de l’industrie a vocation à devenir un “standard“ dans un consortium,
reconnu ensuite comme une “norme“ internationale, et enfin déclinée en différents “profils d’application“ et en
“bonnes pratiques“.
Le LOM (Learning Objects Model), basé sur le travail original d’ARIADNE en Europe (1995) et adopté
ensuite à l’ISO en 2002 sur proposition de l’IEEE (Institute of Electrical and Electronics Engineers), se présente
comme un ensemble descriptif de meta-données composés de quatre-vingt balises XML
Le LOM reprend ainsi toutes les métadonnées du Dublin Core en les détaillant (la délégation
française a réussi à faire rejeter le projet américain d’identifiant unique pour les personnes), et en ajoutant une
partie Education avec les caractéristiques pédagogiques de l'Objet. Cette norme générale LOM donne
ensuite lieu à des « profils d’application » spécifiques : Celebrate en Europe, Normantic au Canada (Chouinard
2002). Avec ce concept d’Objet décrit par 9 catégories et leurs 71 champs (Typical Learning Time, Level of
interactivity..) on considère bien ici que la connaissance est prédéfinie puis transférée, sans dépendre de
l’interaction : un Objet LOM ne peut être décrit que par UN jeu de catégories. La catégorie Learning Resource
Type est souvent critiquée, car elle mélange des types et des fonctions (“exercise, simulation, questionnaire,
diagram, figure, graph, index, slide, table, narrative text, exam, experiment, problem statement, self
assessment, lecture”), la catégorie Semantic Density n’est qu’une mesure subjective donnée par un auteur, la
catégorie Title ne permet qu’une seule valeur car la langue est considérée comme un élément interchangeable,
les critiques sont nombreuses.. Mais la reprise de la discussion au SC36 sur les concepts d’Objet et/ou de
Ressource pourrait déboucher sur une norme dite LRM, acceptant des descriptions multiples, ce que Downes
(2003) appelle un véritable « Profil », en utilisant les schémas RDFs, qui offrent la possibilité d’avoir différents
« domaines de noms » (namespace : xmlns) où peuvent se définir différents jeux de propriétés (ici quatre
balises DC) qui décrivent une même 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, destinés à permettre d'agréger les services applicatifs de plusieurs
entreprises entre elles.
Les services Web poursuivent un vieux rêve de l'informatique: celui d'un monde où les ressources
informatiques pourraient interopérer à travers un réseau, indépendamment 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 démarche d'intégration applicative ex-post interne des
entreprises alors que les Web Services sont, à l'origine, destinés à permettre ex-ante d'agréger les services
applicatifs de plusieurs entreprises entre elles. Les Web services, apparus avec la mouvance Internet et le
développement rapide des applications client-serveur accessibles via un navigateur Web, se veulent un
aboutissement de la logique des applications distribuées. Ce concept peut être analysé comme une réponse au
désir des entreprises et des administrations de relier différents composants logiciels internes et externes.
Deux protocoles fondamentaux sont utilisés : SOAP (Simple Object Access Protocol) qui définit la
structure des messages XML utilisés par les différentes applications pour communiquer ensemble ; WSDL
(Web Services Description Language) qui est un langage de contrat décrivant la façon pour une application
d'invoquer une autre application : standardisation des schémas XML utilisés pour établir une connexion entre
émetteurs et récepteurs. Enfin, dans l'idée d'applications distribuées sur le réseau Internet et utilisables comme
des services, il est nécessaire 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, intégrant toutes sortes d'entrées (nom, carte d'identité des sociétés, description
des produits et des services, etc.), son objectif à terme est d'automatiser les communications entre prestataires,
clients, etc..
Un service Web est décrit dans un document WSDL, précisant les méthodes pouvant être invoquées, leur
signature, et les points d'accès du service (URL, port, etc.). Ces méthodes sont accessibles via SOAP : la
requête et la réponse sont des messages XML transportés 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
fonctionnalités d'une application et les rendre accessibles via des protocoles standards. Le service Web sert
alors d'interface d'accès à 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 décentralisé 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 définit aussi un RPC (Remote Procedure Call) qui résout
certains problèmes soulevés par les technologies telles que CORBA ou DCOM souvent difficiles à mettre en
œuvre. SOAP a pour vocation d'être une spécification simple à mettre en œuvre, et de fonctionner sur toutes
les plates-formes et pour tous les langages de programmation. En définissant trop de services, on complique
l'utilisation de SOAP et on risque de perdre la portabilité (La sécurité 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 décrire de façon précise les services Web, en incluant des détails
tels que les protocoles, les serveurs, les ports utilisés, les opérations pouvant être effectuées, les formats des
messages d'entrée et de sortie, et les exceptions pouvant être renvoyées. WSDL est le point d'entrée du
service : on y trouve la localisation du service, et les opérations qu'il est possible d'invoquer en utilisant SOAP.
Mais ce socle initial de la technologie des Web Services nécessite souvent de se mettre aussi d'accord
sur d'autres dispositifs communs : L'intégrité des transactions ? La sécurité ? Comment gérer l'exécution d'un
processus applicatif impliquant plusieurs Web Services ? Comment publier un Web Services au sein d'une
interface utilisateur ? Comment définir un processus métier en environnement B to B ? Comment structurer les
documents commerciaux échangés et décrire les données métier qu'ils contiennent ? Dans la constitution des
briques des Web Services, la stratégie de Microsoft et IBM au consortium WS-I, consiste à répondre aux
enjeux en partant des couches basses (SOAP). L'autre tendance, représentée par le consortium Oasis et le
projet ebXML tente de donner une coloration métier aux protocoles de base. Le but est de faire communiquer
et collaborer les applications :
1. Interfacer : extraire et injecter des données dans une application. Pour cela on utilise les services
Web (et en particulier WSDL), qui ont l'avantage de pouvoir être accédés à partir de n'importe quel langage de
programmation et qui fonctionne sur n'importe quelle plate-forme. WSDL permet de donner une description
normalisée des fonctionnalités offertes par les applications.
2. Transformer : convertir les données. C'est le rôle 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 générer une facture, et que ces deux applications n'ont pas la même
façon de modéliser une commande, une opération de transformation est nécessaire :
3. Router : transporter les données vers le destinataire. Pour cela on utilise SOAP, qui peut être utilisé
pour une communication synchrone ou asynchrone.
4. Gérer : suivre l'état du processus. Formellement, un processus métier peut être défini comme un
enchaînement d'activités incluant une interaction entre participants, dans le but de réaliser un objectif métier.
Dans un processus métier, on tient compte des différents participants d'une opération, de leur rôle, de l'objectif
de cette opération et des moyens mis en œuvre (messages, documents). Un processus métier décrit des
activités et leur séquencement. Le problème de la représentation des processus métiers n'est pas nouveau
mais BPML est un standard émergeant : Un processus e-business est composé de deux parties : Une interface
publique : définition du dialogue (RosettaNet, ebXML, Biztalk.org ou autre), précisant l'interaction entre les
participants du processus e-business. Elle est commune à tous les participants. Deux interfaces privées (une
par partenaire) : définition des processus métiers implémentés par chaque partenaire.