Laudit Technique Informatique by Henri Ly

L’audit technique informatique
© LAVOISIER, 2005
LAVOISIER
11, rue Lavoisier
75008 Paris
www.hermes-science.com
www.lavoisier.fr
ISBN 2-7462-1200-5
Tous les noms de sociétés ou de produits cités dans cet ouvrage sont utilisés à des fins
d’identification et sont des marques de leurs détenteurs respectifs.
Le Code de la propriété intellectuelle n'autorisant, aux termes de l'article L. 122-5, d'une

part, que les "copies ou reproductions strictement réservées à l'usage privé du copiste et non
destinées à une utilisation collective" et, d'autre part, que les analyses et les courtes citations
dans un but d'exemple et d'illustration, "toute représentation ou reproduction intégrale, ou
partielle, faite sans le consentement de l'auteur ou de ses ayants droit ou ayants cause, est
illicite" (article L. 122-4). Cette représentation ou reproduction, par quelque procédé que ce
soit, constituerait donc une contrefaçon sanctionnée par les articles L. 335-2 et suivants du
Code de la propriété intellectuelle.
L’audit technique
informatique
Henri Ly
COLLECTIONS SOUS LA DIRECTION DE NICOLAS MANSON
Collection Management et Informatique

Collection Etudes et Logiciels Informatiques
Collection Nouvelles Technologies Informatiques
Collection Synthèses Informatiques CNAM
La liste des titres de chaque collection se trouve en fin d’ouvrage.

TABLE DES MATIÈRES
Préface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Claude PINET
Avant-propos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Chapitre 1. Historique et nécessité de l’audit . . . . . . . . . . . . . . . . . . . 15
1.1. Management et système d’information . . . . . . . . . . . . . . . . . . . 15

1.2. Rappel historique de l’audit . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3. Les différents acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.4. Les besoins et les nécessités d’audit informatique . . . . . . . . . . . . . 24
1.4.1. Le système d’information et la résistance aux changements . . . 25
1.4.2. Les postes de coûts et le concept ROI . . . . . . . . . . . . . . . . . 26
Foire aux questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Chapitre 2. Les contextes techniques pour les missions d’audit . . . . . . . 39
2.1. Les contextes techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.2. Les cycles de vie et les systèmes . . . . . . . . . . . . . . . . . . . . . . . 45
2.3. Les référentiels relatifs aux logiciels de qualité . . . . . . . . . . . . . . 51
2.3.1. La norme ISO/SPICE 15504 . . . . . . . . . . . . . . . . . . . . . . 52
2.3.2. La norme ISO/IEC 12207 . . . . . . . . . . . . . . . . . . . . . . . . 54
2.3.3. La norme 9126 relative à l’évaluation des logiciels . . . . . . . . 56
6 L’audit technique informatique
2.4. Classification générique des types d’audit . . . . . . . . . . . . . . . . . 59

Chapitre 3. Les diverses phases d’une mission d’audit . . . . . . . . . . . . . 67
3.1. Les diverses phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.1.1. Les principales phases et le schéma global . . . . . . . . . . . . . . 67
3.1.2. L’enquête préliminaire . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.1.3. Phase de vérification . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.1.4. Phase de restitution et du rapport . . . . . . . . . . . . . . . . . . . 74
3.2. Les techniques, les outils et la formation . . . . . . . . . . . . . . . . . . 77
3.3. Exemple et démarche pour les audits qualité
d’un service de support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3.3.1. Phase de pré-audit et de planification (14 %) . . . . . . . . . . . . 78
3.3.2. Phase de l’enquête préliminaire (25 %) . . . . . . . . . . . . . . . . 79
3.3.3. Phase de vérification rapide (20 %) . . . . . . . . . . . . . . . . . . 79
3.3.4. Phase de vérification ou réalisation de l’audit
proprement dit (25 %) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.3.5. Phase de restitution et du rapport (16 %) . . . . . . . . . . . . . . . 81
Chapitre 4. Les missions d’audit demandées

par la Direction générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.1. Audit de la politique informatique . . . . . . . . . . . . . . . . . . . . . . 87

4.1.1. Audit de la politique d’acquisition en vue
de l’informatisation (adéquation des produits verticaux, rentabilité) . . 87
4.1.2. Audit des projets et futurs projets
(audit de processus de développement) . . . . . . . . . . . . . . . . . . . 90
4.2. Audit relatif aux finances de la fonction informatique . . . . . . . . . . 94
4.2.1. Audit du budget et du suivi . . . . . . . . . . . . . . . . . . . . . . . 94
4.2.2. Audit sur la comptabilité analytique . . . . . . . . . . . . . . . . . 95
4.2.3. Audit sur les prestations internes . . . . . . . . . . . . . . . . . . . 96
4.2.4. Audit des coûts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Table des matières 7
Chapitre 5. Missions d’audit demandées par la Direction

technique/informatique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.1. Audit sur l’utilisation des logiciels (utilisation, licences, piratage) . . . 103
5.2. Audits de qualité de services et de l’informatique horizontale . . . . . . 106
5.2.1. La qualité de service des systèmes . . . . . . . . . . . . . . . . . . . 106
5.2.2. Audit de l’utilisation et de l’exploitation
des logiciels horizontaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.3. Audit d’un grand centre de serveur
ou d’un Business Intelligence Centre . . . . . . . . . . . . . . . . . . . . . . . 112
5.3.1. Les outils et éléments d’investigation . . . . . . . . . . . . . . . . . 114
5.3.2. Quelques résultats de l’audit . . . . . . . . . . . . . . . . . . . . . . 115
5.4. Audit des ressources humaines . . . . . . . . . . . . . . . . . . . . . . . . 117
Chapitre 6. Problème de sécurité et audits associés . . . . . . . . . . . . . . . 123
6.1. Plan de sécurité de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . 124

6.1.1. Plan de sécurité concernant la protection des matériels
(surtout les serveurs) et de la salle de stockage correspondante. . . . . . 126
6.1.2. Sécurité concernant les fichiers . . . . . . . . . . . . . . . . . . . . . 127
6.2. Sécurité dans le domaine des matériels et de la documentation . . . . . 128
6.2.1. Sécurité des matériels . . . . . . . . . . . . . . . . . . . . . . . . . . 128
6.2.2. La sécurité de la documentation . . . . . . . . . . . . . . . . . . . . 129
6.3. La sécurité des supports d’informations (les contenants) . . . . . . . . . 130
6.4. Sécurité dans le domaine des fichiers
(les contenus, les données et programmes) . . . . . . . . . . . . . . . . . . . . 131
6.4.1. Moyens de détection . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
6.4.2. Remèdes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
6.5. Audit et sécurité dans le domaine du réseau. . . . . . . . . . . . . . . . . 134
6.5.1. Normes de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
6.5.2. Systèmes garantissant la sécurité . . . . . . . . . . . . . . . . . . . . 138
6.5.3. Centre de contrôle de réseau . . . . . . . . . . . . . . . . . . . . . . 139
6.5.4. Surveillance du réseau . . . . . . . . . . . . . . . . . . . . . . . . . . 143
6.6. Audit et sécurité des applications Web. . . . . . . . . . . . . . . . . . . . 145
6.7. Audit d’un centre à la suite de plusieurs attaques . . . . . . . . . . . . . 147
6.7.1. Phase de pré-audit et de planification (0,5 jour) . . . . . . . . . . 148

6.7.2. Phase de l’enquête préliminaire (2 jours) . . . . . . . . . . . . . . 149
6.7.3. Phase de vérification rapide (2,5 jours) . . . . . . . . . . . . . . . 149
6.7.4. Phase de vérification ou réalisation de l’audit
proprement dit (3,5 jours) . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
6.7.5. Phase de restitution et du rapport (1,5 jour). . . . . . . . . . . . . . 151
6.7.6. Recommandations plus techniques. . . . . . . . . . . . . . . . . . . 153
6.8. Sécurité et droit de l’informatique . . . . . . . . . . . . . . . . . . . . . . 154
Chapitre 7. Plans types et exemples de procédures . . . . . . . . . . . . . . . 163
7.1. Plan type d’un programme de travail . . . . . . . . . . . . . . . . . . . . . 163

7.2. Plan type d’un rapport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
7.3. Exemples de procédures d’audit . . . . . . . . . . . . . . . . . . . . . . . 166
7.3.1. Exemple de procédure d’audit interne . . . . . . . . . . . . . . . . . 166
7.3.2. Exemple de procédure d’audit qualité pour la qualification
d’un produit logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
7.4. Annexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
7.4.1. Annexe 1 : plan type du rapport d’audit . . . . . . . . . . . . . . . . 182
7.4.2. Annexe 2 : exemple des éléments du référentiel . . . . . . . . . . . 183
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Annexe 1. Rappel des outils pour les auditeurs . . . . . . . . . . . . . . . . . . 191
A1. Rappel des outils pour les auditeurs . . . . . . . . . . . . . . . . . . . . . 191

A1.1. La technique de réunion . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
A1.1.1. Les interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
A1.1.2. Le questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
A1.2. Les autres techniques, les tests et les outils logiciels . . . . . . . . . . 193
A1.2.1. Outils de test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
A1.2.2. Outils (logiciels) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
A1.2.3. La formation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Table des matières 9
Annexe 2. Démarche pour un plan de sécurité . . . . . . . . . . . . . . . . . . 197
Annexe 3. Fonctions illicites des programmes malveillants . . . . . . . . . . 201
A3. La fonction illicite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

A3.1. La fonction à déclenchement différé . . . . . . . . . . . . . . . . . . . . 202
A3.2. La fonction de déplacement . . . . . . . . . . . . . . . . . . . . . . . . . 202
A3.3. La fonction autoreproductrice . . . . . . . . . . . . . . . . . . . . . . . . 203
A3.3.1. Définition des programmes dévastateurs . . . . . . . . . . . . . . 203
A3.3.2. Les virus par ajout . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
A3.3.3. Les virus par recouvrement . . . . . . . . . . . . . . . . . . . . . . 205
Annexe 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
A4. General principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

A4.1. General objectives of the procedure . . . . . . . . . . . . . . . . . . . . 209
A4.1.1. Application field . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
A4.1.2. Expected benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
A4.2. Conditions for application of the procedure . . . . . . . . . . . . . . . 210
A4.2.1. Quality audit Procedure Requirements . . . . . . . . . . . . . . . 210
A4.2.2. Pre-requisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
A4.3. Outpout of the quality audit process . . . . . . . . . . . . . . . . . . . . 212
A4.3.1. Quality audit report . . . . . . . . . . . . . . . . . . . . . . . . . . 212
A4.3.2. Recommandations . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
A4.4. Phases of the quality audit procedure . . . . . . . . . . . . . . . . . . . 213
A4.4.1. Diagram of the process . . . . . . . . . . . . . . . . . . . . . . . . 213
A4.4.2. A step by step procedure. . . . . . . . . . . . . . . . . . . . . . . . 215
A4.4.3. Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
A4.4.4. Modulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Lexique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
PRÉFACE
Il devient impossible de lire un magazine, de regarder la télévision ou

d’écouter la radio sans voir ou entendre les sujets concernant Internet en
général, l’informatique en particulier ainsi que de leurs problèmes ou
déboires : tel opérateur en désarroi, telle société en ligne en faillite, tel
système informatique ou serveur attaqué… Par conséquent, force est de
constater qu’Internet et l’informatique qui constituent une avancée
technologique indéniable possèdent leurs propres faiblesses.
Comment pallier ces dernières, comment protéger, détecter les points

faibles et vérifier l’adéquation de son système d’information et/ou de
ses outils sont les questions actuellement posées par bon nombre de
responsables et dirigeants.
Comprendre, apprendre, se former et s’informer ne sont-ils pas les

« piliers spirituels » et moyens nécessaires pour s’adapter aux nouvelles
technologies présentes, naissantes ou futures. Il en est de même pour la
surveillance de ces outils tel que l’audit informatique.
Ce livre sur la théorie et les pratiques de cette matière applique bien ce

principe par une démarche originale comprenant :
– un rappel historique et l’origine des concepts d’audit ;
– une sensibilisation par l’illustration des exemples et des cas ;
– une explication des principes de base et des notions techniques ;
– une présentation des solutions avec les différentes approches
(conseils et recommandations) ;
– des FAQ et réponses permettant de mieux appréhender les concepts

et répondre aux préoccupations des utilisateurs…
D’autre part, la démystification d’un sujet complexe, assortie

d’exemples et de conseils n’est-elle pas une condition sine qua non pour
la compréhension, l’assimilation et l’application ?
L’ouvrage d’Henri Ly est bien conforme à cette démarche de

démystification des moyens de l’informatique et de l’audit interne et
informatique. La conservation du patrimoine informationnel de
l’entreprise, donc sa pérennité ne peut se concevoir sans une
surveillance et revue accrue de son système d’information et de ses
outils informatiques. L’audit informatique est donc un moyen
incontournable et nécessaire pour ses dirigeants et ses actionnaires,
matière de pratique pour « l’entreprise bien gérée » donc matière de
formation et d’apprentissage pour tout cadre informatique ou étudiant
en situation professionnelle dans un proche avenir.
Claude PINET
Ingénieur expert
Membre de l’AFNOR
DG de CPI Consulting
AVANT-PROPOS
La connaissance est le début de l’action :

l’action, l’accomplissement de la connaissance.
Wang Yang Ming – Mandarin et philosophe chinois (1472-1529)
De nombreux théoriciens considèrent que l’entreprise est une « boîte

noire » avec, à l’entrée, des flux d’informations, et, à la sortie, des
produits finis d’objets et/ou d’informations.
Boîte noire complexe pour les uns, dans laquelle tous les éléments
doivent être coordonnés, synchronisés et « huilés », organisation
fonctionnant dans un environnement imparfaitement connu pour les
autres, l’entreprise se doit de fonctionner, survivre, se rendre
compétitive et conquérir les marchés au risque de décliner et mourir à
terme. Les entreprises ont besoin d’outils, de systèmes d’information et
d’informatique de plus en plus complexes. Ces outils doivent être
fiables et fonctionner parfaitement au risque de ralentir le processus de
production général et de perdre les clients et les marchés.
Pour fiabiliser ces moyens, il faut :

– diagnostiquer,
– vérifier,
– contrôler,
– prévenir les défaillances,
– trouver des moyens correctifs,
– formuler des recommandations pour les responsables décisionnels.
Ce sont les rôles des contrôleurs de gestion, de l’inspection, des

auditeurs et, particulièrement pour les systèmes d’information et
d’informatique, celui des acteurs de l’audit informatique.
Ce livre n’a pas pour ambition de présenter une méthode universelle

d’audit informatique, mais celle de fournir aux lecteurs :
– une définition claire et précise des principaux acteurs,
– une démarche, des approches pragmatiques plutôt qu’une méthodologie
pure,
– des exemples concrets dans des contextes et l’environnement des
CTI. (Centres de traitement des informations) sans omettre le rôle de
l’auditeur informatique dans chaque cas d’étude,
– des exemples d’exercices pour mieux assimiler les définitions et
concepts de chaque chapitre,
– un lexique récapitulatif des termes utilisés.
Si cet ouvrage donne des informations nécessaires à un non-spécialiste

pour mieux connaître l’environnement du contrôle et de l’audit et aux
vérificateurs ou auditeurs non-informaticiens, un fil conducteur ainsi
que des moyens d’aborder le volet audit informatique, son objectif sera
atteint.
CHAPITRE 1
Historique et nécessité de l’audit
La rigueur vient toujours au bout de l’obstacle.

Léonard de Vinci, peintre, ingénieur et savant italien (1454-1519)
1.1. Management et système d’information
En matière de gestion d’entreprise, quelle que soit la nature juridique

ou le type d’activité, on peut établir deux principes importants :
– aucune entreprise ne peut fonctionner sans un système d’information
de gestion, nommé souvent SI de l’entreprise ;
– aucune entreprise ne peut survivre et sa pérennité est mise en jeu si
elle ne possède pas un bon manager ou un chef d’entreprise
compétent. « Manager » consiste à trouver l’adéquation entre les
ressources financières, humaines, matérielles et les finalités des
projets et des objectifs de son entreprise.
Une société a donc besoin d’un bon manager qui sache piloter son
« système d’entreprise ». « Piloter » un système, c’est choisir un
objectif final (éventuellement composé de plusieurs sous-objectifs ou
objectifs d’étapes), définir la meilleure trajectoire, lancer le démarrage
puis corriger en permanence les écarts par rapport à la trajectoire et à
l’objectif lorsque les informations sur les états de l’environnement et
sur le comportement du système montrent que la planification initiale
ne peut être maintenue. En résumé, une activité de pilotage, pour un bon

dirigeant, comporte des actions de planification, de programmation, de
coordination et de contrôle.
Le système d’information de gestion d’une entreprise est formé par

l’ensemble des ressources et moyens utilisés pour traiter les
« informations » et atteindre son objectif ou ses finalités.
A partir des informations internes ou externes de l’entreprise, le

système enregistre les diverses opérations, les mémorise, les traite et
produit différents types de résultats. Il est à remarquer qu’un système
informatique n’est ni un système d’information, ni un système
d’information de gestion, il n’est qu’un outil ou moyen de traitement
et de compilation d’informations au service des deux autres.
Un système d’information peut être considéré comme un langage et un

réseau de communication (au sens large) d’une entreprise, d’une
organisation, construit consciemment pour représenter de manière
fiable et objective, de manière formelle, rapide et économique certains
aspects de son activité passée ou à venir.
Un système d’information de gestion est un système d’information qui

représente une réalité composée d’objets et d’événements. Un objet
est un élément mesurable qui vit et qui peut être transformé par un
événement. C’est un élément mobile dans l’espace et le temps. Un
événement est un fait. Il se produit à un moment, dans un lieu ou à un
endroit déterminé. Il se déroule dans un laps de temps et dans un
certain lieu.
Prenons un exemple : le déclenchement d’une commande d’un client

est un événement, l’article commandé est un objet. Une fois l’élément
parti, le stock diminue et l’ordinateur peut déclencher un autre
événement : imprimer un message signalant que le seuil minimum est
atteint par exemple.
Les volumes d’informations ne cessent de croître, et l’exigence de ces

derniers, en temps réel, ne cesse de s’amplifier depuis ces dernières
décennies, d’où l’importance de posséder des outils informatiques
Historique et nécessité de l’audit 17
fiables, cohérents et sécurisés. De ce fait, l’audit informatique a pris

de l’ampleur durant ces dernières années.
Le noyau du système de gestion d’information qui constitue le

« système d’information » est composé d’un ensemble de données
élémentaires ou « indicateurs », et de la combinaison de ces derniers
pour la conception du ou des « tableaux de bord ». Concernant la notion
de concept de système d’information de gestion, nombre d’entreprises,
privées ou publiques (dont France Télécom) déterminent et respectent
les quatre principes suivants : la rigueur, l’unicité, la fiabilité et la
cohérence. Concepts que nous détaillons ci-dessous :
– rigueur : une précision et une définition claire des données
élémentaires ou indicateurs doivent être appliquées. La circulation
d’informations et les délais d’obtention, les méthodologies de saisie
(quand, comment, où, par qui) ainsi que celles de calcul et
d’agrégation des éléments doivent être bien définis et respectés ;
– unicité : l’unicité de la conception d’un indicateur, de son mode de
saisie, de son mode de remontée doit être réelle et respectée. Ce
concept garantira que les valeurs utilisées par les divers responsables,
quel que soit leur lieu d’exercice de gestion et leur niveau de
responsabilité sont identiques rendant possible une comparaison des
résultats, éléments de base de discussion et d’amélioration ;
– fiabilité : la fiabilité des informations transmises doit être garantie.
A chaque remontée d’indicateurs, un responsable doit valider les
valeurs transmises. On remarque à ce niveau encore, l’importance du
rôle des auditeurs internes ;
– cohérence : le système d’information se présente comme un ensemble
cohérent. Les indicateurs ne doivent pas être redondants et doivent
couvrir tous les domaines d’activité.
Un domaine est couvert par un ensemble d’indicateurs riche et

complexe que l’on doit énumérer et évaluer à sa juste valeur en
fonction de son degré d’importance. En effet, le fait d’avoir trop
d’informations nuit et ralentit le processus de mise à jour, donc de
décision.
C’est dire l’impact du rôle que doivent jouer les vérificateurs,

contrôleurs internes ou externes dans la vie de l’entreprise pour la
certification et la fiabilisation des informations.
Enfin les trois axes d’analyse du système d’information sont :

temporel, géographique, par entité ou par nature.
1.2. Rappel historique de l’audit
Depuis l’Antiquité, les hommes ont senti la nécessité d’utiliser un

véritable système de comptabilité. Par exemple, 2000 ans avant J.-C.,
les Sumériens (habitants de la Mésopotamie sur le Golfe Persique)
avaient un code de la comptabilité qui incluait jusqu’à la comptabilité
analytique. Le commerce entre les différents peuples (Romains,
Egyptiens, Grecs...) conforta la technique comptable. La nécessité de
gérer leur domaine amena l’Eglise et les administrations publiques, au
Moyen-Age, à perfectionner le système comptable.
Ainsi, le premier trait de comptabilité, en partie double, fut l’œuvre du

Frère Lucas Pacioli. Progressivement, le besoin de contrôler les
comptes imposés prit de l’ampleur. Les premiers auditeurs seraient les
Missi dominici sous Charlemagne et, au XIIIe siècle, dans les cités de
Pise et de Venise, des comptables faisaient office d’auditeurs de la
municipalité. Il apparaît que les organisations créées sous l’initiative
royale, ecclésiastique ou municipale ont contribué au développement
de la technique comptable et de l’activité d’audit.
Cependant, il faut attendre la fin du XIXe siècle pour voir la naissance

des associations de comptables. Ce fut le cas en France avec la
création, par décret, de l’Ordre des experts comptables et comptables
agréés et de la Compagnie nationale des commissaires aux comptes.
Aux Etats-Unis, the Security Act de 1935, loi fondamentale sur le

contrôle des comptes des sociétés américaines, impose l’opinion
favorable d’un expert comptable indépendant sur tous les comptes et
bilans.
Cette certification ne serait accordée par les experts qu’après de

nombreuses vérifications aussi rigoureuses que coûteuses d’où l’idée
de contrôle interne avant la « transmission » des documents aux
experts externes afin d’alléger les coûts. Ainsi, à l’origine, la fonction
d’audit interne fut d’ordre purement comptable. Placés devant le
besoin de créer ce contrôle interne, les dirigeants américains
cherchaient à tirer le maximum d’avantages pour leur propre compte,
et de ce fait les domaines d’investigations des auditeurs internes se
trouvaient, élargis surtout vers 1950.
L’Institut français des auditeurs et contrôleurs internes créé à Paris en

1965 (l’IFACI), organisme rattaché à l’Institute of Internal Auditors
fondée à New York en 1941, a donné la définition suivante « l’audit
interne est la révision périodique des instruments dont dispose une
direction pour contrôler et gérer l’entreprise ».
Compte tenu de l’évolution du métier, l’IFACI – dont le siège qui est

à Paris (rue Henri Bergson, 8e) – a été rebaptisé l’Institut français des
auditeurs et consultants internes. Cet organisme, qui est chargé de
représenter la profession d’audit, a pour mission de promouvoir son
développement et de servir les auditeurs et conseillers internes
provenant de tous horizons.
En ces temps de rigueur et de forte concurrence, les fonctions de

contrôle de gestion et d’audit sont mises en valeur et les activités
correspondantes sont plus que jamais à l’ordre du jour.
L’entreprise doit consolider ses parts de marché actuelles, tout en en

conquérant de nouveaux, en s’appuyant sur ses structures, son
organisation, ses acquis. Elle doit aussi sécuriser ses systèmes
d’information en général, d’information de gestion en particulier, et
consolider ses patrimoines et acquisitions...
Bref, elle a besoin de plus d’efficacité et de rentabilité. Les dirigeants

doivent pouvoir évaluer le système de gestion, vérifier la fiabilité des
informations et s’informer par tests de façon intermittente.
Il est à noter qu’actuellement, avec la mondialisation de l’économie et

des finances, les audits de diagnostic et de fusion deviennent des
activités en croissance et très à la mode. Dans le domaine du contrôle,
on trouve des personnes occupant des postes différents et exerçant des
fonctions distinctes. Néanmoins, elles sont souvent appelées à
travailler ensemble car leurs missions respectives concourent à la
bonne marche et à l’expansion de l’entreprise. Le paragraphe suivant
permet de détailler les différents acteurs du monde du « contrôle ».
1.3. Les différents acteurs
Les mots de contrôle et audit suscitent une certaine appréhension, ils

inquiètent et intriguent à la fois. On confond souvent les activités et
ces fonctions, d’autant plus que ces dernières, récemment apparues
dans l’entreprise, sont mystérieuses et multiformes.
En effet, de par sa fonction, un réviseur-comptable doit contrôler les

documents comptables, mais un responsable de sécurité devrait aussi
exécuter des contrôles et des inspections...
Cependant que ce soit un consultant, un contrôleur de gestion, un

responsable de sécurité, un auditeur interne, un organisateur ou un
réviseur-comptable, il doit avoir une capacité d’écoute et une « envie
d’entendre » certaines vérités...
Essayons de définir les fonctions de ces acteurs :

– l’organisateur est la personne intervenant à la demande de la
Direction et a pour mission de proposer une structure avec la
définition précise des rôles et responsabilités de chaque élément de la
structure ;
– le responsable de sécurité a pour mission d’assurer le contrôle et
l’inspection des sites afin de détecter les risques éventuels de
l’entreprise, c’est-à-dire d’assurer la sécurité physique des individus et
du patrimoine. Cette personne a aussi pour mission de vérifier les
normes imposées par la législation et le suivi du règlement intérieur
établi ;
– le contrôleur de gestion est, quant à lui, l’assistant de la Direction

qui établit des budgets, fait des prévisions et contrôle les réalisations.
Il conçoit ou participe à la conception d’un système d’information et
en assure le suivi. Il peut exécuter des contrôles internes d’une façon
continue, détecter et analyser les écarts ;
– l’auditeur interne intervient suivant un planning ou sur ordre de
mission. Il prend une « photo », à un instant donné, d’un service,
d’une organisation... Il apprécie l’état du contrôle interne (ou effectue
un contrôle du système de contrôle interne). Les résultats de ses
travaux sont édités dans un rapport comprenant constats et
recommandations. Si tout fonctionne correctement, son rapport sera en
quelque sorte un satisfecit ;
– le réviseur-comptable apprécie la validité des documents issus de la
comptabilité qui seront rendus publics : le bilan, le compte des
résultats, les informations annexes… Cette personne certifie ces
documents dans le délai imposé par la loi ou le marché. Elle fournit en
quelque sorte un quitus : c’est le rôle principal du réviseur-comptable
externe ;
– le consultant est la personne qui subit les lois du marché (de l’offre
et de la demande) et possède une spécialité et une compétence
reconnues. Il formule des avis et conseils relatifs aux problèmes
détectés. On peut citer, par exemple, les consultants administratifs ou
comptables ou d’organisation.
Nous avons défini les fonctions de ces « différents » acteurs, nous

pouvons citer maintenant leurs caractéristiques et qualités communes.
Ils doivent posséder des capacités d’organisation, de sens pratique,
certaines facilités de contact. Ils doivent pouvoir aussi faire preuve de
diplomatie, d’impartialité et enfin avoir des dispositions pour
l’analyse et la synthèse.
En résumé, ils doivent montrer un sens aigu de l’adaptabilité et une

capacité réelle d’écoute. S’ils doivent tous posséder ces qualités
humaines (sauf le responsable de sécurité et le réviseur externe peut-
être), il existe néanmoins des différences concernant leur domaine de
compétence et leur rattachement hiérarchique :
– Direction générale (DG) ;
– Direction financière et comptable (DFC) ;

– Direction technique (DT).
Les domaines de compétence sont les suivants :

a) contrôle comptable ;
b) contrôle technique, commercial, comptable, sécurité ;
c) diagnostic, avis et conseil ;
d) sécurité physique des systèmes et/ou des agents ;
e) avis et conseil, planification d’un projet ;
f) contrôle des résultats des divers services, consolidation confection
des tableaux de bord de suivi.
Le tableau 1.1 résume la direction d’attache de chaque acteur ainsi

que son domaine d’intervention et de compétence.
Domaine de
Agent Direction d’attache
compétence
Organisateur DG, DFC (Direction E

des Finances et comptabilité)
Responsable de sécurité DT (Direction technique) D
Contrôleur de gestion DG, DFC F
Auditeur interne DG, DFC B
Réviseur comptable Indépendant A
Consultant Indépendant C
Tableau 1.1. Direction d’attache et domaine d’intervention

Points de Statut Auditeur Réviseur

comparaison interne externe
1. But des assure les intérêts des actionnaires et X
travaux tiers, assure les intérêts de la Direction X
générale
2. Moyens liberté concernant le programme X
d’action d’action, travail en fonction d’une X
demande planifiée de la Direction
3. Eléments Régularité et sincérité des informations X X

à contrôler rendues publiques, régularité et sincérité
des informations internes X
Sécurité et conservation du patrimoine d
l’entreprise, sécurité des personnes X
Outils de gestion (adéquation et X
efficacité) X
4. Opération Détection :
d’investigation des fraudes X X
de la non-sincérité des comptes X
des erreurs (par ex : des bilans, X
journaux), des gaspillages, des pertes, X X
relevés des omissions X
X
relevé des poins faibles ou
X
inadéquation des méthodes ou outils X
de gestion.
X
Evaluation des manques à gagner
5. Eléments Les informations comptables X X

et (opérations, patrimoine, divers
domaines comptes…), X
à contrôler les modes d’organisation
dans la société, X
le personnel, les fonctions, les X
structures,
la politique générale de l’entreprise
6 - Les Certifications ou émissions des réserves, X

résultats relevés des fraudes et des délits X
des travaux rapports, notes de synthèse, constats, X
et les recommandations, X
conception des fiches de suivie X
Tableau 1.2. Différence entre une révision externe et un audit intene

Les rôles des différents acteurs étant définis, il nous importe de définir
l’audit interne et l’audit informatique, ainsi qu’un rappel rapide du
contexte de travail potentiel des auditeurs informatiques.
L’audit interne est une activité indépendante

d’appréciation, de contrôle de l’exécution et de l’efficacité
des autres contrôles, en vue d’assister la Direction.
Pour l’audit informatique, nous préconisons la définition suivante :
L’audit informatique est une activité de contrôle du

management informatique pour apprécier l’utilisation,
l’exécution, l’efficacité et l’adéquation des éléments
constitutifs du système informatique ou du système
d’information avec l’objectif et l’orientation de
l’entreprise.
Afin de mieux appréhender la différence entre une révision externe et

un audit interne, nous présentons six points de comparaison résumés
dans le tableau 1.2 de la page précédente.
Il est à remarquer que le service d’audit ou les auditeurs eux-mêmes

possèdent une certaine initiative en ce qui concerne le programme
d’action, mais pas un réel pouvoir de décision.
1.4. Les besoins et les nécessités d’audit informatique
Comme nous l’avons vu, pour les leaders et dirigeants, le besoin

d’audit est provoqué par celui d’obtenir le retour des informations sur
des organisations mises en place. Cela date de l’Antiquité, mais qu’en
est-il pour les éléments justifiant la nécessité et les besoins d’audit
informatique ?
En fait, on peut identifier cette nécessité et ces besoins d’audit

informatique par les trois éléments ci-après :
– c’est d’abord dans le cadre du prolongement du développement de la
théorie de la révision comptable que l’examen et le contrôle des
systèmes d’informatique de gestion ont vu le jour. En France, dans les

années 1970-1980, le Conseil Supérieur de l’ordre des Experts
Comptables a fixé à l’usage de ses membres les principes
fondamentaux de révision : « la révision des comptabilités traitées par
des moyens informatiques » puis « la révision dans un environnement
informatique » (recommandation de révision n°7) ;
– les dirigeants ressentent, au fil des années, le besoin d’audit
informatique afin de connaître l’impact du changement dû aux
introductions de systèmes informatisés dans l’environnement du
travail ;
– le besoin de connaître les chiffres et le retour des investissements
(ROI) avec les divers coûts et les risques encourus.
En effet, pour tous les dirigeants, l’analyse des coûts et le ROI sont
des indicateurs-clés pour la gestion de leurs entreprises. Dès lors, ces
points sont des éléments primordiaux pour les auditeurs car les
fonctions informatiques et les systèmes (générant des coûts) font
partie de leurs domaines de compétences et d’examen. Effectuons un
rapide rappel de ces éléments et de leurs concepts associés.
1.4.1. Le système d’information et la résistance aux changements
Avant de détailler ces éléments pour mieux connaître le système

d’information de l’entreprise, il nous importe d’appréhender un
phénomène, que parfois les auditeurs peuvent rencontrer, appelé la
résistance aux changements. En effet, nombre d’organisations
rencontrent des problèmes suite à l’implémentation d’une nouvelle
technologie en général, et d’un système informatique en particulier.
Pire encore, il existe parfois la fourniture de fausses informations ou
« sabotage » pendant la phase de pré-étude en vue d’instaurer un
nouveau système.
La résistance au changement n’est pas un problème nouveau, mais

déjà identifié par Michel Crozier, professeur à Paris, à Harvard aux
Etats-Unis et fondateur de la sociologie des organisations. Henry
Mintzberg, économiste et également professeur aux Etats-unis a
également parlé de ce problème. En effet, résumée d’une façon
succincte, la résistance aux changements se caractérise par la peur du

transformation du contexte de travail, la peur de la perte du pouvoir,
des acquis et par l’appréhension de l’apprentissage des nouveaux
systèmes. Ainsi l’opposition envers l’innovation, l’automatisation
(première), l’introduction d’un nouveau système d’information et le
changement peut être due aux intérêts d’un groupe ou personnels par
rapport au statu quo ou par rapport à un système déjà en vigueur.
Nous nous permettons de signaler ce phénomène afin de mettre en
évidence la raison pour laquelle, parfois, un auditeur informatique ne
trouvait pas de failles techniques vis-à-vis d’un nouveau système mis
en place, mais un rendement faible, inattendu avec une démotivation
et une mauvaise ambiance.
Dans ce contexte, il est du devoir de l’auditeur de signaler cet état des

choses à la hiérarchie de ce service et à la Direction générale et de ne
plus continuer à rechercher les points faibles techniques. La mission
est dès lors hors de son domaine de compétence. C’est plutôt un
problème sociologique et managériale. Ce n’est plus de l’audit
informatique que l’on a besoin mais d’un audit social. De ce fait, le
rôle de l’auditeur est le suivant avant de passer toutes les informations
à la Direction générale :
– identifier la motivation des utilisateurs (vis-à-vis du nouveau
système mais non individuelle) ;
– identifier s’il existe une stratégie d’adaptation aux changements ;
– identifier s’il existe des attentes irréalistes du nouveau système.
1.4.2. Les postes de coûts et le concept ROI
1.4.2.1. Les postes de coûts

Le projet d’informatisation d’une entreprise ou la refonte de son
système informatique constitue un investissement important.
Pour évaluer le coût de l’informatique on peut se poser la question de

savoir quelle est la part des ressources que l’on consacre ou que l’on
devrait consacrer à la création, au développement et à la maintenance
du système informatique. On considère que le budget informatique est

constitué par un certain nombre de charges.
L’évaluation du coût de l’informatique est déterminée suivant deux

cas différents.
1ercas : l’entreprise ne possède pas encore les outils informatiques,

mais envisage l’automatisation. Ceci est de plus en plus rare, sauf cas
particulier des PME ou chez les artisans. Dans ce cas, l’équipe
dirigeante doit s’assurer que le coût engendré ne risque pas de mettre
en péril l’équilibre financier de l’entreprise.
A chaque étape des études de conception du système, on pratique,

simule les calculs d’évaluation, et on rectifie au besoin. On peut
comparer cela à un pilotage à vue devant aboutir à un objectif qui
consiste à instaurer un système conforme aux besoins et aux capacités
financières de la société.
2e cas : l’entreprise possède un système informatique. L’évaluation du

coût de l’informatique revient à déterminer le budget annuel pour
l’informatique en fonction de l’historique et des prévisions liées aux
missions que devra accomplir le système.
On exprime les montants par poste et par période (trimestrielle,

semestrielle...) et à mesure que les dépenses sont connues, il faut
calculer les écarts pour contrôler et, éventuellement, procéder à des
rectifications.
1.4.2.2. Les diverses charges informatiques de l’entreprise

En dehors des charges intrinsèques du matériel et de celles du logiciel,
on doit distinguer les charges environnantes :
– les charges de premier établissement ;
– les charges répétitives ou périodiques.
1.4.2.2.1. Les charges de premier établissement

Ce sont les charges qui ne se rencontrent qu’une fois pour une
application ou un projet donné. Par exemple :
– le coût de l’étude d’opportunité ;

– les dépenses pour la sensibilisation du personnel ;
– les coûts de conversion (initiation, formation) ;
– les frais de réorganisation partielle ou totale ;
– les coûts ou pertes dues à l’interruption des opérations ;
– les dépenses de formation du personnel informaticien ou utilisateur ;
– le coût d’analyse fonctionnelle ;
– le coût d’analyse organique ;
– le coût de programmation ;
– le coût des essais ;
– le coût d’établissement de la documentation.
1.4.2.2.2. Les charges périodiques ou répétitives

Ce sont les charges qu’on retrouve de par leur nature, d’exercice en
exercice, tant que le système informatique fonctionne. Il convient de
remarquer qu’elles sont fonction des configurations choisies au
préalable.
Exemple : dans un environnement de mini-ordinateurs, lors de la

vérification des coûts, il faut tenir compte des charges du personnel
d’exploitation existant ainsi que des frais généraux, mais dans un
contexte de micro-ordinateurs, les frais généraux sont réduits et, en
théorie, les frais de personnel exploitant doivent être inexistants.
Ces charges constituent la base d’un budget informatique annuel,

appelé aussi budget de fonctionnement. Ce sont :
– les charges de personnel ;
– les charges de matériel (location, maintenance) ;
– les charges locatives des logiciels ;
– les charges de fournitures ;
– les frais généraux inhérents au système informatique (locaux,
climatisation, entretien, assurance).
D’autre part, il importe de savoir que la comptabilité nous permet,

dans le cas d’achat de matériel, de programmes ou progiciels,
d’affecter ces dépenses dans des postes à amortir et que certaines
d’entre elles, les salaires, les charges de location du matériel ou des
programmes par exemple, peuvent être portées directement au compte
d’exploitation général.
Enfin, dans les centres informatiques, on commence à mettre en valeur

le coût des erreurs.
Une simple faute d’analyse ou de manipulation peut engendrer des

erreurs de traitement qui nécessitent des recherches, des rectifications,
des recyclages causant des retards dans la chaîne de traitement.
Le budget initial prévu sera alors modifié créant des écarts entre
prévisions et réalisations. On appelle aussi ce coût, le coût de la « non-
qualité ».
Les missions ainsi que les rôles de l’auditeur informatique relatifs aux
problèmes de coût seront développés plus loin. Essayons pour l’instant
de déterminer les problèmes de retour d’investissement en
informatique.
1.4.2.3. Le concept ROI (retour d’investissement) en informatique

Le ROI (Return on Investment) ou le RSI en français (retour sur
investissement) est une mesure économique utilisée par les dirigeants
et responsables pour évaluer l’impact d’une décision. Cette dernière
peut être une décision d’investissement ou d’affaire en général.
Appliqué en informatique, le ROI reflète la qualité d’un
investissement en informatique : investissement en matériel ou en
logiciel.
A part l’investissement matériel qui peut être considéré comme

amortissable par la législation fiscale en matière de comptabilité, il
importe de savoir le gain engendré par l’ensemble informatique pour
l’entreprise par le calcul et la définition des critères au préalable. Les
éléments suivants les plus utilisés sont le temps, les coûts d’acquisition
et la satisfaction des utilisateurs (sans compter l’économie du
personnel engendrée par l’automatisation). Les outils pour et résultant

d’une démarche ROI sont donc ceux qui permettent de fournir des
chiffres importants collectés (les indicateurs clés de performance) et
des tableaux de bord synthétiques.
La pratique du ROI permet au moins de recouper ces trois éléments :

– transparence et visibilité ;
– maîtrise des coûts ;
– amélioration de la qualité des services et des prestations.
Ces éléments permettront alors d’évaluer la qualité de la décision

prise. L’évaluation est d’autant plus pertinente que les indicateurs clés
reflètent ou rapprochent la réalité contextuelle de l’entreprise. Dans
une mission d’audit informatique d’investissement, les rôles de
l’auditeur pourraient être les suivants :
– vérifier la pertinence des indicateurs clés ;
– vérifier la fiabilité des indicateurs recueillis ;
– vérifier les bases de comparaison et leur fiabilité ;
– contrôler l’exactitude des prestations préconisées dans un contrat de
sous-traitance.
En effet, bon nombre d’entreprises demandent souvent un support

externe concernant l’évaluation de leurs indicateurs de performances
(exemple : utilisation des logiciels et des prestations d’une entreprise
spécialisée dans le conseil et du calcul de rentabilité et de performance
informatique).
Ces concepts étant exposés, revenons aux préoccupations techniques

pour compléter notre background d’auditeur. Ainsi, afin de pouvoir
exécuter des audits informatiques, l’auditeur se devrait de s’informer
sur le contexte technique ainsi que sur les méthodes d’analyse et
d’approche utilisées pour la conception du système d’information de
son entreprise. De ce fait, bien connaître les méthodes, le cycle de vie
d’un système, l’analyse de l’existant ainsi que les diverses étapes de
l’informatisation, constituent un background important pour les
auditeurs en informatique. Surtout si l’intéressé est amené à auditer un
projet dans un contexte de vérification de la politique informatique de
son entreprise. Les chapitres suivants identifient les contextes

techniques dans lesquels les auditeurs seront amenés à exercer leur
métier et rappellent les concepts de cycle de vie des projets.
Résumé du chapitre 1
Ce chapitre permet aux lecteurs d’appréhender l’historique de
l’audit ainsi que la nécessité et les raisons d’être de celui-ci au
sein d’une entreprise. Il rappelle aussi les quatre caractéristiques
primordiales du système d’information de l’entreprise qui sont la
rigueur, l’unicité, la fiabilité et la cohérence.
D’autre part, la surveillance des coûts, des budgets ainsi que

l’obsession du retour d’investissement sont souvent les principales
raisons des demandes d’audits des dirigeants. Néanmoins, il faut
aussi noter que l’appréhension des résistances aux changements
de la base est une préoccupation managériale. Enfin, ce chapitre
identifie également les différents acteurs dans les processus de
contrôle et de vérification au sein d’une entreprise.
FOIRE AUX QUESTIONS
(CHAPITRE 1)
Dans le but de se familiariser avec les notions acquises, le lecteur

pourra par exemple remplir le schéma d’enchaînement des besoins et
de la répartition des tâches. Il pourra choisir les éléments adéquats de
la liste ci-dessous et les placer dans les différents pavés, sous forme
d’un schéma d’enchaînement (sachant que « le losange » représente
un test :
– mission confiée à l’audit interne ;
– pour un dirigeant ;
– pour tiers et actionnaires ;
– intervention du réviseur externe ;
– besoin d’évaluer le système de gestion ;
– vérifier la fiabilité des informations ;
– s’informer par test.
Contraintes : juridique, fournisseurs, concurrences.
Objectifs : profits, qualité, services.

Besoin de sécurité, d ’efficacité

et de rentabilité de la société
Vérifier la fiabilité
de l ’information
OUI ? Pour un dirigeant
Non
Pour tiers et actionnaires
Figure 1.1. Schéma d’entraînement
NOTA BENE.– Se référer au chapitre pour l’exercice, sinon, les

éléments de réponses sont donnés à la page suivante.
Question 1 : quelle est la différence entre un contrôle interne et un

audit ?
Réponse : le contrôle interne est effectué par les agents de

l’entreprise, alors que l’audit peut l’être par un cabinet externe. Le
contrôle interne doit être effectué par un agent ou par le contrôleur de
gestion d’une manière continue, alors que l’intervention de l’audit
dans un service précis est ponctuelle.
Si l’entreprise ne possède pas un service d’audit interne, elle peut faire

appel à un audit externe. Enfin, il est à remarquer que l’entreprise
d’une certaine taille doit d’abord posséder un service de contrôle
interne avant la mise en place d’un service d’audit interne.
Foire aux questions 35
Besoin de sécurité, d ’efficacité

et de rentabilité de la société
Besoin d ’évaluer le système

de gestion
S ’informer par test
Vérifier la fiabilité
de l ’information
Oui ? Pour un dirigeant

Non
Mission confiée à Pour tiers et actionnaires
l ’audit interne
Intervention du réviseur externe
Figure 1.2. Schéma d’entraînement
Question 2 : quel est le rôle de l’auditeur interne comparativement à

un contrôleur de gestion dans le cas de la détection d’une erreur de
gestion ? Et en particulier en matière de produit logiciel ?
Réponse : le rôle de l’audit interne n’est pas de se substituer ou de

remplacer un responsable, ni un contrôleur de gestion. Dans ce cas
l’audit doit révéler l’erreur au contrôleur de gestion et faire remonter
l’information à la Direction générale. En matière de produit logiciel,
seul le contrôle après ou avant la conception et/ou l’implantation du
nouveau logiciel peut être du ressort de l’auditeur informaticien.
Question 3 : s’assurer que l’organisation, les objectifs, les politiques

de la société soient conformes aux réglementations en vigueur, est-ce
du ressort d’un auditeur ? Et qu’en est-il de la fiabilité des
informations qui remontent à la Direction ?
Réponse : les deux rôles cités sont bien ceux de l’auditeur interne.
Question 4 : les contrôles de routine ou la détection systématique

des fraudes (liées à l’informatique), est-ce du ressort de l’auditeur
informatique ?
Réponse :
1) La recherche systématique des fraudes ne devrait pas être

l’attribution des auditeurs. Elle est plutôt du ressort de la personne
responsable de la sécurité (au sein du service informatique) ou à
défaut, de l’Inspection générale, par exemple dans une administration
(ce terme d’inspection est encore très utilisé dans les administrations
et les grandes banques françaises).
2) Les contrôles réguliers ou de routine sont du domaine de

compétence du contrôleur de gestion ou à défaut des chefs de service.
Ils ne sont en aucun cas celui de l’auditeur.
Question 5 : elle est relative aux enjeux et aux risques informatiques.

La possession d’un système informatique et d’un système
d’information intégré exige un investissement coûteux et ces deux
systèmes constituent un patrimoine primordial et vital pour
l’entreprise. De par sa nature et son étendue, l’informatique comporte
des risques.
En fait, quels sont les enjeux directs et les enjeux indirects ? D’autre
part, quel est le rôle d’un auditeur en ce qui concerne les risques
informatiques ?
Réponse : concernant les enjeux, par exemple, en cas

d’indisponibilité prolongée d’un centre de calcul, la location du temps
de calcul à un service externe est un enjeu direct.
La liste ci-dessous constitue les enjeux indirects :

– image de marque de la société ;
– perte de trésorerie résultant des retards dans l’exécution du
traitement des opérations financières ;
– conflit généré à cause des retards de traitement ou de planification

(problème de responsabilité) ;
– défaut dans les procédures d’exploitation entraînant l’écrasement
des informations ;
– vol d’un fichier de l’entreprise.
Concernant ce dernier point, ce genre de « délit » n’engendre pas une

perte financière directe pour l’entreprise, mais, à terme, le fichier volé
pourrait profiter à des concurrents et, de ce fait, les chiffres d’affaires
peuvent subir des variations. En effet ce type de perte ne se traduit pas
tout de suite au plan comptable dans le compte d’exploitation d’une
façon précise.
Enfin concernant les risques informatiques, le rôle de l’auditeur est de

s’assurer que les systèmes soient dotés d’une protection efficace et
que leur utilisation se fasse à bon escient. Il peut également conseiller
les démarches et mesures si l’opportunité se présente.
CHAPITRE 2
Les contextes techniques

pour les missions d’audit
La seule vraie science est la connaissance des faits.

Georges Louis Leclerc, Comte de Buffon,
naturaliste français (1707-1788)
En 500 avant J.-C., Sun Tzu, stratège chinois a écrit L’Art de la

guerre, livre de chevet de tous les grands généraux et stratèges, tels
Alexandre, Napoléon, Mao, Staline.
Sun Tzu écrivit que pour gagner une bataille, il faut d’abord attaquer
l’esprit de l’ennemi et connaître le terrain. Ramener à notre contexte,
cela peut signifier qu’il est primordial que les auditeurs identifient et
prennent connaissance du contexte, de l’environnement, des cycles de
vie du logiciel ou projets, les référentiels ainsi que les phases (où ils
peuvent contribuer) avant d’auditer et de procéder à des vérifications...
Au chapitre précédent, nous avons rappelé l’historique de l’audit, ses

raisons d’être et sa nécessité. Maintenant, il nous importe de connaître
les contextes techniques, les cycles de vie des produits logiciels et
quelques référentiels pour pouvoir appréhender l’audit informatique.
2.1. Les contextes techniques
Le monde informatique est en perpétuelle évolution. Du monde des

mainframes (des gros systèmes), on est passé à celui des mini-
informatiques, puis avec l’apport accru des techniques d’intégrations
et de la miniaturisation des composants, on est arrivé actuellement à
l’ère des micro-ordinateurs serveurs et PC. L’informatique autrefois,
c’était de grosses structures (centres de calcul ou appelés aussi les
CTI, centres de traitement) avec une panoplie de personnel : chef de
centre, chef d’exploitation (personnage important pour coordonner et
planifier les centres fonctionnant en trois/huit), ingénieurs systèmes,
agents de traitement… et avec des terminaux directement connectés
au mainframe. De nos jours, il existe des structures plus légères avec
des PC connectables via les réseaux au centre de serveurs…
Cependant, mouvement de balancier ou nécessité, on assiste à un
retour des centres de calcul ces dernières années, avec des mainframes
et des super ordinateurs, bien entendu avec des possibilités de
connexion des PC des utilisateurs via Internet, RTC et réseaux VPN
(Virtual Private Networks) utilisant du VNC (Virtual Network
Computing).
On voit aussi fleurir de nouvelles appellations pour ces centres de

traitement ou de calcul tel que « Super Info Centre » ou Business
Intelligence Centre (ou BIC, appellation qui commence à apparaître
dans la littérature). Lieu saint, parfois ô combien virtuel ! En effet, on
ne sait plus où se trouve exactement la localisation des données et des
systèmes (en raison de l’infogérance), ni la provenance exacte des
réponses à nos requêtes. En effet, quelquefois ces réponses sont issues
de la compilation d’un traitement des différentes données extraites à
partir des divers SGBD délocalisés. Ainsi, on est capable de fournir
aux utilisateurs des informations, certes issues des bases de données
de l’entreprise, mais aussi des informations provenant de l’extraction
de bases de données externes d’une façon complètement transparente
pour l’utilisateur final. L’exemple le plus marquant, c’est le pouvoir
de faire du benchmark en temps réel pour nos prises de décision ou
d’obtenir des informations complètement en dehors des activités
principales même de son entreprise !
Contextes techniques pour les missions d’audit 41
Pour illustrer la complexité technique, nous donnons l’exemple de

l’évolution d’un centre d’informatique dans un centre de recherche.
En l’espace d’une quinzaine d’années, il est passé d’un centre de type

de mainframe à un centre de serveurs correspondant à deux types de
technologie complètement différents.
Vers les années 1990, ce centre était équipé d’un mainframe IBM de
type S390. De 1996, exactement mi 96, à l’année 1998, on a migré les
applications vers les serveurs de type mono et biprocesseurs avec des
systèmes UNIX. La grosse machine (et ses systèmes d’applications
propriétaires) fut démantelée en 1999.
Du point de vue de la sauvegarde des données, on était passé des

disques durs IBM au système des disques RAID avec un robot de
sauvegarde. Actuellement, les serveurs sont de plusieurs types : la
majorité sont des quatri-processeurs dont la moitié tourne sous Unix,
l’autre sous Linux. Le nombre total des serveurs et stations Unix et
Linux s’élève à 156 unités. Il s’agit de processeurs au format
slides s’encastrant dans des racks. Du point de vue réseau : le centre a
vu évolué ses installations des systèmes de type Token Ring avec
Ethernet vers un système de backbone (cœur de réseaux) d’un giga, en
passant par le réseau ATM (Asynchronous Transfert Mode) associé à
Ethernet. L’ensemble du réseau interne est connecté aux autres centres
par des liaisons spécialisées (6 méga).
Concernant les applications, on peut citer les suivantes : les

applications de type scientifiques et techniques, les bases de données
(Oracle, mySQL, SQL Server) et les applications bureautiques
utilisant directement des logiciels « Office » du marché avec de
nombreux développements associés (développés avec les utilitaires et
macros). Le nombre total de serveurs PC Windows est de quarante.
Du côté matériel ou hardware, des constructeurs SUN, IBM ont aussi

miniaturisé leurs composants et cartes, et, actuellement, il est en
vogue d’avoir des lames (UC, d’interfaces…) installées dans des racks
pré-câblés formant ainsi des systèmes bladecenters.
D’autre part, il importe que les auditeurs appréhendent aussi les

structures et les fonctionnements des infocentres qui connaissent un
certain renouveau ces dernières années.
Par exemple, parmi les centres d’information, un des plus connus en

France est celui du CNRS placé sous la gestion de la direction des
systèmes d’information mise en place en avril 1999. Il facilite l’accès
des données issues des applications nationales, ainsi que les résultats
de leurs analyses.
L’accès à cet infocentre est réservé :

– aux directions du Secrétariat général ;
– aux services des délégations régionales ;
– aux départements scientifiques ;
– à la direction des études et des programmes ;
– aux directions fonctionnelles ;
– aux chercheurs et au personnel des laboratoires.
En dehors des possibilités de requêtes et de consultation, il permet

l’importation et l’exportation des diverses données, par exemple :
– l’import journalier de données Labintel (qui se définit comme l’outil
d’information sur les activités de recherche et de service des
laboratoires et les moyens mis en œuvre), des données concernant les
formations, les protocoles…
– l’import hebdomadaire de données Brevet, des Notifications et des
budgets ;
– l’export hebdomadaire des données relatives aux ressources
financières CNRS vers Labintel.
Enfin, leur environnement technique se compose :

– d’interfaces Web pour les postes de travail ;
– des modules SAS - Serveur Unix Sun E450 - Système de sécurité
SSL (Secure Socket level) ;
– de l’outil de mesure d’audience Analog (outil statistique pour les
accès et les transactions).
Actuellement, la notion d’infocentre semble être banalisée, mais,

néanmoins, il faut maîtriser ses spécificités pour pourvoir exercer des
audits.
Quelque soit les structures infocentre ou centres de serveurs (qui

croissent considérablement avec les opérateurs de Télécom et
chez les FAI – fournisseurs d’accès Internet) pour l’accès et la
vérification d’authentification, on trouve souvent par exemple des
ordinateurs de type SUN avec le système Radius.
RADIUS (Remote Authentication Dial-In User Service) est un des

systèmes le plus utilisé par les FAI ou les IPS (Internet Service
Providers). RADIUS, à chaque connexion d’un utilisateur, vérifie son
nom d’utilisateur et son mot de passe avant de passer la main aux
systèmes internes de l’IPS.
La maintenance et l’évolution des spécifications de RADIUS sont

faites par un groupe de travail IETF. En fait, ce dernier est l’acronyme
de Internet Engineering Task Force. C’est le principal organisme pour
les normes relatives à Internet. Il est composé des opérateurs, des
concepteurs, des chercheurs et vendeurs soucieux de l’évolution des
architectures, des transactions, de l’utilisation et des opérations sur
Internet.
De ce fait, par rapport à leurs aînés, les auditeurs en informatique, de

nos jours, devraient s’informer et se former d’avantage sur ces types
de systèmes et sur les principes et concepts des réseaux. Concernant
les missions sur la cohérence, l’intégrité et la fiabilité des données, il
importe de connaître les systèmes et architectures des outils de gestion
des données cités précédemment.
En résumé
En tant qu’outil et matériel, un système « infocentre » ainsi que les

centres de serveurs offrent des services très différents aux utilisateurs,
mais en contrepartie, leur technicité inhérente est de plus en plus
complexe. Il est à noter que souvent avec ces centres, on sous-traite
l’exploitation et la maintenance : d’où la notion d’infogérance. De ce
fait, auditer ces centres exige une compétence diversifié englobant la

connaissance de :
– de ces types d’architecture et systèmes cités ;
– des principes des traitements coopératifs ;
– des principes des architectures client/serveur ;
– des différents types d’interfaces ;
– des divers types de langages de requêtes ;
– des outils de développement (pour les informaticiens) ;
– des méthodes et moyens de sous-traitance.
D’autre part, il importe de remarquer que, souvent, la notion

d’infocentre se couple avec celle d’infogérance. En effet, bon nombre
d’entreprises prennent l’option out sourcing, cela pour diverses
raisons : manque de compétence interne, manque de ressources
techniques, recentrage sur les tâches du métier, économie du budget
informatique…
Dans ce cas de figure, par expérience, nous observons une croissance

de demandes des missions d’audit de la politique informatique par les
directions générales.
Dès lors, les documents ou procédures tels que cahiers des charges,
procédures d’appels d’offres, les tableaux de bord concernant la
qualité des services, des systèmes, seront les documents clés pour un
auditeur informatique.
Enfin, ces quelques conseils généraux suivants peuvent être utiles

pour un auditeur interne amené à effectuer une mission d’audit
informatique dans une structure infocentre ou un centre de serveurs
soumis à gestion externe.
Conseils :
– distinguer et apprécier les procédures de travail et l’organisation ;
– juger et apprécier les normes de sécurité spécifiques de chaque
contexte (les protections, les sauvegardes...) du côté infocentre ;
– évaluer l’évolution des outils de traitement d’information (existe-t-il

un planning, un schéma directeur ?) ;
– distinguer, juger et apprécier la politique de maintenance du matériel
et des applications aussi bien du côté client, que du côté serveur.
Un exemple d’audit de ce type de centre ou BIC sera développé au

chapitre 5. Passons maintenant en revue les cycles de vie que
l’auditeur devrait appréhender pour ses missions d’audit informatique.
2.2. Les cycles de vie et les systèmes
Un système informatique ou un système logiciel (appelé souvent par

le nom « produit logiciel ») ne peuvent se concevoir sans la notion de
projet. Ce dernier pourrait être considéré sous deux angles :
– le produit objet du projet, identifié par le système cible avec sa
documentation finale ;
– le cycle de vie, matérialisé par des étapes successives et les
« délivrables » associés conduisant vers le système final.
Quelle que soit la méthode choisie, toute conception d’un système est
caractérisée principalement par trois cycles :
– le cycle de vie du système ;
– le cycle de la décision ;
– le cycle d’abstraction.
Le cycle de vie du système est composé de la manière suivante :

– génèse ;
– naissance ;
– croissance ;
– maturité ;
– obsolescence ;
– mort du système.
Cette dernière est caractérisée d’abord par l’obsolescence (résultats

fournis insuffisants) puis par la non-utilisation du système par
l’utilisateur.
Le cycle de décision est celui où l’on rend compte de l’ensemble des

choix durant le cycle de vie.
Le cycle d’abstraction est celui où l’on découpe par niveau

d’information pour isoler les éléments significatifs.
Analyse de l’existant
Dans tout le processus d’un projet informatique, la phase la plus

importante est sans conteste celle de l’analyse de l’existant (appelée
aussi étude préalable).
Il s’agit d’une phase primordiale où une erreur peut enclencher des

écarts financiers importants et des pertes de temps considérables
(phase où un auditeur informatique peut être sollicité et fournir des
critiques constructives, cette phase n’est pas seulement réservée à un
nouveau projet), mais elle peut être aussi déclenchée et utilisée lors de
la réorganisation d’une nouvelle structure ou lors de la constitution
d’un nouveau service.
Concernant l’automatisation en général, on peut distinguer des projets

d’informatisation (mise en œuvre d’un nouveau système d’informatique,
de matériel, de logiciel, ajout de modules spécifiques, des nouvelles
fonctionnalités…) et des projets de développement d’un produit logiciel
proprement dit.
Quoique différentes dans la pratique, ces étapes ont pratiquement les

mêmes principes et démarches.
Nous présentons d’abord les étapes classiques de l’informatisation

avant de passer en revue celles d’un projet de développement logiciel
(le produit logiciel) avec les documents et les contrôles de qualités
associés.
Ces derniers pourraient être faits par les auditeurs en informatique

mandatés par la Direction générale ou la Direction de l’informatique.
Le schéma suivant permet de décrire sommairement toutes les étapes

d’un projet d’informatisation et de situer l’analyse de l’existant.
Etude préalable → analyse de l’existant

PHASE Etude de conception → choix d’une solution stratégique
DE
(Analyse de conception)*
CONCEPTION
Etude fonctionnelle → définition du nouveau système
Etude technique → détail technique du système/des options

PHASE
Mise en œuvre du système → choix & mise en œuvre du
DE système
REALISATION Expérimentation → contrôle de qualité du système
Exploitation → utilisation du système
Maintenance → actualisation, mise à jour, entretien
(*) Cette phase est appelée aussi l’étude d’opportunité par

certains auteurs ou concepteurs.
Tableau 2.1. Les étapes classiques de l’informatisation
Pour la phase d’analyse de l’existant, l’ordre chronologique des

différents stades est :
– choix ou définition, diagnostic ;
– analyse circuit et critique constructive.
Ces sous-étapes (ou stades) cruciales de l’analyse de l’existant seront

reprises ultérieurement (voir tableau 2.2 page 49). Le point de départ
de ces étapes classiques de l’informatisation provient des besoins et
demandes des utilisateurs ; les principaux participants sont les
utilisateurs, les organisateurs, les analystes concepteurs.
Le produit final de cette phase est le rapport « cible » ou le rapport des

objectifs globaux. Ce document sera soumis à l’approbation des divers
responsables. Il propose des améliorations possibles quant aux
méthodes de travail, l’estimation des ressources à mettre en œuvre et

les limites du projet. Dans cette partie, on définit aussi la compatibilité
du projet avec les autres applications et procédures existantes de
l’entreprise. A l’instar des étapes précédentes, nous détaillons ici les
étapes du cycle de vie correspondantes pour un produit logiciel avec
les principaux documents associés. Il est important d’avoir des
contrôles qualité à chaque étape, mais néanmoins un auditeur pourrait
être amené à y participer.
Le détail du tableau 2.2 montre la correspondance entre les diverses

étapes et les principaux documents. Le tableau 2.3 permet
d’appréhender et de synthétiser les divers éléments correspondants aux
étapes cruciales de l’analyse de l’existant, ainsi que des problématiques
intéressantes pour les auditeurs. En effet, ces derniers pourraient être
amenés à diagnostiquer un système, à analyser les circuits, à apporter
des critiques constructives aux décideurs et voire même à les aider dans
leur choix.
En résumé, la Direction générale ou la Direction informatique peut

souhaiter l’intervention d’un auditeur informatique lors de la phase de
diagnostic et de critique constructive. En effet avec un « œil neuf »,
non-impliqué dans la phase d’analyse, faite par l’analyste-concepteur,
l’auditeur peut apporter des idées intéressantes sur le rapport élaboré
en fin de phase critique (exemple : un tel a fait cela, est-ce sa
responsabilité ou est-il le plus apte à le faire ?).
D’autre part, pour la phase de diagnostic par exemple, compte tenu de

son expérience concernant l’analyse des outils de gestion, des tableaux
de bord, des mesures d’indicateur d’activité... l’auditeur peut être un
collaborateur contribuant à faire gagner du temps et apporter une aide
précieuse et certaine dans la compréhension et l’analyse des divers
documents. Ce cas particulier d’aide ou de soutien constitue un audit
de diagnostic et de conseil, cas très limité dans une démarche d’audit
classique, mais plus fréquent avec l’approche des audits de régularité.
Néanmoins ceci démontre le souci de la Direction ou des décideurs
d’utiliser les compétences et les expériences d’un auditeur, même dans
la phase en amont du projet.
Etape du cycle Principaux documents Contrôle Qualité

de vie
Préliminaire Cahier des charges Revue de ces documents
Appel d’offres
Contrat
Planification Document de lancement Revue de planification
du projet
Plan d’assurance qualité
Plan de développement
Spécification Dossier de définition Revue de spécification
des besoins
Les exigences d’interface
Dossier de tests de validation
Conception Dossier de conception générale Revue de conception
générale Dossier des tests d’intégration générale
Conception Dossier de conception détaillée Revue de conception
détaillée Dossier des tests unitaires détaillée
Codage Listing ou fichier des Revue de code
programmes Remarque : la
Documentation programme vérification pourrait se
faire d’une façon
automatique avec des
logiciels (logiscope par
exemple)
Tests unitaires Dossier des tests unitaires Revue de tests unitaires
Bilan des tests unitaires
Intégration Dossier de ces tests Revue d’intégration
Bilan des tests d’intégration
Dossiers d’installation et
d’exploitation.
Recette Dossier des tests de la validation Revue de la recette (PV)
Bilan de la recette.
Installation/ Cahier d’installation Revue d’installation
Diffusion
Exploitation et Dossier de maintenance.
Maintenance
Tableau 2.2. Correspondance entre les diverses étapes

et les principaux documents
Stades Buts Problématique,

moyens ou outils
Choix ou Définition du problème, Problématique à partir des résultats

définition objectifs à atteindre. Bilan soulignant des contre-
performances, rapport d’un audit
externe…
Document interne de la DG précisant
la nouvelle stratégie, les nouveaux
objectifs de la société.
Diagnostic Situer le problème ; réunir Organigramme de fonction et
les informations ; structure, indicateurs, mesures
dresser les points forts et les d’activité et d’effectifs ; courbe
points faibles. ABC ; procédure de travail, schéma
synoptique et circuit (feuilles de
circulation, organigramme ou schéma
synthétique des fonctions, des
services…).
Analyse Décomposition du Divers documents ; imprimés et états
circuit problème en éléments existants, tableaux de bord, liste des
modulaires. Examen pour nouvelles contraintes, conclusion du
chaque module diagnostic.
du contenu de ses
documents et de leur
circulation.
Critiques Examen en vue d’améliorer Liste des points faibles, méthode
constructives les circuits, les documents QQOPQC : se poser toujours les
et procédures en fonction questions suivant la phrase : qui fait
des nouveaux objectifs. quoi, où, pourquoi, quand et
comment.
Tableau 2.3. Correspondance entre les objectifs des stades

et les problématiques, moyens ou outils
En résumé, la Direction générale ou la Direction informatique peut

souhaiter l’intervention d’un auditeur informatique lors de la phase de
diagnostic et de critique constructive. En effet avec un « œil neuf »,
non-impliqué dans la phase d’analyse, faite par l’analyste-concepteur,
l’auditeur peut apporter des idées intéressantes sur le rapport élaboré
en fin de phase critique (exemple : un tel a fait cela, est-ce sa
responsabilité ou est-il le plus apte à le faire ?).
D’autre part, pour la phase de diagnostic par exemple, compte tenu de

son expérience concernant l’analyse des outils de gestion, des tableaux
de bord, des mesures d’indicateur d’activité... l’auditeur peut être un
collaborateur contribuant à faire gagner du temps et apporter une aide
précieuse et certaine dans la compréhension et l’analyse des divers
documents. Ce cas particulier d’aide ou de soutien constitue un audit
de diagnostic et de conseil, cas très limité dans une démarche d’audit
classique, mais plus fréquent avec l’approche des audits de régularité.
Néanmoins ceci démontre le souci de la Direction ou des décideurs
d’utiliser les compétences et les expériences d’un auditeur, même dans
la phase en amont du projet.
2.3. Les référentiels relatifs aux logiciels de qualité
Dans le contexte de l’ingénierie informatique, c’est-à-dire l’étude

globale d’un projet informatique, il existe bon nombre de documents,
guides, voire références, afin de bien concevoir, développer et mettre
en œuvre la solution. L’objectif, c’est d’atteindre une certaine qualité
vérifiable et une traçabilité fiable. C’est pourquoi on parle souvent de
« référentiel pour la qualité logiciel » ou simplement « référentiel
qualité logiciel ».
Que ce soit en amont ou en aval de l’ensemble du processus, un

auditeur pourrait se voir demander d’auditer une phase particulière ou
l’ensemble du processus, ou simplement la qualité du produit logiciel.
De ce fait, il importe de bien connaître les référentiels servant de

documents de base de départ pour ces missions informatiques. Nous
nous bornons à présenter quelques uns d’entre eux, car l’ensemble des
normes existantes relatives aux qualités d’un logiciel ne saurait
contenir dans un livre… Nous en développerons certains afin de
fournir des repères et un référentiel pour nos lecteurs et/ou auditeurs
amenés à exercer ces missions de vérification de la qualité des
logiciels :
– la norme ISO/SPICE 15504 relative à « l’évaluation des processus
logiciels » ;
– la norme ISO/IEC 12207 concernant « le processus du cycle de vie

d’un logiciel » ;
– la norme 9126 relative à l’évaluation des logiciels.
Il existe deux façons d’aborder l’évaluation d’un produit : le principe

de la « boîte noire » et celui de la « boîte blanche ». Le premier
principe consiste à vérifier la bonne démarche de la conception à la
réalisation et/ou à la mise en œuvre du produit ou service. C’est
l’approche par processus, où l’on se soucie des processus et non du
produit en soi. L’application des versions antérieures de la série des
normes ISO 9000 est adéquate à cette démarche.
Cependant, compte tenu de la complexité croissante des logiciels et

surtout ceux conçus pour les domaines de la sécurité et de la sûreté,
cette démarche est insuffisante, voire dangereuse. En effet, elle est
incomplète, car on n’a pas « ouvert le capot » afin de regarder de près
les codes et y détecter les dysfonctionnements ! Une revue renforcée
des codes et le passage à un produit d’analyse de la complexité des
lignes des programmes caractérisent l’approche de type boîte blanche.
L’omission de cette dernière est un potentiel de risques.
Ainsi, on a vu certaines entreprises de développement de services

informatiques déposer le bilan quelques années après l’obtention de
leur certificat ISO 9001. La démarche de la boîte blanche est donc
indispensable pour les logiciels complexes et critiques, en
complément de la première approche. De ce fait, il existe beaucoup de
documents ou normes qui peuvent se classifier en fonction de
l’approche choisie. Nous détaillons ci-après les normes citées
précédemment ainsi que leurs contextes d’application.
2.3.1. La norme ISO/SPICE 15504
Cette norme pour l’évaluation des processus logiciels, est constituée

par un ensemble de documents publiés par l’AFNOR au dernier
trimestre de l’année 1998. C’était à l’époque une norme expérimentale
composée de neuf rapports techniques avec un fascicule de
documentation d’introduction. Son cadre de référence est dédié aux
processus identifiant les sociétés possédant des processus

« répétables » et « traçables » afin de pouvoir appliquer le principe de
capitalisation et de réutilisation. Cette norme a bénéficié des apports
des autres concepts et documents provenant des secteurs des
télécommunications et de l’industrie des logiciels avec les concepts
CMM (Capacity Maturity Model) et de Bootstrap (issu d’un projet
européen pour évaluer et améliorer les processus logiciels)…
A noter que le CMM est développé par le SEI (Software Engineering

Institute de Pittsburgh) sous l’impulsion de la DoD (Department of
Defense des Etats-Unis) pour la sélection des fournisseurs. De ce fait,
ce modèle englobe aussi une dimension d’aptitude pour la réalisation
des évaluations.
Ainsi héritant de CMM, SPICE introduit les six niveaux d’évaluation

(notés de 0 à 5) suivants :
– niveau 0 : processus incomplet. Le processus n’est pas réalisé ou
appliqué ;
– niveau 1 : le processus est réalisé. Il a qualifié ses objectifs ;
– niveau 2 : le processus est bien géré. Toutes les activités planifiées
sont faites et toutes les exigences des produits sont identifiées et
identifiables ;
– niveau 3 : le processus est vraiment établi. La mise en œuvre
s’appuie sur des pratiques standardisées ou normalisées. Autrement-
dit, il pourrait avoir des procédures claires et vérifiables ;
– niveau 4 : le processus est prévisible. Les variations ou écarts d’un
processus sont mesurés et compris ; les mesures récoltées sont
utilisées pour piloter et contrôler le déroulement du processus ;
– niveau 5 : le concept d’optimisation du processus est identifié ;
l’organisation est capable d’améliorer ses processus et les adapter de
façon proactive afin de satisfaire l’évolution des exigences et de s’y
adapter.
Ainsi, avec cette dimension d’aptitude, les entreprises pourraient

demander la certification SPICE via les entreprises accréditées pour
ces tâches.
En ce qui concerne la norme même, voici les différents documents qui

la composent :
– 0 : introduction au référentiel et à son utilisation ;
– 1 : concept et guide d’introduction ;
– 2 : modèle de références pour les processus ;
– 3 : réalisation d’une évaluation ;
– 4 : guide pour la réalisation d’une évaluation ;
– 5 : modèle d’évaluation et guide des indicateurs ;
– 6 : guide de compétence des évaluateurs ;
– 7 : guide pour l’amélioration des processus ;
– 8 : guide pour la détermination d’aptitude de processus ;
– 9 : vocabulaire (utilisé dans le document).
Application de la norme en matière d’audit informatique

Cette norme ISO/IEC 15504 pourrait être utilisée par les auditeurs
amenés à exercer plutôt des audits sur les processus de développement
des logiciels. A titre d’exemple, cette norme pourrait être utilisée
comme référentiel pour auditer un service de développement et
identifier ainsi la progression en matière de qualité, niveau par niveau.
Elle pourrait être utilisée comme audit interne pou la préparation de la
certification de type SPICE. De ce fait, l’auditeur pourrait jouer le rôle
d’audit à blanc pour la préparation à l’examen final par les auditeurs
externes accrédités à la méthodologie et aux concepts SPICE.
2.3.2. La norme ISO/IEC 12207
Le développement des projets informatiques est souvent fastidieux et

rempli d’écueils, sans compter le dérapage fréquent du temps et des
budgets alloués. Il importe donc de structurer et d’harmoniser les
différents processus. L’ISO a développé à cet effet la norme ISO/IEC
12207 concernant le « processus du cycle de vie d’un logiciel ». Cette
norme décrit et préconise les processus mis en œuvre dans les projets
informatiques. Les activités de mise en œuvre, les responsabilités des
divers acteurs ou intervenants ainsi que la politique qualité associée
sont déployées.
Voici le plan de la norme, qui est décomposé en sept articles distincts

et complémentaires :
– article 1 : domaine d’application ;
– article 2 : références normatives (les autres documents en liaison
avec la norme) ;
– article 3 : définitions (des termes utilisés dans le document) ;
– article 4 : application de la norme internationale ;
– article 5 : les processus de base. Cette section décrit les activités
liées au développement (conception, réalisation), à l’exploitation et à
la maintenance du logiciel, à savoir le processus d’acquisition, le
processus de fourniture, celui de développement, celui d’exploitation
et enfin le processus de maintenance ;
– article 6 : les processus de support. Cette section décrit tous les
processus qui peuvent être regroupés dans un contexte de support. Ils
sont au nombre de huit :
- le processus de documentation ;
- le processus de gestion de configuration ;
- le processus d’assurance de la qualité ;
- le processus de vérification ;
- le processus de validation ;
- le processus de revue ;
- le processus d’audit ;
- le processus de résolution de problèmes.
Cette norme rappelle la norme ISO 9000-3 qui met en exergue les
processus de la documentation, celui des revues et les actions
correctives. En effet, l’ISO 9000-3 est une norme de la série 9000
taillée sur mesure et adaptée pour le logiciel, concernant les
spécificités de conception, de réalisation, de livraison et de
maintenance des produits logiciels dans l’industrie informatique. Elle-
même est composée des six articles suivants :
– article 1 domaine d’application ;
– article 2 : références normatives ;
– article 3 : définitions ;
– article 4 : système qualité-cadre ;
– article 5 : système qualité-activités du cycle de vie ;

– article 6 : système qualité-activité de soutien.

A l’instar de la norme qualité ISO 9000-3, la norme ISO/IEC 12297
pourrait être utilisée par les auditeurs amenés à exercer des audits sur
les processus de développement des logiciels plutôt en termes de
contrôle de « boîte noire ». A titre d’exemple, cette norme pourrait
être utilisée comme référentiel pour la vérification de la
documentation, de la validation ou sur l’audit des services de hot line
(processus de résolution de problèmes des clients ou des utilisateurs).
2.3.3. La norme 9126 relative à l’évaluation des logiciels
Vis-à-vis des deux normes précédemment citées, la norme 9126

relative à « l’évaluation des produits logiciels » et ayant comme sous-
titre : « Caractéristiques de qualité et directives d’utilisations » est
plus focalisée sur une vérification de type « boîte blanche » car elle
n’est pas déterminée par une approche processus. Par définition, une
caractéristique qualité (il en existe sept en tout dans ce document) est
une qualité intrinsèque provenant d’une exigence. Néanmoins, il faut
souligner l’existence et/ou la difficulté de déterminer ou d’avoir des
valeurs, des métriques, c’est-à-dire des éléments facilement
chiffrables et mesurables (qui représentent les sous-caractéristiques)
préconisés pour la vérification.
Cette norme est relativement « mince » par rapport aux autres, car elle
laisse la liberté totale aux utilisateurs pour le développement de leurs
métriques. Beaucoup de critiques ont été formulées à l’encontre de
cette liberté qui pourrait amener au foisonnement des métriques non
homogènes et non comparables (pour un benchmark par exemple)
entre divers acteurs de même niveau.
Pour palier ces critiques, il est à noter que les experts ISO travaillent
actuellement à une révision complète de cette norme dont le plan est le
suivant :
– 9126 - 1 : modèle qualité ;

– 9126 - 2 : métriques externes ;
– 9126 - 3 : métriques internes ;
– 9126 - 4 : qualité en matière d’utilisation.
La nouveauté de cette révision consiste à prendre en compte les cycles

de vie du logiciel (de son dynamisme). Ainsi, chaque acteur pourrait
identifier et fixer ses métriques en fonction de ses niveaux et activités.
Cette clarification détermine les différentes perspectives de chaque
acteur dans la chaîne et leurs métriques qui peuvent être différentes :
– perspective d’un responsable qualité ;
– perspective d’un acheteur ;
– perspective d’un développeur ;
– perspective d’un mainteneur.
Malheureusement, la révision est toujours en cours et seule la

première partie est terminée.
La norme 9126 actuelle pourrait être utilisée par les auditeurs amenés
à vérifier la réalisation d’un logiciel. Sous réserve d’une bonne
définition d’un ensemble de métriques au préalable, les auditeurs
pourraient l’utiliser comme référentiel et outil de type « boîte
blanche ». En effet, les métriques seront bâties en fonction des sous-
caractéristiques et l’ensemble des sous-caractéristiques détermine les
caractéristiques.
La norme préconise une revue possible des six principales

caractéristiques suivantes :
– la capacité fonctionnelle, caractérisée par l’aptitude, l’exactitude,
l’interopérabilité, la sécurité et la conformité réglementaire ;
– la fiabilité, définie par la maturité, la tolérance aux fautes et la
possibilité de récupération ;
– la facilité d’utilisation, caractérisée par les facilités de
compréhension, d’apprentissage et d’exploitation ;
– le rendement, défini par le comportement du produit vis-à-vis du
temps, et vis-à-vis des ressources ;
– la maintenabilité déterminée par les facilités d’analyse, de

modification, de tests et la stabilité du produit ;
– la portabilité, caractérisée par la facilité d’adaptation, la facilité
d’installation la conformité aux règles de portabilité et
l’interchangeabilité.
La norme, en soi, est composée des cinq articles suivants :

– article 1 : domaine d’application ;
– article 2 : références normatives ;
– article 3 : définitions ;
– article 4 : caractéristiques de qualité du logiciel. C’est la définition
des sept caractéristiques précédentes et des sous caractéristiques
associées ;
– article 5 : recommandations pour l’emploi des caractéristiques de
qualité concernant les trois visions des acteurs :
- vue des utilisateurs ;
- vue des réalisateurs ;
- vue du maître d’ouvrage.

En résumé, cette norme en l’état actuel est applicable pour exécuter un
audit plus technique de type « boîte blanche », à condition que les
métriques aient été définies au préalable par les concepteurs et les
réalisateurs du logiciel. En aucun cas, il n’est du devoir de l’auditeur
d’établir les métriques lors de sa mission d’audit. Les auditeurs ne
peuvent que conseiller d’en établir s’il s’avère que les métriques
n’existent pas encore dans le service audité, ou encore démontrer la
pertinence d’une ou de plusieurs métriques.
Enfin, nous ne la développons pas en détail mais signalons juste qu’il

existe aussi la norme 14598,en anglais, qui pourrait intéresser les
évaluateurs et auditeurs en particulier sur les parties 5 et 6 suivantes :
– ISO/IEC 14598-5:1998 Software product evaluation - Part 5 :
Process for evaluators ;
– ISO/IEC 14598-6:2001 Software engineering - Product evaluation
Part 6 : Documentation of evaluation modules.
2.4. Classification générique des types d’audit
Après la présentation des contextes techniques et de quelques

référentiels, il nous importe d’introduire les typologies d’audit
informatique avant de détailler, les diverses phases de l’audit, les
spécificités et les rôles que les auditeurs pourront être amenés à jouer.
Les typologies d’audit informatique
Dans la pratique, on peut distinguer trois types d’audits classés en

rapport avec le degré de finalité, d’importance et de difficulté :
a) audit de diagnostic : l’auditeur est appelé à porter un jugement, sur
des objectifs ou nouveaux projets et parfois même au niveau de la
politique informatique, du schéma directeur existant (il faut distinguer
les schémas directeurs concernant la politique du matériel, d’un
domaine ou d’informatique) ou sur un « système » existant qui
fonctionne mal, dans ce cas des analyses des contre-performances et
recommandations sont souhaitées et attendues de la part des
auditeurs ;
b) audit de régularité (conformité) : à l’instar des vérifications des
documents comptables et de la régularité des opérations, en audit
informatique, on est amené à vérifier que telle ou telle procédure (ou
réglementation) est appliquée, que les transactions informatiques sont
régulières ou que les données intégrées dans les ordinateurs sont
réelles et cohérentes ;
c) audit d’efficacité : l’expérience d’audit et les connaissances
techniques informatiques d’une équipe d’audits sont les conditions
nécessaires pour ces missions. Une analyse approfondie des méthodes
et moyens est nécessaire afin de porter un jugement, étayé sur
l’adéquation du fameux couple « objectifs/moyens » (c’est une sorte
de contrat de service que le responsable d’un service reçoit de la part
de sa hiérarchie, composant l’ensemble de moyens et de ressources
pour accomplir ses missions annuelles) avec les objectifs poursuivis
en matière de traitement de l’information.
Un autre moyen de classement des audits informatiques repose sur la

distinction par degrés de difficultés croissants :
– l’audit en milieu informatisé ou d’un environnement informatique ;

– l’audit de sécurité d’une façon globale ou d’une application (voir
l’exemple de la section 3.3) ;
– l’audit informatique système (système autonome ou en réseau).
Historiquement, les missions concernant l’audit en milieu informatisé

étaient faites par les auditeurs internes ou externes non-spécialistes en
informatique.
Ce sont les missions que l’on qualifie souvent de missions « autour de

l’ordinateur » dans la suite logique des révisions comptables. En effet,
en 1975, le Conseil supérieur de l’ordre des experts-comptables et des
comptables agréés a fixé les principes fondamentaux pour la
« Révision des comptabilités traitées par des moyens informatiques »
dans la recommandation de révision numéro 7. Par la suite, ce Conseil
a émis un document concernant « la révision dans un environnement
informatique », comme déjà signalé précédemment...
Par degrés de difficultés, viennent ensuite les missions de type

« sécurité » de l’environnement informatique et la sécurité des
applications (voir le développement dans le chapitre 6). Enfin, les
derniers types de missions nécessitent des spécialistes et des
compétences en réseau, du ou des systèmes (ordinateurs, système
d’exploitation...) audités. De ce fait un appel aux concours extérieurs
est souvent nécessaire quand le champ d’intervention demande des
connaissances techniques, spécifiques à un système.
De ces précédentes remarques, nous tirons les recommandations

suivantes :
– l’audit d’efficacité sur les systèmes ou réseaux ne peut être fait que
dans l’équipe des spécialistes informatiques (ou avec la collaboration
d’un expert externe), autrement, sans concours d’un spécialiste, la
mission sera très probablement vouée à l’échec ou à un succès limité.
En effet, les recommandations émises par des auditeurs ne peuvent
être vagues ou générales face aux spécialistes pointus que sont les
analystes, les ingénieurs système ou l’ingénieur réseau d’un service
informatique ;
– les deux premiers types d’audit, par contre, peuvent être effectués
par un service d’audit d’une entreprise qui aborde les missions
informatiques, ou par un service qui possède une équipe en début
d’initiation aux techniques de l’informatique.
L’auditeur, qui effectue une mission d’audit informatique, doit
posséder une solide formation de gestion et des techniques
informatiques. Ce chapitre identifie les éléments de background Ainsi
la connaissance du contexte technique actuel, du cycle de vie et
des normes relatives à la qualité des logiciels et de leur contexte
d’utilisation est nécessaire pour un auditeur, aussi bien pour
effectuer des missions d’audit dite de type « boîte noire » que pour
des missions de type « boîte blanche ».
Il est à remarquer qu’il existe encore d’autres normes pour la

qualité du logiciel, mais celles développées dans ce chapitre
forment un ensemble minimal de référentiels et d’outils de base de
travail pour effectuer des audits informatiques. Enfin, ce chapitre
se clôture par la présentation de trois types d’audits classés en
rapport avec leur degré de finalité, d’importance et de difficulté, à
savoir : l’audit de diagnostic, l’audit de régularité et celui
d’efficacité, versus un autre type de classement possible : l’audit
fonctionnel et l’audit dit de type opérationnel...
FOIRE AUX QUESTIONS
(CHAPITRE 2)
Question 1 : relative à l’audit informatique fonctionnel et à l’audit

opérationnel. On classe souvent l’audit informatique en deux
catégories : pouvez-vous donner des exemples de chaque catégorie ?
Réponse :
Audit informatique fonctionnel : les quatre audits suivants peuvent être
considérés comme des audits fonctionnels :
– audit des études (lors de l’élaboration des cahiers des charges par exemple) ;
– audit de la production du service informatique ;
– audit de la politique informatique, de la planification des moyens de
mise en œuvre ;
– audit financier de la fonction informatique, concernant le processus
d’investissement.
Audit informatique opérationnel :

– audit des moyens de traitement et des ressources techniques (logique
et physique) ;
– audit d’une application (ou de son environnement, de sa décision
d’implantation, de la maintenance, de la restitution des états...) ;
– audit de la circulation des documents (ou de l’information) et de la
documentation ;
– audit de la sécurité générale liée à l’informatique.
Question 2 : dans le chapitre précédent, on a aussi effectué un

classement par typologie (audit de diagnostic, audit de régularité et
audit d’efficacité). Ce classement est-il compatible avec le classement
audit fonctionnel/opérationnel ?
Réponse : non, il n’existe pas de contradiction. En effet, d’une part,

c’est un problème d’angle de vue et d’autre part, il peut exister une
combinaison possible, c’est-à-dire que les deux types de classement
peuvent être associés. Par exemple, concernant un audit fonctionnel de
la production du service informatique, on peut être amené à vérifier
que telle ou telle procédure (ou réglementation) est appliquée.
Question 3 : la connaissance du cycle de vie est-elle nécessaire pour

mener un audit ?
Réponse : cette connaissance est primordiale pour auditer un projet et

surtout pour examiner la qualité du projet à une phase donnée. Afin
d’éviter les déboires, les dépassements des coûts et les écarts (du point
de vue fonctionnalité), la Direction générale ou la Direction
informatique commande de plus en plus ce genre de missions. En
effet, cette stratégie permet souvent d’aboutir à une bonne conception,
en adéquation avec les besoins des utilisateurs et le souhait de la
Direction.
Question 4 : les contextes techniques changent très rapidement. Les

auditeurs informatiques doivent-ils connaître et maîtriser coûte que
coûte ces évolutions ?
Réponse : oui et non. Bien évidemment, il serait souhaitable que

l’auditeur maîtrise ces contextes, d’où l’importance du composant
« formation » des auditeurs. Néanmoins, en cas de besoin, l’auditeur
interne pourrait faire appel à une assistance technique externe pour
mener à bien sa mission.
Question 5 : en ce qui concerne les référentiels, a-t-on besoin de les

connaître pour auditer un logiciel ?
Réponse : absolument, les référentiels sont des documents de travail

importants pour les auditeurs. Comme leur nom l’indique, ils
constituent le ou les référentiels auxquels on se réfère pour constater
les points forts et le poins faibles. Ce sont en quelque sorte des
données en entrée (inputs) obligatoires à prendre en compte par les
auditeurs.
Question 6 : concernant la matrice ou le tableau 2.2 (de 3 colonnes et

5 lignes, détaillant la correspondance entre les objectifs des stades et
les problématiques et moyens), quelles sont les responsabilités des
auditeurs et le degré de difficulté des stades ?
Réponse : souvent les auditeurs sont sollicités par la Direction qui

apprécie leurs compétences, leur discernement et leur « œil neuf » sur
les projets ou services. D’autre part, les fonctions des auditeurs qui ne
se bornent plus à la vérification, au contrôle ou à l’audit mais
s’étendent aussi au domaine du conseil. Leurs responsabilités de
« conseillers » s’imposent et se développent de plus en plus.
Chaque stade possède une difficulté équivalente, néanmoins le plus

délicat pour un auditeur interne est de conseiller le choix et la
définition d’une nouvelle stratégie, surtout lorsqu’un rapport négatif a
été fourni après l’exécution un audit externe. « Bien analyser le
rapport, les points faibles et apporter des solutions nouvelles » seront
sans conteste des plus values d’un auditeur et/ou d’un conseiller
interne.
Question 7 : peut-on avoir un exemple de cohabitation et d’utilisation

de deux normes dans un service informatique ?
Réponse : oui, la cohabitation de deux normes (de type qualité

logiciel) est une possibilité. Par exemple, la norme 9126 peut être
pratiquée avec la série d’ISO 9000 (voir la procédure développée dans
le chapitre 7). L’application de la norme 9126 est utilisée comme un
outil référentiel pour une vérification « de boîte blanche » (analogue à
l’ouverture d’un capot pour le contrôle technique) par un laboratoire
de tests, tandis que les normes de qualité « classiques » sont utilisées
comme référentiel (plutôt pour la vérification de type « boîte noire »).
Dans ce cas, l’utilisation de ces deux normes permet d’éviter un risque

potentiel. En effet si l’on applique que les normes de qualité
« classiques » et soumettre prématurément un produit logiciel (ou son
processus d’élaboration) à la certification ISO Qualité (processus
respectés, documentation bien faîte, existences des processus
d’actions correctives…) alors que ce produit logiciel pourrait encore
contenir beaucoup d’erreurs et d’imperfections…
CHAPITRE 3
Les diverses phases

d’une mission d’audit
Ce n’est point dans l’objet que réside le sens des choses, mais dans la démarche.
Antoine de Saint-Exupéry, écrivain et aviateur français (1900-1944)
3.1. Les diverses phases
3.1.1. Les principales phases et le schéma global
Une mission d’audit est en fait composée de plusieurs phases

commençant par une lettre de mission reçue par le service d’audit. La
prise en compte de ces éléments ainsi que leur application efficace et
adéquate constituent la bonne démarche de l’audit. Le schéma de la
figure 3.1 permet d’en appréhender, par une vue générale, le
processus.
Chaque année, le responsable d’un service d’audit établit avec ses

collaborateurs un programme d’intervention en fonction d’un plan
d’audit, d’un programme annuel systématique et/ou d’un
« portefeuille de missions ». Tous ces éléments constitués à partir des
demandes de la Direction générale et/ou des diverses directions et
services de la société, déterminent le choix des missions et la politique
de l’audit. Il est à noter que le portefeuille des missions s’agrandit en

fonction de la compétence de l’équipe et de l’évolution de l’entreprise.
Le responsable d’audit peut fixer les priorités avec un représentant de
la Direction générale et arrêter la liste annuelle des missions.
Le choix d’un cycle d’audit étant fixé, quelles que soient les missions,
elles devront être annoncées par une lettre officielle de la Direction
générale adressée aux services audités. Certes, cette phase est
protocolaire mais indispensable. Elle déclenche le travail de l’équipe
d’audit et amorce le point de départ d’une mission comportant
plusieurs phases.
Lettre de Mission
Enquête préliminaire
Phase de vérification
Non
Preuves suff ?
Oui
Rapport
Figure 3.1. Schéma global d’une mission d’audit
Au programme annuel du service d’audit, il peut exister plusieurs

types de missions :
– missions de type cyclique (deux fois ou une fois par an), par
exemple : contrôle des stocks, vérification des indicateurs
représentatifs de l’activité d’un service ;
– missions spécifiques demandées par la Direction générale ;
Les diverses phases d’une mission d’audit 69
– missions dues à des événements nouveaux non prévisibles dans

l’entreprise ou mission d’étude pour un service si celui-ci manque de
ressources « personnelles » ou « matérielles » ou n’arrive pas à
remplir la tâche qui lui est confiée.
Une mission d’audit informatique, à l’instar d’une mission plus

classique, peut se décomposer en trois grandes phases, une fois le
sujet fixé et les lieux ou services à auditer déterminés : d’abord la
phase d’enquête préliminaire, puis celle de la vérification, et enfin la
phase dite de « restitution ».
La restitution des informations et des remarques auprès des services

audités peut être verbale ou écrite. Le premier cas peut se concevoir
pour des missions ponctuelles et rapides sans complexité majeure
(exemple : audit de diagnostic et attente des résultats pour une prise de
décision rapide).
3.1.2. L’enquête préliminaire
La définition des objectifs est la base d’une mission réussie. Les

objectifs doivent être clairs, précis et en harmonie avec la demande de
la Direction générale ou du service demandeur.
En aucun cas, les objectifs ne pourront être déviés. D’une part, cela
aurait une influence sur l’image de marque du service d’audit (donc
une perte de confiance de la part des demandeurs de la mission), et
d’autre part, la diminution des demandes de missions se ferait sentir
tôt ou tard.
En possession de l’ordre de mission, du sujet et des objectifs, les

auditeurs peuvent démarrer leur mission. L’enquête préliminaire,
point de départ de la mission, dure de quatre à cinq jours environ.
Cette durée pourra être allongée si l’entreprise a plusieurs filiales ou
agences disparates ou séparées géographiquement.
Il serait souhaitable que l’ensemble de l’équipe d’audit affectée à cette

mission, participe à l’enquête.
Par exemple, pour une mission d’audit informatique (cas d’une grande
ou moyenne entreprise), la composition et la participation des
membres suivants sont souhaitées :
– chef de mission ou superviseur ;
– l’auditeur spécialiste informatique ;
– un deuxième auditeur (généraliste) en binôme ;
– le chef du service d’audit (éventuellement mais non obligatoire).
L’enquête préliminaire se compose généralement de quatre phases :

l’analyse du sujet et la définition des objectifs, la préparation
(documentation, élaboration des questionnaires...), la prise de contact
avec les audités et enfin l’enquête préliminaire proprement dite sur le
terrain. Cette dernière, d’une durée au minimum de deux ou trois
jours, marque le démarrage d’une mission d’audit. Si la mission
s’effectue sur plusieurs sites ou sur plusieurs services ou fonctions
disparates, la durée peut alors être rallongée. Il est à noter que cette
phase est souvent appelée phase de diagnostic rapide.
But de cette phase :

– collecter des informations afin de pouvoir dresser un plan de
travail ;
– étudier la faisabilité par rapport à l’ordre de mission, des objectifs
préalablement fixés ;
– remettre en cause éventuellement les objectifs (après discussion
avec le service demandeur).
Par exemple, pour une mission d’audit informatique du traitement des

anomalies et limitation des factures erronées chez un opérateur des
télécommunications comme précédemment cité, l’enquête
préliminaire devra permettre de :
– prendre rapidement connaissance des fonctions des divers services
en jeu ;
– étudier l’organigramme de l’organisation et les relations des
services ;
– s’informer sur le fonctionnement du centre de traitement ;
– s’informer sur le volume des factures émises et le nombre de

factures erronées ;
– inventorier les délais, la fréquence des traitements ;
– inventorier les positions de saisie d’information ;
– détecter les erreurs probables ou potentielles ;
– répertorier les divers types d’anomalies ;
– identifier l’impact et les problèmes ressentis par :
- les services contentieux, relation clientèle ;
- le service d’informatique ;
- la Direction générale ou autres directions ou services.
A ce stade, il est intéressant de recenser et de définir les divers

documents associés :
– lettre de mission : c’est une lettre émanant de la Direction générale
qui charge le service Audit interne d’une mission spécifique. Ce
service présente ce courrier aux services audités lors d’une première
réunion de contact. Ce sera le premier document important de la
mission ;
– thème de mission : présentation synthétique des problèmes et
principaux objectifs assignés aux auditeurs par la Direction générale ;
– planning ou plan d’approche : c’est un document décrivant la
manière et éventuellement les méthodes utilisées pour aborder la
mission, le chef de mission peut inclure le budget dans ce document
de planification ;
– programme de travail : c’est un plan détaillé d’investigation et de
vérification concernant les points forts et les points faibles. Ce plan
fait référence à des instructions et procédures relatives à la mission. Il
doit être approuvé par le superviseur (voir lexique) et communiqué au
responsable de l’audit interne ;
– mémorandum : ce document est une note de synthèse élaborée après
certification de certains faits (voir définition plus détaillée dans le
lexique).
A titre d’exemple, un plan du programme de travail d’une mission

intitulée « Limitation des factures erronées » pour un opérateur sera
présenté au chapitre 7.
Enfin, après la phase de l’enquête préliminaire, la phase de

vérification s’impose. Nous allons la développer maintenant.
3.1.3. Phase de vérification
La phase de vérification doit être menée scrupuleusement en fonction

du programme de travail. Elle a pour but de confirmer les points forts
ou points faibles supposés ou constatés dans la phase précédente et de
chiffrer, éventuellement, les pertes et risques.
Cette phase se décompose de la manière suivante :

– au préalable, l’établissement du programme de vérification ;
– l’étape de vérification sur le terrain, et la recherche des preuves et
défaillances ;
– le dépouillement et la compilation des résultats obtenus ;
– enfin l’exploitation des résultats et la première mise en forme, le
classement et la préparation pour l’intégration dans le futur rapport.
Dans la plupart des cas, la recherche des preuves est relativement

évidente à condition de savoir que chercher et quelles preuves trouver
en suivant une démarche préétablie.
La vérification doit être menée avec un planning rigoureux établi au

préalable compte tenu des divers éléments à auditer dans une mission
et de l’emploi du temps des personnes des divers services audités.
C’est une phase primordiale de la mission qui a pour objectif de

fournir aux auditeurs des preuves concernant les points faibles
présumés, et surtout les dysfonctionnements de l’organisation ou des
systèmes visités pouvant ainsi mesurer l’impact des conséquences.
On peut dissocier deux types de vérifications.
a) Les vérifications rapides
On peut appeler cette phase, la « vérification de survol ». En effet, elle

s’appuie sur les premiers entretiens, l’examen de la documentation, les
procédures et des vérifications rapides de conformité (par exemple la

déclaration de l’existence d’un document lors d’une interview s’avère-
t-elle exacte avec la documentation sur place). L’objectif est de
permettre aux auditeurs de détecter rapidement les points forts et les
points faibles.
b) Les vérifications approfondies
L’objectif de cette phase est d’apporter des preuves pour conforter les
éléments recensés dans l’étape précédente et de chiffrer « les dégâts »
réels ou potentiels.
Les deux schémas suivants permettent de mieux appréhender

l’articulation des principales phases d’une mission d’audit et les
diverses étapes de la phase même de vérification.
Résumons rapidement les étapes : la lettre de mission déclenche la

mission d’audit par une enquête préliminaire, suivie de la phase de
vérification.
La dernière phase concernant l’élaboration du rapport ne peut se

déclencher que si toutes les preuves sont considérées comme
suffisantes et confirmées.
La phase de vérification quant à elle, peut être décomposée en deux

sous-phases. Le schéma suivant permet de bien montrer toutes les
étapes de cette phase.
Il détaille les étapes en amont et en aval de la phase de vérification.

Cette dernière est elle-même décomposée en deux processus : les
vérifications rapides et les vérifications détaillées.
L’organigramme suivant décrit toutes les étapes avant la phase de

rapport, appelée aussi phase de restitution.
Etabliss. Plan d ’approche
Programme de vérification
Vérifications rapides
Non
Vérifications détaillées
3
1
BBK sûrs? Pr Confir.
2 oui
Dépouillement des résultats
Exploitation & Mise en forme
Phase de rapport
1- BBK : venant de l’anglo-saxon (voir la définition du lexique)

2- PR : points de reprise (voir lexique)
3- Confir : confirmation des points de reprise, la demande peut être
faite par voie téléphonique. Il est possible de redescendre
sur « le terrain » si la réponse n’est pas satisfaisante.
Figure 3.2. Organigramme des différentes étapes de l’audit
3.1.4. Phase de restitution et du rapport
La dernière phase d’une mission, appelée phase de restitution du

rapport d’audit consiste en la préparation, la rédaction et l’édition d’un
rapport. Les principales étapes sont :
– rédaction d’un projet de rapport ;
– la présentation du projet et l’examen des incohérences ou points
faibles, la mise en accord avec les audités, puis l’élaboration définitive
des recommandations (leur déroulement sera systématiquement suivi
ultérieurement, grâce aux fiches de suivi) ;
– la rédaction du rapport définitif ;

– la notification et l’envoi du rapport au service intéressé ;
– l’établissement des fiches de suivi et l’envoi de la lettre de clôture
de la mission.
Le rapport d’audit doit présenter une démonstration neutre, objective

et apporter des critiques constructives. C’est un dossier technique qui
doit être compréhensible et « lisible » par la hiérarchie ou le High
Management qui ne sont pas des spécialistes par rapport au personnel
des services audités.
Ce document fournit des recommandations en regard des points

faibles détectés. Parfois, il peut exister des recommandations qui ne
sont pas obligatoires (ou doivent être impérativement suivies), mais
étant émises par l’œil neuf d’un service compétent, elles peuvent
apporter des améliorations ou autres idées concernant les procédures
de travail.
Ainsi dans la limite de leurs contraintes et de leurs responsabilités, les

services audités sont libres de tenir compte et/ou d’appliquer ces
recommandations. Néanmoins, il serait souhaitable que le responsable
du service audité argumente le non-suivi de ces recommandations.
Bref, ce rapport est le fruit du travail d’une équipe, pour la direction et

pour le service audité, dont le but essentiel est de contribuer à
l’amélioration et à la bonne marche de l’entreprise. Le rapport final
constituant le fruit de deux à trois mois d’enquête de l’équipe est lui-
même précédé par un pré-rapport.
Ce dernier document est appelé aussi « projet de rapport ». Il doit être

envoyé aux services audités pour des remarques et/ou des
contestations éventuelles. Ce n’est qu’après concertation et accord que
le rapport définitif est édité‚ intégrant les remarques et corrections
éventuelles. Dès lors, ce dernier pourra être envoyé au demandeur de
la mission, à la Direction générale et aux services audités.
Quelques conseils pour le rapport final

Le volume et l’épaisseur du rapport sont fonction du thème et des
services audités (il n’y a pas de règle fixe). Par exemple, il est évident
que la description des dysfonctionnements d’un service d’un
département ou d’une division est probablement moins longue que
celle du département entier avec ses systèmes informatiques et ses
relations avec d’autres entités. Mais d’une manière générale, il est
fortement conseillé d’élaborer dans la mesure du possible des rapports
inférieurs à 25-30 pages. Au-delà, ils lasseraient le lecteur. Un
document de 10 à 20 pages, pouvant relater les procédures, les points
faibles, les dysfonctionnements et les recommandations pertinentes
pourrait être une bonne moyenne.
D’autre part, de la clarté et de la concision sont nécessaires.

L’organigramme d’un service au sein du rapport même est à
déconseiller. Tout au plus, il se trouvera en annexe.
La description des fonctions n’est pas obligatoire, à moins qu’elle soit

indispensable pour situer les points faibles et élaborer les
recommandations.
Enfin, les annexes ne sont pas obligatoires non plus. Elles ne doivent être
à leur place que si la justification des recommandations ou la
compréhension d’un service et/ou d’une procédure sont utiles,
primordiales.
D’autre part, elles peuvent contenir des analyses ou des calculs

auxquels il est fait allusion dans le rapport. Le plan d’un rapport est
fourni en exemple ultérieurement (voir section 7.2).
REMARQUE.− D’après les conseils et les termes des professionnels, de

l’IFACI (Institut français des auditeurs et consultants internes), les
auditeurs devraient dresser un tableau des points forts (PF) et points
faibles (pf) apparents, dégagés d’après certaines preuves ou d’après
l’intime conviction, et que l’on s’impose professionnellement de
vérifier.
Indépendamment des diverses phases précitées, en regard de ces

investigations, il importe de connaître les outils et moyens utilisés par
les auditeurs internes. La section 3.2 essaie d’apporter quelques
éléments de réponses.
3.2. Les techniques, les outils et la formation
Pour effectuer les vérifications ou les enquêtes, un certain nombre de

techniques peuvent être utilisées, mais elles possèdent un champ
d’action limité et ne peuvent être adaptables dans tous les cas.
Le choix d’une technique est fonction du problème à résoudre.

D’autre part, en dehors de la formation de base des méthodes d’audit,
les auditeurs doivent être sensibilisés aux techniques de traitements de
l’information, à la technique de réunion, aux processus d’interviews, à
l’élaboration des questionnaires pertinents.
Compte tenu de l’existence d’une littérature abondante, nous ne

développons pas ces sujets, mais fournissons néanmoins quelques
indications dans l’annexe.
3.3. Exemple et démarche pour les audits qualité d’un service de

support
Pour illustrer les différentes phases détaillées ci-dessus, nous donnons

un exemple d’audit concernant un service de support d’une division
informatique d’une entreprise.
En voici la mission : ayant reçu des plaintes d’utilisateurs concernant

les services rendus, la Direction générale mandate un audit sur le
processus de support de la division informatique.
La lettre de mission est envoyée simultanément à la Division

informatique et au responsable d’audit (au mois de mars de l’année
N). L’audit était planifié et sera exécuté après les vacances d’été.
Nous développons les éléments correspondants à chaque phase du

processus d’audit après la réception de la lettre de mission :
– l’enquête préliminaire ;
– la phase de vérification ;
– la phase de rapport.
Mais regardons d’abord le travail du responsable d’audit et les

concertations avec ses auditeurs : travaux qui peuvent occuper jusqu’à
15 % du temps total dans une mission d’audit. Cette phase sera
nommée « phase de pré-audit et de planification ».
3.3.1. Phase de pré-audit et de planification (14 %)
Dans notre cas particulier, il est évident que ce n’est pas une mission
planifiée d’avance ou une mission de type cyclique. De ce fait, le
responsable d’audit devrait décaler ou refaire son planning annuel
prédéfini et effectuer un choix parmi ses ressources disponibles et
compétentes en la matière. Il devrait, dès lors, provoquer une ou
plusieurs réunions de travail avec son équipe pour discuter l’objet de
l’audit et l’affectation des ressources. Après, il devra répondre à la
direction générale (DG) et écrire au service audité en mettant en
annexe le mandat officiel de la DG.
Par expérience, un responsable pourrait identifier le référentiel utilisé

et effectuer une esquisse de la démarche qui pourrait être suivie par
son équipe. Ainsi après vérification de ses ressources et la possibilité
de décaler certaines missions moins importantes, le responsable
propose à ses auditeurs les deux points importants suivants :
– acceptation de la mission ;
– utilisation du référentiel du service audité s’il existe, dans le cas
contraire, les auditeurs s’appuieront sur la norme ISO/IEC 12207, en
particulier les éléments de l’article 6 pour la vérification concernant le
support :
- vérifier le processus de documentation de l’équipe de support ;
- le processus de gestion de configuration des logiciels utilisés par
le support ;
- le processus d’assurance de la qualité de ce service ;

- le processus de revue de ce service ;
- le processus de résolution de problèmes du personnel support.
3.3.2. Phase de l’enquête préliminaire (25 %)
Elle est composée des quatre sous-phases suivantes :

– l’analyse du sujet et la définition de l’objectif ;
– la préparation (la documentation, l’élaboration des questionnaires...) ;
– la prise des contacts des personnes du service audité ;
– l’enquête préliminaire sur le terrain.
3.3.3. Phase de vérification rapide (20 %)
Elle est appelée aussi phase de vérification de survol, les bases de nos
travaux s’appuient sur :
– les premiers entretiens ;
– l’existence et l’examen rapide de la documentation, des procédures
recueillies sur le terrain et sur les vérifications rapides de conformité.
L’objectif est de permettre aux auditeurs de détecter rapidement les

points forts et les points faibles.
Ainsi, ils devraient dresser un tableau des points forts (PF) et points
faibles (pf) apparents, dégagés d’après certaines preuves ou leur
intime conviction et s’imposer aussi, professionnellement, d’effectuer
plus tard des vérifications plus approfondies.
Pour cette mission, nous avons détecté quelques points forts :

– l’existence d’une documentation complète des logiciels que le
service a la responsabilité de supporter ;
– l’existence d’une procédure générique de support fournie à chaque
nouvelle personne entrant dans le service ;
– un bon taux de couverture du service de support.
Mais aussi quelques points faibles :

– une documentation existante, mais non mise à jour ;
– un défaut d’harmonisation en matière de traitement des problèmes
soulevés par les utilisateurs, soit par téléphone, soit par fiche
d’incidents ;
– aucun délai (même approximatif) n’est fourni aux utilisateurs ;
– un niveau de compétence de l’équipe support disparate.
3.3.4. Phase de vérification ou réalisation de l’audit proprement dit (25 %)
Cette phase importante permet aux auditeurs de vérifier tous les

éléments minutieusement et en détail, afin de pouvoir apporter les
preuves des points forts et des points faibles détectés ou pressentis
dans les phases précédentes.
Des entretiens approfondis ont eu lieu avec les personnes d’un

échantillon établi. Sur un ensemble de vingt-quatre personnes, nous
avons constitué une liste de dix-sept personnes travaillant dans
diverses tranches de plages horaires. Nous avons une représentativité
de plus de 75 %. Ce pourcentage est plus qu’honorable pour une
mission d’audit. Les autres personnes de l’équipe étaient soit en
congé, soit en formation.
Dans notre mission, nous vérifions aussi les divers documents mis à la
disposition de chaque membre de l’équipe et vérifions, bien sûr, les
dernières versions de la documentation avec celles fournies par le
service développeur et par les fournisseurs des logiciels.
En cas de doute, il convient de téléphoner à ces derniers et même de

demander les dernières documentations.
Puis, grâce aux fiches d’incidents recensés, on vérifie la réponse

apportée avec la date de clôture d’incidents. Dans un autre service
audité, ces mêmes fiches portent le nom de « ticket d’incident ».
Quant aux niveaux de compétences disparates des membres de

l’équipe, il faut vérifier les dossiers de formation, leurs expériences
(backgrounds) et comparer les délais des réponses de chaque membre

concernant les incidents de même type.
Ainsi par ces méthodes, on obtiendra des preuves tangibles et

indéniables. A la fin de cette phase, les auditeurs sont en mesure de
préparer le pré-rapport avec des éléments complets issus de toutes les
phases antérieures.
3.3.5. Phase de restitution et du rapport (16 %)
Dans notre mission, cette phase est en fait concrètement décomposée

en deux sous phases appelées : « phase de rapport » (8 %) et « phase
de finalisation » (8 %).
3.3.5.1. Phase de rapport

L’écriture du rapport final (la version 0 que l’on envoie aux services
audités) ne peut se concevoir qu’après l’exécution de toutes les phases
précédentes. Néanmoins, l’élaboration du plan, de la structure et des
grands pavés du pré-rapport (appelé le projet ou draft) peut être
débutée beaucoup plus en amont et complétée au fur et à mesure lors
du déroulement des phases.
3.3.5.2. Phase de finalisation de la mission

Elle comprend :
– la présentation du projet et l’examen des incohérences ou points
faibles, l’obtention d’un accord avec les audités, puis l’élaboration
définitive des recommandations (l’application de ces dernières sera
contrôlée ultérieurement grâce aux fiches de suivi) ;
– l’établissement définitif des fiches de suivi et l’envoi de la lettre de
clôture de la mission (cette dernière ne sera envoyée aux divers
acteurs concernés qu’après réception de l’accusé de réception de notre
rapport par les services audités, sans autre demande de modification).
Pour cette mission d’audit qualité d’un service de support, nous avons
émis trois fiches de suivi : la première concerne la mise à jour de la
documentation technique, la deuxième concerne les fiches d’incident
(dans laquelle nous recommandons de fournir un délai approximatif
aux utilisateurs) et enfin la dernière est en rapport avec la formation
du personnel de support afin d’harmoniser le niveau de compétence de
l’équipe. Il est à remarquer que ces fiches de suivi serviront comme
input pour une prochaine mission du même genre. Enfin, concernant
l’harmonisation en matière de traitement des problèmes soulevés par
les utilisateurs, soit par téléphone soit par fiche d’incidents, nous
avons émis une recommandation, mais il ne nous semble pas
nécessaire d’établir une fiche de suivi. En effet, il suffit d’améliorer la
procédure existante (c’est ce qui a été promis par le service audité).
Une mission d’audit se gère comme un projet en soi. Dès lors, il
importe d’identifier les différentes phases ainsi que les entrées et
sorties (inputs et outputs) correspondants du processus. Après la
réception de la lettre de mission, l’équipe d’audit devrait établir la
démarche et son programme de travail. Ce chapitre détaille donc
les diverses étapes, allant de l’établissement d’un plan d’approche
à la phase de restitution constituée par la phase d’élaboration du
rapport et la clôture de la mission, en passant par les deux phases
de vérification (comprenant les vérifications rapides et les
vérifications détaillées).
Il se termine par la présentation d’un audit qualité d’un service de

support pour illustrer l’approche présentée. A titre d’exemple, une
répartition en temps des diverses étapes du processus d’audit est
proposée, mais il convient de noter que ceci est purement indicatif.
En effet, la répartition réelle est dépendante de chaque projet
spécifique.
FOIRE AUX QUESTIONS
(CHAPITRE 3)
Question 1 : par faute de temps, peut-on se dispenser de la phase de

vérification rapide ?
Réponse : surtout pas, car cette phase est primordiale et l’on finirait
par le regretter. En effet cette phase est nécessaire pour récolter la
documentation et effectuer un premier contact avec les personnes à
auditer.
Question 2 : lorsqu’un point faible est relevé, il est normal qu’un

auditeur le cite dans son rapport, mais peut-il citer le nom de la
personne qui a engendré l’erreur ?
Réponse : il n’est pas souhaitable d’en citer l’auteur. En effet,

quoique responsable de l’erreur, la personne se trouve dans un
système ou contexte lui laissant la possibilité de la faire. Il serait donc
plus diplomate et professionnel de proposer une recommandation pour
éviter de futures erreurs potentielles, plutôt que de citer le nom de la
personne.
Question 3 : quel est le nombre de jours de formation nécessaires

pour un auditeur informaticien de l’entreprise ?
Réponse : il n’y a pas de règles fixes. Il est souhaitable que la

formation soit programmée et bien cadrée suivant les besoins. Une
semaine de formation est un minimum, la moyenne est plutôt de deux
semaines compte tenu de l’évolution rapide des technologies de
l’information.
Ceci ne tient pas compte des formations supplémentaires à suivre chez

les constructeurs lors du changement du système de l’entreprise (si les
auditeurs doivent s’impliquer plus dans les audits systèmes et réseaux)
(voir aussi l’annexe 1).
Question 4 : peut-on découvrir, lors d’une phase de vérification,

l’existence dans un service informatique de l’utilisation simultanée de
deux normes relatives à la qualité des logiciels ?
Réponse : tout à fait, cette découverte n’est pas rare. Cependant

l’auditeur doit vérifier que ces deux normes ne sont pas incompatibles.
Si elles le sont, il importe de le signaler à la Direction générale ou à la
Direction informatique, car c’est aussi le rôle de l’auditeur (voir
également la foire aux questions du chapitre précédent - question 7).
Question 5 : à quel moment peut-on commencer à établir le plan du

rapport ?
Réponse : il n’y a pas de règle fixe. Néanmoins le plan, la structure et

les grands pavés d’un rapport (plutôt le pré-rapport) sont à établir très
en amont. Car ceci permet de fixer la direction du processus.
Ce document établi pendant la phase de vérification peut être

profitable. En effet, à ce moment, on a plus de visibilité et comme
éléments en entrée, on peut citer :
– le plan d’approche ;
– le programme de vérification ;
– quelques éléments obtenus pendant cette phase de vérification…
Question 6 : les fiches de suivi sont-elles nécessaires ?
Réponse : en principe oui. Une mission sans l’élaboration de fiches de

suivi identifie une mission d’audit parfaite, sans aucun point faible
détecté, ce qui est plutôt rare !
Question 7 : lors de l’exemple précédent, dans le dernier chapitre,

une norme est présentée et utilisée, peut-on la combiner avec les
préconisations de type CMM lors d’un audit informatique ?
Réponse : la réponse est catégorique : non ! En effet, même si les

normes ont souvent des philosophies plus ou moins analogues
concernant l’évaluation, une utilisation combinée de deux normes
techniques (normes demandant des exigences différentes) peut
entraîner des confusions pour les audités. Et lors des
recommandations, quel référentiel citera-t-on ?
D’autre part, le second référentiel CMM prend toute sa valeur lors

d’un audit à blanc par les auditeurs internes pour préparer l’entreprise
à la première certification CMM ou préparer l’accès à un niveau
supérieur.
CHAPITRE 4
Les missions d’audit demandées

par la Direction générale
L’énergie usée à atteindre des normes de qualité

est inversement proportionnelle au temps restant avant le prochain audit.
Olivier Sax, écrivain contemporain.
4.1. Audit de la politique informatique
4.1.1. Audit de la politique d’acquisition en vue de l’informatisation

(adéquation des produits verticaux, rentabilité)
Pour concevoir un système d’information ou une application et les

rendre opérationnels, il existe trois moyens : faire, faire faire ou
utiliser un savoir-faire existant.
Néanmoins, il faut identifier l’objet souhaité dès le départ et un des

documents importants d’identification est le cahier des charges ou le
dossier des spécifications.
Le cahier des charges est un document contractuel entre le client

demandeur d’un service (ou d’acquisition de matériel) et ses
fournisseurs. On appelle aussi « cahier des charges » le document
établi entre l’équipe informatique interne d’une entreprise et une SSII

à l’occasion d’une sous-traitance.
Le demandeur de service peut l’établir seul ou avec le fournisseur de

service éventuel. Ce document est primordial, il doit être clair, précis
et sans ambiguïté. En effet, à l’occasion de litiges éventuels, il servira
de document de base d’une façon légale. Son contenu peut s’établir de
la manière suivante.
4.1.1.1. Exemple de cahier des charges

Ce plan est donné à titre d’exemple, car il existe de nombreuses
dispositions en fonction des documents de chaque entreprise.
1. Définition générale et contexte du problème :

– les objectifs ;
– les contraintes.
2. Les documents de base :

– les divers documents et schémas de circulation ;
– les états d’entrée et de sortie (pour une application).
3. Fonctionnalités du futur système :

– les traitements ou modules (ou les détails des matériels) ;
– les solutions envisagées.
4. Les directives :
– les diverses directives ou recommandations ;
– les prévisions d’extension (système ouvert).
5. Conclusion et engagement :
– rappel des engagements mutuels ;
– délai des travaux, planification...
Les directives sont parfois destinées à rappeler certaines notions ou

préconisations du schéma directeur (s’il existe des écarts, ce sera le
rôle du service de contrôle de le signaler), à modifier l’organisation
Missions d’audit demandées par la DG 89
(pour s’adapter au processus d’informatisation par exemple), et les

extensions futures éventuelles.
La Direction peut demander aux auditeurs de participer à ce

processus. Ces derniers peuvent contribuer à veiller à la régularité de
la procédure de l’appel d’offres et de l’établissement du cahier des
charges. Enfin, il est à remarquer que la vérification de la politique
logicielle (harmonisation et compatibilité des logiciels, anti-piratage…)
pourrait aussi faire l’objet d’une mission demandée au service de
l’audit et confiée aux auditeurs informatiques.
4.1.1.2. Utilisation d’un cahier des charges

Cet exemple est extrait d’un cas d’audit réel : lors d’un appel d’offres
pour l’extension d’une application, la Direction générale s’aperçoit
des demandes excessives de tarification de la part des SSII. Souhaitant
comprendre le pourquoi des choses et éventuellement y remédier pour
le futur, la Direction charge une mission d’audit.
Après interviews des acteurs concernés et consultation des documents

existants, l’audit informatique permet de révéler que, dans le cahier
des charges, il manque une partie concernant les prévisions
d’extension et les engagements mutuels entre la SSII et la société.
En fait, l’application était fournie avec un système propriétaire par
l’ancienne SSII qui, entre temps, a été absorbée par une grande
compagnie ; l’équipe des anciens analystes et développeurs a été
dissoute.
De cet audit et du rapport qui en a résulté, on retient la

recommandation suivante :
« Concernant les applications non spécifiques, il serait

souhaitable d’utiliser au maximum les équipements et/ou les
produits COTS (Commercial-Off-The-Shelf equipment/
product) – produits sur étagères – existants sur le marché.
En effet, la maturité de ces produits facilitera la maintenance
et l’extension future ».
D’autre part, le rôle de l’auditeur peut consister à fournir des conseils

concernant :
– le choix d’un produit par comparaison avec les études de CXP par
exemple ;
– le choix d’un type de produit similaire tel que l’ASP (Active Server
pages package) parmi ceux offrant l’application demandée ;
– le choix d’une politique de sous-traitance pour des produits verticaux
très spécifiques.
4.1.2. Audit des projets et futurs projets (audit de processus de développement)
Une mission d’audit d’un nouveau projet d’informatique (ou plutôt

d’un processus de développement en cours) peut être souvent
demandée par la Direction. L’engagement d’un projet ne peut se
concevoir sans l’assurance que quelques grands principes, avant
même le début de la réalisation, soient respectés. En effet, un nouveau
projet ne doit pas seulement son existence qu’à cause des besoins
pressants et urgents des utilisateurs. Il ne se justifie qu’après l’analyse
de l’existant et l’étude d’opportunité. Enfin, il doit être piloté et suivi
par un comité et/ou un chef de projet qui rendra compte régulièrement
aux comités de direction ou aux organes décisionnels de l’entreprise.
L’audit informatique peut être sollicité par la Direction pour l’assister,

pour confirmer ou infirmer le diagnostic de départ.
On voit donc que les rôles de l’auditeur sont :

– s’assurer de l’intérêt du nouveau projet ;
– s’assurer de l’existence d’une coordination et de l’existence d’une
remontée d’information vers les organes de décision ;
– s’assurer de la véracité et de la pertinence des points forts et points
faibles soulevés ;
– veiller aux coûts (s’assurer de l’inexistence des faux frais...), la
planification et la régularité du financement.
Une remarque importante : après la phase d’analyse de l’existant, on

débouche sur celle de l’analyse de conception, étape limite où le
service d’audit interne doit conseiller le développement et

l’intégration des audits trail (voir lexique) dans les applications.
Ces « détecteurs de trace » faciliteront le contrôle, les tests et l’audit

ultérieur de la future application.
Dans ces contextes, il importe de suivre la démarche suivante pour

auditer :
1) identification de la méthode choisie par le comité et/ou responsable
de projet : la méthode choisie est primordiale car son adéquation à la
situation peut retarder ou faire avancer considérablement un projet
d’informatisation. L’expérience de l’équipe vis-à-vis d’elle, l’adhésion
et les retours d’expérience sont des questions primordiales à se poser ;
2) prise de conscience des points forts et des points faibles dans le
contexte audité : les réponses précédentes permettent de fournir
quelques éléments de réponse du diagnostic et d’établir la liste des
points faibles ralentissant le projet, après interviews des acteurs
concernés et consultations des divers documents existants ;
3) vérification des points faibles : cette phase est très importante car
elle permet de vérifier les éléments recueillis précédemment, et ce,
avant d’aborder la dernière phase. Tant que tous les éléments ne sont
pas vérifiés, les auditeurs ne peuvent émettre les recommandations et
conseils ;
4) élaboration des recommandations : cette phase clôture la démarche
proposée. Les recommandations justes, précises et pertinentes
constitueront les plus-values de la mission d’audit informatique.
Nous donnons ci-après un exemple de l’application de cette démarche.
Confrontés à une mission d’audit dans un environnement de

développement moderne (application pour le Web), les auditeurs ont
pour mission de fournir, si possible, des recommandations afin que
l’application développée se comporte sans bugs (ou le moins possible)
et que les délais de livraison soient respectés.
Tout d’abord, les auditeurs identifient la méthode pratiquée et

l’expérience de l’équipe vis-à-vis d’eux, son adhésion au projet, ainsi
que l’existence de retours d’expérience.
A partir de la documentation existante et des interviews des acteurs

concernés, les auditeurs découvrent que la méthode XP (eXtreme
Programming) est relativement nouvelle pour l’équipe de
développement. Néanmoins, celle-ci est très motivée, mais il s’avère
que les codes collectifs dans la bibliothèque logicielle étaient peu
nombreux.
Les auditeurs découvrent les points forts suivants :

– motivation de l’équipe ;
– coopération active entre les développeurs et les utilisateurs ;
– la méthode est adaptée pour ce type d’application.
Cependant, les points faibles sont :

– formation à la démarche XP pas encore assurée à tous les
développeurs ;
– manque de codes collectifs réutilisables ;
– mélange des versions de tests associé à un problème de gestion des
configurations.
La phase de vérification permet de confirmer les éléments trouvés

précédemment. En effet, compte tenu du problème de maturité de
l’équipe concernant XP et le manque d’outil de gestion de
configuration adéquate, les tests et leurs résultats n’étaient ni suivis, ni
mis en œuvre d’une manière convenable. La confirmation de nos
éléments de diagnostic, après vérification, permet d’élaborer la
recommandation suivante :
« La formation de toute l’équipe à la méthode XP ainsi

que l’apport d’un outil de gestion de configuration
devraient améliorer le développement des applications et
réduire les délais. Enfin, il est vivement conseillé de
simuler les corrections avant de les mettre en exploitation
réelle. »
En résumé
L’objectif de l’audit du processus de développement du logiciel est de

fournir à la Direction et/ou au maître d’ouvrage une confirmation de la
conformité du processus de développement suivi par l’entité
auditée (maître d’œuvre, constructeurs, sous-traitants…) vis-à-vis des
dispositions d’Assurance qualité du logiciel, elles-mêmes définies par
l’état de l’art, les règlements normatifs ou des spécifications établies au
préalable.
De ce fait, les éléments suivants doivent être vérifiés par les auditeurs
informatiques :
– politique de gestion de la qualité du logiciel ;
– fonction qualité logiciel (responsabilité et autorité, ressources pour la
vérification…) ;
– documentation du système qualité logiciel (manuel qualité logiciel,
plan qualité logiciel…) ;
– management de projet (responsabilité, planning, revues…) ;
– contrôle qualité du logiciel (cycle de développement, méthodologie
de développement, outil…) ;
– activités de gestion de projet (vérification des documents, gestion de
configuration, gestion, des modifications, mesure de la qualité…).
Des métriques objectives doivent être utilisées pour chacun de ces

critères. Ces métriques doivent être définies au préalable et connues
par les audités.
Ainsi, les résultats de l’audit du processus de développement du

logiciel permettent :
– d’identifier les données et processus manquants ou incomplets dans
le développement en vue d’apporter des recommandations
d’amélioration ;
– d’évaluer, dans le cadre d’une certification ou d’une qualification du
logiciel, les sources potentielles de défaillance de ce dernier ;
– d’évaluer les points forts et les points faibles des acteurs (maître
d’œuvre, sous-traitants,…) en terme de processus de développement du
logiciel ;
– de recommander le choix ultérieur d’un ou plusieurs acteurs pour la
maintenance ou la sous-traitance (ex : dans le cadre d’appel d’offres).
4.2. Audit relatif aux finances de la fonction informatique
Ce type d’audit est très souvent demandé soit par la Direction générale
soit par la Direction financière. En effet, soucieuses des
investissements et de leur rentabilité, ces deux directions sont parties
prenantes des projets informatiques. Ce type d’audit permet de
détecter le fonctionnement correct des démarches budgétaires et de
mesurer les écarts financiers.
4.2.1. Audit du budget et du suivi
Afin de bien vérifier cette démarche, il importe de distinguer les

budgets de fonctionnement de celui des investissements.
Rappelons que les premiers types de budgets concernent l’exploitation

courante ; les dépenses sont du côté débit du compte d’exploitation
informatique dans un système comptable. Quant aux seconds, ils
concernent les dépenses en matière d’investissement (achat de
matériels, de systèmes, de progiciels…) et de développement de
logiciels nécessaires pour les activités de l’entreprise. La séparation de
ces deux types de budget est fondamentale, car elle permet de mesurer
les équilibres et les adéquations des budgets des postes.
L’objectif de l’audit du budget et du suivi est de s’assurer de la

fiabilité des mécanismes de prévision et de suivi budgétaires. Dans ce
contexte, l’auditeur doit vérifier les points suivants :
– l’élaboration du budget concernant chaque chapitre ;
– sa structure ;
– son évolution ;
– son suivi.
Autrement dit, il est nécessaire de connaître quand, comment et par

qui le budget est élaboré. Il importe aussi de savoir comment il évolue
et comment et par qui il est suivi. Le budget est-il vérifié d’une part
par des acteurs responsables du service et/ou du projet, et d’autre part,
par un contrôleur de gestion interne ou externe ?
4.2.2. Audit sur la comptabilité analytique
La comptabilité analytique est indispensable dès lors qu’il y a un

besoin accru de détail et que la taille du service informatique croît. En
effet, si elle n’est pas légalement exigible, elle est plutôt exigée par la
Direction générale et /ou par les actionnaires avertis pour connaître les
imputations et les dépenses de chaque poste. Si la taille de l’entreprise
est assez grande, le centre ou le service informatique peut alors être
considéré comme une division, ou pourquoi pas, un centre de profit et
de service. Dès lors, l’établissement d’une comptabilité analytique
peut fournir des éléments intéressants pour mener sa stratégie et les
analyses ultérieures.
Les charges sont alors découpées par nature et divisées en deux

ensembles : les charges directes et les charges indirectes.
Les charges directes sont celles directement imputables aux

applications ou aux projets identifiables et répertoriés, alors que les
charges indirectes seront imputables à ces mêmes applications ou
projets mais via des sections ou chapitres spécifiques d’abord. Par
exemple via les lignes ou codes budgétaires pour les études, les
traitements, les postes d’énergie, l’achat des fournitures…
Nous n’allons pas rentrer davantage dans les détails d’un système de
comptabilité analytique, mais nous allons identifier les objectifs de
vérification et les rôles des auditeurs dans ce cadre.
Les objectifs dans ce genre de mission sont les suivants :

– vérifier l’existence d’une comptabilité analytique adéquate dans le
service ;
– analyser le degré de granularité et de détail (est-ce suffisant ? est-ce

que la nature et les imputations destinatrices sont bonnes ?).
Pour ce faire, le rôle de l’auditeur est :

– d’examiner tous les documents relatifs de cette comptabilité ;
– vérifier le découpage des charges ;
– vérifier leur affectation aux divers projets et/ou applications.
En fin de mission, les auditeurs devraient être en mesure de prononcer

l’adéquation du système analytique ou éventuellement émettre des
recommandations pour l’amélioration du découpage et/ou pour les
imputations ultérieures.
4.2.3. Audit sur les prestations internes
En général, une direction informatique (DI) fournit des services aux

autres directions. Il importe de distinguer les services fournis et les
charges relatives. Les méthodes de facturations sont nombreuses et
dépendent de la nature des services ; par exemple une distinction doit
être faite en fonction des prestations fournies en matière
d’exploitation, de maintenance ou pour les études.
Dans ce contexte, les rôles de l’auditeur sont les suivants :

– vérifier la justesse de la facturation ;
– assurer une compréhension facile pour les utilisateurs des directions
que la DI facture ;
– vérifier la permanence des tarifs ;
– veiller à l’harmonisation dans la facturation : à services fournis
identiques, la méthode de facturation doit être identique.
Il importe que les factures de prestations envoyées aux utilisateurs

soient claires, concises et transparentes. Un changement de tarif du
prestataire doit être signalé aux services utilisateurs en temps
opportun ; par exemple suffisamment à l’avance à ces derniers afin
qu’ils puissent eux-mêmes préparer leurs propres budgets de
fonctionnement ou d’investissement.
4.2.4. Audit des coûts
L’audit des coûts informatiques fait partie des outils du management.

De ce fait, ce genre de mission est souvent demandé par la Direction
générale et/ou par la Direction informatique. Cependant il faut
dissocier les coûts d’investissement à ceux de fonctionnement.
Ainsi, concernant les coûts de fonctionnement, le rôle de l’auditeur est

de :
– s’assurer de la rentabilité des systèmes (applications et machines) ;
– s’assurer de la maîtrise des coûts par les gestionnaires ;
– vérifier que la croissance des coûts est conforme aux prévisions
(sinon, rechercher les causes) ;
– fournir éventuellement des recommandations ou proposition des
solutions d’extension.
Les démarches de l’auditeur pour accomplir sa mission sont :

– évaluer la facturation interne et externe ;
– évaluer la comptabilité analytique ;
– calculer les coûts de la non-qualité (évaluer les pertes ou manque à
gagner dus aux pannes des systèmes) ;
– incorporer les coûts annexes (dépenses exceptionnelles de saisie, de
location du matériel pour dépannage...) ;
– évaluer la comptabilité des systèmes. Ce point consiste à analyser
le temps UC ou CPU (Central Processing Unit), le temps d’utilisation
des diverses ressources (disques, imprimantes...) ainsi que l’occupation
des espaces disques. Cette démarche permet de surveiller la qualité et
la fiabilité des machines, d’éviter les contre-performances et de
prévoir l’évolution ;
– recenser le nombre d’utilisateurs des systèmes et observer
l’évolution ;
– recenser l’évolution des coûts (accroissement raisonnable ?).
Prenons un exemple pour illustrer ces deux derniers points. Ces

données pourront contribuer à l’analyse de l’auditeur. Les deux
schémas suivants permettent d’observer et comparer l’évolution des
coûts dans un CTI (centre de traitement d’information) ou dans un

centre de serveurs. Le premier graphique montre l’accroissement des
volumes d’informations traités durant les trois années N. Le deuxième
montre, quant à lui, les coûts durant la même période de temps.
45
40
35
30
25
Série1
20
15
10
5
0
année 1 année 2 année 3
Figure 4.1. Schéma montrant le volume d’informations traitées
700
600
500
400
300
200
100
0
année 1 année 2 année 3
Figure 4.2. Schéma montrant l’évolution des coûts
Une étude comparative peut être intéressante et révéler des erreurs de

gestion. En deux ans (entre les années 1 et 3), le volume d’informations
à traiter a crû de 30 % :
40 − 10
30 % qui est égale à :
100
600 − 100
et le coût a augmenté de 500 % :
100
Or, pour une même période de deux ans (entre les années 0 et 2), le
volume d’information a crû de 30 %, pour un delta de coût énorme et
non linéaire. On en déduit un accroissement abusif des coûts de
fonctionnement (500 %, le coût a donc explosé), si aucune
justification tangible ne peut être avancée. Dès lors le rôle de
l’auditeur informatique est de rechercher le pourquoi et le comment
des choses.
Cette étude comparative peut aussi se faire avec l’observation de

l’accroissement du nombre des utilisateurs.
Une étude multicritères (nombre d’utilisateurs, coût, volumes

d’information traités, éléments statistiques du système...) pourrait être
faite selon le même principe. Elle pourrait mieux démontrer
l’évolution et révéler les points faibles de gestion.
Faisant suite à l’audit de ce centre, nous avons émis la recommandation

suivante :
« Il importe, d’une part, de réduire les coûts en identifiant

les surcoûts générés par le suivi mensuel du budget par le
responsable informatique et en les rectifiant et d’autre
part, de revoir les besoins réels en terme d’états de sortie
de listing (outputs listing) avec les utilisateurs ».
En effet, lors des interviews des utilisateurs, nous avons découvert le

stockage des listings fournis sans réelle utilisation. Ces documents ont
été fournis « historiquement et systématiquement » par le service
informatique, sans discussion et renégociation avec les utilisateurs.
Les principaux clients demandeurs d’audits informatiques dans les
grandes structures sont, sans conteste, les Direction générale et
Direction Informatique. Souvent, ce sont les mêmes types de
missions qui sont demandés (les missions de type cycliques).
Cependant, plutôt soucieux des investissements et de leur ROI
(retour sur investissement), la Direction générale, quant à elle,
mandate parfois des audits concernant la politique informatique
engagée ou vis-à-vis de la politique d’acquisition, ou encore des
audits relatifs aux finances de la fonction informatique.
Ce chapitre détaille ces principes et fournit des exemples et des
recommandations concernant ces types de missions. Ainsi, le
dernier exemple exposé, avec deux graphiques, permet de détecter
et de montrer aux lecteurs la non-cohérence de l’évolution des
coûts par rapport aux volumes d’informations fournis aux
utilisateurs. Il va de soi que ces informations intéresseraient au
plus haut point une Direction générale.
FOIRE AUX QUESTIONS
(CHAPITRE 4)
Question 1 : le cahier des charges est-il un document important pour

l’auditeur ?
Réponse : ce document est primordial pour l’auditeur. En effet, il

permet de détecter l’adéquation des services demandés avec ceux
fournis par une société mandatée ou fournisseur.
Question 2 : pour un grand projet, quels sont les points importants à

identifier dans un cahier des charges ?
Réponse : dans un grand projet, un des points importants concerne la

clarté des services demandés et le partage des tâches en un certain
nombre de lots. Ce dernier processus permet de mieux identifier les
tâches accomplies et les délais de livraison afin d’éviter les désaccords
éventuels.
Question 3 : est-il important pour un auditeur de savoir identifier un

budget de fonctionnement et celui d’investissement ?
Réponse : il est primordial de savoir dissocier ces deux types de

budgets. Trop souvent, une mauvaise imputation alourdit à tort
un budget d’investissement. En effet, ce dernier est amortissable
(du point de vue comptable), alors que celui de fonctionnement ne

l’est pas.
Question 4 : une diminution progressive des investissements

informatiques est-elle bénéfique pour l’entreprise ? Que doit faire
l’auditeur qui la détecte ?
Réponse : la diminution progressive des investissements n’est souvent

pas très bénéfique pour l’entreprise. En effet, ceci montre un intérêt
décroissant des dirigeants quant au renouvellement des systèmes
informatiques en général, et parfois en particulier des logiciels. Ceci
est contraire à l’évolution rapide de l’informatique et de la
technologie. Après vérification, si tel est le cas, l’auditeur doit tirer la
sonnette d’alarme.
Question 5 : la vérification des activités de gestion du projet est-elle

du ressort des auditeurs ?
Réponse : tout à fait, car les activités ainsi que les méthodes utilisées
pour gérer les projets conditionnent la réussite de ces derniers. Dès lors,
les auditeurs pourraient être amenés à vérifier le bienfait des activités et
l’adéquation des méthodes entreprises par les responsables
informatiques pour gérer les projets ou services.
CHAPITRE 5
Missions d’audit demandées

par la Direction technique/informatique
Evidence…
Qui ne demande rien, n’a rien
proverbe anonyme
5.1. Audit sur l’utilisation des logiciels (utilisation, licences, piratage)
Très souvent, au sein des PME et PMI, le nombre de licences des

logiciels utilisés ne correspond pas au contrat avec l’éditeur du dit
logiciel. Les raisons évoquées sont souvent des oublis de mises à jour,
la croissance du nombre d’utilisateurs ou l’augmentation des coûts des
licences (raisons économiques). Or, la loi est très sévère en cette
matière, car cette situation est assimilée à un délit répréhensible. Le
caractère délictueux est d’autant plus vraisemblable que les logiciels
dits horizontaux sont utilisables par les PC banalisés, contrairement
aux ordinateurs dédiés et programmés spécifiquement pour la
production ou la gestion de production.
Pire encore, on constate souvent un piratage des logiciels ou des

changements de paramètres des logiciels d’évaluation téléchargés à titre
gracieux. Car pour les éditeurs, les clauses sont très strictes.
En voici un exemple, extrait d’un contrat d’utilisation de logiciel

associé au contrat de vente :
Droits et limites
Par la présente, l’entreprise X offre à l’utilisateur un droit

d’utilisation du logiciel, non exclusif et non transférable,
en respect des conditions suivantes.
a) Droits
L’utilisateur peut installer et utiliser une copie du logiciel

sur un seul ordinateur ; aucune autre copie du logiciel ne
doit être faite excepté une de copie de secours. Cette
licence logicielle ne peut être partagée ou utilisée
simultanément sur des ordinateurs différents.
b) Exception Linux
En dépit des termes qui précèdent, section précédente, le

logiciel exclusif à l’utilisation sur système d’exploitation
Linux peut être copié et redistribué à la seule condition
que ses fichiers binaires ne soient modifiés d’aucune
manière que ce soit (sauf pour la compression et
décompression des fichiers).
c) Limitations
Il est interdit d’effectuer une ingénierie inverse.

L’utilisateur n’a pas le droit d’opérer une ingénierie
inverse, de décompiler ou désassembler le logiciel, ou
encore d’essayer d’obtenir par n’importe quel moyen que
ce soit le code source. Il est interdit de séparer les
éléments logiciels. Le logiciel dispose d’un brevet
unique. Les éléments qui le composent ne doivent en
aucun cas être séparés pour être utilisés sur d’autres
ordinateurs ou de manière indépendante.
Missions d’audit demandées par la DTI 105
Il est interdit de louer le logiciel. L’utilisateur n’a pas

le droit de louer sous quelque forme que ce soit le
logiciel à un tiers.
D’autre part, la loi sanctionne aussi fortement une personne utilisant

une copie. Par exemple l’article L. 122-6 du Code de la propriété
intellectuelle stipule que lorsque l’œuvre est un logiciel toute
utilisation d’un logiciel non expressément autorisée par l’auteur ou ses
« ayants droit » est illicite.
Ainsi, si le délit pénal de contrefaçon lui-même est lié à la

reproduction illicite du logiciel (ce qui implique qu’un simple
utilisateur ne pourra voir sa responsabilité pénale engagée sur ce seul
fondement), l’utilisation d’une copie illicite de logiciel devrait, en
principe, être suffisante pour engager directement la responsabilité
civile de cet utilisateur. Les sanctions financières peuvent aller jusqu’à
plus de 76 000 euros (500 000 francs).
De ce fait, le rôle de l’auditeur dans une mission d’audit des logiciels

est de :
– vérifier l’existence d’une documentation complète des produits
utilisés ;
– vérifier l’adéquation des produits utilisés ;
– vérifier l’existence d’un planning de formation des utilisateurs ainsi
que le respect de l’exécution de ce planning ;
– vérifier l’existence des contrats d’utilisation de logiciels ;
– vérifier que le nombre de produits installés correspond à celui décrit
dans le document précédent ;
– détecter les copies et les logiciels illicitement installés.
Enfin, il est opportun de signaler que le respect de la législation est

primordial, car parfois une seule sanction financière infligée peut
ruiner ou mettre en difficulté les petites PMI et PME.
5.2. Audits de qualité de services et de l’informatique horizontale
Le CLUSIF (Le Club des utilisateurs informatiques en France) a

publié des chiffres alarmants au niveau de l’Hexagone. En effet, d’après
leur récente enquête concernant 608 entreprises et administrations
(résultats publiés en 2004), les chiffres relatifs aux risques encourus,
aux divers accidents et/ou attaques réalisées permet d’établir la liste
suivante :
– accidents d’ordre interne : 37 % ;
– accidents d’ordre externe : 13 % ;
– virus ou vers informatiques : 67 % ;
– attaques ciblées : 7 % ;
– atteinte à l’image de la société ou du service : 2 % ;
– chantages ou fraudes : 1 %.
Si l’on additionne les accidents d’ordre interne et externe, on obtient

le chiffre de 50 %, ce qui montre l’importance de l’exploitation et de
l’utilisation des ordinateurs ainsi que la qualité des services des
systèmes. Quant aux derniers chiffres concernant les problèmes de
virus et des attaques, nous les traitons ultérieurement.
Dès lors, il est opportun d’appréhender d’une part, la qualité de

service des systèmes liée à leurs performances et d’autre part, à la
mauvaise utilisation et exploitation des produits logiciels horizontaux
de l’entreprise.
5.2.1. La qualité de service des systèmes
La qualité de service ne peut se concevoir sans une surveillance

assidue des systèmes et l’existence de relevés d’incidents. Ces
derniers, recensés et complétés au fur et à mesure, forment le journal
des incidents. Outil de travail quotidien des exploitants de calculateurs,
ce journal révèle des informations intéressantes pour l’audit informatique
lors des missions intermittentes.
Un recensement systématique, une centralisation des informations et

une consolidation auprès d’un service de statistiques permettraient de
dresser des tableaux de bord de suivi de la qualité de service des
systèmes informatiques de l’entreprise, à l’échelon local, voire
national si la société possède plusieurs unités de calcul, serveurs ou de
sites de traitement géographiquement disparates (filiales, agences
locales de représentation...).
Les pages suivantes donnent un exemple de suivi d’incidents et de

qualité de service des systèmes. Ces éléments sont :
– le journal des incidents qui peut se définir comme un document de
base où l’on relève quotidiennement les événements dans le but de
surveiller le système ou le serveur et d’établir les statistiques ;
– deux exemples de tableaux de bord décrivant les domaines observés
(systèmes informatiques par application) ;
– un graphique récapitulant la qualité globale du service en temps réel.
REMARQUE.– Par principe déontologique, nous ne fournirons ni les

noms des systèmes informatiques, ni ceux des applications.
Le « système A » désigne un gros serveur de type IBM ou DPS8 de

Bull. Les « systèmes B ou C » désignent les ordinateurs de type Escala
de Bull ou HP 9000.
Les chiffres ont été élaborés et récoltés durant plusieurs mois et nous
ont été fournis lors de l’audit. Le sigle « TMBF » signifie : temps
moyen de bon fonctionnement.
A partir des journaux d’incidents et des statistiques d’exploitation du

centre, le responsable système a pu relever les éléments et établir les
deux tableaux de bord suivants :
– le premier concerne la QoS (Qualité de service) globale pour les
utilisateurs en temps réel et la QoS globale des calculateurs ;
– le deuxième concerne la QoS des interventions des constructeurs et
les indisponibilités détaillées des trois ordinateurs.
5.2.1.1. Tableau de bord n° 1

Ce tableau de bord se compose des deux éléments ci-dessous.
5.2.1.1.1. Qualité de service global pour l’utilisateur temps réel
Principaux indicateurs Valeur du mois Moyenne

des 6 derniers mois
Taux d’indisponibilité 1,08 1,09
TMBF Utilisateur (en heures) 96,40 99,30
Nb. Moyen d’arrêt/utilisateur 1,91 1,92
Durée moyenne d’un arrêt (en 1,05 1,10
heures)
Tableau 5.1. QoS global pour l’utilisateur
Dans les termes anglo-saxons on retrouve souvent le mot « MTBF »

(Mean Time Between Failure) (voir lexique).
D’une certaine manière, le TMBF est le complément du MTBF. En

effet le TMBF est égal au temps total d’observation moyen retranché
du MTBF.
5.2.1.1.2. Qualité de service global des calculateurs

des 6 derniers mois
TMBF Utilisateur (en heures) 3,62 2,62
Nb. Moyen d’arrêt/utilisateur 0,27 0,38
Durée moyenne d’un arrêt 1,92 1,64

(en heures)
Tableau 5.2. Equipements centraux ayant engendré des arrêts complets

pour tous types d’utilisateurs
5.2.1.2. Tableau de bord n° 2

Les éléments indicateurs ci-dessous déterminent la qualité de service
des constructeurs et fournisseurs ainsi que le taux d’indisponibilité des
ordinateurs. Ils constituent le tableau de bord n° 2.
5.2.1.2.1. Qualité de service d’intervention

Les chiffres du tableau ci-dessous concernent toutes les interventions
et tous les SAV.

des 6 derniers mois
Délai moyen de relevé 7,98 7,42
(en heures)
dont délai d’intervention 6,58 5,42
dont délai de réparation 1,40 2,00
Taux de dépassement 38,54 23,86
des délais (%)
par rapport au contrat
Nombre d’interventions 0,45 0,64
par système observé
Tableau 5.3. Qualité de service d’intervention
5.2.1.2.2. Taux d’indisponibilité des systèmes

Pour le système A, le décompte des temps moyens d’arrêts résulte de
l’application d’une pondération par application traduisant la
dégradation globale du service.
Pour les systèmes B et C, seuls les arrêts complets des systèmes sont
décomptés. Cette différence est due au fait que pour les deux derniers
ordinateurs, on ne travaille qu’en mono-application.
Système Valeur du mois Moyenne des 6 derniers

mois
A 2,02 1,38
B 0,24 0,47
C 0,02 0,30
Tableau 5.4. Taux d’indisponibilité des systèmes
Enfin, en comptabilisant par poste d’utilisateur et par mois, le schéma

suivant permet de bien voir l’évolution annuelle du taux d’indisponibilité
(en %) et du TMBF (taux moyen de bon fonctionnement) en heures.
La qualité globale du service temps réel de tous les produits et

applications confondus est inversement proportionnel aux taux
d’indisponibilité.
Dans le schéma ci-dessous, la première série présente les valeurs

mensuelles, la seconde représente la valeur de la moyenne glissante du
semestre. Ces chiffres étaient recueillis par le responsable système
durant une année civile d’exploitation en tenant compte aussi des
indisponibilités dues à la maintenance des ordinateurs et des upgrades
(mise à jour) des systèmes d’exploitation. De ce fait, les taux paraissent
élevés. Mais l’objectif est de rester en dessous de 20 %.
Taux d'indisponibilité d'utilisateurs
25
Taux en %
20
15 Série1
10 Série2
5
0
v
ril
n
ct
éc
ût
Fé
Ju
Av
O
Ao
Mois
Tableau 5.5. Taux d’indisponibilité d’utilisateurs

Fort de ces informations, le rôle de l’auditeur est de :

– s’assurer que les temps d’arrêt des utilisateurs n’ont pas d’impact
sur le personnel et les clients de l’entreprise ;
– contrôler que les durées moyennes des arrêts des machines ainsi que
le nombre d’arrêts restent dans la limite des chiffres fixés dans le
contrat de maintenance du sous-traitant ;
– vérifier que l’objectif du taux d’indisponibilité est respecté.
5.2.2. Audit de l’utilisation et de l’exploitation des logiciels horizontaux
Compte tenu de l’existence sur le marché de nombreux logiciels prêts

à utiliser, le développement ad hoc des produits dédiés à une PME ou
PMI est de plus en plus rare, surtout en ce qui concerne la gestion
administrative, la comptabilité et autres produits de gestion. Dès lors,
il suffit que le responsable de l’entreprise et/ou son responsable
informatique identifient bien leurs besoins puis choisissent les
produits existants et adéquats du marché (concernant le processus de
choix, voir ci-dessous). Ceci est d’autant plus vrai pour les progiciels
de gestion et/ou d’aide de décision appelés souvent des PGI (produits
gestion intégrés) ou des ERP (Entreprise Resources Planning). Ils
sont souvent identifiés comme des logiciels ou produits horizontaux.
Historiquement par exemple, les progiciels de gestion de paie ont vu

le jour dans les années 1970 et furent vendus avec une documentation
complète, voire même avec un programme de formation et une
assistance technique (d’où la notion de package avec le terme
« progiciel »). Au cours des années 1980, d’autres fonctionnalités et
modules ont été créés et vendus pour faciliter les tâches des DRH ou
de leurs équipes (modules de gestion individualisée pour la formation
des employés et pour le recrutement...).
Dès les années 1990, avec le rôle accru des DRH et l’avènement des
micro-ordinateurs, l’intégration des modules précédents dans un grand
progiciel a été perçue comme nécessaire et profitable. Ce phénomène,
avec la conjonction du développement fulgurant des nouvelles
technologies, a amené un nouveau concept celui du « ERM »,
Employee Relation Management (ou gestion de la relation employé) à
partir de l’année 2000. Un bon nombre d’éditeurs proposent même la

possibilité de gestion via le Web, permettant ainsi une consultation à
l’extérieur de l’entreprise. Citons quelques vedettes du marché :
ARCOLE RH (de l’éditeur ARES), ORACLE HRMS (d’ORACLE),
My SAP RH de SAP...
Du point de vue gestion commerciale, le progiciel CAMPUS

(Computer Aided Management and Production Unifying System) est
reconnu pour ces modules intégrés de gestion des achats, des ventes,
de la gestion des stocks, de la facturation ainsi que la fourniture des
éléments pour la comptabilité. Cependant, il faut savoir qu’il ne suffit
pas d’acquérir un bon produit pour, qu’automatiquement, les
problèmes informatiques et de gestion soient résolus. En effet, les
audits pratiqués nous montrent souvent des faiblesses concernant le
choix adéquat d’un progiciel pour l’entreprise ainsi que sur la
formation des utilisateurs.
De ce fait, le rôle de l’auditeur, en ce qui concerne l’utilisation et

l’exploitation des logiciels horizontaux, lors d’une mission est de
vérifier :
– l’adéquation entre l’investissement et le besoin de l’entreprise ;
– que la formation des utilisateurs vis-à-vis du logiciel horizontal est
suffisante pour son exploitation optimum ;
– le contrat de maintenance avec l’éditeur ou le fournisseur du produit
et services ;
– l’interfaçage avec les autres produits existants, par exemple le
logiciel de comptabilité…
5.3. Audit d’un grand centre de serveur ou d’un Business Intelligence

Centre
Pour illustrer nos propos précédents, nous donnons des exemples

extraits d’un audit d’un centre de serveur. Ce dernier est dédié à des
chercheurs pluridisciplinaires dans le domaine de la recherche pour
l’amélioration des réseaux et des trafics. En voici la mission : ayant
migré d’un centre classique de mainframe vers un centre de type
serveurs, la Direction générale mandate un audit sur le fonctionnement

de ce nouveau Business information Centre, moins d’un an après la
migration complète.
La lettre de mission est envoyée simultanément à la Division

informatique et au responsable d’audit. S’apercevant que la requête est
assez vague, ce dernier se réunit avec ses deux auditeurs pressentis
pour la mission et propose de redéfinir le sujet avec plus de précision.
Ainsi l’intitulé de la mission devient « audit de l’organisation, du
fonctionnement et des risques du nouveau centre ».
Cette proposition est envoyée à la Direction générale. L’acceptation

est parvenue une semaine plus tard (avec un mot de remerciement et
de félicitation) au service d’audit. Dans ce genre de mission, l’auditeur
doit chercher à comprendre l’organisation des services, le rôle de
chaque acteur dans cet environnement, et connaître les documents
associés (qui pourraient l’aider dans sa mission). Ceci contribue à
trouver les risques endogènes et exogènes du centre. Nous donnons un
exemple pour illustrer cette démarche.
A l’instar de toutes les missions, le responsable d’audit prévoit un

planning avec ses deux auditeurs, comme suit (le nombre total de
jours évalué est de 35 jours ouvrables) :
– phase de pré-audit et de planification (16 %) ;
– phase d’enquête préliminaire (24 %) ;
– phase de vérification rapide (18 %) ;
– phase de vérification ou réalisation de l’audit proprement dit
(26 %) ;
– phase de restitution et de rapport (16 %) comprenant :
- la phase de rapport (8 %),
- la phase de finalisation (8 %).
Il convient de remarquer que la phase de pré-audit et de planification

(16 %, 5 jours et demi environ) a été un peu plus conséquente par
rapport à l’habitude. Ce fait est dû à la redéfinition de l’objectif et à la
soumission de ce dernier à l’accord de la Direction générale. Il en est
de même pour la phase de réalisation de l’audit proprement dit (26 %).
L’explication découle du fait de la nécessité de vérifier et d’auditer

aussi bien le personnel interne, que les sous-traitants. Maintenant,
focalisons-nous sur les outils et éléments d’investigation.
5.3.1. Les outils et éléments d’investigation
Les outils des auditeurs sont principalement, en dehors de leurs

propres méthodes, les documents du centre (dossier d’exploitation,
fiches d’incidents, cahier de bord...) et les flow charts ou schémas de
circulation des documents établis par eux-mêmes, lors de la mission.
Ces schémas permettent ainsi de montrer d’une façon simple le
fonctionnement du service et les tâches de chaque acteur ou
participant d’un processus. Les autres documents usuels dans ces
situations sont le planning général mensuel ou hebdomadaire, le cahier
de bord (qui devrait être à jour) des ordinateurs serveurs, les relevés
ou journaux d’incidents, le dossier d’exploitation.
Ce dernier dossier doit permettre :

– de connaître les procédures journalières ou hebdomadaires utilisées ;
– d’exécuter les procédures et de connaître la marche à suivre en cas
de panne, de reprise ;
– d’ajuster les ressources physiques et logiques en service dégradé ;
– de connaître les commandes automatiquement exécutées par le
système ou la séquence des JCL (voir lexique).
De ce fait, le rôle de l’auditeur est de :

– s’assurer de l’existence des documents précédemment cités ainsi que
de leur bonne tenue (dossiers à jour, éléments inscrits clairs et sans
ambiguïté) ;
– s’assurer que les plannings soient respectés, et que si un cas de
dérapage se présente, il existe des solutions de repli, de reprise lors
des défaillances des systèmes ;
– s’assurer de l’existence des bonnes méthodes de travail.
5.3.2. Quelques résultats de l’audit
Concernant l’organisation et le fonctionnement du nouveau centre,

aucun problème majeur n’a été détecté. En effet, le redéploiement des
informaticiens internes a été bien planifié (par la Direction générale et
la Division informatique) et exécuté. Le responsable et quatre autres
personnes restent dans la division pour la supervision, la coordination,
les permanences et les relations avec la société de sous-traitance
d’infogérance. Sur les quinze autres personnes, cinq postes n’étaient
pas remplacés après les départs en retraite et les autres personnes
étaient redéployées dans les services administratifs et dans les unités
de recherche pour les travaux de soutien et d’assistance aux
chercheurs. D’autre part, le contrat étant assez « bien ficelé », il n’y a
pas de problèmes importants détectés lors de l’audit effectué au sein
de la société d’infogérance et auprès de leur personnel détaché. En
résumé, nous présentons quelques points intéressants détectés ainsi
que les recommandations associées qui suivent.
Points forts :
– redéploiement réussi des informaticiens d’un centre de mainframe à
la nouvelle structure d’un centre de serveurs ;
– contrat d’infogérance « bien ficelé » avec une société externe,
cependant ce contrat ne met pas l’accent sur la sécurité d’accès aux
informations du centre.
Points faibles :
– il manque une charte ou un document définissant la politique
d’utilisation des ressources et la définition des responsabilités des
différents acteurs ;
– le contrôle de sécurité d’accès aux informations et aux intrusions
n’est pas bien contractualisé.
Ainsi, à titre d’illustration, nous proposons deux paragraphes extraits

du rapport d’audit :
« Il est à noter que la migration progressive d’un centre

classique de mainframe vers un centre serveurs de type
d’infogérance a été réussi. Les informaticiens ont été bien

redéployés grâce à une formation planifiée et à la
redéfinition des rôles. Les personnes parties en retraite ne
sont plus remplacées, mais une compensation budgétaire
est affectée à une sous-traitance externe ».
Pour ce qui concerne les points faibles, nous avons émis les deux
recommandations suivantes.
Première recommandation :
« Etant un centre de recherche pluridisciplinaire et
internationale, il serait souhaitable d’établir une charte ou
un document définissant la politique d’utilisation des
ressources et la définition des responsabilités des
différents acteurs ».
Le document pouvant être établi suivant le plan suivant :

– objectif de la charte ;
– contexte général ;
– utilisateurs et partenaires ;
– droit du centre Business Intelligence Centre (BIC) :
1) le BIC possède le droit de spécifier les systèmes, les logiciels et
les bases de données utilisés par le centre de recherche ;
2) il peut refuser toute introduction des systèmes ou nouvelles
technologies non cohérents avec la mission du centre de recherche,
sa politique ou à l’encontre des droits nationaux et européens ;
3) il peut prendre des mesures administratives, disciplinaires et/ou
d’actions légales pour assurer sa politique et sa mission ainsi que le
respect des droits nationaux et européens.
– droit des utilisateurs ;
– responsabilités des utilisateurs.
Deuxième recommandation :
« Le contrôle de sécurité d’accès aux informations et aux

intrusions n’est pas bien contractualisé. Il serait
souhaitable de réactualiser le contrat d’infogérance en

ajoutant les éléments détaillés ci-dessous ».
La société chargée de l’infogérance devrait mettre en œuvre tous ses

moyens pour :
– prévenir et détecter les intrusions illicites ;
– filtre les accès via le Web ;
– posséder les outils d’évaluation des vulnérabilités d’Internet, des
systèmes scanners et des wireless scanners ;
– posséder les outils d’évaluation et de filtrage des spams concernant
les mails ;
– renforcer la protection des desktops et des serveurs ;
– pratiquer le concept de security management en fournissant des
modules de surveillance et de reporting.
D’autre part, tous ces préalables n’auront aucun sens s’il n’existe pas
un bon encadrement et une bonne équipe. En particulier, la
compétence de l’équipe interne doit être prouvée pour gérer la sous-
traitance et les contrats externes. Enfin, il importe de savoir que
souvent le processus d’audit d’un centre BIC ou de serveurs nous
amène parfois à pratiquer l’audit des ressources humaines de
l’entreprise, qui sera développé dans la section suivante.
5.4. Audit des ressources humaines
Des différents types d’audits, un des plus délicats est sans conteste
l’audit des ressources humaines. En effet, il met en lumière
l’inadéquation de la personne vis-à-vis de son poste, sa démotivation,
voire parfois son manque de compétence. Dans notre contexte d’audit
informatique, nous ne cernons que les ressources humaines concernant
l’utilisation, l’exploitation et/ou le développement du système
d’information de l’entreprise.
Un auditeur peut fonder son travail sur ces trois hypothèses,

concernant l’inadéquation du couple objectif/moyen :
– une mauvaise connaissance ou utilisation du système contribue à un

rendement médiocre ;
– une mauvaise exploitation du système informatique peut amener à
ralentir la capacité du système ;
– un mauvais développement contribue à une maintenance difficile
ainsi qu’à un probable surcoût.
L’objectivité de l’auditeur est primordiale. Il ne doit pas mettre mal à

l’aise le service audité. Il n’a pas pour rôle de dénigrer, ni de
conseiller de mettre à l’écart ou d’évincer quelqu’un. Ce n’est pas sa
mission. Il relate les faits et les disfonctionnements constatés « les
faits, rien que les faits ».
Il est à remarquer que dans bon nombre de PME et PMI, ce sont

souvent des anciens qui « informatisent » leurs services. De l’état
« utilisateur », ils sont passés à « informaticiens maison » de par leur
connaissance approfondie de la structure et de l’histoire de
l’entreprise. Bien entendu, leur savoir est parfois complété par
quelques stages de formation rapide.
Un autre cas, à l’inverse, concerne les informaticiens professionnels

recrutés ultérieurement (après la mise en place des systèmes), mais
connaissant moins l’entreprise. Cela peut être source de problèmes,
car ils sont souvent boucs émissaires ou cibles de critiques lorsqu’il
existe des problèmes informatiques ou lorsque les délais de réponse du
système d’information sont trop longs... La formation et l’information
sont les deux piliers de la motivation du personnel en général et des
informaticiens en particulier.
Le personnel technique ne peut se contenter de quelques séminaires, il

doit avoir une formation adéquate et étalée dans le temps en fonction
de l’évolution du matériel et des logiciels. Sans cela, sa compétence
deviendra vite obsolète et la motivation s’estompera peu à peu. La
formation doit être complétée par l’existence dans l’entreprise d’une
documentation ainsi que de revues à jour.
Avant de détailler quelques-uns des rôles de l’auditeur, il importe de

savoir quels sont les éléments déclenchant une demande éventuelle
d’un audit de ressources humaines par la Direction générale ou par

une direction de production.
En effet, il n’y a pas de fumée sans feu comme dit un vieil adage. La
liste ci-dessous, loin d’être exhaustive, est néanmoins significative des
éléments souvent cités par la Direction :
– retard des traitements des commandes via l’informatique ;
– états des listings non conformes aux états de stock ;
– états des listings non conformes aux documents comptables (qui
peuvent être générés par un autre logiciel) ;
– discordance entre les informaticiens et les utilisateurs ;
– turn over important du personnel informatique.
Des constats précédents, on peut déduire les rôles de l’auditeur :

– vérifier l’existence d’un contrat de travail adéquat pour le personnel
du service informatique ;
– vérifier l’existence d’organigrammes clairs et précis ainsi que la
définition des fonctions (ou en anglais terms of references) ;
– vérifier l’existence des clauses relatives à la non concurrence, à la
fidélité, à la déontologie et au secret professionnel ;
– vérifier l’existence d’un plan de formation adéquat ;
– vérifier l’adéquation des formations demandées vis-à-vis des
besoins concernant l’utilisation du système informatique et/ou des
logiciels ;
– vérifier ou sonder la motivation du personnel.
En outre, il peut aussi :

– s’assurer de la compétence des agents (en relation avec le plan
individuel de formation et les appréciations annuelles) ;
– s’assurer que le turn-over n’est pas excessif, qu’il existe une
politique du personnel correcte (politique de recrutement, de carrière,
de rémunération) ;
– s’assurer de l’existence d’une politique d’horaires cohérente
(équipes en exploitation normale ou en brigade, pour une
permanence...) ;
– s’assurer que seules les personnes concernées et autorisées sont dans

la salle machine ou des serveurs ;
– s’assurer que les précautions concernant le personnel en sous-
traitance ou temporaire sont prises.
De par sa nature, la Direction technique/informatique émet plutôt
des requêtes pour des missions plus spécifiques et plus techniques.
De ce fait, les audits tels que ceux concernant la qualité de service,
l’utilisation des logiciels ou l’exploitation des centres serveurs,
sont les plus fréquemment demandés. Soucieuse de son personnel
technique, cette Direction pourrait aussi demander l’audit de ses
ressources humaines. Ainsi l’auditeur devrait s’assurer de la
compétence de ces personnes aussi bien à travers leurs manières
d’exploiter les systèmes et/ou logiciels qu’à travers leur formation
continue. Cependant, il n’en demeure pas moins qu’un turn-over
anormal démontre souvent l’inadéquation de l’affection des
ressources et/ou l’existence d’un malaise au sein d’une unité
informatique.
FOIRE AUX QUESTIONS
(CHAPITRE 5)
Question 1 : en ce qui concerne un logiciel ERP de l’entreprise, est-il

suffisant que deux personnes connaissent bien le produit ?
Réponse : le nombre de deux personnes est certes nécessaire, mais

pas tout à fait suffisant, un troisième utilisateur maîtrisant un logiciel
de type « Entreprise Resources Planning » serait préférable. En effet,
on observe souvent dans les PME et PMI que la deuxième personne
connaissant le produit tombe parfois malade alors que c’est cette
personne qui remplace le titulaire pendant sa période de vacances.
Question 2 : concernant un même logiciel, pourquoi n’a t’on pas un

même rendement d’une PME à une autre (lenteur ou exploitation non
optimale) ?
Réponse : le rendement d’un produit mis en exploitation dépend de

plusieurs facteurs, dont les deux principaux sont les suivants :
Le premier facteur qu’un auditeur peut prendre en considération est le

facteur des ressources humaines : les utilisateurs sont-ils bien formés
au produit ? Y a-t’il une deuxième personne, voire une troisième
connaissant bien toutes les fonctionnalités du produit ?
Le deuxième facteur concerne le processus de paramétrage des

logiciels ainsi que du système d’exploitation-hôte. A titre d’exemple,
nous avons découvert lors d’un audit, la lenteur d’un ordinateur
exploitant un produit logiciel à cause de ses processeurs
16 bits : en effet le produit logiciel était développé avec une machine
32 bits pour des ordinateurs de dernier cri...
Question 3 : quels sont les problèmes les plus couramment rencontrés

avec les produits PGI (Progiciel de Gestion Intégré) ?
Réponse : les problèmes souvent dévoilés par l’audit concernent

souvent l’utilisation non optimale du produit, l’incohérence des
données (due à des processus de saisies différents) et un bouclage
insatisfaisant avec les données comptables de l’entreprise.
Question 4 : quels sont les documents importants à vérifier si

l’entreprise sous-traite ou fait appel à une infogérance externe ?
Réponse : il s’agit sans conteste du cahier des charges et du contrat ou

le ToR, « Term of Reference ».
Question 5 : quel type de budget important doit-on vérifier dans un

cas d’externalisation ?
Réponse : le budget de sous-traitance est à vérifier avec soin. Mais,

c’est surtout l’accroissement de ce type de budget qui doit être vérifié
et justifié ! Par exemple, un accroissement de ce budget conséquent
(disons entre 50 et 100 %) d’une année sur l’autre est source de
problème. L’auditeur doit alors en chercher les raisons.
CHAPITRE 6
Problème de sécurité
et audits associés
Evidence…
Aucune sécurité ne peut se concevoir sans un plan. La sécurité est
proportionnelle au temps et au budget investi pour établir et exercer ce dernier.
L’auteur
L’information est une des ressources primordiales et constitue une

partie vitale du patrimoine de l’entreprise. Le problème de sécurité
devient donc de plus en plus crucial : sécurité pour la protection des
patrimoines et des biens de l’entreprise, pour la protection contre les
vols, les sabotages et l’espionnage industriel.
Dans de nombreuses PMI ou PME, le poste de sécurité est inexistant

parfois, soit par ignorance, soit par manque de crédit. Plus grave,
certains dirigeants pensent que « les vols ou accidents n’arrivent
qu’aux autres » jusqu’au jour où ils s’aperçoivent que leurs efforts de
recherche ou d’investissement pendant des années sont anéantis en
quelques heures, voire quelques minutes. Il existe bien souvent des
remboursements par les assurances de ces biens volés ou détériorés mais
qu’en est-il des préjudices moraux ou des avances technologiques
perdues et irrécupérables ?
En effet de nombreuses de PMI ou PME travaillent dans des domaines

très pointus pour la défense et la sécurité nationale (parfois même,
elles ont des postes de surveillance institués par le ministère de la
Défense) ou parfois réalisent plus de 70 % de leur chiffre d’affaires à
l’exportation grâce à leur savoir-faire et leur leadership dans une
technologie de pointe.
N’est-il pas étonnant de savoir qu’en ce début même du XXIe siècle, il

existe des unités de recherche d’un des centres parmi les plus
prestigieux du monde qui ne possèdent pas, ou peu, de système de
protection dans certains calculateurs des chercheurs. Parfois, ces
derniers considèrent que la gentillesse et l’intégrité caractérisent toutes
les personnes qui travaillent dans la recherche scientifique (chercheur
ou non), et que l’espionnage industriel comme le nom l’indique,
n’existe que dans l’industrie et non dans les laboratoires en amont du
processus industriel ou dans les laboratoires de recherche
fondamentale...
Un autre exemple : rien qu’en 2003, bon nombre de sites Internet ont
été attaqués par les programmes malveillants ou des virus de hackers
totalisant une perte évaluée à quelques millions d’euros (perte des
chiffres d’affaires, des fichiers clients ou de crédibilités).
Sans rentrer dans le détail de chaque cas particulier de sécurité des

entreprises, nous nous bornons à étudier les problèmes de sécurité
pouvant avoir de l’impact sur l’information en général et plus
précisément dans les domaines de matériels, de protections de fichiers
et enfin dans celui du réseau, tout en précisant le rôle et les travaux
des auditeurs. Commençons d’abord par le plan de sécurité.
6.1. Plan de sécurité de l’entreprise
Une étude réalisée récemment révèle que plus de 60 % des entreprises

ne possèdent pas de plan de sécurité et /ou dans lesquelles, les
responsables informatiques ne sont pas tout à fait conscients des
risques encourus. De nombreux interviewés considèrent que leur
entreprise a un plan de sécurité dès lors qu’ils possèdent un programme
Problème de sécurité et audits associés 125
d’antivirus ou une sauvegarde hebdomadaire. Or ceci est nécessaire,

mais non suffisant ! En fait, qu’entend t’on par risque ? Le risque peut
se définir comme un « hasard » que l’on court d’une perte ou d’un
dommage. Peut être aussi considéré comme risque, un évènement
potentiel engendrant des pertes ou dommages. L’occurrence d’un
risque résulte de l’application d’une menace sur une vulnérabilité
(voir ce mot dans le lexique). Les menaces pourront être d’origines
physiques ou logiques (destruction des fichiers, virus…).
L’étude de 2002 révélée en fin 2003 par la CLUSIF démontre que

64 % des entreprises n’ont toujours pas défini de politique de sécurité
des systèmes d’information pour contrer les risques. Bon nombre
d’entreprises n’intègrent pas la continuité de service invoquant les
raisons suivantes :
– une politique SSI (sécurité des systèmes d’information) est ou
semble onéreuse à mettre en place ;
– les entreprises ont du « retard à l’allumage » ;
– elles sont en phase de sensibilisation, la démarche s’amorce ;
– la réaction de la politique est en cours.
Et concernant les virus, un rapport annuel établi par GMV Conseil

pour le compte de la CLUSIF dévoile une forte augmentation des
infections des virus : de 14,8 % en 2001, le taux d’infection enregistré
s’élève à 26,3 % en 2002. Les derniers chiffres pour 2004 montrent un
taux supérieur à 30 %.
De notre point de vue, une entreprise peut « se vanter » de posséder un

plan de sécurité informatique, seulement si elle assimile et pratique
une méthode reconnue de type MARION-AP (méthode d’analyse des
risques informatiques et d’optimisation par niveau au stade de l’avant-
projet) par exemple, ou encore la méthode MEHARI, méthode
d’harmonisation des risques (issue de la précédente, mais moins
complexe). Et seulement aussi, si elle sensibilise ses utilisateurs de
systèmes informatiques et ses employés en général par une formation
et une prise de conscience collective.
Cette méthode MARION possède un certain nombre de concepts,

un guide de principes et des documents spécifiques ou fiches
méthodologiques.
C’est une démarche globale comprenant au moins six étapes, de

l’analyse des risques à l’étape d’orientation et avant-projet en passant
par les étapes d’expression du risque maximum admissible, à l’analyse
des moyens de sécurité, à l’évaluation des contraintes et aux choix des
moyens.
La phase de choix des moyens est primordiale, en effet c’est à ce

moment que l’on détermine le budget concernant la protection et la
prévention nécessaire.
A défaut d’appliquer une méthode commercialisée connue, nous

proposons un processus de mise en œuvre d’un plan de sécurité en
cinq étapes pour les entreprises (voir annexe 2).
En l’absence d’un plan de sécurité informatique (coûteux et lourd à

mettre en œuvre surtout pour un environnement de micro-ordinateurs)
et pour parer aux urgences, nous préconisons aussi une check-list
simplifiée de contrôle et de protection des matériels, de la
documentation et de la sécurité (voir ci-après). Ces éléments
pourraient être intégrés dans un plan d’action de la politique de
sécurité de l’entreprise.
6.1.1. Plan de sécurité concernant la protection des matériels (surtout les

serveurs) et de la salle de stockage correspondante
Cette partie ne concerne que des services possédant des mainframes

et/ou des mini-ordinateurs (cas des très grandes PME et PMI ou
grande entreprise et administrations) et exploitant encore dans des
salles classiques, des gros disk packs ou des streamers. Par exemple
concernant un centre exploitant des ordinateurs pour le contrôle des
flux aériens ou des centres de gestions des ordinateurs de type
bancaire.
Accès de la salle : le lieu de stockage des ordinateurs ne doit pas être

un lieu de passage non contrôlé (contrôle par badge, par code
d’accès), il faut éviter à tout prix le va-et-vient des personnes
étrangères au service.
Protection de la salle contenant les serveurs de l’entreprise :

– pour l’isolation calorifique et l’air conditionné, il faut surveiller de
près les contrats d’assistance et de maintenance ;
– pour l’alimentation électrique, tester et détecter les coupures, les
fréquences de micro-coupures et garder le voltage constant en
incorporant des stabilisateurs de courant, des onduleurs, et/ou
l’alimentation secourue ;
– protection contre l’incendie : vérifier l’existence des extincteurs, des
armoires ignifugées, des consignes de sécurité et d’urgence, dans la
mesure du possible, il faut préconiser un autre lieu de stockage des
fichiers sauvegardés ;
– problème de pollution et de poussière : par exemple, parmi une
trentaine de facteurs de sécurité, la méthode MARION préconise une
petite liste de questions concernant le micro dépoussiérage complet
des sites informatiques, de leurs infrastructures (faux-planchers, faux-
plafonds et plénum) et du matériel dans la salle d’exploitation.
6.1.2. Sécurité concernant les fichiers
Il faut éviter la perte ou la destruction accidentelle des fichiers. De ce

fait, il est toujours opportun de procéder à des duplications de ces
derniers. Ces copies seront conservées en lieu sûr (armoire ignifugée,
fermée à clé, et située dans un autre lieu de stockage).
L’ensemble des duplications comprend une version de fichiers fils,

pères et grands-pères suivant un planning de sauvegarde.
Pour les fichiers programmes, prévoir des procédures de reprise et

éventuellement des mots d’accès.
Enfin concernant la protection des informations :

– pour la diffusion des résultats ou listings, seules les personnes
intéressées doivent en être les destinataires ;
– protection des données et des programmes vis-à-vis des personnes
étrangères au service (surtout pour les disquettes et CD-ROM ou DVD
dans l’environnement micro-ordinateur) ;
– protection des postes de saisie des informations (surtout
environnement des mini et des gros ordinateurs) : seules les personnes
compétentes et autorisées ont le droit d’utiliser ces consoles
(vérification par des badges et des mots de passe).
Une check-list de sécurité minimum étant fournie, développons

quelques cas spécifiques et déterminons les rôles des auditeurs
informatiques.
6.2. Sécurité dans le domaine des matériels et de la documentation
6.2.1. Sécurité des matériels
Dans le domaine de sécurité des matériels, on néglige souvent le lieu

où sont stockés et exploités les matériels ainsi que la documentation
technique servant à exploiter les machines et les mots de passe. Ceci
est primordial en ce qui concerne les serveurs.
A l’instar de tout atelier de production, un atelier, une salle

informatique micro-ordinateur en pool, un centre de calcul ou une
salle d’exploitation doivent être protégés en accès et les contrôles
doivent être systématiques.
Les mots de passe ne doivent être connus que par le personnel

exploitant et par un groupe restreint (la hiérarchie directe par
exemple). Ces passwords doivent être changés avec une fréquence
déterminée et les consignes de sécurité doivent être respectées
scrupuleusement.
En dehors des éléments précédents, un centre de calcul (cas pour les

gros ordinateurs, les mainframe ou mini-ordinateurs) doit posséder un
système d’insonorisation, de climatisation et d’éclairage adéquat sans

compter l’ergonomie des postes de travail : des terminaux dédiés aux
applications ou des terminaux intelligents, des micro-ordinateurs.
Cependant nous conseillons que ces derniers soient démunis des
possibilités des périphériques pouvant lire des supports externes
(lecteurs des disquettes des CD-ROM, des clés USB) afin d’éviter les
apports des virus ou des programmes malsains. Pour éviter les
problèmes décrits ci-dessus, lors d’un audit informatique, les tâches de
l’auditeur sont les suivantes :
– contrôler l’existence des moyens de protection d’accès dans la salle
machine. Ceci est encore plus crucial avec les micro-ordinateurs dans
la majorité des bureaux d’une entreprise. On ne pense pas au problème
de sécurité, jusqu’au jour où l’on s’aperçoit de la disparition de son
outil de travail ou de la détérioration des fichiers ou du disque dur ;
– contrôler l’existence des normes de sécurité et dans le cas où ces
derniers existeraient (établis par le service de sécurité de l’entreprise),
son rôle se bornera à vérifier l’application de ses normes ;
– contrôler le respect des normes de ventilation et de climatisation
préconisées par les constructeurs ou le respect des normes d’ingénierie
établies par le bureau des méthodes informatiques.
De ce fait, il doit vérifier les feuilles de relevés, le cahier ou le journal

de bord des systèmes. Des outils tels que l’hydro-enregistreur, les
thermomètres ou les documents des préconisations de sécurité et de
protection des constructeurs doivent être consultés.
6.2.2. La sécurité de la documentation
Aucune personne ne peut se vanter de connaître à fond un système

d’exploitation et de faire fonctionner les machines (surtout en mini ou
en mainframe). De ce fait beaucoup de documentation s’éparpille
souvent d’une manière inconsidérée, or la conservation en lieu sûr des
documents techniques est primordiale : dossiers vitaux pour
l’exploitation, pour la compréhension des finalités des systèmes
informatiques et des applications (appelées souvent aussi des
applicatifs).
Documents certes utiles pour la bonne marche des systèmes, mais

aussi nécessaires pour les éventuels saboteurs, pirates ou personnes
malveillantes, d’où la nécessité absolue de l’existence et du stockage
dans un lieu sûr de ces éléments vitaux.
Prenons un exemple : lors d’une enquête, l’équipe d’audit a constaté

que les documents ou dossiers techniques sont éparpillés et non
indexés par application ou par fonctionnalité. Une recommandation
comme la suivante peut alors être formulée dans un rapport.
Recommandation :
« Dans le but d’assurer la confidentialité de certaines

informations, il conviendrait de veiller à limiter la
diffusion de certains documents. Par ailleurs, la
documentation nécessaire à l’exploitation des calculateurs
doit être groupée, indexée et rangée dans des armoires
munies d’un dispositif de fermeture renforcée pendant les
périodes de non-utilisation. »
6.3. La sécurité des supports d’informations (les contenants)
En dehors des disques fixes ou disk packs dont dispose un centre de

calcul comme supports importants des gros ordinateurs ou mini-
ordinateurs, il existe aussi des bandes magnétiques, des cartouches ou
cardridges, des cassettes et des disques souples pour micro-
ordinateurs. La majorité des exploitants prennent des précautions pour
les disques ou disk packs (habitude et préconisations des constructeurs,
concernant les manipulations et les températures ambiantes...), mais
concernant des supports sur bandes (utilisées de plus en plus rarement
comme support d’archivage et de sauvegarde des informations) ou
cartouches, on est beaucoup moins vigilant.
Concernant ces derniers supports, nous n’émettons pas de conseils

compte tenu de leur progressive disparition. Néanmoins, les règles ou
précautions suivantes concernant les disk packs, les disques CD-ROM
ou DVD doivent être suivies.
Précautions pour ces supports
– Eviter les contacts directs sur la surface magnétique.

– Remettre toujours les supports magnétiques dans leurs étuis ou
pochette après utilisation.
– Eviter l’exposition des supports magnétiques au soleil ou auprès de
sources de chaleur.
– Ne jamais « agrafer » un papier au-dessus avec un trombone.
– La température de la salle de stockage doit être surveillée et le
rangement des supports doit être fait dans les boîtes, verticalement, à
l’abri de la poussière.
– Enfin, notons que les CD-ROM ou disquettes s’usent (donnée d’un
constructeur : après 50 millions de rotations), des copies ou des
duplications sont donc nécessaires.
En tant qu’auditeur, nous devons vérifier et soulever les non-

conformités vis-à-vis des éléments précédents et émettre au besoin les
conseils associés.
6.4. Sécurité dans le domaine des fichiers (les contenus, les données et
programmes)
La notion de sauvegarde et de protection des fichiers doit entrer dans

les mœurs. Chacun de nous n’a t-il pas un jour effacé ou détruit un
fichier par inadvertance nécessitant de ce fait de refaire une saisie
partielle ou totale entraînant des pertes financières et de temps ?
L’auditeur informatique doit être capable de prévoir et détecter en

amont ce type d’oubli ou de négligence (exemple : s’assurer de
l’existence des mots de passe et de la prohibition des commandes de
destruction…) et de conseiller la pratique des procédures de
sauvegarde.
Il doit, en outre, proposer le nombre de versions à archiver, la

fréquence de sauvegarde et fixer les périodes de restauration et d’essai
des fichiers sauvegardés. En effet la négligence de ce dernier principe
peut entraîner de mauvaises surprises.
On pourrait s’apercevoir le jour où l’on aura besoin des supports

magnétiques sauvegardés que ces derniers sont illisibles ou incomplets
(manque de certains fichiers importants ou des données tronquées...).
En ce qui concerne les sabotages et les malveillances, les virus

informatiques sont des armes redoutables. Heureusement elles sont
identifiées et reconnues ces dernières années. Ces vers, virus ont pour
but de détruire les fichiers programmes ou les fichiers de données, de
pratiquer le processus de blocage de l’unité centrale ou de la mémoire
centrale paralysant ainsi l’exploitation de l’ordinateur. Pour mieux
connaître les fonctions illicites de ces vers et virus, le lecteur pourra se
référer à l’annexe 3.
En prenant en compte les éléments précédents, on peut en déduire le

rôle que jouera l’auditeur.
Rôle de l’auditeur
Concernant ces problèmes de sécurité des fichiers vis-à-vis des risques

de spoliation et des virus, le rôle des auditeurs informatiques est
primordial. Ces derniers, à chaque mission de ce type, non seulement
font des photos instantanées du service audité, mais doivent aussi
signaler les risques encourus à la direction, donner des moyens ou
conseils de prévention aux utilisateurs ou au personnel du service
audité. Nous ne détaillons pas ici les sécurités concernant les gros
systèmes ou mainframes (des grandes entreprises). En effet nous
supposons que les constructeurs de ces outils proposent des moyens de
protection adéquats et que les entreprises possédant ces systèmes
informatiques disposent d’une équipe d’exploitants plus étoffée
comprenant une cellule de sécurité...
Par conséquent, concernant des PME et PMI, un auditeur doit

fortement insister et conseiller une bonne prévention, une détection et
des remèdes (pour parer contre les problèmes liés aux virus
informatiques).
Ainsi comme moyen de prévention et pour éviter la contamination, il

est souhaitable de ne pas utiliser les programmes de provenance
inconnue et douteuse, par exemple des programmes dits de domaine

public appelés dans le jargon des freeware.
Son rôle consiste aussi à fournir des conseils tels qu’utiliser les
programmes « vaccins » qui détectent les tentatives d’intrusion
(exemple : les produits de Norton, Mc Affee, Virus Detective...) :
– vérifier de temps à autre la taille, la date de création des fichiers et
comparer les fichiers sur disques durs avec les fichiers sauvegardés ;
– faire accepter par les utilisateurs la protection d’accès par mot de
passe et la pratique du changement de ces derniers ;
– faire demander au constructeur spécifique de chaque système les
moyens de sécurité maximale, les programmes de détection de virus et
de tentatives d’accès frauduleuses.
Enfin, en tant qu’auditeur conseil, nous pouvons aussi essayer de

sensibiliser les utilisateurs concernant les moyens de détection et les
remèdes suivants.
6.4.1. Moyens de détection
Il est opportun que les utilisateurs surveillent le ralentissement du

système, la manifestation d’erreurs inexplicables avec un nombre
particulièrement élevé de messages d’erreurs, la dégradation des
performances du système, la diminution des mémoires vives
disponibles, les accès aux périphériques fréquents (pour les micro-
ordinateurs, les voyants du lecteur s’allument de manière trop
fréquente...) ou les disparitions des ressources fichiers (programmes
ou données) et/ou de leurs incohérences.
Enfin, pour les machines connectées au réseau, il faut être sensible

aux lenteurs d’accès aux ressources communes (imprimante laser ou
accès aux serveurs, à Internet...) ou l’observation d’un accroissement
important de la charge réseau.
6.4.2. Remèdes
Les remèdes sont les suivants :

– séparer le système contaminé, le déconnecter du réseau local ;
– détecter les fichiers contaminés et les détruire ;
– utiliser les programmes anti-virus mais surtout utiliser les versions à
jour ;
– restaurer à partir des bons fichiers antérieurement sauvegardés.
D’autre part, pour une meilleure collaboration et coopération, il serait

souhaitable de prévenir toutes les personnes qui possèdent des
systèmes informatiques reliés à nos éléments contaminés. Il importe
aussi de porter plainte et prévenir le CLUSIF (Club de la sécurité
informatique) pour enregistrer ces méfaits et mettre l’information à
disposition de la communauté Web.
Enfin, compte tenu du développement du Web et des réseaux, il est

opportun de détailler les rôles de l’auditeur informatique vis-à-vis de
la sécurité des réseaux et des applications fonctionnant sur le Web :
sujets que nous aborderons plus loin.
6.5. Audit et sécurité dans le domaine du réseau
Le développement des réseaux a pris un essor considérable depuis

25 ans. Au départ, seuls les grands constructeurs pouvaient offrir ces
services avec leurs machines : Bull avec le DSA (Distributed System
Architecture, IBM avec le SNA (System Network Architecture), DEC
avec le DNA (Dec Network Architecture), mais avec le standard et les
normes OSI (Open system interconnexion) de l’ISO (Internationnal
Standard Organisation), les constructeurs de moindre taille,
appliquant ces normes fournissent aussi leurs propres réseaux.
Maintenant, on a davantage de possibilités de choix concernant les
réseaux d’ordinateurs, il convient par contre d’être plus vigilant en
matière de sécurité et de contrôle d’accès.
Dans ce chapitre, nous présentons successivement les normes de

sécurité‚ des réseaux, les outils de contrôle de réseaux puis identifions
les rôles des auditeurs sur les missions d’audit de type réseaux.
6.5.1. Normes de sécurité
De par sa nature, un réseau informatique permet l’interconnexion de

deux ou plusieurs nœuds ou stations de travail. La facilité d’accès ou
d’entrée sur un serveur ou calculateur est réelle et de ce fait, il existe
des risques d’intrusion dans les applications informatiques.
Pour supprimer ces risques inhérents à sa fonction et assurer un

certain niveau de sécurité, le réseau doit posséder des moyens
d’identification, la faculté de restriction d’accès et la possibilité de
transfert d’appel. Le logiciel de gestion doit être conforme aux normes
FIPS (voir ci-dessus).
6.5.1.1. Identification de la ligne

L’identification est la vérification de l’adresse caractéristique du point
d’accès du réseau. Cette identification de la ligne doit être possible à
travers l’ensemble du réseau : à travers le réseau intra X du
demandeur (réseau dans lequel l’utilisateur est demandeur de
connexion au réseau Y), à travers le réseau intra Y du demandé et le
réseau supra X.
L’identification nécessite donc au préalable un plan de numérotage

cohérent au niveau national et des normes standard, des tables
d’adressage et des softs (logiciels) de contrôle. Bon nombre d’outils
existent sur le marché pour gérer et filtrer l’accès au réseau de
l’entreprise.
6.5.1.2. Restriction d’accès

En principe, les restrictions d’accès entraînent des cloisonnements très
restrictifs, par exemple un groupe de terminaux ou de nœuds pour
chaque type d’application. Ces terminaux ne peuvent se connecter aux
autres applications de l’entreprise.
Mais une telle approche conduit à une gestion difficile et ne favorise

pas la souplesse du réseau. Une option plus réaliste consiste à
fractionner le réseau en sous-réseaux : N sous-réseaux de confidentialité
correspondant à N niveaux de confidentialité, ou N sous-réseaux
spécifiques correspondant à des domaines déterminés (exemple :
domaine pour la facturation, pour la gestion technique, pour la
comptabilité...).
Un secteur de confidentialité permet l’accès à toutes les applications

de ce niveau de confidentialité et à toutes les applications des niveaux
de confidentialité inférieure.
Ramené au matériel physique, un terminal habilité à un niveau de

confidentialité donné ne peut accéder qu’aux applications de mêmes
niveaux ou de niveaux inférieurs.
6.5.1.3. Transfert d’appel

Le transfert d’appel doit permettre de transférer la communication
destinée à un serveur ou calculateur vers un autre nœud : serveur ou
calculateur du même réseau ou d’un réseau externe (problème de
panne et de sécurité, notion de chemin non unique ou sécurisé...). Pour
remédier à ce problème, on fait souvent appel au dédoublement des
nœuds, des CCV (commutateurs de circuits virtuels) par exemple. Une
autre méthode consiste à pratiquer la « triangularisation » ou encore
un mélange de ces deux moyens.
La notion de « triangularisation » est souvent mentionnée pour la

sécurisation des nœuds (ordinateurs et/ou terminaux) : entre deux
nœuds A et B importants, il devrait exister un nœud C à partir duquel
on puisse joindre A et B. De ce fait, il y aura toujours un moyen
technique d’atteindre A et B en cas de panne ou de coupure de la
liaison qui relie directement A et B.
L’ensemble des deux schémas suivants permet de bien mettre en

évidence le principe de sécurisation.
Dans le premier, le terminal C (normalement rattaché au centre C),

voulant communiquer avec A1 ou travailler sur l’ordinateur A passe
par la liaison C-B puis B-A. En cas de panne de cette dernière

(coupure ou dérangement), la communication sera interrompue ainsi
que les travaux en cours. Ce problème sera résolu si l’on applique le
principe de triangularisation ou une infrastructure maillée. Par contre
la topologie en structure d’étoile est à déconseiller : car si le noeud
central tombe en panne, toutes les communications seront
interrompues. Dès lors, avec l’application du principe de
triangularisation (cas du second schéma), en cas de dérangement de la
ligne C-B (ou coupure), le terminal C pourra toujours se connecter au
centre A ou communiquer avec les terminaux A1, A2 avec la ligne
directe reliant le centre A et le centre C.
A titre d’exemple, nous donnons les deux schémas simplifiés. Le

premier concerne « l’avant » l’opération de triangularisation (moins
sécurisant) et le second « l’après ».
Terminal B
Terminal A1
Terminal A2
Centre B
Centre A
Terminal A3
Centre C
Terminal C
Figure 6.1. Schéma initial du réseau
Le second montre le principe de triangularisation. Ce schéma montre

la configuration après l’opération de sécurisation. Ainsi chaque nœud
du réseau est relié au moins à deux nœuds voisins, garantissant ainsi
deux chemins de communication.
Terminal B
Terminal A1
Terminal A2
Centre B
Centre A
Terminal A3
Centre C
Terminal C
Figure 6.2. Le principe de triangularisation
6.5.2. Systèmes garantissant la sécurité
Une entreprise ne peut se prévaloir de posséder une sécurité pour son

réseau que si elle possède des systèmes automatiques qui peuvent
proposer les fonctions suivantes :
– assurer la sécurité des échanges effectués sur le réseau X 25 par
exemple (protocole du système Transpac) ou GFA (Groupe fermés
d’abonnés, c’est-à-dire un réseau privé) ;
– gérer et contrôler les accès aux commutateurs ;
– gérer et contrôler les accès aux applications.
Autrement dit, il faudrait tout un ensemble de systèmes qui possède

les deux séries de fonctionnalités ci-dessous :
– fonctions assurées pour la sécurité du réseau :
- contrôle des droits d’accès de tout opérateur ou toute application
engageant un dialogue à travers le réseau ;
- authentification des correspondants (mutuellement) lors de
chaque session ;
- vérification de l’intégrité des messages ;

- journalisation centralisée des transactions des incidents et des
sessions ;
– fonctions pour la gestion des dialogues avec les commutateurs :
- contrôle des droits d’utilisation des commandes ;
- diffusion sélective des éditions vers les terminaux ou les
applications suivant les types ;
- d’édition (message de routine, édition différée...) ;
- journalisation centralisée au niveau de la direction des
commandes, des résultats et des éditions.
6.5.3. Centre de contrôle de réseau
Un centre de contrôle de gestion appelé aussi centre de gestion a pour

fonction d’assurer la supervision des réseaux.
La supervision consiste à administrer le réseau en évaluant sa charge

pour pouvoir suivre son évolution, à surveiller en temps réel l’état du
réseau et de ses éléments (avec une visualisation graphique).
De ce fait, un diagnostic précis pourra être fait sur chaque nœud du

réseau et sur les équipements annexes tels que les modems, les
multiplexeurs...
Certains systèmes peuvent surveiller cinquante à cent nœuds. La

signalisation d’un élément du réseau est instantanée sur le graphique,
la ligne symbolisant la liaison entre les autres éléments change de
couleur (en rouge généralement) ou scintille dès qu’une panne se
matérialise.
Les systèmes de contrôle de réseau proposés sur le marché sont de

plus en plus sophistiqués. Cependant, la majorité des fonctions de
contrôle ne semble pas être une absolue nécessité. La liste suivante
donne un exemple de fonctions utiles.
6.5.3.1. Affectation des unités d’interface de réseau
Le contrôleur doit pouvoir affecter un numéro d’appel à tout nouvel

utilisateur ou l’utilisateur peut lui-même choisir son propre numéro
d’appel. Ce numéro est alors vérifié par le contrôleur, puis inséré dans
une table d’adressage. Un contrôleur doit pouvoir, à la demande d’un
terminal, rechercher un hôte donné qu’il soit sur le même canal, sur un
autre canal ou même sur un réseau local et jouer le rôle d’interface
d’identifications entre les deux systèmes.
6.5.3.2. Contrôle du débit des unités d’interface du réseau

Un contrôleur doit aussi être en mesure de régler indépendamment la
vitesse de transmission de données de chaque unité d’interface en
fonction du volume des transmissions à effectuer.
6.5.3.3. Test, codage et attributions des chemins

On peut utiliser un centre de distribution de clés pour coder certains
parcours entre nœuds. Le système doit être capable de tester les flux et
attribuer un autre chemin ou voie en cas d’engorgement. (Rôle
sophistiqué comme un commutateur téléphonique ou un PABX, un
autocommutateur privé).
6.5.3.4. Configuration
Le contrôle de configuration est sans doute la fonction de réseau la
plus élémentaire. Il est donc conseillé de gérer des tables et des
bibliothèques où seront stockées les adresses des nœuds, les vitesses
de transmission et plus généralement toutes les informations utiles.
Dans un contexte réseau, le rôle de l’auditeur peut être défini comme
suit.
L’auditeur doit :
– vérifier l’existence d’un centre de gestion et de son bon
fonctionnement ;
– vérifier toutes les potentialités du système et signaler les bugs
(erreurs) de logiciel éventuels (à l’aide des journaux ou listings). En
effet, considérant souvent que globalement le module manquant n’est

pas important (surtout si le constructeur le promet dans la version
suivante), l’exploitant ne signale pas à sa hiérarchie mais regrette
seulement le non-fonctionnement de ce module ;
– s’assurer de l’existence de la maintenance adéquate de ce système
(avec les contrats de maintenance et fiches de présence).
6.5.3.5. Entretien du réseau

A l’instar des autres domaines de maintenance classique informatique,
on distingue deux types d’entretien pour les équipements de réseaux :
matériel et logiciels.
6.5.3.6. Entretien du matériel

Dans ce domaine, on sépare encore en deux types : le préventif et le
curatif.
6.5.3.6.1. Entretien préventif périodique

Compte tenu du processus de standardisation croissant, il est
souhaitable de choisir des fournisseurs qui suivent de très près les
normes. L’indépendance éventuelle vis-à-vis du fournisseur est
primordiale. C’est dire la primauté de la prévision et la possibilité de
pouvoir choisir un autre partenaire si l’ancien fournisseur augmente
abusivement les prix, ou si on observe une dégradation de la qualité
du service reçu. C’est la notion de non-dépendance et le choix en
fonction du critère rapport qualité/prix.
Il est à remarquer que dans ce type d’entretien, la tarification pratiquée

par les fournisseurs est plutôt forfaitaire.
6.5.3.6.2. Entretien curatif

L’entretien curatif consiste à réparer des pièces tombées en panne à un
instant donné. Le service de réseaux doit posséder un lot minimum de
pièces et la formation du personnel est à négocier auprès des
constructeurs. D’où la nécessité, pour le responsable de service
d’établir un contrat avec les fournisseurs ou constructeurs. La
tarification comporte le déplacement et les coûts suivant les éléments
échangés. De ce fait, il est intéressant de procéder à des appels à

candidatures et des appels d’offres périodiques.
6.5.3.7. Entretien des logiciels

Il convient de choisir au préalable et dans la mesure du possible des
logiciels standard ou ceux qui respectent les caractéristiques
suivantes :
– l’utilisation des techniques de programmation standard ;
– la conception modulaire ;
– la qualité de la documentation ;
– l’existence de hotlines.
On peut choisir par exemple des softs qui répondent aux normes FIPS
(Federal information processing standard). La maintenance des softs
est à surveiller avec prudence : la diminution du degré de sécurité et la
manifestation de nombreux effets inattendus après de petites
modifications du logiciel sont, hélas, chose courante. En effet un
réseau mis en place relie plusieurs systèmes entre eux et on ne peut
prévoir le comportement ni la réaction totale des éléments
constituants.
La sous-traitance de la maintenance au constructeur est à préconiser si

l’équipe interne de l’entreprise ne possède pas une formation très
pointue ou n’est pas assez étoffée notamment si le logiciel est
commandé et est écrit « sur mesure » par les constructeurs,
fournisseurs ou sociétés de service.
Par contre si l’équipe interne possède une bonne formation, des

documents adéquats et le matériel performant, l’entretien interne
présente de nombreux avantages :
– solution rapide aux problèmes posés ;
– concertation plus facile entre les gestionnaires du réseau et les
utilisateurs ;
– coût d’entretien réduit ;
– disponibilité accrue du réseau pour les contrôles techniques et
fonctionnels.
Pour les problèmes de maintenance, on peut affirmer que lors d’une

enquête le rôle de l’auditeur est le suivant :
– s’assurer de l’existence d’un contrat de maintenance ;
– vérifier le suivi du matériel et le comportement des versions ;
– vérifier que ce système de gestion ne peut être « emprunté » ;
– s’assurer qu’au moins deux personnes de l’équipe savent utiliser à
bon escient le système.
Concernant l’acquisition du centre de contrôle de réseaux ou d’autres

types de matériel, il peut être demandé à l’auditeur de vérifier
pendant, ou a posteriori, le respect des procédures des marchés, des
tests constituant les étapes suivantes (les durées sont données à titre
indicatif) :
– mise en ordre de marche (montage et fonctionnement) ;
– vérification d’aptitude de bon fonctionnement (une semaine après) ;
– vérification de service régulier deux mois après la vérification
d’aptitude) ;
– réception provisoire (une semaine au moins après la phase
précédente) ;
– réception définitive (une semaine après la phase précédente) ;
– exemple de recommandation pour améliorer la maintenance externe.
Recommandation :
« Dans le but d’améliorer la performance de

l’application, il serait souhaitable de surveiller les
contrats de maintenance annuels et de refaire des
négociations éventuelles avec le fournisseur avec les
relevés des incidents et des résolutions des problèmes ».
6.5.4. Surveillance du réseau
Pour la prévention des pannes et le bon fonctionnement du réseau de

l’entreprise, les techniques de surveillance du réseau doivent être
mises en œuvre. Ceci est d’autant plus vrai pour une société possédant
un gros besoin de communication interne et externe, communication
entre gros ordinateurs ou mini-ordinateurs et éventuellement entre

réseaux locaux avec les minis ou mainframes. La surveillance doit être
appliquée‚ aux niveaux des nœuds de transit et de commutation ainsi
qu’à la sortie de chaque élément constituant l’ensemble du « réseau ».
Les principaux éléments à surveiller sont :

– les matériels de transmission :
- comptabiliser les collisions ;
- comptabiliser le nombre de retransmission ;
- vérifier les chemins, les circuits, les voies de transmission ;
– les matériels de commutation :
- vérifier les problèmes d’adressage ;
- contrôler les tables de routage :
- d’un terminal vers l’hôte (vice versa) ;
- de l’hôte vers un autre hôte ;
- des passerelles ;
- des ponts ;
– l’état des équipements :
- l’état physique des lignes (ce service peut être demandé à France
Télécom) ;
- les fréquences d’utilisation et de maintenance ;
- l’existence des normes de sécurité ;
- l’existence des modes opératoires, d’instruction ;
– les sources de retard : vérifier les canaux physiques et logiques
(l’unité d’échange dans un environnement informatique). C’est donc
le processeur d’entrée/sortie ou input/output exécutant des
« programmes » de transfert de communication ainsi que l’affectation
des ports ;
– vérifier les charges :
- voir le nombre d’utilisateurs et de programmes qui s’exécutent ;
- vérifier la compatibilité des protocoles ;
- vérifier le bon fonctionnement des signalisations d’erreur ;
- s’assurer de la cohérence des tailles des paquets d’informations
transmis et reçus, les dates de départ et d’arrivée de ces derniers ;
- vérifier la disponibilité des nœuds (état des unités centrales, de
tables éventuelles ;
- les registres ou mémoires stockant l’état des files d’attente...).
Compte tenu de ces principes de surveillance du réseau, on en déduit

les rôles de l’auditeur :
– s’assurer que l’équipe réseau ou le responsable effectue toutes les
opérations précédentes ;
– s’assurer du bon état des équipements et d’un bon contrat de
maintenance ;
– s’assurer une fréquence normale de vérification et de surveillance
des matériels de réseau ;
– s’assurer de l’existence d’une structure maillée pour le réseau.
Ce rôle est primordial pour une société‚ dite de forte communication

(exemple : vente par correspondance, communication interne importante,
fournisseur d’accès d’Internet...), en effet le réseau en panne paralyse
l’activité totale de l’entreprise, diminue son chiffre d’affaire et ses
marges. Enfin, il lui importe aussi d’évaluer les menaces, risques et les
failles de vulnérabilités1 possibles des systèmes informatiques de
l’entreprise. Il doit aussi s’assurer auprès des responsables la mise en
œuvre des firewalls2, l’utilisation des outils de type SATAN3 et la
protection des backdoors4.
6.6. Audit et sécurité des applications Web
De nos jours, il est inconcevable qu’une entreprise ne soit pas reliée à

la toile : communication, présentation de la société, prise et
chargement (download) des programmes ou des pages via Internet…
Cependant compte tenu du peu d’expérience des programmeurs et de
l’insouciance, bon nombre de codes non sécurisés ont été développés
pouvant exposer l’entreprise aux piratages et aux malveillances.
Récemment en 2004, l’OSWAP (Open Web Application Security), un
groupement de travail de fournisseurs de services de sécurité) a publié
les fameux top ten des dix vulnérabilités des applications Web :
– les requêtes incorrectes (la cohérence des requêtes n’est souvent pas
vérifiée) ;
1. 2. 3. 4. Voir ces définitions dans le lexique.

– les contrôles d’accès non valides (trop d’applications donnent ou

accordent des droits par défaut aux utilisateurs) ;
– gestion de l’authentification et des sessions (le processus
d’authentification aux applications Web est souvent négligé ainsi que
la fermeture des sessions sous le contrôle seul de l’utilisateur) ;
– le cross site scripting (bon nombre de failles d’une application Web
permettent l’exécution des codes malveillants) ;
– dépassement des tampons mémoire (manque de contrôle au niveau
des chaînes de caractères ; ceci entraîne les attaques de buffer
overflows : écrasement des pointeurs et d’adresses) ;
– problème d’injections (l’application Web est servie comme une
passerelle par le hacker ou pirates dont le but est d’attaquer le
serveur) ;
– messages d’erreurs (les messages renvoyés contiennent trop
d’informations sensibles ;
– chiffrement (utilisation des chiffrements de type maison et trop
d’informations sensibles ne sont même pas chiffrées) ;
– déni de service (les applications donnent droit aux utilisateurs
d’accéder à trop de ressources) ;
– administration non sécurisée (l’administration des systèmes est
accessible via le Web).
Pour conclure, le président de OSWAP prévoit, en 2004, une

recrudescence du déni de service compte tenu du peu de mesures
préventives implémentées dans les entreprises. D’autre part,
confrontés dans un centre où il existe ces types de problèmes, nos
expériences permettent de déduire les rôles qui suivent.
– Vérifier la cohérence des requêtes.

– Vérifier l’existence d’une application pour l’authentification.
– Vérifier l’existence des filtrages en input : l’existence des
programmes de contrôle et/ou Firewall et l’inexistence des possibilités
de gestion des systèmes via le Web ou en mode remote.
– S’assurer que les informations données en output n’étaient pas des

informations sensibles.
– S’assurer que le chiffrement est utilisé pour les informations
sensibles en output.
– Vérifier l’existence d’une classification des utilisateurs ainsi que de
leurs droits correspondants.
Il importe de savoir que ces types de vérification devraient être

effectués par l’administrateur ou l’ingénieur système. Pour illustrer un
audit dans ce type de contexte et spécialement d’un centre serveur,
nous présentons le cas suivant faisant suite à des attaques.
6.7. Audit d’un centre à la suite de plusieurs attaques
Ce cas illustre les démarches effectuées lors d’une mission dans un

centre de serveurs concernant les pannes générées par des attaques,
nous donnons un exemple d’audit concernant les problèmes et des
recommandations pour la protection de ce centre.
En voici le contexte : un centre de serveur de Web d’une société a été

récemment mis en place (depuis un an et demi). Son principal rôle est
de fournir des informations concernant les articles vendus par la
société (une grande entreprise, nommée Belcar, négoce d’accessoires
de tuning de personnalisation pour des automobiles) via la toile Web
aux clients potentiels et aux commerciaux en déplacement (souhaitant
montrer aux clients les articles et les prix pratiqués).
Le serveur est géré par un jeune administrateur système qui attribue

les privilèges en fonction de la catégorie d’utilisateur (liste définie par
la Direction qui a donné priorité aux commerciaux).
Depuis sa création, le serveur a subi deux pannes graves dues aux

attaques. Ainsi deux dépannages ont été sollicités par la société. Cette
dernière a payé un ingénieur système consultant externe pour radier
les pannes et restaurer le serveur.
Soucieuce de l’avenir de ce centre, la Direction a commandité un audit

externe indépendant (fait par notre équipe de consultants) pour
exécuter une mission informatique de ce centre.
En effet, d’une part, compte tenu des audits cycliques programmés,

l’équipe d’audit interne n’a pu accepter la mission et, d’autre part, un
défaut de compétence spécifique en est aussi la cause. Nous
développons les éléments correspondants à chaque phase du processus
d’audit et présenterons ensuite quelques recommandations extraites du
rapport final d’audit.
La durée globale de la mission est de dix jours ouvrables répartis de la

manière suivante.
6.7.1. Phase de pré-audit et de planification (0,5 jour)
Malgré notre charge de travail, mais compte tenu de l’intérêt de ce

projet, nous avons accepté cette mission intéressante et valorisante. En
effet l’objectif est de diagnostiquer, d’analyser et de trouver les failles
(facilitant ces attaques génératrices de pannes) et d’émettre les
recommandations pertinentes. Par expérience, pour ce genre de
mission, il n’existe pas réellement de référentiel, car elle est très
technique et exige plutôt un savoir-faire et une pratique en la matière.
Compte tenu du background technique de nos auditeurs et de la

demande de mission qui est bien ciblée, cette phase de pré-audit et de
planification n’occupe que 5 % du temps total réparti pour l’ensemble
de la mission.
Une première planification permet d’identifier les tâches suivantes :

– vérifier le processus de documentation de l’équipe de support ;
– analyser les données disponibles relatives à ces pannes et les deux
rapports d’incidents ;
– vérifier le comportement des logiciels ;
– simuler les attaques pour récolter les éléments ;
– identifier les points faibles et les failles du système.
6.7.2. Phase de l’enquête préliminaire (2 jours)
Cette phase est de même nature que pour les audits classiques, à
savoir qu’elle est répartie en quatre sous-phases qui sont les
suivantes :
– l’analyse du sujet et définition de l’objectif (pour cette mission, le
sujet ainsi que l’objectif sont sans ambiguïté) ;
– la préparation (la documentation, l’élaboration des questionnaires...) ;
– la prise de contact des personnes du service audité (équipe support
et utilisateurs) ;
– l’enquête préliminaire sur le terrain (sur les lieux du serveur).
6.7.3. Phase de vérification rapide (2,5 jours)
Appelée aussi phase de vérification de survol, les bases de nos travaux

s’appuient sur :
– les premiers entretiens avec l’administrateur, quelques commerciaux
et autres utilisateurs ;
– l’existence et l’examen rapide de la documentation, des procédures
et des travaux ou notations des deux dépannages externes. Le premier
définit une panne de déni de service et le second, un problème de
buffer overflow ;
– les vérifications rapides de conformité.
L’objectif de cette phase est double : d’une part, on devrait analyser et

porter un jugement (à travers les interviews recueillies) pour vérifier si
les symptômes correspondent bien aux dires des rapports
d’intervention et d’autre part, les auditeurs devraient détecter les
points forts et les points faibles pressentis.
Ainsi, à la fin de cette phase, les auditeurs devraient dresser un tableau

des points forts (PF) et points faibles (pf) apparents, dégagés d’après
certaines preuves ou d’après l’intime conviction et que l’on s’impose
professionnellement d’effectuer des vérifications plus approfondies
plus tard.
Pour cette mission, nous avons détecté quelques points forts :

– l’existence d’une documentation complète pour la gestion du
serveur ;
– l’existence d’une procédure de secours. Bon taux de fonctionnement
du serveur (couverture du service rendu).
Mais aussi quelques points faibles :

– la documentation, quoique existante, ne semble pas à jour
(concernant l’application qui a posé problème) ;
– pas de procédure technique concernant les attaques ;
– le niveau de compétence de l’équipe support (l’administrateur et son
adjoint) semble disparate et insuffisante.
6.7.4. Phase de vérification ou réalisation de l’audit proprement dit

(3,5 jours)
Cette phase permet aux auditeurs de vérifier tous les éléments

minutieusement et en détail afin de pouvoir apporter les preuves des
points forts et de points faibles détectés ou pressentis des phases
précédentes. Avec l’accord de la Direction, nous avons provoqué des
pannes hors période d’exploitation.
Ainsi lors de cette phase, nous avons pu confirmer les deux problèmes
pressentis :
– panne due au déni de services (DoS, voir lexique) ;
– panne due aux problèmes de buffers overflow à cause d’une
application nouvellement installée.
Les vulnérabilités permettant des attaques de buffer overflow, sont

inhérentes aux codes et sont dues généralement aux manques de
vérification des bornes des variables. Ce problème est donc dû au
module d’une application récemment installée.
En effet, on a détecté que le champ qui demande l’utilisateur connecté

à distance via le Web n’a pas de limite préconisée. Dans notre
mission, nous vérifions aussi les divers documents mis à disposition
de chaque membre de l’équipe et, bien sûr, l’on vérifie avec le service
développeur et avec les fournisseurs des logiciels, les dernières
versions de la documentation.
Puis grâce aux fiches d’incidents recensées, on vérifie le phénomène

d’immobilisation du serveur et la raison. La durée totale
d’immobilisation du serveur est de trois jours ouvrables et la perte
financière est évaluée (malgré le rattrapage) à 12 000 euros de chiffre
d’affaires.
Quant aux niveaux de compétences disparates des membres de

l’équipe, on vérifie les dossiers de formation, leurs backgrounds,
l’administrateur, par exemple, n’avait pas de formation complémentaire
en software, il était issu d’une formation hardware et électronique. Ainsi
par ces méthodes, on obtiendra des preuves tangibles et indéniables. A
la fin de cette phase, les auditeurs sont en mesure de préparer le pré-
rapport avec des éléments complets issus de toutes les phases
antérieures.
6.7.5. Phase de restitution et du rapport (1,5 jour)
Dans notre mission, cette phase est en fait concrètement décomposée

en deux sous-phases appelées : « phase de rapport » et « phase de
finalisation ».
6.7.5.1. Phase de rapport

L’écriture du rapport final (la version 0 que l’on envoie aux services
audités) ne peut se concevoir qu’après l’exécution de toutes les phases
précédentes.
Néanmoins, l’élaboration du plan, de la structure et des grands pavés

du pré-rapport (appelé le projet ou draft) peut être débuté beaucoup
plus en amont et complété au fur et à mesure du déroulement des
phases.
6.7.5.2. Phase de finalisation de la mission

La présentation du projet et l’examen des incohérences ou points
faibles, l’obtention d’un accord avec les audités, puis l’élaboration
définitive des recommandations (l’application de ces dernières sera
contrôlée ultérieurement grâce aux fiches de suivi) :
– l’établissement définitif des fiches de suivi et l’envoi de la lettre de
clôture de la mission et la facturation.
Pour cette mission d’audit du centre de serveur, nous avons émis

quatre fiches de suivi5 :
– la première concerne la mise à jour des systèmes et la nécessité de
« patcher » avec les éléments fournis par les constructeurs ;
– la deuxième est en rapport avec la formation du personnel de
support ; une formation plus technique s’avère nécessaire pour parer à
tous les problèmes de piratages et des hackers ;
– la troisième concerne l’utilisation des outils de prévention tels que
CyberCop ou ISS Internet Scanner (il est nécessaire se connaître par la
suite si ce service applique la recommandation émise et utilise des
outils pour la prévention) ;
– la dernière concerne le suivi de les actions de re-paramétrage des
routeurs, le filtrage des accès au serveur et la révision des privilèges
des utilisateurs.
CyberCop6 est un produit commercial qui revendique la réalisation de

plus que 40 attaques de déni de service, incluant l’attaque Land,
l’attaque Ping, et autres variétés d’attaques. Toutes les potentialités
d’attaques disponibles de l’outil peuvent être exécutées simultanément
ou individuellement. L’outil présente une description de l’attaque
ainsi qu’une suggestion des contre-mesures.
5. Il est à remarquer que ces fiches de suivi serviront comme input pour une
prochaine mission du même genre pour les auditeurs internes.
6. Pour plus d’informations concernant les outils et les techniques, veuillez
consulter l’ouvrage : La sécurité sur Internet du même auteur aux éditions
Hermès Sciences et Lavoisier.
ISS Internet Scanner : comme pour le cas de CyberCop, ISS Internet

Scanner scanne les hôtes pour déterminer si ces derniers sont
susceptibles ou favorables aux attaques de DoS. La version 6.2.1
contient 128 attaques, des éléments en commun avec CyberCop. ISS,
Internet Scanner apparemment donne plus d’informations sur les
attaques que CyberCop et il fournit un meilleur travail quant à la
catégorisation des attaques par cible, par exemple pour les serveurs de
DNS, les serveurs FTP, les Firewalls, etc. Néanmoins, ISS Internet
Scanner fournit lui aussi des descriptions et des contre-mesures pour
les divers types d’attaques de déni de service. Enfin, de cet audit et du
rapport qui en a résulté, on retient les recommandations qui suivent.
6.7.5.3. Recommandation générale

Les attaques de déni de service peuvent causer des dégâts importants
et la protection est difficile. Par conséquent, il est urgent, pour les
compagnies ou organisations possédant des systèmes critiques et
sensibles connectés à Internet, de scanner et de vérifier leur réseau et
systèmes. Elles devront être conscientes des risques et devraient
minimiser les opportunités des attaques réussies des dénis de services.
6.7.6. Recommandations plus techniques
Première recommandation : « afin de minimiser les attaques de type

DoS ou DDoS (Distributed DoS), il serait souhaitable de :
– concevoir les applications plus robustes (ou tester à fond avant la
mise en place) ;
– de limiter les bandes passantes ;
– de garder à jour les systèmes d’exploitation avec des patchs des
constructeurs ;
– exécuter juste le nombre nécessaires de services et le trafic
nécessaire ;
– filtrer les adresses IP.
Seconde recommandation : « afin d’éviter les problèmes de buffer

overflow, il est souhaitable d’éliminer :
– tous les logiciels qui sont vulnérables ;
– tous les ports et services correspondants ;

– d’appliquer le patch du fournisseur et installer la dernière version du
logiciel ».
D’autre part, avant l’installation d’un nouveau logiciel, il serait

souhaitable de déterminer sa sensibilité et tester sa vulnérabilité de
buffer overflow.
Troisième recommandation : « afin de se prémunir contre les attaques

externes, il serait souhaitable de re-paramétrer les routeurs, de filtrer
les accès au serveur et de revoir les privilèges des utilisateurs ».
Avant de clôturer ce chapitre, nous résumons le bilan de cette opération

au niveau financier :
Pertes financières du CA générées par ces deux problèmes :
12 000 euros (4000 x 3 jours)
Appel à des compétences externe pour les dépannages urgents :
2 600 euros
Prestation pour un audit externe : 4 000 euros
Le montant global s’élève à 18 600 euros HT sans compter une perte

possible de l’image de l’entreprise et la nécessité de prévoir une
formation plus pointue pour l’équipe de support interne.
Enfin, il est à noter que les outils présentés précédemment ne seront

pas totalement efficaces pour lutter et démotiver les pirates ou hackers
s’il n’existe pas des moyens juridiques forts et dissuasifs que nous
développons au chapitre suivant.
6.8. Sécurité et droit de l’informatique
Les problèmes de sécurité de l’information, de la propriété et de la

protection des logiciels, de la confidentialité, les relations contractuelles
ont posé un certain nombre de difficultés avec les textes anciens dont
l’interprétation et l’adaptation ne sont pas évidentes. Il y a quelques
années encore aux Etats-Unis, la législation en vigueur pour régler les
problèmes liés à la confidentialité et les vols de temps de machines
était celle sur les « sévices et injures envers autrui » et non la loi sur
les actes de vol. Actuellement le droit américain a rétabli ce vide
juridique.
De par le monde, de nombreux fichiers nominatifs sont déviés de leur

objectif de départ. On assiste aussi à des cessions ou des ventes de ces
fichiers. En France, par la volonté du législateur, une Commission
Nationale Informatique et Liberté (CNIL) a été créée pour lutter
contre les abus et actuellement bon nombre de projets de lois vont être
concrétisés.
Cette commission comporte un certain nombre de sous-commissions

spécialisées dans des affaires différentes. Il a fallu attendre jusqu’à
1985 (l’informatique existe depuis plus de 25 ans), pour qu’une loi
protège les auteurs de logiciels et spécialement ceux de la micro-
informatique.
La loi du 3 juillet 1985 définit la notion de contrefaçon et prescrit les

sanctions applicables aux contrefacteurs. A cette époque, la lutte
contre le piratage des logiciels est déterminée par les sept articles de
cette loi.
Actuellement les projets de loi plus adéquats concernant ce genre

d’abus et les problèmes de hacking vont être mis en œuvre (voir aussi
le chapitre 13 du livre Sécurité Internet et Management Anti-piratage,
référencée en annexe). Mais la première loi qui réprime directement la
fraude informatique est nommée « Loi Godfrain ». Elle date du 5
janvier 1988.
En février 2004, un projet de loi a été adopté par le Sénat dont le but
est d’adapter la loi Informatique et Liberté et enterre la distinction
entre le public et le privé. Dorénavant, seules les données à caractères
sensibles feront l’objet d’une déclaration à la CNIL.
Revenons sur ces anciennes lois existantes et les amendes qui étaient
exprimées en francs, il faut tenir compte du taux actuel d’un euro qui
équivaut à 6,559 francs.
L’article 47 de la loi du 3 juillet 1985 dispose :
« Par dérogation au 2 de l’article 41 de la loi 57-298 du

11 mars 1957 précitée, toute reproduction autre que
l’établissement d’une copie de sauvegarde par l’utilisateur
ainsi que toute utilisation d’un logiciel non expressément
autorisée par l’auteur ou ses ayants droit est passible des
sanctions prévues par ladite loi ».
Désormais la recopie ou la reproduction d’un logiciel constitue un

délit de contrefaçon. La seule exception concerne la reproduction
d’une copie de sauvegarde pour l’usage personnel de celui à qui la
licence est accordée. L’utilisation en dehors des conditions prévues
par la licence constitue aussi un délit de contrefaçon (une utilisation
qui n’a pas été autorisée par l’auteur ou ses ayants droit). La mise en
œuvre des poursuites se fait par la saisie des contrefaçons, puis d’une
assignation délivrée à l’intéressé soit devant le tribunal civil, soit
devant le tribunal correctionnel.
La saisie peut être descriptive ou réelle. Dans le premier cas, l’huissier ou

le commissaire ont seulement à saisir deux exemplaires comme preuve.
Dans le second cas, ils saisissent la totalité des exemplaires trouvés,
néanmoins l’autorisation préalable d’un juge saisi par voie de requête est
nécessaire. Au sens de la loi du 3 juillet 1985, les sanctions applicables au
délit sont les mêmes que celles prévues par la loi du 11 mars 1957, qui
donnent droit au plaignant de faire condamner le contrefacteur tant devant
le tribunal civil que le tribunal correctionnel, en effet la contrefaçon en
matière de droit d’auteur constitue un délit pénal.
Les articles 425, 429 et 323 du Code pénal :

Article 425 : toute édition d’écrits, de composition musicale, de
dessin, de peinture ou de toute autre production, imprimée ou gravée
en entier ou en partie, au mépris des lois et règlements relatifs à la
propriété des auteurs, est une contrefaçon, et toute contrefaçon est un
délit. La contrefaçon, sur le territoire français, est punie d’un
emprisonnement de trois mois à deux ans et d’une amende de 6 000
francs ou de l’une de ces deux peines seulement.
Article 426 : est également un délit de contrefaçon toute reproduction,

de représentation ou diffusion par quelque moyen que ce soit d’une
œuvre de l’esprit en violation des droits de l’auteur, tels qu’ils sont
définis et réglementés par la loi.
Article 323 : concernant l’accès frauduleux dans tout ou partie d’un

système de traitement automatisé de données, il est puni d’un an de
prison et de 15 245 € d’amende. S’il en résulte une altération, soit des
données contenues (suppression ou modification), soit du fonctionnement
même du système, les peines prévues sont de deux ans de prison et de
30 490 € d’après l’article 323-1 du code pénal.
Quant à l’atteinte volontaire au fonctionnement d’un système de

traitement automatisé de données, c’est-à-dire le fait de le fausser ou
l’entraver, est puni de trois ans de prison et de 45 735 € d’amende
d’après l’article 323-2 du Code pénal. Le fait d’introduire
frauduleusement de nouvelles données ou de supprimer ou modifier des
données stockées est puni de trois ans de prison et de 45 735 €
d’amende d’après l’article 323-3 du Code pénal. De plus, on peut
demander l’application du droit civil permettant ainsi de rechercher la
responsabilité de l’individu à l’origine de l’infraction afin qu’il puisse
être condamné à des dommages et intérêts pour le préjudice subi par la
victime en terme de perte de chiffres d’affaires, des commandes, de
notoriété...
Enfin, il convient de remarquer que la lutte contre les cybercriminels

ne pourrait se faire sans la collaboration des techniciens et du
législateur. L’auditeur informatique apporte son savoir pour détecter
les points faibles et failles, les techniques de parade apportées par les
ingénieurs compétents sont nécessaires pour détecter, contrer et piéger
les pirates, mais les lois sont indispensables pour les punir et
démotiver ces futurs crackers.
Ce n’est qu’avec une collaboration étroite de ces acteurs que l’on peut
espérer venir à bout de ces criminels en col blanc dans un proche
futur... Dans un contexte juridique, il importe d’identifier les rôles
suivants de l’auditeur.
Rôle de l’auditeur :
– s’assurer d’une bonne politique logiciel de l’entreprise ;
– s’assurer qu’il n’existe ni piratages ni contrefaçons pratiqués au sein
de l’entreprise ;
– s’assurer du respect des lois en vigueur ;
– s’assurer de la déclaration auprès de la CNIL des données sensibles ;
– vérifier l’existence d’une protection efficace des systèmes (via les
réseaux et réseaux périphériques7) contre les pirates.
L’information est une des ressources primordiales de l’entreprise
et constitue une partie vitale de son patrimoine. Le problème de
sécurité devient donc de plus en plus crucial. Les menaces et les
risques encourus par l’entreprise sont multiformes et variés. De ce
fait, un plan de sécurité est à conseiller pour toute entreprise
soucieuse de son patrimoine informationnel et de ses systèmes
informatiques. De plus, avec le foisonnement des applications sur
le Web et de l’interopérabilité des systèmes et des réseaux, la
surveillance et la prévention devraient être des tâches importantes.
Lors des audits de sécurité, si les auditeurs repèrent un manque
d’outils de détection d’intrusion ou de surveillance, il est de leur
devoir de recommander l’utilisation de ces outils et de signaler les
risques encourus à la Direction. Cependant, ces outils ne seront
pas totalement efficaces pour démotiver les pirates ou malfaiteurs
s’il n’existe pas des moyens juridiques forts et dissuasifs. De ce fait
les auditeurs devraient aussi connaître un minimum d’éléments
juridiques et quelques lois importantes. Ces derniers ont été
évoqués à la dernière section de ce chapitre.
7. Voir définition dans le lexique.

FOIRE AUX QUESTIONS
(CHAPITRE 6)
Question 1 : concernant une mission de sécurité et/ou de détection

d’accès frauduleux aux systèmes, quels sont les documents qu’un
auditeur informatique devrait prendre en considération ?
Réponse : une procédure de contrôle périodique du responsable

informatique sur les matériels et logiciels est nécessaire pour assurer
la sécurité du ou des systèmes. Une équipe d’audit chargée d’une
mission de sécurité et/ou de détection d’accès frauduleux aux
systèmes doit disposer et considérer les documents suivants
concernant la détection d’accès frauduleux :
– cahier de bord des systèmes ;
– dossier de saisie ;
– plan de câblage des terminaux ou interfaces ;
– cahier d’exploitation ;
– procédure de dépannage.
Concernant la sécurité du fonctionnement du système : en plus des

documents antérieurs, il convient aussi de regarder le planning des
révisions des éléments du centre de traitement, les contrats de
maintenance et d’assurances.
Question 2 : concernant la sécurité de la documentation : pour

assurer la sécurité d’exploitation, la continuité du service ou la
détection des fraudes par les tiers, les auditeurs sont amenés à
s’assurer de l’existence et du stockage dans un lieu sûr des dossiers
vitaux pour l’exploitation et la compréhension des fonctionnalités et
finalités des systèmes informatiques et des applications.
Lors d’une enquête, l’équipe d’audit a constaté que des dossiers sont
éparpillés et non indexés sur les fonctionnalités, quel type de
recommandation devrait faire un auditeur ?
Réponse : une recommandation doit être de bon sens, l’auditeur

devrait préconiser un classement approprié en fonction des
fonctionnalités et des modules d’exploitation. En plus, les guides
d’utilisateurs doivent être facilement repérables et utilisables.
Question 3 : concernant la sécurité des supports d’information :

combien d’exemplaires de sauvegarde doit-on préconiser ?
Réponse : il serait préférable d’en sauvegarder au moins deux

versions, ainsi on aura le fils, le père et le grand-père (jargon
informatique). D’autre part, il serait judicieux de vérifier aussi la
fréquence des sauvegardes. Un compromis doit être trouvé. En effet,
une fréquence trop élevée et non justifiée génère un grand nombre de
supports physiques.
Question 4 : concernant la sécurité d’accès aux fichiers : en théorie

l’accès aux fichiers des applications ne pourrait s’effectuer que par le
biais d’une commande ou d’un programme autorisé. Néanmoins, il
peut arriver lors d’un dépannage que les informations présentes dans
la mémoire centrale soient modifiées. Ces cas sont plus fréquents lors
d’une intervention pour l’exploitation : modification de certaines
priorités des tâches, mise à niveau du logiciel, modification des tables
systèmes...
a) En tant qu’auditeur, que devez vous contrôler ?
b) Quelles sont les personnes à interviewer et les documents à vérifier ?
c) Dans un environnement de système de gestion de base de données,

des informations stockées dans les fichiers classiques, comme celles
qui sont intégrées dans une base de données, doivent être vérifiées par
les auditeurs qui s’assurent de leur authenticité, intégrité, pérennité,
confidentialité ainsi que de leur disponibilité. Comment définissez-
vous le terme « dictionnaire de données » et quels sont les éléments à
vérifier ?
Réponse :
a) pour la mise à jour des fichiers des applications, l’auditeur doit
vérifier qu’en aucun cas les utilisateurs non informaticiens ne puissent
accéder aux fichiers et effectuer les lancements des travaux non
tolérés dans le cahier d’exploitation ou les documents de base (dossier
d’analyse, procédures de traitement...).
Pour les mises à jour des fichiers systèmes par des informaticiens :
– s’assurer que ces manœuvres sont consignées sur un cahier de bord,
que l’ingénieur et/ou le responsable sont au courant et que tous ces
travaux ont reçu leur approbation ;
– recenser les statistiques de ces travaux. Un nombre élevé de ces
opérations démontre la non-fiabilité du système et l’inadéquation aux
besoins d’exploitation : un audit spécifique devrait se faire dans ce
cas.
b) Les personnes à interviewer sont les ingénieurs systèmes, le
responsable informatique (ou système), l’administrateur de réseaux et
les exploitants.
c) Définition du dictionnaire de données : c’est l’inventaire de toutes
les données de l’application. Ces dernières sont classées en trois
types :
– les données calculées résultantes des règles de calcul ;
– les données paramètres ou constantes isolées ;
– les données de la base : les données de diverses natures ou
d’origines évolutives ou stables que l’on désire conserver dans la base.
Question 5 : concernant la sécurité d’accès aux systèmes hébergeant

des applications web. Lors d’une vérification, confronté à l’existence
du non-contrôle des droits des utilisateurs accédant aux systèmes (où

se trouvent des applications Web) ainsi que la possibilité
d’administrer via le Web, en tant qu’auditeur informatique, pouvez
vous donner un exemple de recommandation dans un rapport ?
Réponse : voici un exemple de recommandation possible. La sécurité

d’accès aux systèmes via le Web montre certaines failles et
vulnérabilités. Il importe donc de la verrouiller en enlevant la
possibilité d’administration externe à travers le Web et de renforcer
les contrôles des utilisateurs ainsi que de leurs droits correspondants ».
Question 6 : concernant les attaques de déni de service via le Web,

quels seront les conseils des auditeurs ?
Réponse : les auditeurs pourront conseiller une politique de

renforcement de la surveillance associée à l’utilisation des outils tels
que CyberCop et ISS Interner Scanner. En effet, la pratique d’un
scanning peut amener à détecter les tentatives d’accès frauduleuses
des malfaiteurs.
CHAPITRE 7
Plans types
et exemples de procédures
« Quand on est jeune, on échafaude un programme de travail dont on s’imagine

qu’il durera toute la vie et résistera à n’importe quel cataclysme ».
Graham Greene, écrivain anglais (1904-1991).
Moralité...
« Les principes et structures des programmes de travail sont parfois les mêmes,
mais ces derniers doivent être spécifiques et établis en fonction de chaque objectif ».
Henri Ly
Ce chapitre se distingue des autres par sa structure. Pouvant être

considéré comme un guide, il est plutôt pratique, pragmatique, et
opérationnel. En effet, il présente et propose des plans types facilement
modifiables et utilisables pour les besoins d’un service d’audit afin
d’établir un programme de travail ou pour l’élaboration des procédures.
Ces éléments pourront être utilisés directement par les auditeurs.
7.1. Plan type d’un programme de travail
Le plan type proposé est un programme de travail évoqué dans le

chapitre 1 et concernant une mission informatique (focalisant sur le
traitement et les outputs). Cette mission est commanditée par la
direction (d’un opérateur des télécommunications en quête des
éléments qui ont entraîné des problèmes de facturation. Le titre de la
mission s’intitule : « Limitation des factures erronées ». Cette mission

a été demandée suite à des plaintes des clients (anomalies des factures,
factures élevées…).
Exemple de plan proposé pour un programme de travail
A. Rappel des objectifs
A.1. Modalité de traitement des états d’anomalies et des factures

anormales
A.2. Conception des états d’anomalies
A.3. Impact des factures anormales sur les réclamations
B. Etude des procédures – Mémorandum
B.1. Organisation
B.2. Traitement de l’information concourant à la facturation
B.3. Les contrôles de la facturation :
– les états de sortie ;
– contrôle au centre de traitement (au niveau de l’exploitation
informatique) ;
– contrôle dans les agences ou filiales pour les grandes entreprises.
B.4. Les réclamations :
– au centre de traitement ;
– aux agences.
C. Principaux points forts et points faibles
– Points forts et points faibles du centre de traitement.

– Points forts et points faibles des agences.
D. Vérifications
– Contrôle de la facturation des gros clients.

– Contrôle de la facturation des clients ordinaires.
– Contrôle des autres prestations facturées.
– Contrôle des anomalies des états.
Plans types et exemples de procédures 165
Les annexes éventuelles
– L’organigramme du service et les schémas détaillés de la circulation

des documents.
7.2. Plan type d’un rapport
Comme cela est signalé auparavant, le lecteur trouvera un exemple de

plan type issu d’une mission d’audit d’un centre de serveur. La
mission s’intitule : « Audit informatique d’un centre de serveurs et
détection des risques ».
Plan proposé
– Introduction (avec rappel de l’ordre de mission).

– Contexte d’exploitation du centre des serveurs.
– Diagnostic et recommandations.
A. Système physique : architecture générale des serveurs et interfaces
– Les points forts.
– Les points faibles.
– Recommandations.
B. Systèmes logiciels et les problèmes des ports
– Les points forts et les points faibles concernant les logiciels utilisés.
– Les points forts et les points faibles concernant les affectations des
ports.
C. Les autres types de risques
– Recommandations.
– Conclusion : dans cette partie, les auditeurs devraient préconiser
l’application stricte des recommandations compte tenu des risques
encourus, ainsi qu’une mise à niveau rapide des procédures.
7.3. Exemples de procédures d’audit
Les deux procédures d’audit suivantes sont données à titre d’exemple.

Elles sont fournies à titre pédagogique, cependant, les lecteurs
pourront puiser des éléments ou s’en inspirer afin d’établir des
procédures ad hoc pour leurs entreprises.
Le premier exemple concerne une procédure pouvant être utilisée pour

deux types d’audit : l’audit qualité et l’audit informatique.
En effet, la plupart des entreprises redéploient les auditeurs qualités ou

fournissent des informations et formations adéquates à destination des
auditeurs internes pour effectuer les audits informatiques.
En cas de ressources insuffisantes, l’entreprise pourrait aussi faire appel

à de la sous-traitance.
Concernant le deuxième exemple, relatif à l’audit qualité pour la

qualification d’un produit logiciel, un plan est fourni, ce dernier sera
suivi de la procédure en français.
Une version anglaise complète sera aussi présentée en annexe (voir

annexe 4). En effet, compte tenu du fait que les entreprises sont de plus
en plus internationales, un modèle en anglais pourrait donc être utile
aux lecteurs.
7.3.1. Exemple de procédure d’audit interne
7.3.1.1. Introduction
La SFLP (Société des fournitures des logiciels et progiciels) a adopté
une démarche qualité ISO 9001 : 2000. En accord avec cette démarche
et avec celle de la politique qualité de l’entreprise, la Direction
générale, en collaboration avec le comité de pilotage, a adopté cette
procédure proposée par la Direction qualité et lancé les audits internes
DESCRIPTION DU DOCUMENT
Titre :
Procédure d’audit interne
Edition : V 1.1
Codification Interne :
SFLP.DIR.Qual.PRO.03
Edition-date : 04/04/2005
Résumé : l’objectif de cette procédure proposée par la Direction Qualité et approuvée par
la direction générale et le Comité de pilotage est de fournir la démarche et le déroulement
des audits internes au sein de la SFLP (Société des fournitures des logiciels et progiciels).
Les démarches d’audit qualité et d’audit informatique sont similaires, seuls le référentiel
et le choix du profil d’auditeur diffèrent. La procédure est donc applicable pour la
conduite des deux types d’audit.
Mot clés : audit - procédure – auditeur- qualité
Author(s) : Nom : Tel : Direction : service qualité
Fichier électronique
Système Système des utilisateurs Logiciel

Serveur central XX PC sous Windows Word
Approbation du document
Edition Date Nom, fonction et signature Direction/service
Henri Dupont/ / auditeur et auteur du

V 1.1 04/04/2004 DQ*
document
V 1.1 04/04/2004 Jean Eden / Directeur qualité DQ*

V 1.1 04/04/2004 Samuel Tonne / Directeur général DG*
Changements et versions successives
Edition Date Raison des changements Pages affectées
V 0.1 04/02/2005 Création Tous
V 1.1 04/04/2005 Document final, ajout du diagramme Page 4
Note : * DQ : Direction qualité, DG : Direction générale
Tableau 7.1. Description du document de procédure d’audit interne

NOTA BENE.– Il importe d’établir un sommaire si le document est
volumineux.
7.3.1.2. Objectif de la procédure

L’objectif de cette procédure proposée par la Direction qualité et
approuvé par la Direction générale et le Comité de pilotage est de fournir
la démarche et le déroulement des audits internes au sein de la SFST.
La démarche d’audit qualité et d’audit informatique sont similaires,

seuls le référentiel et le choix du profil d’auditeur diffèrent.
Pour les premiers types de mission, les auditeurs du système qualité

sont nécessaires, tandis que celui des auditeurs spécialisés dans les
systèmes informatiques et d’information est exigible pour les audits
informatiques.
Néanmoins, en cas de besoin et compte tenu des spécificités, l’audit

interne peut être sous-traité.
7.3.1.3. Définition et terminologie

A détailler et compléter en fonction des définitions adoptées par
l’entreprise :
Audit : processus systématique, indépendant et
documenté pour obtenir des preuves ou évidences afin
d’évaluer objectivement si les critères d’audit ont été
remplis.
Audit informatique : activité de contrôle du management

informatique pour apprécier l’utilisation, l’exécution,
l’efficacité et l’adéquation des éléments constitutifs du
système informatique ou du système d’information avec
l’objectif et l’orientation de l’entreprise.
Audit interne : appelé parfois audit de premier parti, il est

effectué au nom de l’organisation par le personnel interne
ou par la sous-traitance.
Critère d’audit : ce sont des critères politiques,

procéduraux et des exigences utilisés comme références.
Ils sont définis au préalable avant le déroulement des
missions. Ce sont donc des éléments objectifs pour
l’évaluation.
Plan d’audit ou de travail : plan proposé par les auditeurs

à la DQ et aux audités en vue de faciliter la mission et les
services audités.
7.3.1.4. Documents de référence

A ajouter si nécessaire, en fonction des entreprises et les références ad
hoc en fonction des processus.
Référentiels pour la qualité
– Normes génériques de la série ISO 9000.
– Manuel qualité de SFST.
– Plan d’assurance qualité de SFST.
– ISO 10011-1 :1990, ligne directrice pour l’audit des systèmes
qualité – partie 1 : audit.
qualité – partie 2 : critère de qualification pour les auditeurs.
qualité – partie 3 : gestion des programme d’audit.
– Référentiels pour l’informatique.
– ISO 9000-3 de même principe que la série ISO 9000 pour la qualité,
cette norme est adaptée aux spécificités de conception, de réalisation,
de livraison et de maintenance des produits logiciels.
– ISO/CEI 9126 pour l’évaluation des produits logiciels.
– ISO/CEI 12119 pour les progiciels - exigences qualité et essais.
– ISO/CEI 12207 pour les processus du cycle de vie.
7.3.1.5. Les documents spécifiques en relation avec cette procédure

– Projet de planification.
– Lettre de mission.
– Planning des audits.

– Rapport d’audit.
Les acteurs concernés
– Coordinateur qualité.
– Directeur qualité.
– Auditeurs.
– Comité de pilotage.
NOTE.– Le comité de pilotage qualité et celui de l’informatique sont

souvent distincts, cependant selon la compétence du personnel, un seul
type de comité de pilotage pourrait se concevoir.
Diagramme de la procédure
Le diagramme de la page suivante permet de détailler :

– les acteurs concernés ;
– leurs actions, leurs responsabilités, leurs participations et la
circulation des documents.
7.3.2. Exemple de procédure d’audit qualité pour la qualification d’un

produit logiciel
Le plan d’une autre procédure est présenté ci-dessous. Ce plan

concerne une procédure d’audit qualité pour la qualification
(certification interne) des produits logiciels.
Nous utilisons le terme certification uniquement s’il s’agit d’un audit

de type tierce partie.
La procédure complète est fournie à la page suivante. La version

anglaise sera présentée en annexe 4.
Service audité Auditeur(s) Coordinateur /DQ Comité pilotage
Préparation /proposition
pour le management Participe à la
prépa. du
planning.
Developer un planning
d’audit
Revue commune
Proposition du Planning
Non
Approbation ?
oui Le premier projet

sera présenté au
comité.
Envoi aux services Si nécessaire les
concernés amendements
pourraient se faire
via le système des
Prépa. lettre de mission et
courriers
Envoi aux services concernés
électroniques.
Analyse du système
Réception qualité ou
du Choix des auditeurs et
planning et fourniture du référentiel
de la lettre Validation du Plan
de mission Etablissement d’un
plan d’audit et
soumission au comité
Plan d’audit
validé?
Plan de No
travail ou
d’audit
Envoi du Plan d’audit
Oui
Cette phase inclut:

- la réunion d’ouverture;
Conduite de l’audit - l’ audit;
- la réunion de clôture
avec validation avec les
audités
ainsi que les diverses
Envoi du rapport final Enregistrement du versions avant l’accord
(après approbation des rapport final du rapport.
audités)
Rapport Rapport
d’audit daudit
Mettre en place un Plan Rapport
d’action et informer le d’audit et
comité plan
d’actions
Suivi et revue
Processus Suivant
Figure 7.1. Diagramme relatif à la procédure

Procédure d’audit qualité pour la qualification d’un produit logiciel

Le lecteur trouvera ci-dessous un plan type proposé et la procédure
complète dans les pages suivantes.
A. Principes généraux
A.1. Objectif de la procédure
A.1.1. Champ d’application
A.1.2. Bénéfices attendus
A.2. Référentiels utilisés
B. Conditions d’application
B.1. Exigences de la procédure d’audit qualité
B.2. Les pré-requis
B.2.1. Les pré-requis techniques
B.2.2. Les pré-requis qualité
B.2.3. Les pré-requis administratifs
C. Les résultats et documents du processus d’audit
C.1. Le rapport
C.2. Les recommandations
D. Les différentes phases de l’audit qualité
D.1. Le diagramme
D.2. La procédure étape par étape
D.3. La validité
D.4. Modulation
D.4.1. Expiration d’un produit déjà qualifié
D.4.2. Similitude avec un produit déjà qualifié
Procédure d’audit qualité

(pour un produit de référence ou de test)
DG/Qual-Proc-0002
Edition Numéro V1.00
Date d’édition 23 oct, 2004
Statut Proposition
Catégorie Guide
Tableau 7.2. Réduction de la première page de couverture

IDENTIFICATION DU DOCUMENT
DESCRIPTION DU DOCUMENT
Titre du document
PROCEDURE D’AUDIT QUALITE
NUMERO DE REFERENCE DU DELIVRABLE
REFERENCE - INDEX EDITION : V1.00

DG/QUAL-PROC-002 DATE 23 octobre 2004
D’EDITION:
Résumé
Cette procédure d’audit sera appliquée lors d’une demande de qualification pour un
produit de référence (logiciel) ou un outil de test. Elle détermine le mode de travail, les
conditions et les pré-requis. Elle pourrait aussi être utilisée pour un processus
d’acceptation (de recette) d’un produit de référence ou un outil de test.
Mots clés
audit Qualification Approbation Produit de
référence
Produit de test Outil de test
CONTACT Henri Ly TEL : ext : DIVISION : Qualité

PERSON : 35 12
TYPE DE DOCUMENT ET STATUT

STATUS CATEGORY CLASSIFICATION
Document de Procédure pour la tâche Diffusion pour le
travail public
Projet Tache spécifique ; Guide ;
Version définitive ; Sous tâche Restriction
Version mise à
jour
SAUVEGARDE ELECTRONIQUE
INTERNAL REFERENCE NOM :

SYSTEME HÔTE MEDIA SOFTWARE(S)
ARCHIVE via le réseau Type : Domaine MS Office Word 6.0
PRODUCTION
Identification du Média MS Windows
Tableau 7.3. Procédure complète

Le tableau suivant identifie les autorités qui ont approuvé ce présent

document.
AUTORITE NOM ET SIGNATURE DATE
Responsable du H. Ly 23 octobre 2004

processus de
qualification
Responsable d’unité J.L. Borland 23 octobre 2004
Tableau 7.4. Identification des autorités
Enregistrement des changements du document
Le tableau suivant enregistre l’historique complet des éditions

successives du document.
SECTIONS
EDITION DATE RAISON DU CHANGEMENT PAGES
MODIFIEES
V0.00 01-07-02 Document initial (projet) Toutes les
sections
V1.00 23-10-03 Mise à jour du document Toutes les
sections
Tableau 7.5. Historique des différentes éditions du document
Sommaire
Identification du document
Enregistrement des changements
Plan et développement (voir ci-après)
A. Principes généraux
A.1. Les objectifs généraux de la procédure

Tous les aspects, composants et éléments du système qualité seront
examinés. L’objectif principal est de vérifier l’efficacité du système
qualité du service audité.
L’audit qualité et la qualification technique par une tierce partie, sont les
deux composants pour l’approbation et l’obtention du certificat de
qualification.
A.1.1. Champ d’application
La procédure d’audit est associée à la procédure de qualification. Elles
seront appliquées pour un produit de référence ou un outil de test et
utilisées pour tester la conformité des autres systèmes vis-à-vis d’une
norme ou d’un référentiel donné.
Cette procédure détermine le mode de travail, ainsi que les conditions et

les pré-requis associés. Elle peut être utilisée dans un contexte
d’acceptation ou de recette.
A.1.2. Bénéfices attendus
L’application de cette procédure est considérée comme une méthode
incluant une approche qualité permettant :
– l’établissement d’une confiance sur ces produits ;
– l’amélioration de la qualité de ces produits logiciels et des services ;
– la diminution des coûts globaux de ces produits ;
– l’amélioration du niveau d’exigence requis ;
– la promotion d’une harmonisation progressive des produits utilisés.
Tout cela contribue à une excellence technique.
A.1.2.1. Référentiel utilisé

Tous les termes ou expression utilisés se trouvent dans les documents
ci-dessous (les documents du référentiel étant en anglais, nous avons
gardé leur titre d’origine) :
– Study Report Qualification and Certification Issues

(ref. : PLC.ET1.ST006.000-REP-000) ;
– Qualification Procedure (ref..:Policy document 1 Edition: 1.08) ;
– ISO 9000 : Quality management systems - Fundamentals and
vocabulary (edition date 20/12/2000) ;
– ISO 9001 : Quality management Systems - Requirements (edition
date 20/12/2000) ;
– ISO 9004 : Quality management Systems - Guidelines for performance
improvement (edition date 20/12/2000) ;
– ISO 19011 : Guidelines for quality and/or environmental management
systems auditing (edition date 01/10/2002).
B. Conditions d’application de la procédure
Avant de soumettre un produit ou un système à la qualification et à

l’audit qualité, on ne doit pas perdre de vue le ratio bénéfice vis-à-vis du
coût. Cependant l’audit qualité devrait automatiquement être appliquée
quand on demande une qualification du produit.
B.1. Exigence de la procédure d’audit qualité
Un service ou une entreprise devrait être audité dès lors qu’une
demande de qualification est demandée pour un produit. L’application
doit être exigée pour les cas suivants :
– si le produit doit être utilisé comme un produit de référence ou
comme un outil de test dans le cadre d’un processus de certification
(le produit sera utilisé pour certifier un système) ;
– si le produit doit être utilisé par plusieurs services ou Etats
membres ;
– si le produit doit être utilisé dans plusieurs régions des Etats
membres ;
– si le produit doit jouer un rôle important au sein des centres
régionaux et/ou pour un système central ;
– s’il doit jouer un rôle essentiel concernant le contrôle qualité (un
outil de test par exemple) pour vérifier un système central ou des
systèmes régionaux.
B.2. Pré-requis
B.2.1. Pré-requis techniques
Le produit doit être vérifié et validé par le développeur et/ou par le

fournisseur. Le produit à qualifier pourrait déjà être opérationnel dans
un site particulier.
En parallèle, la qualification technique (incluant la révision des

documents techniques, la vérification des codes…) pourrait être déjà
enclenchée par une tierce partie : un laboratoire accrédité.
B.2.2. Pré-requis qualité
Le demandeur devrait obtenir au préalable soit :
– un label ou une attestation (de la part d’une autorité reconnue) ;
– un certificat ISO 9001 : 2000 concernant le périmètre incluant la
conception et la fabrication du produit ;
– une preuve issue d’un audit interne planifié concernant
l’organisation et la méthodologie. Dans ce dernier cas, notre audit doit
être renforcé.
B.2.3. Pré-requis administratifs
L’exigence administrative est la même que celle issue de la procédure
de qualification, c’est-à-dire que la demande (de qualification) doit être
adressée au chef d’unité de qualification en temps opportun dans la
période prescrite, au moins deux mois avant la période d’évaluation et
au moins quatre mois avant la date espérée pour le jury. D’autre part, le
demandeur devrait désigner un correspondent de qualification (le
responsable du projet du produit ou le responsable qualité) et allouer un
budget pour les dépenses adéquates.
C. Résultat du processus d’audit qualité
C.1. Rapport d’audit qualité
Le principal document résultant de l’audit est le rapport, établi par

l’équipe d’audit. Un plan type est donné en annexe. Ce rapport sera
fourni aux membres du jury et au service audité. L’équipe d’audit
fournira pour chaque demande de qualification de produit, un rapport

spécifique. L’équipe d’audit présentera aussi les éléments détectés
durant la réunion du jury de qualification.
C.2. Recommandations
Si nécessaire, notre équipe d’audit peut émettre des recommandations ou
des suggestions. Tous les éléments, donnant un impact négatif au
système qualité, doivent être corrigés, suivis et tenus en compte par le
service demandeur en adéquation avec les processus correctifs
appropriés (plan d’actions).
D. Phases définies par la procédure d’audit
La procédure d’audit définit un processus cinq étapes.
D.1. Diagramme du processus
Etape 1 :
initialisation Demande
Formation de l’équipe d’audit
Etape 2 : Détermination du référentiel

préparation
Préparation et planning
Ordonnancement
Etape 3 :
audit
Plan de
travail
Réunion de lancement
Révision de la
documentation
Interwiews
Synthèse
Evaluation
Etape 4 :
technique
phase de restitution Ecriture du rapport (laboratoire)
d’audit
Rapport
d’audit
Action corrective
Etape 5 :
suivi
Plan
Contrôle et Validation d’action
La section suivante détaille les étapes de la procédure.

D.2. Une procédure par étape

Etape 1 – Initialisation
Après réception de la décision de la Direction générale ou des autres

directions externes, une équipe d’audit sera constituée ainsi qu’un
responsable d’audit pour le projet. Par la suite, le périmètre d’audit ainsi
qu’un référentiel sera fixé (un exemple de référentiel est donné en
annexe 2).
Etape 2 – Préparation
Le plan de travail et tous les documents relatifs au processus doivent

être préparés par l’équipe d’audit ainsi que la planification de l’audit.
Etape 3 – Visite du service audité ou de l’entreprise :

– réunion de lancement des travaux ;
– revue de la documentation ;
– interviews ;
– examen du référentiel et comparaison de l’application sur le site ;
– détection des non-conformités ;
– rapport sommaire.
Etape 4 – Rapport d’audit
L’équipe d’audit doit établir un rapport. Ce dernier peut être séparé ou

intégré dans le rapport d’évaluation technique avec les éléments
trouvés issues des tests (possibilité d’un rapport commun).
Etape 5 – Suivi
Cette étape concerne le suivi global du processus global et focalise sur

les actions correctives ou les recommandations émises (plan d’action
corrective). Les modifications ou les améliorations prévues doivent être
vérifiées par la suite.
D.3. Validité
La durée de validité d’un rapport d’audit est la même que celle de

l’approbation pour la qualification d’un produit pour une version
donnée: trois ans à partir de la date d’approbation. A chaque
changement du produit ou système ou de son utilisation hors du même
contexte, l’approbation est caduque.
D.4. Modulation
D.4.1. Expiration de la validité d’un produit déjà qualifié
Dans le cas d’expiration de la validité d’un produit déjà qualifié pour

une version donnée, un audit doit être réalisé si une demande de re-
qualification est activée. Néanmoins, l’application de cette procédure
pourrait être allégée.
D.4.2. Similitude avec un produit déjà qualifié
Dans le cas d’une nouvelle version (amélioration ou changement

mineur) issue d’un produit déjà qualifié dans un changement de
contexte ou d’environnement, l’audit qualité n’est pas nécessaire.
Concernant un produit de la même catégorie ou du même type de

produit déjà qualifié, le processus de qualification pourrait être allégé.
Les anciens éléments d’audit pourraient être utilisés si l’environnement
ou le contexte n’ont pas été modifiés.
Remarque concernant les produits de sûreté et de sécurité
Concernant les produits ou systèmes ayant un impact sur la sûreté et la

sécurité, la procédure doit être consolidée sur les points suivants :
– exiger deux équipes d’audit et deux évaluations techniques
effectuées par deux laboratoires accrédités distincts ;
– stipuler une analyse comparative avec les rapports d’audits et les
évaluations techniques obtenus. Autrement dit, la nécessité d’obtenir
des résultats concordants.
7.4. Annexes
7.4.1. Annexe 1 : plan type du rapport d’audit
Introduction
Concernant la qualification d’un outil de référence logiciel ou d’un
outil de test, la procédure de qualification suivante sera utilisée:
Document politique 1 numéro d’édition : 1.8 du 22/10/2002.
Contexte de l’audit
– La présentation des éléments de la société du demandeur.
– Les explications et la rationalité concernant les fonctionnalités du
produit ou du système seront audités.
– La version en cours du logiciel sera examinée.
Termes et définitions
Partie réservée pour la définition des mots techniques utilisés.
Actions d’audit qualité
L’audit qualité comprend les diverses actions suivantes :
– demander au développeur ou fournisseur les principaux documents
concernant le produit ;
– demander les documents ou divers certificats du fournisseur ;
– faire faire des tests techniques par un laboratoire technique accrédité
en vue d’établir un rapport d’évaluation technique ;
– examen des divers documents par notre équipe d’audit en vue
d’établir un rapport d’audit qualité ;
– demander les informations complémentaires et examen de ces
éléments si nécessaire ;
– rédiger un rapport d’audit qualité.
Examen des documents en rapport avec la qualité
Les documents concernant le développement et la conception du produit
ou du système seront examinés (le référentiel du développement).
Documents de certification
Tous les certificats ou preuves (concernant la qualité, document ISO
par exemple) concernant le produit et/ou le service seront examinés.
Mesures et preuves d’assurance qualité
Le rapport et/ou le résultat de l’évaluation technique sera fourni et
présenté par un laboratoire indépendant accrédité.
Conclusion
L’équipe d’audit fournira des recommandations pour la décision du
jury de qualification (pour la qualification du produit).
7.4.2. Annexe 2 : exemple des éléments du référentiel
– Plan de la gestion des configurations.

– Manuel d’installation.
– La norme ISO 9126.
– Manuel des opérations.
– Plan de gestion de projet.
– Plan d’assurance qualité.
– Documents ou historique détaillant les changements du système.
– Description technique, plan de vérification et de validation.
Aucun service technique ne peut fonctionner sans un planning ou
sans un programme de travail ni procédure. Il en est de même pour
un service d’audit lors des missions. Ce chapitre propose donc un
plan type de programme de travail ainsi que quelques procédures.
L’avantage de ces exemples c’est qu’ils peuvent être « retaillé » sur
mesure pour une utilisation rapide et opérationnelle. Enfin, il
importe de souligner que tous les documents ou normes utilisés
devraient inscrits comme référentiel dans ces procédures. En effet,
l’audité ou les membres de son service peuvent contester les
remarques d’un auditeur concernant un point faible si ce dernier ne
figure pas dans un document référencé.
FOIRE AUX QUESTIONS
(CHAPITRE 7)
Question 1 : quel est le nombre de pages au minimum nécessaires

pour un plan de travail ?
Réponse : il n’y a pas de règles fixes. Un nombre de pages minimum

n’est pas nécessaire, mais la qualité est exigée pour l’établissement d’un
plan de travail. En effet, il s’agit du plan de route de l’auditeur pour
pouvoir exercer son audit informatique. Un plan de travail bien conçu et
« bien ficelé » permet d’avancer très rapidement le processus d’audit.
Question 2 : en ce qui concerne les procédures d’audit, doit-on

respecter un plan bien déterminé et/ou un certain nombre de pages ?
Réponse : la ou les procédures d’audit sont très spécifiquement liées à

chaque d’entreprise, quoique le canevas soit pratiquement le même.
C’est pourquoi nous avons donné deux exemples dans ce livre. Ces
exemples permettront aux initiés d’établir rapidement en cas de besoin
une procédure ad hoc.
Quand au nombre de pages, il est variable et c’est toujours la qualité et

la réalité (concernant les démarches adoptées) qui doivent être les points
importants à respecter.
Question 3 : tous les référentiels doivent-ils être cités dans la

procédure ?
Réponse : la réponse est oui sans hésitation. En effet, l’audité peut

contester les remarques d’un auditeur qui cite un point faible ne figurant
pas dans la procédure ou dans un document référencé.
Question 4 : la page d’identification du document est elle réellement

nécessaire dans une procédure ?
Réponse : la réponse est oui. En effet, en vertu du principe de la

traçabilité, cette page permet d’identifier tous les éléments relatifs à ce
document, par exemple, son auteur, son lieu d’archivage, le résumé de
la procédure… C’est en quelque sorte la pièce d’identité du document.
Question 5 : comment doit-on gérer une procédure d’audit ?
Réponse : la gestion des procédures d’un service d’audit est analogue à

celle des documents d’une entreprise souhaitant ou se préparant à être
certifiée ISO 9001 :2000. C’est-à-dire que toute la traçabilité doit être
implicite. La naissance, les modifications des éléments de la procédure
et son retrait doivent être suivis et les dates respectives de ces processus
doivent être consignées.
Question 6 : en quoi consiste le guide TickIT ? Doit-on l’utiliser ?
Réponse : la certification TickIT est élaborée par les Anglo-saxons

concernant la qualité et le développement du logiciel. En fait, c’est
l’adaptation spécifique de l’ancienne norme ISO 9001 pour ce corps de
métier. Il n’est pas nécessaire de l’utiliser sauf si l’on vise une
certification de ce type. Ce guide comporte trois principales sections: la
première pour le client, la seconde pour le fournisseur et enfin la
troisième section pour les auditeurs.
CONCLUSION
Dans un contexte fortement automatisé, de plus en plus « Internet » et

compte tenu des éléments suivants, les besoins de sécurité ainsi que
ceux de conseils et d’audits techniques vont s’accroître d’une façon
importante. :
– foisonnement de l’informatique, de la bureautique surtout, de la
micro-informatique ;
– forte croissance des connexions des réseaux ;
– besoin élevé de communication des entreprises avec leurs filiales ou
avec les autres sociétés implantées dans un futur proche partout en
Europe avec le Marché unique.
Dans un article de l’Usine nouvelle du 10 mars 2005, à propos des

besoins et recrutement des jeunes ingénieurs diplômés (toutes les
disciplines confondues), c’est le secteur « Etudes,conseil et audit » qui a
été classé en premier. Ce qui paraît contradictoire, alors que ces derniers
étaient plutôt formés et préparés pour travailler dans l’industrie ! Cela
est d’autant plus contradictoire que les besoins du secteur de traitement
de l’information est en troisième position derrière le secteur de
l’industrie automobile…
Ainsi, via les besoins croissants du secteur conseil/audit, on peut penser

que la nécessité de la Direction générale ou des dirigeants de maîtriser
leurs systèmes d’information et informatique se ressent de plus en plus
face à l’évolution vertigineuse des nouvelles technologies et le besoin
croissant d’outils d’aide à la décision. Maîtriser ses outils d’information,
de production et/ou de communication est une condition indispensable

pour qu’une entreprise puisse aborder la concurrence et conquérir des
parts de marché. Cela ne peut se concevoir sans l’assurance de la
performance, de la qualité, de la fiabilité des systèmes utilisés (devenant
de plus en plus complexes avec les réseaux et les interconnexions) et de
leurs adéquations avec les besoins de l’entreprise.
De ce fait le rôle des auditeurs informatiques est double : diagnostiquer,

s’assurer (révéler les défauts, failles ou points faibles pouvant nuire à la
sécurité et au fonctionnement) et proposer des améliorations, des
recommandations aux dirigeants et aux chefs de service.
D’autre part, avec l’élargissement de l’Europe et la relance de la

dynamique des activités stimulée par les nouvelles technologies ICT
(Information and Communication Technologies), en particulier avec le
Web et ses outils de communication (Wifi, communication via les
mobiles, via les satellites…), le développement des risques techniques
et informatiques associés sont des menaces réelles. De ce fait, il est
inévitable que le métier d’auditeur spécialisé en informatique et en
système d’information soit amené à s’affirmer. Cela se confirme aussi
par la presse spécialisée. Dans le magazine 01 Informatique DSI de mai
2005, on peut lire la phrase suivante : « Avec l’ouverture des
applications métier sur Internet et l’avènement de nouvelles contraintes
réglementaires comme la Loi Sarbanes-Oxley1, la pratique de l’audit du
système d’information promet de se développer ».
A Bruxelles, conscient des enjeux et des risques liés à la transmission et

à l’authentification des informations, une directive européenne
(n° 1999/93/CEE) de décembre 1999 a été publiée concernant la
réglementation de la signature électronique au niveau communautaire.
Dans une entreprise, pour la bonne marche et la protection de son

patrimoine, l’audit informatique est devenu un élément incontournable
1. La loi Sarbanes-Oxley qui est adoptée en juillet 2002 faisant suite aux déboires
financiers et malversations, par le Congrès américain (appelée aussi SARBOX ou
LSO en français) oblige les entreprises à répondre de certaines prérogatives (voir
aussi lexique).
Conclusion 189
avec son système « fiable et connectable » aux autres réseaux externes à

travers le monde.
Cependant, pour bon nombre d’entreprises, auditer et vérifier la sécurité

et la sûreté de leur système informatique et de leur système
d’information, le problème consiste à trouver cet « acteur
informatique » externe ou interne.
Constatant la nécessité d’une part, d’un audit informatique et d’autre

part, le manque de compétence interne, les responsables ou dirigeants
sont souvent amenés à en appeler à des contributions de consultants ou
d’auditeurs externes.
Mais, il n’en demeure pas moins que la personne responsable de

l’informatique de l’entreprise doit comprendre l’enjeu du processus et
offrir son entière coopération à ces « auditeurs étrangers » venus
d’ailleurs (le personnel de l’entreprise est souvent très méfiant). En
effet, il ne doit pas être nos censeurs, mais nos partenaires pour
l’amélioration de la qualité, de la sécurité et de l’adéquation de nos
outils d’exploitation avec les objectifs de l’entreprise…
ANNEXE 1
Rappel
des outils pour les auditeurs
A1. Rappel des outils pour les auditeurs
Les auditeurs ont besoin d’être bien formés et de maîtriser certaines

techniques pour bien mener leurs missions à terme. Nous ne
développons pas ces sujets, seul un bref rappel concernant les éléments
clefs est détaillé ci-dessous.
A1.1. La technique de réunion
Cette technique demande une préparation sérieuse, de la vigilance et

exige un investissement préalable. Elle comporte deux phases : la phase
préparatoire et le déroulement proprement dit. La convocation établie
puis‚ distribuée aux acteurs concernés peut être considérée comme
l’aboutissement de la phase de préparation. Ce document comporte les
renseignements suivants : le sujet, le champ d’étude, les objectifs, un
plan de réunion, le lieu et l’heure de la séance ainsi que la liste des
participants.
La réunion doit commencer par une présentation des participants, puis

un rappel des objectifs. Il serait souhaitable d’avoir un animateur qui ait
pour rôle de répartir « les temps et les droits de réponse » et d’éviter les
conversations en aparté, de nature hors sujet ou ne concernant pas les
objectifs préalablement fixés. Enfin, une personne doit être désignée
pour l’établissement d’un compte rendu.
A1.1.1. Les interviews
L’interview se fait d’une façon individuelle. Cette technique permet de

creuser plus et d’obtenir des renseignements « pointus » intéressants et
parfois non diffusables en groupe. Elle comporte deux phases :
– la préparation d’une liste des thèmes ou d’éléments à demander (le
check-list) le choix de l’interlocuteur du service audité,
l’établissement des questionnaires (voir infra) constituent la première
phase de l’interview ;
– la conduite de l’interview doit être menée avec tact et souplesse. En
effet d’une part, on perturbe le travail quotidien de l’interlocuteur,
d’autre part certaines questions pourront le gêner. Pour mettre à l’aise
la personne interviewée, il serait souhaitable de se présenter, lui faire
connaître, au préalable, les objectifs de l’entretien et révéler ses
contributions éventuelles dans le domaine enquêté par les auditeurs.
Rappelons qu’il existe des inconvénients par rapport à la réunion

classique :
– un nombre potentiel élevé de personnes à interviewer ;
– une augmentation de délai pour l’obtention des informations
(difficulté pour prendre un rendez-vous) ;
– la nécessité de déplacements importants.
Autrement dit, toute technique de planification et de prévision

budgétaire serait de bon augure.
En tout état de cause, quelle que soit la technique choisie, il faut donc
établir un plan de visite pour tirer un maximum de profit de ces
méthodes de travail. Le plan de visite sera établi en fonction du service
audité, de ses contraintes, de la disponibilité des interlocuteurs et de leur
hiérarchie.
Annexe 1 193
A1.1.2. Le questionnaire
Moins contraignant que les deux techniques précédentes, le

questionnaire crée moins d’appréhension et pose moins de problème
d’ordre psychologique (le participant est invisible et peut être
anonyme). Mais pour le demandeur d’informations, l’utilisation du
questionnaire soulève quelques inconvénients.
– absence de réponse pour certaines questions ;
– retour hors délai, d’où questionnaire non exploitable au bon
moment ;
– réponses hors sujet ;
– non-retour du questionnaire.
Pour éviter au maximum ces inconvénients, une préparation minutieuse

est nécessaire pour déboucher sur des questions précises, sans
ambiguïté, claires et ouvertes (éviter les réponses de type oui ou non).
La longueur du questionnaire est primordiale : trop long, il décourage le
participant, trop court, l’obtention des informations intéressantes sera
difficile. Cependant cet outil n’est pas très fiable et une vérification
s’impose ultérieurement : les fournisseurs des réponses ont tendance à
maximiser leurs points forts et minimiser leurs points faibles.
A1.2. Les autres techniques, les tests et les outils logiciels
A1.2.1. Outils de test
– Les tests : technique consistant à prendre un échantillon d’une

population ou l’étude exhaustive en cas de besoin ou de doute, et le
traiter suivant les méthodes statistiques et/ou probabilistes afin de
terminer les résultats en vue de les comparer avec ceux connus ou déjà
publiés. Une technique mathématique peut être utilisée pour confirmer
une hypothèse est le fameux test de X² (Chi deux).
– Les tests de variances et de co-variances sont parfois nécessaires
dans certains contextes.
– Les graphes ou les schémas de circulation de document ou

d’information : outils permettant d’apprécier de façon synthétique les
événements et de révéler les anomalies.
– Enfin, concernant l’élaboration du rapport ainsi que des divers
documents, il serait souhaitable de maîtriser les outils bureautiques tel
que Microsoft Office ou Star Office. La maîtrise d’Excel par exemple
ainsi que son système graphique ne seraient que bénéfiques pour les
auditeurs pour représenter les chiffres et les données statistiques
recueillies.
Toutes ces techniques ont pour but de trouver les réponses à certaines
questions et/ou de démontrer les points forts ou les points faibles de
l’organisation, des procédures...
En résumé, l’utilisation des techniques et méthodes maîtrisées

permettrait aux auditeurs de « systématiser » les travaux et gagner du
temps. Ceci est d’autant plus profitable lorsqu’il existe des feedbacks
(retours d’informations des autres audits effectués) d’autres membres
pratiquant les mêmes types d’outils.
A1.2.2. Outils (logiciels)
La démarche adoptée des auditeurs consiste aussi à connaître et

identifier les processus pratiqués. Côté outils informatiques, il existe
bon nombre de logiciels tels que IDS Scheer d’IBM, SAP ou Oracle-
Peoplesoft ou celui d’Enablon. Ce dernier permet aux utilisateurs de
saisir des informations sur des formulaires électroniques stockés dans
un serveur.
Ces informations sont ensuite remontées jusqu’à la Direction sous

forme de tableaux de bord avec des indicateurs de risque. L’outil
conserve tous les types d’informations et les archive. Cette possibilité
est très utile pour les auditeurs, surtout dans le cadre de la loi Sarbanes-
Oxley (concernant particulièrement les entreprises qui ont des filiales ou
agences aux Etats-Unis).
Annexe 1 195
L’éditeur BMC Software quant à lui, propose un outil qui identifie les
liens entre les applications et l’infrastructure informatique. De ce fait,
les informations en output pourraient être fort utiles pour les auditeurs
pour identifier les applications métier touchées en cas de panne et les
risques potentiels encourus.
A1.2.3. La formation
Afin de pouvoir exécuter avec efficacité les missions qui lui sont
confiées, un auditeur devrait pouvoir se former régulièrement et se
remettre à niveau. Une formation d’une semaine ou de dix jours n’est
pas excessive pour un auditeur informatique confronté à des missions
pointues telles que celles concernant les systèmes. Et pour la qualité de
ces dernières, cela est même crucial.
Nous conseillons de se former auprès des constructeurs adéquats pour

les outils techniques. Pour une mise à jour de généraliste, l’IFACI serait
également une bonne adresse et aussi l’occasion d’échanger les
expériences avec les autres confrères. Il importe de savoir que les
formations accordées aux auditeurs constituent un investissement et non
un luxe ou une perte de temps.
De ce fait, le responsable d’audit interne devrait planifier et consacrer

des créneaux de formation aux membres de son équipe en cohérence
avec les missions planifiées. Enfin, pour les personnes qui devraient
auditer le cœur des systèmes et/ou réseaux, il est important de leur
accorder des formations supplémentaires auprès des constructeurs. Dès
lors, la durée de l’ensemble de leur formation serait systématiquement
allongée.
ANNEXE 2
Démarche
pour un plan de sécurité
Dans bon nombre de sites audités, nous détectons l’absence d’un plan
de sécurité, en tant qu’auditeur nous pouvons recommander la
démarche suivante en cinq points :
1) l’identification des objectifs et la pré-étude ;
2) l’analyse des risques ;
3) l’élaboration d’un plan d’action ;
4) la réalisation des actions ;
5) le suivi et la réactualisation (si nécessaire) du Plan de sécurité.
Détaillons-en les différentes étapes.
1re étape
L’identification des objectifs et la pré-étude constituent la première

phase du processus. Elle est primordiale, car elle permet une prise de
conscience générale sur les problèmes de sécurité par les différents
acteurs de la Direction, du service informatique, des utilisateurs (leur
représentation) et si nécessaire des représentants syndicaux. En effet la
sécurité est, et sera, l’affaire de tous.
Elle permet aussi de définir en commun un plan global, associé à la

répartition des travaux et responsabilités ainsi que la définition d’un
budget (aval de la Direction) et un calendrier prévisionnel (accord de
tous les acteurs concernés).
2e étape
Cette phase concerne l’analyse des risques. Il faut distinguer l’analyse

par domaine. Par exemple, il faut dissocier le domaine des logiciels
courants de gestion, celui des applications web ou celui du réseau…
L’analyse de l’existant, la pratique du « scoring » (principe de
pondération) et la mise au point d’un plan d’amélioration seront les
tâches de début de cette étape. Puis l’évaluation des moyens et
procédures (ressources, budget, temps), leurs coûts associés et les choix
définitifs clôturent cette étape.
3e étape
Cette étape détermine l’élaboration d’un plan d’action. Celui-ci ne peut

se concevoir qu’à la fin des deux étapes précédentes. En « input», il
prendra toutes les informations issues de ces dernières et définit qui fait
quoi, pour quand, où (lieu quand un événement se réalise), comment et
avec quoi. Ce plan définit un planning rigoureux de chaque tâche
associée aux acteurs correspondants.
4e étape
A partir du plan précédent, on met en place tous les dispositifs prévus

(si c’est la première fois) et on réalise les tâches définies pour et avec
les acteurs associés. Cependant il faut noter l’importance du reporting
des acteurs. Si un incident se manifeste, on applique stricto sensu le
plan d’action. Un bilan est nécessaire après chaque incident et/ou après
l’application du plan.
Annexe 2 199
5e étape
Cette étape se nomme phase de suivi et de réactualisation du plan de

sécurité. En input, elle a besoin des bilans et des documents de
reporting de la phase précédente. Elle est importante et nécessaire car
elle permet aux services informatiques d’évoluer, de s’adapter et
d’élaborer des parades et actions face aux nouvelles menaces,
vulnérabilités et aux nouvelles technologies.
ANNEXE 3
Fonctions illicites
des programmes malveillants
Cette annexe décrit succinctement les programmes dévastateurs ainsi

que leurs diverses fonctions malveillantes et illicites.
A3. La fonction illicite
Afin de mieux appréhender ces problèmes, il nous semble utile de

détailler d’abord les caractéristiques des fonctions illicites ainsi que les
programmes destructeurs.
La « fonction illicite » est une fonction d’un programme non autorisée,

non documentée et qui ne participe en rien aux objectifs officiels du
programme ou à une application informatique.
En général une fonction illicite :

– a un caractère malveillant : la fonction peut avoir un effet
destructeur logique (par exemple un effacement logique de fichier),
plus rarement un effet destructeur physique (par exemple variations
rapides et extrêmes du bras de lecture du disque), un effet inhibiteur
(saturation d’un canal I/O, saturation mémoire, bouclage de
programme, perturbation du Command Liner Interpreter *) ou un effet
purement modificateur. Elle peut, en outre, entraîner le vol ou la
divulgation de données (par exemple, interception de mots de passe

lors des modifications) ;
– n’est connue que d’un nombre très réduit de personnes : son ou ses
concepteurs ;
– ne rend service à personne d’autre qu’à son ou ses créateurs ;
– s’exécute à l’insu de l’utilisateur.
Toute infection utilise une ou plusieurs fonctions illicites. Une fonction

illicite peut avoir un effet temporaire (conditionné à certains paramètres
internes ou externes) ou permanent. Elle peut en particulier intégrer une
fonction d’auto-effacement de certaines traces. Une fonction illicite peut
représenter une petite partie d’un programme ou le programme entier :
on parle dans ce cas d’usurpation d’identité.
Un exemple extrait d’un hebdomadaire spécialisé, il y a quelques années :

le programme Stripes.exe sous MS/DOS (système d’exploitation de Microsoft
pour micro-ordinateur, compatible IBM) contient une fonction illicite :
pendant qu’il affiche à l’écran une figure amusante, tous les mots de
passe sont copiés dans un fichier nommé Stripe.bqs.
A3.1. La fonction à déclenchement différé
La « fonction à déclenchement différé » est une fonction d’un

programme dont l’exécution est différée jusqu’à ce que certaines
conditions soit remplies : déclenchement d’événements particuliers ou
par l’absence d’événement, ou en fonction d’une date, etc. Un exemple
classique de bombe logique à déclenchement différé est celui d’un
programmeur qui, pour se prémunir d’un licenciement, insère dans un
programme de paye une fonction de destruction de fichiers ou de
reformatage des disques durs, dont l’exécution est déclenchée si son
nom disparaît du fichier du personnel ou du fichier de paie.
A3.2. La fonction de déplacement
La « fonction de déplacement » est une fonction qui déplace un

programme ou qui est capable de transférer le programme d’une adresse
Annexe 3 203
à une autre de la mémoire vive (RAM : Random Access Memory) ou de

la mémoire de masse d’un ordinateur. Par exemple, le jeu informatique
Core wars, où l’on trouve le phénomène de lutte de deux programmes
pour acquérir la possession exclusive de la mémoire d’un ordinateur,
repose essentiellement sur les fonctions de déplacement.
A3.3. La fonction autoreproductrice
Enfin, la « fonction autoreproductrice » est une fonction d’un

programme qui possède la faculté de créer une réplique strictement
identique du programme et donc d’elle-même (que l’on appelle souvent
le phénomène de clonage). Un tel programme est très difficile à
éliminer, car il se multiplie rapidement et l’oubli d’un seul exemplaire
suffit pour que le système soit de nouveau, à brève échéance, totalement
contaminé car chaque copie peut à son tour se reproduire
(développement rapide de type exponentiel, même phénomène que les
virus dans le corps humain).
A3.3.1. Définition des programmes dévastateurs
Les programmes destructeurs ou appelés dévastateurs (quatre types) se

différencient par les fonctions qu’ils pratiquent et par leurs définitions :
« Un ver est un programme qui se propage dans un

ordinateur ou dans un réseau, c’est un produit qui s’insère
comme un parasite dans un programme normal
d’application ou utilitaire. »
Exemple récent : un ver nommé w32/MyDoom se propageant via les

mails le 27 janvier 2004, aléatoirement, avait fait quelques centaines de
milliers d’infections des ordinateurs privés et ceux des entreprises via
Internet. Deux jours après, un tiers des utilisateurs du courrier
électronique étaient contaminés dans le monde. Microsoft offrait
250 000 dollars à la personne capable de trouver le ou les auteurs de ce
ver. L’émail incite les gens à ouvrir un fichier exécutable avec les
informations suivantes : « The message cannot be represented in 7-bits
ASCII encoding and has been sent as a binary attachement ».
Autrement dit, l’email précise que le message attaché ne peut être

présenté en 7 bits, en ASCII (c’est-à-dire possibilité de lecture normale)
et a été envoyé en fichier binaire. Les utilisateurs croyant à la véracité
de l’explication ouvrent ce fichier qui n’est en fait que le ver malsain
créant le ralentissement de leurs systèmes et polluant leur réseau
d’entreprise.
Les vers sont des programmes qui ont en plus une possibilité de
déplacement, c’est-à-dire un positionnement dans la mémoire centrale
ou dans les autres supports d’une façon aléatoire en fonction d’une règle
pré-programmée.
Les chevaux de Troie sont les premiers programmes malveillants

connus dans les environnements informatiques, leur technique consiste
à exécuter les fonctions illicites.
Puis arrivent les bombes informatiques : programmes ayant les

caractéristiques des premiers mais en plus ils peuvent agir à retardement
(d’où l’origine de leur nom), en fonction d’une date préprogrammée ou
en déclenchement si l’on rentre un mot clef « détonateur » par hasard ou
par inadvertance.
Enfin les virus sont, chronologiquement, les derniers apparus, outre la

possession de toutes les caractéristiques citées précédemment, ils ont la
possibilité d’autoreproduction, de création des clones de répliques au
sein d’autres programmes.
Ils laissent une empreinte sur les programmes contaminés évitant ainsi
une double contamination, par contre, ils ne laissent aucune trace sur le
système d’exploitation. On peut distinguer deux types de virus par leurs
effets et par leurs manières de contaminer les programmes.
A3.3.2. Les virus par ajout
Les virus par ajout : comme ce nom l’indique, ils ajoutent des
instructions aux divers programmes d’application sans les détruire. A
chaque exécution du programme contaminé, le virus s’exécute puis
Annexe 3 205
redonne le contrôle au programme, il agit d’une façon analogue au sous

programme ou subroutine. Son point fort : sa détection tardive peut
entraîner une possibilité de dégâts importants.
Son point faible : la taille des programmes infectés est automatiquement

augmentée d’où possibilité de s’apercevoir si l’on contrôle
systématiquement les tailles des fichiers et possibilité éventuelle d’y
remédier...
Un exemple pratique de découvrir la taille des fichiers (dans le système

d’exploitation MS-DOS des micros) consiste à taper DIR (directory,
listage du répertoire) : cette commande liste la taille ainsi que la date de
création des fichiers. Puis, on les compare avec les anciennes listes de
sauvegarde.
A3.3.3. Les virus par recouvrement
Les virus par recouvrement détruisent une partie des programmes

d’application et s’installent au départ dans ces derniers.
Enfin ces types de programmes malfaisants se distinguent aussi par leur

complexité de création : par exemple pour l’écriture des chevaux de
Troie ou des bombes, la connaissance du langage C ou de Pascal est
nécessaire et suffisant, mais pour les deux derniers types, la
connaissance de l’assembleur du microprocesseur est indispensable.
Face à ces problèmes, on peut déduire l’importance et le rôle d’un
auditeur.
ANNEXE 4
Quality audit Procedure (for a Reference product or a test tool)

DG/QUAL-PROC-0002
Edition Number V1.00
Edition Date 23 Oct, 2004
Status Proposed Issue
Category Guideline Document
DOCUMENT IDENTIFICATION SHEET

DOCUMENT DESCRIPTION
Document Title
QUALITY AUDIT PROCEDURE FOR TOOLS QUALIFICATION
EWP DELIVERABLE REFERENCE NUMBER
REFERENCE - INDEX EDITION V1.00

DG/QUAL-PROC-002 EDITION DATE : 23, October 2004
Abstract
The audit procedure applies when a qualification process is requested for a reference or test
tool or system. It determines working mode as well as conditions and associated pre-
requisites. It can be used in a acceptance process when applying the qualification procedure
for reference product or test tools.
Keywords
audit Qualification Approval Reference product
Test product Test Tool
CONTACT PERSON Henry Ly TEL : 35 12 DIVISION : EMS
DOCUMENT STATUS AND TYPE

STATUS CATEGORY CLASSIFICATION
Working Draft Executive Task General Public
Draft Specialist Task ; RU Document ; ;
Guideline
Proposed Issue Lower Layer Task Restricted
Released Issue
ELECTRONIC BACKUP
INTERNAL REFERENCE NAME :
HOST SYSTEM MEDIA SOFTWARE(S)
ARCHIVE Network Type : PRODUCT MS Office Word 6.0
Domain
Media Identification : MS Windows
Document approval
The following table identifies all management authorities who have

successively approved the present issue of this document.
AUTHORITY NAME AND SIGNATURE DATE

Qualification Process leader H. Ly 23, October 2004
Head of Quality Unit J.L. Borland 23, October 2004
Document change record
The following table records the complete history of the successive

editions of the present document.
EDITION DATE REASON FOR CHANGE SECTIONS PAGES

AFFECTED
V0.00 01-07-02 Initial document (draft) All sections
V1.00 23-10-03 Updated document All sections

Annexe 4 209
Table of contents
– Document identification sheet.

– Document change record.
– Table of contents.
The same as the French version.
A4. General principles
A4.1. General objectives of the procedure
All aspects, components and topics of the Quality System would be

audited. The main goal is to check the efficiency of the quality system
of the audited service. Quality audit and technical qualification by a
third party laboratory were the two components to get the tool
qualification approval and the certificate of qualification.
A4.1.1. Application field
The audit procedure is associated with the qualification procedure. That

means to be applied to a test product (test tool) or system, i.e. an entity
used to test the conformity of other systems with a standard or a given
referential.
It determines working mode as well as conditions and associated pre-

requisites.
It can be used within the frame of an acceptance process.
A4.1.2. Expected benefits
The application of this procedure is a method which is included in a

quality approach to allow :
– building an established confidence in these products ;
– improving the quality of the software products and of their services ;
– decreasing the global cost of these products ;

– increasing the requirement level concerning these products ;
– promoting a progressive harmonisation of used products ;
this aims to achieve technical excellence.
Referential useful to better understanding

All terms and expressions used can be found in the following
referential :
– « Study Report Qualification and Certification Issues »
(ref. : PLC.ET1.ST006.000-REP-000).
– « Qualification Procedure » (ref. : Policy document 1 Edition :
1.08).
– ISO 9000 : Quality management systems – Fundamentals and
vocabulary (edition date 20/12/2000).
– ISO 9001 : Quality management Systems - Requirements (edition
date 20/12/2000).
– ISO 9004 : Quality management Systems - Guidelines for
performance improvement (edition date 20/12/2000).
– ISO 19011 : Guidelines for quality and/or environmental
management systems auditing (edition date 01/10/2002).
A4.2. Conditions for application of the procedure
Before submitting a product or system to the qualification procedure

and quality audit procedure, one should not lose sight of the ratio
« Interest versus Cost ». However the quality audit procedure will be
automatically applied when a qualification is requested.
A4.2.1. Quality audit Procedure Requirements
A Service or a firm should be audited if a qualification procedure of a

product is required. That means to be applied :
– it has to be used as test product (test tool) in the frame of the
certification procedure ;
Annexe 4 211
– it is or shall be used by several services and Member States ;

– it is or shall be used in several regional centres of several members
States ;
– it plays or shall play a critical role within a regional centres or a
central system ;
– it has or shall have an essential role – namely concerning the quality
control (a test tool, for example) – vis-à-vis the functioning of a
regional centres or a central system ;
– it has or shall have an essential role – namely concerning the quality
assurance (a production tool, for example) – vis-à-vis the functioning
of a regional ATC centres or a central system.
A4.2.2. Pre-requisites
A4.2.2.1. Technical pre-requisites
The product has to have been duly verified and validated by the
developer and/or the supplier.
If need be, the product can already be operational on a particular site of

Member States.
In parallel, the technical qualification (including technical

documentation reviews, code checking…) by a third party accredited
laboratory should be done.
A4.2.2.2. Quality pre-requisites

As it concerns the demander must be already obtain :
– label (an accredited label from a recognised authority) ;
– ISO 9001 :2000 certificate on the defined perimeter including
product design and manufacturing processes (should be applied to the
all of supplier body) ;
– a proven in-house organisation and methodology with a internal
audit planning and methodology. In this case the audit must be
strengthened.
A4.2.2.3. Administrative pre-requisites

The administrative request is the same pre-requisite defined for the
qualification procedure. That means :
A request (for qualification) has to be addressed by the requester to the

Head of R.U Unit in due form in the prescribed periods, namely at least
two months before the beginning of the evaluation work and at least
four months before the expected date for the jury.
Making this, the demander or requester has to designate a qualification

correspondent (Project leader or Quality manager) and to allocate a
budget for the procedure expenses.
A4.3. Outpout of the quality audit process
A4.3.1. Quality audit report
The main output of the quality audit process is the report made by the
audit team (a framework of this report is shown in enclosure 1).
This report will be given to the member of the qualification jury and to
the audited service.
A quality audit team will be set up for each product qualification and a
report is specific for each qualification process.
The audit team will also present the findings during the Jury
Qualification Meeting.
A4.3.2. Recommandations
Recommendations or suggestions could be also given by our quality

audit team if necessary.
Annexe 4 213
All items giving « bad impact » to the quality system must be corrected
and followed up and taken into account by the requester and the team in
appropriate corrective processes (action plan).
A4.4. Phases of the quality audit procedure
The audit procedure defines a process in five steeps.
A4.4.1. Diagram of the process
(We give intentionally another format for the diagram vis-à-vis the previous
one.)
Step 1 : initialisation
Supplier Request
AUDIT TEAM DESIGNATION
REFERENTIAL
DETERMINATION
Step 2 : preparation
PREPARATION AND PLANNING

Step 3 : audit processing
Working Plan
Schedule
KICK-OF MEETING
DOCUMENTATION
REVIEW
INTERVIEWS
SUMMARY
Step 4 : audit reporting
Technical
AUDIT REPORT WRITTING
evaluation
(Laboratory)
Audit Report
Annexe 4 215
Step 5 : follow up
Correctives actions
CHECKING AND VALIDATION

Action
Plan
A4.4.2. A step by step procedure
Step 1 : initialization
After receiving the Decision of the high management or the external

request, a quality audit team will be set up and a team lead designated.
The context or environment and the referential will be fixed (an

example of the product referential is shown in enclosure 2).
Step 2 : preparation
Working plan and all relevant documents must be prepared by the audit
team and the audit schedule established.
Step 3 : visit of audited services or firm
Kick-off meeting :
– documentation review ;
– interviews ;
– referential examination / comparison on the site ;
– non conformity detection ;
– summary report ;
Step 4 : audit report
The quality team will establish an audit report. This report could be
separated or integrated with the findings after the technical qualification
process of the third party laboratory process (Possibility of a common
report).
Step 5 : follow up
The phase consists in the follow up of the global process and focuses on
the corrective actions or recommended actions (action plan).
The effective set up of modifications and improvements must be

checked.
A4.4.3. Validity
The validity of an audit report is the same as the qualification approval

for a given version of a product. It goes up to three years after the
approval date. Any change in the system or if its use in another context
automatically cancels the approval.
A4.4.4. Modulation
A4.4.4.1. Expiration of the validity of an already qualified product

In case of expiration of the validity of a product already qualified in a
given version, a audit must be redone as the re-qualification is
requested. But the procedure can be lightened and limited.
A4.4.4.2. Similarity with an already qualified product

In case of a new version of a product already qualified in a former
version, and in case of no changing context or environment the quality
audit is not necessary.
In case of a product of the same type as an already qualified product, the

qualification procedure can be lightened and be based on a part of
Annexe 4 217
former results to focus on differences and in case the context or

environment do not change, the quality audit is not necessary.
Remark : security and safety products related.
In case of a product or system involving security and safety aspects, the

procedure has to be strengthened on some points like :
– to stipulate two audit teams as well as two technical qualification
and testing by two separated accredited third party laboratories ;
– to stipulate a comparative analysis of the obtained audit results and
technical reports. All results must be consistent.
Enclosure 1
Framework of quality audit report
Introduction
To qualify a software tool, the qualification procedure for test tools
(Policy document 1, edition number 1.8, dated 22/10/2002) is used.
Context of the audit

The presentation about supplier company.
The explanation of software tool product or system to be audited.
The software number version audited.
Terms and definitions

The explanations of special words used.
Quality audit actions

The quality audit has performed in the following actions :
– requesting to the supplier for main product documentation ;
– requesting to the supplier for certification documents ;
– processing technical tests by independent testing laboratory
(technical evaluation report) ;
– examining product documentation by our audit team (quality

evaluation Report) ;
– il necessary, asking for complementary questions to the supplier and
examining answers ;
– writing down this quality audit report.
Quality documents examined

The list of product and system development documents examined
(product or system development referential).
Certification documents
The list of ISO documents examined (quality referential).
Quality assurance measures

The reported conclusions of the technical evaluation processed by the
independent laboratory.
Conclusion
The quality audit team gives a positive/negative statement on this matter
for the qualification jury.
Enclosure 2
Example of product referential
– Configuration Management Plan.

– Installation Manual.
– ISO 9126 Quality Statement.
– Operator’s Manual.
– Project Management Plan.
– Quality Assurance Plan.
– System Change documents.
– Technical description.
– Verification and Validation Plan.
BIBLIOGRAPHIE
[BEE 89] de BEELLEFONDS L., Droit de l’informatique et de la télématique,

Delmas, Paris, 1989.
[FEU 05] FEUJO I., Guide des audits, Editions AFNOR, La Plaine Saint-
Denis, 2005.
[GAV 86] LOUIS-GAVET G., Quelle méthode d’analyse implanter dans votre
entreprise ?, Edition A.I.D.E, 1986.
[KAE 00] KAEO M., Sécurité des Réseaux, Edition Campus Presse, Paris,
2000.
[LAM 01] LAMPRECHT J., ISO 9001 : Commentaires et conseils pratiques,
éditions AFNOR, La Plaine Saint-Denis, 2001.
[LY 89] LY H., RALAY. G., L’audit informatique, théorie et applications
progressives, Pochette de formation, 1989-1990.
[LY 91] LY H., L’audit informatique dans un contexte mini et micro, Editions
d’Organisation, Paris, 1991.
[LY 05] LY H., TRABELSI Z., La sécurité sur Internet, Hermès-Lavoisier,
Londres, 2005.
[PIN 00] PINET C., La qualité du logiciel, Edition AFNOR, La Plaine Saint-
Denis, 2000.
[PIN 05] PINET C., Processus d’ingénierie du logiciel, Edition Pearson, Paris,
2002.
[THO 00] THORIN M., L’audit informatique, Hermès, Paris, 2000.
Revues
01 INFORMATIQUE
01 DSI - Informatique
Décision Informatique
Documents internes du service d’audit France Télécom 1991:
Mission exploratoire pour l’audit informatique, 1991.
France Télécom : document SERNIT (Service Informatique de France
Télécom) 1989.
Revue semestrielle interne de France Télecom.
LEXIQUE
Avertissement : seuls les termes utilisés dans les études précédentes

figurent dans ce lexique. De plus amples définitions devraient figurer
dans les dictionnaires spécialisés.
AFNOR : (Association française de normalisation localisée en Seine

Saint-Denis). C’est une association de Loi 1901 dont le but est de
normaliser les termes et les procédés dans différents domaines
scientifiques et techniques.
Agression : attaque sur une cible susceptible de provoquer un ou

plusieurs sinistres.
Agresseur : est une personne qui attaque ou craque un système. Cette

personne est caractérisée par sa motivation, ses moyens, sa
détermination et les faiblesses ou points faibles aperçus (ou faiblesse
des risques aperçus).
Application : ensemble des moyens logiques et physiques (fichiers,

programmes, procédures...) conçus et mis en œuvre pour automatiser
une ou des tâches pour et/ou par les utilisateurs.
ASP : Active server pages est un package comprenant les facilités et

le langage pour le développement des pages et applications pour le
Web.
Attaquant : autre terme générique, équivalent à l’agresseur ou

désignant les pirates, les crakers ou hackers.
Automatisation : transformation d’un procédé, d’un processus ou

d’une installation en vue de les rendre automatiques (AFNOR).
Backdoor : ce terme désigne une faille d’un système que l’on peut
traduire par port de derrière, porte dérobée ou trappe suivant
l’utilisation dans des contextes différents. Elle pourrait aussi être mise
en place exprès par les constructeurs ou fournisseurs de service afin de
pouvoir accéder au système et reprendre la main pour un dépannage
urgent et/ou à distance.
Back-up : ensemble de moyens mis en oeuvre pour sauvegarder tout

le système sur bande magnétique ou sur cassette par l’intermédiaire du
Stremer (cas du micro-ordinateur), et pour restaurer ces informations
en cas de besoin. Par extension, un centre back-up est un site de
secours à partir duquel on peut redémarrer l’exploitation.
Banque de données : (data bank en anglais). Dans un domaine défini,

l’ensemble de fichiers structurés pouvant être consultés par divers
utilisateurs. Ces fichiers sont gérés soit par un SGF (Système de
Gestion de Fichiers classique), soit par un SGBD (Système de Gestion
de Base de données).
Bastion : un système auquel tous les systèmes ou réseaux étrangers

doivent se connecter pour accéder à un système ou un service qui se
trouve à l’intérieur du Firewall. Un bastion est un élément constituant
du Firewall. C’est le premier élément de contact avec l’extérieur.
BBK (Black Blue Key) : mot d’origine anglo-saxonne désignant des

points clefs colorés en noirs ou en bleus. En fait, ce sont des bilans
brefs mettant en valeur, les points forts (notés BBK+) et les points
faibles (notés BBK-).
Boot strap : programme amorce. Ce programme est intégré‚ en

mémoire morte et a pour but de permettre le chargement du noyau du
système d’exploitation (le Moniteur) à partir d’un disque ou d’une
disquette.
Bugs : les bugs sont des erreurs de programmes. Ce mot a pour

origine erreur de programme de système ou de logiciel de base. Par
abus de langage, faire un bug correspond à trouver et rectifier l’erreur
des instructions dans un programme.
Lexique 223
Canal : c’est l’unité d’échange dans un environnement informatique.

C’est un processeur d’entrée/sortie ou input/output exécutant des
« programmes » de transfert.
Canal multiplexé : c’est un canal qui peut réaliser plusieurs transferts

« simultanément », on peut comparer à une sorte de Time-sharing sur
les contrôleurs connectés. Ce type de canal est réservé pour les
périphériques classiques plus lents tels que les imprimantes.
Canal simple : réservé pour les disques rapides, ce type de canal

n’exécute qu’un transfert entre l’accusé du signal SIO et le traitement
de l’interruption de fin d’entrée/sortie.
Check-list : aide mémoire ou liste d’un questionnaire libre (utiliser

pour faire un check : à un contrôle).
Command line interpreter : analyseur et interpréteur de lignes de

commande (voir noyau du système d’exploitation).
Configuration : composition physique et logique d’un ordinateur et

des organes périphériques. Cette composition doit être précisée ou
déclarée au Moniteur lors de la génération du système.
Configurer : faire une génération d’un système, d’un logiciel ou d’un

outil adapté avec l’environnement d’exploitation.
Cible : actif d’une société ou organisation susceptible d’être visé ou

atteint par un sinistre. La cible est souvent fonction de l’attrait, de
l’identité de la victime et des vulnérabilités connues.
Coupe-feu : voir firewall, pare-feu.
Débugger (un système) : ce terme signifie corriger un système ou un

programme compromis soit accidentellement soit suite à une attaque.
Discovery Tool : provenant de l’anglais, ce mot qui est utilisé

fréquemment dans l’informatique désigne les outils de découverte ou
de reconnaissance pour scanner et obtenir les informations des
systèmes. Les pirates les utilisent pour détecter leurs systèmes cibles.
Directory : fichier répertoire maître ou l’annuaire système indexant

l’emplacement des divers fichiers. Si le directory est corrompu, on ne
peut plus accéder aux fichiers.
E-mail : courrier électronique provenant de l’anglais « electronic

mail », parfois s’écrit émail.
F.A.I : fournisseur d’accès Internet, on désigne aussi souvent les

fournisseurs de portail. Par exemple : Wanaadoo, AOL…
Faille : point faible qu’un attaquant pourrait attaquer, voir aussi

« failles de vulnérabilité ».
Facteur de menace : terme désignant un ensemble ou un couple de

cible et d’agresseur. On note souvent de la manière suivante : facteur
de menace = couple (cibles(s), agresseur(s)).
Failles de vulnérabilité : d’un système (hardware ou software) ou

d’un réseau. Elles sont de plusieurs types : organisationnelles,
procédurales du personnel, de gestion et/ou d’administration, du
logiciel et/ou du matériel…
Firewall : appelé aussi coupe-feu, pare-feu, le firewall un ensemble

d’éléments dont le rôle est de séparer, analyser, limiter les entrées et
sorties indésirables. C’est un ensemble constitué de matériel (routeurs,
ponts, ordinateurs) et de logiciels appropriés. Par abus de langage, on
utilise ce mot pour désigner un logiciel seulement.
Hôte : système physique (ordinateur) rattaché à un réseau.
HTML : Hypertext Macro Language est un langage de

développement pour les hypertextes, conçu vers les débuts des années
90.
HTTP : Hypertext transfert protocol est un protocole technique

servant à transférer les hypertextes, conçu vers le début des années 90.
Lexique 225
Informatique : définition de l’Association française de normalisation

(AFNOR) : ensemble des disciplines scientifiques et techniques
spécifiquement applicables en traitement de l’information effectué
notamment par des moyens automatiques.
Informatisation : processus d’automatisation des activités‚ d’une

chaîne de traitement des processus avec des outils informatiques (qui
amène souvent des implications sur l’organisation), appelé aussi
« automatisation » par abus de langage.
Internet : principal composant de la toile mondiale www, développé

après elle, à ne pas confondre avec cette dernière, mais par abus de
langage on les associe souvent ensemble.
JAVA : est un puissant langage de programmation réseau dont

l’initiateur est la firme Sun Microsystems. Java est disponible sur le
Web (voir page adresse Web intra).
JCL : (d’origine anglo-saxonne signifiant Job Control

Language) : langage de commande des tâches ou travaux avec
lesquels on exprime les ordres au système d’exploitation pour lancer
des programmes et leur mise en correspondance avec les diverses
ressources.
LAN : ce terme venant de l’anglais Local Area Network désigne les

réseaux locaux internes des entreprises.
Logiciel : au départ, ce terme désigne un ensemble de programmes et

de procédés pour utiliser et exploiter un ordinateur (logiciel de base).
Par extension, on l’utilise pour désigner les programmes d’une
application spécifique (ex: logiciel de paie, de comptabilité..). Très
souvent par abus de langage, on l’utilise pour désigner un progiciel
(ex : logiciel Word).
Loi Sarbanes-Oxley : cette loi est adoptée en juillet 2002, faisant

suite aux déboires financiers et malversations, par le Congrès
américain (appelée aussi SARBOX ou LSO en français). Elle oblige
les entreprises à répondre de certaines prérogatives. Il importe de

noter deux éléments importants relatifs à cette loi :
– les entreprises non-américaines sont aussi concernées ;
– les systèmes d’information sont impliqués à double titre aussi. A
savoir, d’une part, dans l’utilisation de l’informatique comme outil de
gestion et de contrôle financier et d’autre part dans l’obligation
d’assurer la sécurité de ce même système informatique (nouveauté de
cette loi).
Mail fake : de faux e-mail avec usurpation d’identité de l’envoyeur.
Main-frame : mot d’origine anglo-saxonne de la firme IBM signifiant

ordinateur central ou principal.
MTBF : Mean Time Between Failures (délai moyen entre les

incidents).
MTTR : Mean Time To Repair (durée moyenne entre les réparations

ou les incidents).
Multiprogrammation : (en anglais Multiprogramming) mode

d’exploitation d’un ordinateur dans lequel plusieurs programmes
utilisateurs sont actifs à la fois, c’est-à-dire chargés en mémoire
centrale et exécutables par l’unité de traitement.
Multitraitement : (Multi-processing) à ne pas confondre avec le mot

précédent. Possibilité d’un système de coordonner et de déclencher le
déroulement simultané de plusieurs processus. Pour ce faire ce
système doit posséder plusieurs types de processeurs.
Menace : conjonction de facteurs susceptibles de favoriser le

déclenchement d’une agression (voir aussi facteur de menace).
Noyau du système : appelé souvent moniteur ou noyau système

d’exploitation, il comporte un ensemble de routines ou instructions
permettant la commande du ou des périphériques appelés BIOS (Basic
Input Output System) et un programme exécutif permettant un
dialogue sommaire avec l’utilisateur. En fait, il comprend aussi le
module d’analyseur des commandes.
Lexique 227
Operating system : voir système d’exploitation.
Overlap : recouvrement (par exemple : recouvrement des réseaux ou

des systèmes).
Password : mot de passe, chaîne de caractères indispensables pour

accéder à un système, à un fichier. En général le système ne tolère pas
plus de trois erreurs ou tentatives d’accès. On dit aussi que le système
est contrôlé par une clef d’accès.
Path : chemin ou moyen de modification directe du contenu d’un

fichier ou d’un programme objet (modification sur un octet ou sur des
bits d’un octet). En micro-informatique, dans le langage MS-DOS, ce
mot indique le chemin d’accès à un fichier ou à un répertoire
(Directory).
Patcher : patcher un système est utiliser pour désigner modifier ou

apporter une correction du système avec des éléments apportés par
l’ingénieur système ou par le fournisseur.
Pare-feux : traduit de l’anglais firewall, on appelle aussi les coupe-

feux (voir le mot Firewall).
PERL : ce terme venant de l’anglais (Pratical Extraction and Report

language) est très populaire pour la programmation réseau.
Exécutable sur plusieurs plates-formes (en particulier sous Unix,
Windows NT), le Perl est disponible sur le Web (voir définition ci-
dessous.
Processeur : dispositif constitué d’une unité de traitement, des

mémoires, des registres et qui permet l’exécution d’un programme
et/ou des opérations logiques et arithmétiques.
Processus : ensemble de tâches ou fonctions exécutées par un

processeur.
Progiciel : ensemble complet et document‚ de programmes conçus

pour être fournis à plusieurs utilisateurs ou clients en vue d’une même
application (définition du JO du 7 décembre 1981).
Remote : ce terme désigne les éléments distants. Voir exemple ci-

dessous
Remote jobs : travaux exécutés à distance ou lancés à distance.
Remote système : système distant.
Répertoire : voir Directory.
Réseau périphérique : appelé aussi réseau DMZ, De-militarized

Zone (no man’s land, Zone démilitarisée), le réseau périphérique est
un dispositif particulier implémenté (additionnel) entre le réseau
extérieur et le réseau que l’on veut protéger.
Ressource : d’une manière générale, quand on parle de « ressource »

on définit l’ensemble moyen : des ressources physiques ou matérielles
et les ressources logicielles.
Ressources matérielles : Unité centrale, mémoires centrales ou

auxiliaires, périphériques, unité de liaison ou unité d’échange.
Ressources logicielles : logiciel exploitation, logiciel de service et/ou

logiciel d’application.
Restauration : ayant pour origine Restore. Opération inverse de la

sauvegarde afin de générer une partie ou la totalité du système lors
d’un plantage. On utilise aussi ce terme pour restaurer des fichiers
écrasés lors d’une fausse manipulation.
Risque : hasard que l’on court d’une perte ou d’un dommage. Peut
être aussi considéré comme un évènement potentiel engendrant des
pertes ou dommages. L’occurrence d’un risque résulte de l’application
d’une menace sur une vulnérabilité (voir ce mot).
SATAN : nom d’un outil d’analyse et de sécurité pour les

administrateurs de réseaux venant de l’anglais : Security
Administrator Tool for Analyzing Networks conçu par Dan Farmer et
Weitse Venema.
Script : séquence d’instruction exécutée par un programme ou par des

interpréteurs. Exemple : script de Java ou pour Active X.
Lexique 229
SIO : le Start input Output désigne le signal de début d’un processus

d’entrée/sortie qu’un canal reçoit.
Sinistre : rupture non souhaitée, dégageant des pertes potentielles par

rapport à un état antérieur considéré comme stable ou normal.
SSH : Secure Shell, le Shell sécurisé préconisé dans l’utilisation des

transactions délicates et confidentielles employant les RPC (Remote
Procedures Call) pour éviter le piratage.
SSF : version française à utiliser obligatoirement car toutes

transactions secrètes et utilisant le cryptage doivent être déclarées aux
gouvernements.
SSL : venant de l’anglais « Secure Socket level », le SSL est un

système de cryptage des données entre un navigateur et un serveur
Web.
Superviseur : (dans un système informatique), c’est l’ensemble des

modules du système d’exploitation qui gère le fonctionnement de
l’ordinateur et assure le bon déroulement des travaux des utilisateurs.
Les fonctions principales du superviseur sont : gestion des ressources
physiques, gestion des travaux, des données, des processus, des liens
entre les tâches, des anomalies et protection contre diverses erreurs de
manipulation ou d’accès aux ressources.
Superviseur : (dans un service d’audit), c’est la personne responsable

d’une mission d’audit et d’un ou deux auditeurs juniors. Il est le chef
de mission qui détermine ou valide le planning, les sites à visiter et
gère éventuellement le budget de ladite mission.
Système d’exploitation : c’est un ensemble de programmes exprimés

en langage machine binaire translatable (non résident) ou absolu
(résident) qui sont chargés dans l’ordinateur, et dont l’exécution
permet l’exploitation de ses ressources, de traiter automatiquement les
programmes utilisateurs. Appelé‚ aussi software ou logiciel de base,
dans un cas simple, ce système d’exploitation se réduit à un moniteur
de 2 à 5 kilo octets résidant en mémoire morte (surtout dans les micro-
ordinateurs).
Temps partagé : (Time sharing en anglais). Le traitement en temps

partagé est le mode d’utilisation d’un ordinateur en temps réel à
l’échelle humaine (réponse de l’ordre de quelques secondes).
Plusieurs utilisateurs se partagent le service de l’ordinateur dans une
même durée de temps. Chaque utilisateur a la sensation que toutes les
ressources de la machine lui sont accessibles.
Temps réel : (real time en anglais). Le système en temps réel est un

système permettant l’exécution rapide de processus et pouvant réagir
rapidement lors d’un changement de contexte ou d’un nouvel
évènement. L’utilisateur peut agir avec des paramètres en cas de
besoin. Système très utilisé dans un contexte de processus industriel.
VNC : issue de l’anglais « Virtuel Network Computing », ce terme

désigne les programmes ou utilitaires permettant d’utiliser un réseau
virtuel par l’administrateur afin de gérer ses systèmes distants.
Vulnérabilité : ensemble de conditions ou failles susceptibles de

favoriser la réussite d’une agression peut être vue comme un couple C
(cible, agression).
Web : en informatique, ce terme désigne la toile des réseaux. Il est

aussi utilisé pour identifier le réseau des documents HTML, reliés
entre eux et diffusés sur les différents serveurs de par le monde.
COLLECTION MANAGEMENT ET INFORMATIQUE
sous la direction de Nicolas Manson
Alain Amghar – Conduite opérationnelle des projets, 2004

Alain Berdugo – Guide du management des SI, 2001
Alain Berdugo – Le maître d’ouvrage du SI, 1997
Alain Berdugo et Pierre Aliphat – Systèmes informatiques de
l'entreprise, 1997
Gilles Blanchard et André Vincent– La fonction achat en
informatique et télécoms, 1999
Jean-Christophe Bonne et Aldo Maddaloni – Convaincre pour
urbaniser le SI, 2004
Jean-Pierre Briffaut – Processus d'entreprise pour la gestion, 2004
Didier Caron – Méthodes objet, 1997
Jean-Pierre Corniou – La société de la connaissance, 2002
Denis Debaecker – PLM — La gestion collaborative du cycle de
vie des produits, 2004
Bernard Debauche et Patrick Mégard – BPM, Business Process
Management, 2004
Alain Desroches et al. – La gestion des risques, 2003
Tru Dô-Khac – Externalisation des télécoms d’entreprise, 2005
Luc Dorrer – Hommes et projets informatiques, 2004
Philippe Fenoulière – Vers une informatique ouverte, 2004
Philippe Fenoulière – La qualité de l’informatisation, 1996
Franck Franchin et Rodolphe Monnet – Le business de la
cybercriminalité, 2005
Jean-François Gautier et Alan Fustec – Informatique de
compétition, 1997
Thierry Harlé et Florent Skrabacz – Clés pour la sécurité des SI,
2004
Pierre Jaquet – Les réseaux et l’informatique d'entreprise, 2003
II Collections sous la direction de Nicolas Manson
Gérard Jean – Urbanisation du business et des SI, 2000

Didier Joliot – Management des SI, 2003
Didier Joliot – Performances des SI, 2003
Henri Kloetzer – La maîtrise d'ouvrage des projets informatiques,
2002
Pierre Laigle – Dictionnaire de l’infogérance, 2000
Jean-Luc Lapon – La direction informatique et le pilotage de
l’entreprise, 1999
Bernard Le Roux et al. – Urbanisation et modernisation du SI,
2004
Pierre Maret – Ingénierie des savoir-faire, 1997
Jean-Pierre Meinadier – Le métier d'intégration de systèmes, 2002
Dominique Moisand – CRM, gestion de la relation client, 2002
Pascal Muckenhirn – Le SI décisionnel, 2003
Gilbert Nzeka – La protection des sites informatiques face au
hacking, 2005
Jean-Louis Peaucelle – Informatique rentable et mesure des gains,
1997
Dany Provost – An 2000, la transition réussie, 1998
Luc Rubiello – Techniques innovantes en informatique, 1997
Alain Rugy (de) – Management et gestion du parc micro, 1998
Jacques Sassoon – Urbanisation des SI — épuisé, 1998
Pascal Silvestre – Le développement des SI, 1996
Marcel Soberman – Développement rapide d'applications, 1996
Sys-com – La bascule du SI vers l’euro – 2ème édition, 2000
Philippe Tassin – Systèmes d'information et management de crise,
2005
Marc Thorin – L’audit informatique, 2000
Zouheir Trabelsi et Henri Ly – La sécurité sur internet, 2005
Collections sous la direction de Nicolas Manson III
Jean-Pierre Vickoff – Estimation et architecture des

développements Agiles, 2005
Jean-Pierre Vickoff – Systèmes d'information et processus Agiles,
2003
COLLECTION ETUDES ET LOGICIELS INFORMATIQUES
Alain Amghar et Frédéric Sitbon – Microsoft Office Project 2003,

2004
Yves Constantinidis – Le logiciel à valeur ajoutée, 2001
Yves Constantinidis – Outils de construction du logiciel, 1998
Erol Giraudy et al. – Le portail Microsoft Sharepoint, 2004
Guy Lapassat – Architecture fonctionnelle des logiciels, 2003
Guy Lapassat – Urbanisme informatique et architectures
applicatives, 2003
Jean-Pierre Meinadier – Ingénierie et intégration des systèmes,
1998
Michel Priem – Trafic et performances des réseaux multi-services,
2004
Jacques Printz et al. – Coûts et durée des projets informatiques,
2001
Jacques Printz – Productivité des programmeurs, 2001
Jacques Printz – Puissance et limites des sytèmes informatisés,
1998
Yvon Rastetter – Le logiciel libre dans les entreprises, 2002
Marcel Soberman – Les grilles informatiques, 2003
Sys-com – Stratégie de test e-business, 2001
Spyros Xanthakis et al. – Le test des logiciels, 2000
COLLECTION NOUVELLES TECHNOLOGIES INFORMATIQUES
Jean-Louis Bénard – Les portails d'entreprise, 2002

Jérôme Besancenot et al. – Les systèmes transactionnels, 1997
Christian Bonjean – Helpdesk, 1999
Jean-Pierre Briffaut – Systèmes d’information en gestion
industrielle, 2000
Jean-François Goglin – La cohabitation électronique, 2005
Jean-François Goglin – La construction d'un datawarehouse –
2ème édition, 2001
Jean-François Goglin – Le Datawarehouse, pivot de la relation
client, 2001
Jean-François Goglin et Philippe Usclade – Du client-serveur au
web-serveur, 1999
Marc Langlois et al. – XML dans les échanges électroniques, 2004
Bernard Manouvrier – EAI, Intégration des applications
d'entreprise, 2001
Norbert Paquel et Olivier Bezaut – XML et développement des
EDI, 2002
René-Charles Tisseyre – Knowledge Management, 1999
COLLECTION SYNTHÈSE INFORMATIQUES CNAM
Florent Bastianello – L’informatique, mémoire de l’entreprise,

1996
Jean-André Biancolin – Temps réel, 1995
Bruno Dardonville – Architecture de Windows NT, 1996
Hervé Guitter – La compression des images numériques, 1995
Renaud Hilleret – Stockage des données distribuées, 1996
Jean-Marc Lê – Les systèmes de télécoms mobiles, 1998
Lionel Mallordy – Répartition d’objets dans les bases de données,
1995
Christophe Pasquier – L'approche objet, 1995
Catherine Pérou – La dépense informatique en France, 1996
Ricardo Ruiz – Systèmes de gestion de bases de données orientés
objet, 1997
Laurent Schneider – Logiciels serveurs et outils d’administration
pour le web, 1997
Philippe Vetter – Calcul coopérant par passage de messages, 1995
Bernard Weiss – ATM, 1995
Bernard Zignin – Les techniques du multithread, 1996

Laudit Technique Informatique by Henri Ly

Transféré par

Droits d'auteur :

Formats disponibles

Laudit Technique Informatique by Henri Ly

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Laudit Technique Informatique by Henri Ly

Transféré par

Droits d'auteur :

Formats disponibles

L’audit technique informatique

Le Code de la propriété intellectuelle n'autorisant, aux termes de l'article L. 122-5, d'une

Collection Management et Informatique

La liste des titres de chaque collection se trouve en fin d’ouvrage.

Chapitre 1. Historique et nécessité de l’audit . . . . . . . . . . . . . . . . . . . 15

1.1. Management et système d’information . . . . . . . . . . . . . . . . . . . 15

Chapitre 2. Les contextes techniques pour les missions d’audit . . . . . . . 39

2.1. Les contextes techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.4. Classification générique des types d’audit . . . . . . . . . . . . . . . . . 59

Chapitre 3. Les diverses phases d’une mission d’audit . . . . . . . . . . . . . 67

3.1. Les diverses phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Chapitre 4. Les missions d’audit demandées

4.1. Audit de la politique informatique . . . . . . . . . . . . . . . . . . . . . . 87

Chapitre 5. Missions d’audit demandées par la Direction

Chapitre 6. Problème de sécurité et audits associés . . . . . . . . . . . . . . . 123

6.1. Plan de sécurité de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . 124

6.7.1. Phase de pré-audit et de planification (0,5 jour) . . . . . . . . . . 148

Chapitre 7. Plans types et exemples de procédures . . . . . . . . . . . . . . . 163

7.1. Plan type d’un programme de travail . . . . . . . . . . . . . . . . . . . . . 163

Annexe 1. Rappel des outils pour les auditeurs . . . . . . . . . . . . . . . . . . 191

A1. Rappel des outils pour les auditeurs . . . . . . . . . . . . . . . . . . . . . 191

Annexe 2. Démarche pour un plan de sécurité . . . . . . . . . . . . . . . . . . 197

Annexe 3. Fonctions illicites des programmes malveillants . . . . . . . . . . 201

A3. La fonction illicite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

A4. General principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Il devient impossible de lire un magazine, de regarder la télévision ou

Comment pallier ces dernières, comment protéger, détecter les points

Comprendre, apprendre, se former et s’informer ne sont-ils pas les

Ce livre sur la théorie et les pratiques de cette matière applique bien ce

– des FAQ et réponses permettant de mieux appréhender les concepts

D’autre part, la démystification d’un sujet complexe, assortie

L’ouvrage d’Henri Ly est bien conforme à cette démarche de

La connaissance est le début de l’action :

De nombreux théoriciens considèrent que l’entreprise est une « boîte

Pour fiabiliser ces moyens, il faut :

Ce sont les rôles des contrôleurs de gestion, de l’inspection, des

Ce livre n’a pas pour ambition de présenter une méthode universelle

Si cet ouvrage donne des informations nécessaires à un non-spécialiste

Historique et nécessité de l’audit

La rigueur vient toujours au bout de l’obstacle.

1.1. Management et système d’information

En matière de gestion d’entreprise, quelle que soit la nature juridique

ne peut être maintenue. En résumé, une activité de pilotage, pour un bon

Le système d’information de gestion d’une entreprise est formé par

A partir des informations internes ou externes de l’entreprise, le

Un système d’information peut être considéré comme un langage et un

Un système d’information de gestion est un système d’information qui

Prenons un exemple : le déclenchement d’une commande d’un client

Les volumes d’informations ne cessent de croître, et l’exigence de ces

fiables, cohérents et sécurisés. De ce fait, l’audit informatique a pris

Le noyau du système de gestion d’information qui constitue le

Un domaine est couvert par un ensemble d’indicateurs riche et

C’est dire l’impact du rôle que doivent jouer les vérificateurs,

Enfin les trois axes d’analyse du système d’information sont :

1.2. Rappel historique de l’audit

Depuis l’Antiquité, les hommes ont senti la nécessité d’utiliser un

Ainsi, le premier trait de comptabilité, en partie double, fut l’œuvre du

Cependant, il faut attendre la fin du XIXe siècle pour voir la naissance

Aux Etats-Unis, the Security Act de 1935, loi fondamentale sur le