Cours SI M2

AUDIT DES SYSTEMES
D’INFORMATION
Présenté par :
SASSA Giquel Thérance
Certifié: COBIT5 – Big Data – Scrum Master – Prince2
OBJECTIFS
Acquérir les fondements de l’audit des systèmes

d’information
Initier les apprenants aux principaux concepts

généraux liés à l’évaluation des SI.
PLAN
I. GENERALITES SUR LES SI
II. DEFINITION DE L’AUDIT DES SI
III. RISQUES LIÉS AUX SI
IV. MISSIONS DES AUDITS SI
V. MÉTHODOLOGIES D’AUDITS DES SI
VI. RÉFÉRENCES ET NORMES
VII. CATÉGORIES D’AUDITS DES SI
VIII.APPROCHE D’AUDIT DES PRINCIPAUX DOMAINES DES SI
IX. FACILITATEURS D’AUDITS DES SI
X. MODÈLE DE LA STRUCTURE D’UN RAPPORT D’AUDIT DES SI
I- GENERALITES SUR LES SI
 Les systèmes d'information sont au cœur des industries de

transformation et de production. Il permet l’échange des données
entre les départements/fonctions de l'entreprise.
 A travers les réseaux qui ont de plus en plus une architecture

distribuées, le SI est devenu une ressource essentielle dans le domaine
d’activités stratégiques de toutes entreprises.
 Son bon fonctionnement contribue à la performance de

l’organisation
I- GENERALITES SUR LES SI
▪ Les SI sont aujourd'hui un support essentiel de l’organisation et le moteur

de son évolution dans un environnement de plus en plus complexe et
mouvant
▪ Le SI est de nos jours reconnu dans la théorie du management

stratégique comme une variable clé de la compétitivité de l'entreprise,
tant sur le court et moyen terme (processus de production) que sur le
long terme (processus d'innovation)
▪ Le système d’information a pour finalité d’offrir un meilleur service aux

utilisateurs et de contribuer à la performance de l’organisation
COMPANY NAME
ABS.COM
I-PutGENERALITES SUR LES SI
a relevant subtitle in this line
Un SI est l’ensemble de ressources (matériel, logiciel,

données, humaine, procédure, etc) structuré pour acquérir,
traiter, mémoriser, transmettre et rendre disponible
l’information (sous forme de données, sons, texte, image,
etc ) dans et entre les organisations
Robert Reix (1934-2006), Systèmes d’information et management des organisations
COMPANY NAME
ABS.COM
I-PutGENERALITES SUR LES SI
a relevant subtitle in this line
Interactions des sous-systèmes à travers des services

COMPANY NAME
ABS.COM
I-Put
GENERALITES
a relevant subtitleSUR
in thisLES
line SI
4- Les SI Standardisé : Caractéristiques

Structure : en couche/urbanisé
Couts : Centre d’investissement pour l’entreprise
Objectifs : Alignement aux orientations de la structure

Contribution : Aide à la productivité des métiers et à la décision
Technique : Tient compte des contraintes technologiques de développement , de

maintenance ou d’exploitation
Sécurité : Politique de securité existante
Réglémentation : Conformité reglementaire interne et externe
Communication : claire les métiers et les services de l’entreprise à travers les SLA
Stockage : Capacité de stockage illimité

Traçabilité : Visibilité
COMPANY NAME
ABS.COM
I-Put
GENERALITES
a relevant subtitleSUR
in thisLES
line SI
L’ensemble des progiciels utilisés dans une

entreprises constitue la partie dématérialisée du
SI
≠
du système informatique de l’entreprise
II- DEFINITION DE L’AUDIT DES SI
 Le Petit Larousse définit l’audit comme « une procédure consistant

à s'assurer du caractère complet, sincère et régulier des comptes
d'une entreprise, à s'en porter garant auprès des divers partenaires
intéressés de la firme et, plus généralement, à porter un jugement
sur la qualité et la rigueur de sa gestion. »
 L’audit des SI diffère fortement de l’audit financier ou opérationnel,

qui s’intéresse aux risques endémiques dans un secteur donné ou
d’une organisation
 L’audit est une méthode d’évaluation rigoureuse qui possède sa propre

norme : le respect des normes et des standards en matière de maîtrise de
techniques d’audit est décrit dans la norme ISO 19011 appelée « Lignes
directrices pour l’audit des systèmes de management : conseils pour le
management d’un programme d’audit, les activités de l’audit et les
compétences des auditeurs ».
 L'audit des systèmes d'information évalue les risques liés à l’environnement

du SI notamment la sécurité (physique, logique, réseau) , la gestion des
changements, les processus, le plan de secours, I’infrastructure, les
données, les projets, etc.
 Un audit régulier des systèmes entre en effet à l’intérieur d’une

démarche qualité continue, pour rester compétitif et atteindre ses
objectifs stratégiques.
 L'audit des systèmes d'information évalue les risques liés à

l’environnement du SI notamment la sécurité (physique, logique,
réseau) , la gestion des changements, les processus, le plan de
secours, I’infrastructure, les données, les projet, etc.
III- RISQUES LIES AUX SI
Illustration : Théorie du flocon de neige

 Les entreprises A et X opèrent toutes deux dans le secteur des médias. Elles sont
toutes deux exposées à un risque lors du calcul des gains pour les prestations
offertes. L’audit interne s’intéresserait forcément à ce processus.
 A utilise un système centralisé de gestion de ses prestations.
 X est dotée d’un décentralisée, et chacune des entités utilise son propre système,
sur diverses plateformes. Chacune communique ses données à un système de
consolidation.
 L’audit du SI pour la société A différera de celui de la société X en raison des
différences des environnements des SI. Il sera donc difficile d’adopter une
approche générique d’audit des SI
 Chaque environnement de SI est unique, et représente donc un ensemble de
risques unique, selon la théorie du flocon de neige.
III-RISQUES LIES AUX SI
Illustration : Théorie du flocon de neige
Plusieurs variable permettent de renforcer la théorie du flocon de
neige à savoir :
▪ La configuration des processus
▪ Le degré de centralisation du système
▪ Le degré de centralisation géographique
▪ Le nombre de serveurs
▪ Le choix des technologies d’infrastructure
▪ Le degré de personnalisation
▪ La structure organisationnelle de la direction en charge des SI.
Illustration : Théorie du flocon de neige :
 Les versions de la technologie utilisée
 Le degré et la méthode d’externalisation
 La politique de l’entreprise (on conserve tous les e-mails
indéfiniment ou on n’en conserve aucun)
 L’environnement d’un SI est propre aux spécificités du SI
 L'audit des SI a pour objectif d’identifier, d’évaluer et déterminer
les risques (opérationnels, financiers, de réputation…) associés
aux activités informatiques d'une organisation
Quelques facteurs liés aux problèmes des SI :
▪ Fiabilité/Disponibilité : le système n’est pas disponible pour utilisation.
▪ Intégrité/Sécurité : accès non autorisé au système
▪ Fiabilité, Conformité/ Intégrité: données incomplètes ou inexactes
▪ Fiabilité/Confidentialité : l’information n’est pas conservée secrète
▪ Fiabilité/Efficacité : le système ne procure pas une fonction voulue ou
attendue
▪ Efficience : le système entraîne une utilisation sous-optimale des
ressources
III - RISQUES LIES AUX SI
 Caractéristiques des risques SI : Evolutivité et dynamisme
 Puisque l’environnement d’un SI est propre aux spécificités du SI,
chaque organisation présente un profil de risque qui lui est propre.
 Selon la loi de Moore de 1965, la densité des données sur un circuit
intégré double tous les 18 mois
 Dans les faits, cela signifie que les progrès technologiques sont rapides
et par conséquent, les risques liés aux SI ne sont pas statiques.
 Ils évoluent, très souvent d’une année à l’autre selon la pente de
croissance et de l’expansion de la technologie
Caractéristiques des risques SI : Evolutivité et dynamisme
Pour éviter ce risque, le responsable de l’audit doit :
▪ Reconnaître la nature dynamique du risque lié aux SI et mener
des évaluations indépendantes de ce risque chaque année
▪ Comprendre les plans à court terme de le direction en charge
du SI pour une année donnée et déterminer quelles peuvent en
être les conséquences sur l’évaluation du risque lié à celui-ci
▪ Actualiser l’évaluation du risque d’audit avant de commencer
le prochain audit
▪ surveiller le profil de risque de l’organisation et être prêt à
adapter les procédures d’audit à son évolution.
Caractéristiques des risques SI : Prolifération

Le responsable de l’audit doit évaluer non pas seulement
chaque risque distinct, mais aussi les interactions entre les
différents risques car l’environnement est vue de manière
architecturale et urbanisée.
Pour éviter la prolifération du risque, il faudrait évaluer les
conséquences des risques à un niveau sur les autres
niveaux et le risque d’une zone sur une autre zone
Caractéristiques des risques SI : Prolifération
Il s’agit de considérer le risque lié aux SI dans sa
globalité et non isolément par division/direction de
l’entreprise
Supposons les risques A et B identifiés dans des
départements différents. Il se peut que, chaque
risque pris séparément, soit en soi faible, mais
ensemble créent un risque C qui est nettement plus
important que la somme des deux risques initiaux.
Les catégories de risques SI : Risque pervasif
C’est un risques qui a une incidence sur l’ensemble de
l’entreprise. Il n’est pas circonscrit à un système ou à un
processus spécifique.
Généralement, lorsqu’on est dans une situation de risque

pervasif, il est très difficile de relier son impact métier.
Illustration : une organisation A est reliée à Internet et n’a pas
mis en place de pare-feu. Sur quel département cela a-t-il
une incidence ?
Les catégories de risques SI : Risque pervasif
C’est un risques qui a une incidence sur l’ensemble de

l’entreprise. Il n’est pas circonscrit à un système ou à un
processus spécifique.
Illustration : une organisation A est reliée à Internet et n’a
pas mis en place de pare-feu. Sur quel compte cela a-t-il
une incidence ?
Potentiellement sur tous et potentiellement sur aucun
Les catégories de risques SI : Risque « spécifique »
C’est un risque directement lié à un processus spécifique

Le mauvais paramétrage des accès d’un compte n’a de
l’influence que sur le compte en question
Si un audit de SI ne ressort pas les risques spécifiques et
pervasifs, il est probable que cet audit ne couvre pas
correctement les risques auxquels l’organisation est
confrontée
Les catégories de risques SI : Risque statique
 C’est un risque qui n’évolue guère d’une année sur l’autre et

provient généralement du secteur dans lequel l’entreprise
opère.
 Illustration: la société X souscrit à un PAAS pour des formation
à distance. Le risque associé est que, si les serveurs ne
fonctionnent plus, la formation cessera jusqu’à ce que les
serveurs soient remis en marche.
 C’est un risque globalement valable d’une année sur l’autre
 Les catégories de risques SI : Risque dynamique
 C’est un risque qui évolue sans cesse. Il est moins tributaire du
secteur de l’organisation et davantage lié à l’évolution
technologique (cf. la loi de Moore)
 Illustration : La découverte d’une faille dans Windows server
2003. Les audits n’ont pas pu détecter la faille jusqu’à ce que le
système présente des faits d’incohérences et que Microsoft
définisse un patch pour y remédier.
 Dans ce cas, l’audit devra se concentrer sur le processus mis en
place pour piloter les patchs et mesurer la rapidité avec laquelle
ils sont introduits.
 Les catégories de risques SI : Risque dynamique
 C’est un risque qui évolue sans cesse. Il est moins tributaire du
secteur de l’organisation et davantage lié à l’évolution
technologique (cf. la loi de Moore)
 Illustration : La découverte d’une faille dans Windows server
2003. Les audits n’ont pas pu détecter la faille jusqu’à ce que le
système présente des faits d’incohérences et que Microsoft
définisse un patch pour y remédier.
 Dans ce cas, l’audit devra se concentrer sur le processus mis en
place pour piloter les patchs et mesurer la rapidité avec laquelle
ils sont introduits.
IV- MISSIONS DES AUDITS DES SI
 Assister l'équipe de projet à évaluer les risques lors des

différentes étapes de réalisation d'un système
 proposer des mesures de réduction et de contrôle des
risques importants dans la réalisation d’un nouveau système
 vérifier la qualité des processus de gestion des changements
et de test du nouveau système
 Evaluer la qualité des projets SI et non SI de l’organisation
Assister l'équipe de projet à évaluer les risques lors des

différentes étapes de réalisation d'un système
proposer des mesures de réduction et de contrôle des
risques importants dans la réalisation d’un nouveau
système
vérifier la qualité des processus de gestion des
changements et de test du nouveau système
Evaluer la qualité des projets SI et non SI de l’organisation
 Assister l'équipe de projet à évaluer les risques lors des différentes

étapes de réalisation d'un système
 proposer des mesures de réduction et de contrôle des risques
importants dans la réalisation d’un nouveau système
 vérifier la qualité des processus de gestion des changements et de
test du nouveau système
 Evaluer la qualité des projets SI et non SI de l’organisation
 L'audit des SI a pour objectif d’identifier, d’évaluer et déterminer les
risques (opérationnels, financiers, de réputation…) associés aux
activités informatiques d'une organisation
V - METHODOLOGIES DES AUDITS DES SI
Il est important d'effectuer un pré-diagnostic afin de

préciser les questions/domaines dont l'audit va traiter.
Cela se traduit par l'établissement d'une lettre de mission
qui détaille les principaux points à auditer.
En général, un auditeur des SI utilise plusieurs approches,
selon le domaine audité du SI.
Cependant il existe une méthodologie d’ensemble qui
présente le déroulement pour mener à bien les audits des
SI.
V- METHODOLOGIES DES AUDITS DES SI
▪ Cadrage et planification de la mission

▪ Comprendre l’environnement
▪ Identifier les contrôles clés
▪ Évaluer la conception des contrôles clés
▪ Vérifier l’efficacité
▪ Rendre les conclusions et recommandations
1- Cadrage et planification de la mission

Cette phase porte sur l’approche générale des travaux,
le niveau de supervision, les ressources nécessaires pour
la mission, les besoins d’intervenants externes
Cette phase a pour objectif de :

Délimiter le périmètre d’intervention de l’équipe
d’audit. Cela peut être matérialisé par une lettre de
mission , une note interne, une réunion préparatoire à
la mission d’audit ;
1- Cadrage et planification de la mission
Définir une approche d’audit et d’organisation des travaux

entre les deux équipes ;
 Définir le planning d’intervention ;
Définir les modes de fonctionnement et de communication.

l’auditeur prend connaissance du dossier de l’équipe de
l’audit (stratégie d’audit, rapports d’audit interne, points
d’audit soulevés au cours des précédents audits).
2- Comprendre l’environnement
Cette étape vise à recueillir les éléments relatifs au

secteur d’activité, aux caractéristique de l’organisation,
aux éléments de contrôle interne et pertinents pour
l’audit. l’objectif de cette phase est :
▪ de comprendre les risques et les contrôles liés au SI
▪ de comprendre comment le SI contribue à la

productivité de l’organisation
Cette phase se fait sur la base de trois aspects notamment :
a- L’organisation de la fonction SI :
➢L’alignement de la stratégie SI à celle de l’entreprise
➢Le mode de gestion et d’organisation de la fonction SI :

Apprécier si la fonction informatique est sous contrôle du
management de l’entreprise
b- Les caractéristiques des systèmes informatiques : L’auditeur
devra se focaliser sur les systèmes clés de façon à identifier les
risques et les contrôles y afférents.
Ainsi, il faut documenter l’architecture du matériel et du réseau en
précisant :
▪ Les caractéristiques des systèmes hardware utilisés (leur

architecture, leur procédure de maintenance, les procédures
de leur monitoring) ;
▪ Les caractéristiques des systèmes software (systèmes
d’exploitation, systèmes de communication, systèmes de gestion
des réseaux, de la base des données et de la sécurité, utilitaires).
c-La cartographie des applicatifs : il s’agit d’inventorier les
applications informatiques utilisées dans les processus métier ainsi
que leurs caractéristiques (langage de développement, année de
développement, bases de données et serveurs utilisés, etc
3- Identification et évaluation des risques

Cette étape permet d’apprécier l’efficacité du contrôle interne courant
et de détecter les anomalies
4-Identifier les contrôles clés : Il s’agit d’identifier les risques liés au SI et

d’apprécier leur impact. Une fois ces risques recensés, l’auditeur devra
évaluer les contrôles mis en place par l’entreprise pour leur gestion.
5- Evaluer la conception des contrôles clés : Il s’agit d'arriver à dégager

des faits indiscutables qui permettent d’apprécier la couverture et
l’efficacité des points de contrôles. Cette phase est délicate et
compliquée dans la mesure où les informations collectées auprès des
opérationnels ressemblent plus à des opinions qu'à un apport sur les faits
recherchés.
6- Vérifier l’efficacité : il s’agit d’apprécier la pertinence des

résultats des points de contrôle mis en place ( gestion de
l’exploitation, gestion de la sécurité, etc).
7- Les tests de procédure et les contrôles de substance : il

s’agit ici de déterminer l’étendue et le calendrier de la mise
en œuvre des procédure au regard des risques identifiés
8- la Communication et le rendu des conclusions

L’auditeur se doit de communiquer avec l’organe de
l’administration en charge du SI et de donner son rendu au
terme de sa mission
VI- RÉFÉRENCES ET NORMES
Le cadre de référence a pour objectif de définir un dispositif de
contrôle efficaces et performants qui permette de maîtriser
efficacement l'activité du SI
L'auditeur se sert des référentiels qui lui permettent d’évaluer la

mise en œuvre des meilleures pratiques liées au SI pour les buts
suivants :
la conformité au cadre normatif (Procédure, lois, règlements…)
la fiabilité (sécurité) du systèmes (équipement, applicatifs…) et

des données
la réalisation et l'optimisation des opérations (traitements)....

Entreprises de normalisation
Elles mettent en place des cadres de contrôle qui visent à aider le
management à gérer les risques (sécurité, fiabilité, conformité) et
les investissements SI
ISO : Organisation Internationale de normalisation, créé en 1946
ISACA : Information Systems Audit & Control Association) est

l'association internationale des auditeurs informatiques, créé en
1967 a mis en plusieurs plusieurs référentiels de bonnes pratiques
des SI
 SANS: SysAdmin, Audit, Network, Security Institute : pour ce qui est de la
formation et de la sensibilisation à la sécurité des TI
AFAI : Association Française de l'Audit et du conseil Informatique
VI-RÉFÉRENCES ET NORMES
L'auditeur dispose d’une gamme variée de référentiels

qui lui sert de guide selon le domaine audité.
CMMI : Capability maturity model integration
Créé en 1991 par le SEI (Software Engineering Institute)
de l'université Carnegie-Mellon, financé par le DoD
le CMMI est un modèle de bonnes pratiques du génie
logiciel pour appréhender et mesurer la qualité des
services rendus.
Il permet d’évaluer et améliorer les activités des
entreprises d'ingénierie
CMMI se décline en trois modèles appelés « constellations » dont

la particularité est qu'ils ont une partie commune (noyau ou core
qui représente environ 60 % des pratiques. Les différences portent
essentiellement sur la catégorie de l’activité
CMMI-DEV pour le développement de systèmes (logiciel ou
autre, modèle publié en août 2006)
CMMI-ACQ pour la maîtrise des activités d'achat (modèle publié
en novembre 2007
CMMI-SVC pour la fourniture de services (modèle publié en
février 2009
On distingue :
Les objectifs génériques : CMMI fournit cinq objectifs
génériques et les pratiques associées qui s'appliquent à
tous les domaines de processus.
Les pratiques génériques : les pratiques génériques
appartiennent aux objectifs génériques. Elles doivent
être systématiquement implémentées pour prétendre
atteindre un niveau de maturité ou de capacité
Les objectifs spécifiques : les objectifs spécifiques sont

liés à un domaine de processus
Les pratiques spécifiques : elles sont liées à un objectif

spécifique, donc à un domaine de processus
Les produits d'activité : ce sont tous les éléments

générés par un projet (plan de projet, spécification,
cahier de test unitaire, revue par les pairs, etc.)
CMMI définit :
une échelle à cinq niveaux de mesure de la
maturité des processus
des indicateurs, nécessaires pour évaluer les

activités menées, par une équipe
l'équipe : peut être un groupe de travail, un ou
plusieurs projets, une société voire une institution
d'État
NIVEAU DE MATURITE 1 « Initial » : Il n'y a pas de

description, pas de surveillance, aucune évaluation de
performance et la communication est absente et es
réactions aux incidents se font en mode urgence, sans
identification claire des priorités
NIVEAU DE MATURITE 2 « Managed », (discipline) : Une

discipline est établie et se matérialise essentiellement
par des plans de développement, d'assurance qualité,
de gestion de configuration.
 NIVEAU DE MATURITE 3 « Defined », (ajusté) : Ce niveau est caractérisé par des lignes
directrices, un plan stratégique, une planification de l'amélioration de
processus, en ligne avec les objectifs d'affaire de l'organisation, la
formalisation des responsabilités et des devoirs des employés.
 NIVEAU DE MATURITE 4 « Quantitatively managed », (gestion quantitative) :

caractérisé par le pilotage des processus sur la base d'objectifs quantitatifs
de qualité produit et processus
 NIVEAU 5 « Optimizing », (optimisation) : Les processus qui sont gérés

quantitativement pour le pilotage de projet (niveau de maturité 4) sont en
amélioration constante afin d'anticiper les évolutions prévues (besoins clients,
nouvelles technologies…)
 NIVEAU DE MATURITE 3 « Defined », (ajusté) : Ce niveau est caractérisé par des lignes
directrices, un plan stratégique, une planification de l'amélioration de
processus, en ligne avec les objectifs d'affaire de l'organisation, la
formalisation des responsabilités et des devoirs des employés.
 NIVEAU DE MATURITE 4 « Quantitatively managed », (gestion quantitative) :

caractérisé par le pilotage des processus sur la base d'objectifs quantitatifs
de qualité produit et processus
 NIVEAU 5 « Optimizing », (optimisation) : Les processus qui sont gérés

quantitativement pour le pilotage de projet (niveau de maturité 4) sont en
amélioration constante afin d'anticiper les évolutions prévues (besoins clients,
nouvelles technologies…)
Aperçu du référentiel CMMI

ITIL (IT Infrastructure Library)

Conçue sur l’initiative du gouvernement britannique, ITIL couvre
l'essentiel des activités d'exploitation et de production des
services. Il aborde les sujets suivants :
Comment organiser un système d'information ?
Comment améliorer l'efficacité du système d'information ?
Comment réduire les risques ?
Comment augmenter la qualité des services informatiques ?
ITIL (IT Infrastructure Library)

ITIL décrit comment on s'assure que le « client » a accès aux
services informatiques appropriés, et comprend :
Le centre de services (service desk)
La gestion des incidents (incident management)
La gestion des problèmes (problème management)
La gestion des changements (change management)
La gestion des mises en production (release management)
La gestion des configurations (configuration management)
ITIL couvre six guides principaux :

Service Support : il est consacré aux process
support qui permet la gestion des services ;
Service Delivery : Consacré à la gestion des
services informatiques
Software Asset Management : Ce module
explique en quoi consiste le pilotage d’un
service IT et comment le rendre performant et
efficace
Quelques aspects SI abordés par ITIL

Gestion des changements : Mettre en œuvre des
démarches de conduite du changement afin
d'anticiper les effets de bord
Gestion de la continuité des services : Définit et met en
œuvre des délais contractuels pour la reprise après
incident
Gestion des niveaux de service : Définit les SLA et
comment maintenir un certain niveau de qualité de
service grâce à des contrats de service
ICT Infrastructure Management : Consacré à l’organisation et aux

outils nécessaires à la fourniture stable des ICT (Information and
Communications Technology) ;
Application Management : C’est un module qui concerne le cycle

de développement et de support d’un logiciel ainsi que l’examen
des services IT ;
Security Management : il est consacré à la sécurité dans les

services informatiques.
Quelques aspects SI abordés par ITIL
Gestion des configurations : il décrit comment l'infrastructure doit

être gérée à travers un état des lieux de l'existant et explique
comment le faire évoluer
Gestion des incidents : il explique comment détecter les incidents,
améliorer le délai de résolution des incidents selon leur criticité sur
le fonctionnement de l'entreprise
Gestion des problèmes : Mieux gérer les problèmes récurrents et
mettre en œuvre des solutions de prévention afin de réduire leur
occurrence, voire les supprimer.
Aperçu du référentiel ITIL

COBIT (Control Objectives for Business and related Technology)

initialement publié en 1994 par l’ISACA (Information Systems Audit and
Control Association), COBIT est l’un des référentiels de contrôle et de
gouvernance des SI. La version 5.0 du CobiT a été publiée en 2012
CobiT est à la base de la Gouvernance et le Management des SI. Il

propose une série d’objectifs de contrôle des SI qui aide le management
à concevoir une politique d’évaluation et de gestion des risques liés aux
SI.
Il comprend six domaines d’intervention à savoir :

Executive summary (Synthèse) : Cette partie résume
de la méthodologie CobiT;
Framework (Cadre de Référence) : c’est la partie
explicative des méthodes, des domaines et des
processus) ;
 Control objectives (Objectifs de contrôle détaillés) :
ces objectifs sont orientés vers le management et les
équipes responsables des services informatiques) ;
Audit guidelines (le guide de l'audit) : décèle, analyse

et explique les failles d'un système et les risques qui en
découlent ainsi que de leur apporter des solutions)
Implementation Tool Set : les outils de la mise en œuvre
du CobiT ;
Management Guidelines (le guide du management) :
Ce guide propose un cadre de 5 degré de pilotage ou
« tableau de bord prospectif (balanced score card) »
Il permet le développement d’un système cohérent de règles,

normes et procédures. Les principes de COBIT5 permettent :
de répondre aux besoins de toutes les parties prenantes

de couvrir l'entreprise dans sa globalité
d’appliquer un référentiel unique et intégré ;
de facilité une approche globale ;
de distinguer la gouvernance de la gestion.
Ces principes sont accompagnés de sept facilitateurs ou leviers de

gouvernance qui couvre et soutiennent de bout en bout toutes les
fonctions et tous les processus du SI.
COBIT5 dénombre trente-sept processus repartis en 5

domaines.
Evaluer, Diriger et Surveiller (EDS) : Ce domaine comprend cinq

processus. Il permet de s’assurer du respect des grandes règles de
gouvernance ;
 Aligner, Planifier et Organiser (APO) : Ce domaine comprend treize
processus. Ce sont les bases de la gestion de l’informatique ;
 Bâtir, Acquérir et Implanter (BAI) : Ce domaine comprend dix
processus. Le but de ce domaine est d’améliorer les processus de
définition et de mise en place des applications informatiques ;
COBIT5 dénombre trente-sept processus repartis en 5

domaines.
Livrer, Servir et Soutenir (LSS) : Ce domaine comprend six
processus. L’objectif est de perfectionner le
fonctionnement de l’exploitation informatique ;
Surveiller, Evaluer et Mesurer (SEM) : Ce domaine
comprend trois processus. Il détaille les bases du contrôle
des Systèmes d’Information dont le contrôle interne.
CobiT Quickstart :
Version simplifiée de CobiT s'adresse principalement aux
PME1 pour lesquelles les techniques informatiques ne
représentent pas un enjeu stratégique mais simplement
un levier dans leur stratégie de croissance.
Il s’interesse à la direction générale en indiquant ce que

l'implantation d'un processus donné va apporter sur les
informations (par exemple sur l'information décisionnelle)
Il se repose sur les hypothèses suivantes :
l'infrastructure informatique n'est pas complexe
la taille de l'entreprise, le système d'information
et l'activité sont bien alignés ;
 les tâches les plus complexes sont externalisées
 la tolérance aux risques est relativement élevée
l'éventail des contrôles est peu étendu ;
la structure de commandement est simple.
CobiT Quickstart se base sur les facteurs suivants :
Efficacité : qualité et pertinence de

l'information, distribution cohérente ;
Efficience : rapidité de délivrance ;
Confidentialité : protection contre la divulgation
Intégrité : exactitude de l'information ;
CobiT Quickstart s’appuie sur ressources telles que :
 le personnel et collaborateurs (internes et
externes)
les applications : ensemble des procédures de
traitement
l'infrastructure : ensemble des installations, Data
Center ;
les données : informations au sens global (format,
structure ;
Disponibilité : accessibilité à la demande et
protection (sauvegarde) ;
Conformité : respect des règles et lois ;
Fiabilité : exactitudes des informations

transmises par le management.
TOGAF (The Open Group Architecture Forum)
TOGAF est norme utilisée pour la structuration en couche de

l'architecture des SI.
Il permet d’avoir une vue globale des actifs informationnels de la
gouvernance et du management de l’entreprise.
Le framework TOGAF structure le SI en quatre couches qui définissent
une vision spécifique du SI à savoir :
 la couche business ;
 la couche des données ;
 la couche application ;
 la couche technologique
TOGAF (The Open Group Architecture Forum) : la couche business
 Elle décrit la vision stratégique de l’entreprise, la gouvernance,

l’organisation et l’ensemble des processus métiers clés.
 Les activités qui se réfèrent à ces processus doivent être en cohérence
avec les facteurs dont le suivi permettrait de mieux maitriser la
trajectoire et la conduite de l’entreprise. Il s’agit entre autres de :
 la vision : elle porte sur la stratégie globale pour atteindre un but,
déclinée en stratégies opérationnelles pour des objectifs et en
schémas directeurs pour les indicateurs de performance ;
 la dénombrabilité : les processus, les étapes des processus et les
résultats de chacun doivent être bien définis ;
TOGAF (The Open Group Architecture Forum) : la couche business
Le pilotage : il consiste à avoir un tableau de bord d’indicateurs

stratégiques et opérationnels de performance ;
le jalonnage : fait référence à des périodes de contrôle et de
recadrage vis-à-vis de la stratégie ;
la subsidiarité : c’est la définition des limites de responsabilités ;
 le mode de fonctionnement : il s’agit de l’ensemble des
procédures, des chartes internes, des règlements qui régissent le
fonctionnement de l’organisation.
TOGAF (The Open Group Architecture Forum) : couche

donnée
Elle fait référence d’une part, à la structure et l’organisation
des données aux niveaux logique et physique, et d’autre
part, aux référentiels des données et la manière dont elles
sont gérées.
L’on distingue deux types de données que sont :
les données référentielles : ce sont des données quasiment
stables, évoluant très peu et nécessaires au fonctionnement
des processus et à la prise de décision.
les données opérationnelles : elles sont volatiles et concernent
les transactions quotidiennes de l’entreprise.
TOGAF (The Open Group Architecture Forum) : couche donnée

Il est important de pouvoir évaluer la qualité des données afin
de déterminer dans quelle mesure elles demeurent pertinentes
pour l’organisation.
Les facteurs de qualité non exhaustifs ci-après désignent un
ensemble de caractéristiques intrinsèques et fonctionnelles :
La fraicheur : elle permet d’avoir une bonne visibilité sur un fait
ou un évènement à un instant donnée, afin de prendre la
décision adéquate ;
La cohérence : il s’agit de l’homogénéité des données avec
les contraintes de l’organisation ;
TOGAF (The Open Group Architecture Forum) : couche donnée
la pertinence : elle représente le degré d’utilité

de la donnée pour une tâche ;
l’exactitude : c’est la variance de la donnée
reçue par rapport à la donnée réellement
représentative ;
la traçabilité : elle permet de suivre le
cheminement des données dans l’organisation ;
TOGAF (The Open Group Architecture Forum) : couche application
Elle définit le parc applicatif de l’entreprise, les

interactions entre les applications, les processus
métiers et la couverture fonctionnelle des
applications.
 L’objectif est d’harmoniser les échanges dans

l’organisation par la distribution et la réutilisation
des fonctions applicatives.
Il s’agit de suivre tout flux informationnels des points de

vue fonctionnel, utilisation et maintenance. par des
facteurs de qualité.
Point de vue « fonctionnel » :

Pertinence : c’est la capacité de répondre au
problème de l’entreprise ;
Adéquation : c’est l’adéquation du logiciel à
l’organisation et aux procédures de l’entreprise ;
Il s’agit de suivre tout flux informationnels des points de vue

fonctionnel, utilisation et maintenance. par des facteurs de
qualité.
Point de vue « fonctionnel » :

Pertinence : c’est la capacité de répondre au problème de
l’entreprise ;
Adéquation : c’est l’adéquation du logiciel à l’organisation
et aux procédures de l’entreprise ;
Evolutivité : c’est la facilité à ajouter d’autre fonction ;
TOGAF (The Open Group Architecture Forum) : couche

application
Point de vue « utilisation »
Maniabilité : aptitude du logiciel à être
convivial et simple d’emploi
Interopérabilité : Aptitude du logiciel à

communiquer ou interagir avec d’autres
système.
Point de vue « maintenance »
Maintenabilité : aptitude avec laquelle on

peut détecter et corriger les erreurs ;
Portabilité : aptitude à fonctionner d’un

logiciel dans un autre environnement ;
TOGAF (The Open Group Architecture Forum) : Couche technologique

Elle décrit l’infrastructure logicielle, matérielle et réseau nécessaire au déploiement des données et des
applications.
L’objectif est de s’assurer que les infrastructures obéissent aux facteurs de qualité que sont entre autres :
la normalisation : elle concerne les normes et les standards uniformes, ouverts et reconnus sur lesquels
doivent reposer les infrastructures ;
la modularité : les infrastructures doivent s’organiser en composants autoportants, indépendants,
réutilisables, privilégiant une autonomie fonctionnelle et technique ;
l’écoresponsabilité : les infrastructures technologiques doivent être choisies et gérées de façon à
respecter l'environnement.
L’adoption du principe des 3RV-E (réduire, réutiliser, recycler, Valoriser et Eliminer) est prescrite pour
soutenir le développement durable
La structuration en couches par TogaF utilise l’ADM

(Architecture developemnt method) qui est un process
circulaire et itératif représenté par plusieurs phases.
La phase préliminaire
 décrit les activité à implémenter pour la mise en place
de l’architecture d’une entreprise
Décrit le rôle de chaque département dans la mise en
place de l’architecture
La phase A : Vision de l’architecture

 décrit en quoi consiste la phase initiale du cycle de mise
en place de l’architecture
Définit le périmètre des activités de mise en place de
l’architecture, identifie les parties prenantes, les outils de
pilotage du projet et l’approbation de la validation du
projet par l’équipe de pilotage
La phase B : Objectif de l’architecture

 décrit comment les objectifs du projet de mise en place
de l’architecture sont en cohérence avec la vision de
l’entreprise
 La phase C : Systèmes d’Information sur lesquels s’appuie
l’architecture
 Décrit les données, les applications et les architectures des
applications
La phase D : Les technologies de l’architecture

 Décrit l’architecture existante (technologie, données,
application, technologie)
Analyse les écarts entre l’architecture existante et
l’architecture cible
La phase E : Opportunités et solutions
 Planification initiale de l’implémentation, identification des livrables
du projet défini dans la phase précédente
La phase F : Planification de la migration
 Créer un ensemble d’activités détaillées par séquence
de transition pour l’implémentation du plan de migration
 La phase G : Implémentation de la Gouvernance
 Présente les avantages du modèle architectural implémenté
 La phase H : Changement de management
 Décrit comment assurer la continuité des services et présente les
nouveaux process de management et s’assure que l’architecture
mise en place répond aux besoins de l’entreprise
 Phase de Management
S’assure que chaque phase ne s’écarte pas des objectifs fixés
Architecture Developement Method

Contenu du cadre des travaux :

Présente le modèle structuré de la conduite des
travaux
Et définit les trois catégories de produits :
Les délivrables
Les artéfacts
blocs
Continuum (vue global)

The Abu Dhabi IT Architecture & Standards

Framework : C’est un référentiel qui décrit le SI
sur huit niveaux notamment : Métiers, Accès et
présentation, Application, Données, Intégration,
Infrastructure, Sécurité et Exploitation
ISO 27002 : c’est un code de bonnes pratiques en
matière de management de la sécurité des systèmes
d'information ;
Val IT : Mis en place par l’ISACA, permet

d'évaluer la création de valeur par projet ou par
portefeuille de projets ;
Risk IT : Mis en place par l’ISACA, a pour but

d'améliorer la maîtrise des risques liés à
l'informatique ;
VII- Catégories d’audits des SI
 L’audit des missions généralistes
 Il a pour objectif de vérifier la cohérence de la stratégie

numérique à l’activité de l’organisation
 Il fournit une approche des implications SI dans les missions-
types de l’organisation
 Il permet d’avoir une vue des principaux enjeux, risques
associés, des acteurs à rencontrer des documents à
récupérer et les principales questions à aborder dans l’audit
spécifique
VII - Catégories d’audits des SI
L’audit de l’organisation
Les organisations utilisent quotidiennement les ressources

informatiques (bureautique, applications dédiées, etc) sans être
conscientes que ces ressources sont, désormais, au cœur de leur
performance et indispensables à leur bon fonctionnement.
L’audit de l’organisation tient compte de la relation avec l’
informatique et vérifie comment l’organisation a procédé pour définir
les besoins en ressources informatiques afin de disposer d’un SI
efficient
1- L’audit de l’organisation
L’auditeur devra à cet effet :
▪ Etudier le fonctionnement de la comitologie associée au
pilotage des SI ;
▪ Se demander si les ressources informatiques sont convenables
et dimensionnées conformément aux besoins et la charge de
l’activité ;
▪ vérifier que l’organisation a mis en place le corpus minimal de
politique du SI, politique de sécurité du SI, charte d’utilisation
▪ Rencontrer la direction générale pour mesurer son degré de

sensibilisation au fait informatique et l’organisation qu’elle a
mise en place pour piloter ses SI ;
En définitive, l’auditeur devra porter une appréciation sur :

➢ la capacité de l’organisation à piloter ses ressources informatiques
➢ les enjeux de la valeur du patrimoine numérique
➢ les risques qui pèsent sur les ressources informatiques et le SI
VII- Catégories d’audits des SI
Il devra se procurer :
les politiques SI et de sécurité SI de l’organisation ;
le plan d’occupation au sols (POS) du SI
la liste des responsables de zones fonctionnelles ;
la charte de l’utilisateur des SI à laquelle sont soumis les
membres de l’organisation ;
la liste des processus de l’organisation incluant les SI qui les
supportent ;
la politique RH et de formation
2- L’audit de processus
 De plus en plus, les processus des organisation sont pour la plupart
fortement dépendants des outils informatiques. A cet effet, la
performance d’un processus s'avère intimement liée à la qualité des
systèmes informatiques.
 l’audit des processus permet donc d’évaluer le niveau de maturité du
processus
 Il intègre l’audit des outils informatiques sur lesquels le processus
s’appuie, l’examen des données et les informations manipulées au cours
du déroulement du processus, ainsi que la communication avec les
autres processus.
Catégories d’audits des SI
L’auditeur devra :
étudier à travers les documents qui décrivent le processus
son fonctionnement, les données et informations
manipulées, et les applications et les infrastructures
ressources.
vérifier que la sécurité physique et logique des données, des
informations, des applications et des infrastructures est en
cohérence avec l’analyse des risques du processus.
vérifier la pertinence de l’analyse des risques sur le
processus et ses ressources ;
Etudier le dispositif de contrôle interne destiné à maîtriser le
processus,
Vérifier que les infrastructures (particulièrement réseaux et
serveurs) et les dispositifs d’assistance aux usagers de ces
systèmes sont suffisants pour répondre aux besoins du
processus
L’auditeur devra rencontrer
la direction générale pour évaluer le mécanisme de
pilotage et contrôle du processus ainsi que leur cohérence
la ou les directions concernées par le processus audité, pour
évaluer le degré de maturité du processus, et étudier
l’organisation qu’elles ont mise en place en vue de définir
et exprimer des besoins informatiques du processus ;
l’auditeur devra se procurer :
 la cartographie des processus ;
 la description du processus audité, incluant l’inventaire des données
et informations manipulées et des applications et infrastructures
utilisées
 les tableaux de bord de reporting du déroulement et de la
performance des processus ;
 la cartographie des données, informations et applications
informatiques de l’organisation ;
la déclinaison des politiques SI et de sécurité SI à l’égard du
processus audité ;
La déclinaison de la charte des utilisateurs à l’égard des
acteurs du processus ;
En définitive, l’auditeur devra porter une appréciation sur
l’efficacité, l’efficience, la sécurité, et la résilience de
l’informatique aux besoins du processus audité
3- L’audit de régularité
 L’audit de la régularité porte sur le respect des normes et du corpus
normatif qui impliquent les processus, les infrastructure, les applicatifs,
les données du SI.
 Il permet de vérifier que les activités portées par les ressources
informatiques respectent elles-mêmes le cadre normatif à travers les
leurs règles.
L’auditeur devra :
 identifier les ressources informatiques utilisées dans le périmètre de son
audit ;
 vérifier que les ressources sont en elles-mêmes régulières (licences,
respect des règles de conservation des données personnelles, respect
des règles de confidentialité, etc.) ;
 vérifier et évaluer la fiabilité des traitements automatiques
conformément au corpus normatif applicable ;
 vérifier que la sécurité appliquée à ces ressources, outre le respect
des règles de confidentialité, garantit raisonnablement qu’elles ne
peuvent être utilisées à des fins frauduleuses.
L’auditeur devra rencontrer :
Les acteurs stratégiques du périmètre du champ audité
pour évaluer s’ils sont conscients de l’obligation du
fonctionnement du SI dans un cadre normatif et s’assurer
qu’ils respectent et font respecter les corpus normatifs
applicables
les acteurs opérationnels de l’entité/processus audité pour
identifier les ressources utilisées ;
Il devra se procurer :
 la cartographie des applications et des systèmes, les
contrats et les licences ;
 la description du dispositif de contrôle des règles du cadre
normatif ;
Sur ce point, l’auditeur devra apprécier à la fois sur la valeur
de la contribution de l’informatique à la réglementation des
activités informatiques.
4- Les audits des fonctions externalisées
 Les motifs d’ouverture des système informatiques des organisations
vers des systèmes externes sont nombreux. A l’instar des taches liées à
l’administration de serveurs, de données ou d’applications via les
technologies de dématérialisation de l’informatique
 Il y a des échanges des données, en temps réel ou non, entre des
parties cocontractants. Le cocontractant a alors la responsabilité de
l’intégrité, de l’accessibilité et de la protection des données.
 Cet audit aborde les obligations des parties cocontractantes dans les
prestations des services informatiques
l’audit des fonctions externalisées a pour objectifs :
D’identifier les données et informations numériques
échangées entre les parties
D’identifier les ressources informatiques matérielles (serveurs,
réseaux, etc.) et applicatives qui y contribuent, ainsi que le
personnel interne et extérieur qui y participe ;
 vérifier que le contrôle interne, y compris la résilience,
appliquée aux ressources est en cohérence avec les enjeux
de l’organisation ;
 Vérifier la conformité de l’exécution des prestations conformément au
cadre normatif des services IT de l’organisation ;
 Vérifier la conformité de l’exécution des prestations conformément au
marché ;
L’auditeur devra rencontrer :
 les acteurs opérationnels de l’organisation chargés des relations
courantes avec le prestataire, pour identifier les ressources
informatiques (informationnelles, matérielles et humaines) concernées
par la prestation externalisée ;
 la direction chargée du SI, pour vérifier qu’elle a validé les échanges
avec le prestataire, y compris le cas échéant, les modalités
d’interconnexion avec les systèmes externes
 Les documents à utiliser sont :
 les marché(s) qui régissent l’externalisation ;
 la description des processus externalisés et de ceux impactés par
l’externalisation
L’auditeur devra se procurer :
 l’inventaire des ressources informatiques utilisées ou impactées par
l’exécution de la prestation externalisée (notamment la cartographie
des applications et des systèmes)
 la description du dispositif de suivi et de contrôle interne des
prestations
 Sur ce point, l’auditeur devra porter une appréciation sur la qualité de
la prise en compte des prestations externalisées et se prononcer sur les
fragilités éventuelles qui peuvent résulter de l’externalisation,
notamment en termes de irréversibilité, de sécurité et de contrôle
interne.
VIII- APPROCHE D’AUDIT DES SI
Généralement, l’audit des SI se fait dans les champs suivants :

- Gouvernance des TI
- Audit des données
- Audit de la passation de contrats TI
- Audit de la sécurité
L’ensemble est intégré dans les phases de planification,
d’évaluation des contrôles généraux et d’évaluation des
contrôles des applications
1- La planification
Le Système d’information est considéré comme un ensemble
de parties interdépendantes (structures physiques, personnel,
outils informatiques) qui interagissent afin d’enregistrer, de
contrôler, d’évaluer et de gérer les transactions.
Cette phase permet d'acquérir une compréhension des
procédures, des méthodes, des opérations, des contrôles et
des risques liés au système
2- Les contrôles généraux

Les contrôles généraux ont pour objectif de sauvegarder les données,
protéger les programmes des applications et assurer la continuité des
opérations informatiques en cas d’interruptions imprévues.
C’est le cadre de contrôles de l’ensemble des fonctions du SI.
Les différentes catégories de contrôles généraux sont :

 Contrôles organisationnels, Contrôles d’accès physique, Contrôles
d’accès logique, Contrôles environnementaux, Contrôles de
modifications des programmes, Plans de continuité des activités et de
reprise après sinistre
2- Les contrôles généraux : Contrôles organisationnels

Les contrôles organisationnels sont les politiques, les
procédures et le cadre organisationnel établis pour garantir :
les politiques de ressources humaines et les pratiques de
management saines, la séparation des fonctions
les stratégies de sécurité d’information mises en œuvre qui
permettent de fournir des méthodes pour évaluer
l’efficacité et assurer l’efficience des contrôles
opérationnels
2- Les contrôles généraux : Contrôles d’accès physique
Les contrôles d’accès physique comprennent les règles et

pratiques pour empêcher l’accès non autorisé et les
interférences avec les services informatiques,
y compris des procédures administratives comme les badges
d’identité pour le personnel, le contrôle des visiteurs, les
mesures physiques telles que les serrures à clé mécaniques et
les serrures électroniques, les caméras et les autres moyens de
limiter l’accès physique aux serveurs et aux autres
infrastructures essentielles.
2- Les contrôles généraux : Contrôles d’accès logique
Ils portent sur la sécurité intégrée aux systèmes informatiques

pour empêcher tout accès non autorisé aux données afin de
s’assurer que tous les utilisateurs disposent de droits d’accès
limités aux besoins de leurs fonctions.
Ils comprennent les parefeux, antivirus, logiciels de détection
d’intrusions et de programmes malveillants.
2- Les contrôles généraux : Contrôles environnementaux
Les contrôles environnementaux portent sur les règles, les

pratiques et les conditions établies pour éviter tout dommage
causé par l’instabilité électrique, l’incendie, la poussière,
l’eau, la nourriture, les températures extrêmes ou l’humidité, et
l’électricité statique.
Le but de ces contrôles concerne les espaces dédiés aux
équipements informatiques qui exigent un milieu spécifique.
2- Les contrôles généraux : Contrôles de modifications des

programmes
ce sont les règles qui visent à garantir que toutes les
modifications apportées à la configuration du système sont
gérées correctement, totalement et en temps utile.
Les mises à niveau et les modifications devraient être dotées
d’un processus officiel pour assurer la journalisation de tous
les changements et permettre la possibilité de faire marche
arrière si des problèmes apparaissent avec la nouvelle
version.
2- Les contrôles généraux : Plans de continuité des activités et de reprise

après sinistre
 Le plan de continuité des activités est une approche globale qui

définit les voies alternatives pour le maintien des processus
opérationnels critiques en cas d’urgence, de catastrophe ou autre
perturbation
 Le Plan de reprise après sinistre est la partie du Plans de continuité des
activités qui tient compte des exigences en matière des réseaux
informatiques et des télécommunications.
2- Les contrôles généraux : Plans de continuité des activités et

de reprise après sinistre
Le plan de continuité et de reprise doit avoir au minimum :
▪ les procédures et les critères pour déterminer quand une
situation est un sinistre
▪ la personne responsable de déterminer le sinistre
▪ Comment déclarer un événement comme étant
officiellement un sinistre et lancer sa mise en œuvre
3- Les contrôles des applications
L’objectif est de garantir l’intégralité, la fiabilité et l’exactitude
du traitement des données.
Les contrôles des applications sont automatisés dans les
applications du SI afin de contribuer à garantir l’autorisation,
l’intégrité, l’exactitude et la validité des transactions. Ils font
intervenir plusieurs types de contrôles à savoir :
Les contrôles d’entrée : garantissent l’autorisation, la
précision, l’intégralité et la ponctualité des données entrées
dans une application.
 Les contrôles de traitement : garantissent l’exactitude, l’intégralité et
la ponctualité des données au cours des traitements. Par exemple à
l’issue d’une opération de modification des données d’un client,
l’application affiche un message confirmant que le traitement a été
réussi
 Les contrôles de sortie : assurent l’intégrité des sorties ainsi que la

diffusion correcte et ponctuelle des sorties produites.
 La sortie d’une application peut être l’entrée vers une autre
application. Si tel est le cas, le vérificateur doit rechercher les
contrôles qui garantissent que les sorties sont transférées avec
précision d'une étape de traitement à l’autre
Les contrôles de traitement : garantissent l’exactitude, l’intégralité et la
ponctualité des données au cours des traitements. Par exemple à l’issue
d’une opération de modification des données d’un client, l’application
affiche un message confirmant que le traitement a été réussi
Les contrôles de sortie : assurent l’intégrité des sorties ainsi que la

diffusion correcte et ponctuelle des sorties produites.
La sortie d’une application peut être l’entrée vers une autre application.
Si tel est le cas, le vérificateur doit rechercher les contrôles qui
garantissent que les sorties sont transférées avec précision d'une étape
de traitement à l’autre
Une fois que les contrôles ont été identifiés, l’étape suivante de
l’audit est de vérifier leur efficacité.
Il s’agira pour l’auditeur de :
▪ soumettre un ensemble de données de test lesquelles, si
l’application fonctionne correctement, produiront des résultats
connus;
▪ développer des programmes indépendants pour ré-exécuter la
logique de l’application ;
▪ évaluer les résultats de l’application
3- AUDIT DU PILOTAGE DES SYSTEMES D’INFORMATION
L’objectif de l’audit est d’évaluer la « maturité » informatique de l’Organisation et
l’adéquation du rôle, du positionnement et des objectifs de la DSI avec les enjeux de
l’Organisation.
PC1 : Rôle et positionnement de l'informatique dans l'organisation

- La DSI est-elle rattachée à la DG et présente au COMEX ?
- vérifier que la DSI est une force de proposition et de conseil dans le domaine des
technologies de l’information.
- Vérifier l’existence d’une charte informatique ou de tout autre document définissant
le rôle et le périmètre de responsabilité de la DSI
- Vérifier que les métiers assurent leur rôle de MOA, en prenant en charge des aspects
de pilotage, des processus, de gestion de changement, de sécurité et d’évolutivité
PC2 : Planification stratégique
- Prendre connaissance du schéma directeur de l’Organisation et
analyser le plan informatique et la feuille de route du SI
- Prendre connaissance des documents d’urbanisme du SI
- Analyse des procédures de pilotage et de mise à jour du plan
d’occupation des sols (POS)
- analyse du positionnement du rôle des responsables de zones
fonctionnelles, de quartiers fonctionnels et de blocs fonctionnels.
PC3 : Budgets et coûts informatiques
- analyse du processus d’élaboration et de validation du budget
(qui, quand, comment) ;
- analyse des outils et procédures de suivi analytique, de contrôle
des coûts, d’analyse des écarts et le cas échéant de
refacturation des utilisateurs ;
- analyse de l’organisation du contrôle de gestion informatique
(existence d’un contrôleur de gestion dédié au sein de la DSI ?)
PC4 : Cadre législatif et réglementaire
- Vérifier que les prescriptions légales découle de la loi et sont
connues et respectées
- Vérifier que la loi sur la fraude informatique est connue et que
des mesures préventives ont été prises par :
- les bannières d’accueil des routeurs et serveurs d’accès distant
(de type “ Bienvenue.. ”, “ Welcome ”,…) sont-elles bannies et
remplacées par des messages d’avertissement ?
- effectuer des contrôles sur un échantillon de postes de travail et
contrôler les justificatifs de licences
4 - AUDIT DE SECURITE
PC1: Politique de sécurité
- Vérifier l’existence d’une politique de sécurité formalisée avec
une implication de la direction générale et une définition claire
des responsabilités
- Vérifier que l’ensemble des responsables et des employés sont
sensibilisés et informés sur la politique de sécurité
- Vérifier l’existence d’un système de mesure et d’évaluation de
l’efficacité de la gestion de la sécurité de l'information et de
collecte des suggestions d'amélioration.
PC2: Organisation de la sécurité
- Vérifier l’existence d’une structure dédiée à la gestion de la
sécurité de l'information : un comité sécurité, un
responsable de la sécurité du système d'information (RSSI) et
des correspondants sécurité dans les unités.
- Vérifier l’existence des procédures d'autorisation de
nouveaux matériels ou logiciels
- Vérifier l’existence des procédures d’accès aux informations de
l'organisation par des tiers notamment le contrôle des accès aux
infrastructures de traitement de l'information ;
- Existence des procédure d’analyse des risques ;
- Existence des mesures de protection de l'information (clause de
confidentialité, transfert de propriété, responsabilités, règles
d'accès physique et logique, restitution ou destruction de
l'information confiée, remplacement de collaborateur )
Vérifier qu'il existe des modalités de réaction aux incidents
de sécurité et aux défauts de fonctionnement :
- Notification des incidents de sécurité ;
- Notification des failles de sécurité ;
- Notification du fonctionnement défectueux de logiciels ;
PC3 : Classification et contrôle des actifs
 Vérifier que les actifs sont inventoriés et hiérarchisés par valeur
 Vérifier que pour tout actif important, un propriétaire est désigné
et informé de ses responsabilités
 Vérifier qu'il existe un système de classification qui définit un
ensemble approprié de niveaux de protection.
 Vérifier que chaque actif a fait l'objet d'une étude visant à
déterminer son niveau de classification.
PC4 : Sécurité du personnel
Vérifier que les postes et les ressources sont définis :
 inclusion de la sécurité dans les responsabilités des postes
sélection du personnel et politique de recrutement ;
accords de confidentialité ;
Vérifier que les utilisateurs sont formés.
PC5 : sécurité : gestion des communications et des opérations
 Vérifier la documentation des procédures et les responsabilités
opérationnelles.
 Contrôler les modifications opérationnelles.
 Vérifier l'établissement de procédures de gestion des incidents.
 Vérifier l'étude de sécurité en cas de gestion externe des
infrastructures
 Vérifier les mesures de protection contre les infections logiques.
 Vérifier les sauvegardes des données :
 réalisation régulière des copies de sauvegarde des données, des
applications et des paramètres ;
 distinguer sauvegarde et archivage ;
 déterminer les périodes de conservation des données ;
 conserver plusieurs générations de sauvegardes ;
 stocker les sauvegarde en lieu sûr ;
 tester régulièrement les supports de sauvegarde ;
 tester régulièrement les procédures de restauration
 Vérifier les modalités de gestion des supports de données :
 tenir en lieu sûr tous les supports amovibles ;
 effacer de manière sécurisée le contenu des supports à réutiliser hors de l'organisation ;
 établir une procédure de mise au rebut des supports prévoyant leur destruction ;
 établir des procédures de manipulation des supports adaptées au niveau de sensibilité de
l'information contenue
 Vérifier les mesures de sécurisation des échanges de données :
 définition d'accords portant sur les échanges d'informations et de logiciels entre les
organisations ;
 sécurité du courrier électronique.
PC6 : Conformité
 Vérifier la conformité aux exigences légales et réglementaires :
 protection des données personnelles ;
 respect de la propriété intellectuelle ;
 Conservation de l'information
 Effectuer des audits de sécurité réguliers :
 internes et externes ;
 revue systématique et tests empiriques (exemple : test d'intrusion) ;
 protection des outils d'audit des systèmes ;
 protection des rapports d'audit de sécurité.
PC6 : Gestion des identifiants et des mots de passe
 Vérifier qu'il y a un seul utilisateur par identifiant

 Vérifier que les identifiants inutilisés pendant un certain délai sont révoqués
 Vérifier que les règles de bases sont connues et mises en place :
utilisation systématique ;
 le titulaire doit être le seul à connaître son mot de passe ;
 changement périodique ;
 procédures en cas d'inactivation ou de perte.
PC7 : . Contrôle des accès

 Vérifier la définition et la documentation de la politique de
contrôle d'accès :
exigences de sécurité des applications individuelles de
l'organisation
profils d'accès standard des utilisateurs pour les catégories
communes de travail ;
établissement de règles "tout est interdit sauf" plutôt que "tout est
permis sauf" ;

 Vérifier la gestion des accès utilisateurs :
 identification unique des utilisateurs (tous les utilisateurs) ;
 vérification que l'utilisateur a été autorisé par le propriétaire des informations ;
 suppression des droits d'accès d'un utilisateur ayant changé de poste ou quitté l'organisation ;
 contrôle périodique et suppression des codes d'identification utilisateurs redondants et des comptes
qui ne sont plus utilisés
 non-réaffectation des codes d'identification ;
 attribution des privilèges aux individus sur la base de leurs "besoins minimum" par rapport à la fonction
qu'ils remplissent ;
 examen régulier des droits d'accès utilisateur.

 Vérifier l'utilisation de mots de passe et de systèmes de déconnexion
automatique :
 tout compte utilisateur doit être protégé par un mot de passe ;
 engagement des utilisateurs à :
 ne pas divulguer leur mot de passe ;
 ne pas écrire leur mot de passe de façon trop évidente ;
 ne pas stocker leur mot de passe dans une procédure automatique ;
 changer leur mot de passe dès qu'ils le soupçonnent d'être compromis ;
PC7 : Contrôle des accès

 contrôler qu'un mot de passe temporaire est envoyé pour la première
utilisation et qu'il est bien changé par l'utilisateur dès la première utilisation ;
 contrôler que les mots de passe temporaires sont transmis aux utilisateurs de
manière sûre ;
 contrôler que le système impose un changement régulier du mot de passe ;
 contrôler que le système impose le choix de mots de passe robustes ;
 discipline utilisateur pour la déconnexion ;
 la déconnexion doit être automatique en cas d'inactivité prolongée.

Vérifier le contrôle des accès aux réseaux :
authentification des utilisateurs pour les connexions externes
protection des ports de diagnostic à distance et de
télémaintenance
contrôle des flux (firewalls)

 Vérifier le contrôle de l'accès aux systèmes d'exploitation :
 identification / authentification des utilisateurs ;
 limitation du nombre de tentatives infructueuses ;
 enregistrement des tentatives infructueuses ;
 limitation des jours et heures de connexion ;
 affichage de la dernière connexion ;
 protection de l'accès aux utilitaires.
 Vérifier le contrôle de l'accès aux applications :

 Vérifier la gestion de l'informatique mobile :
 contrôle d'accès aux ordinateurs portables ;
 protection des données stockées (chiffrement) ;
 protection contre les virus ;
 connexions automatiques à distance ;
 sensibilisation du personnel doté d'ordinateurs portables :
 confidentialité du travail dans les lieux publics ou moyens de transport ;
 surveillance du matériel contre le vol ;
 espionnage industriel.

 Vérifier les suites données aux incidents :
 vérifier les réactions des possesseurs des ordinateurs incidentés ;
 vérifier les modalités effectives de remontée de l’information sur l’incident,
ses délais, son parcours, son format ;
 vérifier les mesures d’isolement du ou des ordinateurs incidentés ;
 vérifier l’effectivité des mesures de communication d’alerte ;
 vérifier l’effectivité des mesures d’enquête et de l’exploration menée
pour identifier les failles du système ayant permis l’incident.
PC8 : Développement et maintenance des systèmes

 Exigences de sécurité des systèmes :
 Expression des besoins, contrôle interne;
 spécification détaillée des besoins, contrôle interne ;
 audit des spécifications ;
 recette des fonctionnalités de contrôle interne ;
 audit de la recette ;
 audit "post mise en place".
 Sécurité des systèmes d'application :
 validation des données d'entrée : type, limites de valeur, liste de valeurs possibles ;
 contrôle des traitements : contrôles de sessions séquentielles, ;
PC8 : Développement et maintenance des systèmes

 exhaustivité des traitements ;
 validation des données de sortie :
 Protocole de recette :
 tests systématiques avant le passage en production ;
 utilisation d'un environnement différent de l'environnement de production ;
 participation des utilisateurs à la recette ;
 documentation de la recette et archivage ;
 procédure de passage en production lors des maintenances correctives
urgentes (journalisation des actions)
4 - AUDIT DES APPLICATIONS INFORMATIQUES EN SERVICE
PC1 : Audit de la sécurité et de la fiabilité : analyse des risques associés à

l'organisation
 Existe-t-il un comité informatique, présidé par la direction générale et au sein
duquel les directions utilisatrices sont représentées et influentes (stratégie,
contrôle et pilotage,..) ?
 Existe-il, au sein de l’organisation, une « politique » relative aux applications,
connue, partagée et mise en œuvre :
 couvrant l’ensemble du cycle de vie de l’application (conception, exploitation) ;
 favorisant la responsabilisation et l’appropriation par les utilisateurs de leur
système d’information ?
 Implémentant la notion de « propriété » d’application
PC1 : Audit de la sécurité et de la fiabilité : analyse des risques associés à l'organisation

 Le rôle et les responsabilités des utilisateurs vis-à-vis de l’application sont-ils
clairement identifiés et couvrent-ils l’analyse des risques, la définition des besoins de
sécurité, la gestion des changements et des évolutions, l’administration de
l’application ?
 A-t-il été réalisé une analyse des risques, spécifique à l’application, qui a débouché
sur la définition des besoins de sécurité (classification formelle des données et des
traitements en termes de disponibilité, d’intégrité et de confidentialité) ?
 Dans le prolongement de l’analyse des risques et de l’expression des besoins de
sécurité, a-t-il été mis en œuvre un contrat de service (SLA) entre l’informatique et la
direction utilisatrice ?
PC2: Audit de la sécurité et de la fiabilité : Analyse des risques associés à l'application

 L'accès aux ressources de l'application (données et transactions) est-il restreint par
un système de gestion d'accès ?
 Existe-t-il une procédure de gestion des profils utilisateurs de l'application placée
sous la responsabilité du propriétaire de l’application (procédure de création /
modification et suppression des droits d’accès) ?
 Chaque utilisateur possède-t-il un identifiant qui lui est propre ? Vérifier qu’il n’existe
pas de compte « générique »
 Le mot de passe associé à l'identifiant permet-il d'assurer une protection d'accès efficace (7
caractères minimum, gestion de l’historique des mots de passe sur 2 ans, contrôle de « trivialité »,
changement trimestriel des mots de passe, etc.) ?
PC2: Audit de la sécurité et de la fiabilité : Analyse des risques associés à

l'application
 L'accès aux données et aux transactions de l’application peut-il être
correctement paramétré en fonction des tâches des utilisateurs ou le
système de confidentialité est-il basé sur le contrôle d’accès aux données ?
 La séparation des tâches est-elle respectée dans le paramétrage des profils
?
 comparer les droits d’accès avec les fonctions des utilisateurs ;
 vérifier l’adéquation entre les droits et les profils ;
 vérifier que toutes les personnes ayant des droits d’accès sont toujours dans le
service / l’organisation.
PC2: Audit de la sécurité et de la fiabilité : Analyse des risques associés à l'application

 Les procédures de transmission de fichiers en entrée assurent-elles l'exhaustivité et
l'exactitude des informations transmises (contrôles systèmes) ?
 Les contrôles mis en œuvre lors de l'intégration des données par fichiers à
l'application sont-ils suffisants et identiques à ceux mis en œuvre dans le cadre
d’une saisie transactionnelle (contrôles applicatifs) ?
 Le système prévoit-il de conserver toutes les données rejetées dans un fichier
d'anomalies protégé et de les éditer en vue d'un contrôle et d'un recyclage ?
 Les données rejetées sont-elles analysées et corrigées dans des délais raisonnables
et compatibles avec les délais de validation des traitements ?
 Les corrections des données rejetées subissent-elles les mêmes contrôles que les
données initiales, et jouissent-elles d'une piste d'audit suffisante ?
 L'intégrité et l'exhaustivité des données transmises entre les différents modules de
l'application et/ou à des applications en aval sontelles assurées ?
PC3: Audit de la sécurité et de la fiabilité : analyse des risques

associés à la fonction informatique
 Au sein du service informatique, les tâches relatives au
développement et à l'exploitation de l'application sont-elles
séparées ?
 L'équipe en charge de la maintenance (interne ou externe) at-
elle une maîtrise suffisante de l’application et les moyens de la
faire évoluer ?
 Existe-t-il une procédure formalisée et standard de maintenance
de l’application validée par l'informatique et la maîtrise
d’ouvrage concernée ?
PC3: Audit de la sécurité et de la fiabilité : analyse des risques

associés à la fonction informatique
 Un logiciel de contrôle de programmes sources et de
programmes exécutables est-il utilisé pour identifier et tracer
toute modification effectuée (piste d'audit) ?
 . La gestion des incidents en général et les procédures
d'urgence en particulier sont-elles définies et correctement
documentées ?
 Vérifier l’existence et l’application d’un Contrat de Service (SLA)
pour l’application : vérifier que le SLA couvre les besoins de
disponibilité, d’intégrité et de confidentialité de l’application et
de ses données
PC4: Audit d'efficacité et de performance: adéquation de l’application aux

besoins
 Le projet s’inscrit-il dans le schéma-directeur du système d’information et ce

dernier est-il aligné avec le schéma directeur de l’organisation ?
 Les utilisateurs ont-ils été suffisamment associés à la définition des
spécifications ou au choix de la solution puis aux évolutions successives ?
 Les utilisateurs réalisent-ils toutes leurs tâches dans l’application (évaluation
du taux d’automatisation des opérations) ?
 L’architecture technique est-elle adaptée et optimisée, notamment les
bases de données (bon dimensionnement des configurations, gestion des
évolutions techniques, personnalisation (tuning) des bases de données, …) ?
PC5: Audit de l’efficacité et de performance : analyse de la performance et

de la rentabilité
 Le projet s’inscrit-il dans le schéma-directeur du système d’information et ce

dernier est-il aligné avec le schéma directeur de l’organisation ?
 Les utilisateurs ont-ils été suffisamment associés à la définition des
spécifications ou au choix de la solution puis aux évolutions successives ?
 Les utilisateurs réalisent-ils toutes leurs tâches dans l’application (évaluation
du taux d’automatisation des opérations) ?
 L’architecture technique est-elle adaptée et optimisée, notamment les
bases de données (bon dimensionnement des configurations, gestion des
évolutions techniques, personnalisation (tuning) des bases de données, …) ?
PC6: Audit d'efficacité et de performance : analyse de

l'évolutivité/pérennité de l'application
Les technologies utilisées sont-elles conformes aux standards
de l’organisation ?
Le logiciel est-il de conception récente et fondé sur des
technologies portables, non obsolètes et évolutives
(matériel, OS, SGBD, outils de développements, …)
Les technologies utilisées sont-elles matures et suffisamment
répandues sur le marché (Linux, J2EE, .net,..) ?
PC6 :Audit d'efficacité et de performance : analyse de

l'évolutivité/pérennité de l'application
 Les technologies utilisées sont-elles conformes aux standards de
l’organisation ?
 Le logiciel est-il de conception récente et fondé sur des technologies
portables, non obsolètes et évolutives (matériel, OS, SGBD, outils de
développements, …)
 Les technologies utilisées sont-elles matures et suffisamment
répandues sur le marché (Linux, J2EE, .net,..) ?
 Le contrat prévoit-il une clause dite d’ « Escrow Agreement »
permettant de disposer des sources, auprès d’un tiers de confiance,
en cas de défaillance de l’éditeur ?
 Les montées de versions sont-elles régulièrement effectuées ?
5 - AUDIT DU SUPPORT UTILISATEURS ET DE LA GESTION DU PARC
PC1. Fonction support : audit fiabilité et sécurité

 Quelle structure de centre d’assistance (help-desk) (HD) est mise en
place
 Existe-t-il une procédure de gestion des demandes, diffusée et
connue des utilisateurs ?
 Quelle est la procédure d'escalade mise en place ?
 Quelle est la couverture géographique du HD ?
 Quelle est la couverture fonctionnelle du HD ?
 Un outil est-il implémenté pour la prise d'appel et le suivi des tickets ?
 Quelles sont les critères à renseigner pour la qualification des tickets ?
PC1. Fonction support : audit fiabilité et sécurité

 Les problèmes sont-ils gérés ? Si oui quel est le processus ?
 Les incidents de production de nuit sont-ils saisis aussi dans l'outil
?
 Quels sont les comités mis en place pour suivre les incidents et
leur résolution ? Qui participe ? Comment sont suivies les actions
?
 Si le HD est externalisé, existe-t-il un contrat de service ?
 Quels sont les indicateurs pour suivre le contrat de service ?
 Y-a-t-il un planning systématique concernant les mises en
production ?
PC2. Fonction support : audit d'efficacité et de performance
Existe-t-il une aide à la saisie pour la saisie des tickets ?
Existe-t-il des revues qualité pour la saisie des tickets ?
Quelle est la procédure de mise à jour de la base de
connaissance ?
Les appels sont-ils enregistrés ?
Des études de satisfaction sont-elles réalisées auprès des
utilisateurs ?

Les certifications (ITIL, ISO, COBIT) sont-elles encouragées au
sein de la DSI, du HD en particulier ?
Interroger le DSI, le responsable HD, des utilisateurs, l'équipe
HD – si possible, participer « à la vie du HD »
Demander la stratégie de formation des utilisateurs et de
l’équipe Help-Desk.
Demander les reportings de suivi
Demander les études de satisfaction

Les certifications (ITIL, ISO, COBIT) sont-elles encouragées au
sein de la DSI, du HD en particulier ?
Interroger le DSI, le responsable HD, des utilisateurs, l'équipe
HD – si possible, participer « à la vie du HD »
Demander la stratégie de formation des utilisateurs et de
l’équipe Help-Desk.
Demander les reportings de suivi
Demander les études de satisfaction
PC3. Gestion du parc matériel et logiciel : audit fiabilité et sécurité

 Quelle est la procédure de déploiement des mises à jour, d’un
nouveau logiciel ?
 Quels sont les outils mis en place pour gérer les versions des logiciels ?
 Quels sont les outils mis en place pour gérer le matériel informatique ?
 L'installation des PC / portables est-elle faite à partir d'un master
(configuration minimum et standardisée) ?
 Existe-t-il un processus spécifique pour le suivi des mises à jour sur les
portables ?
 Le déploiement de nouveaux logiciels ou mises à jour est-il possible à
distance ? (utile pour les utilisateurs nomades)
PC3. Gestion du parc matériel et logiciel : audit fiabilité et sécurité

 Est-il possible pour le HD de prendre la main à distance ? Si oui,
quelle est la procédure ?
 L'inventaire du parc informatique comprend-t-il la localisation
des machines ?
 Les logiciels "non officiels" sont-ils répertoriés et suivis ?
 Les utilisateurs sont-ils sensibilisés à la sécurité informatique,
notamment à l'installation de logiciel "non officiel" ?
 Faire des copies d’écran ou d’extraction des outils de suivi des
mises à jour/déploiement. Vérifier sur les postes utilisateurs les
versions antivirus, firewall, version Windows, version IE
PC4. Gestion du parc matériel et logiciel : audit d'efficacité et de

performance
 Comment est effectué l'inventaire des licences (logiciel, version,
date de mise en production, nombre d'utilisateurs) ?
 Outils de type SAM (Software Asset Management) sont-ils
déployés ?
 Existe-t-il des revues régulières des licences ?
 Existe-t-il une base de données de gestion de configuration de
type CMDB (Configuration Management DataBase)
 La DSI est-elle sensibilisée aux enjeux de la maîtrise des licences ?
IX- FACILITATEURS D’AUDITS DES SI
Outils d’analyse de la sécurité
Les outils d’analyse de la sécurité peuvent globalement être répartis en
catégories suivantes :
 Outils d’analyse de réseau : Ce sont des logiciels que l’on peut lancer sur un
réseau pour recueillir des informations sur son état.
 Les auditeurs SI y font recours pour diverses procédures dont entre autre :
 La vérification de l’exactitude des diagrammes de réseau par une cartographie du réseau
d’entreprise
 L’identification des dispositifs clés du réseau
 La collecte des informations concernant le trafic autorisé sur un réseau
 NB : Ia liste des outils les plus utilisés se trouve sur www.insecure.com
 Outils de piratage
Les outils de piratage offrent une solution automatisée pour vérifier les vulnérabilités des mots de passe
et des identifiant. Ils sont pour les parefeux, les serveurs, les réseaux et les systèmes d’exploitation.
 Outils d’analyse de la sécurité des applications
la sécurité des applications doit être conçue et mise au point en parallèle des processus et des
contrôles applicatifs de manière à intégrer un environnement qui inclus tous les processus
management, opérationnel et support)
 Ces outil permettent également d’évaluer la séparation des fonctions au sein d’une application
Quelques fournisseurs dans ce domaine sont :
 Approva : http://www.approva.net/
 LogicalApps : http://www.logicalapps.com/
 Q Software : http://www.qsoftware.com/index.htm
 Control Solutions International : http://www.csi4sap.com/en/home
 Outils d’analyse des données
Il permettent de faire des statistiques sur les caractéristiques

des données et d’avoir une vue sur e l’utilisation des données
dans les différents processus
les principaux fournisseurs de ces outils sont :
ACL : http://www.acl.com/Default.aspx?bhcp=1
Idea : http://www.audimation.com/product_feat_ benefits.cfm
Monarch : http://monarch.datawatch.com/
SAS : http://www.sas.com/
 Logiciel de diagrammes de circulation
Il permet de représenter graphiquement les flux de
transactions pour l’illustration de la circulation des données
à travers les processus
 Logiciel de suivi des questions en suspens

Ce type de logiciel permet d’effectuer un suivi des questions restées
en suspens ou des défaillances/anomalie observées mais qui sont en
cours de réparation
X- MODÈLE DE LA STRUCTURE D’UN RAPPORT D’AUDIT DES SI
1- Présentation de la couverture
1. Nom du bureau d’audit y compris le logo
2. Nom de l’organisation auditée y compris le logo
3. Intitulé du document. Exemple: Rapport d’audit du SI de….
4. Nom de l’expert auditeur (celui qui conduit les travaux)
5. La signature de l’expert auditeur
6. Date du document, version le cas échéant
7. Le socle document confidentiel
2- Première de couverture
1. Avant propos (clause de confidentialité, de reproduction du
document, l’historique des modifications, le cas échéant )
3-Cadre de la mission
1. Rappeler le cadre de la mission d’audit
2. Indiquer si la présente mission est un audit exhaustif ou audit de suivi
3. Présenter l’objectif de la mission d’audit (Etat de conformité par rapport à un
standard, recommandations, plan d’action)
4. Indiquer, le cas échéant, si la présente mission rentre dans le cadre de la
préparation à la certification ou dans une démarche de conformité
5. Indiquer, la cas échéant, le(s) standard(s) métier de référence par rapport auquel
est réalisée la présente mission d’audit,
6. Indiquer les limites et les contraintes de l’audit
4-Termes et définitions
 Donner les définitions des termes utilisés dans le présent rapport
5-Références
Indiquer tous les documents de référence utilisés pour la
réalisation de la mission d’audit
6-Présentation de l’organisme audité
1. Présenter brièvement l’organisme audité (création, nombre
d’employés, étendu géographique, missions, services fournis,
parties prenantes, clients, etc)
2. Présenter le champs audité avec les processus y afférents
7- Champ d’audit
1. Périmètre géographique (Présenter la liste des département concerné
et à auditer en justifiant leur choix)
2. Description des systèmes d’information
3. Décrire les systèmes d’information des différentes
départements (Composants : serveur, application, base
de données, équipement réseau, solution de sécurité,
d'administration du système d'information)
4. Toute exclusion d'un composant doit être justifiée.
7- Champ d’audit
1. Schéma synoptique de l’architecture du réseau(vue
infrastructure)
2. Faire apparaitre les connexions (LAN, WAN, etc), la
segmentation, l’emplacement des composantes du SI, etc…
8- Méthodologie d’audit
1. Décrire en détail la méthodologie d’audit adoptée tout en
établissant la correspondance entre les domaines couverts et les
référentiels d’audit utilisés
2. Présenter les outils (version, licence, fonctionnalité, etc) d’audit
utilisés
8- Méthodologie d’audit
3-Présenter l’équipe d’auditeur
4-Présenter l’équipe audité
5-Présenter le planning d’exécution de la mission
d’audit
9- Synthèse des résultats de l’audit

1. Rappeler les critères et les standards/référentiels par
rapport auxquels l’audit a été réalisé
2. Rappeler la responsabilité de l’auditeur et les limites de
l’audit (échantillonnage, changements depuis l’audit
3. Rappeler les types et nature de test réalisés pour établir
ces résultats
4. Donner, le cas échéant, une évaluation détaillée de la
réalisation du plan d’action issu de la dernière mission
d’audit
9- Synthèse des résultats de l’audit

5-Présenter une synthèse des principales
pratiques identifiées et défaillances
enregistrées lors de l’audit,
6- Présenter une appréciation générale du
domaine audité
9- Présentation détaillée des résultats de l’audit
1. Présenter le domaine du référentiel d’audit exploité

2. Présenter la vulnérabilité/le risque
3. Décrire la démarche adoptée d’appréciation des
vulnérabilités/risques
4. Présenter l’appréciation des vulnérabilité/risque
5. Présenter la liste des contrôles/mesures vérifiés considérés
comme critères d’audit
6. Présenter les bonnes pratiques identifiées
7. Donner le conseil/la recommandation
10- Plan d’action

1. Organiser par projets les actions/recommandations
associées aux différentes vulnérabilités décelées.
2. Indiquer que le plan d’action est établit en commun
accord avec l’audité
3. Indiquer que le plan d’action prend en considération les
objectifs, les projets en cours et les perspectives de l’audité
4. Faire les estimations sur la base d’un dimensionnement
adéquat des besoins de l’audité (théorie du flocon de
neige), capacités humaines et financières…
11- Liste des annexes
REFERENCES BIBLIOGRAPHIQUES
1. Certification Information Systems Auditor, 27th Edition 2019, ISACA

2. Support de cours de l’audit des systèmes d’information, raphael yende, 2018
3. Management de l’audit des Systèmes d’Information, 2ème édition, Global Technology
Audit Guide, 2013
4. Mesurer la performance du système d’information, David Autissier, 2008
5. Capability Maturity Model Integration (CMMI) – IT Infrastructure Library (ITIL) –
ISO 27001
6. http://www.sei.cmu.edu
7. http://www.itil-officialsite.com
8. http://www.sans.org
9. http://www.opengroup.org

Cours SI M2

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours SI M2

Transféré par

Droits d'auteur :

Formats disponibles

AUDIT DES SYSTEMES

Acquérir les fondements de l’audit des systèmes

Initier les apprenants aux principaux concepts

 Les systèmes d'information sont au cœur des industries de

 A travers les réseaux qui ont de plus en plus une architecture

 Son bon fonctionnement contribue à la performance de

▪ Les SI sont aujourd'hui un support essentiel de l’organisation et le moteur

▪ Le SI est de nos jours reconnu dans la théorie du management

▪ Le système d’information a pour finalité d’offrir un meilleur service aux

Un SI est l’ensemble de ressources (matériel, logiciel,

Interactions des sous-systèmes à travers des services

4- Les SI Standardisé : Caractéristiques

Couts : Centre d’investissement pour l’entreprise

Objectifs : Alignement aux orientations de la structure

Technique : Tient compte des contraintes technologiques de développement , de

Réglémentation : Conformité reglementaire interne et externe

Stockage : Capacité de stockage illimité

L’ensemble des progiciels utilisés dans une

 Le Petit Larousse définit l’audit comme « une procédure consistant

 L’audit des SI diffère fortement de l’audit financier ou opérationnel,

 L’audit est une méthode d’évaluation rigoureuse qui possède sa propre

 L'audit des systèmes d'information évalue les risques liés à l’environnement

 Un audit régulier des systèmes entre en effet à l’intérieur d’une

 L'audit des systèmes d'information évalue les risques liés à

Illustration : Théorie du flocon de neige

Caractéristiques des risques SI : Prolifération

Généralement, lorsqu’on est dans une situation de risque

Les catégories de risques SI : Risque pervasif

C’est un risques qui a une incidence sur l’ensemble de

C’est un risque directement lié à un processus spécifique

 C’est un risque qui n’évolue guère d’une année sur l’autre et

 Assister l'équipe de projet à évaluer les risques lors des

Assister l'équipe de projet à évaluer les risques lors des

 Assister l'équipe de projet à évaluer les risques lors des différentes

Il est important d'effectuer un pré-diagnostic afin de

▪ Cadrage et planification de la mission

1- Cadrage et planification de la mission

Cette phase a pour objectif de :

1- Cadrage et planification de la mission

Définir une approche d’audit et d’organisation des travaux

 Définir le planning d’intervention ;

Définir les modes de fonctionnement et de communication.

Cette étape vise à recueillir les éléments relatifs au

▪ de comprendre les risques et les contrôles liés au SI

▪ de comprendre comment le SI contribue à la

Cette phase se fait sur la base de trois aspects notamment :

➢L’alignement de la stratégie SI à celle de l’entreprise

➢Le mode de gestion et d’organisation de la fonction SI :

▪ Les caractéristiques des systèmes hardware utilisés (leur

3- Identification et évaluation des risques

4-Identifier les contrôles clés : Il s’agit d’identifier les risques liés au SI et

5- Evaluer la conception des contrôles clés : Il s’agit d'arriver à dégager

6- Vérifier l’efficacité : il s’agit d’apprécier la pertinence des

7- Les tests de procédure et les contrôles de substance : il

8- la Communication et le rendu des conclusions

L'auditeur se sert des référentiels qui lui permettent d’évaluer la

la conformité au cadre normatif (Procédure, lois, règlements…)

la fiabilité (sécurité) du systèmes (équipement, applicatifs…) et

la réalisation et l'optimisation des opérations (traitements)....

ISACA : Information Systems Audit & Control Association) est

L'auditeur dispose d’une gamme variée de référentiels

CMMI se décline en trois modèles appelés « constellations » dont

Les objectifs spécifiques : les objectifs spécifiques sont