 

0
GROUPE DE TRAVAIL

Supervision : Pr ATSA ETOUNDI Roger

Coordonnateur : Mme MEKUATE TAYOU Christelle épse TACHOULA

Chef d’équipe : NDEKOU Franklin

Rapporteur ZEH BEKONO Albert

Membres :
AURORE EFFA
BITA Alex
CHIJOU NENGOU Dubois Roger
DJOUMESSI Honoré
KEGNE Yolande
NOLABIA KIASSAMBA Aurelien William
KOM Frankie
MBENG ETO Thierry
ZOGO ABEGA Ambroise Eric
Avec la participation des étudiants de Master I et II en Système d’Information et
Génie logiciel du département informatique de l’Université de Yaoundé I année 2015.

1
SOMMAIRE
INTRODUCTION ................................................................................................................................. 8
1. A qui est destiné ce guide ? ....................................................................................................... 8
2. Objectifs du Guide..................................................................................................................... 8
3. Enjeux et limites ........................................................................................................................ 8
4. Strcuture du guide ..................................................................................................................... 9
I. Partie1 : GENERALITES SUR L’AUDIT DES SYSTEMES D’INFORMATION .............. 10
I.1. DEFINITION DES CONCEPTS ....................................................................................... 11
I.2. PREPARATION D’UNE MISSION D’AUDIT ................................................................ 12
I.2.4. Exigences relatives au prestataire d’audit................................................................. 12
I.2.4. Exigences générales ..................................................................................................... 12
I.2.4. Charte d’éthique .......................................................................................................... 13
I.2.4. Gestion des ressources et des compétences................................................................ 13
I.2.5. Protection de l’information du prestataire d’audit .................................................. 15
I.2.6. Exigences relatives aux auditeurs .............................................................................. 15
I.3. DEROULEMENT D’UNE MISSION D’AUDIT ............................................................. 18
I.3.2. Qu’est que c’est qu’un audit ? .................................................................................... 18
I.3.2. A quoi sert l'audit ? ..................................................................................................... 18
I.3.3. Les principes de l’audit ............................................................................................... 19
I.3.4. Pourquoi auditer.......................................................................................................... 19
I.3.5. Le processus d'audit selon le référentiel CISA ......................................................... 20
I.3.5.3. Evaluer les risques liés à l'audit ............................................................................. 24
I.3.5.4. Déterminer si l'audit est possible ........................................................................... 24
I.3.5.5. Préparation détaillée à l'audit ................................................................................ 25
I.3.5.6. Collecter les preuves de l'audit ............................................................................... 28
I.3.5.7. Tester la preuve collectée ........................................................................................ 30
I.3.5.8. Analyser les résultats ............................................................................................... 30
I.3.5.9. Rapport des conclusions de l'audit......................................................................... 30
I.4. Clôture .................................................................................................................................. 31
II. Partie 2 : AUDIT DES DOMAINES SPECIFIQUES .......................................................... 32
II.1. AUDIT DES PROCESSUS ................................................................................................. 33
II.1.1. Qu’est-ce que l’audit des processus ? ........................................................................ 33
II.1.2. L’audit des processus : Pourquoi ? ............................................................................ 33
II.1.3. L’audit des processus : A quel moment vaut-il mieux le faire ? ............................. 35
II.1.4. Préparation de la mission d’audit et Recommandations générales pour sa mise en
œuvre 36

1
 II.1.5. Audit interne ou externe de processus : quelle démarche adopter ? ..................... 37
II.1.5.1. Etape 1 : Cartographier les processus ..................................................................... 38
II.1.5.2. Etape 2 : Choisir les processus critiques ................................................................. 39
II.1.5.3. Etape 3 : Caractériser chaque processus................................................................. 39
II.1.5.4. Etape 4 : Décrire Chaque processus ........................................................................ 42
II.1.5.5. Etape 5 : Diagnostiquer chaque processus et son contexte pour définir les
objectifs d’optimisation ........................................................................................................... 43
II.1.5.6. Etape 6 : Choisir le degré d’optimisation : améliorer ou reconcevoir selon les
objectifs et indicateurs de performance (recommandations de l’auditeur externe) .......... 44
II.1.5.7. Etape 7 : Optimiser chaque processus (recommandations de l’auditeur externe) ... 44
II.1.5.8. Etape 8 : Mettre en œuvre et piloter le processus (recommandations de l’auditeur
externe) ...................................................................................................................................... 45
II.1.6. Techniques, outils, référentiels ou normes à utiliser pour un audit de processus . 45
II.2. AUDIT DE LA SECURITE PHYSIQUE .......................................................................... 52
II.2.1. Définition et objectifs ....................................................................................................... 52
II.2.2. Pourquoi un audit de sécurité physique ? ...................................................................... 52
II.2.3. Durée d’un audit de sécurité physique ........................................................................... 53
II.2.4. Démarche .......................................................................................................................... 53
II.2.4.1. Etape 1 : Evaluer les risques environnementaux (voisinage) et naturels ............. 54
II.2.4.2. Etape 2 : Evaluer le système de Contrôle d’accès et d’intrusion .......................... 54
II.2.4.3. Etape 3 : Apprécier le système de sécurité incendie ............................................... 58
II.2.4.4. Etape 4 : Apprécier les dégâts des eaux................................................................... 59
II.2.4.5. Etape 5 : Analyser le système Gestion de la sécurité physique ............................. 59
II.2.4.6. Conclusion de l’auditeur sur la gestion de la sécurité ............................................ 59
II.2.5. Techniques, outils, référentiels ou normes à utiliser pour un audit de processus . 59
II.3. AUDIT DU RESEAU .............................................................................................................. 62
II.3.1. Définition ........................................................................................................................... 62
II.3.2. Objectifs ....................................................................................................................... 62
II.3.3. Exécution de l’audit ..................................................................................................... 63
II.3.3.1 Etape 1 : Phase d’approche ....................................................................................... 63
II.3.3.2. Etape 2 : Phase d’analyse de vulnérabilité .............................................................. 64
II.3.3.3. Etape 3 : Phase de tests intrusifs .............................................................................. 64
II.3.4. Techniques, outils, référentiels ou normes à utiliser pour l’audit réseau
informatique................................................................................................................................. 65
II.4. AUDIT DES DONNEES ..................................................................................................... 66
II.4.1. Définition de l’audit des données .................................................................................... 66
II.4.2. Qu’est-ce qu’une donnée ?............................................................................................... 66

2
 II.4.3. Pourquoi l’audit des données ? ....................................................................................... 67
II.4.4. Démarche d’une mission d’audit des données. .............................................................. 70
II.4.4.1. Etape 1 : Vérifier si la criticité et la sensibilité des données sont régulièrement
évaluées ..................................................................................................................................... 71
II.4.4.2. Etape 2 : Vérifier si l’organisation a mis en place les dispositifs de protection de
l’accès aux données, en fonction des besoins ......................................................................... 74
II.4.4.3. Etape 3 : Vérifier si l’organisation a mis en place les dispositifs de protection de
la confidentialité des données, en fonction des besoins ........................................................ 78
II.4.4.4. Etape 4: Vérifier si l’organisation a mis en place les dispositifs de protection de
la confidentialité des données, en fonction des besoins ........................................................ 82
II.4.4.5. Etape 5: Vérifier si l’organisation a mis en place les dispositifs pour respecter la
réglementation en matière de données personnelles ............................................................ 84
II.4.5. Techniques, outils, référentiels ou normes à utiliser pour un audit des processus..... 86
II.5. Audit des Logiciel ................................................................................................................ 89
II.5.1. Définition application ....................................................................................................... 89
II.5.2. Pourquoi l’audit des applications ................................................................................... 89
II.5.3. Quand fait-on l’audit des applications ? ........................................................................ 90
II.5.4. Démarche d’évaluation de logiciels................................................................................. 90
II.5.4.1. Etape 1: Analyse de l’historique et de l’insertion de l’application dans
l’architecture globale .............................................................................................................. 91
II.5.4.2. Etape 2: Analyse de la couverture fonctionnelle..................................................... 91
II.5.4.3. Etape 3 : Analyse du schéma des traitements et élaboration d’une matrice de
contrôle ..................................................................................................................................... 92
II.5.4.4. Etape 4 : Identification des risques .......................................................................... 93
II.5.4.5. Etape 5 : approfondissement des risques identifiés ................................................ 94
II.5.4.6. Etape 6 : Analyse des aspects « qualitatifs » ........................................................... 94
II.5.5. Techniques, outils, référentiels ou normes à utiliser pour un audit des applications
..................................................................................................................................................... 103
II.6. Audit de la sécurité du Système d’information............................................................... 107
II.6.1. Définition de l’audit de la SSI................................................................................... 107
II.6.2. Pourquoi l’audit de la sécurité des systèmes d’information ? ............................... 108
II.6.3. Quand faut-il faire un audit de la sécurité des systèmes d’information ? ............ 108
II.6.4. Démarche de l’audit de la SSI .................................................................................. 111
II.6.4.1. Etape 1 : Définition de la Charte d’audit .............................................................. 112
II.6.4.2. Etape 2 : Préparation de l’audit ............................................................................. 112
II.6.4.3. Etape 3 : Audit organisationnel et physique ......................................................... 113
II.6.4.4. Etape 4 : Audit technique ...................................................................................... 114
II.6.4.5. Etape 5 : Tests d’intrusion...................................................................................... 116

3
 II.6.4.6. Etape 6 : Rapport d’audit ...................................................................................... 116
II.6.4. Méthodes, Normes, Outils et Référentiels d’audit de la SSI .................................. 117
a) Les Méthodes ......................................................................................................................... 117
b) Historique des Normes en matière de Sécurité de l’Information ...................................... 118
a) La suite des Normes ISO 2700X ........................................................................................... 119
II.7. AUDIT DES COUTS INFORMATIQUES ..................................................................... 121
II.7.1. Qu’est-ce que l’audit des coûts informatiques? ........................................................... 121
II.7.2 L’audit des coûts informatiques : Pourquoi ? .............................................................. 121
II.7.3. L’audit des coûts informatiques : A quel moment vaut-il mieux le faire ? .......... 122
II.7.4. Préparation de la mission d’audit ............................................................................ 122
II.7.5. Démarche d’audit interne ou externe des coûts informatiques ............................. 123
II.7.5.1. Etape 1 : Evaluer le catalogue de service de la DSI.............................................. 124
II.7.5.2. Etape 2 : Evaluer la mise en cohérence du modèle d’activités ............................ 125
II.7.5.3. Etape 3 : Evaluer la ventilation du budget en rubrique ...................................... 125
II.7.5.4. Etape 4 : Evaluer le mécanisme d’affectation des ressources aux activités ....... 126
II.7.5.5. Etape 5 : Evaluer le mécanisme de ventilation des activités sur les services..... 126
II.7.5.6. Etape 6 : Evaluer les critères d’analyse et de comparaison ................................. 126
II.7.6. Techniques, outils, référentiels ou normes à utiliser pour un audit de coûts
informatique............................................................................................................................... 127
III. RECEUIL DES REFERENTIELS, NORMES ET METHODES .................................... 130
CONCLUSION .................................................................................................................................. 133
GLOSSAIRE...................................................................................................................................... 134
ANNEXES .......................................................................................................................................... 136
Lois sur la cybercriminalité au Cameroun ................................................................................. 137

4
LISTE DES TABLEAUX
Tableau 1 : Exemple de caractérisation d’un processus

Tableau 2 : référentiels, normes et outils à utiliser pour l’audit de la sécurité physique

Tableau 3 : référentiels, normes et outils à utiliser pour l’audit logiciel

Tableau 4 : Historique des normes en matière de sécurité de l’information

Tableau 5 : Domaines d’audit du SI et référentiels utilisés

5
LISTE DES FIGURES
Figure 1 : Composante du S.I. prises en compte dans le GMASI

Figure 2 : démarche d’audit selon CISA

Figure 3 : Exemple de compétences requises pour l'équipe d'audit
Figure 4 : Exemple de répartition des rôles au sein de l'équipe d'auditeurs.
Figure 5 : cycle d’une preuve durant l’audit
Figure 6 : Zoom sur l’audit des processus
Figure 7 : Étapes d’audit des processus
Figure 8 : Diagramme « Qui fait quoi » d’un processus

Figure 9 : Exemple de processus modélisé avec BPMN

Figure 10 : Zoom sur l’audit de la sécurité physique

Figure 11 : illustration de la démarche Audit de la sécurité physique

Figure 12 : Zoom sur l’audit du réseau

Figure 13 : Illustration de la démarche d’audit de réseau

Figure 14 : Zoom sur l’audit des données

Figure 15 : Serveur de données

Figure 16 : Représentation de la triade D, I, et C.

Figure 17 : Illustration du processus d’audit des données

Figure 18 : Zoom sur l’audit des applications

Figure 19 : Arborescence de INFAUDITOR

Figure 20 : Le système Square

Figure 21 : Qualité d’un logiciel

Figure 22 : Zoom sur l’audit de a sécurité

Figure 23 : éléments utilisés dans la sécurité

Figure 24 : outils utilisés

6
Figure 25 : quels outils utilisés-vous pour sensibiliser les employés

Figure 26 : schéma du processus d’audit de la sécurité des SI

Figure 27 : Cartographie des principales méthodes SSI dans le monde.

Figure 28 : Zoom sur les coûts informatiques

Figure 29 : démarche d’élaboration des coûts informatiques du Cigref

7
INTRODUCTION

1. A qui est destiné ce guide ?

Ce document fait une synthèse des « best practices», de l’application des référentiels
et Normes dans l’audit des différents domaines des systèmes d’information. De ce fait
il est destiné à :

- Les entreprises et organisation spécialisées ou ayant la vocation d’auditer les S.I.

- Les directeurs des Systèmes d’information pour la préparation de L’élaboration
des politiques interne et des audits internes,
Les auditeurs des S.I., leur donne une démarche pour mener à bien les audits.

2. Objectifs du Guide
Les objectifs de cet ouvrage sont de sensibiliser les cabinets d’audit et les autres
acteurs aux spécificités de l’audit des S.I. et d’offrir une approche pratique et spécifique
des rôles et responsabilités de l’auditeur. Ce document définit l’audit par domaine de
S.I., dit quand faire un audit, pourquoi faire un audit et donne une démarche pour l’audit
en précisant les normes, référentiel ou méthode à utiliser.

3. Enjeux et limites
- Enjeux
Ce guide a été rédigé pour aider les auditeurs et les prestataires d’audits dans la
démarche d’audit. Les investissements faits au Cameroun dans le domaine des S.I. est
sans cesse croissant d’où la nécessité de contrôler ce secteur.

- Limites
Ce guide méthodologique restrint l’audit du S.I. à :

L’audit physique
L’audit du réseau
L’audit du logiciel
L’audit des processus
L’audit des données

8
 L’audit de la sécurité qui est un domaine transversal, car on peut
auditer la sécurité liée au dommaines cité plus haut (sécurité du
matériel, sécurité des logiciel, des données et même des processus)
L’audit des coûts qui est aussi englobant que transversale car même
la sécurité à un coup.

De ce qui précède l’audit du S.I. telque developpé dans cet ouvrage peut être
representer comme suit.

Coût

Sécurité

Processus

Données
Physique

Logiciel
Réseau

Figure 1 : Composante du S.I. prises en compte dans le GMASI

4. Strcuture du guide
Ce guide méthodologique est constitué essentiellement de deux parties :

- Partie 1 : généralité sur l’audit des S.I., dans cette partie une synthèse est fait
des bonnes pratiques de l’audit des différents domaines du S.I.
- Partie 2 : audit des différent domaines du S.I., cet ouvrage offre de façon plus
spécifique las techniques, les normes, les référentiels ou méthode à utiliser pour
auditer le domaine.

9
 I. Partie1 : GENERALITES SUR L’AUDIT DES SYSTEMES
D’INFORMATION

Partie1 :
GENERALITES SUR L’AUDIT DES
SYSTEMES D’INFORMATION

10
 I.1. DEFINITION DES CONCEPTS

Système d’information (S.I.) : est un ensemble organisé de ressources (matériel,

logiciel, personnels, données et procédures) permettant de traiter de diffuser de
l’information (cf. norme ISO 19011).

Audit : est un examen méthodique d’une situation relative à un produit, un processus,

une organisation réalisée en coopération avec les intéressés en vue de vérifier la
conformité de cette situation aux dispositions préétablies et l’adéquation de ces dernières
à l’objectif recherché (Cf. Norme AFNOR Z61-102)

Audit interne : est un audit qui fait au sein d’une organisation par le personnel de ladite
organisation

Audit externe : est un audit qui est fait par un consultant externe à l’organisation
auditée.

Domaine d’audit de S.I. : c’est un composant du S.I., dans cet ouvrage une considérons
six domaines (le matériel, les données, les logiciels, les processus, la sécurité et le coût)

Méthode : est une manière de mener selon une démarche raisonnée, une action, un
travail ou une activité (Cf. Larousse)

Normes : est un document qui définit les exigences, les spécifications, les lignes
directrices ou des caractéristiques à utiliser systématique pour assurer l’aptitude à
l’emploi des matériaux, produits, processus et services (Cf. ISO)

Référentiel : c’est une collection de bonnes pratiques sur un sujet donné (le CIGREF)

Prestataire d’audit : c’est un organisme réalisant des services d’audit du système

d’information (Cf .ISO 19011)

11
 I.2. PREPARATION D’UNE MISSION D’AUDIT

Pour mener à bien une mission d’audit, un certain nombre d’exigence doit être
pris en compte

I.2.4. Exigences relatives au prestataire d’audit

Ces exigences sont extraites de l’ouvrage « Prestataire d’audit de la sécurité de
système d’information, référentiel des exigences », Version 1.0 du 31 octobre 2011
proposé par L’ANSI (Agence Nationale de la Sécurité du Système d’Information)

I.2.4. Exigences générales

Les exigences listées dans cette partie portent sur les domaines suivants :
juridique, structurel, responsabilité et impartialité du prestataire d’audit. Comme
exigences, nous pouvons citer :
a) Le prestataire d’audit doit être une entité ou une partie d’une entité dotée de la
personnalité morale de façon à pouvoir être tenu juridiquement responsable de
toutes ses activités d’audit. Une autorité administrative qui réalise des activités
d’audit peut être considérée comme un prestataire d’audit.
b) Le prestataire d’audit réalise ses audits dans le cadre d’une convention d’audit
préalablement approuvée par le commanditaire de l’audit. La loi applicable à la
convention d’audit est la loi française.
c) Le prestataire d’audit assume la responsabilité de l’audit qu’il réalise pour le
compte du commanditaire de l’audit, en particulier des dommages
éventuellement causés au cours de l’audit. Le prestataire et le commanditaire de
l’audit peuvent préciser les modalités de partage des responsabilités au sein de la
convention d’audit. Le prestataire peut s’exonérer de tout ou partie de sa
responsabilité s’il est avéré que le dommage éventuellement subi par le
commanditaire de l’audit résulte d’un défaut d’information de ce dernier.

Il est recommandé que le prestataire d’audit garde, notamment, la responsabilité

des actions qu’il effectue lors de l’audit de son propre fait ainsi que de celles pour
lesquelles le commanditaire de l’audit ne dispose pas de compétence particulière.
12
 I.2.4. Charte d’éthique

a) Le prestataire d’audit doit disposer d’une charte d’éthique prévoyant notamment

que :
- les prestations d’audit sont réalisées avec loyauté, discrétion, impartialité
et indépendance;
- Les auditeurs ne recourent qu’aux méthodes, outils et techniques validés
par le prestataire d’audit;
- les auditeurs s’engagent à ne pas divulguer d’informations obtenues ou
générées dans le cadre des audits sauf autorisation du commanditaire de
l’audit;
- les auditeurs signalent au commanditaire de l’audit tout contenu
manifestement illicite découvert durant l’audit;
- les auditeurs s’engagent à respecter la loi, la réglementation en vigueur
ainsi que les bonnes pratiques liées à l’audit.
b) L’ensemble des auditeurs évalués au titre de la qualification du prestataire d’audit
doivent signer la charte d’éthique prévue au paragraphe précédent préalablement
à la réalisation d’un quelconque audit.

I.2.4. Gestion des ressources et des compétences

a) Le prestataire d’audit doit employer un nombre suffisant d’auditeurs, de

responsables d’équipe d’audit et éventuellement de sous-traitants pour assurer
totalement et dans tous leurs aspects les audits pour lesquels il a établi des
conventions d’audit avec des commanditaires d’audits.
b) Le prestataire d’audit doit s’assurer, pour chaque audit, que les auditeurs désignés
pour réaliser l’audit ont les qualités et les compétences requises. Des auditeurs
débutants du prestataire d’audit peuvent, au titre de leur formation et de leur
montée en compétence, être incorporés à l’équipe d’audit. Ils doivent cependant
respecter la charte d’éthique du prestataire ainsi que l’ensemble des obligations
contractuelles, réglementaires ou légales imposées aux auditeurs.

13
c) Le prestataire d’audit doit s’assurer du maintien à jour des compétences des
auditeurs. Pour cela, il doit disposer d’un processus de formation et assurer une
veille technologique
d) En matière de recrutement, le prestataire d’audit doit procéder à une vérification
des formations, qualifications et références professionnelles des auditeurs
candidats et de la véracité de leur Curriculum Vitae. Le prestataire d’audit peut
également demander au candidat une copie du bulletin n° 3 de son casier
judiciaire.
e) Un processus disciplinaire doit être élaboré par le prestataire d’audit à l’intention
des salariés ayant enfreint les règles de sécurité ou la charte d’éthique.
f) Le prestataire d’audit est responsable des méthodes, outils (logiciels ou matériels)
et techniques utilisés par ses auditeurs et de leur bonne utilisation (précautions
d’usage, maîtrise de la configuration). Pour cela, il doit mettre en œuvre un
processus de formation des auditeurs à ses outils et assurer une veille
technologique sur leur mise à jour et leur pertinence.
g) Le prestataire d’audit justifie, au travers des auditeurs évalués au titre de la
qualification du prestataire d’audit, qu’il dispose des compétences techniques,
théoriques et pratiques, couvrant les domaines suivants :
- systèmes d’exploitation ;
- couche applicative ;
- équipements et logiciels de sécurité ;
- développement d’outils utilisés adaptés à la cible auditée dans le cadre des
audits ou des tests d’intrusion ;
- techniques d’ingénierie inverse ;
- exigences techniques requises par le Référentiel Général de Sécurité.
h) Le prestataire d’audit justifie, au travers des auditeurs évalués au titre de la
qualification du prestataire d’audit, qu’il dispose des compétences
organisationnelles, théoriques et pratiques, couvrant les domaines suivants :
- maîtrise des normes relatives à la sécurité des systèmes d’information ;
- maîtrise des domaines relatifs à l’organisation de la sécurité des systèmes
d’information ;

14
 - maîtrise des pratiques liées à l’audit.

I.2.5. Protection de l’information du prestataire d’audit

Les informations sensibles relatives aux audits, et notamment les preuves, les
constats et les rapports d’audit, doivent être protégés au minimum au niveau Diffusion
Restreinte. Le système d’information que le prestataire d’audit utilise pour le traitement
de ces informations doit respecter les règles de l’instruction interministérielle relative
aux mesures de protection des systèmes d'information traitant d'informations sensibles
non classifiées de défense de niveau diffusion Restreinte et établie par l’ANSSI.

I.2.6. Exigences relatives aux auditeurs

I.2.6.1. Aptitudes générales

a) L’auditeur doit disposer des qualités personnelles décrites au chapitre 7.2 de la
norme ISO19011, lesquelles sont :
- intègres, c’est-à-dire justes, attachés à la vérité, sincères, honnêtes et discrets;
- ouverts d’esprit, c’est-à-dire soucieux de prendre en considération des idées
ou des points de vue différents;
- diplomates, c’est-à-dire faisant preuve de tact et d’habileté dans les relations
avec les autres;
- observateurs, c’est-à-dire activement attentifs à l’environnement physique et
aux activités associées;
- perspicaces, c’est-à-dire appréhendant instinctivement et capables de
comprendre les situations;
- polyvalents, c’est-à-dire ayant de la facilité à s’adapter à différentes
situations;
- tenaces, c’est-à-dire persévérants, concentrés sur l’atteinte des objectifs;
- capables de décision, c’est-à-dire capables de tirer en temps voulu des
conclusions fondées sur un raisonnement et une analyse logiques;
- autonomes, c’est-à-dire sachant agir et travailler de son propre chef tout en
établissant des relations efficaces avec les autres;

15
 - agissant avec courage, c’est-à-dire capables d’agir de manière responsable et
déontologique même si les actions entreprises peuvent ne pas toujours être
appréciées et parfois donner lieu à un désaccord ou une confrontation;
- ouverts aux améliorations, c’est-à-dire sachant tirer des enseignements des
situations, s’efforçant d’obtenir les meilleurs résultats d’audit;
- ouverts aux différences culturelles, c’est-à-dire sachant observer et respecter
les traditions culturelles de l’audité;
- acteurs en équipe, c’est-à-dire sachant travailler en parfaite collaboration avec
des tiers, y compris les membres de l’équipe d’audit et le personnel de
l’audité.
b) L’auditeur doit maîtriser la réglementation applicable aux activités d’audits qu’il
met en œuvre (maîtrise de la réglementation spécifique aux types d’audits, à la
nature ou au secteur d’activité du commanditaire et de l’audité, etc.).
c) L’auditeur doit disposer de qualités rédactionnelles et de synthèse et savoir
s’exprimer à l’oral de façon claire et compréhensible, en langue française.
d) L’auditeur met régulièrement à jour ses compétences par une veille active sur
celles-ci, sur la méthodologie, les techniques ou les outils utilisés lors des
activités d’audit.
Il est recommandé que l’auditeur participe à l’évolution de l’état de l’art par une
participation à des évènements professionnels de son domaine de compétence, à des
travaux de recherche ou la publication d’articles.

I.2.6.2. Expérience

L’auditeur doit avoir reçu une formation en technologie des systèmes

d’information et de communication et en audit. Il est recommandé que l’auditeur :
a) justifie d’au moins deux années d’expérience dans le domaine des systèmes
d’information et de communication ;
b) justifie d’au moins une année d’expérience dans le domaine de la sécurité des
systèmes d’information ;
c) justifie d’au moins une année d’expérience dans le domaine de l’audit de
systèmes d’information.

16
Ces recommandations ne sont pas cumulatives.

I.2.6.3. Aptitudes et connaissances spécifiques aux activités

d’audit

a) L’auditeur doit maîtriser les bonnes pratiques et la méthodologie d’audit

décrite dans la norme ISO 19011 et être en mesure de réaliser des audits
conformément aux exigences relatives au déroulement d’une prestation
d’audit
b) L’auditeur doit être compétent dans au moins une des activités d’audit
pour lesquelles le prestataire d’audit demande la qualification. Pour cela,
l’auditeur doit disposer de connaissances techniques ou organisationnelles
approfondies dans au moins un des domaines cités ci-dessous. Il est
recommandé que l’auditeur soit sensibilisé à l’ensemble des autres
activités d’audit pour lesquelles le prestataire d’audit demande la
qualification.
c) Le responsable d’audit doit disposer des compétences de gestion d’équipe
nécessaire à la constitution adéquate de l’équipe d’audit par rapport aux
objectifs visés dans la convention d’audit.

I.2.6.4. Engagements

a) L’auditeur doit avoir un contrat avec le prestataire d’audit.

b) L’auditeur doit avoir signé la charte d’éthique élaborée par le prestataire
d’audit.
c) L’auditeur s’engage à subir une évaluation personnelle de ses
compétences au titre de la procédure de qualification du prestataire d’audit
dont il dépend.
d) Il est recommandé que le commanditaire de l’audit ait la capacité à
révoquer un auditeur qui ne disposerait pas des compétences attendues.

17
 I.3. DEROULEMENT D’UNE MISSION D’AUDIT

I.3.2. Qu’est que c’est qu’un audit ?

Un audit est défini comme une étude systématique des enregistrements présents,
impliquant des résultats d'analyse, des recherches de preuves et des confirmations
d'hypothèses. Le résultat d'un audit est un rapport contribuant fortement à l'assurance
d'une vérité. Les audits réalisés par un auditeur externe indépendant fournissent une
assurance plus élevée car le degré d'assurance est proportionnel à l'indépendance de
l'auditeur. Il existe 3 types d'audit :
- l'audit interne,
- l'audit externe (réalisé par un prestataire d’audit),
- l'audit indépendant (réalisé par une entreprise d'audit indépendante), le seul
type d’audit ayant une valeur pour une éventuelle certification.

I.3.2. A quoi sert l'audit ?

L’audit est un outil d’amélioration. L'audit est un instrument qui va conduire le

consultant auditeur à émettre un diagnostic servant de base à la recherche
d'améliorations et à la mise en œuvre de recommandations.

L’audit permet entre autre de :

- Déterminer la conformité où la non-conformité du système d’information aux

exigences prescrites (normes, référentiels, benchmarks) ;
- Déterminer l’efficacité du système d’information à satisfaire les objectifs
prescrits ;
- Donner à l’entreprise auditée la possibilité d’améliorer son système
d’information ;
- Vérifiez si les systèmes sont capables de maintenir l'intégrité, la disponibilité
des données du système, et contribuer à l'atteinte des objectifs d'affaires de
l'entreprise

18
 - Prévenir ou détecter des événements indésirables en assurant que les contrôles
internes en place sont appropriés
- Identifier les écarts entre ce qui doit être fait selon les standards et ce qui est
effectivement fait
- Vérifiez et valider la performance des outils automatisés dans une
organisation
- Satisfaire aux exigences réglementaires ;
- Permettre l’amélioration du système d’information de la société auditée ;

I.3.3. Les principes de l’audit

Les principes d’un audit sont les suivants :

- Déontologie : confiance, intégrité, discrétion
- Impartialité : les divers documents produits par l’auditeur doivent refléter de
lanière honnête et précise les activités auditées.
- Conscience professionnelle : les auditeurs doivent avoir les compétences et
l’expérience requise ;
- Indépendance : les auditeurs sont totalement indépendant de la société
auditée et doivent agir en toute objectivité ;
- Preuve : des preuves d’audit doivent être vérifiables ;

I.3.4. Pourquoi auditer

L'audit des systèmes d'information est donc un processus qui vise à vérifier si les
fonctions, les équipements (matériels et logiciels) les processus et les opérations sont
exécutés selon les normes, les lignes directrices et les meilleures pratiques définies. En
général, les activités de vérification peuvent être effectuées soit par des professionnels
externes ou internes selon les besoins et objectifs

19
 I.3.5. Le processus d'audit selon le référentiel CISA

Il comprend 10 étapes.

Validation de la
charte d’audit

Préparation de
l’audit

Evaluation Information sur les

des risques risques liés à l’audit

L’audit
est-il
faisable ?

Exécution du y-a-t-il des

travail d’audit irrégularités ?

Analyse
des
résultats
Prise en compte des
irrégularités et des
actes illégaux dans
les rapports

Rédaction des
rapports

Suivi des
Activités Recherche
de avis
légaux

Figure 2 : démarche d’audit selon CISA

20
 I.3.5.1. Validation de la charte de l'audit

Chaque organisation doit posséder un comité d'audit. Il est composé de directeurs

de l'entreprise, dont généralement le CEO et le CFO, ainsi que l'équipe d'auditeurs
internes.
Les directeurs de l'entreprise, même s’ils ne sont pas experts dans la régulation,
l'assurance et les contrôles, n'en restent pas moins responsables vis à vis de la loi et des
différentes autorités. Ils délèguent au comité d'audit l'autorité de vérifier et contester les
choix faits en matière d'assurance et de contrôles.
Le comité d'audit écrit la charte de l'audit qui donne autorité aux auditeurs pour
conduire les audits. Il précise notamment :

- le périmètre de l'audit et ses objectifs,

- l'autorité de réaliser l'audit et d'avoir accès aux ressources nécessaires,
- la définition des actions mutuelles attendues des auditeurs et le comité
d'audit.
Cette charte doit être validée par les plus hautes autorités de l'entreprise ainsi que
par les auditeurs.
Lors des audits externes (ou indépendants), le comité d'audit écrit une lettre
d'engagement. Elle reprend le contenu de la charte d'audit en y ajoutant :

- un engagement d'indépendance,
- des termes et conditions,
- des attentes (notamment en termes de planning).

I.3.5.2. Préparation de l'audit (vue générale)

La préparation de l'audit est une phase importante pour s'assurer que le travail
effectué va être aligné avec les attentes des donneurs d'ordre.

a) Le périmètre de l'audit
- pour les donneurs d'ordre (leur objectif, certification ?, accréditation ?),

21
 - les données et leurs utilisations,
- les applications et l'infrastructure,
- la localisation,
- les personnes.
b) Les restrictions du périmètre
- imposées par la direction,
- liées à des problèmes de ressources,
- liées aux compétences des auditeurs,
- liées à l'accès aux preuves.
c) Comprendre le type d'audit
- Sécurité
- Applications
- Processus
- Matériel
- Couts
- Etc.
d) Comprendre l'entreprise
- Les régulations spécifiques (à son domaine) auxquelles l'entreprise doit se
conformer.
- Le fonctionnement de l'entreprise et ses cycles.
- Ses objectifs stratégiques et l'intégration de son SI.
- Ses objectifs financiers.
- Ses objectifs opérationnels.

Durant la phase de préparation, les différentes parties prenantes de l'audit ont un

certain nombre de devoirs à accomplir.

 Les devoirs du client :

- Définir le périmètre de l'audit.

22
 - Définir les objectifs de l'audit.
- Donner autorité aux auditeurs pour réaliser l'audit.
- Déterminer les règles de confidentialité concernant l'audit.

 Les devoirs des audités :

- Collaborer avec les auditeurs.

- Identifier les facteurs de succès de leur mission et les mesures de
performance.
- Identifier les rôles et les responsabilités.
- Donner accès aux informations, applications ou personnels appropriés pour
réaliser l'audit.
- Fournir les preuves recherchées.
- Donner accès aux résultats d'audits précédents.

 Les devoirs des auditeurs :

- Planifier chaque audit à réaliser pour atteindre des objectifs spécifiques

nécessaires à l'obtention d'une conformité annuelle.
- Identifier la norme à utiliser pour l'audit.
- Utiliser une stratégie d'audit basée sur la gestion du risque.
- Identifier les demandes concernant la confidentialité et la sécurité de
l'entreprise et les traiter avec le niveau d'attention adéquat.
- Identifier les procédures spécifiques de l'audit et ces procédures doivent
être remises aux audités.
- Expliquer comment les procédures de l'audit vont répondre aux objectifs.
- Lister les preuves qui devront être revues durant l'audit.
- Ecrire un plan projet.
- Identifier les ressources nécessaires.
- Planifier les périodes d'audit.
- Estimer le coût de l'audit.

23
 - Identifier une date cible pour la production du rapport final

I.3.5.3. Evaluer les risques liés à l'audit

L'évaluation des risques est une phase importante de la préparation de l'audit. Elle va
notamment conditionner :

-les ressources nécessaires,

-le matériel à auditer (personnes, informations, procédures, applications),
-le planning des audits individuels,
-le temps nécessaire.
Ces choix doivent être faits afin de réduire les risques identifiés.
Les risques concernent :

- Les risques liés à l'audit du SI (capacité à évaluer correctement les affirmations

de la direction).
- Les risques pris par l'entreprise liés au domaine à auditer.
Un plan de gestion des risques doit être revu tous les ans par le comité d'audit.
Il doit comporter la liste des menaces, leur probabilité, leur criticité et les solutions
apportées par l'entreprise.

I.3.5.4. Déterminer si l'audit est possible

Après la phase de préparation à l'audit et d'évaluation des risques, l'auditeur doit être
capable de déterminer si l'audit demandé est réalisable.
Les conclusions de l'audit sont trop importantes pour l'entreprise pour n'être que
partielles. Il faut donc que l'auditeur se prononce sur la faisabilité de la mission qui lui
a été confiée.
Les questions qu'il doit notamment se poser sont :

24
 - Suis-je capable de produire des résultats d'audit significatifs?

- Est-ce que les objectifs de l'audit sont réalisables ?

- Est-ce que les membres de l'équipe d'audit ont les compétences nécessaires pour
réaliser cet audit?
- Avez-vous assez de temps pour faire un travail de qualité?
- Est-ce que les audités sont collaboratifs?

I.3.5.5. Préparation détaillée à l'audit

 Mise en place de l'équipe d'audit

L'auditeur principal ne peut être expert en tout, il doit s'attarder à construire une
équipe d'audit compétente à partir de personnes de sa propre organisation, de sous-
contractants, d'experts, etc. Un plan de développement des compétences de l'équipe doit
être revu périodiquement. Les compétences ne s'acquièrent pas lors de l'audit mais bien
en amont.

Figure 3 : Exemple de compétences requises pour l'équipe d'audit

 Mettre en plan des contrôles qualités de l'audit

25
 La qualité d'un audit n'est pas atteinte par hasard. Les normes, process et
procédures des audits ont été développés pour augmenter la qualité des audits ainsi que
leur répétabilité et leur consistance.
Lors de la mise en place du processus de contrôle qualité de l'audit, les points suivants
doivent être considérés :

- Utilisation d'une méthodologie d'audit avec un plan et des procédures

documentées.
- Comprendre le besoin et les attentes des audités.
- Identifier les tâches restant à accomplir.
- Respecter les cycles métier du client.
- Conserver les interviews des clients.
- Utiliser les enquêtes de satisfaction.
- S'accorder avec le client sur les termes utilisés.
- Mise en place d'indicateurs de performance de l'audit.
- Mesurer la performance de l'audit par rapport au plan initial.
- Répondre aux questions ou interrogations des auditeurs.

 Prendre contact et communiquer avec les audités

Il est important d'établir une relation de confiance entre les auditeurs et les audités. La
confiance s'acquiert grâce à la communication.
L'auditeur informe les audités de son plan de communication durant l'audit pour éviter
les surprises et rassurer les audités. La communication doit être adaptée à chaque partie
prenante pour être effective.

 Collecter les données

Il existe différentes techniques pour collecter les données :

- observation,

26
 - revue de document,
- interview,
- groupe de travail,
- sondage,
- CAAT (computer assisted audit tool).

 Revue des contrôles mis en place

Il existe trois types de contrôles :

- Préventif
- Correctif
- Inspection (recherche de problèmes)
Chacun possède les trois types d'implémentation :
- administratif (par document écrit)
- technique (implanté dans un outil)
- physique (visuel, mécanique)
Les contrôles forts sont ceux qui sont présents dans les différents types de contrôles
et d'implémentation.

Les principaux problèmes avec les contrôles :

- La direction est souvent exempte de contrôles.

- Les contrôles mis en place sont trop légers et ne peuvent garantir l'assurance
réclamée par la direction.

 Préparation du plan d'audit

Les résultats de l'audit doivent pouvoir être retrouvés par n'importe quel auditeur. C'est
pourquoi, les procédures et le plan d'audit doivent être documentés. Les notes de
l'auditeur ayant permis de trouver les preuves doivent aussi être consignées.

27
Pour chacune de ces trouvailles, l'auditeur doit faire référence à un point précis de la
norme. Cela permet de standardiser les procédures d'audit et les trouvailles gagnent en
crédibilité.
Comme lors d'enquêtes policières, l'auditeur doit pour chaque recherche de preuves se
poser les questions : qui, où, quand, comment, avec quoi et pourquoi.

Le responsable d'audit doit préparer le plan d'audit, y compris la planification et la

coordination des activités.
Le plan d'audit fini devrait être examiné et accepté par le client d'audit et présenté à
l'audité avant que les activités de collectes de données commencent.
Le plan d'audit comprend aussi la répartition des rôles au sein de l'équipe d'audit.
La préparation finale de l'audit comprend aussi la préparation des documents utilisés
pour la collecte de données (Template) ainsi que l'agenda détaillé de chaque journée.

Figure 4 : Exemple de répartition des rôles au sein de l'équipe d'auditeurs.

I.3.5.6. Collecter les preuves de l'audit

Les preuves de l'audit doivent être crédibles et factuelles. Elles doivent supporter les
conclusions des auditeurs. Chaque preuve doit confirmer ou infirmer une position.
Comme pour les enquêtes policières, il existe deux types de preuves :

- les preuves directes (confirment ou infirment directement une position),

28
 - les preuves indirectes (qui nécessitent d'être intégrées dans un raisonnement
pour confirmer ou infirmer la position).
Les preuves directes ont beaucoup plus de valeur.
Les données (ou preuves) de l'audit sont collectées au travers d'échantillonnages
statistiques ou non (subjectivité de l'auditeur basée sur l'analyse de risques). Les données
collectées vont avoir des valeurs différentes mais elles doivent toutes être revues et
enregistrées.
Les données sont hiérarchisées en fonction de leurs valeurs suivant les critères :

- Preuve matérielle confirmant l'existence d'une affirmation.

- Preuve objective dont l'existence fait peu de place à l'interprétation.
- Preuve fournie par une personne ou ressource d'une haute compétence.
- Preuve fournie par une personne indépendante de l'audit.
Les preuves ont aussi un temps de cycle (voir le diagramme ci-dessous).
Une preuve obtenue immédiatement ou plusieurs jours après n’a pas la même valeur.

Figure 5 : cycle d’une preuve durant l’audit

29
 I.3.5.7. Tester la preuve collectée

Il existe deux types de tests :

- Les tests de conformité qui vérifient la présence ou l'absence d'attributs ou

d'occurrences par rapport à une norme.

- Les tests substantifs qui vérifient le contenu et l'intégrité d'une donnée.

Le choix du type de tests dépend de la donnée et de l'échantillonnage de collecte
utilisé.

I.3.5.8. Analyser les résultats

En général, on accorde une marge de tolérance de 5% d'erreurs sur les résultats pour
confirmer qu'une hypothèse est fortement probable.
Chaque point de la norme auditée suivant une méthode d'échantillonnage et une méthode
de tests doit aboutir à une conclusion :

- Sur performance
- Conformité
- Opportunité pour s'améliorer
- Doutes (futurs problèmes en perspective)
- Non-conformité
Chaque résultat doit être enregistré.
Il se peut que certains points ne puissent aboutir à des conclusions faute de preuves
suffisantes ou contradictoires. L'auditeur doit alors poursuivre ses recherches.

I.3.5.9. Rapport des conclusions de l'audit

Une fois ces conclusions arrêtées, l'auditeur doit rédiger un rapport comprenant :

- le périmètre de l'audit,

30
 - les objectifs,
- les méthodes utilisées et les critères retenus,
- la nature des découvertes,
- les conclusions sur le travail effectué,
- des restrictions sur les conclusions.

Ce rapport doit être :

- facile à lire,
- signé, (cette signature atteste officiellement à l’entreprise de l’assurance
recherchée)
- revu avec la direction et les audités pour s'assurer que les conclusions ont bien
été comprises,
- validé,
- distribué,
- conservé.

I.4. Clôture
Après avoir remis son rapport, l'auditeur termine sa mission par une réunion de clôture
avec la direction.
Cette réunion a pour objectif :
- Que la mission assignée à l'auditeur est terminée
- Que la direction s'engage à réaliser les actions recommandées par l'auditeur

31
 II. Partie 2 : AUDIT DES DOMAINES SPECIFIQUES

Partie 2 :
AUDIT DES DOMAINES SPECIFIQUES

32
II.1. AUDIT DES PROCESSUS

Figure 6 : Zoom sur l’audit des processus

II.1.1. Qu’est-ce que l’audit des processus ?

C’est une méthode d’évaluation de la réalité de l’activité. C’est une méthode

d’investigation qui consiste à investiguer l’organisation d’un processus pour s’assurer
de sa maitrise et de sa capacité à atteindre les objectifs.

Elle est toujours accompagnée d’une vérification de son application sur le terrain.

 Sens descendant, de l’organisation du processus vers son application terrain,

 Sens ascendant, en partant du terrain pour remonter vers l’organisation du
processus.

II.1.2. L’audit des processus : Pourquoi ?

Une action sur les processus vise différents objectifs :

a) Détecter les écarts entre ce qui est prévu et ce qui est réalisé
- L'existence et la connaissance de la politique, des objectives qualités
- Comment se déroule l’activité auditée?

33
 - Quelles sont les étapes de contrôle (analyse du risque client)?
- Quels sont les documents utilisés: ce qu’a dit l’audité se reflète t il
- dans la procédure?
- Quels sont les enregistrements de la procédure?
- Permettent-ils de retrouver qui a fait l’opération, quand, avec quels
- matériels?
- Comment sont gérées les interfaces (entre les processus, fonctions,
services et client)?
b) Détecter ce qui n’est pas prévu
- Que se passe-t-il en cas de dérive (machine,
- procédé, etc.)?
- Que se passe-t-il en cas de non conformités
- (produit, système, etc.)?
- Que se passe-t-il en cas de nouvelle machine,
- matière première,
- Que se passe-t-il en cas d’absence, de congés
- ou de surcharge (gestion des compétences)?
c) Évaluer la pertinence et l’efficacité du système qualité?
- Quels sont les indicateurs de suivi du
- processus?
- Comment évoluent ils (y a-t-il des objectifs)?
- Quelle est planification des actions d'amélioration ?
- Et si on supprimait cette étape, ce document, ce
- contrôle ?
d) mieux prendre en compte les attentes des bénéficiaires pour améliorer les services
fournis ;
e) permettre aux différents acteurs de s'impliquer dans le fonctionnement du
processus,
f) clarifier les rôles et responsabilités des acteurs, définir les marges de manœuvre
et les cohérences nécessaires, simplifier les interfaces entre entités ;
g) transformer ou créer un nouveau processus pour répondre à de nouvelles attentes;

34
 h) diminuer les coûts, les délais d'un processus, augmenter sa performance au regard
d'indicateurs définis ;
i) mieux réagir aux aléas ;
j) viser une certification via la mise en place d'un système qualité ;
k) accompagner la mise en place d'un progiciel de gestion

II.1.3. L’audit des processus : A quel moment vaut-il mieux le

faire ?

Le travail sur les processus s'inscrit en général dans le cadre d'une démarche qualité.
Cette démarche doit par conséquent être lancée : affichage de la politique qualité et de
ses axes, communication aux personnels, engagement de la direction, plan d'action,
formation des acteurs clés…

Par ailleurs, l'optimisation des processus est une méthode qui accompagne
efficacement différents types de démarches :

a) Des démarches qualité comme, par exemple, l’élaboration d'engagements de

service, la certification selon les normes ISO, la réduction de
dysfonctionnements…
b) mais aussi d'autres démarches comme, par exemple, les réorganisations globales,
les fusions de service, la gestion des compétences, l’émergence de nouvelles
activités…
Concrètement, on peut déclencher un audit des processus :

c) Devant un évènement indésirable ou un évènement porteur de risque ;

d) Quand on constate des marges d’optimisation (benchmarking) ;
e) Lors d’une analyse de risques a priori (cartographie) ;
f) Lors d’une démarche de certification (V2014).
Démarche complexe qui peut appeler d’autres évaluations connexes.

35
 II.1.4. Préparation de la mission d’audit et Recommandations
générales pour sa mise en œuvre

a) Bien caractériser le périmètre couvert par le processus

L'essoufflement des démarches d’audit des processus s'explique bien souvent par
un mauvais cadrage du périmètre des différents processus. Ces zones de flous
provoquent vite des débats, des revendications des pilotes des différents processus. Il
convient donc de définir avec précision les champs que couvre chaque processus, en
termes d'activités, de productions mais aussi d'acteurs. Cette tâche se révèle parfois
difficile lorsque les processus sont transverses à différentes entités.

b) Identifier les interfaces

C'est souvent aux interfaces entre processus ou entre entités à l'intérieur d'un
même processus que se situent les principales zones d'amélioration potentielle ou zones
à risques. Il convient donc de les identifier au mieux, d'un point de vue commun aux
différents acteurs qui y interviennent. Il est également important d'étudier, à ces
interfaces, les modalités de circulation de l'information liée au processus : y-a-t-il une
bonne traçabilité ? Les informations importantes des étapes passées sont-elles bien
prises en compte aux étapes suivantes ? N'y-a-t-il pas de jeux d'acteurs aux interfaces
avec des objectifs de pouvoir par rétention d'informations ?

c) Ne travailler que sur des processus critiques

Le travail sur les processus doit être cadré d'un point de vue stratégique et ne viser
qu'à améliorer des performances qui font sens au niveau du service et de ses
bénéficiaires. Il ne s'agit donc pas de travailler sur l'ensemble des processus, mais
seulement sur quelques-uns qui pourraient apparaître prioritaires au vu de différents
critères :

- forts dysfonctionnements,
- insatisfaction des bénéficiaires ou émergence de nouvelles attentes,
- évolution de la stratégie du service…

36
 d) Privilégier une approche participative
Les démarches d'optimisation de processus les plus efficaces sont celles qui
associent assez étroitement les acteurs des processus dans leur amélioration. Il revient à
l’auditeur ou au responsable du processus de fixer les modalités de ce travail participatif,
en les échelonnant dans le temps. Une discussion sur la caractérisation du processus est,
dans tous les cas, indispensable. Les travaux peuvent également associer des
bénéficiaires. Enfin, il est important, sur ces processus-clés, d'anticiper les possibles
résistances au changement des acteurs face aux évolutions : optimiser un processus
signifie souvent modifier des pratiques routinières et davantage se tourner vers les
bénéficiaires ou clients internes ou externes.

e) Garder de la souplesse dans la formalisation pour rester ouvert à

l’urgence
La formalisation des processus ne doit pas créer un système rigide dans lequel
chaque acteur se limiterait à observer à la lettre la procédure. Au contraire, ce système
doit être ouvert, pour permettre et même favoriser les initiatives des acteurs, et
adaptable, pour pouvoir réagir aux aléas, aux urgences, et à plus long terme aux
évolutions des attentes des bénéficiaires. Dans certains cas, il peut même être utile de
configurer un processus spécifique, adapté, pour traiter au mieux l'urgence.

Il faut enfin noter que le degré de formalisation d'un processus varie selon les
compétences des acteurs qui le font fonctionner. De façon générale, plus les
compétences sont élevées, moins la formalisation est stricte. Elle est alors remplacée par
la maîtrise professionnelle des acteurs.

II.1.5. Audit interne ou externe de processus : quelle démarche

adopter ?

Nous vous proposons une démarche en plusieurs étapes séquencées. Selon le

contexte, la stratégie, les priorités de votre service, des poids différents peuvent être mis
derrière ces étapes. Nous vous conseillons dans tous les cas de mettre au point la
démarche de façon précise, par exemple en suivant les principes de la conduite de projet.
Cela suppose notamment de bien cadrer la démarche ou le projet d'optimisation, de

37
nommer un pilote pour chaque processus, de définir un dispositif de suivi, de formaliser
un calendrier et d'allouer les moyens nécessaires. Ainsi la démarche que nous vous
proposons se décline en six (06) étapes lesquelles sont :

1. La cartographie des processus

2. Le choix des processus critiques
3. La caractérisation des processus concernés
4. La description de chaque processus
5. Le diagnostic de chaque processus
6. Le choix d’un degré d’optimisation

Figure 7 : Étapes d’audit des processus

II.1.5.1. Etape 1 : Cartographier les processus

Pour aborder une démarche globale de travail sur les processus, il est utile d'en avoir
une vision d'ensemble. Un repérage de l'ensemble des grands processus d'une
organisation peut ainsi être réalisé sous la forme d'un schéma. C’est pourquoi il est
indispensable que l’organisation ait au préalable mis en place une approche processus.

38
Cette étape est facultative lorsqu'un seul processus est étudié.

II.1.5.2. Etape 2 : Choisir les processus critiques

A l'intérieur de la cartographie précédente, il ne s'agit pas toujours de vouloir optimiser

tous les processus, sauf si l'on souhaite se réorganiser entièrement. Différents critères
peuvent ainsi aider aux choix des processus sur lesquels les travaux d'optimisation
porteront en priorité :

- Constats de forts dysfonctionnements,

- Insatisfaction des bénéficiaires ou émergence de nouvelles attentes,
- Évolution de la stratégie du service qui place certains processus avant
d'autres,
- Développement de nouvelles démarches qui peuvent avoir un impact fort
sur certains processus,
- Mise en place de nouveaux outils informatiques et notamment de
progiciels de gestion intégrée,
- Lancement d'une démarche d'engagements de service (pour s'engager vis
à vis d'un bénéficiaire, il est impératif de maîtriser les processus afférents).
II.1.5.3. Etape 3 : Caractériser chaque processus

Il s'agit de répondre aux questions suivantes :

- quelle est la finalité du processus ?

- quel est le bénéficiaire ou le système bénéficiaire du processus ?
- quel(s) est (sont) le(s) service(s) ou produit(s) fourni(s) ?
- quelles sont les exigences des bénéficiaires par rapport à ce service /
produit ?
- quels sont les indicateurs qui permettent de mesurer le respect de ces
exigences et plus globalement la performance du processus ?
- quels sont les acteurs qui concourent directement au processus ?
- quels sont les principaux moyens utilisés ?

39
- quels sont les éléments d'entrée du processus ? (ce sont parfois les
éléments déclencheurs)
- quels sont les fournisseurs de ces éléments ?
- quelles sont les exigences du processus par rapport à ces fournisseurs ?
- quels sont les indicateurs qui permettent de mesurer le respect de ces
exigences ?

40
 Processus :
Indicateurs
Eléments Gestion d’une Eléments de
Fournisseurs Exigences Bénéficiaire Exigences de
d'entrée session de Sortie
performance
formation
Finalité :
Assurer la
qualité de
la prestation de
Contrôles Conformité
formation pour Contrôles
avant la aux
la satisfaction exercés
Niveau de formation référentiels
des forces Niveau de pour
connaissances de la réalité formation
Forces navales connaissances Les forces s’assurer
prérequis du niveau Contrôles
Navales Acteurs : exigé à l’issue Navales de
pour les de connaissances avant,
Officiers de la formation l’assimilation
élèves prérequis pendant et à
instructeurs des
pour chaque l’issue de la
Moyens : connaissance
élève formation
matériel :
locaux et classes
spécialement
équipés….

Tableau 1 : Exemple de caractérisation d’un processus

41
 NB :

 Le repérage des exigences des bénéficiaires est une étape cruciale de la

caractérisation du processus. Elle peut mériter une enquête approfondie
auprès des bénéficiaires.
 Enfin, lorsque la démarche porte sur plusieurs processus, il est important,
à partir de leurs caractérisations, de vérifier qu'ils ne se recouvrent pas ou
alors que leurs interfaces sont clairement identifiées.
II.1.5.4. Etape 4 : Décrire Chaque processus

Il s'agit de réaliser une description d'ensemble du processus avec la présentation

synthétique des activités et de leurs responsables. Ce travail peut utilement se faire sous
la forme d'un diagramme "qui fait quoi".

Les principales étapes du processus peuvent ensuite être identifiées, les principaux
points de contrôle et les indicateurs actuels également.

Voici un exemple de représentation de la description d'un processus :

Figure 8 : Diagramme « Qui fait quoi » d’un processus

42
 Cette représentation synthétique du processus permet d'en prendre connaissance
rapidement et de susciter de façon participative des interrogations sur l'enchaînement
des activités, les relations entre acteurs et avec les bénéficiaires.

II.1.5.5. Etape 5 : Diagnostiquer chaque processus et son contexte pour

définir les objectifs d’optimisation

A partir de la description précédente, il s'agit de mener un diagnostic approfondi

du processus. Ce diagnostic repose sur l'identification précise des principaux faits
marquant le fonctionnement du processus et son contexte. Ces faits peuvent par exemple
porter sur :

- les dysfonctionnements internes au processus,

- les non-qualités constatées,
- la fréquence des anomalies,
- les insatisfactions des bénéficiaires,
- les évolutions des indicateurs (coût, délai),
- les temps passés à la réalisation de tout ou partie du processus,
- l'émergence de nouvelles attentes des bénéficiaires…
Une fois le diagnostic réalisé, il s'agit de le traduire sous forme d'objectifs clairement
formulés et visant l'optimisation du processus : "réduire de 15% le temps passé à
l'accomplissement de cette partie de processus", "accélérer d'un jour les délais", "réduire
le nombre d'anomalies de 20%", "augmenter de 2 points la satisfaction des
bénéficiaires"…

Le diagnostic s'appuie sur une contribution large des acteurs du processus, sur les
mesures permises par les indicateurs existants et sur une analyse documentaire
approfondie.

43
 II.1.5.6. Etape 6 : Choisir le degré d’optimisation : améliorer ou
reconcevoir selon les objectifs et indicateurs de performance
(recommandations de l’auditeur externe)

En fonction des objectifs identifiés à partir du diagnostic précédent, il s'agit de

décider des actions à mener. Celles-ci peuvent avoir une ampleur très variable, selon
deux dimensions :

- Une action d'amélioration consiste à reprendre le processus existant pour

agir sur certains de ses facteurs.
Exemples : mise en parallèle de certaines étapes, suppression d'une étape,
changement d'outil sur une étape, développement des compétences pour
une tâche, mise en place d'indicateurs à un point stratégique du processus,
modification de la procédure régissant une activité.
- Une action de reconception ne part pas du processus existant. Elle ne se
base que sur les niveaux de performance visés (cf étape précédente) et les
moyens et ressources disponibles pour concevoir un tout nouveau
processus, avec des façons de faire nouvelles, des enchaînements non
encore pratiqués.

II.1.5.7. Etape 7 : Optimiser chaque processus (recommandations

de l’auditeur externe)

En fonction des objectifs précédemment identifiés, il s'agit de décider des actions

d'optimisation à mettre en œuvre, actions qui conduiront à modifier de façon plus ou
moins forte le processus. Les modalités de ce travail varient en fonction des actions
décidées. Quelques conseils restent néanmoins valables pour tout type d'optimisation :

- procéder d'abord sur papier en représentant le processus cible,

- faire réagir les acteurs concernés,
- procéder ensuite par tests successifs des différentes phases du processus,
rectifier ce qui s'avère difficile à mettre en œuvre ;

44
 - concevoir les actions d'accompagnement à mettre en œuvre (formation,
gestion des compétences, outillage),
- communiquer tout au long de ces phases,
- installer enfin l'ensemble du processus, en permettant, sur un délai limité,
les ajustements nécessaires à sa bonne mise en œuvre ;
- installer l'ensemble des indicateurs : indicateurs sur le processus (en cours
de production) et indicateurs de résultats (sur le produit / service fourni et
sur la satisfaction des bénéficiaires),
- définir le pilote de processus (personne ou fonction).

II.1.5.8. Etape 8 : Mettre en œuvre et piloter le processus

(recommandations de l’auditeur externe)

Une fois installé, le processus doit vivre sur le long terme. Son pilotage en continu
est indispensable,

- de façon opérationnelle : suivi des indicateurs de processus et de résultat,

traitement des dysfonctionnements, relevé de fonctionnement, bouclages,
traitement des suggestions des acteurs du processus, suivi des moyens mis en
œuvre, suivi des compétences…
- de façon stratégique : réorientations du processus selon les évolutions du
contexte, de l'environnement, des attentes… ; maintien de la cohérence entre
le processus piloté et le système global.

II.1.6. Techniques, outils, référentiels ou normes à utiliser pour un

audit de processus

Les outils, techniques, référentiels ou normes pouvant être utilisés pour ce type
d’audit sont présentés brièvement dans ce paragraphe.
a) L’approche processus

L’approche processus est l’un des huit (08) principes de base du management de la
qualité de la norme ISO 9001, ce principe stipule que « Un résultat escompté est plus

45
efficacement atteint lorsque les ressources et activités afférentes sont gérées comme un
processus ».
Justifications :
La norme internationale de management de la qualité ISO 9001 dans sa version 2000
donne des directives en matière d’organisation pour permettre à une entreprise de
maîtriser la qualité de ses produits, satisfaire ses clients et améliorer continuellement ses
processus. Elle préconise l’utilisation de l’approche processus, car dans son paragraphe
4.1, la norme dit ceci : « L’organisme doit établir, documenter, mettre en œuvre,
entretenir et améliorer en continu un système de management de la qualité conforme
aux exigences de la présente norme internationale. »
Pour mettre en œuvre le système le système de management de la qualité, l’organisme
doit :
- Identifier et gérer les processus nécessaires au système de
management de la qualité ;
- Déterminer la séquence et l’interaction de ces processus ;
- Déterminer les critères et méthodes nécessaires pour assurer le
fonctionnement efficace et la maîtrise de ces processus ;
- Assurer la disponibilité des informations nécessaires pour soutenir le
fonctionnement et la surveillance de ces processus ;
- Mesurer, surveiller et analyser ces processus, et mettre en œuvre les
actions nécessaires pour obtenir les résultats planifiés et
l’amélioration continue des processus.

b) Le symbolisme des processus

L’étude d’un système d’information est une démarche itérative qui nécessite la
modélisation du réel (un modèle est une représentation de la réalité, qui en reprend
l’essentiel en écartant des détails secondaires).
Justifications :
Le formalisme utilisé pour modéliser le système n’est pas neutre :
- il guide le raisonnement ;

46
 - il permet un dialogue précis entre spécialiste et utilisateur (s’il n’est pas trop
technique) ;
- il favorise la continuité des projets et la communication (s’il correspond à une
méthode standardisée et connue).

c) La norme BPMN

BPMN (Business Process Model notation) est une norme de notation pour la
modélisation de processus. BPMN est soutenu par l’OMG/BMPI (Object Management
Group/ Business Process Management Initiative) depuis leur fusion en 2005.
Son objectif est de fournir un cadre permettant de décrire un processus d’une
manière commune à tous les utilisateurs et ce, indépendamment de l’outil utilisé. L’outil
étant bien sûr censé supporter la norme.

Figure 9 : Exemple de processus modélisé avec BPMN

d) Cobit 4 et les processus de la fonction informatique

L’objectif de l’audit de la fonction informatique est de s’assurer que son

organisation et ses processus sont pertinents et conformes aux règles de l’art, qu’il

47
 s’agisse des processus de planification, de pilotage, de développement de nouvelles
applications, de mise à disposition des services ou de support.

Notons que la fonction informatique et les processus à prendre en compte englobent,

bien au-delà des équipes informatiques internes, l’intervention des dirigeants et des
maîtrises d’ouvrage métiers, et l’ensemble des acteurs externes (éditeurs,
prestataires et fournisseurs) qui contribuent au bon fonctionnement du système
d’information.
Justifications :
CobiT (Control Objectives for Information and related Technology) est le
référentiel majeur de ce second type d’audit informatique. CobiT V4.1 identifie les
4 grands domaines et les 34 processus. Il décrit de façon détaillée les objectifs, les
indicateurs, et les bonnes pratiques associés à chacun de ces processus, et propose
les modèles de maturité associés.
Pour une grande part, ces bonnes pratiques définissent les réponses qui doivent être
apportées par la fonction informatique aux préoccupations qui sont celles du
contrôle interne.
C’est notamment le cas pour :
- les processus PO4, PO5, PO8, PO9, et PO10 du domaine Planifier et
Organiser (Voir Figure 4),
- les processus AI5 et AI6 du domaine Acquérir et Implémenter,
- les processus DS4, DS5, DS8, DS10 et DS11 du domaine Délivrer et
Supporter,
- l’ensemble des processus du domaine Surveiller et Évaluer, qui portent
sur le contrôle interne des autres processus.
L’auditeur doit sélectionner, en fonction de ses objectifs, et des caractéristiques
particulières de l’entreprise et de ses systèmes informatiques, quels processus doivent
être analysés de façon plus approfondie.

e) Les référentiels d’assurance qualité de procédures dans une

organisation sur lesquels l’auditeur devrait se baser tout au long

48
 de sa mission d’audit

- les normes, arrêtés, codes et règlementations

Ces documents sont les premiers référentiels de l'entreprise. Ils sont souvent
réécrits en documents internes de l'entreprise pour qu'ils soient plus faciles d'utilisation.

- Le manuel qualité
Document qui définit toute l'organisation mise en place pour obtenir un produit ou
service d'une Qualité satisfaisante à un coût optimum basé sur la norme ISO 9000. C'est
ce document qui devient le référentiel pour les audits.

- Règles de management
La Direction définit des règles qui se retrouvent soit dans des procédures de
fonctionnement, soit dans des chartes de management, soit dans des fiches fonctions qui
retracent les grandes lignes que doivent suivre l'encadrement.

- Le manuel de procédures ou des modes opératoires

Ensemble des documents appartenant à l'entreprise pour la réalisation d'un produit ou
service spécifique (Instructions, Procédures, Plan d'exécution, gammes etc.).

f) La norme ISO 9004

ISO 9001 et ISO 9004 sont compatibles et utilisables séparément ou ensemble pour
satisfaire ou dépasser les attentes des clients et des parties intéressées. Les deux normes
appliquent une approche processus. Les processus sont considérés comme étant
composés d’une ou de plusieurs activités corrélées qui demandent des ressources et une
gestion pour obtenir des éléments de sortie prédéterminés. Les éléments de sortie d’un
processus peuvent constituer directement les éléments d’entrée du processus suivant et
le produit final est souvent le résultat d’un réseau ou système de processus.
Les huit Principes du management de la qualité forment la base de l’amélioration des
performances.

49
Justifications :
Comparée à ISO 9001, ISO 9004 donne des lignes directrices pour un éventail
plus large d’objectifs SMQ, en particulier pour une gestion visant la réussite à long terme
de l’organisme. ISO 9004 est recommandée à titre de guide pour les organismes dont la
direction souhaite tirer parti d’ISO 9001 pour réaliser une amélioration systématique et
continue de la performance d’ensemble. Mais elle n’est pas destinée à être utilisée pour
la certification ou à des fins contractuelles.
Les aspects à prendre en compte lors de l’audit sont :
- la mise en œuvre efficace et efficiente des processus ;
- les opportunités d'amélioration continue ;
- la capacité des processus ;
- l'utilisation efficace et efficiente des statistiques ;
- l'analyse des données sur les coûts de non qualité ;
- l'utilisation efficace et efficiente des ressources ;
- les résultats et les attentes concernant les performances des
processus et des produits ;
- l'adéquation et la justesse des mesures de performance.

g) La norme ISO 19001

ISO 19011 couvre le domaine de l’audit des systèmes de management de la

qualité et de management environnemental. Elle contient des lignes directrices pour les
programmes d’audit, la conduite des audits internes ou externes, et des informations sur
la compétence des auditeurs.
Justifications :
ISO 19011 donne une vue d’ensemble de la manière dont un programme d’audit
devrait fonctionner et dont les audits de systèmes de management de la qualité devraient
se dérouler. Des audits efficaces permettent de s’assurer qu’un SMQ mis en œuvre
satisfait aux exigences spécifiées dans la norme ISO 9001. La nature de votre organisme
et vos besoins spécifiques détermineront la manière dont vous appliquerez ces normes
pour atteindre vos objectifs.

50
51
II.2. AUDIT DE LA SECURITE PHYSIQUE

Figure 10 : Zoom sur l’audit de la sécurité physique

II.2.1. Définition et objectifs

Un audit de sécurité est un audit qui permet de s’assurer que l’ensemble des
dispositions de sécurité prises permet d’assurer la sécurité des données de l’entreprise.
L’objectif d’audit de la sécurité physique est donc de fournir un environnement
physique adapté qui protège l’équipement informatique et les personnes contre les
risques humains et naturels.

II.2.2. Pourquoi un audit de sécurité physique ?

Un audit de sécurité physique peut être établi dans l’un des cas suivant :
- Evaluer le niveau de maitrise, de l’efficience des mesures de sécurité
physique, de leur robustesse et de leur efficience
- A la suite d’un incident
- Demande d’audit externe (commissaires aux comptes, clients, organismes de
contrôle, etc.
- Conformité par rapport à une législation

52
 II.2.3. Durée d’un audit de sécurité physique

Selon degré de granularité, le périmètre, le nombre d’entretiens et de contrôle, la

disponibilité des intervenants... la durée d'un audit de sécurité physique peut aller d'une
demi-journée a une semaine

II.2.4. Démarche

Cette démarche est établie selon le CLUSIF (Club de la Sécurité de l’Information

Français) dans « Aider les auditeurs pour les revues de sécurité physique »
Eventuellement, l’audit peut se dérouler à partir de questionnaire existants en fonction
du type d’audit à réaliser : MEHARI, contrôle interne, issus de normes, issus de la
réglementation. Notre démarche d’évaluation sera donc réalisée selon les types de
métiers :
- Les risques environnementaux et naturels
- Le contrôle d’accès et intrusion
- Les incendies
- Les Dégâts des eaux
- Les Servitudes
- Le système de gestion de la sécurité physique

53
 Figure 11 : illustration de la démarche Audit de la sécurité physique

II.2.4.1. Etape 1 : Evaluer les risques environnementaux (voisinage) et

naturels
a) Voisinage
Il s’agit de l’environnement du site et qui concerne l’ensemble du site(le terrain, le toit,
les murs, les voisins, le sous-sol).
 Y’a –t-il eu une analyse de risques préalable a l’implantation du site ?
 Si oui pouvons-nous voir le rapport ?
La conclusion sera l’adéquation entre les dispositifs de sécurité mis en œuvre et les
risques constatés.

b) Risques naturels
Elles permettent d’éliminer certains risques ou au contraire de découvrir de possibles
risques à approfondir.
Avez-vous réalisé ou fait une analyse de risques environnementale ?
 Risque naturel d’inondation,
 Risque d’exposition naturel a la foudre,
 Risque sismique,
 Risque volcanique,
 Risque Serveo,
 Risque lié à la nature du voisinage,
 Risque lié à un sous-sol instable.

II.2.4.2. Etape 2 : Evaluer le système de Contrôle d’accès et d’intrusion

a) Périphérie
En arrivant l’auditeur fait le tour du site pour identifier les protections physique mis en
place
NB : pour chaque test effectué, noté l’heure du test.

54
  Quelles sont la hauteur et la qualité de la clôture, nombres de cameras
(vérifications postérieure des écrans de contrôle), efficacité du portail
(piéton, véhicules, livraison, personnel, visiteur y compris les flux
associés) ?
 Où se trouve les arrivées des servitudes (énergie, télécommunication, eau,
cuves de fuel, gaz) ?
 Quels sont les horaires d’activités de contrôle ?
 Ou se trouvent les câbles dans le sol ?
 Végétation
 Fréquences de rondes ?
NB : noter l’heure des passages des caméras (pour vérifier ultérieurement les films)

En conclusion on pourra dire si la périphérie du site est protégée en fonction des risques
identifiés, si des brèches de sécurité ont été identifiées et s’il y a adéquation entre les
mesures de sécurité mise en place et les risques identifiés.

b) Périmètre
Pendant le tour extérieur du site, l’auditeur observe les mesures de contrôle associées au
bâtiment etc.
 Comment sont protégés les ouvrants ? Vérifier la cohérence de la
protection. Quel est le matériau utilisé pour les fenêtres (verres blindé,
verre simple, barreaudage, etc..), les volets, les murs (béton, pierre, brique,
etc.)
 Quelle protection pour les accès par le toit (skydômes, etc.) et par les sous-
sols ?
 Demander quelles sont les entrées sur l’extérieur : entrée du personnel
entrée des visiteurs, les zones de chargement/déchargement, les issus de
secours , autres portes donnant sur l’extérieur.
La conclusion dira si le périmètre est protégé en fonction des risques identifiés, s’il y a
les brèches de la sécurité identifiées et si les mesures de sécurité mises en place sont en
adéquation avec les risques identifiés.

55
 c) Bâtiment
Au moment d’entrer, vérifier quels sont les contrôles. Vérifier pour chaque zone, la
présence ou non des sas.
 Quel est l’organigramme de gestion des clés ?
 Où sont les boîtes à clés, comment sont-elles gérées ? et accédées ?
 Quelles sont les protections propres aux issus de secours ?
 Faire le test des portes ouvertes et noter l’heure d’ouverture, les heures de
passages des caméras ?

d) Poste de garde
 Quelle est la localisation du poste de garde ? Sa protection : contrôle
d’accès, vitres sécurisées ? dispositif d’alertes ?
 Quelle est la formation des gardiens ? Quels sont les moyens à leur
disposition ?
NB : Demander à rencontrer les personnes capable de montrer l’historique des alarmes
et des films concernant la période de test des auditeurs pour vérifier des résultats des
tests fait pendant la visite des locaux.

Conclusion concernant le bâtiment

La conclusion permettra de savoir si le bâtiment est protégé en fonction des risques
identifiés, s’il existe des brèches de sécurité identifiées, et si les mesures de sécurité
mises en place sont adéquates.

e) Salles sécurisées
 Discrétion
- Salle serveur est-elle signalée de façon trop voyante ?
- La médiathèque est-elle signalée de façon trop voyante ?
 Protection extérieure (à vérifier pendant la visite) :

56
 - La salle serveur a-t-elle un mur sur l’extérieur ou est-elle
complément à l’intérieur du bâtiment ? A quel étage est située la
salle serveur ? Est-elle accessible directement de l’extérieur ?
- L’enceinte de la salle des serveurs est-elle robuste vis-à-vis d’une
tentative d’effraction et de dégradation ?
 Politique de gestion des accès
- Poser les questions et demander à consulter les procédures et
vérifier leur application.
- Qui à accès et quand ? quelle est la politique d’attribution des
accès ? Quelle est la procédure associée en fonction du type de
contrôle d’accès?
NB : Demander à consulter la liste nominative des personnes ayant l’accès, porter une
attention particulière au personnel non permanent. Demander à voir les journaux de
système de contrôle d’accès.

f) Protection intérieure
- Quelles sont les technologies de détection utilisées ?
- Les détecteurs d’intrusion sont-ils positionnés de façon à couvrir
tout le périmètre à protéger ?

g) Servitudes
Les servitudes concernent tout ce qui sert à faire fonctionner le site :
- Alimentation électrique
- Alimentation télécom
- Climatisation
- Arrivée des eaux
- Arrivée de différents fluides
-
Pendant la visite vérifier

57
 - Comment sont protéger les locaux techniques (local
transformateur, les locaux abritant les groupes électrogènes, les
tableaux généraux)
- Accès quel type d’accès ?
- qui a accès ?
En conclusion, on dira si les locaux sont protégés en fonction des risques identifies, son
a identifié des brèches de sécurité et si les mesures de sécurité mises en place sont en
adéquation avec les risques identifiés.

NB : Les servitudes sont vitales pour le bon fonctionnement d’un site abritant les salles
serveurs. La question à poser, en dehors des contrôles d’accès, concernant
essentiellement la capacité des servitudes à assurer le bon fonctionnement du site et la
disponibilité permanente du site.

II.2.4.3. Etape 3 : Apprécier le système de sécurité incendie

a) Prévention
- Environnement du site à protéger
- Types de construction du bâtiment
- Compartimentage
b) Détection incendie
La détection d’incendie doit être efficace et permettre d’éviter la propagation d’un
feu et donc d’intervenir avant l’incendie.
c) Extinction incendie
- Locaux sans extinction automatique
- Moyens de secours
- Désenfumage
d) Maintenance des équipements de lutte contre le risque
d’incendie
- Maintenance préventive
- Maintenance curative

58
 II.2.4.4. Etape 4 : Apprécier les dégâts des eaux

Demander à voir le plan d’implantation des équipements et des canalisations.

Conclusion de l’auditeur concernant le risque des dégâts des eaux

On dira si les locaux sont protégés en fonction des risques identifies, son a identifié
des brèches de sécurité et si les mesures de sécurité mises en place sont en adéquation
avec les risques identifiés.

II.2.4.5. Etape 5 : Analyser le système Gestion de la sécurité physique

Elle a pour but d’analyser la gestion de la sécurité physique du point de vue :

- Organisation
- Moyens
- Gestion des alarmes
- Procédure
- Installation et maintenance des équipements
- Gestion des schémas d’installation

II.2.4.6. Conclusion de l’auditeur sur la gestion de la sécurité

La conclusion dira si la sécurité est gérée en fonction des risques identifiés, listera les
vulnérabilités de sécurité identifiées et si l’organisation de la sécurité mise en place est
en adéquation avec les risques identifiés.

II.2.5. Techniques, outils, référentiels ou normes à utiliser pour un

audit de processus

Les outils, référentiels, normes et techniques présentées ici aideront l’auditeur dans son
évaluation pour ce type d’audit. Certains de ces outils pourront être utilisés par les
responsables de SI pour la maîtrise de la sécurité physique du SI dont ils ont la charge.

COBIT

Pour ce type d’audit CobiT 4.1 propose le processus DS12 (Livraison et Support)

59
Les Objectifs de contrôle du CobiT :

 (12.1) Sécurité physique ;

 (12.2) Discrétion du site informatique
 (12.3) Accompagnement des visiteurs
 (12.4) Santé et sécurité du personnel
 (12.5) Protection contre les risques liés à l’environnement
 (12.6) Continuité de l’alimentation électrique

ITIL

Le processus suivant est normalement situé hors du cadre de la gestion des services
informatiques et ITIL le positionne d’ailleurs dans un livre à part. Cependant, les
interactions entre ce processus et les dix processus de la gestion des services (ITSM)
sont très fortes et la mise en place de l’un ne peut que difficilement se faire sans l’autre.

- Gestion de l’infrastructure TIC

Les fonctions de gestion de l’infrastructure des TIC sont impliquées dans la plupart des
processus de soutien et de fourniture des services où des questions plus techniques se
présentent. On trouve en particulier la gestion des configurations et la gestion de
capacité, mais également la gestion de la disponibilité. On recommande également que
les modifications de l’environnement (électricité, climatisation, sécurité d’accès,
protection incendie, etc.) soient prises en compte par la gestion de l’infrastructure.

ISO/EC 27002-ISO/IEC 27001

L’annexe A.10.5 de l’ISO 27001 est un objectif nécessaire pour mettre en place les
mesures de sauvegarde et de l’information. Les mesures de sécurité qui en découlent
sont :

 Les zones sécurisées seront protégées par des contrôles adéquats en entrée pour
s’assurer que seul le personnel habilité est admis ;

60
  Les mesures de protection physiques contre les dommages causés par les
incendies doivent être conçus et appliqués ;

 Des copies de sauvegarde des informations des logiciels doivent être réalisés et
soumises régulièrement à essai conformément à la politique de sauvegarde
convenue.

Référentiels /normes Outils

ISO/EC 27002-ISO/IEC 27001 OCSInventory-NG (Open Computer
ISO/IEC 14001 and Software
MEHARI, EBIOS Inventory Next Generation) qui est un
ITIL (Information Technology outil de collecte automatisée
Infrastructure Library) : gestion de d'éléments d'un parc
l’infrastructure IT Informatique
GLPI (gestion Libre de Parc
COBIT Informatique

Tableau 2 : référentiels, normes et outils à utiliser pour l’audit de la sécurité physique

61
II.3. AUDIT DU RESEAU

Figure 12 : Zoom sur l’audit du réseau

II.3.1. Définition

Un Réseau informatique est un ensemble d'équipements reliés entre eux pour échanger
des informations. Par analogie avec un filet (un réseau est un « petit rets », c'est-à-dire
un petit filet), on appelle nœud l'extrémité d'une connexion, qui peut être une
intersection de plusieurs connexions ou équipements (un ordinateur, un routeur,
un concentrateur, un commutateur).

L'audit d'un réseau informatique vise à établir une cartographie précise du réseau
informatique d'une entreprise. Le matériel, le câblage, les logiciels, les équipements
d'interconnexion sont testés et analysés afin de générer des rapports de performances.

II.3.2. Objectifs
L'idée est de s'assurer que le réseau est optimisé pour les processus métiers de
l'entreprise et qu'il répond au niveau de qualité requis pour son système d'information.

62
 II.3.3. Exécution de l’audit

Nous vous proposons dans cet ouvrage un audit du réseau en trois (03) étapes :

- Une étape d’approche qui permet à l’auditeur de s’approprier la philosophie de

l’infrastructure réseau à inspecter ;
- Une étape d’analyse des vulnérabilités et risques et ;
- Une étape de tests intrusifs.

Figure 13 : Illustration de la démarche d’audit de réseau

II.3.3.1 Etape 1 : Phase d’approche

Pour évaluer le niveau de sécurité d'un réseau, il faut d'abord le connaître. Pour la
reconnaissance de l'architecture du système, l'auditeur reçoit des informations
inventoriées par l'équipe informatique locale afin de vérifier le plan d'adressage IP et
éventuellement la stratégie de mise en œuvre de DHCP (Dynamic Host Configuration
Protocol qui est un protocole réseau dont le rôle est d'assurer la configuration
automatique des paramètres IP d'une station) et de NAT (Network Address Translation)
qui permet notamment de faire correspondre une seule adresse externe publique visible
sur Internet à toutes les adresses d'un réseau privé. Il utilise ensuite de multiples outils
de traçage du réseau et des passerelles, afin de détecter les stations, routeurs et firewalls
du réseau et des outils de traçages des frontières externes du réseau : passerelles externes

63
(routeurs et firewalls) et connexions modems pour déterminer les périmètres extérieurs
du réseau. Multiples outils de l'open source sont utilisés pour l'identification de la
topologie réseau comme Cheops, traceroute et tcptraceroute.
Les outils open source utilisés sont : Ntop (Network top : une application qui
produit des informations sur le trafic d'un réseau en temps réel), Bing, Iptraf (petit
utilitaire servant à analyser rapidement et facilement le trafic transitant par vos
connexions réseau) et Network Probe.

II.3.3.2. Etape 2 : Phase d’analyse de vulnérabilité

Au cours de cette phase, l'auditeur détermine, à l'aide des résultats obtenus à

l'étape précédente, les vulnérabilités potentielles et des outils nécessaires à leur
exploitation. En pratique, l'auditeur teste la résistance du système face aux failles
connues, via une analyse automatisée des vulnérabilités, ainsi il établit pour chacune le
type des applications et des services concernés.

Nessus est un exemple d'outil de test automatique de vulnérabilités, il offre des

rapports évolués sur les degrés des vulnérabilités et les risques qu'imposent des failles
détectées sur le système audité. Sara, Whisker, Webserver, fingerprinting, karma et
Tnscmd.pl sont d'autres exemples d'outils d'analyse de vulnérabilités des serveurs de
données & d'applications.

II.3.3.3. Etape 3 : Phase de tests intrusifs

L'objectif des tests intrusifs est d'expertiser l'architecture technique déployée et de

mesurer la conformité des configurations équipements réseaux, firewall, commutateurs,
sondes, etc. Avec la politique de sécurité définie et les règles de l'art en la matière. Les
tests d'intrusion sont réalisés après autorisation explicite du client et reposent sur un
ensemble de scénarios d'attaques expertes (pénétration, intrusion, etc..) mis en œuvre
pour compromettre un système d'information. Réalisés de manière récurrente, les tests
d'intrusion permettent de valider périodiquement le niveau de sécurité du système
d'information et d'en mesurer les variations. Les tests d'intrusion commencent par une
phase de collecte des informations disponibles publiquement, sans interagir avec

64
l'environnement cible puis il s'agit de localiser et caractériser les composants cibles
(systèmes d'exploitation et services applicatifs, positionnement des équipements les uns
par rapport aux autres, types de dispositifs de sécurité mis en œuvre, etc.); c'est la phase
de cartographie de l'environnement cible et enfin il s'agit d'exploiter les vulnérabilités
mises en évidence pendant les phases précédentes de façon a obtenir un accès " non
autorisé " aux ressources.

II.3.4. Techniques, outils, référentiels ou normes à utiliser pour

l’audit réseau informatique

L'auditeur s'appuie sur un certain nombre d'outils pour analyser le réseau informatique :

 Les scanners de vulnérabilités pour identifier le nombre de failles présentes

dans le réseau ;
 Les sondes placées sur des points stratégiques du réseau de façon à mesurer
les niveaux de performances et identifier les goulots d'étranglements par
exemple ;
 Les normes comme ISO 27007 sur la sécurisation de l'information ;
 Les Logiciels d’audit réseau : looklan Network Monitor, Visual audit
 Le référentiel CobiT 5 propose dans le 2e domaine Aligner, Planifier et
Organiser, le processus de gestion d’architecture et d’entreprise (APO03
Gérer l’Architecture d’Entreprise).

65
 II.4. AUDIT DES DONNEES

Figure 14 : Zoom sur l’audit des données

En matière informatique l'audit le plus connu est celui qui concerne la sécurité des
systèmes, l'audit de bases de données constitue une demande de plus en plus croissante.
N'oublions pas que les données constituent la matière même de l'informatique et que la
croissance du volume des données stockées nécessite quelques exigences de sérieux que
certaines officines informatiques ont tendance à oublier au profit d'application poudre
aux yeux.

II.4.1. Définition de l’audit des données

L’audit de données est une méthode permettant de faire une analyse complète des
informations maintenues dans une ou plusieurs bases de données. L’objectif d’une telle
analyse est d’obtenir une vision claire de la qualité des données présentes en bases et de
préconiser des améliorations, essentiellement sur le plan de la conformité et des
performances.

II.4.2. Qu’est-ce qu’une donnée ?

L’AFNOR (Agence Française de NORmalisation) définit une donnée comme un fait,

notion ou instruction représentée sous forme conventionnelle convenant à la
communication, à l’interprétation ou au traitement par des moyens humains ou
automatiques.
66
 Une base de données est une entité dans laquelle il est possible de stocker des
données de façon structurée et avec le moins de redondance possible. Ces données
doivent pouvoir être utilisées par des programmes, par des utilisateurs différents.

Figure 25 : Serveur de données

En informatique on représente les données sous trois aspects:

- Conceptuel,
- Logique,
- Physique.

II.4.3. Pourquoi l’audit des données ?

a) Les enjeux de la sécurité des données.

Les enjeux de la sécurité des données à l’échelle des personnes et des organisations
sont les suivants (cette liste est loin d'être exhaustive) :

- Libertés individuelles : protection de la vie privée (voir vie privée et

informatique),
- Bureautique : sécurité des données enregistrées sur le disque dur du micro-
ordinateur (courriels, répertoires, fichiers documents, données des tableurs
et des présentations…),

67
- Communication : ciblage des parties prenantes internes et externes en
fonction de leurs intérêts, ne pas divulguer inutilement trop d'informations
non structurées sur l'internet,
- Hygiène et sécurité : identification des données nécessaires aux
procédures de protection de la santé des employés,
- Secret des affaires : protection du capital intellectuel de l'entreprise
- Marketing : identification des marchés sensibles, veille concurrentielle,
- Recherche et développement : alignement du processus de R&D sur les
besoins du marché, identifiés et validés par le marketing : sécurisation des
données issues de la veille en entreprise, de la veille technologique, et
développement du capital intellectuel de l'entreprise.
- Exemple dans la chimie : fiche de données de sécurité, pour les substances
chimiques pour l'industrie du pneumatique, de l'automobile…
- Traçabilité des documents et responsabilité du fait des produits défectueux
: pouvoir donner la preuve de la qualité d'un produit.
- Achats : demande d'achat (dans l'aéronautique, l'automobile… par
exemple), critères utilisés pour le choix des fournisseurs.

b) Rappel des objectifs de la sécurité.

- La disponibilité : le système doit fonctionner sans faille durant les plages

d'utilisation prévues et garantir l'accès aux services et ressources installées
avec le temps de réponse attendu.
- L'intégrité : Les données doivent être celles que l'on attend, et ne doivent
pas être altérées de façon fortuite, illicite ou malveillante. En clair, les
éléments considérés doivent être exacts et complets.
- La confidentialité : seules les personnes autorisées ont accès aux
informations qui leur sont destinées. Tout accès indésirable doit être
empêché.

68
 Figure 16 : Représentation de la triade D, I, et C.

La norme ISO 13335 (qui n'existe qu'en anglais) mentionne également la non-
répudiation, la gestion de la preuve (imputabilité), et l'authentification :
- L'authentification correspond à l'une des trois phases du contrôle d'accès,
qui est du domaine de la confidentialité;
- il y a également une notion d'authenticité qui n'est pas liée directement au
contrôle d'accès : il s’agit pour celui qui consulte une donnée, de se
convaincre de l'identité de l'émetteur ou du créateur de la donnée.
- La non-répudiation vise à empêcher que l'auteur d'une donnée puisse
prétendre ensuite qu'il n'en est pas l'auteur; elle implique l'intégrité, mais
s’étend au-delà.
- La gestion de la preuve (imputabilité) concerne tous les aspects de la
sécurité des systèmes d'information.

c) Les principales menaces liées à l’information sécurisée

Les principales menaces liées à l’information sécurisée

- Abus de privilège excessif
- Abus de privilège légitime
- Elévation de privilège

69
 - Exploitation de failles des bases de données vulnérables ou mal configurées
- Injection SQL
- Faiblesse de l’audit natif
- Déni de service
- Vulnérabilités des protocoles de communication des bases de données
- Copies non autorisées de données sensibles
- Exposition de données de sauvegarde

II.4.4. Démarche d’une mission d’audit des données.

Ce domaine traite des aspects de protection des données gérées par le système
d’information, tant sur les problématiques de confidentialité que d’intégrité.
En effet, par nature et en raison du périmètre fonctionnel couvert et du nombre
d’utilisateurs, le système d’information comporte des données sensibles et / ou des
données personnelles.
En termes de structure, le domaine est découpé selon les grandes étapes suivantes :
- La définition des besoins métiers en matière de sécurité des données.
- La protection de l’accès aux données.
- Les dispositifs de gestion de la confidentialité des données.
- Les dispositifs de gestion de l’intégrité des données.
Enfin, un point spécifique concerne le respect des obligations règlementaires
incombant à l’organisation quand elle doit gérer des données à caractère personnel.
Les principaux risques identifiés sur ce domaine sont :
- L’infraction à la loi.
- L’accès non autorisé au système et aux données qu’il gère.
- La copie non autorisée de données.
- La perte ou l’altération de données.
- La mauvaise identification des besoins métier en matière de protection des
données.

70
 - La mise en place de mesures de protection ne permettant pas d’atteindre les
besoins métiers exprimés.

Vérification de la Vérification des dispositifs

définition des besoins de gestion de la
métier en matière de confidentialité des
sécurité des données données

Vérification des mesures Vérification des dispositifs

de protection de l’accès de gestion de l’intégrité
aux données des données

Vérification du respect des

obligations règlementaires

Figure 17 : Illustration du processus d’audit des données

II.4.4.1. Etape 1 : Vérifier si la criticité et la sensibilité des données sont

régulièrement évaluées

 Existe-t-il un référentiel de classification des données ?

Commentaires :

Le référentiel intègre les objectifs en matière de Disponibilité, d’Intégrité, de

Confidentialité et de Traçabilité (DICT).

Ce référentiel inclut notamment l’identification des contraintes réglementaires

pesant sur l’organisation et ses données.
De même, les données à caractère personnel sont identifiées.
Risques :
 Accès non autorisé ou frauduleux.
 Non-respect réglementaire ou légal.

71
  Perte de données.
 Perte de traçabilité.
 Vol de données.
 Altération ou perte d’intégrité des données.
Preuves à demander :

Le référentiel de classification et preuve de son utilisation.

Bonnes pratiques

Le référentiel doit être simple à comprendre, non interprétable, et contenir un

nombre réduit de niveaux de classification

 Les propriétaires des données sont-ils identifiés ?

Commentaires :

Le propriétaire de données est le représentant du métier qui est responsable de la

donnée (vis-à-vis des tiers et des collaborateurs).

Risques :

 Accès non autorisé ou frauduleux.

 Non-respect réglementaire ou légal.
 Perte de données.
 Perte de traçabilité.
 Vol de données.
 Altération ou perte d’intégrité des données.
Preuves à demander :

Lien documenté entre le propriétaire et la donnée (via le dictionnaire des données

ou le processus métier considéré).

Bonnes pratiques

La liste des propriétaires par donnée est publiée et partagée.

 Les données sont-elles classifiées par les propriétaires sur la base du

référentiel ?
72
 Commentaires :

La classification des données est réalisée en application du référentiel et

formalisée pour chaque donnée ou groupe de données dans le respect des
catégories et criticités des données.

Risques :

 Accès non autorisé ou frauduleux.

 Non-respect réglementaire ou légal.
 Perte de données.
 Perte de traçabilité.
 Vol de données.
 Altération ou perte d’intégrité des données.
Preuves à demander :

Classification par criticité des données.

Bonnes pratiques

La classification des données est validée formellement par le propriétaire. Elle

fait l’objet d’une mise à jour régulière.

 Les données nécessitant un chiffrement sont-elles identifiées ?

Commentaires :

Suite à la classification des données du système d’information, une étape distincte

de décision quant au chiffrement éventuel des données peut être conduite.

Risques :

 Accès non autorisé ou frauduleux.

 Non-respect réglementaire ou légal.
 Perte de données.
 Perte de traçabilité.
 Vol de données.
 Altération ou perte d’intégrité des données.

73
 Preuves à demander :

Relevé de décision de chiffrer ou non certaines données.

Bonnes pratiques

La décision de chiffrer ou de ne pas chiffrer est documentée.

II.4.4.2. Etape 2 : Vérifier si l’organisation a mis en place les dispositifs de

protection de l’accès aux données, en fonction des besoins

 Existe-t-il des pare-feux mis en œuvre pour protéger les accès du SI via
Internet ?
Commentaires :

Des pare-feux ont été installés au niveau de chaque connexion Internet et entre
toute zone démilitarisée (DMZ) et la zone de réseau interne.

Risques :

 Accès non autorisé ou frauduleux.

 Perte de données.
 Perte de traçabilité.
 Vol de données.
 Altération ou perte d’intégrité des données.
Preuves à demander :

Obtenir la documentation définissant les règles de pare-feu, et vérifier que ces

règles sont appliquées.

Bonnes pratiques

Il est réalisé une évaluation régulière des risques avec mise à jour et maintien au
niveau des pratiques diffusées sur les réseaux.

 Existe-t-il des dispositions de détection des intrusions associés au filtrage

réseau sur les zones permettant l’accès à Internet ?

74
 Commentaires :

En complément des pare-feux, des dispositifs de détection d’intrusion (ou IDS

pour Intrusion Detection System) permettent l’identification des cas où la sécurité
est contournée et offrent la faculté de protection appropriée en fonction de
l’intrusion.

Risques :

 Accès non autorisé ou frauduleux.

 Perte de données.
 Perte de traçabilité.
 Vol de données.
 Altération ou perte d’intégrité des données.
Preuves à demander :

Obtenir la preuve des alertes et de leur traitement.

Bonnes pratiques

RAS.

 Est ce que l’accès physique aux données et aux systèmes d’hébergement est
restreint de façon appropriée ?
Commentaires :

L’accès aux salles blanches, mais également aux locaux, est restreint aux
personnes autorisées

Risques :

 Accès non autorisé ou frauduleux.

 Perte de données.
 Perte de traçabilité.
 Vol de données.
 Altération ou perte d’intégrité des données.
Preuves à demander :

75
  Procédures d’accès et règles d’attribution, notamment pour les salles
hébergeant les données, y compris chez les prestataires.
 Journal d’accès à la salle blanche hébergeant les serveurs.
Bonnes pratiques

RAS.

 Est ce que les interventions en requête des utilisateurs dans les bases de
données de production sont interdites ? est-ce que les interventions des
applications externes en interrogation sont autorisées et contrôlées ?
Commentaires :

Les requêtes dans les tables sont parfois laissées libres en production pour
compenser les fonctionnalités manquantes.

Dans le cas où les requêtes sont réalisées sous forme de service à la demande au
Centre de Compétences, il est nécessaire de demander la procédure qui encadre
ce service incluant la vérification que les demandeurs sont bien habilités à réaliser
les requêtes.

Risques :

 Accès non autorisé ou frauduleux.

 Perte de données.
 Perte de traçabilité.
 Vol de données.
 Altération ou perte d’intégrité des données.
Preuves à demander :

 Justification de l’inactivation des transactions de requêtage.

 Preuve de l’impossibilité de lancer les programmes concernés, car les
objets d’autorisations liés ne sont pas attribués.
Bonnes pratiques

Des requêtes ad hoc sont développées en fonction des besoins exprimés et

formalisées, en suivant le processus de gestion des changements.

76
 Est ce que les interventions en administration des bases de données sont
encadrées, tracées et contrôlées ?
Commentaires :

Les utilisateurs techniques ont souvent un rôle critique, avec la possibilité

d’interventions sur les bases, et la faculté de s’attribuer des droits.

Risques :

 Accès non autorisé ou frauduleux.

 Perte de données.
 Perte de traçabilité.
 Vol de données.
 Altération ou perte d’intégrité des données.
Preuves à demander :

 Tables d’accès au Système de gestion de bases de données - SGBD -

(journaux).
 Procédures de gestion des bases de données (existence, application et mise
à jour).
 Procédures de gestion des logs des bases de données pour les accès par les
administrateurs.
Bonnes pratiques

Disposer d’un personnel compétent dédié à l’administration des bases de

données.

 Est-ce que les interventions de maintenance sont encadrées, tracées et

contrôlées ?
Commentaires :

Pour des raisons de maintenance ou des besoins relatifs au projet, les équipes
(clients, intégrateurs, etc) peuvent être amenées à accéder au système productif
(diagnostic d’anomalies en production, opérations sur les données comme dans
les fusions de sociétés). Une procédure doit donc permettre de tracer et de

77
 contrôler l’action des intervenants (accès nominatifs, signature d’engagement de
confidentialité). Les intervenants pouvant être localisés un peu partout sur la
planète, cela augmente le risque.

Risques :

 Accès non autorisé ou frauduleux.

 Perte de données.
 Perte de traçabilité.
 Vol de données.
 Altération ou perte d’intégrité des données.
Preuves à demander :

 Procédures relatives à la maintenance.

 Calendrier des actions programmées.
 Journal des traces.
Bonnes pratiques
RAS

II.4.4.3. Etape 3 : Vérifier si l’organisation a mis en place les dispositifs de

protection de la confidentialité des données, en fonction des besoins

 Existe-t-il des dispositifs de gestion des niveaux de confidentialité mis en

œuvre en accord avec la classification ?
Commentaires :

On observe généralement différents niveaux en matière de traitement de la

confidentialité : de la consultation libre au chiffrement.

Risques :

 Accès non autorisé ou frauduleux.

 Vol de données.
Preuves à demander :

78
  Journaux traçant l’utilisation des données jugées les plus sensibles et
preuve de l’exploitation de ces journaux.
 Preuves de la mise en place des dispositifs de chiffrement.
 Preuves de l’existence de règles et procédures mises en place.
 Contrôler la correcte définition et la mise en œuvre de règles de gestion
des niveaux de confidentialité en fonction des besoins exprimés.
Bonnes pratiques

RAS

 Existe-t-il des dispositifs de suivi périodique des risques et des besoins de

confidentialité ?
Commentaires :

Les évolutions des risques et les changements en matière de besoins de sécurité

sont à évaluer périodiquement.

Risques :

 Accès non autorisé ou frauduleux.

 Vol de données.
Preuves à demander :

 Documentation de l’évolution du dispositif.

Bonnes pratiques

Une mise à jour annuelle est un minimum.

 Est-ce que la mise en œuvre des dispositifs et leur efficacité sont contrôlées
périodiquement ?
Commentaires :

Ces contrôles sont effectués par les équipes métier et leur management, et les
actions de correction nécessaires sont entreprises.

Risques :

 Accès non autorisé ou frauduleux.

79
  Vol de données.
Preuves à demander :

 Justificatifs de l’organisation et de la réalisation de ces contrôles, ainsi que

des éventuels plans d’actions.
Bonnes pratiques

 La périodicité des contrôles est établie en fonction des niveaux de criticité.

 Quel que soit le niveau, une évaluation annuelle peut être considérée
comme une bonne pratique.

 Existe-t-il des actions régulières de sensibilisation menées auprès des

personnes ayant accès aux données confidentielles ?
Commentaires :

L’objectif est de responsabiliser les acteurs sur les comportements qui pourraient
affecter la sécurité des données confidentielles.

Risques :

 Accès non autorisé ou frauduleux.

 Vol de données.
Preuves à demander :

 Preuve des actions de sensibilisation (formation, mails, courriers

d’engagement).
Bonnes pratiques

 Une charte existe et est diffusée.

 Un engagement formel à la respecter est consigné.

 Est-ce que l’interdiction de l’utilisation des données de production

confidentielles dans d’autres environnements est mise en œuvre ?
Commentaires :

80
 Les environnements non productifs n’offrent généralement pas le même niveau
de sécurité des données.

Risques :

 Accès non autorisé ou frauduleux.

 Vol de données.
Preuves à demander :

 Procédures de mise à disposition des données sur les environnements non

productifs ou évaluation des niveaux de sécurité des environnements non
productifs.
Bonnes pratiques

Des outils d’anonymisation des données sont utilisés pour alimenter les
environnements non productifs à partir des données de production.

 Existe-t-il un processus de destruction sécurisés des données obsolètes ?

Commentaires :

Cela est particulièrement sensible sur les supports externes de stockage

(cartouches, CD / DVD, disques externes).

Risques :

 Accès non autorisé ou frauduleux.

 Vol de données.
Preuves à demander :

 Procédures de destruction des données et compte rendu de la dernière

destruction des données.
 Le cas échéant, preuve du processus d’aliénation des matériels ou
consommables ayant servi au stockage des données.
Bonnes pratiques

RAS

81
 II.4.4.4. Etape 4: Vérifier si l’organisation a mis en place les dispositifs de
protection de la confidentialité des données, en fonction des besoins

 Existe-t-il des dispositifs de conservation de l’intégrité des données en

fonction des besoins d’intégrité définis ?
Commentaires :

Les accès en modification et en suppression sont attribués aux seules personnes

habilitées. Par ailleurs, des journaux tracent toute modification / suppression de
données, selon un paramétrage propre.

Ces journaux sont exploités régulièrement et les corrections nécessaires

effectuées.

Risques :

 Accès non autorisé ou frauduleux.

 Vol de données.
 Perte de traçabilité
Preuves à demander :

 Matrice des droits d’accès aux données et transactions.

 Existence de la mise en œuvre de journaux sur les tables et preuve de leur
exploitation.
Bonnes pratiques

Le paramétrage des journaux proposés doit être adapté au besoin de

l’organisation et ne doit pas se limiter au paramétrage standard.

 Est-ce que les dispositifs sont mis à jour périodiquement pour prendre en
compte l’évolution des risques et des besoins d’intégrité?
Commentaires :

Les évolutions des risques et les changements en matière de besoins de sécurité

sont à évaluer périodiquement.

Risques :

82
  Accès non autorisé ou frauduleux.
 Perte de traçabilité.
 Altération ou perte d’intégrité des données.
Preuves à demander :

 Documentation de l’évolution du dispositif.

Bonnes pratiques

Une mise à jour annuelle est un minimum.

 Est-ce que la mise en œuvre des dispositifs et leur efficacité sont

régulièrement contrôlées?
Commentaires :

Ces contrôles sont effectués par les équipes opérationnelles et leur management,
et les actions de correction nécessaires sont entreprises.

Risques :

 Accès non autorisé ou frauduleux.

 Perte de traçabilité.
 Altération ou perte d’intégrité des données.
Preuves à demander :

 Justificatifs de l’organisation et de la réalisation de ces contrôles, ainsi que

des éventuels plans d’actions.
Bonnes pratiques

 La périodicité des contrôles est établie en fonction des niveaux de

criticité.
 Quel que soit le niveau, une évaluation annuelle peut être considérée
comme une bonne pratique.
 Est-ce que l’intégrité des journaux de modification de données est assurée ?
Commentaires :

83
 Les actions exécutées par tout utilisateur avec des droits étendus (administrateur)
sont consignées.

Risques :

 Accès non autorisé ou frauduleux.

 Perte de traçabilité.
 Altération ou perte d’intégrité des données.
Preuves à demander :

• Vérification de l’existence d’un dispositif de sécurisation des journaux.

Bonnes pratiques

Un enregistrement des journaux sur un serveur distinct sécurisé est réalisé pour
éviter la possibilité de modification par un utilisateur ayant des droits étendus
sur le serveur d’origine.

II.4.4.5. Etape 5: Vérifier si l’organisation a mis en place les dispositifs pour

respecter la réglementation en matière de données personnelles

 Est-ce que la réglementation en matière de protection des données

personnelles hébergées par le SI est connue ?
Commentaires :

Les obligations touchent notamment à la déclaration, l’acceptation, la mise à

disposition, la conservation en ce qui concerne les données et aux différentes
procédures associées à mettre en œuvre (déclaration d’incidents, évaluation des
dispositifs).

Risques :

 Non-respect des exigences réglementaires ou légales.

Preuves à demander :

 Une organisation est en place pour suivre les évolutions de la

réglementation en matière de données personnelles.

84
 Bonnes pratiques

 Il existe dans l’organisation un correspondant informatique et liberté ou

un Délégué à la protection des données personnelles.

 Est-ce que la réglementation en matière de protection des données

personnelles hébergées par le SI est appliquée ?
Commentaires :

Les différentes obligations touchent notamment à la Déclaration, l’Acceptation,

la Mise à disposition, la Conservation en ce qui concerne les données et aux
différentes procédures associées à mettre en œuvre (déclaration d’incidents,
évaluation des dispositifs).

Risques :

 Non-respect règlementaire ou légal.

Preuves à demander :

 Déclaration de fichiers et de traitements.

 Procédures de gestion documentées y compris les modalités d’information
des personnes faisant l’objet de traitement de données à caractère
personnel et les dispositions mise en œuvre pour leur permettre d’exercer
leur droit (opposition, rectification).
Bonnes pratiques

RAS

 Est-ce que le respect de la réglementation en matière de protection des

données personnelles hébergées par le SI est vérifié ?
Commentaires :

Ces contrôles sont effectués par des équipes internes pour s’assurer de la mise en
œuvre des dispositifs permettant le respect de la règlementation. Les actions de
correction nécessaires sont entreprises.

Risques :
85
  Non-respect règlementaire ou légal.
Preuves à demander :

 Justificatifs de l’organisation, de la réalisation de ces contrôles et des

éventuels plans d’actions.
Bonnes pratiques

 Les traitements de données à caractère personnel sont listés de manière

exhaustive et de manière informatisée.

II.4.5. Techniques, outils, référentiels ou normes à utiliser pour un

audit des processus

- ISO 27001

L'ISO/CEI 27001 est une norme internationale de système de gestion de la sécurité de

l'information de l'ISO et la CEI. Publiée en octobre 2005 et révisée en 2013, son titre
est "Technologies de l'information - Techniques de sécurité - Systèmes de gestion de
sécurité de l'information - Exigences". Elle fait partie de la suite ISO/CEI 27000.

La norme ISO/CEI 27001 décrit les exigences pour la mise en place d'un Système
de Management de la Sécurité de l'Information (SMSI). Le SMSI recense les mesures
de sécurité, dans un périmètre défini, afin de garantir la protection des actifs
informationnels. L’objectif est de protéger les informations de toute perte, vol ou
altération, et les systèmes informatiques de toute intrusion. Cela apportera la confiance
des parties prenantes.

- COBIT

Le CobiT (Control Objectives for Information and related Technology, en

français Objectifs de contrôle de l’Information et des Technologies Associées) est un
outil fédérateur qui permet d'instaurer un langage commun pour parler de
la gouvernance des systèmes d'information tout en tentant d'intégrer d'autres référentiels
tels que ISO 9000, ITIL, etc.

86
La version 5 de CobiT est disponible depuis avril 2012. CobiT 5 est, à ce jour, le seul
référentiel qui est orienté business pour la Gouvernance et la Gestion des Systèmes
d’Information de l’entreprise. Il représente une évolution majeure du référentiel. CobiT
5 peut être adapté pour tous les types de modèles business, d’environnements
technologiques, toutes les industries, les lieux géographiques et les cultures d’entreprise.
Il peut s’appliquer à :

- La sécurité de l’information
- La gestion des risques
- La gouvernance et la gestion du Système d’Information de l’entreprise
- Les activités d’audit
- La conformité avec la législation et la règlementation
- Les opérations financières ou les rapports sur la responsabilité sociale
de l’entreprise

Le référentiel CobiT 5 simplifie les défis de la gouvernance avec seulement 5

principes et sept facilitateurs. Il permet l’intégration avec d’autres approches et normes,
incluant TOGAF, PMBOK, Prince2, COSO, ISO 20000, ISO 27001, ITIL, PCI
DSS, Sarbanes-Oxley et Bâle III.

- COSO

Les trois objectifs du COSO définissent le contrôle interne comme un processus mis
en œuvre par les dirigeants à tous les niveaux de l’entreprise et destiné à fournir une
assurance raisonnable quant à la réalisation des trois objectifs suivants :

- la réalisation et l'optimisation des opérations,

- la fiabilité des informations financières,

- la conformité aux lois et règlements.

Les cinq composants Les cinq composants ont pour objectif l’amélioration du
système du contrôle interne de l’organisation et ils sont interconnectés.

Il s’agit de :

87
 - l'environnement de contrôle,

- l'évaluation des risques,

- les activités de contrôle,

- l'information et la communication, qu'il s'agit d'optimiser,

- la surveillance, c'est-à-dire le « contrôle du contrôle » interne.

- ITIL (Gestion de la sécurité)

La gestion de la sécurité est impliquée dans tous les processus où les questions de
sécurité apparaissent. De telles questions touchent à la confidentialité, l’intégrité et la
disponibilité des données, aussi bien qu’à la sécurité des matériels et des composants de
logiciel, à la documentation et aux procédures. À ce titre, elle est présente dans la gestion
de la disponibilité et de la continuité de service pour valider les menaces sur la
disponibilité du service. Elle est également présente dans la gestion des changements et
la gestion des mises en production pour valider qu’une demande de changement ou
qu’une installation n’a pas d’impact sur la sécurité du système d’information.

88
 II.5. Audit des Logiciel

Figure 18 : Zoom sur l’audit des applications

II.5.1. Définition application

Dans le domaine informatique, est un programme (ou un ensemble logiciel)

directement utilisé par l'utilisateur pour réaliser une tâche, ou un ensemble de tâches
élémentaires d'un même domaine ou formant un tout. Typiquement, un éditeur de
texte, un navigateur web, un lecteur multimédia, un jeu vidéo, sont des applications.

II.5.2. Pourquoi l’audit des applications

Il est important pour toute entreprise de maitriser le fonctionnement de son système

d’information et d’en connaitre les forces, faiblesses les risques auxquels il est soumis
et les menaces qui le guettent. L’audit des applications vient donc dans ce sillage être
un autre moyen d’appréciation du système d’information afin d’évaluer les écarts entre
production et consommation et permettre à l’entreprise de se réajuster si besoin se
présente.

89
 II.5.3. Quand fait-on l’audit des applications ?

L’audit se fait après deux ou trois ans et selon les besoins des dirigeants
d’entreprises

Bon à savoir : Quelques questions à se poser

- Quels sont les critères permettant d’identifier une application bonne ou

critique développée ?
- Quels sont les risques inhérents à l’utilisation de telles applications ?
Comment gérer le manque de traçabilité et sécurité liés à ce type d’application
? Comment faire face aux obligations légales et règlementaires en utilisant ce
type d’application ?
- Pour chacune des applications identifiées, quel est l’impact pour
l’organisation en cas de perte d’intégrité des données, quelle est sa fréquence
d’utilisation, combien de personnes l’utilisent ?
- Pourquoi ces applications ne sont pas embarquées dans le système
d’information de l’organisation ? Dans quelle mesure, l’audit peut-il
intervenir dans la mise en place de standards de développement pour ce type
d’application ?
- Le cas échéant, comment faire entrer ces applications dans le droit commun
de la production informatique en entreprise (qualification du niveau de
sécurité, sauvegarde et archivage, et, surtout, identification des personnes clés
car bien souvent ces applications ne sont maîtrisées que un petit nombre
personne) ?

II.5.4. Démarche d’évaluation de logiciels

Etape 1 : Historique et insertion de l’application dans l’architecture globale

Etape 2 : Couverture fonctionnelle

Etape 3 : Schéma des traitements et matrice de contrôle

Etape 4 : Identification des risques

90
Etape 5 : Approfondissement des risques identifiés

Etape 6 : Analyse des aspects « qualitatifs »

II.5.4.1. Etape 1: Analyse de l’historique et de l’insertion de l’application

dans l’architecture globale

 Historique de l’application

 prise de connaissance des interventions précédentes

Remarque : on peut demander à des collègues qui ont des expériences sur le
logiciel pour savoir des difficultés qu’on rencontre souvent, etc.

 gestion du projet

Remarque : « accouchement difficile » ? Passage sans difficultés ?

 développement interne / externe

 cahier des charges

 maîtrise de l’existant-notion de "boîte noire"

Remarque : est-ce que le client a suffisamment d’informations pour maitriser

le logiciel ?

 gestion des évolutions

 Insertion de l’application dans l’architecture globale

 établir un schéma d’intégration global

II.5.4.2. Etape 2: Analyse de la couverture fonctionnelle

 Liste des fonctionnalités

Remarque : il peut qu’en fonction de l’activité de l’entreprise, elle retient de

telles fonctionnalités, mais pas d’autres.
91
 Schémas des traitements

Remarque : par ce schéma, on essaie de savoir comment initialiser, enregistrer

(par qui, comment), traiter (de quelle manière : séquentielle, continue, etc.),
valider et contrôler.

 Revue des documentations (utilisation, conception, exploitation)

Remarque : À partir du manuel d’utilisation, il faut intégrer la formation

d’utilisation.

 Identification des utilisateurs

Remarque : informaticiens, MOA, contrôleur d’accès, les stagiaires, etc.

 Identification des informaticiens

II.5.4.3. Etape 3 : Analyse du schéma des traitements et élaboration d’une

matrice de contrôle

La démarche à suivre est la suivante :

 découpage de l'application en phases logiques de traitement

 élaboration d'un schéma de flux sur lequel sont présentés :

 les phases logiques de traitement

 les principaux fichiers ou tables concernées

 pour chaque phase logique, établissement d'une matrice de contrôle

comprenant :

 les informations reprises du schéma de flux (phase logique de traitement, entrées,

fichiers de référence, sorties)

 la description du traitement effectué

 la liste des contrôles programmés ou d'exploitation et les objectifs des contrôles

92
  la liste des contrôles effectués par les utilisateurs sur la base des restitutions
disponibles et les objectifs des contrôles opérés

II.5.4.4. Etape 4 : Identification des risques

Fiabilité des interfaces

 les contrôles effectués

 les procédures de recyclage des rejets (ou anomalies)

 la nature et la fréquence des rejets

Contrôle interne applicatif

 le contrôle interne applicatif ne diffère en rien du contrôle interne manuel

 il se décline de la manière suivante :

 autorisation : toutes les transactions, font-elles l'objet d’une autorisation en

accord avec la politique de délégation (contrôle d’accès et séparation des
fonctions))?

 Exhaustivité : les données entrées dans l'application sont-elles bien disponibles

dans les bases de données?

o Absence de perte de données aux différents niveaux de traitement?

o Existence de contrôle de flux?

 exactitude :

o L'application permet-elle de garantir la non altération des données ?

o Existe-t-il des contrôles de valorisation (tests en production, requêtes,

simulation)?

Paramétrage

 identification des tables

 procédures et fréquences des mises à jour

93
 vérification du code (séparation données/traitements)

 personnes concernées.

Pour apprécier si une application est "facile à exploiter", il convient d'étudier :

 les fiches d’incidents tenus par l'exploitation informatique et/ou par les utilisateurs

 le dossier d'exploitation de l'application pour apprécier l'existence de points de

reprise en cas d'incident

 les procédures utilisateurs pour le recyclage des anomalies

 le planning d'exploitation pour apprécier si une attention particulière est donnée à

l'application

II.5.4.5. Etape 5 : approfondissement des risques identifiés

 Procédures palliatives
 contrôles par les utilisateurs
 existence d'une cellule de pilotage et de contrôle des données produites
 proposer la mise en œuvre de contrôles complémentaires
 Mise en place éventuelle de tests informatiques ciblés
 identification des risques
 réalisation d’un cahier des charges
 mise en place des tests
Remarque : distinguer les anomalies intrinsèques ou les anomalies engendrées
par la mauvaise construction ou interprétation des tests.
 réunion de synthèse

II.5.4.6. Etape 6 : Analyse des aspects « qualitatifs »

 L'adéquation fonctionnelle
 La satisfaction des utilisateurs
 L'évolutivité

94
 Le bilan économique
 Les performances

L'adéquation fonctionnelle
Étude des points suivants :
 implication des utilisateurs dans les choix et/ou développements informatiques
 cohérence et stabilité de la demande exprimée : collecter les demandes de mise à jour
de l'application
 apprécier la fréquence de maintenance corrective sur l'application
 vérifier que les restitutions produites par l'application sont effectivement utilisées
 apprécier si les retraitements ou remaniements manuels d'informations issues de
l'application ne pourraient pas être informatisés
Remarques : plus l’entreprise est grosse, plus on a des traitements manuels pour
remonter les informations, plus on a des incertitudes sur l’exactitude et l’exhaustivité
des informations.

La satisfaction des utilisateurs

Par entretien avec les utilisateurs, obtenir les motifs d'insatisfaction éventuels, ils
pourront résulter :
 d’un manque de communication entre utilisateurs et informaticiens
 de retard dans les travaux de maintenance évolutive ou corrective
 d’un manque de formation des utilisateurs
 de contraintes techniques

L'évolutivité
La capacité d'une application à évoluer selon les souhaits de l'entreprise se mesure
suivant les critères suivants :
 qualité de la programmation
 pertinence des choix techniques
 qualité de la documentation

95
 pertinence de l'analyse fonctionnelle
 externalisation du paramétrage

Le bilan économique
L'établissement d'un bilan économique nécessite l'étude des points suivants :
 le coût réel d'acquisition ou de développement et de mise en place de l'application /
coût prévu au plan informatique
 le coût de l'application développée ou acquise par rapport à des progiciels
équivalents du marché
 les gains de productivité
 le coût de fonctionnement
 les coûts de maintenance

Les performances
Les performances d'une application peuvent s'apprécier selon les points de contrôle
suivants :
 fréquence de réorganisation des bases de données ou fichiers accédés par
l'application
 reporting sur le délai moyen de restitution des réponses attendues et évolution dans
le temps
 fréquence et nombre de passages batch sur de gros volumes de fichiers séquentiels
 interactions entre applications

Exemple :
Audit d’une application de comptage et de facturation
Etapes de traitement :
 "contrôle syntaxique" :
o contrôle de présence des informations nécessaires à la valorisation
 " contrôle logique" :
o éclatement des événements unitaires selon leur nature

96
 rapprochement au contrat et valorisation
 prise en compte des produits (services inclus dans le contrat) et des acomptes
 facturation :
o des consommations
o des abonnements
o des PFA (Produits Facturés à l'Acte)
 calcul de la facture
 calcul des lignes de chiffre d’affaires et des écritures de cut-off

Risques étudiés :
 exhaustivité de la remontée ?
o Existe-t-il des contrôles de l'exhaustivité de la prise en compte de l'ensemble
des bandes magnétiques remontant de compteurs ?
o En l'absence de numérotation des événements unitaires, peut-on s'assurer de
l'exhaustivité de la présence de ces derniers ?
 exhaustivité du recyclage ?
o deux faiblesses recensées :
o perte de quelques tickets en anomalie de type 'I'
o non recyclage des anomalies de type 'W'
 exhaustivité du traitement des lots de facturation ?
o Absence de vérification par tests programmés
 exhaustivité de la facturation des contrats ?
o Absence de vérification par tests programmés
 Unicité du numéro de facture ?
o non séquentialité des numéros de facture
o l'unicité du couple contrat-numéro de facture dépend de l'unicité des numéros
de contrat

Risques financiers identifiés :

 exhaustivité de la facturation des ventes ?
o manque de fiabilité des compteurs d'événements unitaires
97
 comptabilisation des prestations ?
o existence de contrats ayant un plan tarifaire nul
Rq : comment traiter les contrats ayant une valeur nulle ?
 valorisation des prestations ?
o utilisation du coût minimum en cas d'anomalie
 diminution non justifiée du compte client ?
o émission de 500 KF d'avoirs chaque mois
Rq : il faut vérifier que soient bien justifiés les avoirs qui sont une source de
fraude
o à valider à partir des tests effectués
 cut-off
o non respecté en cas de retard dans la remontée des tickets
Rq : on vérifie le délai entre la date de ticket et la date de facturation.
 provision pour dépréciation des clients mal calculée
o reste à valider à partir des tests effectués

a) Autres méthodologies :
- INFAUDITOR
La méthodologie Infauditor comprend une arborescence d’évaluation basée sur
des domaines, des sous-domaines et des critères d’évaluation. Par exemple la sécurité
d’une application pourra être découpé en plusieurs critères d’évaluation : contrôles des
entrées ; contrôles des sorties ; contrôles des processus.
L’avantage est qu’elle permet d’aborder l’analyse de façon structurée. De plus, elle peut
être adaptée aisément à des domaines particuliers ou à des situations spécifiques, soit en
aménageant l’arborescence, soit en modifiant les poids.

98
 Audit
d’une
application

0.2 0.2 0.2 0.05 0.05 0.1 0.1 0.1

Adéquation Documen- Maintena-
Sécurité Fiabilité Cohérence Performance Rentabilité
aux besoins tation bilité

0.2 0.2 0.2 0.1 0.1 0.1 0.1

Degré de Atteinte des Procédures Adéquation Performance Degré d’obso-
Convivialité
satisfaction objectifs parallèles documentation Du service lescence

Figure 19 : Arborescence de INFAUDITOR

Cette méthodologie consiste à générer l’arborescence d’audit, c’est-à-dire l’ensemble

des nœuds des domaines retenus. Pour permettre une évaluation globale, chaque nœud
de cette arborescence est affecté d’un poids. La note d’évaluation d’un nœud, par
exemple la sécurité physique d’un système d’information, résulte de la somme pondérée
des notes calculées lors de l’évaluation de chacun des sous-domaines de la sécurité
physique. Au niveau élémentaire, c’est l’auditeur qui, au vu des résultats du test d’audit,
affecte une note et une appréciation au nœud terminal correspondant. Un exemple partiel
d’arborescence est donné figure 1. A chaque niveau, un seul nœud est déployé. Les
valeurs numériques figurant sur les arcs sont les poids de chaque nœud dans l’évaluation
de leur nœud parent.

- La norme CNCC (Compagnie Nationale des Commissaires aux

Comptes)

La description de l’orientation et planification de la mission d’audit en entreprise

consiste à :

 formaliser la cartographie des applications,

 apprécier le degré de complexité du système d’information liée aux applications
 identifier les processus à analyser, utiles aux objectifs de l’audit.

- Cartographie générale des applications du système d’information

99
Objectif

La réalisation d’une cartographie générale des applications permet de

comprendre et de documenter les composantes du système d’information. Elle permet
en outre de mettre en évidence les risques potentiels liés à cette architecture.

b) Travaux à réaliser

L’établissement de la cartographie du système d’information nécessite l’identification

des principales applications et interfaces.

c) Identification des principales applications informatiques

L’identification des applications informatiques concerne le recensement des

applications qui composent le système d’information de l’entreprise. Pour chacune
d’elles, il est nécessaire de connaître :

- le type (progiciel avec indication de l’éditeur/développement spécifique),

- la date de mise en place,
- l’environnement technique : UNIX, Windows, AS400...,
- le mode de traitement (différé ou temps réel),
- le nom de l’éditeur ou du prestataire,
- la date de la dernière modification,
- les principales fonctionnalités,
- la nature des sorties,
- une estimation du volume traité.

d) Identification des principales interfaces

L’identification des principales interfaces concerne les liens qui existent entre les
différentes applications. Ces liens peuvent être automatiques, semi-automatiques ou
manuels. Pour chaque interface identifiée, il est nécessaire de connaître :

- le type d’interface : automatique, semi-automatique, manuel,

100
 - les applications en amont / en aval,
- la nature des flux : ventes, stocks, clients,
- la fréquence : quotidienne, hebdomadaire, mensuelle,
- les états d’anomalies.

e) Résultat

La représentation graphique des différentes applications et des liens existant entre

elles constitue la cartographie générale des applications. Elle permet de visualiser de
façon synthétique un système d’information complexe et sert en outre de support de
communication pluridisciplinaire (culture comptable, culture informatique) dans
l’identification des risques potentiels.

Pour les systèmes très simples (2 à 3 applications), la cartographie pourra se limiter à la

formalisation de tableaux d’inventaire établis par le commissaire aux comptes, alors que
pour les systèmes d’information très complexes, l’intervention d’un expert informatique
peut être nécessaire.

La cartographie des applications peut être complétée avec une description de

l’infrastructure technique : matériels et réseaux.

f) Appréciation de la complexité du système d’information liée aux

applications
- Objectif

La complexité du système d’information est un élément important à prendre en

compte lors de l’établissement du plan de mission. Son appréciation permet de décider
si des compétences informatiques particulières sont nécessaires pour réaliser la mission
et s’il convient que le commissaire aux comptes se fasse assister d’un expert.

- Travaux à réaliser

101
 L’appréciation de la complexité du système d’information concerne l’ensemble des
applications et s’effectue au travers de l’analyse de la cartographie en prenant en
compte les critères suivants :

 existence de progiciel intégré ou de nombreuses applications spécifiques,

 technologie utilisée : système central, client-serveur, Internet,
 paramétrage : complexité, étendue, paramètres standards ou définis par
l’entreprise,
 nombre d’interfaces,
 existence d’interfaces manuelles entre les systèmes,
 dépendance des traitements entre les systèmes.

- Modalités pratiques

La complexité du système d’information de l’entreprise va pouvoir être appréciée à

partir de la cartographie réalisée précédemment et de la documentation fournie (cette
dernière n’a pas d’incidence sur la complexité du système, mais son existence et sa
qualité permettent une analyse plus fine).

Cette étude peut être complétée par un entretien avec le responsable informatique
pour couvrir les points suivants :

 existence ou non d’une documentation,

 degré de mise à jour de la documentation en fonction des évolutions du
système d’information,
 dépendance des traitements entre les systèmes.

NB : L’analyse des applications du système d’information de l’entreprise dans le plan

de mission peut conduit à déterminer des situations où le risque sur la fiabilité du
système d’information sera plus ou moins important.

102
 II.5.5. Techniques, outils, référentiels ou normes à utiliser pour un audit
des applications

Un référentiel d’audit correspond à un recueil de règles, procédures et/ou bonnes

pratiques reconnues au plan international et sur lequel l’auditeur pourra s’appuyer pour
formuler ses recommandations. Dans le domaine de l’informatique, il en existe
notamment deux qui sont particulièrement utilises dans l’audit des applications, à savoir
COBIT, la norme ISO 9126 et norme SquaRE [ISO05] définie depuis 2005 est la norme
qui succède au standard ISO 9126. Elle a été définie à partir d’ISO 9126 et de la partie
évaluation de la norme ISO 14598..

Le référentiel Cobit est le plus utilisé dans le cadre de l’audit des système
d’informations. Dans le cadre précis de ce travail à savoir l’audit du logiciel nous avons
identifié à partir du référentiel Cobit les processus suivants se rapportant au logiciel :

 PO1.1 Gestion de la valeur des SI

 PO3.1 Planification de l’orientation technologique
 PO3.3 Surveillance de l’évolution des tendances et de la réglementation
 PO4.15 Relations
 AI5.3 Choix des fournisseurs
 DS1.1 Référentiel pour la gestion des niveaux de services
 DS1.3 Contrats ou conventions de services (CS)
 DS2.3 Gestion du risque fournisseurs
 DS2.4 Surveillance des performances fournisseurs
 PO5.1 Référentiel de gestion financière
 PO6.3 Gestion des politiques informatiques
 PO7.2 Compétences du personnel
 PO7.4 Formation
 AI2.6 Mises à jour majeures des systèmes existants
 AI4.3 Transfert de connaissances aux utilisateurs finaux
 AI7.1 Formation
 DS7.1 Identification des besoins en savoir et en formation
 O7.4 Formation

103
  DS7.2 Fourniture de formation et d’enseignement
 DS7.3 Évaluation de la formation reçue
 AI3.3 Maintenance de l’infrastructure

La norme ISO/CEI 9126 définit un langage commun pour modéliser les qualités d'un
logiciel. La norme ISO 9126, "Technologies de l’Information : Qualités des produits
logiciels", définit et décrit une série de caractéristiques qualité d’un produit logiciel
(caractéristiques internes et externes, caractéristiques à l’utilisation) qui peuvent être
utilisées pour spécifier les exigences fonctionnelles et non fonctionnelles des clients et
des utilisateurs.

Chaque caractéristique est détaillée en sous-caractéristique, et pour chacune d’elle, la

norme propose une série de mesures à mettre en place pour évaluer la conformité du
produit développé par rapport aux exigences formulées.

Figure 20 : Le système SquaRE

Le système SquaRE décrit deux modèles distincts. Un modèle de qualité lié à

l’utilisation du logiciel et un modèle de qualité propre à la production logicielle. Nous
nous intéresserons ici uniquement à ce dernier. Suivant le même principe que la norme
ISO 9126, le modèle est constitué de huit caractéristiques, décomposées en sous
caractéristiques :

104
 Figure 21 : Qualité d’un logiciel

L'ensemble des outils logiciels utilisables dans les phases d’audit constitue les
CAATs (techniques d’audit assisté par ordinateur ou « computer assisted audit
techniques »).

L'auditeur a à sa disposition tout un ensemble d'outils informatiques a chaque phase de

mission

TYPES D’OUTILS UTILISATION

Générateur de données de tests Préparation automatique des fichiers de tests
Livrés avec les systèmes d’exploitation, pour extraction/fusion
Utilitaires standards
de fichiers, tris de données, etc.
Logiciels de gestion des Logiciels vérifiant l’intégrité et la pertinence des modifications
changements de programmes.
SCARF (systems control audit Consiste à introduire des logiciels d'audit écrits spécialement à
review file) et EAM (embedded l'intérieur du système d'applications de l'entreprise, de sorte que
audit modules) les systèmes applicatifs soient "pilotés" de manière sélective.
Consiste à prendre des images tout au long du "chemin de
traitement" (processing path) suivi par une transaction. On
SNAPSHOT
enregistre les évolutions de données sélectionnées, pour une
révision ultérieure pratiquée par l'auditeur.
Parties de logiciels embarqués sur des systèmes applicatifs, pour
AUDIT HOOKS
fonctionner comme des drapeaux rouges. Ils doivent permettre à

105
 l'auditeur d'agir avant qu'une erreur ou une irrégularité ne soient
allées trop loin.
Cette technique consiste à introduire des entités fictives dans les
fichiers de production. L'auditeur peut demander au système de
ITF (integrated test facilities) travailler soit avec les programmes de production, soit avec les
programmes de test, afin que les programmes mettent à jour les
entités fictives.
Le système déclenche une simulation d'exécution d'instructions
CIS (continuous and de l'application, afin de s'assurer de la fiabilité de la transaction.
intermittent Le déclenchement est fait sur certains critères prédéterminés
simulation) (montant ou autre). Sinon le simulateur attend jusqu'à la
prochaine transaction qui présentera les critères voulus.

Tableau 3 : référentiels, normes et outils à utiliser pour l’audit logiciel

106
 II.6. Audit de la sécurité du Système d’information

Figure 22 : Zoom sur l’audit de la sécurité

II.6.1. Définition de l’audit de la SSI

En informatique, le terme « Audit (ou écoute) » est apparu dans les années 70 et
a été utilisé de manière relativement aléatoire. Nous considérons par la suite un "audit
sécurité de l’information" comme une mission d'évaluation de conformité par rapport
à une politique de sécurité ou à défaut par rapport à un ensemble de règles de sécurité.

Une mission d'audit ne peut ainsi être réalisée que si l'on a défini auparavant un
référentiel, c'est-à-dire en l'occurrence, un ensemble de règles organisationnelles,
procédurales ou/et techniques de référence. Ce référentiel permet au cours de l'audit
d'évaluer le niveau de sécurité réel du " terrain " par rapport à une cible.

Pour évaluer le niveau de conformité, ce référentiel doit être :

 Complet (mesurer l'ensemble des caractéristiques : il ne doit pas s'arrêter au

niveau système, réseau, télécoms ou applicatif, de manière exclusive, de même,
il doit couvrir des points techniques et organisationnels) ;
 Homogène : chaque caractéristique mesurée doit présenter un poids cohérent
avec le tout ;

107
  Pragmatique : c'est-à-dire, aisé à quantifier (qualifier) et à contrôler. Ce dernier
point est souvent négligé.

II.6.2. Pourquoi l’audit de la sécurité des systèmes d’information ?

La nécessité d’un audit de la SSI est liée aux risques de sécurité informatique
issus de la mise en place d’un système d’information. En ce qui concerne l’analyse de
risque, on a défini 12 types de menaces.

- Accidents physiques ;
- Malveillance physique ;
- Panne du SI ;
- Carence de personnel, …

II.6.3. Quand faut-il faire un audit de la sécurité des systèmes

d’information ?

La mise en place d’un audit des SI dépend de la politique de sécurité et de la gestion

des risques au sein de l’entreprise.

La politique de sécurité doit prévoir un schéma organisationnel de sécurité, s’appuyer

sur des normes, des processus, des personnes et combiner plusieurs outils. Parmi les
moyens employés, on peut citer :

- la protection par les règles (classifier l’information) ;

- la protection par les outils (chiffrement) ;
- la protection par les contrats (clauses, obligations, SLA), …

108
Figure 23 : éléments utilisés dans la sécurité

Figure 24 : outils utilisés

109
 a) Quelques recommandations

Sans nécessairement considérer cela comme un guide des bonnes pratiques, on peut
d’ores et déjà extraire des réunions du groupe sécurité du Cigref un certain nombre de
grands principes :

- le principe de précaution ;
- le principe de coopération ;
- le principe d’économie ;
- le principe de séparation des pouvoirs.

On peut également formule un certain nombre de recommandations :

- la désignation de « propriétaires » métiers de l’information ;

- la délégation des droits ;
- le développement de moyens de surveillance, …

L’OCDE a rendu public en juillet 2002 ses nouvelles lignes directrices en matière de
sécurité des systèmes d’information. Ce document constitue une réactualisation des
travaux de 1992. L’organisation a identifié neuf principes fondamentaux en matière de
sécurité :

- sensibilisation ;
- responsabilité ;
- réaction ;
- éthique ;
- démocratie, …

b) L’importance de la sensibilisation

La sécurité est d’autant plus efficace qu’elle est « admise », « diffuse » et par
l’ensemble des acteurs de l’entreprise. L’utilisateur, le client, l’administrateur sont tous
potentiellement à des degrés divers les « maillons faibles » du système d’information.

110
 Figure 25 : quels outils utilisés-vous pour sensibiliser les employés

II.6.4. Démarche de l’audit de la SSI

Dans la section précédente on a évoqué les principales étapes de l’audit de

sécurité des systèmes d’information. Cependant il existe une phase tout aussi importante
qui est une phase de préparation. Nous pouvons schématiser l’ensemble du processus
d’audit comme suite :

111
 Figure 26 : schéma du processus d’audit de la sécurité des SI

II.6.4.1. Etape 1 : Définition de la Charte d’audit

Avant de procéder à une mission audit, une charte d'audit doit être réalisée, elle a pour
objet de définir la fonction de l'audit, les limites et modalités de son intervention, ses
responsabilités ainsi que les principes régissant les relations entre les auditeurs et les
audités. Elle fixe également les qualités professionnelles et morales requises des
auditeurs.

II.6.4.2. Etape 2 : Préparation de l’audit

Cette phase est aussi appelée phase de pré audit. Elle constitue une phase importante
pour la réalisation de l’audit sur terrain. En effet, c’est au cours de cette phase que se
dessinent les grands axes qui devront être suivis lors de l’audit sur le terrain. Elle se
manifeste par des rencontres entre auditeurs et responsables de l’organisme à auditer.
Au cours de ces entretiens, les espérances des responsables vis-à-vis de l’audit devront
être exprimées. Aussi, le planning de réalisation de la mission de l’audit doit être fixé.

Les personnes qui seront amenées à répondre au questionnaire concernant l’audit

organisationnel doivent être également identifiées. L’auditeur (ou les auditeurs) pourrait

112
également solliciter les résultats des précédents audits. Cette phase sera suivie par l’audit
organisationnel et physique.

En synthèse on peut dire que cette étape permet de :

 Définir un référentiel de sécurité (dépend des exigences et attentes des

responsables du site audité, type d’audit) ;
 Elaboration d’un questionnaire d’audit sécurité à partir du référentiel et des
objectifs de la mission ;
 Planification des entretiens et informations de personnes impliquées.

II.6.4.3. Etape 3 : Audit organisationnel et physique

a) Objectifs :
Dans cette étape, il s’agit de s’intéresser à l’aspect physique et organisationnel
de l’organisme cible, à auditer. Nous nous intéressons donc aux aspects de
gestion et d’organisation de la sécurité, sur les plans organisationnels, humains
et physiques.
L’objectif visé par cette étape est donc d’avoir une vue globale de l´état de
sécurité du système d´information et d´identifier les risques potentiels sur le plan
organisationnel.

b) Déroulement :
Afin de réaliser cette étape de l’audit, ce volet doit suivre une approche
méthodologique qui s’appuie sur « une batterie de questions ». Ce questionnaire
préétabli devra tenir compte et s’adapter aux réalités de l’organisme à auditer. A
l’issu de ce questionnaire, et suivant une métrique, l’auditeur est en mesure
d’évaluer les failles et d’apprécier le niveau de maturité en termes de sécurité de
l’organisme, ainsi que la conformité de cet organisme par rapport à la norme
référentielle de l’audit.

113
 II.6.4.4. Etape 4 : Audit technique

a) Objectifs :
Cette étape de l’audit sur terrain vient en seconde position après celle de l’audit
organisationnel. L’audit technique est réalisé suivant une approche méthodique
allant de la découverte et la reconnaissance du réseau audité jusqu’au sondage
des services réseaux actifs et vulnérables.
Cette analyse devra faire apparaître les failles et les risques, les conséquences
d’intrusions ou de manipulations illicites de données. Au cours de cette phase,
l’auditeur pourra également apprécier l’écart avec les réponses obtenues lors des
entretiens. Il testera aussi la robustesse de la sécurité du système d’information
et sa capacité à préserver les aspects de confidentialité, d’intégrité, de
disponibilité et d’autorisation.
Cependant, l’auditeur doit veiller à ce que les tests réalisés ne mettent pas en
cause la continuité de service du système audité.

b) Déroulement :
Vu les objectifs escomptés lors de cette étape, leurs aboutissements ne sont
possibles que par l’utilisation de différents outils. Chaque outil commercial qui
devra être utilisé, doit bénéficier d’une licence d’utilisation en bonne et due
forme.
Egalement les outils disponibles dans le monde du logiciel libre sont admis.
L’ensemble des outils utilisés doit couvrir entièrement ou partiellement la liste
non exhaustive des catégories ci-après :
 Outils de sondage et de reconnaissance du réseau ;
 Outils de test automatique de vulnérabilités du réseau ;
 Outils spécialisés dans l’audit des équipements réseau (routeurs, switchs).
 Outils spécialisés dans l’audit des systèmes d’exploitation ;
 Outils d’analyse et d’interception de flux réseaux ;
 Outils de test de la solidité des objets d’authentification (fichiers de mots
clés) ;

114
  Outils de test de la solidité des outils de sécurité réseau (firewalls, IDS,
outils d’authentification) ;
 Outils de scanne d’existence de connexions dial-up dangereuses
(wardialing) ;
 Outils spécialisés dans l’audit des SGBD existants.
Chacun des outils à utiliser devra faire l’objet d’une présentation de leurs
caractéristiques et fonctionnalités aux responsables de l’organisme audité pour
les assurer de l’utilisation de ces outils.

Les principales phases sont donc :

Phase 1 : Audit de l’architecture du système
 Reconnaissance du réseau et de plan d’adressage ;
 Sondage des systèmes ;
 Sondage réseau ;
 Audit des applications.
Phase 2 : Analyse des vulnérabilités
 Analyse des vulnérabilités des serveurs en exploitation ;
 Analyse des vulnérabilités des postes de travail.
Phase 3 : Audit de l’architecture de sécurité existante
Cette phase couvre entièrement/partiellement la liste ci après :
 Audit des firewalls et des règles de filtrage ;
 Audit des routeurs et des ACLs (Liste de contrôle d’accès) ;
 Audit des sondes et des passerelles antivirales ;
 Audit des stations proxy ;
 Audit des serveurs DNS, d’authentification ;
 Audit des commutateurs ;
 Audit de la politique d’usage de mots de passe.

115
 II.6.4.5. Etape 5 : Tests d’intrusion

a) Objectifs :
Cet audit permet d’apprécier le comportement du réseau face à des attaques.
Egalement, il permet de sensibiliser les acteurs (management, équipe
informatique sur site, les utilisateurs) par des rapports illustrant les failles
décelées, les tests qui ont été effectués (scénarios et outils) ainsi que les
recommandations pour pallier aux insuffisances identifiées.

b) Déroulement :
La phase de déroulement de cet audit doit être réalisée par une équipe de
personnes ignorante du système audité avec une définition précise des limites et
horaires des tests. Etant donné l’aspect risqué (pour la continuité des services du
système d’information) que porte ce type d’audit, l’auditeur doit.
 Bénéficier de grandes compétences ;
 Adhérer á une charte déontologique ;
 S’engager (la charte d’audit) à un non débordement: implication à ne pas
provoquer de perturbation du fonctionnement du système, ni de
provocation de dommages.

II.6.4.6. Etape 6 : Rapport d’audit

A la fin des précédentes phases d’audit sur le terrain, l’auditeur est invité à rédiger
un rapport de synthèse sur sa mission d’audit.

Cette synthèse doit être révélatrice des défaillances enregistrées. Autant est-il
important de déceler un mal, autant il est également important d’y proposer des
solutions. Ainsi, l’auditeur est également invité à donner ses recommandations, pour
pallier aux défauts qu’il aura constatés.

116
Ces recommandations doivent tenir compte de l’audit organisationnel et physique, ainsi
que de celui technique et intrusif. On doit retrouver parmi les recommandations au
minimum :

 Une étude de la situation existante en termes de sécurité au niveau du site audité,

qui tiendra compte de l’audit organisationnel et physique, ainsi que les
éventuelles vulnérabilités de gestion des composantes du système (réseau,
systèmes, applications, outils de sécurité) et les recommandations
correspondantes ;
 Les actions détaillées (organisationnelles et techniques) urgentes à mettre en
œuvre dans l’immédiat, pour parer aux défaillances les plus graves, ainsi que la
proposition de la mise à jour ou de l’élaboration de la politique de sécurité à
instaurer.

L’audit est une démarche collaborative visant l’exhaustivité. Elle est moins réaliste
qu’un test, mais permet en contrepartie de passer méthodiquement en revue tout le
réseau et chacun de ses composants en détail.

II.6.4. Méthodes, Normes, Outils et Référentiels d’audit de la SSI

a) Les Méthodes

Une méthode est une démarche, un processus ou un ensemble de principes qui

permettent d’appliquer une norme au système d’information de l’entreprise. La méthode
sert aussi à faire un audit qui permet de faire, par exemple, un état de la sécurité du
système d’information. Une méthode est souvent accompagnée d’outils afin d’appuyer
son utilisation. Ils peuvent être disponibles gratuitement auprès des organismes qui les
ont produit. Par exemple la méthode MEHARI. La plupart des méthodes sont
appliquées par des experts en gestion des risques (COBIT, EBIOS, MEHARI,
OCTAVE…).

117
 b) Historique des Normes en matière de Sécurité de l’Information
Le tableau ci-après présente l’historique:

Année Norme Traite des SMSI Remplace la norme

1995 BS 7799:1995 Non
1998 BS 7799-2:1998 Oui
2000 ISO 17799:2000 Non BS 7799 :1995
2002 BS 7799-2:2002 Oui BS 7799-2 :1998
2005 ISO 17799:2005 Non ISO 17799 :2000
2005 ISO 27001:2005 Oui BS 7799-2 :2002
2007 ISO 27002 Non ISO 17799 :2005

Tableau 4 : Historique des normes en matière de sécurité de l’information

Figure 27 : Cartographie des principales méthodes SSI dans le monde.

Aujourd’hui, les organismes disposent de deux normes qui se sont imposées comme
références des SMSI, l’ISO/CEI 27001 :2005 qui décrit les exigences pour la mise en

118
place d'un Système de Management de la Sécurité de l’Information et l’ISO/CEI 27002
qui regroupe un ensemble de bonnes pratiques «best practices» pour la gestion de la
sécurité de l'information.

a) La suite des Normes ISO 2700X

Cette norme (aussi connue sous le nom de Famille des standards SMSI ou ISO27k)
comprend les normes de sécurité de l'information publiées conjointement par
l'Organisation internationale de normalisation (ISO) et la Commission électrotechnique
internationale (CEI, ou IEC en anglais).

La suite contient des recommandations des meilleures pratiques en management de la

sécurité de l'information, pour l'initialisation, l'implémentation ou le maintien de
systèmes de management de la sécurité de l'information (SMSI, ou ISMS en anglais),
ainsi qu'un nombre croissant de normes liées au SMSI :

 ISO/CEI 27000 : Systèmes de management de la sécurité de l'information -- Vue

d'ensemble et vocabulaire ;
 ISO/CEI 27001 : Systèmes de management de la sécurité de l'information –
Exigences ;
 ISO/CEI 27002 : Code de bonne pratique pour le management de la sécurité de
l'information ;
 ISO/CEI 27003 : Lignes directrices pour la mise en œuvre du système de
management de la sécurité de l'information ;
 ISO/CEI 27004 : Management de la sécurité de l'information – Mesurage ;
 ISO/CEI 27005 : Gestion des risques liés à la sécurité de l'information ;
 ISO/CEI 27006 : Exigences pour les organismes procédant à l'audit et à la
certification des systèmes de management de la sécurité de l'information ;
 ISO/CEI 27007 : Lignes directrices pour l'audit des systèmes de management de
la sécurité de l'information.

119
120
 II.7. AUDIT DES COUTS INFORMATIQUES

Figure 28 : Zoom sur les coûts informatiques

II.7.1. Qu’est-ce que l’audit des coûts informatiques?

L'audit des coûts informatique a pour objectif d’identifier et d’évaluer les risques
financiers, associés aux activités informatiques d'une entreprise ou d'une administration.
Ainsi l’auditeur doit pouvoir se baser sur les référentiels de bonnes pratiques existants
(exemple le référentiel d’analyse et de benchmarking des coûts du Cigref, CobiT et
ITIL), sur les benchmarks à disposition et sur l’expérience professionnelle des auditeurs
impliqués.

II.7.2 L’audit des coûts informatiques : Pourquoi ?

L’audit des coûts informatiques présente divers intérêts:

- Analyser les coûts et leur évolution dans le temps afin de détecter les
dérapages et de prendre des mesures correctives ;
- Déterminer si la refacturation des services rendus par la DSI et la gestion des
contrats de services avec les clients internes sont faites de façon appropriée;

121
- Déterminer si le catalogue des entreprises participantes aux benchmarking des
coûts informatiques est pertinent ;
- Évaluer si les actions de réduction du coût total de possession des actifs
informatiques sont efficaces ;
- Evaluer le niveau de maturité du contrôle de gestion informatique ;
- Évaluer les mécanismes de calcul des coûts complets ;
- Évaluer la pertinence du plan de comptes informatique ;
- Évaluer la mise en œuvre de la méthode ABC/ABM au domaine des services
rendus par la DSI à ses clients internes ;
- Évaluer la pertinence des outils utiliser pour le contrôle de gestion
informatique ;
- Évaluer les critères de benchmarking utilisées ;
- Optimiser ses coûts ;
- Maîtriser et éviter les dérapages, notamment des coûts variables ;
- Réduire les dépenses ;
- Évaluer la pertinence des indicateurs de performance choisis dans
l’élaboration de tableaux de bord prospectifs.

II.7.3. L’audit des coûts informatiques : A quel moment vaut-il

mieux le faire ?

- Après la mise en place d’un système de contrôle de gestion informatique pour

évaluer son efficacité;
- Avant ou après la clôture d’un exercice budgétaire ;
- Après la clôture d’un projet informatique.

II.7.4. Préparation de la mission d’audit

- Se rassurer de l’existence et de la mise en œuvre d’un dispositif de contrôle

de gestion ou de calcul des coûts informatiques au sein de la DSI ;

122
 - En cas d’absence d’un dispositif de contrôle de gestion, un audit des coûts
informatiques ne pourrait être pertinent, car l’auditeur ne disposerait pas
d’éléments sur lesquels il devrait se baser pour évaluer et tirer des
conclusions : la seule recommandation à ce niveau serait la mise en œuvre
d’un dispositif de gestion des coûts informatiques comme le référentiel
d’analyse et de benchmarking des coûts informatiques du Cigref. C’est le seul
à ce jour à proposer une démarche pragmatique étapée de mise en place d’un
système de gestion des coûts informatiques par la DSI;
- Constituer une équipe mixte formée de personnes ayant les compétences en
contrôle de gestion et d’informaticiens de métier.

II.7.5. Démarche d’audit interne ou externe des coûts

informatiques

Cette démarche s’inspire du référentiel d’analyse et de benchmarking des coûts

informatiques du Cigref. Etant donné que tout audit s’appuie sur un ou plusieurs
référentiels donnés, il est de bon ton qu’une démarche d’évaluation de sa mise en
œuvre y soit associée.

123
 Figure 29 : démarche d’élaboration des coûts informatiques du Cigref

II.7.5.1. Etape 1 : Evaluer le catalogue de service de la DSI

Une DSI délivre de manière générale un ensemble de services à ses clients

internes. Il est de la responsabilité de la DSI de formaliser ce catalogue de services. Il
est, en effet, important de bien cadrer et de bien définir au préalable ce catalogue de
services, avant de se lancer dans la démarche d’analyse. C’est notamment sur ces
services que pourra porter le benchmarking futur. L’auditeur à ce stade doit pouvoir
poser les questions suivantes :

- La DSI a-t-elle une vue complète des services qu’elle rend aux métiers ?
- Cette vue est-elle formalisée ?
- Ces services sont-ils catégorisés ?

124
 II.7.5.2. Etape 2 : Evaluer la mise en cohérence du modèle d’activités

Le modèle d’analyse et benchmarking des coûts propose un modèle d’activités

générique pouvant être facilement adapté au contexte de chaque DSI, quelque soit le
secteur d’activité de l’entreprise. Selon le contexte, il sera naturellement possible de
découper plus finement les activités ou au contraire de les agréger davantage. L’auditeur
à ce stade doit pouvoir poser les questions suivantes :

- La DSI a-t-elle identifiée toutes les activités nécessaires à la fourniture des

services répertoriés ?
- Existe-t-il un manuel de procédure pour la DSI ?
- Ce manuel de procédure est-il appliqué ?
- Les activités sont-elles organisées par processus ?
- Existe-t-il un processus d’analyse des activités de la DSI ?
- La DSI a-t-elle mis en œuvre un référentiel de gestion des services informatiques
tels ITIL ou CobiT ?
- Existe-t-il une cartographie des processus de la DSI ?
- L’approche processus est-elle mise en œuvre au sein de la DSI ?

II.7.5.3. Etape 3 : Evaluer la ventilation du budget en rubrique

Une fois le modèle d’activités adapté au contexte de la DSI, il faut procéder à une
ventilation de son budget en rubriques et sous‐rubriques. Les travaux du Cigref ont
permis de proposer une décomposition du budget d’une DSI en 6 rubriques principales:

- Personnel
- Prestations externes
- Matériels
- Logiciels
- Telecom
- Frais de structure
L’auditeur à ce stade doit pouvoir poser les questions suivantes :

125
 - Existe-t-il un budget de charges détaillé?
- Ce budget intègre-t-il la dimension valeur ? car l’objectif d’une maîtrise des coûts
est aussi de pouvoir identifier les bénéfices issus de l’investissement
informatique.
- Existe-t-il une correspondance entre les rubriques du budget et les comptes du
plan comptable général ?
- Existe-t-il une véritable comptabilité des ressources gérées par la DSI ?
- Existe-t-il un schéma directeur ?

II.7.5.4. Etape 4 : Evaluer le mécanisme d’affectation des ressources aux

activités

L’auditeur à ce stade doit pouvoir poser les questions suivantes :

- Est-ce-que toutes les ressources budgétées ont été affectées à toutes activités
recensées ?
- Comment s’effectue cette répartition ?
- La DSI a-t-elle identifiée des inducteurs de ressources ?
- Ces inducteurs de ressources sont-ils pertinents ?

II.7.5.5. Etape 5 : Evaluer le mécanisme de ventilation des activités sur les

services

L’auditeur à ce stade doit pouvoir poser les questions suivantes :

- La DSI a-t-elle identifiée des inducteurs d’activités?

- Ces inducteurs d’activités sont-ils pertinents ?
- Existe-t-il un mécanisme permettant de capturer la consommation des services
informatiques par les autres clients internes ?
- Existe-t-il un mécanisme de calcul du coût total de possession ?

II.7.5.6. Etape 6 : Evaluer les critères d’analyse et de comparaison

L’auditeur à ce stade doit pouvoir poser les questions suivantes :

126
 - La DSI dispose-t-elle d’un catalogue de DSI participante pour la comparaison ?
- Quels critères ont été utilisés pour qu’elles soient sélectionnées ?
- Ces critères sont-ils pertinents ?
- Quel est le niveau de maturité du contrôle de gestion informatique des DSI
participantes ?

II.7.6. Techniques, outils, référentiels ou normes à utiliser pour un audit de

coûts informatique

a) L’approche processus
L’approche processus est l’un des huit (08) principes de base du management de la
qualité de la norme ISO 9001, ce principe stipule que « Un résultat escompté est plus
efficacement atteint lorsque les ressources et activités afférentes sont gérées comme un
processus ».

Justifications :

Les grandes organisations, entreprises privées et publiques, administrations, sociétés de

service ont beaucoup évolué depuis 20 ans. Ces changements tendent à s’accélérer
encore, avec l’ouverture des marchés, les contraintes de productivité, l’innovation
technique et les besoins de flexibilité organisationnelle. Ils sont à l’origine d’une
effervescence des pratiques managériales, dont témoigne l’explosion du marché des
dispositifs de gestion innovants.

Dans ce contexte, le management par les processus semble constituer la réponse idéale
aux nombreuses contraintes de l’entreprise.

En effet, cette approche implique de prendre en compte toutes les activités de

l’entreprise, puis de les structurer et les analyser afin de les maîtriser et de les optimiser.
En permettant la mesure de l’efficacité individuelle et globale des processus, le
management par les processus devient un outil d’analyse et d’optimisation nécessaire
pour l’entreprise en quête d’une recherche permanente d’amélioration

La valeur est créée par l’ensemble du processus. Les diverses activités qui composent le
processus ne sont ni choisies au hasard ni ad hoc, elles sont connexes et forment un

127
ensemble organisé. La satisfaction des parties prenantes transcende et marque toutes les
activités qui composent le processus.

La logique de finalité implique qu’un processus fasse appel aux ressources de chacune
des fonctions. Tous les acteurs doivent collaborer pour un objectif commun tout en
travaillant dans des services différents.

b) Le processus de gestion financière d’ITIL

« La gestion financière des services informatiques » est un processus décrit dans le livre
« Stratégie des services ». Ce livre inclut en effet trois (03) processus : la gestion des
demandes, la gestion financière et la gestion de portefeuille de services. Les enjeux de
la stratégie des services étant de comprendre les besoins métier, de définir les stratégies
et les services pour les satisfaire et d’optimiser la valeur de ces services. La gestion
financière regroupe les processus et les fonctions pour gérer les budgets, la comptabilité
et la refacturation des services informatiques.

- La gestion du budget : c’est l’activité de prévision et de contrôle des dépenses.

Elle inclut la négociation cyclique pour définir les futurs budgets (habituellement
annuels), la supervision au jour le jour des budgets et leur ajustement ;
- La comptabilité : c’est le processus qui vise à identifier les coûts actuels délivrés
par les services informatiques, à les comparer aux coûts budgétés et à gérer la
variance ;
- La refacturation des services informatiques : c’est l’activité visant à refacturer
les coûts des services informatiques. ITIL précise que cette activité peut être
optionnelle et que de nombreuses organisations traitent le fournisseur de services
informatiques comme un centre de coût.

c) Le CobIT
CobiT (Control Objectives for Information and related Technology) définit les
contrôles, les pratiques et les processus informatiques formels devant être mis en
place, ainsi que les résultats minimaux qu'ils sont censés générer.

128
Ce modèle est utilisé pour vérifier le bon alignement entre l'informatique et les
métiers. Il est complémentaire à ITIL sur l'un des domaines qu'il couvre : la gestion
des services informatiques (prestations/support).

La norme standard COBIT d’appui à la gouvernance SI intègre d’ailleurs 2 processus

centrés autour du pilotage des couts informatiques:

- DS6 : Identifier et imputer les coûts (en vue « d’assurer une connaissance exacte
des coûts imputables aux services informatiques ») ;
- PO5 : Gérer l’investissement informatique (en vue « de garantir le financement
et contrôler le décaissement des ressources financières».

129
 III. RECEUIL DES REFERENTIELS, NORMES ET METHODES

RECEUIL DES REFERENTIELS, NORMES ET METHODES

130
Domaine du SI Référentiels, normes et outils utilisés
• ISO 13335 : Concepts et modèles pour la gestion de la
sécurité des TIC (1996),
• ISO 15408 : Critères communs pour l'évaluation de la
sécurité des Technologies de l'Information,
• ISO/CEI 17799 : Code de bonnes pratiques pour la
gestion de la sécurité d'information (ancienne référence
de la norme ISO/CEI 27002).
• ISO/CEI 27001 : Description des exigences pour la
mise en place d'un Système de Management de la
Sécurité de l'Information (SMSI).
• ISO/CEI 27002 : Nouveau nom pour la norme ISO/CEI
17799.
Audit de la Sécurité • ISO/CEI 27005 : Proposition d'une méthode
d'appréciation des risques (cette phase est obligatoire
dans le cadre d'une certification ISO/CEI 27001).
• ISO/CEI 27006 : Contient des informations sur le
profile propre de l'auditeur 27001.
• Risk IT a pour but d'améliorer la maîtrise des risques
liés à l'informatique
• CobiT : Control Objectives for Information and related
Technology. C'est le principal référentiel des auditeurs
informatiques
• MEHARI
• EBIOS
• OCTAVE
• ISO/CEI 27007 : Guide pour l'audit de Systèmes de
Management de la Sécurité de l'Information (SMSI).
• ISO/CEI 27001 : Système de Management de la
Sécurité de l'Information (SMSI) — Exigences
• ISO/CEI 27002 : Code de bonnes pratiques pour la
gestion de la sécurité de l'information (anciennement
ISO/CEI 17799)
• ISO/CEI 27003 : Système de Management de la
Audit des données Sécurité de l'Information (SMSI) — Guide
d'implémentation
• ISO/CEI 27004 : Mesure de la gestion de la sécurité de
l'information
• ISO/CEI 27005 : Gestion du risque en sécurité de
l'information
• ISO/CEI 27006 : Exigences pour les organismes
réalisant l'audit et la certification de Systèmes de
Management de la Sécurité de l'Information (SMSI)
• ISO 9000 : Systèmes de management de la qualité - principes
essentiels et vocabulaire
• ISO 9001 : Systèmes de management de la qualité -
Exigences
• ISO 9004 : Systèmes de management de la qualité -
Audit des processus Lignes directrices pour l'amélioration des performances
• ITIL qui est un recueil des bonnes pratiques concernant
les niveaux et de support des services informatiques.
• Cobit : dans ses processus DS 1, DS 3, DS 6, DS 12 et
DS 13.
• ISO 9004

131
 • ISO 19001
 CobiT : les processus PO4, PO5, PO8, PO9, et PO10 du
domaine Planifier et Organiser, les processus AI5 et AI6
du domaine Acquérir et Implémenter, les processus DS4,
DS5, DS8, DS10 et DS11 du domaine Délivrer et
Supporter, l’ensemble des processus du domaine
Surveiller et Évaluer, qui portent sur le contrôle interne
des autres processus.
 L’approche processus
• ITIL : Processus de gestion financière
Audit des coûts • CobiT : Avec les processus PO5 et DS6
informatiques • Le référentiel de benchmarking des coûts du Cigref
 ISO 9126 : Gestion des exigences logicielles
 CMMi : Capability Maturity Model integration qui est
une démarche d'évaluation de la qualité de la gestion de
Audit des applications et projet informatique
des projets informatiques  Cobit : dans ses processus PO 10, AI 1 et AI 2
 ISO 25000 (SQARE): Software Product Quality
Requirement and Evaluation
 La méthodologie INFAUDITOR
• ISO 7498 : Modèle réseau OSI en 7 couches
• ISO 11898 : Gestionnaire de réseau de communication
(CAN)
Audit du matériel et • ISO-27002
risques informatiques • MEHARI
• EBIOS
• CobiT

Tableau 5 : Domaines d’audit du SI et référentiels utilisés

132
CONCLUSION

Le Systèmes d’information est un élément essentiel de l’entreprise de nos jours.

Les entreprises sont prêtes à investir de fortes sommes afin d’obtenir un système
d’information performant et adapté à leur activité. C’est également un enjeu majeur pour
la compétitivité de l’entreprise.

Cependant, comment savoir si le système d’information en place est adapté à

l’entreprise?

Il se pose donc le problème de l’évaluation des Systèmes d’information. Les

objectifs de l’évaluation d’un système d’information sont nombreux pour une entreprise.
Cela permet de vérifier la contribution du SI à la performance de l’entreprise, et favorise
le progrès dans l’organisation, avec l’apprentissage organisationnel. On voit également
un objectif de motivation et de guide des acteurs en les situant dans une perspective
d’amélioration continue, ou encore évaluer la qualité des actes de gestion et l’usage des
ressources.

C’est dans cette optique que rentre ce guide des méthodes d’investigation de la
qualité des domaines constitutifs du Systèmes d’information. Cet ouvrage a le mérite
d’aborder de façon pragmatique le problème posé par l’identification d’une démarche
efficace et le choix d’outils et de référentiels adaptés aux différents domaines qui ont
fait l’objet de cette étude.

Ce guide n’a pas la prétention de couvrir tous les domaines d’audit (audit des
délais non évoqué) les types d’audit d’un Systèmes d’information, car il ne traite que
l’audit opérationnel. L’audit financier ayant déjà fait l’objet de plusieurs productions
littéraires sur le sujet et dont les méthodes sont connus et éprouvées. C’est donc la
fonction Systèmes d’information qui a retenu l’attention de ces auteurs, et la richesse de
cet ouvrage réside sur cet aspect. Car il propose des méthodes d’audits sur des domaines
sensibles telles les coûts informatiques, les données et le matériel qui n’ont presque
aucune démarche connue à ce jour. Car les référentiels du domaine ne présentant qu’un
recueil de bonnes pratiques « ce qui doit être fait » et non « comment le faire ? ».

133
GLOSSAIRE

Terme Définition
AFNOR Association Française de Normalisation. Il est l’organisme
français de normalisation et membre de l’Organisation
Internationale de Normalisation (ISO).
COBIT Control Objectives for Information and related Technology
(Objectifs de contrôle de l’Information et des Technologies
Associées). C’est un référentiel et outil fédérateur permettant
d’instaurer un langage commun pour parler de la Gouvernance
des systèmes d’information. Le référentiel COBIT a été
développé en 1994, et publié en 1996, par l’ISACA
(Information Systems Audit and Control Association).
L’ISACA a été créé en 1967 et est représenté en France depuis
1962 par l’AFAI (Association Française de l’Audit et du
Conseil Informatiques). Le COBIT est une approche orientée
processus, qui regroupe cinq domaines et des pratiques.
COSO Committee Of Sponsoring Organizations of the Treadway
Commission. C’est un référentiel de contrôle interne.
DSI (O) Direction des systems d’informations (et de l’organisation).
ISO International Organization for Standardization (Organisation
international de normalization). C’est un organism de
normalization.
IT Le terme anglais IT (Information Technologies) désigne les
notions de technologies de l’information et de la
communication. Il pourra également se traduire par le terme
« informatique ».
ITIL Information Technology Infrastructure Library. Il est constitué
d’un ensemble de bonnes pratiques du management du système
d’information. L’adoption des bonnes pratiques de l’ITIL ont
notamment pour objectif :
 D’apporter aux clients internes comme externes un
service répondant à des normes de qualité préétablies au
niveau international, basées sur une approche par
processus clairement définie et contrôlée ;
 D’améliorer la qualité des SI et de l’assistance aux
utilisateurs.
OS Operating System. Il est traduit en français comme Système
d’exploitation.
RACI Responsible, Accountable ou Approver, Consulted, Informed.
Encore connu sous RACI Matrix, ou encore appelé RAM
(Responsible Assignment Matrix). Il représente dans le
management une matrice des responsabilités qui indique les
rôles et les responsabilités des intervenants au sein de chaque
processus et activité.

134
RSSI Responsable de la Sécurité des Systèmes d’Information.
SLA Service Level Agreement ou Accord sur les niveaux de service.
SOX Encore appelé Sarbox ou SOA. Aux États-Unis, la loi de 2002
sur la réforme de la comptabilité des sociétés cotées et la
protection des investisseurs est une loi fédérale imposant de
nouvelles règles sur la comptabilité et la transparence
financière. Le texte est couramment appelé loi Sarbanes-Oxley,
du nom de ses promoteurs le sénateur Paul Sarbanes et le
député Mike Oxley.
UNIX Système d’exploitation multi-tâches et multi-utilisateurs crée
en 1969.

135
 ANNEXES

ANNEXES

136
Lois sur la cybercriminalité au Cameroun

Dans la Loi n°2010/012 du 21 décembre 2010 relative à la cybersécurité et la

cybercriminalité au Cameroun, sont énumérées les sanctions suivantes relatives aux
infractions liées à la cybercriminalité :
Article 65.- (1) Est puni d’un emprisonnement de cinq (05) à dix (10) ans et d’une
amende de 5.000.000 (cinq millions) à 10.000.000 (dix millions) F CFA ou de l’une de
ces deux peines seulement, celui qui effectue, sans droit ni autorisation, l’interception
par des moyens techniques, de données lors des transmissions ou non, à destination, en
provenance ou à l’intérieur ou non d’un réseau de communications électroniques, d’un
système d’information ou d’un équipement terminal.

(2) Est puni des peines prévues à l’alinéa 1 ci-dessus, tout accès non autorisé, à
l’ensemble ou à une partie d’un réseau de communications électroniques ou d’un
système d’information ou d’un équipement terminal.

(3) Les peines prévues à l’alinéa 1 ci-dessus sont doublées, en cas d’accès illicite portant
atteinte à l’intégrité, la confidentialité, la disponibilité du réseau de communications
électroniques ou du système d’information.

(4) Est puni des mêmes peines prévues à l’alinéa 1 ci-dessus, celui qui, sans droit, permet
l’accès dans un réseau de communications électroniques ou dans un système
d’information par défi intellectuel.

Article 66.- (1) Est puni d’un emprisonnement de deux (02) à cinq (05) ans et d’une
amende de 1.000.000 (un million) à 2.000.000 (deux millions) F CFA ou de l’une de ces
deux peines seulement, celui qui entraîne la perturbation ou l’interruption du
fonctionnement d’un réseau de communications électroniques ou d’un équipement
terminal, en introduisant, transmettant, endommageant, effaçant, détériorant, modifiant,
supprimant ou rendant inaccessibles les données.

(2) Sont passibles des mêmes peines prévues à l’alinéa 1 ci-dessus, les personnes qui
font usage d’un logiciel trompeur ou indésirable en vue d’effectuer des opérations sur
un équipement terminal d’un utilisateur sans en informer au préalable celui-ci de la
nature exacte des opérations que ledit logiciel est susceptible d’endommager.
137
(3) Est puni des mêmes peines prévues à alinéa 1 ci-dessus, celui qui, à l’aide d’un
logiciel potentiellement indésirable collecte, tente de collecter ou facilite l’une de ces
opérations pour accéder aux informations de l’opérateur ou du fournisseur d’un réseau
ou de service électronique afin de commettre des infractions.

Article 67.- Constitue une atteinte à l’intégrité d’un réseau de communications

électroniques ou d’un système d’information et punie des peines prévues à l’article 66,
alinéa 1 ci-dessus, le fait de provoquer une perturbation grave ou une interruption de
fonctionnement d’un réseau de communications électroniques d’un équipement terminal
par l’introduction, la transmission, la modification, la suppression, l’altération des
données.
Article 68.- (1) Est puni d’un emprisonnement de cinq (05) à dix (10) ans et d’une
amende de 10.000.000 (dix millions) à 50.000.000 (cinquante millions) F CFA ou de
l’une de ces deux peines seulement, celui qui accède ou se maintient, frauduleusement,
dans tout ou partie d'un réseau de communications électroniques ou d’un système
d’information en transmettant, endommageant, provoquant une perturbation grave ou
une interruption du fonctionnement dudit système ou dudit réseau.
(2) Les peines prévues à l’alinéa 1 ci-dessus sont doublées s’il en est résulté, soit la
suppression ou la modification des données contenues dans le système d’information,
soit une altération de son fonctionnement.
Article 69.- Est puni d’un emprisonnement de cinq (05) à dix (10) ans et d’une amende
de 10.000.000 (dix millions) à 100.000.000 (cent millions) F CFA ou de l’une de ces
deux peines seulement, celui qui accède sans droit, et en violation des mesures de
sécurité, à l’ensemble ou à une partie d’un réseau de communications électroniques,
d’un système d’information ou d’un équipement terminal, afin d’obtenir des
informations ou des données, en relation avec un système d’information connecté à un
autre système d’information.
Article 70.- Est puni d’une amende de 1.000.000 (un million) à 5.000.000 (cinq millions)
F CFA, celui qui provoque par saturation, l’attaque d’une ressource de réseau de
communications électroniques ou d’un système d’information dans le but de l’effondrer
en empêchant la réalisation des services attendus.

138
Article 71.- Est puni d’un emprisonnement de deux (02) à cinq (05) ans et d’une amende
de 1.000.000 (un million) à 25.000.000 (vingt cinq millions) F CFA, celui qui introduit
sans droit, des données dans un système d’information ou dans un réseau de
communications électroniques en vue de supprimer ou de modifier les données qui en
sont contenues.
Article 72.- Est puni des peines prévues par l’article 66 ci-dessus celui qui, de quelque
manière que ce soit, sans droit, introduit, altère, efface, ou supprime, afin d’obtenir un
bénéfice économique, les données électroniques, de manière à causer un préjudice
patrimonial à autrui.
Article 73.- (1) Est puni d’un emprisonnement deux (02) à dix (10) ans et d’une amende
de 25.000.000 (vingt cinq millions) à 50.000.000 (cinquante millions) F CFA, ou de
l’une de ces deux peines seulement, celui qui, par la voie d’un système d’information
ou dans un réseau de communications contrefait, falsifie une carte de paiement, de
crédit, ou de retrait ou fait usage ou tente de faire usage en connaissance de cause, d’une
carte de paiement, de crédit ou de retrait contrefaite ou falsifiée.
(2) Est puni des peines prévues à l’alinéa 1 ci-dessus, quiconque, en connaissance de
cause, accepte de recevoir par voie de communications électroniques, un règlement au
moyen d'une carte de paiement, de crédit ou de retrait contrefaite ou falsifiée.
Article 74.- (1) Est puni d’un emprisonnement de un (01) à deux (02) ans et d’une
amende de 1.000.000 (un million) à 5.000.000 (cinq millions) F CFA, quiconque, au
moyen d’un procédé quelconque porte atteinte à l'intimité de la vie privée d'autrui en
fixant, enregistrant ou transmettant, sans le consentement de leur auteur, les données
électroniques ayant un caractère privé ou confidentiel.
(2) Sont passibles des peines prévues à l’alinéa 1 ci-dessus les personnes qui, sans droit,
interceptent des données personnelles lors de leur transmission d’un système
d’information à un autre ;
(3) Est puni d’un emprisonnement d’un (01) à trois (03) ans et d’une amende de
1.000.000 (un million) à 5.000.000 (cinq millions) F CFA ou de l’une de ces deux peines
seulement, quiconque procède ou fait procéder, même par négligence au traitement des
données à caractère personnel en violation des formalités préalables à leur mise en
œuvre.

139
(4) Est puni d’un emprisonnement de six (06) mois à deux (02) ans et d’une amende de
1.000.000 (un million) à 5.000.000 (cinq millions) F CFA ou de l’une de ces deux peines
seulement, le fait de collecter par des moyens illicites, des données nominatives d’une
personne en vue de porter atteinte à son intimité et à sa considération.
(5) Les peines prévues à l’alinéa 4 ci-dessus sont doublées, à l’encontre de celui qui met,
fait mettre en ligne, conserve ou fait conserver en mémoire informatisée, sans l’accord
exprès de l’intéressé, des données nominatives qui, directement ou indirectement, font
apparaître ses origines tribales, ses opinions politiques, religieuses, ses appartenances
syndicales ou ses mœurs.
(6) Les peines prévues à l’alinéa 5 ci-dessus, s’appliquent aux personnes qui détournent
les informations, notamment, à l’occasion de leur enregistrement, de leur classement, de
leur transmission.
(7) Est puni d’un emprisonnement de six (06) mois à deux (02) ans et d’une amende de
5.000.000 (cinq millions) à 50.000.000 (cinquante millions) F CFA, ou de l’une de ces
deux peines seulement, celui qui conserve des informations sous une forme nominative
ou chiffrée au-delà de la durée légale indiquée dans la demande d’avis ou la déclaration
préalable à la mise en oeuvre du traitement automatisé.
(8) Est puni des peines prévues à l’alinéa 7 ci-dessus, le fait de divulguer des données
nominatives portant atteinte à la considération de la victime.
Article 75.- (1) Est puni d’un emprisonnement de deux (02) à cinq (05) ans et d’une
amende de 1.000.000 (un million) à 5.000.000 (cinq millions) F CFA ou de l’une de ces
deux peines seulement, celui qui enregistre et diffuse à but lucratif, par la voie de
communications électroniques ou d’un système d’information sans le consentement de
l’intéressé, des images portant atteinte à l’intégrité corporelle.
(2) Le présent article n'est pas applicable lorsque l'enregistrement et la diffusion
résultent de l'exercice normal d'une profession ayant pour objet d'informer le public ou
sont réalisés afin de servir de preuve en justice conformément aux dispositions du Code
de procédure pénale.
Article 76.- Est puni d’un emprisonnement de cinq (05) à dix (10) ans et d’une amende
de 5.000.000 (cinq millions) à 10.000.000 (dix millions) F CFA ou de l’une de ces deux
peines seulement, celui qui confectionne, transporte, diffuse, par voie de

140
communications électroniques ou d’un système d’information, un message à caractère
pornographique enfantine, ou de nature à porter gravement atteinte à la dignité d’un
enfant.

141
Article 77.- (1) Est puni d’un emprisonnement de deux (02) à cinq (05) ans et d’une
amende de 2.000.000 (deux millions) à 5.000.000 (cinq millions) F CFA ou de l’une de
ces deux peines seulement, celui qui, par la voie de communications électroniques ou
d’un système d’information, commet un outrage à l’encontre d’une race ou d’une
religion.
(2) Les peines prévues à l’alinéa 1 ci-dessus sont doublées lorsque l’infraction est
commise dans le but de susciter la haine ou le mépris entre les citoyens.
Article 78.- (1) Est puni d’un emprisonnement de six (06) mois à deux (02) ans et d’une
amende de 5.000.000 (cinq millions) à 10.000.000 (dix millions) F CFA ou de l’une de
ces deux peines seulement, celui qui publie ou propage par voie de communications
électroniques ou d’un système d’information, une nouvelle sans pouvoir en rapporter la
preuve de véracité ou justifier qu’il avait de bonnes raisons de croire à la vérité de ladite
nouvelle.
(2) Les peines prévues à l’alinéa 1 ci-dessus sont doublées lorsque l’infraction est
commise dans le but de porter atteinte à la paix publique.
Article 79.- Les peines réprimant les faits d’outrage privé à la pudeur prévus à l'article
295 du Code Pénal, sont un emprisonnement de cinq (05) à dix (10) ans et une amende
de 5.000.000 (cinq millions) à 10.000.000 (dix millions) F CFA ou de l’une de ces deux
peines seulement, lorsque la victime a été mise en contact avec l’auteur desdits faits,
grâce à l’utilisation des communications électroniques ou des systèmes d’information.
Article 80.- (1) Est puni d’un emprisonnement de trois (03) à six (06) ans et d’une
amende de 5.000.000 (cinq millions) à 10.000.000 (dix millions) F CFA ou de l’une de
ces deux peines seulement, celui qui diffuse, fixe, enregistre ou transmet à titre onéreux
ou gratuit l’image présentant les actes de pédophilie sur un mineur par voie de
communications électroniques ou d’un système d’information.
(2) Est puni des mêmes peines prévues à l’alinéa 1 ci-dessus, quiconque offre, rend
disponible ou diffuse, importe ou exporte, par quelque moyen électronique que ce soit,
une image ou une représentation à caractère pédophile.
(3) Est puni d’un emprisonnement de un (01) à cinq (05) ans et d’une amende de
5.000.000 (cinq millions) à 10.000.000 (dix millions) F CFA ou de l’une de ces deux

142
peines seulement, celui qui détient dans un réseau de communications électroniques ou
dans un système d’informations, une image ou une représentation à caractère pédophile.
(4) Les peines prévues à l’alinéa 3 ci-dessus sont doublées, lorsqu'il a été utilisé un
réseau de communications électroniques pour la diffusion de l'image ou la
représentation du mineur à destination du public.
(5) Les dispositions du présent article sont également applicables aux images
pornographiques mettant en scène les mineurs.
Article 81.- (1) Sont punis des peines prévues à l’article 82 ci-dessous, les faits ci-
dessous, lorsqu’ils sont commis en utilisant un réseau de communications électroniques
ou un système d’information :
- l’offre, la production, la mise à disposition de pornographie enfantine en vue de sa
diffusion ;
- le fait de se procurer ou de procurer à autrui de la pornographie enfantine par le biais
d’un système d’information ;
- le fait pour les personnes majeures de faire des propositions sexuelles à des mineurs
de moins de quinze (15) ans ou une personne se présentant comme telle ;
- la diffusion ou la transmission de pornographie enfantine par le biais d’un système
d’information.
(2) Est considéré comme pornographie enfantine, tout acte présentant de manière
visuelle :
- un mineur se livrant à un comportement sexuellement explicite ;
- une personne qui apparaît comme mineur se livrant à un comportement sexuellement
explicite ;
- des images réalistes présentant un mineur se livrant à un comportement sexuellement
explicite.
Article 82.- Est puni du double des peines prévues à l’article 79 de la présente loi celui
qui commet ou tente de commettre par voie de communications électroniques un outrage
à la pudeur sur un mineur de moins de quinze (15) ans.
Article 83.- (1) Est puni d’un emprisonnement d’un (01) à deux (02) ans et d’une
amende de 500.000 (cinq cent mille) à 1.000.000 (un million) F CFA ou de l’une de ces

143
deux peines seulement, celui qui par voie de communications électroniques, fait des
propositions sexuelles à une personne de son sexe.
(2) Les peines prévues à l’alinéa 1 ci-dessus, sont doublées lorsque les propositions ont
été suivies de rapports sexuels.
Article 84.- (1) Est puni d’un emprisonnement de six mois (06) à deux (02) ans et d’une
amende de 500.000 à 1.000.000 F CFA ou de l’une de ces deux peines seulement, celui
qui accède, prend frauduleusement connaissance, retarde l’accès ou supprime les
communications électroniques adressées à autrui.
(2) Est puni des mêmes peines prévues à l’alinéa 1 ci-dessus, celui qui intercepte sans
autorisation, détourne, utilise ou divulgue les communications électroniques émises, ou
reçues par des voies électroniques ou procède à l'installation d'appareils conçus pour
réaliser de telles interceptions.
Article 85.- Est punie des peines prévues à l’article 84 ci-dessus, celui qui, chargé d'une
mission de service public, agissant dans l'exercice ou à l'occasion de l'exercice de ses
fonctions, détourne ou facilite le détournement, la suppression ou l’accès aux
communications électroniques ou la révélation du contenu de ces communications.
Article 86.- (1) Est puni des peines prévues l’article 71 ci-dessus, celui qui importe,
détient, offre, cède, vend ou met à disposition, sous quelle que forme que ce soit, un
programme informatique, un mot de passe, un code d’accès ou toutes données
informatiques similaires conçus et ou spécialement adaptés, pour permettre d’accéder,
à tout ou partie d’un réseau de communications électroniques ou d’un système
d’information.

(2) Est également puni des mêmes peines prévues à l’alinéa 1 ci-dessus, quiconque
provoque une perturbation grave ou une interruption d’un réseau de communications
électroniques ou d’un système d’information dans l’intention de porter atteinte à
l’intégrité des données.
Article 87.- Les auteurs de l'une des infractions prévues à l’article 86 ci-dessus encourent
également les peines complémentaires suivantes :

144
- la confiscation selon les modalités prévues par l'article 35 du Code Pénal, de tout objet
ayant servi ou destiné à commettre l'infraction ou considéré comme en étant le produit,
à l'exception des objets susceptibles de restitution ;
- l'interdiction dans les conditions prévues par l'article 36 du Code Pénal, pour une durée
de cinq (05) ans au moins, d'exercer une fonction publique ou une activité
socioprofessionnelle, lorsque les faits ont été commis dans l'exercice ou à l'occasion de
l'exercice des fonctions ;
- la fermeture, dans les conditions prévues par l'article 34 du Code Pénal pour une durée
de cinq (05) ans au moins, des établissements ou de l'un ou de plusieurs des
établissements de l'entreprise ayant servi à commettre les faits incriminés ;
- l'exclusion, pour une durée de cinq (05) ans au moins, des marchés publics.
Article 88.- 1) Est puni d’un emprisonnement de (01) à cinq (05) ans et d’une amende
de 100.000 (cent mille) à 1.000.000 (un million) F CFA ou de l’une de ces deux peines
seulement, celui qui, ayant connaissance de la convention secrète de déchiffrement, d'un
moyen de cryptographie susceptible d'avoir été utilisé pour préparer, faciliter ou
commettre un crime ou un délit, refuse de remettre ladite convention aux autorités
judiciaires ou de la mettre en œuvre, sur les réquisitions de ces autorités.

145
(2) Si le refus est opposé alors que la remise ou la mise en œuvre de la convention aurait
permis d'éviter la commission d'un crime ou d'un délit ou d'en limiter les effets, les
peines prévues à l’alinéa 1 ci-dessus, sont portées de trois (03) à cinq (05) ans
d'emprisonnement et l'amende de 1.000.000 (un million) à 5.000.000 (cinq millions) F
CFA.
Article 89.- Le sursis ne peut être accordé pour les infractions prévues dans la présente
loi.

146