Chapitre 1

L'audit informatique
Sommaire
I.Introduction.............................................................................4
II.Définition générale de la fonction informatique......................5
A.Caractéristiques...................................................................................................................5
B.Risques liés à l’organisation................................................................................................6
C.Techniques d’audit..............................................................................................................6
D.Limites de l’audit de la fonction informatique....................................................................6
III.Développement, installation, modification et intégrité du
système.....................................................................................8
A.techniques d’audit...............................................................................................................8
Développement...................................................................................................................8
Mise en place :....................................................................................................................8
Modification :......................................................................................................................8
Intégrité :.............................................................................................................................8
B.exemple de questionnaire....................................................................................................9
IV.Sécurité des accès physiques et logiques............................13
A.Risques sur les ressources logiques...................................................................................13
Questionnaire : organisation et sécurité des accès logiques :...........................................13
B.Risques sur les actifs informatiques .................................................................................16
Organisation et sécurité des accès physiques :..................................................................17
V.Exploitation...........................................................................21
A.Risques liés à l’exploitation .............................................................................................21
VI.Questionnaire : exploitation ............................................................................................22
VII.L’audit des traitements automatises...................................25
A.Contrôles programmes .....................................................................................................25
Modes de traitement :........................................................................................................25
B.Risques_specifiques_aux traitements automatises............................................................26
C.Objectifs d’audit ...............................................................................................................27
D.Procédures programmées de contrôle répondant aux objectifs d’audit ...........................28
Développement_des_procédures programmées de contrôle :...........................................28
Traitements automatisés et irrégularités...........................................................................28
Les enseignements des études sur les irrégularités :.........................................................28
E.Présentation de la méthodologie........................................................................................30
1ère_étape :_connaissance_de l’environnement...............................................................31
2ème étape: examen préliminaire....................................................................................32
3ème étape : évaluation préliminaire...............................................................................34
4ème étape : plan d’approche de l’audit .........................................................................35
5ème étape : tests de vérification du fonctionnement des contrôles.................................35
6ème étape : teste sur les données et/ou sur les soldes des comptes.................................36
7ème étape : évaluation finale...........................................................................................36
F.Contrôle de la comptabilisation achats fournisseurs, enregistrement des factures,
journalisation et centralisation..............................................................................................37
VI.Les techniques de contrôle basées sur l’informatique..........47
A.Techniques_d’audit informatique utilisant l’ordinateur ...................................................47
Avantages et limites :........................................................................................................47
B.Techniques_de_l’audit informatique ................................................................................47
Jeux d’essaie :...................................................................................................................47
Les testes intégrés :...........................................................................................................47
Les tests en parallèle :.......................................................................................................48
Sélection des donnés dans un fichier :.............................................................................48
C.Organisation de la mise en œuvre des tests informatisés..................................................49
Contraintes liées aux tests informatisés............................................................................49
Organisation :....................................................................................................................51
Dossier de travail :............................................................................................................52
VII.Systèmes experts et audit .................................................54
A.Présentation.......................................................................................................................54
B.L’environnement_des_systemes experts...........................................................................54
L’intelligence artificielle :.................................................................................................54
La connaissance :..............................................................................................................54
C.Approche générale des systèmes experts..........................................................................54
Définition :........................................................................................................................54
Objectifs des systèmes experts :........................................................................................54
Les outils de réalisation des systèmes experts :................................................................55
D.Les systèmes experts en audit ..........................................................................................55
Les systèmes experts généraux :.......................................................................................55
Les systèmes experts dans des domaines connexes :........................................................55
Systèmes experts directement liés à l’audit :....................................................................56
VIII.Conclusion : l’usage de l’informatique dans l’audit............57
IX.Bibliographie........................................................................58
I. Introduction
Pour procéder à l’évaluation des risques informatiques spécifiques à la fonction

informatique des guides d’audit sont proposés, les guides sont des instruments qui
doivent être adaptés à l’environnement informatique rencontré c'est-à-dire qu’il faut
les adapter des éléments susceptibles d’affecter la conduite et l’étendu de l’audit :
• Activités de l’entreprise,
• Taille de la fonction informatique,
• Degré de complexité de la configuration et de la sophistication
du système d’informations,
• Dépendance de l’entreprise vis-à-vis de la fonction
informatique.
II. Définition générale de la fonction informatique
La fonction informatique, tout comme les autres fonctions de l’entreprise doivent

suivre les règles de management c’est pour cette raison que l’audit de la fonction
informatique débute par la prise de connaissance de l’environnement et des règles
de gestion.
A. CARACTÉRISTIQUES
L’organisation informatique présente des particularités :

• Rattachement hiérarchique de la fonction informatique : Au fur
et à mesure que l’informatique se détache des fonctions purement comptables
et financiers, la direction informatique se transforme en direction de
l’information. La direction de l’information est alors rattachée à la direction
générale. Cette évolution traduit la reconnaissance de l’importance de la
fonction informatique dans l’entreprise.
• Direction de l’information et organisation : dans certaines
entreprises les informaticiens les responsabilités d’organisateurs sans avoir la
formation nécessaire. Il s’agit là d’une situation fréquente qui peut être la cause
de problèmes graves pour l’entreprise (projets avortés, mise en place
d’applications qui seront rejetées par les utilisateurs, etc.)
• Lien entre direction générale, Direction de l’information et
utilisateurs : les systèmes performants d’informations résultent d’une
collaboration équilibrée entre direction générale, direction de l’information et des
utilisateurs. Qu’un de ces trois groupes soit en position trop marquée de
leadership, et ce sont des options désastreuses qui peuvent être prises.
• Le comité informatique : il regroupe la direction générale, les
représentants des directions opérationnelles et fonctionnelles et la direction de
l’information, le comité se réunit une ou plusieurs fois par an ; les décisions font
objet d’un procès verbal la présence de la direction générale donne le poids
nécessaire aux actions dévolues à la direction de l’information.
• Le plan informatique formalise sur une période qui varie de
deux à cinq ans, les options exercées par le comité informatique. Ce plan est
actualisé au moins une fois par an, après discussion en comité informatique.
• Gestionnaire de base de données : en raison de la complexité
des problèmes à résoudre pour mettre en place et exploiter une base de
données a été développé. Son rôle est de coordonner et de superviser les
activités suivantes :
 Définition des données de base et conception de la structure de la base de
données.
 Maintien de l’intégrité, de l’exhaustivité et de l’exactitude des données;
 Maintien de la sécurité;
 Amélioration des performances;
 Assistance technique ;
B. Risques liés à l’organisation
Les risques liés à une organisation insuffisante de la fonction informatique

sont rappelés ci-dessous :
• Risques liés aux liaisons avec les utilisateurs : incohérence ou
insuffisance des stratégies de l’information et de la sécurité, configuration mal
adaptée aux besoins, évolution irrationnelle de la configuration,
développements, sans relation avec les besoins des utilisateurs.
• Risques liés à la mauvaise séparation des taches à l’intérieur
de la fonction, et procédures d’organisation insuffisantes : erreur, fraude,
malveillance, atteinte à la confidentialité, détournement de ressources,
inefficacité
• Risques liés à une insuffisance des procédures de gestion du
personnel : erreur, fraude, malveillance, atteinte à la confidentialité,
détournement de ressources, inefficacité
C. Techniques d’audit
• Les techniques d’audit permettant d’identifier les risques

relatifs peuvent être résumées ainsi :
• Entretiens avec le Directeur de l’information et les chefs de
service de la fonction informatique ;
• Prise de connaissance des procédures propres à la fonction
informatique dans fonctions
• Prise de connaissance des procédures propres à la fonction
informatique dans l’entreprise ;
• Analyse des liens entre la fonction informatique et les autres
fonctions de l’entreprise ;
• Examen des procès-verbaux du comité informatique et des
comités ad hoc ;
• Examen du plan informatique ;
• Prise de connaissance des procédures de gestion du
personnel informatique ;
• Observation « sur le terrain » que la mise en œuvre de
l’exercice des activités fonctionne en conformité avec les descriptions de
fonctions.
L’auditeur a le plus grand intérêt à comprendre l’histoire de l’informatique afin
d’apprécier son impact sur la fiabilité et l’efficacité du système d’informations.
D. Limites de l’audit de la fonction informatique
Les conclusions de l’audit de l’organisation générale informatique

doivent être analysées car c’est un phénomène bien connu que les organigrammes
et les descriptions de fonctions ne représentent pas forcément la réalité des
coutumes relationnelles de la fonction. Outre ce constat l’auditeur présent à l’esprit
certains risques latents propres à l’organisation informatique.
• Risques inhérents à la fonction de l’ingénieur système : de par
son domaine d’intervention l’ingénieur système a accès à toutes les ressources
informatiques, cette fonction s’exerce généralement sans contrôle, le directeur
de l’information ayant rarement une formation d’ingénieur système. Les
tentatives des auditeurs pour faire face à cette situation sont actuellement plutôt
inadéquates, la grande majorité des auditeurs informatiques n’ayant pas une
formation suffisante pour procéder au contrôle des activités exercées par les
ingénieurs systèmes. Certains auditeurs se satisfont de cette situation en se
faisant remarquer que l’ingénieur système s’il a accès à tout n’a pas une
formation comptable et financière suffisante pour tirer un profit personnel des
lacunes en matière de contrôle des applications.
• Organisation informatique: un organigramme et des
descriptions des fonctions tout à fait satisfaisantes sur le plan de la séparation
des fonctions peuvent cacher une situation dangereuse en l’absence ou
l’insuffisance des procédures d’accès par terminant aux ressources
informatiques. En effet, en l’absence de procédures adéquates d’accès une
personne peut très bien effectuer, de son terminal des tâches tout à fait
incompatible avec celle définit dans le descriptif de sa fonction.
Le contrôle de l’organisation générale de la fonction informatique dans le cadre

de l’audit financier de l’entreprise permet d’apprécier le degré de sensibilisation au
contrôle interne de la fonction, généralement plus la taille de l’entreprise est importante
ou l’activité dépendante de l’informatique et plus les standards de contrôle sont élevés
et de nature à prévenir les principaux risques liés à l’informatique.
Dans la pratique, l’auditeur doit considérer dans son appréciation qu’il ne peut
pas s’attendre à trouver les mêmes standards dans un centre informatique d’une
dizaine de salariés que dans celui de deux cents salariés pour cette raison l’auditeur
intervenant dans un centre de taille moyenne doit prendre en compte des éléments
plus difficiles à appréhender parce que plus subjectif en ce qui concerne notamment
pour la direction de l’information :
 l’intérêt pour le contrôle,
 l’autorité sur les collaborateurs,
 le souci de supervision
 le souci de dialogues avec les utilisateurs.
Le contrôle de l’organisation générale de l’informatique peut amener l’auditeur à
proposer des suggestions pour l’amélioration du contrôle interne.
L’auditeur doit moduler ces dernières en onction de la taille ou de l’activité de
l’entreprise. En effet, et ceci est une règle générale une recommandation n’a de valeur
pour le dirigeant que dans la mesure où elle est raisonnable par rapport à la taille et à
l’activité de l’entreprise ainsi que par rapport aux coûts complémentaires qu’elle
entraîne.
III. DÉVELOPPEMENT, installation, modification et intégrité du
système
A. Techniques d’audit
Les techniques varient bien évidemment, en fonction du domaine de l’intervention :
♦ DÉVELOPPEMENT
- Prise de connaissance de la méthodologie de développement par
entretiens, observations, examen du manuel des procédures et des
manuels de référence de la méthode (1) ;
- Inventaire des projets développés depuis le dernier audit ;
- Tests sur l’application de la méthodologie par examen de la documentation
portant, plus particulièrement, sur les documents suivants : Etude la
faisabilité, étude fonctionnelle, programmes (pour le respect des standards
de programmation et la mise à jour de la documentation), procès-verbaux
de recette.
- Intervention de l’auditeur pendant les phases de développement ;
- Examen des contrats lorsque tout, ou partie, du développement est assuré
par une SSII, ou remplacé par l’achat d’un logiciel.
♦ MISE EN PLACE :
- Prise de connaissance des procédures de transfert et de conversation par
entretiens, observations et examen du manuel des procédures ;
- Intervention de l’auditeur pendant la période de conversion. L’auditeur
précise à l’entreprise, avant la conversion, quels sont les documents dont il
aura besoin pour exercer ses contrôles ;
- Tests par l’examen de la documentation et des documents de contrôle de
l’entreprise.
♦ MODIFICATION :
- Examen du chrono de correspondance du chef du projet avec les
utilisateurs ;
- Prise de connaissance des procédures de modification par entretiens,
observations et examen du manuel de procédures ;
- Examen des coûts de modifications dans les imputations par centre de
coût ;
- Tests partant des modifications observées sur les programmes sources et
suivant le cheminement de la modification sur le plan procédural ;
- Examen des paramétrages du gestionnaire de bibliothèques ;
- Examen des journaux de gestionnaire de bibliothèques.
♦ INTÉGRITÉ :
- Prise de connaissance des procédures de protection de l’intégrité des
systèmes par entretiens, observations, examen du manuel de procédures
et du manuel de référence du gestionnaire de bibliothèques ;
- Tests par :
 Impression des tables d’accès aux ordres de contrôle et
programmes ;
 Impression des tables d’accès aux commandes et programmes
utilitaires permettant de modifier les ordres de contrôle et les
programmes;
 Examen du paramétrage du gestionnaire de bibliothèques ;
 Examen des journaux de console ;
 Examen des journaux du gestionnaire de bibliothèques.
L’auditeur externe prend connaissance, s’ils sont établis, des rapports du
gestionnaire de la sécurité, et/ou de l’audit interne informatique.
B. Exemple de questionnaire
COMMENTAIRES ET
QUESTIONS OUI NON RENVOI AUX FEUILLES
DE TRAVAIL
DEVELOPPEMENT
1. Les développements de système sont-ils
effectués selon une méthodologie ?
2. Cette méthodologie implique-t-elle
suffisamment les utilisateurs au niveau des
phases :
 Etude de faisabilité ?
 Etude fonctionnelle ?
 Recette ?
3. L’étude de faisabilité est-elle approuvée par
le comité informatique ?
4. La phrase étude fonctionnelle prend-elle en
compte :
 La philosophie des contrôles au
niveau de la fonction informatique ?
 La philosophie des contrôles
manuels et informatisés au niveau du
système ?
 Les procédures de sauvegarde, de
restauration et de reprise ?
 La formation nécessaire des
informaticiens ?
 La formation nécessaire des
utilisateurs ?
5. La phase étude fonctionnelle est-elle
approuvée par les utilisateurs ?
6. Les phrases d’analyse organique, de
programmation et de tests font-elles l’objet
de procédures minimisant les risques
d’erreurs, en utilisant par exemple des
méthodes standardisées de programmation
7. Pour les phases de recette provisoire, les
utilisateurs participent-ils réellement à la
mise au point des jeux d’essai ?
8. La recette provisoire des utilisateurs n’est-
elle donnée que lorsque les résultats sur
jeux d’essai sont satisfaisants ?
9. La recette provisoire des utilisateurs fait-elle
l’objet d’un procès verbal entre
informaticiens et utilisateurs ?
10. La documentation est-elle constituée au fur
et à mesure de l’avancement du projet dans
les phases de développement ?
11. En cas de développement de système sous
SGBD, les phases de développement sont-
elles coordonnées et supervisées par un
gestionnaire de données ou un technicien
ayant une formation suffisante. Ce
gestionnaire de données, ou technicien,
s’assure-t-il de l’efficacité du développement
en matière de :
 Définition des données ?
 Validation des données ?
 Définition des règles d’accès ?
 Définition des procédures de
sauvegarde et reprise ?
12.Les développements sont-ils mis au point
dans un environnement de tests, séparé de
l’environnement de production ?
13. En cas de développement d’application sous
infocentre, existe-t-il des procédures
suffisamment en matière de :
• Tests ?
• Documentation ?
• Autorisation ?
• Supervision ?
14. En cas de développement sur micro-
ordinateur, les utilisateurs élaborent-ils un
minimum de documentation ?
15. En cas de développement en PME/PMI, les
éléments fondamentaux suivants sont-ils
respectés :
• Cahier des charges ?
• Recette avec les utilisateurs ?
• Documentation ?
• Travail en parallèle ?
16. En cas de développements confiés à une
SSII, les éléments fondamentaux suivants
sont-ils respectés :
• Cahier des charges défini
conjointement avec l’entreprise ?
• Période d’essai en exploitation
normale ?
• Fourniture d’une documentation
conforme au C NC ?
• Protection suffisante en cas de la
fourniture de programmes limitée aux
programmes-objets ?
17. Les procédures de développement prennent-
elles en compte les réglementations en
vigueur :
• Code général des impôts ?
• Plan comptable général ?
• Décret du 29 novembre 1983 ?
• Loi Informatique et Libertés ?
18. Les procédures de modifications prennent-
elles également en compte les
réglementations en vigueur :
• Code général des impôts ?
• Plan comptable général ?
• Décret du 29 novembre 1983 ?
• Loi Informatique et Libertés ?
MISE EN PLACE
19. Existe-t-il un contrôle de l’intégralité du
transfert des programmes de
l’environnement de tests à l’environnement
de production ?
20. En cas de conversion, existe-t-il un contrôle
sur la « montée en charge » des fichiers ou
l’installation de la base de données ?
Si la réponse est oui à la question
précédente, le contrôle donne-t-il une
assurance suffisante que les données sur
les nouveaux fichiers sont :
• Exhaustives :
- Toutes enregistrées ?
- Toutes enregistrées dans la bonne
période ?
• Exactes : Validation suffisante sur
l’exactitude des données ?
21. Avant la recette finale, le nouveau système
a-t-il été suffisamment testé, notamment à
chaque fois que possible avec l’ancien
système comme système de référence ?
22. Les auditeurs internes participent-ils au
contrôle du processus de conversion ?
23. La recette finale donne-t-elle lieu à un procès
verbal ?
24. La documentation du système comprend-elle
des informations suffisantes sur les
domaines suivants :
 Contrôles sur le transfert dans
l’environnement de production ?
 Contrôles sur la montée en
charge des fichiers, ou
l’installation de la base de
données ?
 Contrôles sur les tests avant
recette finale du système par les
utilisateurs ?
MODIFICATION
25.Existe-t-il une séparation (ordinateurs de
tests, bibliothèques) entre les activités de
tests et de production ?
26. Si cette séparation peut ne pas être
respectée (« forcée ») pour des
modifications urgentes, les possibilités de
contrôle à postériori (supervision et journal
consol), sont-elles suffisantes ?
27. Toute modification fait-elle l’objet d’une
demande écrite des utilisateurs ?
28. Toute modification est-elle effectuée sur des
copies de programmes ?
29. Toute modification n’est-elle testée qu’avec
des jeux d’essai de l’environnement de tests,
ou avec des copies autorisées de fichiers
réels ?
30. La mise en production du ou des
programme(s) modifié(s) est-elle précédée
de l’accord du responsable hiérarchique du
programmeur et de l’utilisateur ?
31. Les documentations sont-elles mises à jour à
chaque modification :
 Analyse/Programmation ?
 Exploitation ?
 Utilisateur ?
 Eventuellement, documentations
relatives à :
- Base de données ?
- Réseau ?
- Sécurité ?
INTEGRITE
32. Existe-t-il des procédures assurant l’intégrité
des systèmes mis en production ?
33. Ces procédures permettent-elles des
contrôles suffisants dans les domaines
suffisants :
 Protection contre les accès non
autorisés ?
 Journalisation des modifications ?
 Correspondance entre programmes
d’exploitation sources et objets ?
34. Ces procédures font-elles l’objet d’un
contrôle périodique à postériori par une
personne indépendante, comme le
gestionnaire de la sécurité ou l’audit interne
informatique ?
35.Si ces procédures ont pour base l’utilisation
d’un gestionnaire de bibliothèques, les
options exercées permettent-elles de
satisfaire les contrôles mentionnés dans la
question précédente ?
IV. SÉCURITÉ des accès physiques et logiques
A. Risques sur les ressources logiques
Les risques pour accès non autorisés aux ressources logiques sont présentés
ci-dessous avec les conséquences pour l’entreprise.
RISQUES CONSEQUENCES
Erreurs causées par des « manipulations » Remise en cause progressive de l’intégrité
non autorisées mais sans intention de du système d’information.
nuire.
Fraudes entraînées par l’exploitation Pertes d’exploitation et financières,
intentionnelle des absences de contrôle du Remise en cause de la réputation de
système d’accès aux ressources logiques. l‘entreprise.
Chantage sur le contenu des informations Remise en cause de la réputation de
accessibles en mode lecture. l’entreprise ;
Infraction à la loi informatique et libertés.
Transfert d’informations commerciales et/ou Remise en cause de la compétition

techniques à la concurrence commerciale et/ou technique avec les
concurrents.
Destruction d’informations par effacement Remise en cause de la continuité
volontaire, ou involontaire d’exploitation ;
Remise en cause de la pérennité si non
réparable.
♦ QUESTIONNAIRE : ORGANISATION ET SÉCURITÉ DES ACCÈS

LOGIQUES :
Oui No Commentaires et
Questions n1 renvoi aux feuilles de
travail
1- Existe-t-il une stratégie de la sécurité des accès
logiques dans l’entreprise ?
2- Cette stratégie a-t-elle été développée par une
1
Lorsque la réponse non, il convient de procéder au travail suivant :
- identifier le risque et son impact sur la fiabilité des applications ;
- Proposer les recommandations pour l’élimination de ce risque.
équipe pluridisciplinaire se composant
d’informaticiens et d’utilisateurs ?
3- Cette stratégie a-t-elle été développée selon un
processus cohérent :
-Etude de faisabilité,
-Etude fonctionnelle,
-Programmation et tests,
-Mise à l’essai des utilisateurs en mode non
bloquant
-Mise en place définitive ?
4- cette stratégie est-elle périodiquement révisée
au fur et à mesure de l’évolution de la
configuration et/ou de la structure du système
d’information ?
5- Cette stratégie est-elle mise en œuvre et
supervisée par un gestionnaire de la sécurité
suffisamment indépendant de la fonction
informatique ?
PROCEDURE ET PREVENTION
6- Les fichiers programmes sensibles sont-ils
stockés hors site en dehors des périodes de
traitement.
7- Pour les systèmes fonctionnant sous SGDB,
est-ce que les gestionnaires de base de données
ne transfèrent aux programmes que les éléments
strictement nécessaires :
- Vue logique ?
- Eléments du dictionnaire ?
8- Les ressources logiques, y compris les
commandes et les programmes utilitaires,
auxquelles peuvent accéder les professionnels de
l’informatique par terminaux ou consoles sont-
elles affectées en accord avec les règles de
séparation des fonctions nécessaires à un bon
contrôle interne ?
Pour répondre à cette question, remplir le tableau suivant :

Ressources Personnel ayant Risque identifié Impact du risque sur les
logiques à la accès à ces applications
disposition des ressources
utilisateurs

auxquelles peuvent accéder les utilisateurs de
leurs terminaux, sont-elles affectées en accord
avec les règles de séparation des fonctions
nécessaires à un bon contrôle interne ?
utilisateurs

auxquelles peuvent accéder les utilisateurs de leurs
terminaux, sont-elles affectées en accord avec les
règles de séparation des fonctions nécessaires à
un bon contrôle interne ?
10- Si l’entreprise utilise des mots de passe, les
règles suivantes sont-elles suivies parr l’entreprise :
- Gestion des mots de passe par une personne

suffisamment indépendante, de préférence le
gestionnaire de la sécurité ?
- Le responsable des mots de passe, procède-t-
il régulièrement aux têtes suivantes :
• Maintenance avec les utilisateurs des
profils d’accès selon l’évolution de
l’entreprise ?
• Contrôle sur le respect des procédures
• Contrôle de la diffusion des mots de passe
aux utilisateurs ?
• Enquête sur les forçages ?
- Les procédures relatives aux mots de passe
assurent-elles une protection suffisante :
• Quatre caractères alphanumériques au
minimum ?
• Pas d’affichage à l’écran ?
• Difficilement reconstituable ?
• Changement au moins tous les mois ?
• Création selon un programme générant
des caractères au hasard ?
• Protection de l’accès aux tables d’accès ?
• Procédures de diffusion des mots de passe
garantissant un secret suffisant ?
• Déconnexion automatique des terminaux
après forçage, ou après les heures
normales de travail ?
11- Si l’entreprise utilise des techniques
encodage/décodage, existe-t-il des procédures
satisfaisantes de gestion des clefs ?
12- Existe-t-il des procédés de journalisation des

accès aux besoins de l’entreprise, selon le degré
de sensibilisation à l’erreur, à la fraude ou à la
malveillance du système d’information ?
13- Cette journalisation permet-elle d’analyser les

éléments suivants :
- autorisation des sollicitations (fichier,
programme,
transaction) ?
- localisation et fréquence des forçages ?
- changement des profils d’accès ?
PROCEDURES DE CONTROLE A POSRTERIORI
14- Existe-t-il des procédures permettant de

contrôler a posteriori l'intégrité du système
d'information ?

utilisateurs
MICRO-ORDINATEUR
15- Les micro-ordinateurs ayant accès à l'unité
centrale, sont-ils soumis à des règles de sécurité
suffisantes, lorsqu'ils peuvent lire ou mettre à jour
les ressources logiques ?
B. Risques sur les actifs informatiques
La mise en place d’une stratégie de l’organisation des actes logiques suppose un

travail d’équipe entre informaticiens et utilisateurs pour construire une architecture
des contrôles d’accès adaptée aux besoins de l’entreprise.
RISQUES CONSEQUENCES
Destruction partielle ou totale des actifs Remise en cause de la pérennité ;
informatiques, entraînant une rupture dans Perte d’une partie de la clientèle ;
la continuité des traitements. Perte d’exploitation ;
Perte financière ;
Réinvestissement, si l’entreprise est son
propre assureur, des actifs informatiques.
Remise en cause de la réputation de
Chantage sur le contenu confidentiel d’un l’entreprise ;
support magnétique volé. Infraction de la loi informatique et des
libertés.
Transfert d’informations commerciales et Remise en cause de la compétition
techniques à la concurrence. commerciale et technique avec des
concurrents.
Installation défectueuse du système Remise en cause de la fiabilité des
électrique et de la climatisation. traitements de l’intégrité des données.
Mise en cause de la responsabilité du chef
Non-respect des règlements relatifs à la d’entreprise ;
sécurité Non-versement des indemnités par les
assureurs pour non-conformité aux normes.
Des causes de nature très différente sont la source des risques présentés. L’origine
de ces dommages peut être interne à l’entreprise, comme le feu, ou externe, comme
le sabotage. Les causes des dommages sont également regroupées par catégories :
- Accès physique aux actifs de l’informatique non contrôlés ;
- Incendie ;
- Dégâts des eaux ;
- Installation ou fonctionnement défectueux du système de climatisation ;
- Alimentation ou fonctionnement défectueux du système de climatisation ;
- Alimentation électrique défectueuse ;
- Mouvements sociaux
Une alimentation électrique et/ou le fonctionnement défectueux de la climatisation
peuvent être la cause d’une atteinte à l’intégrité du système d’information (perte
d’informations, modifications, modification du contenu des mémoires, impressions de
résultats de calculs erronés, destructions des supports d’informations).
Des mouvements sociaux déclenchés soit à la suite d’une grève, soit à la suite d’un
mouvement (campagne contre une entreprise polluante, par exemple) peuvent être
la cause d’une action de vengeance sur les actifs informatiques.
♦ ORGANISATION ET SÉCURITÉ DES ACCÈS PHYSIQUES :
Questions oui Non Commentaires et

renvoi aux feuilles
de travail
1. Existe-t-il une stratégie de la sécurité portant sur
la protection :
- Des accès physiques ?
- Des procédures de sauvegarde, restauration et
reprise ?
- Un plan de sauvegarde en cas en cas de
destruction
du patrimoine informatique physique.
2. Cette stratégie a-t-elle été développée par des

professionnels compétents déformation différente en
ce qui concerne :
- sécurité dite logique
- la sécurité dite physique
3. La sécurité physique est-elle coordonnée et
supervisée par le responsable de la sécurité générale
de l'entreprise, en liaison avec le gestionnaire de la
sécurité ?
4. La sécurité logique relative aux procédures de
sauvegarde et au plan d’urgence est-elle coordonnée
et supervisée par le gestionnaire de la sécurité ?
5. Cette stratégie a-t-elle été développée selon un
processus cohérent, comportant au minimum une
étude de faisabilité et une implication suffisante des
utilisateurs ?
6. Cette stratégie est-elle périodiquement révisée
pour tenir compte de l'évolution de la configuration
et/ou de la structure du système d'information ?
ACCES PHYSIQUES :
7. Existe-t-il des procédures limitant l'accès physique
aux actifs informatiques :
- Les utilisateurs ne sont pas admis dans les locaux
de l’informatique,
- Les pupitreurs n’ont pas accès à la bandothèque,
- Les pupitreurs, seuls, ont accès à la salle machine,
- les tiers accédants aux locaux informatiques font
l’objet d’une autorisation préalable,
- les documentations ne sont accessibles qu’aux
personnes autorisées :
• documentation analyste/programmation
• documentation exploitation
• documentation réseau
• documentation base de données,

• documentation sécurité ?
8. Les procédures d’accès physique sont-elles
renforcées par des systèmes de badge, de carte
magnétique ou de code ?
Décrire le système :
…………………………………………………………..
…………………………………………………………..
…………………………………………………………..
…………………………………………………………..
9. La gestion du système retenu est-elle satisfaisante
pour traiter les problèmes suivants :
-Vol ?
- Démission, licenciement ?
- Changement périodique des codes ?
10. Le système de protection des accès physiques
assure-t-il une protection 24 heures sur 24 par des
procédés d'alarme ou de gardiennage ?
11. Les ressources physiques de la fonction
informatique sont-elles installées dans des locaux
difficiles d'accès ?
12. En cas de crise (mouvements sociaux, par
exemple, les accès aux locaux informatiques
peuvent-ils être fermes rapidement ?
INCENDIE
13. L'entreprise a-t-elle pris des mesures préventives
au moment de l'implantation des ressources
physiques informatiques ?
14. L’entreprise a-t-elle mis en place un système de
détection :
- détecteur de fumée ?
- détecteur de chaleur ?
15. L’entreprise a-t-elle des moyens de combattre
l’incendie en réduisant au maximum les dégâts ;
- CO²
- gaz halon
16. Existe-t-il des instructions incendie suffisamment
connues du personnel informatique :
- interdiction de fumer ?
- volume de papier maximal acceptable à la salle
machine ?
- Nettoyage périodique, y compris dans les faux
planchers ?
- actions à suivre en cas d’incendie ?
- etc. ?
17. les instructions incendie font-elles l’objet d’une

formation adéquate et d’exercices périodiques ?
18. Existe-t-il des procédures suffisantes permettant
de prévenir ou de limiter des dégâts des eaux :
- implantation adéquate ?
- détecteur de niveau d’eau dans les faux planchers ?
- faux planchers en pente ?
- etc. ?
ALIMENTATION ELECTRIQUE
19. Le système d’alimentation électrique est

conforme aux règlements et normes en vigueur ?
20. L’installation comprend elle un transformateur
d’isolement et un régulateur de tension pour se
prémunir des variations du courant électrique ?
21. L’installation permet-elle la continuité de
l’exploitation en cas de coupure électrique :
- Volant d’inertie ?
- Onduleur + batterie ?
- Onduleur + batterie +groupe électrogène ?
PROCEDURE DE SAUVEGARDE ET DE
RESTAURATION ?
22- Existe-t-il des procédures formalisées de
sauvegarde et de restauration ?
23. Les procédures de sauvegarde sont-elles
adaptées aux besoins de l’entreprise ?
24. La périodicité des sauvegardes est-elle adaptée
aux besoins de l’entreprise ?
25. Pour les applications considérées comme vitales
est-il procédé à une duplication des sauvegardes ?
26. Un historique suffisant des jeux de sauvegarde
est-il conservé ?
27. Existe-t-il des procédures de stockage de
sauvegarde hors site ?
28. Le stockage hors site est-il en dehors des locaux
de la fonction informatique ?
29. Le stockage hors site est-il des consignes
suffisamment précises pour mettre en œuvre
correctement les restaurations ?
30. L’exploitation a-t-elle des consignes suffisamment
précises pour mettre en œuvre correctement les
restaurations ?
31. Les procédures de sauvegarde et de restauration
font-elles l’objet d’un contrôle périodique a posteriori
par l’audit interne et/ou le gestionnaire de la
sécurité ?
PROCEDURE DE REPRISE ET DE PLAN DE
SAUVEGARDE
PROCEDURE DE REPRISE
33. Existe-t-il, selon les spécificités de l’entreprise,

des procédures de reprise adaptées :
- A chaud ?
-A froid ?
34. Les procédures de reprise sont-elles

périodiquement testées ?
PLAN DE SAUVEGARDE
35. Les possibilités et les conséquences d’une

exploitation en mode dégradé ont-elles fait l’objet
d’une étude portée à la connaissance à la Direction
Générale ?
36. Existe-t-il un plan de sauvegarde ?

37. Le plan de sauvegarde prend-il pour base une
étude sur l’aspect vital ou non des applications ?
38. La direction générale et les représentants des

principaux utilisateurs ont-ils été impliqués dans la
conception du plan de sauvegarde ?
39. Le choix du mode d’ordinateur de secours a-t-il
été supporté par une étude coût/efficacité ?
V. Exploitation
A. Risques liés à l’exploitation
Le tableau ci-dessous présente les risques associés à l’exploitation et les

conséquences pour l’entreprise :
Risques Conséquences
Organisation insuffisante ou inappropriée Remise en cause de l’intégralité du système
pour prévenir : erreurs- fraudes- chantages d’information ;
-atteinte à la confidentialité- destruction Pertes d’exploitation et financière ;
partielle, ou totale, des ressources Remise en cause de la continuité de
physiques et/ou logiques. l’exploitation ;
Remise en cause de la réputation et de la
concurrence.
Procédure d’exécution insuffisante ou

inappropriée pour prévenir : erreurs -IDEM-
-fraudes- chantages- atteinte à la
confidentialité- destruction partielle, ou
totale, des ressources physiques et/ou
logiques.
Procédure de contrôle insuffisante ne -IDEM-

permettant pas de détecter a posteriori :
erreurs- fraudes -chantages- atteinte à la
confidentialité- destruction partielle, ou
totale, des ressources physiques et/ou
logiques.
Remise en cause de l’intégralité du système

Maintenance préventive insuffisante d’information ;
entraînant un pourcentage anormal
d’erreurs. Coût de l’exploitation des ressources
informatiques trop élevé par rapport aux
Disponibilité de l’ordinateur mal gérée. possibilités théoriques du matériel.
VI. Questionnaire : exploitation
Questions Oui Non Commentaires et renvoi aux

(1) feuilles de travail
ORGANISATION DE L'EXPLOITATION
1. Les règles d'administration de
l'activité exploitation sont-elles
consignées dans un manuel de
procédures ?
2. Ce manuel de procédures prévoit-il,
notamment :
Une séparation entre les activités
développement et exploitation ?
- Une séparation des taches
d'exploitation et de contrôle au
sein de l'activité exploitation ?
- Une interdiction absolue aux équipes

d'exploitation de corriger des erreurs ?
Une interdiction absolue aux
équipes d'exploitation de modifier
des procédures, programmes et
le contenu de fichiers ?
Une fonction indépendante de

bandothécaire lorsque la taille de
la fonction informatique le
justifie ?
Des consignes en cas

d'incidents ? Des consignes
en cas de sinistres ?
Une rotation à l'intérieur des

équipes d'exploitation ?
- Un accès limite à la documentation

d'exploitation ?
3. Lorsque l'ingénieur système est
rattaché à l'exploitation, quels
contrôles le responsable de
l'exploitation exerce-t-il ?
(1) Lorsque la réponse est non, il convient de procéder au

travail suivant : - identifier le risque et son impact sur la
fiabilité des exploitations; - proposer des
recommandations pour l’élimination de ce risque.
Questions Oui Non Commentaires et renvoi aux
feuilles de travail
4. Le manuel général des procédures de
l'exploitation est-il accompagné
d'instructions pour l'exploitation des
applications ?
5. Les instructions d'exploitation pour les
applications comprennent-elles,
notamment :
- Un descriptif du flux d'application

? - Les procédures de
paramétrage ? - La liste des
fichiers nécessaires ?
- Les procédures de sauvegarde, de

restauration et de reprise ?
6. Les instructions d'exploitation pour les
applications sont-elles à jour ?
EXECUTION ET
CONTROLES DES
TRAITEMENTS
PLANNING
7. Les travaux sont-ils lances selon un
planning strict pour lequel toute
modification doit être préalablement
autorisée ?
8. La gestion du planning n'est-elle pas
accessible aux équipes
d'exploitation ?
PREPARATION
9. La fonction de préparation est-elle
accessible aux pupitreurs ?
10. Existe-t-il une fonction de gestion
des supports magnétiques
amovibles permettant :
Une identification externe ou
interne des bandes ?
Une gestion des supports selon

leur(s) caractéristique(s) ?
- Une journalisation des mouvements

des supports ?
Un accès contrôle à la
documentation ? Un accès
contrôle aux supports ?
ALLOCATION DE RESSOURCES
11. Existe-t-il des procédures
d'allocation des ressources
permettant de prévenir les incidents
?
EXECUTION
12. Les activités de l'exploitation sont-
elles enregistrées :
- Application par
application ? - A chaque
incident ?
CONTROLE DE L'EXECUTION
13. La cellule contrôle a-t-elle mis en
place des procédures suffisantes de
contrôle sur l'exhaustivité des
traitements ?
14. Les procédures de distribution des
informations produites par la
fonction informatique sont-elles
adéquates eu égard aux spécificités
de l'entreprise ?
SUPERVISION DE L'EXECUTION
15. Le journal console, ou un produit
programme complémentaire, est-il utilisé
à des fins de contrôle a posteriori :
Temps d'exécution ?
L'utilisation des
programmes ? -
L'utilisation des fichiers ?
Contrôle des traitements
finissant anormalement ?
GESTION DE LA MAINTENANCE
16. La périodicité des visites de

maintenance est-elle suffisante pour
une prévention efficace ?
VII. L’audit des traitements automatises
A. Contrôles programmes
La direction générale attend des traitements automatisés qu’ils gèrent le système

d’information en respectant des critères qualitatifs bien établis
 Assurer un traitement complet et exact des données autorisées ;
 Respecter la réglementation ;
 Assurer la continuité de l’exploitation par des procédures adéquates de
sauvegarde, de restauration et de reprise ;
 Assurer une utilisation efficace des ressources de l’entreprise.
Les intervenants des auditeurs internes comme des auditeurs externes dans les
missions d’audit opérationnel couvrent tous les objectifs évoqués, par contre
l’auditeur externe intervenant dans le cadre du commissariat aux comptes est
uniquement préoccupé par les trois premiers objectifs. Les problèmes relatifs au
respect de la réglementation et à la continuité de l’exploitation ont été précédemment
traités. En conséquence, ne sont développés ici que les problèmes relatifs aux
procédures visant à assurer un traitement complet et exact des données autorisées.
Une application informatisée est considérée comme assurant une exécution
complète, exacte et autorisée des traitements, lorsque celle-ci a été conçue puis
mise en œuvre dans un environnement capable de prévenir ou de détecter la
réalisation d’erreurs ou d’irrégularités.
L’erreur peut être définie comme une anomalie ayant pour origine une action non
intentionnelle et l’irrégularité comme une anomalie ayant pour origine, une action
intentionnelle, l’irrégularité portant le plus souvent sur :
 la manipulation, la falsification ou l’altération d’enregistrements ou de
documents ;
 Le détournement d’actifs ;
 La suppression ou l’omission des effets normaux des enregistrements ;
 L’enregistrement de données fictives ;
 La mauvaise application des procédures en vigueur dans l’entreprise.

Les contrôles généraux représentent la volonté générale en matière de contrôle de
l’entreprise, cette volonté se traduit par un ensemble de procédures : organigramme
et description de fonctions, manuels de procédures, contrôle budgétaire, système de
comptes rendus périodiques, audit interne, compétence du personnel.
L’étude des contrôles programmés est centrée sur les objectifs de l’auditeur selon les
modes de traitements et les risques qui leur sont associés.
♦ MODES DE TRAITEMENT :
Traitement par lots :
Le traitement par lots est défini comme étant le traitement suivant lequel les
programmes à exécuter ou les données à traiter sont groupés par lot. La
caractéristique essentielle des traitements par lots est que la mise à jour des fichiers
n’est pas immédiate.
Pour mettre à jour un ou des fichiers, il faut procéder successivement à la réalisation
des phases de saisie, de validation, de recyclage des anomalies et finalement de
mise à jour.
En raison du caractère séquentiel de ce mode de traitement, le chemin de révision
est généralement facile à suivre pour l’auditeur.
Traitement en temps réel :

Le traitement en temps réel est un mode de traitement qui permet l’admission des
données à un instant quelconque et l’obtention immédiate des résultats.
Un des avantages de ce mode de traitement est de permettre une validation
immédiate des données de saisie par confrontation, pour contrôle et cohérence, avec
les informations de fichiers en ligne.
Traitement en réel différé :

Ce mode de traitement est caractérisé par une validation de la saisie en temps réel
et une mise à jour différée en traitement par lots.
Lorsque le besoin d’information immédiate est important pour les utilisateurs, une
programmation appropriée permet, lorsque l’utilisateur interroge les fichiers, de
recevoir une information à jour même si les fichiers ne sont pas encore réellement
mis à jour.
Ce traitement est très répandu parce qu’il facilite en fait les procédures de
sauvegarde, de restauration et de reprise.
B. Risques_specifiques_aux traitements automatises
Les phases manuelles et informatisées des traitements peuvent être la cause de

risques d’erreurs et d ‘irrégularité en cas d’insuffisance de contrôles.
Etapes du flux manuel Causes d'erreurs ou d'irrégularités Risques

et informatisé des
traitements
1- Préparation * perte physique de documents pendant le *Traitement incomplet
transfert
*Absence de revue préalable des *Traitement inexact
documents du lot.
*Insuffisance des informations saisies sur *Traitement inexact
le lot pour les contrôles ultérieurs.
2- Saisie et validation
Déconnectées de l'unité *Absence d'autorisation préalable *Traitement non

centrale autorisé, introduction de
données fictives
En ligne avec transfert *Insuffisance de contrôle sur transfert des *Traitement incomplet
par télécommunication données par télécommunication ou inexact
En ligne *Absence d'autorisation préalable *Traitement non

autorisé, introduction de
données fictives
*Traitement inexact
Dégradation de l'intégrité
du système d'information
3- Traitement de *Insuffisance des procédures de *Traitement inexact

validation après saisie validation
*Dégradation de
l'intégrité du système
d'information
*Insuffisance des procédures de *Traitement incomplet
recyclage des anomalies
4- Traitement de mise à *Insuffisance des procédures
jour d'autorisation
*Insuffisance des procédures de contrôle *Traitement inexact
de l'exécution
*Dégradation de
l'intégrité du système
d'information
*Insuffisance des procédures de contrôle *Pas de contrôle

a posteriori possible a posteriori
*Pas de chemin de révision *Difficultés
5- Traitements
Tri
Fusion *Insuffisance des procédures de contrôle *Traitement inexact
Calcul de l'exécution
6- Traitements d'édition *Absence de contrôle sur la fiabilité des *Traitement incomplet
informations produites par l'informatique
*Distribution à une personne ou à un *Atteinte aux intérêts de
service non autorisé l'entreprise par suite de
la divulgation des
informations
stratégiques ou
confidentielles
*Distribution tardive *Perte d'efficacité
C. Objectifs d’audit
Ces objectifs sont présentés sous forme de questions auxquelles il faut répondre.
Objectif d’existence :
Toutes les données saisies et traitées sont-elles réelles ?
Objectif d’exhaustivité :
Toutes les données saisies sont-elles enregistrées et traitées ?
Objectif d’évaluation :
Toutes les données saisies et traitées sont-elles correctement évaluées ?
Objectif de comptabilisation :
Toutes les données enregistrées sont-elles correctement comptabilisées ?
D. PROCÉDURES programmées de contrôle répondant aux objectifs
d’audit
Certaines procédures programmées de contrôle peuvent concourir satisfaire

conjointement à plusieurs objectifs.
1-Existence
Toutes les données saisies et traitées sont-elles réelles ?
2-Exhaustivité :
Toutes les données saisies sont-elles enregistrées et traitées ?
3-Evaluation :
Toutes les données saisies et traitées sont-elles correctement évaluées ?
4-Comptabilisation :
♦ DÉVELOPPEMENT_DES_PROCÉDURES PROGRAMMÉES DE
CONTRÔLE :
La stratégie ou la philosophie de contrôle d’un système ou d’une application doit être
développée au moment de l’analyse fonctionnelle avec une implication suffisante des
utilisateurs. La participation des utilisateurs se justifie pour deux raisons
essentielles :
• Les utilisateurs sont responsables de l’exactitude et de
l’intégrité des données , la fonction informatique étant responsable de la bonne
exécution des traitements demandés et approuvés par les utilisateurs ;
• Les informations ont une tendance naturelle à ne programmer
que les contrôles indispensables sur le plan technique comme la vérification des
zones numériques par exemple ;
• Les systèmes en temps réel notamment ceux sous SGBD
entraînent une migration des contrôles du fait qu’une donnée partagée entre
plusieurs services fait l’objet d’une validation commune.
Dans cette approche, le choix parmi les contrôles possibles est réalisé en fonction
des coûts, des performances attendues, des besoins de sécurité…
♦ TRAITEMENTS AUTOMATISÉS ET IRRÉGULARITÉS

En matière de conception de contrôle, l’examen des enquêtes informatisé présente
un intérêt certain :
• Pour la Direction Générale, c’est le moyen d’identifier les faits
générateurs de risques et d’adapter en conséquence l’organisation des
procédures de contrôle de l’entreprise.
• Pour l’auditeur, c’est le moyen de développer des procédures
d’audit qui donnent une assurance raisonnable que les comptes annuels sont
correctement établis.
♦ LES ENSEIGNEMENTS DES ÉTUDES SUR LES IRRÉGULARITÉS :

Sur la base d’une enquête établie en Angleterre, quelques axes de réflexion peuvent
être dégagés sur la fraude dans un environnement informatisé. Cette enquête a
porté sur un large échantillon d’entités commerciales, financières et publiques :
Entités Nombre de réponses Pourcentage de
réponses
Commerciale 185 67%
Financière 46 78%
Du secteur public et de l’Université 88 85%
319
Est considérée comme une fraude dans cette enquête toute irrégularité commise à
l’occasion d’une faiblesse de contrôle interne dans le flux manuel et informatisé
d’une application.
a- Localisation de l’irrégularité :
Nombre de cas Livre Sterling
Entrée 42 858.1710
Sortie 2 3.600
Programme 1 26.000
Détournement de ressources 22 17.379
67 905.149
La première conclusion de l’analyse du tableau ci-dessus porte sur l’importance que
le chef de l’entreprise et l’auditeur doit apporter à la qualité des contrôles de
validation à l’entrée du flux informatisé.
Le fait qu’il y ait une seule erreur purement informatique ne permet pas de conclure
de façon absolue à l’absence de risques informatiques, ceci pour plusieurs raisons :
 Le risque informatique est plus difficile à détecter ;
 Les risques nouveaux causés par le développement des télécommunications,
l’infocentre, la généralisation de la micro-informatique ne seront connus
qu’avec un certain retard ;
 D’autres enquêtes donnent des informations différentes sur la fraude
purement informatique.
Nombre de cas
Entrée 27
Modifications sur le fichier 5
Modifications sur le programme 6
Exploitation incorrecte 4
Divers et inconnus 4
46
b- Types des irrégularités commises à l’entrée :
Applications Nombre de cas Livre Sterling
Décaissements 6 401.225
Stocks 5 256.297
Avoir 5 97.458
Paie 16 61.487
Comptes personnel 10 41.703
42 858.170
La sensibilité à l’irrégularité de ces applications n’étonnera pas le lecteur. Des
procédures strictes de contrôle sur les applications générant des lettres chèques et
les bulletins de paie sont indispensables. Pour les stocks, l’auditeur doit veiller à
l’existence d’analyses régulières des écarts par une personne d’un niveau
hiérarchique suffisant. D’autres études confirment les données ci-dessus.
Applications Dollars
Stocks 1.300.000
Règlements aux fournisseurs 324.000
Règlements aux employés 139.000
Autres 49.000
1.945.000
c- Détournement de ressources :
Activités irrégulières Nombre de cas Livre Sterling
Travail pour le compte de l’informaticien 12 16.339
Vol de logiciels 4 1.000
Vol de documents en sortie 2 40
Sabotage 3 ?
Attente à la confidentialité 1 ?
22 17.379
d- Durée de la fraude :
Durée Nombre de cas Livre Sterling
Inconnue 20 119.366
Jusqu’à 1 an 26 125.673
2 ans 18 644.874
3 ans 2 5.236
4 ans 1 10.000
Plus de 4 ans ? ?
67 905.149
e- Conclusion :
Les contre-mesures suivantes sont généralement proposées par les auditeurs :
 Renforcement des contrôles de validation ;
 Renforcement des contrôles sur les applications sensibles ;
 Procédures d’analyse sur les écarts d’inventaire ;
 Procédures d’analyse de la vraisemblance des résultats ;
 Procédures de gestion rigoureuses dans le centre informatique.
E. PRÉSENTATION de la méthodologie
L’audit des traitements automatisés a pour objectif l’appréciation de la probabilité des

procédures de contrôle à prévenir ou à détecter les risques d’erreurs ou
d’irrégularités significatives dans un flux de données générant des écritures
comptables qui seront la base de l’établissement des comptes annuels.
L’appréciation de la probabilité d’erreurs et d’irrégularités est conduite sur la base
d’une confrontation des caractéristiques de contrôle d’une application avec les
objectifs d’audit de l’auditeur.
Aux objectifs d’audit attendus de tout contrôle interne (existence, exhaustivité,
évaluation et comptabilisation) doit être rajouté l’objectif plus général de la protection
du patrimoine et du respect des textes en vigueur. Pour être réalisé, ce dernier
objectif suppose que l’organisation de la fonction informatique respecte les points
suivants :
 Respect de la loi informatique et libertés pour les applications gérant des
informations nominatives,
 procédures d’accès aux fichiers, programmes et transactions conformes au
principe de séparation entre les fonctions incompatibles,
 procédures de sauvegarde, de restauration et de reprise assurant la continuité
d’exploitation,
 plan de sauvegarde assurant la pérennité de l’entreprise, si l’application est
jugée vitale.
Les risques d’erreurs propres à une application dépendent en grande partie du
caractère répétitif, ou non, du traitement des données. Les applications répétitives
comme la facturation par exemple, font généralement l’objet de procédures de
contrôle, de prévention et de détection plus développées que les applications non
répétitives utilisées une fois par an, ou par trimestre comme le calcul des
amortissements et la valorisation des stocks. Cette différence au niveau des risques
potentiels, tient au fait que les procédures des applications non répétitives sont
souvent moins bien connues par le personnel de l’entreprise et présentent, de ce fait,
plus de risque pour l’auditeur, d’autant qu’elles sont souvent à l’origine des données
significatives pour l’établissement des comptes annuels.
La méthodologie qui sera présentée a pour objectif de permettre :
-une probabilité d’identification raisonnable des risques d’erreurs et d’irrégularités ;
-une adaptation des tests de vérification en fonction des risques identifiés.
♦ 1ÈRE_ÉTAPE :_CONNAISSANCE_DE L’ENVIRONNEMENT

Au cours de cette phase, l’auditeur rassemble les éléments généraux nécessaires à
la compréhension de l’environnement de l’application et à la détermination de la
qualification professionnelle de l’auditeur devant analyser le flux informatisé de
l’application.
Cette prise de connaissance porte sur les domaines suivants :
• appréciation de l’impact sur l’application des contrôles
généraux et des contrôles de la fonction informatique de l’entreprise : l’auditeur
doit considérer qu’un environnement général favorable au contrôle interne n’est
pas une garantie suffisante d’une absence totale des risques ; par contre, à
l’inverse, des contrôles insuffisants, par exemple au niveau de la fonction
informatique, peuvent être directement, ou indirectement, la cause de risques
sur une application.
• évaluation de l’impact sur l’application des procédures
d’autorisation permettant d’intervenir dans le flux manuel et informatisé des
données : cette appréciation porte sur l’examen des organigrammes, des
descriptions de fonctions et des profils d’accès. Le risque lié à des
incompatibilités entre fonctions ou actions doit être pris en compte dans
l’évaluation des risques propres à une application. Par exemple, serait de
prendre en compte l’impact sur le système de comptabilité générale, le fait que,
dans une entreprise, le menu des opérations diverses soit accessible à
l’ensemble du personnel comptable.
• identification des changements apportés à l’application,
depuis le dernier audit, susceptible d’avoir un impact sur les données jugées
comme significatives : le flux informatisé est souvent sujet à changement. En
conséquence, un chemin de révision conservant l’historique des modifications
aux programmes des applications prend ici toute son importance.
• identification de l’importance et de la complexité de la partie
informatisée de l’application : l’auditeur recherche si l’application fait appel à des
procédures d’informatisation très simples, du genre traitement par lot, ou au
contraire très complexes, du genre traitement en temps réel avec SGBD et
réseau, du domaine d’un auditeur ayant reçu une formation appropriée.
A la fin de cette étape, l’auditeur est en mesure de déterminer s’il doit se faire
assister d’un auditeur spécialisé en audit informatique, voire même d’un expert
informatique extérieur au cabinet.
A la fin de cette prise de connaissance, l’auditeur peut décider qu’il ne pourra pas
s’appuyer sur les procédures programmées de contrôle de l’application en raison des
insuffisances des procédures de contrôle de la fonction informatique et/ou des
procédures d’accès. Dans cette hypothèse, l’auditeur doit pourtant procéder aux
phases d’examen et d’évaluation préliminaires. En effet, les éléments collectés au
cours de ces phases permettent à l’auditeur d’identifier avec plus de précision les
risques théoriques de l’application et de concevoir en conséquence un plan de tests
spécifiques, c’est-à-dire adapté à la nature des risques et à leur impact sur la
régularité et la sincérité des comptes annuels.
♦ 2ÈME ÉTAPE: EXAMEN PRÉLIMINAIRE

Cet examen a pour objectif de centraliser toutes les informations nécessaires à
l’évaluation préliminaire des risques liés à l’application :
 identification des données significatives et compréhension des étapes de
traitements ;
 identification par l’auditeur des procédures de contrôle nécessaires ;
 identification des procédures de contrôle mises en place par l’entreprise.
• Identification des données significatives et compréhension

des étapes de traitements :
Les données significatives sont identifiées par l’analyse des documents
d’entrée/sortie et des dessins des fichiers essentiels aux traitements de l’application.
Dans le flux manuel ou informatisé d’une application, une multitude de données sont
traitées mais, généralement, seules quelques données sont significatives pour la
conduite d’un audit comptable et financier (numéro de compte, quantité, montant,
date, etc.).
La compréhension de l’application est généralement réalisée par entretiens,
observations, analyse des documents entrée/sortie et des menus et examen de la
documentation des utilisateurs et des informaticiens. Lorsque l’entreprise utilise un
dictionnaire de données, des informations très utiles pour l’auditeur peuvent être
obtenues par interrogation de ce dictionnaire :
 nom des données ;
 description des données (alphanumérique, numérique, longueur de zone,
etc.) ;
 identification de la personne responsable, de la protection de l’intégrité d’un
groupe de données ;
 définition des procédures de validation ;
 identification des programmes et des transactions associées à une donnée.
En ce qui concerne les étapes de traitement, les informations doivent être
collectées :
 périodicité des traitements : jour, mois, trimestre, année ;
 modes de traitements : lots, temps réel différé, temps réel ;
 types d’entrées : lots sur supports magnétiques, lots entrés d’un poste de
travail, entrées aléatoires d’un poste de travail, interfaces, données générées ;
 fonctionnalités des programmes essentiels à l’application : validation, tri,
fusion, calculs, mise à jour, édition ;
 types de sortie : impression de documents, fichiers.
Les informations nécessaires sont parfois difficiles à obtenir, la documentation
informatique est rarement à jour et au niveau de synthèse souhaité par l’auditeur, de
plus à défaut de dictionnaires de données, la documentation est souvent éclatée
entre plusieurs professionnels de l’informatique : programmateur, préparateur,
gestionnaire de bases de données, gestionnaire de la sécurité. Lorsqu’il n’existe pas
vraiment de documentation, l’analyse des ordres de contrôle permet à l’auditeur
d’identifier au minimum les programmes et fichiers nécessaires à l’exécution des
traitements.
La compréhension du flux doit rester très générale à ce niveau. Elle est documentée
dans les papiers de travail du dossier permanent des systèmes sous forme de
diagrammes de circuit de l’information et de narratifs. L’objet de cette documentation
est de permettre d’appréhender la probabilité d’erreurs.
• identification par l’auditeur des procédures nécessaires de
contrôle :
Cette identification est réalisée par la confrontation des objectifs d’audit aux risques
de l’application tels qu’identifiés par l’analyse du ou des diagrammes de circulation
de l’information. Cette confrontation permet de déterminer, par objectif d’audit, les
éléments de traitement nécessitant, de la part de l’entreprise, la mise en place de
procédures appropriées de contrôle.
L’identification des procédures nécessaires de contrôle est documentée par
l’auditeur dans une feuille de travail »analyse des contrôles ». Pour réaliser avec
succès cette identification, les objectifs d’audit doivent être affichés par la prise en
compte de la spécificité et de la complexité de l’application.
• identification des procédures de contrôle mises en place par
l’entreprise : après avoir identifié, dans la feuille d’analyse des contrôles, les
traitements où des procédures de contrôle sont nécessaires pour satisfaire aux
objectifs d’audit, l’auditeur recherche les procédures de contrôle effectivement
mises en place par l’entreprise. Deux cas peuvent se produire :
 soit l’auditeur dispose, dans les informations obtenues lors de la phase de
compréhension du système, des éléments pour répondre et il n’a pas besoin
de faire des recherches complémentaires.
 soit il doit s’adresser au personnel de l’entreprise pour obtenir des
compléments d’information, l’absence apparente de contrôle pouvant être due
à une compréhension insuffisante du système. Dans ce cas l’auditeur doit
s’adresser à un niveau hiérarchique ayant une vue d’ensemble suffisante du
système.
• Tests d’existence :
L’auditeur qui analyse et décrit un système en vue de l’évaluer peut facilement :
 soit déformer certaines informations ;
 soit obtenir des informations « sur ce qui devrait être » et non pas sur ce qui
est.
L’auditeur doit donc s’assurer que sa compréhension de l’application est correcte.
Pour la vérifier, l’auditeur effectue un test de confirmation de l’existence des
procédures « test d’existence ».
Ce test consiste à sélectionner des données significatives pour lesquelles l’auditeur
vérifie que les étapes des traitements manuels et informatisés, ainsi que les
procédures de contrôle fonctionnent comme décrits dans les diagrammes de
circulation de l’information et les narratifs.
Pour réaliser ce test, l’auditeur procède en partant du grand livre, pour être sûr de
sélectionner des données qui ont été entièrement traitées, puis remonte à la
description du système en prenant, à chaque étape, une photocopie du document
concerné. Sur les copies de ces documents, l’auditeur identifie :
 la matérialisation des contrôles effectués ;
 l’enchaînement des phases de traitement ;
 les services d’où les documents ont été extraits.
Les documents ainsi obtenus sont classés en annexe des diagrammes du circuit de
l’information et des narratifs.
Si au cours des tests l’auditeur constate qu’un contrôle qu’il avait décrit n’est pas
exécuté, ou découvre un contrôle important qu’il n’avait pas identifié, il examine tout
d’abord les autres documents qui en sont au même stade de traitement pour
s’assurer qu’il n’est pas en présence d’une exception. Si cet examen confirme
l’anomalie, tous les éléments des papiers de travail, narratifs et feuilles d’analyse des
contrôles doivent être mis à jour.
♦ 3ÈME ÉTAPE : ÉVALUATION PRÉLIMINAIRE

A ce stade, au vu des diagrammes de circulation de l’information, des narratifs et des
feuilles d’analyse des contrôles, l’auditeur est en mesure d’appréhender les éléments
suivants :
 les risques potentiels d’erreurs ;
 les procédures de contrôle développées par l’entreprise pour prévenir ou
détecter les erreurs potentielles ;
 l’impact théorique des procédures de contrôle, ou de leur absence sur la
probabilité des erreurs ;
 l’impact des problèmes liés à l’organisation des tâches entre les fonctions,
identifiés à l’aide des grilles de séparation des fonctions ;
 l’impact des procédures d’organisation et de contrôle de la fonction
informatique sur le fonctionnement des procédures de contrôle de
l’application.
Sur la base de ces informations, l’auditeur peut répondre à deux questions
essentielles :
 les procédures de contrôle de l’application permettent-elles d’atteindre les
objectifs d’audit ?
 les procédures de contrôle de l’application peuvent-elles être utiles à la
conduite de l’audit ?
L’évaluation préliminaire va amener l’auditeur à constater l’une des situations
suivantes :
• les contrôles existants permettent d’atteindre les objectifs et sont utiles : dans
ce cas, l’auditeur devra s’assurer que les procédures de contrôle fonctionnent
réellement et, dans cette hypothèse s’appuyer sur les procédures de contrôle
pour limiter les travaux de vérification sur les comptes.
• Les contrôles existants ne permettent pas d’atteindre les objectifs, ou ne sont
pas utiles à l’audit : dans ce cas l’auditeur ne vérifiera pas leur fonctionnement
mais il devra évaluer l’incidence potentielle de cette absence de contrôle. Pour
procéder à cette évaluation, l’auditeur décrit les contrôles inefficaces dans une
feuille de travail « incidence des risques identifiés » et l’impact des risques.
Avant de décider d’une vérification approfondie des comptes concernés par les
risques potentiels, l’auditeur devra essayer de les quantifier en procédant à des
tests étendus sur les données. A la suite de ces tests, il pourra être constaté
que les risques potentiels d’erreurs n’avaient pas d’incidence significative.
♦ 4ÈME ÉTAPE : PLAN D’APPROCHE DE L’AUDIT

L’évaluation préliminaire permet à l’auditeur d’établir et de planifier l’organisation des
tests :
 tests de vérification du fonctionnement des contrôles lorsque l’auditeur a
l’intention de s’appuyer sur le contrôle interne d’une application pour limiter,
selon son jugement, les tests sur les soldes des comptes.
 tests étendus sur les données pour quantifier les risques d’erreurs
potentielles lorsque l’auditeur n’a pas l’intention de s’appuyer sur le contrôle
interne, ou lorsque les procédures de contrôle sont inexistantes, inefficaces ou
insuffisantes.
 tests limités sur les soldes des comptes si les tests mentionnés ci-dessus
démontrent une absence raisonnable de probabilité d’existence des risques
d’erreurs.
 tests étendus sur les soldes des comptes si les tests montrent ou confirment
l’existence de risques.
L’ensemble des tests à conduire par l’auditeur constitue le plan d’approche de l’audit
d’une application ; généralement la partie informatisée des applications est plus
sujette à des modifications que la partie manuelle. Pour cette raison, l’auditeur qui
s’appuie sur des contrôles programmés doit avoir l’assurance préalable que les
procédures de la fonction informatique permettent :
 un chemin de révisions des modifications ;
 un contrôle efficace des modifications et des accès.
A défaut de procédures satisfaisantes, l’auditeur doit rechercher si, en conséquence,
des tests sur les données et les soldes des comptes ne seraient pas plus appropriés
vu les risques liés à l’organisation de la fonction informatique.
♦ 5ÈME ÉTAPE : TESTS DE VÉRIFICATION DU FONCTIONNEMENT DES

CONTRÔLES
Ces tests ont pour objet de s’assurer que les procédures de contrôle fonctionnent
bien comme annoncées par l’entreprise et comme compris par l’auditeur. La nature,
la période et l’étendue des tests sont une question de jugement, l’auditeur prend
généralement en compte les facteurs suivants :
 le degré de confiance qu’il entend placer sur le contrôle interne pour limiter les
tests sur les données ;
 la force probante de la matérialisation des contrôles ;
 le besoin de s’assurer que les contrôles ont été appliqués de façon
satisfaisante tout au long de l’exercice comptable.
Les techniques d’audit pour la mise en œuvre des tests de vérification des contrôles
concernent l’observation et l’examen de la matérialisation des contrôles.
Plusieurs techniques sont plus spécifiques à l’informatique :
• Examen a posteriori des listes d’anomalies produites par l’ordinateur pour
s’assurer que les contrôles programmés fonctionnent comme décrits dans la
documentation et sont périodiquement analysés. La fiabilité de cet examen
dépend très largement de l’appréciation des procédures de contrôle propres à la
fonction informatique.
• Saisie par l’auditeur de données dans les traitements informatisés et vérification
du fonctionnement des procédures de contrôle ;
• Examen des programmes sources où sont codés les contrôles. La mise en
œuvre de ce genre de test rencontre plusieurs difficultés : expertise très
approfondie des techniques de programmation/évaluation satisfaisante des
procédures de modification et d’accès aux programmes.
Après réalisation des tests de vérification du fonctionnement des contrôles, l’auditeur
est confronté à l’une des situations suivantes :
 les tests ne révèlent aucune anomalie : les conclusions de l’évaluation
préliminaire sont confirmées et l’auditeur peut préparer son programme de
contrôle des comptes selon les grandes lignes qu’il avait fixées dans le plan
d’approche de l’audit.
 les tests révèlent des anomalies : l’auditeur doit, dans cette hypothèse,
évaluer l’incidence de l’inefficacité des procédures de contrôle et modifier en
conséquence le plan initial d’approche de l’audit.
♦ 6ÈME ÉTAPE : TESTE SUR LES DONNÉES ET/OU SUR LES SOLDES
DES COMPTES
L’objet de ces tests est de déterminer si l’application a généré des erreurs et si ces
erreurs ont un impact significatif sur les états financiers. Ces tests peuvent être
conduits manuellement ou en utilisant les possibilités offertes par les techniques de
l’informatique. Le choix de ces deux natures de tests est fonction :
 de la population des données ;
 de l’importance et de la complexité des informations à traiter ;
 de l’existence, ou non, d’un chemin de révision sur support-papier ; l’auditeur
doit prendre en compte le fait que dans les systèmes informatiques complexes
et très intégrés le chemin de révision prend souvent la forme de support
magnétique.
♦ 7ÈME ÉTAPE : ÉVALUATION FINALE

L’évaluation finale de l’auditeur sur les traitements automatisés dépend du résultat
de l’exécution des tests planifiés dans le plan d’approche de l’audit.
Cette approche porte fondamentalement sur la propension des traitements à
satisfaire à l’objectif de l’auditeur en matière de certification de la régularité et de la
sincérité des comptes annuels. Parallèlement à cette évaluation l’auditeur doit porter
à la connaissance de la direction générale les insuffisances des notées dans
l’organisation du contrôle interne des traitements.
Dans la pratique, l’auditeur rencontre rarement des situations où le contrôle interne
est pleinement satisfaisant ou à ’opposé, complètement inefficace. En fait le plus
souvent, une partie seulement des procédures de contrôle en accord avec les
objectifs de l’audit.
L’intérêt de la méthode d’audit présentée est de s’adapter à ces situations et de
permettre de se développer des tests adaptés à l’évaluation des risques.
F. CONTRÔLE de la comptabilisation achats fournisseurs, enregistrement
des factures, journalisation et centralisation
L’auditeur avant d’identifier les risques spécifiques de l’application, dans les feuilles
d’analyse des contrôles, établit pour les principaux modules un diagramme du circuit
de l’information accompagné d’un narratif.
Diagramme de circuit d’information (I) :

Comptabilité achat-fournisseurs : saisies factures en temps réel ;
Comptabilité
Fonction informatique
Fournisseurs
Factures
Bordereaux Tables
Etc. d’accès
Contrôle
profils
d’accès
Tables
Taux
TVA
Tables
Taux de
change
Bons de
Fichiers :
récep- Validation Ecritures
enregistrement ECJ comptables de la
journée
tion
Fichiers
Fournis-
seurs
Plan de
comptes
 Narratif comptabilité achat fournisseurs : saisie des factures en temps réel.

A- Contrôle du profil d’accès
Contrôle que le mot de passe de l’utilisateur permet d’accéder à la transaction
« validation–enregistrement »
B- Contrôle de validation
 existence du compte fournisseur par appel du fichier fournisseurs
 appel des tables TVA et taux de change pour cohérence entre le montant saisi
et le montant recalculé.
 existence du mois sur lequel l’utilisateur désire imputer la facture
 renvoi à l’écran d’informations quand l’utilisateur saisit certains codes :
Numéro fournisseur
Numéro de société
Numéro de compte de charge ou d’immobilisation
 nécessité d’un bon de réception préalable pour qu’une facture soit acceptée.
 Diagramme de circuit d’information (II) :

Comptabilité achats fournisseurs : journalisation, traitement par lots
COMPTABILITE
FONCTION INFORMATIQUE FOURNISSEURS
EC
J
Rapport de
SAUVEGARDE Contrôle N°1
Bande de
sauvegarde Eclatement
des
écritures
Rapport de
Contrôle N°2
EC
FA
G
F
Fichier Fichier factures

écritures et avoirs
comptabilité fournisseurs
générale
 Diagramme du circuit de l’information (III) :
Comptabilité achats fournisseurs : journalisation, traitement par lots
F
A
F
TRI TRI TRI

1* 2* 3*
Fonction
informat
ique
F F F
A A A
F F F
trié Livres trié trié
auxiliaires
fournisseu Ecritures du
mois (j-1)
rs (j-1)
Comptabilisation Journalisation Pré-centralisation
Livres
auxiliaires
fournisseurs Ecritures du
(j) mois (j)
Comptab Rapport Rapport

ilité de Journaux de
fournisse contrôle d’achats contrôle
urs N°3 N°4
* Tri 1 : Par N° de
fournisseur
* Tri 2 : Par N° de journal
* Tri 3 : par N° de compte
et de journal
 Narratif comptabilité achats- fournisseurs : journalisation par lots
A- Nature des rapports

Rapport 1 : Nombre d’enregistrements lus
Rapport 2 : Nombre d’enregistrements lus par éclatement
Total des montants des factures et avoirs fournisseurs
Total du montant des autres éclatements
Total du montant des écritures lues
Nombre du montant des écritures lues
B- Nature des journaux

Journaux : achats de biens et services
Journaux : immobilisations
 Diagramme de circuit de l’information
Comptabilité achats- fournisseurs : centralisation mensuelle par lots :
Ecritures
du mois
Tri
Sur N°
Compte
Totalisation
Date du mois clôturé par N°
FONCTION
compte INFORMATIQUE
Total écritures mensuelles

Par
N° compte
Livres auxiliaires Grand

mois Validation livre
m-1 mois m-1
centralisation
Livres Grand
auxiliaires Livre
Mois m mois m
Anomalie Journaux de COMPTABILITE

s centralisation
Narratif audit de la comptabilité achats fournisseurs : centralisation
mensuelle par lots.
Phase de validation/ centralisation

Rapprochement des livres auxiliaires fournisseurs des mois m-1 et m, et contrôle de
cohérence entre l’écart m-(m-1) et le total du fichier « total des écritures mensuelles
par numéro de compte ». En cas de différence, une liste d’anomalies a été éditée.
Rapprochement des soldes fournisseurs des livres auxiliaires fournisseurs du mois m
avec les soldes fournisseurs collectifs correspondants au Grand Livre du mois. En
cas de différence, une liste d’anomalies est éditée.
 Feuille d’analyse des contrôles (voir annexes)

 Conclusion
A- Evaluation préliminaire
Sur la base des informations reportées sur les feuilles d’analyse des contrôles,
l’auditeur a conclu que les procédures de contrôles ne remplissaient que les
objectifs d’audit.
Objectif d’exhaustivité :
 il n’y a pas de procédures permettant de s’assurer que toutes les factures de
services sont bien enregistrées.
 Il n’y a pas de procédures suffisantes permettant de s’assurer que toutes les
factures des services sont bien enregistrées dans la bonne période.
 Sous-objectifs d’imputation : il n’y a pas de procédures suffisantes permettant
de s’assurer que les factures (quelle que soit leur nature) sont imputées dans
les bons comptes de charges et d’immobilisations.
B- Plan d’approche de l’audit

En prenant pour base les conclusions de l’évaluation préliminaire, l’auditeur a
développé le plan d’approche de l’audit présenté ci-dessous :
Tests de vérification du fonctionnement des contrôles :
 Observation par sondage, du fonctionnement et de la justification des contrôles
 Examens par l’édition des tables d’accès CICS aux transactions
 Saisie de données par l’auditeur (jeux d’essai)
 Tests sur les données et les soldes des comptes :
• Exhaustivité de l’enregistrement des factures de services :
(date d’appréciation du contrôle interne 15 novembre année n)
(date de vérification des états financiers : 15 février année n+1)
Détermination pour les factures de services de la durée moyenne entre la date
de réception et la date d’enregistrement comptable de la facture. Ce test est
réalisé par un programme informatisé développé par l’auditeur.
Si la durée moyenne obtenue est inférieure à 45 jours, l’auditeur procèdera le
15 février à la recherche des factures de services de l’année n, enregistrées sur
l’année n+1 pour vérifier qu’elles sont provisionnées sur l’année n+1.
Si la durée est supérieure à 45 jours, l’auditeur procèdera à la recherche des
factures de services de l’année n, enregistrées sur l’année n+1 à une date la
plus rapprochée de l’émission de l’opinion sur les états financiers.
• Imputation correcte des factures d’achat et d’immobilisations :
Echantillonnage statistique sur la population de l’année n des factures d’achat
de biens, de services et d’immobilisations. Cet échantillonnage est déterminé
sur la base d’un test informatisé développé par l’auditeur. Deux situations sont
envisagées :
 S’il n’y a pas d’erreurs significatives, l’auditeur ne procèdera sur
les comptes arrêtés au 31 décembre de l’année n (charges et
immobilisations) qu’à des tests limités de cohérence du type contrôles
indiciaires.
 Si des erreurs significatives sont constatées, l’auditeur
appréciera s’il y a un risque quant à la présentation des états financiers.
Contrôle de la mise à jour du fichier fournisseurs

L’auditeur ayant identifié les risques spécifiques de l’application dans les feuilles
d’analyse des contrôles, établit pour les principaux modules un diagramme du circuit
de l’information accompagné d’un narratif.
 Diagramme de la mise à jour en temps réel
Comptabilité fournisseurs Fonction informatique
Bordereau Table
d’accès
CICS
Contrôle profil
d’accès
Validation
et
mise à jour
Fichiers
fournis-
seurs
Narratif de la mise à jour du fichier fournisseurs : traitement en temps réel
A- Contrôle du profil d’accès

CICS contrôle que le mot de passe de l’utilisateur permet d’accéder à la transaction
de validation et de mise à jour du fichier fournisseurs.
B- Contrôle de validation
 Si création, vérification que le fournisseur n’existe pas déjà
 Si suppression, vérification que le fournisseur n’a pas de solde différent de zéro,
 Pour les fournisseurs étrangers, rejet du :
Code TVA indiquant un taux différent de 0
Code de paiement différent de paiement par virement
 Informations obligatoires
Nom et adresse
Mode de paiement
Code fiscal, code devise
Marocain ou étranger
Fournisseurs ; immobilisations, matières premières, autres,
Numéro de compte
C- Fichiers fournisseurs
 Contenu :
 Nom et adresse
 Mode de paiement
 Marocain ou étranger
 Code fiscal, code devise
 Fournisseurs : immobilisations, matières premières, autres
 Numéro de compte
 Date de création et de mise à jour.
 Diagramme du circuit de l’information (II) : mise à jour du fichier

fournisseurs : traitement par lots
Fonction informatique Comptabilité fournisseurs
(A) Edition des comptes

Fichier crées, modifiés,
fournis- annulés
seurs
(A) Sélection sur date du jour

des comptes crées, modifiés,
annulés
 Conclusion
A- Evaluation préliminaire
Sur la base des informations reportées sur les feuilles d’analyse des contrôles, l’audit
a conclu que les procédures de contrôle étaient de nature à satisfaire les objectifs
d’audit.
B- Plan d’approche de l’audit
En prenant pour base les conclusions de l’évaluation préliminaire, l’auditeur a
développé le plan d’approche de l’audit présenté ci-dessous :
Test de vérification du fonctionnement des contrôles :
 Examen de l’édition des tables d’accès CICS aux transactions
 Observation par sondage du fonctionnement et de la justification des contrôles
 Saisie des données par l’auditeur (jeux d’essai).
VI. Les techniques de contrôle basées sur l’informatique
A. Techniques_d’audit informatique utilisant l’ordinateur
♦ AVANTAGES ET LIMITES :
La limitation du risque grâce à la possibilité d’effectuer une ou plusieurs analyses
exhaustives et cela sans porter atteinte au facteur temps. Au contraire l’outil
informatique a permis à l’auditeur d’économiser le temps et donc de minimiser les
coûts par le biais de l’automatisation des travaux, qui normalement étaient effectués
de manière manuelle.
Mais ceci n’est valide que si l’auditeur possède l’aptitude à manipuler correctement
l’outil informatique, ce qui présente déjà une limite. Mais ce n’est pas tout, car
l’utilisation de l’informatique nécessite au départ des dépenses colossales quant à
l’achat de matériel nécessaire et des progiciels sans lesquels l’auditeur ne peut pas
profiter intégralement du matériel qu’il possède. Il faut ajouter à cela les nombreux
tests pour s’assurer de la fiabilité des programmes utilisés.
B. Techniques_de_l’audit informatique
♦ JEUX D’ESSAIE :
• Définition et application :
Cette méthode consiste à introduire au programme déjà existant des informations
réelles et de suivre après, le cours des traitements effectués puis, d’analyser les
résultats obtenus.
Généralement ces jeux permettent de vérifier les programmes du centre
d’informations, la logique des traitements et les routines de calculs particulières
(calculs d’intérêts, d’amortissements…).
• Avantages :
 simples d’utilisation
 ne demandent pas de compétences particulières en informatique
• Limites :
 Non-adéquation aux programmes complexes
 lourdeurs des précalculs
 inadaptation aux vérifications de longue durée
• Dans la même rubrique on signale l’existence de jeux d’essai standards qui
contrairement aux précédents visent surtout à tester le programme face à des
situations courantes, d’où l’appellation « standards ».
♦ LES TESTES INTÉGRÉS :

La fiabilité du système est assurée par l’introduction d’informations fictives, et la
comparaison des résultats obtenus ceux calculés au préalable par l’auditeur.
Ces tests ne sont possibles que dans le cas où le système possède un mode de
travail «essai » pour ne pas affecter les résultats réels donnés par le système.
• Avantages :
 l’abondance du temps affecté à ce type de tests qui permet de déceler
d’éventuelles anomalies
 rapidité d’utilisation
• Limites :
 nécessite des techniques spécifiques en informatique
♦ LES TESTS EN PARALLÈLE :

A l’aide de son propre programme vérifie la compatibilité des résultats donnés par le
programme utilisé par l’entreprise auditée, avec ceux fournis par le programme qu’il
possède.
Ces tests concernent plutôt des programmes bien définis
• Avantages :
 une qualification réelle des anomalies détectées
• Limites :
 difficultés particulières dans la mise en œuvre des tests, à cause des calculs
colossaux et des formules complexes à utiliser pour la création de ces
programmes
 compétences particulières en informatiques pour écrire et analyser ce type de
programme (langages de programmation)
 mise en œuvre assez longue et utilisation délicate.
♦ SÉLECTION DES DONNÉS DANS UN FICHIER :

Cette définition vise un contrôle de certaines informations traitées prélevées
scientifiquement ou aléatoirement sur des fichiers du programme.
La particularité des informations recueillies réside dans leur simplicité.
• Avantages :
 fiabilité des résultats à cause des prélèvements : sur des fichiers réels.
 rapidité d’utilisation
• Limites :
 conservation des fichiers choisis pour la vérification
 risque d’inexploitation des données sélectionnées à cause de leur abondance
 risque de non-détection de quelques anomalies a causes des méthodes de
sélection utilisées
• Compétences requises :
L’auditeur doit avoir une connaissance informatique suffisante pour comprendre la
structure des fichiers et pour réaliser des programmes.
La liste des tests qu’on a proposés n’est pas exhaustive, il existe en fait, plusieurs
tests tels que les fichiers « crochets » et l’analyse des fichiers créés par le système
d’exploitation.
Comme synthèse nous vous présentons un tableau résumant les possibilités de
chacune des techniques précédemment expliquées :
Techniques D’audit Test De Vérification Du Test De Quantification Sur

Informatique Fonctionnement Des Les Données Et Les
Procédures De Contrôle Soldes
Jeux d’essai +
Jeux d’essai standards +
Les tests intégrés + +
Les tests en parallèle + +
Sélection des données
+
dans un fichier
Les fichiers « crochets » + +
L’analyse des fichiers créés
par le système +
d’exploitation
Le choix entre les tests s’avère difficile, il est cependant recommandé d’opter pour
ceux qui restent simples mais adéquats évidemment à l’objectif même de ce test.
C. Organisation de la mise en œuvre des tests informatisés
Ce chapitre insiste sur les préoccupations à maîtriser pour réussir le développement

de tests informatisés et pour documenter, sur le plan pratique et déontologique, ce
type de travaux d’audit.
♦ CONTRAINTES LIÉES AUX TESTS INFORMATISÉS
a- Planification :
Le fait d’utiliser des fichiers, de même que les moyens informatiques de l’entité
contrôlée imposent de nouvelles contraintes au niveau de la planification de
l’intervention de l’auditeur :
• Une étude préalable doit être effectuée à partir des connaissances déjà
acquises sur le système lors de l’étude du contrôle interne Cette étude
permettra de déterminer :
 La faisabilité des travaux envisagés en fonction de la compatibilité des matériels
face aux outils disponibles, de la structure des informations gérées dans le
système et des délais impartis ;
 Une première estimation de la charge nécessaire en temps/homme, qui ne peut
être déterminée que par un auditeur ayant une expérience suffisante de ce
type de travaux.
• La détermination des fichiers à utiliser, après étude de leur rotation ( nombre
de générations conservées, durée de conservation) conduit à demander à
l’exploitation des archivages spécifiques de sauvegardes, des copies
complémentaires, des modifications dans les cycles de rétention, voire des
changements dans la définition de la nature de certains fichiers, etc . L’auditeur
doit procéder à cet examen suffisamment tôt pour ne pas courir le risque, à la
date d’intervention, de se retrouver devant une absence des fichiers qu’il
s’apprêtait à contrôler.
• L’évaluation des charges de temps machine et des contraintes de disponibilité
des « périphériques », afin de pouvoir prévoir, avec le service exploitation, une
disponibilité suffisante des ressources.
L’exécution préalable de ces tâches permet l’élaboration d’un planning réaliste (si
possible prévoyant la souplesse nécessaire, pour tenir compte des aléas non
planifiables : pannes, difficultés imprévues). Dans le cas de travaux répétitifs, d’un
exercice à l’autre, ce planning sera évidemment beaucoup plus facile à définir.
b- Obligation de résultat :
Si l’essence même des travaux de l’auditeur repose sur une obligation de moyens, il
n’en est pas de même au niveau des tests informatisés qui impliquent une obligation
de résultat : un programme, même prêt à 99%, n’est pas opérationnel et risque alors
de bouleverser toute l’organisation d’une mission basée sur les travaux
informatiques. Ce point, évident a priori, n’est pas toujours suffisamment bien perçu.
c- Sites avec bases de données :

De nombreux sites fonctionnent avec des bases de données dédiées la journée aux
travaux transactionnels. Le soir, après une phase de sauvegarde, ces bases de
données sont consultées et mises à jour par des travaux par lot. Durant toutes ces
périodes, les bases de données ne sont en général pas partageables avec d’autres
travaux. Aussi l’auditeur se retrouve-t-il avec des possibilités de travail fractionnées
et très réduites.
Cette situation est un frein très important dans le développement de tests
informatisés et demande une organisation particulière :
• Préparation des travaux d’analyse sur des bases de données de tests, qu’il
faudra quelquefois constituer de toutes pièces, ces bases n’existant pas en
permanence dans l’environnement de tests ;
• Soumission différée des travaux d’audit ; ces travaux doivent être planifiés en
accord avec le service de préparation. Le nombre de passages est alors limité ;
en conséquence l’auditeur doit préparer très complètement son travail.
La mise à « plat » de la base est une possibilité souvent évoquée pour pallier ces
problèmes, l’auditeur travaillant alors sur un fichier indépendant de l’exploitation. Il
faut remarquer que la mise à plat d’une structure à plusieurs dimensions va très
souvent « briser » des liens, donnant une image déformée ou incomplète de la base
à l’auditeur. Suivant le type d’interrogation requise, il sera alors nécessaire de
procéder à plusieurs mises à plat, apportant des contraintes de temps machine et de
volume de stockage.
Une autre solution est de dupliquer la base de données, la figeant ainsi pour les
travaux de l’auditeur. Cette hypothèse, dans la pratique, n’est que rarement réaliste,
face aux problèmes organisationnels et aux besoins de capacité disque
complémentaire. Se surajoute à ces problèmes matériels le fait que la base de
données est, par sa nature même, un ensemble vivant ; sa photographie instantanée
implique alors des contraintes de planning draconiennes.
d- Utilisation du site de l’entité contrôlée ou d’un site externe :

L’auditeur peut envisager de développer des tests informatisés, soit sur le site
interne de l’entreprise, soit en louant des heures de temps machine sue un site
externe. Cette éventualité est nécessaire dans le cas de l’utilisation d’un progiciel
incompatible avec le matériel de l’entité contrôlée.
L’utilisation sur un site externe induit des contraintes complémentaires : acceptation
par l’entité contrôlée de la sortie des supports magnétiques et précautions
particulières pour conserver la confidentialité des informations (états non nominatifs,
destruction systématique de tous les fichiers de travail, sécurisation des supports ; le
cryptage peut être éventuellement retenu comme solution). La règle générale qu’il
est souhaitable de mettre en œuvre est d’obtenir, même pour un travail sur le site de
l’entité contrôlée, des copies de fichiers et de ne jamais travailler sur les fichiers
réels. Dans ce contexte, l’auditeur doit se doter des moyens de contrôle pour
s’assurer que la copie est bien identique au fichier d’origine, et qu’elle correspond à
la bonne version du fichier.
Dans certains cas, il n’est pas possible d’obtenir des duplications de fichiers : bases
de données, fichiers disques trop volumineux et consultés en accès direct ou indexé.
L’auditeur ne doit utiliser ces fichiers qu’après accord formel de la Direction et avec
un surcroît de précautions dans la définition des procédures (l’effacement accidentel
d’un fichier doit être évité à tout prix).
♦ ORGANISATION :
L’organisation porte sur la mise en œuvre des phases suivantes :
• Détermination des objectifs : Elle doit être claire et précise, surtout si l’auditeur
confie à un auditeur spécialisé la mise en œuvre de tests informatisés. En
particulier, la notion de date à laquelle les informations doivent être analysées
est fondamentale. Les termes utilisés doivent être définis avec précision pour
éviter toute confusion, ce qui sous-entend que l’auditeur doit bien connaître le
système à contrôler.
• Estimation du coût : quelquefois difficile à déterminer à priori, cette estimation
est indispensable pour pouvoir faire le choix entre travail manuel et tests
informatisés. Ce coût peut être éventuellement « lissé » sur plusieurs
interventions pour aboutir à un coût acceptable par intervention.
• Analyse des objectifs : la détermination des informations à collecter pour
répondre aux objectifs se fait par entretien avec les responsables des
applications et par analyse de la documentation existante.
• Une difficulté fréquemment rencontrée est liée à la méconnaissance de la part
des services informatiques des fichiers utilisés, en particulier dans les cas
d’informatique distribuée ou d’utilisation de progiciels standard. L’analyse
aboutit à un « mini-cahier des charges » détaillé, qui est discuté avec l’auditeur,
généraliste responsable de la certification des états financiers. De plus, les états
fournis doivent être un support de travail pour les auditeurs. A ce titre ils doivent
être compréhensibles et organisés en fonction de leur exploitation ultérieure :
 Séquence de tri
 Totalisations
 Rupture
 Saut de page
Afin de pouvoir intégrer plus facilement les résultats dans les dossiers, il est
possible d’y indiquer une référenciation et de prévoir des colonnes vierges
pour un dépouillement ultérieur.
• Développement : Le développement des programmes, basé sur l’analyse, doit
être organisé pour que les travaux soient clairs, compréhensibles et
suffisamment simples. Suivant le cas, des tests préalables devront être montés,
ce qui suppose la constitution de jeux d’essai ou l’utilisation de fichiers d’essai
préexistants.
• Mise en œuvre : elle concerne l’exploitation des programmes avec les fichiers
réels. En règle générale, un accord est préalablement pris avec l’exploitation, en
particulier si des montages de bandes doivent être effectués.
• Dans le cas d’enchaînements de travaux, il sera nécessaire de décrire ces
derniers sur les formulaires généralement utilisés par l’exploitation pour les
demandes de travaux exceptionnels, ceci afin d’éviter les erreurs et d’obtenir les
résultats dans les délais souhaités.
Un contrôle formel doit être effectué dès l’obtention des résultats par rapport à des
éléments connus : totalisation, nombre d’enregistrements, données d’exception déjà
repérées manuellement, afin de s’assurer d’un premier niveau de validité des tests.
Un contrôle plus fin devra être effectué ensuite par rapport aux données
mentionnées dans les états de l’entreprise. Si des différences apparaissent, elles
doivent être totalement expliquées, ce qui peut nécessiter des tests
complémentaires, avant de pouvoir accorder un niveau de confiance suffisant aux
travaux effectués par l’auditeur.
♦ DOSSIER DE TRAVAIL :
Pour l’ensemble des tests informatisés, il est nécessaire de constituer un dossier
spécifique dont le contenu devra comprendre, pour un test donné :
• Le rappel des objectifs du test, avec les paramètres utilisés, par exemple :
 Le niveau de confiance, la précision, le taux d’erreurs retenues pour un
échantillonnage, et les méthodes préconisées ;
 Le calcul d’un prix moyen pondéré, etc.
• Le diagramme des traitements, avec les noms des programmes utilisés, des
fichiers lus et créés et l’indication des volumes nécessaires pour les charger.
Lorsque des programmes de tri sont utilisés, la mention des critères de tri est
également indiquée.
• Les dessins de fichiers, sous forme traditionnelle ou sous description
informatiques. Si des fichiers intermédiaires sont créés, leur description est
également mentionnée dans le dossier.
• Les descriptions de programmes, soit sous forme de narratif, soit, ce qui est
plus efficace, sous forme de commentaires détaillés dans les programmes,
facilitant ainsi leur mise à jour.
• Les ordres de contrôle
• Les programmes sources ou les paramétrages (utilitaires, progiciels d’audit).
• Les états obtenus ou une copie de feuillets significatifs. Le cas échéant, il est
nécessaire d’expliciter certaines colonnes.
• Les moyens de contrôle mis en œuvre pour s’assurer que :
 L’on a traité le bon fichier ;
 Le fichier a été intégralement traité ;
 Le test utilisé a bien fonctionné.
• La liste des bibliothèques utilisées, avec leur contenu. Si, à la fin des travaux,
les programmes ont été sauvegardés sur un support magnétique, ce qui est
vivement recommandé, le dossier fait mention du support, de son organisation,
de son identification et des outils nécessaires pour son rechargement.
• Le descriptif des manipulations nécessaires pour :
 Développer les programmes (fonctionnement de l’éditeur, création des
bibliothèques, affectation de supports magnétiques),
 Visualiser ou éditer le contenu des états obtenus,
 Soumettre les travaux
• Pour chaque test est mentionnée la conclusion tirée des résultats.
Eventuellement, un paragraphe reprend les points à améliorer ou à développer
pour l’audit suivant.
En conclusion, le dossier doit être suffisamment développé pour permettre le
contrôle et la supervision des travaux effectués, et pour assurer la continuité des
travaux sur l’exercice suivant.
L’organisation de la mise en œuvre des tests informatisés demande de la part de
l’auditeur de l’expérience, de la compétence et de la prudence. Par un juste retour
des choses, l’auditeur doit s’imposer une rigueur comparable à celle qu’il exige des
entités contrôlées en matière de développement de système, notamment en ce qui
concerne la documentation et les contrôles sur la fiabilité des informations produites.
VII. SYSTÈMES experts et audit
A. PRÉSENTATION
On peut constater ces dernières années un intérêt soutenu porté aux systèmes
experts dans le processus d’informatisation et de bureautisation des travaux d’audit
et de conseil. Ce sujet est abordé en trois parties :
 situer les systèmes experts dans leur environnement plus global de l’intelligence
artificielle et des ordinateurs.
 Présenter les principales caractéristiques des systèmes experts ainsi que leurs
modalités de développement.
 Décrire les principales caractéristiques des systèmes experts disponibles ou
projetés dans le domaine de l’audit.
B. L’environnement_des_systemes experts
♦ L’INTELLIGENCE ARTIFICIELLE :
On peut la définir comme la science qui construit un modèle de fonctionnement basé
sur le fonctionnement intellectuel de l’Homme. Elle comporte d’ores et déjà de
nombreuses branches et des secteurs à niveau de développement inégal.
♦ LA CONNAISSANCE :
C’est la représentation symbolique des objets du monde extérieur et les relations qui
les lient.
L’intelligence symbolique attachera une importance capitale au traitement
d’informations telles que des expressions mathématiques ou des connaissances
descriptives.
C. Approche générale des systèmes experts
♦ DÉFINITION :
Un système ‘expert est un produit qui vise à résoudre des problèmes en suivant un
raisonnement déductif. L’une des applications les plus connues réside dans l’aide au
diagnostic aux forages pour la recherche pétrolière, la détection des pannes dans les
systèmes informatiques, l’aide à l’interprétation des dispositions fiscales et au conseil
fiscal ; l’appréciation du contrôle interne dans les missions d’audit.
♦ OBJECTIFS DES SYSTÈMES EXPERTS :

Le système expert s’efforce de simuler le comportement d’un expert dans sa matière
en vue de résoudre un problème déterminé.
La constitution des systèmes experts implique les étapes suivantes :
 collecter l’ensemble des connaissances et expériences de l’expert humain dans
son domaine.
 Traduire cet ensemble sous forme de règles pour constituer une « base de
connaissance »
 Mettre en œuvre un logiciel d’intelligence artificielle (moteur d’inférence)
permettant d’articuler ces règles entre elles.
EXPERT
Base de connaissances :
Règles
Métarègles
Moteur
d’inférence
Base de frais :
Données.
Description problème
Utilisateur
♦ LES OUTILS DE RÉALISATION DES SYSTÈMES EXPERTS :

On traite souvent des systèmes spécialisés qui sont généralement construits par une
application. Leur moteur d’inférence adopte donc les langages les mieux adaptés à
l’application traitée. Un tel système est généralement écrit en langage machine ou
dans un langage classique évolué comme Pascal.
D. Les systèmes experts en audit
♦ LES SYSTÈMES EXPERTS GÉNÉRAUX :

Ils ont pour objectif d’aider les professionnels dans des domaines généraux tels que
la documentation, la formation et la planification :
 documentation assistée par ordinateur.
 Formation assistée par ordinateur
 Planification des projets et des secteurs.
♦ LES SYSTÈMES EXPERTS DANS DES DOMAINES CONNEXES :

Exemple : droit « automated will writer » : utilisé pour aider à la rédaction des
testaments.
L’économie et la finance : Broker et Reavel.
L’informatique : DART, SYERA
♦ SYSTÈMES EXPERTS DIRECTEMENT LIÉS À L’AUDIT :

Logiciels comptables et de conseil fiscal
Audit financier : La section audit de l’American Accounting Association vient de

proposer le développement des systèmes experts à divers niveaux des travaux
d’audit exemple :
 Auditor : Il permet l’analyse du jugement d’audit avec un système expert sur le
thème des provisions pour créances douteuses.
 Analytical review :
 Contrôle interne : ACL Audit Command Language
Audit informatique : Les chercheurs Hansan et Messier ont développé un système
expert pour assister les auditeurs dans l’évaluation de la fiabilité des systèmes
informatiques avancés.
Il sera essentiel pour les auditeurs de se tenir constamment au fait des évolutions
des systèmes experts afin d’être en mesure d’en faire une utilisation judicieuse dans
leurs missions d’audit.
VIII. Conclusion : l’usage de l’informatique dans l’audit
A la complexité et la sophistication croissante de l’informatique entraînent des

risques dans les entreprises et les organisations, risques qui sont à la mesure de
l’accroissement d’efficacité et de productivité que l’informatique apporte avec elle.
Ces risques, s’ils sont inhérents à l’évolution de l’informatique, sont également très
souvent les conséquences d’une insuffisance organisation et d’une absence de
dispositifs, parfois très simples, qui en permettent le suivi et le contrôle.
Tout au long des pages qui précèdent, nous avons recherché les principaux risques
que l’informatique peut faire naître tant dans la fonction informatique elle –même que
dans les applications informatisées ; nous avons également eu pour préoccupation
de rechercher quelles sont les procédures et contre-mesures les plus utiles pour
pallier et compenser les risques principaux. Ce sont les expériences acquises sur le
terrain auprès d’entreprises de toutes tailles, de niveau et de degré d’informatisation
différents qui ont conduit à ces propositions qui devraient s’avérer directement
utilisables par les dirigeants d’entreprises, les responsables de services
informatiques, les utilisateurs dans l’entreprise et les auditeurs eux-mêmes.
Pour réussir leurs missions, les auditeurs se dotent de méthodes et de techniques de

travail efficaces et de qualité.
Il ne doit pas y avoir ambiguïté sur les objectifs et les finalités de l’audit ;
Il faut demander à l’audit financier dans une entreprise informatisée tout ce qu’il peut
donner.
L’ensemble des méthodes et techniques ainsi élucidées exige de la part de

l’auditeur :
un travail en équipe permettant de répartir les tâches et faisant appel, selon la

complexité du système automatisé rencontré, à des auditeurs spécialisés dans le
domaine informatique, ces équipes pluridisciplinaires sont une des conditions du
succès de l’audit ;
une compétence et une expérience à la hauteur des difficultés rencontrées et de
l’efficacité nécessaire ; la formation en séminaires et sur terrain doit constituer un
investissement important ;
une recherche permanente des méthodes et techniques nouvelles et mieux
adaptées.
L’audit dans un cadre informatisé a suscité des exigences nouvelles pour l’auditeur.
Elles sont à la mesure des attentes des responsables des entreprises. Déjà
aujourd’hui, encore plus demain.
IX.Bibliographie
Intitulé du Livre Auteur(s) Edition
Le contrôle interne des • S. YABLONSKY EDITIONS DE L’USINE
systèmes informatiques • K.L.MYRA NOUVELLE
Informatique de gestion, • J. DELMAS ET CIE AICPA

contrôles et révisions.
Guide pour l’audit financier des • GERARD PETIT CLET
entreprises informatisées • DANIEL JOLY
• JOCELYN MICHEL
L’audit informatique • CLAUDE SAINT- Masson
ANTONIN

Chapitre 1

Transféré par

Informations du document

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

Chapitre 1

Transféré par

Droits d'auteur :

Formats disponibles

L'audit informatique

Pour procéder à l’évaluation des risques informatiques spécifiques à la fonction

La fonction informatique, tout comme les autres fonctions de l’entreprise doivent

L’organisation informatique présente des particularités :

Les risques liés à une organisation insuffisante de la fonction informatique

• Les techniques d’audit permettant d’identifier les risques

D. Limites de l’audit de la fonction informatique

Les conclusions de l’audit de l’organisation générale informatique

Le contrôle de l’organisation générale de la fonction informatique dans le cadre

Les techniques varient bien évidemment, en fonction du domaine de l’intervention :

IV. SÉCURITÉ des accès physiques et logiques

A. Risques sur les ressources logiques

Transfert d’informations commerciales et/ou Remise en cause de la compétition

♦ QUESTIONNAIRE : ORGANISATION ET SÉCURITÉ DES ACCÈS

Pour répondre à cette question, remplir le tableau suivant :

9- Les ressources logiques, y compris les

9- Les ressources logiques, y compris les

- Gestion des mots de passe par une personne

12- Existe-t-il des procédés de journalisation des

13- Cette journalisation permet-elle d’analyser les

PROCEDURES DE CONTROLE A POSRTERIORI

14- Existe-t-il des procédures permettant de

Pour répondre à cette question, remplir le tableau suivant :

B. Risques sur les actifs informatiques

La mise en place d’une stratégie de l’organisation des actes logiques suppose un

♦ ORGANISATION ET SÉCURITÉ DES ACCÈS PHYSIQUES :

Questions oui Non Commentaires et

2. Cette stratégie a-t-elle été développée par des

• documentation base de données,

17. les instructions incendie font-elles l’objet d’une

19. Le système d’alimentation électrique est

33. Existe-t-il, selon les spécificités de l’entreprise,

34. Les procédures de reprise sont-elles

35. Les possibilités et les conséquences d’une

36. Existe-t-il un plan de sauvegarde ?

38. La direction générale et les représentants des

A. Risques liés à l’exploitation

Le tableau ci-dessous présente les risques associés à l’exploitation et les

Procédure d’exécution insuffisante ou

Procédure de contrôle insuffisante ne -IDEM-

Remise en cause de l’intégralité du système

Questions Oui Non Commentaires et renvoi aux

- Une interdiction absolue aux équipes

Une fonction indépendante de

Des consignes en cas

Une rotation à l'intérieur des

- Un accès limite à la documentation

(1) Lorsque la réponse est non, il convient de procéder au

- Un descriptif du flux d'application

- Les procédures de sauvegarde, de

Une gestion des supports selon

- Une journalisation des mouvements

16. La périodicité des visites de

La direction générale attend des traitements automatisés qu’ils gèrent le système

 La mauvaise application des procédures en vigueur dans l’entreprise.

Traitement en temps réel :

Traitement en réel différé :

B. Risques_specifiques_aux traitements automatises

Les phases manuelles et informatisées des traitements peuvent être la cause de

Etapes du flux manuel Causes d'erreurs ou d'irrégularités Risques

Déconnectées de l'unité *Absence d'autorisation préalable *Traitement non

En ligne *Absence d'autorisation préalable *Traitement non

3- Traitement de *Insuffisance des procédures de *Traitement inexact

*Insuffisance des procédures de contrôle *Pas de contrôle

Déconnectées de l'unité Absence d'autorisation préalable Traitement non

En ligne Absence d'autorisation préalable Traitement non

3- Traitement de Insuffisance des procédures de Traitement inexact

Insuffisance des procédures de contrôle Pas de contrôle

Distribution tardive Perte d'efficacité