Pour Une Meilleure Gouvernance Des Systèmes D'information - (WWW - Worldmediafiles.CoM) PDF

14:59
Page 1
CobiT
R
Associ du cabinet ASK Conseil, Fabrice Garnier

de Labareyre exerce le mtier de consultant dans
le domaine des technologies de linformation
depuis plus de quinze ans. Frquemment conseil
de la Direction gnrale et de la DSI de grandes
entreprises, il intervient sur les missions stratgiques relevant de la gouvernance des systmes
dinformation : pilotage des organisations, matrise
des grands projets, performance et qualit des services, scurit de linformation Il est galement
administrateur de lAFAI.
qui sadresse ce livre ?

Aux auditeurs
Aux managers de linformatique
et aux DSI
Aux chefs dentreprise
et aux directions financires
Aux consultants et aux formateurs
Sappuyant sur la version 4.1 de CobiT, cet ouvrage en trois volets

replace ce rfrentiel dans le contexte global de la gouvernance des
systmes dinformation. La premire partie dresse un panorama des
diffrents rfrentiels existants, en dcrivant leurs champs daction
et leur positionnement vis--vis de CobiT. Dans la deuxime partie
sont dtaills les 34 processus de CobiT selon un plan standard, avec
mise en lumire de leurs forces et faiblesses. Enfin, la troisime partie expose des cas pratiques dutilisation et de dploiement de CobiT,
correspondant un vritable mode demploi du rfrentiel. Cet
ouvrage apportera ainsi des rponses pragmatiques tous ceux qui
souhaitent implmenter CobiT dans leur systme dinformation
ou le concilier avec dautres rfrentiels comme ITIL, CMMi ou
ISO 27001.
Au sommaire
CobiT et la gouvernance TI. Prsentation gnrale de CobiT.
Historique de CobiT. Les cinq axes stratgiques. Les autres
rfrentiels de la gouvernance des TI. Le pilotage stratgique.
Le management de la scurit. ITIL : le management des
services. Le management des tudes. Les modles "qualit".
Apprhender CobiT. Documents et publications autour de
CobiT. qui s'adresse CobiT ? Les limites : ce que CobiT n'est
pas. Description dtaille des processus. Planifier et Organiser. Acqurir et Implmenter. Dlivrer et Supporter. Surveiller
et valuer. Mettre en oeuvre CobiT. CobiT pour l'audit. Le
code professionnel d'thique. La mission d'audit. Le contrle
interne. L'outil Quick Scan. CobiT fdrateur. Le pilotage
stratgique. Conjuguer ITIL et CobiT. CobiT et la norme
ISO/IEC 27002. CobiT et la norme ISO/IEC 27001. CobiT et
CMMi. La certification. Transformer la DSI. CobiT Quickstart.
Pour un dploiement tag. Annexes. Glossaire. Objectifs
du systme d'information et processus CobiT.
CobiT
Les auteurs
Dominique Moisand a occup divers postes
responsabilit au sein de PricewaterhouseCoopers
avant de crer en 1990 le cabinet ASK, conseil en
management et organisation, qui s'attache notamment amliorer la gouvernance des systmes
d'information des grands comptes. Vice-prsident
de lAFAI (Association franaise de laudit et du
conseil informatiques) pendant cinq ans, il a collabor plusieurs traductions des ouvrages de
lISACA et diverses publications : Matrise douvrage et matrise duvre, Audit des projets, Le
client pivot de la gouvernance Il anime avec
Fabrice Garnier de Labareyre des sminaires sur la
convergence des rfrentiels de la DSI.
frence incontournable au sein de la communaut des auditeurs informatiques depuis plus de dix ans, CobiT (Control
OBjectives for Information and related Technology) est
devenu un standard de la gouvernance des systmes dinformation.
Publies par lISACA (Information Systems Audit and Control
Association) et lITGI (Information Technology Governance Institute),
les dernires versions 4.0 et 4.1 rpondent tout particulirement aux
problmatiques de management des systmes dinformation.
9 782212 124279
Code diteur : G12427
ISBN : 978-2-212-12427-9
Aux acteurs de linfogrance
39
FABRICE
10/12/08
DOMINIQUE MOISAND
GARNIER DE LABAREYRE
12427_Cobit_17x23
D O M I N I Q U E M O I S A N D
FABRICE GARNIER DE LABAREYRE
CobiT
Implmentation ISO 27001
Pour une meilleure gouvernance

des systmes d'information
CobiT
CHEZ LE MME DITEUR

C. Dumont. ITIL pour un service informatique optimal (2e dition).
N12102, 2007, 378 pages.
C. Dumont. Mmento ITIL.
N12157, 2007, 14 pages.
E. Besluau. Management de la continuit dactivit.
N12346, 2008, 254 pages.
A. Fernandez-Toro. Management de la scurit de linformation.
Implmentation ISO 27001 Mise en place dun SMSI et audit de certification.
N12218, 2007, 256 pages.
F. Valle. UML pour les dcideurs.
N11621, 2005, 282 pages.
P. Roques, F. Valle. UML 2 en action.
De lanalyse des besoins la conception J2EE.
N11462, 2004, 386 pages.
P. Mangold. Gestion de projet informatique.
N11752, 2006, 120 pages.
E. Oneill. Conduite de projets informatiques offshore.
N11560, 2005, 336 pages.
S. Bordage. Conduite de projet Web (4e dition).
N12325, 2008, 394 pages.
M. Rizcallah. Annuaires LDAP (2e dition).
N11504, 576 pages.
R. Lefbure, G. Venturi. Gestion de la relation client.
N11331, 2004, 466 pages.
J.-L. Montagnier. Rseaux dentreprise par la pratique.
N11258, 2004, 556 pages.
L. Verlaine, F. Hardange, F. Biard, D. Elias. Tests de performances des applications Web.
N11395, 2003, 246 pages.
P. Devoitine. Mettre en place et exploiter un centre dappels.
N11122, 2003, 402 pages.
F. Rivard, T. Plantain. LEAI par la pratique.
N11199, 2002, 416 pages.
F. Alin, X. Amoros, M. Saliou. Lentreprise intranet.
Guide de conduite de projet.
N11118, 2002, 228 pages.
F A B R I C E G A R N I E R D E L A B A R E Y R E
Prface de Didier Lambert

Avec la collaboration de J.-M. Chabbal, T. Gasiorowski, F. Legger et L. Vakil
CobiT
DITIONS EYROLLES
61, bd Saint-Germain
75240 Paris Cedex 05
www.editions-eyrolles.com
Le code de la proprit intellectuelle du 1er juillet 1992 interdit en effet expressment la

photocopie usage collectif sans autorisation des ayants droit. Or, cette pratique sest
gnralise notamment dans les tablissements denseignement, provoquant une baisse
brutale des achats de livres, au point que la possibilit mme pour les auteurs de crer des
uvres nouvelles et de les faire diter correctement est aujourdhui menace.
En application de la loi du 11 mars 1957, il est interdit de reproduire intgralement ou
partiellement le prsent ouvrage, sur quelque support que ce soit, sans autorisation de lditeur ou du Centre
Franais dExploitation du Droit de Copie, 20, rue des Grands-Augustins, 75006 Paris.
Groupe Eyrolles, 2009, ISBN : 978-2-212-12427-9
Livre CobiT.book Page V Lundi, 1. dcembre 2008 2:48 14
Prface
Prolifration de modles et de sigles, contraintes de plus en plus fortes,
exigence croissante de matrise de leurs activits : les DSI ne savent plus
parfois quel saint se vouer.
Par o commencer ? ISO, CobiT, ITIL, Lean, CMMi? Pour le nophyte, cest
tout un nouveau continent explorer. Louvrage de Dominique Moisand et
de ses collaborateurs a pour premier mrite de resituer tous ces modles
dans leur perspective relle.
Issu de laudit, dans sa partie noble qui consiste non dnoncer les imperfections mais aider le responsable progresser dans son mtier, CobiT
est devenu un formidable outil dorganisation du mtier de DSI. Par son
approche rigoureuse des processus qui rglent la vie de linformatique en
entreprise, par ladoption progressive de rfrentiels (vocabulaire, concepts,
mesures) qui simposent toute notre profession, il devient la cl de vote
de la dmarche damlioration continue qui simpose tous.
Malgr tout, son adoption se heurte encore bien souvent au caractre parfois sotrique des manuels de rfrence, le manager oprationnel hsitant
se lancer dans un projet quil ne se sent pas capable de matriser.
Cet ouvrage vient combler cette lacune : dmystifier, rendre immdiatement accessibles les concepts soutenant la dmarche CobiT, et proposer
une manire simple et rapide de dmarrer le projet dutilisation de ce rfrentiel dans toutes les entreprises.
Grer une informatique dentreprise est une science encore jeune et imparfaite mais dont limportance ne cesse de crotre, avec lmergence acclre de ce monde numrique indispensable toute activit conomique.
Gageons que la lecture de ce livre dcidera nombre de DSI qui ne lont pas
encore fait sauter le pas, sengager dans cette voie de lexcellence.
Sans oublier le vieux proverbe plus ou moins chinois :
Les modles sont de bons serviteurs et de mauvais matres.
Didier Lambert, ancien prsident du Cigref
et DSI dEssilor
Livre CobiT.book Page VI Lundi, 1. dcembre 2008 2:48 14
Livre CobiT.book Page VII Lundi, 1. dcembre 2008 2:48 14
Table des matires

Partie I
CobiT et la gouvernance TI
Chapitre 1 Prsentation gnrale de CobiT . . . . . . . . . . . . . . . . . . . . . . .
Historique de CobiT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CobiT et la gouvernance TI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lapport de CobiT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Les cinq axes stratgiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapitre 2 Les autres rfrentiels de la gouvernance des TI . . . . . . . . . . . 11

Le pilotage stratgique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
Le COSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
Le Balanced Scorecard (BSC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
Le management de la scurit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
La norme ISO/IEC 27001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
Les normes ISO/IEC 17799 et ISO/IEC 27002 . . . . . . . . . . . . . . . . . . .
15
Les critres communs (ISO/IEC 15408) . . . . . . . . . . . . . . . . . . . . . . . .
16
ITIL : le management des services . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
ITIL V2 et la norme ISO/IEC 20000 . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
ITIL V3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
Le management des tudes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
Le CMMI et la norme ISO/IEC 15504 . . . . . . . . . . . . . . . . . . . . . . . . .
22
Les modles qualit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
La norme ISO 9001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
VII
Livre CobiT.book Page VIII Lundi, 1. dcembre 2008 2:48 14
Table des matires
Le modle EFQM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
Le dveloppement durable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
En rsum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
Chapitre 3 Apprhender CobiT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
Description gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
Les composants de CobiT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
Les processus dans CobiT V4.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
Les documents et publications autour de CobiT . . . . . . . . . . . . . . .
36
destination de la direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
destination des mtiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
destination de la gouvernance TI, du contrle et de la scurit . . . . . . . .
37
Autres publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
Description dtaille de certaines publications . . . . . . . . . . . . . . . . . . . . .
38
Comment aborder CobiT ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
qui sadresse CobiT ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
Les limites : ce que CobiT nest pas . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
En rsum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
Partie II
Description dtaille des processus
Chapitre 4 Planifier et Organiser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
PO1 Dfinir un plan informatique stratgique . . . . . . . . . . . . . . . . . . .
51
PO2 Dfinir larchitecture de linformation . . . . . . . . . . . . . . . . . .
55
PO3 Dterminer lorientation technologique . . . . . . . . . . . . . . . . . . .
59
PO4 Dfinir les processus, lorganisation et les relations de travail 63

PO5 Grer les investissements informatiques . . . . . . . . . . . . . . . . . . .
68
PO6 Faire connatre les buts et les orientations du management .
73
PO7 Grer les ressources humaines de linformatique . . . . . . . . .
76
PO8 Grer la qualit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
PO9 valuer et grer les risques . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
PO10 Grer les projets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
En rsum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
VIII
Livre CobiT.book Page IX Lundi, 1. dcembre 2008 2:48 14
Table des matires
Chapitre 5 Acqurir et Implmenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

AI1 Trouver des solutions informatiques . . . . . . . . . . . . . . . . . . . . .
95
AI2 Acqurir des applications et en assurer la maintenance . . . . . .
99
AI3 Acqurir une infrastructure technique et en assurer

la maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
AI4 Faciliter le fonctionnement et lutilisation . . . . . . . . . . . . . 108
AI5 Acqurir des ressources informatiques . . . . . . . . . . . . . . . . . . . . . . 112
AI6 Grer les changements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
AI7 Installer et valider des solutions et des modifications . . . . . . 121
En rsum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Chapitre 6 Dlivrer et Supporter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

DS1 Dfinir et grer les niveaux de services. . . . . . . . . . . . . . . . . . . 127
DS2 Grer les services tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
DS3 Grer la performance et la capacit . . . . . . . . . . . . . . . . . . . . . 136
DS4 Assurer un service continu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
DS5 Assurer la scurit des systmes . . . . . . . . . . . . . . . . . . . . . . . 144
DS6 Identifier et imputer les cots . . . . . . . . . . . . . . . . . . . . . . . . . 148
DS7 Instruire et former les utilisateurs . . . . . . . . . . . . . . . . . . . . . . 153
DS8 Grer le service dassistance aux clients et les incidents . . . . . 156
DS9 Grer la configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
DS10 Grer les problmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
DS11 Grer les donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
DS12 Grer lenvironnement physique . . . . . . . . . . . . . . . . . . . . . . . 171
DS13 Grer lexploitation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
En rsum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Chapitre 7 Surveiller et valuer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

SE1 Surveiller et valuer la performance des SI . . . . . . . . . . . . . . . 179
SE2 Surveiller et valuer le contrle interne . . . . . . . . . . . . . . . . . . . . . 183
SE3 Sassurer de la conformit aux obligations externes. . . . . . . . 187
SE4 Mettre en place une gouvernance des SI . . . . . . . . . . . . . . . . . . . . 190
En rsum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
IX
Livre CobiT.book Page X Lundi, 1. dcembre 2008 2:48 14
Table des matires
Partie III
Mettre en uvre CobiT
Chapitre 8 CobiT pour laudit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Le code professionnel dthique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
La mission daudit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Lapport de CobiT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Le contrle interne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Loutil Quick Scan de CobiT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Quick Scan en quelques mots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Quick Scan en questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
En rsum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Chapitre 9 CobiT fdrateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Le pilotage stratgique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Cadran 1 - Contribution stratgique . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Cadran 2 - Relation client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Cadran 3 - Futur et anticipation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Cadran 4 - Excellence oprationnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
ITIL et le management des services TI . . . . . . . . . . . . . . . . . . . . . . . . 207
ITIL et CobiT : la complmentarit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Pourquoi les associer ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Conjuguer ITIL et CobiT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
La scurit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
CobiT et la norme ISO/IEC 27002 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
CobiT et lISO/IEC 27001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Le management des tudes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
CobiT et CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
La certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Scnario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Scnario 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Comparaison des scnarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Exemples de dploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
En rsum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Livre CobiT.book Page XI Lundi, 1. dcembre 2008 2:48 14
Table des matires
Chapitre 10 Transformer la DSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

CobiT Quickstart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prsentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Les hypothses de CobiT Quickstart . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Le contenu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pour un dploiement tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Les pralables recueillir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple de dploiement progressif . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
En rsum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
223
223
224
224
225
225
227
231
Partie IV
Annexes
Annexe I Glossaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Annexe II Objectifs du systme dinformation et processus CobiT . . . . . 243
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
XI
Livre CobiT.book Page XII Lundi, 1. dcembre 2008 2:48 14
Livre CobiT.book Page XIII Lundi, 1. dcembre 2008 2:48 14
Avant-propos
Cet ouvrage sadresse tous ceux qui sintressent la gouvernance des
systmes dinformation. En raison du foisonnement des rfrentiels et des
standards, il est indispensable de situer CobiT V4.1 dans cet ensemble.
Nous avons retenu quatre grands courants qui alimentent cette recherche
incessante : lISACA (Information System Audit and Control Association), association base aux tats-Unis, trs active dans le monde entier et qui est
lorigine de CobiT ; le SEI (Software Engineering Institute) dont les recherches
ont abouti la cration de CMMi ; lOGC (Office of Government Commerce), trs
prsent en Grande-Bretagne, en particulier lorigine dITIL, et enfin lISO
(Organisation internationale de normalisation) qui accompagne ces travaux
en les insrant dans un cadre juridique normatif.
La premire partie de ce livre est consacre une prsentation gnrale de
CobiT et des autres rfrentiels. Le chapitre 1 rappelle lhistorique qui a
conduit des premires versions de CobiT, orientes rfrentiels daudit,
la srie des versions 4, axes en priorit guide de management . Le chapitre 2 brosse un rapide tableau des principaux rfrentiels auxquels le DSI
doit se confronter, soit parce quil sagit de standards de facto ou parce que
leur apport dans la gouvernance des systmes dinformation est incontournable. Le chapitre 3 permet dapprhender CobiT comme fdrateur des
principaux rfrentiels. Il reprend tout dabord lessentiel de la prsentation
de louvrage de lAFAI sur la V4.1 de CobiT, puis dcrit la multitude de
documents disponibles sur le site www.isaca.org (en anglais) la date
de parution de ce livre. Ce chapitre sert dintroduction la partie suivante.
La deuxime partie offre une lecture commente de CobiT en dtaillant ses
34 processus selon quatre chapitres, correspondant aux quatre domaines
de processus du rfrentiel : Planifier et Organiser, Acqurir et Implanter,
Dlivrer et Supporter, Surveiller et valuer. Au sein de ces chapitres, les
processus sont dcrits en respectant un plan standardis.
La troisime partie aborde la mise en uvre de CobiT, avec trois cibles : la
premire correspond laudit, le cur de cible initial de CobiT depuis
quinze ans environ, la deuxime place CobiT en fdrateur des autres rfrentiels de la gouvernance, et la troisime aborde le dploiement de CobiT
partir dexemples prcis. En synthse, nous proposons une sorte de
XIII
Livre CobiT.book Page XIV Lundi, 1. dcembre 2008 2:48 14
Avant-propos
modle progressif de dploiement, tir des expriences de mission menes

depuis une dizaine dannes sur ces sujets.
Cet ouvrage se veut pragmatique et utile. Aussi navons-nous pas hsit
prendre position sur la pertinence de certains composants du rfrentiel,
sur ce qui, nos yeux, fait la force de CobiT ou au contraire ne figure qu
titre indicatif.
XIV
Livre CobiT.book Page 1 Lundi, 1. dcembre 2008 2:48 14
PARTIE
CobiT et
la gouvernanceTI
La gouvernance des Technologies de lInformation (TI) regroupe
lensemble du systme de management (processus, procdures, organisation) permettant de piloter les TI. Cette proccupation est une dclinaison
de la volont dassurer une gouvernance dentreprise (corporate gouvernance).
Il existe un grand nombre de rfrentiels qui refltent les bonnes pratiques
mises au point au fil des annes. On peut sen tonner. La ralit est que
chacun deux part dune proccupation particulire : la scurit, la qualit,
les services offerts aux clients, laudit, le dveloppement de projet, etc.
Cest un mal ncessaire pour que chaque fonction se reconnaisse dans ses
propres pratiques. Simultanment se pose la question de la mise en place
dun cadre global, unique pour la DSI, qui rponde toutes les attentes.
CobiT se positionne la fois comme un rfrentiel daudit et un rfrentiel
de gouvernance. Sur le plan de la gouvernance, il se place demble en alignement avec les mtiers et la stratgie de lentreprise. Au-del de ces
positionnements, CobiT est conu, dvelopp et amlior en permanence
pour fdrer lensemble des rfrentiels en rapport avec les TI.
Lensemble de cette problmatique, gouvernance des TI, diversit des rfrentiels et convergence pour la DSI, est traite dans cette premire partie,
qui prsente galement la structure de base de CobiT.
Chapitre 1
Prsentation
gnrale de CobiT
Historique de CobiT
CobiT est le rsultat des travaux collectifs raliss par les principaux
acteurs de la profession, auditeurs internes ou externes, fdrs au sein de
lISACA (Information System Audit and Control Association). Cette association
mondiale base aux tats-Unis est dploye dans les plus grandes villes
du monde. Elle est reprsente en France par lAFAI (Association franaise
pour laudit et le conseil en informatique).
Dans ses premires versions, publies partir de 1996, CobiT (Control
OBjectives for Information and related Technology) se positionne comme un
rfrentiel de contrle. Il dcline sur le domaine IT les principes du
rfrentiel COSO (Committee of Sponsoring Organizations of the Treadway
Commission), publis pour la premire fois en 1992 et dont lobjectif est
daider les entreprises valuer et amliorer leur systme de contrle
interne.
La mise en chantier de CobiT rsultait donc de la volont des auditeurs
de rpondre aux exigences du COSO et de partager les mmes plans
daudit. La plupart des grands cabinets daudit internationaux (les big 6
lpoque) y ont particip. Cest ainsi devenu un standard de fait, au
moins pour les auditeurs informatiques. On y trouvait lessentiel de la
structuration actuelle en domaines, processus et objectifs de contrle
dtaills.
En 1998, lITGI (Information Technology Governance Institute) a t cr sur linitiative de lISACA, en rponse la place de plus en plus importante
occupe par les technologies de linformation. En effet, dans la plupart des
organisations ou des entreprises, lun des principaux facteurs de succs
rside dans la capacit des systmes dinformation apporter la fois la
Partie I CobiT et la gouvernanceTI
Des Big 8 aux Big 4

Dans les annes 1970-1980, les principaux groupes d'audit mondiaux taient surnomms les Big 8 ; il s'agissait de : Arthur Andersen, Arthur Young, Coopers &
Lybrand, Ernst & Whinney, Haskins & Sells (fusionn avec Deloitte), KPMG, Price
Waterhouse, Touche Ross.
Dans les annes 1990, les Big 8 deviennent les Big 6 suite la fusion d'Erns &
Whinney avec Arthur Young pour former Ernst & Young, et de la fusion de Deloitte,
Haskins & Sells avec Touche Ross pour crer Deloitte & Touche.
En 1998, les Big 6 deviennent les Big 5, suite la fusion de Price Waterhouse et
Coopers & Lybrand pour former PricewaterhouseCoopers.
Depuis 2002 et le scandale Enron qui a abouti au dmantlement d'Andersen, on
parle des Big 4. (Deloitte, Ernst & Young, KPMG, PricewaterhouseCoopers).
diffrenciation stratgique et le support des activits. Dans un tel contexte,

la gouvernance des systmes dinformation devient aussi critique que
la gouvernance dentreprise.
Depuis une dizaine dannes, lITGI a men de nombreuses recherches au
travers de groupes de travail rpartis dans le monde entier. Le rsultat de
ces recherches a notamment donn lieu en 2000 la publication de la
version V3 du rfrentiel CobiT proposant, paralllement un guide
daudit , un guide de management prfigurant les versions ultrieures.
la suite des scandales ayant eu lieu au dbut des annes 2000 (Enron,
etc.), le Congrs amricain vote, en 2002, la loi Sarbanes-Oxley (SOX) afin
de redonner confiance aux investisseurs et aux actionnaires en garantissant la fois la transparence des comptes, lexistence de processus
dalerte et lengagement des dirigeants (PDG, DAF). Ceci se traduit par un
renforcement des contrles lis aux processus financiers. On retiendra, par
exemple, la section 404 qui exige un contrle strict des accs et des autorisations. CobiT a t reconnu comme une rponse ces nouvelles exigences,
tant en termes de contrle que de gouvernance.
1. Information Technology (IT) : se rapporte
tantt au potentiel
global offert par les
technologies de
linformation (TI), ou
leur utilisation dans
lentreprise sous
forme de systmes
dinformation (SI).
La gnralisation de la loi SOX ou de ses dclinaisons locales ou sectorielles (IFRS, International Financial Reporting Standards, LSF, Loi de scurit
financire, normes Ble II) a considrablement renforc le rle des auditeurs. Ces dispositions rglementaires ont acclr la diffusion de CobiT
comme rfrentiel de contrle et de gouvernance des SI. Ensuite, lISACA a
publi successivement la version 4 (dcembre 2005) puis la version 4.1
(2007) de CobiT, en regroupant deux visions : le contrle et le management des systmes dinformation (SI) et, plus largement, des technologies
de linformation (TI)1.
Chapitre 1 Prsentation gnrale de CobiT
CobiT et la gouvernance TI
Lapport de CobiT
En tant que rfrentiel de la gouvernance des systmes dinformation, le
primtre de CobiT dpasse celui dvolu la direction des systmes
dinformation pour englober toutes les parties prenantes des SI dans
lentreprise (stakeholders1). Ainsi, selon CobiT, la gouvernance des systmes dinformation est de la responsabilit des dirigeants et du conseil
dadministration, elle est constitue des structures et processus de commandement et de fonctionnement qui conduisent linformatique de
lentreprise soutenir les stratgies et les objectifs de lentreprise, et lui
permettre de les largir .
Contrles mtier, gnraux et applicatifs : limites
RESPONSABILITE METIER
Contrle mtier
RESPONSABILITE IT
Contrle gnral IT
RESPONSABILITE METIER
Contrle mtier
Planifier et
Organiser
Exigences de
fonctionnement
Exigences de
contrle
Acqurir et
Implmenter
Dlivrer et
Supporter
Services
automatiss
Surveiller et
Evaluer
CONTROLES APPLICATIFS
Figure 1-1 : Rpartition des responsabilits de la gouvernance TI
La figure 1-1 illustre aussi bien la responsabilit de la fonction IT sur les

quatre grands domaines de la gouvernance selon CobiT (planifier et organiser, dlivrer et supporter, surveiller et valuer, acqurir et implmenter)
que les responsabilits des mtiers.
CobiT se fixe des objectifs trs pragmatiques refltant les proccupations
de la direction gnrale, tels que :
articuler le systme dinformation aux besoins des mtiers, cest lalignement stratgique ;
apporter des avantages concrets au fonctionnement des processus
mtier (efficacit et efficience) ;
1. Stakeholders :
reprsente lensemble
des acteurs concerns
par la gouvernance
des SI, aussi bien
les actionnaires et
la direction gnrale
que les mtiers.
Ce terme est souvent
traduit par les parties
prenantes.
utiliser lensemble des ressources en liaison avec les SI (infrastructures,

applications, informations et personnes) de faon optimise et responsable ;
matriser les risques lis au SI et leurs impacts pour les mtiers.
1. On entend par processus un ensemble
dactivits corrles
qui transforme des
lments entrants en
lments sortants, les
activits tant ellesmmes dcrites dans
des procdures.
Structur en processus1, CobiT prend en compte les besoins des mtiers,

et plus gnralement des parties prenantes, dans une logique damlioration continue. Le pralable toute diffusion de CobiT est donc la diffusion
dune culture de lamlioration au service des clients de la DSI. Cette approche
rappelle lISO 9001.
Les entres des processus CobiT sont bases sur les exigences ngocies des parties prenantes (mtiers, etc.) conduisant des objectifs.
Ensuite, lexcution des processus est garantie par des responsabilits
clairement affectes et des mesures de performances face aux objectifs
fixs. La satisfaction des clients fait partie des mesures de performance.
ce stade, loriginalit de CobiT est sans doute de crer systmatiquement
un lien entre parties prenantes et DSI, ce qui ncessite bien souvent une
petite rvolution culturelle aussi bien pour les acteurs de la DSI dans leur
tour divoire que pour les mtiers et la direction gnrale qui ignoreraient
superbement le caractre stratgique des SI. Le point cl sous-jacent
cette dmarche est linstauration de dialogues constructifs tous les
niveaux de lorganisation, entre parties prenantes et DSI.
Ce postulat pos, chaque processus propose une liste dobjectifs de contrle
qui nous semble solide et une vision du management du processus (activits principales, responsabilits et indicateurs) qui nous parat plutt
indicative et sujette contextualisation.
Le rfrentiel CobiT, avec ses 34 processus gnriques, est une proposition
qui pourra tre revue pour sadapter la cartographie propre de lorganisation considre. De la mme faon, on pourra facilement coupler CobiT
dautres rfrentiels du march (ISO 27001, ITIL pour Information Technology
Infrastructure Library ou CMMI pour Capability Maturity Model Integration) en
btissant un cadre de rfrence satisfaisant lensemble des exigences. Ceci
est dautant plus vrai que les processus de CobiT sont parfois globaux et
sinterprtent souvent comme des macroprocessus de rfrentiels plus
spcialiss. CobiT est donc un cadre fdrateur.
CobiT sert aussi comparer entre elles (benchmark) diffrentes entits de
lentreprise. Il permet galement, avec les restrictions dusage, de se comparer dautres entreprises. Plus couramment, il conduit la dfinition de
ses propres objectifs et leur valuation priodique.
Les membres de lISACA utilisent CobiT dans de nombreux secteurs dactivit travers le monde. Les spcificits culturelles et les diffrences
davance de dveloppement sur le plan technologique ne semblent pas
limiter ladquation de CobiT pour lalignement des systmes dinformation
aux objectifs stratgiques de lentreprise.
Les cinq axes stratgiques

En rponse la volont dexercer une bonne gouvernance des SI, CobiT
sattache aux cinq axes prsents ci-aprs.
Domaines de la gouvernance des SI
GOUVERNANCE SI
Alignement
stratgique
Lapport de valeur
Consiste mettre en uvre la proposition de valeur
ajoute tout au long de la fourniture du service,
sassurer que linformatique apporte bien les bnfices
attendus sur le plan stratgique, sattacher optimiser
les cots et prouver la valeur intrinsque des SI.
Lalignement stratgique
Consiste sassurer que les plans informatiques restent
aligns sur les plans des mtiers, dfinir, tenir jour et
valider les propositions de valeur ajoute de
linformatique, aligner le fonctionnement de
linformatique sur le fonctionnement de lentreprise.
Apport de valeur
Gestion des
risques
La gestion des ressources
Consiste optimiser linvestissement dans les
ressources informatiques vitales et bien les grer :
applications, informations, infrastructures et personnes.
Les questions cls concernent loptimisation des
connaissances et de linfrastructure.
La gestion des risques

Exige une conscience des risques de la part des cadres
suprieurs, une vision claire de lapptence de
lentreprise pour le risque, une bonne connaissance des
exigences de conformit, de la transparence propos
des risques significatifs encourus par lentreprise et
lattribution des responsabilits dans la gestion des
risques au sein de lentreprise.
Gestion des
ressources
Mesure de la
performance
La mesure de la performance
Consiste en un suivi et une surveillance de la mise en
uvre de la stratgie, de laboutissement des projets,
de lutilisation des ressources, de la performance des
processus et de la fourniture des services, en utilisant
par exemple des tableaux de bord quilibrs qui
traduisent la stratgie en actions orientes vers le
succs dobjectifs mesurables autrement que par la
comptabilit conventionnelle.
Figure 1-2 : Les domaines de la gouvernance des TI
Lalignement stratgique
Les activits informatiques prennent de plus en plus dimportance dans le
fonctionnement des mtiers de lentreprise. Il est donc indispensable que
la rponse de linformatique soit celle attendue par les mtiers. Prenons, par
exemple, une direction marketing qui souhaite lancer un nouveau produit
ou service. Il est indispensable de sassurer que les exemplaires de ce produit,
lorsquils seront disponibles, pourront tre commands puis facturs. Si le
canal de commande est le Web, la disponibilit de lapplication de commande en ligne doit tre assure avec lensemble des lments ncessaires
la commande du produit (rfrences, prix, conditions particulires, etc.).
Par alignement stratgique, il faut donc entendre la capacit fournir les
services souhaits en temps et en heure avec le niveau de qualit requis.
Dans le cas de notre direction marketing, cela signifie que le projet de mise
disposition de commande en ligne doit tre identifi et prioris ds la
rflexion amont par la direction marketing, ceci afin dtre dans les temps
au moment de lannonce du produit au march. Lalignement stratgique
se matrialise par un plan stratgique qui devra traiter des budgets
dinvestissements et de fonctionnement, des sources de financement, des
stratgies de fourniture et dachats tout en intgrant les exigences lgales
et rglementaires.
Lapport de valeur
Linformatique doit galement pouvoir apporter un gain identifiable dans
la bonne excution des processus mtier. Dans le cas de notre direction
marketing, lapport de valeur va se matrialiser par la mise en place dun
canal de distribution adressant une nouvelle clientle. Il permettra la vente
permanente du produit tout en saffranchissant des contraintes de la distribution classique organise autour dun lieu gographique et de plages
horaires plus limites que laccs Web. Dans le processus de distribution,
lapport de linformatique doit pouvoir tre mesur afin didentifier la
valeur apporte en termes de volume de ventes, de progression de chiffre
daffaires et de marge par rapport aux prvisions. Lapport de valeur se
concrtise par la matrise des processus de fonctionnement en termes
defficacit et defficience. Ceci vient complter le processus de pilotage
des investissements qui traitera des cots, des bnfices et des priorits
en fonction de critres dinvestissement tablis (ROI [Return On Investment],
dure damortissement, valeur nette actuelle).
La gestion des ressources
1. Make or buy : dcision stratgique de
coner une activit
un tiers ou de la dvelopper en interne.
Ainsi, par exemple,
les centres dappel
pour le support informatique sont souvent
cons des tiers. Les
raisons de ce choix
sont multiples : comptences mobiliser,
masse critique, professionnalisation,
logistique, temps de
mise en uvre, prix.
Les ressources pour mesurer lactivit informatique doivent tre optimales pour rpondre aux exigences des mtiers. Dans notre exemple de
direction marketing, cela revient dire que les ressources humaines et
technologiques sont mobilises au mieux en termes de volume, dexpertise/comptences, de dlai et de capacit. Cette gestion des ressources se
matrialise par une cartographie des comptences et un plan de recrutement/formation en ce qui concerne les ressources humaines. Cette gestion des ressources est articule la gestion des tiers afin doptimiser le
make or buy1.
Les ressources technologiques font partie du primtre et donneront lieu
un plan dinfrastructure. Celui-ci traitera des orientations technologiques, des acquisitions, des standards et des migrations. Dans ce cas,
la responsabilit du mtier consiste exprimer ses besoins, par exemple,
en termes de capacit (comme le nombre de clients en ligne simultanment).
La gestion des risques

Dans certains secteurs, lactivit cur de mtier de lentreprise peut tre
mise en pril en cas darrt ou de dysfonctionnement de ses systmes
informatiques, car la dpendance des processus mtier envers linformatique est totale. Dans notre exemple de distribution par le Web, si ce canal
est le seul prvu pour le produit en question, lindisponibilit pour cause
de panne ou de retard dans louverture du service de commande en ligne
se solde par une perte nette de revenus qui ne sera jamais rcupre. Dans
le secteur du transport arien, la panne du systme de rservation peut
clouer au sol lensemble des avions dune compagnie. Dans le monde
boursier, larrt des systmes informatiques stoppe immdiatement toutes
les transactions. La gestion des risques informatiques ou des systmes
dinformation correspond un rfrentiel qui comprend une analyse de
risque et un plan de traitement des risques associ. Ce plan de traitement
des risques doit tre tabli selon des critres de tolrance par rapport au
prjudice financier li la ralisation des risques. Cela veut dire en dautres
termes que les moyens engags pour couvrir les risques ne doivent pas coter
plus cher que le prjudice lui-mme.
La mesure de la performance
La mesure de la performance rpond aux exigences de transparence et de
comprhension des cots, des bnfices, des stratgies, des politiques et
des niveaux de services informatiques offerts conformment aux attentes
de la gouvernance des systmes dinformation. L encore, CobiT tente de
faire le lien entre les objectifs de la gouvernance et les objectifs dcliner
sur les processus ou les activits. Ce faisant, on cre du lien et on donne
du sens aux objectifs de performance des SI comme support aux mtiers.
Ces mesures peuvent facilement se traduire par la mise en place dun BSC
(Balanced Scorecard1) qui va offrir une vision densemble de la performance.
1. BSC, Balanced Scorecard (ou tableau de

bord quilibr) : reprsentation de la performance de lentreprise
selon 4 quadrants le
nancier, la relation
client, lanticipation
et loprationnel.
Le BSC a t dvelopp en 1992 par
Robert S. Kaplan et
David Norton.
Chapitre 2
Les autres rfrentiels

de la gouvernance
des TI
En ce qui concerne la gouvernance des TI, il existe de nombreux cadres
de rfrence, chacun avec leur point de vue. Ainsi, chaque cadre de rfrence offre un niveau de dtail appropri dans son domaine. Lune des
difficults de la gouvernance des TI est bien de faire coexister les approches terrain, forcment dtailles et spcialises, et les synthses de
pilotage stratgique. Ce chapitre prsente les principaux rfrentiels en
matire de pilotage global, de pilotage des services, des projets et de la
scurit des TI.
Le pilotage stratgique
Nous allons ici aborder deux approches distinctes de la gouvernance
dentreprise, le COSO et le Balanced Scorecard (BSC).
Le COSO
Le COSO (Committee of Sponsoring Organizations of the Treadway Commission) a
publi en 1992 un cadre de rfrence pour le contrle interne afin daider
les entreprises valuer et amliorer leur systme de contrle interne. Le
contrle interne y est dcrit comme un processus tant sous la responsabilit dune instance constitue dans le but dassurer la ralisation dobjectifs regroups dans les domaines suivants :
efficacit et efficience des oprations ;
fiabilit des rapports financiers ;
conformit aux lois et rglements.
11
En 2004, le COSO a publi le document Management des risques dans lentreprise

(Enterprise Risk Management ou ERM) qui largit le primtre du contrle
interne. LERM englobe :
la notion de portefeuille de risques ;
une structuration en quatre catgories dobjectifs (oprations, reporting,
conformit et objectifs stratgiques) ;
le niveau de prise de risque dcid de faon stratgique par lentreprise ;
les vnements qui impactent les risques ;
les quatre catgories de rponse aux risques (viter, rduire, partager et
accepter) ;
le primtre de linformation et de la communication ;
les rles et les responsabilits des acteurs en charge de la scurit mais
aussi des directeurs (board).
Un rsum en franais de ce document est disponible ladresse
http://www.coso.org/documents/COSO_ERM_Executivesuivante :
Summary_french.pdf.
Le Balanced Scorecard (BSC)

Le Balanced Scorecard (BSC), ou tableau de bord prospectif, est une reprsentation qui permet de clarifier la vision et la stratgie dune entreprise,
et de la traduire en plans daction. Il donne aussi bien le retour sur le
fonctionnement des processus internes que des contraintes externes,
permettant dentrer dans une amlioration permanente de la stratgie
et de la performance. Ses auteurs, Robert Kaplan et David Norton, le
dcrivent comme suit : Le BSC prend en compte les rsultats financiers
traditionnels, mais ces rsultats nclairent que le pass, ce qui convenait
lre industrielle, avec des investissements long terme et une relation
client peu prsente. Ces lments financiers sont inadapts, cependant,
pour piloter les entreprises de lre de linformation qui doivent construire
leur future valeur au travers de linvestissement dans leurs clients, leurs
fournisseurs, leurs employs, leurs processus, leur technologie et leur
innovation.
Dans leur livre, The Balanced Scorecard: Translating Strategy into Action, traduit
en franais sous le titre Le tableau de bord prospectif, Robert Kaplan et David
Norton proposent un instrument de pilotage qui prsente lorganisation
sous quatre facettes : finance, client, processus internes et construction du
futur. Il est dsormais acquis que cette approche conduit une bonne
vision de la gouvernance dentreprise.
12
Chapitre 2 Les autres rfrentiels de la gouvernance des TI
Cette reprsentation valable pour lentreprise peut galement tre utilise

pour la gouvernance des systmes dinformation.
Contribution et alignement
Clients et utilisateurs
Contrle des cots

Rduction des cots
ROI / Automatisation
Valeur adaptative
Management de valeur
Indicateurs
Niveaux de services (SLA)

Conformit aux besoins
Exigences rglementaires
Respect du budget
Niveau de demande
Indicateurs
Budget informatique
Benchmarks
Performance de lentreprise
Qualit du service vs SLA

Satisfaction des utilisateurs et clients
Rclamations
Futur et anticipation
Performances oprationnelles
Gestion des comptences

Sourcing / Achats
Veille technologique
Architecture technique
Urbanisation
Indicateurs
Approvisionnements
Conduite de projets
Maintenance des applications
Exploitation, Administration
Support...
Indicateurs
Influence sur :
Performances
Benchmarks et tendances
Cots standards
performances
cots
niveaux de services
Figure 2-1 : Les quatre cartes stratgiques du Balanced Scorecard (BSC)
Dans cette reprsentation, le cadran 4, Performances oprationnelles,

sintresse aux processus informatiques qui peuvent faire lobjet de benchmarks et dindicateurs concrets, au sein de lentreprise ou dune entreprise
une autre. Les efforts mens sur ce cadran sont typiquement du ressort
de la DSI qui cherche se professionnaliser au mieux. Dans cet effort de
progression, elle doit tenir compte de deux contraintes :
clients et utilisateurs (cadran 2), la fois sous langle du niveau de
service rendre, mais aussi de la consommation du service ;
contribution et alignement (cadran 1), qui mettent linformatique
sous contrainte de cots, de flexibilit et de performance.
Le cadran 3, Futur et anticipation, reprsente la veille quil faut mener pour
optimiser 3, 4 ou 5 ans le systme dinformation (choix dinvestissement,
recrutements, externalisation, etc.).
La DSI pilote directement les cadrans 3 et 4, sous contrainte des cadrans 1
et 2.
13
Le management de la scurit
Plusieurs normes, mthodes et rfrentiels de bonnes pratiques en matire
de scurit des systmes dinformation sont disponibles. Ils constituent des
guides mthodologiques ainsi que les moyens de garantir une dmarche de
scurit cohrente.
LISO a entrepris un vaste effort de rationalisation des travaux existants,
donnant naissance la srie de normes ISO/IEC 27000. Ce nombre correspond la rservation dune srie de normes relatives la scurit. ce
jour, seules les normes 27000, 27001, 27002 et 27006 sont publies. Certaines sont obligatoires pour obtenir une certification, les autres ne sont
que de simples guides :
la norme ISO/IEC 27000 prsente le vocabulaire et les dfinitions du
domaine de la scurit, applicables chacun des standards ;
la norme ISO/IEC 27001 dcrit la politique du management de la scurit des systmes dinformation au sein dune entreprise qui sert de rfrence la certification ;
la norme ISO/IEC 27002 constitue le guide de bonnes pratiques de la
scurit des SI ;
la norme ISO/IEC 27003 a pour vocation dtre un guide dimplmentation ;
la norme ISO/IEC 27004 sera un nouveau standard pour le pilotage des
indicateurs et des mesures dans le domaine de la scurit des SI ;
la norme ISO/IEC 27005 sera un nouveau standard sur le management
des risques pour la scurit des SI ;
la norme ISO/IEC 27006 rsume les exigences applicables aux auditeurs
externes dans leur mission de certification sur lISO 27001.
La norme ISO/IEC 27001

La norme ISO/IEC 27001, publie en novembre 2005, dfinit la politique du
management de la scurit des SI au sein dune entreprise. Elle est issue
de la spcification BS 7799-2:1999 (Specification for Information Security Management Systems) qui dfinit les exigences respecter pour crer un ISMS
(Information Security Management System). Elle spcifie en annexe certains
contrles de scurit, tirs de la norme ISO/IEC 17799, dont la mise en
oeuvre est obligatoire. La norme ISO 27001 comprend six domaines de
processus.
Dfinir une politique de la scurit des informations.
Dfinir le primtre du systme de management de la scurit de linformation.
14
Raliser une valuation des risques lis la scurit.

Grer les risques identifis.
Choisir et mettre en uvre les contrles.
Prparer un SoA1 (Statement of Applicability).
Comme la norme ISO 9001, lISO/IEC 27001 porte autant sur lexistence
des dispositions mises en place, que sur leur efficacit et ltablissement
dune boucle damlioration2 (PDCA, pour Plan-Do-Check-Act).
Principe dun systme de management de la scurit de linformation (SMSI )
Planifier : Lorganisation doit
- dfinir la politique et le primtre
du SMSI
- identifier et dfinir les objectifs SM
Intgr
- manager par les processus et des
plans dactions associes
- prparer le dcret dapplication
Mettre en place et
exploiter le SMSI
tablir le SMSI
Plan
Do
Raliser : Lorganisation doit

- formaliser et mettre en place un
SMSI
- mettre en place des actions de
mise en uvre du SMSI
Agir : Lorganisation doit

- mettre en place les amliorations
identifies dans le SMSI
- entreprendre les actions correctives
et prventives appropries
- maintenir la communication avec
toutes les parties prenantes
- valider/dcider des amliorations
Act
Check
Contrler et
revoir le SMSI
Maintenir et
amliorer le SMSI
Vrifier : Lorganisation doit

- avoir des procdures de contrles
- conduire priodiquement des
revues defficacit du SMSI
- revoir les objectifs SMSI
- conduire des audits internes du
SMSI intervalles planifis
Figure 2-2 : La boucle PDCA applique au SMSI
Les normes ISO/IEC 17799 et ISO/IEC 27002

La norme ISO/IEC 17799 de 2005, renomme ISO/IEC 27002, spcifie une
politique de la scurit des systmes dinformation qui se prsente comme
un guide de bonnes pratiques.
De faon schmatique, la dmarche de scurisation du systme dinformation
doit passer par quatre tapes de dfinition.
1. Primtre protger (liste des biens sensibles).
2. Nature des menaces.
3. Impact sur le systme dinformation.
4. Mesures de protection mettre en place.
La norme ISO/IEC 27002 fournit des exemples et des indications sur les
niveaux 1 3, et liste pour le niveau 4 une srie de mesures mettre en
place. Elle comporte 39 catgories de contrle et 133 points de vrification
rpartis en 11 domaines.
Politique de scurit.
15
1. La certication
dun systme de
management de la
scurit de linformation (SMSI) suppose
un cadre de rfrence
qui permette de tracer les mesures qui
ont t retenues et
celles qui ont t
cartes, cest le SoA
(Statement of Availability).
2. Limplmentation
dun processus nest
rien sans la mise en
uvre de sa boucle
damlioration ou
roue de Deming. Elle
consiste implmenter un processus, le
mettre en uvre, en
mesurer les rsultats
puis lamliorer et
ceci rgulirement.
Organisation de la scurit :
organisation humaine, implication hirarchique ;
notion de propritaire dune information et mode de classification ;
valuation des nouvelles informations ;
mode daccs aux informations par une tierce partie ;
cas de lexternalisation des informations.
Classification et contrle des biens.
Scurit du personnel.
Scurit physique :
organisation des locaux et des accs ;
protection contre les risques physiques (incendies, inondations) ;
systmes de surveillance et dalerte ;
scurit des locaux ouverts et des documents circulants.
Communication et exploitation :
prise en compte de la scurit dans les procdures de lentreprise ;
mise en uvre des systmes de scurisation (antivirus, alarmes).
Contrle daccs :
dfinition des niveaux dutilisateurs et de leur droit daccs ;
gestion dans le temps des droits.
Acquisition, dveloppement et maintenance des systmes.
Gestion des incidents.
Management de la continuit de service.
Conformit :
dispositions rglementaires ;
dispositions lgales ;
dispositions internes (politique).
La norme ISO/IEC 27002 est oriente processus et son application dpasse
de ce fait les simples aspects de technique informatique. Elle sintresse
lorganisation du personnel ainsi quaux problmes de scurit physique
(accs, locaux).
Les critres communs (ISO/IEC 15408)

Origine
La norme ISO/IEC 15408 propose des critres communs dvaluation de la
scurit des technologies de linformation (Common Criteria (CC) for Information Technology Security Evaluation). Destine avant tout aux industriels du
secteur informatique, cette norme permet lvaluation des produits (matriels, logiciels) au niveau international. Elle dfinit les procdures et les
16
mesures techniques mises en place dans le cycle de vie dun systme

dinformation pour fournir une base de comparaison sur les caractristiques de scurit.
Laccord dit CCRA (Common Criteria Recognition Arrangement) a runi 7 pays
capables de dlivrer des certifications, savoir lAllemagne, lAustralie, la
Nouvelle-Zlande, le Canada, les tats-Unis, la France et la Grande-Bretagne.
Plusieurs autres pays (Finlande, Grce, Italie, Isral, Japon, Pays-Bas, Norvge
et Espagne) nont pas de structure de certification mais reconnaissent la validit des critres communs (CC). Cet accord reprend notamment les
normes ITSEC en Europe et TCSEC (Livre Orange) aux tats-Unis, et
permet de dfinir et de valider un certain niveau de scurit atteindre.
Dnition des critres communs (CC)

Les documents dcrivant les CC sont disponibles sur le site de la DCSSI
(Direction centrale de la scurit des systmes dinformation) ladresse
http://www.ssi.gouv.fr/fr/confiance/methodologie.html. La DCSSI est
lautorit nationale franaise de rgulation de la scurit des systmes
dinformation ; elle dpend du Premier ministre. Les critres communs
sont structurs en trois publications :
introduction et modle gnral ;
exigences fonctionnelles de scurit ;
exigences dassurance de scurit.
La norme introduit plusieurs concepts fondamentaux :
TOE (Target of Evaluation) : dsignation de lobjet certifier ;
PP (Protection Profile) : ensemble type dexigences de scurit pour une
catgorie de produits ;
ST (Security Target) : niveau de scurit spcifique souhait pour le produit
valuer ;
les composants, qui reprsentent les ensembles lmentaires dexigences
de scurit.
Les systmes concerns par les critres communs
Les systmes et produits concerns sont, bien sr, ceux consacrs la
scurit des systmes dinformation :
antivirus ;
authentification, PKI/KMI ;
contrle biomtrique ;
pare-feu (firewalls) ;
IDS ;
systmes daccs ;
etc.
17
Et aussi les dispositifs ddis aux communications :

gestionnaires de rseaux ;
routeurs, switchs, hubs ;
VPN ;
etc.
voire les systmes dexploitation eux-mmes.
Les niveaux dvaluation

La certification propose 7 niveaux dassurance dvaluation (EAL, Evaluation
Assurance Level) des critres communs.
Tableau 2-1 : Niveaux dvaluation (EAL, Evaluation Assurance Level) des critres communs
Niveau dvaluation
Critre
EAL1
Test fonctionnellement.
EAL2
Test structurellement.
EAL3
Test et vri mthodiquement.
EAL4
Conu, test et vri mthodiquement.
EAL5
Conu de faon semi-formelle et test.
EAL6
Conception vrie de faon semi-formelle et teste.
EAL7
Conception vrie de faon formelle et teste.
Le distinguo entre conu mthodiquement et conu de faon semiformelle ou formelle, rside dans lemploi ou non de techniques dingnierie scurise avres.
Les CC sont utiliss pour certifier les objectifs dvaluation (TOE) par
rapport aux niveaux dvaluation garantir (EAL).
Chaque certification concerne une cible prcise (dsignation du systme
ou du primtre concern par la certification). Une telle cible peut tre, par
exemple :
un systme dexploitation ;
un rseau informatique ;
une application.
La cible est libre, cest le demandeur qui la dfinit. Elle peut tre dcrite
soit par un constructeur, soit par toute autre organisation (entreprise
cliente, pays, administration) qui demande la certification dun produit.
Chaque certificat possde sa propre cible dvaluation, nomme TOE.
18
Les composants
La politique de scurit est dcrite laide de composants qui constituent
des ensembles dexigences de scurit. On trouve des composants fonctionnels (exigences fonctionnelles) et des composants dassurance (garanties apportes). Par exemple, une famille de composants est ddie la
protection des donnes de lutilisateur, une autre la gestion de la configuration.
PP (Protection Profile)
Pour guider les concepteurs et les valuateurs, il existe des ensembles de
critres prdfinis, les profils de protection (on en compte prs de 1 000).
Un PP dfinit un ensemble dobjectifs et dexigences pour une catgorie de
produits. Par exemple, le CELAR (Dlgation gnrale pour larmement,
DGA) a rdig un profil pour pare-feu protection leve afin dinterconnecter deux rseaux ayant des politiques de scurit diffrentes. Le
niveau vis est EAL5+.
ST (Security Target)
Le ST contient la description des menaces et des objectifs de scurit
du produit certifier. Il indique comment on veut valuer le produit
et jusquo on veut aller en matire de scurit. Le ST est rdig partir
du PP.
Au final, cest la DCSSI qui valide lagrment et dlivre le certificat.
ITIL: le management des services

Dvelopp par lOGC pour le gouvernement britannique, ITIL (Information
Technology Infrastructure Library) se prsente comme une srie de livres dcrivant les bonnes pratiques pour le management des services TI. Son
approche est davantage oriente sur le quoi faire que sur le comment
faire .
Les principes qui sous-tendent ITIL sont lorientation client, la prise en
compte, en amont de tout projet, des exigences de services et lapproche
processus. ITIL est devenu un standard de fait, au moins pour le primtre
des centres dassistance et des oprations.
Ceci tant, lanne 2007 a marqu une tape assez dcisive, presque un
schisme, puisque au moment mme o lISO se basait sur ITIL V2 pour
publier la norme ISO/IEC 20000, on assistait au lancement dITIL V3. ce
jour, la population des utilisateurs dITIL reflte surtout les dploiements
dITIL V2.
19
ITIL V2 et la norme ISO/IEC 20000

1. ITIL V2 est un rfrentiel trs rpandu,
en DSI comme chez
les infogrants. Il permet de structurer les
processus et lorganisation des oprations
partir des centres de
support (help desks,
services desks). Son
succs est en partie
d au systme dinformation dont il se dote
(gestion des appels,
des problmes, etc.)
et la base de donnes des composants
(CMDB) quil permet
de renseigner.
La structure dITIL V21 fait apparatre sept domaines, dont les deux plus utiliss sont Fourniture des services (Service Delivery) et Soutien des services (Service Support). Ils correspondent la couverture de la certification ISO/IEC 20000.
Le domaine Fourniture des services concerne le moyen terme (planification et amlioration de la fourniture de services) et comprend :
la gestion des niveaux de services ;
la gestion financire ;
la gestion de la capacit ;
la gestion de la continuit de service informatique ;
la gestion de la disponibilit.
Le domaine Soutien des services se focalise sur le quotidien et comprend :
le centre de services (Service Desk) ;
la gestion des incidents ;
la gestion des problmes ;
la gestion des configurations ;
la gestion des changements ;
la gestion des mises en production.
Cette sparation en domaines est trs pratique dans la mesure o elle distingue des ensembles cohrents de processus tout en diffrenciant le quotidien (court terme) du moyen terme. Enfin, il est manifeste que
limplmentation de ces deux domaines constitue la fois une premire
tape pour la gouvernance TI et un minimum en la matire.
La prsentation de la certification ISO/IEC 20000 est lgrement diffrente
dans le regroupement des processus mais reprend lensemble des processus dITIL V2.
Par ailleurs, les cinq domaines couverts par ITIL V2 ne faisant pas lobjet de
certification sont :
Business Perspective, qui concerne les questions dorganisation (organisation
de la production, relations entre les diffrentes rles, fonctions et responsabilits, relations avec les fournisseurs et prestataires externes) ;
Application Management, qui concerne la gestion des relations entre tudes et
exploitation (support applicatif, changement logiciel, mise en production) ;
ICT Infrastructure Management, qui concerne le cycle de vie de linfrastructure (automatisation, maintenance, installation) ;
Security Management, qui concerne le pilotage de la scurit informatique ;
Planning to Implement Service Management, qui concerne la mise en place
dune orientation client au sein de la DSI.
chaque fois, ITIL adopte la mme description des bonnes pratiques
(objectifs, primtre, concepts, bnfices et difficults, mise en place, activits, indicateurs et annexes).
20
Processus de fourniture de services

Gestion de la capacit
Gestion de la continuit et de
la disponibilit du service
Gestion des niveaux de services
Rapport sur le service
Gestion de la scurit de
linformation
Budgtisation et
comptabilisation des
services informatiques
Processus de contrle
Gestion des configurations
Gestion des changements
Processus de mise
en production
Processus de
gestion
des relations
Processus de rsolution
Gestion des incidents
Gestion des mises en

production
Gestion des problmes
Gestion des relations

commerciales
Gestion des fournisseurs
Figure 2-3 : Schma des processus de gestion des services de la norme ISO/IEC 20000-1:2005
ITIL V3
Apparue en 2007, la version V3 du rfrentiel ITIL est base sur cinq livres
principaux prconisant des bonnes pratiques, proposant des complments
par secteur ou par march ainsi que des modles gnriques (cartes de
processus, etc.).
Service Strategy dcrit la stratgie gnrale et lapport de valeur des services.
Il traite de lalignement avec les mtiers et la gouvernance des TI.
Service Design propose des procdures, des architectures et des documents
pour crer les processus de management des services.
Service Transition propose des guides pour intgrer concrtement les
processus de gestion des services entre mtiers et oprations.
Service Operation propose des guides pour raliser les objectifs de qualit
de service dans un souci defficacit et defficience.
Continual Service Improvement propose des guides pour identifier et amliorer les processus. Il combine les mthodes du management de la
qualit et la boucle damlioration PDCA.
ITIL V3 ne donne pas lieu la certification des organisations. Cette nouvelle version met laccent sur la boucle damlioration continue des services offerts aux clients de la DSI. Par rapport la version antrieure, elle
comprend galement une dimension stratgique qui se rapproche de
lalignement stratgique cher CobiT.
21
Le management des tudes

Le CMMI et la norme ISO/IEC 15504
Le rfrentiel CMMI est destin aux entreprises qui cherchent matriser
leur usine de dveloppement de systmes ou de logiciels. En ce sens, le
CMMI sadresse soit aux trs grands comptes ayant un service tudes
important, soit aux grandes socits de services ou intgrateurs. Le CMMI
ne se substitue pas une gestion de projet informatique au sens traditionnel. Au contraire, il sappuie sur les mthodes (management de projet
informatique, valuation des charges et des cots, planification, etc.) sousjacentes aux projets.
En tant que rfrentiel de bonnes pratiques, le CMMI comprend principalement 25 domaines de processus, correspondant un dcoupage de
lenvironnement de dveloppement (gestion des exigences, planification
de projet, validation). Chaque domaine de processus contient des objectifs atteindre, ainsi que la description des pratiques auxquelles il sera fait
appel (planifier les processus, fournir les ressources, assigner les responsabilits, former les personnes).
1. SPICE (Software
Process Improvement
and Capability dEtermination) est le nom
du rfrentiel soustendant la norme
ISO/IEC 15004.
Mentionnons pour mmoire la norme ISO/IEC 15504 (SPICE1) qui permet

de certifier la capacit des organisations produire du logiciel. Elle
sapplique plus aux logiciels industriels ou des systmes, et concerne
rarement la DSI. Cette norme prsente des similarits avec le CMMI
(modle de maturit, par exemple).
Lintgration des diffrents modles CMM

Au fil des annes, la famille CMM (Capabilty Maturity Model) sest agrandie
avec lapparition des lments suivants :
CMM ou SW-CMM (Capability Maturity Model for Software) correspond au
modle original cr en 1991 pour auditer les structures de dveloppement de logiciel. Son succs explique quil soit lorigine de plusieurs
dclinaisons ultrieures ;
SE-CMM (System Engineering), destin au dveloppement des systmes ;
SA-CMM (Software Acquisition), consacr aux mthodes dacquisition des
logiciels ;
P-CMM (People), qui sintresse aux processus de gestion du personnel ;
CMMI amliore et intgre depuis 2000 lensemble des autres modles.
Certaines organisations sont restes SW-CMM mais CMMI est devenu un
standard du fait des grandes entreprises mondiales dont le mtier est de
22
produire des logiciels. Les entreprises indiennes ont jou un rle majeur
dans la gnralisation du standard, en faisant un pralable de qualification
dans les consultations.
Le modle de maturit
Le CMMI sintresse la qualit de lorganisation et la matrise des processus. Il propose une dmarche stricte pour valuer les processus et
dfinir des plans damlioration continue, ce qui constitue dailleurs le
standard des modles de maturit. Son modle de maturit en 5 tages est
devenu une rfrence de description des modles de maturit.
Initial
Procdures et autorit mal dfinies. La russite des projets dpend du
savoir-faire de quelques personnes cls. Aucune ou mauvaise application des principes du gnie logiciel. Difficult matriser les cots et les
dlais.
Reproductible
Utilisation de mthodes standards pour grer les activits de dveloppement. Le dveloppement est planifi et suivi. Lquipe matrise et
applique des rgles. Bonne gestion des cots et des dlais.
Dfini
Utilisation des mthodes du gnie logiciel et application des normes.
Lefficacit de chaque processus est vrifie et les meilleures pratiques
sont mises en avant. Processus bien dfini et raisonnablement compris.
Matris
Collecte et analyse systmatique des donnes sur les processus. Les
processus sont mesurs, les risques calculs et devancs. Processus
bien compris, quantifis, mesurs et raisonnablement matriss.
Optimis
Utilisation des donnes pour lamlioration itrative des processus,
capitalisation de lexprience. Tous les processus sont optimiss et toutes
les volutions sont apprhendes. Matrise des processus.
Deux modles de reprsentation sont proposs selon que lon sintresse
la maturit de chacun des processus ou celle de lorganisation.
Le modle continu (continuous) : moins utilis, il rpond un souci de
mise en avant partielle de certains processus.
Le modle tag (staged) : cest le modle original en cinq niveaux. Il
rpond un souci de progression et damlioration des processus.
Le niveau 1 est le niveau de dpart. Les organisations bien rodes se satisferont des niveaux 2 et 3, ce dernier attestant de processus jugs gnralement suffisamment optimiss et scuriss. Les niveaux 4 et 5 sont lapanage
23
des structures trs ractives, capables de surveiller et damliorer en

permanence leur activit.
Il nexiste pas de certification CMMI au sens de lISO. Il y a cependant des
mthodes qui permettent de situer le niveau de maturit dune entreprise
vis--vis du dploiement du CMMI. La plus complte est SCAMPI (Standard
CMMI Appraisal Method for Process Improvement). Cette mthode est applique
par des auditeurs certifis aptes dlivrer une reconnaissance de niveau
de maturit pour une organisation donne.
Repre : le CMMI
Le dploiement de CMMI est un projet de transformation trs srieux. Il ncessite
la fois une bonne description des processus, un systme dinformation associ, une
vritable conduite du changement et la standardisation des pratiques en termes
de pilotage de projets. On compte au minimum 18 mois pour tre niveau 2, et
18 mois de plus pour passer niveau 3. En France, le nombre dorganisations de
niveau 3 est sans doute infrieur 10 !
Les modles qualit

La norme ISO 9001
LISO 9001 dcrit les exigences pour un systme de management de la qualit en vue dune certification de lorganisme qui le met en uvre ou de
satisfaire une volont de ses clients. Cette norme est un outil de management destin aux organisations afin de matriser la chane client-fournisseur en :
donnant confiance aux clients dans la capacit de lentreprise
matriser tous ses processus impliqus dans la livraison des produits/
services ;
modlisant les organisations selon un rfrentiel commun.
La mise en uvre de lISO 9001 repose sur les principes suivants :
lcoute client ;
le leadership ;
limplication du personnel ;
lapproche processus ;
le management par approche systme ;
lamlioration continue ;
lapproche factuelle pour la prise de dcision ;
les relations mutuellement bnfiques avec les fournisseurs.
24
La certification sappuie une valuation de lorganisation ayant mis en

uvre un systme de management selon un primtre dactivit bien identifi. Lvaluation consiste apprcier si le systme est bien document et
si sa mise en uvre fournit les rsultats attendus par rapport la politique
et aux objectifs fixs par la direction.
Une caractristique importante de lISO 9001 est son caractre gnrique. Ainsi, cette norme ne spcifie aucun processus li un mtier
particulier, et il appartient chaque organisation den dfinir le nombre
et la porte.
Cest dailleurs ce caractre qui a permis sa grande diffusion en permettant
lensemble des acteurs industriels de disposer dun standard commun
applicable quel que soit leur secteur dactivit.
Le modle EFQM
Le modle EFQM, propos par lEuropean Foundation for Quality Management,
est un modle dexcellence destin aux organismes qui dsirent satisfaire
de faon durable toutes les parties prenantes par leurs ralisations et leurs
mthodes.
Le modle EFQM repose sur les principes fondamentaux suivants :
lorientation rsultats ;
lorientation clients ;
le leadership et la constance des objectifs ;
le management par les processus et les faits ;
le dveloppement et limplication des personnes ;
lapprentissage, linnovation et lamlioration ;
le dveloppement des partenariats ;
la responsabilit sociale/socitale de lorganisation.
La mise en uvre de ces principes sappuie sur trois phases de maturit
diffrentes :
la phase Initiation ;
la phase Ralisation ;
la phase Maturit.
Le modle EFQM est une reprsentation non normative dune organisation
selon neuf critres rpartis en deux catgories, moyens et rsultats.
Les critres de moyens concernent la faon dont lorganisation gre ses
activits cls. Ils sont les suivants :
leadership ;
personnel ;
25
politique et stratgie ;
partenariats et ressources ;
processus.
Les critres de rsultats concernent la faon dont les rsultats de lorganisation sont obtenus. Ils sont les suivants :
rsultats pour le personnel ;
rsultats pour les clients ;
rsultats pour la collectivit ;
rsultats performances cls.
Moyens
Rsultats
Rsultats
personnel
Personnel
Leadership
Politique et
stratgie
Processus
Partenariat &
ressources
Rsultats
client
Rsultats
Performance
Cls
Rsultat
collectivit
Innovation et apprentissage
Figure 2-4 : Les critres du modle EFQM
Le modle EFQM a t conu pour fournir une reconnaissance de lexcellence travers un trophe annuel. Il se base sur une valuation des organisations candidates selon les neufs critres. Chaque catgorie de critres
est note sur 500 points. Lorganisation candidate qui a obtenu le plus
grand nombre de points se voit dcerner le trophe.
Le dveloppement durable
Sujet en vogue actuellement, le dveloppement durable est en mme
temps source de confusion. De quoi parle-t-on : du volet social ? du volet
cologique ? et sur quel primtre ? de la DSI pour elle-mme ou pour
lensemble des impacts des SI de lentreprise sur lenvironnement ?
En rgle gnrale, les fournisseurs communiquent sur le volet cologique
(Green IT) pour dmontrer leur engagement dans les conomies dnergie,
lconomie du papier ou le recyclage en gnral. Ils peuvent aussi, comme
SAP, en profiter pour commercialiser un module supplmentaire de lERP
pour aider leur client grer ces aspects.
26
Concernant les DSI, on leur demande parfois de se conformer aux normes

de la srie ISO 14000 qui permettent de piloter lincidence des activits
dune organisation sur lenvironnement. Il est frquent de coupler la
dmarche de certification ISO 14001 avec lensemble des rfrentiels applicables la DSI.
En rsum
Il y a beaucoup de rfrentiels qui concernent la DSI ; ceci met en vidence
la ncessit de trouver un langage commun, de crer une convergence
entre ces diffrentes approches. En effet, mme si chacun dentre eux a sa
raison dtre, il nest pas possible de piloter une DSI sans en unifier le langage et les processus.
Parmi les incontournables, citons surtout : ITIL, ISO 27001/27002 et
ISO 14001, le tout dans une logique damlioration continue au service du
client (ISO 9001).
27
Chapitre 3
Apprhender
CobiT
Le rfrentiel CobiT a suscit toute une srie de travaux et de publications.
Dans les premires versions, V3 et antrieures, la publication principale
tait le guide daudit. partir de la version 4, cest le guide de management
qui est devenu le principal ouvrage descriptif de CobiT.
Dans ce chapitre, CobiT est dcrit en termes de structure gnrale et
dapproche travers plusieurs points de vue : celui du guide de management pour CobiT V4.1, qui constitue le document de base, puis ceux de
diverses ressources. En complment, il est utile de consulter priodiquement le site http://www.isaca.org pour connatre les dernires publications
proposes.
La suite de cet ouvrage a pour vocation de fournir un guide de lecture pour
tous ceux qui souhaitent mettre en uvre CobiT au sein de leur organisation
informatique.
Description gnrale
CobiT offre un cadre de rfrence de contrle structur des activits informatiques selon 34 processus rpartis en quatre domaines :
Planifier et Organiser ;
Acqurir et Implmenter ;
Dlivrer et Supporter ;
Surveiller et valuer.
29
La figure 3-1 prsente les diffrents domaines et processus associs.

Cadre de rfrence gnral de CobiT
Objectifs de la
gouvernance
Objectifs mtier
Information
Surveiller et Evaluer
SE1 Surveiller et valuer la performance
des SI
SE2 Surveiller et valuer le contrle
interne
SE3 Sassurer de la conformit
rglementaire
SE4 Grer la gouvernance des SI
Efficacit
Efficience
Confidentialit
Intgrit
Disponibilit
Conformit
Fiabilit
Ressources
Comptences
Information
Applications
Infrastructure
Planifier et Organiser
PO1 Dfinir un plan informatique
stratgique
PO2 Dfinir larchitecture de linformation
PO3 Dterminer lorientation technologique
PO4 Dfinir lorganisation,
les relations de travail
PO5 Grer linvestissement informatique
PO6 Faire connatre les buts et les
orientations du management
PO7 Grer les ressources humaines
PO8 Grer la qualit
PO9 Evaluer les risques
PO10 Grer les projets
Acqurir et Implmenter
Dlivrer et Supporter
DS1 Dfinir et grer les niveaux de
services
DS2 Grer les services tiers
DS3 Grer la performance et la capacit
DS4 Assurer un service continu
DS5 Assurer la scurit des systmes
DS6 Identifier et imputer les cots
DS7 Instruire et former les utilisateurs
DS8 Grer le service dassistance
client et les incidents
DS9 Grer la configuration
DS10 Grer les problmes
DS11 Grer les donnes
DS12 Grer lenvironnement physique
DS13 Grer lexploitation
AI1
AI2
AI3
AI4
AI5
AI6
AI7
Trouver des solutions informatiques

Acqurir des applications et en
assurer la maintenance
Acqurir une infrastructure technique
et en assurer la maintenance
Faciliter le fonctionnement et
lutilisation
Acqurir des ressources
informatiques
Grer les changements
Installer et valider les solutions et les
modifications
Figure 3-1 : Organisation du rfrentiel CobiT
Les composants de CobiT

Les quatre domaines de CobiT regroupent des ensembles cohrents de
processus. Le domaine PO reprsente la dimension stratgique de la gouvernance des TI. Le domaine AI rassemble tous les processus qui impactent les ressources, de lacquisition limplmentation : on y trouve aussi
bien les projets que la mise en exploitation. Le domaine DS est consacr
aux services offerts aux clients de la DSI. Enfin, le domaine SE couvre largement la dimension de contrle, daudit et de surveillance de lensemble.
Les processus de CobiT

Pour chacun des 34 processus, CobiT en dcrit le primtre et lobjet pour
ensuite lister et dvelopper :
les objectifs de contrle destins aux auditeurs informatiques, qui
sont dtaills dans dautres publications ;
un guide de management inscrit dans une logique de gouvernance des SI ;
un modle de maturit propre chaque processus.
30
Chapitre 3 Apprhender CobiT
Les critres dinformation

Pour la gouvernance des TI, CobiT prend en compte une trs riche
segmentation de linformation selon des critres prcis (efficacit, efficience, confidentialit, intgrit, disponibilit, conformit et fiabilit).
Ces critres correspondent aussi bien au point de vue dun auditeur qu
celui du manager :
efficacit : la mesure par laquelle linformation contribue au rsultat
des processus mtier par rapport aux objectifs fixs ;
efficience : la mesure par laquelle linformation contribue au rsultat
des processus mtier au meilleur cot ;
confidentialit : la mesure par laquelle linformation est protge des
accs non autoriss ;
intgrit : la mesure par laquelle linformation correspond la ralit
de la situation ;
disponibilit : la mesure par laquelle linformation est disponible pour
les destinataires en temps voulu ;
conformit : la mesure par laquelle les processus sont en conformit
avec les lois, les rglements et les contrats ;
fiabilit : la mesure par laquelle linformation de pilotage est pertinente.
Les ressources informatiques

Cette dnomination regroupe les quatre classes suivantes : applications,
informations, infrastructures et personnes.
Application : les systmes automatiss et les procdures pour traiter
linformation.
Infrastructure : les technologies et les installations qui permettent le
traitement des applications.
Information : les donnes, comme entres ou sorties des systmes
dinformation, quelle que soit leur forme.
Personnes : les ressources humaines ncessaires pour organiser, planifier,
acqurir, dlivrer, supporter, surveiller et valuer les systmes dinformation
et les services.
Objectifs mtier et objectifs informatiques

De faon globale, CobiT propose 20 objectifs mtier rpartis selon les
quatre axes dun BSC, savoir : perspective financire, perspective
client, perspective interne la DSI, et perspective future ou anticipation.
31
Ces 20 objectifs mtier renvoient 28 objectifs informatiques, euxmmes lis aux processus CobiT, un mme objectif informatique tant
associ un ou plusieurs processus CobiT. Ainsi, CobiT offre une transitivit entre objectifs mtier et informatiques, processus et activits.
Cette structuration permet dobtenir une sorte de synthse de la gouvernance des SI.
Les processus dans CobiT V4.1

Chaque processus est dcrit sur quatre pages, ce qui correspond
lapproche gnrale, laudit, le management du processus et le modle de
maturit.
Les objectifs de contrle

Les objectifs de contrle sont dcrits en termes dattendus rsultant de la
mise en uvre des processus. Des documents plus dtaills (IT Assurance
Guide: Using CobiT) dclinent la structure de contrle des fins oprationnelles. Il apparat clairement que CobiT est un outil oprationnel pour les
auditeurs qui y trouveront toute la matire ncessaire pour tablir des
questionnaires et des grilles dinvestigation.
Le guide de management
La page consacre au guide de management comprend un descriptif des
entres-sorties du processus, un RACI avec rles et responsabilits associs aux activits du processus, et enfin, une proposition dindicateurs de
contrle.
Les activits
CobiT distingue les objectifs de contrle (vision destine lauditeur) des
activits (vision management). Cette distinction peut surprendre car la
liste des activits reprend certains objectifs de contrle dans ses intituls.
Parfois, ces activits sont directement extraites de la description des
objectifs de contrle. De plus, les activits sont listes mais non dcrites.
Le lecteur doit donc faire leffort de dterminer dans la description des
objectifs de contrle ce qui relve de la description dactivit. Il devrait
dcortiquer chaque objectif de contrle en tentant disoler linformation
attache aux activits, aux instances/organisations, aux fonctions, aux
documents/livrables et enfin au contexte.
Pour la mise en uvre de CobiT, partir des activits est intressant condition
de ne pas sy enfermer. Il vaut mieux prendre cette liste comme un pensebte pour donner du corps une description personnalise en fonction
de lorganisation.
32
Les responsabilits et fonctions dans CobiT (RACI)

CobiT ne distingue pas moins de 19 parties prenantes ou fonctions pour la
gouvernance des systmes dinformation. Chacune delles peut avoir un ou
plusieurs rles pour chaque activit.
On peut ainsi tre responsable ou garant, ou simplement consult ou
inform, selon la situation. Ceci est dcrit dans un tableau crois activits/
fonctions.
CobiT ne propose pas proprement parler une organisation, mais les
objectifs de contrle font parfois rfrence des instances comme le
comit stratgique informatique ou le comit de pilotage informatique
dont les missions sont clairement nonces. L encore, le RACI1 est indicatif. Selon la taille et lorganisation de la DSI, certaines fonctions gnriques peuvent tre plus ou moins structures en postes et emplois. Le
RACI de CobiT est une base affiner au cas par cas.
1. RACI : en anglais
Responsible, Accountable, Consulted,
Informed, traduit par
Responsabilit, Autorit (celui qui est
garant), Consult,
Inform. Lautorit (A)
dicte la politique
qui sera applique
par le responsable (R).
DF
Direction mtier
DSI
Propritaire processus mtier
Responsable exploitation
Responsable architecture
Responsable dveloppements
Responsable administratif
Lier objectifs mtier et objectifs

informatiques.
A/R
Identier les dpendances critiques

et les performances actuelles.
A/R
Construire un plan informatique stratgique.
laborer des plans informatiques tactiques.
Analyser les portefeuilles de

programmes et grer les portefeuilles
de projets et de services.
ACTIVITS
33
Bureau projet
DG
Conformit, audit, risque et scurit
Tableau 3-1 : Exemple de RACI (processus PO1)
Les objectifs et les indicateurs

1. Chacun de ces
objectifs donne lieu
une mesure de performance qui permet de
savoir si lobjectif est
atteint (lag indicator
en anglais), ce qui
constitue en mme
temps le contexte de
lobjectif suivant
(lead indicator).
Ainsi, lobjectif informatique sassurer
que les services informatiques sont capables de rsister des
attaques et den surmonter les effets ,
par exemple, sinscrit
la fois dans un
contexte (lead : le
nombre daccs frauduleux) et savre
mesur par un rsultat (lag : le nombre
dincidents informatiques rels qui ont eu
un impact sur lactivit de lentreprise).
Pour chaque processus, on dtaille les objectifs et les mtriques associes.

Un processus est considr comme pilot lorsque des objectifs lui ont t
assigns et que des indicateurs ont t dfinis pour atteindre les objectifs1.
Nul doute que cette construction garantisse la bonne gouvernance en
reliant ainsi les diffrents indicateurs de lactivit lmentaire au mtier.
Ceci tant, il faut disposer dun vrai systme dinformation de pilotage
pour le mettre en uvre, ce qui correspond au stade ultime de la gouvernance SI. Autant les objectifs de contrle nous semblent trs structurants
et invariants, autant la partie guide de management est considrer
comme un exemple mritant dtre contextualis, complt et personnalis au cas par cas.
Le modle de maturit
CobiT propose un modle de maturit gnrique faisant lobjet dune
dclinaison spcifique pour chacun des 34 processus. Ainsi, la mise en
uvre de chacun des 34 processus peut tre confronte des stades du
modle de maturit selon une chelle classique en la matire (voir figure 3-2).
En se limitant cette description gnrique, on peut donc mesurer de
faon globale la maturit de chaque processus et piloter leur amlioration.
m
Les
Figure 3-2 : Modle de maturit
34
CobiT veut aller plus loin en groupant trois dimensions au modle de maturit, pour chacun des 34 processus. Il propose ainsi les dimensions suivantes :
quoi : contrle (initialis, reproductible, dfini, gr et optimis), stades
de 0 5 ;
combien : couverture en termes de primtre ;
comment : capacit raliser les objectifs.
En tudiant la description du modle de maturit1 par processus, il semble
que chaque stade caractrise un palier de mise en uvre en fonction de
son primtre de dploiement au sein de lentreprise. Il peut ainsi y avoir
confusion entre le primtre spcifique de dploiement dun processus
(dimension combien ) et le stade de maturit gnrique quil a atteint,
au sens du CMM (dimension contrle ).
Pour un mme processus, il est ainsi possible de fixer des objectifs diffrents de progression de la maturit en fonction de ltat de maturit
observ sur plusieurs primtres de sa mise en uvre. Pour un mtier ou
un systme donn, le processus peut tre valu au niveau 2 du modle de
maturit alors que, pour dautres, il peut ltre au niveau 3. Selon les exigences mtier et la criticit de linformatique sur les mtiers de lentreprise, la cible en termes de niveau de maturit peut tre diffrente.
Dans le cas dun primtre dvaluation de la maturit globale selon CobiT
(cest--dire tous les mtiers et tous les systmes), il serait donc rducteur
de dire par exemple quun processus donn est globalement au niveau 2 si,
selon les endroits o il est applicable, il se trouve au niveau 3, 4 ou 1.
Le modle de maturit CobiT est conu pour offrir une grande flexibilit
lvaluateur en fonction de ses objectifs et des besoins damlioration. Il est
adapt lactivit daudit du ou des processus considrs plutt qu une
activit de mise en uvre dune dmarche CobiT globale dans lentreprise.
En effet, il ny a aucune recommandation ni orientation quant la priorit
ou lordre de mise en uvre des processus. Les 34 processus du rfrentiel
CobiT ne sont pas prsents pour se loger dans un modle de maturit
tag avec une logique de mise en place progressive comme dans CMMI.
En revanche, un ordre de mise en place des processus CobiT peut tre
envisag mais, dans ce cas, il sera toujours spcifique chaque entreprise
en fonction de ses exigences mtier et de ses objectifs informatiques. Cest
dailleurs partir dune valuation initiale des 34 processus CobiT et selon
les exigences mtier quil sera possible de dfinir un plan de mise en place.
Ce plan spcifiera, processus par processus, les diffrents niveaux de
maturit atteindre en fonction des mtiers et de la criticit des systmes
informatiques associs. Nous navons donc pas repris, dans la suite de la
prsentation des processus, les lments spcifiques des modles de
maturit de CobiT.
35
1. Il y a au moins une
centaine de modles
de maturit dont un
bon nombre servent
des rfrentiels utiliss en DSI. Le prcurseur est celui du SEI
(Software Engineering Institute) qui a
donn le CMM (Capability Maturity
Model), conu pour
valuer la maturit
des organisations en
charge du dveloppement de logiciel. En
gnral, un modle
de maturit a cinq
niveaux : inexistant,
intuitif, dni, gr et
mesurable, optimis.
Les documents et publications autour de CobiT

Il existe de trs nombreux travaux de recherche et publications autour de
CobiT. Certains sont particulirement importants pour complter le rfrentiel.
CobiT est organis en trois niveaux pour appuyer la direction et la fonction
conseil, les mtiers et le management des SI ainsi que la gouvernance, la
scurit et le contrle.
Board briefings
Comment les
dcideurs exercent-ils
leurs responsabilits?
Organes dcisionnels
Comment pouvons- nous mesurer
la performance?
Comment faire pour se comparer
aux autres?
Comment samliorer durablement?
Management Guidelines
Modles de maturit
Gestion de lactivit et des technologies

Quelle est la
structure de la
gouvernance
des SI?
Comment mettre
en uvre la
gouvernance dans
lentreprise?
Comment valuer
la structure de la
gouvernance des
SI?
Gouvernance, scurisation et contrle
COBIT et VAL IT
Control objectives
Implementation
Guide
Assurance Guide
Control practices
Implementation
Guide
Security Baseline
Key management
practices
Control Practices
COBIT Online
COBIT Foundation
training
COBIT implementation workshop
Figure 3-3 : Documents lis CobiT
La figure 3-3 distingue les diffrentes publications lies CobiT selon

quelles concernent :
les guides de management ;
les objectifs de contrle ;
les modles de maturit ;
lorganisation.
36
destination de la direction
Board Briefing on IT Governance, 2nd edition, IT Governance Institute, 2003
(http://www.isaca.org/ContentManagement/Content-Display.cfm?ContentID=39649). Pour plus de dtails, voir page 43.
Information Security Governance: Guidance for Boards of Directors and Executive
Management, 2nd edition, IT Governance Institute, 2006 (http://
www.isaca.org/AMTemplate.cfm?Section=Information_Security_
Governance_Guidance_for_Boards_of_Directors_and_Executive_Manag
ement&Template=/ContentManagement/ContentDisplay.cfm&ContentFileID=10227).
La srie Enterprise Value: Governance of IT Investments (VAL IT), IT Governance
Institute, comprenant trois publications :
The VAL IT Framework 2.0 ;
The Business Case, 2006 (http://www.isaca.org/AMTemplate.cfm?Section=
Deliverables&Template=/ContentManagement/ContentDisplay.cfm&
ContentID=24261) ;
Getting Started With Value Management (http://www.isaca.org/Template.cfm?Section=COBIT6&template=/ContentManagement/ContentDisplay.cfm&ContentID=25060).
destination des mtiers

Management Guidelines, 3rd edition, IT Governance Institute, 2000.
destination de la gouvernance TI, du contrle et de la scurit

Framework, The IT Governance Institute.
Control Objectives, IT Governance Institute, 2000.
CobiT Control Practices: Guidance to Achieve Control Objectives for Successful IT
Governance, 2nd edition, IT Governance Institute, 2007. Pour plus de dtails,
voir page 38.
The IT Assurance Guide: Using CobiT, IT Governance Institute. Pour plus de
dtails, voir page 39.
IT Assurance Framework (ITAF), IT Governance Institute, 2008. Pour plus de
dtails, voir page 39.
IT Control Objectives for Sarbanes-Oxley, 2nd edition, IT Governance Institute,
2006. Pour plus de dtails, voir page 40.
IT Control Objectives for Basel II: The Importance of Governance and Risk Management for Compliance, IT Governance Institute, 2007. Pour plus de dtails,
voir page 40.
37
IT Governance Implementation Guide: Using CobiT and VAL IT, 2nd edition, IT
Governance Institute, 2007. Pour plus de dtails, voir page 41.
Le site de CobiT Online. Pour plus de dtails, voir page 41.
CobiT Security Baseline: An Information Security Survival Kit, 2nd edition, IT
Governance Institute, 2007. Pour plus de dtails, voir page 42.
CobiT Quickstart, 2nd edition, IT Governance Institute, 2007.
CobiT Mapping, IT Governance Institute.
Les cours de formation : CobiT Foundation Course and Exam. Pour plus
de dtails, voir page 43.
Autres publications
IT Alignment: Who Is in Charge?, IT Governance Institute, 2005 (http://
www.itgi.org/AMTemplate.cfm?Section=Deliverables&Template=/
ContentManagement/ContentDisplay.cfm&ContentID=33921).
Optimizing Value Creation from IT Investments, IT Governance Institute, 2005.
Information Risks: Whose Business Are They?, IT Governance Institute, 2005
(http://www.itgi.org/AMTemplate.cfm?Section=Deliverables&Template=/ContentManagement/ContentDisplay.cfm&ContentID=33919).
Governance of Outsourcing, IT Governance Institute.
Measuring and Demonstrating the Value of IT, IT Governance Institute.
CobiT est une structure vivante et volutive, plusieurs projets sont
dailleurs en cours de dveloppement. Les informations sy rfrant sont
disponibles sur le site de lISACA.
Toutes les publications rfrences ci-dessus sont disponibles en tlchargement sur le site de lISACA (http://www.isaca.org) et sur celui de lITGI
(http://www.itgi.org).
Description dtaille de certaines publications

CobiT Control Practices: Guidance to Achieve Control Objectives for
Successful IT Governance, 2nd edition
Les pratiques de contrle prsentes dans cet ouvrage tendent le champ
dintervention de CobiT, en y ajoutant un niveau de dtail supplmentaire
bas sur les bonnes pratiques.
Lensemble des processus informatiques, tout comme les exigences lies
aux informations stratgiques et les objectifs de contrle dtaills, dfinissent ce quil est ncessaire de faire pour implmenter un contrle de la
structure efficient, tout en matrisant les risques, et ce, afin de rcolter les
gains induits par cette implmentation.
Les pratiques de contrle fournissent davantage de dtails quant la finalit de cette implmentation, afin dclairer et de rpondre aux besoins du
38
management, des mtiers, des utilisateurs, et enfin des parties prenantes.

Ces pratiques permettent donc de justifier limplmentation et de mettre
en uvre des contrles spcifiques.
Les ouvrages IT Assurance Guide: Using CobiT et IT Governance Implementation Guide:
CobiT and VAL IT, 2nd edition se rfrent galement aux pratiques de contrle.
IT Assurance Guide: Using CobiT

Louvrage IT Assurance Guide: Using CobiT est une mise jour de The Audit Guidelines. Ce livre utilise le terme dassurance , plus large que celui
daudit car il englobe lvaluation dactivits non gouvernes par un
audit standard interne ou externe, pour dsigner la gouvernance.
Ce guide permet de passer en revue les diffrents processus informatiques
ainsi que les objectifs de contrle dtaills leur tant destins, afin de
rguler et doptimiser le management des systmes dinformation, tout en
amliorant leur performance.
Il inclut galement un guide permettant dexpliquer comment employer
CobiT afin de mettre en uvre la gouvernance de lensemble des activits
informatiques, et de dfinir le champ dapplication de la gouvernance et
ceux des objectifs de contrle.
Lutilisation de ce guide permet aux auditeurs dappuyer leurs conclusions,
dans la mesure o CobiT est bas sur des critres officiels issus de normes
et de documents de bonnes pratiques publis par des organismes de normalisation publics (ISO, CEN) ou privs (diverses associations professionnelles nationales et internationales).
IT Assurance Framework (ITAF)

Le livre IT Assurance Framework (ITAF) fournit une aide pour la conception, la
mise en uvre des missions de gouvernance et la rdaction de rapports
daudit des SI. Il dfinit galement les termes et les concepts spcifiques
de la gouvernance des SI, ainsi que les standards en matire de dfinition
des rles et des responsabilits des professionnels de la gouvernance. Par
ailleurs, il rfrence les comptences requises et les procdures suivre,
notamment en matire datteinte et de contrle des objectifs.
LITAF dfinit trois catgories de standards :
les standards gnraux ;
les standards lis la performance ;
les standards relatifs au reporting.
LITAF nest pas un document uniquement rserv aux professionnels de la
gouvernance. Il permet aussi daider lISACA dans laccomplissement de sa
mission : le conseil aux professionnels de la gouvernance des SI.
39
IT Control Objectives for Sarbanes-Oxley, 2nd edition

Cette seconde dition, acheve en avril 2006, est parue lautomne 2006.
Des vnements tels que les affaires Enron ou Worldcom ont donn naissance une nouvelle re de lhistoire du secteur financier, caractrise par
une plus grande responsabilisation des entreprises.
La loi Sarbanes-Oxley (2002) fut dailleurs cre afin de restaurer la confiance
des investisseurs dans le march public amricain, affect par les scandales
financiers et la dfaillance des entreprises en matire de gouvernance.
Malgr toute la communication ralise autour de cette loi, une relativement faible attention fut porte sur le rle des SI dans les processus aboutissant la production de rapports financiers. Cest dautant plus dsolant
au regard des exigences et de lopportunit que constituent ces rapports
pour la plupart des entreprises, troitement dpendantes de la bonne gouvernance de lenvironnement des SI.
De nombreux professionnels des SI sont tenus pour responsables de la
qualit et de lintgrit des informations produites, surtout lorsque cellesci ne rpondent pas aux objectifs du contrle interne comme des
exigences prconises par la loi Sarbanes-Oxley. Ds lors, des objectifs
de contrle peuvent tre dfinis, permettant de rduire les risques lis
linformation.
En coopration avec les contributeurs, lITGI a rdig le livre IT Control
Objectives for Sarbanes-Oxley, 2nd edition. Ce dernier fait office de rfrence pour
les dcideurs et les professionnels du contrle des SI, ainsi que pour les
professionnels de la gestion et de la gouvernance des SI, lorsque la loi
Sarbanes-Oxley est applicable.
IT Control Objectives for Basel II: The Importance of Governance and

Risk Management for Compliance
Louvrage IT Control Objectives for Basel II: The Importance of Governance and Risk
Management for Compliance fournit un cadre pour la gestion des risques lis
linformation dans le contexte de Ble 2. Ce document sadresse deux
entits distinctes : les membres de la DSI et les experts du service financier. Grce la structure prsente dans cette publication, les services
financiers sont capables dappliquer les exigences prconises en matire
de processus et de contrler les informations relatives aux technologies.
Cet ouvrage traduit le rle des SI en tenant compte des risques oprationnels lis, et la finalit des actions pour les membres de la DSI, les auditeurs internes, les responsables de la gestion des risques et de la scurit
de linformation.
40
IT Governance Implementation Guide: CobiT and VAL IT, 2nd edition

Lobjectif de ce guide est de fournir aux lecteurs une mthodologie pour
implmenter ou amliorer la gouvernance en utilisant CobiT ou VAL IT. Il
apporte ainsi une aide au lecteur ds lors que sa fonction concerne la gestion, la conformit, les risques, la qualit, la performance, la scurit ou
encore la gouvernance du SI.
Ce guide dlivre un plan permettant de mettre en uvre la gouvernance
du SI grce CobiT et VAL IT en 15 tapes. Il couvre les cinq domaines
suivants.
Identifier les besoins : tre attentif, obtenir lengagement (soutien)
des dcideurs, dfinir le champ dapplication, identifier les risques
ainsi que les ressources et les lments fournir, et prvoir un plan
daction.
Prvoir une solution : valuer les performances actuelles, identifier les
zones damlioration possibles et analyser les incohrences.
Planifier : dfinir les projets et mettre en place un plan damlioration.
Implmenter la solution : mettre en uvre les amliorations et les plans
visant accrotre la performance, et revoir lefficacit des programmes.
Rendre la solution oprationnelle : mettre en place une solution durable
et identifier les nouvelles exigences en matire de gouvernance.
La premire recommandation de VAL IT est lalignement la stratgie
dentreprise, notamment au travers de trois aspects :
La gouvernance : dfinir le champ dapplication de la gouvernance et
tablir un contrle de la structure de faon aboutir un alignement
clair et cohrent entre la stratgie dentreprise et le SI, en tenant compte
des programmes dinvestissement dcoulant de la stratgie.
La gestion du portefeuille : grer lensemble du portefeuille afin de
dgager de la valeur pour lentreprise.
Les investissements : contrler et mesurer les rsultats de chaque programme dinvestissement concernant les mtiers, les processus, les
individus, la technologie et les changements organisationnels engendrs
par lactivit de lentreprise et les projets informatiques.
CobiT Online
CobiT Online est un service Web auquel tout le monde peut accder, ds
lors que lon est membre de lISACA et inscrit au service. En utilisant la
personnalisation du site ISACA My CobiT, on peut construire et tlcharger
sa version de CobiT.
41
Pour un utilisateur de CobiT, CobiT Online offre un accs facile et rapide

lensemble des ressources CobiT, telles que les meilleures pratiques, la
mise en uvre du benchmarking, etc.
voluant en fonction des retours dexprience des utilisateurs, CobiT Online
est rgulirement mis jour.
CobiT Security Baseline: An Information Security Survival Kit,

2nd edition
Ce guide, bas sur CobiT 4.1, offre une vue densemble des ressources
ncessaires lorganisation pour mettre en uvre une gouvernance des SI
et un contrle de sa structure. CobiT tend la scurit un primtre
englobant les mtiers.
Cet ouvrage met laccent sur les risques spcifiques lis la scurisation
du SI. Ds lors, la mise en uvre de la scurisation des SI est facilite,
quelle que soit la taille de lorganisation laquelle elle est applique. Il fournit
les lments suivants :
une introduction la scurisation des informations, ce quelle signifie et
les domaines quelle englobe ;
une explication sur limportance de la scurisation et des exemples de
situations frquemment rencontres pouvant gnrer des risques ;
des lments permettant un clairage en matire de dfinition des risques ;
des points de contrle ;
en complment de la configuration de CobiT 4.1, une configuration
mise jour selon la norme ISO/IEC 17799:2005 dfinissant les standards en matire de scurit des informations (prsents dans les normes
ISO/IEC 27001:2007 et ISO/IEC 27002:2007) ;
un kit de survie de la scurit de linformation, fournissant les informations destination :
des utilisateurs particuliers ;
des utilisateurs professionnels ;
des managers ;
des dcideurs ;
des grands dcideurs ;
du comit de direction ;
une annexe contenant un rsum de la scurit relative aux risques
techniques.
42
CobiT Foundation Course and Exam

Les formations1 CobiT aident les professionnels faciliter lapplication des
recommandations fournies par CobiT au sein de leur organisation.
Les comptences CobiT nouvellement acquises permettent daider les organisations et les mtiers dans lalignement stratgique des processus, afin de
permettre aux SI dtre une source de cration de valeur pour lensemble
de lentreprise.
Avec ladoption croissante de CobiT, lISACA reconnat le besoin de structuration et dapprentissage, mais aussi celui de travailler de manire conjointe
avec les Itpreneurs afin de dvelopper une formation cible et pertinente.
Les formations proposes sont les suivantes :
CobiT Awareness Course (2 heures) ;
CobiT Foundation Course (8 heures) ;
CobiT Foundation Exam (1 heure) ;
IT Governance Implementation Course (14 heures) ;
CobiT for Sarbanes-Oxley Compliance (5 heures).
Ces cours de formation sont disponibles ladresse :
http://cobitcampus3.isaca.org/isaca/Catalog/index.aspx.
Board Brieng on IT Governance, 2nd edition
Cet ouvrage sadresse aux comits de direction, aux conseils de surveillance,
aux comits daudit, aux PDG, aux directeurs des SI ainsi qu tous les autres
dcideurs. Il est galement bas sur CobiT et explique en quoi la gouvernance des SI est primordiale, quelle est sa finalit, et fournit des conseils
pour sa mise en uvre. Ce document est compos :
dun rsum du contexte propre la gouvernance ;
dune description de ltendue de la gouvernance ;
de bonnes pratiques et de facteurs de succs ;
de conseils pour mesurer la performance ;
de modles de maturit accompagns du moyen dvaluer lorganisation.
Comment aborder CobiT?

Pour chacun des 34 processus, CobiT offre deux angles dapproche trs complmentaires. Le premier propose une approche des processus par les
objectifs de contrle, trs adapte au monde de laudit, le second propose
un guide de management des processus mais ne fournit aucune indication
sur la faon de le mettre en place et de lanimer. Il appartient chaque entreprise de faire son march dans lensemble des composants de CobiT.
Avant daborder CobiT, il faut comprendre son apport sans entrer dans un
projet de dploiement complet et trop ambitieux. La prsentation qui en
43
1. Pour plus de dtails

sur ces formations,
rendez-vous sur le site
Internet de lISACA,
la rubrique CobiT
Campus : http://
cobitcampus3.is
aca.org/isaca/
Catalog/
index.aspx.
est faite ici se focalise sur une vision dynamique de chaque processus en vue
de les implanter dans une organisation. Dans les chapitres qui vont suivre,
nous dcrirons, pour chaque processus, une vue densemble du processus
selon un triptyque (exigences mtier vis--vis du SI, domaines de gouvernance et ressources informatiques). Une vision dynamique du processus
sera ensuite expose sur la base dun parti pris en ce qui concerne les
activits incontournables du processus en se basant sur une analyse des
objectifs de contrle et des RACI existant dans CobiT. Enfin, des commentaires sur les conditions de mise en uvre et de mesure des processus
seront proposs aprs la description des processus.
Ainsi, les chapitres suivants sadressent ceux qui souhaitent disposer dune
roadmap (feuille de route) pour lancer une dmarche de mise en uvre de
CobiT au sein de leur entreprise. Ils ont pour but de leur donner les cls de
lecture de CobiT afin de les aider implmenter les processus.
qui sadresse CobiT ?

CobiT pour lauditeur informatique
Les premires versions de CobiT ont t dveloppes pour les auditeurs
informatiques, dans la droite ligne des travaux mens par lISACA et avec
le souci daccompagner au mieux la profession des auditeurs des systmes
dinformation.
Le cube CobiT
EXIGENCES MET IER
TE
E
EI TEE
E
LI
E
IT
TE
ITTE
NEC
LITI LIT
TI A
RITI E
AI TCE
TE
E
C
I
IA I BIL
N
C
MI
RM
LITE
E
IICEN
EGGR E NTONNIB
FAI C
D
F
BIILI
T
I
F
OR
E
FFO
FIC
PO
F
NT
IAAB
E IC
D
N
I
E
S
I
P
F
I
F
N
N
N
I
F
I
O
F
NFDDIS
CO
EF
CO
EF
CO
PERSONNES
INFRAST RUCTURE
INFO RMATI ON
Process us
APPLI CATI ONS
PROCESS US INFO RMATIQUES
Domaine s
Activ its et objec tifs
ES
RC
OU
SS
E
R
Figure 3-4 : Le cube CobiT
44
IQ
AT
RM
FO
IN
S
UE
Notons dailleurs que lISACA a depuis plus de 10 ans lanc une certification mondiale des auditeurs de systme dinformation (CISA, Certified Information Systems Auditor).
La structuration et la compltude des objectifs de contrle fait de CobiT le
cadre de rfrence idal pour toute forme dinvestigation.
Le cube CobiT (figure 3-4) illustre lorganisation du rfrentiel autour de
trois dimensions : processus (et activits), segmentation de linformation
et ressource concerne.
CobiT pour le dialogue entre parties prenantes

Selon une tude diligente par le CIGREF (Club informatique des grandes
entreprises franaises), lun des facteurs cls de succs de la gouvernance
passerait par la qualit de la relation entre le DSI et le DG. Dans lapproche
CobiT, ce facteur de succs serait plutt le signe que la gouvernance est
reste un niveau intuitif . Le passage un niveau plus optimis
permettrait de substituer la personnalisation de cette relation une srie
de processus matriss et optimiss.
Les processus1 de CobiT peuvent paratre trop globaux un chef de projet
informatique, par exemple, mais la granularit choisie rsulte dun compromis entre la couverture de lensemble du domaine TI et la comprhension par toutes les parties prenantes des objectifs de chaque processus.
Que ce soit la direction gnrale, les mtiers, les auditeurs internes ou
externes, les services de support aux mtiers (DAF, DRH, Risk Management, etc.), voire les actionnaires, tout le monde peut communiquer
autour de ce cadre de rfrence. Cest donc avant tout un langage commun,
non technique, qui prfigure la ncessit dinstaurer un dialogue entre les
parties.
Cest ainsi que la DSI utilise frquemment CobiT comme outil dautovaluation. En effet, il reprsente un moyen pour elle de dmontrer sa
hirarchie, et ce de faon proactive, que son niveau de matrise des systmes dinformation est satisfaisant sur tous les aspects relevant de sa
responsabilit. Et les auditeurs peuvent valider la qualit de lvaluation
laide du mme outil. Cette approche peut permettre de justifier limportance de mener des projets damlioration, voire de dbloquer des budgets !
CobiT pour le pilotage des systmes dinformation
Dans la mise en uvre de CobiT, il est conseill de mener des actions de
conduite du changement qui regrouperont les acteurs concerns par un
mme processus, lintrieur comme lextrieur de la DSI. Cette
dmarche a pour effet de prciser la fois les activits critiques et les responsabilits associes.
Ceci a le mrite disoler ce qui ressort strictement du primtre de la DSI
un moment donn (la performance oprationnelle), de ce qui relve des
45
1. Le dcoupage en
34 processus rpartis
en 4 domaines donne
une vision synthtique de la gouvernance TI. En
revanche, certains
processus peuvent
tre jugs comme
trop globaux, un peu
comme des macroprocessus. La description
dtaille des activits
et des objectifs de
contrle donne un
niveau de granularit intermdiaire.
conditions de fourniture des services (niveau de service, consommation

des services) ou de linvestissement. Le management y trouve une transparence qui permet de dpolitiser le dbat autour de la valeur ajoute des
systmes dinformation. Tout ceci engendre un climat favorable aux
bonnes prises de dcision visant accrotre lefficience, optimiser les investissements et clairer les choix, pour le plus grand bnfice de lentreprise.
partir du standard CobiT, lentreprise peut btir son rfrentiel pour mettre
sur pied un modle de gouvernance des systmes dinformation.
Les limites : ce que CobiT nest pas

Mme si CobiT est lorigine un rfrentiel issu du monde du contrle
interne, il na pas pour vocation de servir de rfrentiel de certification
selon une approche de conformit des exigences rglementaires ou
contractuelles comme lISO 9001, ou dvaluation de processus comme
lapproche CMMI. En revanche, les objectifs de contrle de CobiT sont
largement utiliss pour rpondre des exigences de certification ou de
contrle interne comme SOX, Ble II.
CobiT ne propose pas de modle de maturit tag pour une valuation de
la direction des systmes dinformation. Ainsi, aucun ordre de priorit de
mise en uvre des processus nest propos.
CobiT ne propose pas une organisation spcifique lie la gouvernance
des systmes dinformation dune entreprise comme le proposent les
normes de systme de management pour la filire qualit.
CobiT ne propose pas non plus un enchanement des activits propres
modliser les processus de matrise des SI de lentreprise comme cest le
cas avec ITIL pour la fourniture et le soutien des services.
CobiT ne va pas rgler la question de la bonne communication entre la DSI
et les parties prenantes.
Enfin, CobiT nest pas un outil de conduite du changement miraculeux qui
diffuserait une culture de la mesure de la performance et de lamlioration.
En revanche, son dploiement peut aider le management mener une
action de changement simultanment.
En rsum
CobiT est un outil fdrateur qui permet dinstaurer un langage commun
pour parler de la gouvernance des systmes dinformation, tout en intgrant les apports dautres rfrentiels ou, de faon plus gnrale, les spcificits de lentreprise.
46
Il prsente lavantage davoir t conu pour une approche globale et, pour
le pilotage, linconvnient dtre issu de laudit, ce qui fait que son volet
guide de management est mconnu.
Son implmentation suppose un accompagnement tenace en termes de
conduite du changement et une approche raisonnable sur le primtre
couvrir en premier lieu.
47
II
PARTIE
Description dtaille
des processus
CobiT est largement dcrit dans la documentation publie par lISACA et
traduite pour partie en franais par lAFAI. Les quatre chapitres qui suivent
dcrivent ses 34 processus, regroups par domaines (PO, AI, DS et SE), afin
que le lecteur ait une vue densemble de chacun mais aussi du cadre
global. Les forces et faiblesses du rfrentiel sont mises en exergue : ainsi,
le modle de maturit na pas t repris car il semble trop complexe et
imprcis mettre en uvre. Il ne sagit pas non plus de laisser croire que
le dploiement de CobiT partirait dun modle unique et immuable pour
toutes les DSI. Limportant est dabord de comprendre et de se persuader
des avantages de CobiT pour structurer lensemble de ses processus.
La description de chaque processus suit un plan dtaill : vue densemble, sa
raison dtre, objectifs et primtre, reprsentation schmatique, planification
et mise en uvre, mesures et contrles, rles et responsabilits, entres et
sorties du processus. La reprsentation schmatique du processus tente en
particulier une mise en perspective de ses activits dans une boucle damlioration (dfinir, mettre en uvre, amliorer, contrler).
Le guide de management pour CobiT V4.1 publi par lAFAI constitue un
excellent document complmentaire la description qui suit.
49
Chapitre 4
Planifier
et Organiser
Les processus dcrits dans ce chapitre traitent de la stratgie et de la tactique permettant doptimiser la contribution des SI latteinte des objectifs
mtier de lentreprise.
Les processus de ce domaine sont les suivants :
PO1 Dfinir un plan informatique stratgique
PO4 Dfinir les processus, lorganisation et les relations de travail
PO5 Grer les investissements informatiques
PO6 Faire connatre les buts et les orientations du management
PO7 Grer les ressources humaines de linformatique
PO8 Grer la qualit
PO9 valuer et grer les risques
PO1
Dfinir un plan informatique stratgique
La place tenue par les systmes dinformation au sein de lentreprise prend

une dimension de plus en plus stratgique. Lobjectif de cration de valeur
et la volont de contribuer efficacement au dveloppement et la performance de lentreprise sont aujourdhui au cur des proccupations des
directions des systmes dinformation.
Cette contribution nest rendue possible que si linformatique adopte des
choix dinvestissement sinscrivant dans une dmarche de transparence, planifie et en cohrence avec les objectifs mtier sur les long et moyen termes.
Cette dmarche aboutit la dfinition dun plan informatique stratgique.
51
Partie II Description dtaille des processus
La planification stratgique informatique est ncessairement relie larchitecture dentreprise et son processus de planification globale. Elle joue un
rle essentiel pour contrler et diriger toutes les ressources informatiques,
en conformit avec la stratgie commerciale et les priorits de lentreprise.
Vue densemble
Le processus PO1 rsulte principalement dune volont de mettre en place une
stratgie des systmes dinformation performante (alignement stratgique)
qui rponde au critre defficacit du systme dinformation pour les mtiers.
Cette volont conduit les DSI sinvestir davantage dans la stratgie globale en simpliquant dans la connaissance des mtiers et le contexte de
lentreprise, tout en matrisant le risque informatique, pour dfinir un plan
informatique stratgique. Cela permet de matriser le potentiel du systme
dinformation actuel et danticiper lvolution de toutes les ressources informatiques selon le critre defficience.
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPORT DE
VALEUR
CONFIDENTIALITE
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
APPLICATIONS
INFORMATIONS
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 4-1 : Dnir un plan informatique stratgique : PO1
Pourquoi ?
Le plan informatique stratgique amne le DSI mieux piloter son budget et
avoir une vision des investissements long et moyen termes. Concrtement, il
se dcline en plans informatiques tactiques, ou schmas directeurs SI, indiquant des objectifs concis court terme ainsi quen plans daction et de tches
compris et accepts par les mtiers et linformatique. Il en ressort des portefeuilles de projets et des offres de services traduisant les besoins mtier.
Lobjectif avou est aussi de rendre cohrentes et transparentes les dpenses
des projets, en communiquant et en impliquant les parties prenantes fonctionnelles informatiques et les mtiers.
52
Chapitre 4 Planifier et Organiser
Le plan informatique stratgique cre une dynamique de communication.

Il fait ainsi apparatre lensemble des parties prenantes les opportunits
et les limites de linformatique, value la performance actuelle, identifie
les besoins en termes de capacit matrielle et de ressources humaines et
met au clair le niveau dinvestissement exig.
Objectifs et primtre
Vis--vis des 28 objectifs globaux assigns au systme dinformation (voir
annexe 2, Objectifs du systme dinformation et processus CobiT ), le
processus PO1 doit permettre de matriser les objectifs prsents dans le
tableau 4-1.
Tableau 4-1 : Objectifs du processus PO1
Obj. 01
Ragir aux exigences mtier en accord avec la stratgie mtier.
Obj. 02
Ragir aux exigences de la gouvernance en accord avec les orientations du CA.
Le processus de planification stratgique informatique dpend en grande

partie des orientations stratgiques et commerciales de lentreprise. Son
primtre englobe lensemble des investissements informatiques de
lentreprise et les actifs associs.
Description du processus
La figure 4-2 reprsente les flux internes du processus PO1.

DEFINIR
ANALYSER LENVIRONNEMENT DE LA DSI
Stratgies mtier
Performance
des TI
Portefeuilles de
programmes
AMELIORER
LIER LES OBJECTIFS METIER ET LES OBJECTIFS INFORMATIQUES
AGIR SUR LES ECARTS
DE FAON APPROPRIEE
IDENTIFIER LES DEPENDANCES ENTRE LINFORMATIQUE
ET LA STRATEGIE DE LENTREPRISE
Plan
stratgique
COMMUNIQUER
DEFINIR LE PLAN INFORMATIQUE STRATEGIQUE
Plans
tactiques
DEFINIR LES PLANS INFORMATIQUES TACTIQUES
FAIRE VALIDER
LES PLANS
ET LES PORTEFEUILLES
CONTROLER
SURVEILLER LES RESULTATS
ATTENDUS DES PROGRAMMES
ALERTER EN CAS DECART
METTRE EN UVRE
GERER LES PLANS TACTIQUES
Portefeuilles
de projets, de
services et
dinvestissements
GERER LES PORTEFEUILLES DE PROJETS ET DE SERVICES

GERER LE PORTEFEUILLE DINVESTISSEMENTS INFORMATIQUES
Figure 4-2 : Reprsentation schmatique des ux internes du processus PO1
53
Planication et mise en uvre

La mise en place dun processus dalignement stratgique ou de dfinition
dun plan informatique stratgique repose sur une connaissance des
mtiers de lentreprise ainsi que des capacits et de la performance relle
des ressources informatiques disponibles. Mais au-del de ce savoir,
limplication des mtiers et de la direction de lentreprise sont indispensables pour valider les orientations futures.
Cette approche prsente lavantage dtablir un dialogue afin de faire
prendre conscience aux mtiers de la valeur de linformatique dans le but
de mieux arbitrer lattribution des budgets de fonctionnement et dinvestissement.
Selon la taille de lentreprise, ce processus devra assurer la dclinaison de
ce plan stratgique par la mise en place de programmes dinvestissement
qui pourront tre leur tour dclins en portefeuilles de projets informatiques et de services.
Mesures et contrles
Les mtriques mettre en place pour sassurer de lefficacit du processus
concernent la vrification des objectifs Obj. 01 et Obj. 02 prsents plus
haut. Ces mesures portent principalement sur la couverture par le plan
stratgique des besoins mtier.
La mesure de la mise en uvre de ce processus passe surtout par le suivi
des volutions des plans SI (stratgiques et tactiques) par rapport aux
plans quivalents de lentreprise et au taux de participation des mtiers
la gestion des programmes dinvestissement.
Rles et responsabilits
Le directeur gnral
Compte tenu de la finalit de ce processus, le responsable de ce processus,
son propritaire ou encore son pilote est trs logiquement la direction de
lentreprise, par lentremise dun de ses directeurs gnraux. Seule la direction gnrale peut se porter garante de lalignement stratgique de la DSI
aux objectifs de lentreprise.
Le responsable mtier
Au sein de ce processus, chaque mtier a la responsabilit de sassurer que
ses objectifs mtier sont bien pris en compte et relis des objectifs informatiques afin que la contribution de linformatique au mtier soit concrtise.
54
Le directeur des systmes dinformation (DSI)

Son rle est de sassurer, en sappuyant sur ses adjoints, que la dclinaison
du plan stratgique SI est bien ralise et que lensemble des ressources
informatiques sera en mesure de fournir le service adquat selon les budgets
dfinis.
Les entres-sorties du processus

PO2, PO 3, PO 4, PO5,
PO6, PO 8, PO 10, AI1,
AI5, AI6, DS1, DS2
PO 5, PO9, PO10, DS1,

SE 1, SE 4
Rapport dvaluation des risques

Rapport cots/bnfices
Portefeuille actualis de
projets
Besoins de services
nouveaux
Portefeuille actualis de
services
Portefeuille de
programmes
Entre de la performance
dans le planning SI
Rapport dtat de la
situation de la
gouvernance SI
Orientation stratgique de
lentreprise pour les SI
PO 1 : Dfinir un plan
stratgique
Plan informatique
stratgique
Plan informatique tactique
Portefeuille de pr ojets
Portefeuille de services
Str atgie dachats et de
four niture
Figure 4-3 : Les entres-sorties du processus PO1
PO2
Dfinir larchitecture de linformation
Parmi les actifs de lentreprise, linformation prend une place croissante aussi
bien pour la bonne marche des processus mtier que pour laide la dcision.
Des drives et des dysfonctionnements au niveau des systmes dinformation se rpercutant sur la bonne marche de lentreprise sont craindre si
la DSI ne garantit pas la qualit de linformation quelle met disposition
des activits mtier et si elle ne met pas en place les ressources et les
outils pour la contrler.
Cette matrise au sein dune DSI est conditionne par la connaissance de
son patrimoine applicatif et la source, par la connaissance de la nature
des informations traites. La modlisation des informations mtier contribue
cet effort, en permettant la mise en place de systmes appropris optimisant lutilisation de cette information.
55
Vue densemble
Le processus PO2 met en avant la ncessit de disposer de ressources
informatiques pour lesquelles les informations sont utilises de faon
optimise et scurise (alignement stratgique, apport de valeur, gestion
des risques, etc.), qui rpondent aux critres defficience, dintgrit, defficacit et de confidentialit.
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPORT DE
VALEUR
CONFIDENTIALITE
APPLICATIONS
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
INFRASTRUCTURES
PERSONNES
CONFORMITE
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 4-4 : Dnir larchitecture de linformation : PO2
Pourquoi ?
La modlisation de donnes permet dviter bien des cueils, lobjectif
tant de maintenir leur cohrence et dviter leur redondance ainsi que
lmergence de systmes dinformation parallles traitant de linformation
en doublon.
La classification de linformation travers un schma valid, prenant en
compte la criticit et la sensibilit des donnes (publiques, confidentielles, secrtes) par rapport au cur de lactivit, contribue dfinir des
niveaux de scurit et statuer sur le propritaire de linformation.
Se posent ensuite les questions de maintenabilit et dvolutivit du systme. Cest pourquoi assurer lintgrit et la cohrence de toutes les donnes stockes ou archives au format lectronique fait aussi partie des
objectifs du processus.
Cest sur ces bases que la DSI est en meilleure position pour faciliter le
dveloppement de systmes rpondant aux besoins spcifiques des
mtiers.
56
tableau 4-2.
Obj. 01
Obj. 04
Optimiser lutilisation de linformation.
Obj. 05
Donner de lagilit linformatique.
Obj. 11
Sassurer de lintgration progressive des solutions informatiques aux processus mtier.
Le primtre du processus comprend lensemble des donnes numrises ou informatises dans les systmes grs par la DSI ou par les
mtiers.
DEFINIR
DEFINIR UN MODELE DINFORMATION DE LENTREPRISE
Dictionnaire(s)
de donnes
ELABORER LE(S) DICTIONNAIRE(S) DES DONNEES
DEFINIR UN SYSTEME DE CLASSIFICATION DES DONNEES

IDENTIFIER LA DIMENSION CRITIQUE
ET SENSIBLE DES DONNEES
COMMUNIQUER
Systme de
classification
FACILITER LE
DEVELOPPEMENT
DAPPLICATIONS
AMELIORER
MAINTENIR A JOUR LE MODELE DINFORMATION,
LE(S) DICTIONNAIRE(S) DE DONNEES
ET LE SYSTEME DE CLASSIFICATION
DEFINIR UN SYSTEME DARCHIVAGE

ET DE DESTRUCTION DES DONNEES
IDENTIFIER LES PROPRIETAIRES DES DONNEES
FAVORISER LA
COMPREHENSION
COMMUNE
DES DONNEES
CONTROLER
CONTROLER LINTEGRITE ET LA COHERENCE
DE TOUTES LES DONNEES
METTRE EN UVRE
PLANIFIER LES SI A PARTIR DES 3 ELEMENTS DEFINIS
Procdures
et outils de
classification
METTRE EN PLACE DES PROCEDURES ET DES OUTILS

DE CLASSIFICATION DES DONNEES
57

Pour tre mis en place, ce processus ncessite une forte implication des
mtiers. Llaboration du modle dinformation de lentreprise ne peut se
passer du pilotage des mtiers, la DSI offrant un cadre mthodologique
pour son laboration et son entretien.
Le processus PO2 dfinit un modle de donnes de lentreprise pour en
garantir lintgrit, la confidentialit et la cohrence. Il vise btir un dictionnaire des donnes de lentreprise robuste et fiable. Le travail avec les
mtiers conduira en particulier optimiser la classification des donnes et
leur affecter un propritaire.
En effet, lidentification et la classification des informations est une prrogative des mtiers, tandis que celle de la DSI se focalise sur le maintien
oprationnel du dictionnaire des donnes partages par lensemble des
applications et systmes informatiques.
En labsence dimplication des mtiers, les objectifs doptimisation de
lutilisation de linformation et dagilit de linformatique ne pourront tre
atteints. Les exigences defficience seront galement trs affectes.
Mesures et contrles
Les mesures permettant de sassurer de lefficacit du processus portent
principalement sur le taux de donnes hors du modle dinformation de
lentreprise et sur les carts par rapport aux rgles de classification des
donnes.
La mesure de la mise en uvre de ce processus passe par le suivi de la frquence dvolution du modle de donnes, le taux de donnes sans propritaire, le nombre de mtiers impliqus dans lidentification et la
classification des donnes.
Le rle du pilote de ce processus est dlicat car sa mise en uvre ncessite une prise de conscience collective de lintrt dun modle darchitecture de linformation. La direction gnrale doit dlguer ce rle au bon
niveau, un mtier seul ne pouvant prendre le leadership. Le DSI, en tant
quinterlocuteur de tous les mtiers, peut jouer ce rle de pilote. Il lui
faudra alors une lgitimit suffisante pour assurer ce rle avec succs.
les donnes font bien lobjet dune identification et dune classification,
conformment aux rgles tablies.
58
Le directeur des systmes dinformation

Son rle est de sassurer que le modle dinformation de lentreprise, le
dictionnaire des donnes et les systmes de classification des donnes
sont bien disponibles et utiliss.
Le responsable architecture
Les donnes de lentreprise deviennent un actif essentiel. Le responsable
darchitecture doit sassurer de la cohrence, voire de la convergence, des
modles de donnes lis aux diverses applications. Il est le garant du
dictionnaire des donnes de lentreprise.

PO1, AI1, AI7, DS3,
SE1
Plan infor matique str atgique

Plan infor matique tactique
Etude de faisabilit exigences
des mtier s
Revues post- dmarr age
Infor mations sur la
per for mance et la capacit
Entr e de la per for mance dans
le planning SI
PO 3, AI 2, DS1, DS4,
DS5, DS11, DS12
PO2 : Dfinir
lar chitecture de
linformation
Systme de classification des
donnes
Plan optimis de systmes
mtier
Dictionnair e de donnes
Ar chitecture de linformation
Classification attribue aux
donnes
Pr ocdures et outils de
classification
PO3
Dterminer lorientation technologique
Les volutions technologiques ouvrent sans cesse de nouvelles possibilits stratgiques aux entreprises. La veille technologique est donc fondamentale non seulement pour optimiser les performances et les cots, mais
aussi pour crer de nouvelles opportunits aux mtiers.
En coordination troite avec les mtiers, la DSI doit initier une politique de
suivi des orientations technologiques. Cette dernire sappuie sur lanalyse
des technologies et des infrastructures informatiques existantes ainsi que
59
sur ltude des technologies mergentes susceptibles damliorer la couverture mtier. Elle constitue le plan dorientation technologique.
Vue densemble
Le processus PO3 a pour objectif principal de sassurer que les infrastructures informatiques (et les applications quelles supportent) rpondront
au mieux aux exigences defficacit et defficience des mtiers.
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPORT DE
VALEUR
CONFIDENTIALITE
APPLICATIONS
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 4-7 : Dterminer lorientation technologique : PO3
Pourquoi ?
Moins lenvironnement informatique est standard, plus le changement
engendr par une stratgie de migration ou un plan dacquisition est
complexe et coteux, en ressources comme en dlais.
Lun des objectifs du plan dinfrastructure technologique est doptimiser
les orientations relatives lacquisition de ressources informatiques qui
doivent conduire des conomies dchelle dans les effectifs et les investissements informatiques.
Lamlioration de lintgration des infrastructures et des applications
doit se traduire par des standards, par une meilleure utilisation des ressources et des capacits ainsi que par la rduction des cots relatifs aux
acquisitions technologiques, travers des plates-formes limites en
nombre et en spcificit.
Un autre objectif de ce plan dinfrastructure consiste grer les orientations pour offrir une meilleure interoprabilit entre les plates-formes et
les applications.
60
tableau 4-3.
Obj. 07
Acqurir et maintenir fonctionnels des systmes applicatifs intgrs et standardiss.
Obj. 15
Optimiser linfrastructure, les ressources et les capacits informatiques.
Ce processus concerne principalement la matrise des infrastructures

informatiques (matriels et logiciels).
PUBLIER LES
STANDARDS
TECHNIQUES
AMELIORER
DEFINIR LUTILISATION FUTURE ET STRATEGIQUE
DES NOUVELLES TECHNOLOGIES
DETERMINER LORIENTATION TECHNOLOGIQUE LA PLUS

FAVORABLE A LACTIVITE DE LENTREPRISE
COMMUNIQUER
FAIRE VALIDER
LE PLAN
DEFINIR
ETUDIER LES TECHNOLOGIES ACTUELLES ET FUTURES
Plan
dinfrastructure
technologique
MAINTENIR A JOUR LE PLAN

DINFRASTRUCTURE TECHNOLOGIQUE
DEFINIR LE PLAN DINFRASTRUCTURE TECHNOLOGIQUE
VEILLER
METTRE EN UVRE
Standards
techniques
SURVEILLER LES TENDANCES DE

LENVIRONNEMENT METIER
METTRE EN PLACE UN FORUM INFORMATIQUE

SURVEILLER LES NOUVELLES TECHNOLOGIES
METTRE EN PLACE UN COMITE ARCHITECTURE TI
SURVEILLER LEVOLUTION DU CADRE
REGLEMENTAIRE ET LEGISLATIF
CONTROLER
VERIFIER LA CONFORMITE AUX STANDARDS
ET AUX LIGNES DIRECTRICES
Ce processus se focalise sur llaboration et la mise en uvre du plan

dinfrastructure technique ou technologique. Il implique principalement la
DSI, dont le responsable aura toute la lgitimit et la crdibilit pour
assurer le rle de pilote.
61
Lune des caractristiques de la mise en uvre de ce processus est la

ncessit de mettre en place une instance ddie la dfinition des orientations technologiques : le comit darchitecture technologique. Cette instance pourra, selon la taille et la criticit des infrastructures, tre anime
par le DSI ou le responsable architecture.
Toutes les dispositions du plan dinfrastructure soulignent le rle important
du comit darchitecture travers les dcisions quil prend en considrant ce
que la technologie peut offrir en termes de produits, services et fournitures.
Une bonne connaissance des mtiers est ncessaire pour garantir lalignement entre technologie et objectifs mtier ainsi que lmergence de possibilits nouvelles grce aux volutions technologiques.
Notons que lexternalisation croissante des processus dexploitation
ncessite dassocier les tiers ce comit afin de reporter sur leurs obligations contractuelles les bonnes pratiques attendues comme rsultat de ce
processus.
Ce processus est intimement li au processus PO2.
Mesures et contrles
Les mesures pour sassurer de lefficacit du processus PO3 portent principalement sur le nombre dcarts par rapport aux standards techniques et
sur lhtrognit des diffrentes plates-formes techniques dployes
dans lentreprise.
La mesure de la mise en uvre de ce processus passe par le suivi du
nombre de runions du comit darchitecture et par la frquence dvolution
du plan dinfrastructure.
Son rle est de sassurer de la dfinition et de la validation des orientations
technologiques.
Le responsable architecture
Il est en charge de la bonne excution des travaux demands par le comit
darchitecture.
Le comit darchitecture
Il assiste le DSI dans sa prise de dcision quant aux orientations technologiques et il pilote les activits de veille et les travaux relatifs la conception
de larchitecture technique du SI.
62

AI1, AI2, AI3, AI7, DS5,
PO5
PO1, PO2, AI3, DS3
Plan informatique stratgique

Plan optimis des systmes
mtier
Architecture de linformation
Mises jour des standards
techniques
Information sur la
performance et la capacit
PO3 : Dterminer
lorientation
technologique
Opportunits technologiques
Standards techniques
Mises jour rgulires de
ltat de la technologie
Plan dinfrastructure
technique
Besoins en infrastructures
PO4
Dfinir les processus, lorganisation

et les relations de travail
Afin de fournir un service de qualit et de rpondre aux attentes traduites

dans les plans stratgique et tactique SI, lorganisation informatique doit
tre en mesure de faire correspondre aux acteurs des mtiers les fonctions
appropries au sein de la DSI.
Pour des raisons defficacit, les rles et les responsabilits au sein de
lorganisation doivent tre bien dfinis et les besoins en comptence anticips. La DSI doit mettre en place, par exemple, un processus de gestion
des comptences global. La dcision de raliser certaines tches en interne
conduit au plan de recrutement et la formation, alors que la dcision de les
sous-traiter des prestataires sappuie sur le sourcing1.
De faon plus gnrale, la DSI doit formaliser tous les processus informatiques qui touchent les mtiers et mettre un accent particulier sur le
contrle, lassurance qualit, la gestion du risque, la proprit des donnes
et des systmes ainsi que la sparation des tches.
Lorganisation doit tre anime par les instances de dcision que sont le
comit stratgique et le comit de pilotage.
63
1. Recherche de fournisseurs (sourcing) :

le sourcing, appel
parfois recherche
dune seconde
source , consiste
mener une veille
active an didentier
des fournisseurs
potentiels. Une veille
bien organise permet dtre trs ractif
le moment venu.
Vue densemble
Le processus PO4 sintresse lorganisation et aux ressources en personnels afin de leur attribuer des fonctions en vue de structurer lorganisation.
Il rpond ainsi aux exigences defficacit et defficience de la DSI vis--vis
des mtiers en optimisant la gestion de ses ressources humaines et en
dveloppant une culture de la gestion des risques.
GOU VERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPLICATIONS
APPORT DE
VALEUR
CONFIDENTIALITE
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 4-10 : Dnir les processus, lorganisation et les relations de travail : PO4
Pourquoi ?
Le propre dune organisation informatique fiable et performante rside
dans sa capacit dadaptation et de ractivit rpondre aux attentes
clients.
Dans ce but, lorganisation doit tendre vers un alignement mtier-informatique et ainsi, rpondre aux exigences et aux stratgies en personnel qui
soutiennent les objectifs mtier.
Un cadre de rfrence des processus informatiques est indispensable pour
clarifier les activits cls, les rles, les postes cls, la proprit et la responsabilit des donnes et des systmes.
Cette mise au clair conduit un renforcement des rles et des responsabilits favorisant la performance individuelle. Le cadre de rfrence conduit
galement la mise en place dun processus efficace de recrutement de
comptences appropries. La dcision de faire voluer le personnel, ou au
contraire de faire appel la sous-traitance dans un cadre de contrle bien
dfini, sen trouve facilite.
64
tableau 4-4.
Obj. 01
Obj. 02
Obj. 05
Le processus PO4 couvre lensemble des aspects du fonctionnement de

lorganisation relatif aux services informatiques.
PO4 Dfinir les processus, lorganisation

DEFINIR
DEFINIR UN CADRE DE REFERENCE
DES PROCESSUS INFORMATIQUES
COMMUNIQUER
Rfrentiel des
processus
informatiques
IMPLIQUER LES TI
DANS LES
PROCESSUS
DE DECISION
CONNAITRE LES
ROLES, LES
RESPONSABILITES
ET LES RELATIONS
POSITIONNER LA FONCTION INFORMATIQUE

SELON LIMPORTANCE DES SI DANS LENTREPRISE
IDENTIFIER LES PROPRIETAIRES DES DONNEES
ET DES SYSTEMES DINFORMATION
CONTROLER
DEFINIR LES ROLES ET RESPONSABILITES DES SI
EVALUER REGULIEREMENT LES

BESOINS EN RESSOURCES
Documentation
des rles et
responsabilits
METTRE EN UVRE
METTRE EN PLACE UN COMITE STRATEGIQUE INFORMATIQUE
SUPERVISER LA MISE EN PRATIQUE

DES ROLES ET RESPONSABILITES
CONTROLER LES ACTIVITES DES
TIERS EXTERNES
METTRE EN PLACE UN COMITE DE PILOTAGE INFORMATIQUE

ETABLIR UNE STRUCTURE DORGANISATION DE LINFORMATION
DE COORDINATION ET DE COMMUNICATION
SEPARER LES ROLES ET LES RESPONSABILITES

Dans le cadre du dveloppement de lorganisation, la fonction informatique doit largir son champ de responsabilit par la cration de postes de
65
responsables qualit, scurit et conformit. Les principes dassurance

qualit au sein de la DSI sont ainsi intgrs. Il en rsulte une meilleure
garantie de la performance des SI et de la protection ou de lintgrit de
linformation.
Les prcautions prendre pour le bon fonctionnement de lorganisation
doivent prvoir des dispositions efficaces de matrise de risques par rapport aux personnels informatiques cls et lapplication du principe de
sparation des tches. Ces dispositions impliquent de bien former le personnel, de partager les connaissances et de prvoir un plan de succession
pour assurer la continuit des services. Le principe de sparation des
tches garantit un fonctionnement efficace et efficient des processus ainsi
quune protection satisfaisante de linformation.
Une fois la structure mise en place, le processus PO4 insiste sur la ncessit de renforcer la position de la fonction informatique au sein de lentreprise, ce qui revient intgrer la gouvernance informatique dans la
gouvernance de lentreprise.
La mise en place de comits stratgiques informatiques tablit une instance de dcision charge de statuer, avec la ractivit ncessaire, sur des
investissements lourds ou des dcisions urgentes. De mme, les comits
de pilotage sont incontournables pour veiller ce que les programmes
dinvestissement informatiques soient en phase avec la stratgie et lorganisation, et ce que linformatique et les mtiers soient impliqus positivement dans la dfinition des priorits, la rsolution des conflits et la
surveillance de la performance.
Sur le plan de la gestion prvisionnelle des emplois et des comptences, la
DSI doit travailler de faon troite avec la DRH et les achats afin doptimiser la rpartition des ressources entre linterne et lexterne, dans une
vision moyen et long termes. La majeure partie des analyses ce sujet
saccorde pour privilgier les connaissances mtier dans les comptences
requises en interne (voir section PO7 Grer les ressources humaines ).
Mesures et contrles
Afin de contrler le bon fonctionnement de lorganisation informatique, une supervision adapte la fonction informatique doit
permettre de sassurer que les rles et les responsabilits sont bien
exercs, et dvaluer la performance sous la forme dindicateurs cls. La
mesure de lefficacit de ce processus passe par le suivi du nombre darbitrages effectus pour rsoudre les conflits de dcision du fait dune mauvaise
ou insuffisante attribution de responsabilits.
66
La mesure de la mise en uvre de ce processus passe par le suivi du taux

de description de fonctions et de leur attribution au personnel, ainsi que
par la frquence des runions du comit de pilotage informatique et de la
mise en uvre effective de ses dcisions dans les dlais dfinis.
Les instances et lires
Le comit stratgique informatique
Il est rattach au plus haut niveau de lentreprise. Il sassure de la bonne
gouvernance du SI et conseille la direction de lentreprise dans les orientations stratgiques et les choix dinvestissement informatique en fonction
des besoins des mtiers. Selon la taille et la criticit de lentreprise, il est
prsid par le prsident de lentreprise ou un directeur gnral dlgu.
Le comit de pilotage informatique
Il est compos de cadres reprsentant les mtiers et linformatique afin de
mettre en uvre la stratgie informatique dfinie par la direction de
lentreprise. Il assure le pilotage des investissements informatiques et des
activits de service (priorits/arbitrages, rsolution des conflits daccs aux
ressources).
La filire qualit
Il sagit de dfinir une organisation ddie propre mettre en uvre la
politique et les objectifs qualit en fonction des exigences des mtiers.
La filire scurit et les risques informatiques
politique et les objectifs scurit, en ligne avec lanalyse des risques lis
aux systmes dinformation.
Les fonctions
Son rle est de sassurer de la dfinition et de la validation de lorganisation
ainsi que du cadre de rfrence des processus informatiques.
Le responsable de la scurit des systmes dinformation (RSSI)
Il anime la filire scurit et sassure que le processus DS5 est bien mis en
uvre.
Le responsable dassurance qualit (RAQ)
Il anime la filire qualit et sassure que le cadre de rfrence des processus
est appliqu et que le processus PO8 est bien mis en uvre.
67

PO1, PO7, PO8, PO9,
SE1, SE2, SE3, SE4
Tous
PO4 : Dfinir les

processus,
lorganisation et les
relations de travail
Politiques et procdures RH des SI
Tableau des comptences SI
Descriptions de postes
Actions pour lamlioration de la
qualit
Plan dactions pour remdier aux
risques SI
Plan dactions correctives
Rapports sur lefficacit des
contrles SI
Recueil des exigences lgales /
rglementaires concernant la
fourniture de services
informatiques
Amliorations du rfrentiel des
processus
Rfrentiel des processus

informatiques
Documentations sur les
propritaires des processus
Organisation et relations de travail
de linformatique
Documentation des rles et
responsabilits
PO5
Grer les investissements informatiques
On a trop longtemps considr la direction des systmes dinformation

comme un centre de cot, sans parvenir expliciter sa contribution en
termes de cration de valeur aux mtiers de lentreprise.
1. Parties prenantes
(stakeholders) : il sagit
de tous les acteurs
concerns, que ce soit
nancirement
(actionnaires), stratgiquement (direction)
ou fonctionnellement
(mtiers).
Aujourdhui, le discours a chang depuis que le concept de gouvernance

informatique a fait son apparition. Les services informatiques sont considrs comme des partenaires des parties prenantes1 du mtier. La transparence au niveau des cots de fonctionnement et dinvestissements
informatiques se gnralise. Ds lors que la DSI dispose dun cadre de
rfrence et de modles de cots adapts, il est usuel que les dpenses
informatiques, mais aussi les bnfices rsultant des investissements
soient affects au niveau des services mtier utilisateurs.
Dans ce contexte, la mise en place dun processus de budgtisation prenant en compte les programmes dinvestissement et un cadre de rfrence
qui couvre les cots, les bnfices, les priorits budgtaires, est plus que
jamais dactualit.
68
Vue densemble
GOU VERNANCE SI
EXIGENCES METIER
RESSOURCES
NFORMATIQUES
I
EFFICACITE
ALIGNEMENT
STRATEGIQUE
APPORT DE
VALEUR
EFFICIENCE
APPLICATIONS
CONFIDENTIALITE
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 4-13 : Grer les investissements : PO5
Le processus PO5 sintresse la bonne gestion financire des ressources

en personnels, infrastructures et applications afin doptimiser lapport de
valeur. Il rpond ainsi aux exigences defficacit et defficience de la DSI
vis--vis des mtiers.
Pourquoi ?
Afin de rendre possible une gestion des investissements informatiques,
ltablissement dun rfrentiel de gestion financire est ncessaire. Des
modles de cots doivent tre dfinis, lesquels apportent une clarification
et aident la validation du budget. Les priorits budgtaires se dclinent
ensuite sur les portefeuilles de projets et de services, refltant lalignement
entre les objectifs informatiques et les exigences du mtier, sur la base de
la transparence et du dialogue.
Le processus de budgtisation se prsente comme un processus de prise
de dcision pour la prvision et laffectation budgtaire. Il contribue
quilibrer les cots et ajuster les prvisions dans une dmarche damlioration continue.
Au quotidien, la gestion des cots permet didentifier rapidement les
carts par rapport au budget et permet dutiliser au mieux les ressources
informatiques dans un objectif de rentabilit.
La gestion des bnfices doit permettre de prendre des dcisions sur la
suite donner concernant un portefeuille dinvestissement, comme poursuivre, ajuster ou abandonner le programme.
Le processus PO5, travers la transparence des dpenses et la notion de
retour sur investissement, conduit aussi la bonne tenue des relations
entre les parties prenantes informatiques et mtiers.
69
annexe 2, Objectifs du systme dinformation et processus CobiT ), le processus PO5 doit permettre de matriser les objectifs prsents dans le
tableau 4-5.
Obj. 12
Sassurer de la transparence et de la bonne comprhension des cots, bnces, stratgies,

politiques et niveaux de services des SI.
Obj. 24
Amliorer la rentabilit de linformatique et sa contribution la protabilit de lentreprise.
Obj. 28
Sassurer que linformatique fait preuve dune qualit de service efciente en matire
de cots, damlioration continue et de capacit sadapter des changements futurs.
Le processus PO5 couvre lensemble des processus financiers relatifs

lorganisation informatique.
Rapport
Cots /
Bnfices
COMMUNIQUER
METTRE EN
EVIDENCE LES
ECARTS
AMELIORER
AMELIORER LA CONTRIBUTION DES SI
AUX RESULTATS DE LENTREPRISE
DEFINIR DES CRITERES DINVESTISSEMENTS

(ROI, dure d'amortissement, valeur nette actuelle)
AIDER A ETABLIR
DES PRIORITES
BUDGETAIRES
FAIRE VALIDER
LES BUDGETS
DEFINIR
ANALYSER LA RENTABILITE DES PORTEFEUILLES
DINVESTISSEMENTS, DES SERVICES
ET DES ACTIFS INFORMATIQUES
DEFINIR DES PRIORITES DANS LATTRIBUTION

DES RESSOURCES INFORMATIQUES
Budgets
Ecarts
Cots /
Prvisions
DEFINIR UN BUDGET GLOBAL INFORMATIQUE

ET DES BUDGETS DE PROGRAMMES INDIVIDUELS
REMEDIER AUX ECARTS AVEC LE

RESPONSABLE METIER DU PROGRAMME
REEVALUER, SI NECESSAIRE, LANALYSE
DE RENTABILITE DU PROGRAMME
MAINTENIR A JOUR LES PORTEFEUILLES
DINVESTISSEMENTS, DES SERVICES
ET DES ACTIFS INFORMATIQUES
METTRE EN UVRE
CONTROLER
METTRE EN PLACE UN REFERENTIEL

DE GESTION FINANCIERE POUR LES SI
METTRE EN PLACE UN PROCESSUS DE BUDGETISATION
ET DE GESTION DES COUTS
COMPARER LES COUTS ET LA VALEUR DES SI

PAR RAPPORT AUX PREVISIONS
EVALUER LES CONSEQUENCES DES ECARTS
SUR LES PROGRAMMES
METTRE EN PLACE UN PROCESSUS

DE SURVEILLANCE DES BENEFICES
70

Pour tre mis en uvre, ce processus ncessite une forte implication
des mtiers et une action combine des mtiers et responsables de la
DSI.
La bonne mise en place de ce processus implique que le comit stratgique informatique ait t cr et quil puisse jouer son rle sur
lensemble des investissements informatiques. Ce processus fait apparatre le besoin dune coresponsabilit dans cette gestion.
Au quotidien, la gestion des cots permet didentifier rapidement les
carts par rapport au budget et dutiliser au mieux les ressources informatiques dans un objectif de rentabilit.
La gestion des bnfices doit permettre la direction gnrale de
prendre des dcisions sur la suite donner concernant un portefeuille
de programmes dinvestissement, comme poursuivre, ajuster ou abandonner le programme.
Le processus PO5, travers la transparence des dpenses et la notion
de retour sur investissement, conduit aussi la bonne tenue des relations entre les parties prenantes. Il permet en particulier de rguler les
niveaux de services demands et la consommation des ressources en en
rpercutant les cots.
Notons que la refacturation des services nest pas une fin en soi. En
revanche, il est important de savoir isoler les cots et de les regrouper
dans des units duvre pertinentes pour dialoguer avec les mtiers.
Mesures et contrles
Les mesures pour sassurer de lefficacit du processus portent principalement sur le nombre dcarts par rapport aux prvisions budgtaires et
sur le ratio cots/bnfices des investissements informatiques pour les
mtiers.
La mesure de la mise en uvre de ce processus passe principalement par
le suivi du taux de projets ou de services dont le cot est valu.
Le comit de pilotage informatique
Il est compos de cadres reprsentant les mtiers et linformatique pour
mettre en uvre le programme dinvestissement informatique dcid par
la direction de lentreprise. Il assure le pilotage des investissements informatiques et des activits de service (priorits/arbitrages, rsolution des
conflits daccs aux ressources, etc.). Il est le pilote de ce processus.
71
Le directeur gnral
Compte tenu de la finalit de ce processus, le directeur gnral en est
le client ; il en est galement le garant dans la mesure o il arbitre les
programmes dinvestissement. charge ensuite au DSI de russir la
transformation de ces investissements en valeur pour lentreprise.
les dcisions, engagements de budget et arbitrages budgtaires ne se font
pas au dtriment de lapport de valeur, et que le rapport cots/bnfices
est celui escompt.

Son rle est de sassurer que le processus budgtaire est bien mis en
uvre et que tous les cots (projets et services) font lobjet dun suivi
rigoureux.
PO1, PO3, PO10, AI1,

DS3, DS6, SE4
PO1, PO10, AI2, DS1,

DS6, SE1, SE4
PO5 : Grer les

investissements
informatiques
Plans informatiques stratgiques et

tactiques
Portefeuilles de projets et de
services
Besoins en infrastructures
Etude de faisabilit des exigences
mtier
Plan performance et capacit
(exigences)
Donnes financires informatiques
Rsultats attendus des
investissements informatiques
des mtiers
Rapports cots/bnfices
Budgets informatiques
Portefeuille actualis des
projets
Portefeuille actualis des
services
72
PO6
Faire connatre les buts et les

orientations du management
La DSI a parfois t tente de se retirer dans sa tour divoire pour

dcrter tranquillement des dispositions prendre sur le plan des systmes dinformation, sans trop en rendre compte. prsent, le SI devient
stratgique et lexigence de qualit de service est plus forte. La DSI est
sous la menace permanente de la contre-performance qui viendra dcrdibiliser son travail et ses choix. Par ailleurs, les investissements doivent
tre justifis de faon plus stricte.
La pression sur les performances et sur les cots conduit plus de transparence. Le directeur des systmes dinformation doit donc tre attentif
la dimension de communication vers les utilisateurs et les dcideurs et
sen servir pour mieux prendre en compte la ralit des besoins et des
moyens de son entreprise.
Vue densemble
Le processus PO6 sintresse la bonne mise en place dun programme de
communication vers les diffrentes parties prenantes afin de dvelopper
une culture de gestion des risques et dalignement stratgique. Il rpond
ainsi aux exigences defficacit de la DSI vis--vis des mtiers.
GOU VERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPLICATIONS
APPORT DE
VALEUR
CONFIDENTIALITE
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 4-16 : Faire connatre les buts et les orientations du management : PO6
73
Pourquoi ?
La politique de la DSI ne saurait se dcider dans labsolu. Elle est le
rsultat dun certain nombre de contingences : besoins satisfaire,
valeur attendue de la technologie, budgets, niveau de risque acceptable,
thique, comptences, rglementations en vigueur, etc. Il est donc
ncessaire de bien comprendre le contexte de lentreprise pour dcider
des politiques informatiques adaptes.
Les parties prenantes ont besoin dun cadre de contrle afin de mieux
piloter leurs investissements et les services offerts. Donner ce cadre une
dimension purement financire serait trop restrictif. Il est ncessaire dune
part de faire accepter aux utilisateurs et aux mtiers les orientations proposes par la DSI issues des politiques et dautre part, de communiquer
autour des oprations de contrle afin de coller au plus prs aux proccupations de lentreprise.
tableau 4-6.
Obj. 12
Sassurer de la transparence et de la bonne comprhension des cots,

bnces, stratgies, politiques et niveaux de services des SI.
Obj. 13
Sassurer dune bonne utilisation et des bonnes performances des applications et des solutions informatiques.
Obj. 19
Sassurer que l'information critique et condentielle nest pas accessible

ceux qui ne doivent pas y accder.
Obj. 20
Sassurer que les transactions mtier automatises et les changes dinformations sont ables.
Obj. 21
Sassurer que les services et linfrastructure informatique peuvent rsister/

se rtablir convenablement en cas de panne due une erreur, une attaque dlibre ou un sinistre.
Obj. 22
Sassurer quun incident ou une modication dans la fourniture dun service informatique na quun impact minimum sur lactivit.
Le processus PO6 couvre lensemble des mcanismes relatifs la communication du DSI vis--vis de son personnel et des tiers externes et, plus
gnralement, de la DSI avec les mtiers.
74
PO6 Faire connatre les buts

et les orientations du management
DEFINIR
DEFINIR LES ELEMENTS DUN ENVIRONNEMENT DE CONTROLE
COMMUNIQUER
DEVELOPPER ET ACTUALISER DES POLITIQUES INFORMATIQUES

Rfrentiel
de contrle
PROMOUVOIR LAPPORT DE VALEUR DES SI

ET LAMELIORATION CONTINUE
METTRE EN PLACE ET MAINTENIR UN REFERENTIEL

DE CONTROLE INFORMATIQUE
FAIRE VALIDER
LES POLITIQUES INFORMATIQUES
EXPLIQUER LES POLITIQUES
ET IMPLIQUER LE PERSONNEL
Politiques
informatiques
FAIRE CONNAITRE LES OBJECTIFS

ET LES ORIENTATIONS INFORMATIQUES
METTRE EN UVRE
FAIRE APPLIQUER LES POLITIQUES INFORMATIQUES
Objectifs et
orientations
informatiques
APPLIQUER UN PROGRAMME DE COMMUNICATION PERMANENT

Pour tre mis en uvre, ce processus ncessite un fort engagement du
directeur des systmes dinformation.
La bonne mise en place de ce processus implique que le DSI dfinisse et
mette jour des politiques informatiques relatives la qualit, la scurit, aux risques, aux achats, la gestion des comptences, etc. Ce processus fait apparatre le besoin dune implication forte de lensemble du
management de la DSI afin que ces politiques soient dployes et que la
communication sappuie sur des actes concrets.
Mesures et contrles
La mesure de lefficacit de ce processus passe par le suivi du nombre
de personnes qui connaissent et comprennent les politiques informatiques et sy conforment. En dautres termes, il sagit de personnes capables didentifier leur contribution la bonne mise en uvre de ces
politiques.
La mesure de la mise en uvre de ce processus passe par le suivi de la frquence des actes de communication et des volutions des politiques en
fonction du contexte des activits informatiques et mtiers.
75
Son rle est de sassurer que le processus de communication des buts et
orientations du management est bien mis en uvre. Il est le pilote de ce
processus.
Le personnel de la DSI
Limportance donne la communication et la clarification des objectifs
se traduit par la cohsion des quipes. In fine, les personnels de la DSI doivent
comprendre et appliquer les politiques dictes.

PO1, PO9, SE2
Tous
PO6 : Faire connatre les

buts et les orientations du
management
Plans informatiques
stratgiques et tactiques
Portefeuille de projets
Guide de gestion des risques
lis aux SI
Rapport sur lefficacit des
contrles du SI
Rfrentiel de contrle des

SI de lentreprise
Politiques informatiques
PO7
Grer les ressources humaines

de linformatique
La politique de gestion des ressources humaines est soumise de fortes

contraintes. Dun ct, les recherches dconomie poussent sans cesse
agrandir les primtres externaliss et, dun autre ct, les volutions
76
technologiques constantes rendent difficile laccs aux ressources critiques. Il

faut donc arbitrer les recrutements, tout en ayant en tte la question de
lemployabilit long terme. En effet, un technicien pointu dans un
domaine na pas forcment de rle prenne lintrieur dune organisation
donne.
Il est donc important doptimiser lutilisation des diffrents vecteurs
damlioration des comptences : le recrutement, la formation et le recours
des tiers.
Les critres de slection des ressources maintenir sont parfois difficiles dterminer. Il est certain quil faut au moins trouver une forte
capacit de dialogue et de comprhension avec les mtiers et une bonne
matrise de la sous-traitance. Dans la mesure o les effectifs de la DSI
sont en diminution constante, ces ressources deviennent de plus en
plus critiques.
Vue densemble
Le processus PO7 gre les ressources humaines de la DSI. Il sintresse la
bonne gestion prvisionnelle des comptences de la DSI, afin de sassurer
que les quipes seront en mesure de sadapter pour faire face aux volutions technologiques (alignement stratgique) et en faire bnficier les
mtiers. Il rpond ainsi aux exigences defficacit et defficience de la DSI
vis--vis des mtiers.
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPORT DE
VALEUR
CONFIDENTIALITE
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
APPLICATIONS
INFORMATIONS
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 4-19 : Grer les ressources humaines de linformatique : PO7
77
Pourquoi ?
Le processus PO7 aborde la question des ressources humaines du point de
vue de la DSI : Quelles sont les ressources et comptences ncessaires ?
Comment anticiper les besoins, recruter les ressources ncessaires et
maintenir les comptences ? De quelles comptences veut-on sentourer :
des experts informatiques, des experts des domaines mtier de lentreprise, des chefs de projet, des pilotes aviss de prestations externalises ?
Pour rpondre ces questions, il faut dvelopper une vritable politique RH au sein de la DSI et pour la DSI (description de postes, gestion
des comptences et des comptences cls, valuation, formation, volution
de carrire, etc.).
Par ailleurs, il est habituel de compter des effectifs supplmentaires sous
forme de contrats de sous-traitance avec dlgation de personnel, dans les
locaux du client. Ces sous-traitants sont en gnral grs par le service
achats et le commanditaire de la DSI, sans implication du responsable des
ressources humaines. Du point de vue de la gestion globale des comptences, cest insuffisant. Il faudrait associer lensemble de ces personnels
externes la gestion des comptences de faon en optimiser lemploi et
suivre les performances correspondantes.
processus PO7 doit permettre datteindre les objectifs prsents dans le
tableau 4-7.
OBJ. 05
OBJ. 09
Se procurer et conserver les comptences ncessaires la mise en

uvre de la stratgie informatique.
Le processus de gestion des ressources humaines de la DSI sarticule

autour du processus de lentreprise en termes de ressources humaines et
les complte pour prendre en compte la dimension mtier SI . Il est
ncessaire, du moins sur le plan de la gestion des comptences, de le lier
au processus achats pour les ressources externes.
78

de linformatique
DEFINIR
AMELIORER
DEFINIR DES PROCESSUS DE RECRUTEMENT
TENIR A JOUR LES CONNAISSANCES

ET LES COMPETENCES
IDENTIFIER LES COMPETENCES CLES
STIMULER LES PERFORMANCES
DEFINIR DES FICHES DE POSTE (rles, niveaux de rmunration,

de responsabilit et de supervision)
Poltiques RH
Fiches de
postes
Tableau des
comptences
SI
CONTROLER
VERIFIER LACQUISITION DES COMPETENCES
METTRE EN UVRE
EVALUER LES PERFORMANCES DES EMPLOYES

PAR RAPPORT AUX OBJECTIFS INDIVIDUELS
APPLIQUER LES POLITIQUES RH

ET LES PROCEDURES PROPRES AUX SI
SUPERVISER LES ROLES ET RESPONSABILITES

ORGANISER LE TRANSFERT DES CONNAISSANCES ET DES
RESPONSABILITES LORS DES MOUVEMENTS DE PERSONNELS
REDUIRE LE RISQUE DE DEPENDANCE VIS-A-VIS

DES RESSOURCES CLES

Dans la majeure partie des entreprises, la gestion des ressources
humaines de la DSI nest quun prolongement des processus et procdures
de lentreprise. Il est rare de trouver des descriptions de comptences
adaptes aux mtiers de linformatique.
En rgle gnrale, lapplication de la politique RH consiste respecter les
processus dentretien et dvaluation annuels, de dtermination des objectifs et dvolution de la masse salariale. Au-del, les salaris de la DSI restent avant tout des agents , des postiers , des cheminots , etc.,
marquant ainsi leur appartenance un corps plus large, dans lequel ils
trouveront dailleurs bien souvent leur volution de carrire.
La mise en uvre du processus PO7 passe par la mise au point dun rfrentiel de comptences de la DSI, ou cartographie, permettant dvaluer
les ressources internes et leur adquation aux besoins actuels et futurs.
Les dcisions stratgiques concernant les ressources humaines font lobjet
dun plan actualis priodiquement. Ce plan se dcline lui-mme en
dautres plans : le plan de recrutement, le plan de formation, les volutions
individuelles et les achats externes de lassistance complmentaire.
79
Mesures et contrles
La mesure de lefficacit de ce processus passe principalement par le suivi
du pourcentage de personnes dont le profil couvre la cartographie cible
des comptences de la DSI. Dautres indicateurs peuvent complter cette
mesure defficacit, par exemple, le suivi de postes cls non pourvus en
interne ou de remplaants identifis.
La mesure de la mise en uvre de ce processus passe par le suivi du plan
de formation par rapport la cartographie cible des comptences, le suivi
du taux de ralisation des valuations des collaborateurs ainsi que le taux
de couverture des postes par une fiche de fonction.
Son rle est de sassurer que ce processus est bien mis en uvre et quil
respecte la politique RH de lentreprise en matire de gestion des ressources
humaines. Il est le pilote de ce processus.
Le responsable des ressources humaines (RRH)
Le responsable des ressources humaines est lmanation de la DRH au sein
de la DSI, charg de faire concider les objectifs et les procdures de la DSI et
de la DRH. Il tient jour le rfrentiel des comptences, pilote les rsultats
des valuations annuelles, participe la dtermination des objectifs, pilote
le recrutement et conseille le DSI en matire de ressources humaines.

PO4, AI1
Tous
PO7 : Grer les ressources

humaines de linformatique
Documentation relative
lorganisation, aux
relations, aux rles et
responsabilits des SI
Etude de faisabilit des
exigences des mtiers
Politiques et procdures
RH des SI
Tableau de comptences
SI
Fiches de poste
Comptences et
connaissances des
utilisateurs et formation
individuelle
Besoins spcifiques de
formation
80
PO8
Grer la qualit
La notion de systme de management de la qualit (SMQ) a t popularise par la famille de normes ISO/IEC 9000. Les principes dvelopps dans
ce processus en proviennent. Il sagit donc de btir un systme cohrent
bas sur une politique qualit dcline en objectifs qualit cohrents avec
le plan informatique stratgique. Ceci sera traduit en procdures et
mthodes, avec le souci de dfinir des indicateurs de mesure pour amliorer en permanence la qualit mais aussi faire progresser paralllement le
systme de management qualit lui-mme.
Vue densemble
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPORT DE
VALEUR
CONFIDENTIALITE
APPLICATIONS
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 4-22 : Grer la qualit : PO8
Le processus PO8 sintresse la bonne mise en place dun SMQ cohrent

avec la stratgie SI (alignement stratgique) et permettant lapport de
valeur ainsi que le dveloppement dune culture de gestion des risques. Il
rpond ainsi aux exigences defficacit, defficience, dintgrit et de fiabilit de la DSI vis--vis des mtiers.
Pourquoi ?
Le processus PO4 dfinit un cadre de rfrence des processus informatiques.
Un systme de management de la qualit doit imprativement complter ce
cadre de rfrence par la dtermination dindicateurs de mesure et de seuils
dobjectifs atteindre, sous peine de tomber rapidement dans loubli. Lexprience prouve que la mesure des rsultats par des tiers est souvent rejete.
Lorsque cette mesure est destine amliorer le fonctionnement et aboutit
81
donc remettre en cause certaines pratiques, cest encore plus dlicat. Il est
trs difficile dancrer une culture de lamlioration continue, do lide de
laligner au processus de management (objectifs individuels).
Enfin, le systme de management de la qualit donne tout son sens aux
activits de la DSI en les alignant, dune part, avec les objectifs stratgiques
et, dautre part, avec les souhaits des utilisateurs des SI.
annexe 2, Objectifs du systme dinformation et processus CobiT ), le processus PO8 doit permettre datteindre les objectifs prsents dans le
tableau 4-8.
OBJ. 16
Rduire le nombre de dfauts et de retraitements touchant la fourniture de solutions et de

services.
OBJ. 25
Livrer les projets temps et dans les limites budgtaires en respectant les standards de
qualit.
Le processus PO8 couvre lensemble des principes relatifs au management

de la qualit et lamlioration continue des produits et services offerts.
Le processus de management de la qualit dicte les principes et les standards pour les autres processus.
DEFINIR
DEFINIR UN SYSTEME DE GESTION DE LA QUALITE (SGQ)
PO8 Grer la qualit
COMMUNIQUER
RESPECTER LES
STANDARDS
PROMOUVOIR
LAMELIORATION
CONTINUE
Standards de
qualit, de
dveloppement
et dacquisition
Plan gnral
qualit
AMELIORER
IDENTIFIER LES ACTIONS
CORRECTIVES ET PREVENTIVES
IDENTIFIER LES STANDARDS INFORMATIQUES

ET LES PRATIQUES DE QUALITE
AMELIORER LE SGQ
IDENTIFIER LES STANDARDS DE DEVELOPPEMENT
ET DACQUISITION
ETABLIR UN PLAN GENERAL QUALITE
CONTROLER
SURVEILLER EN PERMANENCE
LA CONFORMITE AU SGQ
METTRE EN UVRE
METTRE EN PLACE ET ACTUALISER LE SGQ
EVALUER LA VALEUR APPORTEE

PAR LA QUALITE
ALIGNER LES STANDARDS ET LES PRATIQUES

SUR LES BESOINS CLIENTS
SURVEILLER LES PERFORMANCES VIS-A-VIS

DES STANDARDS ET PRATIQUES DE QUALITE
82

La mise en uvre du processus consiste, sur la base dune politique qualit en phase avec la stratgie SI dicte par le DSI, dfinir des objectifs
qualit et une organisation adapte pour sassurer de la qualit des produits et services de la DSI. Cette organisation, matrialise par un plan de
management de la qualit, doit sappuyer sur des procdures et standards
de ralisation des projets et services. Ce plan doit ensuite tre mis en
uvre et audit pour sassurer que lorganisation et les dispositions de
management de la qualit permettent datteindre les objectifs qualit
dfinis.
noter que les processus du domaine SE (Surveiller et valuer, voir chapitre 7), en particulier le processus SE1, sapparentent des processus de
contrle de la qualit, en regard de la dfinition du SMQ.
Mesures et contrles
La mesure de lefficacit de ce processus passe principalement par le suivi
des objectifs qualit, par exemple, le pourcentage de rduction des
dfauts, incidents et problmes rencontrs lors des activits de service de
la DSI. Dautres indicateurs peuvent complter cette mesure defficacit, tels
que le respect des dlais, le respect des cots des projets et des conventions
de service passs avec les directions mtiers.
La mesure de la mise en uvre de ce processus passe par le suivi du taux de
projets respectant les procdures et standards qualit, le taux de couverture
des audits internes et le pourcentage des processus faisant lobjet de revue.
Son rle est de dfinir la politique qualit et les objectifs qualit qui en
dcoulent. Il est le commanditaire des activits de contrle qualit (audits
qualit internes et revues de processus) et pilote ce processus, responsabilit quil peut toutefois dlguer son RAQ (responsable dassurance
qualit).
La lire qualit
Elle a pour mission daider la mise en uvre de la politique qualit et
datteindre les objectifs qualit conformment aux exigences des
mtiers.
Le responsable dassurance qualit
Il anime la filire qualit par dlgation du DSI et sassure que le processus PO8 est bien mis en uvre.
83
PO1, PO10, SE1
Tous
PO8 : Grer la qualit
Standards dacquisition
Standards de
dveloppement
Exigences de standards de
qualit et de mtriques
Actions pour lamlioration
de la qualit
Plan informatique
stratgique
Plans dtaills des projets
Plans dactions correctives
PO9
valuer et grer les risques
Les activits des entreprises sont de plus en plus dpendantes des

systmes dinformation, que ce soit au travers des applications ou
des infrastructures. Le souci de grer les risques qui en rsulte nest
pas nouveau. Sil est rig au niveau de lun des dix processus stratgiques de la gouvernance des SI, cest en particulier parce quil ncessite une vigilance constante qui ne peut pas tre du ressort des
oprationnels.
Le processus PO9 renvoie une exigence de prise en compte plus systmatique des risques par les processus mtier, au-del des systmes
dinformation grs par la DSI, ce qui nest pas toujours mis en uvre.
Ainsi, par exemple, une banque gre dun ct ses archives papier dans
les services et la DSI archive et sauvegarde les donnes applicatives correspondantes. Comment prendre en compte la conservation des donnes
sans tendre cette notion de matrise des risques au niveau global, sans se
limiter la DSI ?
84
Vue densemble
Le processus PO9 vise mettre en place une stratgie de rduction des risques cohrente avec la stratgie SI (alignement stratgique) afin de dvelopper une culture de gestion des risques. Il rpond ainsi aux exigences de
confidentialit, dintgrit et de disponibilit du SI vis--vis des mtiers.
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPORT DE
VALEUR
CONFIDENTIALITE
APPLICATIONS
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 4-25 : valuer et grer les risques : PO9
Pourquoi ?
Un risque se caractrise par sa fentre dapparition, sa probabilit doccurrence et son impact.
Repre : le risque
Trois lments pour le dcrire :
sa fentre dapparition (par exemple, la chute de neige nest pas envisage en
juillet) ;
sa probabilit doccurrence (il y a beaucoup de chance davoir du verglas en mars) ;
son impact (les avions ne pourront pas dcoller).
La combinaison des trois facteurs peut conduire au risque faible qui a des chances
de se produire souvent, au risque exceptionnel fort impact, ou toute autre combinaison.
Le processus de management des risques a pour rle de mettre sans cesse

en regard les risques qui se profilent et leur impact au niveau des mtiers.
Ceci ncessite une parfaite comprhension des dimensions mtier et de la
technologie afin danticiper et proposer les mesures de rduction de risques
les plus appropries.
85
tableau 4-9.
OBJ. 14
Protger tous les actifs1 informatiques et en tre comptable.
OBJ. 17
Protger latteinte des objectifs informatiques.
OBJ. 18
Montrer clairement les consquences pour lentreprise des risques lis aux objectifs et aux ressources informatiques.
1. Actif : tout lment reprsentant de la valeur pour lorganisme (ISO 27001).
Le processus PO9 couvre lensemble des principes relatifs la gestion

des risques et lvaluation des risques en termes financiers. Il est le
lien entre le management global des risques au niveau de lentreprise et
la DSI.
P09 Evaluer et grer les risques
DEFINIR
COMMUNIQUER
DEVELOPPER
LAPPETENCE
POUR LE RISQUE
DETERMINER LALIGNEMENT POUR LA GESTION DES RISQUES

Guide de
gestion des
risques
AMELIORER
DEFINIR LES PRATIQUES DE GESTION DES RISQUES
ET DE CONTROLE
TENIR A JOUR ET SURVEILLER UN PLAN

DACTIONS DE TRAITEMENT DES RISQUES
PLANIFIER LES ACTIVITES DE CONTROLE SELON LES PRIORITES

FAIRE
APPROUVER LES
PLANS DACTIONS
Plan
dactions
METTRE EN UVRE
EVALUER
IDENTIFIER LES EVENEMENTS IMPACTANT

LES OBJECTIFS METIER ET INFORMATIQUES
EVALUER LES RISQUES ASSOCIES

AUX EVENEMENTS
IDENTIFIER LE PROPRIETAIRE DU RISQUE

ET LES PROPRIETAIRES DES PROCESSUS CONCERNES
EVALUER LES REPONSES AUX RISQUES
ETABLIR LE CONTEXTE DE CHAQUE EVALUATION DE RISQUE
86

Si la matrise des risques renvoie tout dabord des dispositions classiques comme le plan de reprise dactivits (PRA), la sauvegarde des donnes ou, au niveau des mtiers, au plan de continuit des activits (PCA),
elle doit aller au-del en imposant la dfinition et la mise en uvre dune
mthodologie dvaluation des risques, llaboration dun plan de traitement
des risques adapt aux prjudices financiers encourus.
Beaucoup de risques gnriques seront traits travers les PRA et PCA
mais il existera toujours des alas qui feront merger des risques plus spcifiques, non prvus a priori. Citons, par exemple, la perte de comptence
stratgique suite au dpart de certaines ressources, les impacts dun projet
spcifique, des conditions climatiques inhabituelles, etc.
Plus gnralement, la DSI doit bien comprendre les objectifs stratgiques
des mtiers pour hirarchiser les risques quils encourent et apporter des
rponses appropries.
La mise en place dun systme de mangement de la scurit de linformation (SMSI) conforme la norme ISO/IEC 27001 est un moyen de rpondre
aux objectifs de contrle du processus PO9.
Mesures et contrles
La mesure de lefficacit de ce processus passe principalement par le pourcentage de rduction des incidents de scurit rencontrs lors des activits
de service de la DSI dus des risques non identifis.
La mesure de la mise en uvre de ce processus passe par le suivi du
nombre dactifs faisant lobjet de lanalyse des risques et dun plan de traitement des risques associ.
La mise en uvre du processus passe par la cration dune fonction en
charge du contrle interne et du management de la scurit au sein de la DSI.
Ceci renvoie la norme ISO/IEC 27001. noter que cette fonction ne saurait
se confondre avec la fonction de gestion de la scurit informatique au sens
technique, laquelle renvoie la norme ISO/IEC 17799 (ou ISO/IEC 27002).
Cependant, cette fonction ne suffit pas assurer le fonctionnement du processus PO9 qui doit galement sappuyer sur des instances transverses
incluant la direction gnrale, les directions mtiers et la direction financire.
La lire scurit et les risques informatiques

politique et les objectifs scurit et de gestion des risques informatiques
en ligne avec lanalyse des risques lis aux systmes dinformation.
87

Son rle est de sassurer de lvaluation des risques et de proposer une
rponse travers un projet de plan de traitement des risques.
La direction mtier
Son rle est de valider les rsultats de lvaluation des risques la concernant
et les rponses proposes par le projet de plan de traitement des risques.
La direction nancire
Son rle est dapprouver les rsultats de lvaluation des risques et les
rponses proposes dans le projet de plan de traitement des risques en fonction des prjudices financiers encourus, et den assurer le financement et le
suivi.

PO1, PO10, DS2, DS4,
DS5, SE1, SE4
PO1, PO4, PO6, DS4,

DS5, DS12, SE4, AI6
PO9 : Evaluer et grer les

risques

Plan de gestion des risques des
projets
Risques fournisseurs
Rsultats des tests des plans de
secours
Menaces et vulnrabilits de
scurit
Historique des vnements de
risque et des tendances
Apptence de lentreprise pour le
risque informatique
Evaluation des risques

Rapports sur les risques
Guides de gestion des
risques de linformatique
Plans dactions/solutions
risques informatiques
PO10
Grer les projets
Pourquoi tant de projets informatiques viennent-ils dfrayer la chronique ?

Certains analystes comme le Standish Group, estiment que plus de 25 % des
88
projets sont loin datteindre leurs objectifs ; dautres vont jusqu mettre en
avant quil faut rencontrer une bute (budget, dlais, qualit) pour provoquer
un lectrochoc qui fera sortir le projet de limpasse en substituant une gestion de projet inefficace une gestion de crise haut niveau.
.
De nombreuses causes sont voques lappui de ces constats. Les plus

courantes stigmatisent le manque de maturit des mtiers (la matrise
douvrage) ou invoquent la spcificit des projets informatiques, qui
sappuient sur des technologies en constante volution, pour expliquer les
drives et les dceptions. Au-del, quen est-il rellement des mthodes et
processus mis en uvre en matire de projets ?
Lapproche du processus PO10 consiste faire peser en interne la DSI
une exigence de professionnalisme qui stendra progressivement aux
acteurs concerns par les projets.
Vue densemble
Le processus PO10 sintresse principalement la bonne mise en place
dun rfrentiel de gestion de programme et de projet (application et
infrastructure) pour un bon alignement stratgique. Il rpond ainsi aux exigences defficacit et defficience du SI vis--vis des mtiers.
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
APPORT DE
VALEUR
EFFICIENCE
APPLICATIONS
CONFIDENTIALITE
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 4-28 : Grer les projets : PO10
Pourquoi ?
Une gestion en mode projet1 a souvent du mal coexister avec les modles
dorganisation hirarchiques et les modes de gestion quils impliquent.
Les projets sont bien souvent dcoups en activits affectes des entits
89
1. Un projet est par

dnition unique.
En informatique, il est
galement sujet des
alas (technologie,
besoins des mtiers).
Ainsi, on oppose le
mode projet au
mode processus.
Tout lenjeu consiste
rduire les incertitudes de la gestion
de projet sans
entrer dans un carcan inadapt.
homognes de lorganisation (dveloppements, tests, changements, etc.) sans

que le chanage des activits entre elles ne soit formalis et pilot. Il sagit
donc de donner une vision transverse et globale de lensemble des projets.
Par ailleurs, les mthodes observes sont des plus diverses, parfois artisanales, souvent dramatiquement absentes. Les fondamentaux font dfaut :
on oublie quun projet commence par une note de cadrage permettant aux
parties prenantes une vritable dcision de Go/No go qui doit ensuite tre
assortie dun plan projet dcoup en tapes, dun budget qui saffinera au
fil des tapes, dun cadre technique valid trs tt par lexploitation et,
enfin, dun travail de conception en troite relation avec les parties prenantes. Sur cet ensemble, il est ncessaire de greffer une supervision et un
pilotage des risques indpendants.
Question cl : quand dcider de faire un projet (Go/No go) ?
Un projet correspond une dcision dinvestissement. Il est recommand de runir
lensemble des lments de dcision dans une note de cadrage (cot, dlais, risques, avantages, retour sur investissement, etc.). Cette note servira tayer la dcision de lancer ou non le projet.
Le processus de management des projets synthtise cette approche pour

tous les projets de la DSI.
tableau 4-10.
OBJ. 01
Rpondre aux exigences mtier en accord avec la stratgie mtier.
OBJ. 02
Rpondre aux exigences de la gouvernance en accord avec les orientations du CA.
OBJ. 25
Livrer les projets temps et dans les limites budgtaires en respectant

les standards de qualit.
Le processus PO10 couvre lensemble des principes relatifs la gestion

des projets. Il est le point de passage entre lentreprise, que ce soit au travers des besoins des mtiers ou de la proccupation de gouvernance
densemble, et les projets mens au sein de la DSI. Ceci se traduit par un
90
rle dinterface, de contrle et de communication entre les parties prenantes

(hors DSI) et les projets.
Le processus PO10 est la vritable tour de contrle de lensemble des projets ayant la fois un rle de cadrage mthodologique et un rle trs oprationnel de pilotage, mesure et actions correctives. Ceci concerne aussi
bien les projets applicatifs que les infrastructures ou la maintenance applicative, en dautres termes, tout ce qui conduit des changements significatifs du systme dinformation.
Le processus PO10 tant un processus stratgique de haut niveau, il sintresse la fois au comment et au quoi . Le comment concerne les
rfrentiels et les mthodes qui seront dfinis, mis en uvre et rgulirement amliors pour conduire les projets. Le quoi se rapporte plus
spcifiquement aux projets et leur management oprationnel.
Les prrequis du processus PO10 sont ainsi la fois dordre stratgique
(quel portefeuille de projets ?), financier (pilotage des investissements),
relatif au dveloppement des ressources humaines (quelles comptences ?) et mthodologique (standards).
Cest un processus trs oprationnel dans son rle de pilotage global des
projets en cours, et trs mthodologique pour fixer aux projets un cadre
prcis permettant den optimiser les chances de succs.
DEFINIR
Portefeuille
projets
DEFINIR UN CADRE DE GESTION DE PROGRAMME
DEFINIR LES PROJETS DONT LES OBJECTIFS

SERVENT UN PROGRAMME
PLANIFIER CHAQUE PROJET
SELON LEUR PRIORITE ET LEUR CODEPENDANCE
Guides
de
gestion
DEFINIR UN CADRE DE GESTION DES PROJETS
COMMUNIQUER
AMELIORER
PRODUIRE UN RETOUR DEXPERIENCE
IMPLIQUER LES
PARTIES PRENANTES
AUX PROJETS
INFORMATIQUES
SUIVRE LES ACTIONS CORRECTIVES
CONTROLER
RAPPORTER LES RESULTATS

AUX PARTIES PRENANTES
ASSURER UN CONTROLE DU PROJET

ET DES CHANGEMENTS APPORTES
DEFINIR LE PERIMETRE DE GESTION DE PROJET
Rapport
Performance
DEFINIR UNE METHODOLOGIE DE GESTION DE PROJET

IDENTIFIER LA STRUCTURE DE GOUVERNANCE DES PROJETS
MESURER LA PERFORMANCE
DU PROJET
METTRE EN UVRE
Plans
projets
DEFINIR LES PROJETS INFORMATIQUES
METTRE EN PLACE UN SYSTEME DE

SURVEILLANCE ET DE MESURE
VERIFIER LA FOURNITURE
DES RESULTATS
ET BENEFICES PREVUS
DEFINIR LE PERIMETRE DES PROJETS
GERER LACHAT DE PRODUITS

ET DE SERVICES INFORMATIQUES
DEFINIR DES PLANS DE PROJETS

(planning, plan qualit, gestion des risques et des changements, etc.)
DEFINIR LES ROLES ET RESPONSABILITES
DES EQUIPES PROJET
GERER LES RISQUES

ET LES CHANGEMENTS
91
EVALUER LES CONSEQUENCES

DUN ECART SUR LE PROJET
ET SUR LE PROGRAMME

En ayant une vue globale des projets de la DSI et une faon homogne de
les grer, ce processus permet de vritablement matriser les projets sous
tous leurs aspects : mthode, avancement et risques. Il ne se substitue pas
aux processus de gestion de projet proprement dits ou au pilotage des
changements. Cest plutt une sorte de vision de synthse des projets de
la DSI, sous un angle stratgique (risques, cots, priorits), destine
dialoguer avec les parties prenantes.
Le pralable la mise en uvre du management des projets consiste
mettre en place une organisation avec une relle responsabilit du processus, puis dfinir le cadre de gestion des programmes et des projets.
Ce processus renvoie la fonction de Project Management Officer (PMO) qui
en est le responsable naturel au travers dune structure ad hoc (office des
projets).
Le schma du processus de la figure 4-29 met en vidence la fois une proccupation oprationnelle de pilotage de projets et le rle damlioration
constante des conditions mmes de conduite des projets.
Mesures et contrles
La mesure de lefficacit de ce processus passe principalement par le pourcentage de projets respectant les dlais, les cots et la qualit.
La mesure de la mise en uvre de ce processus passe par le pourcentage
de projets respectant le rfrentiel de gestion de projet (mthode, procdures, standards, etc.). Dautres indicateurs comme le nombre de projets
faisant lobjet de revue ou le taux de participation active des parties
prenantes peuvent tre suivis.
Son rle est de sassurer quun rfrentiel de gestion des projets et des
programmes est bien dfini et mis en uvre.
La direction mtier
Son rle est de sassurer quelle est bien associe la gestion des projets
et des programmes selon un cadre de gestion bien dfini.
Lofce des projets (PMO)
Son rle est de mettre en place les mcanismes de gestion des projets
(planning, plans qualit, budgets, risques, revues, etc.) et dassurer le
contrle des projets.
92

PO1, PO5, PO8, PO9,
AI1, AI2, AI3, AI4, AI5,
AI6, AI7, DS6, SE1
PO1, PO5, PO7, PO8,

AI7
PO10 : Grer les projets
Rapports sur la performance

des projets
Plan de gestion des risques des
projets
Guide de gestion des projets
Plans de projets dtaills
Portefeuille des projets

Tableau des comptences
informatiques
Standards de dveloppement
Revue post-dmarrage
En rsum
Le domaine PO dcrit les 10 processus stratgiques de la gouvernance des
systmes dinformation. Il sapplique aussi bien des DSI importantes
qu des DSI qui ont externalis la plupart de leurs projets ou de leurs
oprations.
On peut envisager de coupler CobiT dautres rfrentiels, mais ce
domaine PO restera incontournable.
93
Chapitre 5
Acqurir
et Implmenter
Les processus dcrits dans ce chapitre traitent de lidentification, du dveloppement ou de lacquisition des solutions informatiques, de leur mise
en uvre et de leur intgration aux processus mtier, ainsi que de la modification et de la maintenance des systmes existants.
AI1 Trouver des solutions informatiques
AI2 Acqurir des applications et en assurer la maintenance
AI3 Acqurir une infrastructure technique et en assurer la maintenance
AI4 Faciliter le fonctionnement et lutilisation
AI5 Acqurir des ressources informatiques
AI6 Grer les changements
AI7 Installer et valider des solutions et des modifications
AI1
Face un besoin exprim sur une nouvelle application ou sur une nouvelle
fonction, la DSI doit tre force de proposition. Ainsi, il convient tout
dabord danalyser la demande en se posant les bonnes questions.
Ce besoin exprim est-il compatible avec les impratifs stratgiques
mtier ?
Comment peut-il se traduire en termes de solutions informatiques ?
Comment sintgre-t-il dans le programme dinvestissement informatique ?
Peut-on sattendre un retour sur investissement ou une cration de
valeur significative ?
Autant de questions dterminantes pour entamer ou non la suite du processus
95
Si lentreprise dcide daller plus loin, les tapes suivantes consistent

dterminer un ventail de solutions, analyser leur faisabilit sur le plan
technique et leur viabilit sur le plan conomique. Lanalyse des risques et
le bilan conomique (ou rapport cot/bnfices des solutions envisages)
dterminent le choix final. Celui-ci, guid par des critres defficacit et de
rentabilit, conduit au type de solution retenu (faire ou acheter).
Minimiser les cots dachat et de mise en place de solutions constitue lun
des objectifs du processus AI1, tout en sassurant quelles permettront
lentreprise datteindre ses objectifs.
Vue densemble
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPORT DE
VALEUR
CONFIDENTIALITE
APPLICATIONS
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 5-1 : Vue densemble du processus AI1
Le processus AI1 est principalement la consquence du besoin de mettre

en place un dialogue avec les mtiers en vue de lancer les dveloppements
ncessaires lvolution des systmes informatiques (alignement stratgique et apport de valeur) qui rpondent au critre defficacit du systme
dinformation pour les mtiers.
Ce besoin amne les DSI simpliquer davantage dans la connaissance des
mtiers et piloter la contribution des systmes informatiques aux mtiers. Il
sagit de trouver des compromis entre lefficacit recherche par le mtier,
lefficience propre tout bon gestionnaire et une matrise des risques adapte.
Pourquoi ?
Il sagit de traduire les besoins fonctionnels de lentreprise en solutions
informatiques efficaces et efficientes. Ceci passe par des tudes de faisabilit, des business cases et un ventail de solutions permettant de dcider.
96
Chapitre 5 Acqurir et Implmenter
Cet exercice doit concilier les besoins et les exigences mtier actualiss,
leurs volutions futures mais galement lmergence de nouvelles technologies.
processus AI1 doit permettre de matriser les objectifs prsents dans le
tableau 5-1.
Tableau 5-1 : Objectifs du processus AI1
OBJ. 01
OBJ. 06
Dterminer comment traduire les exigences mtier de fonctionnement et de contrle en solutions

automatises efcaces et efcientes.
Le processus AI1 couvre les tapes de dfinition et de prise en compte dun

besoin jusqu la dcision finale qui aboutit un achat ou un dveloppement informatique.
La figure 5-2 reprsente les flux internes du processus AI1.
DEFINIR
DEFINIR LES EXIGENCES METIER
ET LES IMPERATIFS TECHNIQUES
DEFINIR LES RISQUES ASSOCIES AUX PROCESSUS METIER
COMMUNIQUER
EMETTRE DES
RECOMMANDATIONS
AU COMMANDITAIRE
METIER
FAIRE APPROUVER
LES ETUDES ET LES
SOLUTIONS PAR LE
COMMANDITAIRE
METIER
CONTROLER
EVALUER LES BENEFICES
INFORMATIQUES
DES SOLUTIONS PROPOSEES
Etude de
faisabilit
EVALUER LES BENEFICES METIER

DES SOLUTIONS PROPOSEES
Solutions/
Recommandations
METTRE EN UVRE
MENER UNE ETUDE DE FAISABILITE
POUR LA MISE EN PLACE DES EXIGENCES
GERER LINTEGRITE, LEXACTITUDE ET LACTUALITE
DES EXIGENCES METIER
METTRE EN PLACE UN PROCESSUS DAPPROBATION
DES EXIGENCES ET DES SOLUTIONS PROPOSEES
Figure 5-2 : Reprsentation schmatique des ux internes du processus AI1
97
EVALUER LES ALTERNATIVES

POSSIBLES

Toutes les exigences mtier, fonctionnelles et techniques, doivent tre
prises en compte et classes par priorit. Les solutions potentielles proposes en rponse ces exigences doivent tre identifies avant tout dveloppement ou acquisition. Le choix de la solution dfinitive est dict par
des critres de rentabilit, defficacit, de compatibilit, dergonomie, de
disponibilit, de continuit et dvolutivit, et galement de scurit.
En effet, lanalyse des risques, dment documente, permet didentifier au
plus tt les pistes de rduction de risques et ainsi de limiter les impacts
potentiels. Ces risques concernent les menaces sur lintgrit des donnes, la disponibilit, la scurit, le respect de la vie prive et la conformit
aux lois et rglements.
Tout choix dune solution doit tre conditionn par une tude de faisabilit
sur lensemble des solutions possibles (matrielles, logicielles ou de service). Cette analyse conforte la prise de dcision sur le choix de la solution.
La validation mtier est requise pour sassurer que ses exigences sont bien
comprises par linformatique avant accord de mise en place ou avant
achat.
Cette tape de validation est dautant plus importante que, conscients des
enjeux, les mtiers seront davantage impliqus pendant la mise en place.
Mesures et contrles
concernent la vrification des objectifs prsents dans le tableau 5-1. Ces
mesures portent principalement sur la satisfaction des mtiers quant aux
solutions proposes, en particulier le rapport cots/bnfices, la pertinence des tudes ralises en amont par rapport aux rsultats aprs
dploiement (ROI en particulier), lcart entre les spcifications initiales et
les changements demands en cours de projet.
le suivi du nombre dtudes de faisabilit et danalyse de risques ralises.
Plus gnralement, on vrifiera dans quelle mesure le processus de dcision
global est respect.
Le responsable mtier et le propritaire du processus mtier
ses exigences mtier, les risques et la faisabilit ont bien t tudis, et
que les bnfices des solutions proposes ont bien t valus afin de
pouvoir approuver la meilleure solution.
98

Le PMO met en uvre ce processus afin didentifier et dvaluer les diffrentes
solutions adaptes aux exigences mtier. Il est le pivot entre la DSI et les
mtiers ; il doit sa lgitimit sa comprhension intime des mtiers de lentreprise et sa capacit en rpercuter les priorits au sein de la DSI.
Son rle est de sassurer que toutes les activits de ce processus ont t
menes et que tous les acteurs concerns ont bien t impliqus afin que
les bnfices informatiques et mtiers des solutions prconises soient
bien valus.

PO1, PO 3, PO 8, PO10,
AI6, DS1, DS3
PO2, PO5, PO 7, AI2, AI3,

AI4, AI5
AI1 : Tr ouver des solutions

informatiques
Plans infor matiques str atgiques et

tactiques
Mises niveau r gulires de la
technologie
Standar ds technologiques
Standar ds dacquisition et de
dveloppement
Pr incipes de gestion des projets
Plans dtaills des pr ojets
Descr iption du pr ocessus de
changement
Contr ats de services
Plan per for mance et capacit
( exigences )
Etude de faisabilit des

exigences mtier
Figure 5-3 : Les entres-sorties du processus AI1
AI2
Acqurir des applications et en assurer

la maintenance
Lun des objectifs de la DSI est de livrer des applications en adquation

avec les besoins des mtiers, den matriser la maintenance et les volutions afin den assurer le fonctionnement et de procder aux adaptations
99
techniques et fonctionnelles (transformation ou remplacement) ncessaires pour saligner aux processus mtier.
Cet objectif se traduit par une succession dtapes, appele cycle de
dveloppement logiciel .
Aprs les tapes de dfinition du besoin, la traduction des exigences en
spcifications de dveloppement gnrales, dtailles et documentes,
prenant en compte les orientations technologiques et larchitecture de
linformation est essentielle. Une fois cette tape valide, le dveloppement
informatique commence.
Tout au long de cette tape, les mcanismes de dveloppement sont soumis
des principes tels que le respect des standards en matire de configuration
et darchitecture de linformation, la rdaction dun plan dassurance qualit,
la prsence de contrles et de validations, le respect des exigences de scurit (accs, donnes) et la mise en place de pistes daudit.
Une fois les dveloppements termins, tests, valids et mis en production, il
ne reste plus qu garantir la prennit du fonctionnement de lapplication
qui conduit, en dernier lieu, laborer un plan de maintenance.
Ce cycle de dveloppement est cependant perturb par larrive dvolutions tout au long du processus de dveloppement, impliquant de
reprendre tout ou partie des activits prcdemment menes pour intgrer
ces volutions.
Vue densemble
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPORT DE
VALEUR
CONFIDENTIALITE
APPLICATIONS
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Le processus AI2 rsulte principalement de la matrise des tapes du cycle

de vie dune application en vue de raliser les dveloppements applicatifs
100
conformes aux besoins des mtiers (alignement stratgique et apport de

valeur), qui rpondent principalement aux critres defficacit et defficience du systme dinformation.
Pourquoi ?
Les oublis ou les dfauts majeurs commis lors des tapes de conception
peuvent savrer prjudiciables et difficilement rattrapables durant les
dveloppements ou la phase de test, car ils entranent des retours en
arrire coteux. Ainsi, ces tapes sont essentielles pour garantir la qualit
des dveloppements futurs, en conformit avec les exigences mtier.
Le processus AI2 est une sorte de macroprocessus couvrant lensemble du
cycle de vie du dveloppement ou de lacquisition de logiciel. CobiT ne
rentre pas plus dans le dtail des mthodes de conception, de tests, de
gestion de projets, que dans la description des processus ncessaires
une bonne gestion du cycle de vie. En ce sens, ce processus mrite dtre
ensuite dtaill avec un rfrentiel plus spcialis et orient projet comme
PRINCE2, CMMI ou encore PMBOK.
tableau 5-2.
OBJ. 06
Dterminer comment traduire les exigences mtier de fonctionnement

et de contrle en solutions automatises efcaces et efcientes.
OBJ. 07
Acqurir et maintenir fonctionnels des systmes applicatifs intgrs et

standardiss.
Le processus AI2 couvre lensemble des tapes de dveloppement dune

application informatique jusqu celle consistant laborer un plan de
maintenance. Les tapes pralables de dfinition des besoins sont traites
par le processus AI1.
Le processus AI2 couvre cinq grandes tapes dans la conception et le dveloppement de solutions informatiques :
la conception gnrale ;
la conception dtaille ;
la rdaction du plan dassurance qualit ;
101
le dveloppement dapplication ;
la maintenance.
noter que ce processus est li au processus AI7 (voir section AI7 Installer et valider des solutions et des modifications de ce chapitre), qui
traite des tests et de la mise en production des applications ainsi que de
leurs volutions.
AI2 Acqurir des applications

Spcifications
de conception
gnrales
Spcifications
de conception
dtailles
COMMUNIQUER
FAIRE APPROUVER
LES SPECIFICATIONS
Spcifications
des contrles
de scurit
DEFINIR
TRADUIRE LES EXIGENCES METIER
EN SPECIFICATIONS DE CONCEPTION GENERALES
DETAILLER LES SPECIFICATIONS ET LES BESOINS TECHNIQUES
DEFINIR LES SPECIFICATIONS DES CONTROLES DE SECURITE
DES APPLICATIONS (sauvegarde, contrle daccs, etc.)
DEFINIR LE PROCESSUS DE DEVELOPPEMENT
DES APPLICATIONS
DEFINIR UN PLAN DASSURANCE QUALITE DES LOGICIELS
(processus de test, de vrification et de validation, etc.)
VALIDER CHAQUE
ETAPE CLE DU
DEVELOPPEMENT
METTRE EN UVRE
ADAPTER ET IMPLEMENTER
LES APPLICATIONS ACQUISES
CONTROLER
APPLIQUER LES CONTROLES
DE SECURITE DES APPLICATIONS
VERIFIER LA CONFORMITE DES
APPLICATIONS AUX SPECIFICATIONS
DE CONCEPTION, AUX STANDARDS DE
DEVELOPPEMENT ET AUX EXIGENCES
DE QUALITE
REEVALUER LA CONCEPTION
EN CAS DE MODIFICATIONS MAJEURES
GERER INDIVIDUELLEMENT CHAQUE EXIGENCE ET LEUR

NOUVELLE APPROBATION EN CAS DE MODIFICATION
ETABLIR UN PLAN STRATEGIQUE POUR LA MAINTENANCE
ET LES VERSIONS DAPPLICATIONS

La conception gnrale et la conception dtaille traduisant les exigences
mtier en spcifications gnrales et techniques doivent faire lobjet de
contrle et de consultation/validation plusieurs niveaux : coordination
des mtiers, architecture des donnes, dveloppement et exploitation
informatique.
Une conception gnrale de bonne qualit et bien documente est la
garantie que les exigences mtier seront correctement prises en compte.
Une bonne conception dtaille garantit une programmation et une maintenance dapplication terme plus faciles. Elle permet galement de
102
mettre laccent sur les priorits afin de livrer au final une application qui
satisfait aux conditions de rentabilit.
Paralllement, le plan dassurance qualit des logiciels ayant pour
objet de spcifier les critres de qualit et les processus de validation et
de vrification, dont les tests est aussi un document incontournable.
Ce plan fournit galement un cadre de travail pour le processus AI7
sintressant toutes les phases de tests, de recette, dinstallation et de
mise en production.
Dans ltape qui suit la phase de conception, la russite des dveloppements tient au respect des exigences formalises dans les documents de
conception, au respect du plan dassurance qualit, lintgration du systme en conformit larchitecture existante, la configuration standard
et la pertinence des tests.
Un mcanisme de contrle doit tre mis en place pour sassurer que les
rsultats des dveloppements rpondent aux exigences mtier et que la
confidentialit des donnes, lintgrit, la scurit et la disponibilit du
systme sont compatibles avec les processus mtier.
Ce processus concerne galement llaboration dun plan de maintenance
des applications, qui doit obir aux procdures de gestion du changement
en vigueur dans le cadre des volutions et aux procdures de gestion des
incidents en cas de dysfonctionnement.
Mesures et contrles
concernent le suivi du nombre de projets respectant les cots, la qualit,
les fonctions et les dlais. Ces mesures portent principalement sur la satisfaction des utilisateurs quant aux fonctionnalits proposes, en particulier
sur les bnfices apports dans le mtier.
le suivi du plan dassurance qualit de chaque projet applicatif.
Il sassure du bon droulement du projet en laborant le plan dassurance
qualit, conformment aux exigences auxquelles sont soumis les projets
applicatifs et en vrifiant que ses dispositions sont bien en uvre.
Le responsable dveloppements
Il est en charge de la ralisation des diffrentes tapes du projet applicatif.
Il sassure galement de la bonne collaboration des mtiers lorsque des
activits requirent leur validation.
103

PO2, PO 3, PO 5, PO8,
PO10, AI1, AI6
AI4, AI5, DS1, DS3, DS4,

DS5
AI2 : Acqur ir des

applications et en assurer la
maintenance
Dictionnair e de donnes
Schmas de classification des
donnes
Plan optimis des systmes mtier
Mises niveau rgulires de ltat
de lar t de la technologie
Comptes r endus cots/bnfices
Standar ds dacquisition et de
dveloppement
Guides de gestion des pr ojets
des mtier s
Description du processus de
changement
Spcification des contr les de

scur it des applications
Connaissance des applications
et des progiciels
Dcisions dacquisition
Contrats de services
initialement pr vus
Spcifications de disponibilit,
continuit et r eprise
AI3
Acqurir une infrastructure technique

Parmi les postes de dpenses informatiques les plus importants figurent

les investissements lis aux infrastructures, qui incluent les PC, les serveurs,
les imprimantes, les composants rseau, etc.
Face aux infrastructures ayant une dure de vie limite, il convient naturellement de disposer dune stratgie et dun plan de renouvellement, de
remise niveau ou de nouvelles acquisitions. Ce plan constitue une partie
du programme dinvestissement informatique et doit tre en ligne avec le
plan dinfrastructure technologique.
Le processus intgre un certain nombre doprations : la planification
dacquisition, la maintenance, les activits de protection et la mise en
place denvironnements de dveloppement et de tests relatifs linfrastructure.
Dans lintrt de lentreprise, il est en tout cas essentiel de prserver et de
prenniser le fonctionnement des infrastructures, considres comme
supports de logiciel ou comme transporteurs dinformation.
104
Vue densemble
Le processus AI3 rsulte principalement de la matrise des activits visant
acqurir et entretenir linfrastructure en ligne avec les stratgies et les
choix technologiques (gestion des ressources matrielles) qui rpondent
principalement au critre defficience du systme dinformation.
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPORT DE
VALEUR
CONFIDENTIALITE
APPLICATIONS
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Pourquoi ?
Compte tenu des implications budgtaires qui peuvent tre importantes et
en conformit avec le plan dinfrastructure technologique, le plan dacquisition dune infrastructure technique doit obligatoirement tre mis en place. Il
doit tre en phase avec le plan stratgique informatique, larchitecture de
linformation, les orientations technologiques et la stratgie dachat.
annexe 2, Objectifs du systme dinformation et processus CobiT ), le processus AI3 doit permettre de matriser les objectifs prsents dans le
tableau 5-3.
OBJ. 05
OBJ. 08
Acqurir et maintenir oprationnelle une infrastructure informatique

intgre et standardise.
OBJ. 15
105
Le processus AI3 couvre lensemble des oprations ncessaires pour

acqurir et maintenir les infrastructures informatiques. Il ne dveloppe pas
le processus dachat trait dans le processus AI5.
AI3 Acqurir une infrastructure technique

DEFINIR
DEFINIR UN PLAN DACQUISITION DES TECHNOLOGIES
DEFINIR LES MESURES DE CONTROLE ET DE SECURITE
AMELIORER
REVISER PERIODIQUEMENT LINFRASTRUCTURE
EN FONCTION DES EXIGENCES METIER ET DE SECURITE
Exigences de
lenvironnement
physique
Exigences de
surveillance des
systmes
CONTROLER
SUIVRE ET EVALUER LUTILISATION DES COMPOSANTS
DE LINFRASTRUCTURE SELON LEUR SENSIBILITE
METTRE EN UVRE
NEGOCIER LACQUISITION DE LINFRASTRUCTURE
AUPRES DE FOURNISSEURS AGREES
CONTROLER LES MODIFICATIONS CONFORMEMENT

A LA PROCEDURE DE GESTION DES CHANGEMENTS
FOURNIR DES ENVIRONNEMENTS DE TEST

DES APPLICATIONS ET DE LINFRASTRUCTURE
CONFIGURER LES COMPOSANTS DE LINFRASTRUCTURE
ETABLIR UNE STRATEGIE ET UN PLAN
POUR LA MAINTENANCE DE LINFRASTRUCTURE

Les facteurs risques techniques, cots de transition, dure de vie et viabilit du fournisseur sont considrer dans le plan dacquisition.
Les aspects protection et disponibilit des ressources de linfrastructure
doivent tre matriss. ce titre, des mesures de contrle internes doivent
tre prises pour valuer la robustesse de linfrastructure afin de protger la
confidentialit et lintgrit des donnes tous les niveaux.
Pour renforcer la scurit, et permettre lvolutivit, un plan de maintenance de linfrastructure est primordial. Contractuel, il doit inclure des
rvisions priodiques en fonction des besoins mtier et permettre des
remises niveau ou des remplacements de composants.
Dans le cadre de dveloppement et de test dapplications, il est fortement
recommand de disposer dune infrastructure ddie afin de dtecter des
erreurs et des problmes avant la mise en production.
106
Mesures et contrles
concernent le suivi de la capacit grer lobsolescence des infrastructures. Ceci passe par la mesure du respect des standards technologiques et
des procdures dacquisition.
Il est le garant des choix stratgiques concernant les infrastructures. Il en
dlgue la responsabilit oprationnelle au responsable exploitation.
Le responsable exploitation
Il est en charge de la bonne ralisation des diffrentes tapes dacquisition
des infrastructures dans le respect des procdures et des processus
dacquisition de lentreprise. Il sassure de la collaboration des responsables
architecture et administratif.

AI6, DS3
AI4, AI5, AI7, PO3, DS1,

DS3, DS12
AI3 : Acqurir une

infrastructure technique et
en assurer la maintenance
Plan dinfrastructure technique

Standards et opportunits
Mises niveau technique rgulires
Standards dacquisition et de
dveloppement
Principes gnraux de gestion des
projets
des mtiers
changement
Plan performance et capacit
(exigences)
Systme configur tester/installer
Exigences de lenvironnement
physique
Mises jour des standards techniques
Exigence de surveillance des
systmes
Connaissance de linfrastructure
Contrats dexploitation prvus
initialement
107
AI4
Faciliter le fonctionnement
et lutilisation
Il nest pas rare dentendre que les incidents ou les problmes remonts
par les utilisateurs et recenss par les services dassistance trouvent leurs
racines dans une mauvaise utilisation ou dans lignorance de la fonctionnalit dune application.
Partant de ce constat, on attribue parfois ce type de problme un manque
dinformation sur lutilisation de la fonctionnalit en question ou, plus
largement, une absence ou une lacune dans laccompagnement des utilisateurs (formation, documentation, prise en main).
Afin dassurer une bonne utilisation et un bon fonctionnement des applications et de linfrastructure, il est donc ncessaire de proposer des formations, de rdiger de la documentation et des manuels pour les utilisateurs
et linformatique.
Cest ce prix que lon peut esprer utiliser correctement la plupart des
fonctionnalits dune application.
Vue densemble
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPORT DE
VALEUR
CONFIDENTIALITE
APPLICATIONS
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 5-10 : Faciliter le fonctionnement et lutilisation : AI4
Le processus AI4 rsulte principalement de la matrise des activits

visant transfrer aux utilisateurs la connaissance ncessaire au bon
108
fonctionnement des systmes (applications et infrastructures) et une

contribution optimale aux mtiers (apport de valeur) qui rpondent
principalement aux critres defficacit et defficience du systme
dinformation.
Pourquoi ?
En principe, toute livraison dinfrastructure ou de systme doit tre
accompagne dune formation, dun guide dexploitation ou dun mode
opratoire. Il arrive que cette documentation ne soit pas suffisamment
complte, quelle soit obsolte ou gare ou que de nouveaux utilisateurs travaillent sur une application sans formation pralable. Dans
tous les cas, il faut mettre en uvre les solutions qui garantissent
la meilleure appropriation possible pour toute solution informatique.
tableau 5-4.
OBJ. 03
Sassurer de la satisfaction des utilisateurs naux lgard des offres

et des niveaux de services.
OBJ. 11
Sassurer de lintgration progressive des solutions informatiques aux

processus mtier.
OBJ. 13
Sassurer dune bonne utilisation et des bonnes performances des

applications et des solutions informatiques.
OBJ. 16
Rduire le nombre de dfauts et de retraitements touchant la fourniture de solutions et de services.
Le processus AI4 traite tous les aspects de la formation et de la prise

en main des applications. Le transfert de connaissance touche tous
les niveaux dutilisateurs : du secteur mtier au personnel informatique.
109
DEFINIR
DEFINIR UNE STRATEGIE POUR RENDRE
LA SOLUTION EXPLOITABLE
PLANIFIER LA PRODUCTION DE LA DOCUMENTATION
COMMUNIQUER
AMELIORER
AMELIORER LA DOCUMENTATION
SI NECESSAIRE
DEFINIR UNE METHODOLOGIE

DE TRANSFERT DES CONNAISSANCES
COMMUNIQUER AUX
UTILISATEURS
FINAUX
Manuels de
procdures
COMMUNIQUER AU
PERSONNEL DU
SUPPORT ET
AU PERSONNEL
DEXPLOITATION
Manuels
dexploitation,
dassistance
technique et
dadministration
CONTROLER
EVALUER LES RESULTATS
DE LA FORMATION
VERIFIER LA DISPONIBILITE,
LEXHAUSTIVITE ET LEXACTITUDE
DE LA DOCUMENTATION
METTRE EN UVRE
DEVELOPPER LA DOCUMENTATION
DE TRANSFERT DES CONNAISSANCES
PRODUIRE LES SUPPORTS
ET DISPENSER LA FORMATION

Le transfert de la connaissance sopre par diffrents canaux : la documentation, le manuel utilisateur, les manuels de procdures, laide en ligne, le
service support, la formation initiale et la formation permanente.
Il sadresse aux responsables mtier chargs de sapproprier le systme,
les donnes et les rgles de gestion qui sy rattachent. Il touche aussi les
utilisateurs finaux pour les rendre au plus vite oprationnels et pour optimiser leur efficacit. Des plans de formation plus cibls sur linterface
homme/machine sont prvus ce titre.
Le transfert des connaissances vers le personnel de lexploitation et du
support technique est galement indispensable pour obtenir la matrise
des outils mais aussi fournir un support efficace auprs des utilisateurs.
Il faut ensuite actualiser et diffuser aux parties prenantes ces documentations qui doivent contenir les informations utiles pour raliser ces tches
(procdures utilisateurs, de gestion, dexploitation). Outre lacte dappropriation quelle implique, la documentation est un support prcieux pour
mettre plus facilement niveau les systmes et les infrastructures.
Mesures et contrles
concernent le suivi des incidents causs par une mauvaise connaissance
110
des systmes et des applications, et du volume dassistance engag par le

support sous toutes ses formes (service dassistance, correspondant). Le
processus AI4 est susceptible dapporter rapidement une valeur tangible.
On peut en mesurer lefficacit et lefficience facilement (nombre dincidents, nombre dappels dutilisateurs insuffisamment forms, etc.).
le suivi du volume de formation des utilisateurs au dmarrage, du volume
de la documentation utilisateur propose et de la frquence de mise jour
de cette documentation.
Le propritaire du processus mtier
Il est responsable de la bonne ralisation de ce processus. ce titre, il en
est le pilote et est en charge de la diffusion des lments de transfert de
connaissance aux utilisateurs.
Les responsables exploitation et dveloppements
Ils sont responsables de la bonne ralisation des diffrentes tapes de production de la documentation et des actions de formation/communication
pour les utilisateurs.

PO10, AI1, AI2, AI3,
AI7, DS7
AI7, DS4, DS7, DS8, DS9,

DS11, DS13
AI4 : Faciliter le
fonctionnement et
lutilisation

projets
des mtiers
Connaissance de lapplication et de
la suite logiciellle
Connaissance de linfrastructure
Erreurs connues et acceptes
Mises jour de la documentation
requise
Manuels utilisateur, dexploitation,

dassistance, technique et
dadministration
Exigences de transfert de
connaissances pour la mise en
place dune solution
Supports de formation
111
AI5
Acqurir des ressources informatiques
Lacquisition de ressources informatiques englobe le personnel, les services, le matriel et les logiciels. Un processus gnral dacquisition
informatique doit tre dfini et appliqu afin de fournir lentreprise
toutes les ressources informatiques requises en temps voulu et au
meilleur cot.
Le processus comprend les procdures dachats, la slection des fournisseurs, la gestion des relations contractuelles avec les tiers, et fixe les
conditions dacquisition des ressources.
Lobjectif est de dfinir une politique dachat informatique compatible
avec les plans stratgiques, tactiques et le programme dinvestissement
informatique. Celle-ci vise la prise en compte des exigences mtier travers lapport de nouveaux systmes, le dveloppement des infrastructures
et lacquisition des comptences.
Cette politique conduit faire des achats contrls visant ou prservant
les intrts de lentreprise. Elle doit aussi mener vers plus de transparence
dans les relations avec le fournisseur.
Vue densemble
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPORT DE
VALEUR
CONFIDENTIALITE
APPLICATIONS
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 5-13 : Acqurir des ressources informatiques : AI5
Le processus AI5 rsulte principalement du besoin de matrise de la gestion de toutes les ressources du systme dinformation (applications,
112
informations, infrastructures et personnes) pour une contribution optimale aux mtiers (apport de valeur) qui rpondent principalement aux
critres defficacit et defficience du systme dinformation.
En cas dexternalisation des activits (lexploitation notamment), la matrise des risques doit tre assure de bout en bout. Ceci ncessite que le
fournisseur soit averti de toutes les exigences lies la scurit quil doit
prendre en compte.
Pourquoi ?
Une gestion efficace des achats permet la fois de faire des conomies,
de rduire les risques lis aux tiers et de se conformer aux dispositions
lgales. Le processus dacquisition de ressources informatiques prcise
les tapes de contrle et de validation en relation avec le service achats :
la stratgie achat SI, la dcision finale dans le choix du fournisseur, la
ngociation des modalits dacquisition avec le fournisseur, la partie
gestion des contrats fournisseurs vue sous langle achat et la relation
fournisseur.
tableau 5-5.
OBJ. 07
Acqurir et maintenir fonctionnels des systmes applicatifs intgrs

et standardiss.
OBJ. 08
Acqurir et maintenir oprationnelle une infrastructure informatique

intgre et standardise.
OBJ. 09
Se procurer et conserver les comptences ncessaires la mise en

uvre de la stratgie informatique.
OBJ. 24
Le processus AI5 dcline les grands thmes de la politique dachat

informatique. Il doit sintgrer dans le processus dachat gnralis au
sein de lentreprise car il demande une forte intervention du service
achats.
113
DEFINIR
DEFINIR DES PROCEDURES ET DES STANDARDS DACQUISITION
DEFINIR UNE PROCEDURE DE GESTION
DES CONTRATS FOURNISSEURS
CONTROLER
Exigences de
gestion des
relations avec
les tiers
SASSURER QUE LES INTERETS DE LENTREPRISE SONT

PROTEGES DANS LES ACCORDS CONTRACTUELS
SASSURER DU RESPECT DES PROCEDURES
DACQUISITION ETABLIES
METTRE EN UVRE
ETABLIR UNE LISTE DE FOURNISSEURS ACCREDITES
Accords
contractuels
dacquisition
EVALUER ET SELECTIONNER LES FOURNISSEURS
REDIGER DES CONTRATS DACQUISITION (logiciels,

ressources de dveloppement, infrastructure et quipements)

Ce processus instaure une coopration entre linformatique et le service
achats.
En amont de lachat proprement dit, les intresss vont segmenter le
domaine informatique pour recenser les tiers ligibles (infogrants, diteurs, prestataires de services, constructeurs, conseils, etc.). Pour chaque
segment, ils dresseront une liste de fournisseurs consulter dans le cadre
des appels doffre. Des contrats cadres sont ngocis (prix par unit
duvre, rductions) ; cela peut conduire un rfrencement des fournisseurs
accrdits.
La DSI doit tablir les spcifications dachat dcrivant toutes les exigences
applicables au produit ou service demand (descriptif du produit ou service demand, documentation associe, exigences qualit et scurit
applicables).
Au cas par cas, le choix dun fournisseur est gnralement une dcision
prise conjointement avec lacheteur. Les rgles du jeu sont dictes de
faon garantir la traabilit des tapes, du cahier des charges au choix, en
passant par le dpouillement des offres et leur analyse. La procdure de
slection est transparente ; elle note les offres selon les critres tablis
(qualit de la proposition, capacits mettre en uvre la solution, prix,
114
etc.). La ngociation finale seffectue en principe avec le service informatique sur les aspects techniques de la proposition, et avec le service achats
en ce qui concerne les aspects financiers et les clauses dacquisition.
En plus de lacheteur, la DSI doit aussi travailler en troite collaboration
avec un conseiller juridique pour la mise au point dun contrat. En dehors
de lobjet et des modalits laccompagnant, le contrat ne doit pas omettre
des clauses concernant les responsabilits lgales, financires et civiles, la
proprit intellectuelle, les licences, la scurit, les conditions de rsiliation du contrat, les garanties, les pnalits et les mcanismes dvolution
qui influencent les prix (units duvre, travaux supplmentaires).
Le mtier sera aussi associ au processus dacquisition lorsquil est concern
(dveloppements applicatifs, assistance la matrise douvrage).
La gestion des contrats fournisseurs permet de dfinir des objectifs de performance et damlioration sur la dure (voir chapitre 6, section DS2
Grer les services tiers ). Par exemple, le fournisseur peut apporter une
contribution continue la qualit du service offert travers un SLA1 (Service
Level Agreement). Lacquisition de logiciel, de ressources de dveloppement,
dinfrastructure, damnagements dquipements et de services qui leurs
sont lis, doit saccompagner de garanties obligatoires permettant une
fourniture de systmes fonctionnant comme attendus, rsistants aux
pannes et permettant une gestion efficace des incidents.
Mesures et contrles
AI5 concernent le suivi du pourcentage dachats conformes aux procdures
et aux politiques dacquisition.
le suivi du dlai de traitement des achats.
Il est responsable de la bonne ralisation de ce processus et, ce titre, il
en est le pilote. Ds que la DSI devient importante, on nomme un correspondant achats de linformatique qui centralise la relation avec le service
achats.
Les responsables exploitation, dveloppements

et administratif des SI
Ils sont en charge de la bonne ralisation des diffrentes tapes du processus achats au sein de la DSI. En gnral, ils interviennent en binme
115
1. La ngociation dun
contrat de services
aboutit un niveau de
service contractualis
(ou SLA, Service Level
Agreement). Latteinte
de ce niveau de service
et son amlioration
peuvent tre intgres
dans les contrats
conclus avec les tiers.
avec lacheteur, chacun avec sa spcialit, en fonction des domaines

concerns.

AI2, AI3, DS2
DS2, AI7
AI5 : Acqurir des

ressources informatiques
Stratgie dachats informatiques

projets
des mtiers
Catalogue fournisseurs
Exigences de gestion des relations

avec les tiers
Articles achets
Accords contractuels
AI6
Grer les changements
Dans le cadre de la maintenance volutive ou corrective des applications,

de lenvironnement de production, des services et des infrastructures, les
DSI doivent faire preuve de rigueur et de ractivit pour dployer les applications, les logiciels ou les corrections qui simposent.
Le circuit de dcision, ainsi que lensemble des procdures qui en dcoulent, dpend dun processus formalis dit de gestion du changement. Ce
dernier offre un cadre de contrle qui permet le suivi de la demande de
changement ou de correction, de sa cration jusqu sa clture. Il sappuie
sur une gestion trs stricte du planning et ncessite une trs bonne coordination avec la gestion de la configuration (voir chapitre 6, section DS9
Grer la configuration ).
Tout changement incluant procdures, processus, paramtres systmes
et services doit tre enregistr dans un fichier. Son impact doit tre
valu, sa mise en place autorise et ses effets en production suivis. Le
demandeur doit tre videmment inform du statut de sa demande.
116
Vue densemble
Le processus AI6 rsulte principalement du besoin de matrise de tous
les composants en production du systme dinformation (gestion des
ressources) pour ragir aux volutions des besoins des mtiers (apport
de valeur) qui rpondent principalement aux critres defficacit, defficience, de disponibilit et dintgrit du systme dinformation.
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPORT DE
VALEUR
CONFIDENTIALITE
APPLICATIONS
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 5-16 : Grer les changements : AI6
Pourquoi ?
La gestion des changements est un processus crucial pour limiter
les risques dinstabilit de lenvironnement de production. Ce processus contribue une responsabilisation accrue de lutilisateur qui
doit canaliser ses demandes et une meilleure organisation au sein de
linformatique qui doit les traiter. Il pose aussi des principes de transparence dans les relations entre les parties prenantes mtier et informatiques.
Comme beaucoup de processus en liaison avec lexploitation, le processus
AI6 est frquemment partag avec des tiers (infogrants, exploitants), ce
qui accrot encore la ncessit de le rendre efficace et transparent.
117

tableau 5-6.
OBJ. 01
OBJ. 06
Dterminer comment traduire les exigences mtier de fonctionnement et de contrle en solutions

OBJ. 16
Rduire le nombre de dfauts et de retraitements touchant la fourniture de solutions et de

services.
OBJ. 22
Sassurer quun incident ou une modication dans la fourniture dun service informatique na
quun impact minimum sur lactivit.
OBJ. 26
Maintenir lintgrit de linformation et de linfrastructure de traitement.
Le processus AI6 couvre lensemble des tapes de gestion du changement

dans le cadre du dploiement, de la maintenance corrective et volutive. Il
traite aussi bien les changements planifis en accord avec les exigences
mtier que les corrections apporter dans lurgence.
DEFINIR
DEFINIR LES PROCEDURES DE GESTION DES CHANGEMENTS
(y compris les modifications et les correctifs durgence)
AMELIORER
METTRE A JOUR LES SYSTEMES,
LA DOCUMENTATION UTILISATEUR
ET LES PROCEDURES
COMMUNIQUER
METTRE EN UVRE
OBTENIR
LAUTORISATION DE
MISE EN UVRE
ENREGISTRER LES DEMANDES DE CHANGEMENTS
CONTROLER
EVALUER LIMPACT DES CHANGEMENTS

SUR LE SYSTEME EN EXPLOITATION
SASSURER QUE TOUTE

MODIFICATION EST EVALUEE
ET AUTORISEE
FAIRE CONNAITRE
LES MODIFICATIONS
APPORTEES
CLASSER LES DEMANDES DE CHANGEMENTS PAR PRIORITE

APPLIQUER LES CHANGEMENTS AUTORISES
A LINFRASTRUCTURE ET AUX APPLICATIONS
118
SUIVRE LES CHANGEMENTS

ET VERIFIER LEUR CLOTURE

Le processus de gestion des changements vise essentiellement grer les
priorits dans les mises en service, en rduisant les risques dinstabilit
des installations et des applications. Pour atteindre cet objectif, il doit
revtir un caractre industriel (planification rigoureuse, procdures
strictes) et appliquer des standards.
Afin de traiter les demandes dvolution de faon rigoureuse, il est ncessaire de mettre en place une organisation adapte, qui gre ces
demandes de faon standardise au moyen de procdures formelles.
Service dassistance, comits statuant sur les volutions ou autres instances de rvision sont les supports et les canaux essentiels dans la gestion
des changements.
Plutt que davoir une position rigide sur la planification des changements, il est conseill de mettre en place galement un processus des
changements dans lurgence (patchs, correctifs) afin de traiter les actions
correctives urgentes.
Les demandes dvolution et de rsolution derreur reues au niveau du
service dassistance ncessitent une analyse rapide. Aprs enregistrement,
ces demandes sont classes par priorit ou par catgorie, selon des procdures dfinies. Un statut leur est alors affect, puis la demande est transmise aux services techniques pour traitement et valuation des impacts
sur le systme en exploitation et sur ses fonctionnalits. Une fois la
demande traite, il est essentiel, avant la mise en production, de se mettre
en rapport avec la partie prenante concerne.
Tout au long du cycle de vie dune demande, il est important dappliquer
un systme de suivi et de reporting pour informer les demandeurs de lvolution du statut de leur requte et des dlais de mise en uvre.
Aprs chaque changement, un processus de revue doit tre dclench pour
sassurer que la mise en place des changements ne dgrade pas le systme
dinformation.
Mesures et contrles
concernent le suivi du pourcentage de changements qui ont gnr des
incidents.
le suivi des changements ne respectant pas le circuit formel.
119
Il doit sassurer que ce processus est bien mis en place et que le reporting
des changements est oprationnel. Ce processus est un maillon cl dans
lamlioration du fonctionnement global de la DSI. Il sert en particulier
rguler et organiser les flux de nouveauts en production.
Il est en charge de la bonne ralisation de ce processus et, ce titre, il en
est le pilote. En collaboration avec les responsables dveloppements et
mtiers, il sassure que les changements sont bien matriss.
Il participe toutes les tapes du traitement des changements relatifs aux
applications.

PO1, PO8, PO9,
PO10, DS3, DS5,
DS8, DS9, DS10
AI1, AI2, AI3, AI7, SE1,

DS8, DS10
AI6 : Grer les

changements
Portefeuille de projets informatiques

Actions pour lamlioration de la
qualit
Plans dactions pour remdier aux
risques informatiques
projets
Changements demands
Changements de scurit
demands
Demande de service /demande de
changement
Historique des problmes
changement
Rapport sur le statut des changements
Autorisation de changement
120
AI7
Installer et valider des solutions

et des modifications
Cest aprs une dcision dfinitive que tout nouveau systme peut tre
lgitimement mis en exploitation. Derrire cette dcision lourde de consquence, se cache un ensemble de tches importantes, planifies et ralises lors de la phase de dveloppement.
Lors de cette phase, certaines tches demeurent incontournables, telles que
llaboration dun programme de tests dans un environnement ddi impliquant les parties prenantes mtier et informatiques, un planning de recettes
et de formation ainsi quun plan dimplmentation contenant les instructions
de dploiement, de migration et le calendrier de mise en production.
Chaque tape est fondamentale et doit tre valide au fur et mesure pour
assurer le succs dans la mise en place et lutilisation prenne des systmes oprationnels.
Des revues aprs mise en place peuvent suivre pour offrir une visibilit sur
les rsultats attendus, et ainsi permettre dagir en consquence.
Vue densemble
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPORT DE
VALEUR
CONFIDENTIALITE
APPLICATIONS
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 5-19 : Installer et valider des solutions et des modications : AI7
Le processus AI7 rsulte principalement du besoin de sassurer que seules

les solutions valides du systme dinformation seront installes afin de
bien rpondre aux attentes des mtiers (apport de valeur) en respectant
principalement le critre defficacit du systme dinformation.
121
Pourquoi ?
La phase de test est une tape critique qui conditionne la russite des projets. Souvent mis sous la pression de lurgence, le responsable des tests
doit tre ferme pour viter de ngliger cette tape. Cest pourquoi, il est
fondamental de dfinir et de piloter ce processus, ce qui permettra de
suivre la qualit de la fin du cycle de vie du dveloppement des logiciels.
Ltape de mise en exploitation est dlicate et ncessite une documentation prcise et complte. Quel que soit le nom quon lui donne (plan
dimplmentation, dossier dexploitation ou guide dinstallation), il est
ncessaire de disposer dun document qui fournit une description des
procdures de dploiement, dinstallation, de gestion des incidents, du
stockage du logiciel, des modifications effectues entre deux versions et
des solutions de remplacement ou de retour en arrire.
tableau 5-7.
OBJ. 01
OBJ. 11
Sassurer de lintgration progressive des solutions informatiques aux

processus mtier.
OBJ. 13
Sassurer dune bonne utilisation et des bonnes performances des

applications et des solutions informatiques.
OBJ. 16
OBJ. 20
Sassurer que les transactions mtier automatises et les changes

dinformations sont ables.
OBJ. 21
Sassurer que les services et linfrastructure informatique peuvent rsister/se rtablir convenablement en cas de panne due une erreur,
une attaque dlibre ou un sinistre.
Le processus AI7 complte les tapes de conception et de dveloppement

dfinies dans le processus AI2. Laccent est surtout mis sur les aspects de
tests, de prparation et de validation de la mise en production.
122
DEFINIR
AI7 Installer et valider

les solutions et les modifications
Plan
dimplmentation
COMMUNIQUER
Programme
de tests
CONCEVOIR UN PLAN DIMPLEMENTATION

DEFINIR UNE STRATEGIE DE TESTS
DETERMINER
LALIGNEMENT POUR
LA GESTIONDE
DES
RISQUE
S
ET UNE METHODOLOGIE
DE PROGRAMME
TEST
S
CONTROLER
OBTENIR
LAPPROBATION
DES PARTIES
CONCERNEES
FAIRE VERIFIER LE FONCTIONNEMENT INITIAL DU

NOUVEAU SYSTEME PAR SES PROPRIETAIRES
METTRE EN UVRE
METTRE EN PLACE UN ENVIRONNEMENT DE TEST
REPRESENTATIF DE LENVIRONNEMENT DE PRODUCTION
CONTROLER LA MISE EN PRODUCTION
EFFECTUER DES REVUES POST-DEMARRAGE
REALISER DES TESTS DINTEGRATION ET DE CONVERSION

SYSTEME SUR LENVIRONNEMENT DE TEST
Rsultats
des tests
CONDUIRE DES TESTS DE MODIFICATIONS

ET DES TESTS DE RECETTE DEFINITIVE
RECOMMANDER LE TRANSFERT EN PRODUCTION
SELON LES CRITERES DE VALIDATION APPROUVES

La qualit dun programme de tests reste primordiale, dans la mesure o
elle est lune des cls du succs de la mise en production de la solution
informatique.
Les tests contribuent faire valider la solution par les parties prenantes.
Ils minimisent les risques de panne du systme en environnement de
production provoquant des incidences ngatives sur lactivit. Ils permettent galement aux parties prenantes de se familiariser avec le nouveau systme. En cas de succs, la phase de test se termine par une recette
(acceptation).
Ces tests de recette touchent aussi bien la scurit et la performance que
les aspects fonctionnels des composantes du systme dinformation
(applications, infrastructures, technologie et procdures utilisateurs).
Leurs rsultats devront tre conservs et documents afin de servir de
pistes daudit.
Pour crer, en phase de test, des conditions similaires celles de la phase
de production, il faut concevoir un environnement de tests avec des donnes reprsentatives de celles utilises en production. Des tests de conversion des systmes et des donnes sont indispensables dans le cas du
123
passage dune version dun logiciel une autre, ou dune application une
autre.
La migration des donnes fait lobjet dun processus part entire au sein
du processus AI7.
Aprs les tests de modifications et de recette dfinitive, le transfert en production doit tre ralis selon un calendrier bien tabli.
Le passage du systme de lenvironnement de dveloppement et de tests
celui de la production exige de grandes prcautions. Il demande lautorisation du propritaire du systme qui a lassurance que le nouveau sera mis
en production aprs dsactivation de lancien.
Mesures et contrles
concernent le suivi du pourcentage dincidents qui ont suivi la validation
des solutions installes ainsi que la satisfaction des mtiers. On sattachera aussi identifier les causes des carts (jeu de test inadquat, changement de spcification, donnes inexactes).
le suivi de ralisation des activits de ce celui-ci, conformment au plan
dassurance qualit de la solution ( travers les audits et les inspections
mens).
Il est responsable de la dcision de mise en production ; il est le client de ce
processus. En gnral, les projets informatiques sont plutt en retard et les
mtiers poussent ce que la mise en production intervienne au plus vite. Le
responsable du processus doit donc prendre le risque de mettre en service
une solution insuffisamment teste ou incomplte fonctionnellement.

Il doit vrifier que ce processus est bien mis en place et que toutes les parties prenantes sont bien impliques. Il en est le pilote et sassure que les
mtiers pourront dcider convenablement de la mise en production.
Il doit fournir lenvironnement de tests appropri et raliser les tests
techniques. Il travaille en collaboration avec le responsable dveloppements
et le propritaire processus mtier.
124
Il est en charge de la spcification des tests et de leur ralisation, en particulier en ce qui concerne les tests applicatifs.

PO3, PO4, PO8,
PO10, AI3, AI4, AI5,
AI6

DS2, DS9, DS13
AI7 : Installer et valider

les solutions et les
modifications
Standards technologiques
Documentation sur les propritaires
des processus
Standards de dveloppement
Guides de gestion des projets
Systme configur tester /
installer
Manuel utilisateur, dexploitation,
dadministration
Articles achets
Elments de configuration mis

disposition
Erreurs connues et acceptes
Mises en production
Plan de publication et de diffusion de
logiciel
Revue post-dmarrage
En rsum
Le domaine AI couvre lensemble des projets, applicatifs ou infrastructures, lensemble des correctifs et, en bref, tout changement intervenant
sur le primtre des systmes dinformation. Il sapparente au chapitre
Service Transition du rfrentiel ITIL V3.
Certains trouveront que le pilotage des projets proprement parler ny figure
pas. Il est vrai que le processus AI2, qui couvre la fois le dveloppement et
la maintenance dapplications, mrite dtre dtaill. Cest ce niveau quil
faut coupler les mthodes de gestion de projet qui existent par ailleurs.
En revanche, ce domaine a le mrite de dcrire des processus qui sont trop
souvent ignors, tel le processus AI4 (faciliter le fonctionnement et lutilisation), ou ngligs, tels que les processus AI1 (dcision de faire ou non)
et AI6/7 (gestion des changements, tests et mise en production).
125
Chapitre 6
Dlivrer
et Supporter
Ce domaine concerne la mise en uvre des services : exploitation informatique, gestion de la scurit, gestion de la continuit de service, assistance
aux utilisateurs, gestion des donnes et des quipements.
DS1 Dfinir et grer les niveaux de services
DS8 Grer le service dassistance aux clients et les incidents
DS1
Dfinir et grer les niveaux de services
Le premier processus du domaine Dlivrer et Supporter (DS) concerne la

relation avec les bnficiaires des services. Limportance donne ce processus, au moins dans lnumration, reflte une conception trs anglosaxonne des services, base sur une forme souple de contractualisation.
En dautres termes, il ny a fourniture dun service que dans un cadre
127
dfinissant en particulier les engagements souscrits, lequel servira en

mesurer la qualit et lefficience. La notion de service rendu ne prend donc
sens que face un engagement des parties.
Cette notion de niveau de service renvoie un vocabulaire anglais prcis :
on parle de SLR (Service Level Requirement) pour qualifier la demande des
mtiers et de SLA (Service Level Agreement) pour les niveaux de services ngocis entre les parties. Ce distinguo tablit la ncessit de trouver des compromis entre les demandes et les termes de laccord. Autrement dit, les
mtiers ne peuvent pas imposer leurs exigences sans ngociation. On
parle ensuite de contrat de services (CS) et de contrat dexploitation (CE).
Les niveaux de services prcisent non seulement la qualit du service
rendu (par exemple, 80 % des appels au centre dassistance sont rsolus en
moins de 4 heures) mais aussi la capacit prvoir (par exemple, moins de
3 000 appels/jour).
Vue densemble
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPORT DE
VALEUR
CONFIDENTIALITE
APPLICATIONS
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 6-1 : Dnir et grer les niveaux de services : DS1
Ce processus est un pivot de la gouvernance SI travers la relation avec les

mtiers, voire avec les clients de lentreprise eux-mmes. Il pse sur lalignement stratgique et lapport de valeur, la mesure de la performance et
lajustement des ressources. En dautres termes, le niveau de service, ds
lors quil a t ngoci et accept, devrait dicter une bonne part de lorientation de la DSI.
En termes dexigences sur les mtiers SI, la gestion des services renvoie
principalement lefficacit et lefficience.
128
Chapitre 6 Dlivrer et Supporter
Pourquoi ?
Les DSI se demandent parfois quel est lintrt de mettre en place une gestion de niveaux de services alors mme que les clients, utilisateurs et responsables mtier, sen dsintressent. Ce dsintrt apparent masque
souvent une exigence absolue qui leur vite une discussion perue comme
un compromis ce qui semble leur tre d.
La ngociation, puis la gestion des niveaux de services, signe donc une
sorte de maturit de la relation entre mtiers et DSI. La communication
qui en rsulte sera la base dune meilleure comprhension mutuelle, que
ce soit des enjeux mtier ou des contraintes pesant sur le SI.
Enfin, cette rgulation des services de la DSI par la demande est lune des
conditions dune bonne gouvernance, que ce soit en termes de qualit, de
cots ou de ressources.
processus DS1 doit permettre de matriser les objectifs prsents dans le
tableau 6-1.
Tableau 6-1 : Objectifs du processus DS1
OBJ. 01
OBJ. 03
Sassurer de la satisfaction des utilisateurs naux lgard des

offres et des niveaux de services.
OBJ. 12
Sassurer de la transparence et de la bonne comprhension des

cots, bnces, stratgie, politiques et niveaux de services des SI.
Notons que le pige le plus courant consiste parler de satisfaction des

utilisateurs sans y associer les offres et niveaux de services. Un des travers
les plus classiques consiste mesurer une satisfaction avant mme de
savoir pour quel service la DSI et son correspondant se sont mis daccord.
Lensemble des activits de la DSI est concern par les niveaux de services ;
les objectifs de performance internes la DSI doivent donc tre aligns aux
niveaux de services ngocis. ITIL distingue soigneusement les niveaux de
services entre entits de la DSI (OLA, pour Operation Level Agreement), des
niveaux de services contractualiss avec des tiers (UC, pour Underpinning
Contract), lensemble de la chane des services tant soumise au SLA (niveau
de service contractualis avec le client). Cette vision a le mrite de dtailler
chaque activit concourant un rsultat, mais risque de conduire un pilotage morcel alors que le client ne sintresse quau rsultat du SLA.
129
La figure 6-2 reprsente les flux internes du processus DS1.
DEFINIR
DEFINIR UN CADRE DE REFERENCE
POUR LA GESTION DES NIVEAUX DE SERVICES
COMMUNIQUER
ETABLIR UN
ACCORD COMMUN
SUR LE NIVEAU
DE SERVICE
EXIGE
Portefeuille
des services
informatiques
METTRE EN UVRE
ELABORER UN CATALOGUE/PORTEFEUILLE
DES SERVICES INFORMATIQUES
FORMALISER LES CNS
(disponibilit, fiabilit, niveau dassistance, etc.)
RENDRE COMPTE
AUX PARTIES
PRENANTES DES
NIVEAUX DE
SERVICES
ATTEINTS
AMELIORER
CRER UN PLAN DAMELIORATION
FORMALISER LES CNO QUI SOUTIENNENT LES CNS
CONTROLER
SURVEILLER EN PERMANENCE LA PERFORMANCE
DES NIVEAUX DE SERVICES
FAIRE UNE REVUE DES CNS ET DES CONTRATS ASSOCIES
REVOIR ET METTRE A JOUR LE CATALOGUE DE SERVICES
Figure 6-2 : Reprsentation schmatique des ux internes du processus DS1

Comme tous les services de support aux mtiers, la DSI travaille pour
ses clients internes, et une bonne communication est le pralable la
mise en uvre dun cadre de ngociation des niveaux de services.
Le processus de contractualisation passe par une phase dexpression
des besoins de la part des mtiers conduisant aux niveaux de services
aprs ngociation. Le processus se trouverait trs inoprant si on confondait le niveau de service demand (SLR) et le niveau ngoci (SLA). Pour
aborder cette ngociation, il est conseill de sarmer dun historique des
performances observes dans le domaine concern. Cest en particulier le
cas pour les centres de services dont la performance dpend beaucoup de
lampleur de la sollicitation. Un centre dappel prvu pour 1 000 appels/
jour ne rendra pas le mme service sil en reoit 3 000/jour, quelle que soit
la qualit de son organisation.
Cette ngociation doit galement prendre en compte les obligations des
utilisateurs, par exemple, la formation ou le respect des procdures et des
habilitations.
La capacit mesurer la performance en renseignant les indicateurs de
pilotage des niveaux de services est un pralable tout management de
lactivit. Ceci peut se rvler plus ou moins complexe mettre en uvre
130
(par exemple, mesure du temps de rponse observ au niveau du poste de

lutilisateur). Il faut imprativement lancer des processus de mesure de
performance quitte en amliorer progressivement la prcision.
Sagissant des activits externalises, gardons lesprit la ncessit de
mettre en cohrence les SLA et les contrats avec les tiers. En dfinitive,
seuls ces derniers compteront vraiment, ds lors quils sont assortis de
facturation relle.
La boucle damlioration du processus passe par la mesure et un souci
constant de communication afin de trouver les meilleurs compromis entre
les parties.
Mesures et contrles
Les mesures les plus couramment utilises viennent du pilotage des centres dassistance (pourcentage de rsolution dans un dlai donn), des
mesures de fiabilit des composants (nombre de coupure des tlcommunications par jour) ou des statistiques prleves sur les mainframes (temps
de rponse). La principale difficult consiste passer de ces KPI1 techniques attaches un aspect du service offert un KGI ayant un sens pour le
mtier. Cette chane dengagements permet au client final de se concentrer
sur des objectifs mtier (KGI) et la DSI de les dcliner en objectifs techniques (KPI).
Le DSI a un rle majeur dans linstauration dune communication claire
avec les mtiers, base sur la comprhension mutuelle, lexplication, la
mesure, ainsi que sur la dynamique densemble qui tire les uns et les
autres vers un comportement positif. Sans participation du DSI, il nexiste
pas de cadre de niveaux de services partag. Le DSI doit tre linterlocuteur
des directions mtiers comme les responsables des centres de services
sont les interlocuteurs des utilisateurs.
La cellule mthodes et qualit (MAQ)
Le rle de la cellule MAQ est de piloter, relancer, challenger et mesurer la
performance des services au regard des engagements. Elle doit surtout
animer la boucle damlioration continue, en impulsant les actions correctives prioritaires qui simposent.
Le service dassistance et le responsable exploitation
Sous la responsabilit du chef dexploitation, les responsables des centres
de services sont en charge du pilotage oprationnel de la relation avec le
souci de grer lescalade vers le management de la DSI si ncessaire.
131
1. Les indicateurs
(KPI : key performance indicators)
mesurent les performances au niveau
technique et contribuent la ralisation
dobjectifs au niveau
des mtiers, euxmmes mesurs par
des KGI (key goal
indicators).
Le responsable administratif des SI

Le contrle de gestion de la DSI a aussi un rle important quand il sagit de
mettre en place des indicateurs lis aux cots. Noublions pas que les lments de cots constituent souvent des indicateurs pertinents de consommation des services.

PO1, AI1, DS2, DS3,
DS4, DS5, DS6, DS8,
DS11, DS13, SE1
PO1, PO2, PO5, AI2,

AI3, DS4, SE1
DS1 : Dfinir et grer les

niveaux de services
Plans informatiques stratgiques et

tactiques
Classifications attribues aux
donnes
Contrats de services initialement
prvus
Contrats dexploitation initialement
prvus
Exigences de services en cas de
sinistres, y compris les rles et
responsabilits
Entre de la performance dans le
planning informatique
Rapport de revue des contrats

Rapports sur la performance des
processus
Exigences de services nouvelles/
modifies
Contrats de services (CS)
Contrats dexploitation (CE)
Portefeuille actualis des services
Figure 6-3 : Les entres-sorties du processus DS1
DS2
Grer les services tiers
Les activits de la DSI sont de plus en plus imbriques des services contractualiss auprs de tiers. Ces derniers deviennent partie intgrante des
processus de la DSI quand il sagit den garantir lefficacit et lefficience.
Les oprationnels sont invitablement amens banaliser les rapports
entre individus, quils soient internes ou externes lentreprise. Dans ce
contexte, comment maintenir la vigilance ncessaire ? Il faut, quelque part,
instancier un processus de gestion des services contractualiss avec les
tiers.
132
Vue densemble
En termes de gouvernance, les services tiers renvoient deux proccupations, savoir lapport de valeur et la gestion des risques dans un souci
defficacit et defficience.
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPORT DE
VALEUR
CONFIDENTIALITE
APPLICATIONS
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 6-4 : Grer les services tiers : DS2
Pourquoi ?
La gestion des tiers rpond la fois au souci de piloter correctement les
engagements contractuels et celui de se poser les bonnes questions
sur le moyen terme. En travaillant troitement avec la fonction achats,
il sagit de maintenir une veille du march afin doptimiser le couple
apport de valeur/risque, en fonction du segment considr. Il est clair,
par exemple, que la maintenance applicative dun ERP nest pas
mettre au mme niveau que la maintenance des PC sur le plan des
risques.
On observe couramment en la matire un manque danticipation qui rvle
la mauvaise implmentation de ce processus.
annexe 2, Objectifs du systme dinformation et processus CobiT ), le processus DS2 doit permettre de matriser les objectifs prsents dans le
tableau 6-2.
133
OBJ. 03
Sassurer de la satisfaction des utilisateurs naux lgard des offres et des niveaux de services.
OBJ. 10
Sassurer de la satisfaction rciproque dans les relations avec les tiers.
OBJ. 12
Sassurer de la transparence et de la bonne comprhension des cots, bnces, stratgie, politiques et niveaux de services des SI.
Lobjectif Obj. 03 est relativiser en fonction de la visibilit du tiers par

rapport aux utilisateurs. Si sa prestation est incluse dans un ensemble
plus global, la satisfaction de lutilisateur sera un indicateur trs partiel.
En revanche, il faut garder lesprit que le contrat avec le tiers finit par
envahir la discussion et occulter les SLA internes, si on na pas pris garde
daligner les attentes vis--vis des tiers et les engagements pris auprs
des utilisateurs.
Le primtre du processus englobe lensemble des relations avec les tiers quil
sagisse de contrats de type infogrance, de forfaits, de contrats bass sur des
consommations dunits duvre ou mme de dlgation de personnel.
Le primtre du processus recoupe celui du processus DS1 sagissant des
interactions entre les niveaux de services contractualiss avec les tiers et
les niveaux de services ngocis avec les utilisateurs.
IDENTIFIER
IDENTIFIER ET CATEGORISER LES SERVICES TIERS

(type, importance et niveau critique)
CONTROLER
Catalogue
fournisseurs
SASSURER QUE LES FOURNISSEURS SE CONFORMENT

AUX STANDARDS DE LA PROFESSION
SURVEILLER LA FOURNITURE DES SERVICES ET LE
RESPECT DES CLAUSES CONTRACTUELLES
EVALUER ET REDUIRE LES RISQUES FOURNISSEURS
(continuit, exigences de scurit, confidentialit, etc.)
METTRE EN UVRE
FORMALISER LE PROCESSUS DE GESTION DES RELATIONS
FOURNISSEURS (rles et responsabilits, objectifs, livrables, etc.)
ETABLIR DES POLITIQUES ET DES PROCEDURES DEVALUATION

ET DE SELECTION DES FOURNISSEURS
134

La planification et la mise en uvre du processus DS2 part dune identification des principaux services sous-traits caractriser en relation avec
les mthodes employes aux achats. Il est habituel doprer une segmentation selon les catgories des services confis des tiers. Une expertise
de haut niveau ne relve pas de la mme catgorie que le renfort dune
quipe de dveloppement ou une maintenance applicative.
Ensuite, on cherche progressivement, au fur et mesure des renouvellements, encadrer de faon homogne les services sous-traits. Ainsi, par
exemple, on pourra dcider de gnraliser une option de rversibilit lissue
du contrat, de normaliser les dispositions concernant la proprit intellectuelle ou dassortir les contrats de mcanismes dunits duvre avec comptabilisation analytique par client final, de faon rpercuter les cots.
partir de ce portefeuille de services tiers, on cherche optimiser le
couple valeur/risques. Ce peut tre le fruit de rengociations, de comparaisons (benchmarks), le rsultat doutillages ou de standards (ITIL en production) ou la refonte des primtres sous-traiter. Il est manifeste que le
morcellement des contrats entrane une forte implication de la DSI pour
les grer et limite les bnfices de lexternalisation. En revanche, un primtre redessin peut conduire des conomies dchelle voire
labandon de certains domaines techniques jugs peu stratgiques.
Mesures et contrles
La mesure et les contrles des services tiers sont clairement aligns avec
les dispositions contractuelles. Le tableau de bord de mesure des services
fournis par les tiers doit donc tre soigneusement prpar au stade du
cahier des charges pour viter davoir dployer un effort supplmentaire
pour dfinir, alimenter et ngocier les tableaux de bord de suivi du service.
Il est souhaitable que la partie prenante propose avec le service les outils
de mesure avec une possibilit daudit.
Les achats
Les achats informatiques de lentreprise jouent un rle dterminant dans
la russite de ce processus ds lors quils fonctionnent troitement avec
les services internes la DSI.
La direction des systmes dinformation

Au sein de la DSI, il faut trouver une instance et un pilote du processus, ce
qui nest pas toujours chose aise. On va plutt trouver des responsables
par domaine (oprations pour lexploitation, les tlcommunications, les
135
PC, etc.) quil faudra fdrer pour avoir une politique DSI homogne vis-vis des tiers.
Trs frquemment, ce processus est confi aux oprationnels qui sont trop proches des tiers dans le quotidien pour rellement mener ce processus bien.
Le responsable des relations avec les utilisateurs doit tre fortement
impliqu dans la ngociation des services tiers.

PO1, PO8, AI5, DS1,
DS4
PO9, AI5, SE1
DS2 : Grer les services

tiers
Stratgie de fourniture informatique

Clauses contractuelles
Exigences de la gestion des
relations avec les tiers
Compte rendu de revues de
contrats
responsabilits

processus
Catalogue fournisseurs
Risques fournisseurs
DS3
Grer la performance et la capacit
Processus interne la DSI, la gestion des performances et des capacits

constitue la base mme du pilotage des activits.
Vue densemble
La gestion des ressources, en particulier dans les grands comptes, renvoie
des cycles qui ncessitent de bien anticiper partir de ltat de ses ressources propres et de lvolution des demandes. Le processus DS3 est donc
un processus amont critique pour les processus stratgiques que sont PO2
(architecture), PO3 (orientation technologique) et PO5 (investissements).
136
GOU VERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPORT DE
VALEUR
CONFIDENTIALITE
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
APPLICATIONS
INFORMATIONS
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 6-7 : Grer la performance et la capacit : DS3
Il sagit donc essentiellement dapporter la gouvernance du SI les moyens

de grer les ressources informatiques, dans un contexte defficacit, defficience mais aussi de disponibilit. En ce sens, le processus DS3 est le
rsultat des niveaux de services qui auront t ngocis lors du processus
DS1, et produira les informations permettant, dans le cycle des processus
CobiT, den suivre ladquation globale.
Pourquoi ?
Le pilotage des activits de la DSI est bas sur la recherche du meilleur
compromis entre les performances exiges et les capacits informatiques.
Cette proccupation sinscrit aussi bien dans le trs court terme (quelle
attitude observer face des imprvus ?) que dans le moyen terme o il
sagit de planifier au mieux les volutions dans le souci constant
dapporter la meilleure rponse (qualit et prix) aux exigences mtier.
tableau 6-3.
OBJ. 01
OBJ. 15
OBJ. 23
Sassurer que les services informatiques sont disponibles dans les conditions requises.
137
Le primtre du processus comprend les infrastructures et les ressources

ncessaires la fourniture des services dans le respect des niveaux de
services ngocis.
Il consiste tablir une vision prcise des performances et des capacits
(actuelles et futures) et, priodiquement, un tat prcis densemble.
Lune des activits du processus consiste se poser comme initiateur des
demandes de changement gres par le processus AI6 (voir chapitre 5, section AI6 Grer les changements ). On reconnat l le couplage entre
les deux processus quivalents dans ITIL.

Le processus doit avant tout mettre sur pied la revue des performances et
des capacits de linfrastructure et des ressources informatiques de faon
prenne et stable, en relation troite avec les niveaux de services ngocis.
Cela doit conduire la fois des tableaux de bord prcis et des techniques de modlisation permettant danticiper les volutions, le tout au
meilleur cot.
138
Il permettra ainsi de suivre la situation actuelle et de jalonner les grandes

tapes moyen terme pour lvolution des ressources.
Ce processus prend galement en compte une hirarchisation des services fournir de faon tablir les plans de fourniture de service
dgrads, en cas de dfaillance partielle de ressources ou dalas sur les
demandes des mtiers. Lune des activits du processus consiste donc
sassurer priodiquement de la mise en place, de lefficacit et de la pertinence des mesures prises pour garantir la disponibilit du systme
(procdures de secours et de plans durgence).
Enfin, il sattache tablir en permanence une vision prcise et comprhensible des ressources et des performances, maintenir les performances et rendre compte des rsultats face aux conventions de services
ngocies.
Mesures et contrles
Le processus DS3 est une source dalimentation importante du processus
de contrle SE1 (voir chapitre 7, section SE1 Surveiller et valuer la
performance des SI ). Il maintient une vision des paramtres cls du pilotage des ressources : temps de rponse, charges des quipements, indisponibilit, pannes, carts par rapport aux prvisions des mtiers, carts
par rapport aux plans dvolution des infrastructures, etc.
Ce processus ncessite la mise en place et lalimentation dune base de
donnes de lensemble des lments concourant la mesure de la performance et de la disponibilit. Dans le rfrentiel ITIL, on parle de la
CMDB (Configuration Management Database) pour regrouper toutes les
informations sur les composants et les ressources et alimenter une vue
qui part du composant lmentaire (bottom-up) pour apprcier la disponibilit.
Au-del du simple reporting, le processus DS3 demande de modliser lutilisation des ressources et dtre force de proposition pour rpondre aux
questions poses lors du processus PO2 sur lvolution de larchitecture
du systme dinformation.
Le processus DS3 doit la fois sappuyer sur des ressources permanentes
(reporting) et mobiliser des instances au plus haut niveau de la DSI (modlisation, prvisions, plans durgence).
Il doit sassurer en permanence que les performances et les capacits informatiques, actuelles et futures, permettent de respecter les engagements pris.
139

PO2, PO3, PO5, AI1, AI3,
AI6, SE1
AI2, AI3, DS1
DS3 : Grer la
performance et la
capacit
Information sur la performance et la

capacit
Plan de performance et capacit
(exigences)
Changements requis
processus
continuit et reprise
Exigences de surveillance des
systmes
DS4
Assurer un service continu
Au-del du respect des contrats de services qui sont le lot quotidien des DSI, il
est indispensable denvisager les situations de crise voire de catastrophe pour
tenter de mettre en place des plans daction qui en rduisent les impacts.
Vue densemble
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPORT DE
VALEUR
CONFIDENTIALITE
APPLICATIONS
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 6-10 : Assurer un service continu : DS4
140
Si le processus DS4 est particulirement dtaill dans CobiT, cest parce

quil relve en grande partie de la gestion des risques sur un domaine qui
se prte bien une description de bonnes pratiques applicables pour
toutes les entreprises ou organismes.
Notons que la gestion des risques de lensemble du SI est associe
lapport de valeur. La situation de dgradation des performances est telle
que lon ne parle plus dalignement stratgique mais de ce que pourra
apporter encore le plan de continuit en cas de gros problme. Les critres
dexigence sont trs pragmatiques car ils doivent raliser un compromis
entre efficacit et intgrit du systme.
Pourquoi ?
Assurer un service continu signifie offrir le meilleur compromis en fonction
de la dgradation du systme dinformation travers lapplication dun
plan de continuit appropri et prouv. Cette rponse gradue la
dfaillance du systme ne peut pas tre improvise dans lurgence.
tableau 6-4.
OBJ. 21
Sassurer que les services et linfrastructure informatique peuvent

rsister/se rtablir convenablement en cas de panne due une erreur,
OBJ. 22
Sassurer quun incident ou une modication dans la fourniture dun

service informatique na quun impact minimum sur lactivit.
OBJ. 23
Sassurer que les services informatiques sont disponibles dans les

conditions requises.
Parmi les processus DS, quatre processus relvent surtout de la gestion des risques : DS4, DS5 (scurit), DS11 (donnes) et DS12 (environnement physique).
Le plan de continuit constitue la dernire rponse lorsque les trois autres
processus (donnes, environnement, scurit) se sont rvls dfaillants.
Lensemble des services informatiques est concern par le processus DS4.
Il sagit non seulement de prvoir les situations entranant un problme
majeur pour les mtiers, mais aussi denvisager pour chacune dentre elles
un vritable systme dinformation provisoire en attendant le retour la
normale. Les mtiers sont concerns parce que la convention de service va
141
se muer en service dgrad , sur le mme principe dexigences mutuelles.

Quant aux services tiers, ils seront revus pour prendre en compte de nouvelles
demandes.
DEFINIR
DEFINIR UN REFERENTIEL DE CONTINUITE DES SI
AMELIORER
DETERMINER LA CAPACITE DE RESISTANCE DES SI ET LE

DEVELOPPEMENT DES PLANS DE SECOURS
ETABLIR LES PLANS DACTIONS SELON LES

RESULTATS DES TESTS DU PLAN
DETERMINER LES RESSOURCES CRITIQUES

ET LES EXIGENCES DE DISPONIBILITE
CONDUIRE DES REVUES APRES REDEMARRAGE

DETERMINER LES PRINCIPES DE SAUVEGARDE ET DE RESTAURATION
MAINTENIR A JOUR LE PLAN DE CONTINUITE
COMMUNIQUER
FAIRE
COMPRENDRE AU
METIER LES
DELAIS ET LES
COUTS DE
RESTAURATION
METTRE EN UVRE
DEVELOPPER DES PLANS DE CONTINUITE DES SI
CONTROLER
FORMER LES PARTIES CONCERNEES A LA CONTINUITE DES SI

DIFFUSER LE PLAN DE CONTINUITE DES SI
EN TEMPS ET LIEU OPPORTUNS
DEVELOPPER DES PROCEDURES

DE CONTROLE DES CHANGEMENTS
TESTER REGULIEREMENT
LE PLAN DE CONTINUITE
PREVOIR LES ACTIONS A MENER DURANT LA RESTAURATION ET LE

REDEMARRAGE (procdures, alternatives, communication, etc.)
ASSURER LE STOCKAGE HORS SITE ET LA PROTECTION DES
SAUVEGARDES (supports de sauvegarde, documentation, etc.)

Il sagit tout dabord de dfinir un rfrentiel de continuit des systmes
dinformation, ce qui amne redessiner lentreprise en situation de crise :
applications, donnes, tlcommunications, sites informatiss et postes de
travail, rles et responsabilits. Ce rfrentiel est le pivot de la communication avec les mtiers sur la construction dune solution mixant les rponses
des risques gnriques non spcifiques de linformatique (incendie, inondation, malveillance, par exemple). En labsence dune prise de conscience
globale, le plan de continuit informatique ne sera que trs partiel.
Ce plan de continuit informatique sera bti en examinant les ressources
critiques et en tablissant avec les mtiers une hirarchie des services
maintenir. Le rsultat doit prendre en compte les dlais et les cots pour la
mise en uvre du service dgrad, en accord avec les mtiers.
ce stade, on comprend que ce processus ncessite la fois une bonne
connaissance des exigences des mtiers et des vulnrabilits du SI, mais le
plus difficile reste faire pour le faire vivre (maintenir, tester, rviser,
former et communiquer autour du plan de continuit).
142
Lensemble ncessite en outre des sortes de rptitions gnrales grandeur

nature avec changements de sites, arrt et redmarrage sur dautres sites. Ces
exercices sont souvent coteux et longs, mais ils sont pourtant indispensables
si lon veut que lensemble du dispositif soit efficace le jour venu.
Mesures et contrles
Un certain nombre de contrles sont prvus sur lexistence de plans de
continuit, leur mise jour, leur test, les engagements des services tiers
(salles blanches, etc.). Tous ces contrles sont ncessaires mais seul lexercice grandeur nature est probant.
Une seconde catgorie de contrles porte sur les hypothses qui ont prsid la conception du plan de continuit, le faisceau de risques envisags
en hypothse la construction de ce plan.
Il est en charge, en concertation avec les autres responsables de la DSI
(responsable dveloppements, responsable administratif des SI, responsable de loffice des projets), de prparer et maintenir un plan de continuit de services adapt aux besoins des mtiers.

PO2, PO9, AI2, AI4,
DS1
PO9, DS1, DS2, DS8,

DS9, DS11, DS13, SE1
DS4 : Assurer un
service continu

donnes
continuit et reprise
dadministration
Rsultats des tests de secours

Elments de configuration
informatique critiques
Plan de stockage et de protection hors
site
Seuils incidents/sinistres
responsabilits
processus
143
DS5
Assurer la scurit des systmes
Le processus de scurit des systmes dinformation rpond

la dpendance croissante des mtiers vis--vis de linformatique, et
la ncessit de rduire les impacts de ses vulnrabilits sur les
mtiers.
Vue densemble
La contribution la gestion des risques (processus PO9, voir chapitre 4,
section PO9 valuer et grer les risques ) est lobjectif essentiel de ce
processus qui sintresse lensemble des ressources informatiques (applications, informations, infrastructures et personnes).
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPORT DE
VALEUR
CONFIDENTIALITE
APPLICATIONS
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 6-13 : Assurer la scurit des systmes : DS5
Les exigences mtier sont particulirement explicites avec en priorit

les exigences de confidentialit et dintgrit, mais aussi les exigences
de disponibilit, de conformit et de fiabilit. CobiT donne l toute
sa puissance en offrant ainsi une finesse danalyse approprie aux
enjeux.
Pourquoi ?
Pour assurer la scurit des systmes dinformation, il faut maintenir
les ressources associes de faon rduire les vulnrabilits impactant
144
les mtiers. Cela passe par un processus ddi qui donne une vision de
lensemble des ressources informatiques au regard des exigences de scurit.
Le processus DS5 couvre peu prs le spectre de la norme ISO/IEC 27002
(anciennement ISO/IEC 17799). Vis--vis des 28 objectifs globaux assigns
au systme dinformation (voir annexe 2, Objectifs du systme dinformation et processus CobiT ), le processus DS5 doit permettre de matriser
les objectifs prsents par le tableau 6-5.
OBJ. 14
Protger tous les actifs informatiques et en tre comptable.
OBJ. 19
Sassurer que l'information critique et condentielle nest pas accessible ceux qui ne doivent pas y accder.
OBJ. 20
Sassurer que les transactions mtier automatises et les changes

dinformations sont ables.
OBJ. 21
OBJ. 26
Maintenir lintgrit de linformation et de linfrastructure de

traitement.
La gestion des risques informatiques sintresse lensemble de lentreprise, de ses ressources informatiques (infrastructure, donnes, applications) et des acteurs (utilisateurs, internes ou externes, clients, hackers)
susceptibles de sintroduire dans les systmes. Elle ne prend pas en
compte les risques lis aux projets (processus PO10, voir chapitre 4, section
PO10 Grer les projets ).
En cas dexternalisation dactivits vers un tiers, il est important que la
gestion des risques soit garantie de bout en bout et donc, que les exigences de scurit ncessaires applicables aux tiers soient dtermines et
mises en uvre par ces derniers (processus DS2).
145
DEFINIR
DEFINIR UN PLAN DE SECURITE INFORMATIQUE GENERAL
(exigences mtier, risques informatiques, culture de la scurit, etc.)
COMMUNIQUER
COMMUNIQUER AUX
PARTIES PRENANTES
ET AUX UTILISATEURS
TRADUIRE LE PLAN DE SECURITE EN POLITIQUES ET

PROCEDURES DE SECURITE
CONTROLER
EFFECTUER UNE REVUE PERIODIQUE
DE LA GESTION DES DROITS DACCES
ET DES PRIVILEGES UTILISATEURS
SENSIBILISER
A LA SECURITE PAR LA
FORMATION (DS7)
VALIDER ET TESTER PERIODIQUEMENT

LE MAINTIEN A NIVEAU
DE LA SECURITE INFORMATIQUE
METTRE EN UVRE
COMMUNIQUER A LA
GESTION DES
INCIDENTS (DS8)
METTRE EN PLACE UN PROCESSUS DE GESTION DES IDENTITES

ET DES COMPTES UTILISATEUR
EVALUER REGULIEREMENT
LA VULNERABILITE DES SI
(mesures de prvention, dtection, neutralisation)
FOURNIR UNE DEFINITION CLAIRE

DES INCIDENTS DE SECURITE POTENTIELS
Dfinition des
incidents de
scurit
METTRE EN PLACE DES PROCEDURE DE GESTION

ET DE PROTECTION DES CLES DE CHIFFREMENT
METTRE EN PLACE DES PROCEDURES DE CONTROLE ET DE
PROTECTION DES RESEAUX ET DES DONNEES SENSIBLES

La gestion de la scurit informatique ncessite une approche globale en
relation directe avec les mtiers. De mme que la fourniture de services passe
par une contractualisation des niveaux de services, la gestion de la scurit
doit tre nuance et pondre en fonction des enjeux arrts avec les mtiers.
La gestion de la scurit se traduit par un plan de scurit informatique
qui couvre lensemble des domaines et en particulier la scurit en regard
des personnes et des dfaillances des ressources.
Ce plan se dcline en politiques et en procdures. La communication et
la formation (processus DS7) revtent un caractre essentiel. La scurit
est bien souvent perue comme une entrave au fonctionnement des processus mtier, il est donc important que la hirarchie et les utilisateurs
entrent dans une dmarche de sensibilisation et de responsabilisation.
Cela renvoie au caractre raisonnable et appropri des politiques
pour tre acceptables.
Le plan de scurit doit prendre en compte la situation existante. Rien ne
sert driger un mur de fortification sil suffit de sauter la haie au coin du
mur ! Il faudra donc privilgier une approche homogne inscrite dans un
processus damlioration. L plus quailleurs, la dynamique damlioration
du processus est plus importante que sa compltude.
146
Concernant les risques lis aux personnes (internes, externes, malveillantes ou non), on suivra en permanence les volutions rglementaires
et les politiques internes associes (domaine priv du salari, obligations
dinformation, dclarations aux autorits, etc.). Ce domaine couvre la gestion des identits, la gestion des comptes utilisateurs en liaison troite
avec les enjeux applicatifs des processus mtier, la gestion des cls de chiffrement, la gestion de la confidentialit sur les plans de scurit euxmmes, les changes de donnes sensibles et la dtection des logiciels
malveillants. Le risque li aux problmes dhabilitation sera particulirement pris en compte et rpercut sur le processus DS2 pour les tiers (accs
des infogrants, par exemple).
Pour les risques lis aux ressources informatiques, le processus couvrira
la scurit des rseaux, des serveurs, des postes de travail et plus gnralement la scurit de toutes les ressources ncessaires au fonctionnement
des SI.
Une attention particulire sera apporte des processus transverses entre
mtiers et DSI comme larchivage et la dmatrialisation. Ce genre de processus met en uvre des politiques de scurit trs disparates et obissant des objectifs diffrents selon que cest un mtier ou la DSI qui sen
occupe. Par exemple, larchivage de contrats ou leur numrisation au sein
des entits mtier fait-il lobjet des mmes rgles de scurit que ce qui
est appliqu la DSI ?
Le plan de scurit doit tre rgulirement test et actualis, que ce soit
au travers daudits, de sondages ou de contrles automatiques.
Enfin, une hirarchie des incidents de scurit peut tre tablie et communique, en particulier au centre de services, pour que la dtection
dincidents (processus DS8) identifie immdiatement les alertes de
scurit.
Mesures et contrles
La mise en place dun tableau de bord de la scurit sappuie sur la classification des incidents de scurit qui sont rpertoris et classs en
niveaux de risques. Ceci permet davoir une communication claire avec
les mtiers.
Le tableau de bord sera aliment pour partie par les outils de contrle
interne automatiss (applications, espions, etc.), par les exploitants et par
les incidents remonts en DS8 par le centre de services.
Enfin, on tracera galement les tests du plan de scurit, le processus
damlioration de ce plan, vis--vis des objectifs un an et trois ans.
147
Le DSI est clairement en charge de ce processus dont il dlgue la responsabilit, en particulier aux responsables de son quipe (exploitation
architecture, dveloppements), au contrle interne de la DSI et aux responsables des domaines applicatifs.
Il est responsable de la dtermination et du suivi des droits daccs aux
utilisateurs.

PO2, PO3, PO9, AI2,
DS1
PO9, AI6, DS7, DS8,

DS11, SE1
DS5 : Assurer la
scurit des systmes
Dfinition des incidents de scurit

Exigences de formations spcifiques
la sensibilisation la scurit
processus
Modifications de scurit requises
Menaces et vulnrabilits de scurit
Plan et politiques de scurit
informatique
Architecture de linformation
donnes
Standards informatiques
Spcifications de contrles de
scurit des applications
S6
Identifier et imputer les cots
Il peut paratre lmentaire de songer identifier et imputer les cots

de linformatique. Pourtant, peu de DSI ont une vision claire de leurs
cots en regard la fois de la performance du SI et de lapport de valeur
pour les mtiers.
148
Vue densemble
Ce processus concerne en priorit la gestion des ressources parce quil ny
a pas de gestion des ressources efficiente sans une identification claire des
cots. Cette gestion sapplique lensemble des ressources informatiques.
Aprs identification claire et prcise des cots (fiabilit de linformation)
sur les ressources informatiques, le processus sintresse lapport de
valeur pour les mtiers et la mesure de la performance. Cela aboutit
dune part limputation des cots pour les mtiers et dautre part, la
mesure de lefficience de lutilisation des ressources.
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPORT DE
VALEUR
CONFIDENTIALITE
APPLICATIONS
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 6-16 : Identier et imputer les cots : DS6
Pourquoi ?
Lexprience montre que le processus didentification des cots est complexe. La DSI est un service de support qui, en gnral, na pas sa comptabilit propre. Il faut donc reconstituer une comptabilit analytique. titre
dexemple, calculer les cots sur un projet conduit additionner des
dpenses internes (salaires, charges, locaux, etc.) et des dpenses externes
(sous-traitants, centres de services), ce qui amne retraiter des lments
disparates.
Le second cueil vient du niveau de granularit viser pour tre pertinent.
Jusquo aller dans les consommables ? Comment grer les achats imputables
aux SI raliss par les mtiers ?
149

tableau 6-6.
OBJ. 12
Sassurer de la transparence et de la bonne comprhension des cots, bnces, stratgie,

OBJ. 24
OBJ. 28
Sassurer que linformatique fait preuve dune qualit de services efciente en matire de cots,
damlioration continue et de capacit sadapter des changements futurs.
Il ressort que lobjectif principal de ce processus est dinstaurer une transparence pour un pilotage de la performance par les cots. Cette identification
des cots doit conduire une meilleure apprciation de la valeur apporte en
cherchant le meilleur compromis cot/niveau de service.
Lensemble des cots imputables au SI est dans le primtre de ce processus. En toute logique, les dpenses informatiques, quelles soient
effectues par les mtiers ou par la DSI, entrent dans ce primtre. Il
sagit de recrer un compte dexploitation partir de donnes comptables
parses couvrant lensemble des ressources informatiques.
La refacturation aux services utilisateurs nest pas une obligation, mais
le rsultat dune dcision qui ne sera possible quune fois le processus
DS6 rd.
DEFINIR
COMMUNIQUER
IMPLIQUER LES METIERS
DANS LA DEFINITION DU
MODELE DES COUTS
FAIRE COMPRENDRE
AUX METIERS LES
NIVEAUX DE
FACTURATION DES
SERVICES
RENDRE COMPTE EN
TOUTE TRANSPARENCE
AUX UTILISATEURS DES
SERVICES
FOURNIR UNE DEFINITION EQUITABLE DES COUTS

CORRESPONDANTS AUX SERVICES INFORMATIQUES
Modle
de cots
DEFINIR UN MODELE DE COUTS

(cots directs et indirects, frais gnraux, etc.)
AMELIORER
AMELIORER LA RENTABILITE GRACE A UNE
UTILISATION DOCUMENTEE ET COMPRISE
DEFINIR DES PROCEDURES DE FACTURATION

CONTROLER
REALISER DES REVUES ET DES TESTS
COMPARATIFS DU MODELE DE COUTS ET DE
REFACTURATION
METTRE EN UVRE
ETABLIR UNE CORRESPONDANCE ENTRE LES SERVICES
INFORMATIQUES ET LES PROCESSUS METIER
CALCULER ET AFFECTER LES COUTS REELS
150
ANALYSER ET RENDRE COMPTE DES ECARTS

ENTRE LES PREVISIONS ET LES COUTS REELS

La premire tche consiste mettre en place un plan de compte permettant de structurer la comptabilit analytique de la DSI, appropri au suivi
des cots. De nombreux exemples existent, le CIGREF (Club informatique
des grandes entreprises franaises) a travaill et tabli des prconisations
ce sujet. Il sagit l encore de dmarrer de faon modeste et ensuite
damliorer progressivement le processus.
Lidentification des cots passe par les systmes de comptabilit existants
dans lentreprise quil faut donc projeter sur le systme de gestion de
linformatique, mais cette condition indispensable nest pas suffisante.
Pour passer une identification, certains pralables sont ncessaires, lesquels sont lis aux objets de gestion de linformatique (projets, services,
etc.). Citons par exemple le suivi et limputation des temps de travail des
intervenants internes et externes.
Le processus doit progressivement permettre de donner une ide prcise
des cots au regard de la valeur apporte aux mtiers (maintenance dune
application, support, etc.), de faon entrer dans des boucles de rgulation
cot/service lorsque lon parle dajout de fonctionnalits ou de services, par
exemple.
La cible qui consiste dtenir une comptabilit de linformatique est, ne
nous leurrons pas, trs complique atteindre pour les grands comptes. Il
faudra se contenter pendant un certain temps dclairages partiels amenant se confronter des ratios du march (benchmark) pour apprcier et
amliorer la performance.
La communication vis--vis des mtiers est lun des points cls de ce processus, et la garantie de la voir contribuer la rgulation des demandes
dans le cadre dune bonne gouvernance. CobiT semble aller vers une facturation systmatique des services aux mtiers, ce nest pas forcment
lobjectif final dans la mesure o la transparence et limputation permettent
dj une communication prcise.
Mesures et contrles
La capacit identifier lensemble des cots dans les systmes de gestion
de lentreprise est une premire mesure qui suppose une forme de plan de
compte analytique.
La mise au point dun contrle de gestion de linformatique permettant
disoler des units duvre associer des quantits consommes est un
rsultat probant.
Limputation aux mtiers des dpenses informatiques les concernant nest
possible que si les deux premires tapes sont finalises.
151
De faon gnrale, le suivi des cots, mme partiel, est un indicateur qui
peut servir se comparer (benchmark) vis--vis de standards du march
(par exemple, le cot de possession des PC) ou entre des situations semblables en interne (comparaison entre filiales).
Lune des rgles de base consiste viter de trop brouiller les repres
dune anne lautre de manire pouvoir isoler des tendances sur quelques annes.
Le responsable administratif des SI
Il est charg de mettre en place et de suivre le systme de gestion.
Les grandes DSI se dotent dun contrle de gestion interne pour piloter ce
processus qui ne peut pas tre compltement confi la direction administrative et financire.
La direction nancire
Elle joue un rle majeur dans laide la DSI pour construire le systme de
gestion et lalimenter. Cest avec son support que la DSI mettra en uvre
son systme de gestion.
PO2, PO3, PO9, AI2,

DS1
PO5, SE1
DS6 : Identifier et
imputer les cots
Donnes financires informatiques

processus
Documentation sur les propritaires

de systmes
Budgets informatiques
152
DS7
Instruire et former les utilisateurs
Il est courant dentendre que les utilisateurs de la bureautique ne connaissent que 10 % des possibilits offertes par les outils mis leur disposition.
Ce qui est peut tre tolrable pour des progiciels grand public ne saurait
ltre pour le SI interne.
La mise en uvre des composants du SI ne pourra tre efficace que si la
documentation, la formation et laccompagnement des utilisateurs sont
adapts aux besoins et comptences de ces derniers.
Vue densemble
Lune des conditions de lefficacit et de lefficience du SI rside dans
la capacit des utilisateurs en tirer le maximum de bnfices pour les
mtiers.
Autrement dit, la fonction de transformation qui mne lapport de valeur
pour les mtiers passe pour une bonne partie par la formation des utilisateurs. Il en est de mme pour la gestion des risques, lalignement stratgique et la gestion des ressources.
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPORT DE
VALEUR
CONFIDENTIALITE
APPLICATIONS
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 6-19 : Instruire et former les utilisateurs : DS7
Pourquoi ?
Le processus DS7 formalise clairement une exigence daccompagnement
des SI par la monte en comptence des utilisateurs pour en tirer bnfice.
153
tableau 6-7.
OBJ. 03
OBJ. 13
Sassurer dune bonne utilisation et des bonnes performances des applications et des solutions
informatiques.
OBJ. 15
On voit que les objectifs de la formation portent sur ladquation entre le systme dinformation et les besoins des utilisateurs. En clair, il sagit de runir
les meilleures conditions pour que les mtiers disposent dun systme dinformation performant, que ce soit sur le plan des niveaux de services dfinis, de
ladquation des applications aux besoins ou des performances de linfrastructure, le tout en relation avec les comptences des utilisateurs.
Il concerne lensemble des programmes de formation ncessaires aux utilisateurs pour bien tirer profit du systme dinformation.
DEFINIR
AMELIORER
IDENTIFIER ET DEFINIR LES BESOINS EN SAVOIR

ET EN FORMATION DES UTILISATEURS
METTRE A JOUR
LE PROGRAMME DE FORMATION
SELON LES RESULTATS DES EVALUATIONS
METTRE EN UVRE
EVALUER
CONSTRUIRE UN PROGRAMME DE FORMATION

ADAPTE A CHAQUE GROUPE CIBLE
EVALUER ET RENDRE COMPTE

DE LEFFICACITE DE LA FORMATION
ORGANISER LES ACTIVITES

DE FORMATION ET DENSEIGNEMENT
IDENTIFIER LES MEILLEURS OUTILS ET METHODES
POUR DISPENSER LA FORMATION
154

Il sagit de mettre en place et de faire voluer lensemble des plans de formation des utilisateurs, que ce soit pour lutilisation des applications,
linfrastructure ou la gestion de la scurit.
Mesures et contrles
Lun des contrles consiste vrifier la pertinence des programmes de
formation et leur dploiement effectif auprs des utilisateurs.
Il faut aussi prendre en compte les statistiques dappels du centre de services pour identifier parmi les causes les plus frquentes celles qui peuvent tre rduites laide de complments de formation. Le centre
dappels initie ainsi une sorte de boucle damlioration pour le SI, travers
la formation ou, si cest justifi, par des changements.
Le DSI est le pilote de ce processus et sappuie sur son quipe pour dterminer les besoins en savoir et formation, et pour concevoir les formations
ncessaires (en tant quexpert technique).
La direction des ressources humaines
Elle intervient, par lintermdiaire du service formation, pour la conception
des formations (en tant quexpert de lingnierie pdagogique), leur planification et leur dploiement.

Il intervient pour lidentification des besoins en savoir et formation en
fonction des comptences des utilisateurs, puis pour la planification et le
dploiement des formations.
155
PO7, AI4, DS1, DS5,

DS8
AI4, SE1
DS7 : Instruire et former

les utilisateurs

processus
Mises jour de la documentation
requises
Comptences et connaissances
des utilisateurs
Formation individuelle
Besoins spcifiques en formation
Matriels de formation
Besoins de transferts de
connaissances pour la mise en
place de solutions
Exigences de formations spcifiques
la sensibilisation la scurit
Rapports sur la satisfaction des
utilisateurs
DS8
Grer le service dassistance aux clients

et les incidents
Le service dassistance aux clients est le pivot du rfrentiel ITIL. Dans

CobiT, il est dcrit conjointement au processus de gestion des incidents.
Vue densemble
En premire approche, le processus doit rpondre aux attentes du client et
concrtiser un apport de valeur concret du systme dinformation en satisfaisant les exigences defficacit et defficience. Simultanment, le service
dassistance est porteur de mesures de performance.
Le processus DS8 porte sur les applications et les personnes. Cette vision
semble privilgier lassistance aux utilisateurs dapplications sans inclure
les infrastructures ou les donnes.
156
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPORT DE
VALEUR
CONFIDENTIALITE
APPLICATIONS
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 6-22 : Grer le service dassistance aux clients et les incidents : DS8
Pourquoi ?
Il est indispensable dorganiser et de structurer lassistance aux utilisateurs de faon saligner sur les bonnes pratiques en la matire : enregistrement des demandes, traabilit des affectations pour rsolution,
respect des engagements de services, gestion dune base des problmes et
des solutions ( transformer en FAQ). Cela doit conduire amliorer lefficacit et lefficience du centre de services, son cot ainsi que le service
rendu et la satisfaction des utilisateurs.
tableau 6-8.
OBJ. 03
Sassurer de la satisfaction des utilisateurs naux lgard des offres et

des niveaux de services.
OBJ. 13
Sassurer dune bonne utilisation et des bonnes performances des applications et des solutions informatiques.
OBJ. 23
Sassurer que les services informatiques sont disponibles dans les

conditions requises.
Le primtre du processus semble orient sur les personnes et les applications. Concrtement, lensemble des ressources informatiques entre dans
157
le primtre du centre dassistance, que ce soit au premier niveau dintervention ou au second niveau.
Tous les services utilisateurs ou clients finaux (e-services) sont concerns,
mme si les modalits daccs au service sont plus ou moins filtres (keyusers, correspondants).
Ce processus est en relation avec le processus DS5 en ce qui concerne les
incidents lis la scurit.
DS8 Grer le service dassistance client

et les incidents
DEFINIR
DEFINIR DES PROCEDURES DENREGISTREMENT ET DE
CLASSIFICATION DES INCIDENTS (gravit et consquences)
DEFINIR DES PROCEDURES DE SUIVI
ET DE RESOLUTION DES INCIDENTS
CONTROLER
SURVEILLER LA RESOLUTION
DES DEMANDES DANS LES TEMPS CONVENUS
MESURER LA SATISFACTION DES UTILISATEURS
SUR LA QUALITE DU SERVICE
METTRE EN UVRE
METTRE EN PLACE UN SERVICE DASSISTANCE CLIENT
COMMUNIQUER
INFORMER LE CLIENT
DE LETAT
DAVANCEMENT
DE SA DEMANDE
OBTENIR LACCORD
CLIENT POUR LA
CLOTURE
METTRE EN PLACE UN SYSTEME DENREGISTREMENT

ET DE SUIVI DES APPELS
ANALYSER LES TENDANCES ET EN RENDRE

COMPTE AU MANAGEMENT
ENREGISTRER ET CLASSER LES DEMANDES

SELON LES PROCEDURES DEFINIES
TROUVER LES SOLUTIONS ET LES APPLIQUER
(rsolution immdiate, escalade fonctionnelle ou hirarchique)
CLOTURER LINCIDENT
1. Un centre de services
est en gnral organis
avec un premier niveau
qui rsout, dans un
temps limit, les cas les
plus faciles, puis un
second voire un troisime
niveau pour des incidents
plus complexes. En cas
dchec de rsolution, il
est prvu une procdure
descalade an de dnir
un plan daction face
un incident non rsolu.

Les premires tches raliser visent dfinir le service aux clients en
fixant les principaux paramtres sous-jacents : criticit des incidents et
niveaux de services. Cela permet dtablir les procdures de gestion des
incidents et descalade1.
La mise en place de lassistance sappuie sur les procdures qui ont t
dcides, il en rsulte un dimensionnement des quipes pour satisfaire les
niveaux de services dfinis. Un systme dinformation est dployer pour
enregistrer, suivre et rsoudre les demandes. Dans le rfrentiel ITIL, on
insiste sur la cration dune base de donnes regroupant toutes les informations sur les ressources informatiques (infrastructures, applications,
datas) et les changes avec les utilisateurs (tickets dappel, dossiers dincident, etc.).
158
Sur le plan oprationnel, le service dassistance prend en compte les

demandes et les incidents, les qualifie sur le plan de la criticit et applique
les procdures correspondantes. Le processus de rsolution des incidents
est de la mme manire rgl par les engagements de services pris (rsolution
en un dlai donn).
Une importance particulire est donne au processus de clture dincident
qui fait lobjet dun change avec le client afin de sassurer que la clture
est effective pour lui aussi et apprcier sa satisfaction face au service
rendu. Notons que la clture est un vnement important qui doit tre
dat car il servira dans les analyses de performance. De ce fait, on ne peut
pas toujours le lier une clture dcide avec lutilisateur, sous peine
dajouter au dlai de rsolution un dlai de validation.
Ce processus comprend galement un aspect important de communication avec les utilisateurs et un volet essentiel de mesure de performance.
Mesures et contrles
Le centre dassistance est une vritable mine de renseignements sur le
fonctionnement de linformatique selon ses clients, la satisfaction des utilisateurs, les incidents rptitifs ayant une causalit commune (les problmes), les lments de capacit, de disponibilit et enfin, latteinte des
objectifs en termes de niveau de service contract.
Parmi les contrles, on sattache en particulier vrifier la bonne prise en
compte des demandes clients (enregistrement, qualification, affectation,
communication vers le client), lexistence de procdures descalade (pour
les incidents non rsolus dans les dlais), le mcanisme de clture dincidents
et enfin, le tableau de bord et les analyses de tendances.
Le service client
Le centre dassistance aux clients est en gnral constitu comme un ple
part entire sous la responsabilit des services (oprateur, exploitant ou
autre).
Ce service nest pas rattach aux tudes ou aux projets mais il devra peser
sur les choix faire en matire de maintenance applicative, par exemple,
de faon rpondre aux besoins dtects auprs des utilisateurs au travers
lassistance.
159

AI4, AI6, AI7, DS1,
DS4, DS5, DS9,
DS10, DS13
AI6, DS7, DS10, SE1
DS8 : Grer le service

dassistance client et les
incidents
Demande de service/demande de
changement
Rapports dincidents
processus
utilisateurs

dadministration
disposition
Seuils des incidents de scurit
Dfinition des incidents de scurit
Configuration informatique/dtail
des actifs
Problmes connus, erreurs
connues, solutions de
contournement
Tickets dincidents
DS9
Grer la configuration
Connatre tout moment la configuration logicielle et matrielle pour

mieux la grer constitue une brique de base de la gouvernance informatique.
Une gestion de la configuration efficace permet de tracer les modifications
apportes aux composants du SI, aide vrifier la cohrence et la compltude de ces modifications, facilite la rsolution des problmes de production
et en rend la rsolution plus rapide.
Vue densemble
La gestion de la configuration permet en tout premier lieu de conjuguer
apport de valeur et gestion des ressources dans un souci defficacit.
160
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPORT DE
VALEUR
CONFIDENTIALITE
APPLICATIONS
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 6-25 : Grer la conguration : DS9
Le processus DS9 prend en compte les exigences defficience, de disponibilit et dintgrit, et contribue la gestion des risques.
Pourquoi ?
La gestion de la configuration suppose tout dabord de tracer tous les changements pour tenir jour la base de donnes de lensemble des configurations informatiques. partir de l, la gestion de la configuration consiste
optimiser, prvoir et anticiper ses volutions.
tableau 6-9.
OBJ. 14
OBJ. 15
Les ressources informatiques entrent dans le primtre (applications,

infrastructures, informations) du processus DS9.
161
Rapport dinterventions
et de rgularisations
DEFINIR
AMELIORER
DEFINIR DES PROCEDURES DE GESTION DES

CONFIGURATIONS (identification, enregistrement, mise jour)
TRAITER LES ANOMALIES OU LES ECARTS

PAR RAPPORT A LA SITUATION ACTUELLE
METTRE A JOUR
LE REFERENTIEL DE CONFIGURATION
METTRE EN UVRE
CONTROLER
CENTRALISER DANS UN REFERENTIEL TOUTES LES

INFORMATIONS SUR LES ELEMENTS DE CONFIGURATION
VERIFIER REGULIEREMENT LES

INFORMATIONS DE CONFIGURATION
(intgrit des donnes, licences logiciels, etc.)
ETABLIR LES CONFIGURATIONS DE BASE
Rfrentiel de
configuration

Le processus DS9 part de la cration dun rfrentiel centralis avec les
procdures de gestion associes (prise en compte des changements), ce
qui correspond une partie de la CMDB dITIL.
Lun des enjeux consiste sattacher une granularit dobjets suffisants
pour rpondre aux objectifs doptimisation, dvolution et de gestion des
incidents sans entrer dans des dtails superflus.
Mesures et contrles
Les indicateurs de bon fonctionnement du processus sont essentiellement
les carts entre la ralit et la configuration enregistre, avec leurs impacts
en termes de gestion des incidents, doptimisation de la configuration et
de gestion des risques.
Le gestionnaire de la conguration
Le rle de gestionnaire de la configuration sappuie sur les responsables
exploitation, architecture et dveloppements pour la mise jour du rfrentiel de configuration. Par ailleurs, il peut se faire aider dune instance de
dcision en matire de choix dvolutions.
162
AI6, DS8, DS10, DS13,

SE1
AI4, AI7, DS4
DS9 : Grer la
configuration
Configuration informatique/dtail des

actifs
Demande de modification
processus

dadministration
disposition
Elments de configuration
informatique critiques
DS10
Grer les problmes
Une bonne gestion des problmes permet damliorer le fonctionnement

et lutilisation des ressources et ainsi, de mieux rpondre aux besoins des
clients et daccrotre leur satisfaction.
Une gestion efficace des problmes implique didentifier ces problmes,
de les classer, den dterminer la cause, de trouver des solutions, puis de
suivre les actions correctives et den vrifier lefficacit.
Vue densemble
Lapport de valeur est la principale contribution de ce processus la gouvernance informatique, dans un souci defficience et defficacit.
Enfin, le processus DS10 alimente la fois la mesure de la performance et
la gestion des risques avec un focus sur la disponibilit des systmes pour
les mtiers.
163
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPORT DE
VALEUR
CONFIDENTIALITE
APPLICATIONS
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 6-28 : Grer les problmes : DS10
Pourquoi ?
La gestion des incidents est focalise sur la satisfaction des utilisateurs
dans le cadre des niveaux de services contracts, alors que la gestion des
problmes sintresse lradication des problmes rcurrents. Ce processus est donc la source de la dcision sur les changements oprer sur
le systme dinformation. Il agit comme une boucle damlioration du
systme.
tableau 6-10.
OBJ. 03
Sassurer de la satisfaction des utilisateurs naux lgard des offres et

des niveaux de services.
OBJ. 16
OBJ. 17
Il concerne lensemble des ressources informatiques.
164
DEFINIR
DEFINIR DES PROCEDURES DENREGISTREMENT ET DE

CLASSIFICATION DES PROBLEMES (impact, urgence, priorit)
DEFINIR DES PROCEDURES DE SUIVI

ET DE RESOLUTION DES PROBLEMES
CONTROLER
METTRE EN UVRE
COMMUNIQUER
EMETTRE DES
DEMANDES DE
MODIFICATIONS A LA
GESTION DES
CHANGEMENTS (AI6)
SURVEILLER EN PERMANENCE
LES CONSEQUENCES
SUR LES SERVICES INFORMATIQUES
DOTER LE RESPONSABLE DE LA GESTION DES PROBLEMES

DUNE AUTORITE SUFFISANTE
ENREGISTRER ET CLASSER LES PROBLEMES
SELON LES PROCEDURES DEFINIES
REALISER DES ANALYSES CAUSALES
(problmes non rsolus ou erreurs connues)
TROUVER LES SOLUTIONS AUX CAUSES IDENTIFIEES

Autorisation de
modifications
SUIVRE ET CLOTURER LE PROBLEME

Les problmes sont classs selon la mthode employe pour la gestion
des risques (impact, urgence, priorit) et on dfinit une procdure denregistrement, de suivi et de rsolution.
Une cellule est en charge de proposer des solutions dradication pour
rsoudre les problmes.
Le plus difficile est de rpercuter les demandes de changements sur les
units concernes afin de les intgrer dans les plannings avec la priorit
adquate.
Mesures et contrles
Outre le contrle de lexistence du processus et de sa bonne gestion, on
mesure en gnral le nombre de problmes ouverts un moment donn
ainsi que leurs dlais de rsolution et de clture.
Le responsable de la gestion des problmes
Se trouvent impliqus la fois un responsable de la gestion des problmes
(ventuellement ddi) et une instance mlant divers acteurs concerns.
165
Deux points particuliers se rvlent critiques pour la bonne marche du processus :

la lgitimit et la capacit dinfluence du responsable en charge des problmes afin dinfluer sur toutes les units de la direction informatique, y
compris les tudes, pour faire valoir ses priorits ;
la ractivit des acteurs en charge des ressources informatiques pour
trouver une rponse rapide aux problmes critiques et/ou rcurrents, en
particulier lorsque plusieurs domaines techniques sont en jeu (capacit
crer des cellules de crise transverses).
Notons enfin que la rduction des problmes doit la fois amliorer la disponibilit des ressources pour les utilisateurs mais aussi rsorber notablement le flux des incidents. Dans la mesure o la gestion de lassistance et
des incidents est trs souvent externalise, il faut srieusement rflchir
la manire dont on contrle la gestion des problmes ds lors quelle doit
diminuer la charge de lassistance.

AI6, DS8, DS9, DS13
AI6, DS8, SE1
DS10 : Grer les

problmes
Demande de changement
Historique des problmes
processus
Problmes connus, erreurs connues et
solutions de contournement
Autorisation de modification
Rapports dincidents
des actifs
Historiques des erreurs
DS11
Grer les donnes
Les donnes constituent un actif essentiel des entreprises quil faut grer
en termes de conservation, de fiabilit et de protection.
166
La gestion des donnes vise garantir la qualit et la disponibilit des

donnes mtier au moment opportun.
Vue densemble
La mise disposition des informations constitue un apport de valeur
essentiel pour les utilisateurs. Cet objectif doit associer une bonne gestion
des risques sur ces donnes dans le cadre de la gestion des ressources.
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPORT DE
VALEUR
CONFIDENTIALITE
APPLICATIONS
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 6-31 : Grer les donnes : DS11
Les exigences mtier privilgier sont lintgrit et la fiabilit des donnes. noter que la confidentialit, la disponibilit et la conformit des
donnes sont prises en compte dans dautres processus.
Pourquoi ?
Les systmes dinformation produisent et stockent des volumes de donnes considrables. Chaque tape technologique se traduit par un changement dchelle dans les stockages de donnes : le commerce en ligne avec
la trace des transactions, les photos et leur rsolution croissante, et prsent
la vido.
Les cots correspondants augmentent considrablement. Il sagit donc de
grer cet actif au mieux des intrts de lentreprise et des mtiers.
167

tableau 6-11.
OBJ. 04
OBJ. 19
Sassurer que l'information critique et condentielle nest pas accessible ceux qui ne doivent
pas y accder.
OBJ. 27
Assurer la conformit de linformatique aux lois et aux rglements.
Ce processus a sa logique propre et ninterfre pas avec les dispositions

prises dans les applications (habilitations et droits daccs, par exemple).
Parfois, les obligations rglementaires imposent de grer certaines donnes de faon spcifique (cest le cas pour les donnes de la comptabilit
informatise), le processus DS11 doit alors prvoir des dispositions
spciales (dure de conservation, modalits dextraction, etc.).
Il couvre le stockage, larchivage, la sauvegarde et la restitution des donnes. Le primtre du processus englobe lensemble des donnes informatiques. Idalement, il devrait aussi concerner les donnes informatises
stockes dans les mdias grs par les mtiers.
DEFINIR
DEFINIR DES PROCEDURES DE STOCKAGE

ET DARCHIVAGE DES DONNEES
AMELIORER
DEFINIR DES PROCEDURES DE GESTION DE LA MEDIATHEQUE

(inventaire et intgrit des mdias)
DEFINIR DES PROCEDURES DE MISE AU REBUT
SECURISEE DES MATERIELS OU DES MEDIAS
TENIR A JOUR LINVENTAIRE DES MEDIAS ET

TRAITER LES ANOMALIES DETECTEES
DEFINIR DES PROCEDURES DE SAUVEGARDE

ET DE RESTAURATION DES DONNEES
METTRE EN UVRE
CONTROLER
GERER DE FAON SECURISEE LA RECEPTION, LE TRAITEMENT,

LE STOCKAGE ET LA SORTIE DES DONNEES
VERIFIER QUE DES DONNEES DETRUITES OU A

DETRUIRE SONT IRRECUPERABLES
FOURNIR DES MOYENS SURS DELIMINATION DES DONNEES

ET DES MATERIELS DESTINES AU REBUT
TESTER LA RESTAURATION DES DONNEES

ET DES SYSTEMES DANS LES DELAIS REQUIS
168

Le processus rpond la fois des exigences de scurisation des donnes
vis--vis des ressources informatiques (taille des bases de donnes, saturation des mdias, temps daccs, etc.) et aux exigences des mtiers (dure
de conservation, modalits de restitution, criticit, etc.).
Tout part dune dfinition des principales procdures mettre en uvre
(stockage, archivage, mise au rebut, sauvegarde) et dune vision claire et
fiable de la mdiathque , cest--dire de la gestion des supports de
stockage.
La mise en uvre passe par la rigueur dapplication des procdures sans
en oublier les objectifs qui sont essentiellement la mise disposition
dinformations dans des dlais convenus. Le processus comprend donc
la fois une srie de dispositions habituelles en exploitation et les tests
associs qui seuls valident la pertinence densemble.
Une attention particulire est apporte la mise au rebut des donnes qui
peut aller jusquau suivi de la destruction physique de certains supports.
Notons enfin quune des difficults du processus concerne la relation aux
mtiers, au moins sur trois aspects :
la clarification du primtre de gestion des donnes numrises (prise
en compte des mdias grs par les mtiers) ;
la dfinition des exigences mtier et leur ngociation dans des SLA spcifiques (dure de conservation, dlais de restitution, rgles dhistorisation et de mise au rebut) ;
les incidences du rglementaire la fois sur les donnes et sur les applications, qui peuvent amener reconstituer une configuration complte
pour excuter des applications.
Mesures et contrles
Il faudra contrler la compltude, la fiabilit et la mise jour de la mdiathque dans son rle de recensement de lensemble des informations.
Les procdures de sauvegarde et darchivage font lobjet dexcutions
rgulires dont on vrifiera la mise en uvre et les rsultats (cycles de
sauvegarde, supports darchivage, stockage, liens avec le PRA).
Le test densemble (rcupration des informations) est un contrle essentiel
mener sur le processus.
On mesurera en particulier les incidents et les problmes relevant de ce
processus et conduisant une indisponibilit des donnes pour les utilisateurs.
Enfin, on vrifiera la cohrence du processus global de gestion des donnes
entre les mtiers et la DSI.
169
Le service exploitation est habituellement responsable de lensemble du
processus de sauvegarde, darchivage et de scurisation des donnes. Il
sagit du volet industriel du processus, lequel est bien souvent insr
dans un contrat tiers.
Le contrle interne
Il est souhaitable de confier une entit de contrle interne la DSI la responsabilit de tester les dispositions prises dans le plan de gestion des
donnes : essais de rcupration, examen des indicateurs de pilotage et
des incidents.
Cette instance pourra aussi avoir un rle dans le cadre des relations avec
les mtiers afin de complter le fonctionnement industriel du processus
avec des exigences mtier plus nuances (donnes critiques, rgles de
mise au rebut, rgles dhistorisation, etc.).
PO2, AI4, DS1, DS4,

DS5
DS13, SE1
DS11 : Grer les

donnes
Dictionnaire des donnes

donnes
dadministration
Plan de stockage et de protection
hors site
Plan et politiques de scurit
informatique
Instructions dexploitation pour la

gestion des donnes
processus
170
DS12
Grer lenvironnement physique
Lenvironnement physique sous-tend le fonctionnement des installations informatiques et doit ce titre faire lobjet dune gestion
adapte.
Il sagit de choisir les installations adquates et de concevoir des processus efficaces de gestion des accs physiques permettant de limiter les
risques dinterruption de lactivit du fait de dommages subis par le matriel
ou le personnel.
Vue densemble
Le processus de gestion de lenvironnement physique relve essentiellement
de la gestion des risques dans une optique doptimisation des ressources
informatiques dinfrastructures.
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPORT DE
VALEUR
CONFIDENTIALITE
APPLICATIONS
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 6-34 : Grer lenvironnement physique : DS12
En termes dexigences mtier, lemphase est mise sur lintgrit et la

disponibilit.
171
Pourquoi ?
Lenvironnement physique, comprenant les sites dhbergement des installations et les alimentations (lectricit, fluides et lignes de communication), doit tre gr pour protger les ressources informatiques des
sinistres possibles (dtrioration ou destruction accidentelle, accs indsirables, vols, sabotages et malveillance).
tableau 6-12.
OBJ. 14
OBJ. 19
Sassurer que l'information critique et condentielle nest pas accessible

ceux qui ne doivent pas y accder.
OBJ. 21
Sassurer que les services et linfrastructure informatique peuvent rsister/se rtablir convenablement en cas de panne due une erreur, une
attaque dlibre ou un sinistre.
OBJ. 22
Sassurer quun incident ou une modication dans la fourniture dun service informatique na quun impact minimum sur lactivit.
Le primtre du processus comprend les sites physiques et les quipements ou raccordements permettant aux installations informatiques
de fonctionner. Seront pris en considration tous les risques de rupture
dalimentation de fluides, dlectricit ou des tlcommunications.
Les vulnrabilits lies lenvironnement sont galement tudies de
faon y apporter une rponse dans le cadre des plans de secours. ce
titre, on sintressera en particulier aux risques dintrusion physique et de
vol ou aux risques lis aux facteurs environnementaux (inondations,
incendie, explosions, etc.).
Le primtre doit inclure aussi bien les sites propres lentreprise que
les sites grs par des tiers, mme si les modalits de gestion sont diffrentes.
172
DEFINIR
DEFINIR DES MESURES DE SECURITE PHYSIQUE
CONFORMES AUX EXIGENCES METIER
DEFINIR LES PROCEDURES DAUTORISATION
ET DACCES PHYSIQUES AUX SITES
DEFINIR DES MESURES DE PROTECTION
CONTRE LES FACTEURS ENVIRONNEMENTAUX
CONTROLER
METTRE EN UVRE
CHOISIR LE(S) SITE(S) PHYSIQUE(S)
DES EQUIPEMENTS INFORMATIQUES
ETABLIR LES RESPONSABILITES CONCERNANT
LA SURVEILLANCE ET LA SECURITE PHYSIQUE
CONTROLER LES ACCES AUX SITES, BATIMENTS

ET ZONES SECURISEES
CONTROLER LES RISQUES ENVIRONNEMENTAUX
AVEC DES DISPOSITIFS SPECIALISES
GERER ET MAINTENIR LENVIRONNEMENT PHYSIQUE

Le processus est bas sur la dfinition des exigences mtier, les procdures daccs aux sites et les mesures de protection vis--vis des risques
environnementaux.
Notons que ces exigences doivent faire lobjet de ngociations pour
quelles correspondent peu prs ltat du march, en particulier en
termes de sous-traitance aux tiers.
Une fois ces procdures tablies, il sagit de dfinir un responsable par site
et de dployer les procdures correspondantes. Ensuite, les procdures et
les responsabilits tant fixes, on passe la gestion oprationnelle de la
scurit physique.
Le processus DS12, comme tous les processus lis la scurit, est sujet
des contrles priodiques, la fois sur les risques environnementaux et
sur les accs.
173
Mesures et contrles
Les mesures lies au processus conduisent laborer un tableau de bord
des incidents segments par domaine, site et criticit : intrusions, facteurs
environnementaux, pertes de disponibilit (et leurs impacts).
Les sites sous la responsabilit de tiers doivent faire lobjet de mesures et
de contrles spars de faon faire peser les exigences damlioration
dans les dispositifs contractuels. On aura soin en particulier daligner les
indicateurs de mesure aux obligations contractuelles (pnalits, responsabilit civile, etc.).
Les contrles porteront sur les tests priodiques des plans de secours,
la pertinence des procdures et la formation des personnes concernes.
Il est en charge de lensemble du processus. Il doit ensuite dlguer sa
responsabilit par site ou par tiers contractant.
PO2, AI4, DS1, DS4,

DS5
SE1
DS12 : Grer
lenvironnement
physique

donnes
Exigences de lenvironnement
physique

processus
174
DS13
Grer lexploitation
Le processus de gestion de lexploitation concerne lensemble du fonctionnement et de la maintenance des ressources informatiques.
Ce processus conduit dfinir des procdures dexploitation permettant une
gestion efficace des traitements programms et une protection des donnes
sensibles, afin de garantir les niveaux de services dexploitation ; il est aussi
ncessaire de surveiller et de maintenir linfrastructure informatique.
Vue densemble
Le processus DS13 est un processus oprationnel orient sur loptimisation de lensemble des ressources informatiques dans une optique defficacit et defficience.
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPORT DE
VALEUR
CONFIDENTIALITE
APPLICATIONS
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 6-37 : Grer lexploitation : DS13
Pourquoi ?
Lexploitation des ressources informatiques devient de plus en plus
industrialise au sens de lautomatisation et du caractre rptitif des
tches. Les oprations de base ne laissent pas place limprovisation ce
qui signifie que la totalit des tches dexploitation fait lobjet de procdures prcises et dtailles, y compris les demandes de drogations ou les
exceptions.
175
tableau 6-13.
OBJ. 03
OBJ. 21
Sassurer que les services et linfrastructure informatique peuvent rsister/se rtablir convenablement en cas de panne due une erreur, une attaque dlibre ou un sinistre.
OBJ. 23
Sassurer que les services informatiques sont disponibles dans les conditions requises.
Ces objectifs sont considrs du ct de lutilisateur et ncessitent dtre

traduits de faon oprationnelle dans les procdures.
Le primtre du processus DS13 comprend lensemble des ressources
informatiques, que ce soit les infrastructures, les applications, les donnes
et le personnel intervenant. Il sapplique au fonctionnement rgulier, la
maintenance et la rponse aux incidents dexploitation.
DEFINIR
DEFINIR DES PROCEDURES DEXPLOITATION INFORMATIQUE

DEFINIR DES PROCEDURES DE SURVEILLANCE
DE LINFRASTRUCTURE INFORMATIQUE
DEFINIR ET PLANIFIER UNE MAINTENANCE PREVENTIVE
DE LINFRASTRUCTURE INFORMATIQUE
CONTROLER
METTRE EN UVRE
CONTROLER ET SURVEILLER LINFRASTRUCTURE

ET LES TRAITEMENTS REALISES
ELABORER LES PLANNINGS EN FONCTION

DE LA CHARGE DE TRAVAIL
VERIFIER QUE LE PERSONNEL CONNAIT LES

TACHES DEXPLOITATION DONT IL DEPEND
GERER LEXPLOITATION CONFORMEMENT

AUX NIVEAUX DE SERVICES CONVENUS
METTRE EN PLACE DES DISPOSITIFS DE SECURITE PHYSIQUE
POUR LES INFORMATIONS SENSIBLES
176

Le processus part dune dfinition de lensemble des procdures
dexploitation et de surveillance des ressources informatiques. On
sintresse galement au plan de maintenance prventive des installations.
La mise en uvre porte tout dabord sur les planifications journalire,
hebdomadaire et mensuelle pour, en particulier, concilier les exigences
de disponibilit et les oprations mener (changements, maintenance).
La prise en compte des niveaux de services contracts pour bien grer
lexploitation reste une exigence permanente traduite dans les procdures.
On sintressera galement aux dispositifs dploys pour assurer la scurit physique des installations.
Enfin, le processus devra contribuer la mise jour de linventaire des
quipements.
Mesures et contrles
Les mesures sexercent essentiellement sur le plan de la disponibilit
et des performances : nombre dinterruptions de services, pourcentage
de traitements effectus en respect du planning de production, causes
des interruptions (inadaptation des procdures, non-respect des procdures par le personnel, indisponibilits matrielles, etc.).
La stabilit de lensemble peut tre apprcie au travers du nombre de
changements effectus par type de ressource (personnel, applications,
infrastructures).
Les vnements indsirables (incidents, problmes) feront lobjet de tickets
dincident destination des processus concerns.
Il est naturellement le pilote et le responsable du processus.
177

AI4, AI7, DS1, DS4
DS9, DS11
DS8, DS10, SE1
DS13 : Grer
lexploitation

dadministration
Plans de mise en production, de
publication et de diffusion des
logiciels
Plan de stockage et de protection
hors site
des actifs
Instructions dexploitation pour la
gestion des donnes
Tickets dincidents
Historiques des erreurs
processus
En rsum
Le domaine DS dcrit compltement les conditions de fourniture des services informatiques. Il dcrit en premier lieu les relations avec les mtiers
(DS1) et avec les tiers (DS2). Ce prambule permet de cadrer contractuellement lensemble des services.
Pour lessentiel, ce domaine est le plus proche des processus dITIL correspondants. Seul le DS7 semble ne pas tre dcrit dans ITIL.
178
Chapitre 7
Surveiller
et valuer
Les processus dcrits dans ce chapitre traitent de la gestion de la performance, de la surveillance du contrle interne, du respect des normes rglementaires et de la gouvernance.
SE1 Surveiller et valuer la performance des SI
SE2 Surveiller et valuer le contrle interne
SE3 Sassurer de la conformit aux obligations externes
SE4 Mettre en place une gouvernance des SI
SE1
Surveiller et valuer la performance

des SI
La performance du systme dinformation doit faire lobjet dune surveillance

et dune valuation afin de sassurer que la politique informatique est mise
en uvre de faon performante, que les ressources sont utilises de faon
optimise et que les projets et services sont raliss conformment aux
objectifs fixs. Le Balanced Scorecard (BSC) est un outil adapt pour servir
de support au processus de surveillance et dvaluation.
Vue densemble
Le processus SE1 rsulte principalement dune volont de mettre en place
un mcanisme de mesure de la performance du systme dinformation qui
permette de rpondre aux critres defficacit et defficience du systme
dinformation pour les mtiers.
179
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPORT DE
VALEUR
CONFIDENTIALITE
APPLICATIONS
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 7-1 : Surveiller et valuer la performance du SI : SE1
Cette volont amne la DSI dresser des tableaux de bord et un mcanisme de reporting propre informer la direction gnrale et le conseil
dadministration de lentreprise de la contribution de linformatique aux
mtiers de lentreprise et de latteinte des objectifs fixs.
Pourquoi ?
Le processus SE1 centralise les indicateurs de fonctionnement des processus CobiT des domaines PO, AI et DS. Il permet donc de construire un
tableau de bord du fonctionnement de la DSI.
La mesure de la performance de linformatique conduit le DSI planifier
des actions correctives pour remdier aux carts constats grce au
tableau de bord. Ceci est la base de la boucle damliorations de tous les
processus de CobiT.
annexe 2, Objectifs du systme dinformation et processus CobiT ), le processus SE1 doit permettre de matriser les objectifs prsents dans le
tableau 7-1.
Tableau 7-1 : Objectifs du processus SE1
OBJ. 01
OBJ. 02
Ragir aux exigences de la gouvernance en accord avec les orientations

du CA.
180
Chapitre 7 Surveiller et valuer
Tableau 7-1 : Objectifs du processus SE1(suite)
OBJ. 12
Sassurer de la transparence et de la bonne comprhension des cots,

bnces, stratgie, politiques et niveaux de services des SI.
OBJ. 28
Sassurer que linformatique fait preuve dune qualit de service efciente en matire de cots, damlioration continue et de capacit
sadapter des changements futurs.
Le processus SE1 couvre lensemble des mesures et des contrles de la

performance du SI, effectus sur les processus des domaines PO, AI et DS
de la DSI.
La figure 7-2 reprsente les flux internes du processus SE1.
DEFINIR
SE1 Surveiller et valuer

la performance des SI
COMMUNIQUER
FAIRE VALIDER
LES OBJECTIFS
PAR LE METIER
ET LES AUTRES
PARTIES
PRENANTES
DEFINIR LAPPROCHE DE SURVEILLANCE
Objectifs de
performances,
de mesures, etc.
LISTER LES OBJECTIFS MESURABLES

FIXES PAR LE MANAGEMENT
Plan dactions
correctives
DEFINIR DES INDICATEURS DE PERFORMANCE
AMELIORER
RENDRE COMPTE
DE LA
PERFORMANCE A
LA DIRECTION
GENERALE
Rapport de
gestion
METTRE EN UVRE
IDENTIFIER ET SURVEILLER LES ACTIONS

DESTINEES A AMELIORER LA PERFORMANCE
METTRE EN PLACE UNE METHODE DE SURVEILLANCE
EVALUER
EVALUER PERIODIQUEMENT LA PERFORMANCE
PAR RAPPORT AUX OBJECTIFS
Figure 7-2 : Reprsentation schmatique des ux internes du processus SE1

La mise en place dun processus de surveillance sapparente au processus
damlioration continue (roue de Deming ou boucle PDCA) prn par les
normes de systme de management. Ce processus sintresse lanalyse des
rsultats des activits de surveillance des processus, fournis par les activits
de contrle (comme la revue des processus/projets/oprations, les enqutes
de satisfaction, les auto-valuations, les contrles intgrs/automatiss
181
dans les processus des mtiers), et la mise en place des actions issues de
ces analyses ainsi qu leur suivi.
Le processus SE1 est aliment par les rsultats de la majeure partie des
processus oprationnels, en particulier DS et AI. Un cadre prcis permet de
collecter les informations pour les rendre pertinentes dans le cadre de la
surveillance.
Le processus SE1 permet de proposer une valuation de la performance
des SI et den suivre lvolution. Lensemble fait lobjet de comptes-rendus
destins la direction gnrale ou aux rapports annuels.
Enfin, la surveillance conduit un plan dactions correctives qui est le
rsultat de lanalyse des causes des carts et des dysfonctionnements. Le
plan dactions correctives doit faire apparatre les responsabilits associes
et les modalits de suivi de celles-ci.
Mesures et contrles
concernent la vrification des objectifs prsents au tableau 7-1. Ces mesures
portent principalement sur la couverture par des revues de lensemble des
processus, sur le nombre dactions rellement mis en uvre selon les
conditions de dlais et de rsultats fixs initialement, et sur la satisfaction
des parties prenantes quant la qualit du reporting.
le taux de couverture de lensemble des processus par des mtriques, le
respect de la frquence de publication des tableaux de bord ainsi que le
taux dautomatisation de la production des tableaux de bord.
Le directeur gnral
Compte tenu de la finalit de ce processus, le client sera trs logiquement
la direction de lentreprise. Elle attend un reporting de qualit conformment
lapproche de la surveillance quelle a fixe.
Son rle est de sassurer que ce processus est bien mis en uvre, conformment aux exigences de la direction gnrale. Le DSI est le pilote de ce
processus.
Le contrle interne
On parle parfois de fonction audit au sein de la DSI, ce qui nest pas
conforme aux rgles de sparation des tches en la matire. Nous prfrons parler de contrle interne pour qualifier la fonction qui va se charger
182
de faon oprationnelle de piloter les rsultats des contrles remonts par

lensemble des processus de la DSI.

PO5, PO10, AI6,
DS1... DS13, SE2,
SE3, SE4
PO1, PO2, PO4, PO8,

PO9, DS1, SE2
SE1 : Surveiller et
valuer la performance
des SI
projets
Rapports sur le statut des
changements
processus
utilisateurs
Rapports sur lefficacit des
contrles des SI
Rapports sur la conformit des
activits aux obligations externes
Etat de situation de la gouvernance
des SI
Entre de la performance dans le

planning SI
Plans dactions correctives
Historique des vnements de risque
et des tendances
processus
Figure 7-3 : Les entres-sorties du processus SE1
SE2
Surveiller et valuer le contrle interne
Il sagit du contrle que la DSI doit mettre en place pour sassurer que les
contrles et les vrifications mis en uvre pour valuer la performance du
SI sont bien exploits et toujours appropris. Dans le rfrentiel CobiT, le
contrle interne est dlgu chacun des responsables (tudes, exploitation) de la DSI. Cependant, il existe une fonction de contrle interne qui
vrifie que lensemble du processus fonctionne.
Vue densemble
un mcanisme de surveillance du contrle interne afin dapprcier les risques de drives du fonctionnement de la DSI (gestion des risques) et ainsi
183
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPORT DE
VALEUR
CONFIDENTIALITE
APPLICATIONS
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 7-4 : Surveiller et valuer le contrle interne : SE2
de sassurer de lapport de valeur du SI. Ceci permet de rpondre aux critres defficacit et defficience du systme dinformation pour les mtiers.
Pourquoi ?
Le fonctionnement de la DSI est soumis de multiples contraintes et ce
qui tait performant un moment donn ne le sera probablement plus
un autre. De plus, la routine des activits de contrle et labsence de recul des
acteurs de ces activits peuvent aboutir des manquements ou des erreurs
dapprciation.
processus SE2 doit permettre de matriser les objectifs prsents dans le
tableau 7-2.
OBJ. 14
OBJ.17
OBJ. 21
OBJ. 27
184
Le processus couvre lensemble du contrle interne de la DSI : il est la tour

de contrle de lensemble vers laquelle convergent les rsultats des
indicateurs de mesure de chaque processus.
DEFINIR
AMELIORER
DEFINIR UN SYSTEME DE CONTROLE INTERNE ET LINTEGRER

AU REFERENTIEL DES PROCESSUS INFORMATIQUES

PROPOSEES PAR LE MANAGEMENT
METTRE EN UVRE
COMMUNIQUER
RENDRE COMPTE
AUX PARTIES
PRENANTES
Rapport sur
lefficacit
des contrles
des SI
RAPPORTER AU
MANAGEMENT
LES ANOMALIES
DETECTEES
CONDUIRE UNE REVUE GENERALE DU CONTROLE INTERNE
SURVEILLER
CONDUIRE UN PROGRAMME PERMANENT
DAUTO-EVALUATION DU CONTROLE
SURVEILLER ET CONTROLER LES ACTIVITES DU

CONTROLE INTERNE
FAIRE REALISER DES REVUES SUR LEFFICACITE

DES CONTROLES PAR DES TIERS
SURVEILLER LA PERFORMANCE
DES REVUES INDEPENDANTES, DES AUDITS
ET DES INVESTIGATIONS
IDENTIFIER ET ENREGISTRER LES ANOMALIES DETECTEES

PAR LES CONTROLES

La mise en place dun processus de surveillance et dvaluation du contrle
interne est un mcanisme dassurance qui ncessite une prise de conscience
du management de la DSI. Il sagit en effet de mettre en place un double
niveau de contrle, au-dessus du DSI.
Ce processus sintresse principalement lanalyse des rsultats des activits de contrle interne pour en apprcier la pertinence et lancer des
actions correctives afin de faire voluer les pratiques du contrle interne. Il
suppose au pralable la mise en place effective du contrle interne de
linformatique. Le processus SE2 salimente partir des contrles effectus
sur les principaux processus de la DSI.
Mesures et contrles
concernent la vrification des objectifs prsents au tableau 7-2. Ces
mesures portent principalement sur le nombre de faiblesses identifies qui
185
concernent la pratique du contrle interne et sur le nombre dactions

damlioration des pratiques du contrle interne.
La mesure de la mise en uvre de ce processus passe principalement
par le taux de couverture de lensemble des activits du contrle
interne, le dlai entre la dtection dune dfaillance et laction corrective
associe.
Il doit sassurer que ce processus est bien dfini et mis en uvre. Le DSI
est le pilote de ce processus en liaison avec laudit interne de lentreprise.
Les responsables de la DSI
Les principaux responsables de la DSI (tudes, exploitation, etc.) sont en
charge des contrles effectuer sur les processus qui leur reviennent.
Le contrle interne
Le contrle interne contribue ce processus puisquil est charg de prsenter la faon dont il sorganise pour ensuite produire le tableau de bord
DSI.
SE1
PO4, PO6, SE1, SE4
SE2 : Surveiller et
valuer le contrle
interne
Rapports sur lefficacit des contrles

des SI

processus
186
SE3
Sassurer de la conformit
aux obligations externes
Les entreprises sont de plus en plus soumises des exigences rglementaires lies aux mtiers dont lvolution est souvent rapide. La contribution du SI aux mtiers expose la DSI lobligation de conformit. De plus,
les clients de lentreprise peuvent avoir leurs propres exigences vis--vis
des mtiers qui simposent la DSI, en particulier lorsque les produits et
les services de la DSI sont livrs aux clients de lentreprise.
Vue densemble
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPORT DE
VALEUR
CONFIDENTIALITE
APPLICATIONS
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 7-7 : Sassurer de la conformit aux obligations externes : SE3

un mcanisme de contrle de conformit afin de rpondre aux exigences
lgales et rglementaires, et ainsi contribuer lalignement stratgique et
la gestion des risques. Ceci permet de rpondre aux critres de conformit et de fiabilit du systme dinformation pour les mtiers.
Pourquoi ?
La conformit rglementaire est une obligation lgale (par exemple, la
conformit SOX ou lIFRS, ou encore la dclaration des donnes personnelles la CNIL). La conformit aux exigences des clients ressortit du
contrat qui lie les parties (exemple dobligation contractuelle : la confidentialit de certaines informations).
187
Ces deux facettes des obligations externes ncessitent dtre soigneusement

prises en compte, car les consquences peuvent tre graves en cas de problme.
annexe 2, Objectifs du systme dinformation et processus CobiT ), le processus SE3 doit permettre de matriser lobjectif prsent dans le tableau 7-3.
OBJ. 27
Le primtre du processus englobe donc lensemble des lois et des rglements qui sappliquent linformatique de lentreprise.
Ce processus intgre aussi la prise en compte des obligations contractuelles.
DEFINIR
SE3 Sassurer de la conformit

aux obligations externes
DEFINIR UN PROCESSUS DIDENTIFICATION DES EXIGENCES

LEGALES ET REGLEMENTAIRES APPLICABLES AUX SI
Catalogue des
exigences lgales et
rglementaires
METTRE EN UVRE
COMMUNIQUER
RENDRE COMPTE
AU MANAGEMENT
SENSIBILISER LE
PERSONNEL
INFORMATIQUE A
LA CONFORMITE
Rapport sur
la conformit
des activits
informatiques
EVALUER LIMPACT DES EXIGENCES REGLEMENTAIRES
ALIGNER LES POLITIQUES, LES NORMES ET LES PROCEDURES

SUR LES EXIGENCES REGLEMENTAIRES
AMELIORER
ENTREPRISES EN CAS DE NON-CONFORMITE
EVALUER
EVALUER LA CONFORMITE DES POLITIQUES, DES NORMES ET
DES PROCEDURES AUX EXIGENCES REGLEMENTAIRES
EVALUER LA CONFORMITE DES ACTIVITES INFORMATIQUES AUX
POLITIQUES, AUX NORMES ET AUX PROCEDURES

La mise en place de ce processus passe par la dfinition dune fonction de
veille rglementaire et de conformit aux diverses exigences. Cette fonction a un rle de contrle sur lensemble des pratiques de la DSI vis--vis
188
de lensemble de ces exigences ; elle doit avoir toute lautorit ncessaire

pour faire voluer les pratiques de la DSI et les mettre en conformit.
Mesures et contrles
concernent la vrification de lobjectif prsent au tableau 7-3. Ces
mesures portent principalement sur le nombre de non-conformits dtectes
ds lors quune action corrective a t mise en uvre.
La mesure de la mise en place de ce processus passe principalement par la vrification du dlai entre lapparition dune nouvelle exigence et sa prise en
compte dans les pratiques de la DSI, et la vrification du dlai entre la dtection
dune non-conformit et la mise en uvre dune action corrective associe.
Il sassure que ce processus est bien dfini et mis en uvre, et ce titre, il
en est la fois le garant et le responsable.
La fonction contrle de conformit

Elle doit sassurer que lensemble des pratiques lies au SI est conforme
aux exigences lgales et contractuelles.
noter que cette fonction doit sappuyer sur une instance de coordination
avec les mtiers de faon actualiser sans dlai les volutions constates
sur les exigences lgales et rglementaires auxquelles se conformer.

Entres externes
CobiT
PO4, SE1, SE4
SE3 : S assurer de la
conformit aux
obligations externes
Recueil des exigences lgales et

fourniture des services
informatiques
Rapport sur la conformit des activits
informatiques aux exigences lgales
et rglementaires externes
Exigences lgales et
rglementaires
189
SE4
Mettre en place une gouvernance des SI
La mise en place dune gouvernance des SI est une responsabilit de la

direction de lentreprise au plus haut niveau. Celle-ci doit sintgrer dans la
gouvernance gnrale de lentreprise, et tre compatible avec les diffrents
rfrentiels applicables dans cette dernire.
Vue densemble
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES
INFORMATIQUES
EFFICACITE
ALIGNEMENT
STRATEGIQUE
EFFICIENCE
APPORT DE
VALEUR
CONFIDENTIALITE
APPLICATIONS
INFORMATIONS
GESTION DES RISQUES
INTEGRITE
GESTION DES
RESSOURCES
DISPONIBILITE
MESURE DE
LA PERFORMANCE
CONFORMITE
INFRASTRUCTURES
PERSONNES
Lgende
FIABILITE
Primaire
Secondaire
Slectionn
Figure 7-10 : Mettre en place une gouvernance des SI : SE4

un rfrentiel de gouvernance relatif aux 5 domaines de gouvernance prconiss par CobiT (alignement stratgique, apport de valeur, gestion des
ressources, gestion des risques et mesure de la performance). Ceci permet
de rpondre principalement aux critres defficacit et defficience du systme dinformation pour les mtiers.
Pourquoi ?
Il sagit de lessence mme de CobiT. Le processus SE4 pilote dune
certaine faon la conformit de lentreprise aux bonnes pratiques de la
gouvernance SI.
190
processus SE4 doit permettre de matriser les objectifs prsents dans le

tableau 7-4.
OBJ. 02
OBJ. 12
Sassurer de la transparence et de la bonne comprhension des cots, bnces, stratgie, politiques et niveaux de services des SI.
OBJ. 27
OBJ. 28
Sassurer que linformatique fait preuve dune qualit de service efciente en matire de cots,
damlioration continue et de capacit sadapter des changements futurs.
Le primtre du processus comprend lensemble des processus de la DSI.

Il sagit de mettre en place une organisation qui puisse garantir que la gouvernance des systmes dinformation sera effective.

DEFINIR
COMMUNIQUER
FACILITER LA
COMPREHENSION DE LA
STRATEGIE DES SI (rles
des SI, opportunits
technologiques, etc.)
DEFINIR UN CADRE DE GOUVERNANCE DES SI
AMELIORER
DESIGNER LE LEADERSHIP
RESOUDRE LES PROBLEMES DETECTES PAR LES

EVALUATIONS INDEPENDANTES
Rapport sur la
gouvernance
des SI
DEFINIR LES PROCESSUS

DEFINIR LES ROLES ET RESPONSABILITES ET LES
STRUCTURES ORGANISATIONNELLES
IMPLIQUER LE METIER
DANS LES PRISES DE
DECISION LIEES AUX SI
METTRE EN UVRE LES RECOMMANDATIONS

ADOPTEES PAR LE MANAGEMENT
CONTROLER
METTRE EN UVRE
COMMUNIQUER
LAPPETENCE POUR LE
RISQUE INFORMATIQUE
METTRE EN PLACE LA GOUVERNANCE DES SI
FOURNIR UNE ASSURANCE INDEPENDANTE SUR

LA PERFORMANCE ET DE LA CONFORMITE AUX
POLITIQUES, NORMES ET PROCEDURES
METTRE EN PLACE DES INSTANCES DE GOUVERNANCE

(comit stratgique des SI )
RENDRE COMPTE AU CA
EN TEMPS OPPORTUN
SUR LA STRATEGIE, LA
PERFORMANCE ET LES
RISQUES INFORMATIQUES
ALIGNER LA STRATEGIE INFORMATIQUE

SUR LA STRATEGIE METIER

La mise en place de ce processus ncessite que la contribution des SI la
performance de lentreprise soit parfaitement comprise tous les niveaux
de lentreprise, que tous les autres processus soient mis en uvre et quils
produisent les effets escompts.
191
Mesures et contrles
concernent la vrification des objectifs prsents au tableau 7-4. Ces
mesures portent principalement sur le nombre dcarts dtects dans la
mise en uvre de la gouvernance.
celle du nombre de personnes sensibilises et formes aux principes de
gouvernance, y compris au plus haut niveau de lentreprise (conseil
dadministration, direction gnrale), et du temps consacr par la direction
gnrale et le conseil dadministration aux aspects lis au SI (le nombre de
rapports denqutes de satisfaction demands et produits).
Le conseil dadministration et le directeur gnral
Il sagit dune responsabilit dvolue au plus haut niveau de direction de
lentreprise (le conseil dadministration avec lassistance de la direction gnrale). Son rle est de sassurer que toutes les instances parties prenantes dans
la gouvernance des SI ont bien t mises en place et sont oprationnelles.

PO4,PO5, PO9, SE2,
SE3
PO1, PO4, PO5, PO9,

SE1
SE4 : Mettre en place

une gouvernance des SI
Amlioration du rfrentiel des

processus
Etat de situation de la gouvernance
des SI
Rsultats attendus des
investissements mtier qui
sappuient sur les SI
Orientation stratgique de lentreprise
pour les SI
Apptence de lentreprise pour le
risque informatique
Rfrentiel des processus

informatiques
Evaluations des risques et rapports
associs
Recueil des exigences lgales et
fourniture de services
informatiques
192
En rsum
Les processus du domaine SE dcrivent 4 niveaux de surveillance et dvaluation de lensemble du dispositif (PO, AI et DS). Le processus SE1 est
central du fait de son rle de contrle interne de lensemble. Il doit servir
de point de dpart la boucle damlioration des processus dploys (un
peu comme l amlioration continue dans ITIL V3).
Le processus SE2 est plus difficile cerner, car il est mis en place pour surveiller le bon fonctionnement du prcdent. Cela impose quun responsable indpendant, de prfrence laudit interne, soit dsign.
Le processus SE3 a le mrite disoler le contrle de la conformit. Enfin,
SE4 donne un moyen dauditer la mise en place de la gouvernance des SI.
193
PARTIE
III
Mettre en uvre
CobiT
Les grandes directions des systmes dinformation font parfois penser
des petites entreprises qui seraient pilotes partir de la production
industrielle et du service de recherche et dveloppement. Cest assez
normal, pensera-t-on, puisque la direction informatique doit trouver au
sein de son entreprise lensemble des services de support complmentaires ses activits.
Les services de support (contrle de gestion, achats, ressources humaines,
communication) offrent un cadre incontournable en garantissant le fonctionnement de processus cls. Cependant, ils se rvlent inadapts la
prise en compte des spcificits de la DSI pour la gouvernance des SI.
Implanter CobiT, cest se mettre dans une perspective de plus grande autonomie de gestion en dclinant en particulier les fonctions de support de
lentreprise au sein de la direction informatique et pour le SI au sens large.
Ceci tant, il est illusoire et dangereux de vouloir embrasser trop large car
il sagit toujours in fine de projets de transformation.
Au cours des chapitres suivants, nous allons prsenter quelques exemples
de mise en uvre, tirs de cas rels, avec diffrents angles dattaque.
195
Chapitre 8
CobiT pour laudit
CobiT a t et reste le rfrentiel daudit de la gouvernance des SI. Son

utilisation dans les missions daudit est quasi immdiate grce sa structure de base, aux nombreuses publications qui viennent dtailler encore
les objectifs de contrle et aux outils proposs sur le march pour automatiser les contrles.
Le code professionnel dthique

LISACA a tabli un code professionnel dthique pour cadrer les interventions daudit de ses membres. Il sapplique tous les auditeurs certifis
CISA (Certified Information Systems Auditor), lesquels sengagent respecter les
points suivants :
soutenir la mise en uvre et encourager la conformit aux standards,
procdures et contrles appropris pour les systmes dinformation ;
remplir leurs devoirs avec la diligence et la conscience professionnelle
appropries, en accord avec les standards professionnels et les bonnes
pratiques ;
servir lintrt des parties prenantes de manire licite et honnte, tout
en observant une conduite exemplaire, sans simpliquer dans des actes
qui pourraient discrditer la profession ;
protger la proprit et la confidentialit des informations recueillies
lors de leurs missions, moins quune communication ne soit requise
par une autorit lgale. Ces informations ne seront pas utilises pour en
tirer un bnfice personnel, ni communiques des tiers non autoriss ;
maintenir leur comptence niveau dans leurs domaines respectifs, et
accepter dentreprendre uniquement les activits que leur comptence
professionnelle permettra de raisonnablement mener bien ;
197
Partie III Mettre en uvre CobiT
informer les parties appropries des rsultats des travaux effectus, en

communiquant tous les faits significatifs connatre ;
contribuer la formation des parties prenantes en amliorant leur
comprhension de la scurit et du contrle des systmes dinformation.
Cette charte place lauditeur devant ses responsabilits, lesquelles seront
dautant plus faciles respecter quil aura une indpendance complte par
rapport au primtre de laudit.
La mission daudit
Une mission daudit part dune lettre de mission fixant le primtre de
laudit et les responsabilits attribues. Ensuite, lauditeur doit construire
un rfrentiel daudit qui tablira une transparence totale entre la mission
confie et les investigations mener.
CobiT est utilis comme une base solide de points de contrle, il permet
de slectionner les processus critiques et de les valuer. Il est parfois
ncessaire de le complter en fonction des spcificits du sujet (pour un
audit de scurit, il conviendra, par exemple, dajouter les aspects propres
aux dispositifs de scurit existants ; il en sera de mme pour tout ce qui a
trait au domaine lgal et rglementaire). Enfin, CobiT permet des auditeurs non informaticiens de mener de faon professionnelle des audits
informatiques intgrs aux audits gnraux.
Les objectifs de contrle de CobiT constituent une excellente base pour
prparer un rfrentiel daudit. Il suffit ensuite, au cas par cas, de les
toffer de tests dtaills en fonction de la spcificit du primtre
auditer (ils sont parfois dcrits dans des publications spcialises
publies par lISACA).
Le tableau 8-1 donne une ide du formalisme dun rfrentiel daudit qui
procde par tape et prcise des objectifs de contrle, lesquels sont
ensuite dtaills.
Tableau 8-1 : Structure dun rfrentiel daudit
Obtenir linformation
tape 1
Test dtaill
Procdures
Identier et recueillir toutes les procdures qui existent concernant la continuit de service et le plan de secours en cas de
sinistre.
198
Chapitre 8 CobiT pour laudit
Tableau 8-1 : Structure dun rfrentiel daudit (suite)
tape 2
Test dtaill
Recueillir la documentation applicable

Recueillir :
une copie du plan dorganisation en cas de sinistre ;
une liste des responsables ;
linventaire ;
les contrats avec les tiers.
tape 3
Objectifs de contrle
Vrier que le plan de secours en cas de sinistre majeur est adapt
pour garantir la remise en route du systme dinformation en
temps voulu, en accord avec les exigences des mtiers.
Test dtaill
Existence du plan de secours, etc.
La mission daudit se droule en gnral en trois phases.

1. Ltude prliminaire, qui comprend la prise de connaissance de lentit
contrler, le dpistage des risques et lorientation de la mission.
2. La ralisation de laudit proprement parler (excution des travaux de
contrle).
3. La conclusion de la mission (synthse, prsentation orale et rdaction
du rapport).
Il existe aussi dautres classifications des audits selon leur profondeur
technique, les moyens dinvestigation utiliss (intrusion, outillage) ou le
primtre apprhend.
Lapport de CobiT
La structure de CobiT offre lauditeur une classification trs solide :
domaines, processus, objectifs de contrle ;
critres dinformation (efficacit, efficience, confidentialit, intgrit,
disponibilit, conformit et fiabilit) ;
ressources (applications, infrastructure, information et personnes).
cette structure se rattache un dtail gnrique pour chaque objectif
de contrle, prsent comme suit dans le document IT Assurance Guide:
Using CobiT :
Objectif de contrle
Inducteurs de valeur
Inducteurs de risques
Cette notion de valeur lie un objectif de contrle est tout fait intressante puisquelle tend le primtre du contrle, en incluant non seulement
la matrise des risques, mais aussi la cration de valeur.
199
On trouve ensuite un plan de contrle pour cet objectif, puis des tests
dtaills. titre dexemple, lobjectif de contrle DS5.8 sur la gestion des
cls de chiffrement donne lieu quatre pages extrmement prcises de
tests raliser. Et si ce niveau de dtail se rvlait insuffisant, il suffirait de
puiser dans dautres publications (voir chapitre 3, Prsentation dtaille
de CobiT ) pour en dfinir encore un autre.
Enfin, ce rfrentiel peut tre enrichi pour prendre en compte des aspects
techniques pointus.
Le contrle interne
La loi Sarbanes-Oxley et ses dclinaisons, IFRS (International Financial
Reporting Standards) et LSF (Loi sur la scurit financire), ont mis
laccent sur le contrle interne et les responsabilits des dirigeants. Le
prsident de toute socit anonyme doit prsenter un rapport sur les procdures de contrle interne mises en place. De son ct, le commissaire aux
comptes met un rapport sur les procdures de contrle interne relatives
llaboration et au traitement de linformation comptable et financire.
Les entreprises ont donc lobligation de rendre compte des procdures de
contrle interne et, ce titre, le systme dinformation est concern trois
niveaux :
la prise en compte de linformatique comme domaine de gouvernance
de lentreprise ;
les contrles propres la fonction informatique, y compris les procdures
de scurit ;
linsertion de contrles embarqus dans les processus automatiss.
Le guide IT Control Objectives for Sarbanes-Oxley, 2nd edition peut servir de base
une approche dtaille de lvaluation du contrle interne du systme
dinformation. Il sappuie sur CobiT et liste les objectifs de contrle de la
fonction informatique ainsi que les principales applications informatiques
qui supportent les processus de lentreprise.
Le contrle interne peut seffectuer de faon continue grce des outils :
les CAAT (Computer Assisted Audit Techniques ou techniques daudit assist par
ordinateur). Le guide G3 Use of Computer-Assisted Audit Techniques (CAATs),
relatif lusage des techniques daudit assist par ordinateur, est particulirement instructif sur :
la comptence de lauditeur pour lutilisation des CAAT ;
la confiance accorder aux CAAT elles-mmes ;
la confiance accorder aux donnes traites.
200
Ce guide est disponible sur le site de lISACA ladresse suivante :

http://www.isaca.org/AMTemplate.cfm?Section=Standards,_Guidelines,_Procedures_for_IS_Auditing&Template=/ContentManagement/
ContentDisplay.cfm&ContentID=39261
La majeure partie de ces outils est base sur la structure CobiT.
Loutil Quick Scan de CobiT

La socit de conseil en management ASK Conseil a capitalis sur son
exprience pour appliquer un rfrentiel simplifi et adapt aux besoins
des entreprises, qui dcline les prconisations du rfrentiel CobiT en
actions concrtes. Les rsultats du Quick Scan de CobiT sont labors sur
cette base.
Les entreprises qui cherchent optimiser leur dmarche de progrs vers
une bonne gouvernance de leur SI peuvent utiliser loutil Quick Scan de
CobiT, qui rpond cette problmatique en utilisant une mthodologie
visant linariser la trajectoire damlioration et gnrer des gains
rapides en matire de gouvernance.
Quick Scan en quelques mots

Quick Scan permet dobtenir :
un tat des lieux rapide de la gouvernance dune entreprise sur la base
de CobiT sous les deux axes suivants : la maturit et lorganisation ;
le positionnement de lentreprise par rapport dautres entreprises du
mme secteur dactivit ;
un plan daction sur mesure qui tient compte la fois de lexistant et
des apports de vos projets et actions en cours en la matire.
Il sadresse aux directeurs des SI des moyennes ou grandes entreprises. Il
sagit dune photo de la gouvernance SI dune entreprise un instant
donn, accompagne dun plan daction concret adapt aux besoins.
Cette photo sobtient au moyen dune srie dentretiens : 10 15 personnes
sont interviewes individuellement durant 1 h 30 (le DSI et les principaux
managers).
Quick Scan en questions

Selon lISACA, CobiT donne un cadre de rfrence en matire de gouvernance du SI, mais concrtement ?!
201
Pourquoi travailler partir de CobiT ?

CobiT couvre lensemble des processus (34 au total) quune DSI doit matriser. Il est donc le point dentre idal pour effectuer lanalyse globale
dune DSI. Si lon veut approfondir, il convient ensuite de se focaliser sur
un rfrentiel plus appropri (CMMI, ITIL, etc.).
Sur quel primtre intervient Quick Scan ?
On sintresse surtout au pilotage stratgique et aux contrles :
les processus du domaine Planifier et Organiser (PO) qui sont les plus
orients gouvernance informatique ;
les processus du domaine Surveiller et valuer (SE) vont alimenter
les processus PO et aideront la prise de dcisions stratgiques et
tactiques.
Quick Scan focalise son analyse sur les processus PO, tout en vrifiant
lexistence et la bonne intgration du contrle interne (SE1 surtout).
Quelle est la mthodologie utilise par Quick Scan
Figure 8-1 : Le Quick Scan de CobiT
202
tat des lieux

Le Quick Scan value tout dabord le niveau de maturit de chaque processus PO dans la DSI. Cette valuation est effectue sur la base des
cinq niveaux de maturit dfinis dans CobiT, pour chaque objectif de contrle
prconis. Les paramtres de ltude sont ajustables selon lorganisation
considre.
Il tablit ensuite une matrice dorganisation qui photographie la contribution des entits de lorganisation de la DSI chaque processus PO. Ce
livrable rvle le primtre non couvert par lorganisation en matire de
gouvernance, les doublons dans lattribution des rles et des responsabilits, et enfin met en vidence les rgulations informelles.
Analyse
Sur la base du rfrentiel simplifi, lexercice consiste identifier le niveau
actuel pour chaque critre, puis celui atteint lissue des projets et actions
en cours. Ainsi, les lacunes sur le chemin de la gouvernance apparatront.
Recommandations et plan daction
Il sagit enfin de proposer des recommandations se matrialisant soit par
un changement des priorits et/ou de rythme des projets et actions en
cours, soit par lidentification dactions complmentaires engager.
Grce au Quick Scan de CobiT, il est possible de dterminer les actions
prioriser et lordonnancement ncessaire pour une mise en pratique des
recommandations formules.
En rsum
CobiT est le rfrentiel incontournable de laudit de la gouvernance des
systmes dinformation. Sa structure, ses objectifs de contrle dtaills,
les travaux incessants de recherche et les publications associes en font un
outil vivant et reconnu.
203
Chapitre 9
CobiT fdrateur
Limplmentation pragmatique de CobiT vise donner une rponse

rapide et volutive au souci de gouvernance des TI. En sappuyant sur
lexistant, on choisit langle dattaque le plus appropri aux priorits
grer. La question est chaque fois de savoir jusquo aller dans les processus dployer en restant dans les limites dun projet denvergure
approprie.
Le pilotage stratgique
Lune des conditions essentielles du pilotage stratgique est lengagement
de la direction gnrale et des mtiers. De la mme faon, la stratgie
dentreprise est une condition ncessaire sa dclinaison sur le domaine
des TI.
Le Balanced Scorecard (BSC) est une reprsentation intressante pour
illustrer le pilotage stratgique des SI. Certains clients nous demandent
souvent sil est ncessaire que le BSC soit adopt au niveau de lentreprise.
Il est certain que ce serait bon signe mais ce nest pas indispensable la
tenue dun BSC sur la gouvernance des TI.
Les sections suivantes prsentent lutilisation des quatre cadrans du BSC.
Cadran 1 Contribution stratgique

La contribution stratgique se reflte au travers des rsultats des processus
de haut niveau.
On y trouve en particulier le plan trois ans (processus PO1), les investissements (processus PO5), la gestion des risques (processus PO9), le portefeuille de projets (processus PO10) et la surveillance de la gouvernance
205
(processus SE4). Dautres processus peuvent y tre ajouts mais ceux

prcits nous semblent tre les plus importants.
Cadran 2 Relation client

La relation aux clients de linformatique concerne essentiellement les utilisateurs du SI (internes ou externes lentreprise) et les donneurs dordre
dans les mtiers (matrises douvrage). Ce cadran est pilot par la contractualisation des niveaux de services (processus DS1) qui fixe non seulement
des seuils aux objectifs de performance mais aussi des devoirs pour les
mtiers (former les utilisateurs) et des limites (cest--dire consommation
des services prvue, comme le nombre dutilisateurs susceptibles de
contacter lassistance).
Les processus DS8 et DS10 sont essentiels au fonctionnement de cette
relation client.
Interprter la vision et la stratgie : quatre perspectives
Comment
garantir
lalignement
du SI aux
mtiers et le
meilleur
apport de
valeur ?
Alignement stratgique et finance

Objectifs
Mesures
Cibles
Clients et utilisateurs
Initiatives
Comment
respecter nos
engagements
vis--vis des
clients et des
utilisateurs ?
Objectifs
Mesures
Cibles
Initiatives
Vision et
stratgie
Comment
anticiper sur la
technologie, les
ressources, les
tiers pour tre
dans de
meilleures
conditions
oprationnelles ?
Anticipation et vision du futur

Objectifs
Mesures
Cibles
Processus mtier internes

Pour tre
efficaces et
efficients,
comment
piloter nos
processus
internes ?
Initiatives
Objectifs
Mesures
Cibles
Initiatives
Figure 9-1 : Le Balanced Scorecard (BSC)
Cadran 3 Futur et anticipation

Cest dune certaine faon le domaine de la stratgie de la DSI : comment
anticiper les besoins en ressources humaines (processus PO7), sorganiser
(processus PO4 et PO8), assurer une veille des fournisseurs (processus
DS2), anticiper les volutions technologiques et les besoins mtier (processus PO2 et AI1) ou encore faire voluer les architectures (processus
PO3). Tout cet ensemble conditionne le fonctionnement du SI et son cot.
206
Chapitre 9 CobiT fdrateur
Cadran 4 Excellence oprationnelle

Cest le fonctionnement de la DSI au quotidien. Il faut, par exemple, grer
lexploitation (processus DS13), lenvironnement physique (processus DS12),
les changements (processus AI6), etc.
Les performances oprationnelles sont lies pour partie des questions
intrinsques et pour une grande part des considrations autres (anticipation, niveau de risque et alignement stratgique, contrats avec les clients).
Certains exemples de situations observes chez des clients illustrent ce
qui ressemble des compromis :
administration de 60 serveurs Lotus, l o un projet de regroupement
de ces serveurs aboutirait trois serveurs seulement. Il est clair que tant
que ce projet na pas t dcid, leur maintenance cotera plus cher et
sera moins fiable ;
palier technologique permettant de rduire les cots de maintenance
des postes de travail ;
veille sur les contrats des infogrants et choix dun redcoupage des
domaines externaliss afin doptimiser la performance des soustraitants et de minimiser les ressources internes en gestion de contrat ;
ngociation avec les utilisateurs sur la ncessit de dvelopper des programmes spcifiques plutt que de saccommoder dun standard.
Arbitrage entre dveloppements et volution de la demande.
chaque fois, lexcellence oprationnelle dpend des conditions ngocies
dautres niveaux.
ITIL et le management des services TI

ITIL est le cadre de rfrence le plus diffus dans le monde pour le management des services TI ; il est devenu un standard de fait. Notons que le
rfrentiel, qui se prsente comme une vaste librairie, comprend aussi
dautres processus mais que le cur du systme et des certifications associes se rfre au management des services TI. Cest le cas en particulier de
la certification de la norme ISO/IEC 20000.
Il comporte 10 processus classs en deux domaines, savoir le support
aux services (aspect oprationnel) et la fourniture des services (aspect
tactique).
ITIL et CobiT : la complmentarit

ITIL structure son approche du management des services autour de la
relation avec les parties prenantes : utilisateurs des TI au quotidien et
207
matrises douvrage pour le pilotage (directions mtiers, etc.). CobiT, de la

mme manire, a mis systmatiquement en avant la finalit des TI, savoir
la rponse aux besoins des mtiers et le souci daligner loffre la
demande. Les deux approches partagent donc les mmes valeurs sagissant
du management des services TI.
La figure ci-dessous liste les processus CobiT qui sont les plus proches des
processus ITIL. Notons que les noms des processus sont souvent les
mmes, ce qui illustre la prise en compte croissante dITIL par les concepteurs
de CobiT au fil des versions.
Planifier et organiser
2
10
Les processus
CobiT pris en
charge par ITIL
Surveiller et valuer
Acqurir et implmenter
10 11 12 13
Dlivrer et supporter
Aucun
Complet
Source ISACA
Figure 9-2 : Les processus de CobiT couverts par ITIL V3
Une publication (COBIT Mapping : mapping of ITIL V3 with COBIT 4.1) est
consacre aux correspondances (mapping) entre CobiT et ITIL ; elle dcrit
deux niveaux de comparaison. Un niveau global compare les objectifs
dITIL aux objectifs globaux de CobiT. Pour un dtail plus fin, on se base sur
la granularit des objectifs de contrle de CobiT. ITIL a t dtaill en sousparties associes un ou plusieurs objectifs de contrle de CobiT.
Ceux qui sintressent ainsi aux correspondances entre CobiT et dautres
rfrentiels ne manqueront pas dtre frapps du degr trs lev de similitude entre les processus concerns. Sur ITIL V2 par exemple, il semble
que lon puisse pratiquement substituer les 10 processus correspondants
de CobiT et rciproquement.
En revanche, deux diffrences apparaissent clairement : la premire concerne
la compltude, et CobiT couvre dlibrment lensemble de la gouvernance des TI ; la seconde concerne le classement en domaines. CobiT
privilgie le distinguo entre la fourniture des services (domaine DS) et tout
ce qui concerne la mise en uvre (domaine AI) correspondant des changements impactant les ressources informatiques.
208
Pourquoi les associer ?

Les dmarches ITIL et CobiT sont souvent menes de faon spare. ITIL a t
une rponse au souci de mieux structurer les centres de services ; cest pour
cette raison que le centre de services est la seule fonction reprsente au
cur des processus. Les procdures du centre de services autour de la gestion des incidents (structuration en niveaux, escalade, enregistrement des tickets dappel, enrichissement des bases de donnes de rsolution, etc.)
avaient sindustrialiser pour faire face aux sollicitations moindre cot.
Simultanment, un nombre croissant dorganismes a cherch externaliser
ces fonctions de support, qui nentraient pas forcment dans leur cur de
mtier et se rvlaient compliques grer et optimiser en interne. Du
ct des outils, les diteurs en ont propos des plus en plus complets permettant de grer lensemble des procdures et dy associer une base de donnes des ressources informatiques au sens large (tickets dappel, objets de
configuration, mais aussi les descriptions de poste, etc.). Tout cet arsenal
a t bti avec le cadre de rfrence dITIL.
Le DSI qui sintresse aux rfrentiels constate donc rapidement que tout
un pan du systme dinformation de la DSI pour elle-mme existe ou pourrait rapidement exister, entre le centre de services et lexploitation, entre
les services internes et les tiers. Le travail considrable de structuration, de
conception de SI interne, de conduite du changement et de tableaux de
bord est fait, et mieux encore, il est oprationnel, un niveau de dtail que
CobiT natteint pas. La question nest plus de savoir sil faut garder ITIL
mais comment lintgrer au mieux dans une vision complte pour la
gouvernance des TI.
Conjuguer ITIL et CobiT

Les points cls prendre en compte pour conjuguer les deux approches
sont les suivants.
Concilier deux cultures
La culture ITIL est pragmatique, sans cesse confronte aux ralits quotidiennes et oriente plutt vers le service offert (continuit de service,
performance). Elle gre souvent les objets informatiques un niveau de
dtail qui ne concerne que les acteurs du support, de la maintenance ou
de lexploitation.
CobiT, au contraire, risque dtre peru comme trop thorique, peu applicable et pas assez concret pour tre dploy facilement et utilement.
Structurer le rfrentiel densemble
Il faut viter les doublons de processus, ce qui se produit inexorablement si lon ne dcrit pas une cartographie des processus garantissant
une cohrence densemble.
209
Raliser le lien avec les tudes et les dveloppements

ITIL a du mal se propager vers les quipes dtudes et de dveloppements et parfois mme, vers lexploitation. Il nest reconnu ni dans le
pilotage de projets au niveau lmentaire, ni dans la gestion globale
des portefeuilles ou des investissements.
CobiT prsente lavantage de donner un cadre complet qui offre un
processus de transition, le PO10, entre ITIL et les tudes.
Btir progressivement le modle de donnes de la DSI
Les acquis dITIL sont intressants mais le risque est grand de tomber
dans le dtail. Il faut sappuyer sur la CMDB pour crer le modle de
donnes de la DSI, veiller sen distancier et dfinir la granularit
pertinente des donnes pour le pilotage.
Deux exemples concrets

Juxtaposition
Dans cet exemple, la DSI a lanc la rorganisation de son service support
et exploitation. Cela sest traduit par la cration dun service desk et la
mise en place de contrats dinfogrance pour lexploitation des ordinateurs
centraux et des rseaux. Ensuite, lexternalisation du service desk a permis
de gagner plus de 20 % sur les cots du support.
Notons que linfogrant avait t aussi choisi pour sa capacit dployer
ITIL. En apparence, la partie tait gagne et pourtant la situation sest
ensuite dgrade, essentiellement en raison de labsence de vision systmique mais galement par ignorance des points mettre sous contrle.
Simultanment, la DSI sintressait CobiT, au moins pour le domaine PO,
afin de lancer les bases dune gouvernance stratgique des systmes
dinformation.
Avec le recul, il est manifeste que lorganisation interne au service, la gestion des comptences et de la formation ont t des lments cls. Les
profils ne sont pas les mmes entre ceux qui lancent une nouvelle organisation et ceux qui vont ensuite la faire fonctionner. Comme toujours, la
situation tait un peu hybride. Les principaux points de drive observs
sont les suivants.
Les processus et leur rpartition interne/externe
Le service dassistance et la gestion des incidents taient clairement
sous la responsabilit de linfogrant, mais :
le niveau ultime dexpertise (niveau 3) restait la charge du client,
que ce soit sur des questions gnriques (bureautique) ou spcifiques
la socit (applications) ;
certains processus (par exemple, linstallation dun nouveau PC) faisaient simbriquer les responsabilits selon les activits du processus
210
(achats, demande de rendez-vous, installation, configuration des

droits, etc.) ;
le processus de gestion des problmes devenait une sorte dinstance
aux frontires du contrat dinfogrance ;
le service informatique interne avait tendance rester sur un positionnement technique en recrant en double des activits de surveillance,
de veille ou de contrle minutieux.
Labsence de vision systmique au sein de la DSI
Le dploiement dITIL tait limit aux processus lis linfogrant et au
primtre du support qui tait externalis. Les interfaces avec les autres
services (exploitation, tudes, pilotage de la DSI) demeuraient des
points de friction constants, concernant :
la faiblesse du processus de gestion des changements, ce qui rduisait considrablement les bnfices du support ;
lclatement de la vision contractuelle gestion des tiers et ce,
des niveaux de comptence insuffisants, limitant lalignement et la
cohrence entre les contrats et les obligations. En consquence, il
tait difficile de responsabiliser le sous-traitant, mais aussi de crer
du travail en interne aux interfaces entre les sous-traitants ;
l absence de levier sur les services tudes pour faire valoir les priorits
rgler, do limpuissance du responsable de gestion des problmes ;
la croissance simultane du domaine SAP avec son centre de comptences et son organisation propre (centre dappels, support, TMA,
mise en exploitation, etc.), limitant ainsi la pertinence du point
daccs unique vu du client.
La multiplicit des outils de pilotage
La DSI est bien sr le cordonnier le plus mal chauss quand il sagit du
systme dinformation sous-tendant son activit interne. ITIL donne une
rponse partielle, sur un primtre rduit, limit la gestion des incidents et la gestion du parc (embryon de gestion des configurations).
Les points rgler ne sont pas simples :
loutil de gestion du service dassistance avait t dvelopp et maintenu par le client et linfogrant en tait un des utilisateurs. Ce point
limite bien sr la responsabilit du tiers mais permet dassurer un
support aux processus aussi bien internes quexternes. Le choix
inverse aurait conduit crer une interface entre loutil de linfogrant
et loutil interne de gestion de la DSI ;
les autres services avaient leurs outils (tudes, centre de comptences
SAP, exploitation) et la communication avec les interfaces seffectuait
par e-mails ;
211
le service tudes tait assez peu homogne. Un systme de management de la qualit et des procdures de gestion de projets existaient
mais, dans les faits, les pratiques taient assez varies et les outils
disparates (Excel), voire inexistants.
Dans ce contexte, les principaux indicateurs de pilotage qui mergent
durablement sont ceux qui servent aussi grer les contrats tiers, dans la
mesure o ils sous-tendent des enjeux financiers.
En rsum, lanalyse de la situation doit prendre en compte le contexte de
la DSI et de lentreprise. Le changement doit se faire un peu partout simultanment, il ne peut y avoir immobilisme dun ct (les mtiers ou les
tudes, par exemple) et rvolution de lautre (les services de la DSI). La
mise en uvre de lopration peut sanalyser comme une monte progressive en maturit. En ce sens, lancer simultanment une approche stratgique sur les processus PO et une refonte des services autour dITIL (ou
des processus DS) peut se rvler efficace si elle est bien manage.
Ensuite, il faut faire bouger les tudes et tablir la jonction entre les
processus PO et AI.
Intgration
Dans cet exemple, la DSI dcide dimplanter simultanment CobiT et ITIL
en crant un rfrentiel dentreprise commun. Il faut dire que les services
partent dune situation o un grand travail a t effectu sur la structuration du centre dassistance aux utilisateurs, la certification ISO 9001 de la
production (avec une culture des indicateurs et de lamlioration) et la
mise en place dun outil de gestion des incidents.
La dure qui spare le
cas prcdent de
celui-ci est de lordre
de trois ans. Il nous
semble que, pour la
plupart, les grandes
DSI sont plus proches
de ce cas rcent que
du prcdent.
Lintgration passe par une vision stratgique partage au sein de la DSI et

la dfinition dun rfrentiel de processus dans une logique ISO 9001
reprenant les processus PO de CobiT et lISO/IEC 20000 (ITIL V2). Simultanment, une dmarche trs volontariste est mene sur les tudes (nomination de PMO, formation et dploiement de CMMI). Il faut dire que le
primtre tudes de la DSI est important (plus de 800 personnes avec les
externes).
Les principales difficults rencontres sont :
le dcalage entre la logique dentreprise et celle de la DSI
Les services de support (comptabilit, budget, ressources humaines,
achats) de lentreprise ont leur logique propre et des systmes dinformation adapts leurs besoins. Pour la DSI, il faut la fois sy conformer et crer une vision adapte la gouvernance des SI, par exemple :
une comptabilit analytique et un contrle de gestion adapts aux
objets grer dans le cadre de la gouvernance ;
212
la rconciliation entre les dpenses de personnel internes et les

achats externes, de faon alimenter le suivi des consommations
(temps pass, cot) ;
une procdure dachat plus conforme aux exigences (ractivit) et aux
enjeux (rfrencement) ;
des achats mieux coordonns au plus haut niveau de la DSI pour rendre
une vision homogne et dfinir une stratgie claire (processus DS2) ;
une gestion des comptences qui permette de rduire le grand cart
entre les comptences ncessaires dans le cadre dune DSI et le rfrentiel de comptences de lentreprise qui est le fil rouge de la carrire
des agents.
les processus aux interfaces
La DSI est de facto organise en silos (tudes, rseau, exploitation, centre de services, etc.) et les problmes surgissent aux interfaces. Les principaux processus impacts sont les suivants :
tests et mise en production (processus AI7) ;
gestion des problmes (processus DS10) et des changements (processus
AI6) ;
relations avec les mtiers (processus DS1) ;
gestion des donnes (processus DS11) dfaut de relation efficace
avec les mtiers ;
PMO (processus PO10) et gestion du portefeuille de projets.
le systme dinformation de la DSI
En partant des systmes existants, le systme de gestion de lentreprise
et la base de gestion des appels (embryon de la CMDB), on a videmment la mauvaise surprise de constater que le systme dinformation de
la DSI ne sera ni lun (trop global, trop orient entreprise) ni lautre (trop
dtaill). Il reste donc le construire.
la culture de la mesure et de lamlioration de processus
Il est bon de rappeler que la description des processus nest rien sans
culture de la mesure pour lamlioration. Le dfaut de systme dinformation fiable excuse labsence dindicateur. Ne faut-il pas prendre la
question dans lautre sens : btir des indicateurs, mme temporaires, et
amliorer lensemble, y compris la production dindicateurs ?
Cet exemple illustre la difficult trouver les leviers de progrs de la DSI
tant les chantiers ouvrir sont nombreux, chacun semblant tre le pralable la russite du tout !
213
La scurit
Jusqu un pass rcent, la scurit sest limite la protection des systmes
informatiques concerns par le stockage et le traitement des informations
plutt que de la protection de linformation elle-mme. Avec CobiT, la scurit devient lune des composantes de la gouvernance en proposant des
bonnes pratiques de gouvernance de la scurit de linformation. Cette
dernire rejoint ainsi lunivers de la gestion des risques.
La scurit de linformation nest plus seulement un sujet de technicien
mais devient un enjeu de direction gnrale et mtiers. CobiT, en dveloppant lalignement stratgique et lapport de valeur des systmes dinformation, met bien en vidence les risques que labsence de mesure de scurit
de linformation fait courir lentreprise.
CobiT aborde la gouvernance de la scurit de linformation en sintressant :
la prise en compte de la scurit de linformation dans lalignement
stratgique ;
la prise de mesures appropries pour limiter les risques et leurs consquences potentielles un niveau acceptable ;
la connaissance et la protection des actifs ;
la gestion des ressources ;
la mesure pour sassurer que les objectifs de scurit sont bien atteints ;
lapport de valeur par loptimisation des investissements en matire de
scurit de linformation ;
les bnfices retirs ;
lintgration de la scurit de linformation dans les processus.
Globalement, CobiT aborde la scurit de linformation dans plus de
20 processus sur 34. Mais les processus suivants font apparatre une
dimension scurit importante dans les objectifs de contrle :
PO6 Faire connatre les buts et orientations du management
CobiT et la norme ISO/IEC 27002

LITGI a produit un rapport de correspondance entre les 34 processus
CobiT et les 133 mesures prconises par la norme ISO/IEC 27002. Ce rapport fait apparatre que CobiT offre une vision des mesures de plus haut
niveau que celle propose par lISO/IEC 27002. Ainsi, CobiT offre un cadre
de gouvernance, et lISO/IEC 27002 complte ce cadre par la description de
mesures de scurit de linformation.
214
CobiT et lISO/IEC 27001

La norme ISO/IEC 27001, qui sappuie sur lISO/IEC 27002, dcrit les exigences de mise en place dun systme de management de la scurit de
linformation (SMSI). Les principes utiliss sont identiques ceux exprims
dans la norme ISO 9001. CobiT, travers le processus PO8, prconise la mise
en place dun systme de management de la qualit (SMQ) qui reprend les
finalits de lISO 9001. Quant aux exigences de lISO/IEC 27001, elles se
retrouvent galement dans les processus PO6, PO9, DS4 et DS5. En ce sens,
CobiT est parfaitement compatible avec la mise en place dun SMSI.
La mise en place dun SMSI relve de la mme logique que celle dun
SMQ ; cest une question de stratgie et daffichage. En effet, la mise en
place dun systme de management ISO 9001 ou ISO/IEC 27001 est souvent motive par un besoin de reconnaissance, lequel est matrialis par
la certification. Il est cependant important de noter que la manire de
dfinir les primtres est diffrente selon que lon traite de lISO 9001 ou
de lISO/IEC 27001. Pour le management de la qualit, le primtre est
dfini par la dtermination des activits ralises par une organisation
identifie. Pour le management de la scurit de linformation, le primtre est dtermin par lidentification des actifs devant tre protgs.
Cette question du primtre est importante et CobiT, de par sa dimension
de gouvernance de la scurit de linformation, permet de mieux lapprhender. Il est donc utiliser en amont de la mise en place dun SMSI. Le
rsultat dun Quick Scan peut dailleurs tre, pour une direction, lvnement
dclencheur de la mise en place dun SMSI.
Le management des tudes

Il existe de nombreux rfrentiels de processus pour lamlioration du management de projet (PRINCE2, PMBOK, CMMI, etc.), et des mthodes sont galement largement diffuses (PERT, GANTT, points de fonction, etc.). Nous
nous intressons ici lamlioration des processus de production de logiciel
(couramment nomm service tudes ). Ce chapitre ne concerne que les
grandes DSI qui gardent en interne une part importante de dveloppements.
CobiT et CMMI
Les raisons du dploiement de CMMI sont de deux ordres : la ncessit
datteindre un certain niveau de maturit pour satisfaire des obligations
contractuelles ou amliorer le pilotage des tudes, et lamlioration de la
performance. Dans les grandes DSI, il sagit surtout de performance, des processus et des quipes. On part donc du principe que latteinte dun niveau de
maturit CMMI entranera de facto des gains (dure, cot, qualit).
215
Notons quil est inutile de tenter de concilier les modles de maturit de

CobiT et de CMMI. Le premier est vraiment indicatif et destin au management, le second conduit une vraie certification.
Les processus de CMMI se rpartissent en quatre domaines (management
des processus, management de projet, engineering et support). Dans
lexemple qui suit, une DSI dcide un programme important de dploiement de CMMI sans que les actions au niveau du rfrentiel qualit partir
de CobiT ne soient abouties. Les principales difficults ou dconvenues
qui apparaissent au fil du dploiement sont les suivantes :
La conduite du changement dans les quipes
Outre les mthodes qui peuvent se rvler plus ou moins adaptes, la
conduite du changement pose deux problmes assez cruciaux dans
la pratique :
les processus de management de projet et dengineering supposent
lexistence de mthodes (planification, estimation, suivi du reste
faire, tests, etc.). La formation des groupes de travail rvle la disparit des mthodes et pose la question de leur harmonisation, ce qui
met au second plan les processus CMMI ;
les domaines management des processus et processus support sont
trs fortement relis aux processus CobiT ou ITIL. Il est ncessaire
dharmoniser le rfrentiel de la DSI plutt que de prendre en compte
CMMI comme tel.
Dans les deux cas, le risque est grand de devoir faire marche arrire si
ces questions ne sont pas tranches en amont.
Le systme de mesure
Lorsque les enjeux sont polariss sur les cots, on se demande comment mesurer la performance et lamlioration espre. L encore, les
pralables sont assez nombreux pour ne pas viser demble un systme
intgr mais plutt procder par tapes. Citons quelques exemples.
Comment mesurer la dure dun projet si la fin nest pas certaine ? Par
exemple, la fin du contrat dun intgrateur et le passage en TMA peut
signifier que le projet est termin, mais aussi que le budget initial est
consomm ! La mise en production nest pas synchrone de la fin de
contrat.
Comment agrger des cots internes et externes ? et des temps passs
lorsque lon a recours des forfaits ?
Comment estimer un projet (cot, dlai) selon les situations (progiciels, logiciel, TMA, etc.) et les technologies ? A-t-on une courbe
dexprience de mesure des points de fonctions ?
Comment reconstituer lensemble des cots dun projet ?
216
CMMI nest pas un rfrentiel de gouvernance des TI. Pour sen assurer, il
suffit dexaminer le tableau 9-1, traduit du mapping entre CobiT et CMMI
(publication COBIT Mapping: Mapping of CMMi with COBIT v4.1). Il donne une
ide de lampleur des objectifs de contrle non couverts par CMMI et qui
sont pourtant dployer si lon vise un minimum de gouvernance des TI.
Tableau 9-1 : Les objectifs de CobiT nayant pas de correspondance dans CMMI
Objectifs de contrle non couverts

par CMMI
Mots-cls ou concepts non pris en compte

par CMMI
PO2 Dnir larchitecture de linformation
Architecture des donnes, dictionnaire des donnes,

classication, management des donnes.
Cible technologique, architecture, infrastructure, urbanisation.
Gestion des investissements, management des cots,

priorisation des programmes, cycle de vie, portefeuille
de projets, budget TI, apport de valeur.
Management de la performance, de la capacit et de

la disponibilit.
Continuit de service pour les mtiers, rfrentiel de

secours, ressources critiques, reprise de service, site de
secours.
Scurit.
DS6 Identier et imputer les cots
Imputation des cots, dnition des services, catalogue

des services, modle de cot et de refacturation.
DS8 Grer le service d'assistance client

et les incidents
Service dassistance, gestion des incidents, enregistrement des demandes, escalade.
Intgrit des donnes, proprit des donnes et des

systmes, management des donnes, stockage.
DS12 Grer l'environnement physique
Environnement physique.
Gestion des oprations.
Contrles internes, rfrentiel de management

des risques.
SE3 Assurer la conformit aux obligations externes
Gouvernance TI, conformit rglementaire.
217
Il semble assez risqu et coteux de dployer CMMI avant davoir runi au

niveau de la DSI certains pralables, que ce soit sur le plan de la gouvernance densemble (CobiT), de lvaluation des charges (valuation de
charge, estimation du reste faire), des outils de mesure lmentaires
(points de fonction, temps passs) ou sur le plan des mthodes diffuses
et gnralises dans les quipes (pilotage de projet, tests, spcifications).
Une fois runis les pralables de mise en cohrence des mthodes au sein
des tudes et de dploiement des principaux processus de CobiT, CMMI
vient trs facilement sintgrer dans le rfrentiel densemble.
La certification
La certification ISO 9001 obit des rgles strictes, en particulier concernant la structuration des processus en domaines (management, support,
ralisation). Pour conjuguer CobiT et la certification, deux scnarios sont
possibles.
Scnario 1 : certifier ISO 9001 lensemble de la DSI en sappuyant sur les
bonnes pratiques CobiT, voire en y ajoutant les bonnes pratiques CMMI,
ITIL et ISO/IEC 17799.
Scnario 2 : identifier et slectionner dans le rfrentiel CobiT, quelques
processus suffisamment matures pour les intgrer au primtre de certification ISO 9001 de lentreprise.
Scnario 1
Conditions de mise en uvre
Ce scnario implique la mise en uvre de tous les processus de la DSI et
de toutes les bonnes pratiques CobiT, CMMI, ITIL et ISO/IEC 17799.
Il impose de dfinir un systme de management de la qualit (SMQ) ddi
la DSI qui accueille les processus en cours de dfinition, avec tout le rfrentiel documentaire exig par la norme ISO 9001 :
le manuel qualit ;
les 6 procdures documentes :
matrise de la documentation ;
matrise des enregistrements qualit ;
audit interne ;
matrise du produit non conforme ;
actions correctives ;
actions prventives.
mise en uvre des revues de direction.
218
Le primtre de ce scnario englobe tous les processus. La certification

suppose donc une maturit importante du systme de management dans
son ensemble.
Effort de mise en uvre

La mise en uvre de ce scnario est assez lourde. En effet, il suppose de
mettre en place une organisation ddie au systme de management, et de
respecter toutes les exigences dun systme de management.
Une quipe projet spcifique doit tre dsigne pour mettre en place la
dmarche, compose, par exemple, dune personne mi-temps pour
piloter le projet et des reprsentants des directions de la DSI avec une
disponibilit denviron 25 %.
Intrt pour la DSI
Ce scnario rsulte dune dcision stratgique de positionner la DSI
comme un prestataire crateur de valeur et de sinscrire dans la logique de
gouvernance pouvant mener au BSC.
Scnario 2
Conditions de mise en uvre
Ce scnario nimplique pas de dfinir une structure complte de processus. Il sagit de slectionner, dans le modle propos par CobiT, les
processus les plus matures ou les plus dterminants afin de les piloter
selon la logique du systme management global de lentreprise.
Pour tre certifiables, les processus slectionns doivent tre dploys au
sein de la DSI, et tre suffisamment mrs pour tre mesurs ou, pour les
plus critiques, pilots.
Ce scnario ncessite de dfinir une cartographie prsentant une cohrence entre les processus slectionns pour la DSI et ceux dj dfinis pour
lentreprise.
Effort de mise en uvre
La dmarche de la DSI sintgre compltement dans la dmarche globale
de management de lentreprise. Seules des actions dharmonisation documentaire sont ncessaires. Ce scnario ncessite de se coordonner avec
les autres directions de lentreprise et la direction gnrale.
Intrt pour la DSI
Ce scnario permet la DSI dinsrer sa dmarche processus dans un programme dexcellence de la direction de lentreprise. Ainsi, les calendriers
de la DSI dans ses dmarches et celui de la direction gnrale peuvent
saligner. Cet alignement laisse alors la DSI le temps de progresser dans
219
son niveau de maturit. Il prsente lavantage de positionner les processus

SI comme des contributeurs directs la cration valeur des processus
produits (voir le rfrentiel des processus prsent la figure 9-1).
Comparaison des scnarios

Tableau 9-2 : Comparaison des scnarios de certication
Scnario 1
Scnario 2
Principe
Certier ISO 9001 lensemble

de la DSI.
Certier les processus les plus

matures ou prioritaires dj
dploys dans le cadre DSI.
Effort DSI
Mise en place dune organisation ddie.
Dmarche intgre dans une

dmarche globale dentreprise.
2 3 ans
Par tranches de 1 an
Stratgie du directeur des systmes dinformation, autonomie

de la DSI.
Prise en compte des dmarches

DSI dans un programme
dexcellence ou damlioration
continue de lentreprise.
Dlai de mise
en uvre
Intrt
pour la DSI
Exemples de dploiement
Scnario 1
tudions un exemple de mise en place du scnario 1 pour une entreprise
ayant engag une dmarche de certification ISO 9001 et ISO/IEC 27001, en
sappuyant sur les bonnes pratiques CobiT et ITIL.
Le choix de cette DSI a t motiv par un besoin de reconnaissance de la
qualit des prestations offertes, car celle-ci tait exige par les clients des
directions mtiers de lentreprise, cest--dire le march.
La DSI sest donc dote dun systme de management intgr (qualit et
scurit de linformation). La cartographie des processus est structure
selon les trois catgories de processus : management, ralisation et support. Pour llaborer, la DSI a pioch parmi les 34 processus de CobiT en
slectionnant des pratiques ou activits issues des objectifs de contrle et
en les regroupant en macroprocessus. Cette slection a t opre en fonction de la capacit de la DSI les mettre en uvre dans un avenir court
terme, cette capacit ayant t apprcie aprs lvaluation du niveau de
maturit des pratiques existantes. La logique est ensuite damliorer ces
processus dans le temps via la dmarche de progrs continue induite par
la mise en place du systme de management.
220
CobiT a donc servi de guide pour modliser les processus oprationnels en

se centrant sur la responsabilit de la DSI en tant que fournisseur. Ainsi,
toutes les responsabilits dcrites dans CobiT extrieures lorganisation
de la DSI nont donc pas t mises en uvre car elles ntaient pas
comprises dans le primtre de management de la DSI.
Scnario 2
prsent, tudions un exemple de mise en place du scnario 2 pour une
entreprise ayant engag une dmarche dexcellence cible sur lobtention
du prix EFQM.
Pour tre intgrs dans le primtre de certification de lentreprise, les processus slectionns de CobiT doivent cependant rpondre aux exigences
classiques dune dmarche processus. Les critres sont les suivants :
le processus est dfini, dcrit et document ;
le processus est mis en uvre ;
le processus est mesur et des indicateurs sont mis en place ;
le primtre dapplication couvre lensemble de la DSI ;
le processus est ouvert vers lextrieur (orientation client).
Par ailleurs, les processus sont classs en trois catgories :
les processus de management ;
les processus de ralisation ;
les processus supports.
Les processus de management
Dans cette catgorie, trois processus ont t identifis :
PO1 Dfinir un plan informatique stratgique pour le SI
PO10 Manager les projets SI (guide de la gouvernance des SI)
PO9 valuer et grer les risques (dfinir la politique de scurit de
gestion de linformation de lentreprise)
Les processus de ralisation
Au niveau de la DSI, les processus de ralisation sont de deux types : le
dveloppement du SI (grer le projet et fabriquer la solution) et la production (exploitation du SI).
Processus de dveloppement du SI (domaine AI)
Mise en uvre des processus CMMI de niveau 2 sur lensemble de la
DSI.
Processus de gestion des services (domaine DS)
La dmarche ITIL est utilise pour dfinir les processus de gestion des
services (fourniture et soutien des services) en suivant le modle de
maturit de litSMF (IT Service Management Forum) pour la priorit de mise
en place (1 an par niveau).
221
Les processus supports

Les processus supports identifis dans cette catgorie sont :
manager les ressources humaines (processus groupe) ;
grer la refacturation des prestations (spcifique DSI) ;
raliser les achats (processus groupe) ;
dfinir des directives de scurit (spcifique DSI) ;
matriser les risques business lis au SI (spcifique DSI) ;
mettre en place un tableau de bord scurit (spcifique DSI) ;
dfinir un plan de reprise dactivit (PRA) et assurer le support au
dploiement (spcifique DSI).
En rsum
CobiT a choisi de se positionner en fdrateur. Aucun rfrentiel na ce
jour la couverture que CobiT propose sur lensemble des TI. Les travaux
permanents qui sont engags et lesprit douverture qui prside au sein des
groupes de bnvoles justifient cette image de fdrateur. Les autres standards ont une vision beaucoup plus limite, se contentant de querelles aux
frontires, chacun briguant la position de leader. Tant quil y aura des
mondes aussi inconciliables que les tudes (projets) et les services, CobiT
aura son rle jouer !
222
Chapitre 10
Transformer la DSI
Le parti pris de cette implmentation est de sattaquer une transformation de fond de la DSI. Les thmes aborder sont incontournables, mme
si certains prennent plus de temps que dautres. CobiT peut paratre compliqu mettre en uvre et, surtout, demander des pralables importants.
Comment aborder et rsoudre ce problme ?
Nous proposons deux solutions :
la premire, celle de lISACA, consiste dployer une partie restreinte
de CobiT dans certaines conditions, cest CobiT Quickstart ;
la seconde propose un modle de maturit tir de lexprience pour un
dploiement de CobiT en diffrentes tapes.
CobiT Quickstart
Prsentation
CobiT Quickstart peut tre considr comme un point de dpart pour une
extension ultrieure lensemble de CobiT, ou comme un objectif, en particulier pour les PME et aussi pour les entreprises pour lesquels les TI ne
constituent pas un enjeu stratgique proprement parler.
CobiT Quickstart concerne les parties prenantes au sein des entreprises
concernes : auditeurs, responsables des TI et acteurs de la mise en place de
la gouvernance des TI. Pour eux, cette premire approche simplifie est une
chance de lancer le projet sur un primtre raisonnable. CobiT Quickstart est
un puissant outil de dmarrage qui suggre les choses intelligentes
faire , mme si dans de nombreux cas, il faudra ajouter des contrles complmentaires pour constituer la base dune gouvernance efficace de tous les
processus informatiques. CobiT Quickstart est donc une version allge de
CobiT, plus facile daccs et plus simple mettre en uvre.
223
Les hypothses de CobiT Quickstart

Pour appliquer efficacement et sans risque CobiT Quickstart, lISACA propose
les hypothses suivantes pour le choix de cette implmentation simplifie :
linfrastructure informatique nest pas complexe ;
du fait de la taille de lentreprise, les TI et lactivit sont bien aligns ;
le but est de privilgier lachat de services plutt que la ralisation en
interne ;
les comptences informatiques internes sont limites ;
la tolrance au risque est relativement leve ;
lentreprise est trs attentive aux cots ;
la structure de commandement est simple ;
lventail des contrles est peu tendu.
Ces hypothses correspondent la culture du contrle et de lenvironnement
informatique de la plupart des PME et, sans doute aussi, celle de petites
entits secondaires ou autonomes dorganisations de plus grande taille.
Deux tests sont proposs permettant de se situer et, si possible, dviter la
zone rouge :
Rester dans le bleu conduit une valuation du bien-fond dutiliser
CobiT Quickstart ;
Surveiller le thermomtre complte cette valuation partir de 7 critres globaux.
Le principe est de se contenter de CobiT Quickstart tant quon est loin du
rouge .
Le contenu
CobiT Quickstart conserve la structuration classique de CobiT en
domaines, processus et objectifs de contrle. Le modle de maturit est
supprim et le RACI simplifi. Ainsi, sont conservs :
31 processus sur les 34 prsents dans CobiT.
Ils manquent les processus DS6 (Identifier et imputer les cots), DS7
(Instruire et former les utilisateurs) et SE4 (Mettre en place une gouvernance des SI) ;
59 objectifs de contrle dtaills sur les 210 prsents dans CobiT V4.1.
Leur description renvoie aux objectifs de contrle dtaills de CobiT,
rfrencs par leur numro dobjectifs. Pour chaque objectif, deux
trois facteurs cls de succs sont prsents alors quune dizaine est propose dans CobiT.
On parle de bonnes pratiques mettre en uvre plus que dobjectifs
de contrle, ce qui manifeste la volont de prsenter CobiT Quickstart
comme un outil pour le management.
224
Chapitre 10 Transformer la DSI
Une srie de tableaux illustre les liens entre les 62 bonnes pratiques et les
principaux axes de gouvernance TI.
Le premier tableau rpartit des attributs risques selon deux catgories
de thmes .
Les cinq premiers thmes correspondent aux domaines de la gouvernance
des TI (alignement stratgique, apport de valeur, gestion des ressources,
gestion des risques et gestion des performances).
Les neuf thmes suivants rsument concrtement les principales proccupations des dirigeants (optimisation des cots, dlivrance de service,
externalisation, scurit, architecture, intgration des systmes, priorits et planification, contrles programms et scurit des applications).
Le second tableau rpartit les objectifs de contrle de CobiT Quickstart
selon les mmes thmes gnraux.
Pour rsumer, CobiT Quickstart est orient bonnes pratiques et guide de
management des TI plus quaudit ; il peut convenir une premire implmentation. Il met de ct le processus DS6, lequel peut reprsenter effectivement un trs gros effort. Toutefois, mme si le nombre dobjectifs est
divis par trois, il reste un grand nombre de processus dployer, ce qui
reprsente demble une lourde charge et ne rsout pas la question de la
conduite du changement au sein de la DSI.
Pour un dploiement tag

Si lampleur du dploiement de CobiT devient un risque en tant que tel, il faut
imaginer des manires plus progressives de le mettre en place. La premire
approche consiste se demander quelles sont les proccupations auxquelles
on souhaite rpondre afin de mettre en priorit certains processus, la
seconde partirait plutt de lensemble des pralables recueillir pour savoir
ce que lon peut faire et quel stade ; une combinaison des deux serait
idale. Au fil des missions, nous avons dgag une proposition de modle de
maturit tag pour la mise en place progressive de CobiT.
Les pralables recueillir

CobiT se place dans une situation un peu idale dans laquelle lorganisation
serait conforme au RACI, les mesures des indicateurs seraient remontes
dans un systme dinformation de la DSI avec un effort minimum, les cots
seraient connus, les acteurs internes seraient rds la notion de processus et de boucle damlioration, etc.
La situation relle est bien diffrente, et tellement en de des attentes,
que le projet de dploiement tourne court bien souvent. Il faut donc faire
des choix, lesquels dpendent de la situation de la DSI mais aussi des
225
parties prenantes et des objectifs de gouvernance qui se font jour. Les principaux obstacles au dploiement de CobiT sont les suivants.
Le systme de mesure des indicateurs de fonctionnement
Dans le meilleur des cas, il est htrogne avec une couverture correcte ; le plus souvent, il est htroclite, incomplet et surtout centr
autour des domaines qui bnficient de systmes dinformation existants (automates dexploitation, centre dassistance, comptabilit,
facturation, paie, achats). Les lments sont donc parfois mesurs avec
une finalit qui nest pas celle de CobiT.
De la mme manire, le pilotage des projets informatiques mriterait
dtre outill pour produire des indicateurs cohrents (temps pass,
cots, estimations, etc.).
En rsum, limplmentation de CobiT ncessiterait de disposer dun
modle de donnes adapt, propre la DSI, conu dans une logique de
gouvernance IT.
Le contrle de gestion de la DSI
Il se base gnralement sur la comptabilit de la socit sans quil
existe un plan analytique de la DSI. Le pralable avant didentifier et
dimputer les cots peut se rvler trs lourd.
La culture du management des processus
Il est fondamental que les quipes aient une culture de lamlioration
de processus, ce qui suppose daccepter de parler des dysfonctionnements pour dpasser le stade lmentaire du chacun pour soi. Cette
culture a pu tre cre au fur et mesure de la mise en place des processus
(ISO 9001, etc.).
Les contrats avec les tiers
La gestion des tiers sest faite au fil du temps. Son efficacit passe
parfois par la rengociation de contrats (fournisseurs, constructeurs,
intgrateurs, infogrants, diteurs, etc.) et lharmonisation des primtres externaliss. Dans la ralit, certains contrats stalent sur de
longues dures et le travail dharmonisation et de ngociation ne
peut prendre place que dans certains intervalles de temps, plus ou
moins espacs.
Les relations avec les mtiers
La relation avec les mtiers concerne lensemble de la DSI, aussi bien
les services fournir et la scurit que les projets ou la maintenance.
Ces relations sont plus ou moins formalises et propres sinscrire dans
une refonte des processus de la DSI.
Les mthodes mises en uvre sur les projets
Les entreprises ont trs souvent leur propre bibliothque de procdures
et de mthodes pour le cycle de dveloppement de logiciels. Dans les
226
faits, il est rare que les mthodes soient dployes de faon uniforme, et
exceptionnel de dterminer un systme dinformation complet pour
piloter les projets.
Cette liste non exhaustive dobstacles rencontrs couramment donne une
ide de la difficult de transformer une DSI.
Exemple de dploiement progressif

Le choix des processus dployer dpend la fois des objectifs de gouvernance et des obstacles rencontrs. Parmi les objectifs identifis dans notre
exemple, nous avons retenu :
la conformit avec les exigences rglementaires de la loi Sarbanes-Oxley
et, plus gnralement, la rduction des risques ;
le management des ressources.
Cela signifie que lalignement stratgique, la mesure de la valeur et la
mesure de performance ne sont pas dans ce premier lot.
Niveau 0
Cest linexistence de processus formaliss et dploys. On est au niveau le
plus artisanal de lorganisation.
Niveau 1 Scurit et fonctionnement
Le choix stratgique se porte en priorit sur la mise en uvre dune politique de scurit et le bon fonctionnement de la DSI. Cela correspond
plusieurs processus dployer, essentiellement dans les domaines AI et
DS qui contrlent la grande partie des ressources TI.
Groupe 1 Scurit, conformit SOX et disponibilit :
DS8 Grer le service dassistance client et les incidents
227
Groupe 2 Piloter les ressources TI (hormis les projets applicatifs) :

Plusieurs processus sont communs aux deux groupes. Lensemble donne
un premier niveau de 15 processus dployer (processus PO4, PO9, DS1,
DS2, DS4, DS5, DS8, DS9, DS10, DS13, AI3, AI4, AI5, AI6 et AI7). Les puristes
remarqueront que dautres processus devraient tre galement embarqus
ce stade (processus PO10, AI1 et AI2, par exemple) mais le but est de se
concentrer sur un projet pragmatique pour lequel le primtre ne devient
pas un risque.
Le parti pris de ne pas inclure les projets (processus PO10, AI1 et AI2) vient
de lampleur des changements mener et des pralables raliser (harmonisation des pratiques). Concrtement, il faut les dmarrer paralllement
sans quils ne soient encore matures ce stade.
Dploiement
Il commence par une vision claire de lorganisation et de la politique de
matrise des risques. Pour le fonctionnement, le dploiement de cet
ensemble de processus couvre bien les processus ITIL (ou ISO/IEC 20000),
la production, les contrats tiers et la scurit. Sur ces zones, il existe des
indicateurs remonts par les outils (gestion dappels, etc.) ; il convient de
les identifier et de les slectionner pour le pilotage des processus.
Le dploiement saccompagne dune srieuse conduite du changement sur
les fonctions impactes dans les processus, en particulier entre service
dassistance, exploitation, tiers et tudes. Deux cas sont privilgis pour
cela, dans la mesure o ils concernent la plupart des fonctions de la DSI :
la maintenance applicative sur son cycle de vie ;
la gestion des problmes en relation avec les acteurs de la DSI.
Lorganisation doit tre revue pour faire merger les pilotes des processus,
en particulier le responsable assistance/incidents et le responsable des
contrats tiers.
Ce dploiement dure six mois environ et ncessite ensuite au moins six mois
de fonctionnement pour tre bien rd. Des consultants externes assurent un
coaching priodique pour actionner la boucle damlioration permanente.
228
Niveau 2 Mesures et pilotage

Au deuxime niveau de dploiement, on doit bnficier des travaux qui
auront t effectus en amont pour embarquer les projets et le service
tudes. Il est toutefois prmatur de grer les cots, compte tenu du travail
faire en amont sur le systme dinformation concern. ce stade, on
commence piloter les processus dploys (processus SE1), ce qui reprsente en tant que tel un enjeu majeur et un effort considrable. La mise en
place du responsable de ce pilotage est un facteur de succs pour la boucle
damlioration entretenir.
PO8 Grer la qualit
PO10 Manager les projets
Ce niveau permet dtre quasiment complet sur les objectifs de management des ressources et de scurit. Il comprend aussi le pilotage gnral
(processus PO8 et SE1) et prvoit de soccuper srieusement de la communication. Simultanment, il faudra se prparer pour le niveau suivant. La
gestion des cots ncessite dengager la conception du systme dinformation
correspondant.
Niveau 3 Apport de valeur
Au troisime niveau de dploiement, il devient crucial de grer les cots et
les investissements (processus PO5 et DS6) : cest lobjectif principal de ce
niveau. Paralllement, on compltera le dispositif sur les axes stratgiques
(processus PO2 et PO3) et sur la surveillance du contrle interne et de la
conformit aux obligations externes (processus SE2 et SE3).
229
Niveau 4 Gouvernance des SI

Au dernier stade de dploiement, il reste faire progresser en maturit les processus PO1 et SE4 qui finalisent la construction de lalignement stratgique.
Le tableau 10-1 reprsente ce modle de maturit pragmatique, rsultat
des travaux raliss par les consultants de la socit ASK Conseil chez
leurs clients.
230
Niveau 4 - Gouvernance des SI
Niveau 3 - Apport de valeur
Niveau 2 - Mesures et pilotage

PO8 Grer la qualit
PO10 Manager les projets
Niveau 1 - Scurit et fonctionnement
Tableau 10-1 : Proposition de modle de maturit tag, ASK Conseil
En rsum
CobiT peut donner limage dun idal inaccessible : 34 processus avec
chacun son niveau de maturit, ses sous-processus, ces mesures et objectifs. Par o prendre le problme du dploiement ? Il est manifeste que
lorganisation doit suivre un rythme appropri, certains processus passant
en priorit par rapport dautres.
condition de respecter ces prcautions, le dploiement de CobiT, surtout
en association avec ITIL, est un objectif facile atteindre pour la majeure
partie des DSI. La difficult principale, on sy attendait, est informatique :
quelle application dvelopper pour grer les processus CobiT ?
231
PARTIE
IV
Annexes
AnnexeI
Glossaire
A
Agilit
Lagilit informatique est un concept utilis dans le domaine des systmes dinformation. Il est mis en uvre par un certain nombre de
mthodes visant avoir une grande ractivit face aux volutions des
besoins des mtiers, grce une collaboration troite avec le client
tout au long du dveloppement.
Alignement stratgique
Lalignement stratgique consiste :
sassurer que les plans stratgiques restent aligns sur les plans des
mtiers ;
dfinir, mettre jour et valider les propositions de valeur ajoute de
linformatique ;
aligner le fonctionnement de linformatique sur le fonctionnement de
lentreprise.
Apport de valeur
Lapport de valeur consiste :
mettre en uvre la proposition de valeur ajoute tout au long du cycle
de fourniture de services ;
sassurer que linformatique apporte bien les bnfices attendus sur le
plan stratgique ;
235
Partie IV Annexes
sattacher optimiser les cots ;

prouver la valeur intrinsque des SI.
Architecture informatique
Cadre de rfrence intgr pour faire voluer ou tenir jour les technologies existantes et en acqurir de nouvelles afin datteindre les objectifs
stratgiques et les objectifs mtier.
B
Balanced Scorecard (BSC)
Tableau de bord prospectif (ou quilibr), dclin selon quatre axes :
laxe Contribution et alignement, qui reprsente la valeur pour lentreprise des investissements informatiques consentis ;
laxe Clients et utilisateurs, qui reprsente lvaluation de la DSI par les
utilisateurs et clients des systmes ;
laxe Futur et anticipation, qui reprsente la veille quil faut mener pour
optimiser le systme dinformation (choix dinvestissement, ressources
humaines) afin de rpondre aux besoins et aux enjeux venir de
lentreprise ;
laxe Performances oprationnelles, qui reprsente les processus informatiques.
C
Catalogue des services
Document produit par la direction informatique dans le but dinformer ses
clients et ses utilisateurs sur les services et linfrastructure disponible.
Conformit
Mesure par laquelle les processus sont en conformit avec les lois, les
rglements et les contrats.
Condentialit
Mesure par laquelle linformation est protge des accs non autoriss.
236
AnnexeI Glossaire
Contrat dexploitation (CE)

Accord entre les diffrentes structures internes de la DSI charges,
ensemble, de la fourniture des services aux clients (OLA, Operational Level
Agreement).
Contrat de services (CS)

Accord entre un fournisseur de services et le client/utilisateur qui dfinit
les niveaux convenus pour un service et la faon dont ils sont mesurs
(SLA, Service Level Agreement).
Contrle interne
Politiques, procdures, pratiques et structures organisationnelles conues
pour fournir une assurance raisonnable que les objectifs mtier seront
atteints et que les vnements indsirables seront prvenus ou dtects et
corrigs.
D
Dictionnaire de donnes
Base de donnes prcisant, pour chaque donne, le nom, le type, les
valeurs minimale et maximale, la source, les autorisations daccs, le(s)
programme(s) applicatif(s) utilisant cette donne.
Disponibilit
Mesure par laquelle linformation est disponible pour les destinataires en
temps voulu.
E
Efcacit
Mesure par laquelle linformation contribue au rsultat des processus
mtier par rapport aux objectifs fixs.
237
Partie IV Annexes
Efcience
Mesure par laquelle linformation contribue au rsultat des processus
mtier au meilleur cot.
F
Fiabilit
Correspond laptitude dun systme fonctionner durablement avec un
minimum dincidents ou dinterruptions.
G
Gestion des ressources
La gestion des ressources consiste optimiser linvestissement dans les
ressources informatiques vitales et bien les grer (applications, informations, infrastructures et personnes).
Gestion des risques

La gestion des risques exige :
une conscience des risques de la part des cadres suprieurs de lentreprise ;
une vision claire de lapptence de lentreprise pour le risque ;
une bonne connaissance des exigences de conformit ;
de la transparence propos des risques significatifs encourus par
lentreprise ;
lattribution des responsabilits dans la gestion des risques au sein de
lentreprise.
Gouvernance
La gouvernance dcrit comment un systme est dirig et contrl. Elle
associe le pilotage, cest--dire sassurer que les dcisions actuelles prparent convenablement lavenir, et le contrle, cest--dire mesurer lcart par
rapport ce qui tait prvu (CIGREF).
238
AnnexeI Glossaire
Gouvernance dentreprise
Ensemble des responsabilits et pratiques assures par le conseil
dadministration et la direction gnrale, dont le but est de fixer la stratgie, de garantir que les objectifs sont atteints et que les risques sont
grs correctement, et de vrifier que les ressources de lentreprise sont utilises bon escient.
I
Incident
Tout vnement qui ne fait pas partie du fonctionnement standard dun
service et qui cause, ou peut causer, une interruption ou une rduction de
la qualit de ce service.
Infrastructures
Technologies, ressources humaines et quipements qui permettent le
traitement des applications.
Intgrit
Mesure par laquelle linformation correspond la ralit de la situation.
K
Key Goal Indicator (KGI)
Indicateur li un processus donn permettant de vrifier que ce processus
atteint ses objectifs.
Key Performance Indicator (KPI)

Indicateur li un objectif donn permettant de suivre la ralisation de cet
objectif.
239
Partie IV Annexes
M
Mesure de la performance
La mesure de la performance consiste en un suivi et une surveillance de la
mise en uvre de la stratgie, de laboutissement des projets, de lutilisation des ressources, de la performance des processus et de la fourniture
des services.
O
Operational Level Agreement (OLA)
Voir Contrat dexploitation.
P
Problme
Origine inconnue dun ou plusieurs incidents existants ou potentiels.
R
Risque
Potentialit dune menace donne exploiter les points faibles dun actif
ou dun groupe dactifs pour provoquer des pertes et/ou des dommages
ces actifs. Il se mesure en gnral par une combinaison de consquences
et de probabilits doccurrence.
S
Service Level Agreement (SLA)
Voir Contrat de service.
240
AnnexeI Glossaire
Service Level Requirement (SLR)

Document dcrivant les niveaux de services demands par le client.
U
Underpinning Contract (UC)
Niveaux de services ngocis avec les tiers.
241
AnnexeII
Objectifs
du systme
dinformation
et processus CobiT
Les tableaux suivants, classs par domaine, rcapitulent lensemble des
liens entre les 28 objectifs du systme dinformation et les 34 processus
CobiT.
243
Partie IV Annexes
Tableau II-1 : Objectifs du systme dinformation et processus du domaine Planier et Organiser
Ragir aux exigences mtier en accord avec la

stratgie mtier.
Obj. 02 Ragir aux exigences de la gouvernance en accord

avec les orientations du CA.
Obj. 03 Sassurer de la satisfaction des utilisateurs naux

lgard des offres et des niveaux de services.
Obj. 04 Optimiser lutilisation de linformation.
Obj. 05 Donner de lagilit linformatique.
Obj. 06 Dterminer comment traduire les exigences mtier de

fonctionnement et de contrle en solutions
Obj. 07
Acqurir et maintenir fonctionnels des systmes

applicatifs intgrs et standardiss.
Obj. 08 Acqurir et maintenir oprationnelle une

infrastructure informatique intgre et standardise.
Obj. 09 Se procurer et conserver les comptences ncessaires
la mise en uvre de la stratgie informatique.
Obj. 10
Sassurer de la satisfaction rciproque dans les

relations avec les tiers.
Obj. 11
Sassurer de lintgration progressive des solutions

informatiques aux processus mtier.
Obj. 12
Sassurer de la transparence et de la bonne

comprhension des cots, bnces, stratgies,
Obj 13
Sassurer dune bonne utilisation et des bonnes

performances des applications et des solutions
informatiques.
Obj. 14
Protger tous les actifs informatiques et en tre

comptable.
Obj. 15
Optimiser linfrastructure, les ressources et les

capacits informatiques.
244
PO9 : valuer et grer les risques
PO7 : Grer les ressources humaines

de linformatique
PO5 : Grer les investissements

informatiques
PO6 : Faire connatre les buts
PO4 : Dnir les processus,

lorganisation
PO3 : Dterminer lorientation

technologique
PO2 : Dnir larchitecture

de linformation
Obj. 01
Processus
PO1 : Dnir un plan informatique
stratgique
Objectifs
AnnexeII Objectifs du systme dinformation et processus CobiT
Tableau II-1 : Objectifs du systme dinformation et processus du domaine Planier et Organiser (suite)
Obj. 16
Rduire le nombre de dfauts et de retraitements

touchant la fourniture de solutions et de services.
Obj. 17
Obj. 18
Montrer clairement les consquences pour lentreprise

des risques lis aux objectifs et aux ressources
informatiques.
Sassurer que l'information critique et condentielle nest

pas accessible ceux qui ne doivent pas y accder.
Obj. 20 Sassurer que les transactions mtier automatises et

les changes dinformations sont ables.
Sassurer que les services et linfrastructure

informatique peuvent rsister/se rtablir
convenablement en cas de panne due une erreur,
Obj. 22 Sassurer quun incident ou une modication dans la

fourniture dun service informatique na quun impact
minimum sur lactivit.
Obj. 19
Obj. 21
PO9 : valuer et grer les risques
PO7 : Grer les ressources humaines

de linformatique
PO5 : Grer les investissements

informatiques
PO6 : Faire connatre les buts
PO4 : Dnir les processus,

lorganisation
PO3 : Dterminer lorientation

technologique
PO2 : Dnir larchitecture

de linformation
Processus
PO1 : Dnir un plan informatique
stratgique
Objectifs
Obj. 23 Sassurer que les services informatiques sont

disponibles dans les conditions requises.
Obj. 24
Amliorer la rentabilit de linformatique et sa

contribution la protabilit de lentreprise.
Obj. 25 Livrer les projets temps et dans les limites

budgtaires en respectant les standards de qualit.
Obj. 26 Maintenir lintgrit de linformation et de

linfrastructure de traitement.
Obj. 27
Assurer la conformit de linformatique aux lois et aux

rglements.
Obj. 28 Sassurer que linformatique fait preuve dune qualit

de service efciente en matire de cots,
damlioration continue et de capacit sadapter
des changements futurs.
245
Partie IV Annexes
Tableau II-2 : Objectifs du systme dinformation et processus du domaine Acqurir et Implmenter
AI5 : Acqurir des ressources

informatiques
AI4 : Faciliter le fonctionnement

et lutilisation
AI3 : Acqurir une infrastructure

technique

des solutions
et des modications
Ragir aux exigences mtier en accord avec la stratgie

mtier.
AI6 : Grer les changements
Obj. 01
AI2 : Acqurir des applications

Processus
AI1 : Trouver des solutions
informatiques
Objectifs
Obj. 02 Ragir aux exigences de la gouvernance en accord avec

les orientations du CA.

Obj. 06 Dterminer comment traduire les exigences mtier de
fonctionnement et de contrle en solutions
Obj. 07

Obj. 08 Acqurir et maintenir oprationnelle une infrastructure

informatique intgre et standardise.
Obj. 09 Se procurer et conserver les comptences ncessaires

la mise en uvre de la stratgie informatique.
Obj. 10
Sassurer de la satisfaction rciproque dans les relations

avec les tiers.
Obj. 11

Obj. 12

comprhension des cots, bnces, stratgie,
Obj. 13

informatiques.
Obj. 14

comptable.
Obj. 15
Optimiser linfrastructure, les ressources et les capacits

informatiques.
246
Tableau II-2 : Objectifs du systme dinformation et processus du domaine Acqurir et Implmenter (suite)
Obj. 17
Obj. 18
Montrer clairement les consquences pour lentreprise

des risques lis aux objectifs et aux ressources
informatiques.
Obj. 19
Sassurer que linformation critique et condentielle nest

pas accessible ceux qui ne doivent pas y accder.
AI5 : Acqurir des ressources

informatiques
AI3 : Acqurir une infrastructure

technique
AI4 : Faciliter le fonctionnement

et lutilisation

des solutions
et des modications

AI6 : Grer les changements
Obj. 16
AI2 : Acqurir des applications

Processus
AI1 : Trouver des solutions
informatiques
Objectifs
Obj. 20 Sassurer que les transactions mtier automatises et les

changes dinformations sont ables.
Sassurer que les services et linfrastructure informatique

peuvent rsister/se rtablir convenablement en cas de
panne due une erreur, une attaque dlibre ou
un sinistre.
Obj. 21
Obj. 22 Sassurer quun incident ou une modication dans la

fourniture dun service informatique na quun impact
minimum sur lactivit.
Obj. 23 Sassurer que les services informatiques sont disponibles

dans les conditions requises.
Obj. 24

Obj. 25 Livrer les projets temps et dans les limites budgtaires

en respectant les standards de qualit.
Obj. 27
Assurer la conformit de linformatique aux lois et aux

rglements.
Obj. 28 Sassurer que linformatique fait preuve dune qualit de

service efciente en matire de cots, damlioration
continue et de capacit sadapter des changements
futurs.
247
Partie IV Annexes
Tableau II-3 : Objectifs du systme dinformation et processus du domaine Dlivrer et Supporter
DS13 : Grer lexploitation
DS12 : Grer lenvironnement

physique
DS11 : Grer les donnes
DS10 : Grer les problmes
DS9 : Grer la conguration
DS6 : Identier et imputer
DS5 : Assurer la scurit
DS4 : Assurer un service continu
DS3 : Grer la performance
Ragir aux exigences mtier en accord avec la

stratgie mtier.
Obj. 01
DS2 : Grer les services tiers
Processus
DS1 : Dnir et grer
Objectifs
Obj. 02 Ragir aux exigences de la gouvernance en

accord avec les orientations du CA.

Obj. 06 Dterminer comment traduire les exigences
mtier de fonctionnement et de contrle en
solutions automatises efcaces et efcientes.
Obj. 07

Obj. 08 Acqurir et maintenir oprationnelle une

infrastructure informatique intgre et standardise.
Obj. 09 Se procurer et conserver les comptences
ncessaires la mise en uvre de la stratgie
informatique.
Obj. 10
Sassurer de la satisfaction rciproque dans les

relations avec les tiers.
Obj. 11

Obj. 12

comprhension des cots, bnces, stratgie,
Obj. 13

informatiques.
Obj. 14

comptable.
Obj. 15
Optimiser linfrastructure, les ressources et les

capacits informatiques.
248
Tableau II-3 : Objectifs du systme dinformation et processus du domaine Dlivrer et Supporter (suite)
Obj. 16

Obj. 17
Obj. 18
Montrer clairement les consquences pour

lentreprise des risques lis aux objectifs et aux
ressources informatiques.
Sassurer que l'information critique et

condentielle nest pas accessible ceux qui ne
doivent pas y accder.
Obj. 20 Sassurer que les transactions mtier automatises

et les changes dinformations sont ables.
Obj. 19
Sassurer que les services et linfrastructure

informatique peuvent rsister/se rtablir
convenablement en cas de panne due une
erreur, une attaque dlibre ou un sinistre.
Obj. 22 Sassurer quun incident ou une modication

dans la fourniture dun service informatique na
quun impact minime sur lactivit.
Obj. 21
Obj. 23 Sassurer que les services informatiques sont

disponibles dans les conditions requises.
Obj. 24
Assurer la conformit de linformatique aux lois

et aux rglements.
Obj. 28 Sassurer que linformatique fait preuve dune

qualit de services efciente en matire de cots,
damlioration continue et de capacit
sadapter des changements futurs.
249
DS13 : Grer lexploitation
Obj. 25 Livrer les projets temps et dans les limites

budgtaires en respectant les standards de qualit
Obj. 27


DS12 : Grer lenvironnement

physique
DS11 : Grer les donnes
DS10 : Grer les problmes
DS9 : Grer la conguration
DS6 : Identier et imputer
DS5 : Assurer la scurit
DS4 : Assurer un service continu
DS3 : Grer la performance
DS2 : Grer les services tiers
Processus
DS1 : Dnir et grer
Objectifs
Partie IV Annexes
Tableau II-4 : Objectifs du systme dinformation et processus du domaine Surveiller et valuer
Obj. 01
Obj. 02
Obj. 03
Sassurer de la satisfaction des utilisateurs naux lgard des offres et des

niveaux de services.
Obj. 04
Obj. 05
Obj. 06
Dterminer comment traduire les exigences mtier de fonctionnement et de

contrle en solutions automatises efcaces et efcientes.
Obj. 07
Acqurir et maintenir fonctionnels des systmes applicatifs intgrs et

standardiss.
Obj. 08
Acqurir et maintenir oprationnelle une infrastructure informatique intgre et

standardise.
Obj. 09
Se procurer et conserver les comptences ncessaires la mise en uvre de la

stratgie informatique.
Obj. 10
Sassurer de la satisfaction rciproque dans les relations avec les tiers.
Obj. 11
Sassurer de lintgration progressive des solutions informatiques aux processus

mtier.
Obj. 12
Sassurer de la transparence et de la bonne comprhension des cots, bnces,

stratgie, politiques et niveaux de services des SI.
Obj. 13
Sassurer dune bonne utilisation et des bonnes performances des applications et

des solutions informatiques.
Obj. 14
Obj. 15
Obj. 16
Rduire le nombre de dfauts et de retraitements touchant la fourniture de

solutions et de services.
Obj. 17
SE4 : Mettre en place une gouvernance

des SI
250
SE3 : Sassurer de la conformit aux

SE2 : Surveiller et valuer le contrle

interne
Processus
SE1 : Surveiller et valuer la

performance du SI
Objectifs
Tableau II-4 : Objectifs du systme dinformation et processus du domaine Surveiller et valuer (suite)
Obj. 19
Sassurer que linformation critique et condentielle nest pas accessible ceux

qui ne doivent pas y accder.
Obj. 20
Sassurer que les transactions mtier automatises et les changes dinformations

sont ables.
Obj. 21
Sassurer que les services et linfrastructure informatique peuvent rsister/se

rtablir convenablement en cas de panne due une erreur, une attaque
dlibre ou un sinistre.
Obj. 22
Sassurer quun incident ou une modication dans la fourniture dun service

informatique na quun impact minimum sur lactivit.
Obj. 23
Sassurer que les services informatiques sont disponibles dans les conditions
requises.
Obj. 24
Amliorer la rentabilit de linformatique et sa contribution la protabilit de

lentreprise.
Obj. 25
Livrer les projets temps et dans les limites budgtaires en respectant les
standards de qualit.
Obj. 26
Maintenir lintgrit de linformation et de linfrastructure de traitement.
Obj. 27
Obj. 28
Sassurer que linformatique fait preuve dune qualit de service efciente en

matire de cots, damlioration continue et de capacit sadapter des
changements futurs.
251
SE4 : Mettre en place une gouvernance

des SI
Montrer clairement les consquences pour lentreprise des risques lis aux
objectifs et aux ressources informatiques.
SE3 : Sassurer de la conformit aux

Obj. 18
SE2 : Surveiller et valuer le contrle

interne
Processus
SE1 : Surveiller et valuer la

performance du SI
Objectifs
Index
Assurer la scurit des systmes

(DS5) 144
Assurer un service continu (DS4) 140
Acqurir des applications et en

assurer la maintenance (AI2) 99
Acqurir des ressources
informatiques (AI5) 112
Acqurir une infrastructure

technique et en assurer la
maintenance (AI3) 104
besoins mtier 54, 99
action corrective 182
budget 69
AFAI (Association franaise pour

laudit et le conseil en Informatique)
3
BSC (Balanced Scorecard) 12, 205,

236
Agilit 235
AI1 Trouver des solutions
informatiques 95
AI2 Acqurir des applications et
en assurer la maintenance 99
AI3 Acqurir une infrastructure
technique et en assurer la
maintenance 104
AI4 Faciliter le fonctionnement et
lutilisation 108
cadre de rfrence
processus informatique 64
centre de services 209
CMMI (Capability Maturity Model
Integration) 22, 215
CobiT
Quick Scan 201
Quickstart 223
AI5 Acqurir des ressources

informatiques 112
CobiT (Control OBjectives for

Information and related Technology)
3
AI6 Grer les changements 116
CobiT Online 41
AI7 Installer et valider des

solutions et des modifications 121
CobiT version 4 4
CobiT version 4.1 4
253
Index
domaines de la gouvernance
communication 73
comptences 77
alignement stratgique 7
conception 102
apport de valeur 8
contrat
dexploitation (CE) 128
de services (CS) 128
gestion des ressources 8

gestion des risques 9
mesure de la performance 9
COSO Committee of Sponsoring

Organizations of the Treadway
Commission 3, 29
donnes 237
critres
confidentialit 31, 85, 144, 236
conformit 31, 187, 236
disponibilit 31, 85, 117, 171, 237
efficacit 31, 52, 60, 64, 69, 73, 77,
81, 89, 96, 101, 109, 117, 121, 128,
133, 137, 141, 153, 156, 160, 163,
175, 179, 184, 190, 237
efficience 31, 56, 60, 64, 69, 77, 81,
89, 101, 105, 109, 113, 117, 128, 133,
137, 149, 156, 163, 175, 179, 184,
190, 238
fiabilit 31, 149, 167, 238
intgrit 31, 56, 85, 117, 141, 144,
167, 171, 239
cycle de dveloppement 100
D
Dfinir et grer les niveaux de
services (DS1) 127
Dfinir larchitecture de
linformation (PO2) 55
Dfinir les processus, lorganisation
et les relations de travail (PO4) 63
Dfinir un plan informatique
stratgique (PO1) 51
Dterminer lorientation
technologique (PO3) 59
dictionnaire des donnes 58
DS1 Dfinir et grer les niveaux de

services 127
DS2 Grer les services tiers 132
DS3 Grer la performance et la
capacit 136
DS4 Assurer un service continu 140
DS5 Assurer la scurit des
systmes 144
148
DS7 Instruire et former les
utilisateurs 153
DS8 Grer le service dassistance
aux client et les incidents 156
DS9 Grer la configuration 160
DS10 Grer les problmes 163
DS11 Grer les donnes 166
DS12 Grer lenvironnement
physique 171
DS13 Grer lexploitation 175
E
EFQM (European Foundation for
Quality Management) 25
environnement de tests 123
valuer et grer les risques (PO9) 84
externalisation 113, 145
254
Index
apport de valeur 69, 96, 101,

109, 117, 121, 128, 133, 141, 153,
156, 160, 163, 167, 184, 190, 235
Faciliter le fonctionnement et
lutilisation (AI4) 108
gestion des ressources 56, 60,

64, 77, 105, 112, 117, 128, 137,
149, 160, 167, 175, 190, 238
Faire connatre les buts et les

orientations du management (PO6)
73
gestion des risques 64, 73, 85,

133, 141, 144, 167, 171, 183, 187,
190, 238
mesure de la performance 128,
179, 190, 240
G
Grer lenvironnement physique
(DS12) 171
Grer lexploitation (DS13) 175

Grer la configuration (DS9) 160
Grer la performance et la capacit
(DS3) 136
Grer la qualit (PO8) 81
Grer le service dassistance aux
clients et les incidents (DS8) 156
Grer les changements (AI6) 116
Grer les donnes (DS11) 166
Grer les investissements
informatiques (PO5) 68
Grer les problmes (DS10) 163
Grer les projets (PO10) 163
Grer les ressources humaines de
linformatique (PO7) 76
Grer les services tiers (DS2) 132
gestion de projet 89
Identifier et imputer les cots (DS6)

148
infrastructure 104, 239
Installer et valider des solutions et
des modifications (AI7) 121
Instruire et former les utilisateurs
(DS7) 153
investissement informatique 104
ISACA (Information Systems Audit
and Control Association) 3, 197
IT Assurance Framework (ITAF) 39
IT Assurance Guide
Using CobiT 39
ITGI (Information Technology
Governance Institute) 3
ITIL (Information Technology
Infrastructure Library) 19, 207
gestion de services
ITIL V2 19
ISO/IEC 20000 20
ITIL V3 19, 21
gouvernance
domaines
alignement stratgique 52, 56,
73, 77, 81, 85, 89, 96, 101, 128,
187, 190, 235
L
loi Sarbanes-Oxley 4, 40, 200
255
Index
Obj. 17 86, 164, 184

Obj. 18 86
Obj. 19 74, 145, 168, 172
Obj. 20 74, 122, 145
Obj. 21 74, 122, 141, 145, 172, 176,
184
Obj. 22 74, 118, 141, 172
Obj. 23 137, 141, 157, 176
Obj. 24 70, 113, 150
Obj. 25 82, 90
Obj. 26 118, 145
Obj. 27 168, 184, 188, 191
Obj. 28 70, 150, 181, 191
qualit 83
M
management des risques 85
Manager les projets (PO10) 88
Mettre en place une gouvernance
des SI (SE4) 190
modle de maturit 34
CMMI 23
CobiT 15
tag 225
Objectifs du systme dinformation

et processus CobiT 243
niveau de service 128
offre de services 52
organisation 64
objectifs
mtier 51
Obj. 01 53, 57, 65, 90, 97, 118, 122,
129, 137, 180
Obj. 02 53, 65, 90, 180, 191
Obj. 03 109, 129, 134, 154, 157, 164,
176
Obj. 04 57, 168
Obj. 05 57, 65, 78, 105
Obj. 06 97, 101, 118
Obj. 07 61, 101, 113
Obj. 08 105, 113
Obj. 09 78, 113
Obj. 10 134
Obj. 11 57, 109, 122
Obj. 12 70, 74, 129, 134, 150, 181,
191
Obj. 13 74, 109, 122, 154, 157
Obj. 14 86, 145, 161, 172, 184
Obj. 15 61, 105, 137, 154, 161
Obj. 16 82, 109, 118, 122, 164
P
PCA (Plan de continuit des
activits) 87
pilotage stratgique 205
plan
dinfrastructure technologique 60,
104
de compte 151
de continuit informatique 142
de maintenance de linfrastructure
106
de traitement des risques 87
informatique
stratgique 8, 51, 112
tactique 52, 112
PO1 Dfinir un plan informatique
stratgique 51
PO2 Dfinir larchitecture de
linformation 55
256
Index
PO3 Dterminer lorientation

technologique 59
PO4 Dfinir les processus,
lorganisation et les relations de
travail 63
PO5 Grer les investissements
informatiques 68
PO6 Faire connatre les buts et les
orientations du management 73
PO7 Grer les ressources
humaines de linformatique 76
PO8 Grer la qualit 81
PO9 valuer et grer les risques 84
PO10 Grer les projets 88
politique
dachat 112
qualit 83
portefeuille de projets 52
PRA (Plan de reprise dactivits) 87
procdure dachat 112
programme dinvestissement 54
Q
qualit
ISO 9001 24, 215, 218
ISO/IEC 9001 81
R
rfrentiel
daudit 198
de comptences 79
responsabilits
achats 135
cellule mthodes et qualit 131
centre dassistance 159
comit darchitecture 62
257
comit de pilotage informatique

67, 71
comit stratgique informatique 67
conseil dadministration 192
contrle de conformit 189
contrle interne 170, 182, 186
directeur des systmes
dinformation 67
directeur gnral 54, 67, 72, 182,
192
direction financire 88, 152
direction mtier 88, 92
DRH 155
DSI 55, 59, 62, 72, 76, 80, 83, 88, 92,
99, 107, 115, 120, 124, 131, 135, 148,
155, 182, 186, 189
filire qualit 67, 83
filire scurit 67, 87
gestionnaire de la configuration
162
office des projets (PMO) 92, 99, 103
personnel de la DSI 76
propritaire du processus mtier
98, 111, 124, 148, 155
RAQ 67, 83
responsable administratif 115, 132,
143, 152
responsable architecture 59, 62
responsable de loffice des projets
(PMO) 143
responsable de la gestion des
problmes 165
responsable dveloppements 103,
111, 115, 120, 125, 143
responsable tudes 186
responsable exploitation 107, 111,
115, 120, 124, 131, 139, 143, 170,
174, 177, 186
responsable mtier 54, 58, 72, 98
RRH 80
RSSI 67
service client 159
service dassistance 131
Index
SLA (Service Level Agreement) 115,

128, 240
ressources
application 31
information 31
infrastructure 31
personnes 31
SLR (Service Level Requirement)

128, 241
SMQ (Systme de management de
la qualit) 81
roue de Deming (PDCA) 181
SMSI (Systme de management de

la scurit de linformation) 87
spcifications dachat 114

Surveiller et valuer la performance
des SI (SE1) 179
Sassurer de la conformit aux

obligations externes (SE3) 187
schma directeur 52
Surveiller et valuer le contrle

interne (SE2) 183
SE1 Surveiller et valuer la

performance des SI 179
SE2 Surveiller et valuer le

contrle interne 183
tableau de bord 180
SE3 Sassurer de la conformit aux

obligations externes 187
temps de travail imputation 151
SE4 Mettre en place une

gouvernance des SI 190

(AI1) 95
scurit
informatique 14, 144, 214
ISO/IEC 15408 16
ISO/IEC 17799 15
ISO/IEC 27001 14, 87, 215
ISO/IEC 27002 14, 15, 145, 214
slection des fournisseurs 112
test de recette 123
V
VAL IT 41
veille
rglementaire 188
technologique 59
258
Page 1
CobiT
R
Les auteurs
Dominique Moisand a occup divers postes
responsabilit au sein de PricewaterhouseCoopers
avant de crer en 1990 le cabinet ASK, conseil en
management et organisation, qui s'attache notamment amliorer la gouvernance des systmes
d'information des grands comptes. Vice-prsident
de lAFAI (Association franaise de laudit et du
conseil informatiques) pendant cinq ans, il a collabor plusieurs traductions des ouvrages de
lISACA et diverses publications : Matrise douvrage et matrise duvre, Audit des projets, Le
client pivot de la gouvernance Il anime avec
Fabrice Garnier de Labareyre des sminaires sur la
convergence des rfrentiels de la DSI.
Associ du cabinet ASK Conseil, Fabrice Garnier
de Labareyre exerce le mtier de consultant dans
le domaine des technologies de linformation
depuis plus de quinze ans. Frquemment conseil
de la Direction gnrale et de la DSI de grandes
entreprises, il intervient sur les missions stratgiques relevant de la gouvernance des systmes
dinformation : pilotage des organisations, matrise
des grands projets, performance et qualit des services, scurit de linformation Il est galement
administrateur de lAFAI.
qui sadresse ce livre ?

Aux auditeurs
Aux managers de linformatique
et aux DSI
Aux chefs dentreprise
et aux directions financires
Aux consultants et aux formateurs
Aux acteurs de linfogrance
frence incontournable au sein de la communaut des auditeurs informatiques depuis plus de dix ans, CobiT (Control
OBjectives for Information and related Technology) est
devenu un standard de la gouvernance des systmes dinformation.
Publies par lISACA (Information Systems Audit and Control
Association) et lITGI (Information Technology Governance Institute),
les dernires versions 4.0 et 4.1 rpondent tout particulirement aux
problmatiques de management des systmes dinformation.
Sappuyant sur la version 4.1 de CobiT, cet ouvrage en trois volets
replace ce rfrentiel dans le contexte global de la gouvernance des
systmes dinformation. La premire partie dresse un panorama des
diffrents rfrentiels existants, en dcrivant leurs champs daction
et leur positionnement vis--vis de CobiT. Dans la deuxime partie
sont dtaills les 34 processus de CobiT selon un plan standard, avec
mise en lumire de leurs forces et faiblesses. Enfin, la troisime partie expose des cas pratiques dutilisation et de dploiement de CobiT,
correspondant un vritable mode demploi du rfrentiel. Cet
ouvrage apportera ainsi des rponses pragmatiques tous ceux qui
souhaitent implmenter CobiT dans leur systme dinformation
ou le concilier avec dautres rfrentiels comme ITIL, CMMi ou
ISO 27001.
Au sommaire
CobiT et la gouvernance TI. Prsentation gnrale de CobiT.
Historique de CobiT. Les cinq axes stratgiques. Les autres
rfrentiels de la gouvernance des TI. Le pilotage stratgique.
Le management de la scurit. ITIL : le management des
services. Le management des tudes. Les modles "qualit".
Apprhender CobiT. Documents et publications autour de
CobiT. qui s'adresse CobiT ? Les limites : ce que CobiT n'est
pas. Description dtaille des processus. Planifier et Organiser. Acqurir et Implmenter. Dlivrer et Supporter. Surveiller
et valuer. Mettre en oeuvre CobiT. CobiT pour l'audit. Le
code professionnel d'thique. La mission d'audit. Le contrle
interne. L'outil Quick Scan. CobiT fdrateur. Le pilotage
stratgique. Conjuguer ITIL et CobiT. CobiT et la norme
ISO/IEC 27002. CobiT et la norme ISO/IEC 27001. CobiT et
CMMi. La certification. Transformer la DSI. CobiT Quickstart.
Pour un dploiement tag. Annexes. Glossaire. Objectifs
du systme d'information et processus CobiT.
FABRICE
14:59
CobiT
10/12/08
DOMINIQUE MOISAND
GARNIER DE LABAREYRE
12427_Cobit_17x23
FABRICE GARNIER DE LABAREYRE
CobiT
Implmentation ISO 27001


Pour Une Meilleure Gouvernance Des Systèmes D'information - (WWW - Worldmediafiles.CoM) PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Pour Une Meilleure Gouvernance Des Systèmes D'information - (WWW - Worldmediafiles.CoM) PDF

Transféré par

Droits d'auteur :

Formats disponibles

14:59

Associ du cabinet ASK Conseil, Fabrice Garnier

qui sadresse ce livre ?

Sappuyant sur la version 4.1 de CobiT, cet ouvrage en trois volets

Code diteur : G12427

Aux acteurs de linfogrance

Pour une meilleure gouvernance

CHEZ LE MME DITEUR

Prface de Didier Lambert

Le code de la proprit intellectuelle du 1er juillet 1992 interdit en effet expressment la

Livre CobiT.book Page V Lundi, 1. dcembre 2008 2:48 14

Livre CobiT.book Page VI Lundi, 1. dcembre 2008 2:48 14

Livre CobiT.book Page VII Lundi, 1. dcembre 2008 2:48 14

Table des matires

Les cinq axes stratgiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapitre 2 Les autres rfrentiels de la gouvernance des TI . . . . . . . . . . . 11

Le Balanced Scorecard (BSC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

La norme ISO/IEC 27001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Les normes ISO/IEC 17799 et ISO/IEC 27002 . . . . . . . . . . . . . . . . . . .

Les critres communs (ISO/IEC 15408) . . . . . . . . . . . . . . . . . . . . . . . .

ITIL : le management des services . . . . . . . . . . . . . . . . . . . . . . . . . . .

ITIL V2 et la norme ISO/IEC 20000 . . . . . . . . . . . . . . . . . . . . . . . . . . .

Le management des tudes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Le CMMI et la norme ISO/IEC 15504 . . . . . . . . . . . . . . . . . . . . . . . . .

Les modles qualit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

La norme ISO 9001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Livre CobiT.book Page VIII Lundi, 1. dcembre 2008 2:48 14

Table des matires

Chapitre 3 Apprhender CobiT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Les composants de CobiT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Les processus dans CobiT V4.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Les documents et publications autour de CobiT . . . . . . . . . . . . . . .

destination des mtiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

destination de la gouvernance TI, du contrle et de la scurit . . . . . . . .

Description dtaille de certaines publications . . . . . . . . . . . . . . . . . . . . .

Comment aborder CobiT ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

qui sadresse CobiT ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Les limites : ce que CobiT nest pas . . . . . . . . . . . . . . . . . . . . . . . . . . . .

PO1 Dfinir un plan informatique stratgique . . . . . . . . . . . . . . . . . . .

PO2 Dfinir larchitecture de linformation . . . . . . . . . . . . . . . . . .

PO3 Dterminer lorientation technologique . . . . . . . . . . . . . . . . . . .

PO4 Dfinir les processus, lorganisation et les relations de travail 63

PO6 Faire connatre les buts et les orientations du management .

PO7 Grer les ressources humaines de linformatique . . . . . . . . .

PO8 Grer la qualit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

PO9 valuer et grer les risques . . . . . . . . . . . . . . . . . . . . . . . . . . .

PO10 Grer les projets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Livre CobiT.book Page IX Lundi, 1. dcembre 2008 2:48 14

Table des matires

Chapitre 5 Acqurir et Implmenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

AI2 Acqurir des applications et en assurer la maintenance . . . . . .

AI3 Acqurir une infrastructure technique et en assurer

Chapitre 6 Dlivrer et Supporter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Chapitre 7 Surveiller et valuer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

Livre CobiT.book Page X Lundi, 1. dcembre 2008 2:48 14

Table des matires

Chapitre 9 CobiT fdrateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Livre CobiT.book Page XI Lundi, 1. dcembre 2008 2:48 14

Table des matires

Chapitre 10 Transformer la DSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

Livre CobiT.book Page XII Lundi, 1. dcembre 2008 2:48 14

Livre CobiT.book Page XIII Lundi, 1. dcembre 2008 2:48 14

Livre CobiT.book Page XIV Lundi, 1. dcembre 2008 2:48 14