Vous êtes sur la page 1sur 74

UNIVERSITÉ DE LAUSANNE

ÉCOLE DES HAUTES ÉTUDES COMMERCIALES

Du contrôle de gestion informatique à l’IT Gouvernance.


Proposition d’un modèle de tableau de bord de l’activité IT basé
sur COBIT et ITIL.

Mémoire présenté par Hicham, HIDDAK


Sous la direction de M. Jacky AKOKA

en vue de l'
obtention du

Diplôme Postgrade en informatique et organisation

Année académique 2002-2003

devant le jury composé de :


Prof. AKOKA JACKY, directeur du mémoire
Prof. MUNARI SILVIO, directeur du programme MBI
HEC Lausanne- MBI 2003

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

Objectifs du travail

Dans le cadre de ce travail de diplôme, je me propose d’analyser la problématique de maîtrise


-contrôle et pilotage- de la composante « Systèmes d’information » au sein des organisations.
L’objectif principal étant la proposition d’un modèle générique de Gouvernance de l’activité
informatique, ce travail s’articule essentiellement autour de trois grandes parties :

Une première partie consacrée à la revue et l’analyse de la littérature de contrôle des


systèmes d’information.

Une deuxième partie où je propose un modèle de système de contrôle de gestion informatique


en se basant sur le processus IT Financial Management du standard ITIL (Information
Technology Infrastructure Library). Dans cette partie, un accent particulier est mis sur les
différents outils de contrôle de gestion informatique préconisés par ledit standard.

Une troisième partie dédiée à la proposition d’un modèle de tableau de bord pour l’activité
d’une DSI en se basant sur COBIT (Control Objectives for Information and Related
Technology) et l’ITIL.

Le but de l’utilisation de COBIT et ITIL comme référentiel dans l’analyse « contrôle de


gestion informatique / IT Gouvernance » est d’exploiter les meilleures pratiques préconisées
par ces deux standards tout en ayant étudié la faisabilité technique de leur combinaison.

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

Table des matières

Objectifs du travail 3
1. Introduction 7
2. Analyse de la problématique de contrôle de l'IT 7
2.1.Problématique de contrôle de l'IT 8
2.1.1.Pourquoi contrôler? 8
2.1.2.Objectifs de contrôle et ses perspectives? 9
2.1.2.1 Objets du contrôle 10
2.1.2.2 Perspectives de contrôle 11
2.2. Comment contrôler ? Stratégies et outils de contrôle 12
2.2.1 Choix d’une stratégie de contrôle 12
2.2.1.1 Centre de coûts sans répartition 12
2.2.1.2 Centre de coûts avec répartition 12
2.2.1.3 Centre de profit 13
2.2.2 Choix d’un outil de contrôle 13
2.2.2.1 Contrôle institutionnalisé 13
2.2.2.2 Audit des systèmes d’information 14
3. Fonction IT dans l’organisation 15
3.1. Positionnement de la fonction IT 15
3.1.1 Fonction IT participant à un ou plusieurs processus stratégiques 15
3.1.2 Fonction IT ne participant pas directement aux processus stratégiques 15
3.1.3 Fonction IT comme gestionnaire des outils de type back-office 16
3.2. Contributions de la fonction IT 16
3.3. Modélisation générique de la fonction IT 17
4. Système de contrôle de gestion informatique basé sur l'ITIL 18
4.1. Qu'est ce que l'ITIL? 18
4.1.1. Définition 18
4.1.2. Processus de l'ITIL 19
4.1.3. Bénéfices de l'ITIL 20
4.2. IT Financial Management 20
4.2.1. Relations avec les autres processus 21
4.2.2. Activités de l'IT Financial Mangement 21
4.2.2.1. Comptabilité des coûts 22
4.2.2.1.1 Coûts d’investissement / Coûts de fonctionnement 22
4.2.2.1.2 Coûts directs / Coûts indirects 22
4.2.2.1.3 Coûts fixes / Coûts variables 23
4.2.2.2. Budgétisation 23
4.2.2.3. Analyse des projets d'investissement 23
4.2.2.4. Récupération de coûts 24
4.2.3. Bénéfices de l’IT Finance Management 25
4.2.3.1. Visibilité des coûts 25
4.2.3.2. Planification 25
4.2.3.3. Optimisation 25
4.2.3.4. Récupération des coûts 25
4.3. Proposition d’un système de contrôle de gestion informatique 25
4.3.1. Analyse de la problématique de mesure de la performance 25
4.3.1.1. Limites du modèle de calcul économique orienté « coûts » 26
4.3.1.2. De la mesure des coûts à celle de la performance 26
4.3.1.2.1 Amélioration de la rentabilité 27
4.3.1.2.2 Amélioration de la productivité 28

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

4.3.2. Présentation du modèle du système de contrôle de gestion informatique et de ses outils 29


4.3.2.1. Information 30
4.3.2.2. Explication 31
4.3.2.3. Sélection et choix 31
4.3.2.4. Décision 31
5. Mise en place d’un tableau de bord IT basé sur COBIT et ITIL 33
5.1. Tableau de bord et activité IT 33
5.1.1. Principes fondamentaux des tableaux de bord 33
5.1.2. Contrôle de gestion informatique et tableau de bord IT 34
5.1.3. Tableau de bord IT 34
5.2. Analyse COBIT - ITIL 36
5.2.1. COBIT 37
5.2.2. Positionnement de COBIT et ITIL par rapport aux autres standards 38
5.2.3. Comparaison COBIT - ITIL 40
5.2.3.1 Tableau comparatif 40
5.2.3.2 Analyse de correspondance 41
5.3. Construction du tableau de bord IT 44
5.3.1. Méthodologie 44
5.3.2. Construction 44
5.3.2.1. Définition des facteurs clés de succès 44
5.3.2.2. Croisement des facteurs clés de succès avec les niveaux du tableau de bord IT 48
5.3.2.3. Définition des indicateurs par FCS 49
5.3.3. Architecture logicielle et prototypage 53
5.3.3.1. Architecture logicielle 53
5.3.3.1.1. Niveau acquisition 54
5.3.3.1.2. Niveau normalisation 54
5.3.3.1.2.1 Définition d’une ontologie 54
5.3.3.1.2.2 Description des données en XML 55
5.3.3.2. Prototypage 59
5.3.3.2.1. Objectifs 59
5.3.3.2.2. Besoins 59
5.3.3.2.2.1 Besoins non fonctionnels 60
5.3.3.2.2.2 Besoins fonctionnels 60
5.3.3.2.3. Use Cases 60
5.3.3.2.4. Ecrans de l’application 63
6. Conclusion 70
Table des figures 73
Références 74

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

" : L'informatique est le sixième poste de frais généraux dans les entreprises
industriels, avec 1% du chiffre d'affaires, derrière la maintenance (2.3%), la recherche et
développement (1.8%), les infrastructures et locaux, l'administration et le marketing (entre
1.1% et 1.4%). Les dépenses informatiques sont revues au plus juste. Les projets stratégiques
sont maintenus (sécurité, relations clients, formation,...) mais tous les autres postes sont
diminués."
Source: CEGOS, Evolution des frais généraux des entreprises industrielles françaises, février 2003.

" :A l'horizon 2006, la dépense informatique mondiale devrait progresser de


4.4% par an."
Source: Article paru dans le magazine "CIO: Stratégie et technologie" N° 4- Mars 2003 - page 18.

" :Les DSI estiment, à plus de 80%, ne pas avoir la capacité de mesurer l’impact
de l’informatique."
Source:Etude sur la valeur économique de l’informatique lancée par ACADYS.

" : Un projet sur deux est abandonné avant son achèvement ."
Source:Cours Audit des systèmes d’information DPIO.

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

1. Introduction
Dans toutes les entreprises, la construction d' une usine, d' un réseau commercial ou tout
simplement le processus de production (produit ou service), donnent lieu à l' établissement de
budgets détaillés, rigoureusement contrôlés, et font l' objet d'études de rentabilité
prévisionnelle et de mesure de performance économique. Les systèmes d' information, pour
plusieurs raisons, méritent la même attention. En effet, les entreprises recourent de plus en
plus aux moyens de télécommunications pour des besoins de transmissions, aux systèmes
d'information pour des besoins de traitement et d' analyse, et aux bases de données pour des
besoins de stockage. L' utilisation accrue de ces différents services informatiques entraîne
cependant une modification de la structure des coûts où la part des frais informatiques
augmente. Il n'est guère possible de contrôler ces coûts sans la mise en place d'un système de
gestion permettant le cas échéant leur re-facturation.

L’intérêt de la mise en place d' un tel système est de pouvoir mesurer et contrôler dans un
premier temps les coûts engendrés par l' informatique, d'
établir des devis et "facturer" des
prestations aux utilisateurs, de pallier la perte de visibilité des coûts liés au partage des
responsabilités de maîtrise d' oeuvre - maîtrise d' ouvrage, et finalement de gérer un centre
informatique comme un centre de responsabilité à part entière. Dans un deuxième temps, il
s'agira de mesurer la valeur et la contribution des technologies d'information.

2. Analyse de la problématique de contrôle de l'IT


Généralement, deux significations distinctes sont associées au mot "contrôle":

Surveillance: Où contrôler signifie vérifier que les choses se déroulent conformément à ce


qu'on souhaite. Le souhait peut d' ailleurs être formulé en terme plus ou moins précis, sous
forme d'objectifs, de standards,...

Maîtrise: Notion plus global associée au concept de pouvoir. Dans ce sens contrôler revient à
maîtriser, ce qui implicitement suppose au préalable ou en même temps surveiller.

De ce fait, l'
activité de contrôle s'
inscrit dans une logique générale des systèmes de gestion
regroupant trois ensembles d' action:

• Finalisation: Choix des objectifs


• Organisation: Mise en oeuvre et agencement des moyens propres à atteindre ces
objectifs
• Animation et contrôle: Mise en place d' instruments permettant d'
évaluer les résultats
obtenus (et les méthodes par lesquelles ils ont été obtenus)

L'observation des entreprises montre que, très souvent, le domaine des systèmes
d'
information se caractérise par un faible niveau de contrôle. L'
explication la plus souvent
avancée est liée au processus d'
assimilation de la technologie:

Dans la phase de diffusion initiale, l' objectif principal est de favoriser l'
innovation, et de ce
fait, l'
intensité de contrôle est faible. Dans les phases ultérieures, la maturité de la technologie
s'
accompagne d' un renforcement de contrôle. Dans cette perspective, améliorer le contrôle
des systèmes d' information constitue désormais un objectif clairement affirmé par de
nombreuses entreprises. Dans ce qui suit, on s' intéressera dans un premier temps à la
problématique de contrôle. Dans un second plan, on analysera les problèmes liés l' évaluation.

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

2.1. Problématique de contrôle de l'IT

La mise en place d' un système de contrôle des systèmes d' information implique que des
réponses cohérentes soient apportées à deux questions fondamentales:

• Pourquoi contrôler les systèmes d' information? Quels sont les objectifs poursuivis?
Que cherche-t-on à obtenir par la mise en place d'
un système de contrôle des S.I?
• Comment contrôler les systèmes d' information? Comment agencer les différents
moyens propres à améliorer le degré de contrôle?

2.1.1. Pourquoi contrôler?

Le contrôle est normalement conçu pour favoriser le progrès dans l' organisation en favorisant
l'
apprentissage organisationnel. Derrière cet objectif général, une grande variété d' objectifs
immédiats peut être distinguée, et dont la pluralité s'
explique par la diversité des contextes de
contrôle:

Contrôle de gestion au service informatique: L' objectif principal du responsable du service


informatique est de contrôler l' évolution des coûts qu' il maîtrise directement (matériel,
logiciel, personnel informaticien,...) et de justifier, s'
il y a lieu, des demandes de moyens
auprès de la direction générale qui doit décider ou non l' allocation de ressources
complémentaires à partir de résultats observés ou prévisionnels.

Evaluation après implantation d' une solution informatique: Lorsqu' un projet est achevé, que
l'
application est mise en place, certaines entreprises procèdent à une évaluation ponctuelle.
Celle-ci est destinée en priorité au chef de projet. On vérifie ainsi dans quelle mesure les
objectifs du projet ont été atteints et l'
on cherche à corriger par des actions de maintenance les
dysfonctionnements révélés par l' utilisation du système.

Etude d' opportunité: Un responsable de domaine cherche à évaluer de manière prévisionnelle


l'
intérêt économique et la praticabilité d' un projet ou d' un ensemble de projets avant d'
y
affecter des ressources en matériel, logiciel, personnel,...

Ces quelques exemples montrent le caractère hétérogène des contextes d'


évaluation, donc des
objectifs de contrôle. La préoccupation principale de l'utilisateur se révèle à travers la
dimension dominante parmi les suivantes:

• Dimension technique: Très axée sur les outils (réseaux, serveurs,...) dont on surveille
le fonctionnement. Ainsi, le Directeur informatique va suivre l' évolution des temps de
réponse, des débits, des taux de panne,...
• Dimension économique: Elle s' exprime en terme de coûts (rattaché plus ou moins à
l'
utilisateur des outils), d'efficience (résultats obtenus par rapport aux moyens engagés),
d'efficacité (résultats évalués par rapport aux objectifs.
• Dimension organisationnelle: Elle s' exprime par les évaluations en terme de
satisfaction exprimée par des utilisateurs, ou en terme de performance de l' organisation.

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

2.1.2. Objectifs de contrôle et ses perspectives

Afin de mieux situer le problème, on propose ci-dessous un modèle [Voir Figure 1] 1


d'analyse permettant de mieux situer les différents objets du contrôle. En effet, ce modèle
permet de mieux définir les objectifs du contrôle en précisant son objet: Se demander
"Pourquoi contrôler ?" conduit immédiatement à préciser "quoi contrôler ?" et "Selon quelle
perspective ?". Dans ce modèle, un système d' information est considéré comme un ensemble
finalisé et organisé de ressources (matériel, logiciel, personnel, ...) qui fournit un produit
(l'
information) et des services associés (fonctions de traitement, de stockage, de
communication,...) à des utilisateurs devant réaliser des tâches dans le contexte d' une
organisation. L' exécution de ces tâches produit des résultats observables au niveau d' un
individu, d'un groupe, de l'
organisation,...

Contrôle prévisionnel d’efficacité et


Ressources d’efficience des investissements

Contrôle de l’efficience, de la qualité


du processus de construction

Système d’information
Contrôle de fonctionnement :
Disponibilité, fiabilité, temps de
réponse

Outputs : Contrôle de l’efficience technique


Services +Informations Contrôle de qualité output

Contrôle de l’utilisation
Processus d’utilisation Contrôle de satisfaction des
utilisateurs

Contrôle prévisionnel d’efficacité et


Résultats d’efficience A posteriori

Figure 1 : Les objets de contrôle des systèmes d’information

1
Robert Reix. Systèmes d’information et management des organisations. Quatrième édition Vuibert.

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

Par ailleurs et comme le montre le schéma objet de la figure 2 2 , les technologies


d'information exercent des effets multiples: Automatisent, informent et transforment. Elles
automatisent certaines tâches. Elles fournissent des informations. Elles transforment
l'
organisation par modification des tâches et des rôles. L' existence de ces effets multiples
conduit à distinguer, comme le montre la figure 1, différents objets de contrôle d' une part, et
différentes perspectives dans l'
analyse de la contribution à la performance d'autre part.

ENVIRONN-
EMENT
ORGANISA-
TIONNEL

PROCESSUS OPÉRTAIONNEL
AUTOMATISENT + INFORMENT+
TRANSFORMENT
TECHNOLOGIES BUSINESS
DE VALUE
L’INFORMATION

PROCESSUS MANAGÉRIAUX
AUTOMATISENT + INFORMENT+
TRANSFORMENT

ENVIRONN-
EMENT
CONCURR-
ENTIEL

Figure 2 : Les effets des technologies d’information

2.1.2.1 Objets du contrôle

Selon la stratégie de l'entreprise et ses préoccupations dominantes, les entités sur lesquelles
porte le contrôle sont différentes. Ainsi, peut-on contrôler:

• Les moyens utilisés: Le matériel informatique ou l' ensemble matériel, logiciel et


personnel spécialisé étaient à l' origine facilement identifiables, la dispersion des
ressources liées au développement des réseaux, la multiplication des outils rendent
désormais cette identification plus compliquée;

• Le produit et les services offerts: La qualité de l'information et des fonctions fournies


par le système d' information est un autre objet du contrôle. La difficulté d'
évaluation est
plus grande car il importe de tenir compte des différentes utilisations qui en sont faites
par différents utilisateurs.

• Des processus: On peut vouloir contrôler la qualité des processus de construction des
systèmes d'information (par exemple, vérifier si un projet a été réalisé dans les délais et
au coût prévu), et également les processus d'utilisation (Qu'est ce qui est utilisé? Dans
quelles conditions?)

2
Robert Reix. Systèmes d’information et management des organisations. Quatrième édition Vuibert

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

• Des résultats: L' utilisation du système d' information, s'


est-elle traduite par une
amélioration des résultats mesurables (Baisse des coûts, hausse du chiffre d' affaires,
gains financiers,....) au niveau d'un service global?

A signaler que la diversité de ces objets de contrôle rend délicate l'


interprétation des
variations de performance observées.

De l'idée d'un système d' information à sa mise en place par un processus de construction, de
l'
usage des solutions ainsi construites à la modification des pratiques au travers d' un
processus d' utilisation, aux choix des terrains d'
utilisation dans un processus concurrentiel, à
chacune de ces étapes de transformation des investissements en contribution à la performance,
les entités objets du contrôle, comme les perspectives retenues pour les évaluer, vont être
distinctes.

2.1.2.2 Perspectives de contrôle

Dans cette partie, on retrouve toutes les notions classiques de mesures en matière de contrôle
de gestion.

Perspective d'
efficience: Rapprochement entre les résultats obtenus avec les moyens engagés.
On trouve ainsi des mesures simples de productivité directe en nature (nombre de ligne
imprimées, nombre de transactions supportées,... rapportées au montants investis) ou de
productivité en valeur, rapport d' un résultat mesuré en valeur monétaire aux ressources
consommées. (Chiffre d' affaires par terminal de vente) ou de coûts.

Perspective d' efficacité: Rapprochement des résultats obtenus avec les objectifs fixés. Par
exemple : accroissement du nombre de clients correspondant à 80% de objectifs annoncés
grâce à un système de publipostage. Ces mesures d' efficacité, comme souvent celle de la
productivité en valeur sont compliqués parce qu' il est toujours délicat de séparer les
différentes causes de variation du résultat.

Perspective de satisfaction: C'


est une vision de l' efficacité organisationnelle exprimée au
travers des perspectives des utilisateurs. Ces perspectives peuvent découler de causes
multiples (image du service informatique, utilisation plus ou moins agréable d' un système
d'information,...)

De ce fait, lorsqu'on veut caractériser la performance d'


un système d'
information, il est
souhaitable de proposer différentes mesures3:

• La qualité du système technique: accès facile, usage convivial, temps de réponse


court,...
• La qualité de l' information produite: précision, actualité, absence de biais,
accessibilité, exhaustivité,...
• Le niveau d' utilisation: temps réel d' utilisation, nombre de logiciel ou de
fonctionnalités utilisées,...
• La satisfaction de l' utilisateur: traduisant l'
attitude de l'
usager à l'
égard du produit ou
de l'
outils,...

3
Delone W. McLean E. « Information Systems Succes : The quest for the dependant variable », Information
Systems Research 1995.

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

• L' impact sur le performance individuelle: effet sur le temps et la qualité de la


décision, effet sur le niveau d'
effort, gains en productivité, amélioration de la qualité de
vie dans le travail,...
• L' impact sur la performance organisationnelle: efficience générale, performance
financière, avantage compétitif, flexibilité, création de la valeur,...

Le croisement de ces perspectives avec les objets de contrôle, à titre prévisionnel ou


rétrospectif, aboutit à une très grande diversité de modalités du contrôle. De ce fait, évaluer
l'
efficience technique d' un système d' information de cotation en ligne en bourse n'est pas le
même problème qu' évaluer l'efficacité globale d'
un GROUPWARE collaboratif à usage
collectif et constitue également un problème différent d'évaluation d'un Data warehouse.

2.2. Comment contrôler ? Stratégies et outils de contrôle

Comme dit précédemment, un système de contrôle de l' activité IT doit d'


une part fournir les
moyens d' une gestion efficace et efficiente des ressources en technologie d' information et en
particulier fournir les éléments nécessaires aux décisions d' investissement; d'autre part, il doit
encourager une utilisation efficace des systèmes d' information existants et motiver les
utilisateurs et les informaticiens à agir au mieux des intérêts de l'organisation. Pour ce faire,
un système de contrôle de l' IT doit reposer sur une stratégie de contrôle, clairement définie,
pour pouvoir par la suite déterminer les outils de contrôle adéquats. A noter que ces outils
reposent pour la plupart sur la théorie du contrôle de gestion classique.

2.2.1 Choix d’une stratégie de contrôle

Plusieurs stratégies ou principes peuvent être adoptés face à une problématique de contrôle :

• Contrôle formel : Il s’appuie sur des mesures de coût et de productivité par


rapport à des allocations de ressources définies dans le cadre de budgets
établis et surveillés systématiquement.
• Contrôle par le marché : Dans ce cas, un système de prix sur le marché
ouvert à la concurrence détermine l’allocation des moyens.

De ce fait, plusieurs solutions peuvent être distinguées:

2.2.1.1 Centre de coûts sans répartition

Dans ce cas, les coûts liés aux systèmes d’information ne sont pas isolés ou, s’ils sont
enregistrés, ne sont pas répartis aux utilisateurs les ayants occasionnés. Ces coûts sont
considérés comme des charges générales de structure. Cette approche a pour avantages la
simplicité (pas de problème de répartition donc pas de procédures comptables) et la
motivation forte à l’utilisation de technologies d’information puisque les utilisateurs ne
supportent pas les coûts d’utilisation. Cependant, elle ne garantit ni l’efficience ni l’efficacité
dans la mesure où les utilisateurs peuvent formuler des demandes irresponsables non
justifiées.

2.2.1.2 Centre de coûts avec répartition

Les dépenses engagées pour le développement et le fonctionnement des systèmes


d’information sont isolées et suivies dans un ou plusieurs centres de coûts, et font l’objet

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

d’une répartition entre les différents utilisateurs sous forme d’une facturation interne. Cette
approche présente l’avantage de responsabiliser les clients internes dans leurs demandes. La
politique de re-facturation oblige les entités informatiques à justifier leurs investissements et
les utilisateurs à réfléchir sur leurs véritables besoins. De l’autre côté, elle se heurte au
problème du choix d’un système de prix interne. En effet, lors du choix d’un tel système, il
est difficile de respecter des contraintes importantes (principe de compréhension du système
par l’utilisateur, principe de sa stabilité et de son caractère économique). Dans ce cadre, on
distingue beaucoup de formules :

• Facturation au coût total


• Facturation au coût marginal
• Facturation au coût standard

2.2.1.3 Centre de profit

C’est l’application de la logique du contrôle par le marché. L’unité organisationnelle en


charge de l’activité IT se comporte comme un centre de profit devant couvrir ses dépenses
par la facturation de ses services aux usagers, et cela en concurrence éventuelle avec des
prestataires externes. Par ailleurs, l’entité informatique peut rechercher des clients externes
pour vendre les prestations pour lesquelles elle est en surcapacité. Cette démarche pose des
problèmes liés à la confidentialité et à la sécurité, et d’autre part à l’instabilité des prix du
marché.

2.2.2 Choix d’un outil de contrôle

En fonction de la stratégie de contrôle adoptée, l'


organisation dispose d'un certain nombre de
moyens pour l'appliquer. En générale, on distingue deux types d' outils de contrôle:

2.2.2.1 Contrôle institutionnalisé

C'est un contrôle qui est plus ou moins régulier et qui repose pour l'
essentiel sur des moyens
internes. A ce niveau, on distingue des solutions de:

Planification limitée et contrôle inexistant: Absence de dispositif organisé de contrôle des


systèmes d' information.
Planification forte et faible contrôle a posteriori: Evaluation de l'efficacité au niveau du
schéma directeur et des études préalables, avec très peu de suivi.

Planification restreinte avec fort contrôle de l' utilisation et de la satisfaction: Evaluation


prévisionnelle réduite mais contrôle systématique de l' usage des ressources et de la
satisfaction des utilisateurs à travers des enquêtes internes de satisfaction.

Contrôle fort à dominante technique: Le contrôle de l' Output informatique est réalisé grâce à
des indicateurs techniques (incidents, activité,...) et peu d'
indicateurs de coûts.

Contrôle de gestion intégré: Application aux systèmes d'information de la même démarche


de contrôle adoptée pour les autres activités de l'
entreprise ( Budgets, plans, analyse des
écarts,...)

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

2.2.2.2 Audit des systèmes d’information

La mission d' audit du système d'information vient en complément aux dispositifs du contrôle
institutionnalisé. C'
est un examen critique qui permet de mettre en évidence d' éventuelles
anomalies quant au fonctionnement des systèmes d' information et se distingue par son
audit4:
caractère ponctuel. On distingue plusieurs types de missions d'

• Audit stratégique.
• Audit des applications
• Audit de la sécurité informatique
• Audit d' exploitation
• Audit de la sécurité logique
• Audit des coûts
• Audit .....

4
Cours Audit des systèmes d'
information DPIO de M. J.AKOKA

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

3. Fonction IT dans l’organisation


3.1. Positionnement de la fonction IT

Qu’il s’agisse d’un simple service informatique ou d’une direction de systèmes d’information,
la fonction IT a pour mission d’accompagner les unités opérationnelles pour la maîtrise de
leurs processus (organisation et informatisation), en alignant ses objectifs, ses ressources et le
budget affecté aux technologie de l’information avec les programmes et les objectifs de ces
unités. Cette mission impose à la fonction IT, quelque soit sa position dans l’organisation,
une bonne connaissance des métiers de base et des attentes des clients. De ce fait, trois types
de positionnement de la fonction IT peuvent être identifiés :

• Fonction IT participant à un ou plusieurs processus stratégiques


• Fonction IT ne participant pas directement aux processus stratégiques mais
bénéficiant d’importants investissements
• Fonction IT comme gestionnaire des outils de type back-office

3.1.1 Fonction IT participant à un ou plusieurs processus stratégiques

L’arrêt ou l’interruption d’une partie d’un processus IT impacte directement l’activité de


l’organisation. La fonction IT dans ce cas est stratégique. Elle s’implique activement dans les
processus commerciaux, marketing, logistiques,…Pour cela, la fonction IT est dotée d’une
unité exclusive chargée du contrôle de gestion informatique. Exemples d’entreprises entrant
dans ce genre de configuration :

Type d’organisations Processus critiques


Compagnies aériennes Réservations
Banques Réseau boursier
Distribution Logistique et approvisionnement

Schéma organisationnel correspondant :

!
! "#
$
#

3.1.2 Fonction IT au bénéfice d’importants investissements mais ne participant


pas directement aux processus stratégiques

Dans ce cas de figure, l’informatique n’est pas totalement reconnue comme un partenaire
actif dans la contribution aux affaires. Dans une telle configuration, si contrôle de gestion

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

informatique existe, il est assuré par le « corporate » contrôle de gestion. Exemples


d’entreprises entrant dans ce genre de configuration :

Type d’organisations Processus concernés


Universités Gestion des serveurs et du réseau

Schéma organisationnel correspondant :

!
$
#
%

3.1.3 Fonction IT comme gestionnaire des outils de type back-office

Dans ce cas, la fonction IT dépend généralement de la Direction Administrative et Financière.


Son pouvoir est très limité dans ce rattachement par l’approche traditionnelle des fonctions
financières, plus portées sur la gestion des ressources financières, l’optimisation, la réduction
des coûts que sur les leviers de l’efficacité offerts par les technologies de l’information. La
barrière culturelle à franchir est pesante. Exemples d’entreprises entrant dans ce genre de
configuration :

Type d’organisations Processus concernés


Petites et Moyennes Entreprises Gestion IT back-office

Schéma organisationnel correspondant :

$
#
&
!

3.2. Contributions de la fonction IT

On peut exprimer la réalité économique de la fonction IT dans l’organisation en terme de


contributions qui dépassent le simple cadre financier et couvrent un rôle étendu allant de la
stratégie au fonctionnement quotidien. Dans ce cadre, ces contributions peuvent se décliner
sous plusieurs formes:

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

• Contributions à l’activité et au développement


• Mise en place d’une architecture des systèmes d’information
• Rôle d’intégrateur de solutions et de systèmes
• Veille technologique
• Expertise
• Cohérence globale des systèmes d’information
• Performance et efficience

3.3. Modélisation générique de la fonction IT

Dans ce modèle, quelque soit la position de l’unité organisationnelle en charge de la gestion


des technologies d’information, il s’agit de la percevoir comme un ensemble de processus
consommant des ressources en entrées et fournissant des produits ou services en sorties. Les
ressources investies en IT comprennent le capital investi en terme de technologie (réseaux,
serveurs,…) et de ressources humaines consacrées à l’activité IT. La performance est
caractérisée par des indicateurs de performance économique (retour sur investissement, retour
sur vente,…), de productivité (ventes par employé, ventes par agence,…), d’utilisation des
ressources (taux d’utilisation,…).

L’avantage d’un tel modèle [Figure 3] 5 est sa capacité à offrir une distinction claire des
composantes.

INPUTS PROCESSUS DE OUTPUTS


TRANSFORMATION

LES RESSOURCES INTERACTIONS ENTRE LES RESULTATS OBTENUS


INVESTIES DANS L’IT COMPOSANTES DE L’ORGANISATION
IT

CAPITAL INVESTI PROCESSUS PERFORMANCE


ECONOMIQUE
TECHNOLOGIE D’INFO SERVICE LEVEL AGREEMENT
PRODUCTIVITE
RESSOURCES STRUCTURE ORGANISATIONNELLE
HUMAINES DEGRE D’UTILISATION
DES RESSOURCES

Figure 3 : Modèle générique de la fonction IT

5
Robert Reix. Systèmes d’information et management des organisations. Quatrième édition Vuibert

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

4. Système de contrôle de gestion informatique basé sur l'ITIL


Le contrôle de gestion est une sorte d’outil « humain » d’aide à la justification économique
des projets, à la décision et au dialogue avec la direction générale. Son rôle est important car
il doit analyser, expliquer, standardiser, homogénéiser pour rendre l’organisation plus
transparente et lui permettre ainsi d’améliorer sa performance. Dans ce cadre, cette partie n’a
pas pour objectif de décrire le contrôle de gestion classique, mais de proposer un modèle de
système de gestion informatique basé sur le processus IT Financial Management de l’ITIL.
Pour ce faire, nous allons présenter dans un premier temps la norme ITIL : Information
Technology Infrastructure Library. Dans un deuxième temps, il sera question de décrire le
processus IT Financial Management pour aboutir en fin à un modèle de système de contrôle
de gestion informatique.

4.1. Qu'est ce que l'ITIL?

4.1.1. Définition

L' Information Technology Infrastructure Library, bibliothèque de l' infrastructure des


technologies d'information est un ensemble de guides de références développés par l' OGC:
Office of Government Commerce du Royaume-uni. C' est l'équivalent des ISO pour les
technologies de l'information. Les guides de ce cadre de référence décrivent une approche
intégrée basée sur les processus bien définis ainsi que sur des règles de l' art de l'
industrie
informatique pour une gestion efficace et efficiente des services IT. Cette bibliothèque a été
conçue vers la fin des années 80 pour aider le gouvernement central du Royaume-uni à
améliorer les prestations de leurs services IT. Aujourd'hui, plus qu' un cadre de référence des
meilleures pratiques en gestion des services IT, c'
est une véritable industrie en elle-même, qui
touche aux domaines suivants:

• Formation
• Certification
• Société de conseil
• Outils logiciels
• Associations

Le coeur de la méthode est constitué par les domaines Service Delivery et Service Support

Figure 4: The ITIL Service Management Schema

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

4.1.2. Processus de l'ITIL

Concrètement, la méthode ITIL se présente sous la forme d' un ensemble de livres regroupés
en neuf domaines, chacun couvrant un ensemble particulier de cycle de vie de la production
informatique. Les six premiers domaines sont consacrés à la production informatique
proprement dite; les quatre derniers sont consacrés aux questions relatives à l'
environnement
informatique.

Le tableau suivant fournit une description sommaire des processus composant les deux
domaines centraux:

Domaines Processus Objectif


Gérer l' infrastructure de l' IT en identifiant,
Gestion des enregistrant et fournissant de l' information de
configurations gestion sur tous les items qui sont sous contrôle
de la gestion des configurations.
Rétablir les services à la clientèle le plus
Gestion des incidents rapidement possible afin de réduire l' impact
des incidents sur l'infrastructure
Réduire l' impact des incidents et problèmes
causés par des erreurs dans l' infrastructure, et
empêcher leur retour.
Gestion des problèmes
La gestion des problèmes cherche à trouver la
Service Support
racine des problèmes et supprimer les erreurs
de façon permanente.
Utilise des méthodes et des démarches bien
définies de façon à ce que tout changement soit
Gestion des traité efficacement et rapidement, réduisant
changements ainsi au minimum les conséquences des
incidents reliés au changement pour améliorer
les activités de travail quotidiennes.
Examine les services de l' IT sur un plan global
Gestion des mises en
et tient compte de tout aspect des mises à jour,
oeuvre
autant technique que non technique.

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

Domaines Processus Objectif


Maintient et améliore la qualité des services
de l' IT à travers un cycle continuel de
Gestion des niveaux de
négociation, surveillance et établissement de
service
rapports afin rencontrer les objectifs des
clients.
Assure le meilleur rendement possible des
services et du soutien informatisé de
Gestion de la l'
infrastructure de l' IT afin de procurer un
disponibilité niveau de disponibilité soutenu à des coûts
justifiables permettant ainsi à l' entreprise
Service Delivery d'atteindre ses objectifs.
Pour assurer que les caractéristiques des
capacités et des performances actuelles et
Gestion de capacités
futures, reliées aux exigences de l' entreprise,
seraient offertes à des coûts justifiables.
Assure que tous les services et le soutien
Gestion de la continuité
informatisé de l' IT puissent être rétablis dans
des services de l'
IT
les délais prescrits et convenus.
Fourni une fonction de gérance rentable des
Gestion financière des
actifs de l' IT servant à la prestation des
services IT
services.

4.1.3. Bénéfices de l'ITIL

La mise en place et l'


amélioration continue des processus de l'
ITIL permet aux organisations
de:

• Améliorer le taux d' utilisation des ressources


• Etre plus compétitives
• Réduire le nombre de retouches
• Réduire la duplication des tâches
• S' assurer que les projets sont finis dans les temps prescrits
• Améliorer le taux de disponibilité, la fiabilité, la sécurité de données
• Justifier les coûts de fourniture de services de qualité
• Fournir les services que l' organisation a vraiment besoin
• Intégrer les processus commun
• Documenter et communiquer les rôles et responsabilités des fournisseurs (internes et
externes) de services
• Capitaliser les expériences pour en tirer profit
• Identifier et fournir des indicateurs-clé éprouvés

4.2. IT Financial Management

L’objectif du processus IT Financial Management est la gestion des ressources financières au


niveau de l'activité IT pour supporter les objectifs organisationnels. Les données financières
alimentent le côté dépense ou coût de l' équation de prise de décision en prenant en

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

considération les changements dans l'infrastructure IT, les systèmes, les ressources humaines
ou les processus. Un bon fonctionnement des processus IT Financial Management aide les
managers IT à prendre de meilleures décisions en matière de planification et d' investissement
IT. De l'autre côté, la mise en place de ce processus permet d' apporter des éléments de
réponse à une question qu'
on se pose rarement: "pourquoi cela coûte tellement cher?"

4.2.1. Relations avec les autres processus

Le succès de mise en place du processus IT Financial Management dépend du degré de


coordination avec tous les processus de l’environnement IT. Les activités de budgétisation,
de comptabilité des coûts, de leur facturation requièrent des inputs de la part de tous les
managers. L’IT Financial Manager doit avoir une ligne de communication ouverte envers
chaque IT manager et leur fournir les lignes directrices pour le reporting de l’information
financière.

Figure 5 : Optimisation des Processus ITIL

L’idée de base est que les décisions au niveau de n’importe quel processus aient une
implication visible en terme de coûts sur le processus IT Financial Management, d’où la
nécessité d’optimisation de l’ensemble des processus. Ceci passe par la création d’un Service
Level Agreement (SLA) qui définit les responsabilités du département IT. Le processus IT
Financial Management joue le rôle d’un filtre essayant de faire converger les exigences des
clients et les solutions qui ont été validées économiquement.

4.2.2. Activités de l'IT Financial Mangement

Figure 6 : Les Activités de l’IT Financial Management

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

4.2.2.1. Comptabilité des coûts

C'est l'activité qui est à la base du processus IT Financial Management. Elle suppose
l'
identification des biens et activités (éléments de coût) auxquels les coûts peuvent être
assignés. Cela suppose aussi le développement de schémas d' allocation ou de répartition des
coûts grâce auxquels les coûts relatifs à chaque élément sont répartis justement et
équitablement sur les clients internes, les projets en cours ou les activités concernées. Parmi
ses missions:

• Elle permet aux départements IT de quantifier, comprendre et tracer les coûts afin
d'envisager les meilleures possibilités d' économie au niveau de l' activité IT
• Elle permet aux utilisateurs d' avoir une meilleure compréhension de l' allocation des
ressources, ce qui réduit la frustration et la confusion
• Elle assiste les managers dans leur démarche de planification et de contrôle des
opérations dans les organisations IT
• Une comptabilité des coûts couplée à une gestion des coûts protège les départements
IT des offensives basées sur les coûts d' éventuels prestataires externes.

Avant leur assignation ou affectation à un client particulier, les coûts doivent être classés et
catégorisés. Généralement, on distingue les classifications suivantes :

• Coûts d’investissement / Coûts de fonctionnement


• Coûts directs / Coûts indirects
• Coûts fixes / Coûts variables

Chacune de ces classifications est utile lorsqu’il s’agit de déterminer comment comptabiliser
ces coûts et comment les assigner aux clients. Par ailleurs, ces classifications sont aussi utiles
lors de la négociation des prix des prestations avec les clients. De l’autre côté, une
classification correcte permet aux IT Finance Managers une meilleure compréhension de
l’évolution des coûts en fonction des changements des niveaux de service fournis.

4.2.2.1.1 Coûts d’investissement / Coûts de fonctionnement

Les coûts d’investissement sont les coûts relatifs à l’achat et à l’amélioration des actifs fixes.
Par exemple, le remplacement d’un serveur ou la mise à jour d’un réseau sont typiquement de
coûts d’investissement. Les objets d’investissement ont une valeur intrinsèque pour plus d’un
an. Par conséquent, leurs coûts s’amortissent tout au long de leur cycle de vie. Ils sont
souvent assignés aux clients par un amortissement annuel.

Les actifs de fonctionnement ont une durée de vie inférieure à une année. Les coûts de
fonctionnement incluent les coûts nécessaires à l’exercice de l’activité IT et à la maintenance
de son environnement (formation, maintenance, support, salaires,…). La standardisation, le
SLA, les outils automatisés, les contrats d’outsourcing, sont autant de facteurs qui influent
sur les coûts de fonctionnement.

4.2.2.1.2 Coûts directs / Coûts indirects

Les coûts directs sont les coûts qu’on peut affecter à une activité ou une unité
organisationnelle particulière. Ce sont des coûts facilement identifiables et quantifiables.
Quelques exemples : Développement et test, outsourcing, formation, maintenance, achats,…

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

Les coûts indirects sont les coûts qu’on ne peut pas affecter directement à un département
particulier. Ils ne peuvent être assignés à un seul client. De ce fait, ils doivent être répartis sur
l’ensemble des départements de façon équitable. Ce sont les coûts les plus difficilement
comptabilisables. Il est important à ce niveau de développer une approche d’allocation de ces
coûts afin de s’assurer que l’ensemble des départements les perçoit de façon juste et équitable.
Des coûts tels que les temps d’arrêt, coûts cachés et les coûts administratifs peuvent être
difficiles à mesurer et à allouer.

4.2.2.1.3 Coûts fixes / Coûts variables

L’intérêt d’une telle classification se trouve dans le fait qu’elle permet de faire des calculs de
rentabilité en fonction du niveau d’activité.

Les coûts fixes sont les coûts qui restent inchangés même si le niveau d’usage varie. Ils
incluent n’importe quel coût négocié en amont pour l’initiation du service. Exemple : contrats
de maintenance des composantes hardware. A activité nulle, ces coûts restent toujours à un
certain niveau.

Les coûts variables varient à travers le temps en fonction de l’usage des ressources. Par
exemple : les coûts d’un service helpdesk sont des coûts variables.

4.2.2.2. Budgétisation

C'est l' activité de planification du processus IT Financial Management. Lors de


l'
établissement des budgets, on planifie les activités futures et on évalue la performance des
activités en cours. C'est une activité qui requière des compétences en communication et
coordination. Ceci a pour effet indirect l'
alignement de la stratégie et des objectifs en matière
IT avec ceux de l'organisation.

4.2.2.3. Analyse des projets d'investissement

De part sa mission, le département IT est appelé à évaluer les coûts et les bénéfices des
changements proposés dans le cadre de projets d' investissement. On distingue plusieurs
méthodes d'analyse de l'
impact financier d'
un changement:

Valeur Nette Actuelle (VNA) :

Appelée aussi la « Net Present Value ». Elle amène à penser qu’un investissement est
rentable si la valeur actuelle des recettes nettes d’exploitation attendues est supérieure à la
dépense initiale.

Valeur Résiduelle de l’Investissement (VRI):

En matière de gestion des technologies d’information, cette méthode est la plus importante
dans les choix d’investissement et varie selon les architectures concernées. Elle consiste en le
calcul de la valeur des actifs après leur durée de vie. Elle est surtout utilisée par les sociétés
de Leasing ou d’outsourcing de matériels informatiques.

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

Return On Investment (ROI) :

Il exprime, en mois ou en années, la durée nécessaire pour que l’investissement réalisé par
l’entreprise soit compensé par les gains qu’il procure. Cette notion s’apparente bien à la
méthode du « point mort ». Ce critère présente cependant deux inconvénients majeurs : il
défavorise les projets de long terme et ne prend pas en compte l’influence du facteur temps.

Total Cost of Ownership (TCO):

Le Total Cost of Ownership (TCO) est défini comme étant le coût d' un bien tout au long de
son cycle de vie « utile ». L' analyse de TCO essaye d' inclure tous les coûts directs et
indirects. En effet, le TCO inclut non seulement le prix d'
achat, mais aussi les coûts de mise
en place, de formation, de maintenance, et de soutien. Il y a plusieurs approches possibles
pour cerner les éléments qui vont entrer dans le coût de possession informatique. Il faut
évidemment s’attacher aux coûts de fonctionnement que livrent les comptabilités analytiques,
en y incorporant les coûts d’achat sous forme d’amortissements. Ces coûts de fonctionnement
peuvent s’analyser par nature comme indiqué dans la liste ci-dessous :
• Les matériels (PC, imprimantes, portables, périphériques, matériels d’infrastructure :
serveurs, cartes de connexion, composants actifs...)
• Les logiciels (système d’exploitation, outils bureautiques, messagerie, émulations,
navigateurs, applications...)
• L’équipe d’exploitation (gestion technique...)
• L’équipe de support (help desk, cellule d’assistance
• administration...)
• La formation (interne, externe)
• Autres (consommables, documentation, énergie, place, etc.)

Indice de profitabilité (IP):

Pour un projet donné, c’est le rapport de la valeur actuelle des « cash-flows » d’exploitation à
son coût. Dans ce cas, on retiendra les projets qui présentent un indice supérieur à l’unité.

Taux Moyen de Rentabilité (TMR):

Pour un projet donné, c’est le rapport dont le numérateur est le « cash-flows » attendu du
projet et le dénominateur son coût global. Il s’agit de comparer ce taux par rapport à celui de
projets similaires (Benchmarks) . Pour une durée de vie identique, on retiendra naturellement
les projets qui présentent les taux les plus élevés. A noter que cette analyse ne permet pas
d’évaluer un investissement isolé mais d’établir une comparaison entre plusieurs.

Il est à signaler que chaque approche offre des avantages et des inconvénients. Aucune
méthode n' est idéale pour l'
évaluation de tous les changements.

4.2.2.4. Récupération de coûts

C'est l'
activité d'
imputation du processus IT Financial Management. L' organisation IT impute
les coûts de ses services aux utilisateurs de ces services. Cette activité suppose le
développement de méthodes d' imputation rationnelle et de facturation des coûts aux clients.
Ces méthodes doivent être compréhensibles et validées par les utilisateurs.

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

4.2.3. Bénéfices de l’IT Finance Management

L’implémentation d’un tel processus favorise une meilleure visibilité des coûts, la
planification, l’optimisation et la récupération des coûts

4.2.3.1. Visibilité des coûts

Une gestion financière propre au département IT permet au management d’avoir une


visibilité sur le calcul des coûts. Grâce à cette même visibilité :

• L’IT fournit des services selon des budgets négociés avec les clients
• Les coûts de fourniture d’un niveau de service connu sont identifiés et traçables
• Un reporting de l’origine des coûts doit être fait aux clients internes et au top
management
• Les usagers sont facturés équitablement pour les services fournis et selon des prix
connus
• Le département peut comparer le coût de fourniture de ses services avec les coûts
facturés par des prestataires externes (Benchmarking)

4.2.3.2. Planification

Le développement d’un budget rationnel encourage une meilleure planification IT. Les
clients développent par ailleurs une conscience de coûts concernant les services qu’ils
utilisent. En plus, la planification focalise l’attention sur les objectifs et les buts de
l’organisation, et facilite l’évaluation des risques.

4.2.3.3. Optimisation

Les budgets fournissent des métriques qui peuvent être utilisés pour la mesure de la
performance, la fiabilité et la satisfaction des utilisateurs. La comparaison des performances
avec les plans organisationnels est la première étape de l’optimisation de performance. Ce
processus d’optimisation utilise les informations collectées à travers l’activité de comptabilité
des coûts et inclut les procédures et les techniques de management et de réduction des coûts
tout en maintenant et en améliorant les niveaux de service.

4.2.3.4. Récupération des coûts

Un bon système de comptabilité de coûts facilite l’amélioration de la récupération des coûts.


Les unités de coûts doivent être logiques et facilement compréhensibles. La pratique de la
récupération des coûts pousse les groupes IT à justifier leurs dépenses et leurs bénéfices.
D’autre part, ces groupes se trouvent obligés de développer un sens d’efficience et
d’efficacité des coûts.

4.3. Proposition d’un système de contrôle de gestion informatique

4.3.1. Analyse de la problématique de mesure de la performance

Avant de proposer le système de contrôle de gestion informatique, cette partie a pour objectif
de confronter la notion de « coût » avec celle de « valeur ». Autrement dit, il s’agira de faire

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

un rapprochement entre la théorie de rentabilité économique avec celle de la performance


basée sur l’appréciation de la valeur, et cela afin que notre système de contrôle de gestion
informatique puisse intégrer les deux notions.

4.3.1.1. Limites du modèle de calcul économique orienté « coûts »

Les techniques de mesure de coûts permettent, comme cela a été décrit précédemment,
d’appréhender et d’apprécier les différentes composantes des coûts informatiques. Cependant,
lorsqu’il s’agit de la mesure de la rentabilité des systèmes d’information, ces techniques
démontrent une certaine limite, car l’idéal est de pouvoir se situer à un autre niveau d’analyse
et d’appréciation, celui de la valeur ajoutée des systèmes d’information.

Cependant, les pratiques actuelles sont loin de se situer à ce niveau de raisonnement, en


témoignent les principales techniques :

• Elaboration des budgets détaillés des projets


• Suivi des coûts des projets
• Facturation des prestations informatiques
• Etudes BENCHMARKING

Le facteur commun entre ces différents pratiques est la non prise en considération de la
valeur des systèmes d’information et de leur apport ou impact sur la performance des
organisations. Ce constat est en partie imputable aux raisons suivantes :

• Non correspondance de l’investissement à un objectif tangible de gain économique


• Difficulté d’une part de mesure des changements de qualité du service, et d’autre part
de la prise en compte des coûts complets de l’informatisation
• Non implication des métiers et des directions générales dans la réflexion
informatique6

De ce fait, l’incapacité à mesurer précisément la valeur du système d’information engendre


une logique de gestion par les coûts certes indispensable, mais insuffisante car seule, elle est
néfaste à l’action de la fonction IT. De l’autre côté, une mesure de la valeur économique de
l’IT permettrait aux organes de décision d’évaluer réellement la contribution de ses systèmes
d’information. En effet, les limites de la mesure de la dépense économique de l’informatique
sont dues à l’aspect réducteur de la technique, focalisé en grande partie sur le volet « coûts »
et sans perception significative de l’amélioration de la productivité.

4.3.1.2. De la mesure des coûts à celle de la performance

Partant de la conclusion que le calcul économique centré sur les coûts n’est pas à lui seul
suffisant dans les processus de management de l’activité IT, il est nécessaire d’élargir la
notion de la rentabilité et de la substituer par celle de la performance, laquelle permet
d’aborder la notion de gain de façon plus large. A noter à ce niveau, que la mesure de la
valeur des systèmes d’information passe forcément par la définition d’une stratégie des
systèmes d’information alignée avec celle de l’organisation (Existence d’un schéma
directeur).

6
Etude sur la valeur économique de l’informatique lancée par ACADYS 2002

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

Les ressources IT offrent une valeur ajoutée en matière de développement du chiffre


d’affaires, de la qualité de service aux clients externes ou aux utilisateurs internes, des
conditions de travail. La mesure de cette valeur ajoutée passe par l’utilisation de méthodes et
d’outils qui doivent permettre l’appréciation de la productivité interne des processus IT, mais
aussi de sa rentabilité au service de l’organisation.

4.3.1.2.1 Amélioration de la rentabilité

L’amélioration de la rentabilité de l’informatique peut se faire par le suivi d’indicateurs


définis par des outils tels que :

L’analyse de la valeur ;

« C’est une méthode de compétitivité organisée et créative visant la satisfaction du besoin de


l’utilisateur par une démarche spécifique de conception à la fois fonctionnelle, économique et
pluridisciplinaire »7

Sous cette théorie, la valeur d’un produit est une grandeur proportionnelle à la satisfaction de
l’utilisateur et inversement proportionnelle à son coût. La satisfaction des besoins d’un
utilisateur est couverte par des fonctions du produit à un niveau de qualité acceptable.

Valeur = Fonctions
Coût

Exemple : La valeur d’un progiciel (ERP) peut être calculée à partir du coût de son
acquisition, de son développement ou de son déploiement et de l’estimation des fonctions
qu’il remplit. Cette estimation peut se faire en termes financiers (économies), ou de gains de
temps (temps de traitements).

La méthode ABC ;

« C’est une méthode d’optimisation des processus. Elle est fondés sur une évaluation au plus
juste des coûts de revient de chacune des activités du processus »8

La méthode ABC : Activity Based Costing - comptabilité d’activités – vise l’amélioration de


la pertinence des informations fournies par le calcul des coûts. La notion d’activité est au
cœur de la démarche ABC. Une activité est définie comme une combinaison de personnes, de
technologies, de méthodes et d’environnements qui permet de produire un output : produit
(Application informatique) ou service (Maintenance préventive des logiciels)

Grâce à l’approche ABC, le but est l’obtention d’une affectation plus pertinente des charges
indirectes aux outputs en se basant sur le principe suivant :

« Les outputs consomment les activités, et les activités consomment les ressources »

7
Michel Leroy. Le tableau de bord au service de l’entreprise. Editions d’organisation 2001. page :11.
8
Alain Fernandez. Les nouveaux tableaux de bord des décideurs. Editions d’organisation 2001. page :427.

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

Exemple :

Le calcul du coût de revient d’un service de maintenance d’un site Internet pour une direction
régionale passe par la détermination de la part du coût de revient des activités ayant
intervenu dans la réalisation de service (gestion de la base de données, entretien physique des
serveurs, maintenance applicative,…). Dans ce cadre, il s’agit de répondre à la question
suivante : « Quelle est la part de ces activités nécessaire à l’obtention de ce service ? ». Le
coût de ces activités est déterminé à son tour par l’affectation des coûts de ressources
consommées par ces activités.

% %

OUTPUTS ACTIVITES RESSOURCES


(SERVICE OU PRODUIT)

APPLICATION INFO GESTION DES SINISTRES MATERIELS


SECURITE INFO GESTION DES INCIDENTS OUTILS LOGICIELS
INTEGRATION INSTALLATION APP RESSOURCES HUMAINES
MIGRATION DONNES MAINTENANCE DES BD PRESTATAIRES EXTERNES
MISE À NIVEAU GESTION INFRASTRUCTURE …
… DEVELOPPEMENT
CONCEPTION
HELP DESK

CONSOMMATION CONSOMMATION

Figure 7 : Modèle ABC

La mise en évidence des relations entre ces éléments et les calculs des coûts qui en découlent
permettent de mieux gérer les ressources, d’obtenir des coûts plus pertinents et d’améliorer
les performances. A cette fin, il est possible de définir des indicateurs pour piloter les
améliorations souhaitées.

4.3.1.2.2 Amélioration de la productivité

L’amélioration de la productivité interne de l’IT peut se faire quant à elle par le suivi
d’indicateurs définis par des outils tels que :

La méthode AMI :

L’objectif de cette méthode est de fournir un modèle pratique et validé pour définir et utiliser
des approches quantitatives de contrôle et d’amélioration de la production logicielle. Elle est

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

basée sur une métrologie par objectifs permettant de cibler les métriques clés pour éviter une
collecte de données excessive.

Evaluer
-Evaluer Environnement
-Définir les objectifs de
mesure
-Confronter les objectifs
avec l’évaluation

Améliorer Analyser
-Diffusion de données -Décomposer
-Validation des l’objectif initial en
métriques sous objectifs
-Comparaisons avec -Identification des
les objectifs métriques

Mesurer
-Collecte de données
primitives
-Calcul des métriques

Figure 8 : Modèle AMI

La méthode des points de fonction :

Cette méthode aide à prévoir la taille d’un projet et son effort de développement, et d’autre
part à mesurer la productivité du développement informatique. Les points de fonctions sont
une unité de mesure des logiciels. Ils quantifient les fonctionnalités offertes à l’utilisateur
indépendamment des techniques de mise en œuvre utilisées et se substituent à la « ligne de
code », plus difficilement saisissable en début de projet et qui ne permettent pas de comparer
des applications réalisées avec des langages différents. En plus, ils ont l’avantage d’avoir des
normes reconnues et des procédures détaillées.

4.3.2. Présentation du modèle du système de contrôle de gestion informatique et


de ses outils

« Le contrôle de gestion est un système d’information et de communication qui, grâce à ses


procédures, ses méthodes, et ses documents, aide tous les niveaux (opérationnel, tactique et
stratégique) à définir des objectifs cohérents et conformes aux choix politiques de l’entreprise
et à en piloter la réalisation » 9.
9
Michel Leroy. Le tableau de bord au service de l’entreprise. Editions d’organisation 2001. page :12.

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

Partant de cette définition, le contrôleur de gestion informatique aura, en fonction des


niveaux précédemment définis, à comprendre la structure des coûts, les analyser, les
expliquer afin de permettre une prise décisionnelle optimale. De ce fait, sa mission passe par
plusieurs niveaux :

Niveau 1 : Information
Niveau 2 : Explication
Niveau 3 : Sélection et choix
Niveau 4 : Décision
*

"
#

) "#

'($

$ #
!

Contrôle de gestion Niveaux


informatique d’activité IT

Figure 9 : Système de contrôle de gestion informatique

4.3.2.1. Information

Ce niveau se base sur la compréhension de tout les coûts informatiques (structure, et nature)
[Voir partie 4.2.2.1.]. Les outils classiques du contrôleur de gestion informatique à ce niveau
sont :

• Les unités d’œuvre, les coûts de jour-homme, du Mips10,…


• Le suivi budgétaire classique : calcul des écarts, prix de revient,… [Voir partie
4.2.2.2.]
• Le contrôle des engagements et la vérification des factures : Missions ponctuelles
d’audit des coûts

La difficulté à ce niveau réside dans l’éclatement des centres de coûts [Voir partie 4.2.1.] et
dans la technicité du métier informatique qui rend difficile le dialogue entre informaticiens et
gestionnaires.

Le rôle du contrôleur de gestion informatique est d’alerter en cas de dépassement budgétaire


en offrant aux opérationnels de la DSI les moyens de progresser.

10
Million d’instructions par seconde

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

4.3.2.2. Explication

A ce niveau, et au-delà de la simple gestion budgétaire, le contrôleur de gestion informatique


doit proposer en outre une vision analytique des coûts. L’objectif étant de faire comprendre
aux clients ou utilisateurs, les coûts des services rendus et de prévenir et d’expliquer tout
dépassement budgétaire.

Les outils principaux à ce niveau sont :

• Le prix de revient (par service, par application, par projet,…)


• Les « Service Level Agreements » ou contrats de service internes : engagement de
l’IT vis-à-vis des clients internes.
• La refacturation interne [Voir partie 4.2.2.4.]

Le rôle du contrôleur de gestion informatique à ce niveau est de vérifier la conformité et la


pertinence des différents projets et processus avec la stratégie de l’entreprise par des
mécanismes de benchmarking par exemple.

4.3.2.3. Sélection et choix

Ce niveau correspond à l’animation en aidant la maîtrise d’ouvrage et les utilisateurs à


comprendre les conséquences des changements informatiques sur l’organisation des métiers.

Les outils principaux à ce niveau sont : [Voir partie 4.2.2.3.]

• Valeur Nette Actuelle (VNA)


• Return On Investment (ROI)
• Total Cost of Ownership (TCO)
• Valeur Résiduelle de l’Investissement (VRI)
• Indice de profitabilité (IP)
• Taux Moyen de Rentabilité (TMR)
• Les analyses de ratios

Le rôle du contrôleur de gestion informatique est d’assurer une meilleure compréhension des
enjeux financiers (Coûts et gains) par les clients au moment du lancement des projets.

4.3.2.4. Décision

Le contrôle de gestion informatique à ce niveau a un rôle de prévision, d’évaluation des


impacts budgétaires et d’anticipation en fonction des décisions stratégiques. Il est intégré aux
organes de décisions associés au directeur des systèmes d’information et participe à
l’évolution stratégique de l’IT de l’organisation.

Les outils principaux à ce niveau sont :

• La chaîne de valeur
• La SWOT ANALYSIS (Forces, faiblesses, opportunités, menaces)

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

• Analyse du portefeuille d’application (Modèles de McFarlan, Porter/Millar, Sullivan,


Galliers/Hirschheim)11
• Balanced ScoreCard : Tableau de bord prospectif 12

Le contrôleur de gestion informatique à ce niveau se positionne en tant que support du DSI


en favorisant la compréhension des problématiques globales du système d’information.

Avant de clore cette partie, il est à signaler que selon le type d’activité IT et le
positionnement de l’unité en charge de la gestion de l’IT dans l’entreprise [Voir partie 3.1.],
le contrôle de gestion informatique aura des rôles plus ou moins différents. Autrement dit, et
sur un plan théorique, plus la composante IT prend de l’importance dans l’activité de
l’organisation, plus le contrôle de gestion informatique devra prendre en charge les niveaux
précédemment décrit.

11
Cours Stratégie et technologies d’information DPIO : 8.Portfolio d’applications
12
Cours Stratégie et technologies d’information DPIO : 13.Tableaux de bord

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

5. Mise en place d’un tableau de bord IT basé sur COBIT et ITIL


L’élaboration d’un tableau de bord pour l’activité informatique en se basant sur COBIT et
ITIL s’inscrit dans le cadre de la mise en place de ce qu’on appelle la Gouvernance des
systèmes d’information. Le Gartner Group définit l’IT Gouvernance comme étant « les
mécanismes grâce auxquels l’entreprise atteint les objectifs qu’elle s’est fixés en matière de
technologies d’information ». Autrement dit, le terme « Gouvernance » en informatique
signifie aussi le pilotage des processus par lesquels les besoins métier sont identifiés,
analysés, hiérarchisés et satisfaits par la DSI. Du coup, il englobe tout ce qui est management
de l’informatique, conduite de projet, reporting, capitalisation des connaissances, gestion de
ressources humaines, etc. De ce fait, en s’appuyant sur des standards comme COBIT et ITIL,
le tableau de bord qu’on se propose d’élaborer n’a pas uniquement pour but de contrôler la
conduite de l’activité informatique, mais aussi de mettre à la disposition des acteurs
concernés des mécanismes qui permettent d’encourager les bonnes pratiques.

Dans ce contexte, on procédera dans un premier temps à la présentation de l’esprit d’un


tableau de bord IT. Par la suite, une analyse de correspondance entre les processus d’ITIL et
ceux de COBIT sera faite. Cette analyse constituera le référentiel du tableau de bord. On
terminera cette partie par la proposition d’un prototype applicatif réduit de cet outil de
gouvernance IT.

5.1. Tableau de bord et activité IT

5.1.1. Principes fondamentaux des tableaux de bord

« Un tableau de bord est une présentation synthétique pédagogique des indicateurs de


gestion qui permettent à un responsable de suivre la réalisation des objectifs de son unité de
gestion et d’en rendre compte » 13

Disposer d’un système de tableau de bord n’est pas une fin en soi. Le tableau de bord dans
une entreprise, comme dans un avion, permet au pilote de maîtriser sa trajectoire afin
d’atteindre son objectif. Cependant, et contrairement aux tableaux de bord des autres
fonctions de l’entreprise, où les indicateurs de gestion sont plus ou moins homogènes, le
tableau de bord de la fonction IT comprend des indicateurs qui sont hétérogènes. En effet, de
part la nature de sa mission consistant à accompagner les unités organisationnelles de
l’entreprise chacune dans son métier [Voir partie 3], la fonction IT peut être considérée
comme une organisation à part entière. De ce fait, son activité ne peut être pilotée que par
des indicateurs qui touchent à l’ensemble des processus IT.

En conséquence, un système de tableau de bord IT est à la fois un :

Outil de mesure de la performance :

Cette mesure peut se faire soit par rapport aux objectifs préétablis qui servent de référence
(Zéro réclamation des utilisateurs d’une application informatique) ou par rapport à des
benchmarks internes ou externes (Turnover ingénieurs informaticiens dans le secteur). La
différence constitue un écart exprimé en valeur absolue ou relative.
13
Michel Leroy. Le tableau de bord au service de l’entreprise. Editions d’organisation 2001. page :14.

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

Outil de diagnostic :

Le tableau de bord IT attire l’attention sur les phénomènes « anormaux », qui sont au-delà de
la tolérance définie en valeur absolue ou relative pour chaque indicateur. Exemple : La mise
en évidence du risque de dépassement de coûts sur le budget d’un projet de plus 10% du
budget total du projet.

Outil de dialogue et de réactivité :

Chaque acteur concerné commente alors ses résultats, explique les causes des éventuels
écarts et les mesures qu’il a prises à son niveau.

Outils d’information :

Le tableau de bord peut être utilisé pour informer le top management ou l’encadrement des
performances obtenues.

Pour remplir les fonctions précédemment décrites, le tableau de bord IT se doit être :

Simple : avec un nombre maximum de 15 indicateurs


Pertinent : avec les bons indicateurs
Synoptique : avec une vue d’ensemble des éléments important
Pédagogique : avec une prise en considération de la qualité de présentation
Rapide : avec un respect de délais d’édition et de diffusion

5.1.2. Contrôle de gestion informatique et tableau de bord IT

Afin d’assurer le lien entre notre système de contrôle de gestion informatique [Voir partie
4.3.2.] et le tableau de bord de l’activité IT, ce dernier devra prendre en considération et
intégrer les trois niveaux précédemment décrits, à savoir :

• Le niveau stratégique
• Le niveau tactique
• Le niveau opérationnel

L’idée derrière ce rapprochement est de pouvoir mettre en évidence au niveau du système de


contrôle de gestion informatique l’implication en terme de coûts ou de gains de chaque
variation constatée au niveau des indicateurs du tableau de bord IT.

5.1.3. Tableau de bord IT

A l’instar de tout outil de gestion et d’aide à la décision, l’élaboration d’un tableau de bord
pour une DSI devrait commencer par l’expression claire de la vision et des objectifs de
l’activité IT. Ceci se fait par la réponse à la question :

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

???
Où veut-on aller?

Figure 10-1 : Mission stratégique

En parfait alignement avec la stratégie business, la réponse à cette question représente la


définition de la mission de l’IT au sein de l’organisation. Par ailleurs, le pilotage d’une
activité quelle qu’elle soit, requiert une aptitude à pratiquer un diagnostic permanent qui
tourne autour de trois questions majeures :
???
Où sommes-nous maintenant ?

Figure 10-2 : Prise de conscience

???

Comment sait-on qu’on est arrivé à nos objectifs ?

Figure 10-3 : Métrique et contrôle

???

Comment faire pour y arriver ?

Figure 10-4 : Best Way ?

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

La combinaison de COBIT et ITIL vise la prise en considération de l’ensemble de ces


questions dans les système de tableau de bord de l’activité IT. En effet, le schéma suivant
montre et explique la « mécanique » recherchée à travers cet approche :

Où veut-on
aller ? Vision & Objectifs

Où sommes Métriques & contrôle COBIT


nous ?

Comment faire Best Practices ITIL


pour y arriver ?

Comment sait-on Mesure des écarts COBIT


qu’on est arrivé ? & Benchmarks

Figure 11 : Schéma conceptuel du système d’IT Gouvernance

5.2. Analyse COBIT - ITIL

Etant les standards internationaux les plus utilisés en matière de gouvernance des systèmes
d’information, COBIT et ITIL ont pu développer et intégrer depuis leur création, chacun en
des domaines particuliers, une forte dimension de « meilleures pratiques ».
Le but de cette partie est d’exploiter cette caractéristique de « Best practices » en essayant de
combiner les deux modèles afin de mettre en évidence éventuellement les facteurs clés de
succès préconisés par les meilleures pratiques des deux standards. Ces facteurs clés de succès
seront par la suite traduits en un ensemble d’indicateurs pour notre tableau de bord.

A noter qu’une telle démarche aura comme principal avantage l’assurance par le tableau de
bord d’une couverture optimale de l’activité IT, du fait que les indicateurs seront dérivés des
facteurs clés de succès, eux-mêmes dérivés d’un modèle combiné des deux meilleurs
standards de gouvernance IT.

Dans un premier temps, et après un bref rappel de la méthode COBIT, nous allons étudier la
faisabilité « technique » de la combinaison des deux méthodes grâce à un modèle d’analyse
du Gartner Group. Par la suite, nous allons procéder à une analyse comparative entre les deux
modèles. Ceci devra nous permettre enfin de dresser un tableau de correspondance entre les
processus des deux modèles.

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

5.2.1. COBIT

COBIT (Control Objectives for Information and Related Technology ) est un cadre de
référence international basé sur l’observation des bonnes pratiques, en matière de
gouvernance et de contrôle de l’IT. Il permet d' aider à rencontrer les besoins de gestion tout
en réduisant les écarts entre les risques d' affaires, les besoins de contrôle et les défis
technologiques en fournissant une structure de travail logique permettant de lier les processus,
les ressources et les informations aux stratégies et objectifs des entreprises en y ajoutant une
valeur. De ce fait, il a pour objectif d’aider les dirigeants à comprendre et à gérer les risques
informatiques, donc à maîtriser l’informatique et les systèmes d’information.

COBIT a été créé par l'ISACA (Information Systems Audit and Control Association)
représentée en France par l'
AFAI (Association Française de l'
Audit et du conseil
Informatique).

Figure 12 : COBIT Internal Control Framework14

COBIT procède selon le principe suivant :

Pour obtenir l’information nécessaire à l’atteinte de ses objectifs, l’entreprise


doit gérer ses ressources informatiques selon des processus, eux-mêmes regroupés par grands
domaines fonctionnels couvrant toute l’activité informatique.

COBIT retient ainsi 32 processus pour 4 domaines fonctionnels.


Ce sont des objectifs de contrôle de haut niveau. Ils se composent de 271 tâches
qui correspondent aux objectifs de contrôle détaillés ou points d’audit.

14
www.isaca.org

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

5.2.2. Positionnement de COBIT et ITIL par rapport aux autres standards

La décision de mise en place d’un système de gouvernance ou de pilotage de l’activité IT (un


tableau de bord IT ou un IT service management) met l’organisation face à une variété de
choix de modèles permettant le développement et l’amélioration continue de la composante
IT. En effet, il existe plusieurs modèles, standards, méthodes, pratiques et outils dont chacun
a été considéré à un certain moment, malgré leur différence, comme la référence qui va
garantir la performance, les niveaux de service et apporter une optimisation de coûts. Parmi
ces modèles, et outre COBIT et ITIL, on distingue : TCO, ISO17799, CMM,
SCORECARDS,…

Malgré leur différence, l’ensemble de ces modèles ont apporté, certes de différentes manières,
les mêmes éléments de réponse à la question : « Que veut-on atteindre avec
l’informatique ? », à savoir :

• Alignement de la stratégie IT à la stratégie business


• Amélioration de la qualité de service
• Réduction des coûts
• Réduction et maîtrise des risques
• Réduction des délais
Business

Alignement

Tem
Qualité de service

Risques IT

Réduction
Meilleure et maîtrise

Tem
Tem
Valeur IT

Réduction Réduction
Délais
Coûts

et maîtrise

Tem Figure 13 : Objectifs IT Tem

Problématique :

« Jusqu’à quel point est-il possible de construire un modèle en se basant sur la


combinaison de deux ou plusieurs des standards susmentionnés ? »

Pour répondre à cette question, nous allons faire appel à un modèle d’analyse élaboré par le
Gartner Group (Juin 2003). Ledit modèle consiste en une matrice bidimensionnelle de

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

positionnement des différents standards. Le premier axe d’analyse représente la spécificité de


l’IT par rapport au standard et le deuxième représente le degré d’abstraction de ces standards.

A B

D C

Figure 14 : Positionnement des standards IT 15

Les modèles se trouvant dans la zone « A » ont été développés spécifiquement pour les
organisations ou la composante IT a une grande importance, et sont censés par conséquent
apporter des solutions aux problèmes liés à la qualité du service informatique, à la gestion des
processus de l’activité IT et à l’optimisation des coûts informatiques. Ces modèles n’ont
aucune signification pour une activité non IT.

De l’autre côté, les modèles de la zone « C » ne sont pas spécifiques aux organisations IT. Ils
offrent une variété d’approches génériques pour définir et atteindre les objectifs de qualité
sans être nécessairement concernés par les processus spécifiques de l’activité en question.
Néanmoins, vu le degré de crédibilité qu’ils ont atteint au niveau des processus business,
certains d’eux ont été adoptés au niveau des activités IT, sans pour autant pouvoir déterminer
le « Comment faire ». Exemple: Balanced Scorecards IT.

Le modèle d’analyse du Gartner Group est pertinent pour comprendre la problématique


d’intégration et de combinaison de ces standards dans la mesure où il les présente dans un
continuum. En effet, les modèles appartenant au même quadrant de la matrice d’analyse sont
vraisemblablement plus favorables à l’intégration et la combinaison que ceux qui ne le sont
pas. Toutefois, cela ne veut pas dire que les modèles appartenant à différents quadrants ne
peuvent pas être combinés. Dans ce cas, des efforts d’intégration seront plus consistants. De
ce fait, et en se basant sur ce modèle d’analyse, la combinaison entre COBIT et ITIL est

15
Source : Gartner Research (Juin 2003) DF-20-1898

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

techniquement plus évidente que celle de l’ITIL et le Scorecards, en raison de la similarité de


l’envergure, de la portée et de l’approche des premiers.

5.2.3. Comparaison COBIT - ITIL

5.2.3.1 Tableau comparatif

COBIT ITIL
Control Objectives for
Information Technology
Information and Related
Infrastructure Library
Technology
Information Systems Audit
and Control Association Office of Government Commerce
Initiateur (ISACA ) : Association (OGC) : Bureau du commerce
d’Audit et de Contrôle des britannique
Systèmes d’Information
Auditeurs
Utilisateurs IT Managers
Contrôleurs de gestion
Amélioration de la gestion de
l'
ensemble des solutions et autres
Contrôle, métrique et audit
prestations techniques offertes par
des systèmes d’information.
l'
entreprise à ses utilisateurs finaux
Il est conçu pour prendre en
Domaine d’application - qu'ils soient internes ou non. Sans
charge la gestion des risques
oublier celle des infrastructures
liés au domaine
sous-jacentes, c' est-à-dire les
informatique.
réseaux et systèmes (matériel et
logiciel) supportant ces solutions
2 domaines principaux et 11
Domaines & processus 4 domaines et 32 processus
processus

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

5.2.3.2 Analyse de correspondance

Service Support (operational) processes Service Delivery (tactical) processes

SS1: Service Desk (SD) SD1: Service Level Management (SLM)


SS2: Configuration Management (CON) SD2: Availability Management (AM)
SS3: Incident Management (IM) SD3: Capacity Management (CAP)
SS4: Problem Management (PM) SD4: Financial Management (FIN)
SS5: Change Management (CHA) SD5: Service Continuity Management
SS6: Release Management (RM) (SCM)

Planification et Organisation Distribution et support

PO1: Définir un plan informatique DS1: Définir les niveaux de service


stratégique DS2: Gérer les services assurés par des tiers
PO2: Définir l' architecture du système DS3: Gérer la performance et la capacité
d'information DS4: Garantir un service continu
PO3: Déterminer l' orientation technologique DS5: Garantir la sécurité des systèmes
PO4: Définir l' organisation et les relations de DS6: Identifier et répartir les coûts
travail de la fonction informatique DS7: Sensibiliser et former les utilisateurs
PO5: Gérer l' investissement en informatique DS8: Aider et conseiller les clients des
PO6: Communiquer les objectifs et les services informatiques
orientations de la direction DS9: Gérer la configuration
PO7: Gérer les ressources humaines DS10: Gérer les problèmes et les incidents
PO8: Garantir la conformité avec les DS11 Gérer les données
impératifs externes DS12: Gérer les moyens informatiques
PO9: Evaluer les risques DS13: Gérer l'exploitation
PO10: Gérer les projets
PO11: Gérer la qualité

Acquisition et mise en place Surveillance

AM1: Identifier les solutions S1: Contrôler le processus


AM2: Acquérir et maintenir le logiciel S2: Obtenir une garantie d'indépendance
d'application
AM3: Acquérir et maintenir l' architecture
technologique
AM4: Développer et maintenir les
procédures informatiques
AM5: Installer et valider les systèmes
AM6: Gérer les modifications

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

Correspondence entre Processus ITIL & COBIT

ITIL COBIT

Code Processus Code Processus

SS1 Help Desk - -

SS2 Gestion des configurations DS9 Gérer la configuration

SS3 Gestion des incidents


DS10 Gérer les problèmes et les incidents
SS4 Gestion des problèmes

AM6 Gérer les modifications


Acquérir et maintenir le logiciel
SS5 Gestion de changements AM2
d'application
Acquérir et maintenir l'
architecture
AM3
technologique
SS6 Gestion des mises en œuvres AM5 Installer et valider les systèmes
Définir les niveaux de service
DS1
SD1 Gestion des niveaux de service
Gérer les services assurés par des
DS2
tiers
SD2 Gestion de la disponibilité
DS4 Garantir un service continu
SD4 Gestion de la continuité des services

SD3 Gestion des capacités DS3 Gérer les performances et la capacité

SD5 Gestion Financière des services DS6 Identifier et répartir les coûts

Du point de vue de la couverture des domaines de l’activité d’une DSI, il ressort de l’analyse
de correspondance entre les processus des deux standards que le modèle ITIL se retrouve en
grande partie dans les processus COBIT. En effet, à l’exception du domaine de gestion d’un
service Help Desk, tous les autres processus ITIL sont couverts par les processus COBIT.
Cette conclusion s’avère intéressante pour le modèle de tableau de bord IT sur deux plans :

Pour la dérivation des facteurs clés de succès (Première étape de la démarche adoptée
ultérieurement pour la mise en place du Tableau de bord de l’activité IT), on va pouvoir
s’appuyer uniquement sur les processus de la méthode COBIT qui a une couverture plus
large de l’activité informatique que celle de l’ITIL.

De part la « parfaite » couverture de ITIL par COBIT, le « comment-faire » bien décrit et


préconisé dans le standard ITIL pourra être exploité en grande partie.

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

Planning & Organisation Acquire & Implement


Define Strategic Determine Determine Identify Develop & Install &
IT Plan Information Technological Automated Maintain IT Accredit
Architecture Direction Solutions Procedures Systems

Define IT Manage IT Communicate Acquire & Manage Acquire &


Organisation & Investment Aims & Maintain Change Maintain
Relationships Direction Applications Technology
Software Infrastructure

Manage Human Ensure Assess


Resource Compliance Risks
with External
Standards

Manage Manage
Projects Quality

Figure 15 :
Schéma de correspondance entre
ITIL et COBIT
ITIL
Service Support Service Delivery
Service Incident Problem Service Level Availability Capacity
Desk Management Management Management Management Management

Change Release Configuration Financial Continuity


Management Management Management Management Management

Deliver & Support


Monitor
Define & Manage Manage Ensure Ensure
Monitor Assess Manage Third Party Performance & Continuous System
The Internal Control Service Levels Services Capacity Service Security
Process Adequacy
Identify & Manage Educate & Assist & Advise Manage
Allocate Operations Train IT Customers Configuration
Obtain Provide Costs Users
Independent Independent
Assurance Audit
Manage Manage Manage
Problems & Data Facilities
Incidents

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

5.3. Construction du tableau de bord IT

5.3.1. Méthodologie

Il existe plusieurs méthodologies ou approches pour la construction des tableaux de bord. A titre indicatif,
on peut citer :

• La démarche GIMSI
• La démarche BALANCED SCORECARD
• La démarche MEHARI (pour les tableaux de bord de la sécurité informatique)

Néanmoins, quelque soit la méthodologie utilisée, l’élaboration d’un tableau de bord est une démarche qui
consiste à priori à concilier des exigences apparemment contradictoires :

• Retenir peu d’indicateurs, mais tous ceux qui sont essentiels


• Agréger les informations en passant d’un niveau à un autre en favorisant le dialogue entre unités
organisationnelles

Dans le cadre de ce travail, la démarche adoptée pour la construction d’un modèle générique de tableau de
bord de l’activité d’une DSI se compose de 4 étapes essentielles :

• Définition des facteurs clés de succès à partir des processus de la méthode COBIT
• Dérivation des indicateurs de performance par facteur clé de succès
• Formation du tableau de bord
• Alimentation du tableau de bord

5.3.2. Construction

5.3.2.1. Définition des facteurs clés de succès

Dans cette partie, il s’agira de définir à partir des processus COBIT un ensemble de facteurs clés de
réussite pour la mission d’une Direction des Systèmes d’Information. Etant donné que l’un des aspects du
pilotage consiste à connaître sa destination, on peut considérer les facteurs clés de succès comme des
objectifs à atteindre, le tableau de bord étant précisément destiné à faciliter l’orientation vers les buts fixés.
L’examen des processus COBIT fait ressortir les facteurs clés de succès selon le tableau suivant :

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

COBIT Facteurs clés de succès


Alignement
Satisfaction Disponibilité Utilisation des Maîtrise des Ressources
Domaine Processus stratégie IT &
des utilisateurs des ressources ressources risques Humaines
Corporate
PO1: Définir un plan
informatique stratégique
X

PO2: Définir l'


architecture du
système d'
information
X

PO3: Déterminer l'


orientation
technologique
X
PO4: Définir l' organisation et
les relations de travail de la X
Planification et Organisation

fonction informatique
PO5: Gérer l'investissement en
informatique
X
PO6: Communiquer les
objectifs et les orientations de X
la direction
PO7: Gérer les ressources
humaines
X

PO8: Garantir la conformité


avec les impératifs externes
X

PO9: Evaluer les risques X

PO10: Gérer les projets X

PO11: Gérer la qualité X

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

COBIT Facteurs clés de succès


Alignement
Satisfaction Disponibilité Utilisation des Maîtrise des Ressources
Domaine Processus stratégie IT &
des utilisateurs des ressources ressources risques Humaines
Corporate

AM1: Identifier les solutions X

AM2: Acquérir et maintenir le


logiciel d'
application
X

AM3: Acquérir et maintenir


l'
architecture technologique
X

AM4: Développer et maintenir


les procédures informatiques
X

AM5: Installer et valider les


systèmes
X

Acquisition et mise en place


AM6: Gérer les modifications X

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

COBIT Facteurs clés de succès


Alignement
Satisfaction Disponibilité Utilisation des Maîtrise des Ressources
Domaine Processus stratégie IT &
des utilisateurs des ressources ressources risques Humaines
Corporate
DS1: Définir les niveaux de
service
X
DS2: Gérer les services
assurés par des tiers
X
DS3: Gérer la performance et
la capacité
X
DS4: Garantir un service
continu
X
DS5: Garantir la sécurité des
systèmes
X
Distribution et support

DS6: Identifier et répartir les


coûts
X
DS7: Sensibiliser et former les
utilisateurs
X
DS8: Aider et conseiller les
clients des services X
informatiques
DS9: Gérer la configuration X
DS10: Gérer les problèmes et
les incidents
X

DS11 Gérer les données X


DS12: Gérer les moyens
informatiques
X

DS13: Gérer l'


exploitation X

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

5.3.2.2. Croisement des facteurs clés de succès avec les niveaux du tableau de bord IT

Les trois niveaux correspondants aux niveaux de gestion dans une DSI sont :

Niveau stratégique : ce niveau concerne la direction générale et en partie la direction des systèmes
d’information

Niveau tactique :Il correspond au niveau middle management. On y trouve les activités relatives à la
gestion de projets par exemple

Niveau opérationnelle : Ce niveau correspond à l’exploitation et à la gestion quotidienne des activités


d’une DSI.

Le tableau suivant se propose d’offrir un croisement des facteurs clés de succès précédemment définis par
niveau de gestion d’une DSI. Ce croisement ne constitue pas un modèle de référence figé. Il dépend de la
nature de l’activité de l’organisation, du positionnement de la DSI ainsi que du degré de couverture des
activités informatiques par la DSI.

Niveaux de gestion DSI

Facteurs Clés de succès Stratégique Tactique Opérationnel

Alignement stratégie IT & Corporate X

Satisfaction des utilisateurs X

Disponibilité des ressources X

Utilisation des ressources X

Maîtrise des risques X

Ressources Humaines X

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

5.3.2.3. Définition des indicateurs par FCS

« Un indicateur est un instrument de langage particulier. Il constitue un signifiant pour des acteurs
particuliers d’un système les amenant à prendre des décisions d’action. » 16

Les indicateurs de gestion représentent les informations sélectionnées dans un tableau de bord car ils
rendent compte de manière synthétique des performances du système mesuré. Il appartient donc, en
concertation avec les acteurs concernés, de choisir avec soin les informations privilégiées. Par ailleurs, et
du fait que le tableau de bord est un outil personnalisé, il s’agira dans le cadre de ce travail de proposer à
titre d'
exemple une liste « non-exhaustive » d’indicateurs par facteur clé de succès. Il conviendra par la
suite à l’utilisateur de la personnaliser en fonction de ses besoins et de la cohérence global su système.

Néanmoins, l’ensemble de ces indicateurs doit répondre à certains critères, à savoir :

• Clairs et simples
• Significatifs et durables
• Cohérents entre eux

Alignement stratégie IT & Corporate

Facteur clé de Alignement stratégie IT & Corporate


Succès concerné:
Indicateur Formule Commentaires
Dernière mise à Date du jour - Date de Le plan directeur doit être en accord avec la situation
jour du plan la dernière mise à jour réel. Plus il est vieux dans le temps, plus il y a des
directeur du plan directeur chances qu' il ne soit plus réaliste.
Mise en place du Avancement de la L'avancement de la mise en place permet de déterminer
plan directeur mise en place du plan entre autre le moment opportun pour débuter la
directeur (en %) conception d' un nouveau plan.

Maîtrise de risques

Facteur clé de Maîtrise de risques


Succès concerné:
Indicateur Formule Commentaires
Risques des Evaluation du risque L'évaluation des risques d' un projet doit être disponible
projets en cours moyen des projets en en tout temps. La moyenne de ces risques permet de
cours déterminer le niveau général des risques.
Projets très risqués Nb de projet au-dessus Une moyenne tel que l' indicateur différent doit être
d'
un seuil de risque évaluée en tenant compte de l' écart type. Cet indicateur
permet d' obtenir une vision du nombre de projets très
risqués que l'entreprise développe en ce moment. Ils
devraient bénéficiés d' un suivi particulier.
Part des projets Nb de projets terminés Même si beaucoup de projets informatiques ne se
terminés / Nb projets débutés terminent pas, il est important de savoir à quel point une
entreprise est capable de mener à bien ces projets. Si les

16
Daniel Boix. Bernard Féminier. Le tableau de bord facile. Editions d’organisation 2003. page :98.
Hicham HIDDAK Page:
Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

projets en échec sont trop importants, de sérieux efforts


dans le management de projets doivent être réalisés.
Retard Retard moyen des Les projets informatiques se terminent rarement le jour
projets dit, pour le montant prévu avec les spécifications
prévues. Pour des raisons de synchronisations des
différents projets, il est en général important de finir
dans les délais. Cet indicateur nous montre à quel point
l'
entreprise est capable de les respecter.

Satisfaction des utilisateurs

Facteur clé de Satisfaction des utilisateurs


Succès concerné:
Indicateur Formule Commentaires
Défaillances Nb moyen de Ce ratio permet de savoir si les différents éléments du
repérées défaillances repérées système collaborent de manière efficace. Une soudaine
par jour augmentation peut signaler qu' un nouveau produit
installé récemment pose des problèmes; une
augmentation importante du nombre des utilisateurs,
mal supportée; etc.
Satisfaction Nb d' utilisateurs Ce ratio s'obtient sur base d'un questionnaire du type de
moyenne des satisfaits / Nb de celui rendu au premier projet. Il implique la définition
utilisateurs questionnaires d'un seuil limite acceptable. L'indicateur doit pouvoir
retournés donner une la date du dernier sondage, qui doit être fait
régulièrement.
Efficacité Help Incidents résolus / Ce ratio mesure l’efficacité relative à la résolution des
Desk Incidents signalés au incidents signalés au service Help desk. Il implique
Help Desk aussi la définition d’un seuil par niveau de maintenance
(préventive ou curative)

Disponibilité des ressources

Facteur clé de Disponibilité des ressources


Succès concerné:
Indicateur Formule Commentaires
Suivi des Nb heures d' arrêt du Cet indicateur nous permet de connaître la fiabilité de
interruptions de service par mois notre système. Suivant le business concerné, cet
service indicateur est primordial, car il existe des systèmes qui
doivent fonctionner 24h/24. Il est très fortement lié à la
qualité du service mais se distingue de part sa forte
interrelation avec le type de métier de l'entreprise. Il
faut être très attentif car une augmentation peut très vite
impliquer un grand manque à gagner pour l' entreprise.

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

Résistance aux Nb moyen d' attaques Cet indicateur est surtout utile dans une optique
attaques détectées par jour d'évolution temporelle. S’il varie beaucoup il va falloir
faire des contrôles pour vérifier si l'
augmentation vient
d'une nouvelle faille ou au contraire si une diminution
reflète une diminution de l'efficacité de la détection du
système.
Coûts de la Coûts cumulés des Permet de suivre les coûts des attaques et évaluer les
sécurité dégâts occasionnés au mesures à prendre à long terme, grâce notamment à
système cette base de comparaison des coûts.

Utilisation des ressources

Facteur clé de Utilisation des ressources


Succès concerné:
Indicateur Formule Commentaires
Suivi des dépenses Budget dépensé/ Cet indicateur permet de déterminer si les dépenses
(Budget total * suivent bien une progression linéaire vis-à-vis du
Numéro du jour/360) budget prévu. S' il est supérieur à 1, des coûts trop
importants sont enregistrés. Il est important de vérifier
si les coûts de cette entreprise suivent véritablement une
progression linéaire.
Durée de vie des Age moyen du parc Plus le parc informatique peut être considéré comme
investissements informatique ancien, plus il est important de renouveler une partie du
matériel afin d' assurer notamment le confort des
utilisateurs. Il est un indicateur financier car il faut
trouver un bon équilibre entre l' investissement en
nouveau matériel et les besoins.

Ressources humaines

Facteur clé de Ressources humaines


Succès concerné:
Indicateur Formule Commentaires
Taux de rotation Nb de départ / Nb Plus ce ratio est élevé, plus le personnel a tendance à
du personnel d'
employés quitter l'
entreprise et moins la pérennité des systèmes et
la transmission des connaissances peut être assurée.
Taux de personnel Nb d'
employés en IT / Afin d' assurer un service de maintenance et d' aide aux
en IT Nb d'
employés utilisateurs correct, un certain pourcentage du personnel
doit être affilié à l'IT. La valeur cible de cet indicateur
est influencée par :
Niveau d' outsourcing
Choix de développement de solutions
personnels ou d' achat de package
Type d' entreprise
Budget de
formation IT

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

Pour chaque indicateur il est encore nécessaire de :

o Déterminer son seuil normal ou idéal et déterminer les différents seuils d'
alertes
o Choisir les données détaillées qui doivent être accessibles
o Etudier les dépendances avec d' autres indicateurs afin de prévoir les réactions qu'
un
événement peut engendrer sur plusieurs indicateurs.

L’ensemble de ces points sera traité dans le dictionnaire des indicateurs de la partie normalisation des
données [5.3.3.1.2.1].

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

5.3.3. Architecture logicielle et prototypage

Dans cette partie, il s’agira de décrire et de justifier le choix de l’architecture logicielle adoptée pour
l’implémentation technique de notre système informatique de tableau de bord de l’activité IT. Par la suite,
et pour la modélisation du système informatique, nous allons utiliser le langage de modélisation UML. En
effet, l’un des avantages majeurs de ce langage réside dans la prise en considération de l’ingénierie des
besoins. L’objectif de la capture des besoins ou exigences consiste à déterminer ce que le système
informatique doit faire, c' est-à-dire le Quoi, afin de favoriser une meilleure compréhension des
fonctionnalités du système lors du développement.

5.3.3.1. Architecture logicielle

L’architecture logicielle du système informatique du tableau de bord de l’activité IT se compose de trois


niveaux distincts :
• Niveau acquisition
• Niveau normalisation et stockage
• Niveau exploitation ou visualisation

Bases de
données

ERP
Outils
Interface
Outils Fichier d’extraction,
logicielle du
d’extraction, XML de filtrage
tableau de
de filtrage normalisé
bord
IT
BD
Externes

Dictionnaire des
indicateurs
Internet

Acquisition des données Stockage Exploitation des données


des données

Figure 16 : Architecture logicielle du Tableau de bord IT

Dans le cadre de ce travail, seuls les niveaux normalisation et exploitation des données seront développés,
étant donné l’existence d’outils d’extraction pour le niveau acquisition.

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

5.3.3.1.1. Niveau acquisition

Il s’agit à ce niveau d’extraire les données nécessaires des différents systèmes : ERP, Systèmes de
production, WEB, etc. Le problème qui se pose à ce niveau est d’ordre technique. En effet, pour pallier au
problème d’hétérogènité des données, il existe des outils dits ETL (Extraction Transformation Loading).
Ces outils prennent en charge la collecte et le nettoyage des données issues de bases de données
hétérogènes et des ERP les plus courants. L’utilisateur modélise le schéma d’extraction pour les
différentes sources et précise toutes les opérations d’agrégation et de contrôle de valeurs avant de délivrer
les données.

5.3.3.1.2. Niveau normalisation

Comme le montre la figure 16, ce niveau vient s’intercaler entre le niveau acquisition et le niveau
visualisation. Ce niveau représente la référence qui garantie la cohérence des données et le glossaire
général. En effet, on y trouve les informations qui ont été extraites dans le premier niveau, mais qui ont été
stockées en fonction des facteurs clés de succès, des indicateurs du tableau de bord et d’un langage
commun à la DSI. Les sources de données étant le plus souvent hétérogènes, se posent alors deux
problèmes :

• Contrainte technique : Compatibilité des systèmes opérationnels (Sources de données) avec la


solution choisie pour l’implémentation du tableau de bord
• Contrainte logique : Standardisation et normalisation des concepts

La résolution de ces deux contraintes passe par deux étapes :

• Définition d’un dictionnaire commun de concepts pour les indicateurs : Ontologie


• Expression des données selon la logique définie dans le dictionnaire avec un langage de
description de contenu : XML

Pour illustrer ces deux solutions, nous allons prendre comme exemple le facteur clés de succès Maîtrise de
risques avec quelques indicateurs correspondants, notamment le pourcentage de projets en retard ainsi que
le pourcentage de dépassement du budget des projets.

5.3.3.1.2.1 Définition d’une ontologie

Une ontologie est constituée d’un ensemble structuré de termes que l’on nomme descripteurs. Elle a pour
vocation de décrire un domaine particulier à l’aide d’un vocabulaire défini, appelé vocabulaire contrôlé de
termes. Ces termes peuvent être reliés entre eux par des relations sémantiques. D’un point de vue
technologique, une Ontologie peut être perçue comme une base de données de concepts.

En ce qui concerne l’application Tableau de bord IT, il s’agira de décrire l’ensemble des concepts et des
termes qui définissent les données à utiliser. C’est ce qu’on appelle un glossaire d’indicateurs. Ce dernier
mentionne pour chacun des indicateurs, la périodicité, le mode de calcul (données et formules), les sources,
les destinataires ainsi que la signification. Grâce à l’adoption d’une terminologie unique, tous les acteurs
disposent des mêmes chiffres et une meilleure cohérence est garantie. Exemple : « Pour une station de
travail, le Total Cost of Ownership (TCO) n’est pas le coût d’acquisition. »

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

Par ailleurs, cette normalisation devra être accompagnée par la mise en place d’un guide de procédures
précisant le mode d’exploitation de l’outil Tableau de bord IT : périodicité de calcul des indicateurs, de
leur diffusion ainsi que les responsabilités y afférentes.

Les indicateurs retenus pour l’appréciation du facteur clé de succès « Maîtrise des risques » sont :

• Projets en retard
• Dépassement budget projets

Pour chaque indicateur, il s’agira de rédiger une fiche décrivant clairement :

• Sa définition
• Ses termes de mesures : les paramètres nécessaires à son calcul
• Ses modalités d’interprétation
• Son éventuelle relation avec d’autres indicateurs

Fiche indicateur 1 :
Nom de l’indicateur : Projets en retard
Nom abrégé : PRJ_RTD
Objectif : 0%
Base de calcul : Nombre cumulé depuis le 01 janvier de l’année en cours des projets dont :
- La date de début est nulle et la date système est supérieure à la date prévisionnelle de
début.
- La date de fin est nulle et la date système est supérieure à la date prévisionnelle de
fin.
Formule de calcul : Nombre de projets en retard / Nombre de projets
Unité : Pourcentage
Tolérance / objectif :5%
Périodicité : mensuelle
Date mise à disposition : le 2 du premier mois pour le mois précédent
Précision du vocabulaire : Tout projet n’ayant pas encore commencé et devant l’être, ou n’étant pas encore fini et
devant l’être, est considéré comme un projet en retard.

Fiche indicateur 2 :
Nom de l’indicateur : Dépassement du budget des projets
Nom abrégé : PRJ_BDG
Objectif : 0%
Base de calcul : Dépenses cumulées des projets depuis le démarrage des projets en cours
Formule de calcul : Dépenses cumulées réelles / Budgets projets
Unité : Pourcentage
Tolérance / objectif :5%
Périodicité : une fois par quinzaine
Date mise à disposition : le 1er jour ouvrable après le 1 et le 15 de chaque mois.
Précision du vocabulaire : Tout projet dont les dépenses imputées dépassent le budget est considéré comme projet à
budget dépassé.

5.3.3.1.2.2 Description des données en XML

Depuis peu, XML est apparu comme le standard incontournable pour l’échange de données sur le réseau.
Cependant, les éditeurs de systèmes de gestion de bases de données ont montré un grand intérêt à ce
Hicham HIDDAK Page:
Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

nouveau format. En effet, c’est au début de l’année 1999 que le XML commence à apparaître au sein des
notices techniques de certaines solutions d’entreprises. On passait alors de son usage dans la gestion du
contenu des sites Web essentiellement et dans les échanges B to B, à celui du stockage et du classement
des données afin d’en faciliter la gestion depuis des applications tierces.

XML permet de structurer un document et ainsi de gérer son contenu. Il en résulte une suite d’éléments
parfaitement identifiables qu’on peut qualifier de données « stockables et manipulables ». Les ouvertures
offertes par cette proximité structurelle du XML et des bases de données sont multiples :

• Utilisation du XML comme bases de données


• Extraction des données d’une base afin de les intégrer dans une structure XML et, à partir de là,
les transformer à volonté
• Récupération dans une base de données du contenu d’un document XML
• Utilisation des structures XML pour interfacer des bases de données hétérogènes

Pour illustrer la mécanique de calcul des indicateurs précédemment choisis, nous allons commencer par
une brève description du schéma relationnel dans lequel sont stockées les données nécessaires à ce calcul.
Par la suite, nous essayerons de monter le mécanisme d’homogénéisation et d’extraction selon les règles
et le langage définis dans notre ontologie d’indicateurs.

Schéma relationnel :

Le calcul de l’indicateur « Projet en retard » fait appel aux informations suivantes :

• Dates prévisionnelles début et fin de projets


• Dates début et fin de projets

Le calcul de l’indicateur « Dépassement du budget projets » fait appel aux informations suivantes :

• Budget par projet


• Dépenses par projet

Nous supposons pour ce qui suit que les informations relatives aux dates et aux budgets sont gérées par
une application de gestion de projets sous Windows (ACCESS par exemple), alors que les informations
relatives aux dépenses réelles sont dans un module comptabilité analytique d’un ERP sous UNIX (SAP
R/3 pour DB2 par exemple)

Données Projets

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

Données Dépenses

Transformation en données XML :

Données Projets

!" #
- $ %
&'() % *
&' () %
)$ % ! * )$ %
+ , *+ ,
-. *-.
( ) ,) " # *( ) ,)
( )/ ) " # *
( )/ )
*$ %
- $ %
&'() % *
&' () %
)$ % $%& * )$ %
+ , *+ ,
-. *-.
( ) ,) ' # *( ) ,)
( )/ ) " ( # *
( )/ )
*$ %
- $ %
&'() % *
&' () %
)$ % ) **) * )$ %
+ , *+ ,
-. *-.
( ) ,) +# *( ) ,)
( )/ ) ' +# *
( )/ )
( ) ,. # *
( ) ,.
*$ %
- $ %
&'() % " *&' () %
)$ % * )$ %
+ , *+ ,
-. + *-.
( ) ,) " # *( ) ,)
( )/ ) " , # *
( )/ )
*$ %
*
Hicham HIDDAK Page:
Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

Données Dépenses

!" #
-
&'() " +' *&'
()
0 ) , +"( , *0 ) ,
0 ),. +, +(- * 0 ),.
) 1 2. . +/ * ) 1 2.
&'() % *&'
() %
3 + *3
*
-
&'() " , * &'
()
0 ) , +''"+(' *0 ) ,
0 ),. +, +(- * 0 ),.
) 1 2. $ -0( * ) 1 2.
&'() % *&'
() %
3 ,+ *3
*
-
&'() " , *&'()
0 ) , +(-," + * 0 ) ,
0 ),. +, +(- * 0 ),.
) 1 2. #+ ' * ) 1 2.
&'() % *&'
() %
3 -+ *3
*
-
&'() " , * &'
()
0 ) , , -(' * 0 ) ,
0 ),. +, +(- * 0 ),.
) 1 2. " +! - * ) 1 2.
&'() % *&'
() %
3 *3
*
-
&'() " , *&'
()
0 ) , +" , +- * 0 ) ,
0 ),. +, +(- *0 ),.
) 1 2. , +. * ) 1 2.
&'() % *&'
() %
3 *3
*
*

Extraction des données nécessaires :

Pour l’extraction des données contenues dans le ou les documents XML (pour le calcul des indicateurs),
nous utiliserons le standard XQuery. C’est un langage de requête évolué qui se base sur la norme XPath
pour extraire et travailler sur des fragments de documents XML à l’aide d’une bibliothèque de fonctions
standard. Un des avantages de XQuery est de pouvoir faire des requêtes sur plusieurs documents à la fois
contrairement à XPath. XQuery peut être comparé à SQL dans la mesure où une requête SQL sur
plusieurs tables génère une table, de même qu’une requête XQuery sur du XML donne du XML. Par
ailleurs, il existe plusieurs différences :

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

• Existence de plusieurs versions SQL (Oracle, MySql, DB2, SQL Server,…) alors que la norme
XPath sur laquelle se base XQuery est unique et garantie par le W3C.
• Contrairement à d’autres langages de requête de documents XML (notamment XQL ou XSQL
dont la syntaxe est un mélange de langage SQL et celui de XML), la syntaxe de XQuery est très
différente de celle de SQL. En effet, la nature hiérarchique de XML aboutit à des expressions XQuery
semblables à la manière de naviguer au sein d’un système de fichiers.

A titre de comparaison, nous donnons pour le nombre de projets en retard la requête correspondante dans
le modèle relationnel :

Requête SQL - modèle relationnel Requête XQuery


nombre de Select count(*) from projets For $projets In // projets
projets en Where (date_debut is null Where [ $projets [@date_debut_prev<sysdate]
retard And And $projets [@date_debut= ""]]
Sysdate>date_debut_prev) Or [$projets[@date_fin_prev<sysdate]
Or (date_fin is null And $projets [@date_fin= ""]]
And
Sysdate>date_fin_prev) Return $projets

5.3.3.2. Prototypage

Afin de valider les choix précédemment opérés, nous allons essayer dans cette partie d’élaborer un
prototype de l’application tableau de bord IT. Il s’agira de monter une réalisation simplifiée qui sera
complète pour la partie interface graphique pour utilisateur, et partielle pour ce qui est gestion et
traitement de données. Ce prototype sera la concrétisation technique qui aura pour objet de mettre en
œuvre le dispositif tableau de bord IT afin de vérifier la faisabilité et l’utilité des informations produites.

L’application informatique du tableau de bord IT se doit de fournir au management d’une DSI à tous les
niveaux, une visibilité sur l’ensemble de son activité dans les meilleurs délais afin d’assurer le pilotage
complet de son portefeuille de projets et de ressources, et d’aligner ses moyens avec ses objectifs. Cette
application sera utilisable par tout acteur enregistré, et cela, selon les droits d’accès qui lui ont été attribués
par la hiérarchie.

5.3.3.2.1. Objectifs

L’objectif principal de l’application est de permettre la visualisation des indicateurs précédemment


configurés en fonction des profils d’accès. Pour cela, elle devra être fiable, étant donné que son domaine
d’application concerne la prise décisionnelle à tous les niveaux d’une DSI. Son utilisation quotidienne et
éventuellement intensive ne devra pas laisser place à d’éventuels points faibles.
5.3.3.2.2. Besoins

Analysons à présent, les besoins auxquels doit répondre l’application. Les besoins non fonctionnels
correspondent à la manipulation de l’application et précisément son environnement. Les besoins
fonctionnels listent les opérations réalisables par l’application.

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

5.3.3.2.2.1 Besoins non fonctionnels

Interface utilisateur ;

L’application devra être cohérente au point de vue de l’ergonomie. Un fichier d’aide à l’utilisation
présentant l’interface et les fonctionnalités sera disponible. La modélisation des besoins en matière
d’interface utilisateur sera abordée en détail dans la partie [5.3.3.2.3]

Environnement réseau ;

L’application fonctionnera en mode client/serveur.

Développement ;

Environnement de développement : DELPHI 3 for Windows


Environnement d’exécution : Poste client sous Windows 9X/ NT/2000/ XP
La partie base de données de l’application s’appuie sur le SGBD d’Oracle 8. (A noter que tout SGBD
supportant XML pourra héberger la base de données)

5.3.3.2.2.2 Besoins fonctionnels

L’application doit permettre :

• L’accès rapide au tableau des indicateurs en fonction de la configuration faite par profil
• L’édition (suite à la demande de l’utilisateur) d’une page A4 résumant l’ensemble de ces
indicateurs
• La configuration des niveaux d’accès en fonction des profils
• La configuration de la liste des indicateurs à afficher par facteur clé de succès
• L’accès au menu de chaque acteur en fonction de son profil
• Le chargement des données de la base de données

5.3.3.2.3. Use Cases

Grâce aux cas d’utilisation (Use Cases), UML fournit un moyen pour capturer les besoins. Un cas
d’utilisation représente une formalisation très riche des besoins. Il sert de contrat de développement pour
toutes les parties prenantes du développement. Par ailleurs, il est représenté par des acteurs et des figures
d’utilisation. Chaque cas doit être décrit dans le détail pour montrer les interactions entre le système, les
acteurs et les actions internes.

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

Identification

Menu Administrateur

Menu visualisation tout utilisateur

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

Diagramme des états-transitions Administrateur

Diagramme des états-transitions utilisateurs autres que l’administrateur

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

5.3.3.2.4. Ecrans de l’application

Ecran1:

Figure 17 : Menu Identification

Au lancement de l’application, l’écran d’application objet de la figure 17 s’affiche. Cette fenêtre invite
l’utilisateur à saisir le nom d’utilisateur et le mot de passe fournis par l’administrateur de l’application. En
cas de validation positive de ces deux paramètres, le système charge et affiche le menu correspondant à
cette identification. [Voir diagrammes états-transitions ci-dessus]

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

Ecran2:

Figure 18 : Menu Administrateur

Cet écran correspond au menu de l’administrateur de l’application. Grâce à ce menu, il peut :


• Configurer les niveaux d’accès par profil d’utilisateur
• Configurer la liste d’indicateur à afficher par facteur clé de succès
• Charger les données contenues dans le ou les fichiers XML
• Visualiser le tableau de bord

A noter que pour les autres profils d’utilisateurs, ils accèdent après identification directement à la fenêtre
de visualisation du tableau de bord. [Voir diagrammes états-transitions ci-dessus]

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

Ecran3:

Figure 19 : Configuration de niveaux d’accès

Cette fenêtre accessible uniquement à l’administrateur de l’application permet la configuration des


facteurs-clés de succès visibles par profil d’utilisateur [Administrateur- D.G- D.S.I- IT Manager –
Opérationnel]

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

Ecran4:

Figure 20 : Menu configuration des FCS

Cette fenêtre, accessible uniquement à l’administrateur de l’application, permet de choisir les facteurs clés
de succès à configurer.

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

Ecran5:

Figure 21 : Menu configuration des indicateurs

Cette fenêtre accessible uniquement à l’administrateur de l’application permet d’une part de choisir les
indicateurs à afficher par facteur clé de succès (a noter qu’il existe une contrainte programmée qui limite
le choix à moins de quatre indicateurs par facteur-clé de succès). D’autre part, elle permet de fixer pour
chaque indicateur une « valeur objectif » et un seuil de tolérance au-delà duquel une alerte sera donnée.

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

Ecran6:

Figure 22 : Menu chargement des données

Cette fenêtre s’affiche lors du chargement des données et montre l’état d’avancement de cette opération.

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

Ecran7:

Figure 23 : Menu configuration des FCS

C’est la fenêtre principale de l’application. Elle permet la visualisation des indicateurs du tableau de bord.
En fonction des configurations faites au niveau des fenêtres objets des figures 19 & 21, cette visualisation
sera différente d’un profil à un autre. Toutefois, pour chaque indicateur, on aura la valeur constatée, ainsi
que le type d’alerte qui est déterminée en fonction des seuils précédemment fixés.

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

6. Conclusion
En ces temps de restrictions budgétaires, la DSI est tout particulièrement visée. Selon le Gartner Group,
69% des entreprises auraient revu à la baisse leurs investissements informatiques de 7 à 8% en moyenne
en 2002. Plusieurs projets relatifs aux systèmes d’information sont mis en « Stand by » en attendant un
climat économique plus favorable. Et quand de nos jours le Top Management convoque la DSI, ce n’est
plus pour évoquer les nouvelles technologies mais pour parler « retour sur investissement », car la DSI est
toujours montrée du doigt comme un centre de coûts. Dans ce contexte, se comporter en SSII interne,
donc facturer et promouvoir son savoir-faire, peut être la solution.

En effet, grâce à la maîtrise de coûts unitaires de ses services et prestations, la DSI peut notamment par
rationalisation réduire facilement ces derniers. Cet objectif passe principalement par la mise en place d’un
système de contrôle de gestion informatique. Dans une telle démarche, la première étape consisterait à
formaliser et à structurer les prestations de la DSI sous forme de catalogue de services avec une
tarification associée. Dans cette étape, il s’agit d’impliquer dès le départ les unités organisationnelles
opérationnelles. Par ailleurs, il est indispensable que les unités de facturation soient les plus
compréhensibles possible pour les utilisateurs. La deuxième étape consiste à définir des contrats de
services (SLA :Service Level Agreement ) qui sont censés clarifier les responsabilités vis-à-vis des unités
utilisatrices, à qui reviennent les décisions de déterminer la quantité et la qualité des services dont elles ont
besoin et d’en assumer les coûts.

De l’autre côté, se convertir en SSII interne, c’est aussi accepter le risque d’être comparé avec les SSII
externes. D’où la nécessité de mise en place d’un système de pilotage et d’indicateurs de mesure de
compétitivité et de performance, en faisant des benchmarks pour se comparer au marché et en menant des
enquêtes de satisfaction auprès des utilisateurs. Cependant, un système de tableau de bord ne doit pas se
limiter au simple fait de constater. Il doit être un outil de gestion orienté prise de décision donnant aux
acteurs concernés la possibilité non seulement de mesurer leur activité : « le combien ? »,mais aussi
d’anticiper : « le quoi faire ? ».

Dans ce cadre, nous avons proposé un système de tableau de bord pour l’activité d’une DSI basé sur la
méthode COBIT et le standard l’ITIL. L’objectif escompté à travers cette combinaison est d’offrir un outil
capable de répondre justement aux deux questions : « le combien ? » grâce à la grande capacité de
métrique de COBIT et « le quoi faire ? », grâce aux meilleures pratiques ITIL relatives aux différents
processus de gestion de l’IT. Or, l’analyse de correspondance entre les processus des deux standards a
montré que la couverture n’est pas optimale. Autrement dit, il existe principalement des processus de
COBIT non couverts par ceux de l’ITIL, par exemple ceux relatifs à la gestion de projet, à la gestion de la
qualité, l’évaluation des risques en matière de sécurité informatique, ou encore à la gestion des ressources
humaines. Afin d’optimiser cette couverture, les perspectives en matière de perfectionnement de notre
modèle de gouvernance IT sont intéressantes. On peut notamment faire appel à d’autres standards :

Pour la gestion des projets :


Projects in Controlled Environments (initialement PRINCE et maintenant PRINCE2).
Ce standard est une méthode de gestion de projet couvrant l' organisation, la gestion et le contrôle des
projets. Le PRINCE a été développé la première fois par la « Central Computer and Telecommunications
Hicham HIDDAK Page:
Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

Agency » (CCTA), qui dépend maintenant du bureau du commerce de gouvernement (OGC), en 1989
comme norme BRITANNIQUE de gouvernement pour la gestion des projets IT.

Pour la gestion de la sécurité :


ISO 17799 -- The International Organization for Standardization's ISO 17799 : "Information Technology -
Code of Practice for Information Security Management,". Ce standard est basé sur la norme britannique
BS7799. Son objectif est de se concentrer sur la sécurité et de faciliter une organisation dans la création
d'un efficace plan de sécurité IT.

Pour la gestion de la qualité :


La famille des standards ISO 9000 concerne la “gestion de la qualité”. Cela est défini par tout ce qu’une
entreprise doit mettre en œuvre pour améliorer la satisfaction de ses clients, dans le but d’atteindre et de
dépasser le niveau de satisfaction attendu par le client et par les règlements législatifs, tout en améliorant
en permanence ses propres performances afin d’atteindre ce but. Par analogie, le standard ISO 9000 peut
recouvrir tous les processus d’une DSI, en définissant les règles de création et de gestion de la
documentation, et l’amélioration permanente des processus.

PRINCE

ISO 17799

COBIT
ITIL

ISO9000

Figure 24 : Système de Gouvernance IT

A ce niveau, le problème n’est pas seulement de se demander « est-ce qu’on implémente le standard X ou
non ? » mais aussi : « Comment implémenter le standard X ? ». A noter que pour chaque standard
susceptible de couvrir un des domaines de COBIT, il faudra d’une part étudier la faisabilité technique de
son intégration au sein du modèle, et d’autre part apprécier le degré d’adaptabilité nécessaire pour qu’il se
combine sans trop de difficultés.

Par ailleurs, le contexte d’aujourd’hui caractérisé par la complexité, l’incertitude et la rapidité du


changement ne favorise pas une prise décisionnelle aisée. Le tableau de bord IT idéal devra proposer des
éléments facilitant l’interprétation des informations afin de mieux évaluer les choix possibles. Dans ce
cadre, l’une des perspectives en matière d’amélioration de cet outil consiste à le combiner avec les
techniques d’intelligence artificielle (logique floue par exemple). Grâce à une telle association, le système
pourra suggérer des pistes de recherche et d’analyse en se fondant, soit sur la connaissance d’une expertise,

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

soit sur des expériences passées. Dans notre cas, la connaissance d’expert peut correspondre à la
modélisation des meilleures pratiques préconisées par les standards utilisés (ITIL par exemple) en des
règles « IF… THEN … ELSE ». Les expériences passées quant à elles peuvent correspondre à l’historique
des valeurs des différents indicateurs. Grâce à la combinaison de ces informations, le système pourra
suggérer des analyses complémentaires permettant ainsi une meilleure prise décisionnelle.

Une autre perspective d’amélioration concerne le lien entre le tableau de bord IT et le système de contrôle
de gestion informatique pour une meilleure intégration. L’objectif étant entre autre l’optimisation et la
rationalisation de l’utilisation des ressources, l’idée dans cette perspective est de pouvoir évaluer les
répercussions en terme de coûts et de gains dans le système de contrôle de gestion informatique, des
différentes variations constatées au niveau du tableau de bord IT. Cette intégration passe par la définition
de ce qu’on appelle des unités d’œuvre pour les différents indicateurs du tableau de bord. Les valeurs de
ces unités d’œuvre sont à puiser dans les contrats de services –Service Level Agreements– qui définissent
les niveaux de qualité ainsi que les prix correspondant. Ainsi, ces unités d’œuvre joueront le rôle de
traducteur du langage tableau de bord IT (valeurs indicateurs) au langage système de contrôle de gestion
informatique (valeurs économiques : coûts et gains).

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

Figures

Figure 1 : Les objets de contrôle des systèmes d’information


Figure 2 : Les effets de des technologies d’information (adapté de Mooney et Al)
Figure 3 : Modèle générique de la fonction IT
Figure 4 : The ITIL Service Management Schema
Figure 5 : Optimisation des Processus ITIL
Figure 6 : Les Activités de l’IT Financial Management
Figure 7 : Modèle ABC
Figure 8 : Modèle AMI
Figure 9 : Système de contrôle de gestion informatique
Figure 10-1 : Mission stratégique
Figure 10-2 : Prise de conscience
Figure 10-3 : Métrique et contrôle
Figure 10-4 : Best Way ?
Figure 11 : Schéma conceptuel du système d’IT Gouvernance
Figure 12 : COBIT Internal Control Framework
Figure 13 : Objectifs IT
Figure 14 : Positionnement des standards IT
Figure 15 : Schéma de correspondance entre ITIL et COBIT
Figure 16 : Architecture logicielle du Tableau de bord IT
Figure 17 : Menu Identification
Figure 18 : Menu Administrateur
Figure 19 : Configuration de niveaux d’accès
Figure 20 : Menu configuration des FCS
Figure 21 : Menu configuration des indicateurs
Figure 22 : Menu chargement des données
Figure 23 : Menu configuration des FCS
Figure 24 : Système de Gouvernance IT

Hicham HIDDAK Page:


Du contrôle de gestion informatique à l’IT Gouvernance
HEC Lausanne- MBI 2003

Références Bibliographiques

Livres
[1] Alain Fernandez. Les nouveaux tableaux de bord des décideurs. Editions d’organisation 2001
[2] Caroline Selmer. Concevoir le tableau de bord. Editions Dunod 2003.
[3] Chantal Morley. Jean Hugues. Bernard Leblanc. UML pour l’analyse d’un système d’information.
Editions Dunod 2000.
[4] Daniel Boix. Bernard Féminier. Le tableau de bord facile. Editions d’organisation 2003
[5] Delone W. McLean E. « Information Systems Succes : The quest for the dependant variable »,
Information Systems Research 1995.
[6] Gérard Balantzian. Les systèmes d’information : Art et pratiques. Editions d’organisation 2002.
[7] Henri Bouquin. Comptabilité de gestion. Sirey 1993.
[8] Henri Savall, Véronique Zardet. Le nouveau contrôle de gestion. Editions comptables
Malesherbes - Eyrolles.
[9] Henry Mintzberg. Structure et dynamique des organisations. Editions d’organisation 13ème
édition 2003.
[10] Kaplan, Robert S. et Norton, David P, Le tableau de bord prospectif, Editions d’organisation,
1996.
[11] Lionel Collins, Gérard Valin. Audit et contrôle interne : Aspects financiers, opérationnels et
stratégiques. Editions Dalloz 1992
[12] Michel Leroy. Le tableau de bord au service de l’entreprise. Editions d’organisation 2001.
[13] Nasser Kettani. Dominique Mignet. Pascal Paré. Camille Rosenthal-Sabroux. De Merise à UML.
Editions Eyrolles2000.
[14] Robert N. Anthony, Vijay Govindarajan. Management Control Systems. McGraw Hill-Ninth
Edition 1998.
[15] Robert Reix. Systèmes d’information et management des organisations. Quatrième édition
Vuibert.
[16] Robert S. Kaplan, David P. Norton. Le tableau de bord prospectif. Editions d’organisation 2001.
[17] Serge Abitboul. Peter Buneman. Dan Suciu. Data on the Web: From relations to semistructured
Data and XML. Morgan Kaufmann Publishers 2000.

Articles
[1] Magazine « CIO Stratégie & Technologie » N° 4 –Mars 2003
[2] Magazine « CIO Stratégie & Technologie » N° 5 –Septembre 2003

Sites Web
[1] WWW.GARTNER.COM : Gartner Group
[2] WWW.ITIL.COM : Site officiel de l’ITIL
[3] WWW.ITSMF.COM : IT Service Management Forum
[4] WWW.BSCOL.COM : Site Officiel du Balanced Scorecard
[5] WWW.ISACA.ORG : Information Systems Audit and Control Association
[6] WWW.NODESWAY.COM : Construire les tableaux de bord de l'
entreprise
[7] WWW.BORLAND.COM : Editeur du logiciel DELPHI
[8] WWW.ORACLE.COM : Editeur du SGBD Oracle.
[9] WWW.XML.ORG : Site officiel de l’XML
[10] WWW.ONTOLOGY.ORG : Ontology Online
Hicham HIDDAK Page:
Du contrôle de gestion informatique à l’IT Gouvernance