INTRODUCTION A L’AUDIT

INFORMATIQUE

Emmanuel GAVI
Année scolaire : 2019-2020
FICHE DE PRESENTATION DE COURS

TITRE DU COURS INTRODUCTION A l’AUDIT INFORMATIQUE

DUREE 36h
OBJECTIFS DU
COURS Ce cours comme intitulé constitue une introduction à l’audit informatique.
Il est destiné à faire acquérir les fondements de l’Audit Informatique et
permet aux étudiants de s’initier aux concepts de base des systèmes
d’information performante, aux risques liés au SI dans l’entreprise et aux
différentes normes de performance d’un SI, les référentiels d’audit
informatique tels que CobiT, ITIL….
A l’issue de ce cours, les étudiants doivent maîtriser les concepts et
démarches principaux nécessaires à la réalisation d’un audit
informatique.

PLAN DU COURS
INTRODUCTION

I- LES SYSTEMES INFORMATIQUES : ENJEUX ET RISQUE

1.1. Le système informatique

1.1.1. Définition
1.1.2. La performance d’un SI
1.2.3. Les Facteurs clefs d’un SI performant

1.2 Les risques informatiques

1.2.1. Généralités
1.2.2. Les principaux risques informatiques

II- L’AUDIT INFORMATIQUE

2.1 . Les concepts de base de l’audit informatique

2.2 . La démarche d’audit informatique
2.3 . Les référentiels d’audit informatique

III- LES DIFFRENTS TYPES D’AUDIT INFORMATIQUE

A- GOUVERNANCE INFORMATIQUE

3.1 . Audit de la fonction informatique

B- Acquisition Conception Implantation SI

2
 3.2. Audit des études informatiques
3.3. Audit des projets informatiques

C- Exploitation Entretien Soutien SI

3.4. Audit de l'exploitation

3.5. Audit des applications opérationnelles

D- Protection des Actifs Informationnels

3.6. Audit de la sécurité informatique

INTRODUCTION

L'audit informatique (en anglais Information Technology Audit ou IT Audit) a

pour objectif d’identifier et d’évaluer les risques (opérationnels, financiers, de
réputation notamment) associés aux activités informatiques d'une entreprise
ou d'une administration. À cette fin, l’audit va se baser sur le cadre
réglementaire du secteur d’activité du pays concerné, sur les référentiels de
bonnes pratiques existants (exemple le référentiel CobiT), sur les
benchmarks à disposition et sur l’expérience professionnelle des auditeurs
impliqués. Il existe deux grandes catégories d’audit. La première comporte
les audits globaux d'entité durant lesquels toutes les activités ayant trait aux
systèmes d’informations sont évaluées. La seconde catégorie correspond
aux audits thématiques, ayant pour objectif la revue d’un thème informatique
au sein d’une entité (la gestion de projet, la sécurité logique par exemple).
L’audit n’est pas à confondre avec l’activité de conseil qui vise, de manière
générale, à améliorer le fonctionnement et la performance d'une organisation
avec une éventuelle implication dans la mise en œuvre de cette amélioration.
Ces deux activités, audit et conseil, ne peuvent être exercées pour une entité
donnée par les mêmes acteurs afin de ne pas créer une situation favorable
aux conflits d’intérêts

3
 LES SYSTEMES INFORMATIQUES : ENJEUX ET RISQUE

1.1. LE SYSTEME INFORMATIQUE

1.1.1. DEFINITION

Le système informatique, appelé aussi système d’information, (noté SI)

représente l'ensemble des logiciels et matériels participant au stockage, à la
gestion, au traitement, au transport et à la diffusion de l'information au sein
de l'organisation.
La fonction informatique vise à fournir ces ressources à l’organisation.
Elle comprend donc, outre le système informatique, les personnes,
processus, ressources financières et informationnelles qui y
contribuent. Elle ne doit pas être confondue avec la fonction d’information,
ensemble organisé de personnes, de procédures et d’équipement qui a
pour objet de réunir, de trier, d’analyser, d’évaluer et de distribuer, en
temps utile, de l’information pertinente et valide, provenant de sources
internes et externes à l’organisation, afin que tous ceux qui ont à
prendre des décisions disposent des éléments leur permettant de
choisir l’action la plus appropriée au moment adéquat.
La fonction d’information, qui doit être pensée comme telle et non comme
une émanation de la fonction informatique, s’appuie évidemment sur des
ressources informatiques. En raison de la confusion fréquente entre ces
notions, les commanditaires attendent parfois des auditeurs SI un travail sur
la fonction d’information plus que sur le seul système informatique. Il convient
donc d’être très clair sur les attendus de l’audit. Un système informatique est
constitué de ressources matérielles et logicielles organisées pour collecter,
stocker, traiter et communiquer les informations. Les ressources humaines
nécessaires à son fonctionnement (par exemple les administrateurs) sont
parfois incluses dans ce périmètre. Le système informatique ne doit pas être
conçu comme une fin en soi : il est l’un des outils qui permet à l’organisation
d’atteindre ses objectifs. Il ne se justifie qu’en tant que soutien des processus
« métier », sans lesquels il n’a aucun sens. Il doit donc être aligné avec les
objectifs stratégiques de l’organisation. Cet alignement stratégique est
fondamental : désormais, un système informatique est un facteur déterminant
de la performance (efficacité, efficience, maîtrise des risques) d’une
organisation. Inversement, un système informatique inadapté ou mal maîtrisé
peut être une source inépuisable de difficultés. Les développements suivants
exposent, de manière synthétique, les principaux facteurs clés de la
performance du SI et les risques spécifiques qui pèsent sur son
fonctionnement.

1.1.2 LA PERFORMANCE DU SI
Le développement de services pertinents pour l’entreprise, la modernisation
des outils mis à disposition des agents, l’ouverture des données au profit

4
d’une meilleure transparence et de l’innovation doivent s’appuyer sur des
systèmes d’information performants.
Un SI idéal :
 est en adéquation avec la stratégie de l’organisation et les objectifs des
métiers ;
 est en conformité avec les obligations légales ;
 est sécurisé ;
 est fiable ;
 est adaptatif ;
 est pérenne ;
 est disponible ;
 est efficient ;
 respecte le plan d’urbanisme ;

1.1.3. LES FACTEURS CLEFS D’UN SI PERFORMANT

Les principaux facteurs clefs d’un SI performant sont les suivants :

 une forte implication de la direction dans la gestion du SI. Elle doit

notamment superviser la gestion du SI par la mise en place des outils de
pilotage suivants :
 un schéma directeur informatique (SDI), qui définit la stratégie
informatique pluriannuelle, dont la validation par la direction entérine
l’adéquation entre la stratégie informatique et la stratégie de l’entité ;
 des documents d’organisation de la gouvernance du SI, mis à jour
régulièrement ;
 des comités de pilotage informatiques réguliers (suivi des incidents,
suivi des projets, suivi des budgets, etc.), au sein desquels la direction
doit être représentée à bon niveau ;
 des tableaux de bord de suivi de l’informatique ;
 un portefeuille des projets SI et des analyses de la valeur des
systèmes d’information ;
 une politique de sécurité, approuvée au plus haut niveau de la
direction ;
 des comités de sécurité réguliers, au sein desquels la direction doit
être représentée à bon niveau ;

 une cartographie des applications et systèmes informatiques à jour,

incluse dans une politique d’urbanisme informatique. Cette
cartographie est fondamentale pour les auditeurs, les certificateurs ou
tout autre organisme de contrôle.

 une politique de sécurité, qui doit être validée et soutenue par la direction
de l’entité :
 la politique de sécurité des systèmes d’information (PSSI) constitue le
principal document de référence en matière de sécurité des systèmes

5
 d’information (SSI). Elle reflète la vision stratégique de l’entité et
montre l’importance qu’accorde la direction à la sécurité de son SI ;
 elle se matérialise par un document présentant, de manière ordonnée,
les règles de sécurité à appliquer et à respecter dans l’organisme. Ces
règles sont généralement issues d’une étude des risques SSI ;
 après validation, la PSSI doit être diffusée à l’ensemble des acteurs du
SI (utilisateurs, sous-traitants, prestataires…). Elle constitue alors un
véritable outil de communication sur l’organisation et les
responsabilités SSI, les risques SSI et les moyens disponibles pour
s’en prémunir ;
 la PSSI est un document vivant qui doit évoluer afin de prendre en
compte les transformations du contexte de l’organisme (changement
d’organisation, de missions...) et des risques (réévaluation de la
menace, variation des besoins de sécurité, des contraintes et des
enjeux) ;
 idéalement, il devrait exister une charte d’utilisation du système
d’information, dans le but de sensibiliser les utilisateurs à la sécurité
informatique, informer les utilisateurs des responsabilités qui leur
incombent. Pour une meilleure efficacité, cette charte devrait être
signée par tous les agents et une communication régulière sur le sujet
devrait être mise en place avec le support de la direction. Cette charte
contiendrait par exemple les règles de sécurité et de bon usage
(protection du PC, mots de passe, confidentialité, utilisation d’Internet,
de la messagerie, protection du PC, etc.), les normes relatives aux
logiciels (installation, licences, etc.), une description de la traçabilité
des actions sur le SI à laquelle chaque utilisateur est assujetti et les
sanctions applicables en cas de non-respect des règles décrites.

 le respect de la législation en matière de système d’information

 un paramétrage correct des droits d’accès aux applications informatiques

:
 les droits d’accès au SI doivent refléter les règles de séparation des
tâches telles que définies dans l’organisation ;
 au niveau informatique, les développeurs ne peuvent pas avoir accès à
l’environnement de production et le personnel d’exploitation ne peut
pas avoir accès à l’environnement de développement. Par ailleurs,
l’attribution de droits très élevés (« administrateurs ») doit être limitée et
toute action de ces profils « sensibles » doit être tracée et revue
régulièrement ;
 au niveau des applications informatiques, les droits d’accès attribués
doivent traduire de façon informatique les rôles de chacun dans
l’organisation. Chaque agent n’a accès qu’aux applications qui le
concernent dans sa fonction, et à l’intérieur des applications, il existe
des restrictions au niveau de chaque fonctionnalité, voire au niveau
des données ;

6
  les droits d’accès doivent faire l’objet d’une gestion rigoureuse, par un
service dédié. Ainsi, les demandes d’octroi de droit d’accès doivent être
formalisées et obligatoirement validées par les chefs de service. Les
déblocages en cas de perte de mot de passe doivent être organisés.
Enfin, la liste des habilitations, application par application, doit être
revue régulièrement, et les droits d’accès supprimés en cas de départ.

 une bonne gestion des projets de développements informatiques. La

réussite d’un projet informatique nécessite à minima les éléments suivants
:
 une vision claire de l’objectif et des résultats attendus ;
 l’implication de la direction générale ;

 une définition claire des responsabilités des parties prenantes ;

 l’implication des utilisateurs (« bureaux métiers ») ;
 la constitution d’une équipe projet dédiée dirigée par des cadres
expérimentés ;
 des choix techniques pérennes ;
 une gestion rigoureuse et organisée du projet ;
 un déploiement échelonné ;
 un suivi des risques ;
 un accompagnement du changement.

 un SI intégré :
Un SI est dit intégré quand toutes les applications communiquent entre elles
de façon automatique à l’aide d’interfaces. Ainsi, les informations ne sont
saisies qu’une seule fois dans les systèmes (notion de base de données
maîtresse) et les échanges de données font l’objet de contrôles d’intégrité
automatiques. L’action humaine, source potentielle d’erreurs ou de fraude,
est donc très limitée.

 Une démarche qualité informatique :

La mise en place d’une démarche qualité pour la gestion de la production et
le développement informatique permet d’améliorer les performances du
système d’information, de normaliser les procédures de gestion en fonction
des référentiels existants et d’améliorer les compétences des acteurs du
système d’information. Il existe en la matière de nombreux référentiels, dont
les principaux sont les suivants :
 CMMI (Capability Maturity Model + Integration) pour les
développements informatiques (avec plusieurs niveaux de certification
de 1 à 5) ;
 ITIL (Information Technology Infrastructure Library) : plus spécifique à
la gestion de la production informatique ;
 COBIT (Control Objectives for Information and related Technology) :
est un référentiel en matière de gouvernance informatique ;
 ISO 27001 (auparavant la BS7799) : présente les exigences en matière
de sécurité informatique ;
7
  Etc…

1.2. LES RISQUES INFORMATIQUES

1.2.1. GENERALITES

Les développements ci-dessous décrivent, pour chaque risque informatique,

les principaux facteurs de risque et les contrôles ou procédures qui doivent
être mis en place pour prévenir, réduire voire supprimer ce risque.
Pour mémoire, l’externalisation d’un service SI conduit à transférer les
risques, sans pour autant les couvrir de manière certaine. En matière
informatique, comme dans tous les autres domaines, l’externalisation d’un
risque ne dispense ainsi pas une organisation de s’assurer qu’il est
effectivement maîtrisé par son cocontractant et ne l’exonère en rien de sa
responsabilité finale.
Les principaux risques informatiques peuvent être regroupés en 3 domaines :
 les risques opérationnels, qui sont les plus nombreux pour le sujet
traité ;
 les risques financiers, puisque l’informatique et l’information sont des
actifs ;
 les risques légaux de non-conformité, puisque les entités sont
soumises à des normes internes et externes, certaines de portée
légale, concernant la gestion du SI.

1.2.2. LES PRINCIPAUX RISQUES INFORMATIQUES

Les principaux risques, facteurs de risques et dispositifs ou moyens de

contrôles des risques informatiques sont les suivants :
 Inadéquation du SI avec la stratégie de l’entité et les besoins des utilisateurs

 Facteurs de risque :
 manque d’implication de la direction dans la gestion de l’informatique
;
 absence de schéma directeur ;
 absence de gouvernance informatique ;
 manque d’implication des utilisateurs (« bureaux métiers ») dans les
projets informatiques ;
 absence d’analyse de la valeur des SI mis en place.
 Contrôles ou procédures attendus :
 supervision de l’informatique par la direction de l’entité ;
 existence d’une stratégie en adéquation avec la stratégie de
l’organisation, traduite par exemple dans un schéma directeur
informatique ;
 gouvernance informatique en place et validée par la direction ;
 analyse de la valeur (par exemple par MAREVA 2) ;

8
  forte implication des utilisateurs (« bureaux métiers ») dans les
projets informatiques.

 Incapacité de l’organisation à redémarrer les systèmes informatiques en

cas arrêt ou destruction

 Facteurs de risque :
 absence de sauvegarde régulière du SI (sauvegardes externes) ;
 absence de plan de secours ;
 absence de site de secours.
 Contrôles ou procédures attendus :
 mise en place d’un plan de secours (documenté, mis à jour lors de
modifications majeures de l’environnement informatique, et testé au
moins une fois par an) ;
 procédure de sauvegarde quotidienne des données et programmes
critiques ;
 stockage des sauvegardes à l’extérieur de l’entité ;
 les sauvegardes doivent être testées régulièrement ;
 lorsqu’une activité est fortement dépendante de l’informatique, mise
en place d’un site de secours.

 Sécurité du SI inadaptée au niveau de risque identifié et accepté par la

direction

 Les facteurs de risque sont multiples car la sécurité est transversale à

tous les processus de l’informatique :
 sécurité physique ;
 sécurité logique ;
 sécurité du réseau ;
 sécurité de l’exploitation ;
 sécurité des PC ;
 sécurité des données ;
 etc.
 Contrôles ou procédures attendus :
 politique de sécurité en place, validée et supportée par la direction de
l’entité ;
 outils de surveillance du système informatique (par exemple
supervision) ;
 équipe sécurité dédiée recensant tous les incidents relatifs à la
sécurité et capable d’intervenir en cas d’événement de sécurité.

 Accès aux données et aux applications par des personnes non

autorisées

 Facteurs de risque :

9
  absence de politique de sécurité ;
 absence de gestion rigoureuse d’attribution des droits d’accès ;
 absence de gestion rigoureuse des points d’accès ;
 systèmes informatiques ne permettant pas une gestion fine des droits
d’accès ;
 gestion des mots de passe insuffisante.
 Contrôles ou procédures attendus :
 politique de sécurité validée par la direction de l’entité ;
 politique de gestion des mots de passe efficace ;
 gestion rigoureuse des droits d’accès au système d’information en
cohérence avec la séparation fonctionnelle des tâches ;
 revue régulière de la liste des habilitations, application par application
;
 revue régulière des points d’accès ;
 séparation des tâches effective entre les fonctions développements
et exploitation ;
 supervision des profils sensibles alloués au personnel informatique ;
 traçabilité des accès et actions sensibles.

 Applications informatiques non fiables

 Facteurs de risque :
 erreurs dans la programmation des applications par rapport aux
spécifications fonctionnelles ;
 applications insuffisamment testées ;
 utilisateurs insuffisamment impliqués dans les phases de
développements de l’application.
 Contrôles ou procédures attendus :
 forte implication des utilisateurs dans les développements
informatiques ;
 bonne gestion de projet ;
 veille environnementale ;
 procédures de recensement des anomalies ;
 procédures de maintenances correctives, adaptatives et évolutives.

 Indisponibilité du système informatique

 Facteurs de risque :
 mauvaise gestion de l’environnement matériel du SI (énergie,
climatisation, protection physique, etc.) ;
 absence de convention de service ;
 absence d’outil de surveillance de la disponibilité du SI ;

10
  absence de cellule réactive en cas d’indisponibilité ;
 absence de contrat de maintenance des matériels informatiques.
 Contrôles ou procédures attendus :
 convention de service entre l’informatique et les utilisateurs, portant
notamment sur des objectifs de performance du SI, tels le niveau de
disponibilité des serveurs ;
 support utilisateur performant ;
 procédure de gestion des anomalies ;
 procédure de maintenance corrective des applications informatiques ;
 contrats de maintenance des matériels informatiques ;
 environnement matériel adapté ;
 plans de continuité et de reprise de l’activité.

 Mauvaise utilisation du SI par les utilisateurs

 Facteurs de risque :
 applications informatiques non conviviales ;
 utilisateurs insuffisamment formés ;
 documentation utilisateur insuffisante et pas mise à jour ;
 manque de contrôles bloquants dans les applications informatiques.
 Contrôles ou procédures attendus :
 applications faciles d’utilisation ;
 formation initiale des utilisateurs réalisée en temps utile et complétée
par une formation au fil de l’eau ;
 documentation utilisateur complète et mise à jour régulièrement ;
 contrôles bloquants dans les applications ;
 procédures de gestion des maintenances évolutives, adaptatives et
correctives.

 SI non conforme avec la législation

Les lois et décrets portant sur le renforcement des procédures de contrôles

internes concernent pour partie l’informatique. Les actions à mettre en place
font, pour la plupart, partie des recommandations déjà citées pour couvrir
certains risques informatiques comme :
 la politique de sécurité informatique ;
 la documentation informatique à jour ;
 la sécurité des développements informatiques ;
 la gestion rigoureuse des droits d’accès au SI.
• S’agissant des déclarations CNIL(en France), il est recommandé qu’une
personne soit spécifiquement désignée dans l’organisation pour gérer ce
sujet et l’anticiper. Elle doit notamment sensibiliser sur le sujet les services en
charge des développements informatiques.

 SI non pérenne

11
  Facteurs de risque :
 utilisation de la sous-traitance informatique sans transfert de
compétence en interne ;
 documentation informatique inexistante ou non mise à jour suite aux
évolutions du SI ;
 obsolescence de l’application et/ou de la technologie utilisée ;
 forte dépendance vis-à-vis de personnes clés qui peuvent quitter
l’entité.
 Contrôles ou procédures attendus :
 le SI doit faire l’objet d’un schéma directeur informatique ;
 la documentation informatique doit être complète et à jour,
notamment dans un contexte de forte utilisation de la sous-traitance ou
d’applications anciennes ;
 des procédures de transfert de compétence entre les sous-traitants et
les équipes informatiques internes doivent être mises en place.

 SI intégré

Les progiciels de gestion intégrés (PGI) constituent un cas particulier,

porteurs d’avantages, d’inconvénients et de risques spécifiques. Les PGI
(Entreprise Ressource Planning (ERP) en anglais) présentent ’avantage de
couvrir plusieurs domaines métiers d’une entreprise en une seule application
par l’intermédiaire de modules. Par exemple, le PGI le plus connu (« SAP »,
sur lequel repose CHORUS) intègre sous forme de modules les principales
fonctions suivantes :
 module FI (Financial) : comptabilité générale ;
 module CO (Controlling) : contrôle de gestion (comptabilité auxiliaire) ;
 module SD (Sales & Distribution) : administration des ventes ;
 module MM (Material Management) : achat et gestion des stocks ;
 module PP (Production Planning) : gestion de la production ;
 module RE (Real Estate) : gestion immobilière.

Les principaux avantages des PGI sont les suivants :

 réduction des délais administratifs ;
 saisie unique dans le SI de l’organisation ;
 disponibilité immédiate de l’information ;
 piste d’audit « garantie » en principe ;
 la réduction des coûts informatiques est parfois mise en avant, malgré
un investissement initial élevé.
En contrepartie, certaines exigences sont généralement imposées par la
mise en place d’un PGI :
 mise en œuvre rigoureuse et exigeante en matière d’intégration, de
paramétrage et de développements spécifiques potentiellement
coûteux, y compris dans la durée ;

12
  revue de l’architecture technique pouvant conduire au remplacement
des infrastructures matérielles et réseaux ;
 une adéquation des processus et de l’organisation au PGI pouvant
offrir une opportunité de transformation si cette dernière est anticipée et
pilotée ou a contrario constituer un frein au projet si elle n’est pas
souhaitée et assumée ;
 partage de l’information pouvant entraîner un rejet de la part de
certains acteurs ;
 maîtrise globale de la solution dans le temps car des incidents peuvent
bloquer toute l’entité.

Les risques liés aux PGI sont les suivants :

 dérapage des projets (dans le temps et dans les coûts) compte tenu de
la complexité et des enjeux ;
 les développements de programmes « spécifiques » éloignent l’outil du
standard ce qui entraîne des problèmes de maîtrise du PGI voire des
problèmes en termes d’auditabilité (altération possible de la piste
d’audit) ;
 une inadaptation in fine du PGI à l’organisation dans le cas où la
refonte des processus n’a pas été préalablement conduite et portée par
la direction générale ;
 utilisateurs insuffisamment formés qui rejettent l’application ;
 forte dépendance vis-à-vis du sous-traitant et insuffisance de transfert
de compétence en interne sur le PGI ;
 paramétrage des droits d’accès et des profils utilisateurs souvent
galvaudé lors de la phase de développement.
Conformément aux pratiques de l’audit, ces risques sont habituellement
analysés à travers une matrice des risques spécifique.

13
 L’AUDIT INFORMATIQUE

2 .1. Les concepts de base

La notion de contrôle est au cœur de la démarche d'audit informatique.
L'objectif est de mettre en place des dispositifs de contrôle efficaces et
performants permettant de maîtriser efficacement l'activité informatique.
Le contrôle interne est un processus mis en œuvre à l'initiative des dirigeants
de l'entreprise et destiné à fournir une assurance raisonnable quant à la
réalisation des trois objectifs suivants :
1. la conformité aux lois et aux règlements,
2. la fiabilité des informations financières,
3. la réalisation et l'optimisation des opérations.
Il est évident que l'audit informatique s’intéresse surtout au troisième objectif.
La démarche d'audit informatique se définit à partir des préoccupations du
demandeur d'audit qui peut être le directeur général, le directeur
informatique, le directeur financier,… Il va pour cela mandater l'auditeur pour
répondre à une liste de questions précises qui font, plus ou moins
implicitement, référence à l'état des bonnes pratiques connues dans ce
domaine. Cela se traduit par un document important : la lettre de mission ou
la charte d’audit qui précise le mandat à exécuter et qui donne les pouvoirs
nécessaires à l'auditeur. Celui-ci va ensuite s’attacher à relever des faits puis
il va mener des entretiens avec les intéressés concernés. Il va ensuite
s’efforcer d'évaluer ses observations par rapport à des référentiels largement
reconnus. Sur cette base il va proposer des recommandations. L'auditeur
informatique va se servir de référentiels d'audit informatique lui donnant l'état
des bonnes pratiques dans ce domaine. Le référentiel de base est CobiT :
Control Objectives for Information and related Technology. Mais il va aussi
utiliser d'autres référentiels comme : Val IT,Risk IT, CobiT and Applications
Controls, ISO 27002,

2.2. La Démarche d’Audit Informatique

Une mission d'audit informatique se prépare. Il convient de déterminer un
domaine d'études pour délimiter le champ d'investigation. En ce sens il est
conseillé d'effectuer un pré-diagnostic afin de préciser les questions dont
l'audit va traiter. Cela se traduit par l'établissement d'une lettre de mission
détaillant les principaux points à auditer.
Pour mener à bien l'audit informatique il est recommandé de suivre six
étapes suivantes :
1. l'établissement de la lettre de mission : Ce document est rédigé et
signé par le demandeur d'audit et permet de mandater l'auditeur. Il sert
à identifier la liste des questions que se pose le demandeur d'audit.
Très souvent l'auditeur participe à sa rédaction.
2. la planification de la mission permet de définir la démarche détaillée qui
sera suivie. Elle va se traduire par un plan d'audit ou une proposition
commerciale. Ce document est rédigé par l'auditeur et il est soumis à la
14
 validation du demandeur d'audit. Une fois le consensus obtenu il est
possible de passer à la troisième étape,
3. la collecte des faits, la réalisation de tests, … Dans la plupart des
audits c'est une partie importante du travail effectué par les auditeurs. Il
est important d'arriver à dégager un certain nombre de faits
indiscutables,
4. les entretiens avec les audités permettent de compléter les faits
collectés grâce à la prise en compte des informations détenues par les
opérationnels. Cette étape peut être délicate et compliqué. Souvent, les
informations collectés auprès des opérationnels ressemblent plus à des
opinions qu'à un apport sur les faits recherchés,
5. la rédaction du rapport d'audit est un long travail qui permet de mettre
en avant des constatations faites par l'auditeur et les recommandations
qu'il propose,
6. la présentation et la discussion du rapport d'audit au demandeur
d'audit, au management de l'entreprise ou au management de la
fonction informatique. Il peut arriver qu'à la suite de la mission d'audit il
soit demandé à l'auditeur d'établir le plan d'action et éventuellement de
mettre en place un suivi des recommandations. Le non-respect de
cette démarche peut entrainer une mauvaise réalisation et mise en
place d'outils qui ne sont pas conformes aux réels besoins de
l'entreprise.
Cette démarche est essentielle pour l'auditeur car il lui apporte des éléments
fondamentaux pour le déroulement de sa mission mais celle-ci est encore
plus bénéfique pour l'organisation. En effet, les acteurs audités ne sont pas
passifs. Ils sont amenés à porter une réflexion sur leurs méthodes de travail
et à s’intéresser au travail des autres acteurs de l'entité. Cela conduit à une
cohésion d'équipe et à un apprentissage organisationnel. Il s’agit d'un facteur
positif car en cas de changement les acteurs seront moins réticents.
2.3. Les référentiels d'audit informatique
Il existe différents référentiels comme :
 CobiT : Control Objectives for Information and related Technology.
C'est le principal référentiel des auditeurs informatiques.
 Val IT permet d'évaluer la création de valeur par projet ou par
portefeuille de projets,
 Risk IT a pour but d'améliorer la maîtrise des risques liés à
l'informatique (Voir page en anglais http://en.wikipedia.org/wiki/Risk_IT
),
 CobiT and Applications Controls. Voir les sites de l'ISACA Information
Systems Audit
& Control Association qui est l'association internationale des auditeurs
informatiques et de l'AFAI Association
Française de l'Audit et du conseil Informatique, qui est le chapitre français de
l'ISACA.
Mais on peut aussi utiliser d'autres référentiels comme :

15
 ISO 27002 qui est un code des bonnes pratiques en matière de
management de la sécurité des systèmes d'information,
 CMMi : Capability Maturity Model integration qui est une démarche
d'évaluation de la qualité de la gestion de projet informatique,
 ITIL qui est un recueil des bonnes pratiques concernant les niveaux et
de support des services informatiques.

16
 LES DIFFRENTS TYPES D’AUDIT INFORMATIQUE

La démarche d'audit informatique est générale et s’applique à différents

domaines comme la fonction informatique, les études informatiques, les
projets informatiques, l'exploitation, la planification de l'informatique, les
réseaux et les télécommunications, la sécurité informatique, les achats
informatiques, l'informatique locale ou l'informatique décentralisée, la qualité
de service, l'externalisation, la gestion de parc, les applications
opérationnelles…ISACA regroupe tous ces domaines à auditer sous 5
chapitre en partant :
- Le processus d’audit des systèmes d’information qui englobe la
démarche complète d’audit, y compris les processus et la méthodologie
approfondie, qui permet à un auditeur des SI d’effectuer l’audit de
n’importe quel secteur de l’informatique de manière professionnelle.
- La gouvernance et la gestion des TI : Elles font partie intégrante de
la gouvernance d’entreprise et consistent en des structures de direction
et des processus qui garantissent que les TI soutiennent et prolongent
les stratégies et les objectifs de l’organisation. La connaissance de la
gouvernance des TI est essentielle au travail du vérificateur des SI. Elle
constitue une fondation pour le développement de pratiques et de
mécanismes de contrôle solide au service des activités de surveillance
et d’examen de la direction
- l’acquisition, la conception et l’implantation des systèmes
d’information qui donne un aperçu des processus et méthodologies
clés utilisés par les organisations lors de la création et de la
modification d’éléments des systèmes d’applications et de
l’infrastructure
- L’exploitation, l’entretien et le soutien des SI : très importantes pour
garantir aux utilisateurs et aux gestionnaires que les services
escomptés seront rendus. Les attentes relatives au niveau de service
découlent des objectifs d’affaires de l’organisation. La prestation des
services TI comprend les activités des SI, les services des TI ainsi que
la gestion des SI et des groupes responsables de leur soutien.
- Protection des Actifs Informationnels : aborde les éléments clés qui
assurent la confidentialité, l’intégrité et la disponibilité des actifs
informationnels. On y évalue la conception, l’implantation et la
surveillance des mesures de contrôle d’accès physique et logique
permettant d’assurer la CID (CIA en englais). Il évalue aussi la sécurité
de l’infrastructure réseau, les contrôles et les processus
environnementaux ainsi que les procédures utilisées pour classifier,
stocker, récupérer, transporter des actifs informationnels confidentiels
et en disposer. On y décrit les diverses méthodes et procédures suivies
par les organisations en insistant sur le rôle de l’auditeur dans
l’évaluation de leur caractère adéquat et de leur efficacité.

17
L’audit global des SI prendra en compte tous les domaines ci-dessous
énumérés. Les paragraphes qui suivent présentent les audits informatiques
sur les thèmes les plus fréquents.
3.1 Audit de la fonction informatique
Le but de l'audit de la fonction informatique est de répondre aux
préoccupations de la direction générale ou de la direction informatique
concernant l'organisation de la fonction informatique, son pilotage, son
positionnement dans la structure, ses relations avec les utilisateurs, ses
méthodes de travail…
Pour effectuer un audit de la fonction informatique on se base sur les bonnes
pratiques connues en matière d'organisation de la fonction informatique. Elles
sont nombreuses et bien connues, parmi celles-ci on peut citer :
 la clarté des structures et des responsabilités de l'équipe informatique,
 la définition des relations entre la direction générale, les directions
fonctionnelles et opérationnelles et la fonction informatique,
 l'existence de dispositifs de mesures de l'activité et notamment d'un
tableau de bord de la fonction informatique,
 le niveau des compétences et des qualifications du personnel de la
fonction.
Il existe de nombreuses autres bonnes pratiques concernant la fonction
informatique. L'audit de la fonction se base sur ces pratiques dans le but
d'identifier un certain nombre d'objectifs de contrôle comme :
 le rôle des directions fonctionnelles et opérationnelles dans le pilotage
informatique et notamment l'existence d'un comité de pilotage de
l'informatique,
 la mise en œuvre de politiques, de normes et de procédures
spécifiques à la fonction,
 la définition des responsabilités respectives de la fonction informatique
et des unités utilisatrices concernant les traitements, la maintenance, la
sécurité, les investissements, les développements,….
 l'existence de mécanismes permettant de connaître et de suivre les
coûts informatiques, soit à l'aide d'une comptabilité analytique, soit, à
défaut, grâce à un mécanisme de refacturation,
 le respect des dispositifs de contrôle interne comme une évaluation
périodique des risques, la mesure de l'impact de l'informatique sur les
performances de l'entreprise…
Ces différents objectifs de contrôle correspondent au processus PO 4 de
CobiT : “Définir les processus, l'organisation et les relations de travail”.
3.2 Audit des études informatiques
L'audit des études informatiques est un sous-ensemble de l'audit de la
fonction informatique. Le but de cet audit est de s’assurer que son
organisation et sa structure sont efficaces, que son pilotage est adapté, que
ses différentes activités sont maîtrisées, que ses relations avec les
utilisateurs se déroulent normalement,…

18
Pour effectuer un audit des études informatiques on se base sur la
connaissance des bonnes pratiques recensées dans ce domaine. Elles sont
nombreuses et connues par tous les professionnels. Parmi celles-ci on peut
citer :
 l'organisation de la fonction études en équipes, le choix des personnes
et leur formation, leurs responsabilités … ;
 la mise en place d'outils et de méthodes adaptés notamment une claire
identification des tâches, des plannings, des budgets, des dispositifs de
suivi des études, un tableau de bord… ;
 le contrôle des différentes activités qui ne peuvent pas être planifiées
comme les petits projets, les projets urgents… ;
 la mise sous contrôle de la maintenance des applications
opérationnelles ;
 le suivi des activités d'études à partir de feuilles de temps.
Il existe de nombreuses autres bonnes pratiques concernant les études
informatiques. Pour l'auditer on va se baser sur ces bonnes pratiques afin de
dégager un certain nombre d'objectifs de contrôle comme :
 l'évaluation de l'organisation de la fonction d'études informatiques et
notamment la manière dont sont planifiées les différentes activités
d'études ;
 le respect de normes en matière de documentation des applications et
notamment la définition des documents à fournir avec les différents
livrables prévues ;
 le contrôle de la sous-traitance notamment la qualité des contrats, le
respect des coûts et des délais, la qualité des livrables… ;
 l'évaluation de la qualité des livrables fournis par les différentes
activités d'études qui doivent être testables et vérifiables ;
Il existe de nombreux autres objectifs de contrôle concernant les études
informatiques et ils sont choisis en fonctions des préoccupations du
demandeur d'audit.

3.4 Audit des projets informatiques

L'audit des projets informatiques est un audit dont le but est de

s’assurer qu'il se déroule normalement et que l'enchaînement des opérations
se fait de manière logique et efficace de façon qu'on ait de fortes chances
d'arriver à la fin de la phase de développement à une application qui sera
performante et opérationnelle. Comme on le voit un audit d'un projet
informatique ne se confond pas avec un audit des études informatiques.
Pour effectuer un audit d'un projet informatique on se base sur la
connaissance des bonnes pratiques connues en ce domaine. Elles sont
nombreuses et connues par tous les chefs de projets et de manière plus
générale par tous professionnels concernés. Parmi celles-ci on peut citer :
 l'existence d'une méthodologie de conduite des projets,
 la conduite des projets par étapes quel que soit le modèle de gestion de
projets : cascade, V, W ou en spirale (processus itératif),

19
  le respect des étapes et des phases du projet,
 le pilotage du développement et notamment les rôles respectifs du chef
de projet et du comité de pilotage,
 la conformité du projet aux objectifs généraux de l'entreprise,
 la mise en place d'une note de cadrage, d'un plan de management de
projet ou d'un plan de management de la qualité,
 la qualité et la complétude des études amont : étude de faisabilité et
analyse fonctionnelle,
 l'importance accordée aux tests, notamment aux tests faits par les
utilisateurs.
Il existe de nombreuses autres bonnes pratiques concernant la gestion de
projet. Pour effectuer un audit d'un projet informatique on va se baser sur un
certain nombre d'objectifs de contrôle comme :
 la clarté et l'efficacité du processus de développement,
 l'existence de procédures, de méthodes et de standards donnant des
instructions claires aux développeurs et aux utilisateurs,
 la vérification de l'application effective de la méthodologie,
 la validation du périmètre fonctionnel doit être faite suffisamment tôt
dans le processus de développement,
 la gestion des risques du projet. Une évaluation des risques doit être
faite aux étapes clés du projet.
Il existe de nombreux autres objectifs de contrôle possibles concernant l'audit
de projet informatique qui sont choisis en fonction des préoccupations et des
attentes du demandeur d'audit.
Ces différents objectifs de contrôle correspondent aux processus PO 10, AI 1
et AI 2 de CobiT :
PO 10 “Gérer le projet” mais aussi AI 1 “Trouver des solutions informatiques”
et AI 2 “Acquérir des applications et en assurer la maintenance”.

3.3 Audit de la production informatique

L'audit de l'exploitation a pour but de s’assurer que le ou les différents

centres de production informatiques fonctionnent de manière efficace et qu'ils
sont correctement gérés. Il est pour cela nécessaire de mettre en œuvre des
outils de suivi de la production comme Openview d'HP, de Tivoli d'IBM,… Il
existe aussi un système Open Source de gestion de la production comme
Nagios.
Ce sont de véritables systèmes d'information dédiés à l'exploitation.
Pour effectuer un audit de l'exploitation on se base sur la connaissance des
bonnes pratiques concernant ce domaine comme :
 la clarté de l'organisation de la fonction notamment le découpage en
équipes, la définition des responsabilités,…
 l'existence d'un système d'information dédié à l'exploitation notamment
pour suivre la gestion des incidents, la gestion des ressources, la
planification des travaux, les procédures d'exploitation,…
20
  la mesure de l'efficacité et de la qualité des services fournies par
l'exploitation informatique.
Il existe de nombreuses autres bonnes pratiques concernant l'exploitation
informatique. Pour effectuer cet audit on va se baser sur ces bonnes
pratiques afin de dégager un certain nombre d'objectifs de contrôle comme :
 la qualité de la planification de la production,
 la gestion des ressources grâce à des outils de mesure de la charge,
des simulations, le suivi des performances,…
 l'existence de procédures permettant de faire fonctionner l'exploitation
en mode dégradé de façon à faire face à une indisponibilité totale ou
partielle du site central ou du réseau,
 la gestion des incidents de façon à les repérer et le cas échéant
d'empêcher qu'ils se renouvellent,
 les procédures de sécurité et de continuité de service qui doivent se
traduire par un plan de secours,
 la maîtrise des coûts de production grâce à une comptabilité analytique
permettant de calculer les coûts complets des produits ou des services
fournis.
Ces différents objectifs de contrôle correspondent au processus DS 1, DS 3,
DS 6, DS 12 et DS 13 de CobiT : DS 1 “Définir et gérer les niveaux de
services”,
DS 3 “Gérer la performance et la capacité",
DS 6 “Identifier et imputer les coûts”,
DS 12 “Gérer l'environnement physique”,
DS 13 “Gérer l'exploitation”.

3.5 Audit des applications opérationnelles

Les audits précédents sont des audits informatiques, alors que l'audit
d'applications opérationnelles couvre un domaine plus large et s’intéresse au
système d'information de l'entreprise. Ce sont des audits du système
d'information. Ce peut être l'audit de l'application comptable, de la paie, de la
facturation,…. Mais, de plus en plus souvent, on s’intéresse à l'audit d'un
processus global de l'entreprise comme les ventes, la production, les achats,
la logistique,…
Il est conseillé d'auditer une application de gestion tous les deux ou trois ans
de façon à s’assurer qu'elle fonctionne correctement et, le cas échéant
pouvoir apporter les améliorations souhaitables à cette application ou à ce
processus. L'auditeur va notamment s’assurer du respect et de l'application
des règles de contrôle interne. Il va en particulier vérifier que :
 les contrôles en place sont opérationnels et sont suffisants,
 les données saisies, stockées ou produites par les traitements sont de
bonnes qualités,
 les traitements sont efficaces et donnent les résultats attendus,
 l'application est correctement documentée,

21
  les procédures mises en oeuvre dans le cadre de l'application sont à
jour et adaptées,
 l'exploitation informatique de l'application se fait dans de bonnes
conditions,
 la fonction ou le processus couvert par l'application est efficace et
productif, …
Le but de l'audit d'une application opérationnelle est de donner au
management une assurance raisonnable sur son fonctionnement. Ces
contrôles sont, par exemple, réalisés par le Commissaire aux Comptes
dans le cadre de sa mission légale d'évaluation des comptes d'une
entreprise : est-ce que le logiciel utilisé est sûr, efficace et adapté ? Pour
effectuer l'audit d'une application opérationnelle on va recourir aux
objectifs de contrôle les plus courants :
 le contrôle de la conformité de l'application opérationnelle par rapport à
la documentation utilisateur, par rapport au cahier des charges
d'origine, par rapport aux besoins actuels des utilisateurs,
 la vérification des dispositifs de contrôle en place. Il doit exister des
contrôles suffisants sur les données entrées, les données stockées, les
sorties, les traitements,… L'auditeur doit s’assurer qu'ils sont en place
et donnent les résultats attendus,

 l'évaluation de la fiabilité des traitements se fait grâce à l'analyse des
erreurs ou des anomalies qui surviennent dans le cadre des opérations
courantes. Pour aller plus loin l'auditeur peut aussi être amené à
constituer des jeux d'essais pour s’assurer de la qualité des
traitements. Il est aussi possible d'effectuer des analyses sur le contenu
des principales bases de données afin de détecter d'éventuelles
anomalies,
 la mesure des performances de l'application pour s’assurer que les
temps de réponse sont satisfaisants même en période de forte charge.
L'auditeur va aussi s’intéresser au nombre d'opérations effectuées par
le personnel dans des conditions normales d'utilisation.
Très souvent on demande à l'auditeur d'évaluer la régularité, la conformité, la
productivité, la pérennité de l'application opérationnelle. Ce sont des
questions délicates posées par le management à l'auditeur.

3.6 Audit de la sécurité informatique

L'audit de la sécurité informatique a pour but de donner au management une

assurance raisonnable du niveau de risque de l'entreprise lié à des défauts
de sécurité informatique. En effet, l'observation montre que l'informatique
représente souvent un niveau élevé pour risque élevé de l'entreprise. On
constate actuellement une augmentation de ces risques liée au

22
développement d'Internet. Ils sont liés à la conjonction de quatre notions
fondamentales :
1. en permanence il existe des menaces significative concernant la
sécurité informatique de l'entreprise et notamment ses biens
immatériels,
2. le facteur de risque est une cause de vulnérabilité due à une faiblesse
de l'organisation, des méthodes, des techniques ou du système de
contrôle,
3. la manifestation du risque. Tôt ou tard le risque se manifeste. Il peut
être physique (incendie, inondation) mais la plupart du temps il est
invisible et se traduit notamment par la destruction des données,
détournement de trafic,..
4. la maîtrise du risque. Il s’agit de mettre en place des mesures
permettant de diminuer le niveau des risques notamment en renforçant
les contrôles d'accès, l'authentification des utilisateurs,…
Pour effectuer un audit de sécurité informatique il est nécessaire de se baser
sur quelques objectifs de contrôle. Les plus courants sont :
 repérer les actifs informationnels de l'entreprise. Ce sont des matériels
informatiques, des logiciels et des bases de données. Il est pour cela
nécessaire d'avoir des procédures de gestion efficaces et adaptées,
 identifier les risques. Il doit exister des dispositifs de gestion adaptés
permettant de surveiller les domaines à risque. Cette surveillance doit
être assurée par un RSSI, un responsable de la sécurité informatique,
 évaluer les menaces. Le RSSI a la responsabilité de repérer les
principaux risques liés aux différents domaines du système
d'information. Un document doit recenser les principales menaces,
 mesurer les impacts. Le RSSI doit établir une cartographie des risques
associés au système d'information. Il est alors envisageable de
construire des scénarios d'agression et d'évaluer les points de
vulnérabilité,
 définir les parades. Pour diminuer le niveau des risques il est
nécessaire de prévoir les dispositifs comme des contrôles d'accès, le
cryptage des données, le plan de secours,…
Il existe de nombreux autres objectifs de contrôle concernant l'audit de la
sécurité informatique qui sont choisis en fonction des préoccupations et des
attentes du demandeur d'audit.
Ces différents objectifs de contrôle correspondent aux processus de CobiT
DS 5 : “Assurer la sécurité des systèmes” et PO 9 “Evaluer et gérer les
risques”. Il existe un référentiel spécifique à la sécurité informatique : ISO
27002. C'est un code des bonnes pratiques concernant le management de la
sécurité des systèmes d'information. Il est complété par la norme ISO 27001
concernant la mise en place d'un Système de management de la sécurité de
l'Information.

23