L'essentiel Du Référentiel Cobit

La boîte à outils
du DSI
Implémenter CobiT V5
�
étude numéro 13
La boîte à outils
du DSI
Implémenter CobiT V5
étude réalisée par Jean-Pierre Delvaux
étude numéro 13
Implémenter CobiT V5 - mars 2012 - N° 13 - Best Practices Research • 3

BEST PRACTICES INTERNATIONAL
SARL au capital de 21 000 euros – RCS Versailles 503 117 988

Pavillon Sisley, rue de la Croix-Rouge, 78430 LOUVECIENNES
Tél. : +(33) (0)6 75 64 63 97 – Email : information@bestresearch.fr
www.si-antipolis.com
www.bestresearch.fr
© jean-Pierre Delvaux, Best Practices International, 2012
Imprimé en Italie par Pixart.it
ISSN : 0753-3454 - Dépôt légal : mars 2012
Reproduction interdite – Tous droits réservés
Toute utilisation des informations contenues dans cette étude à des fins commerciales ou de
communication est interdite sans un accord écrit de Best Practices International.
Le code de la propriété intellectuelle n’autorisant, aux termes de l’article L. 122-5, d’une part, « les copies
ou reproductions strictement réservées à l’usage privé du copiste et non destinées à une utilisation
collective » et, d’autre part, que les analyses et les courtes citations dans un but d’exemple et d’illustration,
« toute représentation ou reproduction intégrale, ou partielle, faite sans le consentement des auteurs ou
de leurs ayants droits ou ayant cause, est illicite » (Article L. 122-4). Cette représentation ou reproduction,
par quelque moyen que se soit constituerait donc une contrefaçon sanctionnée par les articles L. 335-2 et
suivants du code de propriété intellectuelle. »
4 • Best Practices Research - N° 13 - mars 2012 - Implémenter CobiT V5

Sommaire
I - Introduction page 14
A. CobiT : un outil très opérationnel page 14

B. Faire les bonnes choses et faire bien les choses. page 14
C. Quelques vérités à rappeler… page 14
1. De CobiT et du PDG page 14
2. De CobiT et des directions des métiers page 14
3. De CobiT et du DSI page 14
4. De CobiT et de l’entreprise page 14
5. De CobiT et de l’entreprise (bis) page 14
6. De CobiT et des processus page 14
7. Du caractère international de CobiT page 14
8. De l’adaptabilité de CobiT à la culture française et aux modes français
de gestion d’un SI page 14
9. De CobiT et des entreprises de taille moyenne page 14
10. De CobiT et des technologies page 14
11. De CobiT et de l’audit informatique page 14
12. De CobiT, de sa complétude et de son caractère non prescriptif page 14
13. De CobiT et du TBE
(Tableau de Bord Equilibré / Balanced ScoreCard) page 14
II - Les principes de CobiT V5 page 14
A. Le caractère non encore achevé de la Version 5 page 14

B. La fusion CobiT / RiskIT / ValIT page 14
C. Des processus de gouvernance et des processus de gestion page 14
D. La structure de CobiT V5 page 14
1. Les processus page 14
2. Les pratiques de gestion et de gouvernance page 14
3. Les activités page 14
4. Les livrables des pratiques page 14
5. Les responsabilités des pratiques page 14
6. Mapping avec CobiT V4.1, ValIT, RiskIT page 14
7. Mapping avec Itil, TOGAF, PMBOCK, PRINCE2, ISO page 14
8. La cascade page 14
9. Les objectifs des processus et leurs métriques page 14
E. De la maturité à la capabilité… page 14
1. De la maturité des processus CobiT… page 14
2. à la capabilité des processus CobiT page 14
F. CobiT V5 : Les principaux éléments en français ! page 14
1. Établir et de maintenir le cadre de gouvernance (EDM01) page 14
2. Assurer l’optimisation de la valeur (EDM02) page 14
3. Assurer l’optimisation du risque (EDM03) page 14
4. Assurer l’optimisation des ressources (EDM04) page 14
5. Assurer la transparence pour les parties prenantes (EDM05) page 14
6. Définir le cadre de gestion de l’IT (APO01) page 14

7. Définir la stratégie (APO02) page 14
8. Gérer l’architecture d’entreprise (APO03) page 14
9. Gérer l’innovation (APO04) page 14
10. Gérer le portefeuille (APO05) page 14
11. Gérer les budgets et les coûts (APO06) page 14
12. Gérer les ressources humaines (APO07) page 14
13. Gérer les relations (APO08) page 14
14. Gérer les accords de service (APO09) page 14
15. Gérer les fournisseurs (APO10) page 14
16. Gérer la qualité (APO11) page 14
17. Gérer les risques (APO12) page 14
18. Gérer les programmes et les projets (BAI01) page 14
19. Définir les exigences (BAI02) page 14
20. Identifier et construire les solutions (BAI03) page 14
21. Gérer la disponibilité et la capacité (BAI04) page 14
22. Faciliter le changement organisationnel (BAI05) page 14
23. Gérer les changements (BAI06) page 14
24. Accepter et mettre en œuvre les changements (BAI07) page 14
25. Gérer la connaissance (BAI08) page 14
26. Gérer les opérations (DSS01) page 14
27. Gérer les actifs (DSS02) page 14
28. Gérer les configurations (DSS03) page 14
29. Gérer les requêtes de service et les incidents (DSS04) page 14
30. Gérer les problèmes (DSS05) page 14
31. Gérer la continuité des affaires (DSS06) page 14
32. Gérer la sécurité de l’information (DSS07). page 14
33. Gérer les contrôles des processus métiers (DSS08) page 14
34. Surveiller et évaluer la performance et conformité (MEA01) page 14
35. Surveiller le système de contrôle interne (MEA02) page 14
36. Surveiller et évaluer la conformité avec les exigences externes (MEA03) page 14
III - Des objectifs d’entreprise au

système d’information de l’entreprise page 14

A. La cascade page 14
B. Un « système expert » très abordable page 14
C. Le tableau de bord équilibré (« balanced score card ») de la DSI page 14
IV - L’instanciation des processus CobiT page 14
A. Instancier les processus page 14

B. Quelles instanciations des processus ? page 14
V - CobiT et l’urbanisation du SI page 14

VI - Les acteurs page 14

A. Des « rôles » aux « acteurs » page 14
1. Déterminer les rôles et les structures de l’entreprise page 14
2. Comment exprimer le rapport de chaque rôle et / ou structure
aux pratiques de CobiT ? page 14
3. Rapprocher les rôles CobiT des définitions de fonction des
acteurs du système d’information de l’entreprise page 14
B. CobiT et la cartographie des compétences page 14
1. Le rapprochement par l’appellation des emplois-métiers page 14
2. Le rapprochement sur base des activités et des tâches de la
nomenclature et des processus et pratiques de CobiT page 14
3. La cartographie des compétences page 14
VII - Le comment page 14

A. La cartographie de la gouvernance du SI page 14
B. M. Jourdain et l’existant page 14
C. Principes et utilité des mappings page 14
D. Mappings classiques de CobiT vus par l’ITGI page 14
E. Mappings de CobiT avec des référentiels structurants fortement
utilisés en France page 14
1. CobiT & le « Modèle d’analyse et de benchmarking des coûts
informatiques du Cigref » page 14
2. EBIOS page 14
3. CobiT et le SI de la DSI (Cigref) page 14
VIII - Spécifications générales d’un outillage CobiT page 14
A. Base documentaire « standard » page 14

B. Gestion d’activités « standard » page 14
C. Gestion « standard » des indicateurs page 14
D. Les acteurs page 14
E. Les vues page 14

IX - Le cas d’affaire (« business case ») de CobiT page 14
A. Du côté des coûts… page 14

B. Du côté des bénéfices… page 14
X - CobiT et l’externalisation du SI page 14

A. CobiT est ce qui reste quand on a externalisé au maximum le SI page 14
B. CobiT et e-SCM page 14

I
Introduction
L’objectif de cette étude est d’assister les DSI dans l’utilisation de CobiT en tant qu’outil de base de la
mise en œuvre d’une gouvernance et d’une gestion opérationnelles du système d’information de leur
entreprise.
Le moment est opportun puisque, au moment de la première publication de cette étude (mars 2012) la
nouvelle version 5 de CobiT est en voie de publication et qu’elle s’inscrit résolument dans la perspective
d’être la référence mondiale sur le sujet.
Une première partie de cette étude sera consacrée à la présentation de la nouvelle version 5 en veillant
à adopter le point de vue du DSI. La seconde partie proposera quelques pistes concrètes de mise en
œuvre de la gouvernance et de la gestion du système d’information à partir de CobiT.
A. CobiT : un outil très opérationnel

Le DSI est depuis toujours à la recherche des processus qui assurent le fonctionnement de son système
d’information, à l’image des processus qui assurent le fonctionnement des métiers de l’entreprise.
Cette quête est d’autant plus forte de nos jours alors que plusieurs tendances se conjuguent :
• Le système d’information devient de plus en plus important dans les entreprises

• Le DSI évolue vers des fonctions ayant plus d’impact sur le cœur de métier de l’entreprise
• La pression augmente pour une utilisation plus efficiente des ressources du SI
• La prise en compte des risques liés au SI et leur gestion s’impose de plus en plus.
Aujourd’hui, il n’est plus nécessaire de mener de grandes recherches pour savoir que CobiT est la
réponse à ces enjeux.
Le débat utile aujourd’hui, par contre, portera sur comment faire vivre opérationnellement CobiT dans
le SI de l’entreprise. Cette étude s’inscrit résolument dans cette ligne.
B. Faire les bonnes choses et faire bien les choses

CobiT est un cadre de référence qui précise les objectifs à atteindre par tout SI d’une entreprise. Le
« OB» de CobiT signifie d’ailleurs « Objective ». Il est important à plusieurs égards de bien comprendre
que CobiT spécifie le Quoi (quel objectif atteindre) et qu’il laisse libre sur le Comment : quelle manière
utiliser pour y arriver. Retenons trois raisons qui justifie un tel besoin de compréhension.
C’est important d’abord parce que CobiT met ainsi l’accent sur « faire les bonnes choses » au regard
des objectifs et du contexte de l’entreprise et ne prend pas parti à propos de comment « faire bien les
choses ». La première proposition pèse plus lourd que la seconde dans l’appréciation finale du SI de
l’entreprise.

C’est important, ensuite, parce que cela signifie que chaque entreprise sera libre de déterminer
en fonction de son contexte quelle solution elle va utiliser afin d’atteindre chaque objectif fixé par
CobiT.
L’éventail de solutions à la disposition de l’entreprise étant de deux types :
• Soit adopter une méthode ou un standard réputé du marché et spécialisé dans l’atteinte de l’objectif
spécifique en question (par exemple Itil, CMMi, TOGAF…), type de solution qui explique l’utilité des
nombreux « mappings » existant entre CobiT et ces méthodes ou standards.
• Soit continuer d’utiliser ses pratiques propres développées en interne, si, bien évidemment, elles
sont jugées aptes à atteindre correctement les objectifs fixés par CobiT. Avec ce type de solution,
l’entreprise devra elle-même établir le lien avec CobiT, de la même manière que dans les « mappings »
cités plus haut, élevant ainsi les pratiques internes au rang de contributeurs à la gouvernance du système
d’information mettant ainsi à l’ordre du jour du système d’information la remarque de Monsieur Jourdain
(Cf VII B.).
C’est important, enfin, parce que cela détermine la structure du plan d’implantation de la gouvernance du
système d’information : d’une part, un plan global traitant tous les processus ensemble et indifféremment
et portant sur les aspects liés à « faire les bonnes choses ». D’autre part, un plan spécifique à chaque
objectif à atteindre expliquant comment « faire bien les choses ».
(Source : La balance « faire les bonnes choses », « faire bien les choses »,
exposé de Jean-Pierre Delvaux à l’ANDSI, janvier 2010).
C. Quelques vérités à rappeler…

Mais, avant tout, il est nécessaire de préciser quelques considérations qui traversent l’ensemble de cette
démarche.

1. De CobiT et du PDG
CobiT réserve au conseil d’administration et au Directeur Général l’autorité et la responsabilité de

plusieurs processus fondamentaux ; il indique également qu’ils doivent être consultés et informés sur
certains autres processus. Cette implication dans CobiT est à l’évidence la clé d’une gouvernance et
d’une gestion harmonieuse du SI de l’entreprise en ligne avec celle-ci.
Il appartient au DSI de mettre en place concrètement cette implication, progressivement en fonction

de la maturité des processus CobiT dans son entreprise. Le DSI doit comprendre cela comme une
opportunité majeure pour lui d’être celui qui contribue à aligner l’entreprise et son SI.
2. De CobiT et des directions des métiers
Il est pour principe fondamental que la gouvernance et la gestion du SI de l’entreprise ressortent de la

responsabilité du conseil d’administration des dirigeants de l’entreprise. Les directions des métiers sont
donc, par essence, des parties prenantes de CobiT. Dans le même ordre d’idée, les propriétaires des
processus des métiers sont également des parties prenantes incontournables de tout fonctionnement
harmonieux de CobiT.
Il est de bon conseil d’utiliser CobiT, vu sa notoriété dans le monde du management de l’entreprise,
comme vecteur pour amener les directions des métiers et leurs collaborateurs à s’investir dans les rôles
qui leurs sont spécifiés par CobiT, aidant ainsi à désamorcer l’incompréhension qui pourrait exister
entre la DSI et les métiers.
3. De CobiT et du DSI
Le DSI doit être le sponsor de la démarche CobiT de l’entreprise. C’est la ligne dans laquelle cette étude est
conçue. Les statistiques montrent qu’une autre approche existe, celle dans laquelle le PDG ou le directeur
financier en sont le sponsor. (Voir la statistique dans IT Governance Global Status Report—2008, ITGI).
Exprimé de manière sobre, il est préférable pour le DSI d’être dans cette première situation.
4. De CobiT et de l’entreprise
CobiT est un rappel permanent à la finalité du système d’information, à savoir être au service de
l’entreprise. Une implantation donnée de CobiT n’a de sens que par rapport à une entreprise et par
rapport au SI de celle-ci. Il n’est donc pas imaginable d’implanter CobiT « in abstracto », sans référence
à une entreprise donnée.
Ceci peut sembler être une lapalissade, mais il est utile d’y regarder de plus près dans le cadre de
l’externalisation informatique. Ainsi, si une entreprise décide d’externaliser certaines parties ou certaines
fonctions de son système d’information, elle conserve évidemment l’autorité sur l’ensemble des processus
CobiT de son système d’information.
Pour reprendre le questionnement du Quoi et du Comment, l’entreprise a toujours en charge le Quoi

et le sous-traitant prend en charge le Comment. A la limite, et de manière évidemment caricaturale,
CobiT est ce qui reste du système d’information dans l’entreprise quand celle-ci l’a externalisé au
maximum.
En ce qui concerne le sous-traitant, il est évidemment judicieux de proposer ses services en conformité
avec un standard reconnu du marché propre à ce service en question, par exemple CMMI pour du
développement externalisé de logiciel. Et cette conformité du sous-traitant avec un standard n’est en

rien une alternative ou une concurrence au fonctionnement de CobiT du donneur d’ordre. Ceci explique
donc que CobiT n’est logiquement jamais proposé par les prestataires de services (sauf les cabinets de
conseil et les cabinets d’audit, évidemment…) pour accompagner leurs prestations de service, ce qui
place le DSI dans l’obligation d’endosser le rôle d’initiateur et de sponsor de la démarche CobiT dans
son entreprise, et de se retrouver souvent fort esseulé dans ce rôle.
Et si le sous-traitant lui-même utilise CobiT, ce qui est judicieux également, c’est par rapport au
fonctionnement de son système d’information propre et non par rapport aux services qu’il met à
disposition de ses clients… Ce rapport de CobiT à l’externalisation s’applique évidemment aussi au
« cloud computing » que les analystes nous annoncent en progression exponentielle.
5. De CobiT et de l’entreprise (bis)
Outre les entreprises, CobiT s’adresse également au secteur public, aux ONG… Dans ce cas il est
nécessaire d’adapter plus en profondeur au contexte les objectifs métiers prévus en standard par CobiT
ainsi que leurs liens avec es processus CobiT.
6. De CobiT et des processus
De même que les processus métiers structurent le fonctionnement des métiers de l’entreprise, ce sont
les processus CobiT qui structurent le fonctionnement de la gouvernance et de la gestion du SI.
Les processus CobiT constituent donc l’entité de base de toute mise en œuvre. Il est nécessaire d’y insister
car il est souvent constaté, soit dans des démarches d’implantation, soit dans des démarches d’audit, que
CobiT est réduit à une grande collection d’objectifs de contrôle négligeant ainsi sa dimension processus
et toute la dynamique et toute la cohérence qui sont associées à ce concept.
7. Du caractère international de CobiT
CobiT est connu et reconnu dans toutes les régions du monde et est traduit dans de nombreuses langues.
Ceci est évidemment important en termes de crédibilité pour CobiT mais c’est en outre un facilitateur
pour les DSI d’entreprises ayant des filiales à l’étranger puisqu’ils peuvent s’appuyer sur les traductions
locales pour améliorer la compréhension commune d’un même cadre de référence et pour faciliter son
implantation dans l’ensemble du groupe.
8. De l’adaptabilité de CobiT à la culture française et aux modes français

de gestion d’un système d’information
Au-delà de la traduction en français de CobiT (assurée officiellement par l’AFAI), il est important de
constater que l’apport de la culture française à la gestion du SI se conjugue parfaitement avec CobiT
pour former un ensemble particulièrement efficace.
C’est un point de vue peu, voire pas, développé dans les approches rencontrées habituellement, sur
lequel l’accent sera mis dans cette étude. Ce sera le cas par exemple avec la nomenclature des emplois-
métiers du système d’information publiée par le CIGREF, avec le concept d’urbanisation du système
d’information, avec la méthode EBIOS de l’ANSSI (Agence nationale pour la sécurité des systèmes
d’information) qui permet d’apprécier et de traiter les risques …

9. De CobiT et des entreprises de taille moyenne
Trop souvent, CobiT est connoté « grande entreprise uniquement ». Même s’il est vrai et parfaitement
compréhensible que CobiT rencontre le succès dans les grandes entreprises, il est nécessaire de souligner
que de nombreuses entreprises de tailles plus modestes également adoptent CobiT.
Un rapport récent de l’ISACA et de l’IT Governance Institute (« Global Status Report on the Governance
of Enterprise IT (Geit) - 2011 ») est éloquent à cet égard. Il montre l’engagement des entreprises de
taille moyenne (dans cette étude la frontière entre grandes entreprises et petites entreprises est fixée
à 500 collaborateurs pour l’ensemble de l’entreprise) au regard des questions de gouvernance du SI,
même si les scores y sont en retrait par rapport aux scores des grandes entreprises. Cette étude est donc
conçue pour s’adresser aussi bien aux DSI d’entreprises de taille moyenne qu’à ceux d’entreprises de
grande taille.
10. De CobiT et des technologies
CobiT est technologiquement agnostique. Quelles que soient les technologies utilisées par le système
d’information, CobiT constituera le cadre de référence de leur gestion. Bien évidemment, décliner
des implantations différentes selon les technologies utilisées sera nécessaire.
Il y a des différences, sur certains points, entre CobiT décliné dans un univers Web Services, CobiT
décliné dans un univers client/serveur ou CobiT décliné dans un univers mainframe… La même remarque
s’applique pour l’univers (en expansion…) du « cloud computing », dans la mesure où il peut être
considéré comme un univers technologique.
11. De CobiT et de l’audit informatique
Bien qu’issu originellement du monde de l’audit informatique, CobiT a été accaparé au fil du temps
par les DSI et c’est dans cette ligne que s’inscrit le présent livre. CobiT est maintenant (déjà depuis la
version 4 en fait) officiellement orienté par construction vers les DSI et les directions des métiers.
Cela étant, il est heureux que CobiT réunisse les deux démarches, celle des gestionnaires et celle des
auditeurs, qui sont liées comme les deux faces d’une pièce de monnaie.
12. De CobiT, de sa complétude et de son caractère non prescriptif
CobiT définit et décrit tous les processus de gouvernance et de gestion du système d’information qui
existent normalement dans une entreprise. Cela étant, il appartient à chaque entreprise de décliner son
implantation en fonction de son contexte et de ses objectifs. C’est un objectif de ce livre que d’aider le
DSI dans cette voie.
13. De CobiT et du TBE (Tableau de Bord Equilibré / Balanced Score Card)
Il n’y a pas de processus sans métrique. CobiT propose ses propres métriques intrinsèquement liées à ses
processus. Définir une mise en œuvre de CobiT, c’est donc aussi automatiquement définir les métriques
du SI et donc son Tableau de Bord Equilibré (TBE). Entreprendre une démarche visant à mettre en place
un TBE du système d’information séparée de CobiT est redondante et donc source d’incohérence.

II
Les principes de CobiT V5

A. Le caractère non encore achevé de la Version 5
CobiT V5 est présenté ici sur base des documents publiés à la date de finalisation de cette étude (février
2012) par l’ISACA ; ils le sont en « exposure draft », ce qui signifie bien évidemment que des améliorations,
changements, adaptations peuvent encore être intégrés dans la future version officielle.
Ces documents de l’ISACA sont en anglais, les quelques traductions en français dans le cadre de ce livre
sont de l’auteur et ne sont donc pas certifiées. L’AFAI, chapitre français de l’ISACA, prendra en charge la
traduction officielle et complète comme elle l’a fait jusqu’à présent pour les versions plus anciennes.
B. La fusion CobiT / RiskIT / ValIT

Une avancée importante de la V5 de CobiT est l’intégration dans une même structure de plusieurs
anciens standards : CobiT V4.1 bien évidemment mais également ValIT et RiskIT.
ValIT est un modèle qui vise essentiellement à mettre en évidence la valeur au regard des métiers générée
par les investissements dans l’informatique, à veiller à sélectionner les projets informatiques sur cette
base et à contrôler que les bénéfices attendus sont effectivement réalisés. A l’évidence, ValIT s’adresse
autant aux directeurs des métiers, parmi lesquels il a gagné crédibilité et reconnaissance, qu’aux DSI.
La logique de couverture complète par CobiT de l’ensemble des processus du SI a mené à l’intégration
de ValIT. Les principaux processus de CobiT V5 reprenant les fonctionnalités de ValIT sont les
suivants :
• EDM01 (Établir et de maintenir le cadre de gouvernance)

• EDM02 (Assurer l’optimisation de la valeur)
• APO05 (Gérer le portefeuille)
• BAI01 (Gérer les programmes et les projets).
RiskIT est un modèle qui vise à établir la gouvernance du risque lié au système d’information, à évaluer
ce risque et à y répondre.
RiskIT comprend également un générateur de scénarios de risques (liés au système d’information),

le concept de carte des risques système d’information, les indicateurs clés de risque… qui restent de
grande utilité.
RiskIT, méthode plus récente que CobiT, a obtenu rapidement une bonne notoriété parmi les directions des
métiers et parmi les DSI, confirmée par des scores élevés dans les statistiques sur l’usage des méthodes.
Toujours dans la logique de couverture complète du SI, les principaux processus de CobiT V5
reprenant les fonctionnalités de RiskIT sont les suivants :

• EDM3 (Assurer l’optimisation du risque)
• APO12 (Gérer les risques).
C. Des processus de gouvernance et des processus de gestion

La confusion entre gouvernance et gestion est souvent forte. CobiT V5 met fin à toute ambiguïté sur le
sujet en séparant les processus de gouvernance (domaine EDM : Evaluer, Diriger & Surveiller) d’une
part, des processus de gestion, d’autre part (domaines APO, BAI, DSS, MEA voir ci-dessous).
• Les processus de gouvernance (EDM) contiennent chacun trois pratiques de gouvernance :
• Evaluer
• Diriger
• Surveiller
• Les processus de gestion sont répartis en quatre domaines :
• Planifier : APO
• Construire : BAI
• Opérer : DSS
• Surveiller : MEA
D. La structure de CobiT V5

L’objectif étant de piloter et de contrôler le système d’information de l’entreprise en s’appuyant sur
CobiT, il est nécessaire de bien en comprendre d’abord la structure d’ensemble.

A cet effet, il est utile d’en mettre en évidence les principaux éléments constitutifs ainsi que leurs
relations ; c’est une approche de type diagramme entité-association qui sera utilisée.
1. Les processus
Le processus est l’élément central à prendre en considération dans toute mise en application ; ce n’est
pas par hasard qu’il a été placé au centre du diagramme. CobiT V5 en a identifié 36 qui sont présentés
dans le tableau ci-dessous.
Il y a les quatre processus de Governance qui sont regroupés dans le domaine EDM.

Il y a les 32 processus de Gestion regroupés dans quatre domaines : APO, BAI, DSS, MEA.
La traduction des noms de domaine en français a été faite de manière telle à préserver les abréviations
les désignant en anglais.
Chaque processus est accompagné dans CobiT:
• D’un identifiant (abréviation du nom de domaine) et d’un numéro. (Par exemple BAI04).
• D’un nom de processus : il désigne le sujet principal du processus.
• D’une courte description.
Noms des domaines Abréviations

Evaluer, Diriger & Surveiller EDS Evaluate, Direct & Monitor
Aligner, Planifier & Organiser APO Align, Plan & Organise
Bâtir, Acquérir & Implémenter BAI Build, Acquire & Implement
Délivrer, Servir & Supporter DSS Deliver, Service & Support
Monitorer, Evaluer & Apprécier MEA Monitor, Evaluate & Assess
2. Les pratiques de gestion et de gouvernance
Chaque processus est constitué de quelques pratiques, de gouvernance pour les processus du domaine
EDM et de gestion pour les autres. Il y a au total 208 pratiques (15 de gouvernance et 193 de gestion),
soit en moyenne environ six pratiques par processus.
Elles sont réparties de la manière suivante en fonctions des domaines :
• EDM : 15
• APO : 70
• BAI : 57
• DSS : 49
• MEA :17
Chaque pratique est accompagnée :
• D’une identification constituée de l’identifiant du processus et d’un numéro de série.

(Par exemple BAI04.02).
• Du titre de la pratique.
• D’une courte description.

Processus CobiT
Domaines Identifiants Libellés
EDM - Evaluer, Diriger & Surveiller
EDM01 Établir et de maintenir le cadre de gouvernance
EDM02 Assurer l’optimisation de la valeur
EDM03 Assurer l’optimisation du risque
EDM04 Assurer l’optimisation des ressources
EDM05 Assurer la transparence pour les parties prenantes
APO - Aligner, Planifier & Organiser
APO01 Définir le cadre de gestion du SI
APO02 Définir la stratégie
APO03 Gérer l’architecture d’entreprise
APO04 Gérer l’innovation
APO05 Gérer le portefeuille
APO06 Gérer les budgets et les coûts
APO07 Gérer les ressources humaines
APO08 Gérer les relations
APO09 Gérer les Accords de service
APO10 Gérer les fournisseurs
APO11 Gérer la qualité
APO12 Gérer les risques
BAI - Bâtir, Acquérir & Implémenter
BAI01 Gérer les programmes et les projets
BAI02 Définir les exigences
BAI03 Identifier et construire les solutions
BAI04 Gérer la disponibilité et la capacité
BAI05 Faciliter le changement organisationnel
BAI06 Gérer les changements
BAI07 Accepter et mettre en œuvre les changements
BAI08 Gérer la connaissance
DSS - Délivrer, Servir & Supporter
DSS01 Gérer les opérations
DSS02 Gérer les actifs
DSS03 Gérer les configurations
DSS04 Gérer les requêtes de service et les incidents
DSS05 Gérer les problèmes
DSS06 Gérer la continuité des affaires
DSS07 Gérer la sécurité de l’information
DSS08 Gérer les contrôles des processus métiers
MEA - Monitorer, Evaluer & Apprécier
MEA01 Surveiller et évaluer la Performance et conformité
MEA02 Surveiller le système de contrôle interne
MEA03 Surveiller et évaluer la conformité avec les exigences externes

Il est fondamental de bien comprendre que les pratiques définissent des objectifs à atteindre et non les
solutions pour les atteindre. En d’autres termes, ce sont des QUOI et pas des COMMENT.
Même s’il est tentant de considérer la pratique (de gouvernance ou de gestion) comme élément de base
dans le fonctionnement de CobiT, il est hautement recommandable de baser le fonctionnement sur les
processus et de considérer celles-ci comme des composantes du processus. Cette tentation, qu’il est hélas
souvent possible d’observer sur le terrain, fait l’impasse sur toute la dynamique liée aux processus.
3. Les activités
A chaque pratique sont associées un certain nombre d’activités qui sont des guides pour atteindre les
objectifs des pratiques de gestion et de gouvernance du SI de l’entreprise.
Ces activités :
• Sont orientées action

• Sont en ligne avec les entrées et sorties de la pratique
• Sont basées sur des meilleurs pratiques généralement reconnues
• Doivent être adaptées au contexte de l’entreprise
• Précisent, comme il a été souvent souligné, le QUOI et non le COMMENT
• Sont prévues pour s’adapter à la distribution des rôles prévue pour chaque pratique.
Il y a généralement cinq à dix activités par pratique de gestion ou de gouvernance. Vu leur nombre
élevé, et leur granulométrie fine, leur traduction n’est pas prévue dans le cadre du présent travail. Mais
elles pourront constituer à l’évidence une aide fortement utile dans le cadre de la mise en œuvre des
pratiques correspondantes.
4. Les livrables des pratiques
Des processus fonctionnent parce que les personnes en charge de les faire fonctionner émettent et
reçoivent des informations.
CobiT définit les informations que la bonne mise en œuvre de chaque pratique de gestion et de chaque
pratique de gouvernance est censée produire. En fait CobiT définit l’appellation de l’information en
question mais il n’en détaille pas le contenu.
C’est un constituant clé de la mise en œuvre opérationnelle de CobiT qui mérite un examen plus
approfondi.
Pour chaque pratique de gestion et de gouvernance, CobiT spécifie les informations suivantes :
• Les informations en sortie de la pratique, avec leur destination

• En interne du processus en question
• Un autre processus de CobiT
• La gestion des affaires de l’entreprise hors SI et donc hors CobiT.
• Les informations en entrée de la pratique, avec leur origine
• En interne du processus en question
• Un autre processus de CobiT
• La gestion des affaires de l’entreprise hors SI et donc hors CobiT.

Exemple
Processus APO12 : Gérer les risques
Pratique de Gestion APO12.01 : Collecter les données
(Identifier et collecter les données significatives pour permettre l’identification, l’analyse et le reporting
efficaces des risques liés à l’IT)
Identification de l’information Entrée / Sortie De / Vers
de APO12.01
Données liées au risque sur l’environnement opérationnel. Sortie Interne
Données sur les événements à risque et leurs facteurs Sortie Interne
contributifs.
Questions et facteurs de risque émergents. Sortie Vers APO01.03
Vers APO02.02
Vers EDM03.01
Rapport de situation et des tendances des incidents. Entrée De DSS04.07
Evaluation des activités de gestion du risque. Entrée De EDM03.01
Processus approuvés pour mesurer la gestion du risque. Entrée De EDM03.02
Objectifs clés à superviser pour la gestion du risque. Entrée De EDM03.02
Règles de gestion du risque. Entrée De EDM03.02
Vu leur importance, chacune de ces entités informationnelles sera présentée dans le chapitre
consacré aux principaux éléments de CobiT V5.
A titre d’exemple, figure ci-dessous le détail de ce qui est spécifié par CobiT, au regard de cette question
de la circulation de l’information, pour une pratique choisie au hasard : APO12.01.
Il convient d’être conscient qu’il ne faut pas prendre au pied de la lettre cette question de la circulation
de l’information et ne s’engager dans la mise en place d’un processus que si l’information en entrée
est disponible, fiable, à jour… parce que c’est la meilleure manière de créer un système autobloquant.
Il faudra donc veiller, dans les premières étapes de fonctionnement d’un processus, à prévoir son
fonctionnement en disposant d’informations partielles en entrée.
5. Les responsabilités des pratiques
CobiT définit pour chaque pratique de gestion et pour chaque pratique de gouvernance quelles sont
les responsabilités de l’ensemble des parties prenantes.
Ces parties prenantes sont définies de manière générique dans CobiT ; le tableau ci-dessous en précise
la liste.

Les parties prenantes du SI
Extérieur à Board Conseil d’administration
la DSI CEO PDG
CFO Directeur des finances
COO Directeur des opérations
Business Executives Directeurs des métiers
Business Process Owners Propriétaires des processus métiers
Strategy Executive Committee Comité Exécutif de la Stratégie
Steering (Programmes/Projects) Comité directeur (Programmes / Projets)
Committee
Chief Risk Officer Directeur des Risques
Chief Information Security Officer Directeur de la sécurité de l’information
Architecture Board Comité d’architecture
Enterprise Risk Committee Comité des risques d’entreprise
HR Directeur des ressources humaines
Compliance Conformité
Audit Audit
Interne DSI CIO DSI
Head Architect Responsable de l’architecture
Head Development Responsable des développements
Head IT Operations Responsable des opérations IT
Head IT Administration Responsable de l’administration IT
Project Management Office Bureau projet
Value Management Office Bureau gestion de la valeur
Service Manager Responsable des services
Information Security Manager Responsable de la sécurité de l’information
Business Continuity Manager Responsable de la continuité des affaires
Privacy Officer Responsable de la protection de la vie privée
Il est important de remarquer que :

• Certaines parties prenantes sont internes à la DSI, d’autres sont externes à la DSI
• Certaines parties prenantes sont en fait des comités.
Cette responsabilité des parties prenantes par rapport à chacune des pratiques de gestion et des pratiques
de gouvernance s’exprime dans CobiT sous la forme RACI (Responsable, « Accountable », Consulté,
Informé).
Dans le diagramme des entités-relations, ceci est représenté par « Rôles & Comités », d’une part, et
« Responsabilités des pratiques », d’autre part.

6. Mapping avec CobiT V4.1, ValIT, RiskIT
Comme à l’occasion de chaque nouvelle version, CobiT spécifie la correspondance entre la nouvelle
version et l’ancienne.
Dans ce cas de la nouvelle Version 5, il est important de se rappeler qu’elle est non seulement le
successeur de CobiT V4.1, mais qu’elle succède également à ValIT et à RiskIT. Le mapping de la nouvelle
V5 intègre évidemment cette situation.
Le mapping est détaillé, au niveau de chaque pratique de gestion et de gouvernance, correspondant

aux anciens objectifs de contrôle des versions antérieures.
7. Mapping avec Itil, TOGAF, PMBOCK, PRINCE2, ISO.
Ces mappings de la V5 seront publiés ultérieurement par l’ISACA.

Pour l’instant il est aisé de réaliser les mappings souhaités en se basant sur ceux proposés pour les
versions antérieures (Voir chapitre VII sur les mappings).
8. La cascade
CobiT définit les entités suivantes reliées entre elles dans une démarche de type « cascade » :
• Les objectifs système d’information d’entreprise.

• Les objectifs d’entreprise.
• Les Métriques métiers d’entreprise.
• Les métriques système d’information d’entreprise.
Cette cascade permet d’assurer le lien entre les objectifs d’entreprise et les processus CobiT.
9. Les objectifs des processus et leurs métriques
A chaque processus sont associés quelques objectifs qui leur sont spécifiques. Ces objectifs permettent
d’adapter la compréhension, et la mise en œuvre, du processus au contexte de l’entreprise.
A chaque objectif sont associées deux ou trois métriques.
Il ne faut pas confondre les objectifs qui sont spécifiques à un processus donné (et leurs métriques)
avec les objectifs système d’information d’entreprise (et leurs métriques) qui sont définis sur l’ensemble
du système d’information.
E. De la maturité à la capabilité….

1. De la maturité des processus CobiT…
Depuis de nombreuses années, et jusqu’à la Version 4.1, c’est le concept de maturité qui était la base
de l’évaluation de la qualité de la mise en œuvre des processus.
La maturité était basée sur les attributs de la maturité (voir ci-dessous), le modèle de maturité générique
(voir également ci-dessous) et sur une déclinaison de celui-ci propre à chaque processus.
De plus, des enquêtes de grande envergure auprès d’entreprises utilisatrices de CobiT ont été menées

et ont permis d’établir des statistiques sur la maturité en fonction du processus concerné, de la taille
d’entreprise, du secteur d’activité…
Les attributs de la maturité sont les suivants :

• sensibilisation et communication
• politiques, plans et procédures
• outils et automatisation
• compétences et expertise
• responsabilité opérationnelle et responsabilité finale,
• désignation des objectifs et métriques.
Le modèle de maturité générique comprend les éléments suivants :
• Niveau 0 (Inexistant) : Absence totale de processus identifiables. L’entreprise n’a même pas pris
conscience qu’il s’agissait d’un problème à étudier.
• Niveau 1 (Initialisé/Cas par cas) : On constate que l’entreprise a pris conscience de l’existence
du problème et de la nécessité de l’étudier. Il n’existe toutefois aucun processus standardisé, mais
des démarches dans ce sens tendent à être entreprises individuellement ou cas par cas. L’approche
globale du management n’est pas organisée.
• Niveau 2 (Reproductible mais intuitif) : Des processus se sont développés jusqu’au stade où des
personnes différentes exécutant la même tâche utilisent des procédures similaires. Il n’y a pas de
formation organisée ni de communication des procédures standard et la responsabilité et laissée à
l’individu. On se repose beaucoup sur les connaissances individuelles, d’où un risque d’erreurs.
• Niveau 3 (Processus défini) : On a standardisé, documenté et communiqué des processus via des
séances de formation. Ces processus doivent impérativement être suivis ; toutefois, des écarts seront
probablement constatés. Concernant les procédures elles-mêmes, elles ne sont pas sophistiquées
mais formalisent des pratiques existantes.
• Niveau 4 (Géré et mesurable) : La direction contrôle et mesure la conformité aux procédures

et agit lorsque certains processus semblent ne pas fonctionner correctement. Les processus sont en
constante amélioration et correspondent à une bonne pratique. L’automatisation et les outils sont
utilisés d’une manière limitée ou partielle.
• Niveau 5 (Optimisé) : Les processus ont atteint le niveau des bonnes pratiques, suite à une
amélioration constante et à la comparaison avec d’autres entreprises (Modèles de Maturité).
L’informatique est utilisée comme moyen intégré d’automatiser le flux des tâches, offrant des outils
qui permettent d’améliorer la qualité et l’efficacité et de rendre l’entreprise rapidement adaptable.
2. à la capabilité des processus CobiT
La raison d’être de ce changement est la volonté de se conformer à la norme ISO/IEC (15504 en

l’occurrence).
L’objectif du modèle d’évaluation basé sur la capabilité est de fournir une évaluation rigoureuse, objective
et répétable. Les critères du modèle d’évaluation utilisant la capabilité sont plus précis que ceux du
modèle utilisant la maturité. L’approche de la maturité impliquait d’émettre un jugement, avec des
résultats fortement dépendants de la personne faisant le jugement.

Il apparaît immédiatement que la capabilité d’un processus est nettement plus exigeante que sa maturité,
notamment pour les niveaux les plus bas. Il n’y a donc pas d’équivalence entre les niveaux 1 et 2 des
deux systèmes. Il n’y aura donc pas de continuité dans les statistiques ou un benchmark…
Cette transition, de la maturité à la capabilité, qui est maintenant lancée mais n’en est qu’à ses débuts,
est certainement un changement majeur pour les acteurs de la gouvernance du SI ; c’est aussi une
opportunité pour ceux-ci de lancer (ou relancer) une démarche de mise en œuvre avec des ambitions
d’efficacité revues à la hausse.
On remarquera que :
• Structurellement, les attributs de la capabilité sont propres à un niveau de capabilité alors que
les attributs de la maturité étaient déclinés à tous les niveaux de la maturité.
• Obtenir un niveau de capabilité exige que le niveau de capabilité inférieur soit complètement
atteint.
• Il n’y a conceptuellement pas de déclinaison de la capabilité spécifique à chaque processus

au-dessus du niveau 1.
Modèle générique de capabilité

Comparatif avec le Niveaux Capabilité Signification des niveaux
niveau de maturité de (Basé sur de capabilité basés sur Contexte
(CobiT V4.1) Capabilité ISO 15504) ISO 15504
5. Optimisé 5 Processus Continuellement amélioré Vue d’entreprise.
optimisé pour rencontrer les objectifs Connaissance
d’entreprise pertinents d’entreprise
actuels et projetés
4. Géré & mesuré 4 Processus Fonctionne dans des limites
prédictible définies pour réaliser ses
résultats de processus
3. Défini 3 Processus Implanté en utilisant un
établi processus défini qui est
capable de réaliser ses
résultats de processus
- 2 Processus Implanté d’une manière Vue au cas par cas.
géré gérée (planifié, surveillé Connaissance
et ajusté) et ses livrables individuelle
sont établis de manière
appropriée, contrôlés et
maintenus
- 1 Processus Réalise son but de
effectué processus
2. Reproductible 0 Processus Pas implanté ou peu ou pas
mais intuitif incomplet. de preuve de réalisation
1. Initialisé, cas par cas systématique des buts du
0. Inexistant processus

Les attributs des processus par niveau de capabilité
Niveaux de Capabilité Identifiants Attributs
Capabilité (Basé sur ISO 15504) des attributs
5 Processus optimisé PA5.1 Innovation du processus
PA5.2 Optimisation continue
4 Processus prédictible PA4.1 Mesure du processus
PA4.2 Contrôle du processus
3 Processus établi PA3.1 Définition du processus
PA3.2 Déploiement du processus
2 Processus géré PA2.1 Gestion de l’exécution
PA2.2 Gestion des livrables
1 Processus effectué PA1.1 Exécution du processus
0 Processus incomplet
Le modèle d’évaluation basé sur la capabilité, applicable à la V5 de CobiT mais non encore détaillé par
l’ISACA, a déjà en fait été proposé pour la V4.1 (Voir: « CobiT Process Assessment Model (PAM) using
CobiT 4.1. » ISACA) qui sert de base pour la présentation qui suit.
Le niveau 1 de la capabilité est le seul à avoir une déclinaison spécifique à chaque processus CobiT.
• Les pratiques de base.
• Elles sont en fait déterminées par les Objectifs de Contrôle (V4.1).
• Elles sont spécifiques à chaque processus CobiT.
• Les livrables.
• Ce sont les livrables spécifiés par CobiT.
• En entrée et en sortie.
• Ils sont spécifiques à chaque processus CobiT.
• CobiT les identifie; le modèle de capabilité y ajoute une description de chaque livrable.
• Cela inclut la circulation des livrables
• Entre processus: V4.1.
• Entre pratiques de gestion: V5.
Pour les niveaux supérieurs (de 2 à 5), il n’y a donc pas de déclinaison spécifique à chaque
processus. Il y a par contre des pratiques et des livrables génériques.

Les pratiques génériques
Pratiques génériques Résultat de la réalisation complète de l’attribut Livrable
Niveau 2
PA2.1. Gestion de l’exécution

GP2.1.1 Les objectifs de l’exécution du processus sont identifiés 1.0
2.0
GP2.1.2 L’exécution du processus est planifiée et surveillée 2.0
9.0 (-)
GP2.1.3 L’exécution du processus est ajustée pour satisfaire les plans 4.0
GP2.1.4 Responsabilités et autorités pour exécuter le processus sont définies, assignées et 1.0
communiquées 2.0
GP2.1.5 Ressources et information nécessaire pour exécuter le processus sont identifiées, 2.0
rendues disponibles, allouées et utilisées
GP2.1.6 Les interfaces entre les parties impliquées sont gérées pour assurer une communication 1.0
effective et une assignation claire des responsabilités 2.0
PA2.2. Gestion des livrables
GP2.2.1 Les exigences pour les livrables sont définies 3.0
GP2.2.2 Les exigences pour la documentation et le contrôle des livrables sont définis 1.0
3.0
GP2.2.3 Les livrables sont identifiés de manière appropriée, documentés et contrôlés 3.0
GP2.2.4 Les livrables sont revus en accord avec les dispositions planifiées et ajustés si 4.0
nécessaire pour satisfaire les exigences
Niveau 3
PA3.1 Définition du processus

GP3.1.1 Un processus standard, incluant des directives appropriées de façonnage, est défini qui 5.0
décrit les éléments fondamentaux qui doivent être incorporés dans le processus défini
GP3.1.2 La séquence et interaction du processus standard avec les autres processus est 5.0
déterminée
GP3.1.3 Les compétences requises et les rôles pour exécuter un processus sont identifiés 5.0
comme faisant partie du processus standard
GP3.1.4 L’infrastructure requise et l’environnement de travail pour exécuter le processus sont 5.0
identifiés comme faisant partie du processus standard
GP3.1.5 Des méthodes qui conviennent pour surveiller l’efficacité et la pertinence du processus 5.0
sont déterminées 4.0
PA3.2 Déploiement du processus
GP3.2.1 Un processus défini est déployé basé sur un sélectionné et/ou standard façonné 5.0
processus
GP3.2.2 Les rôles requis, responsabilités et autorités pour exécuter le processus défini sont 5.0
assignés et communiqués
GP3.2.3 Les personnels exécutant le processus défini sont compétents sur la base d’une 1.0
éducation, d’un entrainement et d’une expérience appropriés 2.0
GP3.2.4 Les ressources requises et les informations nécessaires pour exécuter le processus 2.0
défini sont rendues disponibles, allouées et utilisées
GP3.2.5 L’infrastructure et l’environnement de travail requis pour exécuter le processus défini 2.0
sont rendus disponibles, gérés et maintenus.
GP3.2.6 Les données appropriées sont collectées et analysées comme des bases pour 4.0
comprendre le comportement du processus, pour démontrer sa pertinence et son
efficacité, et pour évaluer où une amélioration continue du processus peut être faite.

Les pratiques génériques
Pratiques génériques Résultat de la réalisation complète de l’attribut Livrable
Niveau 4
PA4.1Mesure du processus
GP4.1.1 Les besoins en information du processus en support aux objectifs métiers pertinents 6.0
définis sont établis
GP4.1.2 Les objectifs de mesure du processus sont définis à partir des besoins en information 7.0
du processus
GP4.1.3 Les objectifs quantitatifs pour la performance du processus en support aux objectifs 7.0
métiers correspondants sont établis
GP4.1.4 Les mesures et les fréquences de mesure sont identifiées et définies en ligne avec 7.0
les objectifs de mesure du processus et les objectifs quantitatifs de performance du
processus
GP4.1.5 Les résultats des mesures sont collectés, analysés et rapportés de manière à surveiller 7.0
à quel point les objectifs quantitatifs pour la performance du processus sont rencontrés 9.0
GP4.1.6 Les résultats des mesures sont utilisés pour caractériser la performance du processus 9.0
PA4.2 Contrôle du processus
GP4.2.1 Des techniques d’analyse et de contrôle sont déterminées et appliquées si possible 1.0
8.0
GP4.2.2 Le contrôle des limites de variation sont établis pour une exécution normale du 8.0
processus
GP4.2.3 Les données des mesures sont analysées pour les causes spéciales de variation 9.0
GP4.2.4 Des actions correctives sont prises pour s’atteler aux causes spéciales de variation 9.0
GP4.2.5 Le contrôle des limites sont ré-établis (si nécessaire) suivant les actions de correction 8.0
Niveau 5
PA5.1 Innovation du processus

GP5.1.1 Les objectifs du processus d’amélioration du processus sont définis de manière à 7.0
supporter les objectifs métiers correspondants
GP5.1.2 Les données appropriées sont analysées pour identifier les causes communes de 9.0
variation dans la performance du processus
GP5.1.3 Les données appropriées sont analysées pour identifier les opportunités des meilleures 6.0
pratiques et d’innovation
GP5.1.4 Les opportunités d’amélioration dérivées des nouvelles technologies et des concepts 6.0
du processus sont identifiés
GP5.1.5 Une stratégie d’implantation est établie pour atteindre les objectifs d’amélioration du 6.0
processus
PA5.2 Optimisation continue
GP5.2.1 L’impact de tous les changements proposés est évalué au regard des objectifs du 6.0
processus défini et du processus standard
GP5.2.2 L’implantation de tous les changements agréés est gérée pour assurer que toute 6.0
discontinuité de la performance du processus est comprise et actée (1.0, 3.0, 5.0))
GP5.2.3 Basé sur la performance actuelle, l’efficacité du changement du processus est évaluée 6.0
au regard des exigences définies et des objectifs du processus pour déterminer si les
résultats sont dus à des causes communes ou spéciales

Livrables génériques
Pratique
Libellé Contenu Générique Commentaires
liée
1.0 Documentation du Nom du processus
processus Propriétaire du processus GP2.1.4 La personne responsable du design du processus. Cela
inclut être responsable pour la création, la mise à jour et
l’approbation des documents (procédures, instructions
de travail, protocoles) pour supporter le processus
Etendue du processus GP2.1.1 Une déclaration claire de où commence et finit le
processus
Rôles des processus GP2.1.6 Détaille les rôles clés du processus:
• Les fournisseurs et leurs entrées.
• Les clients et leurs sorties
Carte du processus GP3.1.2 Généralement, dans la forme d’un dessin schématique
de processus pour montrer le flux séquentiel de travail.
Dans la plupart des cas, il y aura une carte montrant le
flux au travers plusieurs processus
Tableau RACI GP2.1.4 Identifie qui est responsable, a l’autorité, est consulté
GP2.1.6 et informé par rapport à chacune des activités clés du
processus
Matrice de contrôle interne GP2.2.2 Matrice montrant les risques identifiés dans le processus
ensemble avec les contrôles identifiés
Procédures du processus GP3.1.1 Un document définissant les activités requises pour
réaliser les résultats requis du processus
2.0 Planification du Objectifs de performance GP2.1.1 Variera, en fonction du processus. Cependant il doit
processus du processus GP2.1.2 y avoir des indices de cibles tels que jalons, activités
requises, estimation des volumes ou calendriers des
livrables
Acquisition des ressources GP2.1.5 Un plan indiquant les ressources et les informations
du processus GP3.2.4 requises pour rencontrer la performance requise pour le
processus, et des informations sur ce que les ressources
doivent fournir
Communication du GP2.1.4 Un plan pour la communication requise pour le
processus GP2.1.6 processus. Il devrait inclure :
GP3.2.3 • Responsabilité pour la communication
• Audience cible
• Le contenu qui devrait être communiqué
• Le timing de la communication
• L’approche de la communication
Infrastructure du processus GP3.1.4 Les installations, outils, méthodes et environnement de
et environnement de travail GP3.2.5 travail pour effectuer le processus
Expérience pour l’exécution GP2.1.4 Description de fonction et d’aptitudes requises pour
du processus, aptitudes entreprendre le processus
requises
Exigence d’apprentissage GP2.1.5 Aptitudes et compétences des utilisateurs, incluant les
du processus exigences de formations individuelles

Pratique
liée
3.0 Plan qualité Déclaration de politique de GP2.1.2 Une déclaration des attentes de qualité des clients pour
qualité et objectifs le processus, par exemple, des livrables ou ponctualité
Contenu des livrables GP2.2.1 Identification de tous les livrables, leur structure et leur
contenu attendu
Critères de qualité pour les GP2.2.1 Les critères au regard desquels chaque livrable sera revu
livrables produits au cours et approuvé
des processus comme
bases pour les revues et les
approbations.
Documentation des GP2.2.2 Les exigences pour la documentation et les exigences
livrables de contrôle, incluant l’identification, la traçabilité et les
approbations
Les livrables : contrôle des GP2.2.3 Définition des procédures pour les versions et le contrôle
changements, des versions des changements qui doivent être appliquées aux
et exigences de gestion livrables.
des configurations
4.0 Comptes rendus Comptes rendus des GP2.2.4 Comptes rendus des revues entreprises des sous-
de la qualité revues au regard des produits ensemble avec toutes les questions se posant
exigences et action prise et les résolutions
fournissant des indices à
l’occasion des contrôles
requis et des vérifications
de qualités
5.0 Politiques & Objectifs organisationnels GP3.1.1 Une déclaration des objectifs d’organisation pour le
standards. et responsabilité pour le processus tel qu’il est appliqué au travers des unités
processus organisationnelles. Il devrait identifier les responsabilités
générales du processus
Critère minimum de GP3.1.1 Le niveau de performance attendu pour le processus au
performance requise pour travers de l’organisation. Ceci peut inclure des jalons,
le processus activités requises, estimation des volumes ou calendriers
des livrables
Norme de cartographie GP3.1.2 Un dessin schématique du flux de travail séquentiel
du processus, incluant GP3.2.1 attendu pour le processus. Ceci devrait aussi identifier
la séquence espérée les interactions attendues entre différentes implantations
et interaction entre les du processus
processus
Procédures étalonnées GP3.2.1 Un document définissant les procédures qui devraient
être suivies dans toutes les implantations du processus
Rôles et compétence pour GP3.1.3 Descriptions de fonctions standardisées et aptitudes
exécuter le processus au GP3.2.2 requises pour entreprendre le processus
minimum de critère de GP3.2.3
performance
Infrastructure minimale GP3.1.4 Les installations, outils, méthodes et environnement de
(installations, outils, travail pour effectuer le processus
méthodes…) et
environnement de travail
pour effectuer le processus
Exigences de reporting et GP3.1.5 Rapports attendus et surveillance requise pour le
de surveillance, incluant les processus, incluant les exigences standardisées de
audits et les revues reporting

Pratique
liée
6.0 Plan d’amélioration Objectifs d’amélioration du GP5.1.1 Le niveau de performance attendu du processus basé
de la performance processus sur les objectifs d’entreprise
Analyse au regard des GP5.1.3 Opportunités identifiées pour des améliorations du
meilleures pratiques processus basé sur des analyses de comparaisons avec
les meilleures pratiques de l’industrie
Opportunités d’amélioration GP5.1.4 Opportunités identifiées d’améliorations du processus
technologiques basées sur des innovations technologiques et de
process
Actions d’amélioration GP5.1.5 Actions identifiées pour améliorer le processus au-travers
de l’organisation
Plan d’implantation des GP5.1.6 Les améliorations proposées, actions planifiées pour
améliorations implanter ces améliorations, responsabilités et calendrier
Approche qualité du projet GP5.1.5 Processus proposé pour confirmer la réalisation des
améliorations: mesures, revues…
7.0 Plan de mesure du Objectifs des mesures GP4.1.1 Objectifs quantitatifs pour le processus relatifs à la qualité
processus et à la performance, basés sur les besoins des clients et
les objectifs d’entreprise
Mesures et indicateurs GP4.1.2 Identification de ce qui doit être mesuré et des
proposés indicateurs de mesure
Procédures de collecte des GP4.1.3 Identification de comment les données doivent être
données recueillies pour supporter les mesures
Procédures analytiques GP4.1.3 Identification des procédures analytiques à utiliser, depuis
GP4.1.4 de simples graphiques jusqu’à de plus sophistiquées
méthodes d’analyse comme le contrôle de processus
statistique, modélisation de la structure, ou autres
méthodes statistiques multivariées
8.0 Plan de contrôle Techniques de contrôle GP4.2.1 Une description des méthodes utilisées pour minimaliser
du processus la variation du processus et du produit.
Cela différera pour chaque produit et pourrait inclure des
choses tels que critères, tests, revues, visite
Approche de la mesure GP4.2.1 Comment la variation dans chaque processus sera
mesurée
Limites de contrôle de la GP4.2.2 Le niveau acceptable de variation du processus
performance normale
9.0 Comptes rendus Comptes rendus des GP4.1.5 Comptes rendus des performances réelles des
des performances revues au regard des processus, avec toutes les variations des résultats
du processus exigences et actions prises attendus et action prise pour rectifier les variations

F. CobiT V5 : Les principaux éléments en français !
Nous présentons ci-dessous, pour chacun des 36 processus de CobiT,
• Son identifiant,
• Son libellé,
• Sa déclaration d’objectif,
• Ses pratiques de gouvernance et / ou de gestion.
• Leur identifiant,
• Leur libellé,
• Le libellé des livrables (en sortie).
• Ses métriques.
CobiT V5 : Le quoi et le comment
EDM BAI DSS

(évaluer, diriger (Bâtir, acquérir et implémenter) (Délivrer, servir et supporter)
et surveiller)
Gérer Accepter et mettre en
Gérer les opérations
la connaissance œuvre les changements
Assurer la
transparence
Facilliter le changement Gérer les contrôles
pour les parties Gérer les changements
organisationnelle des processus métiers
prenantes
Gérer la disponibilité Identifier et construire Gérer la sécurité

et la capacité les solutions de l'information
Assurer la
l'optimisation Définir Gérer les programmes Gérer la continuité
des ressources les exigences et les projets Le des affaires
comment
Gérer les problèmes
APO
(Aligner, planifier et organiser)
Assurer la Gérer les requêtes de
l'optimisation Définir le cadre Gérer service et incidents
Définir
du risque de gestion l'architecture
la stratégie
de l'IT d'entreprise Gérer
les configurations
Gérer
Gérer Gérer
Assurer la les budgets
l'innovation le portefeuille Gérer les actifs
l'optimisation et les coûts
de la valeur
Gérer Gérer MEA
Gérer
les ressources les accords (Monitorer, évaluer et apprécier)
les relations
humaines de service
Surveiller et
établir et Surveiller et Surveiller
apprécier la
maintenir le Gérer évaluer la le système
Gérer Gérer conformité avec
carde de les performance et de contrôle
la qualité les risques les exigences
gouvernance fournisseurs la conformité interne
externes

1. Établir et de maintenir le cadre de gouvernance (EDM01)
Le but du processus est de fournir une approche consistante intégrée et alignée avec l’approche de la
gouvernance d’entreprise. Pour s’assurer que les décisions liées à l’IT sont prises en ligne avec les stratégies
et objectifs de l’entreprise, les processus liés à l’IT sont supervisés efficacement et de façon transparente,
la conformité aux exigences juridiques et réglementaires est confirmée, et que les exigences en matière
de gouvernance pour les membres du Conseil d’administration sont remplies.
• 01 Évaluer la conception de la gouvernance IT d’entreprise

• Principes guidant la gouvernance d’entreprise
• Modèle décisionnel
• Niveaux d’autorité
• 02 Diriger le système de gouvernance

• Communications sur la gouvernance d’entreprise
• Approche du système de récompense
• 03 Surveiller le système de gouvernance

• Rétroactions sur l’efficacité et la performance de la gouvernance
Les indicateurs à utiliser :
• Niveau de satisfaction des parties prenantes (mesurée par le biais de sondages)

• Temps de cycle réels vs cibles pour les décisions clés
• Nombre de rôles, de responsabilités et de pouvoirs qui sont définis, assignés et acceptés par
responsables appropriés des métiers et de l’IT
• Degré auquel les principes de gouvernance agréés sont mis en évidence dans les processus et
pratiques (% de processus et pratiques avec traçabilité claire des principes)
• Nombre d’instances de non-conformité avec l’éthique et les lignes directrices de comportement
professionnel
• Fréquence du rapport sur la gouvernance IT au Comité exécutif et au Conseil d’Administration
• Nombre de questions de gouvernance IT signalées
• Fréquence des revues indépendantes de la gouvernance IT.

2. Assurer l’optimisation de la valeur (EDM02)
Le but du processus est de sécuriser la valeur optimale des initiatives de services et des actifs IT,
l’efficacité de coût de la livraison de solutions et de services, et une image fiable et exacte des coûts et des
bénéfices probables de manière telle que les besoins de l’entreprise soient pris en charge effectivement
et efficacement.
• 01 Évaluer l’optimisation de la valeur

• Évaluation de l’alignement stratégique
• Évaluation des portefeuilles d’investissements et de services
• 02 Diriger l’optimisation de la valeur

• Types d’investissements et critères
• Exigences des revues de validation d’étape
• 03 Surveiller l’optimisation de la valeur

• Rétroaction sur le rendement de portefeuille et de programme
• Mesures pour améliorer la livraison de valeur.
• Écart entre dosage de l’investissement cible et le réel

• Niveau de satisfaction des parties prenantes avec la capacité des entreprises d’obtenir de
la valeur d’initiatives IT
• Niveau de satisfaction de la Direction Générale avec la valeur de la livraison et des coûts
• Nombre d’incidents qui surviennent en raison de contournements réels ou tentatives de
contournement des principes et pratiques établis de gestion de la valeur
• % d’initiatives informatiques dans l’ensemble du portefeuille où la valeur est gérée au travers du
cycle de vie complet
• Niveau de satisfaction des parties prenantes avec le progrès vers les objectifs identifiés, avec
la livraison de valeur basée sur des enquêtes
• % de valeur attendue réalisé.

3. Assurer l’optimisation du risque (EDM03)
Le but du processus est s’assurer que les risques de l’entreprise liés à l’IT ne dépassent pas l’appétit au
risque et la tolérance au risque, l’impact du risque IT à la valeur de l’entreprise est identifié et géré et
le potentiel d’échecs de conformité est minimisé.
• 01 Évaluer la gestion du risque

• Orientation de l’appétit au risque
• Niveaux approuvés de tolérance au risque
• Évaluation des activités de gestion du risque
• 02 Diriger la gestion du risque
• Règles de gestion du risque
• Objectifs clés à surveiller pour la gestion du risque
• Processus approuvés pour mesurer la gestion du risque
• 03 Surveiller la gestion du risque

• Mesures correctives pour traiter les écarts de gestion des risques
• Questions de gestion du risque pour le Conseil d’administration.
• Nombre potentiel de risques IT identifiés et gérés

• Taux de rafraîchissement de l’évaluation des facteurs de risque
• Niveau d’alignement entre les risques informatiques et les risques de l’entreprise
• % des projets d’entreprise qui prennent en considération le risque IT
• % des plans action du risque IT exécutés dans les temps
• % risques critiques qui ont été efficacement atténuées
• % des risques IT qui dépassent la tolérance au risque d’entreprise
• Niveau de l’impact inattendu sur l’entreprise.

4. Assurer l’optimisation des ressources (EDM04)
Le but du processus est de s’assurer que les besoins en ressources de l’entreprise sont satisfaits de
la manière la plus optimale, que les coûts de l’IT sont optimisés, et qu’il y a une augmentation de la
probabilité de réalisation des bénéfices et d’être prêt pour le changement futur.
• 01 Évaluer les stratégies IT pour se procurer les ressources

• Principes directeurs pour l’allocation des ressources et des capacités
• Principes directeurs pour l’architecture d’entreprise
• Approbation des plans de ressources
• 02 Diriger la gestion des ressources

• Communication des stratégies pour se procurer les ressources
• Responsabilités attribuées pour la gestion des ressources
• Principes de sauvegarde des ressources
• 03 Surveiller la gestion des ressources

• Commentaires sur la répartition et de l’efficacité des ressources et des capacités
• Mesures correctives pour traiter les écarts de gestion des ressources.
• Nombre de déviations des stratégies du plan des ressources et de l’architecture d’entreprise

• Avantages (par exemple : les économies de coûts) grâce à une utilisation optimale
des ressources
• Commentaires des parties prenantes sur l’optimisation des ressources
• Nombre de déviations et d’exception des principes de gestion des ressources
• % projets qui s’alignent sur les principes de l’architecture d’entreprise
• % projets et programmes avec un état moyen ou haut de risque en raison de questions
de gestion des ressources
• Réalisation des objectifs de rendement de gestion des ressources
• % de réutilisation des composants de l’architecture.

5. Assurer la transparence pour les parties prenantes (EDM05)
Le but du processus est de s’assurer que les communications vers les parties prenantes sont efficaces et
en temps opportun et que la base des rapports est établie afin d’augmenter les performances, d’identifier
les domaines d’amélioration et de confirmer que les objectifs et stratégies IT sont conformes à la stratégie
de l’entreprise.
• 01 Évaluer les exigences en rapports des parties prenantes

• Évaluation des exigences en rapports de l’entreprise
• Principes de production des rapports et des communications
• 02 Rapporter et communiquer aux parties prenantes directes

• Règles pour valider et approuver les rapports obligatoires
• Directives pour l’escalade
• 03 Surveiller la communication des parties prenantes

• Évaluation de l’efficacité du reporting
• % des parties prenantes couvertes dans les exigences de reporting

• Date de la dernière révision des exigences
• % des rapports qui ne sont pas remis à temps
• % des rapports contenant des inexactitudes
• Satisfaction des parties prenantes avec les rapports
• Nombre de manquements aux exigences de déclarations obligatoires.

6. Définir le cadre de gestion de l’IT (APO01)
Le but du processus est de fournir une approche de gestion cohérente pour activer les exigences de
gouvernance d’entreprise à respecter, couvrant les processus de gestion, les structures organisationnelles,
les rôles et responsabilités, les activités fiables et reproductibles, et les aptitudes et compétences.
• 01 Définir la structure organisationnelle

• Définition de la structure organisationnelle et des fonctions
• Directives opérationnelles d’organisation
• Règles de base de la communication
• 02 établir les rôles et responsabilités

• Définition des rôles et responsabilités liés à l’IT
• Définition des pratiques de supervision
• 03 Maintenir les facilitateurs du système de gestion

• Règles liées à l’IT
• 04 Communiquer les objectifs de gestion et la direction

• Communications sur les objectifs IT
• 05 Optimiser le positionnement de la fonction IT

• Évaluation des options pour l’organisation de l’IT
• Définition des positionnements opérationnels de la fonction IT
• 06 Définir la propriété des informations (données) et du système

• Directives pour la classification des données
• Directives pour la sécurité et le contrôle des données
• Procédures sur l’intégrité des données
• 07 Gérer l’amélioration continue des processus

• Évaluation de l’aptitude des processus
• Opportunités d’amélioration des processus
• Objectifs de performances et métriques pour le suivi d’amélioration des processus
• 08 Assurer la conformité avec les règles et les procédures
• Actions correctives des non-conformités
• % des règles, normes et autres facilitateurs actifs, documentés et mis à jour

• Date des dernières mises à jour pour le cadre et les facilitateurs
• Nombre d’expositions au risque en raison de lacunes dans la conception de l’environnement
de contrôle
• Nombre de personnels qui ont participé à des séances de formation ou de sensibilisation
• % fournisseurs tierces parties qui ont des contrats définissant les exigences de contrôle.

7. Définir la stratégie (APO02)
Le but du processus est de s’assurer que les plans stratégiques de l’IT sont cohérents avec les objectifs
de l’entreprise, et que les objectifs et responsabilités associés sont clairs et compris par tous, avec les
options stratégiques de l’IT identifiées, structurées et intégrées avec les plans d’affaires.
• 01 Comprendre la direction de l’entreprise

• Sources et priorités du changement
• 02 évaluer l’environnement actuel, les aptitudes et la performance

• Point de comparaison des aptitudes actuelles
• Écarts et risques liés aux aptitudes actuelles
• Analyse SWOT des aptitudes
• 03 Définir les aptitudes IT cible

• Buts de haut niveau reliés à l’IT
• Aptitudes métiers et IT requises
• Propositions de changement de l’architecture d’entreprise
• 04 Conduire une analyse des écarts

• Écarts et changements requis pour réaliser les aptitudes cibles
• Enoncé de la valeur des bénéfices pour l’environnement cible
• 05 Définir le plan stratégique et la feuille de route

• Définition des initiatives stratégiques
• Évaluation des risques
• Feuille de route stratégique
• 06 Communiquer la stratégie IT et la direction

• Plan de communication
• Package de communication
• % des objectifs dans la stratégie IT qui prennent en charge la stratégie de l’entreprise

• % des objectifs d’entreprise pris en charge dans la stratégie IT
• % des initiatives dans la stratégie de TI qui sont auto financées (avantages financiers plus élevés
que les frais)
• Tendances des ROI des initiatives inclues dans la stratégie IT
• Satisfaction des parties prenantes de l’entreprise et enquête sur les commentaires
des intervenants de la stratégie IT
• % des projets dans le portefeuille de projets de l’IT qui peut être directement lié à la stratégie IT
• % des objectifs d’entreprises stratégiques obtenus en résultats d’initiatives stratégiques de l’IT
• Nombre de nouvelles possibilités d’entreprise réalisé en conséquence directe
des développements de l’IT
• % des initiatives et projets IT défendues par les responsables métiers
• Réalisation résultats stratégiques mesurable de l’IT partie des objectifs de performance
des personnels
• Fréquence des mises à jour du plan de communication de la stratégie IT
• % des initiatives stratégiques avec une responsabilisation assignée.

8. Gérer l’architecture d’entreprise (APO03)
Le but du processus est de représenter les différents blocs de construction qui composent l’entreprise
et leurs relations ainsi que les principes qui guident leur conception et leur évolution au fil du temps,
ce qui permet une livraison standard, souple et efficace des objectifs opérationnels et stratégiques.
• 01 Développer la vision de l’architecture d’entreprise

• Portée définie de l’architecture
• Principes d’architecture
• Cas d’affaire et proposition de valeur de l’architecture conceptuelle
• 02 Définir l’architecture de référence

• Description des domaines de base et définition de l’architecture
• Modèle d’architecture des processus
• Modèle d’architecture de l’information
• 03 Sélectionner les opportunités et les solutions

• Stratégie d’implantation et de migration de haut-niveau
• Architectures de transition
• 04 Définir l’implantation de l’architecture

• Besoins en ressources
• Description des phases d’implantation
• Exigences en gouvernance de l’architecture
• 05 Fournir des services d’architecture d’entreprise

• Orientations pour le développement des solutions
• Nombre d’exceptions aux standards d’architecture demandées et accordées

• Commentaires des clients de l’architecture
• Bénéfices réalisés par les projets qui peuvent être imputés à l’utilisation de l’architecture
(par exemple : réduction des coûts par le biais de réutilisation)
• Pourcentage de projets utilisant les services de l’architecture d’entreprise
• Date de dernière mise à jour des architectures de domaines ou fédérales
• Nombre d’écarts identifiés dans les modèles au travers des domaines d’architecture d’entreprise,
des informations, des données, des applications et des technologies
• Commentaires des clients de l’architecture au regard de la qualité de l’information fournie
• Pourcentage de projets qui utilisent le cadre et la méthodologie pour réutiliser les composants
définis
• Nombre de personnes formées à la méthodologie et à la boite à outils

9. Gérer l’innovation (APO04)
Le but du processus est d’obtenir avantage concurrentiel, innovation métier, et amélioration de l’efficacité
et de l’efficience en exploitant les développements des technologies de l’information.
• 01vCréer un environnement propice à l’innovation

• Plan d’innovation
• Programme de reconnaissance et de récompense
• 02 Maintenir une compréhension de l’environnement de l’entreprise

• Opportunités d’innovation liées aux facteurs déterminants des métiers
• 03 Surveiller et scruter l’environnement technologique

• Analyses des recherches sur les possibilités d’innovation
• 04 Évaluer le potentiel des technologies émergentes et des idées d’innovation

• Evaluations des idées d’innovation
• Périmètre de la démonstration de faisabilité et contour du cas d’affaire
• Résultats des tests des initiatives de la démonstration de faisabilité
• 05 Recommander des initiatives supplémentaires appropriées

• Résultats et recommandations des initiatives de démonstration de faisabilité
• Analyse des initiatives rejetées
• 06 Surveiller l’implantation et l’utilisation des innovations

• Évaluations de l’utilisation des approches novatrices
• Évaluation des bénéfices de l’innovation
• Plans d’innovation ajustés
• Augmentation de la part de marché ou de compétitivité grâce aux innovations

• Perception et rétroaction des parties prenantes de l’entreprise sur l’innovation IT
• % d’initiatives mises en œuvre ayant un lien clair avec les objectifs de l’entreprise
• % d’initiatives mises en œuvre qui réalisent les avantages envisagés
• Enquêtes et commentaires des parties prenantes
• Inclusion de l’innovation ou émergence des objectifs liés à la technologie dans les objectifs
de performance pour le personnel concerné

10. Gérer le portefeuille (APO05)
Le but du processus est d’optimiser la performance de l’ensemble du portefeuille de programmes en

réponse à la performance des programmes et aux changements de priorités de l’entreprise.
• 01 établir le mix cible d’investissement

• Définition du mix d’investissement
• Identification des ressources et des capacités nécessaires pour supporter la stratégie
• Commentaire sur la stratégie et les objectifs
• 02 Déterminer la disponibilité et la source des financements

• Options de financement
• Attentes de retour sur investissements
• 03 évaluer et sélectionner les programmes à financer

• Cas d’affaire des programmes
• Évaluation des cas d’affaire
• Programmes sélectionnés avec les jalons du retour sur investissements
• 04 Surveiller, optimiser et rapporter sur la performance du portefeuille d’investissement

• Rapports sur la performance du portefeuille d’investissement
• 05 Maintenir les portefeuilles

• Portefeuilles de programmes, services et actifs mis à jour
• 06 Gérer la réalisation des bénéfices

• Résultats bénéficiaires et communications reliées
• Actions de correction pour améliorer la réalisation des bénéfices
• % des investissements informatiques qui ont la traçabilité de la stratégie de l’entreprise

• Degré auquel le management de l’entreprise est satisfait de la contribution du SI à la stratégie
de l’entreprise
• Ratio entre les fonds disponibles et fonds alloués
• Ratio entre les fonds alloués et les fonds utilisés
• % des BU impliquées dans le processus d’évaluation et de priorisation
• Niveau de satisfaction au sujet des rapports de surveillance du portefeuille
• % des modifications du programme d’investissement reflétées dans les portefeuilles
correspondants du SI
• % investissements où les bénéfices réalisés ont été mesurés et comparés au cas d’affaire

11. Gérer les budgets et les coûts (APO06)
Le but du processus est d’encourager le partenariat entre l’IT et les parties prenantes de l’entreprise afin
de permettre l’utilisation efficace et efficiente des ressources liées au SI et de fournir la transparence
et la responsabilisation du coût et de la valeur économique des solutions et des services. Permettre à
l’entreprise de prendre des décisions éclairées concernant l’utilisation des solutions et des services IT.
• 01 Gérer les finances et la comptabilité

• Processus comptables
• Schéma de classification des coûts de l’IT
• Pratiques de planification financière
• 02 Prioriser l’allocation des ressources

• Hiérarchisation et classement des initiatives IT
• Allocations budgétaires
• 03 établir et maintenir les budgets

• Budgets et plan IT
• Communications sur les budgets
• 04 Modéliser et allouer les coûts

• Coûts IT classés
• Modèle d’allocation des coûts
• Communication de l’allocation des coûts
• 05 Gérer les coûts

• Méthode de collecte des données de coût
• Méthode de consolidation des coûts
• Opportunités d’optimisation des coûts
• Nombre d’écarts entre les postes budgétaires attendus et réels

• Nombre de changements budgétaires en raison d’erreurs et d’omissions
• % d’alignement des ressources informatiques avec les initiatives à haute priorité
• Nombre de questions d’allocation de ressources escaladées
• % global des coûts IT avec une allocation conforme aux modèles de coût acceptés
• % de variation entre les budgets, les prévisions et les coûts réels

12. Gérer les ressources humaines (APO07)
Le but du processus est d’optimiser les capacités des ressources humaines pour répondre aux objectifs
de l’entreprise.
• 01 Maintenir une dotation en personnel adéquate et appropriée

• Évaluation des besoins en dotation de personnel
• Plans de développement des compétences et des carrières
• Plans de recrutement de personnels
• 02 Identifier les personnels IT clés
• 03 Maintenir les aptitudes et les compétences des personnels

• Matrices des aptitudes et des compétences
• Plans de développement des aptitudes
• Rapports des entretiens d’évaluation
• 04 évaluer la performance au travail des personnels

• Objectifs individuels
• Évaluation des performances
• Plans d’amélioration
• 05 Planifier et suivre l’utilisation des ressources humaines IT et métiers

• Inventaire des ressources humaines IT et métiers
• Analyses des pénuries en ressources humaines
• Enregistrements des utilisations des ressources humaines
• 06 Gérer les contrats des personnels

• Règles des contrats des personnels
• Accords contractuels
• Revue des accords contractuels
• Nombre de décisions qui ne pouvaient pas être résolues par les structures de gestion et qui ont
été escaladées aux structures de gouvernance
• Satisfaction des dirigeants pour la capacité à décider des gestionnaires
• Nombre de définitions de service et de catalogues de service
• % de rotation du personnel
• Durée moyenne de vacance des postes
• % postes IT vacants

13. Gérer les relations (APO08)
Le but du processus est de créer de meilleurs résultats, une confiance accrue et la confiance envers le
SI et une utilisation efficace des ressources.
• 01 Comprendre les attentes de l’entreprise

• Attentes de l’entreprise clarifiées et convenues
• 02 Identifier les opportunités, les risques et les contraintes pour l’IT améliorer l’entreprise
• Étapes suivantes convenues et plans d’action
• 03 Gérer les relations avec les métiers

• Décisions clés convenues
• Plaintes et statuts d’escalade
• 04 Coordonner et communiquer

• Plan de communication
• Paquets de communications
• Réponses des clients
• 05 Contribuer à l’amélioration continue des services

• Analyses de satisfaction
• Définition de projets d’améliorations potentielles
• % d’alignement des services IT avec les besoins de l’entreprise

• % d’alignement des programmes avec les besoins de l’entreprise
• Notation des utilisateurs et des personnels IT dans les enquêtes de satisfaction
• Taux d’inclusion des opportunités technologiques dans les propositions d’investissement
• Enquête sur la conscientisation technologique des parties prenantes

14. Gérer les accords de service (APO09)
Le but du processus est de s’assurer que les services IT et les niveaux de service rencontrent les besoins
actuels et futurs de l’entreprise.
• 01 Identifier les services IT

• Écarts identifiés dans les services IT à l’entreprise
• Définition des services standards
• 02 Définir les services IT et maintenir le portefeuille des services

• Définition des services
• Portefeuille des services mis à jour
• 03 Cataloguer les services IT

• Catalogues des services
• 04 Définir et préparer les accords de service

• Accords de niveau de service (SLA)
• Accords de niveau d’exploitation (OLA)
• 05 Surveiller et faire rapport sur les niveaux de service

• Rapports sur la performance des niveaux de service
• Plans d’actions d’amélioration et de correction
• 06 Passer en revue les accords et les contrats

• Accords de niveau de service (SLA) mis à jour
• Nombre de processus métiers avec des accords de service non définis

• % des services IT actifs couverts par des accords de service
• % de clients satisfaits que la prestation de services répond aux niveaux convenus
• % de services surveillés aux niveaux de service
• % des objectifs de service atteints
• Nombre et gravité des manquements des services

15. Gérer les fournisseurs (APO10)
Le but du processus est de minimiser le risque associé aux fournisseurs non performants et d’assurer
des prix concurrentiels.
• 01 Identifier et évaluer les relations avec les fournisseurs et les contrats
• Importance du fournisseur et critères d’évaluation
• Catalogue des fournisseurs
• Éventuelles révisions des contrats des fournisseurs
• 02 Sélectionner les fournisseurs

• Demandes de renseignements (RFI) et demandes de proposition (RFP) aux fournisseurs
• Évaluation des RFI et RFP
• Résultats des décisions d’évaluations des fournisseurs
• 03 Gérer les relations avec les fournisseurs et les contrats

• Rôles et responsabilités des fournisseurs
• Processus de communication et de passage en revue
• Passer en revue les résultats et les améliorations proposées
• 04vGérer le risque fournisseur

• Identifier les risques fournisseurs
• Identifier les conditions contractuelles pour minimiser les risques
• 05 Surveiller la performance et la conformité des fournisseurs

• Critères de surveillance de la conformité des fournisseurs
• Résultats du passage en revue de la conformité des fournisseurs.
• % des fournisseurs satisfaisant aux exigences convenues

• Nombre de manquements de service causés par les fournisseurs
• Nombre d’événements liés aux risques menant à des incidents de services
• % d’incidents liés aux risques résolus en coût et temps acceptables
• Fréquence des séances de gestion du risque avec le fournisseur
• Nombre de litiges formels avec les fournisseurs
• Nombre de réunions de passage en revue des fournisseurs
• % des différends réglés à l’amiable dans un laps de temps raisonnable

16 Gérer la qualité (APO11).
Le but du processus est d’assurer la livraison régulière de solutions et de services pour satisfaire aux
exigences de qualité de l’entreprise et satisfaire les besoins des parties prenantes.
• 01 Établir un système de gestion de qualité (QMS)

• Rôles, responsabilités et droits de décision du QMS
• Plans de gestion de la qualité
• Résultats du passage en revue de l’efficacité du QMS
• 02 Définir et gérer les standards de qualité, pratiques et procédures

• Standards de gestion de la qualité
• 03 Concentrer la gestion de la qualité sur les clients

• Exigences du client pour la gestion de la qualité
• Critères d’acceptation
• Résultats du passage en revue de la qualité des services, y compris les commentaires
des clients
• 04 Effectuer la surveillance, le contrôle et le passage en revue de la qualité

• Résultats des passages en revue et des audits de qualité
• Buts et métriques orientés qualités de service des processus
• 05 Intégrer la gestion de la qualité dans les solutions de développement et de livraison

• Résultats de la surveillance de la qualité des solutions et de la livraison des services
• Causes profondes d’échecs de livraison de qualité
• 06 Assurer une amélioration continue

• Communications sur l’amélioration continue et sur les meilleures pratiques.
• Exemples de bonnes pratiques à partager
• Résultats du passage en revue qualité des benchmarks
• % des parties prenantes satisfaites de la qualité du SI

• Nombre de services avec un plan formel de gestion de la qualité
• Moyenne de la notation de satisfaction des parties prenantes pour les solutions et les services
• % de solutions et services livrés avec certification formelle
• Nombre de défauts découverts avant la production
• % projets passés en revue qui répondent aux cibles des buts et objectifs qualité
• Nombre de processus avec une exigence de qualité définis
• Nombre de processus avec un rapport formel d’évaluation de la qualité
• Nombre de SLA qui incluent des critères d’acceptation de qualité

17. Gérer les risques (APO12)
Le but du processus est d’intégrer la gestion du risque d’entreprise lié à l’IT avec la gestion de risque
globale d’entreprise et équilibrer les coûts et les avantages de la gestion des risques d’entreprises liés
à l’IT.
• 01 Collecter les données

• Données liées au risque sur l’environnement opérationnel
• Données sur les événements à risque et leurs facteurs contributifs
• Questions et facteurs de risque émergents
• 02 Analyser les risques

• Étendue des efforts d’analyse du risque
• Scénarios des risques IT
• Résultats des analyses de risques
• 03 Maintenir un profil de risque

• Scenarios de risque documentés par fonction et ligne de business
• Agrégation du profil de risque, y compris le statut des actions de gestion de risques
• 04 Articuler le risque

• Analyses de risque et rapports de profil de risque pour les parties prenantes
• Résultats du passage en revue de l’évaluation de risques des parties tierces
• Opportunités pour l’acceptation de risques plus grands
• 05 Définir un portefeuille de gestion des actions liées au risque

• Projets proposés pour réduire le risque
• 06 Répondre au risque

• Plans de réponse aux incidents liés au risque
• Communication des impacts liés au risque
• Causes profondes liées aux risques
• Nombre d’événements de perte avec caractéristiques clés capturés dans les répertoires
• % d’audits, d’événements et des tendances capturés dans les répertoires
• Degré de visibilité et de reconnaissance dans l’environnement actuel
• % des processus d’affaires clés inclus dans le profil de risque
• Intégralité des attributs et des valeurs dans le profil de risque
• % des propositions de gestion du risque rejetées en raison de l’absence de prise en compte
d’autres risques connexes
• Nombre d’incidents majeurs non identifiés et inclus dans le portefeuille de gestion du risque.
• % des actions des plans de risque IT exécutées comme prévu
• Nombre de mesures ne réduisant pas le risque résiduel

18. Gérer les programmes et les projets (BAI01)
Le but du processus est de réaliser des bénéfices pour l’entreprise et de réduire le risque de retards et
des coûts imprévus, d’érosion de la valeur en améliorant la communication et l’implication des métiers
et des utilisateurs, en assurant la valeur et la qualité des livrables des projets et en maximisant leur
contribution au portefeuille d’investissement et de services.
• 01 Maintenir une approche standard pour la gestion des projets et des programmes
• Mises à jour des approches de gestion de programme et de projet
• 02 Initier un programme

• Cas d’affaire conceptuel du programme
• Mandat du programme et attributions
• Plan de réalisation des bénéfices du programme
• 03 Gérer les engagements des parties prenantes

• Plan d’engagement des parties prenantes
• Résultats des évaluations de l’efficacité de l’engagement des parties prenantes
• 04 Développer et maintenir le plan de programme

• Plan de programme
• Registre du budget et des bénéfices du programme
• Besoins en ressources et rôles
• 05 Lancer et exécuter le programme

• Résultats de la surveillance de la réalisation des bénéfices
• Résultats de la surveillance de l’atteinte des objectifs du programme
• 06 Surveiller, contrôler et rapporter sur les résultats du programme

• Résultats des revues de performance du programme
• Résultats des revues des validations d’étape
• 07 Démarrer et lancer des projets au sein d’un programme

• Déclarations de portée du projet
• Définitions de projet
• 08 Planifier les projets
• Plans de projet
• Point de comparaison du projet
• Rapports et communications du projet
• 09 Gérer la qualité du programme et du projet

• Plan de gestion de la qualité
• Exigences de vérification indépendante des livrables
• 10 Gérer les risques du programme et du projet

• Plan de la gestion des risques du projet
• Résultats des évaluations des risques du projet
• Registre des risques du projet

• 11 Surveiller et contrôler les projets
• Critères de performance du projet
• Rapports d’étape du projet
• Accord sur les modifications au plan de projet
• 12 Exécuter un projet

• Besoins en ressources du projet
• Rôles et responsabilités du projet
• Écarts dans la planification de projet
• 13 Clôturer un projet

• Résultats de la revue post-implantation
• Leçons apprises du projet
• Confirmation de l’acceptation des parties prenantes du projet
• 14 Clôturer un programme

• Communication du retrait du programme et des responsabilités en cours
• % des parties prenantes effectivement engagées

• Niveau de satisfaction des parties prenantes avec implication
• % parties prenantes approuvant la nécessité, la portée, le résultat escompté et le niveau de risque
de projet pour l’entreprise
• % projets entrepris sans cas d’affaire approuvé
• % des programmes actifs entrepris sans cartes de valeur de programme valide et à jour.
• % activités alignées sur la portée et les résultats attendus
• % des déviations du plan traité
• % d’approbation des parties prenantes pour les revues d’étape des programmes actifs
• Fréquence des revues de l’état
• Nombre de questions à propos des ressources (par exemple : compétences, capacités)
• % des bénéfices escomptés atteints
• % des résultats avec l’acceptation initiale
• Niveau de satisfaction des parties prenantes exprimé à la revue de clôture du projet

19. Définir les exigences (BAI02)
Le but du processus est de créer des solutions optimales réalisables qui répondent aux besoins de
l’entreprise tout en minimisant risques.
• 01 Définir et maintenir les besoins fonctionnels et techniques de l’entreprise

• Référentiel de définition des exigences
• Confirmation d’acceptation des exigences des parties prenantes
• Enregistrement des demandes de changement des besoins
• 02 Effectuer une étude de faisabilité et formuler des solutions alternatives

• Rapport d’étude de faisabilité
• Plan de haut niveau d’acquisition et de développement
• 03 Gérer les risques liés aux besoins

• Registre des risques liés aux besoins
• Mesures d’atténuation du risque
• 04 Obtenir l’approbation des besoins et des solutions

• Approbation par les sponsors des besoins et des solutions proposées
• Approbation des revues qualité
• % des besoins revus en raison du mauvais alignement avec les attentes et les besoins
des entreprises
• Satisfaction des parties prenantes aux besoins
• % des besoins rencontrés par la solution proposée
• % risques non atténués
• Nombre d’incidents non identifiés comme des risques
• % des objectifs des cas d’affaires rencontrés par la solution proposée
• % des parties prenantes n’approuvant pas la solution en rapport avec le cas d’affaire

20. Identifier et construire les solutions (BAI03)
Le but du processus est d’établir des solutions en temps opportun et rentables qui soient capables de
soutenir les objectifs stratégiques et opérationnels de l’entreprise.
• 01 Concevoir les spécifications générales des solutions

• Spécifications générales approuvées
• 02 Concevoir les composants détaillés des solutions

• Approbation des spécifications détaillées
• 03 Développer les composants de la solution

• Composants documentés de la solution
• 04 Se procurer des composants de la solution

• Plans d’acquisition approuvés
• Mises à jour de l’inventaire des actifs
• 05 Construire des solutions

• Composants intégrés et configurés de la solution
• 06 Effectuer l’assurance de la qualité

• Plan d’assurance qualité
• Résultats, exceptions et corrections des revues de qualité
• 07 Préparer le test des solutions

• Plan de test
• Procédures de test
• 08 Exécuter le test des solutions

• Journaux des résultats des tests et pistes d’audit
• Communications des résultats des tests
• 09 Gérer les changements des besoins

• Enregistrement de toutes les demandes de modification approuvées et appliquées
• 10 Maintenir les solutions
• Plan de maintenance
• Mises à jour des composants de la solution et de la documentation
• Analyses périodiques de la maintenance
• Nombre de conceptions de solutions remaniées en raison de mauvais alignement avec les exigences
• Temps pris pour approuver que la conception des livrables a satisfait aux exigences
• Nombre d’exceptions à la conception de la solution notées pendant les revues d’étape
• Nombre d’erreurs relevées au cours des tests
• Temps et effort pour procéder aux tests
• Nombre de modifications suivies et approuvées qui génèrent de nouvelles erreurs
• Nombre de demandes de maintenance qui sont insatisfaites


21. Gérer la disponibilité et la capacité (BAI04)
Le but du processus est de maintenir la disponibilité du service, la gestion efficace des ressources et
l’optimisation des performances du système par le biais de la prédiction de la performance future et
des exigences de capacité.
• 01 Évaluer la capacité, la performance et la disponibilité actuelles et créer une base de référence
• Base de référence de la disponibilité, de la performance et des capacités
• Évaluations au regard des SLA
• 02 Évaluer l’impact sur les métiers

• Scénarios de disponibilité, des performances et des capacités
• Évaluations d’impact sur les métiers des disponibilités, des performances et des capacités
• 03 Planifier les besoins pour les services nouveaux ou changés

• Améliorations priorisées
• Plans de performance et de capacité
• 04 Surveiller et faire la revue de la disponibilité et de la capacité

• Rapports des revues de disponibilité, performance et capacité
• 05 Enquêter sur et traiter les questions de disponibilité, de performance et de capacité

• Écarts de performance et de capacité
• Actions de corrections
• Procédure d’escalade d’urgence
• Nombre d’améliorations de la capacité, de la performance ou de la disponibilité non planifiées

• Nombre de pics de transaction où la performance cible est dépassée
• Nombre d’incidents de disponibilité
• Nombre d’événements où la capacité a dépassé les limites prévues
• % et nombre de questions de disponibilité, de performance et de capacité non résolus

22. Faciliter le changement organisationnel (BAI05)
Le but de ce processus est de préparer et susciter l’engagement des parties prenantes pour les changements
de l’entreprise et réduire le risque d’échec.
• 01 Établir le désir de changement

• Communiquer sur les facteurs déterminants du changement
• Communication des dirigeants s’engageant au changement
• 02 Constituer une équipe d’implantation efficace

• Équipe d’implantation et rôles
• Visions et objectifs partagés
• 03 Communiquer sur la vision désirée

• Plan de communication sur la vision
• Communications sur la vision
• 04 Mandater les acteurs et identifier les gains à court terme

• Objectifs de performance RH alignés
• Gains rapides identifiés
• Communications sur les bénéfices
• 05 Faciliter l’exploitation et l’usage

• Plan d’exploitation et d’usage
• Résultats et mesures de succès
• 06 Incorporer des nouvelles approches

• Résultats des audits de conformité
• Communications sur la conscientisation
• Résultats des revues de performance RH
• 07 Rendre le changement durable

• Plans de transfert de la connaissance
• Accord du management sur la communication
• Revues de l’utilisation opérationnelle
• Niveau du désir des parties prenantes pour le changement

• Niveau d’implication de la haute direction
• Nombre de problèmes identifiés de compétences ou de capacité
• Taux de satisfaction des parties prenantes touchées pour l’équipe de mise en œuvre
• Commentaires des parties prenantes sur le niveau de compréhension
• Nombre de requêtes reçues
• Commentaires des parties prenantes sur autonomisation
• % des acteurs avec autorité attribuée de manière appropriée
• % des acteurs formés
• Auto-évaluation des acteurs pour les capacités pertinentes
• Niveau de satisfaction des acteurs exploitant, utilisant et de maintenant le changement
• % utilisateurs formés adéquatement au changement
• Niveau de satisfaction des utilisateurs sur l’adoption du changement

23. Gérer les changements (BAI06)
Le but du processus est de faciliter la livraison rapide et fiable du changement de l’entreprise et

l’atténuation des risques négatifs impactant la stabilité ou l’intégrité de l’environnement modifié.
• 01 Effectuer l’évaluation de l’impact ; prioriser et autoriser les modifications

• Évaluations d’impact
• Requêtes de changement approuvées
• Plan de charge et agenda
• 02 Gérer les changements urgents

• Revue post-implantation des changements urgents
• 03 Suivre et rapporter sur les changements de statut

• Rapports sur les statuts des demandes de changement
• 04 Clôturer et documenter les changements

• Documentation des changements
• Quantité de travail causée par des changements en échec

• Réduction de temps et des efforts requis pour apporter des modifications
• Nombre et l’âge des demandes de modification accumulées
• % des changements en échec dus à des évaluations d’impact inadéquates
• % du totale des changements qui sont des correctifs d’urgence
• Nombre de changements d’urgence non autorisés après le changement
• Cotes de rétroaction des parties prenantes sur leur satisfaction à propos des communications

24. Accepter et mettre en œuvre les changements (BAI07)
Le but du processus est de mettre en œuvre en toute sécurité des solutions en ligne avec les attentes
et les résultats convenus.
• 01 Établir un plan d’implantation

• Plan d’implantation approuvé
• Retrait de l’implantation et processus de récupération
• 02 Planifier la conversion des processus métiers, des systèmes et des données
• Plan de migration
• 03 Planifier les tests d’acceptation

• Plan approuvé d’acceptation des tests
• 04 Établir un environnement de test

• Données de test
• 05 Exécuter les tests d’acceptation

• Journal des résultats des tests
• Évaluation des résultats de l’acceptation
• Acceptation approuvée et autorisation pour la mise en production
• 06 Promouvoir en production et gérer les lancements

• Plan des lancements
• Journal des lancements
• 07 Fournir un soutien précoce à la production

• Plan de support supplémentaire
• 08 Exécuter une revue post implantation

• Rapport de la revue de post implantation
• Plan d’action des remédiations
• % des parties prenantes satisfaites par la complétude du processus de test

• % et nombre des lancements pas prêts pour lancement à temps
• % des lancements ayant causé des temps d’arrêts
• % ou nombre des lancements qui échouent à se stabiliser dans un laps de temps raisonnable
• % et nombre d’analyses terminées sur les causes profondes

25. Gérer la connaissance (BAI08)
Le but du processus est de fournir les connaissances nécessaires à la prise de décision éclairée et à
amélioration de la productivité.
• 01 Faire éclore et faciliter une culture de partage de la connaissance

• Communications sur la valeur de la connaissance
• 02 Identifier et classifier les sources d’information

• Classification des sources d’information
• 03 Organiser et contextualiser l’information dans la connaissance

• Répertoires publiés de connaissance
• 04 Utiliser et partager la connaissance

• Base de données des utilisateurs de la connaissance
• Conscientisation à la connaissance et schémas de formation
• 05 évaluer et retirer l’information

• Résultats de l’évaluation de l’usage de la connaissance
• Règles pour retirer la connaissance
• % d’information couvert pour les catégories

• Volume d’information classifié
• % d’informations classifiées validées
• % de la connaissance disponible réellement utilisé
• Nombres d’utilisateurs entraînés à l’usage et au partage de la connaissance
• % de la connaissance du répertoire utilisé
• Niveau de satisfaction des utilisateurs
• Fréquence de mise à jour

26. Gérer les opérations (DSS01)
Le but du processus est de livrer les résultats des services opérationnels comme prévu.
• 01 Maintenir régulièrement les procédures opérationnelles

• Calendrier opérationnel
• Journal des sauvegardes
• 02 Gérer les services IT externalisés

• Plans d’assurance indépendante
• 03 Surveiller l’infrastructure IT

• Règles de surveillance des actifs et des conditions des événements
• Journal des événements
• Tickets des incidents
• 04 Gérer l’environnement

• Politiques relatives à l’environnement
• Rapports sur la politique d’assurance
• 05 Gérer les installations

• Rapports d’évaluation des installations
• Prise de conscience de la santé et la sécurité
• Nombre d’incidents provoqués par des problèmes opérationnels

• Nombre de procédures d’exploitation non-standard exécutées
• Ratio d’événements par rapport au nombre d’incidents
• % d’événements opérationnels critiques couverts par des systèmes de détection automatique

27. Gérer les actifs (DSS02)
Le but du processus est de justifier tous les actifs IT et d’optimiser la valeur fournie par ces actifs.
• 01 Identifier et enregistrer les actifs en cours

• Registre des actifs
• Résultats des contrôles physiques d’inventaire
• Résultats des revues fonctionnelles
• 02 Gérer les actifs critiques

• Communications des interruptions de service pour maintenance planifiées
• Contrats de maintenance
• 03 Gérer le cycle de vie des actifs

• Requêtes approuvées des demandes d’approvisionnement d’actifs
• Mise à jour du registre des actifs
• Autorisation de retrait des actifs
• 04 Optimiser le coût des actifs

• Résultats des revues d’optimisation des coûts
• Opportunités de réduire les coûts ou d’augmenter la valeur des actifs
• 05 Gérer les licences

• Registre des licences logicielles
• Résultats des audits des licences installées
• Plans d’actions pour ajuster le nombre de licences et leurs affectations
• % licences utilisées au regard des licences payées

• Benchmark des coûts
• Nombre d’actifs obsolètes
• Nombre d’actifs non utilisés

28. Gérer les configurations. (DSS03)
Le but du processus est de fournir suffisamment de renseignements sur les éléments de l’infrastructure
lors de l’évaluation de l’impact des changements et le traitement des incidents des services.
• 01 Établir et maintenir un modèle de configuration

• Étendue du modèle de gestion des configurations
• Modèle logique de configuration
• 02 Établir et maintenir un répertoire et un point de comparaison des configurations

• Répertoire des configurations
• Point de comparaison des configurations
• 03 Maintenir et contrôler les éléments de configuration

• Répertoire mis à jour des éléments de configuration
• Changements approuvés par rapport au point de comparaison
• 04 Produire des rapports de statut des configurations

• Rapports de statut des configurations
• 05 Vérifier et passer en revue l’intégrité du répertoire des configurations

• Résultats des vérifications physiques des éléments de configuration
• Écarts par rapport aux licences
• Résultats des revues de complétude du répertoire
• Nombre de divergences relatives à l’information de configuration incomplète ou manquante

• Nombre d’écarts entre le référentiel de la configuration et la configuration en service

29. Gérer les requêtes de service et les incidents (DSS04)
Le but du processus est d’atteindre une productivité accrue et de minimiser les perturbations grâce à
une résolution rapide des requêtes des utilisateurs et des incidents.
• 01 Définir les schémas de classification des incidents et des requêtes de services
• Modèles et schémas de classification des incidents et des requêtes de services
• Règles d’escalade des incidents
• Critères d’inscription des problèmes
• 02 Enregistrer, classifier et prioriser les requêtes et les incidents

• Journal des incidents et des requêtes de service
• Incidents et requêtes de service classifiées et priorisées
• 03 Vérifier, approuver et satisfaire les requêtes de services

• Requêtes de services approuvées
• Requêtes de service satisfaites
• 04 Investiguer, diagnostiquer et allouer les incidents

• Symptômes des incidents
• Journal des problèmes
• 05 Résoudre et récupérer des incidents

• Résolutions des incidents
• 06 Clôturer les requêtes de service et les incidents

• Requêtes de service et incidents clôturés
• Confirmation de l’utilisateur de résolution ou de réalisation satisfaisante
• 07 Suivre les statuts et produire des rapports

• Rapport de situation et des tendances des incidents
• Rapport sur les statuts de réalisation des requêtes et sur les tendances
• Temps moyen entre les incidents par service IT

• % et nombre incidents causant des perturbations aux processus critiques de l’entreprise
• % des incidents résolus dans un délai convenu et acceptable
• Niveau de satisfaction de l’utilisateur avec la réalisation des demandes de service
• Moyenne de temps écoulé pour traiter chaque type de demande de service

30. Gérer les problèmes (DSS05)
Le but du processus est d’accroître la disponibilité, améliorer les niveaux de service, réduire les coûts
et améliorer la commodité et la satisfaction de la clientèle, en réduisant le nombre de problèmes
opérationnels.
• 01 Identifier et classifier les problèmes

• Schéma de classification des problèmes
• Rapports sur le statut des problèmes
• Registre des problèmes
• 02 Investiguer et diagnostiquer les problèmes

• Causes profondes des problèmes
• Rapports de résolution des problèmes
• 03 Relever les erreurs connues

• Enregistrements des erreurs connues
• Solutions proposées aux erreurs connues
• 04 Résoudre et clore les problèmes

• Enregistrement des problèmes clos
• Communication sur la connaissance apprise
• 05 Effectuer une gestion proactive des problèmes

• Rapports de surveillance de la résolution des problèmes
• Identification des solutions durables
• % de problèmes qui ont été consignés dans le cadre de l’activité de gestion proactive
des problèmes
• % de solutions de contournement définies pour les problèmes ouverts
• % des incidents majeurs pour lesquels les problèmes ont été consignés
• Diminution du nombre d’incidents récurrents provoqués par des problèmes non résolus
• Nombre de problèmes pour lesquels une résolution satisfaisante adressant la cause profonde
a été trouvée

31. Gérer la continuité des affaires (DSS06)
Le but du processus est de poursuivre les opérations critiques de l’entreprise et de maintenir la disponibilité
de l’information à un niveau acceptable pour l’entreprise dans le cas d’une perturbation importante.
• 01 Définir la politique, les objectifs et la portée de la continuité des affaires

• Politique et objectifs pour la continuité des affaires
• Scénarios des incidents perturbateurs
• Évaluations des capacités actuelles de continuité et les écarts
• 02 Maintenir une stratégie de continuité

• Analyses d’impact sur les affaires
• Exigences de continuité
• Options stratégiques approuvées.
• 03 Développer et implanter une réponse de continuité d’affaire

• Actions et communications en réponse aux incidents
• Plan de continuité des affaires
• 04 Assurer la continuité des opérations

• Procédures de secours définies pour les processus d’affaires
• 05 Exercer, tester et passer en revue le plan de continuité des affaires

• Objectifs des tests
• Exercices de test
• Résultats des tests et recommandations
• 06 Examiner, maintenir et améliorer le plan de continuité

• Résultats des revues des plans
• Changements recommandés des plans
• 07 Conduire la formation au plan de continuité.

• Besoins en formation
• Résultats de la surveillance des aptitudes et des compétences
• 08 Gérer les accords de sauvegarde
• Résultats des tests de sauvegarde des données
• 09 Effectuer une revue post-reprise

• Rapport de la revue post-reprise
• Modifications approuvées pour les plans

• % des services IT satisfaisant aux exigences de disponibilité

• % de restaurations réussies et en temps opportun des copies de sauvegarde ou d’autres média
• % de média de sauvegarde transférés et stockés de manière sécurisée
• Nombre de systèmes critiques de l’entreprise non couverts par le plan
• Nombre d’exercices et de tests qui ont atteint les objectifs du rétablissement
• Fréquence des tests
• % des améliorations convenues au plan qui ont été reflétées dans le plan
• % des questions identifiées ont été traitées par la suite dans le plan
• % des parties prenantes internes et externes qui ont reçu une formation
• % des questions identifiées qui ont été abordées par la suite dans le matériel de formation

32. Gérer la sécurité de l’information (DSS07)
Le but du processus est de minimiser l’impact sur les affaires des vulnérabilités et des incidents relatifs
de sécurité de l’information.
• 01 Protection contre les logiciels malveillants

• Politique de prévention des logiciels malveillants
• Évaluations des menaces potentielles
• 02 Gérer la sécurité du réseau et de la connectivité

• Politique de sécurité de la connectivité
• Résultats des tests de pénétration
• 03 Gérer la sécurité des terminaux

• Politiques de sécurité pour les terminaux
• 04 Gérer l’accès et l’identité des utilisateurs

• Droits d’accès utilisateur approuvés
• Résultats des examens des comptes d’utilisateurs et des privilèges
• 05 Gérer la sécurité physique

• Requêtes d’accès approuvées
• Journal des accès
• 06 Gérer les documents sensibles et les périphériques de sortie

• Inventaire des dispositifs et des documents sensibles
• Privilèges d’accès
• 07 Gérer l’information sur les incidents de sécurité

• Caractéristiques des incidents de sécurité
• Enquêtes et revues sur les incidents de sécurité
• 08 Gérer le traitement des informations
• Nombre de vulnérabilités découvertes

• Nombre de violations de pare-feu
• Nombre d’incidents impliquant des terminaux
• Nombre de dispositifs non autorisés détectés sur le réseau ou dans l’environnement
de l’utilisateur final
• % des personnes recevant une formation de sensibilisation se rapportant à l’utilisation
des terminaux
• Nombre de comptes (par rapport au nombre d’utilisateurs et le personnel autorisé)
• Délai moyen entre le changement et la mise à jour des comptes
• Nombre d’incidents liés à la sécurité physique
• Note moyenne pour des évaluations de sécurité physique
• % tests périodiques des dispositifs de sécurité de l’environnement
• % des incidents de sécurité signalés par le personnel
• Magnitude moyenne des incidents signalés
• % des incidents soumis à une revue post incident

33. Gérer les contrôles des processus métiers (DSS08)
Le but du processus est de maintenir l’intégrité et la sécurité des actifs informationnels utilisés dans
les processus métiers dans l’entreprise ou externalisés.
• 01 Contrôler le traitement de l’information métier

• Résultats des revues de l’efficacité des traitements
• Analyses des causes profondes et recommandations
• 02 Gérer les rôles, responsabilités, privilèges d’accès et niveau d’autorisation

• Allocations des rôles et des responsabilités
• Allocations des niveaux d’autorité
• Droits d’accès alloués
• 03 Gérer les erreurs et les exceptions

• Preuves de correction des erreurs et des corrections
• Rapports d’erreurs et analyses des causes profondes
• 04 Assurer la traçabilité des événements informationnels et des responsabilités

• Exigences de rétention
• Enregistrement des opérations
• 05 Protéger les actifs informationnels

• Rapports des transgressions
• % complété de l’inventaire des processus critiques et des contrôles clés

• % couverture des contrôles clés dans les plans de test
• Nombre d’incidents et résultats d’audit indiquant l’échec de contrôles clés
• % des rôles des processus métiers avec les droits d’accès assignés et des niveaux d’autorité
• % des rôles des processus métiers avec une séparation des tâches claire
• Nombre d’incidents et de résultats d’audits à cause de violations d’accès ou de séparation
des tâches
• Nombre d’incidents et de résultats d’audits en raison de la mauvaise planification
• % scénarios de menace couverts dans les tests
• % d’achèvement des scénarios de menace du plan de continuité d’affaire avec des facteurs
de succès mesurables
• % de complétude de la traçabilité du journal des transactions
• Nombre d’incidents où l’historique des transactions ne peut pas être récupéré

34. Surveiller et évaluer la performance et conformité (MEA01)
Le but du processus est de fournir la transparence sur la performance et la conformité et de piloter la

réalisation des objectifs.
• 01 établir une approche de la surveillance

• Exigences de surveillance
• Objectifs de surveillance et métriques approuvés
• 02 Fixer des objectifs de performance et de conformité

• Objectifs de surveillance
• 03 Recueillir et traiter les données de performance et de conformité

• Données de surveillance traitées
• 04 Analyser la performance et rendre compte

• Rapports de performance
• 05 Assurer la mise en œuvre des actions correctives

• Mesures correctives et affectations
• Situations et résultats des actions
• % des objectifs et des métriques approuvés par les intervenants

• % des processus avec des objectifs définis et des métriques
• % des processus critiques surveillés
• % des processus dont les objectifs et les métriques sont revus et améliorés
• % des objectifs et des métriques alignés sur le système de surveillance de l’entreprise
• % des rapports de performance fournis à la date prévue

35. Surveiller le système de contrôle interne (MEA02)
Le but du processus est d’obtenir la transparence pour les parties prenantes clés sur l’adéquation du
système de contrôle interne et ainsi donner confiance dans les opérations, la confiance dans la réalisation
des objectifs de l’entreprise et une compréhension adéquate des risques résiduels.
• 01 Surveiller les contrôles internes

• Résultats de la surveillance du contrôle interne et des revues
• Résultats des benchmarks et autres évaluations
• 02 Passer en revue l’efficacité des contrôles des processus d’affaires

• Preuve de l’efficacité des contrôles
• 03 Exécuter des auto- évaluations de contrôle

• Plans et critères d’auto-évaluation
• Résultats des auto-évaluations
• Résultats des revues des auto-évaluations
• 04 Identifier et faire rapport sur les déficiences de contrôle

• Déficiences de contrôle
• Actions de correction
• 05 S’assurer que les prestataires de l’assurance sont indépendants et qualifiés

• Résultats des évaluations des fournisseurs d’assurance
• 06 Planifier les initiatives d’assurance

• Évaluations de haut-niveau
• Plans d’assurance
• Critères d’évaluation
• 07 Portée des initiatives d’assurance

• Portée des revues d’assurance
• Plan d’engagement
• Pratiques de revues d’assurance
• 08 Exécuter les initiatives d’assurance
• Portée raffinée
• Résultats de la revue d’assurance
• Faire rapport des revues d’assurance
• % des processus assurés comme étant conformes aux objectifs de contrôle interne
• % des processus avec des sorties assurées rencontrant les cibles dans les tolérances
• Nombre de faiblesses identifiées par des rapports externes de qualification et de certification
• % d’initiatives d’assurance suivant les normes de programme d’assurance et le plan approuvés
• % des processus recevant une revue indépendante

36. Surveiller et évaluer la conformité avec les exigences externes (MEA03)
Le but du processus est de s’assurer que l’organisation est conforme à toutes les exigences externes.
• 01 Identifier les exigences de conformité externes

• Répertoire des exigences de conformité
• Journal des actions de conformité requises
• 02 Optimiser la réponse aux exigences externes

• Mise à jour des politiques, des principes, des procédures et des normes
• Communication des exigences de conformité modifiées
• 03 Confirmer la conformité externe

• Écarts de conformité identifiés
• Confirmations de conformité
• 04 Assurer la conformité externe

• Rapports d’assurance de la conformité
• Rapports des problèmes de non-conformité et causes profondes
• Nombre d’exceptions de conformité n’ayant pas été identifiées sur base des exigences
• Nombre de questions de non-conformité critiques identifiées par an
• % de propriétaires de processus signant pour confirmer la conformité

III
Des objectifs d’entreprise à son SI :
la cascade et le TBE
A. La cascade
Un apport essentiel de CobiT est d’assurer le lien entre l’entreprise et son SI. Il y a évidemment le lien
créé par le partage des responsabilités entre métiers et DSI dans le fonctionnement des processus et
des pratiques de gouvernance et de gestion définis dans CobiT ; cette manière d’établir ce lien est traité
par ailleurs.
(Diagramme des Entités / Associations ; la vue « Cascade »)
Il est nécessaire de mettre ici en évidence une autre manière d’établir ce lien entre métiers et SI, de manière
plus structurelle, basée sur la proximité entre les processus CobiT et les objectifs d’entreprise.
Ce lien structurel est construit sur base de quelques objectifs d’entreprise génériques. CobiT en
propose, à titre exemplatif, 17, qui sont repris ci-dessous.

TBE Objectifs (métiers) Objectifs SI
d’Entreprise d’entreprise
Finance 1. Conformité avec les lois et les régulations externes 2, 10
2. Risques métiers gérés 4, 10, 16
3. Portefeuille compétitif de produits et services 1, 5, 7, 9, 12, 17
4. Valeur pour les parties prenantes des investissements d’affaire 1, 3, 5, 7, 11, 13
5. Transparence financière 6
Client 6. Culture orientée service au client 1, 7
7. Continuité & disponibilité du service pour les affaires 4, 10, 14
8. Réponses agiles à un environnement d’affaires changeant 1, 7, 9, 17
9. Prise de décision stratégique basée sur l’information 1, 14
10. Optimisation du coût de la fourniture de service 4, 6, 11
Interne 11. Optimisation des fonctionnalités des processus des métiers 1, 7, 8, 9, 12
12. Optimisation du coût des processus des métiers 5, 6, 11
13. Programmes gérés de changement métiers 1, 3, 13
14. Productivité opérationnelle & du personnel 8, 16
15. Conformités avec les règles internes 2, 10, 15
Apprentissage et 16. Collaborateurs compétents & motivés 16

croissance
17. Culture d’innovation produit & métier 9, 17
Les liens de chaque objectif d’entreprise générique avec les objectifs système d’information d’entreprise
sont repris dans le tableau ci-dessus. Seuls les liens considérés comme forts sont mentionnés ici; les
liens considérés comme moins intenses définis dans CobiT ne sont pas repris dans cette étude, afin
d’alléger le texte.
A nouveau, il appartient à chaque entreprise d’adapter ces liens à son contexte propre. Cette adaptation
des objectifs d’entreprises et de leurs liens avec les objectifs système d’information s’impose plus encore s’il
ne s’agit pas d’une entreprise mais d’une ONG, d’une administration publique, d’une collectivité locale…
Ce lien structurel depuis les Objectifs (métiers) d’Entreprise vers les Objectifs système d’information
d’entreprise constitue la première étape de la démarche en cascade.
CobiT établit ensuite un lien entre les Objectifs système d’information d’entreprise et les processus
CobiT. Seuls les liens considérés comme forts sont mentionnés ici ; les liens considérés comme moins
intenses ne sont pas repris dans cette étude, afin d’alléger le texte.
Ce lien aussi est officiellement exemplatif dans CobiT, mais il est évident qu’il est moins sensible aux
spécificités des contextes des entreprises ; le décliner dans l’entreprise ne devrait donc être envisagé
que sur base de motivations fortes.
Ce lien constitue la deuxième étape de la démarche en cascade qui permet donc en finale de lier Objectifs
métiers d’entreprise et processus CobiT.

B. Un « système expert » très abordable
Vues Objectifs SI Métriques du SI Processus

du TBE d’entreprise COBIT
Liés (p)
Finance 1. Alignement de • % des objectifs stratégiques et les exigences de l’entreprise pris en EDM01
l’IT et de la stratégie charge par les objectifs stratégiques de l’IT EDM02
d’entreprise • Satisfaction des parties prenantes avec portée du portefeuille APO01
des programmes et des services planifiés APO02
APO03
• % des facteurs déterminants de la valeur de l’IT en lien avec les facteurs
APO04
déterminants de la valeur pour l’entreprise
APO07
APO08
BAI02
2. Conformité de • Coût de la non-conformité de l’IT, y compris les accords et les amendes APO01
l’IT et soutien pour • Nombre de questions de non-conformité liées à l’IT rapportées au APO12
la conformité de ComEx ou causant des embarras ou des commentaires publics DSS07
l’entreprise avec les • Nombre de questions de non-conformité relatives aux accords MEA02
lois et règlements contractuels avec les fournisseurs de services de l’IT MEA03
externes • Couverture des évaluations de la conformité
3. Engagement du • % des rôles du Comex avec des responsabilités clairement définies pour EDM01
Comex pour prendre les décisions de l’IT EDM05
des décisions • Nombre de fois que l’IT est à l’ordre du jour du Conseil d’administration
relatives à l’IT de façon proactive
• Fréquence des réunions du Comité (exécutif) de stratégie de l’IT
• Taux d’exécution des décisions relatives à l’IT du Comex
4. Risques gérés • % des processus métiers critiques, des services informatiques et des EDM03
de l’entreprise reliés programmes d’entreprise facilités par l’IT couverts par une évaluation des APO10
à l’IT. risques APO12
• Nombre d’incidents majeurs reliés à l’IT qui n’étaient pas identifiés dans BAI01
l’évaluation des risques BAI06
• % des évaluations de risques de l’entreprise qui incluent les risques liés DSS01
à l’IT DSS04
• Fréquence de mise à jour du profil de risque DSS05
DSS06
DSS07
DSS08
MEA01
MEA02
MEA03
5. Bénéfices réali • % des investissements facilités par l’IT où la réalisation des bénéfices est EDM02
sés grâce aux inves surveillée dans l’ensemble du cycle de vie économique APO04
tissements et services • % des services informatiques où les avantages escomptés sont réalisés APO05
du portefeuille facilités • % des investissements liés à l’IT où les bénéfices déclarés sont atteints APO06
par l’IT ou dépassés BAI01
6. Transparence • % des cas d’affaire des investissements avec clairement définis et EDM02
des coûts, des approuvés les coûts et bénéfices attendus liés à l’IT. EDM03
bénéfices et des • % des services informatiques avec des frais d’exploitation et des avanta- EDM05
risques IT ges escomptés clairement définis et approuvés. APO06
• Sondage sur la satisfaction des parties prenantes clés au sujet de la trans APO12
parence, la compréhension et l’exactitude de l’information financière de l’IT DSS02

Liés (p)
Client 7. Livraison des • Nombre d’interruptions des affaires de l’entreprise dues aux incidents EDM01
services IT en ligne de services de l’IT EDM02
avec les besoins de • % des parties prenantes de l’entreprise satisfaites que la livraison EDM05
l’entreprise des services IT rencontre les niveaux de service convenus APO02
APO08
• % d’utilisateurs satisfaits de la qualité de la livraison des services
APO09
BAI02
BAI03
DSS07
DSS08
MEA01
MEA03
8. Emploi adéquat • % des propriétaires des processus métiers satisfaits par les produits APO04
des applications, et services IT les supportant
des informations • Niveau de compréhension des utilisateurs de la manière dont
et des solutions les solutions technologiques soutiennent leurs processus
technologiques • Niveau de satisfaction des utilisateurs avec les formations et
les manuels d’utilisateur

Liés (p)
Interne 9. Agilité IT • Niveau de satisfaction des dirigeants de l’entreprise avec la réactivité EDM04
de l’IT aux nouvelles exigences. APO01
• Nombre de processus métiers critiques supportés par des applications APO03
et des infrastructures modernes. APO04
APO07
• Temps moyen pour transformer les objectifs stratégiques de l’IT en
BAI08
une initiative convenue et approuvée
10. Sécurité de • Nombre d’incidents de sécurité causant perturbation dans l’entreprise EDM03
l’information, de ou un embarras public. APO12
l’infrastructure et des • Nombre des services IT avec des exigences de sécurité exceptionnelles DSS07
applications • Temps pour accorder, modifier et supprimer les privilèges d’accès, par
rapport aux niveaux de service convenus
• Fréquence d’évaluation de la sécurité par rapport aux dernières
normes et directives
11. Optimisation des • Fréquence des évaluations de la maturité de l’aptitude et de EDM04
actifs, des ressources l’optimisation des coûts APO01
et des aptitudes IT • Tendance des résultats des évaluations APO03
• Niveaux de satisfaction des entreprises et des responsables APO04
APO07
informatiques avec les frais IT et les aptitudes
BAI04
DSS01
DSS02
DSS05
MEA01
12. Facilitation et • Nombre d’incidents de traitement des affaires causés par des erreurs BAI02
soutien des processus d’intégration de la technologie BAI07
métiers en intégrant • Nombre de changements de processus métiers qui doivent être retar- DSS05
les applications et les dés ou remaniés en raison de problèmes d’intégration des technologies
technologies dans les • Nombre de programmes d’entreprise supportés par l’IT retardés ou
processus métiers
encourant des coûts supplémentaires en raison de questions
d’intégration de la technologie
• Nombre d’applications ou d’infrastructures critiques fonctionnant en
silos et non intégrées
13. La livraison de • Nombre de programmes/projets dans les délais et le budget APO05
programmes à temps, • % des parties prenantes satisfaites de la qualité du projet/programme APO07
respectant le budget et • Nombre de programmes nécessitant un important remaniement en APO11
satisfaisant aux exigen raison de défauts de qualité APO12
ces et normes de qualité BAI01
• Frais d’entretien des applications vs le coût de l’ensemble de l’IT
DSS05
14. Disponibilité • Niveau de satisfaction des utilisateurs avec la qualité de gestion de DSS05
d’informations fiables l’information DSS06
et utiles • Nombre d’incidents de processus d’affaires causés par la non
disponibilité de l’information
• Ratio et l’étendue des décisions d’affaires erronées dont
les informations erronées ou indisponibles étaient le facteur clé
15. Conformité de l’IT • Nombre d’incidents liés à la non-conformité aux règles EDM03
avec les règles internes • % des parties prenantes qui comprennent les règles APO01
• % des règles soutenues par des normes et des pratiques de travail MEA01
effectives MEA02
• Fréquence de mise à jour et de revue des règles

Liés (p)
Appren- 16. Personnel • % du personnel dont les compétences IT sont suffisants pour EDM04
tissage et informatique la compétence requise pour leur rôle APO01
croissance compétent et motivé • % du personnel satisfaits de leurs rôles IT APO07
• Nombre d’heures d’apprentissage et de formation par personne
17. Connaissance, • Niveau de sensibilisation et de compréhension des possibilités EDM02
l’expertise et les d’innovation IT des directions des métiers APO01
initiatives pour • Satisfaction des parties prenantes avec les niveaux d’expertise et APO02
l’innovation métier des idées de l’innovation IT APO04
APO07
• Nombre d’initiatives approuvés résultant d’idées novatrices IT BAI08
Cette démarche en cascade constitue à l’évidence une opportunité d’impliquer les directions des métiers
en leur demandant quelles sont leurs priorités parmi les objectifs d’entreprises et en leur montrant les
impacts de leurs décisions sur les processus CobiT.
Il est de bon conseil au DSI de lui suggérer de construire un « système expert » (en fait un simple tableur
Excel) qui automatise le fonctionnement de la cascade en question et qui peut constituer l’outil de base
pour aider les directions des métiers dans les orientations qu’elles souhaitent donner.
C. Le tableau de bord équilibré de la DSI

A chacun de ces objectifs système d’information sont associés des métriques du système d’information.
CobiT en propose 58, de manière exemplative toujours ; elles sont reprises dans le tableau ci-dessus.
Pour ces métriques aussi, CobiT les annonce comme étant exemplatives, mais leur définition est peu
sensible aux spécificités des contextes des entreprises. Lancer une démarche pour en décliner d’autres
ne devrait donc être envisagé que sur base de motivations fortes.
Par contre, les sélectionner toutes les 58 pour constituer le reporting du DSI vers sa DG est disproportionné ;
il sera bien d’établir, avec les directions des métiers, une sélection adaptée aux besoins de l’entreprise.
Et cette sélection sera bien évidemment basée sur les orientations issues du « système expert ».
Ces métriques constituent les éléments de base pour la constitution du TBE (Tableau de Bord
Equilibré de la DSI).

FINANCE
1. Alignement de l'IT et de la statégie
d'entreprise
2. Conformité de l'IT et soutien pour la
EDM BAI conformité de l'entreprise avec les lois et DSS
(évaluer, diriger (Bâtir, acquérir et implémenter) règlements externes (Délivrer, servir et supporter)
et surveiller) 3. Engagement du ComEx pour prendre des
Gérer Accepter etdécisions
mettre enrelatives à l'IT
Gérer les opérations
la connaissance œuvre les changements
4. Risques gérés de l'entreprise reliés à l'IT
Assurer la 5. Bénéfices réalisés grâce aux investissements
transparence et services du portefeuille facilités par l'IT Gérer les contrôles
Facilliter le changement
pour les parties Gérer les changements 6. Transparence des coûts, des bénéficeset des
organisationnelle des processus métiers
prenantes risques IT
et la capacité les solutions de l'information
Assurer la
l'optimisation Définir Gérer les programmes Gérer la continuité
des ressources les exigences et les projets Le des affaires
CLIENT
comment
7. Livraison des services IT
en ligne avec les besoins de Gérer les problèmes
l'entreprise APO
8. Emploi adéquat des (Aligner, planifier et organiser)
Assurer
applications, desla informations et APPRENTISSAGE Gérer les requêtes de
des solutions techniques Définir le cadre
l'optimisation
Définir
Gérer & service et incidents
du risque de gestion l'architecture CROISSANCE
la stratégie
de l'IT d'entreprise 16. Personnel informatique Gérer
compétent et motivéles configurations
Gérer 17. Connaissance,
Gérer Gérer l'expertise et les initiatives pour
Assurer la les budgets
l'innovation le portefeuille l'innovation métier Gérer les actifs
de la valeur
Gérer Gérer MEA
Gérer
INTERNE
10. Sécurité deles
humaines
relations de
l'information, de service
l'infrastructure et des applications Surveiller et
établir et 11. Optimisation des actifs, des Surveiller et Surveiller
apprécier la
maintenir le Gérer
ressources et des aptitudes évaluer la le système
carde de Gérer IT Gérer performance et de contrôle
conformité avec
12. lesFacilitation etlasoutuen
qualité des processus
les risques les exigences
gouvernance fournisseurs
métiers en intégrant les applications et les la conformité interne
externes
technologies dans les processus métiers
13. La livraison de programmes à temps,
respectant le budget et satisfaisant aux
exigences et normes de qualité
14. Disponibilité d'information fiables et
utiles
15. Conformité de l'IT avec les règles
internes

IV
L’instanciation des processus CobiT
Tels que présentés dans CobiT, chacun des 36 processus s’applique de manière uniforme à l’ensemble du
périmètre de l’entreprise. De manière uniforme signifie que tous les éléments caractérisant le processus
sont communs à l’ensemble de l’entreprise.
Il est donc nécessaire de recourir à l’instanciation des processus afin de supporter des mises en œuvre
différentiées lorsque cela est souhaitable.
Il est également nécessaire de mettre en évidence la différence entre les éléments liés à la définition des
processus et les éléments résultants de leur fonctionnement opérationnel.
Avoir des processus instanciés est directement utile par rapport à l’objectif de mise en œuvre effective
sur le terrain poursuivi dans le cadre de cette étude. Un processus instancié est en effet un processus
qui présente toutes les caractéristiques d’un processus exécutable.
A. Instancier les processus
Processus Les étages… Quels éléments ? Exemple

Processus • Ce sont les proces- • Les éléments génériques spécifiés • APO07
Générique sus tels que définis dans par CobiT
CobiT • Repris dans la description de
• Ils sont considérés la structure de CobiT ci-dessus
comme étant universels
de manière à garantir les
qualités de CobiT et la
possibilité de benchmar-
king

Processus • Ce sont les proces- • Le processus générique • APO07
Instancié sus tels qu’ils vont correspondant • Instanciation :
être mis en œuvre • Définition du périmètre : ~ Cadres IT
• En d’autres termes, ~ Le(s) axe(s) d’instanciation ~ Autres personnels IT / France
une instanciation (si nécessaire) ~ Autres personnels IT / Espagne
revient à créer une • Les éléments spécifiques à • Logiciel XYZ de suivi des
copie exécutable du l’entreprise définissant la manière prestations des personnels SI.
processus générique dont elle le met en œuvre : • Procédure visant à imposer aux
• C’est forcément ~ Procédures consultants extérieurs de se
spécifique à chaque ~ Définition des indicateurs conformer aux règles de
entreprise ~ Outillage l’entreprise en matière d’usage
~ Tableau des responsabilité des ressources du SI.
~ Inventaire des compétences ~ (APO07.06.3)
internes • La procédure envisagée ci-dessus
~ Plans d’actions visant à (APO07.06.3) peut évidemment
améliorer la maturité être la même pour les trois
~ … catégories de personnels
• Si des processus sont instanciés envisagées
plusieurs fois c’est à l’évidence
parce qu’ils ont des éléments
différents. Il est cependant
possible, voire recommandable,
de mutualiser certains éléments
entre eux lorsqu’il n’y a aucune
raison de les différentier

Occurrence de C’est la vue opérationnelle Toutes les occurrences des éléments • Taux de rotation du personnel SI
fonctionnement liée au fonctionnement liées au fonctionnement du processus en T1 2012 :
du processus des processus ~ Indicateur de APO07.
• Tableau d’utilisation des
ressources humaines du SI en
T1 2012 :
~ Sortie de APO07.05.
Remarques :
• Le processus est l’élément de base de la gouvernance du SI ; il est donc fortement

recommandable que l’instanciation soit définie à ce niveau.
• Il faut éviter l’instanciation sur base d’éléments de niveau inférieur au processus (tableaux des
responsabilités, pratiques de gestion et / ou de gouvernance …).
• La logique élémentaire impose que l’axe d’instanciation soit défini de manière à ce que les
instanciations ne se chevauchent pas et que l’ensemble des instanciations couvre la totalité du
périmètre de l’entreprise.

La figure Instanciation 1 ci-après représente (en ce qui concerne les pratiques de gestion) une instanciation
unique du processus APO07.
Instanciation unique du processus APO07
A contrario, la figure Instanciation 2 représente (toujours en ce qui concerne les pratiques de gestion)
les instanciations multiples du même processus APO07.
On remarquera que les instanciations ne se chevauchent pas et recouvrent la totalité du périmètre :

cadres et autres personnels, d’une part ; France et Espagne, d’autre part (les deux seuls pays dans le
périmètre de l’entreprise pour la lisibilité de l’exemple).
Enfin, la figure Instanciation 3 représente (toujours en ce qui concerne les pratiques de gestion) une
situation du processus APO07 qu’il est fortement recommandable d’éviter. Il y a une seule instanciation
du processus , mais certaines pratiques de gestion du processus sont différentiées.
Instanciations multiples du processus APO07

B. Quelles instanciations des processus ?
Adopter une instanciation unique d’un processus CobiT donné signifie évidemment uniformiser le
fonctionnement du processus en question sur l’ensemble du périmètre de l’entreprise.
A contrario, adopter des instanciations multiples d’un processus CobiT donné signifie donc accepter,
et promouvoir,– une différenciation de fonctionnement selon les parties concernées du périmètre de
l’entreprise visées par chacune des instanciations.
Instancier ou pas est donc une décision fortement structurante de la gouvernance du SI; le plan
d’instanciation des processus sera à l’évidence un élément essentiel du plan d’implantation de CobiT.
Ce tableau découlera directement de la gouvernance de l’entreprise avec laquelle il devra être en

harmonie.
Etablir la liste exhaustive des circonstances dans lesquelles il sera opportun d’instancier certains
processus est évidemment impossible.
• Les Pays
~ Législations différentes
• Ressources humaines
• Informatique & Liberté
• Droit commercial
• …
~ Langues différentes
• Le contrôle interne
~ Centralisé
~ Par branches
• L’organisation de la DSI
Les instanciations devront refléter les grandes caractéristiques de l’organisation du SI de l’entreprise ;
elles-mêmes en phase avec les principes de la gouvernance d’entreprise.
Dans l’exemple de plan d’instanciation ci-dessous, une typologie simpliste d’organisation des DSI a
été envisagée :
• Centralisée : DSI classique
• Fédérée : DSI Groupe pour la coordination uniquement et DSI des branches
• Décentralisée : DSI des branches
• Urbanisation du système d’information

~ L’urbanisation du système d’information est une politique de gestion du SI largement répandue
et fondamentalement basée sur un POS (Plan d’Occupation des Sols) définissant des zones homogènes
au regard des processus métiers et des applications informatiques correspondantes (cohérence forte à
l’intérieur de la zone, couplage faible avec l’extérieur); zones qui ont chacune leur gouvernance propre
dans le cadre de la gouvernance globale du système d’information
~ La liaison avec l’instanciation des processus CobiT est immédiate : de l’importance d’instancier
certains processus CobiT sur le périmètre de chacune de ces zones et qui marquent les raisons pour
lesquelles ces zones existent d’une part et d’autre part de ne pas instancier les autres processus CobiT qui
marquent l’appartenance de toutes ces zones à une gouvernance globale du système d’information

• Les achats du SI dans des grands groupes
~ Grands fournisseurs (éditeurs, matériel, réseau, conseil) du système d’information.
~ Petits fournisseurs et fournisseurs locaux.
• A mentionner, la situation particulière qui se présentera en cas de fusion / acquisition. Les deux
entreprises en phase de fusion présenteront des tableaux d’instanciation des processus fort proba-
blement différents. Une des premières actions à envisager dans le cadre de la création du SI cible de
l’entreprise fusionnée sera de définir le plan d’instanciation des processus du SI cible, de constater les
écarts par rapports aux plans correspondants des entreprises fusionnantes et d’en déduire les actions
à entreprendre.
Plan d’instanciation des processus (Exemple)

Identifiants Libellés Instancier ?
EDM01 Établir et de maintenir le • C’est le « processus père » à partir duquel tout ce qui concerne la gouvernance
cadre de gouvernance. du SI de l’entreprise va être décidé, dirigé et contrôlé. C’est un bon conseil d’éviter
de l’instancier
• Le présent exercice visant à établir quelques recommandations pour dresser le
tableau d’instanciation des processus relève précisément de ce processus EDM01
EDM02 Assurer l’optimisation Instancier par branche uniquement si la gouvernance d’entreprise le prévoit. Sinon une
de la valeur seule instanciation
EDM03 Assurer l’optimisation Idem que EDM02
du risque
EDM04 Assurer l’optimisation • Une instanciation par branche dans l’hypothèse d’une approche fortement
des ressources décentralisée du SI
• Une seule instanciation
~ dans l’hypothèse centralisée évidemment
~ dans l’hypothèse fédérée si la fédération porte aussi sur la gestion des ressources
• Veiller à la cohérence avec ce qui est décidé en ce qui concerne l’instanciation
d’EDM02 et d’EDM03
EDM05 Assurer la transparence Veiller à la cohérence avec les instanciations d’EDM02 à EDM04
pour les parties
prenantes
APO01 Définir le cadre de • Dépend manifestement de l’organisation cible de la DSI :

gestion du SI. ~ Une seule instanciation si l’organisation cible de la DSI est centralisée
~ Une instanciation pour chaque branche si l’organisation cible de la DSI
est décentralisée
~ Une instanciation pour chaque branche si l’organisation cible de la DSI est
fédérée et ne pas oublier de prévoir une instanciation différente pour
la DSI Groupe
• Veiller à la cohérence avec les instanciations d’EDM02 à EDM05
• Les choix décidés ici se répercutent d’office sur la plupart des processus suivants
APO02 Définir la stratégie • Une seule instanciation si l’organisation cible de la DSI est centralisée
• Une instanciation pour chaque branche si l’organisation cible de la DSI est
décentralisée et / ou fédérée

APO03 Gérer l’architecture • Une seule instanciation si l’organisation cible de la DSI est centralisée
d’entreprise • Une instanciation pour chaque branche si l’organisation cible de la DSI est
APO04 Gérer l’innovation • Une seule instanciation si l’organisation cible de la DSI est centralisée et / ou fédérée.
(Dans l’hypothèse où la gestion de l’innovation est fédérée)
décentralisée.
APO05 Gérer le portefeuille • Une seule instanciation si l’organisation cible de la DSI est centralisée
• Devrait être aligné avec APO03
APO06 Gérer les budgets et les • Une seule instanciation si l’organisation cible de la DSI est centralisée
coûts • Une instanciation pour chaque branche si l’organisation cible de la DSI est
APO07 Gérer les ressources • Une seule instanciation si l’organisation cible de la DSI est centralisée et / ou fédérée.
humaines (Dans l’hypothèse où la gestion des ressources humaines est fédérée)
• Une instanciation pour chaque branche si l’organisation cible de la DSI est décentralisée
• Un autre axe d’instanciation peut s’appliquer également :
~ Les personnels d’encadrement du SI gérés globalement : une seule instanciation.
~ Les autres personnels du SI gérés par DSI de branche : une instanciation
par branche.
• L’attention doit être attirée sur la forte influence des contextes nationaux (législations,
langues) sur ce processus et par conséquent sur la question de l’instancier par pays
APO08 Gérer les relations • Une seule instanciation si l’organisation cible de la DSI est centralisée
• Devrait être aligné avec APO03.
APO09 Gérer les accords de • Une seule instanciation si l’organisation cible de la DSI est centralisée
service • Une instanciation pour chaque branche si l’organisation cible de la DSI est
• Devrait être aligné avec APO03.
APO10 Gérer les fournisseurs • Une seule instanciation si l’organisation cible de la DSI est centralisée et / ou
fédérée. (Dans l’hypothèse où la gestion des fournisseurs est fédérée)
décentralisée
• Un autre axe d’instanciation peut s’appliquer également :
~ une seule instanciation au niveau Groupe pour les « grands fournisseurs » de
l’informatique (principaux éditeurs, principaux fournisseurs de matériels,
principaux fournisseurs d’accès réseau et principales SSII)
~ une instanciation par DSI de chaque branche pour les achats auprès d’autres
fournisseurs
APO11 Gérer la qualité • Une seule instanciation si l’organisation cible de la DSI est centralisée et / ou fédérée.
(Dans l’hypothèse où la gestion de la qualité est fédérée)
décentralisée

APO12 Gérer les risques • Une seule instanciation si l’organisation cible de la DSI est centralisée
• Une instanciation pour chaque branche si l’organisation cible de la DSI est décentrali-
sée et / ou fédérée
BAI01 Gérer les programmes Aligné sur APO03 et APO05

et les projets
BAI02 Définir les exigences • Aligné sur APO03
• Un autre axe d’instanciation peut s’appliquer également : instancier par zone du POS
(Plan d’Occupation des Sols) définie dans l’urbanisation du système d’information
BAI03 Identifier et construire Aligné sur BAI02
les solutions
BAI04 Gérer la disponibilité et • Aligné sur APO03
la capacité • Un autre axe d’instanciation peut s’appliquer également : instancier par type de
plateforme technique (mainframe, serveurs, cloud…)
BAI05 Faciliter le changement Aligné sur BAI02
organisationnel
BAI06 Gérer les changements Aligné sur BAI02
BAI07 Accepter et mettre en Aligné sur BAI02
œuvre les changements
BAI08 Gérer la connaissance Aligné sur BAI02
DSS01 Gérer les opérations Aligné sur EDM04
DSS02 Gérer les actifs Aligné sur EDM04
DSS03 Gérer les configurations Aligné sur EDM04
DSS04 Gérer les requêtes de • Aligné sur EDM04
service et les incidents • Un autre axe d’instanciation peut s’appliquer également : instancier en fonction de
la langue parlée par l’utilisateur final
• Autre axe d’instanciation possible : si l’application est accessible publiquement (par
des personnes n’appartenant pas au personnel de l’entreprise)
DSS05 Gérer les problèmes Aligné sur APO03
DSS06 Gérer la continuité des Aligné sur BAI04
affaires
DSS07 Gérer la sécurité de • Une seule instanciation si l’organisation cible de la DSI est centralisée et / ou fédérée.
l’information (Dans l’hypothèse où la gestion de la sécurité est fédérée)
décentralisée
DSS08 Gérer les contrôles des Aligné sur BAI02
processus métiers Attention à garder la cohérence avec les processus de contrôle (MEA)
MEA01 Surveiller et évaluer Aligné sur EDM05

la Performance et
conformité

MEA02 Surveiller le système de • Une seule instanciation si l’organisation cible de la DSI est centralisée et / ou fédérée.
contrôle interne (Dans l’hypothèse où le contrôle interne est fédéré)
décentralisée
MEA03 Surveiller et évaluer la • Aligné sur EDM05
conformité avec les • Les exigences externes sont fortement dépendantes des législations nationales.
exigences externes Des instanciations par pays peuvent être utiles

V
CobiT et l’urbanisation
du système d’information
L’objectif ici est de montrer qu’il est possible, utile et nécessaire d’utiliser le cadre COBIT pour définir une
politique d’urbanisation afin d’atteindre une meilleure compréhension de toutes les parties prenantes,
d’obtenir une meilleure intégration de l’urbanisation dans le dispositif global de gouvernance et de
gestion du SI et d’envisager toutes les voies possibles.
Ce qui suit n’est donc pas la définition d’une politique d’urbanisation mais un exemple de sélection
des éléments de COBIT utiles pour définir une urbanisation.
Cet exemple (probablement classifiable du côté d’une subsidiarité faible), n’étant qu’un cadre de
solution parmi tant d’autres possibles.
L’exercice proposé ici a aussi le mérite d’être déroulé dans le sens logique : de la gouvernance à
l’urbanisation…
Processus
Pratiques / Métriques CobiT Comment spécifier une politique d’Urbanisation du SI ?
CobiT
EDM01 Établir et de maintenir le cadre de gouvernance
01 Évaluer la conception de la • Inclure la politique d’urbanisation dans les principes de gouvernance
gouvernance IT d’entreprise • L’exprimer dans les livrables définis par COBIT
Sorties :
• Principes guidant la gouvernance
d’entreprise
• Modèle décisionnel
• Niveaux d’autorité
02 Diriger le système de • Une politique d’urbanisation du SI impacte fortement la gouvernance
gouvernance du SI, il est capital que le management exécutif de l’entreprise en soit
informé et la partage
• Prendre en compte les principes liés à l’urbanisation dans
l’établissement des
~ Zones fonctionnelles : Quelles zones ? Avec quel périmètre ?
~ Processus : Quelles instanciations de processus?
• Ces instanciations de certains processus étant bien
évidemment cadrées avec les périmètres des zones
fonctionnelles en question.
~ Structures de gouvernance : Avec quels RACI ?
~ Lister les pratiques de gestion et / ou de gouvernance impactées
• Avec des RACI exprimant fidèlement les principes de l’urbanisation :
~ Autonomie locale pour les zones fonctionnelles
~ Décision centralisée pour l’intégration de l’ensemble

Processus
CobiT
03 Surveiller le système de • évaluer périodiquement comment chaque acteur du SI est dans son
gouvernance rôle au regard de la politique d’urbanisation
• évaluer périodiquement comment fonctionnent les processus liés à
Sortie : l’urbanisation
Rétroactions sur l’efficacité et la
• évaluer l’efficacité de la politique d’urbanisation et identifier
performance de la gouvernance
des actions d’amélioration
• Inclure les résultats de ces activités dans le livrable
Métriques : • Satisfaction des parties prenantes par rapport à la démarche d’urbani-
• Niveau de satisfaction des parties sation
prenantes (mesurée par le biais de • Nombre de rôles liés à l’urbanisation définis, assignés et acceptés
sondages) • A quel degré la politique de l’urbanisation est effectivement mise en
• Nombre de rôles, de respon- place dans les processus / pratiques impliqués ?
sabilités et de pouvoirs qui sont
définis, assignés et acceptés
par les responsables appropriés
des métiers et de l’IT
• Degré auquel les principes
de gouvernance agréés sont
mis en évidence dans les proces-
sus et pratiques (% de processus
et pratiques avec traçabilité claire
des principes)
EDM02 Assurer l’optimisation de la valeur
01 Évaluer l’optimisation de la valeur • Comment la politique d’Urbanisation contribue-t-elle à la fourniture
d’un maximum de valeur par le SI ?
Sorties : • Le faire apparaître dans les livrables
• évaluation de l’alignement
stratégique
• évaluation des portefeuilles
d’investissements et de services
02 Diriger l’optimisation de la valeur • Faire apparaître les projets de construction des infrastructures liées à la
politique d’Urbanisation :
~ « Infrastructure logique » (modèle des données…).
~ Infrastructure applicative (logiciels ETL, EAI…).
~ Infrastructure matériel…
• Définir la manière de les financer.
~ Proportionnellement au chiffre d’affaire des BU ;
~ Proportionnellement à l’utilisation ;
~ De manière uniforme ;
~ …
03 Surveiller l’optimisation de la • établir comment la politique d’urbanisation a permis d’atteindre
valeur les objectifs en matière de création de valeur
• Le faire apparaître dans les livrables
Sorties :
• Rétroaction sur le rendement de
portefeuille et de programme
• Mesures pour améliorer la
livraison de valeur

Processus
CobiT
Métrique : Niveau de satisfaction des parties prenantes au regard de la contribution de
niveau de satisfaction des parties la politique d’urbanisation pour fournir de la création de valeur
prenantes avec la capacité des
entreprises d’obtenir de la valeur
d’initiatives IT
EDM03 Assurer l’optimisation du risque
01 Évaluer la gestion du risque • Déterminer les niveaux de risques liés à la politique d’urbanisation
~ Au niveau central
Sortie : ~ Pour chaque zone fonctionnelle
niveaux approuvés de tolérance au
risque Le faire apparaître dans les livrables
02 Diriger la gestion du risque Veiller à l’existence des règles de gestion du risque (central et de chaque
zone) ; et de leur alignement sur les niveaux de risques déterminés
Sortie : règles de gestion du risque
03 Surveiller la gestion du risque • Superviser les résultats de la politique d’Urbanisation au regard du
risque lié au système d’information
Sortie : • Proposer des actions correctives si nécessaire
mesures correctives pour traiter les
écarts de gestion des risques
Métrique : niveau d’alignement entre Mesurer l’impact de la politique d’urbanisation sur le niveau d’alignement
les risques informatiques et les risques des risques
de l’entreprise
EDM04 Assurer l’optimisation des ressources
01 Évaluer les stratégies IT pour se • Définir les principes de sélection, d’acquisition et d’allocation des
procurer les ressources ressources (personnel, technologies …) dans le cadre de la politique
d’urbanisation :
Sorties : ~ Centralement
• Principes directeurs pour ~ Pour chaque zone
l’allocation des ressources et • Définir les principes de gestion et de contrôle des ressources dans
des capacités le cadre de la politique d’urbanisation
• Principes directeurs pour • Définir les règles de gestion et de contrôle de l’architecture d’entreprise
l’architecture d’entreprise
Le faire apparaître dans les livrables
02 Diriger la gestion des ressources • Communiquer sur les principes d’allocation des ressources en fonction
de la politique d’urbanisation
Sorties : • Décider qui affecte les ressources aux projets liés à l’urbanisation :
• Communication des stratégies ~ En central
pour se procurer les ressources ~ Dans les zones.
• Responsabilités attribuées pour • Définir les métriques liées à l’engagement des ressources à la politique
la gestion des ressources d’urbanisation
Le faire apparaître dans les livrables

Processus
CobiT
03 Surveiller la gestion des Surveiller l’allocation des ressources au regard de la politique
ressources d’urbanisation. Proposer des actions de correction
Sorties : Le faire apparaître dans les livrables

• Commentaires sur la répartition et
de l’efficacité des ressources et des
capacités
• Mesures correctives pour traiter
les écarts de gestion des ressources
Métriques : • Veiller tout particulièrement à définir des indicateurs mettant en
• Nombre de déviations des évidence les effets bénéfiques d’une politique d’Urbanisation sur la
stratégies du plan des ressources gestion des ressources du SI ; calculer ces indicateurs avant le
et de l’architecture d’entreprise démarrage de la mise en œuvre pour avoir une référence et suivre
• Avantages (p. ex., les économies leur évolution
de coûts) grâce à une utilisation ~ Par exemple : temps moyen de développement d’une interface
optimale des ressources • Nombre de déviations par rapport à la politique d’urbanisation et par
• % projets qui s’alignent sur les rapport à son plan de ressources
principes de l’architecture • Gains liés à une meilleure utilisation des ressources dans le cadre
d’entreprise d’une politique d’urbanisation
• % de réutilisation des • % des projets alignés sur les principes d’urbanisation
composants de l’architecture • % de ré-utilisation des composants
EDM05 Assurer la transparence pour les parties prenantes
01 Évaluer les exigences en Bien identifier l’ensemble des parties prenantes du système d’information
rapports des parties prenantes liées à la politique d’Urbanisation
02 Rapporter et communiquer aux Fixer les règles de communication entre les parties prenantes de la
parties prenantes directes politique d’urbanisation :
• Central / Zones
Sorties : • Entre zones
• Règles pour valider et approuver
les rapports obligatoires Faire apparaître la politique d’urbanisation dans les livrables
• Directives pour l’escalade
03 Surveiller la communication des Évaluer la communication vers les parties prenantes au regard de la
parties prenantes politique d’urbanisation
Métrique : % des parties prenantes liées à la politique d’Urbanisation couvertes par
% des parties prenantes couvertes les reportings
dans les exigences de reporting

Processus
CobiT
APO01 Définir le cadre de gestion de l’IT
01 Définir la structure • Définir et mettre en place toutes les fonctions, équipes, comités… liés
organisationnelle à la politique d’urbanisation
~ Préciser leurs droits de décision
Sorties : ~ Établir les directives les concernant
• Définition de la structure ~ Impliquer les personnes liées (par RACI)
organisationnelle et des fonctions • Aligner l’organisation liée à l’Urbanisation et les modèles
• Directives opérationnelles organisationnels définis dans l’architecture d’entreprise
d’organisation
Faire apparaître la politique d’urbanisation dans les livrables
02 Établir les rôles et Intégrer la politique d’Urbanisation dans la définition des rôles et
responsabilités. responsabilités liés au SI
Sortie :
Définition des rôles et responsabilités
liés à l’IT
03 Maintenir les facilitateurs du Encourager la coopération et le travail d’équipe de l’ensemble des acteurs
système de gestion de la politique d’Urbanisation
04 Communiquer les objectifs de Communiquer sur la mise en œuvre de l’Urbanisation à destination de
gestion et la direction l’ensemble des acteurs des processus
Sortie :
Communications sur les objectifs IT
05 Optimiser le positionnement de Positionner correctement dans l’organigramme la cellule en charge de
la fonction IT l’urbanisation
06 Définir la propriété des • Intégrer les principes de l’Urbanisation dans la définition de la propriété
informations (données) et du système des données et des systèmes
• Définir les éléments du langage commun utilisé pour la communication
Sorties : entre les zones fonctionnelles
• Directives pour la classification • Sélectionner les standards de communication sectoriels
des données
• Directives pour la sécurité et Faire apparaître la politique d’Urbanisation dans les livrables
le contrôle des données
• Procédures sur l’intégrité
des données
08 Assurer la conformité avec les Mettre en place des procédures qui prennent en compte la mise en œuvre
règles et les procédures d’une politique d’urbanisation
Métriques : % des règles, normes et autres facilitateurs actifs, relatifs à la mise en
% des règles, normes et autres œuvre de la politique d’Urbanisation, documentés et mis à jour
facilitateurs actifs, documentés et mis
à jour
APO02 Définir la stratégie

01 Comprendre la direction de Identifier à l’aune de la stratégie d’entreprise et des principes de la politique
l’entreprise d’Urbanisation les faiblesses de l’architecture d’entreprise. Les corriger
02 Évaluer l’environnement actuel, les A faire centralement et pour toutes les zones définies dans l’Urbanisation ;
aptitudes et la performance selon les règles de gouvernance de la politique d’Urbanisation définies
dans l’entreprise

Processus
CobiT
03 Définir les aptitudes cible du Idem
système d’information
04 Conduire une analyse des écarts Idem
05 Définir le plan stratégique et la Idem
feuille de route
Faire apparaître la politique d’Urbanisation dans les livrables
Sorties :
• Définition des initiatives
stratégiques
• Évaluation des risques
• Feuille de route stratégique
06 Communiquer la stratégie IT et Idem
la direction
Métriques : • Montrer l’impact de la mise en œuvre de la politique d’Urbanisation
• % des objectifs d’entreprise pris sur ce %
en charge dans la stratégie IT • Montrer l’impact de la mise en œuvre de la politique d’Urbanisation
• Tendances des ROI des initiatives sur les ROI
inclues dans la stratégie IT • Montrer l’impact de la mise en œuvre de la politique d’Urbanisation
• % des initiatives et projets IT sur ce %
défendues par les responsables
métiers
APO03 Gérer l’architecture d’entreprise
01 Développer la vision de Y intégrer les principes de la politique d’Urbanisation
l’architecture d’entreprise
Pour ce qui relève :
Sorties : • de ce qui est central
• Portée définie de l’architecture • de ce qui est dans les zones
• Principes d’architecture
• Cas d’affaire et proposition de Identifier les objectifs d’entreprise à prendre en compte dans chaque zone
valeur de l’architecture fonctionnelle ; et ceux à prendre en compte globalement
conceptuelle
Faire apparaître la politique d’Urbanisation dans les livrables
02 Définir l’architecture de référence Y intégrer les principes de la politique d’urbanisation
Sorties : Ces sorties constituent à l’évidence des éléments particulièrement

• Description des domaines de déterminants découlant de la politique d’Urbanisation.
base et définition de l’architecture
• Modèle d’architecture des
processus
• Modèle d’architecture de
l’information
03 Sélectionner les opportunités et Idem
les solutions
04 Définir l’implantation de Idem
l’architecture
05 Fournir des services Idem
d’architecture d’entreprise

Processus
CobiT
Métriques : • Nombre d’exceptions aux principes de la politique d’urbanisation
• Nombre d’exceptions aux • Bénéfices réalisés par les projets imputables à l’utilisation de
standards d’architecture l’urbanisation
demandées et accordées • Date de dernière mise à jour des livrables d’APO03
• Bénéfices réalisés par les projets
qui peuvent être imputés à
l’utilisation de l’architecture (par
exemple : réduction des coûts par
le biais de re-use)
• Date de dernière mise à jour
des architectures de domaines
ou fédérales
APO04 Gérer l’innovation Pas d’impact lié à la politique d’urbanisation
APO05 Gérer le portefeuille
01 Établir le mix cible Intégrer la dimension « global / zones » dans les portefeuilles
d’investissement
02 Déterminer la disponibilité et la Identifier les fonds :
source des financements • Globaux pour la politique d’intégration
• Globaux à répartir entre les zones
• Propres à chaque zone
APO06 Gérer les budgets et les coûts
03 Évaluer et sélectionner les Intégrer la dimension « global / zones » dans le choix des programmes.
programmes à financer
01 Gérer les finances et la Intégrer la politique d’urbanisation (global / zones) dans les règles
comptabilité comptables, avec pour objectif de pouvoir identifier les coûts liés à chaque
zone et à la politique d’intégration
• Processus comptables
• Schéma de classification Faire apparaître la politique d’Urbanisation dans les livrables
des coûts de l’IT
• Pratiques de planification
financière
02 Prioriser l’allocation des Faire apparaître la politique d’Urbanisation dans les livrables :
ressources • Les priorisations globales et les priorisations par zone
• Idem pour les allocations
Sorties :
• Hiérarchisation et classement
des initiatives IT
• Allocations budgétaires
03 Établir et maintenir les budgets. Intégrer la politique d’Urbanisation dans l’établissement des budgets.
Notamment :
• Un budget par zone fonctionnelle
• Un budget pour l’intégration globale
04 Modéliser et allouer les coûts Intégrer la politique d’Urbanisation dans le modèle d’allocation des coûts
APO07 Gérer les ressources humaines Pas d’impact lié à la politique d’urbanisation

Processus
CobiT
APO08 Gérer les relations
01 Comprendre les attentes de Un but essentiel d’une politique d’urbanisation est de mieux identifier
l’entreprise les besoins des métiers en veillant à distribuer au plus près des métiers
l’écoute de leurs besoins
Sortie :
Attentes de l’entreprise clarifiées et
convenues
02 Identifier les opportunités, les Idem
risques et les contraintes pour l’IT
améliorer l’entreprise
03 Gérer les relations avec les Cadrer le périmètre de responsabilité des gestionnaires des relations sur le
métiers périmètre des zones fonctionnelles
Sorties : Veiller à organiser une procédure d’escalade des difficultés des zones
• Décisions clés convenues fonctionnelles
• Plaintes et statuts d’escalade
Métrique : Une politique d’urbanisation doit déboucher sur un meilleur alignement.
- % d’alignement des programmes Il est de bon conseil de mettre cet indicateur en place avant la mise en
avec les besoins de l’entreprise œuvre et de suivre son évolution afin de montrer le bien-fondé de la
politique d’urbanisation
APO09 Gérer les Accords de service Pas d’impact lié à la politique d’urbanisation
APO10 Gérer les fournisseurs Pas d’impact lié à la politique d’urbanisation
APO11 Gérer la qualité Pas d’impact lié à la politique d’urbanisation
APO12 Gérer les risques Pas d’impact lié à la politique d’urbanisation
BAI01 Gérer les programmes et les projets Pas d’impact lié à la politique d’urbanisation
BAI02 Définir les exigences
Ce processus devrait être instancié :
• Une instanciation unique traitant de l’approche globale du SI
• Une instanciation différente pour chaque zone fonctionnelle.
Comme expliqué plus-haut (voir instanciation) :

• Ceci implique que chaque pratique de gestion de ce processus est
également instanciée de la même manière
• Certains éléments peuvent être mis en commun tels les procédures
01 Définir et maintenir les besoins Définir une procédure commune à toutes les zones fonctionnelles de
fonctionnels et techniques de définition et de mise à jour des exigences (métiers et techniques), y compris
l’entreprise les priorisations, les validations par les métiers
Sorties : Les sorties seront donc spécifiques à chaque zone fonctionnelle mais
• Référentiel de définition respecteront une même procédure
des exigences
• Confirmation d’acceptation des
exigences des parties prenantes
• Enregistrement des demandes
de changement des besoins
02 Effectuer une étude de faisabilité et Idem
formuler des solutions alternatives

Processus
CobiT
03 Gérer les risques liés aux Idem
besoins
04 Obtenir l’approbation des Idem
besoins et des solutions
Métriques : Une politique d’urbanisation doit déboucher sur un meilleur alignement.
• % des besoins revus en raison du Il est de bon conseil de mettre ces indicateurs en place avant la mise
mauvais alignement avec les en œuvre et de suivre leur évolution afin de montrer le bien fondé de la
attentes et les besoins des politique d’urbanisation.
entreprises
• Satisfaction des parties prenantes
aux besoins
BAI03 Identifier et construire les solutions A instancier, en ligne avec BAI02
BAI04 Gérer la disponibilité et la capacité Pas d’impact lié à la politique d’urbanisation
BAI05 Faciliter le changement organisationnel Dans une acception poussée d’une politique d’Urbanisation : à instancier,
en ligne avec BAI02
Mais ne pas l’instancier si nécessité, par exemple, d’une maturité forte sur
le processus
BAI06 Gérer les changements Idem
BAI07 Accepter et mettre en œuvre les Idem
changements
BAI08 Gérer la connaissance Idem
DSS01 Gérer les opérations Pas d’impact lié à la politique d’urbanisation
DSS02 Gérer les actifs Pas d’impact lié à la politique d’urbanisation
DSS03 Gérer les configurations Pas d’impact lié à la politique d’urbanisation
DSS04 Gérer les requêtes de service et les Pas d’impact lié à la politique d’urbanisation
incidents
DSS05 Gérer les problèmes Pas d’impact lié à la politique d’urbanisation
DSS06 Gérer la continuité des affaires Pas d’impact lié à la politique d’urbanisation
DSS07 Gérer la sécurité de l’information Pas d’impact lié à la politique d’urbanisation
DSS08 Gérer les contrôles des processus Dans une acception poussée d’une politique d’Urbanisation : à instancier,
métiers en ligne avec BAI02
Mais ne pas l’instancier si nécessité, par exemple, d’une maturité forte sur
le contrôle (en phase avec les processus du domaine MEA)
MEA01 Pas d’impact lié à la politique d’urbanisation

VI
Les acteurs
A. Des « rôles » aux « acteurs »
Toujours dans la perspective opérationnelle du présent ouvrage, un élément important au regard de la
gouvernance du SI et de CobiT est bien évidemment l’attribution des responsabilités.
Les rôles et les comités ainsi que les responsabilités des pratiques ont été présentés plus haut, dans la
partie CobiT.
Mais la question essentielle au regard de la mise en œuvre est : qui va exercer quelle responsabilité ?
C’est-à-dire passer des « rôles » aux « acteurs ».

En se reportant à la structure de CobiT, il s’agit donc de déterminer les responsabilités des acteurs du
système d’information par rapport aux pratiques de gestion et de gouvernance et ce de manière qui
soit adaptée à l’Entreprise.
1. Déterminer les rôles et les structures de l’entreprise
CobiT a prévu des rôles et des structures standards. (Voir chapitre II, point D.). Comme souvent
mentionné pour nombre d’éléments de CobiT, ce sont simplement des suggestions ; et c’est justement
sur ce sujet des rôles et structures qu’il faut le plus s’interroger sur leur adéquation à l’Entreprise.
Il va donc falloir définir les rôles et structures spécifiques à l’entreprise qui vont être impliqués dans
la gouvernance et la gestion du système d’information :
• Identifier les rôles et structures qui existent déjà

• Définir les rôles et structures n’existant pas et qu’il serait raisonnable de mettre en place
Cet exercice sera conduit de deux manières différentes, selon qu’il s’agit de rôles et structures métiers ou
internes à la DSI. Dans le premier cas, l’implication de l’ensemble des directions métiers sera nécessaire
alors que dans le second, le DSI seul peut décider.
Retenons quelques conseils évidents valables dans les deux cas :
• Prendre d’abord en compte la culture de l’entreprise

• Adapter à la taille de l’entreprise
• éviter de multiplier rôles et structures qui ne feraient que compliquer inutilement la
gouvernance et la gestion
CobiT a également identifié les comités suivants :
• Comité Exécutif de la Stratégie

• Comité directeur (Programmes / Projets)
• Comité d’architecture
• Comité des risques d’entreprise
Le même type de démarche devrait s’y appliquer.
2. Comment exprimer le rapport de chaque rôle et / ou structure aux pratiques de CobiT ?
CobiT a prévu d’exprimer ce rapport sous la forme du RACI (Voir chapitre II, point D.) et propose pour
chaque pratique de gouvernance et /ou de gestion une responsabilité pour chacun des rôles et comités
décrits dans CobiT (c’est au final une matrice de 208 sur 26 !).
Sur ce sujet aussi, il est de bon conseil d’adapter au mieux en fonction des spécificités de l’entreprise.
Chacun connaît les difficultés de la traduction du RACI (en particulier pour le A) ; cette étude
s’aligne sur la traduction ci-dessous plus communément admise en France :
• R: Réalisateur
• A: Autorité
• C: Consulté
• I: Informé

Le RACI devra respecter d’abord quelques règles mécaniques très générales ; ainsi pour chaque pratique
de gestion ou de gouvernance :
• Il faut un A
• Il ne faut qu’un seul A
• Il faut au moins un R
… et quelques bons conseils pratiques :
• éviter de multiplier inutilement des A différents pour les pratiques d’un même processus.
Autrement dit, lorsque c’est possible, aligner toutes les pratiques d’un même processus sur
le même A. Ce conseil est basé sur la cohérence à promouvoir au niveau du processus
• Pour une pratique donnée, le rang hiérarchique du A ne peut pas être inférieur à celui du (ou des) R
• Veiller à respecter les principes de la séparation des tâches. (« Segregation of duties »)
• S’il y a plusieurs R pour une pratique, il est préférable qu’ils aient des niveaux
hiérarchiques comparables
• éviter de multiplier les R pour une même pratique. La lecture des tableaux RACI proposés par
CobiT montre une profusion de R : parfois jusqu’à … 12 R pour une pratique ! Evidemment
lorsqu’il sera décidé, dans un esprit d’efficacité opérationnelle, de s’écarter des R prévus par
CobiT ils devront obligatoirement être impliqués dans la pratique, ce qui se fera par le biais d’un C.
D’autres manières que RACI peuvent être utilisées pour exprimer ce rapport aux pratiques. Certaines
entreprises sont probablement habituées à la notation proposée par le Cigref dans le cadre de son
travail sur « les parties prenantes du système d’information » ; dans ce cas pourquoi pas l’adopter
dans le cadre CobiT ? :
• Pilote (est responsable)

• Réalise (est en charge)
• Apporte un soutien
• Contrôle
• est Informé
• est Consulté
• Audite
Le même système sera utilisé pour le rapport des comités aux pratiques que celui utilisés pour les
Rôles.
3. Rapprocher les rôles CobiT des définitions de fonction des acteurs du système
d’information de l’entreprise
Ce rapprochement finalise la démarche puisqu’il met les acteurs (donc des personnes humaines) dans
des rôles.
Rapprocher ces deux concepts est un pas important de la mise en œuvre de CobiT, pour les raisons
suivantes :
• La définition de fonction est dans l’organisation du travail le lieu où l’entreprise définit

les responsabilités de ses collaborateurs
• La définition de fonction est très largement utilisée dans les entreprises et communément admis
• Il est très fréquent que les définitions de fonctions soient écrites et validées tant par la hiérarchie
que par le collaborateur ce qui contribue à l’amélioration de la maturité de la mise en œuvre.

C’est la raison pour laquelle il est intéressant de se pencher sur la nomenclature des emplois-métiers
du Cigref qui fait référence sur ce sujet dans beaucoup de DSI et de son rapport à CobiT.
B. CobiT et la cartographie des compétences

La nomenclature des emplois-métiers est publiée et mise à jour régulièrement par le Cigref. Nous nous
basons ici plus précisément sur la version 2011 : « Les métiers des Systèmes d‘Information dans les
grandes entreprises. Nomenclature RH – 2011 ».
C’est évidemment un document de référence largement utilisé par les responsables des SI (et des RH).
A ce titre, il constitue un élément important pouvant contribuer à la mise en œuvre de CobiT.
Quel est l’intérêt de rapprocher CobiT de la nomenclature des emplois-métiers du Cigref ? Il est
multiple :
• Pour montrer que les rôles tels qu’ils sont couramment définis dans les DSI en France, de manière
souvent conforme à la nomenclature du Cigref, sont tout à fait compatibles avec une approche CobiT
• Pour montrer que des styles de gestion typiquement français, bien pris en compte par la nomenclature
du Cigref, sont également tout à fait compatibles avec CobiT. C’est notamment le cas pour ce qui
concerne l’urbanisation du SI et pour les concepts de MOA / MOE.
• Parce que la nomenclature a une notoriété très forte ; capitaliser sur cette notoriété peut être un
levier pour atteindre une meilleure diffusion de CobiT. Par exemple par le biais des descriptions de
fonctions
• Pour aider les parties prenantes du SI à prendre en charge correctement leurs responsabilités de
gouvernance définies dans CobiT en les rapprochant des emplois-métiers et des activités prévues par
la nomenclature, ceux-ci étant généralement mieux connus et maîtrisés que celles-là
Il est évident que la nomenclature des emplois-métiers ne vise pas à couvrir :
• Les comités
~ Par définition il ne s’agit pas d’emplois-métiers ; ils n’ont pas leur place dans
la nomenclature des emplois-métiers
~ Dans CobiT, les comités suivants sont définis :
• Conseil d’administration
• Comité Exécutif de la Stratégie
• Comité directeur (Programmes / Projets)
• Comité d’architecture
• Comité des risques d’entreprise
• Les emplois-métiers de l’Entreprise en dehors de ceux de son SI
~ étant hors SI, ils n’ont pas leur place dans la nomenclature du SI
~ Dans CobiT, les parties prenantes externes suivantes sont définies :
• PDG
• Directeur des finances
• Directeur des opérations
• Directeurs des métiers
• Propriétaires des processus métiers
• Directeur des Risques
• Directeur de la sécurité de l’information
• Directeur des ressources humaines
• Conformité
• Audit

• Voir les dessins ci-dessous (rôles CobiT et emplois-métiers de la nomenclature Cigref »).
Les parties prenantes hors DSI y sont représentées sur fond bleu.
A contrario, la nomenclature définit certains-emplois métiers qui, en première analyse, ne semblent pas
jouer de rôle dans la gouvernance et / ou la gestion du système d’information.
C’est le cas par exemple de :
• 3.2 Concepteur - développeur

• 3.3 Testeur
• 3.4 Intégrateur d’applications
• 3.5 Paramétreur de logiciels
• 4.1 Technicien d’exploitation
• 4.2 Technicien poste de travail
• 4.3 Technicien réseaux-télécoms
• 4.4 Administrateur d’outils / de systèmes / de réseaux-télécoms
• 4.5 Administrateur de bases de Données
• 4.6 Intégrateur d’exploitation
• 4.7 Pilote d’exploitation
• 4.8 Expert systèmes d’exploitation
• 4.9 Expert réseaux - télécoms
• 5.1 Assistant fonctionnel
• 5.2 Technicien support utilisateurs
Il est cependant utile d’effectuer pour eux aussi ce rapprochement avec CobiT, de manière à aider les
titulaires de ces emplois-métiers à se situer dans le contexte global du fonctionnement du SI et donc à
les aider à s’y intégrer harmonieusement.
Il est important de rappeler que ce rapprochement entre CobiT et la nomenclature des emplois-
métiers est exemplatif et qu’il doit être adapté à son environnement spécifique par chaque entreprise
potentiellement intéressée de parcourir cette démarche.
1. Le rapprochement par l’appellation des emplois-métiers
Ce rapprochement rapide essaye de mettre en rapport les rôles définis par CobiT et les emplois-métiers
du CIGREF sur base de leur intitulé.
Rôles CobiT & Emplois-métiers

de la nomenclature Cigref (1)
A gauche, sont indiqués les rôles et les structures identifiés dans CobiT ; à droite est indiquée la
nomenclature des métiers des systèmes d’information du CIGREF.
Le rapprochement est immédiat pour :
• Le DSI (Cigref 7.1)

• Le responsable des opérations (Cigref 7.4)
• Le responsable des développements (Cigref 7.5)
• Le responsable de la sécurité de l’information (Cigref 6.3)
Ces rapprochements sont représentés par des traits continus.

Rôles CobiT & Emplois-métiers
de la nomenclature Cigref (2)
Il n’y a pas d’autres rapprochements immédiats.
Par exemple :
• Le responsable de l’architecture : il faut faire le rapprochement avec deux fonctions différentes

de la nomenclature : l’urbaniste (Cigref 1.2) et l’architecte technique (Cigref 4.10)
• Le responsable de l’administration IT pour sa part ne donne pas lieu à un métier identifié dans
la nomenclature
• Les responsabilités du Bureau Projet sont elles aussi une combinaison des responsabilités du
Directeur de projets (Cigref 2.1), du Chef de projet Maîtrise d’Ouvrage (Cigref 2.2) et du Chef
de projet maîtrise d’œuvre (Cigref 2.3)
• Le Bureau gestion de la valeur est à rapprocher du Responsable du SI « métier » (Cigref 1.3) qui
a à l’évidence un périmètre plus large de responsabilités.
En conséquence, il n’est pas conseillé de procéder au rapprochement CobiT / nomenclature des

emplois-métiers de la sorte. Mettre en évidence ce rapprochement sur base des activités et tâches
prévues par la nomenclature d’une part et des processus et pratiques de CobiT d’autre part sera
beaucoup plus productif.
2. Le rapprochement sur base des activités et des tâches de la nomenclature et

des processus et pratiques de CobiT
Ce rapprochement est proposé dans le tableau ci-dessous. La colonne de gauche reprend les emplois-
métiers définis dans la nomenclature.
La colonne centrale mentionne les activités prévues dans cette nomenclature pour l’emploi-métier
correspondant.
La colonne de droite mentionne les processus et pratiques de CobiT qui y correspondent.

Pour alléger le texte, les tâches prévues pour chaque activité de la nomenclature ne sont pas reprises ;
cependant leur ordre est conservé pour mentionner les processus et pratiques de CobiT.
Seuls les identifiants des pratiques CobiT sont mentionnés, les libellés ne sont pas repris toujours afin
d’alléger le texte.
Avant d’être rendu opérationnel dans une entreprise, ce rapprochement doit prendre en compte plusieurs
éléments non inclus ici :
• La nature de la responsabilité exercée par l’emploi-métier sur le processus et / ou pratique de

CobiT correspondant, avec une expression de type RACI, par exemple
• Le périmètre sur lequel s’applique ce rapprochement doit être spécifié, par exemple une seule
application ou l’ensemble des applications
• Le contexte propre à chaque entreprise comme déjà mentionné plusieurs fois
• Certains processus CobiT sont peu ou pas couverts et doivent faire l’objet d’activités
complémentaires dans le chef de certains emplois-métiers. Il s’agit notamment des processus suivants :
• EDM01 : Établir et de maintenir le cadre de gouvernance

• EDM02 : Assurer l’optimisation de la valeur
• EDM03 : Assurer l’optimisation du risque
• EDM04 : Assurer l’optimisation des ressources
• EDM05 : Assurer la transparence pour les parties prenantes
• MEA02 : Surveiller le système de contrôle interne
• MEA03 : Surveiller et évaluer la conformité avec les exigences externes

Nomenclature des Emplois-métiers du CIGREF CobiT
Familles des métiers

Activités Processus & Pratiques
& Métiers
1. Pilotage, organisation
et gestion des évolutions du
1.1 Consultant en systèmes
d’information
Conseil en système • APO02 : Définir la stratégie
d’information ~ 02
• APO04 : Gérer l’innovation
~ 04
~ 05
Assistance aux métiers ou • BAI02 : Définir les exigences
au maître d’ouvrage ~ 01
~ 02
• BAI03 : Identifier et construire les solutions
~ 01
• APO03 : Gérer l’architecture d’entreprise
~ 03
~ 04
• BAI01 : Gérer les programmes et les projets
~ 11
• BAI05 : Faciliter le changement organisationnel
~ 01 à 07
1.2 Urbaniste des systèmes
d’information
Conception du système • APO03 : Gérer l’architecture d’entreprise
d’information ~ 02 à 05
~ 01 à .07
• APO02 : Définir la stratégie
~ 03
• APO11 : Gérer la qualité
~ 02
~ 05
• APO04 : Gérer l’innovation
~ 01 à 05
• MEA01: Surveiller et évaluer la Performance et conformité
~ 04
~ 05
Garantie de la cohérence • BAI02 : Définir les exigences
du système d’information ~ 04

& Métiers
Communication • APO03 : Gérer l’architecture d’entreprise
~ 01
~ 06
• APO08 : Gérer les relations
~ 03
~ 04
1.3 Responsable du système
d’information
« métier »
Pilotage stratégique • APO02: Définir la stratégie
~ 01 à 06
~ 02 à 05
~ 01
~ 01 à 07
• APO06: Gérer les budgets et les coûts
~ 01 à .05
Administration du SI • APO03 : Gérer l’architecture d’entreprise
~ 01 à 05
~ 02
Qualité et conduite de • APO05 : Gérer le portefeuille
projet ~ 01 à 06
~ 01 à 05
• MEA02: Surveiller le système de contrôle interne
~ 01 à 08
• MEA03 : Surveiller et évaluer la conformité avec les exigences
externes
~ 01 à 04
• BAI08 : Gérer la connaissance
~ 01 à 05
~ 09
• APO07 : Gérer les ressources humaines
~ 03


& Métiers
1.4 Gestionnaire
d’applications
Conception d’évolution du • BAI02 : Définir les exigences
système d’information ~ 01
~ 05
• BAI06 : Gérer les changements
~ 01
~ 09
• BAI07 : Accepter et mettre en œuvre les changements
~ 05
Mise en œuvre du système • DSS04 : Gérer les requêtes de service et les incidents
d’information ~ 05
• DSS05 : Gérer les problèmes
~ 01 à 05
~ 07
• BAI02 : Définir les exigences
~ 01
Qualité du SI (performance, • BAI08 : Gérer la connaissance
cohérence, coût, délai…) ~ 04
• DSS08 : Gérer les contrôles des processus métiers
~ 01 à 05
• APO06 : Gérer les budgets et les coûts
~ 05
1.5 Chargé d’affaires interne
Information des métiers « • APO08 : Gérer les relations
clients » ~ 01 à .05
Analyse et contrôle de la • APO09 : Gérer les Accords de service
qualité de service ~ 05
~ 06
Contractualisation de la • APO09 : Gérer les Accords de service
relation métiers-DSI / client ~ 01 à 06
fournisseur
Gestion du problème « • DSS05 : Gérer les problèmes
client » ~ 01 à 05
2. Management de projets

& Métiers
2.1 Directeur de projets
Direction du projet • BAI01 : Gérer les programmes et les projets
~ 01 à .4
Communication / Animation • APO08 : Gérer les relations
~ 03
~ 04
~ 01 à 07
Gestion des ressources • APO10 : Gérer les fournisseurs
~ 03
~ 05
~ 01 à 03
~ 05
~ 01 à .04
2.2 Chef de projet maitrise
d’ouvrage
Responsabilité du contenu • BAI02 : Définir les exigences
fonctionnel du projet ~ 01 à 04
~ 01
~ 04
~ 06
~ 08
~ 10
~ 01 à .08
Conduite du projet • BAI01 : Gérer les programmes et les projets
~ 08 à 13
Préparation, déploiement • BAI8 : Gérer la connaissance
du projet, et mise en ~ 03 à 05
œuvre des actions
d’accompagnement des
utilisateurs


& Métiers
Garantie de la meilleure • BAI07: Accepter et mettre en œuvre les changements
adéquation qualité coût ~ 05
délai • BAI01: Gérer les programmes et les projets
~ 11
~ 05
• BAI03: Identifier et construire les solutions
~ 09
• BAI02: Définir les exigences
~ 03
~ 03
2.3 Chef de projet maitrise
d’œuvre
Responsabilité du contenu • BAI02 : Définir les exigences
technique du ~ 01
projet • BAI03 : Identifier et construire les solutions
~ 01 à 10
~ 04
~ 05
~ 06
~ 07
Conduite du projet sur le • BAI01 : Gérer les programmes et les projets
terrain ~ 12
Déploiement technique • BAI07 : Accepter et mettre en œuvre les changements
du projet et mise en ~ 06
œuvre des actions ~ 07
d’accompagnement • BAI08 : Gérer la connaissance
des utilisateurs
~ 04
Garantie de la meilleure • APO11 : Gérer la qualité
adéquation qualité - coût ~ 05
- délai • BAI01 : Gérer les programmes et les projets
~ 12
3. Cycle de vie des
applications
3.1 Responsable des
systèmes applicatifs
Gestion de la configuration • DSS3 : Gérer les configurations
logicielle ~ 03
~ 04
~ 05
~ 01
~ 10

& Métiers
Gestion de la qualité de la • DSS03 : Gérer les configurations
configuration ~ 03
~ 04
~ 02
Communication • APO08 : Gérer les relations
~ 04
3.2 Concepteur -
développeur
Analyse • BAI03 : Identifier et construire les solutions
~ 02
Qualification • BAI03 : Identifier et construire les solutions
~ 07
~ 08
Développement • BAI03 : Identifier et construire les solutions
~ 03
Maintenance • BAI03 : Identifier et construire les solutions
~ 10
• DSS03 : Gérer les configurations
~ 03
3.3 Testeur
L’organisation des tests • BAI07 : Accepter et mettre en œuvre les changements
~ 03
La conception des tests • BAI07 : Accepter et mettre en œuvre les changements
~ 04
Le déroulement des tests • BAI07 : Accepter et mettre en œuvre les changements
~ 05
3.4 Intégrateur d’applications
Identification et sélection • BAI03 : Identifier et construire les solutions
des composants ~ 02
techniques du projet
Réception, validation et • BAI03 : Identifier et construire les solutions
assemblage de ces ~ 05
composants ~ 06
Définition des interfaces et • BAI03 : Identifier et construire les solutions
des éventuelles évolutions ~ 09
à apporter aux composants
pour permettre leur
intégration
Fourniture du système • BAI07 : Accepter et mettre en œuvre les changements
développé à l’intégrateur ~ 06
d’exploitation


& Métiers
3.5 Paramétreur de logiciels
Analyse • BAI03 : Identifier et construire les solutions
~ 02
Développement • BAI03 : Identifier et construire les solutions
~ 03
Qualification et tests • BAI03 : Identifier et construire les solutions
~ 07
~ 08
Maintenance • BAI03 : Identifier et construire les solutions
~ 10
~ 03
4. Mise à disposition et
maintenance en condition
opérationnelle des
infrastructures
4.1 Technicien d’exploitation
Exploitation • DSS01 : Gérer les opérations
~ 03
~ 04
~ 05
Gestion des incidents et de • DSS04 : Gérer les requêtes de service et les incidents
la sécurité ~ 02
~ 03
~ 04
~ 05
~ 06
• DSS07 : Gérer la sécurité de l’information
~ 05
Maintien des conditions • DSS06 : Gérer la continuité des affaires
générales de production ~ 08
4.2 Technicien poste de
travail
Installation, tests et recettes • DSS01 : Gérer les opérations
~ 03
Exploitation • DSS02 : Gérer les actifs
~ 01
• DSS04 : Gérer les requêtes de service et les incidents
~ 04
~ 05
Maintenance, • DSS02 : Gérer les actifs
administration et sécurité ~ 03
~ 03

& Métiers
Support • DSS04 : Gérer les requêtes de service et les incidents
~ 03
4.3 Technicien réseaux-
télécoms
Installation et tests • DSS01 : Gérer les opérations
~ 03
Exploitation • DSS02 : Gérer les actifs
~ 01
~ 04
~ 05
Administration et sécurité • DSS02 : Gérer les actifs
~ 03
~ 03
4.4 Administrateur d’outils
/ de systèmes / de réseaux-
télécoms
Administration • DSS02 : Gérer les actifs
~ 01
~ 02
~ 03
~ 04
Exploitation • DSS01 : Gérer les opérations
~ 03
• DSS02 : Gérer les actifs
~ 03
~ 04
~ 05
Support • DSS02 : Gérer les actifs
~ 03
~ 06
~ 07
Maintenance et • DSS7 : Gérer la sécurité de l’information
sécurité ~ 02
~ 03
~ 04
~ 05
• DSS02: Gérer les actifs
~ 03


& Métiers
Études • APO04 : Gérer l’innovation
~ 03
~ 03
4.5 Administrateur de bases
de Données
Administration • BAI02 : Définir les exigences
~ 01
~ 03
Exploitation • DSS06 : Gérer la continuité des affaires
~ 08
~ 08
Support • DSS02 : Gérer les actifs
~ 03
~ 05
Études et Contrôle • APO04 : Gérer l’innovation
~ 03
4.6 Intégrateur d’exploitation
Intégration du logiciel dans • BAI07 : Accepter et mettre en œuvre les changements
l’environnement ~ 06
de production
Gestion des changements • BAI06 : Gérer les changements
de version (tenue à jour des ~ 01 à 04
versions déployées) • BAI07 : Accepter et mettre en œuvre les changements
~ 06
~ 03
Implantation du logiciel sur • BAI07 : Accepter et mettre en œuvre les changements.
les serveurs ~ 06
Intégration des nouvelles • BAI03 : Identifier et construire les solutions
applications et des mises ~ 05
à jour
4.7 Pilote d’exploitation
Analyse des messages • DSS04 : Gérer les requêtes de service et les incidents
reçus à l’unité de pilotage ~ 04
Surveillance • DSS01 : Gérer les opérations
~ 03
~ 04
~ 05

& Métiers
Alerte éventuelle • DSS04 : Gérer les requêtes de service et les incidents
d’un niveau d’intervention ~ 05
supérieur
Maintien des conditions • DSS01 : Gérer les opérations
générales de production ~ 03
4.8 Expert systèmes
d’exploitation
Participation aux études et • BAI02 : Définir les exigences
développement ~ 01
• APO10 : Gérer les fournisseurs
~ 02
Soutien auprès des équipes • BAI03 : Identifier et construire les solutions
~ 01
~ 02
~ 03
~ 04
Prospective • APO04 : Gérer l’innovation
~ 03
Mise en place et évolutions • APO03 : Gérer l’architecture d’entreprise
~ 02
~ 03
~ 04
~ 03
~ 04
Ouverture externe • APO04 : Gérer l’innovation
~ 03
4.9 Expert réseaux -
télécoms
Participation aux études et • BAI02 : Définir les exigences
développement ~ 01
~ 02
Soutien auprès des équipes • BAI03 : Identifier et construire les solutions
~ 01
~ 02
~ 03
~ 04
Prospective • APO04 : Gérer l’innovation
~ 03


& Métiers
Mise en place des • APO03 : Gérer l’architecture d’entreprise
évolutions et certifications ~ 02
~ 03
~ 04
~ 03
~ 04
~ 03
~ 04
4.10 Architecte technique
Conception • APO03 : Gérer l’architecture d’entreprise
~ 01 à 05
~ 01
• APO12: Gérer les risques
~ 01 à 06
• DSS07: Gérer la sécurité
~ 01 à 08
Administration • APO03 : Gérer l’architecture d’entreprise
~ 01 à 05
Préconisation • BAI02 : Définir les exigences
~ 01
Conseil • APO04 : Gérer l’innovation
~ 01 à 06
Communication • APO02 : Définir la stratégie
~ 06
• APO08 : Gérer les relations
~ 03
~ 04
5. Support et assistance aux
utilisateurs
5.1 Assistant fonctionnel
Anticipation et conduite du • BAI07 : Accepter et mettre en œuvre les changements
changement ~ 07
~ 04
Assistance et conseil • BAI02 : Définir les exigences
auprès de l’utilisateur final ~ 01
~ 05

& Métiers
Vérification de la qualité et • MEA01 : Surveiller et évaluer la Performance et conformité
de la performance du ~ 03
fonctionnement des
applications de son
domaine SI
5.2 Technicien support
utilisateurs
Accueil des demandes des • DSS04 : Gérer les requêtes de service et les incidents
utilisateurs suite à ~ 02
des dysfonctionnements ~ 03
Traitement ou • DSS04 : Gérer les requêtes de service et les incidents
déclenchement des ~ 04
actions de support ~ 05
correspondantes
Suivi des incidents • DSS04 : Gérer les requêtes de service et les incidents
~ 06
~ 07
6. Support méthode, qualité
et sécurité
6.1 Expert méthode et outils /
qualité / sécurité
Conseil et support auprès • APO12: Gérer les risques
des équipes ~ 01 à 06
• DSS07: Gérer la sécurité
~ 01 à 08
~ 01
~ 02
~ 03
Mise en place des • APO11 : Gérer la qualité
évolutions et certifications ~ 04
~ 05
~ 06
~ 01 à 05
~ 03
~ 04
6.2 Manager de contrats
Stratégie • APO10 : Gérer les fournisseurs
~ 01
Gestion des contrats • APO10 : Gérer les fournisseurs
~ 03


& Métiers
~ 03
~ 04
Définir les moyens et les • APO10 : Gérer les fournisseurs
services ~ 02
Mettre en place les moyens • APO10 : Gérer les fournisseurs
et assurer leur ~ 04
fonctionnement ~ 05
6.3 Responsable sécurité des
systèmes d’information - RSSI
Définition de la politique de • DSS07 : Gérer la sécurité de l’information
sécurité. ~ 01 à 08
Analyse de risques • APO12 : Gérer les risques
~ 01 à 06
Sensibilisation et formation • APO08 : Gérer les relations
aux enjeux de la sécurité ~ 03
~ 04
Etudes des moyens et • DSS07 : Gérer la sécurité de l’information
préconisations ~ 01 à 08
Audit et contrôle • APO01 : Définir le cadre de gestion du SI
~ 08
• APO07 : Gérer les ressources humaines.
~ 01
~ 02
~ 03
~ 05
• MEA02 : Surveiller le système de contrôle interne
~ 04
Veille technologique et • APO04 : Gérer l’innovation
prospective ~ 03
~ 04
~ 01 à 05
7. Management opérationnel

& Métiers
7.1 Directeur des systèmes
d’information
Définition et supervision de • APO02 : Définir la stratégie
la politique de SI et de sa ~ 01 à 06
mise en œuvre • APO05 : Gérer le portefeuille
~ 01 à 06
~ 01 à 05
~ 01 à 05
• MEA02: Surveiller le système de contrôle interne
~ 01 à 08
• MEA03 : Surveiller et évaluer la conformité avec les exigences
externes
~ 01 à 04
Promotion de la qualité • APO08 : Gérer les relations
dans les relations avec les ~ 01 à 05
partenaires internes • APO09 : Gérer les Accords de service
~ 01 à 06
~ 01 à 07
Définition et mise en œuvre • APO10 : Gérer les fournisseurs
d’une politique de « faire ou ~ 01 à 05
faire -faire»
Communication interne, • APO01 : Définir le cadre de gestion du système d’information
motivation et animation du ~ 01
personnel de la DSI ~ 02
~ 06
~ 07
~ 08
~ 01 à 06
Supervision des relations • APO10 : Gérer les fournisseurs
avec les prestataires et ~ 01 à 05
partenaires extérieurs
Garant de la sécurité • APO12 : Gérer les risques
informatique ~ 01 à 06
7.2 Responsable d’entité
Encadrement, animation • APO07 : Gérer les ressources humaines
~ 01 à 06
Planification, organisation, • APO06 : Gérer les budgets et les coûts
gestion ~ 01 à 05
• MEA01 : Surveiller et évaluer la Performance et conformité
~ 01 à .05


& Métiers
Qualité, sécurité • APO11 : Gérer la qualité
~ 01 à 06
~ 01 à 08
~ 01 à 05
~ 01 à 07
7.3 Responsable télécoms
Définition et conception de • APO03 : Gérer l’architecture d’entreprise
l’architecture télécom ~ 01 à 05
~ 01
Continuité de service • DSS01 : Gérer les opérations
~ 01 à 05
• BAI04 : Gérer la disponibilité et la capacité
~ 01 à 05
• DSS06 : Gérer la continuité des affaires
~ 01 à .09
Veille, prospective et • APO04 : Gérer l’innovation
conseil ~ 01 à .06
Appel d’offres et achat de • APO10 : Gérer les fournisseurs
services télécoms ~ 01 à .05
Relations MOE-MOA • BAI02 : Définir les exigences
~ 01 à .04
• BAI05 : Faciliter le changement organisationnel.
~ 06
Audit et contrôle de gestion • MEA01 : Surveiller et évaluer la Performance et conformité
~ 01 à .05
7.4 Responsable
d’exploitation
Production informatique, • DSS01 : Gérer les opérations
maintenance ~ 01 à .05
~ 01 à 05
Qualité, sécurité • DSS06 : Gérer la continuité des affaires
~ 01 à .09
~ 01 à 08
~ 01 à .05
~ 06

& Métiers
Gestion des moyens • APO04 : Gérer l’innovation
~ 01 à 06
~ 01 à 05
7.5 Responsable d’études
Intégration et • BAI02 : Définir les exigences
automatisation des ~ 01 à 04
processus métiers • BAI05 : Faciliter le changement organisationnel
~ 06
• APO09 : Gérer les accords de service
~ 01 à 06
Stratégie SI • APO02 : Définir la stratégie
~ 01 à 06
• APO05 : Gérer le portefeuille
~ 01 à 06
Planification, organisation • APO08 : Gérer les relations
et gestion ~ 01 à 05
Relations fournisseurs • APO10 : Gérer les fournisseurs
~ 01 à 05
3. La cartographie des compétences
Le référentiel de l’e-CF (European e-competence framework) vise à définir les compétences appropriées
pour mettre en œuvre efficacement les technologies de l’information, il a été intégré récemment dans
la nomenclature CIGREF.
Son rapprochement, présenté dans le tableau ci-dessous, avec les processus et pratiques de CobiT peut
être utile dans une perspective d’une bonne gestion de l’adéquation homme / processus.
A remarquer également la définition du niveau de compétence (de 0 à 5) requis pour chaque métier de
la nomenclature. Ce niveau peut être utilisé utilement pour déterminer les responsabilités par rapport
aux processus suivant la typologie RACI.
La cohérence avec le tableau rapprochant CobiT et la nomenclature est globalement bonne (au moins
aux niveaux 4 et 5 qui sont ceux qui correspondent le plus à la gouvernance et à la gestion du système
d’information).
Il faut d’ailleurs remarquer que le rapprochement est plus difficile à faire avec les processus CobiT
pour des compétences exigeant des niveaux moins élevés (niveaux 3 et inférieurs), pour lesquels il est
nécessaire de rapprocher avec les pratiques.

Remarques :
• La « couverture » du processus et / ou de la pratique de gestion ou de gouvernance par la
compétence mise en rapport peut être partielle et ne se rapporter qu’à une partie du périmètre
• Certaines compétences dépassent le périmètre de CobiT, notamment par la prise en compte
de compétences chez les fournisseurs de services
• Ce tableau « Compétences / Processus CobiT » n’est qu’exemplatif, il doit être adopté pour
chaque entreprise en fonction de son contexte
• Certains processus CobiT ne sont pas, en première analyse, couverts (en tout ou en partie) par
des compétences qui leur correspondent. Il s’agit notamment des processus de gouvernance, ce
qui est lié à la question des responsabilités partagées sur ces processus :
• EDM01 : Établir et de maintenir le cadre de gouvernance
• EDM03 : Assurer l’optimisation du risque
• EDM04 : Assurer l’optimisation des ressources
• EDM05 : Assurer la transparence pour les parties prenantes
• Dans le même ordre d’idée, à noter également l’absence du processus DSS08
(Gérer les contrôles des processus métiers).
Compétences e-CF CobiT

A Planifier
A1 Informatique et alignement stratégique métier APO01 • Définir le cadre de gestion du SI
APO02 • Définir la stratégie
APO10 • Gérer les fournisseurs
A2 Gestion des niveaux de service APO09 Gérer les accords de service
A3 Développement du plan d’activités APO05 Gérer le portefeuille
A4 Planification des produits ou des projets BAI02 Définir les exigences
A5 Conception de l’architecture APO03 Gérer l’architecture d’entreprise
A6 Conception des applications BAI03 Identifier et construire les solutions
A7 Veille technologique APO04 Gérer l’innovation
A8 Développement durable Hors du
périmètre
de CobiT
B Développer
B1 Conception et développement BAI03 Identifier et construire les solutions
B2 Intégration des systèmes BAI03 Identifier et construire les solutions
05
B3 Tests BAI03 • Identifier et construire les solutions
07 • Accepter et mettre en œuvre les changements
08
BAI07
03
04
05
B4 Déploiement de la solution BAI07 Accepter et mettre en œuvre les changements
06
B5 Production de la documentation BAI08 Gérer la connaissance
03
Compétences e-CF CobiT
C Utiliser
C1 Support utilisateur DSS04 Gérer les requêtes de service et les incidents
C2 Support des changements DSS04 Gérer les requêtes de service et les incidents
C3 Livraison des services DSS01 Gérer les opérations
C4 Gestion des problèmes DSS05 Gérer les problèmes
D Faciliter
D1 Développement de la stratégie pour la sécurité de APO12 • Gérer les risques
l’information 01 • Gérer les risques
APO12 • Gérer la sécurité de l’information
06
DSS07
D2 Développement de la stratégie pour la qualité APO11 Gérer la qualité
informatique
D3 Prestation de services de formation APO07 Gérer les ressources humaines
03
D4 Achats APO10 Gérer les fournisseurs
D5 Développement des propositions Hors CobiT
D6 Gestion des canaux de vente Hors CobiT
D7 Gestion des ventes Hors CobiT
D8 Gestion des contrats APO10 Gérer les fournisseurs
D9 Développement du personnel APO07 Gérer les ressources humaines
01
02
03
05
D10 Gestion de l’information et de la connaissance BAI08 Gérer la connaissance
E Gérer
E1 Développement prévisionnel Hors CobiT
E2 Gestion de projets et du portefeuille de projets BAI01 Gérer les programmes et les projets
E3 Gestion des risques APO12 Gérer les risques
E4 Gestion des relations client-fournisseur APO08 • Gérer les relations
APO10 • Gérer les fournisseurs
E5 Amélioration des processus MEA01 Surveiller et évaluer la performance et conformité
E6 Management de la qualité informatique APO11 Gérer la qualité
E7 Gestion des changements métier BAI05 • Faciliter le changement organisationnel
BAI06 • Gérer les changements
E8 Gestion de la sécurité de l’information DSS07 Gérer la sécurité de l’information
BAI04 Gérer la disponibilité et la capacité
E9 Gouvernance informatique MEA01 • Surveiller et évaluer la Performance et conformité
MEA02 • Surveiller le système de contrôle interne
MEA03 • Surveiller et évaluer la conformité avec les exigences
APO06 externes
• Gérer les budgets et les coûts

VII
Le comment
Maintenant que le cadre précisant le « Quoi » est bien mis en place, il est temps de se préoccuper du
« Comment ».
C’est ici évidemment que la multiplicité des solutions possibles va se révéler. Chaque entreprise ayant
sa solution, propre à son contexte et à ses objectifs.
Il existe deux grandes familles de solutions :
• Celles qui correspondent à des manières de faire qui sont propres à l’entreprise, manières qui ont
été développées en interne et qui ne font pas spécifiquement référence à une norme ou à un standard
• Celles qui correspondent à des implantations dans l’entreprise de standards connus du marché
(ITIL par exemple)
Cette deuxième famille peut elle-même être subdivisée en deux : les méthodes cadrées officiellement
dans CobiT d’une part et celles qui ne le sont pas (pas officiellement du moins).
Remarquons immédiatement qu’exprimer le Comment simplement en termes de référence à un standard

est insuffisant, cela faisant en effet l’impasse sur la manière dont l’entreprise a implanté concrètement
le standard en question.
Il y a aussi deux points de vue complémentaires : le Comment d’aujourd’hui (situation actuelle)

et le Comment de demain (situation cible) avec évidemment la possibilité de définir des situations
intermédiaires.
A. La cartographie de la gouvernance du système d’information

La cartographie doit être l’outil central de la gouvernance du SI ; travailler à l’établir devrait être une
des premières priorités du DSI sur le sujet de la gouvernance.
Il convient cependant de bien en fixer ses objectifs et son utilité.
« Le principe majeur de la cartographie est la représentation de données sur un support réduit représentant
un espace généralement tenu pour réel. L’objectif de la carte, c’est une représentation concise et efficace,
la simplification de phénomènes complexes (politiques, économiques, sociaux, etc.) à l’œuvre sur l’espace
représenté afin de permettre au public une compréhension rapide et pertinente», selon l’encyclopédie
en ligne Wikipédia.
Plusieurs éléments donc à prendre en compte en ce qui concerne la cartographie de la gouvernance

du système d’information :
• C’est une représentation du réel

• Le réel, forcément complexe, est simplifié
• La représentation doit être la plus concise et efficace possible
• Elle s’adresse à des personnes en vue d’une compréhension rapide et pertinente
Ce retour aux sources pour permettre un meilleur cadrage d’une démarche de cartographie de la
gouvernance du SI ; cela n’est pas inutile, il est fréquent de constater des dévoiements inefficaces et
coûteux en la matière.
• C’est une représentation du réel : ce n’est donc pas le réel ! Il est trop fréquent de constater qu’il y
a confusion entre la cartographie de la gouvernance du SI et la gouvernance du système d’information.
En d’autres termes, que la cartographie est utilisée comme étant la gouvernance elle-même ce qui amène
à deux problèmes : le réel c’est-à-dire la gouvernance n’existe pas d’une part et la cartographie d’autre
part s’enfonce dans un détail inutile dans ce contexte.
• Le réel, forcément complexe, est simplifié : l’exigence de la gouvernance de précision dans la mise
au point des détails n’en est pas une de sa cartographie.
• La représentation doit être la plus concise et efficace possible : il faut veiller à ce que le volume
informationnel de la cartographie reste réduit ; la baser par exemple sur des affirmations Oui / Non
plutôt que sur des opinions… Par contre, la cartographie doit être efficace et donc faire ressortir les
éléments essentiels.
• Elle s’adresse à des personnes en vue d’une compréhension rapide et pertinente : c’est en effet par
rapport à un public cible que la cartographie trouve son utilité. Son public cible est le suivant : toute
personne ayant besoin d’une vue générale et rapide de la gouvernance du SI. Mais, pour une pratique de
gestion et / ou de gouvernance donnée, la cartographie n’est pas l’outil dans les mains des responsables
de la pratique en question (voir les RACI) ; ceux-ci ont besoin d’une documentation bien plus détaillée
(et ils ont d’ailleurs souvent la charge de la produire).
Il faudra en outre ajouter d’autres qualités à la cartographie de la gouvernance du système

d’information.
Il faut un système de repérage, la latitude et la longitude pour continuer avec la métaphore de la

cartographie, qui en ce qui concerne la gouvernance du SI est évidemment assuré par CobiT, (et plus
précisément ses processus et ses pratiques de gouvernance et / ou de gestion).
D’autre part, il faut que la qualité de la cartographie soit égale sur l’ensemble des processus, et des
pratiques de gestion et / ou de gouvernance, quelles que soient les niveaux de maturité (et de capabilité)
de ceux-ci.
Attention toutefois, la tentation est souvent grande de décrire dans le détail des pratiques de gestion
qui correspondent à des niveaux de maturité élevés et de négliger la cartographie ce ceux qui ont des
maturités faibles. Il faudra donc favoriser la globalité de la cartographie plutôt qu’un niveau de détail
trop marqué.
Quelques éléments de la représentation cartographique sont proposés dans le tableau ci-dessous. Chacun
de ces éléments de représentation doit faire l’objet d’une qualification au regard d’une grille très simple
et très factuelle établie à l’avance.
Cette qualification doit être basée au maximum sur des questions objectives amenant des réponses
factuelles afin d’éviter d’entrer dans des démarches d’évaluations plus subjectives et plus longues qui
exposeraient la cartographie aux dérives énoncées plus haut.

Fiche de cartographie de la gouvernance du système d’information
Cadre Remarques
Processus CobiT : XXXXX • La cartographie est faite par rapport
Pratique de Gestion (ou de à CobiT qui en fixe donc la structure
Gouvernance) : .XX • Une fiche pour chaque pratique
(de gestion et / ou de gouvernance)
de chaque processus.
(Soit 208 fiches)
Périmètre (couverture) • Tous les facteurs d’appréciation
sont qualifiés de la même manière
sur le périmètre en question
• S’il y a des différences notables, il
faut établir des fiches différentes
portant sur ces périmètres
éléments de Qualification
représentation
Formalisation. 1. Une procédure écrite explicite la manière dont doit Préciser l’endroit où les documents en
fonctionner la pratique (O/N) question sont mémorisés (url…)
2. La procédure a été officiellement approuvée par le
DSI (O/N)
3. La procédure est gérée conformément à la démarche
ISO de l’entreprise (O/N)
Instances & Responsabilités 1. Les parties prenantes du fonctionnement de la prati- Préciser l’endroit où les documents en
que sont désignées (O/N) question sont mémorisés (url…)
2. Une note de service écrite précise les responsabilités
des parties prenantes sur cette pratique (O/N)
3. Les responsabilités des parties prenantes par rapport
à la pratique sont mentionnées dans leur description de
fonction (O/N)
Livrables 1. Il existe des livrables écrits en sortie de la mise en Préciser l’endroit où les documents en
œuvre de la pratique (O/N). question sont mémorisés (url…)
2. La définition de la structure et du contenu standardisé
de ces livrables est écrite (O/N)
3. Les occurrences de publication des livrables (périodi-
cité, événements initiateurs…) sont définies et la publica-
tion des livrables y est conforme (O/N)
Circulation de l’information. 1. La liste des destinataires des informations est établie Information ici signifie :
par écrit (O/N) • Procédures
2. Il y a un suivi de la consultation effective de l’informa- • Livrables
tion par leurs destinataires (O/N) • Notes de service
3. L’ensemble de l’information est accessible sous forme • Indicateurs
numérique (O/N) • …

Fiche de cartographie de la gouvernance du système d’information
éléments de Qualification Remarques
représentation
Indicateurs 1. Au moins un indicateur relatif à la pratique est défini Vérifier que l’indicateur en question est
par écrit ; ainsi que sa fréquence et son mode de calcul repris dans la liste des indicateurs que
(O/N) CobiT prévoit pour le processus en
2. L’indicateur est calculé conformément à la fréquence question
fixée (O/N)
3. La valeur cible de l’indicateur est définie (O/N)
Outils 1. L’outil est basé sur l’usage élémentaire et non adapté Il s’agit ici d’outillage spécifique à la
de la bureautique traditionnelle (O/N) pratique en question
2. L’outil est basé sur l’usage de la bureautique tradi-
tionnelle mais avec des modèles préprogrammés (par
exemple macro Excel) (O/N)
3. Un logiciel spécialisé est utilisé (O/N). Lequel ?
Audité / Certifié 1. Il existe un rapport du contrôle interne portant sur le • Quelle est la date du plus
fonctionnement de la pratique (O/N) récent audit ?
2. Il existe un rapport d’un auditeur externe portant sur • Quelle certification ?
le fonctionnement de la pratique (O/N)
3. La pratique dispose d’une certification officielle de la
part d’un organisme extérieur (O/N)
Expertise, Compétence & 1. Il existe une formation spécifique pour les parties • Quelle formation ?
Formation prenantes de la pratique (O/N) • Quelle certification ?
2. Il existe un plan de formation et un suivi des forma-
tions reçues par les parties prenantes de la pratique (O/N)
3. Les parties prenantes sont certifiées par un orga-
nisme extérieur de certification (O/N).
Actions de progrès. 1. Des actions de progrès en vue d’une meilleure mise
œuvre de cette pratique sont définies (O/N)
2. Les actions de progrès sont gérées dans un cadre de
gestion de projet (O/N)
3. Le plan de progrès a été validé par le DSI et est suivi
périodiquement par lui (O/N)
Référence à un standard ? 1. La pratique mise en œuvre correspond à une pratique
développée en interne (O/N)
2. La pratique mise en œuvre correspond à une pratique
reconnue sur le marché (O/N)
3. La pratique mise en œuvre est certifiée conforme à
une pratique reconnue sur le marché (O/N)
B. M. Jourdain et l’existant
Dessin : « Par ma foi, il y a plus de quarante ans que je dis de la prose, sans que j’en susse rien ; et je vous suis
le plus obligé du monde, de m’avoir appris cela. »
(Le Bourgeois Gentilhomme, Molière)
Les DSI gouvernent les systèmes d’information dont ils ont la charge depuis toujours … et même depuis
avant que CobiT existe.
Les pratiques internes qu’ils ont utilisées à cet effet ont été mises au point dans l’entreprise, au fil des
années, en prenant en compte au maximum le contexte et les objectifs de celle-ci.
Elles sont, au même titre que d’autres pratiques, externes celles-là et correspondant à des standards,
évidemment candidates pour constituer le « Comment » de chacun des processus CobiT et de leurs
pratiques de gestion et / ou de gouvernance.
Il est important de bien se rendre compte qu’implanter CobiT ne signifie pas automatiquement faire
table rase de ces pratiques internes et de leur remplacement par des pratiques externes.

Le scénario idéal devrait donc être le suivant :
• Identifier les pratiques internes de gouvernance du SI

• Les rapporter au cadre de référence CobiT (processus, pratiques de gestion et / ou de
gouvernance). En liaison avec la cartographie expliquée ci-dessus
• évaluer comment ces pratiques existantes atteignent ou non les objectifs des processus CobiT
• évaluation de la maturité
• évaluation de a capabilité
• Fixer la stratégie pour chaque processus, en fonction de l’atteinte de l’objectif et de l’énergie
(budget, ressources humaines, temps…) disponible :
• Maintenir la pratique interne parce qu’elle est jugée suffisamment bonne
• Améliorer la pratique interne
• Remplacer la pratique interne par une des meilleures pratiques ou standards externes.
En n’oubliant pas que l’efficacité et l’efficience de cette solution seront fonction de
deux éléments :
• La qualité intrinsèque de la pratique externe. Celle-ci est souvent élevée pour
les pratiques bien connues du marché
• La manière dont elle est mise en œuvre dans l’entreprise
C. Principes et utilité des mappings

Les « mappings » établissent la correspondance entre les éléments de base de CobiT, constituant le
Quoi, d’une part et des standards ou normes du marché, constituant le Comment, d’autre part.
Ces mappings sont en général établis avec un niveau de granularité correspondant à la pratique de
gestion et / ou de gouvernance.
Ils sont établis de manière théorique, hors de tout contexte de mise en œuvre réelle dans une entreprise.
Cependant, ils peuvent être utiles dans le cadre plus opérationnel choisi pour le présent livre en servant
de guide aux DSI dans leur démarche de mise en œuvre opérationnelle de la gouvernance de leur
système d’information.
Outre les mappings établis par l’ISACA et quelques mappings originaux proposés ici avec des standards
plus répandus en France, il est nécessaire de préciser que des références privées du marché ont également
ressenti l’utilité d’établir ces mappings, par exemple le mapping CobiT / MOF (Microsoft Operations
Framework) établi par Microsoft.
Chaque entreprise devrait établir son propre choix des standards du marché qu’elle compte utiliser
pour ses processus et le représenter de manière très synthétique comme le dessin ci-dessous en
montre un exemple :
• Le cadre est fourni par CobiT

• La granulométrie est le processus
• Les processus conformes aux pratiques d’un standard donné du marché sont coloriés de
la même manière
• Les processus fonctionnant selon des pratiques internes ne sont pas coloriés
CobiT, cadre des standards du SI
BAI DSS
(Bâtir, acquérir et implémenter) (Délivrer, servir et supporter)
EDM
(évaluer, diriger Standards,
Gérer Accepter et mettre en bonnes
et surveiller) Gérer les opérations
la connaissance œuvre les changements pratiques...
EFQM
Assurer la Facilliter le changement Gérer les contrôles
Gérer les changements
transparence organisationnelle Itil des processus métiers
pour les parties
prenantes 6 Sigma
et la capacité les solutions CMMi de l'information
ISO 9001
Définir Gérer les programmes Gérer la continuité
Assurer la les exigences et les projets Prince 2 des affaires
l'optimisation
des ressources eSCM-CL
ISO 17799 Gérer les problèmes
((27002)
APO
(Aligner, planifier et organiser) Gérer les requêtes de
Nomenclature
Assurer la service et incidents
emploi métier
l'optimisation Définir le cadre Gérer CIGREF
Définir
du risque de gestion l'architecture Gérer
la stratégie TOGAF
de l'IT d'entreprise les configurations
Benchmark
Gérer coûts Gérer les actifs
Gérer Gérer
Assurer la les budgets CIGREF
l'innovation le portefeuille
de la valeur
Gérer Gérer MEA
Gérer
les relations
humaines de service
Surveiller et
établir et Surveiller et Surveiller
apprécier la
maintenir le Gérer évaluer la le système
Gérer Gérer conformité avec
carde de les performance et de contrôle
la qualité les risques les exigences
gouvernance fournisseurs la conformité interne
externes

D. Mappings classiques de CobiT vus par l’ITGI
C’est dans cet esprit que l’ITGI et l’ISACA ont établi une collection de mappings entre CobiT et divers
standards.
Ils ne doivent pas être considérés comme des sous-produits de seconde zone, CobiT veillant dans sa
conception même à favoriser ces correspondances. Ceci a encore été le cas dans le design de la nouvelle
version 5.
Nous présentons ci-dessous une liste de quelques-uns de ces mappings.
Mappings de CobiT par l’ITGI

Version de
Standard mappé Remarques
CobiT
CobiT 4.0 PMBOK 44 pages
CobiT 4.0 ISO/IEC 17799:2005 43 pages
CobiT 4.0 PRINCE2 43 pages
CobiT 4.0 SEI’s CMM for Software 38 pages
CobiT 4.1 CMMI for Development V1.2 55 pages
CobiT 4.0 TOGAF 8.1 281 pages
CobiT 4.1 ITIL V3 65 pages
CobiT 4.1 ITIL V3 & ISO/IEC 27002 131 pages
Edité en commun par l’ITGI & l’OGC
CobiT 4.0 Sarbanes-Oxley (*) 130 pages
(*) : Standard général, pas spécifiquement IT ; étude du
rapprochement avec CobiT
CobiT 4.1 Bâles II (*) 105 pages
(*) : Idem
Ces documents sont téléchargeables sur le Web.
A l’évidence, vu le niveau de détail et donc le nombre de pages, ce genre de livre ne doit pas être lu
séquentiellement mais constitue une référence qui devrait être constamment à portée de main des
acteurs de la gouvernance du SI.
E. Mappings de CobiT avec des référentiels structurants

fortement utilisés en France

Un objectif important de cette étude est de démontrer la capacité d’intégration de CobiT vis-à-vis des
pratiques de gestion et / ou de gouvernance du SI plus spécifiques à la France. Cela fut déjà le cas ci-
dessus avec la nomenclature des emplois-métiers.
Dans cette même idée, le lecteur trouvera ci-dessous des ébauches de mappings de CobiT avec :
• Le benchmarking des coûts du SI du Cigref

• EBIOS de l’ANSSI.
• Le SI de la DSI du Cigref
Ce sont à l’évidence des ébauches qui méritent toutes d’être revisitées en fonction des contextes des
différentes entreprises.
1. CobiT & le « Modèle d’analyse et de benchmarking des coûts informatiques du Cigref »
Ce modèle, dans sa version 2009 publiée par le CIGREF et utilisée ici, est en fait l’actualisation d’un
modèle plus ancien publié conjointement par l’AFAI et le CIGREF en 2006.
Le modèle est téléchargeable gratuitement sur le site web du Cigref (www.cigref.fr).
Les objectifs de ce modèle sont les suivants :
• Mesurer les coûts du SI et les suivre dans le temps

• Se comparer à d’autres DSI
• Renforcer le pilotage économique
• Améliorer le dialogue avec les métiers et la DG
• Contribuer à un meilleur alignement stratégique
Le principe général de valorisation du modèle s’appuie sur les éléments suivants :
• Une affectation du budget de charges de la DSI sur les activités

• Une répartition du coût des activités sur les services à l’aide d’inducteurs qui représentent des
unités d’œuvre techniques permettant de mesurer la « consommation » des activités par
les services
En fait, ce modèle est une instanciation de la méthode ABC (Activity Based Costing) appliquée au
fonctionnement d’une DSI.
Bien évidemment, le modèle d’activités avec ses 39 activités standards, les modalités d’affectation des
rubriques budgétaires sur les activités et enfin l’inducteur de chaque activité constituent le cœur du
modèle.
La très large utilisation du modèle parmi les DSI en fait un candidat de choix pour mettre en œuvre
certaines pratiques de gestion de CobiT.
La proximité forte entre le « Modèle d’analyse et de benchmarking des coûts informatiques » du Cigref
et le processus APO06 « Gérer les budgets et les coûts » de CobiT sera mise à profit utilement. Ce
processus CobiT ayant d’ailleurs pour objectif notamment qu’« un modèle d’allocation des coûts aux
services soit utilisé et maintenu ».
A noter également l’indicateur correspondant à cet objectif dans CobiT : « % global des coûts IT avec une
allocation conforme aux modèles de coût acceptés ». Le modèle d’analyse et de benchmarking précise
d’ailleurs opportunément que ce pourcentage doit être égal à 100 pour que la démarche ait du sens.

« Modèle d’analyse et de benchmarking des coûts informatiques » et CobiT
Les étapes de la démarche CobiT (V5)
étapes Remarques Référence Pratique de gouvernance
et de gestion
1ère étape : Formaliser le L’ensemble des services mis à disposition est APO09.02 Définir les services IT et
catalogue de services de regroupé en quatre grands processus : maintenir le portefeuille des
la DSI • Bureautique services
• Mise à Disposition des Services
• Projets Techniques
• Projets Métiers
2ème étape : Un modèle d’activité standard est proposé. Il se APO06.01 Gérer les finances et la
Mettre en cohérence le compose de 39 activités elles-mêmes regroupées comptabilité
modèle d’activité pour des raisons de clarté en 19 macro-activités.
3ème étape : Les six rubriques sont : APO06.03 Etablir et maintenir les
Décliner le budget en six • Personnel budgets
rubriques • Prestations externes
• Matériels
• Logiciels
• Telecom
• Frais de structure
Ces rubriques sont subdivisées en sous-rubriques
elles-mêmes en relation avec les Comptes du Plan de
Comptes Général.
4ème étape : Voir les principes d’affectation des rubriques APO06.04 Modéliser et allouer les coûts
Affecter les ressources aux budgétaires sur les activités
activités
5ème étape : Cette ventilation se fait sur base d’inducteurs : APO06.04 Modéliser et allouer les coûts
Ventiler les activités sur les • Techniques
services • Financiers
• Au prorata des coûts déjà calculés (pour
les activités n’ayant pas d’inducteur).
Le modèle définit un (et un seul) inducteur pour
chaque activité.
6ème étape : La comparaison peut se faire à différents niveaux : APO06.02 • Prioriser l’allocation
Analyser et comparer. • Les ressources APO06.05 des ressources
• Les activités • Gérer les coûts
~ Interne
~ Bechmark
• Services
Une autre manière de rapprocher le « Modèle d’analyse et de benchmarking des coûts informatiques »
de CobiT est de s’interroger sur les processus qui ont un impact en matière de coût et d’efficacité sur
chacune des macro-activités du modèle d’activités.
Une première ébauche de rapprochement est proposée ci-dessous. Elle est globale (faite au niveau
processus CobiT) et mérite donc d’être revisitée et détaillée au niveau des pratiques de gestion et de
gouvernance avant usage.
« Modèle d’analyse et de benchmarking des coûts informatiques » et CobiT

Macro-activités du modèle d’activités CobiT (V5)
Référence Processus
Acquisition BAI02 • Définir les exigences
BAI03 • Identifier et construire les solutions
Infrastructure bureautique BAI02 • Définir les exigences
BAI03 • Identifier et construire les solutions
Hébergement DSS01 Gérer les opérations
Outsourcing DSS01 Gérer les opérations
Masters et déploiements bureautiques DSS03 Gérer les configurations
Exploitation DSS01 Gérer les opérations
Sécurité DSS06 • Gérer la continuité des affaires
DSS07 • Gérer la sécurité de l’information
Support DSS04 Gérer les requêtes de service et les incidents
Maintenance corrective DSS05 Gérer les problèmes
étude, conception BAI02 Définir les exigences
Réalisation BAI03 Identifier et construire les solutions
Tests, recette, mise en production BAI07 Accepter et mettre en œuvre les changements
Pilotage projets BAI01 Gérer les programmes et les projets
Formation APO07 • Gérer les ressources humaines
BAI05 • Faciliter le changement organisationnel
Urbanisation / Architecture Veille technologique APO03 • Gérer l’architecture d’entreprise
APO04 • Gérer l’innovation
Qualité, méthodes APO11 • Gérer la qualité
MEA01 • Surveiller et évaluer la Performance et conformité
MEA02 • Surveiller le système de contrôle interne
MEA03 • Surveiller et évaluer la conformité avec les exigences externes
Gestion des environnements APO03 Gérer l’architecture d’entreprise
Encadrement et management APO01 Définir le cadre de gestion de l’IT
Gestion administrative APO01 Définir le cadre de gestion de l’IT

2. EBIOS
« L’Agence nationale de la sécurité des systèmes d’information (ANSSI) élabore et tient à jour un
important référentiel méthodologique destiné à aider les organismes du secteur public et du secteur
privé à gérer la sécurité de leurs systèmes d’informations. Ce référentiel est composé de méthodes, de
meilleures pratiques et de logiciels, diffusés gratuitement sur son site Internet
(http://www.ssi.gouv.fr). »
« La méthode EBIOS (Expression des Besoins et Identification des Objectifs de Sécurité) permet d’apprécier
et de traiter les risques. Elle fournit également tous les éléments nécessaires à la communication au sein
de l’organisme et vis-à-vis de ses partenaires, ainsi qu’à la validation du traitement des risques. Elle
constitue de ce fait un outil complet de gestion des risques. »
La méthode EBIOS, très pragmatique et très largement utilisée sur le terrain, constitue, elle aussi, un
exemple d’application méthodologique permettant de garnir certaines pratiques de gouvernance et
de gestion de CobiT.
En l’occurrence, il s’agit principalement des processus suivants :
• Assurer l’optimisation du risque (EDM03)

• Gérer les risques (APO12)
Certaines connexions plus partielles, voire très partielles, avec d’autres processus sont également
envisageables :
• Définir le cadre de gestion de l’IT (APO01)

• Gérer les configurations (DSS03)
• Gérer la sécurité de l’information (DSS07)
• Surveiller le système de contrôle interne (MEA02)
• Surveiller et évaluer la conformité avec les exigences externes (MEA03)
Ce rapprochement EBIOS / CobiT est particulièrement utile dans notre ligne de conduite « boite à
outils ».
En effet, « EBIOS est une boîte à outils à usage variable. Comme toute véritable méthode de gestion
des risques, EBIOS permet d’analyser des risques, de les évaluer et de les traiter dans le cadre d’une
amélioration continue. La spécificité d’EBIOS réside dans sa souplesse d’utilisation. Il s’agit d’une
véritable boîte à outils, dont les activités à réaliser, leur niveau de détail et leur séquencement seront
adaptés à l’usage désiré. En effet, la méthode ne sera pas utilisée de la même manière selon le sujet
étudié, les livrables attendus, le degré de connaissance du périmètre de l’étude, le secteur auquel on
l’applique… »
Le tableau de correspondance entre le Quoi et le Comment qui est proposé ci-dessous doit être
adapté en fonction de la « variation de la focale selon le sujet étudié » que la méthode EBIOS permet
et que chaque Entreprise choisira.
Rapprochement entre EBIOS et CobiT
EBIOS CobiT (V5)
(Version 25 janvier 2010)
Module / Activité / Action Référence Pratique de gouvernance et de gestion

Module 1 – Étude du contexte
Activité 1.1 – Définir le cadre de la gestion des risques
Action 1.1.1. Cadrer l’étude des risques EDM03.02 Diriger la gestion du risque
Action 1.1.2. Décrire le contexte général EDM03.02 Diriger la gestion du risque
Action 1.1.3. Délimiter le périmètre de l’étude EDM03.02 Diriger la gestion du risque
Action 1.1.4. Identifier les paramètres à prendre en compte EDM03.02 • Diriger la gestion du risque.
MEA03.01 • Identifier les exigences de conformité
externes
Action 1.1.5. Identifier les sources de menaces EDM03.02 Diriger la gestion du risque
Activité 1.2 – Préparer les métriques

Action 1.2.1. Définir les critères de sécurité et élaborer les échelles de EDM03.01 Evaluer la gestion du risque
besoins
Action 1.2.2. Élaborer une échelle de niveaux de gravité EDM03.01 Evaluer la gestion du risque
Action 1.2.3. Élaborer une échelle de niveaux de vraisemblance EDM03.01 Evaluer la gestion du risque
Action 1.2.4. Définir les critères de gestion des risques EDM03.01 Evaluer la gestion du risque
Activité 1.3 – Identifier les biens
Action 1.3.1. Identifier les biens essentiels, leurs relations et leurs APO12.01 • Collecter les données
dépositaires APO01.06 • Définir la propriété des informations
APO03.02 (données) et du système
• Définir l’architecture de référence
Action 1.3.2. Identifier les biens supports, leurs relations et leurs APO12.01 • Collecter les données
propriétaires DSS03.02 • établir et maintenir un répertoire et un
point de comparaison des configurations
Action 1.3.3. Déterminer le lien entre les biens essentiels et les biens APO12 .01 • Collecter les données
supports DSS03.02 • établir et maintenir un répertoire et un
point de comparaison des configurations
Action 1.3.4. Identifier les mesures de sécurité existantes APO12.01 • Collecter les données
(correspondance partielle mais pour
l’ensemble du processus)
Module 2 – Étude des événements redoutés
Activité 2.1 – Apprécier les événements redoutés
Action 2.1.1. Analyser tous les événements redoutés APO12.02 Analyser les risques
Action 2.1.2. Évaluer chaque événement redouté APO12.02 Analyser les risques
Module 3 – Étude des scénarios de menaces
Activité 3.1 – Apprécier les scénarios de menaces

EBIOS CobiT (V5)

Action 3.1.1. Analyser tous les scénarios de menaces APO12.02 Analyser les risques
Note : Voir en particulier le détail des menaces et vulnérabilités A rapprocher et fusionner utilement
génériques identifiées dans la base de connaissance EBIOS sur base avec les scénarios génériques de risque
d’un croisement entre : informatique de RiskIT (The Risk IT
• Le mode opératoire Practitioner Guide 2009 ISACA) basés sur
~ les détournements d’usages (USG) un croisement entre :
~ l’espionnage (ESP) • Acteur
~ les dépassements de limites de fonctionnement (DEP) ~ Interne
~ les détériorations (DET) ~ Externe
~ les modifications (MOD) • Type de menace
~ les pertes de propriété (PTE) ~ Malveillance
• Les types de biens supports ~ Accident / Erreur
~ les systèmes informatiques et de téléphonie (SYS) ~ Défaillance
• matériels (MAT) ~ Naturel
• logiciels (LOG) ~ Requête externe
• canaux informatiques et de téléphonie (RSX) • Événement
~ les organisations (ORG) ~ Divulgation
• personnes (PER) ~ Interruption
• supports papier (PAP) ~ Modification
• canaux interpersonnels (CAN) ~ Vol
~ les locaux (LOC) ~ Destruction
~ Conception inefficace
~ Exécution inefficace
~ Réglementation
~ Utilisation inappropriée
• Actif/Ressource
~ Personnes & organisation
~ Processus
~ Infrastructures (bâtiments)
~ Infrastructures IT
~ Information
~ Applications
• Éléments temporels
~ Durée
~ Période d’occurrence (critique /
non critique)
~ Durée de détection
A voir également avec intérêt sur ce sujet

le tableau de rapprochement entre ces
scénarios génériques et les processus
CobiT.
Action 3.1.2. Évaluer chaque scénario de menace APO12.02 Analyser les risques
EBIOS CobiT (V5)

Module 4 – Étude des risques
Activité 4.1 – Apprécier les risques
Action 4.1.1. Analyser les risques APO12.02 Analyser les risques
Action 4.1.2. Évaluer les risques APO12.02 Analyser les risques
Activité 4.2 – Identifier les objectifs de sécurité
Action 4.2.1. Choisir les options de traitement des risques APO12.02 Analyser les risques
Action 4.2.2. Analyser les risques résiduels APO12.02 Analyser les risques
Module 5 – Étude des mesures de sécurité
Activité 5.1 – Formaliser les mesures de sécurité à mettre en œuvre

Action 5.1.1. Déterminer les mesures de sécurité APO12.02 • Analyser les risques
APO12.05 • Définir un portefeuille de gestion des
DSS07 actions liées au risque
• Gérer la sécurité de l’information
(correspondance partielle mais pour
l’ensemble du processus)
Action 5.1.2. Analyser les risques résiduels APO12.02 • Analyser les risques
MEA02.07 • Portée des initiatives d’assurance
Action 5.1.3. Établir une déclaration d’applicabilité MEA02.03 Exécuter des auto- évaluations de contrôle
Activité 5.2 – Mettre en œuvre les mesures de sécurité

Action 5.2.1. Élaborer le plan d’action et suivre la réalisation des APO12.05 Définir un portefeuille de gestion des
mesures de sécurité actions liées au risque
Action 5.2.2. Analyser les risques résiduels APO12.02 Analyser les risques
Action 5.2.3. Prononcer l’homologation de sécurité EDM03.01 • évaluer la gestion du risque
APO12.04 • Articuler le risque
MEA02.01 • Surveiller les contrôles internes
3. CobiT et le SI de la DSI (du Cigref)
Dans le cadre de son « SI de la DSI ; Permettre à la fonction SI d’opérer efficacement son cœur de métier », le CIGREF a
identifié les processus clés de la DSI répartis en trois familles :
• Pilotage
• Opérationnel
• Support
Le rapprochement de ces processus avec ceux de CobiT est immédiat , selon le tableau ci-dessous.

Les processus clés du SI de la DSI (CIGREF) et les processus CobiT
Le SI de la DSI CobiT
Pilotage
Gouverner le SI de la DSI
Piloter l’organisation
Garantir la bonne exécution des BAI01 Gérer les programmes et les projets
missions
Gérer le budget IT APO06 Gérer les budgets et les coûts
Etablir les plans de recrutements et APO07 Gérer les ressources humaines
de gestion des compétences
Gérer les risques APO12 Gérer les risques
Gérer le système
de management
Identifier et capitaliser les bonnes BAI08 Gérer la connaissance
pratiques
Manager la qualité et le contrôle APO11 • Gérer la qualité
interne MEA2 • Surveiller le système de contrôle interne
Mesurer la satisfaction clients et le MEA01 Surveiller et évaluer la performance et
service rendu conformité
Opérationnel
Fournir un service SI
Gérer les demandes DSS04 Gérer les requêtes de service et les incidents
Gérer les services APO09 Gérer les accords de service
Gérer les changements BAI05 • Faciliter le changement organisationnel
• Gérer les changements
BAI06
Construire
Gérer les exigences BAI02 Définir les exigences
Trouver des solutions BAI03 Identifier et construire les solutions.
informatiques aux enjeux Métiers
Choisir les projets APO05 Gérer le portefeuille
Développer, faire évoluer, mettre en BAI03 • Identifier et construire les solutions
œuvre la solution BAI07 • Accepter et mettre en œuvre
les changements
Gérer les configurations - CMMI BAI07 • Accepter et mettre en œuvre
DSS03 les changements
• Gérer les configurations
Exploiter
Gérer les incidents DSS04 Gérer les requêtes de service et les incidents
(restaurer le service)
Gérer les problèmes (traiter la DSS05 Gérer les problèmes
cause)
Gérer les mises en BAI07 Accepter et mettre en œuvre les changements
production
Gérer les configurations - DSS01 • Gérer les opérations
ITIL DSS02 • Gérer les actifs
DSS03 • Gérer les configurations
Assister les clients DSS04 Gérer les requêtes de service et les incidents
Les processus clés du SI de la DSI (CIGREF) et les processus CobiT
Le SI de la DSI CobiT
Support
Permettre le bon
fonctionnement du SI
Gérer les activités support
Gérer les achats et les relations APO10 Gérer les fournisseurs
fournisseurs
Gérer la facturation APO06 Gérer les budgets et les coûts
Gérer la sécurité et la continuité DSS06 • Gérer la continuité des affaires
Gérer la communication APO08 Gérer les relations
Gérer les normes et la APO11 • Gérer la qualité

documentation BAI08 • Gérer la connaissance
Gérer la conformité juridique et MEA03 Surveiller et évaluer la conformité avec les
normative exigences externes
Assurer la qualité APO11 Gérer la qualité
Gérer les ressources humaines APO07 Gérer les ressources humaines
Assurer la veille technico- APO04 Gérer l’innovation
fonctionnelle
Gérer la capacité BAI04 Gérer la disponibilité et la capacité
Gérer la disponibilité BAI04 Gérer la disponibilité et la capacité
Le mapping des processus clés du SI de la DSI (CIGREF) avec les processus CobiT est manifestement
très significatif, même en restant au niveau processus qui correspond à un niveau assez élevé de
granulométrie.
Une analyse plus approfondie du mapping devrait s’interroger sur la couverture de certains processus
CobiT: il s’agit essentiellement des processus de la famille EDM et de certains processus de la famille
APO.
Il conviendrait également de mettre l’accent sur le processus DSS08 :
• Établir et de maintenir le cadre de gouvernance (EDM01)

• Assurer l’optimisation de la valeur (EDM02)
• Assurer l’optimisation du risque (EDM03)
• Assurer l’optimisation des ressources (EDM04)
• Assurer la transparence pour les parties prenantes (EDM05)
• Définir le cadre de gestion de l’IT (APO01)
• Définir la stratégie (APO02)
• Gérer l’architecture d’entreprise (APO03)
• Gérer les contrôles des processus métiers. (DSS08).

VIII
Spécifications générales
d’un outillage CobiT
De nombreux outillages traitant de la gouvernance du système d’information existent sur le marché.
Proposer une étude de ce marché n’est évidemment pas l’objectif de cette étude. L’étude « Le SI de
la DSI » (Cigref) en dresse une liste et les positionne dans diverses catégories (gestion des demandes
- incidents – changements, analyse des temps / Planification, ateliers de génie logiciel, gestion des
configurations, calcul des coûts, gestion des tests…).
Il y apparaît :
• Qu’il n’existe pas d’outil « miracle » ni d’outil unique pour organiser le système d’information
de la DSI
• Que les DSI utilisent des outils spécifiques à chaque catégorie qu’ils intègrent ensuite
(best of breed)
• Qu’ils procèdent à des développements internes lorsque leurs besoins sont très spécifiques
L’ambition dans les lignes qui suivent est de dégager les principaux éléments d’un outillage qui permette
de supporter la mise en œuvre et le fonctionnement de l’ensemble de CobiT en tant que cadre de la
gouvernance et de la gestion du SI de l’entreprise.
C’est évidemment ici que se rejoignent plusieurs concepts fondamentaux mis en évidence dans les
chapitres qui précèdent :
• Les processus et leurs instanciations

• La structure de CobiT et plus particulièrement le diagramme des entités
• …
Chaque DSI, en fonction du paysage logiciel (gestion documentaire, gestion collaborative, supervision…)
qu’il opère, devra choisir ses propres orientations et son propre scénario d’implantation. Cela n’est
pas notre objectif d’aborder ici cette question très fortement dépendante des spécificités de chaque
entreprise.
A. Base documentaire « standard »

Le terme « standard » signifie que la base documentaire n’est évidemment pas propre à l’outil CobiT,
elle doit être prise en charge par une fonction équivalente dans un autre système mis en place au
niveau global de l’entreprise. Elle n’est donc pas détaillée plus avant ici.
Quels sont les documents candidats pour être gérés dans cette base ? D’une part, les occurrences des
livrables des pratiques et, d’autre part, les documents liés aux attributs de la capabilité (procédures,
plans de formation, audits externes…).
Le système en question doit inclure au minimum la gestion des éléments suivants :
• les versions
• les droits / restrictions d’accès
• le suivi des lectures
~ Vous n’avez pas encore lu
~ Vous avez déjà lu
~ Modifié depuis votre dernière lecture
• les rappels proactifs si absence de lecture
Il doit également inclure des fonctions de recherche :
• Par « entité » CobiT :

~ Processus
~ Pratique
~ Livrable
~ …
• Par date
• Par auteur, partie prenante
• …
Les documents pourront être de types divers (MS Office, PDF, Méga, Aris Toolset…). Pour des
raisons de sécurité, le cryptage des documents stockés devra être possible.
B. Gestion d’activités « standard »

Le terme « standard » signifie que la gestion d’activité n’est évidemment pas propre à l’outil CobiT,
elle doit être prise en charge par une fonction équivalente dans un autre système. Elle n’est donc pas
détaillée plus avant dans ce cadre.
Quelles sont les activités qui doivent y être gérées ?
• Les activités liées au fonctionnement des pratiques

• Les activités liées à la mise en place des pratiques (écriture des procédures, mise en place
des outillages spécifiques …)
• Les activités liées au calcul des indicateurs
Les fonctionnalités minimales sont les suivantes :
• Libellé
• Description
• Planification, suivi d’avancement, gestion des ressources, rappels d’échéances par mail…
• …
C. Gestion « standard » des indicateurs

Le terme « standard » signifie que la gestion d’indicateurs n’est évidemment pas propre à l’outil CobiT,
elle doit être prise en charge par une fonction équivalente dans un autre système. Elle n’est donc pas
détaillée plus avant dans ce cadre.

Quels sont les indicateurs qui doivent y être gérés?
• Les indicateurs liés aux processus.

• Les métriques SI d’entreprise.
Il convient de prévoir les éléments suivants :
• Périodicité
• Valeurs mesurées et objectifs (avec dates)
~ Dernière valeur
~ Historique
• Responsable
• Description des sources informationnelles et de la manière de le calculer.
(Lien vers la base documentaire)
• Présentation graphique des résultats « standard »
• TBE
Une bonne pratique est de favoriser l’existence d’un indicateur même sur base d’informations
encodées manuellement par rapport à la difficulté de mise en place d’indicateurs connectés avec les
systèmes automatisés de supervision qui existeraient par ailleurs.
D. Les acteurs

On se reportera au chapitre VI, point A (Des « rôles » aux « acteurs »). Retenons que l’outil doit
supporter et gérer le lien entre les acteurs et les tableaux des responsabilités.
E. Les vues

Plusieurs vues sont possibles :
• Vue synoptique
~ Liste des processus
• Mise en œuvre
• Avancement
• Indicateurs
• Acteurs
~ TBE
• Vue par processus
~ Métriques
• Mise en œuvre
• Suivi
~ Pratiques
• Synthèse d’avancement
• Mise en œuvre
• Vue par acteur
~ Liste des responsabilités
~ Avancement des tâches
~ Liste des tâches
• Vue du A (de RACI)
~ Contrôle d’avancement des activités dont il est A
• Vue par livrable
~ Mise en œuvre
~ Suivi
• Vue par pratique
~ Avancement des activités
~ Statut des livrables
Cette liste n’est pas exhaustive.

IX
Le cas d’affaire (« business case »)
de CobiT
A. Du côté des coûts…
Implanter CobiT c’est faire mieux fonctionner la gouvernance et la gestion qui fonctionnent déjà et dont les
coûts sont repris dans les budgets de fonctionnement et d’investissement du système d’information…
En suivant cette logique, et elle est souvent suivie, il n’y a pas lieu, voire il est même impossible,
d’identifier les coûts spécifiques à la gouvernance du système d’information ; ils sont incorporés dans
les budgets.
Il y a cependant des coûts liés à la gouvernance du SI qui peuvent être identifiés comme tels ; ce sont
généralement des dépenses externes (consultants, auditeurs, logiciels spécifiques, formation). Gartner
(Success with standards, Gartner EXP 2006) estime ces coûts à un montant correspondant à 2 à 3 %
du budget du système d’information.
B. Du côté des bénéfices…

Les recherches de Gartner montrent qu’en moyenne la productivité des organisations augmente de 30 %
en deux ans lorsqu’elles adoptent une approche consistante basée sur les standards de gouvernance.
De manière plus détaillée, l’ISACA a enquêté sur la relation existant entre l’implantation de CobiT et la
performance d’entreprise (Building the Business Case for CobiT and ValIT. Executive Briefing. ISACA
2009), selon les principes de la cascade abordés au chapitre III (point A.).
Les conclusions en sont heureusement positives, elles dépendent cependant :
• Des secteurs d’activité

• De la taille des entreprises
• De la localisation géographique des entreprises
Elles mettent aussi en évidence que certains processus contribuent plus à l’amélioration de la performance
en question, par exemple :
• APO01 : Définir le cadre de gestion du système d’information

• APO05 : Gérer le portefeuille
Ou encore :

• APO12 : Gérer les risques
(*: Success with standards, Gartner EXP 2006).

(**: Building the Business Case for CobiT and ValIT. Executive Briefing. ISACA 2009)

X
CobiT & l’externalisation du SI

A. CobiT est ce qui reste quand on a externalisé au maximum le
Les DSI recourent souvent à l’externalisation pour toute une gamme de services avec des modes
d’organisation et de contractualisation variés et avec des objectifs variés.
CobiT fixant le cadre de la gouvernance et de la gestion du SI de l’entreprise il est donc nécessaire de

s’interroger sur la manière de prendre en compte l’externalisation dans le cadre de sa mise en œuvre.
Les 36 processus de CobiT décrivent l’ensemble de la gouvernance et de la gestion du système

d’information de l’entreprise. Celle-ci en a par définition la charge. Et elle la garde, quelles que soient
les modes d’organisation et de contractualisation qu’elle utilise.
Dans le cas de l’externalisation, même dans une conception très poussée de celle-ci, le rôle de type A
(voir RACI) pour toutes les pratiques et tous les processus reste toujours en charge de l’entreprise et ne
peut jamais être confié au prestataire.
Ainsi, l’entreprise garde-t-elle obligatoirement la fixation des objectifs à atteindre, des indicateurs, des
modes de contrôle… le tout exprimable dans le cadre des processus, pratiques, activités, indicateurs…
spécifiés par CobiT.
Il est donc de bon conseil de suggérer aux entreprises en réflexion sur des externalisations d’utiliser
CobiT en tant que cadre pour spécifier ce sur quoi elle devrait porter. Bien évidemment d’autres questions
que celles de la fixation des rôles au regard de CobiT restent à préciser dans toute contractualisation,
notamment son coût, ses clauses contractuelles…
Il est de bon conseil également aux fournisseurs, même s’ils ne constituent pas la cible fixée pour cette
étude, de réfléchir au positionnement, par rapport aux processus et pratiques de CobiT, des services
qu’ils offrent : cela devrait améliorer l’efficacité de leur dialogue avec leurs clients potentiels.
En ce qui concerne le rôle R, il peut être soit entièrement délégué au fournisseur dans une contractualisation
de type obligation de résultat, soit partagé dans une contractualisation de type obligation de moyens.
Rôles Externalisable ?
R Réalise • Obligation de résultat : Oui.
• Obligation de moyen : Partagé.
A Autorité Non
C Consulté Oui
I Informé Oui
La question du « Quoi » et du « Comment » a été fortement mise en avant dans le cadre de ce livre. Ici
aussi, dans le cas de l’externalisation, cette dualité sera utile. Le « Quoi », exprimé par les processus ainsi
que par les pratiques de gestion et de gouvernance de CobiT, reste toujours à la charge de l’entreprise.
Le « Comment » est externalisable.
Il est donc nécessaire de souligner que la mise en œuvre concrète et efficace des processus CobiT
s’impose à l’entreprise même, et surtout, lorsqu’elle a externalisé les services correspondants. CobiT est
ce qui reste quand on a externalisé au maximum le système d’information…
Tous les processus de CobiT sont-ils égaux devant l’externalisation ? La réponse est manifestement
non.
Ainsi, les processus de gouvernance EDM (EDM01 à EDM05) ne sont pas externalisables puisqu’ils
sont ceux qui précisent la gouvernance du SI. Il doit en être de même des processus MEA (MEA01 à
MEA03) vu leur caractère de contrôle.
Il est fait référence ici à des rôles de type A & R, il va de soi que des rôles de type C & I peuvent toujours
être confiés à des prestataires.
En ce qui concerne les processus du domaine APO, confier un rôle R à un fournisseur, même de manière
partagée, n’est pas acceptable pour la définition du cadre de gestion du SI, la stratégie, la gestion du
portefeuille, les budgets, les ressources humaines, les fournisseurs, les risques. Pour les autres processus
d’APO, le rôle R devrait aussi être totalement internalisé, il pourrait cependant être partagé.
En ce qui concerne les processus des domaines BAI et DSS les rôles de type R peuvent être confiés à
l’extérieur dans le cadre d’une obligation de résultat.
Le tableau d’externalisation ci-dessous récapitule ces considérations relatives à CobiT et à l’externalisation.

Il constitue une enveloppe à l’évidence maximaliste des rôles qui peuvent être confiés à des
prestataires.
Il va de soi que chaque entreprise doit l’adapter à son contexte propre ; il est également de bon conseil
de l’établir avec une granulométrie plus petite (au niveau des pratiques de contrôle et de gestion).

Tableau d’externalisation - Enveloppe maximaliste
Processus CobiT Externalisable ?
A R C&I
Établir et de maintenir le cadre de gouvernance (EDM01) Non Non Oui
Assurer l’optimisation de la valeur (EDM02) Non Non Oui
Assurer l’optimisation du risque (EDM03) Non Non Oui
Assurer l’optimisation des ressources (EDM04) Non Non Oui
Assurer la transparence pour les parties prenantes Non Non Oui
(EDM05)
Définir le cadre de gestion de l’IT (APO01) Non Non Oui
Définir la stratégie (APO02) Non Non Oui
Gérer l’architecture d’entreprise (APO03) Non Partagé Oui
Gérer l’innovation (APO04) Non Partagé Oui
Gérer le portefeuille (APO05) Non Non Oui
Gérer les budgets et les coûts (APO06) Non Non Oui
Gérer les ressources humaines (APO07) Non Non Oui
Gérer les relations (APO08) Non Partagé Oui
Gérer les accords de services (APO09) Non Partagé Oui
Gérer les fournisseurs (APO10) Non Non Oui
Gérer la qualité (APO11) Non Partagé Oui
Gérer les risques (APO12) Non Non Oui
Gérer les programmes et les projets (BAI01) Non Oui Oui
Définir les exigences (BAI02) Non Oui Oui
Identifier et construire les solutions (BAI03) Non Oui Oui
Gérer la disponibilité et la capacité (BAI04) Non Oui Oui
Faciliter le changement organisationnel (BAI05) Non Oui Oui
Gérer les changements (BAI06). Non Oui Oui
Accepter et mettre en œuvre les changements (BAI07) Non Oui Oui
Gérer la connaissance (BAI08) Non Oui Oui
Gérer les opérations (DSS01) Non Oui Oui
Gérer les actifs (DSS02) Non Oui Oui
Gérer les configurations (DSS03) Non Oui Oui
Gérer les requêtes de service et les incidents (DSS04) Non Oui Oui
Gérer les problèmes (DSS05) Non Oui Oui
Gérer la continuité des affaires (DSS06) Non Oui Oui
Gérer la sécurité de l’information (DSS07) Non Oui Oui
Gérer les contrôles des processus métiers (DSS08) Non Oui Oui
Surveiller et évaluer la Performance et conformité (MEA01) Non Non Oui
Surveiller le système de contrôle interne (MEA02) Non Non Oui
Surveiller et évaluer la conformité avec les exigences Non Non Oui
externes (MEA03)
B. CobiT et e-SCM
Le standard e-SCM a émergé sur cette question de l’externalisation des services liés à l’informatique.
e-SCM a été mis au point par l’IT Service Qualification Center de l’Université de Carnegie Mellon, celui-
là même qui avait déjà produit CMMI. En France, une association s’est formée en vue de promouvoir
son utilisation : l’Ae-SCM.
(Voir www.ae-scm.fr)
e-SCM est constitué fondamentalement par des meilleures pratiques du sourcing (il y en a 95).
Chacune de ces pratiques est classée dans un référentiel à trois dimensions :
• Le cycle de vie du sourcing

• Le domaine d’aptitude
• Le niveau d’aptitude
Il est utile de remarquer que le modèle d’aptitude de la nouvelle V5 de CobiT est de même nature que
celui d’e-SCM.
Une caractéristique importante d’e-SCM est de comporter deux volets : un volet SP (Service Provider)
qui s’adresse aux fournisseurs de services et un volet CL (Client) qui s’adresse aux entreprises clientes
de ces fournisseurs.
Ces deux volets sont conçus en miroir de manière à améliorer la compréhension entre l’entreprise et
son fournisseur partenaires d’une externalisation. C’est, à l’évidence, le volet CL qui retiendra l’attention
de l’entreprise qui recourt à l’externalisation de certains services.
Comme pour plusieurs autres standards (Itil … voir ci-dessus), un mapping entre CobiT et e-SCM a été
établi. Notons cependant que ce mapping est fait par l’ITSQC et non par l’ITGI. Notons également qu’il
est fait par rapport à la version SP de e-SCM, et non la version CL, celle qui intéresse les entreprises,
et qu’il est fait par rapport à la V3 de CobiT. Un travail de préparation et une mise à jour seront donc
nécessaires avant de l’utiliser pratiquement. Le lecteur pourra utilement se reporter au document
suivant : “Comparing the eSCM-SP v2 and CobiT”, téléchargeable gratuitement à itsqc.org/downloads/
index.html.
De la même manière que pour les autres standards étudiés plus haut, ce mapping permettra d’établir
quels éléments d’e-SCM peuvent être mis en œuvre pour alimenter les pratiques de gestion et de
gouvernance de CobiT.

Best Practices Research est une marque déposée de Best Practices International - SARL au capital de 21 000 euros,
Pavillon Sisley, rue de la Croix-Rouge, 78430 Louveciennes - Tél. 06 07 04 79 61 - 503 117 988 RCS Versailles
Directeur des études : Philippe Rosé - philippe.rose@bestpractices-si.fr

Rédaction : Aurélie Chandèze - Philippe Rosé
Correction révision : Alain Condrieu
Conception graphique : Charles Ballesterros
Marketing/vente : Marc Guillaumot - marc.guillaumot@bestpractices-si.fr
w w w. be s t re s e a rc h .fr
ISSN : 0753-3454 - Dépôt légal : février 2012.
www.bestresearch.fr

L'essentiel Du Référentiel Cobit

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

L'essentiel Du Référentiel Cobit

Transféré par

Droits d'auteur :

Formats disponibles

La boîte à outils

Implémenter CobiT V5 - mars 2012 - N° 13 - Best Practices Research • 3

SARL au capital de 21 000 euros – RCS Versailles 503 117 988

© jean-Pierre Delvaux, Best Practices International, 2012

Imprimé en Italie par Pixart.it

ISSN : 0753-3454 - Dépôt légal : mars 2012

Reproduction interdite – Tous droits réservés

4 • Best Practices Research - N° 13 - mars 2012 - Implémenter CobiT V5

A. CobiT : un outil très opérationnel page 14

II - Les principes de CobiT V5 page 14

A. Le caractère non encore achevé de la Version 5 page 14

Implémenter CobiT V5 - mars 2012 - N° 13 - Best Practices Research • 5

III - Des objectifs d’entreprise au

IV - L’instanciation des processus CobiT page 14

A. Instancier les processus page 14

V - CobiT et l’urbanisation du SI page 14

6 • Best Practices Research - N° 13 - mars 2012 - Implémenter CobiT V5

VII - Le comment page 14

VIII - Spécifications générales d’un outillage CobiT page 14

A. Base documentaire « standard » page 14

A. Du côté des coûts… page 14

X - CobiT et l’externalisation du SI page 14

Implémenter CobiT V5 - mars 2012 - N° 13 - Best Practices Research • 7

A. CobiT : un outil très opérationnel

• Le système d’information devient de plus en plus important dans les entreprises

B. Faire les bonnes choses et faire bien les choses

Implémenter CobiT V5 - mars 2012 - N° 13 - Best Practices Research • 9

L’éventail de solutions à la disposition de l’entreprise étant de deux types :

C. Quelques vérités à rappeler…

10 • Best Practices Research - N° 13 - mars 2012 - Implémenter CobiT V5

CobiT réserve au conseil d’administration et au Directeur Général l’autorité et la responsabilité de

Il appartient au DSI de mettre en place concrètement cette implication, progressivement en fonction

2. De CobiT et des directions des métiers

Il est pour principe fondamental que la gouvernance et la gestion du SI de l’entreprise ressortent de la

3. De CobiT et du DSI

4. De CobiT et de l’entreprise

Pour reprendre le questionnement du Quoi et du Comment, l’entreprise a toujours en charge le Quoi

Implémenter CobiT V5 - mars 2012 - N° 13 - Best Practices Research • 11

5. De CobiT et de l’entreprise (bis)

6. De CobiT et des processus

7. Du caractère international de CobiT

8. De l’adaptabilité de CobiT à la culture française et aux modes français

12 • Best Practices Research - N° 13 - mars 2012 - Implémenter CobiT V5

10. De CobiT et des technologies

11. De CobiT et de l’audit informatique

12. De CobiT, de sa complétude et de son caractère non prescriptif

13. De CobiT et du TBE (Tableau de Bord Equilibré / Balanced Score Card)

Implémenter CobiT V5 - mars 2012 - N° 13 - Best Practices Research • 13

Les principes de CobiT V5

B. La fusion CobiT / RiskIT / ValIT

• EDM01 (Établir et de maintenir le cadre de gouvernance)

RiskIT comprend également un générateur de scénarios de risques (liés au système d’information),

Implémenter CobiT V5 - mars 2012 - N° 13 - Best Practices Research • 15

C. Des processus de gouvernance et des processus de gestion

D. La structure de CobiT V5

16 • Best Practices Research - N° 13 - mars 2012 - Implémenter CobiT V5

1. Les processus

Il y a les quatre processus de Governance qui sont regroupés dans le domaine EDM.

Chaque processus est accompagné dans CobiT:

Noms des domaines Abréviations

2. Les pratiques de gestion et de gouvernance

Elles sont réparties de la manière suivante en fonctions des domaines :

Chaque pratique est accompagnée :