SOA : L’utilité organisationnelle, technique et...La première partie met en lumière des concepts de la SOA en se référant à la littérature appropriée ainsi que sur des articles

Université de Fribourg, Suisse

Département d’informatique

Systèmes d’information

Dr. Hüsemann Stefan

SOA : L’utilité organisationnelle, technique et

financière de l’architecture orientée service

Emine Ulukütük

Impasse de la Forêt 24, 1700 Fribourg

No. d’étudiant : 10-215-523

Bachelor en Gestion d’Entreprise

Août 2013

Remerciements

Je tiens à remercier toutes les personnes m’ayant aidé et soutenu tout

au long de l’élaboration de ce mémoire de Bachelor.

Mes sincères remerciements vont tout d’abord à Monsieur le

Professeur Stefan Hüsemann, d’avoir accepté de superviser ce travail

et pour sa précieuse aide tant au niveau de son encadrement qu’au

niveau de sa disponibilité qu’il m’a accordé dans la réalisation de ce

travail.

Je souhaite également remercier les entreprises ayant participées à la

seconde partie et particulièrement mes interlocuteurs M. Philippe

Savary ainsi que le responsable informatique de la 2ème firme

analysée. Sans leur précieuse collaboration, la partie pratique de ce

travail n’aurait pas été possible.

Je tiens notamment à remercier Joel Rossier, étudiant-assistant

d’informatique à l’EPFL et particulièrement M. Philippe Savary pour

le temps qu’’ils ont consacré à la relecture de ce travail.

Enfin, j’adresse toute ma reconnaissance à ma famille, mes amis, mes

professeurs et toutes les personnes externes pour leur soutien tout au

long de ma formation universitaire à Fribourg, s’achevant sur ce

mémoire de Bachelor.

- 1 -

TABLE DES MATIÈRES

1. Introduction ................................................................................................................................... 1

1.1. Description du thème ................................................................................................................. 1

1.2. Objectifs et questions centrales du travail ......................................................................... 2

1.3. Méthodologie et structure du travail ................................................................................... 4

2. Qu’est-ce qu’une architecture orientée service ? ............................................................. 5

2.1. Notion de base ............................................................................................................................... 5

2.1.1. Le système d’information ............................................................................................... 5

2.1.2. L’architecture informatique ............................................................................................ 7

2.2. Concept de l’architecture orientée service ........................................................................ 7

2.2.1. Histoire des systèmes d’informations .......................................................................... 7

2.2.2. L’entreprise orientée service : nécessité du SOA ...................................................10

2.2.3. L’architecture orientée service ....................................................................................12

2.2.4. Composantes et principes de base ..............................................................................17

3. L’impact d’une architecture orientée service dans l’entreprise .............................. 25

3.1. D’un point de vue technique et financier ......................................................................... 26

3.1.1. Méthodologie à suivre pour implémenter une SOA .............................................26

3.1.2. Coûts de l’approche ...........................................................................................................30

- 2 -

3.2. D’un point de vue opérationnel et stratégique .............................................................. 33

3.2.1. Changement dans l’organisation ................................................................................33

3.2.2. Attentes de cette approche ............................................................................................34

4. Avantages de l’architecture orientée service .................................................................. 35

4.1. Au niveau organisationnel : la flexibilité du système ................................................. 35

4.2. Au niveau technique : la réutilisabilité des ressources .............................................. 37

4.3. Au niveau financier : la baisse des coûts .......................................................................... 39

5. Etudes de cas ............................................................................................................................... 43

5.1. Office de la Circulation et de la Navigation du canton de Fribourg ....................... 45

5.1.1. Portrait de l’organisation ..............................................................................................45

5.1.2. Présentation du système informatique de l’établissement ..............................46

5.1.3. Description du projet SOA et dans son évolution au fil du temps .................48

5.1.4. Objectifs visés par l’adoption de SOA et grille d’auto-évaluation sur les

attentes et les réalités de SOA ..................................................................................................51

5.1.5. L’utilité réelle de SOA dans l’entreprise ...................................................................54

5.2. Grande compagnie d’assurance ........................................................................................... 56

5.2.1. Présentation de la firme .................................................................................................56

5.2.2. Objectifs visés par l’introduction de SOA .................................................................56

5.2.3. Description de la démarche SOA et dans son évolution au fil du temps .....58

5.2.4. Grille d’auto-évaluation sur les attentes et les réalités de SOA ......................61

- 3 -

5.2.5. L’utilité réelle de SOA dans l’entreprise ...................................................................63

6. Résultats des études de cas : La réalité du SOA .............................................................. 65

6.1. Les avantages de SOA .............................................................................................................. 65

6.2. Les lacunes de SOA ................................................................................................................... 67

6.3. Analyse globale de l’utilité de SOA ..................................................................................... 69

7. Conclusion ................................................................................................................................... 71

8. Bibliographie .............................................................................................................................. 72

8.1. Littérature .................................................................................................................................... 72

8.2. Articles, documents, présentations .................................................................................... 73

8.3. Webographie .............................................................................................................................. 75

9. Annexes ........................................................................................................................................ 77

Annexe 1: « SOA Infrastructures Costs » .................................................................................. 77

- 4 -

TABLE DES FIGURES

Figure 2-1: Historique du SI ....................................................................................................................... 9

Figure 2-2: Fonctionnement en silo des SI ........................................................................................ 11

Figure 2-3: Architecture traditionnelle vs SOA. .............................................................................. 14

Figure 2-4: Architecture de base SOA ................................................................................................. 15

Figure 2-5: Entreprise Service Bus ...................................................................................................... 16

Figure 2-6: SOA, liaison entre vue métier et vue technique ....................................................... 18

Figure 2-7: Composition et interopérabilité ..................................................................................... 22

Figure 2-8 : Le couplage faible entre consommateurs et logique métier .............................. 24

Figure 3-1: Phase de la démarche SOA ............................................................................................... 27

Figure 3-2: Stratégie d'intégration ....................................................................................................... 29

Figure 3-3: Comparaison de la structure des coûts des technologies de l’information

d'une approche traditionnelle et d'une SOA ...................................................................................... 32

Figure 4-1: Motifs de choix lors de l'adoption de démarche SOA ............................................ 37

Figure 4-2 : Principales attentes des entreprises d'une démarche SOA ................................ 39

Figure 4-3: Investissement initial et rendement à long terme des capitaux investis ....... 40

Figure 5-1: Fonctionnement du logiciel CARI .................................................................................. 46

Figure 5-2: Paysage applicatif de l'OCN.............................................................................................. 47

Figure 5-3: Architecture des services en relation avec les activités d'assurance .............. 50

Figure 5-4 : Grille d'évaluation des attentes et des réalités du SOA de l'OCN ..................... 52

Figure 5-5: Grille d'évaluation des attentes et des réalités du SOA de la compagnie

d'assurance ..................................................................................................................................................... 61

1 1. Introduction

1. Introduction

Nous vivons actuellement dans une société de consommation orientée vers la

technologie. Cette dernière est présente dans la vie de tous les jours autant pour les

particuliers que pour les entreprises. Un des concepts clé de cette mutation

technologique est l’informatique, qui est devenu un des piliers d’une bonne gestion

organisationnelle. Toutes questions relatives à la communication et à la gestion

d’entreprise relèvent des systèmes d’information dans la plus grande partie des

firmes, surtout actuellement alors qu’on se situe dans une économie de l’information.

Il est primordial pour chaque firme de savoir gérer ces multitudes d’informations et

d’activités, d’une manière organisée. Le système d’informations s’avère être la

solution idéale pour remédier à ce besoin, et permet également à chaque firme de se

démarquer de la concurrence en gagnant des avantages compétitifs.

Les évolutions perpétuelles que connait l’informatique de gestion, alliées au besoin

grandissant de flexibilité des entreprises, rendent le thème des systèmes

d’informations toujours plus intéressant et actuel dans la gestion d’entreprise. Basé

sur ce fait, ce travail de Bachelor tente de connaître la réelle utilité que procure

l’implémentation d’un SI via une architecture orientée service.

1.1. Description du thème

Aujourd’hui, nous vivons dans une société de consommation orientée technologie,

dans laquelle l’échange d’information est primordial. Du point de vue de l’entreprise,

cela implique une bonne gestion des activités ainsi qu’une bonne communication au

sein de toute l’organisation. Chaque entreprise doit se mettre à jour continuellement

afin de suivre l’évolution des technologies de mondialisation et de globalisation qui

rendent la concurrence toujours plus féroce. Dans cette logique, les firmes doivent

s’adapter à ce contexte en étant toujours plus performantes et flexibles afin de

réaliser leurs objectifs et se démarquer de la concurrence.

2 1. Introduction

D’un point de vue informatique, une des méthodes d’amélioration du fonctionnement

de l’organisation au sein d’une firme sont les systèmes d’informations (SI) qui

permettent une meilleure communication, circulation et coordination des données au

sein de l’entreprise. Toutefois, ces systèmes relèvent d’une complexité considérable

au niveau de la structuration et engendrent des coûts élevés pour l’entreprise.

Afin de pallier à ces problèmes, il existe une architecture de conception et

d’implémentation de SI, nommé architecture orientée service (SOA) qui s’avère être

une solution adéquate. Le but de ce travail est de comprendre si ce type

d’architecture SOA répond réellement aux attentes des entreprises qui l’adoptent

comme elle est censée le faire.

1.2. Objectifs et questions centrales du travail

L’objectif principal de ce travail est d’expliciter l’architecture orientée services d’un

point de vue technique, organisationnel et financier et d’en connaître la réelle utilité

pour les entreprises, compte tenu de l’évolution constante des technologies

informatiques.

Dans un premier temps, on étudiera l’approche SOA d’un point de vue théorique tout

en explicitant cette notion, son impact dans les organisations l’adoptant ainsi que les

défis relevés par ce type d’architecture.

La deuxième partie de ce travail sera dédiée à l’étude de deux entreprises afin de

comprendre dans quelles mesures SOA comblent les attentes de celles-ci. De plus,

ces études vont permettre de comprendre quels sont les objectifs visés et les

attentes des entreprises quant à l’implémentation de la SOA.

Tout au long de la lecture de ce mémoire, le lecteur pourra récolter diverses

réponses aux questions suivantes :

Dans la première partie dédiée à l’aspect théorique de la SOA, nous nous poserons

les questions suivantes :

3 1. Introduction

Qu’est-ce qu’une architecture orientée service ?

Quel est l’impact d’une SOA sur les entreprises ?

Quelles sont les défis des SOA?

Afin de répondre à ces questions, nous puiserons des informations dans la littérature

adéquate et expliciterons les termes de système d’informations et d’architecture

informatique. Nous analyserons également l’impact et les défis relevés par les SOA

d’un point de vue technique, organisationnel et financier.

A la suite de ces notions de base, nous nous intéresserons davantage à l’aspect

pratique de la SOA, en présentant deux entreprises ayant implémenté l’architecture

orientée service grâce à diverses questions faisant référence au début de

l’implémentation SOA, telles que :

Quelles étaient les attentes des firmes au début de l’implémentation de

la SOA ?

Quels étaient les objectifs poursuivis par la mise en place de cette

approche ?

Quelle était l’utilité des SOA pour votre entreprise ?

Ensuite une autre série de questions sera discutée afin de voir si SOA a réellement

pu répondre aux attentes des entreprises, telles que :

Quelle est l’utilité des SOA pour votre entreprise ?

SOA tient-elle ses promesses au niveau de la performance ? Répond-t-

elle réellement aux attentes ?

Quelles sont les lacunes à combler dans cette approche ?

Pour compléter la partie pratique, une analyse globale de la SOA sera réalisée pour

évaluer les avantages et les lacunes de SOA dans l’utilisation pratique de cette

architecture.

4 1. Introduction

1.3. Méthodologie et structure du travail

Ce mémoire de Bachelor est divisé en deux grandes parties : une partie théorique

basée sur un travail de recherche et une partie pratique axée sur des entretiens et

interviews réalisés avec des tiers.

La première partie met en lumière des concepts de la SOA en se référant à la

littérature appropriée ainsi que sur des articles scientifiques, des sites web et sur le

cours de Systèmes d’Informations donné par le Professeur Hüsemann.

La seconde partie, quant à elle, est orientée pratique et va soulever les questions

relevant de l’utilisation de la SOA dans plusieurs firmes. Ceci est réalisé grâce à des

études de cas sur la base d’entretiens et de questionnaires afin de connaître les

réels avantages et inconvénients émanant de l’implémentation de la SOA.

Le chapitre 2 explicite les concepts théoriques de la SOA par l’explication de la

notion de SOA, ses principes et ses composantes ainsi que des défis poursuivis par

cette architecture.

L’impact d’une architecture orientée service au sein d’une organisation est discutée

de manière détaillée dans le chapitre 3. Cet impact est analysé d’un point de vue

technique ainsi que d’un point de vue opérationnel et stratégique.

Le chapitre 4 s’intéresse plus particulièrement aux avantages émanant de la mise en

place d’une telle architecture en se focalisant sur trois angles spécifiques à savoir la

technique, l’organisation et les finances de la firme. Ce chapitre permet de

comprendre pourquoi, comment et sous quelles contraintes financières, la SOA fait

partie du système d’information de l’entreprise.

Le chapitre 5 traite des études de cas de deux firmes, permettant ainsi de

comprendre l’utilité et l’impact d’une SOA dans la pratique en présentant le projet

SOA et les objectifs poursuivis par la mise en place de ce projet. Sur la base de ces

études de cas, une étude sera réalisée sur la réalité du SOA en discutant des

avantages et des lacunes de SOA dans le chapitre 6.

Enfin, ce mémoire s’achève sur une synthèse en récapitulant les principales

réponses émanant de ce travail de recherche.

5 2. Qu’est-ce qu’une architecture orientée service ?

2. Qu’est-ce qu’une architecture orientée service ?

Ce chapitre explicite les principales notions de base qu’englobe l’architecture

orientée service. Il pose les principes de base théorique de ce type d’architecture.

Les questions qui vont être résolus dans ce chapitre sont les suivantes :

Qu’est-ce que un système d’informations ?

Qu’est-ce qu’une architecture orientée service ?

Le premier sous-chapitre va introduire la notion de système d’informations et

d’architecture informatique afin de faciliter la compréhension de ce mémoire.

Par la suite, un bref historique de l’avènement du SOA sera discuté dans le second

sous-chapitre. Nous tenterons également de comprendre la place qu’occupent les

systèmes d’informations dans les entreprises actuellement et les raisons pour

lesquelles une architecture adéquate est primordiale au bon fonctionnement des SI.

Enfin, dans la dernière partie de ce chapitre, une description détaillée de SOA suivra

via la présentation des composantes de cette architecture.

2.1. Notion de base

2.1.1. Le système d’informations

Le système d’informations est une notion très vaste et très complexe dans le jargon

informatique dans la mesure où elle englobe passablement d’éléments. Il existe de

multiples définitions dans la littérature informatique qui se complètent les unes et les

autres.

Le système d’informations est un système indispensable pour une bonne gestion

d’organisation dans la mesure où le traitement de l’information est une activité

incontournable dans les entreprises modernes. Les activités de gestion relèvent


toutes du traitement et de l’utilisation de l’information comme par exemple tenir une

comptabilité, construire des plans de budgets, gérer la relation client, faire des

prévisions pour les trimestres futures, surveiller la production, etc. Toutes ces

activités sont réalisées par la manipulation d’applications et de composantes sur la

base d’informations gérées par des systèmes informatiques.

Les systèmes d’informations sont apparus vers la fin des années soixante dans le

but d’automatiser des travaux d’ordres administratifs, opérationnelles, de gestion et

d’informatique [Grenier, Moine 2003, p.8-9]. L’idée centrale émanant de toutes les

définitions que l’on peut lire dans la littérature informatique est de définir le SI comme

un outil informatique facilitant la gestion des fonctionnalités des entreprises.

Afin de comprendre cette notion, il est important de bien comprendre les deux sujets

la constituant : le système et l’information.

Un système est une totalité organisée et identifiable, plus ou moins complexe,

regroupant des sous-systèmes reliés entre eux et ayant un but commun. Il

permet l’action, la prise de décision et la mémorisation des informations

[Hüsemann 2011].

L’information est définie comme une représentation des « données

transformées sous une forme significative pour la personne qui les reçoit ; elle

a une valeur réelle (ou perçue) pour ses décisions et ses actions » [Gordon,

Olson, Ajenstat, Peaucelle 1986, p. 116].

Le système d’information peut ainsi être défini comme « un ensemble organisé de

méthodes et de moyens humains et matériels destinés à collecter, mémoriser et

transmettre les différents types de données nécessaires au fonctionnement d’une

entreprise » [Grenier, Moine, 2003, p. 10].

Les principaux objectifs poursuivis par l’implémentation d’un système d’informations,

sont l’accès rapide et généralisé à l’information que ce soit à l’interne ou à l’externe,

de travailler avec un système ouvert et interactif avec l’extérieur, le développement

rapide d’applications ainsi que la possibilité d’une administration simplifiée [Ben Driss

Khaled, 2007].


2.1.2. L’architecture informatique

L’architecture informatique est à la base de tout système d’information : elle va le

structurer et l’organiser par des fonctionnalités, des attributs et des composantes qui

sont reliés entre eux. Dans cette logique, les composantes sont modélisées, les

relations sont décrites et les attributs documentés [Hüsemann 2010]. Ainsi,

l’architecture informatique va définir les règles nécessaires à la construction et à

l’implémentation du SI. Dans la littérature informatique, une architecture software est

définie telle que « a set of statements that describes software components and

assigns the functionality of the system to these components. » [Krafzig, Banke,

Slama 2006, p. 56].

Pour structurer les SI, il est nécessaire d’utiliser des architectures d’intégration qui

permettent de couvrir tous les besoins avec une application construite de manière

intégrée. Nous pouvons citer en exemple les Progiciels de Gestion Intégrés

ERP/PGI, les Portails Web, les Data Warehousing et les Architectures Orientées

Services SOA. Dans ce travail, nous allons nous concentrer sur la dernière

architecture d’intégration, la SOA.

En somme, une architecture informatique doit décrire de manière précise tous les

éléments constitutifs du SI afin de comprendre ce système ayant comme tâche

principale le traitement d’informations de manière flexible.

2.2. Concept de l’architecture orientée service

2.2.1. Histoire des systèmes d’informations

Afin de comprendre l’émergence de cette nouvelle architecture software dans les

années 1996, il est intéressant de tracer l’évolution des systèmes d’informations

dans les technologies informatiques.

Nous pouvons diviser l’histoire des systèmes d’informations en quatre grandes

phases selon les auteurs Fournier-Morel, Grojean, Plouin et Rognon [Fournier-Morel,

Grosjean, Plouin, Rognon 2011, p. 3-7].


La première phase consiste à la période où le système informatique des entreprises

était concentré et géré par un serveur unique appelé le mainframe. Ce type de

serveur a l’apparence d’un ordinateur central qui gère l’ensemble de l’information

circulant dans l’entreprise. Ce type d’architecture était extrêmement centralisé

nécessitant le déplacement physique en vue de l’utiliser. En dépit des coûts

d’acquisition et d’exploitation exorbitants, le mainframe était un système cohérent et

fiable procurant des services tels que l’intégrité des données et une très haute

disponibilité des informations.

Ensuite avec le progrès technique et le développement des réseaux informatiques

(et des protocoles associés) reliant les machines hétérogènes permettent

l’apparition des systèmes client/serveur. Ce type d’architecture permet de transférer

les composantes d’interfaces sur les postes de travail tout en conservant les

serveurs. Ces nouvelles applications s’intègrent dans de nombreuses entreprises

grâce aux faibles coûts qu’elles engendrent. Les SI deviennent incontournables au

sein des entreprises. Plus l’informatique devient présente dans l’entreprise, plus des

problèmes de gestion de l’information se posent. En effet, avec l’avènement

informatique, tous types de profils d’une organisation sont confrontés à l’utilisation

des SI sans avoir une formation particulière dans cette branche. On observe alors

une mauvaise gestion de l’information : des duplications, des redondances, des

erreurs ainsi qu’une absence de communication entre les divers départements

apparaissent dans le système. Ceci crée des incohérences dans les fonctionnalités

des SI mais aussi une complexité non gérable par des utilisateurs lambda.

C’est alors que vers la fin des années 90, les limites du client/serveur ont été

atteintes à la suite de nombreux problèmes émanant de cette architecture. On a pu

constater l’émergence d’un nouveau type architectural : les applications web qui

permettent de se connecter aux processus métier de l’entreprise par un simple

navigateur. Ainsi on permet aux clients et aux fournisseurs de s’intégrer dans le parc

informatique de l’organisation et tout ceci à moindre coût. Les applications web

favorisent également le développement du commerce électronique et offrent ainsi

aux firmes des avantages concurrentiels.

Dans les années 2000, une toutes nouvelle tendance dans les technologies des TIC

a fait son apparition : le Cloud computing qui s’avère être une opportunité importante


pour toutes les firmes souhaitant externaliser leur système informatique. Il consiste à

déléguer la gestion de l’informatique d’entreprise à des entités et des personnes

externes, qui sont spécialisées dans le domaine. Tout cela se gère sur demande de

l’entreprise. Toutefois cela pose quelques problèmes en termes de sécurité pour des

données confidentielles ou encore une dépendance de la firme à des tiers étant

donné le manque de maîtrises à l’interne sur les questions d’ordre de sécurité

informatique.

Toutes ces évolutions, ayant contribué au développement des systèmes

d’informations sont illustrés par la figure 2-1. Chaque évolution s’intègre dans des

environnements complexes et devant gérer indépendamment de multiples

informations. De plus, l’informatique est dès lors fortement utilisée dans toutes les

entreprises et par de nombreux utilisateurs non spécialisés dans la branche. De ce

fait, la nécessité d’une nouvelle architecture accessible à l’utilisation de tous et

rationalisant la circulation des informations au sein de tout le système fut nécessaire.

Figure 2-1: Historique du SI [Fournier-Morel, Grosjean, Plouin, Rognon 2011, p. 6]


Le concept d’architecture orientée service, décrit la première fois par le groupe

américain de recherche en technologie Gartner Group en 1996, se présente comme

étant la solution adéquate à la demande actuelle des entreprises. Pour la première

fois, l’architecture orientée service fut définie comme « client/server software design

approach in which an application consists of software services and software service

consumers (also known as clients or service requesters). SOA differs from the more

general client/server model in its definitive emphasis on loose coupling between

software components, and in its use of separately standing interfaces » [Gartner

Group 2013].

2.2.2. L’entreprise orientée service : nécessité du SOA

L’activité principale d’une entreprise est la création de la valeur par le traitement de

l’information. Comme vu précédemment, une bonne utilisation de l’information dans

les activités de gestion va permettre de meilleurs résultats à l’entreprise. De plus, la

quantité d’information générée est si extraordinaire qu’elle dépasse les compétences

humaines et nécessite l’intervention des ordinateurs. C’est par la prise de conscience

de ce fait, que les entreprises ont intégré les systèmes d’informations dans leur

stratégie d’entreprise pour atteindre des objectifs d’optimisation de la performance.

Les systèmes d’information poursuivent trois objectifs par leur intégration dans

l’environnement de l’entreprise au niveau stratégique, tactique et opérationnel

[Hüsemann 2010] :

Objectif stratégique : le SI doit amener des renforcements au niveau des

avantages stratégiques de la firme, pour la différencier et lui octroyer des

avantages compétitifs vis-à-vis des concurrents.

Objectif tactique : à ce niveau, le SI doit être un outil d’aide à la décision.

Grace aux informations détenues par le système, les décideurs doivent

pouvoir choisir les solutions optimales en fonctions de la situation.

Objectif opérationnel : le SI doit pouvoir soutenir les processus d’entreprise

en les développant. Il doit également permettre une utilisation efficace des


ressources de l’entreprise dans le but d’atteindre les objectifs visés par celle-

ci.

L’introduction des systèmes d’informations dans le monde entrepreneurial a modifié

les techniques de gestion d’entreprise en procurant à ces derniers des opportunités

de développement remarquables. Nous avons pu observer des améliorations au

niveau du stockage des données, une fluidité dans la communication des

informations et une simplification dans les processus métiers [Bell, 2006, p. 29].

Pourtant avec l’évolution des technologies de l’information, les systèmes

d’informations construits sous formes d’applications indépendantes deviennent de

plus en plus rigides et de ce fait ne remplissent plus entièrement leur fonction

[Fournier-Morel, Grosjean, Plouin, Rognon 2011, p. 6]. L’entreprise étant

décomposée en plusieurs départements, correspondant à un silo du système

d’information comme dans la figure 2-2, les processus métiers y référants

nécessitent d’être multifonctionnels. En effet, chaque bloc du SI étant isolé en termes

de processus, d’intervenants humains ou matériels et d’interfaces, plusieurs

inconvénients apparaissent quant à l’impossibilité de réutilisation des composantes,

la duplication et les redondances d’objets, la difficulté de mettre en place des

processus métier transversaux, etc. [Fournier-Morel, Grosjean, Plouin, Rognon 2011,

p. 12 ] Le SI est alors confronté à de nouvelles exigences.

Figure 2-2: Fonctionnement en silo des SI [Ben Driss Khaled, 2007]


De plus, la mondialisation favorise la concurrence et fait évoluer les stratégies

d’entreprise qui se complexifient et induisent des changements dans le système.

L’intégration de ces changements dans les systèmes devient de plus en plus difficile

et provoque ainsi des désavantages concurrentiels pour les entreprises. Les

systèmes d’information sont alors dans l’obligation de s’adapter à ces changements

sans perdre de temps et sans engendrer des coûts supplémentaires.

Sur la base de ces faits, les entreprises ont pris conscience de la nécessité de

l’implémentation d’une architecture durable et structurée, capable de s’adapter à tout

changement par la réutilisation et la modification des services existants afin de

travailler. Les principales motivations sont la simplification et la suppression des

redondances dans les processus métiers, une bonne intégration et un meilleur

partage des informations grâce à une interface standardisée, et surtout un système

de gestion de l’information flexible [Holley, Dr. Arsanjani, 2011, p.43].

Parmi toutes les architectures de conception de SI, l’architecture orientée service

SOA est celle qui se rapproche des attentes des entreprises.

2.2.3. L’architecture orientée service

Le concept d’architecture orientée service-SOA, apparut déjà plus de 15 ans n’a

toujours pas de définition exacte et universelle. Cette approche a été développée par

diverses entreprises de recherche en informatique telles qu’IBM, BEA, Oracle ou

Microsoft qui ont chacun leur propre concept et leur propre définition de cette

architecture. Bien que toutes les définitions apparaissant dans la littérature se

ressemblent, elles comportent, chacune, des divergences. Voici quelques manières

de définir une SOA:

« SOA is a software architecture that is based on the key concepts of an

application frontend, service, service respository, and service bus.» [Krafzig,

Banke, Slama 2006, p. 57].


« Service-oriented Architecture (SOA) is an architectural design pattern that

concerns itself with defining loosely-coupled relationships between producers

and consumers. » [Wikipedia, 2013].

« A service-oriented architecture is essentially a collection of services. These

services communicate with each other. The communication can involve either

simple data passing or it could involve two or more services coordinating some

activity. Some means of connecting services to each other is needed. » [Barry,

Barry & Associates, 2013].

Sur la base de ces écrits, nous pouvons décrire la SOA, au niveau de la gestion

d’entreprise, comme une approche de conception et de construction de système

d’informations qui utilise des interfaces services pour la création de SI. Cette

architecture met à disposition des utilisateurs les fonctionnalités et les services

proposés par une entreprise, via une interface standardisée soit à l’interne soit sur

Internet (pour le e-commerce par exemple).

Cette architecture qui s’avère être un modèle d’intégration moderne a comme

principal objectif l’augmentation de la flexibilité, la réduction des coûts d’intégration,

la mise à disposition de services réutilisables, la modification et la réutilisation des

fonctionnalités ainsi que la composition des processus de gestion par l’utilisation de

services déjà existants ou à créer.

Grâce aux services modulaires interagissant entre eux, nous pouvons facilement

exécuter des processus et ainsi répondre aux demandes et aux besoins des

entreprises en matière de flexibilité. Nous pouvons observer dans la figure 2-3 la

différence entre avant et après une intégration SOA explicitantt clairement le concept

d’architecture organisé avec des relations structurées. L’approche SOA facilite la

gestion de l’interface entre les besoins métiers et l’implémentation technique.

L’interopérabilité des services fait de SOA, une approche d’intégration qui se définit

comme une application composée.


Figure 2-3: Architecture traditionnelle vs SOA [Hüsemann 2010].

Dans la littérature, cette conception est souvent présentée comme une approche

pour la refonte progressive des systèmes d’information afin de les rendre durables et

agiles [Bonnet, Detavernier, Vauquier 2008, p. 63]. La principale idée de cette

approche est de construire une architecture logicielle avec des services composés et

reliés entre eux, correspondant aux processus métiers de la firme. Contrairement aux

communications entre des objets hétérogènes comme à l’époque du client/serveur,

ce nouveau style d’architecture met en avant le concept de communication service

passant par des interfaces et masquant ainsi les objets. Le but étant de rendre les

systèmes d’informations aptes et flexibles aux changements qui pourraient apparaitre

par une modification de stratégie ou d’organisation par exemple. [Erl 2008, p. 38].

L’architecture orientée service est un style d’architecture moderne qui suit des

principes de modélisation modernes permettant la réutilisation des services ainsi que

l’exécution de processus d’entreprise. Elle est découpée en plusieurs couches


composée de manière générale d’une couche présentation, d’une couche métiers et

d’une couche données.

Les couches essentielles de ce type d’architecture sont aux nombres de quatre : le

système d’intégration, les services, les processus et l’interface. [Liebhart 2007, p.

67].

Figure 2-4: Architecture de base SOA [Microsoft Corporation 2009]

En commençant par le bas de la figure 2-4, la première couche nommée « couche

applications » se réfère au système d’intégration qui permet les liaisons entre les

données, les processus, les services, les bases de données ainsi que les

applications. Tous ces éléments sont liés par le système d’intégration, même s’ils

sont capables d’interagir directement entre eux.

La couche services correspond au deuxième niveau de l’architecture. Le service

étant un périmètre fonctionnel à caractère modulaire et autonome, représentent les

fonctionnalités d’un système qui sont exposés aux consommateurs par le biais d’une

interface. Étant donné, que ce composant met en relation direct l’entreprise avec les


consommateurs, la couche service a comme fonction principale la gestion de ces

services entres eux [Liebhart 2007, p. 26].

Les relations entre les services consommateurs dits consumer et les services

producteurs dits provider, peuvent être reliés par un Entreprise Service Bus, présenté

ci-dessous dans la figure 2-5. Cette technologie informatique, qui est l’une des

manières d’implémenter la SOA, permet l’interaction entre les applications à travers

les services. Il facilite ainsi l’échange entre l’entreprise et ses partenaires internes et

externes, plus précisément entre les services consommateurs et les services

producteurs en reliant les applications les unes aux autres [Michoud, Abissa

Informatique 2008].

Figure 2-5: Entreprise Service Bus [Michoud, Abissa Informatique 2008]

La troisième couche processus se réfère aux processus métiers du concept SOA, qui

consistent en des suites d’activités réalisées par les services afin d’apporter une

valeur ajoutée à l’entreprise. Ces activités, ayant comme fonction de décrire les

métiers de l’entreprise et non le système informatique, s’appuient sur diverses

structures et applications d’une organisation [Softeam, Guide pratique Objectering,

2008, p.10]. Les processus métiers sont très souvent représentés en langage UML à

l’aide de diagrammes d’activités.


La dernière couche de cette architecture correspond à l’interface service, partie

visible de l’architecture par les utilisateurs. Définie comme un composant logiciel qui

regroupe les opérations passées entre les utilisateurs et les fournisseurs de services,

l’interface ne détaille pas les fonctionnalités techniques de l’implémentation

[Fournier-Morel, Grosjean, Plouin, Rognon, 2011, p. 49-50]. Elle est transparente et

standardisée afin de faciliter l’accès des utilisateurs aux diverses fonctionnalités de

l’entreprise. Le consommateur peut alors exécuter les processus souhaités en ayant

accès aux services via l’interface.

2.2.4. Composantes et principes de base

L’architecture orientée service est un style d’architecture moderne qui suit des

principes de modélisations modernes. Elle est découpée en plusieurs couches

composée d’une dimension présentation, d’une couche métiers et de données.

Les propriétés de base de l’architecture orientée service sont nombreuses et diffèrent

en fonction des divers concepteurs de l’approche SOA. Toutefois, les

caractéristiques fondamentales nécessaires pour classer une architecture comme

étant une SOA sont aux nombre de deux : l’orientation service et le couplage faible.

Par la suite, nous allons analyser en détail ces deux principes acceptés comme étant

essentiels, par l’ensemble de la littérature et des auteurs de ce domaine.

L’orientation service

Défini comme étant la composante fondamentale de cette approche, le service

permet de relier les consommateurs et les fournisseurs sur une même interface,

partie visible de l’architecture par les utilisateurs. Essentiel pour l’architecture

orientée service, le service peut se définir de la manière suivante :

« Un service, au sens SOA, met à disposition d’acteurs (humains ou logiciels)

intervenants dans des processus métiers, un accès vers une ou plusieurs

fonctions métiers. Un service concrétise le lien entre la couche métier


(constituant le côté consommateur) et les implémentations dans le SI

(constituant le côté fournisseur) en prenant à charge un contrat (réalisé par le

pourvoyeur de service). » [Fournier-Morel, Grojean, Plouin, Rognon, 2011, p.

30].

Figure 2-6: SOA, liaison entre vue métier et vue technique [Reproduction réalisée à partir de Fournier-

Morel, Grosjean, Plouin, Rognon 2011, p. 3 ; Laftimi, CNAM 2009]

Le graphe 2-6 démontre les liaisons entre les deux niveaux d’architecture qui sont la

vue métier et la vue informatique, découpée encore en quatre architectures : métier,

fonctionnelle, applicative et technique qui correspondent respectivement aux

processus métier de l’entreprise, aux blocs fonctionnels et aux flux d’informations,

aux blocs applicatifs et finalement à l’infrastructure physique qui supportera les blocs.

Mé

tie

r Consommateurs

Te

ch

niq

ue

Pourvoyeurs

Fournisseurs


Le service est perçu différemment en fonction qu’on soit un utilisateur ou un

informaticien.

Du point de vue de l’utilisateur, le service constitue le résultat visible de la SOA, sur

lequel il pourra travailler, faire des configurations, l’exploiter, définir des contrats de

services, etc. Le service métier est le produit que l’utilisateur va consommer à travers

une interface graphique pour exercer son activité. Un même service métier apparait

simultanément dans plusieurs processus différents, ce qui permet une dynamique

dans le système. Ce service doit être simple d’emploi, doit revêtir le caractère de

réutilisabilité et doit favoriser l’interopérabilité entre ses composantes vu qu’il va relier

plusieurs acteurs sur une interface présente sur le web. [Bonnet, Detavernier,

Vauquier 2008, p. 73-74]. Étant donné que l’utilisateur lambda n’est pas censé

connaître toute la technique derrière le service qu’il utilise, les résultats de la SOA

doivent être normalisés donc compréhensibles par tous. Comme le service doit

respecter un contrat de service, il doit offrir une garantie de qualité et exécuter sa

tâche de manière simple et concise [Fournier-Morel, Grojean, Plouin, Rognon, 2011,

p. 32].

Sous le regard de l’informaticien, le service est une notion plus complexe qui

s’apparente à une composante logique de la SOA avec une fonction déterminée.

Cette notion correspond à une application auto-descriptive présente via une interface

(en langage SOAP/WSDL, REST, etc.), qui communique par message et

indépendamment des autres services. Le service est modulaire, indépendant et

neutre. Pouvant être reliée à d’autres services, cette composante englobe les

données et les informations du système et masque de ce fait l’hétérogénéité du SI.

On obtient ainsi une vue logique des données compréhensible par tous [Fournier-

Morel, Grojean, Plouin, Rognon, 2011, p. 34].

Afin d’atteindre des objectifs stratégiques, l’entreprise est amener à flexibiliser ses

systèmes d’informations et ainsi développer des services. Afin de maximiser la

flexibilité du système, les services doivent respecter quatre principes essentiels de

construction tels que l’autonomie, la réutilisabilité, l’interopérabilité et la composition

des services.


La réutilisation des services [Erl 2008, p. 254-259]

Le principal but de l’architecture orientée service est explicité par ce principe

de réutilisation de services dans les processus du système. Le but étant de

créer des architectures favorisant des modèles de systèmes ayant des

composantes réutilisables. En effet, dans toute création de système, on tente

de créer des fonctionnalités répondant à des critères précis. Chaque

fonctionnalité est spécifique à une tâche précise. Dans cette logique,

l’utilisation d’une fonctionnalité d’un service pour une autre tâche est quasi

impossible si l’on tient compte également du manque de communication entre

les services. L’implémentation de la SOA offre au service, la possibilité d’être

utilisé plusieurs fois, pour des tâches différentes et des utilisateurs différents.

Ainsi, les processus s’exécutent de manière continue dans le système et

permettent d’atteindre les objectifs visés par la firme plus rapidement [Erl

2006, p. 292]. Ceci consiste à la création d’un concept générique favorisant le

paramétrage des services sans difficulté. Le but est de dissocier les services,

auparavant dépendant des uns et des autres, afin de permettre des

modifications rapides, sans passer par une programmation entière du système

et sans perdre de temps [Bonnet, Detavernier, Vauquier 2008, p. 54].

De plus, avec la flexibilité véhiculée par ce principe, SOA offre aux

organisations la possibilité d’une performance conséquente avec une

optimisation des ressources à disposition.

L’autonomie et l’interopérabilité des services [Erl 2008, p. 294-298]

Afin de favoriser la réutilisation des services, il est primordial que chacun de

ces services soit autonomes et capables d’interagir avec les autres

composantes de l’architecture du système.

En général, les services sont très restreints au niveau de leurs champs

d’exécution. En dotant un service d’une certaine autonomie, ce dernier devient

capable de gérer ses ressources sans intervention externe [Erl 2006, p. 303-

304]. L’autonomie leur confère un contrôle significatif sur leurs champs

d’application. Les services métiers doivent être indépendants les uns des

autres, donc faiblement couplés. [Bonnet, Detavernier, Vauquier 2008, p. 54].

Ainsi, ils deviennent en mesure d’exécuter divers logiques métiers de manière

indépendante.


Toutefois, les services ne sont que très faiblement reliés entre eux,

empêchant ainsi une interaction au sein du système. Ceci engendre des

problèmes de communication entre les diverses composantes et empêche le

fonctionnement des processus en continu à cause des redondances, des

duplications, des erreurs, etc.

Pour pallier à ces problèmes, il est primordial d’établir une communication

entre les services, qui doivent interagir entre eux. Pour établir une

communication cohérente, cette architecture implémente les services

échangeant entre eux par messages et dans un langage standardisé (très

souvent XML). L’utilisation d’un vocabulaire métier uniformisé pour chaque

service permet l’intégrité du système. [Bonnet, Detavernier, Vauquier 2008, p.

83]. Les échanges entre les différentes composantes du système, favorisent

l’autonomie de ces composantes et permettent plus de flexibilité au système.

La composition des services [Erl 2008, pp. 388-392]

Afin d’augmenter la réutilisabilité des services, il faut les créer de manière

composée. Chaque service, composé d’unité modulaire, doit être regroupé par

niveau d’abstraction afin de séparer des logiques différentes telles que

processus, métier ou présentation [Bonnet, Detavernier, Vauquier 2008, p.

54].

Construite de manière composée, donc par l’assemblage de multitudes

d’unités modulaires et autonomes, les processus deviennent accessibles et

compréhensibles par tous comme l’illustre la figure 2-7 suivante. Une

commande passée par un service est interconnectée à tous les autres

services dont la présence est nécessaire pour accomplir la tâche en question.

La composition des services crée la possibilité de flux d’interactions entre les

services. De cette manière, la flexibilité et l’interaction règnent entre les

composantes.


Figure 2-7: Composition et interopérabilité [Fournier-Morel, Grosjean, Plouin, Rognon 2011, p. 36]

En somme, les services, au cœur du concept d’architecture orientée service,

encourage la réutilisation des composantes grâce à son caractère mutualisé dans un

environnement d’applications consommatrices, favorise l’interopérabilité grâce à des

intermédiaires internes au SI, et induit une fluidité dans les processus métiers via le

principe de composition.

Afin d’accéder aux fonctionnalités logicielles, les services d’une architecture orientée

service doivent passer par une interface standardisée. C’est pourquoi, les services

présents dans un tel concept se nomment les services web, application exposée par

le biais d'une interface sur Internet ou intranet. La réorganisation des applications en

ensembles cohérents encourage la communication entre des services dits

producteurs et des services appelés consommateurs [Journal du Net, 2007].

L’architecture orientée service a alors un rôle de courtier de service de ces

différentes composantes.

Le service web est l’élément essentiel de la structure des SI orientée service. Ces

services, comportant des fonctionnalités reliées entre elles, regroupent plusieurs

opérations qui seront ensuite présentes sur une interface et directement accessibles


par les consommateurs. À caractère réutilisable, les services web consistent en des

programmes permettant l’échange de données entre des applications et des

systèmes via intranet ou Internet et ceci sans intervention humaine. [Wikipedia 2013]

Il est également important de relever qu’un service est à portée de non seulement

des systèmes d’informations, des processus métier mais également des utilisateurs

via des applications composées. Ces applications consistent en des compositions de

processus de gestion par l’utilisation de service nouveaux ou existants [Hüsemann

2010]. De ce fait, un service qui fait partie intégrante d’une composition, se situe

dans un contexte de partage et d’échange avec les autres services. Il doit être pris

en compte avec toutes les autres composantes de l’application.

Le couplage faible

Le deuxième principe essentiel de la SOA est le couplage faible. Le couplage est

une métrique, d’intensité forte, moyenne ou faible, indiquant le niveau d'interaction

entre deux ou plusieurs composants logiciels [Wikipedia 2013]. Il correspond au

degré d’échange d’informations entre les composants d’un système.

À cause de la faible dépendance entre les services, l’interopérabilité entre ceux-ci est

limitée [Heutschi 2007, p. 33]. En vue de garder un haut niveau de flexibilité dans

l’architecture SI, le plus judicieux est de créer des services autonomes et

indépendants les uns des autres. Ainsi, les services sont alors plus facilement

maniables et modifiables en cas de dysfonctionnements.

Toutefois afin que l’ensemble du système fonctionne correctement, il est primordial

de maintenir des liaisons entre les composantes. Pour cette raison, les services de la

SOA sont reliés par un couplage faible : ils gardent leurs autonomies tout en étant

reliés les uns aux autres mais de manière moindre comme nous pouvons l’observer

dans la figure 2-8 ci-dessous. Ce niveau de couplage est essentiel dans la mesure

où les problèmes apparaissant dans une composante, n’empêchent pas le

fonctionnement de l’ensemble du système.


Figure 2-8 : Le couplage faible entre consommateurs et logique métier [Erl 2008, p. 188]

De plus, le couplage faible comporte de nombreux avantages autant pour le

consommateur que pour le pourvoyeur de services. En effet, afin de pouvoir utiliser

un service, le consommateur envoie un message au système via un protocole de

communication. Le pourvoyeur de service étant tenu par le contrat de service,

répond alors à la requête de l’utilisateur par le même ou un autre protocole de

communication [Fournier-Morel, Grojean, Plouin, Rognon, 2011, p. 51].

Selon les auteurs Fournier-Morel, Grojean, Plouin et Rognon, les avantages

suivants peuvent être détenus par les fournisseurs et les consommateurs grâce au

faible couplage [Fournier-Morel, Grojean, Plouin, Rognon, 2011, p. 51-52] :

POURVOYEUR DE SERVICES CONSOMMATEURS DE SERVICES

Augmentation de la diversité de

consommateurs

Augmentation de la diversité de

fournisseurs

Maitrise de la garantie de la

qualité de ses services

Modification de l’implémentation

de ses services

Facilité d’utilisation sans besoin

de connaître l’implémentation

Fiabilité de transaction avec un

contrat de service explicite

Changement possible de

fournisseur en cas de non-

satisfaction

25 3. L’impact d’une architecture orientée service dans l’entreprise

3. L’impact d’une architecture orientée service dans

l’entreprise

Tenant compte des besoins des entreprises, la SOA est dans l’obligation de

raisonner en tant qu’architecture d’entreprise. L’évolution technologique a favorisé

l’émergence et la présence de plus en plus importante des systèmes d’informations

au sein des organisations.

Pourtant le SI procure non seulement des avantages colossaux aux entreprises,

mais également une complexité significative au sein de l’organisation. La manière de

gérer l’organisation de la firme va également se transformer. La SOA, définie dans

cette logique comme une architecture d’entreprise, s’avère être la solution optimale

face à la complexité des SI. Sans pour autant la simplifier, ce concept met de l’ordre

dans les systèmes d’informations de l’entreprise.

Depuis son apparition, en 1996, cette démarche s’est développée et occupe

aujourd’hui une place importante sur le marché des approches d’intégration de

systèmes. Adopté par de nombreuses entreprises, SOA démontre ses qualités

encore aujourd’hui. En effet malgré la montée fulgurante du « Cloud computing »,

cette démarche architecturale arrive à se démarquer de la concurrence.

Lors de son lancement, la Gartner Group avait prédit à environ 75%, le nombre

d’entreprises ayant recours à SOA dans les années 2008. L’étude réalisée en 2011

par le groupe de recherche américain Forrester Research, le nombre d’entreprise

ayant recours à cette approche s’élevait à 80% (sur un échantillon de 1035

entreprises interviewées). L’efficacité de cette architecture peut être vérifiée par les

résultats de l’étude : avec un taux de pénétration du marché de 60% en Amérique du

Nord tout comme en Europe, la SOA est largement leader de son segment de

marché. La satisfaction des consommateurs de cette approche s’élève en

pourcentage à 81 pour l’Amérique du Nord, et à 73 pour l’Europe [CIO UK, 2011].

Une étude plus récente, réalisée en 2012 par le groupe de recherche française dans

les technologies de l’information Jemm Research & Jemm Vision, souligne que 86%


des entreprises analysés (sur un total de 21) ont engagé une démarche SOA, déjà

complétement intégrée dans leur système. Cette dernière étude appuie les

estimations de 1996 du Gartner Group [Jemm Vision & Jemm Research, 2012].

Avant d’engager un projet SOA, il est primordial de s’intéresser à trois principes

fondamentaux : l’aspect technique englobant la méthodologie nécessaire et les coûts

supportés par la démarche, ainsi qu’au point de vue organisationnel relié aux

modifications qui découlent de cette implémentation. Ces trois aspects sont analysés

dans la suite de manière regroupée.

3.1. D’un point de vue technique et financier

3.1.1. Méthodologie à suivre pour implémenter une SOA

La décision de débuter une approche SOA se fait graduellement en fonction des

besoins de l’entreprise, de l’évolution des technologies de l’information, ainsi que des

coûts émanant des systèmes actuels [Fournier-Morel, Grosjean, Plouin, Rognon

2011, p. 43]. De plus, l’intégration de la SOA dans l’organisation va bouleverser la

manière de travailler dans cette entreprise avec les moyens informatiques à

disposition. C’est pourquoi, une démarche SOA est séquencée en quatre phases : la

planification, la définition, la construction et l’implémentation ainsi que la supervision.

Il existe actuellement de nombreux fournisseurs de conception d’architectures

orientée services telles que IBM, Oracle, Microsoft, etc. qui offrent une solution de

base de cette approche. Toutefois, aucune des solutions proposées n’est dans la

capacité de répondre intégralement aux besoins des entreprises. Pour cette raison, il

est important de suivre minutieusement chaque étape de l’implémentation afin

d’atteindre les objectifs visés comme l’illustre la figure 3-1.


Figure 3-1: Phase de la démarche SOA [SOA Blog, 2010]

La première étape consiste à l’analyse des problèmes auxquels est confrontée

l’entreprise ainsi qu’à la définition des besoins de l’organisation. Le but étant

d’améliorer les lacunes dans le système pour gagner des avantages compétitifs face

à la concurrence. C’est à partir de la prise de conscience de ces problèmes et de ces

besoins, que l’on peut commencer une démarche SOA. Les potentiels de

développement découverts dans cette phase et les objectifs visés par les SI

permettront d’élaborer une stratégie adéquate en se basant sur l’évaluation des

diverses alternatives. Cette période est consacrée à l’élaboration des facteurs de

succès d’un projet SOA à savoir le budget consacré à la démarche, le programme de

mise en œuvre du projet, les acteurs qui vont y prendre part et principalement le

team de développement, les capitaux et les soutiens externes qui vont soutenir la

réalisation du projet [Krafzig, Banke, Slama 2006, p. 263]. Plus précisément, des

tâches telles que l’analyse des dispositifs déjà en place, l’identification des axes

d’amélioration et de progression, la définition des objectifs à atteindre et le choix des

outils d’évaluation d’atteinte des objectifs sont planifiés durant cette première phase


[SOA Blog, 2010]. On va identifier dans cette première partie comment une

démarche SOA peut nous aider à atteindre nos objectifs de base.

La seconde partie s’intéresse à la définition du modèle de référence de gouvernance

SOA (SGRM) à adopter afin de réaliser les objectifs définis dans la partie

précédente. La gouvernance SOA est selon certains auteurs une discipline et selon

d’autre une pratique informatique, qui permet le cadrage et le pilotage d’une

démarche SOA afin de garantir son succès. Elle peut être définie comme

« l’ensemble des moyens et des indicateurs qui permettent de prendre les bonnes

décisions au bon moment et de s’adapter rapidement en tenant compte des

risques » dans le cadre d’une démarche SOA [Fournier-Morel, Grosjean, Plouin,

Rognon 2011, p. 219]. Les principaux piliers d’une gouvernance sont l’organisation

(structures organisationnelles en place), les processus et la technologie. Chaque

action réalisée dans cette logique, est en relation avec un de ces piliers.

La phase de conception de l’infrastructure informatique constitue la troisième partie.

La création et le déploiement d’une architecture SOA sont les activités principales de

cette étape. Il existe trois techniques d’intégration différentes: l’intégration « top

down », l’intégration « bottom up » et l’intégration « outside in » communément

appelé « in the middle » illustré par le graphe 3-2 suivant [Liebhart 2007, p. 172].

Figure 3-2: Stratégie d'intégration [Xebia IT Architects, 2007


L’approche « top down » suit une logique descendante. Elle consiste à

commencer l’intégration par la définition des processus métiers et passer

graduellement à la définition des services métiers nécessaire au fonctionnement

des processus. Cette logique est poursuivie dans le but d’aligner le système

d’information sur le métier de l’entreprise [Erl 2006, p. 363]. Cette approche

permet de piloter l’architecture par les besoins métier tout en minimisant les

redondances des services [Xebia IT Architects, 2007]. Toutefois les coûts

engendrés par cette approche sont importants dans la mesure où elle nécessite

une refonte du SI.

La seconde stratégie d’intégration, nommé « bottom up » opère dans le sens

inverse de la précédente approche. Elle est réalisée dans les entreprises

possédant déjà un système d’information. La conception se déroule de

manière ascendante en commençant par identifier les fonctions existantes du

SI que l’on peut réutiliser en tant que service [Erl 2006, p. 366]. En se basant

sur un système déjà présent, l’entreprise peut récolter un gain sur les coûts

d’implémentation. Ce type d’intégration est meilleur marché qu’une intégration

top down, mais malheureusement pas plus profitable. En effet, elle consiste à

une réutilisation différente d’une fonction déjà existante d’un système, ce qui

ne permet pas une autonomie considérable des services qui restent encore

très dépendants à leur système de base [Xebia IT Architects, 2007].

Enfin, il existe une troisième approche intitulée « in the middle » ou « outside

in », qui se définit comme une combinaison des deux précédentes. Cette

stratégie consiste à développer les approches « top down » et « bottom up »

de manière parallèles pour obtenir des résultats plus pertinents, qui

permettront de déterminer la manière optimale pour définir les processus

métiers. Bien que risqué au moment de la réunion des deux approches, cette

stratégie offre un pilotage efficace de la SOA et favorise la réutilisation des

services.


Une fois toutes les décisions prises quant à la planification et à la stratégie de

conception, les solutions choisies sont alors appliquées. On se situe dès lors dans la

dernière phase de cette démarche : l’implémentation et la supervision. Durant cette

phase, il est important de réaliser chaque étape de l’implémentation en respectant le

temps et le budget à disposition, afin de ne pas engendrér de coûts supplémentaires.

Une fois l’architecture complétement implémentée, le système devient alors

fonctionnel. Cette dernière phase s’achève sur la vérification de l’efficacité du

système, de la supervision de l’atteinte des objectifs, du suivi des performances du

projet et sur une formation fournie aux usagers du système pour une utilisation

optimale [Debray,IBM Software Group, 2005].

3.1.2. Coûts de l’approche

L’adoption de tout nouveau système implique des coûts plus ou moins élevés. Dans

les projets informatiques, ces coûts sont en général très élevés tenant compte des

coûts de conception, de mise en place, d’entretien, de maintenance ou encore

d’échec. Dans cette section, nous allons analyser les principaux frais émanant d’une

démarche SOA en exposant des chiffres tirées d’études réalisées sur le coût de la

SOA.

Les principaux frais activés émanent surtout au niveau de l’implémentation et de la

maintenance du système. Il est difficile de quantifier exactement les montants

nécessaires à une implémentation SOA sachant, qu’ils dépendent de l’ampleur du

projet SOA et de ce fait, des moyens nécessaires à son élaboration. Afin de mieux

cerner l’importance du poids des coûts dans une démarche SOA, il est intéressant

d’analyser différentes études réalisées à ce jour.

Une étude réalisée en 2006 par le GCR Gartner Custom Research, démontre les

différences de stratégies de coûts SOA entre les USA et l’Europe. En Europe, la

tendance est plutôt de réaliser des économies sur les coûts SOA alors qu’aux USA,

les stratégies sont orientées vers le développement de l’agilité SOA. Les principales

dépenses de cette démarche sont dues aux ESB, aux logiciels de sécurité ainsi

qu’aux outils de gestion du système. Ces dépenses représentent selon l’étude,


environ 40% du budget alloué à la démarche alors que les dépenses liées aux

ressources humaines constituent la part plus importante du budget, à savoir dans les

alentours de 54% [Le Monde Informatique 2006]. En comparaison, une étude

réalisée en 2008 par IBM estime à 20% le coût initial de développement et à 80% les

coûts de maintenance du projet sur la base du cycle de vie du projet SOA [IBM

Corporation 2008].

Selon des recherches menées conjointement par l’Université de St-Gall et le groupe

SAP en 2008, il existe une multitude de catégories de coûts engendrés par une

implémentation SOA. Ces coûts sont détaillés à la page 77 dans l’annexe 1, intitulée

« SOA Infrastructures Costs ».

Les principaux coûts recensés sont en termes [SAP AG, University of St. Gallen,

2008, p.23] :

D’investissement dans les infrastructures hardwares et softwares comprenant

les infrastructures physiques et les coûts de licence

De dépenses d’implémentation impliquant les coûts de gestion de projet ainsi

que des tests

Des coûts d’opérations au niveau des services et des systèmes

De gouvernance du concept

De dépense en IT Change Management impliquant les coûts de changements

organisationnels et de formation

Bien entendu, il existe encore d’autres coûts à ne pas négliger telque les coûts de

sécurité informatique, de gestion des systèmes ou encore des coûts implicites

d’effort et de performance [Gartner Group 2008, p. 21]

Vu le nombre croissant d’entreprise ayant recours à cette architecture, les coûts

engendrés deviennent un facteur décisif concernant l’adoption de la SOA. Une étude

menée en 2008 par le groupe de recherche américain IDC, sur les grandes

entreprises ayant implémenté SOA souligne ce fait. Selon cette étude, le nombre

d’entreprises ayant engagés des démarches SOA s’élevait à 53% et les dépenses

annuelles moyennes de chacune de ces firmes approchaient les 1.4 millions de

dollars [Le Monde Informatique 2008]. Lors d’une conférence d’IDC tenue en 2010,


la progression des dépenses pour les architectures orientées services fut estimée à

25% entre 2008 et 2013, tout en soulignant que cette croissance sera tirée par la

région Asie/Pacifique. Le vice-président d’IDC, Ruediger Spies souligne tout de

même que ces dépenses sont justifiées lorsqu’on observe les effets de la SOA sur le

long terme [Le Monde Informatique 2010].

Figure 3-3: Comparaison de la structure des coûts des technologies de l’information d'une approche traditionnelle et d'une SOA [BEA SYSTEMS, 2005]

En effet, un programme SOA se différencie des logiciels traditionnels par sa capacité

de création de valeur de manière plus significative et importante que les projets

logiciels [BEA SYSTEMS, 2005]. Les coûts initiaux élevés s’amortissent au fil du

temps, une fois que les infrastructures SOA sont parfaitement implémentées comme

explicité dans la figure 3-3 ci-dessus.

Bien que les coûts émanant d’une initiative SOA soient élevés, les technologies de

gouvernance SOA restent un des plus importants secteurs en croissance du marché

des infrastructures et du middleware applicatif, générant des revenus de plus de 17.6

milliards de dollars en 2011 [Gartner Group 2011].


3.2. D’un point de vue opérationnel et stratégique

3.2.1. Changement dans l’organisation

L’introduction d’une architecture orientée service dans un système déjà existant va

bouleverser son fonctionnement. Toute l’organisation sera touchée par le

phénomène et en sera profondément modifiée. Cette mutation concerne non

seulement le fonctionnement organisationnel mais également la culture même de

l’entreprise.

De part cette approche, on tente de casser les silos du système [Cf. Chapitre 2.2.1]

pour créer une entité dans lequel tous les départements sont reliés et partagent les

ressources à disposition. Par le partage d’information, la SOA pose les principes de

base d’une organisation homogène sur la base d’un système standardisé. Cela

implique une vision globale de l’organisation, qui est gérée par la gouvernance SOA.

L’infrastructure mise en place relie tous les acteurs de ce système qui peuvent

désormais interagir de manière optimale. Ainsi la SOA optimise toutes les ressources

de l’entreprise. Les buts organisationnels poursuivis par l’implémentation de cette

approche sont [Fournier-Morel, Grosjean, Plouin, Rognon 2011, p.170] :

La mise en place d’un cadre pour l’accomplissement de projets SOA

L’amélioration de l’alignement des besoins métiers et des réponses

techniques

La mise en place d’un outil de communication entre les acteurs internes et

externes du système

La mise en place d’un outil de planification des évolutions du système

Les répercussions directes dans le mode de fonctionnement de l’organisation sont

nombreuses. On en peut relever quelques-unes. Le projet SOA permet par exemple

une augmentation de l’efficacité des systèmes, étant due à l’adaptabilité des

processus. Favorisant la réutilisabilité des composantes, on peut également observer

des améliorations concernant la réduction des délais de mise en œuvre et de la

diminution des coûts informatiques [Bonnet, Detavernier, Vanquier 2008, p. 50].


Toutefois, un changement aussi important dans l’organisation nécessite du temps à

sa mise en place et à son acceptation par tous. Les utilisateurs ont besoin d’un

temps d’adaptation pour se familiariser avec le concept. Il est alors nécessaire de

faire changer les mentalités des acteurs face à ce changement, en les formant à ce

nouveau concept.

3.2.2. Attentes de cette approche

Suite à l’évolution fulgurante des technologies de l’information et la concurrence de

plus en plus rude, le besoin d’agilité s’est fait ressentir dans toutes les organisations.

Il fut primordial de casser les silos des SI et créer des systèmes interopérables.

L’agilité, étant la capacité de réagir rapidement aux changements, est devenue le

mot clé de toute évolution informatique.

SOA est désormais considérée comme une « refonte intelligente du système

d’information, alignées sur les besoins métier, lissée dans le temps et permettant la

cohabitation entre les anciens et nouveaux applicatifs » [Bonnet, Detavernier,

Vanquier 2008, p. 43]. Avec de telles qualités, la SOA s’inscrit à deux niveaux dans

une entreprise : stratégique et opérationnel.

Sur le plan stratégique, ce concept s’inscrit dans la gouvernance des technologies de

l’information. L’approche doit permettre la gestion d’un portefeuille des solutions SOA

(les applications composites) et d’un portefeuille des services [IT- Expert Magazine,

2011]. Au niveau de la stratégie d’entreprise, elle doit favoriser le déploiement

d’outils de mesures pour analyser le rapport coûts/bénéfices et promouvoir le partage

et la compréhension de la stratégie générale [BEA Systems, 2005]. Ainsi les

décisions stratégiques seront prises en tenant compte d’un point de vue global.

Sur le plan opérationnel, ce concept se réfère surtout aux phases de conception, de

déploiement et d’exécution de la mise en place d’une démarche SOA. En effet,

l’opérationnel englobe l’implémentation des processus de gestion des cycles de vie

des services et des applications composées [IT- Expert Magazine, 2011]. À ce

niveau, la SOA doit se définir comme un style architectural dynamique et

standardisée, réduisant les redondances des fonctionnalités du système et favorisant

la réutilisabilité des processus [BEA Systems, 2005].

35 4. Avantages de l’architecture orientée service

4. Avantages de l’architecture orientée service

Depuis la montée en puissance du Cloud computing durant ces dix dernières

années, le concept d’architecture orientée service est souvent remis en question

dans le domaine informatique. On peut apercevoir une division entre les partisans de

ce concept d’un côté et les promoteurs du Cloud de l’autre côté. Les articles

scientifiques criant à la fin du SOA se multiplient. Pourtant les statistiques, comme vu

précédemment, démontre le contraire. A ce niveau, la question se pose alors : SOA

a-t-elle encore une utilité actuellement ? Quelles sont les arguments favorisant

l’adoption de ce concept de nos jours ? Pourquoi opter pour une démarche orientée

service ?

Dans ce chapitre, nous allons analyser les principaux avantages d’une architecture

orientée service sur le plan organisationnel, technique et financier afin de souligner

les avantages découlant de l’adoption d’une SOA dans les infrastructures

informatiques actuellement. Pour cela, nous allons nous baser sur plusieurs études

réalisées à ce jour tout en complétant avec la littérature existante.

4.1. Au niveau organisationnel : la flexibilité du système

Le principal but poursuivi par les entreprises est de se démarquer de la concurrence

pour gagner des parts de marchés et faire des profits. Toutes les théories

économiques l’ayant confirmée, seule une innovation continuelle peut amener à une

position compétitive sur le marché. Pour ceci, il est primordial de s’adapter facilement

et rapidement aux évolutions du marché. Tout retard face aux changements coûte à

l’entreprise non seulement en terme financier mais également en matière de perte de

clients. Dans cette logique, la flexibilité des entreprises face aux évolutions s’avère

être la clé de réussite pour maintenir la satisfaction des clients et le maintien des

parts de marché. Sachant que la majorité des processus d’entreprises sont

informatisés, la flexibilité technologique devient alors un des sujets fondamentaux du

bon fonctionnement de l’organisation.


La flexibilité technologique se définit comme « la capacité de la technologie à se

transformer et à s’adapter au rythme des activités d’une façon aisée et au moindre

coût possible » [Soto, IBM Corporation, 2008, p. 2]. Dans cette optique, l’architecture

orientée service permet la possibilité de créer un environnement technologique

flexible grâce à la standardisation des infrastructures et la décomposition des

applications en services. En effet, ce concept favorise l’agilité par le découpage des

structures applicatives en des composantes, créant une division nécessaire au bon

fonctionnement de l’organisation. Ainsi, les métiers sont construits de manière

alignée aux processus de l’entreprise, qui deviennent automatisés [Raymond,

Softeam, 2011, p. 5]. La standardisation des technologies de l’information est alors à

la base de l’interopérabilité des composantes en favorisant la gestion des processus,

désormais indépendants des services. Toute modification apportée à une

composante du système n’affecte que le service en question sans porter préjudice à

toute autre composante.

Toutefois, les systèmes d’informations ne sont pas des blocs homogènes. Chaque

système est composé de silos applicatifs, de progiciels, de services, etc. qui doivent

interagir les uns avec les autres afin d’être performants. L’importante ampleur de la

communication et du partage d’informations entre ces entités, dote le système d’une

complexité non négligeable [Bonnet, Detavernier, Vauquier 2008, p. 259]. Afin de

contrer la complexité, la SOA se présente comme une solution adéquate en cassant

les silos (barrières organisationnelles). Cette démarche rationalise les échanges

avec un langage commun et gère l’augmentation des flux d’informations grâce à une

structure organisée et standardisée [Holley, Dr. Arsanjani, 2011, p.59].

D’un point de vue économique, les attentes des entreprises de cette démarche sont

diverses. Le graphe 4-1 suivant, tiré d’une étude réalisée en 2009 par le groupe de

recherche Wolfgang Martin Team, illustre les divers motifs de choix économiques

lors de l’adoption d’une démarche SOA. Suivant l’ordre d’importance dans la prise de

décision, nous pouvons citer la haute flexibilité du système, l’optimisation des

processus, la réduction du temps de développement, l’accroissement du ratio

d’innovation et finalement l’augmentation de la production.


Figure 4-1: Motifs de choix lors de l'adoption de démarche SOA [SAP AG, University of St. Gallen, Saat, Discher, 2009, p. 4]

La transformation de l’ensemble du réseau informatique de l’entreprise en le dotant

de la flexibilité, offre de nombreux avantages tels que l’augmentation des bénéfices

induit par une modification de la stratégie informatique, des marges de profits

émanant de l’accroissement de la production ou encore un gain sur le temps de

développement des produits et des services [SAP AG, University of St. Gallen, Saat,

Discher, 2009, p. 18]. Une technologie flexible comme le concept SOA, peut

révolutionner le fonctionnement des systèmes et permettre ainsi aux entreprises de

devenir plus compétitives.

4.2. Au niveau technique : la réutilisabilité des ressources

D’un point de vue technique, l’implémentation SOA contribue amplement à la

réduction de la complexité du système grâce à ses fonctionnalités réutilisables et ses

services indépendants. En effet, le principe de base de la démarche SOA est de

créer des services réutilisables afin d’optimiser les ressources au sein de l’ensemble

du système. Lors de sa conception, les services métiers sont élaborés de manière à

pouvoir être réutilisés d’une part afin de simplifier les processus, d’autre part pour

réduire les coûts de développement des projets.


Par la possibilité de réutilisabilité des composantes déjà existantes, nous pouvons

réaliser des économies en dépenses et en temps nécessaire à la réalisation de

nouveaux projets [Erl, 2007, p.506]. Ainsi un service déjà existant pourra être

invoqué à nouveau par lui-même pour réaliser des tâches déjà exécutées mais

également d’autres lignes de services pourront s’y référer [Raymond, Softeam, 2011,

p. 5]. De cette sorte, les tâches exécutées par les services métiers sont

automatisées, et les services sont mutualisés et ceci en moins de temps que les

autres types d’architecture d’intégration. Ainsi, par l’augmentation de la capacité de

réutilisabilité des services, la SOA diminue les redondances et les erreurs pouvant

apparaitre dans le système tout en accélérant le temps d’automatisation des

processus.

L’orientation service des systèmes simplifie également les problèmes de

maintenance grâce à sa structure organisée. Garantissant une intégration

standardisée avec des composantes interopérables, l’architecture SOA améliore

l’aptitude d’exploitation du système [Bonnet, Detavernier, Vauquier 2008, p. 300-

301]. En effet en assurant un maximum d’indépendances entre les services, on peut

empêcher par exemple les répercussions néfastes du dysfonctionnement d’un

service sur toutes les autres composantes du système. Le problème n’affecte que le

service concerné sans empêcher le fonctionnement des autres services.

L’interopérabilité permet d’une part la standardisation des protocoles pour un meilleur

échange entre les services, et d’autre part la transformation des données entre les

services consommateurs et les services producteurs [Bell 2006, p. 229-230].

L’indépendance totale entre les composantes crée la neutralité technologique sans

contrainte de technologies ou de localisation des services. Ainsi l’échange

d’informations entre les divers services est exécuté de manière adéquate pour une

meilleure communication dans l’ensemble des composants du système.


4.3. Au niveau financier : la baisse des coûts

La plus importante valeur ajoutée du concept d’architecture orientée service est sa

capacité de réduction des coûts sur le plan financier. Une étude réalisée en 2008 aux

États-Unis par le GCR Gartner Customer Research, démontre les attentes des

entreprises vis-à-vis d’un projet SOA [IBM Corporation 2008]. Il ressort de cette

étude que le motif principal à la base d’une adoption du concept SOA est d’ordre

financier.

En effet dans un panel de 151 utilisateurs SOA, 30% ont indiqué avoir choisi ce

concept dans le but de réaliser des économies sur les coûts IT comme explicité sur

la figure 4-2. Nous pouvons en déduire l’ampleur de l’importance des coûts

engendrés par des projets IT dans les organisations surtout lorsqu’on travaille avec

des concepts non agiles.

Figure 4-2 Principales attentes des entreprises d'une démarche SOA [IBM Corporation 2008]


Ces dépenses IT souvent très élevées, englobent non seulement les coûts IT de la

mise en place de nouvelles infrastructures informatiques et de changements qui

suivent l’implémentation, mais également les coûts d’opportunité implicites dans le

cas où le changement n’opère pas en temps voulu [Soto, IBM Corporation, 2008, p.

2]. En effet, la mise en place de ce concept regorge des coûts initiaux exorbitants

dus à l’installation technique, qui seront amortis avec le temps. Sur le long terme, il

est très probable de réaliser des économies sur les coûts essentiellement dus à la

réutilisabilité des composantes.

L’approche SOA, se démarque des approches conventionnelles grâce aux

fonctionnalités qu’elle offre en termes de flexibilité et de baisse des coûts. La figure

4-3 met en relation la structure des coûts de maintenance d’une approche orientée

service et d’une approche d’intégration conventionnelle en accentuant leur évolution

au fil du temps.

Figure 4-3: Investissement initial et rendement à long terme des capitaux investis [Madsen, Loureiro, Groupe CGI, 2006]

Nous pouvons observer qu’au début du projet, les coûts engendrés par la SOA sont

supérieurs aux coûts des approches traditionnelles mais qu’avec le temps, la

tendance s’inverse. Sur le long terme, le concept d’architecture orientée service est

plus bénéfique au niveau de l’amortissement des coûts de maintenance et permet


même de réaliser des marges importantes sur ces coûts par rapport aux méthodes

traditionnelles d’intégration.

La baisse des coûts est notamment due à deux principes majeurs : la réutilisation et

l’interopérabilité des services. Le fait de pouvoir réutiliser les services à maintes

reprises, offre des possibilités d’épargne sur les quatre sources de dépenses IT : les

coûts des projets, les coûts de maintenance, les éventuels changements futurs et le

retour sur investissement.

L’utilisation d’une approche orientée service dans des projets, réduit les coûts de

ceux-ci dans la mesure où elle favorise une implémentation et un déploiement plus

efficient que des approches conventionnelles. Nous pouvons ainsi réaliser des

économies lors de la modification d’un code, de l’intégration de nouveaux modules,

des tests de réussite de projets et lors de la configuration des processus

d’entreprises tout au long du projet, et ceci sans frais supplémentaires [Krafzig,

Banke, Slama 2006, p. 243-244].

Au niveau de la maintenance, les coûts du système sont fortement diminués lorsque

celui-ci est intégré avec une SOA. En effet, la recomposition des services modulaires

et le couplage faible vont simplifier les processus. De ce fait, les dépenses engagées

par la maintenance, les modifications et l’entretien seront réduits [Krafzig, Banke,

Slama 2006, p. 244].

Une autre source de dépenses de toute infrastructure informatique sont les frais

émanant des changements et des évolutions du marché. Afin de faire face à ces

changements, l’entreprise a besoin d’un certain temps d’adaptation qui va coûter à

l’entreprise en termes de bénéfice net et de chiffre d’affaire. SOA s’avère être la

solution adéquate à ce problème. Grâce à son infrastructure standardisée, la SOA

supporte tous types de modifications au cours du temps. De plus, elle est facilement

maniable grâce à la modularité des services réutilisables qu’elle met à disposition. A

long terme, la SOA s’adapte aisément par une intégration facilitée de nouvelles

composantes [Krafzig, Banke, Slama 2006, p. 244].


Enfin, il est possible d’obtenir des retours sur investissements ROI (Return On

Investment) importants avec ce type d’architecture. En effet, sur le long terme, les

coûts initiaux élevés sont amortis. La flexibilité offerte par la SOA est très souvent

décrite comme la raison des possibilités de retour sur investissement [Holley, Dr.

Arsanjani, 2011, p. 28]. Même si mesurer le ROI de la SOA reste une tâche

complexe à réaliser, il existe tout de même des techniques de calculs de la valeur

commerciale de SOA exprimé en valeur monétaire. Toutefois, lors du choix d’une

démarche SOA, les chiffres du ROI ne sont pas significatifs. Il est nécessaire de tenir

compte la stratégie choisie et des objectifs visés pour parvenir à une décision avant

d’opter ce concept.

En somme, les avantages de la SOA offrent à l’entreprise une position compétitive

sur le marché par la flexibilité et une meilleure profitabilité économique grâce à la

réduction des coûts [Gartner Group 2008, p.12].

43 5. Etudes de cas

5. Etudes de cas

Cette seconde partie du mémoire, recense des expériences de la vie pratique

concernant l’architecture orientée service. Le principal objectif étant de prendre

conscience de la réelle utilité du concept de SOA sur la base d’expériences

d’utilisateurs de cette approche et de comprendre comment et pour quelles raisons

cette démarche est appliquée par les entreprises. Même que cette approche a été

élaborée, il y’a déjà quelques années, elle reste malgré tout pas très commune sur le

marché européen et particulièrement en Suisse. C’est pourquoi, réaliser cette partie

fut intéressant et enrichissant pour venir en appui à la partie théorique. Les

expériences récoltées dans la suite du travail, permettent de prendre conscience de

l’application réelle de cette démarche ainsi que les vraies raisons à la base de son

adoption.

Deux difficultés majeures se sont réellement posée dans cette partie du travail.

Premièrement, recenser des institutions utilisant ce type d’architecture fut laborieux,

dans la mesure où les substituts de ce concept sont nombreux. En effet, il existe

plusieurs méthodes d’intégration, et SOA en est une parmi d’autres. Même si ses

avantages sont nombreuses, moult entreprises préférèrent utiliser d’autres types

d’architectures que SOA pour diverses raisons. Ensuite, la seconde difficulté fut

l’accès à l’information. Bien entendu toutes les entreprises agissent dans le cadre de

la confidentialité des données. De ce fait, certaines informations concernant les

études de cas suivantes seront citées de manière anonyme surtout en ce qui

concerne la seconde entreprise. Le principal but demeure dans l’information elle-

même et non dans l’entreprise qui l’a fourni. Nous pouvons encore relever un autre

aspect qui est la collaboration avec les firmes rendus difficile soit à cause de la

distance géographique soit à cause du manque de disponibilité, mais tout à fait

compréhensible de la part des entreprises.

44 5. Etudes de cas

Ces études de cas portent d’une part sur une entreprise privée qui est une grande

compagnie d’assurance et dont le nom ne sera pas cité pour cause de

confidentialité, ainsi que sur une organisation autonome mais publique qui est l’Office

de la Circulation et de la Navigation du canton de Fribourg. Les divers éléments

discutés dans la suite émanent d’un questionnaire identique, traduit en français et en

anglais, adressé à chacune des deux entreprises. J’adresse ma reconnaissance à M.

Philippe Savary, Chef du service IT de l’OCN ainsi que la responsable IT de la

compagnie d’assurance pour leur collaboration et pour le temps qu’ils ont consacré à

la concrétisation de cette partie du travail.

Les informations citées et utilisées dans la suite proviennent des études de cas

réalisées avec les entreprises. Ces études de cas se sont déroulées en deux parties.

Premièrement une série de question ouvertes, identiques pour les deux entreprises,

ont été adressées aux interlocuteurs. Les réponses à ces questions ont été étudiées

dans divers sous-chapitre, en faisant une synthèse de chacune. Ensuite, afin de

comprendre les avantages procurés par l’adoption de l’architecture orientée service

au sein des systèmes informatiques, les entreprises ont dû remplir une grille

d’évaluation. Les principaux avantages au niveau organisationnel, technique et

financier d’une implémentation SOA y étaient exposés. Chaque entreprise a été

priée de remplir cette grille de manière la plus adaptée et réaliste en fonction de leur

situation. Sur la base des résultats obtenus dans ces questionnaires, une analyse a

été réalisée dans la dernière partie de chaque étude de cas.

45 5. Etudes de cas

5.1. Office de la Circulation et de la Navigation du canton de

Fribourg

La première étude de cas repose sur une organisation autonome mais publique de

l’Etat de Fribourg, qui est l’Office de la Circulation est de la Navigation, plus

communément appelée l’OCN.

Ce sous-chapitre se concentre sur l’expérience, en termes d’architecture orientée

service, dans le domaine de la sécurité routière. Les informations utilisées par la

suite proviennent d’une étroite collaboration avec le chef du service IT de l’OCN,

Monsieur Philippe Savary, sur la base d’un questionnaire, lui étant destiné et d’un

échange par courriel électronique.

5.1.1. Portrait de l’organisation

L'Office de la Circulation et de la Navigation (OCN), dont le siège principal se situe à

Fribourg, opère dans les activités liées à l’admission des personnes et des véhicules

à la circulation routière et à la navigation, aux autorisations nécessaires à toutes

catégories de circulation et navigation, à la perception des impôts sur les véhicules

et les bateaux, à l’organisation de cours de prévention, ainsi qu’aux diverses

activités administratives [OCN 2013].

Avec un effectif de près de 100 collaborateurs, cet établissement autonome de droit

public est géré selon les principes de l’économie d’entreprise. Les impôts prélevés

sur les véhicules et les bateaux, s’élevant à près de 90 millions de francs suisses,

sont entièrement versés à l’Etat de Fribourg. Cet établissement supervise la gestion

de plus de de 220'000 conducteurs et 235’000 véhicules dans le canton. La qualité

des prestations offertes, qui est orientée selon les attentes de leur clientèle, est

d’importance capitale. D’ailleurs la performance de leur service ainsi que la qualité de

leurs prestations sont souvent certifiés par des accréditations.

46 5. Etudes de cas

5.1.2. Présentation du système informatique de l’établissement

À l’OCN, le domaine informatique ne fait pas partie intégrante du « Core Business

Management » de l’établissement. Toutefois, étant donné l’ampleur et l’importance

des données informatiques, ce domaine demeure essentiel au bon fonctionnement

de l’ensemble du système. Ce domaine est géré par Monsieur Philippe Savary, chef

du service IT.

Le système informatique de l’OCN se compose d’un (pro)logiciel d’entreprise nommé

CARI ainsi que d’une multitude d’applications hébergées soit localement soit à

l’OFIT1 étant donné qu’elles sont exploités au niveau national. CARI est une

application métier utilisée pour par quatorze services des automobiles et de la

navigation dans l’ensemble de la Suisse [Abraxas CARI 2011].

Elle fonctionne de manière simplifiée selon la figure suivante.

Figure 5-1: Fonctionnement du logiciel CARI

1 L’OFIT est l’Office Fédéral de l’Informatique et de la Télécommunication qui s’avère être l'un des

fournisseurs internes de prestations informatiques de l'administration fédérale [Confédération Suisse 2013].

47 5. Etudes de cas

Le logiciel CARI se caractérise par une série de processus standardisés permettant

de relier plusieurs modules et les bases de données ainsi qu’avec les partenaires

internes et externes comme nous pouvons le voir dans la figure 5-1 [Abraxas CARI

2011]. De cette sorte, les services publiés sur Internet permettent d’intégrer les

clients et les partenaires externes directement dans les procédures internes.

Le paysage applicatif de l’entreprise se représente alors de la manière suivante :

Figure 5-2: Paysage applicatif de l'OCN

Comme le décrit la figure 5-2, le paysage applicatif de l’OCN est constitué de divers

logiciels et éléments reliés entre eux. Le logiciel principal CARI est en quelque sorte

le socle de l’ensemble du système. Il gère une multitude de modules à lui seul

comme la comptabilité débitrice, les relations avec les partenaires internes et

externes, les questions relatives à l’administration, etc. L’architecture orientée service

apparait dans ce paysage au niveau de ce logiciel CARI. Elle est mise en œuvre à

l’intérieur même du logiciel et facilite toutes les relations présentées dans la figure 5-

2 par des flèches. Il existe d’autres logiciels plus spécifiques tels que CarD pour

l’impression des permis de conduire sous la forme de carte de crédit ou encore des

logiciels de gestion comme Abacus. L’OCN dispose également d’une plateforme

Internet comme moyen de communication. Elle est en constante collaboration avec

d’autres organisations externes grâces à divers applications telles que FABER,

48 5. Etudes de cas

ADMAS, RIPOL, MOFIS, TARGA, Sari, etc. qui sont hébergées soit par l’OFIT

(appelée BIT en allemand) ou soit par des serveurs locaux.

Malgré son statut d’autonomie, l’OCN reste une entreprise de droit public et pour

cette raison, elle collabore tout de même avec le service informatique de l’Etat de

Fribourg, nommé le SITEL, qui héberge pratiquement l’ensemble des services

utilisés.

5.1.3. Description du projet SOA et dans son évolution au fil du temps

L’architecture orientées service fait partie du l’architecture logicielle de l’OCN. Elle

est mise en œuvre dans le logiciel CARI, spécifique pour les services automobiles de

l’ensemble de la Suisse (implémentées dans quatorze cantons). Ce type

d’architecture est le plus adapté aux besoins informatiques rencontrés dans ce

domaine, grâce à sa couverture fonctionnelle. L’architecture orientée service n’a pas

été introduite dans le système informatique de l’Office en tant que projet à part

entière. Elle n’est exploitée que dans le service informatique de l’établissement au

niveau de l’architecture logicielle.

Cette démarche informatique est née dans la stratégie informatique de l’Office de la

Circulation et de la Navigation suite à plusieurs contraintes imposées par d’autres

organisations.

D’une part, l’Office a du faire recours à ce type d’architecture dans le prolongement

des décisions prises par l'Office Fédéral des Routes (OFROU) et l'Office Fédéral de

l'Informatique et des Télécommunications (OFIT). Ces deux partenaires jugeaient

nécessaire la mise en place d’un support de centralisation des données de gestion

au niveau national en ce qui concerne le domaine des permis de conduire avec

l’application FABER, celui des permis de circulation avec l’application MOFIS et celui

des mesures administratives avec l’application ADMAS. Le principe consistant était

de centralisé l’information gérée au niveau cantonal directement au niveau fédéral.

Toute information validée par un canton doit être communiquée et validée au niveau

fédéral grâce à un processus actif en temps réel.

49 5. Etudes de cas

D’autre part, l’OCN fait partie d’une association des services automobiles nommée

asa. Cette association œuvre pour le respect des prescriptions sur la circulation

routière de manière uniforme dans l’ensemble du pays [ASA 2013]. Elle travaille

continuellement sur des projets de développements informatiques et d’échanges de

données dans le but de standardiser les processus cantonaux pour assurer une

uniformisation des applications utilisées. Par la standardisation des processus, il

devient alors possible de réduire les coûts informatiques de l’ensemble des membres

de l’association. Le meilleur exemple que l’on peut citer dans cette étude de cas est

celui de l’application CarD développée pour permettre l’impression des permis de

conduire au format de carte de crédit directement dans les offices d’automobiles.

Cette application à elle seule permet une réduction importante des coûts de

développements. De plus, elle a également lancée des projets d’échanges de

données, par exemple pour les questions d’assurance de responsabilité civile, afin

de simplifier les tâches administratives d’une clientèle commune.

Cet environnement nécessitant l’intervention de différents acteurs a contraint l’OCN a

à restructurer son système grâce à une architecture plus flexible comme la SOA, afin

de répondre à tous ces changements et ces obligations qui lui ont été imposées.

Cette technologie orientée service, décrite par Monsieur Savary comme une « mise

en place des services informatiques, à forte intégration mais avec un faible couplage

au niveau de la maintenance, afin de garantir son optimisation » est exploitée à

divers niveaux du système. Tout d’abord, elle intervient notamment dans les

communications qu’entretient l’OCN avec les applications informatiques fédérales

telles que FABER, ADMAS ou MOFIS utilisées par d’autres organisations.

L’intégration avec SOA, facilite les échanges avec ses partenaires externes.

Ensuite, les relations informatiques entretenues avec les compagnies d’assurance,

qui délivrent les attestations d’assurance de responsabilité civile RC pour

l’immatriculation des véhicules et également des bateaux sont améliorées. En guise

d’exemple, nous pouvons observer la figure 5-3 qui représente l’architecture des

services mises en place par une compagnie d’assurance dans les activités de

délivrance des attestations nécessaires pour autoriser l’immatriculation ou la mise en

circulation d’un véhicule.

50 5. Etudes de cas

Figure 5-3: Architecture des services en relation avec les activités d'assurance

La partie supérieure de la représentation explicite les quatre interfaces nécessaires

apparaissant dans ce type d’activités alors que la partie inférieure décrit les relations

étapes par étapes pour la réalisation de cette activité. L’architecture orientée service

favorise la réalisation de ces relations. Les services utilisés via une architecture SOA

permettent une communication claire entre les diverses composantes du système

sachant que tous ces échanges d'informations sont basés sur des web services (en

langage XML).

51 5. Etudes de cas

Enfin, l’implémentation de la SOA dans cette infrastructure informatique permet à

l’OCN, une marge d’indépendance dans la réalisation de certaines tâches

directement dans leur système grâce au couplage faible. Par exemple, le système

assure la production de permis de conduire au format de carte de crédit, et ceci

grâce à la communication qu’elle peut facilement entretenir avec des applications

externes. L’architecture orientée service facilite également la communication de la

firme avec ses clients directement sur leur site internet via des quiz et des

formulaires et services présents sur le web.

L’OCN ne développant pas directement ce type de services elle-même, ces derniers

proviennent de sociétés de service externes spécialisées dans le développement

informatique. En somme, l’architecture orientée service n’a pas été implémentée

dans cette firme en tant que projet mais plutôt tel qu’un prolongement informatique

nécessaire face aux changements continuels des technologies de l’information.

Toutefois ceci ne signifie pas qu’aucun coût a été engendré pour sa mise en œuvre.

Depuis 2001, la mise en place de l’architecture orientée service a activée des coûts

d’investissement dépassant plusieurs millions de francs suisses qui représentent des

sommes considérables.

De par son caractère d’organisation publique, l’OCN est tenu de respecter des

exigences standardisées imposées par l’Etat dans le but d’uniformiser les systèmes.

L’Office est dès lors dans l’obligation de se mettre à jour pour travailler sur la base

d’applications standardisées au niveau national.

5.1.4. Objectifs visés par l’adoption de SOA et grille d’auto-évaluation sur les

attentes et les réalités de SOA

Pour comprendre les attentes de l’entreprise avant l’implémentation de la SOA et la

réalité après l’implémentation pour chacun des avantages théoriques de ce concept,

nous allons analyser la grille d’évaluation suivante, complétée par Monsieur Savary.

52 5. Etudes de cas

Attentes Réalités

ORGANISATIONNEL

Flexibilité "Saint-Graal" Théorique

Modification des

services existants -

Complexe avec une forte

implication de tous les

partenaires que cela soit du côté

du "client" comme du

"fournisseur"

Intégration de

nouveau processus - idem

Adaptation à de

nouvelles exigences - idem

TECHNIQUE

Favoriser le

développement -

Pour éviter les difficultés

d'évolution l'on a tendance à

démultiplier les services

disponibles

Augmentation des

processus à

disposition

- idem

Réutilisation des

ressources - idem

FINANCIER

Coût de

l’implémentation - Pas évaluer / comparer

Coût de la

maintenance - Pas évaluer / comparer

Coût de

l’infrastructure - Pas évaluer / comparer

Figure 5-4 : Grille d'évaluation des attentes et des réalités du SOA de l'OCN

53 5. Etudes de cas

Comme vu précédemment, la démarche SOA n’a pas été adoptée dans le cadre d’un

projet autonome. L’OCN a dû adopter cette technologie à la suite des contraintes

imposées par ses partenaires. L’évolution des partenaires de l’office vers ce type

d’architecture, en est la réelle raison. C’est pourquoi, l’OCN n’a pas établit des

objectifs à atteindre avec cette architecture. Elle a dû l’admettre afin de suivre les

évolutions de ses partenaires en matière de technologie des systèmes

d’informations. Pour cette raison, le département n’avait pas des attentes

particulières vis-à-vis de la SOA lors de son adoption.

Une fois implémentée, les réels avantages et désavantages de cette architecture ont

pu être dénombrés au niveau technique et organisationnel. Certaines parties du

système ont connu des simplifications dans leurs processus grâce à la mise en place

de services à forte intégration, reliés entre elle avec un faible couplage au niveau de

la maintenance. De ce fait, le système utilisé est devenu plus flexible par endroit.

Toutefois, Monsieur Savary juge le niveau de flexibilité amené avec la SOA positif.

En effet, la modification des services existant ainsi que l’intégration de nouveaux

processus, qui auraient dû être améliorée avec l’implémentation SOA, demeure tout

de même complexe à mettre en pratique. Toute modification nécessite l’implication

de tous les partenaires clients ou fournisseurs. De ce fait, la marge d’autonomie de

l’entreprise en termes de changements informatiques se rétrécit.

Au niveau de la technique, le département informatique de l’OCN n’opte pas l’option

de réutilisabilité des services existants, mais plutôt préfère démultiplier les services

disponibles. Certes, de cette manière les problèmes diminuent mais ceci aura

comme conséquence d’augmenter la complexité du système notamment à cause des

redondances. Du fait que l’Office est fortement relié à des partenaires externes, elle

ne peut pas changer de stratégie informatique selon ses envies. Ceci explique les

problèmes de manque de flexibilité ou de non utilisation optimale des ressources à

disposition.

Sur le plan financier, aucune évaluation intégrale des coûts engendrés n’a été

réalisée jusqu’à ce jour par l’établissement. En effet, la mise en place de cette

architecture a été réalisée en plusieurs étapes moyennant des évolutions constantes

dues aux extensions de services. Ceci s’est déroulé sur plusieurs années. Depuis

54 5. Etudes de cas

2001, l’ensemble des coûts engendrés pour l’implémentation et l’adaptation se

monte à la hauteur de plusieurs millions de francs suisses. Pourtant d’autres

avantages apparaissent comme la diminution des dépenses informatiques en

termes de modifications nécessaires à l’avenir. Même si dans ce cas, la SOA ne

permet pas d’avantages directs au niveau des coûts informatiques, elle offre tout de

même des opportunités d’épargne des coûts en cas de modification nécessaire du

système dans le futur.

Il est quasi irréaliste de dénombrer les avantages financiers selon Monsieur Savary,

dans la mesure où elle nécessite des évolutions constantes et rapides, tout en

sachant que ces évolutions engendrent elles aussi des coûts importants. Le plus

efficace sera de comparer cette architecture aux autres solutions utilisées dans le

département, pour connaitre les réelles épargnes réalisées avec SOA.

Dans l’ensemble, l’architecture orientée service fut pour l’office une contrainte

imposée par ses partenaires, à laquelle elle a dû s’y résoudre. Cette technologie

informatique a tout de même apporté des avantages à l’entreprise surtout en termes

d’organisation et d’épargne des coûts informatiques pour les projets futurs. En

somme, la SOA est perçue dans l’Office comme une tentative importante à

l’urbanisation de leur système d’information.

5.1.5. L’utilité réelle de SOA dans l’entreprise

L’architecture orientée service est décrite dans cette organisation comme une

architecture naissant de plusieurs tentatives informatiques passées et présentes

dans le but d’aboutir à une véritable urbanisation des systèmes d’information. La

notion d’urbanisation sous-entend l’évolution continuelle du système d’information en

vue d’anticiper les changements et transformations futurs. Cette discipline

d’ingénierie informatique a comme but de soutenir efficacement les objectifs et les

missions des entreprises [Club Urba-EA 2010, p.3-6]. SOA est le fruit de la mutation

de ces systèmes d’informations qui vont encore continuer à évoluer, dans notre

environnement et notre société bouleverser par le changement continuel. La

démarche SOA garantit des perspectives effectives dans le but de réaliser cette

55 5. Etudes de cas

intention d’urbanisation des systèmes. L’utilité réelle de cette architecture pour la

firme réside dans cette logique d’évolution informatique afin d’augmenter la

performance continuellement.

La mise en place de l’architecture SOA fut longue mais son adaptation le fut encore

plus. Il est difficile pour l’établissement d’estimer ce temps d’adaptation au sein de

toute l’organisation. Toutefois, il est important de souligner que la mise en place

d’une architecture de ce genre nécessite un engagement sérieux de la part de tous

les collaborateurs afin d’en assurer la maîtrise complète. Une fois implémentée

intégralement, l’architecture orientée service a augmenté le potentiel de performance

du système d’informations. Une simplification s’est installée à certains niveaux du

système, tout en complexifiant d’autres niveaux.

Théoriquement parlant, le fait d’adopter une telle architecture pouvait amener à des

gains en avantages concurrentiels. Toutefois étant donné que l’Office n’opère pas

sur un marché libre, cet argument théorique n’est pas discutable pour le cas de cette

entreprise. Ceci n’empêchant pas le fait que la SOA a augmenté la performance du

système en offrant de nombreuses améliorations techniques au niveau de

l’infrastructure logicielle. En somme, la réelle utilité de ce concept se calcule en

termes d’avantages organisationnels pour cette firme. Le gain en flexibilité du

système s’avère être la plus-value de l’adoption de la démarche SOA, permettant

ainsi à l’organisation une marge d’agilité.

56 5. Etudes de cas

5.2. Grande compagnie d’assurance

La seconde étude de cas repose sur une très grande compagnie d’assurance active

dans le monde entier dont le nom ne sera pas divulgué explicitement dans ce travail

pour des questions de confidentialité. Ce sous-chapitre se concentre sur

l’expérience, en termes d’architecture orientée service, dans les domaines de

l’assurance, secteur dans lequel le service est l’activité élémentaire. Les informations

utilisées par la suite proviennent d’une collaboration avec le responsable IT de la

compagnie d’assurance en Suisse, et sur la base d’un questionnaire qui leur était

destiné.

5.2.1. Présentation de la firme

Avec un effectif de plus de 160000 employés dans le monde entier, dont 4000 en

Suisse, et plus de 100 millions de clients, ce groupe d’assurance occupe une place

très importante sur le marché mondiale des assurances. Cette entreprise de service

opère dans plusieurs domaines et plus particulièrement dans des activités telles que

les solutions d’épargne, la gestion de patrimoine avec des produits bancaires ainsi

que dans tous les types d’assurances que ce soit des personnes, des véhicules, des

choses ou encore la responsabilité civile.

5.2.2. Objectifs visés par l’introduction de SOA

Avec de telles activités et une présence aussi importante sur le marché tant national

qu’international, l’entreprise nécessite de détenir un vaste système informatique dans

le but d’uniformiser les applications partout dans le monde entier. Leur système IT,

utilisant divers technologies dont SOA, s’est principalement développé au cours des

dernières années et gère actuellement plus de 300 applications différentes, dont

certaines datent de plus de quarante ans et d’autres sont plus récentes. Ces

applications sont gérées par 6 différentes technologies de déploiement

d’applications dont une est l’architecture orientée service. Cette structure donne lieu

57 5. Etudes de cas

à une infrastructure informatique complexe utilisant des technologies variées afin

d’opérer de manière optimale dans les services proposés par la firme.

Adopter un nouveau concept informatique sous-entend toujours des améliorations de

la situation actuelle tant sur un plan opérationnel que sur un plan stratégique. La

compagnie en question a préféré opter cette démarche pour les avantages qu’elle

procure surtout au niveau organisationnel sans chercher à exploiter entièrement

toutes les fonctionnalités dans l’idée d’optimiser l’utilisation de cette technologie.

L’idée d’origine de l’adoption de cette architecture était de favoriser la réutilisabilité

des composantes du système. Ceci ayant comme but de minimiser les erreurs et les

redondances. De plus, par la réutilisabilité des ressources, l’entreprise a réussi à

développer leur système, pour le rendre plus homogène et efficace. La

communication entre les composantes du système devient améliorée et procure au

système plus de performance.

Toutefois, la réutilisabilité des composantes n’était pas le seul objectif poursuivi. En

effet, avec un système d’information aussi complexe nécessitant une performance

continuelle et une homogénéité au niveau global dans tout son champ d’exécution, il

était et est toujours nécessaire d’utiliser des technologies informatiques facilitant la

réalisation de ces processus complexes. L’entreprise décrit le principal but comme la

hausse du potentiel de management du système d’information constituée de

nombreuses applications complexes. Que l’on se trouve en Suisse, aux USA, ou

dans n’importe quel autre marché mondial, chacun des utilisateurs doit pouvoir

accéder à l’information de manière simple et compréhensible. SOA s’avère être dans

ce sens, une technologie facilitant l’accès à l’information par des utilisateurs lambda

et permet ainsi un meilleur management du système dans son intégralité.

Comme il s’agit ici d’une entreprise dont les activités sont majoritairement des

services, il fut nécessaire pour la firme d’adopter une méthode d’intégration des

applications permettant le découplage entre celles-ci afin de rendre les processus

plus fluides et les fonctionnalités plus simple d’utilisation. De ce fait, l’ensemble des

transactions réalisées dans le monde entier peuvent croître et permettre à

l’entreprise de renforcer sa position sur le marché grâce à un système d’information

plus flexible.

58 5. Etudes de cas

D’une part, le découplage est important pour faire face aux différents changements

technologiques que peuvent connaitre les technologies actuellement utilisées. En

effet, l’évolution technologique est un phénomène toujours plus important de nos

jours. Il est primordial de réussir à faire face à quelconque mutation technologique

afin de rester toujours à jour. Avec l’architecture orientée service, la compagnie

d’assurance peut facilement réagir face à tous types de changements grâce à ses

services modulables et son interface standardisée. Ainsi les fonctionnalités, les

processus et les technologies utilisés ont plus de chance de remplir entièrement leur

fonction en tout temps, dans ce monde heurté par la mutation technologique.

D’autre part, le découplage des composantes, permet une meilleure relation entre

les fonctionnalités back end et l’environnement front end du système d’information.

En effet, les fonctionnalités en arrière-plan du SI sont en général très lentes

d’exécution alors que les interactions sur l’interface d’utilisation doivent être rapides

et efficaces. Le niveau de découplage offert par l’architecture orientée service permet

d’homogénéiser cette relation pour obtenir en fin de compte un environnement

dynamique et flexible.

En plus de l’augmentation de l’agilité du système et la flexibilité face aux

changements, la compagnie souhaitait également gagner des avantages au niveau

financier par la réduction des coûts de maintenance toujours plus démesurés. En

effet, comme vu précédemment dans le chapitre 4.3 aux pages 45-46, les coûts

informatiques peuvent fortement être diminués, sur le long terme, lorsqu’on intègre

un SI avec une architecture SOA. Ce type d’architecture va grâce à la modularité des

services, la réutilisabilité des composantes et la simplification des processus,

diminuer les coûts de maintenance et d’entretien. Toutefois, il demeure difficile de les

quantifier.

5.2.3. Description de la démarche SOA et dans son évolution au fil du temps

Le concept d’architecture orientée service n'a pas été introduit dans la stratégie

informatique de la compagnie en tant que projet à part entière. Il fut nécessaire de

l’adopter à la suite des évolutions technologiques qu’a connues le marché

59 5. Etudes de cas

informatique. Face au besoin grandissant d’agilité dans cet environnement

chamboulé par les changements technologiques, environnementaux, stratégiques,

etc., la firme la introduite dans son infrastructure dans les années 2000.

Depuis, cette méthode d’intégration est en constant développement et joue

aujourd’hui un rôle important dans cette infrastructure. En effet, environ un tiers de

l’architecture logicielle est implémenter par la démarche orientée service. Cette

intégration orientée service est perçue comme une pratique apparaissant dans le

prolongement du développement de software réalisé par le département informatique

de la firme, et dont il est devenu impossible de s’en passer. L’architecture orientée

service a acquis le titre de très puissante gouvernance d’architecture au sein de cette

compagnie permettant ainsi un contrôle important sur l’ensemble de ce système

complexe. Les principes de la SOA sont acceptés et implémenter dans les valeurs

des équipes de développements informatiques

Dans les années 2000, la compagnie d’assurance a lancé un projet informatique

englobant l’établissement des technologies d’intégration à savoir les Enterprise

Service Bus, vu précédemment au chapitre 2.2.3 p. 16, afin de restructurer l’ossature

de leur système, sachant que l’implémentation d’une SOA par une ESB est la

méthode la plus commune de nos jours. Par la suite, ils décident d’implémenter des

processus pour les SOA Services Development et les SOA Services Operations

dans le but d’harmoniser l’architecture en place. Ces deux types de services sont mis

en place pour favoriser le développement et la gestion des opérations du système.

Enfin, la compagnie initie un référentiel de services d’entreprise permettant un

contrôle sur l’ensemble des services et par conséquent une intégration standardisée

de toutes les composantes du système.

L’architecture IT de cette compagnie d’assurance est assez complexe. Afin de

l’expliciter, nous allons décrire de manière simplifiée certains éléments au niveau

technique de l’architecture. Tout d’abord, il faut savoir que la firme dissocie les types

de services en trois catégories. Il existe les Business Objects Services qui consistent

aux services orientée objets, les Business Activity Services qui concernent les

activités générées par le système (par exemple un service faisant appel à d’autres

services) et les Presentation Services qui s’apparente surtout sur le visuel des

informations affichées sur l’interface d’utilisation. Ils agissent sur la base de ces trois

60 5. Etudes de cas

différents niveaux de services qui respectent les principes de couplage faible, voire

même de découplage dans certains cas, pour les données, les fonctionnalités, les

interfaces utilisateurs, etc. Ensuite un Enterprise Service Bus rend possible le

transfert de ces services là où des options d’intégration prédéfinis sont présentes.

Ces options autorisent les services à communiquer entre elles, favorisant l’interaction

de ces dernières. Ainsi l’échange et la communication entre les composantes du

système sont garantis. Enfin, afin d’orchestrer ces services selon les situations

demandées, l’entreprise fait appel à une plateforme du Business Process

Management (BPM). Le BPM, plus communément appelé gestion de processus

métier, permet la modélisation des processus métier de la firme tant dans sa forme

applicative ou humaine afin d’automatiser au maximum les processus métiers

[Madsen, Loureiro, Groupe CGI, 2006, p.4]. Toutefois cette orchestration peut aussi

directement être réalisée par les composants utilisateurs du système sans faire appel

au Business Process Management.

La vision de l’entreprise sur ce concept SOA se caractérise non pas comme une

technique en elle-même, mais comme une pratique permanente dans le

développement de leur système. Ils affirment suivre une forte approche contrat

mettant en relation d’une part une approche orientée entreprise et d’autre part une

plateforme indépendante. Cela signifie, selon les responsables questionnés, qu’il faut

définir le service SOA comme un service contrat en mettant toutes les informations

dans le référentiel de service d’entreprise alors que les plateformes restent

indépendantes du service mais dépendantes des adaptateurs.

En somme, l’architecture orientée service n’a pas été implémentée dans cette firme

en tant que projet mais plutôt telle qu’une pratique permanente dans le

développement de software. De ce fait, le budget consacré à cette implémentation

reste quasi impossible à quantifier même si l’on peut estimer que les frais furent

considérables dans la première phase de son implémentation. De par la complexité

de son système d’information, cette compagnie d’assurance doit en tout temps

développer son infrastructure informatique pour le rendre plus fonctionnel et simple

d’utilisation.

61 5. Etudes de cas

5.2.4. Grille d’auto-évaluation sur les attentes et les réalités de SOA

La figure 5-5 ci-dessus a été complétée par un responsable informatique du

département informatique de la compagnie. Elle met en évidence les attentes de

l’entreprise avant l’implémentation de la SOA et la réalité après l’implémentation pour

chacun des avantages théoriques de ce concept.

Figure 5-5: Grille d'évaluation des attentes et des réalités du SOA de la compagnie d'assurance

Attentes Réalités

ORGANISATIONNEL

Flexibilité High Quite high

Modification des

services existants Easy Sometimes tricky

Intégration de nouveau

processus Easy

Only easy if the respective

services are in place already

Adaptation à de

nouvelles exigences - -

TECHNIQUE

Favoriser le

développement Yes Yes

Augmentation des

processus à disposition - -

Réutilisation des

ressources

One of the principals

reasons Yes

FINANCIER

Coût de l’implémentation - -

Coût de la maintenance Increase of costs Not quantified

Coût de l’infrastructure - -

62 5. Etudes de cas

Comme discuté précédemment, la compagnie d’assurance a opté cette méthode

d’intégration orientée service surtout pour ses avantages au niveau organisationnel.

Nous pouvons d’ailleurs le constater en observant la partie supérieure du tableau.

Seule la partie concernant les attentes et les réalités de SOA au niveau

organisationnel comportent des commentaires. Les deux autres catégories à savoir

l’aspect technique et l’aspect financier ne sont pas pris en compte dans l’analyse

puisqu’elles ne s’avèrent pas faire partie des principaux critères de besoins de

l’entreprise.

Au niveau organisationnel, les attentes de la compagnie étaient grandes. La forte

pression concurrentielle oblige la firme à opter des positions avantageuses. Pour

ceci, la compagnie d’assurance avait des attentes de l’approche SOA très élevés en

termes de flexibilité. Plus un système est flexible, plus il devient facile de réagir

rapidement à une quelconque évolution du marché. Ainsi, la flexibilité des

technologies utilisées permet de gagner des positions intéressantes sur le marché

lorsque celles-ci sont exploitées de manière optimale. L’adoption de la démarche

SOA a engendré certes, des améliorations dans le système et augmenter la flexibilité

mais ceci n’est toujours pas suffisant en rapport avec les attentes initiales. Par

exemple, la firme juge que la modification des services existants ainsi que

l’intégration des nouveaux processus sont des deux principes qui demeurent assez

complexes à mettre en pratique.

Même si les principaux objectifs poursuivis sont au niveau organisationnel, la

compagnie d’assurance a tout de même observé des avantages en termes

techniques et financiers. En effet, grâce à la SOA, il fut possible de réutiliser

certaines ressources. Ce principe permettant une meilleure optimisation et une

allocation efficace des ressources a permis la diminution des coûts de

développement informatique lié à l’architecture logicielle, qui est tout de même

impossible à quantifier.

63 5. Etudes de cas

5.2.5. L’utilité réelle de SOA dans l’entreprise

Comme pour l’exemple précèdent, cette étude a été réalisée dans le but de

connaître la réelle utilité de la démarche d’intégration orientée service.

Dans le cas de cette compagnie d’assurance, l’accent est principalement mis sur

l’utilité organisationnelle que procure SOA. En effet, par cette architecture orientée

service, l’entreprise détient un système d’information flexible et permettant d’être plus

performant à certains niveaux du système d’information.

Sachant que plus de 30% de l’architecture logicielle de la firme est implémentée par

les principes SOA, l’importance de ce concept devient évidente. Ce type

d’architecture répond aux attentes de l’entreprise au niveau de la performance. En

effet, comme tous les services ne sont pas implémentés par l’architecture orientée

service et que le système fonctionne simultanément avec d’autres architecture

également, il est évident que SOA ne peut pas assurer une performance intégrale au

système d’information de l’entreprise à elle seule.

Même si toutes les attentes de la firme au niveau organisationnel ne sont pas

entièrement comblées, elles ne demeurent pas pour autant insatisfaites. Le gain

réalisé au niveau du changement possible grâce à l’approche SOA est bien plus

conséquente que le gain amené au niveau exécutif par la SOA. Ceci est

généralement du au couplage faible même voir au découplage à certains niveaux.

Ce type de couplage entre les services engendre une légère baisse de la

performance à court terme, mais une diminution massive des efforts nécessaires

face aux éventuels changements futurs. De ce fait, l’utilisation d’une telle

architecture, même à raison d’un tiers dans toute l’architecture logicielle, offre à la

firme des gains bénéfiques sur le long terme. Le système d’information adopte un

caractère plus agile et moins complexe.

La firme n’avait pas fixé d’objectifs en termes financiers et techniques lors de

l’adoption de la démarche SOA. Toutefois, cela ne signifie pas pour autant qu’il n’y a

aucun avantage d’ordre technique et financier. Bien entendu, SOA a simplifié la

structure de leur complexe système en permettant la réutilisation des ressources. Le

caractère de réutilisabilité des ressources à disposition fait de ce principe le plus

64

avantageux en termes de flexibilité apportée à l’intérieur même du système. En

terme financier, l’implémentation de la SOA permet de réduire les efforts de

développements futurs en cas de changements nécessaires. Il est évident que la

baisse des coûts informatiques reste un argument majeur à l’adoption de tout type de

projet informatique. Toutefois, il est impossible pour la firme de quantifier ce gain sur

le plan financier.

La vision de cette grande compagnie d’assurance tournée vers l’innovation oblige la

firme à défendre sa position de leader dans de nombreux domaines. De ce fait, le

développement devient le mot d’ordre de la stratégie d’entreprise tant sur le plan

stratégique qu’opérationnel. Le développement informatique s’inscrit alors dans cette

stratégie d’entreprise comme un incontournable outil de réussite. Comme l’affirme le

responsable IT de la compagnie, il n y a pas moyens d’échapper à l’utilisation de ce

type d’architecture surtout dans leur environnement orienté évolution, nécessitant de

créer leurs applications eux-mêmes. Les changements et les modifications dans le

système sont tellement fréquents qu’aucune autre architecture ne pourrait leur

permettre d’y répondre aussi rapidement. De ce fait, la présence de ce type de

technologie agile SOA dans leur architecture logicielle, leur est bénéfique en tout

point.

65 6. Résultats des études de cas : La réalité du SOA

6. Résultats des études de cas : La réalité du SOA

Ce dernier chapitre se concentre sur les éléments précédents afin de synthétiser les

réponses obtenus et les analyser en mettant en évidence les avantages de SOA

ainsi que les lacunes de SOA afin d’en mesurer l’utilité réelle.

Il est ici question de comparaison entre des arguments théoriques émanant de la

littérature informatique et des expériences pratiques d’utilisateurs directs pour

réaliser le potentiel économique de la démarche SOA.

Les études de cas réalisées auprès de deux entreprises en Suisse, ont démontré

l’existence de diverses raisons à l’adoption de cette approche. Les entreprises sont

amenés à adopter ce concept non pas seulement en fonction de leur besoin, mais

également en fonction des contraintes imposées par leurs environnements et leur

stratégie. L’Office de la Circulation et de la Navigation fut dans l’obligation de l’opter

à cause de ses relations avec divers partenaires, alors que la compagnie

d’assurance l’a intégrer telle un outil nécessaire à la mise en place d’un projet

informatique.

Dans cette logique, aucune des deux entreprises n’ont été amené à fixer des

objectifs à viser avec l’adoption de la SOA. Toutefois, une fois intégrée, il est devenu

essentiel aux firmes de retirer des gains de cette architecture sur le plan

organisationnel, technique et financier.

6.1. Les avantages de SOA

Malgré le fait que les deux entreprises analysées sont actives dans des secteurs

différents, le principal avantage qu’elles ont retirés de cette approche SOA reste le

même : l’augmentation de la flexibilité du système d’information grâce à une

architecture logicielle modulable. Cette constatation met en évidence l’importance

des aspects organisationnels et techniques lors de la mise en place d’une telle

technologie et vient confirmer l’existence des avantages sous ces aspects, explicités

dans la partie théorique du travail.


En effet, la flexibilité est présentée comme le mot d’ordre dans la littérature

informatique. Cette nécessité s’explique par la mutation technologique. Nous

évoluons dans un monde compétitif, où la concurrence est de plus en plus rude sur

le marché. Chaque acteur de cet ensemble, est dans l’obligation de se démarquer

des concurrents afin de protéger ou même d’améliorer sa position. La pression est

d’une telle envergure qu’elle crée à elle-même le changement. Les technologies de

l’information se diversifient tous en se complexifiant. La capacité de réaction des

firmes face à ces transformations devient alors indispensable à leur réussite. Raison

pour laquelle, la grande majorité des entreprises tente de se doter de technologies

modulables et flexibles sur le plan informatique.

Nous avons pu constater dans les études de cas que la technologie SOA est

bénéfique pour les deux entreprises en termes de flexibilité. Elle permet à chacune

des deux institutions de faire face aux changements rapidement grâce à la

modularité de ses services. Toutefois, ce type d’architecture ne réduit pas pour

autant la complexité du système intégral et de ce fait contredit nos arguments

théoriques sur ce point.

D’un point de vue technique, les avantages théoriques discutés dans la première

partie du travail ne sont que partiellement obtenus. En effet, aucune des deux cas

analysés ne poursuivaient des objectifs techniques par l’implémentation de la SOA.

Pourtant la réutilisation des ressources a permis aux deux entreprises d’augmenter la

performance de leur SI grâce au couplage faible mise en œuvre dans l’architecture

SOA.

Même que la réutilisation des ressources reste complexe pour l’OCN, elle demeure

néanmoins un atout non négligeable pour la compagnie d’assurance. Avec un tel

avantage, l’entreprise n’est pas obligé de créer des nouveaux services pour chaque

nouvelle requête sachant que ceux-ci existent déjà dans le système. Quant à l’OCN,

la complexité rencontrée pour la réutilisation des services existants s’explique par

l’existence d’un fort couplage entre certains services. Dans ces situations, il devient

très complexe de faire appel à un service déjà existant. Ce principe détaillé dans le

chapitre 2.2.4 offre aux deux institutions des opportunités de développement en leur

permettant de réduire leurs coûts informatiques.


Théoriquement parlant, la réutilisation des composantes devrait permettre

l’augmentation des processus. Dans les études de cas, ceci ne s’est confirmée que

partiellement. En effet, pour la compagnie d’assurance ce principe a largement

contribué à l’augmentation des processus et à la simplification des parties du

système implémenté avec la SOA. En ce qui concerne l’OCN, ce principe fut plus

difficile à mettre en place à cause de la complexité de leur système. Pour contrer la

complexité, ils préfèrent démultiplier les services pour favoriser l’intégration des

nouveaux processus. Le principe de réutilisabilité des composantes reste un

avantage important même qu’il soit mitigé en fonction des situations.

En dépit du fait que les avantages théoriques en termes organisationnels et

techniques ne sont pas entièrement réalisés dans la pratique, ils en demeurent

néanmoins évidents. Les résultats rencontrés dans les études de cas sont

surprenantes dans l’optique financière de la démarche. En effet, dans la première

partie du travail, nous avions affirmés le poids important des coûts dans ce type de

démarche. Aucune des deux entreprises n’a cherché à obtenir de manière directe la

diminution des coûts informatiques. Cette constatation contredit les arguments

financiers que nous avions exposés dans la première partie. La diminution des coûts

informatiques n’est de loin pas l’argument principal à l’adoption du concept orientée

service. Toutefois, nous pouvons tout de même observer dans les deux cas, une

diminution des coûts non quantifiable. Chacune des deux firmes ont vu des

avantages financiers en termes d’épargne des éventuels frais informatiques en cas

de modifications nécessaires dans le futur. La SOA est en quelques sortes un outil

d’anticipation permettant aux entreprises de réaliser des gains sur les éventuels frais

futurs dus aux évolutions technologies ou autres.

6.2. Les lacunes de SOA

Les principales lacunes de la démarche SOA sont difficiles à déterminer sur la base

de ces deux études de cas. En effet, aucune des deux firmes questionnées ne se

sont explicitement prononcés sur le sujet. Ceci est dû au fait, qu’aucune d’entre elles

n’ont analysé les lacunes de leur architecture SOA. Toutefois, en se basant sur leurs

expériences, nous pouvons en déterminer certaines.


Une des difficultés majeures rencontrées fut la durée et les moyens nécessaires à la

mise en place de cette architecture pour les deux cas analysés. En effet, le manque

d’expérience des collaborateurs dans ce domaine a induit à un prolongement de la

durée de son adaptation sans compter les coûts d’implémentation gigantesques qu’a

engendré l’adoption de cette démarche. Il fut nécessaire de mettre en place des

formations internes pour les utilisateurs. Le développement continu nécessaire dans

les technologies de l’information ont nécessité des coûts supplémentaires à la mise à

jour continue des systèmes. De ce fait, la solution SOA n’a pas permis une réduction

des coûts comme promis théoriquement. Toutefois, la plus grande difficulté de

l’adoption d’une telle architecture est l’investissement personnel de chaque

collaborateur concerné. Le réel engagement des collaborateurs fut incontournable à

la réussite de la mise en place de ce concept surtout pour le cas de l’OCN.

Une des autres problèmes rencontrés est la part qu’occupe la SOA dans toute

l’architecture logicielle des deux cas traités. En effet, les deux entreprises possèdent

simultanément avec la SOA d’autres types d’architecture d’intégration. La

coexistence de plusieurs différentes architectures peut amener certains problèmes

notamment dus à leurs divergences de fonctionnement. Moult processus

fonctionnant différemment entrant en ligne de compte, complexifient les systèmes

encore plus que ce qu’ils ne le sont déjà.

En somme, l'architecture SOA est un outil indispensable et nécessaire au

développement de leur système d’information. Monsieur Savary de l’OCN le décrit

comme « une parmi plusieurs tentatives passées et présentes afin d'aboutir à une

véritable urbanisation des systèmes d'information ». La SOA est une des meilleures

perspectives permettant l’accomplissement de cette urbanisation. Chez la compagnie

d’assurance, le bilan se décrit de la même manière : la SOA est une technologie

incontournable même si des améliorations seront toujours nécessaires.


6.3. Analyse globale de l’utilité de SOA

Le principal but de ce travail de Bachelor est de connaître la réelle utilité de

l’architecture orientée service au sein des entreprises de nos jours. Au début de ce

travail, plusieurs avantages ont été discutés d’un point de vue théorique. Dans la

seconde partie, l’analyse pratique nous a démontré les divergences entre

l’expérience pratique et la littérature théorique sur la démarche SOA. Sur la base de

ces deux parties, nous pouvons enfin synthétiser ce travail pour en déduire l’utilité de

ce concept dans les organisations l’exploitant.

Nous pouvons ressortir des deux précédentes parties trois conclusions

fondamentales concernant l’utilisation de la SOA au sein des entreprises aujourd’hui.

En premier lieu, nous avons pu remarquer que les utilisateurs SOA ont une bonne

vision de ce concept. Il est tantôt perçu comme une solution optimale pour l’évolution

des systèmes d’informations, et tantôt considéré comme un outil fondamental pour le

bon fonctionnement de l’infrastructure informatique. Toutefois, même si la SOA

demeure une technologie qui tient sa place dans les politiques informatiques, elle

nécessite tout de même des améliorations afin de répondre à tous les problèmes que

l’on pourrait rencontrer.

En second lieu, nous remarquons que l’approche SOA a autant d’avantages que

d’inconvénients aux trois niveaux d’analyse, à savoir organisationnel, technique et

financier. D’un point de vue organisationnel, elle permet plus de flexibilité donc plus

de marge de manœuvre en cas de modification nécessaire ou face à un changement

technologies. La maniabilité de cette architecture lui confère un caractère agile et de

ce fait plus flexible. Sous un regard technique, la réutilisabilité des services est l’atout

majeur de la SOA. Par cette possibilité, le système se simplifie à certains niveaux et

devient plus opérationnel. Quant aux avantages théoriques promis par la SOA au

niveau financier, ils ne sont pas vérifiés dans la pratique. Aucune des entreprises

n’ont pu voir la réduction directe des coûts. Toutefois, nous avons pu observer dans

le cas de la compagnie d’assurance que cette technologie avait un énorme avantage

financier dans le futur lorsqu’une éventuelle modification devra être appliquée.

70

En dernier lieu, aucune des entreprises analysées n’ont opté l’approche SOA de

manière complète. La solution SOA n’a pas été implémentée intégralement et de ce

fait analyser ce concept alors qu’il n’est que partiellement intégrée n’en démontre pas

les réelles opportunités. La seule réelle utilité de cette démarche qui est une

évidence est sa capacité à augmenter la flexibilité des systèmes d’informations.

De manière générale, nous pouvons constater que les avantages promis au niveau

théorique ne sont que partiellement réalisés dans la pratique. Ceci n’empêche pas

pour autant la vision positive que portent les utilisateurs à l’égard de la SOA et

justifient ainsi l’adoption d’une telle technologie dans les politiques informatiques des

firmes.

71 7. Conclusion

7. Conclusion

L’objectif de base de ce mémoire était de connaître l’utilité organisationnelle,

technique et financière de l’architecture orientée service en comparant les dits

théoriques avec les faits pratiques. Tout au long de ce travail nous avons tenté de

donner une réponse claire à la question émanant de cette recherche : quelle est la

réelle utilité de la SOA ?

Ce raisonnement qui fut présent tout au long de la rédaction de ce travail a abouti à

plusieurs réponses, tantôt satisfaisantes et tantôt surprenantes. Nous avons pu

constater que le concept au niveau théorique ne correspond pas toujours au concept

dans la pratique.

Ce travail qui nous a permis d’étudier une technologie informatique spécifique dans

les domaines de l’informatique de gestion, fut divisé en deux grandes parties

distinctes. La première partie portait sur le concept de la SOA d’un point de vue

théorique. Le but était de comprendre ce concept et les avantages qu’il peut offrir. En

2013, ce sujet a été traité et analysé sous tous ses angles par des professionnels du

domaine. Une quantité non négligeable d’œuvres littéraires, d’articles scientifiques et

de recherches ont été élaborés à ce jour et dont certains ont été utilisés dans la

rédaction de cette partie. Par contre, le nombre de firmes ayant adopté la démarche

SOA en Suisse semble moins important, constaté dans la seconde partie du travail

axée sur l’expérience pratique de la SOA. Notre but était de voir jusqu’à quel niveau,

cette architecture est utile aux entreprises en Suisse, en présentant le cas de deux

entreprises suisses du secteur privé et publique.

Certes il est quasi impossible de donner une réponse à cette question sur la base de

deux études de cas seulement, mais cela ne nous empêche pas d’avoir une idée de

son utilisation. Néanmoins, les résultats obtenus de ces cas, nous permettent de dire

clairement que l’architecture orientée service tient sa place dans toute architecture

logicielle souhaitant agilité et flexibilité. Ce travail de Bachelor nous a démontré que

ce concept, même que concurrencé aujourd’hui par d’autres technologies, garde un

potentiel important de croissance et s’avère être un outil fondamental dans la

continuité de l’optique d’évolution des systèmes d’informations.

72 8. Bibliographie

8. Bibliographie

8.1. Littérature

[Bell, 2006] Bell Marks: Service-Oriented Architecture: a planning and

implementation guide for business and technology, Hoboken, John Wiley & Sohns,

2006.

[Bonnet, Detavernier, Vanquier 2008] Bonnet Pierre; Detavernier Jean-Michel ;

Vauquier Dominique : Le Système d’information durable: la refonte progressive du

SI avec SOA, Paris, Hèrmes Science, 2008.

[Club Urba-EA 2010, p.3-6] Club Urba-EA, Urbanisme des SI et Gouvernance,

Dunod, 2010

[Erl 2008] Erl Thomas: SOA principles of Service Design, Indiana, Prentice Hall,

2008.

[Erl 2006] Erl Thomas: Service-Oriented Architecture, Concept, Technology, and

Design, Indiana, Prentice Hall, 2006.

[Fournier-Morel, Grosjean, Plouin, Rognon 2011] Fournier-Morel Xavier, Grosjean

Pascal, Plouin Guillaume, Rognon Cyril : SOA Le guide de l’architecte d’un SI agile,

Paris, Dunod, 2011.

[Gordon, Olson, Ajenstat, Peaucelle 1986] Gordon, B. Davis ; Olson, Margrethe

H.; Ajenstat, Jacques, Paucelle, Jean-Louis : Systèmes d’information pour le

management. Boucherville, Edition G. Vermette, 1986.

[Grenier, Moine 2003] Grenier, Claude ; Moine, Camille : Construire le système

d’information de l‘entreprise. Paris, Foucher, 2003.

[Heutschi 2007 ] Heutschi Roger: Serviceorientierte Architektur, Architekturprinzipen

und Umsetzung in die Praxis, Berlin, Springer, 2007.

73 8. Bibliographie

[Holley, Dr. Arsanjani, 2011] Holley Kerrie, Dr. Arsanjani Ali: 100 SOA Questions

Asked and Answered, Indiana, Prentice Hall, 2011.

[Hüsemann 2011] Hüsemann, Stefan : Systèmes d’information I. Université de

Fribourg, Suisse, 2011

[Krafzig, Banke, Slama 2006] Krafzig Dirk; Banke Karl ; Slama Dirk : Enterprise

SOA : Service-Oriented Architecture Best Practice, Prentice Hall, 2006.

[Liebhart 2007] Liebhart Daniel: SOA goes real: Service-Orientierte Architekturen

erfolgreich planen und einführen. München, Hanser, 2007.

8.2. Articles, documents, présentations

[BEA SYSTEMS, 2005] Méthodologie SOA en six domaines, Révéler les avantages

métiers d’une Architecture Orientée Services, BEA SYSTEMS, 2005

http://img1.lemondeinformatique.fr/ftp/partnerzone/BEA/livresblancs/livreblanc_metho

dSOA.pdf

[Debray, IBM Software Group, 2005] De la modélisation Métier à l’implémentation

SOA, Séminaire Mettre en œuvre aujourd'hui une Architecture Orientée Services

(SOA), Luc Debray, Paris, 2005

ftp://service.boulder.ibm.com/software/fr/event/soa/SOA2juinCBMtoSOA-LucDebray-

V2.pdf

[Gartner Group 2008] Building an SOA Business Case: A Gartner Framework,

Gartner Group, Anthony Bradley, W Schulte, Daniel Sholler, Paolo Malinverno, 2008

[Laftimi, CNAM 2009] SOA (Service Oriented Architecture) Architectures Orientées

Services, Ahmed Laftimi, CNAM 2009

http://home.nordnet.fr/~ericleleu/cours/nfe107/SOA.ppt

[Michoud, Abissa Informatique 2008] L’approche SOA, Olivier Michoud, Abissa

Informatique, 2008

http://img1.lemondeinformatique.fr/ftp/partnerzone/BEA/livresblancs/livreblanc_methodSOA.pdf

http://img1.lemondeinformatique.fr/ftp/partnerzone/BEA/livresblancs/livreblanc_methodSOA.pdf

ftp://service.boulder.ibm.com/software/fr/event/soa/SOA2juinCBMtoSOA-LucDebray-V2.pdf

ftp://service.boulder.ibm.com/software/fr/event/soa/SOA2juinCBMtoSOA-LucDebray-V2.pdf

http://home.nordnet.fr/~ericleleu/cours/nfe107/SOA.ppt

74 8. Bibliographie

http://www.abissa.ch/data/fichiers/tec_architecture_soa.pdf

[Madsen, Loureiro, Groupe CGI, 2006] Exploitez la pleine puissance de

l'architecture orientée services (SOA) en la combinant à la modélisation des

processus d'affaires, Michael Madsen, Rodrigo Loureiro, Groupe CGI, 2006

http://www.cgi.com/files/white-papers/cgi_whpr_67_soa_bpm_wp_f.pdf

[Raymond, Softeam, 2011] SOA: Architecture Logique : Principes, structures et

bonnes pratiques, Raymond Gilbert, Softeam, Paris, 2011

http://www.softeam.fr/sites/default/files/files/Livre%20blanc-

SOA%20Architecture%20Logique.pdf

[SAP AG, University of St. Gallen, 2008], SAP AG, University of St. Gallen,

Economic Justification of Service-Oriented Architecture, Research Study:

Experiences and Guidelines on Building SOA Business Cases, 2008

http://www.sap.com/brazil/temp/Economic_Justification_of_SOA.pdf

[SAP AG, University of St. Gallen, Saat, Discher, 2009] Economic Justification of

SOA, Jan Saat, Institute of Information Management, University of St. Gallen, Stefan

Discher, Global Platform Marketing, SAP AG, 2009

[Softeam, Guide pratique Objectering, 2008] Le Guide Pratique des Processus

Métiers, Equipe Conseil Softeam, Paris, 2008

http://support.objecteering.com/objecteering6.1/tutorials/fr/guides/business_process_

guide_fr.pdf

[Soto, IBM Corporation, 2008] Augmenter la flexibilité de l’entreprise grâce à

l’architecture orientée service, Soto David, IBM Corporation, 2008

http://www.bitkom.org/files/documents/P2_5_Wirtschaftlichkeit_von_SOA_StGallen_

SAP_FO_SOA_2009.pdf

http://www.abissa.ch/data/fichiers/tec_architecture_soa.pdf

http://www.cgi.com/files/white-papers/cgi_whpr_67_soa_bpm_wp_f.pdf

http://www.softeam.fr/sites/default/files/files/Livre%20blanc-SOA%20Architecture%20Logique.pdf

http://www.softeam.fr/sites/default/files/files/Livre%20blanc-SOA%20Architecture%20Logique.pdf

http://www.sap.com/brazil/temp/Economic_Justification_of_SOA.pdf

http://support.objecteering.com/objecteering6.1/tutorials/fr/guides/business_process_guide_fr.pdf

http://support.objecteering.com/objecteering6.1/tutorials/fr/guides/business_process_guide_fr.pdf

http://www.bitkom.org/files/documents/P2_5_Wirtschaftlichkeit_von_SOA_StGallen_SAP_FO_SOA_2009.pdf

http://www.bitkom.org/files/documents/P2_5_Wirtschaftlichkeit_von_SOA_StGallen_SAP_FO_SOA_2009.pdf

75 8. Bibliographie

8.3. Webographie

[Abraxas Cari 2011] Juin 2013

http://www.abraxas.ch/fileadmin/customer/Dokumente/Produkte/Abx_CARI_Prod_fr.p

df

[Barry, Barry&Associates, 2013] Avril 2013

http://www.service-architecture.com/

[Ben Driss Khaled, 2007] SOA: Démystification, Khaled Ben Driss, Février 2013

http://fr.slideshare.net/kbdsoft/soa-architecture-oriente-service-dmystification-khaled-

ben-driss-21-nov-2007-v121

[CIO UK, 2011] Avril 2013

http://www.cio.co.uk/news/architecture/forrester-claims-soa-projects-still-alive-and-

well/

[Confédération Suisse 2013] Juillet 2013

http://www.bit.admin.ch/org/index.html?lang=fr

[Gartner Group 2011] Mai 2013

http://www.gartner.com/newsroom/id/1632714

[Gartner Group 2013] Février 2013

http://www.gartner.com/id=391595

[IT- Expert Magazine, 2011] Mai 2013

http://www.it-expertise.com/gouvernance-des-architectures-soa-entre-controle-et-

flexibilite/

[Jemm Vision & Jemm Research, 2012] Avril 2013

http://www.jemmvision.com

http://www.abraxas.ch/fileadmin/customer/Dokumente/Produkte/Abx_CARI_Prod_fr.pdf

http://www.abraxas.ch/fileadmin/customer/Dokumente/Produkte/Abx_CARI_Prod_fr.pdf

http://www.service-architecture.com/

http://fr.slideshare.net/kbdsoft/soa-architecture-oriente-service-dmystification-khaled-ben-driss-21-nov-2007-v121

http://fr.slideshare.net/kbdsoft/soa-architecture-oriente-service-dmystification-khaled-ben-driss-21-nov-2007-v121

http://www.cio.co.uk/news/architecture/forrester-claims-soa-projects-still-alive-and-well/

http://www.cio.co.uk/news/architecture/forrester-claims-soa-projects-still-alive-and-well/


http://www.gartner.com/newsroom/id/1632714

http://www.gartner.com/id=391595

http://www.it-expertise.com/gouvernance-des-architectures-soa-entre-controle-et-flexibilite/

http://www.it-expertise.com/gouvernance-des-architectures-soa-entre-controle-et-flexibilite/

http://www.jemmvision.com/

76 8. Bibliographie

[Le Monde Informatique 2006] Mai 2013

http://www.lemondeinformatique.fr/actualites/lire-le-business-s-approprie-la-soa-

estime-le-cabinet-gcr-custom-research-21420.html


http://www.lemondeinformatique.fr/actualites/lire-les-depenses-en-soa-augmentent-

les-risques-aussi-note-amr-research-25444.html


http://www.lemondeinformatique.fr/actualites/lire-depenses-soa-24-entre-2008-et-

2013-selon-idc-30289.html

[Microsoft Corporation 2009] Mai 2013

http://www.microsoft.com/france/entreprises/plateforme-

applicative/scenarios/details/business-processandsoa.aspx

[OCN 2013] Juillet 2013


[SOA Blog, 2010] Mars 2013

http://www.soablog.fr/2010/02/01/presentation-du-cadre-de-reference-framework-de-

la-gouvernance-soa/

[Wikipedia, 2013] Février 2013

http://fr.wikipedia.org/wiki/Couplage_(informatique)

[Xebia IT Architects, 2007] Avril 2013

http://blog.xebia.fr/2007/08/16/mise-en-oeuvre-dune-soa-les-cles-du-succes/

http://www.lemondeinformatique.fr/actualites/lire-le-business-s-approprie-la-soa-estime-le-cabinet-gcr-custom-research-21420.html

http://www.lemondeinformatique.fr/actualites/lire-le-business-s-approprie-la-soa-estime-le-cabinet-gcr-custom-research-21420.html

http://www.lemondeinformatique.fr/actualites/lire-les-depenses-en-soa-augmentent-les-risques-aussi-note-amr-research-25444.html

http://www.lemondeinformatique.fr/actualites/lire-les-depenses-en-soa-augmentent-les-risques-aussi-note-amr-research-25444.html

http://www.lemondeinformatique.fr/actualites/lire-depenses-soa-24-entre-2008-et-2013-selon-idc-30289.html

http://www.lemondeinformatique.fr/actualites/lire-depenses-soa-24-entre-2008-et-2013-selon-idc-30289.html

http://www.microsoft.com/france/entreprises/plateforme-applicative/scenarios/details/business-processandsoa.aspx

http://www.microsoft.com/france/entreprises/plateforme-applicative/scenarios/details/business-processandsoa.aspx


http://www.soablog.fr/2010/02/01/presentation-du-cadre-de-reference-framework-de-la-gouvernance-soa/

http://www.soablog.fr/2010/02/01/presentation-du-cadre-de-reference-framework-de-la-gouvernance-soa/

http://fr.wikipedia.org/wiki/Couplage_(informatique)

http://blog.xebia.fr/2007/08/16/mise-en-oeuvre-dune-soa-les-cles-du-succes/

77 9. Annexes

9. Annexes

Annexe 1: « SOA Infrastructures Costs »

Documents

SOA : L’utilité organisationnelle, technique et...La première partie met en lumière des concepts de la SOA en se référant à la littérature appropriée ainsi que sur des articles