Présentation de l'étude de cas

Introduction

Le sujet traite d'un tour-opérateur qui offre à sa

clientèle plusieurs types de voyages dans le monde
entier. L'étude porte sur la gestion de la société, en
particulier sur la réservation d'un ou plusieurs
voyages.

Le tour-opérateur
L'organisation actuelle du tour-opérateur est illustrée
par l'organigramme de la figure 4.1.

Fig. 4.1
L'organisation du tour-opérateur est articulée autour
des directions suivantes rattachées à la direction
générale dirigée par le PDG M. Gérard Bertrand :
Direction financière : M. Félix Louvet
Direction organisation : M. Roland Faure
Direction marketing : Mme Sylvie
Régnaud Direction commerciale : M.
François Robert Direction de
l'exploitation : M. Jean Ramon
Direction des ressources humaines : M. Henri Baron
Enfin, l'organisation inclut le service informatique,
rattaché à la direction financière et dont le chef de
service est M. Christophe Chevillard.
La direction commerciale s'organise autour d'un
réseau d'agences de voyages exclusives. Il existe
211 agences réparties dans le monde entier (une
vingtaine de pays). Elles ne proposent pas de
produits commercialisés par
d'autres tour-opérateurs. Il existe en moyenne une
dizaine d'agences par pays concerné, dont une
agence principale.
La direction organisation est chargée de concevoir et
d'organiser chaque voyage, et présente tous ces
voyages dans un catalogue.
Les voyages sont uniquement vendus aux clients par
le biais des agences faisant partie de la direction
commerciale.
La direction financière est responsable de toute la
comptabilité de la société, présente et gère les
paiements échelonnés dans le cas de clients ne
désirant pas payer immédiatement.
La direction marketing est responsable de la diffusion
de toutes les opérations promotionnelles auprès des
médias (presse, radio, etc.) et de la publication d'un
catalogue.
Afin de simplifier cette étude de cas, le volet gestion
des villages de vacances et/ou des hôtels (qui est de la
responsabilité de la direction de l'exploitation) sera
exclu du périmètre.

Présentation générale des voyages

Les voyages sont organisés dans le monde entier. Il y
a trois types de destination : la mer, la montagne et
les villes touristiques. Dans ce dernier cas, on
pense à de grandes villes ou à des villes bien
connues, situées près de la mer ou à la montagne. À
chaque endroit, trois types d'hébergement peuvent
être offerts : hôtel, bungalow ou résidence. Il est
évident que tous les modes d'hébergement ne sont
pas disponibles à chaque endroit (il est quelque peu
difficile de trouver des bungalows à New York !). Tous
les voyages proposent plusieurs activités. La liste
actuelle des activités disponibles à un endroit donné
est limitée à l'ensemble ou à une partie des activités
suivantes : natation, plongée, tennis, golf, voile, ski
nautique, escalade, parachutisme en
chute libre, ski et vélo tout terrain. La direction
organisation peut décider d'allonger cette liste.
La durée d'un voyage est fixée à une semaine –
toute la semaine au même endroit, dans le même
lieu d'hébergement. Un client qui désire rester plus
longtemps peut, bien sûr, réserver plusieurs
semaines, mais le prix ne sera pas dégressif pour
autant !
Le prix comprend le voyage d'un point de départ
donné (qui peut être un aéroport, une gare ferroviaire
ou une gare routière) jusqu'au lieu d'hébergement
(transport inclus), le prix de la location, les activités
libres prévues et, à la fin du voyage, le retour, du lieu
d'hébergement à la gare de départ.
Les prix, exprimés en euros, sont adaptés et fixés
pour quatre périodes (une par saison : hiver,
printemps, été, automne). Il existe un prix de
référence à partir duquel le prix réel de chaque
voyage est calculé (un voyage = une semaine, pour
une personne).
Un client peut demander à payer son voyage
immédiatement ou par versements échelonnés.

La direction organisation
La direction organisation a deux responsabilités :
gestion en temps réel des voyages :
hébergements disponibles, état actuel
des réservations, enregistrement des
demandes de réservation, etc. ; organisation
générale d'un voyage : création
d'un voyage, choix de l'hébergement,
organisation des activités, etc., et,
parallèlement, tous les points
de négociation tels que les prix à fixer
avec les compagnies aériennes, les hôtels, etc.
Chaque agence de voyages reçoit tous les jours de
la direction organisation un fax indiquant le nombre
de places
disponibles pour chaque voyage, ce qui permet aux
vendeurs de connaître les destinations encore libres
lorsqu'ils s'entretiennent avec un client.
Le service dispose d'un système informatique
central et d'un « standard téléphonique »
relativement important, composé de 80 personnes
(pour un coût annuel en ressources humaines de 5
M€). Ces personnes sont capables de répondre aux
demandes de toutes les agences, par exemple le
nombre de places disponibles en matière
d'hébergement pour un voyage proposé à une date
donnée, etc. Elles sont également responsables des
demandes de préréservations émanant des agences
de voyage (réservation temporaire : attribution
d'une référence de préréservation), ce qui implique
de mettre à jour l'état des réservations et la gestion
des places disponibles. Les renseignements
nécessaires à l'enregistrement d'une préréservation
sont les informations de base, à savoir
l'identification de l'agence faisant la demande,
l'identification des vacances et du lieu (référence de
l'hébergement). Tous les détails relatifs à la
réservation de voyages sont gérés par la direction
financière (identification du client, mode de
paiement, etc.). La direction organisation reçoit de la
direction financière la commande permettant de
procéder à une réservation définitive.
Toutes les vacances sont décrites dans un
catalogue édité par la direction marketing,
conformément aux informations transmises par la
direction organisation.
La direction organisation soumet à la direction
générale toute proposition visant à étoffer la structure
actuelle des vacances :
ajout de nouveaux pays au
catalogue ; nouveaux sites dans
les pays existants.
La direction organisation applique les décisions prises
par la direction générale.
 La direction marketing
Deux fois par an, la direction marketing édite un
catalogue présentant les voyages existants. Ce dernier
est adressé à chaque agence de voyages et aux
clients dont l'adresse est connue du siège du tour-
opérateur.
Le catalogue offre une description attractive et des
photographies de tous les voyages, présente les
destinations, l'hébergement et les activités
proposées. Un supplément indiquant les prix est
publié chaque trimestre. Le catalogue et le
supplément tarif peuvent être distribués aux clients
ou utilisés par les vendeurs à l'agence de voyages.
Selon les informations transmises par la direction
organisation, la direction marketing conserve ou non
le catalogue en l'état. Par exemple, il peut remanier la
description d'un voyage, remplacer une photographie
par une autre plus attrayante, ajouter des
chambres dans un lieu donné, y organiser de
nouvelles activités, etc.

La direction financière
À l'exception de la paye des employés, la direction
financière gère tous les flux financiers et en particulier
les paiements effectués par les clients.
Ce service dispose déjà d'un système informatique
pour traiter ses opérations, mais il n'est pas relié au
système de la direction organisation. La direction
financière possède également une liste noire des «
mauvais payeurs », en d'autres termes des clients qui
ont eu, à plusieurs reprises, des problèmes de
paiement ou qui n'ont pas soldé en totalité leurs
vacances précédentes.
Ce service est responsable de tous les aspects
financiers d'un voyage :
 acceptation de paiements différés et tous
paiements analogues ;
gestion du paiement immédiat.
Dans le cas d'une demande d'un paiement échelonné,
un dossier est transmis par l'agence de voyages,
fournissant toutes les informations requises :
identification du client, description des références de
pré-inscription, prix, etc. Ensuite, la direction
financière consulte la liste noire. Si le client remplit les
conditions, le paiement échelonné est accepté et les
informations sont envoyées à la direction organisation
afin de procéder à la réservation définitive des
vacances.
La direction financière dispose d'un délai maximal de
huit jours pour donner sa réponse, soit à l'agence
de voyages, soit au client directement, à savoir
accepter ou refuser sa demande. Un paiement
échelonné s'effectue sur six mois, quel que soit le
montant du voyage. Son montant représente le prix
réel des vacances, acompte déduit. La fin du voyage
correspond au début du remboursement.
Chaque paiement (immédiat ou échelonné) est
associé à une échéance. Dans le cas d'un paiement
immédiat, il existe deux dates clés :
acompte pour toute préréservation ;
solde d'une réservation définitive au plus tard huit
jours après versement de l'acompte.
Dans le cas d'un paiement échelonné, il existe
sept échéances :
la première lors de l'acompte versé ;
les six suivantes par versement mensuel, à
partir du mois suivant la fin des vacances.
Chaque échéance donne lieu à une facture adressée
au client. En matière d'acompte, la responsabilité en
incombe à l'agence de voyages (établissement
immédiat de la facture).
Dans ce cas, le formulaire de réservation sert
également de facture. Pour toutes les autres
échéances, la direction financière adresse directement
la facture au client.
Un acompte est encaissé par une agence de
voyages ; tout autre type de paiement est recouvré
par la direction financière (paiement adressé par le
client au siège social de la société, à la direction
financière). L'acompte correspond à au moins 10 %
du prix du voyage.
Si le client demande un paiement échelonné mais
ne remplit pas les conditions, sa demande est
rejetée et il n'a pas d'autre solution que de payer la
totalité du prix (liquidation). Dans le cas contraire,
l'acompte est remboursé au client, à l'exception des
frais de dossier (2 % du prix du voyage), et la
préréservation est annulée (envoi des informations
correspondantes à la direction organisation). La
même règle s'applique à un paiement immédiat : si
le client paie immédiatement (acompte) mais ne
règle pas le solde dans un délai de huit jours à
compter du versement de l'acompte, ce dernier est
remboursé au client, à l'exception des frais de
dossier (2 % du prix du voyage), et la
préréservation est annulée (envoi des informations
correspondantes à la direction organisation). La
direction financière est chargée de rembourser les
clients.

L'agence de voyages
Un vendeur aide un client à choisir son voyage, en
consultant le catalogue et en fonction de plusieurs
paramètres, à savoir le pays, la saison, le choix de la
destination, le type d'hébergement, le niveau de
confort, le nombre de personnes, le prix, etc.
Une fois que le client a choisi un voyage, il peut
demander un devis et/ou une préréservation
(réservation temporaire). Pour faire une
préréservation, le vendeur doit téléphoner à la
direction organisation pour avoir confirmation de la
disponibilité du voyage demandé, puis effectuer la
préréservation. Cette dernière est enregistrée dès
paiement de l'acompte par le client. La réservation
devient définitive lorsque le client liquide la totalité
due.
Le client peut demander de payer ses vacances
immédiatement ou par versements échelonnés. Dans
le premier cas, il verse d'abord un acompte (au
moins égal à 10 % du prix total) et paie le solde dans
un délai de huit jours, sous peine d'annulation de la
réservation. La réservation définitive est effectuée
seulement après paiement du montant total.
Si un client choisit de demander un paiement
échelonné, le vendeur doit ouvrir le dossier
correspondant et lui demander certaines
informations (adresse, profession, copie des derniers
bulletins de salaire, etc.). Après paiement de
l'acompte par le client, le vendeur envoie le dossier
(par la Poste) à la direction financière. Cette dernière
retourne immédiatement sa réponse à l'agence de
voyages et au client, à savoir un dossier accepté ou
refusé.
Dans tous les cas, le client verse directement
l'acompte à l'agence de voyages, mais doit envoyer
(lui-même) le solde ou tout autre paiement à la
direction financière située au siège social de la
société. Il est possible de verser un acompte en
utilisant tous les moyens de paiement, à savoir
paiement en liquide, par chèque ou par carte de
crédit. Mais tous les autres paiements sont toujours
effectués par chèque. Un acompte est toujours
perçu par l'agence, tous les autres paiements sont
toujours perçus par la direction financière. Un
formulaire de réservation est donné au client lors du
paiement de l'acompte et sert également de facture.
Les 211 agences réparties dans les 22 pays
concernés se répartissent en 22 agences
principales (une par pays) et
189 petites agences. Ces agences principales sont
dotées de compétences informatiques, ce qui n'est
le cas des petites agences.
Le directeur de l'agence principale de chaque pays
effectue des études statistiques sur les ventes dans
son pays qu'il transmet régulièrement à la direction
financière centrale, par exemple une fois par semaine.
Les horaires d'ouverture des agences sont 9
h/12 h- 14 h/19 h avec une pointe d'activité entre
18 et 19 heures de 20 % par rapport aux autres
heures de la journée. Le temps consacré par le
vendeur à chaque client varie de vingt minutes à
une demi-heure. En moyenne, 42 demandes client
sont traitées par jour en agence principale.

Les résultats financiers

En France, le tour-opérateur est l'un des principaux
acteurs dans son secteur d'activité. Numéro un il y a
deux ans, il se trouve maintenant à la deuxième place
et continue à perdre des parts de marché.
Les résultats financiers sont résumés dans le tableau
4.1.

Tab. 4.1

2000 2001 2002 2003 2004 2005

Chiffre d'affaires (M€) 18 21 259 29 30 305

3 3 7 0
Nombre de 39 46 565 64 65 660
réservations 0 8 3 0
(en milliers)
Bénéfice avant 36 43 51, 60 60 59
impôts (M€) 5

Le président-directeur général, M. Gérard Bertrand, a

été interrogé sur sa vision des principaux problèmes
relatifs au système actuel de réservation. Il nous livre
sa réflexion en la matière :
« À l'heure actuelle, lorsqu'un client entre dans l'une
de nos agences, il fait une réservation dans 68 %
des cas. Ce taux
de transformation des contacts en réservation est
trop faible, en particulier par rapport à la concurrence.
Environ 8 % des demandes de réservation que nous
recevons ne peuvent pas être satisfaites parce que
nous n'avons plus de place pour le voyage
demandé. Il serait possible de diminuer ce taux si
nous connaissions en temps réel les voyages non
réservés, car dans ce cas, nous serions à même
d'orienter le choix du client vers un voyage
disponible. L'impact de la diminution de ce taux
aurait des effets significatifs car nous savons que,
lorsqu'une première demande ne peut être satisfaite,
il existe une probabilité de 20 % pour que les clients
quittent l'agence sans faire d'autre demande.
Dans l'agence, le vendeur est submergé par les tâches
administratives (envoi et réception de fax et de
lettres), ce qui crée des files d'attente dans
l'ensemble de nos bureaux de vente. Cette attente
provoque la perte de plusieurs ventes parce que
certains clients n'aiment pas du tout attendre.
Un vendeur doit appeler le standard de notre direction
organisation afin de s'informer de la disponibilité des
voyages au catalogue et de procéder à la
réservation. Ce qui signifie que les agences sont
tributaires des heures et jours d'ouverture du standard
central. Une plus grande souplesse est nécessaire,
permettant aux agences de choisir leurs heures et
jours d'ouverture selon la culture et les nécessités
locales.
Certains coûts sont probablement trop élevés, tels
ceux des télécommunications.
Il serait possible d'améliorer notre image en
proposant, comme certains de nos concurrents, un
accès Internet pour notre catalogue.
Nous devons également, tout en préservant notre
réseau d'agences exclusives qui est et restera
probablement encore longtemps notre canal de
distribution de base, nous
ouvrir à de nouveaux canaux de distribution et faire
vendre nos produits par des tiers.
Nous devons aussi améliorer notre rentabilité en
vendant dans nos agences des produits de tiers
complémentaires.
Enfin, nous pourrions améliorer notre cash flow si nous
accélérions la facturation. »

La construction de la solution
méthodologique

1. Les étapes de la démarche et le choix du

cycle de vie
Les étapes de la démarche
La démarche retenue dans le cas du tour-opérateur
est illustrée figure 4.2. Toutes les phases proposées
dans la démarche standard figurent dans le plan de
travail, à l'exception de la phase de mise à jour de la
stratégie puisque celle-ci est à réitérer de manière
régulière, mais seulement en phase de mise en œuvre
du plan d'urbanisme. Dans le cas de notre tour-
opérateur, il s'agit de mener l'étude permettant de
définir en moins de vingt semaines la cible et la
trajectoire de convergence associée, il n'y a donc pas
lieu de prévoir de mise à jour de la stratégie en cours
d'étude.
Enfin, même si cela n'apparaît pas sur le schéma
précédent qui se limite aux phases, les procédures
opérationnelles et le savoir-faire et les compétences
actuelles et cibles de la direction des systèmes
d'information ont été exclus du périmètre de l'étude
car faisant l'objet d'un projet spécifique se déroulant
en parallèle.
On peut noter un certain parallélisme, et en particulier :
l'analyse de l'existant commence avant la fin de
la revue des axes stratégiques ;
la définition de la stratégie commence en parallèle
avec l'analyse de l'existant car dans le cas qui
nous préoccupe, l'approche consiste à concevoir,
au moins dans un premier temps, une cible
idéale. Il vaut donc
 mieux ne pas attendre la fin de l'analyse de
l'existant de manière à ne pas brider la réflexion
;
le plan de convergence peut commencer en
parallèle avec la dernière itération sur la cible.

Choix du cycle de vie adapté

Le cycle de vie est globalement séquentiel (même si
beaucoup de parallélismes ont été introduits dans
la planification), à l'exception de la phase de définition
de la stratégie qui est menée de manière itérative.
Cette option permet rapidement de :
développer une première vision de la cible et de la
confronter à la critique ;
familiariser l'ensemble des intervenants à une
démarche méthodologique et parfois un mode de
pensée jusque-là inconnus.

2. Les livrables
Le choix majeur en termes de livrable est le choix des
cartographies existantes et cibles à réaliser dans le
cadre de l'étude. La figure 4.3 illustre les choix opérés
dans notre étude de cas.
 Fig. 4.3

En fait, seules les cartographies techniques

(existante et cible) ont été écartées du plan de
travail de l'étude, car il existe une cartographie
technique actuelle fiable, et les études
d'infrastructures technologiques cibles étaient déjà
lancées. Le projet viendra donc apporter ses
conclusions à ces études qui en ont de toute façon
besoin pour être menées à leur terme.
Finalement, compte tenu des objectifs du projet
d'urbanisation du tour-opérateur, le choix de livrables
à inclure dans le plan de travail a été fait et est
présenté dans le tableau suivant dans lequel les
livrables retenus sont en caractères gras. Ceux qui
sont à la fois en gras et en italiques figurent dans le
plan de travail de l'étude, mais aucun exemple n'est
fourni dans ce livre (c'est par exemple le cas du plan
d'assurance qualité – PAQ).

Tab. 4.2
PHASE/ActivitéProduits finis

PAQ
PLANIFICATION Note de lancement
DE L'ÉTUDE Procédures
Outils opérationnels
 Modèle des objectifs stratégiques
métier Note sur les axes
stratégiques métier Diagramme
REVUE DES AXES
d'entreprise cible
STRATÉGIQUES
Modèle des objectifs stratégiques du
SI Note sur les objectifs stratégiques
du SI
Matrice de traçabilité objectifs
Compréhension métier/objectifs SI Diagramme d'entreprise
de la stratégie cible
métier de
l'entreprise Modèle des objectifs stratégiques
métier Note sur les besoins
Définition de la d'évolution métier Diagramme
vision cible d'entreprise cible
Modèle des objectifs stratégiques du
SI Note sur les objectifs stratégiques
du SI
Matrice de traçabilité objectifs métier/objectifs SI

ANALYSE DE Cartographie métier de l'existant

L'EXISTANT Cartographie applicative de
l'existant Cartographie technique de
l'existant
Procédures opérationnelles actuelles de la
DSI Recensement des compétences et du
savoir-faire actuels de la DSI
Bilan de l'existant
Note sur les opportunités technologiques
Cartographies Grands axes de la stratégie SI
de l'existant Règles d'urbanisme

Cartographie métier de l'existant

Cartographie applicative de
l'existant Cartographie technique de
l'existant
Procédures opérationnelles actuelles de la
DSI Inventaire des compétences et savoir-
faire actuels de la DSI

Bilan de l'existant Bilan de l'existant

Étude des de la stratégie

opportunités
technologiques

Orientation
et
déclinaison
Note sur les ands axes de la stratégie SI
opportunités Règles d'urbanismes
technologiques

G
r Tab. 4.2 (suite)
PHASE/ActivitéProduits finis

Cartographie métier cible

Cartographie fonctionnelle cible
Cartographie applicative cible
Cartographie technique cible
DÉFINITION Procédures opérationnelles cibles de la DSI
DE LA STRATÉGIE Inventaire des compétences et savoir-faire
cibles de la DSI
Ébauche de plan de convergence
Tableau comparatif des scénarios d'urbanisation
Note de choix d'un scénario d'urbanisation

Cartographie métier cible

Cartographie fonctionnelle cible
Plan d'occupation Cartographie applicative cible
des sols Cartographie technique cible
Ébauche de plan de convergence
Tableau comparatif des scénarios d'urbanisation

Prévision Rapport d'évaluation des performances

des
performanc
es Procédures opérationnelles cibles de la DSI
Inventaire des compétences et savoir-faire
cibles de la DSI
Organisation
Tableau comparatif des scénarios
Note de choix d'un scénario d'urbanisation
cible Évaluation
des scénarios et Planning de l'opération d'urbanisation
choix Note d'organisation du pôle urbanisme
Définition des tableaux de bord
Procédure de production des tableaux de bord
Procédure de mise à jour du référentiel du SI
PLAN DE
CONVERGENCE Planning de l'opération d'urbanisation

Note d'organisation du pôle urbanisme

Finalisation du
Définition des tableaux de bord
plan de
Procédure de production des tableaux de bord
convergence
Procédure de mise à jour du référentiel du SI

Définition et mise Dossier de synthèse de la stratégie SI

en place
de la stratégie de
suivi

PUBLICATION
DE LA STRATÉGIE
 Les acteurs et les instances du projet
Les acteurs
Pour ce projet, les principaux acteurs
sont : le directeur de l'étude ;
le chef de projet de l'étude ;
l'équipe d'étude comprenant urbanistes et
experts métier ;
les équipes étude et développement : il s'agit
des équipes en charge des études et des
développements du système d'information. Ces
équipes apportent leur connaissance de
l'existant et leur vision du plan d'action pour
converger vers la cible. Elles sont également très
utiles dans le test de la cible ;
le responsable qualité ;
le sponsor de l'étude : responsable du comité de
direction en charge de favoriser l'avancée de
l'étude d'urbanisation. Dans le cas du tour-
opérateur, il s'agit de
M. Roland Faure, directeur
commercial ; les utilisateurs ;
la direction des systèmes d'information ;
toutes les directions métier (financière,
organisation, marketing, commerciale, de
l'exploitation et des ressources humaines).

Les instances
Les instances comprennent des instances dont la
durée de vie est limitée à la durée de l'étude alors
que d'autres ont une pérennité sans fin.
Les instances pérennes
Le comité de direction de l'entreprise : il
agit comme instance suprême pour orienter les
travaux relatifs aux développements et aux
évolutions du tour-
 opérateur. Il est composé du Directeur général et
de ses sept directeurs.
Le comité de direction du SI : il agit comme
instance suprême pour orienter les travaux
relatifs aux développements et aux évolutions
du système d'information. Il se réunit aux étapes
clés de l'étude, puis une fréquence trimestrielle
est généralement appropriée. C'est ce comité
qui approuve les orientations générales à
caractère technique, fonctionnel et financier
(schéma directeur – plan informatique), répartit
le budget par domaine de gestion, assure la
promotion et coordonne au plus haut niveau les
options retenues dans l'entreprise. Il décide des
mises à jour du plan d'urbanisme et du plan de
convergence. Le comité de direction du SI est
composé du directeur général ou de l'un de ses
représentants, du directeur du système
d'information et des directeurs métier ou de
leurs représentants.
Les instances non pérennes (dont la durée de vie est celle du
projet)
Le comité de pilotage de l'étude : ses
responsabilités sont les suivantes :
faire valider par la direction générale puis
diffuser une note de lancement ;
fournir toutes les orientations nécessaires à
l'équipe d'étude pour mener à bien sa mission
dans le respect du calendrier prévu ;
résoudre le cas échéant les difficultés liées à la
disponibilité de ressources ;
assurer les arbitrages de haut
niveau ; valider les livrables.
Le comité est présidé par le sponsor de l'étude.
Est prévu au planning de l'étude un comité de
pilotage correspondant à chaque phase clé de
l'étude :
 revue des axes stratégiques ;
analyse de l'existant et itération 1 de la
définition de la stratégie ;
définition de la stratégie itération 2 ;
plan de convergence et itération 3 de la
définition de la stratégie.
La fin de l'étude est validée par le comité de
pilotage et entérinée par le comité de direction
du système d'information.
Le comité de suivi opérationnel : ses
responsabilités sont les suivantes :
faire un point sur les difficultés rencontrées ;
gérer le plan d'actions nécessaires à la
résolution de ces difficultés ;
déterminer les solutions adéquates et
éventuellement alerter le comité de pilotage s'il
le juge nécessaire ;
préparer les comités de pilotage.
Ce comité se réunit fréquemment (en général de
manière hebdomadaire) mais a une durée
volontairement limitée (typiquement une heure
maximum). Il définit les actions à mettre en œuvre
pour faire face aux difficultés rencontrées et suit
leur avancement mais ne traite pas des problèmes
sur le fond. Il est composé du directeur de l'étude,
du chef de projet de l'étude, des personnes clés
de l'équipe d'étude, du responsable étude et
développement et du responsable qualité de
l'étude. D'autres personnes peuvent se joindre au
comité, mais de manière ponctuelle, en fonction
des circonstances.
Le pôle urbanisme
Une nouvelle structure, le pôle urbanisme, devra voir
le jour à la fin de l'étude et jouera un rôle
considérable pour la mise en œuvre du plan
d'urbanisme.
Le pôle urbanisme maintient le SI dans la trajectoire
établie, et ses responsabilités sont les suivantes :
instruction des demandes de permis de construire ;
contrôle de conformité des systèmes livrés par
rapport aux permis de construire ;
maintenance du référentiel du système
d'information ; production de documents de
cadrage ;
conseil après des maîtres d'œuvre et des
maîtres d'ouvrage ;
mises à jour des règles d'urbanisme.
Urbanisme et stratégie

Ce chapitre décrit le « comment faire » pour la phase de revue des axes

stratégiques de la démarche méthodologique d'urbanisation d'un système
d'information.

La captation de la stratégie
Il s'agit de placer le projet d'urbanisation du système d'information dans le
cadre général de la stratégie de l'entreprise ou de l'organisme de manière
à définir une cible pour le système d'information qui soit en phase avec les
processus métier, eux- mêmes en phase avec la stratégie de l'entreprise.
Le recueil et la compréhension de la stratégie sont donc indispensables en
amont de toute démarche d'urbanisation de système d'information.
Une entreprise ou un organisme peuvent être regardés selon une approche top
down
comme indiqué sur la figure 5.1.

Fig. 5.1

L'entreprise ou l'organisme sont alors visualisés selon cinq points de

vue complémentaires :
la mission, qui est en fait la raison d'être de l'entreprise ou de l'organisme ;
la vision, constituée par l'ensemble des objectifs de haut niveau de
l'entreprise ou de l'organisme ;
la stratégie, qui est le moyen de réaliser la vision et qui s'exprime par un
ensemble d'objectifs et de sous-objectifs stratégiques ;
le système d'information, qui comprend :
les processus métier qui supportent les objectifs
stratégiques, le système informatique qui implémente
les processus métier.
L'urbanisation et, partant de là, la démarche pratique proposée n'incluent
pas une méthode pour déterminer la mission, la vision et la stratégie
d'entreprise. Celles-ci sont supposées définies et sont exploitées telles
quelles.
La stratégie est modélisée par une hiérarchie d'objectifs qui sont
décomposés en sous-objectifs. La décomposition des objectifs en sous-
objectifs s'arrête lorsque tous
les objectifs peuvent être atteints par au moins un processus.
Les projets d'urbanisation de systèmes d'information ont leurs origines
dans des décisions d'ordre stratégique pour l'entreprise ou l'organisme.
L'activité de compréhension de la stratégie de l'entreprise est destinée à
définir un cadre de référence commun aux dirigeants de l'entreprise, aux
responsables informatiques et à l'équipe chargée de l'étude d'urbanisation
sur la stratégie générale de l'entreprise ou de l'organisme.
Il s'agit de mettre en évidence les choix stratégiques les plus structurants
pour le système d'information.
Cette activité permet de comprendre et de valider les différentes
orientations stratégiques du système d'information en prenant en compte :
le point de vue de la direction
informatique ; le point de vue des
directions ;
le point de vue des utilisateurs.
À partir de ce cadre commun, l'équipe chargée de l'urbanisation pourra
clairement définir les limites de l'intervention d'urbanisation. Une fois les
limites du champ de l'étude définies et partagées par tous les acteurs,
l'équipe chargée de l'urbanisation établira, dans les grandes lignes les
premières conclusions qu'elle peut tirer de la stratégie de l'entreprise ou de
l'organisme en termes d'aménagement du système d'information.
Plus précisément, les objectifs de la captation de la stratégie sont les suivants :
recueillir et comprendre la politique et la stratégie générale de l'entreprise ou
de l'organisme ;
fournir à l'équipe d'étude une compréhension en profondeur des choix
et orientations de l'entreprise ;
amener la direction à formaliser et/ou préciser des choix implicites ;
sensibiliser les responsables informatiques aux enjeux stratégiques
de l'entreprise ;
évaluer leurs conséquences à court, moyen et long terme au
niveau de son système d'information et de son système informatique ;
expliciter la vision à court, moyen et long terme du développement
des systèmes d'informations ;
s'informer sur les dysfonctionnements majeurs de la situation actuelle.
Durant cette phase de la démarche, la direction et les responsables
informatiques doivent expliciter par le biais d'entretiens, de réunions
ou de documents déjà disponibles les grands axes dans lesquels s'inscrit
l'étude.
La stratégie de l'entreprise ou de l'organisme peut avoir des conséquences
à court terme, à moyen terme ou à long terme sur le système d'information
et le système informatique. Il est alors souhaitable de conserver la
distinction entre chaque groupe d'impacts. Cette classification sera utilisée
lors de la hiérarchisation des rénovations et de l'ordonnancement de la
mise en œuvre de l'urbanisation.
Dans cette phase, on mettra aussi en évidence les besoins d'évolution
indépendants de la stratégie mais provenant de contraintes extérieures,
comme par exemple des changements dans les réglementations du métier
étudié (nouvel assujettissement à la TVA, suppression du bonus/malus pour
les assurances automobiles…).
La direction doit être impliquée dans la démarche. Au minimum, elle
approuvera formellement les documents produits.
 La modélisation de la stratégie
Le diagramme des objectifs est basé sur le diagramme d'Ishikawa. Ce
dernier sert à présenter les causes et leurs effets. Le premier élément est
une flèche centrale correspondant à l'effet majeur recherché, tandis que les
causes engendrant cet effet sont représentées sous forme de flèches
dirigées vers l'axe central (flèche signalant l'effet majeur). La flèche
indiquant la cause est à son tour considérée comme un effet à obtenir, et
les causes induisant cet effet sont représentées par des flèches dirigées
vers cette flèche de cause/effet, etc.
Nous utilisons ici le diagramme d'Ishikawa pour modéliser la stratégie de
l'entreprise, exprimée sous forme d'objectifs principaux et de sous-objectifs.

1. Présentation
Dans cette activité, les actions suivantes sont à mener :
analyse des documents disponibles présentant la stratégie de
l'entreprise ; préparation d'un guide d'entretien ;
conduite des entretiens. Les entretiens sont menés auprès :
des directions (vision stratégique),
des responsables des structures informatiques (moyens,
coûts…), des responsables utilisateurs (vision en matière de
service rendu…) ;
analyse des entretiens ;
consolidation des
résultats ;
première classification et hiérarchisation des besoins.
Le document de synthèse élaboré à l'issue de cette tâche devra comporter
des éléments de réponse aux sujets suivants :
quelles sont les évolutions métier envisagées ?
quelles sont les évolutions en termes de services informatiques
(développement d'applications spécifiques, support aux
utilisateurs…) ?
quels sont les objectifs de qualité (délais de livraison d'un logiciel, zéro
défaut…) ?
quels sont les axes d'évolution envisagés pour l'infrastructure
technique (nouvelles méthodes et outils de développement, nouvelle
architecture technique…) ?
Si la profession supportée par le système d'information comporte des
contraintes
« de place » (réglementations liées au métier), il faudra mener une enquête
auprès des organismes fédérateurs et identifier les évolutions prévues pour
les prochaines années. Ces évolutions, parfois majeures, peuvent
occasionner de fortes modifications de structure dans le système
d'information.
Il faudra aussi s'informer sur toutes les contraintes extérieures non liées
directement à la stratégie mais devant être prises en compte.
Les besoins d'évolution seront classés par ordre de priorité. En
particulier, les besoins d'évolution en termes de performance sur les
événements de gestion clés sont mis en évidence. Si possible, on donne
une estimation macroscopique de la charge de travail induite. Si des
contraintes d'enchaînement sont identifiées, il faut les consigner.
2. Le modèle des objectifs
Un modèle des objectifs est utilisé au début d'un projet de reconfiguration
des processus. Il a pour objet de modéliser la stratégie de l'entreprise ou
de l'organisme, qui sont supposés constituer un élément d'entrée pour la
méthodologie.
La description des objectifs est le complément naturel du diagramme des
objectifs. Elle se compose généralement de quelques pages de description
textuelle.

Règles d'urbanisme pour un diagramme des objectifs

Règle n° 1 : Un même objectif ne figure qu'une seule fois sur le diagramme.

Représentation graphique du modèle des objectifs
Règle n° 2 : Lorsqu'un objectif est décliné en sous-objectifs, la liste des sous-objectifs doit être
exhaustive pour atteindre l'objectif.
Règle n° 3 : Un objectif de niveau le plus fin doit pouvoir être associé à un ou plusieurs KPI (Key
Performance Indicator, indicateur clé de perfomance) SMART (Simple, Mesurable, Ambitieux mais
Réaliste et positionné dans le Temps).

Fig. 5.2

Règles de bonnes pratiques pour un diagramme des objectifs

Il Règle n° 1 : Un
existe objectif commence
plusieurs façons par un
deverbe.
modéliser les objectifs principaux et
intermédiaires d'une entreprise ou pas
Règle n° 2 : Le libellé d'un objectif ne comprend de « organisme.
d'un et » qui pourrait Nous
masquerproposons
deux [Link]
diagramme d'Ishikawa parce qu'il est à la fois visuel et synthétique (on
arrive généralement à tout modéliser sur une page de format A4), et ces
deux caractéristiques en font un excellent outil pour représenter et
communiquer une stratégie. Néanmoins, d'autres représentations peuvent
être tout aussi acceptables.
 3. Le diagramme d'entreprise
Représentation graphique du diagramme d'entreprise

Fig. 5.3

Objectifs du diagramme d'entreprise

Le diagramme d'entreprise est une vue « aérienne » de l'entreprise faisant
apparaître les différentes macro-activités métier (vente et commercial,
administration et finance, production et logistique, veille technologique et
recherche, marketing) et présentant les flux d'information échangés entre
ces macro-activités métier. On fait également figurer sur ce schéma de
synthèse les tiers (les clients et fournisseurs ainsi que les partenaires) ;
l'exhaustivité n'est pas nécessairement l'objectif recherché, mais
davantage la clarté et la compréhension « au premier coup d'œil » et par
tous de l'activité métier de l'entreprise.
Le diagramme d'entreprise permet de :
proposer une vision synthétique de l'activité de l'entreprise ;
figurer et positionner les clients, fournisseurs et partenaires, par rapport
à l'activité métier de l'organisation ;
comprendre les liens entre les macro-activités métier ;
communiquer aux dirigeants et collaborateurs un mode de vision
orienté
« processus » et non plus calqué sur les « organigrammes ».
Il est recommandé de réaliser un tel diagramme lors de la captation de la
stratégie et comme démarche préalable au contrôle de cohérence stratégie
métier – organisation fonctionnelle – diagramme synthétique entreprise-
flux – cartographie des processus.
Enfin, le diagramme d'entreprise peut être utilisé pour représenter une vue
aérienne de n'importe quel sous-ensemble de l'entreprise. On peut alors
l'appeler diagramme de contexte.
Règles de bonnes pratiques pour un diagramme d'entreprise

Règle n° 1 : Privilégier la clarté et la lisibilité à l'exhaustivité.

La carte des SI
Règle n° 2 : Indiquer dans le commentaire associé au diagramme ceux des flux entre processus
Toutes lesniveau
de premier entreprises n'ont
qui n'ont pas pas nécessairement
été indiqués undes
sur le diagramme pour seul [Link]
raisons Certaines,
lisibilité. et
c'est notamment le cas des sociétés multinationales et des grandes
administrations, peuvent avoir plusieurs SI.
Le choix entre une architecture mono-système d'information ou multi-
systèmes d'information est un choix de niveau stratégique qui relève de la
direction générale.
Nous exposons ici les principes permettant de faire ce choix et d'élaborer
la carte des SI.
La carte des SI précise l'organisation « fédérale » des SI d'une grande
entreprise généralement multinationale.

1. Les césures
Les trois principes permettant de définir les SI sont les suivants, classés par
ordre d'importance décroissante :
l'autonomie des
métiers ; la cohérence
du groupe ; les
synergies possibles.
Le principe d'autonomie des métiers suppose que les SI qui les
servent soient aussi indépendants que possible les uns des autres.
La carte des SI cibles peut par exemple préconiser que ces SI soient
structurés autour de lignes métier mondiales avec des applications
standardisées les plus indépendantes possibles de l'organisation, les
entités locales conservant une marge d'autonomie pour leur SI par rapport
aux applications du métier selon le niveau de standardisation poursuivi par
celui-ci et l'importance des spécificités locales.
Il est important de ne pas confondre métier et unité organisationnelle, car si
on crée un SI par unité organisationnelle, on obtient de très nombreux SI trop
liés à l'organisation, ce qui peut être une catastrophe du point de vue de
l'évolutivité.
Idéalement, un SI doit couvrir un et un seul métier de l'entreprise. Ainsi,
plusieurs métiers ne doivent pas partager le même SI. En revanche, un
même métier peut éventuellement disposer de plusieurs SI.
En effet, d'autres axes complémentaires de découpage peuvent être
opportuns mais ils dépendent des spécificités du périmètre considéré.
Sans prétendre à l'exhaustivité, les axes suivants sont les plus courants :
axe « entité juridique
», axe « ligne métier
»,
axe « catégorie de
clients », axe « nature
de produits », axe «
pays »,
axe « canal de distribution ».
Bien entendu, pour un périmètre donné, on n'opère pas autant de césures
qu'il y a d'axes complémentaires de découpage cités précédemment. Sont
retenus uniquement les axes les plus structurants pour le périmètre étudié.
Enfin, dans l'hypothèse où un même SI serait partagé par plusieurs
métiers, il est recommandé de veiller, lors du découpage fonctionnel de
ce SI, à ce que les éléments relatifs à des métiers différents soient
facilement dissociables.
La cohérence du groupe repose sur :
des SI de consolidation (comptabilité générale, contrôle de gestion,
gestion financière, risques) dont les applications s'imposent à tous les
autres SI ;
des référentiels normalisés (Identification Tiers, Identification client,
Produits, Structures) permettant essentiellement des consolidations
transverses. Ces normes doivent porter sur un nombre réduit de
données (il n'est pas nécessaire ni même souhaitable que les
référentiels groupe soient la somme des référentiels des SI) mais être
appliquées rigoureusement. Les métiers ont la charge de produire les
données correspondantes au format ad hoc, à charge pour eux de les
interfacer si les systèmes de production le nécessitent.
La synergie résulte d'une mise en commun de SI entre au moins deux
métiers sans que ce SI soit nécessaire à l'activité du niveau directement
holding.
Les SI sont typiquement organisés selon trois niveaux : le SI du niveau
holding, appelé SI Groupe, s'impose aux SI du niveau commun qui
s'imposent aux SI du niveau d'autonomie des métiers.
Le schéma de la figure 5.4 illustre ce que peut être la vision statique d'une
carte des SI.

Fig. 5.4

Chaque système d'information de cette carte est un SI : c'est donc un

système autonome sur lequel tous les principes et toutes les règles
présentés s'appliquent.
Dans le cas d'un projet d'urbanisation d'un système d'information d'une
entreprise ou d'un organisme ayant fait le choix d'urbaniser un seul de ses
SI, il faut d'abord réaliser la carte des SI et identifier les échanges entre le
SI à urbaniser et les autres SI de l'entreprise. On est ensuite ramené au cas
de l'urbanisation d'un SI.

2. Les échanges inter-SI

 Dans un contexte multi-SI, les échanges d'informations entre les SI
doivent être gérés par un ou plusieurs gestionnaire de flux, pour éviter la
multitude des relations
« point à point ». La figure 1.5 illustre ce principe.

Fig. 5.5

Les principales fonctionnalités assurées par un gestionnaire de flux inter-SI

sont les mêmes que celle d'un gestionnaire de flux interne à un SI.

3. Le plan d'urbanisme
Le plan d'urbanisme
fonctionnel
Le plan d'urbanisme fonctionnel a pour but de représenter de manière
macroscopique les interactions entre les systèmes d'information d'un
contexte multi- SI. Il comporte une vue statique et une vue dynamique.
Lors d'une analyse de l'existant, cette représentation permet de mettre en
évidence d'éventuelles redondances de flux ainsi que les échanges qui ne
transitent pas par les dispositifs d'échanges inter-SI.
La vue statique d'un plan d'urbanisme fonctionnel comprend :
la liste des systèmes d'information ;
le schéma des interactions (macro-flux fonctionnels) entre les systèmes
d'information ;
les fonds de carte pertinents montrant le positionnement des SI entre eux.
La vue dynamique (voir figure 5.6) d'un plan d'urbanisme fonctionnel
comprend les schémas, de type diagramme de séquence, décrivant le
déroulement des échanges entre SI lors de l'exécution des processus
majeurs du périmètre.
 Fig. 5.6

Le plan d'urbanisme applicatif

Le plan d'urbanisme applicatif a pour but de représenter de manière
macroscopique les interactions entre les systèmes informatiques (Si)
d'un contexte multi-Si. Il comporte une vue statique et une vue
dynamique.
Lors d'une analyse de l'existant, cette représentation permet de mettre en
évidence d'éventuelles redondances de flux ainsi que les échanges qui ne
transitent pas par les dispositifs d'échanges inter-Si.
La vue statique d'un plan d'urbanisme applicatif comprend :
la liste des systèmes informatiques (Si) ;
le schéma des interactions (macro-flux applicatifs) entre les
systèmes informatiques ;
les fonds de carte pertinents montrant le positionnement des Si entre eux.

Fig. 5.7

La vue dynamique (voir figure 5.7) d'un plan d'urbanisme applicatif

comprend les schémas, de type diagramme de séquence, décrivant le
déroulement des échanges entre Si lors de l'exécution des processus
majeurs du périmètre.
Le plan d'urbanisme technique
Le plan d'urbanisme technique a pour but de représenter de manière
macroscopique les interactions entre les éléments techniques d'un
contexte multi-Si. Il comporte une vue statique et une vue dynamique.

Étude de cas : urbanisme et stratégie

Cette section représente le dossier de fin de la phase de revue des axes
stratégiques du projet d'urbanisation du système d'information du tour-
opérateur.

1. Introduction
La finalité du projet d'urbanisation du SI du tour-opérateur peut s'exprimer
en une phrase : « Repenser et aligner l'architecture du système
d'information sur la stratégie d'entreprise et se donner les moyens d'une
évolution progressive par projets indépendants. »
Les objectifs correspondants à cette finalité sont de constituer les
architectures métier, fonctionnelle, applicative et technique cibles :
alignées sur les enjeux stratégiques de l'entreprise ;
permettant de désimbriquer progressivement les applicatifs existants ;
permettant de maîtriser les évolutions par paliers successifs, par
projets relativement indépendants, mutuellement cohérents et de taille
raisonnable en budget et en durée.
Dans ce cadre, cette phase de revue des axes stratégiques est destinée à
placer le projet d'urbanisation dans le cadre général de la stratégie de
l'entreprise. La direction et les responsables informatiques devaient
expliciter les grands axes dans lesquels s'inscrit l'étude. Cette activité a
donc été menée sur base d'entretiens, de collecte et d'analyse de
documents (la liste des personnes interviewées et des documents analysés
figure en annexe de ce document).
Ce document présente :
la restitution des objectifs stratégiques métier ;
la restitution des objectifs du système d'information et la définition
d'une première liste de KPI (Key Performance Indicator, indicateur clé
de perfomance) ; un diagnostic sur l'expression de la stratégie telle
qu'elle est, et en particulier sur les points à préciser.
La validation de cette restitution de la compréhension des axes
stratégiques par l'équipe d'étude est importante puisqu'ils constituent le
point de départ pour l'élaboration de la cible qui sera justifiée par sa
contribution à l'atteinte de ces objectifs.

2. Les objectifs stratégiques métier

Diagramme d'Ishikawa
Les objectifs stratégiques métier sont représentés par le diagramme
d'Ishikawa présenté figure 5.8.
 Fig. 5.8

Notes sur les axes stratégiques métier

Augmenter le nombre de contacts
Pour redevenir le tour-opérateur numéro un en France, il faut absolument
générer une croissance soutenue. Celle-ci passe, d'une part par
l'augmentation du nombre de contacts, d'autre part par l'augmentation du
taux de transformation des contacts en réservations.
Pour ce qui est de l'augmentation du nombre de contacts, il s'agit d'attirer
plus de visiteurs dans les différents (actuels et futurs) canaux de
distribution. L'atteinte de cet objectif ne peut être le fruit du hasard et
passe donc par une approche volontariste nécessitant une connaissance
fine des clients et prospects de manière à concevoir et mettre en œuvre
des plans marketing extrêmement ciblés et efficaces.
Augmenter le taux de transformation des contacts en réservations
L'autre vecteur d'accélération de la croissance est l'amélioration du taux de
transformation des contacts en réservations. Aujourd'hui, ce taux est
de 68 %. Un taux de 80 % ferait progresser le chiffre d'affaires d'environ
12 %. Pour atteindre cette cible de 80 % de taux de transformation des
contacts en réservations, il faut :
orienter les clients vers les produits disponibles ;
diminuer de manière drastique les réservations manquées dues à des
départs de clients face à l'importance des files d'attentes ;
permettre aux vendeurs de pouvoir se focaliser sur l'acte de vente en
réduisant leurs tâches administratives au minimum ;
traiter toutes les demandes en temps réel.
Développer des canaux alternatifs
Pour faire face à la concurrence croissante, le canal de distribution
traditionnel, même s'il est appelé à rester probablement encore
longtemps la principale source de vente, ne suffit plus. Il faut maintenant :
se positionner dans l'e-commerce en proposant les produits sous
une autre marque commerciale afin de capter un autre type de
clientèle qui pourrait se
 développer fortement dans un proche
avenir ; faire distribuer les produits par des
partenaires.
Outre leurs contributions au développement de la part de marché, l'atteinte
de ces objectifs aura un impact direct sur la rentabilité puisque
l'augmentation du volume d'affaire permettra d'améliorer la rentabilité de
l'entreprise de par les capacités de négociation supplémentaires qu'elle
permettra vis-à-vis des fournisseurs.
Diminuer les coûts de gestion
La stagnation des bénéfices depuis trois ans et même la légère baisse en
2005 ne sont plus acceptables pour les actionnaires. De plus, elles ont pour
effet de maintenir l'entreprise en position de rachat par l'un de ses
concurrents puisque le cours de l'action est au plus bas depuis plus d'un
an. La sortie de cette situation passe par la croissance et le gain de parts
de marché déjà exposés, mais aussi par une forte rentabilité alignée sur
les meilleures entreprises du secteur. L'enjeu est ici la diminution des coûts
de gestion à qualité de service constante. Quatre axes sont identifiés pour
réaliser cette diminution des coûts de gestion :
l'optimisation des ressources humaines du standard du siège, soit
actuellement 80 personnes qui font un travail sans création de valeur
pour le tour-opérateur. Il s'agit donc de supprimer ces activités pour les
remplacer par des activités créatrices de valeur ;
l'élimination des doubles saisies qui n'entraînent pas seulement des
pertes de temps mais aussi des erreurs qui finissent par coûter cher ;
la diminution des coûts de communication liés aux appels
téléphoniques incessants entre agences et service organisation et aux
fax quotidiens adressés aux agences ;
la distribution de produits de partenaires complétant l'offre du tour-
opérateur et ne nécessitant ni canal particulier, ni compétences pointues,
ni gestion (celle-ci restant à la charge du partenaire).
Améliorer le cash flow
Enfin, l'amélioration du cash flow doit aussi être obtenue et passe, d'une
part par la détection en temps réel des mauvais payeurs afin qu'ils ne
mobilisent pas des réservations qui auraient pu être attribuées à de bons
payeurs, d'autre part par une facturation plus rapide.

3. Les objectifs du système d'information

Dans le cas du tour-opérateur il n'y a qu'un seul système d'information
correspondant au seul et unique métier de celui-ci, la vente de voyages.

Diagramme d'Ishikawa
Les objectifs d'évolution du système d'information sont représentés par le
diagramme d'Ishikawa présenté figure 5.9.
 Fig. 5.9

Notes sur les objectifs du système d'information

Afin de répondre correctement aux objectifs métier, le SI doit se fixer les
objectifs détaillés suivants. Ces objectifs ont été déduits des objectifs métier, et
le lien entre objectifs stratégiques métier et objectifs du SI est décrit à
la section 4.
Améliorer la productivité des vendeurs
Il s'agit de mettre à disposition des vendeurs situés dans les agences ou les
agences principales un outil informatique leur permettant de s'affranchir de
la consultation du fax quotidien sur les disponibilités et de l'appel
téléphonique au siège pour vérifier la disponibilité en temps réel et
enregistrer les réservations.
En outre, l'interface homme/machine sera particulièrement étudiée de
manière à orienter le client sur les produits disponibles. Les données
concernant un client existant pourront être récupérées de manière à éviter
à la fois les pertes de temps et les risques d'erreur.
Optimiser la valeur des clients
Il s'agit de tirer le maximum des clients et prospects identifiés.
La mise en place d'un programme de fidélisation vise à ce qu'un client
dépense une plus grande part de son budget vacances avec des produits
de l'entreprise alors qu'actuellement, il est perçu qu'un même client peut
partir trois fois par an en vacances en ne passant qu'une seule fois par le
tour-opérateur. Il faut donc passer du stade de la perception à la certitude
et se donner les moyens d'analyse pour mettre en œuvre un marketing
ciblé permettant d'atteindre cet objectif.
Il faut donc enregistrer tous les contacts (sans nuire à la productivité de
vendeurs) et mettre en place un outil de gestion de la relation clientèle
parmi les plus performants du marché.
Ouvrir à la vente 24 h/24, 365 jours par an
La concurrence, la nécessité de se positionner dans l'e-commerce mais
aussi la dimension mondiale du tour-opérateur entraînent la nécessité
d'une ouverture du
système à la vente quasiment 24 h/24 et 365 jours par an. Cette ouverture
concerne essentiellement les référentiels produits et clients et les
réservations.
Permettre la vente directe
La vente directe correspond à une demande du marché et permet une
diminution significative des coûts de gestion.
Elle recouvre :
la vente sur le Web ;
la vente via un centre d'appels téléphoniques.
Pour le Web, il s'agit d'ouvrir un portail pour la vente de certains des
produits de l'entreprise et de produits de partenaires sous une marque
commerciale spécifique.
Pour le centre d'appels téléphoniques, il s'agit de vendre l'ensemble de
produits de l'entreprise sous la marque commerciale habituelle. Il s'agit
donc d'une agence supplémentaire mais virtuelle. L'enjeu est aussi de
reconvertir les gestionnaires du service organisation vers un rôle de télé
conseillé. Bien entendu, un programme de conduite du changement
spécifique sera conçu et mis en œuvre pour la transformation des
compétences de ces gestionnaires futurs téléconseillers.
Accepter ou refuser en temps réel les demandes de paiements échelonnés
L'acceptation en temps réel des demandes de paiements échelonnés
permettra de ne plus polluer le système avec des préréservations qui sont
ensuite annulées et diminuera les coûts de gestion.
Intégrer des produits de tiers au catalogue
Le système d'information doit permettre la distribution de produits de
partenaires complétant l'offre du tour-opérateur et ne nécessitant ni canal
particulier, ni compétences pointues, ni gestion (celle-ci restant à la charge
du partenaire).

4. Correspondance objectifs métier/objectifs SI

Le tableau suivant présente la vue globale de la contribution des objectifs
retenus pour la construction du futur SI aux objectifs stratégiques métier. Il
ne reprend que les principaux objectifs des diagrammes d'Ishikawa. Un
tableau exhaustif de correspondance est présenté en section 7.

Key Performance Indicators (KPI)

Cette section a pour but de mettre en regard au moins un « indicateur de
performance » en face de chacun des objectifs identifiés pour le futur SI.
Ces KPI seront suivis régulièrement pour vérifier si les objectifs fixés sont
atteints et donc de mesurer l'efficacité du plan d'évolution du système
d'information mis en œuvre pour implémenter la stratégie d'entreprise.
Ces KPI sont ici fournis à titre illustratif. Dans la réalité, pour chaque KPI, il
faut en plus indiquer la performance actuelle et la performance visée.
 Tab. 5.1

le nombre de

Augmenter
Augmenter

s
alternatif
canaux
er
Développ

Amélior
Diminu
le taux

gestio

coûts
er les
Objectifs métier

cash
er le
flow
de
n
Objectifs SI

des
Améliorer la productivité ×
×
des vendeurs

Optimiser la valeur des clients × × ×

Ouvrir la vente 24 h/24 × × × ×

Permettre la vente directe × × × ×

Accepter ou refuser en
temps réel les demandes × ×
de paiements échelonnés
Intégrer des produits de tiers au × ×
catalogue × ×

Améliorer la productivité des vendeurs

Nombre de contacts enregistrés par vendeur en agence par période.
Nombre de contacts enregistrés par vendeur en agence principale par
période. Nombre de contacts enregistrés par téléconseiller par
période.
Nombre de réservations enregistrées par vendeur en agence par
période. Nombre de réservations enregistrées par vendeur en agence
principale par période.
Nombre de réservations enregistrées par téléconseiller par période.
Taux de transformation des contacts par vendeur en agence par période.
Taux de transformation des contacts par vendeur en agence
principale par période.
Taux de transformation des contacts par téléconseiller par période.
Optimiser la valeur des clients
Nombre moyen de séjours par an par client.
Taux de clients de l'année N-1 également clients l'année N.
Ouvrir à la vente 24 h/24, 365 jours par an
Disponibilité du système de réservation pour les agences.
Disponibilité du système de réservation pour les agences
principales. Disponibilité du système de réservation pour le
portail web.
Disponibilité du système de réservation pour le centre de communication.
Permettre la vente directe
Nombre de réservations enregistrées par le centre de
communication. Nombre de réservations enregistrées par le portail
web.
Accepter ou refuser en temps réel les demandes de paiements échelonnés
 Nombre de demandes de paiements échelonnées non traitées en temps réel.
Insérer des produits de tiers au catalogue
Nombre de produits de tiers au
catalogue. CA généré par les
produits de tiers.
Marges générées par les produits de
tiers. Dans la pratique un bon KPI doit
être SMART :
Simple,
Mesurable,
Ambitieux,
mais
Réaliste,
et positionné dans le Temps.

5. Conclusions sur la compréhension de la stratégie

D'une manière générale, la tendance observée lors des interviews de la
phase de revue des axes stratégiques est que les objectifs stratégiques du
tour-opérateur sont connus et partagés par les acteurs interviewés.
Cette observation est suffisamment remarquable pour qu'elle soit soulignée.
Le bilan de l'existant et la construction de la cible devraient en être plus
aisés ; ils permettront par ailleurs de valider la profondeur de cette
assertion aux niveaux opérationnels de l'entreprise.
La phase de revue des axes stratégiques a par ailleurs permis de mettre en
lumière une zone d'incertitude et de débat sur laquelle il est important de
se pencher.
Bien que la vente de produits de tiers soit apparue comme un objectif
incontesté quant à sa contribution à la stratégie, son contour est
encore aujourd'hui trop flou pour que l'on puisse en dériver des objectifs
opérationnels valables pour le futur système d'information.
Sans avoir fait l'objet d'une analyse approfondie, les résultats des
interviews font a priori apparaître que ce concept recouvre une masse
hétérogène de produits potentiels.
Il est essentiel que le périmètre que recouvre ce concept de vente de
produits de tiers soit précisé, car cela peut avoir des impacts significatifs
sur la construction de la cible. À défaut, les canaux « vente de produits de
tiers » devront faire l'objet d'une
« zone » séparée, sans couplage fort du système d'information cible, à
construire plus tard.

Hiérarchisation et priorisation des objectifs métier

Le (ou les) KPI associé à un objectif métier permet de mettre en évidence les
enjeux associés à cet objectif. C'est alors une information très utile pour
prioriser les objectifs.
Dans notre cas, les personnes interviewées ont indiqué les priorités du
tableau 5.2 pour les objectifs métier retenus.
 Tab. 5.2

PrioritéPrioritéPriorité
Objectifs stratégiques métier
maximalemoyenne minimale
Augmenter le nombre de contacts ×

Développer un marketing ciblé ×

Développer une connaissance fine des clients ×
Augmenter la plage d'ouverture à la
vente ×

Augmenter le taux de transformation

des contacts en réservation ×

Orienter les contacts vers les produits

disponibles ×

Permettre aux vendeurs de se focaliser

davantage sur l'acte de vente ×

Réduire les files d'attente ×

Diminuer la charge administrative des
vendeurs ×

Traiter toutes les demandes en temps

×
réel
Développer les canaux alternatifs ×
Faire distribuer les produits par des partenaires ×
Se positionner dans l'e-commerce ×
Diminuer les coûts de gestion ×
Optimiser les ressources humaines du
standard du siège ×

Diminuer les coûts de communication ×

Éliminer les doubles saisies et les erreurs

×
en découlant
Distribuer les produits de partenaires ×
Améliorer le cash flow ×
Facturer plus rapidement ×
Détecter en temps réel les mauvais payeurs ×

Hiérarchisation et priorisation des objectifs SI

La matrice de croisement des objectifs métier et SI et le jugement ont
permis de déduire aisément les priorités des objectifs SI à partir des
priorités des objectifs métier. Le résultat est présenté dans le tableau 5.3.
 Tab. 5.3
PrioritéPrioritéPriorité
Objectifs SI
maximale moyenne minimale
Améliorer la productivité des vendeurs ×
Proposer une application d'aide à la vente
×
efficace
Proposer une IHM ciblée et ergonomique ×
Récupérer données client si client existant ×
Contrôler en temps réel les disponibilités ×
Optimiser la valeur des clients ×
Mettre en place un programme de fidélité ×
Mettre en place un marketing ciblé ×
Enregistrer tous les contacts ×
Mettre en place un outil de gestion de la
relation clientèle ×
Ouvrir à la vente 24 h/24 ×
Permette un accès aux référentiels produit et
×
client 24 h/24
Permettre un accès aux réservations 24 h/24 ×
Permettre la vente directe ×
Ouvrir un portail de vente directe sur le Web ×
Transformer le standard en centre d'appels ×
Accepter ou refuser en temps réel les
demandes ×
de paiements échelonnés
Automatiser les demandes de paiements
échelonnés ×
Intégrer des produits tiers au catalogue ×

6. Diagramme d'entreprise
Le diagramme a été réalisé pour la situation actuelle du tour-opérateur et pour
la situation cible.

Diagramme d'entreprise : situation actuelle

Tous les flux sont des flux d'information. Les flux financiers sont indiqués
par des flèches en pointillé. Il est à noter que ce schéma n'est pas
exhaustif. Par exemple, la direction générale n'est pas représentée et ses
échanges avec la direction organisation en ce qui concerne la validation du
catalogue non plus. (Voir figure 5.10)
 Fig. 5.10

Diagramme d'entreprise : situation cible

Tous les flux sont des flux d'information. Les flux financiers sont indiqués
par des flèches en pointillé. Comme pour le diagramme d'entreprise
représentant l'existant, il est à noter que ce schéma n'est pas exhaustif.
Par exemple la direction générale n'est pas représentée et ses échanges
avec la direction organisation en ce qui concerne la validation du catalogue
non plus. (Voir figure 5.11)

Fig. 5.11

L'écart entre l'existant et la cible apparaît centré sur les points essentiels
suivants :
suppression de la préréservationet prise directe de réservations,
d'où suppression des flux entre agences et direction
organisation ;
apparition d'une agence virtuelle via le Web et un centre
d'appels ; traitement en temps réel des demandes de
paiements échelonnés ;
intégration au catalogue de produits de partenaires et mise à disposition
de partenaires de produits du tour-opérateur pour commercialisation. Ce
point génère des flux entre la direction organisation et les partenaires,
et en ce qui
 concerne les flux financiers, ils sont également générés mais cette fois
entre la direction financière et les partenaires.
Conscient de l'enjeu que représente l'informatique pour l'atteinte de
cette cible, le directeur général, M. Gérard Bertrand, a décidé de créer une
direction des systèmes d'information dirigée par M. Christophe
Chevillard. L'organigramme cible est le suivant et se différencie donc de
l'organigramme existant par le remplacement du service informatique
rattaché à la direction financière par une véritable direction des systèmes
d'information.

Fig. 5.12

7. Annexes
Annexe 1 : correspondance objectifs métier/objectifs SI
Le tableau synthétique de correspondance objectifs métier/objectifs SI est
présenté
au paragraphe 4. L e tableau détaillé est présenté pages suivantes.

Tab. 5.4
contacts
de
lceibnloé mbre
ntger
mAu
uu
coD
plaege
enrvteartion
uennugrémse
onptpaecrts
dDAeésveclo
eter
fdo'actatleisn
leessfiles
e
dd
rtsrative
avdenmdineuis
acréuhexalrge
en tempsela
dte
m
PaDleitmer
nnaeux
ldeesmcaa
aleirses
tpoaurtesn
pTco
deasns l'e-
oionnner
plgoesstiti
r
ddeistribue
eOnptimiser
erreurs
ldpeeasrtenaires
its t
pfslorowdu
ehs
deocuabsl
ent
leaspidem
éliorer
Allrems
er
Dpliusstriibeur
n
ÉrprFeasli
mauvc t u
rnReedeurs
srso

a isies e
rinneau
clneaigrkmeetin

Dro

Objectifs stratégiques
tirfrss

réa

métier/
r ym e u
uance

ésduevi

mvditm
nvnerati

Objectifs d'évolution
e uiets
t

du SI

Améliorer la × ×
productivité des
vendeurs
Proposer une • • • • • • •
application d'aide à
la vente efficace
Proposer une IHM • • • • • •
ciblée et
ergonomique
Récupérer données • • •
client si client
existant
Contrôler en temps • • • •
réel les disponibilités
Optimiser la valeur × × ×
des clients
Mettre en place un • •
programme de
fidélité
Mettre en place • • • •
un marketing ciblé
Enregistrer tous • • •
les contacts
Mettre en place un • • •
outil de gestion
de la relation clientèle

mauv
contacts
muarketing
nter
u
fin
iusrseance
coDounvnerat
ion
eunneréservat
dfo'actatleisn
leessfiles
e
dd
rtsrative
avdenmdineuis
acréuhexalrge
metpsela
tei
rss enei
naudtetiref
m
aPD
mdmuietsrce
cor
paons l'e-
ldeesstion
ne
pgdroisstritiibou
ulaenr tles
D
eOnptimiser
erreurs
ldpeeasrtenaires
its t
pfslroowdu
bslehs
ldeeoscua
lAiorammrepieérnt
e
er
Dpliusstriibeur
n
ÉrprFeasli
oonptpaecrt
dDAeésvecl

rnReedeurs
Aclendiegnmtse

a isies e
ldéimcoinu
ermr

n er
é leospper
Objectifs stratégiques

plage

dleatm
métier/

r cymteuu
ésduevi
Objectifs d'évolution

nn

dl
du SI

Ouvrir à la × × × ×
vente 24 h/24
Permettre un accès • • • • • • • • • •
aux référentiels
voyages et client 24
h/24
Permettre un accès • • • • • • • • • •
aux réservations 24
h/24
Permettre la × × × ×
vente directe
Ouvrir un portail de • • • • • •
vente directe sur le
Web
Transformer le • • • • • •
standard en centre
d'appels
Accepter ou refuser × ×
en temps réel les
demandes de
paiements
échelonnés
Automatiser les • • •
demandes de
paiements échelonnés
Intégrer des × × × ×
produits tiers au
catalogue

Annexe 2 : liste des personnes interviewées

Les entretiens réalisés en complément de l'analyse des documents
mentionnés en annexe 3 pour acquérir une vision complète des axes
stratégiques de développement du tour-opérateur sont les suivants :
Gérard Bertrand (président-directeur général)
; Félix Louvet (directeur financier) ;
Roland Faure (directeur organisation) ;
Sylvie Régnaud (directeur marketing) ;
Robert François (directeur
commercial) ; Jean Ramon (directeur
exploitation) ;
Christophe Chevillard (directeur des systèmes d'information).
Remarque : toutes les personnes interviewées sont des directeurs. En cas
d'indisponibilité, ils auraient pu être remplacés par leurs collaborateurs
directs. Cependant, même dans ce cas, aucune personne du terrain
n'aurait été interviewée
car il ne s'agit pas de faire ou de remettre en cause la stratégie, mais plus
modestement de la comprendre et de la restituer. C'est pourquoi les
directeurs, ou à défaut leurs collaborateurs directs, constituent le bon
niveau pour ces entretiens.

Annexe 3 : liste des documents utilisés

La liste des documents étudiés lors de la phase de revue des axes
stratégiques est la suivante :
plan stratégique métier ;
rapport d'audit de l'organisation des
réservations ; rapport d'audit du système
d'information actuel ; architecture du poste
de travail ;
organigramme ;
étude de l'existant des projets an 2000 et euro.
Urbanisme et processus métier

Ce chapitre décrit le « comment faire » pour les activités liées à la cartographie

métier existante ou cible de la démarche méthodologique d'urbanisation de
système d'information.

Introduction
Il convient tout d'abord de rappeler la définition d'un processus.
Un processus est constitué d'un réseau d'activités ayant pour finalité le
traitement d'un événement de gestion initiateur. Il a pour objectif la production
des flux de résultats définis dans des conditions de délais et de qualité fixés
pour répondre aux besoins de tiers internes ou externes.
Il doit être défini indépendamment de toute organisation et de tout système
existant dans l'entreprise, et il correspond à la vision fonctionnelle des utilisateurs.
Une procédure, appelée aussi processus organisé, est quant à elle l'image d'un
processus métier décrit dans le cadre d'une organisation structurée. Elle
désigne une séquence d'opérations effectuées par des acteurs agissant sur des
données et régies par des règles de gestion liées à des jalons. Une procédure
est déclenchée par une demande et finalisée par l'acceptation d'un résultat.
Il est également à noter qu'un processus est conçu de bout en bout depuis la
demande du client (interne ou externe) et apporte une valeur ajoutée croissante
jusqu'à la satisfaction complète de celle-ci. Il ne s'arrête pas nécessairement
aux frontières d'un SI (cas ou l'entreprise a plusieurs SI comme évoqué au
paragraphe 5.3) ni même aux frontières de l'entreprise elle-même.

La cartographie des processus et le lien avec la stratégie

1. La cartographie des processus
Les objectifs de la cartographie des processus
La cartographie des processus permet :
d'avoir une vue « aérienne » de l'ensemble des
processus ; de classer les processus en sous-
catégories telles que :
processus opérationnels (processus ayant un impact direct sur la
performance de l'entreprise ou de l'organisme. Ils fournissent des produits
et des services à des clients) ;
processus de pilotage (processus permettant de fixer des orientations,
d'évaluer par rapport à celles-ci une situation passée, présente ou
future et de décider d'actions correctives si nécessaire) ;
processus de support (processus ayant un impact indirect sur la
performance de l'entreprise ou de l'organisme. Ils gèrent les ressources de
l'entreprise).
d'identifier les liens qui peuvent exister entre plusieurs
processus ; d'établir une aide aux affectations de priorités pour
la reconfiguration ;
de permettre à l'ensemble de l'organisation à tous les niveaux de la hiérarchie
de se
« situer » dans une logique descriptive issue des processus ;
 de faciliter en phase préalable la spécification et la mise en place d'un
système d'amélioration de la performance.

Règles de bonnes pratiques pour la cartographie des processus

Règle n° 1 : Les processus opérationnels, les processus de pilotage et les processus de support sont
La représentation graphique de la cartographie des processus

Fig. 6.1

2. La matrice processus/objectifs stratégiques

L'alignement des processus (ou d'ailleurs des procédures) sur la stratégie
peut être visualisé sous la forme d'une matrice processus/objectifs.
Les colonnes de la matrice sont constituées des objectifs représentés par des
flèches dans le diagramme d'Ishikawa modélisant la stratégie de l'entreprise ou de
l'organisme. Tous les objectifs et sous-objectifs donnent lieu à une colonne, d'où
un nombre de colonnes égal au nombre de flèches figurant sur le diagramme
moins 1 (pour la flèche principale).
Les lignes de la matrice sont constituées des différents processus.
À l'intersection d'une ligne et d'une colonne, on indique la contribution du
processus à l'atteinte de l'objectif stratégique. Celle-ci peut être :
pas de contribution ;
contribution faible lorsqu'un dysfonctionnement sur le processus a un impact
sur l'atteinte de l'objectif sans pour autant remettre en cause à lui seul
l'atteinte de l'objectif ;
contribution forte lorsqu'un dysfonctionnement sur le processus est de nature
à remettre en cause à lui seul l'atteinte de l'objectif.
Cette matrice permet d'identifier :
les processus ne contribuant à aucun objectif stratégique ;
 les objectifs stratégiques non adressés par au moins un processus ;
les processus critiques pour l'atteinte des objectifs stratégiques de
l'entreprise. Il est à noter que des grilles de cotation plus sophistiquées
peuvent être établies.

La modélisation de processus
1. Introduction
Cette section décrit :
le formalisme utilisé pour modéliser les processus ;
comment des processus peuvent être réutilisés ou conçus en vue de leur
réutilisation ; le problème de la sous-traitance ;
les stratégies de coordination dans le cas d'une architecture de réseau
d'acteurs ; les avantages et les désavantages comparés des modèles de
processus soft et hard ; les règles d'urbanisme pour la modélisation de
processus ;
les règles de bonnes pratiques pour la modélisation de processus.
On trouvera enfin une présentation des pratiques et des règles de normalisation
à appliquer pour réaliser un modèle de processus de qualité.

2. Le diagramme de processus (organisé)

Le modèle de processus (organisé ou non) est le modèle le plus important pour
représenter toutes les facettes d'un processus. Il décrit le circuit des travaux
(activités) entre les différents acteurs (au sens UML) et, par conséquent, une
série de choix organisationnels (qui fait quoi ? quand ? s'agit-il ou non d'un
acteur humain ? etc.).
Un modèle de processus est composé d'un diagramme de processus
et d'une
description de processus.
La description du processus est le complément naturel du diagramme de
processus. Très peu d'informations textuelles figurent sur ce dernier. Il est donc
indispensable de fournir des informations complémentaires afin d'expliquer les
différents choix le plus clairement possible.
Un diagramme de processus est composé de tout ou partie des éléments suivants :
unités ou acteurs organisationnels (à un niveau d'abstraction élevé car sinon
on est lié à l'organisation et il ne s'agit alors plus de processus mais de
procédures) ;
activités ;
événements ;
données (électroniques ou autres) ;
matières premières ;
produit ;
ressources informatiques.
Les unités organisationnelles ou les acteurs sont des exécutants
chargés de réaliser les activités qui doivent être menées à bien pour atteindre
les objectifs de l'entreprise ou de l'organisme.
Une activité est une tâche ou une action conduite sur un objet dans l'objectif
d'atteindre un ou plusieurs des objectifs fixés par la société. Une activité peut
comporter des préconditions et des postconditions.
Par événement, nous entendons le fait qu'un objet métier bénéficie d'un
statut lié au métier qui contrôle ou influence le reste du processus. Les
événements déclenchent des activités et peuvent être le résultat d'activités.
Les données représentent l'ensemble des données qui participent au processus ;
nous faisons la distinction entre les données qui sont disponibles en format
électronique et les données qui ne sont disponibles qu'en format papier.
Les matières premières sont les marchandises que la société achète à des
fournisseurs pour pouvoir fabriquer les produits finis.
Les produits sont les produits finis fabriqués par l'unité de production de la
société (une usine, par exemple, si nous sommes dans le secteur industriel).
Les ressources informatiques regroupent l'ensemble des ressources de
traitement de l'information. Elles comprennent les ordinateurs, les réseaux, les
logiciels, les entrepôts de données, etc.

Représentation graphique
Exemple de modèle de processus : cas d'une SSII. Gestion des rapports
mensuels de projets.

Fig. 6.2

3. La réutilisation de processus
L'un des avantages majeurs d'une description formelle d'un processus est la
possibilité de le réutiliser. Cela peut être fait :
en partant d'un processus existant qui est modifié ;
en créant un processus généralisé et en dérivant des instances, en
donnant des valeurs spécifiques à un jeu de paramètres.
Dans un cas comme dans l'autre, nous appelons le processus à partir duquel
un autre est construit un modèle de référence.
N'importe quel modèle de processus peut être utilisé comme modèle de
référence. Il s'agit ici en fait du concept d'héritage de l'analyse orientée objet, qui
constitue l'une des principales techniques permettant de réduire les coûts de
développement.
Il est même possible de créer des stratégies optimisées lorsque des
problèmes standard sont reconnus dans un modèle de processus, ce qui facilitera
grandement les tâches de reconfiguration.

4. La décomposition ou la sous-traitance
Un élément de choix crucial dans la conception d'un processus est son
niveau de résolution ou le degré de finesse de sa représentation :
une activité du processus peut être décomposée sans créer de nouveau
processus. Le modèle de processus est alors simplement affiné ;
une activité peut être sous-traitée auprès d'un autre acteur (n'intervenant pas
dans le processus). Cela signifie l'envoi d'un message à un autre processus
qui est décrit par un autre modèle de processus. L'un des aspects
principaux de la sous-traitance est le fait que l'activité sous-traitée soit
exécutée avec ou sans contrôle temporel. Si aucun contrôle temporel n'est
envisagé, le fait d'envoyer le message signifie qu'il sera exécuté en dernier
ressort. En cas de commande de temporisation, le processus d'envoi doit
inclure une activité d'attente qui s'achèvera au moment voulu ou qui sera
annulée si l'ordre est exécuté. Ainsi, l'acte de sous-traiter revient à
communiquer une situation qui induit un déclenchement par l'acteur sous-
traitant ;
une activité peut aussi être commandée à un acteur situé en dehors des
limites du modèle de processus d'entreprise, avec ou sans contrôle de
temporisation. L'interruption transmise par cet acteur est le signal que
l'activité a été exécutée. Cela n'interrompt pas l'exécution des autres
activités.
Il est important de noter que :
l'envoi d'une instruction à un acteur consiste toujours en la transmission
d'une situation. C'est ensuite l'acteur qui est en charge de l'analyse du
message et du déclenchement de l'exécution voulue. C'est tout du moins
ce qu'espère l'envoyeur, qui devra ensuite s'en assurer !
la seule signification des messages qui circulent sur les interfaces d'un
processus de transmission sont des situations résultant de l'exécution
d'activités.

Les stratégies de coordination dans le cas d'une architecture de

réseau d'acteurs
Un processus est un réseau d'activités menant à un objectif. Mais qui est
responsable de l'exécution d'un ensemble d'activités coordonnées ? Une bonne
conception de processus ne peut faire l'impasse sur cette question.
En fait, ce problème a trois aspects distincts :
Qui est en charge de l'exécution ? Une organisation ou un membre de celle-
ci ?
À un bas niveau de résolution, c'est l'organisation qui est responsable
de l'ensemble.
À un niveau de résolution plus élevé, le processus doit être plus précis et
indiquer quelle personne spécifique en a la charge.
Si les acteurs potentiels sont définis, la question est alors de savoir qui donne
les instructions à ces personnes.
Qui prend la décision ? Le gestionnaire ou l'exécutant ?
Un exécutant se contente de faire ce que son chef lui a ordonné et de lui en
rendre compte afin que le gestionnaire soit en position de coordonner
efficacement le réseau. On parle ici de coordination centrale.
Un assistant ayant un plus haut degré d'habilitation peut n'avoir besoin que
d'un signal de déclenchement. Il devient lui-même actif sous l'impulsion de
ce signal, prend la décision voulue et l'exécute. Il rend ensuite compte
au gestionnaire. On
 parle ici de contrôle déconcentré. Il s'agit du premier niveau de
responsabilité (d'habilitation) des assistants.
Qui définit le périmètre d'impact et décide des alertes ou des impulsions ?
La responsabilité peut en incomber au gestionnaire, qui agit plus
comme l'entraîneur d'une équipe que comme un chef. Sa tâche consiste
davantage à stimuler qu'à diriger. Nous parlerons ici de coordination
déconcentrée.
Cette responsabilité peut aussi être confiée à des membres de l'équipe. Ils
réagissent à une situation nouvelle, déterminent s'il faut faire quelque
chose et, si c'est le cas, déterminent le périmètre d'impact, définissent ce
qu'il faut faire et le font ou transmettent un message à un membre plus
compétent de l'équipe. Il s'agit de la vraie coordination décentralisée.

6. Modèle de processus soft et hard

Un modèle de processus hard est extrêmement complexe et doit être limité à une
seule transaction. Il inclut les activités de base, les activités impactées et les
activités inférées, les règles de dérivation et les conditions de leur déclenchement.
Pour rendre un modèle de processus plus compréhensible, de nombreuses
simplifications peuvent être envisagées :
tout ce qui concerne l'affectation des acteurs avant le déclenchement
d'une transaction peut être éliminé ;
tout ce qui concerne le traitement des erreurs et des anomalies peut être
supprimé ; tous les impacts indirects et induits peuvent être omis, pour
ne conserver que le chaînage de base. Ainsi, les objets impactés sans
changement d'état sont implicites.
Ces modèles de processus simplifiés, qui respectent moins les contraintes
syntaxiques et sémantiques, sont plus faciles à lire, mais aussi plus confus. Ils
ne sont généralement pas suffisamment précis pour permettre d'évaluer un
processus, et peuvent donner une vue assez fausse du modèle de processus
d'entreprise.

7. Les règles d'urbanisme des modèles de processus

L'application des pratiques stipulées plus haut permettra de réaliser un modèle
de processus soft, en ce sens qu'il sera destiné à être utilisé par des personnes
expérimentées. Ces diagrammes n'ont pas pour objet d'être précis (par exemple,
certaines activités peuvent être globales et nécessiter de nombreux acteurs ; les
activités interrompues, associées à la fin d'une activité, peuvent être omises ;
certaines règles de gestion peuvent être confuses ou non encore décidées),
mais l'aspect général est celui d'un modèle de processus.
Même s'ils sont utiles à des fins de compréhension, de communication et de
conception, ces modèles ne pourraient pas être utilisés par un ordinateur. Si
l'exécution d'un processus est purement manuelle, ce type de description soft
peut conduire à des surprises lorsqu'elle est utilisée par des personnes
inexpérimentées.
La normalisation des modèles de processus vise à appliquer les pratiques dans
un cadre plus contraignant pour produire des diagrammes hard, à savoir :
non ambigus
; exhaustifs ;
cohérents.
Les diagrammes hard qui peuvent être interprétés par un ordinateur ou un
opérateur humain inexpérimenté mais intelligent doivent respecter d'autres
contraintes.

Règle n° 1 : Une activité d'un processus appartient à un et un seul SI. Une activité d'un processus ne peut donc faire appel aux serv
 Règle n° 2 : Toute transformation des propriétés d'un objet résulte d'une activité, même si c'est simplement l'âge de l'objet qui chan
Règle n° 3 : Une activité élémentaire ne peut être interrompue, ce qui signifie qu'une fois qu'un acteur est affecté à une activité, il n
Règle n° 4 : La fin d'exécution d'une activité force la fin d'exécution simultanée de toutes les activités appartenant au périmètre d'im
Règle n° 5 : Toutes les activités peuvent avoir une fin anormale, mais aussi des événements temporels ou d'abandon. Chacun de ce

8. Les règles de bonnes pratiques pour les modèles de processus

Un processus peut utiliser de différentes manières les concepts du modèle de
processus. La description peut être plus ou moins complète, mais si elle est
pleinement exhaustive comme dans les spécifications d'un processus
automatisé, il est recommandé d'observer les règles suivantes :

Règleest
Cela : La décomposition
n° 1vrai, des processus
soit parce qu'il est limitée à
y a de multiples trois niveaux. Par définition,
représentations d'un même un sous-
fait réel
processus est un processus et doit donc satisfaire la définition d'un processus.
(impacts indirects), soit parce que les règles de gestion impliquent la réévaluation
: Une étape (impacts
Règle n° 2activités du processus correspond à un activité,
type de transformation d'unun
objet exprimé comme
d'autres induits). Une un objet ou événement peut
son état.
toutefois déclencher l'étape. Tous les autres impacts sont indirects ou induits par
Règle n° 3 : Toute fin d'activité génère un événement qui correspond au fait que la transformation
cet
estévénement principal, puisque l'activité concerne de nombreux objets.
finie ou interrompue.
Règle n° 4 : L'occurrence d'un événement porte en elle la fin des transformations d'autres objets qui

Règle n° 5 : Un événement peut activer de nombreux événements déclenchés, au moins un pour chaque
L'évaluation et l'amélioration des processus
objet concerné.
Règle n° 6 : Chaque déclenchement est associé à une décision qui peut commander une activité ou une
1. Introduction
Cette partie donne certaines informations sur l'évaluation des processus. Elle
présente en outre l'alternative que constitue la gestion totale de la qualité, qui est
une approche d'amélioration lente et continue, par rapport à la reconfiguration des
processus, qui est une approche d'amélioration de type grand bond en avant. Elle
décrit enfin les sept axes traditionnels qui peuvent être utilisés pour améliorer les
processus.

2. L'évaluation des processus

Une fois les processus analysés, l'étape suivante consiste logiquement à les
évaluer et à identifier les moyens d'améliorer leur rentabilité. Ceci peut parfois
entraîner la modification des besoins définis antérieurement.
Les améliorations peuvent être insignifiantes ou radicales. L'approche qui
consiste en une amélioration lente et continue des processus correspond à la
gestion totale de la qualité. L'approche de type grand bond en avant
correspond à la véritable méthode de reconfiguration des processus.
Notez que la gestion totale de la qualité et la reconfiguration des processus
sont, par nature, complémentaires. La gestion totale de la qualité fournit le cadre
culturel nécessaire à la reconfiguration des processus. Elle met notamment
l'accent sur la nécessité de changer de comportements et d'attitudes vis-à-vis
des clients. Ce changement permet à son tour de créer/générer l'environnement
propice à la mise en œuvre des diverses stratégies de reconfiguration des
processus.
Notez également que les outils méthodologiques proposés dans ce chapitre pour
les processus peuvent être utilisés à la fois pour la reconfiguration des processus
et pour la gestion totale de la qualité.
L'évaluation d'un processus implique la détermination des coûts et de la qualité
des produits et services fournis par ce processus.
La qualité est principalement évaluée en déterminant dans quelle mesure les
objectifs primaires et secondaires de l'entreprise ou de l'organisme sont atteints.
Le coût du manque de qualité sera mesuré lorsque le processus considéré sera
utilisé pour fournir des produits et services.
Les raisons de ce manque de qualité sont généralement :
le retard de livraison ;
la non-conformité aux spécifications ;
le manque de flexibilité et donc la non-satisfaction des besoins du client.
Exemple : une société de vente par Internet de produits frais a déposé son
bilan du fait d'une logistique défaillante entraînant des livraisons de produits déjà
périmés et des clients mécontents. Le manque de qualité sur le processus de
livraison a donc eu un coût très élevé puisqu'il a été jusqu'à entraîner la
disparition de la société.
Les coûts seront évalués à partir de l'utilisation des ressources par les activités
du processus : personnel, équipements et consommables. Si le processus
organisé est normalisé, chaque activité est effectuée par un seul acteur et le
coût peut donc être calculé sur la base :
du coût unitaire de l' acteur ;
de la quantité utilisée et de la durée de la
tâche ; de la fréquence d'utilisation par
élément en sortie.

3. L'amélioration des processus

Toute amélioration résulte d'une diminution du coût des activités. Celle-ci peut
être liée à la suppression d'une activité ou à l'exécution d'une activité par un
autre type de processeur ou encore à une meilleure coordination des activités.
En conséquence, les sept axes permettant d'améliorer un processus sont :
l'automatisation des activités ;
la gestion plus précise des activités ;
l'extension du périmètre d'impact ;
l'anticipation des besoins ;
le développement de différents scénarios d'exécution ;
la réduction des interfaces manuelles et des opérations de réconciliation ;
l'amélioration de la technologie.

L'automatisation des activités

Cela signifie qu'on utilise un autre type de processeur de manière à réduire les
coûts et à produire de manière répétitive. L'exemple typique est bien entendu le
remplacement de l'homme par la machine pour exécuter une activité.

La gestion plus précise des activités

Il s'agit de gérer plus finement les activités de manière à mieux connaître les
détails de l'exécution, à pouvoir donc détecter les problèmes plus rapidement et
plus précisément, et à pouvoir en informer les autres personnes concernées.

L'extension du périmètre d'impact

Il s'agit d'étendre le périmètre d'impact afin de tenir compte immédiatement de
toutes les conséquences d'un événement et, donc, de mieux organiser
l'utilisation des processeurs. Par exemple, dans un magasin de distribution de
produits électroménagers, lorsqu'on passe en rayon commander un produit, la
vérification de disponibilité et la commande sont passées en rayon mais l'impact
de l'événement va jusqu'à la manutention de manière que lorsque le client se
présente au comptoir de retrait des marchandises après être passé en caisse, sa
marchandise soit déjà prête ou a minima en cours de préparation. L'effet est,
dans ce cas, une réduction significative du temps d'attente au comptoir de retrait
des marchandises, ce qui a un impact direct sur la satisfaction du client.

L'anticipation plus efficace des besoins à long terme

Il s'agit de mieux anticiper les besoins à long terme et, donc, de la capacité
à mieux planifier l'utilisation des ressources matérielles et/ou humaines à long
terme et à réduire les ressources inutilisées.

Le développement de différents scénarios d'exécution pour une activité donnée

Il s'agit de prévoir différentes variantes d'exécution pour une même activité de
manière à être plus flexible pour la prise en compte de besoins de personnalisation
du produit ou du service exprimés par le client.

L'intégration dans un seul acteur

Il s'agit de faire exécuter par un même acteur l'ensemble des activités liées à
la gestion des différentes phases du cycle de vie d'une entité. Cela élimine en
effet les interfaces manuelles et les opérations de réconciliation qui sont des
causes fréquentes de non- performance sur des processus.

L'amélioration de la technologie
L'amélioration de la technologie permet de remplacer des matériels et/ou des
logiciels par d'autres plus performants, que ce soit en termes de rapidité de
traitement ou en termes de précision ou de taux d'erreur. C'est donc aussi une
source d'amélioration des processus.

Étude de cas : urbanisme et processus métier

Cette section présente les visions de l'architecture métier existante et de
l'architecture métier cible du projet d'urbanisation du système d'information du
tour-opérateur.

1. Introduction
Ce document présente :
la cartographie métier actuelle réalisée dans le cadre de la phase d'analyse
de l'existant de la démarche méthodologique ;
un diagnostic de la situation actuelle ;
la cartographie métier cible réalisée dans le cadre de la phase de définition de
la stratégie de la démarche méthodologique.

2. La cartographie métier de l'existant

L'analyse des processus existants a permis de mettre en évidence l'existence
de sept processus opérationnels, de trois processus de pilotage et de trois
processus de support. (Voir figure 6.3) Les processus classés dans la catégorie
processus opérationnels sont ceux qui contribuent directement à la marge de
l'entreprise alors que les autres (classés dans les catégories processus de
pilotage ou processus de support) n'y contribuent qu'indirectement :
processus opérationnels :
marketing ;
réservation ;
paiement ;
paiement échelonné ;
facturation ;
conception des
voyages ; gestion des
produits ;
processus de pilotage :
piloter vente ;
piloter risques ;
piloter trésorerie ;
processus de support :
administration ;
comptabilité, juridique ;
finance.

Fig. 6.3

Opportunité d'analyse des processus

Le tour-opérateur a été numéro un en France pendant vingt ans. Mais, depuis
deux ans, il se trouve relégué à la deuxième place et continue à perdre des parts
de marché. Le directeur général désire mettre en œuvre une nouvelle stratégie lui
permettant de redevenir leader sur son secteur.
La matrice permettant de faire le lien entre les objectifs stratégiques et les
processus métier suivants permet de mettre en lumière les processus sensibles
pour l'atteinte des objectifs mentionnés. Aussi, la modélisation des processus tant
pour l'existant que pour la cible a été limitée aux processus opérationnels
suivants, car ce sont les processus importants par rapport aux objectifs
stratégiques du tour-opérateur :
 marketing ;
réservation ;
paiement ;
paiement échelonné ;
facturation.

Tab. 6.1 f : faible, E : contribution Élevée

coressourc
coldécoula
Dim
eun
dD
transformati
taduixspdo
Aupgromd

devseennd
ada
chP
DiréReél
clie

connaissan
fine

n oeuv
es é v e

vveer
nltiesrerl
Oforicea
mAuagrk

Dà
cleibnlé

adlteemr
lteosuct
partenair
D
par
pcorom
ldgesti
dd
Fles

plaersten
dseaisie
ple
lre
pDpÉlius
Fa cat
conta
de

humain
en
minuer
daeg

eOpinti
erreu

fl

Amélior
ûet
p l a

ministrati
ar rm

mDmimui
piosstrit
Sdae

drou
Téraviet

mauv
easn
Objectifs stratégiques

du'ax
les

laesps
métier/Processus

Marketing E × × E × ×
Réservation f × × E × × × × × E × × E × × f ×
Paiement f × f ×
Paiement échelonné f × E × f ×
Facturation E ×
Conception des
voyages f × f × f ×

Gestion des produits f × f × f ×

Administration
Comptabilité, juridique
Finance
Piloter vente
Piloter risques
Piloter trésorerie

Parmi ces cinq processus, les processus marketing, réservation et paiement

échelonné sont les plus importants pour l'atteinte des objectifs stratégiques.
Il est très important dans ce genre d'étude de limiter le périmètre de manière,
d'une part à mener l'étude dans un délai et dans un budget raisonnables, d'autre
part à se focaliser sur l'analyse des processus susceptibles d'amener une vraie
création de valeur pour l'entreprise.

Cartographie des processus actuels

La cartographie des processus actuels a été établie de manière à avoir la vue
d'ensemble. Cependant, elle ne donne pas la vision des liens entre les processus.
Un modèle des liens entre les processus opérationnels a donc été réalisé en
complément.

Liens entre les processus actuels

Le schéma des liens entre les processus actuels est présenté figure 6.4.
 Fig. 6.4

Modèles des processus actuels

Les modèles de processus sont des modèles de processus organisés car, compte
tenu du problème à résoudre dans le cas du tour-opérateur, il était nécessaire de
descendre à ce niveau de détail. En particulier, l'un des problèmes évoqués étant
la charge administrative des vendeurs, il fallait bien représenter concrètement
les activités de l'acteur vendeur, donc faire apparaître les acteurs, donc aller
jusqu'au niveau de processus organisés. Ce n'est pas toujours le cas,
notamment lorsqu'il n'y a pas de modification à apporter aux processus. Toutefois,
même si formellement il s'agit de processus organisés plutôt que de processus, le
niveau de détail pour la description de l'organisation reste très macroscopique.
Dans la pratique, soit le projet d'urbanisation du système d'information
s'accompagne d'une amélioration des processus, et on est alors quasiment
systématiquement obligé de descendre au niveau des processus organisés,
soit ce n'est pas le cas et le niveau processus suffit souvent.
La réalisation de ces modèles a nécessité l'interview de deux à trois personnes
par processus.
Enfin, il faut noter que les modèles de processus sont ici des modèles de processus
soft comme bien souvent dans les projets d'urbanisation de système d'information
afin de privilégier la clarté de lecture, la rapidité de l'étude et de correspondre aux
objectifs du projet qui n'est ni un projet de reconfiguration de processus, ni un
projet de développement de système.

Processus marketing actuel

 Fig. 6.5

Processus de réservation actuel

Fig. 6.6

Processus de paiement actuel

 Fig. 6.7

Processus de paiement échelonné actuel

Fig. 6.8

Processus de facturation actuel

 Fig. 6.9

3. La cartographie métier cible

Cartographie des processus cibles
La cartographie des processus cibles a été établie de manière à avoir la vue
d'ensemble. On note l'apparition d'un nouveau processus pour les réservations
via Internet et/ou le centre d'appels et la disparition du processus de paiement
échelonné. Les paiements échelonnés ne sont pas supprimés, mais le
processus de paiement échelonné existant gérait en fait l'instruction des
demandes de paiements échelonnés, ce qui, dans la cible, est inclus dans les
activités automatisées du processus de réservation en agence.

Fig. 6.10

Dossier d'investissement
Le principal bénéfice attendu sera de permettre au tour-opérateur de redevenir
numéro un en France.
Autres avantages prévus :
augmentation de la marge bénéficiaire ;
meilleure image ;
comparaison avec la concurrence.
L'analyse financière et les KPI (Key Performance Indicators, indicateurs clés de performance)
Il est possible d'obtenir des profits substantiels en augmentant le ratio demande
de renseignement/demande de réservation, qui est de 68 %, pour atteindre a
minima 72 % et au maximum 88 %. Un taux de 80 % ferait augmenter le chiffre
d'affaires d'environ 12 %.
Il serait possible de réduire les coûts de manière significative en remplaçant une
grande partie des personnes travaillant au standard du service organisation par un
nouveau système. Ce qui permettrait également de diminuer les coûts de
communication. L'ordre de grandeur des profits potentiels est le suivant :

Tab. 6.2

Coûts enBénéfices en MEM€

Investissement

Développement du
nouveau système 6

Acquisition du matériel
et de logiciels 6

Formation des utilisateurs 1,5 /

Total 13,5 0

Tab. 6.3

Coûts en M€ Coûts actuels

Exploitation (coût/année) Bénéfices en M€
en M€

Maintenance du matériel et du
logiciel 0,1 –
0,45
5 0,30

Télécommunications 1,5 3,8 2,3

Salaires (standard
téléphonique) 0,3 4,9 4,6

Total 2,25 8,8 6,6

Le processus de paiement gère un flux monétaire très important et, de ce fait, une
facturation plus rapide pourrait avoir une incidence significative sur le cash flow.
C'est un point à étudier au cours de l'analyse détaillée. Le niveau de détail de la
modélisation de ce processus ne permet pas de comprendre les causes du
problème. Il faudrait donc approfondir l'analyse de ce processus pour comprendre
les modifications à apporter au processus de paiement, ce que nous laisserons de
côté ici.
Résumé de l'analyse financière (en M€) :

Tab. 6.4

2006 2007 2008 2009 2010 2011

Investissement 4,5 9,0 / / / /

Profits / / 13, 14, 14, 16

6 1 9

Retour sur
investissemen – 4,5 – 9,1 13,6 14,1 14,9 16
ts

NB : le seuil de rentabilité devrait donc être atteint fin 2003.

Analyse des résultats
Le principal intérêt du dossier d'investissement est de permettre l'augmentation
du ratio demande de réservation/réservation. C'est pourquoi l'équipe chargée
du projet étudiera cette question avec un soin tout particulier. Ainsi, des
simulations avec de vrais clients seront organisées dans le but de vérifier si les
futurs processus permettront effectivement d'augmenter ce ratio dans les
proportions prévues.
Risques
Il existe plusieurs risques majeurs sur le plan social :
au sein de l'agence, les vendeurs auront moins de travail administratif et
bénéficieront d'une formation appropriée ;
au standard du service organisation, les employés pourraient craindre des
licenciements. Toutefois, il existe un plan élaboré de reclassement dans
d'autres services dans lesquels la société a besoin de recruter et, bien sûr,
dans le centre de communication (pour la vente directe).
Sur un plan technique, il existe également des risques non négligeables.
Panorama de l'environnement externe
Le principal concurrent, actuellement leader sur le marché, s'appelle Club
2000. Depuis deux ans, ses agences fonctionnent avec un système de
réservations en temps réel.
Les informations connues sur Club 2000 sont les suivantes :

Tab. 6.5

2000 2001 2002 2003 2004 2005

Chiffre d'affaires (M€) 183 213 259 297 300 305

Nombre de réservations (en
milliers) 390 468 565 643 650 660

Bénéfices avant impôts (M€) 36 41 51, 60 60 59

La définition du champ du projet

Le champ du projet est le suivant :
analyser les cinq processus retenus ;
concevoir de nouveaux processus permettant d'atteindre les objectifs de la société.

Modèles de processus cibles

La cartographie des processus ne donnant pas plus pour la cible que pour
l'existant la vision des liens entre les processus, un modèle des liens entre les
processus retenus pour l'analyse a donc été réalisé en complément.

Liens entre processus cibles

 Fig. 6.11

Processus marketing cible

Fig. 6.12

Processus de réservation en agence cible

 Fig. 6.13

Processus de e-réservation cible

 Fig. 6.14

Processus paiement cible

 Fig. 6.15

Processus de facturation cible

Fig. 6.16

Tous les objets des modèles de processus cibles ont été préfixés par C
(comme cible) de manière à se repérer aisément entre modèles de
processus existants et modèles de
processus cibles. Les principaux écarts entre les processus existants et les
processus cibles sont les suivants :
processus marketing : ajout d'un message de demande de catalogue de la
part d'un internaute, qui doit donc laisser ses coordonnées pour recevoir le
catalogue demandé ; processus de réservation :
apparition de deux processus, l'un pour la réservation en agence,
l'autre pour la réservation via le Web ou le centre d'appels ;
l'activité de guidage du choix du client se fait en fonction des
disponibilités connues et accessibles en temps réel ;
les allers-retours avec la direction organisation (vérification des
disponibilités) ont été supprimés ;
les décisions concernant les demandes de paiements échelonnés sont
prises en temps réel (pour les réservations en agence) ;
on prend directement des réservations et non plus des
préréservations ; pour les réservations via Internet :
– le visiteur peut demander l'envoi d'un catalogue à son domicile ;
– le visiteur ne peut pas demander de paiement échelonné ;
– le visiteur règle l'acompte par carte bancaire (seul moyen de paiement
autorisé) ; processus de paiement : ce processus est très peu modifié. En fait,
seule la disparition du message solde payé anciennement adressé au
processus de réservation est à noter. Celui-ci n'est plus nécessaire puisqu'il
n'y a plus à basculer le statut de la réservation de pré-réservée à réservée ;
processus de paiement échelonné : ce processus disparaît puisque l'étude
et la décision concernant une demande de paiement échelonné sont
maintenant intégrées et automatisées dans le processus de réservation en
agence et que ce mode de paiement n'est pas autorisé pour les
réservations sur Internet ;
processus de facturation : ce processus est très peu modifié. En fait, seule la
disparition du message de préréservation en provenance du processus de
réservation est à noter.
Le lien entre ces écarts et les objectifs stratégiques est clair et ne mérite donc
pas d'être commenté.
Urbanisme et architecture
fonctionnelle

Ce chapitre décrit le « comment faire » pour les

activités liées à l' architecture fonctionnelle cible de la
démarche méthodologique d'urbanisation de système
d'information.

Le lien entre architecture fonctionnelle et

architecture métier
Il faut rappeler qu'une des activités fondamentales des
projets d'urbanisation consiste à représenter les
différentes visions du système d'information sous des
formes permettant de les exploiter (une base de
données ou un référentiel d'AGL par exemple). Pour
cela, un modèle générique des concepts a été
présenté au chapitre 3.
Au niveau de ce modèle générique, le lien entre
l'architecture métier et l' architecture fonctionnelle est
assuré par l'association entre les classes activité et
bloc.
Une activité est liée à un ou plusieurs processus
métier, qui eux-mêmes permettent d'atteindre un ou
plusieurs objectifs du système d'information, qui va
quant à lui correspondre à un ou plusieurs objectifs
stratégiques métier. Nous avons donc le moyen de
faire le lien entre une activité et les objectifs
stratégiques métier.
L' activité va être automatisée par 0 à N blocs
fonctionnels et un bloc fonctionnel automatise 1 à N
activités. On a donc, via l'activité, un lien entre le bloc
fonctionnel (zone fonctionnelle, quartier fonctionnel ou
îlot fonctionnel) et les
objectifs stratégiques métier qu'il contribue à faire
atteindre. Ce lien est très important pour élaborer
les dossiers d'investissements et pour l'instruction
des décisions d'arbitrage.

La transition de l'architecture métier vers

l'architecture fonctionnelle
Rappelons d'abord que l'architecture fonctionnelle
est la structuration du système d'information en blocs
fonctionnels communicants. Elle répond à la
question : Quoi ? sans tenir compte des acteurs et
de l'organisation.
Le passage de l' architecture métier à l'architecture
fonctionnelle est à la fois rigoureux et artistique en ce
sens qu'il y a un certain nombre d'étapes types et de
règles à respecter qui balisent le chemin de
l'urbaniste, mais sans toutefois constituer des
algorithmes aboutissant s'ils sont appliqués
correctement au seul et unique bon résultat.
Ces étapes sont décrites ici et les règles sont
présentées à la section 7.3.
La première étape de la démarche consiste à
appliquer les règles de bonnes pratiques qui
permettent de définir a priori les zones suivantes pour
l'architecture fonctionnelle cible :
zone échange ;
zone gisement de données ;
zones référentiel de données et de
règles ; zone pilotage ;
zone
opération ;
zone
ressource.
La deuxième étape consiste à exploiter les
processus métier. Les processus métier permettent
d'identifier les classes concepts (c'est-à-dire les
invariants métier).
La description des processus permet naturellement
d'identifier les concepts métier manipulés, et donc
les
classes permettant de décrire un concept métier
indépendant de l'organisation, c'est-à-dire les
classes de substance (voir glossaire). Il est à noter
que le fait d'avoir décrit des processus qui, par
définition, ne décrivent pas l'organisation
contrairement à des processus organisés ou
procédures qui, eux, sont l'instantiation des
processus dans une certaine organisation,
favorisent l'identification des classes de substance.
Il convient ensuite de distinguer parmi les classes
de substance celles qui sont essentielles (classes
concepts) des autres (classes secondaires).
Une classe concept décrit un concept métier majeur.
Une classe concept est donc une classe de substance
portant la notion essentielle du concept métier
correspondant. Une classe secondaire complète la
définition du concept métier auquel elle se rapporte.
Elle est en principe en relation directe (association,
agrégation) avec la classe concept correspondant. La
plupart du temps, une classe secondaire peut
consister en un sous-ensemble fonctionnel du concept
rattaché. Dans d'autres cas, elle peut correspondre à
un concept de moindre importance qui peut avoir une
signification différente d'un contexte à l'autre. Par
exemple, la notion d'« adresse » peut s'appliquer
aussi bien à un
« client » qu'à un « fournisseur ».
Chaque classe concept donne a priori lieu :
à un quartier dans la zone gisement de données
qui gère toutes les données relatives à l'unique
classe concept du quartier et aux classes
secondaires rattachées à cette classe concept ;
à un quartier dans la zone opération si la classe
concept est issue de l'analyse des processus
opérationnels, de la zone pilotage si la classe
concept est issue de l'analyse des processus de
pilotage et de la zone ressource si la classe
concept est issue de l'analyse des processus de
support.
La troisième étape consiste à compléter l'ébauche
d' architecture fonctionnelle en fonction des
objectifs stratégiques du SI.
La quatrième étape consiste à identifier les services
des différents blocs composant l'architecture
fonctionnelle. Pour cela, on se base sur :
la connaissance du système d'information
existant ; la connaissance de l'urbaniste ;
les modèles existants sur le marché (par
exemple TOM dans les télécoms ou IAA pour
l'assurance).
La cinquième étape poursuit l'exploitation des
processus métier. Il s'agit de partir des
événements de gestion, et d'exécuter les processus
permettant de traiter ces événements en vérifiant
pour chaque activité du processus à quels blocs
fonctionnels elle peut faire appel pour être menée à
bien et si les blocs fonctionnels en question
contiennent les services nécessaires.
La sixième étape est un rebouclage par rapport
aux objectifs stratégiques du SI. Il s'agit de
reprendre un à un chaque objectif d'évolution du
système d'information et de se demander en quoi l'
architecture fonctionnelle y répond et en quoi elle
apporte une amélioration significative par rapport à
l'existant.
La septième étape est un rebouclage sur les règles
d'urbanisme pour l'architecture fonctionnelle.
Normalement, celles-ci doivent avoir été respectées,
mais il convient de s'en assurer.
Pour les besoins de la présentation, ces sept étapes
sont présentées de manière séquentielle, mais la
conception d'une architecture fonctionnelle cible
répond à deux points :
elle suit une démarche itérative. Dans la pratique,
trois itérations sont généralement nécessaires, la
première étant la plus longue, la troisième la plus
courte. À l'issue des deux premières itérations, le
périmètre de l'itération
 suivante est redéfini et les décisions prises
sont documentées ;
l'ordre peut être adapté à chaque contexte.

Les règles d'urbanisme

1. Rappel des principes fondateurs
Avant d'appliquer les règles d'urbanisme, il convient
de s'assurer au préalable que les définitions de base
sont respectées. Celles-ci sont donc rappelées car ce
sont de véritables principes fondateurs pour
l'architecture fonctionnelle.
L'architecture fonctionnelle est composée de trois
types de blocs fonctionnels :
les zones fonctionnelles
; les quartiers
fonctionnels ; les îlots
fonctionnels.
La zone fonctionnelle correspond au premier niveau
de découpage du système d'information. La liste des
zones d'un SI est donnée par les règles de bonnes
pratiques.
Le quartier fonctionnel est un regroupement
d'îlots. Il regroupe des composants homogènes
quant à la nature de l'information traitée.
Un quartier va typiquement correspondre à ce que
l'on appelle communément un sous-système.
Un îlot fonctionnel est une entité remplaçable du
système informatique susceptible d'être développée
ou achetée séparément. Un îlot correspond à une
finalité fonctionnelle et comprend des traitements et
des accès à des données pour cette finalité. Les
services au sein de l'îlot sont effectués
indépendamment du chemin suivi par l'information
en amont ou en aval de l'îlot. Un îlot émet des
résultats normalisés exploitables par d'autres îlots.
Un îlot va typiquement correspondre :
une application ou une grande fonction applicative
(développement spécifique) ;
un progiciel ou au module d'un progiciel.
Chaque bloc (zone, quartier ou îlot) doit présenter une
cohérence fonctionnelle interne forte et un couplage le
plus faible possible avec les autres blocs.

2. Les règles d'urbanisme pour l'architecture

fonctionnelle
Il est à noter que les règles présentées ici sont
simplement rappelées, il n'y a en pas de nouvelles par
rapport à celle présentées au chapitre 3.

Règle n° 1 : Règle d'unicité des blocs.

Un îlot appartient à un et un seul quartier, un quartier
appartient à une et une seule zone, donc un îlot
appartient à une et une seule zone.
Au niveau de l' architecture fonctionnelle, un bloc ne
doit donc pas être dupliqué.

Règle n° 2 : Règle d'asynchronisme des îlots.

Après avoir traité un événement, un îlot peut en
traiter immédiatement un autre sans avoir à se
préoccuper de ce qu'il advient du compte rendu de
traitement de l'événement précédent.

Règle n° 3 : Un bloc comporte obligatoirement une prise (interface

Elle est capable d'activer les services du bloc et de gérer
les communications entrantes et sortantes du bloc.

Règle n° 4 : Toute communication entrante ou sortante d'un bloc

Ces prises présentent les avantages suivants :
passe par sa prise.
centraliser les appels de services et limiter le
nombre d'interfaces ;
ajouter un niveau d'encapsulation supplémentaire :
l'intra-muros d'un bloc est à considérer comme
une boîte noire par l'extérieur ; en développement
objet, une classe traduit déjà un premier niveau
d'encapsulation, le principe est à reconduire aux
niveaux supérieurs îlot, quartier et zone ;
mutualiser les services : un service public et
un seul pour répondre à des besoins identiques
formulés par des demandeurs différents
appartenant le cas échéant à des blocs, quartiers
ou zones distincts ; ceci traduit également le
principe de réutilisation ;
accroître la modularité ;
réduire au strict minimum les
impacts suite à une évolution d'un
îlot dont lesservices publics sont
sollicités par une diversité de demandeurs et
rendre plus aisée la détermination de la chaîne
d'impacts ; faciliter la mise en œuvre de
maintenances évolutives.

Règle n° 5 : Seules les prises communiquent avec le gestionnaire de

Les prises sont seules habilitées à communiquer avec le
gestionnaire de flux.
 Règle n° 6 : Une donnée est sous la responsabilité (quel que soit
le type d'accès : création, modification, suppression, visualisation)

Un des objectifs de l'urbanisme est la portabilité des

îlots en respectant les règles d'autonomie et
d'asynchronisme. Pour atteindre cet objectif, il est
nécessaire d'avoir des structures de données
alignées sur les îlots pour que l'ajout, le
remplacement ou la suppression d'un îlot puisse se
faire avec un minimum d'impacts sur le SI.

3. Les règles de bonnes pratiques pour

l'architecture fonctionnelle
Il est à noter que les règles présentées ici sont
simplement rappelées, il n'y en a pas de nouvelles par
rapport à celle présentées au chapitre 3.

Règle n° 1 : Toute architecture fonctionnelle comporte une zone

L'acquisition transforme des flux événement
échange (acquisition/restitution) qui est en quelque sorte la prise du
organisationnels externes en flux fonctionnels
enrichis de toute information nécessaire à leur
traitement en aval par la fonction prise en compte.
Elle garantit aussi la conformité du flux fonctionnel
enrichi aux engagements conclus avec le partenaire
émetteur et aux conditions d'exécution déterminées
par l'entreprise.
La restitution adapte les résultats issus de la fonction
constitution aux supports d'information et aux canaux
de communication, et personnalise l'émission de flux
en fonction du partenaire et du canal.

Règle n° 2 : Toute architecture fonctionnelle comporte une zone

gisement de données.
Cette zone reprend l'ensemble de toutes les
informations dynamiques et pérennes de
l'entreprise ainsi que les services d'accès à ces
données.
Elle assure la conservation et la valorisation du
patrimoine d'informations de l'entreprise, garantit sa
cohérence et permet son enrichissement dans le
temps.
Il faut noter qu'il ne s'agit que d'une règle de bonne
pratique, c'est-à-dire une recommandation. Les avis
sur l'option qui consiste à isoler de tels gisements de
données dans une zone dédiée et celle qui consiste
à les loger dans les quartiers d'autres zones (donc
non spécifiques) sont en effet partagés.
Il y a deux raisons principales qui poussent vers la
solution recommandée dans cet ouvrage : cela
facilite la progressivité de la migration des
applications clientes d'un gisement de données à
mettre en œuvre et surtout renforce l'évolutivité et
les possibilités de synergies entre systèmes
d'information dans un contexte multi-SI.

Règle n° 3 : Toute architecture fonctionnelle comporte une zone

Cette zone regroupe l'ensemble de toutes les
référentiel de données et de règles.
informations communes aux différents éléments du
SI dont le cycle de vie est relativement stable.
Un référentiel contient les données de référence
concernant les produits et services, les règles de
gestion administrative et comptable de la
compagnie, ses métiers, son organisation
indépendamment d'un client particulier ainsi que les
services d'accès à ces données.
La notion de référentiel de règles étant moins
courante que celle de référentiel de données, il
convient de la préciser. L'intérêt d'un référentiel de
règles est d'extraire des règles
métier du code des applications et de les stocker dans
un référentiel.
C'est particulièrement utile pour les règles qui
nécessitent à la fois un fort besoin de partage entre
applications, de qualité et de cohérence.
Les règles stockées dans un référentiel de règles
peuvent être modifiées sans changer le code des
différentes applications qui doivent les utiliser, voire
même sans arrêter ces applications.
Il ne s'agit pas d'isoler systématiquement toutes les
règles métier dans un référentiel de règles mais
c'est particulièrement pertinent lorsque :
ces règles sont très importantes pour l'entreprise
(fort besoin de qualité) ;
ces règles doivent être appliquées à l'identique par
différentes applications (fort besoin de partage et
de cohérence) ;
ces règles sont susceptibles d'être modifiées
fréquemment et l'entreprise a besoin d'agilité.
Exemples de règles métier :
L'acompte à la réservation doit être > 10 % du prix
total du voyage ou encore le solde du voyage doit
être payé un mois avant le départ.
Si le tour-opérateur stocke ces règles dans un
référentiel de règles, il peut alors décider
soudainement que l'acompte à la réservation doit
être > 20 % du prix total du voyage et que le solde
doit être payé deux semaines avant le départ et
cela sans changer aucune ligne de code.
Cet exemple illustre bien l'agilité que confère à
l'entreprise un référentiel de règles.

Règle n° 4 : Toute architecture fonctionnelle comporte une zone

pilotage unique.
Cette zone regroupe les blocs dédiés aux processus de
gouvernance et d'analyse et utilisant des informations
globalisées et historisées.

Règle n° 5 : Toute architecture fonctionnelle comporte une zone

Toute architecture fonctionnelle comporte une zone
(ou un SI) opération par métier principal de l'entreprise.
opération par métier principal de l'entreprise ou de
l'organisme. Le système d'information d'une
entreprise ou d'un organisme n'ayant qu'un seul
métier ne comporte donc qu'une seule zone
opération. Par contre, si l'entreprise ou l'organisme
a plusieurs métiers, le système d'information doit
comporter une zone opération pour chacun. Par
exemple, le système d'information d'une compagnie
exerçant dans le domaine de l'assurance IARD
(incendie, accident, risque divers), de l'assurance-
vie et de la banque comportera une zone opération
IARD, une zone opération Vie et une zone opération
Banque.
Pour une entreprise ayant plusieurs métiers il y a
en fait deux alternatives :
soit un SI par métier ;
soit un seul SI avec une zone opération par métier.
Le choix entre ces deux alternatives relève de la
Direction
Générale.

Règle n° 6 : Toute architecture fonctionnelle comporte une zone

Cette zone regroupe les systèmes dédiés à la
(ou un SI) ressource unique.
gestion des ressources internes à l'entreprise
(ressources humaines, comptabilité, etc.).
 Étude de cas : urbanisme et architecture
fonctionnelle
Cette section présente la vision de l'architecture
fonctionnelle cible du projet d'urbanisation du système
d'information du tour-opérateur réalisée dans le cadre
de la phase de définition de la stratégie de la
démarche méthodologique.
Concernant l'architecture fonctionnelle, celle-ci n'est
réalisée que pour la cible. En effet, il serait de peu de
valeur ajoutée de reconstituer artificiellement une
architecture fonctionnelle existante qui, de plus,
laisserait une large part à l'interprétation, donc à la
subjectivité. Pour l'existant, on commence donc les
cartographies du système informatique avec
l'architecture applicative.
La première étape de la démarche a consisté à
appliquer les règles de bonnes pratiques qui ont
permis de définir a priori les zones suivantes pour l'
architecture fonctionnelle cible du système
d'information du tour-opérateur, comme illustré par le
schéma suivant :
zone échange ;
zone gisement de données ;
zones référentiel de données et de
règles ; zone pilotage ;
zone
opération ;
zone
ressource.
À l'issue de cette étape, l'architecture fonctionnelle
cible se présente comme sur la figure 7.1.
 Fig. 7.1

La deuxième étape a consisté à exploiter les

processus métier. Les processus métier permettent
d'identifier les classes de substance.
Chacun des processus a été passé en revue. Les
modèles de processus (c'est-à-dire les diagrammes
et les commentaires associés) permettent
d'identifier des classes de substance. Une classe de
substance est définie comme une classe permettant
de décrire un concept métier pour l'entreprise
indépendant de l'organisation, par opposition à un
concept métier limité à la vision d'un utilisateur.
Certaines apparaissent explicitement à l'analyse du
diagramme comme la réservation (par exemple en
visualisant le processus de réservation en agence),
d'autres nécessitent la lecture, voire l'interprétation,
des descriptions textuelles associées aux diagrammes.
Par exemple, la notion de tarif n'apparaît pas
explicitement sur les diagrammes de processus au
niveau de détail où ils sont réalisés. Par contre, elle
apparaît assez naturellement dès
qu'on cherche à expliciter en français ce qui se passe
derrière l'activité « guider le choix du processus
de réservation ».
L'analyse des modèles de processus a permis
d'identifier en première approche les classes
concepts suivantes :
processus marketing
: catalogue ;
tarif ;
client ;
agence
;
processus de réservation en
agence : réservation ;
acompte ;
paiement échelonné ;
paiement ;
tarif ;
lieu ;
hébergement et type
d'hébergement ; client ;
moyen de paiement ;
agent (vendeur) ;
processus d'e-réservation
: réservation ;
acompte ;
paiement ;
tarif ;
lieu ;
hébergement et type
d'hébergement ; client ;
processus de paiement :
échéance ;
paiement ;
paiement échelonné ;
facture ;
 processus de facturation :
réservation ;
échéance ;
facture.
Ensuite, il faut distinguer parmi ces classes de substance
les
classes concepts et les classes secondaires.
La plupart du temps, la distinction entre ces deux
types de classes est aisée, mais elle relève parfois du
choix de conception.
À ce stade, il faut aussi identifier les classes
concepts qui pourraient nous échapper car elles ne
sont pas concernées par les processus que nous
avons modélisés (nous n'avons pas modélisé tous
les processus). Les processus non modélisés pour la
cible sont des processus qui changent peu ou pas,
on peut donc se contenter de la modélisation de
l'existant si elle existe ou on peut découvrir les
classes concepts en analysant le modèle de
données de l'existant qui existe toujours sous une
forme ou sous une autre. Pour le tour-opérateur,
aucun modèle de processus n'étant disponible,
nous avons raisonné à partir du modèle de
données existant (à peu près à jour) et nous avons
travaillé avec les experts du système. Il s'agissait en
fait d'identifier les objets essentiels dans le modèle
conceptuel des données existant. Cela nous a
conduit à ajouter à la liste des classes concepts :
la structure de la
compagnie ; la
nomenclature comptable.
Dans le cas du tour-opérateur, nous sommes donc
parvenus à la liste suivante :
classes concepts :
personne ;
réservation ;
paiement ;
 paiement échelonné ;
facture ;
échéance ;
voyage ;
tarif ;
calendrier
;
structure compagnie ;
nomenclature comptable ;
classes secondaires :
catalogue ;
agence ;
acompte ;
hébergement
;
type d'hébergement ;
lieu ;
moyen de paiement ;
vendeur ;
À l'issue de cette étape, l'architecture fonctionnelle
cible se présente comme sur la figure 7.2. Nous
remarquons les points suivants :
les classes concepts ont donné lieu soit à des
quartiers, soit à des îlots pour celles qui sont
venues peupler le quartier référentiel de données
de la zone référentiel ; paiement et paiement
échelonné ont été regroupés ;
les classes secondaires n'ont pas donné lieu à
des quartiers ou à des îlots. Il s'agit des classes :
catalogue, liée à la classe de substance voyage
; agence, liée à la classe de substance
structure compagnie ;
acompte, liée à la classe de substance
paiement ; hébergement, liée à la classe de
substance voyage ; type d'hébergement, liée
à la classe de substance voyage ;
 vendeur, liée à la classe de substance structure
compagnie ;
lieu, liée à la classe de substance voyage ;
moyen de paiement, liée à la classe de
substance paiement.

Fig. 7.2

La troisième étape a consisté à compléter

l'ébauche d'architecture fonctionnelle en fonction
des objectifs stratégiques du SI.
L'optimisation de la valeur des clients nous
conduit à ajouter (ou à confirmer l'intérêt de) les
quartiers suivants :
gestion de la qualité de
service ; traitement des
demandes ; traitement des
problèmes ; marketing
opérationnel ; personne ;
statistiques agences ;
statistiques voyages ;
 marketing stratégique ;
gestion des personnes.
À l'issue de cette étape, l'architecture fonctionnelle
cible se présente comme sur la figure 7.3.

Fig. 7.3

L'ouverture à la vente 24 h/24, et donc l'accès aux

référentiels produit (voyage) et client 24 h/24, nous
conduit à ajouter (ou à confirmer l'intérêt de) les
quartiers ou îlots suivants :
multimédia
; personne
; voyage ;
tarif ;
calendrier ;
gestion des réservations ;
gestion des personnes ;
réservation ;
traitements des demandes.
Bien entendu, l'existence de ces quartiers est une
condition nécessaire pour offrir une ouverture à la
vente 24 h/24, et donc l'accès aux référentiels produit
et client, mais non suffisante. Le besoin de 24 h/24
entraînera d'autres conséquences sur l'architecture
technique.
À l'issue de cette étape, l'architecture fonctionnelle
cible se présente comme sur la figure 7.4.

Fig. 7.4

Permettre la vente directe via Internet et le centre

d'appels nous conduit à ajouter (ou à confirmer
l'intérêt de) les quartiers ou îlots suivants :
multimédia ;
gestion de la qualité de
service ; traitement des
demandes ; traitement des
problèmes ; gestion des
réservations ; réservation ;
gestion des personnes ;
personne ;
 voyage ;
tarif ;
calendrier
.
À l'issue de cette étape, l'architecture fonctionnelle
cible se présente comme sur la figure 7.5.

Fig. 7.5

Accepter ou refuser en temps réel les demandes de

paiement échelonné nous conduit à ajouter (ou à
confirmer l'intérêt de) les quartiers suivants :
acceptation des paiements échelonnés ;
gestion de l'acceptation des paiements échelonnés.
À l'issue de cette étape, l'architecture fonctionnelle
cible se présente comme sur la figure 7.6.
 Fig. 7.6

La quatrième étape consiste à identifier les services

des différents blocs composant l'architecture
fonctionnelle. Pour cela, on se base sur :
la connaissance du système d'information
existant ; la connaissance de l'urbaniste ;
les modèles existants sur le marché : par
exemple TOM (Telecom Operations Map, du
TeleManagement Forum) dans les télécoms ou
IAA (Insurance Application Architecture d'IBM)
pour l'assurance.
La cinquième étape poursuit l'exploitation des
processus métier. Il s'agit de partir des événements de
gestion et d'exécuter les processus permettant de
traiter ces événements en vérifiant pour chaque
activité du processus à quel bloc fonctionnel elle peut
faire appel pour être menée à bien, et si les blocs
fonctionnels en question contiennent les services
nécessaires.
À l'issue de cette étape, l'architecture fonctionnelle
cible se présente, comme sur la figure 7.7.

Fig. 7.7

La sixième étape est un rebouclage par rapport aux

objectifs stratégiques du SI. Il s'agit de reprendre un à
un chaque objectif d'évolution du système
d'information et de se demander en quoi
l'architecture fonctionnelle y répond et en quoi elle
apporte une amélioration significative par rapport à
l'existant.
La septième étape est un rebouclage sur les règles
d'urbanisme pour l'architecture fonctionnelle.
Normalement, celles-ci doivent avoir été respectées,
mais il convient de s'en assurer.
Finalement, l'architecture fonctionnelle cible se
présente comme sur la figure 7.8.
Fig. 7.8
Urbanisme et architecture
applicative

Ce chapitre décrit le « comment faire » pour les

activités liées à l'architecture applicative existante et
à l'architecture applicative cible de la démarche
méthodologique d'urbanisation de système
d'information.

Le lien entre l'architecture applicative et

l'architecture fonctionnelle
Il faut rappeler qu'une des activités fondamentales des
projets d'urbanisation consiste à représenter les
différentes visions du système d'information sous des
formes permettant de les exploiter (une base de
données ou un référentiel d'AGL par exemple). Pour
cela, un modèle générique des concepts a été
présenté au chapitre 3.
Au niveau de ce modèle générique, le lien entre
l'architecture fonctionnelle et l'architecture applicative
est assuré par l'association entre la classe bloc
applicatif et la classe bloc (fonctionnel). Idéalement,
un bloc fonctionnel devrait correspondre à un bloc
applicatif. Cependant, dans la réalité, on n'a
qu'exceptionnellement ce genre de correspondance
bijective du fait de considérations d'implémentation,
de mise en place de progiciels dont le contour ne
correspond jamais aux blocs fonctionnels imaginés,
etc. Il faut donc gérer la correspondance entre blocs
fonctionnels et blocs applicatifs. Un bloc fonctionnel
peut donner lieu à 1 à N blocs applicatifs, un bloc
applicatif
peut contribuer à l'implémentation de 1 à N blocs
fonctionnels.
Au-delà, le lien avec le bloc fonctionnel permet la
traçabilité jusqu'aux objectifs stratégiques métier
comme exposé à la section 7.1.

La cartographie applicative existante

Cette activité consiste à représenter les structures
décrivant le système d'information sous une forme
exploitable pour des traitements ultérieurs
(notamment pour effectuer des études d'impact lors
de la conception des réaménagements du système
informatique). Cette tâche est très importante. En
effet, tout projet, de quelque nature qu'il soit, est
destiné à réaliser la satisfaction des besoins ou la
résolution de problèmes (actuels ou à venir). Il est
donc indispensable de savoir prendre en compte la
situation actuelle, d'en faire un diagnostic et un
pronostic.
Les objectifs de la cartographie applicative de
l'existant sont les suivants :
prendre connaissance de l' architecture
applicative actuelle ;
décrire l'architecture applicative actuelle ;
évaluer les performances du système d'information
et faire des propositions d'axes d'amélioration.
Dans la pratique, il faut s'appuyer sur la
connaissance de l'existant par des équipes d'études
et de développements de l'entreprise ou de
l'organisme.
La première étape consiste, pour l'équipe du projet
d'urbanisation du système d'information, à adapter la
fiche îlot (applicatif) présentée ci-après. En effet, il
faut, d'une part que les informations demandées
soient toutes utiles pour l'étude, d'autre part ne pas
demander des informations déjà disponibles par
ailleurs et, enfin, s'assurer que les
informations demandées ont une chance d'être
collectées compte tenu du contexte.
Plus les questions sont fermées et mieux c'est. Il
convient ainsi d'établir la liste des valeurs possibles
pour les rubriques suivantes :
entités organisationnelles concernées ;
acteurs existants ;
classes concepts existantes ;
processus métier existants ;
types de sites existants.
La deuxième étape consiste, pour l'équipe du
projet d'urbanisation du système d'information, à
présenter aux équipes d'études et de
développements les résultats recherchés. Cette
étape permet d'obtenir l'adhésion des équipes et
de s'assurer de la bonne compréhension de
chaque rubrique de la fiche îlot.
La troisième étape est l'étape au cours de laquelle
les équipes étude et développement sollicitées
remplissent les fiches en bénéficiant du coaching de
l'équipe du projet d'urbanisation du système
d'information. Typiquement, il faut demander assez
rapidement à revoir la liste des fiches îlots envisagés,
de manière à s'assurer que le niveau de granularité
d'un îlot a bien été compris, et les premières fiches, de
manière à s'assurer que les différentes rubriques sont
également bien comprises.
La quatrième étape consiste, pour l'équipe du projet
d'urbanisation du système d'information, à exploiter
les fiches. Au cours de cette étape, des allers-retours
avec les rédacteurs des fiches sont nécessaires, et les
informations sont saisies dans l'outil retenu pour la
cartographie.
Il est alors nécessaire d'avoir une approche top-down
par opposition à l'approche bottom-up suivie jusqu'à
présent. En effet, déterminer les quartiers et les îlots
par analyse des fiches îlots et en raisonnant par les
flux entre îlots est, d'une
part un travail de fourmi, d'autre part ne donne pas un
meilleur résultat que de déterminer a priori (en se
basant sur la connaissance des équipes étude et
développement) quelles sont les zones et les
quartiers principaux et d'essayer de placer les îlots
dans ces zones et dans ces quartiers applicatifs.
La cinquième étape consiste, pour l'équipe du projet
d'urbanisation du système d'information, à demander
la validation de la cartographie applicative de
l'existant ainsi réalisée. Les équipes étude et
développement ayant rempli les fiches donnent un
avis au comité de pilotage pour prononcer ou non
cette validation.
Finalement, cette cartographie applicative montre :
les différents applicatifs composant le système
informatique actuel. Sa granularité correspond à
l'identification des zones quartiers et îlots tels que
définies dans le glossaire ;
les flux entre ces applicatifs (sens, temps réel,
temps différé, automatisé, manuel, description
fonctionnelle du contenu de l'échange, classement
selon la typologie retenue).
Pour chaque îlot, on a la fiche descriptive suivante :

ÎLOT X
1re partie : description métier
1. Contribution aux processus métier
2. Entités organisationnelles concernées
3. Acteurs concernés y compris tiers (nombre, type) 2e partie : description fonctionne
4. Objectifs
5. Classification (Critique, Important, Utile)
6. Entrées
7. Sorties
 8. Fonctions
9. Classes concepts gérées
10. Interfaces
3e partie : description applicative et technique
11. Année de développement
12. Volumes traités (Max, Min, Moy)
13. Disponibilité
14. Fiabilité
15. Matériel(s)
16. Système(s) d'exploitation
17. SGBD ou système de gestion de fichiers
18. Middleware
19. Types de sites concernés
4e partie : premiers éléments de diagnostic
20. Degré d'urbanisation

La transition de l'architecture fonctionnelle

cible vers l'architecture applicative cible
Rappelons d'abord que l'architecture applicative
est la structuration du système d'information en
blocs applicatifs communicants.
Le passage de l'architecture fonctionnelle à
l'architecture applicative est à la fois rigoureux et
artistique en ce sens qu'il y a un certain nombre
d'étapes types et de règles à respecter qui balisent le
chemin de l'urbaniste, mais sans toutefois constituer
des algorithmes aboutissant s'ils sont appliqués
correctement au seul et unique bon résultat.
L'architecture applicative répond à la question :
Comment ? (Qui ? Quand ? Ou ?). Contrairement à
l'architecture fonctionnelle, elle tient compte des
acteurs et de l'organisation. De nouvelles notions
sont donc ajoutées, en particulier les notions de bus
logiciels, de front office, de middle office, de back
office, de copies, d'instances, de sites et d'artères de
communication apparaissent.
Le gestionnaire de flux (ou bus logiciel). Une fois
le découpage du système d'information réalisé, il
s'agit de permettre la communication entre les
différents blocs. Dans un milieu urbain, ceci se
traduit par la mise en place des axes de
communication, la voirie, les réseaux d'égouts…
Dans le système d'information, c'est le rôle du
gestionnaire de flux qui assure ces échanges au
moyen de composants spécialisés (messageries inter-
applicatives, bus logiciels, etc.) sur la base d'un
format standardisé, de façon transparente pour les
applications. À ce stade, on parle du gestionnaire de
flux car d'un point de vue logique, il est unique, mais
cela ne préjuge en rien de l'implémentation physique
pour laquelle différents bus logiciels peuvent être
installés et éventuellement à partir de produits
différents.
Il permet aux applications de communiquer sans se
préoccuper :
de la localisation physique des applications
émettrices ou destinataire(s) ;
des moyens physiques et protocoles utilisés
pour communiquer ;
de la forme attendue par le destinataire.
Le système de gestion de flux assure quatre
grandes fonctions :
l'acheminement des messages (flux) de
l'émetteur vers le destinataire ;
le stockage des messages avec gestion
d'échéancier et de seuil ;
l'activation des applications à échéance (date,
heure, seuil) ou au fil de l'eau ;
la transformation des messages : enrichissement
et mise en forme.
La prise est le moyen mis à la disposition du
monde extérieur par un bloc, pour proposer ses
services. Une prise
comporte des structures de données et un ou des
noms d'opérations que l'on peut utiliser dans ce
bloc.
Les blocs fonctionnels sont ensuite implémentés par
des blocs applicatifs qui communiquent par le biais de
messages échangés via le logiciel gestionnaire de flux
(ou plusieurs d'un point de vue physique mais un seul
d'un point de vue logique).
Le message est le mode de propagation entre blocs
applicatifs d'un flux de données résultant d'un
événement de gestion. Il représente donc un flux
circulant à l'intérieur de l'entreprise ou échangé entre
l'entreprise et son environnement. Il peut être
transmis de manière synchrone ou asynchrone.
Le front office est l'ensemble des services orientés
client activables directement par l'acteur externe en
contact avec le client ou par le client lui-même.
Le back office est l'ensemble des services orientés
produit non activables directement par l'acteur
externe en contact avec le client ou par le client lui-
même.
Le middle office est l'ensemble de services non
activables directement par l'acteur externe en contact
avec le client ou par le client lui-même permettant :
une interaction directe avec le client ;
la correspondance entre les vues client (front
office) et produit (back office).
Les étapes de passage de l'architecture fonctionnelle à
l'architecture applicative sont les suivantes :
La première étape de la démarche consiste à
préciser les fonctions attendues du gestionnaire de
flux.
La deuxième étape consiste à réaliser le mapping
entre l'architecture fonctionnelle et l'architecture
applicative. Pour cela, il faut partir de l'architecture
applicative existante.
Pour les blocs fonctionnels relativement inchangés par
rapport à l'existant a priori, les applicatifs existants
sont réutilisés avec ou sans opération de maintenance
à réaliser.
Pour les blocs fonctionnels nouveaux ou présentant
des évolutions significatives par rapport à l'existant, il
est plus rare de réutiliser des applicatifs existants avec
peu de modification. Il faut donc envisager
l'implémentation des blocs fonctionnels cibles comme
un mixte entre maintenance lourde sur des
applicatifs existants, mise en place de progiciels ou
nouveaux développements spécifiques. Plus on
s'oriente vers de nouveaux développements
spécifiques, plus il est possible d'avoir une
correspondance simple (voire de type un pour un)
entre blocs fonctionnels et blocs applicatifs.
Il est à noter que pour les blocs des zones gisement
de données et référentiel, la correspondance entre
blocs applicatifs et blocs fonctionnels est
généralement de type un pour un.
La troisième étape consiste pour chacun des blocs
applicatifs à décrire sa prise et ses fonctions.
La quatrième étape consiste à projeter cette
architecture applicative en cours d'élaboration dans
l'organisation. On détermine alors quels sont les
acteurs ainsi que les différents types de sites, et on
en déduit les blocs applicatifs devant être instanciés
de manière multiple.
La cinquième étape consiste à donner une vue
dynamique de cette architecture applicative et à
identifier les grandes artères de communication.

Les règles d'urbanisme

1. Les règles d'urbanisme pour l'architecture
applicative
 Règle no 1 : Les données des gisements de données doivent être

Les données partagées doivent être historisées afin

de permettre de « rejouer » si nécessaire un
processus et de garantir la cohérence du contenu et
la bonne fin.

Règle no 2:Lesdonnéesdesgisementsdedonnéesdoiventêtre
accompagnées d'une date de publication de mise à jour.

Les données des gisements de données doivent être

accompagnées d'une date de publication de mise à
jour de sorte que les anciennes valeurs ne soient
pas perdues et que l'on puisse retrouver leur valeur
à un instant passé. Les très anciennes valeurs
peuvent être déportées dans des modules de
gestion de données archivées.

Règle no 3 : Les données des référentiels de données doivent être

accompagnées d'une date de publication de mise à jour (comme les données des

Afin de permettre le versionnement temporel, les

données des référentiels de gisements de
données doivent être accompagnées :
d'une date de publication de mise à jour de sorte
que les anciennes valeurs ne soient pas perdues
et que l'on puisse retrouver leur valeur à un
instant passé. Les très anciennes valeurs
peuvent être déportées dans des modules de
gestion de données archivées ;
d'une date d'effet.

Règle no 4 : Duplication des données.

Au sein d'un bloc, les données peuvent être
dupliquées entre les données de contexte et les
données des gisements de données car cela
correspond à deux niveaux de partage et de cycle
de vie bien différents. En effet, les données sont
isolées et temporaires pour le contexte alors
qu'elles sont partagées et permanentes pour les
gisements de données. Le niveau gisement de
données doit rester maître. La synchronisation au
sein d'un bloc se fait par publication du contexte en
respectant la règle d'intégrité des gisements de
données (règle d'urbanisme pour l'architecture
technique).

o 5 : Lequi
blocoffre
offrant unservice
service est
C'est
Règle le
n bloc un quiledoit
responsable de laqu'il
s'assurer
qualitéladu meilleure
offre service. qualité de service, y compris la
continuité de service.

2. Les règles de bonnes pratiques pour

l'architecture applicative

Règle no 1:Toutearchitectureapplicativecomporteunezone
ordonnancement qui assure l'interface entre front office, back office et middle offi

Plus précisément, cette zone assure :

la traduction, l'ordonnancement et le pilotage
des demandes du FO. Une demande de service
émanant du FO est traduite en un ensemble de
services appelés dans un certain ordre au niveau
des MO et BO ;
le pilotage des processus internes au
SI ; la gestion des priorités.
 Étude de cas : urbanisme et architecture
applicative
1. Introduction
Cette section présente la vision de l'architecture
applicative existante et de l'architecture applicative
cible du projet d'urbanisation du système
d'information du tour-opérateur, réalisées
respectivement dans le cadre de la phase d'analyse
de l'existant et de l'activité de plan d'occupation
des sols de la phase de définition de la stratégie de la
démarche méthodologique.

2. Étude de cas : architecture applicative

existante
Lors de la première étape de la démarche,
l'équipe du projet d'urbanisation du système
d'information a adapté la fiche îlot standard. Un
exemple de fiche îlot dûment complétée est fourni
ci-après pour l'îlot application réservation.

Fiche de description de l'îlot Réservation

Rédacteur
Rédacteur : Christian
Dufour Date de rédaction :
05/01/2006

1re partie : description métier

 Tab. 8.1 Contribution aux processus métier

Contribution du bloc au processus

Processus

Réservation ×
Paiement
Paiement
échelonné
Facturation
Conception
des voyages
Marketing
Gestion des
produits
Administration
Comptabilité
et juridique

Financier

Tab. 8.2 Entités organisationnelles utilisatrices

UO utilisatrices du bloc
Unités organisationnelles

Direction générale
Direction
marketing
Direction financière
Direction
commerciale
Direction organisation
× Direction exploitation
Direction des
ressources humaines
Agence principale
 Agence

ACTEURS CONCERNÉS Y COMPRIS TIERS (NOMBRE, TYPE)

Les quatre-vingts gestionnaires du service organisation.

2e partie : description fonctionnelle

OBJECTIFS
Gérer les préréservations et réservations de
voyages et de moyens de transport.
CLASSIFICATION (CRITIQUE, IMPORTANT, UTILE)
Critique : c'est le cœur du système. S'il ne
fonctionne pas, l'entreprise ne peut fonctionner. Un
arrêt même temporaire a des conséquences
financières.
ENTRÉES
Dossier de réservation :
identification du payeur ;
identification des
voyageurs ; destination ;
durée du séjour ;
mode de
transport ;
villle de départ et de
retour ; mode de
paiement.
Notification de paiement de solde.
Notification de non-paiement de solde.
SORTIES
Confirmation de préréservation.
Confirmation de réservation.
Avis d'annulation de préréservation.
FONCTIONS
Contrôle de
disponibilité. Contrôle
de la liste noire.
Enregistrement d'une préréservation de séjour.
Enregistrement d'une préréservation de transport.
 Basculement du statut d'une préréservation en
réservé ou annulée en fonction du paiement ou
non du solde à payer.

CLASSES CONCEPTS GÉRÉES

Tab. 8.3 Classes concepts gérées

Création Modification Suppression Visualisation

Personne × × × ×
Voyage ×
Transport ×
Prix ×
Lieu ×
Paiement
Paiemen
t
échelonn
é
Facture
Catalogue ×
Réservation × × × ×

INTERFACES

Tab. 8.4 Interfaces

De bloc Vers bloc Éléments échangés

Nom Type de flux

Pilotage Métier
Néant

3e partie : description applicative et technique

ANNÉE DE DÉVELOPPEMENT
1989
VOLUMES TRAITÉS (MAX, MIN, MOY)
L'activité connaît des variations saisonnières
importantes, ce qui explique la différence très
importante entre les volumes Minimum et Maximum.

Tab. 8.5 Volumes traités (Max, Min, Moy)

Nb/jours MIN MOY MAX

Nb de préréservations 500 2 8
000 000
Nb de réservations 450 1 7
800 200
Nb d'annulations 50 200 800
de
préréservations

DISPONIBILITÉ
De 8 h 00 à 22 h 00, heure française, 7 jours sur 7.
FIABILITÉ
Très bonne.
MATÉRIEL(S)
Moyen système HP 3000.
SYSTÈME(S) D'EXPLOITATION
Unix système V.
SGBD OU SYSTÈME DE GESTION DE FICHIERS
Oracle V8.
MIDDLEWARE
Sans objet.
TYPES DE SITES CONCERNÉS
Siège.

4e partie : premiers éléments de diagnostic

DEGRÉ D'URBANISATION
Aucune interface.
Applicatif monolithique.
PRINCIPAUX POINTS FORTS
Fiabilité de l'application.
Application bien
sécurisée.
PRINCIPAUX PROBLÈMES
Disponibilité insuffisante, notamment pour les
agences situées à l'étranger et dans la perspective
de l'ouverture d'un portail de vente directe (sur le
Web et via le centre d'appels).
Usage limité aux gestionnaires de la direction
organisation.
NOUVEAUX BESOINS
Fournir un accès aux vendeurs en agences.
Augmenter de manière drastique la disponibilité de
manière à tendre vers le 24/24 pour les agences et
pour la vente directe sur le Net.
Accepter ou refuser en temps réel les paiements
échelonnés.
La deuxième étape a consisté, pour l'équipe du
projet d'urbanisation du système d'information, à
présenter aux équipes d'études et de
développement les résultats recherchés. Cette
étape a permis d'obtenir l'adhésion des équipes et
de s'assurer de la bonne compréhension de
chaque rubrique de la fiche îlot.
La troisième étape a été l'étape au cours de laquelle
les équipes d'études et de développement sollicitées
ont rempli les fiches en bénéficiant du coaching de
l'équipe du projet d'urbanisation du système
d'information.
La quatrième étape a consisté pour l'équipe du
projet d'urbanisation du système d'information à
exploiter les fiches. Au cours de cette étape, des
allers-retours avec les rédacteurs des fiches ont été
nécessaires.
L'architecture des applications existantes a bien
évidemment été construite non selon les règles
d'urbanisation explicites proposées aujourd'hui
dans le cadre de l'étude, mais selon une logique
implicite de rationalisation qui a, par ailleurs, pu
évoluer au cours du temps.
Pour reconstituer le modèle de l'existant sous forme
d'un schéma d'urbanisme, les fiches îlots collectées
ont été regroupées selon les principes qu'on peut
qualifier de règles d'urbanisme implicites :
les fiches îlots ont été collectées par des groupes
de travail des équipes du tour-opérateur, puis
classées dans des sous-répertoires correspondant
à ces groupes ; même si cette découpe est très
proche d'une organisation du travail, c'est un
premier axe de recherche des quartiers et des
zones ;
un sous-répertoire comportant un nombre limité
d'îlots (par exemple une douzaine d'îlots) peut a
priori être assimilé à un quartier ;
un sous-répertoire comportant trop d'îlots est a
priori
une zone qui doit être découpée en quartiers ;
la découpe en quartiers d'une telle zone se fait en
regroupant des îlots qui remplissent des
fonctions similaires (impression de listes) ou
coopérative (cohérence fonctionnelle forte).
Ces règles ont permis d'avoir une première ébauche
de la découpe en zones et en quartiers. Pour en arriver
à une cartographie plus fine, on a tenu compte de
critères tels que isolations de quartiers pour des
raisons de facilité de maintenance, périmètres de
plans de réurbanisation en cours ou prévus à court
terme.
Finalement, la cartographie applicative élaborée est
représentée par le schéma de la figure 8.1. Les flux
entre applicatifs ont été quant à eux représentés au
moyen d'une matrice à l'aide d'un tableur, car ils
auraient rendu illisible le schéma de la figure 8.1.
 Fig. 8.1

Le système informatique du tour-opérateur a donc été

découpé en quatre zones applicatives majeures :
la zone SI-
Organisation ; la zone
SI-Financier ;
la zone SI-Statistiques
; la zone SI-
Administration.
Ces zones possèdent une cohérence fonctionnelle
interne forte et un couplage minimal.
Le système ne comporte qu'un seul site informatique
centralisé et situé au siège.
La construction de cette architecture a fait
l'objet de plusieurs réunions avec les équipes du
tour-opérateur et a fait alors l'objet d'un consensus.
La cartographie de l'existant telle qu'elle est présentée
correspond ˆ :
des principes de construction qui sont les «
règles d'urbanisme implicites » que l'équipe
d'étude a restituées sur base de ses
observations ;
une analyse plus fine des préoccupations pour le
futur en termes :
de la nécessité et des priorités pour la
réurbanisation des systèmes existants ;
de facilitation de la maintenance de pavés qui
devront être conservés à moyen terme.
Par conséquent, il est important de remarquer que
cette reconstitution a posteriori d'une cartographie «
urbanisée » de l'existant est un exercice guidé par la
recherche de sa cohérence et est donc censée fournir
une interprétation ordonnée de la réalité.
Il est donc à la fois normal et sans grande surprise que
cet exercice donne une image assez positive de la
situation actuelle.
Cependant, il ne faut pas oublier que la construction
de la cible se fait selon des règles d'urbanisme d'autre
nature et nettement plus contraignantes que celles
qui ont conduit à la construction de la « ville actuelle
».
Il ne faut donc pas perdre de vue les deux axes
d'évolution :
maintenir l'existant à partir de la capitalisation
acquise sur la reconstitution de son urbanisation
en blocs hérités du passé ;
(re)construire certains blocs selon des principes
nouveaux et un timing tenant compte des objectifs
stratégiques.
Un bilan a ensuite été dressé, dont les principaux
éléments sont les suivants :
Il saute aux yeux que l'architecture actuelle
correspond en gros à une zone (un SI) par grande
direction et que ces SI communiquent peu entre
eux.
Les problèmes actuels peuvent relever de deux
catégories : ceux liés à la manière dont le système
a été urbanisé et ceux liés à des problèmes internes
aux îlots identifiés (en quelque sorte ceux des
immeubles construits dans la ville).
Vus sous l'angle de l'urbanisation, les principaux
problèmes de l'existant et leurs conséquences
possibles peuvent être résumés comme suit :
Inexistence d'un gestionnaire unique de
flux (d'un point de vue logique) : l'absence d'un
gestionnaire de flux est un héritage de la
conception des systèmes. Il est prouvé que cette
situation induit :
des problèmes de communication, au fur et à
mesure que les médias accédant à la zone
d'échange se multiplient (téléphone, fax, Web,
courrier, centre d'appels…) : les
communications deux à deux entre médias et
moteurs de production créent progressivement
un réseau d'échanges inextricable,
difficilement maîtrisable et
« bruyant » ;
d'où des problèmes de maîtrise et de
contrôle des données que l'on a tendance à
dupliquer à différents endroits du système
pour des raisons de performances,
d'accessibilité ou de disponibilité.
Communication entre blocs par des flux
de natures hétérogènes et des prises
multiples : ce maillage d'îlots communiquant
parfois deux à deux posera certainement des
problèmes pour la mise en œuvre d'une
réurbanisation progressive par morceaux. En
effet, il faudra être très soigneux lors de la
planification de réurbanisation de sous-ensembles
de blocs pour bien en identifier les
communications avec
 les blocs restants. Une solution serait peut-être
de concevoir progressivement des interfaces
multiflux ou spécialisées par type de flux pour
isoler les blocs en les faisant communiquer au
travers de ces interfaces, avant de migrer des
ensembles de blocs vers la cible.
Absence de responsabilité unique d'un î
lot sur une classe concept : c'est
probablement un des problèmes les plus
importants. À remarquer que l'on se place au
niveau macro et non encore au niveau d'un objet
du modèle conceptuel de données, ni des
programmes.
L'analyse des matrices îlots/données est
néanmoins un outil très utile pour une première
approche du périmètre d'impact d'une
modification.
Absence de zone référentiel de règles :
c'est bien entendu une contrainte importante qui
limite la flexibilité du système (acceptation en
temps réel des demandes de paiements
échelonnés).
Absence d'une zone gisement de données :
dans le cas de données traitées en back office,
l'impact majeur de cette option d'architecture est
l'impossibilité de mise à disposition de ces
données en 24/7, sinon par duplication dans les
front et middle offices.
Cette duplication présente par ailleurs le risque
d'une discordance entre données maîtres et
données répliquées.
La cinquième étape a consisté alors pour l'équipe
du projet d'urbanisation du système d'information à
obtenir la validation de la cartographie de l'existant
ainsi réalisée. Celle-ci n'a pas posé de problème
puisque toute la cartographie s'est faite avec les
experts du système d'information existant, et la
validation s'est faite au fur et à mesure.
 3. Étude de cas : architecture applicative
cible
La première étape de la démarche a permis de
définir les fonctions attendues du gestionnaire de flux.
La communication entre les éléments fondamentaux
du SI doit être assurée indépendamment de la
localisation et des spécificités de ces différents
éléments.
La gestion des flux va regrouper l'ensemble des
traitements assurant la « liaison » entre tous les
composants du système urbanisé. En effet, dans un
système correctement urbanisé, chaque bloc possède
deux points d'ancrage normalisés (un point d'ancrage
pour les événements à traiter, un point d'ancrage
pour les comptes rendus). Pour assurer la cohésion
des échanges entre tous les blocs, il faut donc mettre
en œuvre un système de gestion des flux. Les blocs
n'étant plus connectés directement entre eux, il est
aisé de remplacer un bloc par un autre.
En agissant donc comme un « joint de dilatation »,
la gestion des flux permet au système de subir de
nombreux changements tout en assurant la
cohérence de l'ensemble.
La gestion des flux va donc assurer l'universalité de la
communication entre les différents blocs du SI. Ses
différentes fonctionnalités sont décrites dans le
tableau 8.6.

Tab. 8.6

Routeur Gestion de file d'attente

Administration des échanges
Fonctions/Blocs Interpréteur

Prendre en
compte le
message

Identifier l'émetteur ×
Contrôler l'habilitation ×
 Contrôler les doublons ×

Conditionnement
du message

Analyser le message ×

Enrichir l'information ×

Transformer les formats ×

Regrouper/Éclater ×

Transporter

Sécurité, intégrité,
×
historisation et traçabilité

Gestion des files d'attente ×

Recherche du destinataire ×

Transport ×

Activer

Gérer les seuils ×

Gérer le temps ×

Ordonnancer les traitements ×

Cette zone est typiquement implémentée à partir des

middleware du marché (par exemple EAI, moniteurs
transactionnels, etc.).
Rappelons que ces outils permettent de faciliter la
communication cohérente dans un environnement
distribué mais ne prennent pas en charge l'application
des règles de gestion. Ces dernières sont en effet du
ressort des différents applicatifs de la zone
ordonnancement.
À ce stade, l'architecture applicative cible est celle de
la figure 8.2.
 Fig. 8.2

La deuxième étape consiste à réaliser le mapping

entre l'architecture fonctionnelle et l'architecture
applicative. Pour cela, il faut partir de l'architecture
applicative existante.
Pour les blocs fonctionnels relativement inchangés par
rapport à l'existant a priori les applicatifs existants
sont réutilisés avec ou sans opération de maintenance
à réaliser.
Pour les blocs fonctionnels nouveaux ou présentant
des évolutions significatives par rapport à l'existant, il
est plus rare de réutiliser des applicatifs existants avec
peu de modifications. Il faut donc envisager
l'implémentation des blocs fonctionnels cibles comme
un mixte entre maintenance lourde sur des
applicatifs existants, mise en place de progiciels ou
nouveaux développements spécifiques. Plus on
s'oriente vers de nouveaux développements
spécifiques, plus il est possible d'avoir une
correspondance simple (voire de type un pour un)
entre blocs fonctionnels et blocs applicatifs.
 Fig. 8.3

Les résultats sont illustrés par le schéma de la figure

8.3. Ce schéma montre que :
des développements nouveaux ou de
reconstructions doivent être entrepris pour les
blocs suivants :
la zone de gestion de flux, entièrement
nouvelle et indispensable à l'implémentation
des principes d'urbanisme ;
la zone échange, nouvelle et nécessaire pour
prendre en compte les agences virtuelles
(Web et centre d'appels) ;
la zone ordonnancement, elle aussi nouvelle et
nécessaire pour assurer une bonne qualité de
service au client ;
le quartier marketing stratégique, qui doit être
créé pour exploiter au mieux le potentiel des
prospects et des clients ;
 la gestion des personnes et des réservations,
qui doivent être entièrement reconstruites
car elles doivent d'une part subir des
modifications fonctionnelles importantes,
d'autre part être désimbriquées ;
l'îlot acceptation des paiements échelonnés du
quartier gestion des paiements de la zone
opération, qui doit lui aussi être reconstruit car
l'importance des modifications fonctionnelles
rend une reconstruction moins chère qu'une
évolution. Son corollaire est la construction
d'un nouvel îlot acceptation des paiements
échelonnés du quartier référentiel de règles de
la zone référentiel ;
les blocs suivants peuvent être construits à
partir d'applicatifs existants à faire évoluer :
les quartiers gestion des voyages et gestion
des tarifs et les îlots gestion des paiements
comptants, gestion échéancier, gestion des
paiements échelonnés et facturation de la zone
opération ;
les quartiers paiement, facture et échéancier
de la zone gisement de données ;
les îlots voyage, tarif et calendrier du quartier
référentiel de données de la zone référentiel ;
toute la zone ressource, les quartiers statistiques
agences et statistiques voyage de la zone pilotage,
les gisements personnes et réservations et enfin
les référentiels structure compagnie et
nomenclature comptable doivent pouvoir être
réutilisés sans modification (ou avec de faibles
modifications).
La troisième étape consiste pour chacun des blocs
applicatifs à décrire sa prise et ses fonctions.
L'exemple du quartier traitement des demandes
illustre cette étape :
Objectifs : les services du quartier traitement des
demandes ont pour but de récolter les
informations
 nécessaires au traitement en aval des demandes
émanant d'acteurs externes. Ils assurent la
validation et l'enrichissement des éléments
recueillis par appel à d'autres services du SI. Ils
fournissent aux acteurs externes des statuts
signifiants sur l'état d'avancement du
traitement.
Fonctionnement : le quartier traitement des
demandes reprend pour chaque demande un
graphe décrivant les étapes à réaliser et les
transitions possibles entre ces étapes pour
acquérir les informations auprès des acteurs
externes. Si toutes les transitions ne sont pas
indiquées, cela signifie que l'on veut forcer
l'ordre dans lequel traiter la demande d'un
acteur externe. Sur chaque transition peuvent
être mentionnés les services (validations plus
particulièrement) à appeler pour assurer la
validité et l'exhaustivité des données. L'appel à
un service d'un autre bloc du SI donne lieu à
émission d'un flux fonctionnel (message) qui va
être pris en compte par un bloc du quartier
workflow. La demande une fois traitée donne
également lieu à l'établissement d'un flux
fonctionnel vers ce même quartier. L'objectif
des services du quartier traitement des
demandes consiste donc à garantir la conformité
du message final émis, s'il le faut par des appels
à d'autres services.
La quatrième étape consiste à projeter cette
architecture applicative en cours d'élaboration dans
l'organisation. On détermine alors quels sont les FO,
MO et BO ainsi que les différents types de sites et
on en déduit les blocs applicatifs devant être
instanciés de manière multiple.
On obtient donc l'architecture applicative cible de
la figure 8.4.
 Fig. 8.4

À ce stade, quatre types de sites ont été identifiés (le

siège, l'agence principale, l'agence et l'agence
virtuelle), mais l'architecture technique cible étant
centralisée, il n'y a pas lieu de décliner l'architecture
applicative par type de site.
Un extrait du dossier associé à cette cartographie
applicative cible illustre le travail réalisé dans ce
domaine chez le tour-opérateur.

Zone d'échange
La zone d'échange est celle par laquelle vont transiter
tous les flux qui émanent ou à destination d'acteurs
externes (clients, partenaires, autres compagnies,
etc.) au SI du tour- opérateur.
Elle regroupe l'ensemble des services destinés :
prendre en compte les flux en provenance
d'acteurs extérieurs au SI afin de les
transformer en flux
 fonctionnels valides (messages « métier ») par
rapport aux conditions de traitements ultérieurs ;
transmettre l'information vers les acteurs
externes du SI ; à cette fin, les applications de la
zone offrent des services gérant les différents
canaux de communication et l'intégrité du
transport ; elles ne traitent pas le contenu de
l'information. Elles adaptent et personnalisent les
résultats en fonction des différents médias et
acteurs qui en sont les destinataires.

Quartier multimédia
Le quartier multimédia regroupe l'ensemble des
services qui permettent de particulariser les flux
échangés avec les acteurs externes. Rappelons que
la gestion porte sur des flux bidirectionnels, tant
entrant dans le SI en provenance d'un acteur
externe que sortant du SI à destination d'un acteur
externe.

Présentation
L'îlot présentation permet de modifier le « layout » des
informations échangées en fonction du type d'acteur
et du média par lequel les informations sont
transférées.
S'y retrouvent par exemple des services
permettant d'adapter un flux au média utilisé
pour « converser » avec l'acteur, transformer le
flux d'information en un ensemble de page HTML,
imprimer le contenu d'un flux, etc.

Personnalisation
Cet îlot modifie le contenu des informations échangées
en fonction du type d'acteur et du média.
Par exemple, on retrouve des services permettant de :
réaliser les transcodifications des données : les flux
échangés dans un SI correctement urbanisé sont
normalisés (par exemple, « utilisation » d'un
référentiel
 standard du métier). Mais lorsque la compagnie
s'adresse à un acteur externe, elle ne peut pas
se baser sur l'hypothèse qu'il est capable de
gérer ces flux normalisés. Il faut donc prévoir une
transcodification des flux pour les rendre
compréhensibles par l'acteur externe concerné
(et inversement) ;
ajouter aux flux échangés toutes les informations
permettant de personnaliser l'échange. Par
exemple, ajouter les logos des destinataires, un
message marketing en fonction du destinataire.

Routage
Cet î lot reprend les services permettant
d'acheminer les informations à la bonne destination.
On y retrouve par exemple des services de :
tri des courriers pour identifier les actes de
gestion à exécuter ;
regroupement d'un ensemble de flux à
destination d'un seul acteur. Exemple :
regrouper des flux d'informations afin de les
imprimer et de les envoyer en un seul lot ;
éclatement d'un flux à destination de plusieurs
acteurs.

Zone ordonnancement
L'architecture cible est résolument orientée «
services ». Ces derniers sont offerts par différents
blocs du SI. Le traitement d'un flux fonctionnel émis
par la zone échange va donc provoquer
l'enchaînement de différents services.
Ces fonctionnalités de « pilotage » d'une demande
vont donc être couvertes par les blocs de cette zone.
Nous le verrons plus loin, ces fonctionnalités sont
essentiellement construites à l'aide d'un moteur de
workflow et de son référentiel. Les fonctionnalités
de cette zone ne sont pas à confondre avec celles
de la zone de gestion des flux. Cette dernière
assure principalement
les fonctions de mise en relation et de formatage des
messages échangés entre les blocs.

Quartier workflow
Traduction, ordonnancement et pilotage des
processus : Une demande de service possède
plusieurs origines :
la zone d'échange (par exemple les
messages
fonctionnels valides en provenance
d'applications interactives) ;
d'autres blocs du SI dans le cadre
d'exécution de processus internes (par
exemple les demandes formulées en interne
via des batchs).
Les différentes demandes doivent être traduites
en un ensemble d'appels à des services d'autres
blocs du SI (notion de pilotage).
L'ordonnancement de ces appels et la validation
de la cohérence de la transaction dans sa globalité
font partie des activités de ce quartier.
Gestion des priorités : la gestion des priorités
regroupe les services permettant
l'ordonnancement automatique du travail des
vendeurs.
On y retrouve la gestion des événements
commerciaux ou administratifs (par exemple
l'envoi ou la réception de documents, les relances
de pièces, etc.).
La cinquième étape consiste à donner une vue
dynamique de cette architecture applicative et à
identifier les grandes artères de communication.
Pour cela, à partir des processus, on identifie des
déroulements types de ces processus et, pour chacun
d'eux, on trace l'enchaînement de services de
l'architecture applicative qui permet de traiter
convenablement l'événement de gestion initiateur du
processus.
Rappelons qu'une des règles d'urbanisation veut
qu'un bloc comporte obligatoirement une prise
(interface externe).
Cette prise est capable d'activer les services d'un bloc
en fonction des informations contenues dans le flux
entrant et de gérer les communications entrantes et
sortantes de ce bloc.
L'activation des services est normalisée. Les
résultats des traitements effectués (ou comptes
rendus) sont également normalisés.
La structure des comptes rendus reprend :
l'identification du bloc émetteur (celui qui a
exécuté le service) ;
le service à exécuter ;
le contexte du service à exécuter (identification
du bloc demandeur du service, date et heure de la
demande) ; les identifiants des objets
concernés (par exemple réservation) ;
les informations nécessaires au
traitement ; les résultats du traitement.
Remarquons que, dans un SI correctement urbanisé,
la prise d'un bloc publie l'ensemble des services
qu'il offre aux autres blocs du SI. Tous les blocs
du SI peuvent donc accéder à l'ensemble des
services au travers du gestionnaire de flux
(unique d'un point de vue logique).
Modéliser l'ensemble des flux du SI reviendrait donc à
l'extrême à identifier des échanges entre tous les
blocs. Cette modélisation rendrait le schéma illisible
et n'aurait aucune valeur ajoutée (modélisation
théorique) puisque ce sont les processus exécutés qui
définissent les services utilisés et donc les échanges
existant pratiquement.
Il est donc préférable de présenter des flux, c'est-à-
dire la dynamique de l'architecture applicative sur la
base de quelques cas typiques (l'exhaustivité n'étant
ni possible ni
souhaitée), et ensuite d'en dériver les artères de
communication. Une artère de communication est un
regroupement de flux parcourant un trajet commun et
présentant des caractéristiques homogènes (sens du
flux, disponibilité, temps de réponse, volumétrie).
L'exemple suivant décrit la manière dont vont interagir
les blocs du SI dans un processus de réservation
d'un voyage en agence avec demande de paiement
échelonné.
Dans notre cas, l'événement déclencheur d'une
nouvelle réservation est une demande de
réservation en agence.
Cet événement est capté par le SI sous forme d'un
message entrant qui va être transféré à l'îlot
routage du quartier multimédia de la zone échange.
Cet îlot va à son tour émettre un flux vers le quartier
traitement des demandes de la zone échange.
Le quartier traitement des demandes va permettre le
pilotage interactif de la gestion de la demande.
Le message entrant de demande de réservation va y
déclencher l'activation du service demande de
réservation qui va piloter les étapes à réaliser par les
acteurs externes pour traiter la demande. Il faudra,
dans le cas d'une nouvelle réservation, indiquer,
entre autres, qui sont les voyageurs, choisir les dates
de départ et de retour, le lieu de départ, etc. Ce
service va donc piloter le dialogue avec l'acteur
externe.
À chaque étape correspondra la description logique
d'un écran à présenter à l'utilisateur pour saisir ou
visualiser ses données. Ils seront envoyés sous
forme d'écrans logiques au quartier multimédia.
Entre chaque étape, l'appel à des services du SI ou
à d'autres services peut être paramétré. (Voir figure
8.5)
 Fig. 8.5

Les flux de description des écrans logiques (flux de

pilotage) seront interceptés par l'îlot de
personnalisation. Leur contenu sera enrichi de
données de personnalisation en fonction de l'acteur
externe (par exemple avec le logo d'un partenaire).
L'îlot de personnalisation émettra alors un nouveau
flux vers l'îlot de présentation, qui se chargera de
transformer l'écran logique en écran physique en
fonction du média utilisé.
Au fil du déroulement du traitement de la demande, et
plus particulièrement lors des transitions entre les
étapes (enchaînement des écrans), ce quartier
émettra des flux vers d'autres blocs du SI.
Par exemple, il se peut qu'après avoir saisi les
voyageurs, on désire réaliser une validation avant de
passer à l'étape suivante. Un appel au service de
validation des personnes (ne sont-elles pas en liste
noire ?) devra donc avoir été paramétré à la transition
entre l'étape de saisie des intervenants (voyageurs et
payeurs) et celle qui la suit.
Le service de validation des paiements échelonnés
se trouve dans l'îlot acceptation des paiements
échelonnés.
Cet îlot interprète et utilise les règles à appliquer sur
les données qui lui ont été transmises par le quartier
workflow. Une fois les validations réalisées, l'îlot
émettra un compte rendu d'exécution à destination de
l'îlot de traitement des demandes via le bloc workflow.
(Voir figure 8.6)

Fig. 8.6

S'il avait fallu, lors de la saisie des données relatives à

la réservation, établir la liste des lieux de départ
possibles, le quartier traitement des demandes aurait
fait appel à un service de l'îlot voyage du quartier
référentiel de données qui lui aurait retourné les
informations demandées.
Rappelons que toutes les demandes de service entre
blocs s'effectuent au travers du gestionnaire de flux.
Une fois la partie interactive du traitement de la
demande achevée et l'ensemble des données
nécessaires à la
réalisation de la nouvelle réservation introduit, le
travail effectué dans la zone échange est terminé. Il
reste à sauvegarder les données dans les
gisements, et éventuellement à réaliser d'autres
actions ne nécessitant pas d'interaction avec un
acteur externe. Le pilotage de ces opérations est
réalisé dans le quartier workflow de la zone
ordonnancement par les paramètres de la
description du service de constitution d'une
nouvelle réservation. Ce service va être appelé au
départ du quartier traitement des demandes. (Voir
figure 8.7)

Fig. 8.7

Il se peut qu'il faille enchaîner plusieurs processus

métier comme valider la réservation dans son
ensemble, calculer la prochaine échéance, etc.
L'enchaînement des services à exécuter est aussi
paramétré.
Les appels seront réalisés de la même manière
qu'exposé précédemment :
pour valider la réservation dans son ensemble, il
faudra appeler le service de validation d'une
demande de paiement immédiat ;
 pour calculer la prochaine échéance, il sera fait
appel service de calcul de l'échéance de l'îlot
facturation du quartier gestion des paiements de
la zone opération ; etc.
Cette démarche répétée sur une vingtaine de cas
typiques a permis de mettre en évidence les
besoins en artères de communication du système
d'information cible.
Dans le cas du tour-opérateur, cela a permis
d'identifier cinq artères comme l'illustre le schéma de
la figure 8.8.

Fig. 8.8

Une artère données/référentiels pour l'accès aux

zones référentiels et gisements de données. Cette
artère doit offrir une circulation dans les deux sens et
offrir des caractéristiques de top niveau en termes de
disponibilité, de temps de réponse et de sécurité. Le
trafic sur cette artère est très important et quasiment
permanent, notamment pendant les heures
d'ouverture des agences.
Une artère FO/MO-BO pour le lien entre le front office
et le reste du SI (c'est-à-dire à la fois le middle office
et le back
office). Cette artère doit offrir une circulation dans les
deux sens et offrir des caractéristiques de top
niveau en termes de disponibilité et de temps de
réponse. Le trafic sur cette artère est très important et
quasiment permanent, notamment pendant les heures
d'ouverture des agences. C'est par cette artère que
transitent tous les flux externes au SI.
Une artère métier pour le lien entre la zone
ordonnancement et la zone opération et pour les
communications internes à chacune de ces deux
zones. Cette artère doit offrir une circulation dans les
deux sens et offrir des caractéristiques de top niveau
en termes de disponibilité, de temps de réponse. Le
trafic sur cette artère est très important et quasiment
permanent.
Une artère ressource pour le lien entre la zone
ressource et le reste du SI. Cette artère doit surtout
offrir une circulation dans le sens entrant dans la zone
ressource et offrir des caractéristiques de bas niveau
en termes de disponibilité et de temps de réponse.
Une artère pilotage pour le lien entre la zone pilotage
et le reste du SI. Cette artère doit surtout offrir une
circulation dans le sens entrant dans la zone pilotage
et offrir des caractéristiques de bas niveau en termes
de disponibilité et de temps de réponse.

Remarques sur le passage de l'architecture

applicative à l'architecture technique
L'identification des artères et des sens de
circulation doit être complétée par des éléments
volumétriques, car ce sont des éléments
fondamentaux pour définir les besoins en
infrastructures techniques supportant le système
d'information.
Le niveau architecture technique du cadre de
référence présenté au chapitre 3 concerne
l'infrastructure
technologique du système d'information qui
représente l'ensemble des installations de matériels
et de logiciels réalisées pour permettre aux
applications informatiques automatisant les
processus métier de s'exécuter dans des conditions
satisfaisantes pour l'usager.
Il comporte notamment :
les réseaux locaux ou longue distance ;
les plates-formes matérielles (postes de
travail, serveurs départementaux, serveurs
d'entreprises) ;
les logiciels de base (système d'exploitation, SGBD,
middleware, etc.).
On distingue :
les infrastructures technologiques primaires qui
ont un rôle pour l'ensemble du SI ;
les infrastructures technologiques secondaires qui
ont un rôle pour une zone ou quelques quartiers du
SI ;
les infrastructures technologiques tertiaires qui
ont un rôle pour un îlot, voire un groupe d'îlots, du
SI.
Dans le cadre d'un projet d'urbanisation du système
d'information, il convient de se concentrer sur les
infrastructures technologiques primaires et
éventuellement quelques points fondamentaux pour
l'entreprise ou l'organisme concernant les
infrastructures technologiques secondaires. Mais
globalement, les infrastructures technologiques
secondaires et tertiaires relèvent plus de l'architecture
technique (c'est-à-dire concernant un îlot ou à la
rigueur un quartier) que du niveau architecture
technique du cadre de référence d'urbanisme (c'est-à-
dire concernant l'ensemble du système d'information).
La dimension architecture technique du projet
d'urbanisation non couverte par notre étude de cas
doit permettre :
 de définir les grandes orientations concernant
l'infrastructure technique ;
de qualifier le dimensionnement des artères, des
plates- formes et des réseaux sur la base des
éléments volumétriques recueillis au niveau
applicatif ;
de définir les dispositifs de l'architecture technique
en fonction des niveaux de service à atteindre
(performance des applications, délais de remise en
état en cas de dysfonctionnement, niveau de
sécurisation à atteindre) ;
d'élaborer des recommandations d'outils
d'infrastructure technologique permettant de
converger vers une plus grande standardisation ;
de traiter les thèmes techniques suivants qui sont
détaillés dans la suite de ce paragraphe :
le choix d'un modèle d'architecture
technique logique en N couches ;
la communication interapplicative et inter-SI ;
l'organisation des données ;
la supervision ;
les
performances ;
la sécurité.

1. Le choix du modèle d'architecture

technique logique en N couches
La nécessité de structurer les applications pour
maîtriser leur développement ainsi que les échanges
entre applications amènent à concevoir les
applications en couches. Du point de vue de
l'urbanisme, cette approche permet de favoriser la
communication, d'une part à l'intérieur d'une
application, en structurant les règles de dialogue entre
les différentes couches, d'autre part entre les
applications en posant des principes de
communication liée aux couches de diverses
applications.
Elle apporte donc une contribution positive à
l'atteinte des objectifs de l'urbanisme.
Il existe de nombreux modèles à trois, quatre ou
encore cinq couches. Du point de vue de
l'urbanisme, nous ne proposerons pas un modèle
universel mais nous considérons que nous devons a
minima distinguer quatre couches :
la couche présentation-
dialogue ; la couche
application ;
la couche persistance
; la couche données.
La couche présentation-dialogue sert à gérer
la prise en compte des demandes issues des
différents canaux d'accès au système comme
l'Internet ou l'intranet, l'élaboration dynamique des
réponses ainsi que la séquence de dialogue
associée.
Cette couche permet de gérer la prise en compte
des requêtes HTTP standard. Pour cela, elle assure
la gestion de la session d'accès, l'appel d'une
opération de l'interface de la couche application
puis, en retour, l'élaboration dynamique d'une page
web de réponse.
Cette couche permet :
la prise en compte d'un flux de données
automatisé au moyen d'un EAI (Enterprise
Application Integration). Dans ce cas, elle assure
la transformation des formats de données, le
contrôle syntaxique du contenu, l'acheminement
du message et le déclenchement du traitement
applicatif adéquat ;
la prise en compte des services web qui permettent :
de cataloguer un service accessible par le Web
(Internet ou intranet), ce service
représentant un ensemble d'opérations
couplées avec un traitement applicatif ;
d'invoquer directement une opération de
l'interface de la couche application avec un
message XML (en
 utilisant la norme XML Soap) ;
de restituer la réponse applicative sous
forme d'un autre message XML.
La couche application contient la logique
applicative proprement-dite. Elle est structurée en un
ensemble de packages (au sens UML) contenant les
classes métier nécessaires pour l'application. Cette
couche reçoit les demandes de la couche
présentation-dialogue, émet des demandes d'accès
aux données en appelant la couche persistance, reçoit
les données de cette dernière, les structure selon le
modèle des objets de l'application et renvoie ce qu'il
faut à la couche présentation-dialogue.
La couche persistance ne s'occupe que des accès
aux données. Elle est associée aux gisements de
données, supports de stockage de l'ensemble des
données persistantes. Elle est structurée en un
ensemble de packages (au sens UML) contenant les
classes qui contiennent les accès aux tables des
bases de données.
Enfin, la couche données contient l'ensemble des
données stockées soit dans des gisements de
données, soit dans des référentiels.
Le passage d'une couche d'architecture vers une
autre doit impérativement se faire via des interfaces
(au sens UML) qui représentent chacune un service
d'accès.
La cohérence entre l'urbanisme (qui conçoit les
plans des SI dans une perspective de
fonctionnement rationnel et d'évolutivité) et
l'architecture d'un projet (qui en construit les blocs
applicatifs), sera d'autant plus aisée à assurer si l'on
parvient à redécouper les blocs applicatifs selon les
couches du modèle de l'architecture technique
logique.
Un bloc applicatif va donc se matérialiser par un ou
plusieurs composants applicatifs (des paquetages
au sens UML) du même niveau (quartier ou îlot).
En résumé, un paquetage accessible par des
interfaces matérialise chaque bloc applicatif pour
chacune des couches d'architecture technique
logique traversée.
Les communications entre les paquetages respectent
la règle de passage par des interfaces normalisées.
Le niveau architecture technique du plan
d'occupation des sols doit définir (ou
rappeler) le standard à suivre pour les
nouveaux développements en termes
d'architecture technique logique en couches
des applications.

2. La communication interapplicative et
inter-SI
L'identification des artères de communication joue
un rôle clé pour l'architecture.
Une artère de communication est un espace de
communication nécessaire pour faire face aux
prévisions de trafic (il s'agit du trafic de messages
entre blocs applicatifs et inter-SI). Les prévisions de
trafic sont issues de simulations de l'exécution
dynamique des processus. Les caractéristiques d'une
artère de communication sont le sens de circulation, la
fréquence du trafic, la densité du trafic et le niveau de
sécurité requis.
L'approche est pilotée par l'étude des besoins. Pour
satisfaire les besoins des différentes artères de
communication, on peut soit miser sur une seule
technologie, soit sur plusieurs et pour une technologie
donnée sur un seul ou plusieurs produits.
Les solutions basées sur les EAI (Enterprise Application
Integration) et les services web sont les deux
technologies les plus courantes pour implémenter
concrètement le
« gestionnaire de flux » tel qu'il est décrit au niveau de
l'architecture fonctionnelle.
Après l'ère des middlewares du début des années
quatre- vingt-dix qui représentaient un premier pas
pour assurer l'interopérabilité d'applications écrites
dans des technologies différentes, l'EAI est apparu
comme la solution naturelle et évidente pour
implémenter le concept de gestionnaire de flux tel que
décrit dans le chapitre 3.
L'EAI est en effet la solution disponible sur étagère
qui permet d'affranchir les applications (émettrices
et réceptrices) des conversions de syntaxe et du
transport des messages.
L'EAI est donc une technologie utilisée pour la mise
en œuvre de l'urbanisme. Mais ce n'est pas la seule
technologie utilisée et l'urbanisme ne se limite
nullement à la mise en place d'un EAI. En effet, un tel
outil ne redécoupe pas à lui seul comme par miracle
le SI en blocs applicatifs respectant les règles
d'urbanisme.
La capacité de la plate-forme EAI à s'adapter à des
contextes technologiques différents, et donc à faire
interopérer des applications construites sur des
technologies différentes, est l'un des critères clés de
sélection d'un produit. Concrètement, le nombre et la
qualité des différents connecteurs ou adaptateurs
fournis par l'EAI est un critère de choix essentiel.
Les services web sont apparus plus récemment que
les EAI et se sont vite affirmés comme une
technologie importante et d'avenir pour la mise en
œuvre de l'urbanisme.
Ils ont le mérite de reposer sur des protocoles techniques
:
SOAP (Simple Object Access Protocol), qui permet
de standardiser les appels de fonctions interfaces
avec les différentes applications ;
UDDI (Universal Description Discovery and
Integration) qui fournit l'annuaire des services web
disponibles ; WSDL (Web Services
Description Language),une grammairede
 XML qui porte la description
des
 paramètres en entrée et en sortie de la fonction.
Ces deux technologies (EAI et services web) sont à la
fois concurrentes et complémentaires et vont diminuer
l'importance pour un EAI de disposer d'adaptateurs
pour tous types d'applications à partir du moment où
les EAI supportent ces protocoles (SOAP, UDDI et
WSDL). Actuellement, la tendance du marché est la
course à l'intégration de ces protocoles dans les EAI.
À terme, les adaptateurs deviendront obsolètes et le
connecteur « services web » deviendra de plus en plus
universel.
Le service web est particulièrement adapté lorsqu'on
a besoin d'une réponse rapide. Par contre, l'EAI
apporte une réelle valeur ajoutée pour l'échange
d'informations « au fil de l'eau » ou en mode batch.
En effet, l'EAI peut prendre en charge l'extraction des
données de la source émettrice, le transport des
données ainsi que la mise à jour, tout en assurant
sécurité et fiabilité.
La simplicité de mise en œuvre dépend également de
l'hétérogénéité des technologies constituant les
applications ou les SI qui doivent s'échanger des
informations (par exemple, système de paye reposant
sur une technologie différente de celle d'un ERP gérant
la comptabilité générale). Pour l'EAI, cela signifie la
création de connecteurs différents à raison d'un
connecteur par technologie utilisée. Si les applications
utilisent la même technologie de gestion des données
(par exemple, Oracle), l'utilisation de l'EAI s'en
trouvera grandement facilitée. Au final et pour
résumer de manière simple, les services web sont
les mieux adaptés aux besoins de réponses
immédiates (de type transactionnel) et l'EAI est plus
adapté aux autres échanges interapplications ou inter-
SI.
Au-delà de ces deux technologies les plus
courantes, d'autres solutions plus anciennes sont
possibles pour mettre
en œuvre le principe de gestion des flux de messages
interapplicatifs comme les MOM (Middlewares Orientés
Messages), les systèmes de transfert de fichiers,
COM, Corba, Java, adapteurs CICS, gestionnaire de
files de messages etc.
Le niveau architecture technique du plan
d'occupation des sols doit préconiser une
ou plusieurs technologies réalistes par
rapport aux exigences et aux contraintes
pour mettre en œuvre la communication
interapplicative et inter-SI.

3. L'organisation des données

La gestion des données recouvre tous les travaux
informatiques liés à la manipulation des données
d'une base d'informations durant leur cycle de vie. Il
s'agit notamment du stockage, de la
sauvegarde/restauration, de l'import/export de
données, de l'archivage, de la purge, de la sécurité
des accès aux informations, mais aussi des aspects
plus fonctionnels liés à la construction des bases
d'informations, aux règles de gestion associées et à la
restitution de ces informations.
Enfin, l'organisation des données doit être de nature à
garantir les niveaux de services requis pour l'accès
aux données : certaines applications doivent accéder
très rapidement avec une disponibilité maximale aux
données (exemple : la gestion des réservations dans le
cas du tour- opérateur) et d'autres non (par exemple,
les statistiques agences dans le cas du tour-
opérateur).
Le niveau architecture technique du plan
d'occupation des sols doit définir les
principes d'organisation des données
réalistes par rapport aux exigences et aux
contraintes.

4. La supervision
La supervision du système d'information est un
élément clé de la chaîne de la valeur permettant
d'assurer aux utilisateurs le niveau de qualité de
service convenu.
La supervision du SI
comprend :
le pilotage de l'exploitation ;
la supervision technique, qui elle-même
comprend : l'ordonnancement des batchs ;
le suivi de la volumétrie des données ;
la mesure de la qualité de service fournie par
rapport au niveau de service attendu ;
le déclenchement des plans de secours en
cas de dysfonctionnements graves ;
le capacity planning, c'est-à-dire la prévision
d'évolution des infrastructures de production
en fonction de l'évolution de leur utilisation
(augmentation du nombre d'utilisateurs,
augmentation de la taille des fichiers gérés…).
Le niveau architecture technique du plan
d'occupation des sols doit définir les
principes de supervision du SI.

5. Les performances
L'architecture technique cible est construite de
manière à limiter les couplages entre applications et
éventuellement entre centres de traitement
informatique.
Cette action au niveau de l'architecture doit être
prolongée par une gestion des performances des
applications vue en premier lieu des utilisateurs mais
aussi des exploitants.
Les performances recouvrent les paramètres qui
permettent d'atteindre un niveau de service tel que le
temps de réponse, la disponibilité, le temps de remise
en état en cas d'arrêt ou encore la vulnérabilité.
L'établissement d'un plan de performances permet
d'anticiper sur le résultat global d'un processus en
étant en
mesure d'apprécier la contribution attendue et
observée de sous-ensembles applicatifs.
Ce plan recouvre trois parties principales :
un ensemble de processus représentatifs des
liens entre applications ;
le comportement en charge correspondant à
des volumétries de référence ;
la durée des batchs effectuée dans la
fenêtre d'exploitation.
La mise en œuvre du plan comprend la définition des
moyens de tests et le suivi des résultats prévisionnels
et mesurés.
Le niveau architecture technique du plan
d'occupation des sols doit définir un plan de
performance.

6. La sécurité
Un système urbanisé est par définition constitué
d'un ensemble d'applications communicant par
échanges de messages, d'où des flux de messages
importants, et d'une zone échange permettant
l'ouverture du SI sur l'extérieur. Les besoins de
sécurité d'un système urbanisé sont donc plus
importants que pour un système à la fois plus
monolithique et moins ouvert sur l'extérieur.
La politique de sécurité est donc nécessaire et c'est un
point clé de la réflexion sur l'architecture technique
cible, même si la sécurité dépasse bien entendu
largement le cadre de l'architecture technique.
Le niveau architecture technique du plan
d'occupation des sols doit inclure une
réflexion sur la sécurité menée de manière
conjointe avec les plans métier et
fonctionnel et proposer les solutions
techniques pour assurer le niveau de
sécurité requis.
 Remarques sur la démarche de définition du
plan de convergence
La définition du plan de convergence est largement
basée sur l'expérience de l'équipe d'urbanisation du
système d'information. Cependant, il existe une
démarche qui fournit une sorte de fil rouge pour ces
travaux. Cette démarche comporte les étapes
suivantes.
La première étape consiste à identifier les projets
incontournables.
La seconde étape consiste à hiérarchiser les
rénovations. Il s'agit d'identifier les priorités en se
basant en premier lieu sur la hiérarchisation des
objectifs stratégiques métier. La méthodologie
permettant la traçabilité entre les différents niveaux
de description de la cible (objectifs stratégiques
métier, objectifs stratégiques du SI, processus métier,
architecture fonctionnelle, architecture applicative et
architecture technique), il est aisé de hiérarchiser les
rénovations à mener (blocs applicatifs à construire, à
reconstruire ou à rénover) identifiées par l'architecture
applicative cible. Dans un deuxième temps, cette
hiérarchisation peut être revue pour intégrer d'autres
problématiques, comme par exemple la nécessité de
bénéficier de résultats faisant office de « vitrines » le
plus vite possible.
La troisième étape consiste à réaliser un
premier ordonnancement des projets.
L'approche consiste à établir un tableau à deux
dimensions. La première dimension représente le
niveau de complexité de la refonte (celui-ci peut-être
évalué a priori sans attendre l'étape 6 au cours de
laquelle les projets sont estimés) et la seconde, le
degré de satisfaction des objectifs stratégiques
métier suite à la refonte. On peut alors distinguer
quatre cadrans et classer les blocs cibles dans ces
quatre cadrans. Les blocs du cadran dont la refonte
est simple (niveau de
complexité faible) et pouvant apporter un gros plus
par rapport aux objectifs stratégiques sont de bons
candidats pour être refondus en priorité. Ensuite,
viennent les blocs dont la refonte est facile même si le
plus par rapport aux objectifs stratégiques est faible,
puis les blocs difficiles à refondre, mais apportant un
gros plus par rapport aux objectifs stratégiques, et
enfin les blocs à la fois difficiles à refondre et
n'apportant qu'une faible satisfaction des objectifs
stratégiques.
Le schéma de la figure 8.9 illustre cette approche.

Fig. 8.9

À partir de cette classification, on déduit une première

version du plan de convergence en regroupant
différents projets de refonte, ce qui permet de déduire
les états stables du SI, c'est-à-dire les étapes
concrètes qui vont jalonner le plan de convergence.
Un état stable est en effet une configuration du
système informatique ou d'un sous-ensemble du
système informatique qui est apte à assurer un
ensemble cohérent de fonctions du système
d'information.
Un état stable est un ensemble de blocs qui peuvent
fonctionner ensemble :
toutes les fonctionnalités nécessaires sont
présentes (certaines peuvent être dans une
version intermédiaire de la version cible) ;
toutes les données nécessaires sont présentes.
Il est à noter que cette approche fournit quasiment
mécaniquement quatre états stables (un par cadran).
La quatrième étape consiste à mettre à jour le
contenu de ces états stables pour tenir compte des
incompatibilités. Il s'agit d'identifier les
incompatibilités et de s'assurer que les solutions
intermédiaires (interfaces nécessaires au
fonctionnement du système entre deux étapes du plan
de convergence) et les projets induits (par exemple les
projets de type conduite du changement) n'ont pas été
oubliés. En effet, au-delà des aspects d'intérêt
stratégique et des charges de refonte, il est
indispensable de tenir compte de la faisabilité
applicative et technique. Par exemple, la mise en
place d'un nouvel applicatif peut nécessiter la
migration préalable des postes de travail sous un
nouveau système d'exploitation. Ou encore la mise en
place d'un nouvel applicatif peut n'être possible que si
un nouveau référentiel produits a précédemment été
installé.
Cette étape est capitale, car il serait extrêmement
dangereux de fonder un plan de convergence
uniquement sur les considérations fonctionnelles.
La cinquième étape est celle de la description des
projets. Chaque projet identifié dans le plan de
convergence doit faire l'objet d'une fiche
descriptive d'une à deux pages permettant de
préciser ses objectifs, son périmètre et son
positionnement dans les architectures métier,
fonctionnelle, applicative et technique cibles.
La sixième étape permet de contrôler la faisabilité
du plan de convergence du point de vue de la
charge et des délais.
À ce stade, on estime la charge représentée par
l'ensemble des projets permettant d'atteindre
chaque état stable et on s'assure que cette charge
est raisonnable (pour la maîtrise d'ouvrage et pour
la maîtrise d'œuvre) par rapport au délai. Cela
conduit généralement pour les blocs applicatifs les
plus importants à prévoir plusieurs versions pour
mettre en place progressivement des fonctionnalités.
Enfin, la septième et dernière étape permet de
confirmer la définition des états stables et de la faire
valider. Il s'agit ici de l'étape de validation du plan de
convergence. Les maîtrises d'ouvrage métier et la DSI
sont directement impliquées.
On notera enfin que le niveau de détail de la
planification doit être le plus élevé pour le chemin
menant au premier état stable, puis un peu moins
pour le chemin menant au deuxième état stable et
assez macroscopique ensuite. Ceci à la fois parce
que d'une manière générale une planification trop
fine à trop long terme n'apporte pas grand-chose et
parce que dans le cas d'une cible alignée sur la
stratégie, on sait qu'il y aura nécessairement
réactualisation de celle-ci compte tenu que la
rapidité des changements d'environnement pour
une entreprise.