PFE SOA TOYOTA ALGERIE

242 vues

Publié le

Projet de fin d'études

Publié dans : Technologie
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

PFE SOA TOYOTA ALGERIE

  1. 1. © 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
  2. 2. ‫الشــــــــعبية‬ ‫الديمــــــــقراطيـــــــة‬ ‫الجـــــــــزائريــــــة‬ ‫الجـمــــهوريــــــــــة‬ 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
  3. 3. 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.
  4. 4. 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 »
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. VIII ‫ّص‬‫خ‬‫مل‬: ‫يوات‬‫و‬‫ث‬‫ائر‬‫ز‬‫اجل‬‫يه‬‫غضو‬‫يف‬‫مجموػة‬‫غبدانلعيف‬‫مجيل‬‫متؼددة‬،‫يات‬‫اجلنس‬‫وشاظيا‬‫ئييس‬‫ر‬‫ام‬‫ىو‬‫بيع‬‫ات‬‫ر‬‫يا‬‫امس‬‫وكعع‬،‫امغيار‬‫كام‬‫ر‬ّ‫ف‬‫ثو‬‫يضا‬‫أ‬ ‫خدمات‬‫ما‬‫بؼد‬‫بيع‬‫م‬‫ا‬‫ملاػدة‬‫اسؼة‬‫و‬‫من‬‫امزابئن‬.‫يوات‬‫و‬‫ث‬‫ائر‬‫ز‬‫اجل‬‫ثتكون‬‫من‬‫مخس‬‫فروع‬‫متطةل‬(‫ائر‬‫ز‬‫اجل‬،‫امؼامصة‬‫ان‬‫ر‬‫وى‬)...‫؛‬‫لك‬‫فرع‬ ‫يدير‬‫ارده‬‫و‬‫م‬‫اخلاضة‬‫شعتو‬‫و‬‫أ‬‫و‬،‫احمللية‬‫يف‬‫بكة‬‫ش‬‫ثوزيع‬‫ثضم‬‫كرث‬‫أ‬‫من‬36‫متؼامل‬‫منترشة‬‫ػىل‬‫امطؼيد‬‫اموظين‬. ‫يوات‬‫و‬‫ث‬‫ائر‬‫ز‬‫اجل‬‫متتكل‬‫برانمج‬‫دارة‬‫ا‬(‫ختعيط‬‫ارد‬‫و‬‫م‬‫املؤسسات‬)،‫واذلي‬‫يتضمن‬‫مجيع‬‫وظائفو‬‫يف‬‫ائر‬‫ز‬‫اجل‬‫امؼا‬‫مصة‬(‫هظام‬‫مركزي‬)،‫مبا‬‫يف‬ ‫ذكل‬‫معلية‬‫بيع‬‫م‬‫ا‬.‫حنن‬‫هتحدث‬‫غن‬‫بيئة‬،‫موزػة‬‫مكن‬‫و‬‫غري‬‫وسة‬‫ا‬‫متج‬‫من‬‫حيث‬‫دارة‬‫ال‬‫ية‬‫ز‬‫املرك‬.‫يف‬‫مثل‬‫ىذه‬،‫امبيئة‬‫حتسني‬‫الثطال‬ ‫وػالجات‬‫امن‬‫زت‬‫ام‬(‫سري‬‫امؼمل‬)،‫بطفة‬‫جمردة‬‫و‬،‫يعة‬‫بس‬‫َّل‬‫ث‬‫م‬‫دامئا‬‫مشالك‬‫يطؼب‬‫امتؼامل‬‫مؼو‬. ‫تحسني‬‫م‬‫معلية‬‫بيع‬‫م‬‫ا‬،‫احلامية‬‫يوات‬‫و‬‫ث‬‫ائر‬‫ز‬‫اجل‬‫يد‬‫ر‬‫ت‬‫ثطممي‬‫اجناز‬‫و‬،‫حل‬‫استنادا‬‫ىل‬‫ا‬‫ىندسة‬‫برجميات‬،‫موزػة‬‫ثتغلب‬‫ػىل‬‫امبؼد‬‫ايف‬‫ر‬‫اجلغ‬ ،‫نلفروع‬‫مع‬‫احملافظة‬‫ػىل‬‫ات‬‫زي‬‫امل‬‫بة‬‫املكتس‬‫من‬‫برانمج‬‫دارة‬‫ا‬‫غامل‬‫ال‬.‫هبدف‬‫ن‬‫أ‬‫يتحطل‬‫تخدم‬‫املس‬‫ػىل‬‫خدمات‬‫يوات‬‫و‬‫ث‬‫ائر‬‫ز‬‫اجل‬ِ‫ر‬‫ملؼ‬‫ا‬‫وضة‬ ‫ػرب‬‫هت‬‫رت‬‫ه‬‫ال‬. ‫من‬‫بني‬‫امبنيات‬‫امربجمية‬‫اميت‬‫ثؼاجل‬‫ىذه‬،‫املشلكة‬‫امبنية‬‫متؼددة‬‫اخلدمات‬‫ثلدم‬‫حال‬‫تلال‬‫مس‬‫غن‬‫م‬ ُ‫ُظ‬‫ه‬‫شغيل‬‫مت‬‫ا‬‫و‬‫مغات‬ِ‫رب‬‫ام‬،‫جمة‬‫مع‬ ‫تجابة‬‫الاس‬‫مرشوط‬‫دارة‬‫ال‬،‫املوزػة‬‫وضامن‬‫كدر‬‫كرب‬‫أ‬‫من‬‫هة‬‫و‬‫املر‬‫يف‬‫هظام‬‫املؼلومات‬.‫امؼنرص‬‫سايس‬‫ال‬‫ميذه‬‫امبنية‬‫ىو‬"‫اخلدمة‬"‫اميت‬ ‫ػادة‬‫ما‬‫ُنجز‬‫ث‬‫غن‬‫يق‬‫ر‬‫ظ‬‫خدمات‬‫يب‬‫و‬‫ام‬. ‫املوضوع‬‫ئييس‬‫ر‬‫ام‬‫ميذا‬‫امؼمل‬‫ىو‬‫ثطممي‬‫اجناز‬‫و‬‫حل‬‫ن‬ِّ‫ك‬َ‫م‬ُ‫ي‬‫تخدم‬‫املس‬‫من‬‫احلطول‬‫ػىل‬‫خدمات‬‫يوات‬‫و‬‫ث‬‫ائر‬‫ز‬‫اجل‬‫اميت‬‫سيمت‬‫ثوفريىا‬‫ػرب‬ ‫هت‬‫رت‬‫ه‬‫ال‬,‫مع‬‫خفاء‬‫ا‬‫ثؼليدات‬‫امبنية‬‫املوزػة‬. ‫لكامت‬‫امبحث‬:‫امؼمليات‬،‫ميية‬‫تنظ‬‫م‬‫ا‬‫امبنية‬‫متؼددة‬،‫اخلدمات‬‫اخلدمات‬‫بكية‬‫امش‬(‫يب‬‫و‬‫ام‬)،‫دماج‬‫ال‬
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. © Boudekhani, Djellouli, 2012. INTRODUCTION GENERALE
  18. 18. 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.
  19. 19. Introduction générale 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
  20. 20. Introduction générale 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.
  21. 21. Introduction générale 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
  22. 22. 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.
  23. 23. 7 Chapitre❶ L’approche Processus
  24. 24. Chapitre 1 : L’approche processus 8 ... . Chapitre 1 : L’approche processus 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
  25. 25. Chapitre 1 : 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)
  26. 26. Chapitre 1 : L’approche processus 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.
  27. 27. Chapitre 1 : L’approche processus 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)
  28. 28. Chapitre 1 : L’approche processus 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
  29. 29. Chapitre 1 : L’approche processus 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)
  30. 30. Chapitre 1 : L’approche processus 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.
  31. 31. Chapitre 1 : L’approche processus 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
  32. 32. Chapitre 1 : L’approche processus 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.
  33. 33. Chapitre 1 : L’approche processus 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.
  34. 34. 18 Chapitre❷ L’intégration
  35. 35. Chapitre 2 : L’intégration 19 Chapitre 2 : L’intégration 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
  36. 36. Chapitre 2 : 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
  37. 37. Chapitre 2 : L’intégration 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».
  38. 38. Chapitre 2 : L’intégration 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)
  39. 39. Chapitre 2 : L’intégration 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
  40. 40. Chapitre 2 : L’intégration 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)
  41. 41. Chapitre 2 : L’intégration 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
  42. 42. Chapitre 2 : L’intégration 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
  43. 43. Chapitre 2 : L’intégration 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.
  44. 44. 28 Chapitre❸ L’Architecture Orientée Service
  45. 45. 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)
  46. 46. 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.

×