Conception, architecture et urbanisation

des systmes dinformation

S. Servigne
Matre de Confrences, LIRIS, INSA-Lyon, F-69621 Villeurbanne Cedex
e-mail: [email protected]

1. Introduction
Le Systme dInformation (SI) est aujourdhui un lment
central du fonctionnement dune organisation. Un Systme
dInformation peut tre dfini comme un ensemble de
ressources (personnel, logiciels, processus, donnes, matriels,
quipements

informatique

et

de

tlcommunication)

permettant la collecte, le stockage, la structuration, la

modlisation, la gestion, la manipulation, l'analyse, le
transport, lchange et la diffusion des informations (textes,
images, sons, vido) au sein dune organisation. Exemples
de ressources informatiques : fichiers de donnes, bases de
donnes et SGBD (Systme de Gestion de Bases de Donnes),
progiciels intgrs (ERP, ), outils de gestion : gestion
clients (CRM : Customer Relationship Management), gestion
de la chane logistique (SCM : Supply Chain Management),
gestion

des

employs

(ERM :

Employee

Relationship

Management), outils de travail collaboratif (GroupWare),

applications

mtier,

serveurs

dapplication,

serveur

de

prsentation (Web,), systme de Workflow, architecture

dintgration (EAI : Enterprise Architecture Integration, SOA :
architectures orientes services), infrastructure rseau,
La dfinition donne prcdemment laisse entrevoir la
complexit du SI dont les dclinaisons vont sexprimer laide

de diffrentes architectures. Il est alors primordial aujourdhui

de diffrencier systme dinformation (SI) et systme
informatique. Un SI peut tre considr comme une vue
automatisable des mtiers dune organisation et une vue
fonctionnelle

de

linformatique,

donc

indpendante

de

limplmentation technique (figure 1). Le SI est plus prenne

que larchitecture informatique. Les volutions applicatives et
techniques peuvent tre indpendantes du SI en raison de
lvolution des technologies, des configurations ou des besoins
utilisateurs.
SI

Mtier

Informatique

Figure 1. Dcouplage : Processus mtier / Systme

dinformation / Informatique (applications + architecture
technique)
La conception de SI dune entreprise require des mthodes
danalyse de lentreprise afin de modliser les informations et
les donnes, les flux dinformation changs ainsi que les
traitements appliquer sur ces donnes. Ces traitements sont
identifis grce lanalyse des processus mtier (Figure 2).
Institut
Martin

Editions
Trouvaille

Informatique

Commande
ouvrage

Transaction

Livraison
ouvrage

Chane de valeur

Figure 2. Exemple de diagramme de workflow dun processus

mtier gnral
Des modles ou langages de modlisation sont donc
ncessaires. La mthode Merise et plus rcemment UML sont
les plus utiliss notamment en France dans la conception de SI.

Dans beaucoup dorganisations, il ne sagit plus aujourdhui de

concevoir un systme dinformation mais de le faire voluer
au rythme des besoins tout en exploitant les avances
technologiques.
Force est de constater que la complexit des SI est
proportionnelle la complexit croissante des technologies et
des organisations elles-mmes. Le SI doit rpondre aux enjeux
stratgiques de lentreprise, au dveloppement du march,
supporter lvolution des mtiers et des fonctions au sein de
lorganisation, et galement supporter lvolution du primtre
de

lorganisation

(fusion,

intgration

de

diffrentes

entreprises). Le SI doit donc tre volutif, ractif, flexible,

ouvert et galement scuris. Cest lobjectif de la dmarche
durbanisation des systmes dinformation.
2. Conception
Plusieurs mthodes de conception de SI co-existent et sont
exploites diffremment selon les pays. Parmi celles-ci, on peut
citer Merise, UML, AXIAL, IDEF
2.1. Merise
La mthode Merise est ne la fin des annes 70 en France
avec pour objectif de dfinir une dmarche de conception de
SI.
Le principe de base de la mthode Merise repose sur la
sparation des donnes et des traitements. Lorganisation des
donnes semble plus prenne que la dfinition des traitements
qui volue en fonction de lvolution des mtiers, des fonctions
et des utilisateurs. La mthode Merise intgre trois dimensions
appele cycles : le cycle dabstraction, le cycle de vie et le
cycle de dcision. Le cycle de vie dcrit les phases du projet de

construction du SI du schma directeur la ralisation. La

dimension dcisionnelle dcrit des phases de validation du
projet de construction du SI en impliquant la majorit des
acteurs ou utilisateurs du SI afin de sassurer de leur adhsion
au futur SI au sein de lorganisation.
Le cycle dabstraction se dcompose en 3 couches (Cf.
Figure 3), chaque couche correspondant une modlisation
(Donnes et Traitement) du systme dinformation.

1
2
Monde rel

Modlisation conceptuelle

3
Modlisation logique
Modlisation physique

Figure 3. Cycle dabstraction de Merise

Le cycle dabstraction a pour objectif, partir de lexpression
des besoins, de rpondre au QQOQC savoir : Quoi, Qui, O,
Quand, Comment, concernant les donnes et les traitements.
Donnes

Traitements

Quoi

Quelles informations
utiles ? (MCD)

Pour faire quoi ?

(MCT)

Conceptuel

Qui, O,
Quand

Quelle structure de
donnes ? (MLD)

Qui fait quoi et o,

et quand ? (MOT)

Logique

Comment

Comment stocker les

donnes ? (MPD)

Comment fait-on ?
(MOpT)

Physique

Figure 4. Phases danalyse et de conception des donnes et

traitements de Merise
Les modles dcrivant les donnes sont (Figure 4) : le Modle
Conceptuel de Donnes (MCD), le Modle Logique de
Donnes (MLD) et en fin le Modle Physique de Donnes
(MPD). Concernant les traitements, le dcoupage est
symtrique avec le Modle Conceptuel de Traitement (MCT),

le modle Organisationnel de Traitement (MOT) et enfin le

modle Oprationnel de Traitement (MOpT). Le niveau
dabstraction dcroit au fil des modles cest--dire que le
modle conceptuel se veut tre proche de la reprsentation
relle (vue utilisateur) et le modle physique, proche de la
reprsentation informatise ou implmente.
Couche 1 : la Modlisation Conceptuelle des donnes
(MCD) a pour objectif de dcrire le monde rel sous la forme
dentits et de relations entre ces entits : modle entitassociation (Figure 5a). Ces entits sont appeles Classes dans
le langage orient objet UML (Figure 5b).

a)

Client
- n client
- nom client

1..n

Client

b)

titulaire

0-1

Compte
- n compte

1..* Compte

Figure 5. Modlisation conceptuelle de donnes

La modlisation conceptuelle des traitements (MCT) a pour
objectif de dcrire des processus mtier en interaction avec
lextrieur de type : un vnement dclenchant provoque une
transformation du systme d'information pour produire un
rsultat. Les flux dchange sont analyss (Figure 6).
Lenchainement des diffrentes oprations est ensuite dcrit
(Figure 7).

1- Demande douverture de compte

Client

Banque

2- Rponse de la banque
Figure 6 : Diagramme de flux pour la modlisation
conceptuelle de traitement

OPERATION

OPERATION

Figure 7 : Modle conceptuel de traitement

Couche 2 : la Modlisation Logique exprime un choix de
structuration pour les donnes et les traitements. Il sagira par
de dcrire les donnes dans la structure de donnes choisi :
tables de la base de donnes. Par exemple, lentit Client est
transforme en une table de base de donnes appele Client
dont les attributs sont dtaills avec dclaration des identifiants
uniques appels cls. Par exemple, (Figure 8) lidentifiant
unique dun client est son numro. A un numro de client ne
correspond quun seul client.
Table Client

Nclient

Nom client

Figure 8. Modle logique de donnes

Concernant les traitements, le modle organisationnel de
traitement prcise le MCT en dtaillant notamment les
oprations redcoupes en procdures fonctionnelles .
Couche 3 : la Modlisation Physique prsente le modle
dimplmentation savoir le choix de matriel informatique
(logiciel, outil, systme dexploitation, machine) pour le

systme dinformation en termes de support de donnes et de

traitements (produit de SGBD, par exemple Oracle, langage et
environnement de dveloppement). La description des
donnes est ralise dans le langage de dfinition de donnes
du produit logiciel choisi (ex : en SQL pour Oracle). Les types
ou formats de donnes sont dcrits ce niveau. Par exemple,
lentit Client correspondra une table de base de donne et le
numro de client, appel attribut de lentit client et not :
nclient (Figure 4a), pourra tre dclar comme une valeur
entire et le nom du client comme valeur chaine de caractres
cest--dire un mot. Au niveau traitement, les procdures voire
programmes sont dtaills.
2.2. UML : Unified Modeling Language, norme OMG
(Object Management Group)
UML que lon peut traduire en franais comme langage de
modlisation objet unifi est un langage de description orient
objet qui permet de modliser une application selon une vision
objet. Un objet est dcrit par les attributs qui le compose et les
traitements appels mthodes qui peuvent lui tre appliqus.
Par exemple, lobjet client possde un numro et un nom. Les
mthodes applicables lobjet client peuvent tre : consulter le
client, crer, modifier ou supprimer un objet client. UML se
compose dun ensemble de diagrammes (Figure 9) dont
certains ont leur quivalent en Merise (diagrammes :
dorganisation, dobjets, de classes, de composants, de
dploiement, dutilisation, de collaboration, de squences)
qui

peuvent

dinformation.

tre

exploits

pour

dcrire

un

systme

Diagrammes UML

d)

a)

e)

b)

f)

activit

c)

g)

Figure 9. Quelques Diagrammes UML exploitables pour la

conception de SI
a) Diagramme dorganisation, b) diagramme de cas
dutilisation (Use Case), c) diagramme dactivit, d)
diagramme dtat, e) diagramme de classes, f) diagramme de
squences, g) diagramme de collaboration.
3. Architectures
Si le concept darchitecture de SI nest pas rcent, il nen reste
pas moins compliqu. En effet, larchitecture dun SI a de
multiples reprsentations et il serait plus appropri de parler
darchitectures de SI au pluriel. Concernant les mthodes de
conception darchitecture de SI, aucune mthodologie na
russi simposer contrairement UML pour la conception
darchitectures logicielles. Toutefois, les diagrammes UML
peuvent tre exploits lors de la conception ou reconception de
systme dinformation do parfois la confusion possible entre
architecture SI et architecture logicielle. Le tableau ci-aprs

exprime

quelques

diffrences

entre

les

deux

types

darchitectures tant en termes de concepts que de composants.

Architecture de SI

Architecture logicielle

Blocs fonctionnels,

Module logiciel, composant,

rfrentiels de donnes,

classe

flux de donnes
Des applications

Une application

Processus mtier, activits

Spcifications fonctionnelles

Spcifications techniques de Spcification des classes

lensemble du SI (ensemble logicielles
des composants et modles de
donnes)
Figure 10. Architecture de SI vs Architecture logicielle
Dans le domaine des Systmes dInformation, de nombreux
types

darchitectures

existent.

Ces

architectures

sont

parfaitement identifies et sont issues du rsultat des

diffrentes phases de conception dun Systme dinformation.
Quelques exemples sont dtaills ci-aprs :

Architecture fonctionnelle : reprsentation des fonctions

issues de lanalyse des processus mtier. Exemple :
Gestion des Comptes.

Architecture applicative : reprsentation des applicatifs

(composants logiciels) et des flux changs et dfinition de
limplantation sur larchitecture technique

Modle/Architecture logique : reprsentation virtuelle

dune architecture, abordable aux interlocuteurs. On peut
aussi parfois parler darchitecture applicative logique.

Architecture technique : reprsentation des techniques et

standards de construction : Systmes dexploitation,
SGBD, serveurs, middleware, types de rseau

On distingue galement larchitecture dimplmentation,

dexcution, de dploiement, larchitecture physique
4. Urbanisation
Urbanisation rime avec simplification et intgration afin de
rpondre

aux

enjeux

stratgiques,

organisationnels,

et

technologiques de lentreprise. La dmarche durbanisation de

systme dinformation est ne dans les annes 80 au sein des
banques. En effet, partir des annes 60, les systmes
dinformation se sont construits au fil de leau par ajout
successifs dapplicatifs et de structures de donnes sans souci
de cohrence globale. Les propositions dvolution au sein de
larchitecture venaient souvent de la direction informatique
indpendamment de lvolution stratgique de lentreprise. Les
annes 80 ont donc vu natre les architectures complexes dites
spaghetti difficiles matriser et faire voluer (Figure 11).
Appli. 1

Appli. 2
Appli. 1

Appli. n

Appli. 5
Appli. 2

Appli. 3

Appli. 4

Annes 60-70

A partir des annes 1980

Figure 11. Cartographie darchitectures de systmes

dinformation
Il est alors utopique de vouloir tout reconstruire et comme dans
une ville, le systme dinformation doit tre en mesure de
supporter des volutions et rorganisations permanentes. Le
dfi de lurbanisation est de construire une architecture de SI
flexible. Lenjeu est alors le suivant : faire voluer le systme
voire refaire certains morceaux, sans dtruire lexistant, en

intgrant des composants diverses et en exploitant les avances

technologiques dans un souci de cohrence gnrale, de
ractivit et de flexibilit.

Ville urbanise :
La Plata en Argentine

Composant
1

Composant Composant
2
3

Rfrentiel

Composant Composant
4
5

Systme dinformation urbanis

Figure 12. Systmes urbaniss

4.1. Dmarche durbanisation
La dmarche durbanisation recentre le pilotage de lvolution
du systme dinformation sur la stratgie et les besoins des
mtiers de lentreprise ou organisation concerne. Elle est
base sur un modle en quatre couches successives : Mtier,
Fonctionnelle, Applicative et Technique. A partir dobjectifs
stratgiques clairement identifis, les processus mtier
mettre en oeuvre sont alors identifis. Puis les fonctions et
informations utilises par les processus sont alors dtailles et
enfin, les applications et larchitecture technique permettant
dimplmenter ces fonctions sont spcifies. On peut alors
parler dune dmarche top-down , savoir dmarche de
conception descendante. Lurbanisation consiste alors de
passer dun systme dinformation existant un SI cible par
des tapes successives de description ou construction
darchitectures (Figure 13).

Sratgie
mtier
Architecture
mtier
cible

Architecture
mtier
existante

Architecture
fonctionnelle
cible
Architecture
applicative
existante

Architecture
applicative
cible
Architecture
technique
existante

Architecture
technique
existante

Figure 13. Dmarche durbanisation top-down

Cette dmarche est galement exploite pour la conception
darchitecture dentreprise. Une dmarche bottom-up
(ascendante) peut galement tre ralise, pousse par les
avances technologiques et la volont de rorganisation
technologique

et

applicative,

paralllement

ou

indpendamment de la dmarche top-down .

4.2. Cartographies
La cartographie est un outil central de la dmarche
durbanisation.
durbanisation

Chaque
peut

tre

architecture
dcrite

par

de

la

une

dmarche
cartographie

reprsentant son POS : plan doccupation du sol (Figure 14).

Architecture

Cartographie

Architecture
mtier

Carto
Processus

Objectifs stratgiques
Processus / Tches

Architecture
fonctionnelle

Carto
Fonctionnelle

Systme dinformation
Domaines fonctionnels
Rfrentiels et flux

Architecture
applicative

Carto
Applicative

Architecture
technique

Carto
technique

Elments reprsents sur la cartographie

Systmes informatiques
Applicatifs/Progiciels
Composants, Objets Mtiers, flux
Matriels (serveurs, poste de travail)
Logiciels (Systme dexploitation, SGBD)
Architecture rseau

Figure 14. Cartographies

a)
Erreur !

PM

PM

PM

e)

PM

Cartographie mtier

b)

Bloc 1

f)
Zone

Cartographie fonctionnelle

c)

Bloc 2
Fonction 1
Fonction 2

Applicatif 1

g)
Cartographie applicative

d)
Cartographie technique

Figure 15. Cartographies dtailles des architectures SI

4.2.1 Cartographie de larchitecture Mtier (Figure 15 a)
La cartographie mtier reprsente une vue de larchitecture
mtier par une formalisation du mtier de lentreprise en
rpondant aux questions quoi, qui, o et pourquoi (cf. Mthode
Merise). Lobjectif est de dfinir les besoins du mtier vis--vis
du systme dinformation. La cartographie Mtier ou
cartographie processus dcrit les processus mtier (PM) de
lentreprise sous forme de diagrammes (Figure 15a et 16).
Chaque processus peut ensuite tre dtaill en prsentant
lenchainement des activits laide de diagrammes de
workflow ou en exploitant les diagrammes UML (Use Case et
diagramme dactivit Figure 15e). La description des activits
implique donc la spcification des OM : objets mtiers (quoi),
des entits organisationnelles (qui) et des processus qui
rpondent des objectifs (pourquoi). Enfin, la cartographie
Mtier de lexistant peut tre associe une cartographie

Mtier cible si des volutions mtier sont envisages en

rponse de nouveaux objectifs stratgiques.
Gestion
Commande

Edition
ouvrage

Impression

Livraison

Figure 16. Exemple de cartographie de processus mtier

4.2.2 Cartographie de larchitecture Fonctionnelle (Figure
15b)
La cartographie fonctionnelle dcrit les fonctions mises en
uvre pour raliser les activits (issues des processus cf.
Figure 15e et 15f) dcrites dans larchitecture mtier. Il sagit
de dcrire les fonctions valeur ajoute indpendamment de
limplmentation. Le but recherch est une organisation
logique des fonctions, fortement dcouple et sans redondance.
Larchitecture fonctionnelle est dcoupe en Zones, ellesmmes redcoupes en Quartier puis lots ou blocs fonctionnels
indpendants et autonomes (Figure 15f). Llot, qui contient les
fonctions est la plus petite entit du dcoupage. Prenons
lexemple dune zone fonctionnelle banque commerciale,
plusieurs quartier composent cette zone dont le quartier de
gestion lpargne et le quartier de gestion des crdits. Le
quartier de gestion de lpargne peut tre redcoup en
diffrents blocs selon les types de liquidit : comptes chques,
pargne logement (PEL, CEL), pargne liquide (CODEVI)...
Les donnes manipules par ces fonctions sont galement
dcrites. En effet, un bloc fonctionnel est seul propritaire des
donnes quil manipule, afin de faciliter une organisation
modulaire. Des rgles durbanisation ont t dfinies afin
daider au dcoupage de larchitecture fonctionnelle. Le
dcoupage consiste premirement sparer les zones de

rfrentiels

(donnes),

dchange

(communication

avec

lextrieur), de gestion interne (finance, RH, informatique),

de stratgie et rgles de dcision, et les zones oprationnelles
(mtier).
4.2.3. Cartographie de larchitecture applicative (Figure
15c)
Larchitecture applicative est une vue informatique et
dynamique du systme dinformation dcrit dans la couche
fonctionnelle. Lobjectif est la distribution et la rutilisation
des fonctions applicatives.
Larchitecture applicative est dcrite par la cartographie de
lensemble des blocs ou composants applicatifs (composants
logiciel, progiciels, ) et de leurs changes rpondant
lorganisation fonctionnelle spcifie prcdemment. Dans
labsolu, un bloc fonctionnel devrait correspondre un bloc
applicatif. Lexistant et son intgration ne permettent pas
toujours de respecter cette contrainte. Un progiciel intgr
correspondra un lot ou bloc applicatif (lment de
granularit la plus faible, non dcoupable Figure 15g).
Les structures de donnes sont galement dcrites au niveau de
larchitecture applicative. Les accs ces donnes ainsi que la
gestion de leur persistance (sauvegarde, scurit) sont
galement dcrite ce niveau. UML ou Merise offrent les
modles et diagrammes utiles la description de larchitecture
applicative.
4.2.4 Cartographie de larchitecture technique (Figure 15d)
Les infrastructures ncessaires au dploiement des composants
dfinis dans la couche applicative ainsi que la manire dont ils
communiquent, sont dcrites au niveau de larchitecture
technique. Le principal objectif lors de la conception de la

couche technique est la mutualisation des plateformes

techniques dans le but de raliser des conomies dchelle. La
modlisation de la couche technique est principalement
constitue par des diagrammes qui permettent de montrer la
connexion entre les serveurs.
4.3 Urbanisation et architectures dintgration
Les approches SOA et EAI sont des architectures dintgration
permettant de concrtiser la mise en uvre de SI urbaniss.
Elles peuvent tre complmentaires.
SOA : Services Oriented Architecture. La dmarche de
conception darchitectures orientes services rpond aux
besoins de lurbanisation du systme dinformation par
lapproche modulaire en couches quelle propose. Lapproche
SOA concerne larchitecture applicative. Les composants
applicatifs publient des services regroups dans un annuaire.
Lorchestration (lenchainement) de services permet de raliser
des fonctions requises pour la ralisation dactivits de
processus mtier. Une dcomposition des services en couches
de la couche mtier (service mtier : exemple consultation
des comptes-client ) jusqu la couche donnes (service de
base au niveau entit : exemple consultation table client )
est organise. Le dploiement des architectures SOA est
favoris par le dveloppement du web et des Web Services
(SOAP, WSDL, XML), des serveurs dapplication (J2EE,
.NET) et la ncessit croissante de systmes dinformation
ouverts et interoprables (communicants vers lextrieur,
collaboration inter-entreprises).
EAI : Entreprise Architecture Integration. Lobjectif dune
solution EAI est de raliser lintgration des applications sur
une architecture informatique commune afin de leur permettre
de raliser des changes (utile notamment dans le cadre de
fusion dentreprise). Exemple : permettre, une application, la

consultation des donnes dune autre application ou encore la

mise jour des donnes dune autre application.
Bibliographie
Y. CASEAU, Urbanisation et BPM, Dunod, Paris, 2005
J-P. GIRAUDIN & D. RIEU, Mthodes avances de
dveloppement des systmes dinformation, Revue des sciences
et technologies de linformation, Srie Ingnierie des systmes
dinformation, Volume 10, n10, Herms-Lavoisier, Paris,
2005
C. LONGEPE, Le projet durbanisation du SI, Dunod, Paris
2001
J-L. LUCAS, Une architecture internet pour le systme
dinformation de France Tlcom, Eyrolles, Paris, 2001
C. MORLEY, J. HUGUES, B. LEBLANC, O. HUGUES,
Processus mtiers et SI, Dunod, Paris, 2005
J. SASSOON, Urbanisation des systmes d'information,
Herms, Paris, 1998