These Sur La GSI

Conceptualisation de la Gouvernance des Systèmes
dInformation : Structure et Demarche pour la

Construction des Syst` emes dInformation de
Gouvernance
Bruno Claudepierre
To cite this version:

Bruno Claudepierre. Conceptualisation de la Gouvernance des Systèmes dInformation : Struc-
ture et Demarche pour la Construction des Systèmes dInformation de Gouvernance. Ingenierie,
finance et science [cs.CE]. Universite Pantheon-Sorbonne - Paris I, 2010. Francais. <tel-
00748984>
HAL Id: tel-00748984

https://tel.archives-ouvertes.fr/tel-00748984
Submitted on 6 Nov 2012
HAL is a multi-disciplinary open access Larchive ouverte pluridisciplinaire HAL, est

archive for the deposit and dissemination of sci- destinee au depot et à la diffusion de documents
entific research documents, whether they are pub- scientifiques de niveau recherche, publies ou non,
lished or not. The documents may come from emanant des etablissements denseignement et de
teaching and research institutions in France or recherche francais ou etrangers, des laboratoires
abroad, or from public or private research centers. publics ou prives.
THESE DE DOCTORAT
DE LUNIVERSITE PARIS I PANTHEON - SORBONNE
Spcialit : Informatique
Bruno Claudepierre
Pour lobtention du titre de :

DOCTEUR DE LUNIVERSITE PARIS I PANTHEON - SORBONNE
Conceptualisation de la Gouvernance des

Systmes dInformation
Structure et Dmarche pour la Construction des Systmes

dInformation de Gouvernance
Soutenue le 10 dcembre 2010 devant le jury compos de

M. Khalid BENALI Prsident du jury
Mme Colette ROLLAND Directeur de thse
Mme Selmin NURCAN Codirecteur de thse
Mme Corine CAUVET Rapporteur
Mme Camille ROSENTHAL-SABROUX Rapporteur
M. Bahram SOLTANI Membre du jury
A la mmoire de Michle Claudepierre et Ren Claudepierre, disparus en cette anne 2010.
Remerciements
Je souhaite, en premier lieu, exprimer mes plus vifs remerciements au Pr. Colette Rolland,
directrice du Centre de Recherche en Informatique, ainsi quau Pr. Pierre-Yves Hnin, prsident de
luniversit Paris I Panthon Sorbonne (2004-2009), pour mavoir accueilli dans leurs tablissements
et pour mavoir paul dans lobtention de financements, sans lesquels cette thse naurait pas pu voir
le jour.
Je remercie aussi le Pr. Colette Rolland, Professeur lUniversit Paris I - Panthon Sorbonne,
et le Dr. Selmin Nurcan, Matre de Confrences lUniversit Paris I Panthon Sorbonne, pour avoir
accept la direction scientifique de cette thse, pour leurs conseils aviss et leur soutien.
Je remercie sincrement le Pr. Camille Rosenthal-Sabroux, Professeur l'Universit Paris

Dauphine, et le Pr. Corine Cauvet, Professeur lUniversit Paul Czanne Aix-Marseille III, qui ont
eu la gentillesse daccepter le rle de rapporteur.
Mes remerciements vont aussi au Dr. Khalid Benali, Matre de Confrences HDR
lUniversit Nancy II, pour avoir accept la prsidence du jury de cette thse, ainsi quau Dr. Bahram
Soltani, Matre de Confrences HDR lUniversit Paris I Panthon Sorbonne, pour avoir accept
linvitation qui lui a t faite de se joindre au jury.
Je remercie vivement toute lquipe du Centre de Recherche en Informatique, sans qui mes
aventures estudiantines et scientifiques auraient t beaucoup moins plaisantes. Je pense plus
particulirement Franoise, Carine, Rebecca, Daniel, Camille, Elna, Kahina, Oumaima, Islem
Assia, Sana, Salma, Adrian, Raul, Deniz, Kadan, Hicham et Ramzi pour leurs encouragements
quotidiens.
Enfin je tiens aussi remercier ma famille, mes proches et mes amis pour leur soutien et leur
patience. Une pense particulire pour Yannick, Willy et Sylvain : leur soutien inconditionnel et leur
humanit mont souvent t plus que salutaire. A ma mre, pour avoir eut le courage dabandonner ses
alexandrins afin de se consacrer aux (re)lectures de ma thse.
Merci
~i~
Rsum
La gouvernance des systmes dinformation (GSI) relve la responsabilit des dirigeants de
lentreprise. La GSI est une organisation pour la prise de dcision et rpond aux proccupations
importantes des directeurs de systmes dinformation (DSI), pour assurer, dans le temps, les
volutions ncessaires du systme dinformation (SI), et lui permettre de rpondre des besoins de
limitation des risques, de conformit rglementaire, de cration de valeur ou dalignement. Comme un
grand nombre dactivits des organisations, la GSI doit trouver une rponse outille par lintermdiaire
des applications du SI. Bien que ces outils existent, ils ne sont jamais dvelopps en considrant les
activits de la GSI dans leur ensemble.
Nous rpondons ce manque de considration par la conceptualisation de la GSI. Nous avons

ainsi propos REFGOUV (modle de REFrence pour la GOUVernance). Il construit larchitecture des
concepts de la GSI. PROGOUV (modle des PROcessus de GOUVernance) est notre deuxime
proposition conceptuelle : il permet de construire le cadre dynamique pour la manipulation des
concepts de REFGOUV. La force de notre approche est quelle intgre un cycle de gouvernance comme
un processus dcisionnel et intentionnel qui se base sur lanalyse des carts entre une situation de
gouvernance prvue et une situation constate. Les dcisions y ont un impact endogne sur le
portefeuille des projets SI et les objectifs de la gouvernance.
Cette recherche a t valide par plusieurs tudes : le cas PAPCAR illustre un exemple
dapplication de REFGOUV et PROGOUV une situation dentreprise. Une deuxime tude a port sur
la confrontation du pouvoir de reprsentation conceptuelle de REFGOUV par rapport ceux de CobiT,
ITIL et COSO. Il ressort de cette tude que REFGOUV a la capacit, non seulement dimplmenter les
concepts de ces rfrentiels de gouvernance, mais aussi de les tendre.
Cette thse permet ainsi de capitaliser et de structurer la connaissance du domaine de la GSI et

denvisager la construction dun SI intgr, align avec les activits de gouvernance des SI.
Mots Cls : gouvernance des systmes dinformation, conceptualisation, modlisation, ingnierie du

systme dinformation.
~ iii ~
Abstract
IT Governance (ITG) is the responsibility of the executives. ITG is an organization for
decision making and addresses important concerns for chief information officers (CIOs) to ensure,
over the time, that changes enable the IT to meet the needs of risk mitigation, regulatory compliance,
creation of value, or alignment. Like many business activities of organizations, the ITG should find
tooled responses through IT applications. Although these tools exist, they are never developed by
considering the ITG activities as a whole.
We respond to this lack of consideration by the conceptualization of ITG. We have proposed

REFGOUV (REFerence model for GOVernance). It builds the architecture of ITG concepts. PROGOUV
(PROcesses model for GOVernance) is our second conceptual proposal: it lets us build the dynamic
framework for handling REFGOUV concepts. The strength of our approach is that it incorporates a
cycle of governance as a decision-making and intentional process based on the analysis of differences
between an expected situation of governance and findings. Decisions have an endogenous impact on
the IT projects portfolio and governance goals.
This research has been validated by several studies: the case PAPCAR is an application
sample of REFGOUV and PROGOUV to a business situation. A second study focused on confrontation
of the conceptual strength of REFGOUV compared to those of CobiT, ITIL and COSO. This study
shows that REFGOUV has the ability, not only to implement the concepts of governance frameworks,
but also to expand them.
This thesis can thus build the domain knowledge of the ITG and consider the construction of
an IS integrated and aligned to the activities of IT governance.
Keywords: governance of information systems, conceptualization, modeling, engineering information

system.
~ iv ~
Sommaire
CHAPITRE 1. INTRODUCTION ................................................................................................................ 1
1.1. Domaine........................................................................................................................................ 1
1.2. Constat.......................................................................................................................................... 4
1.3. Problmatique.............................................................................................................................. 6
1.4. Mthode de rsolution ................................................................................................................. 7
1.5. Apports et rsultats ..................................................................................................................... 8
1.6. Plan de la thse ............................................................................................................................ 9
CHAPITRE 2. ETAT DE LART............................................................................................................... 11
2.1. Introduction ............................................................................................................................... 11

2.2. Cadre de rfrence pour les approches de la gouvernance des SI ........................................ 11
2.2.1. Mta-modle utilis ............................................................................................................... 12
2.2.2. Description du cadre de rfrence ......................................................................................... 12
2.2.2.1. Le monde du sujet de la GSI ........................................................................................... 14
2.2.2.2. Le monde de lusage de la GSI........................................................................................ 19
2.2.2.3. Le monde du systme de la GSI....................................................................................... 22
2.2.2.4. Le monde du dveloppement de la GSI ........................................................................... 25
2.3. Positionnement des approches ................................................................................................. 29
2.3.1. Les approches de la gouvernance des SI ............................................................................... 29
2.3.1.1. CobiT : Control Objectives for information and technology .......................................... 29
2.3.1.2. COSO : The Committee of Sponsoring Organizations of the Trendway Commission .... 29
2.3.1.3. ITIL : IT Infrastructure Library ...................................................................................... 30
2.3.1.4. CMMI : Capability Maturity Model Integrated .............................................................. 31
2.3.1.5. PMBOK : Project Management Body of Knowledge ...................................................... 32
2.3.2. Synthse du positionnement .................................................................................................. 33
2.4. Conclusion .................................................................................................................................. 36
CHAPITRE 3. APERU DE LA SOLUTION .............................................................................................. 37
3.1. Introduction ............................................................................................................................... 37

3.2. Rappel de la Problmatique et des hypothses de travail ...................................................... 37
3.2.1. Problmatique ....................................................................................................................... 37
3.2.2. Hypothses ............................................................................................................................ 38
3.3. Solution....................................................................................................................................... 38
3.3.1. Proposition ............................................................................................................................ 38
3.3.2. Lunivers des modles ........................................................................................................... 40
3.3.2.1. REFGOUV : dimension statique du SI de gouvernance .................................................... 40
3.3.2.2. PROGOUV : dimension dynamique du SI de gouvernance ............................................... 41
3.3.2.3. MISIG : Mthode dIngnierie du Systme dInformation de Gouvernance .................. 42
3.3.3. Lunivers des langages .......................................................................................................... 43
3.3.3.1. UML : mta-concepts pour la dfinition des concepts de GSI ........................................ 43
3.3.3.2. MAP : mta-concepts pour la dfinition des processus de GSI ...................................... 43
3.3.4. Lunivers des systmes.......................................................................................................... 44
3.4. Synthse des apports ................................................................................................................. 44
CHAPITRE 4. REFGOUV : MODELE DE REFERENCE DU DOMAINE DE LA GSI .................................. 45
~v~
4.1. Introduction ............................................................................................................................... 45
4.2. Reprsentation des concepts ..................................................................................................... 46
4.3. REFGOUV : Modle de rfrence du domaine de la GSI ........................................................ 49
4.3.1. La notion de but et concepts associs .................................................................................... 51
4.3.1.1. Des buts et des mots ........................................................................................................ 51
4.3.1.2. Catgories de buts ........................................................................................................... 52
4.3.1.3. Exemples de buts pour la GSI ......................................................................................... 53
4.3.1.4. Reprsentation des buts de la GSI................................................................................... 54
4.3.2. La notion de projet et concepts associs ............................................................................... 56
4.3.2.1. Le constituant processus dun projet .............................................................................. 57
4.3.2.2. Le constituant ressource dun projet............................................................................... 59
4.3.2.3. Le constituant risque dun projet .................................................................................... 61
4.3.3. La notion de mesure et concepts associs ............................................................................. 62
4.3.3.1. De la mesure la mtrique : 200 ans dhistoire ............................................................. 63
4.3.3.2. Mtriques et indicateurs pour les systmes dinformation .............................................. 65
4.3.3.3. Le tableau de bord de la GSI .......................................................................................... 72
4.3.4. La notion de dcision et concepts associs ........................................................................... 74
4.4. Conclusion .................................................................................................................................. 76
CHAPITRE 5. PROGOUV : MODELE DE PROCESSUS DE LA GSI ......................................................... 79
5.1. Introduction ............................................................................................................................... 79

5.2. Formalisme de modlisation de PROGOUV ............................................................................. 80
5.2.1. Le formalisme de la CARTE ................................................................................................. 80
5.2.2. Concepts de la CARTE ......................................................................................................... 81
5.2.2.1. Intention .......................................................................................................................... 81
5.2.2.2. Stratgie .......................................................................................................................... 82
5.2.2.3. Section ............................................................................................................................. 82
5.2.2.4. Formes agrgatives de sections ...................................................................................... 83
5.2.2.5. Excution et principes de guidage .................................................................................. 85
5.2.2.6. Relation avec les concepts de REFGOUV ......................................................................... 87
5.2.3. Vrification dune CARTE ................................................................................................... 88
5.2.3.1. Validation ........................................................................................................................ 88
5.2.3.2. Invariant de la CARTE .................................................................................................... 88
5.2.4. Prsentation gnrale du mta-modle de processus PROGOUV ........................................... 89
5.2.4.1. Structure dun processus PROGOUV ............................................................................... 89
5.2.4.2. Structure et indexation des lments du processus ......................................................... 90
5.3. Modle de processus PROGOUV ............................................................................................... 91
5.3.1. La dmarche de gouvernance des SI ..................................................................................... 92
5.3.2. La CARTE C : Gouverner le systme dinformation ............................................................ 93
5.3.2.1. Composant graphique ..................................................................................................... 93
5.3.2.2. Composants de guidage pour la slection dintention .................................................... 94
5.3.2.3. Composants de guidage pour la slection de stratgie ................................................... 95
5.3.2.4. Composants de guidage pour laccomplissement dintention ......................................... 98
5.3.2.5. Composant produit .......................................................................................................... 99
5.3.3. La carte C.Cab1 : Elaborer les buts de la gouvernance des systmes dinformation ............ 100
5.3.3.1. Composant graphique ................................................................................................... 100
5.3.3.2. Composants de guidage pour la slection dintention .................................................. 101
5.3.3.3. Composants de guidage pour la slection de stratgie ................................................. 103
5.3.3.4. Composants de guidage pour laccomplissement dintention ....................................... 105
5.3.3.5. Composant produit ........................................................................................................ 110
5.3.4. La carte C.Cbb1 : Gouverner le SI depuis Gouverner le SI par planification des projets ..... 110
~ vi ~
5.3.5. La carte C.Cbb2 : Gouverner le SI depuis Gouverner le SI par prise de dcision ................ 127
5.4. Discussion et conclusion .......................................................................................................... 140
CHAPITRE 6. EVALUATION ................................................................................................................ 143
6.1. Introduction ............................................................................................................................. 143

6.2. Conceptualisation des rfrentiels de la GSI ........................................................................ 144
6.2.1. CobiT................................................................................................................................... 144
6.2.1.1. Historique et usages du rfrentiel CobiT .................................................................... 144
6.2.1.2. Conceptualisation de CobiT .......................................................................................... 145
6.2.2. ITIL ..................................................................................................................................... 148
6.2.2.1. Historique et usages du rfrentiel dITIL .................................................................... 148
6.2.2.2. Conceptualisation dITIL .............................................................................................. 150
6.2.3. COSO .................................................................................................................................. 151
6.2.3.1. Historique et usages du rfrentiel COSO .................................................................... 151
6.2.3.2. Conceptualisation de COSO ......................................................................................... 154
6.3. Proposition de mtriques de correspondance conceptuelle ................................................. 155
6.3.1. Nombre total des classes de modle .................................................................................... 155
6.3.2. Nombre des relations de correspondance entre deux modles ............................................ 155
6.3.3. Degr relationnel dun modle ............................................................................................ 155
6.3.4. Compltude conceptuelle .................................................................................................... 156
6.3.5. Charge conceptuelle ............................................................................................................ 156
6.4. Comparaison de REFGOUV avec les rfrentiels de la GSI ................................................. 156
6.4.1. Mesures de correspondance conceptuelle entre CobiT et REFGOUV .................................. 157
6.4.2. Mesures de correspondance conceptuelle entre ITIL et REFGOUV..................................... 158
6.4.3. Mesures de correspondance conceptuelle entre COSO et REFGOUV ................................. 159
6.4.4. Bilan de ltude comparative............................................................................................... 161
6.5. Evaluation de PROGOUV : le scnario PAPCAR .................................................................. 162
6.5.1. Synthse du cas ................................................................................................................... 162
6.5.2. Etape 1 Initialisation du processus de GSI de PAPCAR .................................................. 163
6.5.2.1. Composant de choix ...................................................................................................... 163
6.5.2.2. Composant dexcution ................................................................................................. 163
6.5.2.3. Composant descriptif .................................................................................................... 163
6.5.3. Etape 2 Initialisation du processus de planification des projets de PAPCAR .................. 169
6.5.4. Etape 3 Initialisation du processus de dcision des investissements sur les projets
PAPCAR ....................................................................................................................................... 185
6.5.5. Finalisation du processus de GSI de PAPCAR ................................................................... 193
~ vii ~
6.5.6. Bilan du cas PAPCAR......................................................................................................... 194
6.6. Positionnement de la Mthode dIngnierie des SI de Gouvernance ................................. 195
6.7. Conclusion ................................................................................................................................ 197
CHAPITRE 7. CONCLUSION ................................................................................................................ 199
7.1. Contributions ........................................................................................................................... 199

7.2. Perspectives de recherche ....................................................................................................... 200
REFERENCES BIBLIOGRAPHIQUES.................................................................................................... 203
ANNEXE A - ENONCE DU CAS PAPCAR ........................................................................................... 211
~ viii ~
Chapitre 1. Introduction
1.1. Domaine
Cette thse porte sur le domaine de la gouvernance des systmes dinformation.
La gouvernance dentreprise est un mcanisme de rgulation permettant de sassurer que la

stratgie de lorganisation est effectivement mise en uvre sur le terrain. Elle est de plus en plus
perue comme un mcanisme permettant de mettre en place une srie de processus susceptibles de
maintenir lentreprise stable, de responsabiliser lensemble des acteurs et de faire en sorte que tous les
acteurs sapproprient les processus, en totale transparence, avec une politique de communication bien
identifie, et des rles clairement dfinis.
La gouvernance des systmes dinformation (GSI) fait partie intgrante de la gouvernance

dentreprise. Elle correspond la mise en place des moyens par lesquels les parties prenantes peuvent
sassurer de la prise en compte de leurs proccupations dans le fonctionnement du systme
dinformation (SI). La GSI vise ainsi dfinir les objectifs assigns au systme dinformation,
planifier, dfinir et mettre en uvre les processus lis la gestion du cycle de vie du SI. Ces activits
reposent sur le contrle et la mesure de la performance de ces processus au regard des objectifs qui
sous-tendent lusage qui est fait du SI.
Tout systme peut tre dirig/matris/mis sous contrle condition de savoir dfinir (i) les
dispositifs permettant de mesurer si les objectifs qui lui ont t assigns sont atteints et dans le cas
contraire (ii) les leviers (variables) daction pour corriger les carts. Selon la cyberntique, la science
de contrle des systmes, un systme ne peut tre matris a priori que si le systme de pilotage a une
varit au moins gale. Autrement dit, sil y a autant de rponses que dtats possibles du systme
piloter. Plutt que de construire une grande varit de dispositifs de pilotage (coteux), il semble plus
prometteur de miser sur des systmes de pilotage pouvant sadapter et apprendre. Le systme de
pilotage doit donc disposer dun organe qui lui permette de mmoriser et de raisonner.
Une dfinition descriptive de la gouvernance consiste considrer quelle dcrit comment un

systme est dirig et contrl1. Ainsi dfinie, la gouvernance est lassociation du pilotage, cest--dire
sassurer que les dcisions daujourdhui prparent convenablement demain, et du contrle, cest--
dire mesurer lcart par rapport ce qui tait prvu. Peter Weill (Weill, 2004) oriente la dfinition de
la GSI en se concentrant sur le concept de dcision : la GSI est un processus de pilotage qui vise
matriser les dcisions prendre ainsi que les risques sous-jacents et orienter les dcisions en vue
daugmenter la valeur et de minimiser les risques pour lorganisation.
1
Gouvernance du systme dinformation, Rapport Cigref, 2002, http://www.cigref.fr
1
Parmi les mthodes de IT Gouvernance, ITIL et COBIT sont les plus en vogue. Appliques
sur un systme dinformation dploy et en usage en entreprise, ces mthodes permettent de dfinir
des indicateurs pour le contrle et le pilotage du SI.
La gouvernance des systmes dinformation (GSI) peut se dfinir comme la dmarche

travers laquelle les professionnels des SI, confronts un problme de dcision ayant comme objet
le SI, vont (i) dfinir et prioriser des objectifs pour les projets de SI en cohrence avec la stratgie de
lorganisation, et (ii) envisager des leviers daction sur le portefeuille de projets en se basant sur des
valuations quantitatives qui elles seules pourront supporter des choix dvolution arguments.
L'objet de la gouvernance du SI est donc le Systme dInformation. Les orientations

stratgiques et les objectifs qui sont assigns au SI seront progressivement atteints par la ralisation
des projets de dveloppement de SI. Ainsi, la GSI met en musique et dirige les volutions du SI
souhaites par la matrise douvrage. Le portefeuille de projets de SI est son instrument privilgi dont
les accords vont progressivement transformer le SI en usage. La relation GSI-SI tant ainsi dfinie, il
convient maintenant de clarifier le propos dun systme dinformation.
Un SI a pour mission de rendre les activits principales de l'organisation gnratrices de

davantage de valeur ajoute. Il tire parti des technologies informatiques (mmorisation,
communication, calcul, transformation, prsentation) pour tablir un rseau de coordination entre les
activits de lorganisation ainsi quun rseau de coopration entre les acteurs de lorganisation. Le SI
constitue un support dinformation et de dcision au service de chaque activit et de chaque acteur.
Aujourdhui, de tels services informationnels reposent, pour la plupart, sur les technologies
informatiques et conduisent assimiler, souvent tort, systmes dinformation et systmes
informatiques. Rappelons que la distinction essentielle entre les deux repose sur la diffrence entre
objectifs et moyens, autrement dit entre besoins et solutions.
Nous dfinissons un SI comme un ensemble organis de ressources technologiques (matriel

et logiciel) et humaines (acteurs et usagers du SI) visant outiller la ralisation des activits de
toute nature (oprations, dcisions, collaborations, capitalisation des savoir-faire) de lorganisation.
Cette dfinition positionne lobjet SI suivant trois axes :
Service : la notion de service des technologies de linformation et de la

communication (TIC) est relativement rcente. Cest une philosophie oriente usagers
qui considre que les TIC sont un support la bonne excution des processus mtier.
Le service est un paradigme important pour l'organisation des entreprises ainsi que
pour la coopration inter-organisationnelle en vue d'obtenir un avantage concurrentiel.
Il n'est alors pas tonnant d'observer que les plus grandes entreprises aux Etats-Unis
tirent plus de 50% de leurs revenus des services (Allmendinger, 2005). Grce aux
2
services, les entreprises stabilisent leurs revenus. Cela s'applique non seulement aux
services de base comme le transport, mais aussi pour lamlioration de la production
des ressources matrielles par des services comme la maintenance, le conseil et la
formation. L'change de services au sein des partenariats permet aux entreprises de
mesurer et de combiner leurs comptences, et de proposer ainsi des solutions leur
clientle qui n'auraient pu tre envisages par lune ou lautre des entreprises de
manire autonome et solitaire. L'ingnierie d'entreprise base de services (SOE)
repose sur le paradigme de slection des services que l'entreprise va ajouter dans son
portefeuille de comptences et proposer ses clients. Les objectifs et les stratgies de
l'entreprise sont mis en correspondance (mapps) avec une architecture d'entreprise
qui structure ses services en couches (Nurcan, 2009) : services mtier, services
logiciel, services technologiques (plateforme et infrastructure).
Technologie : les technologies de linformation et de la communication (TIC)
permettent dinstrumentaliser un support dinformation et de dcision au service de
chaque activit. Cependant la technologie nest pas quun simple support de
lautomatisation de linformation. Elle est aussi un levier qui permet de dcupler les
forces, et peut devenir une arme stratgique si toutefois lusage qui saurait le
permettre est identifi. Les services mtiers innovants ne sont souvent pas ralisables
sans des services IT au sens propre du terme, la technologie devient ainsi levier
indispensable pour soulever un poids que lon ne pourrait soulever autrement. Il est
dsormais communment admis que ce nest pas la possession des ressources
technologiques qui constitue les bases solides pour un avantage concurrentiel et
durable mais de savoir les administrer et manager (Mata, 1995), autrement dit en faire
lusage appropri au regard des besoins de lentreprise. Selon Ross et al. (Ross, 2006),
les entreprises intelligentes dfinissent comment elles vont exercer leur mtier (en
utilisant un modle du systme oprant) et dveloppent les processus mtier et
linfrastructure technologique ncessaires leurs oprations courantes et futures (i.e.
architecture dentreprise) pour guider lvolution de leurs fondations. De plus en
plus de compagnies mettent le vu que leurs infrastructures technologiques rendent
possible leurs capacits futures. Cette aptitude exploiter les fondations en y intgrant
de nouvelles initiatives pour les renforcer et en les utilisant comme une arme au
service de la comptitivit pour dvelopper de nouvelles opportunits mtier est
estime seulement 5% des compagnies (Ross, 2006).
Organisation : le SI est un ensemble organis de ressources technologiques et
humaines dont lobjectif est la production de services destination des parties
prenantes de lentreprise. Le SEI (Software Engineering Institute) propose une analyse
de la maturit reposant sur la notion de processus (Stoddard, 2010). Le processus est
3
alors vu comme le moyen de mettre en cohrence les ressources afin daccomplir un
objectif fix.
1.2. Constat
Les objectifs de la GSI consistent principalement aligner les services offerts par le SI avec
les objectifs mtiers, de protger et dassurer la scurit de linformation de lentreprise dans un
contexte flottant. Les incertitudes sur le SI et les objectifs qui lui sont assigns font lobjet dune
gestion des risques qui anticipe les situations nfastes pour le SI et contourne les obstacles
laccomplissement des objectifs de ses usagers. Ainsi, le sujet de la GSI revt un intrt capital pour
les directeurs de systmes dinformation mais aussi pour les dirigeants dentreprise qui ont de plus en
plus le souhait et lexigence dutiliser les SI comme un avantage concurrentiel.
Le sujet de la GSI est aussi vital pour la survie de lentreprise : lexprience de ces dix
dernires annes montre quune mauvaise gouvernance des SI peut entrainer des drives dangereuses
pour lentreprise comme des scandales financiers. La dcouverte des falsifications des informations
financires a conduit la faillite loprateur amricain WorldCom (entre 2000 et 2002, lentreprise
publie des comptes gonfls de plus de 11 milliards de dollar - Les Echos n 19372 du 16 Mars
2005 page 11). Ce scandale a entrain une dvaluation de laction, des licenciements et la faillite la
plus importante de lhistoire des Etats-Unis. Limpact a aussi t exogne puisque les marchs
boursiers amricains, puis mondiaux, ont connu des fluctuations boursires.
Larchitecture de lentreprise est un lment structurant lorganisation sur laquelle la stratgie

de lentreprise est dploye. La structure de lentreprise ainsi que sa stratgie sont des lments
contextuels que la GSI doit intgrer pour orienter les volutions du SI en cohrence avec les besoins
de lorganisation.
Larchitecture dentreprise est un instrument, ou plus prcisment un socle, pour matriser le

fonctionnement dune organisation et son dveloppement futur (Zachman, 2003). Pour COBIT, une
architecture bien dfinie est la base dun bon environnement de contrle interne (Lankhorst, 2009).
ITIL comporte lensemble de bonnes pratiques les plus largement adoptes dans le domaine doffre de
services informatiques (Moirault, 2008). Il est complmentaire COBIT dans la mesure o les
objectifs de contrle de haut niveau de COBIT peuvent tre atteints par limplmentation des bonnes
pratiques dITIL. Une architecture dentreprise clairement dfinie est alors essentielle pour ITIL
puisquelle offre, aux responsables du systme dinformation, une vision claire des applications, de
linfrastructure informatique, des processus mtier, ainsi que des nombreuses interdpendances entre
ces lments (Lankhorst, 2009).
4
Ainsi, en matire de GSI, la proccupation est d'abord professionnelle : la structure des cadres
de GSI comme COBIT, ITIL ou COSO est ad-hoc. Chacun rpondant un objectif particulier de la
GSI. Les DSI se posent frquemment la question de ladaptation de ces cadres au contexte de leur
entreprise, cela donne lieu la mise en place de projets de GSI. Dautre part, les nombreuses solutions
technologiques (systmes GRC Governance Risk and Compliance) naissantes pour le support la
GSI posent le problme du choix de la meilleure solution outille pour une situation de gouvernance
donne.
Plusieurs tudes statistiques confortent notre perception de la GSI et de la manire dont elle
est mise en uvre dans les organisations. Les investissements en matire de TIC pour les entreprises
reprsentaient, en 2003, 35% de leur apport en capital (Laudon, 2008). Depuis, malgr la crise rcente,
les investissements sur les technologies de linformation progressent. En dpit de cette progression,
certaines entreprises profitent mieux des rsultats de lutilisation des TIC que dautres. Pourquoi ? La
GSI qui oriente les investissements sur les projets en serait-elle responsable ?
Plus rcemment, lAFAI et le CIGREF publient en 2006 une enqute2 sur la maturit de la
gouvernance des SI : les entreprises sondes atteignent, en moyenne, le niveau 2 de maturit. Elles
sont dans une phase didentification des objectifs assigns au SI. Lenqute montre quune mauvaise
maturit de la gouvernance du SI entraine un mauvais alignement sur les processus mtier. Ainsi seul
25% des projets SI font rfrence aux processus mtier et les contrats de services ne sont aligns avec
les enjeux mtier que dans 20% des cas. La matrise financire des projets est limite et seulement
10% des entreprises ont une politique de matrise des risques assiste par lutilisation dun rfrentiel
spcialis.
En 2009, le Gartner Group publie les rsultats dune enqute3 sur les priorits stratgiques des
DSI en France : Amliorer la gouvernance IT est un objectif stratgique qui arrive en 5me position.
En 2010, cet objectif nest plus cit, mais une dernire enqute4 montre quune des 10 priorits
technologiques des DSI est dassurer le support aux activits de management des SI.
Les problmes en matire de gouvernance des SI, principalement traits dans les revues de
management, ont donn lieu la cration de cadres de bonnes pratiques tels que COBIT (Moisand,
2009), (Brand, 2008) de lISACA ou ITIL (Moirault, 2008). Les lments de gouvernance font aussi
lobjet de publication de normes telles que la srie ISO 27000 (Carpentier, 2009) qui traite de la
scurit et de la gestion des risques. Ces cadres et normes savrent utiles pour orienter les dcisions
des managers sur les processus cls des SI. Cependant, ils ne rpondent ni aux besoins de (i)
comprhension du concept de GSI lorsque lon envisage un support outill des activits de
2
http://www.afai.asso.fr/public/doc/170.pdf
3
http://www.silicon.fr/gartner-les-investissements-it-a-la-hausse-en-france-33457.html
4
http://www.gartnerinfo.com/ppmit2/PPM10Profile.pdf
5
gouvernance, ni ceux (ii) de capitalisation sur les bonnes pratiques dans la mesure o leur application
sur un projet donn reste entirement ad hoc ce jour. La gouvernance des SI, comme concept, est peu
tudie en recherche. Quelques travaux existent dans le domaine du management des systmes
dinformation (Weill, 2004). Ces derniers prennent comme objet de leur tude - comme beaucoup de
travaux de ce domaine - lvaluation dun systme dinformation dploy et en usage en entreprise -
vu comme une bote noire - sans donner de prconisations concrtes capitalisables et rutilisables par
des ingnieurs de SI pour mieux construire lavenir.
Pourtant le sujet est essentiel pour lingnierie des SI: il permettrait de guider les phases de
spcification des projets GSI, den diminuer les cots et les dlais, dassurer un support efficace du SI
aux activits des DSI et de limiter le risque de mauvais investissements financiers. Rappelons que les
SI permables aux falsifications dinformation ont permis un usage frauduleux qui fut lorigine des
scandales comme Enron ou WorldCom.
Nous mettons ainsi en vidence les limitations des dmarches ad hoc existantes bases sur les
bonnes pratiques. Ces travaux nous permettent nanmoins dobserver que les praticiens de la
gouvernance des SI cherchent des reprsentations concrtes de lentreprise et du systme
dinformation sur lesquelles construire leurs rflexions (leurs dmarches) concernant la gouvernance.
Cependant, bien que lobjet SI tendu (i.e. le SI et lusage que lon en fait dans lentreprise) soit
formalis, reprsent et implment depuis presque 30 ans, les mcanismes qui visent valuer ses
performances en vue de guider ses orientations futures restent encore informels et ad hoc ce jour.
1.3. Problmatique
Nous nous attaquons un double enjeu pour rpondre dune part aux besoins des entreprises
sur ladaptation de la GSI et linsuffisance des cadres de bonnes pratiques, et dautre part, aux lacunes
de la recherche dans la formalisation de lobjet GSI.
Nous proposons dans cette thse dtudier la gouvernance des SI comme un objet / un artfact
/ un concept en soi. Le manque de formalisation dans ce domaine est un problme de fond qui mrite
dtre approfondi et soulve plusieurs questions de recherche :
Le concept de gouvernance n'est pas clarifi.
o Quels concepts structurent le cadre de ce domaine ? Quelle est la nature de ces

concepts ?
On ne peut pas envisager de gouvernance sans mesures. Cependant, ce jour, des mtriques
gnriques, autres que les indicateurs financiers, n'existent pas.
6
o Quels mtriques et indicateurs pour la gouvernance des SI ?
La nature du processus de gouvernance n'est pas comprise. Il y a des facteurs facilitateurs et

inhibiteurs de la gouvernance mais il manque une comprhension de la nature profonde du
processus, de sa formalisation et de son guidage.
o Quels concepts pour la formalisation du processus de GSI ?
La gouvernance des SI est confronte des objectifs changeants. Malgr cela, le maintien
dune bonne gouvernance dans le temps est peu considr.
o La prise de dcision est souvent cite comme lment cl orientant des actions
dvolution. Comment apprhender alors le concept de prise de dcision pour
maintenir une bonne gouvernance dans le temps ? Quels sont les impacts des
dcisions sur les objectifs de la GSI et sur le SI ?
La gouvernance des SI est lune des activits des organisations que lon peut gomtriquement
situer dans la partie haute dans une cartographie de processus mtier (processus de
dveloppement/processus stratgiques). Par consquent un SI doit aussi permettre le support
outill de cette activit de mme que lon a su outiller les processus de support et les processus
lis au cur de mtier de lentreprise depuis plus de 40 ans.
o Quelle est la nature dun SI qui doit supporter les activits lies sa gouvernance ?
Nous proposons de traiter la problmatique suivante :
Quelle conceptualisation de la gouvernance des SI pour la construction dun SI de

gouvernance ?
Cette problmatique adresse les problmes noncs ci-dessus. Elle est le reflet de la ncessit
de : (i) comprendre le concept de GSI ; (ii) le modliser et le formaliser ; (iii) comprendre le processus
de la GSI ; et (iv) rsoudre le double enjeu de la construction et de la maintenance de la GSI travers
le temps.
1.4. Mthode de rsolution

Nos travaux reposent sur les hypothses suivantes :
H1 : la GSI est un artfact que lon peut conceptualiser.

o H11 : Lactivit de GSI manipule un ensemble dlments conceptualisables.
7
o H12 : Le processus de la GSI est lui-mme conceptualisable.
Notre proposition est la consquence de H1. Nous traitons cette problmatique par la
dmarche de mta-modlisation, autrement dit par abstraction des lments de lunivers du discours de
la GSI. Nous utilisons cette dmarche dans le cadre de lingnierie des systmes dinformation. Dans
ce contexte, les concepts sont perus comme des types dobjets qui sont manipuls pour mener bien
lactivit de GSI et qui doivent tre tracs pour matriser durablement lactivit de GSI.
H2 : un systme dinformation de gouvernance correctement conceptualis est utile

la bonne mise en uvre de lactivit de gouvernance
Les concepts et le modle de processus que nous proposerons dans la suite supportent la
production dun systme dinformation pour la gouvernance des SI.
1.5. Apports et rsultats

Dune manire gnrale, notre proposition peut tre apprhende comme une mthode telle
que le dfinit Seligmann (Seligmann, 1989) autour de quatre composants : (i) une manire de penser
ou paradigme, (ii) une manire de modliser, (iii) une manire dorganiser (dmarche) et (iv) une
manire de supporter ou doutiller.
Notre proposition pour la conceptualisation de la GSI sarticule ainsi en quatre points :
une comprhension de la nature du processus de mise en uvre de la GSI : (i) il est

intentionnel, bas sur des valuations quantitatives des carts entre le planifi et
l'observ ; (ii) il est dcisionnel : on dcide des changements oprer et des actions
mener en rponse des vnements externes ou suite une dtection d'carts.
un mta-modle de produit, ou modle de rfrence de la GSI (REFGOUV), recensant
les concepts manipuls dans le cadre des activits de gouvernance des SI. Le mta-
modle est exprim sous la forme dun diagramme de classes UML visant faciliter
ainsi la conception dun SI ddi la GSI. La notion cl est celle de projet qui est
mesur quantitativement par des mtriques et des indicateurs qui alimentent les
tableaux de bord pour les dcideurs.
un mta-modle de processus, ou modle de processus de la GSI (PROGOUV) qui se
veut gnrique. Ce modle positionne une dmarche de gouvernance des SI, guide
par les objectifs, incluant les tapes de planification des projets, le suivi de leurs
ralisations et les prises de dcision sy rfrant.
une double validation de la proposition qui comporte (i) une tude de cas illustrant la
construction dun SI de gouvernance par instanciation des mta-modles PROGOUV et
8
REFGOUV ; (ii) une confrontation des concepts de REFGOUV avec ceux des cadres de
GSI existants.
Nous souhaitons ainsi rpondre aux besoins (et aux dfaillances actuelles) de la recherche en
ingnierie des SI sur la formalisation des concepts de GSI et la ncessit observe sur le terrain
professionnel des SI pour ladaptation des cadres de GSI.
1.6. Plan de la thse

Cette thse est organise en sept chapitres :
Le chapitre II donne un aperu de ltat des recherches par lintermdiaire dun tat de lart
organis autour dun cadre de rfrence analytique.
Le chapitre III offre un aperu de la dmarche de conceptualisation de la GSI.
Le chapitre IV dcrit les concepts de la gouvernance des SI organiss dans un mta-modle
(REFGOUV).
Le chapitre V dcrit un modle gnrique pour les processus de la GSI (PROGOUV).
Le chapitre VI prsente une double valuation des concepts abords : (i) un positionnement
par rapport aux cadres de GSI existants, et (ii) une application simule de PROGOUV et
REFGOUV sur un cas dcole.
Le chapitre VII conclut ce travail et prsente les perspectives envisages.
9
Chapitre 2. Etat de lart
2.1. Introduction
Ce chapitre prsente ltat de lart des recherches sur la pratique de la gouvernance des
Systmes dInformation (SI). Nous avons choisi de prsenter cet tat de lart au moyen dun cadre de
rfrence inspir du cadre des quatre mondes.qui a t initialement introduit pour caractriser les
problmes dingnierie des SI. Ce cadre, complt par des facettes, fournit une structure de
caractrisation des approches de gouvernance qui facilite leur comparaison. Chaque facette
correspond une caractristique essentielle de la gouvernance des SI. Une facette est associe un
ensemble de valeurs qui permettent une comparaison plus fine des approches les unes avec les autres.
Un survol rapide de la littrature montre quil y a deux types dapproches : les approches
vulgarises, trs utilises dans le monde des organisations et les approches de la recherche dont on
peut trouver la description dans les journaux et les confrences ddis aux nouvelles technologies de
linformation. Nous considrons galement les approches descriptives du sujet de la gouvernance des
SI, issues de la recherche en management des SI ainsi que des approches en ingnierie des systmes
dinformation.
La structure du cadre de rfrence et ses facettes ont t obtenues par analyse de toutes ces
sources dinformation. Celles-ci permettent de comparer les forces et faiblesses de chacune des
approches de la GSI par rapport chacune des caractristiques identifies par une facette.
Ce chapitre est organis comme suit : dans une premire partie nous dcrivons le cadre de
rfrence propos pour le domaine de la gouvernance des SI. Puis cinq approches reconnues sont
values selon ce cadre. Nous concluons ce chapitre en mettant en vidence les lacunes des approches
actuelles, notre positionnement au regard de la littrature et son apport la gouvernance des SI
2.2. Cadre de rfrence pour les approches de la gouvernance des SI

Dans cette section, nous proposons un cadre de rfrence des approches de la GSI. Ce cadre
est construit autour de facettes capturant une dimension spcifique de la GSI. Le principe des facettes
a t introduit dans (Prieto-Diaz, 1991) pour lingnierie logicielle. Ce cadre na pas vocation dcrire
les activits de la gouvernance mais permet dorganiser les approches de la gouvernance sur des axes
danalyse structurants qui nous paraissent pertinents.
11
2.2.1. Mta-modle utilis
Le cadre est structur autour de quatre ples ou mondes . Le cadre de rfrence dit des
quatre mondes a t utilis dans diverses disciplines dingnierie : lingnierie des SI (Jarke, 1992),
lingnierie des exigences (Jarke, 1993), lingnierie des processus (Rolland, 1998) ainsi que
lingnierie du changement (Nurcan, 2003). Plus rcemment ce cadre a t utilis pour lingnierie des
SI dalignement et de gouvernance (Nurcan, 2008) et pour lingnierie des mthodes situationnelles
base de composants (Nehan, 2007).
Il est complt par des facettes selon lapproche introduite dans (Prieto-Diaz, 1991). Celle-ci
vise permettre une classification plus flexible et prcise des composants logiciels et sappuie sur
lnumration des descripteurs des composants, leur association un lexique de termes (thsaurus) et
un graphe des facettes. Le cadre initial des quatre mondes a t adapt par des facettes qui sont des
lments descripteurs.
Chaque facette peut prendre une valeur prdfinie par un domaine de valeurs :
un domaine de valeur simple se rfre un type de valeur primitive prdfinie. Cest

le cas dune valeur entire ou relle ;
un domaine de valeur densemble (SET{a ;b ;}) se rfre un type structur. Par
exemple, un vecteur avec n dimensions est un type structur sur n lments;
un domaine de valeur numr (Enum{a, b,}) se rfre un type numr. Ainsi,
une mention pour un diplme est dun domaine numr et peut prendre sa valeur
parmi les valeurs dfinies sur Enum{ Assez Bien , Bien , Trs Bien }
Le mta-modle de la Figure 2.1 dfinit le cadre propos.
Cadre de rfrence 4 Monde
+nom: String 1 +nom: String

Simple Ensemble Enumr
1..*
Facette
Domaine de valeur
+nom: String
Figure 3.1. Mta-modle du cadre des quatre mondes.
2.2.2. Description du cadre de rfrence

Le cadre de rfrence est obtenu par instanciation du mta-modle (Figure 2.1). La littrature
en matire de gouvernance nous permet de dfinir les valeurs prises par les attributs des classes du
mta-modle. Le cadre de rfrence est prsent la Figure 2.2 et comporte les quatre mondes
suivants :
12
le monde du sujet . Il prsente la gouvernance des SI comme lobjet danalyse et
identifie ses caractristiques intrinsques. La gouvernance y est dcrite comme une
structure organisationnelle pour la prise de dcision concerne par les volutions
simultanes des projets SI, des processus mtier et des processus du SI.
le monde de lusage est le propos de la GSI, il concerne les objectifs de ses
utilisateurs. En matire de gouvernance, les DSI prennent des dcisions avec pour
objectif de limiter les risques, de crer de la valeur et datteindre un certain degr de
performance.
le monde du systme contient lensemble des informations utiles aux activits de
la GSI. Cest le socle informationnel pour la prise de dcision. Il contient les lments
pour la mesure des objectifs de la GSI ainsi que lensemble des documents et modles
utiles au partage de la connaissance lie la GSI.
le monde du dveloppement est constitu des processus de la GSI. Leur excution
permet datteindre les objectifs de la GSI et repose sur la manipulation des lments
informationnels du systme de GSI.
Les mondes sont en relation lun avec lautre (Claudepierre, 2007a), (Claudepierre, 2007b) :
(i) le monde du sujet dfinit un cadre pour lidentification des buts du monde de lusage et en
justifie lexistence. (ii) Le monde du systme est le support de la reprsentation de la ralit du
monde du sujet . (iii) Le monde du systme est construit pour faciliter lexcution des processus
dcrits dans le monde du dveloppement . Enfin, (iv) le monde du systme est un support pour
laccomplissement des objectifs prsents dans le monde de lusage .
Le manager de la gouvernance des SI est ainsi positionn au centre des quatre mondes : il
matrise lenvironnement de la gouvernance et ses mcanismes (monde du sujet), se fixe un ensemble
dobjectifs accomplir (monde de lusage), excute des processus pour y parvenir (monde du
dveloppement) et utilise des documents, modles et mtriques (monde du systme).
13
Monde de lusage
Quels sont les Minimiser les risques Comment rpondre aux
exigences de la GSI ? exigences de GSI ?
Atteindre ltat dalignement
Obtenir la performance
Crer de la valeur
Monde du sujet
A pour objectif
Organisation de la gouvernance
Monde du dveloppement
Dcision Nature des processus
Processus SI Excute
Maturit des processus
Matrise
Processus mtier Capitalisation de la connaissance
Changement Logiciel
Portefeuille de projets SI Utilise
Monde du systme
Contenu
Modle
Comment reprsenter la Quels lments pour
ralit de la GSI ? lexcution des
Mtriques
activits de GSI ?
Figure 3.2. Cadre de rfrence pour la gouvernance des SI
Dans les sections suivantes, les FACETTES sont prsentes en petites majuscules et leur valeur
en italique.
2.2.2.1. Le monde du sujet de la GSI

Le monde du sujet permet de rpondre la question Quest-ce que la gouvernance des
SI ? . Cest une description par facettes de la nature intrinsque de la gouvernance. Ce monde
comporte six facettes : ORGANISATION DE LA GOUVERNANCE, DECISION, PROCESSUS SI, PROCESSUS
METIER, CHANGEMENT et PORTEFEUILLE DE PROJETS SI. Lensemble de ces facettes permet de situer
la gouvernance des SI comme un ensemble dactivits organises pour la prise de dcision ddie aux
choix oprer pour les volutions des projets SI, de leurs impacts sur les processus mtier et les
processus SI. Le tableau 2.1 liste lensemble des facettes et leurs valeurs pour le monde du sujet. Nous
les dcrivons en squence dans la suite.
2.2.2.1.1. Organisation de la gouvernance

(Weill, 2004) propose danalyser le comportement de direction des systmes dinformation en
le comparant aux archtypes de gouvernance tatique. Il dcrit ainsi lorganisation autour de la prise
de dcision. La responsabilit dcisionnelle centralise est alors compare une monarchie et la prise
de dcision collaborative est compare une dmocratie participative entre deux groupes (mtier et
SI). Cette structure de prise de dcision est organise autour dune typologie de dcisions et ltude
montre que les dcisions dinvestissement dans les nouvelles technologies sont du ressort des
directions mtiers, alors que les dcisions plus techniques portant sur larchitecture et linfrastructure
du systme sont du ressort de la DSI. (De Haes, 2005) rejoint cette ide quune organisation des
14
systmes dinformation est structure pour la prise de dcision autour dun comit o les rles et
responsabilits sont distribus.
La facette ORGANISATION DE LA GOUVERNANCE capture cet aspect. Une ORGANISATION DE

LA GOUVERNANCE centralise est le reflet dune structure o la responsabilit des dcisions est
attribue une seule personne. Par exemple, le DSI peut tre seul responsable des dcisions
informatiques sans consultation des responsables mtiers. Une structure dcentralise pour la
gouvernance est reprsentative dune organisation o la dcision est issue dun change et constitue un
consensus entre plusieurs parties-prenantes. Une structure hybride permet dadopter un mode de
responsabilit centralis pour certain types de dcision et dcentralis pour dautres.
ORGANISATION DE LA GOUVERNANCE : Enum{centralise, dcentralise, hybride}
2.2.2.1.2. Dcision
Peter Weill et Jeanne Ross proposent une modlisation structurant le mode de dcision en
matire de gouvernance des systmes d'information (Weill, 2005). Cette tude prsente ainsi cinq
types ou domaines de dcision de gouvernance :
Principes des technologies de l'information. Ce sont les dcisions relatives au rle

stratgique jou par les technologies de l'information
L'architecture. Ce domaine se rfre aux choix technologiques afin de satisfaire les
besoins organisationnels de l'entreprise. La dcision est ici oriente par les processus
mtiers pour un SI correctement urbanis.
L'infrastructure. Ce sont les dcisions concernant l'infrastructure technologique
support. Elle se rfre aux matriels et la capacit de lentreprise les mettre en
uvre, ou identifier des solutions dexternalisation en fonction de la criticit des
objectifs stratgiques.
Les applications mtiers. Ce domaine concerne les besoins applicatifs,
dveloppements internes, sous-traitance, pour les fonctionnalits mtier.
Il ressort que les grandes dcisions mettre en rapport avec la gouvernance des SI se
concentrent sur la mise disposition des services du SI et sur le mode de dploiement des applications.
Larchitecture applicative est un aspect dcisionnel important. Cette architecture ne saurait exister sans
une infrastructure technique de support. Enfin les dveloppements du SI sont assurs par un ensemble
de projets quil convient de planifier.
Nous dcrivons doncla facette DECISION comme reprsentative de la typologie des dcisions
possibles portant sur larchitecture SI, linfrastructure SI ou la planification des projets.
DECISION : Enum{architecture SI, infrastructure SI, planification des projets}
15
2.2.2.1.3. Processus SI
La gouvernance des SI repose sur un ensemble de processus qui permettent de contrler que
les objectifs assigns au SI sont bien considrs et de ragir le cas chant. (Van Grembergen, 2004)
propose ainsi de considrer les processus SI essentiels pour la GSI autour dun processus de contrle
(reporting) et dun processus daction pour la prise de dcision. Il rejoint lide dveloppe plus tt
dans (Luftman, 1999) qui prconise six tapes pour lalignement mtier/SI. Elles concernent
principalement : lidentification des objectifs, la comprhension des liens dalignement, lanalyse (in-
fine, la mesure et le contrle) et la priorisation des carts, la spcification et le choix des actions
mener. Les PROCESSUS SI que nous considrons sont ainsi lis lobtention de la qualit du SI par un
mcanisme de contrle dont les fondements reposent sur la dmarche gnrique de Deming du PDCA
(Plan, Do, Check, Act).
Ainsi les PROCESSUS SI essentiels dans le cadre dune bonne gouvernance sont ceux ddis
laudit, au contrle et au reporting. Manita, dans (Manita, 2007), discute la qualit des processus
daudit comptable. Il ressort de cette tude, la ncessit pour les auditeurs, de matriser la connaissance
du propos de laudit, sans cesse dans une situation changeante, de mesurer la qualit du processus
daudit suivant des indicateurs, et de ladapter au besoin.
La facette PROCESSUS SI permet de reprsenter cet aspect. Les valeurs associes cette facette
mesurent le degr de matrise de ces processus en se basant sur le principe quun PROCESSUS IT est au
minimum document. Lidentification des mtriques, des indicateurs et des rgles de contrle permet
la prise de dcision sur le processus daudit : le processus est alors pilot. Un processus volutif est un
processus sous contrle dont on a envisag les volutions et qui est reprsentatif dune gouvernance
mature.
PROCESSUS SI : Enum{document, pilot, volutif}
2.2.2.1.4. Processus mtier

(Davenport, 1993) dfinit un processus mtier comme un cadre structur et mesur
d'activits destines produire une sortie spcifique pour un client ou un march. Cela implique de
mettre laccent sur la faon dont le travail est effectu au sein d'une organisation, au lieu de se
concentrer sur le produit. Un processus est donc un ordre prcis des activits travers le temps et
l'espace, avec un dbut et une fin, des entres et des sorties clairement dfinies : une structure
d'action.
Il existe plusieurs typologies des processus mtier : nous retenons deux approches pour
caractriser cette notion (Rummler, 1995) et (Alonso, 1997). La premire structure dfinit les
processus par rapport leur apport direct/indirect la cration de valeur. Lapproche (Rummler, 1995)
distingue les processus primaires, qui sont en contact direct avec le client et gnrent directement de la
16
valeur, des processus supports. Les processus supports sont invisibles du point de vue client et sont
fonctionnels : ils concernent la comptabilit, les recrutements ou encore les supports techniques. Les
processus primaires concernent les activits et oprations ddies aux approvisionnements, la
production et la vente. La seconde approche (Alonso, 1997) raisonne sur la nature du processus
mtier. Elle distingue quatre types de processus :
Productif : le processus est rptable et implmente les processus primaires de

lentreprise.
Administratif : le processus est bureaucratique et est rgi par des rgles clairement
tablies.
Collaboratif : le processus se caractrise par dimportantes interactions entre les
acteurs. Cest le cas par exemple des processus de pilotage en comit de direction.
Ad-hoc : le processus se dfinit la vole lors de son excution. Cest un processus
qui nest pas prvu, il est souvent li des exceptions.
La facette PROCESSUS METIER permet de capturer ces aspects. Nous reprenons la typologie
issue de (Alonso, 1997) pour caractriser les valeurs de la facette processus mtier.
PROCESSUS METIER : Enum{productif, administratif, ad-hoc, collaboratif}
2.2.2.1.5. Changement
La conduite du CHANGEMENT dsigne la gestion des processus de transformation de
lorganisation et de ses processus mtiers ou informatiques. (Ploesser, 2008) propose une typologie
des processus de changement :
Changement par substitution : Le remplacement temporaire d'un processus mtier

par un autre, structurellement des processus d'affaires diffrents, gnralement en
rponse un vnement imprvu comme une situation d'urgence
Changement par adaptation : L'adaptation temporaire de la structure d'un processus
mtier en rponse un vnement prvu et temporaire, sans effacer lidentit
structurelle du processus
Changement par volution : Les changements effectus dans le processus mtier
sont permanents. Ils modifient considrablement la composition structurelle du
processus ou de son type
Nous reprenons la classification de (Ploesser, 2008) sur la typologie des changements des
processus mtier et ladaptons pour proposer les valeurs de la facette changement. Les changements
peuvent tre : (i) ad hoc, cest le cas des changements non souhaits ; (ii) volutif, lorsque une
amlioration est envisage ; (iii) correctif, lorsque les processus sont adapts lexcution.
17
Dans le cadre de la GSI les changements interviennent tant sur les processus mtier que sur les
processus SI ou les projets de dveloppement et de maintenance du SI.
La facette CHANGEMENT capture cet aspect et prend ses valeurs sur un domaine numr qui
comporte les valeurs ad-hoc, volutif et correctif.
CHANGEMENT : Enum{ad-hoc, volutif, correctif}
2.2.2.1.6. Portefeuille de projets SI

Le systme dinformation est lobjet de la gouvernance du SI. Ce dernier est transform de
manire continue pour satisfaire les besoins de support et de services informatiques pour les acteurs de
lentreprise. La gestion de portefeuille de projet SI est dfinie par le Cigref (Cigref, 2006) comme une
pratique identifie de la gouvernance des SI. Elle a pour objectif dtablir un ordre de priorit aux
projets de transformation du SI suivant un ensemble de critres. Pour (Reix, 2004), il sagit de classer
les projets selon leur ordre durgence de ralisation par rapport ces critres. Nous identifions ici deux
modes de classification des projets : monocritre ou multi-critre.
Un projet SI est cr pour urbaniser (en anglais Enterprise Architecture) tout ou partie du
systme dinformation, c'est--dire le transformer en cohrence avec des besoins situationnels.
Lapproche par urbanisation est prsente par Christophe Longp comme une approche mettre en
opposition avec une approche plus radicale qui consiste remplacer le SI existant en une seule fois. En
revanche elle cible les lments transformer sur les architectures mtier, fonctionnelles, applicatives
et technologiques. Nous identifions ainsi dans la littrature trois modes de transformation du SI qui se
font par cration, par maintenance ou par volution
La facette PORTEFEUILLE DE PROJET SI (PPSI) est complexe. Elle permet de caractriser le

mode de classification des projets SI et le mode de transformation du SI
PPSI : SET{ mode de classification : Enum{monocritre, multi-critre} ; mode de

transformation : Enum{cration, maintenance, volution}}
18
En conclusion, lanalyse et la synthse des visions de la GSI aboutit la proposition suivante :
Facette Valeur
ORGANISATION DE LA Enum{centralis, dcentralise, hybride}
GOUVERNANCE
DECISION Enum{architecture SI, infrastructure SI, planification projet}
PROCESSUS IT Enum{document, pilot, volutif}
PROCESSUS METIER Enum{productif, administratif, ad-hoc, collaboratif}
CHANGEMENT Enum{ad-hoc, volutif, correctif}
PPSI SET{mode de classification : Enum{monocritre, multi-critre} ;
mode de transformation : Enum{cration, maintenance, volution}}
Tableau 2.1. Liste des facettes du monde du sujet.
2.2.2.2. Le monde de lusage de la GSI

Le monde de lusage permet de rpondre la question Quels sont les objectifs de la
gouvernance des SI, quel est son propos ? . Cest une caractrisation par facette des objectifs de la
gouvernance. Ce monde en comporte quatre : MINIMISER LES RISQUES, ATTEINDRE LETAT
DALIGNEMENT, OBTENIR LA PERFORMANCE et CREER DE LA VALEUR. Lensemble des facettes
associes ce monde permet de mettre en valeur les objectifs de la GSI. La suite de cette section
propose une dfinition de chaque facettes qui sont rsumes dans le tableau 2.3.
2.2.2.2.1. Minimiser les risques

La gestion des risques est fortement relie la gestion des portefeuilles de projets SI. Ainsi
pour chaque projet il est essentiel de mesurer limpact des risques sur le cot, la qualit et les dlais.
Pour la Direction des Systmes dInformation du Centre National de la Recherche Scientifique5, dans
le cadre dun projet SI, il sagit de limiter les risques lis aux ressources, lorganisation et la
planification, aux fonctions dvelopper et aux techniques mettre en uvre. Il sagit ainsi de limiter
les mauvaises rponses aux objectifs de cot, de qualit (capacit dun projet rpondre aux besoins)
et de dlais (Schwalbe, 2007).
La scurit des SI est un enjeu majeur dans le cadre de la GSI. Cest un domaine stratgique
pour les SI (Georgel, 2009) qui impose dassurer la scurit des actifs informationnels. Elle ncessite
pour le SI de se conformer un certain nombre de qualits essentielles comme assurer lintgrit, la
confidentialit et la disponibilit de linformation. Ainsi la scurit des SI vise se protger des
malfaons, des attaques et des intrusions non autorises qui peuvent altrer linformation dune
organisation. La scurit est ainsi lie lexpression de besoins qualitatifs pour linformation.
Pour les dcideurs et les acteurs de lorganisation, obtenir une information de qualit, au
moindre cot, et au bon moment afin dassurer la continuit de leurs activits est essentiel, voir vital.
La gestion et lanalyse des risques informationnels permet de prenniser les activits mtiers : le
5
http://www.dsi.cnrs.fr/conduite-projet/phasedefinition/qualite/risques/basdefqual.htm
19
professeur Serge Agostineli (Agostineli, 2009) identifie les attentes en terme de bonne information
dans les fonctions informationnelles et de rgulation quil accorde aux processus mtier.
Ainsi, quil sagisse de piloter des projets, des processus mtier ou dassurer la satisfaction des
utilisateurs du SI en matire de scurit, linformation doit toujours tre fournie au moindre cot, dans
les dlais impartis et avec les qualits attendues.
La facette MINIMISER LES RISQUES permet de capturer les types de risques lis aux besoins
informationnels. Elle prend sa valeur dans un domaine numr comprenant le surcot, la non-qualit
et le retard.
MINIMISER LES RISQUES : Enum{surcot, non-qualit, retard}
2.2.2.2.2. Atteindre ltat dalignement

Lobjectif premier dun SI est de satisfaire le besoin de support aux acteurs dune
organisation. Le SI peut aussi tre utilis comme avantage concurrentiel. Cest le point de vue soutenu
par Henderson et Venkatraman dans la proposition du modle SAM (Henderson & Venkatraman,
1993). L'alignement stratgique du modle (SAM) mis au point par Henderson et Venkatraman fait
une distinction entre la perspective externe de l'information (stratgie TI) et son objectif interne
(infrastructure TI et infrastructure des processus), reconnaissant ainsi le potentiel de l'informatique la
fois au soutien des activits de lorganisation et celui de sa stratgie. Le modle est bas sur deux
types d'alignement: lajustement stratgique et lajustement fonctionnel. Lalignement consiste ainsi
faire voluer en cohrence les stratgies mtier et SI dune part, et les services mtier et informatiques
dautre part.
Dans les deux cas prcdents on peut identifier trois modes dadaptation pour obtenir ltat
dalignement : (i) dans le cas o le SI est rigide et ne sadapte pas, lalignement ne peut tre opr que
par lvolution des activits mtiers, de ses services et de sa stratgie (volution mtier) ; (ii) lorsque le
SI est vu comme support, cest ce dernier dadapter ses services et sa stratgie aux volutions des
activits mtiers (volution SI) ; (iii) enfin lalignement est optimal lorsque les volutions sont
simultanment appliques aux services et la stratgie du SI et respectivement des mtiers (co-
volution). Le sujet de la co-volution reste un problme dactualit dans le domaine de lingnierie de
lalignement (Etien, 2006) et (Thvenet, 2009).
La facette ATTEINDRE LETAT DALIGNEMENT prend ainsi ses valeurs sur un domaine numr
comprenant les valeurs volution SI, volution mtier et co-volution.
ATTEINDRE LETAT DALIGNEMENT : Enum{volution SI, volution mtier, co-volution}
20
2.2.2.2.3. Obtenir la performance
La performance est au centre des proccupations des DSI. Cest le rsultat de la matrise de la
maturit des processus mtier et SI (Ravichandran, 2005). Aussi lapplication de mthodes orientes
par la maturit des processus comme COBIT ou CMMi est pertinente. Ces cadres proposent un
ensemble prdfini dobjectifs atteindre et de mtriques pour mesurer la maturit des processus.
Il est clair que la GDI doit disposer de mtriques et indicateurs de suivi. La dfinition des
mtriques est souvent une affaire de bon sens , c'est--dire dpendante du bon sens de celui qui les
pense. Alfred Binet (1857-1911), psychologue et pdagogue Franais qui inventa la psychomtrie ira
jusqu affirmer quune chelle mtrique est un instrument que lon ne doit pas mettre entre les mains
d'un imbcile6. Les mtriques peuvent aussi tre dfinies de manire ad hoc suivant le contexte de
lorganisation et ses objectifs.
La mthode GQM The Goal-Question-Metric Approach (Basili, 1994) prsente une

structure hirarchise qui guide la production de mtriques. Elle permet de lier une mtrique un
objectif par lintermdiaire dune question. Nous pouvons prendre lexemple de la minimisation du
cot de lalignement (voir Tableau 2.2).
Etape GQM Exemple

Objectif Minimiser le cot de lalignement
Question Quel est le cot du mcanisme dalignement ?
Mtrique Cot de lalignement par adaptation du SI
Cot de lalignement par adaptation des processus mtiers
Cot de lalignement par covolution
Tableau 2.2. Exemple dapplication de la mthode GQM.
Nous identifions ainsi deux stratgies permettant datteindre la performance de la

gouvernance : une stratgie ad-hoc et une stratgie guide par la maturit des processus. Nous
capturons cet aspect par lintermdiaire de la facette OBTENIR LA PERFORMANCE qui peut prendre les
valeurs ad-hoc ou maturit des processus.
OBTENIR LA PERFORMANCE : Enum {ad-hoc, maturit des processus}
2.2.2.2.4. Crer de la valeur

Dans la littrature, deux grands types de valeur sont abords lorsque lon traite des SI. Nous
distinguons la valeur financire des ressources humaines, matrielles et nergtiques utilises (valeur
patrimoniale) de la valeur dusage. La gouvernance traite de lalignement ; il est donc aussi pertinent
danalyser la cration de valeur tant au niveau du SI (patrimoine SI) quau niveau de lorganisation
(patrimoine mtier). La valeur dusage (usage du SI) est lie lutilisation efficace du systme par ses
6
http://agora.qc.ca/dossiers/Alfred_Binet
21
usagers. Une tude rcente du Cigref (Cigref, 2008) montre limportance de gouverner les SI dans
lobjectif de cration de valeur dusage.
Les valeurs patrimoniales et dusage sont issus des travaux de Jrme Denis (Denis, 2009).
Dans le cadre de la scurit des SI, il se rfre la protection des lments de valeur. Un axe danalyse
de la valeur est associ la qualification des donnes (au contenu du SI) vues comme un bien matriel
et immatriel : ce sont les ressources, les informations, les modles et les donnes de valeur pour
lorganisation. Le patrimoine SI caractrise ces dimensions de la valeur.
(Denis, 2009) fait galement rfrence lassociation des hommes et des machines o la
valeur est issue de la capacit dusage des matriels et logiciels par les acteurs de lorganisation.
Lusage du SI caractrise cette dimension de la valeur.
La notion de valeur mtier est reconnue depuis plus de 20 ans et traite dans le domaine de
lconomie. Elle a t introduite par Porter (Porter, 1986) qui propose de dcrire la cration de valeur
pour une organisation autour des activits de base (approvisionnement, fabrication, commercialisation,
vente et service). La cration de valeur y est facilite par des activits de soutien (infrastructure de
lentreprise, GRH, R&D, achat). La chane de valeur de Porter est rpute pour dterminer la capacit
dune organisation obtenir un avantage concurrentiel. Le patrimoine mtier caractrise la dimension
de valeur accorde par Porter.
La facette CREER DE LA VALEUR capture les lments de valeur concerns : patrimoine SI,
patrimoine mtier et usage du SI.
CREER DE LA VALEUR : Enum{patrimoine SI, patrimoine mtier, usage du SI}
En conclusion, lanalyse et la synthse des objectifs accords la GSI aboutissent la

proposition suivante :
Facette Valeur
MINIMISER LES RISQUES Enum{surcot, non-qualit, retard}
ATTEINDRE LETAT DALIGNEMENT Enum{volution SI, volution mtier, co-volution}
OBTENIR LA PERFORMANCE Enum{ad-hoc, maturit des processus}
CREER DE LA VALEUR Enum{patrimoine SI, patrimoine mtier, usage du SI}
Tableau 2.3. Liste des facettes du monde de lusage.
2.2.2.3. Le monde du systme de la GSI

Le monde du systme de la GSI permet de rpondre la question Quels sont les lments
informationnels utiles pour les activits de la GSI ? . Cest une caractrisation par facette des
supports informationnels pour la gouvernance du SI. Ce monde comporte trois facettes : CONTENU,
MODELE et METRIQUE. Lensemble des facettes slectionnes permet de mettre en valeur les lments
utiles pour les activits dcisionnelles de la GSI au regard des objectifs de cration de valeur, de
22
matrise des risques, dalignement et dobtention de la performance. Le tableau 2.4 liste lensemble
des facettes et leurs valeurs pour le monde du systme.
2.2.2.3.1. Contenu
Les activits de gouvernance des SI reposent sur des supports informationnels, le plus souvent
des documents. Un document synthtise des informations utiles pour la prise de dcision. On peut
trouver des rfrences aux types de documents dans (Georgel, 2009) Nous en fournissons une liste non
exhaustive ci-aprs :
Documents pour lalignement : plan stratgique, cartographie des processus SI/mtier

Documents pour le management : organigramme hirarchique, RACI des membres
des comits de direction, rapports dactivit, description des programmes
Documents pour la gestion des ressources : POS, rapport dincident, modle
darchitecture et dinfrastructure.
Documents pour la gestion des risques : cartographie des risques, plan durgence,
procdure de restauration.
Documents pour la gestion de la performance : tableaux de bord
Documents pour la gestion de la valeur : budget, plan dinvestissement, factures
Documents pour la gestion de la maturit : bonnes pratiques

La facette CONTENU fait ressortir la ncessit pour un systme de gouvernance des SI de grer
un ensemble de documents. Elle est caractrise par lunique valeur nom de document.
CONTENU : Enum{nom de document}
2.2.2.3.2. Modle
Les modles permettent la reprsentation dun domaine et sont le support lanalyse et au
raisonnement. Ils respectent un certain paradigme, c'est--dire une manire de voir, de reprsenter un
sujet particulier.
Les activits de la GSI ncessitent la reprsentation de quatre sujets :
Les processus. Les modles de processus permettent la description des processus

mtiers et SI. En informatique, il existe plusieurs langages pour la modlisation des
processus : le standard UML (Unified Modelling Language) (Booch, 2000) permet de
reprsenter les processus avec le diagramme dactivit. BPMN (Business Process
Modeling Notation) (Briol, 2008) est un standard maintenu par lOMG (Object
23
Management Group). Il permet de reprsenter lenchainement des activits, leur
distribution des acteurs, les vnements inhrents un processus.
Les objets : Les modles objet permettent la reprsentation des classes dobjets. UML
(Booch, 2000) se fonde sur les principes de lobjet et propose les diagrammes de
classes et dobjets avec des notations spcifiques. Ce paradigme est exploit dans
beaucoup dapplications informatiques et notamment les bases de donnes objet, les
systmes dexploitation ainsi que les langages de programmation objet comme C++,
C# ou Java.
Les dcisions : les modles de dcision doivent permettre un dcideur d'agir comme
le prescrivent certaines thories du choix. Dans le cas idal d'un problme totalement
spcifiable, cela consiste en la visualisation dun arbre de dcision qui permet d'oprer
un choix optimal selon les critres voulus (par exemple la minimisation de risque).
Dans ce cas, le modle de rseau bayesien (Lepage, 1992) est applicable. Il envisage
le guidage des dcisions suivant une analyse des probabilits transactionnelles entre
des causes et leurs consquences.
Les volutions : La notion dvolution est aborde dans la littrature. Elle est traite
dans les dmarches durbanisation du SI (Longp, 2004) (Le Roux, 2006) (Le Roux,
2009). Cette discipline s'appuie sur une srie de concepts correspondant ceux de
l'urbanisation de l'habitat humain (organisation des villes, du territoire), concepts qui
ont t rutiliss en informatique pour formaliser ou modliser la ringnierie du
systme d'information. Le modle de la CARTE (MAP) (Rolland, 1998) a aussi t
propos pour la ringnierie du SI et des processus. Il repose sur les concepts de
lintention qui reprsente la projection du besoin dvolution que lon souhaite avoir
pour le SI futur, et de la stratgie qui est la manire datteindre ces intentions. EKD-
CMM (Enterprise Knowledge Development a Change Management Method)
(Nurcan, 1999) est une mthodologie de gestion de changement pour les processus
mtier qui est formalise par des modles de CARTE.
La facette MODELE caractrise les types des modles considrs par une approche de
gouvernance. Elle repose sur un domaine de valeur numr qui contient les valeurs : processus, objet,
dcision et volution. Cette facette est le reflet de la capacit du systme de gouvernance reprsenter
les processus mtier et SI, les dcisions, les projets et leurs volutions.
MODELE : Enum{processus, objet, dcision, volution}
2.2.2.3.3. Mtrique
Les activits de gouvernance des SI reposent sur des mtriques qui permettent aux dcideurs
dapprcier la situation courante au regard des objectifs atteindre. Les mtriques sont ainsi les
24
dimensions de mesure du Quoi ? (le SI, ses projets, ses processus et ses ressources) et du
Pourquoi ? (les objectifs de performance, de valeur, de risque et dalignement).
Nous reprenons ici la proposition de la mthode GQM (Basili, 1994) qui stipule que les
mtriques sont identifies par drivation des objectifs. De plus, la capacit driver des mtriques
dun objectif est directement dpendant de lexpression du but associ. La formulation de lobjectif
doit respecter des contraintes : tre Spcifique, Mesurable, Atteignable, Raliste et Temporel
(SMART). (BovendEerdt, 2009) est une proposition dune mthode de formulation des objectifs
SMART dans le milieu mdical pour la rhabilitation orthopdique des patients.
Nous proposons de capturer les types de mtriques spcifiques la gouvernance des SI. Ils
sont mis en relation avec les objectifs de la GSI tels quils ont t identifis dans le monde de lusage.
Nous distinguons ainsi les mtriques de risque, de performance, de valeur et dalignement.
La facette METRIQUE capture cet aspect et repose sur un domaine de valeurs numres
comprenant les valeurs : risque, performance, valeur et alignement.
METRIQUE : Enum{risque, performance, valeur, alignement}
En conclusion, lanalyse et la synthse des lments du systme de la GSI aboutissent la

proposition suivante :
Facette Valeur
CONTENU Enum{nom de document}
MODELE Enum{processus, objet, dcision, volution}
METRIQUES Enum{risque, performance, valeur, alignement}
Tableau 2.4. Liste des facettes du monde du systme.
2.2.2.4. Le monde du dveloppement de la GSI

Le monde du dveloppement de la GSI est un monde qui est en relation avec les trois autres
mondes du cadre. Il capture les caractristiques du dploiement de la gouvernance des SI. Il se rfre
la description des processus propres la GSI, la manire de distribuer les rles dcisionnels,
lorganisation du comit de direction des SI, la manire de piloter les volutions et les innovations
sur le portefeuille de projets SI, aux processus de dveloppement du SI et aux processus mtier. Le
monde du dveloppement sadapte la nature de la GSI dcrite par le monde du sujet et ses objectifs
dcrits dans le monde de lusage. Les processus de la GSI doivent permettre la performance dans
laccomplissement des objectifs de valeur, de risque, de performance et dalignement. Ces processus
sont de nature collaborative pour la prise de dcision. Il est ainsi essentiel denvisager comment les
acteurs de la GSI partagent leurs connaissances et manipulent linformation au travers des outils
ddis au reporting et la modlisation. Ces processus propres la GSI utilisent les lments du
monde du systme, tels que les aspects de contenu, les modles et les mtriques dcrits dans ce monde.
25
Le monde du dveloppement se compose de quatre facettes : NATURE DES PROCESSUS, MATURITE DES
PROCESSUS, CAPITALISATION DE LA CONNAISSANCE et LOGICIEL. Lensemble des facettes et leurs
valeurs sont prsentes dans le tableau 2.5.
2.2.2.4.1. Nature des processus

Un processus est un ensemble dactivits qui, partir dune ou plusieurs entres, produit un ou
plusieurs rsultats reprsentant une valeur pour un client interne ou externe (Hammer, 1993). En se
rfrant la dfinition de Hammer sur les processus, le processus de dveloppement dun SI est un
ensemble dactivits coordonnes et excutes par un ingnieur systme dans le but de produire le SI
de gouvernance. Le rsultat est un systme de support et daide la dcision (SID) dont il convient de
mesurer lusage et lutilit.
Nous distinguons deux approches de construction des systmes dcisionnels : (i) une approche
collaborative dans laquelle lingnieur dfinit progressivement les tapes du processus la vole .
Le processus est de type ad hoc. (ii) Le dveloppement du systme peut suivre un ensemble dactivits
connues lavance. Pour chaque projet de cration ou de maintenance du systme, lingnieur suivra
des tapes prdfinies. Le processus est alors de type systmatique. Nous capturons ces aspects avec la
facette NATURE DES PROCESSUS qui peut prendre les valeurs ad hoc ou systmatique.
2.2.2.4.2. Maturit des processus

Nous prenons en considration le niveau de MATURITE DU PROCESSUS de dveloppement car
cela impacte fortement la performance des activits de la GSI. Ainsi des processus de GSI de maturit
leve gnreront une documentation et une remonte dinformation plus performante pour la prise de
dcision et lorientation des objectifs de GSI et des projets du SI.
Plusieurs modles de maturit existent. Le plus prouv et utilis par les professionnels des SI
est le CMMI (Capability Maturity Model Integrated) maintenu par le Software Engineering Institute
(SEI, 2006). Le CMMI nvalue pas la maturit des processus de la GSI mais celle des processus de
dveloppement du SI. Il existe cependant un rapport avec la GSI car un niveau lev de maturit
(niveaux 3,4 et 5 du CMMI), les processus et les projets du SI doivent tre pilots, associs des
objectifs de performance, et doivent pouvoir voluer. Ces derniers aspects sont du ressort de la GSI
qui doit organiser les processus de pilotage et dvolution des lments du SI.
Ces dernires annes les chercheurs se sont intresss la cration de modles de maturit
ddis la GSI. Marten Simonsson (Simonsson, 2008) propose ITOMAT (IT Organization Modeling
and Assessment Tool) pour lvaluation de la maturit des processus de GSI. Il montre la corrlation
entre la maturit de la GSI et ses effets sur la maturit des processus SI. Jery Luftman (Luftman,
2004b) propose un modle de maturit pour lalignement mtier/SI tabli sur cinq niveaux. Il propose
dvaluer la maturit de lalignement par lintermdiaire de six critres : la maturit des
26
communications, la maturit des processus de mesure de la valeur, la maturit de la gouvernance, la
maturit des relations de partenariat, la maturit de larchitecture et la maturit des comptences des
acteurs. Chaque critre est associ un objectif pour la progression sur les niveaux de maturit de
lalignement. Ainsi au niveau 5 de lchelle de maturit de Lufman, la gouvernance des SI doit tre
intgre dans toute lorganisation et chez ses partenaires.
Les professionnels des SI proposent aussi des cadres dvaluation de la maturit de la GSI.
Cest le cas du modle de maturit de lISACA qui accompagne CobiT (AFAI, 2002). Au dernier
niveau (5) les processus de la GSI doivent tre capables de sadapter leur environnement, de prouver
leurs apports lefficacit, la performance et la valeur de lorganisation.
Dune manire gnrale les modles de maturit proposent toujours une chelle de maturit
plusieurs niveaux et chacun de ces niveaux, un ensemble dobjectifs et de critres satisfaire.
Nous reprsentons ces aspects par la facette MATURITE DES PROCESSUS qui est situe sur un
domaine de valeur complexe dfini par lensemble constitu du couplage niveau de maturit et
objectif.
MATURITE DES PROCESSUS : SET{niveau, objectif}
2.2.2.4.3. Capitalisation de la connaissance

Les mcanismes de partage de la connaissance manipuls pendant les activits de la GSI
permettent leur CAPITALISATION. Nous reprenons les mcanismes de partage de la connaissance
identifis dans (Nonaka, 1995). La socialisation est un moyen de partager le savoir entre individus ; ce
mcanisme se base sur lexprience individuelle. Lexternalisation consiste en lexplicitation des
connaissances tacites. Linternalisation est un processus dappropriation de la connaissance explicite
en connaissance tacite. La combinaison est un processus dexplicitation des connaissances explicites :
nous pouvons prendre lexemple dun mta-modle qui est une abstraction dun ou plusieurs modles.
Nous capturons ces aspects grce la facette CAPITALISATION DE LA CONNAISSANCE dfinie

sur un domaine comprenant les valeurs socialisation, externalisation, internalisation et combinaison.
CAPITALISATION DE LA CONNAISSANCE : Enum{socialisation, externalisation, internalisation,

combinaison}
2.2.2.4.4. Logiciel
La facette LOGICIEL capture les supports informatiques ddis la GSI. Les approches
actuelles insistent sur la ncessit de produire des indicateurs pour la GSI, de les prsenter aux
dcideurs sous forme de tableaux de bord. Cependant aucune ne traite de manire intgre la
fourniture dapplications de support la GSI.
27
Pourtant lexprience en dveloppement des SI montre que de tels moyens applicatifs peuvent
tre disponibles. Dans le domaine de la gouvernance mtier, les SI proposent des services de BI
(Business Intelligence) (Watson, 2007) qui permettent la restitution dindicateurs extraits des bases de
donnes oprationnelles, et agrgs dans des tableaux de bord pour permettre au dcideur mtier
dorienter ses choix tactiques ou stratgiques. Quen est-il de la GSI o les DSI ont des besoins
similaires ? LISI - Information System Intelligence ( ne pas confondre avec lIIS - Intelligence
Information System - qui regroupe les SI ddis aux services des renseignements gouvernementaux)
est un domaine presque inexistant. Une exprience simple de deux recherches sur Google le montre :
les requtes Information System Intelligence et Information Technology Intelligence ne
renvoient pas de rponses significatives que se soit via www.google.com ou via scholar.google.com.
Dans dautres domaines que la GSI, des applications de support lingnierie sont proposes :
CAME (Computer-aided Method Engineering) pour la conception des mthodes, CASE (Computer-
aided Software Engineering) pour les logiciels. Les outils daide lingnierie de la gouvernance
(CAGE) sont aussi peu dvelopps. Notons cependant la contribution de ITOMAT (Simonsson, 2008)
qui envisage la modlisation des processus SI dans le but de tracer les sources dindicateurs et de
mtriques dans le cadre de la GSI. Cependant cette approche se concentre uniquement sur les aspects
daudit pour la GSI.
Malgr le faible apport de la recherche en matire dintelligence pour les systmes

dinformation et doutils pour lassistance lingnierie de la gouvernance des SI. Il nous semble
important de mettre ce besoin en relief dans la facette LOGICIEL.
La facette LOGICIEL permet de capturer ces aspects. Elle prend comme valeur ISI (Information
System Intelligence) lorsquune approche traite dlments applicatifs ddis la prise de dcision
pour les SI. Elle prend comme valeur CAGE (Computer-aided Governance Engineering) lorsquune
approche traite dlments applicatifs pour le support aux activits dingnierie de la gouvernance.
LOGICIEL : Enum{ISI, CAGE}
En conclusion, lanalyse et la synthse des processus de dveloppement de la GSI aboutissent

la proposition suivante :
Facette Valeur
NATURE DES PROCESSUS Enum{ad-hoc, systmatique}
MATURITE DES PROCESSUS SET{Niveau; Objectif}
CAPITALISATION DE LA Enum{socialisation, externalisation, internalisation,
CONNAISSANCE combinaison}
LOGICIEL Enum{ISI, CAGE}
Tableau 2.5. Liste des facettes du monde du dveloppement.
28
2.3. Positionnement des approches
Nous venons de prsenter le cadre de rfrence facett de la GSI dont le rle premier est
didentifier les caractristiques principales de la GSI selon les 4 perspectives du sujet, de lusage, du
systme et du dveloppement. Cette caractrisation sert comparer des approches similaires mais
diffrentes, simplement en identifiant les facettes inexistantes et en considrant les valeurs des facettes
existantes dans chacune des approches comparer. Cette section est ddie la comparaison de cinq
approches pour la GSI. Ce sont les approches les plus cites en matire de pratique de la gouvernance
des SI : CobiT, COSO, ITIL, CMMi et PMBOK. Le tableau 2.6 rsume le positionnement des cinq
approches par rapport aux facettes du cadre et mentionne pour chaque facette, ayant une prsence dans
lapproche, les valeurs pertinentes associes. La suite de cette section dcrit brivement les approches
puis offre une discussion sur leur positionnement dans le cadre.
2.3.1. Les approches de la gouvernance des SI
2.3.1.1. CobiT : Control Objectives for information and technology

CobiT (Moisand, 2009) est un ensemble de recommandations et de processus permettant
dvaluer les ressources du SI. Il a pour objectif de guider les praticiens dans la mise en place des
contrles internes.
CobiT a t dvelopp en 1994 (et publi en 1996) par lISACA (Information Systems Audit
and Control Association). LISACA est reprsent en France depuis 1982 par lAFAI (Association
Franaise de lAudit et du Conseil Informatiques). CobiT est un cadre de contrle qui vise aider le
management grer les risques (scurit, fiabilit, conformit) et les investissements. CobiT a volu,
la version 4 est apparue en France en 2007.
CobiT est une approche oriente processus, qui regroupe en quatre domaines (planification,
construction, excution et mtrologie), 34 processus distincts qui comprennent en tout 215 activits et
un nombre plus important encore de "pratiques de contrle". Un volet "valuation des systmes
d'information", connu sous le nom de Val IT, tente de complter cette approche.
2.3.1.2. COSO : The Committee of Sponsoring Organizations of the Trendway Commission

COSO (Moeller, 2007) est une mthode de gestion de risques. Cette mthode a pour objectif
de guider les praticiens dans lidentification des risques associs aux objectifs de rendement et de
croissance.
COSO est lorigine le nom dune commission but non lucratif. Elle tablit en 1992 une
dfinition standard du contrle interne et cre un cadre pour valuer son efficacit. Par extension le
standard correspondant s'appelle aussi COSO.
29
En 2002, le Congrs amricain promulgue la loi SarbanesOxley (the Sarbanes-Oxley Act ou
SOX act). Cette loi oblige les socits faisant appel des investissements publics (cas des entreprises
cotes en bourse) valuer leur contrle interne et en publier leurs conclusions dans des rapports.
Imposant en outre l'utilisation d'un cadre conceptuel, le SOX act a ainsi favoris l'adoption du COSO
comme rfrentiel. En France, la loi LSF (Loi de scurit financire) promulgue peu aprs en 2003, a
galement contribu sa diffusion.
De manire plus prcise COSO assigne trois objectifs aux dirigeants de lentreprise :
l'efficacit et l'efficience des activits de lentreprise,

la fiabilit des informations financires,
la conformit aux lois et rglements.
COSO envisage les traitements des risques associs au non-accomplissement des objectifs
prcdents. Il propose ainsi un cadre daudit reposant sur cinq axes :
l'environnement de contrle, qui correspond, pour l'essentiel, aux valeurs diffuses

dans l'entreprise ;
l'valuation des risques au regard de leur importance et de leur frquence ;
les activits de contrle, dfinies comme les rgles et procdures mises en uvre pour
traiter les risques ;
l'information et la communication, qu'il s'agit d'optimiser ;
la supervision, c'est--dire lassurance que le contrle interne est bien effectu.
COSO est ainsi un cadre qui permet de grer les risques tout les niveaux de lentreprise, et
pas uniquement de sa composante SI.
2.3.1.3. ITIL : IT Infrastructure Library

ITIL se positionne sur la gestion des services TI (Chamfrault,2006). Il a pour objectif de
guider, par les bonnes pratiques, les professionnels des SI dans la gestion efficace des ressources et
lobtention de la qualit des services informatiques.
ITIL permet, grce une approche par les processus clairement dfinis et contrls,
d'amliorer la qualit des SI et de l'assistance aux utilisateurs en crant la fonction Centre de services
qui centralise et administre l'ensemble de la gestion des systmes d'informations. ITIL est finalement
une sorte de "rglement intrieur", de manuel de qualit, du dpartement informatique des entreprises
qui l'adoptent. Les apports pour l'entreprise sont une meilleure traabilit de l'ensemble des actions du
dpartement informatique. Ces traces servent de base loptimisation des processus de services TI
pour atteindre un niveau de qualit maximum du point de vue de la satisfaction des clients.
30
Dans sa dernire version, ITIL comporte cinq ouvrages, chacun traitant dune perspective pour
les services informatiques :
La stratgie des services : aborde les aspects de la gestion financire, de la gestion du

portefeuille des projets de service ainsi que la gestion des demandes. Lobjectif est de
garantir que les futurs services soient aligns avec les besoins mtiers et creront une
valeur pour l'entreprise.
La conception des services : ce sont sept processus mettre en uvre pour grer la
continuit des services et leurs volutions. Elle propose un ensemble dindicateurs
pour la mesure de lalignement de la capacit des services la demande.
La transition des services : propose quatre processus pour la gestion des changements,
des configurations, du dploiement des services et de la connaissance.
Lexploitation des services : propose les bonnes pratiques en matire de gestion des
niveaux de contrat de services (SLA).
Lamlioration continue des services : cet ouvrage traite de la supervision de
lalignement et de la mise en uvre du plan damlioration des services.
Par ces orientations, ITIL couvre un large champ de la gouvernance des SI en se concentrant
sur la notion de service et sa qualit. Il exploite la notion de contrat de service entre les demandeurs de
services, et les fournisseurs de services.
2.3.1.4. CMMI : Capability Maturity Model Integrated

CMMi (Chrissis, 2008), (SEI, 2006) se positionne sur lvaluation de la maturit des processus
de gestion des projets. Le CMMi a pour objectif damener une organisation optimiser lefficacit et
la qualit de ses processus. Il se compose des bonnes pratiques issues des modles de maturit CMM-
SE (ingnierie des systmes), CMM-SW (ingnierie des logiciels), CMM-IPD (dveloppement des
produits) et CMM-SS (gestion des fournisseurs). Ces derniers modles ont t progressivement
proposs partir de 1991.
CMMi a t dvelopp et propos en 2001 par le Software Engineering Institute (SEI) de

l'universit Carnegie Mellon. Son objectif initial tait dapprhender et de mesurer la qualit des
services rendus par les fournisseurs de logiciels informatiques du Ministre de la Dfense des Etats-
Unis (DoD). Il est maintenant largement employ par les entreprises d'ingnierie en informatique, par
les DSI et les industriels pour valuer et amliorer leurs propres dveloppements.
La dernire version (v1.2) du CMMi parue en 2006 considre 22 domaines de processus quil
convient dvaluer sur une chelle de 5 niveaux de maturit :
31
Niveau 1 (Initial) : lorganisation des projets de dveloppement repose entirement sur
les comptences des acteurs sans quil y ait un consensus prtabli sur les dmarches.
Il se peut que les projets aboutissent, mais en dpassant les budgets et les dlais.
Niveau 2 (Reproductible) : le dveloppement des projets repose sur les acquis des
expriences prcdentes. Il existe une gestion basique des connaissances sur les
projets qui sont grs selon des plans. Les contrles des cots et des fonctionnalits
sont assurs localement, au niveau de chaque projet.
Niveau 3 (Dfini) : Lorganisation dans son ensemble dispose dune visibilit sur tous
les projets. Il existe une discipline de gestion des cots et des fonctionnalits au
niveau global.
Niveau 4 (Matris) : Les efforts de mesure au niveau local et au niveau de
lorganisation de lensemble des projets permet lajustement des projets et de leurs
ressources, sans effet de bord sur les autres projets. Les performances des processus
sont prvisibles qualitativement et quantitativement.
Niveau 5 (Optimis) : Les processus de gestion des projets sont constamment
amliors de manire incrmentale. Les volutions sont anticipes et les objectifs sont
revus en permanence afin de rester proches des attentes des clients.
Le CMMi se rapporte ainsi la maturit des processus de dveloppement des projets, dans le
but dassurer la performance et le respect des cots, de la qualit et des dlais.
2.3.1.5. PMBOK : Project Management Body of Knowledge

PMBOK (Project Management Body of Knowledge) (PMI, 2010) est le guide du Project
Management Institute dfinissant les champs des connaissances utiles dans le cadre de la gestion de
projet.
Le Project Management Institute (PMI) publie le premier volume du PMBOK en 1987 comme
une tentative de documenter et normaliser les informations et les pratiques de la gestion de projet.
Depuis la 4me dition parue le 31 dcembre 2008, le PMBOK est harmonis avec les autres
normes et pratiques de la gestion de projet. Il intgre plus particulirement la gestion des programmes
et des portefeuilles de projets, et il est adapt aux normes Organization Project Management Maturity
Model (OPM3) et Unified Project Management Lexicon (UPML).
Dans son contenu, le PMOK identifie 42 processus pour la gestion des projets. Chaque
processus est prsent comme des mcanismes de transformation dintrants (documents de
planification, de conception) en extrants (documents, produits). Chaque processus est situ par
rapport cinq groupes de processus (ou types de processus) et neuf domaines de connaissances.
32
Les cinq types de processus correspondent linitialisation, la planification, lexcution,
lvaluation et le contrle, et la fermeture des projets.
PMBOK est orient connaissance. Ainsi chaque processus a un apport potentiel aux
connaissances en matire de :
1. Gestion des intgrations

2. Gestion des objectifs
3. Gestion des cots
4. Gestion des dlais
5. Gestion de la qualit
6. Gestion des ressources humaines
7. Gestion de la communication
8. Gestion des risques
9. Gestion des acquisitions
PMBOK est ainsi un cadre de bonnes pratiques pour la gestion des projets.
2.3.2. Synthse du positionnement

Le tableau 2.6 prsente les caractristiques des cinq approches de gouvernance des SI que
nous avons retenues. CobiT, ITIL, CMMi et PMBOK sont ainsi positionns par lidentification des
facettes que chaque approche considre et par les valeurs spcifiques des facettes du cadre.
La grille de lecture du tableau 2.6 est la suivante : chaque cellule mentionne la ou les valeurs
spcifiques des facettes pour lapproche considre. Par exemple, on voit que lapproche ITIL a une
orientation volutive du changement pour la GSI. La cellule correspondante mentionne ainsi la valeur
volutif. Lorsquune approche est pertinente sur toutes les valeurs dune facette nous mentionnons
une toile (*) dans la cellule correspondante. Ainsi les approches COSO et CobiT sont pertinentes
lorsquon considre la facette MINIMISATION DU RISQUE. Lorsquune facette nest pas pertinente pour
une approche nous mentionnons un tiret (-).
Le tableau montre que les approches ne sont pas compltes au regard du cadre. En effet,
certaines facettes ne sont pas couvertes par certaines approches et, aucune approche ne couvre
lensemble des facettes du cadre. Cela signifie que les approches ne sont pas compltes mais
parcellaires. Les manques sont plus particulirement flagrants pour les mondes de lusage et du sujet.
Cela sexplique sans doute par le fait que les approches ont t produites dans lobjectif de rpondre
un besoin spcifique de la gouvernance sans prendre en compte la totalit de ses aspects. Par exemple,
COSO et CobiT sont ddis au risque alors quITIL est davantage centr sur lalignement.
Lapproche la plus complte au regard du cadre est PMBOK. Cependant, les fonctionnalits sont
33
partielles pour la GSI car lapproche PMBOK reste gnraliste et centre sur la gestion de projets. Les
indicateurs et mtriques par exemple ne sont pas pris en compte.
Chaque approche propose des processus et des bonnes pratiques pour la mise en uvre des
activits de la GSI. Les outils et applicatifs de support existent pour accompagner les activits de la
gouvernance mais ils sont parcellaires, ddis une approche particulire. Ainsi les SI de support la
GSI existent partiellement, mais leur dveloppement suit une logique fonctionnelle telle quon a pu
lexprimenter dans les annes 70 pour les dveloppements des outils mtiers. Les outils CAGE et ISI
tels que nous les avons introduits dans le cadre nont que de trs ples instanciations dans les
approches slectionnes.
Notons enfin que lensemble des approches tentent de mettre en place une capitalisation de la
connaissance par externalisation, c'est--dire par explicitation et formalisation. Cela est
symptomatique des approches o la connaissance est dicte sans pour autant envisager un
enrichissement (cas de capitalisation de la connaissance par combinaison). Cela sexplique par la
focalisation sur lnonc des bonnes pratiques. Cela justifie la publication de versions successives des
livres de bonnes pratiques. Par exemple, la version 5 de CobiT est prvue pour 2011. En 15 ans
dexistence de ce cadre daudit, lISACA a ainsi publi une version tous les trois ans (sans compter les
versions intermdiaires).
Le cadre dmontre quil ny a pas aujourdhui dapproche de la GSI couvrant lensemble des
besoins de la GSI. Lobjectif de cette thse est motiv par cette vidence. Notre intention est de palier
au manque de vision globale et structure des concepts sous jacents la GSI dune part et des
processus de la GSI dautre part.
34
Cadre des quatre mondes Approches de la gouvernance des systmes dinformation
Monde Facette CobiT COSO ITIL CMMI PMBOK
Sujet ORGANISATION DE LA
* * - - *
GOUVERNANCE
DECISION - - Infrastructure - Plan. projet
PROCESSUS IT * * * * *
PROCESSUS METIER - * * - *
CHANGEMENT * - volutif * *
PORTEFEUILLE DE Clas. : Multi-critre Clas. : Multi-critre
- - *
PROJETS SI Transfo. : * Transfo. : *
Usage MINIMISER
* * qualit * *
LES RISQUES
ATTEINDRE LETAT Evolution SI, Evolution
- - Evolution SI -
DALIGNEMENT mtier
OBTENIR
- - - Maturit des processus Maturit des processus
LA PERFORMANCE
Patrimoine SI,
CREER DE LA VALEUR - Patrimoine mtier Patrimoine SI, usage Patrimoine SI
Patrimoine mtier
Systme CONTENU document document document document document
Processus, objet,
MODELE Processus, objet Processus, objet Processus, objet Processus, objet
dcision
Risque, performance, Alignement, Risque, Performance,
METRIQUES risque performance
valeur performance Valeur
Dveloppement NATURE
systmatique systmatique systmatique systmatique systmatique
DES PROCESSUS
MATURITE
* - - * *
DES PROCESSUS
CAPITALISATION DE
externalisation externalisation externalisation externalisation externalisation
LA CONNAISSANCE
LOGICIEL * * * * *
Tableau 2.6. Synthse du positionnement des approches de la GSI.
35
2.4. Conclusion
Dans ce chapitre nous avons propos un cadre facett danalyse de la GSI. Ce cadre considre
quatre perspectives, appeles mondes du sujet, de lusage, du systme et du dveloppement de la GSI.
Ces quatre perspectives sont dtailles par des facettes et leurs valeurs.
Ce cadre a t appliqu 5 approches connues pour la gouvernance des SI. Cet exercice
dapplication a rvl quaucune des approches actuelles ne couvre la totalit des facettes du cadre.
Les approches nont pas de vision globale de la GSI mais des visions parcellaires. Lemphase est
surtout sur les recueils de bonnes pratiques actualiss rgulirement.
Ce travail sur ltat de lart a permis de mettre en vidence le besoin dune recherche sur la
globalit de la GSI. Il vient alimenter et confirmer notre problmatique de recherche : Quelle
conceptualisation de la gouvernance des SI pour la construction dun SI de gouvernance ?
Notre proposition vise fournir une comprhension globale de la GSI par la conceptualisation
et devrait compenser les manques actuels.
Le chapitre suivant prsente plus prcisment notre proposition autour des modles
conceptuels et des processus pour lingnierie des SI de gouvernance.
36
Chapitre 3. Aperu de la solution
3.1. Introduction
Ce chapitre prsente la solution propose dans cette thse pour epondre la problmatique
retenue. Rappelons que cette dernire se rfre au constat dun manque de conceptualisation de la
Gouvernance des Systmes dInformation (GSI). Lanalyse de la littrature montre la faiblesse des
investigations de la recherche dans ce domaine. Nous rpondons cette problmatique en proposant
un cadre dingnierie de SI se composant :
1. dun modle conceptuel de la GSI (REFGOUV) dont lobjectif est de dcrire le systme
de concepts qui sous tend la GSI.
2. dun modle de processus de la GSI (PROGOUV) dont lobjectif est de dcrire la
dynamique dusage des concepts de la GSI.
3. dun modle dingnierie de SI qui sert de support une dmarche de construction du
SI, de support la GSI.
Nous organisons ce chapitre en trois parties :
La section 3.2 est un rappel de la problmatique et des hypothses de travail.

La section 3.3 expose la solution retenue.
La section 3.4 est une synthse des apports de nos travaux.
3.2. Rappel de la Problmatique et des hypothses de travail
3.2.1. Problmatique
Le manque de recherche en matire de conceptualisation de la GSI, et la ncessit de
construire un SI en cohrence avec les besoins des activits de la GSI, nous ont amen noncer la
problmatique suivante :
Quelle conceptualisation de la gouvernance des SI pour la construction dun SI de

gouvernance ?
Elle est justifie par la ncessit de (i) comprendre le concept de GSI, (ii) le modliser et le
formaliser ; (iii) comprendre le processus de la GSI et (iv) de fonder les activits de GSI sur un SI de
support.
37
3.2.2. Hypothses
Comme dcrit prcdemment, les activits de gouvernance des SI alimentent une dmarche de
pilotage du portefeuille des projets qui est dirige par les buts, avec une cible en mouvement. Ce
constat nous permet denvisager une reprsentation de la gouvernance des SI comme un tout constitu
dun produit, qui dcrit le systme de concepts qui sous tend la GSI, et dun processus qui a pour
objectif de guider la dynamique de lvolution du contexte de la GSI.
Il convient, par exemple de positionner un processus daudit de projet de SI comme un

ensemble dtapes de contrles oprer en se servant dindicateurs de projet. Lobjectif dun tel audit
peut tre de mesurer les cots oprationnels des projets. Nous devons ainsi associer un objectif un
processus daudit (produit) et reprsenter la ou les manires possibles de faire voluer ce produit
(processus).
Notre dmarche repose sur les hypothses suivantes :
H1 : la GSI est un artfact que lon peut conceptualiser
H2 : un systme dinformation de gouvernance correctement conceptualis est utile la bonne

mise en uvre de lactivit de gouvernance
Suivant la perception prcdemment formule pour la GSI, nous affinons H1 en deux sous-
hypothses :
H11 : Lactivit de la GSI manipule un ensemble dlments conceptualisables
H12 : Le processus de la GSI est lui-mme conceptualisable
Ces hypothses guident les choix qui ont t pris dans la section suivante. Nous montrons
galement leur validit dans le chapitre 6 qui exploite notre proposition pour la conceptualisation de la
GSI et lingnierie du SI associ.
3.3. Solution
3.3.1. Proposition
Comme le montre la Figure 3.1, notre proposition sorganise autour de trois axes ou univers :
Lunivers des langages. Il comporte les mta-concepts utiliss dans les recherches
acadmiques. Nous manipulons ainsi les concepts formaliss comme des objets et les
propos de leurs usages formaliss comme des intentions.
38
Lunivers des modles. Cest laxe que nous enrichissons. Nous y proposons le
modle de rfrence pour les concepts de la GSI (REFGOUV), le modle de rfrence
pour les processus de la GSI (PROGOUV) et le modle dingnierie du SI de support
la GSI (MISIG). Les modles reposent formellement sur les mta-concepts de
lunivers des langages.
Lunivers des systmes. Il contient lensemble des lments manipuls dans le cadre
des activits de GSI. Il comporte le SI dans son ensemble ainsi que les informations de
support la GSI (rfrentiel des projets SI, modles de processus mtier,
indicateurs).
Langage
Objet Intention
Mta-modle Mta-modle
Universitaires et
UML CARTE chercheurs
Approches de
instanciation
Conceptualisation la GSI
-Articles
Concept -Rfrentiels
Modle REFGOUV
formel
PROGOUV
A Dbut
I1 fin
B C
MISIG
Systme Indicateurs
Projet
Projet11 a
G.S.I. Projet
Projet11 -DSI
? b - Ingnieur mthode
-Ingnieur programme
Rfrentiel c - Responsable projet
de donnes Dcision
Valeur
Figure 3.1. Univers de lapproche
Les univers des langages et des modles intresseront plus particulirement la communaut
acadmique car ils apportent les dmarches de conceptualisation et de manipulation des langages
semi-formels. Cette thse traite plus particulirement du domaine de la GSI et de sa conceptualisation.
Ainsi les chercheurs du domaine du management des SI trouveront ici des lments linterface de
leur domaine et de celui de lingnierie des SI, et rciproquement.
Les univers des modles et des systmes intresseront, plus particulirement, les
professionnels et praticiens des systmes dinformation qui sont la recherche de modles adapts
pour une dmarche dingnierie du SI, de support la GSI. Les DSI et les dirigeants dentreprise
trouveront ici des lments dextension aux bonnes pratiques qui complteront un projet de mise en
place dun rfrentiel de gouvernance.
39
Nous discutons successivement les niveaux 2, 3 et 1.
La figure 3.1 montre une vue densemble de notre proposition.
3.3.2. Lunivers des modles
3.3.2.1. REFGOUV : dimension statique du SI de gouvernance

Le modle REFGOUV est obtenu par conceptualisation. Il est issu de lobservation et lanalyse
de la littrature. Lextraction des concepts de la GSI est ralise partir des lments de la littrature.
Elle correspond lanalyse de la smantique dun texte.
La smantique est la branche de la linguistique qui tudie les termes ou les signifis. Ainsi
nous regroupons un ensemble de termes et mots (les signifiants) autour dun lment cl, le concept
(le signifi). Ce regroupement se fait par distance smantique. Ainsi un texte o les termes mesure
ou value apparaissent, nous guide vers la structuration du concept de mtrique.
Lobjectif du modle REFGOUV est de reprsenter la GSI comme une ontologie, un systme
statique de concepts. Ce modle considre les concepts dans leur ensemble : il dcrit leur structure
intrinsque, leurs proprits et les relations quils entretiennent avec les autres concepts.
Nous utilisons le langage UML pour reprsenter les concepts. La GSI y est dcrite comme un
mcanisme de contrle et de rgulation du portefeuille de projets SI. Elle rpond un besoin et un
ensemble dobjectifs. REFGOUV intgre ainsi les notions de but, de projet SI, dindicateur, de mtrique
et de dcision, comme des concepts manipuls par les DSI, pour dfinir le cadre de la gouvernance des
projets SI. Ils sont galement utiliss par les ingnieurs SI pour la construction du SI, de support la
GSI (Fig. 3.2).
Lavantage de notre approche rside dans la nature de la solution : par la proposition dun
modle nous rpondons un besoin de gnricit qui intgre une pluralit de situations, ou instances,
possibles un niveau dabstraction infrieur. Cela en fait un complment idal aux rfrentiels de
bonnes pratiques qui imposent la prise en compte dun nombre fig dobjectifs (34 dans le cadre de
CobiT).
40
Langage Systme
Objet G.S.I.
Objectif
Mta-modle Utilise
UML Projet
Rfrentiel
de donnes Indicateur
Ingnieur SI
tudie -DSI
MISIG -Ingnieur programme
- Responsable projet
Modle Concept
formel
REFGOUV
Propose
A
Universitaires et
chercheurs
B C
Figure 3.2. Usages et situation du modle REFGOUV
Comme lillustre la Figure 3.2, REFGOUV a pour vocation dtre utilis par lingnieur SI pour
construire le systme dinformation de support la GSI. REFGOUV est ainsi associ la mthode
MISIG pour produire le rfrentiel de donnes du SI. Par lusage de ce SI, les DSI et les responsables
de programme peuvent raliser des requtes pour visualiser le cot des projets. Cet exemple ncessite
davoir dans le modle une reprsentation des concepts de projet, de celui dindicateur et des relations
quils entretiennent. Cette modlisation servira lingnieur du SI pour faire voluer le rfrentiel des
donnes avec la structure de donnes ncessaire au traage de linformation de cot par projet.
3.3.2.2. PROGOUV : dimension dynamique du SI de gouvernance

Notre position est que la nature du processus de gouvernance SI est dcisionnelle et
intentionnelle. Cela nous conduit choisir le langage de la CARTE comme mta-modle pour
exprimer le modle PROGOUV. Le mta-modle de la CARTE est tendu pour permettre la
manipulation des concepts de GSI.
Lobjectif du modle PROGOUV est de reprsenter la dmarche intentionnelle des gouvernants

et des dcideurs pour les SI. Il reprsente le composant processus de la dmarche de gouvernance des
SI.
Comme le montre la Figure 3.3, PROGOUV reprsente ainsi les transitions intentionnelles
portes sur les concepts explors dans REFGOUV. Il permet le guidage des dirigeants dans la
construction dune architecture de gouvernance des SI qui repose sur des objectifs et des portefeuilles
projets quil convient de mettre sous contrle. Par extension, il reprsente le modle des donnes que
le SI de support la GSI doit contenir.
41
Universitaires et
chercheurs
Modle
REFGOUV
A Propose
B C
PROGOUV
MISIG Dbut
Intgre
I1 fin
Ingnieur SI
Construit
Organise
Systme
Objectif
Projet Supporte O
Rfrentiel
de donnes Indicateur
Activits de Gouvernance des SI :
Plannifier
Excuter
Contrler
Dcider
Figure 3.3. Usages et situation du modle PROGOUV
PROGOUV a pour vocation dtre utilis par les ingnieurs SI pour dployer le SI en support
des activits de gouvernance du SI. Le dploiement consiste apporter au bon endroit, au bon moment
et la bonne personne, linformation qui lui est utile. PROGOUV permet de reprsenter la dmarche de
gouvernance du SI. Associ MISIG, PROGOUV permet lingnieur SI de construire un sous-
ensemble du SI qui va permettre le support une activit spcifique de la GSI. Par exemple, lactivit
de dfinition des objectifs stratgiques est une situation capture par le modle PROGOUV qui oriente
lingnieur sur lidentification des concepts prsents dans REFGOUV pour construire le SI
correspondant.
3.3.2.3. MISIG : Mthode dIngnierie du Systme dInformation de Gouvernance

MISIG est transversale lusage des modles REFGOUV et PROGOUV. MISIG est une
mthode qui guide lingnieur SI dans la construction du SI de gouvernance et de ses composants. Il
sagit doprer une instanciation partielle ou totale des concepts prsents dans REFGOUV : lorsque
lingnieur observe une transition intentionnelle dans PROGOUV, lintention cible porte sur un sous
ensemble des concepts de REFGOUV. La construction du SI est ainsi guide par les activits de GSI et
se fait par brique .
Cette dmarche est prsente, et illustre au chapitre 6.
42
3.3.3. Lunivers des langages
3.3.3.1. UML : mta-concepts pour la dfinition des concepts de GSI

UML est un standard maintenu par lOMG (OMG, 2010). Il se rapporte au paradigme objet.
UML est originairement un langage de conception logiciel. Il permet de spcifier les objets
manipuls dans le cadre dune application (diagramme de classes). Le diagramme de classes constitue
un lment trs important de la modlisation : il permet de dfinir quelles seront les composantes du
systme final ; il ne permet pas, en revanche, de dfinir le nombre et les tats des instances
individuelles.
Dans le domaine de la recherche, le langage UML a t utilis plusieurs reprises avec

succs : il permet de structurer des mta-modles dans le cadre dune approche MDA (Mellor, 2002),
de modliser des ontologies (Cranefield, 2001), de spcifier des modles de domaine pour les mtiers
dans le cadre de larchitecture dentreprise (Lankhorst, 2009) ou encore de spcifier des systmes
multi-agents (Bergenti, 2000). Cela fait dUML un langage stable, de rfrence, en matire de
modlisation pour reprsenter des concepts et leurs relations.
Dans notre cas, nous choisissons dutiliser ce langage pour modliser les concepts de la GSI et
montrer les relations quils entretiennent entre eux.
3.3.3.2. MAP : mta-concepts pour la dfinition des processus de GSI

La CARTE (MAP) est un langage de modlisation des intentions (Rolland, 2001). Lintention
est la projection dun souhait port sur un systme dans un tat courant ( As-is ), pour son volution
dans un tat futur ( To-be ). Le cheminement entre les intentions, ou transition intentionnelle, y est
modlis par le concept de section qui est lassociation de trois mta-concepts : lintention source,
lintention cible et la stratgie. Une stratgie est le moyen ou la manire datteindre une intention cible
partir dune intention source.
Le formalisme de la CARTE a t utilis dans plusieurs domaines, par exemple lingnierie

des besoins (Rolland, 1999), lingnierie des mthodes (Ralyte, 2005) et lingnierie des processus
(Nurcan, 2004). Plus rcemment, la carte a t utilise pour formaliser les exigences de GSI
(Claudepierre, 2009a) et pour lanalyse du contexte du processus dingnierie des mthodes
(Kornyshova, 2010). (Rolland, 2010) propose de reprsenter la variabilit des modles de processus
par lintermdiaire de familles ou lignes de processus.
Dans notre cas, la CARTE permet de reprsenter le processus intentionnel pour la GSI. Les
intentions portent sur un systme qui est celui de la GSI.
43
3.3.4. Lunivers des systmes
Lunivers des systmes contient les lments composant le systme dinformation. Il est
constitu des donnes et applications qui sont utiles aux acteurs de la gouvernance des SI. Dans notre
approche, les lments du systme sont des instances des concepts prsents dans lunivers des
modles. La cohrence de ces instances par rapport aux modles est assure par MISIG.
3.4. Synthse des apports

Lobjectif de nos recherches est de dfinir les concepts manipuls par la GSI, et de construire
un SI de support aux activits de GSI.
Nous rpondons cet objectif en proposant :
le modle REFGOUV est exprim suivant le langage UML. Il modlise les objets
(concepts) manipuls par la GSI et leurs relations.
Le modle PROGOUV est exprim suivant le langage de la CARTE. Il formalise le
processus de GSI dont la nature est dcisionnelle et intentionnelle.
La mthode MISIG formalise le processus dingnierie du SI par linstanciation des
modles PROGOUV et REFGOUV.
Les chapitres suivants sont ainsi organiss :
Le chapitre 4 prsente le modle REFGOUV

Le chapitre 5 prsente le modle PROGOUV
Le chapitre 6 est une double valuation de notre proposition par (i) confrontation avec
les standards de GSI et (ii) par une tude de cas instanciant les concepts de REFGOUV
et PROGOUV.
44
Chapitre 4. REFGOUV : modle de
rfrence du domaine de la GSI
4.1. Introduction
Comme nous lavons prcdemment soulign, la gouvernance des systmes dinformation
(GSI) est une activit de pilotage des projets qui est dirige par les buts, et dont la conduite est assure
par lexcution dun processus. Cest ce constat qui nous permet denvisager une reprsentation de la
GSI comme un tout constitu dun produit, dcrivant le systme de concepts qui sous tend la GSI, et
dun processus qui a pour objectif de faire voluer le contexte de la GSI. Cest dans cette double
reprsentation que rside la premire originalit de notre approche.
La GSI est une dmarche de pilotage des projets qui vise atteindre une cible mouvante. En
effet, dans la mesure o des changements en provenance de lenvironnement externe ou interne de
lentreprise peuvent dplacer soit la cible atteindre, soit la situation dans laquelle le projet se trouve,
il serait vain desprer que la trajectoire du projet soit entirement identique celle planifie au
dmarrage.
En outre, tout systme (ici celui du portefeuille de projets) peut tre dirig et mis sous contrle
condition de savoir dfinir (i) les dispositifs permettant de mesurer si les objectifs qui lui ont t
assigns sont atteints, et dans le cas contraire (ii) les leviers (variables) daction pour corriger les
carts. Dans ce contexte, il semble plus particulirement prometteur de miser sur des systmes de
pilotage pouvant sadapter et apprendre. Le systme de pilotage doit donc disposer dun organe qui
lui permette de mmoriser ce qui a t fait, et de raisonner sur ce qui reste faire. Ce qui est a priori
inconnu, dans la mesure o tout nouvel vnement non planifi (ou tout incident de parcours) pourrait
changer la donne. La gouvernance est donc avant tout une affaire de prise de dcision dans lincertain.
La mdiation des dcisions prendre et des actions qui en dcoulent est assure par un dcideur anim
par la volont davancer vers la cible assigne au projet ou au portefeuille de projet. Dans la mesure o
cette cible est mouvante, et relative la situation du projet, le dcideur est responsable de ses leviers
dactions correctives (ajustement) afin de garder le cap par vents et mares.
Ce chapitre a pour objectif de prsenter un modle conceptuel de la GSI dont lobjectif est de
dcrire le systme de concepts qui sous tend la GSI. Rappelons que ce sont les insuffisances notoires
en matire de conceptualisation de la GSI et la ncessit de construire un SI en cohrence avec les
besoins des activits de la GSI qui nous ont conduit chercher une conceptualisation de la
gouvernance des SI pour la construction dun SI de gouvernance. Parmi les multiples raisons de cette
conceptualisation introduites au chapitre prcdent, nous soulignerons ici plus particulirement la
45
ncessit de fonder les activits de GSI sur un SI de support. Cest la deuxime originalit de notre
approche que de se munir dun dispositif pour faciliter la capitalisation, lapprentissage et
ladaptation. REFGOUV a pour vocation dtre utilis par lingnieur SI pour construire le systme
dinformation de support la GSI.
En rsum, nous apprhendons la GSI comme un mcanisme de contrle et de rgulation du

portefeuille de projets SI. Elle rpond un besoin et un ensemble dobjectifs. REFGOUV intgre ainsi
les notions de but, de projet SI, dindicateur, de mtrique et de dcision. Ces concepts sont manipuls
par les DSI pour dfinir un cadre pour la gouvernance des projets SI et par les ingnieurs SI pour la
construction du SI de support la GSI.
Le modle REFGOUV est construit par conceptualisation base sur lobservation et lanalyse de
la littrature. Ce modle considre les concepts dans leur ensemble ; il dcrit leur structure intrinsque,
leurs proprits et les relations quils entretiennent avec les autres concepts.
4.2. Reprsentation des concepts

Un concept peut se dfinir comme la reprsentation intellectuelle dune ide abstraite. Cest
lide que lon se fait dune chose en la dtachant de son objet rel.
La conceptualisation est un processus mental permettant daboutir la construction dune

perspective abstraite et simplifie de la connaissance des lments de notre ralit. Il aboutit la
construction dun systme de concepts ou ontologie. Nous prsentons ici les concepts de la GSI
regroups dans un mta-modle : REFGOUV.
La forme expressive des concepts est guide par lusage du langage UML :
un concept est reprsent par une classe,

une caractristique du concept est reprsente par un attribut de classe
un lien smantique est reprsent par une association
une taxonomie est reprsente par le lien dhritage
46
Chien Personne
+proprit 1..*
+Nom +Nom
+DateNaissance 1..* +propritaire +Prnom
+Pedigre +Adresse
Terrier Berger
+NBChasse +NBTranshumance
Figure 4.1. Concept de chien.
Dans notre monde, le concept de chien est un bien de proprit et est sous la responsabilit
dune personne, le propritaire. Un chien possde plusieurs caractristiques gnriques comme son
nom (Nom), sa date de naissance (DateNaissance) et son pdigre (Pedigre). Suivant sa race,
(taxonomie de chien) il possde des caractristiques spcifiques : un chien de berger aura particip
un certain nombre de transhumance (NBTranshumance). Cet exemple est reprsent suivant le
formalisme UML la Figure 4.1.
Dans ce chapitre nous utilisons ainsi ce langage pour reprsenter les concepts qui sous-tendent
la GSI. Les mta-concepts UML sont prsents la Figure 4.2.
dimension
Type
+nom: String dimension de retour
Concept
dimension
+nom: String
reprsente
+description: String
source
+attributs * Attribut
Association cible Classe
+nom: String
* * +oprations
hrite *
Opration
+paramtres
+nom: String
*
Paramtre
+nom: String
Figure 4.2. Mta-modle UML
Une classe reprsente un concept. Cest un type ou lment classifiant qui comporte un
ensemble dattributs et de mthodes ou oprations. Les attributs, les oprations et leurs paramtres
ont chacun une dimension, ils se rfrent un domaine de valeurs dfinies par un type. Une
association lie deux classes : une classe source et une classe cible. Plusieurs types dassociation sont
dfinis par lOMG (OMG, 2010) :
47
Hritage : elle prsente une classe spcifique comme spcialisation d'une classe plus
gnrique. Cette classe spcifique propose des mthodes dont la classe gnrique ne
dispose pas, tout en conservant la plupart des mthodes de cette classe "mre". La
classe Classe hrite de la classe Type dans le mta-modle UML. Lhritage
est reprsent par une ligne, termine par une flche vide.
Dpendance : cette relation reprsente l'utilisation que fait une classe (et par
instanciation un objet de cette classe) d'une autre. Une classe dpend d'une autre classe
si ses mthodes manipulent des objets de cette autre classe. Par exemple,
DateNaissance (Fig. 4.3) est un objet qui dpend de la classe Attribut par le
strotype instance de . En UML, une dpendance est reprsente par une ligne en
pointills, termine par une simple flche.
Agrgation : cette relation indique un principe de subordination entre l'agrgat (classe
qui regroupe les classes agrges) et les agrges. L'agrgat peut contenir plusieurs
objets d'un type. Par exemple, une classe Rservation peut contenir un ou plusieurs
objets de type Billet de Train. En UML, une agrgation est reprsente par une ligne
entre deux classes, termine par un losange vide ("diamant") du ct de l'agrgat.
Composition : Aussi appele "agrgation forte" ou "agrgation par valeur". Il s'agit en
fait d'une agrgation laquelle on impose des contraintes internes : un seul objet peut
faire partie d'un composite (l'agrgat de la composition), et celui-ci doit grer toutes
ses parties. En clair, les cycles de vie des composants sont totalement dpendants du
cycle de vie du composite. Par exemple, un objet de type Attribut est un composant de
lobjet de type Classe (Fig. 4.3). En UML, la composition est reprsente de la mme
manire que l'agrgation, mais le diamant est plein.
Association : C'est la relation la plus simple entre deux classes. Elle existe partir du
moment o l'une des deux classes sert de type un attribut de l'autre, et que cette autre
envoie des messages la premire (condition ncessaire pour une association). Une
association indique que deux classes communiquent entre elles (dans un sens ou dans
les deux sens). Cest le cas de lassociation entre la classe Chien et la classe
Propritaire (Fig. 4.2). En UML, une association est reprsente par une ligne entre
deux classes, possiblement accompagne d'une flche si l'association n'est pas
bidirectionnelle.
Le langage UML a pour particularit de pouvoir exprimer des concepts des niveaux
dabstraction diffrents : les concepts manipuls un niveau dabstraction suprieur sont appels
mta-concepts et sont dcrits, ainsi que les relations quils entretiennent, dans un mta-modle. Les
concepts (ou objets) manipuls des niveaux dabstraction infrieurs sont des instances de mta-
concepts. Ainsi, dans notre exemple (Fig. 4.3), la notation UML permet la fois la reprsentation des
48
mta-concepts dUML et la reprsentation du concept Chien comme instance des mta-concepts du
mta-modle UML.
Chien String : Type Date : Type Type

<<instance de>>
+Nom: String nom = "String" nom = "Date" +nom: String
+DateNaissance: Date
+Pedigre: String
<<instance de>> dimension
Attribut
Nom : Attribut Pedigre : Attribut DateNaissance : Attribut <<instance de>>
+nom: String
nom = "Nom" nom = "Pedigre" nom = "DateNaissance" *
<<instance de>> +attributs
Chien : Classe <<instance de>> Classe

nom = "Chien"
Le concept 'Chien' comme ensemble d'objets instancis Mta-Modle UML
Figure 4.3. Le concept chien reprsent par le langage UML
Dans la section suivante, nous prsentons en dtail le modle REFGOUV qui formalise et met
en relation les concepts de la GSI. REFGOUV est construit par instanciation des mta-concepts dUML.
4.3. REFGOUV : Modle de rfrence du domaine de la GSI

La figure 4.4 organise les concepts de REFGOUV dans un diagramme de classes. Nous
proposons ainsi de dcrire la GSI par lintermdiaire de quatre notions fondamentales :
Le but (concepts entours en trait plein sur la Fig. 4.4)

Le projet (concepts entours dun trait discontinu alternant point et trait sur la Fig. 4.4)
La dcision (concepts entours en pointill sur la Fig. 4.4)
La mesure (concepts qui ne sont pas encercls sur la Fig. 4.4)
49
a pour objectif
< repose sur
0..*
Ajustement
Dcision
+ID: Integer
+description: String Situation prvue
drive
+date: Date Situation 1..*
+ID: Integer 0..* < valuer

Situation gnre Mtrique
opportunits +description: String
0..* +ID: Integer
< gnre 0..* +description: String
+dim: Object
1..* +valeur: String
< value *
Action Portefeuille
+ID: Integer +ID: Integer 0..* 0..* 0..*
*
1 1 caractristique Indicateur
< value < value
< value
0..* +nom: String +intitul: String
+forme: Object
< impacte
+valeur: Integer
1..*
0..* 0..1 dcoup par > +valeurMIN: Integer
0..* +valeurMAX: Integer
1..* 0..*
1..* 0..1 0..* +date: Date
<impacte Projet 1..* Risque Processus Ressource
1 1..* But a
Catgorie +nom: String 1..*
0..1 +ID: Integer +ID: Integer +ID: Integer
+ID: Integer +date: Date 1
+Nom: String +Nom: String +Nom: String
affin par > +description: String +description: String
0..* +date: Date * * +axeRessource
1..* 1..*
Question CGQ 1..*
+axeProcessus
+nonc: String
Tableau de bord
+axeRisque
+ID: Integer
Domaine GSI
+axeBut +nom: String
1..*
+nom: String 0..* +date: Date
1..*
0..*
Mot
+intitul: String
Critre 0..* +dfinition: String
+nom: String 0..*
Figure 4.4. Les concepts de REFGOUV
50
La figure 4.4 montre une reprsentation des concepts gnriques que nous proposons
dexploiter dans le cadre de la GSI. Ils sont prsents en dtail dans les sous-sections suivantes.
4.3.1. La notion de but et concepts associs
Question CGQ
affin par >
0..* +nonc: String
But
+ID: Integer
+description: String Catgorie
+date: Date 1..* 1
Domaine GSI
1..* +nom: String
0..*
0..*
Mot
+intitul: String 0..* Critre
+dfinition: String 0..*
+nom: String
Figure 4.5. Diagramme de classes des concepts de REFGOUV lis la notion de but
Les buts considrs dans notre tude sont ceux en rapport avec la GSI. Il sagit donc des buts
issus des objectifs oprationnels assigns au SI, ses projets, mais aussi ses objectifs stratgiques pour
la GSI.
4.3.1.1. Des buts et des mots

La tlologie est la science de ltude des buts et plus particulirement de leur reprsentation
(logos) la distinction de la tlonomie qui est la science qui traite de lexpression de la finalit
(nomos). La tlologie et la tlonomie sont des disciplines qui sintressent aux buts atteindre. La
finalit (nomos) peut tre reprsente (comme les intentions exprimes) ou abstraite partir de
l'observation et de la mesure des comportements. Nous basons ainsi notre approche des buts de la GSI
sur deux aspects :
lexpression des buts de la GSI ; cela justifie lexistence des concepts de but et de mot
la typologie des buts de gouvernance ; cela justifie le concept de catgorie.
Ces dernires annes, le domaine de recherche de lingnierie dirige par les modles (IDM)
pour la spcification des systmes dinformation a fourni des modles intgrant la notion dobjectif.
Cette intgration permet de formaliser les besoins des utilisateurs pour un domaine prcis. Les
mthodes de GORE (Goal-Oriented Requirement Engineering) (van Lamsweerde, 2001) prconisent
ainsi lusage des buts pour dcouvrir, laborer, spcifier, analyser et modifier les exigences. Dans cette
perspective, les buts sont organiss dans une hirarchie. Nous identifions ici la ncessit de reprsenter
le concept de but et de mentionner une association rcursive affine par (Fig. 4.5).
51
Dans (Rolland, 1998), nous trouvons un apport essentiel aux mthodes de GORE : les buts se
rapportent aux scenarii dvolution dun SI et sont exprims par lintermdiaire dune structure de
mots (un verbe linfinitif associ un complment). Cela nous guide vers la reprsentation du
concept de mot et la relation dagrgat entre un but et un ensemble de mots (Fig. 4.5).
4.3.1.2. Catgories de buts

Le concept de catgorie repose sur la ncessit clairement identifie dans les mthodes de
GORE de typer les buts et den crer une taxinomie. Ainsi les mthodes GORE distinguent les buts
fonctionnels des buts non-fonctionnels, autrement dit, les soft-goals des hard-goals.
Nous proposons ainsi dorganiser les buts de REFGOUV au sein dune taxinomie de domaine
propre la GSI. Une catgorie est un tiroir dans lequel peuvent se retrouver plusieurs buts
exprims de manire textuelle. Deux lments forment la catgorie : le domaine de gouvernance trait
par le but et le critre de gouvernance associ. Nous fournissons ainsi une structure conceptuelle
ddie la gestion des buts.
Nous pouvons identifier dans la littrature, des exemples de domaine pour la GSI. Nous en
retenons ici quatre qui nous intressent plus particulirement dans le cadre de nos travaux:
Lalignement : (Henderson & Venkatraman, 1993) regroupe lensemble des buts

imposant aux projets de SI ou aux SI eux-mmes dtre mis en cohrence avec les
besoins des utilisateurs du SI et de ses parties prenantes. Exemple : Construire les
projets en cohrence avec les exigences stratgiques de lorganisation .
Le risque : (Georgel, 2009) regroupe lensemble des buts rgissant la prise en compte
et le traitement des risques propritaires et rglementaires pour le SI. Exemple :
Assurer lauthentification des membres du personnel sur les serveurs par login et
mot de passe .
La ressource : (Kyobe, 2004) regroupe lensemble des buts lis la manipulation et
la gestion dune ressource, quelle soit humaine, technique ou financire. Exemple :
Publier un appel doffre pour un projet dinfogrance .
Le contrle : (Sandhu, 1996) regroupe lensemble des buts daudit du SI en usage.
Exemple : Auditer les ples budgtaires .
Les critres sont des axes danalyse pour le domaine de la GSI :
La valeur : (Denis, 2009) regroupe lensemble des buts dont lexpression connote un
objectif datteinte de valeur conomique ou dusage pour le SI. Exemple : Maintenir
le taux dutilit du budget 80% .
52
La performance : (Ravichandran, 2005) regroupe lensemble des buts dont
lexpression connote un objectif datteinte de performance conomique, technique ou
dusage pour le SI. Exemple : Maintenir le taux dutilit du parc applicatif 80% .
La maturit : (Ravichandran, 2005) regroupe lensemble des buts dont lexpression
connote un objectif de transformation et de mtamorphose des plans organisationnels
pour le SI. Exemple : Crer et maintenir les procdures de rinitialisation des
serveurs .
Nous donnons ici un exemple dinstanciation des concepts introduits autour de la notion de but
avec quatre domaines de GSI et trois critres. Cest ainsi douze catgories de but qui peuvent tre
dfinies. Un but est toujours li une catgorie particulire et on peut sinterroger sur la dmarche
didentification de ce lien. (Basili, 1994) propose une dmarche par questionnement (Goal-Question-
Metric) permettant didentifier des mtriques partir dun but. Nous adoptons une dmarche similaire
pour identifier des buts partir des catgories (et rciproquement). Nous identifions ici le concept
associatif Question CGQ (category-goal-question) (Fig. 4.5).
4.3.1.3. Exemples de buts pour la GSI

COBIT est le cadre de rfrence en matire de gouvernance des SI qui est le plus utilis dans
les organisations. Ce cadre propose datteindre 28 objectifs cls de la GSI en mettant en uvre un
ensemble de processus prdfinis. Nous illustrons notre cadre de taxinomie des buts de GSI en mettant
en correspondance les buts noncs dans COBIT et notre typologie de buts.
Identifiant BUT TI (COBIT) Domaine Critre

1 Rpondre aux exigences mtier en alignement avec la Alignement Valeur
stratgie mtier
2 Rpondre aux exigences de gouvernance en alignement avec Alignement Valeur
le comit de direction
3 Assurer la satisfaction des utilisateurs en proposant des Alignement Valeur
services
4 Optimiser lusage de linformation Ressource Maturit
5 Crer lagilit des TIC Ressource Maturit
6 Dfinir comment les fonctionnalits mtier et les exigences Alignement Maturit
de contrle sont traduites en une solution efficiente et
automatise
7 Acqurir et maintenir les applications intgres et Ressource Maturit
standardises
8 Acqurir et maintenir une infrastructure des TIC intgre et Ressource Maturit
standardise
9 Acqurir et maintenir les comptences en TIC qui Alignement Maturit
correspondent la stratgie TIC Ressource
10 Assurer la satisfaction des parties prenantes Alignement Valeur
11 Intgrer les applications et les solutions technologiques aux Alignement Performance
processus mtier
12 Assurer la transparence et la validation des cots, des Risque Performance
bnfices, de la stratgie, des rglements et des services pour Ressource ( ?)
les TIC
13 Assurer lusage adquat et la performance des applications et Risque Performance
des solutions technologiques
53
Identifiant BUT TI (COBIT) Domaine Critre
14 Recenser et protger les actifs des TIC Risque Performance
Ressource Maturit
15 Optimiser linfrastructure des TIC, les ressources et la Ressource Maturit
capacit
16 Rduire la production de solutions et de services dfectueux Risque Performance
17 Protger laccomplissement des objectifs en TIC Risque Maturit
18 Etablir clairement limpact des risques mtier sur les objectifs Risque Maturit
TIC et les ressources
19 Assurer que les informations critiques et confidentielles sont Risque Maturit
protges des accs des personnes non autorises Contrle
20 Assurer la fiabilit de lexcution des transactions mtier et Risque Maturit
des changes dinformation Contrle
21 Assurer que les services TIC et linfrastructure peuvent Risque Maturit
rsister aux dfaillances dues des erreurs, attaques Contrle
dlibres et aux catastrophes
22 Assurer un impact minimal sur les processus mtier dans Risque Maturit
lventualit dun changement ou dune dfaillance des Contrle
services TIC
23 Assurer que les services TIC sont disponibles en rponse aux Alignement Valeur
exigences Risque
24 Amliorer lefficience des investissements TIC et leurs Alignement Performance
contributions aux profits de lorganisation
25 Livrer les projets dans les dlais et les budgets tels que Ressources Performance
spcifier par les normes qualit
26 Maintenir lintgrit des informations et la mise en uvre de Ressource Maturit
linfrastructure
27 Assurer la conformit des TIC aux rglements et la Contrle Performance
lgislation
28 Assurer que les TIC constatent une efficience des cots de la Contrle Maturit
qualit de service, des amliorations continues et de la
permissivit au changement
4.3.1.4. Reprsentation des buts de la GSI.

Un systme tlocentrique doit permettre non seulement dintgrer des buts typs, mais aussi
danticiper la rsonance entre les lments finis. En dautres termes, on peut considrer deux buts
comme disjoints sans rsonance, avec une rsonance hirarchique (inclusion/exclusion) ou avec une
rsonance corollaire (impact).
Ainsi les langages de modlisation de buts comme KAOS (Lamsweerde, 2001) permettent de
structurer une hirarchie de buts en utilisant la logique du premier ordre et les nuds logiques
AND/OR/XOR entre les buts identifis. KAOS permet de reprsenter la rsonance hirarchique entre
les buts. Un exemple connu est celui de la gestion des contrles ariens. Ainsi, la figure 4.3., on
constate que laccomplissement du but de plus haut niveau secteur arien contrlable exige
laccomplissement des quatre sous-buts ; cette exigence est reprsente par loprateur logique ET .
54
Secteur arien contrlable
ET
logique
Contrleurs assigns aux

Plans de vol connus
secteurs ariens
Positions des avions Moyens de communication

connues fonctionnels
Communication pilotes- Communication possible entre les

contrleurs possible contrleurs des secteurs adjacents
Communication possible entre les

contrleurs du mme secteur
Figure 4.6. Exemple de modlisation des buts avec KAOS
On peut galement citer le formalisme i* (Yu, 1995) qui permet de reprsenter laffectation
des objectifs aux acteurs. Ce formalisme permet galement de reprsenter une composition de buts et
de les typer comme des buts fonctionnels ou non fonctionnels. I* permet ainsi de reprsenter la
rsonnance hirarchique et la rsonnance corollaire par lintermdiaire des acteurs.
La CARTE (Rolland, 2001) est une autre manire de modliser les buts en ayant recours aux
notions dintention et de stratgie. La stratgie est la manire par laquelle une intention cible est
accomplie en partant dune intention source : ce triplet (intention source, intention cible et stratgie)
est appel section. La section est donc un moyen de reprsenter une rsonance corollaire entre deux
intentions via la stratgie. Une section peut tre affine par une autre CARTE, de telle sorte quelle
devient une reprsentation de niveau dabstraction suprieur dune CARTE obtenue par affinement. La
carte dtaille inclut son tour des intentions, des stratgies et des chemins de navigation pour dfinir
les multiples manires daccomplir lintention cible de la section qui est objet de lattention dans la
carte suprieure. Les recherches antrieures ont permis dexprimenter la CARTE dans des domaines
varis : lingnierie des SI (Gam, 2008), lingnierie des mthodes (Ralyt, 2005), lingnierie des
processus (Nurcan, 2004). Il a t galement tendu avec la notion de rle dans (Nurcan, 2004),
(Nurcan, 2005). Ainsi la CARTE est un formalisme complet permettant la reprsentation de la
rsonance hirarchique et de la rsonance corollaire sur les intentions. La CARTE nous a aussi permis
de reprsenter les buts de la GSI (Claudepierre, 2009a).
55
4.3.2. La notion de projet et concepts associs
caractristique
+nom: String 1..*
1
a Projet Portefeuille
But
+nom: String 0..* +ID: Integer
+ID: Integer +date: Date
+description: String * *
+date: Date
1..*
1..*
Ressource Risque Processus
+ID: Integer +ID: Integer +ID: Integer
+Nom: String +Nom: String +Nom: String
Figure 4.7. Composant projet de REFGOUV
Le concept de portefeuille est un lment permettant dorganiser, dordonnancer et de

visualiser un ensemble de projets. On peut dire que la nature intentionnelle et dcisionnelle du
processus de GSI est en partie supporte dans REFGOUV (c.f. figure 4.4) par les caractristiques et par
la situation de mise en uvre du projet qui sont mesurables par des mtriques. Ces dernires
sappliquent aux processus, aux risques et aux ressources du projet, et aux buts de GSI associs. Leur
agrgation conduit la dfinition des indicateurs qui composent les tableaux de bord du portefeuille
de projets. Le principal propos de ces tableaux de bord, travers les indicateurs quils comportent, est
dapporter des arguments aux dcisions dajustement sur la conduite dun projet et/ou sur
limplmentation dun portefeuille de projets, dans toutes les situations o les mesures effectues
permettent de constater des carts par rapport aux rsultats attendus.
Plus prcisment, un projet se dfinit comme un engagement irrversible de rsultat

incertain, non reproductible a priori lidentique, ncessitant le concours et lintgration dune grande
diversit de contributions, et rpondant un besoin exprim (Wikipedia, 2010). En dautres termes,
un projet peut se dfinir comme un processus finalit mesurable non reproductible, voluant dans un
environnement risque et ncessitant un ensemble de ressources techniques et humaines organises
pour rpondre un but prdfini, celui (ou ceux) assigns au projet.
La notion de projet impose donc de prvoir les tapes de construction du rsultat attendu du
projet, et dorganiser les activits dans ce but. Un projet a ainsi un cycle de vie qui est rgi par un
modle de processus qui ordonnance ses activits. Nous intgrons la notion de cycle de vie et
dactivits organises par lintermdiaire du concept de processus (Fig. 4.7) dont le type variera en
fonction de celui du cycle de vie du projet.
56
Un projet organise un ensemble de ressources qui sont humaines (rles, acteurs internes ou
externes), conomiques (budget ; contraintes, rglementations et priorits sur les dpenses) ou
techniques (serveurs de base de donnes, applications, services ). Pour (Reix, 2005), un projet SI est
un processus de construction dun SI dont la conduite est assure par une gestion des ressources
(logicielles et humaines) et des risques. Nous identifions ainsi la ncessit de reprsenter le concept de
projet comme lagrgation de trois autres concepts : processus, ressource et risque. Les concepts lis
la notion de projet sont prsents sur le mta-modle REFGOUV (Fig. 4.4).
Les concepts de processus, de risque et de ressource ne sont pas atomiques et nous proposons
daffiner dans les sections suivantes la description du mta-modle REFGOUV les concernant (Fig.
4.4).
4.3.2.1. Le constituant processus dun projet

Dans cette section, nous affinons le concept de processus.
Un processus est un ensemble dactivits organises afin datteindre des buts fixs. Ces
activits sont planifies dans le temps et ncessitent des ressources. Plusieurs dmarches (ou modles
de processus) existent dans la littrature pour lingnierie des systmes dinformation. On peut,
nanmoins, distinguer deux types de dynamique :
La dynamique squentielle, qui prescrit un enchainement dtapes excutes en un

coup ayant pour vocation de rpondre aux besoins dfinis pour le projet. Les phases
successives de conception, de dveloppement, de test et dintgration sont alors mises
en uvre. Les dmarches de projet dit en cascade , en V , en W sont des
exemples de processus de dveloppement de SI dynamique squentielle.
La dynamique itrative reprend la squence prcdente en y ajoutant dune part un
incrment port sur la satisfaction qualitative du rsultat du projet, dautre part, en
intgrant lide que le rsultat ne sera pas obtenu en un coup . Les dveloppements
sont complts au fil des itrations, et ce, en produisant chaque tape un rsultat
(sous-systme) mis en production. Tant que le rsultat du projet nest pas satisfaisant,
de par sa compltude, son dveloppement continue. Cest le cas des dmarches de
projet en spirale , par prototypage ou encore RAD .
Dans tous les cas, la dmarche dun projet peut tre formalise par un modle de processus qui
rpartit les activits du projet entre les acteurs concerns.
BPMN (Business Process Modeling Notation) est un langage de modlisation de processus

mtier permettant (i) la visualisation des affectations des activits aux rles, (ii) lusage des
57
composants applicatifs et (iii) le traage des vnements derreur qui peuvent survenir pendant
lexcution du processus. Le mta-modle de BPMN est reprsent avec la notation UML la Figure
4.8. Lingnierie et la gouvernance de SI sont des mtiers de lentreprise (cest mme lunique
mtier des SSII) et les processus sous-jacents peuvent parfaitement tre dcrits pas la notation BPMN.
Processus
1..* 3..* 2..* 0..*

Objet organisationnel Objet de flux Objet de transition Objet informationnel
1 3..* 2 0..*
Role Squence Donne

Evnement Oprateur Activit
Pool
Message Groupe
Dbut XOR Composite

Association Annotation
Fin OR Atomique
Intermdiaire AND
Figure 4.8. Mta-modle BPMN comme descripteur du concept de processus
(zur Muehlen, 2008) propose de formaliser les activits dun projet de ringnierie de
processus mtier en utilisant la notation BPMN (Fig. 4.8). Nous justifions ici notre choix de la
description du concept de processus par le mta-modle BPMN. Ces travaux reprsentent ainsi un
processus de projet en cascade comprenant quatre tapes: la prparation du projet, la modlisation de
ltat actuel du processus mtier (modle as-is), la modlisation souhaite pour le futur processus
mtier (modle to-be) et la simulation des processus futurs.
Dans la section suivante nous dcrivons en dtail le concept de ressource du mta-modle

REFGOUV.
58
4.3.2.2. Le constituant ressource dun projet
Manipule 1..*
Connaissance
1..*
1..*
Repose sur
Personnel TI
Role TI 0..* Authorisation 1..*
+Budget: int 1..* Information
+Cout: int 0..*
1..*
+Benefice: int 1..* 1..*
+Utilise Maintenu par
0..* 0..*
1..*
Composant applicatif
+Budget: int 1..* Entre
+Cout: int 1..*
1..* +Benefice: int Sortie
1..*
Supporte
1..*
Composant tech.
+Budget: int
+Cout: int
+Benefice: int
Figure 4.9. Meta-modle de ressource pour le SI
Un projet SI est aussi caractris par les ressources spcifiques quil emploie. On entend ici
par ressource les acteurs, les informations, les composants logiciels, les composants techniques et les
moyens financiers ncessaires au projet SI. (Georgel, 2009) qualifie le domaine du management des
ressources TI de complexe. En effet, la disponibilit au mme instant de chacune des ressources
prcdentes peut tre ncessaire au bon accomplissement dune activit dun projet. Par exemple, une
activit de dveloppement dune application WEB ncessitera le recrutement dun dveloppeur WEB,
la mise disposition dun poste de travail quip des logiciels de dveloppement, et une connexion au
serveur de sauvegarde des codes sources.
La description du concept de ressource fait ainsi lobjet dune modlisation plus prcise que
nous proposons (Fig. 4.9). Elle complte notre mta-modle REFGOUV (Fig. 4.4).
Ressources humaines
Les ressources humaines sont constitues de lensemble des intervenants internes ou externes
sur les projets. Une ressource humaine est un acteur qui uvre sur les projets avec un rle dtermin
(dveloppeur, analyse, commercial). Suivant ses prrogatives, il a des droits daccs aux autres
ressources du SI par lintermdiaire des applications (ex : ERP, WebMail, Intranet).
Ces ressources sont reprsentes par les classes Personnel TI, Role TI et Autorisation sur la
figure 4.9.
59
Ressources informationnelles
Les ressources informationnelles correspondent toutes les informations manipules dans un

projet. La ressource informationnelle peut tre formelle, elle est alors structure ou rendue accessible
par le systme dinformation (Intranet, GED, BDD, fichiers, site Internet). Elle peut aussi tre
informelle, cest le cas des changes dides entre personnes, la participation une confrence ou
encore lhritage culturel dune personne. Notre mta-modle considre uniquement les ressources
informationnelles formelles engranges dans des composants applicatifs du SI.
Nous distinguons linformation, confirme par la connaissance, qui est issue de lanalyse dans
le temps, dun ensemble dinformations. Par exemple, Jean est absent le 13 janvier est une
information alors que le taux dabsentisme sera une connaissance, une analyse des faits dabsence
agrgs sur une dure.
Nous reprsentons ces concepts par les classes connaissance et information la figure 4.9. La
classe information est lie par les associations entre et sortie au concept de composant applicatif.
Ressources techniques
Les ressources techniques manipules dans le cadre dun projet sont constitues des
composants de linfrastructure logicielle (SGBD, CMS, IDE) et des composants de linfrastructure
matrielle comme les serveurs, les postes de travail. Selon la littrature (Georgel, 2009), un Software
Infrastructure Component (SIC) est un lment applicatif de linfrastructure du SI et un Hardware
Infrastructure Component (HIC) est un lment technique de support aux composants applicatifs.
Nous reprsentons ces concepts par les classes composant applicatif et composant technique
la figure 4.9. Les deux concepts sont lis par lassociation supporte.
Ressources financires
Les ressources financires sont considres comme des caractristiques de valeur des autres
types de ressources. Ainsi la reprsentation dune ressource financire se fait par lajout dun attribut
aux classes du mta-modle. Les ressources financires concernent les composants applicatifs, les
composants technologiques ainsi que les acteurs. Nous mentionnons les attributs correspondants dans
les classes du mta-modle sur la figure 4.9. Les trois types de ressources financires sont :
Le budget : ensemble des ressources montaires disponibles pour les payes, les
dveloppements et les maintenances des composants du SI
Les cots : ensemble des ressources montaires effectivement consommes.
Les revenus : ensemble des produits financiers gnrs par les acteurs ou par les
composants applicatifs.
60
Dans la section suivante nous dcrirons plus en dtail le concept de risque tel quil est
mentionn dans le mta-modle REFGOUV (Fig. 4.4).
4.3.2.3. Le constituant risque dun projet
Humain
Observe
Physique Systme
ImpactRisque
Technique 0..* utilise
1..*
Elment 0..* +impactant Risque
+Impact Subit 0..* 0..*

Organisation 0..* 1..*
Sensible
gnre
Rglementaire 0..* 0..*

0..* 1..*
+descripteur 0..*
Evnement Situation
1..* 1..* +contexte
0..*
Figure 4.10. mta-modle des risques
Le risque est, selon la dfinition propose par Wikipedia, la possibilit de survenance d'un
dommage rsultant d'une exposition un phnomne dangereux. Le risque est la combinaison de la
probabilit doccurrence dun vnement redout (incident ou accident) et la gravit de ses
consquences sur une cible donne . Dans un contexte dorganisation, notamment de GSI, le risque
est l'ventualit de ne pas atteindre les objectifs fixs. Suivant l'importance accorde ces objectifs,
lorganisation peut ragir diffremment au moment de la survenance de lvnement redout ou
ventuellement par anticipation.
La norme ISO 27001 propose un cadre de structuration des risques et les mcanismes de
traitement : (i) transfrer est l'activit qui vise dporter le risque vers un autre acteur (exemple :
la sous-traitance) ; (ii) accepter le risque est une attitude o on accepte l'ventualit de ne pas
satisfaire les objectifs fixs, il s'agit alors de mettre en uvre des activits limitant les impacts ngatifs
sur les objectifs. (iii) Refuser le risque est le mcanisme le plus contraignant puisqu'il va
contraindre les acteurs accepter de ne pas raliser les objectifs fixs.
Nous formalisons le risque par lintermdiaire du mta-modle prsent la figure 4.10. Le

risque est la possibilit de survenance de dommages sur les lments dun systme en usage. Les
lments dun systme peuvent tre humains (acteurs), physiques (temprature, pression,
hydromtrie), techniques (armoire lectrique, serveur), dorganisation (processus, projet) ou
rglementaires (texte de loi, rgle interne). Les lments du systme gnrent et/ou subissent un
61
ensemble dvnements. Un agrgat spcifique dvnements constitue une signature pour une
situation sensible risque. Limpact est alors la consquence dun risque sur les lments du systme.
Prenons lexemple de lvnement suivant : labsence de M. Dupont le 15 septembre 2010. M.

Dupont est dveloppeur et participe un projet de mise en place des fonctionnalits dun ERP pour le
compte de son entreprise. Le planning mentionne que M. Dupont doit effectuer la recette des modules
quil a dvelopps et doit livrer le prototype de ces modules en fin de journe. On constate ici, que
labsence de M. Dupont (acteur humain) est un vnement qui est la signature dune situation risque
pour le projet de mise en place de lERP. Limpact de ce risque est le retard sur les activits de recette
des modules dvelopps par M. Dupont. Dans notre exemple un lment Humain gnre un vnement
qui est reprsentatif dune situation risque qui a un impact sur un lment dOrganisation (le projet
de mise en place dun ERP).
Nous venons de terminer la formalisation des concepts de REFGOUV (Fig. 4.4) ddis au
projet et nous avons ainsi affin la description des concepts de processus, de ressource et de risque.
La section suivante est ddie la prsentation des concepts de mtrique et dindicateur.
4.3.3. La notion de mesure et concepts associs

Les concepts lis la notion de mtrique sont prsents sur le mta-modle REFGOUV (Figure
4.4). Dans la section 4.3.3.1 nous rappelons la notion de mtrique et ses fondements historiques. La
section 4.3.3.2 dfinit les concepts de mtrique et dindicateur pour les SI et prsente une typologie
des mtriques pour la GSI. La typologie repose sur les liens dassociation value prsents sur le mta-
modle REFGOUV (Fig. 4.11) entre le concept de mtrique et les concepts processus, ressource, risque
et but faisant partie des notions fondamentales (domaines) qui structurent les concepts du mta-
modle de rfrence (figure 4.4), respectivement projet et but. La section 4.3.3.3 prsente le tableau de
bord de la GSI comme un support danalyse des indicateurs suivant quatre axes : laxe des ressources,
laxe des risques, laxe des processus et laxe des buts (voir Fig. 4.11).
62
drive
Mtrique
Situation caractrisitique
* * Projet
0..* 0..* +ID: Integer 1..* 1
+ID: Integer +nom: String
+description: String +nom: String
+description: String < value
< valuer +dim: Object a +date: Date
+valeur: String +description: String
0..*
0..* 1..*
0..*
< value < value
< value
0..*
0..* 0..*
Indicateur Risque Processus But

Ressource
+intitul: String +ID: Integer +ID: Integer +ID: Integer
+ID: Integer +description: String
+forme: Object +Nom: String +Nom: String +Nom: String
+valeur: Integer +date: Date
+valeurMIN: Integer +axeRisque
+valeurMAX: Integer
+date: Date +axeProcessus
1..*
0..* +axeRessource Tableau de bord
+axeBut
+ID: Integer
+nom: String
1..*
+date: Date
Dcision
+ID: Integer
+date: Date
Figure 4.11. Les concepts de mtrique dans REFGOUV
Les concepts lis la mesure sont centraux dans REFGOUV. Ils sont en blancs sur la figure
4.11 (mtrique, indicateur et tableau de bord) et relis aux concepts des domaines annexes. Ces
derniers apparaissent griss sur le diagramme de classe.
4.3.3.1. De la mesure la mtrique : 200 ans dhistoire

Une dformation abusive a abouti remplacer le terme mesure par mtrique ,
notamment en informatique et dans les systmes dinformation. Tant et si bien quun flou subsiste sur
la dfinition accorder la notion de mtrique. Originellement, la notion de mtrique est apparue avec
la cration du systme mtrique universel lors de la Rvolution Franaise, le 7 avril 1795. Le systme
est dit mtrique car il drive un ensemble dunits de mesure en se basant sur ltalon de rfrence, le
mtre. Le mtre, le kilogramme et la seconde sont ainsi crs comme units de mesure. Gauss utilise
ce systme en 1832 pour mesurer le champ magntique terrestre. Aujourdhui, aprs plusieurs
volutions, le systme mtrique est connu sous le nom de systme international dunits de mesure. Il
dfinit les units de mesure de base : le mtre, le kilogramme, la seconde, lampre, le kelvin, la
candela et la mole.
Certaines mesures pour les SI se rapportent au systme mtrique (temps de rponse dun
service en seconde), cependant dautres mesures comme celle de lespace logique (octet) nont aucun
rapport avec le systme mtrique tel que dfini prcdemment. Il convient dune part de dfinir la
63
notion de mtrique en rapport avec les SI mais aussi de distinguer la mesure des phnomnes
physiques de la mesure des phnomnes mathmatiques.
La mesure physique est l'estimation ou la dtermination d'une dimension spcifique (longueur,

capacit, etc.), habituellement en relation avec un talon (standard en anglais). Le rsultat de la mesure
physique s'exprime en termes de multiples de l'talon (un nombre rel multipliant l'unit). On pourra
citer comme exemple la mesure de distances (kilomtres, miles, lieues) ou la mesure du temps
(secondes, heures). Le tableau 4.1 propose des exemples de mesures physiques et de leurs dimensions.
Objectif de mesure Unit de mesure Symbole Moyen de mesure

Distance mtre m dcimtre
Temps seconde s chronomtre
Vitesse Mtre par seconde m.s-1 vlocimtre
Acclration Mtre par seconde m.s-2 acclromtre
carr
Frquence Hertz Hz Frquencemtre
Puissance Watt W Wattmtre
Tableau 4.1. Exemples de mesures
Il convient dadjoindre la mesure physique la notion de mesure mathmatique. Cette dernire

permet, par ailleurs, de dnombrer un ensemble : par exemple le nombre de serveurs dune entreprise.
En mathmatiques, une mesure est une fonction qui associe une longueur , un volume ou encore
une probabilit certaines parties d'un ensemble donn. Il s'agit d'un important concept en analyse
et en thorie des probabilits. Formellement, une mesure est une fonction qui associe chaque
lment S d'une -algbre donne X une valeur (S), qui est un rel positif ou l'infini. Les proprits
suivantes doivent tre vrifies :
L'ensemble vide a une mesure nulle : ()= 0
La mesure est -additive : Soit , n tant fini et les sous-

ensembles Ei de X disjoints deux deux alors la mesure (E) est dfinie par :
La mesure se caractrise ainsi par un type physique ou mathmatique et permet dalimenter les
indicateurs dcisionnels. La section suivante dfinit plus prcisment la notion de mtrique pour les
systmes dinformation.
64
4.3.3.2. Mtriques et indicateurs pour les systmes dinformation
Ces vingt dernires annes, la ncessit de prendre des dcisions sur les projets informatiques
a justifi la mise en place de systmes de mtriques. Ces derniers recensent un ensemble de mtriques
pertinentes pour la prise de dcision dans le cadre des projets de SI. Ces cadres sont souvent
dvelopps dans lindustrie. Cest le cas des treize indicateurs proposs par le Lean Aerospace
Initiative en 2007 (Roedler, 2007). Par ailleurs (Vanek, 2008) propose une analyse de la littrature des
systmes de mtriques et conclut la pertinence de leurs usages dans le cadre des projets dingnierie
de systmes. Dans la suite, nous proposons une dfinition de la notion de mtrique pour les SI et une
typologie des mtriques qui tend la classification des mtriques de Fenton (Fenton, 1997) afin de
proposer un systme de mtriques pour la GSI. Les mtriques pour la gestion des projets SI constituent
galement un apport intressant. Dans ce domaine, nous nous rfrons aux travaux de Ion Ivan (Ivan,
2007) qui propose de mesurer les caractristiques dun projet par des indicateurs sur la complexit, la
consistance, la clart et la prcision. Dans les sections suivantes nous compltons ces apports par des
mesures sur les lments constitutifs dun projet (mtriques de processus, de ressource, de risque et de
but).
4.3.3.2.1. Dfinitions
Mtriques pour les SI. Il sagit dun systme dunits de mesure de rfrence pour lvaluation des
lments constitutifs du SI (projets, applications, processus). Il inclut les units de mesure physiques
et mathmatiques.
Indicateurs pour les SI. Il sagit dun systme de reprsentation formelle dun agrgat de mesures. Il
inclut outre laspect de reprsentation, une chelle de valeur.
4.3.3.2.2. Mtriques pour les processus

Les mtriques de processus se rfrent gnralement la performance, autrement dit, la
capacit dun processus atteindre les objectifs qui lui sont assigns. La littrature propose les KPI
(Key Performance Indicators) (AFAI, 2002). Une organisation repose sur une multitude de processus :
processus mtier, de support, de pilotage stratgique autant de processus que dobjectifs et de KPI
associs. Ainsi la mesure de la performance correspond une analyse multicritres de ltat pass et
actuel des processus de lorganisation.
Kaplan et Norton (Kaplan & Norton, 2003) prsentent un modle multicritres de mesure de la
performance, le tableau de bord prospectif, qui prend en compte plusieurs critres organiss sur quatre
axes danalyse ou perspectives :
La perspective financire : les indicateurs financiers, les mesures axes sur la

rentabilit. Par exemple, le retour sur investissement (ROI) permet d'valuer la
performance des actions engages par le pass.
65
La perspective client : les indicateurs de cet axe sont gnralement utiliss pour
valuer la satisfaction et la fidlit des clients, la mesure de laugmentation de la
clientle et l'augmentation de la rentabilit par client.
La perspective des processus internes : cette catgorie comprend tous les processus en
troite collaboration dont lobjectif est de collectivement contribuer la cration de
valeur. Le processus dinnovation est aussi concern.
La perspective d'apprentissage : cet axe est utilis pour mesurer la formation des
personnels pour l'accs de nouvelles comptences, l'amlioration du systme
d'information et de l'adquation entre les procdures et leurs applications, et dune
manire globale, lapprentissage organisationnel.
Ainsi la rflexion sur les mtriques de processus doit soprer dans une vision intgre o les
processus IT contribuent la performance des processus mtier. Cela rejoint la proposition de (Van
Grembergen, 2000) pour la cration dun ensemble structur de tableaux de bord pour la gouvernance
Mtier/SI visant lobjectif de mettre en uvre lalignement stratgique. Les mtriques de processus
dans une structure de tableau de bord prospectif correspondent aux mesures de lefficacit
oprationnelle. Le tableau 4.2 affiche une liste de mtriques de la performance des processus SI et des
processus mtier.
Perspective Tableau de bord SI Tableau de bord Mtier

Processus Performance des dveloppements : Innovation :
interne - % des projets hors cot, dlais et - % de vente des nouveaux
qualit produits/services
Maturit des dveloppements Activits :
- Niveau de maturit (CMMi) - Niveau de qualit produit/service
Disponibilit : - % des livraisons retournes
- % des composants techniques - Dlai moyen de livraison
disponibles - Dlai moyen de traitement dune
- % des composants logiciels commande
disponibles - SLA
Tableau 4.2. Exemple de mtriques de processus suivant les Tableaux de bord SI et Mtier.
4.3.3.2.3. Mtriques pour les ressources

Les mtriques de ressource sont ddies la mesure des ressources engages dans un projet.
Les ressources mesures sont les personnels, quipes, logiciels, matriels utiliss ou encore
linformation. Les mtriques sont souvent lies au cot (salaire dun employ) ou au gain fiduciaire
dune ressource (vente dinformation). Ainsi la comptabilit analytique apporte des mtriques comme
le chiffre daffaires, les cots directs et indirects, la marge nette, le point mort, le retour sur
investissement ou lamortissement. Le recours ces mtriques est dsormais courant. Cependant les
facteurs danalyse autre que les cots et les bnfices nous semblent indispensables pour mener bien
les activits de GSI en disposant dune vision 360 de lentreprise et en toute transparence.
66
Il sagit de piloter des ressources, les acqurir, les maintenir et les dissoudre pour rpondre de
manire performante aux besoins de support informatique pour une organisation. Ainsi les facteurs
essentiels pour la GSI sont : lutilit des composants du SI (leur degr dusage), la fiabilit et la
disponibilit des ressources. Les personnels et les informations sont des ressources particulires. Les
personnels sont affects des rles suivant leur capacit analyser les problmes (degr dexpertise)
et assurer les responsabilits qui leur incombent. La valeur de linformation est alors mesure/juge
suivant le service quelle rend aux activits mtier (efficacit, confidentialit et disponibilit) et aux
activits de pilotage (intgrit et fiabilit). Un facteur apparu ces dernires annes est la licit qui est
lie lexigence de conformit et qui exige que linformation vhicule par un SI respecte des
contraintes rglementaires. Par exemple en France, le recrutement bas sur des critres
discriminatoires tels que les pratiques religieuses, la race ou lorientation sexuelle dune personne est
scrupuleusement interdit. Le SI de support aux activits du service RH doit par consquent contenir
des informations sur les textes de loi qui dfinissent ce cadre.
Le tableau 4.3 prsente une liste de mtriques. Les facteurs qualitatifs identifis sont adapts
de ceux prsents par Mc Call. La mthode didentification des mtriques repose ici sur la mthode
GQM (voir section 2.2.2.2.3.)(Goal Question Mtrique) (Basili, 1996).
Ressource Facteur Mtrique

Personnel Financier Salaire
Degr dexpertise Niveau de diplme
Annes dexprience
Nombre de projets
Degr de responsabilit Nombre dannes par rle
Degr de fiabilit Jours de prsence
Jours dabsence justifis
Jours dabsence injustifis
Composant applicatif Financier Cot de dveloppement
Cot de maintenance
Degr dusage Frquence dutilisation
Degr de fiabilit Dure entre dfaillances
conscutives
Dure de bon fonctionnement
Degr de maintenabilit Dure de maintenance
Nombre de bugs
Degr de disponibilit Dure de disponibilit
Dure dindisponibilit
Degr de consommation Charge de calcul (Hz)
Charge de mmoire (Octet)
Charge de stockage (Octet)
Degr de scurit Nombre daccs autoriss
Nombre daccs non autoriss
Nombre de virus traits
Composant Technique Financier Cot de dveloppement
Cot de maintenance
Degr dusage Frquence dutilisation
Degr de fiabilit Dure entre dfaillances
conscutives
Dure de bon fonctionnement
67
Ressource Facteur Mtrique
Degr de maintenabilit Dure de maintenance
Nombre de dfaillances
Degr de disponibilit Dure de disponibilit
Dure dindisponibilit
Degr de capacit Capacit de calcul (Hz)
Capacit de mmoire (Octet)
Capacit de stockage (Octet)
Degr de communication Dbit (Octet.s-1)
Degr de scurit Nombre dattaques vites
Nombre daccs physiques non
autoriss
Information Degr defficacit Nombre de requtes par processus
mtier
Degr defficience Cot dobtention
Cot de stockage
Cot de prsentation
Degr de confidentialit Nombre daccs protgs
Degr dintgrit Nombre de pertes par erreur
Nombre de pertes par incident
Niveau de qualit des donnes
Degr de disponibilit Nombre de requtes non satisfaites
Degr de licit Liste des lois considres
Liste des directives internes
considres
Nombre de rgles internes
Nombre de rgles externes
Nombre de rgles internes non
respectes
Nombre de rgles externes non
respectes
Degr de fiabilit Maturit du processus de
production des donnes
Tableau 4.3. Mtriques de ressource pour la GSI.
4.3.3.2.4. Mtriques de risque

La gestion des risques est dfinie par lISO 31000:2009 comme lensemble des activits
coordonnes visant diriger et piloter un organisme en intgrant la mise sous contrle des risques.
On dgage en gnral trois finalits la gestion des risques pour les SI :
1. Amliorer la scurisation des systmes dinformation.
2. Justifier le budget allou la scurisation du systme dinformation.
3. Prouver la crdibilit du systme dinformation laide des analyses effectues.
Les mtriques de risque font partie des mtriques qui alimentent les indicateurs daudit, ils
correspondent la mesure de loccurrence des vnements redouts, et de limpact sur les lments du
systme.
La littrature distingue deux types de mesure en rapport avec le risque :
68
La mesure de limpact dun vnement risque : il sagit destimer la criticit dun vnement
sur le fonctionnement du SI et denvisager les pertes ventuelles pour lorganisation.
La mesure de loccurrence dun vnement : il sagit destimer la probabilit dapparition dun
vnement risque.
Limpact et loccurrence sont deux mesures qui permettent de situer un vnement sur une
chelle de niveau de risque. Le niveau de risque est obtenu par le calcul dune matrice 3x3 (ou 5x5)
dont une dimension correspond une pondration de limpact (i=[0 ;100]) et la seconde dimension
correspond la probabilit doccurrence (p=[0 ;1]). Lindicateur de niveau de risque Nr est obtenu par
la formule Nr=p.i.
On distingue trois niveaux de risque :
Le risque est faible lorsque Nr=[0 ;10] ;

Le risque est moyen lorsque Nr=]10 ;50] ;
Le risque est lev lorsque Nr=]50 ;100].
Probabilit Impact
i=10 (Faible) i=50 (Moyen) i=100 (Elev)
p=10% (Faible) Nr=10x10%=1 (Faible) Nr=5 (Faible) Nr=10 (Faible)
p=50% (Moyen) Nr=5 (Faible) Nr=25 (Moyen) Nr=50 (Moyen)
p=100% (Elev) Nr=10 (Faible) Nr=50 (Moyen) Nr=100 (Elev)
Matrice 3x3 de classification du niveau de risque adapt de (Georgel, 2009)
(Georgel, 2009) propose une classification de 31 vnements risque. Elle est reprise dans le
tableau 4.4.
ID Catgorie Nature Type p (%) i Nr

1 Risque Humain Menace Espionnage 100 100 100
industriel
2 Risque Humain Menace Criminalit 100 100 100
informatique
3 Risque Humain Menace Intrusion 100 50 50
4 Risque Humain Menace Hacker 50 50 25
5 Risque Humain Menace Terrorisme 10 10 1
6 Risque Humain Erreur Comprhension 50 100 50
7 Risque Humain Erreur Manipulation 50 50 25
8 Risque Humain Erreur Choix 50 100 50
9 Risque Humain Erreur Conception 100 100 100
10 Risque Technologique Composant Perte 50 100 50
Logiciel dintgrit
11 Risque Technologique Composant Perte de 10 100 10
Logiciel disponibilit
Logiciel confidentialit
13 Risque Technologique Composant Perte 10 100 10
technique dintgrit
technique disponibilit
technique confidentialit
69
ID Catgorie Nature Type p (%) i Nr
16 Risque Technologique Donne Perte 100 100 100
dintgrit
17 Risque Technologique Donne Perte de 10 100 10
disponibilit
18 Risque Technologique Donne Perte de 10 100 10
confidentialit
19 Risque dactivit Production Perte de 10 50 5
capacit
20 Risque dactivit Production Perte 10 10 1
dintgrit
21 Risque dactivit Production Perte de 10 10 1
disponibilit
22 Risque dactivit Organisation Perte de 50 50 25
capacit
23 Risque dactivit Organisation Perte 10 10 1
dintgrit
24 Risque dactivit Organisation Perte de 10 10 1
disponibilit
25 Risque dactivit Gestion Perte de 100 50 50
capacit
26 Risque dactivit Gestion Perte 100 50 50
dintgrit
27 Risque dactivit Gestion Perte de 100 50 50
disponibilit
28 Risque Naturel Inondation Perte de 50 100 50
disponibilit
29 Risque Naturel Foudre Perte de 50 50 25
disponibilit
30 Risque Naturel Gel Perte de 10 10 1
disponibilit
31 Risque Naturel Canicule Perte de 10 10 1
disponibilit
Tableau 4.4. Classification des risques IT suivant leur niveau de risque Nr.
Selon la classification des niveaux de risque du tableau 4.4, les risques majeurs (Nr=100) pour
lesquels un DSI doit prter une attention particulire, sont avant tout humain : il sagit de contrer les
menaces despionnage industriel, la criminalit informatique et dviter les erreurs de conception. Les
risques dactivit et les risques naturels sont de moindre importance que les risques technologiques.
Pour ces derniers, il sagit de limiter la perte dintgrit pour les donnes, la perte de disponibilit pour
les composants techniques et la perte de confidentialit pour un composant logiciel.
Au niveau du mta-modle REFGOUV, cela correspond lassociation value entre la classe

Mtrique et la classe Risque (Fig. 4.11).
4.3.3.2.5. Mtriques de but

Le mta-modle REFGOUV (Fig. 4.4) mentionne deux associations entre les concepts de but et
de mtrique. La premire dfinit le propos de la mesure, la seconde permet de justifier un but
dajustement suite lobtention dune valeur de mtrique qui nest pas conforme ce qui tait attendu
de la ralisation du projet.
70
Une mtrique de but suppose que laccomplissement du but est mesurable. Dans le domaine
de la gestion de projet, un objectif mesurable est appel SMART (Prather, 2005) en rfrence aux
critres de qualit associs lobjectif. Un but doit ainsi satisfaire les caractristiques suivantes:
Spcifique, Mesurable, Atteignable, Raliste et Temporel.
Par exemple, lobjectif gnrique de la GSI Atteindre ltat dalignement nest pas un
objectif directement mesurable. Cest un objectif apprciable via un indicateur de confiance sur le
degr dalignement. Un objectif SMART dans le cadre de lalignement serait Atteindre un taux
dalignement des composants applicatifs avec les activits mtier de 80% dans 6 mois . Lobjectif est
spcifique lalignement, il repose sur une mesure (le taux dalignement), qui est jug atteignable
(80%), reprsentatif de la ralit (raliste) et temporel (dans 6 mois).
Les mtriques de but correspondent des objectifs mesurables. Il existe ainsi, au plus, autant
de mtriques de but que de buts SMART. Nous reprsentons cela par deux liens : lassociation value
entre le concept mtrique et le concept but dajustement et lassociation a pour objectif entre le
concept mtrique et le concept gnrique but.
4.3.3.2.6. Indicateur
Un indicateur est un outil d'valuation et d'aide la dcision (pilotage, ajustements et rtro-
correction) permettant de mesurer une situation ou une tendance, de faon relativement objective, un
instant donn. La notion dindicateur dans le domaine des systmes dinformation est issue de la
gestion totale de la qualit (TQM) (Ittner, 1995), (Ravichandran, 2000).
Un indicateur se veut tre un agrgat d'informations offrant la possibilit des acteurs

diffrents (scientifiques, gestionnaires, politiques) de dialoguer entre eux. Il revt une forme
(graphique, jauge) et aussi une signification partage entre ses utilisateurs. L'indicateur (qualitatif ou
quantitatif) dcrit gnralement un tat, une rponse ne pouvant tre apprhende directement. Un
indicateur peut en agrger d'autres. Pour un indicateur agrg, on parle plus souvent d'indice.
Un indicateur efficace doit rpondre plusieurs critres :
Robuste, fiable, prcis et donc spcifique. Il doit ainsi tre reprsentatif des carts
mesurs.
Comprhensible et utilisable par tous les utilisateurs
Pertinent par rapport lobjectif concern.
Cot acceptable par rapport au service qu'il rend.
Avoir une temporalit.
A minima, nous considrons un indicateur comme la reprsentation dune mtrique associe

une chelle de valeur. Ainsi un indicateur, comme concept, est une spcialisation du concept de
71
mtrique (voir mta-modle Figure 4.11). Cela nous permet : (i) denvisager un indicateur diffrent
niveaux dagrgation des mesures via lassociation rcursive drive sur le concept de mtrique ;
(ii) de tracer, en navigant au travers des associations, les mtriques contribuant llaboration dun
indicateur.
Prenons comme exemple, dans le domaine de la gestion de projet, lindicateur de valeur

acquise. La valeur acquise est une estimation des dpenses budgtaires qui repose sur la mesure de
ltat davancement du projet. Cet indicateur thorique nest pas forcment le reflet de la position des
dpenses relles dun projet.
Imaginons le dveloppement dun logiciel : un budget de 10 000 a t allou pour la

spcification et le codage (ou implmentation) des modules de lapplication. A linstant t, on mesure la
progression du projet (5%). A linstant t, la valeur acquise est donc de 10 000 x 0,05 = 500 . Dans ce
cas, la mesure est lestimation de lavancement et lindicateur de valeur acquise est lagrgat de deux
mtriques : le rsultat de la mesure davancement du projet et la mesure de la valeur du budget allou.
Nous achevons ici la description des concepts de PROGOUV (Fig. 4.11) ddis aux mtriques
et aux indicateurs. Dans la section suivante, nous prsentons la notion de tableau de bord de la GSI
comme concept organisant les indicateurs et les mtriques prsenter aux dcideurs.
4.3.3.3. Le tableau de bord de la GSI

Nous reprsentons la notion de tableau de bord dans REFGOUV avec quatre associations (Fig.
4.11) entre le concept tableau de bord et les concepts but, risque, processus et ressource.
Cette reprsentation dcoule des travaux de Kaplan et Norton. Un tableau de bord est une vue
croise des indicateurs pour la prise de dcision. Il est organis suivant les axes dfinis par (Kaplan &
Norton, 2003) : laxe financier, laxe clients, laxe des processus internes et laxe de lapprentissage
organisationnel.
Nous adoptons pour notre propos (GSI) ce tableau de bord structur selon quatre perspectives
et nous proposons de lalimenter avec les indicateurs qui rpondent aux besoins de mesure de la GSI
prsents dans la section 4.3.3 (voir Fig. 4.12) :
Laxe stratgique contient les indicateurs dobjectif : ils permettent de mesurer ltat
daccomplissement des objectifs de la GSI.
Laxe de la valeur et de la performance contient les indicateurs de processus : ils
permettent destimer la performance et la maturit des processus SI pendant la
conduite des projets de SI, au regard des performances des processus mtier.
72
Laxe de la gestion des ressources contient les indicateurs de ressources : ils
permettent dvaluer lusage des ressources sur les facteurs de disponibilit, de
fiabilit
Laxe du risque contient les indicateurs de risque : ils permettent dapprcier les
vnements internes issus des processus et des ressources, ainsi que les vnements
externes ayant un impact ngatif sur laccomplissement des objectifs
Ce tableau de bord est ainsi reprsentatif des besoins des DSI de prouver, travers la gestion
des risques et des ressources et le pilotage des processus, la capacit du SI et des processus SI
soutenir (i) la cration de valeur pour le mtier et (ii) la performance de lentreprise.
Un exemple de tableau de bord est prsent (Fig. 4.12). Il correspond une situation o le DSI
prend en considration prioritairement lobjectif de conformit rglementaire (axe stratgique). Cet
objectif est soutenu par deux processus : un processus daudit dmesurant la conformit des projets,
processus et ressources, et un processus de mise en conformit sassurant de la ringnierie des
projets, processus et ressources non conformes. La performance de lexcution des processus repose
sur le pilotage des ressources et la capacit anticiper les risques. Ainsi laxe des ressources
correspond aux indicateurs dexpertise des ressources humaines, de disponibilit des outils daudit et
de fiabilit des donnes de contrle. Laxe des risques repose dans ce cas sur des indicateurs
dvaluation des vnements redouts comme la falsification des informations daudit ou la perte de
disponibilit des outils mtier.
Par souci de concision et de clart, seul un objectif de GSI a t mentionn. Il existe de ce fait
une multitude de contenus de tableaux de bord suivant les objectifs fixs et les relations entre les
indicateurs dfinis dans les quatre axes danalyse.
Axe stratgique Axe valeur et performance

Assurer la conformit rglementaire Processus daudit
Passer dun taux de conformit des Taux de projet non conforme
processus de 95% 100% dans 3 mois Taux de processus non conforme
Passer dun taux de conformit des Taux de ressources non conforme
ressources de 95% 100% dans 3 mois
Processus de mise en conformit
Taux de correction des projets
Taux de correction des processus
Taux de correction des ressources
Axe Risque Axe Ressource

Risque humain Ressources humaines
Falsification des informations daudit Nombre dauditeurs expriment
Erreur de conception pour la ringnierie
Ressources techniques
Risque technologique Disponibilit des outils daudit
Perte de confidentialit Disponibilit des outils correctifs
Risque dactivit Ressources informationnelles

Perte de disponibilit des outils mtier Fiabilit des donnes de contrle
Figure 4.12. Exemple de tableau de bord pour la GSI
73
Nous avons prsent les concepts de mtrique, dindicateur et de tableau de bord pour la GSI.
Ils sont mentionns dans REFGOUV (Fig.4.4) et leur usage permet aux acteurs des SI de prendre des
dcisions argumentes. Le concept de dcision est expos dans la section suivante.
4.3.4. La notion de dcision et concepts associs
Tableau de bord Dcision Action

< repose sur 0..*
+ID: Integer +ID: Integer +ID: Integer
1..*
+nom: String +description: String +description: String
+date: Date +date: Date opportunits
1..* Situation gnre
But
Situation
+ID: Integer Ajustement
+description: String +ID: Integer
+date: Date +description: String
Situation prvue
Figure 4.13. Reprsentation du concept de dcision dans REFGOUV
Dans la littrature deux types de dcision se ctoient (Berthoz, 2003) : la dcision rationnelle
qui repose sur des arguments et la dcision irrationnelle guide par linstinct et la conviction du
dcideur. Le modle REFGOUV se rapporte la dcision rationnelle et formalise un mcanisme de
prise de dcision argumente.
La dcision est un mcanisme de choix argument sur un ensemble de critres dterminants et

aboutissant la slection dune action. Il existe plusieurs familles de dcision. Deux familles
retiennent notre attention :
La prise de dcision est effectue sur un ensemble de critres : les mthodes actuelles
peuvent tre positionnes comme tant appropries pour les prises de dcision
multicritres (choix, classement, agrgation), monocritres (maximisation dune
fonction conomique) ou sans argument (ad-hoc). Parmi les mthodes multicritres,
nous pouvons citer les mthodes dagrgation MAUT (Dyer, 2005) ou ELECTRE
(Roy, 1968).
La prise de dcision est une activit humaine qui peut tre collaborative (modes :
majoritaire, minoritaire ou unanime) ou non-collaborative (mode autoritaire) (Weill,
2004)
Nous ne traitons pas ici des mthodes pour la prise de dcision, mais nous formalisons la
notion de dcision comme concept orientant le choix dune ou plusieurs actions parmi un ensemble
dactions pertinentes dans la situation considre. Nous rappelons quune situation est mesure par les
74
mtriques prsentes dans le tableau de bord et la slection dune action est guide par lanalyse des
indicateurs de tableau de bord refltant ltat de la situation. Le concept de dcision est ainsi associ
un tableau de bord et agrge un ensemble dactions pertinentes.
Nous considrons une situation particulire de dcision pour la GSI comme le constat dcart
entre ce qui a t planifi (situation prvue) et ce qui a t effectivement ralis (situation gnre).
Cela fait lobjet de la cration dun but dajustement dont lobjectif est de compenser lcart.
Lanalyse des carts pour la prise de dcision a notamment t utilise dans le domaine de la finance
pour la constitution des budgets (Gervais, 1998), (Nobre, 2001).
Nous pouvons prendre lexemple dun projet dune charge estime de 300 j.h qui dbute le 1er
septembre. La capacit utile est de 20 jours par mois. Le projet est planifi pour une quipe de 5
personnes soit une vitesse de dveloppement prvue de 5 units par jour et une date de livraison au 1 er
dcembre. Une valuation de la progression du projet est effectue le 15 octobre : le constat est que le
projet a progress plus vite que prvu (6,6 units par jour) et devrait tre termin au 7 novembre. La
livraison est pourtant prvue 21 jours plus tard. Afin de faire correspondre la ralit ce qui a t
planifi il est ainsi ncessaire de procder un ajustement : le projet peut tre planifi de nouveau au
15 octobre avec une quipe de 4 personnes. Les dlais sont respects et une ressource est libre pour
un autre projet ventuel. Le tableau 4.5 rsume cette situation.
Indicateur Planifi (1er septembre) Constat (15 octobre) Planifi (15 octobre)
Situation prvue Situation gnre Aprs Ajustement
Charge restante (j.h) 300 100 100
Taille de lquipe (h) 5 5 4
Dure du projet (j) 300/5 = 60 100/6.666 = 15 100/4 = 25
Vitesse (h/j) 5 200/30 = 6.666 4
Date de fin 1er Dcembre 7 novembre 21 novembre
Tableau 4.5. Exemple dajustement pour une planification de projet
REFGOUV permet ainsi de reprsenter les situations pour la prise de dcision. Nous constatons
par lexemple sur les projets, que la dcision aboutit une modification sur le systme des projets.
Cette modification est la consquence dune action.
Projet
+nom: String
+date: Date 1
0..1
+description: String Action
<impacte
0..1 1 +ID: Integer
But
+ID: Integer < impacte
+date: Date
Figure 4.14. Reprsentation du concept daction dans REFGOUV
75
Le concept daction est mal dfini dans la littrature en matire de gouvernance des SI.
Pourtant nous allons voir que cest un concept fondamental qui permet dintgrer les volutions
ncessaires au processus de la GSI.
Le domaine de la sociologie des techniques dfinit la notion daction. (Akrich, 1993)

sintresse la relation entre les processus dinnovation et lanalyse des formes dactions qui engagent
les objets techniques. Dans le cadre de cette analyse, il s'agit de rendre compte des modalits de
l'action et des consquences que les formes prises par l'action avec des dispositifs techniques ou par
leur mdiation ont sur la dfinition mme des intentions et des acteurs qui les portent . Rapport un
systme de GSI, laction porte sur un dispositif technique compos dobjectifs, de projets (dfinis par
leurs composants processus, ressources, risques), de mesures et de dcisions. La mdiation des
dcisions prendre et des actions qui en rsultent est assure par un dcideur (acteur) guid par
lunique but davancer vers la cible et anim par consquent par des intentions dajustement dans la
mesure o le projet, et encore moins le portefeuille de projets, nest pas un long fleuve tranquille. Des
vents et des courants de toute nature viennent perturber la trajectoire prvue et il faut apporter des
actions correctrices pour garder le cap.
Madelaine Akrich conclut dans son article (Akrich, 1993) sur le concept daction : l'action
peut tre considre comme une coopration entre l'utilisateur et le dispositif; le degr de coordination
ncessaire son bon droulement varie selon les dispositifs de mme que les moyens par lesquels se
construit l'ajustement du dispositif et de son utilisateur . Nous rejoignons cette ide que laction est la
rsultante dun mcanisme de prise de dcision dont lobjectif est lajustement des composantes du SI
et de sa gouvernance.
Dans notre mta-modle REFGOUV (Fig. 4.4 et 4.14), le concept daction est ainsi associ au
concept de dcision dune part et aux concepts de but et de projet par la relation dimpact dautre part.
4.4. Conclusion
Nous avons propos le modle REFGOUV qui dfinit un ensemble de concepts pour la
gouvernance des systmes dinformation. Les concepts, leurs caractristiques et les relations quils
entretiennent sont issus de lanalyse de la littrature.
Nous montrons galement le caractre novateur de lapproche de la GSI par un mcanisme de

conceptualisation : il nous permet denvisager une nouvelle structure pour le tableau de bord de la GSI
suivant les axes stratgie, processus, ressources et risque. Il met galement en lumire la ncessit de
mettre en uvre les activits de la GSI par lanalyse des carts et des objectifs dajustement.
De manire plus gnrale REFGOUV prend en considration lensemble des objectifs de la

gouvernance. Il permet ainsi danticiper les spcifications dun SI correctement architectur et align
76
avec les processus mtiers et les exigences de cration de valeur, et de supporter les dcisions
dajustement qui font partie du lot commun de la GSI.
Les chapitres suivants exploitent les concepts qui composent REFGOUV :
Le chapitre 5 prsente le modle PROGOUV qui guide larchitecte de systme dans la

slection des concepts manipuls dans le processus de gouvernance du SI.
Le chapitre 6 est une validation de notre proposition REFGOUV.
77
Chapitre 5. PROGOUV : Modle de
processus de la GSI
5.1. Introduction
Comme nous lavons dvelopp prcdemment, nous considrons que la gouvernance est
principalement une affaire de prise de dcision dans lincertain. La mdiation des dcisions prendre
et des actions qui en dcoulent, est assure par un dcideur qui est anim par la volont davancer vers
la cible assigne au projet, ou au portefeuille de projets. Dans la mesure o cette cible est mouvante, le
dcideur est responsable de ses leviers dactions correctrices et des ajustements mettre en place pour
atteindre la cible. Nous apprhendons ainsi la GSI comme un mcanisme de contrle et de rgulation
du portefeuille de projets SI.
Dans le chapitre prcdent, nous avons prsent REFGOUV qui intgre les concepts de but, de
projet SI, dindicateur, de mtrique et de dcision. Ce chapitre a pour objectif de prsenter le modle
de processus de la GSI (PROGOUV) qui se veut gnrique. Ce modle positionne une dmarche de
gouvernance des SI, guide par les objectifs, incluant les tapes de planification des projets, le suivi de
leurs ralisations et les prises de dcision sy rfrant. PROGOUV dcrit aussi la dynamique des
activits de la GSI et reprsente la manipulation du systme de concepts de REFGOUV. Lobjectif du
modle PROGOUV est de reprsenter la dmarche intentionnelle des gouvernants et des dcideurs pour
lingnierie des SI.
Le fait de considrer le processus de gouvernance SI comme intentionnel et dcisionnel nous a

conduit choisir le langage de la CARTE (Rolland, 1999) comme mta-modle pour exprimer le
modle PROGOUV (c.f. 3.3.3.2). La CARTE a notamment permis de guider les ingnieurs SI dans la
construction de lalignement mtier/SI (Etien, 2006), (Thvenet, 2009).
PROGOUV permet ainsi le guidage des dirigeants dans la construction dune architecture de
GSI qui repose sur des objectifs et des portefeuilles projets quil convient de mettre sous contrle. Par
extension, il reprsente le modle des donnes que le SI de support la GSI doit contenir.
Dans un premier temps, ce chapitre prsente les concepts de la CARTE (c.f. 5.2) qui sont
utiliss pour formaliser PROGOUV. Une seconde partie est ddie la prsentation du mta-modle
PROGOUV (c.f. 5.3) et des processus intentionnels pour la GSI.
79
5.2. Formalisme de modlisation de PROGOUV
5.2.1. Le formalisme de la CARTE

Le mta-modle de processus PROGOUV utilise les concepts du mta-modle de la CARTE
introduit par C. Rolland en 1999 (Rolland, 1999). La CARTE est reconnue pour permettre la
reprsentation de lintentionnalit et la variabilit des mcanismes daccomplissement des intentions.
Le recours que nous faisons au mta-modle de la CARTE est justifi par la variabilit des mthodes
de gouvernance et la multitude dintentions sous-jacentes cette activit. La figure 5.1 montre un
aperu des concepts de la CARTE dans le cadre dune mthode de gouvernance. Ces concepts sont
dcrits par la suite.
Langage
Mthode de gouvernance Concepts de la CARTE
traduit par > <<Intention>> <<Intention>>
Mthode CARTE
Dbut Fin
affin par
+composant 1..* 1..* 0..1 +source
traduit par >
Composant de mthode Section 1..* +cible 1 Intention
1..* 1..* 1
1
Stratgie
Reprsentation section
Payer une
lien Par CB Par facturation
commande
(stratgie)
Fin
Dbut Par chque nud
(intention)
Figure 5.1. Usage des composants de la CARTE (MAP) dans PROGOUV
La reprsentation dune CARTE se fait par un graphe orient o les intentions sont des nuds
et les stratgies sont les liens entre ces nuds. Le graphe de la CARTE est orient du nud Dbut au
nud Fin. La smantique accorde la flche ou lien est quun lien entrant dans un nud est une
stratgie potentielle permettant datteindre lintention reprsente par le nud ; un lien sortant dun
nud est une option stratgique potentielle une fois que lintention (reprsente par le nud) est
accomplie. Une faon daccomplir une intention cible en utilisant une stratgie rendue optionnelle par
la ralisation dune intention source est appele Section. Une CARTE a une dsignation de la forme
<verbe><complment> permettant de lidentifier et est constitue de plusieurs sections.
La figure 5.2 montre un exemple de CARTE dsigne par Excuter un portefeuille de

projets . Cette CARTE comporte 11 sections et 5 intentions.
80
1 Par construction oriente but
Dbut (a)
2
Par slection de projet
Identifier Par classification

1 un projet dexpert
Par identification des (b) 1
facteurs dvaluation Par rsonance 1 Par valuation
dexpert
1
1
Par application des
fonctions de prfrence Classer le 1
projet dans un dun projet
Evaluer portefeuille (d)
dun portefeuille
un projet Par identification des 1
Par slection 2
(c) facteurs dvaluation
Fin (e)
1 Par non concurence
Figure 5.2. Un exemple de CARTE : Excuter un portefeuille de projets
Les sections suivantes prsentent plus en dtail les concepts de la CARTE.
5.2.2. Concepts de la CARTE
5.2.2.1. Intention
Une intention est la projection mentale dun objectif atteindre. Dans cette projection, une
intention consiste en la ralisation dun ensemble de buts et/ou dactivits. Selon (Jackson, 1995), il
sagit de lexpression dun souhait qui dcrit le rsultant que lon souhaite obtenir. Dans lexemple de
la figure 5.1, Identifier un projet est une intention qui correspond lexcution dun ensemble
dactivits (non encore spcifies) qui ont pour objectif final la cration dun objet (le projet).
Deux intentions particulires Dbut et Fin constituent les nuds ouvrant et fermant la
CARTE. Ces deux intentions ont la particularit de porter sur le processus lui-mme : Dbut est
lintention qui fait passer le processus dcrit ltat actif alors que Fin est lintention qui fait
passer son tat inactif. Dans une CARTE, lintention Dbut na pas dantcdent, cest
uniquement une intention source. Lintention Fin na pas de successeur, cest une intention cible.
Une intention se reprsente graphiquement par un cercle (nud) contenant lintitul de

lintention sous la forme <verbe> <complment>.
Cette description du concept dintention dans les cartes nous amne poser des hypothses de
travail pour la formulation des intentions de PROGOUV :
H1 : Lintentionnalit permet dexprimer les transformations induites par la GSI.
H2 : Le processus de GSI est fini et born par des terminaisons
81
Daprs lhypothse H1, nous exprimons textuellement une intention avec un verbe
dvolution linfinitif et un complment dobjet portant sur les tats du concept. Par exemple,
lintention Identifier un projet a pour verbe identifier qui porte sur lobjet un projet . Le
projet est alors cr (projet.etat := cr).
Daprs lhypothse H2, nous exprimons la situation du processus, avec lintention source
Dbut et lintention cible Fin exprimant les tats actif et arrt du processus dcrit par la
carte. Soit lexpression prdicative sur le principe de composition C1 du processus et la rgle dtat R1
suivantes :
Ainsi le processus PROGOUV passe ltat actif lorsque lintention Dbut de son modle
de carte passe ltat actif. Le processus PROGOUV passe ltat arrt lorsque lintention Fin
de la carte passe ltat actif.
5.2.2.2. Stratgie
Une stratgie est une manire daccomplir une intention. Elle correspond un mcanisme qui
permet daccomplir lintention considre. Une stratgie a une dsignation compose de
<Par><complment>.
Une stratgie est reprsente graphiquement par une flche entrante sur lintention quelle vise
accomplir.
Le nombre de stratgies potentielles qui peuvent intervenir dans laccomplissement dune

intention permet dexprimer la variabilit des manires pour atteindre une intention. Ainsi dans notre
exemple (Fig. 5.2), lintention (b) Identifier un projet peut tre atteinte par lexcution de trois
stratgies : (ab1) Par construction oriente but , (ab2) Par slection de projet lorsquon vient de
dmarrer le processus, ou (cb1) Par rsonance , lorsquon vient dvaluer un (autre) projet.
5.2.2.3. Section
Une section est lagrgation dune intention source Is, dune intention cible Ic et dune stratgie
SIs.Ic liant Is et Ic. Une section est ainsi dfinie par le triplet <Is, Ic, SIs.Ic> et dsigne une manire selon
laquelle, partant dune intention source, une intention cible peut tre accomplie.
Dans lexemple de la Figure 5.2, Identifier un projet est une intention source qui, une fois
accomplie, rend possible le recours la stratgie Par identification des facteurs dvaluation pour
82
accomplir lintention cible Evaluer un projet . Le triplet rsultant < Identifier un projet (b),
Evaluer un projet (c), Par identification des facteurs dvaluation (1)> se lit littralement
Evaluer un projet depuis identifier un projet par identification des facteurs dvaluation .
Lusage de la CARTE dans lingnierie des mthodes dfinit la section comme la description
dune transition situationnelle, entre une situation source obtenue par laccomplissement de lintention
source, et une situation finale rsultante de la ralisation de lintention cible. La situation est alors
dcrite par les tats des composants de mthode. Ainsi lusage dune section satisfait un patron
comportemental qui comprend :
Un prdicat caractrisant les conditions pour autoriser lexcution dune section.

Une post-condition qui prcise ltat du produit lissue de la transition. Dans
PROGOUV (c.f. 5.3), cet tat est dfini par instanciation des concepts du modle
produit (REFGOUV).
Le processus de transformation qui prcise le mode opratoire de lvolution du
produit pour une transition atomique.
Une transition complexe, intgrera des intentions sous-jacentes transitoires. Dans ce cas, le
processus de transformation considr sera dcrit plus prcisment par une carte. Nous reprons ici le
mcanisme daffinement dune section par une carte.
5.2.2.4. Formes agrgatives de sections

Une section dcrit ainsi une transition qui est la fois situationnelle et intentionnelle. Ce qui
fait du mta-modle de carte un outil privilgi pour guider un processus de dcision argument. Une
CARTE contient plusieurs intentions cibles qui peuvent tre accomplies de diffrentes manires
suivant les intentions sources et les stratgies potentielles. La CARTE comporte ainsi une multitude
de transitions situationnelles/intentionnelles complexes. Une telle transition est rpute complexe
lorsquelle met en jeu plusieurs sections.
Nous dcrivons ici trois topologies pour les transitions intentionnelles complexes.
5.2.2.4.1. Paquet
Une relation de type paquet (bundle dans la littrature) permet de prciser que des sections
ayant les mmes intentions sources et cibles sont mutuellement exclusives. La transition intentionnelle
entre les intentions source et cible du paquet est effectue par lexcution dune, et une seule, des
sections. Ceci permet de dfinir une relation de OU exclusif (XOR) entre les sections dun mme
paquet.
Graphiquement la section concerne par le paquet est reprsente par un trait en pointill. Les
diffrentes stratgies mutuellement exclusives sont mentionnes avec deux segments formant un angle
83
aigu. Un exemple de paquet est montr la Figure 5.2 ; il sagit des deux sections entre lintention
source Classer le projet dans un portefeuille et lintention cible Fin . Le processus peut, ainsi,
soit se terminer par la slection dun projet, soit se terminer par la slection dun portefeuille.
5.2.2.4.2. Multi-Segment
Dans une carte, il est possible datteindre une intention cible partir dune intention source de
diffrentes manires, selon diffrentes stratgies. Cette topologie est appele multi-segment
(multithread). Cest une relation logique ET/OU entre sections ayant la mme intention source et la
mme intention cible. Dans lexemple de la Figure 5.2., les deux sections <a, b, 1> et <a, b, 2>,
forment un multi-segment car elles reprsentent deux manires diffrentes qui peuvent tre
complmentaires pour Identifier un projet .
Une relation multi-segment alternative (OU logique) entre plusieurs sections signifie que
lexcution dune des sections est rpute suffisante mais non-exclusive pour accomplir lintention
cible.
Une relation multi-segment composite (ET logique) entre plusieurs sections signifie que
lexcution de toutes les sections est ncessaire et suffisante pour accomplir lintention cible.
5.2.2.4.3. Multi-Chemin
Un chemin (path) permet dtablir une relation dantcdence dans lexcution des sections.
Le multi-chemin (multi-path) consiste en lensemble des combinaisons squentielles de

sections possibles pour atteindre une intention cible partir dune intention source. Une CARTE est
par nature multi-chemin puisquil existe plusieurs chemins possibles pour aller de lintention
Dbut lintention Fin . La Figure 5.2 comporte de nombreux multi-chemin. En guise
dexemple, nous en citerons trois. Le premier chemin se compose des sections <a,b,1>, <b,d,1>,
<d,c,1> et <c,e,1>. Il dcrit le parcours de la carte dexcution dun portefeuille projet lorsque celui-ci
contient un seul projet qui est valu par un expert. Un autre chemin est celui compos des sections
<a,b,2>, <b,c,1>, <c,d,1>, <d,e,2>. Il dcrit un autre parcours caractristique de la construction dun
projet en complment dun portefeuille existant. Lexcution du portefeuille se faisant par excution
dun et dun seul projet. Un autre chemin, un peu plus long que les prcdents, pourrait tre <a,b,1>,
<b,c,1>, <c,b,1>, <b,c,1>, <c,b,1>, <b,c,1>, <c,b,1>, <b,c,1>, <c,d,1>, <d,d,1>, <d,e,2>. Dans ce
dernier cas, le parcours est caractris par une cration des projets, affine par lanalyse de leurs
facteurs dvaluation, qui permet de les prioriser au sein dun portefeuille.
La dcouverte des chemins potentiels se fait par respect des contraintes logiques des paquets et
des multi-segments inclus dans les sections intermdiaires entre lintention source et lintention cible
du multi-chemin.
84
5.2.2.5. Excution et principes de guidage
Le guidage est le support document qui permet un acteur dorienter ses choix lors de
lexcution dune CARTE. Cest un ensemble de directives appliques de manire situationnelle qui
oriente la slection de la directive suivante excuter. Ainsi une situation qui est exprime par
lensemble des tats des produits manipuls par une CARTE est pertinente pour une directive. Une
directive (DXX) est dcrite sous la forme prsente la Figure 5.3.
(Rolland, 1999) dfinit trois cas possibles de guidage pour une navigation dans une CARTE :
Le choix port sur lintention atteindre depuis lintention source : ce choix fait
lobjet dune directive de slection dintention (DSI).
Le choix port sur une stratgie excuter pour naviguer dune intention source vers
une intention cible, lorsquil existe au moins une section entre ces deux intentions. Ce
choix est support par une directive de slection de stratgie (DSS).
Les activits raliser pour que lintention cible dune section puisse tre accomplie.
Cela fait lobjet dune directive daccomplissement dune intention (DAI).
Les directives ont un niveau de complexit suivant les activits dingnierie mettre en
uvre. (Ralyt, 2001) propose une typologie : une directive peut tre simple (activit), tactique
(dcision) ou stratgique (intention). Nous structurons ainsi les directives sur deux dimensions : son
propos et son paradigme dexpression.
Prsentation graphique du composant Prsentation graphique des concepts REFGOUV

de processus PROGOUV concern concerns :
DSI/DSS : tat de la situation de REFGOUV
Is (a) S1 DAI : production dinstances de composants REFGOUV
C1 C2
*
S2 Ic (b) +a1
+a2
+a3
* +a4
Prsentation graphique de directive tactique Prsentation graphique dune directive simple
DXX : <(Situation), Intention de navigation> DAI : <(Situation), Intention de navigation>
(arg1) OU (argN)) ET
SelectionDXX1() SelectionDXXN() Activit 1 Activit 2
arg1 : description de largument qui sil est

vrifi oriente vers la slection de DXX1
Figure 5.3. Patron de conception dune directive.
5.2.2.5.1. Directive de slection dintention

Une Directive de Slection dIntention, appele DSI, permet de slectionner une intention
cible Ic parmi toutes celles possibles partir dune intention source Is. Dans la CARTE, il existe une
DSI associe chaque intention source.
85
Le guidage vers la slection dune intention cible se fait par lvaluation dun argument (arg)
qui, sil est vrifi, oriente vers lopration de slection dune intention cible. Lexcution dune DSI a
pour impact de restreindre lensemble des sections potentielles en sortie de lintention source pour
continuer la navigation dans une carte. Si lexcution de la DSI et lintention cible que cette dernire a
permis de choisir conduisent plusieurs stratgies potentielles, une directive de slection de stratgie
(DSS) est alors propose et excute. Dans le cas o il existe une seule stratgie pour accomplir
lintention cible, lunique directive daccomplissement dintention (DAI), correspondant lunique
section, est alors excute. Les DAI et les DSS sont dcrites dans les sous-sections suivantes.
DSI : Si (arg) alors

(Ic);
Si (card({SIsIc})>1) alors
executer(DSS(Ic/Is)); sinon excuter(DAI(Ic/SIsIc); FinSi
FinSi
5.2.2.5.2. Directive de slection de stratgie

Dans le cas o il existe plusieurs stratgies pour accomplir une intention cible Ic, partir dune
intention source Is, une Directive de Slection de Stratgie, appele DSS, permet de choisir une
stratgie parmi les stratgies potentielles {SIsIc} entre les deux intentions <Is, Ic>. Dans une CARTE, il
existe une DSS associe chaque couple dintentions <Is, Ic> lies par au moins une section ou plus.
Le guidage pour la slection dune stratgie se fait par lvaluation dun argument (arg) qui,
sil est vrifi, conduit la slection dune stratgie parmi n. Lexcution dune DSS se termine par
lexcution dune directive daccomplissement dintention (DAI).
DSS : Si (arg) alors

(SIsIc);
excuter(DAI(Ic/SIsIc));
FinSi
5.2.2.5.3. Directive daccomplissement dintention

Une Directive dAccomplissement dIntention, appele DAI, permet de guider
laccomplissement dune intention de la CARTE partir dune intention source suivant une stratgie
donne. Ainsi, il existe une DAI par section.
Une DAI est simple lorsque lintention est immdiatement atteignable par lexcution dun
mode opratoire prdfini. Dans le cas contraire, elle est affine par une CARTE de niveau plus
dtaille (c.f. 5.2.2.5.6).
86
5.2.2.5.4. Directive de guidage simple
La situation est telle quil ne reste aucune dcision humaine prendre. Il sagit de
loprationnalisation dune section. Ce type de directive correspond ce quon peut aussi appeler une
procdure et prescrit les activits excuter pour modifier le produit considr.
Dans le cadre de PROGOUV, la connaissance mthodologique associe une section

oprationnelle sera encapsule dans une directive daccomplissement dintention (DAI) simple.
5.2.2.5.5. Directive de guidage pour un contexte tactique

La situation de navigation dans la CARTE ncessite de prendre une dcision de choix parmi
plusieurs alternatives. Lorsque les alternatives sont concurrentes (OU inclusif) la directive repose sur
lexpression darguments disjoints et vrifiables sparment. Lorsque les alternatives sont non
concurrentes (OU exclusif) la directive repose sur lexpression darguments corrls.
Le contexte choix (Rolland, 1994) introduit dans le projet NATURE est notamment utilis
dans les DSS lorsque la transition complexe est dfinie par un paquet (OU exclusif) ou un multi-
segment (OU inclusif).
Dans le cadre de PROGOUV, une directive de slection dune intention ou dune stratgie (DSI
et DSS) sera documente par une directive tactique.
5.2.2.5.6. Directive de guidage pour un contexte stratgique

Une directive de guidage peut aussi tre stratgique. Elle correspond alors un besoin
dorienter les choix de nature intentionnelle et den donner une dfinition non prescriptible.
Dans une carte, laffinement dune section repose sur une directive daccomplissement
dintention (DAI) qui est de type stratgique. La DAI contient alors la description de la carte
daffinement.
Dans le cadre de PROGOUV, une directive stratgique sera documente par une carte.
5.2.2.6. Relation avec les concepts de REFGOUV

Les directives guident aussi lutilisation des concepts du mta-modle de produit de la GSI
(REFGOUV). Lorsque ces concepts sont observs pour orienter la slection dune option de guidage
(DSI ou DSS), leurs tats sont dcrits dans linterface de la directive (situation). Lorsque ces concepts
sont transforms par lapplication dune DAI simple, ils sont mentionns comme composant produit
dune directive. Le composant produit dune DAI simple correspond ainsi un sous-ensemble de
REFGOUV.
87
5.2.3. Vrification dune CARTE
Les deux sections suivantes recensent les rgles de vrification dune CARTE. Elles sont
traduites et adaptes des travaux de Colette Rolland (Rolland, 2001), Anne Etien (Etien, 2006) et
Laure-Hlne Thvenet (Thvenet, 2009). La formulation des processus PROGOUV repose sur
lapplication de ces rgles de vrification.
5.2.3.1. Validation
La vrification de la validit dune CARTE consiste en lapplication dun ensemble de rgles
adaptes de (Rolland, 2001). Une CARTE est rpute valide si elle satisfait chacune des rgles
nonces ci-aprs :
R1. Aucune intention dans la CARTE ne peut tre considre comme une sous-partie
dune autre intention.
R2. Aucune stratgie dans la CARTE ne peut tre considre comme une sous-partie
dune autre stratgie.
R3. Aucune intention ne doit tre une manire datteindre une autre intention.
R4. Les intentions ayant pour rsultat la mme partie de produit doivent tre agrges
dans une intention dagrgat.
R5. Les sections reprsentant des manires exclusives de produire un mme rsultat
doivent tre regroupes au sein dun paquet.
R6. Les intentions considres comme faisant partie dune transaction doivent tre
abstraites au sein dune unique intention.
R7. Les intentions qui se complmentent mutuellement doivent tre agrges au sein
dune unique intention.
5.2.3.2. Invariant de la CARTE

Un invariant est une proprit que la carte doit vrifier. Les trois invariants vrifier sont
exprims sous forme de rgle :
RI1 : toute CARTE a une, et seulement une intention, qui nest la cible daucune
stratgie ; cest lintention Dbut .
RI2 : toute CARTE a une, et seulement une intention, qui nest la source daucune
stratgie ; cest lintention Fin .
RI3 : toute intention dans une CARTE est connexe et non bloquante. Elle doit pouvoir
se raliser au moins une fois, cest--dire quil existe un chemin qui la relie
lintention Dbut et lintention Fin .
88
Dans les sections prcdentes nous avons dcrit les concepts constituants de la carte, sa
documentation sous forme de directives ainsi que sa validation. Les notations de la CARTE permettent
ainsi de dfinir un processus intentionnel et dcisionnel qui correspond notre perception de la
gouvernance des SI. Dans la section suivante nous prsentons le mta-modle PROGOUV qui repose
sur la manipulation des concepts de la CARTE.
5.2.4. Prsentation gnrale du mta-modle de processus PROGOUV

La figure 5.4 montre les concepts de la CARTE et prsente le mta-modle de processus de la
GSI, PROGOUV.
Les intentions et les dcisions dans PROGOUV reposent sur lanalyse des tats des concepts de
REFGOUV (c.f. chapitre 4). PROGOUV structure le processus qui sous tendent la GSI et dfinit les
dcisions et les activits qui manipulent les concepts de la GSI (REFGOUV).
0..* < porte sur

Classe a
Etat
+Attribut 1 1..*
0..*
exprime
Intention Source
Concept REFGOUV CARTE 1..* 1 1 DSI
<porte sur 1
+ID +ID
+Objectif a pour source Situation
1
0..1 1..*
1
excute
0..* Intention
affine 1..*
Stratgie +ID
0..* 2..* +Intitul
<porte sur DSS DXX
+ID
manipule Section +Intitul +ID +IntentionNav
1..*
+ID 1
0..*
excute
0..*
1..*
a pour cible Argument
DAI
<porte sur 1
+ID
1..* 1
Intention Cible
Figure 5.4. Mta-modle PROGOUV
5.2.4.1. Structure dun processus PROGOUV

La description des processus PROGOUV (Fig. 5.4) se compose de deux lments clefs :
Une CARTE qui comporte lensemble des sections excuter. Une CARTE est
identifie de manire unique par son identifiant (CARTE.ID) et comporte un objectif
associ (CARTE.Objectif).
Un ensemble de directives pour le guidage lors de lexcution de la CARTE : chaque
directive (DXX) est compose dune situation qui exprime les tats des lments du
cadre de GSI ; dune intention de navigation dans la CARTE (DXX.IntentionNav) ; et
dun ensemble darguments. Chaque directive spcifique (DAI, DSS et DSI) possde
une structure didentifiant qui lui est propre (ID).
89
5.2.4.2. Structure et indexation des lments du processus
Les lments du modle PROGOUV sont identifis de manire unique par un mcanisme
dindexation hirarchique par incrment. Il comporte une composante locale propre chaque CARTE
et une composante hirarchique permettant de situer la profondeur dune CARTE dans la logique
daffinement. La structure dindexation de la carte a t propose dans (Etien, 2006). Nous en
reprenons la structure et ladaptons.
Le modle de processus de la GSI, PROGOUV (Fig. 5.6) est dfini comme une instance du
mta-modle de processus intentionnel et dcisionnel montr la Figure 5.4.
5.2.4.2.1. Codification locale

La codification locale est propre une CARTE, elle permet didentifier au sein dune seule
CARTE les concepts dintention, et de section. Par extension une stratgie est identifie par rfrence
la section quelle supporte.
Les conventions de codification locale que nous proposons sont les suivantes :
Type index Structure dindex Commentaire Exemple

Intention k Index compos dun incrment Figure 5.2 : k=b se
(Intention.ID) k: Enum{az} alphabtique k. Cela permet rfre lintention
dindexer jusqu 26 intentions Identifier un projet
par carte.
Stratgie j Index compos dun incrment Figure 5.2 : j=1 peut se
(Stratgie.ID) j: {N+*} numrique positif j. cet rfrer la stratgie Par
incrment est relatif aux construction oriente but
intentions source et cible que
la stratgie lie. Plusieurs
stratgies peuvent avoir le
mme incrment dindex dans
une mme CARTE.
Section kkj Index compos dun identifiant Figure 5.2 : ab1 se rfre
(Section.ID) agrgeant les index locaux des la section Identifier un
composantes de la section : k, projet par construction
lindex de lintention source ; oriente but depuis
k, lindex de lintention cible dbut
et j lindex de la stratgie.
Tableau 5.1. Structure dindexation locale dune carte
5.2.4.2.2. Codification hirarchique

La codification hirarchique est un complment aux limites de la codification locale. Elle
permet de tracer le degr daffinement intentionnel dune CARTE et de positionner les lments dans
cette hirarchie
Par exemple, suivant la structure dindexation expose par le tableau 5.2, lintention d dindex
hirarchique C.Cab1.Cac3.d est lintention d de la CARTE de troisime niveau daffinement par rapport
la CARTE racine C.
90
Type index Structure dindex Commentaire Exemple
CARTE {C{kkj}+.}* Une carte est identifie par une CARTE C, racine
(CARTE.ID) chane de caractres constitue hirarchique
de la lettre C, dun index local CARTE C.Cab1 : CARTE
de section lorsque celle-ci daffinement de la section
affine une section et dun ab1 de la carte racine C
incrment hirarchique . .
Intention {C{kkj}+.}*k Index compos de lindex C.a : intention a de la
(Intention.ID) k: Enum{az} hirarchique de la CARTE et CARTE racine C
de lindex local k dune
intention
Section {C{kkj}+.}*kkj Index compos de lindex C.ab1 : section ab1 de la
(Section.ID) hirarchique de la CARTE et CARTE racine C
de lindex local k dune
intention
DSI DSI-{C{kkj}+.}*k Index compos du mot DSI DSI-C.a : directive de
(DSI.ID) agrg de lindex hirarchique slection dintention
de lintention source depuis associ lintention
laquelle sopre une slection source k=a de la CARTE
dintention racine C
DSS DSS-{C{kkj}+.}*kk Index compos du mot DSS DSS-C.ac : directive de
(DSS.ID) agrg de lindex hirarchique slection de stratgie
de rfrence de la CARTE et associe la slection de
des index locaux k et k des stratgie qui sopre entre
intentions source et cible lintention source k=a et
lintention cible k=c de
la CARTE racine C.
DAI DAI-{C{kkj}+.}*kkj Index compos du mot DAI DAI-C.ac1 : directive
(DAI.ID) agrg de lindex hirarchique daccomplissement
de la section documente. dintention associe la
section ac1 de la CARTE
racine C.
DAI- C.Cab1.ac1 :
directive
daccomplissement
dintention associe la
section ac1 de la CARTE
C.Cab1.
Tableau 5.2. Structure dindex hirarchique
5.3. Modle de processus PROGOUV

Dans la section 5.2, nous avons organis les concepts de PROGOUV au sein dun mta-modle
et nous avons propos une structure dindexation permettant dorganiser les composants de processus
de PROGOUV reprsents par des CARTES.
Cette section a pour objectif de prsenter plus prcisment les composants de processus
PROGOUV et de documenter les directives mthodologiques associes. Dans un premier temps, nous
rappellerons notre vision de la gouvernance des SI puis nous prsenterons successivement la carte
principale et les trois sous-cartes de PROGOUV. Nous appliquerons la logique dindexation
91
hirarchique prsente la section 5.2.4.2.2. Un aperu de lorganisation des quatre cartes de
PROGOUV est donn la figure 5.5. Le niveau stratgique est affin par les cartes C.C ab1, C.Cbb1 et
C.Cbb2. Le niveau de ralisation correspond lensemble des sections oprationnelles pour la
production des instances de composants REFGOUV.
C Niveau dabstraction
lev
Abstraction intentionnelle
Niveau dabstraction
C.Cab1 C.Cbb1 C.Cbb2 intermdiaire
[] []
C.Cab1C.C
.ab1 .ac1 Niveau oprationnel
C.Cab1
ab1 .ac2.bb1
C.C C.Cab1
ab1 .bc1 .bd1
C.C C.Cab1
ab1 .cb1 .cd1
C.C ab1
Figure 5.5. Index hirarchique appliqu sur les cartes de PROGOUV
5.3.1. La dmarche de gouvernance des SI

Nous rappelons ici brivement la dmarche de la gouvernance des SI.
Une perception communment admise de la GSI est de la structurer en relation au cycle de

W.E. Deming (PDCA) qui prescrit un processus damlioration continue en 4 tapes incrmentales
(Deming, 1991) : (i) la planification (en anglais plan ), (ii) lexcution (en anglais do ), (iii) la
vrification (en anglais check ), et (iv) ladaptation (en anglais act ).
Cependant, cette vision squence et prescriptive ne permet pas de mettre en lumire les
moyens par lesquels la GSI sinscrit de manire continue, mais nanmoins non pr-dfinie, dans le
temps. Nous pensons que cette comparaison au cycle de Deming ne reflte pas la complexit des
mcanismes de gouvernance.
Nous formulons le postulat quune bonne gouvernance des SI sappuie sur la connaissance du
SI existant, de ses projets, de son infrastructure. En fonction de cette connaissance, la GSI assigne des
besoins aux projets de dveloppement du SI. Les dcisions de rorientation de la gouvernance
reposent alors sur lanalyse des carts entre la performance prvue a priori et la performance mesure
a posteriori. Il est ainsi important dintroduire la notion dala : la performance, c'est--dire la maturit
des projets aboutir en qualit, dans les dlais et les budgets, est corrle aux incertitudes avec
lesquelles les projets vont devoir composer. Il est donc essentiel pour la GSI de mener en parallle des
92
activits de suivi et de contrle, et des activits danticipation des vnements perturbateurs pour
lensemble des projets SI dune organisation. Les dcisions gnrent des actions dadaptation pour le
SI, pour ses projets et pour les objectifs assigns ces projets quil convient de capitaliser. Ainsi la
gouvernance de demain repose aussi sur les expriences acquises de la gouvernance daujourdhui.
5.3.2. La CARTE C : Gouverner le systme dinformation
5.3.2.1. Composant graphique

La CARTE C (Fig. 5.6.) est la carte de haut niveau du modle ProGouv. Elle montre le
processus global de la GSI et met en perspective ses caractristiques essentielles par les stratgies
multiples qui visent gouverner le SI.
Par identification
Dbut des buts de GSI Par planification
(a) 1 des projets
1
Par integration de
2 lexistant
Gouverner le
SI (b)
1 2
Fin (c) Par prise de dcision

Par historisation
Figure 5.6. Description de la CARTE C.
Cette carte compte, en plus des intentions Dbut et Fin , lunique intention Gouverner
le SI . Cette macro-intention est lobjectif global que lon souhaite atteindre. Quatre stratgies
permettent daccomplir cette intention :
Par identification des buts de GSI : cette stratgie est utilise pour laborer les
nouveaux buts que lon assigne la stratgie des systmes dinformation.
Par intgration des buts existants : cette stratgie est un complment la premire.
Elle est utilise dans la situation o lon souhaite intgrer les buts dun prcdent plan
stratgique pour le SI.
Par planification des projets : cette stratgie consiste en la planification et

lexcution des volutions du systme dinformation. Le projet est le mcanisme par
lequel les volutions sont implmentes.
Par prise de dcision : cette stratgie met en uvre les mcanismes de mesures de
laccomplissement des projets dans le but de prendre une dcision sur les actions
entreprendre dans le cadre de la GSI.
93
La gouvernance des SI est une activit continue mene dans toutes les situations o le systme
dinformation est lobjet dattentions en vue de son volution. Lobjectif de gouverner un SI reste actif
tant que le SI a une existence. Lintention Fin est atteinte par historisation , c'est--dire par
capitalisation des actions dvolution sur le SI.
Le tableau 5.3 liste lensemble des directives associes la CARTE C.
DSI DSS DAI Sections de la carte C

DSI-C.a DSS-C.ab
DAI-C.ab1 ab1
DAI-C.ab2 ab2
DSI-C.b DSS-C.bb DAI-C.bb1 bb1
DAI-C.bb2 bb2
DSS-C.bc DAI-C.bc1 bc1
Tableau 5.3. Liste des directives associes C
5.3.2.2. Composants de guidage pour la slection dintention
5.3.2.2.1. DSI-C.a : Progresser depuis Dbut

Cette directive tactique est limite par la situation dexcution depuis lintention Dbut . En
effet le seul choix possible, en dmarrant la navigation dans la Carte C, est de slectionner lintention
Gouverner le SI . La figure 5.7 rsume cette situation et contraint excuter la directive de
slection de stratgie (DSS-C.ab) pour orienter le choix entre les deux stratgies offertes.
Par identification
Dbut des buts de GSI
(a) 1
Par integration de But

2 lexistant
Gouverner le
SI (b)
DSI-C.a: <(C.tat= actif), Progresser

depuis Dbut>
Slectionner(DSS-C.ab)
Figure 5.7. Directive DSI-C.a permettant de progresser depuis Dbut
5.3.2.2.2. DSI-C.b : Progresser depuis Gouverner le SI

La directive DSI-C.b propose deux choix :
Gouverner le SI dans le cas o les buts sont exploitables (but.tat= jour) pour la
planification des projets, ou que les projets soient en cours de ralisation pour une
prise de dcision.
94
La finalisation du processus de GSI. Elle consiste terminer cycle de gouvernance
dfini dans le plan stratgique. Cela signifie que les actions de la gouvernance des SI
ont t appliques et que le SI ne fait plus lobjet, momentanment, de lattention des
dirigeants pour une volution
La figure 5.8 prsente la directive de slection dintention permettant de progresser depuis

Gouverner le SI . Cette directive repose sur le constat de la situation des concepts lis au but de
GSI.
Par planification
des projets 1
*
Projet
Gouverner le But
*
2 0..1
SI (b) 0..1
< impacte <impacte
1
1 1
Action
Par historisation
DSI-C.b: <(But.tat= jour projet.tat= jour action.tat=termine),

Progresser depuis Gouverner le SI>
(arg1) (arg1)
Slectionner(DSS-C.bb) Slectionner(DSS-C.bc)
arg1 : Les actions de gouvernance ont t appliques
Figure 5.8. Directive DSI-C.b permettant de progresser depuis Gouverner le SI
5.3.2.3. Composants de guidage pour la slection de stratgie

La carte C contient deux multi-segments dont lexcution est documente par les deux
premires directives de slection de stratgie (DSS-C.ab et DSS-C.bb). La dernire directive (DSS-
C.bc) noffre aucun choix et impose lunique manire de terminer la navigation dans la carte de la
GSI.
5.3.2.3.1. DSS-C.ab : Progresser vers gouverner le SI depuis Dbut

La directive <(C.tat= actif but.tat=identifi), Progresser vers Gouverner le SI depuis
Dbut> est de type choix (contexte tactique). Elle permet de guider la slection dune stratgie au sein
du multi-segment C.ab qui comporte deux stratgies. Lobjectif associ cette directive est de choisir
la manire (stratgie) dont on va pouvoir intgrer un ensemble de buts pour la GSI : soit ces buts
existent dj depuis un prcdent plan stratgique, soit ils seront identifis dans la suite.
Les arguments sont disjoints ce qui permet dtablir un contexte de choix inclusif (OU
logique). Autrement dit, les deux sections C.ab1 et C.ab2 peuvent tre excutes de manire
complmentaire.
95
Par identification
(a) 1
Par integration des

But
2 buts existants
Gouverner
le SI (b)
DSS-C.ab : <(C.tat= actif but.tat=identifi), Progresser vers

Gouverner le SI depuis Dbut>
(arg ) (arg2)
1
Slectionner(DAI-C.ab1) Slectionner(DAI-C.ab2)
arg1 : Les besoins de la GSI imposent la cration de nouveaux buts

arg2 : Les buts de GSI sont connus
Figure 5.9. Directive DSS-C.ab permettant de progresser vers Gouverner le SI depuis Dbut
5.3.2.3.2. DSS-C.bb : Progresser vers Gouverner le SI depuis Gouverner le SI

La directive <(but.tat= jour ou projet.tat= jour), Progresser vers Gouverner le SI depuis
Gouverner le SI> est de type choix. Elle permet de guider la slection dune stratgie au sein du multi-
segment C.bb qui comporte deux stratgies. Lobjectif associ cette directive est de choisir la
manire de gouverner le SI selon ltat davancement dans le cycle de vie du portefeuille de projets.
On peut alors viser :
la planification de projets au sein dun portefeuille de projets en exploitant les buts

prcdemment dfinis (arg1). Ce choix conduit slectionner la directive
daccomplissement dintention DAI-C.bb1.
la prise de dcision dans un environnement constitu des projets en cours de

dveloppement (arg2). Ce choix conduit slectionner la directive daccomplissement
dintention DAI-C.bb2.
Les arguments sont disjoints ce qui permet dtablir un contexte de choix inclusif (OU
logique). Autrement dit, les deux sections bb1 et bb2 peuvent tre excutes de manire
complmentaire.
96
Par planification
des projets
1
Projet * * But
Gouverner le Par prise de dcision
SI (b)
DSS-C.bb : <(but.tat= jour ou projet.tat= jour), Progresser vers

Gouverner le SI depuis Gouverner le SI>
(arg ) (arg2)
1
Slectionner(DAI-C.bb1) Slectionner(DAI-C.bb2)
arg1 : Les buts sont exploitables

arg2 : Les projets sont exploitables
Figure 5.10. Directive DSS-C.bb permettant de progresser vers Gouverner le SI depuis

Gouverner le SI
5.3.2.3.3. DSS-C.bc : Progresser vers Fin depuis Gouverner le SI

Comme le montre la figure 5.11, cette directive tactique offre le seul choix possible qui
consiste slectionner la stratgie par historisation pour terminer le processus de GSI et contraint
slectionner la directive daccomplissement dintention (DAI-C.bc1).
Gouverner le
SI (b)
Action
1
Fin (c)
Par historisation
DSS-C.bc : <(action.tat= jour), Progresser vers Fin depuis Gouverner le SI>
Slectionner(DAI-C.bc1)
Figure 5.11. Directive DSS-C.bc permettant de progresser vers Fin depuis Gouverner le SI
97
5.3.2.4. Composants de guidage pour laccomplissement dintention
5.3.2.4.1. DAI-C.ab1 : Gouverner le SI depuis Dbut par Identification des buts de

GSI
La directive DAI-C.ab1 est de nature stratgique, elle est dcrite par la CARTE C.Cab1. Cette
directive a pour objectif de guider llaboration dun ensemble de buts, classs par catgorie et
assigns la gouvernance du systme dinformation.
Ainsi la section C.ab1 est affine par la CARTE C.Cab1 qui sera dveloppe dans la section
5.3.3.
5.3.2.4.2. DAI-C.ab2 : Gouverner le SI depuis Dbut par Intgration des buts

existants
Cette directive est simple elle consiste rintgrer, dans le processus de gouvernance, les buts
de GSI existants. Cette activit peut saccompagner de lidentification de nouveaux buts (DAI-C.ab1)
dans la mesure o les deux stratgies offertes par la directive DSS-C.ab (Figure 5.9) ne sont pas
mutuellement exclusives.
5.3.2.4.3. DAI-C.bb1 : Gouverner le SI depuis Gouverner le SI par Planification des

projets
La directive DAI-C.bb1 est de nature stratgique, elle est dcrite par la CARTE C.Cbb1. Cette
directive a pour objectif de guider llaboration dun ensemble de projets, didentifier les ressources,
processus et risques associs et danticiper les indicateurs de suivi pour les prises de dcision dans les
tapes ultrieures.
Ainsi la section C.bb1 est affine par la CARTE C.Cbb1 qui sera dveloppe dans la section
5.3.4.
5.3.2.4.4. DAI-C.bb2 : Gouverner le SI depuis Gouverner le SI par Prise de dcision

La directive DAI-C.bb2 est stratgique elle est dcrite par la CARTE C.Cbb2. Cette directive a
pour objectif de guider la prise de dcision sur les projets par lanalyse des situations des processus,
des ressources, des risques et des buts et par observation dcarts en vue de proposer des actions
dajustement.
Ainsi la section C.bb2 est affine par la CARTE C.Cbb2 qui sera dveloppe dans la section
5.3.5.
5.3.2.4.5. DAI-C.bc1 : Finir depuis Gouverner le SI par Historisation

La directive DAI-C.bc1 est simple. Elle consiste terminer le processus de GSI actif en
historisant lensemble des tats du systme de gouvernance :
98
Si des actions ont t menes, les situations de dcision qui les ont gnres sont
dates.
Dans tout les cas, lorsque le cycle de gouvernance est termin, ltat des projets est
dat.
< repose sur

Tableau de bord Dcision
Gouverner 1..*
1..*
le SI (b) Action
1 1 1
1..*
oppotunits < impacte 0..1
Fin But
(c) Par historisation
1..* 0..*
* value * <impacte 0..1

Indicateur
1..* Projet
DAI-C.bc1 : <(action.tat= jour ou ProcessusGSI.dateFin<=Date.TODAY), Finir par

historisation>
1:<(action.tat= jour), 3:<(action.tat= jour et

2:<(Dcision.tat=analyse),
analyser les situations ProcessusGSI.dateFin<=Date.TODAY),
dater les tats de la situation>
de dcision> dater les tats des projets>
2.1:<(Dcision.tat=analyse)
2.2:<(Dcision.tat=analyse) 2.3:<(Dcision.tat=analyse)
, dater les tats des
, dater les tats des actions> , dater les tats des buts>
indicateurs>
Figure 5.12. Directive DAI-C.bc1 permettant de Finir depuis Gouverner le SI par

Historisation
5.3.2.5. Composant produit

La CARTE C et ses directives mthodologiques dfinissent le guidage des responsables de la
GSI. Elles se basent (i) sur les intentions et les stratgies exprimes dans les cartes de GSI ; mais aussi
(ii) sur les situations formalises en exploitant les instances des concepts du mta-modle REFGOUV
(voir chapitre 4). Le composant Produit couvre ainsi une partie du mta-modle REFGOUV. Nous
montrons ici la capacit de PROGOUV, au travers des scenarii des cartes affinant les sections C.ab1,
C.bb1 et C.bb2, produire un systme variable de concepts sur lesquels reposeront les spcifications
dun SI de gouvernance rpondant une situation particulire.
99
5.3.3. La carte C.Cab1 : Elaborer les buts de la gouvernance des systmes
dinformation

1
(a)
1
2 Section ab1 de la
(b) carte C affine par la
carte C.Cab1
1
(c) 2
Par compltude 1
Par affinement 1
Fin (d)
1 Par analyse Par

Par analyse des 1 Identifier un but 1
linguistique compltude
priorits de de GSI (b)
gouvernance
1 Identifier la
Par application CQG catgorie de but
Dbut
(c)
(a)
Par dfinition de 1
domaine
Par dfinition de 2
critre
Figure 5.13. Description de la CARTE C.Cab1.
La CARTE C.Cab1 dcrite la figure 5.13 a pour objectif de construire un panel de buts. Un
but est identifi par drivation du plan stratgique sur lanalyse des prfrences. Un but est typ (ou
rpertori) par le domaine et le critre qui lui correspondent (voir Figure 4.5, section 4.3.1). La
CARTE C.Cab1 comporte quatre intentions et huit sections.
Globalement on identifie deux approches :
Une approche bottom-up qui consiste dans un premier temps identifier un but puis
ensuite lassocier une catgorie.
Une approche top-down qui consiste construire les catgories de but et y associer
des buts drivs.
Le processus didentification des buts de GSI se termine lorsque le panel de buts est jug
complet par les responsables de la GSI.
Le tableau 5.4 liste les directives associes la CARTE C.Cab1.
100
DSI DSS DAI Sections de la carte C1.1
DSI- C.Cab1.a DSS- C.Cab1.ab
DAI- C.Cab1.ab1 ab1
DSS- C.Cab1.ac
DAI- C.Cab1.ac1 ac1
DAI- C.Cab1.ac2 ac2
DSI- C.Cab1.b DSS- C.Cab1.bb DAI- C.Cab1.bb1 bb1
DSS- C.Cab1.bc DAI- C.Cab1.bc1 bc1
DSS- C.Cab1.bd DAI- C.Cab1.bd1 bd1
DSI- C.Cab1.c DSS- C.Cab1.cb DAI- C.Cab1.cb1 cb1
DSS- C.Cab1.cd DAI- C.Cab1.cd1 cd1
Tableau 5.4. Liste des directives associes C.Cab1
5.3.3.2.1. DSI-C.Cab1.a : Progresser depuis Dbut

Lidentification de buts de la GSI a pour pr-requis davoir connaissance de la vision
(objectifs) et de la stratgie de lorganisation. Ces derniers sont consigns dans le plan stratgique de
lorganisation. Nous considrons le plan stratgique comme une ressource informationnelle, instance
du concept de connaissance, cette dernire tant reprsente vue comme une bote noire dans
REFGOUV (voir Figure 4.9, section 4.3.2.2).
Ainsi, si le plan stratgique est connu, lutilisateur est guid pour lidentification des buts de
GSI, par la directive DSS-C.Cab1.ab. De manire complmentaire (arguments disjoints), les catgories
de but peuvent tre identifies par la directive DSS-C.Cab1.ac.
Par analyse des 1 Identifier un but

gouvernance
Identifier la Connaissance
Dbut catgorie de but
(c)
(a)
Par dfinition de 1
domaine
Par dfinition de 2
critre
DSI- C.Cab1.a : <(Connaissance.tat= jour), Progresser depuis Dbut>
(arg1) (arg2) (arg3)
Slectionner(DSS- C.Cab1.ab) Slectionner(DSS- C.Cab1.ac)
arg1 : Les priorits de gouvernance sont connues

arg2 : La gouvernance est dirig par ple de comptence
arg3 : La gouvernance est dirig par la performance
Figure 5.14. Description de la directive DSI-C.Cab1.a.
101
5.3.3.2.2. DSI-C.Cab1.b : Progresser depuis Identifier un but de GSI
Comme le montre la Figure 5.15, cette directive a pour objectif de guider le responsable de la
GSI aprs quil ait identifi un sous-ensemble de buts de GSI. Le choix offert varie entre :
achever le processus didentification des buts, si toutes les exigences de GSI sont
traduites en but typs/catgoriss (Catgorie.tat=identifie)
progresser dans lidentification des buts par affinement, si la couverture des buts nest
pas juge satisfaisante par rapport aux exigences de GSI
identifier la catgorie dun but (argument disjoint), sil reste des buts de GSI pas
entirement spcifis/catgoriss.
Les DSS Progresser vers Identifier un but de GSI depuis Identifier un but de GSI et
Progresser vers Identifier la catgorie de but depuis Identifier un but de GSI peuvent alors tre
excutes de manire simultane, alors que la DSS Progresser vers Fin but depuis Identifier un but
de GSI sera exclusive.
Par compltude
Par affinement Fin (d)
1
1
But Catgorie
Identifier un 1..* 1
but de GSI (b) Identifier la
Par analyse
linguistique catgorie de
but (c)
1
DSI-C.Cab1.a : <(((But.tat= jour) + (But.tat= identifi))

(Catgorie.tat=identifie)), Progresser depuis Identifier un but de GSI>
(arg1) (arg2)
(arg2) (arg1)
Slectionner(DSS-C.Cab1.bb ) Slectionner(DSS-C.Cab1.bd) Slectionner(DSS-C.Cab1.bc)
arg1 : Les buts couvrent lensemble des besoins de GSI

arg2 : Un but nest pas catgoris
Figure 5.15. Description de la directive DSI-C.Cab1.b.
5.3.3.2.3. DSI-C.Cab1.c : Progresser depuis Identifier la catgorie de but

Lobjectif de cette directive est de guider la navigation dans le processus de GSI lorsquune
catgorie but est identifie. Le choix propos est exclusif et consiste soit terminer le processus
didentification des buts de GSI si toutes les exigences de GSI sont couverts par les buts catgoriss,
soit identifier un but de GSI par application de la mthode CQG (Category Question Goal).
102
Fin (d)
Identifier un but Par

1
compltude
de GSI (b) Catgorie
1 Identifier la
catgorie de but
(c)
DSI-C.Cab1.c : <(Catgorie.tat=identifie), Progresser depuis identifier la

catgorie de but>
(arg1) (arg1)
Slectionner(DSS-C.Cab1.cb) Slectionner(DSS-C.Cab1.cd)
Figure 5.16. Description de la directive DSI-C.Cab1.c.
5.3.3.3.1. DSS- C.Cab1.ab : Progresser vers Identifier un but de GSI depuis Dbut
Cette directive tactique est limite par la situation dexcution depuis lintention Dbut
vers Identifier un but de GSI . En effet le seul choix possible est de slectionner la stratgie par
analyse des priorits de gouvernance . Cette directive contraint la slection dune directive
daccomplissement dintention (DAI-C.Cab1.ab1).
5.3.3.3.2. DSS- C.Cab1.ac : Progresser vers Identifier la catgorie de but depuis Dbut
Cette directive guide la slection dune stratgie dans le multi-segment C.Cab1.ac. Les deux
stratgies visent identifier la catgorie de but. Elles sont complmentaires (arguments disjoints) et
peuvent tre slectionnes de manire simultane. Lidentification de la catgorie peut se faire par
dfinition de domaine en empruntant la section ac1 ou par dfinition de critre en empruntant la
section ac2.
103
Identifier la
catgorie de but
Dbut
(c)
(a)
Connaissance
Par dfinition de 1
domaine
Par dfinition de 2
critre
DSS-C.Cab1.ac: <(Connaissance.tat= jour), Progresser vers identifier la

catgorie de but depuis dbut>
(arg1) (arg2)
Slectionner(DAI-C.Cab1.ac2) Slectionner(DAI-C.Cab1.ac1)
arg1 : Lidentification dune catgorie est guide par les critres de GSI
arg2 : Lidentification dune catgorie est guide par les domaines de GSI
Figure 5.17. Description de la directive DSS- C.Cab1.ac.
5.3.3.3.3. DSS- C.Cab1.bb : Progresser vers Identifier un but de GSI depuis Identifier un
but de GSI
Cette directive tactique offre le seul choix possible de slectionner la stratgie par
affinement et contraint slectionner la directive daccomplissement dintention (DAI-
C.Cab1.bb1).
5.3.3.3.4. DSS- C.Cab1.bc : Progresser vers Identifier la Catgorie de but depuis Identifier
un but de GSI
Cette directive tactique offre le seul choix possible de slectionner la stratgie par analyse
linguistique et contraint slectionner la directive daccomplissement dintention (DAI-C.Cab1.bc1).
5.3.3.3.5. DSS- C.Cab1.bd : Progresser vers Fin depuis Identifier un but de GSI
compltude et contraint la slectionner la directive daccomplissement dintention (DAI-
C.Cab1.bd1).
5.3.3.3.6. DSS- C.Cab1.cb : Progresser vers Identifier un but de GSI depuis Identifier la
catgorie de but
application CQG et contraint slectionner la directive daccomplissement dintention (DAI-
C.Cab1.cb1).
104
5.3.3.3.7. DSS- C.Cab1.cd : Progresser vers Fin depuis Identifier la catgorie de but
compltude et contraint slectionner la directive daccomplissement dintention (DAI-
C.Cab1.cd1).
5.3.3.4.1. DAI-C.Cab1.ab1 : Identifier un but de GSI depuis Dbut par Analyse des
priorits de gouvernance
Cette directive consiste identifier un but de la GSI en salignant sur les priorits stratgiques
de lorganisation et leur criticit. Cela prsuppose lexistence dun plan stratgique qui dfinit les
objectifs stratgiques de lorganisation pour laquelle le SI est construit. (Bergeron et al., 2004)
identifie six usages stratgiques des systmes dinformation, savoir utiliser les TI pour :
1. rduire vos cots de production
2. raliser des pargnes substantielles
3. amliorer la productivit de votre entreprise
4. accrotre la profitabilit de votre entreprise
5. amliorer la qualit des produits et services
6. respecter les chances exiges par vos clients
Lidentification des buts de la gouvernance des SI se fait alors par corrlation avec les
objectifs stratgiques de lorganisation. Prenons comme exemple le premier objectif stratgique de la
liste prcdente : Utiliser les TI pour rduire vos cots de production . La corrlation consiste
exprimer un ensemble de buts propres aux SI :
Dfinir et prouver limpact du SI sur la rduction des cots de production.
Dfinir les cots directs et indirects du SI.
La directive, de nature tactique, directive est ainsi dcrite la figure 5.18.
105
Par analyse des priorits But
de gouvernance
1 Identifier un +ID: Integer
but de GSI (b) +description: String
Dbut +date: Date
(a)
DAI-C.Cab1 .ab1 : <(Connaissance.tat= jour), Identifier un but de GSI par analyse des
priorits de gouvernance>
1:<(Connaissance.tat= 2:<(Objectifs stratgique.tat=identifi),

jour), Identifier les objectifs Identifier les buts de GSI associs aux
stratgiques> objectifs stratgiques>
Figure 5.18. Description de la directive DAI-C.Cab1.ab1.
5.3.3.4.2. DAI-C.Cab1.ac1 : Identifier la catgorie de but depuis Dbut par Dfinition

de domaine
La notion de domaine est une spcialisation pertinente dune entit. En mathmatique, le
domaine de dfinition est associ la pertinence dun lment x dun ensemble de dpart pour
lapplication dune fonction f. Pour la gouvernance des SI, la dcouverte de ces domaines consiste
alors se poser la question :
Quels sont les domaines pertinents pour une activit de gouvernance des SI ?
La dfinition dun domaine consiste dcouper le champ dinvestigation de la gouvernance

des SI. Par exemple le rfrentiel de CobiT structure la gouvernance du SI en cinq domaines :
1. Lalignement stratgique ;
2. La cration de valeur ;
3. La gestion du risque ;
4. La gestion des ressources ;
5. La mesure de la performance.
Ces domaines permettent de structurer et situer les processus tels quils sont dfinis par CobiT.
Les domaines consistent pour CobitT en lexpression dun ensemble de macro-objectifs. Une catgorie
de but se rfre ainsi un domaine de la GSI. Cela justifie aussi la dfinition des concepts de
REFGOUV montrs la Figure 5.19 puisque lexcution de la directive DAI-C.Cab1.ac1 va les
instancier (Fig. 5.18)
106
Domaine GSI
Catgorie
+nom
Figure 5.19. Composant de REFGOUV produit par DAI-C.Cab1.ac1
5.3.3.4.3. DAI-C.Cab1.ac2 : Identifier la catgorie de but depuis Dbut par Dfinition

de critre
Un critre est une caractristique mesurable servant de base un jugement. Le critre est un
lment de classification.
Quels lments communs danalyse sur les domaines permettent didentifier quune GSI est
meilleure quune autre ?
Lun des critres souvent mis en avant dans la littrature est quune bonne gouvernance doit
tre performante, gnratrice de valeur et mature. Nous dfinissons ainsi les critres de Valeur ,
Performance et Maturit pour la catgorisation des buts de GSI.
Critre
Catgorie
+nom
Figure 5.20. Composant de REFGOUV produit par DAI-C.Cab1.ac2
5.3.3.4.4. DAI-C.Cab1.bb1 : Identifier un but de GSI depuis Identifier un but de GSI par
Affinement
Lapproche systmique par les buts, cest--dire lapproche qui consiste dfinir les
composants applicatifs dun systme par drivation des buts, est souvent mis en vidence dans la
littrature. Les mthodes GORE (Goal-Oriented Requirement Engineering) telles que le rfrentiel
NFR (Mylopoulos et al., 1992), I*/Tropos (Yu, 1997), (Castro et al., 2002) ou KAOS (Lamsweerde et
Letier, 2003) proposent des mcanismes de composition bass sur les liens logiques ET/OU. La
smantique accorde cette composition est quun sous-ensemble de buts drivs doit tre accompli
pour que le but compos soit accompli.
Laffinement dun but de GSI consiste en la construction dune hirarchie de buts partir du
but considr. Cette hirarchie permet, en plus de structurer les buts de haut niveau de la GSI,
didentifier, dans les niveaux plus bas de la hirarchie, des buts associs aux systmes de support.
107
affin par >
But
+description
+date 0..*
Figure 5.21. Composant de REFGOUV produit par DAI-C.Cab1.bb1
5.3.3.4.5. DAI-C.Cab1.bc1 : Identifier la catgorie de but depuis Identifier un but de GSI

par Analyse linguistique
Lidentification de la catgorie dun but relve de la capacit tisser un rseau smantique des
termes utiliss pour lexpression des buts. Un ensemble de mots composant lexpression dun but peut
ainsi se rfrer un domaine de la GSI. Par exemple, lexpression Mettre en cohrence se
rapportera au domaine de lalignement . De manire identique, les mots peuvent se rfrer des
critres, comme par exemple le terme rapidement se rfrera un critre de performance .
Le rsultat de cette directive (Fig. 5.22) permet de justifier le composant du modle RefGouv
montr la Figure 5.22.
But
+ID
+description
+date
Domaine GSI
+nom
1..*
0..*
0..*
Mot
+intitul
0..*
+dfinition Critre
0..*
+nom
Figure 5.22. Composant de REFGOUV produit par DAI-C.Cab1.bc1
5.3.3.4.6. DAI-C.Cab1.bd1 : Finir depuis Identifier un but de GSI par Compltude

Le processus dlaboration des buts se termine lorsque lensemble des besoins stratgiques
sont couverts par les buts identifis.
5.3.3.4.7. DAI-C.Cab1.cb1 : Identifier un but de GSI depuis Identifier la catgorie de but

par Application CQG
La technique CQG (Category Question Goals) est drive de la mthode GQM (Goal Question
Metrics) (Basili et al., 1994). Elle permet de spcifier des buts de GSI, qui sont dclins en un
ensemble de questions. Chaque question permet didentifier plusieurs buts et porte sur un domaine et
un critre particulier du systme de gouvernance. Prenons lexemple du domaine dalignement
108
stratgique et du critre de maturit . La dmarche CQG sappuie sur le patron de question suivant
: Quel but doit-on dfinir pour atteindre le critre i du domaine j ? :
Quels buts doit-on dfinir pour atteindre le critre de maturit du domaine de lalignement ?
Documenter loffre de services TI

Documenter et archiver le plan stratgique
Assurer le guidage de la mise en cohrence des TI et des processus mtier
Documenter les procdures de maintenance des services
Assurer le support mtier
Dfinir le plan qualit des TI

Question CGQ
+nonc
But
+ID Catgorie
+description 1..* 1
+date
Figure 5.23. Composant de REFGOUV produit par DAI-C.Cab1.cb1
5.3.3.4.8. DAI-C.Cab1.cd1 : Finir depuis Identifier la catgorie de but par

Compltude
109
La figure 5.24 est lagrgation des composants de modle REFGOUV produit par lapplication
des directives de la carte C.Cab1.
Question CGQ
affin par > +nonc
0..*
But
+ID
Catgorie
+description
+date 1..* 1
Domaine GSI
1..* +nom
Mot 0..* 0..*
+intitul 0..* Critre

+dfinition 0..* +nom
Figure 5.24. Synthse du composant REFGOUV produit par la carte C.Cab1
5.3.4. La carte C.Cbb1 : Gouverner le SI depuis Gouverner le SI par

planification des projets
2
Par Par Par
dcoupage portefeuille 3 construction de
1 composants
Par mise jour Identifier Fin (e)

1
un projet (b) Par suivi
2
Par but 1 Sans suivi 2
1
Dbut Par
Par cration Par GQM finalisation
(a) de tableau de
bord 1
2 Excuter un
1 Par
2 Par
Par GQM indicateur projet(d) continuit
Identifier une 2
1
1 mesure(c) Par
Par reprise de adaptation
mtriques
Par mtrique 1
de composant Par reprise de
projet planification
1
Figure 5.25. Description de la CARTE C.Cbb1.
La CARTE C.Cbb1 dcrite la Figure 5.25 a pour objectif de planifier les projets de SI
(autrement dit de constituer un portefeuille de projets) et den assurer la conduite et la ralisation. La
CARTE C.Cbb1 comporte cinq intentions et dix-sept sections.
Nous identifions deux phases distinctes qui sont :
110
La planification des projets et des mesures. Cette phase place lidentification des
projets, leur structuration et leur contexte au sein dun portefeuille de projets. La
structuration dun projet est assure par la construction dartfacts qui forment le
corps dun projet (son processus, les ressources utilises et produites et les risques
gnrs par les activits du projet). Lidentification des mesures se fait par drivation
des mtriques partir des buts en utilisant la mthode GQM (Goal Question Mtrics).
Les mtriques peuvent tre explores par les artfacts et permettre de construire des
indicateurs pour des tableaux de bords
Lexcution des projets. Cette phase met en uvre la ralisation des projets (selon la
planification dfinie dans le portefeuille de projets), quelle ait t cre lors du cycle
de gouvernance en cours ou par un prcdent (par reprise de planification). Un projet
peut tre excut suivant deux modes : par suivi, si un tableau de bord est fourni, ou
sans suivi. A noter que lexcution dun projet peut engendrer des mesures la vole
et ainsi ncessiter de produire un tableau de bord du projet.
Le processus de planification et de ralisation des projets se termine par le constat de

finalisation des projets ou de leur continuit.
Le tableau 5.5 liste lensemble des directives associes la CARTE C.Cbb1.
DSI DSS DAI Sections de la carte C.Cbb1

DSI-C.Cbb1.a DSS-C.Cbb1.adDAI-C.Cbb1.ad1 ad1
DSS-C.Cbb1.acDAI-C.Cbb1.ac1 ac1
DAI-C.Cbb1.ac2 ac2
DSS-C.Cbb1.ab DAI-C.Cbb1.ab1 ab1
DAI-C.Cbb1.ab2 ab2
DSI-C.Cbb1.b DSS-C.Cbb1.bb DAI-C.Cbb1.bb1 bb1
DAI-C.Cbb1.bb2 bb2
DAI-C.Cbb1.bb3 bb3
DSS-C.Cbb1.bc DAI-C.Cbb1.bc1 bc1
DSS-C.Cbb1.bd DAI-C.Cbb1.bd1 bd1
DAI-C.Cbb1.bd2 bd2
DSI-C.Cbb1.c DSS-C.Cbb1.cc DAI-C.Cbb1.cc1 cc1
DAI-C.Cbb1.cc2 cc2
DSS-C.Cbb1.cb DAI-C.Cbb1.cb1 cb1
DSI-C.Cbb1.d DSS-C.Cbb1.dc DAI-C.Cbb1.dc1 dc1
DSS-C.Cbb1.de DAI-C.Cbb1.de1 de1
DAI-C.Cbb1.de2 de2
Tableau 5.5. Liste des directives associes C.Cbb1
111
5.3.4.2.1. DSI-C.Cbb1.a : Progresser depuis Dbut

Au dmarrage de la navigation dans la carte C.Cbb1, cette directive permet de guider les choix
des dcideurs vers lidentification des projets, lidentification des mesures mettre en place pour
matrise la conduite de ces projets, ou la ralisation des projets. Le choix varie entre trois options:
Dans le cas o un projet est dj en cours dexcution (Projet.tat=historis), la

planification initiale est reprise et le projet est excut sil ne ncessite aucune mise
jour. Dans ce cas la directive guide vers la slection de lintention Excuter un projet.
Dans le cas o les buts de GSI sont identifis, (But.tat=identifi), si les besoins de
GSI imposent des contraintes de qualit absolu, comme la scurit par exemple, la
directive guide vers la slection de lintention Identifier une mesure.
Dans le cas o les buts de GSI sont identifis ou quun projet existant ncessite un
recadrage de planification, lintention Identifier un projet est une cible candidate.
Identifier
Par mise jour
un projet
(b)
2
Par but 1
Dbut But * Projet
(a) Par GQM Identifier *
une
2
mesure(c) Excuter un
1
projet(d)
Par reprise
Par reprise de
de mtriques
1 planification
DSI- C.Cbb1.a : <(Projet.tat= historis But.tat= identifi), Progresser

depuis Dbut>
(arg1) ((arg1) (arg2))
(arg2)
Slectionner(DSS- C.Cbb1.ab) Slectionner(DSS- C.Cbb1.ac) Slectionner(DSS- C.Cbb1.ad)
arg1 : Besoin de (re)plannifier un projet

arg2 : Besoin de (re)planifier une mesure
Figure 5.26. Description de la directive DSI-C.Cbb1.a.
5.3.4.2.2. DSI-C.Cbb1.b : Progresser depuis Identifier un projet

Comme le montre la Figure 5.27, aprs quun projet ait t identifi, cette directive a pour
objectif de guider le responsable de la GSI vers lidentification de mesures pour un projet,
lidentification dautres projets, ou la ralisation dun projet. Le choix varie ainsi entre trois intentions
cibles:
112
Dans le cas o un projet ncessite une dfinition plus aboutie (ex : intgration dun
autre projet dans le portefeuille), la directive guide vers la slection de lintention
Identifier un projet .
Si les besoins ncessitent de mettre un projet identifi sous contrle, le choix offert
dans la navigation est Identifier une mesure .
Dans le cas o le projet est rput complet, autrement dit si le projet a t identifi et
les mesures de contrle pour son suivi ont t valides, lintention Excuter un
projet sera la cible propose .
Par Par
dcoupage portefeuille Par construction * *
Projet But
de composants
1 2
3
1 Par suivi 1..* * 1..*
Tableau de bord
1..* a pour objectif
Identifier un Sans suivi
projet (b) 2 1..*
*
Excuter Indicateur Mtrique
1..*
un projet(d)
Par GQM value
Identifier une drive
mesure(c)
DSI- C.Cbb1.b : <(Projet.tat= identifi But.tat= identifi), Progresser

depuis Identifier un projet>
(arg2)
Slectionner(DSS- C.Cbb1.bb) Slectionner(DSS-C.Cbb1.ac) Slectionner(DSS-C.Cbb1.bd)
arg1 : Projet incomplet dans sa dfinition

arg2 : Besoin de plannifier les mesures associes au projet
Figure 5.27. Description de la directive DSI-C.Cbb1.b.
5.3.4.2.3. DSI-C.Cbb1.c : Progresser depuis Identifier une mesure

La directive DSI-C.Cbb1.c oriente les choix de construction de portefeuille de projets
lorsquune mesure a t identifie. Le choix offert au dcideur varie entre continuer explorer les
mesures et laborer des indicateurs ; ou (re)dfinir un projet en fonction des mesures identifies.
113
Par
2 indicateur
Par cration de
tableau de bord
Identifier 1..* 1..*
Mtrique But
1 une
a pour objectif
mesure(c)
Identifier
un projet 1
(b) Par mtrique de
composant projet
DSI- C.Cbb1.c : <(Mtrique.tat= identifi But.tat= identifi),

Progresser depuis Identifier une mesure>
(arg1) (arg2)
Slectionner(DSS-C.Cbb1.cc) Slectionner(DSS-C.Cbb1.cb)
arg1 : La mesure est incomplte dans sa dfinition

arg2 : Besoin dorganiser les mesures pour un projet
Figure 5.28. Description de la directive DSI-C.Cbb1.c.
5.3.4.2.4. DSI-C.Cbb1.d : Progresser depuis Excuter un projet

Un projet est par dfinition un ensemble dtapes structures pour aboutir un objectif dans
un environnement incertain. Ainsi le processus dexcution dun projet peut, soit aboutir
lidentification de situations exceptionnelles qui doivent tre mises sous contrle ( Identifier une
mesure ), soit le processus de planification de projets (construction de portefeuille) se termine lorsque
le projet est en-cours ou finalis.
Fin (e)
1
Par
finalisation Projet
Excuter un Par
projet(d) continuit
Identifier une 2
1
mesure(c) Par
adaptation
DSI- C.Cbb1.d : <(Projet.tat= en-cours), Progresser depuis Excuter un

projet>
Slectionner(DSS-C.Cbb1.dc) Slectionner(DSS-C.Cbb1.de)
arg1 : Une situation de mesure est identifie lors de lexcution dun projet
arg2 : Un besoin dvaluation survient
arg3 : Un projet a t termin
Figure 5.29. Description de la directive DSI-C.Cbb1.d.
114
5.3.4.3.1. DSS-C.Cbb1.ab : Progresser vers Identifier un projet depuis Dbut

Cette directive tactique permet doprer un choix entre deux manires didentifier un projet :
soit le projet nexiste pas et il doit tre construit par analyse des buts (section ab1), soit le projet existe
et une mise jour est ncessaire par rapport aux buts associs la GSI (section ab2).
Par mise jour Identifier

un projet
2 (b)
But * Projet
Par but 1 *
Dbut
(a)
DSS- C.Cbb1.ab : <(Projet.tat= historis But.tat= identifi), Progresser

vers identifier un projet depuis Dbut>
(arg1) (arg2)
Slectionner(DAI-C.Cbb1.ab2) Slectionner(DAI-C.Cbb1.ab1)
arg1 : Besoin de replanification dun projet existant

arg2 : Ncessit de construire un projet rpondant aux besoins de GSI
Figure 5.30. Description de la directive DSS-C.Cbb1.ab.
5.3.4.3.2. DSS-C.Cbb1.ac : Progresser vers Identifier une mesure depuis Dbut

Cette directive tactique permet doprer un choix entre deux manires didentifier une
mesure : soit la mesure nexiste pas et elle doit tre construite par drivation des buts et application de
la mthode GQM (section ac2), soit cette dernire existe et une mise jour est ncessaire par rapport
la mesure initiale (section ac1).
115
Dbut Par GQM
(a) 2
1..* 1..*
Mtrique But
1 a pour objectif
Identifier
Par reprise de une
mtriques mesure(c)
DSS- C.Cbb1.ab : <(Mesure.tat= historis But.tat= identifi),

Progresser vers identifier une mesure depuis Dbut>
(arg1) (arg2)
Slectionner(DAI-C.Cbb1.ac1) Slectionner(DAI-C.Cbb1.ac2)
arg1 : Besoin dintgrer des mesures existantes

arg2 : Ncessit de construire de nouvelles mesures
Figure 5.31. Description de la directive DSS-C.Cbb1.ac.
5.3.4.3.3. DSS-C.Cbb1.ad : Progresser vers Excuter un projet depuis Dbut

Cette directive tactique est limite par la situation dexcution depuis lintention Dbut
vers Excuter un projet . En effet le seul choix possible est de slectionner la stratgie par reprise
de planification . Cette directive contraint ainsi excuter la directive daccomplissement dintention
DAI-C.Cab1.ad1.
5.3.4.3.4. DSS-C.Cbb1.bb : Progresser vers Identifier un projet depuis Identifier projet

Cette directive de slection de stratgie permet de guider la slection dune stratgie pour
amliorer la structuration dun projet lorsquil a t identifi partir des buts de GSI. Le choix des
stratgies offertes varie entre structurer les composants ncessaires son accomplissement (section
bb3) ; situer un projet au sein dun portefeuille (section bb2) permettant ainsi didentifier les
ressources partages ; et dcomposer un projet en sous-projets et den identifier ainsi de nouveaux
(section bb1).
La slection parmi ces stratgies repose sur des arguments portant sur les tats des projets et
les besoins de compltude et de prcision dans la dfinition dun projet.
116
2
Par Par dcoup par >
Par
dcoupage portefeuille 3 construction de 0..1
1 composants 0..* 1..*
Portefeuille Projet
Identifier un
projet (b)
DSS- C.Cbb1.bb : <(Projet.tat= identifi), Progresser vers identifier un

projet depuis identifier un projet>
(arg2)
Slectionner(DAI-C.Cbb1.bb2) Slectionner(DAI-C.Cbb1.bb3) Slectionner(DAI-C.Cbb1.bb1)
arg1 : Un but de GSI ncessite le dveloppement de plusieurs projets

arg2 : Ncessit de dcrire les composantes dun projet
arg3 : Le projet est jug complexe
Figure 5.32. Description de la directive DSS-C.Cbb1.bb.
5.3.4.3.5. DSS-C.Cbb1.bc : Progresser vers Identifier une mesure depuis Identifier un

projet
Cette directive est limite par la situation dexcution depuis lintention Identifier un projet
vers Identifier une mesure . En effet le seul choix possible est de slectionner la stratgie par
GQM . Cette directive contraint ainsi excuter la directive daccomplissement dintention DAI-
C.Cab1.bc1.
5.3.4.3.6. DSS-C.Cbb1.bd : Progresser vers Excuter un projet depuis Identifier un projet

Lexcution dun projet peut se faire par suivi si les mesures ont t identifies et le tableau de
bord du projet construit. La deuxime manire de raliser un projet est de le faire sans suivi, lorsque
son accomplissement est jug certain et sans risques exognes.
1 Par suivi
Identifier
un projet caractristique
(b) 2 a < value
Sans suivi 1..* *
1 *
Projet Mtrique
Excuter un
projet(d)
DSS- C.Cbb1.bd : <(Projet.tat= identifi Mtrique.tat= identifie),

Progresser vers excuter un projet depuis Identifier un projet>
(arg1) (arg1)
Slectionner(DAI-C.Cbb1.bd1) Slectionner(DAI-C.Cbb1.bd2)
arg1 : Il existe une mtrique planifie pour lvaluation des caractristiques du

projet excuter
Figure 5.33. Description de la directive DSS-C.Cbb1.bd.
117
5.3.4.3.7. DSS-C.Cbb1.cb : Progresser vers Identifier un projet depuis Identifier une
mesure
Cette directive conduit au seul choix possible qui consiste slectionner la stratgie par
cration de tableau de bord . Cette directive contraint ainsi excuter la directive
daccomplissement dintention DAI-C.Cab1.cb1.
5.3.4.3.8. DSS-C.Cbb1.cc : Progresser vers Identifier une mesure depuis Identifier une
mesure
Cette directive tactique guide le dcideur dans sa construction dune mesure. Cette exploration
permet par exemple dlaborer des indicateurs lorsque la mesure souhaite ncessite une
reprsentation associe une chelle de valeur (section cc2). Lorsque la mesure est guide par les
caractristiques de lobjet mesur (exemple : la taille dun processus peut se mesurer en nombre
dactivits qui le composent), la section cc1 est utilise.
Par
indicateur
< value
Identifier une 2 caractrisitique * Mtrique
mesure(c) *
Par mtrique de 1
composant projet
DSS- C.Cbb1.cc : <(Mtrique.tat= identifie caractristique.tat= identifie),

Progresser vers Identifier une mesure depuis Identifier une mesure>
(arg1) (arg2)
Slectionner(DAI-C.Cbb1.cc2) Slectionner(DAI-C.Cbb1.cc1)
arg1 : Ncessit de fournir une reprsentation des mesures

arg2 : Ncessit daffiner la mesure des caractristiques sur les composants des projets
Figure 5.34. Description de la directive DSS-C.Cbb1.cc.
5.3.4.3.9. DSS-C.Cbb1.dc : Progresser vers Identifier une mesure depuis Excuter un

projet
Cette directive offre au dcideur un choix unique qui consiste utiliser la stratgie par
adaptation . Cette directive contraint la excuter la directive daccomplissement dintention DAI-
C.Cab1.dc1.
5.3.4.3.10. DSS-C.Cbb1.de : Progresser vers Fin depuis Excuter un projet

Cette directive guide le choix de la manire de terminer le processus de planification de
projets (construction de portefeuille). Deux manires mutuellement exclusives permettent datteindre
lintention Fin : soit le projet en cours dexcution est achev, soit il est en cours dexcution.
118
Dans ce dernier cas, lensemble des tats du projet et de ses composants sont archivs pour une
utilisation ultrieure.
Par 1
Excuter un finalisation
projet(d)
Par 2 a
continuit Projet caractristique
1 1..*
Fin
(e)
DSS- C.Cbb1.de : <(Projet.tat=en-cours), Progresser vers Fin depuis

Excuter un projet>
(arg1) (arg1)
Slectionner(DAI-C.Cbb1.de2) Slectionner(DAI-C.Cbb1.de1)
arg1 : Le projet ne peut tre finalis
Figure 5.35. Description de la directive DSS-C.Cbb1.de.
5.3.4.4.1. DAI-C.Cbb1.ad1 : Excuter un projet depuis Dbut par Reprise de

planification
Cette directive est pertinente pour une situation de reprise dexcution dun projet planifi,
voire dmarr. En dautres termes, il existe les lments de planification ncessaires la mise en
uvre du projet. Les activits associes la reprise dexcution consistent en (i) lanalyse du plan
prcdemment dfini, de ltat davancement du projet ; et (ii) laffectation des ressources ncessaires
la mise en uvre des activits restantes.
Cette directive repose ainsi sur la capacit du SI fournir les informations de planification
pertinentes sur un projet en cours dexcution. Lexcution de cette directive produit les ressources
informationnelles utiles la reprise de planification dun projet.
dcoup par >

0..1 1..*
Projet Ressource
1..*
+nom: String +ID: Integer
+date: Date +Nom: String
Information : Ressource
Nom = Plan de projet
Figure 5.36. Composant de REFGOUV produit par DAI-C.Cbb1.ad1
119
5.3.4.4.2. DAI-C.Cbb1.ac1 : Identifier une mesure depuis Dbut par Reprise de
mtriques
Cette directive repose sur le postulat quune mesure peut tre apprise dexpriences
antrieures sur les projets. Cela ncessite dextraire la connaissance des mtriques du SI existant, den
analyser le contenu et de choisir un ensemble de mtriques pertinentes pour les objectifs courants.
Par exemple, un objectif courant est dassurer la scurit des accs au systme dinformation
stratgique. Un prcdent projet sur la scurisation des accs aux bases de donnes oprationnelles de
lentreprise utilisait lindicateur du pourcentage du nombre dutilisateurs dont le mot de passe
respectait une forme scurise (exemple : plus de huit caractres alphanumriques).
dcoup par >
0..1 1..*
Mtrique
Projet 1..* Ressource
< value +ID: Integer
+nom: String +ID: Integer +description: String
+date: Date +Nom: String 0..* 0..*
+dim: Object
+description: String +valeur: String
Connaissance : Ressource
Nom = Mtrique
Figure 5.37. Composant de REFGOUV produit par DAI-C.Cbb1.ac1
5.3.4.4.3. DAI-C.Cbb1.ac2 : Identifier une mesure depuis Dbut par GQM

Cette directive met en uvre les tapes de la mthode GQM (Goal Question Metrics) de
Victor Basili (Basili et al., 1994). Cette dmarche couvre lidentification des mtriques en posant des
questions concernant loprationnalisation du but considr. La dmarche repose sur le postulat que
les buts sont noncs en rapport avec un artfact (un processus, une ressource, un risque). Une
deuxime tape consiste poser autant de questions possibles sur laccomplissement dun but. Une
mtrique est ensuite corrle un but par lintermdiaire dune question. On peut considrer lexemple
suivant :
Objectif : Amliorer le temps de rponse du processus de reporting
Questions :
Q1 : Quel est le temps de rponse actuel du processus de reporting ?

o M11 : Dure moyenne des temps de rponse
o M12 : Nombre de cas au dessus de la limite
Q2 : Quelle est la dviation du temps de rponse actuel sur lobjectif ?
120
o M21 : (temps de rponse actuel temps de rponse prvu) / temps de rponse
actuel
La dmarche repose ainsi sur un systme de donnes qui doit dcrire les buts, les mtriques
associes et les questions ayant guid lidentification des mtriques.
affin par >

0..*
But Mtrique
a pour objectif 1..*
+ID: Integer +ID: Integer
+description: String 1..* +description: String
+date: Date +dim: Object
+valeur: String
Figure 5.38. Composant de REFGOUV produit par DAI-C.Cbb1.ac2
5.3.4.4.4. DAI-C.Cbb1.ab1 : Identifier un projet depuis Dbut par But

Lidentification dun projet par les buts consiste slectionner les buts de la GSI pertinents
pour un projet. Un but de projet est un objectif qui porte sur les livrables produits durant le projet.
Ainsi les buts de GSI de haut niveau doivent tre traduits pour chaque projet de manire spcifique, en
sous-buts oprationnalisables par le processus du projet. Lidentification dun projet par les buts
concide avec ltape dtude prliminaire dun projet tel que dfini dans PMBOK. Cette tape permet
aussi didentifier les caractristiques dun projet.
affin par >
0..*
But Projet
a caractristique
+description: String * * +date: Date 1 1..* +nom: String
Figure 5.39. Composant de REFGOUV produit par DAI-C.Cbb1.ab1
5.3.4.4.5. DAI-C.Cbb1.ab2 : Identifier un projet depuis Dbut par Mise jour

La mise jour dun projet consiste adapter les objectifs dun projet existant pour quil puisse
satisfaire de nouveaux buts.
5.3.4.4.6. DAI-C.Cbb1.bb1 : Identifier un projet depuis Identifier un projet par

Dcoupage
Lactivit de dcoupage traditionnel dun projet (voir Figure 4.7, section 4.2) consiste
identifier les activits qui le composent. La dmarche consiste identifier les intrants et les extrants
dune activit et dy associer les ressources ncessaires. Dans le cadre de projets complexes, cette
notion de dcoupage en activits devient caduque et ncessite de morceler un projet en plusieurs sous-
projets de moindre envergure. Cest le cas des grands projets industriels comme la construction et la
121
livraison dune navette spatiale. Lacheminement dun composant de la navette sur le lieu
dassemblage nest plus une simple activit mais un projet part entire.
Nous considrons ici la notion de dcoupage comme une considration dordre

mthodologique visant simplifier un projet complexe en plusieurs sous-projets.
0..1 dcoup par >
Projet
1..*
+nom
+date
+description
Figure 5.40. Composant de REFGOUV produit par DAI-C.Cbb1.bb1

Portefeuille
Un portefeuille de projets est une organisation des projets dans un objectif de mutualisation et
defficience des ressources employes. La notion de portefeuille projets dcoule directement du
principe de portefeuille dans le domaine financier.
La ressource le plus souvent considre est fiduciaire : il sagit alors de rpartir (investir)
convenablement un budget sur lensemble des projets dans un but de rentabilisation. Dautres axes
danalyse que celui de la rentabilit financire peuvent tre considrs comme le montre le rapport de
lObservatoire Technologique de Genve (OT, 2004) sur la gestion de portefeuille projets. Lanalyse
de ces axes est rendue possible par la construction de tableaux de bord.
dcoup par >

0..1 1..*
Tableau de bord Projet

+ID: Integer +nom: String Portefeuille
1..*
+nom: String +date: Date +ID: Integer
1..* 0..*

Construction de composants
La construction de composants dcoule de la notion de dcoupage en activits dun projet. Ces
activits sont identifies avec leurs intrants, extrants et les moyens oprants tels que les acteurs
(ressources). Lensemble des activits squences forment le processus du projet (voir Figure 4.8,
section 4.3.2.1).
122
Projet
+nom
+date
+description
1 1..* 1..*
Processus Ressource Risque

+ID +ID +ID
+Nom +Nom +Nom
5.3.4.4.9. DAI-C.Cbb1.bc1 : Identifier une mesure depuis Identifier un projet par

GQM
Cette directive consiste en lapplication de la dmarche GQM. Les intrants considrs, ici,
sont les buts associs aux projets identifis.
affin par >

0..*
But Mtrique
+valeur: String
Figure 5.43. Composant de REFGOUV produit par DAI-C.Cbb1.bc1
5.3.4.4.10. DAI-C.Cbb1.bd1 : Excuter un projet depuis Identifier un projet par Suivi

Cette directive considre que lexcution dun projet sopre dans un cadre de suivi de
performance. Cest le cas lorsque les ressources sont limites et partages entre plusieurs projets. Le
suivi dun projet repose sur un ensemble dindicateurs et de mtriques pertinents pour la prise de
dcision au niveau de son pilotage.
Indicateur
Mtrique
caractristique < value +intitul: String
+ID: Integer +forme: Object
+nom: String * * +description: String +valeur: Integer
+dim: Object +valeurMIN: Integer
1..*
+valeur: String +valeurMAX: Integer
a +date: Date
1
1..*
Projet Tableau de bord
+date: Date +nom: String
+description: String +date: Date
Figure 5.44. Composant de REFGOUV produit par DAI-C.Cbb1.bd1
123
5.3.4.4.11. DAI-C.Cbb1.bd2 : Excuter un projet depuis Identifier un projet par Sans
suivi
Lexcution dun projet sans suivi est assez rare. Mais dans le cas o un projet est simple et
que les risques inhrents sont circonspects, les mesures de pilotage peuvent tre ignores. Cette
directive nest pas associe un composant du mta-modle REFGOUV.
5.3.4.4.12. DAI-C.Cbb1.cc1 : Identifier une mesure depuis Identifier une mesure par
Mtrique de composant de projet
Lidentification dune mesure repose ici, non plus sur le pourquoi (les buts) mais sur les
caractristiques intrinsques inhrentes aux composants dun projet et ses objets. Le standard ISO-
27004, qui est une rfrence en matire de scurit des SI, intgre cette notion par lintermdiaire des
objets de mesurage. Les caractristiques de ces objets, quil convient de mesurer, sont reprsentes par
des attributs. Ce standard dfinit entre autre la complexit de la mesure qui peut tre lmentaire ou
drive. Dans le second cas, la mesure drive repose sur des mesures lmentaires. En rapport avec
REFGOUV, il sagit de mesurer le ou les composants dun projet qui peuvent tre une ressource, un
risque ou un processus
< value Mtrique

caractristique
* * +ID: Integer
+nom: String +description: String
a
+dim: Object
Projet 1..*
1 +valeur: String
+nom: String 0..*
+date: Date 0..* 0..*
< value
< value
< value
0..*
Ressource
1..* +ID: Integer 0..*
+Nom: String Risque
0..*
1..* +ID: Integer
+Nom: String Processus
+ID: Integer
+Nom: String
Figure 5.45. Composant de REFGOUV produit par DAI-C.Cbb1.cc1
5.3.4.4.13. DAI-C.Cbb1.cc2 : Identifier une mesure depuis Identifier une mesure par
Indicateur
Un indicateur est la rsultante dun ensemble de mesures (mtriques). Il se veut reprsentatif
de la position des mesures par rapport une chelle de valeur. Beaucoup de cadres de rfrence
comme CobiT ou CMMi proposent des indicateurs trs gnriques sans donner les moyens
doprationnaliser les mesures. Cest dans ce contexte que sinscrit cette directive qui a pour but
didentifier les mesures effectuer pour supporter lindicateur considr.
124
drive
Indicateur
Mtrique +intitul
+ID +forme
+description +valeur
+dim +valeurMIN
+valeur +valeurMAX
+date
5.3.4.4.14. DAI-C.Cbb1.cb1 : Identifier un projet depuis Identifier une mesure par

Cration de tableau de bord
La cration dun tableau de bord finalise la construction dun projet dans sa phase de
planification. Il permet denvisager son excution dans le cadre dun suivi et va supporter la prise de
dcision. Un tableau regroupe un ensemble dindicateurs jugs pertinents sur des axes danalyse
dcisionnels. Kaplan et Norton (Kaplan, 1996) ont propos de construire un tableau de bord suivant
quatre axes danalyse : laxe financier, laxe du client, laxe du processus et laxe dapprentissage.
Dans cette perspective, un indicateur performant est un indicateur qui couvre les quatre axes. Dans
PROGOUV, ces axes sont adapts la gouvernance des SI :
Laxe du client est celui des buts de la GSI ;

Laxe du processus est inchang ;
Laxe financier est celui des ressources (financires, humaines, techniques et
informationnelles)
Laxe de lapprentissage est celui des risques.
Dcision Indicateur
+ID: Integer < repose sur +intitul: String
+description: String Tableau de bord +forme: Object
+date: Date 1..*
+valeur: Integer
+ID: Integer
+valeurMIN: Integer
1..* +nom: String
Projet +valeurMAX: Integer
+date: Date
1..* +date: Date
+nom: String
+date: Date
+axeRessource +axeProcessus +axeRisque +axeBut
Ressource Processus Risque But

+ID: Integer +ID: Integer +ID: Integer +ID: Integer
+Nom: String +Nom: String +Nom: String +description: String
+date: Date
Figure 5.47. Composant de REFGOUV produit par DAI-C.Cbb1.cb1
125
5.3.4.4.15. DAI-C.Cbb1.dc1 : Identifier une mesure depuis Excuter un projet par
Adaptation
Cette directive consiste identifier une mtrique lors de lexcution dun projet. Le projet
peut alors tre planifi de nouveau la vole en intgrant cette nouvelle mesure.
Projet Mtrique
a caractristique < value
1 +ID: Integer
+nom: String
+nom: String +description: String
+date: Date 1..* * *
+description: String +dim: Object
+valeur: String
Figure 5.48. Composant de REFGOUV produit par DAI-C.Cbb1.dc1
5.3.4.4.16. DAI-C.Cbb1.de1 : Finir depuis Excuter un projet par Finalisation

Le processus sachve par la finalisation du projet
5.3.4.4.17. DAI-C.Cbb1.de2 : Finir depuis Excuter un projet par Continuit

Le processus sachve alors que le projet na pas abouti. La finalisation du projet est reporte
ou planifie un cycle ultrieur de gouvernance.

Lexcution de lensemble des sections de la carte C.Cbb1 permet de justifier le sous-ensemble
du mta-modle de REFGOUV prsent dans la figure 5.49.
drive
* Mtrique
1 1..* caractristique *
Portefeuille Projet +ID: Integer
a +nom: String *< value +description: String affin par >
+ID: Integer 0..*
+nom: String +dim: Object 1..*
+date: Date * 0..*
+valeur: String 1..*
a pour objectif But
0..1 1..* 1..* 0..* 0..* 0..*
+ID: Integer
dcoup par > < value
+date: Date
< value
Indicateur
0..* < value
Processus +intitul: String
+ID: Integer 1..*
+forme: Object
+Nom: String 0..* +valeur: Integer
Risque +valeurMIN: Integer
1..* 0..* +valeurMAX: Integer
+ID: Integer +date: Date
+Nom: String Ressource
1..* +ID: Integer 1..*
+axeProcessus
+Nom: String
Tableau de bord
+axeRisque
+ID: Integer +axeRessource
+nom: String
+date: Date +axeBut
Figure 5.49. Composant de REFGOUV produit par la CARTE C.Cbb1.
126
5.3.5. La carte C.Cbb2 : Gouverner le SI depuis Gouverner le SI par prise de
dcision

Par suivi
1 des projets
Identifier un but
Dbut dajustement de
(a) la gouvernance
SI (b)
4
Par adaptation 2
vnementielle 2 Par valuation des
risques
Par valuation des
Par valuation processus Par valuation des
daccomplissement 3 ressources
du but
1
Prendre une
Dcision (c) 1
Par impact sur les buts 1
2
Sans impact Par analyse de TdB
Fin (d)
3
Par impact sur les projets
Figure 5.50. Description de la CARTE C.Cbb2.
La CARTE C.Cbb2 dcrite la figure 5.50 a pour objectif dassurer la prise de dcision pour
orienter les objectifs et les projets lissue dune phase danalyse. La CARTE C.Cbb2 comporte quatre
intentions et dix sections.
Nous identifions deux phases distinctes qui sont :
Lidentification des buts dajustement de la gouvernance des SI. Lors de lexcution

des projets, des vnements fortuits peuvent survenir et dvier le parcours planifi du
projet. Ces vnements peuvent tre gnrs par les projets eux-mmes (exemple : une
ressource critique devient indisponible) ou par des facteurs externes (exemple : entre
en vigueur dune nouvelle loi). Un but dajustement est identifi par suivi du projet
dans le cas o le projet lui-mme est gnrateur de lvnement fortuit. Un but
dajustement est identifi par adaptation vnementielle lorsque lvnementest
gnr par un facteur externe.
La prise de dcision. Cette phase prsuppose avoir identifi un but dajustement qui
est le propos de la dcision. Par exemple lentre en vigueur dune nouvelle loi force
identifier un but dajustement : vrifier le caractre rglementaire du SI. Le choix
parmi un ensemble dactions est laboutissement de la prise de dcision, guid par
lanalyse de la situation des indicateurs (valuations). Les actions peuvent avoir un
127
impact sur les buts (exemple : crer le but de GSI Assurer la conformit
rglementaire du SI), avoir un impact sur les projets (exemple : crer un projet
daudit de conformit pour vrifier lapplication de la nouvelle loi) ou encore navoir
aucun impact (les dcideurs ont la certitude quaucune action est pertinente au regard
de la situation).
La phase de prise de dcision sachve lorsque les impacts de la dcision sur les buts et les
projets ont t identifis.
Le tableau 5.6 liste lensemble des directives associes la CARTE C.Cbb2.
DSI DSS DAI Sections de la carte C.Cbb2

DSI-C.Cbb2.a DSS-C.Cbb2.ab DAI-C.Cbb2.ab1 ab1
DAI-C.Cbb2.ab2 ab2
DSI-C.Cbb2.b DSS-C.Cbb2.bc DAI-C.Cbb2.bc1 bc1
DAI-C.Cbb2.bc2 bc2
DAI-C.Cbb2.bc3 bc3
DAI-C.Cbb2.bc4 bc4
DSI-C.Cbb2.c DSS-C.Cbb2.cc DAI-C.Cbb2.cc1 cc1
DSS-C.Cbb2.cd DAI-C.Cbb2.cd1 cd1
DAI-C.Cbb2.cd2 cd2
DAI-C.Cbb2.cd3 cd3
Tableau 5.6. Liste des directives associes C.Cbb2
5.3.5.2.1. DSI-C.Cbb2.a : Progresser depuis Dbut

Cette directive tactique offre comme unique choix possible lintention Identifier un but
dajustement de la gouvernance SI . Ce choix conduit la directive de slection de stratgie (DSS-
C.Cbb2.ab) pour orienter le choix entre lidentification des ajustements par suivi des projets ou par
adaptation la survenue dun vnement fortuit.
5.3.5.2.2. DSI-C.Cbb2.b : Progresser depuis Identifier un but dajustement de la gouvernance

SI
Cette directive tactique offre comme unique choix possible de naviguer vers lintention
Prendre une dcision . Ceci conduit la directive de slection de stratgie (DSS-C.Cbb2.bc) pour
orienter ensuite le choix entre les diffrents types dvaluation.
5.3.5.2.3. DSI-C.Cbb2.c : Progresser depuis Prendre une dcision

Cette directive a pour vocation de guider lutilisateur dans la slection dune intention lorsque
lintention prendre une dcision est au moins partiellement atteinte :
Lorsque la prise de dcision dbouche sur la mise en uvre dactions, lintention

Fin est slectionne et le guidage est apport par la DSS-C.Cbb2.cd.
128
Lorsque la prise de dcision ncessite une analyse plus approfondie (les actions ne
sont pas -entirement- identifies), le guidage est apport par la DSS-C.Cbb2.cc.
Prendre une
Dcision (c) 1
Par impact sur les 1
buts 2
Dcision
Sans impact Par analyse de TdB +ID: Integer
Fin +description: String
+date: Date
(d)
3 Par impact sur les
projets
DSI- C.Cbb2.c : <(Dcision.tat=prise), Progresser depuis Prendre une

dcision>
(arg1) (arg1)
Slectionner(DSS-C.Cb21.cd) Slectionner(DSS-C.Cbb2.cc)
arg1 : Il existe des actions identifies correspondantes la dcision
Figure 5.51. Description de la directive DSI-C.Cbb2.c.
5.3.5.3.1. DSS-C.Cbb2.ab : Progresser vers Identifier un but dajustement de la gouvernance

SI depuis Dbut
Cette directive guide vers lidentification dun but dajustement de la GSI. Deux cas sont
envisags :
Le but dajustement est initi par suivi des projets. C'est--dire que les projets sont
gnrateurs de situations ncessitant un ajustement (exemple : accroissement des
dpenses budgtaires sur lensemble des projets).
Le but dajustement peut aussi tre gnr suite la survenue dun vnement externe
comme la publication dun texte rglementaire (loi, ratification dun trait
international).
129
Dbut Par suivi
1 des projets
(a) Situation
+ID: Integer
2
Identifier un but
Par adaptation dajustement de
vnementielle Situation gnre Situation prvue
la gouvernance
SI (b)
DSS- C.Cbb2.ab : <(Situation.tat= cre), Progresser vers Identifier un but

dajustement de la GSI depuis dbut>
(arg1) (arg2)
arg1 : Lvnement fortuit est gnr par un projet

arg2 : Lvnement fortuit est gnr par une entit externe
Figure 5.52. Description de la directive DSS-C.Cbb2.ab.
5.3.5.3.2. DSS-C.Cbb2.bc : Progresser vers Prendre une dcision depuis Identifier un but
dajustement de la gouvernance SI
Cette directive permet de guider la prise de dcision suivant les prfrences dvaluation du
dcideur en rapport avec le but dajustement. Nous distinguons quatre manires non exclusives de
prendre une dcision lorsque le but dajustement a t identifi :
par lvaluation de laccomplissement dun but, lorsque la ncessit dajustement

porte sur un but de GSI (exemple : adapter les composants du SI pour amliorer
lalignement avec les processus mtier)
par lvaluation des processus lorsque la ncessit dajustement porte sur des
processus (exemple : la ringnierie dun processus)
par lvaluation des ressource lorsque la ncessit dajustement porte sur des
ressources (exemple : recrutement dun nouveau personnel)
par lvaluation des risques lorsque la ncessit dajustement porte sur des risques
(exemple : restreindre laccs aux informations stratgiques)
130
Par valuation des
Identifier un but 4 risques
dajustement de But
la gouvernance +ID: Integer
Par valuation des +description: String
SI (b) ressources +date: Date
3
1 Prendre une
2 Par valuation des
Dcision (c)
Par valuation processus Ajustement
daccomplissement
du but
DSS- C.Cbb2.bc : <(Ajustement.tat=cr), Progresser vers Prendre une dcision depuis

Identifier un but dajustement de la GSI>
(arg1) (arg2) (arg3) (arg4)

Slectionner(DAI- Slectionner(DAI- Slectionner(DAI- Slectionner(DAI-
C.Cbb2.bc1) C.Cbb2.bc2) C.Cbb2.bc3) C.Cbb2.bc4)
arg1 : Lajustement porte sur un but
arg2 : Lajustement porte sur un processus
arg3 : Lajustement porte sur une ressource
arg4 : Lajustement porte sur un risque
Figure 5.53. Description de la directive DSS-C.Cbb2.bc.
5.3.5.3.3. DSS-C.Cbb2.cc : Progresser vers Prendre une dcision depuis Prendre une
dcision
Cette directive tactique offre comme unique choix de stratgie possible Par analyse de
tableau de bord . Cette directive contraint slectionner la directive daccomplissement dintention
DAI-C.Cab1.cc.
5.3.5.3.4. DSS-C.Cbb2.cd : Progresser vers Finir depuis Prendre une dcision

Cette directive repose sur lanalyse dimpact des actions engendres par une dcision. Nous
proposons ici de propager limpact suivant deux axes :
Lorsque la dcision a gnr une modification sur les buts, la section cd1 est excute.
Lorsque la dcision a gnr une modification sur les projets et leurs composants
(ressource, processus ou risque), la section cd3 est excute.
La prise de dcision peut ainsi aboutir sur linaction ; dans ce cas, le processus qui consiste
gouverner le SI par prise de dcision se termine sans modification (section cd2).
131
Prendre une
Par impact sur les buts Dcision (c)
1 Dcision
2 +ID: Integer 1..*
Action
Sans impact +description: String +ID: Integer
Fin +date: Date oppotunits +description: String
(d)
3
DSS- C.Cbb2.bc : <(Dcision.tat=cr Action.tat=identifie), Progresser

vers Fin depuis Prendre une dcision >
(arg1) ((arg2) (arg1)) (arg2)
Slectionner(DAI-C.Cbb2.cd1) Slectionner(DAI-C.Cbb2.cd2) Slectionner(DAI-C.Cbb2.cd3)
arg1 : une action engendre des oprations sur les buts

arg2 : une action engendre des oprations sur les projets
Figure 5.54. Description de la directive DSS-C.Cbb2.cd.
5.3.5.4.1. DAI-C.Cbb2.ab1 : Identifier un but dajustement de la gouvernance SI depuis

Dbut par Suivi des projets
Un but dajustement est lobjectif assign une variable daction en gestion de projets. Il
permet dorienter le pilotage des projets : il se base sur lanalyse des causes profondes des vnements
fortuits, souvent indsirables, apparus durant un cycle dexcution des projets.
Dans sa formulation, un ajustement peut porter sur le projet lui-mme et ses composants, ou
sur les buts au service desquels il a t construit. Nous distinguons ainsi :
Un ajustement de processus : permet dorienter une dcision pour ladaptation dun processus
(exemple : reporter la date de livraison du prototype de 4 jours )
Un ajustement de ressource : permet dorienter une dcision pour ladaptation des ressources
(exemple : faire sous-traiter lactivit de codage chez un partenaire )
Un ajustement de risque : permet dorienter une dcision pour ladaptation des risques
(exemple : limiter le nombre de serveurs hors service pour cause de surchauffe des
processeurs )
132
Par suivi Projet 1..* Mtrique
1 des projets * a pour objectif
0..*
*
1..*
Identifier un but But < valuer
Dbut dajustement de
0..*
Situation
(a) la gouvernance
SI (b) Ajustement
Situation gnre Situation prvue
DAI- C.Cbb2.ab1 : <(situation gnre.tat= cr , situation prvue.tat=mesure), Identifier

un but dajustement de la GSI par suivi des projets >
1:<(situation.tat=cr), 2:<(situation
3:<(situation gnre.tat=mesure),
identifier situation gnre.tat=identifie),
formuler le but dajustement>
gnre> mesurer les carts de
situation>
2.1:<(situation 2.2:<(situation
gnre=identifie), mesurer prvue=mesure), mesurer
la situation gnre> lcart>
Figure 5.55. Description de la directive DAI-C.Cbb2.ab1
5.3.5.4.2. DAI-C.Cbb2.ab2 : Identifier un but dajustement de la gouvernance SI depuis

Dbut par Adaptation vnementielle
Cette directive (Fig. 5.56) est lie au contexte dvolution des projets. Cette incertitude porte
sur lapparition dvnements obligeant le dcideur ragir afin de maintenir la prennit du projet en
vue datteindre les objectifs fixs. Ainsi la promulgation dune nouvelle loi en matire de gouvernance
impose de redfinir les objectifs, par consquent didentifier des buts dajustement par rapport ce qui
tait initialement planifi. Nous distinguons ici les faits engendrs par une entit externe (dans notre
exemple un corps tatique) des entits internes (exemple : processus, ressource, projet).
1..* Mtrique
a pour objectif
0..*
Identifier un but But 1..*

< valuer
Dbut dajustement de 0..*
(a) la gouvernance Situation
SI (b)
Ajustement
Par adaptation 2
vnementielle
DAI- C.Cbb2.ab2 : <(situation gnre.tat= cr , situation prvue.tat=mesure,

situation.origine=externe), Identifier un but dajustement de la GSI par adaptation vnementielle>
situation>
Figure 5.56. Directive DAI-C.Cbb2.ab2
133
5.3.5.4.3. DAI-C.Cbb2.bc1 : Prendre une dcision depuis Identifier un but dajustement de
la gouvernance SI par Evaluation daccomplissement dun but
Cette directive repose sur la connaissance pr requise des indicateurs daccomplissement dun
but. Ainsi toute prise de dcision par valuation daccomplissement dun but, prsuppose lexistence
dun tableau de bord contenant des indicateurs de but.
La dcision est un choix port sur un ensemble dactions dajustement alternatives. Ce choix
restreint les actions mettre en uvre pour accomplir le but dajustement. Ainsi les activits qui sous
tendent la prise de dcision sont:
1. Slectionner les indicateurs reprsentatifs du contexte du but dajustement
2. Identifier les actions dajustement potentielles
3. Identifier les critres de choix
4. Ordonner les actions sur des critres de prfrences
5. Choisir la/les action(s) mener.
Dans le domaine de la dcision, les deux mthodes les plus cites sont ELECTRE (Roy, 1968)
et MAUT (Dyer, 2005). ELECTRE se base sur une fonction de sur-classement par respect dune
condition de concordance pour guider lidentification des actions mener, alors que MAUT (Multi-
Attribute Utility Theory) se base sur une fonction de maximisation de lutilit sur un ensemble de
critres pour orienter le choix dune action. MAUT et ELECTRE couvrent lensemble des cinq
activits ci-dessus.
Indicateur
Mtrique
But +intitul: String
a pour objectif +ID: Integer +forme: Object
+ID: Integer +description: String
+description: String +valeur: Integer
1..* 1..* +dim: Object
+date: Date +valeurMIN: Integer
value 1..* +date: Date
0..*
1..*
Ajustement Critre
+nom: String
Action Dcision

1..* opportunits
+description: String +description: String
+date: Date
134
la gouvernance SI par Evaluation des processus
Cette directive repose sur la connaissance pr requise des indicateurs dvaluation des
processus. Ainsi toute prise de dcision par valuation des processus prsuppose lexistence dun
tableau de bord contenant des indicateurs de processus.
Les indicateurs de processus les plus connus sont les KPI (Key Performance Indicator) (AFAI,
2002). Ces derniers sont construits en rapport avec les buts des parties prenantes de lorganisation. Ils
refltent la performance avec laquelle les processus mtier permettent datteindre ces buts
organisationnels. Par exemple, lvolution du chiffre daffaires est un indicateur de la satisfaction des
clients, et de la progression de lentreprise sur son march : cest un indicateur de performance des
processus commerciaux. Le suivi des KPI peut se faire en temps rel, cest le propos du BAM
(Business Activity Monitoring) (Kolar, 2009).
drive
Indicateur
Mtrique
< value +intitul: String
0..* 0..* +description: String +valeur: Integer
Processus +dim: Object +valeurMIN: Integer
+ID: Integer
+Nom: String +date: Date
0..*
Critre
+nom: String
Action Dcision
1..*
opportunits
+date: Date

la gouvernance SI par Evaluation des risques
Cette directive repose sur la connaissance pr requise des indicateurs dvaluation des risques.
Ainsi toute prise de dcision par valuation des risques prsuppose lexistence dun tableau de bord
contenant des indicateurs de risque.
Les indicateurs de risque connus sont les KRI (Key Risk Indicator). Ces derniers ne refltent
pas la ralisation antrieure ou courante dune activit, mais sont reprsentatifs de limpact futur dun
vnement risque sur laccomplissement dun objectif. Un exemple de KRI pour la scurit des
systmes dinformation est le taux de pntration des zones dmilitarises (DMZ) : un taux lev est
reprsentatif dun risque lev despionnage, de dtournement ou de malveillances sur le SI.
135
drive
Indicateur
Mtrique
+intitul: String
< value 0..* +description: String +valeur: Integer
0..*
Risque +date: Date
+ID: Integer
Critre 0..*
+Nom: String
+nom: String
Action 1..* Dcision
+ID: Integer opportunits +ID: Integer

+date: Date

la gouvernance SI par Evaluation des ressources
Cette directive repose sur la connaissance pr requise des indicateurs dvaluation des
ressources. Ainsi toute prise de dcision par valuation des ressources prsuppose lexistence dun
tableau de bord contenant des indicateurs de ressources.
Les indicateurs de ressource permettent dapprcier la qualit des ressources engages dans un
projet : la quantit de budget en rapport avec la dure, le niveau de formation et les comptences des
intervenants, lutilit des applications de support (back office).
drive
Indicateur
Mtrique
< value 0..* +intitul: String
0..*
+description: String +valeur: Integer
Ressource +dim: Object +valeurMIN: Integer
+ID: Integer +valeur: String +valeurMAX: Integer
0..*
Critre
+nom: String
1..*
Action Dcision
opportunits
+date: Date
136
5.3.5.4.7. DAI-C.Cbb2.cc1 : Prendre une dcision depuis Prendre une dcision par
Analyse de tableau de bord
La prise de dcision par analyse de tableau de bord est une activit qui repose sur lanalyse
dun ensemble dindicateurs varis et pertinents pour accomplir le but dajustement. La prise de
dcision par analyse de tableau de bord est une prise de dcision multicritre.
drive
Ressource
+ID: Integer Indicateur
< value 0..* Mtrique
+Nom: String 0..* +intitul: String
< value +description: String +valeur: Integer
0..* 0..* +valeur: String
+ID: Integer +valeurMAX: Integer
+Nom: String 0..*
1..* +date: Date
1..*
< value
Risque But
0..* Action
+Nom: String +description: String +ID: Integer
1..* value 1..*

opportunits Critre
Ajustement
+nom: String
+axeBut
+axeRisque
+axeRessource
+axeProcessus +nom: String < repose sur
+date: Date +date: Date
5.3.5.4.8. DAI-C.Cbb2.cd1 : Finir depuis Prendre une dcision par Impact sur les buts
Dans ce cas de figure, les dcisions ont t prises et les actions entreprendre identifies. Les
actions portent dans ce contexte sur les buts de GSI.
Une action porte alors sur la mise jour des buts de la GSI. Nous identifions ici plusieurs
oprations :
Crer() : un nouveau but est cr.

ModifierTexte() : lnonc du but est adapt
ModifierCatgorie() : la catgorie dun but est modifie
Suspendre() : un but est momentanment suspendu
Supprimer() : un but est dtruit
137
Dcision
+ID: Integer
+date: Date
opportunits
1..*
But
0..1 1
Action
+ID: Integer
+description: String +ID: Integer
< impacte
Figure 5.62. Composant de REFGOUV produit par DAI-C.Cbb2.cd1
5.3.5.4.9. DAI-C.Cbb2.cd2 : Finir depuis Prendre une dcision par Sans impact
Cette directive stipule que le processus de prise de dcision se termine en concluant quil nest
pas ncessaire dentreprendre une action.
5.3.5.4.10. DAI-C.Cbb2.cd3 : Finir depuis Prendre une dcision par Impact sur les
projets
Dans ce cas de figure, les dcisions ont t prises et les actions entreprendre identifies. Les
actions portent sur les projets.
Une action porte alors sur la mise jour des projets. Nous identifions ici plusieurs oprations :
Concept Opration Description

Projet Crer() Les oprations sur les projets permettent
ChangerBut() dadapter lexcution dun projet en modifiant
AjouterRessource() ses buts et en modulant ses ressources et ses
RetirerRessource() risques.
AjouterRisque() Le projet peut tre suspendu pour tre repris un
RetirerRisque() moment ultrieur ou tre dfinitivement
Suspendre() supprim.
Supprimer()
Processus Crer() Les oprations sur les processus permettent de
Adapter() grer leurs cycles de vie. Lopration Adapter()
Supprimer() est utilis pour raliser une ringnierie du
processus du projet.
Ressource Crer() Ces oprations sont utilises pour moduler les
Modifier() ressources dun projet.
Supprimer()
Risque Crer() La modulation du risque est une opration
Moduler() spcifique qui consiste limiter un risque.
Supprimer()
Tableau 5.7. Liste des oprations dvolution des projets.
138
Dcision
+ID: Integer
+date: Date
Ressource
opportunits
+ID: Integer 1..*
+Nom: String Projet
Action
+crer() +nom: String 0..1 1
+modifier() +date: Date +ID: Integer
1..*
+supprimer() <impacte +description: String
+crer()
Risque
+changerBut()
+ID: Integer +ajouterRessource() But
*
+Nom: String +retirerRessource()
1..* *
+ajouterRisque() +ID: Integer
+crer() +retirerRisque() +description: String
+moduler() +suspendre() +date: Date
+supprimer() +supprimer()
+crer()
+ModifierCatgorie()
Processus +Suspendre()
+ID: Integer +Supprimer()
+Nom: String
+crer()
+adapter()
+supprimer()
Figure 5.63. Composant de REFGOUV produit par DAI-C.Cbb2.cd3
139
Lusage du processus intentionnel/dcisionnel dcrit par la CARTE C.Cbb2 manipule
lensemble des concepts prsents dans le diagramme de classe (Figure 5.64). Les apports principaux
mis en vidence pour le mta-modle REFGOUV concernent les concepts de Dcision, dAction et
dAjustement.
+axeBut
opportunits < repose sur
Action 1..*
Dcision Tableau de bord Indicateur
1..*
1 1
<impacte 1..*
+axeProcessus
0..1 +axeRisque
1..*
< impacte +axeRessource drive
Projet
* Mtrique
affin par >
0..1 0..* 0..*
* 0..*0..*
But
0..* < value < value
< value
1..*
Ressource 0..*
Ajustement
1..* 0..*
Risque
0..*
Processus
Situation prvue Situation gnre
0..* < valuer

Situation
Figure 5.64. Composant de produit associ la CARTE C.Cbb2
5.4. Discussion et conclusion

Dans ce chapitre, nous avons expos le modle PROGOUV. La gouvernance y consiste
ajuster, en continue, les activits des projets et des portefeuilles, la lumire des mesures observes et
en ragissant aux vnements fortuits, voire indsirables.
Nous avons utilis le paradigme intentionnel/dcisionnel/situationnel de la CARTE pour

dcrire les processus de GSI. La nature non prdictive des processus de GSI trouve une rponse
approprie dans le modle de la CARTE qui permet de dfinir des situations varies pour de multiples
scenarii de gouvernance. La preuve de la cohrence des concepts du mta-modle REFGOUV est ainsi
faite par les composants de processus PROGOUV prsents dans ce chapitre.
Le mcanisme daffinement de la CARTE permet de dfinir les composants du SI de

gouvernance qui seront utiliss pour lexcution des processus de la GSI. Cela fait de PROGOUV une
140
mthode liant les objectifs stratgiques, reprsents comme des intentions dans la carte et non support
a priori par un SI, avec les composants du SI.
PROGOUV rpond aux insuffisances des rfrentiels actuels de GSI qui ne proposent aucun
guidage situationnelle/dcisionnelle/intentionnelle pour limplmentation des outils et cadres de travail
qui supportent les activits de gouvernance.
Dans le chapitre suivant, nous allons illustrer lapplication des mcanismes de PROGOUV et
lutilisation des concepts de REFGOUV en droulant une tude de cas. Il sagit dun cas dcole,
PAPCAR.
141
Chapitre 6. Evaluation
6.1. Introduction
Nous discutons dans ce chapitre de la validation de nos hypothses de travail :

o H11 : Le domaine de la GSI manipule un ensemble dlments
conceptualisables.
o H12 : Le processus de la GSI est conceptualisable.
Lvaluation de notre proposition (REFGOUV et PROGOUV) repose sur deux aspects : (i) une
comparaison des mta-modles REFGOUV avec ceux du CobiT, dITIL et de COSO, et (ii) une
illustration de lapplication de la dmarche propose avec un scnario reposant sur une excution de
PROGOUV.
La comparaison des mta-modles REFGOUV et ceux des mta-modles des rfrentiels de

GSI proposs dans la littrature (CobiT, ITIL et COSO) consiste confronter le pouvoir dexpression
du modle REFGOUV au regard des standards les plus connus de la GSI. Cette partie de lvaluation
repose sur la proposition de cinq mtriques. Ces mtriques sont adaptes de celles issues de
lvaluation de lalignement des modles (Etien, 2006).
La seconde partie de lvaluation repose sur une illustration de la mthode MISIG le cas
PAPCAR (Nurcan, 2006). Rappelons que la Mthode dIngnierie du Systme dInformation de
Gouvernance (MISIG) est transversale lusage des modles REFGOUV et PROGOUV. Cest une
mthode qui guide lingnieur SI dans la construction du SI de gouvernance et de ses composants. Il
sagit doprer une instanciation partielle ou totale des concepts prsents dans REFGOUV. Pour chaque
section des cartes de PROGOUV, lintention cible porte sur un sous ensemble des concepts de
REFGOUV. Cette valuation permet de mettre en lumire lutilisation des processus dcrits dans
PROGOUV, des concepts dfinis dans REFGOUV, ainsi que lapplication de la mthode MISIG. Nous
mettons en vidence la prise de dcision par lanalyse des carts entre ce qui a t planifi et ce qui est
ralis.
Ce chapitre prsente successivement la description conceptuelle de COBIT, ITIL et COSO.

Puis deux sections sont consacres respectivement la prsentation des mtriques de correspondance
et la comparaison du pouvoir dexpression de REFGOUV avec ceux des trois rfrentiels cits.
Finalement, nous prsentons le cas PAPCAR afin d illustrer lutilisation de la mthode MISIG qui
143
intgre le multi-modle de processus de GSI (PROGOUV) et le modle de rfrence du domaine de la
GSI (REFGOUV).
6.2. Conceptualisation des rfrentiels de la GSI
6.2.1. CobiT
CobiT est un rfrentiel ddi aux processus daudit des ressources du systme dinformation.
A ce titre, il est trs reconnu et utilis dans le cadre des activits de contrle de la GSI. Nous
proposons de dmontrer la pertinence de notre modle REFGOUV au regard de CobiT. Dans cette
partie nous nous rfrons louvrage de Dominique Voisand sur la prsentation du rfrentiel CobiT
V4.1.
6.2.1.1. Historique et usages du rfrentiel CobiT

En 1996, afin de fournir un cadre complet et dtaill sur les objectifs dtablissement de
contrle dans un contexte volutif des technologies de linformation, lInformation Systems Audit and
Control Association (ISACA) a dit le modle COBIT, Control Objectives for Information and
Related Technology . LISACA est reprsent en France par lAFAI (Association Franaise pour
lAudit et le conseil en Informatique).
Les big 6, ou les six plus grands cabinets daudit mondiaux, ont largement contribu
ldification du CobiT : Arthur Andersen, Ernst & Young, Coopers & Lybrand, Deloite & Touche,
KPMG et Price Waterhouse. Le dveloppement de CobiT rsultait de la volont des auditeurs de
rpondre aux exigences du COSO et davoir un rfrentiel commun daudit. Le COSO (Committee of
Sponsoring Organizations of the Treadway Commission) est un rfrentiel publi pour la premire fois
en 1992. Il a pour objectif daider les entreprises amliorer leur systme de contrle interne.
Depuis une dizaine danne, lITGI (Information Technology Governance Institute), cr par
lISACA, maintient et fait voluer le standard de fait CobiT. LITGI a ainsi publi successivement
plusieurs versions : CobiT V3 (2000), CobiT V4 (2005) et CobiT V4.1 (2007). La publication rapide
de plusieurs versions de ce standard connote lintrt croissant de matriser les systmes daudit des
systmes dinformation. Ce besoin est accentu par les diffrents scandales financiers au dbut des
annes 2000 (Enron, Worldcom etc.) et par la volont des Etats de lgifrer sur le renforcement des
contrles lis aux processus financiers. Ainsi plusieurs textes rglementaires et normatifs sont
apparus : la loi Sarbanes-Oxley (SOX) est vote par le Congrs Amricain en 2002. En France, la loi
de scurit financire (LSF) est adopte par le Parlement le 17 juillet 2003 (JO n177 du 2 aot 2003).
Les normes internationales dinformation financire (IFRS International Financial Reporting
Standards) sont cres en 2005 afin dharmoniser la prsentation des tats financiers des entreprises
cotes en bourse.
144
Dans cette perspective un systme dinformation manipule linformation utilise par les
composantes mtiers. A ce titre, les audits doivent reflter la capacit du SI fournir une information
de qualit (efficace, efficiente, confidentielle, raliste, disponible, conforme et fiable). CobiT fait une
description organisationnelle du systme dinformation qui repose sur 34 processus mettre sous
contrle afin de prouver la capacit du SI rpondre aux besoins des directions gnrales tels que :
Faire correspondre le SI aux besoins des mtiers (alignement stratgique)

Apporter des avantages lexcution des processus mtier (efficacit et efficience)
Avoir une utilisation optimale des ressources informatiques (infrastructures,
applications, informations et personnes)
Matriser les risques lis au SI et leurs impacts pour les mtiers.
partir de lanalyse dun ventail dimpratifs plus larges regroupant les impratifs en
matire de qualit, de confiance et de scurit, sept caractristiques distinctes de contrle de
linformation ont t slectionnes. COBIT dfinit ainsi les objectifs de contrle de linformation et
des technologies associes autour de cinq axes danalyse dimportance au regard de la gouvernance
des SI : lalignement stratgique, lapport de valeur, la gestion des risques, la gestion des ressources et
la mesure de la performance.
6.2.1.2. Conceptualisation de CobiT

Le rfrentiel de CobiT est structur par des composantes sur lesquelles il est ais dappliquer
un processus de conceptualisation. Nous faisons ici la description de ces composantes et nous
proposons un modle conceptuel (Fig. 6.1) afin de montrer, un niveau dabstraction identique les
diffrences et les similarits entre les concepts de CobiT et ceux proposs dans cette thse.
145
6.2.1.2.1. Produit
1 Dfinit par
Modle de maturit 1..*
Niveau maturit
1
Ressource TI
Role Activit Critre information
1..* 1..* 1..* 1..4 1..7
Entre 1..* 0..* Domaine de gouv.

1..* Produit 0..* 1
1..*
Element ProcessusCOBIT 1..5
0..* Consomme 0..* * 0..*
Sortie 1
Domaine
1..*
1..* Objectif de contrle
Contrle 1..* Mtrique
1..* 1..* 1..*
1..*
1..* 1..*
But mtier But TI ButCOBIT Mesur par

IndicateurCOBIT
1..* 1..*
Indicateur de but TI
Indicateur de but de processus

But Activit
Indicateur de perf.
Figure 6.1. Diagramme de classe des concepts de CobiT.
Dans les paragraphes suivants, les concepts sur la figure 6.1 apparaissent en italique dans le
corps de texte.
CobiT fait rfrence quatre Domaines gnriques pour les processus. Chacun contient les
processus audits par la dmarche de CobiT et fait rfrence une tape du cycle de gouvernance :
Planifier et Organiser, Acqurir et Implmenter, Dlivrer et Supporter et, Surveiller et Evaluer. Au
total, CobiT regroupe 34 processus (ProcessusCOBIT) qui rpondent cinq exigences de gouvernance
des SI (Domaine de gou.). Un processus est audit suivant des critres dinformation (Critre
information) par rapport un ensemble dobjectifs de contrle (Objectif de contrle). Il est analys
suivant son niveau de maturit qui est reprsentatif de son efficacit et son efficience.
Selon CobiT un processus utilise des ressources en terme de comptences, dinformation,

dapplications et dinfrastructures (Ressource TI), et ncessite des lments dinformations intrants et
extrants (Element, Entre, Sortie). Un processus organise des Activits au cours desquelles
interviennent des acteurs conformment leurs fonctions et leurs responsabilits (Role). CobiT
propose une grille RACI (Responsible, Accountable, Consulted, Informed) qui permet de visualiser les
responsabilits de chacun par rapport aux activits. Pour une activit particulire un DSI peut tre
responsable (R), garant (A), consult (C) ou simplement inform (I).
Les moyens de contrle proposs dans CobiT rpondent des objectifs de contrle. Ils mettent
en uvre un ensemble de mtriques permettant de juger de laccomplissement de lobjectif de
146
contrle. Un objectif de contrle est dfini au regard des buts mtier et des buts TI qui sont les
objectifs que se fixent les parties prenantes dans le cadre des processus de GSI.
Figure 6.2. Architecture de CobiT.
De manire gnrale, les processus de CobiT rpondent un ensemble de 28 buts

(ButCOBIT). Le niveau daccomplissement des buts est mesur suivant des indicateurs
(IndicateurCOBIT).
La figure 6.2 est un extrait du rfrentiel CobiT. Elle dcrit larchitecture du cadre daudit. On
peut identifier la position des buts du SI (IT goals) qui justifient les processus du SI (IT Processes).
Les processus du SI manipulent, transforment et produisent des ressources (IT Ressources) qui par
rapport aux objectifs mtiers (Business Goals), doivent rpondre un certain nombre de critres
qualitatifs sur linformation (Information Criteria).
6.2.1.2.2. Processus
CobiT contient une description par activit dans le guide de management. Chacun des
processus est dcrit suivant un patron de processus qui contient cinq macro-tapes. Les patrons de
CobiT pour chaque processus sont les suivants:
- Dfinir : ensemble des activits de prparation, didentification et de construction des

documents de support la planification et lordonnancement des activits suivantes
- Communiquer : ensemble des activits permettant dinformer les parties-prenantes, les
pilotes, les contrleurs et les acteurs du processus.
- Excuter : ensemble des activits de mise en uvre de la planification initiale
- Contrler : ensemble des activits de contrle. Elles se rapportent la recette du plan de
contrle initialement prvu.
- Amliorer : ensemble des activits de rorientation.
147
6.2.2. ITIL
ITIL (IT Infrastructure Library) est actuellement lapproche la plus largement adopte en
matire de gestion des services TI. Elle fournit un ensemble de directives sur les meilleures pratiques
de gestion des services TI. Le guide ITIL (Cartlidge, 2007) pose les principes cls de la gestion des
services.
Les sections suivantes prsentent plus prcisment les usages du rfrentiel ITIL et le mta-
modle que nous considrons dans cette tude.
6.2.2.1. Historique et usages du rfrentiel dITIL

ITIL a t conu sous limpulsion du gouvernement britannique, au dbut des annes 80. Il est
n de la ncessit damliorer les services des directions des systmes dinformation. Le but tait de
sensibiliser les DSI la qualit et la disponibilit de linfrastructure informatique qui a un impact
direct sur la performance globale dune entreprise.
Cest en premier lieu, lorganisme gouvernemental du CCTA (Central Computer and

Telecommunications Agency) qui a eu pour mission de dvelopper un ensemble de recommandations
pour amliorer lefficacit des services informatiques du secteur public. ITIL a t conu sur la base de
retour dexpriences des secteurs publics et privs. La premire publication dITIL (1989) a ainsi
volu avec des retours dexpriences pour atteindre 30 volumes en 1996.
En avril 2001, le gouvernement britannique annonce la fusion du CCTA avec lOGC (Office
Government Commerce), une subdivision du Her Majestys Treasury qui est en charge des
finances publiques et de la rgulation conomique au Royaume Uni. LOGC est le propritaire du
rfrentiel ITIL qui, en 2002, fait paratre une seconde version comportant 8 livres.
Aujourdhui, ITIL est un ensemble d'ouvrages recensant les bonnes pratiques pour la gestion
des services informatiques. Dans sa dernire version (V3) parue en 2007, le rfrentiel comporte cinq
ouvrages. Nous exposons ici la dmarche dITIL dans sa dernire version.
La figure 6.3 donne une description synthtique du contenu dITIL.
148
SKMS Systme de gestion des connaissances
des services
CMS Systme de gestion des configurations
Stratgie de Package de niveau de service (SPL)
service BD Catalogue des
Services AMIS CMIS ISMS
(portefeuille)
Package de conception des
Conception services(SDP)
Amlioration de service BD Contrats Contrat de niveau de service (SLA)
continue de fournisseur
Contrat de mise en uvre (OLA)
service
Transition de BD Gestion des Bibliothque des
configurations mdias
service
Mise en Demandes Enregistrement Enregistrement

de service des vnement des incidents
uvre de
service Enregistrement Erreurs
des problmes connues
Figure 6.3. Structure de lapproche dITIL.
La dmarche ITIL repose sur un ensemble de processus. La dernire version met laccent sur
la ncessit de considrer un service avec son cycle de vie. Les apports des cinq ouvrages sont illustrs
par la Figure 6.3 :
ITIL Service Strategy (Stratgie de service) : cet ouvrage est l'origine du cycle de vie
des services ITIL. La stratgie des services ITIL fournit des indications sur la
priorisation des investissements pour les prestataires de service dans les services. Plus
gnralement, la stratgie des services vise aider les organisations informatiques
amliorer et dvelopper leurs services sur le long terme. Les grands thmes abords
portent sur la valeur de service, le dveloppement des business case, les actifs des
services, lanalyse de march. Louvrage couvre trois processus : la gestion financire
des services, la gestion du portefeuille des services et la gestion de la demande.
ITIL Service Design (Conception de service) : cet ouvrage donne des conseils sur la
conception des services informatiques et des processus. La conception, au sein de
l'ITIL, est dfinie comme englobant tous les lments pertinents la prestation des
services de technologie, plutt que de se concentrer uniquement sur la conception de
la technologie elle-mme. En tant que tel, le recueil examine comment une solution de
service prvue interagit avec lentreprise et ses environnements techniques : les
systmes de gestion, les processus, la technologie et l'architecture qui sont ncessaires
pour soutenir le service. Le support la conception pour un service informatique est
adress dans le modle de conception des services (SDP). La conception des services,
ainsi que la documentation sur les services, sont grs au sein des catalogues de
149
services. Ce livre couvre la description de dix processus dont la gestion des niveaux de
service (SLA), la gestion du catalogue de service ou la gestion de la capacit.
ITIL Service Transition (Transition de service) : cet ouvrage porte sur la prestation des
services requis par une entreprise en condition oprationnelle, et met en valeur la
notion de projet pour la transformation des services. Ce domaine expose galement
des sujets tels que la gestion des changements. Ce livre comporte la description de six
processus dont la gestion de la connaissance, ou la gestion de la configuration des
actifs des services.
ITIL Service Operation (Mise en uvre de service) : louvrage liste les meilleures
pratiques pour la ralisation de la prestation des niveaux de services tels quils sont
conclus avec les utilisateurs finaux et les clients (la notion de client se rfre la
personne qui paie pour le service et ngocie les SLA). La mise en uvre du service,
tel que dcrit dans ce volume, est la partie du cycle de vie o les services dlivrent
directement de la valeur. Ainsi les suivis des problmes et des demandes sont pris en
considration. Ce livre comporte la description de cinq processus dont la gestion des
vnements, ou la gestion des incidents.
ITIL Continual Service Improvement (Amlioration continue de service) : cet ouvrage
dfinit les bonnes pratiques en matire damlioration continue des services. Il vise
aligner et raligner les services daprs les besoins dvolutions des entreprises. La
CSI vise amliorer l'efficacit des processus mtier, et l'efficacit et la rentabilit des
processus informatiques. Le livre dfinit ce qui doit tre contrl et mesur. Il
comporte la description de trois processus qui se rapportent la gestion des niveaux de
service, aux contrles et mesures des services et au processus damlioration continu
des services.
6.2.2.2. Conceptualisation dITIL

ITIL est le plus simple des rfrentiels de notre tude. Nous proposons de le dcrire par un
mta-modle (Figure 6.4). Dans les paragraphes suivants, les concepts sur la figure 6.4 apparaissent en
italique dans le corps de texte.
150
Document
associ
Application 0..* 1 manipule

0..*
Ressource 0..* 0..* Acteur
Matriel
0..* propritaire 0..*
Information
utilise
0..* 1 contient
mesure 1..* 1 documente
KPI Processus Service
1..* 1 0..*
Bonne pratique Service TI Service Mtier
1 1..* 1..*
mis en oeuvre par
1 1..* 1..*
dcrit 1..*
Volume Objectif Besoin mtier Besoin Client
1
Figure 6.4. Diagramme de classe des concepts dITIL.
ITIL est un corpus de conseils pour la gestion des services TI. Il se compose de cinq volumes.
Chaque volume dcrit des objectifs spcifiques pour la gestion des services. Ainsi le volume consacr
la stratgie des services se rapporte un type dobjectif consacr la gestion de ces services. Un
objectif comme la priorisation des investissements sur les services trouve une rponse dans la mise en
uvre des bonnes pratiques de la gestion financire des services et de la gestion des portefeuilles de
services. Une bonne pratique est une prconisation qui prend la forme dun processus et qui reprsente
les tapes ncessaires lobtention dun service. ITIL distingue le service mtier, du service TI : le
premier rpond des besoins client, et le second des besoins mtier. Un service ncessite un
ensemble de ressources (application, matriel, information, document) qui sont manipuls par des
acteurs. Un acteur peut tre le garant (propritaire) dune ressource.
6.2.3. COSO
COSO est un rfrentiel avant tout ddi la caractrisation des risques financiers et la mise
en uvre des contrles internes. Cest un rfrentiel transversal une organisation. Il concerne, ce
titre, lensemble des systmes de gouvernance. Il est utilis pour dfinir les risques inhrents au SI et
les activits de contrle associes.
Les sections suivantes prsentent plus prcisment les usages du rfrentiel COSO et le mta-
modle que nous considrons dans cette tude.
6.2.3.1. Historique et usages du rfrentiel COSO

COSO, issu des travaux de la Commission Treadway, est mis en place en 1985 aux Etats-Unis.
La commission avait pour mission de travailler sur le thme de la fraude dans le reporting financier.
Son rapport est publi en septembre 1987 et il constitue une base de recommandations pour prvenir et
dtecter ce type de fraude.
151
Le COSO (Committee Of Sponsoring Organizations) regroupe aux USA les associations et
instituts dans les domaines de la Comptabilit et de lAudit Interne qui ont soutenus les travaux de
cette commission. Le rfrentiel du COSO, rdig sur la base des recommandations de la commission
Treadway, est publi en 1992.
Plus prcisment, le rfrentiel COSO pose trois principes du contrle interne :
1. Le contrle interne est un processus : cest un mcanisme transversal qui ncessite

limplication des acteurs chaque niveau de lorganisation.
2. Le contrle interne doit vrifier quune organisation, dans son management est
respectueuse des lois.
3. Le contrle interne est modul suivant les priorits de ralisation des objectifs.
Les objectifs de contrle, que le COSO assigne, correspondent en majorit aux proccupations
des investisseurs assurant le financement des organisations. Pour COSO il sagit ainsi : dassurer
lefficacit et lefficience des oprations, la fiabilit des informations financires, et la conformit aux
lois et aux rglements.
Au regard des objectifs prcdemment tablis, COSO dcrit le cadre pour piloter le contrle
interne dune organisation. Il dcoupe ce cadre en cinq composants :
Lenvironnement de contrle : cest ltat des lieux de lorganisation, ses valeurs, qui
forment la situation pour les audits internes.
Lvaluation des risques : elle consiste mesurer limportance des risques, leurs
impacts sur les objectifs de lorganisation ainsi que leur frquence.
La dfinition des activits de contrle : COSO impose la matrialisation des
procdures de contrle. Il sagit de dfinir prcisment les rgles et procdures de
contrle pour traiter les risques.
Linformation et la communication : ces dernires sont ncessaires pour le partage de
la connaissance lie aux risques, aux contrles et la traabilit des reportings.
La supervision : elle consiste assurer la prennit des activits de contrle. Il sagit
du contrle du contrle interne.
Nous venons de prsenter le socle des objectifs du COSO ainsi que ses composants. La
reprsentation trs connue du COSO sous forme de cube trois facettes (Fig 6.5) permet de visualiser
la rpartition des objectifs et des composants du COSO sur la structure dune entreprise.
152
Figure 6.5. Le cube COSO
La dernire version du COSO (COSO II) met laccent sur la ncessit dintgrer les
informations et les risques non financiers au contrle interne en largissant la notion de reporting.
Dautre part, laxe de la communication et de linformation intgre maintenant la notion temps qui
permet aux audits de se rfrer une capitalisation de la connaissance passe des vnements. Enfin
les responsabilits sont soulignes par la dfinition du rle du comit directoire dans la supervision de
la gestion des risques et de celle du CRO (ou Directeur des Risques) qui a la responsabilit de
limplmentation de COSO.
Dans la section suivante nous prsentons le mta-modle de COSO.
153
6.2.3.2. Conceptualisation de COSO
a un effet sur
Probabilit
Activit de est surveille l'aide de
Action de
contrle traitement a un effet sur Impact
-benefice: int
-cot: int
peut donner lieu
affecte * rsulte en
donne lieu Cause
Risque rsiduel Evnement induit
Risque Occurence
d'vnement interdpendance
Risque inhrent Facteur
effet ngatif sur appartient

Opportunit
effet positif sur

Stratgie ralise
peut dterminer
Catgorie Origine du
1..* appartient d'vnement facteur
Objectif Catgorie
a un effet sur d'objectif
Conformit
aux lois
Tolrance Priorit
au risque Facteur Facteur Facteur
Fiabilit du interne externe
de succs reporting
a un effet sur ralise
dispose d'une
prend en compte Objectif
Apptence oprationnel
au risque dispose d'une
Entit Indicateur de Objectif
value performance stratgique
Partie affecte
prenante
Figure 6.6. Diagramme de classe des concepts de COSO (Sienou, 2007).
(Sienou, 2007) propose une formalisation des concepts du COSO. Nous reprenons le mta-
modle issu de ces recherches. La figure 6.6 mentionne les principales notions considres par le
COSO. Nous proposons une description textuelle de ce mta-modle. Dans la suite, les concepts de
COSO sont mentionns en italique.
Une entit se rfre lorganisation dfinie pour une mission donne qui consiste en la
ralisation dobjectifs qui supporteront une stratgie plus globale. Lentit dispose dune apptence au
risque. C'est--dire dune dfinition de ce qui est acceptable ou non en terme de risque au regard des
objectifs. A un instant donn, une entit dispose ainsi dune tolrance au risque. La caractrisation du
degr de ralisation des objectifs est rendu possible par lanalyse des indicateurs de performance qui
mesurent la capacit des objectifs satisfaire les facteurs de succs. COSO distingue quatre types ou
catgories dobjectifs : la conformit aux lois, la fiabilit du reporting, les objectifs oprationnels et
les objectifs stratgiques.
Un vnement peut avoir une origine endogne ou exogne suivant quil ait t induit par un
facteur interne ou un facteur externe. Lvnement est caractris par limpact et la probabilit de son
occurrence. Plus prcisment une occurrence est une manifestation capable daffecter positivement ou
ngativement la ralisation dun objectif. Dans le premier cas loccurrence dun vnement est
considre comme une opportunit et dans le second cas il sagit dun risque.
154
Une action de traitement est une action corrective ou prventive qui a pour effet de limiter le
risque initialement identifi. Une action prventive aura un effet sur la probabilit dapparition de
lvnement originaire du risque, alors quune action corrective consistera limiter limpact de
lvnement. Dans le cas o le risque ne peut tre totalement circonspect par une action de traitement,
cela donne lieu la considration dun risque rsiduel. Les risques et les actions de traitement sont
superviss par des activits de contrle.
6.3. Proposition de mtriques de correspondance conceptuelle

La correspondance entre modles a dj t trait notamment dans lingnierie de lalignement
mtier/SI. Lalignement a pour objectif de faire correspondre des modles mtier des modles SI.
(Etien, 2006) propose de mesurer un aspect de cet alignement sur le critre de compltude de
linformation. Nous drivons cette approche et nous proposons cinq mtriques pour mesurer la validit
de cette thse sur le critre de compltude conceptuel.
6.3.1. Nombre total des classes de modle

Cette mtrique mesure le nombre de classes dun modle. Elle est utile pour valuer
quantitativement la richesse conceptuelle des diagrammes de classes. Cest une fonction mathmatique
note NTCM de comptage de lensemble des lments de classe c de C prsent dans un modle M.
C'est--dire tel que :
NTCM (M)= card(c) [1]
6.3.2. Nombre des relations de correspondance entre deux modles

Cette mtrique mesure le degr de correspondance conceptuel entre deux modles Ma et Mb.
Elle repose sur une fonction de comptage du nombre des relations entre deux ensembles. Soit R, la
relation de correspondance entre lensemble A des concepts a de Ma et lensemble B des concepts b de
Mb
NRCM(Ma, Mb) = card(aRb) [2]
6.3.3. Degr relationnel dun modle

Le degr relationnel dsigne le nombre de concept a dun modle Ma intervenant dans une ou
plusieurs relations de correspondance avec les concepts b dun modle Mb cible. Le degr relationnel
repose ainsi sur la proposition logique suivante :
[3]
La formule [3] se lit littralement : le nombre de concept a de Ma tel quil existe une relation
liant a b .
155
6.3.4. Compltude conceptuelle
La Compltude conceptuelle au niveau gnrique permet de mesurer la proportion des
concepts dun mta-modle Ma qui participent une ou plusieurs relations de correspondance avec un
concept du mta-modle Mb. Cette mtrique donne une vision globale de la faon dont les concepts
manipuls par un modle rfr sont intgrs un modle rfrant. Une faible valeur pour cette
mtrique connote une faible dpendance conceptuelle du modle rfr par rapport au modle rfrant.
[4]
6.3.5. Charge conceptuelle

La Charge conceptuelle au niveau gnrique permet de mesurer la proportion des concepts
dun modle rfrant Mb intervenant dans un modle rfr Ma.
[5]
6.4. Comparaison de REFGOUV avec les rfrentiels de la GSI

Nous venons de prsenter les approches de CobiT, ITIL et COSO et nous avons fourni pour
chacun un mta-modle des concepts (Figures 6.1, 6.4 et 6.6). Le but de cette section est de comparer,
un niveau dabstraction identique, les mta-modles de CobiT, ITIL et COSO celui de
REFGOUV(Figure 4.4). Dans le cadre de cette comparaison, nous utilisons les mtriques [1, 2, 3, 4 et
5] prcdemment dfinies.
Pour chaque mta-modle compar REFGOUV, nous considrons une matrice danalyse
(exemple Figure 6.7 pour la comparaison REFGOUV-CobiT). Chaque matrice rsume les relations de
correspondance entre les concepts de REFGOUV et ceux du cadre de bonnes pratiques considr. Les
concepts de REFGOUV sont organiss en colonne, et, ceux des cadres de bonnes pratiques en ligne. Un
concept est marqu dun disque vid sil ne participe pas une relation. Un concept est marqu dun
disque plein sil participe au moins une relation. La matrice de correspondance mentionne par un
disque plein un lien de correspondance entre les concepts. Par exemple, sur la Figure 6.7, le concept
Ressource TI de CobiT correspond au concept Ressource de REFGOUV et nous mentionnons un disque
plein dans la cellule lintersection de la ligne du concept Ressource TI et la colonne du concept
Ressource. La zone infrieure de la matrice danalyse rsume les mesures de correspondance
conceptuelle entre le cadre de bonnes pratiques et REFGOUV.
Nous prsentons successivement les tudes des comparaisons de REFGOUV avec CobiT (
6.4.1), ITIL (6.4.2) et COSO (6.4.3). Nous concluons ltude par un bilan sur les forces
conceptuelles de REFGOUV et la validation dune de nos hypothses de travail (H1).
156
6.4.1. Mesures de correspondance conceptuelle entre CobiT et REFGOUV
Situation gnre
Situation prvue
Tableau de bord
Caractristique
Question CQG
Domaine GSI
Ajustement
Portefeuille
Ressource
Indicateur
Processus
REFGOUV
Catgorie
Mtrique
Situation
Dcision
Critre
Risque
Action
Projet
Mot
But
COBIT
ProcessusCOBIT
Contrle
Activit
Rle
Elment
Ressource TI
Objectif de contrle
But TI
But Mtier
ButCOBIT
But Activit
Domaine de Gouv.
Critre information
Mtrique
IndicateurCOBIT
Indicateur de but TI
Indicateur de but de
processus
Indicateur de perf.
Domaine
Niveau de maturit
Modle de maturit
Mesures
NTCM(REFGOUV) 21 NRCM(COBIT, REFGOUV) 17 DR(COBIT, REFGOUV) 17
NTCM(COBIT) 21 NRCM(REFGOUV, COBIT) 17 DR(REFGOUV, COBIT) 8
CoC(COBIT, REFGOUV) 81%
ChC(REFGOUV, COBIT) 38%
Figure 6.7. Rcapitulatif de la mesure de la correspondance conceptuelle REFGOUV-CobiT
La figure 6.7 rsume les concepts intervenants dans CobiT et dans REFGOUV. Les concepts
sont mapps lorsque cela est possible. Par exemple, un objectif pour CobiT correspondra au concept
de but pour REFGOUV.
Aprs comptage des concepts de REFGOUV, la mtrique NTCM prend la valeur 21

(NTCM(REFGOUV) = 21 sur la figure 6.7). Sur la figure 6.1 nous pouvons compter 21 concepts pour
CobiT (NTCM(CobiT) = 21 sur la figure 6.7). Les deux mta-modles sont ainsi quivalents en
richesse conceptuelle.
Le comptage en soi du nombre de concepts est reprsentatif de la richesse conceptuelle dun

modle. Cependant, il ne permet pas dvaluer le degr relationnel, c'est--dire la capacit dun
157
modle tre mis en relation avec les concepts dun autre modle. CobiT a un degr relationnel de 17
(DR=17). Sur la figure 6.7, cela consiste compter le nombre de concepts de CobiT marqus par un
cercle plein. Nous procdons de manire identique pour le degr relationnel de REFGOUV (DR=8).
Pour les 17 relations considres entre les concepts de CobiT et REFGOUV (NRCM=17), la
sollicitation des concepts de CobiT est plus importante que celle de REFGOUV et cela nous montre la
capacit de REFGOUV agrger les concepts de CobiT.
La charge conceptuelle de REFGOUV nous permet danalyser le degr de participation de

lensemble des concepts de REFGOUV dans leurs relations de correspondance avec les concepts de
CobiT. La charge conceptuelle de REFGOUV est de 38%. Il est ainsi pertinent daffirmer que les
concepts de CobiT ne sollicitent que 38% des concepts de REFGOUV.
La compltude conceptuelle de CobiT nous donne une indication supplmentaire. Les

concepts de CobiT participant la relation avec les concepts de REFGOUV reprsentent 81% des
concepts de CobiT. Il est ainsi pertinent daffirmer quune grande partie des concepts de CobiT
correspondent aux concepts de REFGOUV.
Nous montrons ainsi la puissance conceptuelle de REFGOUV, dune part dans sa capacit
intgrer les concepts dun rfrentiel de GSI trs connu (CobiT), et dautre part dans sa capacit
ltendre conceptuellement.
6.4.2. Mesures de correspondance conceptuelle entre ITIL et REFGOUV

La figure 6.8 rsume les concepts intervenant dans ITIL et dans REFGOUV. Les concepts sont
mapps lorsque cela est possible.
Par exemple, un objectif pour ITIL correspondra au concept de but pour REFGOUV. Sur la
figure 6.4 nous pouvons compter 16 concepts pour ITIL (NTCM(ITIL) = 16 sur la figure 6.8). ITIL est
ainsi plus pauvre en nombre de concepts que REFGOUV (21).
ITIL a un degr relationnel de 16 (DR=16). Sur la figure 6.8, cela consiste compter le
nombre de concepts de ITIL marqus par un cercle plein. Nous procdons de manire identique pour
le degr relationnel de REFGOUV (DR=7). Pour les 17 relations considres entre les concepts dITIL
et REFGOUV (NRCM=17), la sollicitation des concepts dITIL nous montre la capacit de REFGOUV
intgrer les concepts dITIL.
La charge conceptuelle de REFGOUV (figure 6.8) nous permet danalyser le degr de

participation de lensemble des concepts de REFGOUV dans leurs relations de correspondance avec les
concepts dITIL. La charge conceptuelle de REFGOUV est de 33%. Il est ainsi pertinent daffirmer que
les concepts dITIL ne sollicitent que 33% des concepts de REFGOUV.
158
Situation gnre
Situation prvue
Tableau de bord
Caractristique
Question CQG
Domaine GSI
Ajustement
Portefeuille
Ressource
Indicateur
Processus
REFGOUV
Catgorie
Mtrique
Situation
Dcision
Critre
Risque
Action
Projet
Mot
But
ITIL
Objectif
Volume
Bonne pratique
Processus
KPI
Service
Service TI
Service mtier
Besoin mtier
Besoin Client
Ressource
Acteur
Document
Application
Matriel
Information
Mesures
NTCM(REFGOUV) 21 NRCM(ITIL, REFGOUV) 17 DR(ITIL, REFGOUV) 16
NTCM(ITIL) 16 NRCM(REFGOUV, ITIL) 17 DR(REFGOUV, ITIL) 7
CoC(ITIL, REFGOUV) 100%
ChC(REFGOUV, ITIL) 33%
Figure 6.8. Rcapitulatif de la mesure de la correspondance conceptuelle REFGOUV-ITIL
La compltude conceptuelle dITIL nous donne une indication supplmentaire. Les concepts
dITIL participant la relation avec les concepts de REFGOUV reprsentent 100% des concepts
dITIL. Il est ainsi pertinent daffirmer que la totalit des concepts dITIL correspondent aux concepts
de REFGOUV.
intgrer la totalit des concepts du rfrentiel ITIL, et dautre part dans son importante capacit
ltendre (seulement 33% des concepts de REFGOUV sont sollicits).
6.4.3. Mesures de correspondance conceptuelle entre COSO et REFGOUV

La figure 6.9 rsume les concepts intervenant dans COSO et dans REFGOUV. Les concepts
sont mapps lorsque cela est possible. Par exemple, un objectif pour COSO correspondra au concept
de but pour REFGOUV.
159
Situation gnre
Situation prvue
Tableau de bord
Caractristique
Question CQG
Domaine GSI
Portefeuille
Ressource
Indicateur
Processus
REFGOUV
Catgorie
Mtrique
Situation
Dcision
Critre
Risque
Action
Projet
Mot
But
COSO
Activit de contrle
Action de traitement
Probabilit
Impact
Evnement
Cause
Facteur
Origine du facteur
Facteur interne
Facteur externe
Catgorie d'vnement
Occurrence d'vnement
Risque
Risque rsiduel
Risque inhrent
Opportunit
Stratgie
Objectif
Catgorie d'objectif
Conformit aux lois
Fiabilit du reporting
Objectif oprationnel
Objectif stratgique
Facteur de succs
Indicateur de performance
Entit
Priorit
Tolrance au risque
Apptence au risque
Partie prenante
Mesures
NTCM(REFGOUV) 20 NRCM(COSO, REFGOUV) 21 DR(COSO, REFGOUV) 21
NTCM(COSO) 30 NRCM(REFGOUV, COSO) 21 DR(REFGOUV, COSO) 7
CoC(COSO, REFGOUV) 70%
ChC(REFGOUV, COSO) 35%
Figure 6.9. Rcapitulatif de la mesure de la correspondance conceptuelle REFGOUV-COSO
Sur la figure 6.6 nous pouvons compter 30 concepts pour COSO (NTCM(COSO) = 30 sur la
figure 6.9). COSO est ainsi beaucoup plus riche en nombre de concepts que REFGOUV (21).
COSO a un degr relationnel de 21 (DR=21). Sur la figure 6.9, cela consiste compter le
nombre de concepts de COSO marqus par un cercle plein. Nous procdons de manire identique pour
le degr relationnel de REFGOUV (DR=7). Pour les 21 relations considres entre les concepts de
COSO et REFGOUV (NRCM=21), la sollicitation des concepts de COSO nous montre la capacit de
REFGOUV les intgrer.
160
La charge conceptuelle de REFGOUV (figure 6.9) nous permet danalyser le degr de
participation de lensemble des concepts de REFGOUV dans leurs relations de correspondance avec les
concepts de COSO. La charge conceptuelle de REFGOUV est de 35%. Il est ainsi pertinent daffirmer
que les concepts de COSO ne sollicitent que 35% des concepts de REFGOUV.
La compltude conceptuelle de COSO nous donne une indication supplmentaire. Les

concepts de COSO participant la relation avec les concepts de REFGOUV reprsentent 70% des
concepts de COSO. Il est ainsi pertinent daffirmer quune partie des concepts de COSO
correspondent aux concepts de REFGOUV.
intgrer une partie des concepts du rfrentiel COSO, et dautre part sa capacit ltendre.
6.4.4. Bilan de ltude comparative
Situation gnre
Situation prvue
Tableau de bord
Caractristique
Question CQG
Domaine GSI
Ajustement
Portefeuille
Ressource
Indicateur
Processus
REFGOUV
Catgorie
Mtrique
Situation
Dcision
Critre
Risque
Action
Projet
Mot
But
Rfrentiels compars
COSO
COBIT
ITIL
Mesures
NTCM(REFGOUV) 21 NRCM(*, REFGOUV) 55 DR(*, REFGOUV) 54
NTCM(*) 67 NRCM(REFGOUV, *) 55 DR(REFGOUV, *) 11
CoC(*, REFGOUV) 81%
ChC(REFGOUV, *) 52%
Figure 6.10. Bilan de ltude de la correspondance conceptuelle de REFGOUV avec les cadres de GSI.
Dans cette section nous avons compar les mta-modles de CobiT, ITIL et COSO au mta-
modle REFGOUV qui sont exprims un niveau conceptuel identique. Cette comparaison est
argumente et repose sur lvaluation de cinq mtriques [1, 2, 3, 4, 5] que nous avons proposes.
La figure 6.10 rsume les valuations des forces conceptuelles de chaque approche par rapport
REFGOUV.
Lors de cette tude nous avons compar 57 concepts, tous les cadres de GSI confondus, aux 21
concepts de REFGOUV. Sur ces 57 concepts, 44 sont en relation de correspondance avec 11 concepts
de REFGOUV. La compltude conceptuelle des cadres de bonnes pratiques est de 81% alors que la
charge conceptuelle de REFGOUV est de 52%. Cette tude nous rvle la capacit de REFGOUV
intgrer les concepts des cadres de bonnes pratiques ainsi qu les tendre.
161
Plus prcisment, nous constatons (Figure 6.10) que les cadres de bonnes pratiques ne
proposent pas de support conceptuel la dcision, et lvaluation des situations permettant aux
dirigeants des SI de pouvoir orienter et piloter les actions dvolution entreprendre.
Nous montrons aussi par les rsultats de cette tude, la capacit du mta-modle REFGOUV
traduire les concepts de gouvernance des SI. Nous validons ici notre premire hypothse : Le
domaine de la GSI manipule un ensemble dlments conceptualisables .
6.5. Evaluation de PROGOUV : le scnario PAPCAR
6.5.1. Synthse du cas

Le cas PAPCAR est un cas dcole (Nurcan, 2006). Son nonc est disponible en annexe de
cette thse. Il sagit dune situation de projet de dveloppement des SI utilise avec les tudiants de
deuxime anne de Master en Systme dInformation et des Connaissances. Lobjectif de ce cas est de
solutionner le problme des transformations du SI sur le court, moyen et long terme tout en assurant
lalignement du SI aux contraintes stratgiques et oprationnelles de lentreprise. Lnonc du cas
PAPCAR, tel quil est distribu aux tudiants, est insr en annexe de cette thse.
Nous proposons de rsoudre le cas PAPCAR en suivant les processus de GSI dcrit par
PROGOUV (voir Chapitre 5). Nous explorons le scnario prsent sur la figure 6.11
Par identification
(a) 1 des projets
1
Gouverner le
SI (b)
1 2

Par historisation
Figure 6.11. Scnario du cas PAPCAR pour la carte C de haut niveau.
Ce scnario consiste gouverner le SI de PAPCAR en identifiant les objectifs du SI

gnrateur de valeurs pour lentreprise, en construisant un portefeuille de projets pour rpondre ces
objectifs. La prise de dcision, dans notre cas, concerne la priorisation des projets dans un
environnement o les ressources sont limites. Nous dcrivons le scnario PAPCAR par les tapes de
choix de navigation lors du guidage de la carte. Chaque tape peut ainsi tre dcrite par un composant
de choix, un composant dexcution, et un composant descriptif :
Composant de choix : il dcrit la logique de guidage permettant daboutir lexcution

dune section de PROGOUV. Il utilise les directives tactiques (DSI et DSS).
162
Composant dexcution : il se rfre une section de PROGOUV. Il dcrit les activits
entreprendre lorsque la section peut tre applique aux activits de GSI, ou la carte
excuter lorsquil sagit dune section documente par une directive stratgique.
Composant descriptif : il dcrit la transformation effectivement opre pour la
rsolution du cas PAPCAR ainsi que les impacts sur le systme dinformation.
6.5.2. Etape 1 Initialisation du processus de GSI de PAPCAR

Lors de linitialisation, lintention Dbut de la carte C de PROGOUV est active.
6.5.2.1. Composant de choix

La situation impose lexcution des directives DSI-C.a et DSS-C.ab. Lexcution de la
directive DSI-C.a impose lexcution de la directive DSS-C.ab. Les buts de la GSI de PAPCAR ne
sont pas connus apriori, et il est ncessaire de les identifier. Dans cette situation, la directive DSS-C.ab
oriente vers le choix de la directive stratgique DAI-C.ab1.
6.5.2.2. Composant dexcution

DAI-C.ab1 : Gouverner le SI depuis Dbut par Identification des buts de GSI
La directive DAI-C.ab1 est de nature stratgique, elle est dcrite par la CARTE C.Cab1. Cette
directive a pour objectif de guider llaboration dun ensemble de buts, classs par catgorie et
assigns la gouvernance du systme dinformation.
Lexcution de cette directive nous oriente vers lexcution de la CARTE C.Cab1. Nous explorons le
scnario prsent la figure 6.12.
Fin (d)
1 Par analyse Par

Par analyse des 1 Identifier un but 1
linguistique compltude
gouvernance
Identifier la
catgorie de but
Dbut
(c)
(a)
Figure 6.12. Scnario du cas PAPCAR pour la carte C.Cab1.
6.5.2.3. Composant descriptif

Le composant dexcution est stratgique. Il sagit dexcuter la carte daffinement de la
section C-ab1. La description consiste exposer, puis dcrire, les tapes du scnario de la Figure
6.12.
163
6.5.2.3.1. Etape 1.1 Identification des buts de GSI pour PAPCAR
Lintention Dbut de la carte C.Cab1 de PROGOUV est active.
6.5.2.3.1.1. Composant de choix
Par analyse des 1 Identifier un but

gouvernance
Identifier la Connaissance
catgorie de but
Dbut
(c)
(a)
Par dfinition de 1
domaine
Par dfinition de 2
critre
DSI- C.Cab1.a : <(Connaissance.tat= jour), Progresser depuis Dbut>
Slectionner(DSS- C.Cab1.ab) Slectionner(DSS- C.Cab1.ac)
arg1 : Les priorits de gouvernance sont connues

arg2 : La gouvernance est dirig par ple de comptence
arg3 : La gouvernance est dirig par la performance
Figure 6.13. PAPCAR : Description de la directive DSI-C.Cab1.a.
La directive DSI-C.Cab1.a propose deux choix qui reposent sur la connaissance pralable du
plan stratgique de PAPCAR. La lecture de lnonc nous informe que la diminution des dlais de
livraison et celle des cots de production sont deux objectifs stratgiques pour PAPCAR. Nous
pouvons ainsi identifier les priorits pour la gouvernance des SI : aligner les SI sur les besoins
stratgiques de lentreprise et ses activits mtier. Cet tat nous guide, suivant largument arg1, sur la
slection de la directive DSS-C.Cab1.ab. Cette dernire noffre pas de choix stratgique.
164
6.5.2.3.1.2. Composant dexcution
DAI-C.Cab1.ab1 : Identifier un but de GSI depuis Dbut par Analyse des priorits de
gouvernance
Par analyse des priorits But

de gouvernance
1 Identifier un +ID: Integer
but de GSI (b) +description: String
Dbut +date: Date
(a)
DAI-C.Cab1 .ab1 : <(Connaissance.tat= jour), Identifier un but de GSI par analyse des
priorits de gouvernance>
1:<(Connaissance.tat= 2:<(Objectifs stratgique.tat=identifi),

jour), Identifier les objectifs Identifier les buts de GSI associs aux
stratgiques> objectifs stratgiques>
Figure 6.14. PAPCAR : Description de la directive DAI-C.Cab1.ab1.
6.5.2.3.1.3. Composant descriptif

Dans le cas de PAPCAR il sagit de solutionner un alignement du SI sur les processus mtier
et de crer de la valeur pour lorganisation. Les objectifs pour le SI sont ainsi dicts par la prise en
compte des objectifs mtiers. La lecture du cas permet de dgager lobjectif mtier de haut niveau qui
est de devenir le leader de la distribution de papier sur le march. Sa dcomposition est prsente la
figure 6.15.
De plus, la prise en compte unique des buts mtier nest pas suffisante. Il est ncessaire
dintgrer ltat courant du SI (Cartographie des applications) afin de cibler les lments applicatifs
modifier. Nous dfinissons ainsi un ensemble de buts SI satisfaire.
Lurgence du cas PAPCAR est dassurer la prennit de lentreprise en dveloppant les SI

pour faire diminuer les cots, les dlais et augmenter la qualit des produits et services. Dautre part,
afin de limiter la saturation des flux de trsorerie, la DSI doit investir de manire responsable dans les
projets et les prioriser. Ainsi un instant donn, la DSI ne peut effectuer quun projet la fois. Cela
suppose de mener des tudes de faisabilit et de dcider des orientations futures pour les portefeuilles
des projets SI.
Les objectifs de la figure 6.15 sont des buts mtier. Ils sont recenss dans le tableau 6.1 avec
les buts SI qui leur correspondent. Nous mentionnons galement le but de priorisation des
investissements sur les projets forte valeur ajoute qui porte sur la valeur des ressources.
165
Etre le leader de la
distribution de
papier sur le march
Se repositionner sur Offrir une livraison Optimiser la Assurer la prennit

Attirer la clientle
le march rapide fabrication de lentreprise
Maintenir les sites

Prparer les Sapprovisionner en
Dvelopper de Prospecter de industriels en
produits proximit matires premires
nouveaux produits nouveaux clients conditions
des clients au meilleur cot
oprationnelles
Entretenir la
Adapter loffre Donner des dates de Respecter les dates Fournir les produits motivation des
produit livraison fiables de livraison fixes finis de qualit ressources
humaines
Offrir un choix Optimiser

Etre ractif aux
couvrant les besoins Optimiser la gestion lexploitation des UP Maitriser lquilibre
demandes des
courants comme les des stocks selon le plan de financier
clients
demandes pointues charge
Ngocier les
conditions tarifaires
Figure 6.15. Les objectifs stratgiques pour le cas PAPCAR
6.5.2.3.2. Etape 1.2 Identification des catgories de buts pour PAPCAR

Lintention Identifier un but de GSI de la carte C.Cab1 de PROGOUV est active.
Par compltude
Par affinement Fin (d)
1
1
But Catgorie
Identifier un 1..* 1
but de GSI (b) Identifier la
Par analyse
linguistique catgorie de
but (c)
1
DSI-C.Cab1.a : <(((But.tat= jour) + (But.tat= identifi))

(Catgorie.tat=identifie)), Progresser depuis Identifier un but de GSI>
(arg1) (arg2)
(arg2) (arg1)
Slectionner(DSS-C.Cab1.bb ) Slectionner(DSS-C.Cab1.bd) Slectionner(DSS-C.Cab1.bc)

arg2 : Un but nest pas catgoris
Figure 6.16. PAPCAR : Description de la directive DSI-C.Cab1.b.
La directive DSI-C.Cab1.b. propose trois choix qui reposent sur la connaissance pralable des
buts. Ltape 1.1 du cas PAPCAR a permis didentifier ces buts. Ils permettent de couvrir lensemble
des besoins de GSI mais nont pas t catgoriss. Suivant les arguments prsents par la directive
166
(Fig. 6.16), nous avons le choix entre orienter le processus ProGouv vers lintention fin ou vers
lintention identifier la catgorie de but. Nous slectionnons la directive DSS-C.Cab1.bc. Cette dernire
noffre pas de choix stratgique.

DAI-C.Cab1.bc1 : Identifier la catgorie de but depuis Identifier un but de GSI par
Analyse linguistique
Lidentification de la catgorie dun but relve de la capacit tisser un rseau smantique des
termes utiliss pour lexpression des buts. Un ensemble de mots composant lexpression dun but peut
ainsi se rfrer un domaine de la GSI. Par exemple, lexpression Mettre en cohrence se
rapportera au domaine de lalignement . De manire identique, les mots peuvent se rfrer des
critres, comme par exemple le terme rapidement se rfrera un critre de performance .

En considrant lensemble des buts de plus bas niveau pour les activits mtiers, nous
identifions un ensemble de buts dalignement pour le SI. Le tableau 6.1 rsume lensemble de ces
buts.
But mtier But SI Domaine GSI Critre

Prospecter de nouveaux clients ADV : Assurer un support Alignement Performance
informationnel pour les prospects
Ngocier les conditions ADV : Mettre jour les bases tarifaires Alignement Performance
tarifaires en fonction de la politique de tarification
Etre ractif aux demandes des ADV : Assurer lintgrit des Scurit Performance
clients informations sur les commandes
ADV : Diminuer les dlais de Alignement Performance
transmission des informations sur les
commandes
ADV : Dmatrialisation des documents Alignement Performance
clients
Donner des dates de livraison ADV : Assurer lintgrit des Scurit Performance
fiables informations sur les livraisons
ADV : Diminuer les dlais de Alignement Performance
transmission des informations sur les
livraisons
ADV : Dmatrialiser les documents Alignement Performance
transporteur
Dvelopper de nouveaux Dvelopper les outils dassistance au Alignement Performance
produits design (CAO)
Dvelopper la base des connaissances sur Valeur Performance
les produits
Adapter loffre produit ADV : Assurer les modifications au Alignement Performance
catalogue
Offrir un choix couvrant les Dvelopper le catalogue en ligne des Alignement Performance
besoins courants et les produits courants
demandes pointues
ADV : Dvelopper lintranet de gestion Alignement Performance
des clients pour les demandes spcifiques
Prparer les produits ADV : Dvelopper un bus inter-UV pour Alignement Performance
167
But mtier But SI Domaine GSI Critre
proximit des clients le partage des connaissances sur les
disponibilits des stocks
ADV : Intgrer la go-localisation des Alignement Performance
commandes dans les composants
applicatifs
Respecter les dates de livraison Assurer la disponibilit des composants Alignement Performance
SI pour la livraison
Optimiser la gestion des stocks Dvelopper linterface GPAO/ADV Alignement Performance
Crer un SI centralis de gestion des
stocks
Sapprovisionner en matire Dvelopper le SI Achat Alignement Performance
premire au meilleur cot
Fournir des produits finis de Dvelopper le systme de contrle temps Alignement Performance
qualit rel
Optimiser lexploitation des UP Dvelopper le bus inter-UP Alignement Performance
selon le plan de charge
Maintenir les sites industriels Assurer la disponibilit du SI Alignement Performance
en conditions oprationnelles
Entretenir la motivation des Assurer la communication interne Valeur Performance
ressources humaines
Matriser les quilibres Justifier le budget des SI par mise en Valeur Performance
financiers place dune politique SLA
Prioriser les investissements sur les Valeur Ressource
projets forte VA
Tableau 6.1. Synthse des buts SI pour le cas PAPCAR
Sur le tableau 6.1 nous notons que la majeure partie des buts sont ddis la performance de
lalignement.
6.5.2.3.3. Etape 1.3 Finalisation de lidentification des buts pour PAPCAR

Lintention Identifier la catgorie de but de la carte C.Cab1 de PROGOUV est active.
Fin (d)
Identifier un but Par

1
compltude
de GSI (b) Catgorie
1 Identifier la
Par application CQG catgorie de but
(c)
DSI-C.Cab1.c : <(Catgorie.tat=identifie), Progresser depuis identifier la

catgorie de but>
(arg1) (arg1)
Slectionner(DSS-C.Cab1.cb) Slectionner(DSS-C.Cab1.cd)
Figure 6.17. PAPCAR : Description de la directive DSI-C.Cab1.c.
168
Les prcdentes tapes ont permis didentifier les buts de GSI, de couvrir lensemble des
besoins de la GSI et didentifier les catgories de but. Suivant arg1, il nest plus ncessaire de
progresser dans lidentification des buts de GSI. Lapplication de la directive nous oriente vers la
slection de la directive DSS-C.Cab1.cd. Cette dernire noffre pas de choix stratgique.

DAI-C.Cab1.cd1 : Finir depuis Identifier la catgorie de but par Compltude

Nous terminons ici le scnario didentification des buts de GSI pour le cas PAPCAR. Ltape
suivante consiste planifier le portefeuille des projets SI afin de satisfaire les objectifs identifis.
6.5.3. Etape 2 Initialisation du processus de planification des projets de

PAPCAR
Par identification
(a) 1
Gouverner le
SI (b)
Figure 6.18. Situation du scnario PAPCAR.
Nous venons dexcuter la section C-ab1 de la carte C de haut niveau. Lintention

Gouverner le SI (Figure 6.18) est maintenant active et elle nous permet denvisager la planification
des projets SI.
169
Par planification
des projets 1
*
Projet
Gouverner le But
*
2 0..1
SI (b) 0..1
< impacte <impacte
1
1 1
Action
Par historisation

(arg1) (arg1)
Figure 6.19. PAPCAR : Description de la directive DSI-C.b.
La directive DSI-C.b (Figure 6.19) propose deux choix qui reposent sur la connaissance
pralable des buts, des projets et des actions de gouvernance. Ltape 1 du cas PAPCAR a permis
didentifier les buts. Mais les actions de gouvernance nont pas encore t dfinies. Ainsi largument
arg1 nous guide vers la slection de la directive DSS-C.bb.
Par planification
des projets
1
Projet * * But
Gouverner le Par prise de dcision
SI (b)
DSS-C.bb : <(but.tat= jour ou projet.tat= jour), Progresser vers

Gouverner le SI depuis Gouverner le SI>
(arg ) (arg2)
1
Slectionner(DAI-C.bb1) Slectionner(DAI-C.bb2)
arg1 : Les buts sont exploitables

arg2 : Les projets sont exploitables
Figure 6.20. PAPCAR : Description de la directive DSS-C.bb.
La directive DSS-C.bb (Figure 6.20) propose deux choix qui reposent sur la connaissance
pralable des buts et des projets. Ltape 1 du cas PAPCAR a permis didentifier les buts. Mais les
projets nont pas encore t dfinis et ne sont pas exploitables. Ainsi les arguments arg1 et arg2 nous
guident vers la slection de la directive DAI-C.bb1.
170
DAI-C.bb1 : Gouverner le SI depuis Gouverner le SI par Planification des projets
La directive DAI-C.bb1 est de nature stratgique, elle est dcrite par la CARTE C.Cbb1. Cette
directive a pour objectif de guider llaboration dun ensemble de projets, didentifier les ressources,
processus et risques associs et danticiper les indicateurs de suivi pour les prises de dcision dans les
tapes ultrieures.
2
Par
portefeuille
Identifier Fin (e)

1
un projet (b) Par suivi
Par but 1
Dbut
Par cration Par GQM
(a) de tableau de
bord 1
1 Excuter un Par
projet(d) continuit
Identifier une 2
mesure(c)
Figure 6.21. Scnario du cas PAPCAR pour la carte C.Cbb1.

section C-bb1. La description consiste prsenter les tapes du scnario de la Figure 6.21.
171
6.5.3.3.1. Etape 2.1 Identifier les projets de PAPCAR
Lintention Dbut de la carte C.Cbb1 de PROGOUV est active.
Identifier
Par mise jour
un projet
(b)
2
Par but 1
Dbut But * Projet
(a) Par GQM Identifier *
une
2
mesure(c) Excuter un
1
projet(d)
Par reprise
Par reprise de
de mtriques
1 planification
DSI- C.Cbb1.a : <(Projet.tat= historis But.tat= identifi), Progresser

depuis Dbut>
(arg2)
Slectionner(DSS- C.Cbb1.ab) Slectionner(DSS- C.Cbb1.ac) Slectionner(DSS- C.Cbb1.ad)
arg1 : Besoin de (re)plannifier un projet

arg2 : Besoin de (re)planifier une mesure
Figure 6.22. PAPCAR : Description de la directive DSI-C.Cbb1.a.
La directive DSI-C.Cbb1.a (Figure 6.22) propose trois choix qui reposent sur la connaissance
projets nont pas encore t dfinis. Ainsi largument arg1 nous guide vers la slection de la directive
DSI-C.Cbb1.ab.
Par mise jour Identifier

un projet
2 (b)
But * Projet
Par but 1 *
Dbut
(a)
DSS- C.Cbb1.ab : <(Projet.tat= historis But.tat= identifi), Progresser

vers identifier un projet depuis Dbut>
(arg1) (arg2)
arg1 : Besoin de replanification dun projet existant

arg2 : Ncessit de construire un projet rpondant aux besoins de GSI
Figure 6.23. PAPCAR : Description de la directive DSS-C.Cbb1.ab.
172
La directive DSS-C.Cbb1.ab (Figure 6.23) propose deux choix qui reposent sur la connaissance
projets nont pas encore t dfinis. Ainsi largument arg2 nous guide vers la slection de la directive
DAI-C.Cbb1.ab1.

DAI-C.Cbb1.ab1 : Identifier un projet depuis Dbut par But
affin par >
0..*
But Projet
a caractristique
+description: String * * +date: Date 1 1..* +nom: String
Figure 6.24. PAPCAR : Composant de REFGOUV produit par DAI-C.Cbb1.ab1.
La directive DAI-C.Cbb1.ab1 impose didentifier les projets par regroupement des buts (Figure
6.24).

Lobjectif est de construire le corpus des projets suivant le processus PROGOUV ddi cette
activit. Une premire tape consiste dcouper, c'est--dire identifier le primtre des projets. Cette
identification repose sur les buts : un ensemble de buts SI correspond un projet.
De manire gnrale nous pouvons dune part, distinguer plusieurs zones pour les volutions
du SI sur la cartographie des applications et dautre part, associer ces volutions aux buts prsents
dans le tableau 6.1. Le tableau 6.2 prsente la distribution des projets identifis par rapport aux buts.
Nous distinguons deux types de projets : les projets au court terme, plus simple mettre en place, et
qui ne ncessitent pas dinvestissement de ressources importantes, et les projets au long terme, qui
sont rputs plus complexes. Les premiers projets sont majoritairement des projets dadaptation du SI
existant, alors que les seconds vont davantage modifier larchitecture et linfrastructure du SI.
173
6.5.3.3.2. Etape 2.2 Organiser le portefeuille des projets de PAPCAR
Lintention Identifier un projet de la carte C.Cbb1 de PROGOUV est active.
Par Par
Projet But
de composants
1 2
3
1 Par suivi 1..* * 1..*
Tableau de bord
projet (b) 2 1..*
*
1..*
un projet(d)
Par GQM value
mesure(c)

(arg2)

Figure 6.25. PAPCAR : Description de la directive DSI-C.Cbb1.b.
La directive DSI-C.Cbb1.b (Figure 6.25) propose trois choix qui reposent sur la connaissance
pralable des buts et des projets. Dans le cas de PAPCAR, les ressources limites, oblige considrer
lensemble des projets dans un portefeuille. Les projets sont incomplets dans leurs dfinitions. Ainsi
largument arg1 nous guide vers la slection de la directive DSS-C.Cbb1.bb.
Par Par
Projet But
de composants
1 2
3
1 Par suivi 1..* * 1..*
Tableau de bord
projet (b) 2 1..*
*
1..*
un projet(d)
Par GQM value
mesure(c)

(arg2)

Figure 6.26. PAPCAR : Description de la directive DSS-C.Cbb1.bb.
174
La directive DSS-C.Cbb1.bb (Figure 6.26) propose trois choix qui reposent sur la connaissance
pralable des projets. Dans le cas de PAPCAR, nous avons identifi cinq projets damlioration du SI
existant. Ainsi largument arg1 nous guide vers la slection de la directive DAI-C.Cbb1.bb2.

DAI-C.Cbb1.bb2 : Identifier un projet depuis Identifier un projet par Portefeuille
dcoup par >

0..1 1..*
Tableau de bord Projet

+ID: Integer +nom: String Portefeuille
1..*
+nom: String +date: Date +ID: Integer
1..* 0..*
Figure 6.27. PAPCAR : Composant de REFGOUV produit par DAI-C.Cbb1.bb2.
La directive DAI-C.Cbb1.bb2 prconise lorganisation dun agrgat de projets au sein dun

portefeuille (Figure 6.27).

Lensemble des projets SI du cas PAPCAR ont t identifis. Nous les organisons au sein de
portefeuilles de projets thmatiques (Tableau 6.2).
Le dveloppement des interfaces BtoC et BtoB : mettre en place les outils informatiques
ncessaires la communication avec le client/fournisseur. Il sagit dtre ractif et de prendre
les dcisions mtier en diminuant les dlais de transmission des informations. Cela peut passer
par la cration de solution CRM, dun site Internet pour les commandes avec une gestion de
profil client, des fonctionnalits de chat pour le SAV, ou de mettre en place une gestion
lectronique des documents.
Lamlioration des systmes oprants ADV/GPAO : sans remettre en cause linfrastructure de
base des SI (UV et UP), il sagit principalement damliorer les dlais et la ractivit en
travaillant sur les flux synchrones et asynchrones. Les flux dinformation forte valeur
doivent tre traits en temps rel et cela afin de limiter la dure dattente pour la disponibilit
des informations.
Lamlioration des systmes de reporting. Les dlais de traitement de linformation pour la
prise de dcision peuvent coter cher. Le reporting est ncessaire pour le sige social afin de
prendre les dcisions stratgiques mais il est aussi utile aux directions oprantes (UV et UP)
pour faciliter leur adaptation.
Interoprabilit des systmes oprants ADV/GPAO. Linteroprabilit nest pas un besoin
immdiat mais elle permettrait aux 20 units de vente davoir connaissance en temps rel de
ltat des autres UV/UP, de leurs stocks, et dadapter la distribution des livraisons pour
175
satisfaire le maximum de clients en cas de stocks de produits limits. De mme,
linteroprabilit des systmes entre les UP permettrait de pouvoir basculer les types de
production entre les sites industriels.
Amlioration des services du SI aux mtiers : la matrise de linformation et de la
communication entre les acteurs doit permettre la ractivit face aux vnements. Il sagit
aussi de fournir les outils adquats autorisant les acteurs partager la connaissance et
amliorer leur productivit.
176
Num But SI Portefeuille Projet au court terme Projet au long terme
ADV : Assurer les modifications au Dvelopper l'interface ADV
1 catalogue pour les catalogues
Assurer la communication interne Mise en place des services de
2 chat et visio-confrence
Assurer la disponibilit du SI Projet de cration des
3 serveurs de secour
Dvelopper la base des connaissances sur Mise en place d'une
les produits plateforme Wiki sur les
amlioration des services
4 produits
du SI aux mtiers
Dvelopper les outils dassistance au Appel d'offre aux diteurs
5 design (CAO) d'outils CAO
Justifier le budget des SI par mise en Ressencer les demandes des
6 place dune politique SLA mtiers
Dvelopper le SI Achat Dvelopper les outils et BDD Mise en place d'une
7 des services achat place de march
Assurer la disponibilit des composants Projet de cration des
8 SI pour la livraison serveurs de secour
Crer un SI centralis de gestion des Dvelopper les outils et BDD
Mise en place des
stocks du service national de gestion
modules ERP
9 des stocks
amlioration des systmes
Dvelopper le systme de contrle Amnager les interfaces
de reporting
temps rel GPAO/ADV pour Mise en place du
communiquer avec les SI des systme de pilotage
10 stocks
ADV : Assurer lintgrit des informations Authentifier les accs au
sur les commandes systme de gestion des
11 entrepts
ADV : Assurer lintgrit des informations Authentifier les accs au
sur les livraisons systme de destion des
12 entrepts
ADV : Assurer un support informationnel Dvelopper la BDD des Mise en place des
13 pour les prospects prospects modules CRM
ADV : Dvelopper lintranet de gestion
Dvelopper la BDD des
des clients pour les demandes
demandes client
14 spcifiques
ADV : Intgrer la go-localisation des
oprants ADV/GPAO Amliorer la BDD des
commandes dans les composants
commandes
15 applicatifs
ADV : Diminuer les dlais de transmission
Amliorer les flux
des informations sur les commandes
assynchrones
16
ADV : Diminuer les dlais de transmission
Amliorer les flux Mise en place des
des informations sur les livraisons
assynchrones modules ERP
17
ADV : Mettre jour les bases tarifaires en
Dvelopper le catalogue
fonction de la politique de tarification
national
18
ADV : Dmatrialisation des documents
Projet de dmaterialisation
19 clients
des factures, bon de livraison
ADV : Dmatrialiser les documents dveloppement des
et AR
20 transporteur interfaces BtoC et BtoB
Dvelopper le catalogue en ligne des Dvelopper le site Internet
21 produits courants des commandes
ADV : Dvelopper un bus inter-UV pour le
partage des connaissances sur les interoprabilit des
Mise en place des
22 disponibilits des stocks systmes oprants
modules SCM
23 Dvelopper linterface GPAO/ADV ADV/GPAO
24 Dvelopper le bus inter-UP
Prioriser les investissements sur les
25 projets forte VA
Tableau 6.2. Portefeuille des projets SI PAPCAR
177
6.5.3.3.3. Etape 2.3 Identifier les mtriques de suivi pour projets de PAPCAR

La directive DSI-C.Cbb1.b (Figure 6.25) propose trois choix qui reposent sur la connaissance
pralable des buts et des projets. Les projets sont complets dans leurs dfinitions, ils sont organiss
dans un portefeuille, mais aucune mtrique na t dfinie dans le but danalyser le portefeuille. Ainsi
largument arg2 nous guide vers la slection de la directive DSS-C.Cbb1.bc. Cette dernire directive ne
propose pas de choix et guide vers la slection de la directive DAI-C.Cbb1.bc1.

DAI-C.Cbb1.bc1 : Identifier une mesure depuis Identifier un projet par GQM
affin par >

0..*
But Mtrique
+valeur: String
Figure 6.28. PAPCAR : Composant de REFGOUV produit par DAI-C.Cbb1.bc1.
La directive DAI-C.Cbb1.bc1 prconise lidentification de mtriques par lapplication de la

mthode GQM (Goal Question Metrics). Elle oriente cette identification par la ncessit de poser une
question associe au but que lon considre (Figure 6.28).

La difficult du cas PAPCAR est de pouvoir anticiper les volutions futures et les dcisions
prendre lavenir. Il sagit didentifier les mtriques sur lesquelles les dcisions futures seront prises.
Nous considrons ainsi le but Prioriser les investissements sur les projets forte VA . Au regard de
ce but nous pouvons nous interroger sur les mtriques :
Quelle(s) mtrique(s) pour valuer linvestissement sur les projets ?

Quelle(s) mtrique(s) pour valuer la valeur ajoute dun projet ?
Nous pouvons ici identifier deux catgories de mtriques pour le cas PAPCAR : les mtriques
mtiers sur les dlais et les cots de revient qui vont reprsenter la valeur ajoute par un projet SI, et
les mtriques sur les projets SI. Ces dernires nous intressent plus particulirement car elles sont le
socle pour lorientation des planifications des projets dans un environnement ressources limites. Il
faut les prioriser suivant leur importance et la situation.
178
Nous utilisons ici les mtriques suivantes :
Budget du projet () : le budget est linvestissement financier allou lactivit dun

projet, ses ressources.
Charge du projet (j.h) : Cest une estimation de la charge de ralisation dun projet par
rapport aux participants
Nombre de participants (h) : nombre dacteurs assigns un projet
Dure (m) : la charge dun projet et le nombre de participants permettent destimer la
dure totale dun projet en mois.
Production dun projet (u.t) : nombre dunits de temps mtier dgags par un projet
SI. Cest la valeur ajoute que nous considrons pour un projet PAPCAR.
6.5.3.3.4. Etape 2.4 Construire le tableau de bord des projets de PAPCAR

Lintention Identifier une mesure de la carte C.Cbb1 de PROGOUV est active.
Par
2 indicateur
Par cration de
tableau de bord
Identifier 1..* 1..*
Mtrique But
1 une
a pour objectif
mesure(c)
Identifier
un projet 1
(b) Par mtrique de
composant projet
DSI- C.Cbb1.c : <(Mtrique.tat= identifi But.tat= identifi),

Progresser depuis Identifier une mesure>
(arg1) (arg2)
Slectionner(DSS-C.Cbb1.cc) Slectionner(DSS-C.Cbb1.cb)
arg1 : La mesure est incomplte dans sa dfinition

arg2 : Besoin dorganiser les mesures pour un projet
Figure 6.29. PAPCAR : Description de la directive DSI-C.Cbb1.c.
La directive DSI-C.Cbb1.c (Figure 6.29) propose deux choix qui reposent sur la connaissance
pralable des buts et des mtriques. Les mesures ont t identifies et il est ncessaire de les organiser
et de les adapter la situation particulire du portefeuille des projets SI. Ainsi largument arg2 nous
guide vers la slection de la directive DSS-C.Cbb1.cb. Cette dernire directive ne propose pas de choix
et guide vers la slection de la directive DAI-C.Cbb1.cb1.
179
DAI-C.Cbb1.cb1 : Identifier un projet depuis Identifier une mesure par Cration de
tableau de bord
Dcision Indicateur
+ID: Integer < repose sur +intitul: String
+description: String Tableau de bord +forme: Object
+date: Date 1..*
+valeur: Integer
+ID: Integer
+valeurMIN: Integer
1..* +nom: String
Projet +valeurMAX: Integer
+date: Date
1..* +date: Date
+nom: String
+date: Date
+axeRessource +axeProcessus +axeRisque +axeBut
Ressource Processus Risque But

+ID: Integer +ID: Integer +ID: Integer +ID: Integer
+Nom: String +Nom: String +Nom: String +description: String
+date: Date
Figure 6.30. PAPCAR : Composant de RefGouv produit par DAI-C.Cbb1.cb1
La directive DAI-C.Cbb1.cb1 prconise la construction dun tableau de bord. Elle oriente cette
construction par la prise en compte dun ensemble dindicateurs dont les axes danalyse sont associs
lvaluation des ressources, des risques, des buts et des processus (Figure 6.30).

Suivant les mtriques prcdentes nous construisons le tableau de bord (Tableau 6.3) pour
lensemble des projets. Les portefeuilles sont analyss sur trois axes : le cot (mesure du budget), la
valeur ajoute (mesure de la production du.t mtier) et les dlais (dure du projet). Dans la situation
de PAPCAR, le tableau de bord permet dvaluer les portefeuilles sur les axes ressource et processus.
Portefeuille Budget Participant Charge Production Dure

() (h) (j.h) (u.t) (m)
dveloppement des interfaces BtoC et BtoB
amlioration des systmes oprants
ADV/GPAO
amlioration des systmes de reporting
interoprabilit des systmes oprants
ADV/GPAO
Amlioration des services du SI aux
mtiers
Tableau 6.3. Tableau de bord des portefeuilles des projets SI PAPCAR
6.5.3.3.5. Etape 2.5 - Excuter les projets de PAPCAR

180
La directive DSI-C.Cbb1.b propose trois choix qui reposent sur la connaissance pralable des
buts et des projets. Les tapes prcdentes du cas PAPCAR nous ont permis didentifier le portefeuille
des projets et de construire le tableau de bord. Ainsi les arguments arg1 et arg2 (Figure 6.25) nous
guident vers la slection de la directive DSS-C.Cbb1.bd.
1 Par suivi
Identifier
un projet caractristique
(b) 2 a < value
Sans suivi 1..* *
1 *
Projet Mtrique
Excuter un
projet(d)
DSS- C.Cbb1.bd : <(Projet.tat= identifi Mtrique.tat= identifie),

Progresser vers excuter un projet depuis Identifier un projet>
(arg1) (arg1)
Slectionner(DAI-C.Cbb1.bd1) Slectionner(DAI-C.Cbb1.bd2)
arg1 : Il existe une mtrique planifie pour lvaluation des caractristiques du

projet excuter
Figure 6.31. PAPCAR : Description de la directive DSS-C.Cbb1.bd.
La directive DSS-C.Cbb1.bd propose deux choix qui reposent sur la connaissance pralable des
projets et des mtriques. Les tapes prcdentes du cas PAPCAR nous ont permis didentifier les
mtriques lies aux caractristiques de cot (budget), de qualit (production dunits de temps) et de
dlais (dure). Ainsi largument arg1 (Figure 6.31) nous guide vers la slection de la directive DAI-
C.Cbb1.bd1.
Indicateur
Mtrique
caractristique < value +intitul: String
+nom: String * * +description: String +valeur: Integer
1..*
a +date: Date
1
1..*
Projet Tableau de bord
+date: Date +nom: String
+description: String +date: Date
Figure 6.32. PAPCAR : Composant de REFGOUV produit par DAI-C.Cbb1.bd1
181
La directive DAI-C.Cbb1.bd1 (Figure 6.32) prconise de prendre en considration les mtriques
des caractristiques utiles la prise de dcision future. Pour cela, il est ncessaire davoir identifi les
mtriques associes aux caractristiques du projet.

Les projets SI sont dans un tat initial : ils sont identifis et correspondent des besoins
tablis. Lexcution correspond, ici, initier ltude de faisabilit de chacun des projets. Cette phase
nous permettra de complter et dvaluer les indicateurs du tableau de bord dans lobjectif dune prise
de dcision sur la planification court terme de lensemble des projets.
Ainsi le but Prioriser les investissements sur les projets forte VA (Tableau 6.1) ncessite
de planifier une prise de dcision aprs ltude de faisabilit des projets. Dautre part, la directive
DAI-C.Cbb1.bd1 nous oriente vers un recadrage du tableau de bord (Tableau 6.3) pour le suivi des
projets. Nous considrons le tableau de bord suivant (Tableau 6.4) :
Portefeuille Budget () Production (u.t) Dure (m)

dveloppement des interfaces BtoC et BtoB
amlioration des systmes oprants ADV/GPAO
amlioration des systmes de reporting
interoprabilit des systmes oprants
ADV/GPAO
Amlioration des services du SI aux mtiers
Tableau 6.4. Tableau de bord pour le suivi des portefeuilles de projets SI PAPCAR
6.5.3.3.6. Etape 2.6 Finaliser la planification des projets de PAPCAR

Lintention Excuter un projet de la carte C.Cbb1 de PROGOUV est active.

La directive DSI-C.Cbb1.d propose deux choix qui reposent sur la connaissance pralable des
projets. Les tapes prcdentes du cas PAPCAR nous ont permis didentifier le portefeuille des
projets, de construire le tableau de bord pour le suivi des projets et dexcuter les projets. Il est
ncessaire dvaluer les mtriques identifies dans lobjectif de dcider des priorits dinvestissement.
Ainsi largument arg2 (Figure 6.33) nous guide vers la slection de la directive DSS-C.Cbb1.de. Les
projets ne peuvent tre finaliss et cette dernire directive nous oriente vers la slection de la directive
DAI-C.Cbb1.de2.
182
Fin (e)
1
Par
finalisation Projet
Excuter un Par
projet(d) continuit
Identifier une 2
1
mesure(c) Par
adaptation
DSI- C.Cbb1.d : <(Projet.tat= en-cours), Progresser depuis Excuter un

projet>
Slectionner(DSS-C.Cbb1.dc) Slectionner(DSS-C.Cbb1.de)
arg1 : Une situation de mesure est identifie lors de lexcution dun projet
arg2 : Un besoin dvaluation survient
arg3 : Un projet a t termin
Figure 6.33. PAPCAR : Description de la directive DSI-C.Cbb1.d.

DAI-C.Cbb1.de2 : Finir depuis Excuter un projet par Continuit
Le processus sachve alors que le projet na pas abouti. La finalisation du projet est reporte
ou planifie un cycle ultrieur de gouvernance.

Ltude de la faisabilit des projets SI, au court terme pour PAPCAR, sachve et fournit une
valuation de lensemble des indicateurs envisags pour le portefeuille des projets (Tableau 6.5). Pour
chaque projet, les estimations de budget, de dure et de production sont fournies. Et pour chaque
portefeuille, les mtriques destimation sont agrges (total du portefeuille).
Notons lvaluation 0 pour le portefeuille Interoprabilit des systmes oprants

ADV/GPAO. Ceci est d labsence de projet court terme pour ce portefeuille.
183
Portefeuille Projet au court terme Budget () Production (u.t) Dure (m)
Dvelopper l'interface ADV
pour les catalogues 100000 200 1
Mise en place des services de
chat et visio-confrence 100000 200 1
Projet de cration des
serveurs de secour 75000 500 0,5
Mise en place d'une
plateforme Wiki sur les
amlioration des services produits 100000 250 1
du SI aux mtiers Appel d'offre aux diteurs
d'outils CAO 200000 250 0,5
Ressencer les demandes des
mtiers 50000 0 0,5
Dvelopper les outils et BDD
des services achat 100000 100 1
serveurs de secour 75000 500 0,5
Total du portefeuille 800000 2000 6
du service national de gestion
des stocks 200000 1500 3
amlioration des systmes Amnager les interfaces
de reporting GPAO/ADV pour
communiquer avec les SI des
stocks 200000 1500 3
Authentifier les accs au
systme de gestion des
entrepts 50000 200 1
systme de destion des
entrepts 50000 200 1
prospects 100000 750 1,5
demandes client 100000 750 1,5
oprants ADV/GPAO
Amliorer la BDD des
commandes 100000 750 1
Amliorer les flux
assynchrones 200000 1250 3
Amliorer les flux
assynchrones 200000 1250 3
national 100000 850 2
Projet de dmaterialisation 200000 1000 2
des factures, bon de livraison 200000 1000 2
dveloppement des
Dvelopper le site Internet
interfaces BtoC et BtoB
des commandes 200000 1000 2
interoprabilit des
systmes oprants
0 0 0
ADV/GPAO
Tableau 6.5. Estimation des performances des projets SI au court terme
184
6.5.4. Etape 3 Initialisation du processus de dcision des investissements
sur les projets PAPCAR
Par identification
(a) 1 des projets
1
Gouverner le
SI (b)
Figure 6.34. Situation du scnario PAPCAR.
Nous venons dexcuter la section C-bb1 de la carte C de haut niveau. Lintention

Gouverner le SI (Figure 6.34) est toujours active et elle nous permet denvisager la prise de
dcision pour les priorits dinvestissement sur les projets SI de PAPCAR.

Les composants de choix pour cette nouvelle situation ont dj t utiliss ltape 2. Il sagit
des directives DSI-C.b (Figure 6.19) et DSS-C.bb (Figure 6.20). Les actions de gouvernance ne sont
toujours pas envisages mais les projets sont exploitables dans lobjectif dune prise de dcision. La
directive DSS-C.bb nous oriente ainsi vers la slection de la directive DAI-C.bb2.

DAI-C.bb2 : Gouverner le SI depuis Gouverner le SI par Prise de dcision
La directive DAI-C.bb2 est stratgique elle est dcrite par la CARTE C.Cbb2. Cette directive a
pour objectif de guider la prise de dcision sur les projets par lanalyse des situations des processus,
des ressources, des risques et des buts et par observation dcarts en vue de proposer des actions
dajustement.
Par suivi
1 des projets
Identifier un but
Dbut dajustement de
(a) la gouvernance
SI (b)
4
Par valuation des

ressources
Prendre une
Dcision (c)
Fin (d)
3
Figure 6.35. Scnario du cas PAPCAR pour la carte C.Cbb2.
185
section C-bb2. La description consiste prsenter les tapes du scnario de la Figure 6.35.
6.5.4.3.1. Etape 3.1 Identifier les buts dajustement PAPCAR

Lintention Dbut de la carte C.Cbb2 de PROGOUV est active.

La directive DSI-C.Cbb2.a ne propose pas de choix et oriente vers la slection de la directive
DSS-C.Cbb2.ab (Figure 6.36).
Dbut Par suivi

1 des projets
(a) Situation
+ID: Integer
2
Identifier un but
Par adaptation dajustement de
vnementielle Situation gnre Situation prvue
la gouvernance
SI (b)
DSS- C.Cbb2.ab : <(Situation.tat= cre), Progresser vers Identifier un but

dajustement de la GSI depuis dbut>
(arg1) (arg2)
arg1 : Lvnement fortuit est gnr par un projet

arg2 : Lvnement fortuit est gnr par une entit externe
Figure 6.36. PAPCAR : Description de la directive DSS-C.Cbb2.ab.
La fin de ltude de faisabilit des projets gnre une nouvelle situation pour ltat des projets.
Les indicateurs pour le suivi des projets ont t valus. Largument arg1 de la directive nous guide
vers la slection de la directive DAI-C.Cbb2.ab1.

DAI-C.Cbb2.ab1 : Identifier un but dajustement de la gouvernance SI depuis Dbut par
Suivi des projets
186
Par suivi Projet 1..* Mtrique
1 des projets * a pour objectif
0..*
*
1..*
Identifier un but But < valuer
Dbut dajustement de
0..*
Situation
(a) la gouvernance
SI (b) Ajustement
DAI- C.Cbb2.ab1 : <(situation gnre.tat= cr , situation prvue.tat=mesure), Identifier

un but dajustement de la GSI par suivi des projets >
situation>
Figure 6.37. PAPCAR : Description de la directive DAI-C.Cbb2.ab1
La directive DAI-C.Cbb2.ab1 prconise les activits excuter dans lobjectif de formuler un

but dajustement (Figure 6.37).

Dans le cas de PAPCAR la situation gnre est reflte par le tableau de bord de suivi des
portefeuilles de projets. Elle correspond une situation planifie pour la prise de dcision sur les
priorits dinvestissement des projets.
Il sagit maintenant pour les dcideurs de se rapporter la stratgie de lentreprise afin de

dcider, parmi les projets, ceux qui seront immdiatement mis en uvre, et ceux qui seront
provisoirement suspendus.
Nous considrons ainsi le but dajustement suivant : dfinir une planification des projets
permettant de dgager 10000 u.t. mtier dans 24 mois .
Le but dajustement sinscrit dans la politique de lentreprise : il correspond la ncessit de

diminuer les dlais sur les processus mtier, et de permettre loutil de production de ragir plus
rapidement.
6.5.4.3.2. Etape 3.2 Dcider des priorisations des projets PAPCAR

Lintention Identifier un but dajustement de la gouvernance SI de la carte C.Cbb2 de
PROGOUV est active.

La directive DSI-C.Cbb2.b ne propose pas de choix et oriente vers la slection de la directive
DSS-C.Cbb2.bc (Figure 6.38).
187
Par valuation des
Identifier un but 4 risques
dajustement de But
la gouvernance +ID: Integer
Par valuation des +description: String
SI (b) ressources +date: Date
3
1 Prendre une
2 Par valuation des
Dcision (c)
Par valuation processus Ajustement
daccomplissement
du but
DSS- C.Cbb2.bc : <(Ajustement.tat=cr), Progresser vers Prendre une dcision depuis

Identifier un but dajustement de la GSI>
(arg1) (arg2) (arg3) (arg4)

Slectionner(DAI- Slectionner(DAI- Slectionner(DAI- Slectionner(DAI-
C.Cbb2.bc1) C.Cbb2.bc2) C.Cbb2.bc3) C.Cbb2.bc4)
arg1 : Lajustement porte sur un but
arg2 : Lajustement porte sur un processus
arg3 : Lajustement porte sur une ressource
arg4 : Lajustement porte sur un risque
Figure 6.38. PAPCAR : Description de la directive DSS-C.Cbb2.bc.
Le but dajustement a t identifi et correspond dans le cas de PAPCAR dgager des units
de temps pour les processus mtier. Il est ainsi ncessaire de se rapporter lvaluation des processus.
Largument arg1 de la directive nous guide vers la slection de la directive DAI-C.Cbb2.ab1.

DAI-C.Cbb2.bc2 : Prendre une dcision depuis Identifier un but dajustement de la
gouvernance SI par Evaluation des processus
drive
Indicateur
Mtrique
< value +intitul: String
0..* 0..* +description: String +valeur: Integer
+ID: Integer
0..*
Critre
+nom: String
Action Dcision
1..*
opportunits
+date: Date
Figure 6.39. PAPCAR : Composant de REFGOUV produit par DAI-C.Cbb2.bc2
La directive DAI-C.Cbb2.bc2 prconise de prendre une dcision en se rfrant aux mesures des
processus (Figure 6.39).
188
Conformment au composant dexcution, nous analysons la production des projets SI au
regard de leur apport la performance des processus mtier. Cela revient slectionner en priorit les
portefeuilles de projets SI afin de maximiser la vitesse de gain dunits de temps (u.t) pour loutil de
production.
Ltude sur la faisabilit des projets permet de dgager les informations suivantes (Tableau
6.6). Les portefeuilles dveloppement des interfaces BtoC et BtoB, et amlioration des systmes de
reporting sont les plus performants et produisent en moyenne 500 u.t./mois. Cependant, ils ne sont pas
suffisant pour permettre une production de 10000 u.t., conformment au but dajustement : dfinir
une planification des projets permettant de dgager 10000 u.t. mtier dans 24 mois .
Portefeuille Budget () Production (u.t) Dure (m)

dveloppement des interfaces BtoC et BtoB 600000 3000 6
amlioration des systmes oprants ADV/GPAO 900000 6000 14
amlioration des systmes de reporting 400000 3000 6
interoprabilit des systmes oprants ADV/GPAO 0 0 0
Amlioration des services du SI aux mtiers 800000 2000 6
Tableau 6.6. Estimation des performances des projets SI
Suivant le tableau 6.6, les indicateurs nous montrent quun investissement global de 1900000
permet de dgager 12000 u.t sur 26 mois. Soit un potentiel de 11076 u.t. sur 24 mois.Il sagit de
donner la priorit aux portefeuilles dveloppement des interfaces BtoC et BtoB, amlioration des
systmes oprants ADV/GPAO, et amlioration des systmes de reporting.
Dans limmdiat, PAPCAR ne peut investir que sur un seul projet. Et suivant la situation de
crise, il est judicieux de slectionner les projets les plus rentables. Cest le cas du portefeuille
amlioration des systmes de reporting : il est lun des deux portefeuilles les plus performant et
linvestissement est le plus faible (400 000 ). La dcision de donner la priorit aux projets du
portefeuille amlioration des systmes de reporting est prise.
6.5.4.3.3. Etape 3.3 Adapter les excutions des projets de PAPCAR

Lintention Prendre une dcision de la carte C.Cbb2 de PROGOUV est active.

La directive DSI-C.Cbb2.c (Figure 6.40) propose deux choix qui reposent sur la connaissance
pralable des dcisions. Dans le cas de PAPCAR, il sagit dorienter les actions pour moduler et
prioriser les projets. Ainsi largument arg1 nous guide vers la slection de la directive DSS-C.Cbb2.cd.
189
Prendre une
Dcision (c) 1
Par impact sur les 1
buts 2
Dcision
Sans impact Par analyse de TdB +ID: Integer
Fin +description: String
+date: Date
(d)
3 Par impact sur les
projets
DSI- C.Cbb2.c : <(Dcision.tat=prise), Progresser depuis Prendre une

dcision>
(arg1) (arg1)
Slectionner(DSS-C.Cb21.cd) Slectionner(DSS-C.Cbb2.cc)
arg1 : Il existe des actions identifies correspondantes la dcision
Figure 6.40. PAPCAR : Description de la directive DSI-C.Cbb2.c.
La directive DSS-C.Cbb2.cd (Figure 6.41) propose trois choix qui reposent sur la connaissance
pralable des dcisions et des actions. Dans le cas de PAPCAR, il sagit de suspendre les projets non
prioritaires. Ainsi largument arg2 nous guide vers la slection de la directive DAI-C.Cbb2.cd3.
Prendre une
Par impact sur les buts Dcision (c)
1 Dcision
2 +ID: Integer 1..*
Action
Sans impact +description: String +ID: Integer
Fin +date: Date oppotunits +description: String
(d)
3
DSS- C.Cbb2.bc : <(Dcision.tat=cr Action.tat=identifie), Progresser

vers Fin depuis Prendre une dcision >
(arg1) ((arg2) (arg1)) (arg2)
Slectionner(DAI-C.Cbb2.cd1) Slectionner(DAI-C.Cbb2.cd2) Slectionner(DAI-C.Cbb2.cd3)
arg1 : une action engendre des oprations sur les buts

arg2 : une action engendre des oprations sur les projets
Figure 6.41. PAPCAR : Description de la directive DSS-C.Cbb2.cd.

DAI-C.Cbb2.cd3 : Finir depuis Prendre une dcision par Impact sur les projets
190
Dcision
+ID: Integer
+date: Date
Ressource
opportunits
+ID: Integer 1..*
+Nom: String Projet
Action
+crer() +nom: String 0..1 1
+modifier() +date: Date +ID: Integer
1..*
+supprimer() <impacte +description: String
+crer()
Risque
+changerBut()
+ID: Integer +ajouterRessource() But
*
+Nom: String +retirerRessource()
1..* *
+ajouterRisque() +ID: Integer
+crer() +retirerRisque() +description: String
+moduler() +suspendre() +date: Date
+supprimer() +supprimer()
+crer()
+ModifierCatgorie()
Processus +Suspendre()
+ID: Integer +Supprimer()
+Nom: String
+crer()
+adapter()
+supprimer()
Figure 6.42. PAPCAR : Composant de REFGOUV produit par DAI-C.Cbb2.cd3
La directive DAI-C.Cbb2.cd3 prconise un ensemble doprations sur les concepts projet,

processus, ressource et risque (Figure 6.39). Ces oprations sont sollicites par des actions.

Suivant les contraintes de ressources et celles des projets SI actuellement en cours il est ainsi
ncessaire denvisager des actions au regard de la situation expose par le tableau de bord (Tableau
6.6). Nous envisageons ainsi de suspendre lensemble des projets SI et dinvestir les ressources et
personnels disponibles sur les projets damlioration des systmes de reporting.
La contribution des SI la performance mtier devrait ainsi permettre de dgager 3000 units
de temps en six mois, ce qui permettra une diminution des cots de revient et une augmentation de la
ractivit des processus mtier.
191
Portefeuille Projet au court terme Budget () Production (u.t) Dure (m) Action
Dvelopper l'interface ADV
pour les catalogues 100000 200 1 suspendre
Mise en place des services de
chat et visio-confrence 100000 200 1 suspendre
serveurs de secour 75000 500 0,5 suspendre
Mise en place d'une
plateforme Wiki sur les
amlioration des services produits 100000 250 1 suspendre
du SI aux mtiers Appel d'offre aux diteurs
d'outils CAO 200000 250 0,5 suspendre
Ressencer les demandes des
mtiers 50000 0 0,5 suspendre
des services achat 100000 100 1 suspendre
serveurs de secour 75000 500 0,5 suspendre
Total du portefeuille 800000 2000 6 suspendre
du service national de gestion
des stocks 200000 1500 3 actif
amlioration des systmes Amnager les interfaces
de reporting GPAO/ADV pour
communiquer avec les SI des
stocks 200000 1500 3 suspendre
Total du portefeuille 400000 3000 6 actif
systme de gestion des
entrepts 50000 200 1 suspendre
systme de destion des
entrepts 50000 200 1 suspendre
prospects 100000 750 1,5 suspendre
demandes client 100000 750 1,5 suspendre
oprants ADV/GPAO
Amliorer la BDD des
commandes 100000 750 1 suspendre
Amliorer les flux
assynchrones 200000 1250 3 suspendre
Amliorer les flux
assynchrones 200000 1250 3 suspendre
national 100000 850 2 suspendre
Projet de dmaterialisation 200000 1000 2 suspendre
des factures, bon de livraison 200000 1000 2 suspendre
dveloppement des
Dvelopper le site Internet
interfaces BtoC et BtoB
des commandes 200000 1000 2 suspendre
Tableau 6.7. Actions appliques aux projets SI
192
6.5.5. Finalisation du processus de GSI de PAPCAR
Par identification
(a) 1 des projets
1
Gouverner le
SI (b)
Par prise de dcision
Figure 6.43. Situation du scnario PAPCAR (tape 4).
Nous venons dexcuter la section C-bb2 de la carte C de haut niveau. Lintention

Gouverner le SI (Figure 6.43) est toujours active et nous venons dappliquer des actions de
gouvernance visant planifier les investissements sur les projets SI. Cela nous permet denvisager la
finalisation du processus de gouvernance et de capitaliser la connaissance sur les actions entreprises.

Les composants de choix pour cette nouvelle situation ont dj t utiliss ltape 2. Il sagit
de la directive DSI-C.b (Figure 6.19).
Par planification
des projets 1
*
Projet
Gouverner le But
*
2 0..1
SI (b) 0..1
< impacte <impacte
1
1 1
Action
Par historisation

(arg1) (arg1)
Figure 6.44. PAPCAR : Directive DSI-C.b permettant de progresser depuis gouverner le SI
193
< repose sur
Gouverner 1..*
1..*
le SI (b) Action
1 1 1
1..*
oppotunits < impacte 0..1
Fin But
(c) Par historisation
1..* 0..*
* value * <impacte 0..1

Indicateur
1..* Projet
DAI-C.bc1 : <(action.tat= jour ou ProcessusGSI.dateFin<=Date.TODAY), Finir par

historisation>
1:<(action.tat= jour), 3:<(action.tat= jour et

2:<(Dcision.tat=analyse),
analyser les situations ProcessusGSI.dateFin<=Date.TODAY),
dater les tats de la situation>
de dcision> dater les tats des projets>
2.1:<(Dcision.tat=analyse)
2.2:<(Dcision.tat=analyse) 2.3:<(Dcision.tat=analyse)
, dater les tats des
, dater les tats des actions> , dater les tats des buts>
indicateurs>
Figure 6.45. Directive DAI-C.bc1 permettant de finir par historisation

Ltat des projets de PAPCAR, les dcisions et les indicateurs sont dats afin de construire le
socle des connaissances sur le cycle de gouvernance SI.
Nous terminons ainsi ltude de cas PAPCAR. La section suivante permet de mettre en valeur
les apports de cette tude de cas aux soutiens de nos hypothses de travail.
6.5.6. Bilan du cas PAPCAR

Nous venons de montrer avec le traitement du cas PAPCAR la faisabilit des processus
PROGOUV. Ce cas nous a permis de dcrire un scenario dexcution du processus guid de
gouvernance SI. Cela dans lobjectif de satisfaire des buts de performance de lalignement mtier/SI.
La figure 6.46 prsente la structure du SI rsultant de lapplication des processus PROGOUV.
194
a pour objectif
< repose sur
Ajustement
Dcision
+ID: Integer
+description: String Situation prvue
+date: Date Situation drive
1..*
+ID: Integer 0..* < valuer
Situation gnre Mtrique
< gnre +ID: Integer
opportunits 0..* 0..* +description: String
+dim: Object
1..* * +valeur: String
< value
Action
0..*
+ID: Integer
*
Portefeuille caractristique Indicateur

1
< value
+ID: Integer +nom: String +intitul: String
+forme: Object
a 1..* +valeur: Integer
+valeurMIN: Integer
0..* 0..* 1 0..* +valeurMAX: Integer
1..* 1..* +date: Date
<impacte Projet Risque Ressource Processus
But 0..1 +nom: String +ID: Integer 1..*
1..* * +ID: Integer +ID: Integer
+date: Date 1..* +Nom: String
+ID: Integer 1..* +Nom: String +Nom: String
Catgorie 1 1..* * +description: String
+description: String 0..*
+date: Date
1..* 0..1
dcoup par >
affin par > +axeProcessus
+axeRessource Tableau de bord
+axeRisque
+ID: Integer
Domaine GSI
+nom: String
+nom: String +date: Date
0..* 1..*
+axeBut
1..*
0..*
Mot
Critre 0..* +intitul: String

+dfinition: String
0..*
+nom: String
Figure 6.46. Structure pour le SI de gouvernance du cas PAPCAR.
Dans le cas PAPCAR nous avons pu mettre en vidence seize tapes du processus de GSI.
Chacune de ces tapes est dcompose en un lment de choix pour la dcision de guidage, un lment
dexcution qui est la description du modle de section PROGOUV appliquer et un lment descriptif
qui consiste instancier le modle de processus PROGOUV la situation de PAPCAR. Nous montrons
ainsi en quoi le processus de GSI est intentionnel et dcisionnel et en quoi PROGOUV permet de
conceptualiser le processus de GSI. Nous validons ainsi notre hypothse H12 qui se rapporte la
conceptualisation du processus de GSI.
La figure 6.46 propose un modle de spcification pour le SI de gouvernance de lentreprise

PAPCAR. Il est justifi par les activits de gouvernance que nous avons ralises dans le cadre de
cette tude de cas. Nous validons ainsi notre hypothse H2 qui se rapporte la qualit du SI de
gouvernance.
6.6. Positionnement de la Mthode dIngnierie des SI de Gouvernance

La Mthode dIngnierie des SI de Gouvernance (MISIG), que nous proposons dans cette
thse, a t dmontre, par lexemple, sur le cas PAPCAR. Elle consiste en une slection des concepts
de REFGOUV par les intentions et la situation des dirigeants en matire de GSI. PROGOUV est le
mcanisme qui permet de tracer les concepts instancier au regard de ces intentions.
195
Afin dclairer au mieux notre apport, nous proposons dvaluer MISIG sur le cadre de
rfrence des quatre mondes propos au chapitre 2 (c.f. 2.3.2).
Le rsultat du positionnement de MISIG est prsent au tableau 6.8. On observe que les
couvertures des facettes DECISION et de celles du monde de lusage sont totales. Cela se justifie par le
processus tlonomique propos dans PROGOUV qui permet de construire dynamiquement le corpus
de buts, et ainsi, denvisager nimporte quel type de dcisions sur le portefeuille de projets.
Plus prcisment, MISIG permet de spcifier un systme de gouvernance qui se base sur
lanalyse des carts entre ce qui est planifi et ce qui est constat. Cela fait de MISIG un systme de
GSI qui supporte les CHANGEMENTS volutifs. Cependant MISIG est faible au regard de la facette
ORGANISATION DE LA GOUVERNANCE : en effet le manque de formalisation des acteurs dans nos
modles ne permet pas de tracer la responsabilit des acteurs en matire de dcision.
Cadre des quatre mondes Approches de la gouvernance des systmes dinformation

Monde Facette CobiT COSO ITIL MISIG
Sujet ORGANISATION
DE LA * * - -
GOUVERNANCE
DECISION - - Infrastructure *
PROCESSUS IT * * * *
PROCESSUS
- * * -
METIER
CHANGEMENT * - volutif volutif
PORTEFEUILLE
- - * *
DE PROJETS SI
Usage MINIMISER
* * qualit *
LES RISQUES
ATTEINDRE
LETAT - - Evolution SI *
DALIGNEMENT
OBTENIR
LA - - - *
PERFORMANCE
CREER DE LA Patrimoine Patrimoine SI,
- *
VALEUR mtier usage
Systme CONTENU document document document document
Processus, Processus, Processus,
MODELE *
objet objet objet
Risque,
Alignement,
METRIQUES performance, risque *
performance
valeur
Dveloppement NATURE
systmatique systmatique systmatique systmatique
DES PROCESSUS
MATURITE
* - - *
DES PROCESSUS
CAPITALISATION
DE LA externalisation externalisation externalisation externalisation
CONNAISSANCE
LOGICIEL * * * -
Tableau 6.8. Synthse du positionnement de MISIG.
196
Au regard des autres approches, MISIG est le plus complet sur le monde du systme : il repose,
comme nous avons pu le voir prcdemment, sur des MODELES de dcision et dvolutions.
Sur le monde du dveloppement, MISIG est quivalent aux autres approches. Cependant, nous
navons introduit les outils des processus (LOGICIEL) de MISIG qu ltape de spcification.
6.7. Conclusion
Dans ce chapitre, nous avons pu valider nos hypothses de travail et montrer les avantages des
mta-modles proposs, REFGOUV et PROGOUV. Nous rappelons nos hypothses de travail :

o H11 : Le domaine de la GSI manipule un ensemble dlments
conceptualisables.
o H12 : Le processus de la GSI est conceptualisable.

Dans un premier temps, nous avons valu la puissance conceptuelle du mta-modle

REFGOUV par rapport aux rfrentiels de GSI les plus connus (CobiT, ITIL et COSO). Cette
valuation repose sur la proposition de cinq mtriques qui permettent de juger des correspondances
conceptuelles entre plusieurs mta-modles. Nous avons considr les mta-modles de CobiT, ITIL,
et COSO. Nous avons ainsi prouv, en utilisant des mtriques dalignement conceptuel, la capacit du
modle REFGOUV reprsenter les concepts du domaine de la GSI. Nous avons galement montr, au-
del de sa capacit dintgration, que REFGOUV permet galement dtendre, par les concepts, les
dmarches de GSI comme CobiT, ITIL, ou COSO.
Le cas PAPCAR nous a permis de montrer la manire dont les processus PROGOUV
permettent de manipuler les concepts de REFGOUV. La finalit est lingnierie dun SI contenant les
lments cls, pour une situation particulire de gouvernance des SI. Dans le cas de PAPCAR il
sagissait, sur un cycle de gouvernance en seize tapes, de dcider de lordre de priorit des projets SI.
Nous avons ainsi prouv la capacit de PROGOUV conceptualiser les processus de la GSI et sa
capacit produire un SI de gouvernance spcifique.
Nous validons ainsi nos hypothses de travail. La section suivante conclut nos travaux et
propose des perspectives de recherche prometteuses.
197
Chapitre 7. Conclusion
7.1. Contributions
Cette thse a fait un double constat. Tout dabord, des tudes ont montr que les besoins des
professionnels en matire de gouvernance des SI portent sur lintgration plus aise des cadres de
bonnes pratiques aux situations particulires des entreprises. Dautre part, les recherches actuelles ne
proposent pas de solution pour construire un systme dinformation correctement urbanis pour
soutenir lensemble des activits de la GSI. Lanalyse de la littrature vient appuyer ce constat et
montre que la dmarche dimplmentation des SI de gouvernance est avant tout fonctionnelle, et
calque sur un mode de rsolution en silos. Ainsi la GSI nest jamais perue dans une vision globale
pour pouvoir concevoir un SI de gouvernance.
Nous avons ainsi formul le problme suivant : Quelle conceptualisation de la gouvernance

des SI pour la construction dun SI de gouvernance ?
Cette formulation induit des hypothses fortes sur la capacit des artfacts de la GSI tre
conceptualisables. Fort de ces hypothses nous avons dress un cadre de rsolution bas sur des
langages de modlisation informatiques. Nous avons ainsi propos REFGOUV, qui est exprim dans le
langage UML. Il construit larchitecture des concepts de la GSI. PROGOUV est notre deuxime
proposition conceptuelle : il est exprim dans le langage de la CARTE et permet de construire le cadre
dynamique pour la manipulation des concepts de REFGOUV. La force de notre approche est quelle
intgre un cycle de gouvernance comme un processus dcisionnel et intentionnel qui se base sur
lanalyse des carts entre une situation de gouvernance prvue et une situation constate. Les dcisions
y ont un impact endogne sur le portefeuille des projets SI et les objectifs de la gouvernance.
Les propositions de REFGOUV et PROGOUV ont finalement t confrontes des mcanismes

dvaluation. REFGOUV a fait lobjet dune confrontation de ses concepts par rapport ceux des
standards CobiT, ITIL et COSO. Il ressort de cette tude que REFGOUV a la capacit, non seulement
dintgrer les concepts des cadres de bonnes pratiques, mais aussi de les tendre. Le modle PROGOUV
a t expriment sur le cas PAPCAR et nous montrons ainsi sa capacit implmenter un scnario
prcis pour la gouvernance des SI. Les valuations menes plaident ainsi en faveur de notre
proposition pour un cadre conceptuel qui aboutit produire un SI de gouvernance adaptable et
urbanis.
Notre contribution permet de capitaliser la connaissance du domaine de la GSI et denvisager

la construction dun SI ddi aux activits de gouvernance des SI.
199
7.2. Perspectives de recherche
Les perspectives de recherche sont prometteuses. Elles trouvent leurs justifications dans la
prcision des concepts prsents dans cette thse, mais aussi sur lenvironnement des domaines de
recherche et la pratique de la gouvernance des SI. Nous pouvons ainsi numrer les questions
suivantes :
Cette thse est-elle suffisante pour explorer les concepts de la GSI en profondeur ?
Lextension et laffinement des concepts de cette thse peuvent faire lobjet de recherches.
Nous envisageons plusieurs pistes que nous prsentons ici.
La dcision dans cette thse repose sur lanalyse des carts. Cest une dcision argumente
mais on peut se poser la question de limpact du mode argumentaire (ou non-argumentaire) sur la
modlisation du SI.
Nous avons galement propos un ensemble de mtriques tant pour la GSI que pour
lvaluation de REFGOUV et PROGOUV. Dautres mtriques peuvent tre proposes et il existe des
mthodes didentification. Le challenge ne rside pas dans lidentification dun corpus de mtriques
pour un besoin prcis, mais plutt dans lvaluation de la qualit des mtriques proposes au regard
dun besoin dvaluation.
Nous avons, dans cette thse, abord la notion daction, mais il savre quelle a, au regard de
REFGOUV, un impact endogne sur le systme de GSI. Ainsi on peut aussi envisager ltude de la GSI
sous un angle exogne. Par exemple : quel est limpact des dcisions de la GSI sur le systme de
gouvernance dentreprise ou de la gouvernance des ressources humaines ? La cyberntique, comme
science de lanalyse des relations entre les systmes, peut-elle apporter des pistes dinvestigation ?
PROGOUV permet de dfinir un guidage situationnel, intentionnel et dcisionnel de la GSI.

Cependant le formalisme est limit dans la reprsentation des acteurs et des rles. Une extension
possible est dintroduire la notion de rle.
Les concepts de notre proposition sont-ils suffisamment prouvs ?
Dans cette thse, nous avons procd deux types dvaluation de nos propositions : une
validation par la mesure dquivalence conceptuelle et une validation par lexemple et la simulation.
Cependant notre contribution na pas fait lobjet dune tude de fond en situation relle. Ainsi,
dautres validations doivent tre menes par lexprimentation et les tudes empiriques.
200
Lingnierie des SI pour des systmes dintelligence comme nouveau domaine de
recherche ?
La gouvernance des SI sapparente aux autres formes de gouvernance : les gouvernances

dentreprise, mtier, financire, universitaire, militaire, dEtat, mondiale ont toutes pour singularit
dtre des systmes pour la planification des objectifs, des dcisions et de leurs excutions dans
lintention de faire voluer le propos quelles traitent. Ces intentions dvolution sont toujours mises
dans le contexte du temps suivant quelles portent sur des volutions court, moyen ou long terme.
Les systmes experts et les systmes intelligents constituent en soi une contribution des
domaines mathmatiques et informatique par le fait quils supportent la prise de dcision. Mais ils ne
desservent quun besoin particulier de la gouvernance. Par ailleurs, les recherches actuelles sur des
modes de gouvernance spcifiques (SOA Governance, e-government) aboutissent au
dveloppement de systmes dinformation propres ces domaines. Nous avons encore une fois une
rponse fonctionnelle un besoin prcis.
Ainsi aucun domaine de recherche en informatique nadresse un primtre assez large pour
tudier lingnierie des systmes (dinformation) de systme (dintelligence).
201
Rfrences Bibliographiques
(AFAI, 2002) AFAI, ITGI, COBIT, Gouvernance, Contrle et Audit de lInformation et des
Technologies Associes, Troisime dition, 2002.
(Agostinelli, 2009) S. Agostinelli, Lanalyse du processus mtier au coeur du systme dinformation
oriente le projet d'intelligence conomique. In, M., Ghenima, A., Ouhsel & S., Sidhom, (eds.).
SIIE2009 : 2e Confrence Internationale Systmes dInformation et Intelligence Economique,
(pp. 254-271). Nancy : IHE ditions, 2009.
(Akrich, 1993) M. Akrich, Les objets techniques et leurs utilisateurs, de la conception laction, in
Raisons pratiques, n4,"Les objets dans l'action" pp.35-57, 1993.
(Allmendinger, 2005) G. Allmendinger, R. Lombreglia, Four strategies for the age of smart services,
Harvard business review, vol. 83, S. 131-4, 136, 138, 2005.
(Alonso, 1997) G. Alonso, D. El Abbadi, C. Mohan, Functionality and Limitation of Current
Workflow Management Systems, IEEE Expert, 1997.
(Aloui, 2007) A. Aloui, S. At-el-Hadj, A. Bouazzi, Mthodologie de conception Etat de lart et
ingnierie de dveloppement, congrs international CMSM conception et modlisation des
systmes mcaniques . Monastir, TUNISIE. 19-21/03/2007.
(Basili, 1994) Basili V. R., Caldiera G., Rombach H. D., The Goal Question Metric Approach, in
Encyclopedia of Software Engineering, John Wiley & Sons, Inc., p. 538-542, 1994.
(Ben Zada, 2007) Ben Zada Y., Chapurlat V., Crestani D., Construction et valuation de projet de
changement des entreprises manufacturires, GDR I3, MACS, 2007.
(Bergenti, 2000) Bergenti, F. and Poggi, A., Exploiting UML in the design of multi-agent systems. In
Engineering Societies in the Agents World, edited by Omicini, A., Tolksdorf, R., and
Zambonelli, F., Lecture Notes in Computer Science (Springer), pp. 106-113, 2000.
(Bergeron, 2004) F. Bergeron, L. Raymond et S. Rivard, Lalignement stratgique des TI et la
performance des PME, 9me Colloque de l'AIM, Evry, 2004.
(Berthoz, 2003) A. Berthoz, La dcision, Ed. Odile Jacob, 2003, ISBN 9782738111029.
(Bessai, 2008) K. Bessai, B. Claudepierre, O. Saidani, S. Nurcan, Context-aware Business Process
Evaluation and Redesign, The 9th Workshop on Business Process Modelling, Development,
and Support (BPMDS'08, (in association with the CAISE'08 Conference), CEUR (pub), June
16-17, 2008, Montpellier, France.
(Booch, 2000) G. Booch, J. Rumbaugh, I. Jacobson, Le guide de l'utilisateur UML, 2000, ISBN 2-212-
09103-6.
(Brand, 2008) K. Brand, H. Boonen, IT Governance Based on Cobit 4.1: A Management Guide, 3me
edition, Van Haren Publishing, 2008, ISBN 908753116.
(Briol, 2008) P. Briol, BPMN, the Business Process Modeling Notation Pocket Handbook, LuLu.com,
2008. ISBN 978-1-4092-0299-8.
(Carpentier, 2009) Jean-Franois Carpentier, La scurit informatique dans la petite entreprise: tat de
l'art et bonnes pratiques, Editions ENI, 2009, ISBN 2746048205.
(Cartlidge, 2007) A. Cartlidge, A. Hanna, C. Rudd, I. Macfarlane, J. Windebank, S. Rance, An
Introductory Overview of ITIL V3, Ed. A. Cartlidge et M. Lillycrop, itSMF, 2007, ISBN
0-9551245-8-1.
(Castro et al., 2002) J. Castro, M. Kolp, J. Mylopoulos. Towards Requirements-Driven Information
Systems Engineering: The Tropos Project. In Information Systems, 27(6), September 2002.
203
(Chamfrault,2006) T. Chamfrault, C. Durand, ITIL et la gestion des services, Ed. Dunod, 2006.
(Chrissis, 2008) M. B. Chrissis, M. Konrad, S. Shrum, CMMI 2e dition - Guide des bonnes pratiques
pour l'amlioration des processus - CMMI pour le dveloppement, version 1.2, Pearson
Education France, 2008, ISBN 978-2-7440-7304-5
(Cigref, 2008) Cigref, McKinsey&Company, Dynamique de cration de valeur par les Systmes
dInformation, 2008.
(Claudepierre, 2009a) B. Claudepierre, S. Nurcan, ITGIM: An intention-driven approach for analyzing
the IT Governance requirements, The 3d International Workshop on Requirements, Intentions
and Goals in Conceptual Modeling (RIGiM 2009), in conjunction with the 28th International
Conference on Conceptual Modeling (ER 2009), 9-12 November 2009, Gramado, Brazil.
(Claudepierre, 2009b) B. Claudepierre, S. Nurcan, Constats et fondements pour des mthodes
d'ingnierie de systmes d'information diriges par les exigences de gouvernance. Numro
Spcial RCIS'08 de la Revue Ingnierie des Systmes d'Information. Volume 14, N 4,
Herms, 2009.
(Claudepierre, 2007a) B. Claudepierre, S. Nurcan, A Framework for Analising IT Governance
Approaches, International Conference on Enterprise Information Systems (ICEIS), Funchal,
Portugal, June 2007, p. 512 - 516.
(Claudepierre, 2007b) B. Claudepierre, S. Nurcan, Proposition dun cadre de rfrence pour la
gouvernance des Systmes d'Information, Le 4me workshop "Ingnierie et Gestion des
Processus d'Entreprise" des Groupements de Recherche I3 et MACS du CNRS, Dynamique
des organisations et cration de valeur : Apports des typologies et des cartographies de
processus, 15 Mai 2007, Paris.
(Corteau, 2001) A.M. Corteau, F. Bergeron, An information technology trilogy: business strategy,
technological deployment and organizational performance, in Journal of Strategic IS, vol. 10,
p. 7799, 2001.
(Cranefield, 2001) S. Cranefield, Networked Knowledge Representation and Exchange using UML
and RDF, in Journal of Digital Information, Vol 1, No 8, 2001.
(Davenport, 1993) T. Davenport, Process Innovation: Reengineering work through information
technology. Harvard Business School Press, Boston, 1993.
(De Haes, 2008) S. De Haes, W. Van Grembergen, Analysing the Relationship Between IT
Governance and Business/IT Alignment Maturity, Proceedings of the 41st Hawaii
International Conference on System Sciences, IEEE, 2008.
(De Haes, 2005) S. De Haes, W. Van Grembergen, IT Governance Structures, Processes and
Relational Mechanisms: Achieving IT/Business Alignment in a Major Belgian Financial
Group, Proceedings of the 38th International Conference on System Sciences, Hawaii, 2005.
(Deming, 1991) W.E. Deming, J.-M. Gogue, Hors de la crise, Economica, 1991, ISBN
9782717820904.
(Denis, 2009) J. Denis, Les ressorts de la scurit informatique - Des hommes, des machines et des
donnes, in C Licoppe (ed.), L'volution des cultures numriques, de la mutation du lien social
l'organisation du travail, FYP, Paris (p. 190-199), 2009.
(Dyer, 2005) J. S. Dyer, MAUT Multiattribute utility theory, Chapter 7 in Multiple Criteria Decision
Analysis: State of the Art Survey, International Series in Operations Research & Management
Science, 2005, Volume 78, IV, 265-292, DOI: 10.1007/0-387-23081-5_7.
(Etien, 2006) A. Etien, Lingnierie de lalignement: Concepts, Modles et Processus. La mthode
ACEM pour la correction et lvolution dun systme dinformation aux processus
dentreprise, thse de doctorat, 13 mars 2006, Universit Paris 1.
204
(Fenton, 1997) N.E. Fenton, S.L. Pfleeger, Software Metrics: A Rigorous and Practical Approach,
PWS Publishing Company, 1997.
(Gam, 2008) I. Gam, Ingnierie des Exigences pour les Systmes dInformation Dcisionnels :
Concepts, Modles et Processus La mthode CADWE, Thse de lUniversit Paris I
Panthon Sorbonne, Octobre 2008.
(Georgel, 2009) F. Georgel, IT Gouvernance Management stratgique dun systme dinformation,
3me dition, Ed. Dunod, 2009, ISBN 978-2-10-052574-4.
(Gericke, 2009) A. Gericke, H.-G. Fill, D. Karagiannis, R. Winter, Situational method engineering for
governance, risk and compliance information systems, Proceedings of the 4th International
Conference on Design Science Research in Information Systems and Technology, ACM, May
7-8, 2009, Malvern, PA, USA.
(Gervais, 1998) M. Gervais, G. Thenet, Planification, gestion budgtaire et turbulence, in Finance
Contrle Stratgie Volume 1, N 3, septembre 1998, p.57 84.
(Hammer, 1993) M. Hammer, J. Champy, Reengineering the Corporation: A Manifesto for Business
Revolution, Harper Collins,London, 1993.
(Henderson & Venkatraman, 1993) J. Henderson, N. Venkatraman, Strategic alignment: leveraging
information technology for transforming organizations, IBM Systems Journal, 32, 1993.
(Ittner, 1998a) C. Ittner, D. Larcker, Innovations in performance measurement: trends and research
implications, in Journal of Management Accounting Research 6, 205238, 1998.
(Ittner, 1998b) C. Ittner, D. Larcker, Are non-financial measures leading indicators of financial
performance?: an analysis of customer satisfaction, in Journal of Accounting Research 36, 1
35, 1998.
(Ittner, 1997) C. Ittner, D. Larcker, Quality strategy, strategic control systems, and organizational
performance, Accounting, Organizations and Society 22, 293314.
(Ittner, 1995) C. Ittner, D. Larcker, Total quality management and the choice of information and
reward systems, in Journal of Accounting Research 33, 134, 1995.
(Ivan, 2007) I. Ivan, A. Visoiu, D. Palaghita, IT projects metrics, in Journal of Applied Quantitative
Methods, Projects and Programs Evaluation. Risks, Ressources, Activities, Portfolio and
Project Management, 2:3, 2007.
(Izza, 2007) S. Izza, L. Vincent, P. Burlat, Vers une typologie intgr des processus dentreprise,
Actes du 4e workshop Ingnierie et gestion des processus, GDR I3, MACS, 2007.
(Jackson, 1995) M. Jackson, Software Requirements and Specifications, Addison-Wesley. 1995.
(Jarke, 1992) M. Jarke, J. Mylopoulos, J.M. Schmidt, Y. Vassiliou, DAIDA - An Environment for
Evolving Information Systems, ACM Trans., in Information Systems, vol. 10, n 1, 1992.
(Jarke, 1993) M. Jarke, K. Pohl, Requirements Engineering: An Integrated View of Representation,
Process and Domain, Proceedings of the 4th European Software Conference, Springer Verlag,
1993.
(Kaplan, 2003) R.S. Kaplan, D.P. Norton, Le tableau de bord prospectif, Editions d'Organisation,
2003, ISBN 2-7081-2932-5.
(Kaplan, 1996) R.S. Kaplan, D.P. Norton, Balanced Scorecard Translating strategy into action,
Harvard Business School Press, 1996.
(Kolar, 2009) J. Kolar, Business Activity Monitoring, Thse de lUniversit de Masarykiana, 2009.
(Kornyshova, 2010) E. Kornyshova, R. Deneckre, B. Claudepierre, Contextualization of method
components, International Conference on Research Challenges in Information Science (RCIS),
Ed. IEEE, ISBN #978-1-4244-4840-1, Nice, France, May 2010.
205
(Kyobe, 2004) M.E. Kyobe, Investigating the strategic utilization of IT resources in the small and
medium-sized firms of the eastern free state province, International Small Business Journal,
vol. 22, no. 2, pp. 131-58, 2004.
(Lamsweerde, 2003) A. van Lamsweerde, E. Letier, From Object Orientation to Goal Orientation: A
Paradigm Shift for Requirements Engineering, Proc. Radical Innovations of Software and
Systems Engineering, LNCS, 2003.
(Lamsweerde, 2001) A. van Lamsweerde, Goal-Oriented Requirements Engineering: A Guided Tour,
invited mini-tutorial paper appeared in Proceedings RE01, 5th IEEE International
Symposium on Requirements Engineering, Toronto, August 2001, 249-263.
(Lankhorst, 2009) M. Lankhorst, Enterprise Architecture at Work: Modelling, Communication and
Analysis, Springer Verlag Berlin Heidelberg, 2009, ISBN 978-3-642-01309-6.
(Laudon, 2008) K.C. Laudon, J.P. Laudon, Management Information Systems: Managing the Digital
Firm, 11me edition, Prentice Hall, 2008, ISBN 013607846X.
(Lepage, 1992) E. Lepage, M. Fieschi, R. Traineau, J. Gouvernet, C. Chastang, Systme d'aide la
dcision fond sur un modle de rseau bayesien application la surveillance
transfusionnelle, in Informatique et Sant - Nouvelles Mthodes de Traitement de
l'Information en Mdecine, Paris, Springer-Verlag, 1992.
(Le Roux, 2006) B. Le Roux, J. Paumier, La gouvernance de l'volution du SI, Lavoisier, Paris, 2006,
ISBN 2-7462-1293-5.
(Le Roux, 2009) B.Le Roux, La transformation stratgique du systme d'information, Lavoisier, Paris,
2009.
(Longp, 2004) C. Longp, Le projet d'urbanisation du S.I. 2e dition, Dunod, Paris, 2004, ISBN 2-
10-007376-1.
(Luftman, 1999) J. Luftman, T. Brier, Achieving and Sustaining Business-IT Alignment, in California
Management Review, Vol. 42, No. 1. (1999), pp. 109-122.
(Luftman, 2004) J. Luftman, E.R. Maclean, Key issues for IT executives, MIS Quarterly Executive,
vol. 3, 2004, p. 89-104.
(Luftman, 2004b) J. Luftman, Assessing Business-IT Alignment Maturity, in Strategies for Information
Technology Governance, Ed. by Van Grembergen, Idea Group, 2004, ISBN 1591401402.
(Manita, 2007) R. Manita, Le comit daudit et la qualit de laudit externe : quelle interaction ?,
Congrs international de lAFFI Ethique et Gouvernance , Bordeaux, 27-29 juin 2007.
(Mata, 1995) F.J. Mata, W.L. Fuerst, J.B. Barney, Information Technology and Sustained Competitive
Advantage: A Resource-Based Analysis, MIS Quarterly, vol. 19, Dec. 1995, S. 487-505.
(Mellor, 2002) S.J. Mellor, K. Scott, A. Uhl, D. Weise, Model-Driven Architecture, in Advances in
Object-Oriented Information Systems, Lecture Notes in Computer Science, 2002, Volume
2426/2002, 233-239.
(Moeller, 2007) R. Moeller, COSO enterprise risk management: understanding the new integrated
ERM framework, Ed. Joh Wiley and Sons, 2007, ISBN 9780471741152.
(Moisand, 2009) D. Moisand, F. Garnier de Labareyre, CobiT Pour une meilleure gouvernance des
systmes dinformation, Eyrolles, Paris, 2009.
(Muehlen, 2008) M. zur Muehlen, D.T. Ho, Service Process Innovation: A Case Study of BPMN in
Practice. In: Ralph Sprague, Jr. (Ed.): Proceedings of the 41st Hawaii International
Conference on System Sciences. Waikoloa, HI, January 7-10, 2008.
(Mylopoulos et al., 1992) J. Mylopoulos, L. Chung, B. Nixon, Representing and Using Non-
Functional Requirements: A Process-Oriented Approach. IEEE Transactions on Software
Engineering, 18(6), June 1992.
206
(Nehan, 2007) Y.-R. Nehan, R. Deneckre, Component-based Situational Methods: A framework for
understanding SME, IFIP, vol. 244, Situational Method Engineering: Fundamentals and
Experiences, Switzerland, 2007.
(Nobre, 2001) T. Nobre, Mthodes et outils du contrle de gestion dans les PME, Finance Contrle
Stratgie Volume 4, N 2, juin 2001, p. 119 - 148.
(Noirault, 2008) C. Noirault, ITIL (version 3): les meilleures pratiques de gestion d'un service
informatique, Editions ENI, 2008, ISBN 2746041200.
(Nonaka, 1995) I. Nonaka, H. Takeuchi, The knowledge-creating company, New York, Oxford
University Press, 1995.
(Nurcan, 2009) S. Nurcan, R. Schmidt, Service-oriented Enterprise Architecture for Enterprise
Engineering: Introduction, Proceedings of EDOC, IEEE Workshops and Short papers, 2009.
(Nurcan, 2008) S. Nurcan, B. Claudepierre, I. Gmati, Conceptual Dependencies between two
connected IT domains: Business/IS alignment and IT governance, Research Challenges in
Information Science (RCIS), Long paper, Marrakech, Morocco, June 2008.
(Nurcan, 2006) S. Nurcan, J. Casarus, Cas PAPCAR : Quelle place pour les systmes dinformation au
sein des organisations et quelle contribution la performance des processus organiss. Etude
de Cas du Master Administration des Entreprises, IAE de Paris, 2006.
(Nurcan, 2005) S. Nurcan, M.-H. Edme, Intention Driven Modelling for Flexible Workflow
Applications, Special issue of the Software Process: Improvement and Practice Journal on
"Business Process Management, Development and Support", 10:4, 2005.
(Nurcan, 2004) S. Nurcan, Business Process Modeling for developing Process Oriented IT Systems,
Information Resources Management Association (IRMA), Business Process Management
Tools and Technologies track, New Orleans, USA, May 2004.
(Nurcan, 2003) S. Nurcan, C. Rolland, A multi-method for defining the organisational change, Journal
of Information and Software Technology (JIST), Elsevier, vol. 45, n 2, 2003, p. 61-82.
(Nurcan, 1999) S. Nurcan, C. Rolland, Using EKD-CMM electronic guide book for managing change
in organisations, Submitted to the European-Japanese Conference on Information Modelling
and Knowledge Bases , Japan, 1999.
(OMG, 2010) OMG, OMG Unified Modeling LanguageTM (OMG UML), Infrastructure, version 2.3,
OMG document number : formal/2010-05-03, mai 2010
(OT, 2004) Observatoire Technogique, Centre des Technologies de lInformation, Rpublique et
Canton de Genve, Etudes & Gestion de Portefeuille de Projets Informatiques, document
disponible ladresse : http://ot.geneve.ch/partenariat/IMG/pdf/Portefeuille_info.pdf. Consult
le 24 aout 2010.
(Prather, 2005) C.W. Prather, The Dumb Thing About Smart Goals for Innovation, Research
Technology Management. Sep/Oct 2005, Vol. 48 Issue 5, p14-15, 2p.
(Prieto-Diaz, 1991) R. Prieto-Diaz, Implementing Faceted Classification for Software Reuse,
Communications of the ACM. Special issue on software engineering, 34(5):88 97, 1991.
(Ploesser, 2008) K. Ploesser, J. Recker and M. Rosemann, Towards a Classification and Lifecycle of
Business Process Change, 9th Workshop on Business Process Modeling, Development, and
Support (BPMDS'08), 16-17 June 2008, Montpellier, France.
(PMI, 2010) Project Management Institute, A Guide to the Project Management Body of Knowledge:
(PMBOK Guide), 4me dition, Ed. PMI, 2010, ISBN 9781933890630.
(Porter, 1986) M. Porter, L'avantage concurrentiel, InterEditions, Paris, 1986.
(Ralyte, 2005) J. Ralyte, N.M. Maiden, C. Rolland, R. Deneckre, Map-driven Modular Method Re-
engineering: Improving the RESCUE Requirements Process, International Conference on
207
Advanced information Systems Engineering (CAISE), CAiSE Short Paper Proceedings, Porto,
Portugal, June 2005.
(Ralyt, 2001) J. Ralyt, Ingnierie des mthodes base de composants, Thse de Doctorat,
Universit de Paris I, Janvier 2001.
(Ravichandran, 2005) T. Ravinchandran, C. Lertwongsatien, Effect of information systems resources
and capabilities on firm performance: A resource-based perspective, Journal of Management
Information Systems, 21, 4 (Spring 2005), 237276.
(Ravichandran, 2000) T. Ravichandran, A. Rai, Quality management in systems development: An
organizational system perspective, MIS Quarterly; Sep 2000; 24, 3; ABI/INFORM Global, p.
381
(Reix, 2005) R. Reix, Systmes dinformation et management des organisations, 5me dition,
Librairie Vuibert, Paris, 2005.
(Rolland, 2001) C. Rolland, N. Prakash. Matching ERP System Functionality to Customer
Requirements, International Symposium on Requirements Engineering (RE), Toronto, Canada,
August 2001.
(Rolland, 1999) C. Rolland, N. Prakash, A. Benjamen, A multi-model view of process modeling,
Requirements Engineering, (4):169187, 1999.
(Rolland, 1998) C. Rolland, A Comprehensive View of Process Engineering, Proceedings of the 10th
International Conference CAISE98, Lecture Notes in Computer Science 1413, B. Pernici, C.
Thanos (Eds), Springer, 1998.
(Rolland, 1998) C. Rolland, C. Souveyet, C. Ben Achour, Guiding GoalModeling Using Scenarios,
IEEE Trans. on Sofware. Engineering, Special Issue on Scenario Management, December
1998, 1055-1071.
(Rolland, 1994) C. Rolland, G. Grosz, A general framework for describing The Requirements
Engineering Process, in the Proceedings of the Conference on Systems Man and Cybernetics
(CSMC94), San Antonio, Texas, 1994.
(Ross, 2006) J.W. Ross, P. Weill, D. Robertson, Enterprise Architecture as Strategy: Creating a
Foundation for Business Execution, Harvard Business School Press, 2006.
(Roy, 1968) B. Roy, Classement et choix en prsence de points de vue multiples : la mthode
ELECTRE, RIRO, Vol. 8 : 57-75, 1968.
(Rummler, 1995) Rummler, Brache, Improving Performance: How to manage the white space on the
organizational chart, Jossey-Bass, San Francisco, 1995.
(Saidani, 2007) O. Saidani, S. Nurcan, Prise en compte de laspect dcisionnel dans lingnierie et la
gestion des processus dentreprise, GDR I3, MACS, 2007.
(Sandhu, 1996) R. Sandhu, P. Samarati, Authentication, access control, and audit, in ACM Computing
Surveys (CSUR), Ed. ACM, 28:1, pp 241-243, 1996.
(Schwalbe, 2007) K. Schwalbe, Information Technology Project Management, Fifth Edition, Ed.
Cengage Learning, 2007, ISBN 978-1-4239-0145-7.
(SEI, 2006) SEI, CMMI for Development version 1.2, Software Engineering Institute, 2006,
http://www.sei.cmu.edu/pub/documents/06.reports/pdf/06tr008.pdf.
(Seligmann, 1989) P.S. Seligmann, G.M. Wijers, G.H. Sol, Analysing the structure of IS
methodologies, an alternative approach, Proceedings of the 1st Dutch Conference in
Information Systems, Amersfoort, Netherlands, 1989.
(Sienou, 2007) A. Sienou, E. Lamine, H. Pingaud, Intgration de la gestion de processus et de la
gestion des risques : vers un modle conceptuel du risque processus, Actes du 4e workshop
Ingnierie et gestion des processus, GDR I3, MACS, 2007.
208
(Sienou, 2007) A. Sienou, Modles conceptuels du risque, EDSys 2007, 8me congrs des doctorants.
(Simonsson, 2008) M. Simonsson, P. Johnson, The IT organization modeling and assessment tool:
Correlating IT governance maturity with the effect of IT, Proceedings of the 41st Hawaii
International Conference on System Sciences, 2008.
(Stoddard, 2010) R.W. Stoddard, D.R. Goldenson, Approaches to Process Performance Modeling: A
Summary from the SEI Series of Workshops on CMMI High Maturity Measurement and
Analysis, Carnegie Mellon University, SEI, January 2010.
(Thvenet, 2009) L.-H. Thvenet, Proposition dune modlisation conceptuelle d'alignement
stratgique : La mthode INSTAL, thse de doctorat, 11 dcembre 2009, Universit Paris 1.
(Tricot, 2000) A. Tricot, M. Tricot, Un cadre formel pour interprter les liens entre utilisabilit et
utilit des systmes dinformation (et gnralisation lvaluation dobjets finaliss),
Proceedings of Colloque Ergo-IHM, Biarritz, France, 3-6 Octobre 2000, p. 195-202.
(Vanek, 2008) F. Vanek, P. Jacksonn, R. Grzybowski, Systems Engineering Metrics and Applications
in Product Development: A Critical Literature Review and Agenda for Further Research, in
The Journal of the International Council on Systems Engineering, Wiley InterScience, 11:2,
(2008), ISSN 1098-1241.
(Van Grembergen, 2004) W. Van Grembergen, S. De Haes, E. Guldentops, Structures, processes and
relational mechanisms for information technology governance: theories and practices, in
Strategies for Information Technology Governance, Ed. by Van Grembergen, Idea Group,
2004, ISBN 1591401402.
(Van Grembergen, 2000), W. Van Grembergen, The Balanced Scorecard and IT Governance,
Information Systems Control Journal, n2, 2000.
(Watson, 2007) H.J. Watson, B.H. Wixom, The Current State of Business Intelligence, in Computer,
Ed. IEEE Computer Society, pp. 96-99, September 2007.
(Weill, 2005) P. Weill, J. Ross, A Matrixed Approach to Designing IT Governance, MIT Sloan
Management Review, 46:2, 2005.
(Weill, 2004) P. Weill, J. Ross, IT Governance: How Top Performers Manage IT Decision Rights for
Superior Results, Harvard Business School Press, Boston, 2004.
(Wirtz, 2008) P. Wirtz, Les meilleures pratiques de gouvernance dentreprise, La Dcouverte, Paris
2008.
(Yu, 1997) E. Yu, Towards Modeling and Reasoning Support for Early-Phase Requirements
Engineering, Proceedings of the 3rd International Symposium on Requirements Engineering
(RE97), Washington, USA, January 1997.
(Yu, 1995) E. Yu, Modelling Strategic Relationships for Process Reengineering, PhD Thesis,
Graduate Department of Computer Science, University of Toronto, Toronto (1995).
(Zachman, 2003) J.A. Zachman, The Zachman Framework for Enterprise Architecture: A Primer
for Enterprise Engineering and Manufacturing, Electronic book published March 2003.
www.zachmaninternational.com.
209
Annexe A - Enonc du cas PAPCAR
211

These Sur La GSI

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

These Sur La GSI

Hochgeladen von

Copyright:

Verfügbare Formate

Conceptualisation de la Gouvernance des Syst`emes

dInformation : Structure et Demarche pour la

To cite this version:

HAL Id: tel-00748984

HAL is a multi-disciplinary open access Larchive ouverte pluridisciplinaire HAL, est

Pour lobtention du titre de :

Conceptualisation de la Gouvernance des

Structure et Dmarche pour la Construction des Systmes

Soutenue le 10 dcembre 2010 devant le jury compos de

Je remercie sincrement le Pr. Camille Rosenthal-Sabroux, Professeur l'Universit Paris

Nous rpondons ce manque de considration par la conceptualisation de la GSI. Nous avons

Cette thse permet ainsi de capitaliser et de structurer la connaissance du domaine de la GSI et

Mots Cls : gouvernance des systmes dinformation, conceptualisation, modlisation, ingnierie du

We respond to this lack of consideration by the conceptualization of ITG. We have proposed

Keywords: governance of information systems, conceptualization, modeling, engineering information

2.1. Introduction ............................................................................................................................... 11

3.1. Introduction ............................................................................................................................... 37

5.1. Introduction ............................................................................................................................... 79

6.1. Introduction ............................................................................................................................. 143

7.1. Contributions ........................................................................................................................... 199

ANNEXE A - ENONCE DU CAS PAPCAR ........................................................................................... 211

La gouvernance dentreprise est un mcanisme de rgulation permettant de sassurer que la

La gouvernance des systmes dinformation (GSI) fait partie intgrante de la gouvernance

Une dfinition descriptive de la gouvernance consiste considrer quelle dcrit comment un

La gouvernance des systmes dinformation (GSI) peut se dfinir comme la dmarche

L'objet de la gouvernance du SI est donc le Systme dInformation. Les orientations

Un SI a pour mission de rendre les activits principales de l'organisation gnratrices de

Nous dfinissons un SI comme un ensemble organis de ressources technologiques (matriel

Cette dfinition positionne lobjet SI suivant trois axes :

Service : la notion de service des technologies de linformation et de la

Larchitecture de lentreprise est un lment structurant lorganisation sur laquelle la stratgie

Larchitecture dentreprise est un instrument, ou plus prcisment un socle, pour matriser le

Le concept de gouvernance n'est pas clarifi.

o Quels concepts structurent le cadre de ce domaine ? Quelle est la nature de ces

La nature du processus de gouvernance n'est pas comprise. Il y a des facteurs facilitateurs et

o Quels concepts pour la formalisation du processus de GSI ?

Nous proposons de traiter la problmatique suivante :

Quelle conceptualisation de la gouvernance des SI pour la construction dun SI de

1.4. Mthode de rsolution

H1 : la GSI est un artfact que lon peut conceptualiser.

H2 : un systme dinformation de gouvernance correctement conceptualis est utile

1.5. Apports et rsultats

Notre proposition pour la conceptualisation de la GSI sarticule ainsi en quatre points :

une comprhension de la nature du processus de mise en uvre de la GSI : (i) il est

1.6. Plan de la thse

2.2. Cadre de rfrence pour les approches de la gouvernance des SI

un domaine de valeur simple se rfre un type de valeur primitive prdfinie. Cest

Cadre de rfrence 4 Monde

+nom: String 1 +nom: String

Figure 3.1. Mta-modle du cadre des quatre mondes.

2.2.2. Description du cadre de rfrence

Portefeuille de projets SI Utilise

Figure 3.2. Cadre de rfrence pour la gouvernance des SI

2.2.2.1. Le monde du sujet de la GSI

2.2.2.1.1. Organisation de la gouvernance

La facette ORGANISATION DE LA GOUVERNANCE capture cet aspect. Une ORGANISATION DE

ORGANISATION DE LA GOUVERNANCE : Enum{centralise, dcentralise, hybride}

Principes des technologies de l'information. Ce sont les dcisions relatives au rle

DECISION : Enum{architecture SI, infrastructure SI, planification des projets}

PROCESSUS SI : Enum{document, pilot, volutif}

2.2.2.1.4. Processus mtier

Productif : le processus est rptable et implmente les processus primaires de

PROCESSUS METIER : Enum{productif, administratif, ad-hoc, collaboratif}

Changement par substitution : Le remplacement temporaire d'un processus mtier