SI Architecture Orientee Services SOA en

Université Hassan II Mohammedia - Casablanca
Ecole Nationale de Commerce et de Gestion
Réalisé par :
Architecture orientée services

SI
(SOA)
Réalisé Par :
AMER Mounia
EL BABSIRI Najlaa
EL HARTI Abir Encadré par :
GUENNANI El mehdi Mme. JABRAOUI Siham
HARTI Soukaina
RABIB Oumaima
RAMIJ Sophia
SAIL Sara
Année universitaire : 2016/2017

Architecture orientée services (SOA) 2016/2017
Sommaire
INTRODUCTION ..................................................................................................................... 2
1. QU’EST-CE QUE LE SOA ? ............................................................................................. 5
1.1 Définition du système d’information Agile .................................................................... 5
1.2 Définition du SOA .......................................................................................................... 5
1.3 Architecture SOA clef de l’agilité ................................................................................... 5
1.4 Les objectifs de la SOA ................................................................................................... 6
2. Les composant et les principes du SOA ......................................................................... 6
2.1 Les composants de la SOA ............................................................................................. 6
2.2 Les principes de la SOA ................................................................................................. 7
3. Mise en œuvre d’une SOA ................................................................................................ 8
3.1 Méthodologie à suivre pour implémenter une SOA ........................................................ 8
3.2 Clés de succès ................................................................................................................ 11
3.3 Coûts de l’approche ....................................................................................................... 13
4. Avantages de l’architecture orientée service ............................................................... 15
4.1 Au niveau organisationnel : la flexibilité du système ................................................... 15
4.2 Au niveau technique : la réutilisabilité des services ..................................................... 16
4.3 Au niveau financier : la baisse des coûts ....................................................................... 17
5. Les limites de la SOA ..................................................................................................... 18
5.1 La sécurité (liée à l’implémentation) ........................................................................... 18
5.2 Le manque de compétences (lié à l’architecture et au design) ...................................... 19
5.3 Coût de la mise en place de la SOA .............................................................................. 21
5.4 La lenteur d’exécution ................................................................................................... 21
6. Etude de cas ..................................................................................................................... 22
Conclusion .............................................................................................................................. 27
Bibliographie/ Webographie ................................................................................................. 28
1
INTRODUCTION
Depuis quelques années, Les entreprises n’étaient guère équipées d'un

système d'information intégré. Elles endurent jusqu’à ce jours des systèmes mixtes
et hétérogènes, elles possèdent différentes applications développées en différentes
plateformes, utilisant différentes technologies et langages de programmation .Ces
applications sont sous différents modèles ou architectures
- combinaison de monolithique, client/serveur, et application multi-tiers,

- mélange de solutions procédurales, orientées objet et à base de composants,
- Mélange de langages de programmation,
- Différents types de SGBD (relationnel, objet, hiérarchique ….) et de produits
- Différentes solutions de middleware pour la communication (MOM : message
Oriented Midelware, ORB : object Request Broker, RPC : Remote procedural
Calls …etc.)
- Différents middleware de gestion de transactions et de sécurité,
- Différentes manières de partage de données
- Multiples protocoles et modèles de transmission d'informations.
Dans un système traditionnel, « legacy » est défini comme tout système

logiciel qui est difficile à maintenir, mais qui est souvent indispensable à
l’organisation. Une autre définition qui attire l’attention est donnée par (Semih Srtin et
al) qui considère tout logiciel implémenté avec une technique pré-SOA comme
application legacy « any software artifact that was built using pre-soa techniques is
legacy ».
Les systèmes legacy ne permettent pas une agilité des systèmes d'information
de l’entreprise ce qui est due à la difficulté de s'adapter rapidement et à moindre coût
avec le changement du métier. Autre problème, l'intégration des applications de
l'entreprise, des solutions très utiles ont été proposées tel que MOM, ORB, RPC,
EAI, ERP qui sont des technologies d'intégration très utilisées dans les applications
traditionnelles, mais cette intégration n'a pas pu surmonter les deux chausse–trappes
en particulier le couplage technique et fonctionnel entre consommateur et fournisseur
de services.
A titre d’exemple, l’ERP qui est un système d’information fonctionnel qui a

connu une forte concentration sur le marché des ERP et qui a pu combler des
différents problèmes naissant des autres systèmes mais qui reste aussi un système
riche de limites fonctionnelles (L'ERP est un système critique ;ERP et flexibilité :
règles de paramétrage strictes ;Modification des modes de contrôle de
l'entreprise),limites techniques (Ressources réseaux pour les systèmes client serveur
2
classique ;Complexité des bases de données ;Interfaçage avec les autres SI : le

problème de format propriétaire ;ERP et système décisionnel : difficulté pour l'apport
de données externes).
D’où la nécessité de création de nouveaux systèmes qui doivent s’adapter

rapidement en fonction des changements du métier et du marché. La solution est
dans l'architecture orientée service SOA qui se base sur le couplage lâche entre les
services, donc une adaptabilité plus rapide et à moindre coût. Pour assurer l’agilité
des SI et permettre une utilisation des services, de façon à satisfaire les processus
métier et les utilisateurs, il est important d’avoir une architecture software orientée
service (SOA).
Cette orientation dans le développement des systèmes est exigée de nos jours, car
le monde, le métier et le marché changent rapidement; mais est-ce que les
entreprises doivent remplacer définitivement les systèmes existants dits legacy
systems par des systèmes créés à zéro? La réponse est non pour plusieurs raisons :
 Ils sont le résultat d'un énorme investissement ;

 Ils enregistrent la connaissance, l'expertise, et les principes économiques
qui peuvent ne pas être disponibles partout ailleurs que dans le code source
 Les coûts et les risques pour développer un système de rechange peuvent
être inaccessibles et le développement en question prendra de toute façon
plusieurs années avant que la fonctionnalité du code legacy soit sûrement
remplacée par le nouveau système;
Ce qu'il faut faire est donc d’intégrer ces systèmes traditionnels dans le
nouveau système à base de SOA en présentant leurs fonctionnalités sous forme de
services interrogeables et réutilisables en attendant que le nouveau système soit
reconstruit sur les nouvelles normes. Cet article décrit une architecture multi-agent
pour l’encapsulation des fonctionnalités des système à base d’architecture CORBA en
les présentant en tant que service web réutilisable et invocable par autres services,
afin de permettre leurs intégration en des système à base d’architecture orienté
services SOA.
Dans ce projet, nous allons s’intéresser à l’analyse du système SOA afin de

pallier aux problèmes des anciens systèmes pré-SOA ou autrement comment le
système SOA réagit au sein des entreprises tout en tenant compte de répondre à la
question suivante :
 Le SOA répond réellement aux attentes des entreprises comme il est

censé le faire ?
Pour ce faire , nous avons élaboré un plan de recherche et d’interprétation

s’intéressant dans un premier chapitre à ce que définit le SOA ainsi dans un
deuxième, il a été nécessaire d’aborder les principes, composantes et
3
implémentation du système et comme troisième partie- indispensable dans chaque

travail- on va voir les avantages et les limites du SOA et enfin, pour appuyer notre
étude, la mise en place d’une étude de cas concrète dans une entreprise marocaine
est bénéfique pour la bonne compréhension des enjeux du système.
4
1. QU’EST-CE QUE LE SOA ?
1.1 Définition du système d’information Agile :
Un système d’information agile est un système qui est capable de s’adapter

aux évolutions fonctionnelles et techniques, qui est plus ouvert afin d’absorber les
processus de gestion avec les tiers, qui permettra l’évolution de l’organisation sans
remise en cause des applicatifs métier. Ce système d’information d’un nouveau
genre devra être capable de se recycler au cours du temps, il sera prévu pour se
reconfigurer proprement sans générer de scories applicatives. C’est un système
d’information durable.
1.2 Définition du SOA :
SOA est un style architectural qui permet de construire des solutions

d’entreprises basées sur les services. Le service est une action exécutée par un
fournisseur à l'attention d'un client, cependant l'interaction entre client et
fournisseur est faite par le biais d'un médiateur (qui peut être un bus) responsable de
la mise en relation des composants. L’aspect le plus important de l’architecture SOA
selon est qu’elle permet de séparer l’implémentation du service de son interface.
1.3 Architecture SOA clef de l’agilité :
Pour assurer l’agilité des SI et permettre une utilisation des services, de façon
à satisfaire les processus métier et l’utilisateur, il est important d’avoir une
architecture software orientée service (SOA).
Les systèmes d’information doivent pouvoir s’adapter rapidement en fonction
des changements du marché. Les architectures orientées services (SOA pour
Service Oriented Architectures) ont été définies pour répondre à des besoins de
réutilisation et d’adaptabilité. Une architecture orientée services est un style
d’architecture fondée sur la description de services et de leurs interactions. Les
caractéristiques principales d’une architecture orientée services sont le couplage
faible, l’indépendance par rapport aux aspects technologiques et l’extensibilité.
La propriété de couplage faible implique qu’un service n’appelle pas
directement un autre service; les interactions sont gérées par une fonction
d’orchestration. Il est donc plus facile de réutiliser un service puisqu’il n’est pas
directement lié aux autres.
L’indépendance par rapport aux aspects technologiques est obtenue grâce
aux contrats d’utilisation qui sont indépendants de la plate-forme technique utilisée
par le fournisseur du service.
Enfin, l’extensibilité est rendue possible par le fait que de nouveaux services
peuvent être découverts et invoqués à l’exécution
5
Une application à base d’architecture orienté service SOA est un ensemble de

services indépendants les un des autre plus des orchestrations pour la réalisation
des processus métiers transversales plus des outils de gouvernance et de médiation.
1.4 Les objectifs de la SOA :
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:
•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.
2. Les composant et les principes du SOA
2.1 Les composants de la SOA :
Le paradigme "découvrir, interagir et exécuter" comme montré dans la figure

1.1, ce paradigme permet au consommateur du service (client) d’interroger un
annuaire pour le service qui répond à ses critères. Si l’annuaire possède un tel
service, alors il renvoie au client le contrat du service voulu ainsi que son adresse.
SOA consiste en quatre entités configurées ensemble pour supporter le paradigme
découvrir, interagir et exécuter.
Figure 1.1 Le
paradigme
"découvrir,
interagir et
exécuter"
6
Le consommateur de service Le consommateur de service est une

application qui requière un service. C’est l’entité qui initie la localisation du service
dans l’annuaire, interagit avec le service à travers un protocole et exécute la fonction
exposée par le service [02].
Le fournisseur de service Le fournisseur de service est une entité

adressable via un réseau, il accepte et exécute les requêtes venant d’un client Le
fournisseur de service publie le contrat de service dans l’annuaire pour qu’il puisse
être accédé par les clients
L’annuaire de service L’annuaire de service est un annuaire qui contient les

services disponibles. C’est une entité qui accepte et sauvegarde les contrats du
fournisseur de service et présente ces contrats aux éventuels clients
Le contrat de service Le contrat spécifie la manière dont le client de service

va interagir avec le fournisseur de service. Il spécifie le format de la requête et la
réponse du service
2.2 Les principes de la SOA :
L’architecture orientée service se base sur les principes suivants:
• Diviser pour régner : Substituer la découpe strictement applicative par une

structuration en composants plus réduits et potentiellement plus simples à faire
évoluer.
• Alignement métier : Construire et organiser le système à partir des réalités

métiers, qui doivent se retrouver dans ses constituants.
• Neutralité technologique : Assurer une indépendance totale entre les interfaces et

les implémentations. L’élément qui utilise un service ne doit pas être contraint ni par
la technologie d’implémentation, ni par sa localisation (potentiellement distribué).
• Mutualisation : Favoriser la réutilisation de services métiers par plusieurs lignes

métiers ou applications. Permettre la construction de services de haut niveau par
combinaison de services existants.
• Automatisation des processus métier : Isoler la logique des processus métiers

sur des composants dédiés qui prennent en charge les enchaînements de tâches et
les échanges de flux d’information.
• Echanges orientés Document : Les informations échangées par les services

possèdent une structure propre, guidée par les besoins métiers. On privilégie la
transmission de contenus complets et utilisables au profit d’accès direct aux
7
structures de type objet ou relationnel. La plupart des acteurs SOA préconisent une
mise en oeuvre progressive, excluant les opérations de type « big bang », avec une
cohabitation entre les constituants divers (legacy, anciennes applications, ERP etc…)
et les services SOA.
3. Mise en œuvre d’une SOA :
3.1 Méthodologie à suivre pour implémenter une SOA :
La mise en œuvre d’une architecture orientée services (SOA) est un bien vaste
chantier. Elle impacte toutes les composantes du SI (Système d’Information) et doit
impliquer tous les acteurs de la DSI et même au-delà. De plus, elle suppose une
profonde mutation des façons de penser et de concevoir le SI.
Autour de cette problématique titanesque, la question de la bonne approche pour la
mise en place d’une SOA a donné lieu à bien des écrits et des théories chacune
sous tendant des positions souvent trop dogmatiques.
Les différentes approches
En premier lieu, la polémique a rapidement enflé sur le thème « Top Down

contre Bottom Up ». Un débat bien trop manichéen dans lequel certains ont vu le
combat des puristes contre les pragmatiques, des générateurs de valeurs contre les
gestionnaires (« cost savers ») ou encore des évangélistes métiers contre les
architectes techniques. Cette opposition stérile tend à disparaitre mais elle a laissé
des traces et ressurgit encore régulièrement sous des formes diverses [1].
Une fois cette première « guerre de religion » apaisée, on a vu fleurir pléthore
d’approches hybrides proposant une troisième voix. Parmi ces approches, on
retiendra l’approche Middle Out et l’approche Outside In (Aussi appelé Meet In The
Middle) qui là encore ont chacune leurs partisans.
8
Top Down
Le point de départ de cette approche est le suivant : puisque

l’objectif de la mise en œuvre d’une SOA est d’aligner le SI sur le métier de
l’entreprise, c’est en toute logique qu’elle doit partir de la définition (ou de la
formalisation) des processus métiers pour descendre ensuite au travers
des différentes strates du SI afin de définir les services nécessaires à la
réalisation de ces processus (en commençant par la définition des services
de plus au niveau, c’est-à-dire offrant le plus de valeur ajoutée métier).
Cette approche représente la voie royale :
 Elle permet de piloter la SOA par les besoins métiers.
 Elle minimise la redondance de services.
Elle n’est cependant que rarement possible car :
 Elle signifie une refonte de tout ou partie du SI, jugée bien souvent trop
coûteuse et trop risquée.
 Elle rend difficile l’adhésion à la démarche des équipes MOE (Maîtrise
d’œuvre).
Bottom Up
A l’inverse, cette approche prône une phase de conception

ascendante. Une analyse de l’existant (cartographie applicative) permet
de déterminer les fonctions existantes du SI. Ainsi cartographiées, il est
possible d’identifier les fonctions du SI qui sont éligibles au rang de service.
Une fois ces fonctions mises en mode service, elles sont exploitables au
sein de services à forte valeur ajoutée et / ou de processus métiers.
Cette approche peut séduire par plusieurs aspects :
 Elle contraint à réaliser une cartographie du SI qui, si elle est
tenue à jour et publiée, facilitera la réutilisation de services.
 Le coup du ticket d’entrée peut paraître moins élevé que pour
une démarche Top Down.
Elle présente cependant des travers rédhibitoires :
 Elle bloque le pilotage de la SOA par les besoins métiers.
 Elle ne favorise pas la mise en place d’un effort transverse :
elle ne permet pas de sortir de la « culture projet ». En effet, les services
émergeants de cette approche restent très fortement couplés à leur
application d’origine.
 Elle rend très difficile la justification de l’investissement auprès
du métier, qui n’en verra les bénéfices qu’une fois les services auront été
rendus exploitables au sein de processus métiers.
Enfin, cette approche se limite à une mise en mode service de
fonctions existantes sur le SI. C’est présupposer que cet existant suffit à
réaliser le métier de l’entreprise. Quel est dans ce cas la pertinence de la
mise en place d’une SOA pour aligner le SI sur le métier ?
9
Outside In (Meet In The Middle)
Cette approche préconise de mener en parallèle :

 Un chantier Top Down pour définir les processus métiers et les
services de plus haut niveau nécessaires à leur réalisation.
 Un chantier Bottom Up afin de cartographier l’existant applicatif
dont dispose l’entreprise pour supporter les services métiers à forte valeur
ajoutée.
Une fois ces deux chantiers en phase finale, commence la délicate étape
de l’accostage. Son objectif est de « réconcilier » les résultats des deux
approches afin de déterminer comment seront réalisés les processus métiers. Il
faut, pour cela, croiser les besoins en services (exprimés par le chantier Top
Down) et le patrimoine applicatif (cartographié par le chantier Bottom Up).
De part sa nature, cette approche réunit les bénéfices des approches
Top Down et Bottom Up. Elle permet de piloter la SOA par les besoins métiers
tout en facilitant la réutilisation de services et la capitalisation sur l’existant.
Mais elle cumule également les travers des deux approches,
notamment en induisant un très fort risque d’effet tunnel.
En effet, le point critique de cette démarche est l’étape d’accostage. C’est d’elle
seule que dépend la réussite ou l’échec de la mise en œuvre d’une SOA. D’un
côté, elle doit intervenir (et aboutir) suffisamment tôt pour éviter un décalage
entre les résultats des chantiers préliminaires et la réalité opérationnelle
(Nouveaux besoins métier / Cartographie obsolète). D’un autre côté, elle ne doit
pas démarrer trop tôt afin de ne pas parasiter les chantiers Top Down et Bottom
Up et de se baser sur des résultats suffisamment étoffés.
Le bon déroulement de l’étape d’accostage passe donc par une
coordination étroite des chantiers Top Down et Bottom Up très en amont de sa
réalisation.
Middle Out
Cette approche peut être introduite par la phrase « BPM et SOA sont les deux
faces de la même pièce ». Assertion qui fait référence à un autre débat stérile
ayant fait couler beaucoup d’encre et qui rappelle qu’il est impossible de
dissocier la définition des processus métiers de l’établissement du
catalogue de services.
Par opposition à l’approche Outside In, cette méthode propose de
commencer « In the middle », c’est-à-dire là où le métier et les IT parlent le
même langage (ou en tout cas presque). Elle s’attaque donc d’emblée à ce
qui reste un des principaux freins à l’adoption des SOA au sein des DSI
françaises : La compréhension du métier de l’entreprise par les maîtrises
d’œuvre et inversement, la compréhension des contraintes IT par les
maîtrises d’ouvrage.
10
Une fois les différentes parties d’accord sur un premier socle de services
« métiers » nécessaires :
 La maîtrise d’ouvrage engage un chantier Middle Up pour spécifier les
processus métiers.
 La maîtrise d’œuvre engage un chantier Middle Down pour spécifier le
socle de services de plus bas niveau permettant la réalisation des services métiers.
Cette approche fait donc la part belle au dialogue entre métier et IT et pose la
compréhension mutuelle comme pré-requis à la mise en œuvre d’une SOA.
Elle limite par contre le pilotage de la SOA par les besoins métiers, puisque le point
de départ est l’identification des services métiers nécessaires et non la définition des
processus réalisant le métier de l’entreprise.
3.2 Clés de succès :
Il n’existe pas de recette miracle pour la mise en œuvre d’une architecture

orientée services (SOA). Il est illusoire de croire que l’application d’une des
approches présentées plus haut garantisse sa réussite. Comme souvent, la réponse
adéquate dépend, pour beaucoup, du contexte de l’entreprise : ses besoins, ses
moyens, ses ambitions, son existant (organisationnel et méthodologique), …
Même s’il ne sert à rien de réinventer la roue, il est donc primordial de savoir
décliner et adapter les différentes approches (ou combinaison d’approches)
possibles dans le contexte de mise œuvre.
Il est également important de garder à l’esprit que l’approche choisie doit

garantir la prise en compte du changement. En effet, la mise en œuvre d’une SOA
étant un chantier de longue haleine, il y a fort à parier que les besoins métiers
changeront en cours de route. C’est le premier pas vers l’agilité du SI et l’alignement
de l’IT sur le métier.
Toutefois, quelle que soit l’approche choisie (et déclinée), la mise en place
d’une architecture orientée services (SOA) ne peut pas aboutir si :
 Elle n’est pas traitée comme un projet transverse.
 Elle n’est pas pensée en termes métier.
 Elle ne s’accompagne pas d’un travail d’évangélisation visant
à changer les façons de penser et de concevoir le SI.
Un projet transverse :
La mise en place d’une SOA est un effort (une initiative) qui doit être mené de
façon transverse. Elle ne peut pas être traitée projet par projet. Elle passe par un
projet de gouvernance, mené par une équipe transverse. On ne parle pas ici d’un
projet de réalisation qui engendrera du logiciel, mais d’un projet de pilotage.
11
Pour réussir la mise en place d’une SOA, il faut étendre la « culture

projet » (pour autant que cette dernière ne soit pas complètement pervertie). En
effet, même si le projet reste le seul cadre performant pour la construction d’une
solution logicielle, il limite automatiquement, dès sa définition, le champ d’analyse. Il
est utopique de demander à un responsable de projet d’étendre ces analyses au-
delà du champ de son projet.
Cela ne veut pas dire qu’il faut abandonner le projet comme unité de
production de logiciel. Cela veut dire qu’on ne peut plus mener la construction du SI
par une simple juxtaposition de projets : Le SI doit devenir plus que la somme des
applications qui le composent.
Un des moyens de garantir la transversalité du chantier est de mettre sur pied
une équipe SOA dédiée en charge de le coordonner. Cette équipe doit regrouper des
représentants et experts de chaque population impliquée :
 Maîtrises d’ouvrage métier : Expert métier.
 Maîtrises d’ouvrage SI : Architecte fonctionnel.
 Maîtrises d’œuvres : Architecte technique / logiciel.
 Exploitation.
Penser métier : La mise en place d’une SOA doit être pensée en termes de
besoin métiers et pas en terme de besoins techniques : la construction d’une
architecture IT doit se baser sur la problématique métier qu’elle tend à résoudre (ou
sur le(s) service(s) métier(s) qu’elle essaie de rendre).
Evangéliser : La mise en place d’une SOA implique une mutation profonde

des façons de penser et de travailler. Comme pour l’agilité, il ne suffit pas
d’appliquer la culture SOA lors de la définition des architectures IT ou de la
réalisation d’une application, mais il faut savoir l’étendre à l’ensemble des
composantes d’une organisation.
Il faut commencer à sensibiliser les acteurs le plus tôt possible afin que cette
mutation aboutisse et se face en douceur. L’évangélisation est de la responsabilité
de l’équipe de coordination SOA.
Savoir itérer : Il est bénéfique d’aborder la mise en œuvre d’une SOA via une
approche par projets agiles. On remarque qu’en planifiant cette mise en œuvre
par itérations verticales (qui traversent toutes les couches du SI) sur des
périmètres fonctionnels restreints, en y intégrant progressivement les évolutions
des couches supportant les processus, chaque itération est pilotée par un besoin
métier et les mutations du SI sont introduites progressivement.
Simplicité du concept : le principe de base d'une architecture orientée

services est très simple à comprendre.
12
Potentiel réel de réutilisation : le fait de découper et d'implémenter un

système en services permet réellement de réutiliser des fonctionnalités de celui-ci à
partir d'autres systèmes et à l'intérieur même de celui-ci.
Intégration : bien que non essentiel en soit, les architectures orientées

services utilisent souvent les services Web comme technologie d'implémentation.
Cela facilite grandement l'intégration entre les systèmes basés sur des technologies
différentes à cause des propriétés universelles des services Web.
3.3 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.
Les principaux coûts recensés sont en termes
13
•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 tel que 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]
14
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
4. Avantages de l’architecture orientée service :
Au-delà d’une nouvelle technologie ou méthode, la SOA est une philosophie

de conception qui oriente la façon dont les ressources seront intégrées et les
services qui seront exposés à l’emploi, nécessitant une forte adhésion des directions
informatique et métier à un même objectif : une meilleure agilité des systèmes face
aux transformations nécessaires. De ce fait, opter pour une démarche orientée
service s’avère une décision stratégique agissant sur le plan organisationnel,
technique et financier.
4.1 Au niveau organisationnel : la flexibilité du système :
Dans l’optique d’une recherche permanente d’innovation dans l’entreprise, la

technologie peut constituer ou non un élément facilitateur, dans la mesure où elle
offre la flexibilité nécessaire pour se transformer et s’adapter au même rythme que
l’économie.
Des éléments tels que le découpage des applications en « services »

individuels, la standardisation des choix technologiques ou la virtualisation de
l’infrastructure constituent l’essence de l’architecture SOA (Service Oriented
Architecture), nouveau paradigme des systèmes d’information, dont le principal
avantage est précisément de permettre que l’informatique réponde aisément aux
nécessités de changement de l’entreprise et que celle-ci perçoive les technologies de
l’information comme un avantage compétitif sur lequel s’appuyer pour s’adapter au
marché.
En utilisant une analogie simple, SOA transforme les applications de

l’entreprise en pièces de Lego, capables de s’emboîter dans toutes sortes de
configurations et réutilisables pour différentes constructions. En outre, la valeur
ajoutée de la SOA pour l’entreprise est sa capacité à réduire sensiblement les coûts
de l’adaptation au changement.
15
Il existe actuellement un consensus sur la nécessité de synergie entre la

technologie et les affaires. SOA est la clé de cette dynamique qui fournit la flexibilité
et l’agilité nécessaires pour répondre aux besoins des affaires au moment où ils
apparaissent. La rapidité, la flexibilité et même, la prévision sont les avantages
concurrentiels qui conduisent une entreprise au succès.
Avec une architecture SOA, les entreprises peuvent compter sur ces attributs.
Pour ces nombreuses raisons, l’adoption de SOA doit être envisagée comme une
initiative stratégique, qui requiert le leadership direct du DSI et qui doit compter sur le
soutien explicite de l’équipe dirigeante de l’entreprise
SOA transforme les

applications de l’entreprise
en pièces de Lego,
capables de s’emboîter
dans toutes sortes de
configurations et
réutilisables pour
différentes constructions
Cependant pour parvenir à modeler un produit avec de petites pièces, il en

faudra bien davantage que pour le concevoir avec de grandes pièces. Le jeu
constitué de petites pièces est un jeu d’expert, qui requiert que le joueur y soit
préparé. Il aura probablement besoin d’un manuel d’instructions, devra faire preuve
d’une plus grande adresse, avoir des gestes plus précis, garantir une plus grande
capacité d’intégration, etc. Ainsi, changer de jeu, s’orienter vers les services,
permettra de gagner en flexibilité en disposant de pièces plus petites, mais exigera
une plus grande habileté pour combiner autant de pièces le plus rapidement possible
tout en restant fidèle au modèle.
4.2 Au niveau technique : la réutilisabilité des services :
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 afin de simplifier les processus et de 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
16
de nouveaux projets. 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. 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. 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
4.3 Au niveau financier : la baisse des coûts :
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.
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.
17
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 : les coûts des projets, les coûts de maintenance, les éventuels
changements futurs et le retour sur investissement.
Une autre source de dépenses de toute infrastructure informatique se résume

dans 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.
 La transformation de l’ensemble du réseau informatique de l’entreprise

en le dotant de cette architecture, offre de nombreux avantages à l’entreprise
tels que les marges de profits émanant de l’accroissement de productivité des
employés ( ces employés peuvent concentrer leurs énergies sur la création de
la valeur ajoutée et sur les processus de collaboration, les activités semi-
structurées, plutôt que d’avoir à se conformer aux limitations et restrictions des
sous-systèmes grâce à un accès simplifié à tous les systèmes d’information)
ou encore un gain de temps pour les décideurs qui obtiennent des
informations plus complètes et plus précises fournies par les différents
départements (financier ….).
5. Les limites de la SOA :
5.1 La sécurité (liée à l’implémentation) :
Lors de la mise en œuvre d’une SOA, il est souhaitable de repenser

l’architecture de sécurité (confidentialité, intégrité et disponibilité). En effet, les
approches traditionnelles tiennent pour acquise la non-réutilisation des services et en
tirent avantage. (Il est plus facile de sécuriser une application quand ces composants
ne sont utilisés que par un nombre restreint de consommateurs). Or, la mise en
œuvre d’une SOA pousse à la réutilisation de services.
C’est une des raisons pour lesquelles, dans certaines situations, l’aspect sécurité
rend la mise en œuvre d’une SOA très (trop) coûteuse (de par la difficulté
d’implémentation des aspects sécurité). Il y a donc souvent un compromis à trouver
entre la réutilisabilité et la sécurité.
18
L’émergence des architectures orientées service (SOA) a introduit les

problèmes de sécurité suivants :
 L’authentification des utilisateurs finaux des services est déléguée aux

applications consommatrices ou au tiers d’intermédiation. Les applications qui
fournissent des services peuvent aisément identifier les consommateurs
directs ou le tiers d’intermédiation, mais elles n’ont pas connaissance de
l’identité des utilisateurs finaux, de leurs droits, ni de leurs intentions.
 Les mesures de sécurité à appliquer dépendent de l’environnement dans
lequel une application est utilisée. Malheureusement, l’environnement d’un
service change avec chaque nouveau consommateur. De ce fait, la
sécurisation d’un service peut rapidement devenir très coûteuse.
 Concernant la disponibilité (qui fait partie de la sécurité), même en pratiquant
au mieux le couplage lâche, il existe un certain degré d’interdépendance entre
les services. Si un service critique tombe, alors tous ceux qui s’appuient
dessus seront également indisponibles.
5.2 Le manque de compétences (lié à l’architecture et au

design) :
Il n’existe pas de recette miracle pour la mise en œuvre d’une architecture

orientée services (SOA). Il existe de nombreuses façons de le faire. Comme souvent,
la réponse adéquate dépend, pour beaucoup, du contexte de l’entreprise : ses
besoins, ses moyens, ses ambitions, son existant (organisationnel et
méthodologique),
Mais quelque soit l’approche choisie, on constate un manque de connaisses et de

compétences dans plusieurs domaines :
 L’architecture métier
Le terme lui-même, bien qu’étant de plus en plus présent dans le monde SOA,
est tout à fait nouveau pour de nombreuses entreprises. La création d’une
architecture métier au sein d’une SOA signifie : dépasser les frontières des
départements, intégrer la modélisation des processus métiers, concevoir un modèle
de données canonique, définir les services métiers (avec le bon niveau de
granularité), arbitrer sur les niveaux de sécurité à mettre en œuvre, recueillir et
prendre en compte les exigences et préoccupations métiers des différentes parties et
enfin penser suivant les patterns SOA
 L’ingénierie des exigences logicielles
La boîte à outils du concepteur applicatif se limite souvent aux cas

d’utilisations. Or, cette méthodologie n’est pas très appropriée aux environnements
19
SOA car elle ne couvre qu’une zone très limitée. La définition des exigences qualités
devient en effet de plus en plus importante du fait que la complexité des architectures
SOA a un impact fort sur les performances, la disponibilité et la gestion des
applications
 La gestion de projet
Un chef / directeur de projet devrait viser deux objectifs : Délivrer dans les
temps et les budgets impartis les produits métier tout en garantissant que ces
produits sont « prêts pour la SOA ». Ces objectifs peuvent être en conflit et un chef /
directeur du projet devrait être en mesure de gérer ces conflits. Malheureusement,
dans la pratique les chefs /directeurs de projet ignorent tout simplement l’aspect SOA
quand les conflits se produisent.
 L’architecture et développement logiciel
Les architectes et développeurs logiciels ont besoins de connaissances dans

de nombreux domaines techniques : patterns d’intégration, patterns SOA, ESB,
BPM, stack WS-*, … Il est particulièrement difficile de trouver des spécialistes avec
une expérience solide sur ces sujets.
 La Direction Informatique
Dans les grandes entreprises, il existe plusieurs responsables informatiques

(un par département). La mise en place d’un middleware commun s’avère alors
presque impossible, de par les problèmes de partage des responsabilités et de la
propriété des composants. Dans ce cadre une solution est la création d’une cellule
transverse dédiée en charge des éléments communs à tous les départements et de
la coordination des efforts de ceux-ci.
Si une société manque de compétences (connaissances) ne serai-ce que

dans un de ces domaines, l’ensemble de la mise en œuvre d’une architecture
orientée service (SOA) est en danger.
Les symptômes sont de longues discussions (parfois pendant des années) dont les
seuls résultats sont des documents volumineux et / ou une infrastructure middleware
inutilisée. Ces discussions portant la plupart du temps, sur qui doit faire quoi et
comment les responsabilités sont partagées.
Le problème fondamental est que les personnes impliquées, bien qu’elles aient de
nombreuses années d’expérience, ne se rendent pas compte de leurs lacunes dans
certains domaines de compétences nécessaires pour la mise en œuvre de SOA.
Embaucher des consultants expérimentés sur ces domaines pour y pallier ne résout
le problème que si tout le monde participe activement au processus d’apprentissage
et que ces consultants ont un rôle de coaching.
20
5.3 Coût de la mise en place de la SOA :
La mise en place d’un SOA a un coût élevé à la fois financier et humain. Il faut
former une équipe d'experts en conceptions ainsi que plusieurs équipes pour
développer et administrer les différents services. Dans le cas idéal, l’activité de
l’entreprise doit être pensée autour des services. La conception du système
d’information est donc une étape initiale critique. Si le fonctionnement de l’entreprise
n’est pas organisé autour des services alors il est difficile d’utiliser un SOA et donc le
coût de fonctionnement sera élevé. En effet, les SOA ont un intérêt limité si
l’entreprise ne base pas ses processus sur l’exploitation des services, il faut donc
concevoir des Workflows adaptés. De plus, il est difficile de migrer d’une architecture
monolithique vers une architecture SOA sans étude préalable efficace.
5.4 La lenteur d’exécution :
Parmi les limites de la SOA, on peut citer la longue trajectoire de la mise en

orbite. En effet, S’il faut environ huit minutes pour mettre une fusée en orbite, la mise
en orbite de la fusée SOA, elle, peut malheureusement prendre des mois ou des
années. Tout simplement parce que votre programme SOA requiert une masse
critique de services pour que l’agilité de ses applications composites et processus
se manifeste, et qu’il faut aussi un certain temps à une structure informatique pour
qu’elle s’adapte aux nouveaux impératifs du cycle de vie SOA. Ces délais ne sont
pas exempts de risques :
✓ Usure SOA : La durée et la complexité d’élaboration d’une architecture SOA

risquent de créer une lassitude au sein de l’organisation. Pour l’atténuer, il convient
de veiller à ce que chaque projet continue d’offrir un retour sur investissement, en
plus de contribuer à la réussite SOA de l’entreprise.
✓ Changements au niveau de la direction : Au cours de cette longue

trajectoire de mise en orbite, des collaborateurs essentiels risquent d’être licenciés,
de trouver un meilleur poste ailleurs ou de prendre leur retraite. Tout peut arriver !
Ces départs peuvent se révéler extrêmement préjudiciables mais, avec une vision
commune et une équipe engagée, vous êtes en mesure de les surmonter.
✓ Opposition des éditeurs : Certains éditeurs de logiciels risquent de vous

présenter leur offre comme une solution SOA monofournisseur. Rien ne les empêche
d’instaurer un couplage fort ou de faire obstacle à l’interopérabilité par souci de
maximiser les recettes tirées de leurs services ou licences.
✓ Opposition des consultants : Les consultants entendent garder la main et
multiplier le nombre d’heures facturables. La SOA peut confirmer ou infirmer ces
perspectives lucratives. Sachez que les consultants feront tout pour défendre ou
accroître leurs revenus la plupart du temps.
21
✓ Opposition des personnes chargées de la mise en oeuvre : À moins que la

mise en oeuvre progressive des règles ne s’accompagne de mesures incitatives, les
développeurs et autres parties prenantes peuvent toujours opposer une résistance
active ou passive.
✓ Coupes dans les financements : Si les projets SOA cessent de produire des
résultats quantifiables par les dirigeants, des coupes claires risquent d’être
effectuées dans les fonds affectés à votre programme SOA. Ne perdez pas de vue
les indicateurs important le plus pour vos supérieurs hiérarchiques et veillez à mettre
en adéquation votre programme SOA et ces objectifs.
6. Etude de cas :
Cette partie a pour principal objectif de prendre conscience de l’utilité du

concept de la SOA, en réalité, sur la base de l’expérience des utilisateurs de cette
approche. Ce qui va nous permettre, éventuellement de comprendre les raisons
pour lesquelles cette approche est adoptée, et pourquoi elle n’est toutefois pas très
commune, surtout en Europe, et au Maroc bien évidemment.
Il est à noter que cette étude a été réalisé en deux parties, la première
consistait en un entretien à questions ouvertes, et la deuxième avait pour but de
comprendre les avantages procurés par l’adoption de l’architecture orientée service
au sein des systèmes informatiques, dans ce sens, les entreprises ont dû remplir une
grille d’évaluation. Sur la base de ces données recueillies, nous avions eu droit aux
informations, citées ci-dessous.
1-Présentation de l’entreprise :
Cette étude repose sur une entité autonome mais publique de l’état de
Fribourg, Suisse. Il s’agit de l’Office de Circulation et de Navigation de Fribourg OCN.
De ce fait, on aura une vue de prés sur l’expérience en termes d’Architecture
Orientée Services, dans le domaine de la sécurité routière.
1-1.1 Portrait de l’organisation :
L’OCN 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. Cet établissement, qui compte une centaine de
collaborateurs, supervise la gestion de plus 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
22
leur service ainsi que la qualité de leurs prestations sont souvent certifiés par des
accréditations.
1-1.2 Le système d’information de l’OCN :
À 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.
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’ l’Office Fédéral de l’Informatique et de la Télécommunication, é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
Cette application fonctionne de manière simplifiée selon la figure suivante :
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 ci-
dessus. 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.
23
Le paysage applicatif de l’entreprise se représente alors de la manière

suivante :
Comme le décrit cette figure, 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 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.
1-2La SOA au cœur de l’OCN :
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.
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
24
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.
2- L’utilité réelle de la 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
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
25
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é.
26
Conclusion
L’utilisation des SOA a donc pour but d’avoir une vision globale du système
d’information d’une entreprise. Il représente la capitalisation des ressources métier
d’une entreprise avec la réutilisation des services et le stockage des données sur
une base de données unique. L’utilisation d’une telle architecture facilite l’évolution
des applications mais demande beaucoup d’efforts au niveau conception. Certes il
est quasi impossible de donner une définition exacte de la SOA sur la base d’une
seule étude 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 ce cas, nous permet de dire
clairement que l’architecture orientée service tient sa place dans toute architecture
logicielle souhaitant agilité et flexibilité.
Des architectures types existent et se développent de plus en plus. Elles sont

également validées par des experts. Mais les entreprises possédant des applications
centralisées développées de manière monolithique n’ont pas de bénéfices à adopter
ce type d’architecture. En effet, l’application doit être pensée orientée services dès le
début, afin d’orienter les workflows vers cette notion de service. De plus l’architecture
SOA n'est pas en soi une technologie, mais un principe de conception, tandis que les
services Web en sont une implémentation technologique
Pour finir, cette architecture a connu un échec durant ces dernières années et
ceci ne devrait en rien tempérer l’adoption à venir des microservices architecture.
Elles sont plus rapides et plus faciles à mettre à jour. Lorsque les développeurs
changent une application monolithique traditionnelle, ils doivent effectuer un test
détaillé pour vérifier que le changement n'affecte pas d'autres fonctions ou
comportements. Avec les microservices, les développeurs peuvent mettre à jour des
composants de l'application sans que cela n'ait d'incidence sur d'autres parties ….
27
Bibliographie/ Webographie
 Les principes de la conception SOA pour les nuls. EDITION LIMITEE

IBM
 Livre Blanc BEA Méthodologie SOA en six domaines (Révéler les

avantages métiers d’une Architecture Orientée Services)
 http://blog.xebia.fr/2008/07/17/les-10-pieges-de-la-soa/
28

SI Architecture Orientee Services SOA en

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

SI Architecture Orientee Services SOA en

Transféré par

Droits d'auteur :

Formats disponibles

Université Hassan II Mohammedia - Casablanca

Ecole Nationale de Commerce et de Gestion

Architecture orientée services

Année universitaire : 2016/2017

Depuis quelques années, Les entreprises n’étaient guère équipées d'un

- combinaison de monolithique, client/serveur, et application multi-tiers,

Dans un système traditionnel, « legacy » est défini comme tout système

A titre d’exemple, l’ERP qui est un système d’information fonctionnel qui a

classique ;Complexité des bases de données ;Interfaçage avec les autres SI : le

D’où la nécessité de création de nouveaux systèmes qui doivent s’adapter

 Ils sont le résultat d'un énorme investissement ;

Dans ce projet, nous allons s’intéresser à l’analyse du système SOA afin de

 Le SOA répond réellement aux attentes des entreprises comme il est

Pour ce faire , nous avons élaboré un plan de recherche et d’interprétation

implémentation du système et comme troisième partie- indispensable dans chaque

1. QU’EST-CE QUE LE SOA ?

1.1 Définition du système d’information Agile :

Un système d’information agile est un système qui est capable de s’adapter

1.2 Définition du SOA :

SOA est un style architectural qui permet de construire des solutions

1.3 Architecture SOA clef de l’agilité :

Une application à base d’architecture orienté service SOA est un ensemble de

1.4 Les objectifs de la SOA :

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

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

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

2. Les composant et les principes du SOA

2.1 Les composants de la SOA :

Le paradigme "découvrir, interagir et exécuter" comme montré dans la figure

Le consommateur de service Le consommateur de service est une

Le fournisseur de service Le fournisseur de service est une entité

L’annuaire de service L’annuaire de service est un annuaire qui contient les

Le contrat de service Le contrat spécifie la manière dont le client de service

2.2 Les principes de la SOA :

L’architecture orientée service se base sur les principes suivants:

• Diviser pour régner : Substituer la découpe strictement applicative par une

• Alignement métier : Construire et organiser le système à partir des réalités

• Neutralité technologique : Assurer une indépendance totale entre les interfaces et

• Mutualisation : Favoriser la réutilisation de services métiers par plusieurs lignes

• Automatisation des processus métier : Isoler la logique des processus métiers

• Echanges orientés Document : Les informations échangées par les services

3. Mise en œuvre d’une SOA :

3.1 Méthodologie à suivre pour implémenter une SOA :

Les différentes approches

En premier lieu, la polémique a rapidement enflé sur le thème « Top Down

Le point de départ de cette approche est le suivant : puisque

A l’inverse, cette approche prône une phase de conception

Outside In (Meet In The Middle)

Cette approche préconise de mener en parallèle :

3.2 Clés de succès :

Il n’existe pas de recette miracle pour la mise en œuvre d’une architecture

Il est également important de garder à l’esprit que l’approche choisie doit

Pour réussir la mise en place d’une SOA, il faut étendre la « culture

Evangéliser : La mise en place d’une SOA implique une mutation profonde

Simplicité du concept : le principe de base d'une architecture orientée

Potentiel réel de réutilisation : le fait de découper et d'implémenter un

Intégration : bien que non essentiel en soit, les architectures orientées

3.3 Coûts de l’approche :

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

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

Les principaux coûts recensés sont en termes

•D’investissement dans les infrastructures hardwares et softwares comprenant

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