Audit SI

1-Audit : Definition et origines
Un audit est un processus permanent ou

ponctuel, par lequel une fonction de
l’entreprise est évaluée par une ou plusieurs
personnes qui n’exercent pas cette fonction
dans l’entreprise
Audit : Définition et origines
Une entreprise souhaite un audit d’une de ses

fonctions parce que ses responsables y
perçoivent un dysfonctionnement ou des
possibilités d’amélioration, ou bien veulent
comprendre la « vraie » réalité de cette
fonction, c'est-à-dire au-delà de ce qui en est
dit ou de ce qu'elle paraît être.
1
Audit et Sécurité des Systèmes d’Informations
Cadre général de l’audit
Un audit :
Un passage en revu critique
Un entretien qui doit aboutir à une évaluation, une
appréciation.
La démarche est la même : approche par les risques.
4 objectifs permanents :
Efficacité : capacité à attendre les objectifs. Politique

de DG respectée ou non ?
Efficience : Ressources nécessaires de mise en œuvre des

politiques consommées sans gaspillage ??
Economie : les ressources pour mise en œuvre des

politiques de la DG : obtenues au moindre coût ?
Sécurité : les ressources pour mise en œuvre des

politiques de la DG sont elles préservées.
2
Les demandeurs d'un audit de l'activité informatique
La Direction de l'entreprise
Pour vérifier le respect des orientations qu‘elle a définis
Le responsable informatique
l'opinion motivée de spécialistes sur sa propre organisation
Les contrôleurs externes

S’intéressent à la qualité de l'environnement informatique
Les principales questions posées par les décideurs :
Les questions posées aux auditeurs informatiques sont

très variées
Elles peuvent porter :

– Le rôle de l’informatique
– La politique informatique
– Les structures informatiques
– Les applications
– Les moyens mis en œuvre
– Les hommes
– ...
3
Selon quelle démarche et avec quels outils ?
Pour auditer, il faut :
Un besoin clairement exprimé

Un périmètre bien défini
Une méthode formelle
Des outils
Des moyens et des compétences
...
Les méthodes :
Les méthodes globales

Cobit
Mehari
EBIOS
Marion
Melisa
...
Les méthodes « propriétaires"

Sans méthode formelle
4
Les principales méthodes d'audit de sécurité
Nom Signification Origine Caractéristiques
Méthode accessible à tous,

dans un langage simple.
Les outils fournis
Control permettent la mesure des
objectives for
Cobit
information and
ISACA performances mais la
technology méthode est aujourd'hui
davantage assimilée à une
méthode de gouvernance
des SI.

Notamment déployée au
sein de l'administration
française, cette méthode
Expression des comprend une base de
Besoins et connaissances et un
Ebios Identification des DCSSI recueil de bonnes
Objectifs de pratiques. Elle est
Sécurité téléchargeable sur le site
de la DCSSI et
s'accompagne d'un
logiciel.
5
Pas une méthode à
proprement parler mais
un document permettant
Fiche
à une autorité donnée
d'Expression
(secteur secret défense
Feros Rationnelle des SCSSI
notamment) de définir le
Objectifs de
niveau d'engagement de
Sécurité
sa responsabilité dans
l'application d'une
politique de sécurité.

Fonctionne par
questionnaires
débouchant sur 27
Méthodologie indicateurs répartis en 6
d'Analyse de Risques catégories. 2 phases
Marion Informatiques CLUSIF (audit des vulnérabilités
Orientée par et analyse des risques)
Niveaux permettent la définition
et la mise en oeuvre de
plans d'actions
personnalisés.
6
Succède à la
méthode Marion.
S'articule autour de
Méthode 3 plans. Permet
Harmonisée désormais
Mehari CLUSIF
d'Analyse de d'apprécier les
Risques risques au regard
des objectifs
"business" de
l'entreprise.
Les méthodes : Globales /Propriétaires
Les méthodes globales:

– Pourquoi une méthode ?
Être efficace
Être crédible
Se comparer
...
– Oui, mais …
C'est trop lourd !
C'est pas adapté !
C'est théorique
…
Les méthodes propriétaires

– Objectif :
personnaliser et simplifier ...
7
Introduction
• Introduction à l'audit des systèmes d'information:
– L'audit d'un environnement informatique peut concerner l'évaluation des

risques informatiques de la sécurité physique, de la sécurité logique, de la
gestion des changements, du plan de secours, etc. Ou bien un ensemble de
processus informatiques - ce qui est généralement le cas - pour répondre à une
demande précise du client.
– Par exemple, apprécier la disponibilité des informations et des systèmes. Le

CobiT permet justement de rechercher quels processus informatiques
répondent le plus efficacement à une telle demande. Dans le cas de la
disponibilité : par exemple la sécurité physique et le plan de continuité.
Introduction
Approche générale :
– Un audit informatique (audit des systèmes d'information), se fait selon

un schéma en 4 phases :
• - Définition précise du plan de travail, récolte d'information, recherche et

schématisation des processus métiers et/ou informatiques à apprécier,
définition des rôles et responsabilités, analyse forces - faiblesses
- Analyse des processus importants, définition des risques, évaluation
préliminaire des risques, de l'efficacité des contrôles
- Tests des contrôles
- Tests de matérialité.
8
Introduction
– Un audit informatique (audit des systèmes d'information) ne concerne

pas nécessairement la sécurité. En effet, il peut aussi évaluer des
aspects stratégiques ou de qualité des systèmes d'information.
– Par exemple, répondre à la question suivante : Est-ce que les
systèmes d'information de l'entreprise répondent efficacement aux
besoins des services métiers ?
– Alignement métiers : quel concept déjà ?
– La démarche est très similaire, en choisissant et évaluant les

processus informatiques proposés par le CobiT qui répondent le mieux
à la demande du client.
Introduction
• Un Audit se concrétise toujours par un rapport : exemples
– Audit de l'environnement informatique :
• Mission : Evaluer les risques des systèmes d'information

nécessaires au fonctionnement des applications. (Par
exemple : Sécurité physique, sécurité logique, sécurité des
réseaux, plan de secours...)
• Livrables : Rapport contenant les faiblesses relevées, leur

niveau de risque et les mesures correctives proposées.
9
Introduction
– Audit d’une application informatique
• Mission : Evaluer les risques d'une application informatique.

La mission débute par la définition des processus métiers
concernés, puis évalue leurs risques.
• Livrables : Rapport contenant les faiblesses relevées, leur

niveau de risque et les mesures correctives proposées.
Introduction
– Audit d'une application en cours de développement :
• Mission : Assister l'équipe de projet à évaluer les risques

lors des différentes étapes de réalisation d'une application
informatique et proposer des mesures de réduction et de
contrôle des risques importants.
• Livrables : Mesures proposées de réduction et de contrôle

des risques importants de la nouvelle application
informatique.
10
L‘audit : dans quels buts ?
Il existe deux types d'audit informatique

répondant chacun à un but différent :
1-l'audit du besoin ;
2-l'audit de découverte des

connaissances.
1-L‘Audit du Besoin :
L'audit du besoin comporte deux
parties :
• 1.1- l'analyse de l'existant ;
• 1.2- la détermination de la cible.
11
1-L‘Audit du Besoin :
1.1-L'analyse de l'existant consiste en un travail de terrain au

terme duquel on formalise la circulation des documents
"types" d'un acteur à l'autre et le traitement que chaque
acteur applique à ces documents, à l'aide de logigrammes
(traitements sur les documents) et de représentation de
graphes relationnels (circulation des documents).
L‘Audit du Besoin :
– 1.2-La détermination de la cible consiste à repérer :

• les passages "papier - numérique" et "numérique - papier" ;
• les redondances dans le graphe ("formulaires en plusieurs
exemplaires") ;
• les goulots d'étranglement (dispersion des infrastructures, points de
contrôle et validation nécessaires ?) ;
• le découpage en zones, en sous-graphes : les domaines "métier". Ainsi
chaque zone peut être dotée d'un outil spécifique, plutôt qu'un seul
système global "usine à gaz".
• Ainsi le résultat de l'audit, généralement élaboré et approuvé
collectivement, peut donner lieu non pas à un projet, mais plusieurs
projets ordonnancés dans une feuille de route.
12
– 2-Audit de Découverte des Connaissances (peu utilisé

puisque réservé à certaines applications (hypercube,..))
• L'audit de découverte des connaissances consiste à valoriser les

données et connaissances existantes dans l'entreprise. La
modélisation mathématique des bases de données oblige
toujours à "perdre" une partie de l'information, il s'agit de la
redécouvrir en "brassant" les données.
• Un audit de découverte des connaissances aboutit généralement

au montage d'un système décisionnel, mais peut également être
le prélude à un système de gestion des connaissances
L'audit de découverte des connaissances se pratique de

la manière suivante :
• Pas d'objectifs : on ne sait pas ce que l'on va découvrir ;

• Un domaine : on sait sur quels métiers on travaille, donc sur
quelles bases de données ;
• une équipe intégrée : travaille in situ, trois acteurs dont un
expert "métier", un expert "administration informatique" et un
fouilleur de données (data mining)
• Le travail se fait par boucle courte de prototypage
• Pour faciliter le brassage des données, on modifie leur format et
leur disposition relative. C'est le "preprocessing" qui prend le
plus de temps
• À l'aide d'algorithmes à apprentissage d'une part, et de
visualisations de données d'autre part, le fouillleur met en
évidence des liens empiriques entre les données
13
– Les corrélations et liens retenus doivent répondre à trois critères :

inconnu de l'utilisateur, explicable à posteriori, et utile. La
démonstration théorique du phénomène est totalement superflue.
– Les connaissances détectées sont formalisées (arbres, graphes,
tableaux, règles, etc.) puis prototypées logiciellement
– La validité des connaissances prototypées est vérifiée grâce à un test
statistique (khi deux, kappa, etc.) sur un jeu de données dit "test set",
différent du jeu ayant servi à l'analyse ("training set")
– Le test set peut être soit externe au training set, soit recalculé à
partir de lui (rééchantillonnage)
Si le test est passé, le modèle est mis en production

– On recommence le cycle.
– Concrètement, l'empilement des modèles, eux-mêmes parfois
complexes (arbres et récursivité) peuvent aboutir à de vrais problèmes
d'architecture informatique :
– Parallélisation des calculs
– Volumétrie des données
– Charge du réseau, en partie due aux mécanismes de réplication
– D'un autre côté, le résultat de calcul issu d'un empilement de modèles
peut aboutir à des résultats particulièrement pertinents et
surprenants
14
Les niveaux de l‘Audit
• On peut identifier 3 niveaux d‘audit informatique :
– Stratégique : assurer la pertinence du SI, son adéquation aux

objectifs de l‘entreprise, son alignement à ses stratégies)
– Tactique : assurer la qualité des processus mis en oeuvre par la

fonction informatique (exploitation quotidienne,
développement de nouvelles applications, évolution du système
existant, préparation de l‘avenir,..)
– Opérationnel : assurer la sûreté du fonctionnement quotidien

de l‘informatique
Les règles de l‘audit
• Quel que soit le type de l‘audit (interne ou externe,

contractuel ou legal,..) la finalité est toujours de
porter un jugement sur le management du SI et
l‘execution de ses objectifs. C‘est donc la comparaison
entre ce qui est observé (acte de management ou
d‘execution) et de que cela devrait être, selon un
système de références.
15
• L‘audit ne doit pas se limiter à une approbation ou

une condamnation (inutile pour l‘audité), mais
préciser ce qu‘il aurait fallu faire, et ce qu‘il faudra
faire pour corriger les défauts constatés.
• Exemple : la documentation est globalement

compréhensible, mais elle doit être mise à jour car
elle n‘est plus en phase avec la maintenance de la
dernière année.
Règle 1 :
L‘audit informatique consiste à comparer

l‘observation d‘un ou plusieurs objets, selon un
ou plusieurs aspects, à ce qu‘ils devraient être,
pour porter un jugement et faire des
recommendations.
16
• La tache de l‘auditeur est parfaitement définie

quand l‘objet et l‘aspect le sont : elle ne doit pas
en déborder.
Exemple : S‘il lui est demandé de vérifier la

sécurité d‘une application, et qu‘il en est
satisfait, il est inutile de savoir si les résultats
sont exacts (étude de fiabilité) ou inutiles (étude
d‘adaptation).
• Règle 2 :
L‘auditeur ne doit pas interpréter la finalité de

l‘audit en fonction de ses goûts ou aspirations,
à fortiori ne pas déborder de la mission si des
lacunes hors mission se révèlent.
17
Sous réserve que les moyens attribués soient

suffisants (l‘auditeur doit s‘en assurer lors de la
signature du contrat) et que l‘auditeur est
compétent dans le domaine audité,
5-Les règles de l‘audit
Règle 3 :
l‘audit est toujours faisable.
(la non-faisabilité est un argument poubelle utilisé
par l‘auditeur incompétent).
Exemple : l‘audit d‘une application peut parfois être

très ardu : non-disponibilité des personnes,
documentation partiellement dépassée, etc...
18
Le travail d‘audit peut-être assez complexe et

doit obeir aux mêmes règles que le
management ou la conduite de projets, en
partuculierêtre découpé en fonctions
conduisant de façon arborescente à un plan
avec des étapes significatives de conclusions
partielles
Règle 4 :
Les moyens et actions de l‘auditeur doivent être
adaptés exclusivement mais exhaustivement au sujet
de l‘audit.
Exemple : si un audit a besoin de données financières

(confidentielles) en tant que données périphériques
qui ne rentrent pas dans le domaine de l‘audit,
l‘auditeur devra avoir accès à ces données tout en
respectant la confidentialité.
19
les différents audit SI (liste non exhaustive)
L'audit de la planification :
Rôle de la planification informatique : plan, schéma
directeur, etc, Cohérence entre les objectifs du
schéma directeur et la stratégie de l'entreprise
Les différents audit SI (liste non exhaustive)
L'audit de la fonction informatique :
Positionnement et structure de la fonction
informatique. Capacité à atteindre les objectifs avec
sûreté et efficacité. Relations avec la Direction
Générale et les utilisateurs. Clarté des structures et
des responsabilités.
20
L'audit des projets :
Existence d'une méthodologie de conduite des
projets. Respect des phases du projet. Conformité des
projets aux objectifs généraux de l'entreprise. Qualité
des études amont : expression des besoins, cahier des
charges.
L'audit des études :
Planification des études. Conduite des projets par
étape. Maîtrise du processus de développement. Mise
sous contrôle de la maintenance.
21
L'audit de la micro-informatique :
Instruction des demandes particulières. Suivi de
l'utilisation des logiciels. Formation des utilisateurs.
Contrôle de l'auto-développement.
les différents audit SI, suite (liste non exhaustive)
L'audit de l'exploitation :
Qualité de la planification de l'exploitation. Gestion des
ressources. Procédures de sécurité et de continuité de
service. Maîtrise des coûts d'exploitation.
22
L'audit des réseaux et des communications :
La conception du réseau. Choix des standards et
notamment en matière de protocole. Mise en place de
dispositifs de mesure de l'activité.
L'audit de la sécurité :
Les facteurs de limitation des risques : Existence d'une
politique du système d'information. Implication des
utilisateurs. Méthodes de travail et outils adaptés aux
objectifs.
23
L'audit des applications opérationnelles :
Nécessité d'évaluer périodiquement les applications
opérationnelles. L'importance du respect des règles de contrôle
interne : la conformité. Appréciation de la contribution de
l'application à l'efficacité du dispositif.
4-10 ...
les différents audit SI
L'audit de la planification informatique :
– L’état de l’art en matière de planification informatique :

plan, schéma directeur, master plan, etc.
– Les trois dimensions des schémas directeurs : architecture,

coût et dispositif de travail.
– Les bonnes pratiques observées en matière de planification

informatique :
• existence d’un document de référence ;
• fixation d’orientations ;
• capacité d’évolution.
24
Diagnostic
Toute opération d’audit informatique nécessite la mise

en œuvre d’un diagnostic :
– Fonctionnel – Technique
Cartographie du système d’information
25
Diagnostic fonctionnel :
L'objectif d'étudier le contexte fonctionnel de

chaque application et son environnement d'organisation
Les environnements sont généralement

caractérisés par :
– les flux d'information,
– les règles de gestion,
– les contraintes réglementaires
Diagnostic fonctionnel :
Etablir le périmètre des domaines d'applications

Identifier les contraintes fonctionnelles
intrinsèques de chaque application ou domaine
applicatif.
Caractériser précisément les flux d'information
(nature et modalité d'utilisation des données,
émetteur et destinataire).
Etudier les liens inter applications et les
interfaces avec d'autres bases de données ainsi
que les règles de gestion associées (sécurité,
périodicité et modalités de mise à jour, ...).
26
La cartographie fonctionnelle du système d'information
La démarche précédente débouche concrètement

sur une cartographie fonctionnelle des systèmes
d'information
C'est la représentation des différentes

fonctions des applications et de leurs flux
d'échanges, regroupés en domaines d'informations
cohérents
Diagnostic technique :
Recense avec précision les composants de

chaque programme (code source, langages,
progiciels, volumétrie, documentation,....)
Il consiste à analyser précisément les

composants techniques de chaque application
la plate-forme d'exploitation : nombre de sites,

nombre de postes de travail, typologie des unités
centrales (gros système, départementale,
monoposte), réseaux de communication
27
Diagnostic technique :
l'architecture logicielle : client/serveur,

bureautique, infocentre.
les outils de développements : système

d'exploitation, Systèmes de Gestion de Base de
Données, langages de programmation, méthode
d'analyse et recours aux Ateliers de Génie Logiciel.
la volumétrie des composants techniques : écrans,

entrées/sorties, restitutions, lignes de programmes.
La cartographie technique d'un système d'information:
Représentation des :
– divers composants du système avec
leurs couplages,
– regroupés en sous-systèmes
– dont l'évolution est indépendante .
28
Le rôle de la planification informatique :
L’informatique est une activité à cycle long

Un projet dure 6 à 24 mois
Une application utilisée : 7 à 12 ans et même parfois
plus
Il est pour cela nécessaire d’avoir une vision longue
Différents types de démarche :
– Schéma directeur
– Plan Informatique
– Document d’orientation
– ....
Aider à ce que les SI contribuent aux objectifs de
l’entreprise
Avoir une démarche rationnelle permettant de
dégager des orientations et des objectifs à atteindre
29
Les dimensions des schémas directeurs :
Schéma directeur doit répondre à 3 préoccupations

– L’architecture :
Architecture technique (central,
réseau, poste client,...)
Architecture fonctionnelle (applications)
– Les coûts :
Les investissements à effectuer
Les gains et la rentabilité
Les coûts de fonctionnement
– Le dispositif de travail :
La mise en place de l’architecture
Les développements
Le pilotage
Des démarches plus limitées :
Beaucoup de SD ne couvrent que l’architecture

fonctionnelle
Absence ou déconnexion de l’architecture technique
Dans ce cas c’est plus un programme de travail des
études informatiques qu’une démarche de planification
Une évaluation des dépenses d’investissements mais
sans évaluation des gains et de la rentabilité
Le dispositif de travail n’est pas prévu
Pas de dispositif de suivi et de pilotage
30
Les bonnes pratiques observées en matière de planification
Trois bonnes pratiques importantes concernant la

planification :
Existence d’un document

Fixation des orientations
Capacité d’évolution
Existence d’un document (1/2)
Importance de disposer d’un document écrit

(nombre élevé d’interlocuteurs)
A vérifier :
– Il doit exister dans chaque entreprise un
document fixant les orientations informatiques à
moyen terme (Plan Informatique, Schéma,
Directeur, Plan à long terme,....)
– Les objectifs de développement du système
d’information doivent être cohérents avec les
objectifs de l’entreprise
31
Existence d’un document (2/2)
– Les orientations doivent être cohérentes entre elles et

avec les moyens octroyés à l’informatique
– Ce document doit être connu et approuvé par les
principaux décideurs de l’entreprise
– De même les informaticiens et les principaux
utilisateurs doivent disposer du même document
Fixation des orientations
A vérifier :
– document de référence doit fixer des orientations

claires et comprises des intéressées
- choix technologiques réalistes et conformes aux besoins
- orientations fonctionnelles cohérentes avec
orientations technologiques
– orientations prises correspondent bien aux objectifs
recherchés
– moyens disponibles sont suffisants
– tenue en compte des évolutions pour réajuster les
objectifs et des moyens
32
Capacité d’évolution
A vérifier :
– L’existence d’un suivi périodique de la planification
– L’existence d’un système d’évaluation de la politique
informatique.
– Le document de planification doit être périodiquement
mis à jour à l’aide d’un processus régulier
– La capacité à faire évoluer les règles et à saisir les
opportunités qui se présentent
Audit d’un schéma directeur
L’audit porte sur les éléments suivants :

– La cohérence entre les objectifs du SD et de la
stratégie de l’entreprise
– Le processus de validation du schéma directeur
– Le dispositif de pilotage du schéma directeur
– Les méthodes de suivi du schéma directeur
– Les procédures d’actualisation du schéma directeur
33
La cohérence entre les objectifs du schéma directeur et de la

stratégie de l’entreprise
Point fondamental car l’alignement stratégique est un enjeu

majeur
Trop souvent pas convergence et même parfois il y
a divergence
Un SD qui n’est pas orienté vers les préoccupations du
management ne sera pas appliqué
Travail à faire :
– S’assurer que orientations connues des dirigeants
– Analyser le SD et le document de stratégie
– Avoir des entretiens avec les principaux dirigeants
Le processus de validation du SD
L’élaboration du SD doit être de manière participative

Une démarche cohérente doit être suivie
Les principaux décideurs et les principaux utilisateurs
des SI doivent avoir participé à son élaboration
Il doit exister un consensus sur les objectifs recherchés
et sur les moyens pour les atteindre
Il est possible que, sur des points particuliers, il reste
des désaccords mais ils doivent être limités
Travail à faire :
– Analyser les comptes-rendus des réunions des groupes
de travail et du comité de pilotage
– Faire des entretiens avec quelques participants au
processus
34
Le dispositif de pilotage du SD
Il doit exister un document, figurant si possible dans

le SD, précisant les modalités pratiques de mise en place
et de pilotage du schéma directeur
On doit périodiquement mesurer l’avancement de la
mise en place du SD et un rapport doit être établi
Un organe (généralement un comité de pilotage) doit
prendre, si nécessaire, des mesures correctives
Travail à faire :
– Examiner le document définissant les modalités de
pilotage
– S’assurer que la mise en œuvre du SD se fait
conformément à ce qui a été prévu
– Analyser les décisions prises par le comité de pilotage
Les méthodes de suivi du SD
Pour piloter efficacement le SD on doit régulièrement

mesurer son avancement
nécessaire d’avoir une démarche d’évaluation
clairement définie
L’appréciation différente selon les points de vue :
– L’informaticien
– L’utilisateur
– Le décideur
Travail à faire :
– Examiner le document définissant la méthode ou la
démarche d’évaluation du schéma directeur
– Vérifier l’application de cette méthode
– Avoir des entretiens avec quelques informaticiens,
utilisateurs et décideurs pour appréciation du suivi du SD
35
Les procédures d’actualisation du schéma directeur
Le schéma directeur doit être périodiquement mise à jour

Prendre en compte si c’est un plan à long terme glissant
Cette mise à jour peut porter sur :
– Les objectifs à atteindre
– L’architecture mise en place
– Les moyens affectés
– Le nombre et l’importance des projets lancés
– Le mode de déploiement
– ....
Travail à faire :
– Examiner les différents documents de mise à jour du schéma
directeur
– Apprécier leur pertinence
– Détecter s’il n’y a pas une dérive des objectifs ou une fuite
en avant
36
La sensibilité des dirigeants :
Les dirigeants s’interrogent assez fréquemment sur

le niveau des coûts informatiques
Attitude de scepticisme
Les coûts sont toujours trop élevés
Ils se souviennent qu’ils se sont jadis fait «avoir»
Les fournisseurs sont souvent trop présents
Ils veulent avoir un avis neutre et indépendant
Une notion assez floue
En fait la notion de coût informatique n’est pas très

claire
Il comprend le matériel .... mais aussi les PC
Les progiciels .... mais aussi les études
....
Il existe une nette tendance à la sous-évaluation
Il existe de nombreuses zones d’ombres
Qu’est ce qui fait partie des coûts informatiques et ce
qui en est exclu ?
37
Un sujet difficile
Ne pas sous estimer la complexité de l’évaluation des

coûts informatiques
La difficulté est réelle
Mélange entre les dépenses d’investissement et les
dépenses de fonctionnement
Pas de nomenclature des dépenses reconnue
Difficultés de faire des comparaisons entre différentes
entreprises, même dans un groupe
Il n’existe pas de référentiel largement reconnu
Il existe des études de benchmarking mais elles sont
hétérogènes
De nombreuses causes de sous-évaluation
Une nette tendance à la sous-évaluation des dépenses :

– Domaine imprécis
– Dépenses oubliées
– Méthodes de calcul incertaines
– .....
Il est difficile d’obtenir des coûts par projet et encore
plus des coûts par application
On a trop souvent une approche à dominante technique
38
Délimiter le domaine informatique
Qu’est ce qui fait partie de l’informatique ?

– Le service informatique seul
– La fonction informatique : c’est la somme entre le coût
du service informatique et celui de l’informatique
décentralisée
– Le système d’information
Cas des dépenses des services décentralisés et des filiales
Notion de coût complet
C’est tout ce qu’a coûté l’informatique au cours

d’une période déterminée
Le problème c’est le tout
Pour le cœur des dépenses c’est clair
Par contre les frontières sont beaucoup plus floues
De nombreuses dépenses sont difficiles à cerner :
– Les dépenses décentralisées : PC, réseau,
communication, assistance technique,....
– Difficulté de mesurer les temps de la maîtrise
d’ouvrage
39
Importance d’avoir une méthode de calcul efficace
Pour calculer des coûts il est nécessaire de disposer

d’une méthode de calcul
Elle consiste à :
– Définir le domaine de référence
– Définir les produits informatiques
– Définir la méthode de calcul
Calcul des amortissements du matériel et surtout des
coûts des études et du démarrage
Prise en compte des autres charges
Les principes du contrôle de gestion de l'informatique
Une philosophie du management

La décentralisation des décisions
La détermination des objectifs
Améliorer l'efficacité des dépenses informatiques
Le pilotage des investissements informatiques
40
Améliorer l'efficacité des dépenses informatiques
Les directions générales s'interrogent sur l'opportunité des

dépenses informatiques
Elles veulent savoir où passe l'argent
Elles veulent aussi connaître son impact sur l'efficacité de
l'entreprise
Le contrôle de gestion des dépenses informatiques vise :
1. Maîtriser l'évolution des dépenses informatiques
2. Mettre sous contrôle les coûts de fonctionnement
3. Piloter efficacement les investissements
informatiques
1 - Maîtriser l'évolution des dépenses informatiques
Il est toujours difficile de passer des objectifs

techniques à des objectifs financiers
Le faible nombre de mesures limite les analyses
Il existe une réticence naturelle face à la mesure
Difficulté de trouver les moyens d'action efficaces
Il est nécessaire de démontrer la bonne gestion de
l'informatique
41
2 - Mettre sous contrôle les coûts de fonctionnement
Importance de bien maîtriser les coûts récurrents

Commencer par définir avec rigueur ce que sont les
coûts de fonctionnement
Risque de sous-évaluation et même d'oubli de certain
postes
Utilisation des outils existants : Job accounting
Mise en place des outils d'analyse
Calculer des coûts unitaires par application
Apprendre à travailler les coûts des applications
3 - Le pilotage efficace des investissements informatiques
La maîtrise de l'informatique passe par la maîtrise

des projets informatiques
La moitié des coûts informatiques sont directement liés aux
projets
Tendances :
– Le renforcement des études amonts
– Une sélection plus rigoureuse des projets
– Un phasage des projets
– Un dispositif de suivi des développements
– Les tests et la réception de l'application
– Un audit de fin de projet
42
Rappel sur les techniques d‘évaluation des coûts
Plan
Les principes de base de la comptabilité analytique

Les concepts clés
Les différentes méthodes existantes
La mise en oeuvre de ces règles
Quelques recommandations
Les principes de base de la comptabilité analytique
Le calcul du coût de revient d'une application ou d'un

projet
Il faut passer des dépenses par nature aux :
– dépenses par centre de frais : les études,
l'exploitation, l'assistance,....
– dépenses par produits, services ou projets
La notion de dépenses directement affectables
– les sous-traitances, les achats spécifiques,...
Le traitement des dépenses non-directement
affectables
– L'imputation sur la base des unités d'oeuvres
consommées
43
Les concepts clés
Le coût de revient d'une application

Tout ce qu'a coûté une application à un moment donné,
dans l'état où elle se trouve
Commencer par déterminer le domaine informatique
Mesurer le volume d'activité (Unité d’Oeuvre) par
application
Calculer le coût unitaire par Unité d’Oeuvre
Le coût d'une application :
– Les coûts directs
– Les coûts indirects : la somme des coûts par
centre de frais
Imputer les dépenses par centres de frais et par nature
Répartition des dépenses par centre de frais
Le travail des coûts
Il est possible de faire diminuer les coûts sur moyenne

période en agissant sur les différents postes de dépenses
Une importante palette d’actions possibles :
– Les mesures ponctuelles
– Les aménagements simples
– La refonte d’applications
Planifier les actions dans le temps
44
Les différentes méthodes existantes
La méthode des coûts réels ou des coûts historiques :

Centre de frais, coût d'unité d'oeuvre
La méthode des coûts standards :
La notion de coût d'unité d'oeuvre standard
La méthode des coûts directs :
La combinatoire des méthodes :
Coûts complets réels
Coûts complets standards
Coûts directs réels
Coûts directs standards
La méthode ABC
La mise en oeuvre en pratique
Les quatre préalables :

– Un schéma comptable clair
– Le découpage en centres de frais
– La ventilation des charges
le suivi des temps et des salaires
l'imputation des factures des fournisseurs
les amortissements du matériel
– La mesure de l'activité des différents centre de frais
L'amortissement des études
– Le choix de la durée des amortissements
45
1 - L'analyse du coût des applications existantes
Le but n'est pas de faire de la comptabilité Plus la

méthode est simple, plus les calculs sont
compréhensibles
L'objectif est de comprendre les causes des sur-coûts
Détecter suffisamment tôt les évolutions à venir
Situer les coûts informatiques par rapport aux coûts
des fonctions
Apprécier s'il est intéressant d'investir plus
Et s'il est possible chercher à réduire les
investissements faits
Les différentes démarches d’audit des coûts
Plan
L'analyse du coût des applications existantes

L'évolution des coûts unitaires
L'audit des dépenses constatées
L'audit des méthodes comptables
L'estimation prévisionnelle des dépenses
Les budgets d'investissements
Le contrôle des investissements
46
Tenir compte des gains
Il est aussi important de chercher à mesurer les

enjeux
Il existe deux sortes de gains :
– Les gains de productivité:
Faire la même chose avec moins de ressources
Ex : moins de temps par commande
– Les gains d'efficacité
Faire plus avec les mêmes ressources
Ex : plus de chiffre d’affaires et de marge
Les investissements informatiques sont sources de
gains de productivité et d’efficacité
2 - L'évolution des coûts unitaires
Chercher à avoir une vision dynamique des coûts par

application
Tenir compte de l'évolution des fichiers et des volumes à
traiter
Rôle de la fiche d'application pour suivre l'évolution des
coûts :
– Constituer un historique des volumes et des coûts
– Mettre en avant les facteurs de hausse des dépenses
La séparation des frais fixes et des frais variables
Réduire le poids des frais fixes
Les actions sur les coûts variables
47
3 - L'audit des dépenses constatées
En matière de coûts informatiques on souffre de

l'absence de références indiscutables
Il peut exister des normes internes à l'entreprise
On peut trouver des orientations dans le schéma
directeur ou dans les cahiers des charges
En fait, peu d'entreprises ont une politique en ce
domaine
Si toutes les entreprises ont des budgets globaux et un
suivi, peu ont des analyses des dépenses
Il est nécessaire de les analyser de manière fine
Mais cette approche a des limites
Il est pour cela nécessaire d’auditer la méthode
comptable
4 - L'audit des méthodes comptables
Quelques points de contrôle :

Vérifier l'existence d'une documentation écrite
Examen des feuilles de calcul et des résultats
Le respect des règles comptables communes
Est-ce que les coûts calculés sont significatifs ?
Les coûts sont-ils complets ou partiels ?
La qualité des mesures d'activité
La conformité de la procédure de calcul
Des simplifications sont-elles possibles ?
L'appréciation de la qualité des résultats
48
5 - L'estimation prévisionnelle des dépenses
Il existe presque toujours un budget des dépenses

Les trois méthodes de prévision des dépenses de
fonctionnement :
– L'évaluation globale
– L'évaluation analytique
– L'estimation par les volumes à traiter
Avoir un modèle simple d'évolution des coûts
Passer des dépenses de fonctionnement au budget :
– Les amortissements
– Les achats de matériels
L'audit des prévisions
Identifier et qualifier la méthode de prévision utilisée

Apprécier la qualité des prévisions au cours des trois
précédents exercices
Les cinq points à regarder de prés :
– La prise en compte des frais fixes
– Le poids de la maintenance des applications
– La durée de vie des systèmes
– La prévision de la charge machine
– L'évolution des volumes à traiter
Distinction entre investissement et fonctionnement
49
6 - Les budgets d'investissements
Le dérapage des budgets est fréquent

La loi de Mac Namara :
– doublement des coûts
– doublement des délais
– réduction de moitié des fonctions disponibles
Avec humour on parle d’un multiplicateur de 3,14
entre budget d'origine et coût final
Nécessité de bâtir des budgets crédibles
Il y a peu d'erreurs sur l'évaluation des coûts de
programmation mais ce n'est que le tiers des coûts
Le poids des études amonts et de l'organisation
La sous-évaluation des tests et de la mise en place
L'audit des investissements
Examiner quelques projets récemment mis en oeuvre

Quelques points à regarder de près :
– Y-a-t il eu un dossier d'investissement ?
– Appréciation de la qualité des prévisions de coût
– Liste des postes qui sont systématiquement sous-
évalués
– Recherche des causes de dérapage
– Y-a-t il eu une appréciation des gains ?
– Appréciation de la qualité de l'évaluation des enjeux
50
L'audit des outils de contrôle de gestion de l’informatique
Plan
– L’audit du contrôle de gestion

– L’audit des dépenses constatées
– L’audit des méthodes comptables
– L’audit de la comptabilité analytique
– L’audit des prévisions de dépenses
– L’audit des budgets des dépenses
– L’audit des investissements
– L’audit des tableaux de bord
– L’audit des projets
– L’audit de la refacturation
– L’audit du dossier d’investissement
51
Le contrôle de gestion de l'informatique
Le contrôle de gestion repose sur une philosophie du

management : la décentralisation
Faire prendre les bonnes décisions au bon niveau
La direction par objectifs :
– Les objectifs techniques
– Les objectifs financiers
– Les objectifs qualitatifs
La détermination des budgets
Le suivi des écarts
L'application du contrôle de gestion à l'informatique
L'audit du contrôle de gestion
Neuf points de contrôle :

– Existe-t-il des objectifs et de quelle nature sont-ils ?
– Y-a-t-il des objectifs économiques ?
– Quelles sont les responsabilités des décideurs ?
– Y-a-t-il une liaison entre les objectifs et les budgets ?
– Est-ce que la procédure budgétaire est vivante ?
– Est-ce que les budgets sont négociés ?
– Les budgets sont-ils établis par responsables ?
– Les responsables sont-ils d'accord sur les budgets ?
– Les utilisateurs reçoivent-ils copie des budgets
Repérer les systèmes purement formels
52
L'audit des dépenses constatées
Six points de contrôle :

– Existence d’un plan de comptes des dépenses
Informatiques
– Y-a-t-il des normes ou des règles internes en matière de
dépenses informatiques ?
– Est-ce que les coûts obtenus sont complets ?
– Trouve t’on dans le schéma directeur et dans les cahiers
des charges des orientations précises en matière de coût ?
– Y-a-t-il une politique claire en matière de dépenses
effectivement constatées ?
– Effectue t’on régulièrement des analyses de ces
dépenses ?
Mais pour répondre aux attentes du management il faut
auditer les méthodes comptables
L'audit des méthodes comptables
Neuf points de contrôle :

– Vérifier l'existence d'une documentation écrite
– Examen des feuilles de calcul et des résultats
– Le respect des règles comptables communes
– Est-ce que les coûts calculés sont significatifs ?
– Les coûts sont-ils complets ou partiels ?
– La qualité des mesures d'activité
– La conformité de la procédure de calcul
– Des simplifications sont-elles possibles ?
– L'appréciation de la qualité des résultats
53
L'audit de la comptabilité analytique
Huit points de contrôle :

– La simplicité de la méthode de calcul utilisée
– Le nombre de centres de frais (à limiter
strictement)
– Le degré de complétude des coûts
– La charge de travail nécessaire pour effectuer
la comptabilité analytique
– La qualité des mesures d'activité : unité
d'oeuvre des centres de frais vers les prix de revient
– Le poids des clés de répartition forfaitaires
– La confusion entre la comptabilité analytique avec
le système de refacturation
– Les coûts par projet et par application sont-ils
utilisés ?
L'audit des prévisions des dépenses
Identifier et qualifier la méthode utilisée

Apprécier la qualité des prévisions au cours des trois
précédents exercices
Les cinq points à regarder de prés :
– La prise en compte des frais fixes
– Le poids de la maintenance des applications
– La durée de vie des systèmes
– La prévision de la charge machine
– L'évolution des volumes à traiter
Les prévision de dépenses doivent faire la distinction
entre investissement et fonctionnement
54
L'audit des budgets informatiques

– La cohérence entre les budgets et le plan
informatique ou le schéma directeur
– La cohérence entre le budget des études et le planning
des études
– La cohérence entre le budget d'exploitation et le
planning des déploiements
– Les relations entre les objectifs du service informatique
et le niveau de ses dépenses
– L'existence de variantes budgétaires
– La qualité et le réalisme des hypothèses budgétaires
Il est important d'apprécier la pertinence de la procédure
d'élaboration des budgets
L'audit des investissements
Examiner quelques projets récemment mis en oeuvre

Six points de contrôle à regarder de près :
– Y-a-t il eu un dossier d'investissement ?
– Appréciation de la qualité des prévisions de coût
– Liste des postes systématiquement sous-évalués
– Recherche des causes de dérapage
– Y-a-t il eu une appréciation des gains ?
– Appréciation de la qualité de l'évaluation des enjeux
55
L'audit des tableaux de bord
Sept points de contrôle :

– L'utilisation des tableaux de bord de l'informatique par
la direction générale
– Les objectifs doivent être négociés
– Les objectifs sont cohérents avec les budgets
– La qualité des indicateurs choisis
– S'assurer que la procédure est vivante
– Le délai de disponibilité des chiffres mensuels
– La liste des décisions prises depuis trois mois à l'aide
des tableaux de bord
L'audit des projets
Sept points de contrôle :

– L'existence d'une méthode de gestion des projets
(s'assurer qu'il existe un document écrit, qu'il est lisible
et qu'il est utilisé)
– Un document doit décrire le projet et son organisation
– Le phasage du projet doit être clair et à la bonne maille
– Vérifier les "outputs" à la fin de chaque phase
– La qualité du dispositif de pilotage
– Le rôle des utilisateurs doit être clairement défini
– Examiner les raisons du rejet des projets
56
L'audit du dossier d'investissement
Huit points de contrôle :

– Le degré d'application de cette procédure par les
décideurs
– La qualité du dossier d'investissement
– L'existence d'un comité d'investissement
– Le degré d'engagement du management
– Le politique de sélection et : quels sont les critères
effectivement utilisés
– Quelle est la nature des gains constatés
– Y-a-t il des audits de fin de chantier ?
L'audit de la refacturation

– Estimer le degré de compréhension des règles de la
facturation par les utilisateurs
– Les règles de facturation qui sont appliquées sont elles
contestées ?
– Est-ce que la facturation se fait selon des unités
d'oeuvres techniques ou des unités d'oeuvre utilisateurs ?
– Est-ce qu'on a constaté des modifications des
comportements des utilisateurs ? De quelle nature sont
ces changements ?
– Est-ce que les utilisateurs et le service informatique sont
dans une relation client-fournisseur ?
– Quelle est la stabilité des calculs ?
57
Plan
L’état de l’art en matière d’organisation

– Le diagnostic de l'organisation
– Les liens entre l'audit informatique et l'audit de
l'organisation
– Les deux approches de la gestion de l’entreprise :
par fonction
par processus
– L'analyse des structures : organigramme,
décentralisation
– L'analyse des hommes, des compétences, des
motivations
Les bonnes pratiques en matière d'organisation
Les points de contrôle
Recommandations
Exemples
58
Le diagnostic de l'organisation
Très souvent on demande à l’auditeur de « jeter un

coup d’œil» à l’organisation en place
Les préoccupations informatiques renvoient souvent à
des problèmes d’organisation
Que veut dire « évaluer une organisation » ?
De multiples approches possibles :
– Structures
– Hommes
– Répartition des tâches
– Efficacité, productivité
– Coûts des opérations, des services, des processus
– ….
Evaluer une organisation
Objectif : porter une appréciation objective sur une

organisation en place
Avoir une vision large orientée vers le système
d’information de l’entreprise et les partenaires
extérieurs
Décrire l’organisation en place et la comparer à un
référentiel
Malheureusement il n’y a pas de référentiel global de
l’ensemble des fonctions et des processus largement
reconnu
Peu de chose dans CobiT. Il s’intéresse surtout à
l’organisation de l’informatique. Peu de chose sur
l’ensemble de l’informatique
Rôle très important de la connaissance des entreprises
C’est un vrai métier : consultant
59
Les liens entre l'audit informatique et l'audit de l'organisation
L’audit informatique s’intéresse à l’automation des

traitements i.e l’automation des fonctions ou des process
L’audit de l’organisation s‘intéresse à la manière dont
opèrent les fonctions et les process
Ce sont deux domaines voisins mais différents par
l’approche et la démarche de l’auditeur :
– Dans le cas d’un audit informatique on entre par
l’informatique
– Dans le cas d’un audit organisation on entre par
l’organisation
Mais dans les deux cas on analyse, on classe et on
juge les mêmes objets
Les deux approches de la gestion de l’entreprise
On peut analyser l’activité de l’entreprise selon deux

grands axes :
– par fonction :
La comptabilité
Le commercial
La production
….
– par processus :
Les ventes
Les achats
…
Approche verticale ou approche horizontale
60
Approche par les fonctions ou par les process
A B C D E
Processus A
Processus B
Processus C
Processus D
Analyser les fonctions et les process
On commence par identifier les services

On repère les tâches ou les groupes de tâches
effectuées
On les regroupe par fonction
– Par exemple : la comptabilité, la R & D,
l’exploitation, …
On peut aussi les regrouper par processus
C’est le même travail que celui fait dans :
– Le BPR : Business Process Reengineering
– La démarche qualité (ISO 9000/2000)
On observe trois difficultés majeures :
– Tâches redondantes
– Mauvais enclenchement des tâches
– Nombre trop élevé de tâches
61
L'analyse des structures
L’approche par les structures permet de détecter les

dispositifs inadaptés et peu efficaces
On va pour cela déterminer au sein des unités :
– La constitution des équipes et des responsables
– Les domaine de responsabilité des décideurs
– Le rattachement des équipes
A partir de ces éléments il est possible de reconstruire
un organigramme des unités
Un effort de rationalisation, de simplification et de
réduction du nombre de niveaux hiérarchiques
L’objectif est d’avoir une organisation plus réactive
La gestion des structures
C’est un ensemble de travaux subtils :

– Découpage en équipes
– Pouvoir et responsabilité des chefs d’unités
– Ligne hiérarchique (qui reporte à qui)
– Modalités du reporting
– Comités de direction, composition, rôle,….
– Modalité de pilotage et de contrôle
– Relations avec les autres unités opérationnelles
– Contrôle des opérations décentralisées
– ….
Dans l’entreprise, qui a en charge l’analyse des
structures et de leur évolution ?
62
Centraliser ou décentraliser
Un des choix d’organisation fondamentaux concerne le

choix entre la centralisation et la décentralisation des
opérations et des responsabilités :
– On peut centraliser toutes les opérations au siège
, où du moins, le plus d’opérations possibles
– On peut au contraire reporter sur les départements
ou les agences le plus d’opérations et de
responsabilité possibles
Les directions d’entreprise ont toujours une certaine
marge de manœuvre
Nécessité d’une certaine cohérence entre les
différents domaines :
Si on donne des responsabilités il faut aussi donner
les moyens nécessaires et assurer une autorité suffisante
L’évaluation des hommes
L’analyse de l’organigramme n’est pas suffisant

Il faut prendre en compte le rôle des hommes dans la
structure
Il est nécessaire d’évaluer le contenu des postes, les
compétences et le degré de motivation
Ce travail doit être fait de manière périodique
La gestion des hommes (gestion des ressources
humaines) :
– La description des fonctions et des postes
– L’évaluation périodique des personnes
– La séparation des tâches (règles de contrôle
interne)
– Les relations avec les autres unités
63
1 - Le contenu des postes
Il est nécessaire de définir pour chaque poste les

tâches qu’il est nécessaire d’accomplir
Tous les postes doivent disposer d’une description de
poste mettant en avant les compétences et l’expérience
nécessaire
Les ressources en personnel doivent périodiquement
être évaluées (au moins une fois par an)
Des entretiens d’évaluation doivent être organisés
périodiquement avec tous les salariés
Normalement ils sont assurés par la hiérarchie
Une supervision effective de chaque personne doit
être faite notamment pour juger qu’elle dispose des
moyens pour faire
son travail et qu’elle est performante
2 - Les compétences
Le but de ces entretiens périodiques est

aussi d’évaluer les compétences du personnel
Détecter :
– Les insuffisances
– Les capacités inemployées
– Les potentialités
C’est le rôle de la hiérarchie
Souvent liés à la gestion de la formation
Très souvent ces évaluations ne sont pas
64
3 - Le degré de motivation
Très difficile à évaluer car subjectif

Généralement elle est faite globalement
Evaluation de la hiérarchie (Tour de table du
Comité de Direction)
Etudes de la DRH :
– Enquête globale du personnel
– Enquête par entretiens approfondis
– ….
Il est toujours difficile de sonder les coeurs
Les bonnes pratiques en matière
Les bonnes pratiques en matière d'organisation sont

nombreuses
Elles sont largement connue par le management
Il n’existe pas un référentiel généralement accepté en
matière d’organisation
Six bonnes pratiques sont très importantes :
– Formaliser les règles et l’organisation
– Privilégier l’approche par les processus
65
Formaliser les règles et l’organisation
La première bonne pratique est de définir par écrit

l’organisation de l’entreprise
Ceci se fait par de nombreux moyens :
– Notes de service, plan de développement
– Organigramme
– Description de fonction, délégations
– Procédures opérationnelles
– Documentation des applications informatiques
– ….
Il est recommandé d’avoir un recueil de l’ensemble de
ces documents
Privilégier l’approche par les processus
Il est nécessaire de formaliser les principaux processus

de l’entreprise (5 à 10)
Vision transversale
Prise de conscience de son importance à l’occasion du
développement de la démarche Qualité
Il est nécessaire d’avoir un dossier d’analyse par
processus
Gros travail de mise à plat et de rationalisation :
réduire le nombre de tâches
Prévoir des contrôles de bout en bout
Avoir un système d’information propre au processus,
avec une base de données et un tableau de bord
(Datawarehouse)
66
Clarifier les structures et les responsabilités
Avec le temps les structures se complexifient et

s’alourdissent
Les responsabilités se diluent et finalement personne
ne se sent responsable (coupable ?)
Il est périodiquement nécessaire de faire le ménage,
d’élaguer et de redéfinir des lignes hiérarchiques claires
Touts les domaines de l’entreprise doivent avoir :
– Une définition de leur périmètre
– Un responsable
– Un suivi d’activité (tableau de bord)
Faute de cela l’organisation sera lourde et peu
efficace
Définir les organes de décision
Il est de même nécessaire d’analyser les différents

organes de décision de l’entreprise : comité de direction,
comité de stratégie, comité d’investissements,…
Il faut analyser la manière dont ils fonctionnent :
périodicité des réunions, les participants, les présidents, les
décisions prises,…
Les responsabilités des comités doivent être bien définies
Les principaux objectifs de l’entreprise doivent être sous
contrôle des différents comités
Capacité à prendre rapidement la bonne décision
67
Mettre en place des contrôles suffisants
Une organisation sûre et efficace est une organisation

contrôlée
Il faut qu’il existe des dispositifs de contrôles efficaces
permettant de détecter :
– Les erreurs
– Les fraudes
– Les inefficacités
– ….
Certains contrôles sont manuels mais un nombre
croissant de contrôles sont informatisés
Il faut s’assurer que les contrôles sont en place et
fonctionnent efficacement
Appliquer les règles de contrôle interne
Il est important de vérifier que l’organisation respecte

les principes du contrôle interne
On doit disposer d’une démarche formalisée
Les facteurs de risques doivent être repérés
Des priorités doivent être fixées de manière claire
Les choix doivent être effectués en tenant compte des
enjeux économiques
Mesurer leur impact sur les performances de
l’entreprise
Analyser les missions des auditeurs internes et
externes et leurs impacts
68
Etre prudent et attentif
En fait, à ces six bonnes pratiques s’ajoute une

septième règle, la plus importante
En matière d’organisation, il faut être prudent et
attentif
C’est un domaine où l’expérience compte beaucoup
Importance de l’observation et de l’esprit critique
Prudent : L’observation est difficile
L’interprétation est délicate
Attentif : L’enchaînement des causes est complexe
De faibles variations peuvent avoir des conséquences
importantes
Le succès en ce domaine repose sur une approche
pragmatique
Les points de contrôle
L’audit de l’organisation peut avoir de multiples

aspects
Sept points de contrôles importants :
– Existence d’un document définissant l’organisation
– Organigramme
– Délégations de pouvoir claires
– Procédures de contrôle régulières
– L’évaluation des risques
– Tableau de bord
– Révision périodique de l’organisation
Il existe bien sur d’autres points de contrôles
69
Existence d’un document définissant l’organisation
Il est souhaitable qu’il existe un document unique

regroupant toutes les notes d’organisation
Il doit être mis régulièrement mis à jour
S’il n’existe pas c’est un point faible
Ce document doit être largement diffusés parmi les
managers et les décideurs (et même des exécutants)
En pratique, la plupart des choix se font sur la base de
ce document
L’auditeur s’assurer que ce document existe, qu’il est
largement diffusé, connu des intéressés et appliqué
Il évalue la qualité et le degré de complétude du
document
Organigram
Il est nécessaire de disposer d’organigrammes clairs et

à jour
Ils doivent refléter la réalité en précisant les liens de
dépendance entre les différents responsables
On doit éviter :
– les « électrons libres »
– Les « râteaux trop larges »
Le danger des structures construites pour satisfaire les
«grosses légumes»
Si c’est le cas, faire apparaître le poids des féodalités
Les lignes hiérarchiques doivent être clairement
définies
L’auditeur doit apprécier la qualité des organigrammes
70
Délégations de pouvoir claires
Il est nécessaire que les personnes chargées de

certaines opérations aient des délégations de pouvoir
« La signature »
Ces délégations doivent être écrites et largement
diffusées
Ces documents doivent être claires et sans ambiguïtés
Les délégations figurent souvent dans les fiches de
fonction des responsables
L’auditeur va analyser les délégations de pouvoir et
s’assurer qu’elles sont cohérentes et efficaces
Il va vérifier que tous les responsables bénéficient de
délégations claires
Procédures de contrôle régulières
Il doit exister des contrôles régulier de l’activité

Il est nécessaire que des contrôles soient périodiquement
effectués. Ce sont :
– Les inventaires
– L’analyse de la facturation
– La consistance des comptes clients et fournisseurs
– Les pointages de banques
– ….
Les traitements informatiques facilitent ces contrôles et
améliorent leur fiabilité
L’auditeur doit s’assurer que ces contrôles sont en place,
fonctionnent, sont fait à une périodicité suffisante et donnent
des résultats satisfaisant
Il va analyser les fonctions de contrôle automatisées
71
L’évaluation des risques
Un risque c’est la possibilité d’exposition de l’organisation

aux conséquences néfastes d’événements futurs
Gérer des risques est une démarche permettant de réduire
la probabilité des risques et de limiter les conséquences des
dommages qui peuvent survenir
On va pour cela procéder en 4 étapes :
– Analyser et évaluer les risques par domaine
– Mettre en place des mesures préventives
– Décider de contre-mesures ou de parades
– Assurer un suivi des risques
Une démarche de gestion des risques qui ne suit pas cette
logique est une approche d’une autre nature
L’auditeur s’assure qu’il existe une procédure régulière
d’évaluation des risques (globaux, par domaine,..)
Tableau de bord
Il est nécessaire que les principaux domaines :

services, fonctions, processus,…soient mis sous contrôle
grâce à des tableaux de bords
Ils permettent de rapprocher :
– Des objectifs
– Des réalisations
On suit un nombre limités d’indicateurs (une
vingtaine)
L’auditeur doit s’assurer l’existence de tableau de
bords et leur production régulière (mensuelle)
Apprécier les décisions prises à l’aide de ces tableaux
de bord
72
Révision périodique de l’organisation
Il est nécessaire que les règles de fonctionnement de

l’organisation soit périodiquement mis à jour
Ces évolutions se font régulièrement et naturellement
On doit veiller à ce qu’elles évoluent sans heurt
Eviter le changement pour le changement
Périodiquement on va évaluer l’organisation en place et
l’adapter aux changements de contexte
L’auditeur doit s’assurer que périodiquement (entre 6 et
18 mois) on révise l’organisation
Apprécier l’impact des derniers changements effectués
(sur 1 à 2 ans)
Les recommandations possibles
Mettre au clair la procédure – Formaliser la procédure

– Démarche Qualité ISO 9000
Simplifier la procédure – Reeingenering – « La simplif »
Travailler la productivité des équipes
Mettre en place et améliorer les tableaux de bord
Alléger ou revoir les contrôles
Automatiser la procédure : partiellement ou de bout
en bout
Revoir l’affectation des tâches (au service, à l’équipe,
à la personne)
Requalifier le personnel (formation, mutation,…)
Ne toucher aux structures qu’en cas de besoin
73
Exemples de missions d’audit concernant l’audit de

l’organisation
Audit de la gestion commerciale

Audit du service achat
Audit de la fonction commerciale
Une entreprise de distribution souffre d’une prise de

commandes trop lourde, de traitements des livraisons
complexes et des facturations peu fiables
La direction générale veut sortir de cette situation
Effectivement la fonction est lourde et complexe. Souvent,
certaines opérations sont inutiles
L’organisation est peu efficace et il y a de nombreux points
d’engorgement
Les services refont de nombreux travaux et contrôlent mal
l’activité globale
L’application informatique est ancienne et peu efficace
Lancer une action de simplification des opérations
Supprimer tous les cas particuliers qui ne se justifient pas
Refondre l’application informatique
74
Audit du service achat
Les unités de production se plaignent de la lourdeur et

des délais des opérations d’achats
La direction financière trouve que les stocks sont trop
élevés
Effectivement les coûts d’achat sont élevés
Mais les prix moyen d’achats sont aussi trop élevés
Le niveau des stocks est anormalement élevé
L’organisation en place est peu efficace
Redéfinir les objectifs du service Achat
Repenser la manière d’effectuer les achats
Mettre en place une structure plus légère et plus réactive
Développer un outil informatique simple pour lancer les
approvisionnements dans les unités
75
L'approche de l’entreprise par les processus
On s’intéresse de plus en plus aux processus

Deux raisons :
– Impact des démarches Qualité
– Le reengineering des processus
Nécessité de suivre l’enchaînement des opérations
L’approche par les logiques de service (ou de fonction) ont
des limites. On optimise la productivité localement mais la
productivité globale reste médiocre
Une entreprise a entre 5 et 10 procédures principales et
une vingtaine de procédures secondaires, rarement plus
L'approche qualité : l'importance des procédures
Le développement des démarches Qualité depuis 20 ans

Pression des décideurs pour résister à la concurrence avec
des produits (et des services) meilleurs et moins chers
Au début on a cherché des démarches plus ou moins
efficaces comme les cercles de Qualité, les boîtes à idées,…
L’idée de la Qualité Total a amené l’approche par les
processus (de bout en bout)
C’est une autre vision de l’entreprise
Optimisation par fonction ou par process
Non seulement on améliore la qualité mais aussi la
productivité
76
Description des processus
Un processus est un enchaînement d’opérations, ou de

tâches, permettant d’obtenir un produit ou un service
comme :
– La réception et le traitement d’une commande
– L’achat d’un produit,
– ….
En informatique on a aussi des processus :
– La gestion de projet
– L’achat de services ou de produits
– …
Les processus sont au cœur de l’activité des entreprises
et des administrations
Le reengineering des processus
Idée de Michael Hammer et James Champy de reconcevoir

l’entreprise autour de ses processus (1993) : 2 millions d’ex.
L’idée de base est de reconstruire l’entreprise autour de
ces processus : le BPR, Business Process Reengineering
Le regroupement de plusieurs postes en un seul
La redistribution des tâches entre les unités
Alléger les vérifications et les contrôles
Rôle très important de l’informatique dans l’évolution des
processus : délocalisation, centralisation, meilleur circulation
de l’information,…
Redéfinir les règles de fonctionnement de l’organisation
77
La démarche d'audit appliquée à un processus
Les auditeurs sont amenés à s’intéresser aux processus

Trois soucis :
– La formalisation, manuel, formation,….
– La simplification, la productivité,…
– L’amélioration de la qualité des contrôles
L’auditeur va analyser les processus :
– L’analyse des tâches, leur automatisation,…
– La répartition des tâches
– La manière dont les salariés les mettent en oeuvre
– …..
Aboutir à un ensemble de recommandations positives
Les bonnes pratiques en matière de processus
Il est important de dégager quelques règles permettant de

travailler efficacement
Ces bonnes pratiques sont :
– Un découpage logique et simple des tâches
– Une enclenchement efficace des tâches
– Une informatisation efficace des processus
– La mise sous contrôle des processus
– La révision périodique des processus
Il existe sûrement d’autres bonnes pratiques
mais elles sont moins vitales
78
Un découpage des tâches logique et simple
Les tâches sont la base de la construction

d’une organisation
Il est important d‘identifier sans ambiguïté les tâches
Les tâches doivent être faciles à repérer
Elles ont :
– Une durée de réalisation courte
– Un réalisateur
La plupart des tâches sont répétitives
Un salarié assure généralement moins de
Une enclenchement efficace des tâches
Les tâches ont des entrées (input) : des

commandes, des factures, des pièces comptables,…
Les tâches ont des sorties (output) : des bons de
commandes, des bons de livraison, des factures,…
La plupart des tâches ont en amont une ou plusieurs
tâches
La tâche alimente à son tour d’autres tâches
79
Une informatisation efficace des processus
Un nombre croissant de tâches sont effectuées à l’aide

de programmes informatiques
Domaine de la gestion
Applications bureautique, messagerie,…
Mythe de l’automatisation totale des tâches
En fait, il est nécessaire qu’il y ait des interventions
humaines à toutes les étapes d’un processus
La mise sous contrôle des processus
Pour améliorer l’efficacité des processus il

est nécessaire de les mettre sous contrôle
On va pour cela suivre différents indicateurs
significatifs concernant :
– La productivité
– L’efficacité
– Les délais
On s’attacher à se fixer des objectifs et à les comparer
aux réalisations
80
La révision périodique des processus
Si les indicateurs font apparaître des fragilités ou des

poches de sous-activités, il est possible d’améliorer la
solution en place
Même sans dérive il est nécessaire de revoir
périodiquement le fonctionnement des processus
On va pour cela reconstruire le processus
On doit pour cela suivre quelques grandes orientations :
– Réduire le nombre de tâches
– Mettre des tâches en parallèles
– Automatiser les tâches
– …
On doit s’attacher à effectuer cette révision périodique
Les points de contrôle en matière de processus
On doit vérifier le bon fonctionnement des processus

Les points de contrôle des process sont :
– L’efficacité globale des processus
– Le découpage des processus en tâches
– L’existence d‘un responsable de processus
– Le pilotage des processus
– La qualité de la documentation des processus
– La formation des salariés aux processus
Mais il est possible de trouver des points de contrôle en
matière de process
81
L’efficacité globale des processus
L’entreprise doit gérer ses processus

On doit s’attacher à :
– Individualiser les processus
– Suivre les volumes d’opérations traitées
– Evaluer les coûts unitaires des opérations
Les managers et les décideurs doivent surveiller ces
éléments et prendre régulièrement des décisions
L’auditeur doit s’attacher à vérifier que les processus
sont identifiés et sont pilotés
Il analyse les tableaux de bord ou la comptabilité
analytique pour apprécier l’efficacité des processus
Il évalue les décisions prises à partir de ces données
Le découpage des processus en tâches
L’entreprise doit disposer d’un dossier à jour décrivant

l’ensemble des processus (Qualité, ISO 9000/2000)
Ce dossier doit clairement faire apparaître l’ensemble des
tâches et leur organisation
Le découpage en tâches doit être rationnel et logique
L’auditeur doit évaluer la qualité des dossiers de
description des procédures
Il va analyser le degré de complétude des dossiers par
sondage
Il s’assure que les managers et les décideurs prennent
régulièrement des décisions concernant le découpage des
processus (rectification, remaniement, redéploiement,…)
82
L’existence d‘un responsable de processus
Il est nécessaire que chaque procédure importante ait un

responsable
Il faut lui donner les moyens d’agir sur l’ensemble du
processus
Le cas échéant, un comité de pilotage doit aider le
responsable à gérer efficacement ce processus
L’auditeur doit s’assurer que chacun des processus
principaux a un pilote et qu’il a effectivement les moyens
d’agir
On vérifie que les décisions sont prises à temps et qu’elles
permettent de corriger des dérives constatées
Le pilotage des processus
Chaque processus important doit être piloté

Pour cela, le responsable du processus doit disposer d’un
tableau de bord
Les objectifs a atteindre doivent être clairs et
atteignables
Les mesures doivent être simples et régulièrement
effectués
Le responsable de processus doit avoir à sa disposition
différents moyens d’actions
L’auditeur doit s’assurer que le processus dispose d’un
tableau de bord
Analyser les récentes décisions prises par le responsable
de processus à propos de cette procédure
83
La qualité de la documentation des processus
Il doit exister un documentation de chaque processus

Elle doit être claire
Elle doit être à jour
Elle doit être largement diffusée
Elle doit être comprise par tous les intervenants
L’auditeur doit s’assurer que la documentation de la
procédure est claire et complète
Il interroge un certain nombre de participants
intervenant sur le processus pour apprécier leur degré de
connaissance de la procédure
La formation des salariés aux processus
Il est nécessaire que l’ensemble du personnel

participant à
la procédure reçoive une formation adaptée
Ce peut être :
– Une formation spécialisée
– Une formation générale
– Une formation à l’outil informatique
Très souvent l’investissement formation est trop limité
et on n’a pas les résultats attendus
L’auditeur va analyser le plan formation : objectifs,
programmes, effectifs, suivi pédagogique,…
Mesurer le pourcentage d’opérateurs formés
Valider auprès de quelques participants le niveau des
compétences atteintes
84
Les recommandations en matière de processus
Il existe un grand nombre de recommandations possibles

concernant les processus
On peut les classer en 4 catégories :
– Les améliorations ponctuelles
– Les actions à la marge
– L’amélioration de l’informatisation
– La refonte des processus
L’auditeur doit être très attentif à l’établissement du plan
d’action
1 - Les améliorations ponctuelles
Ce sont des mesures simples ne touchant pas à l’application

informatique, généralement ce sont des mesures
d’organisation comme :
– Mettre en place des indicateurs d’activité
– Améliorer l’organisation des postes de travail
– Modifier l’ordre des opérations
– Mieux répartir la charge de travail
– Changer la répartition des tâches
– Ajouter un contrôle ou un pointage
– Enlever un contrôle inutile
– Faire corriger des erreurs dans les programmes de
saisie, de traitement ou de restitution
– Simplifier le classement des pièces
– ….
85
2 - Les actions à la marge
Dans certains cas on cherche à mieux utiliser les

possibilités offertes par le système en place sans chercher à
le changer :
– Faire modifier la structure de la base de données
– Améliorer les écrans de saisie
– Mettre en place de nouveaux contrôles des données,
des traitements, des bases de données,…
– Ajouter de nouvelles fonctions
– Prévoir de nouveaux contrôles globaux
– ….
Ce sont des modifications plus ou moins importantes des
traitements informatiques existants
3 - L’amélioration de l’informatisation
On décide dans ce cas de refondre l’application ou les

applications informatiques assurant le fonctionnement de
la procédure :
– Audit de l’application
– Schéma directeur
– Expression des besoins
– Cahier des charges
– …
Ce sont aussi des mesures comme :
– L’amélioration de l’exploitation
– L’optimisation du code
– Le développement des services (Help-desk,…)
– La formation aux applications
– ….
86
4 - La refonte des processus
Il est parfois nécessaire de reprendre l’ensemble du

processus et d’imaginer une nouvelle procédure
Ce sont toujours de grosses opérations
C’est souvent le seul moyen de dégager des gains de
productivité significatifs
Dans ce cas on va chercher à modifier des options
fondamentales
Il y a toujours un volet informatique plus ou moins
important et qui impose des délais
La refonte des processus est un véritable projet
Il est nécessaire d’avoir une véritable maîtrise
d’ouvrage
Construire le plan d’action concernant les processus
Il n’y a pas de révolution en ce domaine

Ce sont toujours des évolutions progressives
Il faut jouer le temps
Distinguer les trois plans :
– Le court terme. Ce sont des changements qui peuvent
être mise en place sans délai et sans investissement
– Le moyen terme. Il est nécessaire d’effectuer des
études complémentaires
– Le long terme. Il faut effectuer des investissements
lourds qui se traduisent par la remise en cause des choix
antérieurs
On attend de ces actions des progrès significatifs et
substantiels
87
Exemples de missions d’audit concernant les processus
Audit du processus comptable

Audit du processus de vente
Audit du processus comptable
La direction financière souhaite améliorer le fonctionnement

des processus comptables et particulièrement de la comptabilité
client
L’analyse fait apparaître un processus complexe
Les contrôles sont peu efficaces. Il n’y a pas de contrôles
globaux
Les tâches sont très parcellaires et le personnel a du mal à
avoir une vision d’ensemble de la procédure comptable
Renforcer les contrôles en place notamment pour les journées
Simplifier les opérations
Revoir les écrans de saisies (passer de 10 mn par pièce à 3 mn)
Former le personnel
Modifier les méthodes d’archivage (40 % de la charge de
travail)
88
Audit du processus de vente
L’entreprise de distribution précédente décide d’aller plus

loin et d’analyser l’ensemble de sa procédure de commande-
livraison-facturation de bout en bout
L’analyse détaillée fait apparaître 118 tâches au lieu des
26 indiquées dans la procédure ISO 9000
Il y a de nombreux retours en arrières
L’analyse statistiques des commandes montre qu’il faut en
moyenne 6,35 jours pour livrer une commande sur stock
L’application informatique demande trop d’interventions
d’utilisateurs
Pousser l’opération de simplification en supprimant 75
tâches
Regrouper l’ensemble des interventions manuelles en 5
étapes
Former ou reformer le personnel des agences et des
services commerciaux au processus
89

Audit SI

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Audit SI

Încărcat de

Drepturi de autor:

Formate disponibile

1-Audit : Definition et origines

Un audit est un processus permanent ou

Audit : Définition et origines

Une entreprise souhaite un audit d’une de ses

Cadre général de l’audit

La démarche est la même : approche par les risques.

Audit et Sécurité des Systèmes d’Informations

Efficacité : capacité à attendre les objectifs. Politique

Efficience : Ressources nécessaires de mise en œuvre des

Economie : les ressources pour mise en œuvre des

Sécurité : les ressources pour mise en œuvre des

Les demandeurs d'un audit de l'activité informatique

Les contrôleurs externes

Audit et Sécurité des Systèmes d’Informations

Les principales questions posées par les décideurs :

Les questions posées aux auditeurs informatiques sont

Elles peuvent porter :

Selon quelle démarche et avec quels outils ?

Pour auditer, il faut :

Un besoin clairement exprimé

Audit et Sécurité des Systèmes d’Informations

Les méthodes globales

Les méthodes « propriétaires"

Méthode accessible à tous,

Les principales méthodes d'audit de sécurité

Les principales méthodes d'audit de sécurité

Audit et Sécurité des Systèmes d’Informations

Les méthodes : Globales /Propriétaires

Les méthodes globales:

Les méthodes propriétaires

• Introduction à l'audit des systèmes d'information:

– L'audit d'un environnement informatique peut concerner l'évaluation des

– Par exemple, apprécier la disponibilité des informations et des systèmes. Le

– Un audit informatique (audit des systèmes d'information), se fait selon

• - Définition précise du plan de travail, récolte d'information, recherche et

– Un audit informatique (audit des systèmes d'information) ne concerne

– La démarche est très similaire, en choisissant et évaluant les

• Un Audit se concrétise toujours par un rapport : exemples

– Audit de l'environnement informatique :

• Mission : Evaluer les risques des systèmes d'information

• Livrables : Rapport contenant les faiblesses relevées, leur

• Un Audit se concrétise toujours par un rapport : exemples

– Audit d’une application informatique

• Mission : Evaluer les risques d'une application informatique.

• Livrables : Rapport contenant les faiblesses relevées, leur

• Un Audit se concrétise toujours par un rapport : exemples

– Audit d'une application en cours de développement :

• Mission : Assister l'équipe de projet à évaluer les risques

• Livrables : Mesures proposées de réduction et de contrôle

Il existe deux types d'audit informatique

2-l'audit de découverte des

L‘audit : dans quels buts ?

1.1-L'analyse de l'existant consiste en un travail de terrain au

L‘audit : dans quels buts ?

– 1.2-La détermination de la cible consiste à repérer :

– 2-Audit de Découverte des Connaissances (peu utilisé

• L'audit de découverte des connaissances consiste à valoriser les

• Un audit de découverte des connaissances aboutit généralement

L‘audit : dans quels buts ?

L'audit de découverte des connaissances se pratique de

• Pas d'objectifs : on ne sait pas ce que l'on va découvrir ;

– Les corrélations et liens retenus doivent répondre à trois critères :

L‘audit : dans quels buts ?

Si le test est passé, le modèle est mis en production