Université Internationale d'Agadir

Audit et contrôle en milieu informatisé

Professeur

Abdelhaq Elbekkali, Ph.D, CPA (Expert-comptable)

1
 Partie II.

Contrôle et audit en milieu informatisé.

Audit II_A. El bekkali_ A 2018 2

A. Les contrôles en environnement informatisé

B. La gouvernance des technologies de l’information

C. L’audit comptable en environnement informatisé.

3
 A. Les contrôles en milieu informatisé

a. Les risques reliés aux TI

b. L’ impact des TI sur le contrôle interne

c. Les contrôles généraux et les contrôles des

applications.

4
 a. Les risques reliés aux TI

 Pourquoi les TI, sont si importantes à l’heure actuelle?

 Les opportunités offertes par les TI en matière de réduction

des coûts opérationnels;

 Les processus des organisations dépendent de plus en plus

des TI;

 La capacité des TI de changer radicalement les pratiques

d’affaires;

 Les menaces qui pèsent sur les SI (vulnérabilité);

 Les coûts reliés aux SI.

5
Les principaux risques technologiques

 Les virus informatiques

 Les fraudes informatiques

 L’accès non autorisé au système

 La perte et/ou la modification de données et programmes

 Les pannes du système.

6
 Ces risques ont un impact sur les objectifs du système

Disponibilité

Confidentialité
Exhaustivité

Autorisation
Intégrité

Exactitude

Maintenabilité

7
Trois catégories de fraudes informatiques

 Le vol d’information

 Le vol d’éléments d’actif à la suite de manipulations de données

 La destruction volontaire d’informations ou de programmes.

8
Les applications comptables figurent parmi les systèmes privilégiés par
les fraudeurs :

 Bordereau de paie

 Les comptes clients

 Les comptes d’avantages sociaux

 Les comptes des notes de frais.

9
Ex de manipulations de données :

 Addition ou suppression de noms de la liste des fournisseurs

autorisés;

 Altération de la cote de crédit des clients au fichier maître;

 Insertion de code d’identification spécial aux inscriptions

frauduleuses de manière à ce que ces dernières ne figurent pas dans
les rapports sur les exceptions;

 Etc….

10
Comment protéger l’entité contre les fraudes informatiques?

Des procédures de contrôle interne telles que:

 La séparation des fonctions incompatibles

 L’utilisation de mots de passe

 Le chiffrement (encryptage) des fichiers contenant des

informations critiques afin d’empêcher qu’ils soient copiés sans
autorisation

 L’exercice d’un contrôle strict sur l’accès physique aux

ordinateurs.

11
 La vérification des antécédents personnels des employés (au
moment du recrutement et périodiquement)

 La rotation du personnel (notamment du personnel assumant des

fonctions clés)

 L’examen de toutes les plaintes des clients. Comme minimum, on

devrait consigner toutes les erreurs du système et leur correction et
les faire revoir par une personne indépendante, pour expliquer le
pourquoi et le comment de ces erreurs.

12
Quelques pistes pour détecter les fraudes potentielles commises par les
employés

 Changement dans les habitudes de vie des employés : train de vie

trop grand par rapport au salaire!

 Acharnement au travail. L’employé ne quittant jamais le bureau

avant les autres ou qui ne prend jamais de vacances!

 Absence de délégation.

13
b. L’impact des TI sur le contrôle interne

Cet impact se manifeste au niveau:

1. de la structure organisationnelle

2. de la nature du traitement de l’information

3. de la conception des procédures de contrôle.

14
1. Impact des TI sur la structure organisationnelle

Quelques éléments:

 Le manque de compétence de la haute direction en matière de TI

nuit à sa capacité de bien comprendre et contrôler les TI;

 Le traitement de l’information dans un système informatisé, fait

intervenir un nombre restreint de personnes, comparativement à
un système manuel. Risque donc de concentration de la
connaissance du système et par conséquent, risque de limitation
de la séparation des tâches.

15
2. Impact des TI sur la nature du traitement

 Possibilité d’absence de documents appuyant les données

introduites. Les données peuvent être entrées en ligne (les
autorisations sont automatisées)

 Possibilité d’absence de documents de sortie visibles.

16
3. Impact des TI sur la conception des procédures de contrôle

 Automatisation des procédures des contrôles (plus fiables)

 L’enregistrement d’une opération erronée comporte le risque

de se répercuter sur d’autres enregistrements

 Dans un environnement manuel, il est généralement possible

d’identifier la ou les personnes ayant accordé l’autorisation
d’une opération. Dans un environnement informatique, cette
autorisation peut être automatisée

 Dans un système manuel, une erreur humaine peut se produire

et ce, même si les contrôles sont efficaces (ex. passer outre les
contrôles), ce qui n’est pas le cas dans un système informatisé.

17
c. Les contrôles généraux informatiques et les contrôles
des applications

Deux types de contrôles des TI doivent fonctionner conjointement pour

assurer un traitement complet et exact de l'information :

1. les contrôles généraux informatiques

2. et les contrôles des applications.

18
1. Les contrôles généraux informatiques (CGI)

Consistent en des politiques et procédures qui couvrent

plusieurs applications et qui permettent le fonctionnement
efficace des contrôles des applications

Ces contrôles ont donc pour but d’assurer la fiabilité et

l’intégrité de l’environnement de traitement informatique.

19
Les CGI portent notamment sur:

 le fonctionnement du centre de traitement et du réseau;

 l'acquisition, la modification et la maintenance du système

d'exploitation et des logiciels d'application;

 les modifications des programmes;

 la sécurité d'accès au moyen de mots de passe, l'accès à

distance, Internet, etc.

(Ces contrôles seront revus plus loin avec le cadre Cobit)

20
2. Les contrôles des applications

Ces contrôles se rapportent aux tâches particulières exécutées par le

système informatique

Ils visent à fournir un degré raisonnable de certitude que

l’enregistrement, le traitement et la communication des données sont
exécutés correctement.

21
Pour les contrôles des applications, on distingue entre :

 Les contrôles portant sur l’entrée des données

 Les contrôles portant sur le traitement des données

 Les contrôles portant sur les données de sortie.

22
2.1. Contrôles portant sur l’entrée des données

Ces contrôles visent à fournir une assurance raisonnable que les

données entrées dans le système ainsi que les données transmises
par les voies de communication, ont été correctement enregistrées
dans le système et sont intègres

2.2. Contrôles portant sur le traitement

L’objectif de ces contrôles est de s’assurer que le traitement des

opérations a été effectué comme prévu, c’est-à-dire que:

• toutes les opérations autorisées ont été traitées;

• que les opérations traitées ont été toutes autorisées;

• et que le traitement des opérations est exact.

23
Quelques exemples de contrôles de traitement:

 Le contrôle de séquence. contrôle qui assure que les données

suivent un ordre numérique, alphabétique, chronologique ou
autre. Ex. Dans le cas d’une paie, le programme pourrait inclure
une ou des instructions qui demandent au système de s’assurer
que les cartes de temps des employés sont entrées, traitées et
classées, dans l’ordre des numéros de ces derniers;

 Le contrôle de limite. contrôle portant sur le respect de bornes

préétablies. Ex. Marge de crédit; gestion de stocks, etc.

24
 Le contrôle d’exhaustivité. Contrôle qui assure que les
renseignements enregistrées, renferment tous les éléments
d’informations requis. Ex. Pour l’émission du chèque de paie, un
contrôle (programmé ou manuel) assurera que toutes les
informations relatives aux bénéficiaires requises pour le
paiement, sont fournies

 Le contrôle logique. Contrôle permettant de s’assurer que les

informations traitées ne contiennent pas des éléments
incompatibles. Ex. Incompatibilité due au sexe, à l’âge, ou à toutes
autres caractéristiques d’une personne

 Le chiffre d’autocontrôle Permet de vérifier l’authenticité des

numéros identifiant des personnes ou des choses. Ex. no
d’employé; no de carte de crédit, etc.

25
2.3. Contrôles portant sur les données de sortie (ou sur les résultats)

Ces contrôles visent à procurer l’assurance que:

o les résultats du traitement sont exacts

o que seul le personnel autorisé, a accès aux données de sorties

Ces contrôles ont donc pour objectif l’examen des résultats en vue
d'en établir l’intégrité.

26
B. La gouvernance des Technologies de l’Information (GTI)

a. Les fondamentaux de la GTI

b. Cobit : le référentiel des meilleures pratiques en GTI

c. L’évaluation des contrôles via Cobit.

27
a. Les fondamentaux de la Gouvernance des TI

La gouvernance des TI est un sous-ensemble de la gouvernance

d’entreprise

La gouvernance d’entreprise peut être définie comme, « l’ensemble des

responsabilités et pratiques exercées par le conseil d’administration et la
direction dans le but de fournir une orientation stratégique permettant
d’assurer que les objectifs fixés sont atteints et que les risques sont
gérés de façon appropriée et que les ressources de l’organisation sont
utilisées de façon responsable »

Source: ISACA (Information Systems Audit and Control Association). 2001.

Traduction libre

28
 La GTI

« La gouvernance des TI (GTI) intègre et institutionnalise les bonnes

pratiques pour s’assurer que les TI supportent les objectifs d’affaires de
l’organisation. La GTI permet à l’organisation de tirer avantage de son
système d’information, en maximisant les bénéfices, en profitant des
opportunités et en obtenant un avantage concurrentiel »
(Cobit 4.1)

Autres éléments de la GTI:

 La GTI vise à réduire les risques reliés à l’utilisation des TI, par le
biais du contrôle et de l’audit pour atteindre les objectifs du système:
l’intégrité, la disponibilité, la confidentialité et la maintenabilité;

 La GTI, comme tout autre sujet de gouvernance, relève de la

responsabilité directe du Conseil d’Administration.

29
 La GTI permet donc de s’assurer:

 Que les TI sont gouvernées en fonction des meilleures

pratiques assurant que les TI supportent les objectifs d’affaires;

 Que les ressources TI sont utilisées de façon responsable;

 et que les niveaux des risques TI sont gérés de façon

appropriée

Bref, la GTI permet d’assurer l’alignement de la stratégie TI

sur la stratégie d’affaires de l’organisation.

30
b. Cobit : le référentiel des meilleures pratiques en GTI

Un référentiel, c’est quoi?

Ensemble de règles et d’usages que les professionnels reconnaissent

comme vrais et qui devraient être appliqués. On parle aussi de modèle ou
de cadre (framework)

Les meilleures pratiques, c’est quoi?

Une bonne pratique, est une pratique conforme à l’état de l’art d’un
domaine donné. Fruit de l’expérience et de la recherche, son efficacité et
sa fiabilité sont avérées, ont été éprouvées et sont reconnues par tous;

Dans le domaine des TI, il existe de nombreuses bonnes pratiques dont

l’application permet la performance du système et par conséquent, celle
de l’organisation.

31
De nombreux référentiels ont été conçus pour aider les organisations
à encadrer leur GTI et la rendre effective, dont les plus reconnus et
utilisés sont:

 Cobit (Control Objectives for Information and Related

Technology);

 ITIL (The IT Infrastructure Library);

 ISO 27000;

 CMMi (Capability Maturity Model Integration);

 PMBOK (Project Management Body of Knowledge).

32
Quelle est l’utilité du recours à un référentiel de gouvernance des TI?

 Adopter les meilleures pratiques dans le domaine;

 Adopter une démarche ordonnée, rigoureuse et systématisée;

 Améliorer la gestion de processus en mettant l’accent sur les

éléments prioritaires et en suggérant des solutions pertinentes;

 Se conformer à une réglementation ou à une norme;

 Se positionner en terme de conformité ou de performance par

rapport aux tiers (quel est notre niveau de maturité?).

33
 Cobit
(Control Objectives for Information and Related Technology)

Le référentiel Cobit de l’IT Governance Institute [1] et de l’ISACA [2]

se présente aujourd’hui comme le standard de facto en matière
de GTI

Cobit est un référentiel qui permet d’organiser, par le contrôle,

l’alignement entre les objectifs établis par la direction, les besoins
des utilisateurs et les ressources disponibles

Cobit s’appuie sur le principe que les systèmes d’information doivent

être conçus et mis en place pour fournir une information fiable.

[1] www.itgi.org/
[2] www.isaca.org
34
 Cobit, qui en est à sa 5ème version, est la synthèse des meilleures
pratiques, auxquelles les organisations peuvent se référer pour
contrôler et surveiller les risques reliés à l’utilisation de leurs TI

Plus spécifiquement, Cobit permet à l’organisation:

 de structurer ses activités TI sur la base d’un modèle reconnu;

 de faire en sorte que ses TI répondent adéquatement à ses

exigences d’affaires (alignement stratégique);

 de déterminer les ressources TI à contrôler (les applications,

les informations, les infrastructures et les personnes);

 de mieux identifier les objectifs de contrôles à prendre en

considération.

35
CobiT s’adresse aux trois intervenants principaux de
l’organisation:

 La direction

 Les utilisateurs des TI

 Les auditeurs (internes et externes).

36
 La direction (le management)

Cobit permet à la direction:

 de disposer d’un modèle structuré pour maîtriser les risques

(financiers, organisationnels et technologiques), reliés à
l’alignement des TI sur les objectifs de l’entité;

 de mieux définir les besoins en matière de contrôle TI et

d’intégrité de l’information;

 de sensibiliser tous les intervenants à l’importance des

contrôles TI;

 de réaliser efficacement des diagnostics des contrôles TI (listes

détaillée des contrôles).

37
 Les utilisateurs (des TI)

Cobit permet de fournir des garanties quant à la sécurité et aux

contrôles des services informatiques fournis à l’interne ou par des
tiers

 Les auditeurs

Cobit offre aux auditeurs, internes et externes, la possibilité:

 de mieux comprendre les contrôles TI et de mieux réaliser les

tests d’efficacité de ces contrôles;

 de mieux justifier leurs évaluations des contrôles TI et de mieux

formuler leurs recommandations sur ces contrôles.

38
 L’architecture du Cobit

Cadre de Référence (Framework)

Ce cadre s’articule autour:

 des besoins d’information de l’organisation;

 des ressources TI dont elle dispose;

 du processus de gestion TI (domaines dans lesquels peuvent

être définis les objectifs de contrôle).

39
 Besoins de l’organisation en information

Pour atteindre ses objectifs (stratégiques, financiers, opérationnels),

l’organisation doit disposer d’information pertinente. Cette
pertinence est déterminée dans Cobit à partir de sept critères:

 Efficacité: information significative et pertinente pour le processus de

gestion: distribuée de manière ponctuelle, correcte, cohérente et utilisable

 Efficience: Information mise à disposition grâce à l'utilisation optimale (la

plus productive et la plus économique) des ressources

 fiabilité: fourniture d'informations pertinentes pour le fonctionnement de

l'entité et l'exercice des responsabilités

 conformité aux lois et règlements.

40
 Intégrité: Information exacte, exhaustive et autorisée

 Confidentialité: l’information sensible est protégée contre toute

divulgation non autorisée

 Disponibilité: l'information doit être disponible et le rester

lorsqu'un processus de gestion en a besoin. Concerne aussi la
sauvegarde des ressources.

41
 Les ressources TI

Cobit répartit les ressources TI en quatre segments, afin d’en

atténuer la complexité:

 Les informations: les données relatives à une activité, insérées ou

fournies par le système d’information;

 Les applications : ensemble des procédures manuelles et

programmées de traitement des données;

 Les infrastructures : équipement, système d’exploitation, bases

de données, réseau,…

 Le personnel : Les personnes (à l’interne et à l’externe) en charge

de la gestion du système d’information.

42
 Le processus TI

Cobit détermine dans le processus TI:

 4 domaines: regroupement naturel de processus correspondant

souvent à un domaine de responsabilité organisationnel

 34 processus: série d’activités et de tâches groupées et qui

constituent les objectifs de contrôle général

 220 activités: tâches nécessaires à l’obtention d’un résultat

mesurable et qui forment les objectifs des contrôles détaillés.

43
Le processus de gestion est construit dans Cobit sur trois niveaux:

4 Domaines

34 Processus

220 Activités

44
 Chacun des 34 processus du Cobit est destiné à fournir une
information devant répondre aux besoins d’affaires selon les critères
d’efficacité, d’efficience, de confidentialité, d’intégrité, de
disponibilité, de conformité et de fiabilité.

Pour chacun des 34 processus, Cobit détermine 4 rôles présentés

sous l’acronyme RACI :

 Responsible (personne chargée de la réalisation de tâches

reliées à un processus donné),

 Accountable (personne qui fixe les priorités et les directives),

 Consulted (personne devant être consultée),

 et Informed (personne devant être informée).

45
Cube Cobit

46
Le concept de « domaine » est important dans l’architecture Cobit,
car il définit une répartition logique vis-à-vis des systèmes
d’information

Les domaines se définissent comme suit:

 Planification et Organisation (PO)

 Acquisition et Implémentation (AI)
 Distribution et Support (DS)
 Monitoring et Évaluation (ME).

47
 Planification et Organisation (PO)

Ce domaine recouvre, la stratégie et la vision TI permettant de faire

en sorte que les TI contribuent à la réalisation des objectifs de
l’organisation

Cette stratégie doit être planifiée, communiquée

et gérée adéquatement.

48
 Le domaine PO, regroupe les 10 processus suivants:

PO1: définir un plan stratégique TI

PO2: définir l’architecture de l’information
PO3: déterminer l’orientation technologique
PO4: définir l’organisation et les relations TI
PO5: gérer l’investissement informatique
PO6: communiquer les objectifs de la direction (management)
PO7: gérer les ressources humaines
PO8: gérer la qualité
PO9: évaluer les risques
PO10: gérer les projets.

49
Application (des exemples)

PO1. 1 Intégration des TI au plan à long et à court terme de

l’organisation

Objectif de contrôle:

« La direction générale (DG) est responsable du développement et de

la mise en œuvre de plans à long et à court terme qui répondent à
la mission et aux objectifs de l'entreprise. Dans ce but, la DG doit
s'assurer que les TI ainsi que les possibilités qu'elles offrent sont
évaluées de manière adéquate et prises en compte dans les plans
à long et à court terme de l'entreprise. Lesquels plans doivent
permettre de s'assurer que les TI sont bien alignées sur la
mission et les stratégies métiers de l'entreprise ».

50
Application (suite)

PO1.6 Communication des plans informatiques

Objectif de contrôle

« La direction doit s'assurer que les plans informatiques à court et à

long terme sont communiqués aux propriétaires de processus de
gestion et aux autres personnes concernées dans l'entreprise ».

51
 Acquisition et Implémentation (AI)

Ce domaine recouvre la stratégie TI qui doit identifier, développer ou acquérir

les solutions TI et les intégrer adéquatement aux différents processus
d’affaires. La stratégie TI doit aussi s’assurer que les changements et la
maintenance des systèmes sont opérés en concordance avec les
objectifs des différents processus d’affaires

Ce domaine porte sur les points suivants:

 Le développement ou l’acquisition de nouvelles solutions TI répondent

adéquatement aux besoins des processus d’affaires;

 Les nouveaux systèmes acquis ou développés fonctionnent

correctement;

 Les changements réalisés ne remettent pas en cause le fonctionnement

général du système.

52
 Le domaine AI, regroupe les 7 processus suivants:

AI1: trouver des solutions automatisables

AI2: acquérir des applications et en assurer la maintenance
AI3: acquérir une infrastructure technologique et en assurer la
maintenance
AI4: développer les procédures et en assurer l’utilisation
AI5: acquérir les ressources TI
AI6: gérer les changements
AI7: Installer et valider les systèmes.

53
 Distribution et support (DS)

Ce domaine recouvre la fourniture des services informatiques, la

sécurité et la continuité, le support aux utilisateurs

Ce domaine interpelle l’organisation au niveau des points suivants:

 La rentabilité dans l’utilisation des systèmes;

 La sécurité de l’information (intégrité, confidentialité et

disponibilité).

54
 Le domaine DS, regroupe les 13 processus suivants:

DS1: définir et gérer des niveaux de service

DS2: gérer des services tiers
DS3: gérer la performance et la capacité
DS4: assurer la continuité de service
DS5: assurer la sécurité des systèmes
DS6: identifier et imputer les coûts
DS7: sensibiliser et former les utilisateurs
DS8: gérer le service support et les incidents
DS9: gérer la configuration
DS10: gérer les problèmes
DS11: gérer les données
DS12: gérer les installations
DS13: gérer les opérations.

55
 Monitoring et Évaluation (ME)

Ce domaine recouvre l’évaluation et la surveillance de la qualité et de

la conformité des processus informatiques par rapport à des critères
préétablies

Ce domaine interpelle l’organisation au niveau des points suivants:

 La surveillance continue de la performance de l’informatique et

de la correspondance de cette performance aux objectifs des
différents processus d’affaires;

 L’efficacité et l’efficience des contrôles;

 Le suivi et la production de rapports sur les contrôles, les

risques et la performance.

56
 Le domaine ME, regroupe les 4 processus suivants:

ME1: évaluer la performance TI

ME2: surveiller le contrôle interne
ME3: s’assurer de la conformité réglementaire
ME4: fournir de la gouvernance TI.

57
 Objectifs de l’entreprise
Gouvernance des Technologies de l’Information
ME1 Monitor and evaluate IT PO1 Define a strategic IT plan.
performance. PO2 Define the information architecture.
ME2 Monitor and evaluate internal PO3 Determine technological direction.
control. PO4 Define the IT processes, organisation and
ME3 Ensure regulatory compliance. relationships.
ME4 Provide IT governance. PO5 Manage the IT investment.
PO6 Communicate management aims and
direction.
INFORMATION PO7 Manage IT human resources.
PO8 Manage quality.
• Effectiveness
PO9 Assess and manage IT risks.
• Efficiency
PO10 Manage projects.
• Confidentiality
• Integrity
• Availability
• Compliance
• Reliability
MONITOR AND PLAN AND
COBIT 4.1

EVALUATE ORGANISE
IT RESSOURCES
• Applications
• Information
• Infrastructure
• People

ACQUIRE AND
DS1 Define and manage service levels. DELIVER AND
DS2 Manage third-party services.
IMPLEMENT
DS3 Manage performance and capacity. SUPPORT
DS4 Ensure continuous service.
DS5 Ensure systems security. AI1 Identify automated solutions.
DS6 Identify and allocate costs. AI2 Acquire and maintain application software.
DS7 Educate and train users. AI3 Acquire and maintain technology
DS8 Manage service desk and incidents. infrastructure.
DS9 Manage the configuration. AI4 Enable operation and use.
DS10 Manage problems. AI5 Procure IT resources.
DS11 Manage data. AI6 Manage changes.
DS12 Manage the physical environment. AI7 Install and accredit solutions and changes.
DS13 Manage operations.
58
 Le modèle de maturité de Cobit
Pour contrôler efficacement l'infrastructure du système d'information, les
managers se posent souvent le genre de questions suivantes:

 “Jusqu'où devons-nous aller, et le coût est-il justifié par le bénéfice ?”

 “Quels sont les standards internationalement reconnus, et comment

sommes-nous positionnés par rapport à eux ?”

 “Que font les autres et comment sommes-nous positionnés par

rapport à eux ?”

 “Sur le marché, quelles pratiques sont-elles considérées comme les

meilleures, et comment sommes-nous positionnés par rapport à
elles ?”

Pour pouvoir répondre à ces question, le référentiel Cobit offre un

modèle de maturité pour chacun des 34 processus TI.

59
Le modèle de maturité de Cobit permet au propriétaire du processus,
de déterminer le niveau d'adhésion de ce processus aux objectifs de
contrôle, soit sous la forme d'une auto-évaluation, soit en ayant
recours à une évaluation externe

L’évaluation des processus TI sur la base du modèle de maturité de

Cobit consiste pour l’organisation de se situer elle-même sur une
échelle graduée de 0 à 5 (d'Inexistant à Optimisé)

Cette approche est basée sur le Modèle de Maturité (CMMI)

développé par le Software Engineering Institute pour le
développement de logiciels.

60
Modèle de maturité

61
En s’appuyant sur le modèle de maturité, la direction peut faire
apparaître, pour chacun des 34 processus TI du CobiT, :

 l'état actuel de l‘organisation (où elle se situe actuellement);

 l'état actuel des meilleures pratiques du marché (comparaison);

 l'état actuel des standards internationaux (autre comparaison);

 la stratégie de l’organisation en matière de progrès (où

l‘organisation souhaite se situer).

62
 Modèle général de maturité

 Niveau 0 (Inexistant): Absence totale de processus

identifiables. L‘organisation n'a même pas pris conscience
qu'il s'agissait d'un problème à étudier

 Niveau 1 (Initialisé): l‘organisation a pris conscience de

l'existence du problème et de la nécessité de l'étudier. Il
n'existe toutefois aucun processus standardisé, mais des
approches dans ce sens tendent à être appliquées
individuellement ou au cas par cas. L'approche globale du
management n'est pas organisée

63
 Niveau 2 (Reproductible): Des processus se sont développés
jusqu'au stade où des personnes différentes exécutant la même
tâche utilisent des procédures similaires. Il n'y a pas de formation
formelle ou de communication des procédures standard, et la
responsabilité est laissée à l'individu. On se repose beaucoup sur
les connaissances individuelles, d'où une probabilité d'erreurs

 Niveau 3 (Défini): Des procédures ont été standardisées,

documentées et communiquées via des séances de formation.
Toutefois, leur utilisation est laissée à l'initiative de chacun, et il
est probable que des déviations seront constatées. Concernant
les procédures elles-mêmes, elles ne sont pas sophistiquées,
mais formalisent des pratiques existantes.

64
 Niveau 4 (Géré): Il est possible de contrôler et de mesurer la
conformité aux procédures et d'agir lorsque des processus semblent
ne pas fonctionner correctement. Les processus sont en constante
amélioration et correspondent à une bonne pratique.
L'automatisation et l'utilisation d'outils s'effectuent d'une manière
limitée ou partielle

 Niveau 5 (Optimisé): Les processus ont atteint le niveau des

meilleures pratiques, suite à une amélioration constante et à la
comparaison avec d'autres organisations. L'informatique est utilisée
comme moyen intégré d'automatiser les flux de travaux, offrant des
outils qui permettent d'améliorer la qualité et l'effiacacité et de
rendre l‘organisation rapidement adaptable.

65
 Exemple. Maturité du processus PO1: Définir un plan informatique
stratégique

 Niveau 0 Inexistant: Il n'y a pas de planification informatique

stratégique. Le management n'a pas conscience qu'un plan
informatique stratégique est nécessaire à la réalisation des objectifs
de l‘organisation.

66
 Niveau 1 Initialisé, au cas par cas: Le besoin d'un plan informatique
stratégique est ressenti par le management, mais aucun processus
de décision structuré n'est mis en place. On utilise une planification
informatique stratégique en réponse à des besoins spécifiques et les
résultats sont donc sporadiques et sans logique. On en discute
occasionnellement lors de réunions du management des TI et non
lors de réunions de direction de l‘organisation. L'alignement des
besoins de l‘organisation, des applications, et des technologies se
fait d'une façon réactive, portée par l'offre des fournisseurs plus que
par une stratégie générale de l‘organisation. La position stratégique
par rapport au risque est déterminée de façon informelle, projet par
projet.

67
 Niveau 2 Reproductible, mais intuitif: Le management des TI utilise
la planification stratégique, mais sans la documenter. Réalisé par
l'informatique, le plan n'est partagé avec la direction de
l’organisation qu'en réponse à des besoins spécifiques. La mise à
jour de ce plan n'intervient que suite à des demandes du
management : il n'y a aucun processus d'anticipation des mises à
jour du plan rendues nécessaires par les développements de
l'informatique ou de l’organisation. On prend les décisions projet par
projet, sans stratégie globale. On connaît les risques et les avantages
des principales décisions stratégiques pour les utilisateurs, mais leur
définition reste intuitive.

68
 Niveau 3: Défini Une politique définit quand et comment réaliser le
plan informatique stratégique. Ce dernier suit une approche
structurée qui est documentée et connue de tout le personnel. Le
processus de planification informatique est normalement construit
et garantit une bonne probabilité de réalisation d'un plan approprié.
Toutefois, la mise en œuvre du processus est laissée à l'initiative de
chaque responsable et aucune procédure d'examen périodique de
ce processus n'est prévue. La stratégie informatique globale inclut
une définition cohérente des risques acceptés par l‘organisation et
précise si elle se voit en position d'innovateur ou de suiveur. Les
stratégies informatiques en matière de finance, technique et
ressources humaines conduisent de plus en plus à l'acquisition de
nouveaux produits et technologies.

69
Niveau 4: Géré et mesurable: La planification informatique stratégique est une
pratique standard et le management signale les anomalies. Elle correspond
à une fonction de management comportant des responsabilités majeures. Le
processus de planification informatique stratégique est contrôlé par le
management qui l'utilise pour prendre ses décisions en connaissance de
cause et mesurer son efficacité. Il existe à la fois des plans à court et long
terme qui sont diffusés à tous les échelons de l‘organisation, avec des mises
à jour lorsque c'est nécessaire. La stratégie informatique et la stratégie
globale de l‘organisation sont de mieux en mieux coordonnées grâce à
l'utilisation de processus communs et de technologies à valeur ajoutée, et
grâce à la mise en œuvre d'applications et de technologies à travers la ré-
ingénierie des processus de l‘organisation. Il existe un processus bien défini
assurant une bonne répartition entre les ressources internes et externes
nécessaires au développement et à l'exploitation des systèmes. On formalise
de plus en plus les tests comparatifs pour se comparer aux normes du
marché et de la concurrence.

70
Niveau 5 Optimisé: Le plan informatique stratégique est un processus
documenté et vivant ; toujours pris en compte dans la définition des
objectifs de l‘organisation. La valeur apportée par les investissements
informatiques est patente. Le processus de planification tient compte
en permanence des dernières analyses du rapport entre risques et
bénéfices. La stratégie de planification informatique fait partie
intégrante de la stratégie générale de l‘organisation. On développe et
on actualise en permanence des plans informatiques à long terme
réalistes pour refléter l'évolution des technologies et des activités de
l‘organisation. Les plans informatiques à court terme sont constitués
de projets, divisés en tâches planifiées dans le temps, et comprenant
les résultats à livrer ; chaque tâche est contrôlée et actualisée au fur et
à mesure de son évolution. Les tests de comparaison avec les normes
reconnues et fiables du marché constituent un processus bien défini,
intégré au processus de formulation des stratégies. Le Service
Informatique trouve et met en œuvre de nouvelles applications pour
conduire à la création de nouvelles opportunités et améliorer l'avantage
compétitif de l‘organisation.

71
 Le modèle de maturité se base donc sur le principe suivant :

La qualité d'un système est largement tributaire de la qualité du

processus utilisé pour son développement (et sa maintenance)

Un processus immature est improvisé et chaotique. Il est caractérisé

par :

 une imprévisibilité des coûts et de la qualité;

 une gestion par crise ;
 des succès grâce aux «héros», en dépit des processus

Cela occasionne des impacts importants dont :

 Perte de temps ;
 Stress et burn-out ;
 Technologie mal exploitée ;
 Contribution faible aux objectifs d’affaires.

72
c. L’évaluation des contrôles via Cobit

Dans le cadre d’un audit informatique ou d’un audit comptable

(commissariat aux comptes), l’auditeur peut s’appuyer sur Cobit pour
évaluer les contrôles informatiques

Exemples de procédures d’évaluation des contrôles généraux reliés

aux:

1. Contrôles de sécurité

2. Contrôles de gestion des changements.

73
1. Contrôles de sécurité

Ces contrôles visent la gestion de l’accès et la protection de

l’intégrité de l’environnement de traitement informatique
et des données informatiques

Ils comprennent notamment un cadre interne de

sécurité de l’organisation (politique et normes), ainsi que
des mécanismes permettant l’authentification des
utilisateurs et la restriction de l’accès, au besoin.

74
 Exemple: contrôles des accès

Objectif: s’assurer que l’accès aux données et aux programmes ou

au système, est réservé aux seules personnes désignées

Exemples de contrôles: « Des politiques, des procédures et des

normes sont établies pour la gestion des codes utilisateurs et des
mots de passe » (CobiT DS 5.4, 5.5 et 5.6)

Exemples de procédures de contrôle: l’auditeur doit s’informer sur:

 les politiques relatives à la gestion des codes utilisateurs et des mots

de passe;

 la politique d’approbation des demandes d’accès, de modification des

droits d’accès, de retrait des droits d’accès (mutations, départs);

 la procédure de réactivation du code utilisateur et la restauration du

mot de passe doivent comporter un moyen d’assurer que c’est le bon
utilisateur qui a accès au système.

75
 Exemple: contrôles des accès (suite)

Exemples de contrôles: « Des procédures d’identification et

d’authentification sont exigés pour entrer dans le système » (CobiT
DS 5.8)

Exemples de procédures de contrôle: l’auditeur doit:

 vérifier, par le biais du fichier contenant la liste des mots de

passe, que ces derniers sont stockés sous forme cryptée;

 vérifier à travers un échantillon de documents d’autorisation

d’accès, si la ou les autorisation (s) donnée (s) est (sont)
appropriée (s).

76
2. Contrôles de gestion des changements

Ces contrôles visent la gestion de changement apportés à

l’environnement de traitement informatique, aux applications,
et aux données qui peuvent avoir une incidence sur l’intégrité
et la fiabilité du traitement informatique

Ils comprennent notamment les contrôles à l’égard de

l’amorce et de l’autorisation d’un changement, de la mise à
l’essai du changement et de son déploiement dans un
environnement de production.

77
Contrôles de gestion des changements (suite)

L’objectif de l’évaluation de ces contrôles, est de vérifier si les

modifications apportées aux applications, programmes et données,
ont été approuvées, conçues, mises à l’essai et appliquées selon les
règles

Exemples de contrôles: « Des procédures sont en place pour la

journalisation et la mise en œuvre de toutes les modifications
prévues » (CobiT AI 6.1)

Exemples de procédures de contrôle: Le praticien doit :

 vérifier si les demandes de modifications sont consignées dans

un journal;

 s’informer sur le type d’information nécessaire pour déclencher

une modification.

78
Contrôles de gestion des changements (suite)

Exemples de contrôles: « Seules des modifications autorisées sont

déclenchées » (CobiT AI 6.5)

Exemples de procédures de contrôle: Le praticien doit:

 vérifier, à partir d’un échantillon de formulaires de demandes de

modifications journalisées, si ces formulaires ont été autorisés par
le responsable du service utilisateur concerné avant de procéder à
la modification;

 vérifier la validité des modifications réalisées, à partir d’un

échantillon de modifications journalisées dans les journaux des
problèmes d’exploitation.

79
C. L’audit comptable en environnement informatisé

80
 L’audit comptable réalisé dans un environnement
informatique peut poser à l’auditeur des difficultés de mise
en œuvre en termes d’approche, de nature des procédures
à réaliser et d’exploitation des résultats obtenus à l’issue de
ces procédures

La prise en compte de l’environnement informatique lors

d’un audit ne doit pas être confondue avec l’audit
informatique d’un système d’information confié
généralement à des experts spécialisés.

81
 l’existence d’un environnement informatique ne modifie pas
l’objectif et l’étendue de la mission de l’auditeur

 l’utilisation des TI modifie la saisie et le processus de traitement et

de conservation des données et en conséquence peut avoir une
incidence sur les systèmes comptables et le contrôle interne de
l’entité

 un environnement informatique peut ainsi avoir une incidence sur la

démarche de l’auditeur lors :

 de la phase de la planification de la mission

 de la phase d’exécution des procédures d’audit.

82
 Phases de la mission Tâches à réaliser

 Prise de connaissance de
l’environnement informatique et
description du système d’information
de l’entité
Phase de la planification de la mission

 Incidence de l’environnement
informatique sur le risque
d’anomalies significatives (RAS)

Phase de l’exécution des procédures  Incidence de l’environnement

d’audit informatique sur les procédures
d’audit.

83
 Phases de la mission Tâches à réaliser

 Prise de connaissance de
l’environnement informatique et
description du système d’information
de l’entité
Phase de la planification de la mission

 Incidence de l’environnement
informatique sur le risque
d’anomalies significatives (RAS)

Phase de l’exécution des procédures  Incidence de l’environnement

d’audit informatique sur les procédures
d’audit.

84
 I. Phase de la planification de la mission

a. Prise de connaissance de l’environnement informatique et

description du système d’information de l’entité

b. Incidence de l’environnement informatique sur le risque

d’anomalies significatives (RAS).

85
a. Prise de connaissance de l’environnement informatique et
description du système d’information de l’entité

1. Prise de connaissance de l’environnement informatique

L’auditeur s’intéresse à deux domaines de l’environnement

informatique de l’entité qui peuvent impacter les procédures
d’élaboration des comptes (enregistrement, traitement et sortie des
données), à savoir:

1.1. La stratégie informatique de l’entité

1.2. La fonction informatique de l’entité.

86
1.1. La stratégie informatique de l’entité

 Pourquoi l’auditeur doit-il s’intéresser à la stratégie informatique de

l’entité auditée?

Car dans le cas où l’entité ne planifie pas correctement ses besoins

actuels et futurs de ses ressources TI, cela aurait pour effet d’augmenter
le risque inhérent (RI).

87
 A quoi l’auditeur doit-il s’intéresser lors de sa prise de connaissance
de la stratégie informatique de l’entité auditée?

L’auditeur doit porter son attention sur les éléments suivants:

 la connaissance des dirigeants quant à l’existant et aux évolutions futures du

système d’information

 La connaissance des dirigeants quant aux risques auxquels l'entité est

exposée du fait de l’utilisation de solutions informatiques et les mesures
prises pour gérer ces risques

 L’implication des entités métiers dans la détermination de la stratégie

informatique (processus d’élaboration).

88
 Quels sont les éléments probants que l’auditeur doit obtenir à ce
chapitre?

 de la documentation telle que : les PV du CA; le budget informatique

des deux ou trois dernières années et prévisions

 confirmation des informations obtenues lors de l’entretien avec la

direction: entretien avec le responsable informatique

 entretien avec des utilisateurs clés représentant les différentes

entités métiers.

89
1.2. La fonction informatique

L’auditeur doit s’intéresser à deux éléments importants:

1.2.1. L’organisation de la fonction informatique

1.2.2. Les compétences informatiques.

90
1.2.1. L’organisation de la fonction informatique

 Pourquoi l’auditeur doit-il s’intéresser à l’organisation informatique

de l’entité auditée?

Car dans le cas où cette fonction est mal structurée , où la séparation de

fonctions et des tâches est inadéquate, cela ferait augmenter
le risque d’anomalie significative.

91
 A quoi l’auditeur doit-il s’intéresser lors de sa prise de connaissance de
l’organisation de la fonction informatique de l’entité auditée?

L’auditeur doit s’interroger, notamment, sur:

 Les caractéristiques de l’organisation informatique :
• l’existence ou non de la fonction informatique
• l’existence d’un organigramme à jour comprenant une définition
des fonctions et un partage clair des rôles et des responsabilités
pour chaque poste

 La séparation des tâches : le maintien de la séparation des tâches lors de la

rotation des équipes, des congés ou de départ d’un salarié

 Le recours aux prestataires : nombre de prestataires, degré de dépendance

vis-à-vis des prestataires, …

92
Principales fonctions d’une direction informatique dans une entreprise de grande
taille

Direction générale

Autres
directions

Sécurité DSI Audit interne

Conception Exploitation
Maintenance
informatique informatique

Progiciels Système
système Réseau
d’exploitation

93
 Quels sont les éléments probants que l’auditeur doit obtenir à ce
chapitre?

Entretiens avec le responsable informatique sur:

 La description de l’organigramme général et de la fonction informatique

 La description des postes, des fonctions et des responsabilités des
membres de la fonction informatique
 Les tâches effectuées par le service de l’informatique et localisation
géographique des services
 recours à la sous-traitance

Ces informations peuvent être complétées par des entretiens avec les
responsables des départements métiers.

94
1.2.2. Les compétences informatiques

 Pourquoi l’auditeur doit-il s’intéresser aux compétences

informatiques de l’entité auditée?

Car un service informatique qui comprend un personnel

mal ou insuffisamment formé, ou surchargé, ou évalué
de façon inadéquate ou dont le taux de rotation est
élevé, cela contribue à augmenter le niveau du risque
d’anomalies significative.

95
 A quoi l’auditeur doit-il s’intéresser lors de sa prise de connaissance
des compétences informatiques de l’entité auditée?

L’auditeur doit s’interroger, notamment, sur:

 Le niveau de compétence:

• compétences en rapport avec les besoins actuels et futurs notamment

dans la perspective programmée d’un changement de technologie
• niveau de formation du personnel du service informatique
• mesure de la performances du personnel

 La charge de travail par rapport aux ressources humaines disponibles:

nombre d’heures supplémentaires/nombre d’heures travaillées

 Le niveau de rotation du personnel: nombre de départs sur les deux

dernières années; stabilité du niveau d’occupation.

96
 Quels sont les éléments probants que l’auditeur doit collecter à ce
chapitre?

 entretiens avec le responsable de l’informatique

 analyse des documents suivants: calendrier des formations, comptes

rendus annuels des évaluation, …

 confirmation de ces informations auprès des utilisateurs clés

représentant les différentes directions.

97
 b. Incidence de l’environnement informatique sur le
risque d’anomalies significatives (RAS)

Lors de cette phase, l’auditeur évalue l’impact de l’environnement

informatique sur le risque inhérent et sur le risque lié au contrôle

Cette évaluation permettra à l’auditeur de planifier les procédures

substantives qu’il devra mener à la clôture des comptes, à l’aide ou non
de techniques d’audit assistées par ordinateur (TAAO), afin de maintenir
le risque d’audit acceptable à un niveau faible.

98
 Phases de la mission Tâches à réaliser

 Prise de connaissance de
l’environnement informatique et
description du système d’information
de l’entité
Phase de la planification de la mission

 Incidence de l’environnement
informatique sur le risque
d’anomalies significatives (RAS)

Phase de l’exécution des procédures  Incidence de l’environnement

d’audit informatique sur les procédures
d’audit.

99
1. Incidence de l’environnement informatique sur le risque inhérent

Cette incidence est appréciée par l’auditeur à travers la vérification de:

1.1. la conception et l’acquisition des solutions informatiques

1.2. la distribution et le support informatique

1.3. la gestion de la sécurité.

100
1.1. Conception et acquisition des solutions informatiques

1.1.1. Comment les solutions informatiques sont-elles acquises ou

développées?

Les modalités d’acquisition ou de développement de solutions

informatiques ont un impact sur le risque inhérent

L'entité doit avoir mis en place des procédures qui permettent

d’identifier les besoins informatiques et de mener à terme les projets
d’acquisition ou de développement de solutions.

101
L’auditeur doit vérifier que:

 les besoins en nouveaux outils sont correctement identifiés

 une fonction développement distincte est prévue dans la structure

informatique de l'entité

 les développements/paramétrages suivent des procédures

formalisées :

• rédaction de cahier des charges / spécifications

• validations par la direction ou le responsable informatique

 les procédures de tests sont définies

• tests formalisés avant la mise en production.

102
Quels éléments probants?

 Documentation suivante:

• procédures de développement (langage utilisé, environnement

utilisé, etc.)

• dossier de paramétrage

• contrats de sous-traitance de solutions informatiques

 Entretiens avec le responsable informatique et le responsable du

développement.

103
1.1.2. Comment sont installés et validés les nouveaux systèmes informatiques ?

L'entité doit avoir mis en place des procédures pour permettre une mise en
place sans risque d’un nouvel outil ou d’une nouvelle application

L’auditeur doit vérifier que :

 des tests ont été menés avant le démarrage de toute nouvelle application ou
d’une nouvelle version

 les développements sont validés par la direction ou le responsable

informatique avant d’être déployés

 La documentation des outils est appropriée

 des méthodes de gestion du changement sont prévues pour faciliter le

démarrage.

104
Quels éléments probants?

L’auditeur peut s’appuyer sur:

 l’analyse des documents suivants :

• inventaire des solutions informatiques

• calendrier des tests de validation
• comptes rendus des tests

 les entretiens avec les personnes suivantes :

• responsable informatique
• responsable du développement
• utilisateurs ayant participé à la mise en place
• responsables opérationnels associés au projet.

105
La mise en production d’une application mal ou insuffisamment testée
peut avoir des conséquences directes sur l’établissement des comptes

Si le système d’information présente des failles de conception, les

comptes pourront contenir des anomalies significatives.

106
Exemple

Une société de production et de négoce d’un produit X a mis en place

une nouvelle application de gestion des ventes. Faute de temps,
l’application a été testée rapidement et seuls les principaux types de
vente ont été testés

L’application a été mise en production quelques mois avant la fin de

l’année qui est la période au cours de laquelle 70 % du chiffre d’affaires
est réalisé

Au mois de décembre, alors que l’activité était maximale, les

commerciaux se sont aperçus qu’il était impossible d’enregistrer dans
l’application les ventes du produit X en coffret (une unité du produit X
plus un produit Y)

107
 En effet, cette fonctionnalité n’avait pas été testée et ne fonctionnait
pas dans la nouvelle application. Toutes les ventes de ce type ont donc
été enregistrées manuellement sur un cahier et saisies par la suite en
comptabilité

Le risque est la non exhaustivité des enregistrements et le non respect

de la séparation des exercices qui aurait été évité si l’application avait
fait l’objet de tests plus complets.

Cet exemple montre qu’une des difficultés est de recenser

préalablement tous les cas de figures qui peuvent se présenter et pour
lesquels une réponse doit être prévue et testée. Ainsi, la coopération
des utilisateurs en amont du processus s’avère indispensable.

108
1.1.3. Comment est assurée la maintenance du système d’information ?

L'entité doit avoir mis en place des procédures permettant la continuité

d’exploitation des applications, leur pérennité et leur disponibilité

L’auditeur doit vérifier:

 que le département informatique a une bonne maîtrise de ses applications

et est capable de les maintenir

 que le recours à une maintenance externalisée n’entraîne pas une

dépendance trop forte de l'entité vis-à-vis de ses prestataires.

109
L’auditeur peut s’appuyer :

 sur l’analyse des documents suivants :

• les contrats de maintenance

• le journal des interventions du service maintenance/sous-traitance
• le comptes rendus d’intervention des sous-traitants

 sur les entretiens avec les personnes suivantes :

• responsable informatique,
• responsable de la fonction maintenance/exploitation,
• Propriétaires métiers (ventes, achats, comptabilité, etc.).

110
1.2. Distribution et support

1.2.1. Quelle est la qualité du support fourni aux utilisateurs?

1.2.2. Comment sont gérés les problèmes d’exploitation quotidiens ?

1.2.3. Comment sont gérées les fonctions externalisées ?

111
1.2.1. Quelle est la qualité du support fourni aux utilisateurs?

L'entité doit avoir mis en place un dispositif de formation et

d’assistance permettant aux utilisateurs d’avoir les connaissances
nécessaires pour une utilisation optimale des outils dont ils ont l’usage
dans le cadre de leurs fonctions

Ainsi, pour chaque nouvel outil, un support aux utilisateurs et/ou une
formation doivent être dispensés, afin de réduire le risque de
mauvaises utilisations (erreurs, traitements inadaptés, etc.).

112
L’auditeur doit vérifier que :

 les utilisateurs disposent d’une information suffisante sur les outils

qu’ils utilisent :

• formation aux nouveaux outils

• documentation et manuel utilisateur disponibles à tout moment
• possibilité de faire appel à une cellule de support

 les procédures de formation sont adaptées (formation initiale/

formation continue).

113
Quels éléments probants?

 analyse des documents suivants :

• plans de formation collectifs / individuels

• demandes de formation (acceptées/refusées)
• évaluation des formations reçues par les participants
• journal des demandes des utilisateurs au support informatique
• journal de suivi des incidents/résolutions par le support informatique

 les entretiens avec les personnes suivantes :

• direction de l'entité
• responsable informatique
• responsable de la formation / Responsable des RH
• responsable du support informatique aux utilisateurs.

114
1.2.2. Comment sont gérés les problèmes d’exploitation quotidiens ?

L’administrateur du système d’information est responsable du bon

fonctionnement de ce système et de son contrôle. C’est à lui de
centraliser les anomalies

Il gère les habilitations d’accès aux données et doit pouvoir détecter les
tentatives d’intrusion. Son rôle est primordial dans la prévention des
risques informatiques.

115
L’auditeur doit:

 analyser les procédures de suivi des dysfonctionnements du système

d’information : suivi des pannes/indisponibilités

 suivi des comptes utilisateurs: recherche de comptes non utilisés qui

peuvent être des points d’entrée potentiels pour des fraudeurs

 fiabilité des identifiants et mots de passe : des outils permettent de

rechercher les mots de passe trop faciles à découvrir (mots du dictionnaire,
prénoms, mots de passe égaux à l’identifiant),

 gestion de niveaux d’habilitation différents selon les postes occupés. Ex.

• habilitations en écriture sur l’application de comptabilité pour l’équipe

comptable et en consultation seule pour le reste des salariés,

• habilitations en consultation des données salariales aux seules équipes

de paye et à la direction.

116
1.3. Gestion de la sécurité

1.3.1. Comment sont gérées les sauvegardes ? Existe-t-il un plan de

secours ?

1.3.2. Comment est définie et mise en œuvre la sécurité logique ?

1.3.3. La sécurité physique est-elle satisfaisante ?

117
 1.3.1. Comment sont gérées les sauvegardes ? Existe-t-il un plan de
secours ?

L'entité doit avoir mis en place des procédures efficaces de sauvegarde

et un plan de secours :

 procédures de sauvegarde : les données de l'entité doivent être

correctement sauvegardées pour qu’en cas de défaillance du
système d’information, ces données soient facilement récupérables

 plan de secours : dans certains secteurs d’activité, l'entité doit

prévoir une solution capable de se substituer au système
d’information courant pour pouvoir faire face à un sinistre majeur.

118
L’auditeur doit:

 vérifier que des procédures de sauvegarde ont été établies et sont

appliquées:

• exhaustivité des applications sauvegardées,

• fréquence des sauvegardes,
• durée et lieu de conservation des données,
• tests réguliers de relecture des supports de sauvegarde

 vérifier que l'entité a mis en œuvre une réflexion sur les solutions de
secours en cas de défaillance du système ou en cas de sinistre :

• plan de reprise d’activité,

• site de repli.

119
Eléments probants

 analyse des documents suivants :

• procédures de sauvegarde formalisées,

• comptes rendus des tests de reprise de données,
• contrats de prestation de plan de secours,
• charte de bonne utilisation du système d’information à destination
des utilisateurs,

 sur les entretiens avec les personnes suivantes :

• responsable de l’informatique,
• responsable de la sécurité,
• prestataire externe en charge des solutions de secours.

120
1.3.2. Comment est définie et mise en œuvre la sécurité logique ?

La vérification de la sécurité logique a pour objectif de s’assurer de

l’existence d’un dispositif adapté à la prévention de ces risques.

121
L’auditeur doit:

 vérifier qu’une politique de sécurité logique a été mise en place par

l'entité (antivirus à jour; protection contre les attaques externes)

 vérifier la politique des habilitations (définition des profils

utilisateurs en adéquation avec les fonctions occupées; utilisation
d’Internet/messagerie; surveillance de l’accès aux données
sensibles)

 Évaluer les mesures de sensibilisation du personnel à la sécurité

logique (existence d’une charte de bonne utilisation du système
d’information signée par les utilisateurs; courriels de sensibilisation).

122
1.3.3. La sécurité physique est-elle satisfaisante ?

 Y-a-t-il un risque de destruction physique des outils informatiques ?

 Y-a-t-il un risque qu’une personne extérieure puisse s’introduire sans

autorisation dans les locaux de la société afin d’accéder au système
d’information (programmes et données)

L’auditeur doit vérifier:

 les moyens d’accès aux locaux de l’entité et plus particulièrement à ceux

abritant les ressources informatiques

 les moyens de protection dont est dotée l'entité pour les types de sinistres
suivants : incendie, inondation, coupure de courant/surtension,
vol/malveillance, pannes.

123
Eléments probants:

 Documents suivants: plan d’accès aux locaux de l'entité; localisation

de la salle informatique; procédures de sécurité en cas d’incendie;
procédures s’appliquant aux visiteurs extérieurs)

 les entretiens avec les personnes suivantes: direction de l'entité;

responsable informatique; responsable de la sécurité)

 la visite des locaux et des salles machines pour vérifier que les
procédures décrites sont appliquées.

124
 II. Phase de l’exécution des procédures d’audit

L’Incidence de l’environnement informatique sur les procédures d’audit.

125
 Phases de la mission Tâches à réaliser

 Prise de connaissance de
l’environnement informatique et
description du système d’information
de l’entité
Phase de la planification de la mission

 Incidence de l’environnement
informatique sur le risque
d’anomalies significatives (RAS)

Phase de l’exécution des procédures  Incidence de l’environnement

d’audit informatique sur les procédures
d’audit.

126
A partir des éléments vérifiés lors de l’évaluation des risques, le CAC se
concentre sur les risques de niveau modéré ou élevé, afin de
déterminer la nature et l’étendue des tests substantifs à mener et s’il
est pertinent, pour ce faire, de recourir aux TAAO.

Le CAC peut recourir à des procédures d’audit manuelles, à des

Techniques d’Audit Assistées par Ordinateur, ou combiner les deux pour
rassembler suffisamment d’éléments probants.

127
Les Techniques d’Audit Assistées par Ordinateurs
(TAAO)

128
 Les Techniques d’Audit Assistées par Ordinateurs
(TAAO)

Dans le cadre d’une mission d’audit, l’ordinateur peut être utilisé par
Le CAC pour automatiser plusieurs opérations routinières

Les TAAO peuvent être utilisées aussi bien par l’auditeur externe que
par l’auditeur interne

Deux types de TAAO: celles axées sur les systèmes (ou sur les
programmes), et celles axées sur les données.

129
1. Les TAAO axées sur les systèmes

 techniques qui reposent sur l’utilisation de programmes qui

permettent d’examiner et de vérifier les contrôles automatisés

 servent surtout à l’exécution des tests de procèdures

 Contrairement aux techniques axées sur les données, qui portent sur
les données réelles de l’entité auditée, les techniques axées sur les
systèmes mettent l’accent sur la mise à l’épreuve des contrôles
internes du système informatique.

130
 Les techniques axées sur les systèmes les plus courantes :

 La méthode du jeu d’essai

 La méthode du jeu d’essai intégré
 La méthode des outils de piratage.

131
 La méthode du jeu d’essai

Permet à l’auditeur de créer des enregistrements d’essai particuliers

et de les faire traiter par les programmes informatiques (programmes
exécutables) utilisés réellement par l’entité

Un jeu d’essai contient habituellement des données qui respectent les

normes (cas normaux) et d’autres qui ne les respectent pas

Il est essentiel que l’auditeur s’assure que les données d’essai sont
traitées par les programmes que l’organisation utilise réellement et non
pas une version modifiée à l’intention de l’auditeur

L’auditeur doit toujours garder le contrôle des sorties résultant des

données d’essai.

132
 La méthode du jeu d’essai intégré

Cette méthode consiste en la mise en place d’une entité fictive dans le

système de l’organisation auditée et à traiter des données d’essai
pour cette entité

Cette méthode permet de vérifier l’exactitude du traitement par le

programme d’application dans un environnement d’exploitation

Exemple: Dans le cas de l’audit des comptes fournisseurs, l’auditeur

crée un fournisseur fictif dans la base de données des fournisseurs
et entre des commandes pour ce fournisseur. Il cherchera alors des
résultats et des preuves des contrôles pertinents.

133
 La méthode des outils de piratage

Consiste à tester la sécurité de l’accès aux systèmes de l’entité auditée

Exemple de techniques utilisées

• Les scanneurs de réseau: Exemple, Netscan Tools, Internet Security

Scanneur, Sam Spade et Internet Maniac, permettent d’avoir des
informations sur un réseau (les types de programmes utilisés, les
serveurs et les postes de travail et les dispositifs de surveillance),

• Les scanneurs de port: Exemple, Port Scanneur, Port Scan2, Yet Another
Port Scanneur et Fast Scan. Ces programmes permettent de localiser les
ports d’entrée dans un ordinateur par lesquels on peut accéder au
système sans autorisation,

134
• Les perceurs de mots de passe: Exemple, John the Ripper, Killer Cracker
et Lophtcrack. L’auditeur peut utiliser ces outils pour percer le cryptage
des mots de passe utilisateur ou compte. L’objectif de l’auditeur est de
tester la fiabilité des mots de passe et du respect de la politique de
gestion de ces derniers.

135
2. Les TAAO axées sur les données

Programmes qui servent à choisir, récupérer, récapituler et traiter les

données à l’aide du système informatique de l’organisation cliente

Le but étant de s’assurer des deux objectifs suivants : l’intégralité et

l'exactitude des données

L’auditeur doit s’assurer, aux fins de l’utilisation des TAAO axées sur
les données, de l’intégrité (absence de manipulation par le client) du
fichier d’essai utilisé

Les TAAO axées sur les données sont utilisées aux fins des tests de
substance. Ces techniques impliquent le recours à des programmes
permettant de consulter et de récupérer les données des fichiers du
client pour effectuer des sondages substantifs.

136
 Plusieurs types de programmes informatiques ont été mis en place
pour effectuer des TAAO axées sur les données

Des exemples :

 Les progiciels d’audit

 Les programmes généraux

 Les programmes faits sur mesure.

137
 Les progiciels d’audit

Les plus connus sont les « logiciels d’audit généralisés » (LAG)

Il est difficile de concevoir un logiciel d’audit pour chaque type

d’environnement informatique. Or, les LAG peuvent tourner sur
plusieurs types d’environnements.

138
 Principales fonctions présentes dans la plupart des LAG :

 Accès aux fichiers: Lire des fichiers (plusieurs en même temps)

 Réorganisation des fichiers: Trier les données dans des ordres

différents et fusionner en un seul fichier les données provenant de
plusieurs fichiers

 Sélection: Extraire des données répondant à certains critères

 Statistiques: Sondage d'attributs ou de variables.

139
• Arithmétique: Gamme complète des opérations arithmétiques
permettant le calcul dans les zones de travail, le contrôle de
l’exactitude arithmétique, la production des totaux de contrôle, etc.

• Stratification et analyse des fréquences: On peut avec certains LAG

obtenir des tableaux de fréquences et des graphiques à barres
(histogrammes).

• Rapports: Le logiciel peut créer des rapports contenant de

l’information utile à l’auditeur. Ce dernier peut choisir différentes
mises en page.

140
 L’auditeur dispose de plusieurs programmes informatiques pour la
réalisation de ce type de TAAO, dont notamment, les progiciels d’audit,
dont les plus connus sont les Logiciels d’Audit Généralisé,
tels que:

 ACL (Audit Software Language)

 IDEA (Interactive Data Extraction and Analysis)

D’autres solutions commerciales sont disponibles sur le marché pour

supporter l’audit assisté par ordinateurs, telles que :

141
 RVR (www.rvrsystems.com);
 ENABLON (www.enablon.com)
 Oracle, module internals, Control Manager Discoverer
(www.oracle.com);
 SAP, module Process Control (www.sap.com);
 SAS (www.sas.com);
 Crystal, Seagate Software (www.businessobjects.com);
 Teammate (www.pwcqlobal.com).

Fin du cours

142