Cours Auditinformatique 2014 2015 OK

ISP-BUKAVU
Audit informatique
2ème année de Licence en Informatique de gestion
CT Bulabula Kizungu Dema Mayaba
Cours d’Audit informatique
Chapitre 0 : Introduction.................................................................... 2
0.0. Motivation ............................................................................. 2
0.1. Le contexte ........................................................................... 5
0.2. Les objectifs .......................................................................... 6
Chapitre 1 : Principes et règles de l’audit informatique ............................... 7
1.1. Définition et types ................................................................... 7
1.2. Principe d’audit ...................................................................... 9
1.3. Règles d’audit ........................................................................ 9
1.4. Objectifs de l’audit ................................................................. 11
1.5. Démarches de l’audit ............................................................... 15
1.6. Déontologie de l’audit ............................................................. 16
1.7. Types d’erreurs...................................................................... 16
1.8. Spécificités de l’audit informatique ............................................. 17
Chapitre 2 : L’audit des objectifs informatiques ....................................... 22
2.1. Préliminaires ......................................................................... 22
2.2. La politique informatique.......................................................... 23
2.3. Le schéma ou le plan directeur ................................................... 25
Chapitre 3 : L’audit des moyens informatiques ........................................ 27
3.1. Les moyens techniques ............................................................. 27
3.2. Ressources humaines ............................................................... 29
3.3. Audit des moyens financiers ....................................................... 30
Chapitre 4 : L’audit spécifique des entreprises d’informatique ..................... 31
4.1. Audit de service informatique .................................................... 31
4.2. Audit des projets informatiques (développement des logiciels) ............. 31
4.3. Audit d’entreprises faisant des études informatiques ......................... 34
4.4. Audit d’entreprises installant des logiciels ..................................... 34
Chapitre 5 : Déroulement de l’audit informatique..................................... 35
5.1. Plan de travail ....................................................................... 35
5.2. Lettre de soumission et programme fiscal ...................................... 35
5.3. Considérations stratégiques ....................................................... 35
5.4. Ressources de l’auditeur ........................................................... 36
5.5. Travaux de l’auditeur .............................................................. 36
5.6. Rapport de l’audit .................................................................. 36
5.7. Le suivi de l’audit ................................................................... 37
Cours d’Audit Informatique en L2 Informatique de Gestion, 2014-2015 (CT Bulabula) Page 1

Introduction
0.0. Motivation
De la nécessité de l’audit informatique dans les entreprises publiques
congolaises
Par Le Potentiel
http://www.lepotentiel.com/afficher_article.php?id_edition=&id_article=40503
du 30/01/2007
Aujourd’hui, l’utilité de l’ordinateur n’est plus à démontrer dans la vie
courante tout comme dans la vie des organisations publiques et privées,
l’ordinateur est devenu l’un des instruments indispensables de gestion
courante de celle-ci. Car, face à la pluralité et la complexité des activités
que développent ces entreprises, l’apport des techniques du traitement
automatique de l’information par l’ordinateur s’est avéré indispensable non
seulement pour le gain de temps qu’elles permettent, mais également pour la
qualité du travail qu’elles fournissent.
Cet article se propose de réfléchir sur la nécessité de l’audit du système
informatique ou audit informatique dans les entreprises publiques congolaises, et
ce, à travers différents aspects du traitement informatique. Si, d’ores et déjà, il
semble opportun d’affirmer avec force cette nécessité au sein des entreprises
publiques de la RDC à l’instar des autres pays qui ont déjà pu moderniser leurs
services publics, il importe de préciser que le contrôle peut être a priori ou a
posteriori. De même, habituellement on distingue le contrôle interne, le contrôle
externe et le contrôle par les usagers. Le contrôle a priori repose sur la
prévoyance des problèmes potentiels. Il vise la prévention des problèmes avant
qu’ils ne surviennent et va de pair avec la planification. Le contrôle interne
s’effectue, au sein d’une entreprise, de deux manières: par le pouvoir
hiérarchique qui participe aux fonctions de commandement au sein de service, et
par des organes internes chargés du contrôle et de la vérification.
En principe, le contrôle externe appartient au commun de mortels à travers les
organes législatifs. Mais, il peut aussi être exercé sous forme de pression par des
groupes organisés, indépendants en vue d’obliger les hauts cadres de
l’Administration à jouer leur rôle de responsables du bien-être. Ce contrôle sur
l’entreprise publique peut être exercé par des organes qui représentent les
intérêts privés ou l’opinion publique à travers la FEC, les syndicats, les
représentants des organismes internationaux tels que le FMI, la Banque mondiale,
etc.
Tout bien considéré, il est établi que l’acte de contrôle intervient souvent après
d’autres activités non moins importantes telles que la planification et la
définition des objectifs, l’organisation structurelle et la répartition des tâches
d’exécution. Nous sommes d’avis avec E. T Harner et C. Ford que les quatre
éléments ci-dessous sont indispensables pour l’exercice du contrôle. Il s’agit
singulièrement de :

1. les critères de performance ou les standards suivant lesquels la
performance peut être jugée;
2. l’information qui permet de suivre le déroulement actuel des opérations et
d’être au courant des événements;
3. le pouvoir, ou l’autorité de prendre des mesures d’ajustement et de
correction lorsqu’elles sont requises par la situation ;
4. la compétence pour exécuter la meilleure solution dictée par les
alternatives prévalentes».
ETAT DES LIEUX DES ENTREPRISES PUBLIQUES

A la question de savoir qui peut commettre une fraude, Il y a lieu de dire qu’il
s’agit du personnel à tous les échelons hiérarchiques dans l’entreprise; du
propriétaire de l’entreprise lui-même, des tiers, clients, fournisseurs, bailleurs de
fonds, etc. qui peuvent participer à la fraude.
Parmi les cas les plus fréquents de fraude, nous épinglons: la falsification du bilan
ou des statistiques en vue d’une promotion du maintien de poste ou de
l’obtention d’une gratification, le détournement des bénéfices au préjudice du
fisc, des associés ou même de créanciers, l’acte qui consiste à dérober des
espèces, outils, marchandises, déchets; le fait de recevoir des rétributions ou des
avantages de clients ou des fournisseurs, sous forme de commission (pots-de-vin),
saler une note de frais, être de connivence avec des fournisseurs, à l’effet de
surfacturer les fournitures faites à l’entreprise, facturer des prestations fictives.
Pour une mise en route d’un audit informatique au sein des entreprises publiques
en RDC, il faut s’assurer de la performance dont il ferait montre eu égard les
insuffisances liées à un certain nombre de paramètres. D’où la nécessité d’un
état des lieux en la matière.
Une observation fouillée du parc informatique utilisé au sein des entreprises

publiques congolaises dénonce cinq principales failles que voici:
1. Vétusté du matériel informatique. Nos parcs informatiques sont
caractérisés par leur vétusté et l’obsolescence. La plupart des ordinateurs
utilisés sont complètement amortis, et ne supportent pas les logiciels
récents tournant dans l’environnement Windows ou Linux. L’âge de ces
machines varie entre 6 et 20 ans alors que leur durée de vie prévue par le
fabriquant est de 5 ans. D’ailleurs, certaines d’entre elles connaissent déjà
des arrêts intempestifs et peuvent s’arrêter définitivement à tout moment
et priver ainsi les gestionnaires de l’information dont ils ont besoin pour la
prise de décision.
2. Difficulté de trouver des pièces de rechange. Compte tenu de leur âge, ces
types de matériels ne sont plus fabriqués et posent ainsi le problème de
remplacement en cas de panne.
3. Manque de recyclage du personnel informatique. Excepté quelques
formations ponctuelles sur l’utilisation des outils récents, le personnel
informatique n’a pas été recyclé dans divers domaines, à savoir la
planification informatique, l’organisation, la conception des systèmes
d’information, l’analyse et la programmation en langage orienté objet,

l’utilisation de nouveaux systèmes d’exploitation ; bureautique,
maintenance des ordinateurs, etc.
4. Maintenance irrégulière du matériel informatique. Dans un environnement
caractérisé par des problèmes sociopolitiques dont l’impact négatif sur les
affaires n’est plus à démontrer, les entreprises congolaises, à cause des
difficultés financières qu’elles subissent, sont incapables de faire face aux
frais liés à la maintenance de leurs parcs informatiques.
5. Inexistence d’un Plan directeur informatique pour définir la politique
d’informatisation de l’entreprise. L’inexistence des Plans informatiques
dans la majorité des entreprises laisse entrevoir un manque d’orientations
précises que doivent prendre les sociétés dans le domaine informatique
pour les prochaines années. Les sociétés sont contraintes aujourd’hui de
naviguer à vue dans ce domaine. Cela ne permet pas du tout de suivre
l’évolution technologique et de disposer des machines, des logiciels et du
personnel performants capables d’assurer un appui efficace à la gestion de
l’entreprise.
6. Insuffisances de matériels pour couvrir les besoins de tous les centres
d’exploitation. La non application des Plans directeurs informatiques par
les entreprises qui en possèdent, due essentiellement au manque de
financement se traduit par une informatisation incomplète de diverses
entités. Ainsi, force est d’exécuter des travaux manuels fastidieux. De ce
qui précède, il y a nécessité absolue de créer un environnement
informatique sain au sein des entreprises publiques. 8° Nécessité de la
création d’un environnement informatique sain au sein des entreprises
publiques. La technologie a fort évolué avec la mondialisation. Ainsi, les
entreprises publiques ne se contentent plus que de fournir quelques
services au public. Elles s’efforcent aussi d’apporter leur pierre à la
réalisation des missions dites modernes de l’Etat. Cette lourde et difficile
responsabilité de l’Etat moderne exige un outil subséquent; l’ordinateur
susceptible de traiter automatiquement l’information. Cependant,
l’ordinateur, seul, ne peut rien donner de bon. Il faut qu’il soit manié par
un personnel suffisamment formé, capable de s’en tirer les meilleurs
résultats selon les besoins. En outre, l’ordinateur et l’opérateur ne
suffisent pas non plus. Il faut leur adjoindre des logiciels les plus
performants pour des exploits extraordinaires en vue de se positionner sur
l’échiquier informatique mondial. Cette trilogie matérielle, logicielle et
personnelle démontre l’importance de la création d’un environnement
informatique adéquat dans les entreprises publiques. En effet, les progrès
techniques apportent beaucoup d’avantages aux entreprises qui les
adoptent. Il faut retenir que l’augmentation considérable de la vitesse
d’exécution des machines entraîne la réduction de temps de traitement, la
diminution considérable des coûts des matériels. L’avènement de la mini et
de la micro-informatique a permis la réduction du coût d’acquisition des
machines. Cela s’est traduit par l’accroissement et la généralisation de
l’utilisation des moyens informatiques en RDC.

DES PISTES DE SOLUTIONS
L’optimisation du traitement de l’information au sein de l’entreprise représente
aujourd’hui un gisement inépuisable de performance. Sur le terrain, pour
survivre, les organisations doivent a nécessairement s’adapter à leurs nouvelles
contraintes. Elles doivent appréhender et maîtriser la gestion de l’information et,
par extension, celle de leur système d’information.
Par conséquent deux types de solutions liées aux besoins de l’entreprise sont
envisageables : les solutions liées aux besoins permanents et celles liées aux
besoins ponctuels. Les solutions liées aux besoins permanents préconisent la
présence d’un service d’audit pour piloter toutes les activités de l’audit au sein
de l’entreprise.
A ce stade, les décideurs doivent garantir l’indépendance à assurer à l’auditeur
par rapport au service qu’il doit rendre, étant donné que c’est un service qui doit
contrôler les autres. Il doit aussi être bien positionné afin de jouir d’une
indépendance vis-à-vis des services contrôlés et aussi de l’autorité nécessaire à la
réalisation de ses missions. Ceci garantit la mise en application des
recommandations faites par l’auditeur.
Quant aux solutions liées aux besoins ponctuels, celles-ci consiste à externaliser
des fonctions qui étaient précédemment internes ou à confier à une société
extérieure des fonctions qu’on pourrait assurer en interne. On peut externaliser
l’ensemble de l’informatique ou se limiter à une partie, par exemple l’entretien
du matériel ou le help-desk. , Du point de vue financier, le but de l’infogérance
n’est pas de diminuer les coûts: c’est le couple coût-valeur qui importe. Du point
de vue organisationnel, on cherche à aider l’organisation à accomplir les tâches
qu’il serait difficile ou peu judicieux de prendre en charge en interne, et, par là,
à l’aider à se développer.
Le souci majeur a été donc de convaincre que l’application d’un audit
informatique au sein de l’entreprise offre beaucoup d’avantages en matière de
sécurité, ‘de performance et évolution du système informatique tout entier dans
son environnement. En effet, le temps ayant changé, les entreprises ont
démontré leur besoin d’une nouvelle façon de gérer le quotidien: ce qui a justifié
l’importance de la création d’un environnement informatique au sein d’elles.
(*) Licencié en informatique de gestion, en sciences et techniques documentaires
de l’Institut Supérieur de Statistique de Kinshasa, et Assistant au département de
l’informatique de cette institution. Il se spécialise en système d’information et
réseaux informatiques.
JEAMPY MBIKAYI M’PANYA (*)
0.1. Le contexte
De nombreux auditeurs et des consultants constatent les difficultés rencontrées
par les entreprises en informatique. Les décideurs s’interrogent sur les choix
informatiques à effectuer. Pour ces raisons ils sont amenés à lancer des audits
informatiques. Même, s'ils n'effectuent pas eux-mêmes la mission et qu'ils la
confient à un auditeur spécialisé, il est important de comprendre la démarche de

façon à apprécier ce qui est commun à toutes les démarches d'audit et ce qui est
spécifique à l'audit informatique.
Ce cours initie à un étudiant du niveau de licence en Informatique de gestion (qui
a acquis une certaine connaissance de l'informatique et notamment de ses modes
d'organisation et de fonctionnement), auditeur généraliste, à un expert-
comptable, à un commissaire aux comptes, à un consultant en informatique et en
organisation,… d'acquérir rapidement une vision d'ensemble des principales
démarches mises en œuvre dans le cadre des missions d'audit informatique.
C’est pour un futur auditeur informatique une bonne initiation au métier qui
pourra être ensuite complétée par des audits plus spécialisés comme l’audit des
projets ou le management de la sécurité informatique.
0.2. Les objectifs

- Fournir en 30 heures (15 heures de théorie et 15 heures de Travail pratique
dans une entreprise informatique) une information de synthèse donnant
une vue globale de l’audit des systèmes d'information à des décideurs et
des auditeurs de façon à leur permettre d'apprécier les possibilités offertes
par cette démarche.
- Identifier les points-clés de la démarche d'audit appliquée à l'informatique
et aux systèmes d'information

Chapitre 1 : Principes et règles de l’audit informatique
1.1. Définition et types

1.1.1. Définition
Audit vient du mot latin AUDIRE qui signifie écouter, faire un diagnostic.
Il s’agit donc d’une activité qui diagnostique les forces et les faiblesses d’un
système en référence à des objectifs déclarés ou sous-entendus, qui analyse les
raisons de ces lacunes et qui propose un plan d’action afin que le service audité
réponde aux besoins et exigences de l’entreprise en terme de qualité de service,
de sécurité, d’efficacité, de cohérence, …
On peut auditer n’importe quoi : un service taxi, un enseignement… Les objectifs
doivent donc être clairs au départ.
L’auditeur doit dresser la liste d’objectifs en fonction desquels il fait le
diagnostic des faiblesses (pas souvent des forces).
Si les faiblesses n’existent pas, l’audit en général ne se justifiera pas. Comme en
médecine, s’il n’y a pas de maladies, le médecin n’est pas sollicité pour un
diagnostic, …, avant de tirer un plan de guérison…
Un audit se fera donc en quatre étapes successives suivantes :

1) la clarification des objectifs ;
2) le diagnostic ;
3) l’analyse et
4) le plan d’action.
1.1.2. Types d’audit

Deux types d’audit à différencier :
L’audit externe à être réalisé par un expert ou une société différente de
l’entreprise auditée.
L’audit interne à être réalisé par un autre service que le service audité
(exemple : dans une entreprise donnée qui a un service de contrôle et de qualité
qui est habilité à faire des audits dans les autres services) ou par le service lui-
même (dans ce cas, on parle d’auto-évaluation).
NB : Les entreprises sans auto-évaluation risquent de fonctionner normalement.
Une entreprise doit consacrer une journée pour faire l’audit interne.
Pourquoi un audit externe ?

Les demandes d’audit portent principalement sur des structures, des programmes
ou des projets. Selon le cas, les questions posées diffèrent, avec des
recouvrements significatifs.
Dans le cas d’un audit de structure, le commanditaire demande d’abord une
analyse des services qu’elle rend à des clients internes ou externes, avec une
appréciation d’une part sur le périmètre (le « catalogue »), d’autre part sur la
qualité de service, mesurée ou perçue. Il souhaite ensuite vérifier comment
l’organisation mise en place utilise les moyens et régule les coopérations de la

structure étudiée au sein de l’entreprise concernée et avec ses fournisseurs. De
façon plus spécifique, la demande inclut parfois une analyse du traitement des
projets prioritaires au sein de la structure.
Pour un audit d’un grand projet, la focalisation change radicalement et l’audit se
concentre sur l’alignement du projet avec la stratégie de l’entreprise, le
pilotage, la maîtrise du budget et du calendrier, la qualité technique de la
solution, la conduite du changement.
L’audit d’un grand programme combine les deux types de demandes précédentes:
le programme coordonne plusieurs projets sur une assez longue durée. Il a donc
une structure pérenne dont l’objectif majeur est de livrer progressivement les
sous-ensembles fournis par les projets, en assurant leur coordination technique et
leur synchronisation.
Les contraintes qui s’imposent à l’auditeur externe sont néanmoins similaires

entre les différents cas. En premier lieu, le délai est toujours très réduit, de
l’ordre de quelques semaines sur des périmètres parfois très complexes, avec un
grand nombre d’acteurs. En effet, l’audit est souvent motivé par une situation de
difficulté où les décisions ne peuvent être repoussées trop longtemps.
Même pour un audit préventif, le commanditaire souhaite que la perturbation
qu’il introduit soit d’une durée limitée. L’auditeur se doit d’étayer ses constats
sur une convergence de pièces et de témoignages, mais il lui est demandé de
collecter ces éléments en perturbant au minimum l’objet d’étude !
Une autre exigence porte sur l’exhaustivité. Même si les questions posées sont
assez précises, l’auditeur ne peut ignorer des thèmes au risque de laisser dans
l’ombre des facteurs de risque grave.
Le commanditaire recherche enfin une indépendance totale de l’audit par
rapport aux acteurs de la structure, du programme ou du projet examiné.
Ces variantes et ces contraintes s’appliquent à un service d’audit interne comme
à une équipe externe.
L’appel à un audit externe, alors qu’il existe un service interne, s’explique
souvent par la recherche d’une combinaison spécifique de compétences, qui sont
nécessaires pour aborder les différentes facettes du sujet : la compréhension du
métier doit s’allier à la maîtrise des enjeux d’organisation, de conduite de
projet, d’architecture informatique, de transformation. La demande est d’ailleurs
parfois de conduire une démarche de coopération entre les auditeurs internes et
externes.
Les avantages de l’audit interne sont la compétence, l’impartialité, la neutralité,

l’exhaustivité, (l’expert va ne pas se focaliser sur un sujet, un objet, par contre,
il pose les questions générales : cf. audit général), l’extériorité (regard externe),
la clarté (on peut dire les choses comme elles se présentent).
Les désavantages de l’audit externe.

 Il coûte très cher car il est fonction du temps que l’auditeur passe dans
l’entreprise si cette dernière renferme plus services…

 L’extériorité : l’audit extérieur. On peut rencontrer à l’auditeur n’importe
quoi, il peut être manipulé par les personnes interviewées car il ne connaît
pas l’histoire de l’entreprise.
 La rapidité : le temps passé dans un service…
Les avantages de l’audit interne : le contraire de l’audit externe.
1.2. Principe d’audit

D’abord, comme dans toute branche de l’activité d’une entreprise, l’audit doit
exister en informatique, et même davantage en fonction des vulnérabilités et des
coûts qu’elle induit.
Un audit informatique n’a de sens que si sa finalité est définie : contrôle fiscal,
juridique, expertise judiciaire, vérification de l’application des intentions de la
direction, examen de l’efficacité ou de la sécurité d’un système, de la fiabilité
d’une application, etc.
Exemple.– Une « évaluation du système informatique », pourtant souvent

proposée commercialement, n’a aucun sens. Le terme implique une notion de
valeur, donc chiffrée, subjectivement avec une référence par conséquent, alors
qu’aucune notation n’a de fondement objectif. Ne sont fondées que des
approches par aspects sur objets, exprimées concrètement par « tel composant
du système, sujet de la mission, présente telles qualités et tels défauts ».
PRINCIPE.– Auditer rationnellement est expliciter les finalités de l’audit, puis en

déduire les moyens d’investigation jugés nécessaires et suffisants.
Pratiquement, c’est apprécier dans un but précis, et une situation concrète
observée (le « comment »), l’application du principe et des règles (le
«pourquoi»).
1.3. Règles d’audit

Quel que soit le type de l’audit (interne ou externe, contractuel ou légal, etc.),
la finalité est toujours de porter un jugement sur le management du système
d’information et l’exécution de ses objectifs. C’est donc la comparaison entre ce
qui est observé (un acte de management ou d’exécution) et ce que cela devrait
être, selon un système de références.
Il est clair que le jugement ne peut se limiter à une approbation ou plus souvent à
une condamnation, qui serait totalement inutile en soi aux audités, mais préciser
ce qu’il aurait fallu faire, et ce qu’il faudra faire pour corriger les défauts
constatés.
Exemple.– Une conclusion peut être que la documentation d’une application est
globalement compréhensible, mais qu’il faut la mettre à jour car elle n’est plus
exactement en phase avec la maintenance de la dernière année, qui a négligé ce
point.

REGLE.– L’audit informatique consiste à comparer l’observation d’un ou plusieurs
objet(s), selon un ou plusieurs aspects, à ce qu’il(s) devrai(en)t être, pour porter
un jugement et faire des recommandations.
La tâche de l’auditeur est parfaitement définie quand l’objet et l’aspect le sont.
Et elle ne doit pas en déborder.
Exemple.– S’il lui est demandé de vérifier la sécurité d’une application, et qu’il
en est satisfait, il est complètement indifférent de savoir si les résultats en sont
exacts, car c’est une question de fiabilité ; ou qu’ils sont absolument inutiles, car
il s’agit d’adaptation.
En effet, l’auditeur ne doit jamais remettre en cause la finalité de son audit en
fonction de ce qui est plus simple, ou plus intéressant de faire, selon ses goûts.
Il est beaucoup plus facile de formuler cette règle que de l’appliquer : qui n’a
tendance à la transgresser, surtout si des lacunes évidentes mais hors mission se
révèlent ?
Les règles sont identiques à celles du management, sauf une, la faisabilité. En

supposant que les moyens attribués sont suffisants, et s’en assurer fait partie de
la négociation préalable, et que l’auditeur est compétent, la non-faisabilité
impliquerait que le système est incontrôlable, pratiquement par absence de
documentation. Et alors la conclusion immédiate est qu’il a tous les défauts
possibles.
Exemple.– Un cas réel est celui d’une entreprise dont il était demandé
d’examiner la fiabilité du sous-système comptable, avec une prévision de
plusieurs semaines de travail : en quelques heures, l’application écrite en langage
proche de la machine, aucunement documentée, reposant sur un système de
bases de données et un gestionnaire de télécommunications maison, avec un
nombre très réduit d’informaticiens compétents, tous indisponibles (ils étaient
toujours absorbés par la réparation de pannes) devait conclure à la non-fiabilité
et en prime à toutes les observations critiques concernant les aspects vus plus
haut.
REGLE.– L’audit informatique est toujours faisable (contrairement au

management de l’informatique).
Le travail d’audit peut être assez complexe, et donc il doit obéir aux mêmes
règles que le management, et en particulier être découpé en fonctions
conduisant de façon arborescente à un plan avec des étapes significatives de
conclusions partielles. Mais le maillon le plus faible de sa démonstration est bien
entendu celui qui remet tout en cause.
Exemple.– Si la mission concerne la sécurité d’une application de gestion du
personnel, l’auditeur peut éluder avec accord du demandeur les questions de
plan et de budget ; il lui faudra examiner à fond mais sous le seul aspect de
sécurité et dans la mesure où ils concernent cette application, les matériels et
logiciels, les ressources humaines, les contrats, les méthodes, et enfin les
réalisations et leur exploitation. Cela fait, et puisqu’il a examiné tous les objets
concernés selon l’aspect demandé, les conclusions de l’auditeur seront certaines
et inébranlables.

REGLE.– Les moyens et actions de l’auditeur doivent être adaptés exclusivement
mais exhaustivement au sujet de l’audit.
Cela implique naturellement l’évolutivité (ouverture de recommandations sur
l’avenir, et non simple constat d’échecs), la cohérence et la planification des
ressources, bien entendu l’exactitude (fiabilité) des conclusions. La sécurité de
l’audit ne s’applique qu’aux documents de travail et aux rapports, à leur non-
diffusion hors destinataires autorisés, donc doit aller de soi.
L’avancement des travaux doit être logique comme une démonstration
mathématique, donc arborescente dans un sens voisin du précédent : « pour
prouver telle affirmation, il faut s’assurer de tels et tels faits ; et pour prouver
tel fait, il faut le décomposer en tels et tels points, etc. ».
Exemple.– Pour prouver qu’une application de gestion du personnel est sûre, et à
supposer que le demandeur ne soit pas intéressé par un examen de ses finalités ni
des moyens financiers en ce domaine, il faudra examiner les sécurités du matériel
et du logiciel de base, y compris les réseaux, utilisés par cette fonction, examiner
toujours sous le seul angle de la sécurité les diagrammes de circulation
d’information et les responsabilités (fiches de fonction) de chaque membre du
personnel impliqué, les méthodes et les programmes sensibles de l’application,
les saisies d’informations, les recyclages d’anomalies, la bibliothèque.
Alors seulement l’auditeur pourra affirmer avoir fait une étude exhaustive et
trouvé toutes les failles possibles.
1.4. Objectifs de l’audit

Ils sont différents et dépendent de la personne de l’entreprise qui commande
l’audit et qui, bien entendu, va interpréter les résultats de l’audit.
L’objectif principal est d’améliorer l’entreprise.
a) Le directeur général veut voir plus clair sur l’organisation de son entreprise,
avoir les éléments pour modifier le fonctionnement des services (amélioration,
restructuration de l’entreprise, création de nouveaux services, licenciement,
budgétisation pour des achats de grande envergure, …). Bref, c’est lui le décideur
pour modifier.
Attention : ces modifications peuvent paraître positives et/ou négatives si l’audit
a été bien et/ou mal fait)
b) Le directeur du service audit (informatique) s’intéresse à avoir des conseils
en termes d’organisation et de fonctionnement.
Exemple : acheter un serveur pour l’ISP-Bukavu ou engager un technicien.
L’intérêt est que le directeur du service va utiliser le rapport de l’audit pour que
les réformes soient acceptées par la direction générale et les employés de son
service.
c) Le directeur financier est plus intéressé par avoir des perspectives claires en
termes de recette et de dépenses pour son budget.
Au-delà même de l’objectif cible qu’est la maîtrise du SI, beaucoup de

responsables n’ont pas une vue claire et précise de ce qui appartient à leur
périmètre, ni de la sensibilité et la criticité des composants.

Il n’est pas rare en réunion d’entendre : « ne pourrions nous pas commanditer un
audit ? ». Cette question pleine d’espoir, n’est en fait qu’un point de départ. Il
serait aberrant de présenter à des auditeurs de métier ce qu’est un audit. Mais il
a semblé intéressant d'exposer le point de vue des commanditaires.
«On me demande de renouveler une architecture, dont je n’avais même pas
connaissance et encore moins de budget !», proclame une MOA (maitrise
d’ouvrage) au fond du couloir… Ce premier type d’audit a pour attente du
commanditaire, qu’il soit RI, DI, DSI ou MOA, une cartographie. Le déclencheur ?
Une non-connaissance de son périmètre.
Les éléments attendus ? Tout et rien, car il ne connaît pas son périmètre.
Il faut donc insister pour que le commanditaire exprime son besoin et les livrables
attendus, et si possible formellement. L’audit mené sous forme de microprojet
permet de garantir le respect des délais et du coût pour le commanditaire.
L’avantage complémentaire d’une telle démarche pour la division/direction des
audits, c’est d’être capable de justifier les budgets de fonctionnement alloués.
L’étiquette « poste de coût » pour cette direction disparaît alors. « Gouvernance
d’entreprise et refacturation interne » quand tu nous tiens…
Les données cartographiques peuvent être organisationnelles, orientées
processus, techniques (cartographie de flux, d’infrastructure…) ou orientées
inventaire sur le patrimoine informationnel (données existantes, licences des
logiciels, brevets…).
Ces audits ont pour but d’apporter des éléments d’aide à la décision, pour que le
commanditaire y voit plus clair dans sa stratégie, sa tactique, son plan d’action
opérationnel ou son projet.1.
Toutefois, l’auditeur devra veiller à seulement énumérer les éléments et à ne pas
les qualifier. C’est un travers des commanditaires que d’insister pour que le
livrable couple la cartographie à une analyse d’impact ou de risque. Or, à l’issu
de la cartographie, c’est au commanditaire / MOA / responsable d’effectuer
cette analyse et de porter la responsabilité de cette classification résultante et
des moyens à mettre en œuvre. Seul le propriétaire de l'information est capable
d’évaluer l’impact.
En contrepartie d’une énumération exhaustive et neutre, il est bien entendu que
des recommandations de bonnes pratiques ou des pistes d’évolutions,
accompagnent toujours un rapport d’audit.
Audit – L’attente d’une justification budgétaire

« Comment diable vais-je pouvoir justifier mon budget 2006 ? ». Faire un audit
peut être vu par un commanditaire comme une justification tierce pour défendre
un budget.
Ce type d’audit intéresse plus spécifiquement les responsables Sécurité des SI, les
MOA de projets d’optimisation, etc.
L’objectif attendu de tels audits est la mise en évidence des défaillances ou
manques, que le dit budget saura combler à coups sûrs.
Contrairement au cas précédent, le commanditaire va souvent insister pour vous
présenter un point de vue pessimiste de l’objet audité.

Les attentes en termes de livrables sont, comme d'habitude, clairement à définir
en amont. Une justification des montants budgétaire n’est généralement pas
attendue de l’auditeur.
Au contraire, le commanditaire préfère généralement garder toute latitude sur ce
point, pour pouvoir faire son « marché ». Il faut donc veiller à qualifier le niveau
de détail attendu du rapport, afin de rester dans la cible temporelle et
budgétaire.
Audit – Test de performance

Pour un décideur, l’audit est un outil permettant de mesurer la performance d’un
SI et des processus connexes. D’autres outils notamment le benchmarking sont
utilisés.
Contrairement à un reporting, il va permettre d’obtenir des indicateurs par une
tierce entité considérée comme objective.
Le point clé d’un tel rapport est de ne pas copier un tableau de bord existant,
mais de fournir les indicateurs pertinents, parfois valoriser ceux établis ou au
contraire proposer leur suppression s’ils ne sont pas représentatifs de la
production informatique mesurée.
Autre avantage d’auditer ces indicateurs récurrents, c’est la vérification de la
méthodologie de collecte, leur consistance externe et interne et l’analyse qui en
est faite.
Enfin, auditer la chaîne de communication interne peut parfois révéler des faits
surprenants et riches d'enseignement...
Audit – Test d’alignement

Le fondement même de l’audit : vérifier le positionnement entre ce que l’on a et
ce que l’on croit avoir.
Pivot central de COBIT, l’alignement est trop peu souvent objet d'audits.
Au passage, il est important de souligner les apports des travaux du CIGREF sur la
gouvernance des SI.
Le travail de fond doit être fait sur le commanditaire, pour le « sortir » de ses
obligations journalières opérationnelles.
Audit – Test pour rassurer

Une catégorie qui se décline en deux sous-catégories en fonction du
commanditaire :
• l’audit d’autosatisfaction : pour briller auprès des partenaires, de la
hiérarchie…
• l’audit par les partenaires : pour certifier ce que proclame l’entreprise.
Ces deux types d’audit sont là pour rassurer. L’attente est a priori une note
d’une page avec une conclusion contenant au maximum un axe d’amélioration
mineure. Sinon, ce n’est pas un audit qui rassure…
Audit – L’arme du paladin ou du chevalier noir

Il y a toujours dans une entreprise un preux paladin redresseur de tort, qui
brandit régulièrement l'arme qu'est l’audit. L’objectif souvent attendu est

d'obtenir un rapport démontrant les dérives organisationnelles ou une
performance informatique insatisfaisante.
Le livrable attendu doit être extrêmement étayé, pour augmenter le poids de
notre héro dans les jeux de politiques internes. Le rapport doit être neutre pour
que l’auditeur se désengage de toute répercussion du dossier. A une époque où la
transparence est le socle des normes et politiques, y compris d’entreprise, il est à
penser que le nombre d’audits de ce type va se multiplier massivement.
L’importance pour l’auditeur dans ce domaine est de définir avec une grande
précision le périmètre audité pour éviter toute dérive et rester dans la cible
choisie par le commanditaire.
A noter que de tels évènements risquent de solliciter l’éthique de l’auditeur en
plus des règlements internes et du cadre légal.
Particularité importante, l’audit qui déborderait vers un cadre de
cybersurveillance, doit être préparé en amont par le commanditaire vis-à-vis de
la législation française (pénal, civil et de droit du travail).
Enfin si le paladin est un chevalier noir, un cost killer ou un contrôleur général, la
finalité est rarement la création de valeur, mais plutôt la réduction des coûts
(d’infrastructure et organisationnels) ou le re-engineering de processus IT. Le
rapport se devra d’être particulièrement objectif, ciblé et bien entendu neutre.
La difficulté de conformité éthique et réglementaire soulignée précédemment
redouble d’importance.
Audit – L’attente d’une réponse

Les responsables sécurité ou MOA proposent parfois de répondre à leur question
par un audit, afin de connaître ce qui se passe réellement.
Ce type d’audit va au-delà d’un problème d’alignement car les commanditaires
connaissent l’existence d’un problème mais souhaitent avoir une confirmation ou
un appui par une entité tierce.
L’important pour l’auditeur est bien entendu d’arriver à faire exprimer les
attentes du commanditaire. Celui-ci tournera alors souvent autour du pot,
évoquant des problématiques mineures, sensées vous guider, sans vous le dire
explicitement, vers un plus « gros poisson » : la mise en exergue d’une collusion,
d’un processus organisationnel défectueux, etc.
Les points communs…

Pour conclure cette idée, derrière tout audit il y a un commanditaire avec ses
intentions spécifiques et pas toujours exprimées. L'effort de formalisation des
objectifs d'audit, et la spécification du niveau de détail du rapport, ne sont
jamais à oublier.
Il faut absolument poser ou se poser les questions :
• de l’objectif réel,
• des attentes finales du commanditaire,
• de l’utilisation qui va être fait du rapport.
Cette liste n’est en aucun cas exhaustive puisque l’intention finale est souvent
unique.

Enfin soulignons une dernière fois que de ne pas formaliser les attentes et
contraintes de réalisation de la mission est dangereux pour l'image de l'Audit.
C'est s'embarquer sur un publi-reportage alors qu'il faudrait faire du journalisme
d'investigation, si cette analogie peut être admise.
1.5. Démarches de l’audit

Comment fonctionne généralement un audit ?
Les démarches ne sont pas toutes les mêmes et on ne peut pas toutes les
retrouver. Il peut y en avoir d’autres.
Tout compte fait, on a à
1°) Définir les objectifs de l’audit :
- sur quoi est-ce qu’il va porter ?
- sur quels services ? Tous ? Une partie seulement ?
- sur quel aspect ? (qualité, organisation du service, service d’une personne ?
de sécurité ? …)
- sur quelle période ?
- A quelle profondeur (précision du rapport)
2°) Evaluer / justifier les risques / faiblesses
3°) Proposer des actions correctives
Voici les 18 points de contrôle possible d’un audit informatique
 Dé-saturation des unités de stockage
 Accélération des performances de lecture/écriture de données
 Correction des dysfonctionnements du système d’exploitation
 Correction des dysfonctionnements de périphériques
 Correction des dysfonctionnements d’applications
 Optimisation des performances du système et des applications
 Mesure des performances du réseau câblé et des commutateurs
 Réglage des moniteurs (anti- scintillement, correction chromatique,
etc.)
 Sécurité antivirale
 Protection anti-intrusion
 Planification des sauvegardes de données sensibles
 Détection des failles de sécurité Intranet
 Mise en adéquation des besoins de chaque utilisateur avec sa machine
 Vérification de l’intégrité des pilotes (imprimante, carte graphique,
etc.)
 Détection des risques d’incendie (connexions électriques à risque)
 Nettoyage des organes sensibles (ventilateurs bruyants, souris, etc.)
 Bilan sur la pérennité du réseau
 Conseils d’évolution matérielle et logicielle à moyen et long terme.

1.6. Déontologie de l’audit
a) Que doit être le comportement de l’auditeur ?
Il faut d’abord faire la part des choses entre l’audit et le conseil.
Le conseil est une activité très proche de l’audit.
Il va diagnostiquer les propositions des solutions ainsi que une proposition
de mise en œuvre des solutions.
Le conseil a comme objectifs, non pas d’abord l’amélioration du service
étudié, mais la vente des biens et matériels.
L’audit est indépendant des fournisseurs.
Le conseil est lui-même un fournisseur. Il n’a pas de garantie que l’analyse
faite par le conseil n’est pas influencée par le désir de profit du conseil.
Une société de l’audit ne fait que l’audit.
b) Il faut garantir une compétence multidisciplinaire, c’est-à-dire une
compétence technique, une compétence managériale (voir faire un
organigramme, comment fonctionne un service, …), compétence
financière, compétence juridique, …
c) Il faut que l’audit réalise des rapports réalistes, indépendants et motivés.
Toutes les conclusions doivent être motivées dans les rapports. Pas
question de couler des phrases muettes telles que « il faudrait faire ceci
… » sans explication.
1.7. Types d’erreurs

L’audit va se concentrer sur les faiblesses, les lacunes, les problèmes.
Tout cela peut être vu comme différents types d’erreur dans l’organisation d’une
entreprise.
Il ne faut pas porter des jugements ni parler de fautes ou de fraudes.
L’auditeur n’est pas un juge d’instruction ni même un donneur de leçons.
C’est un expert pour détecter des erreurs, un mauvais fonctionnement de
l’entreprise.
Par exemple : l’accessibilité d’un service est réduite car le préposé est souvent
absent.
L’auditeur ne doit pas juger le préposé car il ne connaît pas toutes les raisons qui
militent à ce que ce dernier soit absent.
L’auditeur constate et le dit.
Types d’erreurs de dysfonctionnement

a) erreurs dues à l’incompétence : on peut suggérer des compléments
d’informations
b) erreurs dues à une mauvaise modélisation du problème de départ : le
service a oublié tels ou tels autres aspects dans son fonctionnement
c) erreurs dues à une mauvaise définition des objectifs : les services veulent
de beaux produits alors que les objectifs premiers c’est le profit et la vente
d) erreurs dues à une mauvaise communication entre les personnes ou services
e) erreurs dues à l’oubli de vérification : on est très vite content du produit
alors que l’on n’a pas testé assez ; il peut contenir des erreurs.

1.8. Spécificités de l’audit informatique
On abordera ici un aspect plus informatique que général.
a) L’informatique est un secteur clé de l’entreprise.
C’est un secteur vital de l’entreprise. Si l’informatique ne fonctionne pas
bien, toute la stratégie de l’entreprise est affaiblie.
Par exemple : imaginer une entreprise d’aviations, de trains (de voyages).
Si leur système de réservation est en panne, l’émission des billets est
impossible, et donc pas de vente, pas d’entrées. Cela peut arriver des
temps en temps.
Les gens qui font de l’audit informatique touchent à une chose
fondamentale.
b) L’informatique est un secteur très diversifié
En effet, on a plusieurs domaines qui utilisent l’informatique : secrétariat,
service clientèle, communication avec l’extérieur, comptabilité, … presque
toute l’entreprise est informatisée.
On doit donc avoir beaucoup de compétences dans tous ces domaines.
c) Toute l’entreprise a son mot à dire
Cela signifie ici que tout le monde a le droit à dire quelque chose, tout le
monde est concerné. Tout le monde doit être interviewé lors d’un audit.
Exemple : les secrétaires savent ce dont ils ont besoin mieux que leur
patron.
D’où la nécessité et l’importance du management et de la communication.
d) La très haute technicité en beaucoup de domaines aussi bien matériel,
sécurité, logiciel (Leur utilisation correcte est recommandée, avoir aussi
choisi de bons logiciels qui s’adaptent aux différentes situations de
l’entreprise sans faille, …), ergonomie (interaction homme-machine), droit.
e) L’audit informatique n’a pas droit à l’erreur
Si l’on se trompe de solution, cela va coûter trop cher à l’entreprise et
risquerait de bloquer son développement et donc comme conséquence
l’audit aura une très mauvaise réputation comme étant incompétente.
Cela est d’autant plus difficile que le rapport d’audit informatique va
donner des solutions très précises qui devront fonctionner.
Par exemple : on n’imprime pas ; on change d’imprimantes mais on
continue à ne pas imprimer. Celui qui aurait été fait cet audit sera
considéré comme incompétent.
Il vaut mieux affirmer son ignorance (« je ne sais pas répondre à cette
question, à ce problème ») que de donner une mauvaise solution qui se
retournera contre vous.
f) Le monde informatique est un monde plein d’imaginerie.
Les gens ne connaissent pas de chose mais se l’imaginent. C’est le cas du
patron qui ne connaît pas grand-chose sur l’informatique ; il s’imagine
souvent des solutions miracles totalement imaginaires.
On doit beaucoup expliquer les contraintes des systèmes informatiques
pour que le patron puisse s’imprégner de la réalité des choses.

Une introduction au COBIT (Control objectives for information and related
technology)
Le caractère spécialisé de l’audit des Systèmes d'Information (SI) et les
compétences requises pour effectuer un tel audit rendent nécessaire la mise en
œuvre de normes spécifiquement adaptées à cette discipline. L’un des objectifs
de l’ISACA® (Information Systems Audit and Control Association® – Association de
l’audit et du contrôle des systèmes d’information, référence mondiale en
gouvernance, contrôle et assurance qualité des Technologies de l’Information
(TI)) est de proposer des normes mondialement applicables conformes à son
optique. Le développement et la promulgation de Normes d’audit des SI sont des
pierres angulaires de la contribution de l’ISACA à la communauté des auditeurs.
La structure des Normes d’audit des SI fournit de nombreux niveaux d’assistance :
 Les normes définissent des exigences obligatoires en matière d’audit des SI
et de reporting. Elles informent :
– Les auditeurs des SI sur le niveau minimum de performances requis
pour satisfaire aux responsabilités stipulées dans le Code d’éthique
professionnelle de l’ISACA
– Les dirigeants d’entreprise et les autres parties concernées sur les
attentes de la profession en matière d’agissements des praticiens
– Les titulaires de la certification CISA® (Certified Information Systems
Auditor® – Auditeur informatique agréé) sur les exigences de leur
charge. Toute incapacité à mettre en œuvre ces normes peut
entraîner une enquête sur la conduite du titulaire de la certification
CISA par le Conseil d’administration de l’ISACA ou tout autre Comité
approprié et, en définitive, des actions disciplinaires.
 Les directives apportent des instructions sur l’application des Normes
d’audit des SI. L’auditeur des SI doit s’y référer au moment de mettre en
œuvre les normes, faire appel à son jugement professionnel avant de les
appliquer et se préparer à justifier tout écart vis-à-vis d’elles. Les
Directives d’audit des SI visent à fournir de plus amples informations sur la
manière de se conformer aux normes applicables.
 Les procédures constituent des exemples de méthodes qu’un auditeur des
SI peut appliquer lors d’une mission d’audit. La documentation des
procédures contient des informations sur la mise en œuvre des normes
d’audit des SI, mais ne fixe pas d’obligations. Les Procédures d’audit des SI
visent à fournir de plus amples informations sur la manière de se conformer
aux normes applicables.
Pourquoi le CobiT (Control objectives for information and related technology)?:

Pour
 la gouvernance, le contrôle et l’audit de l’information et des technologies
associées
 la gestion des risques liés aux nouvelles technologies
 la mise en place de directives efficaces et de contrôles adéquats.
Pour qui ? Pour

 le management (ajustement des investissements, maîtrise de la technologie
de l’information)
 les utilisateurs (sécurité et gestion des services informatiques fournies)
 les utilisateurs (conseil du management)
Les ressources du COBIT® constituent un modèle de bonnes pratiques. La

structure du COBIT précise : « Les dirigeants ont pour responsabilité de préserver
l’ensemble des actifs de l’entreprise. Pour exercer cette responsabilité et
atteindre ses objectifs, les dirigeants doivent établir un système de contrôle
interne adapté. » Le référentiel COBIT fournit un ensemble détaillé de contrôles
et de techniques de contrôle destiné aux environnements de gestion des systèmes
d’information. Dans le COBIT, le choix des éléments les plus pertinents pour un
audit particulier est basé sur la sélection de processus TI spécifiques et sur la
prise en compte des critères d’information du COBIT.
Comme le précise la structure du COBIT, chacun des éléments suivants est
organisé par processus de gestion TI. Le modèle COBIT est destiné aux dirigeants
et aux responsables des TI, mais aussi aux auditeurs des SI. Par conséquent, son
utilisation permet de comprendre les objectifs de l’entreprise, de faire connaître
les meilleures pratiques et d’émettre des recommandations autour d’une
référence normative comprise et respectée de tous. Le COBIT inclut :
 Des objectifs de contrôle — Déclarations génériques détaillées et de haut
niveau pour un contrôle de qualité minimale
 Des pratiques de contrôle — Justifications pratiques et instructions de mise
en œuvre pour les objectifs de contrôle
 Des directives d’audit — Instructions relatives à chaque zone de contrôle
sur la manière de comprendre les problématiques, d’évaluer chaque
contrôle, de mesurer la conformité et de quantifier le risque de contrôles
non satisfaisants
 Des directives de gestion — Instructions sur la manière d’évaluer et
d’améliorer les performances des processus TI à l’aide de la métrologie, de
modèles de maturité et de facteurs de succès essentiels. Elles constituent
une structure orientée gestion pour l’auto-évaluation des contrôles
continus et proactifs spécifiquement centrée sur :
– La mesure des performances — Jusqu’à quel point la fonction TI
répond-elle aux besoins de l’entreprise ? Les directives de gestion
permettent de mettre en œuvre des ateliers d’auto-évaluation, mais
aussi d’assurer l’application par les dirigeants de procédures de
vérification et d’amélioration continues dans le cadre d’un plan de
gouvernance TI.
– Définition du profil des contrôles TI — Quels sont les processus TI
importants ? Quels sont les facteurs de succès essentiels d’un
contrôle ?
– Sensibilisation — Quels sont les risques que les objectifs ne soient pas
atteints ?
– Étalonnage concurrentiel — Que font les autres ? Comment mesurer
et comparer les résultats ? Les directives de gestion proposent des

exemples de métrologie au service de l’évaluation des performances
TI en entreprise. Les indicateurs d’objectifs essentiels soulignent et
mesurent les résultats des processus TI et les indicateurs de
performances essentiels évaluent l’efficacité des processus en
quantifiant les éléments favorables. Les modèles et attributs de
maturité assurent l’évaluation des capacités et l’étalonnage
concurrentiel. Ils aident les dirigeants à mesurer les capacités de
contrôle, mais aussi à identifier les besoins de vérification et les
stratégies d’amélioration.
Un glossaire est à disposition sur le site Internet de l’ISACA à l’adresse
www.isaca.org/glossary. Dans ce glossaire, les termes « audit » et « review » sont
interchangeables.
Exclusion de responsabilité : L’ISACA a conçu ces directives comme le niveau
minimum de performances requis pour satisfaire aux responsabilités stipulées
dans son Code d’éthique professionnelle. L’ISACA ne saurait garantir que
l’utilisation de ce produit constitue une assurance de résultat. La présente
publication ne saurait être considérée comme incluant l’ensemble des procédures
et tests adaptés ou comme excluant d’autres procédures et tests susceptibles de
conduire raisonnablement à des résultats similaires. Au moment de déterminer la
propriété d’une procédure ou d’un test spécifique, le professionnel du contrôle
doit faire appel à son propre jugement professionnel en fonction des
circonstances, des systèmes impliqués ou de l’environnement technologique.
Le Comité de normalisation de l’ISACA s’engage à réaliser une vaste consultation
pour préparer les Normes, Directives et Procédures d’audit des SI.
Avant d’éditer ses documents, le Comité de normalisation publie des exposés-
sondages à l’échelle internationale pour recueillir les avis du grand public.
Si nécessaire, le Comité de normalisation consulte également des personnalités
dont l’expertise ou l’intérêt dans le domaine abordé est susceptible d’apporter
un éclairage utile. Dans le cadre de son programme de développement continu, le
Comité de normalisation encourage les membres de l’ISACA et toutes les parties
intéressées à lui signaler les problèmes émergents qui nécessitent l’établissement
de nouvelles normes.
NB : Envoyez les suggestions par courrier électronique (standards@isaca.org), par
télécopie (+1 847 253 1443) ou par courrier postal (adresse à la fin de ce
document) au siège international de l’ISACA, à l’attention du directeur de la
recherche normative et des relations avec les universités.
Date de publication du présent document : 15 octobre 2004.
NORME D’AUDIT DES SYSTÈMES D’INFORMATION

PLANIFICATION
Planification S5
Introduction
01. Les Normes d’audit des SI de l’ISACA contiennent des principes de base et
des procédures essentielles obligatoires, indiqués en caractères gras, ainsi
que les instructions associées.

02. La présente Norme d’audit des SI a pour objectif l’établissement de
normes et la promulgation d’instructions concernant la planification des
audits.
03. L’auditeur des SI doit planifier la portée de l’audit des systèmes
d’information pour atteindre ses objectifs et se conformer aux lois et aux
normes d’audit professionnel en vigueur.
04. L’auditeur des SI doit développer et documenter une approche d’audit
basée sur le risque.
05. Il doit développer et documenter un plan qui expose la nature, les
objectifs, la durée et l’ampleur de l’audit, ainsi que les ressources
requises.
06. Il doit également développer un programme et des procédures d’audit.
1. Commentaire
07. S’agissant des fonctions d’audit interne, un plan doit être développé ou
mis à jour, au moins une fois par an, pour les activités en cours. Le plan
doit servir de structure pour les activités d’audit et aborder les
responsabilités définies par la charte d’audit. Le nouveau plan ou sa
version mise à jour doit être approuvé par le comité d’audit (si mis en
place).
08. S’agissant d’un audit des SI externe, un plan doit normalement être
préparé pour chaque mission d’audit ou de non-audit. Le plan doit
comporter les objectifs de l’audit.
09. L’auditeur des SI doit comprendre la nature de l’activité à contrôler.
L’étendue des connaissances requises doit être déterminée par la nature
de l’entreprise, son environnement, les risques et les objectifs de l’audit.
10. L’auditeur des SI doit effectuer une évaluation des risques pour attester
que tous les éléments matériels seront couverts de manière appropriée au
cours de l’audit. Les stratégies d’audit, les seuils de tolérance et les
ressources peuvent alors être développés.
11. Le programme et/ou le plan d’audit peuvent nécessiter un réajustement
en cours d’audit pour régler les problèmes (nouveaux risques, prévisions
erronées ou conclusions des procédures déjà effectuées) pouvant survenir
durant l’audit.
12. Se référer aux instructions suivantes pour plus d’informations sur la
préparation d’une charte d’audit ou d’une lettre de mission :
 Directive d’audit des SI G6, Concepts d’importance relative pour l’audit
des systèmes d’information
 Directive d’audit des SI G15, Planification
 Directive d’audit des SI G13, Utilisation de l’évaluation des risques dans
la planification d’audit
 Directive d’audit des SI G16, Effet des tiers sur le contrôle des TI d’une
entreprise
 Structure COBIT, Objectifs de contrôle
 Date de prise d’effet
13. La présente Norme d’audit des SI s’appliquera à tous les audits de
systèmes d’information débutant à compter du 1er janvier 2005.

Chapitre 2 : L’audit des objectifs informatiques
2.1. Préliminaires
Le système d’information doit constituer un système cohérent, même s’il est
constitué de nombreux objets de natures, voire de localisations différentes.
Définir ses objectifs doit donc précéder les choix de moyens et actions. C’est un
problème complexe à poser clairement, donc à résoudre parfaitement, mais il
faut s’y attacher si l’on ne veut pas laisser les décisions essentielles dépendre
d’objets qui n’ont par nature aucune finalité propre (sauf les ressources
humaines).
La difficulté tient paradoxalement à l’absence de contrainte générale autre que
l’adéquation au monde extérieur, la liberté étant totale dans le cadre de la
politique de l’entreprise, dont le système d’information n’est qu’un support de
réalisation.
Les contraintes précises n’interviendront qu’ultérieurement, par la disponibilité
des moyens et la praticabilité des actions. Et comme les uns et les autres sont
fluctuants, puisque les techniques et produits changent vite (parfois mais pas
toujours par progrès intrinsèque), la seule méthode rationnelle est d’établir une
politique informatique et de la détailler logiquement en buts par objectifs
indépendants des ressources, puis de classer ceux-ci dans un plan de réalisation
étalé dans le temps, puisque les moyens et actions ne sont presque jamais
immédiatement disponibles.
Suivant les contraintes, tel but sera ou non finalement retenu, et s’il l’est,
atteint de telle ou telle façon. Le détail n’a pas à être défini au moment de
l’élaboration de la politique informatique ; cependant, si une ressource se révèle
inaccessible, il faut revenir au niveau du but concerné, chercher à l’atteindre
d’une autre manière, et s’il n’en existe pas, remonter au niveau du plan et le
remettre en cause.
C’est donc l’opposé de la démarche, pourtant bien plus courante, qui consiste à
découvrir une nouvelle ressource et à s’interroger sur ce qu’il est possible d’en
faire : servant un but indéfini, l’audit ne peut porter sur celui-ci, ou plutôt
l’auditeur doit reconstituer mentalement ce qu’aurait été la démarche logique.
Exemple.– Il fut un temps où les bases de données, les systèmes experts, la
prétendue intelligence artificielle, voire la capacité des disquettes étaient
présentés comme des solutions par les fournisseurs et prestataires. Il ne manquait
que la définition des problèmes !
De plus, l’auditeur doit toujours penser que l’informatique n’est pas une
superstructure plaquée sur l’entreprise, mais une infrastructure qui a un rôle
stratégique, structurant en extensivité et en intensité et qui n’est pas réduite à
des outils : les techniques ne doivent pas occulter les problèmes de fond.
Il a déjà été dit que l’information est un bien précieux, et portée par un véritable
système nerveux ; un animal privé d’encéphale ne peut survivre qu’un moment
sans assistance externe ; et les outils ne seront jamais en soi l’équivalent d’un
encéphale.

L’échec historique du management automatisé était prévisible dès le départ.
Avant d’auditer un système informatique, il faut absolument connaître le
contexte dans lequel ce système doit fonctionner, donc connaître les termes de
référence qui ont été établis par l’entreprise pour son système informatique.
Donc, il faut connaître les objectifs assignés, confiés à l’informatique au sein de
l’entreprise auditée ou à auditer.
On ne peut pas faire un audit informatique sans connaître :
- par rapport à quoi cette entreprise a introduit l’informatique en son sein ;
- ses objectifs clairement définis.
L’entreprise doit décrire ce qu’elle veut de son service informatique et l’audit de
vérifier le bon fonctionnement par rapport à son apport.
Deux outils sont importants pour clarifier les objectifs informatiques d’une
entreprise : la politique informatique ou plan stratégique informatique et le
schéma ou plan directeur.
2.2. La politique informatique

Définir la politique informatique n’est guère technique, le rôle des techniciens
n’étant que de réaliser tel ou tel but ou de révéler au gestionnaire qu’il est
irréalisable.
Aussi est-il essentiel qu’elle soit définie par la direction, peut-être avec l’aide
d’un service ou d’un conseil spécialisé en organisation, mais qui n’a pas de
pouvoir de décision. Elle doit être adaptée à la finalité de l’entreprise, donc
évolutive et homogène avec les objectifs de celle-ci, et documentée, donc
concrétisée par un écrit. Il n’est pas essentiel de déterminer d’abord si elle est
faisable, c’est l’analyse ultérieure qui devra répondre à cette question.
La politique informatique est décrit dans un document (petit en nombre de
pages : deux) rédigé ou approuvé par les plus hautes autorités (Conseil
d’administration, Direction générale) et qui décrit la place et le rôle stratégique
de l’informatique.
C’est dans ce document :
- que l’on saura si l’entreprise a une volonté de s’informatiser ou pas ;
- qu’on verra l’organigramme général de l’entreprise et la place du service
informatique dans celui-ci.
Exemple 1 : Pour une société X, on voudrait que l’informatique fonctionne selon
un organigramme comme celui-ci :

Direction
générale
Service Service
financier production
Atelier Atelier
mécanique électronique
Service
informatique
ici, l’informatique est un système qui est au service technique du reste au 4ème
niveau …
Exemple 2 :
Direction
Service
informatique
Service Service
financier production
Le service informatique est autonome (indépendant) des autres services, à part la

direction.
Exemple 3 : Voici le schéma de MesOrdi (2004-2005) : Cf. TP

PDG
Secrétaire
Gérant
Maintenance
Caissière et
Informatique
Cf. TP d’audit informatique

Exercice : Décrire le plan stratégique d’un centre de formation informatique
Bref, les schémas sont différents d’une société à une autre et cela, selon la
politique informatique de chaque entreprise.
Le document de politique informatique doit aussi décrire les futures orientations
pour l’informatique.
Par exemple : le rôle et les objectifs à atteindre pour les services informatiques,
notamment, par exemple, il faut que chaque service soit connecté à l’Internet ou
que la gestion des stocks soit informatisée.
NB : Si l’entreprise n’a pas de volonté informatique dans son document
stratégique, il est sûr que l’audit informatique pourrait être cohérent ou pas.
Ce document stratégique reste idéaliste ou difficile à obtenir, mais il reste très
important. Lors de l’audit informatique, il faut obliger la Direction générale
d’avoir un plan stratégique. S’il faut vraiment aider une entreprise qui ne l’a pas
à le rédiger correctement, compte tenu bien sûr de ce qu’elle va dire, sans ce
document, il n’est presque pas impensable de faire un audit informatique.
2.3. Le schéma ou le plan directeur

C’est un document assez gros (entre 10-150 pages), technique, écrit par les
responsables informatiques qui ne disent pas où est-ce qu’ils sont situés par
rapport à la direction générale, mais décrivent seulement ce que fait chacun par
rapport au service informatique.
Son contenu sera par exemple :
a) le schéma organisationnel du service
Ce document peut paraître simple ou très compliqué, réduit à une personne
ou à plusieurs personnes qui peuvent jouer plusieurs rôles
b) Les applications mises en œuvre et le plan descripteur
C’est notamment à titre exemplatif :

- la comptabilité : faut-il la faire en Access, en Excel, faut-il acheter
un logiciel ou faut-il créer ou développer un progiciel adéquat ?
Bref, le responsable, les processus de réparation doivent être
décrits ;
- les applications des étudiants : les services concernés, les objectifs
de l’application (inscription, liste des cours, paiement des bourses
d’études, délivrance des diplômes, …) ;
- les applications du personnel ; paiement, …
- application de la gestion de stocks
- des grosses applications mathématiques qui imposent des super
ordinateurs
- applications « Office » : secrétariat (gestion des documents),
archivage, comptabilité des documents, sécurité des documents,
confidentiabilité, …
c) La politique de sécurité et de qualité
- Le plan directeur doit dire, si possible, comment le service
informatique gère la sécurité (du réseau, des machines, des données,
du personnel),…
- Le plan directeur explique aussi comment il met en œuvre des
procédures de contrôle de qualité qui impose des réunions régulières
d’évaluation, la veille technologique (quelqu’un ou tout le monde
doit consacrer 5 à 10% de son temps à la lecture, à la formation, à la
participation à des congrès pour être informé de l’avancée
technologique de l’informatique (exemple : savoir qu’il y a un
nouveau Pentium sur le marché…)
d) Le plan directeur expose le fonctionnement interne du service : règlement
d’ordre intérieur, règles de déontologie pour les usagers, code de bonne
conduite, …
Ceci est très important pour bien espérer faire l’audit informatique.
Bref, le plan directeur permet à l’auditeur de connaître en profondeur les
services informatiques et leurs fonctionnements sur papier.
Si le plan directeur n’existe pas, l’audit ne peut se faire ! Il faut toujours
commencer par là.

Chapitre 3 : L’audit des moyens informatiques
3.1. Les moyens techniques

Il s’agit ici de l’audit de tout le matériel informatique en général tant même qu’il
soit diversifié.
Il faut faire des audits en fonction des matériels existants (Cf. . câblage, circuit
électrique, logiciels, …)
3.1.1. Audit des matériels

La première chose, c’est de faire le relevé du matériel et des logiciels en passant
dans tous les services.
L’audit va donc décrire l’état du matériel informatique, donc il va dépendre
d’une entreprise à une autre : la liste suivante n’est pas donc exhaustive :
- ordinateurs
- logiciels utilisés
- réseaux (câbles, connexion du fournisseur d’accès Internet : modèle,
antenne satellite, débit, …)
- les périphériques (projecteur, imprimante, graveur, scanneur, appareils
numériques, …)
- les consommables
- l’environnement (électricité, locaux (sécurité, grandeur, ventilation,
contre poussière, …)
Pour chaque matériel et chaque logiciel, on va faire une sorte de table de la

manière suivante (par exemple) :
Matériel Nombre Etat Local Observations
Pentium IV Portable DELL 5 OK 118 À remplacer en 2009
L’idée n’est pas de faire un relevé mais de donner l’état du matériel. Même si on
ajoute une colonne du service qui les utilise, cela n’aura pas d’impact direct ici ;
c’est donc inutile…
Logiciel Licence Utilisation Observations

MS Office Pas (donc pirate) Secrétariat A mettre à jour
On fait de même pour le local, les périphériques, pour les connexions (on devra
ici dresser un schéma du réseau le plus simple possible).
Tout dessin doit être commenté comme suit :
1) donner une bonne image de l’état des logiciels, du réseau, des matériels,
…
2) L’audit va ensuite analyser l’état du matériel et donner un avis général sur
celui-ci.
Exemple : Le matériel est vieux ou non homogène ou suffisant (bien
entretenu…) : faire un avis général en tant qu’un expert.

Le matériel est dispersé (dans des bureaux différents)
NB : Ne parler que du matériel existant et visible.
3) L’audit va enfin réfléchir à la cohérence entre l’état existant et le plan
directeur.
Exemple :
 Le Directeur Général dit que chaque travailleur doit voir ses mails
dans son bureau alors qu’il n’y a pas de connexion ou que la
connexion est insuffisante.
 Le logiciel de gestion des stocks doit être remplacé car il ne peut
opérer les conversions en Euros…
Il faut pouvoir dire après l’audit quelles sont les lacunes et proposer des
solutions.
Il faut nécessairement que les solutions soient motivées par le plan directeur (pas
de solutions monstrueuses des conseillers sans motivation).
L’idéal est que l’audit propose différentes solutions selon le budget ou des
priorités différentes (d’être émises par le Directeur et tout son staff…)
L’auditeur doit bien connaître le métier pour aider comme il faut le directeur de
l’entreprise que l’on doit auditer. Il doit aussi poser des questions pour savoir
davantage même ce que le Directeur Général ne dit pas.
3.1.2. L’audit de la sécurité

Pourquoi faut-il en faire ?
Dans l’audit informatique des grandes sociétés, c’est le point le plus important.
La sécurité bouge tellement qu’il faut s’adapter au jour le jour.
L’audit de la sécurité recouvre plusieurs domaines, notamment :
 la sécurité physique du matériel (vol, surtension, foudre (cf. onduleur UPS),
chute de tension, l’environnement (propreté, poussière, petits rongeurs des
câbles et fils, thermites, dégât des eaux, la nourriture, boissons, … (pas
fumer, pas manger, pas boire dans le local machines, …), éviter les rayons
solaires, …
 La sécurité liée à Internet (au réseau : il s’agit d’avoir un antivirus à jour.
De plus en plus, un système de sécurité (un pare-feu un firewall), une
bonne gestion de mots de passe (éviter l’imprimante, l’accès à votre
machine, …), la fiabilité de la connexion (on dépend du fournisseur d’accès,
…), la fiabilité des services partagés (imprimantes, serveur des fichiers pour
petite ou grande entreprise…)
 La sécurité liée aux données (questions à poser au service informatique) :
confidentialité, back-up (sauvegarde régulière, journalière, hebdomadaire)
sur quel type de support (CR Rom, DUP, tape, USB, un autre disque dur
localisé ailleurs, …)
Attention : l’audit doit vérifier si les procédures de sauvegarde sont
connues et réellement mises en œuvre.
Rappelons que la meilleure sauvegarde est la sauvegarde sur papier.
Conclusion : L’audit analyse l’état de sécurité et propose des solutions pour les
lacunes observées.

3.1.3. Audit des réseaux et des communications
L’audit va vérifier la solidité du réseau.
Pour les grosses entreprises, le réseau est essentiel. Il faut une gestion de réseau
très précise. Chaque ordinateur (ou périphérique) doit être identifié (par une
adresse IP).
Il faut gérer des réseaux locaux avec des passerelles entre eux.
Pour exemple : le réseau des étudiants est indispensable de celui de l’université.
La gestion du réseau doit vérifier les comportements des utilisateurs (ex : virus,
accès à des sites interdits, utilisation de toute la bande passante, …).
Les connexions réseaux sont en pleine évolution, il faut donc que le gestionnaire
du réseau se forme régulièrement de peur de ne pas être dépassé par les
événements.
3.1.4. Audit d’une application particulière

L’idée est d’auditer un logiciel particulier pour analyser son efficacité et sa
compatibilité avec les stratégies dans l’entreprise.
Par exemple : un logiciel des finances acheté il y a dix ans.
L’audit doit d’abord clarifier les objectifs attendus et voir si le logiciel y répond
ou non et quelles sont les lacunes, les solutions possibles.
(Exemples : nouveau logiciel, nouveau module qui peut imposer une réécriture du
code, …)
NB : l’achat d’un nouveau logiciel (différent du premier) coûte cher, surtout en
expertise locale, c’est-à-dire les employés perdent en effet une grande partie de
leur compétence acquise avec l’ancien logiciel…
Il vaut mieux prendre de mise à jour que des changements radicaux (mais ce
n’est pas toujours vrai dans tous les cas, …).
S’il faut acheter un nouveau logiciel, il faut faire une étude du marché.
3.2. Ressources humaines

3.2.1. 1ère approche
L’audit présentera l’organigramme des responsabilités actuelles. Il faut faire
attention au recouvrement des responsabilités (tuilage) : si quelqu’un est absent,
qui le remplacera ? Mais pour être remplacé, il faut donc connaître les
responsabilités de l’absent.
Quels moyens sont-ils mis en œuvre pour que l’information circule?
Rappelons que l’audit informatique présente des procédures différentes selon les
entreprises à auditer, cependant, elles changent chaque fois.
Y a-t-il donc des documents qui expliquent les procédures techniques à suivre en
cas de problèmes ou si le responsable est absent ?
Il est donc important que les procédures techniques soient écrites régulièrement
pour qu’à une absence, il n’y ait pas de trous, de blocage dans l’entreprise.

3.2.2. 2ème approche
Il est question ici de faire un audit analyse des ressources humaines à partir des
grandes applications ou des grands services.
Exemple 1 : une application clientèle de la ressource humaine : Mr X va encoder,
Mr Y a écrit le code du programme, …
Exemple 2 : une application web en ressource humaine a besoin d’un
programmeur informaticien, d’un graphiste, d’un responsable des
contenus de cours, du chargé des communications, …
Conclusion
L’audit vérifie les cohérences des ressources humaines avec les objectifs du
schéma ou plan directeur.
L’audit propose des solutions en fonction des lacunes données (de type des gens
ne se parlent pas assez, l’équipe comptabilité n’est pas tout à fait compétente),
etc.
3.3. Audit des moyens financiers

L’audit fait le relevé de dépenses passées et des sommes allouées pour le futur
(budget).
Attention pour le matériel important informatique : il faut prendre en compte les
amortissements et les renforcements des machines.
Bien entendu, l’audit, comme d’habitude, va analyser la cohérence des
ressources financières avec les objectifs (de l’entreprise) définis dans le plan
directeur, et proposer des solutions.

Chapitre 4 : L’audit spécifique des entreprises d’informatique
Les entreprises d’informatique sont celles qui vendent de l’informatique.
4.1. Audit de service informatique

Une entreprise d’informatique est une entreprise qui vend du conseil, du
matériel, des solutions ou des services informatiques.
Exemple : Cybercafé (connexion Internet ou fournisseur d’accès) vend les
connexions, magasin de fournitures informatiques.
Il faut les auditer particulièrement.
L’objectif d’une telle entreprise est d’offrir un service de qualité et une
compétence. L’audit va se concentrer sur la satisfaction des clients, la
compétence des techniciens (pas besoin d’avoir un plan directeur, la fiabilité du
service (ne tombe pas tout le temps en panne, …).
L’audit n’est pas spécifique à ce genre de service, il est semblable à l’audit de
toute entreprise vendant des fournitures ou des services.
Exemple : agence de voyage, magasins des sports, …
4.2. Audit des projets informatiques (développement des logiciels)

But : Améliorer la maîtrise des projets informatiques
Contexte
De plus en plus souvent les auditeurs sont amenés à évaluer les projets
informatiques en cours de développement. Or, les projets informatiques sont de
plus en plus complexes, tant sur les plans organisationnels, fonctionnels que
techniques. Il est dans ces conditions assez normal que les décideurs
s’interrogent et se demandent s'ils atteindront les objectifs qui leur ont été fixés
et surtout quand les équipes opérationnelles y arriveront.
Même si les facteurs de dérive sont connus, les dérapages de coûts et de délais
des projets informatiques sont encore très fréquents. Pire, les fonctions prévues
ne sont pas toujours au rendez-vous. Dans ces conditions et compte tenu des
montants engagés, les gestionnaires deviennent de plus en plus attentifs aux
dérives financières des projets et à leur justification économique.
Pour ces raisons, ils demandent des audits des projets informatiques. Pour réussir
ce type de mission il est nécessaire de comprendre la démarche de façon à
apprécier ce qui est commun à tous les audits et ce qui est spécifique à l'audit
des projets informatiques.
Objectifs
 Connaître les bonnes pratiques en matière de gestion de projet informatique,

 Fournir aux participants les connaissances nécessaires pour effectuer le
diagnostic d’un projet informatique notamment en identifiant et en évaluant
les risques associés au projet,
 Acquérir une démarche permettant d'effectuer efficacement l'audit de tout
projet informatique.
Il concerne plus
 les auditeurs internes et externes,
 les chefs de mission et directeurs de mission ayant à réaliser des audits de
projets informatiques,
 le futur auditeur informatique,
 le chef de projet, Directeur de projets,
 le consultant en informatique et en organisation,
 le maître d'ouvrage, dirigeant d'entreprise,
 le directeur informatique, responsable des études.
 le Responsable qualité.
L’état de l’art en matière de projet informatique
 La notion de projet
 Les particularités des projets informatiques
 Tenir les délais et les budgets
 Évaluation des risques liés au projet
 Les risques de la non-qualité, les dérapages des coûts et des délais
 Nécessité de mettre en place un dispositif de pilotage efficace
Démarches d'audit des projets
 Les objectifs et les points de contrôle :
 Évaluation du processus de développement
 Existence de processus, de méthodes et de standards
 Vérification de l’application de la méthodologie
 Compréhension les causes de dérives des projets
 Adéquation des fonctions aux besoins des utilisateurs
 Autres objectifs de contrôle
Audit des projets aux différentes phases du projet

 Étude de faisabilité (dossier d’expression des besoins, étude
d’opportunité,...)
 Cahier des charges (analyse fonctionnelle, conception générale,…)
 En cours de réalisation (analyse détaillée, programmation,
paramétrage, tests unitaires,…)
 Tests (tests d’intégration, tests de performance, recette,…)
 Application opérationnelle
Les différents types d’audit des projets
 Les grands projets
 Les projets stratégiques

 La mise en œuvre d’un ERP
 Le déploiement sur de nombreux sites
 Les petits projets
 Les projets en PME
Exemples de mission d’audit de projet
 Audit d’un projet en phase amont
 Audit d’un grand projet à la fin du cahier des charges
 Audit d’un projet moyen en mode client-serveur
 Audit d’un projet en RAD
Traitement en groupe d'un cas
 L'audit d'un projet au stade de la faisabilité
 L'audit d'un projet à la fin de l'analyse fonctionnelle
L’audit va se concentrer sur la qualité des processus de développement du
logiciel (Cf. cours de génie logiciel : qualité des logiciels).
Parmi les qualités escomptées à un logiciel, on peut citer entre autres :
 La fiabilité (bonne réponse)
 La rapidité (réponse rapide)
 La modularité (on peut étendre le logiciel)
 La compatibilité (avec d’autre standard : lire des fichiers venant d’autres
logiciels, …)
 La lisibilité du code source (agréable, commentaires existant, …)
Il faut aussi vérifier la qualité de la gestion, du projet logiciel.
Quelle est la méthodologie mise en œuvre ? Comment fonctionnent les équipes
qui travaillent sur le projet ? …
Audit Projet
- Démarche d'audit de projet
- Phases préliminaires de l'audit
- Guide d'audit et points de contrôle
Les petits et les grands projets
- Conduite de projet : démarche et acteurs
- Maturité des processus du projet
- Petits et grands projets
Audit de l'organisation et de la conduite de projet
- Gestion de projet et processus de support
- Accompagnement du projet
- Organisation
- Facteurs de succès et points de contrôle
Audit des phases du projet
- Etude préalable
- Analyse et spécifications générales
- Conception et spécifications détaillées
- Construction du logiciel
- Tests
- Facteurs de succès et points de contrôle

4.3. Audit d’entreprises faisant des études informatiques
C’est le cas d’une entreprise qui vend des études statistiques.
L’audit va vérifier la compétence, la qualité des services.
4.4. Audit d’entreprises installant des logiciels

Ici l’audit va se concentrer sur la qualité du suivi de l’installation (Cf. service
d’après vente).
Le suivi comporte les caractéristiques suivantes :
 Existence d’un help desk (comptoir d’informations ou d’aides) Cf. 1er
dépannage : quelque chose qui va donner les premières réponses aux
premières difficultés ;
 Compétences de l’informaticien ;
 Capacité à contacter le concepteur du logiciel.
La compétence peut être vérifiée par des certificats ou diplômes donnés par la
firme créatrice du logiciel (cf. société certifiée Microsoft, certifiée Dell,
académie CISCO, …)
Voici à ce propos les procédures standardes pour les audits informatiques
proposées par l’association COBIT

Chapitre 5 : Déroulement de l’audit informatique
Il s’agit ici d’une sorte de conclusion de la partie théorique.

Il y a des étapes qu’on peut ajouter et celles qu’on peut supprimer. Bref, ce n’est
pas exhaustif.
5.1. Plan de travail

Après avoir rencontré la direction de l’entreprise, vous avez une idée globale du
service informatique, de la qualité du service, de l’existence ou de l’absence du
plan stratégique et du schéma directeur. C’est la première chose à faire.
A partir de votre expertise, vous établissez un plan de travail avec un certain
nombre de journées pour les différentes étapes de l’audit (plan stratégique, plan
directeur, interview des personnes, relevé du matériel, travail d’analyse,
rédaction du rapport, présentation des résultats).
En fonction de tout ceci, on a un plan de travail, pas trop détaillé mais
suffisamment précis pour que la direction soit convaincue des délais proposés.
Et puis, on fait un devis à partir du nombre de journées fois le nombre d’hommes
nécessaires à l’audit ; il faut ajouter les frais alloués à l’audit.
A côté du devis et du plan de travail, il est bien d’indiquer les références (les
compétences) de l’équipe de l’audit.
5.2. Lettre de soumission et programme fiscal

Après avoir fait un devis, on écrit la lettre de soumission et si vous êtes choisi,
vous préparez un programme détaillé de l’audit (détaillez les points du plan de
travail avec d’autres mentions comme les dates exactes (interviews, rencontres,
…).
A partir de là, vous signez un contrat avec l’entreprise.
Ce contrat contiendra les éléments suivants : l’objectif de l’audit, la liste des
services audités, les ressources mises au service de l’audit par l’entreprise (local
pour les interviews, accès aux dossiers, …) ainsi que les délivrables (choses que
l’on remet à l’entreprise à la fin : rapport, présentations) dans des délais fixés ou
pas dans le contrat. Celui-ci contient aussi le mode de paiement.
5.3. Considérations stratégiques

A ce niveau, on est au début de l’audit.
Il ne faut pas se lancer « tête baissée » dans l’audit. Il faut d’abord bien
considérer le contexte stratégique de l’audit.
Presque toujours, l’audit est utilisé dans l’entreprise pour des raisons
stratégiques différentes que celles de l’amélioration de la qualité.
Souvent, la direction peut essayer de « manipuler » l’audit.
Par exemple : Crise dans une grande entreprise entre la Direction et les
travailleurs : pour que la crise se termine, on exige un audit au lieu d’éviter la
grève.

Il est donc important de ne pas se laisser manipuler. Pour cela, il faut se
renseigner sur l’entreprise et son véritable objectif.
Après, il faut prendre du temps pour bien clarifier l’objectif que l’entreprise veut
atteindre par l’informatique (plan stratégique).
5.4. Ressources de l’auditeur

Après avoir discuté avec le responsable de l’audit ou le Directeur général,
l’auditeur doit rassembler les documents dont il a besoin : le plan directeur,
l’organigramme, les procédures de sauvegarde.
Tous les documents qui se trouvent et donc qui existent au sein de l’entreprise ne
sont plus à reprendre ; s’il n’y en a pas, il faut en faire.
Le rapport sera basé sur ces ressources documents qui seront mentionnées en fin
de rapport (cf. bibliographie).
Chaque fois que vous utilisez un document, vous devez le citer dans le rapport.
Il faut évidemment contrôler l’exactitude de toutes les sources.
5.5. Travaux de l’auditeur

Cela dépend de ce qu’on va auditer.
La liste des travaux peut être : interviews, relevés du matériel, de ressources
humaine et financière, le contrôle de la qualité, des logiciels, … cf. tout ce qui a
été vu avant le but, l’objectif de ces travaux est d’obtenir le plus d’informations
possibles afin d’avoir une vision claire et correcte des forces et lacunes des
services informatiques.
Plus vous avez des informations, plus le rapport sera clair (non confus).
Ce n’est pas nécessaire de faire beaucoup d’interviews ou de relevés ; il faut
surtout atteindre une représentation claire (non confuse) de la structure.
Un bon auditeur est quelqu’un qui voit très vite la lacune, le problème, les
tensions, les enjeux, …
5.6. Rapport de l’audit

C’est le temps de rédiger le rapport lorsqu’on a une vision très claire de la
situation, et ce en fonction des objectifs du départ, et proposer des solutions
adéquates en fonction des lacunes mises en évidence.
Le rapport contiendra les parties suivantes :
a) Introduction : contexte de l’audit
b) Historique du service informatique et le plan stratégique (objectifs
informatiques de l’entreprise)
c) le plan directeur et l’organigramme [à partir de ce point, tout devient
dépendant de l’audit]
d) Les ressources matérielles [ou Le service « clientèle »]
e) Les ressources humaines [ou le service « comptabilité »]
f) Les ressources financières [ou le service « gestion de stocks »]
g) Les services spécialisés (cf. chapitre 4)
h) L’analyse de la situation et des lacunes
i) Proposition de solutions

j) Conclusions
5.7. Le suivi de l’audit

Lorsque le rapport est rédigé, on le transmet pour réception (les autorités
peuvent observer des amendements ou des compléments d’informations).
Dès réception, on peut faire une présentation des conclusions aux différents
niveaux intervenant dans l’audit. Il est important que le pas qui rencontre
l’auditeur pour qu’il soit informé des résultats de l’audit, si cela est possible et
en tout cas pas la direction. C’est transparent qu’un facteur important pour le
succès de la mise en œuvre des solutions proposées par l’audit.
De toutes les façons, le résultat de l’audit ne vous concerne pas, sauf à ceux qui
ont payé l’audit.
Vous ne pouvez pas publier les résultats de l’audit qu’avec la permission de son
commanditaire.


Cours Auditinformatique 2014 2015 OK

Transféré par

Informations du document

Titre original

Copyright

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 :

Cours Auditinformatique 2014 2015 OK

Titre original :

Transféré par

Droits d'auteur :

ISP-BUKAVU

Cours d’Audit Informatique en L2 Informatique de Gestion, 2014-2015 (CT Bulabula) Page 1

Cours d’Audit Informatique en L2 Informatique de Gestion, 2014-2015 (CT Bulabula) Page 2

ETAT DES LIEUX DES ENTREPRISES PUBLIQUES

Une observation fouillée du parc informatique utilisé au sein des entreprises

Cours d’Audit Informatique en L2 Informatique de Gestion, 2014-2015 (CT Bulabula) Page 3

Cours d’Audit Informatique en L2 Informatique de Gestion, 2014-2015 (CT Bulabula) Page 4

Cours d’Audit Informatique en L2 Informatique de Gestion, 2014-2015 (CT Bulabula) Page 5

0.2. Les objectifs

Cours d’Audit Informatique en L2 Informatique de Gestion, 2014-2015 (CT Bulabula) Page 6

1.1. Définition et types

Un audit se fera donc en quatre étapes successives suivantes :

1.1.2. Types d’audit

Pourquoi un audit externe ?

Cours d’Audit Informatique en L2 Informatique de Gestion, 2014-2015 (CT Bulabula) Page 7

Les contraintes qui s’imposent à l’auditeur externe sont néanmoins similaires

Les avantages de l’audit interne sont la compétence, l’impartialité, la neutralité,

Les désavantages de l’audit externe.

Cours d’Audit Informatique en L2 Informatique de Gestion, 2014-2015 (CT Bulabula) Page 8

Les avantages de l’audit interne : le contraire de l’audit externe.

1.2. Principe d’audit

Exemple.– Une « évaluation du système informatique », pourtant souvent

PRINCIPE.– Auditer rationnellement est expliciter les finalités de l’audit, puis en

1.3. Règles d’audit

Cours d’Audit Informatique en L2 Informatique de Gestion, 2014-2015 (CT Bulabula) Page 9

Les règles sont identiques à celles du management, sauf une, la faisabilité. En

REGLE.– L’audit informatique est toujours faisable (contrairement au

Cours d’Audit Informatique en L2 Informatique de Gestion, 2014-2015 (CT Bulabula) Page 10

1.4. Objectifs de l’audit

Au-delà même de l’objectif cible qu’est la maîtrise du SI, beaucoup de

Cours d’Audit Informatique en L2 Informatique de Gestion, 2014-2015 (CT Bulabula) Page 11

Audit – L’attente d’une justification budgétaire

Cours d’Audit Informatique en L2 Informatique de Gestion, 2014-2015 (CT Bulabula) Page 12

Audit – Test de performance

Audit – Test d’alignement

Audit – Test pour rassurer

Audit – L’arme du paladin ou du chevalier noir

Cours d’Audit Informatique en L2 Informatique de Gestion, 2014-2015 (CT Bulabula) Page 13

Audit – L’attente d’une réponse

Les points communs…

Cours d’Audit Informatique en L2 Informatique de Gestion, 2014-2015 (CT Bulabula) Page 14

1.5. Démarches de l’audit

Cours d’Audit Informatique en L2 Informatique de Gestion, 2014-2015 (CT Bulabula) Page 15

1.7. Types d’erreurs

Types d’erreurs de dysfonctionnement

Cours d’Audit Informatique en L2 Informatique de Gestion, 2014-2015 (CT Bulabula) Page 16

Cours d’Audit Informatique en L2 Informatique de Gestion, 2014-2015 (CT Bulabula) Page 17

Pourquoi le CobiT (Control objectives for information and related technology)?:

Pour qui ? Pour

Cours d’Audit Informatique en L2 Informatique de Gestion, 2014-2015 (CT Bulabula) Page 18

Les ressources du COBIT® constituent un modèle de bonnes pratiques. La

Cours d’Audit Informatique en L2 Informatique de Gestion, 2014-2015 (CT Bulabula) Page 19

NORME D’AUDIT DES SYSTÈMES D’INFORMATION

Cours d’Audit Informatique en L2 Informatique de Gestion, 2014-2015 (CT Bulabula) Page 20

Cours d’Audit Informatique en L2 Informatique de Gestion, 2014-2015 (CT Bulabula) Page 21

Cours d’Audit Informatique en L2 Informatique de Gestion, 2014-2015 (CT Bulabula) Page 22

2.2. La politique informatique

Cours d’Audit Informatique en L2 Informatique de Gestion, 2014-2015 (CT Bulabula) Page 23

Le service informatique est autonome (indépendant) des autres services, à part la

Exemple 3 : Voici le schéma de MesOrdi (2004-2005) : Cf. TP

Cours d’Audit Informatique en L2 Informatique de Gestion, 2014-2015 (CT Bulabula) Page 24

Cf. TP d’audit informatique

2.3. Le schéma ou le plan directeur

Cours d’Audit Informatique en L2 Informatique de Gestion, 2014-2015 (CT Bulabula) Page 25

Cours d’Audit Informatique en L2 Informatique de Gestion, 2014-2015 (CT Bulabula) Page 26