PFE SOA TOYOTA ALGERIE

© Boudekhani, Djellouli, 2012.
Conception et réalisation d’une
solution web orientée service (SOA)
pour la gestion du processus de vente
(Application au cas pratique de TOYOTA-ALGERIE)
BOUDEKHANI Mohamed Djamel Eddine
DJELLOULI Hicham
2011-2012

‫الشــــــــعبية‬ ‫الديمــــــــقراطيـــــــة‬ ‫الجـــــــــزائريــــــة‬ ‫الجـمــــهوريــــــــــة‬
République Algérienne Démocratique et Populaire
‫و‬‫العــلـــــــــــــمـي‬ ‫البــــحــــــث‬ ‫و‬ ‫العــــالــــــــــي‬ ‫التــــــــــعـــليــــــم‬ ‫زارة‬
Ministère de l’Enseignement Supérieure et de la Recherche Scientifique
‫اآللي‬ ‫لإلعالم‬ ‫العليا‬ ‫الوطنية‬ ‫المدرسة‬
‫(ال‬‫الوطني‬ ‫معهد‬‫سابقا‬ ‫اآللي‬ ‫اإلعالم‬ ‫في‬ ‫للتكوين‬)
Ecole Nationale Supérieure d’Informatique
Ex. INI (Institut National de Formation en Informatique(
Mémoire de fin d’études
Pour l’obtention du diplôme d’Ingénieur d’Etat en Informatique
Option : Systèmes d’information
Thème
Conception et réalisation d’une solution web orientée
service (SOA) pour la gestion du processus de vente
(Application au cas pratique de TOYOTA-ALGERIE)
Document de Base
Réalisé par : BOUDEKHANI Mohamed Djamel Eddine
DJELLOULI Hicham
Encadré par :
DAIRI Abdelkader
NADER Fahima
Promotion : 2011/2012

III
ِِ‫ب‬‫سـمِهللاِامـرح‬‫ــ‬‫ـمـ‬‫نِامرحمي‬
Remerciement :
Nous souhaitons manifester nos sincères remerciements à Dieu le tout
puissant qui nous a donné la foi, la force et la patience pour aller jusqu’au
bout de ce travail,
Nous exprimons toute notre gratitude pour Nos Promoteurs, Madame
Fahima NADER et Monsieur Abdelkader DAIRI pour leurs précieux conseils,
leur disponibilité, la confiance qu’ils nous ont toujours témoignée et la
sollicitude dont ils nous ont entourées.
Nous remercions, tous le corps enseignant de l’ESI et surtout les membres
du jury un par un, pour avoir accepté de juger notre travail.
Nous tenons à remercier également le personnel de TOYOTA-ALGERIE
notamment l’équipe de IT-department pour leurs soutien et bonne humeur.
Nous exprimons notre reconnaissance à Mlle Amel OUDJET qui nous a
beaucoup aidés et orientés avec ses corrections et remarques.
Nous adressons une pensée affective à Nos Amis de l’ESI qui ont rendu
agréables nos années d’études.
Nous tenons enfin à remercier tous ceux qui ont collaborés de près ou de
loin { l’élaboration de ce travail. Qu’ils acceptent nos humbles
remerciements.

IV
Dédicaces
J’aimerais, avant tout propos, exprimer ma reconnaissance à l’Eternel
mon Dieu pour ce que je suis car aucune vraie réussite n’est possible
sans Lui. Qu’il me soit permis ici de Lui rendre témoignage pour les
merveilles qu’il ne cesse d’accomplir dans ma vie.
Je dédie ce modeste travail :
À mes très chers parents, en témoignage et en gratitude de
leur dévouement et leur soutien permanent durant toutes mes
années d’études, leurs sacrifices illimités, leur réconfort moral
et tous les efforts qu’ils ont consentis pour mon éducation et
mon instruction pour me voir réussir un jour.
Que Dieu les garde inchallah.
À Madjid, Salima, Nawel et Imad;
À Nacer et Aïda;
À toute la famille "DJELLOULI" & "ZIANI" ;
À mon binôme Boudekhani Djamal Eddine et ses parents;
Une dédicace très spéciale à
Meriem ALLOUANI
À tous ceux que j’aime et qui m’aiment, à tous je dédie ce travail…
« Hicham »

V
Dédicaces
Je dédié ce modeste travail,
A mes chers parents qui n’ont jamais cessé de
m’encourager et me soutenir,
A ma chère sœur,
A ma famille,
A mon binôme Hicham et sa famille,
A tous ceux qui me sont chers, et mes amis.
‫امحلدِهلل‬
Mohamed Djamel Eddine

VI
Résumé :
OYOTA-ALGERIE est un membre du groupe multinational Abdulatif Djameel, son
activité principale est la vente de voitures, pièces de rechange, elle assure aussi un
service après-vente pour une large clientèle. TOYOTA-ALGERIE est constituée d’un
ensemble de 5 branches connectées (Alger, Oran,…) chaque branche gère ses propres
ressources et activités locales; et son réseau de distribution comporte plus de 36
concessionnaires éparpillés sur le territoire national.
TOYOTA-ALGERIE dispose d’un progiciel de gestion (ERP) qui regroupe l’ensemble de ses
fonctions au niveau d’Alger (système centralisé), y compris le processus de vente. On
parle donc d’un environnement distribué, hétérogène mais centralisé en termes de
gestion. Dans un tel environnement, avoir une meilleure communication, synchronisation
de traitements (Workflow), abstraction, portabilité et simplicité, a toujours posé un
problème.
Afin d’améliorer le processus de vente actuel, TOYOTA-ALGERIE veut concevoir et mettre
en place une solution basée sur une architecture logicielle distribuée, qui surmonte
l’éloignement géographique des branches, tout en gardant les fonctionnalités assurées
par l’ERP, en permettant à un internaute de se connecter au site web de TOYOTA-
ALGERIE et de bénéficier des services offerts en ligne.
Parmi les architectures qui répondent { cette problématique, L’architecture orientée
service (SOA) offre une solution indépendante des plateformes et langages, répandant
aux contraintes de gestion distribuée, et assurant une meilleure flexibilité du système
d’information. L’élément de base de l’architecture SOA est la notion de « service »
souvent implémenté sous forme de web services.
Le principal travail de ce sujet est donc la conception et la mise en place d’une solution
permettant de consulter plusieurs services en ligne, en cachant la complexité de
l’architecture distribuée.
Mots clés: Processus métier, SOA, Web Services, Intégration.
T

VII
Abstract:
OYOTA-ALGERIE is a member of Abdulatif Djameel a multinational group, its main
activity is the sale of cars, spare parts. It also provides an after-sales service to a
wide customer base. TOYOTA-ALGERIE consists of a set of five branches
connected (Algiers, Oran ...); each branch manages its own resources and local activities.
And its distribution network includes more than 36 dealers scattered nationwide.
TOYOTA-ALGERIE has a management software (Enterprise Resource Planning), which
includes all of its functions at Algiers (centralized system), including the sales process. We
are talking about a distributed environment, but heterogeneous in terms of centralized
management. In such an environment, a better communication, treatments
synchronization (Workflow), abstraction, portability and simplicity has always been a
problem.
To improve the existing sales process, TOYOTA-ALGERIE wants to design and implement
a solution, based on a distributed software architecture that overcomes the geographical
remoteness of branches, while maintaining the features guaranteed by the ERP, allowing
a user to connect to the TOYOTA-ALGERIE website and its services offered online.
Among the architectures that address this problem, service-oriented architecture (SOA)
offers a solution independent of platforms and languages, spreading to distributed
management constraints, and ensure greater flexibility of the information system. The
basic element of SOA is the notion of "service" often implemented as web services.
The main topic of this work is the design and implementation of a solution enabling the
consult several online services, hiding the complexity of the distributed architecture.
Keywords: business process, SOA, Web Services, Integration.
T

VIII
‫ّص‬‫خ‬‫مل‬:
‫يوات‬‫و‬‫ث‬‫ائر‬‫ز‬‫اجل‬‫يه‬‫غضو‬‫يف‬‫مجموػة‬‫غبدانلعيف‬‫مجيل‬‫متؼددة‬،‫يات‬‫اجلنس‬‫وشاظيا‬‫ئييس‬‫ر‬‫ام‬‫ىو‬‫بيع‬‫ات‬‫ر‬‫يا‬‫امس‬‫وكعع‬،‫امغيار‬‫كام‬‫ر‬ّ‫ف‬‫ثو‬‫يضا‬‫أ‬
‫خدمات‬‫ما‬‫بؼد‬‫بيع‬‫م‬‫ا‬‫ملاػدة‬‫اسؼة‬‫و‬‫من‬‫امزابئن‬.‫يوات‬‫و‬‫ث‬‫ائر‬‫ز‬‫اجل‬‫ثتكون‬‫من‬‫مخس‬‫فروع‬‫متطةل‬(‫ائر‬‫ز‬‫اجل‬،‫امؼامصة‬‫ان‬‫ر‬‫وى‬)...‫؛‬‫لك‬‫فرع‬
‫يدير‬‫ارده‬‫و‬‫م‬‫اخلاضة‬‫شعتو‬‫و‬‫أ‬‫و‬،‫احمللية‬‫يف‬‫بكة‬‫ش‬‫ثوزيع‬‫ثضم‬‫كرث‬‫أ‬‫من‬36‫متؼامل‬‫منترشة‬‫ػىل‬‫امطؼيد‬‫اموظين‬.
‫يوات‬‫و‬‫ث‬‫ائر‬‫ز‬‫اجل‬‫متتكل‬‫برانمج‬‫دارة‬‫ا‬(‫ختعيط‬‫ارد‬‫و‬‫م‬‫املؤسسات‬)،‫واذلي‬‫يتضمن‬‫مجيع‬‫وظائفو‬‫يف‬‫ائر‬‫ز‬‫اجل‬‫امؼا‬‫مصة‬(‫هظام‬‫مركزي‬)،‫مبا‬‫يف‬
‫ذكل‬‫معلية‬‫بيع‬‫م‬‫ا‬.‫حنن‬‫هتحدث‬‫غن‬‫بيئة‬،‫موزػة‬‫مكن‬‫و‬‫غري‬‫وسة‬‫ا‬‫متج‬‫من‬‫حيث‬‫دارة‬‫ال‬‫ية‬‫ز‬‫املرك‬.‫يف‬‫مثل‬‫ىذه‬،‫امبيئة‬‫حتسني‬‫الثطال‬
‫وػالجات‬‫امن‬‫زت‬‫ام‬(‫سري‬‫امؼمل‬)،‫بطفة‬‫جمردة‬‫و‬،‫يعة‬‫بس‬‫َّل‬‫ث‬‫م‬‫دامئا‬‫مشالك‬‫يطؼب‬‫امتؼامل‬‫مؼو‬.
‫تحسني‬‫م‬‫معلية‬‫بيع‬‫م‬‫ا‬،‫احلامية‬‫يوات‬‫و‬‫ث‬‫ائر‬‫ز‬‫اجل‬‫يد‬‫ر‬‫ت‬‫ثطممي‬‫اجناز‬‫و‬،‫حل‬‫استنادا‬‫ىل‬‫ا‬‫ىندسة‬‫برجميات‬،‫موزػة‬‫ثتغلب‬‫ػىل‬‫امبؼد‬‫ايف‬‫ر‬‫اجلغ‬
،‫نلفروع‬‫مع‬‫احملافظة‬‫ػىل‬‫ات‬‫زي‬‫امل‬‫بة‬‫املكتس‬‫من‬‫برانمج‬‫دارة‬‫ا‬‫غامل‬‫ال‬.‫هبدف‬‫ن‬‫أ‬‫يتحطل‬‫تخدم‬‫املس‬‫ػىل‬‫خدمات‬‫يوات‬‫و‬‫ث‬‫ائر‬‫ز‬‫اجل‬ِ‫ر‬‫ملؼ‬‫ا‬‫وضة‬
‫ػرب‬‫هت‬‫رت‬‫ه‬‫ال‬.
‫من‬‫بني‬‫امبنيات‬‫امربجمية‬‫اميت‬‫ثؼاجل‬‫ىذه‬،‫املشلكة‬‫امبنية‬‫متؼددة‬‫اخلدمات‬‫ثلدم‬‫حال‬‫تلال‬‫مس‬‫غن‬‫م‬ ُ‫ُظ‬‫ه‬‫شغيل‬‫مت‬‫ا‬‫و‬‫مغات‬ِ‫رب‬‫ام‬،‫جمة‬‫مع‬
‫تجابة‬‫الاس‬‫مرشوط‬‫دارة‬‫ال‬،‫املوزػة‬‫وضامن‬‫كدر‬‫كرب‬‫أ‬‫من‬‫هة‬‫و‬‫املر‬‫يف‬‫هظام‬‫املؼلومات‬.‫امؼنرص‬‫سايس‬‫ال‬‫ميذه‬‫امبنية‬‫ىو‬"‫اخلدمة‬"‫اميت‬
‫ػادة‬‫ما‬‫ُنجز‬‫ث‬‫غن‬‫يق‬‫ر‬‫ظ‬‫خدمات‬‫يب‬‫و‬‫ام‬.
‫املوضوع‬‫ئييس‬‫ر‬‫ام‬‫ميذا‬‫امؼمل‬‫ىو‬‫ثطممي‬‫اجناز‬‫و‬‫حل‬‫ن‬ِّ‫ك‬َ‫م‬ُ‫ي‬‫تخدم‬‫املس‬‫من‬‫احلطول‬‫ػىل‬‫خدمات‬‫يوات‬‫و‬‫ث‬‫ائر‬‫ز‬‫اجل‬‫اميت‬‫سيمت‬‫ثوفريىا‬‫ػرب‬
‫هت‬‫رت‬‫ه‬‫ال‬,‫مع‬‫خفاء‬‫ا‬‫ثؼليدات‬‫امبنية‬‫املوزػة‬.
‫لكامت‬‫امبحث‬:‫امؼمليات‬،‫ميية‬‫تنظ‬‫م‬‫ا‬‫امبنية‬‫متؼددة‬،‫اخلدمات‬‫اخلدمات‬‫بكية‬‫امش‬(‫يب‬‫و‬‫ام‬)،‫دماج‬‫ال‬

IX
Table des matières
TABLE DES MATIERES............................................................................................................................................ IX
TABLE DES FIGURES.............................................................................................................................................. XII
LISTE DES TABLEAUX :..........................................................................................................................................XV
LISTE DES SIGLES ET ABREVIATIONS : ................................................................................................................XVI
.................................................................................................................1INTRODUCTION GENERALE
INTRODUCTION GENERALE :..................................................................................................................................2
PRESENTATION DU SUJET :........................................................................................................................................3
Contexte :........................................................................................................................................................3
Problématique :...............................................................................................................................................3
Objectifs assignés : ..........................................................................................................................................4
ORGANISATION DU RAPPORT : ..................................................................................................................................5
PARTIE I : SYNTHESE BIBLIOGRAPHIQUE..................................................................................6
CHAPITRE 1 : L’APPROCHE PROCESSUS ................................................................................................................8
I.1 INTRODUCTION : .................................................................................................................................................8
I.2 DEFINITIONS : ....................................................................................................................................................8
I.3 OBJECTIFS : .......................................................................................................................................................9
I.4 TYPES DE PROCESSUS POUR UNE APPROCHE PROCESSUS : .......................................................................................9
I.5 LE PROCESSUS METIER :.....................................................................................................................................10
I.5.1 Définition :..............................................................................................................................................10
I.5.2 Couches d’un processus métier :............................................................................................................11
I.5.3 Gestion des processus métiers (Business Process Management) :........................................................12
I.5.3.1 Les avantages de la gestion des processus métiers...........................................................................................12
I.5.3.2 Cycle de vie d’une gestion de processus métier(BPM) .....................................................................................12
I.5.4 Le cycle de vie d’un processus métier :..................................................................................................13
I.6 GENERALITES SUR LE PROCESSUS DE VENTE :........................................................................................................13
I.6.1 Le processus d’achat :............................................................................................................................14
I.6.2 Le E-commerce :.....................................................................................................................................14
I.6.2.1 Processus de vente en ligne :................................................................................................................................15
I.6.2.2 Systèmes de paiement électronique : .................................................................................................................16
I.6.2.3 Bénéfices d’avoir un processus de vente en ligne : ..........................................................................................16
I.6.2.4 Les possibles problèmes de la vente en ligne : ..................................................................................................16
I.6.3 La vente en ligne en Algérie:.................................................................................................................17
I.7 CONCLUSION :..................................................................................................................................................17
CHAPITRE 2 : L’INTEGRATION..............................................................................................................................19
II.1 INTRODUCTION : ..............................................................................................................................................19
II.2 DEFINITIONS : .................................................................................................................................................19
II.3 DEFIS D’INTEGRATION : ....................................................................................................................................20
II.4 ARCHITECTURE D’INTEGRATION :.......................................................................................................................21
II.4.1 Intégration décentralisée : ....................................................................................................................21
II.4.2 Intégration centralisée :........................................................................................................................22
II.5 LES COUCHES (IMPLIQUEES) PAR L'INTEGRATION .................................................................................................23
II.5.1 L’intégration au niveau de données (Data-level integration) :..............................................................23
II.5.2 L’intégration au niveau applicative (Application Integration) : ...........................................................24

X
II.5.3 L’intégration au niveau de processus métiers (Business process integration) :...................................26
II.5.4 L’intégration au niveau Présentation (Presentation integration) :......................................................27
II.6 CONCLUSION : ................................................................................................................................................27
CHAPITRE 3 : ARCHITECTURE ORIENTEE SERVICE .............................................................................................29
III.1 INTRODUCTION :.............................................................................................................................................29
III.2 DEFINITIONS : ................................................................................................................................................29
III.3 AVANTAGES DE LA SOA :.................................................................................................................................30
III.4DESCRIPTION D’UNE ARCHITECTURE SOA :........................................................................................................32
III.4.1 Couches de SOA :..................................................................................................................................32
III.4.2 Les concepts basiques de SOA :..........................................................................................................33
III.4.2.1 Services :................................................................................................................................................................33
III.4.2.2 Contrat de service :..............................................................................................................................................36
III.4.2.3 Orchestration de services :.................................................................................................................................38
III.4.2.4 Chorégraphie :......................................................................................................................................................39
III.4.2.5 Le bus de service (Entreprise Service Bus):......................................................................................................40
III.5 CONCLUSION : ...............................................................................................................................................41
CHAPITRE 4 : WEB SERVICES ...............................................................................................................................43
IV.1 INTRODUCTION :.............................................................................................................................................43
IV.2 DEFINITIONS : ................................................................................................................................................43
IV.3 CARACTERISTIQUE D’UN SERVICE WEB : .............................................................................................................44
IV.4 TYPOLOGIE DES SERVICES WEB :........................................................................................................................44
IV.5 ARCHITECTURE ET FONCTIONNEMENT D’UN WEB SERVICES : .................................................................................45
IV.6 XML ET LES WEB SERVICES : ............................................................................................................................49
IV.7 L’INTERET D’UTILISER LES WEB SERVICES :..........................................................................................................49
IV.8 LES WEB SERVICES ET L’INTEGRATION :..............................................................................................................49
IV.9 LES WEB SERVICES ET SOA : ............................................................................................................................50
IV.10 CONCLUSION :..............................................................................................................................................50
PARTIE II : ETUDE DE CAS / PROCESSUS DE VENTE DE TOYOTA-ALGERIE .......51
CHAPITRE 1 : ETUDE PRELIMINAIRE....................................................................................................................52
I.1 INTRODUCTION : ...............................................................................................................................................52
I.2 PRESENTATION DE L’ORGANISME D’ACCUEIL :.......................................................................................................52
I.2.1 Présentation de TOYOTA :......................................................................................................................52
I.2.1.1 Historique de TOYOTA :........................................................................................................................53
I.2.1.2 Divisions et filiales :..............................................................................................................................53
I.3 TOYOTA-ALGERIE :.......................................................................................................................................54
I.3.1 Organigramme de TOYOTA-ALGERIE :....................................................................................................55
I.4 GENERALITES SUR LE CADRE DE L’ETUDE : ............................................................................................................55
I.4.1 Cadre de l’étude: ....................................................................................................................................55
I.4.2 Situation informatique de TOYOTA-ALGERIE:........................................................................................56
I.4.3 Cahier de charge : ..................................................................................................................................57
I.5 DEMARCHE GLOBALE ADOPTEE POUR L’ANALYSE ET LA CONCEPTION :......................................................................57
I.5.1 Approche adoptée :................................................................................................................................57
I.5.2 Démarche adoptée:................................................................................................................................58
I.5.3 Méthode adoptée: .................................................................................................................................58
I.5.4 Modélisation adoptée:...........................................................................................................................59
I.6 CONCLUSION: ..................................................................................................................................................59

XI
CHAPITRE 2 : ANALYSE ET CONCEPTION ............................................................................................................61
II.1 INTRODUCTION : ..............................................................................................................................................61
II.2 ANALYSE : ......................................................................................................................................................61
II.2.1 Aspect Pragmatique :............................................................................................................................62
II.2.1 Aspect Sémantique :..............................................................................................................................71
II.3 CONCEPTION:..................................................................................................................................................79
II.3.1 Aspect géographique: ...........................................................................................................................79
II.3.2 Aspect Logique:.....................................................................................................................................80
II.3.2.1 Architecture Logique:.........................................................................................................................81
II.3.2.2 Identification des services:.................................................................................................................85
II.4 CONCLUSION : ................................................................................................................................................95
CHAPITRE 3 : REALISATION..................................................................................................................................97
III.1 INTRODUCTION :.............................................................................................................................................97
III.2 ASPECT TECHNIQUE : ......................................................................................................................................98
III .3 ASPECT LOGICIEL :.........................................................................................................................................99
III .4 PRESENTATION DES INTERFACES PRINCIPALES DE L’APPLICATION DE VENTE EN LIGNE: ...........................................101
III.5 CONCLUSION :..............................................................................................................................................108
....................................................................................................................109CONCLUSION GENERALE
CONCLUSION GENERALE ET PERSPECTIVES :...................................................................................................110
BIBLIOGRAPHIE ..................................................................................................................................................112
ANNEXE A: PRAXEME.........................................................................................................................................115
PRESENTATION DE LA METHODE PRAXEME :............................................................................................................115
LES DIFFERENTS ASPECTS DE LA METHODE PRAXEME : ..............................................................................................116
LES REGLES DE DERIVATION :.................................................................................................................................117
POURQUOI PRAXEME :.........................................................................................................................................118
ANNEXE B : ASPECT SECURITE...........................................................................................................................119
IDENTIFICATION DES INFORMATIONS A SECURISER :.................................................................................................119
ANALYSE DES RISQUES : .......................................................................................................................................119
MESURES DE SECURITE :.......................................................................................................................................119
1. Physique :............................................................................................................................................119
2. Logique :.............................................................................................................................................119
ANNEXE C : SUITE DES DIAGRAMMES CONCEPTUELS.....................................................................................120
TRAVAUX CITES EN ANNEXES:...............................................................................................................................125
LISTE DES FIGURES D’ANNEXES:............................................................................................................................126
LISTE DES TABLEAUX D’ANNEXES:.........................................................................................................................126

XII
Table des figures
Figure 1: Plan du mémoire-----------------------------------------------------------------------------------------------------5
Figure 2: L'approche processus -----------------------------------------------------------------------------------------------8
Figure 3: Vue systémique du processus métier-----------------------------------------------------------------------10
Figure 4: Processus de vente ------------------------------------------------------------------------------------------------11
Figure 5:cycle de vie d'un BPM --------------------------------------------------------------------------------------------12
Figure 6: Cycle de vie d’un processus métier (Weske, 2007)-------------------------------------------------------13
Figure 7: Etapes d’un processus de vente (Steven, 2010) --------------------------------------------------------15
Figure 8: Les couches les plus importantes pour la création d’une solution basée sur SOA---------21
Figure 9: Intégration décentralisée/service légataire installé sur un frontal (Xavier Fournier-Morel,
2008) -------------------------------------------------------------------------------------------------------------------------------22
Figure 10: Intégration centralisée via un service technique (Xavier Fournier-Morel, 2008)-----------22
Figure 11: L’intégration au niveau de données------------------------------------------------------------------------23
Figure 12: Services exposant des interfaces(API) ---------------------------------------------------------------------24
Figure 13:Modélisation des processus métiers-------------------------------------------------------------------------26
Figure 14: L'architecture SOA (Titux.com) -------------------------------------------------------------------------------31
Figure 15: Les couches SOA --------------------------------------------------------------------------------------------------32
Figure 16: Concepts de base d'une SOA----------------------------------------------------------------------------------33
Figure 17: Composition d'un Service (Rosen, Lublinsky, Smith, & Balcer, 2008)---------------------------34
Figure 18: Couplage fort (Bonnet, 2005)---------------------------------------------------------------------------------35
Figure 19: Couplage faible (Bonnet, 2005)-------------------------------------------------------------------------------35
Figure 20: La notion du Contrat---------------------------------------------------------------------------------------------37
Figure 21: Exemple de contraintes non fonctionnelles ------------------------------------------------------------37
Figure 22: Orchestration Vs Chorégraphie (valtech)----------------------------------------------------------------39
Figure 23:Echange d’informations entre Client et service via un bus ESB-----------------------------------41
Figure 24: Les couches de base de communications entre les services web ----------------------------------44
Figure 25: L’architecture d’un service Web traditionnel ------------------------------------------------------------45
Figure 26: Modélisation d’un service Web ------------------------------------------------------------------------------45
Figure 27: Structure d’un message SOAP --------------------------------------------------------------------------------47
Figure 28 : Structure d’un document WSDL2 ---------------------------------------------------------------------------47
Figure 29: Implémentation de SOA basée sur les Web Services --------------------------------------------------50
Figure 30 Organigramme de TOYOTA-ALGERIE ------------------------------------------------------------------------55
Figure 31 Approches de conception SOA (Heubès, 2007)-----------------------------------------------------------57

XIII
Figure 32 Choix Conceptuels------------------------------------------------------------------------------------------------59
Figure 33 Diagramme de cas d'utilisation - Gestion de contenu --------------------------------------------------63
Figure 34 Diagramme d'activité du cas d'utilisation Consulter le catalogue des articles ------------------64
Figure 35 Diagramme d'activité - Création d’un article--------------------------------------------------------------65
Figure 36 Diagramme de cas d'utilisation - Gestion de panier-----------------------------------------------------65
Figure 37 Diagramme d'activité - Ajouter un article au Panier ----------------------------------------------------66
Figure 38 Diagramme de cas d'utilisations - Gestion de profile ---------------------------------------------------66
Figure 39 Diagramme d'activité du cas d'utilisation Création client ---------------------------------------------67
Figure 40 Diagramme de cas d'utilisation - Gestion de vente------------------------------------------------------68
Figure 41 Diagramme d'activité du cas d'utilisation Prise de rendez-vous------------------------------------69
Figure 42 Diagramme d'activité du cas d'utilisation Paiement ---------------------------------------------------71
Figure 43 Diagramme de classe du module Order Management-------------------------------------------------72
Figure 44 Diagramme de classe globale----------------------------------------------------------------------------------73
Figure 45 Diagramme d'états de transitions de la classe Client---------------------------------------------------74
Figure 46 Diagramme d'états de transitions de la classe Article (vu par l'administrateur)----------------75
Figure 47Diagramme d'états de transitions de la classe Article (vu par Client)-------------------------------75
Figure 48 Diagramme d'états de transitions de la classe Commande ------------------------------------------75
Figure 49 Diagramme d'états de transitions de la classe Panier --------------------------------------------------75
Figure 50 Diagramme d'états de transitions de la classe Ligne de Commande-------------------------------76
Figure 51 Suite des états de transition qui comporte la procédure de paiement---------------------------76
Figure 52 Diagramme d'états de transitions de la classe Promotion--------------------------------------------76
Figure 53 Diagramme d'états de transitions de la classe Rendez-Vous----------------------------------------77
Figure 54 Diagramme de déploiement de l'Aspect Géographique -----------------------------------------------80
Figure 55 Clé de l'Architecture Logique ----------------------------------------------------------------------------------82
Figure 56 Première partie de l'Architecture Logique-----------------------------------------------------------------83
Figure 57 Deuxième partie de l'Architecture Logique----------------------------------------------------------------84
Figure 58 Diagramme de séquence du service Création d’un Client---------------------------------------------86
Figure 59 Diagramme de séquence de service Créer un article --------------------------------------------------87
Figure 60 Diagramme de séquence du service Réservation d’un Rendez-Vous ------------------------------88
Figure 61 Diagramme de séquence du service Création d’une Commande -----------------------------------89
Figure 62 Diagramme de séquence du service Création de paiement en ligne-------------------------------90
Figure 63 Diagramme de séquence du service Consulter la liste des clients selon un type paramétré91
Figure 64 Diagramme de séquence du service Consulter la liste des articles selon un type paramétré
----------------------------------------------------------------------------------------------------------------------------------------92

XIV
Figure 65Diagramme de séquence du service Consulter l’historique des commandes d’un client-----93
Figure 66 Diagramme de séquence du service Consulter l’historique des paiements en ligne d’un
client--------------------------------------------------------------------------------------------------------------------------------94
Figure 67 Diagramme de déploiement de l’Architecture Technique/Logiciel---------------------------------97
Figure 68 Authentification Client----------------------------------------------------------------------------------------- 101
Figure 69 Page d’accueil----------------------------------------------------------------------------------------------------- 101
Figure 70 Présentation du catalogue de voitures en ligne-------------------------------------------------------- 102
Figure 71 Détails sur un Article-------------------------------------------------------------------------------------------- 102
Figure 72 Commande en ligne--------------------------------------------------------------------------------------------- 103
Figure 73 Facturation -------------------------------------------------------------------------------------------------------- 103
Figure 74 Paiement----------------------------------------------------------------------------------------------------------- 104
Figure 75 Catégorie d'articles---------------------------------------------------------------------------------------------- 104
Figure 76 Kit de distribution ----------------------------------------------------------------------------------------------- 105
Figure 77 Kit d'embrayage-------------------------------------------------------------------------------------------------- 105
Figure 78 Panier d'achat ---------------------------------------------------------------------------------------------------- 106
Figure 79 Catalogue de Services et Prestations ---------------------------------------------------------------------- 106
Figure 80 Statistique sur le compte Client----------------------------------------------------------------------------- 107
Figure 81 Historique et Suivi Commande ------------------------------------------------------------------------------ 107
Figure 82 Succursales et Concessionnaires de TOYOTA-ALGERIE répartis sur la carte ------------------- 108

XV
Liste des tableaux :
Tableau 1: Couches technologiques des Services Web ......................................................................46
Tableau 2 Dictionnaire de données...................................................................................................79
Tableau 3 Contrat de Service Création d’un client.............................................................................85
Tableau 4 Contrat de Service Créer un article....................................................................................87
Tableau 5 Contrat de Service Réservation d’un rendez-vous.............................................................88
Tableau 6 Contrat de Service Création d’une commande. ................................................................89
Tableau 7 Contrat de Service Création d’un paiement en ligne.........................................................90
Tableau 8 Contrat de Service Consulter la liste des clients selon un type paramétré.........................91
Tableau 9 Contrat de Service Consulter la liste des articles selon un type paramétré. ......................92
Tableau 10 Contrat de Service Consulter l’historique des commandes d’un client............................93
Tableau 11 Contrat de Service Consulter l’historique des paiements en ligne d’un client..................94

XVI
Liste des sigles et abréviations :
API : Application Programming Interface JDBC : Java Database Connectivity
AOS : Architecture Orientée Service JEE : Java Entreprise Edition
BPM : Business Process Management JSF : Java Server Faces
EAI : Entreprise Application Integration SI : Système d’Information
EJB : Entreprise Java Bean SOA : Service-Oriented Architecture
ERP : Entreprise Ressource Planning SOAP : Simple Object Acces Protocol
ESB : Entreprise Service Bus UDDI : Universal Description Discovery and
Integration
HTTP(S) : HyperText Transfer Protocol
(Secure)
WSDL : Web Service Description Language
IP : Internet Protocol XHTML : Extensible HyperText Markup
Language
IT : Information Technologies XML : Extensible Markup Language

© Boudekhani, Djellouli, 2012.
INTRODUCTION
GENERALE

Introduction générale
2
Introduction générale :
Afin de répondre aux exigences du marché et renforcer leur compétitivité, les
entreprises se concentrent de plus en plus sur leur cœur de métier, elles cherchent
toujours à augmenter les revenus et réduire les coûts de leurs processus métiers, qui
sont généralement supportés par des systèmes d’informations distribués.
Dans ce cas, le rôle du système d’information selon Mike Rosen est de valoriser la
circulation des données entre les différentes parties de l’entreprise, en mettant en avant
l‘importance de ses processus métiers et garantissant l‘interopérabilité, la flexibilité et
la réutilisabilité. (Rosen, Lublinsky, Smith, & Balcer, 2008)
En effet, un processus métier qui manque d’efficacité peut engendrer une perte
de revenu et/ou une augmentation des coûts. Ce qui a incité TOYOTA-ALGERIE
d’accorder une grande importance { l’amélioration de son processus de vente actuel, elle
cherche une solution qui surmonte l’éloignement géographique de ses
branches, tout en gardant les fonctionnalités assurées par son ERP.
L’architecture orientée service est une des architectures qui répondent bien à ces
défis et qui vise à répondre de manière pertinente aux challenges liés à la flexibilité,
l’interopérabilité, et l’agilité des S.I. C’est une approche architecturale qui exploite la
propriété de couplage faible des services, s‘exécutant au cours d‘un processus métier, et
permette de les réutiliser, tout en assurant une facilité d’intégration de nouvelles
solutions.
Cependant, une telle architecture impose que tous les services soient exposés sur
le web à travers les services web. L'avantage de cette conception est que le support des
messages d'invocation de service (le web donc) est vraiment universel et ne nécessite
aucune configuration, maintenance, évolution… (den, 2007)
TOYOTA-ALGERIE veut adopter une « Architecture Orientée Services » (SOA) d’une
manière à la fois personnalisée et adaptée à son contexte, à ses besoins, à ses contraintes
en vue de faire converger le « Business » et l’« IT ». Autrement dit de réduire les écarts
constatés entre les enjeux métiers de l’entreprise, et le Système d’Information (SI)
déployé et censé aider à y répondre. Cet alignement « Business / IT » va assurer à
l’entreprise une flexibilité, une souplesse d’exécution lui permettant de réagir rapidement
et efficacement aux différents changements qui l’impactent, et enfin d’améliorer sa part
de marché.
Le présent document illustre notre travail qui consiste à concevoir et à mettre en
place une application web basée sur une architecture orientée service, implémentée par
des services web permettant aux clients de TOYOTA-ALGERIE et aux internautes de
bénéficier des services offerts en ligne sur son site web.

3
Présentation du sujet :
Contexte :
TOYOTA-ALGERIE est un membre du groupe Abdulatif Djameel (Multinational).
L’activité principale de TOYOTA-ALGERIE est la vente de voitures, pièces de rechange et
assure un service après-vente pour une large clientèle. TOYOTA-ALGERIE est constituée
d’un ensemble de 5 branches connectées (Alger, Oran, Annaba, Blida, Ouargla), chaque
branche gère ses propres ressources et activités, et d’un réseau de distribution
comportant plus de 36 concessionnaires éparpillés sur quelques points du territoire
national.
Problématique :
Les estimations de l’activité commerciale du marché Algérien de l’automobile
indiquent que le marché potentiel Algérien est en croissance permanente, En 2011 la
hausse des importations a été de 36%1
par rapport à 2010. Cette situation représente pour
les entreprises une source importante pour augmenter ses profits. Elle a incité les
dirigeants de TOYOTA-ALGERIE à chercher les meilleures solutions pour l’exploiter, y
compris celles liées { son système d’information, afin de bien se positionner sur le marché
et de faire face aux différents défis qui l’attendent dans l’avenir.
Comme cité avant, chaque branche de TOYOTA-ALGERIE gère ses propres
ressources et activités au niveau local tel-que :
 Services : rendez-vous, réservation, commande, suivie, payement, réclamations…etc.
 Sa plate-forme technique (Base de données, Système d’exploitation, Serveur
d’applications).
1
Le marché algérien de l’automobile : un marché pas comme les autres / Par : Mustapha MEKIDECHE, journal
Liberté, disponible sur : http://www.liberte-algerie.com/contribution-economique/le-marche-algerien-de-l-
automobile-un-marche-pas-comme-les-autres-en-toute-liberte-174952

4
Une opération de synchronisation générale est déclenchée au niveau de la branche
d’Alger.
En s’appuyant sur ces contraintes, Les principales difficultés relevées par les
responsables de TOYOTA-ALGERIE sont citées ci-dessous :
1. Les clients sont contraints de se déplacer aux agences pour bénéficier des services
(vente et après-vente) offerts par TOYOTA-ALGERIE tels que la prise de rendez-vous,
Réservation et commandes de voiture et/ou pièce de rechange, faire le suivi d’une
commande, Déposer des réclamations, et enfin le payement.
2. TOYOTA-ALGERIE dispose d’une masse importante d’informations provenant des
différentes branches (Alger, Oran, Annaba, Blida, Ouargla), et applicatifs (ERP, …) de
l’entreprise. Cette masse d’information hétérogène engendre parfois un risque
d’utilisation des données redondantes et parfois erronées ce qui peut influer la qualité
de la décision prise.
3. Le site web actuel de TOYOTA-ALGERIE ne permet pas une bonne communication et
visibilité entre l’entreprise et ses clients, ce qui cause une perte probable des clients
potentiels.
Objectifs assignés :
Pour surmonter les difficultés déjà mentionnées TOYOTA-ALGERIE a fixé les objectifs
suivants :
Décentraliser le système d’information, et offrir plus d’autonomie aux différentes
branches.
Donner la possibilité aux clients de bénéficier de certains services sans avoir à se
déplacer (Prise de rendez-vous en ligne, Réservation de voiture et/ou pièce de
rechange, Passez des commandes de voitures et/ou pièces de rechange, faire le
suivi d’une commande, Déposer des réclamations, Faire un payement
électronique).
Permettre une meilleure communication entre les clients et l’entreprise { travers
son site web.

5
Organisation du rapport :
Comme la Figure 1 l’indique, le présent mémoire est composé d’une introduction
générale suivie de deux parties principales ; une partie théorique et une autre
pratique :
Figure 1: Plan du mémoire
Partie I : cette partie va présenter des concepts purement théoriques, elle sera
consacrée à la synthèse bibliographique, elle comporte exactement quatre chapitres où
nous allons aborder l’approche processus, l’intégration, l’architecture orientée service
(SOA), et finalement les web services.
Partie II : présente le cas pratique de notre projet et le processus de
développement de notre solution, elle comporte exactement trois chapitres. Nous
commençons par une étude préliminaire portant sur l’existant de l’organisme d’accueil
suivi par une brève présentation des choix conceptuels adoptés. L‘analyse et la
conception quant à elle dérivera des modèles élaborés en amont pour asseoir
l‘architecture de notre solution selon une orientation service pour la gestion de vente au
sein de Toyota-Algérie. Nous finirons cette partie avec le chapitre réalisation où on
présente le prototype réalisé à travers les vues des diverses fonctionnalités.
Enfin, la dernière partie tire les conclusions et annonce les perspectives.
Des annexes ont été ajoutées afin d'apporter de plus amples informations sur
certains points décrits dans le rapport :
 La présentation de la méthode publique Praxeme qu‘on a adoptée pour la mise en
œuvre d‘une architecture orientée service,
 Les détails de la conception, où nous complétons la description des cas
d‘utilisation et les modèles d‘architecture logique.
Plan du
mémoire
Partie I:
Synthése
bibliographique
Approche
processus
Integration SOA Web service
Partie II:
Conception
Etude de
l'existant
Analyse Conception Réalisation

Partie I :
Cette partie est consacrée à une
étude bibliographique qui précise
le contexte de notre travail, les
notions et concepts que nous
utilisons. Nous commençons par
donner un aperçu de ce qu’est
l’approche par processus, avant de
nous pencher sur le concept
d’intégration, SOA puis sur les web
service.

7
Chapitre❶
L’approche Processus

Chapitre 1 : L’approche processus
8
...
.
I.1 Introduction :
Le marché et l’environnement concurrentiel sont en évolution continue, et
s’enquérir de la performance de l’entreprise revient { s’intéresser à la performance de ses
processus.
L’approche processus, selon Yvon Mougin, est une façon différente de voir le
fonctionnement de l’organisation avec une vision transversale axée sur les résultats. Elle
a surtout été utilisée dans le milieu informatique. Elle y est employée pour décrire et
analyser (modéliser) une activité dans le but de l’informatiser et de s’assure de sa bonne
qualité.
Elle est applicable { tout type d’organisation (entreprises, administrations,
associations…), quelle que soit leur taille, elle constitue un outil très intéressant pour
développer la responsabilisation des personnes et résoudre les dysfonctionnements
internes. (Mougin, 2002)
C’est donc une méthode destinée { maîtriser et améliorer le fonctionnement d'un
organisme.
I.2 Définitions :
L’ISO2
9001 version 2000 définit le processus comme un :"Ensemble d'activités3
corrélées
ou interactives qui transforme des éléments d'entrée en éléments de sortie".
Le groupe Eyrolles définit l’approche processus comme une méthode d’analyse ou de
modélisation, qui consiste à décrire de façon méthodique une organisation ou une
activité, généralement dans le but d’agir dessus. ( BRANDENBURG & WOJTYNA, 2003)
2
International Organization for Standardization
3
Taches identifiables du processus aux entrées et sorties clairement définies et dont la valeur ajoutée est
mesurable.
Activité 1 Activité nActivité 2 ...
.
Entrée
Sortie
Temps
Figure 2: L'approche processus

9
I.3 Objectifs :
En lisant dans la littérature, les principaux objectifs d’une approche processus sont :
 Une meilleure visibilité du fonctionnement de l’entreprise et ainsi permettre une
meilleure maîtrise des relations et interactions entre clients et fournisseurs, internes
et externes.
 Elle facilite les flux de communications et les modes de fonctionnement transversaux.
 Maîtriser la valeur ajoutée de chacun des processus, de voir les points de blocage ou
de risques.
 L'approche processus améliore également le management des interfaces entre
processus.
Pour synthétiser, l’approche processus est une méthode qui consiste à aborder le
fonctionnement de l’entreprise par ses processus. Elle met en évidence des chaînes
d’activités qui conduisent aux produits, aux dysfonctionnements, réduire les coûts et les
délais, et permet d'avoir plus de flexibilité pour satisfaire la clientèle finale..
I.4 Types de processus pour une approche processus :
Selon Brad Debauche, nous distinguons les types suivants :
 Processus de réalisation : Processus contribuant directement à la réalisation du
produit ou du service, depuis la détection du besoin du client à sa satisfaction. Ils
correspondent au cœur de métier de l'organisme.
Exemples : recherche et développement, conception, fabrication, livraison …
 Processus support (ou de "soutien") : Processus qui contribuent au bon
déroulement des autres processus en leur apportant les ressources nécessaires
(humaines, matérielles, financières…).
Exemples : maintenance, ressources humaines, maîtrise de la documentation...
 Processus de management (ou de "pilotage") : Processus qui contribuent à la
détermination de la stratégie, de la politique qualité et au déploiement des
objectifs à travers tous les processus de l'entreprise. Ils permettent leur pilotage
et la mise en œuvre des actions d'amélioration.
Exemples : Responsabilité, autorité et communication, Amélioration continue
Classer les processus permettra d’analyser les différentes exigences concernant la
modélisation des processus selon leur type. Quand il s’agit Par exemple, d’un processus
de production, l’accent est mis sur la logique de construction afin de minimiser le temps
d’exécution. (Brad Debauche, 2004)

10
I.5 Le processus métier :
I.5.1 Définition :
Un processus métier d’après Weske Mathias est : « un ensemble d’activités incluant une
interaction entre des participants (applications ou des services du SI, acteurs humains,
d’autres processus métiers) sous la forme d’échange d’informations ».
Un processus métier peut être interne à une entreprise ou bien il peut mettre en jeu
d’autres partenaires. Dans ce cas on parle de processus collaboratifs. Un processus
collaboratif est appelé « processus métier B2B ». (Weske, 2007)
Tout processus métier selon Geoffrey Sparks : A un objectif, des entrées et sorties
spécifiques, utilise des ressources, a un nombre d‘activités qui se déroulent en un ordre
précis, peut concerner plus d‘une unité d‘organisation, crée de la valeur. (Geoffrey, 2012)
Figure 3: Vue systémique du processus métier
L’événement « déclencheur » : qui est { l’origine du processus (par exemple : événement
« envoi d’une lettre au client » réclamant des informations complémentaires pour traiter
la demande, et l’événement « réception de la réponse du client »).
Informations : Un processus métier utilise des informations pour compléter et adapter
ses activités, contrairement aux ressources, les informations ne sont pas consommées
lors du processus, elles sont plutôt utilisées dans le cadre du processus de
transformation. Une information peut provenir d‘une source externe.
Ressources : Une ressource est une contribution à un processus métier, et, contrairement
à l'information, est généralement consommée durant le traitement.
Afin de modéliser le processus métiers, les notions concernant la modélisation du
processus métier sont présentées ultérieurement.
Objectif : Tout processus métier a un but bien défini. C'est la raison pour laquelle
l'organisation fait ce travail et sa justification, il doit être défini en termes de bénéfices
pour l'organisation.

11
Sorties : Un processus métier produit généralement une ou plusieurs sorties de valeur à
l'entreprise, soit pour l'usage interne ou pour satisfaire des exigences extérieures, Une
sortie d'un processus métier peut alimenter un autre processus.
Exemple : Le schéma ci-dessous est un exemple typique de processus métier qui est le
traitement d’un ordre d’achat (traitement de l’évènement déclencheur). Les activités
constituant ce processus commencent par la prise en compte de la commande et se
terminent par la livraison au client. Entre ces deux extrémités, plusieurs activités
intermédiaires se déroulent selon un chemin connu { l’avance afin de garantir le
fonctionnement correct et cohérent de ce processus. Un exemple de ces activités
intermédiaires est la vérification de niveau de stock pour les articles demandés et dans le
cas d’une réponse négative on devra procéder au lancement du processus de fabrication.
Figure 4: Processus de vente
I.5.2 Couches d’un processus métier :
Le niveau métier : cette vue métier est une vue de haut niveau sur le processus,
définissant ses étapes principales et l’impact sur l’organisation de l’entreprise.
Le niveau fonctionnel : c’est la formalisation des interactions entre les participants
fonctionnels du processus. Dans cette vue, les règles métiers sont formalisées afin de
conditionner l’organisation du processus pour garantir que le résultat issu de son
déroulement est conforme avec l’objectif métier.
Le niveau technique : Il représente les liens entre les activités/participants modélisés au
niveau fonctionnel et les applications/services du système d’information, ainsi que les
tâches utilisateurs.
N.B : Ce découpage n’est pas exhaustive, il existe des modèles qui donnent lieu { d’autres
couches, par exemple : une couche applicative, une couche de données... (Brad
Debauche, 2004)

12
Ces découpages vont être utilisés dans la démarche d’identification des services (chapitre
conception).
I.5.3 Gestion des processus métiers (Business Process Management) :
La gestion des processus métiers selon John Jeston, est une démarche centrée sur les
processus métiers de l'entreprise, orientée à satisfaire les besoins de ses clients.
C’est une méthodologie qui consiste { fournir un ensemble d’outils qui prennent en
charge le cycle de vie d’un processus métier. Il permet de définir rapidement et en
souplesse des processus depuis leur analyse jusqu’à leur implémentation, de déterminer
leurs objectifs, et de les superviser que cela soit au niveau applicatif ou au niveau
fonctionnement humain. (John Jeston, 2006)
I.5.3.1 Les avantages de la gestion des processus métiers
L’impact de la gestion des processus métiers sur une entreprise est très important, en
termes de réduction des coûts administratifs, de gains de productivité et d’optimisation
du fonctionnement de l'entreprise. (Loïc, 2010)
En outre, elle permet :
Une simplification des processus : la modélisation va permettre d’étudier et de
rationaliser les processus avant la phase de conception.
Une Amélioration de l’efficacité des opérations : La durée des cycles est réduite.
Davantage d’opérations pourront être traitées sans personnel supplémentaire.
Un Contrôle des processus métiers : L’entreprise obtient une très bonne conformité aux
diverses réglementations grâce à la mise en œuvre de pratiques éprouvées.
Favoriser une flexibilité maximale : Comme la modélisation des processus s’effectue {
l'aide diagrammes évolués et sans code informatique, les réponses aux évolutions des
besoins sont largement facilitées.
Un suivie de la performance des processus : Les données sont capturées et regroupées
pour former des indicateurs de performance, et être synthétisées dans des tableaux de
bord. Les alertes mises en œuvre sont déclenchées et avertissent automatiquement les
personnes concernées.
I.5.3.2 Cycle de vie d’une gestion de processus
métier(BPM)
Le cycle de vie de la gestion des processus
métiers passe par quatre étapes : (Loïc, 2010).
 La modélisation des processus métier :
représentation graphique des processus.
 Génération de l'application : la génération
des modèles pour tous ce qui est
Figure 5:cycle de vie d'un BPM

13
automatisable, afin de les rendre exécutables pour tous les acteurs ou superviseurs
des processus.
 Exécution des processus : exécution et contrôle des processus et gestion de leurs
cycles de vie.
 L’optimisation des processus : amélioration des processus basée sur des métriques
réelles de performance des processus.
Le BPM a donc comme objectif d’avoir la meilleure vue globale de l'ensemble des
processus métiers de l'entreprise et de leurs interactions pour les optimiser, dans la
mesure du possible, et les automatiser au maximum à l'aide des applications métier.
I.5.4 Le cycle de vie d’un processus métier :
Le cycle de vie d’un processus métier passe
par des phases qui sont indépendantes et ceci
n’implique pas l’ordre des phases. (Weske,
2007)
Conception et analyse : La conception se fera
via un modèle de processus métier et sera
validé par un workshop entre les acteurs
concernés, une simulation technique est
recommandée pour qu’on puisse savoir si le
processus ramène les résultats attendus.
Configuration : Une fois validé le processus métier, plusieurs manières sont possibles
pour l’implémentation. Soit par des procédures classiques sans l’intervention logicielle,
ou bien via un logiciel, où on a intérêt de configurer le système selon l’environnement
organisationnel.
Adoption: Après la configuration du processus métier qui doit répondre aux objectifs
attendus. Sa mise en place est contrôlée par le système de gestion de processus métier
pour s’assurer que le processus métier suit son modèle déj{ décrit.
Evaluation : En utilisant des techniques telles que business activity monitoring et process
mining technics, cette phase a pour but de s’assurer du modèle décrit et même de
l’améliorer.
Administration : Les intervenants dans le cycle de vie d’un processus métier tel que : Chef
process officer, Business engineer, doivent assurer dans une bonne coordination, le bon
fonctionnement du processus métier.
I.6 Généralités sur le processus de vente :
Littéralement, la vente est un échange d’un objet contre un prix convenu. (Définition
de Larousse)
Figure 6: Cycle de vie d’un processus métier (Weske, 2007)

14
Plus généralement la vente est l’ensemble d'opérations (prise de contact,
livraison…) par lesquelles un bien ou un droit détenu par un vendeur est cédé à un
acheteur en échange d'une contrepartie, généralement la remise d'une somme d’argent.
I.6.1 Le processus d’achat :
On présente ici les étapes essentielles d’un processus d’achat (des clients) vue par Ulrike
Mayrhofer:
1. Encercler les besoins.
2. Déterminer les besoins
3. L'évaluation des options
4. Achat
5. Évaluer la décision
Le client d’abord identifie ses besoins, ensuite il définit les prescriptions nécessaires pour
satisfaire ses besoins, après ceci il évalue les options qui s’offrent { lui pour enfin
procéder { l’achat qui se conclue avec une probable négociation et un test de produit
pour évaluer sa satisfaction. (Ulrike, 2006)
Dans un processus de vente, l’Internet peut s’utiliser comme un point de vente ou de
marketing. La vente par Internet est aussi appelée « vente en ligne » ou « commerce
électronique ».
Dans ce qui suit nous allons détailler la notion de e-commerce, pour pouvoir appliquer
ses concepts sur notre processus de vente.
I.6.2 Le E-commerce :
Le commerce électronique (e-commerce, en anglais) désigne l’utilisation des
technologies de l’information et de la communication (les TIC), pour créer, transformer,
et redéfinir des relations commerciales entre des organisations, et entre organisations et
individus. Elle est devenue un composant essentiel pour les stratégies d’affaires et un
catalyseur du développement de l’économie mondiale. (Delacroix, 2000)
Le e-Commerce ne se limite pas à la vente, mais englobe également :
 La réalisation de devis en ligne.
 Le conseil aux utilisateurs.
 La mise à disposition d'un catalogue électronique.
 Un plan d'accès aux points de vente.
 La gestion en temps réel de la disponibilité des produits (stocks).
 Le paiement en ligne.
 Le suivi de la livraison.
 Le service après-vente.

15
I.6.2.1 Processus de vente en ligne :
Le temps est le principal souci du consommateur, chaque démarche d’offre doit proposer
un moyen pour gagner un temps que ce soit pour les commandes ou les livraisons.
Pour cela, le processus de vente doit être automatisé dans chaque une de ses étapes
(ventes, achats, facturations, expéditions).
Pour répondre aux 5 étapes d’achat, vues précédemment, il y a 5 étapes principales pour
un processus de vente en ligne définit par «The digital body language » qui est une
ressource qui aide les entrepreneurs à développer leur trafic web (Steven, 2010):
Figure 7: Etapes d’un processus de vente (Steven, 2010)
❶Perspective : La prospection est l'endroit où le vendeur peut envoyer du trafic ciblé
vers le site de vente. C'est ce que tous l'optimisation du moteur de recherche et de
commercialisation a été d'environ. Le but est d’assurer le client que le vendeur peut
couvrir son besoin.
❷Rapport : La conduite de relation avec le client potentiel sur un site web à une relation
avec tout ce que le site présente : l’esthétique, vitesse de téléchargement, temps de
réponse … cela présente un dialogue avec le client afin de renforcer sa confiance.
❸Qualifier : Dans cette étape, le vendeur essaie de comprendre ce que le client
recherche et puis le conduire exactement où il peut le trouver.
❹Présenter : Dans un site web (qui est notre cas), on ne peut pas entrer dans un dialogue
direct avec le client, mais on peut le savoir grâce à la présentation du site et voir où sont
les choses qui l’ont attiré (En regardant les liens et les mots de recherche exécutée par ce
client).
❺Fermer : Dans cette étape le client conclut son achat, mais il a toujours besoin que le
vendeur lui aide à faire sa décision, plus précisément à avoir confiance en lui-même. Cela
se présente dans un site web par une bonne politique de confidentialité, plus une
garantie.
Ensuite le vendeur aide le client à remplir sa commande c’est-à-dire en remplissant les
champs triviaux à sa place.
Exemple : un scénario de vente en ligne : (Delacroix, 2000)
1. Les visiteurs se connectent sur le site.
2. Ils examinent les produits.
3. Ils ajoutent les produits à leur chariot virtuel d’achats.
❶Perspective ❷Rapport ❸Qualifier ❹Présenter ❺Fermer

16
4. Ils confirment leurs achats.
5. La commande est créée dans la base de données.
6. Le paiement est autorisé.
7. Les commandes sont envoyées à la logistique.
8. Les commandes sont effectuées par la logistique.
I.6.2.2 Systèmes de paiement électronique :
Il existe deux catégories principales des systèmes de paiement électronique (Alami,
2009) :
1. Paiement avec intermédiaire : c’est la banque qui prend en charge les étapes de
transaction, le vendeur ne voit jamais les informations associées au client.
2. Paiement sans intermédiaire : le client remplit un formulaire sécurisé et donne son
numéro de carte bancaire crypté, le vendeur récupère les informations cryptées et
effectue lui-même des transactions avec la banque via son terminal de paiement
électronique.
Il existe différents moyens de paiement électronique, on en cite : Carte de crédit, chèques
électroniques, porte-monnaie électronique…
I.6.2.3 Bénéfices d’avoir un processus de vente en ligne :
On ne pourra pas illustrer tous les bénéfices de la vente en ligne en manque d’une étude
détaillée sur le marché, pour cela on se contente de citer les bénéfices les plus clairs et qui
ont été estimé importants dans le marché mondial : (Nicolas, 2001)
 Atteindre plus de clients.
 Eviter de perdre des parts de marché prises par des entreprises qui utilisent déjà le
commerce électronique.
 Simplifier les tâches de la vente.
 Etendre géographiquement le marché.
 Accélérer le processus de vente.
 Améliorer la qualité de service.
 Réduire les coûts.
N.B : il existe une relation entre la taille d’entreprise et le service de vente en ligne, plus
l’entreprise est grande, elle aura intérêt { offrir des services sur le web, afin de rester en
concurrence sur le marché. En cas inverse, où une entreprise de grande taille n’offert
aucun service en ligne, ceci pourra dégrader l’image de cette entreprise.
I.6.2.4 Les possibles problèmes de la vente en ligne :
Les problèmes récurrents rencontrés par les entreprises d’après (Nicolas, 2001) sont les
suivants :
La sécurité du paiement.

17
Nombre d’achat peut être faible, (d’où la nécessité de faire une étude sur le marché
avant de lancer la vente d’un produit x sur le net).
Impossibilité de vendre un produit sur le web.
Gestion plus complexe de la chaine logistique.
Coût plus ou moins élevé de la solution web.
Les termes de contrat de vente en ligne peuvent ne pas être clairs pour le client.
I.6.3 La vente en ligne en Algérie:
Bien que le payement électronique ne soit pas très développé en Algérie, beaucoup
d’entreprises se sont lancées dans des projets de commerce électronique, non seulement
pour gagner de nouvelles parts du marché mais surtout pour accroitre la relation
entreprise-clients.
Le client souhaite une offre globale immédiatement afin de ne pas réitérer son processus
d'achat. De même, l'interactivité doit s'établir entre les e-clients du site, et l’e-entreprise
afin de créer une véritable communauté virtuelle autour de l’offre. (Benoit, 2008)
I.7 Conclusion :
Dans ce chapitre, Nous avons introduit brièvement l’approche processus, ou nous
avons pu constater son importance pour assurer et améliorer le fonctionnement des
organisations.
Par la suite nous nous sommes focalisés sur le concept processus métier, cadre
d’étude de notre projet et concept de base de notre architecture, pour bien maitriser son
fonctionnement, et également améliorer sa performance, ceci est rendu possible à
travers le BPM. Il nous a été utile pour l‘étude et la formalisation du processus métier de
notre cas d’étude : Le processus de vente chez TOYOTA-ALGERIE.
Puis nous avons donné des généralités sur le processus de vente, ce qui nous a
permis d’avoir une idée clair sur les différentes étapes d’une opération de vente en ligne.
Le chapitre qui suit est consacré { l’intégration des processus métier aux systèmes
d’information.

18
Chapitre❷
L’intégration

Chapitre 2 : L’intégration
19
II.1 Introduction :
Les besoins croissants en matière de disponibilité et d'accessibilité de
l'information présente de nouveaux défis pour le développement d'applications
d’entreprise. Pour cela l’entreprise doit se doter d’un système d’information qui permet
l’intégration intra et inter entreprise.
La majorité des entreprises, cependant, ont toujours des applications existantes et
indispensables à leur mission, développées en utilisant des architectures et des
technologies différentes, qui n'ont généralement pas été conçus permettant une possible
(voir indispensable) extension basée sur de nouvelles architectures et technologies. D’un
autre coté elles ne peuvent pas se permettre de redévelopper l’ensemble de leur système
d'information à partir de zéro dans l'environnement commercial d'aujourd'hui.
Pour répondre à cette tâche difficile et garantir les objectifs d'intégration, plusieurs
méthodes, techniques, modèles et technologies ont été développées au fil des années,
comme Entreprise Application Integration (EAI), gestion des processus métier (BPM) et
service l’architecture orientée services (SOA).
II.2 Définitions :
Le terme intégration désigne selon SCHMUTZ Guido, la conception et la réalisation d'un
système d'information permettant le partage sans restriction des données et des
processus métiers entre toutes les applications connectées. (SCHMUTZ, 2010).
En outre la capacité d'accéder instantanément à des informations vitales qui peuvent être
stockés dans une variété d'applications différentes peut influencer à la réussite d'une
entreprise. Pour chaque entreprise, la présence d’une infrastructure d'information
efficace qui évite la nécessité d'effectuer de nombreuses tâches manuellement ou d’une
façon redondante est très importante. Idéalement, un système bien intégré devrait offrir
le soutien des processus métiers avec un accès instantané à l'information, peu importe
quelle partie du système est utilisé.
Le processus d’intégration est souvent complexe, cette difficulté réside dans le fait que le
projet d’intégration est un sujet qui est lié { la société (entreprise) dans son ensemble, et
non avec le service informatique (IT departement) seulement, où la plupart des
problèmes surgissent. (SCHMUTZ, 2010)
Cette conscience n’est pas toujours présente dans la majorité des entreprises ce qui
présente un risque important d’échec surtout lorsque la haute direction n’emploie pas
suffisamment d’argent et/ou d’équipes d’intégration pour un tel projet.
L'intégration semble être l'une des plus importantes priorités stratégiques,
principalement en raison de nouvelles solutions d'affaires novatrices exigent l'intégration

20
des différentes unités d'affaires : les données de l'entreprise, les applications et les
systèmes d'entreprise. En effet, le total devient plus que la somme de ses parties.
II.3 Défis d’intégration :
Par le passé, il y avait des tentatives de résoudre l’intégration de nouvelles applicatifs
dans l’entreprise par diverses méthodes et technologies: scripts pilotés par batch,
échanges de fichiers par FTP, middleware orientés message, EAI, etc…
Avec CORBA4
, ils ont essayé d’apporter une réponse standardisée { la problématique,
mais sans rencontrer de réel succès décisif.
L’absence de solution architecturale efficace pour résoudre ce problème a plongé les
systèmes d’information dans une situation de blocage vis-à-vis les exigences des métiers.
Typiquement les entreprises qui ont existé ces dernières années ont rarement des
systèmes d'information intégrés. Au contraire, elles sont confrontées à un mélange
disparate de systèmes existant: hétérogènes, lourds et rigides. Les entreprises ont
généralement de différentes applications, développées au fil du temps (SCHMUTZ, 2010).
Il s'agit notamment de:
 Des applications développées à l'intérieur de l'entreprise.
 Des solutions sur mesure, en sous-traitance.
 Des applications commerciales et ERP.
Ces applications marchent généralement sur différentes plate-forme en utilisant
différentes technologies et langages de programmation, parce qu'ils ont été développés
au fil du temps (SCHMUTZ, 2010).
Cela se manifeste par:
 Combinaisons d'applications monolithiques5
, client/serveur et multi-niveaux
 Mélange de solutions procédurales, orienté objet et basées sur composants
 La mixité des langages de programmation
 Différents types de systèmes de gestion de bases de données (relationnelles,
hiérarchiques, objet)
 Différentes solutions middleware de communication (middleware orienté
message, Object Request Broker, les appels de procédure à distance, etc…)
 Transaction et middleware de gestion de sécurité
 Différentes façons de partage des données : utilisation possible de l'EDI, XML, et
d'autres formats propriétaires pour l'échange de données.
4
CORBA : Common Object Request Broker Architecture
5
Qui forme un seul bloc

21
Le problème d’intégration de ces différents types est résolu par l’utilisation de standard
ouverts et diffusés. Grâce à ces standards, les services et l’interface peuvent inter
opérer parce qu’ils sont définis de la même manière.
II.4 Architecture d’intégration :
L’architecture qui permet d’accomplir parfaitement ces tâches est identifiable dans un
modèle multicouche de quatre niveaux : le système d’intégration, les services,
l’orchestration et l’interface. Ces quatre niveaux forment les couches les plus importantes
pour la création d’une solution basée sur l’architecture orientée service. (Liebhart, 2007)
Figure 8: Les couches les plus importantes pour la création d’une solution basée sur SOA
Nous allons voir par la suite, les deux approches architecturales concernant une
intégration SOA avec des applications existantes, comme décrit dans l’ouvrage de
(Xavier Fournier-Morel, 2008) :
II.4.1 Intégration décentralisée :
Elle consiste { faire évoluer le système existant pour qu’il offre lui-même les façades
(services légataires), par exemple sous forme de web services. L’accès { ses façades par
les services de haut niveau (applicatif ou fonctionnel) sera de façon homogène, tout
comme l’accès aux simples services Crée, Lire, Modifier, et Supprimer, via les mêmes
middlewares de communication (Web Service, EJB, ESB…).
Ce type est le plus envisageable surtout lorsque la solution SOA à mettre en place doit
accéder à des sites géographiquement distants et disposant de leur propre informatique
locale souvent ancienne, complexe et efficace d’où l’intérêt de les encapsuler via des
façades «locales».

22
Ces façades permettent de lancer un traitement local (exemple : lancement d’une
commande) ou de récupérer des informations locales à ces sites (exemple : état
d’avancement d’une commande). La figure 9 présente l’intégration décentralisée via des
façades implémentées sur un serveur «frontal» également local.
Les avantages de cette solution sont :
 Préserver un existant rôdé,
 Réaliser les façades par les informaticiens
en charge de ces applications locales,
 Isoler totalement la solution métier SOA de
toute adhérence avec les technologies
«locales».
Facteurs clés pour sa réussite :
Le choix du bus de communication entre la
solution métier SOA et les services
légataires6
distants. Ce bus doit être
compatible avec les technologies locales.
La nécessité de synchroniser fortement le
projet de développement de la solution
métier SOA d’une part, et le projet de
développement des services légataires
d’autre part.
II.4.2 Intégration centralisée :
L’approche centralisée consiste { installer les
façades sur un ou des serveurs entourant le
mainframe, et { encapsuler directement l’accès au
système existant dans ces façades.
Cette solution est intéressante lorsqu’il s’agit
d’accéder { une application du système central
(mainframe) déjà structurée sous forme de
services, ou qu’il est facile de modifier pour qu’elle
offre (dans sa technologie native) l’équivalent de
services.
Dans une solution centralisée, les développeurs
des façades SOA accèdent directement à un
service technique d’accès au middleware de
6
Services représentatifs
Figure 9: Intégration décentralisée/service
légataire installé sur un frontal (Xavier Fournier-
Morel, 2008)
Figure 10: Intégration centralisée via un service
technique (Xavier Fournier-Morel, 2008)

23
communication avec le système existant, que ce soit un EAI, un MOM, un moniteur
transactionnel ou une passerelle orientée mainframe.
II.5 Les couches (impliquées) par l'intégration
L'architecture d'intégration est généralement construite systématiquement de plusieurs
couches. L'idée derrière cela est de décomposer le problème en plusieurs petits
problèmes et de résoudre chaque sous-problème à part.
Les types les plus importants de l'intégration comme présentés par l’ouvrage de
(SCHMUTZ, 2010) sont les suivants:
Data-level integration
Application integration
Business process integration
Presentation integration
II.5.1 L’intégration au niveau de données (Data-level integration) :
C’est souvent le point de départ lorsqu’une
entreprise commence à travailler sur
l'intégration. L’intégration au niveau de données
met l'accent sur le déplacement des données
entre les applications avec l'objectif de partager
les mêmes données entre ces différentes
applications.
D'un point de vue technique, cette opération est
relativement simple vue l’existence de plusieurs
outils permettant le partage de données aux
bases de données.
En outre, L’intégration au niveau de données ne nécessite pas de modifications apportées
aux applications. La figure 11 montre L’intégration au niveau de données.
Mais le problème réside dans la complexité des bases de données et de leur nombre.
Pour réussir cette opération des connaissances techniques ne suffisent pas, il faut :
Comprendre comment les données sont stockées dans telle base de données et
sous quelle forme.
Savoir quand et comment on pourra extraire les données.
Encore plus important, être familier avec le type et la structure de la base de
données de destination.
Cela pour permettre la cohérence de données entre les bases de données ainsi que les
applications qui les utilisent.
Figure 11: L’intégration au niveau de données

24
Il faut aussi garder la sémantique des bases de données, comme Il est probable que nous
aurons à faire face à plusieurs bases de données différentes où chacune a ses propres
caractéristiques applicatives et structurelles.
II.5.2 L’intégration au niveau applicative (Application Integration) :
L'intégration d'applications est centré sur le partage des fonctionnalités du logique
métier, et pas seulement les données pures. L'intégration des applications est
généralement obtenue grâce à l'utilisation d'interfaces de programmation d'applications
(API).
Les applications qui exposent leur fonctionnalité via les API permettent l'accès aux
fonctionnalités d'une manière automatique, sans utiliser l'interface utilisateur.
Auparavant l'utilité d'API n’était pas très
claire, c'est pourquoi la plupart des
anciennes applications ne les ont pas.
Depuis lors, la plupart des applications les
plus récentes ont accepté la notion de
services7
que peut fournir une application à
d'autres applications. Dans les nouvelles
applications existantes, il sera plus
susceptible de trouver des APIs permettant
l’accès { la fonctionnalité du système
existant.
L'objectif de l'intégration des applications
est donc double:
Comprendre et utiliser des API pour accéder aux fonctionnalités requises,
Masquer les différences de technologie utilisée pour les API et leur accès.
Ce dernier point est réalisé en utilisant les services, qui exposent les interfaces(API),
comme indiqué dans la figure 12.
Les interfaces fournissent le contrat entre les applications. La mise en œuvre des
interfaces ou l’exécution de quelques applications en arrière-plan n’est pas un souci, on
peut changer les applications qui implémentent une certaine interface sans le système
d'information influence sur les totales ou partielles applications tant l'interface reste
inchangée.
7
Un service «façade» est un intermédiaire qui permet à ses clients (applications ou
services de haut niveau) réalisés en «nouvelles technologies» d’accéder { des fonctions
métier existantes sans se soucier de l’hétérogénéité technologique.
Figure 12: Services exposant des interfaces(API)

25
Par conséquent, le plus grand soin doit être pris dans la définition d'interfaces.
Aujourd'hui, on admet que les bonnes interfaces sont ceux faiblement couplés. Ceci peut
être réalisé principalement par le partage de données uniquement, sans le
comportement; structuration des données, et utilisant des technologies ouvertes
standard.
Parmi les approches qui sont beaucoup développées autour de ce type, on trouve
l’Entreprise Application Intégration(EAI).
Entreprise Application Intégration :
Définition: L’intégration d’applications d’entreprise (EAI, Enterprise Application
Integration) est un concept qui est la conséquence du besoin d’intégrer des systèmes
d’information pour former un tout cohérent et opérationnel à la fois au sein des
entreprises et entre entreprises (appelé inter-EAI) (Alonso, 2004).
L’EAI est légèrement plus ancien que la SOA et son objectif principal est d’intégrer toute
l’informatique en un seul élément, pour qu’elle soit plus souple et efficace. Comme dans
le cas de la SOA, l’EAI est un terme vague, qui est devenu à la mode et qui a été inventé
pour les mêmes raisons qui ont poussé l’apparition de la SOA.
L’EAI avait comme rôle d’ajouter un système intermédiaire qui facilite la démarche
d’intégration car les outils technologiques utilisés dans un système d’information sont
peu interopérables, l’EAI devait non seulement gérer les formats d’échange mais aussi de
prendre en compte le flux des événements entre les applications, dans ce contexte un
système de gestion de Workflow8
devient un élément important de l’EAI.
Classement des EAI :
L’EAI basé sur le Workflow peut être classée en deux catégories (Kwak, 2002) :
1. EAI statique : L’exécution du processus de Workflow suit un chemin précis et
prédéfini. Il n’est pas possible d’ajouter un processus ou de modifier la configuration
de la définition du processus en cours d’exécution.
2. EAI dynamique : La liaison entre les services des applications se fait en cours
d’exécution selon des règles spéciales. La configuration des interfaces des services
peut alors être changée et de nouveaux systèmes peuvent être ajoutés.
L’implémentation de l’EAI :
Les solutions d’EAI sont généralement appuyées sur des infrastructures propriétaires par
exemple : TIBCO Business Works de l’éditeur Business Works et BEA WebLogic
Integration de l’éditeur WebLogic. Mais depuis la spécification de standards dans la plate-
8
Processus Métier

26
forme J2EE9
, telle que la définition de JMS10
, qui définit une interface d’accès standard
en Java pour les MOMs11
, par Sun et ses partenaires.
Ces solutions d’EAI reposent généralement sur l’utilisation d’une infrastructure
d’intégration dédiée qui gère la communication et les échanges des applications au lieu
de communications directes entre applications, aussi appelée un bus de communication.
Une des couches techniques d’une solution EAI est l’infrastructure de communication,
très souvent implantée en utilisant des MOMs. Ce choix s’explique par le fait que les
MOMs favorisent le découplage entre applications qui est un moyen de garantir qu’il n’y
ait pas de conséquence au niveau du fonctionnement du système, lors de l’ajout ou du
retrait d’une application (les applications sont en quelque sorte autonomes).
(IBM Software Group Allemagne Norbert Bieberstein. Sogeti Pays-Bas Martin van den
Berg. Sogeti USA Erik van Ommeren)
II.5.3 L’intégration au niveau de processus métiers (Business process integration) :
L'intégration des processus métiers présente le système d'information d'entreprise à
l'échelle estimée, avec des exigences claires sur le soutien technologique moderne. Cela
signifie que les interfaces des systèmes
d'information seront fondées sur une nouvelle
architecture conçue. Cependant, les
fonctionnalités ne sont pas remises en œuvre,
mais plutôt en utilisant les applications
existantes. Ces applications existantes sont
transformées d'une manière { ce qu’elles
exposent leurs fonctionnalités du processus de
couche métier et l'architecture d'application
moderne qui sera utilisée. Enfin, les différentes
pièces sont collées ensemble, généralement au
moyen d'une modélisation des processus
métiers et la langue d'exécution, tels que
BPEL12
, comme indiqué dans la figure.
SOA, BPEL, et les technologies connexes
offrent aujourd'hui de nouvelles opportunités pour faire des systèmes d'information
intégrés, plus flexibles et adaptable aux changements des processus métiers.
9
Java 2 Enterprise Edition
10
Java Message Service
11
Message-Oriented Middleware
12
Business Process Execution Language
Figure 13:Modélisation des processus métiers

27
De cette façon, nos systèmes d'information peuvent obtenir plus d’agilité, fournir un
meilleur support pour l'évolution des besoins, s'aligner plus aux besoins des entreprises.
Cette opération est souvent liée à la réingénierie des processus métiers et n'est pas
seulement un problème technique.
II.5.4 L’intégration au niveau Présentation (Presentation integration) :
Souvent, après la réalisation de l'intégration des processus métiers, on continue avec
l'intégration au niveau présentatif. A ce niveau les applications existantes doivent être
rénovées et encapsulées sur le niveau intermédiaire, où ils exposent leurs services par le
biais des interfaces de haut niveau, il devient vital que l'utilisateur bénéficie d'une vue
unifié du système d'information.
L’intégration des résultats du système intégré dans la présentation doit permettre aux
utilisateurs d’accéder aux fonctionnalités de ce système. Sans qu’ils aperçoivent la
diversité des applications existantes qui sont en arrière-plan d'exécution.
Ceci grâce à des interfaces communes, fournis par la couche métier, développé dans la
phase d'intégration des processus métiers. Par conséquent, la couche de présentation est
découplée et elle cache les détails des applications existantes.
L’intégration est considérée comme une étape de présentation dans laquelle, une
interface utilisateur commune est définie est mise en œuvre, généralement elle sera un
portail pour le système multi-niveaux d’informations de l'entreprise, de telle sorte { ce
que l'interface utilisateur donnera l'illusion d'un nouveau système, et d'ajouter la pièce
manquante à l'architecture d'intégration multi-niveaux.
II.6 Conclusion :
À la fin de ce chapitre, on peut dire que l’intégration signifie : faire évoluer le
système informatique existant à travers de nouvelles applications, processus métier,
etc… ce n’est pas toujours facile { le faire c’est pourquoi toute l’entreprise doit être
inclue dans un tel projet.
Un projet d’intégration passe par les types d’intégration suivants : intégration au
niveau de données, intégration applicative, intégration des processus métier et
intégration au niveau présentation, et avant de mettre en place un tel travail, des tests
sont fait afin de garantir le bon fonctionnement du système rénové.
C’est étapes d’intégration s’incluent eux même dans une architecture orientée
service, où deux solutions sont possibles soit une intégration décentralisée qui est le cas
le plus répandu lors d’un projet SOA sur des sites géographiquement éloigné, soit avec
une intégration centralisé.
N.B : On optera pour l’intégration décentralisée vue qu’elle répond au juste { notre cas
d’étude, où le système n’est pas déj{ structuré en couches de services, comme il est le cas
pour l’intégration centralisée.

28
Chapitre❸
L’Architecture Orientée
Service

Chapitre 3 : L’Architecture Orientée Service
29
Chapitre 3 : Architecture Orientée Service
III.1 Introduction :
Service-Oriented Architecture est l'une des grandes tendances des architectures
informatique dans l’entreprise de notre temps, elle est devenue à la mode au début 2005
grâce aux succès du déploiement de l'Internet dans le public et dans les entreprises.
De nombreuses organisations et entreprises sont attirées par l'agilité, réduction
des coûts et l’amélioration de la qualité des opérations que la SOA présente, par le biais
de certains concepts tels que le couplage lâche, la réutilisation, l'encapsulation et
l'interopérabilité.
L’architecture SOA peut ajouter une valeur commerciale réelle aux entreprises en
mettant en œuvre une couche de services qui permettra de placer et de modifier
rapidement des processus métiers, sans avoir à faire de modifications difficiles et
coûteuses sur les systèmes opérationnels. Adopter une SOA dans une entreprise est un
défi sérieux qui exigera des efforts importants à différents niveaux, du commerce à
l'infrastructure IT.
L’objectif de cette partie est de chercher en claire ce qui se cache derrière les trois
lettres du mot « SOA », en présentant ses concepts clefs tels que le concept de services,
en mettant en évidence la relation qui doit s’établir entre les clients des services et les
fournisseurs.
III.2 Définitions :
Le concept « SOA », bien qu’il soit apparu pour la première fois il y a plus de dix ans, ne
trouve pas encore une définition homogène. Les groupes de recherche dans le domaine
de l’informatique et les concepteurs d’architecture orientée service (par exemple IBM,
Gartner ou Microsoft), suite { des petites différences dans les modèles d’architecture
SOA qu’ils ont développés, ont créé chacune leur définition du concept, toutes similaires
mais pas identiques, ci-après on va donner quelques définitions différentes qui
permettent d’éclairer ce concept :
Voici une définition donnée par le groupe Gartner, Inc., fondée en 1979, qui est une
entreprise américaine de conseil et de recherche dans le domaine de la technologie.
Définition 1 :« L’architecture orientée service constitue un style d’architecture basée sur le
principe de séparation de l’activité métier en une série de services, Ces services peuvent être
assemblés et liés entre eux selon le principe de couplage lâche pour exécuter l’application
désirée, ces services sont définis à un niveau supérieur de la traditionnelle approche
composants » (Gartner Group, 2005)

Chapitre 3 : L’Architecture Orientée Service
30
Ce concept d’architecture met { dispositions les fonctionnalités et les technologies de
l’entreprise sous forme de services, qui sont accessibles par les utilisateurs { travers une
interface standard.
Une définition plus complète, avec plus de détail, donnée par Stefan Hack, Markus
Lindemann:
Définition 2 : « La SOA est une approche de développement de systèmes d’information
définie par des standards d’architectures, qui permettent une évolution progressive des
systèmes d’information. Le but de ces standards est d’augmenter la flexibilité, la
réutilisation et l’interopérabilité des composants du système. Pour atteindre ces buts la SOA
utilise comme composante principale les services. Ceux-ci, permettent de répondre bien aux
changements auxquelles les entreprises sont soumises » (Hack & Lindemann, 2008)
Mais, on peut aussi dire que l'architecture orientée-service est une évolution normale de
l'architecture client-serveur en conjonction avec le domaine des systèmes distribués. Mais
c'est avant tout une solution au problème de l'intégration des systèmes. Il est important
de comprendre que l'AOS n'est pas une technologie, mais bien une approche
architecturale pour la création et l’implémentation de systèmes d’information flexibles et
biens adaptables aux changements des besoins des entreprises.
L'objectif est de décomposer les fonctionnalités de l’entreprise dans un ensemble de
fonctions basiques, les services justement, et de décrire finement le schéma d'interaction
entre ces services (Carter, 2008)dans le cadre d’un processus métier. Les services seront
ensuite développés et déployés sous forme de composants logiciels indépendants. Ainsi,
ce type d’architecture offre plus de flexibilité et d’adaptabilité, et permet une intégration
plus facile des processus grâce à des services faiblement reliés entre eux. La SOA est pour
ce motif définie des applications composées (Hack & Lindemann, 2008).
La finalité de ce type d’architecture est de supprimer la construction d’applications
lourdes incapables de supporter une logique métier en évolution. Idéalement,
l’encapsulation de chaque service doit garantir sa réutilisabilité et son interopérabilité.
Finalement, l’avantage le plus appréciable du « service » est la facilité d’évolution de
l’ensemble dans lequel il s’inscrit.
Plusieurs modèles de SOA ont été créés par les principales entreprises informatiques du
monde (IBM, Microsoft, SAP, Oracle,….), qui présentent des petites différences au niveau
de la complexité des services qu’ils offrent.
III.3 Avantages de la SOA :
Une architecture orientée services permet d'obtenir tous les avantages d'une
architecture client-serveur et notamment (Drapeau, 2009) :
 Une modularité permettant de remplacer facilement un composant (service) par un
autre.

PFE SOA TOYOTA ALGERIE

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (6)

Similar a PFE SOA TOYOTA ALGERIE

Similar a PFE SOA TOYOTA ALGERIE (20)

PFE SOA TOYOTA ALGERIE