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
tel-00748984, version 1 - 6 Nov 2012

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 Mme Colette ROLLAND Mme Selmin NURCAN Mme Corine CAUVET Mme Camille ROSENTHAL-SABROUX M. Bahram SOLTANI Prsident du jury Directeur de thse Codirecteur de thse Rapporteur Rapporteur Membre du jury

tel-00748984, version 1 - 6 Nov 2012

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

tel-00748984, version 1 - 6 Nov 2012

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~

tel-00748984, version 1 - 6 Nov 2012

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

tel-00748984, version 1 - 6 Nov 2012

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 situat ion 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

tel-00748984, version 1 - 6 Nov 2012

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

tel-00748984, version 1 - 6 Nov 2012

~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

tel-00748984, version 1 - 6 Nov 2012

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 5.3.4.1. Composant graphique ................................................................................................... 110

~ vi ~

5.3.4.2. Composants de guidage pour la slection dintention .................................................. 112 5.3.4.3. Composants de guidage pour la slection de stratgie ................................................. 115 5.3.4.4. Composants de guidage pour laccomplissement dintention ....................................... 119 5.3.4.5. Composant produit ........................................................................................................ 126 5.3.5. La carte C.Cbb2 : Gouverner le SI depuis Gouverner le SI par prise de dcision ................ 127 5.3.5.1. Composant graphique ................................................................................................... 127 5.3.5.2. Composants de guidage pour la slection dintention .................................................. 128 5.3.5.3. Composants de guidage pour la slection de stratgie ................................................. 129 5.3.5.4. Composants de guidage pour laccomplissement dintention ....................................... 132 5.3.5.5. Composant produit ........................................................................................................ 140 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.3.1. Composant de choix ...................................................................................................... 170 6.5.3.2. Composant dexcution ................................................................................................. 171 6.5.3.3. Composant descriptif .................................................................................................... 171 6.5.4. Etape 3 Initialisation du processus de dcision des investissements sur les projets PAPCAR ....................................................................................................................................... 185 6.5.4.1. Composant de choix ...................................................................................................... 185 6.5.4.2. Composant dexcution ................................................................................................. 185 6.5.4.3. Composant descriptif .................................................................................................... 186 6.5.5. Finalisation du processus de GSI de PAPCAR ................................................................... 193 6.5.5.1. Composant de choix ...................................................................................................... 193 6.5.5.2. Composant dexcution ................................................................................................. 194

tel-00748984, version 1 - 6 Nov 2012

~ vii ~

6.5.5.3. Composant descriptif .................................................................................................... 194 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

tel-00748984, version 1 - 6 Nov 2012

~ 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

tel-00748984, version 1 - 6 Nov 2012

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

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 in strument privilgi dont

tel-00748984, version 1 - 6 Nov 2012

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

tel-00748984, version 1 - 6 Nov 2012

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 cap ital 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

tel-00748984, version 1 - 6 Nov 2012

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 lorgan isation 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 appl ications, de linfrastructure informatique, des processus mtier, ainsi que des nombreuses interdpendances entre ces lments (Lankhorst, 2009).

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 ?

tel-00748984, version 1 - 6 Nov 2012

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 3

http://www.afai.asso.fr/public/doc/170.pdf http://www.silicon.fr/gartner-les-investissements-it-a-la-hausse-en-france-33457.html 4 http://www.gartnerinfo.com/ppmit2/PPM10Profile.pdf

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 phas es 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.

tel-00748984, version 1 - 6 Nov 2012

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.

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 ?

tel-00748984, version 1 - 6 Nov 2012

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

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.

tel-00748984, version 1 - 6 Nov 2012

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 mtamodle 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

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.

tel-00748984, version 1 - 6 Nov 2012

tel-00748984, version 1 - 6 Nov 2012

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

tel-00748984, version 1 - 6 Nov 2012

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.

tel-00748984, version 1 - 6 Nov 2012

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 +nom: String 1

Monde +nom: String Simple Ensemble Enumr

1..* Facette +nom: String Domaine de valeur

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.

tel-00748984, version 1 - 6 Nov 2012

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 exigences de la GSI ?
Minimiser les risques

Atteindre ltat dalignement Obtenir la performance Crer de la valeur

Comment rpondre aux exigences de GSI ?

Monde du sujet
Organisation de la gouvernance Dcision Processus SI Processus mtier Changement Portefeuille de projets SI

A pour objectif

Monde du dveloppement
Nature des processus Excute Matrise
Capitalisation de la connaissance Logiciel Utilise

Maturit des processus

Monde du systme
Contenu Comment reprsenter la ralit de la GSI ? Modle Mtriques Quels lments pour lexcution des activits de GSI ?

tel-00748984, version 1 - 6 Nov 2012

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

tel-00748984, version 1 - 6 Nov 2012

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 ( infine, 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

tel-00748984, version 1 - 6 Nov 2012

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 l ieu 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

tel-00748984, version 1 - 6 Nov 2012

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}}

tel-00748984, version 1 - 6 Nov 2012

18

En conclusion, lanalyse et la synthse des visions de la GSI aboutit la proposition suivante : Facette ORGANISATION DE LA
GOUVERNANCE DECISION PROCESSUS IT PROCESSUS METIER CHANGEMENT

Valeur Enum{centralis, dcentralise, hybride} Enum{architecture SI, infrastructure SI, planification projet} Enum{document, pilot, volutif} Enum{productif, administratif, ad-hoc, collaboratif} Enum{ad-hoc, volutif, correctif} 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.

PPSI

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

tel-00748984, version 1 - 6 Nov 2012

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

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 fourni e 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

tel-00748984, version 1 - 6 Nov 2012

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 ( covolution). 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

tel-00748984, version 1 - 6 Nov 2012

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 Objectif Question Mtrique Exemple Minimiser le cot de lalignement Quel est le cot du mcanisme dalignement ? 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

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

tel-00748984, version 1 - 6 Nov 2012

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 : 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 Facette

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

tel-00748984, version 1 - 6 Nov 2012

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

tel-00748984, version 1 - 6 Nov 2012

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 Ro ux, 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

tel-00748984, version 1 - 6 Nov 2012

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 CONTENU MODELE METRIQUES Valeur Enum{nom de document} Enum{processus, objet, dcision, volution} 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 pris e 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 co rrlation 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

tel-00748984, version 1 - 6 Nov 2012

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 l eur 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

tel-00748984, version 1 - 6 Nov 2012

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 (Computeraided Software Engineering) pour les logiciels. Les outils daide lingnierie de la gouvernance

tel-00748984, version 1 - 6 Nov 2012

(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 abouti ssent la proposition suivante : Facette NATURE DES PROCESSUS MATURITE DES PROCESSUS CAPITALISATION DE LA
CONNAISSANCE LOGICIEL

Valeur Enum{ad-hoc, systmatique} SET{Niveau; Objectif} Enum{socialisation, externalisation, internalisation, combinaison} 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

tel-00748984, version 1 - 6 Nov 2012
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 rende ment 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

tel-00748984, version 1 - 6 Nov 2012

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 CMMSE (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 EtatsUnis (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 :

tel-00748984, version 1 - 6 Nov 2012

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

tel-00748984, version 1 - 6 Nov 2012

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

tel-00748984, version 1 - 6 Nov 2012

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.

tel-00748984, version 1 - 6 Nov 2012

34

Cadre des quatre mondes Monde Facette Sujet ORGANISATION DE LA

GOUVERNANCE DECISION PROCESSUS IT PROCESSUS METIER CHANGEMENT PORTEFEUILLE DE PROJETS SI MINIMISER LES RISQUES ATTEINDRE LETAT DALIGNEMENT OBTENIR LA PERFORMANCE

Approches de la gouvernance des systmes dinformation CobiT COSO ITIL * * * * document Processus, objet Risque, performance, valeur systmatique * externalisation * * * * * Patrimoine mtier document Processus, objet risque systmatique externalisation * Infrastructure * * volutif * qualit Evolution SI Patrimoine SI, usage document Processus, objet Alignement, performance systmatique externalisation *

CMMI * * Clas. : Multi-critre Transfo. : * * Maturit des processus Patrimoine SI document Processus, objet performance systmatique * externalisation *

PMBOK * Plan. projet * * * Clas. : Multi-critre Transfo. : * * Evolution SI, Evolution mtier Maturit des processus Patrimoine SI, Patrimoine mtier document Processus, objet, dcision Risque, Performance, Valeur systmatique * externalisation *

tel-00748984, version 1 - 6 Nov 2012

Usage

CREER DE LA VALEUR Systme CONTENU MODELE METRIQUES Dveloppement NATURE

DES PROCESSUS MATURITE DES PROCESSUS CAPITALISATION DE 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 ?

tel-00748984, version 1 - 6 Nov 2012

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.

tel-00748984, version 1 - 6 Nov 2012

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 du n 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 :

tel-00748984, version 1 - 6 Nov 2012

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 soushypothses : 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 Mta-modle UML

Intention Mta-modle CARTE

Universitaires et chercheurs

tel-00748984, version 1 - 6 Nov 2012

instanciation

Conceptualisation

Modle

REFGOUV A B C

Concept formel

Approches de la GSI -Articles -Rfrentiels

PROGOUV
Dbut I1 fin

MISIG

Systme G.S.I.
Rfrentiel de donnes

Indicateurs Projet 11 Projet Projet 11 Projet

a -DSI - Ingnieur mthode -Ingnieur programme - Responsable projet

?
Dcision Valeur

b
c

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.

tel-00748984, version 1 - 6 Nov 2012

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

Objet Mta-modle UML

Ingnieur SI

G.S.I.

Systme

Objectif Projet

Utilise

Rfrentiel de donnes

Indicateur
-DSI -Ingnieur programme - Responsable projet

tudie

MISIG

Modle Propose
Universitaires et chercheurs

Concept formel A

REFGOUV

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

tel-00748984, version 1 - 6 Nov 2012

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 B MISIG C

Propose

PROGOUV

Intgre
Ingnieur SI

Dbut I1 fin

Construit
Systme Projet
Rfrentiel de donnes

Organise
Supporte

Objectif

O
Activits de Gouvernance des SI : Plannifier Excuter Contrler Dcider

Indicateur

tel-00748984, version 1 - 6 Nov 2012

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 sousensemble du SI qui va permettre le support une activit spcifique de la GSI. Par exemple, lactivi t 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.

tel-00748984, version 1 - 6 Nov 2012

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.

tel-00748984, version 1 - 6 Nov 2012

44

Chapitre 4. REFGOUV : modle rfrence du domaine de la GSI

4.1. Introduction

de

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

tel-00748984, version 1 - 6 Nov 2012

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.

tel-00748984, version 1 - 6 Nov 2012

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
+proprit +Nom +DateNaissance 1..* +Pedigre 1..*

Personne +Nom +propritaire +Prnom +Adresse

Terrier +NBChasse

Berger +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

tel-00748984, version 1 - 6 Nov 2012

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.

Type +nom: String Concept +nom: String +description: String reprsente

dimension dimension de retour dimension

source Association cible * hrite Classe *

+attributs +oprations * +paramtres * Paramtre +nom: String

Attribut +nom: String

Opration +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

tel-00748984, version 1 - 6 Nov 2012

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 mtaconcepts. 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 +Nom: String +DateNaissance: Date +Pedigre: String

String : Type nom = "String"

Date : Type nom = "Date"

<<instance de>>

Type +nom: String

<<instance de>>

dimension

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

Chien : Classe nom = "Chien"

<<instance de>>

Classe

Le concept 'Chien' comme ensemble d'objets instancis

Mta-Modle UML

tel-00748984, version 1 - 6 Nov 2012

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..* Dcision +ID: Integer +description: String +date: Date Situation prvue Situation Situation gnre 0..* 1..* Action +ID: Integer +description: String 1 1 0..* < impacte 1..* But +ID: Integer +description: String +date: Date 0..1 * * 1..* 0..* 0..1 <impacte 0..1 dcoup par > Projet +nom: String +date: Date +description: String 1..* a 1 1..* 0..* Risque +ID: Integer +Nom: String 1..* 0..* Processus +ID: Integer +Nom: String 0..* Ressource +ID: Integer +Nom: String 1..* +axeProcessus +axeRisque Domaine GSI +nom: String 0..* +axeBut 1..* Tableau de bord +ID: Integer +nom: String +date: Date +axeRessource 1..* Portefeuille +ID: Integer * caractristique +nom: String < value < value +ID: Integer +description: String 0..* < valuer 1..* Mtrique +ID: Integer 0..* +description: String +dim: Object +valeur: String * 0..* 0..* 0..* Ajustement

drive

tel-00748984, version 1 - 6 Nov 2012

opportunits

< gnre

< value

Indicateur < value +intitul: String +forme: Object +valeur: Integer +valeurMIN: Integer +valeurMAX: Integer +date: Date

1..* Catgorie 1 affin par > 0..* Question CGQ +nonc: String 1..*

0..* Critre +nom: String

1..* Mot +intitul: String +dfinition: String

0..* 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

affin par > 0..*

Question CGQ +nonc: String

But +ID: Integer +description: String +date: Date Catgorie

1..* 1

Domaine GSI
1..* 0..*

+nom: String
0..* 0..*

Mot +intitul: String +dfinition: String

0..*

Critre +nom: String

tel-00748984, version 1 - 6 Nov 2012

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

tel-00748984, version 1 - 6 Nov 2012

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 -QuestionMetric) permettant didentifier des mtriques partir dun but. Nous adoptons une dmarche similaire

tel-00748984, version 1 - 6 Nov 2012

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 1 2 3 4 5 6 BUT TI (COBIT) Rpondre aux exigences mtier en alignement avec la stratgie mtier Rpondre aux exigences de gouvernance en alignement avec le comit de direction Assurer la satisfaction des utilisateurs en proposant des services Optimiser lusage de linformation Crer lagilit des TIC Dfinir comment les fonctionnalits mtier et les exigences de contrle sont traduites en une solution efficiente et automatise Acqurir et maintenir les applications intgres et standardises Acqurir et maintenir une infrastructure des TIC intgre et standardise Acqurir et maintenir les comptences en TIC qui correspondent la stratgie TIC Assurer la satisfaction des parties prenantes Intgrer les applications et les solutions technologiques aux processus mtier Assurer la transparence et la validation des cots, des bnfices, de la stratgie, des rglements et des services pour les TIC Assurer lusage adquat et la performance des applications et des solutions technologiques Domaine Alignement Alignement Alignement Ressource Ressource Alignement Critre Valeur Valeur Valeur Maturit Maturit Maturit

7 8 9 10 11 12

Ressource Ressource Alignement Ressource Alignement Alignement Risque Ressource ( ?) Risque

Maturit Maturit Maturit Valeur Performance Performance

13

Performance

53

Identifiant 14 15 16 17 18 19 20 21

BUT TI (COBIT) Recenser et protger les actifs des TIC Optimiser linfrastructure des TIC, les ressources et la capacit Rduire la production de solutions et de services dfectueux Protger laccomplissement des objectifs en TIC Etablir clairement limpact des risques mtier sur les objectifs TIC et les ressources Assurer que les informations critiques et confidentielles sont protges des accs des personnes non autorises Assurer la fiabilit de lexcution des transactions mtier et des changes dinformation Assurer que les services TIC et linfrastructure peuvent rsister aux dfaillances dues des erreurs, attaques dlibres et aux catastrophes Assurer un impact minimal sur les processus mtier dans lventualit dun changement ou dune dfaillance des services TIC Assurer que les services TIC sont disponibles en rponse aux exigences Amliorer lefficience des investissements TIC et leurs contributions aux profits de lorganisation Livrer les projets dans les dlais et les budgets tels que spcifier par les normes qualit Maintenir lintgrit des informations et la mise en uvre de linfrastructure Assurer la conformit des TIC aux rglements et la lgislation Assurer que les TIC constatent une efficience des cots de la qualit de service, des amliorations continues et de la permissivit au changement

Domaine Risque Ressource Ressource Risque Risque Risque Risque Contrle Risque Contrle Risque Contrle Risque Contrle Alignement Risque Alignement Ressources Ressource Contrle Contrle

Critre Performance Maturit Maturit Performance Maturit Maturit Maturit Maturit Maturit

22

Maturit

23

Valeur Performance Performance Maturit Performance Maturit

tel-00748984, version 1 - 6 Nov 2012

24 25 26 27 28

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

Plans de vol connus Positions des avions connues

Contrleurs assigns aux secteurs ariens Moyens de communication fonctionnels

Communication pilotescontrleurs possible

Communication possible entre les 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

tel-00748984, version 1 - 6 Nov 2012

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

But +ID: Integer +description: String +date: Date

*

Projet +nom: String +date: Date +description: String

0..*

Portefeuille +ID: Integer

1..*

1..*

Ressource +ID: Integer +Nom: String

Risque +ID: Integer +Nom: String

Processus +ID: Integer +Nom: String

Figure 4.7. Composant projet de REFGOUV

tel-00748984, version 1 - 6 Nov 2012

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

tel-00748984, version 1 - 6 Nov 2012

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..* Objet organisationnel 1 3..*

3..* Objet de flux 2 0..*

2..* Objet de transition

0..* Objet informationnel

Role Evnement Pool Dbut Fin Intermdiaire XOR OR AND Composite Atomique Oprateur Activit

Squence

Donne

Message

Groupe

Association

Annotation

tel-00748984, version 1 - 6 Nov 2012

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

1..*

Manipule 1..* Personnel TI +Budget: int +Cout: int +Benefice: int +Utilise 0..* Role TI 1..* 1..* Maintenu par 0..* 1..* 1..* 1..* 1..* Supporte 1..* Composant tech. +Budget: int +Cout: int +Benefice: int 0..* Authorisation 0..*

Connaissance 1..* Repose sur

1..* Information 1..* 1..*

Composant applicatif +Budget: int +Cout: int 1..* +Benefice: int

Entre Sortie

tel-00748984, version 1 - 6 Nov 2012

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

tel-00748984, version 1 - 6 Nov 2012

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

Technique

0..* Elment

utilise 1..* 0..*

ImpactRisque

+impactant Risque Subit Sensible 0..* 0..*

Organisation

0..* gnre

1..*

+Impact

Rglementaire

0..* 1..*

1..* Evnement

0..* +descripteur 1..* 0..* +contexte

0..* Situation

tel-00748984, version 1 - 6 Nov 2012

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 foncti onnalits 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

tel-00748984, version 1 - 6 Nov 2012

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 mtamodle 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 mtamodle 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 Situation +ID: Integer +description: String 0..* 0..* < valuer Mtrique +ID: Integer +description: String +dim: Object +valeur: String 0..* < value 0..* Indicateur +intitul: String +forme: Object +valeur: Integer +valeurMIN: Integer +valeurMAX: Integer +date: Date 0..* 1..* Ressource +ID: Integer +Nom: String 0..* * *

caractrisitique +nom: String 1..* a 1

Projet +nom: String +date: Date +description: String 1..*

< value 0..*

< value 0..* Risque +ID: Integer +Nom: String +axeRisque

< value 0..* Processus +ID: Integer +Nom: String But +ID: Integer +description: String +date: Date

+axeProcessus +axeRessource Tableau de bord +ID: Integer +nom: String +date: Date +axeBut 1..*

Dcision

tel-00748984, version 1 - 6 Nov 2012

+ID: Integer +description: String +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 Distance Temps Vitesse Acclration Frquence Puissance Unit de mesure mtre seconde Mtre par seconde Mtre par seconde carr Hertz Watt Symbole m s m.s-1 m.s-2 Hz W Moyen de mesure dcimtre chronomtre vlocimtre acclromtre Frquencemtre Wattmtre

tel-00748984, version 1 - 6 Nov 2012

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. L es proprits suivantes doivent tre vrifies : L'ensemble vide a une mesure nulle : ()= 0 La mesure est -additive : Soit ensembles Ei de X disjoints deux deux alors la mesure (E) est dfinie par : , n tant fini et les sous-

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 KP I (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

tel-00748984, version 1 - 6 Nov 2012

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 Processus interne Tableau de bord SI Performance des dveloppements : - % des projets hors cot, dlais et qualit Maturit des dveloppements - Niveau de maturit (CMMi) Disponibilit : - % des composants techniques disponibles - % des composants logiciels disponibles Tableau de bord Mtier Innovation : - % de vente des nouveaux produits/services Activits : - Niveau de qualit produit/service - % des livraisons retournes - Dlai moyen de livraison - Dlai moyen de traitement dune commande - SLA

tel-00748984, version 1 - 6 Nov 2012

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.

tel-00748984, version 1 - 6 Nov 2012

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 Personnel Facteur Financier Degr dexpertise Mtrique Salaire Niveau de diplme Annes dexprience Nombre de projets Nombre dannes par rle Jours de prsence Jours dabsence justifis Jours dabsence injustifis Cot de dveloppement Cot de maintenance Frquence dutilisation Dure entre dfaillances conscutives Dure de bon fonctionnement Dure de maintenance Nombre de bugs Dure de disponibilit Dure dindisponibilit Charge de calcul (Hz) Charge de mmoire (Octet) Charge de stockage (Octet) Nombre daccs autoriss Nombre daccs non autoriss Nombre de virus traits Cot de dveloppement Cot de maintenance Frquence dutilisation Dure entre dfaillances conscutives Dure de bon fonctionnement

Degr de responsabilit Degr de fiabilit

Composant applicatif

Financier Degr dusage Degr de fiabilit

Degr de maintenabilit Degr de disponibilit Degr de consommation

Degr de scurit

Composant Technique

Financier Degr dusage Degr de fiabilit

67

Ressource

Facteur Degr de maintenabilit Degr de disponibilit Degr de capacit

Degr de communication Degr de scurit Degr defficacit Degr defficience

Information

Degr de confidentialit Degr dintgrit

tel-00748984, version 1 - 6 Nov 2012

Degr de disponibilit Degr de licit

Degr de fiabilit

Mtrique Dure de maintenance Nombre de dfaillances Dure de disponibilit Dure dindisponibilit Capacit de calcul (Hz) Capacit de mmoire (Octet) Capacit de stockage (Octet) Dbit (Octet.s-1) Nombre dattaques vites Nombre daccs physiques non autoriss Nombre de requtes par processus mtier Cot dobtention Cot de stockage Cot de prsentation Nombre daccs protgs Nombre de pertes par erreur Nombre de pertes par incident Niveau de qualit des donnes Nombre de requtes non satisfaites 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 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 p=10% (Faible) p=50% (Moyen) p=100% (Elev) i=10 (Faible) Nr=10x10%=1 (Faible) Nr=5 (Faible) Nr=10 (Faible) Impact i=50 (Moyen) Nr=5 (Faible) Nr=25 (Moyen) Nr=50 (Moyen) i=100 (Elev) Nr=10 (Faible) Nr=50 (Moyen) Nr=100 (Elev)

tel-00748984, version 1 - 6 Nov 2012

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 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Catgorie Risque Humain Risque Humain Risque Humain Risque Humain Risque Humain Risque Humain Risque Humain Risque Humain Risque Humain Risque Technologique Risque Technologique Risque Technologique Risque Technologique Risque Technologique Risque Technologique Nature Menace Menace Menace Menace Menace Erreur Erreur Erreur Erreur Composant Logiciel Composant Logiciel Composant Logiciel Composant technique Composant technique Composant technique Type Espionnage industriel Criminalit informatique Intrusion Hacker Terrorisme Comprhension Manipulation Choix Conception Perte dintgrit Perte de disponibilit Perte de confidentialit Perte dintgrit Perte de disponibilit Perte de confidentialit p (%) 100 100 100 50 10 50 50 50 100 50 10 100 10 100 10 100 100 50 50 10 100 50 100 100 100 100 100 100 100 100 i 100 100 50 25 1 50 25 50 100 50 10 100 10 100 10 Nr

69

ID 16 17 18 19 20 21 22 23 24 25

Catgorie Risque Technologique Risque Technologique Risque Technologique Risque dactivit Risque dactivit Risque dactivit Risque dactivit Risque dactivit Risque dactivit Risque dactivit Risque dactivit Risque dactivit Risque Naturel Risque Naturel Risque Naturel Risque Naturel

Nature Donne Donne Donne Production Production Production Organisation Organisation Organisation Gestion Gestion Gestion Inondation Foudre Gel Canicule

tel-00748984, version 1 - 6 Nov 2012

26 27 28 29 30 31

Type Perte dintgrit Perte de disponibilit Perte de confidentialit Perte de capacit Perte dintgrit Perte de disponibilit Perte de capacit Perte dintgrit Perte de disponibilit Perte de capacit Perte dintgrit Perte de disponibilit Perte de disponibilit Perte de disponibilit Perte de disponibilit Perte de disponibilit

p (%) 100 10 10 10 10 10 50 10 10 100 100 100 50 50 10 10 100 100 100 50 10 10 50 10 10 50 50 50 100 50 10 10

i 100 10 10 5 1 1 25 1 1 50 50 50 50 25 1 1

Nr

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 rtrocorrection) 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.

tel-00748984, version 1 - 6 Nov 2012

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.

tel-00748984, version 1 - 6 Nov 2012

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 lexcuti on 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
Assurer la conformit rglementaire Passer dun taux de conformit des processus de 95% 100% dans 3 mois Passer dun taux de conformit des ressources de 95% 100% dans 3 mois

tel-00748984, version 1 - 6 Nov 2012

Axe valeur et performance

Processus daudit Taux de projet non conforme Taux de processus non conforme Taux de ressources non conforme Processus de mise en conformit Taux de correction des projets Taux de correction des processus Taux de correction des ressources

Axe Risque
Risque humain Falsification des informations daudit Erreur de conception pour la ringnierie Risque technologique Perte de confidentialit Risque dactivit Perte de disponibilit des outils mtier

Axe Ressource
Ressources humaines Nombre dauditeurs expriment Ressources techniques Disponibilit des outils daudit Disponibilit des outils correctifs Ressources informationnelles 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 +ID: Integer +nom: String +date: Date Dcision +ID: Integer +description: String +date: Date 0..* Action +ID: Integer 1..* +description: String opportunits

< repose sur

1..* But +ID: Integer +description: String +date: Date

Situation gnre Situation +ID: Integer +description: String Situation prvue

Ajustement

tel-00748984, version 1 - 6 Nov 2012

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

tel-00748984, version 1 - 6 Nov 2012

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 Charge restante (j.h) Taille de lquipe (h) Dure du projet (j) Vitesse (h/j) Date de fin Planifi (1er septembre) Situation prvue 300 5 300/5 = 60 5 1er Dcembre Constat (15 octobre) Situation gnre 100 5 100/6.666 = 15 200/30 = 6.666 7 novembre Planifi (15 octobre) Aprs Ajustement 100 4 100/4 = 25 4 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 +description: String But +ID: Integer +description: String +date: Date 1 Action <impacte +ID: Integer 0..1 1 +description: String < impacte 0..1

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

tel-00748984, version 1 - 6 Nov 2012

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.

tel-00748984, version 1 - 6 Nov 2012

77

tel-00748984, version 1 - 6 Nov 2012

Chapitre 5. PROGOUV : processus de la GSI

5.1. Introduction

Modle

de

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.

tel-00748984, version 1 - 6 Nov 2012

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
Mthode traduit par >

Concepts de la CARTE
CARTE affin par 0..1 Section 1..* 1..* 1..* <<Intention>> Dbut <<Intention>> Fin

tel-00748984, version 1 - 6 Nov 2012

+composant 1..* Composant de mthode traduit par >

1..*

+source +cible 1 1 Intention

Stratgie

Reprsentation
lien (stratgie)
Dbut
Par CB

section
Payer une commande
Par facturation

Par chque

nud (intention)

Fin

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

Dbut (a)
2

Par construction oriente but

Par slection de projet

Par identification des facteurs dvaluation Par rsonance

1

Identifier un projet (b)

1

Par classification dexpert

1 1

Par valuation dexpert

1

Par application des fonctions de prfrence

Evaluer un projet (c)

Classer le projet dans un portefeuille (d)

1

dun projet
dun portefeuille
2

Par identification des facteurs dvaluation

Par slection

Fin (e)
1

Par non concurence

Figure 5.2. Un exemple de CARTE : Excuter un portefeuille de projets

tel-00748984, version 1 - 6 Nov 2012

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 :

tel-00748984, version 1 - 6 Nov 2012

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

tel-00748984, version 1 - 6 Nov 2012

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

tel-00748984, version 1 - 6 Nov 2012

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).

tel-00748984, version 1 - 6 Nov 2012

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 de processus PROGOUV concern Is (a) S1 Prsentation graphique des concepts REFGOUV concerns : DSI/DSS : tat de la situation de REFGOUV DAI : production dinstances de composants REFGOUV
C1 C2
* * +a4

S2

Ic (b)

+a1 +a2

+a3

Prsentation graphique de directive tactique

Prsentation graphique dune directive simple

DXX : <(Situation), Intention de navigation>

DAI : <(Situation), Intention de navigation>

(arg1)
SelectionDXX1()

OU

(argN)) SelectionDXXN() Activit 1

ET
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

tel-00748984, version 1 - 6 Nov 2012

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 multisegment (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 d e 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.

tel-00748984, version 1 - 6 Nov 2012

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 .

tel-00748984, version 1 - 6 Nov 2012

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).

tel-00748984, version 1 - 6 Nov 2012

Classe +Attribut
1

a 1..*

0..*

< porte sur

Etat
0..* exprime

Intention Source Concept REFGOUV CARTE +ID +Objectif

0..1 affine 0..* manipule 2..* 0..* 1..* a pour source 1 <porte sur 1

DSI +ID
1 1 Situation 1 1..*

excute 1..* <porte sur DSS 1..*

Intention DXX +IntentionNav +ID +Intitul

Stratgie +ID +Intitul

0..*

Section +ID

+ID
1 excute

a pour cible <porte sur 1 1..* 1

1..*

0..* Argument

DAI +ID

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.

tel-00748984, version 1 - 6 Nov 2012

Les conventions de codification locale que nous proposons sont les suivantes : Type index Structure dindex Intention k (Intention.ID) k: Enum{az} Commentaire Exemple Index compos dun incrment Figure 5.2 : k=b se alphabtique k. Cela permet rfre lintention dindexer jusqu 26 intentions Identifier un projet par carte. Index compos dun incrment Figure 5.2 : j=1 peut se 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. Index compos dun identifiant Figure 5.2 : ab1 se rfre 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

Stratgie (Stratgie.ID)

j j: {N+*}

Section (Section.ID)

kkj

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 CARTE (CARTE.ID)

Structure dindex {C{kkj}+.}*

Intention {C{kkj}+.}*k (Intention.ID) k: Enum{az} {C{kkj}+.}*kkj

Section (Section.ID)

DSI (DSI.ID)

DSI-{C{kkj}+.}*k

DSS (DSS.ID)

DAI (DAI.ID)

DSI-C.a : directive de slection dintention associ lintention source k=a de la CARTE racine C DSS-{C{kkj}+.}*kk DSS-C.ac : directive de slection de stratgie associe la slection de stratgie qui sopre entre lintention source k=a et lintention cible k=c de la CARTE racine C. DAI-{C{kkj}+.}*kkj Index compos du mot DAI DAI-C.ac1 : directive 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

tel-00748984, version 1 - 6 Nov 2012

Commentaire Une carte est identifie par une chane de caractres constitue de la lettre C, dun index local de section lorsque celle-ci affine une section et dun incrment hirarchique . . Index compos de lindex hirarchique de la CARTE et de lindex local k dune intention Index compos de lindex hirarchique de la CARTE et de lindex local k dune intention Index compos du mot DSI agrg de lindex hirarchique de lintention source depuis laquelle sopre une slection dintention Index compos du mot DSS agrg de lindex hirarchique de rfrence de la CARTE et des index locaux k et k des intentions source et cible

Exemple CARTE C, racine hirarchique CARTE C.Cab1 : CARTE daffinement de la section ab1 de la carte racine C C.a : intention a de la CARTE racine C

C.ab1 : section ab1 de la CARTE racine C

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.

Niveau dabstraction lev

Abstraction intentionnelle

C.Cab1

C.Cbb1

C.Cbb2

Niveau dabstraction intermdiaire

[]

[]

tel-00748984, version 1 - 6 Nov 2012

C.Cab1 .ab1 .ac1 C.C ab1 C.Cab1 .ac2.bb1 C.C ab1 C.Cab1 .bc1 .bd1 C.C ab1 C.Cab1 .cb1 .cd1 C.C ab1

Niveau oprationnel

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 perturbat eurs 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.
Dbut (a)
2
Par identification des buts de GSI

1
Par integration de lexistant

Par planification des projets

tel-00748984, version 1 - 6 Nov 2012

Gouverner le SI (b)
2
Par prise de dcision

Fin (c)

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 DSI-C.a DAI Sections de la carte C 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 DSS DSS-C.ab

tel-00748984, version 1 - 6 Nov 2012

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.

Dbut (a)
2

Par identification des buts de GSI

1
Par integration de lexistant

But

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
*

Gouverner le SI (b)
1

But

Projet * 0..1 <impacte 1 Action 1

0..1 < impacte

Fin (c)

Par historisation

Par prise de dcision

tel-00748984, version 1 - 6 Nov 2012

DSI-C.b: <(But.tat= jour projet.tat= jour action.tat=termine), Progresser depuis Gouverner le SI> (arg1) Slectionner(DSS-C.bb) arg1 : Les actions de gouvernance ont t appliques (arg1)

Slectionner(DSS-C.bc)

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 (DSSC.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 depui s 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

Dbut (a)
2

Par identification des buts de GSI

1
Par integration des buts existants

But

Gouverner le SI (b)

DSS-C.ab : <(C.tat= actif but.tat=identifi), Progresser vers Gouverner le SI depuis Dbut> (arg2) (arg )
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

tel-00748984, version 1 - 6 Nov 2012

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 multisegment 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 SI (b)

Par prise de dcision

DSS-C.bb : <(but.tat= jour ou projet.tat= jour), Progresser vers Gouverner le SI depuis Gouverner le SI> (arg2) (arg )
1

Slectionner(DAI-C.bb1) arg1 : Les buts sont exploitables arg2 : Les projets sont exploitables

Slectionner(DAI-C.bb2)

tel-00748984, version 1 - 6 Nov 2012

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)
1

Action

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 :

tel-00748984, version 1 - 6 Nov 2012

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
1..*

Gouverner le SI (b)

1..*

Action

Fin (c)

oppotunits

1..*

1 1 < impacte 0..1

Par historisation

But
1..* 0..* * value 1..* * <impacte 0..1

Indicateur

Projet

DAI-C.bc1 : <(action.tat= jour ou ProcessusGSI.dateFin<=Date.TODAY), Finir par historisation>

1:<(action.tat= jour), analyser les situations de dcision>

2:<(Dcision.tat=analyse), dater les tats de la situation>

3:<(action.tat= jour et ProcessusGSI.dateFin<=Date.TODAY), dater les tats des projets>

tel-00748984, version 1 - 6 Nov 2012

2.1:<(Dcision.tat=analyse) , dater les tats des indicateurs>

2.2:<(Dcision.tat=analyse) , dater les tats des actions>

2.3:<(Dcision.tat=analyse) , dater les tats des buts>

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
5.3.3.1. Composant graphique
(a)
2 1 1

(b)
1

Section ab1 de la carte C affine par la carte C.Cab1

2

(c)

Par affinement

Par compltude

Fin (d)
1

tel-00748984, version 1 - 6 Nov 2012

Par analyse des priorits de gouvernance

Identifier un but de GSI (b)

1

Par analyse linguistique

Par compltude

Dbut (a)

Par application CQG

Identifier la catgorie de but (c)

Par dfinition de domaine

Par dfinition de 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 DSI- C.Cab1.a

DAI Sections de la carte C1.1 DAI- C.Cab1.ab1 ab1 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. Composants de guidage pour la slection dintention 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

DSS DSS- C.Cab1.ab DSS- C.Cab1.ac

tel-00748984, version 1 - 6 Nov 2012

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 lidentif ication 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 priorits de gouvernance

Identifier un but de GSI (b) Identifier la catgorie de but (c)

Par dfinition de domaine Par dfinition de critre
1

Connaissance

Dbut (a)

DSI- C.Cab1.a : <(Connaissance.tat= jour), Progresser depuis Dbut> (arg1) Slectionner(DSS- C.Cab1.ab)

(arg2) (arg3)
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

tel-00748984, version 1 - 6 Nov 2012

excutes de manire simultane, alors que la DSS Progresser vers Fin but depuis Identifier un but de GSI sera exclusive.

Par affinement
1

Par compltude
1
Fin (d)

But

Catgorie 1..* 1

Identifier un but de GSI (b)

Par analyse linguistique

Identifier la catgorie de but (c)

DSI-C.Cab1.a : <(((But.tat= jour) + (But.tat= identifi)) (Catgorie.tat=identifie)), Progresser depuis Identifier un but de GSI> (arg1) Slectionner(DSS-C.Cab1.bb ) (arg2) (arg1) (arg2)

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 de GSI (b)

1

Par compltude

Catgorie

Identifier la catgorie de but (c)

DSI-C.Cab1.c : <(Catgorie.tat=identifie), Progresser depuis identifier la catgorie de but>

(arg1)
Slectionner(DSS-C.Cab1.cb)

(arg1)
Slectionner(DSS-C.Cab1.cd)

arg1 : Les buts couvrent lensemble des besoins de GSI

Figure 5.16. Description de la directive DSI-C.Cab1.c.

tel-00748984, version 1 - 6 Nov 2012

5.3.3.3. Composants de guidage pour la slection de stratgie 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

Dbut (a)
Par dfinition de domaine Par dfinition de critre
1

Identifier la catgorie de but (c)

Connaissance

DSS-C.Cab1.ac: <(Connaissance.tat= jour), Progresser vers identifier la catgorie de but depuis dbut> (arg1) Slectionner(DAI-C.Cab1.ac2) (arg2) 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.

tel-00748984, version 1 - 6 Nov 2012

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 (DAIC.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 Cette directive tactique offre le seul choix possible de slectionner la stratgie par compltude et contraint la slectionner la directive daccomplissement dintention (DAIC.Cab1.bd1). 5.3.3.3.6. DSS- C.Cab1.cb : Progresser vers Identifier un but de GSI depuis Identifier la catgorie de but Cette directive tactique offre le seul choix possible de slectionner la stratgie par application CQG et contraint slectionner la directive daccomplissement dintention (DAIC.Cab1.cb1).

104

5.3.3.3.7. DSS- C.Cab1.cd : Progresser vers Fin depuis Identifier la catgorie de but Cette directive tactique offre le seul choix possible de slectionner la stratgie par compltude et contraint slectionner la directive daccomplissement dintention (DAIC.Cab1.cd1). 5.3.3.4. Composants de guidage pour laccomplissement dintention 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 l es 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.

tel-00748984, version 1 - 6 Nov 2012

La directive, de nature tactique, directive est ainsi dcrite la figure 5.18.

105

Par analyse des priorits de gouvernance

But

Identifier un but de GSI (b)

Dbut (a)

+ID: Integer +description: String +date: Date

DAI-C.Cab1 .ab1 : <(Connaissance.tat= jour), Identifier un but de GSI par analyse des priorits de gouvernance>

1:<(Connaissance.tat= jour), Identifier les objectifs stratgiques>

2:<(Objectifs stratgique.tat=identifi), Identifier les buts de GSI associs aux 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

tel-00748984, version 1 - 6 Nov 2012

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

Catgorie

Domaine GSI +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

tel-00748984, version 1 - 6 Nov 2012

tre performante, gnratrice de valeur et mature. Nous dfinissons ainsi les critres de Valeur , Performance et Maturit pour la catgorisation des buts de GSI.

Catgorie

Critre +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 .

tel-00748984, version 1 - 6 Nov 2012

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

1..*

+nom
0..* 0..* 0..* 0..*

Mot +intitul +dfinition

Critre +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

tel-00748984, version 1 - 6 Nov 2012

But +ID +description +date Catgorie

1..* 1

Figure 5.23. Composant de REFGOUV produit par DAI-C.Cab1.cb1 5.3.3.4.8. DAI-C.Cab1.cd1 : Compltude Le processus dlaboration des buts se termine lorsque lensemble des besoins stratgiques sont couverts par les buts identifis. Finir depuis Identifier la catgorie de but par

109

5.3.3.5. Composant produit 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 > 0..*

+nonc

But +ID +description +date

Catgorie
1..* 1

Domaine GSI
1..*

+nom
0..* 0..* 0..* 0..*

Mot +intitul +dfinition

Critre +nom

tel-00748984, version 1 - 6 Nov 2012

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
5.3.4.1. Composant graphique
Par dcoupage Par portefeuille

1
Par mise jour

Par construction de composants

Identifier un projet (b)

1
Par cration de tableau de bord Par GQM

Fin (e)
Par suivi Sans suivi 2

Dbut (a)
2

Par but

Par finalisation

2
Par indicateur

Par GQM

Excuter un projet(d)

Par continuit

1
Par reprise de mtriques

Identifier une mesure(c)

Par mtrique de composant projet

1
Par adaptation

1 1
Par reprise de planification

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 f orment 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

tel-00748984, version 1 - 6 Nov 2012

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 DSI-C.Cbb1.a DAI Sections de la carte C.Cbb1 DAI-C.Cbb1.ad1 ad1 DAI-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 DSS DSS-C.Cbb1.ad DSS-C.Cbb1.ac

111

5.3.4.2. Composants de guidage pour la slection dintention 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.

tel-00748984, version 1 - 6 Nov 2012

Par mise jour

2
Par but

Identifier un projet (b) 1 Identifier une mesure(c)

Par reprise de planification
But * * Projet

Dbut (a) 1

Par GQM

2
Par reprise de mtriques

Excuter un projet(d)

DSI- C.Cbb1.a : <(Projet.tat= historis But.tat= identifi), Progresser depuis Dbut> (arg1) Slectionner(DSS- C.Cbb1.ab) (arg2) Slectionner(DSS- C.Cbb1.ac) ((arg1) (arg2)) 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 dcoupage

Par portefeuille

Par construction de composants

Projet
1..* 1..* * *

But
1..* a pour objectif 1..*

2 Identifier un projet (b)

1 2

Par suivi
Sans suivi

Tableau de bord

tel-00748984, version 1 - 6 Nov 2012

Par GQM

Excuter un projet(d)

Indicateur
1..* value

Mtrique

Identifier une mesure(c)

drive

DSI- C.Cbb1.b : <(Projet.tat= identifi But.tat= identifi), Progresser depuis Identifier un projet> (arg1) Slectionner(DSS- C.Cbb1.bb) (arg2) Slectionner(DSS-C.Cbb1.ac) ((arg1) (arg2)) 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

2
Par cration de tableau de bord

Par indicateur

Identifier une mesure(c) 1

Par mtrique de composant projet

Mtrique

1..*

1..*

But

a pour objectif

Identifier un projet (b)

DSI- C.Cbb1.c : <(Mtrique.tat= identifi But.tat= identifi), Progresser depuis Identifier une mesure> (arg1) Slectionner(DSS-C.Cbb1.cc) (arg2) Slectionner(DSS-C.Cbb1.cb)

arg1 : La mesure est incomplte dans sa dfinition arg2 : Besoin dorganiser les mesures pour un projet

tel-00748984, version 1 - 6 Nov 2012

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)

Par finalisation

Projet

Excuter un projet(d) Identifier une mesure(c)

1
Par adaptation

Par continuit

DSI- C.Cbb1.d : <(Projet.tat= en-cours), Progresser depuis Excuter un projet> (arg1) Slectionner(DSS-C.Cbb1.dc) (arg2) (arg3) 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. Composants de guidage pour la slection de stratgie 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

2
Par but

Identifier un projet (b) 1

But

* *

Projet

Dbut (a)

tel-00748984, version 1 - 6 Nov 2012

DSS- C.Cbb1.ab : <(Projet.tat= historis But.tat= identifi), Progresser vers identifier un projet depuis Dbut> (arg1) Slectionner(DAI-C.Cbb1.ab2) (arg2) 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 u ne 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 (a)

Par GQM

1
Par reprise de mtriques

Mtrique

1..*

1..*

But

Identifier une mesure(c)

a pour objectif

DSS- C.Cbb1.ab : <(Mesure.tat= historis But.tat= identifi), Progresser vers identifier une mesure depuis Dbut> (arg1) Slectionner(DAI-C.Cbb1.ac1) (arg2) Slectionner(DAI-C.Cbb1.ac2)

arg1 : Besoin dintgrer des mesures existantes arg2 : Ncessit de construire de nouvelles mesures

tel-00748984, version 1 - 6 Nov 2012

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

Par dcoupage

Par portefeuille

1 Identifier un projet (b)

Par construction de composants

dcoup par > 0..1

Portefeuille

0..*

Projet

1..*

DSS- C.Cbb1.bb : <(Projet.tat= identifi), Progresser vers identifier un projet depuis identifier un projet> (arg1) Slectionner(DAI-C.Cbb1.bb2) (arg2) (arg1) (arg3)

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

tel-00748984, version 1 - 6 Nov 2012

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 DAIC.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.

Identifier un projet (b)

1 2

Par suivi
caractristique

Sans suivi
1 Projet

1..*

< value * 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)
Slectionner(DAI-C.Cbb1.bd1)

(arg1) 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.

tel-00748984, version 1 - 6 Nov 2012

Par indicateur

Identifier une mesure(c)

Par mtrique de composant projet

caractrisitique

< value *

Mtrique

DSS- C.Cbb1.cc : <(Mtrique.tat= identifie caractristique.tat= identifie), Progresser vers Identifier une mesure depuis Identifier une mesure>

(arg1)
Slectionner(DAI-C.Cbb1.cc2)

(arg2) 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 DAIC.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.

Excuter un projet(d)

Par finalisation Par continuit

1 2
Projet
1 1..*

caractristique

Fin (e)

DSS- C.Cbb1.de : <(Projet.tat=en-cours), Progresser vers Fin depuis Excuter un projet>

(arg1)
Slectionner(DAI-C.Cbb1.de2) arg1 : Le projet ne peut tre finalis

(arg1) Slectionner(DAI-C.Cbb1.de1)

tel-00748984, version 1 - 6 Nov 2012

Figure 5.35. Description de la directive DSS-C.Cbb1.de. 5.3.4.4. Composants de guidage pour laccomplissement dintention 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 +nom: String +date: Date +description: String

1..*

Ressource +ID: Integer +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..*

Projet

1..*

Ressource +ID: Integer +Nom: String

Mtrique
< value 0..* 0..*

tel-00748984, version 1 - 6 Nov 2012

+nom: String +date: Date +description: String

+ID: Integer +description: String +dim: Object +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 M etrics) 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 o M11 : Dure moyenne des temps de rponse M12 : Nombre de cas au dessus de la limite

Q2 : Quelle est la dviation du temps de rponse actuel sur lobjectif ?

120

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 +ID: Integer +description: String +date: Date

Mtrique
a pour objectif 1..* 1..*

+ID: Integer +description: String +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

tel-00748984, version 1 - 6 Nov 2012

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 +ID: Integer +description: String +date: Date

* *

Projet +nom: String +date: Date +description: String

a 1 caractristique 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 sousprojets 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 +nom +date +description

1..*

Figure 5.40. Composant de REFGOUV produit par DAI-C.Cbb1.bb1 5.3.4.4.7. DAI-C.Cbb1.bb2 : Identifier un projet depuis Identifier un projet par

tel-00748984, version 1 - 6 Nov 2012

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 +ID: Integer +nom: String +date: Date

1..* 1..*

Projet +nom: String +date: Date +description: String Portefeuille

0..*

+ID: Integer

Figure 5.41. Composant de REFGOUV produit par DAI-C.Cbb1.bb2 5.3.4.4.8. DAI-C.Cbb1.bb3 : Identifier un projet depuis Identifier un projet par 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..*

Processus +ID +Nom

Ressource +ID +Nom

Risque +ID +Nom

Figure 5.42. Composant de REFGOUV produit par DAI-C.Cbb1.bb3 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,

tel-00748984, version 1 - 6 Nov 2012

sont les buts associs aux projets identifis.

affin par > 0..*

But +ID: Integer +description: String +date: Date

Mtrique
a pour objectif 1..* 1..*

+ID: Integer +description: String +dim: Object +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 partag es 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.

Mtrique caractristique +nom: String

1..* a 1 < value * *

Indicateur +intitul: String +forme: Object +valeur: Integer +valeurMIN: Integer +valeurMAX: Integer +date: Date
1..*

+ID: Integer +description: String +dim: Object +valeur: String

Projet +nom: String +date: Date +description: String

Tableau de bord +ID: Integer +nom: 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 ISO27004, 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

tel-00748984, version 1 - 6 Nov 2012

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

caractristique
a

< value *

Mtrique
* +ID: Integer +description: String +dim: Object +valeur: String

+nom: String
1 1..*

Projet +nom: String +date: Date +description: String

0..* < value < value

0..* 0..*

< value 0..* 0..* Risque +ID: Integer +Nom: String 0..* Processus +ID: Integer +Nom: String

Ressource 1..* +ID: Integer +Nom: String 1..*

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 +ID +description +dim +valeur +intitul +forme +valeur +valeurMIN +valeurMAX +date

Figure 5.46. Composant de REFGOUV produit par DAI-C.Cbb1.cc2 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

tel-00748984, version 1 - 6 Nov 2012

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 +ID: Integer +description: String +date: Date < repose sur

Indicateur Tableau de bord

1..*

Projet +nom: String +date: Date +description: String

1..*

+ID: Integer +nom: String +date: Date

+intitul: String +forme: Object 1..* +valeur: Integer +valeurMIN: Integer +valeurMAX: Integer +date: Date

+axeRessource

+axeProcessus

+axeRisque

+axeBut

Ressource +ID: Integer +Nom: String

Processus +ID: Integer +Nom: String

Risque +ID: Integer +Nom: String

But +ID: Integer +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 +nom: String +date: Date +description: String 1

a 1..*

caractristique +nom: String

Mtrique < value * * +ID: Integer +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

tel-00748984, version 1 - 6 Nov 2012

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. 5.3.4.5. Composant produit 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 a 1..*

Portefeuille +ID: Integer

0..* 0..1

Projet +nom: String +date: Date +description: String

1..* 1..*

caractristique +nom: String

+ID: Integer * < value +description: String +dim: Object +valeur: String
0..* 0..* 0..*

affin par > 1..* 1..* a pour objectif * 0..*

But +ID: Integer +description: String +date: Date

dcoup par >

< value

< value 0..* Processus +ID: Integer +Nom: String 1..* Risque +ID: Integer +Nom: String 1..* +axeProcessus +axeRisque +axeRessource < value

Indicateur +intitul: String +forme: Object +valeur: Integer +valeurMIN: Integer +valeurMAX: Integer +date: Date
1..*

0..* 1..* 0..*

Ressource +ID: Integer +Nom: String

Tableau de bord +ID: Integer +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

5.3.5.1. Composant graphique
1
Par suivi des projets

Dbut (a)
2

Identifier un but dajustement de la gouvernance SI (b)

2
Par valuation des risques

Par adaptation vnementielle

Par valuation daccomplissement du but

Par valuation des processus Par valuation des 3 ressources

Prendre une Dcision (c)

2

Par impact sur les buts 1

tel-00748984, version 1 - 6 Nov 2012

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 DSI-C.Cbb2.a DSS DAI Sections de la carte C.Cbb2 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. Composants de guidage pour la slection dintention 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 (DSSC.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

tel-00748984, version 1 - 6 Nov 2012

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)

Par impact sur les 1 buts 2 Sans impact

1
Dcision

Fin (d)

Par analyse de TdB

Par impact sur les projets

+ID: Integer +description: String +date: Date

DSI- C.Cbb2.c : <(Dcision.tat=prise), Progresser depuis Prendre une dcision> (arg1) (arg1) Slectionner(DSS-C.Cbb2.cc)

Slectionner(DSS-C.Cb21.cd)

arg1 : Il existe des actions identifies correspondantes la dcision

tel-00748984, version 1 - 6 Nov 2012

Figure 5.51. Description de la directive DSI-C.Cbb2.c. 5.3.5.3. Composants de guidage pour la slection de stratgie 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 (a)

Par suivi des projets

Situation +ID: Integer +description: String

2
Par adaptation vnementielle

Identifier un but dajustement de la gouvernance SI (b)

Situation gnre

Situation prvue

DSS- C.Cbb2.ab : <(Situation.tat= cre), Progresser vers Identifier un but dajustement de la GSI depuis dbut>

(arg1)
Slectionner(DAI-C.Cbb2.ab1)

(arg2) Slectionner(DAI-C.Cbb2.ab2)

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.

tel-00748984, version 1 - 6 Nov 2012

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

Identifier un but dajustement de la gouvernance SI (b)

1
Par valuation daccomplissement du but

Par valuation des risques

But +ID: Integer +description: String +date: Date

Par valuation des ressources

Par valuation des processus

Prendre une Dcision (c)

Ajustement

DSS- C.Cbb2.bc : <(Ajustement.tat=cr), Progresser vers Prendre une dcision depuis Identifier un but dajustement de la GSI> (arg2) Slectionner(DAIC.Cbb2.bc2) arg1 : Lajustement porte sur un but arg2 : Lajustement porte sur un processus arg3 : Lajustement porte sur une ressource arg4 : Lajustement porte sur un risque Slectionner(DAIC.Cbb2.bc1) (arg1) (arg3) Slectionner(DAIC.Cbb2.bc3) (arg4) Slectionner(DAIC.Cbb2.bc4)

Figure 5.53. Description de la directive DSS-C.Cbb2.bc.

tel-00748984, version 1 - 6 Nov 2012

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

Par impact sur les buts

1
Fin (d)
Sans impact

Prendre une Dcision (c)

2
Dcision +ID: Integer +description: String +date: Date 1..* oppotunits Action +ID: Integer +description: String

3
Par impact sur les projets

DSS- C.Cbb2.bc : <(Dcision.tat=cr Action.tat=identifie), Progresser vers Fin depuis Prendre une dcision > (arg1) ((arg2) (arg1)) Slectionner(DAI-C.Cbb2.cd2)

(arg2)
Slectionner(DAI-C.Cbb2.cd3)

Slectionner(DAI-C.Cbb2.cd1)

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.

tel-00748984, version 1 - 6 Nov 2012

5.3.5.4. Composants de guidage pour laccomplissement dintention 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 des projets

Projet
* * a pour objectif 1..*

1..*

Mtrique 0..* < valuer

Dbut (a)

Identifier un but dajustement de la gouvernance SI (b)

But

0..*

Situation 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), identifier situation gnre>

2:<(situation gnre.tat=identifie), mesurer les carts de situation>

3:<(situation gnre.tat=mesure), formuler le but dajustement>

2.1:<(situation gnre=identifie), mesurer la situation gnre>

2.2:<(situation prvue=mesure), mesurer lcart>

Figure 5.55. Description de la directive DAI-C.Cbb2.ab1

tel-00748984, version 1 - 6 Nov 2012

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..* a pour objectif

Mtrique 0..* < valuer

Dbut (a)
2

Identifier un but dajustement de la gouvernance SI (b)

But

1..* 0..*

Situation Ajustement

Par adaptation vnementielle

Situation gnre

Situation prvue

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>

1:<(situation.tat=cr), identifier situation gnre>

2:<(situation gnre.tat=identifie), mesurer les carts de situation>

3:<(situation gnre.tat=mesure), formuler le but dajustement>

2.1:<(situation gnre=identifie), mesurer la situation gnre>

2.2:<(situation prvue=mesure), mesurer lcart>

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

tel-00748984, version 1 - 6 Nov 2012

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.

But +ID: Integer +description: String +date: Date

a pour objectif 1..* value 1..* 1..*

Mtrique +ID: Integer +description: String +dim: Object +valeur: String

Indicateur +intitul: String +forme: Object +valeur: Integer +valeurMIN: Integer +valeurMAX: Integer +date: Date
0..*

1..*

Ajustement

Critre +nom: String Action +ID: Integer +description: String

1..* opportunits

Dcision +ID: Integer +description: String +date: Date

Figure 5.57. Composant de REFGOUV produit par DAI-C.Cbb2.bc1

134

5.3.5.4.4. DAI-C.Cbb2.bc2 : Prendre une dcision depuis Identifier un but dajustement de 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).

tel-00748984, version 1 - 6 Nov 2012

drive

< value 0..* 0..*

Mtrique +ID: Integer +description: String +dim: Object +valeur: String

Indicateur +intitul: String +forme: Object +valeur: Integer +valeurMIN: Integer +valeurMAX: Integer +date: Date
0..*

Processus +ID: Integer +Nom: String

Critre +nom: String Action +ID: Integer +description: String

1..*

Dcision

+ID: Integer opportunits +description: String +date: Date

Figure 5.58. Composant de REFGOUV produit par DAI-C.Cbb2.bc2 5.3.5.4.5. DAI-C.Cbb2.bc3 : Prendre une dcision depuis Identifier un but dajustement de 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

Mtrique
< value 0..* 0..*

Indicateur +intitul: String +forme: Object +valeur: Integer +valeurMIN: Integer +valeurMAX: Integer +date: Date
0..*

+ID: Integer +description: String +dim: Object +valeur: String

Risque +ID: Integer +Nom: String Critre +nom: String Action +ID: Integer +description: String
1..* opportunits

Dcision +ID: Integer +description: String +date: Date

Figure 5.59. Composant de REFGOUV produit par DAI-C.Cbb2.bc3 5.3.5.4.6. DAI-C.Cbb2.bc4 : Prendre une dcision depuis Identifier un but dajustement de

tel-00748984, version 1 - 6 Nov 2012

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

< value 0..*

0..*

Mtrique +ID: Integer +description: String +dim: Object +valeur: String

Indicateur +intitul: String +forme: Object +valeur: Integer +valeurMIN: Integer +valeurMAX: Integer +date: Date
0..*

Ressource +ID: Integer +Nom: String

Critre +nom: String

1..*

Action +ID: Integer +description: String

Dcision +ID: Integer +description: String +date: Date

opportunits

Figure 5.60. Composant de REFGOUV produit par DAI-C.Cbb2.bc4

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 +Nom: String 0..*

< value < value 0..*

Mtrique +ID: Integer +description: String +dim: Object +valeur: String

1..*

Indicateur +intitul: String +forme: Object +valeur: Integer +valeurMIN: Integer +valeurMAX: Integer +date: Date

Processus +ID: Integer +Nom: String

0..*

0..* 0..* 1..*

< value

Risque +ID: Integer +Nom: String

0..*

But +ID: Integer +description: String +date: Date

value opportunits

Action +ID: Integer +description: String

1..*

tel-00748984, version 1 - 6 Nov 2012

1..*

Ajustement
+axeBut

Critre +nom: String

+axeRisque +axeRessource

Tableau de bord +ID: Integer +axeProcessus +nom: String +date: Date

< repose sur

Dcision +ID: Integer +description: String +date: Date

Figure 5.61. Composant de REFGOUV produit par DAI-C.Cbb2.cc1 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 +description: String +date: Date

opportunits

But +ID: Integer +description: String +date: Date

0..1 < impacte 1

1..*

Action +ID: Integer +description: String

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

tel-00748984, version 1 - 6 Nov 2012

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 Projet Opration Crer() ChangerBut() AjouterRessource() RetirerRessource() AjouterRisque() RetirerRisque() Suspendre() Supprimer() Crer() Adapter() Supprimer() Description Les oprations sur les projets permettent dadapter lexcution dun projet en modifiant ses buts et en modulant ses ressources et ses risques. Le projet peut tre suspendu pour tre repris un moment ultrieur ou tre dfinitivement supprim. Les oprations sur les processus permettent de grer leurs cycles de vie. Lopration Adapter() est utilis pour raliser une ringnierie du processus du projet. Ces oprations sont utilises pour moduler les ressources dun projet.

Processus

Ressource

Risque

Crer() Modifier() Supprimer() 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 +description: String +date: Date Ressource +ID: Integer +Nom: String +crer() +modifier() 1..* +supprimer() Risque +ID: Integer +Nom: String +crer() +moduler() +supprimer() Processus +ID: Integer +Nom: String +crer() +adapter() +supprimer()
opportunits 1..*

Projet +nom: String +date: Date +description: String +crer() +changerBut() +ajouterRessource() +retirerRessource() +ajouterRisque() +retirerRisque() +suspendre() +supprimer()
0..1 1

Action +ID: Integer +description: String

<impacte

* *

But +ID: Integer +description: String +date: Date +crer() +ModifierCatgorie() +Suspendre() +Supprimer()

1..*

tel-00748984, version 1 - 6 Nov 2012

Figure 5.63. Composant de REFGOUV produit par DAI-C.Cbb2.cd3

139

5.3.5.5. Composant produit 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

Action
1 1

opportunits 1..* <impacte

Dcision

< repose sur

Tableau de bord
1..*

1..*

Indicateur

+axeProcessus 0..1 < impacte 1..* +axeRisque +axeRessource Mtrique 0..* 0..* 0..*0..* < value 1..* Ressource 0..* 1..* 0..* 0..* Processus < value < value drive

Projet
*

affin par > 0..1

tel-00748984, version 1 - 6 Nov 2012

But
0..*

Ajustement

Risque

Situation prvue

Situation gnre

Situation

0..*

< valuer

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.

tel-00748984, version 1 - 6 Nov 2012

141

tel-00748984, version 1 - 6 Nov 2012

Chapitre 6. Evaluation
6.1. Introduction
Nous discutons dans ce chapitre de la validation de nos hypothses de travail : H1 : la GSI est un artfact que lon peut conceptualiser. o o H11 : Le domaine de la GSI manipule un ensemble dlments conceptualisables. H12 : Le processus de la GSI est conceptualisable. H2 : un systme dinformation de gouvernance correctement conceptualis est utile la bonne mise en uvre de lactivit de gouvernance Lvaluation de notre proposition (REFGOUV et PROGOUV) repose sur deux aspects : (i) une

tel-00748984, version 1 - 6 Nov 2012

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

tel-00748984, version 1 - 6 Nov 2012

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 Au dit 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 s ous 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

tel-00748984, version 1 - 6 Nov 2012

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
Modle de maturit 1 Dfinit par 1 Ressource TI Role 1..* 1..* Entre Element Sortie 1..* 0..* Produit Consomme 0..* 0..* 1 Activit 1..* 1..* 1..4 0..* 1..* 1..5 0..* Domaine Contrle 1..* 1..* But TI ButCOBIT 1..* Mesur par 1..* Indicateur de but TI Indicateur de but de processus Indicateur de perf. IndicateurCOBIT 1..* 1..* Mtrique 1..7 Critre information 1..* Niveau maturit

Domaine de gouv.

ProcessusCOBIT 1 *

1..* 1..* Objectif de contrle 1..* 1..* But mtier

1..*

But Activit

tel-00748984, version 1 - 6 Nov 2012

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.

tel-00748984, version 1 - 6 Nov 2012

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 mtamodle 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.

tel-00748984, version 1 - 6 Nov 2012

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 service
Package de niveau de service (SPL) BD Catalogue des Services (portefeuille) AMIS CMIS ISMS

Amlioration continue de service

Conception de service

Package de conception des services(SDP) Contrat de niveau de service (SLA) Contrat de mise en uvre (OLA) Bibliothque des mdias

BD Contrats fournisseur

Transition de service

BD Gestion des configurations

Mise en uvre de service

Demandes de service

Enregistrement des vnement Erreurs connues

Enregistrement des incidents

Enregistrement des problmes

tel-00748984, version 1 - 6 Nov 2012

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

tel-00748984, version 1 - 6 Nov 2012

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 Application Matriel Information

associ 0..* 1 0..* 0..* manipule 0..* 0..* Acteur

Ressource

0..* propritaire

utilise

KPI 1..*

mesure 1..*

Processus

documente 1

0..* Service

1 0..*

contient

Bonne pratique 1 mis en oeuvre par Volume 1 dcrit 1..* 1 Objectif

Service TI 1..* 1..* Besoin mtier

Service Mtier 1..* 1..* Besoin Client

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.

tel-00748984, version 1 - 6 Nov 2012

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 mtamodle 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

tel-00748984, version 1 - 6 Nov 2012

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.

tel-00748984, version 1 - 6 Nov 2012

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 Activit de contrle est surveille l'aide de Action de traitement -benefice: int -cot: int donne lieu Risque rsiduel Risque Risque inhrent effet ngatif sur Opportunit ralise effet positif sur Catgorie d'vnement peut dterminer Origine du facteur Occurence d'vnement * rsulte en Cause Evnement induit Probabilit Impact

a un effet sur

affecte

peut donner lieu

interdpendance

Facteur

appartient

Stratgie

1..* a un effet sur Tolrance au risque

Objectif

appartient

Catgorie d'objectif

Conformit aux lois Priorit ralise Facteur de succs prend en compte Fiabilit du reporting Objectif oprationnel Objectif stratgique Facteur interne Facteur externe

tel-00748984, version 1 - 6 Nov 2012

a un effet sur Apptence au risque

dispose d'une dispose d'une

Entit Partie prenante affecte value

Indicateur de performance

Figure 6.6. Diagramme de classe des concepts de COSO (Sienou, 2007). (Sienou, 2007) propose une formalisation des concepts du COSO. Nous reprenons le mtamodle 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.

tel-00748984, version 1 - 6 Nov 2012

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]

tel-00748984, version 1 - 6 Nov 2012

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

tel-00748984, version 1 - 6 Nov 2012

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 NTCM(REFGOUV) NTCM(COBIT) Mesures 21 NRCM(COBIT, REFGOUV) 21 NRCM(REFGOUV, COBIT) 17 17 DR(COBIT, REFGOUV) DR(REFGOUV, COBIT) CoC(COBIT, REFGOUV) ChC(REFGOUV, COBIT) 17 8 81% 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

Ressource

Indicateur

Processus

REFGOUV

Catgorie

Mtrique

Situation

Dcision

Critre

Risque

Action

Projet

Mot

But

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.

tel-00748984, version 1 - 6 Nov 2012

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

tel-00748984, version 1 - 6 Nov 2012

ITIL Objectif Volume Bonne pratique Processus KPI Service Service TI Service mtier Besoin mtier Besoin Client Ressource Acteur Document Application Matriel Information NTCM(REFGOUV) NTCM(ITIL) 21 16 Mesures NRCM(ITIL, REFGOUV) NRCM(REFGOUV, ITIL) 17 17 DR(ITIL, REFGOUV) DR(REFGOUV, ITIL) CoC(ITIL, REFGOUV) ChC(REFGOUV, ITIL) 16 7 100% 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. Nous montrons ainsi la puissance conceptuelle de REFGOUV, dune part dans sa capacit 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

Ressource

Indicateur

Processus

REFGOUV

Catgorie

Mtrique

Situation

Dcision

Critre

Risque

Action

Projet

Mot

But

Situation gnre

Situation prvue

Tableau de bord

Caractristique

Question CQG

Domaine GSI

Portefeuille

tel-00748984, version 1 - 6 Nov 2012

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 NTCM(REFGOUV) NTCM(COSO) Mesures 20 NRCM(COSO, REFGOUV) 30 NRCM(REFGOUV, COSO) 21 21 DR(COSO, REFGOUV) DR(REFGOUV, COSO) CoC(COSO, REFGOUV) ChC(REFGOUV, COSO) 21 7 70% 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

Ressource

Indicateur

Processus

REFGOUV

Catgorie

Mtrique

Situation

Dcision

Critre

Risque

Action

Projet

Mot

But

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. Nous montrons ainsi la puissance conceptuelle de REFGOUV, dune part dans sa capacit 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

tel-00748984, version 1 - 6 Nov 2012

Tableau de bord

Caractristique

Question CQG

Domaine GSI

Ajustement

Portefeuille

Rfrentiels compars COSO COBIT ITIL NTCM(REFGOUV) NTCM(*) 21 67 Mesures NRCM(*, REFGOUV) NRCM(REFGOUV, *) 55 55 DR(*, REFGOUV) DR(REFGOUV, *) CoC(*, REFGOUV) ChC(REFGOUV, *) 54 11 81% 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 mtamodle 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

Ressource

Indicateur

Processus

REFGOUV

Catgorie

Mtrique

Situation

Dcision

Critre

Risque

Action

Projet

Mot

But

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
Dbut (a)
Par identification des buts de GSI

tel-00748984, version 1 - 6 Nov 2012

Par planification des projets

Gouverner le SI (b)
1 2
Par prise de dcision

Fin (c)

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.

tel-00748984, version 1 - 6 Nov 2012

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)
Identifier un but de GSI (b)
1

Par analyse des priorits de gouvernance

Par analyse linguistique

Par compltude

Dbut (a)

Identifier la catgorie de but (c)

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 priorits de gouvernance
1

Identifier un but de GSI (b) Identifier la catgorie de but (c)

Par dfinition de domaine Par dfinition de critre
1

Connaissance

Dbut (a)

DSI- C.Cab1.a : <(Connaissance.tat= jour), Progresser depuis Dbut> (arg1) Slectionner(DSS- C.Cab1.ab) (arg2) (arg3) Slectionner(DSS- C.Cab1.ac)

tel-00748984, version 1 - 6 Nov 2012

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 de gouvernance

But

Identifier un but de GSI (b)

Dbut (a)

+ID: Integer +description: String +date: Date

DAI-C.Cab1 .ab1 : <(Connaissance.tat= jour), Identifier un but de GSI par analyse des priorits de gouvernance>

1:<(Connaissance.tat= jour), Identifier les objectifs stratgiques>

2:<(Objectifs stratgique.tat=identifi), Identifier les buts de GSI associs aux objectifs stratgiques>

tel-00748984, version 1 - 6 Nov 2012

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 le march

Attirer la clientle

Offrir une livraison rapide

Optimiser la fabrication

Assurer la prennit de lentreprise

Dvelopper de nouveaux produits

Prospecter de nouveaux clients

Prparer les produits proximit des clients

Sapprovisionner en matires premires au meilleur cot

Maintenir les sites industriels en conditions oprationnelles

Adapter loffre produit Offrir un choix couvrant les besoins courants comme les demandes pointues

Donner des dates de livraison fiables

Respecter les dates de livraison fixes

Fournir les produits finis de qualit Optimiser lexploitation des UP selon le plan de charge

Entretenir la motivation des ressources humaines Maitriser lquilibre financier

Etre ractif aux demandes des clients

Optimiser la gestion des stocks

tel-00748984, version 1 - 6 Nov 2012

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. 6.5.2.3.2.1. Composant de choix
Par affinement
1 Identifier un but de GSI (b) 1

Par compltude
1
Fin (d)

But 1..* 1

Catgorie

Par analyse linguistique

Identifier la catgorie de but (c)

DSI-C.Cab1.a : <(((But.tat= jour) + (But.tat= identifi)) (Catgorie.tat=identifie)), Progresser depuis Identifier un but de GSI> (arg1) Slectionner(DSS-C.Cab1.bb ) (arg2) (arg1) Slectionner(DSS-C.Cab1.bd) (arg2) Slectionner(DSS-C.Cab1.bc)

arg1 : Les buts couvrent lensemble des besoins de GSI 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. 6.5.2.3.2.2. Composant dexcution 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 .

tel-00748984, version 1 - 6 Nov 2012

6.5.2.3.2.3. Composant descriptif 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 Prospecter de nouveaux clients Ngocier les conditions tarifaires Etre ractif aux demandes des clients But SI ADV : Assurer un support informationnel pour les prospects ADV : Mettre jour les bases tarifaires en fonction de la politique de tarification ADV : Assurer lintgrit des informations sur les commandes ADV : Diminuer les dlais de transmission des informations sur les commandes ADV : Dmatrialisation des documents clients ADV : Assurer lintgrit des informations sur les livraisons ADV : Diminuer les dlais de transmission des informations sur les livraisons ADV : Dmatrialiser les documents transporteur Dvelopper les outils dassistance au design (CAO) Dvelopper la base des connaissances sur les produits ADV : Assurer les modifications au catalogue Dvelopper le catalogue en ligne des produits courants ADV : Dvelopper lintranet de gestion des clients pour les demandes spcifiques ADV : Dvelopper un bus inter-UV pour Domaine GSI Alignement Alignement Scurit Alignement Critre Performance Performance Performance Performance

Alignement Scurit Alignement

Performance Performance Performance

Donner des dates de livraison fiables

Alignement Alignement Valeur Alignement Alignement

Performance Performance Performance Performance Performance

Dvelopper de nouveaux produits Adapter loffre produit Offrir un choix couvrant les besoins courants et les demandes pointues

Alignement Alignement

Performance Performance

Prparer les produits

167

But mtier proximit des clients

Respecter les dates de livraison Optimiser la gestion des stocks Sapprovisionner en matire premire au meilleur cot Fournir des produits finis de qualit Optimiser lexploitation des UP selon le plan de charge Maintenir les sites industriels en conditions oprationnelles Entretenir la motivation des ressources humaines Matriser les quilibres financiers

But SI le partage des connaissances sur les disponibilits des stocks ADV : Intgrer la go-localisation des commandes dans les composants applicatifs Assurer la disponibilit des composants SI pour la livraison Dvelopper linterface GPAO/ADV Crer un SI centralis de gestion des stocks Dvelopper le SI Achat Dvelopper le systme de contrle temps rel Dvelopper le bus inter-UP Assurer la disponibilit du SI Assurer la communication interne Justifier le budget des SI par mise en place dune politique SLA Prioriser les investissements sur les projets forte VA

Domaine GSI

Critre

Alignement

Performance

Alignement Alignement

Performance Performance

Alignement Alignement Alignement Alignement Valeur Valeur Valeur

Performance Performance Performance Performance Performance Performance Ressource

tel-00748984, version 1 - 6 Nov 2012

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. 6.5.2.3.3.1. Composant de choix
Fin (d) Identifier un but de GSI (b)
1

Par compltude

Catgorie

Par application CQG

Identifier la catgorie de but (c)

DSI-C.Cab1.c : <(Catgorie.tat=identifie), Progresser depuis identifier la catgorie de but> (arg1) Slectionner(DSS-C.Cab1.cb) (arg1)

Slectionner(DSS-C.Cab1.cd)

arg1 : Les buts couvrent lensemble des besoins de GSI

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. 6.5.2.3.3.2. Composant dexcution DAI-C.Cab1.cd1 : Finir depuis Identifier la catgorie de but par Compltude Le processus dlaboration des buts se termine lorsque lensemble des besoins stratgiques sont couverts par les buts identifis. 6.5.2.3.3.3. Composant descriptif Nous terminons ici le scnario didentification des buts de GSI pour le cas PAPCAR. L tape suivante consiste planifier le portefeuille des projets SI afin de satisfaire les objectifs identifis.

tel-00748984, version 1 - 6 Nov 2012

6.5.3. Etape 2 Initialisation du processus de planification des projets de PAPCAR

Dbut (a)
Par identification des buts de GSI

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

6.5.3.1. Composant de choix

Par planification des projets

1
*

Gouverner le SI (b)
1

But

Projet * 0..1 <impacte 1 Action 1

0..1 < impacte

Fin (c)

Par historisation

Par prise de dcision

DSI-C.b: <(But.tat= jour projet.tat= jour action.tat=termine), Progresser depuis Gouverner le SI> (arg1) Slectionner(DSS-C.bb) arg1 : Les actions de gouvernance ont t appliques (arg1) Slectionner(DSS-C.bc)

tel-00748984, version 1 - 6 Nov 2012

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 l argument arg1 nous guide vers la slection de la directive DSS-C.bb.

Par planification des projets

1
Projet * * But

Gouverner le SI (b)

Par prise de dcision

DSS-C.bb : <(but.tat= jour ou projet.tat= jour), Progresser vers Gouverner le SI depuis Gouverner le SI> (arg2) (arg )
1

Slectionner(DAI-C.bb1) arg1 : Les buts sont exploitables arg2 : Les projets sont exploitables

Slectionner(DAI-C.bb2)

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

6.5.3.2. Composant dexcution 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 un projet (b) Dbut (a)

Par but

Fin (e)
Par suivi

1
Par cration de tableau de bord Par GQM

tel-00748984, version 1 - 6 Nov 2012

Excuter un projet(d)

Par continuit

Identifier une mesure(c)

Figure 6.21. Scnario du cas PAPCAR pour la carte C.Cbb1. 6.5.3.3. Composant descriptif Le composant dexcution est stratgique. Il sagit dexcuter la carte daffinement de la 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. 6.5.3.3.1.1. Composant de choix
Par mise jour

2
Par but

Identifier un projet (b) 1 Identifier une mesure(c)

Par reprise de planification
But * * Projet

Dbut (a) 1

Par GQM

2
Par reprise de mtriques

Excuter un projet(d)

DSI- C.Cbb1.a : <(Projet.tat= historis But.tat= identifi), Progresser depuis Dbut> (arg1) Slectionner(DSS- C.Cbb1.ab) (arg2) Slectionner(DSS- C.Cbb1.ac) ((arg1) (arg2)) Slectionner(DSS- C.Cbb1.ad)

tel-00748984, version 1 - 6 Nov 2012

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 pralable des buts et des projets. Ltape 1 du cas PAPCAR a permis didentifier les buts. Mais les projets nont pas encore t dfinis. Ainsi largument arg1 nous guide vers la slection de la directive DSI-C.Cbb1.ab.

Par mise jour

2
Par but

Identifier un projet (b) 1

But

* *

Projet

Dbut (a)

DSS- C.Cbb1.ab : <(Projet.tat= historis But.tat= identifi), Progresser vers identifier un projet depuis Dbut> (arg1) Slectionner(DAI-C.Cbb1.ab2) (arg2) Slectionner(DAI-C.Cbb1.ab1)

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 pralable des buts et des projets. Ltape 1 du cas PAPCAR a permis didentifier les buts. Mais les projets nont pas encore t dfinis. Ainsi largument arg2 nous guide vers la slection de la directive DAI-C.Cbb1.ab1. 6.5.3.3.1.2. Composant dexcution DAI-C.Cbb1.ab1 : Identifier un projet depuis Dbut par But
affin par > 0..*

But +ID: Integer +description: String +date: Date

* *

Projet +nom: String +date: Date +description: String

a 1 caractristique 1..* +nom: String

Figure 6.24. PAPCAR : Composant de REFGOUV produit par DAI-C.Cbb1.ab1.

tel-00748984, version 1 - 6 Nov 2012

La directive DAI-C.Cbb1.ab1 impose didentifier les projets par regroupement des buts (Figure 6.24). 6.5.3.3.1.3. Composant descriptif 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 ter me, 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. 6.5.3.3.2.1. Composant de choix
Par dcoupage Par portefeuille Par construction de composants
* *

Projet
1..* 1..* * *

But
1..* a pour objectif 1..*

2 Identifier un projet (b)

1 2

Par suivi
Sans suivi

Tableau de bord

Par GQM

Excuter un projet(d)

Indicateur
1..* value

Mtrique

Identifier une mesure(c)

drive

DSI- C.Cbb1.b : <(Projet.tat= identifi But.tat= identifi), Progresser depuis Identifier un projet> (arg1) Slectionner(DSS- C.Cbb1.bb) (arg2) Slectionner(DSS-C.Cbb1.ac) ((arg1) (arg2)) Slectionner(DSS-C.Cbb1.bd)

tel-00748984, version 1 - 6 Nov 2012

arg1 : Projet incomplet dans sa dfinition arg2 : Besoin de plannifier les mesures associes au projet

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 dcoupage Par portefeuille

Par construction de composants

Projet
1..* 1..* * *

But
1..* a pour objectif 1..*

2 Identifier un projet (b)

1 2

Par suivi
Sans suivi

Tableau de bord

Par GQM

Excuter un projet(d)

Indicateur
1..* value

Mtrique

Identifier une mesure(c)

drive

DSI- C.Cbb1.b : <(Projet.tat= identifi But.tat= identifi), Progresser depuis Identifier un projet> (arg1) Slectionner(DSS- C.Cbb1.bb) (arg2) Slectionner(DSS-C.Cbb1.ac) ((arg1) (arg2)) Slectionner(DSS-C.Cbb1.bd)

arg1 : Projet incomplet dans sa dfinition arg2 : Besoin de plannifier les mesures associes au projet

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 da mlioration du SI existant. Ainsi largument arg1 nous guide vers la slection de la directive DAI-C.Cbb1.bb2. 6.5.3.3.2.2. Composant dexcution DAI-C.Cbb1.bb2 : Identifier un projet depuis Identifier un projet par Portefeuille
dcoup par > 0..1 1..*

Tableau de bord +ID: Integer +nom: String +date: Date

1..* 1..*

Projet +nom: String +date: Date +description: String Portefeuille

0..*

+ID: Integer

Figure 6.27. PAPCAR : Composant de REFGOUV produit par DAI-C.Cbb1.bb2.

tel-00748984, version 1 - 6 Nov 2012

La directive DAI-C.Cbb1.bb2 prconise lorganisation dun agrgat de projets au sein dun portefeuille (Figure 6.27). 6.5.3.3.2.3. Composant descriptif Lensemble des projets SI du cas PAPCAR ont t identifis. Nous les organisons au se in 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.

tel-00748984, version 1 - 6 Nov 2012

176

Num But SI Portefeuille ADV : Assurer les modifications au 1 catalogue Assurer la communication interne 2 Assurer la disponibilit du SI 3 Dvelopper la base des connaissances sur les produits amlioration des services 4 du SI aux mtiers Dvelopper les outils dassistance au 5 design (CAO) Justifier le budget des SI par mise en 6 place dune politique SLA Dvelopper le SI Achat 7 Assurer la disponibilit des composants 8 SI pour la livraison Crer un SI centralis de gestion des stocks 9 amlioration des systmes Dvelopper le systme de contrle de reporting temps rel

tel-00748984, version 1 - 6 Nov 2012

10 ADV : Assurer lintgrit des informations sur les commandes 11 ADV : Assurer lintgrit des informations sur les livraisons 12 ADV : Assurer un support informationnel 13 pour les prospects ADV : Dvelopper lintranet de gestion des clients pour les demandes 14 spcifiques amlioration des systmes ADV : Intgrer la go-localisation des oprants ADV/GPAO commandes dans les composants 15 applicatifs ADV : Diminuer les dlais de transmission des informations sur les commandes 16 ADV : Diminuer les dlais de transmission des informations sur les livraisons 17 ADV : Mettre jour les bases tarifaires en fonction de la politique de tarification 18 ADV : Dmatrialisation des documents 19 clients dveloppement des ADV : Dmatrialiser les documents interfaces BtoC et BtoB 20 transporteur Dvelopper le catalogue en ligne des 21 produits courants ADV : Dvelopper un bus inter-UV pour le interoprabilit des partage des connaissances sur les systmes oprants 22 disponibilits des stocks ADV/GPAO 23 Dvelopper linterface GPAO/ADV 24 Dvelopper le bus inter-UP Prioriser les investissements sur les 25 projets forte VA

Projet au court terme Dvelopper l'interface ADV pour les catalogues Mise en place des services de chat et visio-confrence Projet de cration des serveurs de secour Mise en place d'une plateforme Wiki sur les produits Appel d'offre aux diteurs d'outils CAO Ressencer les demandes des mtiers Dvelopper les outils et BDD des services achat Projet de cration des serveurs de secour Dvelopper les outils et BDD du service national de gestion des stocks Amnager les interfaces GPAO/ADV pour communiquer avec les SI des stocks Authentifier les accs au systme de gestion des entrepts Authentifier les accs au systme de destion des entrepts Dvelopper la BDD des prospects Dvelopper la BDD des demandes client Amliorer la BDD des commandes Amliorer les flux assynchrones Amliorer les flux assynchrones Dvelopper le catalogue national Projet de dmaterialisation des factures, bon de livraison et AR Dvelopper le site Internet des commandes

Projet au long terme

Mise en place d'une place de march

Mise en place des modules ERP Mise en place du systme de pilotage

Mise en place des modules CRM

Mise en place des modules ERP

Mise en place des modules SCM

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 Lintention Identifier un projet de la carte C.Cbb1 de PROGOUV est active. 6.5.3.3.3.1. Composant de choix 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. 6.5.3.3.3.2. Composant dexcution DAI-C.Cbb1.bc1 : Identifier une mesure depuis Identifier un projet par GQM
affin par > 0..*

tel-00748984, version 1 - 6 Nov 2012

But +ID: Integer +description: String +date: Date

Mtrique
a pour objectif 1..* 1..*

+ID: Integer +description: String +dim: Object +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). 6.5.3.3.3.3. Composant descriptif 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.

tel-00748984, version 1 - 6 Nov 2012

6.5.3.3.4.1. Composant de choix

2
Par cration de tableau de bord Par indicateur

Identifier une mesure(c) 1

Par mtrique de composant projet

Mtrique

1..*

1..*

But

a pour objectif

Identifier un projet (b)

DSI- C.Cbb1.c : <(Mtrique.tat= identifi But.tat= identifi), Progresser depuis Identifier une mesure> (arg1) Slectionner(DSS-C.Cbb1.cc) (arg2) 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

6.5.3.3.4.2. Composant dexcution DAI-C.Cbb1.cb1 : Identifier un projet depuis Identifier une mesure par Cration de tableau de bord

Dcision +ID: Integer +description: String +date: Date < repose sur

Indicateur Tableau de bord

1..*

Projet +nom: String +date: Date +description: String

1..*

+ID: Integer +nom: String +date: Date

+intitul: String +forme: Object 1..* +valeur: Integer +valeurMIN: Integer +valeurMAX: Integer +date: Date

+axeRessource

+axeProcessus

+axeRisque

+axeBut

Ressource +ID: Integer +Nom: String

Processus +ID: Integer +Nom: String

Risque +ID: Integer +Nom: String

But +ID: Integer +description: String +date: Date

tel-00748984, version 1 - 6 Nov 2012

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). 6.5.3.3.4.3. Composant descriptif 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 ()
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

Participant (h)

Charge (j.h)

Production (u.t)

Dure (m)

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 Lintention Identifier un projet de la carte C.Cbb1 de PROGOUV est active.

180

6.5.3.3.5.1. Composant de choix 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.

Identifier un projet (b)

1 2

Par suivi
caractristique

Sans suivi
1 Projet

1..*

< value * 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.bd2)

tel-00748984, version 1 - 6 Nov 2012

Slectionner(DAI-C.Cbb1.bd1)

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 DAIC.Cbb1.bd1. 6.5.3.3.5.2. Composant dexcution
Mtrique caractristique +nom: String
1..* a 1 < value * *

Indicateur +intitul: String +forme: Object +valeur: Integer +valeurMIN: Integer +valeurMAX: Integer +date: Date
1..*

+ID: Integer +description: String +dim: Object +valeur: String

Projet +nom: String +date: Date +description: String

Tableau de bord +ID: Integer +nom: 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. 6.5.3.3.5.3. Composant descriptif 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) :

tel-00748984, version 1 - 6 Nov 2012

Portefeuille 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

Budget ()

Production (u.t)

Dure (m)

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. 6.5.3.3.6.1. Composant de choix 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)

Par finalisation

Projet

Excuter un projet(d) Identifier une mesure(c)

1
Par adaptation

Par continuit

DSI- C.Cbb1.d : <(Projet.tat= en-cours), Progresser depuis Excuter un projet> (arg1) Slectionner(DSS-C.Cbb1.dc) (arg2) (arg3) 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

tel-00748984, version 1 - 6 Nov 2012

Figure 6.33. PAPCAR : Description de la directive DSI-C.Cbb1.d. 6.5.3.3.6.2. Composant dexcution 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. 6.5.3.3.6.3. Composant descriptif 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 Projet de cration des serveurs de secour 75000 500 0,5 Total du portefeuille 800000 2000 6 Dvelopper les outils et BDD 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 Total du portefeuille 400000 3000 6 Authentifier les accs au systme de gestion des entrepts 50000 200 1 Authentifier les accs au systme de destion des entrepts 50000 200 1 Dvelopper la BDD des prospects 100000 750 1,5 Dvelopper la BDD des amlioration des systmes 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 Dvelopper le catalogue national 100000 850 2 Total du portefeuille 900000 6000 14 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 Total du portefeuille 600000 3000 6 interoprabilit des systmes oprants ADV/GPAO

tel-00748984, version 1 - 6 Nov 2012

0 Total du portefeuille 0

0 0

0 0

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
Dbut (a)
Par identification des buts de GSI

Par planification des projets

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. 6.5.4.1. Composant de choix

tel-00748984, version 1 - 6 Nov 2012

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. 6.5.4.2. Composant dexcution 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.
1
Par suivi des projets

Dbut (a)

Identifier un but dajustement de la gouvernance SI (b)

Par valuation des ressources

Prendre une Dcision (c)

Fin (d)
3
Par impact sur les projets

Figure 6.35. Scnario du cas PAPCAR pour la carte C.Cbb2. 185

6.5.4.3. Composant descriptif Le composant dexcution est stratgique. Il sagit dexcuter la carte daffinement de la 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. 6.5.4.3.1.1. Composant de choix 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 (a)

Par suivi des projets

Situation +ID: Integer +description: String

tel-00748984, version 1 - 6 Nov 2012

Par adaptation vnementielle

Identifier un but dajustement de la gouvernance SI (b)

Situation gnre

Situation prvue

DSS- C.Cbb2.ab : <(Situation.tat= cre), Progresser vers Identifier un but dajustement de la GSI depuis dbut> (arg1) Slectionner(DAI-C.Cbb2.ab1) (arg2) Slectionner(DAI-C.Cbb2.ab2)

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. 6.5.4.3.1.2. Composant dexcution DAI-C.Cbb2.ab1 : Identifier un but dajustement de la gouvernance SI depuis Dbut par Suivi des projets

186

Par suivi des projets

Projet
* * a pour objectif 1..*

1..*

Mtrique 0..* < valuer

Dbut (a)

Identifier un but dajustement de la gouvernance SI (b)

But

0..*

Situation 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), identifier situation gnre>

2:<(situation gnre.tat=identifie), mesurer les carts de situation>

3:<(situation gnre.tat=mesure), formuler le but dajustement>

2.1:<(situation gnre=identifie), mesurer la situation gnre>

2.2:<(situation prvue=mesure), mesurer lcart>

Figure 6.37. PAPCAR : Description de la directive DAI-C.Cbb2.ab1

tel-00748984, version 1 - 6 Nov 2012

La directive DAI-C.Cbb2.ab1 prconise les activits excuter dans lobjectif de formuler un but dajustement (Figure 6.37). 6.5.4.3.1.3. Composant descriptif 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. 6.5.4.3.2.1. Composant de choix 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

Identifier un but dajustement de la gouvernance SI (b)

1
Par valuation daccomplissement du but

Par valuation des risques

But +ID: Integer +description: String +date: Date

Par valuation des ressources

Par valuation des processus

Prendre une Dcision (c)

Ajustement

DSS- C.Cbb2.bc : <(Ajustement.tat=cr), Progresser vers Prendre une dcision depuis Identifier un but dajustement de la GSI> (arg2) Slectionner(DAIC.Cbb2.bc2) arg1 : Lajustement porte sur un but arg2 : Lajustement porte sur un processus arg3 : Lajustement porte sur une ressource arg4 : Lajustement porte sur un risque Slectionner(DAIC.Cbb2.bc1) (arg1) (arg3) Slectionner(DAIC.Cbb2.bc3) (arg4) Slectionner(DAIC.Cbb2.bc4)

Figure 6.38. PAPCAR : Description de la directive DSS-C.Cbb2.bc.

tel-00748984, version 1 - 6 Nov 2012

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. 6.5.4.3.2.2. Composant dexcution DAI-C.Cbb2.bc2 : Prendre une dcision depuis Identifier un but dajustement de la gouvernance SI par Evaluation des processus
drive

< value 0..* 0..*

Mtrique +ID: Integer +description: String +dim: Object +valeur: String

Indicateur +intitul: String +forme: Object +valeur: Integer +valeurMIN: Integer +valeurMAX: Integer +date: Date
0..*

Processus +ID: Integer +Nom: String

Critre +nom: String Action +ID: Integer +description: String

1..*

Dcision

+ID: Integer opportunits +description: String +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

6.5.4.3.2.3. Composant descriptif 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 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 Budget () 600000 900000 400000 0 800000 Production (u.t) 3000 6000 3000 0 2000 Dure (m) 6 14 6 0 6

tel-00748984, version 1 - 6 Nov 2012

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. 6.5.4.3.3.1. Composant de choix 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)

Par impact sur les 1 buts 2 Sans impact

1
Dcision

Fin (d)

Par analyse de TdB

Par impact sur les projets

+ID: Integer +description: String +date: Date

DSI- C.Cbb2.c : <(Dcision.tat=prise), Progresser depuis Prendre une dcision> (arg1) (arg1) Slectionner(DSS-C.Cbb2.cc)

Slectionner(DSS-C.Cb21.cd)

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

tel-00748984, version 1 - 6 Nov 2012

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.

Par impact sur les buts

1
Fin (d)
Sans impact

Prendre une Dcision (c)

2
Dcision +ID: Integer +description: String +date: Date 1..* oppotunits Action +ID: Integer +description: String

3
Par impact sur les projets

DSS- C.Cbb2.bc : <(Dcision.tat=cr Action.tat=identifie), Progresser vers Fin depuis Prendre une dcision > (arg1) ((arg2) (arg1)) Slectionner(DAI-C.Cbb2.cd2)

(arg2)
Slectionner(DAI-C.Cbb2.cd3)

Slectionner(DAI-C.Cbb2.cd1)

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. 6.5.4.3.3.2. Composant dexcution DAI-C.Cbb2.cd3 : Finir depuis Prendre une dcision par Impact sur les projets

190

Dcision +ID: Integer +description: String +date: Date Ressource +ID: Integer +Nom: String +crer() +modifier() 1..* +supprimer() Risque +ID: Integer +Nom: String +crer() +moduler() +supprimer() Processus +ID: Integer +Nom: String +crer() +adapter() +supprimer()
opportunits 1..*

Projet +nom: String +date: Date +description: String +crer() +changerBut() +ajouterRessource() +retirerRessource() +ajouterRisque() +retirerRisque() +suspendre() +supprimer()
0..1 1

Action +ID: Integer +description: String

<impacte

* *

But +ID: Integer +description: String +date: Date +crer() +ModifierCatgorie() +Suspendre() +Supprimer()

1..*

tel-00748984, version 1 - 6 Nov 2012

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. 6.5.4.3.3.3. Composant descriptif 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 Projet de cration des 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 Dvelopper les outils et BDD des services achat 100000 100 1 suspendre Projet de cration des serveurs de secour 75000 500 0,5 suspendre Total du portefeuille 800000 2000 6 suspendre Dvelopper les outils et BDD 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 Authentifier les accs au systme de gestion des entrepts 50000 200 1 suspendre Authentifier les accs au systme de destion des entrepts 50000 200 1 suspendre Dvelopper la BDD des prospects 100000 750 1,5 suspendre Dvelopper la BDD des amlioration des systmes 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 Dvelopper le catalogue national 100000 850 2 suspendre Total du portefeuille 900000 6000 14 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 Total du portefeuille 600000 3000 6 suspendre

tel-00748984, version 1 - 6 Nov 2012

Tableau 6.7. Actions appliques aux projets SI

192

6.5.5. Finalisation du processus de GSI de PAPCAR

Dbut (a)
Par identification des buts de GSI

Par planification des projets

Gouverner le SI (b)
2
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.

tel-00748984, version 1 - 6 Nov 2012

6.5.5.1. Composant de choix 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
*

Gouverner le SI (b)
1

But

Projet * 0..1 <impacte 1 Action 1

0..1 < impacte

Fin (c)

Par historisation

Par prise de dcision

DSI-C.b: <(But.tat= jour projet.tat= jour action.tat=termine), Progresser depuis Gouverner le SI> (arg1) Slectionner(DSS-C.bb) arg1 : Les actions de gouvernance ont t appliques (arg1) Slectionner(DSS-C.bc)

Figure 6.44. PAPCAR : Directive DSI-C.b permettant de progresser depuis gouverner le SI

193

6.5.5.2. Composant dexcution

Tableau de bord < repose sur

Dcision
1..*

Gouverner le SI (b)

1..*

Action

Fin (c)

oppotunits

1..*

1 1 < impacte 0..1

Par historisation

But
1..* 0..* * value 1..* * <impacte 0..1

Indicateur

Projet

DAI-C.bc1 : <(action.tat= jour ou ProcessusGSI.dateFin<=Date.TODAY), Finir par historisation>

1:<(action.tat= jour), analyser les situations de dcision>

2:<(Dcision.tat=analyse), dater les tats de la situation>

3:<(action.tat= jour et ProcessusGSI.dateFin<=Date.TODAY), dater les tats des projets>

2.1:<(Dcision.tat=analyse) , dater les tats des indicateurs>

2.2:<(Dcision.tat=analyse) , dater les tats des actions>

2.3:<(Dcision.tat=analyse) , dater les tats des buts>

tel-00748984, version 1 - 6 Nov 2012

Figure 6.45. Directive DAI-C.bc1 permettant de finir par historisation 6.5.5.3. Composant descriptif 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 +date: Date Situation prvue Situation Situation gnre opportunits 1..* Action +ID: Integer +description: String 1 Portefeuille +ID: Integer a 0..* 1..* 1..* Catgorie 1 1..* But * +ID: Integer +description: String 0..* +date: Date affin par > <impacte 0..* Projet 1..* 1 1..* Risque +ID: Integer 1..* +Nom: String Ressource +ID: Integer +Nom: String 0..1 +nom: String +date: Date +description: String * 1..* 0..1 0..* * caractristique +nom: String 1..* 0..* Processus +ID: Integer +Nom: String 1..* < value Indicateur +intitul: String +forme: Object +valeur: Integer +valeurMIN: Integer +valeurMAX: Integer +date: Date 0..* < gnre < value +ID: Integer +description: String 0..* < valuer 1..* Mtrique +ID: Integer 0..* +description: String +dim: Object +valeur: String * drive

dcoup par > +axeRessource +axeRisque

+axeProcessus Tableau de bord +ID: Integer +nom: String +date: Date

Domaine GSI

tel-00748984, version 1 - 6 Nov 2012

+nom: String

0..* 0..* Mot 1..*

1..*

+axeBut

Critre +nom: String 0..*

0..* +intitul: String +dfinition: 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 Monde Facette Sujet ORGANISATION
DE LA GOUVERNANCE DECISION PROCESSUS IT PROCESSUS METIER CHANGEMENT PORTEFEUILLE DE PROJETS SI MINIMISER LES RISQUES ATTEINDRE LETAT DALIGNEMENT OBTENIR LA PERFORMANCE CREER DE LA VALEUR CONTENU

tel-00748984, version 1 - 6 Nov 2012

Approches de la gouvernance des systmes dinformation CobiT COSO ITIL MISIG * * * * * * * * Infrastructure * * volutif * qualit Evolution SI * * volutif * * *

Usage

document Processus, objet Risque, performance, valeur systmatique * externalisation *

Patrimoine mtier document Processus, objet risque systmatique externalisation *

Patrimoine SI, usage document Processus, objet Alignement, performance systmatique externalisation *

* * document * * systmatique * externalisation -

Systme

MODELE METRIQUES Dveloppement NATURE

DES PROCESSUS MATURITE DES PROCESSUS CAPITALISATION DE LA 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 : H1 : la GSI est un artfact que lon peut conceptualiser. o o H11 : Le domaine de la GSI manipule un ensemble dlments conceptualisables.

tel-00748984, version 1 - 6 Nov 2012

H12 : Le processus de la GSI est conceptualisable.

H2 : un systme dinformation de gouvernance correctement conceptualis est utile la bonne mise en uvre de lactivit de gouvernance

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, audel 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

tel-00748984, version 1 - 6 Nov 2012

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.

tel-00748984, version 1 - 6 Nov 2012

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.

tel-00748984, version 1 - 6 Nov 2012

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

tel-00748984, version 1 - 6 Nov 2012

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

tel-00748984, version 1 - 6 Nov 2012

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.

tel-00748984, version 1 - 6 Nov 2012

(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-21209103-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.

tel-00748984, version 1 - 6 Nov 2012

(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.

tel-00748984, version 1 - 6 Nov 2012

(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.

tel-00748984, version 1 - 6 Nov 2012

(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 210-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 NonFunctional 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.

tel-00748984, version 1 - 6 Nov 2012

(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 Reengineering: 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.

tel-00748984, version 1 - 6 Nov 2012

(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.

tel-00748984, version 1 - 6 Nov 2012

(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

tel-00748984, version 1 - 6 Nov 2012

tel-00748984, version 1 - 6 Nov 2012

Annexe A - Enonc du cas PAPCAR

211