CobiT - Pour Une Meilleure Gouvernance Des Systèmes D - Information

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.
D O M I N I Q U E M O I S A N D 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
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 : dmystier, 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
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 5 5 7
Chapitre 2 Les autres rfrentiels de la gouvernance des TI . . . . . . . . . . . 11

Le pilotage stratgique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le COSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le Balanced Scorecard (BSC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le management de la scurit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . ITIL V3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le management des tudes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le CMMI et la norme ISO/IEC 15504 . . . . . . . . . . . . . . . . . . . . . . . . . Les modles qualit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . La norme ISO 9001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11 12 14 14 15 16 19 20 21 22 22 24 24
VII
Table des matires
Le modle EFQM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le dveloppement durable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . En rsum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25 26 27 29 29 30 32 36 37 37 37 38 38 43 44 46 46
Chapitre 3 Apprhender CobiT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Description gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Les composants de CobiT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Les processus dans CobiT V4.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Les documents et publications autour de CobiT . . . . . . . . . . . . . . . destination de la direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . destination des mtiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . destination de la gouvernance TI, du contrle et de la scurit . . . . . . . . Autres publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Description dtaille de certaines publications . . . . . . . . . . . . . . . . . . . . . Comment aborder CobiT ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . qui sadresse CobiT ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Les limites : ce que CobiT nest pas . . . . . . . . . . . . . . . . . . . . . . . . . . . . En rsum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Partie II Description dtaille des processus

Chapitre 4 Planifier et Organiser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PO1 Dnir un plan informatique stratgique . . . . . . . . . . . . . . . . . . . PO2 Dfinir larchitecture de linformation . . . . . . . . . . . . . . . . . . PO3 Dterminer lorientation technologique . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . PO10 Grer les projets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . En rsum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 51 55 59 68 73 76 81 84 88 93
PO4 Dfinir les processus, lorganisation et les relations de travail 63
VIII
Table des matires
Chapitre 5 Acqurir et Implmenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

AI1 Trouver des solutions informatiques . . . . . . . . . . . . . . . . . . . . . AI2 Acqurir des applications et en assurer la maintenance . . . . . . 95 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
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
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
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 (Ofce of Government Commerce), trs prsent en Grande-Bretagne, en particulier lorigine dITIL, et enn 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 : Planier 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
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 gure qu titre indicatif.
XIV
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 retent les bonnes pratiques mises au point au l 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 prgurant 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) an de redonner conance 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 nanciers. 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 nancire, 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 Planifier et Organiser Exigences de fonctionnement Exigences de contrle Acqurir et Implmenter Dlivrer et Supporter Services automatiss RESPONSABILITE METIER Contrle mtier
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.
Surveiller et Evaluer
CONTROLES APPLICATIFS
Figure 1-1 : Rpartition des responsabilits de la gouvernance TI
La gure 1-1 illustre aussi bien la responsabilit de la fonction IT sur les quatre grands domaines de la gouvernance selon CobiT (planier et organiser, dlivrer et supporter, surveiller et valuer, acqurir et implmenter) que les responsabilits des mtiers. CobiT se xe des objectifs trs pragmatiques retant 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 (efcacit et efcience) ;
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 xs. 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 dnition de ses propres objectifs et leur valuation priodique.
Les membres de lISACA utilisent CobiT dans de nombreux secteurs dactivit travers le monde. Les spcicits 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 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. 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. 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.
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.
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.
Gestion des ressources
Mesure de la performance
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 signie que le projet de mise disposition de commande en ligne doit tre identi et prioris ds la rexion amont par la direction marketing, ceci an 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 nancement, des stratgies de fourniture et dachats tout en intgrant les exigences lgales et rglementaires.
Lapport de valeur Linformatique doit galement pouvoir apporter un gain identiable 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 an didentier 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 defcacit et defcience. Ceci vient complter le processus de pilotage des investissements qui traitera des cots, des bnces 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 an 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 nancier 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 bnces, 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 difcults 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 an 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 : efcacit et efcience des oprations ; abilit des rapports nanciers ; 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 clarier 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 nanciers 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 nanciers 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 : nance, 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
Contrle des cots Rduction des cots ROI / Automatisation Valeur adaptative Management de valeur
Clients et utilisateurs
Niveaux de services (SLA) Conformit aux besoins Exigences rglementaires Respect du budget Niveau de demande
Indicateurs
Budget informatique Benchmarks Performance de lentreprise
Indicateurs
Qualit du service vs SLA Satisfaction des utilisateurs et clients Rclamations
Futur et anticipation
Gestion des comptences Sourcing / Achats Veille technologique Architecture technique Urbanisation
Performances oprationnelles
Approvisionnements Conduite de projets Maintenance des applications Exploitation, Administration Support...
Indicateurs
Influence sur : performances cots niveaux de services
Indicateurs
Performances Benchmarks et tendances Cots standards
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 exibilit 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 certication, les autres ne sont que de simples guides : la norme ISO/IEC 27000 prsente le vocabulaire et les dnitions 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 certication ; 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 certication sur lISO 27001.
La norme ISO/IEC 27001

La norme ISO/IEC 27001, publie en novembre 2005, dnit la politique du management de la scurit des SI au sein dune entreprise. Elle est issue de la spcication BS 7799-2:1999 (Specication for Information Security Management Systems) qui dnit les exigences respecter pour crer un ISMS (Information Security Management System). Elle spcie 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. Dnir une politique de la scurit des informations. Dnir le primtre du systme de management de la scurit de linformation.
14
Raliser une valuation des risques lis la scurit. Grer les risques identis. 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 efcacit 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 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
tablir le SMSI
Plan
Mettre en place et exploiter le SMSI
Do
Act
Maintenir et amliorer le SMSI
Raliser : Lorganisation doit - formaliser et mettre en place un SMSI - mettre en place des actions de mise en uvre du SMSI
Check
Contrler et revoir 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
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.
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, spcie 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 dnition. 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 vrication rpartis en 11 domaines. Politique de scurit.
15
Organisation de la scurit : organisation humaine, implication hirarchique ; notion de propritaire dune information et mode de classication ; valuation des nouvelles informations ; mode daccs aux informations par une tierce partie ; cas de lexternalisation des informations. Classication 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 : dnition 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 dnit 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 certications, 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 certication 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 dnir 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 certier ; PP (Protection Prole) : ensemble type dexigences de scurit pour une catgorie de produits ; ST (Security Target) : niveau de scurit spcique 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 ; authentication, PKI/KMI ; contrle biomtrique ; pare-feu (rewalls) ; 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 certication 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 EAL1 EAL2 EAL3 EAL4 EAL5 EAL6 EAL7 Test fonctionnellement. Test structurellement.
Critre
Test et vri mthodiquement. Conu, test et vri mthodiquement. Conu de faon semi-formelle et test. Conception vrie de faon semi-formelle et teste. 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 certier les objectifs dvaluation (TOE) par rapport aux niveaux dvaluation garantir (EAL). Chaque certication concerne une cible prcise (dsignation du systme ou du primtre concern par la certication). Une telle cible peut tre, par exemple : un systme dexploitation ; un rseau informatique ; une application. La cible est libre, cest le demandeur qui la dnit. Elle peut tre dcrite soit par un constructeur, soit par toute autre organisation (entreprise cliente, pays, administration) qui demande la certication dun produit. Chaque certicat 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 conguration. PP (Protection Profile) Pour guider les concepteurs et les valuateurs, il existe des ensembles de critres prdnis, les prols de protection (on en compte prs de 1 000). Un PP dnit un ensemble dobjectifs et dexigences pour une catgorie de produits. Par exemple, le CELAR (Dlgation gnrale pour larmement, DGA) a rdig un prol pour pare-feu protection leve an 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 certier. 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 nal, cest la DCSSI qui valide lagrment et dlivre le certicat.
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 rete 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 certication ISO/IEC 20000. Le domaine Fourniture des services concerne le moyen terme (planication et amlioration de la fourniture de services) et comprend : la gestion des niveaux de services ; la gestion nancire ; 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 congurations ; 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. Enn, 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 certication 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 certication 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, bnces et difcults, 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 Gestion de la scurit de linformation Budgtisation et comptabilisation des services informatiques
Rapport sur le service
Processus de contrle
Gestion des configurations Gestion des changements
Processus de mise en production

Gestion des mises en production
Processus de gestion des relations Processus de rsolution

Gestion des incidents Gestion des relations commerciales Gestion des fournisseurs
Gestion des problmes
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 defcacit et defcience. Continual Service Improvement propose des guides pour identier 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 certication 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, planication, 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, planication de projet, validation). Chaque domaine de processus contient des objectifs atteindre, ainsi que la description des pratiques auxquelles il sera fait appel (planier 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 certier 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 l 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 qualication 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 dnir 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 dnies. La russite des projets dpend du savoir-faire de quelques personnes cls. Aucune ou mauvaise application des principes du gnie logiciel. Difcult matriser les cots et les dlais. Reproductible Utilisation de mthodes standards pour grer les activits de dveloppement. Le dveloppement est plani et suivi. Lquipe matrise et applique des rgles. Bonne gestion des cots et des dlais. Dni Utilisation des mthodes du gnie logiciel et application des normes. Lefcacit de chaque processus est vrie et les meilleures pratiques sont mises en avant. Processus bien dni 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, quantis, 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 sufsamment 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 certication 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 certis 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 certication 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 an de matriser la chane client-fournisseur en : donnant conance 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 bnques avec les fournisseurs.
24
La certication sappuie une valuation de lorganisation ayant mis en uvre un systme de management selon un primtre dactivit bien identi. 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 xs par la direction. Une caractristique importante de lISO 9001 est son caractre gnrique. Ainsi, cette norme ne spcie aucun processus li un mtier particulier, et il appartient chaque organisation den dnir 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
Personnel Rsultats personnel
Rsultats
Leadership
Politique et stratgie
Processus
Rsultats client
Rsultats Performance Cls
Partenariat & ressources
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 proter 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 certication 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 unier 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 : Planier et Organiser ; Acqurir et Implmenter ; Dlivrer et Supporter ; Surveiller et valuer.
29
La gure 3-1 prsente les diffrents domaines et processus associs.

Cadre de rfrence gnral de CobiT
Objectifs de la gouvernance
Objectifs mtier
Information 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
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
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
Acqurir et Implmenter
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. Enn, 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 (efcacit, efcience, condentialit, intgrit, disponibilit, conformit et abilit). Ces critres correspondent aussi bien au point de vue dun auditeur qu celui du manager :
efcacit : la mesure par laquelle linformation contribue au rsultat des processus mtier par rapport aux objectifs xs ; efcience : la mesure par laquelle linformation contribue au rsultat des processus mtier au meilleur cot ; condentialit : 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 ; abilit : 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, planier, 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 nancire, 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 ns 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 enn, 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 enn 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 afner au cas par cas.
Tableau 3-1 : Exemple de RACI (processus PO1)
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).
ACTIVITS
Lier objectifs mtier et objectifs informatiques. Identier les dpendances critiques et les performances actuelles. Construire un plan informatique stratgique. laborer des plans informatiques tactiques. Analyser les portefeuilles de programmes et grer les portefeuilles de projets et de services.
C C A C
I C C I
A/R R C
R A/R R A
C C I C C C C C C C C C C C C C I R C C I
33
Conformit, audit, risque et scurit I
Responsable dveloppements
Propritaire processus mtier
Responsable administratif
Responsable exploitation
Responsable architecture
Direction mtier
Bureau projet
DSI
DG
DF
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 dnis 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 spcique 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 gure 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 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, dni, 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 spcique 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 xer 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 exibilit 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 spcique 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 dnir un plan de mise en place. Ce plan spciera, 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 spciques des modles de maturit de CobiT. 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.
35
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.
Comment les dcideurs exercent-ils leurs responsabilits?
Board briefings
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

Implementation Guide Control practices Security Baseline Key management practices COBIT Online COBIT Foundation training COBIT implementation workshop
COBIT et VAL IT Control objectives
Assurance Guide Implementation Guide Control Practices
Figure 3-3 : Documents lis CobiT
La gure 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 Brieng 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, dnissent ce quil est ncessaire de faire pour implmenter un contrle de la structure efcient, tout en matrisant les risques, et ce, an de rcolter les gains induits par cette implmentation. Les pratiques de contrle fournissent davantage de dtails quant la nalit de cette implmentation, an dclairer et de rpondre aux besoins du
38
management, des mtiers, des utilisateurs, et enn des parties prenantes. Ces pratiques permettent donc de justier limplmentation et de mettre en uvre des contrles spciques. 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, an de rguler et doptimiser le management des systmes dinformation, tout en amliorant leur performance. Il inclut galement un guide permettant dexpliquer comment employer CobiT an de mettre en uvre la gouvernance de lensemble des activits informatiques, et de dnir 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 ofciels 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 dnit galement les termes et les concepts spciques de la gouvernance des SI, ainsi que les standards en matire de dnition 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 dnit 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 nancier, caractrise par une plus grande responsabilisation des entreprises. La loi Sarbanes-Oxley (2002) fut dailleurs cre an de restaurer la conance des investisseurs dans le march public amricain, affect par les scandales nanciers 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 nanciers. 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 dnis, 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 ofce 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 nancier. Grce la structure prsente dans cette publication, les services nanciers 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 nalit 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. Identier les besoins : tre attentif, obtenir lengagement (soutien) des dcideurs, dnir le champ dapplication, identier les risques ainsi que les ressources et les lments fournir, et prvoir un plan daction. Prvoir une solution : valuer les performances actuelles, identier les zones damlioration possibles et analyser les incohrences. Planier : dnir 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 lefcacit des programmes. Rendre la solution oprationnelle : mettre en place une solution durable et identier 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 : dnir 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 an 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 spciques 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 signie 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 dnition des risques ; des points de contrle ; en complment de la conguration de CobiT 4.1, une conguration mise jour selon la norme ISO/IEC 17799:2005 dnissant 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, an 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 an 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 nalit, 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.
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.
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
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. Enn, 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 an 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 T LI E TE E E T CE EI IT IT IL E NE IT LI TI A TE TC A TE EC IT IL IB I IA MI G RR RM N TO B N IC CI LITE C EN I I E E G N F I O D A F N BIILI T I OR E F ESP F C C O AB I F F N T EF D I N I E I P I FIIA N N F O IN FD S FF O I F O F N C E D C E CO Domaine s
PROCESS US INFO RMATIQUES
Activ its et objec tifs
APPLI CATI ONS
INFO RMATI ON
Process us
INFRAST RUCTURE
ES RC OU SS E R
IQ AT RM FO IN
Figure 3-4 : Le cube CobiT
44
PERSONNES
S UE
Notons dailleurs que lISACA a depuis plus de 10 ans lanc une certication mondiale des auditeurs de systme dinformation (CISA, Certied 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 (gure 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 prgure 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 justier 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
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.
45
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 lefcience, optimiser les investissements et clairer les choix, pour le plus grand bnce 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 certication 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 certication 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 spcique lie la gouvernance des systmes dinformation dune entreprise comme le proposent les normes de systme de management pour la lire 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. Enn, 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 spcicits 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
PARTIE
II
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), an 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, planication 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 (dnir, 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 Dnir un plan informatique stratgique PO2 Dnir larchitecture de linformation PO3 Dterminer lorientation technologique PO4 Dnir 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 PO10 Grer les projets
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 efcacement 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, planie et en cohrence avec les objectifs mtier sur les long et moyen termes. Cette dmarche aboutit la dnition dun plan informatique stratgique.
51
La planication stratgique informatique est ncessairement relie larchitecture dentreprise et son processus de planication 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 defcacit 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 dnir 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 defcience.
GOUVERNANCE SI EXIGENCES METIER RESSOURCES INFORMATIQUES
EFFICACITE ALIGNEMENT STRATEGIQUE APPORT DE VALEUR GESTION DES RISQUES GESTION DES RESSOURCES MESURE DE LA PERFORMANCE EFFICIENCE APPLICATIONS CONFIDENTIALITE INFORMATIONS INTEGRITE DISPONIBILITE INFRASTRUCTURES
CONFORMITE FIABILITE
PERSONNES
Lgende 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, identie 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 Obj. 02
Ragir aux exigences mtier en accord avec la stratgie mtier. Ragir aux exigences de la gouvernance en accord avec les orientations du CA.
Le processus de planication 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 gure 4-2 reprsente les ux internes du processus PO1.
DEFINIR
ANALYSER LENVIRONNEMENT DE LA DSI Stratgies mtier Performance des TI Portefeuilles de programmes
PO1 Dfinir un plan informatique stratgique
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
DEFINIR LE PLAN INFORMATIQUE STRATEGIQUE
CONTROLER
SURVEILLER LES RESULTATS ATTENDUS DES PROGRAMMES ALERTER EN CAS DECART
COMMUNIQUER
FAIRE VALIDER LES PLANS ET LES PORTEFEUILLES
Plans tactiques
DEFINIR LES PLANS INFORMATIQUES TACTIQUES
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 dnition 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 an 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 lefcacit du processus concernent la vrication 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 nalit 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 an 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 dnis.
Les entres-sorties du processus

PO 5, PO9, PO10, DS1, SE 1, SE 4 PO2, PO 3, PO 4, PO5, PO6, PO 8, PO 10, AI1, AI5, AI6, DS1, DS2
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 defcience, dintgrit, defcacit et de condentialit.
GOUVERNANCE SI
EXIGENCES METIER
RESSOURCES INFORMATIQUES
PERSONNES
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 classication de linformation travers un schma valid, prenant en compte la criticit et la sensibilit des donnes (publiques, condentielles, secrtes) par rapport au cur de lactivit, contribue dnir 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 spciques des mtiers.
56
Obj. 01 Obj. 04 Obj. 05 Obj. 11
Ragir aux exigences mtier en accord avec la stratgie mtier. Optimiser lutilisation de linformation. Donner de lagilit linformatique. 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.
PO2 Dfinir larchitecture de linformation
DEFINIR
DEFINIR UN MODELE DINFORMATION DE LENTREPRISE Dictionnaire(s) de donnes ELABORER LE(S) DICTIONNAIRE(S) DES DONNEES
AMELIORER
MAINTENIR A JOUR LE MODELE DINFORMATION, LE(S) DICTIONNAIRE(S) DE DONNEES ET LE SYSTEME DE CLASSIFICATION
DEFINIR UN SYSTEME DE CLASSIFICATION DES DONNEES

IDENTIFIER LA DIMENSION CRITIQUE ET SENSIBLE DES DONNEES
COMMUNIQUER
FACILITER LE DEVELOPPEMENT DAPPLICATIONS FAVORISER LA COMPREHENSION COMMUNE DES DONNEES
Systme de classification
DEFINIR UN SYSTEME DARCHIVAGE ET DE DESTRUCTION DES DONNEES
IDENTIFIER LES PROPRIETAIRES 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 dnit un modle de donnes de lentreprise pour en garantir lintgrit, la condentialit et la cohrence. Il vise btir un dictionnaire des donnes de lentreprise robuste et able. Le travail avec les mtiers conduira en particulier optimiser la classication des donnes et leur affecter un propritaire. En effet, lidentication et la classication 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 defcience seront galement trs affectes.
Mesures et contrles
Les mesures permettant de sassurer de lefcacit du processus portent principalement sur le taux de donnes hors du modle dinformation de lentreprise et sur les carts par rapport aux rgles de classication 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 lidentication et la classication 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 sufsante pour assurer ce rle avec succs.
Le responsable mtier
Au sein de ce processus, chaque mtier a la responsabilit de sassurer que les donnes font bien lobjet dune identication et dune classication, 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 classication 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 PO 3, AI 2, DS1, DS4, DS5, DS11, DS12
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
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 defcacit et defcience des mtiers.
PERSONNES
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 spcicit. Un autre objectif de ce plan dinfrastructure consiste grer les orientations pour offrir une meilleure interoprabilit entre les plates-formes et les applications.
60
Obj. 07 Obj. 15
Acqurir et maintenir fonctionnels des systmes applicatifs intgrs et standardiss. Optimiser linfrastructure, les ressources et les capacits informatiques.
Ce processus concerne principalement la matrise des infrastructures informatiques (matriels et logiciels).
PO3 Dterminer lorientation technologique
DEFINIR
ETUDIER LES TECHNOLOGIES ACTUELLES ET FUTURES DETERMINER LORIENTATION TECHNOLOGIQUE LA PLUS FAVORABLE A LACTIVITE DE LENTREPRISE Plan dinfrastructure technologique DEFINIR LE PLAN DINFRASTRUCTURE TECHNOLOGIQUE
AMELIORER
DEFINIR LUTILISATION FUTURE ET STRATEGIQUE DES NOUVELLES TECHNOLOGIES MAINTENIR A JOUR LE PLAN DINFRASTRUCTURE TECHNOLOGIQUE
COMMUNIQUER
FAIRE VALIDER LE PLAN
PUBLIER LES STANDARDS TECHNIQUES
VEILLER METTRE EN UVRE

Standards techniques METTRE EN PLACE UN FORUM INFORMATIQUE SURVEILLER LES NOUVELLES TECHNOLOGIES METTRE EN PLACE UN COMITE ARCHITECTURE TI SURVEILLER LEVOLUTION DU CADRE REGLEMENTAIRE ET LEGISLATIF SURVEILLER LES TENDANCES DE LENVIRONNEMENT METIER
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 dnition 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 an 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 lefcacit 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 dnition 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

PO1, PO2, AI3, DS3 AI1, AI2, AI3, AI7, DS5, PO5
Plan informatique stratgique Plan informatique tactique 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
An 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 defcacit, les rles et les responsabilits au sein de lorganisation doivent tre bien dnis 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.
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.
63
Vue densemble
Le processus PO4 sintresse lorganisation et aux ressources en personnels an de leur attribuer des fonctions en vue de structurer lorganisation. Il rpond ainsi aux exigences defcacit et defcience 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
PERSONNES
Figure 4-10 : Dnir les processus, lorganisation et les relations de travail : PO4
Pourquoi ?
Le propre dune organisation informatique able 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 clarier 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 efcace 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 dni, sen trouve facilite.
64
Obj. 01 Obj. 02 Obj. 05
Ragir aux exigences mtier en accord avec la stratgie mtier. Ragir aux exigences de la gouvernance en accord avec les orientations du CA. Donner de lagilit linformatique.
Le processus PO4 couvre lensemble des aspects du fonctionnement de lorganisation relatif aux services informatiques.
PO4 Dfinir les processus, lorganisation et les relations de travail
DEFINIR
DEFINIR UN CADRE DE REFERENCE DES PROCESSUS INFORMATIQUES Rfrentiel des processus informatiques POSITIONNER LA FONCTION INFORMATIQUE SELON LIMPORTANCE DES SI DANS LENTREPRISE IDENTIFIER LES PROPRIETAIRES DES DONNEES ET DES SYSTEMES DINFORMATION DEFINIR LES ROLES ET RESPONSABILITES DES SI
COMMUNIQUER
IMPLIQUER LES TI DANS LES PROCESSUS DE DECISION
CONTROLER
EVALUER REGULIEREMENT LES BESOINS EN RESSOURCES SUPERVISER LA MISE EN PRATIQUE DES ROLES ET RESPONSABILITES CONTROLER LES ACTIVITES DES TIERS EXTERNES
CONNAITRE LES ROLES, LES RESPONSABILITES ET LES RELATIONS
Documentation des rles et responsabilits
METTRE EN UVRE
METTRE EN PLACE UN COMITE STRATEGIQUE INFORMATIQUE
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 efcaces 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 efcace et efcient 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 dnition des priorits, la rsolution des conits 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 an 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
An 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 lefcacit de ce processus passe par le suivi du nombre darbitrages effectus pour rsoudre les conits de dcision du fait dune mauvaise ou insufsante 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 dnis.
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 an de mettre en uvre la stratgie informatique dnie par la direction de lentreprise. Il assure le pilotage des investissements informatiques et des activits de service (priorits/arbitrages, rsolution des conits daccs aux ressources). La filire qualit Il sagit de dnir 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 Il sagit de dnir une organisation ddie propre mettre en uvre la politique et les objectifs scurit, en ligne avec lanalyse des risques lis aux systmes dinformation.
Les fonctions
Le directeur des systmes dinformation Son rle est de sassurer de la dnition 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 lire scurit et sassure que le processus DS5 est bien mis en uvre. Le responsable dassurance qualit (RAQ) Il anime la lire 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 Plan informatique stratgique Plan informatique tactique 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 bnces 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 bnces, les priorits budgtaires, est plus que jamais dactualit.
68
Vue densemble
GOU VERNANCE SI EXIGENCES METIER RESSOURCES NFORMATIQUES I
PERSONNES
Lgende
Primaire Secondaire Slectionn
Figure 4-13 : Grer les investissements : PO5
Le processus PO5 sintresse la bonne gestion nancire des ressources en personnels, infrastructures et applications an doptimiser lapport de valeur. Il rpond ainsi aux exigences defcacit et defcience de la DSI vis--vis des mtiers.
Pourquoi ?
An de rendre possible une gestion des investissements informatiques, ltablissement dun rfrentiel de gestion nancire est ncessaire. Des modles de cots doivent tre dnis, lesquels apportent une clarication et aident la validation du budget. Les priorits budgtaires se dclinent ensuite sur les portefeuilles de projets et de services, retant 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 didentier rapidement les carts par rapport au budget et permet dutiliser au mieux les ressources informatiques dans un objectif de rentabilit. La gestion des bnces 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
Obj. 12 Obj. 24 Obj. 28
Sassurer de la transparence et de la bonne comprhension des cots, bnces, stratgies, politiques et niveaux de services des SI. Amliorer la rentabilit de linformatique et sa contribution la protabilit de lentreprise. 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 nanciers relatifs lorganisation informatique.
PO5 Grer les investissements informatiques
DEFINIR
Rapport Cots / Bnfices ANALYSER LA RENTABILITE DES PORTEFEUILLES DINVESTISSEMENTS, DES SERVICES ET DES ACTIFS INFORMATIQUES DEFINIR DES CRITERES DINVESTISSEMENTS (ROI, dure d'amortissement, valeur nette actuelle) DEFINIR DES PRIORITES DANS LATTRIBUTION DES RESSOURCES INFORMATIQUES Budgets DEFINIR UN BUDGET GLOBAL INFORMATIQUE ET DES BUDGETS DE PROGRAMMES INDIVIDUELS
AMELIORER
AMELIORER LA CONTRIBUTION DES SI AUX RESULTATS DE LENTREPRISE 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
COMMUNIQUER
AIDER A ETABLIR DES PRIORITES BUDGETAIRES
FAIRE VALIDER LES BUDGETS
METTRE EN EVIDENCE LES ECARTS
Ecarts Cots / Prvisions
METTRE EN UVRE
METTRE EN PLACE UN REFERENTIEL DE GESTION FINANCIERE POUR LES SI METTRE EN PLACE UN PROCESSUS DE BUDGETISATION ET DE GESTION DES COUTS METTRE EN PLACE UN PROCESSUS DE SURVEILLANCE DES BENEFICES
CONTROLER
COMPARER LES COUTS ET LA VALEUR DES SI PAR RAPPORT AUX PREVISIONS EVALUER LES CONSEQUENCES DES ECARTS SUR LES PROGRAMMES
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 didentier rapidement les carts par rapport au budget et dutiliser au mieux les ressources informatiques dans un objectif de rentabilit. La gestion des bnces 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 n 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 lefcacit du processus portent principalement sur le nombre dcarts par rapport aux prvisions budgtaires et sur le ratio cots/bnces 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 conits daccs aux ressources, etc.). Il est le pilote de ce processus.
71
Le directeur gnral Compte tenu de la nalit 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. Le responsable mtier
Au sein de ce processus, chaque mtier a la responsabilit de sassurer que les dcisions, engagements de budget et arbitrages budgtaires ne se font pas au dtriment de lapport de valeur, et que le rapport cots/bnces 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 justis 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 an de dvelopper une culture de gestion des risques et dalignement stratgique. Il rpond ainsi aux exigences defcacit de la DSI vis--vis des mtiers.
GOU VERNANCE SI
EXIGENCES METIER
PERSONNES
Lgende
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 an de mieux piloter leurs investissements et les services offerts. Donner ce cadre une dimension purement nancire 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 an de coller au plus prs aux proccupations de lentreprise.
Obj. 12 Obj. 13 Obj. 19 Obj. 20 Obj. 21
Sassurer de la transparence et de la bonne comprhension des cots, bnces, stratgies, politiques et niveaux de services des SI. Sassurer dune bonne utilisation et des bonnes performances des applications et des solutions informatiques. Sassurer que l'information critique et condentielle nest pas accessible ceux qui ne doivent pas y accder. 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. Sassurer quun incident ou une modication dans la fourniture dun service informatique na quun impact minimum sur lactivit.
Obj. 22
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
DEFINIR
PO6 Faire connatre les buts et les orientations du management
DEFINIR LES ELEMENTS DUN ENVIRONNEMENT DE CONTROLE
COMMUNIQUER
PROMOUVOIR LAPPORT DE VALEUR DES SI ET LAMELIORATION CONTINUE FAIRE VALIDER LES POLITIQUES INFORMATIQUES EXPLIQUER LES POLITIQUES ET IMPLIQUER LE PERSONNEL FAIRE CONNAITRE LES OBJECTIFS ET LES ORIENTATIONS INFORMATIQUES Politiques informatiques Rfrentiel de contrle
DEVELOPPER ET ACTUALISER DES POLITIQUES INFORMATIQUES
METTRE EN PLACE ET MAINTENIR UN REFERENTIEL DE CONTROLE INFORMATIQUE
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 dnisse 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 an que ces politiques soient dployes et que la communication sappuie sur des actes concrets.
Mesures et contrles
La mesure de lefcacit 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 didentier 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 clarication des objectifs se traduit par la cohsion des quipes. In ne, 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 Portefeuille de services 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 difcile 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 difciles 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, an de sassurer que les quipes seront en mesure de sadapter pour faire face aux volutions technologiques (alignement stratgique) et en faire bncier les mtiers. Il rpond ainsi aux exigences defcacit et defcience de la DSI vis--vis des mtiers.
GOUVERNANCE SI
EXIGENCES METIER
PERSONNES
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 insufsant. Il faudrait associer lensemble de ces personnels externes la gestion des comptences de faon en optimiser lemploi et suivre les performances correspondantes.
Vis--vis des 28 objectifs globaux assigns au systme dinformation (voir annexe 2, Objectifs du systme dinformation et processus CobiT ), le processus PO7 doit permettre datteindre les objectifs prsents dans le tableau 4-7.
OBJ. 05 OBJ. 09
Donner de lagilit linformatique. 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
DEFINIR
PO7 Grer les ressources humaines de linformatique
DEFINIR DES PROCESSUS DE RECRUTEMENT
AMELIORER
TENIR A JOUR LES CONNAISSANCES ET LES COMPETENCES STIMULER LES PERFORMANCES
IDENTIFIER LES COMPETENCES CLES 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
APPLIQUER LES POLITIQUES RH ET LES PROCEDURES PROPRES AUX SI ORGANISER LE TRANSFERT DES CONNAISSANCES ET DES RESPONSABILITES LORS DES MOUVEMENTS DE PERSONNELS
EVALUER LES PERFORMANCES DES EMPLOYES PAR RAPPORT AUX OBJECTIFS INDIVIDUELS
SUPERVISER LES ROLES ET RESPONSABILITES 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 lefcacit de ce processus passe principalement par le suivi du pourcentage de personnes dont le prol couvre la cartographie cible des comptences de la DSI. Dautres indicateurs peuvent complter cette mesure defcacit, par exemple, le suivi de postes cls non pourvus en interne ou de remplaants identis. 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 che de fonction.
Le directeur des systmes dinformation 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 Rles et responsabilits
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 dnir des indicateurs de mesure pour amliorer en permanence la qualit mais aussi faire progresser paralllement le systme de management qualit lui-mme.
Vue densemble
PERSONNES
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 defcacit, defcience, dintgrit et de abilit de la DSI vis--vis des mtiers.
Pourquoi ?
Le processus PO4 dnit 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 difcile dancrer une culture de lamlioration continue, do lide de laligner au processus de management (objectifs individuels). Enn, 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.
OBJ. 16 OBJ. 25
Rduire le nombre de dfauts et de retraitements touchant la fourniture de solutions et de services. 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)
AMELIORER
IDENTIFIER LES ACTIONS CORRECTIVES ET PREVENTIVES AMELIORER LE SGQ
COMMUNIQUER
PO8 Grer la qualit
RESPECTER LES STANDARDS
Standards de qualit, de dveloppement et dacquisition
IDENTIFIER LES STANDARDS INFORMATIQUES ET LES PRATIQUES DE QUALITE IDENTIFIER LES STANDARDS DE DEVELOPPEMENT ET DACQUISITION ETABLIR UN PLAN GENERAL QUALITE
PROMOUVOIR LAMELIORATION CONTINUE
Plan gnral qualit
CONTROLER METTRE EN UVRE

METTRE EN PLACE ET ACTUALISER LE SGQ ALIGNER LES STANDARDS ET LES PRATIQUES SUR LES BESOINS CLIENTS EVALUER LA VALEUR APPORTEE PAR LA QUALITE SURVEILLER LES PERFORMANCES VIS-A-VIS DES STANDARDS ET PRATIQUES DE QUALITE SURVEILLER EN PERMANENCE LA CONFORMITE AU SGQ
82

La mise en uvre du processus consiste, sur la base dune politique qualit en phase avec la stratgie SI dicte par le DSI, dnir 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 dnis. 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 dnition du SMQ.
Mesures et contrles
La mesure de lefcacit 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 defcacit, 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.
Le directeur des systmes dinformation Son rle est de dnir 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 lire 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
Plan informatique stratgique Plans dtaills des projets Plans dactions correctives
Standards dacquisition Standards de dveloppement Exigences de standards de qualit et de mtriques Actions pour lamlioration de la qualit
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) an de dvelopper une culture de gestion des risques. Il rpond ainsi aux exigences de condentialit, dintgrit et de disponibilit du SI vis--vis des mtiers.
PERSONNES
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 prolent et leur impact au niveau des mtiers. Ceci ncessite une parfaite comprhension des dimensions mtier et de la technologie an danticiper et proposer les mesures de rduction de risques les plus appropries.
85
OBJ. 14 OBJ. 17 OBJ. 18
Protger tous les actifs1 informatiques et en tre comptable. Protger latteinte des objectifs informatiques. 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 nanciers. Il est le lien entre le management global des risques au niveau de lentreprise et la DSI.
DEFINIR
P09 Evaluer et grer les risques
COMMUNIQUER
DEVELOPPER LAPPETENCE POUR LE RISQUE Guide de gestion des risques
DETERMINER LALIGNEMENT POUR LA GESTION DES RISQUES
AMELIORER
DEFINIR LES PRATIQUES DE GESTION DES RISQUES ET DE CONTROLE PLANIFIER LES ACTIVITES DE CONTROLE SELON LES PRIORITES TENIR A JOUR ET SURVEILLER UN PLAN DACTIONS DE TRAITEMENT DES RISQUES
FAIRE APPROUVER LES PLANS DACTIONS
Plan dactions
METTRE EN UVRE
IDENTIFIER LES EVENEMENTS IMPACTANT LES OBJECTIFS METIER ET INFORMATIQUES IDENTIFIER LE PROPRIETAIRE DU RISQUE ET LES PROPRIETAIRES DES PROCESSUS CONCERNES EVALUER LES REPONSES AUX RISQUES ETABLIR LE CONTEXTE DE CHAQUE EVALUATION DE RISQUE
EVALUER
EVALUER LES RISQUES ASSOCIES AUX EVENEMENTS
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 dnition et la mise en uvre dune mthodologie dvaluation des risques, llaboration dun plan de traitement des risques adapt aux prjudices nanciers encourus. Beaucoup de risques gnriques seront traits travers les PRA et PCA mais il existera toujours des alas qui feront merger des risques plus spciques, non prvus a priori. Citons, par exemple, la perte de comptence stratgique suite au dpart de certaines ressources, les impacts dun projet spcique, 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 lefcacit 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 identis. 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 suft 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 nancire.
La lire scurit et les risques informatiques Il sagit de dnir une organisation ddie propre mettre en uvre la politique et les objectifs scurit et de gestion des risques informatiques en ligne avec lanalyse des risques lis aux systmes dinformation.
87
Le directeur des systmes dinformation 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 nanciers encourus, et den assurer le nancement 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 informatique stratgique Plan informatique tactique Portefeuille de services 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 inefcace 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 spcicit 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 defcacit et defcience du SI vis--vis des mtiers.
GOUVERNANCE SI EXIGENCES METIER RESSOURCES INFORMA TIQUES
PERSONNES
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
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.
89
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 safnera au l des tapes, dun cadre technique valid trs tt par lexploitation et, enn, 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.
OBJ. 01 OBJ. 02 OBJ. 25
Rpondre aux exigences mtier en accord avec la stratgie mtier. Rpondre aux exigences de la gouvernance en accord avec les orientations du CA. 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 signicatifs 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 dnis, mis en uvre et rgulirement amliors pour conduire les projets. Le quoi se rapporte plus spciquement aux projets et leur management oprationnel. Les prrequis du processus PO10 sont ainsi la fois dordre stratgique (quel portefeuille de projets ?), nancier (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 xer aux projets un cadre prcis permettant den optimiser les chances de succs.
DEFINIR
DEFINIR UN CADRE DE GESTION DE PROGRAMME
DEFINIR LES PROJETS DONT LES OBJECTIFS SERVENT UN PROGRAMME
Portefeuille projets
COMMUNIQUER
IMPLIQUER LES PARTIES PRENANTES AUX PROJETS INFORMATIQUES
AMELIORER
PRODUIRE UN RETOUR DEXPERIENCE SUIVRE LES ACTIONS CORRECTIVES
PO10 Grer les projets
PLANIFIER CHAQUE PROJET SELON LEUR PRIORITE ET LEUR CODEPENDANCE
DEFINIR UN CADRE DE GESTION DES PROJETS

DEFINIR LE PERIMETRE DE GESTION DE PROJET DEFINIR UNE METHODOLOGIE DE GESTION DE PROJET IDENTIFIER LA STRUCTURE DE GOUVERNANCE DES PROJETS
Guides de gestion
RAPPORTER LES RESULTATS AUX PARTIES PRENANTES
CONTROLER
ASSURER UN CONTROLE DU PROJET ET DES CHANGEMENTS APPORTES Rapport Performance
MESURER LA PERFORMANCE DU PROJET VERIFIER LA FOURNITURE DES RESULTATS ET BENEFICES PREVUS EVALUER LES CONSEQUENCES DUN ECART SUR LE PROJET ET SUR LE PROGRAMME
METTRE EN UVRE
DEFINIR LES PROJETS INFORMATIQUES
DEFINIR LE PERIMETRE DES PROJETS DEFINIR DES PLANS DE PROJETS (planning, plan qualit, gestion des risques et des changements, etc.) DEFINIR LES ROLES ET RESPONSABILITES DES EQUIPES PROJET
Plans projets
METTRE EN PLACE UN SYSTEME DE SURVEILLANCE ET DE MESURE
GERER LACHAT DE PRODUITS ET DE SERVICES INFORMATIQUES GERER LES RISQUES ET LES CHANGEMENTS
91

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 dnir le cadre de gestion des programmes et des projets. Ce processus renvoie la fonction de Project Management Ofcer (PMO) qui en est le responsable naturel au travers dune structure ad hoc (ofce des projets). Le schma du processus de la gure 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 lefcacit 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.
Le directeur des systmes dinformation Son rle est de sassurer quun rfrentiel de gestion des projets et des programmes est bien dni 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 dni. 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, PO7 , PO8, AI7 PO1, PO5, PO8, PO9, AI1, AI2, AI3, AI4, AI5, AI6, AI7 , DS6, SE1
PO10 : Grer les projets
Portefeuille des projets Tableau des comptences informatiques Standards de dveloppement Revue post-dmarrage
Rapports sur la performance des projets Plan de gestion des risques des projets Guide de gestion des projets Plans de projets dtaills Portefeuille de projets
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 lidentication, du dveloppement ou de lacquisition des solutions informatiques, de leur mise en uvre et de leur intgration aux processus mtier, ainsi que de la modication et de la maintenance des systmes existants. Les processus de ce domaine sont les suivants : 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 modications
AI1
Trouver des solutions informatiques
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 signicative ? 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/bnces des solutions envisages) dterminent le choix nal. Celui-ci, guid par des critres defcacit 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
PERSONNES
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 defcacit 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 lefcacit recherche par le mtier, lefcience propre tout bon gestionnaire et une matrise des risques adapte.
Pourquoi ?
Il sagit de traduire les besoins fonctionnels de lentreprise en solutions informatiques efcaces et efcientes. 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.
Vis--vis des 28 objectifs globaux assigns au systme dinformation (voir annexe 2, Objectifs du systme dinformation et processus CobiT ), le 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
Ragir aux exigences mtier en accord avec la stratgie mtier. Dterminer comment traduire les exigences mtier de fonctionnement et de contrle en solutions automatises efcaces et efcientes.
Le processus AI1 couvre les tapes de dnition et de prise en compte dun besoin jusqu la dcision nale qui aboutit un achat ou un dveloppement informatique.
La gure 5-2 reprsente les ux internes du processus AI1.
AI1 Trouver des solutions informatiques
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 Etude de faisabilit
CONTROLER
EVALUER LES BENEFICES INFORMATIQUES DES SOLUTIONS PROPOSEES 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
EVALUER LES ALTERNATIVES POSSIBLES
Figure 5-2 : Reprsentation schmatique des ux internes du processus AI1
97

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 identies avant tout dveloppement ou acquisition. Le choix de la solution dnitive est dict par des critres de rentabilit, defcacit, de compatibilit, dergonomie, de disponibilit, de continuit et dvolutivit, et galement de scurit. En effet, lanalyse des risques, dment documente, permet didentier 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
Les mtriques mettre en place pour sassurer de lefcacit du processus concernent la vrication 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/bnces, la pertinence des tudes ralises en amont par rapport aux rsultats aprs dploiement (ROI en particulier), lcart entre les spcications initiales et les changements demands en cours de projet. La mesure de la mise en uvre de ce processus passe principalement par le suivi du nombre dtudes de faisabilit et danalyse de risques ralises. Plus gnralement, on vriera dans quelle mesure le processus de dcision global est respect.
Le responsable mtier et le propritaire du processus mtier
Au sein de ce processus, chaque mtier a la responsabilit de sassurer que ses exigences mtier, les risques et la faisabilit ont bien t tudis, et que les bnces des solutions proposes ont bien t valus an de pouvoir approuver la meilleure solution.
98
Lofce des projets (PMO) Le PMO met en uvre ce processus an didentier 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. Le directeur des systmes dinformation 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 an que les bnces 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 an 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 dnition du besoin, la traduction des exigences en spcications 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 conguration 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
PERSONNES
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 defcacit et defcience du systme dinformation.
Pourquoi ?
Les oublis ou les dfauts majeurs commis lors des tapes de conception peuvent savrer prjudiciables et difcilement 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.
OBJ. 06 OBJ. 07
Dterminer comment traduire les exigences mtier de fonctionnement et de contrle en solutions automatises efcaces et efcientes. 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 dnition 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 modications de ce chapitre), qui traite des tests et de la mise en production des applications ainsi que de leurs volutions.
Spcifications de conception gnrales
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.)
AI2 Acqurir des applications et en assurer la maintenance
Spcifications de conception dtailles
COMMUNIQUER
FAIRE APPROUVER LES SPECIFICATIONS
Spcifications des contrles de scurit
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
VALIDER CHAQUE ETAPE CLE DU DEVELOPPEMENT
METTRE EN UVRE
ADAPTER ET IMPLEMENTER LES APPLICATIONS ACQUISES 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 spcications 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 an de livrer au nal une application qui satisfait aux conditions de rentabilit. Paralllement, le plan dassurance qualit des logiciels ayant pour objet de spcier les critres de qualit et les processus de validation et de vrication, 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 conguration 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 condentialit 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
Les mtriques mettre en place pour sassurer de lefcacit du processus 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 bnces apports dans le mtier. La mesure de la mise en uvre de ce processus passe principalement par le suivi du plan dassurance qualit de chaque projet applicatif.
Lofce des projets (PMO) Il sassure du bon droulement du projet en laborant le plan dassurance qualit, conformment aux exigences auxquelles sont soumis les projets applicatifs et en vriant 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 Standards dacquisition et de dveloppement Guides de gestion des pr ojets Plans de projets dtaills Etude de faisabilit des exigences 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 et en assurer la maintenance
Parmi les postes de dpenses informatiques les plus importants gurent 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 planication 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 defcience du systme dinformation.
PERSONNES
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.
OBJ. 05 OBJ. 08 OBJ. 15
Donner de lagilit linformatique. Acqurir et maintenir oprationnelle une infrastructure informatique intgre et standardise. Optimiser linfrastructure, les ressources et les capacits informatiques.
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.
DEFINIR
AI3 Acqurir une infrastructure technique et en assurer la maintenance
DEFINIR UN PLAN DACQUISITION DES TECHNOLOGIES
DEFINIR LES MESURES DE CONTROLE ET DE SECURITE
AMELIORER
Exigences de lenvironnement physique Exigences de surveillance des systmes REVISER PERIODIQUEMENT LINFRASTRUCTURE EN FONCTION DES EXIGENCES METIER ET DE SECURITE
CONTROLER
SUIVRE ET EVALUER LUTILISATION DES COMPOSANTS DE LINFRASTRUCTURE SELON LEUR SENSIBILITE
METTRE EN UVRE
NEGOCIER LACQUISITION DE LINFRASTRUCTURE AUPRES DE FOURNISSEURS AGREES 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 CONTROLER LES MODIFICATIONS CONFORMEMENT A LA PROCEDURE DE GESTION DES CHANGEMENTS

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 an de protger la condentialit 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 an de dtecter des erreurs et des problmes avant la mise en production.
106
Mesures et contrles
Les mtriques mettre en place pour sassurer de lefcacit du processus 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.

PO3, PO8, PO10, AI1, 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 Plans de projets dtaills Etude de faisabilit des exigences des mtiers Description du processus de changement Plan performance et capacit (exigences)
Dcisions dacquisition 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). An 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
PERSONNES
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 defcacit et defcience 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 sufsamment 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.
OBJ. 03 OBJ. 11 OBJ. 13 OBJ. 16
Sassurer de la satisfaction des utilisateurs naux lgard des offres et des niveaux de services. Sassurer de lintgration progressive des solutions informatiques aux processus mtier. Sassurer dune bonne utilisation et des bonnes performances des applications et des solutions informatiques. 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
AI4 Faciliter le fonctionnement et lutilisation
DEFINIR
DEFINIR UNE STRATEGIE POUR RENDRE LA SOLUTION EXPLOITABLE PLANIFIER LA PRODUCTION DE LA DOCUMENTATION
AMELIORER
AMELIORER LA DOCUMENTATION SI NECESSAIRE
COMMUNIQUER
COMMUNIQUER AUX UTILISATEURS FINAUX Manuels de procdures
DEFINIR UNE METHODOLOGIE DE TRANSFERT DES CONNAISSANCES
CONTROLER
EVALUER LES RESULTATS DE LA FORMATION VERIFIER LA DISPONIBILITE, LEXHAUSTIVITE ET LEXACTITUDE DE LA DOCUMENTATION
COMMUNIQUER AU PERSONNEL DU SUPPORT ET AU PERSONNEL DEXPLOITATION
Manuels dexploitation, dassistance technique et dadministration
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 naux pour les rendre au plus vite oprationnels et pour optimiser leur efcacit. 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 efcace 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
Les mtriques mettre en place pour sassurer de lefcacit du processus 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 lefcacit et lefcience facilement (nombre dincidents, nombre dappels dutilisateurs insufsamment forms, etc.). La mesure de la mise en uvre de ce processus passe principalement par 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
Principes gnraux de gestion des projets Plans dtaills des projets Etude de faisabilit des exigences 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 dni et appliqu an 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 xe les conditions dacquisition des ressources. Lobjectif est de dnir 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
PERSONNES
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 defcacit et defcience 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 efcace 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 nale 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.
OBJ. 07 OBJ. 08 OBJ. 09 OBJ. 24
Acqurir et maintenir fonctionnels des systmes applicatifs intgrs et standardiss. Acqurir et maintenir oprationnelle une infrastructure informatique intgre et standardise. Se procurer et conserver les comptences ncessaires la mise en uvre de la stratgie informatique. Amliorer la rentabilit de linformatique et sa contribution la protabilit de lentreprise.
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
AI5 Acqurir des ressources informatiques
DEFINIR
DEFINIR DES PROCEDURES ET DES STANDARDS DACQUISITION DEFINIR UNE PROCEDURE DE GESTION DES CONTRATS FOURNISSEURS
Exigences de gestion des relations avec les tiers
CONTROLER
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
EVALUER ET SELECTIONNER LES FOURNISSEURS
Accords contractuels dacquisition
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 spcications 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 nale 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 nanciers 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, nancires et civiles, la proprit intellectuelle, les licences, la scurit, les conditions de rsiliation du contrat, les garanties, les pnalits et les mcanismes dvolution qui inuencent 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 dnir 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 efcace des incidents.
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.
Mesures et contrles
Les mtriques mettre en place pour sassurer de lefcacit du processus AI5 concernent le suivi du pourcentage dachats conformes aux procdures et aux politiques dacquisition. La mesure de la mise en uvre de ce processus passe principalement par 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
avec lacheteur, chacun avec sa spcialit, en fonction des domaines concerns.

PO1, PO8, PO10, AI1, AI2, AI3, DS2
DS2, AI7
AI5 : Acqurir des ressources informatiques
Stratgie dachats informatiques Standards dacquisition Principes gnraux de gestion des projets Plans dtaills des projets Etude de faisabilit des exigences des mtiers Dcisions dacquisition 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 conguration (voir chapitre 6, section DS9 Grer la conguration ). Tout changement incluant procdures, processus, paramtres systmes et services doit tre enregistr dans un chier. 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 defcacit, defcience, de disponibilit et dintgrit du systme dinformation.
GOUVERNANCE SI
EXIGENCES METIER
PERSONNES
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 efcace et transparent.
Vis--vis des 28 objectifs globaux assigns au systme dinformation (voir annexe 2, Objectifs du systme dinformation et processus CobiT ), le
117
processus AI6 doit permettre de matriser les objectifs prsents dans le tableau 5-6.
OBJ. 01 OBJ. 06 OBJ. 16 OBJ. 22 OBJ. 26
Ragir aux exigences mtier en accord avec la stratgie mtier. Dterminer comment traduire les exigences mtier de fonctionnement et de contrle en solutions automatises efcaces et efcientes. Rduire le nombre de dfauts et de retraitements touchant la fourniture de solutions et de services. Sassurer quun incident ou une modication dans la fourniture dun service informatique na quun impact minimum sur lactivit. 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 planis en accord avec les exigences mtier que les corrections apporter dans lurgence.
DEFINIR
AI6 Grer les changements
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
OBTENIR LAUTORISATION DE MISE EN UVRE
METTRE EN UVRE
ENREGISTRER LES DEMANDES DE CHANGEMENTS EVALUER LIMPACT DES CHANGEMENTS SUR LE SYSTEME EN EXPLOITATION CLASSER LES DEMANDES DE CHANGEMENTS PAR PRIORITE APPLIQUER LES CHANGEMENTS AUTORISES A LINFRASTRUCTURE ET AUX APPLICATIONS
CONTROLER
SASSURER QUE TOUTE MODIFICATION EST EVALUEE ET AUTORISEE SUIVRE LES CHANGEMENTS ET VERIFIER LEUR CLOTURE
FAIRE CONNAITRE LES MODIFICATIONS APPORTEES
118

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 (planication rigoureuse, procdures strictes) et appliquer des standards. An 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 planication des changements, il est conseill de mettre en place galement un processus des changements dans lurgence (patchs, correctifs) an 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 dnies. 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
Les mtriques mettre en place pour sassurer de lefcacit du processus concernent le suivi du pourcentage de changements qui ont gnr des incidents. La mesure de la mise en uvre de ce processus passe principalement par le suivi des changements ne respectant pas le circuit formel.
119
Le directeur des systmes dinformation 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 ux de nouveauts en production. Le responsable exploitation
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.
Le responsable dveloppements 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 Principes gnraux de gestion des projets Plans de projets dtaills Changements demands Changements de scurit demands Demande de service /demande de changement Historique des problmes
Description du processus de changement Rapport sur le statut des changements Autorisation de changement
120
AI7
Installer et valider des solutions et des modifications
Cest aprs une dcision dnitive que tout nouveau systme peut tre lgitimement mis en exploitation. Derrire cette dcision lourde de consquence, se cache un ensemble de tches importantes, planies 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
PERSONNES
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 an de bien rpondre aux attentes des mtiers (apport de valeur) en respectant principalement le critre defcacit 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 dnir et de piloter ce processus, ce qui permettra de suivre la qualit de la n 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 modications effectues entre deux versions et des solutions de remplacement ou de retour en arrire.
OBJ. 01 OBJ. 11 OBJ. 13 OBJ. 16 OBJ. 20 OBJ. 21
Ragir aux exigences mtier en accord avec la stratgie mtier. Sassurer de lintgration progressive des solutions informatiques aux processus mtier. Sassurer dune bonne utilisation et des bonnes performances des applications et des solutions informatiques. Rduire le nombre de dfauts et de retraitements touchant la fourniture de solutions et de services. 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.
Le processus AI7 complte les tapes de conception et de dveloppement dnies dans le processus AI2. Laccent est surtout mis sur les aspects de tests, de prparation et de validation de la mise en production.
122
Plan dimplmentation
DEFINIR
CONCEVOIR UN PLAN DIMPLEMENTATION DEFINIR UNE STRATEGIE DE TESTS DETERMINER LALIGNEMENT POUR LA GESTION DES RISQUE S ET UNE METHODOLOGIE DE PROGRAMME DE TEST S
AI7 Installer et valider les solutions et les modifications
COMMUNIQUER
OBTENIR LAPPROBATION DES PARTIES CONCERNEES
Programme de tests
CONTROLER
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 an 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 modications et de recette dnitive, 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
Les mtriques mettre en place pour sassurer de lefcacit du processus concernent le suivi du pourcentage dincidents qui ont suivi la validation des solutions installes ainsi que la satisfaction des mtiers. On sattachera aussi identier les causes des carts (jeu de test inadquat, changement de spcication, donnes inexactes). La mesure de la mise en uvre de ce processus passe principalement par 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).
Le propritaire du processus mtier
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 insufsamment teste ou incomplte fonctionnellement.

Il doit vrier 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
Le responsable dveloppements Il est en charge de la spcication des tests et de leur ralisation, en particulier en ce qui concerne les tests applicatifs.

PO3, PO4, PO8, PO10, AI3, AI4, AI5, AI6 PO2, PO5, PO10, AI4, 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 Plans de projets dtaills Systme configur tester / installer Manuel utilisateur, dexploitation, dassistance, technique et dadministration Articles achets Autorisation de changement
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 gure 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. Les processus de ce domaine sont les suivants : DS1 Dnir 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 Identier et imputer les cots DS7 Instruire et former les utilisateurs DS8 Grer le service dassistance aux clients et les incidents DS9 Grer la conguration DS10 Grer les problmes DS11 Grer les donnes DS12 Grer lenvironnement physique DS13 Grer lexploitation
DS1
Dfinir et grer les niveaux de services
Le premier processus du domaine Dlivrer et Supporter (DS) concerne la relation avec les bnciaires des services. Limportance donne ce processus, au moins dans lnumration, rete 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
dnissant en particulier les engagements souscrits, lequel servira en mesurer la qualit et lefcience. 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 qualier 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 INFORMA TIQUES
PERSONNES
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 lefcacit et lefcience.
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. Enn, 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.
Vis--vis des 28 objectifs globaux assigns au systme dinformation (voir annexe 2, Objectifs du systme dinformation et processus CobiT ), le 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 OBJ. 12
Ragir aux exigences mtier en accord avec la stratgie mtier. Sassurer de la satisfaction des utilisateurs naux lgard des offres et des niveaux de services. 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 gure 6-2 reprsente les ux internes du processus DS1.
DS1 Dfinir et grer les niveaux de services
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.)
AMELIORER
CRER UN PLAN DAMELIORATION DES SERVICES INFORMATIQUES
RENDRE COMPTE AUX PARTIES PRENANTES DES NIVEAUX DE SERVICES ATTEINTS
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 dnitive, 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 an 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 abilit des composants (nombre de coupure des tlcommunications par jour) ou des statistiques prleves sur les mainframes (temps de rponse). La principale difcult 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 nal de se concentrer sur des objectifs mtier (KGI) et la DSI de les dcliner en objectifs techniques (KPI). 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 directeur des systmes dinformation 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
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, PO2, PO5, AI2, AI3, DS4, SE1 PO1, AI1, DS2, DS3, DS4, DS5, DS6, DS8, DS11, DS13, SE1
DS1 : Dfinir et grer les niveaux de services
Plans informatiques stratgiques et tactiques Portefeuille de projets 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 lefcacit et lefcience. 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 defcacit et defcience.
GOUVERNANCE SI
EXIGENCES METIER
PERSONNES
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 an 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.
133
OBJ. 03 OBJ. 10 OBJ. 12
Sassurer de la satisfaction des utilisateurs naux lgard des offres et des niveaux de services. Sassurer de la satisfaction rciproque dans les relations avec les tiers. 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 nit 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)
DS2 Grer les services tiers
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 planication et la mise en uvre du processus DS2 part dune identication 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 cons 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 nal, 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 bnces 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 dnir, 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 con 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 Standards dacquisition Clauses contractuelles Exigences de la gestion des relations avec les tiers Compte rendu de revues de contrats Contrats de services (CS) Exigences de services en cas de sinistres, y compris les rles et responsabilits
Rapports sur la performance des 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
PERSONNES
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 defcacit, defcience 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 planier au mieux les volutions dans le souci constant dapporter la meilleure rponse (qualit et prix) aux exigences mtier.
OBJ. 01 OBJ. 15 OBJ. 23
Ragir aux exigences mtier en accord avec la stratgie mtier. Optimiser linfrastructure, les ressources et les capacits informatiques. 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 lefcacit et de la pertinence des mesures prises pour garantir la disponibilit du systme (procdures de secours et de plans durgence). Enn, 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 (Conguration 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).
Le responsable exploitation Il doit sassurer en permanence que les performances et les capacits informatiques, actuelles et futures, permettent de respecter les engagements pris.
139

AI2, AI3, DS1 PO2, PO3, PO5, AI1, AI3, AI6, SE1
DS3 : Grer la performance et la capacit
Spcifications de disponibilit, continuit et reprise Exigences de surveillance des systmes Contrats de services (CS)
Information sur la performance et la capacit Plan de performance et capacit (exigences) Changements requis Rapports sur la performance des processus
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
PERSONNES
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 efcacit et intgrit du systme.
Pourquoi ?
Assurer un service continu signie 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.
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. Sassurer quun incident ou une modication dans la fourniture dun service informatique na quun impact minimum sur lactivit. Sassurer que les services informatiques sont disponibles dans les conditions requises.
OBJ. 22 OBJ. 23
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
DETERMINER LA CAPACITE DE RESISTANCE DES SI ET LE DEVELOPPEMENT DES PLANS DE SECOURS DETERMINER LES RESSOURCES CRITIQUES ET LES EXIGENCES DE DISPONIBILITE
AMELIORER
ETABLIR LES PLANS DACTIONS SELON LES RESULTATS DES TESTS DU PLAN
DS4 Assurer un service continu
CONDUIRE DES REVUES APRES REDEMARRAGE

DETERMINER LES PRINCIPES DE SAUVEGARDE ET DE RESTAURATION
COMMUNIQUER
FAIRE COMPRENDRE AU METIER LES DELAIS ET LES COUTS DE RESTAURATION
MAINTENIR A JOUR LE PLAN DE CONTINUITE
METTRE EN UVRE
DEVELOPPER DES PLANS DE CONTINUITE DES SI
CONTROLER
DEVELOPPER DES PROCEDURES DE CONTROLE DES CHANGEMENTS TESTER REGULIEREMENT LE PLAN DE CONTINUITE
FORMER LES PARTIES CONCERNEES A LA CONTINUITE DES SI DIFFUSER LE PLAN DE CONTINUITE DES SI EN TEMPS ET LIEU OPPORTUNS 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 dnir 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 spciques 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 difcile 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 efcace 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.
Le responsable exploitation Il est en charge, en concertation avec les autres responsables de la DSI (responsable dveloppements, responsable administratif des SI, responsable de lofce 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
Classifications attribues aux donnes Evaluation des risques Spcifications de disponibilit, continuit et reprise Manuels utilisateur, dexploitation, dassistance, technique et dadministration Contrats de services (CS) Contrats dexploitation (CE)
Rsultats des tests de secours Elments de configuration informatique critiques Plan de stockage et de protection hors site Seuils incidents/sinistres Exigences de services en cas de sinistres, y compris les rles et responsabilits Rapports sur la performance des 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
PERSONNES
Figure 6-13 : Assurer la scurit des systmes : DS5
Les exigences mtier sont particulirement explicites avec en priorit les exigences de condentialit et dintgrit, mais aussi les exigences de disponibilit, de conformit et de abilit. CobiT donne l toute sa puissance en offrant ainsi une nesse 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 OBJ. 19 OBJ. 20 OBJ. 21
Protger tous les actifs informatiques et en tre comptable. Sassurer que l'information critique et condentielle nest pas accessible ceux qui ne doivent pas y accder. 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. Maintenir lintgrit de linformation et de linfrastructure de traitement.
OBJ. 26
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
DS5 Assurer la scurit des systmes
COMMUNIQUER
COMMUNIQUER AUX PARTIES PRENANTES ET AUX UTILISATEURS
DEFINIR UN PLAN DE SECURITE INFORMATIQUE GENERAL (exigences mtier, risques informatiques, culture de la scurit, etc.) 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 VALIDER ET TESTER PERIODIQUEMENT LE MAINTIEN A NIVEAU DE LA SECURITE INFORMATIQUE
SENSIBILISER A LA SECURITE PAR LA FORMATION (DS7)
METTRE EN UVRE
COMMUNIQUER A LA GESTION DES INCIDENTS (DS8) METTRE EN PLACE UN PROCESSUS DE GESTION DES IDENTITES ET DES COMPTES UTILISATEUR 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 EVALUER REGULIEREMENT LA VULNERABILITE DES SI (mesures de prvention, dtection, neutralisation)

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 fortication sil suft 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 condentialit 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. Enn, une hirarchie des incidents de scurit peut tre tablie et communique, en particulier au centre de services, pour que la dtection dincidents (processus DS8) identie immdiatement les alertes de scurit.
Mesures et contrles
La mise en place dun tableau de bord de la scurit sappuie sur la classication 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. Enn, 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 directeur des systmes dinformation 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. Le propritaire du processus mtier
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
Architecture de linformation Classifications attribues aux donnes Standards informatiques Evaluation des risques Spcifications de contrles de scurit des applications Contrats dexploitation (CE)
Dfinition des incidents de scurit Exigences de formations spcifiques la sensibilisation la scurit Rapports sur la performance des processus Modifications de scurit requises Menaces et vulnrabilits de scurit Plan et politiques de scurit informatique
S6
Identifier et imputer les cots
Il peut paratre lmentaire de songer identier 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 efciente sans une identication claire des cots. Cette gestion sapplique lensemble des ressources informatiques. Aprs identication claire et prcise des cots (abilit 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 lefcience de lutilisation des ressources.
PERSONNES
Figure 6-16 : Identier et imputer les cots : DS6
Pourquoi ?
Lexprience montre que le processus didentication 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
processus DS6 doit permettre de matriser les objectifs prsents dans le tableau 6-6.
OBJ. 12 OBJ. 24 OBJ. 28
Sassurer de la transparence et de la bonne comprhension des cots, bnces, stratgie, politiques et niveaux de services des SI. Amliorer la rentabilit de linformatique et sa contribution la protabilit de lentreprise. 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 identication 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.
DS6 Identifier et imputer les cots
COMMUNIQUER
IMPLIQUER LES METIERS DANS LA DEFINITION DU MODELE DES COUTS
DEFINIR
FOURNIR UNE DEFINITION EQUITABLE DES COUTS CORRESPONDANTS AUX SERVICES INFORMATIQUES Modle de cots
AMELIORER
AMELIORER LA RENTABILITE GRACE A UNE UTILISATION DOCUMENTEE ET COMPRISE DES SERVICES INFORMATIQUES
DEFINIR UN MODELE DE COUTS (cots directs et indirects, frais gnraux, etc.)
FAIRE COMPRENDRE AUX METIERS LES NIVEAUX DE FACTURATION DES SERVICES
DEFINIR DES PROCEDURES DE FACTURATION DES SERVICES INFORMATIQUES

ETABLIR UNE CORRESPONDANCE ENTRE LES SERVICES INFORMATIQUES ET LES PROCESSUS METIER CALCULER ET AFFECTER LES COUTS REELS DES SERVICES INFORMATIQUES REALISER DES REVUES ET DES TESTS COMPARATIFS DU MODELE DE COUTS ET DE REFACTURATION ANALYSER ET RENDRE COMPTE DES ECARTS ENTRE LES PREVISIONS ET LES COUTS REELS
RENDRE COMPTE EN TOUTE TRANSPARENCE AUX UTILISATEURS DES SERVICES
150

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. Lidentication 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 sufsante. Pour passer une identication, 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 nal dans la mesure o la transparence et limputation permettent dj une communication prcise.
Mesures et contrles
La capacit identier 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 nalises.
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 liales). 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 con la direction administrative et nancire.
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
Documentation sur les propritaires de systmes Rapports cots/bnfices Budgets informatiques Plans de projets dtaills Contrats de services (CS) Contrats dexploitation (CE)
Donnes financires informatiques Rapports sur la performance des processus
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 efcace 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 lefcacit et de lefcience du SI rside dans la capacit des utilisateurs en tirer le maximum de bnces 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.
PERSONNES
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 bnce.
153
OBJ. 03 OBJ. 13 OBJ. 15
Sassurer de la satisfaction des utilisateurs naux lgard des offres et des niveaux de services. Sassurer dune bonne utilisation et des bonnes performances des applications et des solutions informatiques. Optimiser linfrastructure, les ressources et les capacits informatiques.
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 dnis, 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 prot du systme dinformation.
DS7 Instruire et former les utilisateurs
DEFINIR
IDENTIFIER ET DEFINIR LES BESOINS EN SAVOIR ET EN FORMATION DES UTILISATEURS
AMELIORER
METTRE A JOUR LE PROGRAMME DE FORMATION SELON LES RESULTATS DES EVALUATIONS
METTRE EN UVRE
CONSTRUIRE UN PROGRAMME DE FORMATION ADAPTE A CHAQUE GROUPE CIBLE ORGANISER LES ACTIVITES DE FORMATION ET DENSEIGNEMENT IDENTIFIER LES MEILLEURS OUTILS ET METHODES POUR DISPENSER LA FORMATION
EVALUER
EVALUER ET RENDRE COMPTE DE LEFFICACITE DE 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 vrier 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 identier 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 justi, par des changements.
Le directeur des systmes dinformation 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 planication et leur dploiement.
Le propritaire du processus mtier

Il intervient pour lidentication des besoins en savoir et formation en fonction des comptences des utilisateurs, puis pour la planication et le dploiement des formations.
155
PO7 , AI4, DS1, DS5, DS8
AI4, SE1
DS7 : Instruire et former les utilisateurs
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 Contrats dexploitation (CE) Exigences de formations spcifiques la sensibilisation la scurit Rapports sur la satisfaction des utilisateurs
Rapports sur la performance des processus Mises jour de la documentation requises
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 defcacit et defcience. 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
PERSONNES
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 lefcacit et lefcience du centre de services, son cot ainsi que le service rendu et la satisfaction des utilisateurs.
OBJ. 03 OBJ. 13 OBJ. 23
Sassurer de la satisfaction des utilisateurs naux lgard des offres et des niveaux de services. Sassurer dune bonne utilisation et des bonnes performances des applications et des solutions informatiques. 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 naux (e-services) sont concerns, mme si les modalits daccs au service sont plus ou moins ltres (keyusers, correspondants). Ce processus est en relation avec le processus DS5 en ce qui concerne les incidents lis la scurit.
DEFINIR
DS8 Grer le service dassistance client et les incidents
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
METTRE EN PLACE UN SYSTEME DENREGISTREMENT ET DE SUIVI DES APPELS ENREGISTRER ET CLASSER LES DEMANDES SELON LES PROCEDURES DEFINIES TROUVER LES SOLUTIONS ET LES APPLIQUER (rsolution immdiate, escalade fonctionnelle ou hirarchique) CLOTURER LINCIDENT
ANALYSER LES TENDANCES ET EN RENDRE COMPTE AU MANAGEMENT
OBTENIR LACCORD CLIENT POUR LA CLOTURE
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 dnir le service aux clients en xant 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 dnis. 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 qualie 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 an 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 enn, latteinte des objectifs en termes de niveau de service contract. Parmi les contrles, on sattache en particulier vrier la bonne prise en compte des demandes clients (enregistrement, qualication, affectation, communication vers le client), lexistence de procdures descalade (pour les incidents non rsolus dans les dlais), le mcanisme de clture dincidents et enn, 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
Manuels utilisateur, dexploitation, dassistance, technique et dadministration Autorisation de changement Elments de configuration mis disposition Contrats de services (CS) Contrats dexploitation (CE) Seuils des incidents de scurit Dfinition des incidents de scurit Configuration informatique/dtail des actifs Problmes connus, erreurs connues, solutions de contournement Tickets dincidents
Demande de service/demande de changement Rapports dincidents Rapports sur la performance des processus Rapports sur la satisfaction des utilisateurs
DS9
Grer la configuration
Connatre tout moment la conguration logicielle et matrielle pour mieux la grer constitue une brique de base de la gouvernance informatique. Une gestion de la conguration efcace permet de tracer les modications apportes aux composants du SI, aide vrier la cohrence et la compltude de ces modications, facilite la rsolution des problmes de production et en rend la rsolution plus rapide.
Vue densemble
La gestion de la conguration permet en tout premier lieu de conjuguer apport de valeur et gestion des ressources dans un souci defcacit.
160
GOUVERNANCE SI
EXIGENCES METIER
PERSONNES
Figure 6-25 : Grer la conguration : DS9
Le processus DS9 prend en compte les exigences defcience, de disponibilit et dintgrit, et contribue la gestion des risques.
Pourquoi ?
La gestion de la conguration suppose tout dabord de tracer tous les changements pour tenir jour la base de donnes de lensemble des congurations informatiques. partir de l, la gestion de la conguration consiste optimiser, prvoir et anticiper ses volutions.
OBJ. 14 OBJ. 15
Protger tous les actifs informatiques et en tre comptable. Optimiser linfrastructure, les ressources et les capacits informatiques.
Les ressources informatiques entrent dans le primtre (applications, infrastructures, informations) du processus DS9.
161
Rapport dinterventions et de rgularisations
DS9 Grer la configuration
DEFINIR
DEFINIR DES PROCEDURES DE GESTION DES CONFIGURATIONS (identification, enregistrement, mise jour)
AMELIORER
TRAITER LES ANOMALIES OU LES ECARTS PAR RAPPORT A LA SITUATION ACTUELLE METTRE A JOUR LE REFERENTIEL DE CONFIGURATION
METTRE EN UVRE
CENTRALISER DANS UN REFERENTIEL TOUTES LES INFORMATIONS SUR LES ELEMENTS DE CONFIGURATION ETABLIR LES CONFIGURATIONS DE BASE
CONTROLER
VERIFIER REGULIEREMENT LES INFORMATIONS DE CONFIGURATION (intgrit des donnes, licences logiciels, etc.)
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 sufsants pour rpondre aux objectifs doptimisation, dvolution et de gestion des incidents sans entrer dans des dtails superus.
Mesures et contrles
Les indicateurs de bon fonctionnement du processus sont essentiellement les carts entre la ralit et la conguration enregistre, avec leurs impacts en termes de gestion des incidents, doptimisation de la conguration et de gestion des risques.
Le gestionnaire de la conguration Le rle de gestionnaire de la conguration sappuie sur les responsables exploitation, architecture et dveloppements pour la mise jour du rfrentiel de conguration. Par ailleurs, il peut se faire aider dune instance de dcision en matire de choix dvolutions.
162
AI4, AI7, DS4
AI6, DS8, DS10, DS13, SE1
DS9 : Grer la configuration
Manuels utilisateur, dexploitation, dassistance, technique et dadministration Elments de configuration mis disposition Elments de configuration informatique critiques
Configuration informatique/dtail des actifs Demande de modification Rapports sur la performance des processus
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 efcace des problmes implique didentier ces problmes, de les classer, den dterminer la cause, de trouver des solutions, puis de suivre les actions correctives et den vrier lefcacit.
Vue densemble
Lapport de valeur est la principale contribution de ce processus la gouvernance informatique, dans un souci defcience et defcacit. Enn, 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
PERSONNES
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.
OBJ. 03 OBJ. 16 OBJ. 17
Sassurer de la satisfaction des utilisateurs naux lgard des offres et des niveaux de services. Rduire le nombre de dfauts et de retraitements touchant la fourniture de solutions et de services. Protger latteinte des objectifs informatiques.
Il concerne lensemble des ressources informatiques.
164
DEFINIR
DEFINIR DES PROCEDURES DENREGISTREMENT ET DE CLASSIFICATION DES PROBLEMES (impact, urgence, priorit)
DS10 Grer les problmes
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) 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) SURVEILLER EN PERMANENCE LES CONSEQUENCES SUR LES SERVICES INFORMATIQUES
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 dnit une procdure denregistrement, de suivi et de rsolution. Une cellule est en charge de proposer des solutions dradication pour rsoudre les problmes. Le plus difcile est de rpercuter les demandes de changements sur les units concernes an 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 dinuence du responsable en charge des problmes an dinuer 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 enn que la rduction des problmes doit la fois amliorer la disponibilit des ressources pour les utilisateurs mais aussi rsorber notablement le ux des incidents. Dans la mesure o la gestion de lassistance et des incidents est trs souvent externalise, il faut srieusement rchir 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
Autorisation de modification Rapports dincidents Configuration informatique/dtail des actifs Historiques des erreurs
Demande de changement Historique des problmes Rapports sur la performance des processus Problmes connus, erreurs connues et solutions de contournement
DS11
Grer les donnes
Les donnes constituent un actif essentiel des entreprises quil faut grer en termes de conservation, de abilit 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.
PERSONNES
Figure 6-31 : Grer les donnes : DS11
Les exigences mtier privilgier sont lintgrit et la abilit des donnes. noter que la condentialit, 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
processus DS11 doit permettre de matriser les objectifs prsents dans le tableau 6-11.
OBJ. 04 OBJ. 19 OBJ. 27
Optimiser lutilisation de linformation. Sassurer que l'information critique et condentielle nest pas accessible ceux qui ne doivent pas y accder. 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 spcique (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
DS11 Grer les donnes
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 DEFINIR DES PROCEDURES DE SAUVEGARDE ET DE RESTAURATION DES DONNEES
AMELIORER
TENIR A JOUR LINVENTAIRE DES MEDIAS ET TRAITER LES ANOMALIES DETECTEES
METTRE EN UVRE
GERER DE FAON SECURISEE LA RECEPTION, LE TRAITEMENT, LE STOCKAGE ET LA SORTIE DES DONNEES FOURNIR DES MOYENS SURS DELIMINATION DES DONNEES ET DES MATERIELS DESTINES AU REBUT
CONTROLER
VERIFIER QUE DES DONNEES DETRUITES OU A DETRUIRE SONT IRRECUPERABLES 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 dnition des principales procdures mettre en uvre (stockage, archivage, mise au rebut, sauvegarde) et dune vision claire et able 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 enn quune des difcults du processus concerne la relation aux mtiers, au moins sur trois aspects : la clarication du primtre de gestion des donnes numrises (prise en compte des mdias grs par les mtiers) ; la dnition des exigences mtier et leur ngociation dans des SLA spciques (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 conguration complte pour excuter des applications.
Mesures et contrles
Il faudra contrler la compltude, la abilit 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 vriera 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. Enn, on vriera 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 coner 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 an 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 Classifications attribues aux donnes Manuels utilisateur, dexploitation, dassistance, technique et dadministration Contrats dexploitation (CE) Plan de stockage et de protection hors site Plan et politiques de scurit informatique
Instructions dexploitation pour la gestion des donnes Rapports sur la performance des 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 efcaces 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
PERSONNES
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, uides 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).
OBJ. 14 OBJ. 19 OBJ. 21
Protger tous les actifs informatiques et en tre comptable. Sassurer que l'information critique et condentielle nest pas accessible ceux qui ne doivent pas y accder. 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. Sassurer quun incident ou une modication dans la fourniture dun service informatique na quun impact minimum sur lactivit.
OBJ. 22
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 uides, 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
DS12 Grer lenvironnement physique
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

CHOISIR LE(S) SITE(S) PHYSIQUE(S) DES EQUIPEMENTS INFORMATIQUES ETABLIR LES RESPONSABILITES CONCERNANT LA SURVEILLANCE ET LA SECURITE PHYSIQUE GERER ET MAINTENIR LENVIRONNEMENT PHYSIQUE CONTROLER LES ACCES AUX SITES, BATIMENTS ET ZONES SECURISEES CONTROLER LES RISQUES ENVIRONNEMENTAUX AVEC DES DISPOSITIFS SPECIALISES

Le processus est bas sur la dnition 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 dnir un responsable par site et de dployer les procdures correspondantes. Ensuite, les procdures et les responsabilits tant xes, 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.
Le responsable exploitation 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
Classifications attribues aux donnes Evaluation des risques Exigences de lenvironnement physique
Rapports sur la performance des 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 dnir des procdures dexploitation permettant une gestion efcace des traitements programms et une protection des donnes sensibles, an 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 defcacit et defcience.
GOUVERNANCE SI
EXIGENCES METIER
PERSONNES
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 signie que la totalit des tches dexploitation fait lobjet de procdures prcises et dtailles, y compris les demandes de drogations ou les exceptions.
175
OBJ. 03 OBJ. 21 OBJ. 23
Sassurer de la satisfaction des utilisateurs naux lgard des offres et des niveaux de services. 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. 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
DS13 Grer lexploitation
DEFINIR DES PROCEDURES DE SURVEILLANCE DE LINFRASTRUCTURE INFORMATIQUE DEFINIR ET PLANIFIER UNE MAINTENANCE PREVENTIVE DE LINFRASTRUCTURE INFORMATIQUE

ELABORER LES PLANNINGS EN FONCTION DE LA CHARGE DE TRAVAIL GERER LEXPLOITATION CONFORMEMENT AUX NIVEAUX DE SERVICES CONVENUS METTRE EN PLACE DES DISPOSITIFS DE SECURITE PHYSIQUE POUR LES INFORMATIONS SENSIBLES CONTROLER ET SURVEILLER LINFRASTRUCTURE ET LES TRAITEMENTS REALISES VERIFIER QUE LE PERSONNEL CONNAIT LES TACHES DEXPLOITATION DONT IL DEPEND
176

Le processus part dune dnition 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 planications 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. Enn, 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.
Le responsable exploitation Il est naturellement le pilote et le responsable du processus.
177

AI4, AI7, DS1, DS4 DS9, DS11
DS8, DS10, SE1
DS13 : Grer lexploitation
Manuels utilisateur, dexploitation, dassistance, technique et dadministration Plans de mise en production, de publication et de diffusion des logiciels Contrats de services (CS) Contrats dexploitation (CE) Plan de stockage et de protection hors site Configuration informatique/dtail des actifs Instructions dexploitation pour la gestion des donnes
Tickets dincidents Historiques des erreurs Rapports sur la performance des 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. Les processus de ce domaine sont les suivants : 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 an 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 xs. 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 defcacit et defcience du systme dinformation pour les mtiers.
179
GOUVERNANCE SI
EXIGENCES METIER
PERSONNES
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 xs.
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 planier 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.
Vis--vis des 28 objectifs globaux assigns au systme dinformation (voir 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 mtier en accord avec la stratgie mtier. 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 OBJ. 28
Sassurer de la transparence et de la bonne comprhension des cots, bnces, stratgie, politiques et niveaux de services des SI. 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 gure 7-2 reprsente les ux internes du processus SE1.
DEFINIR COMMUNIQUER
DEFINIR LAPPROCHE DE SURVEILLANCE LISTER LES OBJECTIFS MESURABLES FIXES PAR LE MANAGEMENT DEFINIR DES INDICATEURS DE PERFORMANCE Plan dactions correctives
SE1 Surveiller et valuer la performance des SI
FAIRE VALIDER LES OBJECTIFS PAR LE METIER ET LES AUTRES PARTIES PRENANTES
Objectifs de performances, de mesures, etc.
AMELIORER
RENDRE COMPTE DE LA PERFORMANCE A LA DIRECTION GENERALE Rapport de gestion
METTRE EN UVRE
METTRE EN PLACE UNE METHODE DE SURVEILLANCE
IDENTIFIER ET SURVEILLER LES ACTIONS DESTINEES A AMELIORER LA PERFORMANCE
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. Enn, 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
Les mtriques mettre en place pour sassurer de lefcacit du processus concernent la vrication 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 xs initialement, et sur la satisfaction des parties prenantes quant la qualit du reporting. La mesure de la mise en uvre de ce processus passe principalement par 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 nalit 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 xe. Le directeur des systmes dinformation 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 qualier 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
Rapports cots/bnfices Rapports sur la performance des projets Rapports sur le statut des changements Rapports sur la performance des processus Rapports sur la satisfaction des 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 Rapports sur la performance des 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 vrications 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 vrie que lensemble du processus fonctionne.
Vue densemble
Le processus SE2 rsulte principalement dune volont de mettre en place un mcanisme de surveillance du contrle interne an dapprcier les risques de drives du fonctionnement de la DSI (gestion des risques) et ainsi
183
GOUVERNANCE SI
EXIGENCES METIER
PERSONNES
Figure 7-4 : Surveiller et valuer le contrle interne : SE2
de sassurer de lapport de valeur du SI. Ceci permet de rpondre aux critres defcacit et defcience 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.
Vis--vis des 28 objectifs globaux assigns au systme dinformation (voir annexe 2, Objectifs du systme dinformation et processus CobiT ), le processus SE2 doit permettre de matriser les objectifs prsents dans le tableau 7-2.
OBJ. 14 OBJ.17 OBJ. 21
Protger tous les actifs informatiques et en tre comptable. Protger latteinte des objectifs informatiques. 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. Assurer la conformit de linformatique aux lois et aux rglements.
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.
SE2 Surveiller et valuer le contrle interne
DEFINIR
DEFINIR UN SYSTEME DE CONTROLE INTERNE ET LINTEGRER AU REFERENTIEL DES PROCESSUS INFORMATIQUES
AMELIORER
SUIVRE LES ACTIONS CORRECTIVES PROPOSEES PAR LE MANAGEMENT
COMMUNIQUER
RENDRE COMPTE AUX PARTIES PRENANTES Rapport sur lefficacit des contrles des SI
METTRE EN UVRE
CONDUIRE UNE REVUE GENERALE DU CONTROLE INTERNE
SURVEILLER
CONDUIRE UN PROGRAMME PERMANENT DAUTO-EVALUATION DU CONTROLE FAIRE REALISER DES REVUES SUR LEFFICACITE DES CONTROLES PAR DES TIERS IDENTIFIER ET ENREGISTRER LES ANOMALIES DETECTEES PAR LES CONTROLES SURVEILLER ET CONTROLER LES ACTIVITES DU CONTROLE INTERNE SURVEILLER LA PERFORMANCE DES REVUES INDEPENDANTES, DES AUDITS ET DES INVESTIGATIONS
RAPPORTER AU MANAGEMENT LES ANOMALIES DETECTEES

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 an 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
Les mtriques mettre en place pour sassurer de lefcacit du processus concernent la vrication des objectifs prsents au tableau 7-2. Ces mesures portent principalement sur le nombre de faiblesses identies 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.
Le directeur des systmes dinformation Il doit sassurer que ce processus est bien dni 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 la performance des processus
Rapports sur lefficacit des contrles des SI
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
PERSONNES
Figure 7-7 : Sassurer de la conformit aux obligations externes : SE3
Le processus SE3 rsulte principalement dune volont de mettre en place un mcanisme de contrle de conformit an 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 abilit 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 condentialit 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.
Vis--vis des 28 objectifs globaux assigns au systme dinformation (voir 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
Assurer la conformit de linformatique aux lois et aux rglements.
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
DEFINIR UN PROCESSUS DIDENTIFICATION DES EXIGENCES LEGALES ET REGLEMENTAIRES APPLICABLES AUX SI
SE3 Sassurer de la conformit aux obligations externes
Catalogue des exigences lgales et rglementaires
COMMUNIQUER
RENDRE COMPTE AU MANAGEMENT Rapport sur la conformit des activits informatiques
METTRE EN UVRE
EVALUER LIMPACT DES EXIGENCES REGLEMENTAIRES
AMELIORER
SUIVRE LES ACTIONS CORRECTIVES ENTREPRISES EN CAS DE NON-CONFORMITE
ALIGNER LES POLITIQUES, LES NORMES ET LES PROCEDURES SUR LES EXIGENCES REGLEMENTAIRES
SENSIBILISER LE PERSONNEL INFORMATIQUE A LA 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 dnition 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
Les mtriques mettre en place pour sassurer de lefcacit du processus concernent la vrication 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 vrication du dlai entre lapparition dune nouvelle exigence et sa prise en compte dans les pratiques de la DSI, et la vrication du dlai entre la dtection dune non-conformit et la mise en uvre dune action corrective associe.
Il sassure que ce processus est bien dni 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
Exigences lgales et rglementaires
Recueil des exigences lgales et rglementaires concernant la fourniture des services informatiques Rapport sur la conformit des activits informatiques aux exigences lgales et rglementaires externes
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
PERSONNES
Figure 7-10 : Mettre en place une gouvernance des SI : SE4
Le processus SE4 rsulte principalement dune volont de mettre en place 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 defcacit et defcience 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 OBJ. 27 OBJ. 28
Ragir aux exigences de la gouvernance en accord avec les orientations du CA. Sassurer de la transparence et de la bonne comprhension des cots, bnces, stratgie, politiques et niveaux de services des SI. Assurer la conformit de linformatique aux lois et aux rglements. 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.
SE4 Mettre en place une gouvernance des SI
DEFINIR COMMUNIQUER
FACILITER LA COMPREHENSION DE LA STRATEGIE DES SI (rles des SI, opportunits technologiques, etc.) Rapport sur la gouvernance des SI DEFINIR UN CADRE DE GOUVERNANCE DES SI
DESIGNER LE LEADERSHIP DEFINIR LES PROCESSUS DEFINIR LES ROLES ET RESPONSABILITES ET LES STRUCTURES ORGANISATIONNELLES
AMELIORER
RESOUDRE LES PROBLEMES DETECTES PAR LES EVALUATIONS INDEPENDANTES METTRE EN UVRE LES RECOMMANDATIONS ADOPTEES PAR LE MANAGEMENT
IMPLIQUER LE METIER DANS LES PRISES DE DECISION LIEES AUX SI

FOURNIR UNE ASSURANCE INDEPENDANTE SUR LA PERFORMANCE ET DE LA CONFORMITE AUX POLITIQUES, NORMES ET PROCEDURES
COMMUNIQUER LAPPETENCE POUR LE RISQUE INFORMATIQUE
METTRE EN PLACE LA GOUVERNANCE DES SI
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
Les mtriques mettre en place pour sassurer de lefcacit du processus concernent la vrication des objectifs prsents au tableau 7-4. Ces mesures portent principalement sur le nombre dcarts dtects dans la mise en uvre de la gouvernance. La mesure de la mise en uvre de ce processus passe principalement par 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
Rfrentiel des processus informatiques Rapports cots/bnfices Evaluations des risques et rapports associs Recueil des exigences lgales et rglementaires concernant la fourniture de services informatiques
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
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 difcile 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. Enn, 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 spcicits 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 ne 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 certis CISA (Certied 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 condentialit 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 bnce 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
informer les parties appropries des rsultats des travaux effectus, en communiquant tous les faits signicatifs 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 xant le primtre de laudit et les responsabilits attribues. Ensuite, lauditeur doit construire un rfrentiel daudit qui tablira une transparence totale entre la mission cone 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 spcicits 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). Enn, 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 suft ensuite, au cas par cas, de les toffer de tests dtaills en fonction de la spcicit 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. 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.
tape 3
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 classications 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 classication trs solide : domaines, processus, objectifs de contrle ; critres dinformation (efcacit, efcience, condentialit, intgrit, disponibilit, conformit et abilit) ; 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 insufsant, il sufrait de puiser dans dautres publications (voir chapitre 3, Prsentation dtaille de CobiT ) pour en dnir encore un autre. Enn, 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 nancire), 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 nancire. 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 conance accorder aux CAAT elles-mmes ; la conance 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 simpli 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 Planier 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 vriant 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 dnis 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 enn met en vidence les rgulations informelles. Analyse Sur la base du rfrentiel simpli, lexercice consiste identier 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 enn de proposer des recommandations se matrialisant soit par un changement des priorits et/ou de rythme des projets et actions en cours, soit par lidentication 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 rete 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 xe 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 Initiatives

Comment respecter nos engagements vis--vis des clients et des utilisateurs ?
Clients et utilisateurs Objectifs Mesures Cibles Initiatives
Vision et stratgie
Anticipation et vision du futur Objectifs Mesures Cibles Initiatives
Pour tre efficaces et efficients, comment piloter nos processus internes ?
Comment anticiper sur la technologie, les ressources, les tiers pour tre dans de meilleures conditions oprationnelles ?
Processus mtier internes 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 able ; 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 an 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 spciques 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 certications associes se rfre au management des services TI. Cest le cas en particulier de la certication 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 nalit 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 gure 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 l des versions.
Planifier et organiser
1 4 2 3 4 5 6 7 8 9 10
Acqurir et implmenter
Surveiller et valuer
Les processus CobiT pris en charge par ITIL
3 1
10 11 12 13
Dlivrer et supporter
Complet Aucun
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 n, 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 conguration, 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 dnir 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, an 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 prols 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 spciques 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, conguration 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 bnces du support ; lclatement de la vision contractuelle gestion des tiers et ce, des niveaux de comptence insufsants, limitant lalignement et la cohrence entre les contrats et les obligations. En consquence, il tait difcile 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 congurations). 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 nanciers. 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 efcace 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 certication 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 dnition 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 difcults 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 dnir 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 l 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 efcace 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 able 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 difcult 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 bnces 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 PO9 valuer et grer les risques DS4 Assurer un service continu DS5 Assurer la scurit des systmes
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 nalits 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 dafchage. 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 certication. Il est cependant important de noter que la manire de dnir 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 dni par la dtermination des activits ralises par une organisation identie. Pour le management de la scurit de linformation, le primtre est dtermin par lidentication 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 certication. 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 difcults ou dconvenues qui apparaissent au l 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 (planication, 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 n nest pas certaine ? Par exemple, la n du contrat dun intgrateur et le passage en TMA peut signier que le projet est termin, mais aussi que le budget initial est consomm ! La mise en production nest pas synchrone de la n 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 suft 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 PO2 Dnir larchitecture de linformation PO3 Dterminer lorientation technologique PO5 Grer les investissements informatiques
Mots-cls ou concepts non pris en compte par CMMI 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. Imputation des cots, dnition des services, catalogue des services, modle de cot et de refacturation. Service dassistance, gestion des incidents, enregistrement des demandes, escalade. Intgrit des donnes, proprit des donnes et des systmes, management des donnes, stockage. Environnement physique. Gestion des oprations. Contrles internes, rfrentiel de management des risques. Gouvernance TI, conformit rglementaire.
DS3 Grer la performance et la capacit DS4 Assurer un service continu
DS5 Assurer la scurit des systmes DS6 Identier et imputer les cots DS8 Grer le service d'assistance client et les incidents DS11 Grer les donnes DS12 Grer l'environnement physique DS13 Grer lexploitation SE2 Surveiller et valuer le contrle interne SE3 Assurer la conformit aux obligations externes
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, spcications). 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 certication ISO 9001 obit des rgles strictes, en particulier concernant la structuration des processus en domaines (management, support, ralisation). Pour conjuguer CobiT et la certication, deux scnarios sont possibles. Scnario 1 : certier 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 : identier et slectionner dans le rfrentiel CobiT, quelques processus sufsamment matures pour les intgrer au primtre de certication 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 dnir un systme de management de la qualit (SMQ) ddi la DSI qui accueille les processus en cours de dnition, 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 certication 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 spcique 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 dnir une structure complte de processus. Il sagit de slectionner, dans le modle propos par CobiT, les processus les plus matures ou les plus dterminants an de les piloter selon la logique du systme management global de lentreprise. Pour tre certiables, les processus slectionns doivent tre dploys au sein de la DSI, et tre sufsamment mrs pour tre mesurs ou, pour les plus critiques, pilots. Ce scnario ncessite de dnir une cartographie prsentant une cohrence entre les processus slectionns pour la DSI et ceux dj dnis 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 gure 9-1).
Comparaison des scnarios

Tableau 9-2 : Comparaison des scnarios de certication
Scnario 1 Principe Certier ISO 9001 lensemble de la DSI. Mise en place dune organisation ddie. 2 3 ans Stratgie du directeur des systmes dinformation, autonomie de la DSI.
Scnario 2 Certier les processus les plus matures ou prioritaires dj dploys dans le cadre DSI. Dmarche intgre dans une dmarche globale dentreprise. Par tranches de 1 an Prise en compte des dmarches DSI dans un programme dexcellence ou damlioration continue de lentreprise.
Effort DSI 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 certication 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 certication de lentreprise, les processus slectionns de CobiT doivent cependant rpondre aux exigences classiques dune dmarche processus. Les critres sont les suivants : le processus est dni, 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 identis : PO1 Dnir un plan informatique stratgique pour le SI PO10 Manager les projets SI (guide de la gouvernance des SI) PO9 valuer et grer les risques (dnir 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 dnir 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 identis dans cette catgorie sont : manager les ressources humaines (processus groupe) ; grer la refacturation des prestations (spcique DSI) ; raliser les achats (processus groupe) ; dnir des directives de scurit (spcique DSI) ; matriser les risques business lis au SI (spcique DSI) ; mettre en place un tableau de bord scurit (spcique DSI) ; dnir un plan de reprise dactivit (PRA) et assurer le support au dploiement (spcique 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 justient 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 simplie 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 efcace 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 efcacement et sans risque CobiT Quickstart, lISACA propose les hypothses suivantes pour le choix de cette implmentation simplie : 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 simpli. Ainsi, sont conservs : 31 processus sur les 34 prsents dans CobiT. Ils manquent les processus DS6 (Identier 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 planication, 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 an 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 l 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 bncient de systmes dinformation existants (automates dexploitation, centre dassistance, comptabilit, facturation, paie, achats). Les lments sont donc parfois mesurs avec une nalit 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 didentier 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 l du temps. Son efcacit 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 difcult 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 identis 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 signie 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 : PO9 valuer et grer les risques AI3 Acqurir une infrastructure technique et en assurer la maintenance AI6 Grer les changements AI7 Installer et valider des solutions et des modications DS1 Dnir et grer les niveaux de services DS2 Grer les services tiers DS4 Assurer un service continu DS5 Assurer la scurit des systmes DS8 Grer le service dassistance client et les incidents DS9 Grer la conguration DS10 Grer les problmes DS13 Grer lexploitation
227
Groupe 2 Piloter les ressources TI (hormis les projets applicatifs) : PO4 Dnir les processus, lorganisation et les relations de travail 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 modications DS8 Grer le service dassistance client et les incidents DS9 Grer la conguration DS13 Grer lexploitation 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 identier 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 bncier 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. PO6 Faire connatre les buts et les orientations du management PO7 Grer les ressources humaines PO8 Grer la qualit PO10 Manager les projets AI1 Trouver des solutions informatiques AI2 Acqurir des applications et en assurer la maintenance DS3 Grer la performance et la capacit DS7 Instruire et former les utilisateurs DS11 Grer les donnes DS12 Grer lenvironnement physique SE1 Surveiller et valuer la performance des SI 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). PO2 Dnir larchitecture de linformation PO3 Dterminer lorientation technologique PO5 Grer les investissements informatiques DS6 Identier et imputer les cots SE2 Surveiller et valuer le contrle interne SE3 Sassurer de la conformit aux obligations externes
229
Niveau 4 Gouvernance des SI Au dernier stade de dploiement, il reste faire progresser en maturit les processus PO1 et SE4 qui nalisent 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.
Tableau 10-1 : Proposition de modle de maturit tag, ASK Conseil
PO4 Dnir les processus, lorganisation et les relations de travail PO9 valuer et grer les risques 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 modications DS1 Dnir et grer les niveaux de services DS2 Grer les services tiers DS4 Assurer un service continu DS5 Assurer la scurit des systmes DS8 Grer le service dassistance client et les incidents DS9 Grer la conguration DS10 Grer les problmes DS13 Grer lexploitation PO6 Faire connatre les buts et les orientations du management PO7 Grer les ressources humaines PO8 Grer la qualit PO10 Manager les projets AI1 Trouver des solutions informatiques AI2 Acqurir des applications et en assurer la maintenance DS3 Grer la performance et la capacit DS7 Instruire et former les utilisateurs DS11 Grer les donnes DS12 Grer lenvironnement physique SE1 Surveiller et valuer la performance des SI PO2 Dnir larchitecture de linformation PO3 Dterminer lorientation technologique PO5 Grer les investissements informatiques DS6 Identier et imputer les cots SE2 Surveiller et valuer le contrle interne SE3 Sassurer de la conformit aux obligations externes PO1 Dnir un plan informatique stratgique SE4 Mettre en place une gouvernance des SI
Niveau 1 - Scurit et fonctionnement
Niveau 2 - Mesures et pilotage
Niveau 3 - Apport de valeur
230
Niveau 4 - Gouvernance des SI
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 difcult 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 ; dnir, 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 bnces 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 an 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) an 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 dnit 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 xs.
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 signicatifs 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 xer la stratgie, de garantir que les objectifs sont atteints et que les risques sont grs correctement, et de vrier 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 vrier 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
Objectifs
PO1 : Dnir un plan informatique stratgique PO3 : Dterminer lorientation technologique PO2 : Dnir larchitecture de linformation
Processus
PO7 : Grer les ressources humaines de linformatique PO5 : Grer les investissements informatiques PO6 : Faire connatre les buts et les orientations du management PO9 : valuer et grer les risques PO4 : Dnir les processus, lorganisation et les relations de travail
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. 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 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 Obj. 11 Obj. 12 Sassurer de la satisfaction rciproque dans les relations avec les tiers. Sassurer de lintgration progressive des solutions informatiques aux processus mtier. Sassurer de la transparence et de la bonne comprhension des cots, bnces, stratgies, politiques et niveaux de services des SI. Sassurer dune bonne utilisation et des bonnes performances des applications et des solutions informatiques. Protger tous les actifs informatiques et en tre comptable. Optimiser linfrastructure, les ressources et les capacits informatiques.
Obj 13
Obj. 14 Obj. 15
244
AnnexeII Objectifs du systme dinformation et processus CobiT
Tableau II-1 : Objectifs du systme dinformation et processus du domaine Planier et Organiser (suite)
Objectifs
PO1 : Dnir un plan informatique stratgique PO3 : Dterminer lorientation technologique PO2 : Dnir larchitecture de linformation
Processus
PO7 : Grer les ressources humaines de linformatique PO5 : Grer les investissements informatiques PO6 : Faire connatre les buts et les orientations du management PO9 : valuer et grer les risques PO4 : Dnir les processus, lorganisation et les relations de travail
Obj. 16 Obj. 17 Obj. 18
Rduire le nombre de dfauts et de retraitements touchant la fourniture de solutions et de services. Protger latteinte des objectifs informatiques. 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. 19
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 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
Objectifs
AI3 : Acqurir une infrastructure technique et en assurer la maintenance AI2 : Acqurir des applications et en assurer la maintenance AI1 : Trouver des solutions informatiques
Processus
AI4 : Faciliter le fonctionnement et lutilisation AI5 : Acqurir des ressources informatiques AI6 : Grer les changements AI7 : Installer et valider des solutions et des modications
Obj. 01
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 Obj. 11 Obj. 12 Sassurer de la satisfaction rciproque dans les relations avec les tiers. Sassurer de lintgration progressive des solutions informatiques aux processus mtier. Sassurer de la transparence et de la bonne comprhension des cots, bnces, stratgie, politiques et niveaux de services des SI. Sassurer dune bonne utilisation et des bonnes performances des applications et des solutions informatiques. Protger tous les actifs informatiques et en tre comptable. Optimiser linfrastructure, les ressources et les capacits informatiques.
Obj. 13
Obj. 14 Obj. 15
246
Tableau II-2 : Objectifs du systme dinformation et processus du domaine Acqurir et Implmenter (suite)
Objectifs
AI3 : Acqurir une infrastructure technique et en assurer la maintenance AI2 : Acqurir des applications et en assurer la maintenance AI1 : Trouver des solutions informatiques
Processus
AI4 : Faciliter le fonctionnement et lutilisation AI5 : Acqurir des ressources informatiques AI6 : Grer les changements AI7 : Installer et valider des solutions et des modications
Obj. 16 Obj. 17 Obj. 18
Rduire le nombre de dfauts et de retraitements touchant la fourniture de solutions et de services. Protger latteinte des objectifs informatiques. Montrer clairement les consquences pour lentreprise des risques lis aux objectifs et aux ressources informatiques. Sassurer que linformation critique et condentielle nest pas accessible ceux qui ne doivent pas y accder.
Obj. 19
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 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
Objectifs
DS4 : Assurer un service continu DS3 : Grer la performance DS2 : Grer les services tiers DS6 : Identier et imputer DS5 : Assurer la scurit DS1 : Dnir et grer
Processus
DS12 : Grer lenvironnement physique DS9 : Grer la conguration DS10 : Grer les problmes DS13 : Grer lexploitation DS7 : Instruire et former DS11 : Grer les donnes DS8 : Grer le service
Obj. 01
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 Obj. 11 Obj. 12 Sassurer de la satisfaction rciproque dans les relations avec les tiers. Sassurer de lintgration progressive des solutions informatiques aux processus mtier. Sassurer de la transparence et de la bonne comprhension des cots, bnces, stratgie, politiques et niveaux de services des SI. Sassurer dune bonne utilisation et des bonnes performances des applications et des solutions informatiques. Protger tous les actifs informatiques et en tre comptable. Optimiser linfrastructure, les ressources et les capacits informatiques.
Obj. 13
Obj. 14 Obj. 15
248
Tableau II-3 : Objectifs du systme dinformation et processus du domaine Dlivrer et Supporter (suite)
Objectifs
DS4 : Assurer un service continu DS3 : Grer la performance DS2 : Grer les services tiers DS6 : Identier et imputer DS5 : Assurer la scurit DS1 : Dnir et grer
Processus
DS12 : Grer lenvironnement physique DS9 : Grer la conguration DS10 : Grer les problmes DS13 : Grer lexploitation DS7 : Instruire et former DS11 : Grer les donnes DS8 : Grer le service
Obj. 16 Obj. 17 Obj. 18
Rduire le nombre de dfauts et de retraitements touchant la fourniture de solutions et de services. Protger latteinte des objectifs informatiques. 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. 19
Obj. 22 Sassurer quun incident ou une modication dans la fourniture dun service informatique na quun impact minime 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 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
Partie IV Annexes
Tableau II-4 : Objectifs du systme dinformation et processus du domaine Surveiller et valuer
Objectifs
Processus
Obj. 01 Obj. 02 Obj. 03 Obj. 04 Obj. 05 Obj. 06 Obj. 07 Obj. 08 Obj. 09 Obj. 10 Obj. 11 Obj. 12 Obj. 13 Obj. 14 Obj. 15 Obj. 16 Obj. 17
Ragir aux exigences mtier en accord avec la stratgie mtier. Ragir aux exigences de la gouvernance en accord avec les orientations du CA. Sassurer de la satisfaction des utilisateurs naux lgard des offres et des niveaux de services. Optimiser lutilisation de linformation. Donner de lagilit linformatique. Dterminer comment traduire les exigences mtier de fonctionnement et de contrle en solutions automatises efcaces et efcientes. Acqurir et maintenir fonctionnels des systmes applicatifs intgrs et standardiss. Acqurir et maintenir oprationnelle une infrastructure informatique intgre et standardise. Se procurer et conserver les comptences ncessaires la mise en uvre de la stratgie informatique. Sassurer de la satisfaction rciproque dans les relations avec les tiers. Sassurer de lintgration progressive des solutions informatiques aux processus mtier. Sassurer de la transparence et de la bonne comprhension des cots, bnces, stratgie, politiques et niveaux de services des SI. Sassurer dune bonne utilisation et des bonnes performances des applications et des solutions informatiques. Protger tous les actifs informatiques et en tre comptable. Optimiser linfrastructure, les ressources et les capacits informatiques. Rduire le nombre de dfauts et de retraitements touchant la fourniture de solutions et de services. Protger latteinte des objectifs informatiques.
250
SE3 : Sassurer de la conformit aux obligations externes
SE1 : Surveiller et valuer la performance du SI
Tableau II-4 : Objectifs du systme dinformation et processus du domaine Surveiller et valuer (suite)
Objectifs
Processus
Obj. 18 Obj. 19 Obj. 20 Obj. 21
Montrer clairement les consquences pour lentreprise des risques lis aux objectifs et aux ressources informatiques. Sassurer que linformation critique et condentielle nest pas accessible ceux qui ne doivent pas y accder. 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. Sassurer quun incident ou une modication dans la fourniture dun service informatique na quun impact minimum sur lactivit. Sassurer que les services informatiques sont disponibles dans les conditions requises. Amliorer la rentabilit de linformatique et sa contribution la protabilit de lentreprise. Livrer les projets temps et dans les limites budgtaires en respectant les standards de qualit. Maintenir lintgrit de linformation et de linfrastructure de traitement. Assurer la conformit de linformatique aux lois et aux rglements. Sassurer que linformatique fait preuve dune qualit de service efciente en matire de cots, damlioration continue et de capacit sadapter des changements futurs.
Obj. 22 Obj. 23 Obj. 24 Obj. 25 Obj. 26 Obj. 27 Obj. 28
251
SE3 : Sassurer de la conformit aux obligations externes
SE1 : Surveiller et valuer la performance du SI
Index
A
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 action corrective 182 AFAI (Association franaise pour laudit et le conseil en Informatique) 3 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 AI5 Acqurir des ressources informatiques 112 AI6 Grer les changements 116 AI7 Installer et valider des solutions et des modifications 121
Assurer la scurit des systmes (DS5) 144 Assurer un service continu (DS4) 140
B
besoins mtier 54, 99 BSC (Balanced Scorecard) 12, 205, 236 budget 69
C
cadre de rfrence processus informatique 64 centre de services 209 CMMI (Capability Maturity Model Integration) 22, 215 CobiT Quick Scan 201 Quickstart 223 CobiT (Control OBjectives for Information and related Technology) 3 CobiT Online 41 CobiT version 4 4 CobiT version 4.1 4
253
Index
communication 73 comptences 77 conception 102 contrat dexploitation (CE) 128 de services (CS) 128 COSO Committee of Sponsoring Organizations of the Treadway Commission 3, 29 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
domaines de la gouvernance alignement stratgique 7 apport de valeur 8 gestion des ressources 8 gestion des risques 9 mesure de la performance 9 donnes 237 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 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
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
E
EFQM (European Foundation for Quality Management) 25 environnement de tests 123 valuer et grer les risques (PO9) 84 externalisation 113, 145
254
Index
F
Faciliter le fonctionnement et lutilisation (AI4) 108 Faire connatre les buts et les orientations du management (PO6) 73
apport de valeur 69, 96, 101, 109, 117, 121, 128, 133, 141, 153, 156, 160, 163, 167, 184, 190, 235 gestion des ressources 56, 60, 64, 77, 105, 112, 117, 128, 137, 149, 160, 167, 175, 190, 238 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 gestion de services ISO/IEC 20000 20 gouvernance domaines alignement stratgique 52, 56, 73, 77, 81, 85, 89, 96, 101, 128, 187, 190, 235
I
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 ITIL V2 19 ITIL V3 19, 21
L
loi Sarbanes-Oxley 4, 40, 200
255
Index
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
N
niveau de service 128
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 Objectifs du systme dinformation et processus CobiT 243 offre de services 52 organisation 64
O
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
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
257
Index
ressources application 31 information 31 infrastructure 31 personnes 31 roue de Deming (PDCA) 181
SLA (Service Level Agreement) 115, 128, 240 SLR (Service Level Requirement) 128, 241 SMQ (Systme de management de la qualit) 81 SMSI (Systme de management de la scurit de linformation) 87 spcifications dachat 114 Surveiller et valuer la performance des SI (SE1) 179 Surveiller et valuer le contrle interne (SE2) 183
S
Sassurer de la conformit aux obligations externes (SE3) 187 schma directeur 52 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 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
T
tableau de bord 180 temps de travail imputation 151 test de recette 123 Trouver des solutions informatiques (AI1) 95
V
VAL IT 41 veille rglementaire 188 technologique 59
258
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.
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.
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

CobiT - Pour Une Meilleure Gouvernance Des Systèmes D - Information

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

CobiT - Pour Une Meilleure Gouvernance Des Systèmes D - Information

Transféré par

Droits d'auteur :

Formats disponibles

D O M I N I Q U E M O I S A N D FABRICE GARNIER DE LABAREYRE

DITIONS EYROLLES 61, bd Saint-Germain 75240 Paris Cedex 05 www.editions-eyrolles.com

Table des matires

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

Table des matires

Le modle EFQM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Le dveloppement durable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . En rsum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

Partie II Description dtaille des processus

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

Table des matires

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

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

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

Table des matires

Partie III Mettre en uvre CobiT

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

Table des matires

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

Prsentation gnrale de CobiT

Partie I CobiT et la gouvernanceTI

Des Big 8 aux Big 4

Chapitre 1 Prsentation gnrale de CobiT

Figure 1-1 : Rpartition des responsabilits de la gouvernance TI

Partie I CobiT et la gouvernanceTI

Chapitre 1 Prsentation gnrale de CobiT

Les cinq axes stratgiques

Gestion des ressources

Figure 1-2 : Les domaines de la gouvernance des TI

Partie I CobiT et la gouvernanceTI

Chapitre 1 Prsentation gnrale de CobiT

Les autres rfrentiels de la gouvernance des TI

Partie I CobiT et la gouvernanceTI

Le Balanced Scorecard (BSC)

Chapitre 2 Les autres rfrentiels de la gouvernance des TI

Figure 2-1 : Les quatre cartes stratgiques du Balanced Scorecard (BSC)

Partie I CobiT et la gouvernanceTI

La norme ISO/IEC 27001

Chapitre 2 Les autres rfrentiels de la gouvernance des TI

Mettre en place et exploiter le SMSI

Maintenir et amliorer le SMSI

Contrler et revoir le SMSI

Figure 2-2 : La boucle PDCA applique au SMSI

Les normes ISO/IEC 17799 et ISO/IEC 27002

Partie I CobiT et la gouvernanceTI

Les critres communs (ISO/IEC 15408)

Chapitre 2 Les autres rfrentiels de la gouvernance des TI

Partie I CobiT et la gouvernanceTI

Chapitre 2 Les autres rfrentiels de la gouvernance des TI

ITIL: le management des services

Partie I CobiT et la gouvernanceTI

ITIL V2 et la norme ISO/IEC 20000

Chapitre 2 Les autres rfrentiels de la gouvernance des TI

Processus de fourniture de services

Rapport sur le service

Processus de mise en production

Processus de gestion des relations Processus de rsolution

Gestion des problmes

Partie I CobiT et la gouvernanceTI

Le management des tudes

Chapitre 2 Les autres rfrentiels de la gouvernance des TI

Partie I CobiT et la gouvernanceTI

Les modles qualit

Chapitre 2 Les autres rfrentiels de la gouvernance des TI