Sys Info

Architectures de Systmes dInformation
Livre Blanc
Novembre 2002
Table des matires

PREFACE de Franois Tabourot.................................................................................................................................2
Comment larchitecture et lurbanisme apportent une rponse aux nouveaux enjeux de
rentabilit de lentreprise ............................................................................................................................................3
I.
Introduction ..........................................................................................................................................................7
La rvolution Internet aura-t-elle lieu ? .............................................................................................................7
Des consquences inattendues sur le march informatique .................................................................................8
Restaurer la confiance ncessitera daugmenter le taux de russite des projets .....................................................9
Pourquoi ne pas appliquer linformatique les mthodes prouves dans dautres secteurs ? ...........................10
La technologie nest pas un messie, elle fait simplement partie de lhistoire ......................................................11
La gestion du changement sappliquera aussi aux DSI .......................................................................................12
II.
Dmarche darchitecture dentreprise .............................................................................................................13

Mille et une DSI........................................................................................................................................................13
A quoi sert une DSI ? ..............................................................................................................................................14
La DSI, une SSII comme les autres ?.....................................................................................................................15
Conclusion................................................................................................................................................................17
III.
Etat de lart des principes darchitecture ........................................................................................................18

LArchitecture Logicielle ...........................................................................................................................................18
LArchitecture de SI ..................................................................................................................................................24
IV.
Les outils de larchitecte...................................................................................................................................33

Le formalisme de modlisation ................................................................................................................................33
Des patterns pour structurer la conception..............................................................................................................40
V.
Dmarche darchitecture projet........................................................................................................................48

LEtude Stratgique..................................................................................................................................................50
LEtude dArchitecture Gnrale ..............................................................................................................................52
LEtude dArchitecture Dtaille ...............................................................................................................................69
Le bureau darchitecture en phase dimplmentation ..............................................................................................75
VI.
Bibliographie ......................................................................................................................................................80
VII. A propos dOCTO Technology..........................................................................................................................81
Prface de Franois Tabourot

Directeur Gnral MEGA International
Comment larchitecture et lurbanisme apportent une rponse

aux nouveaux enjeux de rentabilit de lentreprise
Tout en changeant de nature et dintensit, la demande de justification conomique des
dpenses se fait de plus en plus pesante sur les directeurs informatiques.
Cest pour rpondre cette transformation des attentes du management que les outils de
pilotage dont les directions informatiques ont besoin voluent.
Cest par cet angle que nous proposons de comprendre le fondement des approches de
cartographie et durbanisme de systmes dinformation.
Comme larchitecte et lurbaniste uvrent au dveloppement de lhabitat et des cits, le directeur
informatique dispose avec ces nouveaux outils dun ensemble de cartes et de reprsentations
utiles pour analyser, construire et adapter les systmes dinformation aux grands enjeux mtier
de lentreprise. Mais ces outils doivent aussi sinscrire dans une dmarche de rentabilit, comme
nous allons le montrer dans cette prface.
De lorganisation des ressources la justification conomique

A lorigine, il nest pas question de justification conomique : lorsque la modernisation entrane
avec elle, la promesse du dynamisme de la croissance et du progrs social, quel dcideur
conomique voudrait sy opposer ?
Cest ainsi que se font les grands progrs, par rupture, lorsque les vidences et les fantasmes
initiaux sont assez forts pour attnuer la visibilit des difficults quimposera le changement.
Cest de cette faon que sest dveloppe linformatique de gestion dans lentreprise la fin des
annes 70 : pouvait-on imaginer ne pas sinformatiser ? Nier que lapport fonctionnel de cette
technologie tait un levier de modernit au bnfice de lhomme et de son rapport au travail ?
Aucune entreprise na contest le besoin dinformatisation, pour rester dans les standards de
comptitivit. Lamlioration de la productivit par lautomatisation des tches administratives se
suffisait elle-mme, comme vidence initiale pour dclencher un vaste mouvement
dinformatisation.
Sous la responsabilit de la direction administrative et financire, une nouvelle direction, la
direction informatique, sest alors vue charge de faire lacquisition et de dployer dans les
meilleures conditions ces nouvelles technologies : machine, base de donne, langage, systme
dexploitation
Ensuite, lvolution technologique sinscrivant sans rupture dans la continuit de la rvolution
fonctionnelle initiale, le besoin de justification conomique est apparu et sest intensifi avec le
temps.
Nous allons montrer comment lurbanisme contribue la rentabilit de lentreprise, dabord de
manire simple, en permettant doptimiser le systme dinformation par rapport aux activits de
lentreprise, mais aussi de manire innovante, en permettant damliorer sa contribution la
production de valeur dans lentreprise.
Urbanisme et rduction des cots

Ds lors que limpact dune innovation sur le business model nest pas vident, tout choix
technologique doit tre justifi par le retour sur investissement. Cest dire que le directeur
informatique doit prouver que le mme service peut fondamentalement tre rendu moindre
cot : dexploitation, de maintenance, de dploiement
Le cahier des charges fix au directeur informatique par le management loriente alors vers la
recherche dconomies, sans dgradation du service rendu par linformatique lentreprise. Et le
rle du directeur informatique consiste slectionner les solutions les plus adaptes parmi les
offres des fournisseurs, selon trois axes de rduction de cots possibles :
Diminution des cot dexploitation des architectures matrielles par migration des
technologies gros systmes ;
Diminution du cot des dveloppements par utilisation des progiciels et - gnralisation
des principes de dveloppement bass sur la rutilisation ;
Rationalisation du parc applicatif par apurement du legacy system .
Pour faire face une offre foisonnante et fortement combinatoire sur le plan des solutions
technologiques (rseau, base de donnes, machines), les directions informatiques ont ainsi
t amenes mettre en place une responsabilit darchitecture technique . Cette structure,
souvent renforce dune expertise externe, assume la responsabilit du down-sizing des
cots informatiques par le levier de linfrastructure, en adressant des enjeux de diminution des
cots dexploitation et de mutualisation des ressources.
Sur laxe applicatif, et sensiblement au mme moment, comment nier limpact considrable de
larrive des progiciels sur lvolution des responsabilits et du mode de raisonnement du
directeur ou responsable des tudes ? Fabriquer du code sinscrit de la mme manire dans une
justification conomique drastique o lon doit dmontrer que le mme service nexiste pas dj
dans le parc applicatif, ni lextrieur sous forme dun progiciel. Il est dsormais admis que faire
cote toujours plus cher quacheter tout fait (ici lhistoire viendra pondrer ce point de vue, en
particulier sur la base du retour dexprience du dploiement des ERP).
Si lon choisit de dvelopper en interne, on est contraint de dmontrer que tant le choix du
langage que celui de larchitecture fonctionnelle minimise les cots de dveloppement et
maximise la rutilisation des composants.
Dans ce contexte, et pour rpondre cette pression conomique base sur la rduction des
cots, les directeurs informatiques ont besoin de nouveaux outils de pilotage de leur activit et
dinstrumentation de leur relation avec le management.
La cartographie urbanise des systmes dinformation apparat comme le moyen pour le
directeur informatique de garantir loptimum de lutilisation de ses ressources matrielles et
applicatives.
Elle lui permet en effet :
1. de parfaitement connatre et matriser lensemble de ses ressources ;
2. de comprendre leur niveau dinterdpendance et de rutilisabilit ;
3. de garantir la facilit daccs cette information documentaire, en rangeant lensemble
de ces lments lintrieur de repres proches de lactivit de lentreprise.
Cette nomenclature statique dactivits constitue le cadre de rfrence mtier permettant
durbaniser lensemble des ressources.
Cette cartographie est un projet dlimit essentiellement au sein du service informatique. Elle
nimplique pas de connatre le fonctionnement de lentreprise, les grands processus mtier, la
collaboration des activits et des acteurs. Beaucoup de projets de cartographie sont ainsi mens
sans grande implication des directions fonctionnelles.
Selon cette approche, la cartographie est essentiellement un outil doptimisation utile la
direction informatique.
En dcrivant les diffrents composants du systme dinformation, leurs relations et leur utilisation
pour servir les diffrents mtiers de lentreprise, on dispose en effet dun outil doptimisation
complet pour :
analyser les redondances et reprer les applications inutilises ;
mesurer limpact dune opration de maintenance et rationaliser sa mise en uvre : ce
nest pas pour rien que ces approches ont connu leur heure de gloire lors des projets an
2000 ;
faciliter les projets dacquisition de nouvelles technologies, en particulier
dintroprabilit de systmes, workflow et EAI.
Ainsi, comme il sattache une simple lecture des systmes dinformation et de leur position sur
le planisphre de lorganisation de lentreprise, lurbanisme des systmes dinformation dans son
acception courante (thorie de Jacques Sassoon), et par extraplation des thories de
lurbanisme traditionnel, accompagne la dmarche de rduction des cots, dont lobjectif
principal est la recherche de loptimum.
Cette analyse des outils durbanisme met en vidence leur propre limite comme tous les outils
doptimisation. Pour prendre le langage des financiers, on comprend que la fabrication de
marge par rduction de dpenses nest pas un facteur daccroissement du chiffre daffaires.
Quautrement dit et trs naturellement on comprend quayant dmontr leur capacit servir le
fonctionnement du business model de lentreprise au moindre cot, la question mergente
pose aux directions informatique est denvisager leur capacit contribuer significativement
la production de valeur.
Cest dire proposer des investissements informatiques (matriels ou applicatifs) dont le
retour sur investissement se calculera sur la base dun gain de productivit dun processus
mtier, de la conqute de parts de march, de la capacit se diversifier, donc sur la base
dune vue dynamique du fonctionnement de lentreprise.
Si lon assume quurbaniser cest positionner des objets sur des repres, ce nouvel urbanisme
naissant est celui qui permet denvisager la contribution des ressources informatiques (les
objets) la performance des chanes de valeur de lentreprise (les repres).
Urbanisme et production de valeur

Il sagit donc dsormais de dmontrer comment linformatique permet, non seulement de
rentabiliser ses investissements propres, mais aussi de produire de la valeur pour lentreprise.
Au del de la rduction des cots dans linformatique, lenjeu pour la direction informatique
concerne en effet sa capacit contribuer de manire directe la production de valeur.
Cela signifie par exemple :
utiliser les outils de business intelligence pour mieux qualifier les contacts lors dune
prise de commande, et par suite diminuer les taux dimpays et augmenter le panier
moyen en VPC ;
organiser des changes automatiss et intgrer le systme de gestion de livraison dun
sous-traitant pour proposer en ligne ses clients les meilleures solutions de rsolution
de panne ;
dvelopper une gestion automatise des processus pour organiser le back office de
lensemble de ses agences, et assurer ainsi une rponse centralise tous les dossiers
de prts transmis par les agents dans un dlai garanti.
Lurbanisme nouveau permet de rapprocher la cartographie du systme dinformation de la

vision dynamique des chanes de valeur, cest dire des collaborations entre activits et acteurs
pour produire de la valeur. Le projet durbanisme implique alors les grandes directions mtier de
lentreprise, pour comprendre comment linformatique contribue la stratgie de lentreprise.
Dans cette dmarche, le directeur informatique se rapproche dune fonction de chef de
progrs dcrite la fin des annes 80 par Andr Leynaud1 dans ses traits sur linformatique
stratgique.
Tel est le challenge de lentreprise daujourdhui : penser son positionnement concurrentiel et sa
cration de valeur sur le march, en corrlation directe avec larchitecture de ses ressources en
particulier informatiques.
Cest la nouvelle problmatique durbanisme de systmes dinformation, qui recentre le directeur
informatique sur les enjeux mtier de lentreprise, au risque dune moins grande matrise de la
dimension technologique des systmes dinformation, ventuellement sous-traite des tiers.
Lentreprise fera ainsi de son responsable informatique un business architecte , capable de
prendre en main la dclinaison oprationnelle de la stratgie.
Pour sy prparer il lui faut dores et dj des outils de pilotage constitus en fond documentaire
qui prcise :
Les chanes de valeur, leur description, et les performances stratgiques attendues ;
Larchitecture des ressources, et en particulier, leur contribution ces chanes de valeur.
Cest la vue business du systme dinformation urbanis selon les processus mtier de
lentreprise.
Un nouveau rle pour le Directeur Informatique

Si le cycle complet de mise en place dun systme dinformation obit toujours la mme
problmatique, lintensification de la problmatique associe chaque tape justifie selon nous
une spcialisation et un partage des rles.
Ainsi, cest souvent lintgrateur extrieur qui, assumant la responsabilit de la performance
informatique , aura linitiative de la technologie, alors que le directeur informatique rendra
compte au comit de direction de latteinte dobjectifs business.
1. Quand le service est identifi et que le problme se limite en optimiser le cot, alors le
mtier informatique devient un mtier dindustriel, seul capable :
de matriser le foisonnement technologique et faire merger des formes de
standardisation ;
de gnrer des conomies par mutualisation des cots.
2. Quand les services rendus par la technologie sont des leviers de transformation du
business model , de son efficacit et de sa comptitivit, les hommes et les femmes
qui pensent larchitecture fonctionnelle du systme dinformation pilotent la rflexion
stratgique sur la base de leur double matrise :
des mcanismes de cration de valeur, les business process ;
de la contribution des services fournis ces business process .
Sils sont les maitres douvrage du systme dinformation, ils doivent ltre davantage
pour leur connaissance du fonctionnement et des hommes de lentreprise, que pour celle
des rgles de gestion contenues dans les systmes.
1 : Andr Leynaud fut le Prsident du Gamma International au sein du Groupe Hay, puis de Cap Gemini.
Cest, selon notre analyse lune des causes principales du revers de la nouvelle conomie
qui, en privilgiant lapproche strictement technologique, a occult la lecture de certaines
transformations de business model pourtant trs significatives et portant sur les modes de
consommation, dachats, de distribution
De la mme manire, mais sur le plan de la micro conomie, la mise en place des grands ERP
atteint finalement son retour sur investissement lorsque enfin, quelquun sintresse
comprendre comment les utilisateurs vont travailler mieux avec de nouveaux outils,
indpendament de la manire dont ils sont fabriqus.
Matrise des processus mtiers, de larchitecture corrlative des hommes et des ressources qui
contribuent leur fonctionnement et leur performance, est plus que jamais une attente forte dans
une macro conomie qui acclre considrablement le besoin de flexibilit du busines model .
Est-il donc ncessaire de convaincre le dcideur conomique du bien fond de lurbanisme des
systmes dinformation, lorsque, au bout du compte, on dmontre que cest lui qui en formule la
demande ?
Sans doute que le jargon informatique encore trop souvent employ pour dcrire lurbanisme ne
sert pas le directeur informatique. Il lui appartient aussi den faire un outil de communication pour
son management, pour prendre sa place vritable au sein des directions dentreprise.
I. Introduction
La rvolution Internet aura-t-elle lieu ?
Septembre 2000. Les espoirs de gains de productivit lis la mise en place des Nouvelles
Technologies de lInformation et de la Communication (NTIC) dans les entreprises sont au plus
haut. Ils justifient la dmesure des valorisations de toute socit ayant plus ou moins vaguement
affich des e-ambitions. Malheureuse, ringarde, celle qui nest pas une e-entreprise, qui na pas
Les promesses de
nombreux chantiers
informatiques ces
cinq dernires
annes nont pas
t tenues.
4,
son projet eProcurement2, eCRM3, eSCM ou qui noffre pas laccs son catalogue de tles
dacier lamin sur le WAP.
Septembre 2002. Le e est pass de mode, ensemble avec les trotinettes et les stocksoptions, et sest dfinitivement par dun voile de dsutude comme seule la disparition des
pantalons pattes dlphant et des sous-pulls en acrylique nous avait habitus : pouah, plus
jamais a.
Internet devait acclrer la marche du progrs, on naurait jamais imagin quel point cette
vitesse imaginaire consumerait sa crdibilit au point de lui brler les ailes. Car tel est le sens de
la crise, une crise de confiance, une sorte de dsillusion face une suppose rvolution, ou
nouvelle conomie, qui na laiss la place qu des ardoises faramineuses en lieu et place des
conomies et accroissements de la comptitivit attendus.
Or les gains de productivit lis une dmarche dinformatisation de processus, quels quils
soient (marketing, vente, approvisionnement, achat, etc.) apparaissent conditionns la
dmatrialisation globale dudit processus et une rorganisation du travail autour de ce
processus.
On oublie trop
souvent que les
technologies de
linformation sont
avant tout des
technologies au
service de
lorganisation.
Ceci a deux consquences, lune informatique pour laquelle la complexit et ltendue des
chantiers ont t sous-estimes. Lautre, organisationnelle, renvoie au fameux paradoxe de
Solow5, qui ne voyait dans laugmentation de lutilisation de linformatique aucune augmentation
de la productivit ( linformatique se voit partout, sauf dans les statistiques ). Or ce paradoxe
nen est plus un lorsquon observe les entreprises qui accompagnent leurs projets informatiques
des rorganisations ncessaires la prsence de ce nouveau personnel numrique .
Ainsi, la plupart des projets CRM mis en place pour des fonctions cibles ont atteint leurs
objectifs : centre dappels, infocentre commerciaux (churn6, rentabilit produit), gestion de
contacts, etc. Mais les projets himalayens ont souvent accouch de souris, quand ils ont
accouch. Et pour cause, on avait simplement oubli dimaginer que cest tout lunivers de
lentreprise qui serait boulevers par la mise en place de tels systmes : reprise de contrle en
central, regroupement de comptences, modification des centres de profit, nouveaux services
vendre au client, etc.
Lentreprise est un tout, linformatique ne doit pas tre vue comme la cl de vote unique du
changement. Si la production nest pas flexible, inutile de squiper dun systme complexe de
gestion de la chane logistique ! Linnovation technique doit aller de pair avec des innovations
organisationnelles : dveloppement du juste temps , et du sur-mesure avec
externalisation massive7.
2
3
4
5
6
7
: Gestion lectronique des achats.

: Gestion lectronique de la relation client.
: Gestion lectronique de la chane dapprovisionnement.
: Economiste amricain, prix Nobel dconomie en 1987.
: Taux de Churn : facteur qui mesure la propension dun client changer de fournisseur, trs utilis dans le secteur des tlcommunications.
: Nouvelle conomie : rapport Daniel Cohen et Michle Debonneuil.
Linformatisation
doit accompagner
les changements
dorganisation
lintrieur de
lentreprise ; elle
peut aussi les
susciter.
A ce registre, les meilleurs exemples susceptibles dtayer cette thse se trouvent auprs des
entreprises virtuelles , qui se sont construites prcisment dans des modles modulaires
devant pallier labsence de ciment capitalistique. Ici loutil informatique est un facteur cl
dintgration dacteurs indpendants dans une structure cohrente.
Elle est un ciment

alternatif au ciment
capitalistique pour
les nouvelles
entreprises en
rseau .
Ainsi paradoxalement, on avait imagin que leBusiness allait augmenter la capacit changer
de fournisseurs plus rapidement, et cest linverse qui sest produit et continuera
vraisemblablement se produire : linvestissement informatique seffectue dans la dure, avec
les partenaires privilgis, pour qui lon btit un systme commun.
Certains chantiers
ncessiteront au
pralable une
rflexion dordre
dontologique.
Inversement, il
existe des limites
lutilit de
linformatisation.
Un alignement
stratgique est
ncessaire.
Les entreprises virtuelles qui ont connu les succs les plus durables, comme Ikea, Benetton, Dell
ou Nike sappuient sur des modes dintgration diffrents de la possession du capital, mais
atteignent un degr de cohrence stratgique tout fait comparable celui dune entreprise
capitaliste classique8. Elles possdent en particulier les systmes de gestion de la chane
logistique les plus performants.
Inversement, il est des situations o linformatisation ne sert aucun dessein tangible. Lidologie
du pervasive computing9 , chre certains, ne sapplique pas tout. On dcouvre ainsi
lavance de phase des rseaux 3G, dont aucun service au consommateur ne peut encore
justifier le cot dinvestissement, ou les limites du one-to-one et de la personnalisation. Les
systmes informatiques de relation client sonnent le glas des arbitrages historiques entre
richesse et impact de linformation, puisquils ouvrent la possibilit de diffuser automatiquement,
donc massivement, du contenu personnalis10. L o un tissu de plusieurs dizaines de milliers
de conseillers financiers tait la condition sine qua non dune relation riche, il est dsormais
possible deffectuer un conseil personnalis massif sur la base dinformations de profils. Ces
possibilits font nanmoins peur et soulvent des problmes dontologiques non encore rgls
: protection de la vie prive, risques inhrents la cration de bases centralises de profils...
Car qui nous veut du bien au final ? Cette extension fulgurante des systmes de scoring hrits
du monde bancaire tous les secteurs ncessite des rflexions plus pousses sur la relation qui
unit une entreprise ses clients. Celle-ci doit demeurer bilatrale, gagnant/gagnant. Les gains
dun systme de Relation Client doivent donc tre partags avec celui-ci !
Des consquences inattendues sur le march informatique
Cet ensemble
dcueils a fait
exploser la bulle
Internet et laisse
derrire lui un
march de ldition
dprim.
Ces diffrents cueils ont fait quelques dgts collatraux, dont les diteurs de logiciels ont t
les premires victimes. Progiciels de xRM (portails, relation client, relation partenaire,
eCommerce), places de march, gestion de la chane logistique, gestion de conception
collaborative et tant dautres, ont fait les frais de leur avance de phase sur le march. Dans ces
conditions, seuls les gros acteurs et leurs premires lignes de partenaires ou sous-traitants
peuvent survivre.
Les principales vraies innovations des cinq dernires annes autour des notions de relation
client, chane logistique, achats, ou conception de produits ont t intgres aux offres des
mastodontes du secteur (Oracle, SAP, PeopleSoft) par acquisition ou dveloppement interne.
La convergence ERP/CRM/SCM/PLM/SLM11 annonce des suites de gestion intgres et
modulaires pour toutes les industries. Seules la banque et lassurance restent encore
8 : Frdric Frry : Benetton ou l'entreprise virtuelle .

9 : Informatique diffuse.
10 : Blown into Bits : How the New Economics of Information Transforms Strategy (ou comment la nouvelle conomie de l'information transforme la stratgie), de
Philip Evans et Thomas Wurster.
Concentration dans
les couches hautes :
lERP tout faire.
Lintgration des
progiciels
dinfrastructure est
la seule rponse
possible
lascension du
logiciel libre sur ce
credo.
partiellement lcart de ce mouvement massif de progicialisation. Pour combien de temps ?

Cette inflation des progiciels dentreprise suit un second mouvement de fond : la convergence
vers des socles dinfrastructure standard : J2EE et .Net pour lexcution des traitements, bus
EAI pour linteroprabilit entre modules, outils PKI12 pour la scurisation des changes, etc.
Paralllement, la standardisation dont se nourrit le march depuis lavnement de TCP/IP,
annonce fatalement de grands bouleversements dans lindustrie du logiciel. Vingt ans aprs les
premires communications entre ordinateurs via ce standard13, nous sommes en passe de
rendre aussi transparente une conversation scurise et smantiquement riche14. Cela peut
paratre long pour une industrie qui se targue des plus forts taux dinnovation, mais cest
finalement le temps ncessaire la coordination dun secteur. Pour autant, il est difficile de croire
que les promoteurs de standards comme J2EE pouvaient imaginer quel point une norme
pouvait acclrer la concentration du march. Il y avait une dizaine de moniteurs transactionnels
avant 1998, tous plus onreux et spcifiques. Il y a moins de cinq acteurs aujourdhui, en
comptant bien sr le logiciel libre, fournisseur dsormais incontournable de couches basses :
des logiciels comme Linux, JBoss ou PostgreSQL15 vont continuer tailler des croupires aux
diteurs dinfrastructure classique, mme aprs leffondrement de leurs tarifs.
Pour contrer cette offensive, une course lintgration va sengager. Car entre un serveur
dapplications payant et un gratuit, le choix du gratuit risque de simposer ds lors que lon aura
franchi la barrire psychologique qui nous pousse encore croire que lun est forcment moins
bien que lautre. La contre-offensive consiste proposer le socle de base - la limite
gratuitement -, en y associant une offre de modules et doutils connexes.
Cest le mouvement qua clairement initi Microsoft avec sa plate-forme .Net, qui consacre la
notion de Progiciel dInfrastructure Intgr : transactionnel, persistance, scurit, changes, et
outillage cohrent de conception, dveloppement et exploitation. IBM et Oracle poursuivent
galement cette dmarche.
Les efforts des diteurs pour rendre plus accessibles leurs produits, quils soient applicatifs ou
techniques se heurtent encore au constat que seul un projet informatique sur quatre atteint ses
objectifs dans le respect de son budget et de ses dlais.
Restaurer la confiance ncessitera daugmenter le taux de

russite des projets
Taux dchec des
projets
informatiques en
baisse, mais
toujours inquitant.
Lincomprhension
chronique entre
fonctionnels et
informaticiens
lorigine de ces
statistiques
dplorables.
Ltude du Standish Group pour 1998 montre une amlioration par rapport 1996 puisque le
taux dchec des projets tombe de 40 % 28 %. En revanche, encore prs de la moiti des
projets sont en retard et/ou hors budget, ce qui laisse seulement un quart de projets pleinement
russis.
Ceci nest pas une fatalit, puisque certains secteurs comme la Distribution parviennent un
taux de succs de 60 %.
Quelles sont les causes de telles statistiques ? En premier lieu les problmes de pertinence des
projets dans le contexte organisationnel de lentreprise dj voqus : modle conomique
dfaillant et absence de gestion du changement.
La seconde cause majeure semble se situer dans lincomprhension chronique entre quipes
fonctionnelles et quipes informatiques. Lorsquun architecte en btiment produit le plan dun
difice, le client final et le matre douvrage savent quoi sattendre, tandis que le matre duvre
11 : Respectivement Enterprise Resource Planning, Customer Relationship Management, Supply Chain Management, Product Lifecycle Management, Service Lifecycle Management.
12 : Public Key Infrastructure : systmes permettant la confidentialit et lintgrit dchanges lectroniques laide de procds cryptographiques.
13 : Voir RFC 793, septembre 1981.
14 : Notamment au travers des standards promus autour des Web Services.
15 : Respectivement systme dexploitation, serveur dapplication Java et base de donnes relationnelle en Open Source.
sait gnralement ce quil lui reste faire. La raison ? Les plans. Ils instituent une reprsentation
et un vocabulaire commun dune part, et permettent de crer un rfrentiel dtaill du projet
dautre part.
Pourquoi ne pas appliquer linformatique les mthodes

prouves dans dautres secteurs ?
Larchitecture cre
les conditions du
dialogue entre les
intervenants du
projet.
Larchitecture, littralement lArt de construire des difices , est avant tout lart de
communiquer. Du plan commercial en 3D, au plan dtaill des vacuations deau jusquau
nombre de fentres et de tonnes de bton fournir, larchitecture aura servi de support aux
activits des vendeurs, des matres douvrage, et des diffrents matres duvre. Larchitecture
est ainsi le vecteur de la Qualit et de la Coordination du projet. Imaginer construire un
immeuble sans plans suffit pour avoir une ide du niveau de Qualit et de Coordination que lon
obtiendrait...
En informatique toutefois, le problme se corse lgrement. Les plans dun Systme
dInformation (SI) nont quun lointain rapport avec leurs cousins des Travaux Publics. Les SI ont
en effet une dimension dynamique, structure autour des cas dutilisation, et qui ncessite
lutilisation de diffrents niveaux de reprsentation mlant processus, acteurs, systmes,
donnes, etc. Michel Pbereau, Prsident de BNP Paribas dclarait ainsi Linformatique
bancaire, cest un peu les cathdrales du Moyen-Age, commences en style roman et termines
en gothique flamboyant. Les architectes sont morts depuis longtemps et plus personne na les
plans 16.
Les plans de nos

Systme
dInformation
nexistent pas.
Face cette complexit, le rflexe qui a prvalu jusqu prsent a t de ne btir que des plans
de trs bas niveau, cest dire des plans darchitecture technique. Rseaux, firewall, 3-tiers, bus,
hub, et maintenant peer-to-peer sont autant de reprsentations qui permettent de dcrire la
ralit physique dun systme. Mais elles achoppent dans une mission de communication
englobant toutes les facettes dun projet, notamment les plus fonctionnelles. La bonne nouvelle
vient de la monte dans les couches , tendance de fond que vit le secteur informatique
depuis son apparition, et notoirement aliment par la standardisation. Elle nous conduit
inexorablement matriser les systmes un niveau de plus en plus lev.
Nous aborderons donc larchitecture dans sa globalit, alors quelle nest rellement prsente
aujourdhui qu un niveau technique. Du reste, si nous disposions de cartes de Systmes
dInformations tendus, nous serions probablement surpris den constater la complexit, la
redondance, voire lillogisme. Conserverions-nous ces systmes actuels de places financires,
de facturation tlcom ou ces rseaux dadministrations en les amliorant ou serions-nous
amens les remplacer ? Les programmes fondamentaux du cerveau humain (son architecture
donc) semblent voluer de moins en moins avec lge, est-ce galement le destin de nos
Systmes dInformation ? Cest--dire devenir des tres complexes mus par une machinerie
simpliste ? Larbitrage entre rnovation et reconstruction est un dilemme rcurrent de
larchitecte.
Ainsi, en informatique comme dans le BTP, larchitecture est une mthode susceptible
daugmenter la matrise des chantiers denvergure. Par sa fonction de vecteur de
communication, elle concerne tous les acteurs impliqus dans les projets, au premier rang
desquels figurent les donneurs dordre. Nous montrerons galement que les investissements
quelle ncessite se rentabilisent par laugmentation de la qualit et la diminution des dpenses
de coordination.
16 : Les Echos, 12 dcembre 2001
10
Plus cest
compliqu
lintrieur, plus ce
sera compliqu
intgrer avec
lextrieur.
Labsence de dmarche darchitecture de SI na pas nui la mise en place unitaire dapplications.

Progiciels cls en main et mthodologies de dveloppement de plus en plus prouves ont
permis damliorer la productivit de ces investissements. Mais cette capacit dployer des
modules de plus en plus complexes a laiss de ct la problmatique de leur fonctionnement au
sein dun systme dinformation qui les coordonne. Par capillarit , cette intgration entre
modules se complexifie elle aussi.
Larchitecture est
lart damener la
bonne information,
au bon endroit,
dans la bonne
forme, et de
manire scurise.
La dmatrialisation complte de chanes de traitements ncessite une intgration des donnes

rfrentielles, de la smantique (le vocabulaire), et de la scurit. Larchitecture de SI est lart de
relier les pices dun puzzle, tandis que celui de crer les pices individuelles est du ressort de
larchitecture de code. Architecturer, cest permettre damener la bonne information, au bon
endroit, dans la bonne forme, et de manire scurise. Simple problme technique ?
Malheureusement non.
Btir les futurs systmes de remboursement de prestations mdicales, dachat de voyages la
carte, ou de rglement/livraison cross-border de produits financiers ncessitera de faire
interoprer des applications de diverses gnrations, qui nont que peu de choses en commun.
Un seul challenge
pour les SI de
prochaine
gnration :
augmenter leur
capacit
dinteroprabilit.
Par exemple, comment mettre en place un service qui prviendrait automatiquement par SMS
toute personne dont lavion subit un retard ou une annulation (embaucher des gens pour le faire
ne serait probablement pas assez rentable) ? Il faut que les systmes de rservation interoprent
automatiquement avec un rseau de tlphonie. Plus prcisment, il faut que ces systmes de
rservation en back-office sachent remonter ce type dinformations au front-office, qui se
chargerait de propager linformation aux clients concerns. Sachant que le distributeur du billet
nest pas forcment le producteur du trajet en avion, lquation devient multi-acteurs, ce qui ne
fait quajouter sa complexit. Ce type de problme na de solution quau travers dune
dmarche de spcification tendue normalisant notamment le cycle de vie dvnements
dentreprise comme ce banal retard davion .
La technologie nest pas un messie, elle fait simplement partie

de lhistoire
Interoprer impose
une matrise de
larchitecture
technique ET
fonctionnelle.
Heureusement larchange Technologie vient notre secours, me direz-vous. La technologie aide,

certes. EAI, infrastructures 3-tiers et outils de scurit nous assistent dans la tche de
construction de ces espaces de confiance , cependant ils ne suffisent pas en soi. Ce ne sont
que des botes outils finalement ; nous avons encore trop de latitude pour amener la bonne
information au bon endroit (quelle information envoyer, quel moment ? selon quels protocoles ?
quelles mthodes de routage, statiques, dynamiques ?), dans la bonne forme (quel format ? quelle
smantique ? quelles donnes rfrentielles ?), de manire scurise (qui me contacte ? est-il en
droit de me communiquer cette information ? est-ce bien celle quil a mise ?).
Attention donc aux chimres technologiques, qui alimentent illusions et malentendus. Oui, les
standards mergents des Web Services vont amliorer linteroprabilit, mais ils ne constituent
quun lment de base de la communication, ne sattaquant pas encore aux problmes
complexes de smantique, qui ne trouveront pas de solution dans un carcan uniquement
technique. Un produit driv bancaire ne se modlise pas comme un billet de train ou une
commande de trois palettes de parpaings.
Pour nous assister dans la construction darchitectures applicatives, nous allons utiliser et
promouvoir un certain nombre de pratiques standard, que nous nommerons patterns dans la
suite. Comme la fentre en PVC de 2m sur 1m20 est une solution standard louverture dune
11
Des plans
standards ,
pratiques
communes de la
profession,
permettent de
rsoudre des
problmes
rcurrents.
pice sur lextrieur ; la priorit droite, le feu de signalisation ou le rond-point, sont trois
solutions possibles pour un croisement ; des patterns darchitecture, tels que la notion de
royaume et dmissaire, ou le concept de noyau sont respectivement des solutions standards
la communication inter-SI et intra-SI. Ces patterns nous permettent de dcliner des architectures
semblables quel que soit le secteur dactivit, diminuant de fait leur cot.
Ces similitudes nous poussent penser que les implmentations volues de ces patterns
constitueront le futur des Progiciels dInfrastructure Intgrs.
La gestion du changement sappliquera aussi aux DSI
Adapter la DSI de
nouvelles priorits.
Dans les entreprises o le niveau de synergies entre branches ou vis--vis de lextrieur est
lev, il faut bien tre conscient que linteroprabilit des Systmes dInformations (SI), support
de ces synergies ne se crera pas delle-mme. Pour augmenter la capacit dinteroprabilit du
SI, les DSI vont devoir se doter dune organisation susceptible daccueillir des projets mixant
ressources internes et externes, tout en conservant une forte capacit de matrise transverse.
Parce quelles taient vues sous un angle purement technique, donc sans sponsor de haut
niveau, les initiatives transverses actuelles, comme le dploiement de rfrentiels ou de bus
dchanges ont jusqu prsent priclit. Les promouvoir au rang de priorit stratgique leur
confrera une toute autre dimension.
Voila par le menu les thmes abords dans cet ouvrage, nous invitons le lecteur les parcourir
sa guise selon son profil, puisquil y trouvera, nous lesprons, des rponses des questions
dordre organisationnel, fonctionnel et bien sr technique.
Pierre Pezziardi
12
II. Dmarche darchitecture dentreprise

Le dfi qui se pose une entreprise est de savoir quels sont les services informatiques
adapts son contexte stratgique. En second lieu, elle sinterrogera sur ceux devant tre
assurs lchelle de lentreprise (ou du groupe), ceux quil convient de laisser aux soins des
units oprationnelles (ou des filiales), et ceux quil convient dexternaliser.
Mille et une DSI

Les DSI sont
confronts trois
grandes catgories
de projets, dont les
objectifs sont
radicalement
diffrents.
Ce contexte stratgique, vari selon les secteurs et le temps (!), induit diffrents types de
missions pour les DSI. Ces missions peuvent se dfinir selon trois types dapproches :
l utilit , la dpendance , et le dveloppement . Ces missions vont de labsence
totale de services dinfrastructure dans la socit loffre de services tendus, disponibles dans
toute lentreprise au sens large, y compris dans les units oprationnelles, auprs des
fournisseurs et des clients 17.
Dans lapproche utilit , les services informatiques ont pour objectif essentiel de rduire les
cots, par la rationalisation du patrimoine informatique ou linformatisation de processus
existants. Comptabilit groupe, mutualisation de rfrentiels de scurit, ou fusion de systmes
mtier sont des projets types dans cette stratgie. Une DSI oprant dans ce mode grera un
portefeuille de projets dits Tels Que Construits 18, car connus au sens mtier, et uniquement
pilots par le retour sur investissement prcis (ROI19) que lon souhaite en attendre.
Le calcul du ROI
dun projet
informatique na de
sens que dans un
contexte stable et
connu. Les projets
innovants devront
tre pilots laide
dautres mtriques.
Une approche dpendance rpond quant elle une politique spcifique de lentreprise.
Ce ne sont plus simplement des conomies qui sont recherches, mais de nouvelles
opportunits retour rapide. Un constructeur automobile pourra ainsi connecter ses
concessionnaires ses systmes internes, leur donnant accs aux informations produits, au
suivi de clientle, la gestion du SAV, au commissionnement, etc. Nous parlerons de portefeuille
de projets Mieux Que Construits , puisquil sagit damliorer des systmes existants pour les
ouvrir des partenaires, ou les intgrer de nouveaux processus par exemple. Dans ce cas, le
pilotage par le ROI peut savrer plus dlicat ds lors que des hypothses doivent tre introduites
dans le calcul : amlioration de limage chez les distributeurs, augmentation du cot de sortie
des clients, etc.
Enfin, lapproche dveloppement conduit un surinvestissement informatique vis--vis
des besoins immdiats. Ils concrtisent une stratgie long terme. Une banque sengouffrant
dans la bataille de la fourniture de services bancaires constituerait ainsi une plate-forme
mutualise de distribution de ses produits, pour attaquer plus rapidement ce march. Dans ce
mode, une DSI est amene grer un portefeuille de projets dits Autres Que Construits ,
cest--dire innovants au sens o ils informatisent une fonction qui nexiste pas encore dans
lentreprise. Le business model tant hautement instable, le pilotage ne peut seffectuer que
par limitation des risques, ce qui conduit souvent une approche bocal (ou nursing ),
isolant le projet du reste de lentreprise, dans un premier temps.
17 : Un systme dInformation pour tre comptitif, de Peter Weill et Marianne Broadbent.

18 : Catgorisation introduite par Jean-Pierre Corniou, actuel Prsident du CIGREF dans son ouvrage La socit de la connaissance Ed. Herms.
19 : Return On Investment (terme consacr).
13
A quoi sert une DSI ?

La DSI a pour rle
de dcliner la
stratgie de
lentreprise au plan
informatique.
Aprs avoir analys en dtail plus de cinquante entreprises comprenant plusieurs units, ltude
de Peter Weill et Marianne Braodbent conclut : les bonnes dcisions sur les systmes
dinformation reposent sur une excellente apprhension du contexte stratgique. De plus,
cette apprhension doit tre articule, communique et partage dans lentreprise pour
mettre en vidence la relation entre la stratgie long terme et la capacit de linfrastructure .
Selon nous, cet aspect communication est fondamental si lon est sensible largument que rien
ne peut finalement tre impos par la force.
Le contexte stratgique dun assureur pourra ainsi susciter un fort besoin dans de loutillage de
gestion de la relation client. Ne pas investir serait suicidaire ds lors que tous les concurrents
amliorent sensiblement leur qualit de service perue via ce biais. De tels systmes vont
utiliser, puis progressivement remplacer, dautres systmes plus anciens, que leurs auteurs vont
a priori dfendre. Ce renouvellement permanent doit tre expliqu et apprhend pour limiter les
conflits inhrents au changement.
Btir la stratgie du Systme dInformation et la communiquer

Communiquer cette
stratgie est
fondamental pour
faire adhrer aux
changements
quelle ncessite.
De quoi rverait un dirigeant pour enfin comprendre ce qui peut bien se passer derrire les portes
des salles machines et des bureaux dtudes informatiques ? Probablement dun tableau de
bord structur, contenant des indicateurs varis sur ladquation des systmes aux besoins,
la qualit de service, la capacit de maintenance des systmes, lhistorique des
investissements Lobjet nest pas ici de vous proposer comment btir une telle war room 20,
elle est encore bien hypothtique.
Pour autant, maintenir une architecture globale des systmes, permet dentamer la structure dun
tel tableau de bord. Cette premire tape permettra par la suite dy agrger toutes les
informations susceptibles daider aux dcisions dallocations de ressources. A commencer par
les informations de cot et de qualit de service technique, les plus simples.
Larchitecture du SI
est un calque grce
auquel il est
possible de piloter
collgialement les
projets
informatiques.
Les propositions de projets issues des units oprationnelles seront ainsi confrontes ces
indicateurs. Lide tant de pouvoir rpondre plus facilement et de faon plus juste des
questions comme faut-il plutt installer un nouveau systme pour mes vendeurs ou pour mes
acheteurs ? ou bien dans linfrastructure, un rfrentiel client pour mieux grer la continuit
de ma relation ? Un systme dapprovisionnement automatis et centralis ? Une plate-forme
dacquisition de flux (EDI, Swift...) mutualise ? Le tableau de bord, structur en domaines et
sous-domaines de lentreprise, permet de positionner chaque nouvel investissement vis--vis
des indicateurs de son domaine. On privilgiera, sous rserve des enjeux stratgiques mtier,
les cases rouges , qui peuvent ltre pour diverses raisons : pauvret fonctionnelle (dans
labsolue ou face la concurrence), faible qualit de service, vtust des systmes, etc.
De lautre ct de la hirarchie, larchitecture devient un outil de communication vers les
employs, et les quipes informatiques en particulier. Comme on attend mieux sur le
priphrique parisien ds quun panneau vous informe quil vous reste vingt minutes
poireauter, on se trouve galement mieux lorsque lon se situe par rapport lunivers
informatique de la socit. On finit par y adhrer quelque part.
20 : Les organisations du XXIe sicle, de Marc Lemarignier et Jessica Scale.
14
Crer et promouvoir les ouvrages transverses du SI

Les ouvrages
transverses du SI
peuvent avoir une
utilisation directe,
comme une
comptabilit groupe,
ou indirecte, comme
un rfrentiel mtier
Pas douvrage
transverse sans
proposition de
valeur perceptible
pour les projets.
Les services informatiques transversaux se sont longtemps limits aux centres dexploitation et
aux services techniques (poste de travail, rseau, firewall). Lvolution des technologies et de
la standardisation permet de proposer des services applicatifs transverses. A commencer par les
ERP : ressources humaines, achats, comptabilit. Ces services ont une utilisation directe, ce qui
nest pas le cas de certaines fonctions applicatives dinfrastructure , qui bien que
fondamentales, nont quune utilisation indirecte : par exemple, les rfrentiels (utilisateurs, tiers,
et produits essentiellement), ou les diffrents niveaux possibles de plate-forme employs - plateforme clients, plate-forme fournisseurs, ou plate-forme partenaires que nous dtaillerons plus
loin.
Ces ouvrages sont clairement de la responsabilit des DSI, qui doivent galement en assurer la
promotion et le support auprs des projets. Offrir un service attrayant est le seul moyen dviter
lchec de ce type dinitiatives, souvent juges lourdes et complexes par les projets, qui prfrent
travailler indpendamment, loin des usines gaz . Les chantiers transverses doivent
proposer une valeur perceptible pour les projets et tre accessibles simplement.
Insuffler et contrler les orientations des projets

Enfin, loin de vouloir contrler tout ce qui est ralis dans le SI, ce qui est totalement vain, il faut
nanmoins se donner les moyens dinsuffler et de contrler les principaux partis pris
architecturaux des projets. Quils soient de dimension fonctionnelle (quel dcoupage de
domaines ? quelle utilisation des ouvrages transverses ? quelle mthodologie de conception ?)
ou bien de dimension technique (mthodologies danalyse, de dveloppement, de test et
dintgration, architecture, standards technologiques).
Les normes
dinteroprabilit
sectorielles jouent
un rle de plus en
plus important dans
les entreprises, en
imposant des
schmas
fonctionnels et
techniques aux
activits les plus
tournes vers
lextrieur.
Grer linteraction de lentreprise avec les organismes de

standardisation du secteur
Une consquence de la globalisation est laugmentation importante du nombre de transactions
dnoues lectroniquement. Tous les secteurs ont aujourdhui besoin dorganismes de
standardisation qui dfinissent les normes dinteroprabilit pour ces transactions lectroniques.
Les ralisations de Swift dans la finance, de lITU dans le monde des tlcommunications ou de
lUN/CEFACT dans lindustrie, sont des exemples significatifs de limportance de ces
consortiums. Pour une grande entreprise, il est fondamental dy tre reprsente, dune part pour
recueillir les meilleures informations sur les normes actuelles et venir, mais aussi pour influer
sur certains choix dans ces normes.
En disposant dune comptence importante sur ces aspects, la DSI renforce galement sa
lgitimit auprs des units oprationnelles.
La DSI, une SSII comme les autres ?

Pour justifier sa
primaut sur les
projets
informatiques, la
DSI doit diffrencier
ses comptences
vis--vis des offres
de services
extrieures
Quest-ce qui diffrencie un chef de projet, un concepteur, un dveloppeur, un support

exploitation issu de la DSI de son homologue de SSII ? La valeur cre par linternalisation de
telles ressources nest pas toujours vidente dterminer.
Pourtant, les missions de la DSI que nous voquions, savoir btir la stratgie du SI et la
communiquer, crer et promouvoir les ouvrages transverses du SI, insuffler et contrler les
orientations des projets, ou grer linteraction de lentreprises avec les organismes de
standardisation du secteur, sont des missions de longue haleine, inscrire dans une continuit.
15
Deuxime point essentiel, la ncessaire ouverture des DSI vers lextrieur, au-del de la trop
traditionnelle dualit Matre duvre/Matre dOuvrage hrite du btiment. En particulier,
comment vont sorganiser les missions durbanisme ou de construction de systmes transverses
impactant de nombreux processus existants ? Comme lvoque Franois Tabourot, lapport des
Directions Mtier est alors fondamental. Une dmarche durbanisme centre sur la loptimisation
du rapport cot/qualit du SI peut la limite tre mene par la DSI seule.
Matriser une
mthodologie de
construction des
projets informatique
est un pr-requis
cette comptitivit.
Un bureau
darchitecture, o
sigent fonctionnels
et techniques, peut
assumer une
mission de gardien
du temple.
Une dmarche durbanisme dans la dure doit modifier plus profondment les manires de faire
existantes dans lentreprise, pour que tout nouveau projet sintgre dans les plans . Ceci ne
peut tre le fait unique dune cellule imposant des contraintes aux projets (en avaient-ils vraiment
besoin ?), mais bien la matrise diffuse dune mthodologie, cest--dire une manire
commune daborder les projets : conception par les processus, modlisation, architecture
dintgration dans le SI, etc. En somme, on urbanise plus par le bas que par le haut, ce qui
signifie finalement que lurbanisme cest de la formation avant tout.
Au chapitre du comment , la solution unique nexiste pas. Dans Urbanisation du business et
des SI, Grard Jean introduit par exemple une matrise douvrage stratgique , manation
trs jacobine et mtier , destine dessiner les plans du SI long terme. Pourquoi pas ?
Ou pourquoi pas une DSI Groupe runissant un Comit SI avec les directions mtier ? Le
seul point important est de parvenir largir la rflexion Systme dinformation au-del du
cercle des experts techniques.
Compte tenu du caractre oprationnel de certaines missions, dont la mise au point et la
diffusion dune mthodologie projet de bout en bout, un bureau darchitecture permanent peut
tre une rponse ces sujets.
Une activit de haute prcision

Tout lart de la
mthodologie est de
se positionner en
facilitateur plus
quen commissariat
au plan .
Il faut tre trs vigilant aux limites de la centralisation et la ncessaire subsidiarit des quipes
projet. Imposer des structures trop contraignantes cre les conditions mmes de la
subversion. Ainsi, maintenir une architecture globale ne signifie pas imposer aux projets des
lourdeurs administratives supplmentaires, en leur infligeant divers dossiers darchitecture, mais
au contraire en leur apportant un soutien. Cest la vieille histoire du client/serveur, o un prtexte
technologique a permis de dcentraliser les projets, trop longtemps soumis au joug de
linformatique centrale ! Mais ce qui a t gagn en rapidit a t immdiatement, et pour
longtemps, perdu au niveau de linteroprabilit, donc au dtriment de lagilit du SI.
De plus, dans certains grands groupes, plusieurs structures de DSI adosses aux diffrents
mtiers cohabitent. Dans les entreprises o le besoin de synergies entre ces mtiers augmente,
des DSI Groupe ont merg. Le partage des prrogatives entre ces acteurs nest gnralement
pas simple. Car chacun dfendant son niveau de transversalit, il arrive que les champs
interfrent. Entre annuaire groupe et annuaire branche, entre eProcurement groupe et solution
dachats locale, il est souvent difficile de trancher entre le plus global, mais aussi le plus long et
le plus cher, et le moins global, mais aussi le plus rapide et rentable court terme. DSI et DSIG
sont probablement condamnes vivre en comptition, selon les axes de dveloppement plus
ou moins long terme promus par la Direction.
16
Conclusion
Pour assurer ces diffrentes missions, les entreprises auront besoin de mettre en place un
Bureau dArchitecture du Systme dInformation, cellule ddie rassemblant des
comptences fonctionnelles et techniques, et dont le rle sera :
de dresser les plans globaux du SI et de ses frontires immdiates, et les
communiquer,
de faire appliquer des normes durbanisme et dinteroprabilit au niveau des projets,
en promouvant une mthodologie projet de bout en bout,
de promouvoir oprationnellement les ouvrages transversaux dinfrastructure,
de recueillir les standards dinteroprabilit du secteur dans les consortiums ad-hoc,
et promouvoir leurs extensions souhaites dans le cadre de lactivit de lentreprise.
Le Bureau dArchitecture ne doit pas se transformer en commissariat au plan, Kremlinis dans
une tour divoire bien labri des projets. Il doit au contraire accueillir, valoriser et diffuser les
comptences issues des lignes mtier, do provient lessentiel de linnovation. Cest une
communaut, un ordre, plus quune structure part entire.
17
III. Etat de lart des principes darchitecture

Architecture Art
de concevoir et de
construire un
btiment selon des
partis esthtiques et
des rgles
techniques
dtermins
(ditions Larousse)
Dans le domaine de lInformatique comme dans celui du Btiment, larchitecture a ses coles,
ses styles, ses courants Mais linformatique est une science encore jeune, elle a ainsi vu se
succder en quelques dcennies plusieurs mthodologies darchitecture, quil sagisse de
larchitecture logicielle ou de larchitecture de SI
Si dans le domaine de larchitecture logicielle un consensus sest cr ces dernires annes
autour du paradigme objet et des mthodologies bases sur UML21 (Unified Process ou eXtreme
Programming notamment), en revanche dans le domaine de larchitecture de SI aucune
mthodologie na russi saffirmer avec succs : force est de constater que ces mthodologies
se sont le plus souvent limites des projets spcifiques sans parvenir se gnraliser
lchelle du SI.
Cest pour mieux estimer la difficult dfinir et prenniser des principes darchitecture de niveau
SI que nous proposons ici un tat de lart critique des principales mthodologies darchitecture,
de larchitecture logicielle larchitecture de SI. Lanalyse des russites et des checs nous
permettra dune part de modrer nos prtentions - il nexiste trs certainement pas de
mthodologie unique darchitecture, la ntre ne faisant pas exception -, et dautre part, de justifier
les principes fondateurs de la dmarche darchitecture de SI que nous proposons dans cette
ouvrage.
LArchitecture Logicielle
Larchitecture
logicielle se
consacre
architecturer et
concevoir le code
dune application
partir de ses
spcifications
fonctionnelles.
Larchitecture de SI
se consacre
architecturer et
intgrer un
ensemble
dapplications et de
rfrentiels partir
de spcifications
fonctionnelles
dfinies au niveau
plus global du SI.
Larchitecture logicielle est un domaine dans lequel sest panoui au cours des dix dernires
annes le paradigme objet ainsi que les langages et mthodologies associs (UML, xUP, DesignPatterns, XP). Ltat de lart en la matire est maintenant relativement stable, et les
mthodologies dingnierie logicielle dignes des mthodologies de production industrielle
Mais pourquoi consacrer un chapitre larchitecture logicielle dans un livre blanc consacr
larchitecture de SI ? Pourquoi sintresser un domaine qui sadresse a priori plutt aux
quipes de dveloppement et pour lequel il existe ce jour une littrature abondante ?
Cest prcisment parce quil sagit dun domaine darchitecture dans lequel une mthodologie
sest affirme avec succs que nous estimons utile de nous y attarder quelques instants, sans
pour autant vouloir faire un nime ouvrage sur UML/UP Nous le verrons dans le chapitre
suivant, les mthodologies darchitecture de SI pchent par manque de pragmatisme, par la
croyance illusoire aux dmarches top-down , et il nous apparat important de souligner en
quoi les mthodologies darchitecture logicielle bases sur le paradigme objet se dmarquent de
ces approches.
21 : Unified Modeling Langage.
18
UML
Positionnement
Labstraction est la
capacit ne voir
que lessentiel dun
problme ; on
parlera de niveau
dabstraction
suivant le niveau de
maille de lanalyse
du problme.
Lencapsulation
consiste ne
sintresser qu
linterface du
systme et
masquer les
mcanismes
internes.
Les langages objet et les mthodologies orientes objet (OO) sont aujourdhui un standard
incontournable dans le domaine de lingnierie logicielle, les deux piliers du paradigme objet que
sont labstraction et lencapsulation tant particulirement adapts la dmarche danalyse et
de conception de systmes logiciels.
Les premiers langages objet sont apparus au milieu des annes 80 (SmallTalk, Eiffel) et les
premires mthodes danalyse OO sont quant elles apparues au dbut des annes 90, poque
laquelle on dnombrait plusieurs dizaines de mthodologies OO. La concentration sest
acclre vers 1995, par la stabilisation autour de trois mthodes (OOM, OMT, OOSE) puis par
la fusion en 1997 de ces mthodes dans un langage unique, UML, sous la coupe de lOMG22.
En terme danalyse et de modlisation objet, UML est aujourdhui un standard incontournable,
stabilis, industriel (pris en charge par la plupart des outils de modlisation et de
dveloppement). Au del des matrises doeuvre, UML est galement de plus en plus utilis par
les matrises douvrage pour spcifier fonctionnellement les cas dutilisation dune application,
pour modliser les processus mtier au niveau SI23
A travers les diffrents cas dusage possibles, UML reste un langage formel de modlisation
(bas sur un mta-modle, un formalisme rigoureux), mais nest ni une mthodologie (on peut
trs bien adopter par exemple une mthodologie OMT en utilisant le formalisme UML), ni un
processus de dveloppement qui dfinit les tapes du processus, les acteurs, la dmarche (UP,
RUP24). En revanche, UML cadre lanalyse en proposant une dmarche de modlisation base
sur llaboration itrative de modles.
La dmarche de modlisation UML

Le principe dUML, et ce qui en fait sa force, est de reprsenter un systme par un ensemble
limit de modles et de cadrer lanalyse du systme en proposant :
des niveaux dabstraction diffrents suivant les modles, pour matriser la
complexit du systme : modles de use-case, modle danalyse, modle de
conception
des diffrentes vues complmentaires dun systme (diagrammes statiques,
dynamiques), pour guider lutilisation de concepts objet.
Nous ne dtaillons pas ici le dtail de la dmarche de modlisation, le formalisme UML, ou les
modles, que le lecteur pourra trouver dans les nombreux ouvrages existants sur le sujet
Cependant dans le cadre dune comparaison au domaine de larchitecture de SI, il est important
de retenir que cette dmarche repose sur trois piliers :
22 : Open Management Group (www.omg.org). LOMG a notamment normalis CORBA et MDA.

23 : Cf. Architecture de SI plus loin.
24 : Rational Unified Process (Rational Software).
19
1. La dmarche est itrative et incrmentale : le systme est construit et valid par

tapes. Les modles sont labors de plus en plus finement, par itrations
successives et allers-retours, en sappuyant sur des niveaux dabstraction
diffrents et de plus en plus fins :
Les trois piliers

fondateurs de toute
dmarche de
modlisation base
sur UML sont
litration en zooms
successifs
(abstraction), le
pilotage par les usecases, et une
rflexion
architecturale trs
en amont.
La recueil et la formalisation des besoins : diagramme de use-cases,

diagrammes dactivits, spcification dtaille des diffrents scnarios de
chaque use-case sous forme de diagramme de squence
Lanalyse du domaine : identification des objets mtiers, associations entre
objets On tablit ici le MCD25 objet de lapplication.
Lanalyse logicielle : modlisation des principaux mcanismes logiciels,
identification des classes dinterface/contrle/entits, diagrammes de
squence et de collaboration entre ces lments pour chaque scnario dun
cas dutilisation
La conception : dtail des rouages dimplmentation logiciels, en sappuyant
par exemple sur un certain nombre de patterns26 (Design-Patterns [12],
Architectural Patterns [13]...), qui proposent des manires de faire cl en
main : Pattern Faade lorsque lapplication doit utiliser un sousensemble restreint de services dun systme complexe, Pattern Broker
pour dlguer linvocation de plusieurs services un objet ddi
2. La dmarche est pilote par les Use-Cases : ce sont eux qui guident llaboration
des modles ; la recueil des besoins principaux du systme est le point de dpart
de la dmarche, et les modles voluent conjointement avec lenrichissement du
modle des cas dutilisation.
Au del de lanalyse et de la conception, cest lensemble du processus de
dveloppement qui est pilot par les use-cases, comme lillustre le schma suivant :
Figure 1 : UML, un ensemble de modles pilots par les cas dutilisation

25 : Modle Conceptuel de Donnes.
26 : www.patternsdepot.com,www.cs.wustl.edu/~schmidt/patterns.html,www.posa.uci.edu, hillside.net/patterns...
20
3. La dmarche est centre sur larchitecture : larchitecture est la cl de vote de

la dmarche, elle est garante de la bonne implmentation des Use-Case, des
objectifs du projet (qualit, cots, interoprabilit, rutilisabilit), elle permet
didentifier les risques, et de justifier les choix.
Selon P. Kruchten27, larchitecture logicielle se reprsente selon 4+1
vues :
4 vues pour
reprsenter
larchitecture
logicielle selon
langle de vue des
diffrents acteurs.
+ 1 vue use case
qui les pilote.
Vue Logique : elle se concentre sur la modlisation des principaux lments

darchitecture et mcanismes logiciels, la dfinition des lments du domaine
(objets mtier, diagrammes dtats de ces objets). Elle comprend en
particulier les modles danalyse et de conception du systme, cest la vue
des quipes de conception et dveloppement.
Vue Composants (ou vue Implmentation) : elle permet didentifier les
modules (composants logiciels) qui implmentent les lments dfinis dans
la vue logique, de les regrouper en composants logiciels, didentifier les
dpendances dintgration entre ces composants ; cest la vue des quipes
dintgration.
Vue Processus : en environnement multi-tches, cette vue de larchitecture
permet de dfinir les processus, la coordination et la synchronisation des
processus, les threads dexcution Cette vue est optionnelle et nest utile
que dans le cas darchitectures complexes multi-tches.
Vue Dploiement : elle prcise larchitecture de production (ressources
matrielles, implantation des composants, pilotage) Cette vue permettra
par exemple de sassurer que lapplication rpond aux contraintes de
dploiement, aux exigences de qualit de service (monte en charge, temps
de rponse, haute-disponibilit) et sintgre aux infrastructures de
supervision, etc.
Vue Use-Cases (vue +1 ) : elle se concentre sur un sous-ensemble des
cas dutilisation qui ont une influence significative sur larchitecture du
systme. Ces use-cases structurants permettent didentifier les
fonctionnalits et contraintes importantes, les risques majeurs de
larchitecture, ce sont eux qui guident llaboration des quatre autres vues de
larchitecture, de la conception la mise en production de lapplication.
Figure 2: Vues de larchitecture logicielle selon P. Kruchten
27 : The 4+1 view model of software architecture , IEEE 1995 Ce modle a servi de rfrence pour lensemble des mthodologies et processus bass sur
UML.
21
UP, un processus gnrique de dveloppement

A ce stade, nous ne parlons pas encore de processus dingnierie logicielle : comment mettre
en uvre cette dmarche de modlisation au sein dun projet ? Quels sont les acteurs, les
activits, les documents changs, les phases et leurs livrables ? Cest prcisment le but des
mthodologies de dveloppement drives de UP de proposer une dmarche projet de bout en
bout, de la phase de recueil des besoins la mise en production de lapplication.
Sans vouloir dtailler UP ou lun de ses processus drivs comme RUP, retenons quil sagit dun
processus se basant sur les trois piliers prcits (dmarche itrative, pilote par les use-cases,
et centre sur larchitecture) et proposant un dcoupage du projet en quatre phases :
. La phase Cration , dont le but est de prsenter un certain nombre dlments
qui permettront de dcider ou non de lopportunit du projet : expression des
besoins (principaux use-cases), bauche grossire et provisoire de larchitecture,
organisation ncessaire, estimation des cots de dveloppement et du ROI,
recensement des principaux risques (organisationnels, techniques) ;
UP, un processus
de dveloppement
unifi qui reprend
les trois piliers de la
dmarche UML et
dcompose le projet
en quatre phases ;
notre mthodologie
darchitecture de SI
reprendra beaucoup
des concepts UP,
notamment
litration.
. La phase Elaboration qui va prciser la plupart des Use-Cases, la dfinition

de larchitecture de rfrence du systme, un plan projet dtaill pour la finalisation
du projet. En sortie de cette phase, on aura ralis un prototype qui aura permis de
valider les grands choix architecturaux et de traiter les risques majeurs ;
. La phase Construction dans laquelle lapplication va tre dveloppe,
larchitecture stabilise, lensemble des use-cases dfinis, implments et tests.
En sortie de cette phase, on se retrouvera avec une version beta de
lapplication.
. La phase Transition qui consiste effectuer un beta-testing de lapplication
sur un nombre rduit dutilisateurs, de corriger les bugs constats, puis de dployer
entirement lapplication (mise en production, mise sur le march).
UP dfinit galement un certain nombre dactivits (expression de besoins, analyse, conception,
implmentation, tests/dploiement, gestion) que lon va retrouver au sein des diffrentes phases ; les
mthodologies drives dUP (RUP par exemple) sattachent dcrire dans le dtail ces
activits, les acteurs, les documents, le workflow entre acteurs, les livrables en fin dactivit et en
fin de phase
Figure 3: Exemple de
Processus Unifi :
RUP (source :
Rational Software)
22
Conclusion
En ce qui concerne les activits de dveloppement et dingnierie logicielle, un large consensus
sest opr autour du paradigme objet, principalement pour les raisons suivantes :
Utilisation dun langage de modlisation formel et standardis, UML ;
Puissance et adquation du paradigme objet (abstraction, encapsulation) pour les
activits danalyse et de conception qui permet la modlisation des niveaux
successifs dabstraction ;
Dmarche itrative, et non squentielle, entre les phases de recueil des besoins,
analyse, conception, grce notamment aux niveaux dabstraction proposs par les
modles ;
Unification du langage de modlisation UML et des langages de dveloppement
(Java, C#, etc.) autour dun mme paradigme (lobjet), ce qui favorise la continuit
entre les phases de conception et les phases dimplmentation ;
Large utilisation de patterns dans les phases danalyse et de conception (Design
Patterns, Analysis Patterns).
En revanche, lintgration dUML dans les projets de dveloppement passe par une phase non
ngligeable de formation voire dvolution culturelle (passer par exemple du monde Cobol Java
ou de la spcification par lcran la spcification par le processus, ne se font pas sans mal), et
dautre part la mise en place de processus de type UP peut reprsenter un risque fort en
labsence dun socle mthodologique au niveau entreprise. Prudence donc avant de foncer tte
baisse dans lutilisation de RUP au sein dun projet de dveloppement !
23
LArchitecture de SI
Larchitecture de SI se diffrencie de larchitecture logicielle par les concepts manipuls :
modules logiciels, classes, composants pour larchitecture logicielle ; modules applicatifs,
rfrentiels, flux pour larchitecture de SI. En outre, larchitecte logiciel doit concevoir une
architecture implmentant des cas dutilisations centrs sur une application, alors que larchitecte
de SI devra concevoir une architecture implmentant des cas dutilisation transverses
diffrentes applications Si la dmarche est globalement la mme (dfinir la structure dun
systme, ses composants, sa dynamique), architecture logicielle et architecture de SI oprent
cependant des niveaux diffrents de granularit et dabstraction.
Si llment de
rfrence en
architecture
logicielle est la
classe logicielle, elle
devrait tre la
brique applicative
en architecture de
SI Or les
diffrentes
mthodologies
darchitecture de SI
existantes
sattachent
structurer un SI en
classes logicielles !
Et pourtant, de la mme faon quune mthodologie darchitecture logicielle permet daller

jusquaux spcifications des classes logicielles dune application en partant des spcifications
fonctionnelles, les diffrentes mthodologies darchitecture de SI se sont attaches atteindre
les mmes objectifs : permettre, partir des processus mtier de lentreprise, de dcrire les
spcifications techniques dtailles du lensemble du SI, jusquaux interfaces des composants et
aux modles de donnes
Ces mthodologies top-down (du processus au code), se regroupent en deux courants
principaux, lapproche Donnes/Traitements (Zachman, Merise) et lapproche Composants
(RM-ODP, Catalysis) qui adresse plus spcifiquement les architectures des systmes
distribus.
Mais indpendamment de la mthodologie choisie, une dmarche darchitecture commence par
lurbanisation des fonctions mtier (structuration en blocs fonctionnels, changes entre ces
blocs) partir des processus mtier ; cest cette premire phase darchitecture au niveau mtier
de lentreprise (processus, modle dinformation) que nous nous proposons dillustrer avant de
nous concentrer plus prcisment sur les mthodologies darchitecture de SI.
Lurbanisation des fonctions du SI

Si la dfinition des processus mtier de lentreprise et du modle dinformation ne relve pas
explicitement des activits darchitecture mais plutt de celles des fonctionnels, larchitecte devra
en revanche, au niveau mtier, urbaniser les fonctions et processus, structurer le SI en blocs
fonctionnels, garantir son volutivit fonctionnelle Une tche matrisable au niveau dun
primtre fonctionnellement limit (projet, systme autonome...) mais qui devient rapidement
complexe lchelle du SI dentreprise, tant le caractre transverse et tendu des processus
mtier est difficile structurer.
Pour matriser cette complexit, lentreprise peut se baser dune part sur une
mthodologie standard de modlisation des processus (outils, mthodes,
rfrentiels...) partage par les diffrents projets, et dautre part, sur lutilisation de patterns
mtier, apportant des bases de solutions des problmes connus et rfrencs.
Mthodologies de modlisation des processus

Les mthodologies de modlisation des processus mtier sont le plus souvent bases sur des
outils BPM ou BPR28 du march (Mega, Casewise), voire sur des outils de type Visio ou
Word Il nexiste pas de standard en matire de mthodologie, chaque socit de conseil ou
chaque diteur spcialis dans le domaine propose gnralement sa propre mthodologie de
modlisation, quelle soit base sur un formalisme UML ou un formalisme propritaire
28 : Resp. Business Process Modeling, Business Process Re-engineering.
24
Quil sagisse de
mthodologies de
modlisation de
processus ou de
patterns mtier, les
initiatives qui
russissent sont
celles pousses par
les organismes
sectoriels Un
exemple parmi tant
dautres, la course
de ebXML le
gnraliste aprs
RosettaNet le
pragmatique
Notons en revanche linitiative UMM29 en cours de gestation au sein de lUN/CEFACT, dont

lobjectif est de fournir une mthodologie standard base sur UML pour la modlisation des
processus mtier entre une entreprise et ses partenaires ; cette mthodologie rsulte de la fusion
de mthodologies issues dorganisations verticales comme ITU, TMForum, RosettaNet, et a t
adopte par diffrents organismes horizontaux comme GCI (Global Commerce Initiative), X12
pour lEDI, ebXML, et par certains organismes verticaux comme SWIFT pour la finance. Cette
mthodologie nest pas encore stabilise, mais esprons que le fait quelle soit guide et adopte
par des initiatives verticales soit un gage de succs et de prennit.
Patterns mtier
Les patterns mtier utiliss pour la structuration des processus, lurbanisation des fonctions, ou
la dfinition dun modle dinformation, sont gnralement issus dinitiatives verticales La
raison en est simple : qui mieux quun consortium doprateurs tlcoms peut dfinir les rgles
durbanisation du mtier dun oprateur ? Certainement pas des initiatives horizontales comme
ebXML, OAG...
Plusieurs initiatives verticales ont ainsi propos avec succs des patterns, frameworks ou
modles dinformation. Citons parmi les plus connus :
TOM ou NGOSS dans le domaine des tlcommunications (voir encadr ci-aprs) ;
RosettaNet dans le domaine du Supply Chain Management (SCM) ; RosettaNet est
un consortium de 350 compagnies, principalement des quipementiers de matriel
informatique et lectronique, qui a russi faire adopter par lensemble de
lindustrie un ensemble de processus collaboratifs, un dictionnaire de donnes et de
messages, (interoprabilit smantique), une infrastructure de communication
(interoprabilit technique)
TOM (Telecom Operations Map) est un framework pour la dfinition des processus mtier
oprationnels dun oprateur. Propos par le Telemanagement Forum dans le cadre du modle
NGOSS (Next Generation Operation Systems Support), TOM permet de structurer les processus
oprationnels centrs sur le client de loprateur en trois catgories verticales : Fulfillment
(capacit abonner le client au service), Assurance (capacit fournir le service au
client), Billing (facturation des services au client). Pour chaque processus de ces catgories
verticales, TOM propose un modle dimplmentation end-to-end pour les fonctions
horizontales de Customer Care, Service Development, Network Management, en dtaillant les
services offerts par chaque module, les enchanements et interactions entre ces services
La figure suivante montre dune part les principaux modules fonctionnels du modle TOM, et
illustre comment le modle peut aider la structuration dun processus end-to-end de
facturation impliquant loprateur et des Service Providers externes.
29 : Unified Modeling Methodology.
25
Figure 4: Le modle TOM et un exemple durbanisation dun processus de facturation

TOM volue actuellement vers eTOM, extension de TOM lensemble des processus dun Service
Provider (ASP, fournisseur de contenu 3G) eTOM ne se limite pas aux processus oprationnels
dun oprateur mais fournit un cadre pour lensemble des processus dune entreprise (gestion de
produit, stratgie, RH...), impliquant lensemble des acteurs externes lentreprise : clients,
partenaires, fournisseurs... Un modle en cours de maturation qui, avant dtre applicable
lensemble des entreprises, devra tre prouv par les futurs acteurs du 3G Patience donc !
26
Pour larchitecte, structurer son architecture mtier en sappuyant sur ce type de patterns va lui
permettre :
De disposer dune vision transverse de lorchestration des processus de
lentreprise, lui permettant de proposer des schmas durbanisme pertinents,
De favoriser linteroprabilit entre lentreprise et ses partenaires (processus,
smantique des messages...),
De dfinir les formats pivots entre blocs fonctionnels du SI (par exemple, utiliser
xCBL comme format dchange entre les applicatifs de gestion des stocks),
De favoriser la progicialisation de certains applicatifs, par intgration de
progiciels spcialiss de faon standardise sur certaines fonctionnalits (ex. :
Operation Support Systems pour les oprateurs).
Lentreprise aura donc tout intrt utiliser au maximum ce genre de patterns lorsquils existent,
voire simpliquer dans des initiatives sectorielles de standardisation.
Architecturer le SI : lapproche Donnes/Traitements

Les premires mthodes danalyse de SI sont apparues au dbut des annes 70, avec la monte
en puissance des applications de gestion sur systmes centraux ; on parlait alors des mthodes
analytiques (Corig, Warnier) qui consistaient dcomposer le SI de faon atomique avec un trs
faible niveau dinteraction entre les fonctions du systme : indpendance des traitements, des
donnes
Au dbut des annes 80, ces mthodes ont volu vers lapproche systmique, qui considre le
SI comme un tout cohrent avec un niveau plus lev dinteractions entre les fonctions du
systme. Le SI y est vu comme un systme dynamique et interactif, constitu dun ensemble de
traitements oprant sur des donnes en entre et restituant des donnes en sortie (traitement
dun bon de commande, dition de facture) : cest lapparition des mthodes danalyse de SI
orientes Donnes/Traitements , comme Zachman ou Merise en France
Lapproche
Donnes/Traitements centre
lanalyse dun
problme sur la
donne manipule.
Cette approche structure lanalyse fonctionnelle dun systme en sparant distinctement le

quoi (quelles sont les donnes manipules ?) du comment (quels traitements sont
raliss sur ces donnes ?). Tout au long de la phase danalyse, le problme sera dcompos
squentiellement en fonctions, sous-fonctions, jusquaux traitements unitaires, en gardant
continuellement cette dualit Donnes/Traitements , et en modlisant exhaustivement les
donnes et les traitements.
Le premier framework darchitecture de SI dentreprise bas sur lapproche Donnes/Traitements fut
propos par Zachman30 au dbut des annes 80 : il sagit dun cadre unifi darchitecture qui stend de
la modlisation mtier larchitecture de production en passant par le dveloppement logiciel.
Ce framework est encore utilis de nos jours dans les pays anglo-saxons et intgr de
nombreux outils CASE31 (Casewise, Popkin Software, Visible Systems...).
30 : www.zifa.com.
31 : Computer-Aided Sofware Engineering.
27
Le Framework Zachman se reprsente de faon matricielle en six colonnes et cinq lignes :

Les colonnes adressent les aspects de lentreprise : Quoi (que traite-t-on),
Comment (comment traite-t-on), O (aspects gographiques), Qui, Quand,
Comment (aspects organisationnels),
Les lignes adressent les vues selon les diffrents acteurs de lentreprise : les
enjeux stratgiques, puis le modle mtier, le modle fonctionnel SI, les modles
conceptuels et physiques darchitecture
Le framework
Zachman : un cadre
darchitecture
centr sur la
donne et associ
une dmarche
squentielle qui part
des processus
mtier pour arriver
jusqu
limplmentation
physique des
systmes
A chaque cellule de la matrice sont associs des documents formaliss

darchitecture; par exemple, le formalisme Entits/Associations sera utilis pour
Modle Conceptuel de Donnes de la cellule Donnes/Conception .
La figure suivante montre une reprsentation partielle de ce framework (les colonnes Qui,
Quand, et les aspects organisationnels ne sont pas reprsentes) :
Figure 5 : Zachman Enterprise Architecture Framework
28
Cette reprsentation matricielle du SI fait certes le bonheur des thoriciens mais dans la
pratique, elle suppose une dmarche squentielle, de la dfinition des processus au
dveloppement des applications du SI : analyse fonctionnelle, puis laboration exhaustive des
modles conceptuels/logiques/physiques des donnes et traitements, pour aboutir aux phases
dimplmentation. A chaque ligne est associe une modlisation exhaustive des donnes
(le quoi ), des traitements (le comment ), de limplantation des donnes et traitements
(le o ).
Zachman et Merise
sont des mthodes
qui modlisent
exhaustivement
lensemble des
Donnes et
Traitements dun
systme.
Cette absence
dabstraction les
limite un
primtre beaucoup
plus restreint que le
SI.
Cette dmarche top-down est ralisable en thorie avec un gigantesque outil CASE mais
irraliste sur le plan pratique dans un environnement dentreprise, o les processus mtier sont
transverses plusieurs applications : une modification du processus mtier au niveau de la vue
fonctionnelle du modle devra se traduire en un changement dimplmentation logicielle au
niveau dun ensemble dapplications htrognes (modles physiques de donnes, procdures
stockes, scripts PL/SQL, transactions CICS), le plus souvent maintenues par des quipes
projets diffrentes
Et pourtant, les mthodes Zachman et Merise ont su saffirmer pendant prs de deux dcennies ! En y
regardant de plus prs, cest en fait dans le domaine du dveloppement dapplications quont
effectivement perc ces mthodes et non dans le domaine de larchitecture de SI : Merise par
exemple fut largement utilis - bien avant UML - pour lanalyse et la conception dapplications
client-serveur, ou dapplications mainframe (3270, CICS)... En revanche, une mthodologie
darchitecture de type Zachman/Merise au niveau SI suppose de dfinir exhaustivement des
modles conceptuels et physiques de donnes/traitements pour lensemble des applications du
SI, avec toutes les contraintes techniques et organisationnelles qui en dcoulent
Le flop de Merise OO
Dans le domaine de lingnierie logicielle, le paradigme Donnes/Traitements et les mthodes
Merise furent utilises bien avant UML. Face aux apports du paradigme objet (abstraction,
encapsulation), Merise fut rapidement abandonne, non sans un dernier sursaut, la mthode OOM
(Object Oriented Merise) : il sagissait grossirement de renommer traitement en objet , sans
remettre en cause les fondations de la dmarche, centre sur la donne ! Cette mthode est ainsi
reste bien labri, dans les rayons des bibliothques
Quant au paradigme Donnes/Traitements , il nest pas en lui-mme antinomique avec une

mthodologie darchitecture de SI : on peut trs bien structurer un SI en traitements sans
pour autant tomber dans les travers de lexhaustivit de modlisation et du syndrome topdown , il suffira de savoir se limiter des niveaux de modlisation suffisamment levs, qui se
concentrent sur lessentiel des fonctionnalits. En outre, ce genre dapproche pourra mme
permettre la re-utilisation des traitements entre applications !
Les travers des mthodes Zachman/Merise sont donc principalement une modlisation trop
exhaustive des donnes/traitements, utopique lchelle du SI ; ainsi quune croyance trop forte
dans les dmarches squentielles, plutt que le paradigme Donnes/Traitements . Ces
mthodes ont chou lchelle du SI pour ces deux raisons, et par consquent, elles sont
accuses de faon un peu trop rapide de ne pas permettre la mutualisation des traitements au
niveau du SI : cest ce point que devait rsoudre la trs prometteuse approche Composants
29
Architecturer le SI : lapproche Composants

Avec la monte des mthodologies et langages OO au dbut des annes 90, puis lapparition
des premiers ORB32, un nouveau courant darchitecture de SI est apparu au milieu des annes
90 : les architectures de systmes distribus.
Surfant sur la vague

objet, un nouveau
courant
darchitecture est
apparu autour des
systmes distribus
: de Corba aux
serveurs de
composants.
Systmes Distribus et Composants Ne confondons pas !

Un systme distribu est un systme constitu dune plate-forme dexcution (ORB), proposant
des services techniques des composants (accs distants, persistance, transactions, scurit,
nommage...). Les composants sont rpartis sur cette plate-forme, ils implmentent la logique
mtier et exposent des services aux autres composants, dautres applications
En dehors des environnements spcifiques ORB ou serveurs dapplications J2EE/.Net, on parle
galement de composants pour dsigner plus gnralement un module autonome exposant des
services aux autres modules, sans considrer lenvironnement dexcution de ces composants ;
le composant est caractris par ses interfaces, son comportement dynamique, son modle de
donnes linterface Une transaction CICS unitaire ou un Web Service de type effectuer un
virement bancaire sont ce titre tous deux des composants.
Ce courant sest accompagn de plusieurs mthodologies darchitecture, dont les objectifs

restaient comparables aux initiatives Zachmaniennes, savoir fournir un cadre unifi pour
larchitecture de SI (du mtier linfrastructure technique) mais sadressant cette fois-ci aux
systmes distribus.
Le cadre normatif en la matire est le modle RM-ODP33 normalis conjointement par ISO/ITU
au milieu des annes 90. Cest un modle qui fut labor sous linfluence du framework Zachman
(on y retrouve notamment cinq vues darchitecture suivant les acteurs) mais guid par le
paradigme OO et non par le paradigme Donnes/Traitements.
Dans les grandes lignes, RM-ODP fournit un cadre darchitecture bas sur cinq vues du systme :
La vue Entreprise, qui dcrit les activits mtier du systme,
La vue Information, qui dfinit linformation traite par le systme et la faon dont
elle est traite par les diffrents composants,
La vue Traitement, qui spcifie fonctionnellement les traitements effectus par les
diffrents composants
La vue Ingnierie qui dcrit les mcanismes logiciels permettant la distribution des
composants et leur excution sur les plates-formes dexcution (ORB, serveur
dapplications),
La vue Technologie qui dfinit les technologies matrielles et logicielles utilises
pour linfrastructure dexcution, leur configuration
Il est noter que la vue Traitement sattache architecturer le systme en composants tout
en faisant abstraction des mcanismes techniques de la plate-forme dexcution ; en ce sens,
elle nest pas spcifique aux systmes distribus, la diffrence des deux dernires vues. Dans
labsolu et en dehors du contexte RM-ODP, cette vue Traitement pourrait tre utilise pour
architecturer un SI base de composants qui seraient des transactions CICS, des services
Web
32 : ORB : Object Request Broker, infrastructure dexcution dobjets rpartis, cf. norme CORBA de lOMG.
33 : Reference Model for Open Distributed Processing.
30
RM-ODP est un
modle de
rfrence partir
duquel vont se
driver des
mthodologies
darchitecture pour
les systmes
distribus.
RM-ODP nest pas une mthodologie, cest un modle de rfrence plutt abscons et rbarbatif
qui utilise un formalisme prcis et peu rpandu dans les entreprises Cest la raison pour
laquelle diffrentes mthodologies darchitecture allges , inspires de ce modle, sont
apparues. Elles utilisent un formalisme connu bas sur UML, comme par exemple Catalysis34, ou
encore des mthodologies labores spcifiquement par et pour certaines grandes entreprises
franaises35.
La figure suivante illustre une des phases de la dmarche Catalysis qui consiste spcifier
fonctionnellement un composant (cf. vue Traitement du modle RM-ODP).
Figure 6: Illustration de la mthode Catalysis pour la spcification dun composant ddi la vente
Les mthodologies
drives de RMODP, tout comme
les mthodologies
Zachman-Merise,
sont des
mthodologies topdown qui supposent
de spcifier dans le
dtail les modles
de tous les niveaux
(fonctionnels,
techniques...)
MDA
MDA (Model Driven Architecture, littralement Architecture guide par les modles), est une
rcente initiative en cours de standardisation lOMG. Lide est de partir des modles du domaine
mtier de lentreprise (au sens UML du terme), pour dfinir des PIM (Platform Indpendant Model),
vision abstraite dun composant mtier. Ce PIM est ensuite driv en diffrents PSM (Platform
Specific Model) en fonction de linfrastructure dexcution : CORBA, EJB, .NET, SOAP
Lobjectif est louable, standardiser par un mta-modle bas sur UML la reprsentation abstraite
dun composant et sa reprsentation technique . Mais cette initiative est encore trop jeune pour
servir de base de nouvelles mthodologies darchitecture : malheureusement, seuls les PSM
CORBA sont aujourdhui dfinis
Mmes causes, mmes checs : tout comme les mthodologies Zachman/Merise, les
mthodologies darchitecture de SI drives de RM-ODP se sont limites des primtres projet
et nont pas russi stendre au niveau SI cause de leur caractre exhaustif (spcifications
dtailles tous les niveaux) et squentiel (top-down) - utopiste au niveau du SI. Pire encore,
les mthodologies drives de RM-ODP supposent que le SI peut tre implment sous la forme
34 : www.catalysis.org.
35 : France Tlcom (Memento Technique N14, www.rd.francetelecom.fr).
31
dun systme distribu tendu ! Do les limites de ces mthodologies pour prendre en compte
les legacy systems , les moniteurs transactionnels autres que les OTM36, les MOM37, les
progiciels intgrs, etc. Car ces systmes doivent tre systmatiquement accds comme des
objets, mais ne le sont pas dans la plupart des cas.
En conclusion, ces mthodologies darchitecture sont intressantes pour des projets spcifiques
btis sur des architectures distribues, mais non applicables au niveau du SI. En revanche,
lapproche consistant au niveau de la vue Traitement structurer son SI en composants,
indpendamment de toute plate-forme dexcution, reste un point fort de ces dmarches.
Bilan et conclusions
Deux cueils ont fait
chouer les
mthodologies
darchitecture
(Zachman, RMODP) lchelle du
SI : dogmatisme et
manque de
modles.
La mthodologie de construction du Systme dInformation nexiste pas encore, mais elle

correspond un besoin criant des grandes entreprises et des entreprises en rseau.
LHistoire nous permet de raliser les causes dchec de ces initiatives, que lon peut synthtiser
en deux principaux griefs :
Le dogmatisme : la croyance dans une dmarche top-down squentielle (de la
stratgie au code) et aux principes de projection automatique entre les niveaux.
Le manque de modles pour faire converger les rflexions. Car en dehors de leurs
spcificits stratgiques, deux banques ou deux oprateurs auront des systmes
qui finalement devront se ressembler, car ils voluent dans les mmes rseaux
dinteroprabilit.
Evitons les erreurs

du pass en
proposant une
mthodologie
darchitecture
pragmatique, base
sur un formalisme
simple et des
patterns.
La mthodologie darchitecture de SI que nous proposons tente de gommer ces deux dfauts par
une emphase particulire sur :
Le pragmatisme :
- une mthode centre sur litration et linteractivit entre fonctionnels et
techniques,
- une rupture assume mais matrise entre architecture gnrale et
conception dtaille,
Le formalisme et les modles :
- Les modles utiles la conception sont identifis, avec une responsabilit
claire, sous un formalisme au standard UML,
- La constitution dun portefeuille de patterns fonctionnels permet de
restreindre le champ des possibilits et de converger vers des solutions
prouves.
36 : OTM : Object Transaction Monitor, moniteur transactionnel objet (utilis dans les architectures ORB).
37 : MOM : Message Oriented Middleware.
32
IV. Les outils de larchitecte

Ce chapitre se propose dexpliciter ce que nous entendons par formalisme pour une
architecture de SI, et dautre part de prciser la notion de modle, ou pattern darchitecture.
Le formalisme de modlisation
Le besoin dun formalisme de modlisation darchitecture
Le chapitre prcdent concluait sur le besoin dun formalisme et de modles adapts la
modlisation darchitecture de SI. Il ne se dgage en effet pas encore de consensus sur ce sujet,
et chaque outil amne gnralement son propre formalisme de modlisation (MEGA, Amarco,
etc.).
Nous proposons dappuyer notre formalisme de modlisation sur UML, qui est le standard
aujourdhui largement accept dans le monde de larchitecture logicielle. Nous avons slectionn
les diagrammes qui nous semblent adapts la modlisation darchitecture de systme
dinformation. Notre approche restant pragmatique, nous avons donc privilgi la clart et lutilit
des modles au respect strict des rgles dUML.
Point de vue et redondance dinformation

Certains diagrammes UML peuvent sembler redondants mais cette redondance fait partie du
formalisme UML. Par exemple, le diagramme de squence et le diagramme de collaboration sont
intimement lis. Il est toutefois intressant de changer de point de vue pour claircir larchitecture
et/ou en faire ressortir une opportunit damlioration.
Chaque diagramme permet de visualiser larchitecture suivant un angle diffrent et permet donc de
dtecter des erreurs ou de proposer des modifications. Par exemple, un diagramme de
collaboration montrera mieux quun diagramme de squence quune brique applicative change de
nombreux flux avec le systme, ce qui poussera peut-tre larchitecte modifier larchitecture afin
de rationaliser les changes.
Note sur les outils de modlisation : plus quun outil, cest lutilisation dun formalisme de
modlisation qui importe. Les exemples de diagramme UML qui suivent, ont t raliss avec
Rational Rose. Il aurait t possible dutiliser dautres outils tels que MEGA, Visio ou TogetherJ.
Les diagrammes fonctionnels

Les quipes fonctionnelles produisent et ont la responsabilit de diagrammes que nous
regrouperons dans un volet fonctionnel :
Diagramme
Diagramme
Diagramme
Diagramme
dorganisation,
de cas dutilisation,
dactivit,
dtat.
33
Diagramme dorganisation
Le diagramme dorganisation nest pas un diagramme UML mais il nous semble trs important
car il nest pas possible de saffranchir de lorganisation dune entreprise pour concevoir son SI.
Le diagramme dorganisation permet de donner une vision gnrale de lorganisation de
lentreprise sur le primtre du projet.
Prenons lexemple de la mise en place dun systme de gestion de production. Les principales
directions utilisatrices de ce systme sont : la direction commerciale, la direction de la production
et la direction des achats. Les autres dpartements tels que les ressources humaines, la finance
et linformatique sont hors primtre pour ce projet car elles nutilisent pas directement le
systme.
Figure 7 : Diagramme dorganisation restreint au primtre projet
Diagramme de cas dutilisation

Un cas dutilisation reprsente une interaction entre un ou des acteur(s) et le systme
dinformation. Il permet dexprimer les services rendus par le systme. Un diagramme de cas
dutilisation regroupe plusieurs cas dutilisation qui ont un fort lien fonctionnel.
Lintrt dun tel diagramme est davoir du sens pour tous les acteurs du projet et notamment les
utilisateurs. La bonne ide des cas dutilisation est de dcrire le systme travers des
interactions avec ses acteurs. On ne se situe pas sur des modles logiques issues de rflexions
thoriques, mais bien sur des modles dutilisation relle, comprhensibles par tous.
34
Voici un exemple de diagramme qui regroupe les principaux cas dutilisation lis la direction
commerciale :
Figure 8 : Diagramme de cas dutilisation lis la direction commerciale
Nous navons considr que les acteurs lis lusage normal du systme et non des acteurs
exceptionnels comme un gestionnaire . La rflexion sur les cas dutilisation doit tre
cohrente avec le primtre du projet. Un travers classique consiste vouloir dcrire trop
finement les cas dutilisation, avec le risque de driver vers le comment au lieu de rester
dans le quoi ce stade.
Diagramme dactivit
Un diagramme dactivit dcrit lenchanement des activits participant la ralisation dun cas
dutilisation (UC pour use-case). Un diagramme dactivit intgre tous les scnarios dexcution
possibles dun cas dutilisation et fait donc apparatre des embranchements, des choix
conditionnels et des rendez-vous.
Le point de vue reste celui de lacteur principal du cas dutilisation et il ne sagit donc pas de
dcrire les activits internes du systme mais bien celle de lacteur.
Ce diagramme permet de dtailler visuellement un cas dutilisation. Tous les cas dutilisation ne
doivent pas obligatoirement tre dcrit par un diagramme dactivit. Par exemple, le
UC Authentification qui est inclus dans les UC Gestion des clients et Gestion des
commandes , na probablement pas besoin dtre dtaill par un diagramme dactivit.
Lexemple suivant dcrit le diagramme dactivit associ au cas dutilisation Nouvelle
commande :
35
Figure 9 : Diagramme dactivit du cas dutilisation Nouvelle commande
Diagramme dtat des objets mtiers

Un diagramme dtat dcrit le cycle de vie dun objet mtier manipul par le systme.
Les objets mtier auxquels larchitecte sintresse sont ceux qui ont un sens pour les quipes
fonctionnelles. On ne cherchera pas deviner les objets internes du systme, et on
sintressera donc ceux exprims par les experts fonctionnels. Pour certains objets mtier,
dtailler le cycle de vie permet denrichir la rflexion, mais il faut bien les choisir. Dans notre
exemple, nous identifions les objets Commande, Client, Ordre de Fabrication, Bon de Livraison,
etc.
Figure 10 : Diagramme dtat de lobjet Commande
36
Les diagrammes applicatifs

Les diagrammes du volet applicatif sont sous la responsabilit de lquipe darchitecture :
Diagramme de briques applicatives,
Diagramme de squence,
Diagramme de collaborations.
Diagramme de briques applicatives

Ce diagramme est utilis pour dcrire le dcoupage systme en briques applicatives.
Il est bas sur un diagramme de classes dUML et utilise un strotype Brique . On appelle
Brique un sous-systme applicatif associ un niveau de dtail donn. Il est possible de
zoomer dans une brique et de montrer les sous-briques qui la constitue.
Voici un exemple de diagramme de briques applicatives :
Figure 11 : Diagramme de briques applicatives
Diagramme de squence
Un diagramme de squence dcrit les interactions entre les acteurs et les briques applicatives
du systme dans le contexte du droulement dun scnario dun cas dutilisation.
Une fois les briques applicatives dfinies, il est possible dexpliciter le droulement des cas
dutilisation sur le systme. Lobjectif est de sassurer que les cas dutilisation sont ralisables
avec notre modle de briques applicatives.
Voici le diagramme associ au cas dutilisation Nouvelle commande pour le cas dune
commande dont tous les articles sont en stock :
37
Figure 12 : Diagramme de squence pour le passage dune nouvelle commande
Diagramme de collaboration
Un diagramme de collaboration reprsente les changes et les mcanismes de coopration
entre les diffrentes briques du systme.
Ce diagramme peut contenir des informations redondantes avec le diagramme de squence.
Dailleurs certains outils permettent un passage presque automatique de lun vers lautre. Son
atout est de prsenter les changes dun point de vue flux, alors que le diagramme de squence
sattache en prsenter le squencement.
Dans notre exemple :
Figure 13 : Diagramme de collaboration
38
Synthse
Volet fonctionnel
Type
Objectifs
Diagramme dorganisation
Conserver une cohrence entre SI et

organisation
Diagramme de cas dutilisation
Dcomposer et regrouper les cas dutilisation

par affinit fonctionnelle
Diagramme dactivit
Zoomer sur les activits ralises dans

certains cas dutilisation
Diagramme dtat
Dcrire les cycles de vie complexes des

principaux objets mtiers
Volet Applicatif
Type
Objectifs
Diagramme de briques applicatives
Prsenter le dcoupage du SI en briques

applicatives
Diagramme de squence
Valider larchitecture en droulant les cas

dutilisation sur les briques applicatives
Diagramme de collaborations
Mettre en vidence les flux quchange une

brique applicative avec le reste du systme.
Nous avons vu que la communication est un des enjeux majeurs de tout projet informatique
denvergure. Lutilisation du formalisme de modlisation graphique que nous venons de dcrire
aide larchitecte tablir un langage commun entre les diffrents acteurs du projet.
39
Des patterns pour structurer la conception

Un pattern est une manire de rsoudre un problme rcurrent, cest un modle. Par exemple,
on utilise le pattern Modle Vue Contrleur (MVC) pour btir des interfaces homme/machine
complexes. Ce pattern impose une sparation entre le Modle IHM (la forme des crans et des
tats), la Vue quil donne sur les donnes, et le Contrleur qui rgit les interactions entre crans.
Cest un standard, aujourdhui incorpor dans la plupart des outils, et qui a contribu
lamlioration notoire de la productivit et de la qualit des dveloppements dIHM.
Le pattern
fonctionnel
sintresse autant
la future
organisation des
utilisateurs du SI,
qu la structure du
SI lui-mme.
En architecture de Systmes dInformation, le pattern aura galement ce rle de structuration. Il

est dautant plus pertinent que le problme pos est nouveau, et donc que le nombre
dinconnues est important. Lapplication dun pattern va conduire rduire le champ des
possibilits.
Le pattern darchitecture sintresse autant lorganisation du SI (son architecture), qu
lorganisation des utilisateurs du SI (nous le verrons plus loin). Mais le lecteur attentif aura ragi
ce stade : beaucoup de dirigeants nous demandent en effet de raliser des Systmes
dInformation indpendants de lorganisation... Cest une pure utopie. Un SI est prcisment au
service dune organisation. Si lon souhaite quil serve les besoins dune organisation diffrente,
on devra soit le modifier, soit avoir prvu en amont ce changement, et payer les cots de cette
flexibilit.
Prenons un exemple simple, le cas de la relation client. Si un SI est organis selon des lignes produits ,
il ne sera pas adapt une gestion transverse du client. Si lorganisation change avec la mise
en place de chargs de clientle multi-produits, il faudra modifier le SI en consquence pour faire
apparatre un outil utile cette nouvelle population dutilisateurs.
Nous le rappelons, les technologies de lInformation sont des technologies au service de
lOrganisation.
Au niveau des patterns, nous distinguerons deux catgories :
Les patterns
techniques
permettent quant
eux de zoomer sur
des problmes
informatiques purs.
les patterns fonctionnels, qui ont un impact sur lorganisation et la structuration du

SI, comme par exemple la notion de Royaume/Emissaire ou de Noyau.
les patterns techniques, qui rsolvent des problmes darchitecture un niveau
de maille plus fin, comme par exemple le pattern Single Sign On ou
Datawarehouse.
Le pattern fonctionnel Royaume-Emissaire

Initialement imagin par les usines de dveloppement logiciel de Microsoft, sous la houlette de
Pat Helland, la notion de Royaume et dEmissaire a t utilise pour dvelopper des systmes
de bases de donnes complexes comme le serveur de messagerie Exchange. Lide repose sur
le constat que tout systme est compos dun cur (le Royaume) et de fonctions ddies la
communication extrieure (lEmissaire), et que ces fonctions gagnent tre spares. Le
royaume ne fait confiance personne, et ne communique quavec son missaire. Lmissaire a
donc la responsabilit de filtrer et transformer les sollicitations extrieures avant de transmettre
son travail au royaume.
Un Royaume pour
le cur de mtier,
un ou des
Emissaires pour les
activits lies au
monde extrieur.
Le pattern Royaume/Emissaire sapplique un niveau Systme dInformation, et il impose une

organisation adapte. Imaginons par exemple, le cas du systme dinformation oprant le fichier
dempreintes ADN national. Ce systme est constitu dun Royaume dont lobjet est la gestion
courante des donnes dempreintes gntiques : ajout et modification dlments dans la base,
recherche multicritres, facturation, etc. LEmissaire du systme aura lui pour rle dassurer que
40
Figure 14 : Pattern Royaume/Emissaire
les requtes utilisateur sont bien conformes la politique dutilisation du systme. Par exemple,
seuls les enquteurs habilits et munis dun mandat spcifique relatif une enqute seront
autoriss par lEmissaire accder au royaume. Dans notre exemple, si le nombre daccs au
fichier est faible, lEmissaire peut mme navoir aucune existence informatique, pour ne se
matrialiser quen du personnel charg de valider les requtes des polices nationales ou
internationales.
Le pattern Royaume/Emissaire est toujours pertinent lorsquun systme a de fortes contraintes
de scurit, mais il lest aussi lorsque ce systme requiert des interactions nombreuses et
varies avec lextrieur.
De manire synthtique, lmissaire contiendra tout lment susceptible de remplir les fonctions
suivantes :
publier les services et processus offerts par canaux, canaux tant pris au sens
large : canaux physiques (Web, mail, fax, tlphone) et logiques (employs,
partenaires, revendeurs...). LEmissaire prend en charge les spcificits des
processus de chaque canal pour les masquer au Royaume.
contrler et habiliter les sollicitations extrieures, vrifier lidentit, la signature,
la confidentialit, la non-rpudiation38, le droit daccs. Cette dernire fonction tant
souvent la plus complexe.
38 : Voir Le Livre Blanc de la Scurit OCTO Technology 2001.
41
rconcilier les visions extrieures et intrieures, car lmissaire aura en sa

possession un certain nombre de donnes de rfrence, dont il diffusera des clichs
vers ces utilisateurs. Par exemple dans le cas dun missaire Catalogue papier
dun Royaume de vente par correspondance , les utilisateurs disposent du
clich des prix en date ddition du catalogue, ceux-ci ont pu varier dans le
Royaume, qui lui, fait rfrence.
LEmissaire
dcharge le
Royaume des
fonctions non
vitales, il exploite
donc des objets
mtier inconnus du
Royaume.
Straight Through
Processing, une
discipline pratique
dans tous les
secteurs dactivit.
Dun point de vue technique, lEmissaire va ncessairement manipuler de nouveaux objets

mtier (voir paragraphe Formalisme de modlisation ), non disponibles dans le Royaume.
Dans notre exemple, il sagira en particulier du dossier de requte, compos de la ou des
requte(s) au fichier et des pices justificatives. LEmissaire utilise le dossier pour filtrer les
requtes, le Royaume ne sintresse quaux requtes elles-mmes.
Enfin, il est gnralement pertinent dutiliser un formalisme pivot unique entre le royaume et
lmissaire (ici les requtes), lmissaire se chargeant des conversions entre ce format et les
diffrents formats de canaux quil gre, dont ceux manuels. XML est bien entendu le choix
technique prfr pour prendre en charge cette smantique.
Le pattern fonctionnel NOYAU

Le noyau est un pattern que nous allons utiliser dans les environnements o le rle du systme
dinformation est dautomatiser des tches volumineuses et impliquant de nombreux systmes.
Cest en particulier le cas dans certains secteurs de la finance, o le Straight Through Processing
(STP), cest--dire la capacit traiter une instruction sans intervention humaine, est
fondamentale. Augmenter le taux de STP de quelques points peut gnrer des gains de
productivit colossaux du fait des volumes traits. Le STP est une problmatique que lon
retrouve plus largement chez les oprateurs tlphoniques (facturation, roaming,
compensation), la logistique dans la distribution ou la fabrication, les systmes

de rservation
Le noyau est donc un routeur dvnements mtier. Quelle diffrence avec un outil EAI me
demanderiez-vous ? La mme quentre SAP et une base de donnes. Le noyau pourra tre
implment laide dun produit EAI, mais cest avant tout une brique fonctionnelle du SI, qui
aura ces utilisateurs (les responsables STP ) et sa logique propre.
Le STP conduit
lautomatisation de
processus
complexes, qui
impose une
intgration de haut
niveau entre
systmes
informatiques.
Prenons lexemple dune problmatique STP chez un conservateur de titres, cest--dire lacteur
responsable de la livraison des produits financiers une fois leur ngociation effectue, et
leur conservation dans un coffre multi-instruments. Le noyau va devoir manipuler les
instructions des clients (ordres dachat ou de vente sur un instrument financier particulier : cash,
valeurs mobilires, drivs, change, etc.), et les router vers le bon destinataire du traitement :
traitement du cash, des valeurs mobilires, du change, etc. Jusquici rien dexceptionnel. La
complexit intervient lorsque les interactions entre ces diffrentes briques de traitement
sintensifient, cest--dire lorsque ltat dun objet mtier A dans une brique X a un impact sur ce
que devrait faire lobjet B dans une brique Y. Elles dpendent trs souvent du statut des objets
dans chacune de ces briques. Par exemple, une instruction titres rgler en dollars va ncessiter
la cration dune instruction de change pour poursuivre son dnouement. Linstruction de change
va suivre son propre processus, et cest au moment o elle va atteindre un statut particulier,
disons contrepartie trouve , que linstruction titre initiale va pouvoir poursuivre son propre
processus. Le noyau devra comprendre lavancement de ces diffrents statuts, pour ragir sur
une transition de statut, en prenant en compte un historique dinstructions lies.
42
Figure 15 : Pattern Noyau

Cet exemple nous illustre les concepts manipuls par le noyau :
le noyau comprend les objets mtier qui le traversent : il a donc un dictionnaire de
ces objets, et il en connat les attributs spcifiques qui vont lui permettre de prendre
des dcisions. Il dfinit la norme de ces attributs, cest--dire lensemble des valeurs
quils peuvent prendre. Dans notre exemple : instruction prise en charge ,
contrle , mise sur les marchs , apparie39 , dnoue sont les
statuts nominaux, auxquels on devra adjoindre des tats lis aux erreurs et aux
annulations ( suspens , annule ).
le noyau notifie ces collatraux des vnements mtier, sur la base dune table de
routage statique ou dynamique
. statique dans le cas o les rgles mtier sappliquent sans que le noyau
naie se souvenir du pass (noyau sans tat)
. dynamique dans le cas o les rgles mtier sappliquent galement sur la foi
du pass. Dans notre exemple il sagira dune base de liens entre instructions
subordonnes.
39 : La contrepartie a t trouve.
43
Pour crer un noyau, il faudra donc sintresser :

au format pivot des objets mtier transverses au SI, et leur transformation vers
les formats supports par les collatraux40,
aux lments smantiques transverses tout le SI, et notamment la notion de
statut,
aux donnes qui doivent persister dans le noyau pour garantir son bon
fonctionnement. Il nest pas rare que le noyau finisse par alimenter tous les
systmes transverses (infocentres facturation, rentabilit, piste daudit, risques,
SLA...), sans pour autant possder cette donne lui-mme.
aux fonctions quil doit prsenter ses utilisateurs : rparation dobjet mtier,
rejeu dobjet mtier, annulation de processus, statistiques, etc.
au caractre actif ou passif : le noyau a-t-il une copie des donnes de processus
prsentes dans les collatraux, copies quil consolide en une vision globale, ou bien
cre-t-il lui-mme du processus inexistant ailleurs et possde-t-il en propre des
donnes de processus ?
Etre trs vigilant sur

le lieu de vie des
processus de
lentreprise :
processus frontoffice, processus
STP de back-office
ou nouveaux
processus
transverses ?
Quelle
responsabilit pour
ces derniers ?
Noyau et Business Process Management (BPM)

Beaucoup a t crit sur le Business Process Management, nouvelle idole technologique
suppose crer des processus dans toute lentreprise. Intressons-nous la ralit des faits. Dans
un Systme dInformation classique, nous allons constater que les processus de vente sont grs
par le SI Front-Office, par exemple un progiciel de Gestion de la Relation Client, tandis que les
processus de back-office sont grs par lERP. Il est des cas moins manichens bien sr, mais
lintrt de lexemple est de montrer que des processus vivent dj dans des parties du SI de
lentreprise. La question se poser en architecture est de savoir si lintgration entre deux
domaines cre du processus supplmentaire ou pas. Et cest loin dtre toujours le cas,
ninventons pas du BPM l o il ny en a pas. Dans ces situations, un noyau statique (sans tat),
voire une intgration point point permettront dassurer linteroprabilit des domaines.
Lorsque lorchestration de fonctions ncessite un tat, comme par exemple le cas de notre noyau
STP financier, nous crons de fait du processus. Ceux-ci peuvent tre du domaine front-office,
donc visibles du client (comme le dclenchement automatique dordre sur atteinte de seuils), ou du
domaine back-office, avec lautomatisation de processus internes (le cas de notre instruction de
change, dun appel de marge automatique, etc.). Ainsi la question fondamentale se poser est de
savoir qui appartiennent les processus que nous crons, cest--dire qui en sera responsable
une fois en production ? Puis comment implmenter ces processus ? Dans mes progiciels mtier,
ou laide dun outil de BPM gnraliste ? Tous les cas se prsentent, mais si les progiciels de
BPM peuvent aider implmenter un noyau, ils sont souvent trop rigides pour grer des processus
dynamiques sans requrir de dveloppement spcifique.
En conclusion, soit nous trouvons des processus mtier cl en main dans des progiciels (vente,
approvisionnement, etc.), soit nous devrons dvelopper du spcifique. Ne croyons pas au mythe
du gestionnaire de processus gnraliste cl en main, mais recherchons plutt des botes outils
de haut niveau auprs de ce type dditeur.
40 : Ici lEAI peut tre un facilitateur.
44
Le pattern fonctionnel Rfrentiel

Dernier pattern fonctionnel, mais non des moindres, le Rfrentiel. Passons rapidement sur
quelques dfinitions : un rfrentiel est un rceptacle de donnes plutt stables, et utilises par
au moins deux systmes distincts, cest donc un systme mutualis. Dans les entreprises, on
distingue en particulier les rfrentiels employs (pages blanches internes, annuaires des
utilisateurs du SI, annuaires de messagerie, etc.), les rfrentiels clients (bases prospects, bases
clients etc.) et les rfrentiels produits (catalogue de produits, rfrentiel valeurs mobilires,
prestations de service, etc.).
Mettre en place un
rfrentiel pour
rduire les cots ou
augmenter la
cohrence, souvent
vhicule de
nouvelles
opportunits.
La cration dun rfrentiel procde de deux volonts distinctes qui sont :

les conomies, par la mutualisation de systmes autrefois distincts
(ex. : rfrentiel valeurs)
les gains en cohrence, qui peuvent tre la source daugmentation de la
comptitivit (rfrentiel client) ou damlioration de la scurit (rfrentiel
employs).
Pourquoi un pattern ? Quelque soit la nature du problme, la cration dun rfrentiel se fait
souvent par fusion. Fusion de systmes, mais aussi de personnel charg de ces systmes. On
ne cre pas un rfrentiel employs sans modifier profondment les processus dinscription dans
les branches de lentreprise : ressources humaines, systmes informatiques, tlphonie,
partenaires, administrations, etc. Ne parlons pas des rfrentiels client, qui sont la cause mme
des grandes mtamorphoses que subissent les entreprises actuellement.
Bien quon ait longtemps cru que des technologies, comme LDAP par exemple, allaient nous
permettre de crer des rfrentiels les yeux ferms et les mains dans les moufles. Labsence de
systme global, automatis et traable de gestion des employs dans les entreprises aujourdhui
nous pousse croire que la technique ne doit probablement pas tre lunique problme.
De mme, beaucoup de thoriciens de lUrbanisme nous proposent des beauts lyriques du type
toute donne appartient un bloc et un seul . Dans les faits, la prsence dun existant non
urbanis impose une gymnastique beaucoup plus acrobatique avec ces donnes distribues
dans lentreprise ! La problmatique est synthtise dans la figure suivante :
Figure 16 :
Pattern
Rfrentiel
45
Partager des
donnes dans un
environnement
distribu et multimatre : un
problme plus
compliqu quon le
croit.
Le domaine rfrentiel X est responsable bien sr de la gestion de ses donnes dites

matres . Lexistence de donnes matres prsuppose celle de donnes esclaves , que
lon retrouvera donc dans les systmes utilisant cette donne pour leurs traitements, mais ntant
pas habilits la modifier directement. Et vice versa. Pour des raisons historiques, la plupart des
Systmes dInformation hbergent de nombreux rfrentiels, conduisant un environnement
multi-matre : plusieurs systmes peuvent tre responsables de la mme donne.
Pour assurer sa mission de gestion de donnes pour le compte dautres applications, le
rfrentiel va devoir :
recevoir, autoriser et rpondre aux accs en lecture ses donnes,
recevoir, autoriser et orchestrer les processus distribus de gestion de ses donnes
(provisioning). Cest ce niveau que sera gr le fait que lorsquun employ est
embauch, on doit traiter son dossier dans diffrents services, comme les RH ou les
services informatiques,
propager automatiquement ces donnes matres vers lextrieur.
Un dictionnaire de donnes (ou mta-donnes), dcrit la structure des donnes gres, leur
propritaire, leur cycle de vie, leurs habilitations, ou leurs cibles de rplication. Il permet aux
briques de synchronisation et de gestion des donnes matres de raliser leur travail. Ce
dictionnaire gagne tre partag, mais peut tre disjoint pour des questions techniques ou lies
lexistant.
Pour conclure cette partie sur les patterns fonctionnels, notons que le pattern procde lui-mme
dune logique dassemblage. Et nous voyons par exemple que le cas dun important systme
dinformation ddi la gestion dun rfrentiel, par exemple le fichier ADN, ncessitera de
sappliquer lui-mme un pattern royaume/missaire pour isoler toutes les fonctions
dhabilitation et de synchronisation dans un systme ddi, porteur dune lourde complexit.
Enfin, le pattern doit tre flexible, inutile de systmatiser tout linfini. Lobjectif est de structurer
le neuf, pas de changer lexistant tout prix. Inutile par exemple de vouloir migrer des existants
dans des schmas aussi complets si cela ne cre pas spcifiquement de valeur ou dconomies.
Les patterns techniques

Il arrive souvent quun point du dossier darchitecture gnrale ncessite un zoom technique
pour tre mieux qualifi, nous pourrons utiliser des patterns techniques pour proposer des
solutions darchitecture technique.
Des patterns
techniques pour
tayer un problme
informatique
spcifique.
Un pattern darchitecture technique pourra rsoudre un problme informatique pur. Il na a priori

pas dincidence sur lorganisation, hormis lexploitation du systme. Le pattern Single Sign On
(SSO) permet par exemple de grer une plate-forme technique daccs scuriss et transparents
aux applications, voire certaines fonctions unitaires de lentreprise. Ce pattern fera parti dun
projet portail par exemple.
46
Figure 17 : Pattern SSO dcentralis, les composants de scurit sont implants dans chaque application
Figure 18 : Pattern SSO centralis, les composants de scurit sont implants dans un Reverse Proxy unique,
adapt aux architectures Web
Les patterns darchitecture technique sont nombreux, nous en trouverons autour des thmes de
la scurit comme notre exemple, des interfaces homme/machine (architecture multi-canal,
ditique ), des services mtier (gestion du transactionnel, composants avec ou sans tat ),
de la persistance (stockage relationnel, stockage XML, stockage infocentre..), des changes
(pattern EAI ou ETL, format pivot).
Nous ne visons pas lexhaustivit dans cette publication, puisque ces lments darchitecture
technique sont abondamment dcrits dans nos diffrentes publications (voir Bibliographie).
47
V. Dmarche darchitecture projet
Eclater une
problmatique en
plusieurs projets et
rintgrer ensuite
les ralisations dans
une solution
globale.
La complexit des projets informatiques est proportionnelle aux ambitions dautomatisation et

doptimisation des processus de lentreprise. Ces projets sont dautant plus complexes quils
doivent intgrer un existant lourd et sinsrer dans un environnement impliquant un grand
nombre dacteurs et de systmes htrognes.
La difficult relve de la capacit concevoir une solution ralisable dans les temps et cots
impartis, sur la base de concepts simples, et la construire sans dvier des objectifs initialement
fixs. La dmarche consiste en un dcoupage en sous-ensembles de complexit moindre
donnant lieu des chantiers de taille raisonnable et pilotable, cest dire compris entre 5 et 10
personnes en rgime de croisire. Le dfi reste ensuite de garantir lintgration entre ces
modules pour aboutir une solution globale satisfaisant lensemble des besoins exprims.
Cette dmarche nest bien sr pas systmatique. Elle nest justifie que dans la mesure o le
projet adresse une complexit importante en termes de processus mtier, de nombre de briques
applicatives combiner, ou denvironnements techniques htrognes intgrer. Elle devient
indispensable lorsque plusieurs gnrations technologiques et des progiciels divers doivent
coexister.
La dmarche
darchitecture na de
pertinence que dans
des environnements
complexes ou nonstandard.
Lthique projet
prend ses racines
dans un objectif
clair et fond.
Lorsque la problmatique adresse un primtre suffisamment dlimit et matris avec un

minimum dinteractions avec des composants externes, le besoin darchitecture est moins
vident. Il suffit de rechercher un progiciel du march, mme de niche, dont la couverture
fonctionnelle serait proche du besoin ou denvisager un dveloppement maison. Dans ce cas-l,
des dmarches de type XP ou RUP41 sont directement adaptes.
Dans le cadre du btiment, on fait rarement appel un architecte lorsquil sagit de monter des
maisons en prfabriques. Le montage est gnralement plutt directement pris en charge par le
fabricant ou son distributeur. Encore moins lorsquil sagit de faire un ravalement de faade, ou seul
le respect de certaines normes techniques, environnementales ou durbanisme importe. La valeur
ajoute de larchitecte se positionne pour des problmes complexes ou non standards.
En revanche, ladoption dune approche architecture devient indispensable lorsque le projet doit
implmenter des processus complexes engendrant de multiples imbrications de nombreuses
briques. Cest le cas par exemple pour la refonte dun Back-Office bancaire, la mise en place dun
Front-Office multi-canal, ou encore la construction dune place de march.
Cette approche doit galement respecter une certaine thique projet fonde sur les spcificits
propres tout chantier denvergure : dfinition des objectifs, organisation pluri-comptences,
budget prvisionnel, planning, etc.
Pour russir un dcoupage pertinent de ce type de problmatique et concevoir des solutions
ralistes, il faut relever le challenge de la collaboration entre utilisateurs, fonctionnels et
techniques. Les informations changes doivent tre formalises sans subir la dformation dun
effet tlphone arabe .
41 : eXtreme Programming, Rational Unified Process.
48
Un formalisme
commun comme
liant des diffrents
profils du projet.
Pour viter ces problmes de communication lis des incompatibilits de langage, cette mixit
de profils requiert un formalisme commun pendant toute la dure du projet. La cration dun
discours universel est une des cls de la capacit crer une synergie dquipe. Ce discours
devra sappuyer sur les piliers suivants :
Une Mthodologie, cadre gnral dans lequel les parties progressent de manire
itrative et cohrente, chacun ladressant de son propre point de vue, fonctionnel,
applicatif ou technique,
Un Rfrentiel des modles, dans lequel sont rpertoris les modles formels et la
documentation courante,
Un Vocabulaire, issu des rgles communes de reprsentation.
En pratique, comme nous lavons voqu dans un chapitre prcdent, nous prconisons le
standard UML comme base pour ce formalisme commun. En effet ce langage de modlisation
offre toutes les vues ncessaires la formalisation des volets fonctionnel, applicatif et technique.
Ces diagrammes permettent notamment de dfinir les acteurs (utilisateur, partenaire,
fournisseur, etc.), de dcrire les processus et les objets mtier et de spcifier les flux et les
briques applicatives.
Cest avec ce positionnement de pivot central de cohrence que larchitecte sengage assumer
les responsabilits suivantes :
1. Assurer la comprhension mutuelle avec les acteurs amont, par la normalisation
des supports de transmission de linformation,
2. Assurer un rle de conseil en urbanisme et en Systme dInformation pour
concevoir des architectures modulaires, faisables au regard des solutions du
march et de lexistant,
3. Assurer un rle de contrle et de support dans les phases aval pour garantir la
cohsion des ralisations.
La dmarche darchitecture projet est classiquement constitue de deux grandes phases
majeures. La premire, la phase Etude, a pour objectif essentiel de cadrer le projet et de dfinir
les plans pour sa mise en uvre. La deuxime, la phase Implmentation, consiste la
ralisation de la solution elle-mme.
Larchitecture est la
pierre angulaire de
la phase Etude.
Nous verrons un peu plus loin que cest sur la phase Etude que la dmarche est vritablement
la plus innovante. Cest pour cette raison que nous prcisons dans le dtail chaque activit de
cette phase. Larchitecte y joue un rle central de coordination et de communication, assumant
les deux premires responsabilits nonces ci-dessus. Ces activits sont rparties en trois
tapes, lEtude Stratgique, lEtude dArchitecture Gnrale et lEtude dArchitecture Dtaille,
telle que le dcrit la figure suivante :
49
Figure 19 : Les trois tapes de la phase Etude

Larchitecture
garantit la matrise
de lentropie
dans la phase
Implmentation.
Au cours de la phase Implmentation, lquipe architecture conserve cette responsabilit de

conseil en urbanisme et en Systme dInformation mais assurera surtout un rle de contrle et
de support aux quipes de ralisation, garantissant la matrise de lentropie du projet.
LEtude Stratgique
Pas de projet sans
sujet prcis.
Ltude stratgique :
identifier les enjeux,
dfinir les besoins
et valider
lopportunit.
On ne fait pas de projet sans sujet prcis. Lorsquun client sinterroge sur lintrt de choisir telle
solution darchitecture plutt quune autre, il est souvent ncessaire de revenir des
fondamentaux comme : Pour quoi faire? Pour quand ? Pour qui ? Pour combien ?. Bien
que banales, ces interrogations sont rarement souleves ou alors avec des rponses peu
approfondies.
Lorsquun responsable informatique du milieu industriel souhaite mettre en place un systme
automatis de e-Procurement42, il peut toujours se lancer dans des prototypes et des tudes pour
sentir la maturit du march. Pour autant, il lui faudra bien un jour rpondre ces questions. A
quel type dachat souhaite-t-il destiner sa future solution ? Quel niveau dinvestissement lui
semble-t-il raisonnable pour un tel projet ? Quelle rentabilit attend-il de cette volution ? Quelle
est la criticit de mettre en uvre telle solution ?
Toutes ces interrogations doivent tre abordes lors dune tude stratgique prliminaire,
destine identifier les enjeux, dfinir les besoins et valider lopportunit. Bien que nayant
aucune vocation fournir des recettes pour mener cette tude, la dmarche darchitecture a
besoin de ces rsultats pour faire des choix de solutions pertinents. A linverse si certains critres
ne sont pas pris en compte ds ce pralable au projet, il risque fort de ne pas aboutir ou de
passer ct, malgr tous les efforts que lon pourrait faire par la suite.
42 : Gestion informatise des achats.
50
Larchitecte peut participer cette premire tape pour, dune part, sassurer que toutes les
informations dont il aura besoin par la suite seront bien fournies et, dautre part, anticiper les
contraintes et autres lments techniques pouvant tre structurant pour la suite du projet.
Ltude stratgique fournit des rponses sur les sujets suivants :
1. Le primtre,
2. Le modle conomique,
3. Le planning prvisionnel.
Cerner le primtre
= rechercher les
processus les plus
ritrs, fort
impact et
ncessitant une
traabilit
importante.
Le premier point consiste dfinir le primtre du projet partir dune expression de besoin et
des objectifs que lon se fixe pour atteindre ces besoins.
Il est donc ncessaire dans un premier temps de consulter les futurs utilisateurs, ou tout du
moins les fonctionnels , seuls pouvoir formuler la demande au travers dune expression de
besoin. Il sagit pour cela de cadrer avec le type de processus que lon souhaite automatiser, les
processus slectionns devant prsenter plusieurs caractristiques parmi les suivantes :
la ritration : le mme processus est ralis plusieurs fois, sans modification ni
spcificit,
la taille : le processus a un impact sur beaucoup de personnes ou dactivits,
la traabilit : il est important pour lentreprise de savoir quelle information a t
traite par qui et quand.
Dans le cadre dun projet de e-Procurement, lautomatisation de certaines procdures dachat a
plutt les caractristiques ritration et taille que traabilit. Ces deux caractristiques fortes en
font nanmoins un bon candidat linformatisation, dans lespoir den tirer un retour sur
investissement.
Ce besoin doit ensuite tre amend en vrifiant dans quelle mesure un tel projet pourrait
sinscrire avec cohrence dans la stratgie globale de lentreprise. Lorsque lentreprise a investi
massivement dans une place de march, la cohrence dun projet de e-Procurement est
vidente, puisque les gains de productivit attendus le sont principalement du fait de
lhomognisation des procdures dachat dans lentreprise, ce qui prche pour une certaine
centralisation
Enfin, les contraintes fortes potentiellement structurantes doivent tre prises en compte dans
cette phase amont. Elles peuvent tre dordre politique, lorsque lorganisation est impacte,
calendaire, lorsque le projet est intimement li la roadmap dautres projets, fonctionnel
lorsquune partie majeure du processus mtier de lentreprise est en mutation, ou enfin technique
lorsque la maturit dun lment cl du projet nest pas garantie (par exemple le niveau de
scurit sur Internet).
Cette confrontation des besoins avec la stratgie et les autres dpendances externes permet de
dfinir les objectifs que lon fixe collgialement pour le projet.
A ce stade de ltude, il est possible de dresser un premier modle darchitecture gnrale,
identifiant les principales briques. Le systme de GMAO43, la gestion des fournisseurs, lintranet
Entreprise et la place de march pourraient par exemple reprsenter les principaux pavs
applicatifs dun projet de e-Procurement.
43 : Gestion de Maintenance Assiste par Ordinateur.
51
Construire le
modle conomique
: un exercice
souvent subjectif.
Dfinir le planning
prvisionnel.
Avec tous ces lments clairement formaliss, le primtre du projet peut tre prcis, ainsi que
les conditions dans lesquelles il est lanc.
Le deuxime thme approfondir est le modle conomique du projet, ou comment justifier la
solution avec le business case quelle est cense couvrir.
La dfinition des cas mtier adresss permet den dduire les processus mettre en uvre et
donc danticiper les rorganisations ventuellement ncessaires. On peut ainsi calculer un
investissement prvisionnel et estimer le niveau de ROI un horizon donn. Comme nous
lavons dj dit, le calcul du ROI est ais sur un projet Tel Que Construit , car fond sur des
mtriques connues issues du pass. Il lest moins sur des projets Mieux Que Construits et
Autres Que Construits , pour lesquels des hypothses doivent tre labores
(rorganisation, diminution du temps de gestion administrative au profit du temps commercial,
ouverture de nouveaux marchs, etc.). A ce jeu, on se retrouve souvent dans la peau dun institut
de sondage cherchant son coefficient correcteur pour dterminer les intentions relles de
vote... Exercice souvent fallacieux, lhistoire nous la montr.
Le dernier point consiste la dfinition du planning prvisionnel.
Sensibiliser sur la
dmarche et le
niveau
dengagement de
chacun.
A partir dun premier tat des lieux sur la couverture des solutions et des systmes existants,
crois avec une modlisation du besoin en termes de processus, de criticit et de spcificit, un
premier planning dvolution fonctionnelle est dfini, une trajectoire trace et des grands jalons
fixs.
Il est indispensable ce stade de fournir un cadre de travail pour la suite, prcisant la dmarche,
les prrogatives de chaque acteur et leur rle sur chaque activit prvue dans la dmarche. Tous
ces lments doivent tre dfinis et accepts par tous.
Dans cet ouvrage, nous proposons de nouvelles faons de faire, demandant une forte
sensibilisation auprs des intervenants. Ds le dpart, il est ncessaire danticiper ce besoin
dducation et de gestion du changement en lanant un rel plan de communication sur la
dmarche et le suivi de son application.
LEtude dArchitecture Gnrale

Les objectifs et les livrables
Trois objectifs pour
la phase dEtude
dArchitecture
Gnrale :
Concevoir,
Communiquer et
Chiffrer.
Les objectifs de la phase dEtude dArchitecture Gnrale sont de concevoir, communiquer et

chiffrer larchitecture gnrale du projet :
Concevoir la cration et la modlisation de larchitecture du systme qui servira de
guide pour la suite du projet et notamment la phase dtude darchitecture dtaille,
Communiquer une vision commune de larchitecture gnrale sur laquelle
saccordent tous les acteurs du projet,
Chiffrer macroscopiquement le projet.
Les rsultats de cette phase dtude sont :
Le Dossier dArchitecture Gnrale (DAG),
La contribution au Plan Projet Gnral (PPG).
52
Le Dossier dArchitecture Gnrale (DAG)

Le DAG (Dossier
dArchitecture
Gnrale) : trois
angles de vue sur
un systme unique.
Le DAG se compose de trois volets :

Un volet fonctionnel : il contient des modles danalyse fonctionnelle formaliss
partir des expressions de besoin : diagrammes dorganisation, diagrammes de cas
dutilisation, diagrammes dactivit, diagrammes dtats dobjet mtier (voir le
chapitre Formalisme de modlisation),
Un volet applicatif : il contient des modles de conception informatique :
diagrammes de briques applicatives, diagrammes de squence, diagrammes de
collaboration, (voir le chapitre Formalisme de modlisation),
Un volet technique : il contient des cartographies de lexistant, des audits
techniques, des tudes de re-utilisation dapplications, etc.
Une ou plusieurs architectures ?
Certains ouvrages sur larchitecture de SI introduisent la notion darchitecture fonctionnelle (AF),
darchitecture applicative (AA) et darchitecture technique (AT) souvent obtenues en suivant une
dmarche de construction top-down 44.
Ce dcoupage, bien que sduisant dun point de vue thorique, nous semble surtout tre une vue
de lesprit qui ne reflte pas la ralit de larchitecture de SI o il existe de fortes adhrences entre
les diffrents niveaux darchitecture. Aussi, nous prfrons considrer larchitecture dun SI
comme un tout indivisible qui peut tre observ suivant plusieurs angles de vue ou volet.
Cette distinction peut sembler subtile mais elle est primordiale et va bien au-del dune diffrence
lexicale entre le terme architecture et le terme volet . En effet, non seulement cette
approche dune architecture unique invalide lexistence de ponts de transformation entre les
diffrents niveaux darchitecture mais elle a galement un impact trs fort sur la dmarche
mme de construction de larchitecture. En effet, l o certains conseillent une dmarche de
construction en cascade AF -> AA -> AT, nous dfendons une approche itrative et incrmentale
de la construction de larchitecture.
44 : Le projet durbanisation du systme dinformation, de C. Longp.
53
Le Plan Projet Gnral (PPG)

Le PPG est un livrable essentiel qui va contenir et justifier les engagements budgtaires et
calendaires du projet, ainsi que son organisation.
Le PPG (Plan Projet
Gnral) :
organiser, chiffrer et
planifier.
Il contient galement trois volets :

Volet organisation : organisation des quipes fonctionnelles, des
dveloppements, de lintgration, de lhomologation. Le volet organisation fait
apparatre les lments transverses, comme le Bureau dArchitecture que nous
dcrirons plus loin.
Volet planning : lotissement des tches et plans de migration,
Volet financier : macro-chiffrage du projet,
Lobjet nest pas de prsenter ici une mthodologie de chiffrage, mais de rsumer comment le
Dossier dArchitecture Gnrale participe la cration de ce document.
Le PPG exploite la
structure des blocs
de larchitecture, et
la description de
linvisible interstitiel,
souvent nglig.
Premier aspect, le DAG a dfini lensemble des briques de larchitecture. Ces briques vont
constituer la cl de rpartition principale des diffrents chantiers : par exemple, la brique
rfrentiel Produit , la brique infocentre marketing ou la brique Sales Force
Automation . Que celles -ci soient implments sous la forme de dveloppements spcifiques
ou via des progiciels, la liste des principales fonctions de la brique permet destimer la charge
de cration, avec laide de mtriques classiques, dpendantes des mthodes de dveloppement
ou dintgration : Spcifications Fonctionnelles Gnrales, Spcifications Fonctionnelles
Dtailles, Dveloppement/Paramtrage, Tests Unitaires, Tests de briques, Homologation,
Migration.
Second aspect, le DAG sintresse trs en amont aux problmes dintgration entre briques.
Cest souvent ce niveau que peinent nombre de projets, faute davoir anticip la complexit
toujours plus grande de ces chantiers. Plus une brique ralise de tches , plus lintgration avec
son environnement sera complexe ! Lintrt du DAG est davoir apprhend la plupart des flux
complexes entre briques, et donc de permettre un chiffrage fin pour ces intgrations. Le DAG ne
sintresse en revanche pas aux flux techniques (rplications de donnes en particulier), pour
lesquels une mtrique devra tre tablie.
Une dmarche itrative

La phase dtude darchitecture gnrale suit une dmarche itrative et incrmentale base sur
les trois activits suivantes :
Analyse des besoins fonctionnels et du SI existant,
Conception de larchitecture gnrale du SI,
Evaluation & Validation de larchitecture gnrale.
54
Figure 20 : Dmarche de construction de larchitecture gnrale
Cette approche itrative permet de travailler par zoom successif (macro-processus, cas
nominaux, cas dexception, etc.) et daffiner au fur et mesure les modles de conception de
larchitecture gnrale. Elle favorise galement la collaboration entre les diffrentes quipes
participant au projet.
Etant le seul avoir une vision globale de larchitecture et des contraintes associes
(fonctionnelles, applicatives et techniques), cest larchitecte qui fournit la premire bauche de
larchitecture. Cest lui galement qui la modifie et laffine par itrations successives
: re-dcoupage / fusion de briques applicatives, application dun pattern, mutualisation de flux,
etc.
Ces modifications le conduisent solliciter les quipes fonctionnelles et techniques pour tudier
certains aspects particuliers des besoins et de lexistant : demande dinformation
complmentaire sur un cas dutilisation, audit technique des applications existantes, tude de
flux, etc. Par exemple, larchitecture peut vouloir mutualiser certains traitements communs
plusieurs cas dutilisation et demandera donc aux quipes fonctionnelles de dtailler ces cas
dutilisation laide de diagrammes dactivit pour pouvoir mieux cerner les traitements
mutualisables.
Quelle granularit pour larchitecture gnrale ?

Le DAG assure la
transition entre la
phase dtude
gnrale et la
phase
dimplmentation. Il
ne se substitue pas
au design des
briques du systme.
LArchitecture Gnrale ne dcrit pas dans le dtail le systme mais servira de structure la
phase dImplmentation.
En particulier, le DAG fait apparatre les diffrentes briques du SI et leur responsabilit respective.
Son rle nest pas de rentrer dans le design dtaill de chaque brique. La frontire entre
architecture et design stablit en ayant lesprit le principe de subsidiarit : au niveau dune
brique, existe-t-il une volont transverse dsignant larchitecte comme meilleur concepteur plutt
que le futur chef de projet de la brique ?
55
Pour mieux cerner cette dmarche, nous proposons de lillustrer dun use case qui nous
permettra dattacher des exemples aux concepts voqus.
Introduction du use case

Paris le 26 septembre 2002, M. Jean-Paul DELEVOYE, ministre de la Fonction publique a adress
un courrier lensemble de la reprsentation nationale concernant la ncessaire simplification des
procdures administratives. Les contraintes, les dlais et la complexit de nombreuses procdures
sont, en effet, de plus en plus mal accepts et compris aussi bien par nos concitoyens que par les
fonctionnaires eux-mmes. Le ministre dclare Simplifions la vie des Franais .
Juin 2003. Malgr lamlioration sensible des procdures de chacune des administrations
concernes (ministre des Finances, caisses dallocations, ministre de lIntrieur) et la mise en
place de tlservices de plus en plus nombreux, ltat peine atteindre lobjectif fix, car aucune
de ces initiatives nest coordonne. Un changement dadresse ou de situation familiale reste
toujours un cauchemar pour lusager. Le guichet unique de la Fonction Publique nexiste pas.
Septembre 2003. Aprs un dbat houleux lassemble, la question du guichet unique a trouv
son compromis. Aucune administration ne pouvant lgitimement se dmarquer des autres pour
grer une relation usager et sinterfacer aux autres acteurs, cette mission a t confie trois
piliers de la vie quotidienne des citoyens : les mairies, les prfectures, et les bureaux de Poste.
Chacun aura le mme niveau de prrogatives, et distribuera donc les mmes prestations. Le
service sera gratuit pour lusager, et financ par un transfert budgtaire des administrations vers
les guichets, au titre des conomies lies la baisse de frquentation directe. Le guichet fournit
lusager les prestations transverses et un accueil de premier niveau, les administrations conservant
la mainmise sur leurs spcificits : recherche demploi, dclaration fiscale, scolarisation, justice,
etc.
Janvier 2004. Le projet GNU Guichet National Unifi sera ralis lextrieur des Systmes
dInformations des entits concernes pour mieux tre partag. Les oprateurs des mairies, des
prfectures et de La Poste utiliseront ce systme unique, simplifiant ainsi la mobilit du citoyen,
tout en rduisant les cots de mise en place. Dans un premier temps, les guichets proposeront aux
usagers la prise en charge de lensemble de leurs formalits, mais nen automatiseront quune
partie.
Le systme dinformation qui sous-tend lactivit aura un premier palier oprationnel un horizon
de deux ans. Un second palier renforcera laspect relation au client avec la mise en place dun
systme proactif ( push ).
La phase danalyse
La phase danalyse
mne en parallle
lanalyse
fonctionnelle et
lanalyse technique
de lexistant.
La phase danalyse mne deux activits en parallle :

Recueil et analyse des besoins fonctionnels,
Audit et analyse de lexistant applicatif et technique.
Lobjet nest pas de prsenter une mthodologie de recueil de besoins fonctionnels mais de
montrer linformation ncessaire larchitecte pour concevoir larchitecture du SI. En effet, tous
les besoins exprims par les quipes fonctionnelles nont pas ncessairement dimpact sur
larchitecture gnrale. Par exemple, spcifier que le nouveau systme dinformation dune
entreprise doit pouvoir manipuler aussi bien des euros que des dollars pour la gestion des
commandes, ne doit donc pas tre pris en compte pendant la phase de conception, car il ne
sagit pas dun besoin structurant lchelle du SI.
56
Larchitecte a donc un rle de slection et de structuration des besoins fonctionnels afin de faire
ressortir ce qui contraint larchitecture du systme. Cette activit est mene en troite
collaboration avec les quipes fonctionnelles afin de garantir la validit des modles fonctionnels
utiliss.
Larchitecte est en particulier intress par :
Lorganisation de lentreprise : il ne sagit pas de dcrire dans le dtail
lorganigramme de lentreprise mais plutt de donner une vue densemble du
dcoupage organisationnel de lentreprise sur le primtre du projet. Larchitecte
sintresse galement aux diffrents acteurs qui seront amens utiliser le systme
dinformation.
Larchitecture ne
sintresse pas
tout les cas
fonctionnels.
Les cas dutilisation : le recueil des besoins fonctionnels sorganisant

gnralement autour des cas dutilisation (voir le chapitre Formalisme de
modlisation ), larchitecte cherche les trier, les slectionner et regrouper
ensemble ceux qui ont une forte affinit fonctionnelle. Tous les cas dutilisation ne
sont pas forcment pertinents pour construire larchitecture gnrale. Il suffit
dtudier les principaux cas dutilisation mtier. Il est par contre important de les
choisir avec soin pour quils soient reprsentatifs de lensemble du mtier : 2 ou 3
cas dutilisation par processus mtier, par exemple.
Les objets mtier : les objets mtier auxquels larchitecte sintresse sont ceux qui
ont un sens pour les quipes fonctionnelles. Il ne sagit pas de deviner les
objets internes du systme mais de se concentrer sur ceux qui apparaissent
directement dans le discours des fonctionnels. Ces objets mtier se retrouveront au
cur de la problmatique dinteroprabilit entre briques.
En parallle de la phase danalyse fonctionnelle, les architectures pilotent des audits de lexistant
applicatif et technique. Ces tudes sont dautant plus importantes que le poids de lexistant est
lourd. Dans le cas de systmes from scratch , les tudes porteront plutt sur les SI avec
lesquels ils doivent sinterfacer : services offerts, formats dchanges, rfrentiels existants, etc.
57
Illustration de la phase danalyse sur le use-case GNU

Recueil des besoins fonctionnels
Parmi les documents fournis par les quipes fonctionnelles, larchitecte va sintresser
particulirement ceux dcrivant lorganisation fonctionnelle, les cas dutilisation et les diffrents
acteurs.
Ladministration GNU (Guichet National Unifi) est compose de trois directions :
Direction des services aux usagers : cest la direction charge des relations avec
les usagers et des services qui leur sont rendus.
Direction des oprations : cest la direction charge de lorganisation des
guichets, des utilisateurs du SI et des infrastructures.
Direction des relations avec les administrations : cest la direction charge des
relations avec les correspondants des administrations interfaces GNU (gestion,
refacturation et traitement des procdures).
Les principaux utilisateurs du systme GNU sont :
Usager : citoyen bnficiaire des prestations administratives.
Utilisateur : guichetier qui sert les usagers.
Administrateur : guichetier aux droits plus levs qui peut utiliser des fonctions
dadministration.
Correspondant administratif : interface entre GNU et les administrations
publiques.
Voici des exemples des principaux cas dutilisation du systme, fournis par les quipes
fonctionnelles :
Ouverture de dossier usager : cration dun dossier usager dans le systme
GNU.
Suivi de dossier usager : modification, consultation et fermeture dun dossier
usager.
Demande de prestation : ouverture dune demande de prestation offerte par GNU.
Par ex. : changement de statut familial, changement dadresse, demande de
duplicata, etc.
Suivi de prestation : modification et consultation des prestations en cours.
Cration dune nouvelle prestation : mise disposition dune nouvelle prestation
administrative.
Identification & habilitation : authentification et identification des usagers, des
utilisateurs, des administrateurs, etc. Chaque personne possde des habilitations
propres.
Refacturation de procdure : les prestations administratives excutes par GNU
sont refactures aux administrations centrales.
58
Chaque cas dutilisation est gnralement accompagn dune description textuelle voire dun
diagramme dactivits qui montre lenchanement des activits participant la ralisation du cas
dutilisation.
Analyse des besoins fonctionnels
Comme indiqu dans la dmarche, la premire tche de larchitecte est de trier, structurer et
analyser les expressions de besoins fournies par les quipes fonctionnelles.
Parmi les acteurs dcrits par les quipes fonctionnelles, larchitecte retient ceux qui sont acteurs
principaux du systme au sens UML, cest--dire ceux qui interagissent directement avec le
systme. Dans le cas du systme GNU, il sagit donc de lutilisateur, de ladministrateur et des
correspondants administratifs. Par contre, lusager final ninteragissant pas directement avec le
systme, il ne sera pas considr pendant cette phase dtude gnrale45.
Ltude des cas dutilisation permet de faire ressortir les principaux objets mtier du systme GNU :
Dossier usager : contient les informations relatives lusager, lhistorique des
prestations, ainsi que la liste des prestations en cours de traitement.
Prestation : une prestation dsigne le regroupement de plusieurs procdures
administratives. Exemple : la prestation Dclaration de naissance contient les
procdures Dclaration de naissance pour ltat-civil et Dclaration de
naissance pour la CAF , etc..
Procdure : une procdure dsigne un service mis la disposition de GNU par une
administration publique. Exemple : Changement de statut familial pour ltatcivil ou Demande de duplicata de permis de conduire .
Note : nous avons cart lacteur Usager pour notre tude gnrale mais
nous conservons lobjet mtier Dossier usager .
La procdure administrative est centrale pour lactivit du GNU, et constitue donc un objet mtier
dont le cycle de vie est dcrit ci-aprs :
Figure 21 : Diagramme dtat pour

lobjet mtier Procdure
45 : On sy intressera plus tard un niveau technique pour matrialiser les accs libre services (Internet et bornes interactives).
59
Ensuite, larchitecte trie et organise les cas dutilisation en regroupant ceux lis par une affinit
fonctionnelle forte (manipulation du mme objet mtier, mme contexte fonctionnel, etc.) :
Package Gestion des usagers
Ouverture de dossier usager
Suivi de dossier usager
Package Gestion des prestations
Demande de prestation
Suivi de prestation
Changement de statut familial, Changement dadresse, Demande de duplicata, etc.
Cration dune nouvelle prestation
Package Scurit
Authentification usager
Authentification utilisateur
Authentification administrateur
Package Gestion des procdures
Mise en place dune nouvelle procdure
Traitement dune procdure
Refacturation de procdure
Figure 22 : Regroupement en packages des cas dutilisation

Chaque package fait lobjet dun ou de plusieurs diagrammes qui dcrivent les cas dutilisation
regroups ainsi que les relations quils ont entre eux :
60
Figure 23 : Diagramme de cas dutilisation pour le package Gestion des prestations
La phase de conception
La phase de
conception est
initie par
larchitecte partir
des modles de la
phase danalyse.
Une premire rflexion fonde sur les diffrents modles danalyse fonctionnelle (organisation de
lentreprise, principaux objets mtier, regroupement des cas dutilisation en packages, etc.)
permet larchitecte dbaucher un premier dcoupage du SI en briques applicatives.
Ce dcoupage est nourri par les modles de la phase danalyse fonctionnelle mais, comme dans
tout travail de cration, il est galement le rsultat de considrations moins rationnelles qui
influencent larchitecte : exprience, intuition et orientation du projet.
Cette premire version de larchitecture permet dinitier le cycle ditration qui va permettre
daffiner et damliorer larchitecture gnrale du SI.
La dmarche itrative de conception darchitecture se base sur la construction de modles
complmentaires. Chaque nouveau modle permet de changer de point de vue sur larchitecture
et de dtecter des erreurs ou des opportunits damlioration :
Les diagrammes de briques applicatives permettent de dcrire larchitecture
statique du systme.
Les diagrammes de squence qui donnent une vision dynamique du systme,
vont par exemple faire ressortir les opportunits de mutualisation de traitement.
61
Les diagrammes de collaboration permettent de modliser le contexte des
briques applicatives et en particulier de contrler/matriser les flux quils changent

avec le reste du systme.
Des itrations
successives avec
les diffrents
acteurs du projet
permettent daffiner
larchitecture
gnrale du SI.
Chaque modification ou amlioration de larchitecture peut conduire larchitecte demander des

tudes complmentaires aux quipes fonctionnelles et techniques. Cest cet aspect itratif qui
fait la force de cette dmarche.
Rappelons quen termes de granularit, larchitecture gnrale sarrte au niveau de la brique
applicative, cest--dire une entit cohrente fonctionnellement et techniquement. Elle pourra par
la suite faire lobjet dun choix de progiciel ou dun dveloppement spcifique, ncessitant dans
ce cas une spcification plus dtaille.
Illustration de la phase de conception sur le use-case GNU
Premire bauche darchitecture gnrale

Une premire rflexion fonde sur les diffrents modles danalyse fonctionnelle (organisation de
lentreprise, principaux objets mtier, regroupement des cas dutilisations en packages, etc.)
permet larchitecte dbaucher un premier dcoupage du SI en briques applicatives :
Figure 24 : Diagramme de briques applicatives

Il sagit ensuite dprouver et de vrifier ce dcoupage en considrant maintenant le systme dans
un contexte dynamique. Pour cela, larchitecte construit les diagrammes de squence associs
aux principaux cas dutilisation.
62
Figure 25 : Diagramme de squence pour le cas dutilisation Dclaration de naissance
Premire itration darchitecture gnrale

On remarque sur le diagramme de squence que le traitement de la procdure naissance pour
ltat civil est trs similaire au traitement de la procdure naissance pour la CAF . Cette
observation conduit larchitecte se demander comment cette architecture pourrait tre amliore.
Dans un but de mutualisation des traitements, larchitecte demande aux quipes fonctionnelles de
prciser le traitement des procdures naissance pour ltat civil et naissance pour la CAF
laide de diagrammes dactivit.
Figure 26 : Lobservation de ces diagrammes dactivit confirme cette similitude.
63
Sous la direction de larchitecte, une analyse des relations entre le cur du

s y s t m e ( G R C Prestations ) et les briques applicatives qui permettent de
communiquer avec les administrations distantes, fait ressortir les points suivants :
Chaque administration a son propre mode daccs (tl-procdure, email, courrier,
etc.) et format dchange (la CAF utilise le numro de scurit sociale pour identifier
lusager alors que le centre des impts possde un identifiant contribuable),
cependant toutes offrent une notion transverse de procdure.
Il y a donc opportunit de mutualiser les traitements communs toutes les
administrations distantes : cration et suivi de la procdure, refacturation de la
procdure, etc.
Il existe de fortes contraintes de scurit : le GNU doit tre un acteur de confiance
qui les administrations dlguent une partie de leurs procdures, le GNU doit donc
crer une zone de confiance virtuelle entre les diffrents Systmes dInformation.
Larchitecte suggre lutilisation dun pattern Royaume / Emissaire qui permet de dcoupler la
gestion des prestations usagers, du traitement spcifique des procdures par les administrations
distantes. Larchitecte propose donc une nouvelle version de larchitecture aprs application du
pattern :
Figure 27 : Application du pattern Royaume/Emissaire
A ce stade, le systme peut supporter une organisation distribue dans les guichets pour les
fonctions du Royaume, et une organisation distribue ou centralise pour lEmissaire.
64
Architecture gnrale finalise

Plusieurs itrations permettront ensuite daffiner ce modle statique pour aboutir au modle final :
Figure 28 : Diagramme final de briques applicatives

Chaque brique fait galement lobjet dune fiche dtaille, mentionnant notamment les principaux
services rendus, un commentaire sur les points cls, etc.
Enfin, nous identifierons ce stade les lments cls de larchitecture technique : ce sont les
lments sensibles pour lesquels des choix structurants doivent tre pris en dbut de projet
car susceptibles dimpacter les chiffrages. Ils seront valids par le prototype.
En ce qui concerne le guichet GNU, larchitecte aura identifi les points cls suivants :
La gestion du multi-entits
Le fait de pouvoir initier une prestation dans une entit (Prfecture) et de pouvoir
suivre cette prestation dans une autre entit (Mairie), ou sur le Web, conduit
invitablement une architecture centralise. Cette centralisation devra
nanmoins autoriser un cloisonnement logique des entits au sein du systme
unique. Le multi-entit promet des gains par rapport des systmes autonomes,
mais il alourdit notoirement la problmatique dhabilitation.
Lachat ou le dveloppement
Certains composants dinfrastructure cl en main seront clairement intgrs dans
larchitecture (worflow, changes, base de donnes, GED...), quils soient issus
dditeurs ou du monde Open Source. Quant aux fonctions applicatives, au vu des
spcificits du traitement des prestations et des procdures, seule la partie GRC
pourra exploiter les fonctions dun progiciel mtier. Le choix se portera sur un
acteur ddi la gestion de base client et dhistorique, plutt quun acteur
gnraliste.
65
La gestion optimise du multi-canal

Dans un contexte ou laccs aux services peut se faire soit par des canaux Libre Service
(Web, Minitel, bornes interactives, etc) soit par des canaux Guichet ou centre dappel, il
est essentiel de pouvoir factoriser au maximum le SI et dviter les dveloppements
redondants dans chaque filire.
La gestion des changes avec les partenaires
La plate-forme dchanges est le point central de communication avec les
Administrations et autres partenaires (notaires, RSS, etc.). Il sagit ici de
dterminer les formats dchanges utiliss (syntaxe, smantique) et la scurisation
des changes (authentification, confidentialit, intgrit, non-rpudiation...).
La gestion documentaire
La numrisation et la gestion des documents est galement transverse au
systme : gestion des messages entrants/sortants avec les usagers et les
partenaires (formulaires, pices justificatives).
La gestion du Workflow
Modlisation, excution et pilotage des processus pour lexcution des prestations
et des procdures, suivi des tats des diffrentes instances de processus, gestion
des tches humaines, processus descalade, etc.
La phase de validation
Larchitecture gnrale pose les fondements dun systme dinformation. Cest en effet ce
niveau que sont prises des dcisions structurantes pour le systme : utilisation de patterns,
mutualisation de briques fonctionnelles ou dinfrastructure, dfinition des mcanismes
dinteroprabilit inter-modules, etc. Dans le but de matriser les risques projet, le directeur de
projet est en droit dobtenir une certaine garantie quant ladquation et la qualit de
larchitecture gnrale propose.
Larchitecture
gnrale doit tre
value et valide
selon deux axes :
un axe fonctionnel
et un axe Systme
dInformation.
La validation de
larchitecture doit
demeurer une
activit continue,
mme si une phase
formelle peut
ponctuer la
conception.
Ceci conduit donc larchitecte devoir rpondre aux deux questions suivantes :
Mon architecture rpond-elle aux besoins fonctionnels du systme pour
laquelle elle a t construite ? Couverture fonctionnelle et respect de principes
fonctionnels structurants (scabilit, multilinguisme, multi-entit, etc.)
Mon architecture rpond-elle aux objectifs de qualit du SI pour laquelle elle
a t construite ? Critres de flexibilit, critres de scurit, standards
technologiques, performance, accessibilit, etc.).
Qui valide le DAG ?

La validation du DAG est sous la responsabilit du directeur de projet en sappuyant la fois sur
les quipes fonctionnelles et techniques. Toutefois, ces dernires nen valident pas les mmes
aspects. La validation du DAG peut seffectuer de manire formelle la fin de la conception, mais
il est pertinent de drouler cette activit tout au long du projet. Cest le principe mme dune
dmarche itrative.
66
Comment valider un DAG ?

Il existe de nombreuses faons de valider une architecture technique (prototype, benchmark de
performance, etc.) mais il est plus difficile de trouver des mthodes pour valider une architecture
sous tous ses volets.
Nous proposons une mthodologie de validation deux niveaux pour rpondre aux deux
questions qui ont t prcdemment poses :
La validation suivant un axe fonctionnel permet de vrifier que larchitecture
considre rpond bien aux besoins fonctionnels,

La validation suivant un axe SI permet de vrifier que larchitecture rpond aux
objectifs de qualit du SI.
Validation suivant un axe fonctionnel

Le diagramme de
squence est au
centre de la
dmarche de
validation.
Qui :
Equipe fonctionnelle et architecture
Comment :
Les besoins fonctionnels impactants tant exprims par des cas dutilisation, il sagit donc de
construire les diagrammes de squence illustrant ces use-cases. Bien sr, il ne sagit pas de
considrer tous les cas dutilisation. Les principaux cas nominaux (rgle des 80 / 20) et quelques
cas dexception suffisent valider larchitecture gnrale dun point de vue fonctionnel.
Cette opration peut tre ralise sous la forme dateliers entre les quipes fonctionnelles et
techniques, o lon prouve collgialement les cas dutilisation sur larchitecture. Le diagramme
de squence est au centre de la dmarche de validation.
Validation suivant un axe SI

La caractrisation
de mtriques
techniques permet
de valider
larchitecture dun
point de vue SI.
Qui :
Equipe architecture + quipe technique
Comment :
Une architecture gnrale peut couvrir les besoins fonctionnels sans tre optimale dun point de
vue Systme dInformation. Il est donc ncessaire dvaluer larchitecture suivant cet axe pour
arbitrer entre plusieurs conceptions et/ou qualifier une architecture par rapport des critres
dfinis dans le cahier des charges. Par exemple, tirer sur laxe flexibilit va ncessairement
impacter laxe cot, on a rien sans rien.
67
Figure 29 : Evaluation darchitectures par caractrisation
Il existe de nombreuses faons de caractriser un SI. Voici une liste des mtriques qui nous
semblent pertinentes mais non exhaustive dans le cadre de larchitecture gnrale :
Agilit / Extensibilit :
. Capacit intgrer rapidement de nouveaux flux et/ou de nouveaux
applicatifs : intgration dun nouveau canal de distribution, sous-traitance
dune activit, etc.
. Capacit supporter plusieurs modes dorganisations,
Respect des standards applicatifs et techniques de lentreprise
. Larchitecture utilise-t-elle les fonctions transverses mises en place au niveau
SI, comme les rfrentiels, la scurit, les plates-formes dchanges, les
services communs ?
. Larchitecture technique sinsre-t-elle dans lunivers dexploitation connu ou
ncessite-t-elle de nouvelles technologies ?
Evolutivit : Capacit intgrer de nouveaux utilisateurs, des rfrentiels plus
larges, monte en charge, etc.
Scurit : Mesure de la scurit globale du systme : scurisation des changes,
difficult dintrusion, authentification des acteurs, etc.
Cots : Mesure du rapport qualit/prix, benchmark par rapport dautres
constructions.
Enfin dans le cas dune architecture transitoire, il est galement ncessaire de considrer la
mtrique Ecart par rapport la trajectoire : des briques non prennes sont-elles
apparues ? A-t-on avanc vers la cible ?
Remarques sur la formulation des objectifs de qualit du SI
Il est important de noter que ces mtriques nont de sens que par rapport des critres
dvaluation prcis. Ceux-ci sont exprims dans le cahier des charges du systme mais souvent
de manire imprcise. Par exemple : Le SI devra tre construit sur un socle volutif et prenne
aussi bien dun point de vue fonctionnel, applicatif et technique . .
68
Exprims de cette faon, les objectifs du SI sont flous et peu directeurs. En effet, qui voudrait dun
systme dinformation construit sur un socle dpass sans possibilit dvolutions ?
De la mme faon, exiger dune architecture quelle soit scurise est trop imprcis. Une
architecture nest dite scurise que vis--vis de certains risques. Par exemple, une architecture
peut sappuyer sur un excellent systme dauthentification et dhabilitation mais rester vulnrable
une attaque interne.
Il est donc indispensable pour valuer et donc valider un systme dinformation de disposer
dobjectifs et de critres de qualit prcis. Ceux-ci sont en gnral exprims dans le cahier des
charges. Par exemple, au lieu de dire le SI devra tre modulaire , il est prfrable de
dire le SI devra pouvoir permettre lexternalisation de la gestion des expditions sous 5 ans .
De mme, au lieu de dire le SI devra tre scalable , il est prfrable de dire le SI devra tre
capable de permettre une augmentation de 200 % du nombre de transactions dans les 3 ans .
LEtude dArchitecture Dtaille

LEtude dArchitecture Dtaille est la dernire partie de la phase Etude, elle se fonde
notamment sur le Dossier dArchitecture Gnrale, et va sattacher :
Concevoir larchitecture technique du SI sur la base du DAG,
Mettre en place un socle technique et mthodologique oprationnel pour la phase
Implmentation,
Valider cette architecture et ce socle (technique, mthodologique) sur la base dun
prototype implmentant un use-case significatif.
Les livrables de cette
oprationnelle :
phase sont constitus dune partie documentaire et dune partie
Le Dossier dArchitecture Technique (DAT), organis en trois volets (Logiciel,

Dveloppement, Production) qui dcrivent respectivement les mcanismes logiciels
de larchitecture technique (chanes de liaison, produits utiliss), le framework de
dveloppement et son cadre dutilisation (outils, librairies, mthodologies), et les
caractristiques de larchitecture de production (aspects systmes et rseau,
dimensionnement, implantation des composants, supervision du systme),
Une version oprationnelle du socle technique et mthodologique :
environnement de dveloppement, de tests et dintgration, frameworks et services
techniques communs (IHM, logs), services mtier communs (parseur de
messages, machine tats), guides mthodologiques,
Le prototype sert de
support la
validation de
larchitecture, et de
la mthodologie.
Un prototype oprationnel implmentant un use-case significatif, permettant de

valider les choix darchitecture dfinis dans le DAT, les exigences de production
(qualit de service, monte en charge, dploiement), dprouver le socle
technique (outils, frameworks) sur une ralisation concrte, de valider la
mthodologie sur lensemble de la chane de production (des spcifications
techniques aux procdures de dploiement).
69
Le framework de dveloppement, un lment fondamental pour la russite du projet

Un framework correspond un ensemble doutils du march, de bibliothques spcifiques et de
mthodologies qui visent faciliter, cadrer et acclrer les dveloppements du projet.
Le framework de dveloppement, labor en phase Etude et consolid en phase Implmentation,
est fondamental la bonne russite du projet :
Il dfinit le cadre de travail et les engagements de chacune des parties, fonctionnelles et
techniques, en spcifiant le processus de dveloppement.
Le processus de dveloppement dcrit le qui fait quoi ? : quelle est la profondeur des
Spcifications Fonctionnelles Gnrales ? Comment sont-elles formalises (Word, UML) ?
Produit-on des Spcifications Fonctionnelles Dtailles ou se suffit-on dune documentation
gnre partir du code ?
Il permet de mieux dcorrler les aspects techniques de limplmentation des fonctionnalits.
Un framework a pour objectif de fournir un ensemble de services, de factoriser les difficults, et par
consquent daffranchir les concepteurs et les dveloppeurs de la rsolution de problmatiques
techniques ou rcurrentes. Au niveau de lexploitation des comptences, cette approche permet
dutiliser des dveloppeurs moins expriments, dans la mesure o chacun na pas connatre la
complexit sous jacente des frameworks utiliss.
Il contraint et standardise les dveloppements.
Le cadre dutilisation du framework doit permettre de canaliser le projet et dviter la dispersion des
quipes. La prsence de ce cadre augmente la rutilisation, et vite le cloisonnement entre les
diffrentes quipes de dveloppement
Il diminue les risques lis au projet.
Lutilisation de diffrents frameworks reconnus est un gage de qualit. En effet, tout bon framework
(issu dorganismes de normalisation mtier, de lOpen Source, ou le fruit dun diteur) aura t
lobjet de longs efforts et de compromis dexperts. Mme si la mise en place dun framework
requiert un ticket dentre initial pour les projets, il se rentabilise toujours par une meilleure matrise
des dlais et de la qualit.
Le Dossier dArchitecture Technique

Ce dossier sera compos de trois volets (Logiciel, Dveloppement, Production), chaque volet
tant guid par un fil conducteur : la structuration en couches de larchitecture technique.
Figure 30 : Structure dun Dossier dArchitecture Technique
70
Dans ce modle que nous proposons, chaque couche implmente des services spcifiques, dont
nous donnons une liste non exhaustive. Le rle de larchitecte tant prcisment de les dfinir
en dtail lors de la conception de larchitecture.
Couche Prsentation
Services IHM (client lourd, client lger), gestion du multi-canal (web, voix, mobile,
fax), services de portail (aggrgation dIHM, bouquets de services), services de
reporting, services dimpression (impressions PDF, gestion de templates, ditions
de masse),
Un dossier structur
en 5 couches, les
volets
dveloppement et
production
permettent une
lecture transverse.
Couche Traitements
Implmentation de la logique mtier sous forme de composants stateless/statefull,
pooling des composants, exposition des composants (Web Services, RMI/IIOP,
.NET Remoting) dautres applications (couche Prsentation, couche
Traitements), services daccs aux donnes (encapsulation des requtes SQL,
voire mapping Objet/Relationnel), services transactionnels (transactionnel
SGBD, transactionnel multi-ressources en srie ou en parallle46),
Couche Persistance
Services de stockage des donnes, moteurs relationnels, bases objets, bases
XML
Couche Echanges
Services dchange entre Traitements (changes synchrones, asynchrones), entre
systme de Persistance (synchronisation de rfrentiels, ETL...), services de
garantie de livraison de message, Message Broker (Transformation, Routage,
DataFlow), services de gestion de transactions tendues (processus,
compensation),
Couche Scurit
Services de scurit : SSO, authentification, gestion des habilitations, intgrit,
non-rpudiation La scurit nest pas une couche isole, mais transverse aux
autres couches : authentification des utilisateurs et contrle des habilitations au
niveau des services IHM, scurisation des traitements (authentification,
habilitations grosse maille et habilitations fines), scurisation des changes,
scurisation des donnes
Le volet Logiciel
Le volet Logiciel dcrit les logiciels utiliss (serveurs dapplications, EAI, SGBD, etc.), et les
chanes de liaison entre les lments de larchitecture (interactions entre couches), ainsi quavec
le reste du SI.
Nous ne fournissons pas ici de modle formel (UML...) pour ce volet ; hormis la structuration en
couches, dcrivant les mcanismes logiciels pour les diffrents services dinfrastructure
identifis. A titre dexemple, on pourra trouver au niveau de la couche Prsentation la description
technique des services dimpression (trop souvent considrs tort comme la dernire roue du
carrosse !) : librairies StreamServe pour la gnration de documents PDF partir de modles,
librairies Crystal Report pour les services de reporting, description des chanes de liaison entre
les diffrents lments de larchitecture, description du flux extranet avec un partenaire pour
ldition de masse, etc.
46 : On parle alors de two-phase commit, protocole lourd nutiliser quen dernier recours.
71
Exemples de points cls du Volet Logiciel pour le use-case GNU

Gestion du multi-entits (couche traitement)
Larchitecte proposera la mise en place dun annuaire LDAP centralis contenant les utilisateurs,
leurs rles et leur entit. Le systme tant bti sur des briques rcentes, cet annuaire pourra tre
unique, vitant lusage dun progiciel de provisioning pour propager les informations
utilisateurs dans diffrentes cibles (GRC, GED, workflow..). Les librairies dauthentification et de
gestion des habilitations (rcupration des droits daccs, gestion des modles dhabilitations
spcifiques chaque entit, etc.) seront incluses dans le socle technique et utilises par
lensemble des applications. Le choix dune organisation centralise pour les correspondants
administration nimpose pas le support du multi-entit dans lEmissaire.
Gestion mutualise du multi-canal (couche IHM)
Une couche spcifique de services IHM exposera sous forme de services Web des fonctions
ddies enrobant les traitements mtier des diffrents modules applicatifs (GRC, Gestion des
Prestations, Gestions des Procdures, Gestion Documentaire, etc.). Exemple : le service IHM
getCustomerListShortInfo() qui renvoie une liste dusagers en 4 colonnes prtes laffichage, et
les traitements mtier getCustomerList() et getCustomerInfo(), plus gnraux. Les services IHM
sont communs aux diffrents canaux daccs (Web, 3G, guichet). Seuls les crans pourront se
diffrencier, par exemple client lourd de type WinForm pour les guichets, pages Web pour
lInternet.
Gestion des changes avec les partenaires (couche interoprabilit)
Les changes avec les partenaires seront au format XML, prconisation du cadre commun
dinteroprabilit de lATICA47. La scurisation des changes se fera par utilisation de SSL V3 et de
certificats X.509, toujours conformment aux prconisations de lATICA. Le GNU utilisera un tiers
externe pour la dlivrance des certificats, la vrification des certificats des autres partenaires, etc.,
linterface avec cet ASP se faisant par le protocole XKMS.
Bien que lATICA recommande de se baser sur ebXML pour linteroprabilit des processus
collaboratifs entre administrations, pour des questions de dlai, larchitecture pourra se baser sur
des normes plus oprationnelles comme BPEL4WS pour lorchestration de Web Services. Des
outils de mapping permettront de sinterfacer aux tl-procdures existantes dans dautres
standards (EDI notamment).
Gestion documentaire (couche traitement)
Lapplication de gestion documentaire est transverse aux diffrents modules applicatifs du GNU.
Elle exposera ses services sous forme de Web Services en utilisant la recommandation SOAP
with Attachments du W3C pour inclure des documents binaires aux requtes SOAP (pices
justificatives scannes, etc).
Lapplication de gestion documentaire devra galement prendre en compte les problmatiques
dhabilitation de lutilisateur ou de lagent guichet en se basant sur les services du socle technique,
la gestion de lhistorique des documents, larchivage des documents
Gestion du Workflow (couches traitement et interoprabilit)
Le gestionnaire de Workflow sera utilis au sein de diffrentes briques applicatives, notamment au
sein du module Prestations et du module Procdures. Il sagira de diffrentier les fonctionnalits
de workflow humain (gestion des tches et des rles, procdures descalade, gestion des emplois
du temps des personnes, etc.) des activits de Process Flow (squencement denvois de
messages, attente de rception dun message, etc) : Les fonctionnalits de Workflow seront
ralises par des progiciels spcifiques (exemple Akazi), le Process Flow par des progiciels
dinfrastructure comme Biztalk Server, WebMethods Integrator, ou des bibliothques Open Source
implmentant BPEL4WS et du parsing XML.
47 : Agence pour les Technologies de lInformation et de la Communication dans lAdministration, www.atica.pm.gouv.fr
72
Le volet Dveloppement
Ce volet a pour objectif de dcrire le socle technique et mthodologique (framework) qui sera
utilis pour le dveloppement des briques du projet.
Le volet Dveloppement se structurera par la description des lments suivants, en gardant
comme fil directeur les diffrentes couches de larchitecture :
Le volet
dveloppement :
des outils, des
bibliothques cl en
main et des guides
mthodologiques.
Maximiser les deux
premiers points
pour pouvoir mieux
limiter le dernier.
Les Outils : ce sont les outils utiliss par les concepteurs pour spcifier
(conception UML, intranet documentaire), et par les dveloppeurs lors du
dveloppement et des tests (environnement de dveloppement, gestionnaires de
sources, tests unitaires, automatisation des dploiements). Ces outils seront
spcifis pour chacune des couches de larchitecture : Outils de dveloppement
des interfaces, IDE pour le dveloppement des composants mtier, outils de
conception de bases de donnes, etc. Cest grce cette vision transverse quil
devient envisageable de dployer dans un build unique des composants Java,
des flux EAI, et des crans Web.
Les Bibliothques : il sagit dun ensemble de fonctions ou dobjets spcifiques au
projet ou lentreprise, et mis disposition des concepteurs et des programmeurs.
On y retrouvera des bibliothques transverses ou spcifiques aux diffrentes
couches de larchitecture, quil sagisse de bibliothques techniques ou mtier :
- Librairies transverses : structures de donnes complexes, gestion des
traces, gestion des erreurs, des alertes dexploitation, du multilinguisme, du
paramtrage, objets mtier transverses
- Librairies spcifiques la couche Prsentation : composants graphiques
rutilisables (boutons, zones de saisie avec cycle de vie, menus, slecteur de
devises, fentre matre-dtail)
Librairies spcifiques la couche Traitements : monte en charge,
gestion du transactionnel, mission et rceptions asynchrones, machine
tat
- Librairies spcifiques la couche Persistance : bibliothque daccs aux
donnes, centralisation des requtes, outils danalyse dimpact
- Librairies spcifiques la couche Echanges : outils de suivi de messages,
dordonnancement des tches, de parsing de messages (ex. Swift, EDI).
- Librairies spcifiques la couche Scurit : authentification mutualise,
gestion des habilitations
La Mthodologie : il sagit de dcrire dans le dtail le processus de
dveloppement de bout en bout (de la conception lintgration : guides de
dveloppement, patterns, mthodologie dintgration continue) en contraignant
lutilisation des outils et des bibliothques dans le contexte du projet.
73
Le volet Production
Ce volet dcrit larchitecture de production et les procdures dexploitation associes :
Architecture de production : serveurs, implantation des composants, topologie
rseau, dimensionnement des machines, mcanismes de clustering, de
sauvegarde et restauration, outils de supervision ou intgration des outils de type
Patrol, Tivoli
Procdures de dploiement et de configuration, procdures dexploitation, de
supervision
La dmarche
La dmarche est compose de trois activits :
La conception de larchitecture technique, qui se base sur les spcifications du
DAG, les principaux use-case fonctionnels et les contraintes darchitecture
technique respecter (contraintes projet issues du DAG, patterns et principes
darchitecture prdfinis au niveau entreprise, etc) pour dfinir larchitecture
technique du SI,
La mise en place oprationnelle du framework de dveloppement,
La ralisation dun prototype et limplmentation dun use-case permettant de
valider la fois le prototype et le framework de dveloppement.
Comme tout difice
informatique,
lArchitecture
Technique se btit
itrativement.
La dmarche se voudra itrative : une premire bauche de lAT permettra de spcifier et

dimplmenter une premire version du framework (outils, librairies, mthodologies), puis une
premire version dun prototype permettra de valider les choix darchitecture et dprouver le
framework de dveloppement. Une deuxime itration permettra denrichir le DAT, de consolider
le framework, etc, jusqu lobtention dune version du DAT et du framework juges suffisamment
stables pour servir de point de dpart aux quipes de dveloppement de la phase
Implmentation.
Il est important de considrer le prototype comme llment central et unificateur des activits de
cette phase : il permet de valider et faire voluer simultanment larchitecture technique et le
framework de dveloppement, car on prototype la fois une architecture ET un framework.
A chaque itration, lactivit de prototypage portera sur un use-case simple mais significatif,
permettant de valider les choix darchitecture effectus pour cette itration et de drouler, valider
de bout en bout une mthodologie de dveloppement (utilisation des outils, des librairies et des
cadres dutilisation du framework).
Enfin, rappelons que lactivit de conception, bien que dj guide par la structuration en
couches, devra se baser autant que possible sur lutilisation de patterns darchitecture, comme
par exemple des patterns EAI48, des patterns dinteroprabilit ou de synchronisation de
rfrentiels comme ceux proposs par IBM49, des patterns SSO, etc.
Exemple : Pattern Gestion du transactionnel tendu entre traitements
Dans un environnement distribu, nous recommandons fortement lutilisation du gestionnaire
dchange comme gestionnaire de transactions entre traitements, sur un mode compensation
(couplage lche entre traitements, lannulation de la transaction se fait grce un processus de
compensation pilot par le gestionnaire dchanges), plutt que denvisager lutilisation de
moniteurs transactionnels XA qui prsuppose que lensemble des traitements soient XAcompliant
48 : EAI Architectural patterns, Jeffrey C. Lutz, http://www.eaijournal.com.

49 : http://www-106.ibm.com/developerworks/patterns/.
74
Le bureau darchitecture en phase dimplmentation

Ltape prcdente a permis didentifier un palier, de finaliser un plan de mise en uvre et de
construire les fondations pour son implmentation. En thorie, tout est prt pour aborder
lindustrialisation du projet. En pratique, nous expliquons dans cette partie en quoi lapplication
des livrables fournis en amont (DAG, PPG, architecture technique, socle et mthodologie)
ncessite un accompagnement mlant rigueur et flexibilit.
Matriser lentropie
inhrente tout
projet informatique.
Bien que nayant pas vritablement vocation prendre en charge la gestion du projet, larchitecte
a comme engagement de matriser son entropie, cest--dire maintenir un certain ordre dans la
ralisation.
Les facteurs endognes dentropie proviennent essentiellement des raccourcis pris
individuellement, initiatives personnelles qui, combines entre-elles, peuvent engendrer
beaucoup de complexit au niveau du projet. Les facteurs exognes ont pour origine les
nouveaux besoins fonctionnels ou les nouvelles contraintes techniques, voire des lments
technologiques dun march en forte maturation, pouvant apparatre au cours de la dure du
projet.
Le rle de larchitecte sera de contenir cette entropie et de grer les vnements imprvus de
faon ce que les volutions requises restent, autant que possible, dans un cadre en cohrence
avec les plans initiaux. Dans tous les cas, il sassurera que les ralisations correspondent bien
aux plans, quil devra ventuellement mettre jour.
Le Bureau
dArchitecture du
projet : une
structure transverse
pour encadrer et
supporter les
travaux de
ralisation.
Une piste pour contenir lentropie est de mettre en place une organisation limage de
larchitecture, cest dire de dcouper le projet en autant de sous-projets correspondant aux
briques applicatives, avec une cellule de pilotage assez rduite et des cellules projets, mixant les
fonctionnels et les techniques.
Pour assurer la cohrence et lalignement de toutes ces quipes sur la stratgie globale du
projet, seule une structure transverse ayant la vision globale et connaissant les tenants et les
aboutissants des plans peut encadrer les travaux de spcification et de ralisation.
Ce Bureau dArchitecture du projet (BA) a une double mission de contrle qualit et de
support. A la croise des interactions entre les diffrents acteurs du projet, son rle peut tre
rparti suivant deux types de prrogatives, fonctionnelles et techniques. Le BA pourra tre une
manation dune structure centrale telle que celle dcrite au chapitre Dmarche darchitecture
dentreprise.
Les prrogatives fonctionnelles du bureau darchitecture

Un certain nombre de livrables ont t produits lors de la phase Etude, parmi lesquels le Dossier
dArchitecture Gnrale (DAG), dfinissant les volets fonctionnels, applicatifs et techniques des
plans de la cible et du palier raliser.
Bien quayant t valid dans les grandes lignes au travers de la conception et le prototypage
dun use case reprsentatif, cette architecture gnrale na pas adress de manire exhaustive
et dtaille tous les cas dutilisation et les processus implmenter. Il faut prsent remplir les
botes et couvrir compltement le primtre dfini.
Laction du BA, la fois en assistance et en validation, peut se structurer autour des thmes
suivants:
75
Sensibilisation et Formation,
Maintenance et Projet,
Interoprabilit,
Homologation des processus transverses.
Sensibiliser la
stratgie et former
aux nouveaux
concepts.
Le BA doit retransmettre et expliquer aux fonctionnels les grands principes qui ont structurs les
choix darchitecture, au travers de formations et autres actions de communication.
Il sagit de les sensibiliser la stratgie fonctionnelle motivant le projet dans son ensemble (telle
que, par exemple, une orientation centre sur le client ou le caractre stratgique dune
remonte du chiffre daffaire la journe) et sur la criticit de certains domaines applicatifs en
particulier.
Il sagit galement de les former sur les patterns qui ont servi de base la conception gnrale
de larchitecture. Par exemple, le BA sera charg de transmettre les rgles qui rgissent le
concept de noyau et ses interactions avec les autres briques applicatives.
Faire appliquer les

plans
Le BA prend tout son sens dans son implication dans les projets. Il apporte son recul et sa vision
transverse en assistant les projets pour btir leur dossier dintgration dans larchitecture globale.
Ainsi, il peut tre amen intervenir plus ou moins directement dans la dfinition et la validation
des spcifications fonctionnelles dune brique applicative, afin de garantir quelle ne sorte pas du
primtre prvu, quelle remplisse bien les fonctions pour lesquelles elle a t conue, et que ces
interactions avec les autres briques soient conformes au modle dchange.
Prenons lexemple dun SI de Distribution : la phase tude a dfini une architecture dans laquelle
les fonctions Paiement, Cash et Facturette ont t regroupes dans une brique Encaissement,
et les fonctions Gestion du Personnel de caisse et Gestion du Catalogue Articles sont ralises
dans dautres briques. Le rle de larchitecte est dassister le chef de projet Encaissement qui ne
connat pas les raisons de cette rpartition fonctionnelle mais doit comprendre comment il va
rsoudre son besoin en termes de code Articles ou de gestion des rotations de caisses.
ou les mettre
jour
Cette implication en profondeur du bureau architecture dans les sous-projets lui permet de
conserver sa capacit danalyse dimpact lors de lapparition dune nouvelle demande et
didentifier les volutions potentielles de larchitecture. Il ne sagit pas l de tenir jour en temps
rel une cartographie exhaustive, mais de prendre en compte avec pertinence les nouveaux
besoins, afin de minimiser limpact sur larchitecture et de garantir la scabilit des briques
applicatives. Lorsque des changements importants sont dcids, il sagit de les formaliser et de
les communiquer aux quipes impactes.
Pour tous ces arbitrages, le BA participe aux comits de validation des projets.
Interoprabilit :
support
mthodologique et
gestion de la
cohrence.
Sur le thme Interoprabilit, le BA fournira un support mthodologique pour la constitution des

spcifications fonctionnelles des flux avec les autres briques. Il encadrera les fonctionnels sur
des sujets tels que le support de transactions longues ou les impacts de la mise en place dune
gestion au fil de leau50.
Il pourra imposer un formalisme commun et lutilisation doutils de type rfrentiel de flux et de
contrats de service.
50 : Voir le prochain livre blanc dOCTO Technology, paratre, sur les mthodologies et les technologies lies la problmatique de linteroprabilit.
76
Homologation des
processus
transverses.
Sur le thme de lhomologation des processus transverses, processus impactant plusieurs

modules, le BA apportera un support en participant lcriture du cahier de recette et des cas de
tests. Il tudiera lopportunit dintroduire un certain niveau dautomatisation dans les tests de
non-rgression, par lutilisation doutils comme ceux proposs par un diteur comme Mercury.
Les prrogatives techniques du bureau darchitecture

Les prrogatives techniques du BA concernent dune part laccompagnement autour du socle, et
dautre part lintgration oprationnelle des briques applicatives pour assurer la cohrence bout
en bout.
Le socle :
des outils et des
mthodologies de
conception et de
dveloppement.
En dernire tape de la phase tude de la dmarche, larchitecture technique a t conue et un

socle a t construit et valid au travers dun prototype reprenant un cas dutilisation
reprsentatif. Ce socle va servir de cadre de travail commun (framework) pour limplmentation
de lensemble des briques applicatives de larchitecture.
Il a pour vocation non seulement dimplmenter les cinq couches de lArchitecture Technique,
mais galement de fournir les guides mthodologiques pour la conception, le dveloppement,
lintgration et lexploitation des briques applicatives.
Le socle contient toute lArchitecture Technique, telle que dcrite dans ltude darchitecture
dtaille, selon les trois volets logiciels, dveloppement et production. Le socle ou une partie du
socle peut tre issu de standards de lentreprise mis en uvre par des structures informatiques
transverses.
Laccompagnement
autour du socle :
assistance, contrle
et maintenance.
En phase dimplmentation, le BA est dpositaire de ce socle. Il est charg den faire la

promotion, dassister les quipes projet, et den vrifier la bonne utilisation, et den assurer la
maintenance pour adresser les nouveaux besoins.
Une de ses principales actions est de former, puis dassister, les quipes de dveloppement
lutilisation de lenvironnement de travail du socle et des mthodes de dveloppements
appliquer.
Un bon socle ne se juge pas au kilo

Il ne sagit pas de noyer les projets sous des tonnes de documentations diteurs, ni de leur imposer
une somme astronomique de rgles contraignantes quils nappliqueront jamais. Lobjectif est de
leur faciliter la tche dacquisition de ce socle par la fourniture de cadres dutilisation prcis et
succincts. Le succs de cette dmarche passe par ladhsion des quipes. Elles doivent percevoir
les gains en efficacit, qualit et flexibilit, issus de la bonne utilisation du socle. Cest pourquoi l
aussi, la formation est primordiale.
Les nouvelles
mthodologies de
dveloppement
mettent lemphase
sur les cycles courts
et la
responsabilisation.
Le principal dfi de cette phase est dduquer sur les principes de dveloppement telles que ceux
mis en avant dans les mthodologies agiles (ex. : eXtreme Programming51). Ces nouvelles
mthodologies sont centres sur les cueils constats dans les projets informatiques, cest dire
la qualit et laptitude supporter le changement. Elles prconisent une collaboration troite et
une forte dlgation de responsabilit aux dveloppeurs, allant de la conception la validation
de leur code, par une utilisation systmatique des tests unitaires52.
51 : http://www.extremeprogramming.org/ ou http://www.xprogramming.com/.
52 : cf. louvrage sur les tests unitaires de Vincent Massol paratre aux ditions Manning (http://www.manning.com/)et le livre blanc dOCTO Technology sur le
dveloppement dapplications, paratre galement.
77
Lautonomie de la
brique, sous
contrle qualit.
Exploitation bout en
bout par un
monitoring
technique et
applicatif.
Maintenance
corrective et
volutive de
linfrastructure
technique.
Une brique est une brique. La dmarche darchitecture consistant dcouper en briques, elle
permet de donner le maximum dautonomie (donc de responsabilits !) aux quipes charges
de leur implmentation ; mais une condition : que cette implmentation respecte les
fondations communes. En consquence, le BA peut notamment oprer des revues de codes ou
de tests unitaires pour vrifier la qualit des dveloppements. Le cas chant, lorsque le
framework a t contourn sans son accord, il pourra exiger le re-factoring du module concern.
En bout de chane, le BA sensibilisera les quipes de production lexploitation de bout en bout,
en mettant notamment en place des outils et des procdures de gestion dalertes applicatives.
Lobjectif est de responsabiliser ces populations, en plus de lexploitation des ressources
techniques (rseaux, machine, etc.), un niveau dexploitation applicatif, tels que par exemple
le dpassement de seuil haut ou bas de files dattente, ou lallongement des temps de rponse.
Une collaboration entre le BA et les quipes de production sera privilgier.
Quelque soit la taille ou la dure du projet, un travail de maintenance des infrastructures est
prvoir. Dune part, les bugs techniques ou les lacunes fonctionnelles dtects par les utilisateurs
(les quipes de dveloppement, dintgration et dexploitation) devront tre corrigs. Dautre part,
les volutions fonctionnelles ou les innovations technologiques donneront lieu de la
maintenance volutive sur le socle.
Au sein de lquipe du BA, des experts techniques de chaque couche sassureront, lors de la
phase dinitialisation et tout au long de la vie du projet, du btonnage du socle en termes
notamment de scurit, de performance, de tolrance aux pannes et dvolutivit. Ces experts
seront rgulirement sollicits pour la rsolution des problmes, le passage des patchs diteurs,
voire la monte de version des produits utiliss dans le socle.
Une des dernires prrogatives techniques ( last but not least , comme le veut la formule
consacre) est la responsabilit de la plate-forme dintgration.
Responsabilit de la
plate-forme
dintgration.
Comme nous avons pu dj lvoquer plusieurs reprises dans ce document, le principe de la

dmarche darchitecture Projet est de dclater une problmatique en plusieurs briques et de
rintgrer leurs implmentations dans une solution globale et homogne rpondant au besoin
exprim.
En collaboration avec les quipes applicatives du BA, les quipes techniques doivent donner les
moyens aux briques de tester leurs fonctionnalits indpendamment de la disponibilit des
autres briques, puis de les intgrer aux autres briques.
Il faut par consquent dune part leur fournir des injecteurs et des bouchons simulant
les interactions externes, et dautre part disposer dun environnement dintgration permettant la
recette progressive des briques par la mise en uvre des processus transverses : passage des
tests de bout en bout et construction des packages constituant la solution globale.
Conclusion
Sil nintervient pas directement dans limplmentation des briques applicatives, le BA est
pourtant omniprsent, car responsable du respect de larchitecture sur laquelle il sest engag en
phase Etude.
Plus il sera pdagogue et convaincant en assistance, meilleure sera la qualit des ralisations,
et par consquent moins il aura exercer de rle coercitif.
78
La formation sur site est un lment cl de la matrise de la qualit.

Comme toute activit industrielle, linformatique sest attache dans ses premires heures
produire vite, sans souci rel de qualit, de dveloppement durable, et de beaut finalement.
Lorsque Michel Pbereau parle de Cathdrales propos de nos Systmes dInformation, son
lyrisme travestit une ralit constitue dusines encombres plutt que ddifices gothiques. Car
limage des usines industrielles du milieu du sicle dernier, o se trouve le beau ?
Cette notion de beau a fait son chemin dans lentreprise pour amliorer globalement les
conditions de travail. Larchitecture de Systmes dInformation est quant elle une discipline
jeune, qui a motiv la cration dOCTO. Pour les mmes raisons, peut-tre nous conduira-t-elle
jusqu des activits de design, des architectures signes Stark , ou comme me le soufflait
un client, OCTO des architectures vivre .
79
VI. Bibliographie
[1] Nouvelle conomie : rapport Daniel Cohen et Michle Debonneuil - Paris : La
Documentation franaise, 2000. 251 p. (Collection Les Rapports du Conseil danalyse
conomique ; 28).
[2] Frdric Frry : Benetton ou lentreprise virtuelle , Vuibert, 1999.
[3] Blown into Bits : How the New Economics of Information Transforms Strategy (ou
comment la nouvelle conomie de linformation transforme la stratgie), de Philip Evans et
Thomas Wurster, publi par Harvard Business School Press courant 1999.
[4] Les Echos Un systme dInformation pour tre comptitif, de Peter Weill et Marianne
Broadbent.
[5] Les Echos Les organisations du XXIe sicle, de Marc Lemarignier et Jessica Scale.
[6] Urbanisation du business et des SI, de Grard Jean (d. Herms).
[7] Le projet durbanisation du systme dinformation, de Christophe Longp
ISBN 2-100-05694-8 Dunod.
[8] Evaluating Software Architectures Methods and Case Studies
Paul Clements, Rick Kazman, Mark Klein ISBN 0-201-70482-X202 Addison-Weisley.
[9] Le processus unifi de dveloppement logiciel - Ivar Jacobson, Grady Booch, James
Rumbaugh ISBN 2-212-09142-7 Eyrolles.
[10] UML en action Pascal Roques, Franck Valle ISBN 2-212-09127-3 Eyrolles.
[11] La socit de la connaissance - Jean-Pierre Corniou, Herms.
[12] Design Patterns, Elements of Reusable OO software, The Gang of 4.
[13] Pattern Oriented Software Architecture, Editions Wiley & Sons.
[14] The 4+1 view model of software architecture, IEEE 1995.
[15] France Tlcom, Mmento Technique N14 (www.rd.francetelecom.fr).
[16] EAI Architectural patterns, Jeffrey C. Lutz.
80
VII. A propos dOCTO Technology

www.octo.com
OCTO Technology est le cabinet de conseil en Architecture de Systme dInformation du groupe
Aubay. Depuis sa cration en 1998, OCTO Technology publie les fruits de ses expriences sous
forme de livres blancs. Ils sont diffuss et diffusables gratuitement.
Aprs avoir publi autour des trois offres technologiques : les serveurs dapplications et
IRM, lEAI, et la Scurit, OCTO Technology vous propose ce dernier Livre Blanc, qui synthtise
son savoir faire en terme de construction darchitectures complexes. Dans ce domaine, ses
clients sont des acteurs grands comptes, soucieux dexploiter au mieux les nouvelles
technologies, et considrant larchitecture comme un enjeu stratgique pour leur SI daujourdhui
et de demain. Citons parmi eux : Air Liquide, BNP Paribas, Natexis, Socit Gnrale, France
Tlcom, Total Fina Elf, JC Decaux, Vivendi, Orange, Wanadoo ...
OCTO Technology 2002

Les informations contenues dans ce document reprsentent le point de vue actuel dOCTO
Technology sur les sujets voqus, la date de publication. Tout extrait ou diffusion partielle est
interdite sans lautorisation pralable dOCTO Technology.
Les noms de produits ou de socits cits dans ce document peuvent tre les marques
dposes par leurs propritaires respectifs.
Auteurs :
Les auteurs de ce document sont des consultants dOCTO Technology, par ordre alphabtique :
Laurent Avignon, Gilles Laborderie, Rmy Mathieu-Daud, et Pierre Pezziardi.
Remerciements spciaux Eric Groise sans qui ce libre blanc naurait jamais vu le jour, et
Lyonel Thouvenot pour la qualit visuelle du produit fini.
Pour tout complment dinformations : architecture@octo.com
Bibliographie OCTO Technology

Le Livre Blanc des Serveurs dApplication OCTO Technology 1999
Serveurs dApplications (d. Eyrolles)
Le Livre Blanc de lEAI OCTO Technology 1999
Intgration dApplications (d. Eyrolles)
Le Livre Blanc de lIRM OCTO Technology 2000
Le projet eCRM (d. Eyrolles) - laurat du prix AFISI 2002
Le Livre Blanc de la Scurit OCTO Technology 2001
Architectures de Systmes dInformation, Livre Blanc OCTO Technology 2002
81
Dpt lgal : Dcembre 2002

Imprim pour OCTO Technology chez
PORTAPRINT - 2 rue du Blanc-Seau
59334 - TOURCOING CEDEX
N de dosier : 2002110026
82
OCTO Technology - 62 rue La Botie - 75008 Paris

Tl : (33) 1 58 56 10 00 - Fax : (33) 1 58 56 10 01 - http://www.octo.com

Sys Info

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Sys Info

Transféré par

Droits d'auteur :

Formats disponibles

Architectures de Systmes dInformation

Table des matires

Dmarche darchitecture dentreprise .............................................................................................................13

Etat de lart des principes darchitecture ........................................................................................................18

Les outils de larchitecte...................................................................................................................................33

Dmarche darchitecture projet........................................................................................................................48

VII. A propos dOCTO Technology..........................................................................................................................81

Architectures de Systmes dInformation

Prface de Franois Tabourot

Comment larchitecture et lurbanisme apportent une rponse

De lorganisation des ressources la justification conomique

Architectures de Systmes dInformation

Urbanisme et rduction des cots

Architectures de Systmes dInformation

Urbanisme et production de valeur

Architectures de Systmes dInformation

Lurbanisme nouveau permet de rapprocher la cartographie du systme dinformation de la

Un nouveau rle pour le Directeur Informatique

Architectures de Systmes dInformation

Architectures de Systmes dInformation

: Gestion lectronique des achats.

Architectures de Systmes dInformation

Elle est un ciment

Des consquences inattendues sur le march informatique

8 : Frdric Frry : Benetton ou l'entreprise virtuelle .

Architectures de Systmes dInformation

partiellement lcart de ce mouvement massif de progicialisation. Pour combien de temps ?

Restaurer la confiance ncessitera daugmenter le taux de

Architectures de Systmes dInformation

Pourquoi ne pas appliquer linformatique les mthodes

Les plans de nos

16 : Les Echos, 12 dcembre 2001

Architectures de Systmes dInformation

Labsence de dmarche darchitecture de SI na pas nui la mise en place unitaire dapplications.

La dmatrialisation complte de chanes de traitements ncessite une intgration des donnes

La technologie nest pas un messie, elle fait simplement partie

Heureusement larchange Technologie vient notre secours, me direz-vous. La technologie aide,

Architectures de Systmes dInformation

La gestion du changement sappliquera aussi aux DSI

Architectures de Systmes dInformation

II. Dmarche darchitecture dentreprise

Mille et une DSI

17 : Un systme dInformation pour tre comptitif, de Peter Weill et Marianne Broadbent.

Architectures de Systmes dInformation

A quoi sert une DSI ?

Btir la stratgie du Systme dInformation et la communiquer

20 : Les organisations du XXIe sicle, de Marc Lemarignier et Jessica Scale.

Architectures de Systmes dInformation

Crer et promouvoir les ouvrages transverses du SI

Insuffler et contrler les orientations des projets

Grer linteraction de lentreprise avec les organismes de

La DSI, une SSII comme les autres ?

Quest-ce qui diffrencie un chef de projet, un concepteur, un dveloppeur, un support

Architectures de Systmes dInformation

Une activit de haute prcision

Architectures de Systmes dInformation

Architectures de Systmes dInformation

III. Etat de lart des principes darchitecture

21 : Unified Modeling Langage.

Architectures de Systmes dInformation

La dmarche de modlisation UML

22 : Open Management Group (www.omg.org). LOMG a notamment normalis CORBA et MDA.

Architectures de Systmes dInformation