Vous êtes sur la page 1sur 115

Royaume du Maroc Université Mohammed V - Souissi Ecole Nationale Supérieure d’Informatique et d’Analyse des Systèmes - E.N.S.I.A.S.

et d’ A nalyse des S ystèmes - E.N.S.I.A.S. Mémoire de Projet de Fin d’Etudes Pour

Mémoire de Projet de Fin d’Etudes

Pour l’Obtention du Titre

d’Ingénieur d’Etat en Informatique

Option Réseaux et Télécommunications

Sujet

Environnement E-Commerce sur plate-forme Internet

Soutenu par :

Mlle. N.FEREHAN Mlle. A.HAJAMI

Membres de jury :

M. M.EL KOUTBI(Président)

M. M.ERRADI(Encadrant) M. L.KIFA(Encadrant)

Année Universitaire 2000/2001

A mes très chers parents

Comment pourrai-je exprimer ma gratitude envers vous. Merci, pour votre amour, vos sacrifices et votre soutien tout au long de mon parcours. Que Dieu vous garde pour moi et vous donne une longue vie pleine de santé.

A ma très chère sœur Naima, qui était toujours à mon côté quand j’en avais besoin.

Je vous souhaite une vie pleine de bonheur.

A mes frères Noureddine et Tarik,

A mes petites sœurs Fikriya, Ibtissam, Hind, et Jalila.

Merci. Je vous suis très reconnaissante.

A l’ensemble de ma famille pour qui j’ai un grand respect.

A ma binôme et sœur Amina, à qui je souhaite bonne chance pour son prochain projet.

A mes chères amies avec qui j’ai passé des instants inoubliables.

A la mémoire de Mme Aïcha Berrada notre professeur à l’ENSIAS.

A tous ceux qui me sont chers.

Je dédie le fruit de mon projet de fin d’études.

Nourelhouda

A mes très chers Parents,

Nul mot ne pourra exprimer ma gratitude envers vous. Pour tout l’amour et le soutien que vous m’avez offerts, pour tout vos sacrifices, pour toutes les belles choses que vous m’avez apprises, pour tout,

je vous aime beaucoup.

Que Dieu vous garde pour moi et vous donne une longue vie pleine de santé.

A mon très cher frère Abdelmajid,

j’ai toujours cherché les expressions qui puissent correspondre à ce que tu représentes pour

moi, mais en vain. Pour t’exprimer mon respect et mon amour et ma gratitude, je n’ai pas trouvé les termes.

A mes très chers frères, Anass, Zakarya et Mehdi,

pour votre soutien, votre sympathie, et votre amour. Mon amour pour vous est aussi immense que la mer et le ciel.

A ma très chère amie Souad,

pour tous les moments de notre amitié.

A Nourelhouda,

pour ton soutien et ta gentillesse.

A toutes mes amies,

pour tous les moments inoubliables que nous avons passés ensemble.

A mes amis,

pour votre sympathie, votre soutien et votre encouragement.

A tous les gens qui m’ont soutenue le long de mon parcours.

A

la mémoire de notre professeur regrettée Mme Aïcha BERRADA.

A

tous ceux qui m’aiment,

je

vous aime plus que vous le croyez.

Je dédie le fruit de mon projet de fin d’études.

&Remerciements&

Amina

Au terme de ce projet de fin d’études, nous exprimons notre profonde gratitude et

tenons à remercier M. M.ERRADI et M. M.SENHADJI pour leurs directives précieuses et conseils pertinents.

Nous remercions aussi M. L.KIFA pour sa gentillesse et son soutien le long de la

période de notre stage.

Nos remerciements s’adressent également à M. M.EL KOUTBI qui a bien voulu

évaluer notre travail.

Nos remerciements vont également à Mlle Assia SENHADJI qui n’a aménagé ni son

temps ni son énergie pour nous aider à avancer dans notre projet. Sa gentillesse et son dynamisme nous ont touchées profondément.

Nous saisissons aussi l’occasion pour remercier tout le personnel de COMPUTIME

pour

leur

gentillesse

et

leur

soutien

notamment

Jamal,

Noureddine,

Hamid

et

Lhoussine.

 

Que le corps professoral

remerciements.

et

administratif

de

l’ENSIAS

trouve

ici

nos

vifs

Nous remercions toutes les personnes qui nous ont aidées, de prés ou de loin, au cours

de ce projet.

Résumé

Le domaine du commerce électronique via Internet est actuellement en pleine expansion. Les entreprises de toutes les tailles et partout dans le monde cherchent à se procurer une solution de E-Commerce.

Le marché marocain a, lui aussi, besoin de solutions E-Commerce. Plusieurs discussions, émissions télévisées, séminaires et réunions sont faits pour la promotion de cette technologie dans notre pays.

Le développement d’une solution pour le commerce électronique interentreprises nécessite toute une démarche d’études avant d’entamer la réalisation proprement dite.

Il faut, avant tout, faire une étude sur le domaine en question : le commerce électronique. Cette étude a pour but de connaître l’environnement général et les notions conjointes à l’E-Commerce. Ensuite, il faut définir une architecture générale de la solution désirée. Puis, il est nécessaire de connaître, en gros, les différents outils de développement pour pouvoir choisir l’outil qui répond plus aux besoins spécifiés dans l’architecture précédemment élaborée.

Abstract

The area of the electronic trade on Internet is currently in full expansion. Enterprises of all sizes and everywhere in the world seek to obtain a solution of E-Commerce.

The Moroccan market needs E-Trade solutions. Several discussions, televised emissions, seminaries and meetings are made for the promotion of this technology in our country.

The development of a solution for the Business to business E-Commerce necessitates all a step of studies before to start the realization.

It is necessary, before all, to make a study on the area in question : Electronic Commerce. This study has for goal to know the general environment and notions joint to the E-Commerce. Then, it is necessary to define a general architecture of the solution desired. Then, it is necessary to know the different tools of development to be able to choose the tool that replies more to needs specified in the previously elaborate architecture.

Table des matières

Table des matières Remerciements--------------------------------------------------------------------------------- 4
Table des matières Remerciements--------------------------------------------------------------------------------- 4

Remerciements--------------------------------------------------------------------------------- 4 Résumé----------------------------------------------------------------------------------------- 5

Abstract---------------------------------------------------------------------------------------- 6

Table des matières---------------------------------------------------------------------------

7

Liste des figures------------------------------------------------------------------------------

10

Liste des tableaux----------------------------------------------------------------------------- 12

13

Partie I : Environnement général du projet-------------------------------------------- 15 Chapitre I : Description du projet------------------------------------------------ 16

Introduction générale-----------------------------------------------------------------------

I.1 Description du projet EECPI--------------------------------------------------------- 16

I.2 Démarche de réalisation du projet--------------------------------------------------- 17

Chapitre II : Présentation de l’organisme d’accueil-------------------------- 19

19

II.1 Mission et projets stratégiques-----------------------------------------------------

II.2 Les services de COMPUTIME------------------------------------------------------ 19

20

Partie II : Généralités sur le Commerce Electronique------------------------------ 21

Chapitre III : EDI : Echange de Données Informatisé----------------------- 22

II.3 Secteurs d’activités-------------------------------------------------------------------

III.1 La démarche de la mise en place de l’EDI---------------------------------------

22

III.2 Les différents modes d’échange---------------------------------------------------

24

III.3 Les composants d’une architecture EDI------------------------------------------ 25

III.4 Les réseaux EDI---------------------------------------------------------------------- 28

ChapitreIV : Le langage Edifact-------------------------------------------------- 37

VI.1 Le standard Edifact------------------------------------------------------------------ 37

VI.2 Le langage Edifact et la sécurité--------------------------------------------------- 44

VI.3 Un aperçu sur d’autres langages--------------------------------------------------- 45

Chapitre V : Le commerce Électronique---------------------------------------- 47

V.1 Vue d’ensemble--------------------------------------------------------------------

47

V.2 Le commerce électronique au Maroc-------------------------------------------

47

V.3 Commerce traditionnel et commerce électronique----------------------------- 48

V.4 L’infrastructure du commerce électronique------------------------------------

50

V.5 L’avenir avec le commerce électronique---------------------------------------- 50

Partie III : Etude de la solution E-Commerce----------------------------------------- 51

Chapitre VI : Architecture de la solution--------------------------------------- 52

52

VI.1 Architecture générale-------------------------------------------------------------

VI.2 Scénario B to B-------------------------------------------------------------------- 53

VI.3 Front Office et Back Office------------------------------------------------------ 55

Chapitre VII : Etude comparative des plates-formes et choix de l’outil de travail--------------------------------------------------------- 58

VII.1 Les logiciels sur le marché------------------------------------------------------ 58

VII.2 Plate-forme------------------------------------------------------------------------ 60

VII.3 Composants----------------------------------------------------------------------- 63

VII.4 Fonctionnalités-------------------------------------------------------------------- 66

Chapitre VIII : Composants de la solution choisie--------------------------- 69

VIII.1 Les composants de Commerce Server---------------------------------------- 69

VIII.2 Intégration de la traduction Edifact------------------------------------------- 74

VIII.3 Pipeline Editor------------------------------------------------------------------- 75

Conclusion------------------------------------------------------------------------------------- 76

Glossaire---------------------------------------------------------------------------------------- 77

Annexes--------------------------------------------------------------------------------- 82

Annexe A : Pipeline Editor-------------------------------------------------------------------

83

Annexe B : Procédure d’installation de Commerce Server------------------------------- 93

Annexe C : L’architecture Client/Serveur--------------------------------------------------

96

Annexe D : COM/MTS : Le Middleware de Microsoft----------------------------------

106

Annexe E : Le langage XML----------------------------------------------------------------- 111

Liste des figures

Liste des figures Figure 1 : La démarche du projet -------------------------------------------------------------- 18
Liste des figures Figure 1 : La démarche du projet -------------------------------------------------------------- 18

Figure 1 : La démarche du projet --------------------------------------------------------------

18

Figure 2 : Architecture d’un système EDI : les interfaces applicatifs---------------------

25

Figure 3 : Les composantes d’une solution EDI : Le traducteur---------------------------

26

Figure 4 : Couche EDI entre applications et communications-----------------------------

28

Figure 5 : Lien direct entre partenaires--------------------------------------------------------

29

Figure 6 : Réseaux tiers vus comme une boite aux lettres électronique -----------------

31

Figure 7 : Structure du message Edifact------------------------------------------------------

42

Figure 8 : Le diagramme simplifié du message facture (Invoic)--------------------------

42

Figure 9 : Schéma hiérarchique d’une transmission en interchange Edifact-------------

44

Figure 10 : Architecture générale pour l’échange informatisé sur Internet--------------

53

Figure 11 : Scénario Entreprise /Client-------------------------------------------------------

54

Figure 12 : Scénario Entreprise /Transitaire--------------------------------------------------

54

Figure 13 : Scénario d’une transaction bancaire---------------------------------------------

55

Figure 14 : Les éléments du Front office et du Back office--------------------------------

57

Figure 15 : Architecture technique requise par Commerce Server------------------------

61

Figure 16 : Architecture technique de WebSphere------------------------------------------

63

Figure 17 : Les composants de Commerce Server-------------------------------------------

70

Figure 18 : Utilisation du Pipeline d’échange commercial---------------------------------

74

Figure 19 : Intégration de la traduction Edifact----------------------------------------------

75

Figure 20 : L’architecture Client/Serveur ----------------------------------------------------

96

Figure 21 : Architecture Client lourd /Serveur léger----------------------------------------

97

Figure 22 : Architecture Client léger/Serveur lourd-----------------------------------------

98

Figure 23 : Architecture Client/Serveur à trois niveaux------------------------------------

98

Figure 24 : Architecture Web à trois niveaux------------------------------------------------

101

Figure 25 : Architecture DNA -----------------------------------------------------------------

103

Figure 26 : Les pages ASP----------------------------------------------------------------------

104

Figure 27 : MTS----------------------------------------------------------------------------------

105

Figure 28 : interface, implantation d’interface et instance d’interface--------------------

107

Figure 29 : Le Middleware COM--------------------------------------------------------------

109

Figure 30 : Exemple d’application structurée en trois étages réalisée avec DCOM----

110

Liste des Tableaux

Liste des Tableaux Tableau 1 : Exemple de données Composites------------------------------------------------ 39
Liste des Tableaux Tableau 1 : Exemple de données Composites------------------------------------------------ 39

Tableau 1 : Exemple de données Composites------------------------------------------------

39

Tableau 2 : Les niveaux d’Edifact---------------------------------------------------------

40

Tableau 3 : Les segments de service Edifact --------------------------------------------

41

Tableau 4 : Délimiteurs Edifact------------------------------------------------------------

43

Tableau 5 : Nouvelle et ancienne méthode d’achat d’un produit ------------------------

49

Tableau 6 : Différentes plates-formes e-commerce sur le marché------------------------- 59

60

Tableau 8: Fonctionnalités offertes par : Commerce Server et WebSphere-------------- 68

Tableau 7 : Comparaison configuration matérielle requise--------------------------------

Tableau 9 : Les composantes en rapport avec l’étape d’envoi de l’ordre d’achat-------

73

Tableau 10 : Modèles standards de création de pipeline -----------------------------------

85

Tableau 11 : Comparaison entre l’architecture 2-tiers et 3-tiers---------------------------

99

Tableau 12 : Architecture DNA ---------------------------------------------------------------

102

Introduction générale

Introduction générale L’ère actuelle des nouvelles technologies de l’information se concentre sur le commerce
Introduction générale L’ère actuelle des nouvelles technologies de l’information se concentre sur le commerce

L’ère actuelle des nouvelles technologies de l’information se concentre sur le commerce électronique. Cette notion supprime les frontières nationales, impose de nouvelles approches commerciales et invite les différents acteurs de l’économie à y prendre partie. C’est une façon de bénéficier de l’évolution des outils informatiques et des bénéfices de l’Internet qui assure une présence sur le niveau mondial avec un coût réduit.

La mise en œuvre sécurisée du commerce électronique est une entreprise qui à 80% juridique et 20% technique. La solution juridique est un préalable fondamental à l’utilisation des moyens électroniques de transmission de données commerciales [CIDPCE]. Or la promotion du commerce électronique se heurte à des obstacles d’ordre juridique à cause du décalage entre le droit et l’évolution technique.

Au même titre que l’entreprise, l’administration est plus que jamais concernée par le phénomène du E-Commerce. Elle est concernée, dans un premier lieu, parce qu’elle gère un gisement informationnel immense dont le libre accès doit être garanti dans des conditions transparentes. En second lieu, elle est concernée par le fait qu’elle constitue un agent économique actif de production et d’échange de biens et services.

Le concept du commerce électronique envahi divers domaines et se crée des notions conjointes. Ainsi on peut distinguer trois principaux domaines du commerce électronique : le commerce entreprise/consommateur dit B to C (Business to Consumer), le commerce interentreprises dit B to B (Business to Business), et le commerce entreprise/administration dit B to A (Business to Administration). Les médias font plus de lumière sur le commerce B to C, alors que le commerce B to B représente la partie la plus importante du marché.

Le B to B concerne les échanges et les traitements commerciaux entre entreprises. Depuis les années soixante, l’échange de données informatisé (EDI) existe au niveau mondial. La mise en place d’un système EDI est coûteuse ce qui la rend à la portée des grandes entreprises seulement.

Les opportunités offertes par l’Internet modifient les perspectives commerciales des petites et moyennes entreprises. L’Internet représente pour les PME un portail pour entrer dans l’ère du E-Commerce.

Notre projet intitulé « Environnement E-Commerce sur plate-forme Internet » a pour but de proposer une solution pour le domaine du commerce électronique interentreprises sur Internet. Une solution désignée aux PME/PMI désirant avoir leur propre solution E-Commerce.

Le présent rapport est divisé en trois grandes parties. Dans la première partie nous présentons l’environnement général du projet. Ainsi dans le premier chapitre nous présentons notre projet. Une présentation de l’organisme d’accueil est faite dans le deuxième chapitre. La deuxième partie du rapport porte sur des généralités sur le commerce électronique. Nous y présentons les principales notions relatives au domaine du commerce électronique interentreprises. De ce fait le troisième et le quatrième chapitres sont respectivement consacrés à la présentation de l’EDI et de la norme Edifact. Nous présentons ensuite le commerce électronique dans le cinquième chapitre. La troisième partie contient l’étude de la solution E-Commerce. Ainsi nous détaillons dans le sixième chapitre l’architecture de la solution. Le septième chapitre est une étude comparative des différents outils existant de mise en œuvre de la solution. Quant au dernier chapitre, il porte sur les composants de la solution retenue avec une proposition d’extension.

A la fin du rapport, nous présentons en complément les différentes annexes. Ces annexes traitent successivement le Pipeline Editor, la procédure d’installation de Commerce Server, l’architecture client/serveur, le Middleware COM/MTS, et le langage XML.

Partie I

Environnement général du projet

Dans cette partie nous présentons l’environnement général de notre projet « Environnement E-Commerce sur plate-forme Internet ». Le premier chapitre est une description du projet. Dans le deuxième chapitre nous présentons l’organisme qui nous a accueillies pendant la période de notre projet de fin d’études, à savoir la société COMPUTIME.

Chapitre

I

Description du projet

Les opportunités d’affaires en matière de gestion de transactions commerciales entre entreprises sur l’Internet devraient se multiplier de part le coût réduit de cette plate- forme. Des entreprises de toutes tailles peuvent en bénéficier. Les PME/PMI ont besoin d’une solution E-Commerce sur Internet. Il est donc nécessaire de concevoir et de réaliser une architecture du commerce électronique qui donne la possibilité de monter et de configurer des solutions qui répondent à ce besoin.

I.1 Description du projet EECPI 1

Notre projet vise à développer un environnement pour supporter le commerce électronique et spécialement le domaine interentreprises (B to B) sur plate-forme Internet. Il entre dans le cadre des solutions destinées aux PME/PMI désirant avoir leur propre solution pour effectuer des opérations commerciales.

Notre solution consiste à :

Développer un site Web pour le e-business. Cela revient à développer un site

Web dynamique qui contient un catalogue des produits avec leur description, et de traiter toute commande lancée par les clients.

Créer la base documentaire, qui est un système d’information contenant toutes

les données concernant les produits et services de l’entreprise, de ses clients potentiels avec leurs préférences, des produits fréquemment consultés et achetés, et des fournisseurs.

Mettre en œuvre la base de connaissance qui n’est autre qu’un programme qui

permet de guider les clients à choisir les produits qui répondent mieux à leurs besoins. Ainsi, suivant un ensemble de critères signalés et un besoin exprimé, une ou plusieurs solutions sont proposées aux clients.

Paramétrer les documents par l’Edifact : les documents fréquemment échangés

que ce soit avec les partenaires ou avec la banque tel que la facture, le devis,…seront traduits en format standard vérifiant la norme Edifact. Ainsi un système de traduction sera mis en place pour assurer le codage et le décodage de ces documents.

1 Environnement E-Commerce sur Plate-forme Internet.

I.2 Démarche de réalisation du projet

Pour mener à bien la réalisation de notre projet, nous avons adopté une démarche qui assure la maîtrise du développement du projet, pour ne pas tomber dans le piège du tâtonnement de plusieurs chemins qui puisse donner un résultat qui ne soit ni sûr ni maîtrisable.

Nous avons divisé le projet en plusieurs étapes. La première consiste à faire une étude pour mieux se familiariser avec les notions de l’EDI et le commerce électronique. Ces notions qui, jusqu’au début de ce projet, nous étaient floues, voire inconnues.

Une fois les notions relatives au domaine du commerce électronique et à l’EDI sont plus claires et mieux connues, il était possible de donner une architecture bien détaillée de l’environnement e-commerce qui contient tous les composants nécessaires pour monter une solution en ligne. Ceci était l’objectif de la deuxième étape.

Avant de choisir une plate-forme qui va permettre d’implémenter cette solution, une étude comparative des outils de développement était primordiale dans la troisième étape. Nous avons consacré la quatrième étape à l’installation de l’environnement de développement.

Comme l’outil choisi donne plusieurs fonctionnalités, nous l’avons adapté à notre situation, avant d’ajouter les composants requis. Ceci est fait lors de la cinquième et la sixième étape.

La dernière étape concerne le traitement de site de COMPUTIME.

La figure 1 présente le diagramme des différentes étapes du projet.

Etude préalable Se familiariser avec les notions EDI et commerce électronique Conception de l’architecture
Etude préalable
Se familiariser avec les
notions EDI et commerce
électronique
Conception de l’architecture
Modéliser l’environnement
du commerce électronique
Etude comparative
Comparer les différentes plates-
formes de développement
Installation de la plate-forme
Installation de la plate-forme
choisie
Adaptation de l’outil
Utilisation des
composants
Ajout de nouveaux composants
Mariage Commerce Server
et Edifact
Application au site de Computime
Appliquer au cas de
Computime
Figure 1 : la démarche du projet

Les étapes du projet sont ainsi définies avec le résultat de chaque étape. La dernière étape concerne la réalisation du projet pour le compte de la société COMPUTIME. Le chapitre suivant présente cette société qui nous a accueillies pendant la période du stage.

Chapitre

II

Présentation de l’organisme d’accueil

Dans ce chapitre nous présentons l’organisme d’accueil, COMPUTIME. Nous commençons par donner ses missions et ses objectifs stratégiques, ensuite les services qu’il offre à ces clients. Enfin, nous décrivons ses secteurs d’activité.

II.1 Mission et objectifs stratégiques

COMPUTIME a pour mission d’offrir à ses clients des solutions d’automatisation de la saisie de données pertinentes et de haute performance.

Grâce à son savoir-faire, COMPUTIME permet à ses clients d’avoir accès à une technologie de haute gamme pour la construction de leur système d’information.

La démarche globale adoptée par la société COMPUTIME pour l’élaboration de sa politique d’entreprise a pour base les principes suivants :

Etre en état constant de veille technologique et éprouver les progrès techniques du secteur.

S’adapter aux contraintes existantes et proposer des solutions d’automatisation progressives.

Encadrer ses clients dans la mise en place de solutions grâce à une offre de service couvrant le conseil, l’ingénierie et le déploiement.

Opter pour les meilleurs produits permettant la mise en place d’une solution de haute performance.

II.2 Les services de COMPUTIME

COMPUTIME est une société d’ingénierie des systèmes ADC (Automatic Data Collection). Ses services sont centrés autour du conseil et de l’intégration des systèmes d’Identification automatique et des systèmes d’information.

Compte tenu de son expertise dans les systèmes d’information et son savoir-faire en matière d’interfaçage avec des moteurs de bases de données existants, COMPUTIME a développé des solutions pour :

Gestion des temps

Contrôle d’accès

Suivi de production

suivi d’objet

Suivi du contrôle-qualité

Solution pour les points de vente

II.3 Secteurs d’activités

COMPUTIME opère sur trois secteurs d’activités :

II.3.1 Etude, Ingénierie et Conception

Solutions dans le domaine des systèmes d’information, de codification des

données, conception des codes à barres linéaires 1D/2D,

Conception des supports : Etiquettes, Tag, Badges, vignettes.

Conseil et assistance technique pour le choix de systèmes.

II.3.2 Développement

Développement d’application de gestion des temps.

Développement d’application de suivi d’objets.

Développement d’application de suivi du contrôle-qualité.

Développement pour les applications des terminaux portables et terminaux

industriels.

II.3.3 Conception / Réalisation de systèmes clés en main

Conception, implantation, configuration, assistance technique et formation du

personnel sur les systèmes d’information autour de cartes multifonctions : pointage, contrôle d’accès, suivi des temps d’activité.

informatiques globales de codification et

d’identification automatique.

Mise

en

place

de

solutions

Solutions autour du concept CIM (Computer Integrated Manufacturing).

Nous avons présenté dans ce chapitre un tour d’horizon des activités de la société COMPUTIME. Dans la partie suivante du rapport, nous exposons des généralités sur le commerce électronique.

Partie II

Généralités sur le Commerce Electronique

Cette partie porte sur les notions relatives au domaine du commerce électronique. Nous y présentons successivement : l’EDI, comme forme spécifique du commerce électronique, l’Edifact, le langage standard de l’EDI, et enfin le commerce électronique, en donnant un survol sur ce concept.

Chapitre

III

EDI :

Echange de Données Informatisé

Les entreprises tendent actuellement à se rapprocher les unes des autres, sous la pression des exigences du climat accrue imposé par la mondialisation. Ainsi, une langue commune conventionnelle s'impose en vue d'une universalité de la communication.

L'Echange de Données Informatisé -EDI- offre aujourd'hui des moyens automatisés et normalisés. Ceci permet aux entreprises d’échanger des documents, pratiquement sans intervention humaine et en se dégageant des moyens traditionnels comme le courrier ou le téléphone.

L’EDI est une forme d’échange d’informations utilisant les réseaux. Il peut être défini comme l’échange entre applications hétérogènes, avec automatisation des traitements.

Dans un système EDI, c’est tout le processus d’échange qui est informatisé.

Au-delà des classifications, il s’agit d’une déclaration de principe :

L’EDI met en jeu un processus informatisé, et non seulement une opération isolée.

Il met en relation des systèmes d’information.

Il a pour objectif des gains en efficacité et en productivité, avec l’automatisation de certains aspects ou de la totalité de ce processus.

Ainsi, il s’agit d’échange non seulement de machine à machine mais de système d’information à système d’information. Cet échange est effectué sans modifier les applications qui fournissent ou reçoivent des informations. Par ailleurs, il s’agit bien des échanges automatisés.

Les pages suivantes essayeront de donner un état de l'art de cette technologie.

III.1 La démarche de la mise en place de l’EDI

Des travaux, débats et recherches conceptuelles tournent le plus souvent autour de la définition des étapes d’un projet de l’EDI.

Ainsi, après la prise de décision pour intégrer l’EDI dans le réseau communautaire, il convient, en général, de suivre les étapes suivantes :

III.1.1 Identifier tous les partenaires du réseau communautaire

La première étape consiste à déterminer l’ensemble des partenaires selon des critères spécifiques. Ces critères sont : le secteur d’activité, la taille de l’entreprise, le style de management et la culture de l’entreprise, le type de données utilisé, ainsi que l’environnement de l’entreprise.

Il faut également déterminer tous les documents échangés en utilisant l’EDI, ainsi que la part de chaque partenaire en volume documentaire.

III.1.2 Spécifier les scénarios de messages

Cette phase consiste à effectuer une étude documentaire pour la transmission de documents par la voie de l’EDI et en déduire la liste des messages à utiliser.

Une série de recherches réalisée pour voir si des messages normalisés et appropriés existent dans la liste des documents à transmettre. Il faut donc :

Analyser la bibliothèque des répertoires de données élémentaires utilisées.

Analyser la bibliothèque des répertoires de segments utilisés.

Analyser la bibliothèque des répertoires de messages utilisés et déterminer le scénario d’échange de ces messages.

Si l’on ne trouve pas de messages appropriés, il faudra se résigner à développer de nouveaux messages spécifiques.

III.1.3

normalisés

Cette étape consiste à définir les dictionnaires élémentaires des données, c’est à dire la référence des données qui seront échangées. Il faut également constituer le dictionnaire des messages, ce qui correspond aux formulaires destinés à l’échange.

Il est recommandé dans cette démarche d’utiliser le maximum des éléments déjà existants dans la norme, surtout la spécialisation des échanges logiques.

Ce qui revient à définir les procédures administratives de chaque partenaire en matière de classement, archivage, édition, exploitation en rapport avec les applications spécifiques de chaque utilisateur. Et à déterminer la liste des destinataires de chacun des partenaires et les flux de messages pour chaque destination.

formats

Etablir

les

correspondances

entre

formats

privés

et

III.1.4 Définir la norme et les réseaux de télécommunications

Lors de cette phase, on détermine la norme à utiliser dans l’échange et on définit la solution technique : matériels, logiciels et les réseaux de communication.

Ce choix est conditionné par l’infrastructure technique existante au niveau de chaque partenaire.

Les problèmes de sécurité de transmission sont aussi négociés et résolus avant de commencer l’implémentation de l’EDI.

III.1.5 Mettre en œuvre le système

Cette phase est celle de la personnalisation pour chacun des membres de la communauté EDI, avec la préparation des éléments matériels et logiciels à intégrer.

Elle est également la phase de développement des systèmes de conversion de formats, des correspondances et leur mise en œuvre. Il est possible à la suite de réaliser des procédures de test pour valider le modèle.

III.1.6 Adopter un accord d’interchange

L’usage de l’informatique, dans sa forme télématique implique la disparition du papier accompagne de la disparition du e droit qui exige le papier.

C’est un vrai heurt entre le droit et l’informatique. Le contrat d’interchange a pour but de combler ce vide juridique existant.

III.2 Les différents modes d’échange

Il existe trois modes d’échange pour l’EDI :

III.2.1 Le mode autonome

Cette solution consiste à installer l’ensemble de la solution EDI, sur un même ordinateur. L’activité EDI est alors entièrement indépendante du système informatique de l’entreprise.

les données ne sont pas échangées électroniquement entre ces ensembles, elles sont traitées manuellement entre le logiciel EDI et les applicatifs de gestion de l’entreprise.

III.2.2 Le mode intégré

Ce mode consiste à installer l’ensemble de la solution EDI directement sur l’ordinateur qui supporte les applicatifs.

L’activité

l’entreprise.

EDI

est

alors

entièrement

intégrée

dans

le

système

informatique

de

III.2.3 Le mode frontal

Ce mode consiste à installer l’ensemble de la solution EDI sur un ordinateur, qui possède un lien avec le système informatique.

L’activité EDI est alors indépendante dans ses traitements, mais les applicatifs de gestion et la solution EDI communiquent par transfert.

On parle alors de rapatriement et d’extraction des données.

III.2 Les composantes d’une architecture EDI

L’introduction de la nouvelle technologie facilitera et accélérera l’échange de données et les transactions commerciales entre les entreprises. En particulier l’utilisation de l’EDI.

Ce système est constitue de trois composants principaux :

L’environnement applicatif.

Le logiciel EDI.

Les systèmes de communication.

III.2.1 L’environnement applicatif

Il

et

comprend :

l’ensemble des applications qui vont fournir ou récupérer les informations échangées,

correspond

aux

applications

concernées

par

les

informations

échangées,

 les interfaces "pivots" entre ces applications et les logiciels EDI, "Traducteur" ou
 les interfaces "pivots" entre ces applications et les logiciels EDI, "Traducteur" ou
"Gestionnaire de transactions EDI".
Fichiers
« Plate »
Traducteur
Application1
Ou
Gestionnaires de
Interface Pivot
Application2
Transactions
EDI
Base de
Application3
Données
des
échanges

III.2.2 Les logiciels EDI

Communément appelés « Traducteur » ou aussi « Gestionnaire de transactions EDI ». Ils assurent comme fonction principale la conversion des données, à l’émission et à la réception, d’un format propriétaire à un format Edifact ou inversement.

Ces logiciels peuvent assurer, de plus, un ensemble de fonctions complémentaires ayant trait à la sécurité et à la gestion des accordes d’interchange.

Généralement, le traducteur fait appel aux composantes qui figurent sur le schéma ci- dessous :
Généralement, le traducteur fait appel aux composantes qui figurent sur le schéma ci-
dessous :
Système d’information
Gestion des fichiers
Traduction des données
Gestion de la station
Formatage des données
Vers les
partenaires
Gestion des communications

Figure 3 : Les composantes d’une solution EDI : Le traducteur

a. La gestion des fichiers

Cette étape permet de sortir l’application vers les partenaires EDI. On parle de fichiers privatifs ou de fichiers applicatifs.

b. La traduction des données

Cette section effectue la traduction du format local au format EDI normalisé.

c.

Le formatage des données

Cette composante regroupe les données en fonction des profils d’utilisation. Elle permet en effet la subdivision en groupes fonctionnels, en messages et en segments. L’ensemble sera confié aux réseaux de télécommunications.

d. La gestion des communications

Regroupe les protocoles d’échange de l’information, la session avec les partenaires, ou avec les réseaux à valeur ajoutée.

e. La gestion de la station

Contribue à l’administration, aux contrôles généraux, à la gestion des erreurs éventuels, le paramétrage.

III.2.3 Les systèmes de communication

L’architecture applicative est supportée par les réseaux de télécommunication. Dans ce contexte, il faut noter que les différents protocoles et systèmes de télécommunication cèdent la place à un standard universel, celui d'Internet.

L'EDI est en général supporté par la messagerie (sur Internet ou d'autres systèmes). Cependant, comme pour la messagerie interpersonnelle, il est possible, par exemple, de véhiculer des messages au travers d'HTTP, c'est-à-dire sur le Web.

Quoi qu'il en soit, le système de communication sous-jacent comprend un outil de gestion de la messagerie, le Message Handling System (MHS).

Il est souhaitable que l’EDI travaille avec les moyens de communication. Et donc qu'il y ait une forte indépendance entre le système de traduction/gestion des messages et les outils de communication.

Le schéma suivant fournit une vue des "couches" transport et applications EDI.

Les logiciels de communication dialoguent eux-mêmes avec des couches inférieures qui sont celles qui relient les systèmes informatiques au réseau.

Figure 4 : Couche EDI entre applications et communications III.3 Les réseaux EDI Lorsque des

Figure 4 : Couche EDI entre applications et communications

III.3 Les réseaux EDI

Lorsque des partenaires désirent échanger des données informatisées, ils doivent être reliés d’une manière ou d’une autre.

Cette liaison peut s’effectuer en deux modes : directe ou indirecte.

3.3.1 Echanges directs

En EDI point par point ou direct, les partenaires échangent directement des communications électroniques. En d’autres termes, il existe un moyen d’accès direct de l’ordinateur de l’expéditeur vers l’ordinateur du destinataire.

L’accès direct est le plus souvent utilisé par des lignes téléphoniques et un modem d’ordinateur.

Un partenaire qui utilise un modem d’ordinateur compose simplement le numéro d’appel d’un autre partenaire.

Liaison directe Partenaire 1 Partenaire2 Figure 5: Lien direct entre partenaires
Liaison directe
Partenaire 1
Partenaire2
Figure 5: Lien direct entre partenaires

Pour qu’une liaison directe puisse fonctionner, les organismes doivent être compatibles d’un point de vue communications.

Ainsi les partenaires doivent-ils utiliser les mêmes protocoles de lignes, de débits, etc. Les deux parties doivent également utiliser les mêmes standards ou avoir la possibilité de traduction d’un standard à un autre.

De plus puisque l’expéditeur appelle directement les partenaires, les parties doivent se mettre d’accord sur les heures de disponibilité de chaque système. Ainsi l’ordinateur qui reçoit doit être ouvert et libre quand l’émetteur envoie son message.

Un système direct peut fonctionner lorsqu’un organisme communique électroniquement avec seulement un petit nombre de partenaires. Cependant lorsque ce nombre augmente, il devient de plus en plus difficile d’établir des liaisons avec chacun d’entre eux.

Un certain nombre d’organismes échangent actuellement des données informatisées avec de nombreux partenaires au moyen de systèmes directs, ou point par point.

Mais beaucoup d’entreprises estiment trop difficile de maintenir des liaisons directes avec un nombre important de partenaires.

En effet, la possibilité d’être relié directement avec de nombreux partenaires relier par protocoles de communication différents est extrêmement chère.

III.3.2 Liaison indirecte ou passage par un réseau tiers

III.3.2.1 Le rôle des réseaux tiers

Les réseaux tiers se sont développés, dans la communauté EDI, pour résoudre les problèmes inhérents à l’établissement de communication avec plusieurs partenaires.

Les expériences récentes montrent que la plupart des entreprises se tournent vers un réseau tiers lorsqu’elles atteignent un volume EDI allant de quatre à six partenaires.

En fait, un réseau tiers fournit la compétence et l’expertise en matière de communications, et de l’équipement nécessaire aux communications électroniques.

De plus un réseau tiers peut offrir des services à valeur ajoutée, comme la traduction aux standards, les connexions internationales, et les connexions à d’autres réseaux tiers.

On peut utiliser un réseau tiers de deux manières : comme une simple boîte aux lettres

électronique ou bien pour des services additionnels. Ceci valeur ajoutée.

III.3.2.2 Le service courrier des réseaux tiers

Le service le plus simple que peut fournir un réseau tiers est celui d’une boite aux lettres électroniques.

Dans ce cas, le réseau offre un service très semblable à celui fourni par le service postal. Le service postal reçoit les lettres des expéditeurs, trie le courrier par destinataire et le dépose dans la boîte aux lettres du destinataire.

Les réseaux tiers fonctionnent exactement de la même manière, en fournissant des boîtes à lettres électroniques pour les messages EDI.

Comme on le voit sur la figure ci-dessous, un réseau tiers crée une boîte électronique pour chaque partenaire.

dans le cadre d’un réseau à

L’expéditeur transmet des messages informatisés au réseau tiers, habituellement en composant son numéro d’abonné, sur les lignes téléphoniques. Ce dernier reçoit les messages électroniques et les trie par destinataire.

Les messages électroniques sont alors stockés dans les boîtes à lettres des destinataires, jusqu’à ce qu’ils soient relevés par un appel du destinataire.

La majorité des réseaux tiers permettent à leurs utilisateurs de relever leurs messages en attente, en même temps qu’ils effectuent leurs envois.

De plus la plupart des réseaux tiers fonctionnent 24 heures sur 24 et 7 jours sur 7.

Réseau tiers Partenaire A Partenaire B reçoit Trie Boîte aux Boîte aux lettres du lettres
Réseau tiers
Partenaire A
Partenaire B
reçoit
Trie
Boîte aux
Boîte aux
lettres du
lettres du
partenaire
partenaire
A
B
Figure6 : Réseaux tiers vus comme une boîte aux lettres électronique

III.3.2.3 Avantages des boîtes aux lettres électroniques

L’utilisation d’un réseau tiers comme boîte aux lettres électronique élimine un certain nombre de problèmes associés aux liaisons directes avec les partenaires.

Au nombre d’avantages que l’on en retire, on peut citer :

Elimination des problèmes de compatibilité des communications

L’un des avantages à utiliser un réseau de boîte aux lettres(BAL) électronique est que l’entreprise compose un numéro d’appel unique, celui du réseau tiers.

Sa seule obligation est donc d’être compatible avec un seul ensemble de matériels et de spécifications, sur le plan de communication.

De plus, la plupart des réseaux tiers sont capables de recevoir et émettent en de nombreux protocoles de communications, et à plusieurs vitesses de transmission. En fin en raison du fonctionnement 24 heures sur 24, les zones horaires ne constituent pas un problème.

Par exemple, grâce à sa BAL, une grande société de produits de consommation courante émet et reçoit des messages à trois heures du matin chaque jour. Cela permet à l’entreprise de garder à la fois ses lignes téléphoniques et son système informatique

libres, pendant la journée, pour d’autres activités. Et l’entreprise profite des tarifs réduits puisque les appels se font aux heures creuses.

Appel ou connexion unique

Avec une BAL, il n’y a qu’un seul appel à effectuer pour pouvoir joindre tous ses partenaires. L’expéditeur appel le réseau tiers qui appelle, à son tour, chacun des partenaires.

De plus l’appel au réseau tiers se fait généralement à un numéro vert gratuit ou en passant par un numéro local. L’appel est donc tarifé au maximum comme un appel local, indépendamment de l’endroit où se trouve le partenaire.

Informations de contrôle

De plus des fonctions de stockage, de réception et d’expédition des messages, BAL fournit également des informations de contrôle.

La plupart de ces réseaux génèrent un relevé d’activité, qui indique la teneur et la destination des envois, et un relevé des messages reçus dans la boîte aux lettres.

Très souvent, le relevé d’activité est établi « par exception », et ne fait état que des messages de la boîte aux lettres qui n’ont pas été relevés pendant les 24 dernières heures.

Mémoire tampon de sécurité

Un autre avantage des réseaux tiers et qu’ils agissent comme une mémoire tampon entre l’ordinateur de l’entreprise et ses partenaires. En les utilisant, on peut faire de l’EDI, sans avoir aucun ordinateur extérieur directement relié à l’ordinateur de l’entreprise.

III.3.2.4 Les services à valeur ajoutée

En plus des simples services de BAL, les réseaux tiers sont susceptibles de fournir des services à valeur ajoutée supplémentaires pour leurs clients EDI.

Lorsque ces services supplémentaires sont utilisés, on appelle habituellement le réseau tiers : « réseau à valeur ajoutée » ou RVA.

Dans son rôle de RVA, un réseau tiers est semblable à un bureau de poste. Les fonctions usuelles d ‘un bureau de poste peuvent comprendre la préparation du courrier, son étiquetage et son acheminement.

Les versions électroniques de ces fonctions sont réalisées par les réseaux tiers, lorsqu’ils jouent le rôle des réseaux à valeur ajoutée. Ces services additionnels incluent :

Les services de traduction

Un important service à valeur ajoutée fourni par le RVA est la traduction. Un réseau tiers reçoit les données dans un format spécifique à une entreprise donnée et traduire cette information au standard EDI.

Cela permet de faire l’EDI sans pour autant changer les logiciels du système interne. Une fois données à envoyer sont extraites des fichiers internes, le logiciel de l’ordinateur du RVA effectuera la traduction dans la norme EDI avant d’envoyer les données à un partenaire.

La traduction par le RVA permet de réduire les temps de développement et de mise en place du logiciel EDI. Mais il faut noter qu’à long terme, l’utilisation d’un RVA pour la traduction est une solution plus coûteuse que le développement sur place du logiciel approprié.

De plus il peut rendre plus difficile encore la décision de changer de RVA ou de se mettre à la traduction au sein même de l’entreprise.

La conversion en document papier

Les RVA offrent la possibilité de convertir les documents électroniques en messages sur papier. Ce format imprimé est alors envoyé au partenaire concerné, qui n’a pas la possibilité de recevoir les messages en EDI, soit par fax, soit par courrier postal.

La prise directe sur le réseau

Un autre service offert par le RVA est la prise directe sur le réseau. Les grandes entreprises permettent à leurs partenaires commerciaux d’accéder aux données de leurs systèmes.

Les partenaires doivent alors composer le numéro d’appel des ordinateurs des grandes entreprises pour récupérer l’information. Un RVA, par la prise directe sur le réseau, lance les appels nécessaires pour recouvrir l’information et place les messages dans la BAL.

En utilisant ce service, la firme doit seulement effecteur un seul appel, au réseau tiers, pour à la fois envoyer et recevoir les messages électroniques. Même si ces messages résident sur l’ordinateur d’un partenaire qui n’utilise pas les services d’un réseau tiers.

Chiffrement et authentification

Le chiffrement et l’authentification sont des possibilités importantes offertes par certains réseaux tiers.

Le chiffrement est le procédé qui consiste à changer un message EDI en message codé, qui ne peut pas être lu à moins que le destinataire ne possède la clé du code.

L’utilisation du chiffrement assure le secret des données. Au contraire, l’authentification des données n’assure pas le secret, mais garantit que les données ne sont pas modifiées.

L’authentification peut être utilisée comme une forme de signature électronique, puisqu’elle permet de vérifier l’identité de l’expéditeur. Avec l’authentification, le message EDI est changé en un message codé. Ce dernier est envoyé simultanément au destinataire avec le message EDI.

Bien qu’ils ne soient pas utilisés pour tous les messages EDI, le chiffrement et l’authentification sont courants dans l’activité bancaire, ou dans d’autres secteurs. Ils sont utilisés pour la transmission d’informations financières ou d’informations sensibles.

III.3.3 Association EDI / Internet

Internet va-t-il remplacer l’EDI ?

dire que l’EDI est un concept indépendant des réseaux de télécommunications

et des langages normalisés de communication, et Internet n’est qu’un support universel de service.

L’utilisation du Web actuellement pour l’EDI est possible. En effet, la messagerie d’Internet (SMTP : Simple Mail Transport Protocol) offre aujourd’hui des solutions plus perfectionnées. Afin d’autoriser la signature électronique des messages et leur cryptage, grâce à la version sécurisée S/MIME ou le MIME sécurisée.

Ainsi les réseaux à valeur ajoutée sont donc moins nécessaires, et Internet est tout à fait adapté à cette nouvelle syntaxe.

De quelle façon cette syntaxe intervient-elle en matière de sécurité ?

Elle fournit l’encadrement. Elle prévoit des éléments spéciaux pour protéger les messages individuellement, collectivement et par session d’échange. Elle propose des éléments d’accueil pour les services d’authentification, d’intégrité, de signature et de confidentialité. Il s’agit d’une structure d’accueil indépendante des réseaux et des protocoles qui facilitent les interactions entre les traducteurs d’un système EDI.

Il faut

III.4 Les avantages et les services de l’EDI

L’EDI est une technique qui agit sur tous les niveaux organisationnels de l’entreprise. Plus loin encore, il permet de :

Rationaliser les flux d’information externes de l’entreprise,

Métamorphiser la culture de l’entreprise,

Et bouleverser le système traditionnel des circuits papiers.

Ses avantages sont multiples et s’étendent à plusieurs dimensions. Nous allons classer, ci-dessous, ses services et ses portées par catégorie :

III.4.1 Portées stratégiques

- Permet de protéger des segments de marché.

l’avantage

concurrentiel.

-

Capture

de

nouveaux

segments

pour

le

développement

de

- Augmente les ventes et le nombre de clients.

- Améliore l’image de marque.

III.4.2 Portées pour l’organisation administrative

- Réduit le pourcentage d’erreurs.

- Améliore la qualité de l’information.

- Elimine la double saisie.

- Supprime les pénalités de retard.

- Améliore l’état des stocks.

- Réduit le coût du papier, des fax, poste et téléphone.

- Améliore la qualité de service.

- Réduit le nombre d’employés.

III.4.3 Au niveau du cycle ‘’commande- livraison- paiements’’

- Accélère les processus transactionnels et les règlements (commandes, factures, règlements).

- Compresse les délais.

III.4.4. Au niveau des relations avec l’environnement

- Améliore les relations avec les organisations et partenaires.

- Partage les bénéfices avec les partenaires.

- Fidélise la clientèle.

III.4.5 Portées pour le système d’information

de

l’information).

- Suivi logistique ‘’de bout en bout’’.

- Gain de place et de temps.

- Meilleure structure des archives.

- Crédibilité élevée des statistiques.

- Contrôle élevé des coûts.

- Couverture plus importante des besoins.

- Interfaçage automatique des applications de l’entreprise.

- Communication banalisée avec tous les partenaires.

Selon les besoins et les sensibilités techniques des différents secteurs d’activités, plusieurs langages EDI ont été conçus et mis en place. Ceci avant d’aboutir à une convergence vers le plus structuré mais aussi le plus polyvalent d’entre eux : le langage universel Edifact. La description de ce langage sera l’objet du chapitre suivant

- Amélioration

de

la

réponse

à

l’événement

(justesse,

précision,

qualité

Chapitre

IV

Le langage Edifact

L’EDI est conçu pour que l’ordinateur qui reçoit les données, puisse les « lire » et les traiter, sans intervention humaine supplémentaire.

Cela signifie que les données doivent apparaître dans un format codé plutôt que textuel.

Alors qu’un employé à l’entrée des commandes peut examiner deux demandes d’achat totalement différentes et d’en extraire l’information pertinente. Un ordinateur ne le peut pas. Ce dernier a de grosses possibilités en efficacité et précision.

Mais il ne peut pas reconnaître pour identique des informations semblables, dans des formats ou des positions différentes.

Il faut donc l’avertir, à l’avance, du type d’information qu’il va recevoir et du format sous lequel elle se présente.

L’information doit alors être transmise sous cette forme spécifique afin d’être lue et comprise par l’ordinateur qui la reçoit.

Les standards ou normes EDI fournissent la structure requise pour permettre aux ordinateurs de lire, comprendre et traiter les documents d’affaires.

Plusieurs langages ont été développés. Dans ce chapitre nous allons décrire le langage Edifact. Ensuite nous donnerons un aperçu sur d’autres langages.

IV.1 Le standard Edifact

United Nations Electronic Data Interchange For Administration, Commerce And Transport. Ce langage est destiné à être la norme mondiale en matière de l’EDI. L’Edifact se compose de deux niveaux : le niveau syntaxique et le niveau sémantique.

L’importance du niveau sémantique différencie Edifact des autres langages techniques.

Le niveau syntaxique permet d’organiser le discours grâce à des séparateurs, des groupements de données de messages, et par des enchaînements de messages en scénarios. Les éléments de service sont gérés à ce niveau (émetteur, destinataire, date et numéro des messages, références aux applications traitées), par des segments de services de la syntaxe.

Le langage Edifact se compose principalement de :

- d’un vocabulaire, le dictionnaire des données élémentaires appelé TDED (Trade Data Elements Directory - Norme ISO 7372).

-

9735).

d’une grammaire, les règles de syntaxe Edifact au niveau application (Norme ISO

IV.1.1 Le dictionnaire des données (TDED)

Chaque donnée élémentaire du TDED comprend :

- une désignation alphabétique et un indicatif numérique (TAG).

- une description sémantique.

- une note (observation supplémentaire).

- une référence qui renvoie à une autre section si la note ne suffit pas.

- des synonymes.

L’indicatif numérique est composé de 4 chiffres. Chaque groupe de mille correspond à une catégorie de données.

Alors que les données internationales occupent les 500 premiers nombres, ainsi on a la classification :

- Groupe 0 (0000-0499) :

- Groupe 1 (1000-1499) :

- Groupe 2 (2000-2499) :

- Groupe 3 (3000-3499) :

- Groupe 4 (4000-4499) :

- Groupe 5 (5000-5499) :

- Groupe 6 (6000-6499) :

- Groupe 7 (7000-7499) :

- Groupe 8 (8000-8499) :

- Groupe 9 (9000-9499) :

Données de service.

Documentation, références.

Dates , heures, intervalles, temps.

Parties, adresses, lieux, pays.

Clauses, conditions, termes, instructions.

Montant, frais, pourcentage.

Intitulés de mesures, qualités.

Marchandises et articles : description et intitulés.

Modes et moyens de transport, conteneurs.

Eléments de données de secteurs particuliers

( banques, douanes, etc…).

Les chiffres suivants indiquent :

- pour la série de 000 à 499 : les données internationales.

- pour la série de 500 à 799 : les données nationales.

- pour la série de 800 à 999 : les données sectorielles.

IV.1.2 Les données élémentaires du TDED

Ce dictionnaire comprend trois types de données :

- alphabétique représenté par le symbole a.

- numérique représenté par le symbole n.

- alphanumérique représenté par le symbole an.

Chaque donnée est soit :

composite : composé de plusieurs données ordonnées, son indicatif numérique commence par C.

Et les données qui constituent la donnée composite sont soit obligatoires (M :

Mandatory), soit facultatives (C : Conditionnal).

CC118

INFORMATION

Etat

Commentaires

PRIX UNITAIRE

5110

Prix unitaire

M

n

15

nature de la devise

5821

Code de base du prix unitaire

C

an

2

ex: CT contractuel

5284

Base du prix unitaire

C

n

9

ex : par millier

6410

Spécificateur de l’unité de mesure

C

an

3

ex : par paire

 

Tableau 1 : Exemple de donnée composite

 

Codée : on peut associer à une seule donnée élémentaire plusieurs codes, par

exemple la donnée élémentaire « Mode de paiement » possède une liste de codes

associés.

Qualifiantes : afin de diminuer le nombre de données à manipuler et d’enrichir la

précision sur les significations des données, on utilise les valeurs qualifiantes.

Les valeurs qualifiantes sont capitales car elles permettent de préciser l’exacte signification d’une donnée générique. Les valeurs qualifiantes sont enregistrées sous forme de code, et regroupées dans le Code Sets Directory.

IV.1.3 Les niveaux d’Edifact

Le langage Edifact se structure à l’aide de listes emboîtées les unes dans les autres. Le tableau suivant récapitule l’ensemble de ces niveaux d’emboîtement, du plus grand au plus petit :

Emboîtement

Nom du niveau

Se comporte comme

Edifact

Plus grand

Interchange

Dossier

Règles syntaxiques

 

Groupe fonctionnel

Intercalaire

Règles syntaxiques

 

Message

Message

Vocabulaire

 

Groupe de segment

Fiche

Règles syntaxiques

 

Segment

Information

Vocabulaire

 

Composite

Expression

Vocabulaire

 

Elément

Mot ou code

Vocabulaire

Plus petit

Alphabet

Alphabet

Règles syntaxiques

Tableau 2 : Les niveaux d’Edifact

Pour certains de ces niveaux, Edifact définit uniquement des règles syntaxiques. Tandis que pour d’autres, la norme définit une sémantique, éventuellement utilisée par les règles.

Par exemple la syntaxe du niveau « message » stipule que tout message commence par le segment UNH.

IV.1.4 Structure du segment Edifact

Le segment Edifact est un regroupement de données simples ou composites. Ce regroupement de données en segment est régi par les règles suivantes :

- Les données regroupées en des segments agencées en fonction des utilisateurs auxquels elles sont destinées.

- Le regroupement prend en compte les données qui sont produites, stockées et transmises en même temps.

- Le regroupement des données relatives aux même fonctions est obligatoire.

Ceci pour faciliter la tâche de l’utilisateur.

La structure d’un segment comporte :

alphabétiques.

Un intitulé du segment.

Une suite de données simples ou composites suivies de leur statut obligatoire (M) ou facultatif (C).

Il existe un type particulier de segments : les segments de contrôle. Ces derniers contiennent des informations tels que l’émetteur du message, la date de transmission.

Les segments de contrôle ont un TAG qui commence toujours par ‘‘UN’’. Le tableau ci dessous présente les segments de contrôle qui interviennent dans un accord d’interchange :

caractères

Une

étiquette

de

segment,

appelée

TAG

représentée

par

3

Intitulé du segment

TAG

Statut

Avis de chaîne de caractère de service

UNA

C

Segment d’en-tête de contrôle d’échange

UNB

M

Entête de groupe fonctionnel

UNG

C

Entête de message

UNH

M

Segment de délimitation du message

UNS

C

Segment de délimitation S du message

UNS

C

Fin de message

UNT

M

Fin de groupe fonctionnel

UNE

C

Fin d’Interchange

UNZ

M

Tableau3 :Les segments de service Edifact

IV.1.5 Structure du message Edifact

Le message Edifact est un ensemble de segments structurés sous forme arborescente. La lecture du message se fait par le parcours de l’arbre en profondeur de gauche à droite.

UNG ' Message Message Message Message UNE ' UNH ' Segment Segment Segment Segment UNT
UNG '
Message
Message
Message
Message
UNE '
UNH '
Segment
Segment
Segment
Segment
UNT '
EN TETE +
élément de donnée simple +
élément de donnée composite
'
Elément de donnée
Elément de donnée
Code
:
Valeur
Valeur
:
constitutive
constitutive
Valeur
Valeur
Figure 7 : Structure du message Edifact
La facture est le document le plus échangé entre les entreprises. Dans ce diagramme, on
La facture est le document le plus échangé entre les entreprises. Dans ce diagramme,
on présentera le message facture. Chaque segment est représenté par une case dont les
trois parties représentent le TAG du segment, son statut et le nombre de répétitions.
Message INVOIC simplifié
UNT
UNS IMA
M 1
M 1
M 1
ACI FIX
ALC
IXS
VAL
PRP CNT
C 10
C 5
C
1
C
10
C
2
M 1
C 5
ALI
TRI
ACA
FTX
RFF
C
5
C
5
C
5
C
5
C
1
Groupe de
C
10
C
25
segments

Figure 8 : Le diagramme simplifié du message Facture (Invoic)

IV.1.6 La syntaxe de codage

Le codage d’un message Edifact est réalisé en ASCII, à partir du diagramme. Les différents éléments d’un message sont délimités par des caractères.

En voici quelques-uns :

fin de segment

+

séparateur ou en-tête de segment

:

séparateur de données constitutives

?

caractère suspensif

Tableau4 : Délimiteurs Edifact

Pour l’exemple de la facture (du message Invoic) , nous présentons un extrait du codage :

UNA :+. ?’UNB+UNOA :1+5012345678901 :14+123456 :91+901111 :1236+REF01+ PASSW+INVOIC’UNH+INV001+INVOIC :90 :1 :UN’BGM+380+75-064-H-

227101+901111’NAD+SU+5013456000145 :14++ICI

POLYMERS+POBOX90 :WILTON+MIDDLESBOROUGH++T568

AND

CHEMICALS

IV.1.7 structure de l’interchange

L’organisation des messages est normalisée grâce à l’interchange Edifact. L’Edifact permet l’identification du destinataire logique de l’ensemble des messages en la « mettant sous enveloppe ». Cette enveloppe se différencie de celle de communication utilisée pour identifier le destinataire suivant la norme de communication.

Le début et la fin d’un groupe fonctionnel sont indiqués par deux segments de service. UNG et UNE. Le segment UNA indique des dérogations aux règles de syntaxe Edifact. Tous ces segments sont optionnels.

La figure suivante présente la forme d’une transmission en Interchange Edifact

Etablissement CONNEXION Fin INTERCHANGE 1 INTERCHANGE i INTERCHANGE n UNA ' UNB Groupe fonctionnel Groupe
Etablissement
CONNEXION
Fin
INTERCHANGE 1
INTERCHANGE i
INTERCHANGE n
UNA '
UNB
Groupe fonctionnel
Groupe fonctionnel
Groupe fonctionnel
UNZ '
UNG '
Message
Message
Message
Message
UNE '
UNA : Segment de service
UNG : Segment d'en tête de groupe fonctionnel
UNB : Segment d'Entête d'interchange
UNE : Segment de Fin de groupe fonctionnel
UNZ : Segment de Fin d'interchange
Figure 9 : Schéma hiérarchique d’une transmission en interchange Edifact

IV.2 Le langage Edifact et la sécurité

Le langage Edifact est considéré comme faible du point de vue de la sécurité. Dans les mises en œuvre actuelles, il est nécessaire d’adjoindre des éléments complémentaires pour résoudre les divers besoins de protection.

Cette situation est profondément modifiée par la dernière version de la syntaxe Edifact, la version 4. Si celle-ci assure une parfaite compatibilité ascendante avec les versions antérieures, elle propose également de nombreuses fonctionnalités pour répondre aux exigences en matière de sécurité d’un système de commerce électronique.

Deux solutions sont proposées pour résoudre les différents besoins de sécurité :

regrouper sous les termes de « sécurité jointe » et « sécurité disjointe »[LANGLOIS].

IV.2.1 La sécurité jointe

Le principe de la sécurité jointe est de transmettre les éléments de sécurité avec les données objets de cette sécurité. Pour mettre en œuvre ces procédures, il faut ajouter dans les messages Edifact des segments de sécurité en tête et en queue des données applicatives.

IV.2.2 La sécurité disjointe

Elle est utilisée pour envoyer les éléments de sécurité indépendamment des données objets de la sécurité. Ce besoin de sécurité peut être complémentaire de la sécurité jointe.

La sécurité disjointe est assurée au moyen du message AUTACK. Celui-ci permet d’envoyer en un seul message plusieurs éléments de sécurité correspondants à un ou plusieurs éléments Edifact. Il est aussi possible de sécuriser le message AUTACK lui- même.

La version 4 de la syntaxe Edifact favorise encore plus Internet et en général les réseaux moins sécurisés.

IV.3 Un Aperçu sur d’autres langages

Nous verrons successivement la norme ANSI X12, le langage SGML, le langage Galia, le langage Gencod, propre au secteur de la distribution. Et le langage CFONB, propre au réseau bancaire.

IV.3.1 ANSI X12

Le développement de cette norme a commencé en 1978, il est composé de :

- Un ensemble de standards de transactions.

- Un répertoire de données.

- Un répertoire de segments.

- Une norme de contrôle de transmission.

IV.3.2 SGML

Développé par les spécialistes de l’édition et de l’imprimerie en 1986, Standard Generalized Markup Language est un langage de balisage généralisé. Il permet de décrire un document comme un ensemble organisé.

SGML permet d’une part de décrire la structure d’un document, d’autre part de repérer dans ce document les différents éléments (chapitre, paragraphe, notes, titres,…).

IV.3.3 Galia

C’est le Groupement pour l’Amélioration des Liaisons dans l’Industrie Automobile, la norme s’appelle ODETTE. Elle utilise une partie de la norme X12 au niveau des répertoires de données.

IV.3.4 GENCOD

Gencod est une norme EDI assez répandue en France et destinée plus particulièrement au secteur de la distribution.

Le service « Alegro » proposé par les associations de promotion de Gencod. Il aide les entreprises du secteur à mettre en place un réseau EDI Gencod.

Ceci avec une complète intégration de la gestion à code barres utilisés par les acteurs de la grande distribution.

Aujourd’hui le réseau Gencod propose une migration progressive vers la norme Edifact.

IV.3.5 CFONB

Plutôt qu’un langage, CFONB est en faite une série de règles d’utilisation de formats de fichiers structurés. Cette structure est capable d’être traités par les systèmes d’informations des banques et par le réseau à valeurs bancaire.

Après avoir définir les concepts EDI et Edifact, nous présenterons dans le chapitre suivant le commerce électronique.

Chapitre

V

Le Commerce Electronique

Notre projet est directement lié au concept du commerce électronique interentreprises. Ce chapitre est consacré à la présentation de ce concept. Après une vue d’ensemble du E-Commerce au niveau mondial, nous présentons le commerce électronique au Maroc. Nous effectuons une comparaison entre le commerce traditionnel et le commerce électronique, avant d’enchaîner avec l’infrastructure nécessaire pour cette nouvelle technologie. Nous terminons ce chapitre par l’avenir promis par le concept en question.

V.1 Vue d’ensemble

Le commerce électronique se définit essentiellement comme processus de vente et d’achat de produits et de services sur l’Internet, mais il se caractérise par bien d’autres aspects. A ses débuts, il englobe la gestion de transactions d’achats et de transferts de fonds sur des réseaux d’ordinateurs. Il s’étend désormais à la vente et à l’achat de nouveaux produits tel que l’information électronique.

Le commerce électronique interentreprises ne cesse de croître en partie grâce à l’Internet. De petites entreprises peuvent désormais traiter on-line au même titre que les plus grandes. Quelle que soit leur taille, les entreprises peuvent tirer parti de l’Internet pour réduire les coûts de gestion de commerce électronique. Et ceci en remplaçant d’autres réseaux par l’Internet.

Le commerce électronique ne se réduit pas aux transactions d’achat et de vente de biens ou de services qui génèrent directement un revenu. Ce système englobe d’autres formes de transactions qui permettent d’assurer des revenus de manière indirecte. Nous citons la création de besoins suscitant une demande se rapportant à un bien ou un service, ou aussi la fourniture de support de vente. Ajoutons à ceci le fait d’assurer un service après vente ou encore, faciliter les échanges entre entreprises partenaires.

V.2 Le Commerce électronique au Maroc

Les PME/PMI marocaines sont peu utilisatrices de technologies de l'information et des communications alors que celles-ci constituent un facteur clé de leur compétitivité.

L'utilisation de l’Internet a un impact sur le marché national. Elle garantit :

- une amélioration de la qualité des produits et services offerts.

- de nouvelles opportunités d’affaires.

- une large présence des produits et services.

- la réduction des coûts de revient.

- la génération d’emplois dans les domaines du développement de logiciels, de contenu et de services.

- une rationalisation des flux de production.

- une meilleure gestion financière.

En outre, l’efficacité et la pertinence du recours à l’Internet, deviennent des éléments discriminants dans la concurrence. Cela implique que les entreprises en fassent une priorité stratégique.

Le réseau public marocain de télécommunications est entièrement numérisé et offre déjà la quasi-totalité des services de télécommunications de base et à valeur ajoutée. Donc on peut dire que l’infrastructure du commerce électronique existe au Maroc, et il suffit d’implémenter les solutions.

L’état marocain s’est impliqué dans le domaine du commerce électronique. En effet, le Maroc est conscient des opportunités offertes par le commerce électronique pour le développement des entreprises nationales. C’est pourquoi il a engagé la réflexion sur les instruments nécessaires au développement de cette nouvelle forme de commerce. Il a institué à cet effet un comité Interministériel pour le Développement et la promotion du Commerce Electronique[CIDPCE].

V.3 Commerce traditionnel et commerce électronique

Les échanges traditionnels sont généralement réalisés par courrier, télécopie ou téléphone. Les documents transmis ne sont pas normalisés et demandent de la part des opérateurs un effort d’interprétation avant de pouvoir être pris en charge par le système d’information de l’entreprise.

Dans le domaine du commerce électronique, les échanges sont entièrement dématérialisés, et la grande partie des traitements l’est aussi.

En comparant le cycle de vente d’une transaction traditionnelle à celui d’une transaction électronique (voir tableau 5), on peut noter bien des similitudes. Seules les méthodes d’obtention et de transmission de l’information varient. Dans une transaction traditionnelle, de multiples vecteurs de communications différents sont indispensables. Cette diversité a pour conséquence de compliquer la coordination des opérations et d’allonger considérablement le temps de traitement d’une commande. En revanche, dans le cas d’une transaction électronique, l’information est numérisée de bout en bout

et il n’existe qu’un seul vecteur de communication. Seules les applications de transfert et de traitement des données différent[LANGLOIS].

Etape du cycle de vente

Commerce traditionnel (multiples vecteurs de communication)

Commerce électronique (unique vecteur de communication)

 
 

Recherche d’informations sur un produit

Magazines, représentants, catalogues

Pages Web

Commande de produit

Lettres, formulaires

E-mail

Confirmation de commande

Lettres, formulaires

E-mail

Vérification de prix

Catalogue

Catalogue en ligne

Vérification de disponibilité

Téléphone, fax et confirmation de prix

 

Passation de la commande

Formulaire imprimé

E-mail, pages Web

Envoi de la commande(client), réception de la commande(fournisseur)

Fax, courrier

E-mail, EDI

Spécification d’une commande prioritaire

 

Base de données en ligne

Vérification de disponibilité au dépôt

Formulaire imprimé, téléphone, fax

Base de données en ligne, pages Web

Planification de la livraison

Formulaire imprimé

E-mail, base de données en ligne

Génération de la facture

Formulaire imprimé

Base de données en ligne

Réception du produit

Livreur

 

Confirmation de réception

Formulaire imprimé

E-mail

Envoi de facture (fournisseur); réception de facture (client)

Courrier

E-mail, EDI

Echéance de paiement

Formulaire imprimé

EDI, base de données en ligne

Envoi règlement (client) ; réception règlement (fournisseur)

Courrier

EDI, EFT

Tableau 5 : Nouvelle et ancienne méthode d’achat d’un produit

V.4 L’infrastructure du commerce électronique

La mise en place d’un système du commerce électronique requiert une infrastructure matérielle et logiciel bien définie. Elle est fondée sur le principe du Client/serveur. La communication réseau est à la base du commerce électronique, et le réseau Internet est le support qui prend plus d’ampleur.

L’infrastructure réseau englobe tous les moyens de communication mis en œuvre pour transmettre l’information. Elle réunit toutes les technologies Internet, à savoir la pile de protocoles TCP/IP.

Le middleware est une réponse aux besoins de toute entreprise possédant une informatique interne et qu’elle veut continuer à développer sans rupture de processus[LANGLOIS]. Les nouveaux logiciels doivent échanger des informations avec les logiciels existants. La structure de communication inter applications revêt une importance primordiale. Elle conditionne l’ajout d’un nouveau logiciel sans rupture du plan de développement informatique. Les extensions et les développements peuvent être envisagés pour des applications externes. C’est en ce sens que les techniques du middleware peuvent être utilisées comme des outils du commerce électronique.

Le commerce électronique nécessite un certain degré de sécurité pour protéger les différentes informations échangées entre les entreprises. Pour éviter toute fraude et assurer en plus un paiement sécurisé, des protocoles de sécurité ont été mis en place (SSL, SET,…).

V.5 L’avenir avec le commerce électronique

Le développement des échanges électroniques est au cœur de la dynamique économique des années à venir. Il entraîne des changements profonds dans l’organisation et le fonctionnement des entreprises, dans leurs rapports avec les clients et dans leur comportement sur le marché mondial. L’efficacité et la pertinence du recours aux technologies de l’information et de la communication deviennent des éléments discriminants dans la concurrence. Cela implique que les entreprises et les Administrations, ensemble, en fassent une priorité stratégique.

Partie III

Etude de la solution E-Commerce

Cette partie porte sur l’étude de la solution E-Commerce. Nous détaillons dans le sixième chapitre l’architecture générale de la solution. Le septième chapitre est une étude comparative des différents outils existant de mise en œuvre de la solution. Quant au dernier chapitre, il porte sur les composants de la solution retenue.

Chapitre

VI

Architecture de la solution

La solution proposée peut être présentée de plusieurs points de vue. Une présentation en schéma global donne une idée générale sur la solution et ses fonctionnalités, et exprime les critères de choix de l’outil de développement. Ensuite nous présentons le scénario du commerce électronique entre entreprises. Les fonctionnalités sont présentées avec plus de détail dans un schéma Front Office et Back Office.

VI.1 Architecture générale

Aux exigences matérielles de la mise en place d’une solution de commerce électronique, s’ajoutent les exigences logicielles. L’architecture Client/Serveur est à la base de l’utilisation des réseaux informatiques. L’importance des données traitées dans le domaine du E-Commerce impose l’utilisation des bases de données. Notre solution fait appel à la traduction Edifact, ce qui implique l’intégration d’un traducteur dans la pile des logiciels utilisés. L’utilisation du réseau Internet correspond à l’utilisation de la pile de protocoles TCP/IP. Ces données esquissent les composants principaux d’une solution E-Commerce.

La figure suivante donne l’architecture générale des échanges informatisés sur plate- forme Internet. Aussi présente-t-elle les principaux composants mise en jeu pour la réalisation de la solution.

Système Base d’information Serveur documentaire Web ODBC/JDBC Base de Site Marchand connaissances Traducteur
Système
Base
d’information
Serveur
documentaire
Web
ODBC/JDBC
Base de
Site Marchand
connaissances
Traducteur Edifact
Internet
Navigateur
TCP/IP
Traducteur Edifact
Système d’information
Partenaire (Client, Fournisseur, transitaire, banque)
Figure 10 : Architecture générale pour l’échange informatisé sur Internet

VI.2 Scénario B to B

L’environnement des échanges commerciaux pour l’entreprise fait intervenir tous les partenaires de l’entreprise, fournisseurs, clients ou aussi transitaires. Nous pouvons aussi considérer la participation de la banque dans ces échanges.

Entreprise / Client

Les échanges entre l’entreprise et ses clients concernent les devis, les bons de commande, les bons de livraison et les factures. Le schéma suivant illustre ce scénario.

Entreprise Client Devis Bon de commande Bon de livraison Facture Figure 11 : Scénario Entreprise/Client
Entreprise
Client
Devis
Bon de commande
Bon de livraison
Facture
Figure 11 : Scénario Entreprise/Client

Le scénario d’échanges Entreprise/Fournisseur est le même que le scénario précédent, le fournisseur prend la place de l’entreprise, et cette dernière prend la place du client.

Entreprise/Transitaire

Les messages échangés entre l’entreprise et le transitaire sont : la réservation, la confirmation de la réservation, l’ordre de transport, statut de transport et l’avis d’arrivée envoyé par le transitaire au client.

Entreprise Transitaire Client Réservation Confirmation Ordre de transport Statut du transport Avis d’arrivée
Entreprise
Transitaire
Client
Réservation
Confirmation
Ordre de transport
Statut du transport
Avis d’arrivée
Figure 12 : Scénario Entreprise/Transitaire

Transaction bancaire

Pour ce qui est de l’échange avec la banque, toutes les transactions ont le même
Pour ce qui est de l’échange avec la banque, toutes les transactions ont le même
principe. On prend par exemple l’implication de l’entreprise et le client dans une
transaction. Les documents échangés sont : ordre de paiement, état de traitement
bancaire, avis de paiement, avis de débit, avis de crédit et l’extrait de compte.
Entreprise
Banque de
Banque du
Client
l’entreprise
client
Ordre de paiement
Etat du traitement
Avis de paiement
Communication
inter-bancaire
Avis de débit
Avis de crédit
Extrait de compte
Extrait de compte

Figure 13 : Scénario d’une transaction bancaire

VI.3 Front Office et Back Office

Le système E-Commerce peut être défini comme composé de deux parties. La première partie, dite Front Office, groupe les interfaces et les champs de saisie des données. La deuxième partie, dite Back Office, assemble les différents traitements sur les documents échangés et la validation des données saisies.

VI.3.1 Front Office

Le Front Office comprend les différentes interfaces utilisateurs. L’environnement commerce électronique que nous avons conçu est présenté aux utilisateurs sous forme de site Web. Il est divisé en deux parties :

- Une première partie pour les visiteurs non identifiés.

- Une seconde partie pour les clients identifiés. Cette partie donne plus de priorités aux clients par rapport aux autres visiteurs.

Le site est développé sur les axes suivants :

- Le catalogue en ligne, pour la présentation des produits et services à vendre.

- Formulaire d’inscription des clients.

- Formulaire d’identification des clients.

- Le formulaire des besoins, pour aider les clients qui ont des besoins spécifiques et qui n’arrivent pas à faire un choix précis (Commande guidée).

- Le formulaire de commande.

- L’interface de paiement (relation avec la banque).

VI.3.2 Back Office

Le Back Office contient les traitements des données correspondant aux interfaces du Front Office présenté ci-dessus. A savoir :

- Mise à jour et maintenance du catalogue.

- Vérification des comptes et mots de passe.

- Base documentaire et base de connaissance.

- Prise en compte des commandes.

- Génération et validation des factures.

- Mise à jour du système d’information.

- Traitement du paiement.

La figure 14 résume les composants du Front Office et du Back Office.

L’architecture générale est ainsi définie. Nous signalons que les exigences de sécurité vont être prises en charge dans tous les traitements les nécessitant. Dans le chapitre suivant nous exposons l’étude comparative effectuée pour le choix de l’outil de développement de la solution.

Front Office

Front Office Client Back Office Entreprise Banque Base de données catalogue Mise à jour du catalogue
Client
Client
Back Office Entreprise Banque Base de données catalogue Mise à jour du catalogue Attribution de
Back Office
Entreprise
Banque
Base de données catalogue
Mise à jour du catalogue
Attribution de comptes
Alimentation de la base de
données Client
Validation de comptes
Vérification du compte et
mot de passe
Base de connaissance
Base documentaire
Recherche des solutions à
partir de la base
documentaire en se basant
sur la base de connaissance
Traitement de la commande
Prise en compte de la
commande
Facture
Génération et traduction
Edifact de la facture
Emission de la facture
Paiement
Emission de
l’état de :
- traitement
- avis de
paiement
- avis de
débit

Catalogue en ligne

Présentation des produits et services à vendre

en ligne Présentation des produits et services à vendre Inscription Saisie des information sur le client

Inscription

Saisie des information sur le client

à vendre Inscription Saisie des information sur le client Identification Saisie du compte et mot de

Identification

Saisie du compte et mot de passe

le client Identification Saisie du compte et mot de passe Commande guidée Spécification des besoins du

Commande guidée

Spécification des besoins du client

passe Commande guidée Spécification des besoins du client Commande Sélection des besoins et validation de la

Commande

Sélection des besoins et validation de la commande

Commande Sélection des besoins et validation de la commande Facture Réception de la facture Paiement Ordre

Facture

Réception de la facture

Commande Sélection des besoins et validation de la commande Facture Réception de la facture Paiement Ordre

Paiement

Ordre de paiement

Figure 14 : Les éléments du Front Office et du Back Office

Chapitre

VII

Etude comparative des plates-formes et choix de l’outil du travail

Pour réaliser un site de commerce électronique, une entreprise doit choisir les produits les mieux adoptés à son activité et à ses besoins.

Il existe un grand nombre de solutions sur le marché. Chacune assurant une ou plusieurs des fonctions nécessaires à la vente en ligne : serveur Web, création de catalogue, moteur de recherche, gestion de panier virtuel, calcul de TVA et de paiement sécurisé et interface avec des solutions externes.

Avant de se lancer dans le développement d’un site commercial, une étude comparative des différentes solutions possibles est cruciale.

Nous allons présenter les logiciels existants sur le marché, puis établirons une comparaison entre deux produits : WebSphere Studio d’IBM et Commerce Server de Microsoft.

VII.1 Les logiciels sur le marché

Sur le marché actuel, il existe une variété des solutions logiciels. Nous avons repris ci- dessous sous forme de tableau, l'offre logiciel sur le marché, sous les rubriques suivantes : nom du produit, éditeur, plate-forme, brève description.

Produit

Editeur

Plate-forme

Description

e-commerce 2.0

Ubiquis

NT

e-commerce 2.0 permet la création automatisée de sites commerciaux, une synchronisation automatique entre les données du site web et le système de gestion de l’entreprise, interface avec les solutions de paiement sécurisée

EfrontOffice 9.0

Clarify

NT,

La version eFrontOffice 9.0 s’appuie sur les modules de gestion client jusqu’alors proposés(service client, gestion des ventes et marketing). du côté client, eOrder gère les commandes en ligne et eConfigurator, un outil de configuration produit.

UNIX,

ORACLE,

SUN

SOLARIS

 

Enfinity

Intershop

NT, SUN,

Serveur marchand, Enfinity, le moteur de transaction gère les flux entre les modules intelligent merchandiser(commerce intelligent), Remote XML interface(gestion XML), pipeline orchestrator et Cartridge API ( développement sur mesure)

HP

i.Sell 2.0

Informix

NT,UNIX

L’éditeur met l’accent sur les fonctionnalités liées à la personnalisation du contenu. i.Sell travaille à base de deux composants : i.Sell Merchandiser qui permet de réaliser une boutique en ligne, back office compris(gestion de commandes, catalogue électronique, gestion des prix, des promotions, des systèmes de fidélistion, etc.) et i.Sell Personnalizer vise à positionner les logiciels d’informix face à la concurrence

IStore 3i

Oracle

Sun

L’outil store crée les profils clients, charge la base de produits, gère les promotions et génère des rapports d’audiences. Le logiciel fournit un historique des commandes en ligne et dispose d’un système de messagerie intégré afin d’assurer la communication client/commerçant. IStore 3i s’adresse aux entreprises qui souhaitent un délai de réponse au marché le plus court possible. Facturé plusieurs centaines de milliers de francs selon la puissance du serveur

Solaris,

HP-UX,

Compaq

Trusted6

4,UNIX,

AIX, NT

Commerce

Microsoft

NT

L’outil permet de créer, gérer, administrer un site commercial, facile à utiliser.

Server

Websphere

IBM

NT, AIX,

Serveur marchant, nouvelle version de Net.commerce, le logiciel gère la globalité des transactions du site. La solution bénéficie désormais des capacités d’ouverture de Websphere 3.0 vers les gros systèmes et vers XML.la version inclut aussi la technologie Blaze advisor pour la personnalisation.

Commerce suite

Sun

4.1

Solaris

Tableau 6 : Différentes plates-formes E-Commerce sur le marché

Nous choisissons parmi les différents produits, deux plates-formes qui correspondent à deux grands éditeurs mondiaux, à savoir Commerce Server de Microsoft, et WebSphere d’IBM. Nous effectuerons une comparaison entre ces deux solutions.

Cette comparaison s’établit sur trois axes, à savoir la plate-forme matérielle et logicielle requise, les composants, et les fonctionnalités offertes par les deux produits.

VII.2 Plate-forme

VII.2.1 Matériels

Avant toute installation de Commerce Server ou bien de WebSphere, notre machine doit avoir les caractéristiques bien précises que nous avons récapituler dans le tableau suivant :

 

Commerce Server

WebSphere

RAM

96 Mo minimum et 128 recommandé

512 Mo

Processeur

100MHz

300MHz

Espace disque

1Go

500Mo

Ecran et Résolution

_

256 couleurs et 800*600

Tableau 7 : Comparaison : Configuration matérielle requise

VII.2.2 Logiciels

Commerce Server sera installé sous l’environnement de Windows NT Server avec option Pack ( le système d’exploitation réseaux de Microsoft ) où seront exécutés les processus :

Internet Information Server ( IIS ) : le serveur Web qui va publier le site marchant.

Microsoft SQL Server : le SGBD relationnel qui va gérer la base de données centrale.

Front Page.

De sa part, l’utilisateur de notre système (client ) doit avoir un navigateur Internet ( tel que Internet explorer ) et sa machine doit être connectée à l’Internet pour pouvoir entrer en interaction avec le site pour visiter et lancer les commandes.

La figure suivante récapitule la configuration logicielle requise pour l’installation de Commerce Server.

Navigateur Navigateur client opérateur du site de commerce Serveur Windows NT IIS 4.0 Active Server
Navigateur
Navigateur
client
opérateur du
site de
commerce
Serveur Windows NT
IIS 4.0
Active Server Pages
Commerce Server
Base de données SQL
Server ou autre base
de données compatible
ODBC
Figure 15 : Architecture technique requise par Commerce Server

Des considérations doivent être prises en compte lors de l’installation de Commerce Server. La procédure d’installation de cet outil est présentée en annexe.

Dans le cas de WebSphere, l’un de systèmes d’exploitation suivants devrait être installé : Microsoft Windows NT 4.0 avec service Pack 4, Microsoft Windows x, ou

AS/400.

En plus de Microsoft Internet Explorer version 4.0 ou supérieure et si PageDetailer est installé, on doit prendre Microsoft Internet Explorer 5.0.

les travaux relatifs à WebSphere

Application Server.

Le

sous-système

WebSphere

Studio

contient

Serveur d'applications

Un serveur d'applications WebSphere fournit l'environnement d'exécution pour les composants Java côté serveur (tels que les servlets, les fichiers JSP et les beans enterprise).

Module d'extension

Le module d’extension du serveur d'applications fournit une interface avec le serveur Web. Cette interface sert à gérer les requêtes client portant sur les ressources côté serveur et pour les acheminer vers le serveur d'applications en vue de leur traitement.

Un serveur d'applications contient les composants architecturaux suivants :

Moteur de servlet

Le moteur de servlet s'exécute à l'intérieur du serveur d'applications et gère les requêtes relatives aux servlets, aux fichiers JavaServer Pages (JSP) et aux applications Web qui les contiennent.

Conteneur d'EJB

Le serveur d'applications interagit avec le conteneur d'EJB pour autoriser l'accès aux beans enterprise se trouvant dans le conteneur d'EJB.

Serveur Web

Le serveur Web reçoit des requêtes relatives aux composants côté serveur (tels que les servlets, les fichiers JSP et les beans enterprise) et il les transmet à WebSphere Application Server via une interface appelée le module d'extension.

WebSphere Application Server traite les requêtes et envoie les réponses au client via le serveur Web.

Le composant de logiciel suivant s'exécute sur un poste de travail client :

Console d'administration

La console d'administration est une application Java autonome qui s'exécute sur un poste de travail. La console se connecte au serveur d'administration WebSphere et présente une interface graphique qui permet de configurer et de gérer les ressources WebSphere.

La figure suivante représente l’architecture technique de WebSphere.

Figure 16 . Architecture technique de WebSphere. VII.3 Composants VII.3.1 Composants de Commerce Server Commerce

Figure 16. Architecture technique de WebSphere.

VII.3 Composants

VII.3.1 Composants de Commerce Server

Commerce Server est une plate-forme complète de création de sites commerciaux virtuels. Ce produit est composé des éléments suivants :

outils ;

objets COM (Component Object Model) orientés commerce ;

Microsoft Wallet.

Chacun de ces éléments est décrit dans les sections qui suivent.

VII.3.1.1 Outils

Grâce aux nombreux outils de Commerce Server 3.0, la création de sites Commerce Server personnalisés est encore plus facile qu'auparavant.

de

l'infrastructure nécessaire au nouveau site Commerce Server.

Assistant Créateur de site : L'objectif de cet Assistant est de simplifier la création d'un site commercial à l'aide d'une interface conviviale afin d'obtenir rapidement un site Commerce Server totalement fonctionnel.

Cet

Assistant

Fondations

de

site :

Assistant

facilite

la

configuration

Pipeline Editor : Pipeline Editor sert à personnaliser le pipeline d'un site afin d'assurer l'intégration complète dans les anciens systèmes ou dans les autres systèmes existants de l'entreprise

Outil de gestion des certificats : permet de créer une demande de certificat et de gérer l'échange des certificats entre les partenaires commerciaux.

Gestionnaire de liaisons de site de commerce : destiné aux développeurs amenés à transformer un site Commerce Server existant en fichier exécutable auto- extractible.

Outils d'administration : L'administrateur du serveur dispose de trois interfaces d'administration suivantes : le composant logiciel enfichable Commerce Server pour Microsoft Management Console (MMC), les pages Commerce de Commerce Server WebAdmin (Web-based Administration) ou l'interface de ligne de commande Commerce Server.

VII.3.1.2 Objets COM de Commerce Server

Les

grandes

catégories :

Composants utilitaires : Ils permettent de gérer les interactions entre les fichiers

.asp et les données figurant dans la base de données du site, d'effectuer des conversions et des validations de types de données, de gérer les messages d'erreur, de faciliter les tâches d'administration, de stocker les informations issues des formulaires de

commande pour la session en cours, etc.

Composants de pipeline de traitement des commandes (OPP, Order

Processing Pipeline) : Ces composants sont utilisés pour gérer les données liées à une

commande par l'intermédiaire des différentes étapes du processus de traitement des commandes.

Commerce Server 3.0 fournit plusieurs pipelines traités, chacun étant associé à une fonction précise tel que Le pipeline de vérification du bon de commande et le pipeline d'achat.

Composants de pipeline d'échange commercial (CIP, Commerce Interchange

Pipeline) : Ces composants facilitent l'échange d'objets de données d'entreprise (tels que les bons de commande, les reçus, les bons de livraison, etc.) entre les partenaires commerciaux.

composants

de

Commerce

Server

peuvent

être

regroupés

en

trois

VII.3.1.3 Microsoft Wallet

Microsoft Wallet permet aux utilisateurs de stocker leurs informations d'adresse et de paiement en toute sécurité sur leur ordinateur.

VII.3.2 Composants de WebSphere Studio

WebSphere se compose d’un plan de travail et d’un certain nombre d’assistants, ainsi que de produits annexes de développement pour le Web.

Plan de travail Studio : le plan de travail aide l’utilisateur à gérer et tenir à jour les application et les fonctions de site Web.

JavaBean, base de données et assistants SQL : Ces assistants permettent

d’ajouter le plus rapidement possible un contenu dynamique aux pages Web créées. Ils permettent de récupérer et de mettre à jour les informations dans les bases de données communes et d’utiliser des JavaBeans côté serveur. Ces fonctions permettent de tout faire, d’une simple consultation de table aux applications libre-service complexes.

Les assistants guident l’utilisateur, étape par étape, et génèrent du côté de servlet évolué.

Assistant JAR : cet assistant convertit une classe Java en JavaBean standard. Il

est possible d’utiliser le fichier JAR résultant dans l’assistant JavaBean ou l’ouvrir avec AppletDesigner pour l’ajouter à une applet.

Assistant Importation : permet la migration de sites Web et l’utilisation de ces

ressources existantes comme base de départ. L’Assistant Importation permet de copier rapidement des fichiers de sites Web existants dans un projet WebSphere Studio à partir de leur lieu de publication. L’assistant invite l’utilisateur à lui fournir les renseignements dont il a besoin, et grâce aux requêtes FTP ou HTTP, il copie le site fichier par fichier.

Page Designer, avec WebArt Designer et AnimatedGif Designer : Page

Designer est un éditeur HTML, présentant des fonctions avancées. Il permet de concevoir (mise en forme et contenu ) rapidement des pages Web dynamiques et des balises Java Server Pages ( JSP ). Il offre la possibilité de passer du mode Visuel au mode textuel et previsualiser les pages générées pour voir leur apparence.

PageDesigner comprend sa propre bibliothèque de graphique réutilisable et deux programmes graphiques permettant la création, l’édition et l’animation de fichiers d’image. Grâce à cela l’utilisateur peut faire en sorte que les sites Web aient l’impact visuel désiré.

Applet designer : il répond aux besoins de l’utilisateur lorsque celui-ci veut

créer rapidement une applet pour son site Web. Cet outil de création d’applications multimédia permet d’associer rapidement des JavaBeans et de constituer ainsi de nouvelles applets.

VII.4 Fonctionnalités

VII.4.1 Fonctionnalités de Commerce Server

Grâce à ses composantes, Commerce Server permet de :

Créer un site

L'Assistant Créateur de site permet de générer un site commercial totalement fonctionnel en toute simplicité. Selon les options qu’on adopte, l'Assistant crée tous les fichiers Active Server Pages (.asp). Les sites créés par l'Assistant peuvent être modifiés à l'aide de Microsoft Visual InterDev. Ces sites sont compatibles Microsoft Wallet pour l'inscription et l'achat.

Le schéma des sites Commerce Server est indépendant. On peut donc utiliser une base de données sans avoir à en modifier la structure. On peut également utiliser l'Assistant afin de générer un schéma complet de base de données. Dans un cas comme dans l'autre, on peut agencer les données de la façon qui semble la plus adaptée aux produits et à l’entreprise. Le site obtenu à l'aide de l'Assistant Créateur de site permet de présenter un catalogue dynamique des produits et d'accepter les commandes tout en s'intégrant dans les systèmes existants de l’entreprise.

Personnaliser le site

On peut créer un site Commerce Server rapidement à l'aide de l'Assistant. Aussi peut- on exploiter les nombreuses possibilités de développement de Commerce Server afin d'adopter le site à ses besoins.

Gérer le site

Parallèlement à la conception du site, l'Assistant Créateur de site génère un jeu de pages Web utilisées par l'opérateur du site afin d'effectuer, à distance, certaines tâches de gestion. Les tâches de gestion peuvent consister en l'ajout et la suppression de produits, la modification de la structure d'un service, la réalisation de ventes ou de promotions, la vérification des commandes. Les modifications sont automatiquement répercutées sur les pages du site sans qu'il soit nécessaire de modifier les fichiers ASP. L'accès à ces pages de gestion est limité à l'opérateur du site et aux comptes utilisateurs Microsoft Windows NT qu'il a habilités.

Administrer le serveur

Commerce Server comprend plusieurs outils d'administration, en local ou à distance, de l'ordinateur serveur sur lequel sont installés les sites Commerce Server. Ces outils permettent à l'administrateur du serveur d'ajouter, de supprimer, d'ouvrir et de fermer les sites. Ils permettent en plus de créer des sites et de modifier les propriétés des sites existants.

VII.4.2 Fonctionnalités de WebSphere

De sa part, et grâce à ses composantes, WebSphere studio assure :

La création des applications Web pour différentes unités entièrement basées sur

Java.

L’accès aux bases de données et la production des fonctions de programmation.

La sécurisation du site. En effet WebSphere Studio contient des options de

sécurité permettant de contrôler l’accès aux divers utilisateurs du système.

WebSphere Studio permet de recueillir des informations sur le client et sur le paiement pour les utiliser plus tard sur ces commandes.

Le tableau 8 résume les fonctionnalités offertes par les deux produits et associe à chaque service l'outil qui l'assure.

D’après cette étude, il apparaît clairement que Commerce Server contient plus de fonctionnalités et des composants pour le développement de solution B to B. Le pipeline de traitement de commandes et le pipeline d’échange commercial sont les principaux composants pour la mise en œuvre de telle solution.

Les pipelines de traitement de commandes et d’échange commercial sont présentés dans le chapitre suivant avec le pipeline Editor.

 

Commerce Server

WebSphere

Création du site

Assistant créateur de site

PageDesigner

Accès aux Bases de données

Composants utilitaires

Bases de données et Assistants SQL

Administration du site

Microsoft Management Console MMC

Plan de travail Studio

WebAdmin

Interface de ligne de commande Commerce Server

Sécurisation du site

Microsoft Wallet

Options de sécurité

Traitement des commandes

Pipeline de traitement des commandes

Non existant

Possibilité d'intégration des anciens systèmes

Pipeline Editor

Non existant

Gestion des échanges entre partenaires

Pipeline d'échange commercial

Non existant

Tableau 8 : Les fonctionnalités offertes par Commerce Server et WebSphere

Chapitre

VIII

Composants de la solution choisie

Commerce Server fournit les outils et les fonctionnalités nécessaires aux sites de commerce interentreprises. Parmi ses fonctionnalités nous citons : la prise en charge des bons de commande, des procédures d'approbation des commandes et de l'échange sécurisé des informations (commandes et bons de livraison, par exemple) entre les partenaires commerciaux. Dans ce chapitre nous présentons les pipelines mis en jeu dans le développement d’une solution B to B.

VIII.1 Les composants de Commerce Server

Comme nous l’avons signalé au chapitre précédent, Microsoft Commerce Sever est composé essentiellement de trois composants (Objets COM) :

Composants utilitaires.

Composants de pipeline de traitement des commandes (OPP, Order Processing

Pipeline).

Composants

Pipeline).

Interchange

de

pipeline

d'échange

commercial

(CIP,

Commerce

Le schéma suivant interprète ces composants et leurs fonctionnalités.

Fichier .asp Utilitaires Base de données du site OPP prix, taxe, Commande Commande expédition, stocks
Fichier .asp
Utilitaires
Base de
données
du site
OPP
prix, taxe,
Commande
Commande
expédition, stocks
brute
traitée
CIP
mappage, signature,
Partenaire
Entreprise
cryptage, transport,
audit
Commerce Server
Figure 17 : Les composants de Commerce Server

Le pipeline de Commerce Server est une infrastructure logicielle qui relie un ou plusieurs composant(s) et les exécute successivement sur un objet OrderForm ou Dictionary. Commerce Server 3.0 utilise cette infrastructure pour mettre en œuvre deux modèles de pipeline : le pipeline de traitement des commandes (OPP, Order Processing Pipeline) et le pipeline d'échange commercial (CIP, Commerce Interchange Pipeline).

VIII.1.1 Pipelines de traitement des commandes (Pipelines interentreprises)

Commerce Server 3.0 comprend cinq types de pipeline de traitement des commandes de base. Ils sont utilisés pour mettre en œuvre les sites de commerce de détail et les sites de commerce interentreprises.

Pipelines de détail

Pipeline de produit

Pipeline de vérification du bon de commande

Pipeline d'achat

Pipelines interentreprises

Pipeline de planification d'achats d'entreprise

Pipeline d'envoi d'achats d'entreprise

Nous nous contentons à la présentation des pipelines interentreprises, vue qu’ils sont les éléments qui opèrent dans le cadre du commerce B to B. Les pipelines de traitement des commandes interentreprises sont utilisés dans des sites de commerce destinés à la création et la transmission d'ordres de commande entre entreprises. Ces pipelines sont exécutés à divers moments du processus d'achat :

Planification d'achats d'entreprise (CorpPurchasePlan.pct). Exécute des

composants du pipeline de traitement des commandes qui calculent le total du bon de commande, y compris les remises promotionnelles, les taxes, et les divers frais.

Envoi d'achats d'entreprise (CorpPurchaseSubmit.pct). Exécute des

composants du pipeline de traitement des commandes qui valident la demande d'achat transmise par l'ordre d'achat. Ces composants transfèrent l'ordre d'achat au vendeur et

inscrivent une commande dans l'espace de stockage d'une base de données.

VIII.1.1.1 Pipeline de planification d'achats d'entreprise

Le pipeline de planification d'achats d'entreprise exécute des composants du pipeline de traitement des commandes qui calculent le montant total de la commande. Le montant comprend l'ensemble des remises promotionnelles, les taxes, les frais d'expédition et les frais de manutention.

Le pipeline de planification d'achats d'entreprise comprend 14 étapes.

1. Informations sur l'article de la demande.

2. Informations sur le fournisseur.

3. Informations sur l'acheteur.

4. Initialisation de la demande.

5. Vérification de la demande.

6. Prix de l'article de la demande.

7. Ajustement du prix de l'article de la demande.

8. Ajustement du prix de la demande.

9. Calcul du sous-total de la demande.

10. Expédition.

11. Manutention.

12. Calcul des taxes.

13. Calcul du total de la demande.

VIII.1.1.2 Pipeline d'envoi d'achats d'entreprise

Le pipeline d'envoi d'achats d'entreprise comprend deux étapes. Celles-ci exécutent des composants qui valident la demande d'achat transmise par l'ordre d'achat. Aussi transfèrentelles l'ordre d'achat au vendeur et inscrivent une commande dans l'espace de stockage de base de données.

Le pipeline d'envoi d'achats d'entreprise peut être exécuté lorsque un objet OrderForm est exécuté et une confirmation de la volonté du client de finaliser l'achat est obtenue.

Du fait que les composants de ce pipeline écrivent dans une base de données, le pipeline d'envoi d'achats d'entreprise est souvent un pipeline traité.

Le pipeline d'envoi d'achats d'entreprise comprend les étapes suivantes :

a. Etape de validation de l'ordre d'achat

Cette étape est utilisée pour vérifier la validité de l'ordre d'achat.

Commerce Server ne comprend aucun composant pour cette étape (autre que Scriptor). On peut cependant ajouter son propre composant personnalisé pour valider l'ordre d'achat.

b. Etape d'envoi de l'ordre d'achat

Cette étape traite le bon de commande complété et le transmet au vendeur.

Voici les composants en rapport avec cette étape :

Composant

Description

 

ExecuteProcess

Exécute une application sur le serveur avec les arguments spécifiés.

Créer PO

Génère

un

ordre

d'achat

basé

sur

un

fichier

modèle.

PipeToPipe Transfer

Transfère un objet OrderForm ou Dictionary du pipeline en cours d'exécution vers un autre pipeline.

POtoFile

Envoie un ordre d'achat (ordinairement le résultat de Créer PO) à un fichier.

SaveReceipt

Ecrit le contenu de l'objet OrderForm dans l'espace de stockage des reçus.

SendSMTP

Envoie

un

message

électronique

à

l'adresse

spécifiée.

 

Composant

Description

SQLItem

Exécute la commande SQL spécifiée pour chaque article de la commande avec pour arguments les champs indiqués de la commande et de l'article.

SQLItemADO

Exécute la commande SQL spécifiée pour chaque article de la commande avec pour arguments les champs indiqués de la commande et de l'article. Ce composant est identique à SQLItem, excepté qu'il effectue sa tâche à l'aide Microsoft ActiveX Data Objects (ADO) et qu'il peut être inclus dans un pipeline traité.

SQLOrder

Exécute la commande SQL spécifiée une fois par commande, avec pour arguments les champs de la commande indiqués.

SQLOrderADO

Exécute la commande SQL spécifiée une fois par commande, avec pour arguments les champs de la commande indiqués. Ce composant est identique à SQLOrder, excepté qu'il effectue sa tâche à l'aide Microsoft ActiveX Data Objects (ADO) et qu'il peut être inclus dans un pipeline traité.

Tableau 9 : les composants en rapport avec l’étape d’envoi de l’ordre d’achat

VIII.1.2 Pipeline d’échange commercial

Le pipeline d'échange commercial (CIP, Commerce Interchange Pipeline) permet aux entreprises de toute taille d'échanger des informations sous forme électronique. Le pipeline d'échange commercial conditionne et achemine les objets de données commerciales d'une application à l'autre par réseau. Ce réseau peut être local (LAN), étendu (WAN), à valeur ajoutée (VAN) ou Internet. Le pipeline prend en charge les scénarios de commerce interentreprises, notamment les achats d'entreprise et les achats par chaîne d'approvisionnement.

Le pipeline d'échange commercial permet d'effectuer n'importe quel type de transaction commerciale par voie électronique. La figure ci-après illustre la manière dont une entreprise peut utiliser le pipeline d'échange commercial pour communiquer avec une autre en créant un vaste réseau d'entreprises reliées entre elles.

Tr Rec Rec Partenaire1 Partenaire 1.1 Tr Rec Tr Tr Rec Entreprise Tr Rec Tr
Tr
Rec
Rec
Partenaire1
Partenaire 1.1
Tr
Rec
Tr
Tr
Rec
Entreprise
Tr
Rec
Tr
Rec
Rec
Partenaire 2
Partenaire2.1
Tr
Rec
Tr
Tr : Transmission
Rec : Réception

Figure 18 : Utilisation du Pipeline d’échange commercial

Les pipelines de transmission et de réception du pipeline d'échange commercial peuvent tourner sur divers sites et serveurs ou cohabiter sur le même serveur. En fait, le pipeline de transmission ne doit pas nécessairement transmettre ses données à un pipeline de réception. De même, le pipeline de réception ne doit nécessairement recevoir ses données d'un pipeline de transmission. Le pipeline de transmission doit seulement effectuer une transmission vers un composant logiciel (tel un convertisseur EDI) conçu pour interpréter les données envoyées. Le pipeline de réception doit seulement savoir comment interpréter les données reçues.

VIII.2 Integration de la traduction Edifact.

Le composant ExecuteProcess de l’OPP permet d’exécuter une application sur le serveur. L’utilisation de ce composant va nous permettre d’integrer la traduction Edifact dans l’outil de développement (Commerce Server). Nous proposons d’ajouter un composant traducteur après le traitement de la commande par l’OPP et avant la transmission de l’objet commercial par le CIP.

En effet, après le traitement de l’OrderForm (commande) par le pipeline OPP, ce dernier envoie en sortie l’objet Dictionary. Avant d’envoyer le Dictionary au CIP, on execute le processus de traduction qui nous livre un objet Dictionary standard Edifact.

Ce dernier va être traité par le CIP pour être acheminé vers la destination à
Ce dernier va être traité par le CIP pour être acheminé vers la destination à travers le
réseau Internet.
ExecuteProces
Site
OPP
Web
Dictionary
Traducteur Edifact
OrderForm
à plat
Dictionary
Standard
Edifact
CIP
Objet crypté
Internet
et signé

Figure 19 : Intégration de la traduction Edifact

VIII.3 Pipeline Editor

Pipeline Editor est une application qui permet de modifier des pipelines d'échange commercial et des pipelines de traitement des commandes de Commerce Server. Il existe deux versions de Pipeline Editor :

Pipeline Editor version Win32 qui permet de modifier un pipeline sur l'ordinateur local ou sur

un ordinateur connecté à un réseau local (LAN).

Pipeline Editor version ASP qui permet de modifier un pipeline à distance sur Internet à l'aide

d'un navigateur Web.

Ces deux versions offrent des fonctionnalités très semblables. On peut en effet modifier des pipelines existants dans l'une ou l'autre version, mais on ne peut créer un pipeline que dans Pipeline Editor version Win32.

Une présentation plus détaillée de ce composant est donnée dans l’annexe A.

Conclusion

Conclusion Le projet EECPI consiste à développer un environnement pour supporter le commerce électronique
Conclusion Le projet EECPI consiste à développer un environnement pour supporter le commerce électronique

Le projet EECPI consiste à développer un environnement pour supporter le commerce électronique interentreprises sur plate-forme Internet.

Nous avons suivi une démarche composée de plusieurs étapes. Une première étape concerne l’étude des notions relatives au commerce électronique. Une deuxième étape consiste à élaborer l’architecture générale du commerce interentreprises. La troisième étape porte sur l’étude comparative des différents outils de développement E- Commerce du domaine B to B qui existent sur le marché. L’étape suivante est l’installation de la plate-forme choisie. Puis l’adaptation de l’outil et le développement du composant de traduction. Enfin, vient la réalisation de la solution pour le compte de COMPUTIME.

Nous avons présenté dans ce rapport le résultat de l’étude préalable en présentant les différentes notions liées au domaine B to B. Aussi avons-nous présenté l’architecture relative à ce domaine. Ensuite nous avons exposé le résultat de l’étude comparative et l’architecture de la solution choisie.

Des contraintes matérielles concernant les caractéristiques de la plate-forme ont été la cause du retard de l’installation des outils de développement. Une fois les outils seront installés, le projet poursuivra son évolution et aboutira à un résultat qui pourra être le premier de son genre au Maroc. Signalons que le Maroc n’a pas encore de solution dans le domaine du commerce électronique. Le résultat de ce projet sera une solution qui intègre une plate-forme E-Commerce et la traduction Edifact, et sera d’un grand bénéfice pour les PME/PMI, et pour l’économie nationale en générale.

Ce projet nous a été très utile. Nous avons acquis des connaissances pertinentes dans le domaine du commerce électronique généralement, et dans le B to B via Internet spécifiquement. L’environnement du travail nous a permis d’apprendre des connaissances professionnelles, et nous a amenées du cadre d’étudiant vers le cadre d’ingénieur.

Glossaire

Glossaire A ccord d’interchange ANSI A P I Applet B A L B to B C
Glossaire A ccord d’interchange ANSI A P I Applet B A L B to B C

Accord

d’interchange

ANSI

API

Applet

BAL

B to B

Client/Serveur

CIP

COM

Commerce

électronique

Cryptage

Accord Contrat par lequel des personnes établissent les conditions juridiques et techniques d’utilisation d’un EDI. Au plan purement technique, cet accord portera notamment sur le langage utilisé pour l’EDI. La forme des messages, le rythme des échanges, le sort des accès de réception. En plus du traitement et de la sécurité des messages, leur enregistrement, et leur stockage.

American National Standard Institute. Le comité X12 de l’ANSI a mis au point une série de standards pour l’EDI (dénommée ANSI x- 12) : ceux-ci sont compatibles avec les normes et les recommandations internationales UN/EDIFACT.

Application Programming Interface. Décrit la façon de communiquer avec une application.

Application qui est une séquence de code qui ne peut s’exécuter que dans e contexte d’un navigateur

Boîte Aux Lettres. Unité logique d’un système de messageries électroniques qui permet de stocker les messages reçus de différentes origines et d’y accéder à tout moment pour consultation et/ou retrait.

Business to Business : Commerce électronique entre entreprises

Décrit la relation qui existe entre un ordinateur client et un ordinateur serveur au niveau des applications mises en réseau. Le système client est en général l’ordinateur de bureau d’un collaborateur. Le serveur est le plus souvent un ordinateur plus puissant qui stocke de gros volumes de données et sert à exécuter des programmes importants.

Commerce Interchange Pipeline. Ces composants facilitent l'échange d'objets de données d'entreprise

Component Object Model : le Middleware objet de Microsoft

Désigne l’utilisation combinée et optimale des technologies de la communication qui permettent d’assurer et de développer les transactions d’affaires.

Procédé visant à transformer, à l’aide de conventions secrètes, des informations ou des signaux clairs en informations ou signaux inintelligibles pour des tiers.

DCOM

DNA

Donnée

EDI

Edifact

EFI

EFT

HTML

HTTP

Interchange

Internet

Interopérabilité

IP

Java

Distributed Component Object Model. La technologie DCOM permet à deux objets, l’un client, l’autre serveur, de communiquer entre eux.

Distributed interNet Architecture de Microsoft. Une plate-forme de développement pour des applications totalement réparties.

« Fait, concept ou instruction représenté sous une forme conventionnelle et adaptée à une communication, à une interprétation ou à un traitement par l’homme ou par des moyens automatiques. » (ISO2382-1).

Electronic Data Interchange. Transmission d’ordinateur à ordinateur, d’application à application, de données structurées selon des messages préétablis et normalisés via un moyen de télécommunication.

Electronic Data Interchange for Administation, Commerce and Transport. Règles des Nations unies concernant l’EDI.

Echanges de Formulaires Informatisés. Forme simplifiée de l’EDI qui permet à un utilisateur d’émettre ou de recevoir des documents électroniques structurés en mettant à sa disposition des grilles de lecture ou de saisie, simples, appelées formulaires.

Electronique Funds Transfer : technologie fut conçue pour optimiser la transmission électronique d’ordre de paiement

Hyper text Markup Language. Langage normalisé utilisé pour développer les applications Web

Hyper Text Transfer Protocol. Protocol utilisé pour accéder aux serveurs Web.

Anglicisme, synonyme d’échange. « Communication électronique d’un partenaire à un autre en une combinaison structurée de messages et segments de services commençant par un en-tête de contrôle d’échangete se terminant par une fin de contrôle d’échange. » (ISO9735).

INTernational NETwork (le réseau mondial). Réseau constitué d’une fédération de réseaux d’ordinateurs qui utilise le même protocole de communication (TCP/IP) et fonctionnent comme un réseau virtuel unique et coopératif.

Aptitude des équipements terminaux ( informatiques et de télécommunication) à fonctionner avec le réseau. Et avec les autres équipements terminaux permettant d’accéder à un même service.

Internet Protocol. Il est responsable de l’adressage, qu’il effectue sur la base de l’adresse source et de l’adresse cible

Langage de programmation introduit par Sun Microsystems, spécialement conçu pour Internet.

Java Bean

LAN

Middelware

MTS

Navigateur

Pipeline traité

PME/PMI

ODBC

OPP

RPC

RVA

Script

Sécurité

SGML

SMTP

Un composant logiciel écrit en Java conçu pour être manipulé à l’aide d’outils graphiques. Il contient des classes Java et constitue l’élément de base pour construire des appliquettes ou/et des applications Java.

Local Area Network. Un réseau de nature local, qui connecte des ordinateurs d’un même immeuble.

Mot Américain crée pour désigner une couche de logiciel située entre le système d’exploitation d’un ordinateur et les logiciels d’application

Microsoft Transaction Server . Middleware transactionnel fonctionnant au-dessus de DCOM

En Anglais Browser. Logiciel permettant d’affichage des documents du World Wide Web.

Un pipeline traité est un pipeline exclusivement composé de composants conçus et configurés pour prendre en charge des transactions Microsoft Transaction Server (MTS).

Petites et Moyennes Entreprises, Petites et Moyennes Industries.

Open Database Connectivity . Interface standard de Microsoft permettant d’accéder à des données

Order Processing Pipeline. Ces composants sont utilisés pour gérer les données liées à une commande par l'intermédiaire des différentes étapes du processus de traitement des commandes.

Remote Procedure Call. En Français, appel de procédure éloignée.

Réseau à Valeur Ajoutée. Un RVA est un réseau de télécommunication gère par un opérateur. Cet opérateur permet de faire communiquer des applications et des matériels en apportant des fonctionnalités supplémentaires. Comme l’extraction, la traduction, le formatage, ou le choix du protocole de communication.

séquence de code écrite en langage de script, tels que JavaScript ou Vbscript.

Il comprend l’identification, l’authentification, la vérification de l’intégrité des messages. Et la non répudiation des messages au moyen d’une signature électronique.

Standard Generlised Mard-Up Language. Série de standards pour le bornage et l’adressage de parties d’un texte. Norme ISO permettant de décrire un document comme un ensemble organisé pour y accéder de manière automatique et gérer les mises à jour sans avoir à réviser tout le document.

Simple Mail Transfer Protocol. Protocole de transmission d’un message entre deux machines. C’est la messagerie électronique, service majeur d’Internet.

Stub

TCP

Traducteur

URL

VAN

Wallet

WAN

World Wide Web

WWW, Web,

W3

XML

Mot anglais signifiant souche. Un Stub est une séquence de code générée automatiquement permettant de relier client et serveur au Middleware.

Transmmision Control Protocol. Il est basé sur l’utilisation de datagrammes ou « paquets ». TCP assure la communication de bout en bout entre deux équipements.

ou convertisseur, Ensemble logiciel utilisé pour convertir une information dans une codification et/ou selon un format donné dans une autre codification et/ou selon d’autres règles de formatage (structuration).

Uniform Resource Locator. Adresse standardisée de toute ressource sur Internet.

Value Added Network. Voir RVA.

Microsoft Wallet permet aux utilisateurs de stocker leurs informations d'adresse et de paiement en toute sécurité sur leur ordinateur.